관측

개인 지라에 가장 먼저 만든 티켓의 제목은 "이슈트래커를 개인 할일관리 소프트웨어로 사용할 수 있는지 알아본다."였습니다. 2020년 8월 15일이고 본문에는 "내 할일을 관리하는데 지라 또는 레드마인을 사용하려고 한다"고 적혀 있습니다. 이 티켓이 그 뒤 6년 동안 쌓인 2만 3천여 건 가운데 첫 번째입니다. 그때는 만드는 문제가 아니라 고르는 문제였습니다. 둘의 비용과 관리 부담을 견줘 본 뒤 지라를 골랐고 그날로 이 티켓을 닫았습니다. 11분 뒤에 만든 다음 티켓은 "이슈트래커를 개인 할일관리에 사용한다."였고 첫 티켓이 그것을 막고 있는 관계로 이어져 있습니다. 고르는 일이 끝나야 쓰는 일이 시작된다는 뜻입니다. 그 뒤로 6년 동안 도구를 다시 고민한 기억이 없습니다. 잘 맞는 도구는 화제에서 사라집니다.

그 6년 이전에는 다른 도구도 시도해 봤습니다. Things는 비싸고 아름다웠으며 Microsoft To Do는 간결했습니다. 둘 다 처음 얼마간은 만족스러웠지만 적극적으로 쓰다 보면 조금씩 아쉬웠습니다. 아쉬움의 정체는 대개 같았습니다. 이 앱이 상정한 사용 방식에서 조금만 벗어나면 그 다음으로 더 나아갈 방법이 아예 제공되지 않는다는 것입니다. 지라는 정반대였습니다. 아쉬운 지점이 생기면 그 지점을 본격적으로 커스텀할 수 있었습니다. 필드를 만들고 워크플로를 고치고 화면 구성을 바꾸고 JQL로 원하는 화면을 만들어냈습니다. 개인이 쓰기에 지나치게 무겁다는 평이 있는 것을 알지만 제 경우에는 그 무거움이 유용했습니다. 지난 '다중 담당자에 의한 지라 설계 철학의 훼손'에서 지라의 설계 철학에 대해 한참 이야기한 적이 있습니다. 그렇게 따질 만큼 이 도구를 개인 영역과 업무 영역 전반에 걸쳐 오랜 시간에 걸쳐 사용했습니다.

이 방식이 더 이상 맞지 않게 된 것은 에이전트를 생활과 업무에 적극적이다 못해 공격적으로 쓰기 시작하면서부터입니다. 지라도 MCP를 지원합니다. 그런데 말도 안 될 정도로 느렸고 에이전트를 통해 쓰기에는 자잘한 곳에서 커스텀이 막혔습니다. 가령 에이전트 실행 결과를 지라 태스크에 별도 필드로 첨부하려고만 해도 상당한 고통이 따랐고 첨부된 로그를 보려고 화면을 커스텀하는 데도 어려움이 있었습니다. 이게 저만 겪는 일인지 궁금해 찾아보니 공개된 기록이 꽤 있었습니다. 아틀라시안 개발자 커뮤니티에는 Rovo MCP 서버에 첨부를 올리는 도구가 아예 없고 본문을 고치면 기존 첨부 노드가 조용히 사라진다는 보고가 올라와 있습니다[^Rovo MCP Server: no attachment-upload tool, and description drops ADF media nodes on edit]. 커스텀 필드는 공식 문서가 "명시적 설정 없이는 인식되거나 반환되지 않을 수 있다"고 적어 두었지만 그 명시적 설정이 무엇인지 물으니 고객지원에 문의하라는 답이 돌아왔고 그대로 미해결로 남았습니다[^Atlassian MCP custom field support]. 느리다는 체감에도 근거가 있었습니다. 공식 저장소에는 응답이 너무 장황해서 작업 항목이 조금만 많아도 컨텍스트 윈도우가 무너진다는 이슈가 있고[^MCP tool responses too verbose - breaks context window for users with many work items] 카드 서른 장쯤 조회하면 곧장 레이트리밋에 걸리지만 언제 풀리는지는 알려 주지 않는다는 보고도 있습니다[^Atlassian MCP Server Rate Limits]. 이 글을 쓰려고 조사하는 동안에도 같은 일을 겪었습니다. 이슈 세 건을 받았습니다. 응답이 14킬로바이트였고 그중 실제로 쓸모 있는 값은 키와 제목과 생성일 셋뿐이었습니다. 나머지는 이슈마다 반복되는 아바타 주소 열두 개와 절대 URL과 내부 식별자였습니다. 필요한 필드만 달라고 명시해도 그 값들은 그대로 따라왔습니다.

