문제
새 팀에 합류했어요. 회사를 인수했어요. 핵심 의존성의 유지 관리가 끊겨서 누군가는 그 의존성을 평가해야 해요. 코드베이스는 방대하고 시간은 촉박해요.
예전 방식: 파일을 열고, grep으로 뒤지고, 몇 주에 걸쳐 머릿속 지도를 그려요. 단일 에이전트 방식: 파일을 Claude에 붙여 넣고 질문해요. 한 번에 대화 하나씩, 세션이 끝날 때마다 컨텍스트를 잃어요.
어느 쪽도 확장되지 않아요. 50만 줄짜리 코드베이스에는 모듈이 수백 개 있어요. 에이전트 하나가 품질이 떨어지기 전까지 컨텍스트에 담을 수 있는 파일은 아마 20개 정도예요. 순차적인 세션이 수십 번 필요하고, 그다음에도 결과는 여전히 사용자가 직접 종합해야 해요.
“저는 똑똑하고 유능하며 프로그래밍 경험도 많지만, Claude 에이전트 하나의 결과물을 제대로 검토할 만큼 집중력을 유지하는 것도 겨우 해내요.” (petesergeant, HN)
에이전트 하나의 결과물도 소화하기 어렵다면, 처음 보는 코드베이스에서 40개의 개별 세션 결과를 종합한다고 상상해 보세요.
Chief가 돕는 방법
코드베이스 전체를 병렬로 읽기
Chief는 사용자의 감사 목표를 병렬 읽기 작업으로 분해해요. 모듈, 서비스, 레이어마다 에이전트 하나씩이에요. 에이전트들은 코드베이스 전체로 동시에 퍼져 나가고, 각자 범위가 정해져 있어 컨텍스트가 선명하게 유지돼요. 사용자의 에이전트 구독이 허용하는 만큼 한꺼번에 실행돼요. Chief의 리팩터링 워크플로를 움직이는 것과 같은 병렬 실행을 순수 분석에 적용한 거예요.
감사 목표는 사용자가 정하고, 읽기는 에이전트가 해요
알아야 할 것을 Chief에 말하세요. “모든 데이터베이스 접근 패턴을 정리하고 N+1 쿼리를 표시해 주세요.” “모든 인증 경계를 찾아 신뢰 모델을 문서화해 주세요.” “모든 외부 API 의존성과 그 장애 양상을 파악해 주세요.” Chief가 감사 계획을 제안하고 에이전트가 실행해요. Auto mode를 켜면 감사 트랙이 작업 한도와 사용자의 제공업체 사용량 주간 상한 안에서 사람 없이 실행돼요. 사용자는 소스 파일을 한 번도 열지 않아요.
요약으로 결과를 한데 모으기
각 에이전트는 사용자의 감사 기준에 맞춰 구조화된 결과를 보고하고, Chief는 모든 결과를 마일스톤의 승인 기준에 비추어 검토해요. Chief의 요약은 모든 모듈의 결과를 취합해요. 에이전트의 원시 기록이 아니라 바로 활용할 수 있도록 정리된 결과예요. 사용자의 결정이 필요한 결과는 사용자의 할 일 목록에 올라가요(얼리 액세스).
감사 영역마다 다른 에이전트
아키텍처 분석에는 Claude Code, 기계적인 패턴 탐지에는 Codex, 테스트 커버리지 평가에는 Qwen Code를 쓰세요. Chief의 BYOA 모델로 감사 마일스톤마다 에이전트를 고를 수 있어요. 보안 검토, 의존성 매핑, 데드 코드 탐지, API 표면 목록화까지 모두 병렬로 실행돼요.
감사 세션 간에 유지되는 컨텍스트
Chief는 모든 에이전트 세션에 걸쳐 프로젝트 수준의 컨텍스트를 유지하고 결과를 다음으로 이어 가요. 그래서 나중 작업은 앞선 작업이 찾아낸 것을 바탕으로 진행돼요. 한 에이전트가 인증 모듈이 공유 미들웨어 레이어에 위임한다는 사실을 발견하면, 미들웨어를 감사하는 에이전트는 그 사실을 알고 시작해요. 처음부터 다시 시작하거나 같은 것을 반복해서 발견하는 일이 없어요.
코드베이스 감사가 병렬 에이전트에 잘 맞는 이유
1. 읽기는 완벽하게 병렬화할 수 있어요
코드베이스 감사는 순수한 읽기 작업이에요. 모든 모듈을 독립적으로 분석할 수 있어요. 병합 충돌도, 의존성 순서도 없어요. 수백 개의 파일을 동시에 면밀하게 살펴봐야 할 뿐이에요. 바로 Chief의 병렬 디스패치에 맞는 작업이에요.
2. 단일 에이전트의 컨텍스트 붕괴는 감사 품질을 망쳐요
파일 500개를 읽는 에이전트 하나는 얕고 일반적인 관찰을 내놓아요. 각자 파일 50개를 읽는 에이전트 10개는 깊고 구체적인 결과를 내놓아요. Chief는 각 에이전트를 최적의 상태, 즉 정해진 범위와 선명한 컨텍스트 안에 두면서 코드베이스 전체 그림을 조율해요.
3. 종합이 어려운 부분이고, Chief가 그걸 맡아요
가치는 개별 에이전트의 결과가 아니라 모든 결과를 아우르는 종합적인 관점에 있어요. Chief는 각 트랙을 기준에 비추어 검토하고, 모든 에이전트의 결과를 정리된 감사 보고서로 요약해요. 사용자는 원시 출력이 아니라 종합된 내용을 검토하면 돼요.
4. 감사는 반복되고, Chief는 기억해요
분기별 보안 검토. 인수 전 실사. 컴플라이언스 점검. 주요 업그레이드 전 의존성 감사. Chief의 지속적인 프로젝트 컨텍스트 덕분에 각 감사는 이전 감사를 바탕으로 진행돼요. Chief가 이미 코드베이스 구조를 알고 있으니 두 번째 감사는 더 빨라요.
예시: 40만 줄 코드베이스의 인수 전 기술 실사
1. 감사 목표 설정. CTO가 Chief를 열고 프로젝트 수준의 목표를 정해요. “인수 대상 회사의 백엔드 코드베이스에 대한 기술 실사를 완료해 주세요. 아키텍처 품질, 보안 태세, 확장 병목, 기술 부채를 평가해 주세요.”
2. Chief가 감사 계획 제안. Chief가 저장소 구조를 분석하고 병렬 감사 트랙 5개를 제안해요.
- 트랙 1 아키텍처 매핑: 서비스 경계, 데이터 흐름, 의존성 그래프(서비스 6개에 에이전트 6개)
- 트랙 2 보안 감사: 인증 경계, 입력 검증, 시크릿 관리, OWASP 공격 표면(에이전트 3개)
- 트랙 3 데이터 레이어 분석: 스키마 설계, 쿼리 패턴, 마이그레이션 이력, N+1 탐지(에이전트 2개)
- 트랙 4 인프라와 배포: CI/CD, 컨테이너 설정, 확장 특성(에이전트 1개)
- 트랙 5 코드 품질 신호: 테스트 커버리지, 데드 코드, 의존성 최신성, 오류 처리 패턴(에이전트 3개)
3. 에이전트 투입. CTO가 계획을 승인하고, 작업 한도와 제공업체 사용량의 주간 상한을 설정한 채 Auto mode를 켜요. Chief는 읽기 작업을 각각 정해진 범위로 병렬 디스패치하고, CTO의 에이전트 구독이 허용하는 만큼 한꺼번에 실행해요. 에이전트들은 읽고, 분석하고, 구조화된 기준에 맞춰 결과를 보고해요. 코드는 전혀 수정되지 않아요. 순수한 분석이에요.
4. 어디서든 모니터링. CTO가 이사회 회의 중에 휴대폰으로 진행 상황을 확인해요. 트랙 1은 80% 완료됐어요. 트랙 2는 심각한 문제 3건을 표시했어요. 서비스 2개에 하드코딩된 시크릿과 관리자 엔드포인트의 인증 검사 누락이에요. 인증 검사 누락 건은 CTO만 판단할 수 있는 사안으로 CTO의 할 일 목록에 올라가요(얼리 액세스). 트랙 3은 N+1 쿼리 패턴 14개를 찾아냈어요.
5. 종합 보고서. Chief가 5개 트랙 전체의 결과를 구조화된 실사 보고서로 요약해요. 심각한 보안 이슈 3건, 성능 병목 14건, 데이터 레이어의 중간 수준 기술 부채, 전반적으로 견고한 아키텍처. CTO는 소스 파일을 하나도 열지 않고 포괄적인 기술 평가를 손에 넣어요.
6. 결과. 보통 엔지니어링 팀이 수행하는 데 2-3주가 걸리는 실사 과정이 약 하루 만에 끝났어요. 각 에이전트는 정해진 범위에서 선명한 컨텍스트를 유지했어요. 모든 결과는 특정 모듈과 파일까지 추적할 수 있어요. CTO는 직감이 아니라 데이터에 근거해 인수 권고를 내렸어요.
플랜 참고. 이 규모의 감사는 Free 플랜의 하루 30개 작업을 훌쩍 넘기 때문에 Pro에 맞는 사례예요. Free에서는 트랙 한두 개로 시작하세요.
Chief를 써야 할 때
- 처음 보는 코드베이스를 이해해야 할 때: 새 직장, 인수, 물려받은 프로젝트, 오픈 소스 의존성 평가.
- 코드베이스가 에이전트 하나로 감당하기에 너무 클 때: 수십 개 모듈에 걸친 수백 개 파일, 어떤 단일 컨텍스트 창에도 담을 수 없는 양.
- 원시 기록이 아니라 구조화된 결과가 필요할 때: 보안 태세, 아키텍처 품질, 기술 부채 평가, 컴플라이언스 검증.
- 감사가 시간에 쫓길 때: 실사 마감, 인시던트 대응, 마이그레이션 전 위험 평가.
- 병렬 에이전트가 코드베이스의 다른 부분을 동시에 읽을 때: 정해진 범위를 각각 분석하는 에이전트 10개가 모든 것을 훑는 에이전트 하나보다 더 깊고 구체적인 결과를 내놓아요.
자주 묻는 질문
기존 코드 리뷰 도구와 무엇이 다른가요?
GitHub PR 리뷰, Reviewboard, Gerrit 같은 기존 코드 리뷰 도구는 코드의 변경 사항을 평가해요. Chief의 코드베이스 감사는 코드 자체를 평가해요. 사용자는 diff를 검토하는 게 아니라, 기존 코드베이스 전체를 읽고 분석하도록 에이전트를 보내는 거예요. 풀 리퀘스트 하나를 리뷰하는 것과 회사의 기술 스택 전체를 감사하는 것의 차이예요.
Chief는 파일을 수정하지 않고 코드베이스를 감사할 수 있나요?
네. 코드베이스 감사는 순수한 읽기 작업이에요. 에이전트는 분석하고, 결과를 보고하고, 발견한 내용을 드러낼 뿐 파일을 변경하거나 브랜치를 만들지 않아요. Chief는 읽기를 조율하고 결과를 종합해요.
Chief는 에이전트가 얕고 일반적인 관찰을 내놓지 않도록 어떻게 하나요?
각 에이전트의 범위를 제한해요. 에이전트 하나가 파일 500개를 이해하려 애쓰는 대신, Chief는 각자 파일 50개를 분석하는 에이전트 10개를 디스패치해요. 범위가 정해지면 컨텍스트가 선명해지고, 그만큼 구체적이고 실행 가능한 결과가 나와요. 그런 다음 종합 레이어가 에이전트들의 인사이트를 연결해요.
Chief로 어떤 종류의 감사를 조율할 수 있나요?
기존 코드베이스에 대한 모든 구조화된 분석이 가능해요. 보안 검토, 아키텍처 매핑, 의존성 감사, 기술 부채 평가, 컴플라이언스 검증, 마이그레이션 전 위험 분석, 테스트 커버리지 평가, API 표면 목록화, 데드 코드 탐지, 성능 병목 파악 등이에요.
코드베이스 감사에는 어떤 에이전트가 가장 좋나요?
에이전트마다 뛰어난 감사 영역이 달라요. Claude Code는 아키텍처 추론과 보안 분석에 강해요. Codex는 기계적인 패턴 탐지를 잘 처리해요. Chief의 BYOA 모델로 감사 트랙마다 에이전트를 고를 수 있고, 모두 하나의 대시보드에서 조율돼요.
Chief는 이전 감사의 결과를 기억하나요?
네. Chief는 지속적인 프로젝트 수준 컨텍스트를 유지해요. 분기별 보안 감사를 실행하면 Chief는 지난 감사에서 파악한 코드베이스 구조를 알고 있어요. 반복 감사는 더 빠르고, 지난 평가 이후 바뀐 부분에 집중할 수 있어요.
여러 코드베이스를 한 번에 감사할 수 있나요?
네. 저장소마다 각각 하나의 Chief 프로젝트가 되고 사용자의 모든 프로젝트가 한곳에 모여 있어서, 여러 저장소에 걸쳐 동시에 감사를 실행할 수 있어요. 여러 저장소로 이루어진 회사의 인수 실사나 프로젝트 전반의 보안 점검에 유용해요. Free 플랜은 프로젝트 5개까지 지원하고, Pro는 제한이 없어요.
코드베이스 감사에 Chief를 무료로 쓸 수 있나요?
네. Free 플랜에는 사용자의 에이전트로 쓰는 프로젝트 5개와 하루 30개 작업이 포함되고, 신용카드도 필요 없어요. Pro는 이 제한을 없애고 얼리 액세스 기능을 더해요. 많은 읽기 작업으로 나뉘는 대규모 감사는 보통 하루 30개가 넘는 작업이 필요하므로 Pro에 맞는 사례예요.