데모는 항상 잘 된다. LLM에 툴 몇 개 연결하고, 프롬프트 다듬고, 에이전트 돌리면 그럴듯한 결과가 나온다. 팀원들이 박수 치고, 슬랙에 GIF가 올라온다. 문제는 그 다음이다. 그 워크플로우를 실제 프로세스에 붙이는 순간, 질문이 완전히 바뀐다. '프롬프트가 잘 작동하나?'가 아니라 '툴이 실패하면 어떻게 되나?', '에이전트가 잘못된 걸 재시도하면?', '컨텍스트를 잘못 넘겨받은 다음 에이전트는?'이 된다.
dev.to에 올라온 두 편의 글—Building AI Workflows Is Easy. Making Them Reliable Is Systems Engineering과 The Agent Is Easy. The Loop Is the Job—은 같은 지점을 다른 각도에서 찌른다. 에이전트를 만드는 건 쉽다. 5줄짜리 SDK 코드면 된다. 진짜 일은 그 에이전트가 프로덕션에서 살아남도록 루프 전체를 설계하는 것이다.
프롬프트는 신뢰성을 관리할 수 없다
많은 팀이 프롬프트를 더 정교하게 만드는 것으로 신뢰성 문제를 해결하려 한다. 재시도 조건, 안전 제약, 완료 판단 기준을 전부 프롬프트 안에 욱여넣는다. 이건 근본적으로 잘못된 접근이다. 프롬프트는 모델이 어떻게 추론할지를 안내할 수 있다. 하지만 외부 시스템과의 상호작용에서 발생하는 일관성과 안전성은 프롬프트가 보장할 수 없다.
핵심 구분선은 명확하다. 모델은 추론하고, 시스템이 통제한다. 에이전트가 "이메일 보냈습니다"라고 말하는 것과 실제로 이메일이 발송된 것은 다른 사실이다. 에이전트의 최종 응답은 증거가 아니라 주장이다. 프로덕션 워크플로우에서 그 주장을 그대로 믿는 팀은 언젠가 반드시 사고를 낸다.
신뢰성 설계의 네 레이어
신뢰할 수 있는 AI 워크플로우는 네 가지 책임을 명확히 분리해야 한다. 추론(Reasoning)은 모델이 맡는다. 실행(Execution)은 런타임이 통제한다. 상태(State)는 워크플로우 엔진이 관리한다. 증거(Evidence)는 감사 레이어가 기록한다. 이 네 가지가 하나의 프롬프트 호출 안에 뭉쳐 있으면, 디버깅은 사실상 불가능해진다. 뭔가 잘못됐을 때 어디서 잘못됐는지 알 수 없기 때문이다.
실행 레이어에서 특히 과소평가되는 게 재시도 전략이다. 전통적인 API 재시도는 단순하다. 타임아웃이면 다시 보내면 된다. AI 워크플로우의 실패는 종류가 다르다. 툴 타임아웃, 잘못된 페이로드, 비즈니스 로직 오류, 권한 거부, 예산 초과—각각 완전히 다른 대응이 필요하다. 모든 실패에 "에이전트 다시 돌리기"로 응답하는 팀은 비용을 태우면서 신뢰성은 얻지 못한다. 때로는 재시도하지 않는 것이 올바른 재시도 전략이다.
상태 관리는 멀티 에이전트 환경에서 더 복잡해진다. 단일 에이전트가 컨텍스트를 잃는 것과, 에이전트 A의 잘못된 주장이 에이전트 B의 입력이 되는 것은 스케일이 다른 문제다. 리서치 에이전트가 틀린 데이터를 수집했다고 주장하고, 그게 분석 에이전트로 넘어가고, 리뷰어 에이전트가 승인하고, 커뮤니케이션 에이전트가 고객에게 발송하는 루프—결과물은 그럴듯해 보이지만 기반이 깨져 있다. 명시적인 핸드오프, 검증 게이트, 체크포인트 없이는 멀티 에이전트 워크플로우는 신뢰성이 아니라 불확실성의 증폭기가 된다.
Build → Eval → Improve 루프가 실제 업무다
두 번째 글이 짚는 포인트는 역할 정의에 있다. AI 엔지니어는 ML 엔지니어가 아니다. 모델을 훈련시키는 사람이 아니라, 모델을 프로덕션 제품으로 만드는 사람이다. 그리고 그 일의 핵심은 Build → Eval → Improve 루프를 운영하는 것이다. 에이전트를 만드는 건 오후 한 나절이면 된다. 그 에이전트가 실제로 개선되고 있는지, 아니면 그냥 그렇게 느껴지는 건지를 측정하는 게 진짜 일이다.
이 루프에서 가장 어려운 건 메트릭 선택이다. 잘못된 메트릭으로 루프를 돌리면 노이즈만 쌓인다. 올바른 메트릭은 시스템이 복리처럼 개선된다. AI 엔지니어링의 레버리지는 대부분 무엇을 측정할지 결정하는 데서 나온다. 프롬프트를 다듬는 시간의 절반이라도 평가 파이프라인 설계에 쓴다면, 대부분의 팀은 지금보다 훨씬 빨리 신뢰할 수 있는 시스템에 도달할 수 있다.
테크 리드가 먼저 설계해야 할 것
팀 리빌딩 관점에서 이 논의가 시사하는 바는 분명하다. AI 워크플로우를 '기능'으로 취급하는 팀과 '시스템'으로 취급하는 팀은 프로덕션 이후 경험이 완전히 갈린다. 에이전트 코드를 빠르게 짜는 능력보다, 실패 모드를 미리 열거하고 각각에 대응하는 아키텍처를 설계하는 능력이 지금 시점에 더 중요한 팀 역량이다.
구체적으로 팀이 먼저 합의해야 할 것들이 있다. 어떤 실패를 자동 재시도할 것인가, 어떤 실패를 인간에게 에스컬레이션할 것인가, 어떤 실패는 워크플로우를 중단해야 하는가. 에이전트가 완료를 주장할 때 어떤 증거를 요구할 것인가. 워크플로우가 중간에 실패했을 때 어느 체크포인트부터 재개할 것인가. 이 질문들에 대한 답이 코드보다 먼저 나와야 한다.
AI 워크플로우의 신뢰성은 모델이 얼마나 똑똑한가의 문제가 아니다. 시스템이 얼마나 정직한가의 문제다. 에이전트가 실제로 뭘 했는지 증명할 수 있는 구조, 상태가 어디에 있는지 항상 알 수 있는 구조, 잘못된 실패에 잘못된 방식으로 대응하지 않는 구조—이게 없으면 아무리 정교한 프롬프트도 프로덕션을 버티지 못한다. 데모는 아이디어가 가능하다는 걸 증명한다. 프로덕션은 시스템이 신뢰할 수 있다는 걸 증명해야 한다. 그 두 증명은 전혀 다른 설계를 요구한다.