AI-Assisted Engineering Talk #25/27
코딩 에이전트는 생각보다 단순한 구조로 이루어져 있습니다. UI, 모델, 하네스 — 이 세 조각이 전부이옵니다. 그런데 문제는 모델이 바뀔 때마다 하네스를 다시 짜야 한다는 것이지요. 프롬프트 튜닝, 도구 최적화, 컨텍스트 관리… 이 모든 것이 모델 세대마다 달라집니다. OpenAI Codex 팀이 제안하는 답은 명쾌합니다 — 하네스를 추상화 계층으로 삼아 SDK 벤더에게 위임하라. 그러면 여러분은 제품을 만드는 데만 집중할 수 있습니다.
코딩 에이전트의 해부학
에이전트 = UI + 모델 + 하네스
코딩 에이전트는 세 부분으로 구성됩니다. UI(CLI, IDE, 클라우드 에이전트), 모델(GPT-5.1, Codex Max 등), 그리고 하네스(프롬프트와 도구를 결합한 코어 에이전트 루프). 하네스가 모델과 직접 상호작용하는 핵심 레이어이며, 이 발표의 초점이옵니다.
하네스의 난제: “Way harder than you think”
하네스는 모델이 사용자 및 코드와 소통하고 도구를 실행하는 인터페이스 레이어입니다. 커스텀 도구의 모델 친화성, 모델별 프롬프트 튜닝, Thinking 모델 레이턴시, 컨텍스트 윈도우 관리와 컴팩션, MCP 플러밍, 이미지 해상도 압축, API 진화 추종 등 — 겉보기보다 훨씬 어려운 과제가 산적해 있습니다.
““People kind of over-complicate things. It’s made out of three parts.” Bill Chen — OpenAI Applied AI Startups” ## 모델의 습관을 이해하는 것이 전부입니다
모델 = Intelligence + Habit
모델은 Intelligence(어떤 언어와 프레임워크를 잘 아는가)와 Habit(문제를 풀 때 학습된 행동 패턴)으로 나뉩니다. OpenAI 모델의 훈련된 습관은 planning → context gathering → thinking → coding → testing. 프롬프트 엔지니어링의 본질은 모델의 지능을 끌어내는 것이 아니라, 모델의 습관과 정렬하는 것이옵니다.
과잉 프롬프팅의 역설
GPT-5 출시 시 발견된 반직관적 현상입니다. 다른 모델용 프롬프트를 그대로 적용하자 “모든 파일을 꼼꼼히 살펴라"는 지시가 이미 그렇게 훈련된 모델과 충돌하여 극심한 성능 저하가 발생했습니다. 모델에게 직접 물었더니 답은 명쾌했습니다 — “You’re telling me to go look at everything and I don’t really need to.” 과소 지시가 과잉 지시보다 낫습니다.
습관 정렬 = 프롬프트 엔지니어링의 본질
Cursor는 Codex 모델과 도구를 ‘in distribution’으로 정렬하여 최상 성능을 달성했습니다. 새 모델 도입 시 기존 프롬프트를 버리고 모델의 자연 습관을 먼저 관찰하는 것, 도구 설계를 모델의 훈련 분포에 맞추는 것 — 이것이 실무에서의 핵심 시사점이옵니다.
““Developing a feel for these habits is how you become a good prompt engineer.” Bill Chen — OpenAI” ## 하네스를 추상화 계층으로
하네스 SDK = 새 추상화 계층
하네스를 추상화 계층으로 삼아 모델 업그레이드 시 프롬프트와 도구 최적화를 SDK 벤더에게 위임하는 패턴입니다. “래퍼 아닌가?“라는 반론에 대해 — AWS가 서버의 래퍼가 아닌 것처럼, 하네스 SDK는 모델 복잡성의 추상화이옵니다. Zed는 Codex를 레이어로 감싸 IDE 인터페이스만 제공하고, 하네스 유지보수 부담 없이 코드 에디터 차별화에 집중합니다.
Agent-in-Agent: 도구를 만드는 도구
에이전트 진화의 세 단계: (1) 대화할 수 있는 챗봇, (2) 도구를 사용할 수 있는 챗봇, (3) 자신에게 없는 도구를 만들 수 있는 도구를 가진 챗봇. Codex를 SDK로 임베드하면 TypeScript 라이브러리, Python exec, GitHub Actions, MCP 커넥터를 통해 코딩에 한정되지 않는 “터미널을 위한 컴퓨터 사용 에이전트"가 됩니다.
Future-Proof의 정의와 메커니즘
정의: 모델이 바뀌어도 에이전트 하네스를 재작성하지 않아도 되는 속성. 메커니즘: 모델 습관 의존적 코드를 하네스 SDK에 캡슐화하여 벤더가 모델별 적응을 담당합니다. 제품 코드는 하네스 API 위에서만 동작하므로 모델 변경에 불투명합니다. 모델 세대가 진화하면 “trust ceiling"이 상승하고, SDK가 새 역량을 자동 노출합니다.
““Focusing most of your efforts on differentiating your product is what this pattern allows you to do.” Brian Fioca — OpenAI” ## 핵심 인사이트
💡 [Insight 1] 프롬프트 엔지니어링은 지능 추출이 아니라 습관 정렬이다
모델의 습관에 역행하는 지시는 지능을 낭비시킵니다. 모델이 이미 하는 행동을 다시 명령하지 않는 것 — 이것이 GPT-5 출시 때 가장 크게 배운 교훈이옵니다. 과잉 프롬프팅은 성능을 떨어뜨리고, 과소 지시가 오히려 나은 결과를 가져옵니다.
💡 [Insight 2] 하네스는 인프라다 — 직접 유지하지 말고 위임하라
모델이 바뀔 때마다 프롬프트를 다시 쓰고 도구를 재최적화하는 것은 AWS 없이 서버를 직접 관리하는 것과 같습니다. 하네스 SDK는 모델 복잡성을 추상화하는 인프라 레이어이며, 그 위에서 제품 차별화에 집중하는 것이 이 패턴의 핵심 가치이옵니다.
💡 [Insight 3] Spec은 What, Harness는 How
같은 OpenAI의 Sean Grove(영상 12)는 “명세가 새 코드"라 했고, Chen & Fioca는 “하네스가 새 추상화 계층"이라 합니다. 결합하면: Spec은 시간에 안정적인 what이고, Harness는 모델마다 달라지는 how이옵니다. Future-proofing은 Spec을 정본으로 고정하고 Harness의 모델 의존 부분을 최소화하는 것입니다.
💡 [Insight 4] 에이전트의 다음 진화: 도구를 만드는 도구
단순한 도구 사용을 넘어, 자신에게 없는 도구를 즉석에서 만들 수 있는 메타 도구의 등장. 엔터프라이즈에서는 고객별 API 플러그인 커넥터를 자동 생성하여, 과거 Professional Services 팀이 하던 일을 코드가 대체합니다. ## 반증과 맹점
SDK 벤더 = 단일 실패점
하네스를 벤더에게 위임하면 벤더의 적응 실패가 하위 전 제품의 동시 degradation으로 이어질 수 있습니다. 추상화의 레이턴시 비용도 무시할 수 없으며, 모델 고유 기능(새 추론 모드 등)에 즉시 접근하지 못하는 단점이 있습니다.
암묵적 모델 신뢰가 검증을 대체하는 위험
“Let the model do what it knows"라는 원칙은 명시적 검증 대신 암묵적 모델 역량 신뢰로 이어질 수 있습니다. 하네스 SDK 위임 시 검증 표면 소유권이 벤더로 이전되어 사용자의 검증 통제력이 약화될 수 있다는 점도 주의가 필요합니다.
다른 발표와의 교차 연결
- “명세가 새 코드” — 명세는 코드와 모델 가중치로 이중 컴파일되는 상위 소스. Grove의 정적 관점(Spec)과 Chen의 동적 관점(Harness)은 같은 현상의 양면입니다. Spec Internalization Depth가 모델 세대마다 높아지면 Harness 요구가 줄어든다는 결론에 도달합니다.
- Anthropic은 “루프는 사소하고, 도구와 프롬프트가 전부"라 했습니다. Chen & Fioca는 한 발 더 나아가 그 도구와 프롬프트 자체를 SDK로 추상화하자고 제안합니다. 같은 문제에 대한 내부화 vs 외부화 접근의 차이이옵니다.
- 12-Factor의 “모델을 쉽게 교체할 수 있어야 한다"는 원칙이 이 발표의 Future-Proof 개념과 직결됩니다. 하네스 SDK는 12-Factor의 모델 교체 가능성을 인프라 수준에서 해결하는 구현체이옵니다.
실무 적용 체크리스트
모델 습관 먼저 관찰
새 모델 도입 시 기존 프롬프트를 적용하기 전에, 모델의 자연 습관을 빈 프롬프트로 먼저 관찰하십시오.
과잉 프롬프팅 경계
모델이 이미 잘 하는 행동을 다시 명령하고 있지 않은지 점검하십시오. 과소 지시가 과잉 지시보다 나을 수 있습니다.
하네스 코드 감사
모델 특화된 프롬프트 튜닝이 제품 코드에 흩어져 있다면, 추상화 계층으로 격리할 수 있는지 검토하십시오.
도구를 in-distribution으로
커스텀 도구를 설계할 때 모델의 훈련 분포에 맞추고 있는지, 오픈소스 하네스 구현을 레퍼런스로 활용하십시오.
검증 표면 소유권 확인
하네스를 SDK에 위임할 경우, 검증 표면의 통제권이 어디까지 유지되는지 명시적으로 정의해 두십시오.
Spec과 Harness 분리
무엇을 할 것인가(Spec)와 어떻게 할 것인가(Harness)를 명확히 분리하여, Spec은 시간에 안정적인 정본으로 유지하십시오.
모델은 바뀌어도 명세는 남습니다. 하네스의 복잡성을 내려놓을 때, 비로소 제품이 보이기 시작하옵니다.