Jira 티켓부터 기능 환경까지: 멀티 에이전트 AI 개발자 구축 과정

저는 EXANTE의 웹 애플리케이션 책임자(Head of Web Applications)인 Alina입니다. 저는 저희 웹 프로젝트들의 기술 전략, 납품 효율성 및 팀 전반의 엔지니어링 프로세스를 담당하고 있습니다. 또한 AI 전환을 포함한 여러 이니셔티브를 주도하고 있습니다.

저희가 AI 작업을 시작했을 때, 단순히 개별 개발자 도구에 머무르고 싶지 않았습니다. 저희는 일부 작업을 처음부터 끝까지 처리할 수 있는 자율적인 파이프라인을 원했고, 이것이 개발자 생산성을 얼마나 향상시키고 작업 완료 시간(time from task to finished result)을 단축하는지 측정하고 싶었습니다. 그 결과물이 바로 Codey입니다. Codey는 Jira 태스크에서 작동하는 기능까지의 경로 중 상당 부분을 독립적으로 처리하는 멀티 에이전트 AI 코딩 에이전트 시스템입니다.

저희가 6개월 전에 배포를 시작했습니다. 현재까지의 수치는 다음과 같습니다:

• 250개의 태스크가 이 시스템을 거쳤습니다.
• 그 중 75%가 성공적으로 완료되었습니다.
• Codey를 사용하는 팀들의 전체 태스크 중 7%가 이제 Codey에 의해 처리됩니다.
• 코딩 시작부터 배포된 기능 환경까지의 평균 시간은 약 30분입니다.

핵심 교훈은 이렇습니다. 단일한 강력한 모델만으로는 AI를 실제 개발 프로세스의 일부로 만들기에는 충분하지 않다는 것입니다. 고품질 요구사항, 잘 준비된 프로젝트, 측정 가능한 검사(measurable checks), 그리고 시스템이 작동하는 방식에 대한 명확한 규칙들이 필요합니다.

개별 자동화에서 AI 소프트웨어 엔지니어까지

저희는 작게 시작했습니다: 변경된 diff를 기반으로 한 AI 코드 리뷰 및 영향받은 모듈 분석입니다. 이것들은 코드가 작성된 후의 개별 단계를 가속화했지만, Jira 태스크를 분석하고 코드베이스를 탐색하는 것부터 구현 및 검사에 이르기까지 전체 사이클을 스스로 완료할 수는 없었습니다. 저는 이 단계에 대해 이전 기사에서 작성했습니다.

Codey가 다음 단계였습니다. Codey는 코드를 탐색하고, 계획을 세우고, 구현 및 테스트를 작성하며, 결과를 검사하고 발견된 문제를 수정하는 모든 과정을 스스로 수행합니다.

Codey는 현재 Node.js, React 및 Python 프로젝트와 잘 작동합니다. 저희는 로컬 프론트엔드 및 사용자 인터페이스(UI) 작업으로 시작하여, 이후 프론트엔드와 백엔드를 모두 건드리는 풀스택 변경 사항으로 넘어갔습니다.

오늘날 저희는 이 도구를 제 담당 영역의 모든 프로젝트에 사용합니다. 내부 고객 관계 관리(CRM) 및 백오피스 시스템부터 클라이언트가 직접 사용하는 핀테크 서비스, 여기에는 클라이언트 포털, 웹 거래 터미널, 데스크톱 애플리케이션까지 포함됩니다.

Codey 작동 방식: 멀티 에이전트 아키텍처

아키텍처적으로 볼 때, Codey는 AI 에이전트를 위한 사내 오케스트레이션 레이어입니다. 여기서 AI 에이전트란 정의된 역할과 필요한 도구에 접근할 수 있는 연결된 런타임 환경에서 실행되는 대규모 언어 모델(LLM)을 의미합니다. 저희는 세 가지 런타임을 사용합니다: Claude Agent SDK, Codex, 그리고 OpenCode. 이들은 에이전트가 리포지토리, 파일 및 터미널과 작업할 수 있도록 합니다.

Codey는 이들을 단일 에이전트 워크플로우로 연결합니다. 역할을 할당하고, 단계를 거치며, 검사를 실행하고, 수정 요청을 위해 작업을 다시 보내고, 결과를 Jira, GitLab 및 지속적 통합(CI)과 동기화합니다.

