---
title: '프롬프트로 일한 30일: <em>주의력</em>은 어떻게 사라지는가'
tags:
  - career
  - ai
  - essay
published: true
date: 2026-11-14 17:57:00
updated: 2026-11-14 18:15:35
description: '30일 치 기록을 세어 봤더니 한 가지 일만 60분을 한 날이 없었다'
art:
  undraw: distractions
---

## Table of Contents

## 세어 본 이유

요즘 나는 프롬프트로 일한다. Claude Code 세션을 여러 개 열어 놓고 그 사이를 오가면서 코드를 만든다. 그렇게 일하는 하루가 어떤 모양인지 궁금해서, 토요일 오전에 최근 30일 동안 내가 남긴 기록을 모아서 세어 봤다. Claude Code 세션, 슬랙 메시지, 캘린더, PR과 커밋이다.

평일에는 하루에 세션을 31개 열고 프롬프트를 232건 보냈다. 이 프롬프트로 PR을 하루 17.5개 만들었다.

그런데 평일 22일 가운데 한 가지 일만 60분 이상 한 날은 하루도 없었다. 가장 길었던 게 59분이다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=stay&hl=10-19,10-22,10-27,11-06" title="평일 22일, 하루 중 한 가지 일만 가장 오래 한 시간. 날짜가 적힌 4일은 아래에서 하나씩 살펴본다" height={300} />

여기서 한 가지 일이란 Claude Code 세션 하나 또는 슬랙 대화방 하나를 말한다. 내가 보낸 프롬프트와 슬랙 메시지를 시간순으로 늘어놓고, 다른 세션이나 다른 대화방으로 옮겨 가기 전까지를 한 덩어리로 셌다. 30분 넘게 아무것도 쓰지 않았으면 거기서 끊었다.[^1] 막대 아래에 점이 찍힌 날은 회의가 들어오지 못하게 캘린더에 집중 블록을 잡아 둔 날인데, 이 블록은 뒤에서 따로 살펴본다.

> 기간은 2026년 10월 15일부터 11월 13일까지 30일이고, 평일이 22일, 주말이 8일이다. 시각은 모두 한국 시간이다.
>
> 모은 기록은 네 가지다. Claude Code가 기기에 남기는 세션 기록(기기 두 대), 슬랙 검색으로 모은 내 메시지의 시각과 대화방, 캘린더 일정의 시각과 분류, GitHub의 PR과 리뷰, 기본 브랜치 커밋이다. 슬랙 메시지 본문과 일정 제목은 저장하지 않았다. 회사 일과 개인 작업은 구분하지 않고 합쳤다. 어디에 쓰든 주의력은 한 사람 것이기 때문이다.
>
> - **프롬프트**: 도구 결과와 명령을 빼고 내가 직접 입력한 것만 셌다. 두 기기를 서로 다른 스크립트로 집계해서 세는 기준이 완전히 같지는 않다.
> - **옮겨 다닌 횟수**: 10분 안에 이어서 쓴 것 가운데, 바로 앞과 다른 세션이나 대화방에 쓴 경우만 셌다.
> - **조용한 시간**: 평일 10~19시에 슬랙을 25분 이상 쓰지 않은 시간에서 회의 시간을 뺀 것이다. 25분보다 짧은 틈은 아예 세지 않았다. 25분은 뽀모도로 한 번의 길이에서 따온 기준이라, 기준을 바꾸면 값도 달라진다.
> - **동시에 돌아가던 세션**: 세션에 기록이 남으면 그 뒤 15분 동안은 돌아가는 것으로 보고, 분 단위로 몇 개가 겹쳤는지 셌다.
> - **회의**: 캘린더 기준이다. 실제로 참석했는지는 고려하지 않았고, 식사와 친목 일정(하루 26분)도 들어 있다.
>
> 이 기록에는 내가 쓴 것만 잡힌다. 슬랙을 읽기만 한 것, 회의에서 말한 것, 코드를 읽고 생각한 시간은 잡히지 않는다. 30분 넘게 아무것도 쓰지 않고 읽거나 생각만 했다면 그 시간은 한 가지 일을 한 시간으로 세지 않았다. 60분은 쓰는 일만 놓고 잰 값이다.
>
> 집중 블록을 잡은 날은 전부 월요일과 금요일인데, 요일에 따른 차이는 고려하지 않았다. 이직 전이나 에이전트를 쓰기 전과의 비교도, PR과 커밋 하나하나의 크기도 고려하지 않았다.

