Context Engineering with Dex Horthy — 컨텍스트 엔지니어링 실전 가이드

Context Engineering with Dex Horthy

에피소드 개요

LLM 컨텍스트 작동 방식과 컨텍스트 한계 극복 방법 — 즉 "컨텍스트 엔지니어링" — 은 LLM과 함께 일하는 소프트웨어 엔지니어에게 점점 더 중요해지고 있다. 이번 에피소드에서는 "컨텍스트 엔지니어링"이라는 용어를 만든 HumanLayer의 CEO이자 공동창업자인 Dex Horthy와 이야기를 나눴다.

컨텍스트 엔지니어링의 아이디어, 하네스 엔지니어링, 루프 엔지니어링, 소프트웨어 팩토리, 그리고 AI 보조 소프트웨어 개발에 대한 그의 접근 방식이 어떻게 진화했는지, HumanLayer가 코드 품질을 희생하지 않고 어떻게 소프트웨어 개발 수명주기의 더 많은 부분을 자동화하도록 엔지니어링 팀을 돕고 있는지를 논의했다.

Dex의 핵심 관찰 12가지

1. 12-Factor Agents — 약 100명의 "진짜" AI 엔지니어와의 대화에서 탄생

Dex는 2024년 8월경 AI 에이전트를 구축하기 시작했다. 당시 일반적인 접근법은 LangChain이나 CrewAI 같은 프레임워크를 사용하는 것이었다. 그는 기업 내 $100K+ 계약으로 AI 솔루션을 납품하는 실제 AI 엔지니어 약 100명과 이야기했다. 그들은 이런 프레임워크를 사용해보다가 버리고 직접 파이프라인을 구축했다. Dex는 이 대화에서 얻은 교훈을 히트작 "12-Factor Agents"에 공유했다.

2. 리뷰 없는 코드 배포는 재앙 — 몇 달 안에

Dex는 2025년 7월 모델이 코드를 쓰고 인간이 아무것도 검토하지 않는 실험을 했다. 4개월 후 그들은 전체 시스템을 폐기했다. 프로덕션이 중단됐고, 아무리 Opus 4.1을 프롬프팅해도 모델이 근본 원인을 찾지 못했다.

결국 며칠 동안 스파게티 코드를 헤매다가 기본 키가 코드베이스 전체에 잘못 라우팅된 것을 발견했다. 수정 후에는 인간이 한 번도 읽지 않은 코드베이스에 재적응하는 데 3주가 걸렸다. 오늘날 Dex는 최신 모델이 코드를 훨씬 빠르게 생산하기 때문에 이 문제가 4개월도 안 걸려 발생할 것이라고 생각한다.

3. 오늘날의 코딩 모델들은 코드베이스를 시간이 갈수록 나쁘게 만들도록 학습된다

Dex는 LLM이 기존 코드베이스를 "저하"시키는 이유는 SWE-bench 스타일 벤치마크에 최적화되어 있기 때문이라고 생각한다. 이 벤치마크들은 Django 같은 코드베이스에서 알려진 수정을 재현하는 것에 보상하지만, 잘못된 아키텍처 결정은 측정할 수 없다. 이는 잘못된 아키텍처와 잘못된 프로그램 설계의 비용 함수를 단위 테스트 실행으로 평가할 수 없기 때문이다.

Dex의 최선의 추측: 무엇이 올지 모르는 상태로 코드베이스에 20개 피처를 순서대로 구축하는 모델의 eval.

4. 컨텍스트 엔지니어링 101: "dumb zone"이 시작되는 곳 찾기

경험칙으로, 컨텍스트 창 사용량이 적을수록 결과가 좋다. 어텐션 메커니즘이 이차방정식적(quadratic)이기 때문이다: 컨텍스트 창에 들어가는 것이 많을수록 모두 처리하는 데 더 많은 컴퓨팅이 필요하다.

1M 컨텍스트 창을 가진 모델의 경우 적당하다고 느낄 때 300-400K에서 중단한다. 소형 모델은 약 100K에서 멈춘다. 이 경험적 한계를 넘어 컨텍스트 창이 채워지면 성능이 저하되기 시작하고, 모델이 .env 파일 삭제 같은 점점 더 어리석은 행동을 하기 시작하면 "dumb zone"에 진입한 것이다.