작업이 Codey에 도달하는 방식

시나리오 1: 스프린트 계획

이것이 어떻게 작동하는지는 팀 내에서 Codey가 얼마나 도입되었는지에 따라 다릅니다. 처음에는 팀이 수동으로 잘 설명된 작업을 선택하고 시스템을 위해 레이블을 지정합니다.

프로세스가 확립된 팀의 경우, Codey와 개발자는 공통 백로그를 공유합니다. 기본적으로 Codey가 적합한 작업을 가져가고, 팀은 특정 이유로 사람이 처리해야 하는 모든 항목에 AI 건너뛰기(AI skip) 레이블을 적용합니다. 시간이 지남에 따라 저희는 이를 연결된 모든 팀과 프로젝트로 확장할 계획입니다.

시나리오 2: Slack

요청자가 필요한 것을 설명합니다. Codey는 요청자를 시스템 내비게이션을 돕고, 세부 사항을 명확히 하며, Jira 작업을 생성하는 데 도움을 줍니다. 그런 다음 이 작업을 완료하고, 머지 리퀘스트(MR)를 열어 동일한 스레드로 돌아옵니다. 여기서 요청자에게 태그를 지정하고, 결과를 검토해 달라고 요청하며, 기능 환경으로 연결되는 링크를 공유합니다.

Codey가 Jira로부터 작업을 받으면, 관련 GitLab 저장소들을 식별합니다. 각 프로젝트는 다음 사항에 대한 사전 정의된 설정을 가지고 있습니다:

• 어떤 저장소가 이 작업을 받아야 하는지
• 어떤 자동화 검사를 실행할지
• 누구를 검토자로 지정할지
• 기능 환경을 어떻게 배포하고 올바른 프론트엔드 및 백엔드 버전을 연결할지

이러한 설정을 통해 Codey는 특정 프로젝트의 프로세스를 거쳐 작업을 진행하는 방법과 팀 검토를 위해 결과를 준비하는 방법을 알게 됩니다.

시스템 내 AI 에이전트 역할

각 작업에는 6가지 핵심 역할이 작동합니다:

Researcher → Planner → Developer → Reviewer → QA → Verifier

• Researcher: 요구 사항과 코드베이스를 연구합니다.
• Planner: 계획을 수립합니다.
• Developer: 코드를 작성하고 테스트합니다.
• Reviewer: 변경 사항의 품질과 정확성을 확인합니다.
• QA (품질 보증): 테스트와 기술 검사를 실행합니다.
• Verifier: 결과를 계획에 명시된 필수 요구 사항과 비교합니다.

서로 다른 역할들은 서로 다른 모델을 사용합니다. 만약 Reviewer나 자동화 검사에서 문제가 발견되면, 작업은 재작업을 위해 Developer에게 돌아갑니다.

결과가 전달되면, 팀이 이를 검토합니다. Codey는 MR과 Jira 작업으로부터 코드 및 비즈니스 로직에 대한 댓글을 가져와 변경 사항을 만들고 검사를 다시 실행합니다.

작업이 영원히 개정판 루프를 돌지 않도록, Codey는 최대 3번의 반복만 수행합니다. 만약 댓글들이 여전히 해결되지 않았다면, 작업은 AI failed 상태가 됩니다. 그 결과는 통계에 기록되고 시스템의 자체 개선 루프로 피드백됩니다. 필요하다면 수동으로 실행을 재시작할 수 있습니다.

검사 및 오류 처리

MR이 생성되면, Codey는 프로젝트의 품질 게이트(quality gates)를 실행합니다: 테스트, 린터(linters), 보안 검사 및 AI 코드 리뷰입니다. 문제가 수정 가능하다면, 해당 작업은 재작업을 위해 돌아갑니다. 만약 프로젝트 설정 때문에 특정 검사를 실행할 수 없다면, Codey는 초안 MR(Draft MR)을 열고 완료되지 않은 검사 목록을 보여줍니다.

대부분의 AI 실패 상태는 다음 세 가지 원인 중 하나로 귀결됩니다:

• 컨텍스트 누락 (missing context)
• 여러 상호 의존적인 리포지토리(repositories)에 걸친 변경 사항
• 새로운 프로젝트 또는 기술 스택에서의 첫 번째 작업

