에이전트보다 워크플로가 먼저다

에이전트 도입을 검토하는 자리에서는 대개 모델부터 고른다. 어떤 모델이 코드를 더 잘 쓰는지, 비용은 얼마인지, 어느 도구에 붙일지를 먼저 본다.

그런데 에이전트를 실제 업무에 넣은 은행들이 공개한 내용을 보면 모델 이야기는 뒤로 밀려 있다. 앞에 나오는 것은 승인, 권한, 기록, 예외 처리다.

이 글의 주장은 하나다. 에이전트에게 되돌릴 수 없는 권한을 주기 전에 워크플로부터 정리해야 한다. 워크플로가 정리되어 있어야 통제 지점을 꽂을 자리가 생기기 때문이다.

1. 은행은 무엇을 앞에 두었나

두 은행의 공개 자료를 봤다. 둘 다 당사자나 공급사의 발표라는 점은 감안해야 한다. 여기서 확인할 수 있는 것은 “그렇게 했다”가 아니라 “그렇게 설계했다고 밝혔다”까지다.

카카오뱅크

카카오뱅크는 2026년 8월 사내 기술 컨퍼런스에서 ‘AI를 사용하는 은행’에서 ‘AI가 일하는 은행’으로 전환하겠다고 발표했다. 기획부터 개발·배포까지를 에이전트가 수행하게 하겠다는 내용이다.

그 전제로 세 가지 기반을 내걸었다.

기반	내용
AI-Ready Data	검증된 최신 데이터를 제공한다
AI-Ready Workflow	정해진 규정 안에서만 에이전트가 행동하고, 예외 상황에는 사람이 개입한다
AI-Ready Foundation	안전한 실행 환경과 통제된 API를 두고, 모든 과정을 추적한다

세 항목 어디에도 모델 이름이 없다. 전부 에이전트가 움직일 바닥에 관한 이야기다.

순서도 그렇다. 이 은행은 2022년 금융 분야 AI 안내서 작업에 참여했고, 2023년 자체 AI 거버넌스 로드맵을 세웠으며, 최고책임자·주관팀·소관팀으로 역할과 책임을 나눴다. AI 전담 조직 신설은 2024년, AI 서비스 출시는 2025년, 에이전트 전환 선언은 2026년이다.

Barclays

Barclays는 고객 실사(Client Due Diligence) 업무를 에이전트 기반으로 재설계한 과정을 공개했다. 나눈 방식이 분명하다.

누가	무엇을
사전 정의된 프로세스	필수 승인, 리스크 규칙, 통제, 기한, 증거 요건을 강제한다
에이전트	정보 수집, 출처 비교, 누락 식별처럼 상황마다 달라지는 일을 한다
사람	예외와 결과가 무거운 판단을 맡는다

에이전트는 프로세스 안에서 일하고, 프로세스 자체는 에이전트가 정하지 않는다.

같은 은행의 수석 AI 엔지니어는 한 인터뷰에서 프로덕션 에이전트의 우선순위로 세 가지를 꼽았다고 전해진다. 에이전트의 행동을 사후에 재구성할 수 있는 텔레메트리, 권한 경계, 코드로 구현된 킬 스위치다. 모델 성능은 그 목록에 없다.

에이전트에게 백지수표를 줄 수는 없다.

2. 은행은 통제 구조를 새로 만든 것이 아니다

여기서 “은행은 규제 때문에 그럴 수밖에 없다”는 반론이 나온다. 절반만 맞다.

은행의 승인 체계, 감사 증적, 책임 분리는 AI 이전부터 있었다. 은행은 에이전트를 위해 통제 구조를 새로 지은 것이 아니라, 이미 있던 구조 위에 에이전트를 얹었다.

이 차이가 중요하다. 규제가 은행에게 준 것은 AI 통제 기술이 아니다. 업무를 단계로 나누고, 단계마다 누가 무엇을 보고 판단하는지 적어 두는 습관이다. 그 습관 덕분에 에이전트를 꽂을 자리와 사람을 남겨 둘 자리가 처음부터 구분되어 있었다.

일반 조직과 은행의 격차는 모델이나 예산이 아니다. 그 자리가 있느냐 없느냐다.