5. 더 큰 컨텍스트 창 ≠ 더 똑똑한 모델

모델의 지능은 컨텍스트 창 내의 토큰을 사용하는 능력, 즉 다음 결정에 어떤 컨텍스트 부분이 관련 있는지 결정하는 능력에 있다. 얼마만큼의 컨텍스트 사용이 합리적인지 감을 잡고, "dumb zone"에 부딪히면 실험해야 한다.

6. 빈번하고 의도적인 압축(compaction)

더 복잡한 프로젝트를 위해 Dex가 사용하는 기법이다. 길고 노이즈 많은 컨텍스트를 Markdown 문서로 압축한 다음, 이 "압축된 컨텍스트"를 가리키는 Markdown과 함께 새 세션을 신선하게 시작한다.

그가 사용하는 워크플로우:

• 세션 1: 많은 코드를 읽고("smart zone"에 있는 동안 컨텍스트 창 채우기), 리서치 문서 출력
• 세션 2: 수행할 작업을 설명하는 티켓을 받아 설계 문서로 변환
• 다음 세션: 두 문서를 모두 받아 계획 수립
• 인간은 실제로 중요한 곳에서 루프에 참여: 이 경우 설계 문서와 아키텍처 검토 (Dex는 모델이 이 부분에서 약하다고 생각함)

7. 비즈니스가 번창하거나 대규모·높은 비용이 될 때까지 LLM 사용 최적화하지 말기

Dex는 항상 문제를 해결하는 가장 스마트한 모델로 소프트웨어 구축을 시작할 것을 제안한다. 엔지니어링 시간이 거의 항상 병목이기 때문이다. 실제 규모와 비용이 충분히 높아졌을 때만 LLM 사용과 컨텍스트 사용을 최적화하기 시작하라. 그 때 프로세스의 더 간단한 단계에 GPT-OSS-120B (Opus 대비 1/1000 비용) 같은 모델을 사용하는 것이 가치 있을 수 있다.

8. "완전히 맞습니다!" = 새 세션 시작 신호

"완전히 맞습니다!" 또는 "반박하시는 게 맞습니다!" 같은 말은 새 세션을 시작할 때가 됐다는 의미다. 이런 응답은 LLM 세션이 "궤적 오염(trajectory-poisoned)"됐고, 시간과 토큰을 낭비하고 있다는 의미다. 모델은 자기회귀적(autoregressive)이어서 다음 메시지를 이전 대화를 기반으로 예측한다. 이런 루프에 빠지면: 모델이 실수 → 사용자가 "야단" → 모델이 또 실수 → 사용자가 "야단" → 모델이 다음 가장 가능성 높은 메시지가 또 다른 실수임을 계산!

9. 컨텍스트 창에서 중요한 4가지

• 크기: 클수록 "dumb zone" 전 여유 공간 확보
• 정보 품질: 컨텍스트 창에 들어간 것은 이후 모든 턴에서 사실로 취급됨. 이것이 오류가 복리로 증가할 수 있는 이유.
• 누락 정보: 에이전트가 필요한 정보가 없으면, 에이전트가 추측으로 채워 결과가 나빠짐.
• 궤적(Trajectory): 모델은 자기회귀적이므로, 이전 대화를 기반으로 다음 메시지를 예측한다. "궤적 오염"은 에이전트가 원하지 않는 일을 하는 패턴에 빠진 것. 이 경우 처음부터 시작해야 할 때.

10. Slow loops — 루프 엔지니어링의 핵심

HumanLayer 팀은 매일 밤 에이전트를 시작해 코드베이스에서 한 가지를 수정하고 풀 리퀘스트를 여는 자동화로 시작했다. 아침에는 머지를 기다리는 PR이 있었다. 시간이 지나면서 조정해 이제 4개 에이전트가 아침까지 총 4개 PR을 열고, 코드 품질 개선에 집중한다. 사람이 머지 전에 모두 읽는다.

11. "Token harder" vs "Token smarter"

