프롬프트 그만 늘리세요 — AI 에이전트는 제어 흐름이 답입니다

요즘 AI 에이전트 만든다는 분들 이야기를 들어보면, 다들 비슷한 벽에 부딪힙니다. 프롬프트를 100줄, 200줄까지 늘렸는데도 에이전트가 엉뚱한 도구를 호출하거나, 같은 일을 두 번 하거나, 중요한 단계를 빼먹습니다. 그래서 또 프롬프트에 “절대 X 하지 마"를 한 줄 더 추가하죠. 그런데 이게 진짜 해결책일까요?

최근 개발자 커뮤니티와 유튜브 강의들에서 공통적으로 나오는 메시지가 하나 있는데요, “프롬프트 엔지니어링은 한계가 있다”는 겁니다. 진짜 동작하는 에이전트를 만들려면 프롬프트가 아니라 제어 흐름(control flow)을 설계해야 한다는 이야기입니다. 이게 무슨 말인지, 왜 지금 이런 흐름이 강해지는지 풀어보겠습니다.

왜 프롬프트만으로는 안 되는가

LLM이 똑똑해지면서 한동안 분위기는 “프롬프트만 잘 쓰면 다 된다"였습니다. 시스템 프롬프트에 모든 규칙을 욱여넣고, few-shot 예시를 잔뜩 붙이고, “단계별로 생각해” 같은 마법의 주문도 넣었죠.

문제는 에이전트가 여러 단계의 의사결정을 해야 할 때 드러납니다. 예를 들어 “고객 문의를 받아서 → DB 조회하고 → 환불 가능한지 판단하고 → 가능하면 처리하고, 아니면 상담사 연결” 같은 흐름이요. 프롬프트로 이걸 다 통제하려고 하면, LLM이 한 번이라도 추론을 잘못 하는 순간 전체가 무너집니다.

ForrestKnight라는 개발자가 올린 영상 “Everything You Need to Know About Coding with AI"는 15만 회 넘게 조회됐는데, 핵심 메시지가 단순합니다. “vibe coding 하지 말고 구조부터 잡아라." AI에게 일을 맡기되, 일이 흘러가는 골격은 사람이 짜야 한다는 거죠.

제어 흐름이 뭔가요

쉽게 말하면 “언제 LLM을 부르고, 언제 안 부를지”를 코드로 정해두는 겁니다. 모든 판단을 LLM에게 떠넘기지 않는다는 뜻이에요.

전통적인 소프트웨어 엔지니어링에서 늘 하던 일이죠. if문, for문, switch문, 상태 머신(state machine), 워크플로우 엔진. 이런 것들이 다 제어 흐름입니다. 에이전트 시대라고 이게 사라진 게 아니라, 오히려 더 중요해졌습니다.

예를 들어볼게요. 사용자 입력을 받았을 때:

• 의도 분류 → 이건 LLM이 잘함
• 의도가 “환불"이면 → 코드로 분기
• 환불 정책 체크 → 이건 그냥 SQL 쿼리
• 정책 통과하면 → 결제 API 호출 (LLM 안 거침)
• 실패하면 → 사람에게 에스컬레이션

여기서 LLM이 하는 일은 “분류"와 “사용자에게 친절하게 응답하기” 정도입니다. 나머지 골격은 다 결정론적인 코드예요. 이게 안정적으로 돌아가는 에이전트의 모습입니다.

“STOP Building AI Agents” — 역설적인 제목의 진짜 의미

Zubair Trabzada가 올린 “STOP Building AI Agents. Do THIS Instead.” 영상은 23만 회 조회됐는데, 제목이 도발적이지만 메시지는 명확합니다. “무작정 자율 에이전트부터 만들지 말고, 워크플로우부터 짜라”는 거예요.

업계에서 부르는 용어로는 workflow와 agent의 구분입니다. 워크플로우는 미리 정의된 단계를 따라가는 것, 에이전트는 LLM이 매 단계 다음 행동을 결정하는 것. 둘 다 필요하지만, 대부분의 비즈니스 문제는 워크플로우로 해결됩니다. 정말 동적인 의사결정이 필요한 좁은 구간에만 에이전트적 자율성을 주면 되는 거죠.

이게 왜 중요하냐면, 토큰 비용과 지연 시간 때문입니다. 매 단계 LLM을 호출하면 응답이 5초씩 걸리고 비용도 폭발합니다. 코드로 처리할 수 있는 부분을 코드로 처리하면, 사용자 경험과 비용이 둘 다 좋아집니다.

그럼 프롬프트 엔지니어링은 죽었나요

아닙니다. 자리를 옮긴 거예요. IBM Technology가 올린 “RAG vs Fine-Tuning vs Prompt Engineering” 영상이 64만 회 조회된 데서 보듯, 사람들은 여전히 이 세 가지를 어떻게 조합할지 고민합니다.

새로운 그림은 이렇습니다. 제어 흐름이 큰 골격을 잡고, 각 노드 안에서 프롬프트 엔지니어링이 정확도를 책임지고, 필요에 따라 RAG로 컨텍스트를 보강하고, 더 깊은 도메인 적응이 필요하면 파인튜닝을 합니다. 프롬프트 하나에 모든 걸 욱여넣는 게 아니라, 각 도구를 제 역할에 쓴다는 거죠.

특히 에이전트 안에서는 프롬프트가 짧아지고 더 좁은 책임을 갖게 됩니다. “이 단계에서는 사용자 의도만 분류해줘” 같은 식이요. 한 프롬프트가 100가지 일을 하려고 하지 않으니까 디버깅도 쉬워집니다.

실무자에게 주는 시사점

지금 에이전트 프로젝트를 하시는 분이라면, 다음 질문을 던져보세요. “이 단계, 정말로 LLM이 결정해야 하나?" 답이 “아니"라면, 그 부분은 코드로 옮기세요. LLM은 자연어 이해와 생성, 그리고 진짜 모호한 분류 문제에 집중시키는 게 좋습니다.

또 하나, 프롬프트 길이가 200줄을 넘어가고 있다면 그건 설계가 잘못되고 있다는 신호입니다. 한 호출이 너무 많은 책임을 지고 있다는 뜻이거든요. 단계를 쪼개고, 각 단계 사이를 코드로 잇는 방향이 거의 항상 더 나은 답입니다.

AI 에이전트의 진짜 경쟁력은 모델의 똑똑함이 아니라 그 똑똑함을 어떻게 배치하느냐에서 갈릴 가능성이 큽니다. 프롬프트를 한 줄 더 늘리고 싶을 때, 잠깐 멈춰서 “이걸 if문으로 바꿀 수 있지 않을까?“를 물어보는 습관, 지금부터 들여놓을 만합니다.

여러분이 만드는 에이전트는 지금 어디쯤 와 있나요? 프롬프트의 늪에 빠져 있나요, 아니면 잘 짜인 흐름 위에 LLM이 점처럼 놓여 있나요?