티켓의 40%를 AI에 위임하는 방법

출처: The New Stack

AI는 코딩에서 우리를 이깁니다.

하지만 계획, QA, SDLC 전반에 걸친 모든 도구와의 작업 등 거의 모든 분야에서 더 좋고 더 빠릅니다.

그렇다면 왜 우리는 에이전트에게 티켓부터 프로덕션까지 전체 기능과 버그를 맡기지 않을까요?

우리가 해야 할 일은 무엇을 만들지 결정하고, 에이전트가 가장 잘하는 일을 하게 하는 것뿐입니다.

하지만 아직은 불가능합니다.

그 이유는 오늘날 모든 SDLC가 수동으로 운영되고 있기 때문입니다.

승인, 리뷰, 인계. 편안함을 주지만 대부분 불필요한 절차들입니다.

“모든 SDLC가 오늘날 수동이다. 승인, 리뷰, 인계. 이것은 에이전트에게는 연극처럼 보인다. 에이전트는 그냥 앞으로 나아가고 싶어한다.”

에이전트에게는 연극처럼 보이는 것이죠. 에이전트는 단지 앞으로 나아가고 싶어합니다.

따라서 소프트웨어 전달 방식을 에이전트를 우선으로 설계해야 합니다.

이를 위해서는 세 가지가 갖춰져야 합니다: 컨텍스트, 가드레일, 가시성.

• 컨텍스트 – 에이전트가 티켓 제목만이 아니라 작업 전체 그림에서 시작하도록.
• 가드레일 – 범위가 어디까지인지, 무엇을 건드리지 말아야 하는지, 언제 멈추고 물어야 하는지를 알게 함.
• 가시성 – 엔지니어가 에이전트 로그를 하루 종일 보지 않아도 현재 상황을 파악할 수 있게.

티켓이 들어오는 순간부터 배포되는 순간까지 이를 지원할 인프라를 구축합시다.

우리가 만들고 있는 것

세부 사항에 들어가기 전에 전체 구조를 살펴보세요.

에이전트 작업과 인간 검증이 번갈아 가며 진행되는 다섯 단계입니다.

Phase 1: Planning – 원시 티켓을 풍부한 컨텍스트, 상세 PRD, 포괄적인 기술 사양을 갖춘 에이전트가 실제로 작업할 수 있는 형태로 변환합니다.

Phase 2: In review – 스코어카드가 작업이 안전하고 에이전트가 수행하기에 충분히 정의됐는지 검증합니다. PM이 PRD에 서명하고, 엔지니어가 기술 사양에 서명합니다. 이후 코딩 에이전트에게 전달됩니다.

Phase 3: In Development – Cursor 또는 Claude Code 에이전트가 티켓을 작업하고, 진행 상황에 따라 엔터티를 업데이트합니다.

Phase 4: Preview – PR이 열리고 클라우드 환경에서 실행되면 엔지니어와 PM이 미리 보기합니다. 그 후 배포 흐름에 넘깁니다.

Phase 5: Deploy – 현재 인시던트와 배포 금지 윈도우를 확인하고, 릴리즈 노트를 생성한 뒤 배포합니다.

이 글의 나머지 부분에서는 각 단계를 차례대로 살펴보며, 실제 동작하기 위해 먼저 준비해야 할 사항들을 설명합니다.

전제 조건: 컨텍스트 레이크

에이전트가 최상의 작업을 수행하려면 최고의 컨텍스트가 필요합니다(더 나은 컨텍스트가 더 나은 모델보다 항상 우수하다). 이는 모든 워크플로와 에이전트가 읽을 수 있는 실시간 엔지니어링 시스템 모델을 의미합니다.

이 가이드를 위해 컨텍스트에 포함시켜야 할 세 가지는 다음과 같습니다.

• 서비스(티어(T1/T2/T3), 소유 팀, 레포 링크)
• Port의 기본 통합을 통해 동기화된 GitHub 데이터: 레포, 열린 PR, 최근 커밋, CODEOWNERS
• Jira, Linear, GitHub Issues 등에서 가져온 작업 항목, 해당 서비스와 연결

우리가 곧 구축할 워크플로는 필요에 따라 MCP를 통해 추가 데이터를 끌어올 수 있습니다.

예를 들어, 에이전트가 정확한 기술 사양을 작성하려면 과거 ADR, 런북, Notion이나 Confluence에 있는 이전 사양을 읽고 싶을 수 있습니다.

PRD를 개선하려면 실제 고객 문제와 연결해야 하므로 Zendesk나 Intercom용 MCP도 연결해두면 좋습니다.

Phase 1: Planning

티켓이 생성될 때 전체 워크플로가 시작됩니다. 티켓은 Jira, Linear, 혹은 Port에 있을 수 있습니다.

모든 단계가 동일한 필드에 읽고 쓰도록 generic blueprint(예: work_item)를 만들 것을 권