지금 바로 "ai agents를 위한 이슈 트래커 (issue tracker for ai agents)"를 검색해 보면 결과물은 거의 모두 한 가지 형태입니다. 즉, 리포지토리(repo) 내에 존재하며, 로컬 데이터베이스(local database)에 작업을 저장하고, 컨텍스트 윈도우 (context window)가 가득 찼을 때 단일 코딩 에이전트 (coding agent)가 자신이 무엇을 하고 있었는지 잊어버리는 것을 방지하기 위해 존재하는 소규모의 git 네이티브 트래커 (git-native tracker)입니다. Beads는 모두가 링크를 거는 도구입니다. Trekker와 수십 개의 Show HN 클론(clones)들도 같은 아이디어입니다. 이들은 좋은 도구이며 실제 문제를 해결합니다. 즉, 긴 작업을 수행하는 에이전트는 자신의 메모리 (memory)가 초기화되기 때문에, 남은 작업을 기록할 수 있는 내구성 있는 장소가 필요합니다.

이것은 단일 에이전트 버전의 작업입니다. 이 포스트는 에이전트가 둘 이상이 되거나, 동일한 목록을 확인해야 하는 사람이 나타나는 순간 발생하는 버전에 관한 것입니다. 그 시점에는 한 사람의 리포지토리에 있는 로컬 파일만으로는 충분하지 않으며, 트래커는 팀 전체와 에이전트 함대 (fleet of agents) 전체가 동시에 운용할 수 있는 무언가가 되어야 합니다.

로컬 트래커가 제대로 수행하는 작업

에이전트에게 읽고 쓸 수 있는 작업 목록 (task list)을 주면 두 가지가 즉시 개선됩니다: 집중력 (focus)과 연속성 (continuity)입니다. 집중력은 에이전트가 긴 프롬프트 (prompt)로부터 다음 항목을 다시 유도하는 대신 다음 항목을 읽기 때문에 향상됩니다. 연속성은 세션 (session)이 종료될 때 상태 (state)가 기록되므로, 다음 세션이 처음부터 시작하는 대신 마지막에 멈춘 지점부터 다시 시작할 수 있기 때문에 향상됩니다.

r/ClaudeCode의 한 개발자는 그 어떤 제품 페이지보다 이 루프 (loop)를 더 잘 설명했습니다:

"티켓팅 시스템 (ticketing system)에 백로그 항목 (backlog items)을 생성한 다음, 세미 워터폴 (semi waterfall)과 애자일 (agile) 프로세스가 결합된 방식으로 단계별로 진행하게 합니다. 계획을 위해 초기에 컨텍스트 (context)를 사용할 수 있고, 그 후에는 여러 에이전트를 사용하거나 자리를 비워야 할 때 다시 이어서 실행할 수 있습니다."

마지막 절이 핵심입니다. 사전에 계획을 세우고, 백로그 (backlog)를 에이전트에게 넘긴 뒤, 자리를 비웠다가 다시 돌아와서 이어서 할 수 있어야 합니다. 트래커는 당신이 멈춘 지점이자 다시 돌아올 지점입니다. 로컬 git 트래커는 한 대의 머신에서 한 명의 에이전트를 위해 이 역할을 수행합니다. 이는 진정으로 유용하며, 만약 당신의 설정이 그것이 전부라면 다른 것은 필요하지 않을 수도 있습니다.

로컬 기록의 확장성이 한계에 다다르는 지점

기록을 읽어야 하는 주체가 한 명 이상이 되는 시점부터 마찰이 시작됩니다.

두세 개의 에이전트를 병렬로 실행하면, 한 클론(clone)에 있는 파일은 다른 에이전트들에게 보이지 않습니다. 팀원을 추가하더라도, 그 팀원은 당신의 브랜치를 가져오지(pull) 않는 한 당신의 에이전트가 기록한 내용을 볼 수 없습니다. 일주일 뒤에 돌아왔을 때, 종료된 작업의 "이유"는 오직 당신의 기기에만 있는 데이터베이스 속에 묻혀버립니다. 단일 에이전트용 메모리 도구는 애초에 공유된 기록 시스템 (system of record)이 되도록 설계되지 않았으므로, 워크플로우가 확장되었다고 해서 저절로 공유 시스템이 되지는 않습니다.

에이전트를 운용하는 팀에게 실제로 필요한 기록은 다음과 같습니다:

