나는 새로운 용어를 만들거나 프레임워크를 구축하려던 것이 아니었습니다.

내가 하려던 것은 내가 함께 작업하는 에이전트(Agents)들을 위한 스케줄러(Scheduler) 역할을 그만두는 것이었습니다.

나는 프롬프트(Prompts)로 시작했습니다.

프롬프트는 효과가 있었습니다. 그것이 문제였습니다.

초기 세션에서 에이전트와 함께 작업하는 것은 명백히 다음 단계의 잠금 해제(Unlock)처럼 느껴졌습니다. 코드, 제품 사고(Product thinking), 전략, 문서화, UI 리뷰, 조사, 테스트, 그리고 계획에 대해 도움을 요청할 수 있었습니다. 작업은 더 빨라졌습니다. 훨씬 더 빨라졌습니다. 며칠이 걸리던 문제들을 오후 한때에 탐색할 수 있었습니다. 디자인 아이디어는 목업(Mockups)으로 변할 수 있었습니다. 버그(Bugs)는 테스트(Tests)로 변할 수 있었습니다. 모호한 우려는 조사 브리프(Research brief), 작업 그래프(Task graph), 또는 풀 리퀘스트(Pull request)로 변할 수 있었습니다.

이것은 실제적이었기에 흥미로웠습니다. 이것은 장난감 같은 사용 사례(Use case)가 아니었습니다. 나는 제품 작업, 리포지토리 상태(Repo state), 테스트, 실제 소프트웨어 시스템, 그리고 기술적 및 제품적 결정 내에서 에이전트를 사용하고 있었습니다. 마치 문이 열린 것 같은 기분이었습니다.

가능성은 무궁무진했습니다. 백로그(Backlog) 또한 마찬가지였습니다.

나는 흐름(Flow)을 유지하기 위해 늦은 밤, 때로는 한밤중에 프롬프트를 작성하고 있는 자신을 발견했습니다. 시도해 볼 가치가 있는 다른 일들이 항상 있었습니다. 수정해야 할 버그, 스케치해야 할 기능, 탐색해야 할 제품 아이디어, 메워야 할 프로세스 격차, 조사해야 할 경쟁사 같은 것들 말입니다. 모델(Models)은 이 모든 것을 도와줄 수 있었고, 이는 계속해서 밀어붙이지 않는 것이 낭비처럼 느껴지게 만들었습니다.

그것은 이상한 거래였습니다. 더 짧은 시간 안에 더 많은 일을 해낼 수 있었지만, 오직 기계에 계속해서 먹이를 공급할 때만 가능했습니다. 만약 내가 프롬프팅을 멈추면, 진전도 멈췄습니다.

하지만 첫 번째 가속화의 파도가 지나간 후, 이상한 일이 일어났습니다.

여전히 전체를 하나로 묶어 유지하고 있는 것은 바로 나였습니다.

에이전트들은 거의 모든 일을 도울 수 있었지만, 제가 말해주지 않으면 다음에 무엇이 중요한지 알지 못했습니다. 그들은 PR (Pull Request)을 검토할 수는 있었지만, 어떤 PR이 오래된(stale) 것인지는 알지 못했습니다. 테스트를 작성할 수는 있었지만, 어떤 동작이 테스트가 부족한 상태인지는 알지 못했습니다. 프로세스 문서를 개선할 수는 있었지만, 어떤 프로세스가 방금 실패했는지는 알지 못했습니다. 시장 신호(market signal)를 조사할 수는 있었지만, 그 신호가 제품 작업(product work)을 중단시켜야 하는 것인지 여부는 알지 못했습니다. 그들은 작업을 수행할 수는 있었지만, 언제 작업을 깨워야(wake up) 하는지를 신뢰성 있게 결정할 수는 없었습니다.

그것이 첫 번째 진짜 병목 현상 (bottleneck)이 되었습니다.

그것은 모델의 능력 (model capability) 문제가 아니었습니다. 그것은 주의력 (attention) 문제였습니다.

프롬프팅 (Prompting)이 나의 주의력을 런타임 (Runtime)으로 만들었다

사람들이 에이전트에 대해 이야기할 때, 보통 능력 (capability)부터 시작합니다. 모델이 코딩을 할 수 있는가? 추론 (reasoning)을 할 수 있는가? 도구 (tools)를 호출할 수 있는가? 리포지토리 (repo)를 다룰 수 있는가? 브라우저를 사용할 수 있는가?

