'Claude가 멈추자 마치 원시인처럼 코딩해야 했다.' 지난주 앤트로픽의 AI 서비스 장애 당시 한 개발자가 남긴 말입니다. 디지털투데이의 보도에 따르면 Claude 장애는 수일간 지속됐고, 그 여파는 단순한 불편함을 넘어 현대 개발자의 워크플로우가 얼마나 AI에 깊이 의존하고 있는지를 적나라하게 드러냈습니다. 레딧과 디스코드에서는 'AI에 반쯤 뇌를 맡긴 상태'라는 자조 섞인 고백들이 쏟아졌죠.
이 사태가 흥미로운 건 단순히 '의존도가 높다'는 사실이 아닙니다. 진짜 질문은 이겁니다. 우리는 AI를 제대로 쓰고 있는가? 장애 때 무너진 워크플로우 대부분은 AI에게 즉흥적인 프롬프트를 던지며 답을 얻는 방식에 기대고 있었습니다. 그 방식 자체가 이미 한계에 부딪히고 있었고, 장애는 그 균열을 한순간에 가시화했을 뿐입니다.
프롬프트 엔지니어링의 시대는 끝났다
dev.to에 올라온 'Context Engineering Is the New Prompt Engineering'은 이 전환을 정확히 짚습니다. '완벽한 프롬프트를 쓰는 것'이 AI 활용의 핵심이던 시대는 지났습니다. 지금 AI에서 드라마틱하게 더 나은 결과를 얻는 팀들은 프롬프트를 갈고 닦는 게 아니라 컨텍스트를 설계하고 있습니다.
현장에서 흔히 겪는 장면을 떠올려보세요. Claude에게 기능 구현을 요청하면 문법적으로 완벽하지만 프로젝트와 전혀 맞지 않는 코드가 나옵니다. 여러분이 Tailwind를 쓰는데 styled-components를 사용하고, 레포지터리 패턴이 있는데 컴포넌트 안에 비즈니스 로직을 때려 넣습니다. 그러면 '우리는 Tailwind 써요'라고 수정하고, '비즈니스 로직은 레포지터리에'라고 다시 수정하고, '테스트는 Vitest로'라고 또 수정합니다. 다섯 번의 back-and-forth, 소모된 토큰, 그리고 개발자의 집중력. 이게 프롬프트 엔지니어링 방식의 실제 비용입니다.
CLAUDE.md: 컨텍스트를 한 번만 설계하는 방법
컨텍스트 엔지니어링의 핵심 도구는 .claude/CLAUDE.md 파일입니다. 프로젝트 루트에 위치한 이 파일은 AI가 모든 응답 이전에 읽는 '프로젝트 헌법' 같은 것입니다. 여기에 담기는 내용은 단순한 지시사항이 아닙니다.
- 기술 스택과 아키텍처: Next.js + Tailwind + Supabase + Drizzle ORM, 그리고 각각을 어떻게 쓰는지
- 폴더 구조: 새 파일이 어디에 가야 하는지 명확한 지도
- 컴포넌트 원칙: 언제 컴포넌트를 만들고, 언제 만들지 말아야 하는지
- 데이터 접근 패턴: 모든 DB 쿼리는
src/lib/repositories/drizzle/에, Supabase 클라이언트는 auth와 storage만 - 테스트 기준: 어떤 변경에 어떤 수준의 테스트가 필요한지
- 완료 체크리스트: 테스트 통과, 빌드 성공 전까지 태스크 완료 선언 금지
이 파일이 있으면 'course enrollment 컴포넌트 만들어줘' 한 마디에 TypeScript 타입, Tailwind 스타일링, 올바른 폴더 위치, 테스트 파일까지 한 번에 나옵니다. 같은 요청에 다섯 번의 수정 루프가 필요하던 것이 첫 시도에 끝납니다. 구조화된 컨텍스트가 환각을 60% 줄이고 작업 완료 정확도를 45% 향상시킨다는 데이터는 이 차이를 수치로 보여줍니다.
컨텍스트 드리프트: 설계가 필요한 더 깊은 이유
CLAUDE.md가 해결하는 건 '프로젝트 최초 설정' 문제만이 아닙니다. 또 다른 dev.to 아티클이 지적하는 컨텍스트 드리프트는 장기 세션에서 발생하는 구조적 문제입니다. LLM은 상태가 없습니다(stateless). 매 요청마다 이전 대화 전체를 다시 주입하는 방식이고, 대화가 길어질수록 두 가지 문제가 생깁니다.
첫째는 컨텍스트 윈도 한계입니다. 대화가 너무 길어지면 초기 시스템 프롬프트가 말 그대로 밀려납니다. AI가 여러분의 첫 번째 지시를 더 이상 '볼 수' 없게 되는 겁니다. 둘째는 어텐션 희석입니다. 128k나 200k 토큰 윈도 안에 들어오더라도, 대화 후반부의 최근 토큰이 초기 핵심 지시보다 수학적으로 더 높은 가중치를 갖게 됩니다. React hooks를 디버깅하다 'catching the payload'라는 표현을 썼더니 AI가 낚시 훅을 설명하기 시작했다는 실제 사례는 이 메커니즘의 극단적 결과입니다.
CLAUDE.md는 이 문제의 구조적 해결책이기도 합니다. 매 응답 전에 읽히는 파일이 핵심 컨텍스트를 지속적으로 '갱신'하기 때문입니다. 여기에 더해 긴 세션을 다루는 팀이라면 세 가지 엔지니어링 가드레일을 병행할 수 있습니다: XML 태그나 마크다운 헤더를 활용한 구조화된 프롬프트, 5~10턴마다 대화를 요약해 주입하는 롤링 요약, 그리고 일정 주기로 핵심 목표를 재주입하는 오브젝티브 리프레시.
AI 의존도 문제, 방향이 틀렸다
Claude 장애 이후 'AI 의존도가 너무 높다'는 우려가 나왔습니다. 맞는 말이지만, 해석의 방향이 중요합니다. 문제는 AI를 많이 쓴다는 게 아니라, 어떻게 쓰느냐입니다. 프롬프트를 즉흥적으로 던지고 결과를 받는 방식은 AI가 멈추는 순간 워크플로우 전체가 멈춥니다. 반면 컨텍스트를 설계해두면 그 설계 산출물—CLAUDE.md 파일들, 구조화된 프롬프트 템플릿—은 팀의 지식 자산이 됩니다. Claude가 아닌 다른 도구를 써도, 다음 AI가 나와도 재활용할 수 있습니다.
메타의 선임 소프트웨어 엔지니어가 '간단한 작업도 LLM을 활용하는 게 자연스러운 흐름이 됐다'고 말하는 세상에서, AI 없이도 작동하는 워크플로우를 유지하되 AI를 쓸 때는 제대로 쓰는 것이 현실적인 전략입니다. 컨텍스트 엔지니어링은 그 '제대로'의 핵심입니다.
지금 당장 시작하는 법
거창하게 시작할 필요 없습니다. 오늘 AI와 pair-programming을 하면서 몇 번이나 같은 컨텍스트를 반복 설명했는지 세어보세요. 그 반복이 세 번 이상이라면, 그 내용이 CLAUDE.md에 들어가야 할 것들입니다. 현재 프로젝트에서 AI에게 가장 자주 수정을 요청하는 패턴—스타일링 방식, 폴더 위치, 네이밍 규칙—을 모아 파일 하나로 만드는 것이 시작점입니다.
컨텍스트 엔지니어링은 화려하지 않습니다. CLAUDE.md 파일이 겉보기에 별것 아닌 텍스트 파일인 것처럼요. 하지만 좋은 UX가 눈에 안 보이듯, 잘 설계된 컨텍스트도 마찰 없는 경험으로만 감지됩니다. AI가 처음부터 맞는 코드를 내놓는 것, 그게 프롬프트를 잘 쓴 결과가 아니라 컨텍스트를 잘 설계한 결과라는 걸 알아채는 팀이 다음 단계로 가는 팀입니다.