• 로컬이 아닌 호스팅 방식 (Hosted, not local). 클론마다 복사본을 만드는 것이 아니라, 모든 에이전트와 모든 사람이 접근하는 하나의 정전(canonical) 목록이 있어야 합니다.
• 기계와 사람이 동일한 곳에서 제어 가능할 것. 에이전트는 API를 통해 이슈를 기록하고, 사람은 1초 뒤에 보드에서 이를 확인합니다. 동일한 기록을 두 가지 인터페이스로 사용하는 것입니다.
• 자리를 비웠을 때도 읽기 쉬울 것. 단순히 "여기에 작업이 있다"는 것뿐만 아니라, 당신이 없는 동안 어떤 일이 일어났는지 알려주는 댓글과 활동 기록 (activity trail)이 있어야 하여, 작업 재개가 실질적으로 가능해야 합니다.

Radial은 바로 그러한 버전을 위해 구축되었습니다. Radial은 호스팅되는 이슈 트래커 (issue tracker)이므로, 당신이 읽든, 팀원이 읽든, 혹은 오늘 아침에 새로 띄운 네 번째 에이전트가 읽든 목록은 동일합니다. Radial은 빠르고, 트래커이며, 오직 트래커로서의 기능에 충실합니다. 또한 보드를 클릭하는 사람과 API를 호출하는 에이전트에게 동일한 동사(verbs)를 노출합니다.

에이전트를 통한 제어

에이전트는 트래커의 기본적인 동사들을 사용하여 MCP 또는 CLI를 통해 Radial을 제어합니다. 다음은 터미널을 통한 작업 재개 루프 (pick-up loop) 예시입니다. 업무에 복귀한 에이전트가 자신에게 할당되었거나 진행 중인 작업을 나열한 다음, 가장 상위 이슈의 활동 기록을 읽어 지난 세션이 어디에서 멈췄는지 확인하는 과정입니다.

radial list --assignee me --status "in progress" --json
radial activity RAD-219 --json

첫 번째 호출은 에이전트가 파싱할 수 있는 JSON 형식으로 답변되는 "내가 무엇을 하고 있는가"에 대한 질문입니다. 두 번째는 작업 시작 지점입니다: activity는 이슈의 히스토리, 댓글, 상태 변경 사항 등을 모두 반환하므로, 작업을 수행하는 에이전트는 추측하는 대신 이미 발생한 일들을 읽게 됩니다. 작업이 완료되면 에이전트는 메모와 함께 이슈를 종료하며, 다음 읽는 사람(사람 또는 에이전트)은 동일한 기록을 보게 됩니다.

MCP (Model Context Protocol)를 통해 동일한 루프가 mcp.radial.build에 호스팅된 서버를 대상으로 search_issues, list_issues, comment, close_issue를 사용합니다. 따라서 Claude Code나 Codex 내부의 에이전트는 자신의 도구 루프(tool loop) 내에서 공유된 리스트를 읽고 쓸 수 있습니다. Claude Code MCP 워크스루에서는 이를 약 5분 만에 연결하는 방법을 다룹니다.

정직함을 유지하는 부분

이 제품의 핵심이기에 두 가지 정직한 노트를 남깁니다.

첫째, Radial은 로컬 환경을 제공한다는 점에서 로컬 git 트래커와 경쟁하지 않습니다. 이는 클라우드 호스팅 방식입니다. 만약 당신의 모든 요구사항이 단일 리포지토리 내에서 한 에이전트의 개인적인 메모일 뿐이며, 그것이 기기를 절대 벗어나지 않기를 원한다면 git 네이티브 도구가 올바른 선택이며, 저희도 그렇게 말씀드릴 것입니다. Radial의 가치는 기록을 공유해야 할 때, 즉 여러 에이전트, 여러 사람이 하나의 리스트를 사용할 때 발휘됩니다.

둘째, 지능은 여전히 당신의 것입니다. Radial은 에이전트가 빠르게 기록하는 장소이지, 더 똑똑한 트래커가 아닙니다. 제품 내에 코파일럿 (copilot)도, AI 요약도, 자동 분류 (auto-triage)도, AI 크레딧 미터 (AI credit meter)도 없습니다. 왜냐하면 당신의 에이전트가 이미 사고를 수행하고 있으며, 당신은 이미 그 비용을 한 번 지불했기 때문입니다. 당신이 연결하는 모든 에이전트 자격 증명 (credential)은 API, CLI, 그리고 MCP 서버의 클라이언트이며, 에이전트 자격 증명은 과금 대상 시트(billed seats)로 계산되지 않습니다. 워크스페이스의 사람들에 대해서는 가입 시 정해진 요율로 사용자당 연간 50달러를 고정하여 지불합니다. 해당 기록을 대상으로 10개의 에이전트를 가동하더라도 가격은 변하지 않습니다. 이것이 Plain Software의 약속 (Plain Software Pledge)입니다: 저희가 코파일럿을 출시하거나, 사용량을 측정하거나, 당신이 요청하지 않은 AI에 대해 비용을 청구하는 날, 당신의 구독은 무료가 됩니다.

