코딩 에이전트에게 티켓, PR(Pull Request), 리뷰 댓글을 제공하는 CLI 기반 방식. 왜 이것이 MCP 서버보다 토큰 비용이 적게 드는지, 그리고 기업용 Windows 노트북에 설정했을 때 무엇이 문제가 되었는지.
Adeyemi Tubosun · 2026년 10월 · 10분 분량
문제점: 에이전트는 코드를 작성할 수 있지만, 티켓을 볼 수 없다.
AI 코딩 에이전트들은 이제 코드 작성에 능숙하다. 하지만 대부분은 코드가 왜 작성되는지에는 여전히 맹점을 가지고 있다. 승인 기준(acceptance criteria)은 Jira에 있고, 디자인 노트는 Confluence에 있으며, 리뷰 댓글은 Bitbucket의 풀 리퀘스트에 있다. 따라서 개발자는 자신의 도구와 에이전트 사이에서 복사-붙여넣기 계층 역할을 하게 된다.
나는 Jira와 Bitbucket을 사용하는 팀에 합류한 신입 엔지니어로서 이 문제를 겪었다. 모든 티켓은 같은 루프를 의미했다: Jira 열기, 스토리를 채팅창에 복사, 코드 작성, Bitbucket으로 전환하여 PR 설명을 수동으로 작성하고, 다시 전환하여 리뷰 댓글을 읽고 답변하기.
이 글에서는 Atlassian의 Teamwork Graph CLI (TWG CLI)가 이 루프를 어떻게 닫는지, 왜 그 CLI 기반 설계가 일반적인 Model Context Protocol (MCP) 서버보다 코딩 에이전트에 더 적합한지, 그리고 이를 제한된 기업용 Windows 장치에 설정했을 때 내가 배운 점을 보여준다.
TWG CLI란 무엇인가
TWG CLI는 AI 코딩 에이전트에게 Atlassian 작업 컨텍스트에 접근할 수 있게 해주는 명령줄 도구이다. Atlassian은 이를 에이전트를 위해 후처리된 것이 아니라, 처음부터 에이전트를 염두에 두고 구축되었다고 설명한다 (Atlassian Support).
이는 Atlassian의 사람, 콘텐츠, 활동 및 그들 간의 관계를 담은 지도인 Teamwork Graph 위에 놓여 있다. 이 그래프는 권한을 인지하고 있어(permission-aware), 에이전트는 사용자가 이미 볼 수 있는 것만 보게 된다 (Atlassian Developer).
이것이 다루는 범위:
- Jira: 작업 항목(work items), 보드(boards), 스프린트(sprints), 필터(filters), 전환(transitions), 및 링크
- Confluence: 페이지(pages), 공간(spaces), 데이터베이스(databases), 화이트보드(whiteboards), 검색 기능(search)
- Bitbucket: 저장소(repositories), 풀 리퀘스트(pull requests), 브랜치(branches), 커밋(commits), 및 파이프라인(pipelines)
- 기타: Jira Service Management, Assets, Loom, Trello, Rovo Search, 및 Goals
이는 Claude Code, Codex, Gemini CLI, Cursor 및 셸 명령을 실행할 수 있는 기타 에이전트와 작동합니다. 사용자는 구문을 배울 필요가 없습니다. "열려 있는 Jira 이슈는 무엇인가요?"와 같이 결과(outcome)를 요청하면 에이전트가 필요한 명령어(Atlassian Developer)를 선택합니다.
작성 시점을 기준으로 TWG CLI는 Atlassian의 Early Access Program에 있으며 무료로 사용할 수 있지만, 일부 기능은 나중에 유료화될 수 있다는 점을 참고해야 합니다(Atlassian Support).
단순히 MCP를 사용하지 않는 이유? 컨텍스트 세금(The context tax)
MCP는 에이전트가 표준 인터페이스를 통해 외부 도구를 발견하고 호출할 수 있게 해주는 개방형 프로토콜입니다. Atlassian은 자체 제품인 Rovo MCP Server를 제공하는데, 이는 Jira, Confluence, Jira Service Management, Bitbucket, Compass용 클라우드 호스팅 엔드포인트이며 OAuth 2.1과 사용자의 기존 권한으로 보호됩니다(Atlassian Developer). 이것은 좋은 제품입니다. 문제는 어떤 형태가 코딩 에이전트에 적합한가 하는 것입니다.
코딩 에이전트에게 있어 MCP의 주요 비용은 컨텍스트입니다. 일반적인 MCP 클라이언트는 에이전트가 작업을 수행하기 전에 모든 도구의 이름, 설명 및 입력 스키마를 모델의 컨텍스트 창에 미리 로드합니다 (MindStudio). 대규모 서버는 이를 비용이 많이 들게 만듭니다. 널리 인용되는 예시 중 하나는 GitHub MCP 서버가 첫 번째 작업 전에 약 55,000 토큰 분량의 정의를 추가한다는 것입니다 (Manveer Chawla). Tyk이 보고한 벤치마크에 따르면 MCP는 동등한 CLI 호출 대비 4배에서 32배 많은 토큰을 사용합니다 (Tyk).
CLI는 반대로 작동합니다. 에이전트는 거의 아무것도 로드되지 않은 상태에서 시작합니다. 명령이 필요할 때, 해당 명령어에 대해 --help를 실행하고 몇백 토큰을 읽어옵니다. TWG는 이 점을 활용합니다. 모든 명령은 동일한 패턴을 따르고 모든 레벨에서 도움말(help)을 노출하므로, 에이전트는 진행하면서 기능을 발견할 수 있습니다 (Atlassian Support).
MCP에 공정하게 평가하자면, 클라이언트들이 더 똑똑해지고 있습니다. 예를 들어 Claude Code는 도구 검색 기능을 추가하여 모든 스키마를 한 번에 로드하지 않게 되었습니다 (VideoGen). 격차는 좁혀지고 있지만, 이미 터미널 내에서 작동하는 코딩 에이전트에게는 CLI가 여전히 더 자연스러운 방식입니다.
한눈에 보는 TWG CLI 대 Rovo MCP 서버
두 가지 모두 Atlassian의 권한을 존중합니다. 주요 차이점은 실행 위치와 에이전트에 로드되는 방식입니다.
토큰 소비: TWG가 추가될 때 무엇이 변하는가
TWG를 추가하는 것은 에이전트의 초기 컨텍스트를 거의 변경하지 않지만, MCP 서버는 전체 도구 목록을 모든 세션에 추가합니다. 정확한 차이는 서버와 클라이언트에 따라 다르므로 아래 게시된 수치를 참고 자료로 활용하고 자체 환경에서 측정해야 합니다.
공개된 측정치 분석
| 설정 | 첫 작업 전 로드되는 토큰 | 일반적인 작업을 위한 토큰 | 출처 |
| :--- | :--- | :--- |
| GitHub MCP 서버 (43개 도구) | 약 55,000 | 세션 내내 스키마가 로드됨 | Manveer Chawla |
| ... |
Across equivalent tasks, Scalekit의 벤치마크에 따르면 MCP는 CLI 호출보다 4배에서 최대 32배 많은 토큰을 사용했습니다 (Tyk). 이 수치는 Atlassian에만 국한된 것은 아니지만, 패턴을 보여줍니다.
TWG의 위치
TWG는 스킬(skills)과 CLI를 결합하여 Claude Code에 도달합니다. 스킬은 세션 시작 시 짧은 이름과 설명만 로드하며, 전체 지침은 에이전트가 해당 스킬을 사용하기로 결정할 때 로드됩니다. 이후 에이전트는 실행하려는 명령어에 대한 TWG의 커맨드 도움말만 읽습니다. 따라서 고정 비용은 몇 개의 짧은 스킬 설명이며, 나머지는 작업별로 필요한 양에 비례하여 지불됩니다.
요약하자면, TWG 워크플로우는 일반적으로 동일한 워크플로우를 MCP에서 사용하는 것보다 적은 토큰을 사용합니다. 절감되는 부분은 오버헤드입니다. MCP 서버는 사용 여부와 관계없이 모든 도구 정의를 전체 세션 동안 컨텍스트에 유지하는 반면, TWG는 현재 단계가 필요한 것만 로드하기 때문입니다.
두 가지 유의사항
- 콘텐츠 비용은 어느 쪽이든 동일합니다. 긴 Jira 설명이나 큰 PR diff는 MCP를 통해 오든 TWG를 통해 오든 같은 토큰을 사용합니다. 작업이 주로 큰 티켓이나 diff 읽기에 관한 것이라면, 그 차이는 줄어듭니다.
- 차이가 좁혀지고 있습니다. MCP 클라이언트들은 필요할 때만 도구 정의를 로드하는 도구 검색 기능을 추가하고 있습니다. Claude Code는 이미 이 기능을 수행하며 (VideoGen), MCP의 초기 오버헤드를 많이 제거했습니다.
직접 측정해 보세요
세 번의 새로운 세션에서 동일한 프롬프트를 실행하고 숫자를 기록하세요. Claude Code에서는 /context를 통해 도구 정의를 포함하여 컨텍스트 창이 어떻게 분할되는지 보여줍니다.
- Atlassian 통합 기능 없이 세션을 시작하고
/context를 실행합니다. 이것이 기준선(baseline)입니다.
- Rovo MCP Server를 추가하고, 새 세션을 시작한 다음, 다시
/context를 실행합니다. 그런 다음 “PROJ-1234를 가져와서 승인 기준을 요약해 줘”라고 요청하고, /context를 한 번 더 실행합니다.
- MCP 서버를 제거하고 TWG를 활성화한 다음, 새 세션에서 2단계를 반복합니다.
| 설정 | 시작 시 도구 및 스킬 정의 (토큰) | 가져오기 및 요약 작업 후 총 토큰 (tokens) |
| :--- | :--- |
| 기준선, 통합 없음 | [당신의 숫자] | [당신의 숫자] |
| ... | |
직접 얻은 숫자는 이 섹션을 어떤 벤치마크보다 훨씬 설득력 있게 만듭니다. 만약 고객이 MCP용 도구 검색을 지원한다면 그것도 기록해 두세요. 왜냐하면 그것이 격차를 줄여주기 때문입니다.
매일 달라지는 다섯 가지 워크플로우
TWG가 연결되면, 텍스트를 도구 간에 옮기는 것을 멈추고 결과(outcomes)를 요청하기 시작합니다. 이들이 저에게 가장 큰 차이를 만든 워크플로우들입니다.
- 티켓 가져오기 (Pick up a ticket). "PROJ-1234 티켓을 가져와줘." 에이전트가 스토리와 수용 기준(acceptance criteria)을 읽고, 브랜치를 생성하며, 계획을 제안합니다. 당신은 기억에 의존하는 것이 아니라 실제 요구사항부터 시작할 수 있습니다.
- 한 번에 풀 리퀘스트 열기 (Open a pull request in one step). "PROJ-1234의 커밋, 푸시, 그리고 PR을 열어줘." 에이전트가 티켓과 diff를 기반으로 PR 설명을 작성하여, 설명이 일관성을 유지하고 작업 항목(work item)에 연결되도록 합니다.
- 브라우저 없이 리뷰 피드백 처리하기 (Address review feedback without the browser). "내 PR의 댓글들을 처리해줘." 에이전트가 리뷰어의 메모를 가져와 수정 사항을 만들고, 당신이 확인만 하면 되는 답변 초안까지 작성합니다.
- 코드뿐 아니라 티켓 기준으로 검토하기 (Review against the ticket, not only the code). "PR #193을 검토해줘." 에이전트가 수용 기준과 diff를 비교하여 검사하며, 이는 스타일만 보는 리뷰로는 놓치기 쉬운 '클린 코드는 맞지만 기능은 틀린' 문제를 잡아냅니다.
- 아침 현황 파악하기 (Get a morning view). "내가 처리해야 할 일은 뭐야?" 에이전트가 당신의 스프린트 티켓과 검토를 기다리는 PR들을 결합하여 보여줍니다. 스탠드업 미팅을 위한 좋은 출발점이 됩니다.
핵심 공통점은 이 에이전트가 팀과 동일한 진실 공급원(source of truth)에서 작동한다는 것입니다. 이것이 속도보다 더 중요합니다. 티켓으로부터 생성된 PR 설명은 오후 6시에 기억에 의존해 타이핑하는 것보다 훨씬 정확합니다.
설정하기: 기업 네트워크 환경의 난관 포함
공식적인 설정 과정은 약 10분이 걸립니다. 회사 Windows 노트북에서는 더 오래 걸렸기 때문에, 실제로 작동했던 경로와 예상되는 문제점들을 알려드립니다.
1. 바이너리 설치 (Install the binary)
Windows의 경우, Atlassian의 설치 프로그램은 PowerShell 스크립트입니다 (GitHub의 TWG CLI):
curl.exe -fsSL https://teamwork-graph.atlassian.com/cli/install.ps1 -o "$env:TEMP\twg-install.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\twg-install.ps1" -Yes -SkipLogin -Plugin claude-code
직접 실행하세요. 자동 모드로 실행되는 에이전트는 일반적으로 원격 스크립트를 다운로드하고 실행하는 것을 거부하며, 이는 당연한 반응입니다.
2. 새 터미널 열기 (Open a new terminal)
설치 프로그램은 TWG를 사용자 PATH에 추가하지만 현재 창에서는 인식하지 못합니다. twg --version으로 확인하세요.
3. 계정 및 에이전트 연결
twg setup
twg skills install --agent claude
twg upkeep enable
twg setup은 브라우저 로그인을 실행하고 Atlassian 사이트를 요청합니다. Bitbucket API 토큰을 제공하면 '예'라고 답하세요. 그렇지 않으면 PR 기능이 작동하지 않습니다. 이 토큰은 반드시 TWG의 마스킹된 프롬프트에만 붙여넣고 채팅창에는 절대 붙여넣지 마세요. 두 번째 명령어는 Claude Code가 스킬을 찾는 위치에 TWG의 스킬을 배치합니다. 세 번째 명령어는 백그라운드에서 로그인 상태를 유지합니다.
4. 확인하기
새 에이전트 세션을 시작하고 twg doctor를 실행하도록 요청한 다음, 아는 티켓을 가져오도록 요청하세요. 모든 점검은 통과해야 합니다.
제가 겪었던 문제점들 (Gotchas)
- 바이너리 다운로드 중 설치 프로그램이 멈춥니다. 기업의 HTTPS 검사(inspection)는 대용량 다운로드를 느리게 하거나 중단시킬 수 있습니다.
curl.exe를 사용하여 바이너리를 %LOCALAPPDATA%in wg.exe에 직접 다운로드하고, 해당 폴더를 사용자 PATH에 추가한 다음 2단계부터 계속 진행하세요. 이렇게 하면 설치 프로그램의 플러그인 단계를 건너뛰게 되므로, twg skills install은 절대 건너뛰지 마세요.
- Node 스크립트가 'unable to get local issuer certificate' 오류로 실패합니다. 동일한 HTTPS 검사는 Atlassian API를 호출하는 Node 도구에 문제가 발생하게 합니다. 최신 버전의 Node는
--use-system-ca를 사용하여 Windows 인증서 저장소를 신뢰할 수 있습니다. 구형 버전에서는 신뢰할 루트(trusted roots)를 PEM 파일로 내보내고 NODE_EXTRA_CA_CERTS가 이를 가리키도록 설정하세요. 절대로 NODE_TLS_REJECT_UNAUTHORIZED=0을 설정하지 마세요. 이는 인증서 검사를 완전히 비활성화합니다.
Guardrails: 에이전트가 당신처럼 행동합니다
에이전트가 게시하는 모든 내용은 귀하의 이름으로 표시됩니다: PR, 댓글, 티켓 전환 등. 이를 심각하게 받아들이세요.