QA 이슈 해결을 자동화하는 Agentic 워크플로우

소프트웨어 팀의 생산성을 가장 크게 떨어뜨리는 문제는 복잡한 버그가 아닙니다.

오히려 대부분의 시간을 소모하는 것은 작고 반복적인 이슈들입니다.

버튼이 동작하지 않거나 특정 조건에서 목록이 비어 보이는 문제와 같은 이슈입니다.

이러한 문제는 대부분 몇 줄의 코드 수정으로 해결됩니다. 그러나 그 몇 줄을 수정하기 위해 엔지니어는 전체 개발 사이클을 반복해야 합니다.

1. 이슈의 맥락을 파악하고
2. 관련 레포지토리를 탐색하고
3. 수정 위치를 확인하고
4. 코드를 수정한 뒤
5. Pull Request를 생성하고
6. 리뷰를 요청합니다.

실제로는 코드 수정 자체보다 이 과정의 오버헤드가 더 큰 경우가 많습니다. 이 과정이 반복되면서 팀의 작업 흐름이 자주 끊기게 됩니다.

이 지점에서 하나의 질문이 생깁니다.

엔지니어링 워크플로우에서 실제로 인간의 판단이 필요한 부분은 어디까지일까요.

‍

‍

반복적인 실행 작업은 왜 여전히 인간의 몫인가

대부분의 개발 조직에서는 QA 이슈가 다음과 같은 방식으로 처리됩니다.

1. QA 팀이 Slack 채널에 버그를 보고합니다.
2. 엔지니어는 해당 이슈를 확인하고 해결 방향을 판단합니다.
3. 이후 실제 수정 작업은 GitHub나 로컬 개발 환경에서 진행됩니다.

이 구조 자체는 자연스러운 협업 방식입니다.

Slack은 개발 환경에 접근하지 못하는 팀원들과도 문제 상황을 공유하고 논의할 수 있는 가장 효과적인 커뮤니케이션 채널이기 때문입니다. 또한 이슈의 맥락과 진행 상황을 팀 전체에 투명하게 공유하는 역할도 합니다.하지만, 실제 대응에서는 이슈 해결 과정에서 반복되는 실행 작업에 가장 많은 리소스가 필요합니다.

버그의 원인을 파악하고 수정 방향을 결정하는 과정은 인간의 판단이 필요한 영역입니다. 그러나 그 이후 단계에서는 반복적인 실행 작업이 이어집니다.

예를 들어 다음과 같은 과정입니다.

• 관련 레포지토리를 탐색하고
• 수정이 필요한 파일을 찾고
• 코드를 수정하고
• 브랜치를 생성하고
• Pull Request를 생성하고
• 리뷰를 요청합니다.

이러한 작업은 대부분 이슈마다 동일한 형태로 반복됩니다.즉, 핵심 문제는 Slack과 GitHub 사이의 협업 구조가 아니라 판단 이후에 이어지는 실행 단계가 여전히 인간의 작업으로 남아 있다는 점입니다.

위의 질문은 여전히 풀리지 않고 남아 있습니다.

엔지니어링 워크플로우에서 인간이 수행해야 하는 판단 작업과 시스템이 대신 수행할 수 있는 실행 작업은 어떻게 구분할 수 있을 지에 대한 의문입니다.

‍

‍

Slack에서 시작되는 실행형 워크플로우

이 문제를 해결하기 위해 설계된 시스템이 issue-resolver-bot입니다.

이 봇은 Slack의 이모지 반응을 트리거로 삼아 이슈 분석부터 Pull Request 생성까지의 과정을 자동으로 수행합니다.

핵심 아이디어는 단순합니다.

이슈 해결의 논의와 실행을 하나의 환경 안에서 연결하는 것입니다.

워크플로우는 다음과 같이 작동합니다.

1. 먼저 QA 팀원이 Slack QA 채널에 버그를 보고합니다. 텍스트뿐 아니라 스크린샷이나 첨부 파일도 함께 업로드할 수 있습니다.
2. 이미지가 포함된 경우 시스템은 해당 이미지를 Amazon Bedrock으로 전달하여 시각적 맥락을 함께 분석합니다.
3. 이후 팀원이 해당 메시지에 bug 이모지를 추가합니다. 이 이모지가 자동화 프로세스를 시작하는 트리거가 됩니다.
4. 상시 실행 중인 Go 기반 서비스인 issue-resolver-bot이 Slack 이벤트를 감지하고 자동화 파이프라인을 실행합니다.

‍

‍

이슈 복잡도에 따른 AI 처리 구조

모든 이슈가 동일한 수준의 추론을 요구하는 것은 아닙니다.

따라서 시스템은 이슈의 복잡도를 분석하여 서로 다른 AI 모델을 사용합니다.

