클로드 코드와 정말로 제품을 만들 수 있을까?

저는 최근 3개월동안 클로드 코드를 사용하여 AI 이미지 생성앱인 NanaChan AI를 만들었습니다.

처음엔 시행착오도 많았지만 마지막에는 4만줄이 넘는 코드베이스에서도 기능을 안정적으로 만들고 배포할 수 있게 되었습니다.

이 과정에서 얻게된 인사이트를 공유하고자 합니다.

NanaChan AI 소개

NanaChan AI는 제가 엄선한 프롬프트를 텍스트형태가 아닌, GUI의 옵션 형식으로 조합하여 이미지를 만들어내는 이미지 to 이미지 생성 앱입니다. API로는 구글의 나노바나나 모델을 사용하고 있죠.

앱은 각각 앱스토어 와 구글플레이에서 받아보실 수 있습니다.

다른 일을 병행하면서 진행해서, 초기 버전 출시까지는 총 2개월 정도 소모되었습니다.

이 프로젝트는 아래 규모에서 Claude Code (Max 플랜 $100)를 사용하여 1인 개발로 진행되었습니다.

프로젝트 통계

기술 스택

• Frontend: React Native 0.81.4 + TypeScript 5.8.3
• Backend: Supabase (PostgreSQL + Edge Functions)
• AI: Google Gemini API
• Monetization: Google Mobile Ads + IAP
• State Management: Zustand
• Navigation: React Navigation
• Localization: i18next (한국어 우선)

클로드 코드는 굉장히 멋지게 작동했다. 적어도 처음에는..

최초에 프롬프트가 있었다.

프로젝트는 다음 하나의 프롬프트로 시작되었습니다.

"Gemini API를 사용하여 사용자가 선택한 이미지를 피규어 이미지로 만들어주는 앱을 만들거야. 프롬프트는 ~한 프롬프트를 사용할거고, 안드로이드와 애플 모두에서 작동하는 앱으로 만들거야. 모던하고 심플한 디자인의 앱으로 프로토타입을 만들어줘"

Opus는 멋지게 작업을 시작했습니다. 몇가지 질답을 한 이후에 스스로 React Native 개발 환경을 세팅하고, 곧 실제로 "작동하는" 그럴싸한 프로토타입을 실행했습니다.

디자인은 기대했던 그런 디자인은 아니었지만 꽤 그럴듯하게 실행되었습니다. 몇 가지 버그가 있어 클로드와 몇 번 에러로그를 주고받은 이후에 초기 요구사항을 만족하는 프로토타입의 실행이 성공했습니다.

실제로도 이정도가 되는구나!를 느낀 이후, 저는 본격적인 프로젝트 개발에 들어가려고 했습니다.

하지만 그전에 기능 몇 가지를 더 수정하려고 했습니다.

처음에는 디자인을 좀 더 개선해보고 싶었습니다. "모던하고, 심플하게"는 너무 추상적이었고 실제 나온 결과물은 어딘가 스캠처럼 보이는 애플리케이션이었죠.

그래서 저는 클로드에게 명령했습니다.

"우리 앱의 디자인을 개선해야한다. VSCO와 같이 깔끔하고 심플한 디자인을 달성해야해. VSCO에서 영감을 받은 5색 미만의 색 구성을 사용하는 디자인 원칙을 만들어서 제품에 적용해줘"

You're absolutely right!

그러자 또다시 클로드는 분주하게 움직이기 시작했습니다.

하지만 어째서인지 이전에 개발하던 내용들은 잊은듯이 컴포넌트를 이상한 방법으로 건드리고, 마치 처음 보는 프로젝트인냥 코드를 수정하기 시작했죠.

그 뿐만이 아니라 비지니스 모델 분석을 진행한 이후에도, 실제 작업을 이어나가다보면 하나의 세션임에도 이전의 내용들을 완전히 잊어버린듯한 코드를 작성하기도 부지기수였습니다.

