LLMAgent 개발 시 Redmine을 이용한 티켓 관리의 장점과 단점

우치노 코키(内野航希)라고 합니다. 현재 LLMAgent의 태스크 실행을 Redmine으로 관리하는 시스템을 개발하고 있으며, 구성이나 실제 사용감이 참고가 될지도 모른다는 생각에 게시하게 되었습니다. 아직 개발 도중이지만, 실제로 사용해 보니 장점과 단점이 상당히 명확하게 보여서 이번에는 그 구성과 소감을 공유하고자 합니다.

전체적인 구현은 AI에게 맡기고 있으며, 저 자신은 상세 구현에는 관여하지 않았습니다. 그럼에도 불구하고 설계 판단 과정에서 얻은 지견이 누군가에게 참고가 된다면 좋겠습니다.

현재 개발 중인 시스템은 Unity 게임을 LLMAgent에 의해 자동 개발하는 일련의 플로우를 구축하는 것을 최종 목표로 하고 있습니다.

내용
✅ 장점	태스크 관리가 용이 / 역할 분담 가능 / 장애 복구가 쉬움 / 확장하기 쉬움
❌ 단점	티켓 입도(Granularity)에 따라 복잡화 / 저속·무거움 / 데드락(Deadlock) 발생 리스크 / 토큰 소비가 많음

• 사용자로부터 제시된 기획 정보를 바탕으로 초기 태스크를 Redmine 티켓으로 발행한다
• Redmine을 폴링(Polling)하여, Worker가 될 유휴 LLMAgent에 실행 가능한 티켓을 할당한다
• Worker는 처리 완료 후, 자신의 티켓 정보를 업데이트한다

이 구성을 통해 대규모 태스크를 티켓 단위로 분할하여 여러 Worker에게 분산 처리시킬 수 있습니다.

또한, 티켓의 깊이(계층)에 따른 처리 전환도 구현하고 있습니다. 예를 들어 초기 티켓에 대해서는 타이틀·스테이지 셀렉트·인게임과 같은 Unity 씬(Scene) 단위로 서브 티켓을 발행하여, 장면별 정보를 분할하여 관리하고 있습니다.

Redmine은 인간을 위한 티켓 관리 도구이기 때문에, 진행 중(InProgress)·에러(Error)·완료(Resolved)와 같은 상태를 인간이 직접 확인하기 쉽다는 것이 강점입니다.

Redmine을 선정한 이유는 다음 두 가지입니다:

• 무료로 사용할 수 있다
• API가 마련되어 있다

이 두 조건을 만족하는 도구라면 Jira나 Linear 등 다른 티켓 관리 도구로도 대체가 가능할 것이라고 생각합니다. 또한 요구사항이 심플하다면 자체 제작도 선택지에 들어갑니다.

복잡한 개발에서 LLMAgent의 역할을 나누어 각 Agent가 단일 책임(Single Responsibility)을 철저히 지키도록 할 수 있습니다.

게임 개발에서는 관련된 직종이 매우 다양합니다:

• 스크립트 작성
• 기획 정보의 구현 해석
• 2D·3D 에셋(Asset) 생성
• BGM·SE 생성
• Unity 조작

LLMAgent가 대응할 수 없는 태스크(이미지 생성·음악 생성 등)에 대해서는 티켓을 트리거로 외부 생성 API를 호출하는 구성도 고려하고 있습니다. 이 "티켓 → Worker 기동"이라는 완충 단계를 통해 태스크 종류에 따른 티켓 발행이나 필요한 정보의 주입을 유연하게 수행할 수 있습니다.

New·InProgress·Resolved와 같은 상태(Status)를 통해 진척도나 남은 태스크 양을 파악하기 쉽습니다.

폴링이 도중에 정지하더라도 완료된 티켓이 저장되어 있기 때문에, 재기동 후 미완료 태스크부터 처리를 재개할 수 있습니다.

태스크 종류를 추가하고 완충부의 분기 처리 대응 방법을 기술하는 것만으로 새로운 종류의 태스크를 다룰 수 있게 됩니다. 티켓(문자열)이라는 느슨한 결합(Loosely Coupled) 인터페이스를 사이에 두고 있는 것이 확장성의 높이로 이어지고 있다고 느낍니다.

게임 개발 특유의 문제로, "프로그램적으로 옳음 = 게임적으로 옳음"이 아니라는 점이 있습니다. 티켓의 입도나 기술이 부적절하면 "동작만 하는 프로그램 모음"이 되기 쉽습니다.

현재 검토 중인 개선책:

• 5W1H나 개발 배경을 티켓에 포함
• 최종 페이즈에 게임 경험 개선 태스크를 명시적으로 포함

티켓 발행·폴링·신규 Agent 기동이라는 오버헤드(Overhead)로 인해 심플한 구성과 비교하여 처리가 무거워집니다. 스몰한 태스크 관리층을 자체 제작함으로써 개선할 수 있을지도 모릅니다.

에러 발생 시 HotFix 티켓을 재발행하는 플로우를 구성했더니, LLM이 문제를 해결하지 못해 HotFix가 무한 루프를 도는 상태가 발생했습니다.

대책으로서 인간에 의한 확인 플로우(Human-in-the-loop) 도입이 필요하다고 생각합니다. 이는 보안 관점(LLM에 대한 풀 액세스 권한을 주지 않음)에서도 중요합니다.

Worker를 매번 신규로 띄우는 관계로, 동일한 컨텍스트(Context) 정보를 Agent마다 반복해서 읽어들이게 되어 토큰 소비가 늘어납니다. 공유 컨텍스트의 캐시 활용 등이 개선의 여지가 될 것 같습니다.

이상, LLMAgent를 Redmine의 티켓 단위로 관리하는 시스템의 개요와 실제로 느낀 장점·단점의 공유였습니다.

아직 안정적인 출력까지는 도달하지 못했지만, 이러한 구성의 시행착오가 누군가에게 참고가 된다면 기쁘겠습니다. "이런 방법이 있어요", "이 설계는 낭비가 많아요"와 같은 피드백이 있다면, 꼭 댓글로 남겨주시면 큰 도움이 되겠습니다.