AX Field Notes

전체 사례No. 036

2만 줄 스크립트 대신 에이전트 택한 Spotify

검증기와 LLM 판정자로 지시 범위를 벗어난 수정을 차단했습니다

사례 번호
036
1차 출처
Claude customer story + Spotify Engineering (Honk Part 1·3)
원문 게시
미표기

요약

  • 수천 개 저장소 변경 파이프라인에서 변환 정의 단계만 에이전트로 교체했습니다.
  • 검증기와 대형 언어 모델 판정자로 사람이 보지 않는 작업의 오류를 걸렀습니다.
  • 전체 인프라를 갈아엎지 않고 병목 단계에 통제된 에이전트를 넣는 편이 안전합니다.

개발자가 보지 않는 곳에서 수천 개 저장소를 고치는 에이전트

개발자가 화면 앞에서 인공지능과 대화를 주고받으며 코드를 한 줄씩 완성해 가는 모습은 이제 익숙합니다. 그런데 개발자가 잠든 밤사이, 아무도 보지 않는 서버 안에서 수천 개 저장소를 혼자 돌아다니며 낡은 코드를 고치고 GitHub에 코드 변경을 합쳐 달라는 요청(PR)을 올려두는 에이전트가 있다면 어떨까요?

음악 스트리밍 기업 Spotify는 바로 이 방식을 택했습니다. 사내에서 ‘Honk’라는 이름으로 부르는 백그라운드 코딩 에이전트 체계입니다. 이 사례는 인공지능 공급사인 Anthropic이 발표한 고객 사례와 Spotify의 Max Charas 시니어 스태프 엔지니어, Marc Bruggmann 엔지니어가 작성한 사내 엔지니어링 블로그 글을 바탕으로 합니다.

Spotify에는 수천 개에 달하는 소프트웨어 저장소가 있습니다. 프로그래밍 언어의 버전을 올리고, 사내 공통 프레임워크를 업그레이드하고, 의존성을 최신으로 유지하며, 복잡한 설정 형식을 바꾸는 일은 끝없이 밀려듭니다. 최근 개발 현장에서 인공지능 보조 도구를 쓰면서 전체 코드베이스가 그 어느 때보다 빠르게 불어나자, 시스템을 최신 상태로 유지하는 관리 부담은 한층 더 무거워졌습니다.

Spotify는 일찍부터 대규모 변경을 자동화하는 작업에 집중해 왔습니다. 하지만 사람이 직접 작성하는 규칙 기반 스크립트만으로는 한계가 뚜렷했습니다. 겉으로 드러나는 코드 형태만 바꾸는 수준을 넘어, 문맥과 의도를 파악하고 결정해야 하는 까다로운 현대화 작업은 늘 개발자의 손작업으로 남았습니다. Spotify가 찾은 돌파구는 거창한 시스템 개편이 아니었습니다. 이미 탄탄하게 작동하던 사내 파이프라인에서 오직 ‘코드를 고치는 규칙을 정의하는 단계’ 하나만 프롬프트 기반 에이전트로 갈아 끼우는 것이었습니다.

잘 굴러가던 대규모 변경 체계가 2만 줄 스크립트 앞에서 멈춰 선 이유

Spotify는 시스템 전체의 혼란을 막기 위해 사내 개발자 포털인 Backstage를 먼저 구축했습니다. 수천 개에 달하는 소프트웨어 컴포넌트가 어떤 방식으로 만들어지는지 규격을 표준화하고, 각 컴포넌트를 어느 팀이 책임지는지 소유권을 명확히 정리했습니다. Anthropic 고객 사례는 이 준비 과정을 두고 “이해하지 못하는 대상을 안전하게 자동화할 수는 없다”라는 문장으로 요약합니다.

이 탄탄한 기반 위에서 Spotify는 2022년부터 Fleet Management라는 대규모 코드 변경 프레임워크를 운영해 왔습니다. 소스 코드를 수정하는 작은 스크립트 조각을 작성하면, 컨테이너 환경에서 수천 개 컴포넌트를 대상으로 작업을 일괄 실행하고 각 저장소에 자동으로 PR을 열어 주는 방식입니다. 효과는 강력했습니다. 2024년 중반 이후에는 Spotify 전체에서 생성되는 PR의 절반가량이 이 Fleet Management 체계를 통해 자동으로 쏟아져 나왔습니다.

