AI 코딩 도구가 정말 개발 비용을 줄였을까 — CTS-SW 이해하기

TL;DR

• CTS-SW는 고객에게 전달한 소프트웨어 한 단위의 비용이다.
• 같은 팀에서 비용과 전달 단위의 정의를 유지해야 한다.
• 품질과 미완료 작업을 비용 지표 옆에서 함께 봐야 한다.

시작하며

AI 코딩 도구를 도입하면 코드 작성 시간, 자동완성 수락률, PR 수처럼 쉽게 수집할 수 있는 숫자부터 보게 된다. PR(Pull Request)은 코드 변경을 검토하고 합치기 위한 요청이다.

이 숫자들은 도구가 얼마나 쓰이고 코드가 얼마나 빨리 만들어지는지 보여준다. 하지만 고객에게 기능을 전달하는 비용이 실제로 줄었는지는 알려주지 않는다.

코드는 빨리 만들어졌는데 리뷰가 밀릴 수 있다. 자동 빌드와 테스트를 수행하는 CI가 느리거나 수동 배포가 남아 있으면, 생성에서 절약한 시간을 뒷단에서 다시 쓰게 된다.

이전 글에서는 토큰 가격보다 모델, 도구, 재시도와 사람의 검토까지 포함한 요구사항 실현 비용을 보는 편이 낫다고 이야기했다.¹ Amazon의 CTS-SW(Cost to Serve Software)는 소프트웨어 전달 과정의 비용을 살펴볼 수 있는 지표다.²

이 글에서는 CTS-SW를 어떻게 정의하고 읽을지 정리한다. 컨텍스트에 익숙해질 시간이 줄면서 생기는 인지부채와 리뷰 병목은 별도 글에서 다룬다.³

1. 고객에게 전달한 한 단위의 비용

CTS-SW의 기본 계산은 단순하다.

CTS-SW = 같은 기간 소프트웨어를 만들고 운영하는 비용
         / 그 기간 고객에게 전달한 소프트웨어 단위 수

Amazon은 소프트웨어 개발의 활동마다 비용을 세밀하게 나누기보다, 투입한 비용과 고객에게 전달한 산출물을 먼저 연결한다. 그다음 어떤 도구와 개발 방식이 비용 변화와 관계가 있는지 찾는다.²

비용을 정확히 구하기 어렵다면 개발자 수와 투입 기간을 대리 지표로 사용할 수 있다. 다만 이 경우 결과는 금액이 아니라 개발자의 시간으로 표현해야 한다.

예를 들어 개발자 8명이 한 주 동안 고객에게 도달한 배포를 16회 만들었다고 해보자. 이는 계산을 설명하기 위한 가상의 예시다.

8 개발자-주 / 16회 = 배포당 0.5 개발자-주
8 개발자-주 / 20회 = 배포당 0.4 개발자-주

같은 인원과 기간에 배포를 20회 완료했다면 배포당 투입량이 20% 줄어든다. 여기서 개발자-주는 개발자 한 명이 한 주 동안 쓴 시간을 뜻한다.

도구 사용료까지 포함한 금액 지표가 필요하다면 인건비, 도구·모델 비용과 운영 비용을 같은 화폐 단위로 모아야 한다. 개발자-주에 토큰 요금을 그대로 더할 수는 없다.

AI 도구를 평가할 때는 계약, 테스트와 개발 도구를 정비하는 하네스 작업도 비용 범위 안에 남겨야 한다. 이 작업을 제외하면 도입 비용을 작게 보이게 만들 수 있다.

2. 무엇을 한 단위로 셀지 먼저 정한다

계산보다 어려운 것은 소프트웨어 한 단위의 정의다.

Amazon은 서비스 지향 아키텍처에서는 배포를 사용할 수 있고, 큰 애플리케이션을 한 번에 배포하는 구조에서는 고객에게 전달된 코드 변경을 단위로 삼을 수 있다고 설명한다.² 저장소에 병합됐지만 고객에게 전달되지 않은 PR을 같은 의미로 세면 안 된다.

따라서 측정을 시작할 때 아래 내용을 합의해야 한다.

한 배포에 기능 열 개가 들어갈 수도 있고, 설정 하나만 바뀔 수도 있다. 배포 횟수는 고객 가치의 크기를 직접 나타내지 않는다.

그래서 CTS-SW는 매출이나 고객 만족과 별개인 전달 비용 지표로 쓰는 편이 맞다고 생각한다. 숫자가 낮아졌다고 고객에게 더 가치 있는 제품을 만들었다고 결론 내릴 수는 없다.

단위를 작게 나누는 방식이 바뀌었다면 전후 비교에도 표시해야 한다. 같은 기능을 네 번에 나눠 배포했다는 이유만으로 비용 효율이 네 배 좋아진 것은 아니다.

3. 비용을 읽을 때 함께 볼 지표

Amazon은 CTS-SW를 단독으로 쓰지 않고 보안·복원력 같은 품질 지표와 함께 본다. 비용을 낮추는 동안 다른 중요한 성질이 나빠지지 않는지 확인하는 지표를 tension metric이라고 부른다.⁴

