프롬프트 엔지니어링에 관해 읽은 대부분의 글은 틀렸습니다. 그 증거가 어디에 있는지 말씀드리겠습니다.
먼저 분명히 해두겠습니다. 이 글은 유출된 자료를 악용하거나 시스템을 탈옥(jailbreak)시키는 방법에 관한 것이 아닙니다. 저는 그 두 가지에 전혀 관심이 없고, 진짜 회사를 운영하는 당신도 관심을 가져서는 안 됩니다. 제가 관심 있는 것은 이것입니다. 깊이 사고해 설계된 프로덕션 시스템 프롬프트의 구조가, 실제 세상에서—압박 속에서, 스케일에서, 시스템을 깨려는 실제 사용자들 앞에서—작동하는 AI 에이전트 지시서를 작성하는 법에 관해 우리에게 무엇을 가르쳐주는가.
Anthropic은 관련 자료의 상당 부분을 스스로 공개해 왔습니다—공식 시스템 프롬프트 릴리스 노트를 참고하십시오. 그리고 Simon Willison은 이 프롬프트들이 어떻게 구조화되어 있고 무엇을 드러내는지를 가장 잘 기록해 온 공개 관찰자입니다. 유출된 프롬프트가 가치 있는 이유는 비밀을 드러내기 때문이 아닙니다. 진지한 프로덕션 스케일에서, 자기가 무엇을 하고 있는지 실제로 아는 팀이 강력한 모델에게 지시문을 어떻게 쓰는지를 보여주기 때문입니다. 그리고 그들이 지시문을 쓰는 방식은, 대부분의 창업자와 오퍼레이터가 에이전트에 프롬프트를 던질 때의 모습과 거의 닮은 점이 없습니다.
교훈 1: 구조가 곧 지시입니다
진지한 프로덕션 프롬프트를 읽을 때 가장 먼저 치고 들어오는 것은, 구조적 비계(scaffolding)의 양입니다. 헤더로 나뉜 섹션. 번호 매긴 규칙. 명시적인 역할 정의. 서로 다른 지시 카테고리를 구분하는 XML 태그. 이것은 스타일이 아닙니다. 이것 자체가 지시입니다.
당신이 모델에게 한 덩어리의 텍스트를 쏟아부으면, 모델은 프롬프트의 서로 다른 부분들이 무엇을 의미하고 어떻게 관계되는지 스스로 추론해야 합니다. 반면 당신이 모델에 명시적인 구조—"이 섹션은 안전에 관한 것이다, 이 섹션은 도구 사용에 관한 것이다, 이 섹션은 거절 기준에 관한 것이다"—를 주면, 헤더를 다 쓰고 난 시점에 이미 프롬프트 엔지니어링의 절반을 끝낸 셈입니다.
제가 아는 대부분의 창업자들은 이메일처럼 보이는 프롬프트를 씁니다. 인사, 한 문단, 요청, 서명. 그것은 당신의 회사를 이해하는 똑똑한 인턴에게는 통합니다. 적대적 조건 하에서, 스케일로, 동작하는 모델에는 통하지 않습니다.
교훈 2: 규칙은 예시를 이깁니다. 예시는 추상을 이깁니다.
진지한 프로덕션 프롬프트는 매우 특수한 계층 구조를 씁니다. 상단에 하드 룰("절대 X를 하지 말 것"). 중단에 구체적인 예시. 하단에 마지막 안전망으로서의 추상적 원칙. 유출된 Claude Code 프롬프트는 이 패턴을 거의 완벽하게 따릅니다.
대부분의 오퍼레이터가 작성한 프롬프트는 정반대입니다. 모호한 추상—"도움이 되고 정확하게 답하라"—으로 시작하고, 끝까지 하드 룰이나 구체적인 예시를 하나도 주지 않습니다. 모델은 최선을 다하지만, 닻이 없습니다. 그래서 그 행동은 당신이 예측할 수도, 재현할 수도, 디버깅할 수도 없는 방식으로 표류합니다.
제가 꼼꼼히 읽고 얻은 결론은 이렇습니다. 에이전트에 주는 모든 지시에는 올바른 출력이 어떤 모습인지 보여주는 최소한 하나의 구체적인 예시가 포함되어야 합니다. 만약 그 예시를 쓸 수 없다면, 저는 자신이 원하는 것을 충분히 이해하지 못한 것이고—에이전트는 더더욱 모를 것입니다.
에이전트에게 당신이 원하는 것의 좋은 예시를 보여줄 수 없다면, 에이전트는 그것을 당신을 위해 만들 수 없습니다. 예시가 곧 스펙입니다.
교훈 3: 거절 행동은 안전 문제가 아니라 설계 문제입니다
프롬프트의 상당 부분은 모델이 언제, 어떻게 무언가를 거절해야 하는지에 관한 것입니다. 단순히 "불법적인 것"에 국한되지 않습니다. 언제 거절할 것인가, 언제 반박할 것인가, 언제 명확화 질문을 할 것인가, 언제 그냥 진행할 것인가—에 관한 완전한 분류 체계가 있습니다. 그 분류 체계는 가정된 것이 아니라 엔지니어링된 것입니다.
회사를 위한 에이전트 제품을 짓고 있다면, "거절" 행동은 뒤늦게 떠올리는 것이 아닙니다. 그것은 당신의 프롬프트에서 가장 레버리지가 높은 단일 부분입니다. 왜냐하면 에이전트가 "더 많은 정보가 필요합니다"라고 말했어야 할 순간에 "최선을 다해 보겠습니다"라고 말할 때마다—또는 시도했어야 할 순간에 "그건 도와드릴 수 없습니다"라고 말할 때마다—당신은 사용자의 신뢰를 태우고 있고, 사용자에게 당신의 에이전트를 우회하는 법을 훈련시키고 있는 것이기 때문입니다. 말한 대로 실천하고, 실천한 대로 말합니다—이 원칙은 에이전트에게도 적용됩니다. 에이전트가 자기가 할 것과 하지 않을 것 사이에 분명한 선을 그을 수 없다면, 에이전트는 하지 말아야 할 것에 예스를 할 것이고, 해야 할 것에 노를 할 것입니다.
해피 패스(happy path)를 설계하기 전에 거절 분류 체계를 먼저 설계하십시오. 그것이 어른의 움직임입니다.
교훈 4: 도구 사용 지시는 작업 지시보다 더 많은 단어를 가져야 합니다
그 프롬프트에서 도구를 어떻게, 언제 사용할지에 관한 지시는 어떤 작업을 수행할지에 관한 지시보다 상당히 더 깁니다. 우연이 아닙니다. 도구 사용은 에이전트가 실제 세상에서 실패하는 지점입니다. 잘못된 도구를 호출하는 것. 올바른 도구를 잘못된 인자로 호출하는 것. 도구를 잘못된 순서로 호출하는 것. 명확화 질문을 먼저 했어야 할 순간에 도구를 호출하는 것.
당신 회사의 에이전트가 어떤 도구든—데이터베이스, API, 파일 시스템, 검색 인덱스—접근 권한을 갖고 있다면, 프롬프트 엔지니어링 시간의 최소 60%를 도구 사용 지시에 써야 합니다. 성격이 아닙니다. 톤이 아닙니다. 각 도구를 언제 꺼내 들 것인가, 그리고 그 도구가 자기가 할 일을 실제로 했는지를 어떻게 검증할 것인가의 역학입니다.
교훈 5: 프롬프트는 대화가 아니라 정책입니다
진짜 프로덕션 프롬프트를 읽으며 제가 얻은 가장 중요한 사고의 전환이 이것입니다. 시스템 프롬프트는 메시지가 아닙니다. 정책입니다. 에이전트가 그 아래서 운영되는 성문 헌법입니다. 법률 문서처럼 작성되어야 합니다—정밀하고, 모호하지 않고, 충돌하는 규칙 사이에 명시적인 우선순위가 있고, 엣지 케이스에 대한 구체적인 언어가 있는.
대부분의 창업자가 작성한 프롬프트는 대화체입니다. 신입 사원에게 보내는 Slack 메시지처럼 읽힙니다. 그 결과 만들어지는 에이전트는 5분짜리 온보딩을 받은 신입 사원처럼 행동합니다. 열정적. 대체로 도움이 됨. 이따금 재앙적. 날마다 일관성이 없음.
에이전트의 시스템 프롬프트를 변호사가 읽을 것처럼 다시 쓰십시오. 당신의 에이전트가 변호사처럼 말하기를 원하기 때문이 아닙니다. 그렇게 쓰기 위해 요구되는 바로 그 정밀성이, 1,000명의 사용자가 동시에 두드릴 때 에이전트가 일관되게 행동하기 위해 필요한 바로 그것이기 때문입니다.
제가 읽고 나서 실제로 한 것
제가 자기 도구에 프롬프트를 쓰는 방식에 가한 세 가지 실용적인 변화:
- 이제 저는 모든 새 에이전트 프롬프트를 구조적 아웃라인으로 시작합니다—역할, 하드 룰, 도구 사용 지시, 예시, 거절 분류 체계, 엣지 케이스—내용의 단 한 문장을 쓰기 전에.
- 저는 모든 주요 지시에 대해 최소 세 개의 구체적인 예시를 쓰도록 스스로를 강제합니다. 쓸 수 없다면, 그 지시는 아직 충분히 정의되지 않은 것입니다. 그것은 저에게 패배가 아니라 신호입니다.
- 저는 프롬프트를 버전 관리되는 정책으로 취급합니다. 모든 변경에 커밋 메시지가 붙습니다. 모든 변경이 동일한 시나리오 세트에 대해 테스트됩니다. 새벽 1시에 카우보이 편집은 없습니다.
이 습관들을 채택하기 위해 유출된 프롬프트를 읽을 필요는 없습니다. 그러나 언젠가 진지한 프로덕션 프롬프트를 손에 넣게 된다면—열린 마음으로, 주의 깊게, 한 번 읽어 보십시오. 그것은 이 글을 포함한 어떤 프롬프트 엔지니어링 블로그 글보다도 AI 에이전트에게 지시하는 법에 관해 더 많은 것을 가르쳐줄 것입니다.
당신에게 드리는 도전. 지금 당신의 가장 중요한 에이전트를 구동하는 시스템 프롬프트를 꺼내십시오. 계약서를 감사하는 변호사가 된 것처럼 그것을 읽으십시오. 모든 문장에 대해 물으십시오. 이 규칙은 구체적인가? 예시가 있는가? 우선순위는 모순을 만나도 살아남는가? 셋 중 하나라도 답이 '아니오'라면, 이번 주에 다시 쓰십시오. 작동하는 에이전트와 화요일 오후에 당신을 망신시키는 에이전트 사이의 격차는 거의 언제나 모델이 아니라 프롬프트에 있습니다.
제가 이 모든 것을 어떻게 일상 운영에 실제로 연결하는지에 대해서는 오퍼레이터의 콕핏 안의 AI를 참고하십시오.