에이전트가 글을 쓰는 데서 멈추지 않고 배포하고, 병합하고, 메시지를 보내기 시작하면 어느 조직이든 같은 문제를 만난다. 은행은 먼저 겪었을 뿐이다.

3. 정리된 워크플로란 무엇인가

“워크플로를 정리하라”는 말은 쉽게 흘려듣게 된다. 이슈 트래커가 있고 CI가 돌고 있으면 정리되어 있다고 느끼기 때문이다.

내가 쓰는 기준은 네 가지 질문에 답할 수 있느냐다.

각 단계는 무엇을 받아 무엇을 내놓는가.
어느 지점부터 되돌릴 수 없는가.
그 지점에서 누가 무엇을 보고 판단하는가.
판단의 근거가 그 시점에 실제로 존재하는가.

1번에 답하지 못하면 에이전트에게 일을 넘길 단위가 없다. 2번에 답하지 못하면 게이트를 어디에 둘지 정할 수 없다. 3번에 답하지 못하면 게이트를 두어도 책임자가 없다.

4번은 가장 자주 빠진다. 아래 사례가 정확히 그 경우였다.

4. 자리가 있어도 끝이 아니다

은행 사례가 말해 주는 것은 “자리가 있어야 통제 지점을 꽂는다”까지다. 직접 겪어 보니 그 뒤에 두 단계가 더 있었다.

단계	질문
자리가 있다	통제 지점을 꽂을 단계가 워크플로에 존재하는가
자리가 맞다	그 지점에 승인할 대상이 이미 존재하는가
작동한다	그 게이트가 실제로 무언가를 막는가

자리가 틀린 게이트

모노레포의 배포 워크플로를 세운 날, 승인 게이트가 이미지를 빌드하는 잡에 붙어 있다는 것을 발견했다.

승인은 “이 이미지를 프로덕션에 올릴까”를 묻는 일이다. 게이트가 빌드 앞에 있으면 그 이미지가 만들어지기도 전에 묻는 셈이다. 승인자가 볼 것이 없다.

게이트를 승격 잡으로 옮겼다. 게시는 게이트 없이 진행하고, 게시된 다이제스트를 검증한 뒤에 승인을 받는 구조다.

  # Publishing is never gated: the artefact must exist before anyone can be asked
  # to approve its promotion. Approval belongs to the `promote` job below.
  publish:
    permissions:
      contents: read
      packages: write

옮기고 나서도 한 군데가 남아 있었다. latest 태그가 게시 시점에 붙고 있었다. 승인 전에 latest가 새 이미지를 가리키면, latest를 받아 가는 쪽에는 승인 여부가 아무 의미가 없다.

빌드 잡에 붙은 게이트는 승인이 아니라 지연이고, 승인 전에 움직이는 latest는 게이트를 형식으로 만든다.

작동하지 않는 게이트

며칠 뒤 실제 릴리스 태그를 밀었다. 승격 잡이 승인 대기로 멈춰 있을 것이라는 보고가 올라왔다.

확인해 보니 배포는 이미 끝나 있었다. 전부 성공이었다.

Publish api/web/pipeline  success
Promote to production     success
GitHub Release            success

저장소의 환경 설정에 보호 규칙이 비어 있었다. 필수 리뷰어가 지정된 적이 없으니 승격 잡이 멈출 이유가 없었다. 워크플로 파일에 적힌 environment:만 보고 게이트가 있다고 믿은 것이다.

게이트를 코드에 붙이는 것과 게이트가 실제로 작동하는 것은 별개다.

같은 시기에 다이어그램 조합을 검사하는 정적 분석 게이트를 만들면서는 이 교훈을 반영했다. 통과만 하고 한 번도 발화하지 않는 게이트는 믿을 수 없어서, 과거에 실제로 깨졌던 스냅샷을 넣어 정확히 잡아내는지부터 확인했다.

사람이 이 파이프라인을 직접 돌릴 때는 이런 구멍이 잘 드러나지 않는다. 배포하는 사람이 곧 판단하는 사람이라 게이트가 없어도 멈출 줄 안다. 에이전트는 멈추지 않는다. 막는 것이 없으면 끝까지 간다.

