님들 쓰는 법 틀렸어요, Anthropic이 직접 말했습니다

Anthropic이 며칠 전에 "Opus 4.6 최대한 활용하기"라는 공식 가이드를 올렸습니다. 근데 이게 그냥 마케팅 글이 아니에요. 읽어보면 Anthropic이 "사용자들이 우리 모델을 잘못 쓰고 있다"고 은근히 말하는 글이거든요.

저는 Claude Code를 매일 씁니다. 회사에서도 Claude로 거의 모든 업무 코드를 짰고, 지금도 하루에 수백 번은 Claude한테 뭔가를 시키고 있어요. 그래서 이 가이드를 보자마자 "아, 이거 진짜 그렇다"고 무릎을 쳤습니다. 제가 경험으로 알고 있던 것들을 Anthropic이 공식적으로 확인해준 느낌이에요.

근데 원문을 그냥 번역하면 재미가 없잖아요. 그래서 오늘은 Anthropic의 공식 가이드를 제 실전 경험으로 재해석해보겠습니다. "아, 이래서 내 결과물이 별로였구나"를 깨닫게 해드릴게요.

AI와 협업하는 새로운 방식

모델이 바뀌었는데, 쓰는 법은 안 바뀌셨죠?

Opus 4.6 업데이트 소식이 나왔을 때, 대부분의 반응은 "오, 더 똑똑해졌네" 정도였어요. 근데 이번 업데이트의 진짜 의미는 "더 똑똑해졌다"가 아닙니다. AI와 협업하는 방식을 바꿔야 한다는 거예요.

솔직히 말할게요. 저도 Claude를 처음 쓸 때는 다른 사람들이랑 비슷했거든요. 프롬프트를 열심히 다듬고, "이거 잊지 마" 리마인더를 달고, 역할극을 시키고. "너는 시니어 개발자야. 10년 경력이야." 이런 거요.

근데 Opus 4.6에서는 이게 전부 역효과예요. 왜냐면 모델 자체가 달라졌거든요. 이전 모델에서 통하던 테크닉이 지금은 오히려 방해가 됩니다.

Anthropic이 공식적으로 말한 Opus 4.6의 변화를 저는 크게 두 가지 관점으로 봤어요:

원문은 5가지로 나누는데, 실전에서는 이 두 관점이 훨씬 직관적이에요. "AI한테 뭘 넣느냐"와 "AI가 뭘 뱉느냐"로 나누면 바로 행동이 바뀌거든요.

입력이 달라졌다 — "반복하지 마세요, 한 번이면 됩니다"

지시를 한 번만 해도 된다는 건 무슨 뜻일까

Anthropic이 제일 먼저 언급한 게 이거예요. "Say it once." 한 번만 말하세요.

이전 모델에서는 중요한 규칙을 세 번, 네 번 반복해야 했어요. "절대 테스트 파일을 수정하지 마. 다시 말하지만 테스트 파일은 건드리지 마. 마지막으로 한 번 더, 테스트 파일 수정 금지." 이런 식으로요. 안 그러면 긴 대화 중간에 슬쩍 테스트 파일을 수정하거든요.

Opus 4.6은 다릅니다. 처음에 한 번 말하면 세션 끝까지 유지해요. Anthropic 표현을 빌리면, "Instructions carry through longer sessions without drifting." 지시가 긴 세션에서도 흐트러지지 않는다는 거예요.

이게 실전에서 뭘 바꾸는지 말씀드릴게요.

제가 Claude Code에서 CLAUDE.md를 쓸 때, 예전에는 같은 규칙을 여러 형태로 반복해서 넣었거든요:

# 예전 CLAUDE.md (중복이 많음)
- 테스트 파일을 수정하지 마라
- /tests/ 디렉토리의 파일은 읽기 전용이다
- 테스트가 실패하면 구현을 고쳐라, 테스트를 고치지 마라
- 절대로 테스트 코드를 삭제하거나 수정하지 마라

네 줄이 전부 같은 말이에요. 근데 예전에는 이래야 했어요. 한 줄만 쓰면 무시당하니까.

지금은 이걸로 충분합니다:

# 지금 CLAUDE.md (간결)
- 테스트 파일(/tests/)은 절대 수정하지 마라

한 줄이면 끝이에요. 그리고 이게 더 좋은 결과를 만들어요.

왜냐하면 CLAUDE.md가 짧을수록 AI가 각 규칙에 더 집중하거든요. 제 강의에서도 이 얘기를 하는데, 컨텍스트 윈도우는 AI의 RAM이에요. 거기에 불필요한 중복을 넣으면 정작 중요한 정보가 밀려나요. Opus 4.6이 지시를 잘 따르게 된 만큼, CLAUDE.md를 더 짧고 핵심적으로 유지하는 게 유리합니다.

