Originally published at moday.me . Building MODAY in public. 내가 Claude Code를 사용하는 방법: 정리하지 않고, 위임하며, 즉흥적으로 진행하기. 이제 지난 시간을 되돌아보며 내가 Claude Code를 어떻게 사용하는지 이야기할 차례입니다. 지금까지 MODAY를 구축하는 과정에 대해 꽤 많이 작성했지만, 내부적으로 Claude Code를 어떻게 다루는지에 대해서는 아직 이야기하지 않았습니다. 스택(Stack)을 어떻게 선택했는지, 게시 파이프라인(Pipeline)을 어떻게 구축했는지, 블로그를 9개 언어로 어떻게 현지화했는지, 15분 만에 챗봇을 어떻게 넣었는지 — 이 모든 것들은 무엇을 만들었는지에 대한 측면이었습니다. 이제 상점이 문을 열고 운영 단계에 진입했으니, 한 단계 올라가 메타(Meta)적인 부분을 작성할 차례입니다. 결론을 미리 말씀드리자면: 저는 정리하지 않고, 위임하며, 즉흥적으로 진행합니다. 아마 시중에 돌아다니는 대부분의 Claude Code 가이드와는 반대 방향일 것입니다.

CLAUDE.md는 Claude가 작성했습니다
보통 권장되는 방식은 다음과 같습니다: "프로젝트 정보를 CLAUDE.md에 정리하세요". 브랜드, 기술 스택(Stack), 코드 컨벤션(Conventions), 우선순위 등을 말이죠. Claude Code가 파악할 수 있도록 인간이 컨텍스트(Context)를 잘 정리해 두라는 것입니다. 거기까지가 표준 매뉴얼입니다. 하지만 MODAY의 CLAUDE.md에는 제가 직접 쓴 문장이 단 한 줄도 없습니다. 그 안에 정확히 무엇이 들어있는지도 모릅니다. 프로젝트 초기에 저는 Claude Code에게 "파일들을 네가 원하는 대로 직접 정리해"라고 말했고, Claude는 브랜드 정보, 스택, SKU 테이블, Markets 설정, 단계별 우선순위 등을 스스로 수집하기 시작했습니다. 훑어보면, 아마 제가 수동으로 작성했을 때보다 Claude가 읽기에 훨씬 더 가독성 좋은 형식으로 되어 있을 것입니다. 처음부터 끝까지 저는 정리 작업을 단 한 번도 수행하지 않았습니다. 정리라는 작업 자체를 Claude에게 맡겼습니다.

세션은 "감

저는 세션을 역할(예: "번역 세션", "코드 세션")에 따라 나누지 않습니다. 대신 워크플로우 (workflow)에 따라 나눕니다. 다소 지저분한 방식이지만, 그 결과로 사고의 흐름이 하나로 이어집니다. 화면을 수정하다가 "잠깐, 이걸 바꾸면 번역도 조정하는 게 좋겠는데"라는 생각이 들면, 그 즉시 동일한 세션에서 번역 작업을 시작합니다. 세션 간에 컨텍스트 (context)를 옮기는 비용이 제로에 가깝기 때문에, 의사결정의 흐름이 끊기지 않습니다. 놀랍게도 이 점이 큰 차이를 만듭니다.

기술적 지침은 거의 없습니다. 다른 포스트에서도 언급했듯이, 스택 (stack)을 선택할 때 기술적인 조건은 단 하나도 제시하지 않았습니다. 오직 비즈니스 조건만 제시했습니다. 구현 단계에 들어서서도 이 태도는 변하지 않았습니다. 제가 의식적으로 전달하는 유일한 사항은 다음과 같습니다: "Shopify와 Gelato를 표준 방식대로 사용하세요. 커스텀 구현 (custom implementation)은 최소한으로 합니다."

저는 이것을 SaaS의 황금률이라고 생각합니다. 장기적으로 가장 안정적인 방법은 공급업체가 예상한 범위 내에서 움직이는 것입니다. 커스텀 (custom)은 단기적으로는 멋져 보이지만, 공급업체가 업데이트를 출시하는 즉시 깨져버립니다. 표준 플로우 (standard flows), 표준 API (standard API), 표준 테마 구조 (standard theme structure). 정말 필요한 경우에만 이 범위를 벗어나야 합니다.

