출시 소식이라기보다는 워크플로우에 관한 노트입니다. 저는 MCP를 통해 지속적인 코드 인덱스(code index)가 연결된 대규모 모노레포(monorepo)에서 Claude Code를 실행해 왔는데, 그 차이점이 제가 예상했던 부분과는 달랐습니다.

크게 변하지 않은 점: 무언가를 찾는 것. Claude의 grep은 성능이 좋으며, 이름이 잘 지어진 코드베이스에서는 정확한 검색(exact search)이 벡터 검색(vector-search)의 홍보 내용보다 더 잘 작동합니다. 식별자(identifier)의 일부만 알아도 grep으로 찾아낼 수 있습니다.

크게 변한 점: 리팩터링(Refactor) 질문이 더 이상 읽기 연습이 아니게 되었습니다. "이 시그니처(signature)를 변경하면 무엇이 깨질까?"라는 질문은 예전에는 에이전트가 15개의 파일을 읽고, 컨텍스트 창(window)의 3분의 1을 채운 뒤, 우연히 열었던 파일들에 대해서만 맞는 답변을 내놓는 것을 의미했습니다. 이제는 호출자(callers)를 요청하고 전체 세트를 받아옵니다. 에이전트가 자신 있게 과소 보고(under-reporting)하는 일이 멈춥니다. 이것이 실제로 중요한 변화입니다. 이전의 패턴은 이랬습니다: 파일 3개를 읽고, 호출 지점(call sites) 3개를 찾고, 호출자 3개를 보고한 뒤, 그것이 전부인 것처럼 리팩터링하는 것입니다. 그 출력물에는 불완전함을 나타내는 신호가 전혀 없었기에, 나중에 무언가 깨질 때까지 저는 그것을 알아차리지 못했습니다.

컨텍스트(Context)가 더 오래 지속되므로, 세션도 더 오래 지속됩니다. 가장 큰 이점은 속도가 아니라, 세션 시작 시점에 이미 알 수 있었던 코드의 형상을 재구축하는 데 컨텍스트 창을 낭비하지 않는다는 점입니다.

도움이 되지 않는 부분: 타입 수준의 진실(type-level truth)이 필요한 모든 것. 제네릭(Generics), 동적 디스패치(dynamic dispatch), DI 컨테이너(DI containers), 몽키 패칭(monkey-patching) 등입니다. 루프 안에 타입 체커(type checker)가 없기 때문에, 언어 서버(language server)가 맞다면 이 부분은 틀릴 것입니다. 이것은 빌드 단계나 언어별 데몬(daemon)을 제공하는 것이 아니라, 정확성의 동등함(correctness parity)을 제공하는 것이 아닙니다.

세션 내 설정은 두 줄입니다: /plugin marketplace add Goldziher/basemind /plugin install basemind@basemind 로컬 방식, API 키 없음, 텔레메트리(telemetry) 없음, Rust 및 MIT 라이선스: github.com/Goldziher/basemind. 다른 분들도 과소 보고 문제를 발견했는지, 아니면 그냥 수동으로 에이전트에게 구조를 제공해 왔고 그것으로 충분했는지 궁금합니다.