포스트

모델이 조금은 느려졌으면 좋겠다: 브레인 토큰 리밋과 AI 시대의 주의력 경제

게시
By BLUEBUG
37 분읽는 시간
모델이 조금은 느려졌으면 좋겠다: 브레인 토큰 리밋과 AI 시대의 주의력 경제

원문 출처: stdy.blog — 모델이 조금은 느려졌으면 좋겠다 (2026.04.08)
참고 원문: Paul Graham — Maker’s Schedule, Manager’s Schedule (2009.07)
작성 기준일: 2026년 4월 9일 (최신 정보 반영)

1. 글의 배경: 새벽 서버실 대신 새벽 tmux 화면

글은 아주 구체적인 장면에서 시작한다. 새벽에 핸드폰으로 원격 서버에 접속하면, 여러 개의 tmux 세션에서 커서 예닐곱 개가 제각기 다른 속도로 깜빡이고 있다. 하나는 코드 리뷰를 마쳤고, 하나는 리팩터링을 완료했으며, 또 하나는 아직 기능 구현을 한창 진행 중이다.

이 장면이 인상적인 이유는, 이것이 오늘날 AI 에이전트를 본격적으로 활용하는 1인 개발자(혹은 소규모 팀)의 일상적인 현실을 매우 생생하게 묘사하기 때문이다. 고작 1-2년 전만 해도 상상하기 어려웠던 풍경이다. 한 사람이 여러 개의 AI 에이전트를 병렬로 돌리고, 그것들을 ‘관리’하는 구조가 실제 개발 워크플로우로 자리 잡기 시작했음을 보여준다.

그 장면을 바라보면서 글쓴이의 머릿속에 떠오른 문장이 핵심이다: “모델이 조금은 느려졌으면 좋겠다.” 글쓴이 스스로도 인정하듯, 1년 전만 해도 이 문장은 이해하기 어려웠을 것이다. AI가 더 빨라지는 것은 무조건 좋은 일이라는 전제가 지배적이었기 때문이다. 그런데 지금은 다르다.

2. 핵심 개념: “브레인 토큰 리밋”

글 전체를 관통하는 가장 핵심적인 메타포가 바로 브레인 토큰 리밋(Brain Token Limit) 이다. AI 모델에는 한 번에 처리할 수 있는 컨텍스트 분량, 즉 “토큰 리밋”이 존재한다. 에이전트가 일정량 이상의 정보를 처리할 수 없듯이, 인간의 뇌도 한 번에 처리할 수 있는 정보와 주의력의 총량에 한계가 있다는 것이다.

글쓴이가 말하는 문제의 본질은 이렇다: AI 에이전트의 속도가 빠를수록, 그 에이전트들이 만들어내는 ‘피드백의 흐름’도 빨라진다. 그런데 그 흐름을 처리하는 것은 결국 인간이다. 에이전트가 결과를 내놓고 다음 지시를 기다릴 때마다, 인간의 뇌는 그 결과를 검토하고, 판단하고, 다음 프롬프트를 구성해야 한다. 이 과정에서 소모되는 것이 바로 ‘브레인 토큰’이다.

글쓴이는 AI 에이전트의 토큰 비용보다 자신의 브레인 토큰 비용이 먼저 바닥나고 있다고 진단한다. 이것이 이 글의 출발점이자 전체 논증의 핵심이다.

3. Fast 모드의 역설: 더 빠를수록 더 피곤하다

현재 주요 AI 코딩 도구들은 속도를 높이는 방향으로 경쟁적으로 기능을 추가하고 있다. 글쓴이가 직접 언급하는 것은 Claude Code의 /fast 모드와 OpenAI Codex CLI의 /fast 모드다.

Claude Code의 /fast 모드: Anthropic의 Claude Opus 4.6 기준으로, fast 모드는 표준 요금의 6배인 MTok당 $30/$150에 제공된다. 속도는 빠르지만 비용이 매우 높아, 글쓴이처럼 정액제로 사용하는 경우 추가 과금 대상이 되어 실사용을 꺼리게 된다.