Dex는 Claude 구독을 최대화하는 방법을 공유하는 "Hyper Engineering"이라는 그룹 채팅에 있다. 이 접근 방식을 그는 "token harder"라고 부른다. 반대편은 "token smarter": AI에서 최대 가치를 얻으면서 통제를 유지하는 것. 스마터가 실행하기 더 어렵다.

12. "소프트웨어 팩토리" 운영 3가지 방식

Dex가 실행 가능하다고 보는 옵션:

• 불 끄기: 에이전틱 코딩에 올인, 코드 미검토, AI가 너무 많은 슬롭을 만들지 않기를 기도. Dex가 시도했다 실패.
• AI 생성 코드 전부 읽고 검토: 인간 속도로 느려짐. 이 방식으로 AI 이전 엔지니어링 대비 생산성 30-50% 향상 기대.
• 레버리지 찾되 사람을 루프에 유지: 계획에 투자한 1시간이 구현에서 4시간을 절약할 수 있는 곳 찾기. 레버리지가 있는 곳에 더 많은 시간 투자: 설계, 아키텍처, 핵심 결정. 그런 다음 에이전트가 코드를 생성하도록 하고 전부 검토하지 않는다. 이 방식으로 Dex는 개발자가 모든 코드를 직접 작성할 때보다 2-3배 빠르게 움직일 수 있다고 생각한다.

관련 Pragmatic Engineer 딥다이브

• Uber가 개발에 AI를 사용하는 방법: 내부 관찰
• AI 에이전트가 실제로 우리를 느리게 만들고 있나?
• 2026년 소프트웨어 엔지니어를 위한 AI 툴링
• 소프트웨어 엔지니어로서의 Vibe Coding
• Claude Code가 어떻게 구축되는가

핵심 요약 (20줄)

1. HumanLayer CEO Dex Horthy가 "컨텍스트 엔지니어링" 용어를 창안, 12-Factor Agents 작성
2. 100명 실제 AI 엔지니어 인터뷰: LangChain·CrewAI 프레임워크 → 직접 파이프라인으로 전환
3. 결정적 실패: 2025년 7월 코드 미검토 실험 → 4개월 후 프로덕션 중단·전체 시스템 폐기
4. SWE-bench 최적화 코딩 모델들은 아키텍처 악화를 측정하지 못함 → 코드베이스 시간이 갈수록 나빠짐
5. "dumb zone": 1M 컨텍스트 모델은 300-400K에서, 소형 모델은 100K에서 중단 권장
6. 어텐션 메커니즘이 이차방정식적 → 컨텍스트 사용량 적을수록 결과 품질 높음
7. 큰 컨텍스트 창 ≠ 더 똑똑한 모델 → 관련 토큰 선별 능력이 진짜 지능
8. 의도적 압축: 긴 컨텍스트를 Markdown으로 압축 → 새 세션에서 재시작
9. 멀티 세션 워크플로우: 리서치 → 설계 문서 → 계획 → 인간이 설계·아키텍처 검토
10. LLM 비용 최적화는 실제 규모에 도달할 때까지 미루기
11. "완전히 맞습니다!" = 궤적 오염(trajectory poisoning) 신호 → 즉시 새 세션 시작
12. 컨텍스트 창 4요소: 크기·정보 품질·누락 정보·궤적
13. 오류 복리: 컨텍스트에 들어간 것은 이후 모든 턴에서 사실로 취급됨
14. Slow loops: 매일 밤 에이전트가 코드 수정 PR 4개 오픈, 아침에 인간이 검토 후 머지
15. "Token harder" vs "Token smarter" — 통제 유지하며 최대 가치가 더 어렵지만 더 좋음
16. 소프트웨어 팩토리 옵션 1: 풀 에이전틱·미검토 → Dex 시도했다 실패
17. 소프트웨어 팩토리 옵션 2: 전부 검토 → 인간 속도, 30-50% 생산성 향상
18. 소프트웨어 팩토리 옵션 3: 레버리지 찾기 + 사람 루프 유지 → 2-3배 빠름 (권장)
19. 핵심 통찰: 계획 1시간 투자가 구현 4시간 절약 → 설계·아키텍처에 집중
20. 결론: AI 코딩의 인간 레버리지 포인트는 설계와 아키텍처 — 코드 생성은 에이전트에게