요약

1. AI Orchestration을 구축해서 개발 속도와 코드 품질을 동시에 향상시켰다.
2. 기존 팀의 개발 프로세스(Jira 티켓 → 개발 → PR → 리뷰)를 Rules, Workflow, Agent, Skill로 구성해 AI에 이식했다.
3. Jira Automation과 연동해서 사람이 요구사항만 정리하면 AI가 자동으로 개발하고, PR을 만들고, 리뷰하면서 상태가 자동으로 전이되는 구조를 만들었다.

서론

최근 AI 기술의 발전이 빨라지면서 AI Assistant의 성능 또한 크게 향상됐고, 코드를 직접 치는 경우가 눈에 띄게 줄었다. AI를 더 잘 활용하는 방법을 찾아보다가 Sub Agent를 팀원처럼 활용하고, Main Agent가 PM 역할을 해서 하나의 개발팀을 구성하는 AI Orchestration이라는 아이디어를 접하게 됐다.

마침 팀에서 적용하고 있는 개발 프로세스가 잘 정리되어 있었기 때문에, 이 프로세스를 그대로 AI에게 가르쳐 주면 되겠다는 생각이 들었다. 이 글에서는 그 과정에서 구축한 AI Orchestration의 구조와 설계 의도를 정리해보려고 한다.

기존 개발 방법과 문제점

AI Orchestration을 구축하기 전에는, spec 문서를 작성해서 AI Agent에게 개발 계획을 세우게 하고 구현을 맡기는 식으로 작업했다. AI가 작업하는 동안 기다리는 시간이 아까워서 같은 Repository를 여러 개 Clone 받아 병렬로 개발을 진행했다. A Clone에서 AI가 작업하는 동안 B Clone에서 다른 Task를 시작하는 방식이었다.

이렇게 하게 된 이유는 단순했다. AI가 일하는 동안 기다리는 시간이 아까웠고, 그렇다고 한 Repository에서 여러 Agent를 동시에 돌리면 코드가 꼬이고 Context 관리가 어려웠기 때문이다.

하지만 이 방식에는 큰 문제가 있었다.

1. Token 낭비가 심했다. 매번 새로운 대화를 시작할 때마다 AI가 코드를 처음부터 다시 읽어야 해서 하루에 몇백만 Token을 쓰게 됐고, 금방 사용량 제한에 걸렸다.
2. Context 관리가 어려웠다. 여러 Clone에서 동시에 작업하다 보니 어디서 무엇을 했는지 추적이 힘들었다.
3. 품질이 일관적이지 않았다. AI가 자유롭게 코드를 작성하다 보니 코딩 컨벤션이나 팀 규칙을 지키지 않는 경우가 잦았다.

결국 내가 원하는 건 명확했다. 팀에서 개발자가 Jira 티켓을 받고, 코드를 분석하고, 개발하고, 빌드와 테스트를 돌리고, PR을 만들고, 리뷰를 받는 그 흐름 전체를 AI가 그대로 수행하는 것. 사람이 일하던 프로세스를 AI에게 가르쳐서 팀원처럼 일하게 만드는 것이었다.

본론

이러한 문제를 해결하기 위해 Cursor IDE를 기반으로 나만의 AI Orchestration을 구축했다. 전체 시스템은 크게 필수적인 Core Orchestration과 이를 확장하고 최적화하는 Advanced Optimization으로 나뉜다.

---

Part 1: Core Orchestration (The Foundation)

AI Orchestration의 가장 기본이 되는 뼈대다. 이 부분만 구축해도 AI가 팀의 규칙을 준수하며 코드를 작성하고 리뷰하는 것이 가능하다.

1. Docs 정리

가장 먼저 한 일은 Repository에 대한 문서를 AI가 빠르게 파악할 수 있도록 정리하는 것이었다. Token 낭비의 가장 큰 원인이 AI가 매번 소스 코드를 읽어서 Context를 파악하는 것이었기 때문에, 코드를 읽지 않아도 프로젝트를 이해할 수 있는 문서를 만들었다.

이때 가장 중요하게 생각한 원칙은 AI Readable이었다. 사람이 읽기 좋은 서술형 문서가 아니라, AI가 파싱하기 쉬운 구조로 작성했다. 기술 스택은 테이블로, 아키텍처는 텍스트 다이어그램으로, 실행 방법은 명령어 리스트로 정리하는 식이다.

