AI 에이전트에 필요한 건 더 긴 프롬프트가 아니라 제어 흐름이라는 주장

• 글의 핵심 주장은 명확함. 복잡한 일을 안정적으로 처리하는 에이전트에는 “더 정교한 프롬프트”가 아니라 “코드로 짠 제어 흐름”이 필요하다는 것

  • MANDATORY, DO NOT SKIP 같은 문구를 프롬프트에 넣기 시작했다면 이미 프롬프트만으로 제어하려는 방식의 한계에 닿은 거라고 봄
  • 모델에게 강한 말투로 지시하는 건 실행 보장을 만드는 게 아니라, 그럴듯한 부탁을 더 길게 쓰는 것에 가깝다는 얘기임

• 글쓴이는 프롬프트 체인을 프로그래밍 언어에 비유해서 비판함

  • 만약 어떤 언어에서 문장이 “명령”이 아니라 “제안”이고, 함수가 환각을 섞어놓고도 Success를 반환한다면 로컬 추론이 불가능해짐
  • 복잡도가 커질수록 어디서 왜 틀렸는지 추적하기 어려워지고, 시스템 신뢰성은 무너진다는 논리임

• 소프트웨어가 확장되는 방식은 결국 재귀적 조합성이라는 지적도 나옴

  • 라이브러리, 모듈, 함수처럼 예측 가능한 단위를 쌓아 올리기 때문에 큰 시스템을 만들 수 있음
  • 반면 프롬프트 체인은 좁은 작업에는 유용해도, 비결정적이고 명세가 약하고 검증이 어려워서 같은 방식으로 확장하기 힘듦

• 그래서 필요한 건 결정적 스캐폴드임

  • 명시적인 상태 전이, 검증 체크포인트, 실패 처리 로직을 코드에 넣어야 함
  • 대규모 언어 모델(LLM)은 판단이나 생성이 필요한 일부 단계를 맡는 컴포넌트가 되고, 전체 흐름은 런타임이 통제하는 구조가 됨

• 하지만 제어 흐름만으로도 부족하고, 공격적인 오류 감지가 같이 필요하다고 말함

  • 에이전트는 실패해도 조용히 틀린 결론까지 빠르게 달려갈 수 있음
  • 중간 검증이 없으면 결과가 틀렸는지 모른 채 다음 단계가 계속 쌓이는 문제가 생김

• 검증이 없을 때 남는 선택지는 셋뿐이라는 표현이 꽤 찰짐

  • 베이비시터: 사람이 계속 중간에서 지켜보며 오류가 퍼지기 전에 잡음
  • 감사자: 실행이 끝난 뒤 전체 결과를 끝까지 다시 검증함
  • 기도: 그냥 결과를 믿고 받아들임. 요즘 말로 하면 바이브 수용임

sequenceDiagram
    participant 런타임
    participant 검증기
    participant 대규모언어모델
    participant 도구
    런타임->>대규모언어모델: 현재 상태와 작업 요청
    대규모언어모델-->>런타임: 후보 응답 생성
    런타임->>검증기: 응답 조건 검사
    검증기-->>런타임: 통과 또는 실패 반환
    런타임->>도구: 통과한 작업만 실행
    도구-->>런타임: 실행 결과 반환
    런타임->>검증기: 다음 상태 전이 가능 여부 확인

기술 맥락

• 이 글에서 말하는 선택은 에이전트의 핵심 로직을 프롬프트에 숨기지 말고 코드의 제어 흐름으로 끌어내자는 거예요. 왜냐하면 프롬프트는 모델이 따라주길 기대하는 문장에 가깝고, 코드는 실패 조건과 다음 단계를 명확히 표현할 수 있거든요.

• 대안은 프롬프트 체인을 계속 길게 만드는 방식이에요. 간단한 자동화에는 이게 빠르고 편하지만, 단계가 늘어나면 어떤 조건에서 멈추고 재시도하고 실패 처리할지 검증하기 어려워져요. 그래서 복잡한 작업일수록 런타임이 상태를 들고 있어야 해요.

• 구현 관점에서는 대규모 언어 모델(LLM)을 “판단하는 함수”처럼 다루는 쪽에 가까워요. 모델이 낸 답을 바로 믿는 게 아니라, 검증 체크포인트를 통과한 결과만 다음 도구 호출이나 상태 전이로 넘기는 식이에요.

• 이 접근이 중요한 이유는 에이전트 실패가 티 나게 터지지 않을 수 있기 때문이에요. 조용히 틀린 결론을 만들고도 성공처럼 보일 수 있으니, 사람이 계속 감시하지 않으려면 프로그램이 중간중간 틀렸음을 잡아내야 해요.