ZoomInfo의 938개 파일 일주일 이식

요약

• 엔지니어 1명이 15개 에이전트를 지휘해 핵심 기능 938개 파일을 일주일 만에 옮겼습니다.
• 무분별한 생성으로 메모리 누수와 구조 왜곡 같은 인공지능 쓰레기 코드가 드러났습니다.
• 에이전트가 읽기 쉬운 협업 체계와 사전 검증 관문이 기술적 혼란을 막는 열쇠입니다.

6개월짜리 프레임워크 전환을 일주일 만에 끝낼 수 있을까요

기업용 소프트웨어를 개발할 때 오래된 프레임워크를 최신 기술로 바꾸는 작업은 모든 개발팀이 꺼리는 대표적인 난제입니다. 프레임워크란 개발자가 소프트웨어를 만들 때 지켜야 하는 기본 뼈대이자 도구 모음을 뜻합니다. 뼈대를 통째로 바꾸는 작업은 겉으로 보이는 글자만 바꾸는 단순 번역이 아닙니다. 기존 구조를 밑바닥부터 뜯어보고, 모든 세부 기능을 문서로 남긴 뒤, 새로운 문법 규칙에 맞춰 코드를 다시 써야 합니다. 이전 화면과 동작이 오차 없이 완벽히 일치하는지 확인하는 대규모 검증까지 마쳐야 비로소 끝이 납니다.

글로벌 기업 정보 플랫폼 기업인 ZoomInfo의 애플리케이션 개발팀도 똑같은 벽에 부딪혔습니다. 회사 시스템의 핵심 기능 하나를 기존 프레임워크인 Angular에서 최신 웹 프레임워크인 React로 전면 재작성해야 했습니다. 이 핵심 기능을 과거 Angular로 처음 만들었을 때의 공식 기록을 살펴보면, 엔지니어 4~5명이 매달려 꼬박 6개월 동안 개발했던 거대한 프로젝트였습니다. 이번에 다른 프레임워크로 옮겨야 할 대상 파일만 938개에 달했습니다.

그런데 ZoomInfo 엔지니어링 블로그에 Faraazuddin Mohammed가 공개한 결과는 상식을 뛰어넘었습니다. 단 한 명의 엔지니어가 전체 과정을 지휘하여 938개 파일 전체를 단 일주일 만에 React로 완전히 옮겨 냈기 때문입니다. 그 과정에서 지휘자가 실제로 손을 움직여 작업한 시간은 고작 8시간에서 12시간 사이였습니다. 4~5명이 반년 동안 매달려야 했던 분량을 에이전트 무리를 이끄는 지휘자 한 명이 일주일 만에 끝낸 비결은 무엇이었을까요.

통제되지 않은 에이전트가 쏟아내는 세 가지 결함

대규모 코드를 인공지능에게 무작정 맡겨 전환하려 하면 끔찍한 부작용이 먼저 발생합니다. 세밀한 통제 장치 없이 에이전트에게 코드를 작성하게 만들면 현업에서 이른바 ‘인공지능 슬롭(AI slop)’, 즉 저품질 쓰레기 코드가 걷잡을 수 없이 쌓이기 때문입니다. ZoomInfo 팀이 실험 과정에서 목격한 인공지능 결함은 크게 세 가지 유형으로 나타났습니다.

첫째는 테스트 코드에서 발생하는 메모리 누수였습니다. React 컴포넌트의 기능을 검증하기 위해 작성된 Jest와 RTL 단위 테스트 코드에서 문제가 터져 나왔습니다. 단위 테스트란 개별 코드 조각이 의도대로 동작하는지 작게 쪼개어 검사하는 과정입니다. 에이전트는 테스트를 빠르게 만들어 냈지만 가짜 데이터인 목(mock)을 깨끗이 정리하지 않거나, 실행 대기 중인 타이머를 방치하거나, 테스트가 끝난 컴포넌트를 해제하는 뒤처리 과정을 빠뜨려 메모리 누수를 일으켰습니다.

둘째는 원본 프레임워크의 구조를 엉뚱하게 모방하는 ‘구조적 환각’이었습니다. Angular는 외부 부품을 부품 내부로 주입해 결합을 느슨하게 만드는 의존성 주입(DI) 방식과 비동기 데이터 흐름을 다루는 RxJS 스트림을 핵심으로 씁니다. 반면 React는 상태를 독립적으로 다루는 커스텀 훅이나 전역 데이터를 공유하는 Context 문법을 쓰는 것이 표준입니다. 그런데 에이전트는 React다운 문법을 쓰지 않고, Angular의 낡은 처리 방식을 흉내 낸 비정상적으로 복잡한 우회 코드를 만들어 냈습니다.

