01핵심 개요
| 항목 | 내용 |
|---|---|
| 핵심 주제 | 같은 클로드 코드를 써도 결과가 갈리는 이유는 모델·프롬프트 실력이 아니라 "작업 전에 에이전트가 무엇을 알고 있는가" |
| 근거 수치 | 프로젝트 컨텍스트 파일 유무에 따라 작업 완료율 약 30% → 90%(3배 차이) |
| 제시자 | 안드레이 카르파티(테슬라 AI 총괄·오픈AI 창립 멤버 출신)가 정리한 작업 방식 |
| 핵심 개념 | 컨텍스트 엔지니어링 — 매 요청을 잘 쓰는 프롬프트 엔지니어링과 달리, 에이전트가 항상 알고 있는 배경 지식(규칙·구조·금지사항)을 만드는 작업 |
| 실천 축 | ①컨텍스트 파일 관리 ②세션(창) 구성 ③지시 대신 성공 기준 부여 ④변경분 중심 리뷰 습관 ⑤LLM 위키로 반복 설명을 문서화 |
| 오늘 30분 실천 | 안 쓰는 규칙 삭제 → 두 번 이상 고친 것 세 줄 기록 → 위키 폴더 생성 → 세션 두 개로 영역 분리·성공 기준 부여 |
02핵심 기능/내용 구조
영상은 "같은 클로드 코드인데 누구는 한 번에 끝내고 누구는 다섯 번을 고친다"는 관찰에서 출발한다. 저자는 이 차이가 모델 성능도, 프롬프트 실력도 아니라 "에이전트가 작업을 시작하기 전에 무엇을 알고 있느냐"에서 갈린다고 말하며, 한 연구에서 이 차이가 정답률 30%와 90%로 벌어졌다는 수치를 근거로 든다. 이어서 안드레이 카르파티가 정리한 작업 방식을 소개한다. 예전에는 사람이 대부분의 코드를 직접 짜고 AI는 자동완성 정도로 썼지만, 지금은 반대로 코드의 대부분을 에이전트가 쓰고 사람은 고르고 다듬는 쪽으로 역할이 바뀌었다. 이 변화의 핵심은 "더 좋은 문장을 짜내는 것"에서 "에이전트가 일할 환경을 만드는 것"으로 시간을 옮긴 태도이며, 이 환경을 만드는 작업에 컨텍스트 엔지니어링이라는 이름이 붙었다.
03기술적 맥락
프롬프트 엔지니어링과 컨텍스트 엔지니어링은 범위가 다르다. 프롬프트는 한 번의 요청이고, 컨텍스트는 그 요청들이 실행되는 배경 — 매번 다시 설명하지 않아도 에이전트가 이미 알고 있는 정보(프로젝트가 무엇을 하는지, 어떤 규칙을 지켜야 하는지, 무엇을 절대 하면 안 되는지)다. 예를 들어 패키지 매니저를 하나로 정해뒀는데 에이전트가 매번 다른 것을 쓴다면, 매번 고쳐주는 대신 컨텍스트 파일에 한 줄 적어두면 끝난다. 이런 항목이 열 개쯤 쌓이면 체감이 크게 달라지는데, 이는 "지시를 잘 쓰게 된 것"이 아니라 "지시할 일 자체가 줄어든 것"이다. 근거로 제시된 연구 수치는 에이전트 코딩 작업에서 프로젝트 컨텍스트 파일이 없을 때 작업 완료율 약 30%, 잘 만든 컨텍스트 파일을 얹었을 때 90%까지 상승 — 3배 차이다. 다만 이 수치가 모든 상황에 그대로 적용되는 것은 아니며 작업 종류와 컨텍스트 파일의 질에 따라 달라진다고 단서를 단다. 그럼에도 방향은 분명하다: 미리 알려준 만큼 덜 헤맨다. 이는 모델을 바꿔서 얻는 차이보다 크며, 많은 사람이 결과가 안 좋으면 더 비싼 모델부터 찾지만, 같은 모델이라도 환경만 정리해도 체감이 먼저 바뀐다.
04전략적 의미
카르파티가 강조하는 컨텍스트 파일 작성 원칙은 네 가지다. 첫째, 프로젝트가 무엇인지 한 문단으로 요약. 둘째, 실행·테스트 명령어를 그대로 기재. 셋째, 지켜야 할 규칙·이름 규칙·폴더 구조·금지 사항. 넷째, 자주 틀리는 지점 — 한 번 고쳐준 걸 또 틀린다면 그건 파일에 없다는 뜻이다. 저자는 이 네 번째가 실제로 가장 중요하다고 강조한다. 같은 실수가 반복되는 건 에이전트가 나쁜 게 아니라 사람이 안 알려준 것이기 때문에, 규칙을 미리 상상해서 쓰지 않고 틀린 것을 본 다음에 적는 방식을 권한다. 그러면 파일이 짧게 유지되고 실제로 필요한 것만 남는다. 작성 순서도 중요한데, 중요한 내용을 위쪽에 두어야 하며 길어질수록 아래쪽 지시는 약해진다. 반대로 하지 말아야 할 것도 있다 — 코드를 통째로 붙여넣지 말 것(이미 저장소에 있음), 언젠가 할 일 목록을 넣지 말 것(지금 지켜야 하는 규칙만 남길 것). 파일이 길어질수록 지켜지는 비율은 오히려 떨어지며, 저자 경험상 규칙이 20줄일 때가 200줄일 때보다 잘 지켜진다. 그래서 한 달에 한 번 파일을 열어 안 쓰는 규칙을 지우는 관리를 권한다 — 규칙은 늘리는 것보다 버리는 게 더 어렵지만, 버려야 나머지가 지켜진다. 팀 단위라면 이 파일을 저장소에 넣어야 한다. 각자 컴퓨터에만 두면 사람마다 다른 규칙으로 작업하게 되지만, 저장소에 두면 리뷰가 가능해지고 규칙 변경도 코드처럼 논의 대상이 되어 개인 취향이 아닌 팀의 합의가 된다.
05핵심 워크플로우·방법론
06활용 시나리오
- 개인 개발자의 반복 실수 교정: 클로드 코드가 패키지 매니저를 계속 다른 것으로 쓰거나 같은 실수를 반복할 때, 그때마다 고쳐주는 대신 컨텍스트 파일(CLAUDE.md 등)에 규칙 한 줄을 추가해 지시할 일 자체를 줄인다.
- 여러 작업을 동시에 돌리는 병렬 개발: 독립적인 작업 단위로 영역을 나누고 세션(터미널/창) 2~3개를 열어, 각 세션에 "테스트 통과", "화면이 이렇게 보이면 끝" 같은 확인 가능한 성공 기준을 줘서 에이전트가 스스로 반복하게 하고 사람은 병목에서 빠진다.
- 팀 단위 규칙 공유: 컨텍스트 파일을 개인 컴퓨터가 아닌 저장소(git)에 넣어, 규칙 변경을 코드 리뷰처럼 논의 대상으로 만들고 팀원마다 다른 규칙으로 작업하는 문제를 방지한다.
- 반복되는 질문·설명을 줄이는 지식 축적: 새 세션이나 새 팀원이 합류할 때마다 같은 배경 설명을 반복하는 대신, LLM 위키 폴더에 반복 설명되는 주제를 페이지로 쌓아 다음 질문이 그 위에서 시작되게 한다.
- 디자인처럼 자동 판정이 어려운 작업: 화면 전체가 아니라 컴포넌트 하나로 범위를 좁혀 성공 기준을 세우고 반복 속도를 높인다.
07현황 및 전망
저자는 이 방식이 "모델을 바꾸는 일"이 아니라 "내 쪽을 정리하는 일"이라는 공통점을 강조하며, 도구(모델)는 이미 충분히 좋고 남은 차이는 대부분 무엇을 미리 알려줬느냐에서 갈린다고 결론짓는다. LLM 위키 아이디어는 공개 두 주 만에 GitHub 스타 5,000개를 넘기며 다수의 따라 구현이 나왔을 만큼 반향이 컸는데, 이는 많은 사람이 "같은 설명을 계속 반복해야 하는" 동일한 불편을 겪고 있었다는 방증으로 해석된다. 영상은 오늘 적용 가능한 다섯 가지 실천 항목(①컨텍스트 파일을 20줄 수준으로 줄이기 ②자주 틀리는 것만 기재 ③세션을 영역별로 2~3개로 시작 ④지시 대신 성공 기준 제시 ⑤반복 설명은 문서로 이관)을 제시하고, 30분 내 실행 가능한 순서(안 쓰는 규칙 삭제 → 최근 두 번 이상 고친 것 세 줄 기록 → 위키 폴더 생성 후 가장 자주 설명한 주제 하나 이관 → 세션 두 개로 영역을 나눠 성공 기준 부여)로 마무리한다. 저자는 이번 주에 "얼마나 덜 고쳐줬는지" 직접 세어보라고 권하며, 그 숫자가 이 방식의 효과를 보여주는 지표라고 말한다.
08용어 사전
| 용어 | 한줄설명 | 비유/예시 |
|---|---|---|
| 컨텍스트 엔지니어링 | 에이전트가 항상 아는 배경 지식을 만드는 작업 | 매번 설명 대신 신입사원 매뉴얼을 미리 주는 것 |
| 프롬프트 엔지니어링 | 한 번의 요청 문장을 잘 쓰는 기술 | 매번 다른 주문서를 정성껏 쓰는 것 |
| 컨텍스트 파일 | 프로젝트 규칙·명령어·금지사항을 적어두는 문서(CLAUDE.md 등) | 신입에게 주는 회사 매뉴얼 |
| LLM 위키 | 반복 질문의 답을 문서로 쌓아 다음 질문이 그 위에서 시작되게 하는 구조 | 매번 새로 찾는 대신 정리된 백과사전을 보는 것 |
| 성공 기준(success criteria) | 기계가 스스로 판정 가능한 완료 조건 | "오류 없이 실행되면 끝" 같은 체크리스트 |
| 세션(창) | 독립 작업 단위로 여는 에이전트 실행 창 | 여러 명의 조수에게 각자 다른 방을 주는 것 |
| 변경분 중심 리뷰 | 전체가 아닌 늘고 줄어든 부분만 확인하는 검토 방식 | 계약서 전체 대신 정정된 조항만 확인하는 것 |
| 삭제줄(diff의 -) | 코드에서 조용히 사라진 부분 | 눈에 안 띄게 빠진 안전장치 |