여기서 문득 생각해 봤습니다. 지라는 애초에 사람이 사용하도록 만들어진 도구입니다. 이 응답의 대부분을 차지하는 아바타 주소는 사람이 보는 화면을 그리기 위한 것이고 그것이 잘못된 설계라고 말할 수는 없습니다. 그런데 한동안 모든 작업에 에이전트를 쓰는 관점에서는 다른 의문이 생깁니다. 이슈트래커는 과연 인간을 위한 것이어야 할까요. 이슈트래커를 에이전트가 사용한다면 인간을 위한 인터페이스는 불필요합니다. 오히려 인간의 기록 쪽이 부정확하고 또 충분히 세세하지 못합니다. 제가 남기는 한 줄짜리 메모보다 에이전트가 남기는 실행 로그가 훨씬 정확하고 훨씬 자세합니다. 차라리 에이전트가 사용할 이슈트래커가 있으면 좋겠다는 생각이 들었습니다. 찾아보니 이미 누군가 만들어 두었습니다. Beads라는 도구입니다. 소개 문구 첫 줄이 "AI 에이전트를 위한 분산 그래프 이슈트래커"이고 설치 안내가 여러 코딩 에이전트별로 되어 있습니다[^steveyegge/beads]. 처음 생각한 것과 상당히 비슷합니다. 그런데 이번에는 완전히 에이전트를 위한 것이어서 사람이 볼 인터페이스가 아예 없었습니다. 화면을 만드는 일은 이 도구가 맡지 않는다고 소개 문서에 적혀 있습니다. 커뮤니티가 만든 터미널 인터페이스와 웹 인터페이스 목록을 참고하라고 적혀 있을 뿐 코어에는 그런 것이 없습니다. 저 역시 이슈트래커를 보면서 제 일을 해야 하므로 웹 인터페이스가 필요했습니다. 그래서 이 요구사항에 맞는 이슈트래커를 그냥 바닥부터 만들기로 결정했습니다. 기계가 일하는 장소를 만들되 제가 그 안을 관측할 수단을 두는 일입니다. 앞선 도구에는 사람이 관측할 수단이 없었고 지라는 관측 수단만 있었습니다.

이름은 그냥 issue라고 지었습니다. 이전에 space 프로젝트에 이름을 붙일 때와 같은 방식입니다. 지금 와서는 복수형으로 할 걸 그랬나 하는 생각이 듭니다. 이슈 하나를 다루는 도구가 아니라 이슈들을 모아 보는 도구입니다. 만들기 시작한 것은 2026년 8월 2일 23시 56분입니다. 그날 제출한 첫 퍼포스 체인지리스트에는 설계 문서만 있었습니다. 설명에 "코드 변경 없음 — 계획 문서만"이라고 적혀 있고 계획 문서 일곱 편이 전부입니다. 그 문서의 한 줄이 이 도구 전체를 설명합니다. 첫 사용자가 LLM 세션이므로 MCP를 웹보다 먼저 만들고 사람이 보는 웹은 그다음이며 외부 유저 등록은 맨 마지막이라고 적어 두었습니다. 같은 문서의 비목표 항목도 그만큼 중요합니다. "Jira 대체가 아니다. 스프린트, 담당자, 워크플로 커스터마이즈, 권한 매트릭스는 만들지 않는다. 작업자가 LLM 세션 한 명이라 값이 없다." 지라를 6년 쓴 사람이 지라를 다시 만들지 않겠다고 선언하고 시작했습니다. 이 결정이 나중까지 이 도구의 성격을 그대로 두었습니다. 담당자 필드가 없으니 담당자 화면이 필요 없고 스프린트가 없으니 번다운 차트가 필요 없습니다. 사람용 화면에 더 집중하지 않은 이유의 절반은 이 비목표에 있습니다.

