생산성 임계 돌파 — 5명·1년이 1인·3주로

예전 같으면 다섯 명이 일 년 매달려야 했을 ERP·전자결재 구축을, 한 사람이 3주 만에. 이건 “조금 빨라졌다”는 이야기가 아닙니다. 인당 생산성의 자릿수가 바뀌면 산업의 원가구조 자체가 무너집니다.

먼저, 이 수치의 정직한 경계

본론에 들어가기 전에 가장 오해받기 쉬운 부분부터 못 박습니다. “5명·1년 → 1인·3주”는 CEO가 잡은 목표이자 현재 체감이지, 외부 기관이 독립적으로 검증한 측정값이 아닙니다. 같은 범위·같은 품질을 동일 조건에서 비교한 실험실 수치도 아닙니다.

그럼에도 이 수치를 쓰는 이유는 방향이 분명하기 때문입니다. 정확히 3주냐 4주냐가 핵심이 아닙니다. 핵심은 “팀·연 단위”로 잡던 일이 “1인·주 단위”로 내려오는 자릿수의 변화가 실제로 일어나고 있다는 것입니다. 부풀린 숫자는 한 번 의심받는 순간 글 전체의 신뢰를 무너뜨립니다. 그래서 이 글에서는 “검증된 사실”과 “내부 체감”을 매번 구분해 표시합니다.

용어: 임계 돌파(threshold leap)

같은 방식 안에서 10%·30% 빨라지는 점진적 개선이 아니라, 일하는 방식 자체가 달라져 생산성의 자릿수가 바뀌는 단절적 도약입니다. 물이 99도에서 100도로 갈 때 액체가 기체로 상(相)이 바뀌듯, 양의 변화가 어느 선을 넘으면 질의 변화가 됩니다.

”조금 빨라진 것”과 “차원이 바뀐 것”의 차이

생산성 향상에는 두 종류가 있습니다. 둘은 비슷해 보이지만 결과가 완전히 다릅니다.

1. 점진적 개선 — 같은 방식 안에서 10%, 30% 빨라집니다. 더 좋은 IDE, 더 빠른 빌드, 더 숙련된 손. 경쟁의 속도를 높입니다.
2. 차원 변화 — 일하는 방식 자체가 달라져 자릿수가 바뀝니다. 사람이 한 줄씩 치던 일을 에이전트가 1차로 만듭니다. 경쟁의 규칙을 바꿉니다.

제가 말하는 임계 돌파는 후자입니다. 다섯 명·일 년이라는 작업을 한 명·3주로 줄이는 건, 같은 방식으로 빨리 친 결과가 아닙니다. 사람이 코드를 한 줄씩 치는 대신, AI 에이전트가 1차로 작성하고 사람이 방향과 검증만 맡는 구조로 바꿨기에 가능했습니다. 손이 빨라진 게 아니라 일의 주체가 바뀐 것입니다.

	점진적 개선	차원 변화(임계 돌파)
무엇이 바뀌나	도구·숙련도	일의 주체와 방식
향상폭	10~30% 빠름	자릿수가 바뀜
경쟁에 미치는 영향	속도를 높임	규칙을 바꿈
예시	더 빠른 빌드, 더 숙련된 손	에이전트가 1차로 만들고 사람이 검증

왜 이게 산업을 흔드는가 — SI 원가구조의 무력화

시스템 통합(SI) 산업의 가격은 오랫동안 단순한 공식을 따랐습니다.

투입 인력 × 기간 = 원가 = 견적.

더 큰 시스템은 더 많은 사람과 더 긴 기간을 의미했고, 그게 곧 청구서였습니다. 이 공식이 산업 전체의 가격·계약·조직을 떠받쳤습니다.

용어: 인월(man-month)

“사람 한 명이 한 달 일하는 양”을 한 단위로 보는 견적 단위입니다. 5명이 12개월 일하면 60인월. SI 산업은 오래 이 단위로 가격을 매겼습니다. 큰 시스템 = 많은 인월 = 비싼 견적. 인월은 곧 “사람의 시간을 판다”는 산업의 정체성이기도 했습니다.

그런데 한 사람이 다섯 사람 몫을 주 단위로 해낸다면, 이 공식의 분모가 무너집니다.

"인력 × 기간"으로 매기던 견적의 분모가 자릿수째 줄어드는 모습(개념도, 수치는 근사). 빨강 막대가 거의 사라진 자리에서 인월 기반 가격 모델 자체가 의미를 잃습니다.

