1. 핵심 주장 (Core Claims)
- Context Engineering이란: RAG, 메모리, 에이전틱 히스토리, 구조화된 출력 같은 온갖 추상화 레이어를 걷어내고 보면, 결국 모든 것은 "토큰을 모델에 넣고 구조화된 출력을 받아내는" 문제로 환원된다. 데모 수준(80%)을 넘어 95~99% 신뢰도로 가려면 컨텍스트 윈도우에 무엇을, 어떤 순서로 넣는지를 직접 설계해야 한다.
- Dex Horthy가 용어를 처음 만들었다: Human Layer 공동창업자 Dex Horthy가 2025년 4월 "12 Factor Agents" 발표 이후, 수백 명의 AI 엔지니어와 대화하며 공통 패턴에 이름을 붙인 것이 "context engineering"이다. Toby Lütke(Shopify), Andrej Karpathy가 이후 이 용어를 대중화했지만 Dex가 며칠 앞섰다.
- 컨텍스트 윈도우에는 물리 법칙이 있다: 100만 토큰 컨텍스트 윈도우가 생겨도 모델이 "똑똑해지는" 것은 아니다. 어텐션은 quadratic(제곱)으로 작동하므로 토큰이 늘어날수록 주의가 희석된다. 2025년 한 연구에 따르면 프론티어 LLM은 150~250개 지시사항을 넘어가면 따르는 능력이 급격히 떨어진다.
- Smart Zone vs Dumb Zone: 컨텍스트 윈도우 앞쪽(대략 첫 10만~20만 토큰)은 "스마트 존"으로 모델이 정보를 잘 활용하지만, 그 이후는 "덤 존"으로 들어가면 성능이 저하된다. 원칙은 "컨텍스트 윈도우를 적게 쓸수록 결과가 좋다."
- Loop Engineering — Ralph Wiggum 기법: 프롬프트를 쓰는 대신 루프를 설계하는 패러다임. 핵심은 "백프레셔(back pressure)" — 모델이 스스로 작업을 검증하도록 피드백 루프를 자동화하는 것. 검증 가능한 문제(컴파일러, 린터, 테스트)일수록 블랙박스처럼 취급해 루프를 돌릴 수 있다.
- Dark Factory(다크 팩토리)의 실패: Human Layer 팀은 2025년 7월 "라이트 오프(불 꺼진)" 소프트웨어 팩토리 — 사람이 코드를 전혀 읽지 않고 에이전트가 이슈→PR→배포까지 전부 처리하는 시스템 — 를 만들었으나, 11월에 결국 폐쇄했다. 코드베이스가 너무 나빠져서 처음부터 다시 만드는 게 고치는 것보다 쉬워졌기 때문.
- Token Harder vs Token Smarter: "Token harder"는 Claude 구독 6개를 모두 풀가동하며 토큰 사용량 자체를 극대화하는 접근(효율/유틸라이제이션에 집착, Eli Goldratt의 "The Goal"에서 말하는 국소 최적화 함정). "Token smarter"는 사람의 판단·취향·아키텍처 감각을 유지하면서 AI로 최대한 빠르게 움직이는 접근.
- 소프트웨어 팩토리의 역사: 용어 자체는 1968년 NATO 컨퍼런스에서 처음 등장했고, 이후 DevOps(자동화 피드백 루프), 2018년 미 국방부/공군의 "DevSecOps Factory"(Nicolas Chaillan 100페이지 에세이)를 거쳐, 지금은 AI 에이전트가 인간 개발자를 대체하는 "에이전틱 팩토리"로 진화했다.
- Spec-driven development는 대체로 실패했다: 스펙과 코드라는 두 개의 진실 소스(source of truth)가 생기면 곧 어긋난다(drift). Amazon Kiro 등 스펙 기반 개발 도구들은 유지보수 프로젝트 일부를 제외하면 대부분 버려졌다.
- 의도적 압축(Intentional Compaction): 컨텍스트가 노이즈로 가득 찰 때, 유용한 부분만 마크다운 문서로 압축하고 검증한 뒤 새 대화를 시작하는 것이 컨텍스트 엔지니어링의 핵심 빌딩 블록이다.
- "You're absolutely right"는 위험 신호: 모델이 이 말을 하기 시작하면, 컨텍스트의 궤적(trajectory) 자체가 오염된 것 — 대화 이력상 "다음에 또 실수할 확률"이 높아진 상태이므로 세션을 새로 시작해야 한다.
- Human Layer의 제품 방향: "Pull Request를 죽이자"는 아이디어 — PR 단위의 이산적 리뷰 대신, 에이전트 작업을 실시간·협업적으로 볼 수 있는 IDE(Figma식 클라우드 협업 모델)를 구축 중.
2. 근거와 사례 (Evidence & Examples)
- Ralph Wiggum 데모 (2024-07-12경, 1년 4일 전): Jeff Huntley가 SF를 방문해 Sonnet을 24시간 내내 돌려 6주간 6천 달러를 써서 Gen Z 프로그래밍 언어(2단계 컴파일러 포함, 컴파일러 자체가 그 언어로 작성됨)를 만들어낸 사례.
- Slow Loops (느린 루프): Human Layer가 실제 운영 중인 방식 — GitHub Actions에서 매일 밤 크론으로 린터를 돌려 "한 가지만 고치고 커밋·푸시"하는 루프를 실행, 아침에 일어나면 코드베이스를 조금씩 개선한 PR 1개(혹은 여러 개)가 생성돼 있다. React Doctor(프론트엔드용), prop narrowing(옵셔널 prop을 줄이는 안티패턴 감지) 같은 피드백 메커니즘을 추가해 다차원으로 확장 가능.
- Opus 4.1 디버깅 실패 사례: 코드를 3개월간 읽지 않은 상태에서, 정교한 프롬프팅으로도 Opus 4.1이 근본 원인(사실은 특정 primary key가 잘못된 타입 객체로 라우팅되던 문제)을 찾지 못해, 팀이 결국 며칠간 직접 코드를 파고들어 3주간 온보딩 작업을 해야 했던 실제 사고.
- 12 Factor Agents (2025년 3~4월 작성): Dex가 크루AI/랭체인 등 에이전트 프레임워크 생태계를 관찰하며 도출한 12개 원칙 — 자연어를 도구 호출로, 프롬프트/컨텍스트 윈도우 직접 소유, 도구는 구조화된 출력일 뿐, 실행 상태와 비즈니스 상태 통합, 실행/일시정지/재개 API, 도구 호출로 인간과 접촉, 제어 흐름 직접 소유, 에러를 컨텍스트 윈도우에 압축, 작고 집중된 에이전트, 어디서든 트리거, 사용자가 있는 곳에서 만나기, 상태 비저장 리듀서(정확히는 트랜스듀서)로 만들기.
- RPI(Research-Plan-Implement) 프레임워크의 진화: 2025년 8월 처음 제시. Research 단계는 서브에이전트 병렬로 코드베이스를 읽고 10K 토큰짜리 마크다운 요약을 만드는 것(10만 토큰 컨텍스트 → 1만 토큰 요약). 하지만 실제로 쓰다 보니 계획 문서(plan doc)에 모든 diff 블록을 다 적었더니, 계획을 읽는 데 20분 + PR을 읽는 데 20분 = 코드 리뷰 시간이 오히려 2배로 늘어나는 "안티-레버리지" 문제를 발견해 접근을 수정.
- 모델의 "수평적 계획(horizontal plan)" 문제: 앱을 만들라고 하면 모델은 DB → 서비스 레이어 → API → 프론트엔드 순으로 계획을 세우는데, 이는 사람이 실제로 일하는 방식(가짜 API로 프론트를 먼저 완성 → 서비스 레이어 연결 → DB 마이그레이션 → 비즈니스 로직 → 에러 핸들링)과 정반대라 중간 검증이 불가능해진다.
- SRE 조직 비유: 구글 SRE 팀이 데이터센터를 1개→5개→50개로 늘리면서도 팀 인원을 선형적으로 늘리지 않고 자동화로 대응한 사례(SRE 책 인용) — headcount는 로그함수적으로, output은 선형적으로 증가하는 구조가 "token smarter"가 지향하는 모델.
- RLVR(Reinforcement Learning with Verifiable Rewards) 연구: Claude Code가 다른 CLI 코딩 에이전트보다 좋은 이유는 모델과 하네스(harness)를 함께 학습시켜, 특정 도구(파일 읽기/쓰기/검색)를 호출하는 능력 자체를 강화학습으로 훈련했기 때문. 다만 "3개월 뒤 유지보수성이 좋은 코드를 쓰는 능력"은 벤치마크가 없어 훈련되지 않고 있다는 게 Dex의 관찰.
- Frontier Code / Marathon 벤치마크: Cognition 팀이 만든 벤치마크로, 패치가 골든 정답과 기능적으로 동일한지 판단하는 judge 모델 + 코드 품질을 평가하는 두 번째 judge 모델을 사용하지만, 여전히 불충분하다고 평가. 모델이 자기 코드를 스스로 평가하면 sycophantic(아첨성)하게 나온다는 문제도 지적.
- 하니스 엔지니어링(Harness Engineering): Martin Fowler가 정의한 "inner harness"(Claude Code/Codex 같은 도구 자체가 노출하는 통합 지점 — 커맨드, MCP, 스킬)와 "outer harness"(사용자가 자기 코드베이스에 맞게 커스터마이징하는 부분)의 구분.
3. 구조화된 시사점 (Structured Insights)
| 개념 | 정의 | 실무 함의 |
|---|---|---|
| Context Engineering | 컨텍스트 윈도우에 넣는 토큰의 종류·순서·양을 직접 설계 | 프레임워크(RAG/메모리 라이브러리) 그대로 쓰면 80%까지만 도달, 그 이상은 토큰 레벨 사고 필요 |
| Smart Zone / Dumb Zone | 앞쪽 10~20만 토큰(모델별 상이) vs 그 이후 | 작업을 스마트 존 안에서 끝내도록 세션을 자주 압축(compaction)해서 재시작 |
| Instruction Budget | 지시사항이 150~250개를 넘으면 준수율 급감 | 상충하는 지시나 중간에 마음을 바꾸는 대화는 특히 위험 — 새 세션으로 리셋 |
| Trajectory(궤적) | 대화 이력 자체가 다음 행동을 예측하는 재료가 됨 | "You're absolutely right"가 나오면 이미 나쁜 궤적에 진입했다는 신호 → 재시작 |
| Loop Engineering | 검증 가능한 문제를 루프로 자동화(백프레셔) | 컴파일러/린터/테스트처럼 결정론적 검증이 있는 영역에서만 다크 루프 적용 |
| Slow Loops | 하루 1회 크론으로 소규모 개선 PR 생성 | 기능 개발이 아니라 "코드베이스 품질 유지"에만 다크 루프를 쓰는 것이 안전 |
| Token Harder vs Smarter | 유틸라이제이션 극대화 vs 사람 판단 유지한 채 가속 | "harder"는 국소 최적화 함정, "smarter"가 지속가능한 방향 |
| RPI → 압축 아티팩트 | Research(요약)→Design(사람 검토)→Plan(수직적 슬라이스)→Implement | 계획 문서를 영구 보존하지 말고 매번 새로 생성(코드가 진실의 원천) |
| Spec-Driven Dev의 한계 | 스펙과 코드 이중 진실 소스는 결국 drift | 스펙을 evergreen 문서로 유지하려는 시도는 실무에서 거의 성공 사례 없음 |
| Dark Factory | 완전 무인 자동화(팩토리 은유: 조명 없는 공장) | 코드 리뷰 전면 제거는 3~6개월 내 유지보수 불능 상태로 귀결(실증 사례) |
핵심 인과 구조: 모델의 어텐션은 quadratic이라 컨텍스트가 커질수록 관련성 판단 비용이 커진다 → 그래서 "적게, 스마트 존 안에서" 작업해야 한다 → 이를 위해 "의도적 압축"이 필요하다 → 압축을 반복 적용한 것이 RPI 프레임워크다 → RPI를 완전 자동 루프로 돌리면 다크 팩토리가 되는데, 사람이 코드 아키텍처/유지보수성을 검증하는 단계가 빠지면(모델이 아직 이 부분은 훈련되지 않았으므로) 3~6개월 뒤 붕괴한다.
4. 실행 포인트 (Action Points)
- 컨텍스트 윈도우를 아끼는 습관화: 작업이 스마트 존(대략 10~20만 토큰)을 넘어가려 하면, 지금까지의 작업을 파일/문서로 압축하고 새 세션을 시작한다.
- "You're absolutely right" 등장 시 즉시 리셋: 모델이 사과성 응답을 반복하기 시작하면 궤적이 오염된 것이므로, 컨텍스트를 이어가지 말고 새로 시작한다.
- 루프는 검증 가능한 영역에만 적용: 컴파일러/린터/테스트처럼 결정론적으로 옳고 그름을 판단할 수 있는 작업만 완전 자동 루프(다크 루프)로 돌리고, 기능 개발·아키텍처 결정에는 사람을 반드시 개입시킨다.
- 하나씩, 작게 시작: 루프 엔지니어링을 도입할 때 한 번에 큰 시스템 전체를 다크 팩토리화하지 말고, 작은 루프 하나(예: 매일 밤 린터 fix PR 1개)부터 검증하며 확장한다.
- 계획 문서는 일회용으로: RPI의 research/plan 문서를 영구 보존해 유지하려 하지 말고, 코드가 바뀔 때마다 필요 시 새로 생성한다(토큰은 싸고 사람 시간은 비싸다).
- 모델의 "수평적 계획"을 그대로 따르지 말 것: DB→서비스→API→프론트 순서로 짜인 계획은 중간 검증이 불가능하니, 사람이 개입해 수직적 슬라이스(작은 end-to-end 조각)로 재구성하도록 유도한다.
- 레버리지 지점 찾기: 구현 전 1시간을 계획/설계에 투자해 PR 리뷰 시간을 20분으로 줄이는 식으로, 사람 개입 지점을 "가장 효율적인 곳"에 배치한다(전부 검토 or 전부 무검토의 양극단을 피함).
- 코드 리뷰를 절대 포기하지 않기: 에이전트가 코드를 작성해도 최소한 아키텍처/프로그램 설계 수준에서는 사람이 계속 읽어야 한다. 그렇지 않으면 기술부채가 조용히 쌓여 3~6개월 뒤 "처음부터 다시 만드는 게 더 쌈" 상태에 도달한다.
핵심 요약 (20줄)
컨텍스트 엔지니어링은 RAG, 메모리, 에이전틱 히스토리 같은 추상화를 걷어내고 결국 "어떤 토큰을 모델에 넣을지"를 직접 설계하는 작업이라는 것이 이 대화의 출발점입니다.
Human Layer 창업자 Dex Horthy는 2025년 4월 "12 Factor Agents" 발표 직후 수백 명의 AI 엔지니어와 대화하며 이 용어를 처음 만들었고, 이후 Toby Lütke와 Andrej Karpathy가 대중화시켰습니다.
컨텍스트 윈도우가 100만 토큰까지 커져도 모델이 똑똑해지는 것은 아니며, 어텐션이 제곱으로 작동하기 때문에 토큰이 늘어날수록 관련 정보에 집중하는 능력이 떨어집니다.
프론티어 LLM은 150~250개 지시사항을 넘기면 준수율이 급격히 떨어진다는 2025년 연구 결과가 언급되었습니다.
컨텍스트 윈도우의 앞쪽 10만~20만 토큰은 "스마트 존", 그 이후는 "덤 존"으로 불리며, 원칙은 컨텍스트 윈도우를 적게 쓸수록 결과가 좋다는 것입니다.
루프 엔지니어링은 프롬프트 대신 루프를 설계하는 방식으로, 핵심 원리는 모델이 스스로 결과를 검증할 수 있는 "백프레셔" 피드백 루프를 만드는 것입니다.
Ralph Wiggum 기법은 Sonnet을 6주간 24시간 돌려 6천 달러를 써서 자체 컴파일러를 가진 프로그래밍 언어를 만들어낸 사례에서 유래했습니다.
Human Layer 팀은 사람이 코드를 전혀 읽지 않는 "다크 팩토리"를 2025년 7월에 구축했지만, 코드베이스가 너무 나빠져 11월에 결국 폐쇄했습니다.
반면 매일 밤 크론으로 한 가지 이슈만 고치는 "슬로우 루프"는 실제로 잘 작동하는 방식으로 소개되었습니다.
소프트웨어 팩토리라는 용어는 1968년 NATO 컨퍼런스에서 처음 등장했고, DevOps를 거쳐 2018년 미 국방부의 DevSecOps Factory 제안으로 이어졌습니다.
Spec-driven development는 스펙과 코드라는 두 개의 진실 소스가 시간이 지나며 어긋나기 때문에 대부분 실무에서 버려졌다고 지적됩니다.
RPI(Research-Plan-Implement) 프레임워크는 애초에 계획 문서에 모든 코드 변경을 적었더니 리뷰 시간이 오히려 두 배로 늘어나는 문제를 겪은 뒤 수정되었습니다.
모델은 DB부터 프론트까지 순서대로 짜는 "수평적 계획"을 세우는데, 이는 사람이 실제로 일하는 수직적 슬라이스 방식과 반대되어 중간 검증이 불가능해집니다.
의도적 압축은 노이즈가 쌓인 컨텍스트를 마크다운 문서로 요약해 검증한 뒤 새 세션을 시작하는 컨텍스트 엔지니어링의 핵심 기법입니다.
모델이 "You're absolutely right"라고 반복해서 답하기 시작하면 대화의 궤적 자체가 오염된 신호이므로 세션을 새로 시작해야 합니다.
Token harder는 클라우드 구독 여러 개를 풀가동해 토큰 사용량 자체를 극대화하는 접근이고, token smarter는 사람의 판단력을 유지하며 속도를 높이는 접근입니다.
구글 SRE 팀이 데이터센터를 늘리면서도 인원을 선형적으로 늘리지 않은 사례가 token smarter가 지향하는 확장 모델로 제시되었습니다.
Claude Code가 다른 코딩 에이전트보다 나은 이유는 모델과 하니스를 함께 강화학습으로 훈련했기 때문이지만, 유지보수성 높은 코드를 쓰는 능력은 아직 벤치마크가 없어 훈련되지 않고 있습니다.
Human Layer는 "풀 리퀘스트를 죽이자"는 아이디어 아래, PR 단위 리뷰 대신 에이전트 작업을 실시간·협업적으로 볼 수 있는 클라우드 IDE를 개발 중입니다.
채용 시에는 CS 기초와 분산 시스템을 이해하는 인재를 선호하며, AI 개발자로 성장하는 데는 몇 달이면 충분하지만 CS 기초를 가르치는 데는 훨씬 오래 걸린다는 점이 강조되었습니다.
마무리에서 Dex는 리팩터링(Martin Fowler), 클린 코드, 실용주의 프로그래머 같은 소프트웨어 공학 고전들이 AI 시대에 오히려 더 중요해졌다고 추천했습니다.