나의 AI 에이전트(AI agents)들은 내가 맡긴 어떤 작업이든 완수할 수 있었다. 하지만 그중 단 하나도 어떤 작업이 한 달을 허비하는 낭비인지 나에게 말해주지는 못했다.

그 격차는 모델의 품질(model quality)에 관한 문제가 아니었다. 그것은 내가 어떤 계층(layer)을 겨냥했느냐의 문제였다. 나는 실행(execution)을 넘겨주었다: 초안 작성, 동기화 실행, 변경 사항 배포와 같은 것들 말이다. 조종(Steering), 즉 현장이 내 발밑에서 움직이기 전에 무엇을 할 가치가 있는지, 그리고 어떤 순서로 할지를 결정하는 일은 내가 스스로 간직했다. 나의 판단력이야말로 가장 빠르게 노화되는 부분이다.

나는 몇 주마다 가치가 재산정되는 분야에서 동시에 수많은 프로젝트를 운영한다. 나의 작업 시스템은 시맨틱 검색(semantic search) 기능이 덧붙여진 작업 관리자(task manager)였다. 그것은 1초 만에 어떤 작업이든 찾아낼 수 있었다. 하지만 한 프로젝트가 내가 내리지 않은 어떤 결정 때문에 일주일 동안 막혀 있다는 사실은 나에게 말해주지 못했다.

검색(Retrieval)은 구조(Structure)가 아니다

시맨틱 검색(Semantic search)은 재현율(recall)을 제공한다. 당신이 무언가를 생각하면, 그것이 그 무언가를 찾아낸다. 내가 그것이 결코 할 수 없는 것을 알아차리기 전까지는 그것이 지능처럼 느껴졌다. 바로 나의 두 목표가 서로 의존하고 있다는 사실을 보는 것 말이다.

아무리 검색이 잘 된다 하더라도, 평면적인 리스트(flat list)에는 형태가 없다. 모든 작업이 똑같이 준비된 것처럼 보인다. 세 단계 전에서 막혀 있는 작업이 지금 바로 시작할 수 있는 작업과 똑같이 보인다. 내게 필요했던 것은 더 나은 재현율(recall)이 아니었다. 그것은 그래프(graph)였다.

의존성 계층(The Dependency Layer)

나는 AI 코딩 에이전트(AI coding agents)를 위한 메모리로 구축된, Git 기반의 의존성 그래프(dependency graph)인 beads를 발견했다. 나는 대신 그것을 나의 인간 워크플로우(human workflow) 아래에 두었다.

상황을 바꾼 명령어는 bd ready였다. 열 개의 프로젝트에 걸쳐 있는 모든 열린 작업을 응시하는 대신, 나는 차단되지 않은 프런티어(unblocked frontier), 즉 지금 바로 실행할 수 있는 단계들만을 확인하게 되었다. 다른 무언가를 기다리고 있는 모든 것들은 해소될 때까지 숨겨진다. 처음 이 명령어를 실행했을 때, 나는 마침내 나의 목표 중 어떤 것들이 서로 겹쳐져 있는지 볼 수 있었다.

그것은 순서(order)를 해결해주었다. 하지만 방향(direction)을 해결해주지는 않았다.

그래프도 여전히 당신의 계획을 신뢰한다

beads는 내가 선언한 순서(sequence)를 강제합니다. 하지만 그것은 목표 그 자체가 여전히 올바른 목표라고 가정합니다. 변화가 느린 환경에서는 그 가정이 유효합니다. 하지만 변화가 빠른 환경에서는 그것이 실제 위험 요소가 됩니다. 즉, 3주 전에 이미 의미가 없어진 목적지를 향해 완벽하게 순서가 정해진 계획을 실행하고 있는 상황 말입니다.

그래서 나는 에이전트(agent)를 한 단계 위로 올렸습니다. 실행(execution) 단계에서 조종(steering) 단계로 말입니다.

드리프트 감사 (The Drift Audit)