나는 여기에 시작했지만 고객에게 전달하지 못한 작업도 함께 보고 싶다. 앞으로 쓸 미완료 작업 지표는 CTS-SW의 공식 계산 항목이 아니라, 비용 변화의 배경을 살피기 위한 제안이다.

예를 들어 같은 정의로 측정한 CTS-SW가 낮아졌는데 리뷰 대기열과 오래된 작업이 늘었다면, 당장 전달한 단위의 비용은 개선됐어도 앞으로의 전달이 원활할지는 더 확인해야 한다.

그렇다고 대기열 증가만으로 미래 비용 상승이나 인지부채를 확정할 수는 없다. 일시적인 대형 작업, 휴가, 외부 승인 대기처럼 다른 이유도 있을 수 있다. 어떤 일이 어디에서 얼마나 기다리는지 찾아볼 신호로 사용하는 편이 낫다.

반대로 필요한 이해를 미룬 채 승인하면 리뷰 대기열은 줄어도 팀의 이해에는 빈칸이 남을 수 있다. 승인 건수가 늘었다는 사실을 고객에게 전달한 완료량의 증가와 구분하고, 중요한 변경의 동작·실패 조건을 설명할 수 있는지와 후속 재작업도 함께 확인해야 한다.³

미완료 작업에 이미 쓴 인건비와 모델 비용은 합의한 기간 비용에 포함된다. 여기에 임의의 ‘재고 벌점’을 더하면 같은 비용을 두 번 셀 수 있다. CTS-SW 계산은 유지하고, 미완료 작업과 품질을 옆에 놓고 해석한다.

또 이번 달 비용에는 다음 달에 전달할 작업이 포함되고, 이번 달 산출물에는 지난달에 시작한 작업이 포함될 수 있다. 이 때문에 한 주의 증감만으로 효과를 판정하기보다 여러 기간의 추세를 함께 보는 편이 낫다.

4. 지표를 개인의 실적 목표로 만들지 않는다

배포 횟수를 평가 기준으로 삼으면 의미 없는 배포를 늘릴 수 있다. 리뷰 완료 건수를 목표로 주면 충분히 이해하지 않은 채 승인할 유인도 생긴다.

DORA는 전달 지표를 목표나 팀 간 경쟁에 사용하면 수치를 맞추는 행동이 나타날 수 있다고 설명한다.⁵ SPACE도 개발 생산성을 하나의 활동량으로 환원하지 말아야 한다고 제안한다.⁶

CTS-SW 역시 같은 팀의 변화와 그 이유를 찾는 데 쓰는 편이 적절하다. 서로 다른 제품, 운영 책임과 소프트웨어 단위를 가진 팀의 순위를 매기면 비교 기준부터 달라진다.

개인별 점수로 나누기도 어렵다. 한 사람이 코드를 빨리 만들어도 팀의 테스트 환경, 검토 방식과 배포 권한이 고객에게 전달되는 시점을 바꾼다. 비용 변화의 원인을 찾기 전에 특정 구성원의 성과로 돌려서는 안 된다.

내가 도입한다면 측정 목적과 함께 개인 평가·팀 서열·인원 감축 근거로 사용하지 않는다는 범위도 먼저 합의하고 싶다.

5. 한 팀에서 같은 기준으로 시작하기

처음부터 정교한 원가 모델을 만들기보다 한 팀에서 전달 단위, 비용 범위, 품질 기준을 정한다. 제품 담당자는 고객에게 도달한 결과를 정의하고, 개발·운영 담당자는 비용과 장애 기록을 연결할 수 있다.

그다음 최근 몇 주의 기준선을 만들고, 숫자가 팀의 경험과 대체로 맞는지 본다. 단위 정의나 팀 구성이 바뀌면 기록을 남기고 비교 가능한 구간을 구분한다.

도구를 도입하거나 병목 하나를 개선한 뒤에는 비용뿐 아니라 완료량, 미완료 작업과 품질이 함께 어떻게 바뀌었는지 확인한다. 여러 변화가 동시에 있었다면 어느 하나의 효과로 단정하지 않는다.

리뷰 대기열이 늘었다면 다음 질문은 ‘더 빨리 승인할 수 있는가’에서 끝나지 않는다. 왜 기다리는지 진단하고, 사람이 판단할 범위를 줄이거나 검증을 개선할 작업을 정해야 한다. 이해 비용과 자동화 비율을 바꿔 리뷰 병목을 줄이는 방법은 별도 글에 정리했다.³

마치며

CTS-SW를 쓰는 이유는 AI가 코드를 얼마나 만들었는지에서 한 걸음 더 나아가, 고객에게 전달한 결과에 얼마를 썼는지 확인하기 위해서다.

같은 비용과 단위 정의를 유지하면서 품질, 미완료 작업과 고객 가치를 함께 보면 숫자가 좋아진 이유를 더 잘 설명할 수 있다. 나는 이 지표를 한 팀의 개선 방향을 찾는 출발점으로 쓰고 싶다.

• #ai
• #engineering-productivity
• #cts-sw
• #developer-experience
• #organization