▲

대규모 코드베이스에서 Claude Code가 작동하는 방식 : 모범 사례 및 시작점

 (claude.com)
4P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Claude Code는 인덱스를 업로드하지 않고 개발자 머신에서 파일 시스템 탐색과 grep, 참조 추적으로 라이브 코드베이스를 직접 읽음
  • 성능은 모델만이 아니라 CLAUDE.md, hooks, skills, plugins, MCP 서버로 이뤄진 하네스와 구축 순서에 크게 좌우됨
  • 대규모 저장소에서는 얇고 계층적인 CLAUDE.md, 하위 디렉터리 시작, 범위 지정 테스트·린트, 제외 규칙이 탐색 효율을 높임
  • LSP 통합은 문자열 검색 대신 심볼 기준 정의·참조 추적을 제공해, 다중 언어·대규모 코드베이스에서 잘못된 탐색을 줄임
  • 성공적인 도입에는 3~6개월마다 설정을 검토하고, plugin·권한·규칙을 관리할 DRI 또는 agent manager가 필요함

대규모 코드베이스에서 Claude Code가 탐색하는 방식

  • Claude Code는 소프트웨어 엔지니어처럼 파일 시스템을 순회하고, 파일을 읽고, grep으로 필요한 내용을 찾고, 코드베이스 전반의 참조를 따라감
  • 개발자 머신에서 로컬로 동작하며, 코드베이스 인덱스를 빌드하거나 유지하거나 서버에 업로드할 필요가 없음
  • RAG 기반 AI 코딩 도구는 전체 코드베이스를 임베딩하고 질의 시점에 관련 청크를 가져오지만, 대규모 환경에서는 임베딩 파이프라인이 활발한 개발 속도를 따라가지 못할 수 있음
  • 인덱스가 몇 주, 며칠, 몇 시간 전 상태를 반영하면 이미 이름이 바뀐 함수나 지난 스프린트에서 삭제된 모듈을 반환할 수 있고, 해당 정보가 오래됐다는 신호도 없을 수 있음
  • Claude Code의 에이전트형 검색은 임베딩 파이프라인이나 중앙 인덱스 없이 각 개발자 인스턴스가 살아 있는 코드베이스를 기준으로 작업하게 해줌
  • 단점도 있음: Claude가 어디를 봐야 할지 알 수 있는 시작 문맥이 충분할 때 가장 잘 작동함
  • 모호한 패턴의 모든 인스턴스를 10억 줄 코드베이스에서 찾으라고 하면 작업이 시작되기도 전에 컨텍스트 창 한계에 부딪힐 수 있음
  • 코드베이스를 잘 설정하고 CLAUDE.md 파일과 skills로 문맥을 계층화한 팀일수록 더 좋은 결과를 얻음