여기서부터 8월 8일까지 6일 동안 퍼포스 체인지리스트 361건을 만들었습니다. 날짜별로는 1건, 93건, 91건, 68건, 38건, 34건, 36건입니다. 이 글의 수치는 8월 8일 새벽 4시 13분에 받아 둔 데이터베이스 사본에서 센 값입니다. 통계 화면을 담은 그림과 그 그림에 맞춘 실행 횟수와 총 소요만 같은 날 밤 기준입니다. 기본 구조는 사실상 둘째 날 하루에 다 만들었습니다. 코어와 스키마와 인제스트가 한 건, MCP 도구 열세 개와 웹과 공개용 빌더 한 건, 도커 배포가 한 건입니다. 나머지 358건으로는 그 구조 위에서 뒤늦게 드러난 것들을 계속 고쳤습니다. 이 비율이 이번 작업에서 가장 인상적이었습니다. 만드는 데 하루를 쓰고 동작하게 만드는 데 5일을 썼습니다. 그 5일 동안 테스트를 27건에서 1,264건으로 늘리고 MCP 도구를 13종에서 79종으로 늘렸습니다. 런타임 의존성은 처음부터 끝까지 0입니다. package.json에 dependencies 항목 자체가 없습니다. 노드 내장 SQLite와 표준 라이브러리만 쓰고 MCP 프로토콜도 JSON-RPC를 직접 구현했습니다. 이 선택 하나를 계속 따르느라 나중의 여러 결정을 따로 고민하지 않았습니다. 예를 들어 문서에 다이어그램을 넣기 위해 머메이드를 직접 구현했습니다. 그 근거는 3메가바이트짜리 라이브러리를 넣는 것이 그 결정을 한꺼번에 뒤집는 일이라고 계획 문서에 적어 둔 코드 주석 한 줄이었습니다. 지원할 문법의 범위는 명세서를 따르지 않고 이미 쌓인 문서 마흔 블록에서 실제로 쓰는 빈도에 따라 정했습니다. 코드 하이라이터도 같은 방식이었습니다. 저장된 코드블록 4,700여 개 중 3,852개에 언어 표시가 없다는 것을 세어 보고 언어를 모르면 색을 넣지 않기로 했습니다.

도구를 만든 다음에는 흩어져 있던 문서를 이 도구로 마이그레이션 했습니다. 저장소마다 설계 문서와 이슈 파일이 따로 관리되고 있었습니다. 그것을 Issue 시스템으로 옮기고 저장소에는 "본문은 Issue 시스템에 있다"는 몇 줄짜리 링크만 남겼습니다. 지금 문서 1,717편과 그 버전 2,146개를 Issue 시스템으로 관리하고 저장소 파일은 자동으로 생성되는 사본입니다. 이 작업에서 순서가 중요했습니다. 문서의 버전을 관리하는 기능을 먼저 만들고 그다음에 저장소 파일을 링크로 바꿨습니다. 마지막으로 각 링크 파일을 LLM 진입점 하나로 모았습니다. 이유는 계획 문서에 적어 두었습니다. 지금까지 버전을 관리해 온 것은 P4였지만 링크만 남긴 파일만 남기는 순간 그것마저 끊긴다는 것입니다. 기록할 기능을 먼저 만들어 두라는 의미입니다. 그리고 바로 다음 날 그 버전 덕분에 문서를 되살렸습니다. 링크로 바꿀 대상을 고르는 조건을 좁게 만들어서 아직 옮기지 않은 문서 38편을 링크 몇 줄로 덮어 버렸습니다. 한 프로젝트의 문서 총량이 331,649자에서 34,011자로 줄었습니다. 복구는 두 갈래로 했습니다. 50편은 전날 만들어 둔 첫 번째 버전에서 되살렸고 38편은 퍼포스 히스토리에서 가져왔습니다. 실패는 없었고 복구 기록이 데이터베이스에 11초 사이의 두 종류 흔적으로 남아 있습니다. 이 사고에서 판단 하나를 얻었고 그 뒤로 계속 되새기고 있습니다. 오탐지의 대가는 기록 없음이지만 미탐지의 대가는 전문 소실이므로 탐지 범위는 항상 더 넓게 잡아야 한다는 것입니다.

