얼마 전, 엔지니어 type의 인기 기사 랭킹에서 1위를 차지한 기사가 있습니다.

GMO 대표 · 쿠마가이 마사토시 「2개월 만에 10만 행의 코드를 작성했다」

(엔지니어 type, 2026.07.01)

GMO 인터넷 그룹 대표 · 쿠마가이 마사토시 씨(62세)가, Claude Code로 2개월 동안 약 10만 행의 코드를 작성하여 "예전 같으면 5,000만 엔이 들었을 개발이 토큰 비용 3만 엔으로 끝났다"라고 말하는 내용입니다. 숫자의 임팩트가 강하네요.

주장만 정리하면…

만든 것은 기업의 기간 시스템(Core System)이 아니라, 자신만의 전용 툴입니다. 막히면 화면 스크린샷을 Claude에 붙여넣어 벽치기(Wall-hitting, 대화형 피드백)를 하고, GitHub을 경유하여 9대의 디바이스를 나누어 쓰며 혼자서 완성했다는 개발 방식도 소개되어 있습니다.

62세 · 비엔지니어인 경영 탑이 자신의 손으로 직접 만들어냈다. 이 점은 솔직하게 평가해야 합니다.

"AI로 개발이 바뀐다"라고 말하는 경영자는 산더미처럼 많지만, 대부분은 전언(傳聞)입니다. 남에게 들은 이야기를 마치 자신의 말인 것처럼 이야기하죠.

반면 쿠마가이 씨는 스스로 에러에 막히고, 스크린샷을 붙여 질문하며 하나씩 해결해 나가고 있습니다. 현장에 "AI를 써라"라고 명령만 내리고 자신은 만지지 않는 경영층과 비교했을 때, 이 일차 체험(Primary Experience)의 차이는 아마 본인이 생각하는 것보다 클 것입니다.

이하, 숫자에는 상당히 엄격하게 쓰겠지만, 여기서는 전제로 깔아두겠습니다.

기사의 "5,000만 엔"은 누군가가 낸 견적이 아닙니다. 로직은 이렇습니다.

과거 SIer 시세: 1인월(Man-month) 100만 엔으로 쓸 수 있는 것은 평균 1,000행
↓
"1,000행 = 100만 엔"을 업계의 대략적인 시세로 설정
...

100인월입니다. 1억 엔입니다.

10만 ÷ 1,000 = 100. 원문 기사의 원문이 이렇게 되어 있습니다.

그렇게 되면, 10만 행의 코드를 작성하려면 50인월, 즉 『5,000만 엔』이 들었던 셈입니다.

즉, 오류는 원문 기사 측에 있습니다.

그리고 주목해야 할 점은, 오류의 방향입니다. 이 계산은 쿠마가이 씨에게 불리한 방향으로 틀려 있습니다. 자신의 논리에 솔직하게 따랐다면 "1억 엔이 3만 엔이 되었다"라고 말할 수 있었는데, 그 절반으로 신고하고 있습니다. 숫자를 부풀리고 싶은 사람이라면 이런 식으로 틀리지 않습니다.

(짐작건대, 그가 말하는 "시간 효율 50배"는 100인월 ÷ 본인의 2개월 = 50배로 깔끔하게 나옵니다. 어딘가에서 올바르게 100인월을 산출해 두고, 금액으로 바꾸는 단계에서만 50인월이 되었다는 맥락은 생각할 수 있습니다. 어디까지나 추측입니다.)

다음은 "3만 엔". 기사에 첨부된 청구 이력 스크린샷에는 다음과 같은 캡션이 붙어 있습니다.

개발 시작 후 합계로 "$435"라는 경이적인 저가격(약 3만 엔 초반의 토큰 비용)에 수렴

$435입니다. 2026년 7월의 달러/엔 환율은 162엔 전후이므로, 약 7만 엔입니다. 3만 엔 초반이 되지 않습니다. 증거로 첨부된 스크린샷이 본문의 금액보다 2배 이상을 나타내고 있습니다.

그리고 "1/30". 기사 안에 나열된 5,000만 엔과 3만 엔, 이 비율은 약 1,667배입니다. 1/30이 아닙니다. 이 "30"이라는 숫자가 어디서 온 것인지는 원문 기사를 읽어도 알 수 없었습니다.

자, 여기까지 3곳의 구멍을 뚫어놓고 판을 뒤엎어 보겠습니다.

고쳐 봅시다. 1억 엔 ÷ 7만 엔 = 약 1,429배. 원래의 5,000만 엔 ÷ 3만 엔 = 약 1,667배.

