같은 코드베이스에서 여러 AI 코딩 에이전트를 운영하고 있다. 3개일 수도, 13개일 수도 있다. 각 에이전트는 자신의 작업을 추적해야 한다. 이슈 생성, 상태 업데이트, 의존성 확인, 진행 보고. 플릿 전체에서 분당 수십 건의 쓰기가 발생한다.
이것이 agentic engineering이다. 인간이 AI 에이전트 플릿을 조율해 소프트웨어를 출시하는 워크플로우. 새로운 방식이지만, 누구나 가장 먼저 손이 가는 건 이미 알고 있는 도구다. Jira. Linear. GitHub Issues. Notion. 팀에서 쓰는 프로젝트 관리 도구.
그건 작동하지 않는다. 그리고 이 불일치는 표면적인 게 아니다. 아키텍처 수준의 문제다.
레이턴시가 처리량을 죽인다
Jira API 호출에는 200800ms가 걸린다. Linear API는 더 빠르지만 여전히 100300ms다. 이슈 하나를 생성하고, 의존성을 읽고, 상태를 업데이트하면 HTTPS, DNS 해석, TLS 핸드셰이크, JSON 직렬화를 거치는 3번의 라운드 트립이다. 좋은 날 기준으로 500ms.
로컬 CLI에서 SQLite 데이터베이스에 쓰는 건 50ms 미만. 대부분 10ms 이하.
반올림 오차처럼 들리지만, 작업 수를 곱하면 이야기가 달라진다. 에이전트가 태스크를 처리하면서 서브 이슈 2~3개를 만들고, 부모 상태를 업데이트하고, 블로커를 확인하고, 진행 상황을 코멘트할 수 있다. 6번의 작업. 각 500ms면 3초의 순수 대기 시간. 각 10ms면 60밀리초. 30초면 태스크 사이클을 마칠 수 있는 에이전트가 그 시간의 10%를 코드 대신 HTTP 대기에 쓰게 된다.
이걸 13개 에이전트로 확장하면 오버헤드는 시간당 수 분 단위가 된다.
인증 인프라는 취약한 접착제
모든 에이전트에 API 토큰이 필요하다. 토큰은 만료된다. 레이트 리밋이 있다. 한 에이전트가 20건의 연속 업데이트를 쏟아내면 429 Too Many Requests가 돌아온다. 그러면 제 할 일 대신 지수 백오프 재시도 루프에 빠진다.
작업 자체와는 전혀 관계없는 장애 모드를 통째로 추가한 셈이다. 토큰 로테이션, 시크릿 관리, 에이전트 간 레이트 리밋 배분. 로컬 데이터베이스에 레코드 하나 쓰는 것처럼 당연해야 할 기능을 위한 운영 오버헤드다.
이슈 트래커가 디스크 위의 파일이면 인증할 대상이 없다. 에이전트가 파일시스템을 읽을 수 있으면 이슈도 읽고 쓸 수 있다. 고장 날 요소가 하나 줄어든다.
데이터 모델이 인간을 전제한다
Jira를 열어보자. 스프린트가 보인다. 스토리 포인트. 프로필 사진과 이메일 주소를 가진 담당자. "리뷰 중"이나 "그루밍 대기" 같은 상태의 워크플로우. 데이터 모델 전체가 스탠드업, 스프린트 플래닝, 회고를 하는 인간 팀을 위해 설계됐다.
에이전트는 스탠드업을 하지 않는다. 스토리 포인트로 추정하지 않는다. 7개의 상태와 4개의 승인 게이트가 있는 워크플로우는 필요 없다.
에이전트에게 필요한 건 의존성 그래프다. 이 태스크는 저 태스크에 의해 블록됐다. 이 에픽에는 12개의 하위 항목이 있고 7개가 완료됐다. 이 에이전트가 이 이슈를 45초 전에 클레임한 후 보고가 없다. 근본적인 데이터 구조는 열을 따라 이동하는 카드 보드가 아니라 블로킹 관계를 가진 태스크 트리다.
SaaS 도구들은 "자동화" 기능을 덧붙이지만, 그 아래 핵심 모델은 여전히 인간용 Kanban 보드다. Jira 플러그인을 만들어 에이전트가 이슈를 생성하게 할 수는 있다. 하지만 Jira가 당신의 에이전트를 스프린트 팀의 구성원으로 인식하는 건 바꿀 수 없다.
클라우드 의존은 단일 장애점
에이전트는 로컬에서 돌아간다. 로컬 파일을 읽고, 로컬 코드를 쓰고, 로컬 git 저장소에 커밋한다. 오프라인에서도, 비행기 안에서도, 레이턴시 2000ms인 네트워크에서도 작동한다. 상관없다.
하지만 이슈 트래커가 SaaS 제품이면 모든 에이전트 작업에 인터넷 접속이 필요해진다. Linear가 10분간 다운되면? 플릿 전체가 멈춘다. 집 인터넷이 30초 끊기면? 모든 에이전트가 재시도 루프에 빠진다. 작업을 조율해야 할 이슈 트래커가 전체 시스템의 단일 장애점이 된다.
로컬 퍼스트라면 이슈 트래커의 신뢰성은 파일시스템과 동일하다. 항상 사용 가능하고, 항상 빠르고, 항상 내 통제 하에 있다.
쓰기 볼륨의 자릿수가 다르다
SaaS 프로젝트 관리 도구는 510명의 인간 팀이 하루에 몇 차례 업데이트하는 걸 상정한다. 팀 전체에서 50100건 정도의 쓰기.
13개 에이전트가 몇 분마다 이슈를 업데이트하면 단일 프로젝트에서 시간당 수백 건의 API 호출이 발생한다. 이건 사용량의 소폭 증가가 아니다. 완전히 다른 사용 패턴이다. 인간 팀에게 넉넉해 보이는 레이트 리밋이 에이전트 플릿에게는 넘을 수 없는 벽이 된다.
그리고 문제는 볼륨만이 아니다. 동시성이다. 세 에이전트가 같은 에픽의 하위 항목을 동시에 업데이트한다. 상태 필드의 경합 조건. 코멘트 스레드의 낙관적 잠금 실패. SaaS 도구가 해결할 필요 없었던 문제들이다. 인간이 세 터미널에서 같은 이슈를 동시에 업데이트하는 일은 없으니까.
협업은 데이터 포기를 의미한다
Jira 프로젝트를 팀원과 공유하려면 둘 다 Jira 계정이 필요하다. 데이터는 Atlassian 서버에 있다. 자신의 프로젝트 데이터를 API로 접근하는 특권에 대해 시트당, 월단위로 비용을 지불한다.
다른 도구로 옮기고 싶다면? 가능한 것만 CSV로 내보내고 나머지는 포기해야 한다. 코멘트, 첨부파일, 커스텀 필드, 감사 이력. 쓸 수 있는 형식으로 꺼내는 건 행운에 맡길 일이다. SaaS 모델은 데이터 소유권을 편의성과 교환한다.
하지만 협업에 중간 벤더가 필요하진 않다. 이슈 데이터베이스가 Dolt(데이터베이스용 Git) 같은 것으로 관리된다면, 리모트에 push하고 팀원이 pull하면 된다. 코드를 브랜치하듯 이슈 데이터베이스를 브랜치한다. 머지도 같은 방식이다. 같은 도구와 멘탈 모델로 충돌을 해결한다. 데이터는 계속 내 것이다. 협업이 구독이 아니라 git처럼 작동한다.
실제로 작동하는 것
브랜드 이름을 걷어내고 에이전트가 이슈 트래커에 정말로 필요한 것을 생각해보자.
- 로컬 퍼스트. 네트워크 의존 없음. 데이터베이스는 디스크 위의 파일.
- CLI 네이티브. 에이전트는 터미널에 산다. 인터페이스도 그래야 한다.
- Git 기반. 버전 관리, 머지 가능, 감사 추적. 벤더 종속 없음.
- 인증 오버헤드 없음. 에이전트가 파일시스템을 읽을 수 있으면 이슈도 추적할 수 있다.
- 저레이턴시. 작업당 50ms 이하. 500ms가 아니라.
- 중개자 없이 동기화. API webhooks가 아니라 git 저장소처럼 push & pull.
이것이 내가 매일 쓰는 것이다. beads는 정확히 이 워크플로우를 위해 만들어진 Git 네이티브 이슈 트래커다. 모든 것을 Dolt 기반 버전 관리와 동기화를 갖춘 로컬 SQLite 데이터베이스에 저장한다. CLI가 주 인터페이스다. 에이전트는 다른 명령을 실행하듯 이슈를 생성, 업데이트, 조회한다.
Beadbox는 그 위에 내가 만든 비주얼 레이어다. 로컬 데이터베이스의 변경을 감시하고 의존성 트리, 에픽 진행 상황, 에이전트 활동을 실시간으로 렌더링한다. 에이전트는 CLI를 쓴다. 나는 대시보드를 쓴다. 둘 다 같은 로컬 데이터베이스에서 읽는다.
기존 도구가 문제는 아니다
Jira는 본래 목적에서 탁월하다. 구조화된 워크플로우를 통한 인간 팀 조율. Linear는 속도와 세련됨을 원하는 소규모 팀에 아름답다. GitHub Issues는 오픈소스 협업에서 마찰이 없다.
어떤 것도 나쁜 도구가 아니다. 다른 문제를 풀고 있을 뿐이다. 5명의 인간이 2주 스프린트를 도는 워크플로우라면 계속 쓰면 된다.
하지만 5개, 10개, 혹은 13개의 AI 에이전트가 같은 코드베이스에서 실시간으로 조율하고 있다면, SaaS 모델의 한계를 넘어선 것이다. Agentic engineering에는 agentic engineering을 위해 만들어진 도구가 필요하다. 인간 워크플로우에 API를 덧붙인 것이 아니라.