AI 에이전트를 한두 개 쓸 때는 대화창만으로도 충분해 보인다. Claude Code에게 코드를 고치라고 하고, 결과를 보고, 다시 수정하면 된다. 하지만 에이전트가 늘어나기 시작하면 문제가 달라진다.
조사 에이전트는 코드를 읽고, 구현 에이전트는 파일을 수정하고, 테스트 에이전트는 실패 로그를 본다. 리뷰 에이전트는 남은 리스크를 지적한다. 사람은 중간중간 방향을 정한다. 이때 가장 먼저 무너지는 것은 모델 성능이 아니라 업무 인수인계다.
누가 무엇을 조사했는지, 어떤 가정을 했는지, 어떤 테스트를 했는지, 왜 이 결정을 했는지, 다음 작업자가 어디서부터 이어가야 하는지가 대화 로그 속에 묻힌다.
그래서 나는 Jira Issue를 AI 에이전트 팀의 공용 작업 객체로 쓰는 방식을 고민하기 시작했다.
대화 로그는 작업 시스템이 아니다
에이전트 대화 로그는 자세하다. 하지만 자세하다는 것과 업무 시스템으로 적합하다는 것은 다르다.
대화 로그의 문제는 다음과 같다.
- 너무 길어서 사람이 다시 읽기 어렵다.
- 에이전트별 컨텍스트가 분리된다.
- 조사 결과와 잡담, 실패한 시도, 최종 결정이 섞인다.
- 테스트 결과가 어디 있는지 찾기 어렵다.
- 다음 에이전트가 같은 조사를 반복한다.
- 작업 상태가 명확하지 않다.
특히 여러 에이전트를 쓰면 이 문제가 심해진다. 각 에이전트는 자기 세션 안에서는 맥락을 잘 이해한다. 하지만 다음 에이전트가 같은 맥락을 갖고 시작한다는 보장은 없다.
필요했던 것은 더 긴 채팅 로그가 아니었다. 작업 단위별로 목표, 상태, 조사, 결정, 테스트, 결과가 쌓이는 공용 객체가 필요했다.
왜 Jira Issue인가
새로운 에이전트 전용 업무 시스템을 만들 수도 있다. 하지만 현실적으로 좋은 선택은 아니다. 사람이 이미 쓰는 시스템 밖에 별도 시스템을 만들면 결국 동기화 비용이 생긴다.
Jira는 이미 사내 업무 요청의 단위다. 담당자, 상태, 우선순위, 라벨, 댓글, 첨부, 링크, 히스토리가 있다. 사람도 익숙하다. 에이전트가 여기에 들어오면 새 시스템을 강요하지 않고 기존 업무 흐름 안에서 작동할 수 있다.
Jira Issue는 다음 역할을 할 수 있다.
- 업무 요청서
- 요구사항 원본
- 조사 결과 저장소
- 결정 기록
- 테스트 결과 로그
- 다음 에이전트를 위한 handoff 문서
- 사람 리뷰어를 위한 요약 보고서
중요한 것은 Jira를 단순 티켓 관리 도구로 보지 않는 것이다. AI 에이전트 시대에는 Jira Issue가 사람과 에이전트가 함께 읽고 쓰는 작업 계약서가 될 수 있다.
에이전트는 직접 대화하지 않아도 된다
처음에는 에이전트끼리 직접 대화하게 만들면 좋을 것 같았다. 조사 에이전트가 구현 에이전트에게 결과를 말하고, 구현 에이전트가 테스트 에이전트에게 넘기는 식이다.
하지만 운영 관점에서는 직접 대화보다 Jira를 통한 비동기 인수인계가 낫다.
Research Agent → Jira Comment: 조사 결과
Implementation Agent → Jira Comment: 구현 요약
Test Agent → Jira Comment: 테스트 결과
Review Agent → Jira Comment: 리스크와 리뷰
Human Owner → Jira Status: 승인 또는 반려
이 방식의 장점은 명확하다.
첫째, 사람이 중간에 들어와도 맥락을 볼 수 있다. 둘째, 에이전트가 바뀌어도 기록이 남는다. 셋째, 나중에 비슷한 이슈를 처리할 때 과거 결정을 검색할 수 있다.
에이전트 팀 운영에서 중요한 것은 에이전트끼리 실시간으로 떠드는 것이 아니었다. 중요한 것은 작업의 결과와 판단 근거가 조직의 업무 시스템 안에 남는 것이다.
Jira Issue 템플릿
에이전트가 읽고 쓰기 좋은 Jira Issue는 일반적인 사람용 이슈보다 조금 더 구조적이어야 한다.
내가 생각한 기본 템플릿은 다음과 같다.
## 목표
이 이슈에서 해결해야 하는 문제
## 배경
왜 이 작업이 필요한지
## 요구사항
- 명시 요구사항
- 제약 조건
- 완료 기준
## 조사 결과
- 확인한 코드/문서/로그
- 중요한 발견
- 아직 불확실한 점
## 실행 계획
- Step 1
- Step 2
- Step 3
## 테스트 결과
- 실행한 명령
- 성공/실패 결과
- 실패 원인
- 재현 방법
## 결정 사항
- 선택한 접근
- 버린 대안
- 트레이드오프
## 다음 작업자에게
- 이어서 봐야 할 파일
- 주의할 점
- 남은 작업
이 템플릿은 완벽하지 않다. 너무 길면 사람이 안 쓴다. 하지만 에이전트가 작업을 이어받기에는 이런 구조가 훨씬 낫다.
핵심은 모든 이슈를 거대한 문서로 만들자는 것이 아니다. 최소한 목표, 완료 기준, 조사 결과, 테스트 결과, 다음 작업자에게 남길 내용을 구분하자는 것이다.
역할 분리
Jira를 중심에 두면 에이전트 역할도 자연스럽게 나눌 수 있다.
Research Agent는 관련 코드와 과거 이슈를 조사하고, 조사 결과를 Jira에 남긴다. Implementation Agent는 이슈와 조사 결과를 읽고 구현한다. Test Agent는 테스트를 실행하고 재현 가능한 로그를 남긴다. Review Agent는 변경 사항과 Jira 기록을 함께 보고 누락된 리스크를 지적한다.
사람의 역할도 바뀐다. 사람이 모든 세부 로그를 읽는 것이 아니라, Jira Issue에 정리된 목표, 결정, 테스트 결과, 남은 리스크를 보고 승인하거나 방향을 수정한다.
이 구조에서는 에이전트가 사람을 대체한다기보다, 사람이 검토할 수 있는 형태로 일을 남기는 것이 중요하다.
기대 효과
정량 측정은 아직 부족하다. 하지만 이 방식에서 기대하는 효과는 분명하다.
- 같은 조사를 반복하는 일이 줄어든다.
- 다음 에이전트가 어디서부터 시작할지 명확해진다.
- 테스트 결과 누락이 줄어든다.
- 사람이 리뷰할 때 맥락 파악 시간이 줄어든다.
- 과거 이슈에서 해결 패턴을 재사용할 수 있다.
가장 큰 변화는 작업의 기억이 대화창이 아니라 Jira에 남는다는 점이다. 대화창은 세션이 끝나면 휘발된다. Jira Issue는 조직의 기억으로 남는다.
한계와 주의점
물론 Jira를 에이전트 로그 저장소처럼 쓰는 것에는 위험도 있다.
- 댓글이 너무 길어질 수 있다.
- 에이전트가 중복 댓글을 남길 수 있다.
- 상태 전환을 잘못하면 workflow가 꼬인다.
- 민감 정보가 댓글에 남을 수 있다.
- Jira API 제한이나 속도가 병목이 될 수 있다.
- 템플릿이 너무 빡빡하면 사람이 쓰지 않는다.
특히 보안은 중요하다. Jira comment에 .env, API token, Slack webhook URL, 고객 개인정보, 내부 장애 로그 원문을 그대로 붙이면 안 된다. 에이전트가 자동으로 기록을 남기는 만큼 redaction과 preview가 필요하다.
결론
AI 에이전트 팀 운영에서 중요한 것은 더 똑똑한 모델만이 아니었다. 여러 에이전트가 같은 업무를 이어받고, 사람이 중간에 검토하고, 과거 작업을 다시 찾을 수 있는 업무 인터페이스가 필요했다.
Jira Issue는 그 역할을 하기에 현실적인 선택이다. 새 시스템을 만들지 않고, 사람이 이미 쓰는 업무 시스템 안에 에이전트를 들어오게 할 수 있기 때문이다.
다음 글에서는 이 생각을 Claude Code 플러그인으로 옮길 때 어떤 인터페이스가 필요한지 정리해보겠다.