"AI가 멍청한 게 아니라, 당신의 컨텍스트가 멍청한 거다"
Claude Code를 깔고 나서 제일 먼저 하는 짓이 있다. 코드 덩어리를 붙여넣고 '이거 고쳐줘'라고 치는 것. 그리고 결과가 기대에 못 미치면 'AI는 아직 멀었어'라고 결론 낸다. 내가 수십 번 봐온 패턴이다.
그런데 Hacker News에서 화제가 된 내부 벤치마크 데이터는 다른 이야기를 한다. Context Engineering을 제대로 적용한 팀은 복잡한 멀티파일 태스크 완료 속도가 3.7배 빨라지고, 버그 발생률이 42% 줄었다. 이 숫자는 마케팅 카피가 아니다. 구조화된 컨텍스트 입력이 모델의 추론 품질을 실질적으로 바꾼다는 Anthropic 공식 문서의 주장을 수치로 뒷받침한다.
문제는 도구가 아니라 입력 설계다.
28만 개 instruction 파일이 폭로한 민낯
최근 dev.to에 공개된 대규모 분석 결과가 이 문제를 훨씬 선명하게 보여준다. 28,721개 GitHub 레포지토리, 165,063개 파일, 330만 개 instruction을 분석한 결과—놀랍도록 불편한 숫자가 나왔다.
CLAUDE.md 파일의 73%는 실제 instruction이 아니다. 헤딩, 설명 단락, 예시 블록이 대부분이고, 진짜 행동 지시(directive)는 전체의 27%뿐이다. 평균 instruction 길이는 8.9단어, 문장 단편 수준이다.
더 심각한 건 구체성의 문제다. 전체 instruction의 약 70%가 추상 언어로 작성되어 있다. Claude 사용자들의 경우 30.6%만이 특정 도구·파일·커맨드를 명시한다. 나머지는 '일관된 코드 포맷을 사용하라' 같은 범주 수준의 지시다.
이게 왜 치명적이냐? 같은 연구에서 인용한 통제 실험 결과가 답을 준다. 구체적 구조물을 명시한 instruction은 추상적 instruction 대비 LLM 준수율이 10.9배 높았다(N=1000, p<10⁻³⁰). ACL 2025에서 발표된 RuleArena 연구(Zhou et al.)도 같은 방향을 가리킨다—규칙이 모호하거나 과소명세될수록 강한 모델도 체계적으로 실패한다.
'ruff format으로 커밋 전 포맷하라'는 instruction은 따라진다. '일관된 포맷을 유지하라'는 instruction은 사실상 노이즈다.
실전에서 효과가 검증된 7가지 기법 중 핵심 3가지
개론은 충분하다. 팀 리드 관점에서 내일 당장 적용 가능한 것들로 좁혀보자.
① 삼겹 구조(Context Sandwich)
Claude Code 대화창 시작에 붙이는 컨텍스트를 '고→중→저→고' 레이어로 설계하는 방식이다. 프로젝트 미션(고), 아키텍처 레이어 구조(중), 코드 규범(저), 그리고 현재 태스크(고)로 끝낸다. Anthropic 공식 문서는 이렇게 계층화된 컨텍스트가 복잡한 멀티파일 태스크에서 추론 능력을 40% 향상시킨다고 명시하고 있다. 핵심은 마지막에 '내가 원하는 결과'를 다시 상기시키는 것—LLM의 근접 인과 편향을 역으로 이용하는 구조다.
② Harness로 AI 출력 사전 제약
GitHub 19K 스타를 받은 Archon은 AI가 생성하는 코드의 출력 형식을 사전에 Schema로 정의한다. api/*.py는 async def 포함, 최대 150줄, 테스트 필수, Google 스타일 docstring—이런 규칙이 코드 작성 전에 걸린다. 위반은 결과물이 나온 후 리뷰에서 걸리는 게 아니라 생성 단계에서 차단된다. 기존 CI/CD의 '인프라스트럭처 애즈 코드' 사상을 AI 출력에 적용한 것이다.
③ 세션 기억 관리
claude-mem(GitHub 38K 스타)은 Claude Code 세션 히스토리를 자동 기록하고 다음 세션에서 관련 기억을 불러온다. 숙련된 시니어 엔지니어가 새 프로젝트 온보딩에 2주 걸리는 문제—Claude Code는 매 세션마다 이 비용을 지불한다. 이 플러그인을 쓴 팀들은 '반복 설명' 오버헤드가 60% 줄었고 새 프로젝트 착수 속도가 2배 빨라졌다고 보고한다.
그리고 AI는 자신의 코드에 10/10을 줬다
Context Engineering으로 Claude Code 생산성을 높이는 것과 별개로, 반드시 직면해야 할 두 번째 문제가 있다. AI 생성 코드를 AI가 검증하는 루프의 위험성이다.
dev.to에 올라온 실험 하나가 이걸 정확히 포착했다. 개발자가 AI에게 배열 평균값 함수를 작성하게 했다. 빈 배열 처리 누락, 의미 없는 중복 루프, 혼란스러운 변수명—세 가지 문제가 있었다. 같은 AI에게 리뷰를 시켰더니 결과는 '깔끔하고 효율적이며 모든 엣지케이스를 처리한다. 10점 만점에 10점'이었다.
빈 배열 문제를 지적하자 AI는 수정 후 11점을 줬다.
이건 AI가 멍청해서가 아니다. AI는 자신이 생성한 패턴과 자신이 평가하는 패턴을 동일한 확률 분포로 본다. 자기 출력은 자기 패턴에 항상 완벽하게 매칭된다. 이 구조상 자기 평가는 평가가 아니라 자기 확인(self-confirmation)이다.
반면 다른 AI 도구가 작성한 코드를 리뷰하게 했더니 7개 문제를 발견하고 6점을 줬다. AI가 남의 코드를 리뷰하는 건 실질적으로 유용하다. AI가 자신의 코드를 리뷰하는 건 연극이다.
컨텍스트 설계와 품질 검증은 한 쌍이다
이 두 문제—컨텍스트 품질과 자기평가 한계—는 사실 같은 실패 패턴의 두 얼굴이다. 팀이 AI-First 워크플로우를 설계할 때 묶어서 봐야 한다.
컨텍스트 설계가 잘못되면: AI는 빠르게 엉뚱한 코드를 생성한다. Harness 없이 추상적 instruction만 던지면 출력이 레포 패턴과 충돌하고, 리뷰 비용이 생성 비용보다 커진다.
자기평가 루프에 빠지면: 빠르게 생성된 코드가 자신 있게 검증된다. '빠름'과 '신뢰'가 결합해서 눈에 안 보이는 기술 부채가 쌓인다. 프로덕션에서 터지는 건 언제나 이 교차점이다.
현장에서 즉시 적용 가능한 원칙은 단순하다:
- Instruction은 구체적 구조물을 명시하라. '일관된 포맷'이 아니라 '
ruff format으로 포맷하라'. - AI가 쓴 코드의 리뷰는 다른 AI 세션이나 인간이 맡아라. 같은 세션의 자기검토는 품질 게이트가 아니다.
- '이게 작동하나?'가 아니라 '무엇이 잘못될 수 있나?'를 물어라. 검증 질문의 구조 자체를 바꿔야 다른 답이 나온다.
팀 리드가 설계해야 할 것
결국 이 모든 수치가 가리키는 지점은 하나다. AI 도구의 생산성 상한은 팀의 컨텍스트 설계 능력이 결정한다.
3.7배 속도 향상은 Claude Code가 스스로 달성한 게 아니다. 구조화된 컨텍스트, 사전 제약된 출력 Harness, 지속적인 세션 기억—이 설계를 팀이 만들어서 AI에게 쥐어줬을 때 나온 숫자다. 그리고 그 코드를 자기평가 루프에 맡기지 않고 독립적인 검증 단계를 거쳤을 때 버그 42% 감소가 따라왔다.
Instruction 파일 73%가 노이즈이고, 70%가 추상 언어이며, AI가 자신의 버그 코드에 10/10을 주는 현실—이걸 알고 나면, 팀 리드가 다음에 집중해야 할 것이 명확해진다. 더 좋은 AI 도구를 찾는 게 아니라, 지금 도구에 더 좋은 컨텍스트를 설계하는 것이다.