컨텍스트 엔지니어링 — AI에게 '기억'을
상주시켰더니 생긴 일
프롬프트를 매번 쓰는 대신 파일로 만들어 AI가 일하는 공간에 심어두는 것 — 이게 컨텍스트 엔지니어링이에요. 정체성 파일(CLAUDE.md), 인계 파일(HANDOFF), 기억 파일을 갖추자 "매일 0에서 시작하는 문제"가 실제로 사라졌어요. 그런데 몇 달을 운영해 보니, 업계 예찬론이 말해주지 않는 한계 세 가지가 남았어요. 그 한계가 3편의 '하네스'로 이어져요.
발상 전환 — 프롬프트를 쓰지 말고, 심어두자
1편에서 프롬프트라는 형식의 한계에 부딪힌 얘기를 했어요. 돌파구는 의외로 단순한 발상이었어요. 매번 타이핑하던 프롬프트를 파일로 만들어서, AI가 매 세션 자동으로 읽게 하면 되잖아?
Claude Code로 작업 환경을 옮기면서 이게 가능해졌어요. 작업 폴더에 CLAUDE.md라는 파일을 두면 세션을 열 때마다 자동으로 읽혀요. 거기에 "너는 이런 역할이고, 이런 규칙으로 일하고, 우리 상황은 이래"를 한 번만 적어두면, 다시는 타이핑할 필요가 없어요. 매일 아침의 워밍업 10분이 통째로 사라진 거예요.
비슷한 시기에 업계도 같은 결론에 도달하고 있었어요. 2025년 6월, AI 연구자 안드레이 카파시(Andrej Karpathy)가 "프롬프트 엔지니어링보다 컨텍스트 엔지니어링이 맞는 이름"이라고 말하면서 이 용어가 널리 퍼졌어요. 진짜 어려운 문제는 잘 부탁하는 문장이 아니라, AI가 보는 정보의 창(컨텍스트 윈도)에 무엇을 채워 넣을지 설계하는 일이라는 거죠. Anthropic도 그해 9월 공식 기술 블로그에서 "이제 관건은 적절한 단어 찾기가 아니라, 어떤 컨텍스트 구성이 원하는 결과를 만드는가"라고 정리했어요.
출처: Andrej Karpathy, X(2025.6) — x.com/karpathy · Anthropic 엔지니어링 블로그, "Effective context engineering for AI agents"(2025.9) — anthropic.com/engineering
기억의 건축 — 파일 세 종류면 된다
몇 달에 걸쳐 갖춰본 결과, 상주시킬 컨텍스트는 크게 세 종류였어요. 각각 다른 질문에 답해요.
- 정체성 파일(CLAUDE.md) — "너는 누구고, 어떻게 일하는가". 역할·말투·업무 절차·품질 기준. 매 세션 자동으로 읽혀요.
- 인계 파일(HANDOFF.md) — "어제 어디까지 했는가". 프로젝트마다 하나씩, 목표·결정·다음 단계를 기록해요. 세션이 바뀌어도, 심지어 PC가 바뀌어도 이 파일만 있으면 이어져요.
- 기억 파일(memory) — "반복되는 결정과 선호". "이 표현은 쓰지 말자", "보고서엔 항상 근거를 달자" 같은 누적 결정을 한 건씩 파일로 쌓아요.
운영하면서 원칙이 하나 생겼어요. "적어두지 않은 건 사라진다." 대화에서 아무리 좋은 결정을 해도, 파일로 남기지 않으면 다음 세션의 AI에겐 없던 일이에요. 반대로 파일에 적힌 건 확실하게 이어져요. 그래서 작업을 끝낼 때마다 "인계 파일 정리해줘" 한마디를 습관으로 붙였어요.
기억 다음은 분업 — 컨텍스트에도 설계가 필요했다
파일이 쌓이니 다음 문제가 왔어요. 제안서 쓰는 법, 메일 쓰는 법, 분석하는 법, 디자인 규칙… 전부 정체성 파일에 넣었더니 파일이 감당 못 하게 커진 거예요. 매 세션 그걸 통째로 읽는 것도 낭비고요.
그래서 컨텍스트를 쪼갰어요. 항상 읽어야 하는 것(정체성·핵심 규칙)만 상주시키고, 특정 작업에만 필요한 것은 작업 유형별 전문 서브에이전트와 스킬로 분리했어요. 제안서 담당, 데이터 분석 담당, 문서 디자인 담당… 이런 식으로요. 필요할 때만 해당 컨텍스트가 펼쳐지니, 평소엔 가볍고 일할 땐 깊어요.
여기까지 갖추고 나니 확실히 달라졌어요. 아래가 실제로 매일 반복되는 장면이에요.
"저번에 뭐 하고 있었더라"부터 시작. 지난 대화를 뒤져 맥락을 복사해 오고, 놓친 결정사항은 기억에 의존해요. 재설명에 10분 이상, 그마저 매번 조금씩 달라요.
세션을 열면 인계 파일 기준으로 "A안 검토까지 끝났고, 다음은 B안 초안"을 AI가 먼저 짚어요. 첫 마디부터 본론이에요. 다른 PC에서 열어도 똑같아요.
뜻밖의 보너스 — AI를 위한 기억이, 사람의 인계 문서가 되다
이 구조의 가장 큰 수확은 예상 밖의 곳에서 왔어요. 인계 파일은 원래 AI에게 어제 맥락을 이어주려고 만든 건데, 급한 일정에 담당자가 자리를 비우는 일이 생기자 그 파일이 그대로 사람의 인계 문서가 된 거예요.
협의 뉘앙스와 "지난번에 안 된다던 것"이 담당자 머릿속에만 있어요. 이어받는 사람은 0에서 재시작하거나, 상대방에게 "처음부터 다시 설명해 주세요"라고 해야 해요.
프로젝트 인계 파일에 목표·결정·금기·다음 단계가 이미 기록돼 있어요. 파일 하나 열고, 첫날부터 맥락이 갖춰진 상태로 이어받아요.
돌아보면 당연한 일이었어요. 매 세션 0에서 시작하던 AI의 문제와, 담당이 바뀔 때마다 0에서 시작하던 팀의 문제는 같은 문제였던 거예요. 적어두는 구조 하나가 둘 다 풀었어요.
그런데 — 예찬론이 말해주지 않는 것
여기서 이야기가 끝나면 좋았을 거예요. 실제로 컨텍스트 엔지니어링을 다루는 글 대부분이 여기서 끝나요. 하지만 몇 달을 매일 굴려 보니, 이 방식이 스스로 해결하지 못하는 문제가 셋 있었어요. 시작은 어떤 사고였어요.
작업 폴더를 클라우드 저장소와 동기화해 쓰고 있었는데, AI가 파일을 빠르게 연속 저장하는 동안 동기화가 꼬이면서 충돌 사본이 100개 넘게 생겼어요. 어느 게 진짜 파일인지 하나하나 대조하며 복구하는 데 반나절이 날아갔죠.
진짜 충격은 그다음이었어요. 복구를 끝내고 규칙 파일을 열어 보니 — 이 사고를 막는 규칙이 이미 적혀 있었어요. "작업 전엔 동기화를 일시중지할 것." 적어는 뒀는데, 그날 지키지 않은 거예요. 문서에 있다는 것과 지켜진다는 건 완전히 다른 문제였어요.
이 사고를 계기로 그동안 쌓인 찜찜함을 정리해 보니, 컨텍스트 엔지니어링의 구조적 한계가 선명해졌어요.
규칙을 아무리 잘 적어도, 그건 여전히 '부탁'이에요. AI도 사람도 바쁘면 빠뜨려요. 지켜지는 날과 안 지켜지는 날이 생기고, 품질은 그만큼 들쭉날쭉해져요.
파일은 계속 쌓여요. 옛 버전과 새 버전이 중복으로 읽히고, 한때는 매 세션 수만 자를 낭비하고 있었어요. 컨텍스트가 비대해질수록 정작 중요한 내용이 그 속에 희석돼요. 심는 것만큼 덜어내는 설계가 필요한데, 그건 아무도 안 알려줘요.
"수치엔 근거를 달아라"라고 적어둬도, AI가 그럴듯하게 틀린 숫자를 내면 그대로 나가요. 좋은 컨텍스트는 좋은 입력을 보장할 뿐, 출력이 맞는지 확인해 주지는 않아요.
셋의 공통점이 보이시나요? 전부 "적는 것"으로는 해결이 안 되는 문제예요. 한계 1을 해결하려고 "규칙을 꼭 지키자"라는 규칙을 하나 더 적는 건 코미디잖아요. 다른 종류의 도구가 필요했어요.
컨텍스트 엔지니어링은 분명 프롬프트 엔지니어링보다 한 단계 위예요. 그건 확실해요. 다만 몇 달 운영해 본 입장에서 한 줄을 보태면 — 컨텍스트는 '무엇을 알려줄까'의 설계이지, '반드시 하게 만들까'의 설계가 아니에요. 아는 것과 하는 것 사이의 간극은 사람 조직에서든 AI에게든 똑같이 존재하더라고요.
그 간극을 메우는 게 다음 편의 주제예요. 규칙을 '부탁'하는 걸 그만두고, 코드로 '강제'하기 시작한 이야기요.
다음 편 예고 — 부탁을 강제로 바꾸다
사고 이후 방향을 다시 틀었어요. 세션이 시작되는 순간, 지시가 들어오는 순간, 작업이 끝나는 순간 — 이 길목마다 코드가 자동으로 개입해서 규칙을 실행하게 만드는 것. 문서에 적힌 규칙이 아니라, 빠뜨리는 게 불가능한 규칙. 업계에서 '하네스(harness)'라고 부르는 그 층이에요. 3편에서 그 구조 전체를 공개해요.
자주 묻는 것
컨텍스트 엔지니어링이 정확히 뭔가요?
CLAUDE.md에는 뭘 적어야 하나요?
컨텍스트를 잘 갖추면 규칙은 항상 지켜지나요?
- 프롬프트 엔지니어링의 한계
- 컨텍스트 엔지니어링 — AI에게 '기억'을 상주시키다 (지금 읽는 글)
- 하네스 엔지니어링 — AI가 일하는 '작업장'을 짓다