GitLab 내부의 AI 에이전트: 티켓 라이프사이클 자동화 과정에서 배운 점

인간의 통제를 제거하지 않으면서 티켓 그루밍 (Ticket Grooming), 구현 지원, 그리고 머지 리퀘스트 (Merge Request) 리뷰를 위해 AI 에이전트를 사용한 실제 사례 연구

대부분의 기업은 또 다른 챗봇을 필요로 하지 않습니다.

그들에게 필요한 것은 매일 이미 일어나고 있는 업무 과정에서의 마찰 (Friction)을 줄이는 것입니다.

소프트웨어 팀의 경우, 이러한 마찰은 외부에서 보기에는 정상적으로 보이는 곳에 숨어 있는 경우가 많습니다. 불분명한 티켓 (Ticket), 누락된 수락 기준 (Acceptance Criteria), 누군가의 머릿속에만 존재하는 구현 계획, 반복되는 리뷰 코멘트, 그리고 현실과 서서히 동떨어져 가는 문서화 등이 그것입니다.

QvAI에서 우리는 정확히 이러한 종류의 마찰을 해결하는 익명화된 GitLab 기반 AI 에이전트 시스템을 작업했습니다.

원래의 사례 연구는 QvAI 블로그에 헝가리어로 게시되었습니다. 이 기사는 더 넓은 교훈에 초점을 맞춘 영어판입니다. 즉, 우리가 무엇을 만들었는지, 왜 여러 개의 에이전트를 사용했는지, 가치가 어디에서 나타났는지, 그리고 다른 팀들이 이 패턴으로부터 무엇을 배울 수 있는지에 대한 내용입니다.

목표는 엔지니어를 대체하는 것이 아니었습니다.

목표는 엔지니어링 워크플로 (Workflow)를 더 명확하고, 빠르고, 제어하기 쉽게 만드는 것이었습니다.

진짜 병목 현상은 코딩이 아니었다

사람들이 소프트웨어 개발에서 AI에 대해 이야기할 때, 보통 코드 생성 (Code Generation)으로 바로 건너뜁니다.

그것은 일리가 있습니다. 코드는 눈에 보입니다. 코드는 데모할 수 있습니다. 코드는 측정 가능한 것처럼 느껴집니다.

하지만 많은 팀에서 더 큰 손실은 코드가 작성되기 전과 후에 발생합니다.

맥락 (Context)이 누락된 상태로 티켓이 도착합니다. 비즈니스 목표는 모호합니다. 수락 기준 (Acceptance Criteria)은 불분명합니다. 개발자는 후속 질문을 던지고, 답변을 기다리고, 가정을 세우고, 구현을 시작합니다. 그러다 나중에 리뷰 과정에서 중요한 무언가가 전혀 조율되지 않았음을 알게 됩니다.

누구도 잘못한 것이 없었습니다. 프로세스에서 단순히 컨텍스트 (Context)가 누출되었을 뿐입니다.

그것이 이번 사례의 진짜 문제였습니다.

팀은 다음 네 가지 영역에서 반복적인 마찰을 겪고 있었습니다:

1. 티켓 그루밍 (Ticket grooming)에 너무 많은 수동 읽기와 명확화 작업이 필요했습니다.
2. 구현 계획 (Implementation plans)이 충분히 명시적이지 않은 경우가 많았습니다.
3. 머지 리퀘스트 (Merge request) 리뷰 과정에서 더 일찍 명확히 할 수 있었던 문제들이 계속 발견되었습니다.
4. 티켓 상태와 문서화가 실제 작업 내용을 항상 반영하지는 않았습니다.

이러한 점들은 이 프로세스를 AI 에이전트 (AI agents)에 적합하게 만들었습니다.

AI가 마법처럼 완벽한 코드를 작성할 수 있기 때문이 아니라, 워크플로우 (Workflow) 내에 반복적인 읽기, 확인, 요약, 계획 및 리뷰 과정이 포함되어 있었기 때문입니다.

