본문으로 건너뛰기

© 2026 Molayo

Zenn헤드라인2026. 06. 10. 08:16

【전편】Claude Opus 4.8로 생각하고, Sonnet 4.6으로 쓰게 하기 ── CLAUDE.md에 「AI를 위한 규칙」을 두어

요약

Claude Desktop(Opus 4.8)을 설계 참모로, Claude Code(Sonnet 4.6)를 구현 실행자로 분리하여 활용하는 효율적인 AI 개발 워크플로우를 소개합니다. 인간의 역할을 코딩에서 AI를 위한 규칙(CLAUDE.md) 작성으로 전환하는 전략을 다룹니다.

핵심 포인트

  • Opus 4.8은 복잡한 아키텍처 설계와 추론 담당
  • Sonnet 4.6은 고속 파일 수정 및 실제 구현 담당
  • CLAUDE.md와 docs/를 활용한 AI 전용 규칙 설정 중요
  • 인간의 업무는 코딩에서 AI 가이드라인 작성으로 변화

지방에서 독립계 시스템 아키텍트(System Architect)로 활동하고 있는, 다이콘(H.I. MET Architect)입니다. 본업으로는 병원 내 SE로서 의료 DX를 추진하면서, 부업으로는 업무 통합 기반 「Weaver」의 사업 전개나 모바일 앱 개발을 하고 있습니다.

최근, Claude Code를 완전히 활용하고 있습니다. 어느 정도로 활용하고 있느냐 하면, 저의 주요 업무가 「AI에게 전달할 규칙을 생각하는 것」과 「YES라고 대답하는 것」 두 가지로 수렴되고 있을 정도입니다. 손은 커피 잔을 받치기 위해 아껴두고 있습니다.

…그렇다고 해서, 그냥 통째로 맡겨서 잘 되고 있는 것은 아닙니다. AI가 기분 좋게 일하게 하기 위해, 인간 측에서 하고 있는 것이 두 가지만 있습니다.

  • 두 개의 Claude ( Claude DesktopClaude Code)를 역할에 따라 구분해서 사용하기 -
  • CLAUDE.mddocs/에 「AI를 위한 규칙」을 작성하기

전편인 이 기사에서는 이 두 가지를 해설합니다. 「정말로 폭주를 막는 설정(권한·훅 (Hook))」은 후편에서 다룹니다.

모델 구성 메모: Claude Desktop 측에서는 Claude Opus 4.8, Claude Code 측에서는 Claude Sonnet 4.6을 사용하고 있습니다.

파트너는 두 명. 「설계 담당 (Opus 4.8)」과 「구현 담당 (Sonnet 4.6)」

저는 Claude를 "두 명 고용했다"는 이미지로 개발하고 있습니다.

  • Claude Desktop (Opus 4.8) = 참모
    Anthropic 최고봉의 추론 모델. 복잡한 아키텍처 판단·요건 정리·기술 선정·브레인스토밍(Wall-hitting)과 같은 「깊게 생각하는」 업무를 맡깁니다. 여기서는 코드를 완성하지 않습니다. 방침을 굳히는 데 전념하게 합니다.
  • Claude Code (Sonnet 4.6) = 현장 감독
    고속이며 비용 효율이 뛰어난 구현 스페셜리스트. Desktop에서 굳힌 방침을 전달하여, 파일을 가로질러 직접 움직이게 하는 실행 부대입니다.

왜 나누는가. 이유는 간단합니다, 모델의 "특기"가 다르기 때문입니다. Opus 4.8은 깊은 추론과 전체적인 조립에서 압도적이지만, 수십 개의 파일을 다시 쓰는 단순 구현에는 오버스펙(Over-spec) 기미가 있습니다. Sonnet 4.6은 코드 생성·파일 가로지르기를 폭속으로 해내며, 장시간의 자율 구현에도 강합니다. 「최강의 두뇌는 생각하는 쪽으로, 끈기 있는 실행력은 구현하는 쪽으로」 —— 이것이 모델 분할의 왕도입니다. 회사에서도 설계가 가장 뛰어난 사람에게 하루 종일 복사 붙여넣기를 시키지는 않으니까요 (웃음).

관점Claude Desktop (Opus 4.8)Claude Code (Sonnet 4.6)
역할참모·생각하는 담당현장 감독·구현자
...

요령은, Desktop에서 굳힌 방침을 거의 그대로 Claude Code를 위한 "발주서"로 만드는 것입니다. 그리고 인간은 소모되기 쉬운 구현 작업이 아니라, 판단에 체력을 쓸 수 있습니다. 이것이 은근히 효과적입니다.

인간에게 남은 유일한 업무는 「규칙 만들기」

AI 주도 개발(AI-driven development)이 진행될수록, 인간의 업무는 「코드를 쓰는 것」에서 「AI에게 부과할 규칙을 만드는 것」으로 옮겨갑니다. 어떻게 움직여 주길 바라는지, 무엇을 해서는 안 되는지를 말로 표현하여 파일에 두는 것. 그것을 쓰는 장소가 CLAUDE.mddocs/입니다.

그도 그럴 것이, AI는 무서울 정도로 우수한 신입사원입니다. 너무 우수해서 그대로 두면 「좋은 의도로」 요청하지도 않은 개수까지 해버리기도 합니다. 악의는 1밀리그램도 없습니다. 그렇기 때문에 일을 시작하기 전에 규칙을 건네줄 필요가 있는 것입니다.

규칙은 두 종류. 파일을 나누어 둔다

AI에게 전달할 규칙은 크게 두 종류가 있습니다.

  • 어떤 프로젝트에서도 공통된 「작업 규칙」 (결론부터 쓰기, 마음대로 변경하지 않기 등)
  • 그 프로젝트 고유의 「정보」 (기술 스택, 커맨드, 명명 규칙 등)

