5.4 엔지니어링의 비용과 단위 경제성

개요 및 동기

이 주제는 5부를 명시적으로 재무적으로 돌린다: 재무 이해관계자가 직접 사용할 수 있는 용어로 엔지니어링 비용을 표현하는 방법, 그리고 불투명하고 집계된 부서 예산 항목이 아니라 산출물이나 사용의 의미 있는 단위당 표현되는 비용인 단위 경제성을 구축하는 방법. 엔지니어링 비용은 보통 소프트웨어 주도 조직에서 가장 큰 통제 가능한 지출 항목이지만, 그것을 이끄는 것이나 그것이 성장과 함께 어떻게 확장되는지에 대한 가시성이 거의 없이 단일한 큰 수치로 보고되어, 흔히 재무 기능에 의해 가장 잘 이해되지 않는다. 이 주제는 그 간극을 메우기 위해 존재하는데, “이 시스템을 운영하는 데 우리에게 비용이 얼마나 드는가”나 “우리가 성장함에 따라 우리의 비용은 어떻게 확장되는가”에 구체적인 재무 용어로 답할 수 없는 엔지니어링 리더는 모든 예산 대화에서 실제 불리한 위치에 있기 때문이다.

이 주제가 권장하는 구체적인 규율인 단위 경제성은 총 인원 비용이나 총 클라우드 지출로서만이 아니라, 배포당, 서비스된 고객당, 처리된 거래당, 혹은 비즈니스에 실제로 중요한 다른 단위당 비용을 표현하는 것을 의미한다. 이 재구성은 주제 1.3의 산출물보다 결과 원칙에 직접 연결된다: 하락하는 총비용 수치는 더 적은 고객을 섬기는 것에서 온다면 자동으로 좋은 것이 아니며, 상승하는 총비용 수치는 비례적으로 훨씬 더 많은 고객을 섬기는 것에서 온다면 자동으로 나쁜 것이 아니다. 단위 경제성은 비용 추세를 단지 눈에 보이게 만드는 것이 아니라 해석 가능하게 만드는 것이다.

대규모 팀에게 이 주제의 규율은 엔지니어링 재무를 블랙박스에서 읽기 쉽고 관리 가능한 시스템으로 바꾼다. 엔터프라이즈 조직은 단위 경제성을 사용해 다른 제품, 플랫폼, 혹은 팀의 비용 효율성을 공정한 기준으로 비교한다. 정부 조직은 같은 규율을 사용해 재정 책임을 입증하고 시간이 지남에 따라 시민당 비용을 줄일 인프라 투자에 대한 증거 기반 사례를 만든다.

핵심 원칙

총비용 홀로는 분모 없이는 해석할 수 없다. 의미 있는 단위당 비용인 단위 경제성은 불투명한 수치를 실행 가능한 추세로 바꾼다.
임의적이거나 쉽게 게임당하는 분모가 아니라 진정한 비즈니스나 임무 가치를 반영하는 단위를 선택하라.
비용은 여러 구성 요소를 가진다: 인원, 인프라, 도구. 각각 다른 비용 동인과 다른 지렛대를 가지므로 그것들을 별도로 추적하라.
FinOps 관행은 이 책이 전달과 품질 메트릭에 가져오는 것과 동일한 엄격함을 클라우드 비용에 가져온다. 비용을 피할 수 없고 불투명한 주어진 것이 아니라 측정 가능하고 관리 가능한 것으로 취급하라.
하락하는 총비용이 자동으로 좋은 것은 아니며, 상승하는 것이 자동으로 나쁜 것은 아니다, 같은 시기에 단위 측정치에 무슨 일이 일어났는지 확인하지 않고서는.

권장 사항

임의적인 분모가 아니라 실제로 전달된 가치를 반영하는 단위를 선택하라

