그 그래프는 누가 만들어요? AI 에이전트의 컨텍스트를 그래프로 관리한다는 것

공공기관에서 데모를 하던 중이었다. AI 가 이슈를 읽고 수정 제안을 붙이는 걸 보던 분이 물었다. "수정하려는 소스 외에 연결된 소스도 봐야 하는 거 아닌가요?" 맞다. 그래서 그래프를 보고 찾아간다고 답했더니 바로 다음 질문이 나왔다.

"그 그래프는 누가 만드나요?"

아무도 안 만든다. 이 답을 하는 순간 미팅의 공기가 바뀌는 걸 여러 번 봤다. 이 글은 그 짧은 답 뒤에 있는 구조를 설명하는 글이다.

AI 에게 컨텍스트를 준다는 건 무슨 뜻인가

AI 에이전트에게 컨텍스트를 준다는 건, 사람 시니어 개발자가 머릿속에 들고 다니는 맥락을 기계가 조회할 수 있는 형태로 만들어 준다는 뜻이다. 이 코드가 왜 이렇게 생겼는지 적힌 이슈, 지난번 비슷한 변경이 낸 장애, 이 모듈을 참조하는 다른 소스. 에이전트의 출력 품질은 모델 성능 곱하기 컨텍스트 품질인데, 앞의 항은 모델 회사들이 올려 주니까 조직이 개입할 수 있는 건 사실상 뒤의 항뿐이다.

문제는 대부분의 조직에서 이 맥락이 사람 머릿속과 여러 도구에 흩어져 있다는 것. 그래서 "AI 도입"의 첫 단계가 모델 선택이 아니라 컨텍스트 정리가 된다.

왜 벡터 검색만으로는 부족한가

벡터 검색(RAG)만으로 부족한 이유는, 검색이 찾아 주는 건 비슷한 문서지 연결된 사실이 아니기 때문이다.

"결제 모듈 타임아웃"으로 검색하면 타임아웃을 언급한 문서 조각들이 나온다. 유용하다. 그런데 에이전트가 정말 필요한 건 이런 경로다. 이 이슈에 연결된 커밋 → 그 커밋이 건드린 모듈 → 그 모듈을 참조하는 다른 소스 → 그 소스에 얽힌 과거 장애. 이건 유사도가 아니라 관계다. 임베딩 공간에서 아무리 가까워도 "이 커밋이 저 이슈 때문에 생겼다"는 사실은 나오지 않는다. 그 사실은 데이터에 관계로 존재하거나, 존재하지 않거나 둘 중 하나다.

그래서 우리는 2차원 테이블을 검색하는 구조가 아니라 그래프를 따라가는 구조를 택했다. 이슈, 문서, 코드, 빌드, 배포가 전부 고유 ID 를 갖고 서로를 참조한다. 문서는 옵시디언처럼 서로 링크되고 그래프 뷰로 열린다. 온톨로지라는 오래된 단어가 요즘 다시 나오는 이유가 이거다. 지식을 개체와 관계로 표현해 두면, 그 위에서 추론하는 건 사람이든 AI 든 같은 방식으로 할 수 있다.

그래서, 그 그래프는 누가 만드나

그래프는 아무도 만들지 않는다. 일하는 과정에서 자동으로 생긴다.

이슈에서 브랜치를 만들면 간선이 하나 생긴다. 커밋이 변경요청에 붙으면 또 하나. 파이프라인이 그 변경요청을 빌드하면 또 하나. 배포가 나가면 또 하나. 어느 것도 "그래프를 만드는 작업"이 아니다. 전부 원래 하던 일이다. 다만 그 일들이 같은 평면에서 일어나기 때문에 부산물로 관계가 남는 것뿐이다.

반대로 도구가 파편화된 환경에서 이 그래프를 만들려면 어떻게 해야 하나. 이슈 트래커, 저장소, CI, 위키의 API 토큰을 각각 발급받고, 서로 다른 응답 스키마를 이어 붙이는 접착 코드를 짜고, 커밋 메시지의 문자열을 파싱해서 관계를 추측해야 한다. 해 봤다. 되긴 된다. 그런데 토큰 관리부터 스키마 드리프트까지 전부가 운영 부담이고, 그렇게 만든 관계는 추측이라서 조용히 틀린다. 우리가 깃허브, 깃랩 연동을 실제로 제공하면서도 이 방식의 한계를 계속 말하고 다니는 이유다.

에이전트는 그래프를 어떻게 쓰나

에이전트는 그래프 위에서 필요한 맥락만 뽑아 간다. 전체를 다 읽는 게 아니다.

이슈 하나를 받으면 그 이슈를 중심으로 몇 홉을 걸어 본다. 연결된 커밋, 관련 문서, 과거의 비슷한 이슈. 거기서 나온 것들만 컨텍스트 윈도로 가져간다. 이게 중요한 이유는 두 가지다. 하나는 정확도. 관련 없는 것을 읽지 않은 에이전트가 더 정확하다. 다른 하나는 비용. 폐쇄망에서 오픈소스 LLM 을 돌리는 조직이라면 컨텍스트 윈도가 곧 GPU 비용이라서, 필요한 맥락만 골라 주는 인프라가 모델 성능만큼 결과에 영향을 준다.

실제로 우리 내부에서 돌아가는 사례를 그대로 말하면 이렇다. 파이프라인이 깨지면 에이전트가 에러 메시지를 중계하는 게 아니라 그래프를 타고 원인 후보를 좁혀서 진단을 붙인다. 이슈에서 소규모 변경요청을 만들 때는 연결된 소스를 보고 수정안을 제안한다. 둘 다 화려한 기능이 아니라, 필요한 맥락이 조회 가능한 형태로 있으니까 되는 일이다.

지식그래프 없이 AI 도입하면 어떻게 되나

지식그래프 없이 AI 를 도입하면, 에이전트가 매번 백지에서 시작한다. 조직에 10년 치 히스토리가 있어도 에이전트에게는 없는 것과 같다. 그때 나오는 결과물이 "그럴듯한데 우리 상황을 모르는" 코드다. 리뷰어가 걸러내는 데 드는 시간이 에이전트가 아낀 시간을 잠식하고, 몇 달 뒤에 "AI 는 우리랑 안 맞더라"는 결론이 난다. 모델 잘못이 아니다. 맥락을 못 준 것이다.

컨텍스트를 하나의 평면에 모으는 일은 AI 이전에도 가치가 있었다. 통합 플랫폼 이야기를 우리가 몇 년째 하는 이유다. 다만 AI 가 붙는 순간 이 가치의 성격이 바뀐다. 사람에게 좋은 것에서, 에이전트가 일을 하기 위한 전제 조건으로. AI 도입을 검토하면서 모델 벤치마크부터 보고 있다면 순서를 바꿔 보시라. 에이전트가 딛고 설 컨텍스트가 조회 가능한 형태로 있는지가 먼저다.