그러한 질문들은 중요합니다. 다만 그것들이 가장 먼저 무너진 원인은 아니었을 뿐입니다.

무너지기 시작한 것은 그 능력 (capability)을 둘러싼 운영 모델 (operating model)이었습니다.

모든 세션은 여전히 제가 컨텍스트 (context)를 재수화 (rehydrate)하는 과정을 필요로 했습니다. 내가 무엇을 만들고 있는가? 어제 무엇이 바뀌었는가? 어떤 브랜치 (branch)가 중요한가? 어떤 PR이 준비되었는가? 어떤 문서가 오래되었는가? 어떤 결정이 나의 결정이며, 어떤 결정은 에이전트가 안전하게 내릴 수 있는가?

에이전트들이 가만히 앉아 있었던 것은 그들이 약해서가 아니었습니다. 작업에 신뢰할 수 있는 라우팅 계층 (routing layer)이 없었기 때문에 가만히 있었던 것입니다.

제가 나타나서 프롬프팅 (prompting)을 잘 수행하면 시스템은 강력하게 느껴졌습니다. 하지만 제가 그러지 않으면 아무 일도 일어나지 않았습니다.

실제로 경험해 보기 전까지는 당연하게 들릴 것입니다. 하루가 지나고, 이틀이 지납니다. 유능한 에이전트 노동력은 충분히 사용 가능하지만, 아무도 열려 있는 루프 (open loops)를 점검하거나, 오래된 PR을 알아차리거나, CI (Continuous Integration)를 확인하거나, 흩어진 신호들을 순위가 매겨진 작업으로 전환하지 않습니다.

그래서 인간이 런타임 (runtime)이 됩니다.

저는 스케줄러 (scheduler)였습니다. 저는 메모리 계층 (memory layer)이었습니다. 저는 QA 게이트 (QA gate)였습니다. 저는 제품 라우터 (product router)였습니다. 저는 에스컬레이션 시스템 (escalation system)이었습니다. 저는 어떤 대화가 중요한지, 어떤 문서가 최신인지, 어떤 브랜치 (branch)가 존재하는지, 어떤 작업이 차단되었는지, 그리고 어떤 미결 사항들을 다시 처리해야 하는지를 기억하는 사람이었습니다.

아이러니하게도, 에이전트들은 저를 더 빠르게 만드는 동시에 더 과부하 상태로 만들었습니다.

끝없는 가능성의 유혹

에이전트가 유용해지면 발생하는 또 다른 현상이 있습니다. 바로 표면적 (surface area)이 폭발적으로 늘어난다는 것입니다.

에이전트가 있기 전에는, 탐색 비용이 너무 많이 들기 때문에 많은 아이디어가 조용히 사라졌습니다. '이 경쟁사를 비교해 봐야겠다'라거나, '이 온보딩 (onboarding) 문서를 개선해야겠다', 혹은 '저 핸들러 (handler)를 리팩터링 (refactor)해야겠다'라고 생각할 수도 있지만, 하루에 쓸 수 있는 시간은 한정되어 있습니다. 제약 조건은 명확합니다. 그래서 그냥 다음 단계로 넘어갑니다.

에이전트와 함께라면, 그 제약 조건이 모호해집니다.

갑자기 모든 아이디어가 실행 가능한 것처럼 느껴집니다. 모든 오래된 문서를 정리할 수 있을 것 같고, 모든 제품 인터페이스를 재설계할 수 있을 것 같으며, 모든 경쟁사의 발표를 분석할 수 있을 것 같습니다. 모든 테스트 공백이 티켓 (ticket)이 될 수 있고, 모든 거친 생각들이 계획으로 바뀔 수 있습니다.

도구 그 자체에서 오는 조용한 압박도 있었습니다. 만약 내가 이러한 모델들, 이러한 구독 서비스들, 이러한 역량의 창구들에 접근할 수 있다면, 사용하지 않는 용량은 낭비되고 있다는 느낌이 들었습니다. 프롬프팅 (prompting)을 하지 않는 매 시간은 기회를 놓치고 있는 것처럼 느껴졌습니다.