의도를 설명하면 규칙보다 강하다

Anthropic이 흥미로운 말을 했어요. "Explain the intent behind your instruction, not just the rule." 규칙만 말하지 말고, 왜 그런 규칙인지를 설명하라는 거예요.

이건 실전에서 엄청난 차이를 만들어요.

예를 들어볼게요:

# 규칙만 쓴 경우
- 함수는 50줄을 넘지 마라

# 의도까지 쓴 경우
- 함수는 50줄을 넘지 마라. 이 프로젝트는 AI 에이전트가 주로 수정하기 때문에,
  파일과 함수가 작아야 AI가 정확한 맥락을 잡을 수 있다.

첫 번째를 주면 AI는 "50줄"이라는 숫자만 지켜요. 49줄짜리 복잡한 함수를 만들어도 규칙은 위반하지 않았다고 생각하죠.

두 번째를 주면 AI는 의도를 이해해요. "아, AI가 읽기 쉬운 코드를 원하는구나." 그래서 50줄이 아니라 20~30줄 수준으로 자연스럽게 쪼개고, 함수 이름도 더 직관적으로 짓고, 모듈 분리도 적극적으로 합니다. 숫자를 지키는 게 아니라 목적을 달성하려고 하는 거예요.

Opus 4.6는 적은 예시에서도 패턴을 잘 파악한다고 Anthropic이 말했어요. 그러니까 규칙 10개를 나열하는 대신, 핵심 의도 3개를 설명하는 게 더 효과적입니다.

맥락을 먼저 읽는다 — 느려진 게 아니라 똑똑해진 거다

Opus 4.6를 쓰다 보면 눈에 띄는 변화가 하나 있어요. 시작이 느려졌다는 거예요. 예전에는 질문하자마자 바로 코드를 뱉었는데, 지금은 파일을 이것저것 읽고 나서야 응답해요.

처음에는 "왜 이렇게 느리지?" 싶었거든요. 근데 Anthropic이 이걸 공식적으로 설명했어요. "Opus 4.6 reads the full picture: file structures, existing patterns, dependencies, how things connect." 변경하기 전에 전체 그림을 먼저 파악한다는 거예요.

이게 왜 중요하냐면요.

제가 현업에서 처음 보는 코드베이스를 AI로 파악할 때, 가장 큰 문제가 "AI가 맥락을 모른 채로 코드를 수정하는 것"이었거든요. 기존 패턴을 모르니까 완전히 다른 스타일의 코드를 만들어내는 거예요. 팀의 컨벤션과 안 맞고, 기존 유틸 함수를 활용하지 않고 새로 만들고.

Opus 4.6는 이걸 스스로 해결합니다. 코드를 수정하기 전에 관련 파일들을 먼저 훑어보고, 기존 패턴을 파악하고, 그에 맞춰서 코드를 작성해요. 사람한테 온보딩이 필요하듯, AI도 온보딩을 하는 거예요. 다만 이전 모델은 온보딩을 안 했고, Opus 4.6는 알아서 합니다.

Anthropic은 이에 맞춰서 "맥락을 미리 제공하라"고 조언해요. "Front-load your context." AI가 이해에 투자하는 만큼, 처음에 좋은 정보를 많이 줄수록 결과가 좋아진다는 거예요.

실전에서 제가 하는 방식은 이거예요:

이 프로젝트의 /src/routes/ 구조를 먼저 파악하고,
기존 API 엔드포인트 패턴을 확인한 다음에,
같은 패턴으로 게시물 삭제 API를 만들어줘.

이렇게 하면 AI가 기존 코드를 참고해서 일관된 스타일로 코드를 작성해요. "게시물 삭제 API 만들어줘"라고만 하면 AI가 나름대로 읽긴 하는데, 방향을 명시해주면 더 정확한 곳을 먼저 읽게 되거든요.

그리고 하나 더. Anthropic이 명시적으로 말한 게 있어요. "Skip the role setting." 역할 설정은 건너뛰라는 거예요. "너는 시니어 개발자야", "10년 경력 전문가처럼 행동해" — 이런 프롬프트가 Opus 4.6에서는 불필요합니다. 모델이 작업과 맥락에서 적절한 전문성 수준을 추론하거든요.

