소수 개발팀에게 대규모 코드베이스 AI가 의미하는 것

왜 "대규모 코드베이스용"이라는 말이 눈에 걸리나

메타가 Muse Code를 발표하면서 내세운 핵심 문구는 "large code bases"다. 단순한 코드 완성이 아니라, 서로 얽힌 복잡한 소프트웨어에서 복잡한 태스크를 처리할 수 있는 에이전트라고 했다. 구글의 Jules, 마이크로소프트의 Copilot Workspace와 비슷한 포지셔닝이지만, 메타는 MTIA 자체 칩 개발에 투자한 인프라 역량을 배경으로 내세운다. 더 긴 컨텍스트를 더 낮은 추론 비용으로 처리하는 것 — 칩 수준 최적화 없이는 대규모 코드베이스 분석을 API로 소비하는 게 비용 문제가 된다는 걸 메타도 알고 있다는 뜻이다.

큰 기업 얘기처럼 들린다. 수십 명의 엔지니어가 수십만 줄짜리 모노레포를 관리하는 그 세계. 우리 같은 소수 팀은 Cursor나 Claude Code로 충분한 거 아닌가 싶기도 하다. 그런데 조금만 뒤집어 보면 이야기가 달라진다.

소수 팀일수록 복잡도의 압박이 더 세다

HEDVION에서 운영하는 봇만 열다섯 개가 넘는다. diet, funeral, pet, money, ssul, blog... 각각 독립적인 것 같지만 /opt/common/이라는 공용 모듈을 공유한다. db.py, claude_cli.py, discord_post.py — 이 파일 하나가 바뀌면 전체 봇이 영향을 받는다.

올해 초 실제로 겪은 일이다. 공용 경로에 db.py가 추가되면서 gov 봇의 로컬 db.py가 가려졌다. 원인은 sys.path.insert(0, '/opt/common')였고, 이게 4일 동안 발행을 멈춰놨다. 에러는 ImportError: cannot import name 'KST'. 원인을 찾는 시간보다, 봇 열다섯 개 사이의 의존성 지도를 머릿속에 갱신하면서 추적하는 과정 자체가 문제였다.

대형 팀은 이런 상황을 코드 리뷰, PR 체크리스트, 테스트 커버리지로 방어한다. 소수 팀은 그럴 인력이 없다. 역설적으로, 전체 코드베이스를 이해하고 변경의 파급 효과를 추적하는 AI의 필요성은 대형 팀보다 소수 팀에서 더 크다.

Muse Code는 실제로 무엇이 다른가

아직 일반 공개 전이라 직접 써본 건 아니다. 메타가 공개한 내용 기준으로는, 단일 파일 편집을 넘어 여러 파일에 걸친 변경을 계획하고 실행하는 에이전트 루프를 돌린다. Anthropic의 Claude Code, GitHub Copilot Workspace와 같은 "편집→실행→검증" 루프 구조다.

차별점으로 내세우는 건 "복잡한 소프트웨어 안에서의 복잡한 태스크 처리"다. 핵심은 코드베이스 전체의 컨텍스트를 유지하면서 변경을 제안하는 능력이다. 현재 Cursor + Claude에서도 @codebase 기능으로 비슷하게 쓸 수 있지만, 토큰 한계에 부딪히거나 핵심 파일을 빠뜨리는 경우가 종종 있다. Muse Code가 내세우는 건 그 한계를 밀어붙인 버전이다.

트레이드오프: 속도 절감과 신뢰 비용

도입을 고려하면 반드시 마주치는 질문이 있다. AI가 코드베이스를 이해한다는 말을 얼마나 믿을 수 있는가.

우리 봇에는 명시적으로 문서화하기 어려운 암묵적 규칙이 꽤 있다. 공용 모듈 경로 추가는 append만, insert(0) 절대 금지. 이건 코드 주석으로 포착되지 않고, 왜 이 규칙이 있는지는 사고 히스토리를 알아야 이해된다. AI 에이전트가 이 맥락 없이 "효율적으로" sys.path.insert(0, ...)를 썼다면? 그 수정을 리뷰하는 데 드는 시간이 에이전트가 절약해준 시간을 도로 잡아먹는다.

