공수 산정 (3) AI 가속을 견적에 반영하는 법 — 암달의 법칙이 정한 공수의 바닥

"AI로 개발하면 빠르잖아요."

견적을 내기 전부터 이 반박을 먼저 예상했습니다. 누가 실제로 꺼낸 게 아니라, 제가 머릿속으로 미리 떠올린 질문입니다. 그리고 저는 이 반박이 틀렸다고 생각하지 않습니다. 실제로 빨라지는 작업이 있으니까요. 문제는 그 다음입니다 — 그래서 이걸 견적에 어떻게 반영해야 하는가. 전체 공수에 곱하기 0.7을 하면 되는 걸까요.

어떤 외주 건의 개발 문서를 검토하면서 이 질문을 정면으로 마주하게 됐습니다. 발주처가 만든 문서 세트가 꽤 정교해서 — 기능마다 검증 가능한 수용 기준이 붙어 있고 선행 의존성이 표로 정리돼 있었습니다 — 추정이 아니라 문서의 요구사항에 1:1로 대응하는 계산이 가능했습니다. 덕분에 "AI 가속을 어디에 얼마나 반영할 것인가"도 감이 아니라 항목 단위로 따질 수 있었습니다. (기획 문서의 종류와 체계는 전에 따로 정리한 적이 있습니다.)

결론부터 적자면 일괄 계수는 답이 아니었습니다. 그리고 그 대신 찾은 방법은 예상보다 훨씬 강한 논증을 만들어 줬습니다.

먼저 — 표준은 AI를 전제하지 않습니다

공수 산정의 근거로 쓰는 공개 표준부터 확인했습니다. 「소프트웨어사업 대가산정 가이드」의 단가도, 소프트웨어진흥법 제46조 제4항에 근거해 공표되는 SW기술자 평균임금도, 「소프트웨어사업 계약 및 관리감독에 관한 지침」 [별표1]의 생산성 상수도 — 전부 AI 가속 계수를 두고 있지 않습니다.

2024년 개정에서 'AI 도입사업 대가산정'이 추가되긴 했습니다. 다만 이건 AI 솔루션을 도입하는 비용을 어떻게 셀 것인가에 대한 항목이지, 개발 생산성이 올랐으니 공수를 깎으라는 할인 규정이 아닙니다. 이름이 비슷해서 오해하기 쉬운 부분입니다.

이 사실이 중요한 이유는 이렇습니다. 표준 산식으로 공수를 뽑으면 그 숫자에는 애초에 AI 가속이 반영돼 있지 않습니다. 그러면 "AI 무전제로 계산했다"는 것은 부풀리기가 아니라 산업 표준과의 정합성입니다. 방어가 아니라 사실 진술이라는 뜻입니다.

다만 이걸로 대화가 끝나지는 않습니다. "표준에 없어서요"는 정확하지만 상대를 납득시키지는 못합니다. 상대가 묻고 있는 건 표준이 뭐라고 하느냐가 아니라 실제로 얼마나 빨라지느냐이기 때문입니다. 그래서 한 걸음 더 들어가야 했습니다.

그래서 압축 등급으로 쪼갰습니다

전체 공수에 일괄 계수를 곱하는 대신, 작업 항목마다 AI 압축 가능성 등급을 매겼습니다. 같은 프로젝트 안에서도 AI가 줄여주는 정도가 항목별로 완전히 다르다는 것이 출발점이었습니다.

표를 보기 전에 전제를 하나 못 박아 두겠습니다. 아래 시간은 시니어 개발자 한 명이 Claude Code를 쓰면서 MVP 범위를 구현할 때의 공수이고, 합계는 1,045시간입니다.

등급	성격	예	시간
high	실제로 크게 줄어듦	화면 기본 틀, 단순 등록·조회, 테스트 스캐폴딩	325시간
medium	부분적으로 줄어듦	데이터 모델 배선, 게이트 증빙 산출	302시간
low	거의 안 줄어듦	커넥터 안정화, 다국어 개체 인식·감성분석	378시간
none	전혀 안 줄어듦	실사용 검증, 발주처 커뮤니케이션	40시간

이렇게 나눠 놓고 나서 가장 먼저 눈에 띈 것은 high가 전체의 다수가 아니라는 사실이었습니다. 체감으로는 "요즘은 AI가 거의 다 해주는데"에 가까웠는데, 항목별로 갈라 놓고 합을 내 보니 크게 줄어드는 구간은 3분의 1이 채 안 됐습니다. 감과 계산이 어긋난 지점이었습니다.

