r/ClaudeCode에 올라와 292점을 받은 한 줄짜리 고백이 한 주 동안 트위터·HN·디스코드를 돌고 있어요. 글쓴이는 비개발 창업자였고, Claude Code로 6주 만에 결제·인증·관리자까지 다 붙은 SaaS를 만들었어요. 한 달이 지나서 본인도, 새로 합류한 외주 개발자도, 본인의 새 시니어 친구도 그 코드베이스 안에서 일어나는 일을 누구도 정확히 설명하지 못한다는 거예요.
이건 '바이브 코딩 80/20 함정'(5월 5일에 다룬 주제)의 운영 단계 버전이에요. PoC 1시간이 무서운 게 아니라 6주 동안 만들어진 4만 줄짜리 AI 생성 코드를 누가 어떻게 인계받느냐가 무서워요. AI 코딩이 빌드 시간을 6배 줄여 준 만큼, 인계 시간은 3배 늘어난다는 통계가 4월 말 GitHub State of AI Code 2026 보고서에 나왔어요.
한국 비개발 창업자에게 이 문제는 더 무거워요. PoC를 외주에서 받으면 인계받을 사람이 없고, AI 코드를 본인이 만들었으면 분쟁 시 영업비밀 보호 책임이 본인에게 다 떨어져요. 시리즈 A 실사에서 "이 코드 누가 책임지냐"가 30분 안에 깨지는 사례가 1주일에 두 번씩 나오고 있어요.
Claude Code, Cursor, Codex 같은 에이전틱 코딩 도구는 한 번에 200~800줄을 쏟아내요. 사람이 줄 단위로 리뷰하지 않으면 에이전트가 추가한 헬퍼 함수, 임시 mock, 재시도 로직, 캐시 키, 환경 변수가 누구의 결정인지 추적이 안 돼요.
3개월 뒤에 그 코드를 다시 열어보면 같은 패턴이 6벌씩 들어 있고, 작동은 하는데 어떤 게 'canonical' 인지 모르겠는 상태예요. 외주 개발자에게 인계하려고 하면 "이건 왜 이렇게 했나요?" 질문에 본인이 답을 못 해요.
이게 4월 30일 Mitchell Hashimoto가 Ghostty를 GitHub에서 떼어낸 배경, 4월 22일 Opus 4.7 'anxiety' 플레이북 논란, 4월 17일 Self-Verification 출시가 모두 가리키던 같은 문제예요. 속도와 이해도는 별개의 KPI다.
결정적으로 한국 시장에서는 AI 코드의 IP 귀속이 정해지지 않았어요. 외주 NDA에 "AI 도구로 생성된 코드의 50/50 추정 위험"을 명시하지 않으면, M&A 실사 단계에서 가치의 30~60%가 깎이는 사례가 2026년 1분기에만 4건 보고됐어요.
에이전트가 한 번에 쏟아내는 200~800줄을 그대로 머지하지 마세요. 모듈(예: payments, auth, idempotency, audit-log)을 5~7개로 나누고, 각 모듈에 사람이 30분 안에 읽고 사인오프하는 게이트를 두세요. 한 번에 3개 PR로 자르고, 각 PR은 max 300줄 룰을 강제하세요.
이걸 안 하면 인계받는 사람이 첫 주에 어디부터 봐야 할지 모릅니다. 시니어 개발자 주 4시간을 사람 사인오프에 쓰면 인계 시간이 70% 줄어요. (5월 5일 Vibe Coding 80/20 함정 글의 실측 결과예요.)
AI가 만든 코드의 가장 큰 약점은 'Why'가 없다는 거예요. 에이전트는 "왜 Redis가 아니라 메모리 캐시를 썼나"를 코드에 남기지 않아요. 6주 뒤 본인도 그 결정을 못 떠올려요.
해법은 단순해요. 모든 PR에 1페이지 ADR(Architecture Decision Record)을 강제하세요. 형식은 4줄: 컨텍스트 / 결정 / 대안 / 결과. 에이전트에게 "이 PR을 머지하기 전에 ADR을 docs/adr/ 디렉토리에 만들어"라고 지시하면 90초 안에 만들어 줘요. 이게 인계 자산 1순위예요. 6개월 뒤 새 외주사가 들어올 때 ADR 50개만 봐도 코드베이스의 70%를 이해해요.
AI 코드의 두 번째 약점은 "왜 작동하는지" 검증이 없다는 거예요. 유닛 테스트가 0~5%인 경우가 흔한데, 외주 인계 시 "이 코드가 작동한다"는 증명이 안 돼요.
2026년 표준은 평가셋(eval set)이에요. 핵심 도메인(결제 / 인증 / 환불 / 사용자 가입)마다 200건짜리 입력×기대 출력 쌍을 만들어 두세요. 에이전트에게 "이 모듈에 대한 평가셋 200건을 합성으로 만들어"라고 지시하면 1시간 안에 초안이 나와요. 그중 50건은 사람이 검수하고, 150건은 LLM 검증으로 충분해요.
외주 인계 시 평가셋 통과율 95%를 사인오프 조건으로 박으면 분쟁 70% 감소해요. 에지 케이스(인코딩 우회, 시간대 경계, 결제 webhook 재시도)도 평가셋에 들어가야 해요.
AI 코드베이스를 외주가 인계받을 때 가장 큰 장벽은 "이 코드가 어떻게 돌아가는지" 컨텍스트 압축이에요. 4월 9일에 다룬 Karpathy 프리컴파일 위키 전략이 정확히 그 답이에요.
매주 1회, 에이전트에게 "지난 주 변경분을 wiki/architecture.md에 1페이지로 요약해"라고 지시하세요. 이때 핵심 결정·핵심 함수 시그니처·외부 의존성 만 남기고 나머지는 버려요. 6개월 뒤 wiki/는 50KB가 되고, 새 외주사가 첫 주에 그것만 읽어도 70%를 이해해요.
CLAUDE.md / AGENTS.md / docs/adr/ / wiki/architecture.md 4개 파일이 인계 자산의 핵심이에요. 토큰 47,450 → 360으로 압축됐다는 4월 9일 글의 측정값이 여기서도 그대로 적용돼요.
이 모든 게 있어도, 분기에 한 번은 사람 시니어가 코드베이스를 30분 walkthrough 하면서 "이게 왜 이렇게 됐는지"를 음성/Notion 형태로 남겨야 해요. AI는 walkthrough를 못 해요.
그리고 NDA·계약서에 다음 4줄을 박으세요. (1) 외주가 사용한 AI 도구 종류·빈도 보고 의무 / (2) AI 생성 코드 비율 분기별 보고 / (3) AI 코드의 IP 귀속을 발주자 100%로 명시(Enterprise zero-retention 한정) / (4) Co-authored-by trailer 정책 합의(VS Code Copilot 자동 trailer 5월 4일 글 참조).
이 4줄이 빠지면 1년 뒤 분쟁에서 저작권 귀속이 불분명해져 협상 자체가 불리해져요. M&A 실사 때 외주 1년치 AI 사용 비율이 30%만 넘어도 가치 평가가 깎여요.
"우리도 이해 못 하는 코드"는 우리만의 문제가 아니에요. 2026년 한국 시장에서 비개발 창업자의 70%가 같은 자리에 서 있어요. 차이는 'AI 속도'를 자산으로 바꿀 수 있는 5가지 잠금이 코드 안에 박혔는지 한 줄도 안 박혔는지예요.
이미 만들어진 AI 코드베이스를 안전하게 인계받고 싶다면 포텐랩 상담에서 무료 진단을 받을 수 있어요. AI 생성 코드 인계와 ADR·평가셋 셋업을 표준 자산으로 운영하고 있어요. AI 모델·에이전트 자체를 깊이 다루어야 한다면 트리숲도 좋은 파트너예요.