Monorepo 구조였기 때문에 전체 프로젝트의 개요를 담은 overview 문서를 만들고, 각 Application과 Library별로 역할과 의존 관계를 정리했다. 이렇게 해두니 AI가 코드를 읽는 대신 문서 몇 개만 참조해도 프로젝트 전체를 파악할 수 있게 됐고, Token 사용량이 눈에 띄게 줄었다.

2. Rules 시스템

문서로 프로젝트 구조를 가르쳤다면, Rules는 일하는 방식을 가르치는 역할이었다. Cursor IDE에서는 .cursor/rules/ 디렉토리에 규칙 파일을 두면 AI가 자동으로 참조하는 기능이 있다. 이를 활용해서 팀의 코딩 컨벤션, Git 규칙, PR 규칙, 테스트 규칙, 보안 규칙 등을 파일로 정리했다.

규칙 파일은 크게 세 종류로 나뉜다.

• 전역 규칙: 코드 스타일, Git 브랜치 네이밍, 커밋 메시지, PR 작성법 등 모든 작업에 적용되는 규칙
• 워크플로우 규칙: 티켓 수령부터 PR 생성까지의 전체 작업 흐름
• 도메인별 규칙: gRPC, REST API, 프론트엔드 등 작업 영역에 따라 다른 규칙

토큰 효율성을 위한 적용 전략

Rules를 설계하면서 가장 신경 쓴 부분은 토큰 효율성이었다. 규칙 파일이 10개가 넘다 보니 모든 규칙을 항상 로드하면 Context Window를 낭비하게 된다. 그래서 규칙을 두 가지로 분류했다.

• 항상 적용: 전역 규칙과 워크플로우 규칙처럼 모든 작업에 필수인 핵심 규칙만 항상 로드
• 조건부 적용: 도메인별 규칙은 해당 파일 패턴을 수정할 때만 자동 로드

예를 들어 gRPC 규칙은 gRPC 관련 파일을 수정할 때만 로드되고, 프론트엔드 규칙은 프론트엔드 파일을 수정할 때만 로드된다. 이렇게 하면 백엔드 작업을 할 때 프론트엔드 규칙이 불필요하게 로드되는 것을 방지할 수 있었다.

3. Workflow

Docs가 프로젝트를 가르치고, Rules가 규칙을 가르친다면, Workflow는 일의 순서를 가르치는 역할이다. 이것이 AI Orchestration의 핵심이었다.

기존에 팀에서 개발자가 일하는 흐름을 그대로 AI 워크플로우로 매핑했다. 티켓 수령부터 PR 생성, 코드 리뷰까지의 전체 프로세스를 9단계로 정의했다.

이 워크플로우의 핵심 설계 포인트는 두 가지다.

첫 번째는 팀 프로세스와 1:1로 매핑된다는 것이다.

사람이 하던 일	AI가 하는 일
Jira 티켓 확인, 요구사항 분석	티켓 조회 후 Plan 모드에서 부족한 요구사항 분석
관련 코드 파악	Skill을 활용한 코드 분석
코드 작성	Rules를 준수하며 구현
로컬에서 빌드/테스트 확인	빌드, 테스트, 린트 순차 검증
리뷰 요청 전 셀프 체크	Sub Agent가 코드 품질 분석
PR 생성	GitHub에 PR 자동 생성
동료 코드 리뷰	Review Agent가 인라인 코멘트 작성

두 번째는 이전 단계가 실패하면 다음 단계로 진행하지 않는다는 것이다. 빌드가 깨지면 테스트를 실행하지 않고, 테스트가 실패하면 PR을 만들지 않는다. AI가 직접 실패 원인을 분석하고 수정한 뒤 재시도하며, 3회 이상 실패하면 사람에게 도움을 요청한다. 사람이 일하는 방식과 동일하다.

4. Agents (Main & Review)

Workflow가 전체 흐름을 정의한다면, Agent는 그 흐름 안에서 전문적인 판단을 담당하는 역할이다.

Main Agent는 PM처럼 전체를 조율하며 Workflow를 따라 작업을 진행한다.