Codex CLI의 /fast 모드: OpenAI의 Codex CLI는 정액제 리밋 내의 토큰이 소모되는 구조로, 속도가 약 1.5배 향상되지만 토큰 소모량은 약 2배가 된다. 글쓴이는 에이전트와 빈번한 핑퐁(ping-pong) 방식의 인터랙션이 필요한 작업에서 이 모드를 자주 사용한다고 밝힌다.

그런데 글쓴이가 깨달은 것은, 이처럼 에이전트가 더 빠르게 결과를 내놓을수록 자신의 브레인 토큰 소모도 그에 비례하여 증가한다는 점이다. 에이전트가 1시간에 한 번 결과를 내놓을 때와, 10분에 한 번 결과를 내놓을 때, 인간이 처리해야 하는 판단과 의사결정의 빈도는 6배 차이가 난다. 속도의 이득이 주의력의 부담으로 전환되는 구조다.

4. Slow 모드의 역설적 매력: 느린 것이 더 효율적일 수 있다

이 맥락에서 글쓴이가 제안하는 아이디어가 바로 인터랙티브 코딩 에이전트를 위한 Slow 모드다. 개념은 간단하다. 이미 Anthropic의 Message Batches API가 표준 가격의 50% 할인(비동기 처리, 24시간 SLA 이내 완료 보장) 방식으로 제공되고 있는데, 이와 유사한 개념을 인터랙티브 코딩 에이전트에도 적용하자는 것이다.

즉, 내가 즉각적인 응답을 받지 않아도 되는 상황이라면, 퀄리티는 유지하되 비용은 낮추고 응답을 느리게 보내주는 옵션을 선택할 수 있으면 좋겠다는 것이다. 마치 택배에서 빠른 배송 대신 저렴한 일반 배송을 선택하는 것과 같은 논리다. Anthropic이나 OpenAI 모두 서버 워크로드에 시달리는 상황이니, 느린 응답을 수용하는 대가로 더 낮은 비용을 받는 구조가 양측 모두에게 합리적일 수 있다.

글쓴이는 Slow 모드가 특히 유용할 세 가지 시나리오를 제시한다.

첫 번째: 다른 중요한 메인 작업에 집중하는 도중 병렬로 짬짬이 보조 작업을 돌릴 때. 에이전트가 느리게 응답하면, 메인 작업에 집중하는 흐름을 끊지 않아도 된다.

두 번째: 자는 동안, 즉 6-8시간 이내에만 작업이 완료되면 되는 경우. 잠자는 시간 동안 돌아가는 비동기 작업에는 빠른 응답이 전혀 필요하지 않다.

세 번째: AI 에이전트를 쓰지 않는 별도의 집중 작업에 몰두해야 할 때. 이것이 글쓴이가 가장 중요하다고 강조하는 케이스다.

5. 핵심: “내가 병목이다”는 느낌과 효능감 하락

세 번째 시나리오가 가장 중요한 이유에 대해, 글쓴이는 솔직하게 털어놓는다. Slow 모드에서 에이전트의 토큰 비용이 절약되는 것은 사실 별로 중요하지 않다고. 그것보다 훨씬 중요한 것은 자신의 브레인 토큰 비용이 절약되는 것이라고.

문제의 핵심은 심리적인 것이다. 3-4개의 프로젝트에서 총 6-7개의 에이전트 세션을 병렬로 돌리다 보면, 창을 이리저리 돌아다니며 다음 프롬프트를 입력하느라 오히려 중요한 작업이 느려지는 느낌을 받는다고 한다. 더 나아가, ‘놀고 있는’ 세션에서 다음 지시를 기다리며 깜빡이는 AI 커서를 무시하는 것 자체에도 적지 않은 멘탈 에너지가 소모된다.

이 지점이 매우 예리하다. 알림을 무시하는 것, 기다리는 무언가에 반응하지 않는 것도 인지적 자원을 소모한다는 것은 심리학과 인지과학에서 잘 알려진 사실이다. 이른바 주의력 잔여 효과(Attention Residue) 현상으로, 하나의 일을 마치지 않은 채 다른 일로 전환할 때 이전 작업에 대한 생각이 남아 집중도를 떨어뜨리는 현상이다. 글쓴이가 경험하는 것은 AI 에이전트 시대에 등장한 이 현상의 새로운 변형이다.

