프롬프트 엔지니어링은 끝났나? 에이전틱 AI 시대의 워크플로 설계

좋은 답 한 번은 데모가 될 뿐이죠. 프롬프트 엔지니어링은 사라지지 않았지만, 이제는 좋은 문장 하나보다 어떤 단계는 코드가 통제하고 어떤 단계는 모델이 판단하며 어디에서 사람이 승인할지를 함께 설계해야 합니다.

에이전트가 언제나 더 나은 자동화 방식은 아니거든요. Anthropic은 실행 경로가 코드로 미리 정해진 시스템을 ‘워크플로’, 모델이 도구와 진행 방식을 동적으로 선택하는 시스템을 ‘에이전트’로 구분합니다. 또한 복잡성을 늘리기 전에 가장 단순한 해법부터 검토하라고 권합니다. OpenAI의 에이전트 구축 가이드도 규칙 기반 방식으로 충분한 업무에는 결정론적 해법이 적합할 수 있다고 설명합니다. (Anthropic, Building effective agents, OpenAI, A practical guide to building agents)

질문부터 바꿔야 합니다. “에이전트를 도입할까?”보다 “이 업무의 어느 구간에 어느 정도의 재량을 줄까?”가 먼저죠.

1. 세 가지를 먼저 구분하자

결정론적 워크플로: 경로는 코드가 정한다

결정론적 워크플로에서는 조건문, 상태 머신, 큐, 권한 규칙 같은 소프트웨어 로직이 다음 단계를 정합니다. LLM이 분류나 요약을 담당하는 한 단계로 포함될 수는 있지만, 실행 순서와 허용된 분기는 애플리케이션이 통제합니다. 여기서 ‘결정론적’이라는 말은 LLM 문장이 매번 완전히 같다는 뜻이 아니라, 업무의 제어 흐름이 미리 정의됐다는 뜻입니다.

다음과 같은 업무에 먼저 고려할 수 있습니다.

입력 형식과 처리 규칙이 안정적이다.
예외 유형을 코드로 열거할 수 있다.
같은 조건에서 같은 처리 경로가 중요하다.
비용, 지연 시간, 감사 가능성을 예측해야 한다.

예를 들어 파일 형식 검사 → 필수 항목 추출 → 규칙 검증 → 데이터베이스 저장에서는 에이전트가 매번 다음 행동을 판단할 이유가 없죠. 중간 추출에 LLM을 쓰더라도 스키마 검증 실패 시 재요청하거나 사람 검토로 보내는 경로는 코드로 고정할 수 있습니다.

에이전틱 워크플로: 다음 행동을 모델이 고른다

에이전트는 목표, 도구, 제약을 받은 뒤 현재 상태에 따라 검색할지, 추가 정보를 요청할지, 코드를 실행할지, 작업을 종료할지를 선택합니다. OpenAI는 이런 시스템의 핵심을 모델이 워크플로 실행을 관리하고, 도구를 동적으로 선택하며, 종료 또는 사용자 이관 시점을 판단하는 구조로 설명합니다.

에이전트는 다음 조건에서 의미가 있습니다.

입력이 문서, 대화, 웹 정보처럼 비정형이다.
사전에 모든 분기를 열거하기 어렵다.
조사 과정에서 얻은 정보에 따라 다음 단계가 달라진다.
실패해도 되돌릴 수 있고, 추가 지연과 비용을 감수할 가치가 있다.

반대로 단계가 명확한 업무에 에이전트 루프를 넣으면 호출 횟수와 실패 경로만 늘 수 있습니다. 처음부터 여러 에이전트 역할을 만들 필요도 없습니다. OpenAI는 우선 단일 에이전트의 도구와 지시를 확장하고, 복잡한 지시를 따르지 못하거나 도구 선택 오류가 반복될 때 분리를 검토하라고 권합니다. Anthropic 역시 고정된 하위 작업이면 프롬프트 체이닝, 라우팅, 병렬화 같은 조합 가능한 워크플로 패턴을 먼저 제시합니다.