셋째는 언어 서버의 끝없는 수정 굴레였습니다. 문법 오류를 지적하는 린트 규칙과 데이터 유형을 검사하는 타입 규칙이 서로 충돌할 때 이 문제가 나타났습니다. 에이전트가 쓰는 언어 서버가 소스 코드를 컴퓨터가 분석하기 쉽게 나무 형태로 펼친 추상 구문 트리(AST)를 자동 수정하는 과정에서 충돌 규칙을 만나자 고침 작업을 무한히 되풀이했습니다.

여기에 물리적인 컴퓨터 성능의 한계도 분명했습니다. 에이전트마다 실시간 문법 검사를 위해 TypeScript 언어 서버(LSP)를 띄워야 했는데, 이 서버가 컴퓨터 메모리를 엄청나게 잡아먹었습니다. ZoomInfo 팀은 Apple M2 Pro 칩과 32GB RAM을 갖춘 개발용 컴퓨터 한 대에서 동시에 실행할 수 있는 작업자 수의 실험상 한계가 15개임을 확인했습니다. 15개를 넘어서자마자 메모리가 폭증해 컴퓨터 전체가 다운되었습니다. ZoomInfo는 처음에는 3개에서 5개 에이전트로 시작하고, 메모리 사용률이 80% 안팎에서 안정되는 지점까지 서서히 늘려 가라고 조언합니다.

역할을 쪼개고 설계도를 먼저 그리는 멀티 에이전트 조직

ZoomInfo는 이 문제를 해결하기 위해 Claude Code 도구의 Agent Teams 설정 방식을 도입했습니다. 하나의 거대한 모델이 모든 일을 처리하게 두지 않고, 역할을 정교하게 분담하는 계층형 조직을 짠 것입니다.

본격적인 코드 작성에 들어가기 전에 팀은 ‘설계도(Blueprint)’ 단계부터 거쳤습니다. 에이전트 한 대가 /src/legacy 디렉터리에 있는 레거시 Angular 코드 전체를 먼저 샅샅이 읽었습니다. 그러고 나서 컴포넌트별 전환 실행 계획을 담은 migration_plan.md 파일을 만들었습니다. 이때 처음부터 15개 작업자가 서로 순서를 기다리며 병목에 걸리지 않고 독립적으로 동시에 코드를 작성할 수 있도록 단계를 쪼개어 계획을 세우라고 지시했습니다.

설계도가 완성된 뒤 새로운 세션을 열어 본격적인 Agent Teams 모드를 가동했습니다. 조직은 팀을 총괄하는 팀 리드 에이전트 1개와 전문 역할을 맡은 작업자 에이전트 15개로 구성되었습니다. 팀 리드는 Claude Opus 모델을 배치했고, 실제 손발이 되어 일할 15개 작업자로는 Claude Sonnet 모델을 배정했습니다. 15개 작업자의 임무는 철저히 나뉘었습니다:

• 엔지니어링 에이전트 10개: Angular 컴포넌트를 React 코드로 다시 쓰고 테마 스타일을 입히는 작업을 수행했습니다.
• 단위 테스트 에이전트 1개: Jest와 RTL을 사용해 기능 단위 검증 코드를 작성했습니다.
• Playwright 에이전트 1개: 브라우저를 직접 띄워 사용자의 실제 화면 조작 흐름을 끝에서 끝까지 검증하는 E2E(End-to-End) 테스트를 맡았습니다.
• 코드 리뷰 에이전트 2개: 새로 작성된 코드가 팀의 개발 지침과 코딩 관례를 엄격히 지켰는지 감시했습니다.
• 동등성 및 감사(Parity & Audit) 에이전트 1개: 기존 Angular의 기능이 빠짐없이 새 React 코드에 반영되었는지 점검하고 전체 작업 목록을 관리했습니다.