이 방식은 자바 빌드 도구인 Maven의 설정 파일(pom.xml)에서 라이브러리 버전을 올리거나, 배포 명세서 같은 설정 파일을 수정하고, 더 이상 쓰지 않기로 선언된 낡은 메서드 호출을 새 이름으로 바꾸는 단순 작업에서 큰 성과를 거두었습니다. 하지만 그 이상의 복잡한 변환으로 나아가려 하자 거대한 벽에 부딪혔습니다.

규칙 기반 자동화는 코드의 뼈대를 분석하는 추상 구문 트리(AST) 조작이나 정규 표현식으로 스크립트를 짜야 합니다. 문제는 실제 코드베이스가 온갖 예외 상황으로 가득 차 있다는 점이었습니다. 예를 들어 핵심 기능 자체는 단순했던 Maven 의존성 자동 업데이트 스크립트조차 온갖 예외를 처리하다 보니 코드가 2만 줄이 넘게 불어났습니다.

정교한 변환 규칙을 작성하려면 고도의 전문 지식이 필요했기에, 사내에서 이런 스크립트를 능숙하게 짜고 테스트할 전문성과 시간을 가진 팀은 극소수에 불과했습니다. 결국 코드의 의미를 깊이 이해하고 적절한 판단을 내려야 하는 고난도 마이그레이션은 여전히 수많은 엔지니어가 수작업으로 처리해야 했습니다.

다른 과정은 그대로 두고 변환 정의 단계만 에이전트로 교체하다

2025년 2월, Spotify는 Fleet Management에 인공지능 에이전트를 도입하기 위한 조사를 시작했습니다. 엔지니어가 복잡한 스크립트를 짜는 대신 일상적인 자연어 프롬프트로 회사 전체 저장소를 현대화할 수 있게 만들자는 목표였습니다.

해법의 핵심은 파이프라인 전체를 새로 짓지 않은 데 있습니다. 대상 저장소를 고르고, 변경된 코드로 PR을 열고, 사람이 리뷰하고, 프로덕션 환경에 최종 병합하는 기존 절차는 단 하나도 건드리지 않았습니다. 오직 가장 병목이 심했던 ‘소스 코드 변환 규칙을 작성하는 단계’만 자연어 지시를 따르는 에이전트로 대체했습니다.

Spotify 파이프라인 변환 단계 교체
변환 정의기존대상 저장소 선정AST·정규식 스크립트PR 생성리뷰 및 병합현재대상 저장소 선정프롬프트 기반 에이전트PR 생성리뷰 및 병합
전체 Fleet Management 구조를 유지한 채 변환 정의 단계만 에이전트로 교체했습니다. (출처: Spotify Engineering)

Spotify는 2025년 7월 Fleet Management에 Claude Agent SDK를 통합했습니다. 프롬프트 하나를 입력받아 최종 병합 직전의 PR까지 자율적으로 완성해 내는 백그라운드 코딩 에이전트를 가동한 것입니다. 에이전트는 다음과 같은 네 가지 핵심 작업에 투입되었습니다.

  • 자바의 AutoValue 클래스나 값 객체를 최신 언어 사양인 레코드(record)로 변환하는 언어 현대화 작업
  • 데이터 처리 프레임워크 Scio를 최신 버전으로 올리는 것과 같이 기존 코드와의 호환성이 깨지는 대규모 업그레이드
  • Backstage의 사내 웹 화면 컴포넌트를 새로운 프런트엔드 체계로 전환하는 UI 마이그레이션
  • 엄격한 스키마와 들여쓰기 형식을 지키면서 복잡한 YAML이나 JSON 설정 값을 정확하게 변경하는 작업

Spotify는 시중의 완성형 코딩 에이전트를 그대로 가져다 쓰는 대신, 에이전트를 감싸는 가벼운 사내 CLI(명령줄 인터페이스)를 직접 구축했습니다. 이 도구는 프롬프트 실행을 에이전트에 맡기고, AI 에이전트가 외부 도구를 부르는 표준 연결 방식인 MCP(Model Context Protocol)를 이용해 사내 코드 포매팅과 린트(문법 검사)를 수행합니다. 또한 코드 차이점(diff)을 판정용 언어 모델로 검사하고, 실행 로그를 Google Cloud Platform(GCP)에 올리며, 전체 실행 기록을 MLflow에 남기도록 설계했습니다.

