지난 5월 말, 작은 뉴스레터 봇이 28개 AI 에이전트 시스템으로 자란 이야기를 적었습니다. 그 글의 마지막 문장은 "작고, 책임이 분명하고, 사람이 검토할 수 있는 에이전트부터 시작하라"였어요.

그로부터 50일이 지났습니다. 에이전트는 28개에서 48개가 되었고, 커밋은 1,015개에서 2,810개로, 머지된 코드 리뷰(PR)는 137개에서 640개를 넘겼습니다. 지금 이 시스템에는 40개가 넘는 정기 실행 스케줄이 매일, 매주 돌아갑니다.

그런데 이번 글의 주인공은 새로 늘어난 20개의 에이전트가 아닙니다. 지난 50일 동안 우리가 매달린 진짜 문제는 이거였거든요.
에이전트를 만드는 건 쉬워졌는데, 돌보는 게 병목이 되었다.
이 글은 그 병목을 어떻게 풀었는지에 대한 기록입니다. 1편이 "에이전트를 만드는 법"이었다면,
이번 편은 "에이전트 함대를 돌보는 법"이에요.

공교롭게도 최근 Anthropic이 우리가 하고 있던 일에 이름을 붙여줬습니다. 루프 엔지니어링(Loop Engineering). 프롬프트를 잘 쓰는 단계를 지나, "정지 조건을 만날 때까지 스스로 반복하는 작업 루프"를 설계하는 단계로 넘어간다는 개념인데, 지난 50일의 우리 기록이 정확히 그 사다리를 오른 과정이었습니다. 그래서 이번 글은 그 틀을 빌려 정리해 보려고 합니다.

이 글의 숫자(에이전트 수, 커밋 수, PR 수, 스케줄 수)는 전부 저희 코드 저장소의 기록에서 그대로 가져온 값입니다(2026년 7월 19일 기준). 사고 사례도 실제 내부 기록에서 가져왔습니다.

만들기는 쉬워졌는데, 돌보기가 병목이 되었다

1편에서 "같은 뼈대를 재사용하니 새 에이전트를 붙이는 비용이 뚝 떨어졌다"고 썼는데, 그 말은 계속 사실이었습니다. 6월 이후로도 에이전트는 계속 늘었어요. 문제는 그다음이었습니다.

에이전트가 48개, 정기 실행이 40개를 넘어가자, 사람이 매일 아침 "어젯밤 뭐가 잘 돌았고 뭐가 죽었나"를 확인하는 것 자체가 하나의 업무가 되었습니다. 실패 알림이 쌓이면 사람은 알림을 읽지 않게 되고, 알림을 읽지 않으면 자동화는 한계가 있습니다. 6월 이후 쌓인 커밋을 유형별로 세어보면 새 기능(feat)이 422개인데, 수정과 정리(fix, chore, docs)가 618개입니다. 여전히 만드는 일보다 돌보는 일이 더 많아요.

그래서 지난 50일 동안 만든 것들은 대부분 "일하는 에이전트"가 아니라 "에이전트를 돌보는 장치"였습니다.

루프 엔지니어링: 우리가 만들던 것의 이름

Anthropic의 루프 입문 가이드는 AI 에이전트의 루프를 자율성 순서로 네 단계로 나눕니다. 사람이 시킬 때마다 도는 턴 기반 루프, 검증 가능한 목표를 주면 달성할 때까지 도는 목표 기반 루프, 정해진 스케줄로 도는 시간 기반 루프, 그리고 사람의 실시간 개입 없이 이벤트에 스스로 반응하는 프로액티브 루프.

이 틀에 우리 함대를 겹쳐보면 지난 50일이 한 장으로 정리됩니다.

백서 제작처럼 사람이 시키면 완료까지 도는 에이전트가 1단계, OKR 대비 현재를 재고 우선순위를 매겨 일을 시키는 지휘자 에이전트가 2단계, 매일 아침 돌아가는 43개의 정기 실행이 3단계입니다. 1편까지의 우리는 여기까지 와 있었어요. 그리고 지난 50일 동안 오른 계단이 마지막 4단계, 프로액티브 루프입니다.