거의 변하지 않습니다.

양쪽의 오류가 같은 방향(둘 다 과소 신고)이기 때문에, 비율을 취하면 서로 상쇄되기 때문입니다. 자릿수는 움직이지 않습니다.

이것이 숫자 비판의 한계입니다. 금액의 틀린 부분을 아무리 찾아내도, "자릿수가 다르게 저렴하게 만들었다"라는 이야기의 골격은 살아남고 맙니다. 그러므로 정말로 물어야 할 것은 자릿수가 맞느냐가 아닙니다. 그 1억 엔과 7만 엔은 애초에 같은 것을 세고 있는가입니다.

먼저 하나 짚고 넘어가겠습니다.

Claude Code의 통계가 세고 있는 것은, 세션을 통해 추가된 행의 누적입니다. 쓰고 지우고, 리팩토링(Refactoring)으로 통째로 교체한 분량도 전부 거기에 포함됩니다. 순증(Net increase)이 아닙니다. "10만 행의 코드가 존재한다"가 아니라 "Claude Code가 누적 10만 행을 썼다"가 올바른 표현입니다.

그리고 까다로운 점은, 이 숫자를 외부에서 검증할 수 없다는 것입니다. 실제 리포지토리(Repository)는 비공개이며, 스토어에 나와 있는 것은 빌드된 바이너리(Binary)뿐입니다. 실제로 몇 행이 있는지인 본인만이 제시할 수 있습니다. 반증 불가능한 숫자가 독자적으로 유포되고 있는 상태입니다.

그 점을 전제로, 행수 그 자체에 대한 이야기입니다.

• 동일한 기능을 10만 행으로 작성할지 2만 행으로 작성할지는 구현 방식에 따라 다르며, 행수가 많다고 해서 반드시 좋은 것도 아닙니다 (오히려 그 반대인 경우가 더 많습니다).
• 대상은 개인용 시간 관리 앱입니다. 사양 합의, 타인과의 정합성, 장기 유지보수를 책임져야 하는 기업 시스템의 10만 행과는 1행의 무게감이 다릅니다.

코드 리뷰(Code Review)에서 "이번 주에 ○○행 작성했습니다"가 칭찬이 된 사례는 없습니다. 액면 그대로 받아들이면, 이야기 전체가 한 단계 과대평가되는 방향으로 흐릅니다.

여기가 핵심입니다.

"1인 월 100만 엔으로 1000행"이라는 시세를 "1000행밖에 못 쓰는 건가, 생산성이 낮네"라고 읽는 것은 오독입니다. 그 1000행에는 요구사항 정의, 설계, 리뷰, 테스트, 문서화, 그리고 납품 후에 타인이 유지보수할 수 있는 상태로 만들기까지의 모든 공수(Man-month)가 포함되어 있습니다.

"1000행을 사양 합의부터 유지보수 가능한 상태까지 가져가는 데 1인 월이 걸린다"는 의미의 숫자입니다. 작성 속도에 대한 이야기가 아닙니다.

쿠마가이 씨는 그 풀 로드(Full load)의 단가를, 이 모든 것을 전혀 포함하지 않는 AI 출력 행수에 곱했습니다. 사과 가격표를 귤의 개수에 곱하고 있는 격입니다.

1억 엔은 "타인에게 발주하여 풀 세트로 제작했을 때의 총액", 7만 엔은 "직접 만들었을 때의 API 이용료만". 그리고 경영진 본인이 2개월 동안 투입한 시간은 어디에도 계상되어 있지 않습니다. 운동장을 맞추고 본인 공수를 더하면, 배율은 상당히 줄어듭니다.

숫자가 틀렸다는 점보다 이쪽이 더 치명적입니다. 틀린 것은 고칠 수 있지만, 이것은 고칠 방법이 없기 때문입니다.

마지막의 "1500배". 시간 효율(50배)과 비용 절감(1/30)이라는, 단위가 다른 두 개의 계측기를 곱해버린 숫자입니다.

속도와 저렴함을 곱해서 나온 "1500배"에는 물리적인 의미가 없습니다. "빨라졌다(50배)", "저렴해졌다(30배)"라고 따로 말해도 충분히 전달될 부분을, 굳이 곱해서 4자리 숫자로 키워 놓았습니다. 게다가 그 "30"은 아까 보았듯이 출처가 불분명합니다.

이 한 수에서 기사의 톤이 잘 드러납니다.

