코딩 에이전트를 도입한 팀이 가장 먼저 부딪히는 불만은 대개 비슷하다. 에이전트가 같은 유형의 실수를 반복하고, 수정 후에도 다른 곳이 무너진다. 팀은 모델을 교체하거나 프롬프트를 정교하게 다듬는 방향으로 움직이지만, 그래도 재작업(rework) 비율이 줄지 않는다.
이 현상을 모델 성능 문제로 보면 해결책이 빗나간다. 에이전트가 잘못된 코드를 생성하는 주된 이유 중 하나는 모델이 코드베이스 전체를 충분히 이해하지 못한 채 판단을 내리기 때문이다. 특정 함수의 시그니처, 모듈 간 의존 관계, 타입 제약처럼 코드에 내재된 구조적 사실이 에이전트의 컨텍스트 창 안에 정확하게 들어오지 않으면, 모델 자체가 아무리 좋아도 틀릴 수밖에 없다.
이 글은 그 전제를 받아들인 팀이 다음으로 해야 하는 선택, 즉 요구사항 단계에서 코드 컨텍스트 공급 방식을 어떻게 결정하느냐에 집중한다.
코드 컨텍스트 공급 방식이 왜 요구사항 단계의 결정인가
에이전트 도입 프로젝트에서 컨텍스트 공급 방식은 흔히 구현 세부 사항으로 취급된다. 나중에 RAG를 붙이거나 벡터 DB를 얹으면 된다는 식이다. 그런데 이 결정을 늦게 내리면 치러야 할 대가가 생각보다 크다.
코드 컨텍스트를 어떻게 표현하고 검색할 것인지에 따라, 에이전트가 실행할 수 있는 작업의 정확도 상한이 달라진다. 컨텍스트 공급 방식이 에이전트 루프의 입력 품질을 결정하고, 입력 품질이 출력 신뢰도를 결정한다. 이 사슬은 구현 단계에서 바꾸기 어렵다. 벡터 검색 기반으로 파이프라인을 구성한 뒤에 구조 기반 지식 그래프로 전환하려면 인덱싱 방식, 쿼리 설계, 에이전트 도구 인터페이스를 함께 바꿔야 한다.
따라서 이 질문은 요구사항 단계에서 명시적으로 다뤄야 한다.
두 접근의 실질적 차이
RAG·벡터 검색 기반 접근은 코드를 텍스트 청크로 쪼개 임베딩 벡터로 변환한 뒤, 질의와 의미적으로 유사한 청크를 검색해 에이전트에 넘긴다. 구축 비용이 낮고, 자연어 형태의 코드 관련 질문에 비교적 잘 반응한다. 이미 RAG 파이프라인을 운영하는 팀이라면 동일한 인프라를 재사용할 수 있다.
한계는 구조적 정확성에 있다. 함수가 어떤 타입을 받고, 어떤 모듈이 그 함수를 호출하며, 호출 체인이 어디까지 이어지는지 같은 질문에 벡터 검색은 확률적으로 관련 있는 청크를 돌려준다. 에이전트가 이 청크로 코드를 수정하면, 청크에 담기지 않은 의존 관계를 모르는 상태에서 판단을 내리게 된다.
형식 검증(formal methods) 기반 지식 그래프는 코드베이스를 파싱해 함수, 클래스, 모듈, 타입, 의존성을 명시적인 노드와 엣지로 표현한다. 에이전트가 특정 함수에 대한 정보를 요청하면, 의미적 유사성이 아니라 코드 구조에서 확인된 사실을 반환한다. 이 방식이 약속하는 것은 '관련 있을 가능성이 높은 내용'이 아니라, 코드에서 파싱 시점에 검증된 정보다.
대신 초기 구축 비용이 RAG보다 높다. 언어별 파서와 그래프 스키마를 갖춰야 하고, 코드베이스가 바뀔 때마다 그래프를 갱신하는 파이프라인도 필요하다. 지원 언어 범위도 벡터 검색보다 좁을 수 있다.
어떤 팀에 무엇이 맞는가
두 접근 중 하나가 무조건 낫다는 주장은 설득력이 낮다. 팀의 상황에 따라 합리적인 선택이 달라진다.
RAG·벡터 검색이 더 나은 출발점인 상황:
- 코드베이스 규모가 작고, 에이전트 작업이 코드 이해보다 생성 비중이 높을 때
- 실험 단계여서 인덱싱 파이프라인에 투자할 여력이 아직 없을 때
- 자연어 문서, 커밋 메시지, 이슈 내용 등 비구조 텍스트를 함께 검색해야 할 때
- 에이전트가 특정 패턴이나 예시를 찾는 수준의 작업을 주로 수행할 때
형식 검증 기반 지식 그래프가 더 적합한 상황:
- 코드베이스가 수십만 줄 이상이고, 파일 간 의존 관계가 복잡할 때
- 에이전트가 리팩터링, API 변경 영향 분석, 타입 오류 수정처럼 구조적 정확성이 요구되는 작업을 담당할 때
- 재작업 비용이 크거나, 에이전트 출력의 정확도가 팀 생산성에 직접 영향을 줄 때
- 토큰 비용을 줄이는 것이 우선순위 중 하나일 때. 정확한 컨텍스트를 작게 넘기면, 불필요한 청크를 대량으로 주입하는 것보다 토큰 소모가 적을 수 있다
이 두 기준이 섞여 있는 팀도 많다. 그 경우에는 어느 작업 유형의 재작업이 더 자주, 더 비싸게 발생하는지를 먼저 측정하고 판단하는 것이 합리적이다.
요구사항 단계에서 확인해야 할 것들
형식 검증 기반 지식 그래프 투자를 검토할 때 요구사항 문서에 포함되어야 하는 질문들이 있다.
첫째, 에이전트가 수행할 작업 중 코드 구조에 대한 정확한 이해가 없으면 실패하는 비율이 얼마나 되는가. 이 비율이 높을수록 벡터 검색의 한계가 더 빨리 드러난다.
둘째, 코드베이스가 지속적으로 변경되는 환경인가. 지식 그래프는 코드베이스 변경 시 재생성이 필요하다. 하루에도 수십 번 코드가 바뀌는 팀이라면 그래프 갱신 주기와 신선도를 어떻게 관리할지 미리 설계해야 한다.
셋째, 팀이 사용하는 언어와 프레임워크가 대상 도구의 파서 지원 범위 안에 있는가. 형식 검증 기반 파싱은 언어 문법에 의존하므로, 지원 언어 목록과 성숙도를 미리 확인해야 한다.
넷째, 도구가 에이전트 프레임워크와 어떻게 통합되는가. 지식 그래프가 에이전트의 도구 호출 인터페이스로 노출되지 않으면, 그래프를 만들어도 에이전트가 실제로 활용하지 못한다.
비용 대비 정확성, 어디서 계산이 맞는가
지식 그래프 구축에는 초기 비용이 든다. 구축 이후에도 그래프 갱신과 운영을 위한 파이프라인 유지 비용이 지속적으로 발생한다. 반면 RAG는 구축이 빠르고, 범용 클라우드 서비스로 운영할 수 있다.
이 비교가 지식 그래프에 유리하게 전환되는 지점은, 에이전트 재작업 비용이 누적되어 구축 비용을 넘어서는 시점이다. 재작업 비용은 개발자 시간으로 환산된다. 에이전트가 틀린 코드를 생성하고, 개발자가 그것을 디버깅하고, 다시 테스트하는 루프가 얼마나 자주 돌아가는가가 핵심 변수다.
현재 이 손익 분기점을 정확히 계산한 공개 벤치마크는 충분하지 않다. 팀의 코드베이스 특성, 에이전트 작업 유형, 개발자 비용에 따라 이 시점이 크게 달라지기 때문에, 일반화된 수치를 신뢰하기보다 자체 파일럿으로 검증하는 것이 더 안전한 판단이다.
파일럿 설계 방향 하나를 제안한다면, 동일한 작업 세트를 RAG 기반 에이전트와 지식 그래프 기반 에이전트에 각각 실행하고, 에이전트 출력을 사람이 수정하는 데 걸리는 시간을 측정하는 것이다. 이 측정이 있어야 비용 대비 정확성 개선이 팀의 맥락에서 실제로 성립하는지 판단할 수 있다.
요구사항 문서에 '코딩 에이전트 도입'이라고 적혀 있다면, 그 옆에 '컨텍스트 공급 방식 결정'도 함께 써야 한다. 그 결정을 구현 단계로 미루면, 나중에 훨씬 비싼 비용으로 돌아올 가능성이 높다.
