TL;DR: tree-sitter로 콜 그래프(Call Graph)를 구축하여, 간접적인 호출 관계를 단 한 번의 쿼리로 AI 에이전트에게 제시하는 코드 지식 그래프 도구인 codegraph를 실제로 자사 리포지토리에 도입하여, 과거 가장 왕복이 많았던 리뷰 사례로 검증했다. 결과적으로 콜 그래프 질의로 검출할 수 있었던 것은 4곳 중 2곳뿐이었다. 나머지 2곳은 문제의 중심이 되는 함수를 직접 호출하지 않고, 동일한 판정 조건을 독립적으로 재구현한 '호출 관계가 없는 중복 코드'였기 때문에 콜 그래프상에서 두 지점이 연결되어 있지 않았고, 이 질의 방식으로는 검출할 수 없었다. 도구의 홍보 문구(간접 호출 누락 대책)와 우리 팀의 실제 장애 모드(독립 구현된 중복)가 맞물리지 않았다는 이야기다.

어떤 Medium 기사가 Andrej Karpathy의 발언을 인용하며, LLM에게 매번 똑같은 조사를 시키지 말고 구조를 한 번 만들어 재사용하게 하라는 취지의 이야기를 소개하고 있었다 [source: Yanli Liu, "Andrej Karpathy's Fix for LLM Memory Works on Code Too", Medium, 2026-07]. 이 발상을 코드베이스에 적용한 도구들이 몇 가지 나오고 있다. 그 기사에서 소개된 것이 colbymchenry/codegraph라는 OSS 도구다 (2026년 7월 29일 확인. GitHub상에서 ★약 6.3만, 최종 push는 7월 24일. 2026년 1월에 만들어진 것을 고려하면 반년 정도 만에 이만큼 성장한 셈이다). tree-sitter로 코드를 파싱하여 함수 및 호출 관계를 그래프로서 SQLite에 영속화하고, MCP를 통해 AI 에이전트에게 공개한다. 에이전트는 "이 함수의 호출처는 어디인가?"라는 질문을 받을 때마다 grep을 통해 여러 파일을 일일이 다시 읽는 대신, 그래프에 한 번 질의하는 것만으로 끝낼 수 있다는 설명이다. 이번에 테스트한 것은 이 codegraph뿐이며, 같은 기사에서 소개되었던 리뷰 특화 자매 도구는 대상에서 제외했다.

흥미로워 보여서 실제로 자사의 운영 리포지토리에 넣어 보았다. 다만 단순히 "편리해 보인다"에서 끝내지 않고, 과거에 실제로 비용이 많이 들었던 상황에서 테스트해 보기로 했다.

우리는 여러 AI 에이전트를 조합한 개발 체제를 갖추고 있다. 어떤 AI가 코드를 구현하면, 다른 AI가 그것을 리뷰한다. 리뷰에서 지적 사항이 나오면 수정하고, 다시 검토를 받는다. 이 왕복 횟수가 그대로 운영 비용이 된다.

사내 운영 규칙 문서에는 어떤 수정 사항이 4곳에 분산된 중복 로직을 건드리는 바람에 리뷰가 9라운드나 걸렸던 사례가 기록되어 있다. 라운드마다 "이전 라운드에서 수정한 부분은 좋아졌지만, 다른 중복 부분에는 아직 오래된 로직이 남아 있다"라는 지적이 반복되었다. 당시의 리뷰 운영은 diff로 변경된 부분을 기점으로만 보고 있었다. 아직 수정되지 않은 형제 코드들을 사전에 찾아내는 절차를 포함하지 않았던 것이다.

이것은 바로 codegraph가 해결한다고 주장하는 문제처럼 보였다——라는 것이 당시 나의 이해였다. "이 함수를 변경하면 다른 어디에 영향을 주는가"를 단 한 번의 쿼리로 찾아낼 수 있다면, 구현하기 전에 중복 지점을 전부 찾아낼 수 있을 것이다. 9라운드가 걸렸던 문제가 1라운드로 끝날지도 모른다. 다만, 이 기대가 실제로 성립할지는 아직 검증하지 않은 가설에 불과했다.

설치 자체는 몇 초 만에 끝났다. 자사 리포지토리(Python 파일 400여 개)를 인덱싱하는 데 걸린 시간도 3초 정도로 생각보다 가벼웠다.

9라운드가 걸렸던 실례의 중심 함수에 대해 "이것을 호출하는 곳은 어디인가", "이것을 변경하면 무엇이 영향을 받는가"라는 이른바 호출처 탐색 및 영향 범위 분석(Impact Analysis) 쿼리를 던져 보았다. 결과는 4곳 중 2곳밖에 나오지 않았다. 발견된 2곳은 모두 중심 함수를 직접 호출하고 있는 곳이었다.

남은 2곳을 수동으로 확인하니 이유를 알 수 있었다. 이 2곳은 문제의 중심 함수를 호출조차 하지 않고 있었다. 동일한 판정 조건("이 기사는 평가가 낮으므로 보류한다"와 같은 취지의 플래그)을 각 장소에서 독립적으로 재구현하고 있었던 것이다. 호출 관계가 없는 이상, 콜 그래프상에서 이 2곳과 중심 함수는 연결되어 있지 않다. 호출처 탐색 및 영향 범위 분석이라는 쿼리의 특성상, 중심 함수와의 사이에 호출 경로(Call Path)가 존재하지 않는 곳은 애초에 이 질의 방식으로는 나올 수가 없다.

