에이전트를 위한 '프롬프트 엔지니어링'은 잘못된 접근 방식입니다. 사실 당신은 분산 시스템 런북을 작성하고 있는 것입니다.

매주 누군가가 딱 한 가지 기능만 기가 막히게 수행하는 "프로덕션 에이전트" 데모를 올리곤 하지. 그럼 댓글창은 자기 에이전트는 맨날 삽질만 한다는 사람들로 도배가 돼. 내 생각에 이건 모델 성능 문제가 아니라, 접근 방식 자체가 잘못된 거야.

우리 대부분이 LLM을 처음 접했을 때, 똑똑한 사람한테 질문하듯이 아주 정확하게 프롬프트를 짜는 법을 배웠잖아. 명확하게 말하고, 배경 설명해주고, 형식 지정해주고 이런 거. 이런 방식은 한 번 주고받는 대화에는 아주 잘 먹혀. 근데 자율적으로 계속 돌아가야 하는 작업에서는 성공률이 40%도 안 나올걸.

이유는 수학에 있어. 네 에이전트가 단계별로 95%의 정확도를 보인다고 치자. 최신 모델치고는 진짜 대단한 수치지. 근데 작업이 10단계로 이어진다면? 성공률은 95%가 아니라 0.95^10, 즉 60% 정도밖에 안 돼. 20단계로 넘어가면 36%까지 곤두박질치지. 에러가 곱셈으로 누적되거든. 단계가 늘어날 때마다 도박을 하는 셈이야.

이게 에이전트한테 "좋은 프롬프트"가 뭔지 다시 정의하게 만들어.

대화형 프롬프트는 좋은 "결과물"을 내놓는 게 목적이야. 반면에 에이전트형 프롬프트는 신뢰할 수 있는 "프로세스"를 만들어야 해. N번의 연속적인 의사결정을 버티고, 모호한 상황에서도 헛소리(환각) 안 하고, 언제 멈추고 물어봐야 할지 정확히 알고, 툴이 에러를 뱉거나 아무것도 안 줄 때 어떻게 복구할지 명확한 가이드가 있어야 한다는 거지. 이건 그냥 요청사항이 아니라, 운영 매뉴얼(ops runbook)에 훨씬 가까운 문서야.

내가 직접 해보면서 효과를 본 것들은 이거야:

1. 모든 행동 전에 추론 단계를 강제해. ReAct 패턴(action:을 실행하기 전에 thought: 블록을 먼저 뱉게 하는 거)은 선택이 아니라 필수야. 이거 없으면 모델은 바로 행동으로 넘어가 버리는데, 그러면 복잡한 작업은 죄다 망가지거든.

2. 툴 호출 횟수를 명확하게 제한해. 제한 없이 루프를 돌리면 모델은 툴을 더 쓰려고 억지 질문을 만들어내. "웹 검색은 5번을 넘기지 마"처럼 확실한 상한선을 두면, 확률적인 루프가 딱 정해진 범위 안에서만 돌아가게 돼. 프롬프트 문장 다듬는 것보다 이 제약 조건 하나 거는 게 신뢰도 향상에 훨씬 도움 돼.

3. 툴 스키마를 공공 API 계약처럼 다뤄. 에이전트가 터지는 이유 대부분은 모델이나 프롬프트가 아니라, 애매한 툴 스키마 때문이야. 파라미터 타입 정확히 정하고, enum 제약 걸고, 모든 인자에 명확한 description을 달아놔야 호출이 깔끔하게 들어와. 스키마 설명이 애매하면 호출도 개판으로 나옴.

4. 실패 상황에 대한 행동을 명시해. 검색 결과가 없으면? 툴에서 에러가 나면? 작업이 애매하면 에이전트가 뭘 해야 할지 정해줘. 시스템 프롬프트에 안 적어두면 모델은 지 맘대로 그럴싸한 걸 지어내는데, 그게 우리가 원하는 결과일 리가 없지.

5. 제약 조건(Constraints) 필드는 나중에 덧붙이는 게 아니라, 아키텍처의 안전장치야. 처음 만드는 사람들은 이걸 선택 사항으로 보는데, 실제 프로덕션 에러 로그를 보면 전혀 아니거든.

이 문제 파고들다가 전체 루프 아키텍처를 상세하게 분석한 글을 썼어. 코딩 없이 ChatGPT나 Gemini에서 바로 돌려볼 수 있는 예제도 있고, 왜 에러 누적 때문에 "데모용" 신뢰도가 프로덕션에서는 안 통하는지 수학적으로도 정리해 뒀으니 참고해: https://appliedaihub.org/blog/autonomous-ai-agents-rise/

다들 신뢰도 높이는 데 효과 본 패턴 있으면 공유 좀 해줘. 특히 긴 세션에서 처음부터 다시 시작하지 않고 컨텍스트 오염(context drift) 해결하는 좋은 방법 아는 사람 있어?