이 두 가지를 별개의 파일로 만들어 docs/ 폴더에 둡니다. 나누는 이유는 간단합니다, 공통 규칙 파일은 다른 프로젝트에 복사하는 것만으로 재사용할 수 있기 때문입니다.

your-project/
├── CLAUDE.md # Claude Code가 매번 가장 먼저 읽는 파일
└── docs/
...

CLAUDE.md 본체는 얇게 유지하고, 위의 두 파일을 읽게 하기만 합니다. 작성법은 이것뿐입니다.

CLAUDE.md(프로젝트 직하단)

@docs/working-agreement.md
@docs/project-context.md

선두의 @

는 Claude Code에게 "이 파일도 함께 읽어줘"라고 전달하는 방식입니다. 이를 통해 매 세션마다 두 개의 규칙 파일이 자동으로 읽힙니다.

보충: 동일한 작업 규칙을 모든 프로젝트에 일괄 적용하고 싶다면, 홈 폴더의

~/.claude/

에 두는 방법도 있습니다. 하지만 우선은 "프로젝트마다 docs/에" 두는 것만으로도 충분합니다.

docs/working-agreement.md ── 공통 작업 규칙

이것이 제가 어떤 프로젝트에도 가져가는 "작업 규칙"의 핵심입니다. 포인트는 전부 다 집어넣지 않는 것입니다. 정말 효과가 있는 행만 남깁니다.

# General Working Agreement(범용 규칙)
## Response behavior(응답 습관)
- 결론부터 작성한다. 서두의 미사여구("알겠습니다", "물론입니다" 등)는 금지.
...

각 블록의 의도는 다음과 같습니다.

  • "자신이 없다면 그렇게 말하기": AI의 "완벽합니다!"는 인간의 "아마 괜찮을 거예요"보다 더 방심할 수 없습니다(웃음). 불확실함을 불확실하다고 말하게 하는 것만으로도 할루시네이션 (Hallucination) 피해를 상당히 줄일 수 있습니다.
  • "2~3개 안을 제시하고 기다리기": 갑자기 50개의 파일을 다 고쳐놓은 뒤에 "아니, 그게 아니야"라고 하게 되는 상황이 가장 괴롭습니다. 선택 단계를 한 번 거치는 것만으로도 재작업이 급격히 줄어듭니다.
  • "요청한 것만 변경하기": AI는 친절한 마음으로 요청하지도 않은 "덤으로 개선하기"를 하기 쉽습니다. 선의의 폭주를 첫 번째 줄에서 막습니다.

⚠️ 단, 중요한 전제:

Claude는 이것을 "절대적인 규칙"이 아니라 "문맥 (Context)"으로 취급합니다. 따라서 위의 HARD STOP도 이것"만"으로는 정말로 멈추지 않습니다. CLAUDE.md는 "지시"일 뿐이며, 그 자체로 강제력을 갖지는 않습니다. 물리적으로 멈추는 방법은 후편에서 자세히 다루겠습니다.

docs/project-context.md ── 프로젝트 고유 정보 (Weaver 사례)

"고유 정보에 무엇을 적어야 할까?"라는 이미지가 떠오를 수 있도록, 저의 업무 통합 기반인 Weaver (Redmine + Mattermost + Docker + Cloudflare Tunnel 구성)에서도 사용할 수 있는 구체적인 기술 내용을 첨부합니다.

# Project Context(Weaver — 업무 통합 기반)
## 기술 스택
- Redmine 5.x(태스크·간트 차트·스케줄 관리)
...

이렇게만 적어두면, "이 서비스를 재시작해줘" 또는 "이 스키마를 바꾸고 싶어"라고 요청할 때 매번 처음부터 설명할 필요가 없어집니다.

개발 중: 저는 대개 "YES"를 누르고 있습니다

  • **Desktop (Opus 4.8)**과 대화하며 방침을 확정한다.
  • 확정된 방침을 **Claude Code (Sonnet 4.6)**에 발주한다 (docs/가 토대이므로 지시는 최소한으로).
  • Code가 구현하고, diff와 테스트 결과와 함께 "이건 어떠신가요?"라고 답해온다.
  • 저는 그것을 살펴보고 "좋네"라고 승인한다 (= "YES"라고 답한다).

저의 주요 업무는 커피를 내리는 것과, 올라온 diff를 보고 "좋네"라고 고개를 끄덕이는 것——이라는 말은 절반은 농담입니다만, 인간의 에너지를 "구현하는 수작업"이 아니라 "판단과 규칙 만들기"에 전부 쏟을 수 있다는 점이 이 체제의 가장 큰 장점입니다. 손이 피로하지 않은 방식은 오래 지속할 수 있는 방식이기도 합니다 (이 부분은 꽤 진심으로 중요하게 생각하고 있습니다).

마지막으로

"코드를 빠르게 작성할 수 있는" 가치는 앞으로 점점 상대적으로 낮아질 것이라고 생각합니다. 대신 올라가는 것은, AI에게 어떤 규칙을 부여할 것인가를 결정하는 능력입니다. CLAUDE.mddocs/는 그 "규칙 만들기"를 파일로 옮겨 적는 연습장 같은 것입니다.

이 "규칙을 정하고 AI에게 맡기는" 방식은 제가 개발하고 있는 업무 통합 기반 Weaver를 만드는 방식 그 자체이기도 합니다. 지방의 시스템 아키텍트로서, 앞으로도 "규칙으로 AI를 길들이는" 지견을 계속해서 발신하겠습니다.

▶ 후편 「Claude Code의 폭주를 물리적으로 멈추기 ── settings.json의 권한과 후크」로 이어집니다.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0