결과에 대한 팀 검토

Codey는 각 MR에 대해 영향을 받는 모듈을 식별하고, Jira에 제품의 어떤 부분이 회귀 테스트(regression testing)가 필요한지 기록합니다. 검사가 통과하면, 프론트엔드와 백엔드는 별도의 기능 환경(feature environment, 미리 보기 환경)에 배포되며, 요청자는 여기서 전체 기능을 엔드투엔드로 확인할 수 있습니다.

결과가 기대치에 부합하면, 요청자가 **확인(Confirm)**을 클릭합니다. 그러면 해당 작업은 팀 검토를 거쳐 릴리스 빌드로 넘어갑니다. Codey는 인간의 개입이 필요한 과정에서 작동합니다: 제품 승인(product acceptance), 최종 결정 및 릴리스 책임은 여전히 사람에게 있습니다.

AI 코딩 에이전트 도입의 비즈니스적 과제

작업 정의의 품질

개발팀의 어떤 구성원과 마찬가지로, Codey 역시 명확한 요구 사항 없이는 작업을 잘 수행할 수 없습니다. 그래서 저희는 단위 테스트(unit tests) 및 통합 테스트(integration tests)에 대한 요구 사항을 포함하여 승인 흐름(acceptance flow)과 예상 검사를 의무적으로 기술하는 Jira 작업 템플릿을 도입했습니다.

Codey에 대한 팀의 신뢰

저희는 루틴한 작업이나 리팩토링부터 시작할 것을 제안합니다. 이러한 작업은 원래 전문가 검토를 거치기 때문입니다. 성공적인 결과가 쌓이면서, 팀들은 수동 선택에서 벗어나 Codey와 개발자를 위한 공유 백로그(shared backlog)로 이동하고, 예외 사항을 **AI 건너뛰기(AI skip)**로 표시합니다. 신뢰는 점진적으로 증가하며, 시스템은 그 과정에서 더 많은 컨텍스트를 얻게 됩니다.

검토 및 개선으로의 작업 부하 변화

초기 채택 단계에서 작업의 일부가 이러한 단계로 이동합니다. 개발자는 단순히 작업을 이해하는 것뿐만 아니라 Codey가 이를 어떻게 해석하고 구현했는지도 알아야 합니다. 우리는 더 정확한 작업 설명, 각 프로젝트에 대한 상세 규칙, 그리고 다단계 자동 및 수동 검토를 통해 이를 줄입니다.

인프라 비용 (Infrastructure costs)

별도의 백엔드 기능 환경은 운영하는 데 비용이 더 많이 듭니다. 이 비용을 통제하기 위해 우리는 환경 수명을 제한하고 축소된 테스트 데이터베이스를 사용합니다.

멀티 에이전트 시스템의 기술적 과제 (Technical challenges of a multi-agent system)

시스템 범용성 (System versatility)

프로젝트는 아키텍처, 코드베이스 구조, 기술 스택 및 개발 규칙에서 차이가 납니다. 하나의 에이전트 지침 세트는 모든 곳에서 동일하게 좋은 결과를 제공하지 못합니다.

따라서 우리는 각 프로젝트에 대한 프로필을 유지합니다. 여기에는 아키텍처, 코드베이스 구조, 빌드 및 테스트 명령어, 로컬 개발 규칙이 포함됩니다. 반복적인 작업을 위해 Codey는 세 가지 수준의 스킬을 가지고 있습니다:

• 글로벌 (global)
• 언어별 (language-specific)
• 프로젝트별 (project-specific)

시스템은 축적된 패턴으로부터 새로운 버전의 스킬을 생성합니다. 이들은 먼저 검토된 후에야 파이프라인에 추가됩니다. 이러한 컨텍스트 엔지니어링(context engineering) 접근 방식은 Codey가 각 프로젝트에 맞춰 행동하도록 할 수 있게 합니다.

변경 품질 (Change quality)

신뢰할 수 있는 변경 사항을 위해서는 간단하고 재현 가능한 설정, 명확한 검사 명령어, 그리고 성숙한 품질 게이트가 필요합니다. CI 파이프라인 내의 테스트, 린터(linters), 보안 검사 및 AI 코드 리뷰는 문제가 되는 변경 사항이 팀의 작업 부하를 늘리거나 프로덕션에 도달하기 전에 막습니다.