루프 엔지니어링에서 우리가 가장 크게 공감한 대목은, 루프 설계의 핵심이 "무엇을 시킬까"가 아니라 "언제 멈추게 할까"라는 점입니다. 트리거보다 정지 조건이 먼저라는 것. 1편에서 소개한 위험도 3단계, 킬스위치, 사람 승인 게이트가 전부 정지 조건의 다른 이름이었고, 이번에 만든 장치들도 결국 "루프가 잘못 돌기 시작했을 때 어떻게 알아채고 멈추나"에 대한 답이었습니다.

실패에는 세 종류가 있다

운영을 해보니 실패는 한 가지가 아니었습니다. 세 종류였고, 각각 잡는 방법이 달랐어요.

첫째, 시끄러운 실패. 정기 실행이 돌다가 에러를 내며 죽는 경우입니다. 이건 그나마 낫습니다. 다만 하루에 수십 개가 돌면 실패 알림도 쌓이는데, 마케터에게 스택트레이스(에러 원문)를 들이밀어봐야 아무 의미가 없죠. 그래서 하루 두 번, 최근 실패를 자동으로 수집해서 "일시적인 네트워크 문제인지, 코드 버그인지, 외부 데이터가 막힌 건지"를 분류하고, 비개발자가 읽을 수 있는 카드 한 장으로 묶어 보내는 에이전트를 만들었습니다. 같은 원인으로 여러 번 실패하면 카드 한 장에 "같은 이유로 N번"이라고 접어서요. 실패가 없으면 아무 말도 하지 않습니다.

둘째, 침묵 실패. 이게 훨씬 무섭습니다. 실행이 실패하는 게 아니라, 아예 실행 자체가 안 뜨는 경우예요. 스케줄 설정이 잘못되거나 플랫폼 쪽 문제로 예약이 조용히 증발하면, 실패 알림조차 없으니 아무도 모릅니다. 이건 실패를 감시하는 방식으로는 절대 못 잡아요. 그래서 반대로 "예정된 실행이 실제로 있었는지"를 매일 대조하는 감시자를 따로 뒀습니다. 일이 터졌을 때 우는 알람이 아니라, 심장이 뛰지 않을 때 우는 알람인 셈이죠.

셋째, 초록불인데 틀린 실패. 셋 중 가장 교묘합니다. 어떤 문제를 고쳐서 반영했는데, 실행은 성공(초록불)으로 끝나면서 정작 고친 효과는 안 나타나는 경우예요. 사람은 "고쳤으니 됐겠지" 하고 잊어버리고, 다음 날 결과를 확인하겠다는 다짐은 퇴근과 함께 증발합니다. 그래서 우리는 무언가를 고칠 때마다 "다음 예정 실행에서 이러이러한 결과가 보여야 한다"는 검증 계약을 저장소에 함께 등록하게 했습니다. 다음 실행이 끝나면 시스템이 계약과 실제 결과를 대조해서 통과인지 실패인지 한 번만 알려줍니다. 여기서 원칙 하나를 세웠는데, 이 판정에는 AI를 쓰지 않습니다. 검증은 결정론적인 규칙으로만 합니다. "고쳤는지"를 확인하는 장치가 또 틀릴 수 있으면 곤란하니까요.

에이전트를 돌보는 에이전트: 첫 프로액티브 루프

이 세 겹의 감시 장치가 매일 아침 각자 보고를 올리니, 이번엔 그 보고를 읽고 조치하는 일이 사람에게 남았습니다. 그래서 지난주, 그 일을 하는 에이전트를 하나 더 만들었습니다. 이름 그대로 함대 주치의입니다. 루프 엔지니어링의 용어로 말하면, 우리 함대의 첫 프로액티브 루프예요. 사람이 깨우지 않아도 매일 아침 스스로 시작하고, 진단부터 조치 제안까지 사람의 실시간 개입 없이 돕니다.