이건 많은 분들이 아직 모르는 부분인 것 같아요. "역할극을 시키면 결과가 좋아진다"는 게 GPT 시절부터 내려온 상식인데, Opus 4.6에서는 해당 안 됩니다. 오히려 역할 설정에 토큰을 쓰는 게 낭비예요.

개발자의 작업 환경

출력이 달라졌다 — "끈기와 주관이 생겼습니다"

포기하지 않는 AI

Opus 4.6의 가장 큰 변화는 끈기예요. Anthropic 표현으로 "Stays persistent on difficult tasks."

이전 모델은 어려운 문제에 부딪히면 빨리 포기했어요. "이건 제가 하기 어렵습니다. 다른 방법을 시도해보시겠어요?" 이런 식으로 물어보거든요. 근데 Opus 4.6는 스스로 여러 접근법을 시도하고, 막히면 다른 경로를 찾아보고, 진짜 안 될 때만 사용자에게 확인을 구해요.

이게 실전에서 무슨 차이를 만드냐면요.

제가 Claude Code로 복잡한 리팩터링을 할 때가 있어요. 파일 10개에 걸쳐 있는 로직을 새로운 구조로 바꾸는 작업이요. 이전 모델로는 이게 거의 불가능했어요. 3~4번째 파일쯤 수정하다가 앞에서 수정한 걸 잊어버리고, 엉뚱한 방향으로 가거든요. 그래서 파일 하나씩 따로 시켜야 했어요.

Opus 4.6는 이걸 한 번에 해요. 10개 파일을 전부 읽고, 의존성을 파악하고, 순서를 정해서 하나씩 수정해 나가요. 중간에 에러가 나면 스스로 디버깅하고요. 처음에 좀 느리지만, 완성도는 확실히 높아졌어요.

근데 여기서 주의할 점이 있어요.

Anthropic이 직접 경고한 건데, "Opus 4.6 can occasionally go beyond what was requested." 요청한 것 이상을 할 수 있다는 거예요. 기능 하나를 시켰는데 관련 파일도 같이 수정하고, 요청하지 않은 추가 파일을 만들기도 해요.

실제로 저도 겪었거든요. "이 API 엔드포인트에 에러 핸들링 추가해줘"라고 했더니, 에러 핸들링만 추가하는 게 아니라 전체 에러 처리 미들웨어를 새로 만들고, 에러 코드 상수 파일도 만들고, 기존 에러 처리도 새 미들웨어로 마이그레이션하더라고요. 의도는 좋은데, 내가 원한 건 그게 아니었거든요.

그래서 Anthropic이 추천하는 건 체크인 포인트를 설정하라는 거예요.

게시물 정렬 기능을 추가해줘.
단, 각 주요 단계 후에 나한테 확인을 받아줘.
두세 가지 이상의 접근법을 시도하기 전에 먼저 물어봐.

이렇게 하면 AI가 폭주하지 않고, 적절한 시점에 "이렇게 진행해도 될까요?"라고 물어와요. 이건 제 강의 Ch3에서 다루는 "탐색 → 설계 → 구현 → 커밋" 워크플로우와도 직결되는 부분이에요. AI가 끈기가 생긴 만큼, 우리가 울타리를 잘 쳐줘야 합니다.

의견을 가진 AI

이 부분이 제가 개인적으로 가장 좋아하는 변화예요. Anthropic 표현으로 "Weighs in more readily." 더 적극적으로 의견을 제시한다는 거예요.

이전 모델은 사용자 말을 무조건 따랐어요. "이 구조로 해줘"라고 하면 "네, 그렇게 하겠습니다"라고 하고 실행했죠. 내가 잘못된 방향으로 가고 있어도요. 유도 질문에도 약했어요. "이거 좋은 방법 맞지?"라고 하면 "네, 좋은 접근입니다"라고 동의해버렸거든요.

Opus 4.6는 아닌 걸 아니라고 말해요. "이 구조보다 이렇게 하는 게 더 나을 것 같은데요"라고 대안을 제시해요. 유도 질문에도 덜 흔들리고, 자기 판단이 있으면 그걸 말해요.

Anthropic 원문에서 이런 표현을 썼어요: "Opus 4.6 is less susceptible to leading questions." 유도 질문에 덜 휘둘린다는 거예요. 이게 왜 중요하냐면, AI를 써서 코드 리뷰를 할 때 진짜 유용하거든요.

예를 들어, 제가 어떤 아키텍처를 설계하고 나서 AI한테 리뷰를 시킨다고 해볼게요.

이전 모델에게: "이 아키텍처 괜찮은 것 같아. 문제 있어?"
→ "네, 잘 설계되었습니다. 몇 가지 작은 개선점만 있습니다..."