결국 글쓴이는 이렇게 결론 내린다: 애초에 내가 감당할 수 있는 속도로 피드백이 오면 좋겠다. 속도를 줄여서라도 자신의 인지적 부담을 인간적인 수준으로 조절하고 싶다는 것이다.

6. Ralph 루프와 자동 오케스트레이션의 한계

글쓴이는 이에 대한 반론도 함께 검토한다. “유의미한 다음 작업을 무한히, 그리고 자동으로 줄 수 있다면 이상적이지 않냐”는 반론이다. 즉, 에이전트 간 오케스트레이션을 잘 구성해서 인간의 개입 없이도 작업이 자동으로 이어지게 하면 되지 않느냐는 것이다.

여기서 등장하는 것이 Ralph 루프(Ralph Loop) 혹은 오토리서치(Auto-research) 개념이다. 이는 AI 에이전트가 인간의 개입 없이 스스로 다음 작업을 결정하고 실행하는 자율 루프 방식을 의미한다. 이론적으로 이것이 완벽하게 동작한다면, 인간의 브레인 토큰은 거의 소모되지 않을 것이다.

그러나 글쓴이는 이것이 그리 쉽지 않다는 현실적 한계를 지적한다. Ralph 루프나 오토리서치를 돌릴 ‘소재’가 무한하지 않다는 것, 그리고 정말로 무한히 돌려버린다면 정작 자신에게 필요한 작업을 할 토큰(비용)이 없어진다는 것이다. 오케스트레이션을 잘 하면 된다는 조언도 있지만, 해법이 하나일 필요는 없다고 말한다. Slow 모드는 오케스트레이션의 대안이 아니라, 또 하나의 유효한 선택지일 수 있다는 주장이다.

7. Paul Graham의 Maker’s Schedule / Manager’s Schedule: 2009년의 통찰

글쓴이는 자신의 경험을 2009년 Paul Graham이 쓴 에세이 “Maker’s Schedule, Manager’s Schedule”에 빗댄다. 이 에세이는 오늘날에도 개발자 커뮤니티에서 널리 인용되는 고전이다.

7.1 두 가지 스케줄의 차이

폴 그레이엄은 인간의 시간 사용 방식을 두 가지 유형으로 구분했다.

매니저의 스케줄(Manager’s Schedule): 관리자, 임원, 투자자들이 사용하는 방식이다. 하루를 1시간 단위로 쪼개어, 매 시간마다 다른 일을 한다. 이 방식에서는 미팅 한 번을 잡는 것이 별로 부담스럽지 않다. 빈 슬롯을 찾아 채우면 그만이기 때문이다.

메이커의 스케줄(Maker’s Schedule): 프로그래머, 작가, 창작자들이 사용하는 방식이다. 이들은 최소 반나절 단위로 시간을 사용해야 제대로 된 일을 할 수 있다. 한 시간 단위로는 집중 상태에 들어가기도 힘들다. 그래서 미팅 하나가 잡히면 그것은 단순한 1시간 손실이 아니라, 오전 전체 또는 오후 전체가 사실상 날아가는 결과를 낳는다. 미팅이 오전 중간에 있다면, 미팅 전 시간과 미팅 후 시간이 각각 너무 짧아서 깊은 작업이 불가능해지기 때문이다.

7.2 두 스케줄이 충돌할 때

각각의 스케줄은 그 자체로는 잘 작동한다. 문제는 둘이 만날 때다. 매니저의 스케줄에 있는 사람들은 보통 더 많은 권력을 가지고 있어, 무의식적으로 주변 사람들을 자신의 주파수에 맞추려 한다. 그 결과 메이커들은 자신의 깊은 집중 시간을 지키기 위해 지속적으로 싸워야 한다.

7.3 2009년 해법: 오피스 아워와 야간 작업

폴 그레이엄은 Y Combinator를 메이커의 스케줄로 운영한다고 밝혔다. 그 해법으로 두 가지를 제시했다. 첫째는 오피스 아워 방식이다. 미팅을 하루의 끝부분에 몰아서, 핵심 메이커 시간을 보호하는 것이다. 둘째는 야간 작업이다. 자신의 스타트업 시절, 저녁 식사 후부터 새벽 3시까지 프로그래밍을 하고, 오전 11시에 일어나 낮 동안 “비즈니스 업무”를 처리하는 방식으로 사실상 하루에 두 개의 작업 모드를 분리했다.