Review Agent는 PR 생성 후에 GitHub PR에 직접 인라인 코멘트를 작성하는 역할이다. 사람이 코드 리뷰를 하는 것과 동일한 방식이다.

• Frontend Review Agent: 컴포넌트 설계, 상태 관리 패턴, 렌더링 최적화 등을 리뷰한다.
• Backend Review Agent: API 설계, DB 쿼리 효율성, 에러 핸들링, 보안 등을 리뷰한다.
• Spec Review Agent: 처음에 정의된 요구 사항을 모두 만족하는지 리뷰한다.

리뷰 Agent를 설계하면서 의도적으로 개발할 때 사용하는 모델과 다른 모델을 사용했다. 같은 모델이 코드를 작성하고 리뷰까지 하면 자기가 작성한 코드의 문제를 잘 발견하지 못하는 경향이 있었다. 사람도 자기가 쓴 코드를 셀프 리뷰하면 놓치는 부분이 있는 것과 같은 이치다. 서로 다른 모델은 추론 방식이 다르기 때문에 한쪽이 놓치는 부분을 다른 쪽이 잡아낼 수 있었고, 이를 통해 리뷰 효율을 높일 수 있었다.

---

Part 2: Advanced Optimization (Scaling Up)

Core가 단일 작업의 품질을 보장한다면, Advanced 단계는 작업의 규모와 속도, 그리고 지속 가능성을 위한 확장이다.

5. Supervisor / Worker & Git Worktree

여러 Task를 동시에 처리해야 하는 상황을 위해 Supervisor와 Worker라는 두 가지 역할을 정의하고, 이를 물리적으로 뒷받침하기 위해 Git Worktree 전략을 도입했다.

Supervisor는 여러 Task를 동시에 조율하는 PM 역할이다. Jira에서 Ready 상태의 Task들을 확인하고, 변경 범위가 겹치지 않는 Task들은 병렬로 처리하고, 겹치면 순차 처리한다.

Git Worktree는 하나의 Git 저장소에 여러 작업 디렉토리를 연결하는 기능이다. Clone과 달리 .git 객체를 공유하기 때문에 가볍고, 디스크 공간도 적게 차지한다. Jira 티켓별로 독립된 Worktree를 생성하여, 각 Task가 서로 다른 디렉토리에서 독립적으로 작업되도록 했다. 덕분에 여러 Task를 병렬로 진행해도 코드가 꼬이는 문제가 사라졌다.

6. Skills & MCP

Agent가 판단과 분석을 담당한다면, Skill은 도구에 해당한다. 입력과 출력이 명확하게 정의되어 있고, 추론 없이 정해진 작업만 수행하는 재사용 가능한 기능 단위다.

특히 기존에 팀에서 사용하던 Code Generator Script들을 Skill로 매핑해서 제공했다. 덕분에 AI가 코드를 작성할 때도 팀의 보일러플레이트와 컨벤션을 완벽하게 준수할 수 있었다.

여기에 MCP(Model Context Protocol)를 연동하여 AI가 GitHub와 Jira 같은 외부 서비스를 직접 다룰 수 있게 했다. GitHub MCP를 통해 PR 생성, 코멘트 작성, 리뷰 등을 할 수 있고, Jira MCP를 통해 티켓 조회, 상태 변경 등을 할 수 있다.

이 연동이 완성되면서 비로소 기존 팀 프로세스를 AI가 End-to-End로 수행할 수 있게 됐다. Jira Automation 규칙을 연결하면 상태 전이까지 자동화되어, 사람은 요구사항 정리와 최종 승인만 하면 되는 구조가 완성된다.

7. Docs Update Workflow

지속 가능한 AI Orchestration을 구축하려면 코드가 변하면 문서도 함께 변해야 한다. 문서가 오래되면 AI가 잘못된 Context를 기반으로 작업하게 되고, 결국 품질이 떨어진다.

이 문제를 해결하기 위해 문서 업데이트 자체도 하나의 워크플로우로 정의했다. 핵심은 AI가 문서 업데이트가 필요한 시점을 스스로 감지하고 제안한다는 점이다.

