AI 코딩 에이전트가 똑똑해질수록, 결과를 좌우하는 건 코드보다 컨텍스트(context)가 된다는 메시지를 전합니다. 패트릭 드부아는 컨텍스트도 코드처럼 생성-평가-배포-관측의 수명주기로 관리해야 하며, 그렇지 않으면 "그냥 복붙 프롬프트" 수준에 머문다고 강조합니다. 핵심은 테스트 가능한 컨텍스트, 조직이 재사용 가능한 컨텍스트, 그리고 관측(로그/프로덕션 피드백) 기반으로 계속 개선되는 플라이휠을 만드는 것입니다.
1. 오프닝: "AI 코딩 에이전트, 다들 써보셨나요?"
발표자는 컨퍼런스의 아키텍트 트랙을 직접 열며(트랙 호스트가 없어 본인이 진행), 청중에게 분위기를 풀 듯 질문을 던집니다. AI 코딩 에이전트를 써본 사람과 안 써본 사람을 손들게 하더니, 안 써본 사람을 보고 "내 사람들"이라며 웃으며 시작해요.
"AI 코딩 에이전트를 이 방에서 써본 분? 손 들어보세요."
"안 써본 분? 손 들어보세요."
"좋아요, 내 사람들. 완벽하네요."
그리고 오늘의 주제를 꺼냅니다. 제목은 "Context Is the New Code", 또는 "Context Development Life Cycle(컨텍스트 개발 수명주기)"입니다. 아직 다듬어지지 않은 생각일 수도 있지만, 지금 AI 시대에 필요한 질문이라고 깔아둡니다.
"이건 좀 '미완성' 아이디어예요. 다 정리된 건 아니죠. 근데 AI에서 뭐가 완벽하게 정리돼 있긴 한가요?"
2. 왜 "컨텍스트가 새로운 코드"가 되었나
발표자는 요즘 개발이 "코드를 직접 만지는 일"보다, AI에게 "어떻게 일하라고 시키는지"로 바뀌고 있다고 말합니다. 이른바 바이브 코딩(vibe coding)—프롬프트로 분위기/의도를 전달하며 코딩하는 흐름을 전제로 깔아요.
"이제 여러분 다 프롬프트로 바이브 코딩하고 있죠. 저는 코드 거의 안 만져요. 그냥 AI에게 '이거 다르게 해줘'라고 말하죠."
그가 말하는 핵심 변화는 두 가지입니다.
-
컨텍스트가 계속 생성된다
AI에게 지시하고, 규칙을 적고, 참고자료를 붙이고, 기억을 쌓는 행위가 모두 "코드만큼 중요한 산출물"이 됩니다. -
코드가 다시 컨텍스트로 '변환'되기도 한다
예전엔 코드로 직접 구현하던 복잡한 로직이, 이제는 재사용 가능한 스킬(skill)이나 워크플로우 형태의 컨텍스트로 바뀐다는 거예요.
그는 제품 온보딩 사례를 듭니다. 사용자마다 Python/Node.js 등 환경이 다르고 패키지 매니저도 다 다른데, 이를 전부 코드로 처리하려면 개발량이 폭발합니다. 하지만 AI 에이전트에게 "먼저 패키지 매니저를 파악하고, 생태계를 파악한 뒤, 사용자와 함께 단계적으로 진행하라"는 스킬(재사용 가능한 컨텍스트)로 만들면 해결 범위가 더 커진다는 거죠.
"이걸 코드로 다 처리하는 건 사실상 불가능해요. 코딩이 엄청 많이 필요하죠."
"근데 스킬로 '패키지 매니저 파악 → 생태계 파악 → 단계별로 사용자와 진행'이라고만 주면, 우리가 코드로는 절대 못 풀 문제를 더 많이 풀어요."
여기서 결론: 컨텍스트는 단순 프롬프트가 아니라, 재사용 가능한 '제품/팀의 지식과 규칙'이 되고 있습니다. 그래서 관리 방식도 달라져야 합니다.
3. 컨텍스트 개발 수명주기: Generate → Evaluate → Distribute → Observe
패트릭은 2009년 DevOps를 처음 이야기할 때의 비유를 가져옵니다. 당시에는 "Ops를 Dev처럼" 만들자는 발상이었고, 협업/배포 자동화/프로세스 혁신으로 이어졌습니다. 지금은 비슷하게 "컨텍스트를 코드처럼" 다뤄야 한다는 거예요.
"2009년에 'Ops가 Dev처럼 보이면 어떨까?'라고 던졌죠. … 이제는 '컨텍스트가 코드라면?'을 생각해요."
그래서 소프트웨어 개발 수명주기(SDLC)가 있듯이, 컨텍스트 개발 수명주기(CDLC)를 제안합니다. DevOps 감성답게 무한 루프(infinity loop)로 설명해요.
- Generate(생성): 컨텍스트를 만든다
- Evaluate(평가): 컨텍스트를 테스트한다
- Distribute(배포): 팀/조직에 공유·패키징한다
- Observe(관측): 실제 사용/로그/프로덕션 결과로 피드백을 얻는다
- 그리고 다시 개선하며 반복 🔁
"우리는 컨텍스트를 많이 만들어요. 그다음 테스트하고, 배포하고, 실제로 동작하는지 관측해요. 안 되면 적응해서 다시 생성하죠."
4. Generate: 컨텍스트는 어떻게 만들어지는가
여기서는 사람들이 가장 익숙한 구간부터 정리합니다. 컨텍스트 생성은 단순히 프롬프트 치는 것에서 끝나지 않고, 점점 재사용·표준화·외부지식 결합으로 확장되고 있다고 말해요.
4.1 사람 손으로 프롬프트를 쓰는 가장 기본 형태
발표자는 AI에게 "내 발표가 언제냐" 같은 걸 물었더니 웹사이트를 긁어와서 정확히 알려준 경험을 들며, 기본 컨텍스트("나는 Patrick이다" 같은)만 줘도 꽤 많은 일을 한다고 합니다.
"그냥 '내 발표가 AI Engineer에서 언제야?' 물었는데 웹사이트를 가져와서 '여기요' 하더라고요. 진짜 놀랐죠."
4.2 재사용 가능한 프롬프트: instructions / agent.md
프롬프트를 매번 치는 건 귀찮으니 재사용 가능한 컨텍스트 파일이 등장합니다. 에이전트 생태계에서 agent.md 같은 표준이 생기고 있다고 언급하며, 특정 도구가 자기만의 이름을 쓰는 건 살짝 놀리기도 합니다.
"재사용 프롬프트가 필요해요. 요즘은
agent.md같은 표준화가 좀 생기고 있죠."
"Claude는 아직도Claude.md라고 부르긴 하지만… 뭐, 느낌 아시죠."
4.3 최신 문서/라이브러리 지식을 끌어오는 컨텍스트
LLM이 최신 문서(버전2인지 3인지)를 모를 수 있어 환각이 생기니, 라이브러리 문서를 다운로드해 컨텍스트로 제공하라는 얘기도 합니다.
"LLM이 최신 문서를 모를 수 있어요. 그럼 '버전2? 버전3?' 헷갈리며 환각하죠."
"그래서 '문서를 내려받아 컨텍스트로 넣어라'고 하면 그 버전에 맞게 더 잘 코딩해요."
4.4 GitHub/GitLab/Slack/티켓 등 "업무 흔적"도 컨텍스트
MCP든, 저장소든, 채팅이든, 티켓이든… 개발 과정에서 생기는 거의 모든 게 컨텍스트로 빨려 들어옵니다.
"GitHub, GitLab, Slack… 어디서든 컨텍스트를 끌어옵니다."
"티켓도 컨텍스트예요. 우리는 그걸 끌어와서 일하니까요."
4.5 스펙 기반 개발: 프롬프트를 "명세"로 쓰기
최근 흐름으로 spec-driven development(명세 중심)도 언급합니다. 먼저 명세를 쓰고, 에이전트가 계획 모드로 쪼개 단계별 실행 프롬프트로 변환해 실행하는 방식이죠.
"프롬프트를 명세처럼 쓰고, 에이전트가 계획 모드로 쪼개서 단계별로 실행하는 방식도 나오고 있어요."
5. Evaluate: 컨텍스트도 "테스트"해야 한다
여기서 발표는 확 궤도를 틉니다. 사람들이 agent.md를 두 줄 바꾸고도 "뭐 되겠지(YOLO)" 하고 넘어가는데, 그 영향이 얼마나 큰지 모르고 있다는 거예요.
"Claude.md(=agent.md)에서 두 줄 바꾸면, 영향이 뭔지 아세요?"
"그냥 'YOLO, 좋아 보이네' 하고 가는 건가요?"
그는 컨텍스트도 코드처럼 테스트 전략이 필요하다고 말하면서, "evals(이밸)"—즉 컨텍스트에 대한 테스트를 제안합니다.
"이제는 코드만 있는 게 아니라 컨텍스트도 있어요. 영향도를 보려면 테스트가 필요하죠."
"AI 엔지니어링에선 eval이 익숙하지만, 'AI로 코딩하는 현장'에선 아직 흔하진 않아요."
5.1 린팅(linting)처럼: 형식/스펙 검증
코드에 린터가 있듯, 컨텍스트(스킬 등)도 스펙에 맞는지 검증할 수 있습니다. 예를 들어 설명(description) 길이 제한 같은 규칙을 체크하는 형태죠.
"설명이 꼭 있어야 한다, 길이는 이 정도여야 한다… 이런 걸 스펙으로 검증할 수 있어요."
5.2 Grammarly처럼: "이 문장이 에이전트가 이해할 수준인가?"
형식만 맞아도 내용이 부실하면 에이전트가 못 알아듣습니다. 그래서 "이 컨텍스트 이해했어?"라고 물어 피드백을 받는 방식으로 품질을 올릴 수 있다고 합니다. 이때 그는 자신이 타이핑보다 음성으로 말할 때 더 자세히 설명하게 된다는 개인 팁도 덧붙여요 😄
"두 단어만 던지면 에이전트가 이해하기엔 너무 부족하죠."
"그래서 '이 컨텍스트 이해했어?'라고 물어서 피드백을 받는 거예요."
"저는 음성 코딩이 좋아요. 말로 하면 더 자세히 설명하게 되거든요. 타이핑은… 아직도 두 손가락이라서요."
5.3 규칙 준수 테스트: 'awesome' 접두사 예시
회사 규칙으로 "모든 API 엔드포인트는 /awesome으로 시작해야 한다"고 해봅시다. 컨텍스트에 그 규칙을 넣어두면 에이전트가 새 엔드포인트를 만들 때 /awesome/user 같은 형태로 생성하길 기대합니다.
그리고 이를 LLM Judge(심판 LLM)에게 평가하게 할 수 있다고 말해요. (물론 regex로도 되지만 예시로 든다고 밝힙니다.)
"모든 API 엔드포인트는
/awesome접두사를 써라."
"컨텍스트 없이 같은 질문을 하면, 어떤 LLM도 URL에 'awesome'을 붙여주지 않아요."
또 모델마다 반응이 달라질 수 있으니(예: Gemini vs Copilot), 컨텍스트를 '스위처블'하게 만들고 테스트로 차이를 확인하자고 합니다.
"Gemini는 다르게 반응하고 Copilot도 다를 수 있어요. 그래서 테스트를 돌려봐야 차이를 알죠."
5.4 도구를 쥔 Judge: 엔드투엔드 테스트까지 확장
진짜로 중요한 건 "코드 텍스트가 규칙을 만족하느냐"가 아니라 "실제로 돌아가느냐"입니다. Judge에게 도구를 주면(샌드박스에서 실행), curl로 호출해보는 식으로 엔드투엔드 테스트가 됩니다.
"저는 코드만 보는 게 아니라, 실행해서 엔드포인트를 테스트하고 싶어요."
"Judge에게 도구를 주면, Judge가 에이전트가 돼서 샌드박스에서 curl도 할 수 있죠."
"그럼 이건 사실상 end-to-end 테스트예요."
또 "특정 커밋 + 특정 컨텍스트" 조합에서 시나리오를 돌려 컨텍스트가 결과를 바꿨는지를 판단할 수도 있다고 설명합니다.
5.5 테스트 결과로 컨텍스트 자동 개선
테스트가 있으면 피드백을 기반으로 "컨텍스트를 고쳐라/개선하라"를 자동화할 수도 있습니다(예: GitHub Actions 같은 곳에서).
"피드백이 있으니 '이 컨텍스트 고쳐, 개선해'라고 자동화할 수 있어요."
5.6 CI/CD에 올릴 때의 함정: 비결정성(undeterministic)
하지만 eval을 CI/CD에 넣으면 문제가 생깁니다. LLM은 항상 같은 결과를 내지 않기 때문이죠. 그래서 "한 번 돌려 패스/실패"로 판단하면 디버깅 지옥이 온다고 경고합니다.
"eval을 한 번 돌리고, 또 돌리면 결과가 같지 않을 수 있어요."
"한 번에 패스/실패로 판단하면 '이거 왜 안 되지?' 디버깅 못 합니다."
대신 여러 번 돌려 성공률을 보고, 테스트별로 허용 실패를 다르게 두는 에러 버짓(error budget) 관점이 유용하다고 말합니다.
"다섯 번 돌려서 다섯 번 중 몇 번 성공했는지 보세요."
"저는 이걸 에러 버짓처럼 생각하는 게 도움이 되더라고요."
6. Distribute: 컨텍스트를 팀과 조직에 "배포"하는 법
이제 컨텍스트를 나 혼자 쓰는 게 아니라, 팀/조직이 쓰려면 공유·패키징·발견·보안이 필요하다고 말합니다.
6.1 저장소에 넣는 공유: 마찰이 거의 없는 방식
컨텍스트를 repo에 체크인하면 동료가 체크아웃하면서 바로 공유됩니다.
"repo에 컨텍스트를 넣으면, 동료가 체크아웃하는 순간 공유가 되죠. 마찰이 거의 없어요."
6.2 여러 프로젝트/팀에서 재사용하려면 "패키지"가 필요
하나의 프로젝트가 아니라 여러 프로젝트에서 쓰려면, 코드에서 라이브러리가 있었듯 컨텍스트도 패키지화해야 합니다. 그리고 패키지를 찾으려면 레지스트리(registry)가 필요하죠.
"여러 팀/프로젝트에서 재사용하려면, 라이브러리처럼 패키징해야죠."
"패키지를 발견하려면 레지스트리가 필요합니다."
그는 스킬(skills)과 Tessl 레지스트리/마켓플레이스 같은 흐름을 언급합니다.
6.3 마켓플레이스의 현실: "대부분 품질이 낮다"
여기서 꽤 직설적으로 말합니다. 많은 스킬이 학습에는 도움이 되지만, 품질 기준(evals)을 통과할 만큼 좋지는 않다는 거예요.
"현실적으로 말하면… 스킬의 99.9%는 별로예요."
"그래도 남들이 어떻게 하는지 배우는 데는 도움이 되죠."
6.4 스킬은 텍스트만이 아니라 스크립트/문서 등 묶음이 된다
스킬 패키지에는 컨텍스트뿐 아니라 스크립트, 문서 등 여러 구성요소가 들어갈 수 있고, 플러그인/MCP까지 포함되는 방향으로 표준이 형성되는 중이라고 봅니다.
"스킬은 컨텍스트만 담는 게 아니에요. 스크립트도 문서도 여러 걸 담죠."
"코딩 에이전트들이 '이걸 패키지 포맷처럼 지원한다'고 하기 시작했어요."
6.5 컨텍스트도 의존성 지옥이 온다
패키지가 생기면 의존성 충돌이 생기듯, 컨텍스트 패키지도 React 규칙 패키지와 프론트엔드 가이드라인 패키지가 충돌하는 식의 dependency hell이 생길 수 있다고 경고합니다.
"죄송하지만… 컨텍스트도 의존성 지옥이 옵니다."
6.6 보안: 낯선 컨텍스트를 내 노트북에서 실행하는 시대
레지스트리에서 받은 스킬은 결국 내 환경에서 실행될 수 있습니다. 그래서 보안이 중요해졌고, 컨텍스트 자체를 스캔하는 도구 흐름도 등장합니다(예: 자격증명 노출 등).
"낯선 사람이 만든 걸 내 노트북에서 실행할 수 있잖아요. 그래서 보안이 필요해요."
"Snyk 같은 스캐너가 컨텍스트도 스캔하기 시작했죠."
또 "누가 만들었는지, 어떤 모델로 만들었는지" 같은 출처·구성 정보를 담는, 일종의 AI SBOM(컨텍스트 패키지 명세서) 같은 개념도 이야기합니다.
"누가 만들었나? 어떤 모델로 만들었나? … 패키징 세계의 SBOM처럼, AI SBOM이 필요해질 거예요."
7. Observe: 로그와 프로덕션에서 피드백을 수집해 개선한다
여기서부터는 "컨텍스트를 라이브러리처럼 배포했을 때" 진짜 중요한 질문이 나옵니다. 다른 사람이 쓰기 시작하면, 그게 여전히 잘 작동하는지 어떻게 알 것인가?
"다른 사람이 쓰기 시작하면, 이게 아직도 잘 되는지 어떻게 피드백을 받죠?"
7.1 에이전트 로그가 최고의 피드백 채널
팀/조직 차원에서 에이전트 로그를 보면 "어떤 컨텍스트가 자꾸 빠지는지" 패턴이 보이고, 이를 공통 컨텍스트로 만들어 배포하면 모두가 이득을 봅니다.
"조직 차원에서 로그를 보면, 에이전트가 '이게 없어요'라고 말하는 패턴이 보이죠."
"모두가 빠뜨리는 거라면, 그 컨텍스트를 만들어 배포하면 모두가 개선돼요."
또 로그에 대한 표준도 생기고 있어서("agent ND"라고 언급) 피드백 채널로 유용해진다고 말합니다.
7.2 PR 리뷰도 사실은 "컨텍스트에 대한 피드백"
PR에서 "이건 틀렸어요"라는 피드백을 계속 논쟁으로만 끝내지 말고, "그 PR을 만든 컨텍스트가 뭔가 부족했구나"라고 보고 컨텍스트를 개선하자는 제안입니다.
"PR에서 '이거 틀렸어'라는 건 컨텍스트에 대한 피드백이에요."
"PR에서 계속 싸우지 말고, '컨텍스트를 개선하자'고 하면 다음번엔 같은 문제가 안 생기죠."
7.3 프로덕션 실패가 가장 강력한 피드백
코드 리뷰를 통과해도 프로덕션에서 실패할 수 있습니다. 그는 "프로덕션에서 실패한 변경 코드 조각"을 추적하고, "입출력이 뭐가 잘못됐는지"를 잡아 다음에 재발하지 않도록 테스트 케이스로 만들자고 합니다.
"진짜 피드백은 프로덕션에서 나와요."
"실패한 변경 코드, 잘못된 입출력… 이걸로 테스트 케이스를 만들면 다음에 같은 실수를 안 하죠."
7.4 에이전트의 '이상 행동'을 막기 위한 관측과 격리
에이전트는 샌드박스에서도 "탈출하려고" 매우 자원ful(교활하게 유능)할 수 있다고 말합니다. 환경변수/메모리 파일 등을 뒤질 수 있으니 추적(트레이싱)과 관측이 필요하다는 거죠.
"샌드박스 안에 둬도, 에이전트는 탈출할 만한 걸 엄청 잘 찾아요."
"환경변수… 메모리 파일… 그래서 추적할 수 있어야 해요."
하지만 중요한 함정이 하나 있습니다. 샌드박스로 "실행 환경"을 막을 수는 있어도, 코딩 에이전트는 기본적으로 agent.md, skill.md 같은 컨텍스트를 자동으로 로드합니다. 즉, 다운로드한 순간 이미 컨텍스트가 들어가 버리니 샌드박스만으로는 막기 어렵다는 거예요.
"코딩 에이전트는 기본적으로 agent.md, skill.md를 그냥 로드해요. 아무도 막지 않죠."
"다운로드하면 즉시 로드됩니다. 샌드박스로는 그걸 필터링 못 해요."
그래서 그는 컨텍스트 필터(context filter)라는 개념을 제안합니다. 웹 애플리케이션 방화벽(WAF)처럼 프롬프트 인젝션 패턴 등을 필터링하는 계층이 필요하다고요.
"저는 이걸 컨텍스트 필터라고 불러요."
"웹 방화벽처럼 프롬프트 인젝션 패턴을 걸러내는 거죠."
또한 이런 관측/로그/트레이스 중심 접근은 하네스 엔지니어링(harness engineering)과도 맞닿아 있다고 덧붙입니다.
8. 결론: 엔진(LLM)보다 연료(컨텍스트)가 성능을 좌우한다
마지막으로 발표자는 루프를 두 층으로 정리합니다.
- 개인/저자 관점 루프: 컨텍스트 생성 + 테스트(라이브러리 저작 도구 루프)
- 조직 관점 루프: 누군가 사용 → 관측 → 개선 → 재배포(스케일링 루프)
그리고 대부분이 아직은 개인 단위로 프롬프트를 다듬는 수준에 머물러 있는데, 이를 팀의 "반사작용(reflex)"으로 만들자고 권합니다. "빠진 게 있으면 컨텍스트를 추가한다"가 팀 문화가 되면, 다른 팀도 재사용하면서 조직 전체에 플라이휠이 돌기 시작한다는 거죠.
"여러분은 지금 혼자서 마크다운을 다듬고 있죠."
"이걸 팀으로 해보면 어떨까요? 빠진 게 있으면 컨텍스트를 추가하는 걸 '반사적으로'요."
"팀의 팀으로 확장하면 플라이휠이 생겨요. 여기서 고치면 다른 팀이 재사용하죠."
가장 인상적인 비유로 메시지를 못 박습니다. LLM과 코딩 에이전트는 엔진이고, 컨텍스트는 연료라는 말이에요. 엔진을 바꾸기 어렵다면, 우리가 통제 가능한 연료(컨텍스트)를 엔지니어링하자는 제안입니다.
"코딩 에이전트와 LLM은 그냥 엔진이에요."
"엔진에 잘못된 연료, 즉 컨텍스트를 넣으면 성능이 안 나옵니다."
"저는 LLM을 바꾸진 못해요. 하지만 컨텍스트는 최적화할 수 있죠."
"복사-붙여넣기하고 '되겠지' 하는 방식 말고, 엔지니어링 방식으로요."
마지막으로 링크드인으로 슬라이드를 공유하니 연결해달라고 하고, Tessl에서 일부 아이디어를 구현하고 있으니 써보라고 권합니다. 또 본인이 콘텐츠를 큐레이션하는 AI DevCon(런던, 6월 1~2일)도 안내한 뒤 Q&A로 넘어갑니다.
9. Q&A: "더 '이상한(exotic)' 컨텍스트 형태는요?"
질문자는 전통적 컨텍스트(프롬프트/문서) 말고, 아키텍처 문제를 정의하고 목표/테스트로 변환하는 자동화 시스템을 만들고 있다며 의견을 묻습니다. 특히 "일관성(consistency)" 자체를 eval로 삼는 접근을 소개해요. 같은 느슨한 정의를 여러 번 '선명한 정의'로 변환했을 때 결과가 들쭉날쭉하면 원 정의가 나쁘고, 결과가 일관되면 꽤 괜찮은 정의라는 식입니다.
"일관성을 컨텍스트 또는 eval로 쓸 수 있을까요?"
"여러 번 돌렸을 때 '선명한 정의'가 계속 같으면 괜찮고, 다르면 원 정의가 너무 나쁜 거죠."
패트릭은 "그 exotic 케이스에 대한 딱 떨어지는 답"을 주기보다는, 사람들이 과소평가하는 현실을 짚습니다. 코드 대신 컨텍스트를 쓰면 시간이 절약될 거라고 생각하지만, 진짜 시간은 '올바른 eval을 작성하는 데' 많이 들어간다는 거예요. 그리고 고급 사용자들은 비즈니스 케이스에 맞는 eval을 만들기 위해, eval을 만드는 "자기만의 프로세스"까지 위에 쌓는다고 답합니다.
"여러분이 코드를 덜 쓰고 컨텍스트로 시간을 절약할 줄 알았겠지만…"
"이걸 제대로 하려면 '올바른 eval을 쓰는 데' 시간이 들어요."
"이제는 프롬프트 하나만 맞추는 게 아니라, eval 프롬프트들까지 다 맞춰야 하거든요."
"고급 사용자들은 비즈니스 케이스에 맞는 eval을 만들기 위한 자기 프로세스를 또 만들어요."
질문을 고맙게 받으며 추가 질문을 받고, 이후 부스에 있을 테니 인사하라고 마무리합니다.
"좋은 질문입니다. 감사합니다."
"질문 없으면… 저는 여기저기 있을게요. Tessl 부스에도 있을 겁니다."
마무리
이 발표는 AI 코딩 시대의 핵심 과제가 "더 좋은 모델을 고르는 일"만이 아니라, 컨텍스트를 코드처럼 체계적으로 다루는 엔지니어링이라는 점을 강조합니다. 특히 컨텍스트 테스트(evals), 패키징/레지스트리/보안, 로그·PR·프로덕션 기반 관측을 통해 컨텍스트를 지속 개선하는 구조를 만들면, 개인 수준의 프롬프트 요령을 넘어 조직 단위의 생산성 플라이휠로 확장할 수 있다는 메시지로 귀결됩니다.