GitHub Qubot 공부 정리 | 사내 분석 에이전트를 만든다는 게 뭔지
GitHub이 Copilot 기반으로 만든 사내 데이터 분석 에이전트 Qubot 구축기를 읽고 정리했다.
GitHub 블로그에서 Qubot이라는 사내 분석 에이전트 구축기를 읽었다. Copilot을 활용해 GitHub 직원들이 자연어로 내부 데이터를 조회할 수 있게 만든 프로젝트다. 처음엔 제목만 보고 “사내 챗봇 구축기겠지” 싶었는데, 구조 설명을 읽다 보니 생각이 좀 달라졌다.
컨텍스트 계층 설계 부분이 흥미로워서 정리해봤다.
1️⃣ 이게 뭐냐?
Qubot은 GitHub이 내부적으로 만든 Copilot 기반 데이터 분석 에이전트다. “이 기능의 재방문율이 가장 높은 사용자 그룹은?” 같은 탐색적 질문을 Slack이나 VS Code에 입력하면, 내부 데이터 웨어하우스에서 쿼리를 짜고 답변을 가져온다. 기술 지식 없이도 데이터에 질문할 수 있는 인터페이스를 만든 거다.
구조는 크게 세 부분이다. 사용자가 접근하는 UI 레이어(Slack, VS Code, Copilot CLI), 데이터 맥락을 관리하는 컨텍스트 계층, 그리고 실제 쿼리를 실행하는 엔진이다. 쿼리 엔진은 Kusto와 Trino 중 상황에 맞는 걸 자동으로 선택한다. 이 선택 자체도 에이전트가 알아서 한다.
여기서 가장 인상적이었던 건 컨텍스트 계층 설계다. GitHub 데이터는 원본, 정제, 큐레이션 세 단계로 나뉘는데, 에이전트가 이 구조를 이해하고 적절한 레이어에서 맥락을 끌어와야 정확한 답변이 나온다. 팀은 이 컨텍스트를 마크다운 기반으로 정규화했다. 별도 도구 없이 누구나 마크다운 문서로 기여할 수 있게 만든 거다.
PR이 올라올 때마다 오프라인 검증을 돌려 에이전트 응답 품질이 나빠졌는지 체크하는 평가 체계도 만들었다고 한다. 기능이 바뀔 때마다 에이전트가 정확히 답하는지 자동으로 확인하는 구조다.
2️⃣ 내가 든 생각
처음엔 “그냥 자연어 SQL 생성기 아닌가”라는 생각이 들었는데, 구조를 보고 나서 조금 달라졌다. 핵심이 쿼리 생성보다 컨텍스트 관리에 있다는 인상이었다.
데이터 웨어하우스엔 수십 개의 테이블이 있고, 같은 지표도 레이어마다 다르게 저장돼 있을 수 있다. 에이전트가 이걸 제대로 이해하려면 그 구조를 설명하는 맥락이 미리 잘 정비돼 있어야 한다. 글에서도 컨텍스트 계층을 정비하고 나서 답변 품질이 눈에 띄게 달라졌다는 내용이 나온다.
👉🏻 디자이너 관점에서 보면, 이게 컴포넌트 설계 문제랑 비슷하게 느껴졌다. 좋은 컴포넌트는 사용자가 내부를 몰라도 쓸 수 있다. Qubot도 결국 데이터 구조를 모르는 직원이 데이터에 접근할 수 있게 만드는 UX 레이어처럼 보였다. Slack, VS Code, CLI 세 곳에 인터페이스가 퍼져 있다는 것도 진입 장벽을 낮추겠다는 의도처럼 읽혔다.
평가 체계 이야기도 흥미로웠다. 프론트엔드에서 스냅샷 테스트가 UI 회귀를 잡는 것처럼, 에이전트도 응답 품질을 지속적으로 체크하는 체계가 필요한 것 같았다. 에이전트를 “만드는 것”보다 “유지하는 것”이 더 복잡할 수 있겠다는 생각이 들었다.
💡 여기서 드는 질문? 마크다운 기반 컨텍스트는 누가 유지보수할까. 에이전트 성능이 이 문서 품질에 달려있다면, 유지보수 비용이 다른 형태로 남아있는 셈 아닐까 싶었다.
⭐️ 마지막으로, 개발자 도구를 공부하면서 든 생각
공부 끝에 이 한 줄이 남았다 — “에이전트 성능은 결국 컨텍스트 품질에서 나온다.” 자연어로 묻는 인터페이스보다, 그 뒤에 뭘 얼마나 잘 정리해뒀느냐가 더 중요해 보였다.