저는 이전에 우리가 했던 결정을 왜 기억하지 못하냐고 하며, 어디가 어떻게 잘못되었는지 지적했고, 그럴 때 마다 클로드는 You're absolutely right!을 뱉어내면서 마치 단기기억상실증에 걸린 개발자처럼 눈앞의 수정사항만 어떻게든 떼우는식으로 행동하기 일수였습니다.

어떤 수정사항이 생기든지, 어떤 요구사항이 생기든지 클로드는 프로젝트의 방향성, 계획, 의도와는 상관없이 You're absolutely right! 을 남발하며 무조건적으로 저를 긍정하였고 이는 곧 개발 생산성의 저하와도 직결되었습니다.

문제는 거기서 그치지 않았습니다. 아무리 claude.md 에 무조건적인 긍정을 금지하여도 대화가 몇 번 이어지고나면 그런 지시사항 뿐 아니라 다른 모든 지시사항도 무시하게 되었다는거죠.

저는 제가 모든 코드를 검수하고 동작을 확인해야만 하는 단계에 이르러서야 한 가지 중요한 깨달음을 얻게되었습니다.

컨텍스트로부터 배운 내용은 컨텍스트가 오염되면 결국 사라질수밖에 없다는 사실을 말입니다.

모든 것은 컨텍스트 관리

결국 문제는 길어지는 세션과 그에따라 오염되는 컨텍스트였습니다. 최초에는 하나의 세션에서 대화하는 모든 중요한 내용들을 클로드가 기억해줄것이라 생각했지만, 클로드가 한 세션에 가질 수 있는 컨텍스트 양에는 한계가 있었습니다.

컨텍스트 윈도우의 최대 길이는 200k token (약 500페이지 분량의 텍스트) 참고: https://support.claude.com/en/articles/8606394-how-large-is-the-context-window-on-paid-claude-plans

세션이 오래 지속되게되면 컨텍스트는 금방 고갈되고, 세션을 이어가기 위해 클로드 코드는 auto compaction을 실행합니다. 이 과정에서 필요한 정보들이 날아가면서 클로드는 마치 새로운 세션을 시작한 것 처럼 "바보같이" 작동하기도 합니다.

클로드가 원하는바를 제대로 실행하기를 원한다면 한정적인 컨텍스트를 최대한 잘 활용해야 했습니다.

컨텍스트를 효율적으로 다루기 위해서 다음의 전략들을 사용했고 결과는 상당히 만족스러웠습니다.

• claude.md의 개선
• 외부 메모리를 활용하기
• 서브에이전트 활용하기
• 매니저패턴 사용
• 단일작업 단일세션 원칙 적용

1. CLAUDE.md의 효율적인 작성

최초 claude.md 에는 여러가지 내용들이 종합적으로 들어가 있었습니다.

클로드가 어떻게 행동해야 하는지, 워크플로우를 포함한 작업 방식과 프로젝트 목표를 포함한 프로젝트 개요, 프로젝트 구조와 테크스팩, 그리고 예제 코드를 포함한 좋은예와 나쁜예 까지...

/init을 사용해 만든 claude.md에다가 정말 많은것을 claude를 시켜 작성했고, 그 결과 컨텍스트의 소진은 두말할것도 없고 어떤 정보가 클로드가 행동함에 있어서 정말 중요한 정보인지 알 수 없게되어 자주 무시되게 되었습니다.

claude.md를 완전히 재작성 했습니다. 이모지나 각종 형식적인 것들은 모두 제거하고, 주요 행동원칙과 관련된 간략한 내용으로 다시 정리했습니다.

예를들어서 프로젝트 구조나 테크스펙등은 클로드가 어떻게 행동해야 하는지에 대해서 설명하는 내용들이 아닙니다.

• 클로드가 이 프로젝트에서 해야 하는 역할
  • CEO(유저)에게 작업을 보고하는 매니저