매일 아침 주치의는 밤사이의 실패, 실행 부재, 검증 결과를 한 덩어리로 받아서 원인을 파악합니다. 그리고 딱 두 가지 행동만 합니다. 코드로 고칠 수 있는 문제면 수정안을 만들어 코드 리뷰(PR)로 올리고, 사람만 할 수 있는 문제(만료된 로그인, 외부 서비스 장애 같은)면 Slack 카드 한 장으로 정리해 보냅니다.

여기서 1편의 원칙이 그대로 이어집니다. 주치의는 자기가 만든 수정안을 스스로 반영하지 못합니다. 머지 버튼은 여전히 사람이 누릅니다. 대신 정지 조건을 세 겹 더 둘렀어요. 이메일 발송이나 콘텐츠 발행, 데이터 구조처럼 위험한 영역의 코드는 아예 건드리지 못하게 막았고, 하루에 올릴 수 있는 수정안은 3건으로 제한했고, 같은 문제로 이미 수정안이 열려 있으면 중복해서 만들지 못하게 했습니다. 프로액티브 루프를 돌리기 전에 멈출 방법부터 설계한 겁니다.

그리고 재미있는 건 그다음입니다. 주치의가 올린 수정안을 사람이 그대로 머지했는지, 고쳐서 머지했는지, 닫아버렸는지를 전부 장부에 기록합니다. 언젠가 "이 정도 문제는 사람 승인 없이 반영해도 된다"로 권한을 올려주는 날이 온다면, 그 근거는 감이 아니라 이 장부에 쌓인 실제 승인률이어야 한다고 생각해서요. 자율성은 선언하는 게 아니라, 실적으로 승격되는 것이라는 게 우리가 정한 규칙입니다.

AI가 쓴 글을 AI가 채점하되, 같은 AI에게는 맡기지 않는다

돌보는 문제를 어느 정도 풀고 나니, 다음 질문이 남았습니다. 시스템이 안 죽고 도는 것과 별개로, 매일 나가는 콘텐츠의 품질은 좋아지고 있나? 그걸 어떻게 재나?

사람이 전수 검토하는 건 이미 아니었고(그러려고 만든 자동화니까요), 그렇다고 글을 쓴 AI에게 "네가 쓴 글 몇 점이야?"라고 물을 수는 없었습니다. 언어모델은 자기가 쓴 글에 후한 점수를 주는 경향(자기선호 편향)이 알려져 있거든요.

그래서 채점 구조를 이렇게 짰습니다. 글은 저희가 쓰던 모델이 쓰고, 채점은 다른 회사의 모델이 합니다. 검색 의도에 맞는지, 구조가 좋은지, 우리 문체에 맞는지, 사실 관계가 위험하지 않은지, 행동 유도가 자연스러운지 다섯 가지 기준으로요. 그리고 채점자 자체도 믿지 않기로 했습니다. 점수 기준이 되는 앵커 글 9편을 정해두고, 주기적으로 재채점시켜서 채점자의 기준이 슬금슬금 변하지 않았는지(드리프트)를 감시합니다.

솔직하게 덧붙이면, 이 점수는 아직 관측 전용입니다. 점수가 낮다고 발행을 막지는 않아요. 채점기를 믿고 게이트로 쓰려면 먼저 채점기 자신의 신뢰 기록이 쌓여야 하니까요. 앞의 주치의와 같은 원칙입니다.

지표가 틀리면, 자동화는 성실하게 틀린 방향으로 달린다

