LLM Wiki

코딩 에이전트는 grep으로 코드를 읽는다, 68만 줄을 AI로 짠 팀이 정리한 규칙

Properties2
descriptionAI Sparkup 게시글의 핵심 내용과 실무적 의미를 원문에 근거해 정리한다.
tagsai-coding, ai-agents, ai, aisparkup, news

6 min read

출처

개요

Modem은 2025년 초부터 AI 코드 생성 도구만으로 제품을 개발해 왔으며, 애플리케이션 코드 36만 줄과 테스트 코드 32만 줄의 99.9%를 LLM으로 작성했다고 설명합니다. 이 글은 Claude Code, Codex, OpenCode 같은 코딩 에이전트가 코드를 찾을 때 임베딩이나 벡터 데이터베이스보다 grep·ripgrep 기반의 문자열 검색을 주로 사용한다는 관찰에서 출발합니다. 함수와 파일에 구체적인 이름을 붙이면 검색 결과와 에이전트가 읽어야 할 후보가 줄어들어 컨텍스트 사용량과 오답 가능성을 낮출 수 있습니다. 타입과 모듈 분할도 에이전트가 구현을 탐색하기 전에 코드의 의미와 위치를 파악하는 데 도움을 줍니다. 다만 실험에서는 이름, 파일 구조, 타입 변경이 함께 적용됐으므로 검색 가능한 이름만의 효과를 입증한 결정적 벤치마크로 보기는 어렵습니다.

핵심 포인트

  • 코딩 에이전트는 함수명 변경이나 기능 위치 탐색에서 컴파일러의 의존성 그래프나 언어 서버 심볼 정보보다 grep·ripgrep 검색에 의존하는 경우가 많습니다.
  • 이름의 구체성이 검색 후보를 크게 줄입니다. Modem의 모노레포 실험에서 create는 459개 파일·1,585개 줄, createClient는 23개 파일·466개 줄, createStripeClient는 19개 파일·43개 줄과 일치했습니다. 검색 시간은 모두 약 47~50ms로 비슷했습니다.
  • 검색 결과는 정답이 아니라 일치한 문자열이므로, 일반적인 이름은 에이전트가 주변 코드나 파일 전체를 추가로 읽게 만들어 컨텍스트 예산을 소모시킵니다.
  • import 추적만으로는 역방향 호출자 탐색, 배럴 파일의 실제 export 이름 확인, 메서드 호출 위치 파악에 한계가 있습니다. 구별되는 심볼명은 이런 상황에서 이식성 높은 검색 단서가 됩니다.
  • 구체적인 타입과 타입명은 구현을 직접 읽지 않아도 함수의 의도와 인자 역할을 드러내며, UserId와 OrgId처럼 구분된 타입은 잘못된 사용을 컴파일 오류로 노출시킵니다.
  • write-discoverable-code 스킬을 적용한 실험에서 Haiku의 토큰 소비 중앙값은 32% 줄었고, 이미 구체적인 이름을 사용하던 Sol의 절감폭은 12%였습니다. Odysseus의 대형 파일을 개념별 모듈로 나눈 실험에서는 Haiku와 Grok 4.5의 비용이 각각 34.3%, 31.5% 감소했습니다.
  • 실험 결과는 코드 탐색이 어려운 모델일수록 이름과 구조 개선의 이득이 크다는 방향을 보였지만, 스킬 적용 과정에서 여러 설계 요소가 동시에 바뀌었다는 한계가 있습니다.

왜 중요한가

AI 코딩 에이전트의 성능은 모델 능력뿐 아니라 코드베이스가 검색되고 분류되는 방식에도 영향을 받습니다. 함수명과 파일명을 구체적으로 작성하고, 대형 파일을 개념별로 나누며, 타입 정보를 명확히 하면 에이전트가 잘못된 후보를 읽는 데 쓰는 토큰과 시간을 줄일 수 있습니다. 이는 같은 작업을 더 저렴한 모델로 수행할 수 있는지, 에이전트가 제한된 컨텍스트 예산 안에서 버그를 찾아낼 수 있는지와 연결됩니다. 다만 이 글의 실험은 이름·구조·타입의 효과를 완전히 분리하지 않았으므로, 프로젝트에 적용할 때는 자체 코드베이스와 모델 조합으로 별도 검증하는 것이 필요합니다.

참고 링크

관련 위키

원문 보존 위치

원문 전체는 raw source: 2026-08-07-aisparkup-post-15054-grep-68-ai에 source_url 및 HTML 원문과 함께 저장되어 있습니다.