TaskTrack — 에이전트 작업 관리를 위한 Specify 명세

이제 제 이전 블로그 포스트에서 제안했던 내용을 테스트해 볼 시간입니다. 소스 코드로 인코딩하지 않고도 에이전트(Agent)가 실행할 애플리케이션을 명세(Spec)화하는 것이 가능할까요? 함께 알아봅시다.

모든 지식 노동자에게 익숙한 애플리케이션 유형 중 하나는 작업 관리(Task Management)입니다. 모든 작업은 생명주기 상태(Lifecycle status), 다른 작업과의 의존성(Dependencies), 그리고 진행 이력(History of progress)을 가집니다.

이제 에이전트에게도 그들만의 작업 관리 시스템을 부여해 봅시다.

TaskTrack는 Specify 명세로 구현된, 단순하지만 사소하지 않은 작업 관리 시스템 변형입니다. 이는 에이전트가 내부적으로 가끔 사용하는 체크박스 기반의 할 일 목록(To-do lists)을 넘어, 위에 나열된 핵심 시스템 기능들을 모방합니다.

TaskTrack은 두 가지 절차를 정의합니다: 요구사항으로부터 상호 연결된 작업 세트를 생성하는 "계획 작성 실행(Plan Authoring Run)"과, 이전에 작성된 계획을 완료를 향해 진행시키는 "계획 실행 실행(Plan Execution Run)"입니다. 하나의 실행 실행만으로는 완료를 달성하기에 항상 충분하지 않을 수 있는데, 이는 TaskTrack이 인간의 피드백(Human feedback)을 요청하고 이를 다음 실행 실행 중에 통합할 수 있도록 허용하기 때문입니다. 또한, 모든 실행 실행은 고급 에이전트 컨텍스트 관리(Agent context management)를 가능하게 하기 위해 "작업 처리 실행(Task Processing Run)" 하위 절차로 나뉩니다.

TaskTrack은 이 모든 것을 300줄 미만의 텍스트로 구현합니다. 만약 구현에 소스 코드를 사용했다면, 프로그래밍 언어에 따라 필수적인 파일 I/O 작업(TaskTrack은 단순성을 위해 데이터베이스가 아닌 파일을 사용합니다)만을 구현하기에도 충분한 공간이었을 것입니다. 자연어는 쉽게 매우 비대해질 수 있지만, 엄격하고 과학적인 글쓰기 스타일과 Specify 표준이 제공하는 기능의 광범위한 사용은 이를 효과적으로 방어할 수 있습니다.

공식적인 테스트는, 다른 방법이 있겠습니까, 영감 없는 또 다른 Breakout 클론을 구현하는 것입니다. 요구사항, 완료된 TaskTrack 계획, 그리고 결과물은 저장소(Repository)에 포함되어 있습니다.

직접 테스트를 실행해보고 싶다면, 포함된 README 파일에 작성 에이전트(authoring agent)와 실행 에이전트(execution agent)를 위한 실행 프롬프트(launch prompts)를 포함한 필요한 정보가 들어 있습니다. 두 실행 프롬프트가 어떻게 구조화되어 있는지 주의 깊게 살펴보시기 바랍니다. 이들은 TaskTrack 용어를 사용하며 관련 파일들을 가리킵니다. 이 프롬프트들은 작업 관련 행동 지침(behavioral instructions)을 포함하지 않습니다. 실행 에이전트의 실행 프롬프트에는 에이전트의 기능을 범용적인 TaskTrack 명세(specification)로 매핑하기 위한 에이전트 특화 지침이 포함되어 있습니다. 과거의 전통적인 수동 코딩 디자인 패턴(manual coding design patterns)의 원칙은 에이전트 시대(agentic era)에도 여전히 유효합니다!

그리고 이제, 마침내 테스트 결과입니다. 요약하자면: 작동합니다!

작성 에이전트는 표시된 대로 모든 TaskTrack 파일을 생성했으며, 이는 아마도 그리 놀랍거나 인상적이지는 않을 것입니다. 더 중요한 점은, 실행 에이전트가 16개의 작업과 2번의 실행 과정 전체에 걸쳐 결정론적 동작(deterministic behavior)을 보여주었다는 것입니다. 저는 LLM의 본질적으로 무작위적이고 따라서 비결정론적인(non-deterministic) 특성 때문에 결정론적 동작이 반드시 소스 코드 내에 인코딩되어 있어야 한다는 말을 자주 듣습니다. 저는 이번 테스트 결과를 바탕으로 그 점을 확인할 수 없었습니다. 실행 에이전트는 매번 정의된 단계별 절차(step-by-step procedure)를 원칙대로 따랐습니다. 정의된 텍스트 출력조차 마치 print 문에 의해 생성된 것처럼 신뢰할 수 있고 반복 가능하게 생성되었습니다.