당신의 단위 경제성 계산을 위해 진정으로 비즈니스나 임무 가치를 추적하는 단위를 선택하라: 서비스된 고객당 비용, 처리된 거래당 비용, 배포당 비용, 혹은 공공 부문 서비스에 대해 처리된 시민 상호작용당 비용. 전달된 가치의 어떤 진정한 외부 단위에도 상응하지 않는, 내부적이고 대체로 재량적인 개수 같은, 그 비율을 치장하기 위해 너무 쉽게 부풀려질 수 있는 분모를 피하라.

인원, 인프라, 도구 비용을 분리하라

엔지니어링 비용은 적어도 세 개의 서로 다른 동인과 서로 다른 지렛대를 가진 구별되는 구성 요소를 가진다: 인원 비용(급여, 복리후생, 단기적으로 대체로 고정됨), 인프라 비용(클라우드 지출, 사용량에 따라 대체로 가변적이고 엔지니어링 관행을 통해 직접 최적화 가능함), 그리고 도구 및 라이선스 비용(흔히 좌석당이나 사용 등급당 고정 비용). 진정한 성장과 함께 확장되는 인프라에 의해 이끌리는 상승하는 총비용은 관리되지 않는 도구 확산에 의해 이끌리는 같은 총 상승과 매우 다른 대응이 필요하므로, 이것들을 하나의 섞인 총액이 아니라 별도로 추적하라.

특별히 클라우드 인프라 비용에 FinOps 규율을 적용하라

FinOps는 엔지니어링, 재무, 비즈니스 팀 사이의 기능 간 협업을 통해 가변적인 클라우드 지출에 재무적 책임을 가져오는 규율이다. 그 핵심 관행을 직접 적용하라: 비용 귀속을 위해 팀과 서비스별로 클라우드 자원에 태그를 달고, 정기적인 주기로 예산에 비추어 지출을 검토하며, 인프라 비용 효율성(실제 사용 단위당 비용)을 단순히 받아들일 피할 수 없고 고정된 오버헤드가 아니라 의도적으로 최적화할 가치가 있는 엔지니어링 메트릭으로 취급하라.

시간에 따른 단위 비용 추세를 추적하고 움직임을 명시적으로 조사하라

단일한 단위 비용 스냅샷은 그 추세보다 덜 유용하다: 플랫폼이 성숙하고 확장됨에 따라 서비스된 고객당 비용이 떨어지고 있는가(진정한 효율성 이득의 신호), 아니면 오르고 있는가(축적되는 비효율성, 더 높은 유지보수 비용을 이끄는 기술 부채, 혹은 더 자원 집약적인 세그먼트 쪽으로의 서비스되는 고객 혼합 변화의 신호). 설명 없이 수치를 보고하는 대신 상당한 단위 비용 추세 변화를 명시적으로 조사하라.

비용 데이터를 이 책의 다른 곳에 있는 기술 부채와 품질 메트릭에 연결하라

단위당 상승하는 인프라나 유지보수 비용은 때때로 축적된 기술 부채(주제 4.5)나 복잡도 핫스팟의 확산(주제 4.1, 주제 4.3)의 직접적이고 측정 가능한 결과다: 비효율적인 코드 경로, 중복된 인프라, 잘 최적화되지 않은 쿼리는 모두 결국 상승된 단위 비용으로 나타난다. 상승하는 단위 비용을 4부의 처닝 및 복잡도 신호와 함께 당신의 부채 우선순위 지정 논의에 대한 하나의 입력으로 사용하라. 입증되고 측정 가능한 비용 영향을 가진 부채 항목은 정량화되지 않은 품질 불만 홀로보다 개선 투자에 대한 더 강한 사례를 만들기 때문이다.

트레이드오프: 장단점

접근법	장점	단점
총비용만 보고하기	단순하고, 예산이 전형적으로 배분되는 방식과 일치함	분모 없이는 해석할 수 없음; 효율성 추세를 숨김
잘 선택된 분모를 가진 단위 경제성	해석 가능하고, 실행 가능하며, 시간과 팀에 걸쳐 비교 가능함	진정으로 의미 있고 게임하기 어려운 단위를 선택하는 데 주의가 필요함
섞인 비용 보고 (인원, 인프라, 도구 결합)	단순한 단일 수치	어떤 특정 비용 동인이 실제로 변하고 있는지와 왜인지를 흐림
분리된 비용 구성 요소	주어진 비용 추세에 대해 당길 올바른 지렛대를 드러냄	더 상세한 비용 귀속과 추적 인프라가 필요함