이런 일이 한 번이 아니었습니다. 이번 작업에서 반복해 나타난 형태는 대체로 같습니다. 테스트를 전부 통과하는 것처럼 보이는 상황에서 사고가 일어났습니다. 저장소와 Issue 시스템의 내용이 같은지 대조하는 기능이 "122건 중 122건 동일"이라고 보고하는 동안 저장소 파일의 상태 값은 전부 엉뚱한 값이었습니다. 원인은 비교에 사용할 목록을 재생성하지 않은 코드 한 줄이었고 그 어댑터를 프로젝트 열여덟 개 중 열여섯 개가 쓰고 있었습니다. 그것을 못 잡는 테스트를 따로 만들어 두었습니다. 대조 함수를 거치지 않고 생성 함수를 직접 불러 확인하게 만들었으니 그 테스트는 처음부터 아무것도 측정하고 있지 않았습니다. 다른 날에는 테스트 907건이 전부 통과했지만 명령줄 도구 네 개는 실행하기만 하면 오류를 내고 멈췄습니다. 이 글에서 하나만 남긴다면 이 대목일 것 같습니다. 검사가 실패하지 않는 것은 문제가 없다는 의미가 아니라 이 검사가 무엇을 확인하는지 점검한 적이 없다는 뜻인 경우가 더 많습니다.

이 도구가 지라와 가장 크게 다른 부분은 에이전트를 실제로 실행하는 부분입니다. 웹에서 이슈를 열고 시작을 누르면 그 이슈를 처리할 에이전트가 실제로 돕니다. 다음에 할 일들도 웹에서 미리 큐에 넣어 둘 수 있습니다. 밤에 처리해 두고 싶은 이슈 여럿을 순서를 정해 큐에 추가해 두면 러너가 하나씩 가져갑니다. 구조에서 마음에 드는 부분은 경계를 나누는 방식입니다. 코드 머리에 이렇게 적어 두었습니다. "웹은 큐에 남기는 것까지만 한다. 실행은 호스트 러너가 집어 간다. 컨테이너에는 p4도 claude도 없고, 그 사실이 곧 안전장치다." 웹 서버가 동작하는 컨테이너 안에는 형상관리 도구도 에이전트 실행 파일도 아예 설치되어 있지 않습니다. 그래서 웹이 공격당해도 웹이 할 수 있는 일은 큐에 한 줄 더 추가하는 것뿐입니다. 큐의 행 식별자는 그대로 에이전트 세션의 식별자로 넘어가서 큐 한 줄과 실행 한 번이 일대일로 대응합니다. 웹에서 일어나는 모든 쓰기는 웹이 직접 하지 않고 MCP 도구를 거쳐 갑니다. 이렇게 한 이유를 기록했습니다. 판정은 도구가 합니다. 웹이 다시 판정하면 결과가 두 개가 되고 둘은 달라질 수 있기 때문입니다.

