비용 판단을 설계 단계로 옮기는 Shift Left FinOps
■ 문제: 비용 권고는 배포가 끝난 뒤에 도착합니다. FinOps 실무자 40%가 엔지니어를 움직이는 일을 최대 과제로 꼽았습니다.
■ 해결: 판단 시점을 설계 쪽으로 옮깁니다. FinOps Foundation은 이 영역을 Architecting & Workload Placement 역량으로 정리해 두었습니다.
■ 효과: 설득할 일이 줄어듭니다. 바꿀 수 있는 폭이 가장 넓은 때에 비용이 논의되기 때문입니다.
스테이징에서 멀쩡히 돌던 야간 배치 잡이 프로덕션에 올라간 지 3주 만에 월 비용 보고서 첫 줄에 올라왔습니다. 인스턴스 타입을 고른 자리는 두 달 전 설계 리뷰였고, 그때 비용 이야기는 나오지 않았습니다. 지금 바꾸려면 재배포 일정부터 다시 잡아야 합니다.
Shift Left FinOps가 가리키는 지점
Shift Left FinOps는 비용 판단을 청구서가 아니라 설계도 쪽에 두자는 이야기입니다. 새로 만들어진 개념이라기보다, 실무에서 같은 자리에 반복해서 걸리다 보니 이름이 붙은 쪽에 가깝습니다.
FinOps Foundation의 State of FinOps 설문에서 응답자 40%가 ‘엔지니어가 비용 최적화 권고를 실행하도록 만드는 일’을 가장 큰 과제로 꼽았습니다. 같은 분석에서 52%는 이 문제를 문화와 협업의 영역에서 풀고 있었습니다(FinOps Foundation, Encouraging Engineers to Take Action).
권고가 늦게 도착하기 때문입니다. 아키텍처가 굳고 배포가 끝난 다음에 오는 제안은, 받는 쪽에서 보면 끝난 일을 되돌리라는 요청입니다. 숫자를 보여주는 일과 그 숫자로 무엇을 정할지는 별개라는 점은 앞선 글에서도 짚었습니다.
설계 단계에서 정해지는 것들
FinOps Foundation은 2026년 프레임워크에서 기존 Architecting for Cloud 역량의 이름을 Architecting & Workload Placement로 바꾸고, 배포 전에 아키텍처 결정을 먼저 검토하라는 지침을 넣었습니다. 정의는 이렇습니다. “성능과 확장성, 운영 목표를 충족하면서 비용을 의식하고 효율적으로 솔루션을 설계하고 현대화하는 것.”
문서에는 이런 문장도 있습니다. “가치와 비용 효율은 시스템의 설계 안에 그것을 심을 때, 또는 시스템 수명에서 가능한 한 이른 시점에 가장 잘 달성됩니다.”(FinOps Foundation, Architecting & Workload Placement)
인스턴스 패밀리, 리전, 스토리지 등급, 관리형 서비스를 쓸지 직접 운영할지 — 이 선택들이 앞으로 몇 년치 청구서의 윤곽을 그립니다. 운영 단계에서 할 수 있는 일은 그 윤곽 안에서의 조정입니다.
Crawl에서 Walk로 넘어가는 자리
같은 문서는 이 역량의 성숙도를 세 단계로 나눠 둡니다.
- Crawl — 사례별로 그때그때 결정하고 기본 패턴을 따릅니다. 문서화된 트레이드오프 모델은 없습니다
- Walk — 비용, 가치, 주권, 복원력, 지속가능성에 가중치를 둔 모델이 문서로 존재합니다
- Run — 설계와 실제 구현을 비교해 추적하고, 패턴 라이브러리를 계속 다듬습니다
Crawl과 Walk 사이에 놓인 것은 문서 한 장입니다. 어떤 기준으로 무엇을 포기했는지가 적혀 있는 문서. 도구를 새로 들이기 전에 쓸 수 있는 것이기도 합니다.
앞의 배치 잡으로 돌아가 봅니다. 설계 리뷰 체크리스트에 ‘이 구성의 월 비용 추정’ 한 줄이 있었다면 두 달 뒤의 재배포 일정은 생기지 않았을 겁니다. 그 한 줄을 넣는 데 드는 것은 회의 시간 10분입니다.
자주 묻는 질문(FAQ)
Q. Shift Left FinOps는 엔지니어에게 비용 책임을 떠넘기는 것 아닙니까?
아닙니다. 엔지니어가 결정을 내리는 그 시점에 비용 정보가 함께 놓이게 하는 일입니다. FinOps Foundation도 클라우드 자원의 예상 비용이 설계와 개발 활동의 일부로 엔지니어에게 보이는 상태를 이상적이라고 적고 있습니다. 판단에 쓸 재료를 건네는 쪽입니다.
Q. 설계 단계에서는 사용량을 모르는데 비용을 어떻게 추정합니까?
정확한 금액을 맞히는 일이 아닙니다. 후보 구성 두세 개의 상대적인 크기를 견주는 정도면 충분합니다. 개발 환경 테스트로도 비용 변화의 이른 신호를 얻을 수 있다고 FinOps Foundation은 권합니다.
Q. 어디서부터 시작하면 됩니까?
사용자 스토리 템플릿이나 설계 리뷰 체크리스트에 ‘클라우드 비용 영향’ 항목을 한 줄 더하는 것이 가장 가벼운 출발점입니다. 비용을 최적화해야 할 경계 조건 중 하나로 다루는 습관이 여기서 생깁니다.
Q. 그러면 운영 단계의 최적화는 필요 없습니까?
필요합니다. 다만 설계에서 그어진 윤곽 안에서 움직입니다. 둘은 순서의 문제입니다.
