AI 에이전트 자동화가 불안정해 보일 때 많은 팀은 먼저 프롬프트를 고친다. 더 자세히 지시하고, 예시를 붙이고, 금지 규칙을 더 길게 넣는다. 물론 어느 정도 효과는 있다. 하지만 반복 실행 환경에서는 금방 한계가 드러난다. 같은 요청이 상황에 따라 다른 경로를 타고, 실패 후 어디서 다시 시작해야 할지 모호하며, 승인 시점이 흔들리기 때문이다. 이 문제는 프롬프트 부족이 아니라 제어 흐름 부재에 가깝다.
메인 허브 글 에이전트 레디 업무 환경이란 무엇인가: 컨텍스트·제어 흐름·승인·MCP까지 한 번에 정리에서 설명했듯, 실행형 AI의 품질은 답변 품질보다 작업 경로의 선명도에 더 크게 좌우된다. 특히 n8n의 agent architecture patterns가 강조한 topology, control flow, failure containment, 커뮤니티에서 반복되는 bounded workflow와 replay 논의는 모두 같은 결론으로 모인다. 에이전트를 오래 굴리려면 “무엇을 말할까”보다 “어떻게 멈추고 다시 이어갈까”를 먼저 설계해야 한다.
왜 프롬프트만으로는 반복 작업을 안정화할 수 없을까
프롬프트는 입력 지침이다. 반면 반복 자동화에 필요한 것은 상태 전이 규칙이다. 예를 들어 “최신 미처리 run을 골라 글 3개를 만들고 publish job을 enqueue하라”는 업무는 단순한 자연어 요청처럼 보여도 실제로는 선택, 생성, 기록, 큐잉, 상태 갱신이라는 여러 단계로 나뉜다. 이때 어떤 단계가 성공인지, 실패 시 다시 해도 되는지, 이미 끝난 쓰기를 어떻게 건너뛸지가 정의돼 있지 않으면 에이전트는 그때그때 즉흥적으로 행동하게 된다.
즉 좋은 프롬프트는 출발점일 뿐이다. 운영 품질은 결국 제어 흐름에서 나온다.
제어 흐름 설계의 최소 단위는 다섯 가지다
실무에서 너무 복잡한 오케스트레이션을 먼저 만들 필요는 없다. 대신 아래 다섯 가지를 분명히 적는 것만으로도 품질 차이가 크다.
-
시작 조건 현재 실행이 언제 시작되는지다. 스케줄, 이벤트, 수동 트리거 가운데 무엇인지 명확해야 중복 실행을 막기 쉽다.
-
성공 조건 어디까지 끝나야 이 런이 완료인지 적어야 한다. 예를 들어 초안 생성만으로 끝인지, 큐 등록까지가 끝인지, 머지 확인까지가 끝인지 다를 수 있다.
-
중간 상태 각 단계 결과를 외부 상태로 남겨야 한다. 그래야 세션이 끊겨도 다시 시작할 수 있다.
-
재시도 규칙 실패했을 때 무조건 처음부터 반복할지, 특정 단계만 다시 할지, 몇 번까지 시도할지 정의해야 한다.
-
승인 지점 사람이 꼭 확인해야 할 순간을 앞당겨 정의해야 한다. 그렇지 않으면 승인 요청이 늦게 오거나 너무 자주 오게 된다.
이 다섯 가지가 없는 자동화는 눈앞에서는 그럴듯해 보여도, 두 번째 실행부터 흔들릴 가능성이 높다.
bounded workflow가 중요한 이유
bounded workflow는 에이전트를 작게 가두자는 뜻이 아니다. 각 실행이 어디서 시작해서 어디서 끝나는지, 무엇을 하지 않는지 명확하게 하자는 뜻에 가깝다. 이 경계가 있어야 실패 원인을 좁히고, 재개 시 중복 쓰기를 피하고, 승인도 일정한 의미를 갖게 된다.
예를 들어 글 발행 자동화에서 “초안 생성”, “GitHub publish job 큐 등록”, “머지 확인”을 하나의 무제한 세션으로 묶으면 중간 상태가 흐려진다. 반대로 각 단계의 경계를 정하면 어떤 자동화는 초안까지 담당하고, 어떤 자동화는 큐 등록까지만 담당하고, 이후 단계는 별도 launchd publisher가 처리하도록 나눌 수 있다. 이 방식이 실제로 더 안정적이다.
bounded workflow는 복잡성을 줄이기보다 복잡성을 위치별로 나누는 방법이다.
replay와 재개는 고급 기능이 아니라 기본 기능이다
에이전트 자동화는 외부 시스템을 많이 만질수록 실패가 정상 상태가 된다. 파일 잠금, API 지연, 승인 대기, 네트워크 이슈, 중복 상태 충돌은 모두 흔하다. 이런 환경에서 replay를 특별한 기능처럼 취급하면 운영이 곧 사람의 기억력에 의존하게 된다.
재개 가능한 흐름을 만들려면 다음 원칙이 유용하다.
- 이미 끝난 쓰기는 상태 필드로 확인하고 건너뛴다.
- 실패한 단계와 실패 원인을 별도로 남긴다.
- 읽기 단계와 쓰기 단계를 가능하면 분리한다.
- 외부 큐에 넘긴 뒤에는 그 큐를 기준 상태로 취급한다.
이 원칙이 있으면 에이전트는 매번 전체 작업을 새로 하지 않아도 된다. 장기 실행 자동화에서 생산성은 속도보다 재개성에서 더 크게 갈린다.
승인 구조는 제어 흐름의 일부로 넣어야 한다
승인을 사후 체크리스트로 다루면 흐름이 쉽게 깨진다. 제어 흐름 설계 단계에서부터 승인 지점을 상태 전이의 일부로 넣어야 한다. 예를 들어 “초안 완료 -> 승인 대기 -> 외부 반영”처럼 모델이 아니라 상태 머신 관점으로 생각하는 편이 안전하다.
특히 모바일 승인형 Codex 흐름이 보여 준 핵심은, 승인 자체를 줄이는 것이 아니라 승인 타이밍을 선명하게 만드는 데 있다. 사람은 전체 로그를 읽지 않아도 되고, 에이전트는 승인 전까지 준비만 마치면 된다. 이렇게 해야 승인 요청이 예외가 아니라 운영의 정상 단계가 된다.
실무에 바로 쓰는 제어 흐름 질문
아래 질문은 대부분의 에이전트 자동화 설계에서 그대로 사용할 수 있다.
- 이 작업은 어떤 이벤트나 스케줄로 시작되는가.
- 성공으로 간주할 정확한 마지막 상태는 무엇인가.
- 실패했을 때 처음부터 다시 하지 않아도 되는 단계는 어디인가.
- 어떤 단계가 외부 쓰기이며, 그 직전 승인 근거는 무엇인가.
- 같은 작업이 중복 실행됐을 때 어떻게 감지하고 건너뛸 것인가.
- 다음 자동화 또는 사람이 이어받을 상태는 어디에 남는가.
이 질문에 선명하게 답하지 못하면, 프롬프트를 길게 써도 안정성은 크게 나아지지 않는다.
제어 흐름은 에이전트를 덜 자유롭게 만드는 것이 아니라 더 오래 일하게 만든다
제어 흐름 설계를 이야기하면 종종 에이전트의 자율성을 줄이는 것처럼 들린다. 하지만 실제로는 반대다. 잘 설계된 분기와 재시도 규칙, 승인 지점, 재개 상태가 있어야 에이전트는 더 긴 시간 동안 더 적은 감독으로 일할 수 있다. 제어 흐름이 없는 자율성은 자유가 아니라 즉흥성에 가깝다.
결국 좋은 에이전트 자동화는 멋진 프롬프트보다 좋은 운영 경계를 먼저 가진다. 제어 흐름이 선명하면 프롬프트는 짧아져도 되고, 흐름이 흐리면 프롬프트를 아무리 늘려도 매번 다른 행동이 나온다. 그래서 지금 필요한 것은 에이전트에게 더 많이 말하는 일이 아니라, 에이전트가 어떤 경로로 움직일지 더 정확히 써 두는 일이다.