프롬프트는 대화가 아니라 계약이다: 에이전트가 ‘업무’를 하게 될 때 팀이 바꿔야 할 것

thumbnail

밤 11시쯤이었다. 배포 하나가 애매하게 걸렸고, 채널에는 “그냥 stop 하고 내일 보죠”가 올라왔다.

나는 똑같이 썼다. “stop.”

그런데 몇 분 뒤에 PR이 하나 더 올라왔다. 또 커밋이 붙었다. 로그를 보면 아까랑 같은 실패를 다시 밟고 있었다.

여기서부터 사람들은 서로를 보기 시작한다. “누가 시켰어?” “난 stop 하라고 했는데?”

사실 둘 다 맞다. 사람은 stop을 말했고, 시스템은 stop을 ‘명령’으로 받지 않았다.

이 경험 이후로 나는 프롬프트를 대화로 취급하지 않는다. 계약서로 취급한다. 계약서에 없는 건, 하지 않는 게 원칙이다.


‘상태(state)’가 없으면 업무는 계속 리셋된다

채팅은 기억을 전제로 한다. 방금 한 말을 상대가 기억하고, 맥락을 쌓고, 그 위에서 다음 말을 한다.

하지만 에이전트가 하는 일은 채팅이 아니라 작업이다. 작업은 “어디까지 했는지”가 남아야 한다. 그렇지 않으면 매번 처음부터 다시 시작한다. 이때 생기는 대표적인 문제가 두 가지다.

  • 같은 맥락을 매번 다시 설명하느라 토큰/시간이 쌓인다.
  • 실패를 밟은 자리까지 다시 가서 또 실패한다.

Computerworld가 다룬 ‘stateful AI’ 이야기를 읽으면, 이게 기술 유행이라기보다 업무 요건이라는 게 드러난다. 멀티스텝 실행, 승인, 재시도, 감사 같은 걸 하려면 상태를 들고 있어야 한다. 상태가 없으면 “업무”는 성립이 안 된다. (참고자료)

내가 여기서 얻은 결론은 단순하다.

  • 프롬프트가 길어지는 건 종종 ‘설명’이 아니라 ‘상태를 흉내 내는 비용’이다.
  • 상태를 어디에 둘지(벤더/우리 DB/티켓 시스템)를 정하지 않으면, 팀은 언젠가 “왜 매번 처음부터 해?”로 싸운다. 우리는 일단 ‘티켓’ 한 곳으로 박는다.

계약서가 없으면, 좋은 의도는 그냥 구멍이 된다

“AI는 인간처럼 생각하지 않는다. 인간처럼 말하지 마라”는 류의 조언이 가끔 훈계처럼 들리는데, 실제로는 운영 경고에 가깝다. 말은 부드럽지만, 시스템은 종종 압축(compaction)되고, 지시는 유실되며, ‘상식적인 멈춤’이 자동으로 붙지 않는다. (참고자료)

그래서 프롬프트를 ‘좋은 말’로 쓰면, 구멍이 된다.

“조심히/안전하게/가능하면” 같은 말은 통제가 아니라 구멍이다. stop 사례가 딱 그랬다.

좋은 의도는 리뷰어를 설득하지만, 시스템을 통제하지는 못한다.


결정적 워크플로우가 필요한 순간(그리고 왜 통제탑이 생기는지)

ServiceNow의 ‘자율 인력’ 이야기를 읽고 나서, 내 결론은 이거였다. 확률적인 모델을 붙이더라도 조직은 결국 결정적인 워크플로우에서만 움직인다. 누가 승인하는지, 어떤 경계 안에서만 실행되는지, 기록은 어디에 남는지. 통제탑(control tower) 얘기가 나오는 이유가 여기 있다. (참고자료)

즉, “프롬프트 잘 쓰기”보다 먼저 “프로세스에서 멈추기”가 필요하다.


프롬프트 계약서 10줄(복붙용)

아래는 내가 ‘대화’가 아니라 ‘업무’로 올릴 때, 프롬프트 상단에 박는 문장들이다. 예쁘게 쓰지 말고, 실행되게 써야 한다.

  • 목적: 이 작업의 성공 조건은 ___ 이다(테스트/승인/산출물).
  • 범위: 수정 가능한 경로는 /docs, /configs 까지(그 외는 제안만).
  • 금지: ___ 는 절대 건드리지 않는다.
  • 승인: 실행(명령/머지/배포)은 코드오너 1명 승인 전까지 금지.
  • 중단: 동일 실패 3회면 즉시 중단하고 사람 호출(커밋/재시도 금지).
  • 재시도: 자동 재시도는 ___회까지만.
  • 상태: 작업 상태는 ___(티켓/DB/PR 본문) 한 곳에만 기록.
  • 근거: 모든 결론은 한 줄 근거를 남긴다(근거: PR# + 실패 로그 한 줄).
  • 도구: 허용 도구는 ___, 금지 도구는 ___.
  • 보고: 완료/중단 시 요약 3줄(무엇/왜/다음).

이걸 적으면 ‘답변’은 조금 덜 자연스러워질 수 있다. 대신 “stop 했는데 왜 또 했어?” 같은 대화는 확 줄어든다.


‘채팅→업무’로 승격해도 되는지 묻는 질문 5개

  • 이 작업은 실패해도 되돌릴 수 있나? 되돌리는 버튼은 어디에 있나?
  • 중단 조건이 숫자로 박혀 있나? (예: 3회 실패면 중단)
  • 상태를 어디에 남길 건가? 한 곳으로 모을 수 있나?
  • 승인이 필요한 순간이 명확한가? “승인 전 금지”가 문장으로 적혀 있나?
  • 출처/근거를 남기는 형식이 고정돼 있나?

5개 중 하나라도 “그때 가서”라면, 아직은 채팅 수준이 맞다. 업무로 올리면 팀이 버거워진다.

출처/근거 계약은 다음 글에서 따로 다룬다. (이번 글은 “멈춤/상태/승격”까지만.)


참고자료

  • Computerworld — OpenAI launches stateful AI on AWS, signaling a control plane power shift
    • https://www.computerworld.com/article/4138831/openai-launches-stateful-ai-on-aws-signaling-a-control-plane-power-shift-2.html
  • Computerworld — AI doesn’t think like a human. Stop talking to it as if it does
    • https://www.computerworld.com/article/4138071/ai-doesnt-think-like-a-human-stop-talking-to-it-as-if-it-does.html
  • Computerworld — ServiceNow plans automation of L1 Service Desk roles, promises more AI ‘specialists’ to come
    • https://www.computerworld.com/article/4138040/servicenow-plans-automation-of-l1-service-desk-roles-promises-more-ai-specialists-to-come-2.html

댓글