8. 2026년의 반전: 이제 모두가 메이커이자 매니저다

폴 그레이엄의 에세이가 나온 지 17년이 지났다. 그 사이에 무엇이 달라졌는가. 글쓴이의 통찰이 빛나는 지점이 바로 여기다.

2009년의 고민은 팀장으로서 미팅 폭탄을 맞을 때 생기는 것이었다. 즉, 메이커의 역할을 하는 사람이 매니저 역할도 겸하게 될 때 발생하는 갈등이었다. 해결책은 비교적 명료했다. 미팅을 하루 끝에 몰아서 메이커 시간을 보호하거나, 아예 야간에 메이커 작업을 하는 것이었다.

그런데 2026년에는 그 구도가 근본적으로 달라졌다. AI 에이전트를 사용하는 개발자는 이제 스스로가 동시에 메이커이자 매니저가 되어야 한다. 그것도 단 한 명의 팀장이 아니라, 여러 명의 AI 에이전트를 동시에 관리하는 매니저가 된다.

변화의 내용을 구체적으로 살펴보면:

2009년: 캘린더가 쪼개졌다. 미팅 하나가 오후 전체를 날려버렸다.
2026년: 세션이 쪼개지고, 뇌가 쪼개진다. AI 에이전트 하나가 결과를 내놓을 때마다 뇌의 일부를 그쪽으로 돌려야 한다.

2009년: 문제의 원천은 외부의 타인(회의 소집자)이었다.
2026년: 문제의 원천은 자신이 스스로 만들어낸 AI 에이전트들이다.

2009년: 해결책은 시간의 배치(미팅을 하루 끝에 몰기)였다.
2026년: 해결책은 AI 에이전트의 응답 속도 조절(Slow 모드)이 될 수 있다.

9. 최신 동향: AI 에이전트 병렬 실행의 현주소 (2026)

글쓴이의 문제의식이 얼마나 시의적절한지, 최신 동향을 보면 더욱 분명해진다.

9.1 Superset IDE의 등장 (2026년 3월 1일)

2026년 3월 1일, Superset IDE라는 오픈소스 멀티에이전트 IDE가 출시되었다. Claude Code, Codex 등 다양한 AI 코딩 에이전트를 10개 이상 병렬로 실행할 수 있도록 Git worktrees를 활용해 각 에이전트를 독립된 샌드박스에서 격리하는 방식을 채택했다. 출시 직후 GitHub 트렌딩 8위에 오르며 3,285개의 스타를 받았다.

개발자들의 반응에서 핵심적인 비판이 등장했는데, 이것이 글쓴이의 통찰과 정확히 맞닿아 있다. Hacker News의 한 개발자는 이렇게 지적했다: “10개의 에이전트를 동시에 완료 상태로 만들어놓으면, ‘타이핑 시간’을 ‘읽기 시간’으로 전환하는 것뿐인데, 그게 오히려 더 나쁠 수 있다.” 사람이 병목이 된다는 문제 자체는 에이전트를 아무리 많이 병렬로 돌려도 해소되지 않는다는 것이다.

9.2 Claude Code Agent Teams (2026년 2월 6일)

Anthropic은 2026년 2월, Claude Code Agent Teams 기능을 공개했다. 단일 AI 어시스턴트가 순차적으로 작업을 처리하는 방식 대신, 여러 Claude 인스턴스가 자율적으로 조율하고 서로의 결과를 검토하며 복잡한 코드베이스를 병렬로 처리할 수 있게 해주는 패러다임 전환이었다. 한 개발자는 16개의 Claude 에이전트를 동원해 Rust 기반 C 컴파일러(Linux 커널을 컴파일할 수 있는 수준)를 처음부터 구현하기도 했다.

9.3 OpenAI Codex 서브에이전트 (2026년 3월 16일)