예를 들어 개발이나 코드 리뷰 중에 AI가 기존 규칙에 없는 새로운 패턴을 발견하면, "이것을 문서에 추가할까요?"라고 제안한다. 사용자가 승인하면 별도의 경량 워크플로우가 실행된다. 이 플로우 덕분에 Docs와 Rules가 코드와 함께 살아있는 문서로 유지될 수 있었다.

결론

구축 이후의 변화

AI Orchestration을 도입한 이후 가장 크게 달라진 점은 사람의 역할이 변했다는 것이다. 이전에는 코드를 직접 작성하거나, AI가 작성한 코드를 일일이 확인하는 데 시간을 썼다면, 이제는 Jira 티켓에 요구사항을 최대한 자세히 작성하고, Jira 링크만 넘기면 됐다. AI가 Plan 단계에서 부족한 정보를 추가로 물어보고, 이후에는 PR Review 단계에서 결과물을 확인하는 것만으로 충분했다.

이런 방식으로 일하다 보니 부수적인 효과도 있었다. 요구사항을 Jira에 상세히 남기게 되면서 Sprint Meeting이나 평소에 팀원들이 어떤 일을 하는지 더 명확해졌고, 작업 History가 자연스럽게 잘 남겨지게 됐다.

체감한 변화를 정리하면 다음과 같다.

• Token 사용량 감소: Docs와 Rules를 잘 정리해두니 AI가 매번 코드를 읽을 필요가 없어졌다.
• 코드 품질 일관성: Rules로 컨벤션을 강제하고, Agent가 PR 전후로 검증하니 일관된 품질의 코드가 나왔다.
• 병렬 작업 안정성: Git Worktree와 Supervisor를 통해 여러 Task를 안전하게 병렬 처리할 수 있게 됐다.
• 프로세스 자동화: Jira 티켓 수령부터 PR 생성과 코드 리뷰까지, 기존에 사람이 수동으로 하던 흐름이 자동으로 동작한다.

실제 사례

구축 이후에 실제로 효과를 크게 체감한 사례 두 가지를 소개한다.

ESLint에서 Biome으로 전체 마이그레이션

pre-push 단계에서 Lint 검사를 실행하고 있었는데, 변경된 프로젝트만 실행해도 약 2분 정도 걸리는 문제가 있었다. Biome으로 전환하면 해결될 거라 판단했지만, Biome에 대한 지식이 거의 없었다. Jira 티켓만 생성해서 AI에게 작업을 맡겼는데, 100% 정확하게 처리하지는 않았지만 정상 동작하는 수준까지 만들어줬고, 세부적인 설정만 직접 조정해서 2~3시간 만에 전체 마이그레이션을 완료할 수 있었다.

PR Test CI 최적화

MCP를 통해 AI가 CI 로그를 직접 조회할 수 있도록 연동했다. 이를 통해 AI가 CI에서 발생하는 비효율적인 부분을 스스로 찾아서 개선하도록 했는데, Unit Test 실행 시간이 16~20분에서 3~4분대로 약 80% 단축됐다. 사람이 직접 CI 로그를 분석하고 최적화 포인트를 찾는 것보다 훨씬 빠르게 처리된 케이스였다.

한계와 향후 방향

물론 아직 완벽하지는 않다. 새로운 기능을 개발하는 경우는 대부분 잘 수행했지만, 기존 코드를 리팩토링하거나 도메인 특화된 비즈니스 로직을 다루는 경우에는 잘 수행하지 못하는 경우가 있었다. 이런 부분은 앞에서 소개한 문서 업데이트 플로우를 통해 AI가 참조하는 Context를 지속적으로 보강하면서 나아지고 있다. 앞으로는 AI가 반복되는 패턴을 학습해서 Rules를 스스로 개선하거나, 오탐 패턴을 자동으로 보정하는 방향으로 발전시키고 싶다.

결국 이번 작업을 통해 느낀 것은, AI Orchestration의 핵심이 AI에게 "코드를 짜라"고 지시하는 것이 아니라 "우리 팀이 일하는 방식을 가르쳐주는 것"이라는 점이었다. 팀의 프로세스, 규칙, 품질 기준을 체계적으로 정리하고 AI에 이식하면, AI는 단순한 코드 생성 도구가 아니라 팀의 일원으로 동작할 수 있다. 이미 잘 정리된 팀 프로세스가 있다면, AI Orchestration 구축은 생각보다 어렵지 않다.