물론 이 충격이 SI 산업을 하루아침에 무너뜨린다는 말은 아닙니다. 인월 모델은 가격뿐 아니라 책임·계약·신뢰의 구조이기도 해서, 관성이 큽니다. 다만 “사람 수 × 기간”이 더 이상 결과물의 크기를 설명하지 못하는 순간, 그 위에 세워진 견적·조직·계약은 천천히 정당성을 잃습니다. 변화는 극적이지 않게, 그러나 되돌릴 수 없게 옵니다.

현재 어디까지 왔나

이 글에서 말하는 ERP·전자결재 시스템은 추상적 비유가 아니라 지금도 만들고 있는 실물입니다. CEO가 잡은 목표 기준으로 전자결재는 사실상 완성 단계, ERP는 80% 진행 중이라고 봅니다(내부 기준 현황, 미배포 개발 단계).

그리고 한 사람이 ERP만 만드는 게 아닙니다. 회로 설계 분석, 펌웨어 자동화, 마케팅 페이지, 출퇴근 앱까지 〈여러 프로젝트가 동시에〉 굴러갑니다. 이 “동시성”이야말로 임계 돌파의 진짜 증거입니다. 손의 개수가 병목이라면 동시에 여러 개를 굴릴 수 없습니다.

한 가지 더 정직하게 짚을 게 있습니다. 임계를 넘었다고 사람이 한가해지는 건 아닙니다. 병목이 “손”에서 “검증”으로 옮겨갔을 뿐입니다. 그래서 1인 개발자의 하루는 “코드를 친다”기보다 “끊임없이 결정한다”에 가깝습니다. 자릿수가 바뀐 건 생산량이지, 사람이 쉬는 시간이 아닙니다.

도약은 공짜가 아니다 — 제동 장치가 함께 가야 한다

여기서 비전 글이 빠지기 쉬운 함정을 정직하게 짚습니다. 생산성이 폭증하면 좋은 일만 생기는 게 아닙니다.

⚠ 빠른 생산은 빠른 부채를 낳는다

AI가 빠르게 만든 코드는 빠르게 비대해지고, 빠르게 기술 부채를 쌓습니다. AI는 “기존 파일에 덧붙이기”에 편향돼 있어, 멈춤 장치가 없으면 파일이 조용히 수천 줄로 부풉니다. 인당 생산성이 5배가 되면, 통제 장치가 없을 때 부채도 5배 속도로 쌓입니다. 속도 자체가 새로운 종류의 위험이 되는 셈입니다.

그래서 우리는 속도와 짝을 이루는 제동 장치를 함께 만들어야 했습니다. 파일이 일정 크기를 넘으면 커밋을 막는 게이트, 테스트가 통과해야만 다음으로 넘어가는 관문, 한 작업을 작은 단위로 쪼개는 규율 같은 것들입니다.

역설적이게도, 이 제동 장치들은 속도를 늦추는 게 아니라 오히려 속도를 지속 가능하게 만듭니다. 빠른 차일수록 좋은 브레이크가 필요한 것과 같습니다 — 브레이크는 차를 느리게 하려고 다는 게 아니라, 안심하고 빠르게 달리려고 답니다.

도약이 주는 것	도약이 데려오는 위험	짝지어야 할 제동 장치
인당 생산성 자릿수 변화	코드 비대화 가속	파일·함수 크기 한도(ratchet 게이트)
빠른 기능 추가	검증 없는 “완료” 선언	테스트 통과를 강제하는 관문
여러 프로젝트 동시 진행	맥락 혼선·일관성 붕괴	작업 단위 분할·세션 규율

교훈

생산성의 진짜 변곡은 “더 빨리”가 아니라 “다른 방식으로”에서 옵니다. 사람이 1차로 만들고 도구가 돕는 구조에서, 도구가 1차로 만들고 사람이 검증하는 구조로 바꾸면 인당 생산성의 자릿수가 달라집니다. 그 도약은 SI처럼 인월로 가격을 매기던 산업의 원가구조를 무력화합니다. 단, 두 가지를 잊으면 안 됩니다 — ① 수치는 목표·체감이지 검증된 사실이 아니라는 정직함, ② 속도에는 반드시 제동 장치를 짝지어야 한다는 규율. 통제 없는 속도는 자산이 아니라 부채입니다.

---

이 도약이 왜 가능한지(②·③ 주체 전환)는 〈입력 없는 ERP〉에서, AI 코딩 폭주를 막는 제동 장치(Harness)의 공학은 〈큰 그림 Part 4〉에 자세히 있습니다. 빠른 부채의 실제 현장 사례는 〈god 파일을 막지 못한 것〉을 참고하세요.