핵심 긴장은 단순성 대 실행 가능성이다. 단일한 총비용 수치는 보고하기 쉽고 많은 조직이 이미 예산을 배분하는 방식과 일치하지만, 그것은 무엇이 비용 변화를 이끌고 있는지와 그 변화가 진정한 효율성을 반영하는지 진정한 성장을 반영하는지 둘 다를 흐린다. 이 주제가 권장하는 다소 더 복잡한 단위 경제성과 구성 요소로 분리된 보고에 투자함으로써 이 긴장을 해결하라. 비용이 움직일 때 정확히 어떤 지렛대를 당겨야 할지 아는 결과적인 실행 가능성은, 가장 작은 규모를 넘어선 어떤 조직에게도 적당한 추가 추적 노력의 가치가 있기 때문이다.

팀과 논의할 질문

우리는 엔지니어링 비용을 의미 있는 단위(고객, 거래, 배포)당 추적하는가, 아니면 불투명한 총액으로만 추적하는가? 총액만 존재한다면, 무엇이 당신의 비용 추세를 진정으로 해석 가능하게 만들지 식별하고 그것을 추적하기 시작하려면 무엇이 필요할지 논의하라.
우리는 현재 비용을 인원, 인프라, 도구 구성 요소로 분리할 수 있으며, 우리는 무엇이 최근의 변화를 이끌고 있는지 아는가? 당신의 실제 비용 분석이 존재한다면 그것을 가져와 그것이 자신 있게 이 질문에 답할 만큼 충분히 상세한지 확인하라.
우리는 우리의 클라우드 인프라 비용에 FinOps 태깅과 귀속 관행을 적용했는가, 아니면 그것은 단일하고 귀속되지 않은 항목인가? 지출이 특정 팀이나 서비스에 귀속될 수 없다면, 진정한 귀속을 향한 첫 단계가 어떻게 보일지 논의하라.
우리의 단위 비용 추세는 최근에 어느 방향으로든 상당히 움직였으며, 우리는 왜인지 아는가? 실제이고 최근의 움직임이 있다면 그것을 조사하고 당신이 그것을 자신 있게 설명할 수 있는지, 아니면 그것이 미스터리로 남아 있는지 확인하라.
우리의 현재 인프라 비용 추세는 4부의 기술 부채나 복잡도 핫스팟 신호 중 어느 것과 상관관계가 있는가? 이 데이터 출처를 명시적으로 교차 참조하고 부채 개선 비즈니스 사례를 강화할 수 있는 연결이 나타나는지 확인하라.
내일 재무 이해관계자가 “우리에게 고객 한 명을 더 섬기는 데 비용이 얼마나 드는가”라고 묻는다면, 우리는 자신 있게 답할 수 있을까? 이 구체적이고 실용적인 질문은 당신의 단위 경제성이 실제로 구축되고 준비되었는지, 아니면 단순히 이론적인 열망인지 시험한다.

분야별 관점

스타트업. 단위 경제성은 이르게 엄청나게 중요한데, 투자자와 창업자 모두 추가 고객 한 명을 섬기는 비용이 지속 가능성 쪽으로 추세를 보이는지 아니면 확장할 수 없는 비즈니스 모델 쪽으로 추세를 보이는지 알아야 하기 때문이다. 공식적인 FinOps 도구를 정당화할 만큼 회사가 충분히 커질 때까지 기다리는 대신, 거친 추정치로라도 아주 일찍부터 이것을 추적하라.

중소기업. 클라우드 제공업체 청구 대시보드는 보통 전용 FinOps 도구 없이도 충분한 기본 비용 가시성을 제공한다. 주된 규율은 고립된 상태에서 총 청구서만 보는 대신 합리적인 단위(고객당 비용이나 거래당 비용)를 선택하고 주기적으로 추세를 확인하는 것이다.