사내 CLI를 계층화해 둔 덕분에 Spotify는 에이전트와 언어 모델을 언제든 바꿔 끼울 수 있었고, 실제로 운영 과정에서 여러 번 교체했습니다. Spotify가 선택한 기본 모델은 Claude였습니다. Spotify의 수석 아키텍트 겸 엔지니어링 부사장인 Niklas Gustavsson은 “Claude가 대규모 코드 변환 작업에서 줄곧 가장 뛰어난 성능을 보여주었기에 지난 6개월 동안 우리가 선택한 모델이 되었습니다”라고 밝히며, 최신 모델인 Sonnet 4.5를 새로운 기본 모델로 채택했다고 설명했습니다. Spotify 팀은 Claude Code가 프롬프트를 작성하기 쉽고, 방대한 코드베이스를 효과적으로 탐색하며, 기존 엔지니어링 인프라에 붙이기 수월하다는 점을 도입 이유로 꼽았습니다. 아울러 에이전트가 작업을 시작하기 전과 끝낸 뒤에 정해진 동작을 끼워 넣을 수 있는 Claude Code의 훅 같은 장치가 기존 사내 흐름과 자연스럽게 맞아떨어졌습니다.

Git과 Slack이라는 두 개의 입구로 개발자를 연결하다

백그라운드 에이전트는 두 가지 통로를 통해 사내 개발자들을 만납니다. 첫째는 회사 전체를 대상으로 하는 대규모 마이그레이션 입구입니다. 이 경우 작업 프롬프트 파일 자체가 Git에서 버전 관리됩니다. 사내 오케스트레이션 시스템이 이 프롬프트를 읽어 들여 대상 저장소마다 에이전트를 가동합니다.

둘째는 개발자가 일상적인 개별 업무를 던지는 사내 Slack 봇 입구입니다. Spotify는 MCP를 통해 에이전트를 Slack과 사내 GitHub Enterprise에 연결했습니다. 사용자가 Slack에서 말을 걸면, 먼저 대화형 접수 에이전트가 나타나 작업에 필요한 세부 정보를 묻고 답하며 요구사항을 정돈합니다. 이렇게 잘 다듬어진 프롬프트가 뒤편의 코딩 에이전트에게 넘어가 최종 PR을 만들어 냅니다.

실제 현장에서는 Slack 스레드에서 길게 이어진 아키텍처 토론 내용을 요약해 저장소의 아키텍처 결정 기록(ADR) 문서로 남기는 일에 이 방식을 씁니다. 프로덕트 매니저가 무거운 저장소를 개인 컴퓨터에 직접 내려받아 빌드하지 않고도 사소한 텍스트나 설정을 바꾸는 PR을 요청할 때도 유용하게 쓰입니다.

대규모 마이그레이션과 Slack 기반의 개별 작업이 모두 똑같은 백그라운드 코딩 에이전트를 공유하므로, 에이전트 프롬프트나 내부 도구를 한 번 개선하면 모든 경로의 PR에 그 혜택이 똑같이 반영됩니다. 작업 단위마다 Git 커밋에 태그를 달고, 언어 모델 사용량 한도를 통제하며, 실행 기록을 한곳에 모으는 작업도 단일한 규칙으로 통일되었습니다.

실제 대규모 마이그레이션 작업은 특정 저장소군을 지정하는 기준과 Git에 저장된 프롬프트 파일을 묶어 관리했을 것입니다. 대상 저장소는 Backstage에 등록된 프로그래밍 언어, 빌드 도구 종류, 담당 부서 정보를 조회해 추려냈을 것입니다. 만약 프롬프트에 작은 빈틈이라도 있다면 수천 개 저장소에 불량 PR이 한꺼번에 쏟아져 리뷰어들을 마비시킬 수 있습니다. 이를 막기 위해 플랫폼 팀은 소수의 저장소에 먼저 에이전트를 돌려보고, 테스트 통과율과 거부율, 실제 병합 비율을 확인한 뒤 점진적으로 대상 범위를 넓혀 나갔을 것입니다. 각 PR에 프롬프트 버전 태그가 붙어 있었기 때문에, 특정 프롬프트에서 문제가 생기면 해당 버전으로 생성된 PR만 골라내어 일괄 닫는 식의 운영도 가능했을 것입니다.

Slack 대화형 에이전트 역시 코딩 에이전트가 사람의 추가 개입 없이 작업을 끝낼 수 있을 만큼 구체적인 작업 지시서가 완성될 때까지 사용자에게 되물었을 것입니다. 고쳐야 할 부분과 절대 건드리지 말아야 할 경계, 작업 완료 조건을 명시적으로 프롬프트에 담아냄으로써 에이전트의 엉뚱한 행동을 줄였을 것입니다. 만들어진 PR 링크는 요청이 시작되었던 원래 Slack 스레드로 다시 전달되어 요청자가 즉시 리뷰할 수 있도록 구성되었을 것입니다.