성공을 판정하는 기준을 다시 정립했습니다. 보통은 프로세스가 0으로 끝났는지를 확인합니다. 여기서는 실행 전후로 그 이슈의 상태를 해시로 만들어 비교하고 이슈의 상태가 실제로 바뀌었는지를 확인합니다. 그래서 상태 어휘에 "변화없음"이라는 항목을 따로 두었습니다. 깨끗하게 성공했지만 아무것도 바뀌지 않은 경우입니다. 실제로 세 번 있었습니다. 세 번을 합쳐 API 요금으로 환산하면 38달러를 썼지만 이슈의 상태는 바뀌지 않았습니다. 이 어휘가 없었다면 그 세 건은 성공 60건에 그대로 포함됐을 것이고 통계는 더 좋아 보였을 것입니다. 지금까지 90번 실행했고 실행 시간을 합치면 81시간 20분입니다. 가장 비싼 작업은 388턴에 걸쳐 진행되었으며 API 요금 환산 56.20달러였습니다. 이 값은 실제 청구액이 아닙니다. 구독제를 사용하기 때문에 달러 환산액은 청구서에 나타나지 않고 그래서 실행을 멈추는 기준으로도 쓸 수 없습니다. 상한은 두 가지 조건에 의해 설정됩니다. 하나는 턴 상한이고 80에서 200으로, 다시 1,000으로 올렸습니다. 이것은 무한 루프를 막는 장치이지 사용량을 막는 장치가 아닙니다. 실제로 사용량을 막는 것은 다른 쪽입니다. 러너가 큐에서 작업을 가져오기 전에 클로드의 사용량 조회 결과를 읽어 5시간 사용률과 주간 사용률을 확인하고, 미리 정해 둔 상한을 넘었으면 다음 이슈를 가져와 작업을 시작하지 않습니다. 상한은 웹 설정 화면에서 정하고 기본값은 둘 다 50퍼센트입니다. 기본값을 절반으로 낮게 둔 이유가 있습니다. 이 관문은 가져오는 시점만 판정하므로 49퍼센트에서 시작한 작업이 5시간 한도를 넘겨서 끝날 수 있고, 남겨 둔 절반이 그 오차를 흡수합니다. 작업 도중에 끊는 방법도 있지만 그것은 하던 일을 반쯤 자르는 것이라 더 나쁩니다. 사용량을 못 읽으면 상한을 넘었는지 알 수 없으므로 그때도 다음 이슈를 가져와 작업을 시작하지 않습니다. 이 관문을 만들기 전에는 러너가 큐에 새 이슈가 있으면 무조건 가져왔고 도구는 토큰 제한을 아예 몰랐습니다. 끝난 뒤에 달러 환산액을 받아 적을 뿐이었으니 주간 한도를 다 쓰고 나서야 알게 되는 구조였습니다. 지금도 달러 환산액을 화면에 표시합니다. 이는 한도 내에서 작동하기 위한 값이 아니라 어느 프로젝트에 얼마가 들었는지 확인하는 값입니다. 그 화면을 만들면서 정한 규칙이 좋았습니다. 실패와 취소와 변화없음을 따로 세고 그 환산액도 같이 표시합니다. 성공한 것만 세면 돈을 쓰고 아무것도 얻지 못한 실행이 통계에서 빠집니다. 평균 옆에 최댓값을 나란히 두는 것도 같은 이유입니다. 턴 상한을 정할 때 참고하는 값은 평균이 아니라 가장 많은 턴을 쓴 한 건입니다.

도구와 수정 작업 사이에 순환이 일어나기도 합니다. 에이전트가 이슈를 처리하면 그 결과를 퍼포스 체인지리스트로 제출하고 Issue 시스템은 형상관리 서버를 스스로 읽어 그 퍼포스 체인지리스트를 다시 Issue 시스템으로 수집합니다. 지금까지 42건의 실행이 퍼포스 체인지리스트 42개를 남겼고 그중 40개가 Issue 시스템으로 되돌아왔고 그 퍼포스 체인지리스트로 이슈 45건이 닫혔습니다. 첫 번째 에이전트 실행이 남긴 제출 설명은 제가 쓰지 않았습니다. 무엇이 잘못돼 있었는지, 무엇을 바꿨는지, 어떻게 검증했는지를 에이전트가 제 규약대로 직접 적었습니다. 그중 한 번은 이 도구의 감시 화면이 서로 모순되는 문장을 동시에 띄우고 있다는 이슈였습니다. 에이전트가 자기 실행을 보여 주는 화면의 결함을 118턴 28.7분 만에 스스로 고쳤습니다.

관측하면서 알게 된 것도 있습니다. 만드는 동안 저는 화면을 보다가 이상한 곳을 발견하면 캡처해서 에이전트에게 신고했습니다. 신고한 것 중 다섯 건은 코드를 실측해 보니 원인이 제가 본 것과 달랐습니다. 가장 마음에 드는 사례는 닫힌 항목에 상태 배지를 붙여 달라고 요청한 건입니다. 배지는 이미 있었습니다. 흐림 값이 0.6으로 지정되어 있어서 테두리 색이 흐려졌고 그래서 배지가 없는 것처럼 보였을 뿐입니다. 다른 하나는 표가 좌우로 너무 길어 가로 스크롤 없이는 다 볼 수 없다고 신고한 건입니다. 원인은 닷새 전에 제가 직접 요청한 "표는 한 줄을 유지하고 넘치면 가로로 스크롤한다"는 규칙이었습니다. 칸이 아홉 개인 표에서는 그 규칙이 화면 폭과 무관하게 언제나 스크롤을 만듭니다. 이 도구의 교훈 문서가 이 현상을 이렇게 정리해 두었습니다. "이슈로 등록해 달라는 말은 받아쓰기 요청이 아니다." 관측한 것과 실제 사실이 다를 수 있고 그 차이를 확인하는 것까지가 신고를 받는 쪽의 일이라는 뜻입니다.