바로 이 지점에서 AI 에이전트가 진정으로 유용해질 수 있습니다.

하나의 범용 어시스턴트 대신 여러 에이전트를 사용한 이유

기업용 AI 프로젝트에서 흔히 범하는 실수는 모든 것을 수행하는 하나의 어시스턴트를 구축하려는 시도입니다.

티켓을 읽고, 코드를 작성하고, 코드를 리뷰하고, 문서를 업데이트하고, 질문에 답합니다. 이는 데모에서는 인상적이지만 프로덕션 (Production) 환경에서는 제어하기 어려운 모호한 디지털 동료가 되어버립니다.

우리는 다른 접근 방식을 취했습니다.

시스템은 각각 좁은 역할을 가진 여러 개의 특화된 에이전트 (Specialized agents)를 사용했습니다.

이 방식이 중요했던 이유는 각 에이전트를 특정 작업에 대해 평가할 수 있었기 때문입니다. 그루밍 에이전트 (Grooming agent)가 코드 리뷰어 (Code reviewer)처럼 행동할 필요는 없었습니다. 리뷰 에이전트 (Review agent)가 프로덕트 매니저 (Product manager)처럼 행동할 필요도 없었습니다. 구현 에이전트 (Implementation agent)가 비즈니스 우선순위를 결정할 필요도 없었습니다.

각 에이전트는 워크플로우 내에서 명확한 위치를 가졌습니다.

그루밍 에이전트

그루밍 에이전트는 GitLab 티켓을 읽고 누락된 정보를 찾았습니다.

불분명한 요구사항을 식별하고, 명확화를 위한 질문을 제안하며, 수락 기준 (Acceptance criteria)을 수립하는 것을 도왔습니다.

이는 기초적인 것처럼 들리지만, 팀의 리듬을 변화시킵니다.

개발자가 구현 중간에 모호함을 발견하는 대신, 팀은 더 이른 시점에 티켓에 대한 구조화된 검토를 받게 됩니다. 에이전트가 전체 작업을 해결할 필요는 없습니다. 비용이 많이 드는 엔지니어링 시간이 투입되기 전에 작업을 더 명확하게 만들기만 하면 됩니다.

이는 일반적인 AI 프로젝트에 대해서도 유용한 상기 사항입니다.

최고의 첫 번째 에이전트는 종종 가장 진보된 에이전트가 아닙니다. 나머지 프로세스의 입력 품질 (Input quality)을 개선하는 에이전트가 최고의 에이전트입니다.

구현 에이전트 (The implementation agent)

티켓이 명확해지면, 구현 에이전트 (Implementation agent)는 기술 계획을 준비하고 적절한 경우 코드 변경을 수행했습니다.

이 에이전트는 티켓, 저장소 컨텍스트 (Repository context), 댓글, 그리고 공유된 개발 가이드라인을 바탕으로 작동했습니다. 또한 리뷰 에이전트 (Review agent)나 사람 검토자 (Human reviewer)의 피드백을 바탕으로 반복 (Iterate)할 수도 있었습니다.

핵심은 개발자를 루프 (Loop)에서 제외하는 것이 아니었습니다.

핵심은 개발자에게 더 나은 시작점을 제공하는 것이었습니다.

더 간단한 작업의 경우, 에이전트가 생성한 머지 리퀘스트 (Merge request)는 사람이 검토하고 머지할 수 있을 정도로 충분히 완성도가 높았습니다. 더 복잡한 작업의 경우에도 에이전트는 여전히 빈 페이지 문제 (Blank-page problem)를 줄여주었습니다. 에이전트는 솔루션의 형태를 준비하고, 관련 파일을 찾아내며, 첫 번째 기술적 가정을 명시적으로 드러냈습니다.

최종 구현에 여전히 사람의 판단이 필요할 때조차 이는 가치가 있습니다.

AI가 시간을 절약하기 위해 반드시 작업을 끝마칠 필요는 없습니다. 때로는 숙련된 사람이 작업을 더 빨리 끝낼 수 있는 상태로 만들어 둠으로써 가치를 창출합니다.

리뷰 에이전트 (The review agent)

리뷰 에이전트 (Review agent)는 티켓 목표, 저장소 컨텍스트 (Repository context), 그리고 팀의 개발 규칙을 기준으로 머지 리퀘스트 (Merge request)를 확인했습니다.

이 에이전트는 누락된 부분, 불일치, 위험한 변경 사항, 그리고 구현 내용이 티켓의 의도와 일치하지 않는 부분을 찾아냈습니다.

이 에이전트는 머지 (Merge) 전에 특히 유용했습니다.

이 에이전트는 일반적인 리뷰 사이클 (Review cycles) 동안 놓치기 쉬운 문제들을 포착했습니다. 더 중요한 점은, 피드백을 더 일찍 확인할 수 있게 되었다는 것입니다. 구현 에이전트 (Implementation agent)가 사람이 본격적으로 시간을 투입하기 전에 작업을 다듬을 수 있었습니다.

최종 결정권은 여전히 사람이 가졌습니다.

에이전트는 단순히 리뷰 프로세스를 더 날카롭게 만들었을 뿐입니다.

가장 중요한 설계 선택: AI는 제안하고, 사람은 결정한다

가장 안전한 AI 시스템이 항상 능력이 가장 낮은 시스템인 것은 아닙니다.

가장 안전한 시스템은 경계 (Boundaries)가 가장 명확한 시스템입니다.

이 GitLab 워크플로우 (Workflow)에서 에이전트들에게 무제한의 자유가 주어지지는 않았습니다. 에이전트들은 미리 정의된 권한 (Permissions), 제어된 작업 (Controlled actions), 그리고 감사 가능한 단계 (Auditable steps) 내에서 작동했습니다.

이는 세 가지 이유로 중요했습니다.

첫째, 소스 코드, 티켓 (Tickets), 그리고 내부 문서는 민감한 기업 데이터입니다. 시스템은 필요한 컨텍스트 (Context)만을 사용해야 했습니다.

둘째, 엔지니어링 결정에는 리스크 (Risk)가 따릅니다. 시스템은 분석, 준비, 제안, 그리고 리뷰를 수행할 수 있었지만, 티켓 상태, 머지 (Merge), 그리고 우선순위에 관한 최종 결정은 엔지니어와 책임 있는 리더들의 몫으로 남겨두었습니다.

셋째, 팀에는 일관성 (Consistency)이 필요합니다. 만약 모든 개발자가 서로 다른 방식으로 각기 다른 AI 어시스턴트 (AI assistant)를 사용한다면, 조직의 행동은 분산될 것입니다. 이 설정에서 에이전트들은 공유된 가이드라인, 리뷰 기준, 그리고 품질 기대치를 따랐습니다.

이것이 모든 사람에게 챗봇 (Chatbot)을 제공하는 것과 제어된 워크플로우 (Controlled workflow)를 구축하는 것의 차이입니다.

이것이 바로 QvAI에서 비즈니스 워크플로우를 위한 AI 에이전트 (AI agents for business workflows)를 생각하는 방식이기도 합니다: 좁은 책임 범위, 유용한 컨텍스트, 측정 가능한 목표, 제어된 권한, 그리고 중요한 지점에서의 인간의 승인입니다.

개발자들에게 변화된 점

가장 큰 변화는 개발자들이 코딩을 멈춘 것이 아니었습니다.

가장 큰 변화는 그들이 제대로 준비되지 않은 작업들을 덜 다루게 되었다는 점입니다.

티켓은 더 자주 명확한 수락 기준 (Acceptance Criteria)을 갖게 되었습니다. 개발자들은 관련 기술 영역을 더 일찍 확인할 수 있었습니다. 구현 (Implementation)이 너무 진행되기 전에 리스크를 더 쉽게 포착할 수 있었습니다. 리뷰 코멘트는 기본적인 문맥 누락 대신 실제 엔지니어링 판단에 더 집중하게 되었습니다.

구현 에이전트 (Implementation Agent)와 리뷰 에이전트 (Review Agent) 또한 유용한 피드백 루프 (Feedback Loop)를 생성했습니다.

구현 에이전트가 솔루션을 제안하면, 리뷰 에이전트가 티켓 및 공유된 가이드라인과 대조하여 이를 검토했습니다. 만약 무언가 누락되었다면, 인간 리뷰어가 개입하기 전에 구현 에이전트가 작업을 개선할 수 있었습니다.

이 루프가 시스템을 완벽하게 만들지는 않았습니다.

하지만 시작점을 더 나은 상태로 만들었습니다.

그리고 실제 엔지니어링 팀에서, 더 나은 시작점은 종종 매우 큰 가치를 지닙니다.

부수적 효과: 인간이 작성하는 더 나은 티켓

가장 흥미로운 결과 중 하나는 기술적인 것이 아니었습니다.

그루밍 에이전트 (Grooming Agent)는 시간이 지남에 따라 사람들이 티켓을 작성하는 방식을 개선했습니다.

에이전트가 누락된 문맥, 모호한 수락 기준 (Acceptance Criteria), 또는 불분명한 비즈니스 목표를 지속적으로 드러냄에 따라, 티켓을 작성하는 사람들에게 피드백 루프가 형성되었습니다. 그들은 이슈가 구현 단계에 도달하기 전에 무엇이 누락되었는지 확인할 수 있었습니다.

이것은 워크플로 (Workflow) 내 AI의 과소평가된 이점입니다.

훌륭한 에이전트는 단순히 작업을 처리하는 데 그치지 않습니다. 조직의 프로세스가 어디에서 취약한지를 보여줍니다.

이 사례의 경우, 더 나은 그루밍 (Grooming)이 더 나은 티켓으로 이어졌습니다. 더 나은 티켓은 더 원활한 구현으로 이어졌습니다. 원활한 구현은 더 집중된 리뷰로 이어졌습니다.

에이전트는 작업자로서 유용했을 뿐만 아니라, 거울로서의 역할도 수행했습니다.

이 패턴이 GitLab에만 국한되지 않는 이유

이번 사례에서는 GitLab이 환경이었지만, 이 패턴은 훨씬 더 광범위합니다.

동일한 구조를 많은 비즈니스 프로세스에 적용할 수 있습니다:

요청이 시스템에 들어옵니다.

에이전트가 가용한 문맥을 읽습니다.

내부 규칙에 따라 요청을 검토합니다.

누락된 정보를 요청하거나 다음 단계를 준비합니다.

다른 에이전트 또는 인간이 출력을 검토합니다.

리스크 관리가 필요한 경우 사람이 최종 결정을 승인합니다.

소프트웨어 개발에서 대상(objects)은 티켓(tickets), 머지 리퀘스트(merge requests), 저장소 파일(repository files), 그리고 리뷰 코멘트(review comments)입니다.

금융 분야에서는 인보이스(invoices), 구매 주문서(purchase orders), 예산 규칙(budget rules), 그리고 승인 워크플로우(approval workflows)가 될 수 있습니다.

영업 분야에서는 리드(leads), CRM 기록(CRM records), 제안서(proposals), 그리고 후속 작업(follow-up tasks)이 될 수 있습니다.

인사(HR) 분야에서는 지원서(applications), 내부 정책(internal policies), 인터뷰 노트(interview notes), 그리고 온보딩 체크리스트(onboarding checklists)가 될 수 있습니다.

운영(operations) 분야에서는 지원 티켓(support tickets), 벤더 이메일(vendor emails), 보고서(reports), 그리고 예외 처리(exception handling)가 될 수 있습니다.

이것이 바로 AI 자동화가 모델 데모(model demo)가 아닌 실제 프로세스(real process)에서 시작되어야 하는 이유입니다.

질문은 "여기에 AI를 추가할 수 있을까?"가 되어서는 안 됩니다.

더 나은 질문은 "동일한 종류의 읽기, 확인, 요약 또는 준비 작업이 반복적으로 발생하는 곳은 어디인가?"가 되어야 합니다.

그곳이 바로 비즈니스 프로세스를 위한 AI 자동화(AI automation for business processes)가 실용적으로 적용될 수 있는 지점입니다.

시스템을 작동하게 만든 요소

돌이켜보면, 시스템이 작동할 수 있었던 것은 몇 가지 실질적인 선택 덕분이었습니다.

에이전트들은 좁은 역할(narrow roles)을 가졌습니다. 그루밍(Grooming), 구현(implementation), 그리고 리뷰(review)는 각각 별개의 책임이었습니다.

그들은 기존 워크플로우(workflow) 내부에서 작동했습니다. 팀은 모든 작업을 별도의 채팅 인터페이스로 옮길 필요가 없었습니다.

그들은 실제 컨텍스트(real context)를 사용했습니다. 티켓, 코멘트, 머지 리퀘스트, 저장소 데이터, 그리고 개발 가이드라인이 모두 중요했습니다.

그들은 제어된 권한(controlled permissions)을 가졌습니다. 시스템은 감사 가능성(auditability)과 인간의 결정 지점(human decision points)을 중심으로 설계되었습니다.

그들은 유용한 중간 작업물(intermediate work)을 생성했습니다. AI가 작업을 완료하지 못했을 때조차, 인간의 단계를 더 빠르고 명확하게 만들 수 있을 만큼 충분한 작업을 준비해 두는 경우가 많았습니다.

마지막 포인트가 중요합니다.

AI 프로젝트는 종종 완전한 자동화(full automation)만이 유일한 성공적인 결과인 것처럼 판단되곤 합니다. 실제 팀에서는 적절한 마찰(friction)을 제거할 수 있다면 부분적인 자동화(partial automation)만으로도 여전히 매우 높은 가치를 가질 수 있습니다.

80%가 준비된 티켓은 완료된 작업은 아닙니다.

하지만 개발자가 의도를 처음부터 다시 재구성해야 하는 모호한 티켓보다는 훨씬 낫습니다.

AI 에이전트를 고려하는 팀을 위한 교훈

만약 회사에서 AI 에이전트 (AI agents) 도입을 고려하고 있다면, 처음부터 자율적인 시스템 (autonomous system)을 요구하며 시작하지 마십시오.

사람들이 이미 정보를 읽고, 확인하고, 요약하고, 준비하거나, 시스템 간에 이동시키는 데 시간을 소비하고 있는 반복적인 워크플로우 (workflow)를 찾는 것부터 시작하십시오.

그런 다음 다음과 같이 질문하십시오:

맥락 (context)이 부족하여 업무가 정체되는 곳은 어디인가?

사람들이 똑같은 확인 질문을 반복해서 던지는 곳은 어디인가?

검토자 (reviewers)들이 항상 동일한 유형의 문제를 발견하는 곳은 어디인가?

어떤 결정이 반드시 인간의 몫으로 남아야 하는가?

어떤 단계가 에이전트에 의해 안전하게 준비될 수 있는가?

이러한 프레이밍 (framing)은 "봇을 만들자"라고 접근하는 것보다 더 나은 AI 시스템으로 이어집니다.

특히 내부 데이터, 권한, 비즈니스 규칙 (business rules)이 중요한 맞춤형 워크플로우 (custom workflows)의 경우, 일반적인 SaaS 도구만으로는 충분하지 않은 경우가 많습니다. 바로 이 지점에서 맞춤형 AI 개발 (custom AI development)이 의미를 가질 수 있습니다.

모든 회사가 복잡한 무언가를 필요로 하기 때문이 아닙니다.

AI가 프로세스에 맞춰져야 하며, 그 반대가 되어서는 안 되기 때문입니다.

마지막 생각

최고의 AI 에이전트 프로젝트가 항상 가장 극적인 것은 아닙니다.