이 1,045시간은 앞 편의 9,216 인시와 같은 자로 잰 값이 아닙니다

여기서 숫자 하나를 미리 정리해 두는 게 좋겠습니다. 앞 편에서 같은 MVP를 9,216 인시로 적었습니다. 8.8배 차이입니다. 같은 기능 목록인데 재는 자가 다르기 때문입니다. 그쪽은 AI를 전제하지 않고 공표된 표준 생산성을 그대로 쓴 값입니다. 표준 산식은 애초에 인력 등급을 입력 변수로 받지도 않습니다. 반면 이쪽은 시니어 한 명이 AI를 쓰는 값입니다. 대상 국가 범위도 다릅니다.

이 8.8배를 전부 AI 효과라고 말하면 거짓말이 됩니다. AI 전제, 시니어 개인이냐 블렌디드 표준 팀 생산성이냐, 국가 범위가 한꺼번에 다르니 어느 몫이 AI인지 이 두 숫자만으로는 가를 수 없습니다. 제가 굳이 둘을 나란히 두는 이유는 다른 데 있습니다. 전제를 안 밝히면 같은 범위가 8.8배로 벌어집니다. 그러니 견적을 받았을 때 숫자보다 먼저 물어야 하는 게 있다는 뜻입니다. "AI를 전제하고 세셨습니까?"

이 분해가 만드는 논증

이 1,045시간은 이미 Claude Code를 쓰는 것을 전제한 값입니다. 그런데도 여기서 한 걸음 더 양보하겠습니다. 모델이 앞으로 더 좋아져서 high(325시간)와 medium(302시간)을 합한 627시간을 아예 0으로 만들어 준다고 가정하겠습니다. 실제로는 불가능한 낙관이지만, 그렇게 쳐도 좋습니다.

그래도 low(378시간)와 none(40시간)을 합한 418시간이 남습니다.

이건 제가 만든 논법이 아니라 암달의 법칙입니다