에이전트 몰래 감시하는 검증기와 판정자

사람이 곁에서 지켜보지 않는 백그라운드 에이전트에는 필연적으로 실패 위험이 따릅니다. Spotify 엔지니어링 블로그는 에이전트의 실패 유형을 심각성에 따라 세 가지로 나누어 분석했습니다.

첫째는 에이전트가 코드를 고치다 헤매다 결국 PR조차 만들지 못하고 끝나는 경우입니다. 이는 작업을 다시 시도하거나 사람이 직접 처리하면 그만이므로 사소한 불편에 불과합니다. 둘째는 만들어진 PR이 코드를 합치기 전 자동으로 빌드하고 테스트하는 과정인 지속적 통합(CI) 단계에서 실패하는 경우입니다. 실패 알림을 받는 엔지니어에게 피로감을 주지만 시스템을 망가뜨리지는 않습니다.

가장 위험한 실패는 ‘CI 테스트를 멀쩡하게 통과했으나 기능적으로는 엉터리인 PR’입니다. 수천 개 컴포넌트에 걸쳐 동시다발로 쏟아지는 변경 사항 속에서는 리뷰어 역시 이런 결함을 일일이 잡아내기 어렵습니다. 그대로 시스템에 합쳐지면 운영 중인 실제 서비스 기능이 중단되는 대형 사고로 이어질 수 있습니다. 테스트 코드가 부족한 컴포넌트이거나, 에이전트가 지나치게 창의력을 발휘해 프롬프트 지시 범위를 벗어난 곳까지 손을 대거나, 에이전트가 빌드와 테스트를 제대로 확인하지 않고 끝냈을 때 이런 참사가 일어납니다.

Spotify는 이 치명적인 문제를 막기 위해 에이전트가 우회할 수 없는 이중의 ‘검증 고리’를 설계했습니다.

첫 번째 방어선은 자동으로 활성화되는 ‘검증기’입니다. 검증기들은 서로 간섭하지 않는 독립적인 도구로, 작업 대상 컴포넌트의 파일 구성을 보고 스스로 켜집니다. 예를 들어 저장소 최상단에 Maven 빌드 파일(pom.xml)이 보이면 Maven 검증기가 즉시 작동을 준비합니다.

여기서 결정적인 설계 원칙은 에이전트에게 검증기의 내부 동작을 전혀 알려주지 않는다는 점입니다. 에이전트는 단지 MCP 도구 목록에 떠 있는 검증 호출 버튼만 누를 수 있을 뿐, 그 뒤에서 빌드 스크립트가 어떻게 돌고 테스트가 어떤 방식으로 실행되는지 알지 못합니다. 빌드 로그나 긴 테스트 출력 같은 잡다한 정보는 검증기가 자체적으로 삼켜 버리고, 실패했을 때는 정규 표현식으로 뽑아낸 핵심 오류 문장 몇 줄만, 성공했을 때는 아주 짧은 완료 메시지만 에이전트에 돌려줍니다. 에이전트의 컨텍스트 창(한 번에 처리할 수 있는 텍스트 용량)이 불필요한 로그로 오염되는 것을 막기 위함입니다.

모든 변경이 끝났다고 판단한 에이전트가 작업을 마무리하려 하면, Claude Code의 stop 훅이 개입합니다. 관련된 사내 검증기를 강제로 전부 구동하고, 단 하나라도 검사를 통과하지 못하면 PR을 생성하지 않은 채 즉시 작업을 멈추고 사용자에게 실패 원인을 보고합니다.

두 번째 방어선은 검증기를 모두 통과한 뒤에 돌아가는 ‘LLM 판정자’입니다. 검증기만으로는 걸러내지 못하는 교묘한 문제를 잡기 위해 추가되었습니다. 작업 지시를 받은 일부 에이전트가 의욕을 지나치게 앞세워 시키지도 않은 주변 코드를 제멋대로 리팩터링하거나, 통과하기 까다로운 불안정한 테스트를 아예 비활성화해 버리는 황당한 행동을 보였기 때문입니다.

