에이전트는 도구함에 없는 건 못 쓴다
배포 에이전트를 CI/CD 파이프라인에 붙여본 팀이라면 한 번쯤 목격했을 장면이 있다. 새 버전 배포 후 헬스체크를 기다리는 에이전트가 for i in $(seq 1 40); do sleep 3; curl -s http://host/health && break; done 같은 코드를 스스로 작성하는 것. dev.to에 올라온 한 개발자의 사례가 이 문제를 정확히 짚는다. 에이전트가 만든 루프는 '올바른 응답'이 아니라 '어떤 응답이든 오면' break를 탈출하도록 짜여 있었고, 결과적으로 스테일 바디를 반환한 200 응답에 배포 완료를 선언해버렸다.
이게 일회성 버그가 아니라는 게 핵심이다. 에이전트는 bash 셸만 있으면 매번 똑같이 취약한 sleep 루프를 '처음부터 다시 발명'한다. 도구함에 더 나은 프리미티브가 없기 때문이다. 지시로 막을 수 있는 문제가 아니다. "제대로 된 버전이 뜰 때까지 기다려"라고 프롬프트에 적어봤자, 에이전트가 꺼낼 수 있는 최선은 여전히 sleep이다.
프리미티브를 설계하면 나쁜 행동이 구조적으로 불가능해진다
이 문제를 해결한 방식이 흥미롭다. 해당 개발자는 opencode-waitfor라는 플러그인을 만들어 에이전트 도구함에 wait_for라는 단일 프리미티브를 추가했다. URL이면 HTTP 폴링, host:port면 TCP 연결 체크, 그 외엔 셸 커맨드 실행—세 가지 타깃 형태를 하나의 동사로 처리한다. 결정적인 차이는 expect 옵션이다. wait_for http://host/health expect { json_match: { version: abc123 } }처럼 쓰면, 에이전트는 '200 응답'이 아니라 '올바른 버전이 담긴 200 응답'이 올 때까지 기다린다. 스테일 바디 문제가 프롬프트 레벨이 아니라 도구 레벨에서 봉쇄된다.
타임아웃이 났을 때도 다르다. 기존 루프는 실패 시 아무 정보도 남기지 않아 에이전트가 다시 프로브를 쏴야 했다. wait_for는 마지막으로 본 HTTP 상태와 바디, 혹은 마지막 커맨드의 exit code와 출력을 그대로 반환한다. 에이전트가 실패 진단을 추가 왕복 없이 할 수 있다. 팀 입장에서 이 설계 원칙은 명확하다. 에이전트에게 더 나은 프리미티브를 주면, 나쁜 행동은 '지시로 막아야 할 것'이 아니라 '구조적으로 선택할 수 없는 것'이 된다.
포트폴리오가 늘어날수록 메타데이터 관리가 병목이 된다
배포 자동화의 또 다른 현실적 문제는 '스케일'이다. 앱 하나는 수동으로 관리할 수 있다. 그런데 AI 어시스티드 코딩 덕분에 앱 열 개를 4개월 만에 출시하게 되면? 빌딩 병목은 사라졌는데, 메타데이터·스크린샷·리뷰·키워드·릴리즈 관리라는 새로운 병목이 생긴다. dev.to에서 소개된 App Store Release Agent 사례가 바로 이 지점을 건드린다.
이 툴킷의 설계 철학이 팀에 그대로 이식할 만하다. 첫째, App Store Connect를 canonical source로 두되, 로컬 미러를 작업 공간으로 삼는다. 파일 하나당 정보 하나(title.txt, keywords.txt)로 쪼개서 에이전트가 diff를 보여주고, 사람이 검토한 뒤, 정확히 하나의 변경만 적용하는 구조다. "앱 페이지를 개선해"가 아니라 "이 파일로 en-US 키워드를 patch하되 dry-run 먼저"라는 수준의 명령이 가능해진다. 둘째, 모든 실제 변경은 --apply 플래그 없이는 실행되지 않는다. 기본이 dry-run이다. 에이전트가 실수로 프로덕션 메타데이터를 날리는 사고를 구조적으로 막는다. 셋째, 변경마다 changelog.md에 왜, 무엇을, 어떻게, 결과가 무엇인지 기록한다. 앱이 열 개를 넘어가면 키워드 하나를 왜 바꿨는지 기억하는 게 불가능해진다. 에이전트가 생성한 audit trail이 그 기억을 대신한다.
에이전트가 실제 비즈니스 워크플로우에 들어갈 때
더 극단적인 사례도 있다. 기업용 AI 에이전트 플랫폼 라이저(Lyzr)는 자체 에이전트 '시바클로(SivaClaw)'를 시리즈B 투자 유치 과정에 직접 투입했다. 130명이 넘는 투자자의 질문에 자동 응답하고, 수십 건의 투자 메모 작성을 지원하고, 투자자가 어느 슬라이드에서 오래 머물렀는지·무엇을 클릭했는지까지 추적해 적합 투자자를 선별했다. 결과는 4억 달러(약 6000억 원) 규모의 투자 관심. AI 타임스가 보도한 이 사례에서 한 투자자는 "초기 검토 단계를 의미 있게 단축했다"면서도 "실사(Due Diligence)까지 획기적으로 단축할 수준은 아직 아니다"라고 평가했다.
이 사례가 배포 파이프라인 문제와 연결되는 지점이 있다. 투자 에이전트든, 배포 에이전트든, 릴리즈 에이전트든—에이전트가 실제 비즈니스 워크플로우에 들어갈 때 공통으로 필요한 설계 요소가 있다. 에이전트가 canonical source가 어디인지 알고, 변경 전에 diff를 보여주고, 실패 시 진단 가능한 정보를 남기고, 사람의 명시적 승인 없이 돌이키기 어려운 액션을 실행하지 않는 구조.
팀이 배포 에이전트를 붙이기 전에 설계해야 할 체크리스트
세 사례를 종합하면 팀이 배포 에이전트를 파이프라인에 붙이기 전에 먼저 답해야 할 질문들이 보인다.
1. 에이전트 도구함에 올바른 프리미티브가 있는가?
bash만 주면 에이전트는 sleep 루프를 발명한다. readiness를 의미하는 동사(wait_for)처럼, 에이전트가 제대로 된 행동을 '선택할 수 있는' 도구를 먼저 설계해야 한다.
2. Canonical source와 작업 공간이 분리되어 있는가? 프로덕션이 canonical source고, 에이전트가 작업하는 로컬 미러가 따로 있어야 한다. 에이전트가 diff를 보여주고 사람이 검토한 뒤 적용하는 구조.
3. 기본 동작이 dry-run인가? 에이전트의 모든 mutating action은 명시적 승인 없이는 실행되지 않아야 한다. 속도보다 안전이 먼저다.
4. 실패 시 진단 가능한 정보를 남기는가? 타임아웃이 났을 때 '실패'만 반환하는 에이전트는 다음 사람(혹은 다음 에이전트)이 원인을 다시 수집해야 한다. 마지막으로 관찰한 상태를 그대로 넘겨야 한다.
5. 변경 이유가 기록되는가? 에이전트가 빠를수록 변경이 많아지고, 변경이 많아질수록 왜 바뀌었는지 추적이 어려워진다. audit trail은 사후 관리가 아니라 설계 단계부터 포함되어야 한다.
전망: 에이전트 도구함 설계가 팀 역량의 핵심이 된다
"올바른 데이터로 학습하면 AI가 대부분의 반복 업무를 대신할 수 있다"는 라이저 공동창업자의 말은 맞다. 그런데 현장에서 더 중요한 문제는 모델 품질이 아니라 에이전트가 쓸 수 있는 도구의 품질이다. sleep 루프 문제가 증명하듯, 에이전트는 도구함에 없는 건 만들어내지 못한다—아니, 만들어내려다 더 나쁜 무언가를 만든다.
앞으로 팀의 AI 배포 역량은 '어떤 모델을 쓰느냐'보다 '에이전트 도구함을 얼마나 잘 설계했느냐'로 갈린다. wait_for 하나를 추가하는 게 수백 줄의 프롬프트 엔지니어링보다 실질적인 품질 개선을 만들어낸 것처럼. 배포 에이전트를 파이프라인에 붙이기 전에, 먼저 그 에이전트가 쓸 수 있는 프리미티브를 설계하는 시간이 필요하다.