Context Is the New Code
📺 원본 영상: Context Is the New Code — Patrick Debois, Tessl 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-04 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
DevOps 운동의 창시자 중 한 명인 Patrick Debois가 AI 코딩 에이전트의 시대에 “컨텍스트(Context)“가 코드를 대체하는 새로운 핵심 자산이 되고 있다고 주장한다. 그는 2009년 DevOps에서 “Ops가 Dev처럼 되면 어떨까”라는 질문을 던졌듯, 이번에는 “컨텍스트가 곧 코드라면, 우리는 그것을 어떻게 다뤄야 하는가”라는 질문을 제시한다. 이를 위해 기존 소프트웨어 개발 수명 주기(SDLC)에 대응하는 **컨텍스트 개발 수명 주기(Context Development Lifecycle)**를 제안하며, Generate(생성) → Test(테스트) → Distribute(배포) → Observe(관찰)의 순환 구조로 설명한다.
컨텍스트가 코드다: 패러다임 전환
Patrick Debois는 자신이 이미 코드를 거의 직접 작성하지 않는다는 고백으로 강연을 시작한다. 프롬프트를 통해 AI에게 지시하는 것이 일상이 되었고, 이 흐름에서 그는 “컨텍스트가 새로운 코드”라는 명제를 도출했다. 이것은 단순한 수사적 표현이 아니다. 과거에는 복잡한 온보딩 로직을 수백 줄의 코드로 구현해야 했지만, 이제는 “먼저 사용자의 패키지 매니저가 무엇인지 파악하고, 생태계를 파악한 후, 사용자와 함께 이 단계들을 수행하라”는 스킬(Skill) 하나로 대체할 수 있게 되었다. 코드로는 모든 경우의 수를 다루는 것이 불가능했던 문제를, 컨텍스트가 더 우아하게 해결하는 것이다.
이 관점에서 코드는 두 방향으로 컨텍스트로 변환되고 있다. 하나는 AI가 코드를 생성하므로 컨텍스트(프롬프트)가 코드의 입력이 되는 방향이고, 다른 하나는 기존의 코드 로직이 재사용 가능한 스킬이나 워크플로우로 변환되어 컨텍스트 그 자체가 되는 방향이다. Debois는 2009년 DevOps 운동과의 유사성을 강조한다. DevOps가 “Ops가 Dev처럼 일하면 어떨까”라는 질문에서 협업과 배포 자동화를 탄생시켰듯, 이번 “컨텍스트가 코드라면”이라는 질문은 컨텍스트를 다루는 전혀 새로운 엔지니어링 규율을 낳고 있다.
컨텍스트 개발 수명 주기: 무한 루프
03:21 - 컨텍스트 개발 수명 주기를 나타내는 무한 루프(Infinity Loop) 다이어그램 슬라이드. Generate → Test → Distribute → Observe → Adapt → Regenerate의 순환 구조를 시각화한 화면
Debois는 소프트웨어 개발 수명 주기(SDLC)에 대응하는 **컨텍스트 개발 수명 주기(Context Development Lifecycle)**를 제안한다. 우리가 이미 대량의 컨텍스트를 생성하고 있다면, 그것을 테스트하고, 배포하고, 실제 동작을 관찰하고, 그 결과를 바탕으로 다시 컨텍스트를 개선하는 순환이 필요하다는 것이다. 그 구조는 DevOps의 상징인 무한 루프 형태로, Generate(생성) → Test(테스트) → Distribute(배포) → Observe(관찰) → Adapt(적응) → Regenerate(재생성)의 순서로 이어진다. 강연 전체는 이 루프의 각 단계를 구체적인 사례와 함께 설명하는 방식으로 진행된다.
Generate: 컨텍스트 생성
생성(Generate) 단계는 대부분의 청중에게 가장 친숙한 영역이다. 프롬프트를 직접 타이핑하는 것이 가장 기초적인 컨텍스트 생성이지만, 더 나아가면 재사용 가능한 형태로 발전한다. 코딩 에이전트마다 이것을 부르는 이름이 다르지만(Claude의 경우 CLAUDE.md, 기타 에이전트의 경우 agent.md 등), 현재 agent.md라는 표준화된 형식으로 수렴하는 흐름이 있다.
컨텍스트 생성의 또 다른 중요한 축은 외부 문서의 활용이다. LLM이 학습한 라이브러리 버전과 현재 사용 중인 버전이 다를 경우 환각(Hallucination)이 발생하기 때문에, 최신 라이브러리 문서를 직접 컨텍스트로 주입하는 방식이 효과적이다. 여기에 MCP(Model Context Protocol)가 결정적인 역할을 하고 있다. GitLab, GitHub, Slack 등 다양한 소스에서 컨텍스트를 끌어오는 것이 MCP를 통해 가능해졌고, 심지어 티켓(Issue) 하나를 가져오는 것 자체도 컨텍스트를 생성하는 행위다.
가장 발전된 형태는 **사양 주도 개발(Spec-Driven Development)**이다. 프롬프트를 단순한 명령이 아니라 명세서(Specification)처럼 작성하면, 에이전트가 이를 계획 모드(Planning Mode)로 분해하고 단계별 실행 계획을 스스로 수립한다. 이는 컨텍스트 생성이 단순한 “프롬프트 타이핑”을 넘어 소프트웨어 명세 작성에 가까워지고 있음을 의미한다.
Test: 컨텍스트를 어떻게 테스트하는가
Debois가 가장 강조하는 단계가 바로 테스트다. CLAUDE.md에서 두 줄을 바꿨을 때 그 변경이 어떤 영향을 미치는지 알 수 없다면, 결국 YOLO(“looks good to me, let’s do it”) 방식으로 운영하는 것과 다름없다. 코드에 테스트가 필요하듯, 컨텍스트에도 검증이 필요하다. AI 엔지니어링 세계에서 이를 **Eval(평가)**이라고 부르지만, 코딩 에이전트와 함께 일하는 일반 개발자들 사이에서는 아직 보편화되지 않았다는 점을 강연자는 지적한다.
테스트의 수준은 코드 테스트와 마찬가지로 여러 계층으로 나뉜다. 가장 기초적인 수준은 **린팅(Linting)**으로, IDE의 구불구불한 밑줄처럼 컨텍스트의 형식 오류나 필수 필드 누락을 잡아낸다. 그 위 수준은 Grammarly 유사 피드백으로, “이 컨텍스트를 읽고 에이전트가 이해할 수 있는지” LLM 자체에게 묻는 방식이다. 컨텍스트가 너무 짧거나 모호하면 에이전트가 올바른 행동을 할 수 없으므로, 작성한 컨텍스트의 명확성을 자동으로 검증하는 것이다. Debois는 개인적으로 타이핑보다 음성 코딩(Voice Coding)을 선호하는 이유도 말로 설명할 때 훨씬 더 풍부하고 명확한 컨텍스트가 생성되기 때문이라고 덧붙인다.
07:18 - 스킬(Skill) 포맷의 Linting 검증 예시 슬라이드. 설명 필드 존재 여부, 길이 제한 등 컨텍스트 형식을 검사하는 간단한 린터 규칙이 표시된 화면
더 높은 수준의 테스트는 LLM을 판사(Judge)로 활용하는 방식이다. 예를 들어 회사의 모든 API 엔드포인트는 /awesome 프리픽스를 사용해야 한다는 컨벤션이 agent.md에 명시되어 있다고 가정하자. “사용자 저장 엔드포인트를 추가하라”고 프롬프트를 보냈을 때, 생성된 코드에 실제로 /awesome/user가 포함되어 있는지를 또 다른 LLM에게 판단하게 할 수 있다.
09:26 - LLM을 판사(Judge)로 사용하는 컨텍스트 테스트 예시 코드 슬라이드. 생성된 코드가 ‘/awesome’ 프리픽스를 포함하는지 LLM이 판단하는 테스트 구조를 보여주는 화면
여기서 한 단계 더 나아가, Judge에게 도구(Tool)를 주어 에이전트로 만들면 엔드-투-엔드(End-to-End) 테스트가 가능해진다. 파일의 코드를 보는 것에 그치지 않고, 실제로 엔드포인트를 curl로 호출하고 결과를 검증하는 것이다. 이는 단순히 코드가 규칙을 따르는지를 보는 것을 넘어, 실제 동작이 의도한 대로 이루어지는지를 확인하는 통합 테스트에 해당한다. 특정 커밋 시점의 컨텍스트를 기준으로 이 시나리오를 실행하면, “이 컨텍스트 변경이 실제로 차이를 만들었는가”를 측정할 수 있다.
11:04 - Judge에게 도구(Tool)를 부여해 에이전트로 만드는 엔드-투-엔드 테스트 개념 슬라이드. curl 실행 등 실제 동작 검증이 가능한 구조를 설명하는 화면
한편 컨텍스트 테스트를 CI/CD 시스템에 통합하려 할 때 중요한 주의사항이 있다. 코드 테스트와 달리 Eval은 **비결정론적(Non-Deterministic)**이다. 동일한 테스트를 두 번 실행해도 결과가 다를 수 있기 때문에, “한 번 통과하면 성공”이라는 기준을 적용할 수 없다. Debois는 이를 SRE의 에러 버짓(Error Budget) 개념으로 접근하라고 제안한다. 동일한 테스트를 다섯 번 실행했을 때 몇 번이나 성공하는지를 측정하고, 테스트마다 허용 실패율을 다르게 설정하는 것이다. 중요한 컨벤션 테스트는 실패율을 최소화하고, 상대적으로 유연한 기준의 테스트는 어느 정도의 실패를 허용하는 식으로 운영한다.
Distribute: 컨텍스트를 패키지처럼 배포하기
테스트가 완성된 컨텍스트를 동료와 공유하는 가장 간단한 방법은 git 리포지토리에 체크인하는 것이다. 팀원이 clone하면 zero friction으로 동일한 컨텍스트를 사용할 수 있다. 그러나 여러 프로젝트, 여러 팀에 걸쳐 재사용하고 싶다면 더 구조화된 방법이 필요하다.
Debois는 이 문제를 소프트웨어 라이브러리와 패키지 관리 시스템의 개념으로 해결할 수 있다고 주장한다. 컨텍스트 조각들을 패키지로 묶고, 필요한 프로젝트에서 “설치”하는 방식이다. 이 개념이 확장되면 **레지스트리(Registry)**가 된다. Tessl의 마켓플레이스가 이 방향을 구현한 사례로, 다양한 스킬(Skill)을 탐색하고 가져올 수 있는 공간이다. 다만 강연자는 솔직하게 “현재 마켓플레이스에 있는 스킬의 99.9%는 품질이 낮다”고 언급한다. 다른 사람들이 어떻게 작업하는지 배우는 용도로는 유용하지만, Eval을 실행해보면 실제 품질 기준을 충족하는 스킬은 극히 드물다는 것이다. 그렇기 때문에 많은 조직이 자체 내부 레지스트리를 구축하려는 흐름이 생기고 있다.
14:49 - 컨텍스트 레지스트리와 패키지 의존성 개념 슬라이드. Tessl 마켓플레이스의 스킬 배포 구조 또는 의존성 관리 다이어그램이 표시된 화면
스킬은 단순한 컨텍스트 텍스트를 넘어 스크립트, 문서, MCP 연결 등 다양한 요소를 포함할 수 있는 복합 패키지로 진화하고 있다. 실제로 대부분의 주요 코딩 에이전트들이 스킬 포맷을 컨텍스트 배포의 표준 패키지 형식으로 채택하는 방향으로 움직이고 있다.
패키지 시스템이 성숙해지면 필연적으로 **의존성 지옥(Dependency Hell)**도 따라온다. 프론트엔드 컨텍스트 패키지를 설치했을 때 React 컨텍스트 패키지와 충돌이 생기는 상황은 npm의 악몽을 그대로 재현한다. 라이브러리 버전과 컨텍스트 버전이 짝을 이루어 관리되어야 하는 이유다.
보안 역시 중요한 문제다. 외부 레지스트리에서 낯선 사람이 만든 스킬을 다운로드해 로컬 머신에서 실행하는 것은 분명한 보안 위험을 수반한다. Snyk과 같은 보안 스캐너가 컨텍스트(스킬 파일)를 스캔하여 크리덴셜 노출이나 서드파티 코드 삽입 여부를 검사하는 방식이 이미 등장했다. 더 나아가 “이 스킬이 누가 만들었고, 어떤 모델로 생성되었는가”를 추적하는 **AI SBOM(Software Bill of Materials)**의 개념도 형성되고 있다. 소프트웨어 공급망 보안에서 SBOM이 필수가 되었듯, 컨텍스트 공급망에서도 동일한 흐름이 시작되고 있는 것이다.
17:01 - 컨텍스트 보안 스캐닝 개념 슬라이드. Snyk과 유사한 방식으로 스킬 파일의 크리덴셜 노출 및 외부 코드 삽입을 탐지하는 도구와 AI SBOM 개념을 설명하는 화면
Observe: 운영 환경에서 컨텍스트 관찰하기
컨텍스트 라이브러리를 만들어 배포한 이후, 다른 팀이 실제로 사용하는 과정에서 무언가 잘못되고 있다면 어떻게 알 수 있을까? Debois는 이 피드백 채널로 에이전트 로그를 적극 활용할 것을 제안한다. 팀 전체의 에이전트 로그를 분석했을 때 특정 컨텍스트가 반복적으로 누락되고 있다는 신호가 감지된다면, 그 부분에 대한 컨텍스트를 보완하여 배포하면 된다. agent.md 표준의 로그 포맷이 정착되면서 이런 피드백 채널을 자동화하는 것도 가능해지고 있다.
PR(Pull Request) 리뷰 역시 중요한 피드백 소스다. PR에서 “이 부분이 잘못됐다”는 코멘트가 달린다면, 그것은 해당 PR을 생성한 에이전트의 컨텍스트가 불충분했다는 신호다. PR을 두고 계속 논쟁하는 대신, 컨텍스트 자체를 개선하면 다음 반복에서 동일한 문제가 반복되지 않는다.
💡 [영상 참조] 강연자는 이 시점에서 프로덕션 코드를 계측(Instrument)하여 실패한 코드 변경을 컨텍스트 개선과 연결하는 도구의 슬라이드를 보여줍니다. 📺 원본 영상에서 확인하세요.
더 나아가 프로덕션 환경에서 실제로 실행 중인 코드의 피드백도 컨텍스트 개선 루프에 통합될 수 있다. 컨텍스트로부터 생성된 코드가 프로덕션에서 실패할 경우, “이 코드 변경이 실패를 유발했다, 여기서 테스트 케이스를 만들어 다음에 같은 문제가 반복되지 않게 하라”는 자동화된 피드백 루프를 구성할 수 있다.
보안 관찰의 측면에서 Debois는 에이전트 **샌드박싱(Sandboxing)**의 필요성을 강조하면서도 그 한계를 솔직하게 인정한다. 에이전트를 샌드박스 안에서 실행해 탈출 시도를 관찰해보면, 환경 변수 접근, 메모리 파일 열람 등 다양한 방식으로 시스템을 탐색한다는 것을 알 수 있다. 문제는 코딩 에이전트가 기본적으로 agent.md와 스킬 파일을 아무런 제한 없이 로드한다는 점이다. 외부에서 다운로드된 스킬이 즉시 로드되기 때문에 샌드박스만으로는 이를 막을 수 없다. 이를 보완하기 위해 Debois는 **컨텍스트 필터(Context Filter)**라는 개념을 제안한다. 웹 애플리케이션 방화벽(WAF)처럼 컨텍스트에 포함된 특정 패턴, 프롬프트 인젝션(Prompt Injection) 시도 등을 걸러내는 레이어다.
21:41 - 에이전트 샌드박싱과 컨텍스트 필터(Context Filter) 개념 슬라이드. 웹 애플리케이션 방화벽(WAF)에 대응하는 컨텍스트 레이어 필터링 구조를 도식화한 화면
개인에서 조직으로: 컨텍스트 플라이휠
Debois는 컨텍스트 개발 수명 주기를 세 가지 레벨로 구분한다. 첫 번째는 개인 루프로, 지금 대부분의 개발자가 하고 있는 것처럼 자신만의 마크다운 파일을 정제하고 다듬는 수준이다. 두 번째는 팀 루프로, 컨텍스트 라이브러리를 만들고 팀 내에서 공유하며 관찰을 통해 지속적으로 개선하는 단계다. 이 단계는 소나큐브(SonarQube)와 CI/CD를 결합한 모델과 유사하다. 세 번째는 조직 루프로, 한 팀이 컨텍스트를 개선하면 그 효과가 조직 전체로 퍼지는 플라이휠(Flywheel) 효과가 작동하는 단계다.
이 플라이휠이 작동하려면 “문제를 발견하면 컨텍스트를 추가한다”는 것이 팀의 반사적인 행동(Reflex)이 되어야 한다. 개인이 해결한 문제가 다른 팀도 가진 문제였다면, 그 컨텍스트 개선의 혜택이 자동으로 조직 전체에 전파되기 때문이다.
마무리: 엔진이 아닌 연료를 최적화하라
Debois는 LLM과 코딩 에이전트 자체는 “엔진”에 불과하다는 비유로 강연을 마무리한다. 엔진이 아무리 좋아도 잘못된 연료, 즉 불량한 컨텍스트를 주입하면 제대로 동작하지 않는다. LLM 자체를 수정하거나 제어할 수 있는 사람은 거의 없지만, 컨텍스트는 누구나 최적화할 수 있다. 그리고 그 최적화를 “운에 맡기는” 방식이 아니라, 엔지니어링된 방식으로 접근해야 한다는 것이 이 강연의 핵심 메시지다.
Q&A에서 청중이 던진 “코드와 일반적인 Eval 외에 유용한 컨텍스트 생성 소스가 있는가”라는 질문에 대해, Debois는 흥미로운 역설을 언급한다. 컨텍스트를 코딩 대신 작성하면 시간이 절약될 것 같지만, 제대로 된 Eval을 작성하는 데는 엄청난 시간이 필요하다. 프롬프트 하나가 아니라 모든 Eval의 프롬프트를 올바르게 만들어야 하기 때문이다. 실제로 고수준의 실무자들은 자신만의 Eval 구축 프로세스를 별도로 만들어 운용하고 있다고 그는 전했다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Context Is the New Code — Patrick Debois, Tessl |
| 채널 | AI Engineer |
| 강연자 | Patrick Debois (Tessl) |
| 리포트 작성 | 2026-05-04 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- Skills are the New SDKs - Elvin Aghammadzada, DataRobot
- Hierarchical Memory - Context Management in Agents — Sally-Ann Delucia
- Does GenAI belong to data scientists — Phil Hetzel, Braintrust
- Ralph Wiggum (and why Claude Code’s implementation isn’t it) with Geoffrey Huntley and Dexter Horthy
- How Google DeepMind Runs Agents at Scale — KP Sawhney & Ian Ballantyne, Google DeepMind