버그 티켓, AI에게 맡겨봤습니다 — QUBA 개발기
QA가 등록한 Jira 버그 티켓을 AI Agent가 먼저 조사하고, 원인과 수정안까지 제안한다면 어떨까요? 사이드 프로젝트로 시작한 버그 처리 자동화 Agent ‘QUBA’의 설계 과정과, 분석 품질을 좌우한 데이터 임베딩·RAG 구축, 그리고 실제 티켓으로 측정한 효과까지 공유합니다.
이학성 · 하동우 · 민경윤 · VAS개발팀
#AI Agent #LangGraph #MCP #RAG #임베딩
목차
1부 · 왜 만들었고, 어떻게 생겼나
시작은 작은 호기심이었습니다
버그 하나를 고치기까지, 시간은 어디서 새고 있을까
AI Agent가 들어갈 수 있는 네 개의 틈
다른 팀은 어떻게 하고 있을까
사례에서 찾은 세 가지 설계 원칙
왜 LangGraph였나
QUBA 아키텍처 한눈에 보기
2부 · 티켓 하나가 리포트가 되기까지
7개 노드로 흐르는 파이프라인
정보 수집 — fetch_ticket
문맥 보강 — enrich_context
분석과 검증 — synthesize
3부 · 근거는 어디서 오는가
분석 근거는 어디서 오는가
임베딩: 의미를 좌표로 바꾸는 일
임베딩 이전에 결정되는 것
청킹 실패가 임베딩 실패로 보였다
데이터 공급망을 분리하다
벡터는 어떻게 검색되는가
벡터 검색만으로 부족한 이유
후보 생성과 정밀 판정을 분리하다
점수 분포를 이해해야 confidence가 된다
벡터 위에 구조화된 연결을 더한다
4부 · 그래서 효과가 있었나
비용과 시간으로 따져보기
마치며
시작은 작은 호기심이었습니다
QUBA는 Quality Bug Assistants의 약자로, 한마디로 버그 처리 자동화 AI Agent입니다. 출발점은 단순한 질문이었습니다.
“QA 테스트 후 쌓이는 Jira 버그 티켓을 AI에게 맡기면, 버그 처리 과정도 자동화할 수 있지 않을까?”
개발자는 생각보다 많은 시간을 버그를 분석하고 수정하는 데 씁니다. 이 구간에 AI를 잘 끼워 넣으면 팀 전체의 생산성을 꽤 끌어올릴 수 있겠다는 기대로 팀 내 매니저 세 명이 사이드 프로젝트를 시작했습니다.
아직 개발 중인 프로젝트입니다
QUBA는 완성된 제품이 아니라, 실제 업무 적용을 목표로 계속 테스트하며 다듬고 있는 프로젝트입니다. 이 글은 설계와 아키텍처, 파이프라인 내부 동작, 분석 품질을 좌우한 데이터 임베딩·RAG 구축, 그리고 실제 티켓으로 측정한 효과까지를 한 번에 정리한 기록입니다.
버그 하나를 고치기까지, 시간은 어디서 새고 있을까
AI를 붙이기 전에, 먼저 지금 우리가 버그를 어떻게 처리하고 있는지부터 정리했습니다. 대부분의 팀이 비슷한 흐름일 거라 생각합니다.
신규 기능 릴리즈 전, QA팀이 집중적으로 테스트합니다.
버그가 발견되면 Jira 티켓이 등록됩니다.
개발 PM이 담당 개발자에게 티켓을 할당합니다.
개발자는 티켓의 현상을 확인하고 원인을 추적합니다.
원인을 찾으면 소스를 수정하고 테스트합니다.
Jira에 원인과 처리 결과를 코멘트로 남기면, QA가 재테스트합니다.
일반적인 버그 처리 프로세스. 4단계 ‘원인 추론’에서 개발자는 여러 시스템을 오가야 합니다.
여기서 눈여겨볼 곳은 4단계입니다. 원인을 찾는 데 필요한 정보가 한곳에 모여 있지 않거든요. 버그 유형에 따라 소스 코드, API 규격서, 서버 로그, DB 데이터, 정책 문서, 과거 처리 이력을 하나씩 찾아보며 퍼즐을 맞춰야 합니다.
코드를 고치는 시간보다, 고치기 전에 여기저기 흩어진 정보를 모으고 연결하는 시간이 더 길 때가 많습니다. 그래서 이렇게 생각했습니다. 이 정보 수집과 연결을 AI Agent가 대신하고, 원인 분석까지 거들어 준다면 어떨까?
AI Agent가 들어갈 수 있는 네 개의 틈
위 프로세스에서 반복적으로 발생하는 작업을 중심으로
아직 개발 중인 프로젝트입니다
QUBA는 완성된 제품이 아니라, 실제 업무 적용을 목표로 계속 테스트하며 다듬고 있는 프로젝트입니다. 이 글은 설계와 아키텍처, 파이프라인 내부 동작, 분석 품질을 좌우한 데이터 임베딩·RAG 구축, 그리고 실제 티켓으로 측정한 효과까지를 한 번에 정리한 기록입니다.
버그 하나를 고치기까지, 시간은 어디서 새고 있을까
AI를 붙이기 전에, 먼저 지금 우리가 버그를 어떻게 처리하고 있는지부터 정리했습니다. 대부분의 팀이 비슷한 흐름일 거라 생각합니다.
신규 기능 릴리즈 전, QA팀이 집중적으로 테스트합니다.
버그가 발견되면 Jira 티켓이 등록됩니다.
개발 PM이 담당 개발자에게 티켓을 할당합니다.
개발자는 티켓의 현상을 확인하고 원인을 추적합니다.
원인을 찾으면 소스를 수정하고 테스트합니다.
Jira에 원인과 처리 결과를 코멘트로 남기면, QA가 재테스트합니다.
일반적인 버그 처리 프로세스. 4단계 ‘원인 추론’에서 개발자는 여러 시스템을 오가야 합니다.
여기서 눈여겨볼 곳은 4단계입니다. 원인을 찾는 데 필요한 정보가 한곳에 모여 있지 않거든요. 버그 유형에 따라 소스 코드, API 규격서, 서버 로그, DB 데이터, 정책 문서, 과거 처리 이력을 하나씩 찾아보며 퍼즐을 맞춰야 합니다.
코드를 고치는 시간보다, 고치기 전에 여기저기 흩어진 정보를 모으고 연결하는 시간이 더 길 때가 많습니다. 그래서 이렇게 생각했습니다. 이 정보 수집과 연결을 AI Agent가 대신하고, 원인 분석까지 거들어 준다면 어떨까?
AI Agent가 들어갈 수 있는 네 개의 틈
위 프로세스에서 반복적으로 발생하는 작업을 중심으로