지휘관인 팀 리드 Opus는 작업자들의 작업 현황판인 shared_memory.json과 작업 대기열인 todo_list.md를 실시간으로 지켜보았습니다. 작업자가 응답이 없는 멈춤 상태에 빠지면 정해진 신호 시간 초과(하트비트 타임아웃) 규정에 따라 해당 프로세스를 강제로 재시작시켰습니다. 반대로 작업자가 자율적으로 해결하기에 너무 복잡하다고 판단한 문제가 나오면 작업을 건너뛰고 문서를 갱신한 뒤, 인간 지휘자에게 즉시 알려 최종 결정을 맡겼습니다.

ZoomInfo 마이그레이션 팀 구조

에이전트가 읽기 쉬운 코드베이스와 작업 통제 장치

15개의 에이전트가 한 저장소에서 동시에 일하려면 코드가 사람뿐 아니라 인공지능도 혼선 없이 파악할 수 있는 구조여야 합니다. 사람이 머릿속으로만 알고 있는 암묵적 규칙에 의존하면 에이전트들은 금세 엉뚱한 방향으로 폭주합니다. ZoomInfo는 코드 저장소를 세 가지 핵심 축으로 개편했습니다.

첫 번째 축은 무리 전체의 상태를 기록하는 ‘동적 상태 관리’였습니다. 에이전트들은 shared_memory.json 파일과 todo_list.md 파일을 전체 작업 현황판이자 대기열로 활용했습니다. 두 개 이상의 에이전트가 같은 파일을 동시에 집어 들어 작업이 엉키는 충돌을 원천 차단하기 위함이었습니다. 실제 환경에서는 작업자가 컴포넌트를 맡기 전에 상태 파일에 자신의 식별자와 상태를 먼저 기록해 소유권을 묶어 두었을 것입니다. 만약 작업이 실패하거나 지정된 시간을 넘기면 작업을 대기열로 되돌려 다른 작업자가 이어받도록 처리하고, 앞선 단계의 컴포넌트 변환이 끝나야만 뒤따르는 종속 작업들이 풀려 대기열로 나왔을 것입니다.

두 번째 축은 에이전트의 길잡이가 되는 ‘아키텍처 색인’이었습니다. 전체 진입점인 claude.md 파일이 에이전트를 agents.md 파일로 안내했습니다. 그리고 agents.md는 컴포넌트 설계 방식, 디자인 스타일 규칙, 테스트 작성 규칙, 상태 관리에서 해야 할 일과 하지 말아야 할 일을 쪼개어 적어 둔 작은 문서들로 길을 열어 주었습니다.

세 번째 축은 인간과 인공지능이 함께 갱신하는 ‘살아 있는 설계도’였습니다. 초기 생성된 migration_plan.md는 고정된 문서가 아니라 팀 리드 Opus와 인간 엔지니어가 지속적으로 수정해 나가는 작전판이었습니다. 여기에 사용자 인터페이스를 다듬는 프런트엔드 디자인 스킬, TypeScript 언어 서버의 실시간 타입 검사, 브라우저를 가상으로 띄워 렌더링을 직접 확인하는 Playwright MCP 연결이 한 덩어리로 결합되었습니다.

에이전트 맥락 색인 트리

검증 역할을 맡은 Playwright 에이전트는 테스트가 실패해도 React 코드를 직접 고치지 않고, DOM 불일치와 콘솔 에러를 shared_memory.json에 기록해 팀 리드에게 알렸습니다. 코드를 직접 수정하다 생길 부작용을 막기 위해 역할을 이처럼 제한했을 것입니다. 또한 기존 Angular 앱과 새로 만든 React 앱에 동일한 시나리오를 실행하여 결과를 비교했을 것입니다.

저품질 코드가 본 코드에 섞여 들어가지 않도록 막는 방패는 감사 에이전트였습니다. 이들은 인간 개발자가 풀 리퀘스트(PR)를 최종 검토하기 전에 1차 관문 역할을 수행했습니다. 작업자들이 임의로 남겨 둔 ‘TODO’ 주석이나 컴포넌트 경계 위반, 아키텍처 규칙 위반을 무자비하게 걸러냈습니다. 아마도 코드 문법 검사기인 ESLint와 TypeScript 컴파일러 결과를 규칙 문서와 대조해 검증하고, 동일한 파일에서 자동 수정이 계속 헛돌면 즉시 중단하고 인간에게 알리는 차단 장치를 가동했을 것입니다.

엔지니어의 일은 코드 작성에서 환경 설계로 바뀝니다