기사에는 슬쩍 이런 구절이 있습니다.

심지어 일부 기능은 이미 일반 사용자용 앱으로 스토어 공개까지 해버렸습니다.

10만 행이나 5000만 엔이라는 숫자 뒤에 가려져 간과되기 쉽지만, 엔지니어로서 가장 눈썹이 꿈틀거리는 부분은 솔직히 이 문장입니다.

우선 선긋기부터 하겠습니다. 자신 전용의 비공개 앱이라면 테스트가 없어도 아무런 문제가 없습니다. 사용하는 것도 자신뿐이고, 고장 나서 곤란한 것도 자신뿐입니다. 오히려 취미 범위에서 과도하게 테스트를 작성하는 것은 KISS/YAGNI 원칙에 반합니다. "AI와 대화하며 돌아가는 것을 만든다"는 이른바 바이브 코딩(Vibe Coding)은 이 영역과 최고의 궁합을 자랑합니다.

문제는 그것을 공개하여 타인이 사용하게 하는 순간, 책임의 차원이 달라진다는 것입니다.

• 자동 테스트(Automated Test)가 없으면 회귀(Regression)를 감지할 수 없습니다. AI에게 다음 수정을 요청했을 때, 다른 곳이 조용히 망가져도 알아차릴 수 없습니다.
• 보안. 입력 검증(Validation), XSS, 인증·인가, 의존 라이브러리의 취약점. "돌아간다"와 "공격에 견딘다"는 별개의 문제입니다.
• 개인정보를 다룬다면 보관과 유출의 리스크. 사용자의 데이터를 맡는 시점에서 법적·윤리적 책임이 발생합니다.
• 유지보수. 만든 본인만이 구조를 알고 있고, 심지어 그 구조를 AI가 작성했다면, 반년 뒤에 누가 고칠 것인가.

그리고 여기서 서두의 표로 돌아갑니다.

| 아무에게도 묻지 않고 혼자 개발 | 책도 YouTube도 보지 않고, 사내 엔지니어와도 상의하지 않음 |

원문의 표현은 이렇습니다.

한 명에게도 묻지 않았습니다. 책도 읽지 않았고, YouTube도 보지 않았습니다. 사내 누구에게도 묻지 않고 만들었습니다.

국내 유수의 엔지니어 조직을 보유한 회사의 수장이, 사내 누구에게도 보여주지 않고 작성한 코드를 스토어에 공개했다.

이것이 이 기사에서 가장 주목해야 할 지점이라고 생각합니다. 일본 내 유수의 리뷰어에게 결재나 품의 없이 접근할 수 있는 위치에 있는 사람이, 그것을 단 한 번도 검토하지 않고 출하했습니다. "아무에게도 묻지 않고 혼자서"는 공개 전이라면 무용담이지만, 공개 후에는 사례(Case study)입니다.

같은 문장이라도 선의 어느 쪽에 있느냐에 따라 의미가 반전됩니다.

비엔지니어(Non-engineer)가 AI로 만들 수 있는 시대의 함정은, 이 경계선(Line)이 보이지 않는다는 점입니다. 보이지 않기 때문에, 선을 넘었다는 자각이 발생하지 않습니다. 악의도 태만도 아닌, 단순히 "작동하니까 내놓았다"일 뿐입니다.

그리고 이것은 남의 일이 아닐 것입니다.

이 글을 읽은 당신 회사의 경영진이 다음 주에 "우리도 하자"라고 말할 가능성은 꽤 높습니다.

그때 이를 저지할 재료는 "위험합니다"가 아닙니다. "공개하지 않는다면 마음대로 하십시오. 하지만 공개할 것이라면, 리뷰를 한 번 거쳐주세요" 라는, 선의 위치를 제시하는 것입니다. 금지가 아니라, 선을 보여주는 것입니다.

그것을 할 수 있는 것은, 선이 보이는 쪽에 있는 사람뿐입니다.

"5,000만 엔 → 3만 엔 → 1,500배"는 액면 그대로 받아들이지 않는 편이 좋습니다. 금액은 두 곳 모두 틀렸으며, 1,500배는 단위가 다른 것을 곱한 연출입니다.

다만, 수정하더라도 자릿수는 변하지 않았습니다. 그리고 방향성까지 부정할 생각은 없습니다. 개인이 AI로, 이전이라면 외주를 주었을 수준의 것을 만들 수 있게 되었다. 비용 구조가 근저에서 바뀌었다. 이 점은 과장 없이 맞습니다.