• 클로드가 이 프로젝트에서 해야 하는 행동
  • 객관적이면서도 제품위주의 관점에서 요청을 비평적으로 처리 (No you're absolutely right)
  • 툴이 필요한 모든 작업은 직접 하지 않고 적절한 서브에이전트에게 위임하기 (컨텍스트 절약) 등등

대신 그동안 claude.md 내부에 존재하던 테크스펙, 프로젝트 워크플로, 그 외 프로젝트 진행에 필요한 부차적인 내용들은 외부의 문서로 분리하여 링크만 제공하고 필요시에 읽도록 하였습니다.

그 외에도 별도로 프로젝트의 구조와 진척도를 판단하여 바로 스프린트 작업으로 뛰어들 수 있도록 준비하는 /ready 커맨드를 만들어서 각 세션 시작전에 실행하였습니다.

이런 방식으로 claude.md에 적혀진 원칙은 최대한 지켜지면서도 불필요한 컨텍스트를 미리 로드하지 않아 답변의 일관성과 품질이 향상되었습니다.

2. 외부 메모리에 저장하기

클로드가 컨텍스트에서 배운것은 그 컨텍스트 안에서만 유효합니다. 세션이 끝나고 컨텍스트가 사라져도 사라지고, 컨텍스트가 길어지면서 compact등을 통해 컨텍스트 오염이 일어나면 더이상 유효한 지식이 아니게 됩니다.

세션간의 작업의 연속성을 보존하면서도, 클로드가 배운 내용들을 기억하게 하기위해 외부 메모리를 적극적으로 사용하였습니다.

클로드와 작업하면서 클로드와 함께 결정하거나 작업한 내역을 마크다운 파일로 저장하도록 했습니다. 작업 목록과 프로젝트에 대한 설명, 비지니스 모델 등등 프로젝트 진행에 필요한 모든 것들을 외부에 저장하고, 필요한 시점에 이를 불러서 쓰도록 했습니다.

특히 sprint단위의 작업목록을 관리하여 현재 해야하는 일들이 어떤 것들인지 나침반으로 삼을 수 있게 하여 작업의 연속성을 보장하였습니다.

다음은 NanaChan AI의 claude 폴더 구조입니다

.claude/
├── CLAUDE.md                    # 핵심 규칙 (항상 로드됨)
├── commands/                    # 커스텀 커맨드 (초기화 커맨드 포함)
├── archive/                     # 더이상 사용하지않게 된 문서들
├── skills/                      # 스킬들
├── spec/                        # 스펙 문서 (진실의 원천)
│   ├── feature/                 # 기능별 명세
│   ├── api/                     # Edge Function API 명세
│   ├── business/                # 비지니스 모델과 리서치
│   └── schema/                  # DB 스키마 명세
├── work/
│   ├── backlog/
│   ├── roadmap/                 # 분기별 로드맵
│   └── sprints/
│       ├── archive/             # 종료된 스프린트들의 보관
│       └── current/
│           ├── sprint.md        # 현재 스프린트 목표와 상태
│           └── tasks/           # 개별 태스크 파일
└── agents/                      # 서브에이전트 정의

예를 들어 "출석 체크 기능"을 구현한다면, 먼저 spec/feature/attendance/ 폴더에 기능 명세를 "직접" 작성합니다. UI 요구사항, 비즈니스 로직, 엣지 케이스, 그리고 가능하다면 코드레벨의 구현 방법까지 기술합니다.

그 다음은 클로드에게 스프린트에 "출석체크" 기능을 추가하도록 일정을 할당하게 합니다. 클로드는 work/sprints/current/tasks/t4-daily-attendance.md에 태스크의 상태와 진행 상황을 기록합니다.

그리고 개발이 진행되는동안 메인 에이전트와 서브에이전트는 스펙 문서를 참고하여 작업을 진행하게 됩니다.

이렇게되면 다음과 같은 이득이있습니다.

1. 새 세션을 시작해도 이전 세션의 작업내역이 모두 체크되고 있기 때문에 이어서 작업을 진행할 수 있습니다.
2. 서브에이전트들은 모두 공통된 스펙문서를 보고서 작업을 진행하므로 작업의 결과물도 의도와 크게 달라지지 않습니다.
3. 작업간의 영향도를 판단하고 병렬로 작업들을 진행할 수 있게 됩니다.

마치 인간 개발자가 JIRA 티켓과 위키 문서를 보고 작업하는 것과 같습니다.

하지만 굳이 JIRA나 notion과 같은 툴을 쓸 이유는 없습니다. 프로젝트는 저와 클로드가 1:1로 진행하고, 진척도 관리도 클로드를 위한 것에 더 가깝기 때문에 정해진 템플릿에 맞춰서 로컬에 작업 내역을 관리하는것이 비용면에서도, 접근속도면에서도 훨씬 유리하기 때문이죠.

3. 서브에이전트 사용하기

외부 메모리로 컨텍스트에서 배운 것들을 보존하는데는 성공했지만, 이것만으로 컨텍스트를 아끼는것은 여전히 부족했습니다. 문제는 하나의 클로드가 모든 것을 하려고 할 때 발생했습니다.

React Native 코드를 작성하고, Supabase Edge Function을 만들고, 한국어 번역을 하고, 코드 리뷰까지... 하나의 세션에서 이 모든 걸 처리하려니 컨텍스트가 폭발했습니다. 파일 내용을 읽고, 수정하고, 테스트 결과를 확인하는 과정에서 대화창이 끊임없이 길어졌습니다.

그러던 중 클로드 코드의 서브에이전트 기능을 적극적으로 활용해보기로 했습니다. 서브에이전트는 새로운 컨텍스트로 시작하고, 서브에이전트의 컨텍스트는 메인에이전트의 컨텍스트에 남지 않습니다.

우리에게 필요한것은 작업이 어떻게 이루어졌는지에 대한 과정과 결과에 대한 보고입니다.

코드의 수정사항은 PR을 통해 확인할 수 있으므로, 툴 사용과 코드의 변경 내역등은 컨텍스트내에 존재할 필요가 없는 것이죠.

메인 대화의 긴 히스토리를 가져가지 않고, 해당 작업에 필요한 정보만 전달받아 작업합니다. 그리고 결과만 돌려줍니다. 컨텍스트가 분리되니까 각자의 영역에서 깊이 있는 작업이 가능해졌습니다.

저는 프로젝트에 맞는 전문 에이전트들을 정의했습니다:

Before (메인 클로드가 직접 작업)

나: 출석 체크 기능 만들어줘
클로드: [500줄의 코드 출력]
클로드: [테스트 코드 200줄]
클로드: [한국어 번역 추가]
클로드: [수정 사항 300줄]
→ 컨텍스트 폭발, 이후 작업에서 초기 요구사항 망각

After (서브에이전트 위임)

나: 출석 체크 기능 만들어줘
클로드(Manager): mobile-developer에게 구현을 위임합니다.
[서브에이전트가 별도 컨텍스트에서 작업]
클로드(Manager): 구현 완료. 테스트 12개 통과.
→ 메인 컨텍스트는 깨끗하게 유지

대부분의 서브에이전트는 https://github.com/VoltAgent/awesome-claude-code-subagents 에서 가져와 사용하였습니다. 잘 정의된 서브에이전트 프리셋들이 많아서 적절하게 가져다가 사용하면 프로젝트에 빠르게 적용할 수 있습니다.

4. 매니저 패턴의 적용

서브에이전트를 사용하더라도 일부 작업 결과들이 메인 대화창으로 넘어오는등의 이슈가 있었습니다.

이제 작업내역과 결과 코드변경 그 모든것이 컨텍스트 바깥에 영구적으로 존재하므로 저는 메인대화창에서 그런 변경사항을 확인할 필요가 없어졌습니다.

우리가 실제로 사람들과 일을 할때와 마찬가지로, 클로드가 코드레벨단위의 모든 변경사항보다는 어떤방식으로 처리를 시도했고 어떤 결과가 나왔는지를 보고하길 원했습니다.

그래서 더 급진적인 규칙을 도입했습니다: 메인 클로드는 절대 직접 코드를 작성하지 않고, 툴도 직접 부르지 않는다.

저는 클로드에게 "Manager" 역할을 부여했습니다. CEO(나)에게 보고하는 중간 관리자죠. Manager의 역할은 명확합니다:

CLAUDE.md에 다음 규칙을 명시했습니다:

## Critical Rules (NEVER violate)

1. **NEVER call tools directly** - Always delegate to subagents
   - No code editing (use mobile-developer, backend-developer)
   - No git operations (use general-purpose)
   - No file exploration (use Explore agent)
   - **Exception**: None. Even small tasks must be delegated.

그리고 이제 컨텍스트는 훨씬 간결해져서, 작업단위의 중요한 대화만 남게 되었습니다.

이제 작업지시에는 "구현 완료, 테스트 통과" 라는 심플한 문장이 남았습니다. 컨텍스트가 오염되지 않으니 결과물의 품질도 더욱 일정해지고, 지시사항의 이행도 좀 더 확실해졌습니다.

5. 단일 작업 단일 세션

하지만 결국 위의 모든 노력도 컨텍스트의 총량을 벗어나는 세션길이는 감당할 수 없었습니다.

복잡한 기능을 구현하다 보면 디버깅 과정에서 로그를 확인하고, 테스트를 돌리고... 아무리 Manager 패턴을 써도 작업량 자체가 많으면 결국 컨텍스트 제한에 도달하고 맙니다.

하나의 세션을 오래 지속할 수 없다면, 하나의 세션에서 많은 작업을 하지 않으면 됩니다.

하나의 작업은 최대한 단일 기능구현으로 하면 추후 리버트하기도 편하기 때문에, 다량의 컴포넌트를 새로 제작해야하거나 영향도가 복잡한 작업들은 다시 작업을 쪼갭니다.

한 세션에서 처리하기 좋은 작업:

• 단일 기능 구현
• 버그 수정 1-2개
• 코드 리뷰 1회
• 문서 작성/수정

새 세션을 시작해야 하는 신호:

• 컨텍스트 제한 경고가 울리기 시작함
• 작업 방향이 완전히 바뀜
• 에러가 반복되면서 디버깅이 길어짐
• "아까 말했던 거 기억나?"라고 묻고 싶어질 때

세션의 종료는 작업의 종료를 의미하고, 클로드는 워크플로에 따라서 작업이 끝나면 작업에 대한 결과와 변경사항을 문서에 기록합니다.

결론: 컨텍스트 관리의 여정

2개월간의 여정을 돌아보면, 결국 모든 문제는 컨텍스트 관리로 귀결되었습니다.

클로드 코드는 놀라운 도구입니다. 하지만 그 힘을 온전히 발휘하려면 적절한 구조가 필요합니다. 마치 뛰어난 개발자도 좋은 프로세스 안에서 더 빛나는 것처럼요.

제가 발견한 다섯 가지 전략을 요약하면:

1. 적절한 CLAUDE.md 작성: 간결하게 해야하는 행동만 작성한다
2. 외부 메모리: 스펙, 태스크, 결정 사항을 파일로 저장한다
3. 서브에이전트: 전문 영역별로 작업을 분리해 컨텍스트를 격리한다
4. 매니저 패턴: 메인 클로드는 조율만, 실제 작업은 모두 위임한다
5. 적절한 세션 크기: 한 세션에 욕심내지 말고, 자연스럽게 나눈다

처음에는 단 한줄의 지시사항을 이행시키기위해 수없이 비슷한 지시를 반복하면서 사용량을 고갈시켜 고통스러웠던 시간도 있었습니다.

하지만 점차 컨텍스트를 깨끗하게 유지할 수 있게 되면서 더 큰 코드베이스에서의 코드수정과 개발에도 큰 문제없이 작동할 수 있게 되었고, 마침내는 4만줄 이상의 프로덕션 앱을 만들 수 있게 되었습니다.

단순 4만줄이 아니라 모든 코드를 인간 개발자가 자연스럽게 읽을 수 있고, 유지보수가 가능한 4만줄이라는 점이 정말 의미가 있는 점입니다.

사실 컨텍스트 관리 이외에도 몇 가지 포인트가 더 있습니다.

• 작업 사이클 관리: 플래닝 - 개발 - 리뷰 - PR작성 의 순으로, PR작성까지가 하나의 사이클로 움직이도록 하였습니다. 저의 개입이 필요할정도로 중요한 결정요소가 없다면 저를 부르지 않도록 했습니다.
• Auto compact 끄기: /config 명령어를 사용하여 Auto-compact 를 끌 수 있습니다. Auto compact가 돌게되면 필요한 내용까지 같이 날아갈 수 도 있어서 아에 꺼두고 직접 컨텍스트를 관리합니다. 한계에 달하지 않도록 애초에 작업량을 설정하는것이 중요하지만 한계에 달하면 작업을 종료하고 더 작은 단위의 새 작업으로 다시 시작합니다.
• TDD를 강제하기: 테스트케이스를 먼저 작성하고 거기에 맞춰 코드를 작성하도록 했습니다. 테스트 케이스들을 기준점 삼아서 피드백루프를 돌면서 좀 더 의도한 결과에 맞는 코드를 만들어냅니다.
• 지시는 디테일하면 디테일할 수록 의도대로 나온다: 이미 스펙문서를 통해 이것을 달성하고 있지만, 지시는 자세히 적을수록 그 결과는 의도와 가까워집니다.
• 영어로 지시한다: 한국어로 프롬프트를 작성할 때 보다 영어로 작성할 때가 품질이 더 일관되고 좋았던 경험이 있습니다. 이것은 실제로도 훈련데이터의 불균형과 코드와 언어간의거리등의 요인으로 인해 나타난다고 보고되는 현상이기도 합니다.

부록: 느낀점

이번 프로젝트를 진행하면서 가장 크게 느낀점이 있다면, "LLM을 사용하더라도 결과물은 내가 컨트롤 할 수 있는 범위 이상의 품질로 나올 수 없다" 라는 것입니다.

간혹가다가 한두줄의 수정사항으로 수정이 끝날 수 있는 버그를 고치지 못해서 수십줄의 코드와 새로운 로직을 만들어내는 경우들이 있었습니다. 이 때는 결국 제가 해당 화면에 해당하는 코드들을 확인하고 문제인 부분을 짚어내지 않으면 기존 동작마저 해치는 코드들이 덕지덕지 붙었습니다. 반대로 해당 코드를 짚어내고 수정방향을 제시했을때는 제대로 수정을 진행하였습니다.

또 다른 예로는 리팩토링을 수정하면서 재사용가능한 공통 컴포넌트를 만들라는 지시로인해 십수줄의 서로다른 성격의 props들이 뚫려있는 괴물 컴포넌트를 만들어내기도 했습니다.

결국 다시 세세한 지시를 통해서 단순히 통일된 "공통" 컴포넌트가 아니라 각 카테고리별로 공통 컴포넌트를 "사용한" 개별 컴포넌트로 만드는 식으로 리팩토링을 해야했습니다.

아직까지는 코드단위의 구현 방법과 패턴까지 지시할 수 없다면 지속가능한 프로젝트를 만들기란 조금 힘들지 않을까 싶은 생각이 드는 순간들이었습니다.

그러나 여전히 클로드 코드는 강력한 도구였습니다.

ADHD가 심해서 생각만하고 실행을 하지못해 휘발되는 아이디어들이 많았는데, 클로드 코드덕분에 일단 구현단계까지 끌어줄 수 있어서 흥미가 식기전에 빠르게 프로젝트로 몰입할 수 있게 만들어주었고, 세부적인 구현 방법보다는 서비스의 전체적인 설계와 비지니스 모델에 대해 생각해 볼 수도 있었습니다.

이 글이 여러분의 클로드코드 사용에 작은 도움이 되었으면 좋겠습니다.