MCP와 Temporal을 활용한 에이전트 기반 Jira 자동화 플랫폼 구축

대부분의 "AI 자동화 (AI automation)" 데모는 워크플로 (workflow)가 단일 요청보다 길게 실행되어야 하는 순간 무너집니다. 에이전트 (agent)가 몇 번의 도구 호출 (tool calls)을 수행하면, 프로세스가 충돌하거나 타임아웃 (timeout)이 발생하여 모든 상태 (state)를 잃게 됩니다. 저는 Atlassian (Jira 및 Confluence) 내부에서 실제 다단계 작업을 수행할 수 있고, 재시작, 재시도(retries), 그리고 실패를 견뎌낼 수 있는 무언가를 원했습니다. 그래서 저는 두 가지 아이디어를 중심으로 오픈 소스 플랫폼을 구축했습니다: 도구 접근을 위한 MCP와 내구성이 있는 실행 (durable execution)을 위한 Temporal입니다.

Repo: https://github.com/ahmet-ozel/atlassian-ai-workflow-platform

원샷 에이전트 (one-shot agents)의 문제점

전형적인 에이전트 루프 (agent loop)는 다음과 같습니다: 티켓을 읽고, 행동을 결정하고, 도구를 호출하고, 이를 반복합니다. 이는 짧은 작업에는 괜찮습니다. 하지만 워크플로가 몇 분 또는 몇 시간 동안 지속되거나, 간헐적으로 실패하는 외부 시스템에 의존하거나, 배포 (deploy) 후에 재개되어야 하는 경우에는 무너집니다. 만약 오케스트레이션 (orchestration)이 단일 Python 프로세스 내에서 실행된다면, 어떤 충돌이든 발생했을 때 처음부터 다시 시작해야 함을 의미합니다. 실제 Jira 이슈를 다루는 비즈니스 워크플로에서 이는 용납될 수 없습니다.

도구로서 MCP를 사용하는 이유

Model Context Protocol (MCP)은 에이전트가 도구를 발견하고 호출하는 방식을 표준화합니다. 에이전트에 Jira API 호출을 하드코딩 (hard-coding)하는 대신, 저는 Jira와 Confluence를 MCP 도구로 노출합니다. 에이전트는 깔끔하고 타입이 지정된 도구 인터페이스 (create issue, transition status, search, comment, fetch a Confluence page)를 보게 되며, 프로토콜이 연결을 처리합니다.

실질적인 이점은 디커플링 (decoupling, 결합도 낮추기)입니다. 에이전트 로직을 건드리지 않고도 도구를 추가하거나 변경할 수 있으며, 동일한 도구가 모든 MCP 호환 클라이언트 (MCP-compatible client)에서 작동합니다. 또한 에이전트 프롬프트 (prompt)가 API 메커니즘보다는 의도 (intent)에 집중할 수 있게 해줍니다.

오케스트레이션을 위해 Temporal을 사용하는 이유

Temporal은 내구성이 있는 워크플로 (durable workflows)를 제공합니다. 워크플로 코드는 일반적인 Python처럼 보이지만, 모든 단계가 체크포인트 (checkpointed)로 저장됩니다. 만약 워커 (worker)가 중단되면, 워크플로는 다른 워커에서 마지막으로 완료된 단계부터 재개됩니다. 재시도 (retries), 타임아웃 (timeouts), 그리고 백오프 (backoff)는 선언적 (declarative)으로 처리됩니다.

이는 에이전트 워크플로 (agent workflows)에 완벽하게 매핑됩니다. 각각의 LLM 호출과 각 도구 호출 (tool call)은 하나의 Temporal 액티비티 (activity)가 됩니다. 만약 LLM 제공업체가 속도 제한 (rate-limit)을 걸거나 Jira 호출이 실패하더라도, Temporal은 전체 추론 체인 (reasoning chain)을 다시 실행하는 대신 해당 단일 액티비티만을 재시도 (retry)합니다. 장시간 소요되는 승인 프로세스 (티켓 상태를 전환하기 전 사람이 검토할 때까지 대기하는 과정) 또한 편법이 아닌 워크플로의 정상적인 일부가 됩니다.

트레이드오프 (tradeoff)는 추가적인 인프라입니다. Temporal은 실행해야 할 서비스가 하나 더 늘어나는 것이며, 부수 효과 (side-effect)를 일으키는 액티비티 (activities)와 결정론적 (deterministic)인 워크플로 코드 사이의 차이를 고려해야 합니다. 짧고 상태가 없는 (stateless) 작업에는 과할 수 있습니다. 하지만 신뢰성이 반드시 필요한 작업이라면, 그 가치는 빠르게 증명됩니다.

아키텍처 (Architecture)

이 스택은 몇 가지 구성 요소를 결합합니다:

에이전트에게 Atlassian 도구들을 노출하는 MCP 통합 레이어 (integration layer)
내구성이 있는 워크플로 (durable workflows)와 액티비티를 실행하는 Temporal 워커 (workers)
Jira 이벤트를 워크플로 트리거 (trigger)로 변환하는 웹훅 게이트웨이 (webhook gateway)
워크플로를 실행하고 검사하기 위한 관리자 대시보드 및 Streamlit UI
멀티 프로바이더 LLM 지원 (OpenAI, Anthropic, Gemini, 그리고 자체 호스팅되는 vLLM)

모든 것은 단일 Docker Compose 스택에서 실행되므로, 전체 시스템을 로컬에서 구동하고 움직이는 구성 요소들을 함께 확인할 수 있습니다. 제공업체 선택은 설정 (config) 기반이므로, 개발 중에 호스팅된 모델을 로컬 모델로 쉽게 교체할 수 있습니다.

배운 점

"무엇을 할 것인가"와 "그 일을 수행하며 어떻게 생존할 것인가"를 분리하는 것이 핵심적인 통찰이었습니다. 에이전트는 의도 (intent)에 대해 추론하고 도구를 선택합니다. Temporal은 신뢰성 (reliability)을 담당합니다. MCP는 도구의 경계 (tool boundary)를 담당합니다. 이 세 가지 책임을 분리함으로써 각각을 추론하고 테스트하기가 훨씬 단순해졌습니다.

또 다른 교훈은 결정론적 (deterministic)인 워크플로 코드는 하나의 규율 (discipline)이라는 점입니다. 비결정론적인 모든 것 (네트워크 호출, 타임스탬프, 난수 등)은 워크플로 본문이 아닌 액티비티 (activity) 내에 존재해야 합니다. 이 점을 깨닫고 나니 디버깅이 훨씬 쉬워졌습니다. 워크플로 히스토리 (workflow history)가 발생한 일에 대한 정확하고 재현 가능한 로그 (log)이기 때문입니다.

현재는 Atlassian을 대상으로 하고 있지만, 도구 계층 (tool layer)은 다른 플랫폼으로 확장할 수 있도록 설계되었습니다.

피드백 환영

다른 분들은 장기 실행 에이전트 워크플로 (long-running agent workflows)를 어떻게 처리하고 계신지 듣고 싶습니다. Temporal을 사용하시나요, 아니면 큐 (queue)와 자체 상태 머신 (state machine)을 사용하시나요, 혹은 커스텀 오케스트레이션 루프 (custom orchestration loop)를 사용하시나요? 그리고 MCP 사용자분들께 질문드립니다. 하나의 에이전트가 동시에 여러 시스템에 접근해야 할 때 도구 (tools)를 어떻게 구조화하고 계신가요?

리포지토리 (Repo) 및 설정 안내: https://github.com/ahmet-ozel/atlassian-ai-workflow-platform