Opus 4.6에게: "이 아키텍처 괜찮은 것 같아. 문제 있어?"
→ "이 구조에서 [구체적 문제]가 발생할 수 있습니다. 대안으로..."

이전 모델은 사용자의 프레이밍에 맞춰줬어요. "괜찮은 것 같아"라고 했으니까 "네, 괜찮습니다"에서 시작하는 거죠. Opus 4.6는 그 프레이밍에 덜 영향받고, 실제로 문제가 있으면 짚어줘요.

이걸 활용하는 방법은 간단해요. AI한테 의도적으로 스트레스 테스트를 시키세요.

이 설계의 문제점을 3가지 이상 찾아줘.
내가 놓치고 있는 게 뭐야?
이 접근법이 실패할 수 있는 시나리오를 알려줘.

이전 모델에서는 이렇게 물어봐도 "괜찮아 보입니다만 굳이 찾자면..."이라면서 소극적이었거든요. Opus 4.6는 진짜로 문제를 찾아서 말해줘요.

이건 특히 혼자 개발하는 분들한테 엄청나게 유용해요. 팀이 있으면 동료가 "이거 이상한데?" 해주는데, 혼자 하면 그런 사람이 없잖아요. Opus 4.6가 그 역할을 어느 정도 해줄 수 있게 된 거예요.

근데 여기서도 주의점이 있어요. Anthropic이 말한 것처럼, "How you frame a problem can still influence the response." 프레이밍이 여전히 영향을 준다는 거예요. 완전히 객관적인 건 아닙니다.

그래서 중요한 결정을 리뷰할 때는 중립적으로 물어보세요. "이거 괜찮지?"가 아니라 "이 설계를 평가해줘"라고요. 프레이밍 편향을 최소화하는 거예요.

글쓰기가 좋아졌다는 건 코드에도 적용됩니다

Anthropic이 마지막으로 언급한 게 글쓰기 품질 향상이에요. 근데 이건 "문서를 예쁘게 쓴다"는 수준의 얘기가 아니에요.

코드에 적용하면 이렇습니다:

제 강의 Ch6에서 "PR 수준의 커밋 만들기"를 다루는데, Opus 4.6로는 이게 훨씬 수월해졌어요. AI가 만든 커밋 메시지를 거의 수정 없이 쓸 수 있는 수준이 됐습니다.

그리고 스타일 매칭이 좋아졌다는 것도 중요해요. 기존 코드의 스타일을 파악해서 그에 맞춰 코드를 작성하거든요. 이전에는 AI가 만든 코드가 기존 코드와 스타일이 달라서 "누가 봐도 AI가 짠 코드"였는데, 지금은 기존 코드베이스에 자연스럽게 녹아들어요.

그래서 실전에서 뭘 바꿔야 하나

지금까지 이론적인 얘기를 많이 했는데, 구체적으로 뭘 바꾸면 되는지 정리해볼게요. 제가 Opus 4.6으로 바꾸고 나서 실제로 변경한 것들입니다.

Before/After 비교

지금 당장 할 수 있는 3가지

1. CLAUDE.md를 다이어트시키세요

지금 CLAUDE.md를 열어서, 같은 말을 여러 형태로 반복하는 부분을 찾으세요. 전부 하나로 합치세요. 그리고 각 규칙에 왜 이 규칙이 있는지 한 줄 추가하세요.

# Before
- 테스트 파일을 수정하지 마라
- /tests/ 디렉토리의 파일은 읽기 전용이다
- 테스트가 실패하면 구현을 고쳐라, 테스트를 고치지 마라

# After
- 테스트 파일(/tests/)은 절대 수정하지 마라.
  구현과 검증을 분리해야 AI의 치팅을 방지할 수 있다.

2. 역할 설정 프롬프트를 삭제하세요

시스템 프롬프트나 대화 시작 부분에 "너는 ~야"라는 역할 설정이 있다면, 지우세요. 대신 맥락과 목표를 알려주세요.

# Before
"너는 10년 경력의 시니어 백엔드 개발자야. TypeScript 전문가로서 답해줘."

# After
"이 프로젝트는 SvelteKit + TypeScript 기반이고,
JSON 파일로 데이터를 저장하는 구조야.
기존 API 패턴을 따라서 댓글 기능을 추가해줘."

역할을 알려주는 대신, 프로젝트의 맥락을 알려주세요. Opus 4.6는 맥락에서 적절한 전문성 수준을 알아서 추론합니다.

3. AI한테 반론을 시키세요

