[Thoughts] 어제의 정석이 오늘의 안티패턴
AI agent instruction을 interface처럼 설계해야 하는 이유
정구봉님의 LinkedIn 피드를 읽다가 멈칫했다.
Claude Build Day에서 Anthropic Head of Engineering을 만나고 온 후기였는데, 핵심은 이거였다.
“베스트 프랙티스라고 붙잡고 있던 Claude Code 사용법이 거의 다 ‘그때는 맞고 지금은 틀린’ 정보가 돼 있었다.”
나도 비슷한 경험을 반복하고 있었다. instruction을 정성스럽게 짜놓으면, 몇 달 뒤에 그게 오히려 발목을 잡는다. 이게 반복되니까 뭔가 구조적으로 잘못된 거라는 생각이 들었다.
뒤집힌 세 가지
정구봉님이 정리한 건 세 가지였다.
1. Plan Mode → Auto Mode
Opus 4 시절에는 계획부터 세우는 게 정석이었다. 지금은 아니다. 바로 들어가는 게 더 잘 된다. 내가 끼워넣던 계획 단계가 오히려 방해였다.
2. 빽빽한 컨텍스트 → 최소한만 주기
시스템 프롬프트를 빽빽하게 깎는 데 시간을 많이 썼다. 지금은 반대다. 최소한만 주고 모델이 스스로 찾아가게 두는 게 낫다. 미리 떠먹여준 컨텍스트가 모델의 탐색을 막고 있었다.
3. 즉시 교정 → 영구 자산화
틀리면 그 자리에서 “이렇게 해”라고 다시 시켰다. 지금은 틀린 걸 CLAUDE.md에 적거나 skill로 만들어 둔다. 한 번 고치면 다음 세션부터 영구적으로 안 틀린다. 지적이 아니라 자산으로 쌓이는 구조.
Instruction은 Interface다
여기서 한 걸음 더 생각해봤다.
이 세 가지를 관통하는 게 뭘까. 개발자 시절 Java를 만지던 습관이 남아서인지, 떠오른 비유가 하나 있다.
Agent instruction을 concrete class처럼 짜면 모델이 바뀔 때마다 깨진다. Interface처럼 짜야 한다.
1
2
3
4
5
// ❌ 구현을 하드코딩
"먼저 plan을 세우고, 3단계로 나누고, 각 단계마다 확인을 받아라"
// ✅ 인터페이스만 정의
"사용자의 의도를 정확히 달성하라. 품질 기준은 X다."
Interface로 설계하면:
- 모델이 바뀌어도 instruction을 안 고쳐도 된다
- how를 열어두니까 모델의 탐색 공간이 넓어진다
- 교체 비용 ≈ 0. 인터페이스는 안정적이고, 구현만 swap
반면 “plan mode 강제”, “CoT 형식 지정”, “도구 호출 순서 고정” 같은 건 구현 상속이다. 모델 세대가 바뀌면 깨진다.
뭐가 Interface이고, 뭐가 Implementation인가
| Interface (오래 감) | Implementation (금방 구식됨) |
|---|---|
| 목표, 품질 기준, 제약조건 | 구체적 사고 절차, 도구 호출 순서 |
| “정확하게, 간결하게” | “먼저 검색하고, 결과를 요약하고…” |
| 도메인 지식, 용어 정의 | 모델 약점 보완용 가드레일 |
| 보호 규칙 (정보 마스킹 등) | 특정 모델 버전에 최적화된 프롬프트 기법 |
이걸 실제 agent 프로젝트에 적용하면 이런 구조가 된다.
Before: 하나의 설정 파일에 페르소나, 워크플로우, 문체, 프로세스를 전부 하드코딩.
After:
1
2
3
4
5
6
7
8
9
10
config (interface — 불변 규칙만)
├── 페르소나
├── 보호 규칙
├── 품질 기준
└── 유형 → 외부 참조
templates/ (implementation — 교체 자유)
├── task_type_a.md
├── task_type_b.md
└── task_type_c.md
새 유형 추가? 템플릿 파일 하나 추가하면 된다. 핵심 설정은 안 건드린다.
Self-Improvement 없는 Agent는 감가상각 자산이다
여기서 불편한 진실이 하나 있다.
고정된 system prompt + 고정된 instruction으로 구성된 agent는 본질적으로 감가상각 자산이다. 모델이 분기마다 크게 바뀌는 환경에서, 과거 모델의 약점을 보완하려고 넣은 가드레일은 새 모델에선 족쇄가 된다.
완전한 self-improvement는 아직 미해결 문제다. 하지만 최소한 이런 구조는 갖출 수 있다:
- Instruction의 계층 분리 — 원칙(interface)과 전술(implementation)을 나눠서, 전술만 교체 가능하게
- 실수의 자산화 — 세션 단위 교정이 아닌, 영구적으로 학습되는 구조
- 주기적 재검증 — “이 instruction이 아직 유효한가?”를 평가하는 루프
결국 구축보다 갱신 비용을 낮추는 아키텍처가 장기적으로 이기는 구조다.
마무리
“어제의 정석이 오늘의 안티패턴”이라는 말은 2015년 Google의 Ilya Grigorik이 O’Reilly Velocity Conference에서 한 말에서 유래한 것으로 보인다.
“Yesterday’s perf best-practices are today’s HTTP/2 anti-patterns”
HTTP/1.1의 정석(도메인 샤딩, 스프라이트)이 HTTP/2에선 오히려 성능을 깎았듯, AI 에이전트의 best practice도 같은 운명을 겪고 있다.
베스트 프랙티스를 오래 붙잡을수록 손해를 본다. 잘 버리는 사람이 이긴다.
다만, 잘 버리려면 버리기 쉬운 구조로 만들어놔야 한다. 그게 인터페이스다.
1년 뒤엔 이 글도 틀린 게 될 거다. 솔직히 지금 맞는지도 모른다. 정해진 게 없고, 개척하는 중이니까. 그래도 그래서 재밌다.