개발자 편의성(developer ergonomics)을 고려하여 구축된 분산형 이벤트 소싱(event-sourced) 이슈 트래커가 차세대 에이전트 워크플로우(agentic workflows)에서 어떤 역할을 할 수 있는지에 대하여

Vision drift (비전 드리프트)

Harness engineering은 최근 에이전트 워크플로우(agentic workflows)에서 아키텍처 드리프트(architectural drift)를 제어해야 한다는 아이디어를 대중화했습니다. 하지만 이러한 논의에서 놓치고 있는 부분은 더 높은 수준에서의 유사한 문제인 비전 드리프트(vision drift)일 수 있습니다.

제가 말하는 비전 드리프트(vision drift)란, 구현이 단순히 아키텍처에서 벗어나는 것을 넘어 원래의 제품 의도(product intent)로부터 벗어나는 것을 의미합니다. 그리고 이러한 위험은 제한된 도구들로 인해 가려져 있을 가능성이 있습니다. 프로젝트 관리 도구들이 추적 가능한 이야기(traceable story)가 아닌 단편적인 스냅샷(snapshot)만을 제공하는 한, 감지되지 않는 드리프트(drift)의 위험은 높아집니다.

드리프트(drift)는 시간이 흐름에 따른 사양 감사(specification audits)를 통해 감지됩니다. 그러나 Git을 통해 코드 이력(code history)은 쉽게 탐색할 수 있는 반면, 이슈 트래킹(issue tracking)은 본질적으로 이러한 능력이 부족합니다. 이슈 트래커(issue trackers)는 “지금 무엇이 일어나고 있는가?”라는 질문에는 매우 탁월하게 답하지만, “이 분야의 작업이 지난달에 어떻게 진화했는가?” 또는 “작년 이맘때는 무엇이 진행되었는가?”, 혹은 “우리가 어떻게 거기서 여기까지 오게 되었는가?”라는 질문에는 답하지 못하는 경향이 있습니다.

Workflow audits (워크플로우 감사)

제가 Epiq을 구축하기 시작했을 때, 이것은 제 고려 사항이 아니었습니다. 에이전트 코딩(Agentic coding)은 막연한 소문으로만 들었던 것이었고, 사실 저는 그저 이상적인 개발자 경험(ideal developer experience)을 추구하고 있었습니다. 하지만 이러한 추구는 저를 비정통적인 아키텍처(unorthodox architecture)의 길로 인도했고, 결과적으로 몇 가지 흔치 않은 특성을 가진 이슈 트래커(issue tracker)를 만들게 되었습니다. 그중 하나는 타임 트래블링(time-traveling)을 통해 과거의 상태를 조사하고 시퀀스(sequences)를 재생(replay)할 수 있는 능력입니다. 저는 아직 이러한 기능을 갖춘 다른 이슈 트래커를 접해보지 못했습니다.

처음에는 이것을 단순한 눈요기용 기능(gimmick feature)이라고 생각했습니다. 지난 2주간의 과정을 짧은 영화처럼 시각화하여 레트로 스타일로 스프린트 전체를 재생할 때의 놀라움(wow-factor)을 상상해 보세요. 저는 이것이 얼마나 많은(혹은 적은) 작업이 완료되었는지 성찰하는 데 도움이 될 것이라고 생각했습니다. 하지만 제가 직접 처음으로 에이전트가 완전히 구현된 기능을 만들기로 결심하고 나서야, 제품 개발의 통제권을 유지하는 데 진심인 사람에게 '타임 트래블(time-travel)'이 얼마나 필수적인 기능이 될 것인지 깨닫게 되었습니다.

제기된 질문들

저는 Claude와 함께 새로운 기능에 대한 마스터 플랜을 세웠고, Claude는 Epiq MCP를 사용하여 이를 소화 가능한 작업들로 세분화했습니다. Claude가 작업을 시작한 지 2시간 만에 돌아왔을 때, 모든 이슈가 보드의 리뷰(review) 컬럼으로 이동한 것을 보고 기뻤습니다. 저는 한두 시간 동안 코드를 검토했습니다. 모든 것이 훌륭해 보였습니다. 이미 코드베이스에 확립된 아키텍처 패턴(architectural patterns)을 따르며, 견고하고 테스트되었으며 잘 작동하는 코드였습니다. 다만, 이제 저는 작업이 어떻게 진행되었는지에 대해 엄청난 호기심이 생겼습니다. 코드에 관한 질문에서 멈추는 대신, 저는 완전히 새로운 질문들을 던지고 있는 자신을 발견했습니다.

• 어떻게 여기까지 오게 되었는가?
• 진행 과정에서 경로 수정(course corrections)이 이루어졌는가?
• 처음에 예상하지 못했던 새로운 티켓(tickets)이 생성되었는가?
• 계획이 수정되었는가?
• 보드의 다른 이슈들이 차단 요소(blockers)가 되었는가?

단 하나의 에이전트가 2시간 동안 독립적으로 작업했을 뿐인데도 구현 과정이 어떻게 진화했는지 궁금해졌습니다. 저는 20개의 에이전트가 3일 동안 협업할 때는 어떤 종류의 질문들이 생겨날지 스스로에게 묻게 되었습니다.

작업은 어떻게 조정되었는가?
에이전트들이 서로 방해하며 낭비하며 일했는가, 아니면 서로의 작업을 바탕으로 조화롭게 일했는가?
가장 중요한 것은 - 그들이 초기 비전(initial vision)을 포기했는가, 아니면 수정했는가?

그 시점에서 저는 보드의 스냅샷 상태(snapshot state)만으로는 더 이상 이러한 질문들에 답할 수 없음을 깨달았습니다. 보드의 진화 과정을 실시간으로 앉아서 모니터링하지 않는 한, 이러한 질문에 답할 준비가 되지 않은 상태가 될 것입니다.

전체 이야기

반면에, Epiq을 사용하면 단 한 번의 명령만으로 가능했습니다: ":replay 2h". 그것만으로 전체 세션이 타임랩스 영화처럼 재생되는 것을 볼 수 있었습니다. 그 순간, 이것이 인간이 비전 (vision)을 계속 통제하기 위해 필요한 완전히 새로운 세대의 기능 중 일부라는 사실이 깨달아졌습니다.

프로젝트 관리 도구의 미래

에이전트 기반 코딩 (agentic coding)은 조만간 사라지지 않을 것으로 보입니다. 초기 열풍 이후 우리의 방법론에 어느 정도 수정 과정이 있겠지만, 인간이 통제권을 유지할 수 있는 능력을 보존한다면 진지한 프로덕션 환경에서도 그 자리를 잡을 수 있을 것이라 생각합니다. 이는 차세대 프로젝트 관리 도구에 새로운 요구 사항이 생김을 의미합니다.

에이전트가 점점 더 많은 자율성 (autonomy)을 갖게 됨에 따라, 잠재적인 비전 드리프트 (vision drift)의 위험은 더 나은 워크플로우 감사 (workflow auditing)를 요구합니다. 아키텍처 감사 (architectural audits)에서 한 단계 더 나아간 것이 에이전트 기반 워크플로우 (agentic workflows)를 둘러싼 논의의 자연스러운 다음 단계로 보입니다.

Git이 소스 코드의 진화를 검사 가능한 (inspectable) 상태로 만들었다면, 차세대 프로젝트 관리 도구는 의도 (intent)의 진화를 검사 가능한 상태로 만들어야 할 것입니다.

_관심이 있으시다면 👉 Explore Epiq