이제 에이전트는 정해진 일정에 따라 나의 전체 작업 그래프(task graph)를 읽고 한 가지를 질문합니다. "내가 원한다고 말했던 것에서 내가 어디로 벗어나고(drifting) 있는가?"

매주 에이전트는 전술적 드리프트(tactical drift), 즉 절반만 완료된 실타래나 내가 손대지 않은 프로젝트를 포착합니다. 매달에는 전략적 드리프트(strategic kind), 즉 습관적으로 계속 자금을 투입하고 있는 목표를 포착합니다.

에이전트는 내가 일을 했는지 확인하는 것이 아닙니다. 그 일이 여전히 내가 주장했던 방향을 가리키고 있는지를 확인하는 것입니다.

내가 놓치고 있다는 사실조차 모르는 것들

여기 불편한 부분이 있습니다. 나는 작업을 추가하는 그 순간에는 나에게 완벽하게 말이 된다고 생각되는 작업들을 추가합니다. 하지만 나의 지식에는 경계(edge)가 있으며, 그 경계는 나에게 알리지도 않고 움직입니다.

그래서 두 번째 에이전트가 추천 피드(recommendation feed)가 당신의 기록을 스캔하는 방식으로 나의 미결 작업(open tasks)들을 스캔합니다. 다만, 이번 주 현장에서 실제로 출시(shipped)된 것들과 대조하여 읽어냅니다. 에이전트는 세상이 조용히 쓸모없게 만든 경로와, 하룻밤 사이에 가치가 저렴해진 경로들을 표시(flag)합니다. 이를 통해 나는 만약 그대로 두었다면 기꺼이 한 달 동안 더 걸어갔을 죽은 길(dead roads)에서 벗어날 수 있습니다.

나의 영수증으로 루프를 채우기

마지막 조각은 단순한 질문에서 나왔습니다. "beads를 운영하는 사람들은 이 모든 것이 제대로 작동하는지 어떻게 추적하는가?"

그 답은 느낌(vibes)에 의존해 조종하는 것을 멈추는 것이었습니다. 이제 나의 메트릭 대시보드(metrics dashboard)와 매일 기록하는 시간들은 조종(steering) 레이어로 직접 피드백됩니다. 한 달 전, 대시보드는 내가 최우선 순위라고 이름 붙였던 프로젝트가 기록된 수많은 시간을 잡아먹었음에도 불구하고 아무것도 출시하지 못했다는 것을 보여주었습니다. 나는 알아차리지 못했지만, 숫자는 알고 있었습니다.

그 부분이 여전히 나를 불안하게 만듭니다. 일단 에이전트가 나의 실제 기록(receipts)을 바탕으로 조종하기 시작하면, 내 목록에서 가장 위험한 작업은 더 이상 내가 계속 피하고 있는 작업이 아닙니다. 그것은 조용히 가치를 잃어버린 목표를 향해, 내가 가장 빠르게 끝내고 있는 바로 그 작업입니다.

실행 계층 (execution layer)은 결코 어려운 부분이 아니었습니다. 중요한 판단 (judgment)의 10분의 1 정도에 불과할지도 모릅니다. 어떤 작업이 존재할 가치가 있는지를 결정하는 모든 것은 그보다 한 단계 위 계층에 위치합니다.

따라서 여기 깊이 고민해 볼 만한 질문이 있습니다. 만약 당신의 AI가 당신의 목록에 있는 모든 항목을 끝낼 수 있다면, 그 목록이 여전히 끝낼 가치가 있는지 확인하는 사람은 누구입니까?

저는 실제 구축 사례 — AI 통합 (AI integration), 크론 기반 자동화 (cron-driven automation), 그리고 프로덕션 환경에서 발생하는 문제들 — 에 대한 현장 노트 (field notes)를 작성합니다. 2주마다 새로운 게시물이 올라옵니다. 이 글이 유용했다면, 에이전트 플레이북 (the agent playbook)을 함께 다운로드해 보세요.