모델만큼 중요한 하네스

  • Claude Code의 성능은 모델 자체보다 모델 주변에 구축된 하네스(harness) 에 크게 좌우됨
  • 하네스는 CLAUDE.md, hooks, skills, plugins, MCP 서버라는 다섯 확장 지점으로 구성됨
  • 각 계층은 앞선 계층 위에 쌓이므로 팀이 구축하는 순서도 중요함
  • LSP 통합과 subagents는 이 설정을 보완하는 추가 역량으로 작동함

  • CLAUDE.md 파일

    • CLAUDE.md는 Claude가 모든 세션 시작 시 자동으로 읽는 문맥 파일임
    • 루트 파일은 큰 그림을 담고, 하위 디렉터리 파일은 로컬 규칙을 담음
    • 모든 세션에 로드되므로 광범위하게 적용되는 내용에 집중해야 성능 저하를 막을 수 있음

  • Hooks

    • Hooks는 Claude의 잘못된 행동을 막는 스크립트에 그치지 않고, 설정을 지속적으로 개선하는 데 더 큰 가치가 있음
    • stop hook은 세션 중 일어난 일을 되돌아보고 문맥이 신선할 때 CLAUDE.md 업데이트를 제안할 수 있음
    • start hook은 팀별 문맥을 동적으로 로드해 개발자가 수동 설정 없이도 자신의 모듈에 맞는 설정을 받게 함
    • 린팅과 포매팅 같은 자동 검사는 Claude가 지시를 기억하게 하는 것보다 hook으로 규칙을 결정적으로 강제할 때 더 일관된 결과를 냄

  • Skills

    • Skills는 모든 세션을 비대하게 만들지 않으면서 필요한 전문성을 온디맨드로 유지하게 함
    • 대규모 코드베이스에는 수십 가지 작업 유형이 있을 수 있지만, 모든 전문성이 모든 세션에 들어갈 필요는 없음
    • Skills는 점진적 공개(progressive disclosure)를 통해 특화 워크플로와 도메인 지식을 컨텍스트 공간 밖에 두고, 필요할 때만 로드함
    • 보안 리뷰 skill은 Claude가 취약점을 평가할 때 로드되고, 문서 처리 skill은 코드 변경 뒤 문서를 업데이트해야 할 때 로드되는 식으로 동작함
    • Skills는 특정 경로에 범위를 지정할 수 있어, 결제 서비스 팀의 배포 skill이 해당 디렉터리에만 바인딩되고 모노레포의 다른 영역 작업에는 자동 로드되지 않게 할 수 있음

  • Plugins

    • Plugins는 잘 작동하는 설정이 부족 지식으로 남지 않게 배포하는 수단임
    • plugin은 skills, hooks, MCP 설정을 하나의 설치 가능한 패키지로 묶음
    • 새 엔지니어가 첫날 plugin을 설치하면 이미 Claude를 쓰던 사람들과 같은 문맥과 기능을 즉시 갖게 됨
    • plugin 업데이트는 managed marketplaces를 통해 조직 전체에 배포될 수 있음
    • 한 대형 리테일 조직은 Claude를 내부 분석 플랫폼에 연결하는 skill을 만들어 비즈니스 분석가가 워크플로를 떠나지 않고 성과 데이터를 가져오게 했고, 비즈니스 전체 롤아웃 전에 이를 plugin으로 배포함

  • Language Server Protocol 통합

    • Language Server Protocol(LSP) 통합은 Claude가 개발자의 IDE와 같은 코드 탐색 능력을 갖게 함
    • 대규모 코드베이스용 IDE 대부분은 이미 “go to definition”과 “find all references”를 구동하는 LSP를 실행하고 있음
    • Claude에 이를 노출하면 함수 호출을 정의로 따라가고, 파일 전반의 참조를 추적하며, 서로 다른 언어의 같은 이름 함수를 구분하는 심볼 수준 정밀도를 얻음
    • LSP가 없으면 Claude는 텍스트 패턴 매칭에 의존해 잘못된 심볼에 도달할 수 있음
    • 한 엔터프라이즈 소프트웨어 회사는 C와 C++ 탐색을 대규모 환경에서 안정화하기 위해 Claude Code 롤아웃 전에 LSP 통합을 조직 전체에 배포함
    • 다중 언어 코드베이스에서는 가장 가치가 높은 투자 중 하나임

  • MCP 서버

    • MCP 서버는 Claude가 직접 도달할 수 없는 내부 도구, 데이터 소스, API에 연결하는 방식임
    • 가장 성숙한 팀은 Claude가 직접 호출할 수 있는 도구로 구조화 검색을 노출하는 MCP 서버를 구축함
    • 다른 팀은 Claude를 내부 문서, 티켓 시스템, 분석 플랫폼에 연결함

  • Subagents

    • Subagents는 탐색과 편집을 분리함
    • subagent는 자체 컨텍스트 창을 가진 격리된 Claude 인스턴스로, 작업을 받아 수행한 뒤 최종 결과만 부모에게 반환함
    • 하네스가 갖춰진 뒤 일부 팀은 읽기 전용 subagent를 띄워 서브시스템을 매핑하고 결과를 파일에 쓰게 한 다음, 메인 에이전트가 전체 그림을 바탕으로 편집하게 함

  • 구성요소별 역할과 흔한 혼동

    • CLAUDE.md: Claude가 자동으로 읽는 문맥 파일이며 모든 세션에 로드됨. 프로젝트별 규칙과 코드베이스 지식에 적합하고, skill에 들어가야 할 재사용 전문성을 넣기 쉬움
    • Hooks: 핵심 시점에 실행되는 스크립트이며 이벤트로 트리거됨. 일관된 동작 자동화와 세션 학습 포착에 적합하고, 자동 실행돼야 할 일을 프롬프트로 처리하기 쉬움
    • Skills: 특정 작업 유형을 위한 패키지화된 지시이며 관련 있을 때 온디맨드로 로드됨. 세션과 프로젝트 전반에서 재사용되는 전문성에 적합하고, 모든 내용을 CLAUDE.md에 넣기 쉬움
    • Plugins: skills, hooks, MCP 설정 번들이며 설정 후 항상 사용 가능함. 조직 전체에 작동하는 설정을 배포하는 데 적합하고, 좋은 설정을 부족 지식으로 남겨두기 쉬움
    • LSP: 언어별 서버를 통한 실시간 코드 인텔리전스이며 설정 후 항상 사용 가능함. 타입 언어의 심볼 수준 탐색과 자동 오류 감지에 적합하고, 자동으로 된다고 가정하기 쉬움
    • MCP 서버: 외부 도구와 데이터 연결이며 설정 후 항상 사용 가능함. Claude가 직접 접근할 수 없는 내부 도구 접근에 적합하고, 기본이 작동하기 전에 MCP 연결부터 만들기 쉬움
    • Subagents: 특정 작업용 별도 Claude 인스턴스이며 호출 시 실행됨. 탐색과 편집 분리, 병렬 작업에 적합하고, 탐색과 편집을 같은 세션에서 처리하기 쉬움
    • LSP는 plugin 계층을 통해 접근되며, subagents는 설정된 확장 지점이 아니라 위임 역량임

성공적인 배포에서 반복된 세 가지 설정 패턴

  • 대규모에서도 탐색 가능한 코드베이스 만들기

    • Claude가 대규모 코드베이스에서 도움을 줄 수 있는 범위는 올바른 문맥을 찾는 능력에 의해 제한됨
    • 모든 세션에 너무 많은 문맥을 로드하면 성능이 떨어지고, 너무 적은 문맥은 Claude가 눈먼 상태로 탐색하게 만듦
    • 효과적인 배포는 초기에 코드베이스를 Claude가 읽기 쉽게 만드는 데 투자함

    • CLAUDE.md 파일은 얇고 계층적으로 유지

      • Claude는 코드베이스를 이동하면서 CLAUDE.md 파일을 가산적으로 로드함
      • 루트 파일은 큰 그림을, 하위 디렉터리 파일은 로컬 규칙을 맡음
      • 루트 파일은 포인터와 치명적인 주의사항만 담아야 하며, 그 밖의 내용은 잡음이 되기 쉬움

    • 저장소 루트가 아니라 하위 디렉터리에서 시작

      • Claude는 작업과 실제로 관련 있는 코드베이스 부분으로 범위가 제한될 때 가장 잘 작동함
      • 모노레포에서는 도구가 루트 접근을 전제로 하는 경우가 많아 직관에 반할 수 있음
      • Claude는 디렉터리 트리를 자동으로 위로 올라가며 발견한 모든 CLAUDE.md 파일을 로드하므로 루트 수준 문맥은 사라지지 않음

    • 테스트와 린트 명령은 하위 디렉터리별로 범위 지정

      • Claude가 한 서비스만 바꿨는데 전체 테스트 스위트를 실행하면 타임아웃이 나고 관련 없는 출력에 컨텍스트를 낭비함
      • 하위 디렉터리의 CLAUDE.md 파일은 코드베이스의 해당 부분에 적용되는 명령을 명시해야 함
      • 각 디렉터리가 자체 테스트와 빌드 명령을 가진 서비스 지향 코드베이스에서 잘 작동함
      • 깊은 교차 디렉터리 의존성을 가진 컴파일 언어 모노레포에서는 하위 디렉터리별 범위 지정이 더 어렵고 프로젝트별 빌드 설정이 필요할 수 있음

    • .ignore 파일로 생성 파일, 빌드 산출물, 서드파티 코드 제외

      • .claude/settings.json에 permissions.deny 규칙을 커밋하면 제외 규칙이 버전 관리됨
      • 팀의 모든 개발자가 별도 설정 없이 같은 노이즈 감소 효과를 얻음
      • 일부 코드베이스에서는 생성 파일 자체가 개발 대상일 수 있음
      • 코드 생성기를 다루는 개발자는 프로젝트 수준 제외 규칙을 로컬 설정에서 재정의할 수 있고, 나머지 팀에는 영향을 주지 않음

    • 디렉터리 구조가 충분하지 않으면 코드베이스 맵 구축

      • 코드가 일반적인 디렉터리 구조로 통합돼 있지 않은 조직에서는 루트의 가벼운 Markdown 파일이 도움이 됨
      • 각 최상위 폴더와 그 안에 무엇이 있는지 한 줄 설명을 적으면 Claude가 파일을 열기 전에 훑을 수 있는 목차가 됨
      • 최상위 폴더가 수백 개라면 루트 파일은 최고 수준 구조만 설명하고, 하위 디렉터리 CLAUDE.md가 다음 수준 세부 정보를 온디맨드로 제공하는 계층형 접근이 가장 잘 작동함
      • 더 단순한 경우에는 Claude가 참조해야 할 특정 파일이나 디렉터리를 @로 멘션하는 것으로 같은 역할을 할 수 있음

    • LSP 서버로 문자열이 아니라 심볼 기준 검색

      • 대규모 코드베이스에서 흔한 함수 이름을 grep하면 수천 개 매치가 나오고, Claude는 무엇이 중요한지 판단하려고 파일을 열며 컨텍스트를 소모함
      • LSP는 같은 심볼을 가리키는 참조만 반환하므로, Claude가 아무것도 읽기 전에 필터링이 이뤄짐
      • 설정하려면 언어용 code intelligence plugin과 해당 language server 바이너리를 설치해야 함
      • Claude Code 문서에는 사용 가능한 plugin과 문제 해결 방법이 포함됨

    • 예외

      • 계층형 CLAUDE.md 접근도 깨지는 엣지 케이스가 있음
      • 수십만 개 폴더와 수백만 개 파일을 가진 코드베이스, Git이 아닌 버전 관리에 있는 레거시 시스템이 이에 해당함

  • 모델 지능 변화에 맞춰 CLAUDE.md 파일 유지보수

    • 모델이 발전하면 현재 모델을 위해 작성한 지시가 미래 모델에는 방해가 될 수 있음
    • Claude가 과거에 어려워하던 패턴을 안내하던 CLAUDE.md 규칙은 새 모델에서 불필요해지거나 오히려 제약이 될 수 있음
    • 예를 들어 모든 리팩터링을 단일 파일 변경으로 나누라는 규칙은 이전 모델이 흐름을 유지하는 데 도움이 됐을 수 있지만, 새 모델이 잘 처리하는 조정된 다중 파일 편집을 막을 수 있음
    • 모델 추론이나 Claude Code 도구의 특정 한계를 보완하려고 만든 skills와 hooks는 그 한계가 사라지면 오버헤드가 됨
    • Perforce 코드베이스에서 p4 edit을 강제하기 위해 파일 쓰기를 가로채던 hook은 Claude Code가 네이티브 Perforce 모드를 추가한 뒤 중복이 됨
    • 팀은 3~6개월마다 의미 있는 설정 검토를 예상해야 함
    • 주요 모델 릴리스 뒤 성능이 정체된 것처럼 느껴질 때도 설정 검토를 할 가치가 있음

  • Claude Code 관리와 도입의 소유권 지정

    • 기술 설정만으로는 도입이 일어나지 않음
    • 가장 빠르게 퍼진 롤아웃은 광범위한 접근 전에 인프라 투자가 있었음
    • 작은 팀, 때로는 한 사람이 도구를 연결해 개발자가 처음 Claude를 만졌을 때 이미 워크플로에 맞게 작동하도록 만들었음
    • 한 회사에서는 엔지니어 몇 명이 첫날부터 사용할 수 있는 plugin과 MCP 묶음을 구축함
    • 다른 회사에서는 AI 코딩 도구 관리를 전담하는 팀이 롤아웃 전에 인프라를 준비함
    • 이 작업은 보통 신규 엔지니어 온보딩과 개발자 도구 구축을 맡는 개발자 경험 또는 개발자 생산성 조직 아래에 있음
    • 여러 조직에서는 Claude Code 생태계를 관리하는 하이브리드 PM/엔지니어 역할인 agent manager가 등장하고 있음
    • 전담 팀이 없다면 최소 실행 가능한 형태는 DRI 한 명임
    • 이 DRI는 Claude Code 설정, 설정값 판단, 권한 정책, plugin marketplace, CLAUDE.md 규칙의 소유권과 최신 상태 유지 책임을 가져야 함
    • 상향식 도입은 열의를 만들지만, 효과 있는 것들을 중앙화할 사람이 없으면 파편화될 수 있음
    • 표준화된 CLAUDE.md 계층이나 선별된 skills와 plugins 같은 Claude Code 규칙을 모으고 전파할 개인 또는 팀이 필요함
    • 이 작업이 없으면 지식은 부족 지식으로 남고 도입은 정체됨

거버넌스와 롤아웃

  • 대규모 조직, 특히 규제 산업에서는 거버넌스 질문이 일찍 등장함
  • 어떤 skills와 plugins를 사용할 수 있는지 누가 통제하는지, 수천 명의 엔지니어가 같은 것을 독립적으로 다시 만들지 않게 하는 방법, AI 생성 코드가 사람이 만든 코드와 같은 리뷰 절차를 거치게 하는 방법이 주요 쟁점임
  • 초기에는 승인된 skills의 정의된 집합, 필수 코드 리뷰 절차, 제한된 초기 접근으로 시작하고 신뢰가 쌓이면 확장하는 접근이 권장됨
  • 가장 매끄러운 배포는 초기에 엔지니어링, 정보보안, 거버넌스 대표가 함께 참여하는 교차 기능 워킹그룹을 만들고 요구사항과 롤아웃 로드맵을 함께 정의한 조직에서 나옴

조직에 적용할 때의 전제와 한계

  • Claude Code는 엔지니어가 주요 코드베이스 기여자이고, 저장소가 Git을 사용하며, 코드가 표준 디렉터리 구조를 따르는 전통적 소프트웨어 엔지니어링 환경을 중심으로 설계됨
  • 대부분의 대규모 코드베이스는 이 틀에 맞지만, 큰 바이너리 자산을 가진 게임 엔진, 비전통적 버전 관리 환경, 비엔지니어가 코드베이스에 기여하는 환경은 추가 설정 작업이 필요함
  • 제시된 패턴은 전통적 설정을 전제로 하며 여러 고객 환경에서 작동함
  • 남은 복잡성은 각 조직의 코드베이스, 도구, 조직 구조에 맞게 판단해야 함
  • Anthropic의 Applied AI 팀은 이런 패턴을 조직의 구체적 요구사항으로 옮기기 위해 엔지니어링 팀과 직접 협업함

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • “소프트웨어 엔지니어처럼” 코드베이스를 탐색한다는 표현과 결론이 서로 어긋나 보임
    자동완성이나 LSP는 항상 쓰고 유용한데, 그것도 일종의 색인 아닌가? Claude가 왜 그런 걸 못 쓰는지도 의문임
    소프트웨어 엔지니어는 코드베이스를 기억하기도 하는데, 그건 사실상 RAG에 가깝고, 자동완성되는 CMD+P로 필요한 파일을 찾는 근육 기억도 많음
    수천 명의 엔지니어가 동시에 바꾸는 전체 코드베이스에 대해 실시간일 필요는 없고, 그냥 내가 작업 중인 브랜치만 잘 보면 됨
    처음부터 파일 시스템을 순회하며 코드베이스를 탐색하는 일은 드물고, 보통 새 코드베이스일 때나 그러는데 그 경우에도 최적의 경험이라고 부르긴 어려움

    • 내가 일하는 방식과 정확히 같음
      LSP가 없던 시절부터 큰 코드베이스를 탐색하는 법을 익혔고, 오랫동안 vim을 쓰면서 grep으로 관련 파일을 찾았음
      작년에 Claude Code를 처음 써봤을 때 “뭐야, 내가 하려던 그대로 하네”라는 느낌이었음
    • 답은 글의 도입부에 있음
      Claude Code는 수백만 줄짜리 모노레포, 수십 년 된 레거시 시스템, 수십 개 저장소에 걸친 분산 아키텍처에서 운영 중이라는 전제임
      그래서 어디서나 동작하는 견고한 도구를 쓰는 일반 사례에 최적화되어 있고, 특히 크고 지저분한 코드베이스에서 그렇다는 얘기임
      다만 잘 정리된 작은 저장소라면 더 나은 도구를 쓸 수 있고 써야 한다는 지적도 맞음
      적어도 Codex는 그런 식으로 동작하고, 예를 들어 grep을 하기 전에 먼저 go doc을 사용함
    • 정말 큰 코드베이스에서는 grep과 find가 시간 초과됨
      그 규모에서 일하다 보면 Claude가 검색을 가능하게 하려고 만들어둔 도구를 쓰지 않는다는 걸 금방 알게 됨
    • 짧은 문단 안에 그럴듯한 표현이 많지만, 실제로는 희망 섞인 주장처럼 보임
      “소프트웨어 엔지니어처럼”이라는 말은 부분적으로만 맞음
      사람도 심볼 검색을 쓰지만, 특정 작업 맥락에서 기억하고 있는 심볼을 검색함
      지금 Claude Code가 심볼을 무차별 탐색하는 방식은 엔지니어가 일하는 방식과 다름
      오타 하나로 에이전트가 뭔가를 다시 구현해야 한다고 판단할 수 있고, 운 좋게 파일을 읽더라도 쉽게 환각에 빠질 수 있음
      큰 코드베이스에서 일하는 방식도 아님
      “grep으로 정확히 필요한 것을 찾는다”는 부분이 특히 마음에 걸림
      grep을 하려면 무엇을 grep할지 알아야 하고, 결과가 수천 개 나오면 전부 확인해야 함
      그런 결과가 나오면 사람은 결과를 무식하게 훑기보다 출력을 좁히는 방법을 생각함
      글의 접근은 탄탄한 권장사항이라기보다 현재 방식을 정당화하는 설명에 가까움
      “코드베이스 색인이 필요 없다”는 말도 맞긴 하지만, grep-read-grep으로 문맥을 불려가며 결국 언젠가 답을 찾는다는 뜻일 뿐임
      “Claude Code 없이도 개발자가 직접 구현할 수 있으니 Claude Code가 필요 없다”는 말과 비슷하게 들림
      이 “필요 없다”는 메시지는 결정을 절대명제처럼 커뮤니티에 전달한다는 점에서 잘못됐다고 봄
      전반적으로 조직 비용에 대해서는 솔직함
      여러 조직에서 “에이전트 매니저”라는, PM과 엔지니어를 섞은 역할이 Claude Code 생태계를 관리하기 위해 생기고 있고, 팀은 3~6개월마다 의미 있는 설정 검토를 해야 한다고 말함
      이는 사전 구축된 코드 지능 계층 없이 대규모 Claude Code를 쓰는 현실을 정확히 보여줌
      방향은 맞게 잡았지만, 글을 읽고 나면 “문제를 풀지 못했고 여기가 우리의 한계”라는 뒷맛이 남음
    • 코드베이스 일부를 처음부터 탐색하더라도, 절대 변하지 않는 부분도 있는데 매번 탐색하는 건 토큰 낭비가 큼
      Claude와 자주 다투는 지점도 탐색을 훨씬 덜 하게 만드는 것임
      거의 변하지 않는 것들을 느리고 비싼 방식으로 훑는 것보다 내가 더 잘 알고 더 빠름
      그런데 매번 같은 종류의 토끼굴로 들어감

  • 일화로, LLM 온보딩과 오케스트레이션용 프로젝트를 설계하고 있었는데 Claude가 각 파일의 처음 40줄만 읽도록 선택했음
    나중에 다른 세션에서 낮은 품질의 원인을 찾던 Claude가 그 결함을 발견하고, 문서 줄과 함수 시그니처의 입력/출력을 입력으로 삼는 AST 분석을 하도록 코드를 바꿈
    Claude의 초기 접근은 정말 좋지 않았음
    Claude Code가 얼마나 많이 수정·검토되어야 좋아질 수 있는지, 애초에 좋은 코드를 만들 수 있는지 의문이 듦
    일반화하면, Claude는 “처음 40줄만 읽기”처럼 국소적이고 식별 가능한 나쁜 결정은 고칠 수 있음
    결함이 분리되어 있고 한 코드 조각으로 추적 가능하기 때문임
    하지만 실제 소프트웨어 품질 문제는 개별적으로는 합리적인 작은 결정들이 모여 나쁜 결과를 만드는 경우가 많음
    그때는 어느 하나가 명백한 “결함”이 아니어서, 낮은 품질의 구성요소를 조각조각 생성하는 도구는 각 조각이 따로 보면 괜찮아 보이기 때문에 좋은 코드로 수렴하지 못할 수 있음

    • 문맥 보존을 위해 소스 코드를 좁은 구멍으로 들여다보도록 학습된 것 같음
      이런 경우에는 하위 로직이나 완전한 하위 에이전트가 잘 맞을 수 있음
      예를 들어 하위 에이전트에게 “이 파일을 훑고 요약해줘, X와 Y에 관련된 부분을 표시해줘. 그러면 내가 메인 문맥에서 볼게”라고 맡기는 방식임
      또 메인 작업 흐름을 주기적으로 관찰하다가, 자신이 생각 중인 파일 안의 무언가가 현재 작업과 관련 있거나 방향을 바꿀 수 있다고 판단하면 끼어들게 할 수도 있음

  • Claude Code가 큰 코드베이스에서 어떻게 동작하냐고? 간단함
    작은 프로젝트에서도 첫 프롬프트에 5시간 사용 한도의 35% 까지 먹고, 5분 안에 빨리 응답하지 않으면 캐시가 날아가서 다음 프롬프트에 또 12~15%를 내게 됨

    • 링크된 글은 이걸 피하는 방법을 설명함
      큰 코드베이스에 순진하게 풀어놓으면, 찾는 동안 토큰을 많이 태우는 게 맞음

  • Claude Code가 코드베이스를 검사해서 효과적인 하니스를 자동 생성해주면 안 되나?
    CLAUDE.md나 AGENTS.md, skills, 플러그인을 정의해봤지만 다른 사람들이 말하는 만큼의 효과는 못 얻고 있음
    예를 들어 LSP 플러그인이 있어도 Claude Code는 LSP의 심볼 이름 변경을 쓰지 않고 파일을 하나씩 느리게 고치거나, 프롬프트에 특정 단서가 들어가면 skill을 호출하라고 명시해도 호출하지 않음
    내가 잘못 쓰는 건가? 복사해서 쓸 만한 견고한 하니스 예제가 있는지 궁금함

    • 이건 몇 년째 이어진 고통 지점이고 아직 전혀 해결되지 않았음
      “A이면 X를 해라. B, C, D를 해라. A를 해라”라고 해도 그냥 X를 쓰지 않음
      “잊어버렸기” 때문임
      규칙을 만드는 데 쓴 시간이 실제로 보상받을지 믿을 수 없고, 오히려 언젠가는 실패할 거라고 믿을 수 있음
      RAG, 하니스, skills가 전부 이걸 고치겠다고 했지만 현실에서는 고치지 못했음
    • /init 사용과 코드베이스를 설명하는 CLAUDE.md 또는 AGENTS.md 파일을 두는 걸 그만뒀음
      남겨둔 건 코드베이스를 탐색하는 방법과 조사할 때 git log를 쓰라는 내용뿐인데, 이것도 아마 중복일 가능성이 큼
      나도 답을 모르겠음
      작업 중인 코드베이스는 대략 10만 줄 정도라 큰 편으로 치는지는 모르겠지만, 개인적으로는 일해본 저장소 중 가장 큼
    • 어떤 경우에는 스크립트를 단 hooks가 문맥 창에 정보를 넣어주는 방식이 효과가 있어 보임
      문맥을 제한하려고 불필요한 린터 메시지는 일부 제거해야 했음
      운영체제 패키지 저장소로 설치하고 스크립트에서 호출할 수 있는 린터나 언어별 검사기도 도움이 됨
      모델과 skill 문맥의 조합도 차이를 만들 수 있음
      4.6에서 “동작하던” skill이 4.7에서는 잘 안 맞을 수 있는데, 4.7은 더 명시적인 지시가 필요하지만 4.6보다 비교적 안정적임
      skill을 업데이트하는 것도 도움이 될 수 있고, 전후로 테스트와 실행을 비교해야 함
      Claude Code는 불필요한 도구 호출도 문맥에 넣기 때문에, 예를 들어 beads를 좋아한다면 작업을 억제해야 할 수도 있음

  • 코드베이스 색인에 대한 주장에는 동의하지 않음
    PHPStorm이나 다른 JetBrains IDE에서는 색인이 꽤 잘 동작함

    • PHPStorm 색인은 굉장함
      아주 드물게 손상된 적이 있지만 쉽게 고칠 수 있었고, 오래된 결과를 받은 적은 없음
      Claude의 검색 도구를 써봤다면 그 팀이 색인에 대해 아무것도 모른다는 데 놀라지 않을 것임
      주력 제품이 텍스트 기반 채팅인 회사가 사용자가 그 채팅에서 텍스트 검색을 쉽게 못 하게 하는 건 이해가 안 됨
    • Claude Code는 JetBrains의 MCP를 써서 그 색인을 사용할 수 있음
    • 이상한 주장임
      AI 쓰레기 글인가? GitHub Copilot도 꽤 좋은 로컬 색인을 가지고 있음
      코드를 벡터 데이터베이스에 넣는 건 그렇게 어려운 문제가 아님

  • 이 글은 Claude가 쓴 게 분명함
    군더더기가 많고 실질적인 내용은 별로 없음

  • C, C++, C#, Java, PHP처럼 팀들이 AI 코딩 도구와 항상 연결해 생각하지 않는 언어도 포함된다는 표현이 이상함
    왜 Claude Code가 그런 언어에서 잘 동작하지 않을 거라고 예상해야 하지? 어떤 언어를 연상해야 하는 건가, Python과 JavaScript인가?

  • 몇 주가 아니라 몇 달 단위로도 판이 바뀌는 업계에서, 명확한 패턴이 드러날 만큼 시간이 충분했고 그 패턴이 큰 코드베이스에서 성공적이었다니 흥미로움
    성공 기준이 뭔가? 운영 데이터베이스를 지우지 않았다는 건가, 팀 속도가 올랐다는 건가, 코드베이스 수명이 늘었다는 건가, 운영팀이 더 행복해졌다는 건가?

    • AI 도구 때문에 운영 데이터베이스가 날아갔다면, 그건 운영 리소스를 삭제할 수 있는 운영 권한을 개발자에게 준 본인과 조직의 실패라고 계속 말하고 싶음
      그런 수준의 무제한 접근 권한을 받은 회사에서 일해본 적이 없음

  • 요즘 스트레스는 전부 Claude Code가 지시를 따르지 않는 데서 오고, 코드베이스가 커질수록 더 나빠졌음
    오해는 말아야 하는데 Claude는 대단하고 좋아함
    하지만 Claude Code만 고용해서 코드베이스를 유지보수하거나 기능을 추가하게 할 수는 전혀 없음
    과거 실수에 대한 메모리 항목을 계속 추가하지만, 중요한 지시를 무시하는 문제는 여전히 약 90% 확률로 발생함
    피하는 유일한 방법은 모든 작업을 옆에서 지켜보고 결과를 엄청나게 검토하는 것뿐임
    Claude Code는 문서화나 큰 코드베이스를 이해하는 데는 훌륭하지만, 전체를 이해해야 하는 변경 작업에는 약함
    예를 들어 코드베이스 전반에 여러 엔티티용으로 쓰는 레지스트리 패턴이 약 10개 있는데, “이 하나의 레지스트리 패턴을 사용하라”는 명시 규칙이 있었는데도 Claude Code가 엔티티별로 독립된 레지스트리 4개를 따로 구현했음
    이 단순한 작업을 맞추게 하려고 반나절 동안 Claude Code에게 소리치다시피 했고, 결국 스트레스와 시간을 아끼려고 직접 수정했음

  • 각 CLAUDE.md 파일에 정확히 무엇이 들어가야 하는지 구체적인 용어로 설명도 안 해주는데, 그런 파일이 얼마나 중요한 건지 모르겠음

    • 물고기: 여기서 읽을 수 있음 https://code.claude.com/docs/en/best-practices#write-an-effe...
      낚시법: 1) 공식 skill-creator를 설치함 2) 위 링크를 사용해 claude-md-improver를 만듦 3) 공식 문서에서 progressive-disclosure 주제를 조사하게 해서 skill을 개선함 4) 새 skill을 CLAUDE.md 파일에 적용하고 변경을 받아들임
답변달기