수치로 봐도 마찬가지다. 최근 AI 코딩 에이전트 벤치마크(SWE-bench Verified 기준) 상위 모델들의 해결률은 40~50%대다. 절반 가까이는 틀린다. 소수 팀에서 절반의 오답을 걸러내는 리뷰 비용은 결코 가볍지 않다. 특히 프로덕션에 곧장 붙어있는 봇이라면, AI가 제안한 변경이 cron 타이밍을 건드리거나 DB 커넥션 패턴을 깨면 실제 발행 중단으로 이어진다.

그래서 현실적인 구조는 "AI가 알아서 다 해준다"가 아니라, "AI가 드래프트를 짜고 사람이 좁은 범위에서 검증한다"다. 이 구조에서 Muse Code 같은 도구의 가치는 드래프트 품질이 얼마나 높은가에 달려있다.

우리 팀이라면 어디에 먼저 쓸까

신규 봇을 만들 때가 가장 명확한 적용점이다. 새 봇을 만들 때마다 체크리스트가 있다 — cms_site row 추가, discord_channels.json 등록, publish-progress.py 업데이트, cron 추가, 로그 경로 설정, uptime 모니터 등록... 이걸 일일이 찾아가며 빠뜨리지 않으려고 문서를 뒤지는 시간이 실제 로직을 짜는 시간보다 길 때가 있다.

"새 봇 {slug}를 만들어. 기존 봇 패턴을 참고해서 필요한 파일과 설정을 전부 잡아줘"라고 에이전트에 던질 수 있다면, 핵심 비즈니스 로직 — 어떤 크롤러를 쓸지, 어떤 주제를 어떻게 생성할지 — 에만 집중할 수 있게 된다. 뼈대 생성은 반복 패턴이 명확하고, 이쪽이야말로 에이전트가 잘하는 영역이다.

두 번째는 크로스-봇 리팩터링이다. 공용 모듈에 변경이 생길 때마다 영향받는 봇 열다섯 개를 하나씩 확인하는 건 지금도 수작업이다. "이 함수 시그니처가 바뀌면 어느 봇이 영향을 받나"를 전체 코드베이스를 읽고 알려주는 것만으로도 충분히 가치 있다. 세 번째는 레거시 파악이다. 오래된 봇일수록 왜 이렇게 짰는지 이유를 잊어버린다. 전체 모노레포 컨텍스트를 들고 추론해주는 능력은, 지금 Claude Code로도 어느 정도 되긴 하지만 한계가 명확하다.

당장 써먹을 수 있는 시사점

Muse Code가 일반 공개되기 전에도, 지금 바로 적용할 수 있는 방향이 있다.

컨텍스트 문서를 코드와 같은 위치에 둬라. AI 에이전트의 품질은 컨텍스트 품질에 비례한다. sys.path append 규칙이나 MIN_BODY_CHARS = 1500 게이트 같은 암묵적 규칙을 CLAUDE.md에 기록해온 건, 사실 AI를 위한 훈련이기도 하다. Muse Code든 뭐든, 에이전트가 읽을 수 있는 형태의 컨텍스트가 없으면 대형 코드베이스 이해 능력도 무용지물이다.

새 봇이나 기능을 만들 때는 에이전트를 "완성 코드 생성기"가 아니라 "페어 프로그래밍 파트너"로 써봐라. 체크리스트 확인과 뼈대 생성에 쓰면 실수율이 내려간다. 지금 Claude Code로도 "기존 diet 봇 패턴을 참고해서 insurance 봇의 generate.py 뼈대를 잡아줘"는 꽤 잘 된다.

공용 모듈 수정 전에 에이전트에게 영향 범위 분석을 물어보는 걸 체크리스트 항목으로 만드는 것도 바로 시작할 수 있다. 이미 Claude Code에서 @codebase로 할 수 있고, Muse Code 같은 도구는 그 분석의 신뢰도를 높이는 방향으로 쓸 수 있다. 속도는 AI가, 판단은 사람이 — 이 분업이 소수 팀에서 에이전트를 쓰는 가장 현실적인 방식이다. 도구가 아무리 좋아져도 이 구조는 당분간 바뀌지 않는다.

원문: AI News & Artificial Intelligence | TechCrunch