이 단 하나의 지침만으로도 저는 API 호출 방식, 테스트 전략, 에러 핸들링 (error handling), 구현 세부 사항 등 거의 모든 것을 Claude Code의 손에 맡길 수 있습니다. Claude Code가 명확한 설명을 요구할 때면 저는 "당신이 하세요"라고 답합니다. 때때로 Claude Code는 확인을 위해 찾아오기도 합니다. "이 파일의 내용을 보여줄까요?", "이렇게 하면 될까요?", "테스트 코드는 어떻게 작성할까요?". 이 거의 모든 질문에 저는 "당신이 하세요"라고 답합니다. 파일을 보고 싶다면 자신의 도구를 사용하게 하고, 결정을 요구하면 "당신이 결정하세요"라고 돌려줍니다. 실제로 거의 모든 경우에 Claude Code는 스스로 읽고, 스스로 결정하며, 추가적인 개입 없이 구현까지 완료합니다. 이것이 제가 다른 포스트에서 말했던 내용의 실전 버전입니다: "AI 측에 주도권을 주고 싶다." 결정을 되돌려주는 것이 아니라, 결정권을 넘겨주는 것입니다.

결국 제 쪽에는 API로 처리할 수 없는 일들만 남습니다. 은행 계좌, 결제 서비스 제공업체(payment provider) 검토, 서비스 등록, 청구 데이터, API 키 발급 같은 것들 말이죠. 그런 부분은 계약 대상이 사람이기 때문에 제가 직접 움직입니다. 나머지는 Claude가 맡습니다. 저는 Claude Code가 매일 GA4를 감시하며 개선 사항을 제안하도록 만듭니다. 이것은 서비스를 오픈한 후 시작한 새로운 루틴입니다. 매일 Claude Code가 GA4를 모니터링하고 문제 목록과 개선 제안을 뽑아냅니다. 저는 그것을 훑어보고 명백히 방향이 잘못된 것들만 제외합니다. 나머지 60~70%는 그 자리에서 바로 구현하도록 명령합니다. 제안과 구현 사이에서 제가 하는 유일한 일은 'GO' 또는 'NG'라고 말하는 것뿐입니다. 코드를 작성하거나 설계를 고민하는 일은 사실상 제로(zero)에 가깝습니다. 저는 이것을 하나의 운영 개념으로 만들고 싶습니다: "최소 하루에 한 가지 개선 사항을 구현한다". 상점이 문을 연 순간부터, 매일 어제보다 조금이라도 더 나은 무언가가 있게 만드는 것입니다. 개선 루프(improvement loop)가 멈추지 않는 브랜드는 장기적으로 결국 승리합니다. 그것이 저의 베팅입니다. 그리고 그 개선 루프의 99%는 Claude Code가 움직입니다.

정리하지 않지만, 정리되어 있다
이 시점에 와서 다시 한번 생각합니다. 저는 '전통적인 개발 매뉴얼'의 거의 모든 것, 즉 정리, 설계, 계획을 거의 하지 않습니다. 제가 직접 작성한 CLAUDE.md 파일도 없습니다. 세션은 그때그때 상황에 따라 진행됩니다. 워크플로우(workflow)가 정형화된 루틴으로 변환되어 있지도 않습니다. 명시적인 기술 설계(technical design)도, 작업 관리 도구도 없습니다. 그런데도 구축부터 운영에 이르기까지 모든 것이 매끄럽게 돌아갑니다. 정확히 말하자면, 저는 조직화(organization)를 Claude 측에 위임했습니다. 저는 하지 않지만, Claude Code는 합니다. 그래서 부수적인 효과로 '정리된' 상태가 유지됩니다. 이 구조는 손정의(Masayoshi Son, SoftBank 창립자)가 "해봅시다"라고 말하면, 매우 유능한 실행 팀이 달려들어 모든 것을 조직하고 구현하는 모습과 상당히 닮아 있습니다.

저는 «해봅시다»의 입장에 머물며, 실행 팀은 AI가 맡습니다. AI 시대에는 혼자서도 그러한 구조를 재현할 수 있습니다. 이것이 지난 3주 동안 제가 느낀 가장 큰 감각입니다. 결론적으로, 이것이 유일한 정답이라고 생각하지는 않습니다. 물론 전통적인 방식—CLAUDE.md를 잘 작성하고, 목적에 따라 세션을 분리하며, 워크플로우를 루틴으로 만드는 방식—도 분명 효과가 있을 것입니다. 하지만 저의 경우, 정리하지 않는 것이 더 빨랐습니다. 만약 정리하는 데 쓸 여유 시간이 생긴다면, 저는 그 시간을 Claude Code에 무언가를 던져주고 그것이 되돌려주는 결과물에 대해 결정하는 데 쓰는 것을 선호합니다. 계속해서 소식을 전해드리겠습니다. — Yoskee moday.me

하루를 시작하세요. — MODAY 티셔츠
세트 구성 | 가격
일주일 전체 → 월–일 (7) $159
평일 업무 → 월–금 (5) $119
스타터 패키지 → 월 · 수 · 금 (3) $79
주말 → 토 · 일 (2) $55
$99 이상 구매 시 무료 배송 · 8가지 색상 × 6가지 사이즈 · 9개 언어