OpenAI는 2026년 3월 16일, Codex CLI에 서브에이전트(subagents) 기능을 전체 개발자에게 공개했다. 하나의 코딩 작업을 여러 병렬 서브에이전트로 분리 실행할 수 있게 된 것이다. 이 기능이 “한 번에 10명의 엔지니어를 돌릴 수 있다”고 과대 포장될 것이라는 지적도 함께 나왔다. 실제로는 10개의 서브에이전트가 동시에 작동하면 같은 파일을 두 에이전트가 검토하여 서로 다른 요약을 내놓는 등 충돌이 빠르게 발생한다.

9.4 Claude Code 쿼터 소진 문제 (2026년 3월 말)

더 흥미로운 것은, 최근 Claude Code 사용자들이 쿼터를 예상보다 훨씬 빠르게 소진하는 문제가 공론화되었다는 점이다. Claude Max 5 플랜($100/월)을 사용하는 개발자가 1시간 만에 쿼터를 다 써버렸다고 보고했고, Anthropic은 이것이 “예상보다 훨씬 빠르게 사용 제한에 도달하고 있다”는 사실을 공식적으로 인정하고 최우선 조사 과제로 삼겠다고 밝혔다. 에이전트 병렬 실행의 확산이 토큰 소모를 구조적으로 가속화하고 있음을 보여주는 사례다.

10. Anthropic Batch API의 현재: 이미 Slow 모드의 절반은 있다

글쓴이가 제안하는 “Slow 모드”의 개념은 사실 이미 Anthropic의 Message Batches API 형태로 부분적으로 존재한다.

10.1 Batch API의 작동 방식

Batch API는 즉각적인 응답이 필요 없는 요청들을 비동기적으로 묶어 처리하며, 표준 가격의 50% 할인이 적용된다. 모든 Claude 모델이 지원되며, 24시간 SLA 이내에 처리가 완료된다. 2026년 3월에는 Claude Opus 4.6 및 Sonnet 4.6의 Batch API에서 최대 출력 토큰 상한을 300,000 토큰으로 대폭 상향하는 베타 기능도 추가되었다.

10.2 프롬프트 캐싱과의 시너지

Batch API는 프롬프트 캐싱(표준 가격의 10% 비용으로 반복 입력 처리)과 결합하면 최대 95%까지 비용 절감이 가능하다. Opus 4.6 기준으로, 표준 입력 가격이 MTok당 $5인데, 배치 + 캐시 히트 조합 시 $0.25까지 떨어진다.

10.3 한계: 인터랙티브 세션에는 적용 불가

그러나 Batch API는 현재 비인터랙티브(non-interactive) 작업에만 적용 가능하다. 코드 리뷰, 대규모 테스트 생성, 문서화, 오프라인 분석 등에 적합하며, 개발자가 실시간으로 결과를 기다리며 다음 프롬프트를 입력하는 인터랙티브 에이전트 세션에는 사용할 수 없다.

바로 이 지점이 글쓴이의 제안이 채우려는 공백이다. 배치 처리처럼 비용이 절감되면서도 인터랙티브하게 사용할 수 있는, 즉 “느리게 응답하지만 대화는 계속 이어지는” 모드가 없다는 것이다.

11. 브레인 토큰 관리: 현실적인 전략들

글쓴이가 제기한 문제는 아직 완전한 기술적 해법이 없다. 그러나 현재 가능한 방식들을 정리하면 다음과 같다.

11.1 작업의 성격에 따른 에이전트 분류

코딩 도구 비교 연구에 따르면, Codex CLI와 Claude Code를 상호 보완적으로 사용하는 개발자들이 많아지고 있다. Codex는 처리량과 속도가 중요한 반복적 작업(boilerplate, 대규모 코드 리뷰)에, Claude는 깊이 있는 추론과 복잡한 리팩터링에 각각 활용하는 방식이다. 에이전트의 유형을 분류해 각기 다른 사이클로 작동시키면 브레인 토큰 소모를 어느 정도 분산할 수 있다.

11.2 알림 기반의 비동기 워크플로우

Superset IDE가 제시한 접근법은, 에이전트가 완료되거나 의사결정이 필요한 순간에만 알림을 보내고, 나머지 시간에는 인간이 다른 작업에 집중할 수 있게 하는 것이다. 이것은 Slow 모드 제안과 근본 방향이 같다. 에이전트가 알아서 진행하고, 인간은 필요할 때만 개입하는 비동기적 협업 구조다.