이 구조는 속도와 비용 그리고 추론 능력 사이의 균형을 고려하여 설계되었습니다.

단순한 수정에는 빠른 모델을 사용하고 복잡한 변경에는 더 높은 추론 능력을 가진 모델을 사용합니다.

‍

‍

레포지토리 탐색부터 Pull Request 생성까지

이슈 분석이 완료되면 시스템은 관련 레포지토리를 탐색합니다.

필요한 경우 프론트엔드와 백엔드 레포지토리를 모두 분석합니다. 이후 코드 수정과 브랜치 생성 그리고 Pull Request 생성까지의 과정을 자동으로 수행합니다.

Pull Request의 작성자는 봇 계정입니다.

이 과정에서 엔지니어가 수행해야 하는 반복적인 실행 작업은 크게 줄어듭니다.엔지니어는 Slack에서 이슈의 맥락을 정리하고 수정 방향을 결정한 뒤 자동화 파이프라인을 트리거합니다.

이후 레포지토리 탐색, 코드 수정, 브랜치 생성, Pull Request 작성과 같은 실행 단계는 시스템이 수행합니다.

엔지니어의 역할은 생성된 Pull Request를 검토하고 승인하는 것입니다.

판단은 인간이 수행하고 실행은 시스템이 담당합니다.

‍

‍

Slack 안에서 완료되는 이슈 해결 과정

이 시스템의 가장 중요한 변화는 코드 수정이 자동화된다는 점이 아닙니다.

이슈 해결의 전체 과정이 Slack 안에서 이루어진다는 점입니다.

엔지니어가 Slack에서 수정 방향을 제시하면 QA나 PM이 추가 맥락을 제공합니다. 논의가 정리되면 누군가 이모지를 추가합니다.

이 시점에서 자동화가 실행됩니다.

새로운 명령어나 인터페이스가 필요하지 않습니다. 팀이 이미 사용하고 있는 행동 하나로 전체 워크플로우가 시작됩니다.

실제로 여러 이슈가 엔지니어가 아닌 팀원이 이모지를 트리거하면서 해결되었습니다.

본 Agentic 워크플로우를 구축한 지 3주도 채 되지 않는 기간 동안 10개 이상의 이슈가 이 방식으로 처리되었습니다.

‍

‍

인간의 역할은 설계입니다

이 프로젝트의 코드 대부분은 Claude Code를 통해 작성되었습니다.

주요 작업은 다음과 같습니다.

• 기능 요구사항 정의
• 이슈 분류 기준 설계
• 생성된 Pull Request 품질 검토
• 엣지 케이스 피드백
• 시스템 아키텍처 설계

시스템 아키텍처는 Slack App, GitHub App, Amazon Bedrock 그리고 Go 기반 오케스트레이션 서비스로 구성되어 있습니다.

Claude Code가 코드를 작성하고 인간은 방향을 결정합니다.

이 구조는 시스템이 구현하려는 철학과도 일치합니다.

‍

‍

아직 남아 있는 과제

현재 시스템에도 한계는 존재합니다.

봇이 가장 잘 작동하는 경우는 이슈 설명 안에 어느 레포지토리의 어느 부분을 수정해야 하는지에 대한 힌트가 충분히 포함되어 있을 때입니다.

맥락이 거의 없는 이슈에서도 정확한 수정 위치를 추론하는 능력은 아직 개선이 필요한 영역입니다.

UI 관련 문제도 현재는 제한적인 영역입니다.

레이아웃이나 스타일 문제는 코드만으로 판단하기 어렵기 때문입니다.

이를 해결하기 위해 Figma MCP 연동을 준비하고 있습니다. 디자인 토큰과 컴포넌트 스펙을 직접 참조할 수 있게 되면 UI 관련 이슈도 동일한 자동화 파이프라인 안에서 처리할 수 있을 것으로 보고 있습니다.

‍

‍

실행을 시스템에 위임하는 새로운 워크플로우

일에서의 해방은 모든 일을 자동화하자는 의미가 아닙니다.

인간이 수행해야 하는 판단과 책임의 영역을 명확히 하고 나머지를 시스템에 위임하는 것을 의미합니다.

issue-resolver-bot은 그 첫 번째 시도입니다.

하나의 이모지가 Pull Request가 되는 이 흐름은 팀이 더 중요한 문제에 집중할 수 있는 시간을 만들어 줍니다.

반복적인 실행은 시스템이 담당하고 인간은 판단과 방향 설정에 집중합니다.

이것이 Enhans가 말하는 New Digital Labor가 실제 워크플로우 안에서 작동하는 방식입니다.

‍

‍

이와 같은 Agentic 워크플로우나 AI 기반 자동화 시스템을 조직의 개발 환경에 도입하는 방법에 관심이 있다면, Enhans 팀에 문의해 주시기 바랍니다.

문의하기