만든 것과 실제로 사용하는 것은 다릅니다. 개인 계정으로 동작하는 에이전트와 업무 계정으로 동작하는 에이전트를 구분해서 프로젝트마다 어느 쪽이 낼지 정하는 기능을 만들었지만 아직 활성화하지 않았습니다. 그 작업의 제출 설명에 제가 직접 적어 두었습니다. "에이전트를 실제로 등록하지 않았다. 등록이 0이면 라우팅은 꺼짐이고 이 변경만으로는 동작이 바뀌지 않는다." 어느 계정이 개인이고 어느 계정이 업무인지는 사람의 결정이고 잘못 설정하면 이슈가 잘못된 계정과 잘못된 맥락으로 처리될 수 있기 때문입니다. 워크스페이스별로 여러 에이전트가 동시에 동작하는 구조도 코드는 만들었지만 실제로 둘째 러너를 띄워 본 기록이 없습니다. 공개용 웹도 만들었지만 프로젝트 스무 개가 전부 내부로 잠겨 있어서 지금 공개 빌드를 실행하면 공개될 이슈는 아직 없습니다. 외부에서 제보를 받는 화면은 아직 404입니다. 이 화면은 이 도구를 만든 두 번째 이유이기도 합니다. 첫 번째 이유가 기계가 주로 사용하고 사람은 주로 관측하는 이슈트래커였다면 두 번째는 이미 공개해 둔 서비스와 도구의 사용자에게서 수정 요청을 직접 받는 것입니다. 이 목적으로 지라를 쓰려면 유료 요금제가 필요해서 부담스러웠고 깃헙 이슈를 쓰자니 제가 형상관리에 주로 퍼포스를 쓰기 때문에 불편했습니다. 그래서 비공개 프로젝트는 비공개대로 관리하고 공개 프로젝트는 공개 프로젝트대로 사용자에게서 수정 요청을 받으려고 했습니다. 그 절반이 아직 남아 있습니다. 퍼포스 저장소의 문서를 링크마저 지우고 완전히 없애는 마지막 단계도 코드만 있고 아직 아무 프로젝트에도 적용하지 않았습니다. 이 글을 쓰는 사이, 그러니까 6일이 지난 다음 날 하루 사이에 그중 셋이 달라졌습니다. 계정을 구분하는 기능은 켜지 않고 지웠습니다. 러너와 그 러너가 맡을 이슈만 있으면 되고 계정을 가르는 층은 필요 없다고 다시 판단했기 때문입니다. 둘째 러너는 실제로 띄웠고 그날 넷까지 늘렸으며 서로 다른 프로젝트의 작업 둘이 동시에 도는 것도 확인했습니다. 퍼포스 저장소의 문서를 완전히 없애는 마지막 단계도 프로젝트 하나에 처음 적용했습니다. 여기까지만 적으면 하루 만에 셋이 정리된 것처럼 읽히는데 그 하루에 제출한 체인지리스트가 88건이고 그중 상당수는 켜고 나서야 안 돌고 있다는 것을 알게 된 기록입니다. 주기 실행을 맡을 백그라운드 작업은 등록된 적이 한 번도 없었고, 내리라고 표시해 둔 러너는 다섯 시간과 열두 시간이 지나도 그대로 떠 있었으며, 끝났다는 보고 한 번을 놓친 탓에 이미 끝난 작업이 큐를 세 시간 가까이 막고 있었습니다. 에이전트를 쓰면 이만큼 빨리 만들 수 있다는 말은 맞습니다. 다만 빨라진 것은 코드를 쓰는 일이지 켜고 운영하는 일이 아닙니다. 6일 만에 361건을 제출한 뒤에도 아직 시작도 못 한 목록이 남아있습니다.