만약을 대비하여, codegraph 자체에 내장된 자연어 검색 기능을 사용해 '이 판정 조건을 체크하는 부분이 어디인가'와 같은 질문 방식도 시도했지만, 이쪽은 엉뚱한 심볼을 대량으로 반환하는 노이즈가 많은 결과였습니다. 원하는 두 곳에는 도달할 수 없었습니다. 적어도 이번에 시도한 두 가지 종류의 문의 방법에서는 그렇습니다.

여기서 가장 큰 깨달음을 얻었습니다. codegraph가 해결하려는 것은 'A를 호출하는 것이 B이고, B를 호출하는 것이 C인데, grep으로는 C까지 도달하기 위해 지루하고 다단계적인 조사가 필요하다'라는 간접 호출의 누락입니다. grep으로도 끈기 있게 추적하면 찾아낼 수 없는 것은 아니지만, 수고와 실수의 여지가 크습니다. 이는 확실히 존재하는 문제이며, 툴 측의 데모에서도 실제로 그러한 예시가 제시되었습니다.

하지만 우리가 9라운드를 투자한 대가는 그것과는 다른 장애 모드였던 것 같습니다. '같은 일을 하는 유사한 코드가 서로를 전혀 호출하지 않고 여러 곳에 존재한다'는 중복입니다. 이는 콜 그래프를 아무리 정교하게 따라가도 나타나지 않습니다. 그곳에는 호출이라는 '연결'이 아니라, 단지 비슷한 의도를 가졌을 뿐 서로 무관한 별개의 코드 조각들만 있을 뿐이기 때문입니다.

유행하는 툴의 설명을 읽고 '이것으로 우리 문제도 해결될 거야'라고 착각하기 시작했지만, 실제로 우리의 과거 인시던트에 대입해 보고 나서야 둘이 다르다는 것을 깨달았습니다. 지금까지 해왔던 대응책—중복이 의심되면 먼저 grep으로 확인하고, 발견된 경우 관련 파일 전체를 AI 리뷰에 통째로 읽히는 것—은 적어도 현재까지 이 툴을 도입한 후에도 대체되지 않았습니다.

툴 자체의 평가와 별개로, 도입 과정 그 자체에서도 배울 점이 있었습니다.

첫 번째는 인스톨러의 '미리보기 기능'을 과신했던 것입니다. 사전에 설정 파일에 쓰여질 내용을 확인할 수 있는 옵션이 있었기 때문에, 그것으로 안전성을 확인했다고 생각했습니다. 그런데 실제로 설치를 실행하자, 미리보기에는 나타나지 않았던 변경 사항들이 또 있었습니다. 에이전트에게 프롬프트를 전송할 때마다 실행되는 자동 훅(automatic hook)과 에이전트용 행동 지침을 추가한 신규 파일입니다. 미리보기에서 보여준 범위와 실제로 쓰여지는 범위가 일치한다고 할 수 없습니다. 확인했다고 생각했지만, 사실은 확인하지 못한 부분이 남아 있었습니다.

또 하나는 효과 측정 자체에 대한 부작용이었습니다. 도입한 툴을 '매번 허가를 받는 것이 번거로우니까' 자동 허가 목록(automatic approval list)에 추가했는데, 나중에 기존 이용 상황 로그(어떤 툴이 얼마나 호출되어 승인되었는지)에서 이 툴의 호출 기록이 전혀 보이지 않게 된 것을 깨달았습니다. 편리하게 만들려던 조치가 그대로 '도입 전후로 얼마나 사용되는지'를 측정하는 수단을 스스로 무너뜨리는 결과를 초래했습니다. 효과를 측정하고 싶은 툴일수록, 실수로 자동 허가해버리기 전에 한 번 멈춰 생각하는 것이 좋을지도 모릅니다.

이번에 알게 된 것은 '이번에 시도한 두 가지 종류의 문의 방법으로 9라운드 사례를 막을 수 있었는지'라는 좁은 질문에 대한 답일 뿐이며, '도입해서 일상 업무가 편해지는지'라는 더 넓은 효과는 아직 측정하지 못했습니다. 일주일 정도 운영해 보고 리뷰 왕복 횟수나 비용에 변화가 생기는지는 별도로 확인할 계획입니다. 다만, 대조군이 없는 전후 비교일 뿐이므로, 약간의 변화가 나타난다 하더라도 그것이 정말 이 툴 덕분인지 다른 요인 때문인지 가려내기는 쉽지 않을 것 같습니다.

콜 그래프를 따라가면 발견되는 의존 관계와, 아무리 따라가도 발견되지 않는 독립적인 중복. 두 가지 모두 같은 현장에 혼재해 있다면, 후자를 찾아내는 방법은 결국 아직 인간(혹은 AI)이 grep으로 눈으로 확인하는 수밖에 없는 것일까요? 아니면 호출 관계가 아니라 '의미적 유사도'로 코드를 비교하는 다른 접근 방식이 이 간극을 메워줄 수 있을까요?

참고 링크: