AI 에이전트를 사용하여 몇 분 만에 JIRA 버그를 자동 할당하고 해결하기

에이전틱 엔지니어링 (Agentic Engineering)은 단순히 유행어(buzzword)로 머무는 것이 아니라, 실제 엔지니어링 시간을 낭비하는 고통스럽고 지루한 문제들을 해결하기 시작할 때 진정으로 흥미로워집니다.

가장 심각한 문제 중 하나는 버그 분류 (bug triage)입니다.

Jira에 버그가 생성됩니다. 아직 아무도 담당자가 없습니다. 아무에게도 알림이 가지 않습니다. 중요한 무언가가 고장 난 상태로 버그는 방치되고, 고객 지원 팀은 관련 문의를 받기 시작하며, 엔지니어링 팀은 소음이 충분히 커진 후에야 비로소 이를 인지합니다. 이것은 단순히 도구의 문제만이 아닙니다. 이는 소유권 (ownership)과 컨텍스트 (context)의 문제입니다.

이것이 바로 에이전틱 엔지니어링 (Agentic Engineering)이 빛을 발하는 지점입니다.

모든 새로운 버그를 사람이 직접 검사하고, 어떤 서비스에 속하는지 추측하고, 담당 팀을 찾아 티켓을 업데이트한 다음, 적절한 사람들에게 알림을 보내도록 요청하는 대신, 이미 나의 엔지니어링 카탈로그 (engineering catalog)를 이해하고 있는 AI 에이전트에게 그 작업을 맡길 수 있습니다. 그 결과 더 빠른 라우팅 (routing), 더 적은 미할당 티켓, 그리고 훨씬 적은 수동 오버헤드 (manual overhead)를 얻을 수 있습니다.

이 설정에서는 새로 생성된 Jira 버그가 자동으로 분석되어 가장 가능성 높은 서비스와 매칭되고, 적절한 팀에 연결되며, Jira 내에서 업데이트됩니다. 만약 신뢰도 (confidence)가 낮다면, 사람의 검토를 위해 Slack으로 에스컬레이션 (escalated)됩니다. 이것이 실용적인 에이전틱 엔지니어링 (Agentic Engineering)입니다. 단순히 화려함을 위한 것이 아니라, 유용합니다.

미할당 버그의 진짜 문제

대부분의 팀이 버그를 무시하는 이유는 부주의해서가 아닙니다. 프로세스가 확장성 (scale)을 갖추지 못했기 때문입니다.

버그가 Jira에 들어오면 소유권이 없는 경우가 많습니다. 누군가는 제목과 설명을 수동으로 검사하고, 시스템의 어느 부분이 영향을 받는지 이해하며, 이를 서비스에 매핑하고, 다시 그 서비스를 팀에 매핑해야 합니다. 규모가 작은 팀에서는 이것이 짜증 나는 일이지만, 규모가 커지면 병목 현상 (bottleneck)이 됩니다.

그 비용은 단순히 지저분한 백로그 (backlog) 그 이상의 문제입니다.

버그가 너무 오랫동안 할당되지 않은 채로 방치됩니다.
고객 접점 이슈가 적절한 팀에 도달하는 데 더 오랜 시간이 걸립니다.
지원 채널 (support channels)이 비공식적인 알림 시스템이 되어버립니다.
엔지니어링 매니저들이 문제를 해결하는 대신 소유권 (ownership)을 추적하는 데 시간을 허비합니다.
컨텍스트 (context)가 Jira, Slack, 리포지토리 (repos), 서비스 카탈로그 (service catalogs) 전반에 흩어집니다.

더 빠른 장애 대응 (incident response)과 깔끔한 실행을 원한다면, 버그가 컨텍스트와 소유권을 포함한 상태로 전달되어야 합니다. 이것이 이 워크플로에서 말하는 에이전틱 엔지니어링 (Agentic Engineering)의 약속입니다.

이 에이전틱 엔지니어링 워크플로가 하는 일

이 워크플로는 전체 프로세스 중 유일한 수동 단계, 즉 누군가가 Jira에 버그를 생성하는 것에서 시작합니다.

그 이후에는 자동화가 주도권을 잡습니다.

버그는 제 엔지니어링 시스템의 컨텍스트 레이어 (context layer) 역할을 하는 Port로 동기화됩니다. 그러면 AI 에이전트가 이슈를 살펴보고, 소프트웨어 카탈로그 (software catalog)를 쿼리하며, 서비스, 리포지토리, 사용자, 팀 및 관련 엔티티 (entities)를 확인하여 누가 해당 문제의 소유자일 가능성이 가장 높은지 결정합니다.

그 지점부터 워크플로는 세 가지 결과로 분기됩니다:

1. Port의 엔티티 업데이트
에이전트의 확신이 충분하다면, 이슈를 발견된 서비스 및 소유 팀에 연결합니다.

2. Jira 티켓 업데이트
이유를 설명하는 댓글을 추가하고, 소유권이 성공적으로 해결되었는지 여부를 나타내는 라벨 (label)을 적용합니다.

3. 확신도가 낮을 때 Slack 알림 전송
매칭 결과가 불확실하면, 사람이 최종 결정을 내릴 수 있도록 버그를 트리아지 채널 (triage channel)로 보냅니다.

이것은 매우 견고한 에이전틱 엔지니어링 패턴입니다. 에이전트가 맹목적으로 행동하는 것이 아니라, 컨텍스트를 바탕으로 작동하며 결정을 내리고, 확신도가 임계값 (threshold) 아래로 떨어지면 우아하게 사람에게 권한을 넘기기 때문입니다.

컨텍스트 레이어가 중요한 이유

이 부분은 과소평가하기 쉽습니다.

AI 에이전트는 적절한 컨텍스트 (Context)를 가질 때에만 유용합니다. 만약 제 에이전트가 어떤 서비스가 존재하는지, 어떤 리포지토리 (Repository)가 해당 서비스와 매핑되는지, 어떤 팀이 이를 소유하고 있는지, 또는 Jira 이슈가 해당 모델과 어떻게 연관되는지를 알지 못한다면, 그것은 그저 추측하는 것에 불과합니다.

이것이 바로 이 워크플로 (Workflow)에서 Port를 컨텍스트 레이어 (Context layer)로 사용하는 이유입니다. 카탈로그 (Catalog)가 에이전트를 위한 이해의 시스템이 됩니다.

실질적인 관점에서, 에이전트는 다음과 같은 정보를 검사할 수 있습니다:

서비스 (Services)
리포지토리 (Repositories)
팀 (Teams)
사용자 (Users)
Jira 이슈 (Jira issues)
위 모든 항목 간의 관계 (Relationships)

이 지점에서 에이전틱 엔지니어링 (Agentic Engineering)은 단순한 자동화 그 이상이 됩니다. 에이전트는 단순히 이벤트에 반응하는 것이 아니라, 구조화된 엔지니어링 컨텍스트 (Engineering context)를 바탕으로 추론합니다.

버그의 제목이 알려진 서비스를 명확하게 가리킬 때, 소유권은 몇 초 만에 해결될 수 있습니다. 제목이 모호하고 신호가 약할 때, 동일한 시스템은 확실한 척하는 것을 피할 수 있을 만큼 충분한 정보를 알고 있습니다. 이것이 바로 이러한 워크플로가 작동해야 하는 방식입니다.

기초 설정 방법

이것이 작동하게 하려면 몇 가지 빌딩 블록 (Building blocks)을 갖추어야 합니다.

1. 데이터 모델 생성

설정은 Port의 블루프린트 (Blueprint)에서 시작됩니다. 여기서 사용되는 주요 블루프린트는 다음과 같습니다:

Jira 사용자 블루프린트 (Jira user blueprint)
Jira 프로젝트 블루프린트 (Jira project blueprint)
Jira 이슈 블루프린트 (Jira issue blueprint)

이 블루프린트들은 워크플로가 의존하게 될 엔티티 (Entities)의 구조를 정의합니다. 블루프린트가 생성되면, 올바른 이슈 데이터가 유용한 형태로 Port에 동기화될 수 있도록 Jira 통합 매핑 (Jira integration mapping)을 업데이트해야 합니다.

2. Jira 연결

거기서 생성된 버그가 Port로 자동 동기화될 수 있도록 Jira를 데이터 소스 (Data source)로 연결해야 합니다. 연결되면 새로운 이슈가 카탈로그 내에 나타나며 자동화 (Automations)를 트리거할 수 있습니다.

그러한 동기화 없이는 나머지 흐름이 결코 시작되지 않습니다.

3. 외부 도구 구성 (Configure external tools)

AI 에이전트가 소유권을 확신할 수 없을 때를 대비한 폴백 알림 (fallback alerts) 용도로 Slack이 사용됩니다. 즉, Slack 앱과 봇 토큰 (bot token)이 시크릿 (secret)으로 준비되어 있어야 합니다.

댓글과 라벨 (labels)을 티켓에 다시 작성할 수 있도록 Jira API 액세스도 구성해야 합니다. 이러한 자격 증명 (credentials)은 Port의 시크릿 (secrets)으로 저장됩니다.

4. 셀프 서비스 액션 생성 (Create self service actions)

워크플로 (workflow)는 백그라운드에서 다음과 같은 여러 액션 (actions)을 사용합니다:

발견된 서비스 및 팀에 이슈 (issue) 연결
Jira 댓글 추가
Jira 라벨 추가
Slack 알림 전송

이러한 액션들은 AI 에이전트와 자동화 (automation)가 결정을 내린 후 호출할 수 있는 것들입니다.

5. AI 에이전트 생성 (Create the AI agent)

실제 에이전트는 서비스 및 팀의 자동 발견 (auto discovery)을 담당합니다. 에이전트는 모델 컨텍스트 프로토콜 (Model Context Protocol) 도구를 사용하여 카탈로그를 쿼리하고 액션을 실행합니다.

이는 에이전트가 단순한 분류 (classification) 이상의 일을 수행하기 때문에 에이전틱 엔지니어링 (Agentic Engineering)의 훌륭한 사례입니다. 에이전트는 컨텍스트 (context)를 가져오고, 신뢰도 (confidence)를 평가하며, 올바른 운영 경로를 선택합니다.

6. 자동화 생성 (Create the automation)

마지막으로, Jira 버그가 생성될 때 실행되는 자동화를 생성합니다. 이 자동화는 동기화 직후 워크플로가 즉시 시작될 수 있도록 이슈를 AI 에이전트로 전달합니다.

실제 사례로 보는 훌륭한 에이전틱 엔지니어링 (What good Agentic Engineering looks like in practice)

많은 AI 워크플로가 인상적으로 들리지만, 한 가지 질문을 던지면 이야기가 달라집니다: 시스템이 불확실할 때는 어떻게 될까요?

이 설정이 강력한 이유가 바로 여기에 있습니다.

AI 에이전트는 70%의 신뢰도 임계값 (confidence threshold)을 사용합니다.

신뢰도가 70% 이상이면, 이슈가 올바른 서비스 및 팀에 연결되고, Jira 티켓이 업데이트되며, 라벨을 통해 AI가 소유권을 해결했음을 나타냅니다.
신뢰도가 70% 미만이면, 이슈는 소유권 확인이 필요한 상태로 표시되고 Slack 분류 (triage) 알림이 전송됩니다.

이것이 바로 합리적인 운영 설계 (operational design)입니다.

훌륭한 에이전틱 엔지니어링은 모든 결정에 AI를 강제로 밀어넣는 것이 아닙니다. 컨텍스트가 확실한 곳에서는 에이전트가 행동하게 하고, 모호함이 남아 있는 곳에서는 제어권을 다시 인간에게 돌려주는 것입니다.

예시 1: 명확한 버그가 자동으로 할당되는 경우

워크플로우를 테스트하기 위해, 제목이 알려진 서비스(service)를 명확하게 가리키는 버그를 생성합니다. 해당 이슈는 결제(checkout) 페이지에서 배송(shipment) 서비스가 중단된다는 내용을 담고 있습니다.

이는 에이전트에게 강력한 신호(signal)를 제공합니다.