휴먼 인 더 루프(HITL): 사람이 매 단계 대신 책임 지점에 들어간다

HITL은 결정론적 방식과 에이전틱 방식 사이의 별도 등급이라기보다, 두 방식 모두에 붙일 수 있는 통제 패턴입니다. 사람이 모든 출력을 읽는 것이 아니라 다음과 같은 지점에서 실행을 멈추고 승인, 수정, 거절 또는 이관합니다.

결제, 환불, 삭제, 발송처럼 되돌리기 어렵거나 외부에 영향을 주는 행동 직전
민감정보, 법률·의료·채용 판단처럼 오류 비용이 큰 단계
재시도 횟수, 실행 시간, 비용 한도를 초과한 경우
모델의 결과가 규칙 검증이나 신뢰 기준을 통과하지 못한 경우

OpenAI 가이드는 고위험 행동과 실패 임계치 초과를 사람 개입의 대표적 트리거로 제시합니다. NIST AI RMF는 더 나아가 사람과 AI의 역할, 감독 절차, 지식 한계, 평가 방식을 정의하고 문서화하도록 안내합니다. 즉 “마지막에 사람이 볼 것”이라는 문장만으로는 부족합니다. 누가, 무엇을 보고, 어떤 기준으로, 어느 시간 안에, 어떤 결정을 내리는지가 운영 규칙이어야 합니다. (NIST AI RMF Core)

2. 선택 기준: 모호성보다 먼저 실패 비용을 본다

질문	그렇다면	권장 출발점
규칙과 입력 형식이 안정적인가?	예	결정론적 워크플로
다음 단계가 조사 결과에 따라 달라지는가?	예	제한된 도구를 가진 단일 에이전트
행동을 되돌리기 어렵거나 제3자에게 영향을 주는가?	예	실행 전 사람 승인
객관적인 합격 기준을 만들 수 있는가?	예	자동 검증 게이트와 평가
오류 비용은 큰데 합격 기준이 모호한가?	예	자동 실행을 줄이고 전문가 검토

한 업무가 표의 한 행에만 들어갈 필요는 없습니다. 실제로는 결정론적 외곽 + 에이전틱 구간 + 사람 승인 게이트가 가장 설명하기 쉬운 구조인 경우가 많습니다.

예를 들어 고객 환불 처리는 다음처럼 나눌 수 있습니다.

코드가 주문 존재 여부, 신청 기한, 환불 한도를 확인한다.
규칙으로 판단할 수 없는 사유만 에이전트가 정책 문서와 상담 기록에서 조사한다.
에이전트는 승인이나 거절을 직접 실행하지 않고, 근거가 연결된 제안과 구조화된 데이터를 만든다.
금액 또는 위험 기준을 넘으면 담당자가 승인·수정·거절한다.
승인된 입력만 결정론적 결제 API 단계로 전달하고 모든 결정을 기록한다.

이 구조에서는 모델이 강한 비정형 정보 해석에는 재량을 주면서도, 금전적 부작용은 코드와 사람의 통제 아래 둡니다.

3. 좋은 에이전트는 ‘자율성’보다 경계가 선명하다

도구를 읽기와 쓰기로 나눈다

검색, 조회, 계산 같은 읽기 도구와 전송, 수정, 결제 같은 쓰기 도구를 같은 위험도로 취급하면 안 됩니다. 각 도구에 최소 권한을 부여하고, 쓰기 도구에는 입력 검증과 승인 조건을 둡니다. 프롬프트의 “조심하라”는 문구는 인증, 권한 제어, 허용 목록을 대신하지 못합니다.

종료 조건과 예산을 코드로 둔다

완료 조건, 최대 단계 수, 재시도 횟수, 시간과 비용 한도, 사람에게 이관할 조건을 명시합니다. “성공할 때까지 반복”은 운영 규칙이 아닙니다. 에이전트가 멈춰야 할 때 안전하게 멈추는 것도 기능이니까요.

