소프트웨어 팀의 경제학: 대부분의 엔지니어링 조직이 눈 감고 운전하는 이유

소프트웨어 팀의 진짜 비용

• 서유럽 기준 소프트웨어 엔지니어 1명의 연간 비용은 약 €130,000임 (급여 + 사회보험 + 연금 + 장비 + 관리 오버헤드 + 사무실 비용 전부 포함)
  • 8명 팀이면 연간 €104만, 월 €87,000, 영업일 하루당 약 €4,000
  • 대부분의 엔지니어는 이 숫자를 모름. 매니저도 마찬가지인 경우가 많음
• 이 숫자를 모르면 모든 우선순위 결정이 "감"으로 이루어짐
  • 유저 2%가 쓰는 기능에 3주를 투자하면? 그건 €60,000짜리 의사결정임
  • 분기 동안 운영 개선을 미룬다면? 매일 계산 가능한 비용이 쌓이는 중
  • 고객이 떠나서가 아니라 "기존 플랫폼이 부끄러워서" 리빌드하는 건, 자기 돈이었으면 절대 안 할 자본 배분임

플랫폼 팀의 손익분기점

• 내부 개발자 플랫폼을 만드는 8명 팀이 100명의 엔지니어를 서빙한다고 가정함
  • 팀 비용 월 €87,000. 이걸 정당화하려면 100명에게 합산 1,340시간/월을 절약해줘야 함
  • 엔지니어 1명 시급이 약 €65이니까, 엔지니어당 월 13.4시간, 주 약 3시간 절약이 손익분기선
• 주 3시간은 잘 만든 플랫폼이면 충분히 달성 가능한 수준임
  • 수동 배포 제거, 환경 셋업 시간 단축, 반복적인 설정 작업 자동화 등
• 그런데 손익분기(1x)는 진짜 기준이 아님

• 문제는 대부분의 플랫폼 팀이 이 숫자를 추적하지도, 빌드 우선순위에 반영하지도 않는다는 것
  • 로드맵은 엔지니어링 선호도 + 이해관계자 요청 + 분기별 플래닝으로 결정됨
  • 팀 존재의 재무적 근거는 검토되지 않은 채 방치됨

고객 대면 팀: 같은 수학, 다른 레버

• 고객 대면 프로덕트 팀도 같은 €87,000/월 비용 구조임. 레버만 다름
• 이탈률(Churn): 가장 직접적인 레버
  • 5만 유저, 월 2% 이탈이면 매달 1,000명 = MRR €50,000이 빠져나감
  • 이탈 원인을 찾아서 해결하면 그것만으로 손익분기의 대부분을 커버함
• 활성화(Activation): 과소평가되는 레버
  • 월 가입자 10,000명 중 활성화율 30%라면, 7,000명은 획득 비용만 날리는 셈
  • 활성화율을 30% → 35%로 5%p 올리면 추가 500명 전환 = 월 €25,000 추가 MRR
  • 이것만으로 손익분기의 약 29%를 달성함
• 전환율(Conversion): 작은 개선이 복리처럼 쌓임
  • 월 트라이얼 20,000건, 전환율 4% → 4.5%로 올리면 추가 100명 = 월 €5,000 추가 수익
• 핵심은 어떤 레버가 어떤 재무 결과에 얼마나 연결되는지 아는 것인데, 대부분의 팀은 이걸 모름

20년간의 재무적 눈가림

• 대부분의 팀이 재무 지표 대신 활동 지표(velocity, 티켓 수, 출시 기능 수)나 감성 지표(NPS, CSAT)를 추적함
  • 이건 재무 측정의 열화판이 아니라 아예 다른 카테고리임
  • 활동·감성 지표가 올라가는데 재무 성과는 악화되는 상황이 얼마든지 가능함
  • 기능을 더 많이 출시하면서 동시에 완전히 틀린 걸 만들 수 있음
• 왜 이렇게 됐는가? → 2002~2022년, 약 20년간의 거시경제 환경 때문
  • 2002~2011: 금리는 낮았지만 닷컴 버블·금융위기 여파로 위험 선호도는 억제됨. 아직 잔존하는 재무 규율이 있었음
  • 2011~2022: 제로금리 정상화 + 리스크 선호 과잉교정 + SaaS 투자 논리 결정화. 세 가지가 동시에 도래함
  • 11년이면 한 세대의 프로덕트·엔지니어링 리더 전체가 형성되기 충분한 시간
  • 이 세대는 팀이 재무적 리턴을 증명해야 하는 환경을 한 번도 경험하지 못했음
• 2022년 금리가 올라갔지만 행동은 자동으로 바뀌지 않았음. 애초에 행동이 재무 논리와 연결된 적이 없었기 때문

LLM이 바꾸는 게임

• 대규모 코드베이스 = 귀중한 자산이라는 전통적 관점이 흔들리고 있음
  • 코드베이스가 크면 유지보수 비용도 함께 커짐. 엔지니어를 추가할수록 조율 비용, 의존성, 의사결정 속도 저하가 발생
  • 자산과 부채가 동시에 존재하는데, 20년간 저금리가 부채 쪽을 가려왔음
• Nathan Cavaglione이라는 개발자가 LLM 에이전트를 써서 14일 만에 슬랙 핵심 기능의 ~95%를 복제함
  • 슬랙은 수천 명의 엔지니어가 10년 이상, 수십억 달러를 들여 만든 제품
  • 물론 엔터프라이즈 세일즈, 컴플라이언스, 데이터 보안 등은 포함 안 됨
  • 하지만 "규모와 축적된 복잡성 = 경쟁 해자"라는 전제는 더 이상 안전하지 않음
• "빠르게 만든 코드는 관리 불가능한 부채가 된다"는 반론도 있지만...
  • 사람이 유지보수할 때만 해당되는 이야기임
  • 에이전트-to-에이전트 세계에서는 지저분한 코드베이스에 에이전트 10개를 투입하는 게 팀을 꾸리는 것보다 싸고 빠름
  • 에이전트가 낯선 시스템을 파악하는 데 10일 걸려도, 여전히 대부분의 개발팀보다 빠르고 저렴함
• 결론: 팀의 존재 이유를 재무적으로 설명할 수 있는 조직이 구조적으로 앞서게 됨
  • build vs buy를 조직 선호가 아닌 실제 경제성으로 판단 가능
  • 충분한 리턴을 못 내는 팀을 식별 가능
  • 이런 습관을 먼저 만드는 조직이 복리로 이점을 축적함

---

기술 맥락

이 글의 핵심 프레임워크는 "엔지니어링 팀을 투자 단위로 보자"는 건데요, 특히 플랫폼 엔지니어링 쪽에서 중요한 시사점이 있어요. 내부 플랫폼 팀이 DevEx(개발자 경험) 개선을 명목으로 존재하지만, 실제로 시간 절약을 정량 측정하는 팀은 거의 없거든요. DORA 메트릭이나 SPACE 프레임워크가 있지만 이것도 재무 지표와는 거리가 있어요. LLM 에이전트가 코드 생성 비용을 급격히 낮추면서, 기존에 "인력 수 = 역량"이라는 등식이 깨지고 있는 상황이에요. 특히 한국 IT 업계에서도 "개발자 채용 규모 = 기술력"이라는 인식이 강한데, 이 글이 제시하는 재무적 프레임은 팀 규모 결정에 대한 관점을 바꿀 수 있는 좋은 출발점이에요.