다음에 중요한 기술 결정을 할 때, AI한테 동의를 구하지 말고 반론을 요청하세요.

이 아키텍처로 진행하려고 해.
이 접근법의 약점 3가지와 대안을 제시해줘.

Opus 4.6는 이전 모델보다 솔직하게 문제를 지적해요. 혼자 개발할 때 가장 위험한 건 "내가 옳다고 확신하는 것"인데, AI를 반론자로 쓰면 이 위험을 줄일 수 있어요.

코드 리뷰와 검증

Anthropic이 안 말한 것 — 제가 말할게요

공식 가이드에는 없지만, 제가 실전에서 느낀 것들을 추가로 말씀드릴게요.

루프를 인식하세요

Anthropic이 "Recognize looping"이라고 살짝 언급하고 넘어갔는데, 이건 생각보다 자주 일어나는 문제예요.

Opus 4.6는 끈기가 생겼잖아요. 근데 끈기가 생겼다는 건, 같은 실수를 반복하면서도 계속 시도한다는 뜻이기도 해요. 이전 모델은 빨리 포기했는데, Opus 4.6는 같은 방향으로 계속 밀어붙이면서 "이번엔 될 거야"라는 느낌으로 비슷한 시도를 반복하기도 해요.

이걸 인식하는 기준이 있어요. 3번 이상 비슷한 에러가 나면 개입하세요. AI한테 "지금까지 시도한 접근법을 요약해줘"라고 물어보고, 완전히 다른 방향을 제시하세요. AI가 루프에 빠졌을 때 같은 맥락 안에서 알아서 빠져나오는 건 아직 한계가 있어요.

간단한 작업은 오히려 제약을 줘야 한다

Anthropic도 이걸 살짝 언급했어요. "Narrow the scope on simple tasks." 간단한 작업은 범위를 좁히라고요.

Opus 4.6가 맥락을 열심히 파악한다는 건, 간단한 작업에서는 오버킬이 될 수 있다는 뜻이에요. "이 변수명을 바꿔줘"라고 했는데 관련 파일 20개를 전부 읽고 나서야 응답하면, 시간 낭비잖아요.

간단한 작업에서는 이렇게 하세요:

이 파일만 봐. src/utils/format.ts
formatDate 함수의 파라미터 이름을 date에서 timestamp로 바꿔줘.
다른 파일은 건드리지 마.

범위를 명확히 제한하면 AI가 불필요한 탐색을 건너뛰고 바로 실행해요.

모델이 바뀔 때마다 습관을 업데이트하세요

이건 제가 가장 강조하고 싶은 거예요.

AI 모델은 계속 바뀝니다. 3개월 전에 통하던 테크닉이 지금은 안 통하고, 지금 통하는 테크닉이 3개월 후에는 안 통할 수 있어요. "이렇게 하면 AI 결과가 좋아진다"는 고정된 진리가 아니에요. 모델에 따라 달라지는 전략이에요.

그래서 제 강의에서도 특정 프롬프트 템플릿을 외우라고 하지 않아요. 대신 원리를 가르쳐요. 컨텍스트가 왜 중요한지, 검증은 왜 필요한지, 설계를 왜 먼저 해야 하는지. 이 원리를 이해하면 모델이 바뀌어도 적응할 수 있거든요.

Opus 4.6에 맞춰서 CLAUDE.md를 줄이고, 역할 설정을 빼고, 체크인 포인트를 넣는 것처럼요. 이건 Opus 4.6에 특화된 전략이지만, "모델의 특성을 이해하고 거기 맞게 조절한다"는 원리는 어떤 모델에서든 적용됩니다.

마무리

Opus 4.6는 단순히 "더 똑똑한 Claude"가 아닙니다. AI와 협업하는 방식을 바꿔야 하는 모델이에요.

핵심을 한 문장으로 요약하면:

이전 모델에서 통하던 습관들 — 지시 반복, 역할극, 무조건 동의 — 이 전부 Opus 4.6에서는 낡은 방식이 됐어요. 도구가 바뀌면 쓰는 법도 바꿔야 합니다. 그래야 도구의 진짜 힘을 끌어낼 수 있어요.

오늘 저녁에 CLAUDE.md를 열어보세요. 중복된 규칙이 있나? 의도 없이 규칙만 나열돼 있나? 역할 설정이 남아있나? 이 세 가지만 정리해도 내일부터 AI의 결과물이 달라질 겁니다.

다음 뉴스레터에서도 바이브 코딩과 AI 코딩 관련 실전 인사이트를 가져오겠습니다.

레퍼런스