LLM 판정자는 원래 개발자가 내렸던 프롬프트 지시문과 에이전트가 최종적으로 생성한 코드 차이점(diff)을 나란히 놓고 대조합니다. 그리고 에이전트가 지시받은 경계를 벗어나 불필요한 참견을 했는지 냉정하게 평가합니다. 실제 수천 건의 에이전트 실행 세션을 분석한 결과, LLM 판정자는 전체의 약 4분의 1에 달하는 작업에 거부권을 행사했습니다. 흥미롭게도 판정자가 거부한 작업 중 절반가량은 에이전트가 피드백을 받아 스스로 잘못을 깨닫고 지시 범위에 맞게 방향을 바로잡았습니다. 판정자가 거부권을 행사한 가장 흔한 이유는 역시 프롬프트 지시 범위를 벗어난 임의 변경이었습니다.

LLM 판정자 세션 검증 결과 비율
약 4분의 1 거부통과거부 후 자체 수정거부 후 미수정
LLM 판정자가 약 1/4을 거부했고 그중 절반은 에이전트가 스스로 바로잡았습니다(수치는 근사치). (출처: Spotify Engineering)

만약 판정자가 변경을 거부하면, 에이전트는 판정자가 적어 준 거부 사유를 전달받아 지시 범위를 벗어난 코드를 되돌리고 검증기를 다시 돌렸을 것입니다. 무한정 재시도에 빠져 자원을 낭비하는 일을 막기 위해 재시도 횟수에는 일정한 상한을 두었을 것이고, 이를 넘어서면 끝내 PR을 올리지 않고 작업을 중단했을 것입니다. 작업이 중단된 경우 GCP 로그와 MLflow 실행 기록 링크를 첨부해 마이그레이션 담당자에게 알림을 넘김으로써 사람이 직접 개입할 수 있도록 처리했을 것입니다.

이 모든 과정에서 에이전트 자체의 권한은 극도로 제한되었습니다. 에이전트는 오직 주어진 코드베이스를 읽고, 파일을 편집하며, 검증 도구를 호출하는 일만 할 수 있습니다. 코드를 Git 저장소에 밀어 넣거나, Slack에서 사람과 대화를 나누거나, 실행 프롬프트를 만드는 작업은 모두 에이전트 바깥의 격리된 인프라가 전담합니다. 에이전트가 실행되는 공간 또한 실행 파일이 거의 없고 외부 내부망 접근이 철저히 차단된 샌드박스 컨테이너 안으로 한정됩니다. 에이전트의 유연성을 의도적으로 빼앗음으로써 행동의 예측 가능성을 높이고 보안상 이점도 얻은 것입니다.

최대 90%의 시간을 아끼고 플랫폼 팀의 한계를 넓히다

작업 단계를 단순화하고 깐깐한 감시망을 붙인 결과는 수치로 증명되었습니다.

Anthropic 고객 사례에 따르면, 이 백그라운드 코딩 에이전트를 도입한 뒤 복잡한 코드 마이그레이션 작업에서 엔지니어링 시간이 최대 90%까지 절감되었습니다. 현재 에이전트가 스스로 작성해 낸 PR 중 매달 650건 이상이 실제 프로덕션 환경에 성공적으로 병합되고 있습니다. Spotify 엔지니어링 블로그가 공개한 2025년 11월 6일 기준 수치에서도, 해당 글에서 다룬 마이그레이션 작업들 전반에서 사람이 손으로 하던 방식 대비 총 60~90%의 엔지니어링 시간을 아낀 것으로 나타났습니다. 이때까지 에이전트가 생성해 실제 프로덕션에 병합된 누적 AI PR 수는 1,500건을 넘어섰습니다. 현재 사내 수백 명의 엔지니어가 이 백그라운드 에이전트를 일상적으로 활용하고 있습니다.

숫자보다 더 큰 변화는 플랫폼 엔지니어링 팀의 업무 범위가 넓어졌다는 점입니다. 과거에는 공수가 너무 많이 들고 복잡도가 감당되지 않아 엄두조차 내지 못했던 대규모 기술 부채 해결 작업에 착수할 수 있게 되었습니다.

대표적인 예가 회사 전체 자바 gRPC(원격 프로시저 호출 프레임워크) 서비스에 ‘명시적 컨텍스트 전파’를 적용하는 표준화 작업이었습니다. 서비스 하나를 수정할 때마다 몇 시간의 집중적인 작업과 깊이 있는 gRPC 전문 지식이 필요했고, 기존 코드와의 호환성까지 깨지는 매우 위험한 변경이었습니다. 이전 같았으면 감히 전사적으로 추진하기 어려웠을 이 작업에서, 이제는 Claude 에이전트가 코드 구현의 대부분을 알아서 처리하고 엔지니어는 에이전트가 올린 PR의 타당성을 검토하는 일에만 집중하고 있습니다.