22일을 하루씩 들여다봤다. 그중 4일을 적는다.

## 가장 바빴던 목요일

10월 22일 목요일에 나는 Claude Code 세션 49개에 프롬프트를 314건 보냈고, 슬랙 대화방 21곳에 메시지를 395건 썼다. 합치면 709건으로 30일 중 가장 많다. 회의는 12시부터 18시 사이에 3개, 모두 240분이었다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=day&d=10-22" title="10월 22일의 수치. 세로선은 평일 22일의 중앙값이다" height={290} />

이날 슬랙도 회의도 없던 시간은 가장 길게 이어진 것이 4분이었다. 세션과 대화방 사이를 옮겨 다닌 횟수는 258번이다.

그렇다고 일을 못 한 날은 아니다. PR을 9개 만들었고 커밋이 42건 쌓였다. 기록만 보면 일을 많이 한 날이다. 4분이라는 숫자만 빼면 그렇다.

## 슬랙이 조용했던 화요일

이런 날을 보면 슬랙이 원인인 것 같다. 그래서 슬랙을 가장 적게 쓴 평일을 찾아봤다. 10월 27일 화요일이고, 122건을 썼다.

이날은 슬랙도 회의도 없이 25분 이상 이어진 시간이 모두 173분이었고, 그중 한 번은 101분이나 이어졌다. 22일을 통틀어 가장 길게 조용했던 시간이다. 25분은 뽀모도로 한 번의 길이에서 따온 기준이다. 그보다 짧은 틈은 무언가를 붙잡고 하기에 모자라다고 보고 세지 않았다.

그런데 이날 한 가지 일만 가장 오래 한 시간은 27분이었다. 22일 중 세 번째로 짧다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=day&d=10-27" title="10월 27일의 수치. 세로선은 평일 22일의 중앙값이다" height={290} />

조용했던 101분 동안에도 한 세션에 27분 넘게 프롬프트를 이어서 보낸 적이 없다. 세션을 옮겨 다녔거나, 30분 넘게 아무것도 쓰지 않았다는 뜻이다. 이날 보낸 프롬프트는 200건, 연 세션은 18개였다.

슬랙이 조용해도 60분은 나오지 않았다. 슬랙 말고도 이유가 하나 더 있었다.

## AI가 늘린 세션 전환

AI 때문에 세션 전환이 많아졌다. 에이전트를 쓰기 전의 기록은 남아 있지 않아서 얼마나 늘었는지 숫자로 보여 줄 수는 없다. 하지만 왜 늘었는지는 기록에 그대로 드러난다.

AI를 쓰기 전에는 이 정도로 정신없이 세션을 오갈 수가 없었다. 코드를 직접 칠 때는 내가 손을 떼면 그 일도 멈췄다. 다른 일로 넘어가면 하던 일은 그대로 멈춰 있었으니, 한꺼번에 벌여 놓을 수 있는 일의 수에 한계가 있었다.

지금은 내가 다른 곳을 보고 있어도 일이 진행된다. 프롬프트를 보내고 나면 에이전트가 일하는 몇 분 동안 손이 빈다. 그 몇 분을 기다리지 않고 다른 세션을 연다. 그 세션도 일을 시작하면 또 손이 비니, 세 번째 세션을 열거나 슬랙을 본다. 오갈 수 있게 되니까 오가는 것이다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=sessions" title="동시에 돌아가던 세션 수와 한 세션에 연달아 보낸 프롬프트 수" height={340} />

하루에 연 세션 31개는 겹쳐서 돌아갔다. 세션이 하나라도 돌아가던 시간 가운데 44%는 두 개 이상이, 17%는 세 개 이상이 같이 돌아갔다. 가장 많을 때는 8개가 한꺼번에 돌았다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=sessday&hl=10-22,10-27,11-06" title="30일 동안 날마다 연 Claude Code 세션 수. 옅은 띠는 주말이다" height={260} />