그것은 저의 집중력을 줄여주기는커녕 더 산만하게 만들었습니다. 갑자기 에이전트에게 지금 당장 시킬 수 있는 유용한 일들이 열 가지나 생겨난 것입니다. 어려운 점은 더 이상 레버리지 (leverage)를 찾는 것이 아니었습니다. 어려운 점은 그 레버리지를 어디로 향하게 할지 결정하는 것이었고, 그다음 작업을 계속 진행할 수 있을 만큼 충분히 몰입(present) 상태를 유지하는 것이었습니다.

그것은 취하게 만들면서도 위험합니다. 거의 무엇이든 시작할 수 있게 될 때, 무엇이 주의를 기울일 가치가 있는지를 결정하는 것이 진짜 업무가 되기 때문입니다.

문제는 단순히 "에이전트가 이것을 할 수 있는가?"가 아닙니다. 문제는 "이것을 지금 해야 하는가?" "이것이 업무를 진전시키는가?" "이것이 실제 신호(signal)인가, 아니면 그저 흥미로운 주의 분산 요소인가?" "이것이 지속 가능한 레버리지(leverage)를 창출할 것인가, 아니면 내가 이제 관리해야 할 또 다른 실타래가 될 것인가?"입니다.

에이전트의 능력이 더 커진다고 해서 인지 부하 (cognitive load)가 자동으로 줄어드는 것은 아닙니다. 때로는 오히려 증가합니다. 에이전트가 할 수 있는 일이 많아질수록, 가능한 업무의 양도 더 많이 나타납니다. 그 업무를 라우팅 (routing)하는 시스템이 없다면, 빌더(builder), 엔지니어, 또는 소규모 팀은 무한한 가능성을 처리하는 인간 교환기 (human switchboard)가 되어버립니다.

이는 번아웃 (burnout)으로 가는 빠른 길입니다.

업무가 나쁘기 때문이 아닙니다. 모든 업무가 그럴듯하기 때문입니다.

첫 번째 교훈: 프롬프트 (Prompts)는 운영 모델 (Operating Model)이 아니다

나는 여전히 프롬프팅 (prompting)을 매우 중요하게 생각합니다. 프롬프트의 품질은 중요합니다. 명확한 지침은 중요합니다. 컨텍스트 (context)도 중요합니다. 잘 정의된 요청은 유용한 결과물과 자신감 넘치는 헛소리의 더미 사이의 차이를 만들어낼 수 있습니다.

하지만 프롬프팅은 운영 모델이 아닙니다.

프롬프팅은 에이전트가 특정 순간에 어떤 일을 수행하도록 돕습니다. 하지만 프롬프팅 그 자체로는 조직에게 무엇을 기억해야 할지, 무엇을 검사해야 할지, 무엇을 검증해야 할지, 무엇을 개선해야 할지, 무엇을 무시해야 할지, 또는 언제 에스컬레이션 (escalate)해야 할지를 알려주지 않습니다.

그것이 내 사고방식의 첫 번째 변화였습니다. 처음에는 에이전트에게 도움을 요청하는 법을 더 잘하려고 노력했습니다. 시간이 흐르면서 더 중요한 질문은 다음과 같이 바뀌었습니다: 어떤 운영 계층 (operating layer)이 나를 런타임 (runtime)으로 만들지 않으면서 에이전트의 업무가 복리로 쌓이게(compound) 할 수 있을 것인가?

그 다음에 나타난 사다리

이 시리즈의 나머지 부분은 이에 대응하여 내가 구축하기 시작한 것과, 그 개인적인 워크플로 (workflow)가 어떻게 더 넓은 운영 모델로 성장했는지에 관한 것입니다.

문제는 개인적인 차원에서 시작되었지만, 오래도록 개인적인 문제로 남아있지는 않을 것이라고 생각합니다. 에이전트가 유용해지기 시작하면, 어떤 창업자나 소규모 팀이라도 동일한 질문에 직면하게 됩니다: 어떻게 하면 인간을 런타임으로 만들지 않고 업무를 계속 진행시킬 수 있을 것인가?

첫 번째 단서는 반복이었습니다. 만약 내가 계속해서 같은 것을 요구한다면, 그 프롬프트는 재사용 가능한 능력 (reusable capability)이 되고 싶어 할 것입니다.

반복되는 프롬프트는 기술 (skills)이 되었습니다. 기술에는 GitHub 내에서의 공유된 프로세스 (shared process)와 지속적인 상태 (durable state)가 필요했습니다. 정적인 문서 (static docs)에는 루프 (loops)가 필요했습니다. 루프는 때때로 정렬된 워크플로우 (ordered workflows)로 구성되었습니다. 그리고 그 워크플로우에는 어텐션 라우팅 (attention routing)이 필요했습니다.