엔터프라이즈. FinOps 관행과 분리된 비용 구성 요소 추적은 이 규모에서 필수적인데, 클라우드 지출이 많은 팀에 걸쳐 퍼진 매우 크고 흔히 충분히 정밀 조사되지 않는 예산 항목을 나타낼 수 있기 때문이다. 적절한 비용 귀속 태깅과 전용 비용 검토 주기에 투자하고, 단위 경제성을 사용해 다른 제품 라인이나 플랫폼에 걸쳐 비용 효율성을 공정하게 비교하라.

정부. 재정 책임과 입증 가능한 비용 효율성은 예산 정당화와 공공 책임성에 직접 관련된다. 시민당 비용이나 처리된 거래당 비용으로 표현된 단위 경제성은 흔히 원시 총 지출 수치보다 예산 위원회에게 훨씬 더 설득력 있고 해석 가능한 메트릭이며, 시간이 지남에 따라 단위당 비용을 줄이는 인프라 투자에 대한 비즈니스 사례를 직접 뒷받침한다.

사례

엔터프라이즈. 한 서비스형 소프트웨어 회사의 재무 팀은 여러 연속된 분기 동안 상승하는 총 클라우드 인프라 지출에 경각심을 느꼈고, 처음에는 비효율성이나 낭비를 가정했다. 단위 경제성 분석, 즉 활성 고객당 비용은 고객 수가 인프라 비용보다 더 빠르게 성장하고 있었기 때문에 총 지출이 올랐음에도 단위 비용이 실제로 꾸준히 떨어지고 있었다는 것을 보여 주었으며, 이는 총 지출만 보는 것에 의해 가려진 진정한 효율성 개선이었다. 이 재구성은 재무 대화를 “엔지니어링이 왜 더 많이 지출하고 있는가”에서 “우리는 어떻게 이 효율적인 확장을 지속하는가”로 바꾸었으며, 이는 진정으로 건강한 성장 주도 지출을 겨냥했을 불필요하고 잠재적으로 해로운 비용 삭감 명령을 피한, 물질적으로 더 생산적인 논의였다.

정부. 한 주 정부의 디지털 서비스 기관은 그것이 대체하고 있는 레거시 온프레미스 시스템에 맞서 비용을 비교하는 예산 위원회에 지속적인 클라우드 인프라 투자를 정당화하라는 요청을 받았다. 단위 경제성 분석, 즉 처리된 시민 거래당 비용은, 새로운 시스템이 같거나 더 낮은 총 인프라 예산으로 훨씬 더 높은 거래량을 처리했기 때문에, 더 높은 명목 총 지출에도 불구하고 새로운 클라우드 기반 시스템의 단위 비용이 레거시 시스템의 것보다 상당히 더 낮았다는 것을 보여 주었다. 이 단위 비용 비교는, 해석하기 더 어려운 총 지출 비교가 아니라, 지속적이고 확장된 클라우드 투자를 위한 성공적인 사례의 중심 증거가 되었다.

비즈니스 사례: 동기, ROI, TCO

엄격한 단위 경제성의 수익은 모든 재무 이해관계자가 결국 묻는 질문에 대한 방어 가능하고 해석 가능한 답이다: 이 지출은 효율적인가, 그리고 그것은 지속 가능하게 확장되고 있는가. 위의 엔터프라이즈 사례는 이것을 잘못했을 때의 위험을 보여 준다: 총 지출만 본 관점은 단위 기준으로 덜이 아니라 더 효율적이 되고 있던 지출에 대해 불필요하고 역효과를 낳는 비용 삭감 명령을 촉발할 뻔했다.

총 소유 비용은 비용 귀속 도구(FinOps 태깅 관행)와 비용 구성 요소를 분리하고 시간에 따른 단위 추세를 추적하는 분석 규율을 포함한다. 그 투자는 정보가 부족한 총비용 관점 홀로에 근거해 중요한 예산 결정을 내리는 위험, 즉 실제로 효율적이었던 지출을 삭감하거나 진정으로 비효율적이 되고 있던 지출을 잡아내지 못하는 위험에 비하면 미미하다.

