통제가 아니라 맥락
여러분 에이전트의 프롬프트에 있는 모든 규칙은 버그에서 시작되었습니다.
누군가 나쁜 동작을 보고, 규칙을 쓰고, 넘어갔습니다. 다른 누군가도 똑같이 했습니다. 세 번째 사람은 모델이 어느 화요일에 한 번 이상한 짓을 했다는 이유로 "절대 X를 하지 마"를 추가했습니다. 아무도 무엇 하나 지우지 않았습니다.
여섯 달 뒤, 에이전트는 실제 작업을 생각하는 것보다 자신의 규칙집을 헤쳐 나가는 데 더 많은 컨텍스트 윈도를 쓰고 있습니다.
그것이 통제 방식의 사고입니다. 그리고 저는 그것이 팀이 AI 에이전트를 만들 때 저지르는 가장 큰 설계 실수 중 하나라고 생각합니다.
더 큰 패턴을 드러내는 작은 예시
우리는 예약된 작업으로 트리거된 에이전트가 실행 도중에 계속해서 새로운 예약 작업을 만들어 내는 문제에 부딪혔습니다. 무한 재귀, 다만 현실 세계의 부작용을 동반한 채로요.
대응하는 두 가지 방법이 있습니다.
통제 방식: 금지하세요. 스케줄이 스케줄을 만들지 못하게 막는 코드를 작성하세요. 프롬프트 규칙을 추가하세요. "스케줄 안에서 절대 스케줄을 만들지 마." 그리고 출시하세요.
맥락 방식: 실제로 무슨 일이 일어나고 있는지 에이전트에게 알려 주세요.
너는 태평양 시간 오전 3:00에 예약된 작업으로 트리거되었어. 스케줄 ID: sched_29x8f. 예약 실행은 사용자가 원래 승인한 정해진 범위를 가진 격리된 실행이야. 새로운 예약 작업을 만드는 것은 그 범위를 원래 승인 너머로 확장하는 것이 돼.
첫 번째 접근은 하나의 동작을 땜질합니다. 두 번째는 에이전트에게 그 상황에 대한 모델을 제공합니다.
이제 에이전트는 인접한 질문들에 대해서도 추론할 수 있습니다. 오전 3시에 알림을 보내야 할까? 사용자가 명시적으로 요청하지 않은 후속 프로세스를 만들어야 할까? 원래 실행의 범위를 넘어 확장하는 무언가를 수정해야 할까?
규칙은 필요 없습니다. 에이전트가 스스로 알아냈습니다.
많은 팀이 실제로 필요한 것이 맥락일 때 통제에 손을 뻗습니다.
프롬프트 안에서도 같은 구분이 나타납니다
이것은 시스템 수준의 강제에 관한 것만이 아닙니다. 맥락 대 통제의 갈림은 프롬프트 안에도 존재합니다.
맥락 방식 프롬프팅: 대체로 사실, 의견은 최소한으로.
너는 예약된 작업 때문에 실행되고 있어. 베이징 시간 오전 3:00에 트리거되었어. 작업 ID: sched_29x8f. 사용자는 특정 범위에 대해 이 실행을 승인했어.
통제 방식 프롬프팅: 의견이 담기고, 지시적인.
스케줄 만드는 것을 피해. 도구 X로 사용자에게 알려야 해. Z가 아니면 절대 Y를 하지 마.
때로는 지시적인 명령이 유용합니다. 하지만 아주 흔히 그것들은 빠진 사실을 보충하고 있습니다. 그리고 일단 그런 식으로 보충하기 시작하면, 중독성이 생깁니다.
프롬프트가 관료제가 되는 과정
이것이 더 깊은 실패 양상입니다.
팀이 문제를 보고 규칙을 추가합니다. 그러고 나서 또 하나. 그리고 또 하나. 각각은 국지적인 문제를 땜질하지만, 함께 모이면 대리물(proxy) 로 가득한 시스템을 만들어 냅니다.
Bezos는 2016년 주주 서한에서 이 패턴을 묘사했습니다. 좋은 프로세스는 여러분이 고객을 섬길 수 있도록 여러분을 섬깁니다. 하지만 조심하지 않으면, 프로세스 그 자체가 목적이 되어 버립니다.
그것이 바로 에이전트 시스템에서 일어나는 일입니다.
규칙은 목적이 아닙니다. 규칙은 여러분이 원하는 결과의 대리물입니다. 그리고 대리물은 복리로 불어납니다. 하나가 더 많은 것을 요구하는 엣지 케이스를 만들어 냅니다. 곧 에이전트는 누구도 온전히 기억하지 못하는 어떤 역사적 이유로 각각 추가된, 켜켜이 쌓인 지시들을 헤치며 추론하게 됩니다.
인간 조직에서 이것은 관료제가 됩니다. 에이전트 시스템에서는 흉터 조직으로 가득한 거대한 프롬프트가 됩니다.
사실은 나이 들고, 의견은 썩는다
"이 실행은 오전 3시에 예약된 작업으로 트리거되었다" 같은 사실은 안정적입니다. 어떤 모델이 그것을 읽든 — Claude, GPT, Gemini, 다음 분기에 무엇이 나오든 — 참으로 남습니다.
"하위 스케줄 만드는 것을 피해야 한다" 같은 진술은 깨지기 쉽습니다. 그것은 해석에 의존합니다. 어떤 상황에서는 도움이 되고, 다른 상황에서는 조용히 빗나갈 수 있습니다.
모델을 교체할 때, 프롬프트 안의 모든 의견은 잠재적인 지뢰입니다. 새 모델은 다른 추론 성향을 가지고 있고, 여러분이 정성껏 보정한 "피해"가 그 모델에게는 완전히 다른 것을 의미할 수도 있습니다.
하지만 환경, 권한, 범위, 제약에 대한 근거 있는 사실은 모델과 엣지 케이스 전반에 걸쳐 일반화되는 경향이 있습니다. 그렇기 때문에 사실이 더 나은 건축 자재입니다.
모델 특이성의 함정
이것은 통제 문제의 가장 음흉한 버전일지도 모릅니다. 팀은 일시적인 모델 결함을 끊임없이 영구적인 시스템 구조로 바꿔 놓습니다.
모델이 어떤 좁은 경우에 나쁘게 동작합니다. 팀은 가드레일을 추가합니다. 프롬프트 패치, 코드 체크, 오직 하나의 특정 실패 양상을 막기 위해서만 존재하는 이상한 분기.
그 패치는 그 특이성이 지속될 것이라는 데 거는 베팅입니다. 그것은 거의 결코 지속되지 않습니다.
세 달 뒤, 모델이 바뀝니다. 원래의 동작은 사라집니다. 하지만 패치는 남습니다. 아무도 그것을 제거하고 싶어 하지 않습니다. 어쩌면 어떤 이유가 있어서 거기 있었을지 모르니까요.
이것이 시스템 프롬프트가 레거시 코드가 되는 과정입니다.
추상적으로 진술하면 우리는 그 위험을 쉽게 알아볼 수 있습니다. 하지만 실제로, Sonnet의 현재 추론 성향을 프롬프트마다 땜질하는 것은 모습만 바꾼 같은 패턴입니다.
안정적인 시스템 동작을 문서화하는 것은 가치 있습니다. 모델의 추론 성향을 땜질하는 것은 쳇바퀴입니다. 모델은 여러분이 패치를 유지할 수 있는 것보다 빠르게 발밑에서 바뀔 것입니다.
좋은 테스트 사례: 권한 거부
도구 진단에서 그 구분을 명확히 볼 수 있습니다. 에이전트가 권한 오류에 부딪혔을 때.
통제 방식:
TOKEN이 없어. "zero permissions request gmail.send"를 실행해서 고쳐.
직접적이지만, 에이전트는 아무것도 배우지 못합니다. 다음번에 다른 권한 오류에 부딪히면, 막혀 버립니다.
맥락 방식:
process.env.GMAIL_TOKEN → 존재함 zero connectors inspect gmail → 연결됨 zero permissions inspect gmail.send → 거부됨
선택지:
- gmail.send에 대해 사용자 승인을 요청한다
- 이미 승인된 경로가 있다면 그것을 사용한다
이제 에이전트는 토큰이 존재하고, 커넥터가 작동하며, 특정 권한이 거부되었다는 것을 압니다. 시스템의 상태를 이해하고, 규칙을 쓴 사람이 결코 예상하지 못한 새로운 상황에 대해 추론할 수 있습니다.
휴리스틱
제가 계속 돌아오게 되는 것은 이것입니다.
프롬프트에 "하지 마", "피해", 또는 "절대"를 쓰려 할 때마다. 멈추세요. 물으세요. 이 규칙은 어떤 사실을 보충하고 있는가?
대개 빠진 사실이 있습니다. 에이전트는 자신이 어떤 환경에 있는지, 사용자가 무엇을 승인했는지, 어떤 행동이 되돌릴 수 없는지, 또는 왜 이 실행이 일반적인 채팅 상호작용과 다른지를 이해하지 못합니다.
그 사실을 적어 두세요. 규칙은 지우세요.
때로는 여전히 제약을 원할 것입니다. 특히 파괴적인 행동, 자금 이동, 또는 안전 경계 주변에서요. 강한 통제는 여전히 중요합니다.
하지만 많은 프롬프트 규칙은 진정한 경계가 아닙니다. 그것들은 빠진 이해에 대한 보충입니다. 그리고 그것들이야말로 쌓이고 썩는 것들입니다.
목표
목표는 체크리스트를 암기하는 에이전트가 아닙니다.
목표는 명확한 경계 안에서 좋은 결정을 내릴 만큼 자신의 상황을 충분히 이해하는 에이전트입니다.
한 철학은 규칙을 쌓아 올려 동작을 통제합니다. 다른 철학은 세계를 읽을 수 있게 만들어 동작을 개선합니다.
첫 번째는 관료제로 기웁니다. 두 번째는 이해로 기웁니다.
맥락을 쌓으세요. 흉터 조직을 지우세요. 생각할 수 있는 에이전트를 출시하세요.