프롬프트를 보낸 순서를 봐도 마찬가지다. 세 번에 한 번은 바로 앞과 다른 세션으로 보냈다. 한 세션에 프롬프트를 딱 한 건만 보내고 다른 세션으로 넘어간 경우가 47%이고, 10건 이상 이어서 보낸 경우는 6%뿐이다.

에이전트와 슬랙 사이도 오간다. 평일 하루에 211번을 옮겨 다녔는데, 그중 58%가 Claude Code와 슬랙 사이였다. 프롬프트를 보내고, 기다리는 동안 슬랙에 답하고, 돌아와서 다음 프롬프트를 보내는 식이다.

이렇게 일하면 일 하나의 크기도 작아진다. 평일 하루에 PR을 17.5개 만들었고, PR 하나에 프롬프트가 13건 들었다. PR은 대부분 만든 지 5분 안에 병합됐다.[^2] 프롬프트 13건이면 끝나고 5분 뒤에 병합되는 일을 60분씩 붙잡고 있을 이유가 없다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=make&hl=10-29,11-06" title="30일 동안 날마다 만든 PR. 옅은 띠는 주말이다" height={260} />

22일 중 한 가지 일만 가장 오래 한 날은 11월 6일 금요일(59분)이다. 그날 만든 PR은 2개로, 22일 중 가장 적었다. 하루뿐인 사례라 규칙이라고 하기는 어렵다.

결과물만 보면 이 방식은 잘 굴러간다. 30일 동안 PR을 452개 만들었다. 그 대신 한 가지 일을 오래 붙잡고 있는 시간이 없어졌다.

## 혼자 만드는 서비스

이 속도가 동료들에게 어떤 영향을 줄지도 생각해 봤다. 하루 17.5개씩 나오고 대부분 5분 안에 병합되는 PR을 팀이 다 읽을 수는 없다. 아마 따라오기 힘들 것이다.

실제로 지금 만들고 있는 서비스는 계속 혼자 하고 있다.

혼자 하면 빠르다. 대신 이 코드를 아는 사람이 나 하나가 된다. 번들 크기나 순환 import처럼 기계가 검사할 수 있는 것은 [성능 개선 글](/2026/10/performance-improvement-workflow)에서 정리한 장치들이 지켜 준다. 하지만 구조가 일관된지, 다른 사람이 이어받을 수 있는지는 누군가 읽어 줘야 알 수 있다. 나는 그걸 읽어 줄 사람이 따라오지 못하는 속도로 만들고 있다.

리뷰는 나도 한다. 같은 30일 동안 PR 498개에 리뷰를 564건 남겼다. 리뷰한 PR이 내가 만든 PR(452개)보다 많다. 평일 하루 24건이고, 가장 많았던 11월 4일 수요일에는 PR을 25개 만들면서 47개에 리뷰를 48건 남겼다. 564건 가운데 487건이 승인이고, 68건은 코멘트만 남긴 리뷰다.

꼼꼼하게 보는 것은 봐 달라는 요청이 온 경우다. 대부분은 쓱 보고 이슈가 없으면 승인을 누르거나, 내가 봐야 할 중요한 것만 리뷰한다. 일종의 허브 역할이다.

## 집중 블록을 잡아 둔 월요일과 금요일