그래서 지라는 어떻게 됐을까요. 업무 티켓을 담아 두던 프로젝트 하나를 Issue 시스템으로 통째로 옮겨 봤습니다. 1,290건이고 그중 98퍼센트가 이미 닫힌 것입니다. 일을 옮긴 것이 아니라 이력을 옮긴 셈입니다. 그러고도 지라를 계속 쓰고 있습니다. 아직 어느 쪽을 주력으로 쓸지 결정하지 못했기 때문입니다. 지라는 수 년을 써서 손에 익었고 그 위에 자동화를 여러 개 만들어 두었습니다. 예를 들어 아웃룩 일정을 읽어 회의 태스크를 만들고 그것을 확인해 제가 미리 회의를 준비하는 흐름은 이미 지라를 중심으로 만들어 두었습니다. 되풀이해서 열리는 회의가 정시에 자동으로 티켓이 되고 그 자동 생성분이 전체의 58퍼센트입니다. 다만 지라 자동화가 더 우세하다고 말하기는 어렵습니다. 새 Issue 시스템은 같은 기능을 외부 자동화 도구를 연결하지 않고 코드로 직접 만들 수 있습니다. 지라에 붙여 둔 자동화를 이쪽의 기본 기능으로 조금씩 흡수해 오다 보면 결국 두 도구가 거의 같아지는 시점이 올 것입니다. 그때가 되면 어느 쪽을 계속 쓸지 확정할 수 있습니다. 에이전트를 자연스럽게 쓰는 환경에서는 목표를 더 올릴 수도 있습니다. 일정을 읽어 회의 티켓을 만들고 제가 그것을 확인해 준비하는 데서 멈추지 않고 에이전트가 일정을 읽어 티켓을 만들고 관련 문서를 읽고 주제를 리서치해서 제가 회의에 들고 갈 문서를 미리 작성하는 데까지 스스로 진행하게 할 수 있습니다. 이것까지 고려하면 지라에서 서서히 벗어날 가능성이 높다고 예상합니다.

지금 이 글의 티켓도 지라에 있습니다. 새로 만든 Issue 시스템에 등록된 프로젝트 스무 개 중에 블로그는 아직 없습니다. 그러니까 이 이야기는 6년 쓴 도구를 버리고 갈아탄 이야기가 아닙니다. 사람이 쓰기 좋게 만들어진 도구는 그대로 두고 기계가 쓸 곳을 옆에 하나 더 만든 이야기에 가깝습니다. 그 장소를 만들면서 관측 수단을 둔 이유도 처음 생각과는 조금 달라졌습니다. 처음에는 제가 일하려면 봐야 하니까 관측 수단이 필요하다고 생각했지만 만들고 보니 관측의 값은 다른 데 있었습니다. 관측하지 않았다면 흐림 값 0.6 때문에 배지가 흐려 보이는 것도, 제가 정한 규칙이 아홉 칸짜리 표에서 어떤 결과를 내는지도 알 방법이 없었을 것입니다. 기계가 읽을 수 있게만 만들면 기계는 불평하지 않습니다. 불평하지 않는다는 것과 잘 돌고 있다는 것은 다른 이야기입니다.

이 도구가 새롭게 6년을 버틸지는 모르겠습니다. 아직 6일 된 도구이고 이슈트래커의 진짜 시험은 1년 뒤에 그 안에 쌓인 기록이 여전히 쓸모 있는가일 텐데 이를 측정하기에는 아직 자료가 충분하지 않습니다. 다만 한 가지는 조금 분명해졌습니다. 이슈트래커가 사람을 위한 것이어야 하느냐는 질문에는 예 아니면 아니오로 답하지 않는 편이 더 잘 맞는 것 같습니다. 기계가 쓰기 좋은 구조를 먼저 만들고 사람은 그 안을 관측할 수단만 있으면 충분한 경우가 꽤 있습니다. 그리고 그 관측은 보기 좋으라고 하는 것이 아니라 안이 어떤지 알아보려고 하는 것입니다. 소프트웨어가 머리를 잃어 간다는 이야기가 요즘 자주 나옵니다[^Is Software Losing Its Head?]. 정작 같은 이슈트래커 업계에서는 사람 화면을 그대로 두고 에이전트를 1급 참여자로 올리자는 정반대 방향도 함께 진행되고 있습니다[^Linear moves sideways to agentic AI as CEO declares issue tracking dead]. 어느 쪽이 맞는지는 아직 모르겠고 당분간은 지라와 이 도구를 나란히 두고 지내 볼 생각입니다. 그럼 이 이야기는 1년쯤 뒤에 다시 꺼내 보겠습니다.