1편에서 소개한 지휘자 에이전트는 매주 성과 지표를 읽고 다음 작업을 정합니다. 그런데 운영 중에 서늘한 사실을 하나 발견했어요. 지표를 만드는 코드 자체에 버그가 있으면, 자율 시스템은 그 틀린 숫자를 향해 아주 성실하게 최적화한다는 겁니다. 예를 들어 글의 언어를 웹 주소 경로로 판정하던 로직은, 일본어 글을 한국어 실적으로 계산하는 착각을 일으킬 수 있었습니다. 사람이라면 "어, 숫자가 좀 이상한데?" 하고 멈칫하겠지만, 자동화는 멈칫하지 않습니다.

그래서 지휘자 앞에 측정 무결성 게이트를 달았습니다. 지표의 시계열이 비정상적으로 끊기거나, 여러 데이터 소스가 동시에 급락하거나, 데이터의 출처가 수상하면 그 주의 자율 실행을 통째로 멈춥니다. 판단이 애매하면 실행하는 쪽이 아니라 멈추는 쪽을 택합니다(fail-closed). 비슷한 원칙을 콘텐츠에도 적용했는데, 트렌드를 종합해 보고서를 만드는 에이전트는 수집 풀에 실제로 존재하는 출처만 인용할 수 있고, 지어낸 출처가 감지되면 그 문장을 통째로 버립니다. AI가 출처를 그럴듯하게 지어내는 문제는 여전히 존재하고, 우리는 그걸 설득이 아니라 구조로 막기로 했어요.

콘텐츠를 넘어, 실험에는 대조군을 넣었다

지난 50일의 또 다른 변화는 함대의 영역이 콘텐츠를 넘어 고객 데이터와 CRM으로 넓어진 것입니다. 방문자의 행동을 이어 붙여 영업이 만나야 할 리드를 점수로 골라내는 에이전트, 고객사의 제품 활성화 단계를 매일 집계하는 퍼널, 조건에 맞는 고객군을 골라 여정에 태우고 이메일과 메시지를 보내는 캠페인 엔진이 새로 합류했습니다.

여기서 우리가 가장 공들인 부분은 화려한 기능이 아니라 대조군입니다. 캠페인을 설계할 때 일부 고객을 의도적으로 발송에서 제외한 대조군으로 남겨두고, 캠페인의 성과를 "보낸 사람들의 전환율"이 아니라 "보낸 집단과 안 보낸 집단의 차이(증분)"로 계산합니다. 그리고 대조군이 없는 캠페인에는 증분을 부풀려 보여주는 대신 정직하게 "모름"이라고 표시합니다. 마케팅 자동화가 만들어내는 숫자 중 상당수는 자동화가 없었어도 일어났을 일이거든요. 시스템이 자기 성과를 스스로 부풀릴 수 없게 만드는 것, 이것도 넓은 의미의 브레이크라고 생각합니다.

50일 동안 비싸게 배운 것들

이번에도 값을 치르고 배운 것들을 정리해둡니다.

초록불이 제일 위험합니다. 빨간불은 어떻게든 눈에 띕니다. 정말 비싼 사고는 성공으로 표시된 채 조용히 틀리고 있는 것들이었어요. 발송 워크플로우 하나는 실행 환경 설정이 잘못된 채로 만들어져서, 생겨난 이래 단 한 통도 실제로 발송된 적이 없다는 걸 한참 뒤에 알았습니다. 그래서 "고쳤다"는 다음 실행의 실제 결과로만 인정하고, 그 확인을 사람의 기억이 아니라 시스템의 계약으로 만들었습니다.

감시자도 감시가 필요합니다. 실패를 모으는 에이전트, 부재를 감지하는 에이전트, 검증을 판정하는 에이전트 중 하나가 죽으면 어떻게 될까요. 주치의는 세 소스 중 하나가 죽어도 나머지로 진단을 계속하게 만들었고(fail-soft), 진단 자체가 이상하게 돌면 전체를 멈추는 비상정지 스위치도 그대로 물려받았습니다.

신뢰는 장부로 쌓입니��. AI에게 권한을 더 줄지 말지를 놓고 토론하는 것보다, 일단 가장 낮은 권한(제안만 하기)으로 일을 시키고 사람의 승인 기록을 쌓는 게 훨씬 생산적이었습니다. 승인률이 충분히 높아지면 그때 권한을 한 칸 올리면 됩니다. 근거가 실적이니 논쟁할 일도 없고요.