11.3 폴 그레이엄 식의 시간 블로킹 변형

2009년 폴 그레이엄의 해법을 2026년 버전으로 변형하면: AI 에이전트 세션 리뷰 시간을 특정 시간대에 집중시키고, 나머지 시간은 에이전트가 결과를 기다리더라도 자신은 깊은 집중 작업에 몰두하는 것이다. 에이전트의 커서가 깜빡여도 그것을 ‘오피스 아워 때 처리할 것’으로 분류하는 방식이다.

11.4 Claude Code의 스케줄 작업 기능

2026년 현재, Claude Code는 클라우드 스케줄 작업(Cloud Scheduled Tasks) 기능을 지원한다. Anthropic 관리 인프라에서 실행되므로, 컴퓨터가 꺼져 있어도 작업이 계속된다. 원격 제어, 모바일 앱 연동 등을 통해 세션을 다양한 환경 간에 이동할 수도 있다. 이 기능을 적극 활용하면, 잠자는 동안 돌릴 작업을 사전에 스케줄링해두고 아침에 결과만 확인하는 비동기 워크플로우를 구성할 수 있다.

12. 거시적 함의: 인간-AI 협업의 병목은 이제 인간이다

이 글이 담고 있는 가장 중요한 메시지는 기술적인 것이 아니라 인지적, 사회적인 것이다. AI 에이전트가 강력해질수록, 그 에이전트들을 지휘하고 검토하고 조율하는 인간의 인지적 부담도 함께 증가한다는 역설이다.

이것은 단순히 한 명의 개발자의 불편함이 아니다. AI 에이전트 팀을 운용하는 모든 규모의 개발 조직이 직면하게 될 근본적인 구조적 문제다. 에이전트 10개를 병렬로 돌리면 산출량이 10배가 되는 것이 아니라, 검토와 조율에 드는 인지적 비용이 점점 병목이 되면서 실효적 생산성 향상에 한계가 생긴다는 것이다.

코딩 도구 생태계의 관측자들도 이 점을 지적하고 있다. OpenAI Codex 서브에이전트를 분석한 연구에 따르면, 이 기능으로 성공하는 팀은 에이전트를 가장 많이 돌리는 팀이 아니라, 가장 명확한 질문을 하고 가장 적은 충돌로 병합하는 팀이 될 것이라고 한다. 조율(coordination)이 희소 자원이 된다는 뜻이다.

13. 결론: 속도는 수단이지 목적이 아니다

이 글이 제기하는 “모델이 느려졌으면 좋겠다”는 역설적 바람은 단순한 투정이 아니다. 그것은 AI 에이전트 시대의 생산성과 인지적 지속가능성 사이의 균형에 대한, 매우 선구적인 문제 제기다.

속도가 빠를수록 좋다는 전제는 인간이 그 속도를 감당할 수 있을 때만 성립한다. 에이전트 토큰 리밋과 달리 브레인 토큰 리밋은 돈을 더 내도 늘릴 수 없고, 밤을 새운다고 해결되지도 않는다. 오히려 과부하가 걸리면 효능감이 떨어지고, 판단 질이 낮아지며, 중요한 작업에서 오류가 늘어난다.

폴 그레이엄이 2009년에 “미팅의 비용을 이해하라”고 말했다면, 2026년의 교훈은 “AI 에이전트 속도의 비용을 이해하라”가 될 것이다. 더 빠른 것이 항상 더 좋은 것은 아니다. 자신의 브레인 토큰 리밋을 인식하고, 그에 맞게 AI 에이전트의 속도와 방식을 조율하는 것이 진정한 AI 네이티브 워크플로우의 출발점일지 모른다.

브레인 토큰 리밋은 단지 개인의 문제가 아니다. 그것은 인간-AI 협업의 지속가능한 미래를 설계하는 데 반드시 고려해야 할, 근본적인 제약이다.

참고 자료

이 문서는 2026년 4월 9일 기준 최신 정보를 반영하여 작성되었습니다.

AI, Material
AI brain-token-limit claude-code fast-mode attention-residue ralph-loop Autoresearch ai-bottleneck Claude.write
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.