각 계층은 이전 계층의 실패 모드 (failure mode)를 해결했습니다. 또한 각 계층은 다음 병목 현상 (bottleneck)을 드러냈습니다.

결국 질문은 매우 단순해졌습니다: 지금 무엇을 실행해야 하는가?

이것이 제가 어텐션 운영체제 (Attention Operating System)를 정의하기 시작한 이유입니다. 멋진 용어를 원해서가 아니라, 문제가 구체화되었기 때문입니다. 시스템에는 상태를 검사하고, 무엇이 주의를 기울일 가치가 있는지, 무엇을 위임할 수 있는지, 무엇을 스케줄링해야 하는지, 그리고 무엇에 인간의 결정이 필요한지를 결정할 방법이 필요했습니다.

목표는 더 많은 알림을 만드는 것이 아닙니다. 목표는 신뢰할 수 있는 어텐션 라우팅 (attention routing)입니다.

이것이 제가 에이전트 운영체제 (Agent Operating System)라고 말하는 것의 시작입니다. 컴퓨터 과학적 의미의 운영체제도 아니고, 제가 이 카테고리를 발명했다는 주장도 아닙니다. 그보다는 에이전트 지원 작업 (agent-assisted work)을 위해 리포지토리(repo)가 소유하는 운영 계층 (operating layer)에 가깝습니다: 상태 (state), 어텐션 (attention), 루프 (loops), 스택 (stacks), 증거 (evidence), 피드백 (feedback), 그리고 인간 게이트 (human gates)를 포함합니다.

하네스 (harness)는 변할 수 있습니다. 하지만 운영 모델 (operating model)은 살아남아야 합니다.

이 시리즈의 방향

이 시리즈는 제가 어떻게 여기까지 왔는지, 그리고 그 과정이 어떻게 성장했는지에 대한 이야기입니다.

완성된 교리로서가 아닙니다. 승전보를 울리기 위함도 아닙니다. 실제 소프트웨어 작업 내에서 에이전트를 매일 유용하게 만들기 위해 노력하며 작성한 현장 노트 (field notes)에 가깝습니다.

경로는 다음과 같습니다:

1. AI 에이전트 덕분에 속도가 붙었지만, 곧 주의력(Attention)이 병목 현상이 되었다: 프롬프팅이 어떻게 레버리지 (leverage)를 창출했는지, 동시에 어떻게 인간의 주의력을 런타임 (runtime)으로 만들었는지에 대하여.
2. 프롬프트가 인프라가 될 때: 반복되는 프롬프트가 어떻게 기술 (skills)이 되었는지, 그리고 그 기술이 어떻게 자연스럽게 프로세스 문서 (process docs), 온보딩 (onboarding), GitHub Issues, PRs, 로드맵 (roadmaps), 그리고 공유된 운영 컨텍스트 (shared operating context)로 이어졌는지에 대하여.
3. 루프, 어텐션, 그리고 에이전트 운영체제: 반복되는 작업이 어떻게 트리거 (triggers), 검증기 (verifiers), 중단 조건 (stop conditions), 증거 (evidence), 에스컬레이션 (escalation), 그리고 다음에 무엇을 실행할지 결정하는 어텐션 계층 (attention layer)을 갖게 되었는지에 대하여.

다음 포스트는 그 사다리의 첫 번째 단계, 즉 반복적인 프롬프트 (prompts)가 더 이상 채팅처럼 느껴지지 않고 인프라 (infrastructure)처럼 보이기 시작하는 순간부터 시작됩니다.

더 넓은 논지는 간단합니다:

에이전트 우선 (Agent-first) 팀은 단순히 더 나은 프롬프트를 작성하는 것만으로는 확장 (scale)할 수 없습니다.

그들은 에이전트 주변에 더 나은 운영 체제 (operating systems)를 구축함으로써 확장할 것입니다.

그것은 매우 인간적인 깨달음에서 시작됩니다: 만약 에이전트가 능력이 있음에도 불구하고 당신이 프롬프트를 입력하지 않으면 아무것도 움직이지 않는다면, 병목 현상 (bottleneck)은 모델이 아닙니다.

병목 현상은 어텐션 (attention)입니다.