문제는, 바뀐 것이 비용 구조뿐이며, 책임의 구조는 1mm도 바뀌지 않았다는 점입니다. 7만 엔으로 만들 수 있게 되어도, 공개한 앱이 개인정보를 유출했을 때의 책임은 5,000만 엔을 들여 만들었을 경우와 동일합니다. 싸진 것은 만드는 쪽의 비용이지, 사용하는 쪽의 리스크가 아닙니다.

여기서 "그렇기 때문에 테스트(Test), 보안(Security), 유지보수(Maintenance)라는 '공개의 예법'을 가진 인간의 가치가 올라간다"라고 마무리하면, 엔지니어 독자들은 기분 좋게 글을 읽을 수 있을 것입니다. 실제로 초안은 그렇게 적혀 있었습니다.

하지만, 아마 아닐 것입니다. 예법의 가치가 올라가는 것은, 예법이 결여된 제품이 벌을 받는 시장뿐입니다.

쿠마가이 씨는 예법 없이 공개했습니다. 현재까지는 아무 일도 일어나지 않았습니다. 그리고 인기 기사 랭킹 1위입니다. 시장은 지금, 예법의 결여를 벌하지 않고 있습니다.

벌이 오지 않는다면, 가격도 매겨지지 않습니다. "품질의 가치가 올라간다"는 것은, 내버려 두면 그렇게 될 것이라는 예언이 아니라, 누군가가 벌을 가시화했을 때 비로소 성립하는 주장입니다.

그러니, 벌벌 떨 필요는 없다고는 말하지 않겠습니다. 당신이 3만 엔의 경계 밖에서 내놓는 가치는, 그것을 사는 사람이 있어야 비로소 가치가 됩니다. 구매자를 육성하는 단계까지 아마 업무 범위에 들어와 있습니다.

출처: 엔지니어type 「GMO 대표 쿠마가이 마사토시 '2개월 만에 10만 행 코드 작성했다' 대표 스스로 '사용해야 가치가 있다'를 몸소 실천하는 이유」(2026.07.01) https://type.jp/et/feature/31346/

이상의 내용도 모두 Claude (+기술 기사 작성을 위한 자체 제작 SKILL)가 작성했습니다(웃음).

초안에는 기사에 이모지가 포함된 Mermaid 다이어그램이 있었습니다. 50 × 30 = 1500인 플로우차트(Flowchart)입니다. 거기서 무언가 느끼는 분도 있을 것입니다.

그런데 Claude 스스로가 그 Mermaid를 지웠습니다. 지운 이유는, 직전 문장에 "50과 30을 곱해서 1500"이라고 적혀 있는데, 그 옆에 50과 30을 곱해서 1500을 만드는 그림이 놓여 있다. 인간은 곱셈 그림을 그리지 않으니까요... 라고 합니다(웃음).

여기까지는 뭐, 웃고 넘길 이야기입니다.

초안에는 "먼저, 검산한다"라는 섹션이 통째로 없었습니다.

Claude가 작성한 초안은, 쿠마가이 씨의 "10만 행 ÷ 1,000행 = 50인월(Man-month)"을 코드 블록에 깔끔하게 재구성한 뒤, 전제 조건만 비판하고 나눗셈은 하지 않았습니다. $435라는 캡션(Caption)도 보지 않았습니다. 1/30의 출처도 묻지 않았습니다. "그 숫자는 진짜인가"라는 헤드라인을 스스로 달았던 기사가, 숫자를 단 한 번도 검산하지 않았던 것입니다.

게다가 친절하게도 "AI가 저렴함을 돋보이게 하기 위해 형편 좋게 구성한 시산"이라며 동기까지 추측했습니다. 실제 오류는 쿠마가이 씨에게 불리한 방향이었기에, 이는 완전한 억지였습니다. 검산했더라면 쓰지 않아도 되었을 문장이었습니다.

그 기사를 Claude 자신에게 "비평하라"고 다시 던졌더니, 출처를 다시 읽고 3곳을 수정해 왔습니다.

초안에 부족했던 것은 검산하는 능력이 아닙니다. 검산을 거쳐야 한다는 판단입니다.

쿠마가이 씨가 "작동하니까 공개했다" & 제가 "읽을 만한 기사니까 공개했다"는 것은, 테스트가 없는 코드를 공개하는 것 & 검산이 없는 숫자를 공개하는 것과 같은 선의 같은 쪽에 있습니다.

선은, 선을 넘은 쪽에서는 보이지 않는 법입니다...라는 말로 마치겠습니다.