이 계산에는 이미 이름이 붙어 있습니다. 암달의 법칙(Amdahl's Law)입니다. 진 암달이 1967년에 병렬 처리를 두고 정리한 것으로, 시스템의 일부만 빨라질 때 전체 향상에는 천장이 있다는 관찰입니다. 가속되는 비율을 p라 하면, 그 부분을 아무리 무한히 빠르게 만들어도 전체 속도 향상은 1/(1−p)를 넘지 못합니다. 못 줄이는 부분이 바닥을 만들기 때문입니다.

원래는 프로세서를 늘리는 이야기였습니다만, 이 논리는 가속이 어디서 오는지를 가리지 않습니다. 프로세서든 AI든 "일부만 빨라진다"는 조건이 같으면 같은 천장이 생깁니다. 위 표를 그대로 대입하면 이렇게 됩니다.

가속 가능 비율  p = 627 ÷ 1,045 = 0.60
최대 속도 향상     = 1 ÷ (1 − 0.60) = 2.5배
공수의 바닥        = 1,045 × (1 − 0.60) = 418시간

모델이 앞으로 얼마나 더 좋아지든 이 범위의 공수는 2.5배 이상 줄지 않고, 418시간 아래로 내려가지 않습니다. 더 좋은 모델이 나오면 627시간이 더 빨리 0에 수렴할 뿐, 418시간은 그 자리에 그대로 있습니다.

이름을 붙이고 나니 이 논증의 성격이 분명해졌습니다. 이건 제가 AI를 낮게 평가해서 나온 숫자가 아닙니다. p를 1.0으로 잡지 않는 한 반드시 나오는 산술입니다. 그러니 반박하려면 저를 반박할 게 아니라 p를 올려야 하고, p를 올리려면 low·none으로 분류한 항목이 사실은 압축 가능하다는 것을 항목 단위로 보여야 합니다. 그건 할 수 있는 논쟁이고, 제가 원한 논쟁이기도 합니다.

그래서 프레임이 바뀝니다

이게 일괄 30% 할인보다 훨씬 강합니다. 왜 강한지 곰곰이 생각해보니 숫자가 커서가 아니라 프레임이 바뀌기 때문이었습니다.

일괄 30% 할인은 "30%가 맞느냐"는 협상을 엽니다. 상대는 40%를 부르고 저는 20%를 부르고, 양쪽 다 근거가 없으니 결국 목소리 큰 쪽이 이깁니다. 반면 압축 등급 분해는 "AI를 최대로 인정해도"라는 프레임이 됩니다. 상대가 꺼낼 카드를 제가 먼저 꺼내서, 그 카드를 최대치로 인정한 뒤에도 남는 것을 보여주는 구조입니다.

인정할 수 있는 것을 먼저 인정하면 논쟁이 그만큼 줄어듭니다. 남는 건 "그럼 이 418시간은 왜 안 줄어드느냐" 하나뿐이고, 그건 답할 수 있는 질문입니다.

왜 low와 none은 줄어들지 않는가

세 가지 구조적인 이유가 있었습니다. 그리고 셋 다 "AI가 코드를 잘 못 짜서"가 아니라 애초에 코드 생성이 병목이 아니어서였습니다.

① 크롤링의 병목은 타이핑 속도가 아니라 상대방 사이트입니다

AI는 셀렉터를 1초에 써줍니다. 그런데 봇 탐지, TLS 핑거프린팅, IP 평판, CAPTCHA를 뚫어주지는 않습니다. 코드를 빨리 쓰는 것과 상대가 막아 놓은 것을 통과하는 것은 다른 문제입니다.

더 정확히 말하면 이건 상대가 대응하는 적대적 함수입니다. 코드 생성 문제라면 더 좋은 모델이 해결해 주겠지만, 이건 상대편에 사람이 앉아서 우리의 우회를 보고 다시 막는 구조입니다. 생성 속도가 100배가 되어도 이 왕복의 횟수는 줄지 않습니다.

② 정확도를 "측정"하려면 정답 라벨셋이 있어야 합니다

수용 기준에 정확도 목표가 걸려 있으면 그 정확도를 잰 근거가 있어야 합니다. 그러려면 정답이 붙은 데이터가 필요하고, 도메인 특화 다국어 감성분석 라벨링은 결국 전문가 노동입니다.

"라벨도 LLM으로 만들면 되지 않나"라는 생각이 자연스럽게 따라옵니다. 그런데 그렇게 만든 점수는 모델이 모델을 채점한 값입니다. 수용 기준의 근거로는 쓸 수 없습니다. 채점자와 응시자가 같으면 그 점수는 성능이 아니라 일치도를 잰 것이니까요.

③ 수용 기준은 코딩 시간이 아니라 관측 캘린더 시간을 요구합니다

"잡 성공률 98%" 같은 기준을 증명하려면 파이프라인을 며칠씩 돌려야 합니다. 코드가 완성된 시점은 측정의 시작점이지 끝점이 아닙니다.

이게 제가 이번 산정에서 가장 늦게 이해한 것이었습니다. 코딩 완료와 수용 기준 충족은 같은 사건이 아닙니다. 그리고 AI는 앞의 것만 당겨줍니다. 뒤의 것은 시간이 흘러야 합니다. (이 캘린더 시간이 인원을 늘려도 줄지 않는다는 이야기는 5편에서 따로 다루겠습니다.)

정리하며

AI 가속에 대해 이번 산정에서 배운 것은 두 가지로 줄어듭니다.

첫째, AI 가속을 일괄 계수로 반영하면 안 됩니다. 작업 성격별로 압축률이 완전히 다르기 때문에 평균 하나로 뭉개면 정보가 사라집니다. 그리고 뭉갠 숫자는 협상의 대상이 되지만 쪼갠 숫자는 검증의 대상이 됩니다. 검증할 수 있는 숫자가 언제나 강합니다.

둘째, 가속에는 천장이 있고 그 천장은 제 의견이 아니라 산술이 정합니다. p를 1.0으로 잡지 않는 한 바닥은 반드시 남습니다. 그러니 논쟁은 "몇 퍼센트를 깎을 것인가"가 아니라 "무엇이 low인가"에서 벌어져야 합니다. 후자는 항목 단위로 답할 수 있는 질문이고, 답이 나오면 견적이 실제로 바뀝니다.

처음 질문으로 돌아가면, "AI로 하면 빠르잖아요"에 대한 제 답은 "네, 빨라집니다"입니다. 다만 어디가 빨라지는지를 항목별로 말할 수 있어야 그 다음 문장을 이어갈 수 있습니다. 627시간은 정말로 빨라집니다. 그리고 418시간은 그렇지 않습니다. 이 두 문장을 같이 말할 수 있게 된 것이 이번 산정의 소득이었습니다.

그런데 "빨라지지 않나"에는 후보가 하나 더 있습니다. "이미 만들어 둔 걸 재사용하면 되지 않나"입니다. 다음 편에서 그 질문에 추측 대신 실사로 답한 이야기를 적겠습니다. 결론만 미리 적자면, 재사용할 코드를 63시간어치 찾고도 견적은 올랐습니다.