AI 코딩 에이전트에게 “이 메서드를 삭제해도 되는가”, “이 인터페이스 구현체를 모두 바꿔라”, “이 생성자의 호출부를 찾아라”라고 맡겼을 때 가장 먼저 흔들리는 것은 코드 작성 능력이 아니라 탐색의 정확도입니다. 에이전트가 같은 문자열을 찾는 것과, C# 컴파일러가 어떤 선언과 호출을 연결했는지 아는 것은 다른 일입니다.
특히 여러 프로젝트로 나뉜 .NET 솔루션, 오버로드가 많은 도메인 코드, 제네릭과 인터페이스 구현이 얽힌 서비스에서는 텍스트 검색 결과만으로 수정 범위를 확정하기 어렵습니다. 이때 Roslyn과 MSBuild를 통해 심볼, 호출, 참조, 상속, 구현 관계를 추출하는 컴파일러 기반 코드 탐색이 도움이 될 수 있습니다.
다만 이를 곧바로 “AI 에이전트용 코드 그래프 도입”으로 연결할 필요는 없습니다. 작은 서비스나 변경 범위가 좁은 팀에서는 IDE 탐색과 저장소 검색만으로도 충분할 수 있습니다. 판단의 출발점은 도구의 기능 목록이 아니라, 에이전트가 현재 어떤 종류의 실수를 내고 있는가입니다.
세 가지 선택지의 차이는 검색 속도가 아니라 증거의 수준에 있다
C# AI 코딩 에이전트가 저장소를 이해하도록 돕는 방법은 크게 세 층으로 나눌 수 있습니다.
| 선택지 | 에이전트가 얻는 정보 | 잘 맞는 작업 | 주의할 한계 |
|---|---|---|---|
| 파일명·문자열 검색 | 파일 위치, 이름이 같은 코드 조각, 텍스트 일치 | 설정 찾기, 명확한 클래스명 탐색, 작은 수정 | 오버로드, 별칭, 인터페이스 호출, 생성 코드에서 오판할 수 있음 |
| IDE 또는 언어 서버 탐색 | 정의 이동, 사용처 찾기, 일부 진단 결과 | 개발자가 대화형으로 검토하는 작업 | 헤드리스 에이전트 실행 환경에서 동일하게 활용하기 어려울 수 있음 |
| 컴파일러 기반 심볼 인덱스 | 선언 식별자, 바인딩된 호출, 참조, 상속, 구현, 프로젝트 정보 | 다중 프로젝트 변경, 리팩터링, 영향 분석, 삭제 후보 조사 | 빌드 환경과 인덱스 최신성을 운영해야 함 |
| 아키텍처·품질 분석 플랫폼 | 의존성, 규칙, 메트릭, 추세, 시각화 | 구조 개선 계획, 품질 관리, 조직 단위 거버넌스 | 에이전트의 즉시 코드 탐색 문제에는 과할 수 있음 |
텍스트 검색은 “ProcessOrder라는 철자가 어디에 있는가”를 답합니다. 반면 컴파일러 기반 탐색은 “어느 ProcessOrder 선언이 어느 호출과 연결되는가”를 답하는 쪽에 가깝습니다.
이 차이는 오버로드에서 바로 드러납니다. 같은 이름의 메서드가 매개변수 유형별로 여러 개 있을 때, 텍스트 검색은 후보를 나열할 뿐입니다. C# 컴파일러는 호출 시점의 인수 유형, 제네릭 추론, 확장 메서드 규칙 등을 적용해 실제 대상 심볼을 결정합니다. AI 에이전트가 그 결론을 받아야 변경 후보를 덜 섞습니다.
인터페이스도 마찬가지입니다. IOrderService를 참조하는 파일을 찾는 것만으로는 어떤 구현체가 배포 구성에서 쓰이는지, 특정 멤버가 어느 구현으로 연결되는지 알기 어렵습니다. 컴파일러가 해석한 implements, overrides, inherits 관계는 에이전트가 추측 대신 확인 가능한 정적 근거를 따라가게 합니다.
코드 그래프가 효과를 내는 C# 코드베이스의 조건
컴파일러 기반 탐색은 모든 저장소에서 같은 가치가 나오지 않습니다. 다음 조건이 겹칠수록 도입 우선순위가 높아집니다.
첫째, 솔루션 경계가 복잡한 경우입니다. API, 애플리케이션, 도메인, 인프라, 테스트 프로젝트가 분리되어 있고 프로젝트 간 참조가 많다면, 에이전트는 파일 트리만 읽어서 호출 경로를 복원하기 어렵습니다. 어떤 호출이 운영 코드인지 테스트 코드인지도 프로젝트 메타데이터를 함께 봐야 구분할 수 있습니다.
둘째, 변경 요청이 영향 분석을 포함하는 경우입니다. “이 기능을 추가하라”보다 “이 계약을 바꾸되 기존 호출자를 빠뜨리지 마라”, “사용되지 않는 내부 API를 정리하라”, “특정 인터페이스를 구현한 모든 클래스를 점검하라” 같은 작업에서 의미가 큽니다. 이런 요청은 생성보다 탐색과 검증의 비중이 높습니다.
셋째, AI 에이전트가 이름 충돌이나 참조 누락을 반복하는 경우입니다. 예를 들어 같은 이름의 DTO와 도메인 모델을 잘못 수정하거나, 테스트 전용 헬퍼를 운영 코드 사용처로 오해하거나, 가상 메서드의 재정의를 놓치는 일이 반복된다면 원인은 모델의 추론력보다 탐색 입력의 모호함일 수 있습니다.
넷째, CI나 개발 환경에서 솔루션을 재현 가능하게 로드할 수 있는 경우입니다. 컴파일러 기반 인덱싱은 소스 파일만 읽지 않습니다. 프로젝트 파일, SDK, 패키지, 대상 프레임워크, 조건부 컴파일 설정이 맞아야 Roslyn이 코드 의미를 제대로 해석할 수 있습니다. 빌드가 개발자 PC마다 다르게 열리는 상태라면 그래프 도입보다 먼저 빌드 재현성을 정리하는 편이 낫습니다.
반대로 단일 프로젝트 규모가 작고, 에이전트가 주로 테스트 추가나 화면 단위 수정처럼 좁은 일을 맡는다면 코드 그래프는 관리 대상만 늘릴 수 있습니다. 이 경우에는 저장소 안내 문서, 명확한 디렉터리 규칙, 테스트 실행 명령, 검색 규칙을 정비하는 쪽이 비용 대비 효과가 클 수 있습니다.
“사용처 없음”은 삭제 승인 신호가 아니라 검토 후보 신호다
컴파일러 기반 인덱스가 주는 가장 유용하면서도 위험한 정보 중 하나는 들어오는 참조가 없는 선언입니다. 이를 곧바로 죽은 코드라고 판단하면 안 됩니다.
정적 분석이 포착하기 어려운 경로가 있기 때문입니다. 리플렉션, 문자열 기반 타입 로딩, DI 컨테이너 등록, ORM 매핑, 직렬화 프레임워크, 소스 생성 결과, 외부 플러그인 계약은 일반적인 호출 그래프에 나타나지 않거나 제한적으로만 나타날 수 있습니다. 런타임에 도달하지 않는다는 증명과, 현재 인덱스에서 참조가 관찰되지 않았다는 사실은 다릅니다.
따라서 에이전트에게는 다음처럼 역할을 제한하는 편이 안전합니다.
- 인바운드 참조가 없는 멤버를 삭제하지 말고 후보 목록으로 분류한다.
- 호출자 프로젝트와 파일 위치를 제시해 운영 코드와 테스트 코드를 구분한다.
- 인터페이스 구현, 상속, 오버라이드 관계를 함께 확인한다.
- DI 등록, 리플렉션, 설정 파일, 직렬화 계약 여부는 별도 검색과 사람 검토 항목으로 남긴다.
- 수정 뒤에는 해당 솔루션 구성에서 빌드와 테스트를 실행해 가설을 검증한다.
이 원칙은 AI 에이전트의 자율성을 낮추자는 뜻이 아닙니다. 오히려 에이전트가 “확인된 정적 사실”, “추가 확인이 필요한 런타임 경로”, “수정 제안”을 구분해 보고하도록 만들자는 뜻입니다. CTO와 개발 리드는 에이전트의 답변이 그럴듯한가보다, 어떤 근거로 범위를 정했는지 검토할 수 있어야 합니다.
도입은 그래프 저장소부터 시작하지 않아도 된다
코드 그래프라는 말을 들으면 별도 데이터베이스, 질의 언어, 시각화 화면부터 떠올리기 쉽습니다. 그러나 AI 코딩 에이전트 목적이라면 첫 단계에서 그 모든 요소가 필요하지는 않습니다.
Roslyn과 MSBuild 기반 인덱서는 솔루션을 읽어 심볼 노드와 관계 데이터를 JSON 같은 공개 형식으로 내보낼 수 있습니다. 예를 들어 Graphify C#은 헤드리스 환경에서 C# 소스를 인덱싱하고, 호출·참조·구현·상속·재정의 관계를 추출하는 도구입니다. 별도 IDE나 컴파일된 프로젝트 DLL 없이 동작하도록 설계되어 있으며, 솔루션과 프로젝트 파일을 입력으로 받을 수 있습니다. 다만 필요한 SDK, 패키지, MSBuild 입력은 로컬 환경에서 उपलब्ध해야 합니다.
탐색 단계의 팀이라면 다음 순서가 현실적입니다.
-
실패 작업을 먼저 모은다. 최근 AI 에이전트 PR 가운데 참조 누락, 잘못된 오버로드 수정, 구현체 누락, 테스트 코드 오판이 있었던 작업을 골라냅니다. “그래프가 좋아 보인다”는 이유만으로 시험 과제를 만들지 않는 편이 좋습니다.
-
한 솔루션에서 인덱스 정확도를 확인한다. 에이전트가 찾기 어려웠던 메서드나 인터페이스를 대상으로, 컴파일러 기반 결과가 사람이 IDE에서 확인한 사용처와 얼마나 일치하는지 봅니다. 이 단계에서는 그래프 쿼리 UI보다 심볼 식별과 프로젝트 구분이 정확한지가 중요합니다.
-
에이전트 지시문을 바꾼다. “검색해 보라”는 지시만으로는 부족합니다. 구조와 사용처 질문에서는 인덱스를 갱신하고, 선언은 이름이 아니라 심볼 식별자로 확인하며, 참조가 없다는 결과를 런타임 미사용 증명으로 해석하지 않도록 규칙을 명시해야 합니다.
-
PR 단위로 효과를 비교한다. 구현 시간만 보지 말고 사람이 수정 범위를 다시 찾는 시간, 누락으로 인한 재작업, 검토자가 근거를 확인하는 난이도를 함께 봅니다. 인덱싱 시간이 줄어도 검토 부담이 늘면 운영상 이득이 아닐 수 있습니다.
-
갱신 책임을 정한다. 인덱스가 오래되면 정확한 심볼 관계도 오래된 답이 됩니다. 로컬 작업 시작 시, 에이전트 세션 시작 시, PR 검증 시점 중 어디에서 갱신할지 정해야 합니다. 대규모 솔루션에서는 전체 재생성과 증분 갱신 중 어느 쪽이 개발 흐름을 덜 방해하는지도 확인해야 합니다.
구매나 내재화 전에 확인할 운영 질문
외부 도구를 도입하든 내부 스크립트를 만들든, 제품 데모보다 아래 질문에 답할 수 있는지 확인하는 편이 낫습니다.
- 우리 솔루션의 대상 프레임워크, 조건부 컴파일, 사설 패키지 피드를 포함해 프로젝트를 안정적으로 로드할 수 있는가?
- 생성 코드, 테스트 프로젝트, 도구 프로젝트를 인덱스에 포함하거나 제외하는 기준은 무엇인가?
- 동일한 이름의 오버로드와 제네릭 메서드를 심볼 단위로 구분하는가?
- 인터페이스 구현, 가상 메서드 재정의, 상속 관계를 어떤 방향의 관계로 제공하는가?
- 에이전트가 인덱스 결과를 읽기 쉬운 형식인가, 별도 질의 서버나 전용 UI가 필요한가?
- 소스 코드와 인덱스 산출물이 개발자 장비, CI, 외부 AI 서비스 중 어디에 저장되는가?
- 인덱스 실패나 복원 실패가 발생했을 때 에이전트는 추측으로 계속 작업하는가, 작업을 중단하고 사람에게 알리는가?
여기서 마지막 질문은 특히 중요합니다. 인덱서가 실패한 상태에서 에이전트가 이전 결과를 읽는다면, 겉으로는 컴파일러 기반 탐색을 쓰는 것처럼 보여도 실제로는 오래된 근거로 수정할 수 있습니다. 인덱스의 생성 시각, 대상 브랜치, 빌드 구성, 대상 프레임워크를 결과물에 남기는 운영 규칙이 필요한 이유입니다.
코드 그래프는 AI 에이전트를 더 똑똑하게 만드는 만능 계층이 아닙니다. 대신 C# 컴파일러가 이미 알고 있는 관계를 에이전트의 작업 근거로 꺼내는 장치입니다. 팀의 다음 행동은 전체 플랫폼 계약이 아니라, 최근 실패한 영향 분석 작업 하나를 골라 컴파일러 기반 탐색이 검토 시간을 줄이는지 확인하는 작은 비교 실험이면 충분합니다.