집중 블록은 내가 내 캘린더에 직접 잡아 두는 일정이다. Tanya Reilly의 [The Staff Engineer's Path](https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/)를 참고해서 잡기 시작했다. 그 시간에는 회의를 잡지 말아 달라는 표시이고, 나도 그 시간만큼은 한 가지 일에 쓰려고 비워 둔다. 매주 월요일과 금요일 14시부터 19시까지 300분씩 잡아 두고 있어서, 22일 중 9일(월요일 4일, 금요일 5일)에 이 블록이 있었다.

10월 19일 월요일도 블록이 있던 날이다. 그런데 이날은 슬랙도 회의도 없이 25분을 넘긴 적이 한 번도 없다. 가장 길게 조용했던 시간이 18분이다. 회의가 4개 240분 있었고 세션은 44개를 열었다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=day&d=10-19" title="10월 19일의 수치. 세로선은 평일 22일의 중앙값이다" height={290} />

블록을 잡아 둬도 그 시간에 회의가 겹쳐서 들어왔다. 10월 19일의 마지막 회의는 17시 30분에 끝났다. 블록을 잡은 9일 가운데 6일은 블록이 시작되는 14시 이후에도 회의가 있었다. 10월 30일 금요일에는 10시부터 19시 사이에 회의가 480분 잡혀서, 블록 300분 가운데 적어도 240분이 회의와 겹쳤다.

회의가 겹치지 않은 날도 있다. 앞에서 본 11월 6일 금요일은 회의가 14시에 끝나서 블록 300분에 회의가 하나도 겹치지 않았다. 22일 중 한 가지 일만 가장 오래 한 날이지만 그래도 59분이었고, 이날도 세션을 14개 열고 슬랙 메시지를 201건 썼다.

<BarCompare title="집중 블록을 잡은 날과 아닌 날의 시간" unit="분" before="블록이 없는 날" after="블록을 잡은 날" rows="슬랙도 회의도 없이 25분 이상 이어진 시간|76|103;한 가지 일만 가장 오래 한 시간(중앙값)|35|35" />

9일 평균으로 보면, 300분을 비워 두고 늘어난 조용한 시간은 27분이다. 그 27분도 금요일에서만 나왔다. 월요일 4일은 77분으로 블록이 없는 날(76분)과 거의 같았고, 금요일 5일은 124분이었다. 한 가지 일만 가장 오래 한 시간은 블록이 없는 날과 같았다.

<BarCompare title="집중 블록을 잡은 날과 아닌 날의 슬랙 메시지" unit="건" before="블록이 없는 날" after="블록을 잡은 날" rows="슬랙 전체|315|219;팀 동료들과의 대화방|103|26;그 밖의 슬랙|212|192" />

블록을 잡은 날에는 슬랙을 96건 덜 썼다. 그중 77건은 팀 동료들과 일 이야기를 하는 대화방에서 줄었다. 내가 슬랙에서 가장 많이 쓰는 방인데, 화요일부터 목요일까지는 하루 100건 안팎이고 월요일은 13건, 금요일은 37건이다. 팀 동료들과의 대화는 블록이 있는 날 확실히 줄어든다. 나머지 슬랙은 블록이 있어도 20건밖에 줄지 않았다.

집중 블록이 막을 수 있는 것은 회의뿐이고, 그 회의도 다 막지는 못했다. 한 가지 일을 오래 하는 데는 전혀 도움이 되지 않았다. 블록을 잡아 둔 14시부터 19시 사이에도 프롬프트와 슬랙 메시지를 하루 평균 196건 썼다. 92초에 한 건꼴이고, 블록이 없는 화요일부터 목요일까지의 같은 시간대(243건)보다 19% 적다.

## 평일 하루의 모양

22일을 전부 겹쳐 놓으면 이런 모양이 된다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=heatmap" title="요일과 시간대별로 직접 쓴 프롬프트와 슬랙 메시지, 그리고 시간대별 커밋" height={470} />

평일 10시부터 19시까지 프롬프트와 슬랙 메시지를 하루 367건 쓴다. 88초에 한 건꼴이다. 가장 진한 칸은 목요일 16시대로, 한 시간에 87건, 41초에 한 건꼴이다. 점심때인 12시대에만 절반으로 줄고, 19시대는 하루 중 두 번째로 바쁘다.

이 시간에 내가 하는 일은 네 가지다.

첫째는 만드는 일이다. 앞에서 본 세션 31개와 PR 17.5개가 여기서 나온다.

둘째는 회의다. 평일 10시부터 19시까지 540분 가운데 203분, 38%가 회의다. 회의 시간의 62%는 챕터와 기술 공동체 일이고, 22일 중 19일에 있었다. 회의 중에도 슬랙을 쓴다. 회의 203분 가운데 슬랙을 쓰지 않고 25분 이상 이어진 시간은 많아야 82분이다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=meet" title="평일 10~19시 가운데 회의 시간과 그 구성" height={300} />

셋째는 팀 동료들과의 대화다. 앞에서 말한 그 대화방 하나에 31일 동안 1,577건을 썼다. 내가 쓴 슬랙 메시지 6,207건의 25%다. 글자 수 중앙값이 9자일 만큼 짧은 말을 하루 75건씩 주고받는다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=slack" title="슬랙 메시지를 쓴 곳과 팀 동료들과의 대화방 요일별 메시지 수" height={490} />

넷째는 팀 밖에서 오는 질문에 답하는 일이다. 채널에 쓴 글 3,227건 가운데 3,133건, 97%가 스레드에 단 답글이다. 31일 동안 채널에 새로 쓴 글은 94건뿐이다. 답글은 우리 팀 채널(908건)보다 팀 밖 채널(2,097건)에 2.3배 많이 썼다. 여기에 일대일 DM이 1,394건 더 있다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=reply" title="채널에 쓴 글 가운데 답글의 비중과 답글을 쓴 채널" height={210} />

네 가지 다 내 일이고 뺄 수 있는 것이 없다. 문제는 네 가지가 전부 10시에서 19시 사이에 몰려 있다는 점이다.

Paul Graham은 2009년에 쓴 글에서 만드는 사람의 시간표와 관리자의 시간표가 다르다고 했다. 관리자는 하루를 한 시간 단위로 나눠 쓰고, 만드는 사람은 적어도 반나절은 통째로 쓰고 싶어 한다. 회의가 하나만 끼어도 오후가 두 토막이 나는데, 두 토막 모두 어려운 일을 하기에는 짧아서 오후를 통째로 날리게 된다는 것이다.[^3] 내 하루에는 두 시간표가 같이 들어 있다. 거기에 분 단위로 오는 슬랙과, 에이전트를 기다리는 몇 분이 더해진다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=window&hl=10-19,10-22,10-27,10-30" title="평일 22일의 10~19시 540분을 어디에 썼는가" height={340} />

540분에서 회의 203분을 빼면 337분이 남는다. 그중 슬랙도 회의도 없이 25분 이상 이어진 시간은 하루 평균 87분이다. 0분인 날이 2일 있었고, 90분 넘게 이어진 것은 22일을 통틀어 앞에서 본 10월 27일 한 번뿐이다.

일이 잘게 쪼개지는 것이 새로운 이야기는 아니다. González와 Mark는 2004년에 분석가, 소프트웨어 개발자, 관리자를 하루 종일 따라다니며 관찰했다. 사람들은 한 가지 작업을 평균 3분 하고 다른 작업으로 넘어갔고, 같은 주제의 일끼리 묶어서 봐도(논문에서는 working sphere라고 부른다) 평균 12분이었다. 한 사람이 동시에 걸쳐 있는 일은 평균 10가지였다.[^4] 20년 전 사무실도 이미 그랬다. 다만 그때는 열 가지에 걸쳐 있어도 한 번에 하나만 진행할 수 있었고, 지금은 세션을 여는 만큼 진행된다. 미룰 이유가 줄어든 만큼 전부를 한꺼번에 붙잡게 됐다.

## 저녁과 주말

이렇게 일해도 만들어 내는 양은 줄지 않는다. Mark와 Gudith, Klocke의 2008년 실험에서도, 방해를 받은 사람들은 오히려 과제를 더 빨리 끝냈고 품질에도 차이가 없었다. 더 서둘러서 방해받은 시간을 메운 셈인데, 대신 스트레스와 좌절감이 커졌고, 시간에 더 쫓겼고, 힘이 더 들었다.[^5]

스트레스는 기록에 남지 않는다. 시각은 남는다.

<LiveDemo src="/demos/how-attention-disappears/index.html?view=daily&hl=10-17,10-24" title="30일 동안 날마다 쓴 프롬프트와 슬랙 메시지. 옅은 띠는 주말이다" height={310} />

평일에 쓴 프롬프트와 슬랙 메시지의 21.5%는 19시 이후에 쓴 것이다. 평일 22일 중 13일은 마지막 커밋이 22시를 넘겼다.

주말도 비슷하다. 10월 17일 토요일에는 프롬프트를 173건 보냈고 커밋이 103건 쌓였다. 커밋 수로는 30일 중 가장 많은 날이다. 10월 24일 토요일은 FEConf에서 발표한 날이자 내 생일이었다. 30일 중 PR을 하나도 만들지 않은 유일한 날인데, 그날도 프롬프트는 47건 보냈다. 주말 8일 중 7일에 PR을 만들었고, 주말에도 커밋은 하루 40건으로 평일과 같았다. 같은 30일 동안 블로그에는 글을 13편 올렸다.

<BarCompare title="평일과 주말의 하루 평균" unit="건" before="평일" after="주말" rows="프롬프트|232|112;슬랙 메시지|275|19;커밋|40|40;PR|17.5|8.4" />

30일 동안 프롬프트도 커밋도 없던 날은 하루도 없다.

## 주의력이 사라진 방식

주의력이 어떻게 사라졌는지는 세어 보고서야 알았다. 한꺼번에 사라진 게 아니었다. 88초에 한 번씩, 프롬프트 하나와 답글 하나에 조금씩 빠져나갔다.

원인을 하나로 꼽을 수도 없다. 슬랙이 조용한 날에도, 집중 블록을 잡은 날에도 60분은 나오지 않았다. 에이전트로 일하는 방식, 회의, 팀 안의 대화, 팀 밖에 다는 답글이 전부 같은 시간대에 겹쳐 있다.

그렇게 쪼개져도 일은 멈추지 않는다. 내가 다른 세션을 보는 동안에도 에이전트는 일을 하고, 그래서 한 가지 일만 60분 이상 한 날이 하루도 없었는데 PR은 하루 17.5개씩 나왔다.

만들어 내는 양이 줄지 않으니, 세어 보기 전에는 이런 상태인 줄 알기 어렵다. PR과 커밋은 계속 잘 나오기 때문이다.

## 받은 권고

기록을 같이 센 Claude에게 지금 내 상태가 어때 보이는지, 무엇을 바꾸면 좋을지 물었다. 과부하인데 결과물이 잘 나와서 문제가 보이지 않는 상태라는 답이 돌아왔다. 주의력보다 쉬는 날이 없는 것이 더 급하다고도 했다. 권고는 네 가지였다.

| 권고                                                 | 지금                            |
| ---------------------------------------------------- | ------------------------------- |
| 일주일에 하루는 프롬프트도 커밋도 없는 날로 비운다   | 30일 중 0일                     |
| 동시에 여는 세션을 2개까지로 줄여서 2주 동안 해 본다 | 3개 이상이 같이 돌아간 시간 17% |
| 챕터 일을 얼마나 할지 정한다                         | 하루 147분, 회의의 62%          |
| 집중 블록 시간에는 세션을 하나만 열고 슬랙을 닫는다  | 300분을 비우고 27분을 얻음      |

두 번째 권고에는 단서가 붙어 있었다. 세션을 2개로 줄이면 하루 17.5개씩 나가던 PR도 줄어든다. 줄어드는 PR과 60분을 맞바꿔야 한다. 세 번째 권고의 이유는 이랬다. 회의 시간의 62%가 챕터 일이라, 만드는 시간을 늘리려면 여기부터 정해야 한다고 했다.

## 건수로 보이지 않는 것

이런 하루가 나만의 일은 아닌 것 같다. UC 버클리의 Ranganathan과 Ye는 미국의 한 기술 회사 직원 200명을 2025년 4월부터 12월까지 조사하고, AI가 일을 줄이지 않고 오히려 일의 강도를 높였다고 보고했다. 사람들은 에이전트를 여러 개 동시에 돌리면서 여러 일을 한꺼번에 붙잡았고, 일이 잘되고 있다고 느끼면서도 늘 여러 일 사이를 오가고 있다는 기분이 들었다고 한다.[^6]

PR이 늘어나는 만큼 리뷰가 밀리는 것도 여러 팀에서 확인됐다. Faros AI가 개발자 1만여 명, 1,255개 팀의 기록을 분석한 보고서에 따르면, AI를 많이 쓰는 팀의 개발자는 PR을 98% 더 병합했고 PR 리뷰에 걸리는 시간은 91% 늘었다. 그런데 회사 단위의 지표에서는 개선이 확인되지 않았다.[^7]

나도 이 흐름 안에 있고, 숫자로 보면 더 심하다. LinearB가 PR 810만 개로 만든 기준표에서 상위 10% 조직은 개발자 한 명이 일주일에 PR을 2개 넘게 병합한다.[^8] 나는 일주일에 83개를 병합했다. Microsoft의 집계로는 평균적인 직장인이 평일 하루에 Teams 메시지를 153건 받는데, 나는 슬랙 메시지를 하루 275건 쓴다. 메시지와 회의 초대를 가장 많이 받는 상위 20%가 근무 시간에 2분마다 한 번씩 알림을 받는다는데, 나는 88초마다 한 번씩 무언가를 쓰고 있었다.[^9]

이렇게 열심히 일한다고 해서 내가 좋은 개발자인지, 좋은 동료인지, 좋은 평가를 받는지는 다른 문제다. 이 부분은 여전히 확신이 없다.

[^1]: 한 가지 일만 한 시간, 세션과 대화방을 옮겨 다닌 횟수, 슬랙을 쓰지 않은 시간은 프롬프트의 86%가 나온 기기 한 대와 슬랙만으로 계산했다. 다른 한 대의 세션까지 시각을 맞춰 합치면 더 짧아진다. 동시에 돌아가던 세션 수와 연달아 보낸 프롬프트 수는 기기마다 따로 센 뒤 더했다.

[^2]: PR 452개 중 한 계정의 424개로 구한 값이다. 병합까지 걸린 시간의 중앙값을 날마다 구했고, 그 값들의 중앙값이 5분이다. 값이 있는 27일 중 18일이 10분 이하였다.

[^3]: Paul Graham, [Maker's Schedule, Manager's Schedule](https://paulgraham.com/makersschedule.html) (2009년 7월). 원문은 "A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."이다.

[^4]: Victor M. González, Gloria Mark, ["Constant, Constant, Multi-tasking Craziness": Managing Multiple Working Spheres](https://ics.uci.edu/~gmark/CHI2004.pdf) (CHI 2004). 초록에 "People average about three minutes on a task", "people spend about 12 minutes in a working sphere before they switch to another"라고 적혀 있다.

[^5]: Gloria Mark, Daniela Gudith, Ulrich Klocke, [The Cost of Interrupted Work: More Speed and Stress](https://ics.uci.edu/~gmark/chi08-mark.pdf) (CHI 2008). 초록에 "people completed interrupted tasks in less time with no difference in quality", "this comes at a price: experiencing more stress, higher frustration, time pressure and effort"라고 적혀 있다.

[^6]: Aruna Ranganathan, Xingqi Maggie Ye, [AI Doesn't Reduce Work: It Intensifies It](https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it) (Harvard Business Review, 2026년 2월). 인용문은 Simon Willison이 [옮겨 적은 대목](https://simonwillison.net/2026/Feb/9/ai-intensifies-work/)에서 가져왔다. "AI introduced a new rhythm in which workers managed several active threads at once", "a sense of always juggling, even as the work felt productive"라고 적혀 있다.

[^7]: Faros AI, [The AI Productivity Paradox Report 2025](https://www.faros.ai/blog/ai-productivity-paradox-report-2025) (2025년 7월). "Developers on teams with high AI adoption complete 21% more tasks and merge 98% more pull requests", "PR review time increases 91%", "we observed no significant correlation between AI adoption and improvements at the company level"이라고 적혀 있다. 팀마다 AI를 가장 적게 쓴 두 분기와 가장 많이 쓴 두 분기를 비교한 상관 분석이고, 개발 조직의 지표를 분석하는 제품을 만드는 회사가 낸 보고서다.

[^8]: LinearB, [2026 Software Engineering Benchmarks Report](https://linearb.io/resources/engineering-benchmarks-report). PR 8,109,244개와 4,813개 팀을 분석한 보고서다. 기준표의 Merge Frequency(per dev/week)는 상위 10%인 Elite가 2.0 초과, 하위 40%가 0.66 미만이다. 내 값은 30일 동안 병합된 PR 357개를 주 단위로 환산한 것이다.

[^9]: Microsoft, [Breaking down the infinite workday](https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday) (Work Trend Index Special Report, 2025년 6월). "The average worker receives 153 Teams messages per weekday."라고 적혀 있다. 2분 간격은 방법론에 "The two-minute figure reflects the average time between pings during an eight-hour workday.", "Based on the top 20% of users by ping volume received."라고 설명돼 있다.