--- title: "AI 에이전트에 필요한 건 더 긴 프롬프트가 아니라 제어 흐름이라는 주장" published: 2026-05-07T16:43:35.000Z canonical: https://jeff.news/article/2322 --- # AI 에이전트에 필요한 건 더 긴 프롬프트가 아니라 제어 흐름이라는 주장 이 글은 복잡한 작업을 안정적으로 처리하는 AI 에이전트를 만들려면 프롬프트 체인을 더 정교하게 만드는 것만으로는 부족하다고 주장한다. 핵심 로직은 코드와 런타임의 결정적 제어 흐름으로 옮기고, 대규모 언어 모델은 전체 시스템이 아니라 검증 가능한 컴포넌트로 다뤄야 한다는 내용이다. - 글의 핵심 주장은 명확함. 복잡한 일을 안정적으로 처리하는 에이전트에는 “더 정교한 프롬프트”가 아니라 “코드로 짠 제어 흐름”이 필요하다는 것 - `MANDATORY`, `DO NOT SKIP` 같은 문구를 프롬프트에 넣기 시작했다면 이미 프롬프트만으로 제어하려는 방식의 한계에 닿은 거라고 봄 - 모델에게 강한 말투로 지시하는 건 실행 보장을 만드는 게 아니라, 그럴듯한 부탁을 더 길게 쓰는 것에 가깝다는 얘기임 - 글쓴이는 프롬프트 체인을 프로그래밍 언어에 비유해서 비판함 - 만약 어떤 언어에서 문장이 “명령”이 아니라 “제안”이고, 함수가 환각을 섞어놓고도 `Success`를 반환한다면 로컬 추론이 불가능해짐 - 복잡도가 커질수록 어디서 왜 틀렸는지 추적하기 어려워지고, 시스템 신뢰성은 무너진다는 논리임 - 소프트웨어가 확장되는 방식은 결국 재귀적 조합성이라는 지적도 나옴 - 라이브러리, 모듈, 함수처럼 예측 가능한 단위를 쌓아 올리기 때문에 큰 시스템을 만들 수 있음 - 반면 프롬프트 체인은 좁은 작업에는 유용해도, 비결정적이고 명세가 약하고 검증이 어려워서 같은 방식으로 확장하기 힘듦 > [!IMPORTANT] > 이 글의 결론은 “LLM을 쓰지 말자”가 아니라 “LLM을 시스템 그 자체로 두지 말고, 검증 가능한 런타임 안의 컴포넌트로 다루자”에 가까움. - 그래서 필요한 건 결정적 스캐폴드임 - 명시적인 상태 전이, 검증 체크포인트, 실패 처리 로직을 코드에 넣어야 함 - 대규모 언어 모델(LLM)은 판단이나 생성이 필요한 일부 단계를 맡는 컴포넌트가 되고, 전체 흐름은 런타임이 통제하는 구조가 됨 - 하지만 제어 흐름만으로도 부족하고, 공격적인 오류 감지가 같이 필요하다고 말함 - 에이전트는 실패해도 조용히 틀린 결론까지 빠르게 달려갈 수 있음 - 중간 검증이 없으면 결과가 틀렸는지 모른 채 다음 단계가 계속 쌓이는 문제가 생김 - 검증이 없을 때 남는 선택지는 셋뿐이라는 표현이 꽤 찰짐 - 베이비시터: 사람이 계속 중간에서 지켜보며 오류가 퍼지기 전에 잡음 - 감사자: 실행이 끝난 뒤 전체 결과를 끝까지 다시 검증함 - 기도: 그냥 결과를 믿고 받아들임. 요즘 말로 하면 바이브 수용임 ```mermaid sequenceDiagram participant 런타임 participant 검증기 participant 대규모언어모델 participant 도구 런타임->>대규모언어모델: 현재 상태와 작업 요청 대규모언어모델-->>런타임: 후보 응답 생성 런타임->>검증기: 응답 조건 검사 검증기-->>런타임: 통과 또는 실패 반환 런타임->>도구: 통과한 작업만 실행 도구-->>런타임: 실행 결과 반환 런타임->>검증기: 다음 상태 전이 가능 여부 확인 ``` --- ## 기술 맥락 - 이 글에서 말하는 선택은 에이전트의 핵심 로직을 프롬프트에 숨기지 말고 코드의 제어 흐름으로 끌어내자는 거예요. 왜냐하면 프롬프트는 모델이 따라주길 기대하는 문장에 가깝고, 코드는 실패 조건과 다음 단계를 명확히 표현할 수 있거든요. - 대안은 프롬프트 체인을 계속 길게 만드는 방식이에요. 간단한 자동화에는 이게 빠르고 편하지만, 단계가 늘어나면 어떤 조건에서 멈추고 재시도하고 실패 처리할지 검증하기 어려워져요. 그래서 복잡한 작업일수록 런타임이 상태를 들고 있어야 해요. - 구현 관점에서는 대규모 언어 모델(LLM)을 “판단하는 함수”처럼 다루는 쪽에 가까워요. 모델이 낸 답을 바로 믿는 게 아니라, 검증 체크포인트를 통과한 결과만 다음 도구 호출이나 상태 전이로 넘기는 식이에요. - 이 접근이 중요한 이유는 에이전트 실패가 티 나게 터지지 않을 수 있기 때문이에요. 조용히 틀린 결론을 만들고도 성공처럼 보일 수 있으니, 사람이 계속 감시하지 않으려면 프로그램이 중간중간 틀렸음을 잡아내야 해요. ## 핵심 포인트 - 복잡한 에이전트에는 프롬프트보다 결정적 제어 흐름이 필요하다고 주장함 - 프롬프트 체인은 비결정적이고 검증이 어려워 복잡도가 커질수록 신뢰성이 떨어진다고 봄 - 명시적 상태 전이와 검증 체크포인트를 두고 대규모 언어 모델을 시스템의 일부 컴포넌트로 취급해야 한다고 제안함 - 검증이 없으면 사람 감시, 사후 감사, 그냥 믿기 중 하나에 의존하게 된다고 지적함 ## 인사이트 요즘 에이전트 개발에서 자주 보이는 “프롬프트를 더 세게 쓰면 되겠지” 흐름에 찬물을 끼얹는 글이다. 실제 제품을 만들려면 모델의 똑똑함보다 실패를 감지하고 되돌릴 수 있는 소프트웨어 구조가 더 중요하다는 얘기라, 꽤 정곡을 찌름.