이 단 한 번의 테스트 결과가 명세화(speccing)의 생존 가능성에 대한 일반적인 증명을 제공하는 것은 아니라는 점은 말할 필요도 없습니다. 이는 그것이 작동할 수 있다는 것, 즉 가능하다는 것을 보여줍니다. 어쩌면 비결정론적인 에이전트 동작은 근본적인 LLM의 무작위성보다는 명확하지 않은 지침(unspecific instructions)의 결과인 경우가 더 많을지도 모릅니다.

이 모든 말을 마쳤지만, 테스트 실행이 완벽과는 거리가 멀었습니다. 이 과정에서 소위 '가치 있는 학습 경험'이라 불릴 만한 것들이 여러 차례 발생했습니다.

첫 번째이자 가장 명백한 발견은 단 하나를 제외한 모든 타임스탬프(timestamps)가 부정확하다는 점입니다. 작성 에이전트(authoring agent)는 현재 UTC 시간을 가져오기 위해 Python 스크립트를 작성하고 실행했습니다. 반면 모든 작업 처리 서브 에이전트(subagents)들은 단순히 타임스탬프를 지어냈습니다. 나중에 제가 시스템에 이러한 동작 차이에 대해 물었을 때, 시스템은 흥미로운 답변을 내놓았습니다. 새로운 타임스탬프를 생성하는 것은 "단일하고, 두드러지며, 일회적인 단계... 실제 python/date 호출을 할 가치가 있는 단계"인 반면, 타임스탬프 필드를 업데이트하는 것은 "새로운 서브 에이전트 컨텍스트 내의 모든 작업, 모든 실행에서 발생하는... 반복적이고 기계적인 단계"이며, "모델들은 반복적인 상용구(boilerplate)를 체계적으로 후순위로 미룬다"는 것이었습니다.

이것은 TaskTrack의 문제가 아니라 준비가 덜 된 에이전트의 결과입니다. 그리고 바로 이 지점에서, 제가 아무리 노력해도 우리를 먼저 공격한 뒤 핵을 쏠까 봐 두려워하는 그 기계들이 정작 현재 시간에 대한 내장된 접근 권한은 없는 것 같다는 농담 섞인 한마디를 던지지 않을 수 없습니다... 만약을 대비해 이 점을 명심해 두겠습니다.

두 번째 발견은 에이전트 스스로가 테스트 결과를 검토하며 언급했듯이, 작업 해결(task resolutions)이 반드시 TaskTrack 명세(specification)에서 요구하는 것처럼 간결하지는 않다는 점입니다. 하지만 '간결함'이란 무엇일까요? 바로 그렇습니다. 이것은 해석의 여지가 있고 다양한 결과를 초래하는, 서둘러 작성된 모호한(hand-wavy) 지침의 전형입니다. 우리가 현재 자연어(natural language)를 사용하고 있다고 해서 엄밀함(rigor)을 놓아도 된다는 뜻은 아닙니다.

다행히 이는 핵심 처리 로직이 아닌 해결(resolution) 부분에만 영향을 미치므로 큰 문제는 아닙니다. 그럼에도 불구하고 향후 발표에서는 수정할 가치가 있습니다.

세 번째 발견은 엄밀히 말해, 이 놀라운 기계들에게 이제 메모리(memory)가 있기 때문에 테스트 실행에 결함이 있었다는 점입니다. 작성 에이전트와 실행 에이전트 모두 사고 출력(thinking output)을 통해 이것이 테스트라는 사실을 인지하고 있음을 드러냈습니다. 저는 이 결함이 질적 테스트 결과 자체를 무효화한다고 생각하지는 않습니다. 그럼에도 불구하고 향후 테스트 설정에는 더 많은 주의와 고려가 필요할 것입니다.

그동안, TaskTrack 명세(specification)가 공개되었으며, 라이선스는 허용적(permissive)이고, 의견을 자유롭게 나눌 수 있는 상태입니다. 한 번 살펴보시고 여러분의 생각을 알려주세요.