FAQ

AI 에이전트를 위한 최고의 이슈 트래커는 무엇인가요?

얼마나 많은 에이전트와 인간이 기록을 공유하느냐에 따라 달라집니다. 작업 도중 맥락을 놓치지 않도록 프라이빗한 저장소 내 메모리(in-repo memory)가 필요한 단일 코딩 에이전트의 경우에는 Beads와 같은 git-native 로컬 트래커가 적합합니다. 반면, 인간과 함께 여러 에이전트를 운용하며 모두가 동일한 목록을 공유해야 하는 팀의 경우에는 에이전트가 API, CLI, 그리고 MCP를 통해 제어할 수 있는 호스팅형 트래커가 필요하며, 이것이 바로 Radial이 메우고 있는 격차입니다.

Radial은 Beads와 어떻게 다른가요?

Beads는 로컬, git-native 트래커입니다. 작업(task)을 저장소 내부의 데이터베이스에 저장하며, 주로 단일 코딩 에이전트가 컨텍스트 리셋(context reset) 상황에서도 지속적인 메모리를 유지할 수 있도록 하는 데 존재합니다. Radial은 호스팅형, 다중 사용자 트래커입니다. 워크스페이스의 모든 인간과 모든 에이전트가 읽고 쓰는 하나의 정식 목록(canonical list)을 제공하며, 사람을 위한 보드와 기계를 위한 API, CLI, 그리고 MCP 서버를 갖추고 있습니다. 용도가 다릅니다. 단일 에이전트를 위한 로컬 메모리냐, 아니면 팀과 그 팀의 에이전트 군단(fleet)을 위한 공유 기록 시스템(system of record)이냐의 차이입니다.

AI 에이전트가 스스로 이슈를 생성하고 종료할 수 있나요?

네, 가능합니다. 에이전트는 사람이 사용하는 것과 동일한 동사를 사용하여 CLI(radial create, radial list, radial close), REST API, 또는 MCP 서버를 통해 Radial을 제어합니다. 에이전트는 작업 도중 발견한 이슈를 등록하고, 자신에게 할당된 항목을 나열하며, 이슈의 활동 기록(activity trail)을 읽어 마지막 세션이 어디서 멈췄는지 확인하고, 작업이 완료되면 코멘트와 함께 이슈를 종료할 수 있습니다. 이 모든 과정은 인간의 중개 없이 이루어집니다.

에이전트를 더 많이 추가하면 비용이 더 많이 드나요?

아니요. 에이전트 자격 증명(credentials)은 API의 클라이언트일 뿐, 과금 대상인 시트(seat)가 아닙니다. 워크스페이스에 있는 인간에 대해 사용자당 연간 50달러를 지불하며, 이 금액은 가입 시점의 요율로 고정됩니다. 에이전트를 한 대를 연결하든 열 대를 연결하든 가격은 동일합니다. 제품 어디에도 AI 크레딧 미터(credit meter)는 존재하지 않습니다.

제가 자리를 비운 뒤에 에이전트는 어떻게 작업을 "다시 이어가나요?"

기록을 읽음으로써 가능합니다. 당신이 돌아왔을 때, 에이전트는 현재 진행 중인 사항을 나열하고 해당 이슈의 활동 이력(activity history)을 읽습니다. 이 이력에는 이전 세션의 댓글과 상태 변경 사항이 포함되어 있습니다. 그 흔적이 바로 인수인계(handoff) 역할을 합니다. 복귀한 에이전트나 팀원은 아무 정보 없이 처음부터 시작하는 대신 이미 일어난 일들을 확인하게 됩니다. 이는 로컬 트래커(local tracker)가 단일 에이전트에게 제공하던 연속성(continuity)을 공유되고 호스팅되는 버전으로 구현한 것입니다.

요약 버전

로컬 트래커는 단일 에이전트에게 메모리(memory)를 제공했으며, 이는 실질적인 해결책이었습니다. 다음 문제는 팀 단위의 문제입니다. 여러 에이전트와 여러 인간이 모두 접근 가능한 곳에 호스팅되어, 자리를 비웠다 돌아와도 읽을 수 있는 동일한 기록을 운용해야 합니다. 그것이 바로 당신의 에이전트가 실제로 운용할 수 있는 트래커이며, Radial이 존재하는 이유입니다.

개발자(developers) 페이지에서 에이전트를 연결하거나, 만약 반대 의견을 다투는 스레드를 통해 이곳에 오셨다면 왜 저희가 이슈 트래킹이 죽지 않았다고(issue tracking isn't dead) 생각하는지 읽어보시기 바랍니다.

원문은 Radial 블로그(Radial blog)에 게시되었습니다.