안티패턴과 함정

분모 없이 총비용 보고하기: 해석할 수 없고 비용이 효율적으로 확장되고 있는지 비효율적으로 확장되고 있는지 숨긴다.
비용 계산을 위해 쉽게 게임당하거나 임의적인 단위 선택하기: 정보를 주기보다 치장하는 비율을 만들어 낸다.
인원, 인프라, 도구 비용을 하나의 수치로 섞기: 어떤 특정 동인이 실제로 변하고 있고 어떤 지렛대가 그것을 다루는지 흐린다.
클라우드 비용 귀속(FinOps 태깅) 없음: 팀이나 서비스 수준에서 인프라 지출을 사실상 관리되지 않고 책임질 수 없는 상태로 남긴다.
단위 추세를 확인하지 않고 총비용 변화에 반응하기: 진정으로 효율적이고 성장 주도적인 지출에 대해 불필요한 비용 삭감 명령을 촉발할 수 있다.
비용 추세를 기술 부채나 복잡도 데이터에 결코 연결하지 않기: 부채 개선 투자에 대한 정량화되고 강화된 사례를 놓친다.

성숙도 모델

1단계, 시작: 엔지니어링 비용이 단위 경제성이나 구성 요소 분리 없이 오직 불투명한 총액으로만 보고된다.
2단계, 개발: 일부 비용 분석이 존재하지만, 단위 경제성이 일관성이 없고 클라우드 비용 귀속이 대체로 부재하다.
3단계, 표준화: 잘 선택된 분모를 가진 단위 경제성이 일관되게 추적되며, 비용은 조직 전체에서 인원, 인프라, 도구 구성 요소로 분리된다.
4단계, 관리: FinOps 귀속과 검토 관행이 확립되며, 단위 비용 추세가 능동적으로 조사되고 기술 부채 및 품질 신호에 연결된다.
5단계, 조율: 조직은 재무 이해관계자로부터의 상세한 단위 비용 질문에 자신 있게 답할 수 있으며, 비용 데이터가 최고 수준에서 엔지니어링 투자 결정과 예산 정당화 둘 다를 직접 알려준다.

논의를 위한 아이디어

어떤 단위가 우리의 비용 추세를 진정으로 해석 가능하게 만들 것이며, 우리는 그것을 추적하는가?
최근의 비용 변화를 그 인원, 인프라, 도구 구성 요소로 분리할 수 있을까?
우리의 인프라 지출 중 어느 부분이든 현재 특정 팀이나 서비스에 귀속되지 않는가?
우리의 단위 비용 추세는 최근에 움직였으며, 우리는 왜인지 아는가?
상승하는 단위 비용이 다뤄지지 않은 기술 부채의 증상일 수 있는 곳은 어디인가?

핵심 요약

의미 있는 가치 단위당 비용인 단위 경제성은 불투명한 총비용 수치를 해석 가능하고 실행 가능한 추세로 바꾼다.
진정한 비즈니스나 임무 가치를 반영하는 단위를 선택하고, 쉽게 게임당하거나 임의적인 분모를 피하라.
각각 다른 동인과 다른 지렛대를 가지므로 비용을 인원, 인프라, 도구 구성 요소로 분리하라.
귀속 태깅과 정기적인 검토를 포함해 특별히 클라우드 인프라 비용에 FinOps 규율을 적용하라.
그와 함께 단위 추세를 확인하지 않고서는, 하락하는 총비용은 자동으로 좋은 것이 아니며, 상승하는 것은 자동으로 나쁜 것이 아니다.

참고 문헌 및 추가 자료

Storment, J.R., and Mike Fuller. Cloud FinOps: Collaborative, Real-Time Cloud Financial Management. O’Reilly Media, 2020.
Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Beyer, Betsy, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016.
FinOps Foundation. FinOps Framework. finops.org.