다양한 역할에 맞는 LLM 선택 (Choosing LLMs for different roles)

우리는 코딩 에이전트를 평가하기 위해 정기적인 벤치마크(benchmarks)를 실행합니다. 모델, 역할 및 도구의 다양한 조합이 동일한 일반 목적 작업을 수행합니다. 우리는 세 가지를 비교합니다:

• 해결률 (solve rate): 필수 검사를 통과하고 인간 리뷰와 비교할 수 있는 점수를 받은 해결책의 비율
• 실행 속도 (speed of execution)
• 실행 비용 (cost of execution)

평가를 독립적으로 유지하기 위해, 결과는 같은 계열의 모델에 의해 검토되지 않습니다.

벤치마크 결과에 따르면 모든 단계에서 가장 강력한 단일 모델을 사용하는 것이 항상 최상의 결과를 가져오지는 않았습니다. 일부 역할의 경우, 더 단순한 모델이 더 잘 작동했습니다. 이는 계획을 더 충실히 따르고, 해결책을 과도하게 복잡하게 만들지 않으며, 더 빠르게 완료하기 때문입니다. 따라서 우리는 테스트 결과에 따라 역할별로 모델 할당 방식을 정기적으로 검토합니다. 최근 라운드 이후, 일부 역할을 Codex 모델로 이동시켰습니다.

지속적인 개선 (Continuous improvement)

Codey를 체계적으로 개선하기 위해 학습 루프(Learning loop)를 사용합니다. 이는 로그와 문제 발생 세션을 분석하고, 반복되는 오류를 식별하며, 가설을 수립합니다. 모든 변경 사항은 동일한 벤치마크를 통해 테스트되며, 측정 가능한 개선이 이루어진 후에만 프로덕션에 배포됩니다.

한 사이클 동안 우리는 20개의 가설을 테스트하고 그중 9개를 유지했습니다. 또한 개발자와 테스터의 피드백도 반영합니다. 병렬적으로, 우리는 시스템이 코드 및 컨텍스트와 작동하는 방식을 최적화합니다: RTK는 명령어 출력 볼륨을 줄이고, 추상 구문 트리(AST) 인덱스는 적절한 모듈 검색 속도를 높입니다.

Codey의 다음 단계 (Next steps for Codey)

다음으로 작업하고 있는 내용은 다음과 같습니다:

• 자동 백로그 분석: 시스템이 적합한 작업을 제안하면, 팀은 AI에게 맡길 수 없는 작업을 제외할 것입니다.
• 강화된 학습 루프: MR(Merge Request) 내 인간 댓글에 대한 지속적인 분석을 통해, 해당 피드백을 사용하여 엔진을 자동으로 개선합니다.
• 더 넓은 커버리지: 새로운 요청자 및 부서, 프로젝트, 기술 스택 및 시스템과 Codey를 연결합니다.
• 더 많은 컨텍스트 소스: 문서, Jira 및 업무 커뮤니케이션을 통해, Codey가 개발뿐만 아니라 작업에 대한 분석적이고 제품적인 작업을 지원할 수 있도록 합니다.
• 기능 기반 배포: Codey의 변경 사항이 필수 검사를 거친 후 더 빠르게 프로덕션에 도달하도록 합니다.

결론

6개월이 지난 지금, 우리는 AI 개발자가 실제 작업 프로세스의 일부가 될 수 있음을 확인했습니다. 강력한 모델을 개발에 연결하는 것만으로는 충분하지 않습니다. 고품질의 요구사항, 잘 준비된 프로젝트, 측정 가능한 검사 항목, 그리고 시스템 작동 방식에 대한 명확한 규칙들이 필요합니다.

다음 단계는 Codey에게 작업 정의부터 프로덕션까지 전체 사이클을 맡기는 것입니다. 이 과정에서 합의된 규칙과 위험 통제 장치는 유지될 것입니다.

만약 여러분이 자체 파이프라인에서 코딩 에이전트를 운영하고 있다면, 댓글로 역할을 어떻게 분배하고 모델을 어떻게 구성했는지 듣고 싶습니다.

원문은 Exante Technology on Medium에 게시되었습니다.