네 명의 서로 다른 AI 에이전트와 함께 28,000개 파일 규모의 코드베이스를 혼자 운영하는 방법

진정한 1인 개발자의 혼돈이 어떤 것인지 묘사해 보겠습니다. 새벽 2시입니다. 당신은 에이전트 A(Agent A)에게 데이터베이스 스키마 (database schema)를 리팩토링 (refactor)하라고 지시합니다. 에이전트 A가 백그라운드에서 실행되는 동안, 당신은 에이전트 B(Agent B)에게 그에 맞춰 API 엔드포인트 (API endpoints)를 업데이트하라고 지시합니다.

10분 후, 당신의 터미널 (terminal)은 500 에러를 쏟아내고, Git 히스토리 (Git history)는 스파게티 괴물처럼 엉망이 되어 있으며, 두 에이전트는 어떻게든 git push --force라는 끝없는 파멸의 루프 속에서 서로의 의존성 (dependencies)을 덮어써 버린 상태가 됩니다.

1인 창업자로서 거대한 코드베이스 (codebase)로 규모를 확장할 때, 하나의 AI 어시스턴트 (AI assistant)만으로는 충분하지 않습니다. 당신은 UI용, 백엔드 로직 (backend logic)용, 테스트 작성용 등 여러 개의 자율 에이전트 (autonomous agents)를 가동하기 시작합니다. 하지만 AI 에이전트들은 공간적 인지 능력 (spatial awareness)이 부족합니다. 만약 이들을 자유롭게 풀어둔다면, 서로의 영역을 침범하고, 충돌하는 변수를 환각 (hallucinate)하며, 조용히 프로덕션 (production) 환경을 망가뜨릴 것입니다.

AI가 생성한 머지 충돌 (merge conflicts)을 풀어내는 고통은 솔직히 직접 코드를 작성하는 것보다 더 심합니다.

해결책은 에이전트의 수를 줄이는 것이 아니라, 그들을 위한 엄격한 "라우팅 테이블 (routing table)"을 구축하는 것입니다. 다음은 제가 네 명의 에이전트를 놀라울 정도로 생산적이고 완전히 격리된 상태로 유지하기 위해 사용하는 정확한 아키텍처 (architecture)입니다:

Become a Medium member

1. UI 샌드박스 (The UI Sandbox, 에이전트 1): 이 에이전트는 프론트엔드 디렉토리(예: /components 및 /app)로 엄격하게 제한됩니다. 저는 이 에이전트에게 API 타입에 대한 읽기 전용 (read-only) 권한을 부여하지만, 백엔드 로직을 건드리는 것은 완전히 차단합니다. 만약 버튼에 새로운 엔드포인트 (endpoint)가 필요하다면, 이 에이전트는 백엔드가 준비될 때까지 데이터를 모킹 (mock) 하도록 지시받습니다.

2. 데이터 코어 (The Data Core, 에이전트 2): 이 에이전트는 저의 핵심 작업 수행자입니다. 오직 /models 및 /database 내부에서만 작동합니다. 이 에이전트는 React가 무엇인지 알지 못하며, CSS에는 관심이 없습니다. 유일한 임무는 데이터 무결성 (data integrity)을 보장하고, 마이그레이션 (migration)을 처리하며, 깨끗한 데이터베이스 쿼리 (database query)를 작성하는 것입니다.

3. API 브릿지 (The API Bridge, 에이전트 3): 이 에이전트는 /routes 폴더에 위치합니다. 데이터 코어가 구축한 스키마 (schema)를 가져와 프론트엔드와 연결합니다. 데이터베이스 스키마 자체를 변경하는 것은 엄격히 금지됩니다. 만약 데이터 코어가 특정 필드를 제공하지 않았다면, 이 에이전트는 임의로 필드를 만들어내는 환각 (hallucinate)을 일으킬 수 없습니다.

4. 관리인 (The Janitor, 에이전트 4): 엄격하게 /tests 폴더에서 실행됩니다. 전체 코드베이스에 대한 읽기 전용 (read-only) 권한을 가집니다. 유일한 임무는 단위 테스트 (unit test)를 작성하는 것이며, 다른 세 에이전트가 필연적으로 무언가를 망가뜨렸을 때 비명을 지르는 것입니다.

당신의 AI 에이전트들을 시니어 풀스택 개발자 (senior full-stack developers)처럼 대하는 것을 멈추세요. 대신 엄격한 가드레일 (guardrails)이 필요한, 똑똑하지만 혼란스러운 주니어 개발자 (junior devs)처럼 대하세요. 그들의 환경을 분할하고, 읽기/쓰기 (read/write) 권한을 단단히 제한한다면, Git 지옥 없이도 당신의 1인 생산성은 10배로 향상될 것입니다.

만약 이 설정이 오늘 당신의 골칫거리를 해결해 주었다면, 이 흐름을 계속 이어가 봅시다. 저는 인디 개발자들이 매일 직면하는 숨겨진 문제들에 대해 가공되지 않은 날 것 그대로의 해결책을 공유합니다.