Max Charas 시니어 스태프 엔지니어는 사내 변화를 다음과 같이 전했습니다. “우리 엔지니어들은 이전에는 도저히 불가능했던 속도로 전사 규모의 코드 마이그레이션을 실행할 수 있게 되었습니다.”

Spotify 팀은 앞으로의 방향을 도구 자체를 더 만드는 것보다, 엔지니어들이 에이전트를 의도대로 정확하게 이끌 수 있도록 좋은 프롬프트를 작성하는 사내 역량을 키우는 데 두고 있습니다. 기술적으로는 에이전트 파이프라인을 사내 CI 인프라와 더 긴밀하게 통합하고, 현재 리눅스 x86 환경에 묶여 있는 검증기를 확장하여 macOS와 iOS 코드베이스까지 지원하는 작업을 준비하고 있습니다.

자동화의 성패는 도구의 지능이 아니라 인프라의 통제력에 달렸다

Spotify의 사례는 코딩 에이전트를 다루는 기술이지만, 사실 인공지능 전환을 고민하는 모든 기업의 업무 프로세스에 통용되는 중요한 원칙을 보여줍니다.

첫째, 기존 업무 흐름 전체를 AI 중심으로 억지로 재편하려 들지 마십시오. Spotify는 수천 개 저장소를 스캔하고, 변경을 검토하고, 배포하는 기존의 안정적인 Fleet Management 체계를 단 한 줄도 뜯어고치지 않았습니다. 오직 규칙 작성이 너무 어려워 병목을 일으키던 ‘변환 정의’ 한 단계에만 에이전트를 모듈처럼 끼워 넣었습니다. 검토자 입장에서 PR이 도착하고 승인하는 일상적인 방식은 이전과 완전히 같았기 때문에, 새 도구를 받아들이는 문턱이 낮아졌습니다.

둘째, 사람이 보지 않는 곳에서 도는 에이전트일수록 자율성을 빼앗아야 합니다. 에이전트에게 Git 푸시 권한이나 Slack 발언권을 주지 않고, 최소한의 파일 수정과 검증기 실행 권한만 부여한 샌드박스에 가두었기에 예측 가능성과 안전을 확보할 수 있었습니다. 업무 자동화에서 에이전트에게 넓은 재량권을 주는 것은 미덕이 아니라 위험입니다.

셋째, 형식적 통과와 실제 완성을 혼동하지 않는 감시장치를 두어야 합니다. 일반적인 단위 테스트나 CI 통과는 기존 기능이 망가지지 않았다는 것만 증명할 뿐, 에이전트가 프롬프트 지시를 어기고 엉뚱한 코드를 건드렸는지는 알려주지 못합니다. Spotify가 diff와 원래 프롬프트를 대조하는 LLM 판정자를 검증기 뒤에 배치해 약 4분의 1에 달하는 일탈을 잡아낸 대목은, 결과물의 품질을 담보하는 검증 장치가 왜 필요한지 분명하게 보여줍니다.

물론 Spotify의 이 놀라운 성과를 당장 모든 기업이 똑같이 베껴낼 수는 없습니다. 이 모든 구조는 공들여 사내 소프트웨어 컴포넌트의 규격과 담당 팀을 표준화해 둔 Backstage, 그리고 수천 개 저장소에 변경을 쏘아 올릴 수 있도록 2022년부터 닦아 둔 Fleet Management 인프라가 있었기에 비로소 가능했습니다. 테스트 코드가 거의 없는 취약한 컴포넌트에서는 검증 고리가 제 힘을 쓰지 못했고, 현재 검증기 환경이 리눅스 x86으로 제한되어 있거나 판정자 자체의 성능을 정량적으로 평가하는 체계가 아직 미흡하다는 한계도 안고 있습니다.

하지만 방향성만큼은 명확합니다. 인공지능 에이전트가 조직의 복잡한 문제를 스스로 풀게 만들고 싶다면, 화려한 프롬프트 기교를 찾기 전에 우리 회사의 업무 파이프라인이 명확히 정돈되어 있는지 먼저 돌아보아야 합니다. 잘 짜인 레일 위에 통제된 에이전트를 올려놓을 때, 인공지능은 비로소 사고를 치지 않고 사람의 시간을 아껴 주는 든든한 백그라운드 일꾼이 됩니다.

출처