구조화된 계약으로 단계를 연결한다

단계 사이에는 자유로운 대화문보다 필수 필드, 허용 값, 출처, 신뢰 상태가 있는 구조화된 데이터를 사용합니다. 모델이 만든 값은 스키마와 업무 규칙으로 다시 검사합니다. 그러면 모델이나 프롬프트를 바꿔도 어느 단계에서 계약이 깨졌는지 추적하기 쉽습니다.

승인 전후의 부작용을 분리한다

승인 대기 상태를 저장하고 재개할 수 있어야 하며, 재시도해도 중복 결제나 중복 발송이 생기지 않도록 멱등 키를 사용해야 합니다. LangGraph의 공식 인터럽트 문서도 재개 시 노드가 처음부터 다시 실행될 수 있으므로, 인터럽트 이전의 부작용은 멱등적으로 만들거나 승인 이후 별도 노드로 분리하라고 설명합니다. (LangGraph, Interrupts)

최종 답뿐 아니라 경로를 평가한다

에이전트는 여러 단계에서 도구를 호출하고 상태를 바꾸므로 최종 문장만 맞는지 보는 것으로 충분하지 않습니다. 대표 과제 묶음을 만들고 성공률, 잘못된 도구 호출, 불필요한 단계, 사람 이관률, 정책 위반을 함께 측정합니다. NIST의 생성형 AI 프로필은 알려진 정답과의 비교, 사람 감독, 자동 평가 등 여러 방법으로 정확성·품질·신뢰성을 평가할 것을 제안합니다. (NIST AI 600-1, Generative Artificial Intelligence Profile)

4. 그렇다면 프롬프트 엔지니어링은 무엇이 되는가

프롬프트는 여전히 시스템의 핵심 입력입니다. 목표, 금지 행동, 도구 사용 조건, 필요한 근거, 출력 형식, 모호할 때의 이관 규칙을 모델이 이해할 수 있게 표현해야 합니다. Anthropic은 전체 프롬프트뿐 아니라 도구 정의와 명세에도 같은 수준의 주의를 기울여야 한다고 강조합니다.

달라진 점은 프롬프트가 더 이상 품질과 안전을 혼자 책임지지 않는다는 것입니다.

프롬프트는 모델의 판단 기준을 설명한다.
컨텍스트는 판단에 필요한 정책, 데이터, 현재 상태를 제공한다.
코드는 허용된 경로, 검증, 종료 조건을 강제한다.
권한 체계는 모델이 실제로 할 수 있는 행동을 제한한다.
평가와 로그는 변경 후 품질과 실패 경로를 보여준다.
사람 승인은 책임이 필요한 결정을 맡는다.

따라서 “프롬프트 엔지니어링의 종말”은 정확한 진단이 아닙니다. 더 정확한 표현은 프롬프트 최적화가 워크플로·컨텍스트·권한·평가 설계 안으로 편입됐다는 것입니다.

도입 전에 답해야 할 다섯 가지

이 단계의 경로를 코드로 고정하지 못하는 이유는 무엇인가?
에이전트에게 꼭 필요한 최소 도구와 데이터는 무엇인가?
실패를 자동으로 감지할 수 있는 합격 기준은 무엇인가?
어떤 행동은 실행 전에 반드시 사람이 승인해야 하는가?
중단, 재시도, 재개 때 같은 부작용이 두 번 발생하지 않는가?

첫 질문에 답하지 못하면 결정론적 워크플로부터 시작하는 편이 낫습니다. 나머지 질문에 답하지 못하면 에이전트를 운영 환경에 연결하기에는 아직 이릅니다. 좋은 설계의 목표는 가장 자율적인 AI가 아니라, 필요한 곳에서만 재량을 쓰고 실패했을 때 통제권을 회수할 수 있는 시스템입니다.

프롬프트 엔지니어링은 끝났나? 결정론적·에이전틱·HITL 워크플로 설계

핵심 요약