ZoomInfo가 발표한 수치는 놀라운 속도 향상을 보여줍니다. 938개 파일에 달하는 핵심 기능 프레임워크 전환을 수작업으로 진행했다면 4~5명의 엔지니어가 6개월 동안 매달려야 했습니다. 하지만 멀티 에이전트 방식을 적용하자 단 1명의 엔지니어가 15개 에이전트를 지휘하여 일주일 만에 완결했습니다. 지휘자가 순수하게 투입한 작업 시간은 8~12시간에 불과했습니다.

이 결과가 주는 가장 큰 의미는 엔지니어의 역할이 근본적으로 변했다는 사실입니다. 전통적인 개발에서 엔지니어의 산출물은 키보드로 한 줄씩 쳐 내려간 코드 자체였습니다. 그러나 이번 프로젝트에서 엔지니어의 산출물은 발판(scaffolding)과 맥락, 그리고 피드백 고리를 설계하는 일로 바뀌었습니다. 개발 지침서와 테마 파일, 로컬 검증 서버, 정교한 프롬프트를 깔아 두는 ‘에이전트 우선’ 환경을 구축하자, 실제 기계적인 코드 작성과 반복 변환은 에이전트들이 도맡아 끝냈습니다.

이로 인해 엔지니어는 단순 반복 노동에서 완전히 해방되었습니다. 대신 전체 시스템의 아키텍처 예외 상황을 처리하고 미세한 품질을 다듬는 ‘마지막 구간(last mile)‘에 자신의 시간과 집중력을 온전히 쏟아부을 수 있었습니다.

그러나 ZoomInfo 팀은 결코 멀티 에이전트가 저절로 모든 것을 해결해 주는 만능 해결책은 아니라고 못 박습니다. 대규모 에이전트가 쏟아내는 엄청난 코드 무질서도(엔트로피)를 통제하려면 오히려 “강한 기술적 규율”이 필요하다고 강조합니다. 규율이 느슨해지는 순간 에이전트 무리는 순식간에 시스템을 망가뜨리는 거대한 기술 부채를 양산하기 때문입니다.

이 사례가 비개발 직군과 기업 리더에게 던지는 질문

ZoomInfo의 사례는 소프트웨어 개발팀뿐 아니라 기업의 디지털 전환을 고민하는 모든 조직에 세 가지 명확한 원칙을 시사합니다.

첫째, 에이전트는 철저한 가드레일 안에서만 협력자로 일해야 합니다. 인간 설계자가 전체 작업 고리 안에 머물며 통제권을 쥐고 있어야지, 인공지능에게 모든 판단을 백지위임해서는 안 됩니다.

둘째, ‘에이전트가 읽기 쉬운 환경’을 만드는 데 먼저 투자해야 합니다. 사람이 보기에만 그럴싸한 방대한 문서는 수많은 에이전트를 조율하는 데 아무런 도움이 되지 않습니다. 파일 상태를 추적하고 맥락을 명확히 전달하는 기계 친화적 색인 체계가 선행되어야 생산성이 폭발합니다.

셋째, 인간의 지능은 마지막 20%의 복잡한 영역에 아껴 써야 합니다. 대량의 기계적 반복 작업은 잘 짜인 에이전트 무리에 과감히 위임하고, 인간은 조직의 과거 맥락, 특수한 예외 처리, 최종적인 완성도 검증 같은 고차원적 판단에 집중해야 조직의 생산성을 극대화할 수 있습니다.

물론 이번 성과를 기업의 모든 코드 전환에 섣불리 일반화해서는 안 됩니다. 이번 사례는 전체 시스템이 아니라 격리된 특정 핵심 기능 하나를 옮긴 실험이었습니다. 실제로 코드를 배포한 이후 장애 발생 비율이 어떠했는지, 장기적인 유지보수 비용이 얼마나 들었는지는 아직 공개되지 않았습니다. 그럼에도 불구하고 15개의 에이전트를 하나의 조직처럼 통제해 6개월짜리 프로젝트를 단 일주일 만에 끝내 보인 ZoomInfo의 실험은, 앞으로 지식 노동이 조직되고 운영될 미래의 명확한 단서를 던져 주고 있습니다.

---

출처

ZoomInfo Engineering — Experience with Multi-Agent AI for Framework Migration at ZoomInfo — https://engineering.zoominfo.com/experience-with-multi-agent-ai-for-framework-migration-at-zoominfo — 2026-04-08 (Applications Team at ZoomInfo)