이슈가 Port로 동기화되면 자동화가 실행되며, 순식간에 버그에 소유권 데이터(ownership data)가 보강됩니다. 워크플로우는 해당 이슈를 배송 서비스와 연결하고, 플랫폼 팀을 소유자로 식별하며, 그 근거를 Jira에 댓글로 남기고, AI가 할당했음을 나타내는 레이블(label)을 적용합니다.

여기서 추론(reasoning) 과정이 중요합니다. 시스템은 단순히 "나를 믿으세요"라고 말하지 않습니다. 왜 매칭이 이루어졌는지 설명합니다. 이 경우, 이슈 제목이 카탈로그에 있는 배송 서비스와 매우 유사하며, 해당 서비스에는 이미 명시적인 소유 팀이 정의되어 있습니다.

이러한 종류의 설명 가능성(explainability)은 자동화된 분류(triage)를 더 신뢰할 수 있게 하고 감사(audit)하기 쉽게 만들기 때문에 가치가 있습니다.

또한, 발생하지 않은 일에도 주목하십시오.

신뢰도(confidence)가 충분히 높았기 때문에 Slack 알림은 전송되지 않았습니다. 이를 통해 분류(triage) 채널을 깨끗하게 유지하고, 정말로 모호한 사례들을 위해서만 채널을 비워둘 수 있습니다.

예시 2: 모호한 버그가 인간의 검토를 위해 에스컬레이션되는 경우

다음으로, 더 일반적인 이슈를 테스트합니다. 버그 제목은 단순히 결제 페이지가 충돌하고 있다고 되어 있습니다.

이제 신호(signal)가 약해졌습니다.

제목이 특정 서비스와 명확하게 매핑되지 않습니다. AI 에이전트는 여전히 이를 분석하지만, 이번에는 충분한 신뢰도로 소유권을 결정할 수 없습니다. 따라서 불확실한 할당을 하는 대신, 다음 두 가지 작업을 수행합니다.

티켓에 소유권 확인이 필요하다는 레이블을 지정합니다.
분류(triage) 채널로 Slack 알림을 보냅니다.

Jira 댓글은 해당 이슈가 자동 할당을 위해 분석되었으나, 확신할 수 있는 서비스나 팀을 식별할 수 없었음을 설명합니다. Slack 메시지 역시 동일한 결과를 전달하며, 이슈 제목, 유형 (type), 상태 (status), 우선순위 (priority), 그리고 신뢰도 점수 (confidence score)와 같은 유용한 메타데이터를 함께 포함합니다.

이것이 바로 제가 에이전트 기반 엔지니어링 (Agentic Engineering)으로부터 기대하는 폴백 (fallback) 방식입니다. 시스템은 첫 번째 단계 (first pass)를 즉시 수행함으로써 도움을 주지만, 아는 척하며 허세를 부리지는 않습니다. 불확실한 상황을 깔끔하게 에스컬레이션 (escalate) 합니다.

운영상의 이점은 보기보다 더 큽니다

언뜻 보기에는 단순히 버그 할당을 자동화하는 좁은 범위의 작업처럼 보일 수 있습니다. 하지만 실제로는 그보다 훨씬 더 중요합니다.

이러한 에이전트 기반 엔지니어링 (Agentic Engineering) 워크플로우를 구축하고 나면, 다음과 같은 몇 가지 복합적인 이점을 얻을 수 있습니다.

더 빠른 응답 시간

이슈가 훨씬 더 빨리 적절한 팀에 도달합니다. 소유권이 불분명한 경우에도 버그가 방치되는 대신 분류 (triage) 경로가 즉시 작동합니다.

수동 분류 작업의 감소

엔지니어링 리드와 지원 팀은 티켓을 일일이 관리하는 데 쓰는 시간을 줄이고, 문제를 해결하는 데 더 많은 시간을 할애할 수 있습니다.

더 깔끔한 Jira 관리 (hygiene)

레이블 (labels), 댓글 (comments), 그리고 연결된 엔티티 (linked entities)가 일관되게 적용됩니다. 이는 이슈 트래커를 훨씬 더 신뢰할 수 있게 만듭니다.

인간의 주의력 활용 최적화

에이전트의 신뢰도가 낮을 때만 사람이 개입합니다. 그것이 바로 인간의 판단이 가장 유용하게 쓰여야 할 지점입니다.