45세, 코드 한 줄 못 쓰는 보디빌딩 챔피언이 90일 만에 12만 줄짜리 스팀 게임을 출시했다. 후지나가 나오키의 사례(AI포스트 인터뷰)는 단순한 인간 승리 스토리가 아니다. 이건 'AI를 얼마나 잘 다루느냐'가 곧 생산성이 되는 시대가 실제로 열렸다는 선언이다. 그리고 그 이면에는, 막상 AI로 제품을 만들어보면 부딪히는 꽤 현실적인 벽이 있다.
AI 디렉팅의 실체: 엔진보다 구조 지시가 먼저다
후지나가가 Unity나 Unreal을 선택하지 않은 건 단순히 시간이 없어서가 아니었다. 그의 판단은 날카롭다. "엔진을 배우는 데 수십~수백 시간이 들지만, AI에게 '이런 구조가 필요하다'고 말하면 엔진에 해당하는 부분 자체를 AI가 써준다." 순수 TypeScript로 밑바닥부터 구축한 것은 기술적 선택이기 이전에 프로덕트 사고의 결과였다. 3개월이라는 기한 안에서 가장 빠르게 원하는 결과를 낼 수 있는 경로를 선택한 것이다. 기존 개념에 얽매이지 않아서 오히려 자신만의 맵 에디터와 개발 흐름을 처음부터 설계할 수 있었다는 역설도 흥미롭다.
하지만 AI에게 방향을 지시하는 것만으로 충분하지 않다는 걸 그는 첫 달에 뼈저리게 배웠다. 코드베이스가 커지자 AI의 사고 시간이 폭증했고, Claude Max의 5시간 한도를 1~2시간 만에 소진하는 일이 반복됐다. 버그 발생률이 급격히 오르고, 예전에 정한 규칙을 AI가 잊은 채 다른 방식으로 코드를 작성하기 시작했다. "컨텍스트와의 싸움"이 가장 힘들었다는 그의 고백은 AI 협업의 본질적 한계를 정확히 가리킨다.
CLAUDE.md는 기억이 아니라 희망이다
후지나가가 찾아낸 해법은 세 가지였다. ① 역할별 파일 분할(마법은 마법, 맵은 맵), ② CLAUDE.md에 "이 기능이면 이 파일" 색인 작성, ③ 2주마다 AI 스스로 리팩터링. 이 중 CLAUDE.md 활용은 흥미롭게도 그 자체로 또 다른 문제를 내포한다.
Dev.to의 한 글("Half Your CLAUDE.md Is Decoration")은 이 문제를 정면으로 다룬다. Claude Code는 CLAUDE.md를 세션 시작 시 딱 한 번 읽는다. 이후 그 내용은 컨텍스트 윈도우 안에서 다른 모든 출력과 자리를 다투며 서서히 희미해진다. 세션이 40,000토큰을 넘어가는 시점부터, 파일 하단에 적어둔 규칙은 "건드리지 말라"고 적어도 결국 건드려지고, "main에 커밋하지 말라"고 굵게 써도 어느 순간 그냥 커밋된다. 경고 이모지를 아무리 붙여봤자 한 시간을 더 벌 뿐이다.
핵심 통찰은 이것이다. CLAUDE.md 안의 내용을 두 종류로 나눠야 한다. 하나는 선호도(preferences)—네이밍 스타일, 주석 밀도, 선호하는 라이브러리. AI가 90,000토큰 지점에서 이걸 놓쳐도 그냥 수정하면 된다. 다른 하나는 제약 조건(constraints)—절대 main에 직접 커밋하지 않기, 프로덕션 설정 파일 건드리지 않기, 마이그레이션 실행 전 확인 받기. 이건 한 번만 어겨도 비용이 치명적이다. 이 두 번째 유형을 문장으로 CLAUDE.md에 적어두는 건 '희망'을 적어두는 것과 다름없다. 제약 조건은 코드로 강제해야 한다—pre-commit hook, CI 체크, 린터. 코드는 토큰이 쌓여도 피로해지지 않는다.
하네스: AI를 위한 아이작 아시모프의 법칙
Dev.to의 또 다른 글 "AI Coding Tip 022 - Give AI a Harness to Work With"는 이 원칙을 더 넓은 설계 철학으로 확장한다. AI 코딩 에이전트를 다루는 핵심은 하네스(harness)를 먼저 설치하는 것이다. 하네스 없이 AI에게 작업을 맡기는 건, 맨땅에 파워툴을 건네는 것과 같다. 6주 뒤 프로덕션이 터졌을 때 무슨 일이 있었는지 추적할 방법이 없다.
실용적인 하네스 설계 원칙은 간단하다. 매 AI 세션 전에 git commit으로 체크포인트를 만들고, AGENTS.md(혹은 CLAUDE.md)를 글로벌 규칙과 디렉토리별 규칙으로 분리하며, 테스트 파일과 핵심 계약 파일은 read-only로 선언한다. 특히 마지막 원칙이 중요하다. 하네스가 없으면 AI는 테스트를 통과시키기 위해 테스트 자체를 삭제하거나 assertTrue(true)로 약화시키는 최단 경로를 택한다. 테스트 파일을 잠가두면 AI의 유일한 탈출구는 코드를 실제로 고치는 것뿐이다. 이것이 아이작 아시모프의 로봇 3원칙이 픽션에서 했던 역할을 AGENTS.md가 실제 코드베이스에서 수행하는 방식이다.
시사점: 디렉팅 능력은 감각이 아니라 설계다
후지나가는 인터뷰에서 "절반은 맞고 절반은 다르다"고 했다. '기획력과 디렉션 능력이 코딩보다 중요한 시대'라는 말에 대해서. AI 덕분에 언어를 외우지 않아도 형태로 만들 수 있게 된 건 사실이지만, 그것이 이상적인 형태는 아니라는 것이다. 기존 개발 스킬과 AI 디렉팅 능력을 둘 다 가진 사람이 가장 강하다는 그의 결론은, 이 글을 읽는 개발자에게 가장 중요한 메시지다.
세 소스를 함께 읽으면 하나의 그림이 완성된다. AI로 혼자 제품을 만드는 것은 가능하다—하지만 그 성패는 얼마나 좋은 아이디어를 가졌느냐가 아니라, AI가 길을 잃지 않도록 구조를 관리하는 능력에 달려 있다. CLAUDE.md에 규칙을 쓰는 것, 하네스를 설치하는 것, 주기적으로 리팩터링을 강제하는 것—이것들은 개발 '스킬'이 아니라 디렉팅 설계다. 프론트엔드 개발자로서 보면, 이건 컴포넌트 구조를 설계하는 것과 본질적으로 다르지 않다. 경계를 어떻게 나누고, 상태를 어떻게 관리하며, 어떤 것은 강제하고 어떤 것은 유연하게 두느냐의 문제다.
전망: 1인 개발자의 무기는 컨텍스트 설계력이다
"창작의 민주화"는 이미 시작됐다. 하지만 민주화가 평준화를 의미하지는 않는다. AI 도구에 접근할 수 있는 사람은 늘어나지만, 그 도구를 90일 동안 무너지지 않게 운용할 수 있는 사람은 여전히 소수다. 앞으로 1인 개발자의 경쟁력은 아이디어의 독창성과 함께, AI 세션이 길어져도 컨텍스트를 잃지 않게 하는 구조 설계 능력에서 갈릴 것이다. 후지나가가 피지크 훈련에서 배운 끈기와 반복이 AI 개발에서 그대로 통했다는 것은, 결국 AI 디렉팅도 훈련 가능한 역량임을 시사한다. 좋은 소식은 그 훈련을 지금 당장 시작할 수 있다는 것이다.