보고는 읽는 사람의 언어로. 초기의 알림은 엔지니어의 언어였습니다. 지금은 모든 알림이 "무엇이 멈췄고, 어떤 영향이 있고, 다음에 뭘 하면 되는지" 세 가지로 번역되어 나갑니다. 자동화 시스템의 보고를 사람이 안 읽기 시작하는 순간이 진짜 장애의 시작이라는 걸 배웠거든요.

여전히, 한계도 분명합니다

주치의는 아직 수정안을 제안만 할 수 있고, 반영은 전부 사람이 합니다. 콘텐츠 채점기는 관측만 하고 있고, 발행을 막을 만큼 신뢰가 쌓이지 않았습니다. AI가 쓴 콘텐츠의 검수가 필수라는 1편의 결론도 그대로 유효합니다. 그리고 돌보는 장치를 아무리 만들어도 돌보는 일 자체는 사라지지 않았어요. 다만 사람이 돌보는 대상이 "48개의 에이전트"에서 "그 에이전트들을 돌보는 몇 개의 장치"로 줄었을 뿐입니다. 우리는 그 정도면 충분히 남는 장사라고 생각하고 있습니다.

마치며

1편을 쓸 때 우리는 "자율성에는 브레이크가 있어야 한다"고 적었습니다. 50일이 지난 지금은 한 문장을 더 붙이고 싶어요. 브레이크 다음에 필요한 건 계기판이라는 것. 시스템이 스스로 실패를 분류하고, 부재를 감지하고, 수정의 효과를 검증하고, 자기 성과를 부풀리지 못하게 만드는 장치들이 있어야, 사람은 안심하고 판단에만 집중할 수 있습니다.

루프 엔지니어링의 언어로 다시 말하면 이렇습니다. 좋은 루프는 트리거가 아니라 정지 조건에서 시작합니다. 그리고 루프의 자율성은 선언이 아니라, 사람의 승인 기록이 쌓인 장부를 근거로 한 칸씩 올라갑니다. AI 에이전트를 하나 만들어 굴리고 계신 분이라면, 두 번째 에이전트를 만들기 전에 첫 번째 에이전트의 실패를 어떻게 알아챌지부터, 그리고 언제 멈추게 할지부터 정해보시길 권합니다. 우리가 지난 50일 동안 배운 가장 비싼 교훈이, 결국 그 순서였습니다.

데이터라이즈는 이커머스 데이터를 기반으로 마케팅을 자동화하고 고도화하는 일을 합니다. 이런 시스템을 만들고 운영하는 이야기가 더 궁금하시거나, 비슷한 고민을 함께 풀어보고 싶으시다면 언제든 편하게 이야기 나눠요.

출처에 대하여

• 에이전트 수(28개→48개), 커밋 수(1,015개→2,810개), 머지된 PR 수(137개→약 640개), 정기 실행 스케줄 수(43개), 커밋 유형 분포: 데이터라이즈 마케팅 에이전트 저장소의 Git 기록과 에이전트 레지스트리에서 직접 확인한 값입니다(2026년 7월 19일 기준).

• 사고 사례(한 통도 발송되지 않은 워크플로우, 언어 오분류 가능성 등): 내부 사고 기록과 이를 고친 코드 리뷰에서 가져왔습니다.

• 언어모델의 자기선호 편향과 출처를 지어내는 문제: 대규모 언어모델에 대해 일반적으로 알려진 특성이며, 모델과 버전에 따라 정도는 다를 수 있습니다.

• 루프 엔지니어링과 루프 4유형(턴 기반, 목표 기반, 시간 기반, 프로액티브) 분류: Anthropic, "Getting started with loops"(2026). 유형별 우리 함대 에이전트의 대응은 저희 해석입니다.