5. 게이트는 늘리는 것이 아니다

여기까지 읽으면 통제 지점을 많이 꽂으라는 이야기로 들릴 수 있다. 반대다.

승인 요청이 많아지면 사람은 내용을 보지 않고 승인을 누른다. 그 순간 게이트는 보호 규칙이 비어 있던 환경 설정과 같은 상태가 된다. 있지만 아무것도 막지 않는다.

기준은 네 가지 질문의 2번이다. 되돌릴 수 없는 지점에만 둔다.

위 사례에서 이미지 게시에는 게이트를 두지 않았다. 게시된 이미지는 아무도 받아 가지 않으면 영향이 없고, 다시 만들 수 있다. 게이트는 프로덕션 승격 한 곳에만 남겼다. Barclays가 결과가 무거운 판단만 사람에게 남긴 것과 같은 원칙이다.

6. “먼저”는 어디까지인가

솔직하게 적어 둘 것이 있다. 위의 두 구멍은 모두 돌려 보고 나서야 알았다. 게이트 위치가 틀렸다는 것은 워크플로를 세운 뒤에, 게이트가 작동하지 않는다는 것은 태그를 민 뒤에 드러났다.

그러니 “모든 워크플로를 완벽히 정리한 뒤에 에이전트를 들여라”는 말은 지킬 수 없는 요구다. 워크플로의 구멍은 책상에서 다 보이지 않는다.

“먼저”의 기준은 도입 시점이 아니라 권한이다.

읽고 제안하는 에이전트는 일찍 들여도 된다. 오히려 워크플로의 빈 곳을 드러내는 수단이 된다.
배포, 병합, 삭제, 외부 발송처럼 되돌릴 수 없는 행동을 맡기기 전에는 네 가지 질문에 답이 있어야 한다.

정리 범위도 전사 프로세스가 아니다. 에이전트가 행동하는 경로만이다.

7. 통제부터 하면 느려지지 않나

Barclays가 고객 실사를 재설계한 목적은 통제 강화가 아니라 온보딩 속도였다. 단계와 책임이 정리되어 있어야 어느 구간을 에이전트에게 넘겨도 되는지가 보이고, 넘길 수 있는 구간이 보여야 빨라진다.

워크플로 정리는 통제의 전제이면서 속도의 전제다.

반대 방향의 신호도 있다. Gartner는 2027년 말까지 에이전트형 AI 프로젝트의 40% 이상이 취소될 것으로 예측했고, 원인으로 비용 증가, 불분명한 사업 가치, 부적절한 리스크 통제를 들었다. 예측이지 관측은 아니지만, 모델 성능이 원인 목록에 없다는 점은 눈여겨볼 만하다.

두 은행의 사례가 이 주장을 증명하지는 않는다. 통제 없이 들여 잘된 조직도, 통제를 준비하다 도입하지 못한 조직도 있을 것이다. 다만 실수의 비용이 가장 큰 곳에서 무엇을 앞에 두었는지는 참고할 만하다.

8. 정리

에이전트를 실제 업무에 넣은 은행들이 앞에 둔 것은 모델이 아니라 승인, 권한, 기록, 예외 처리였다.
은행은 통제 구조를 새로 만든 것이 아니라 이미 있던 구조 위에 에이전트를 얹었다. 격차는 그 자리의 유무다.
통제 지점은 자리가 있고, 자리가 맞고, 실제로 작동해야 한다. 셋은 따로 확인해야 한다.
게이트는 되돌릴 수 없는 지점에만 둔다. 많으면 형식이 된다.
“먼저”의 기준은 도입이 아니라 되돌릴 수 없는 권한이다.

에이전트에게 권한을 넘기기 전에 팀에 물어볼 것은 네 가지다.

각 단계는 무엇을 받아 무엇을 내놓는가.
어느 지점부터 되돌릴 수 없는가.
그 지점에서 누가 무엇을 보고 판단하는가.
판단의 근거가 그 시점에 실제로 존재하는가.

그리고 하나 더. 그 게이트가 마지막으로 무언가를 막은 것은 언제인가.