글쓴이는 변호사도 의사도 아니다. 본문에 등장하는 의료·법조 비유는 외부에서 관찰한 것을 바탕으로 했기 때문에 디테일에서 엄밀하지 못한 부분이 있을 수 있다. 결정 밀도와 컨텍스트 운영의 큰 그림에 초점을 두고 읽어주시면 좋겠다.
1. 생산성 폭발이 아니라 결정 피로
AI와 개발자가 같이 일하는 방식에 대해 이런저런 글을 봐 왔지만, 정작 내가 하루하루 겪고있는 상황은 흔히 얘기하는 "생산성 폭발" 과는 결이 좀 달랐다. 만드는 속도는 확실히 빨라졌다. 그런데 동시에 무언가 묘하게 피곤했다. 그러나 정확히 이 피로감이 어디에서부터 오는 것인지는 말로 설명하기 어려웠다.
며칠을 자문해 본 뒤에야 실체가 잡히기 시작했다. AI는 내게 무엇을 만들지가 아니라 무엇을 선택할지를 끊임없이 묻는다. "이 에러의 근본 원인을 파고들까요, 아니면 증상만 가릴까요?" "A안과 B안 중 어느 쪽으로?" "이 기능을 이번 이터레이션에 포함할까요?" 생산성은 터졌는데 그로부터 비롯되는 의사결정의 양도 폭발적으로 증가한것이다.
이 글은 그 피로의 정체를 뜯어보고, 이미 비슷한 부담을 안고 살아온 전문직(의료·법조)을 거울 삼아 — 구조가 보이면 대응도 보이지 않을까 하는 생각으로 출발했다.
2. 풍경: 대학병원의 3분 진료
예전에 와이프가 항암치료를 한 적이 있다. 대학병원 종양내과 선생님은 정말 3분 안에 이전 검사 결과를 훑고, 상태를 확인하고, 다음 치료 방침을 말하고, 다음 환자로 넘어갔다. 왜 "3분 진료" 라는 말이 있는지 그때 이해했다. 환자 입장에선 야속하지만 의사 입장에선 그 속도로 돌리지 않으면 오늘 진료가 끝나지 않는다.
이건 결정 밀도(decision density) 가 높은 직업에서 보이는 전형적인 풍경이다. 3분마다 해야하는 판단이 하나씩, 하루 수십 건 많게는 수백건, 이건 의사만의 이야기가 아닐것이다. 가석방 심사나 영장 발부처럼 짧은 결정을 하루에 수십 건씩 내리는 판사도 마찬가지다. 판사도 사람인지라 판결 시간대에 따라 결정이 달라진다는 흥미로운 연구가 있는데, 점심시간 직전에는 가석방 인용률이 거의 0%, 점심 직후엔 65%까지 올라갔다고 한다. 변호사도 매터(matter)별 결정이 연달아 들어온다. 결정 밀도가 높은 전문직은 늘 존재했다.
AI와 일하면서 내가 느끼는 것은 개발자라는 직업의 풍경이 그쪽으로 급하게 이동하고 있다는 감각이었다. 코드를 쓰는 시간은 줄고, 판단을 내리는 시간이 늘었다. 만드는 시간이 0에 수렴할수록 남은 일은 "무엇을 만들지" "왜 만들지" "어느 쪽이 나은지" 를 고르는 일이다.
3. 유비추리는 반만 맞다
처음엔 "개발자도 이제 대학병원 종양내과 의사처럼 일을 해야하는구나" 로 정리하려 했다. 근데 좀 자세히 뜯어보니 세부 사항이 맞지 않았다.
개발자가 AI에게 하는 목록들을 써보면 이렇다. "이 버그의 근본 원인이 무엇이냐 " 같은 진단형 질문. "이 문제를 해결하는 접근법을 세 개 제안해줘" 같은 치료 선택형 질문. 이 두가지 유형의 질문에 대한 답은 거의 완전히 AI에게 위임될 수 있는데, 이게 바로 종양내과 의사의 본업과 일치한다는 것이다. 진단하기 그리고 치료방법 선택하기.
그렇다면 개발자 손에는 이제 무슨 숙제가 남아있는가. 트레이드오프 결정 (속도 vs 안정성, 단순 vs 유연). 범위 결정 (이 기능 포함할까, 지금 건드릴까). 취향과 스타일 (네이밍, 폴더 구조). 그리고 가장 어려운 문제인 제품과 사업 차원의 판단들. "어떻게 만들까" 는 이미 AI에게 넘어갔고, "왜 · 무엇을 · 어디까지" 할 것인지만 내 손에 남아있다. 이제 유비를 다시 찾아야 한다.
4. 세 축으로 본 구조적 이동
짚어보면 개발자의 업무 중 AI 때문에 이동한 축은 하나가 아니다. 적어도 세 갈래의 축이 동시에 움직였다.
축 1: 결정 밀도. 단위 시간당 내려야 하는 판단 수가 급증했다. 전에는 개발자가 한가지 이슈를 붙잡고 종일 고민할 수 있었지만 이제는 AI가 분단위로 결정 후보를 물어오기 때문에 필연적으로 내려야 하는 결정의 밀도가 증가한다.
축 2: 컨텍스트의 지속성. 의사는 환자별로 차트를 닫고 다음으로 넘어갈 수 있고(wipe out) 판사도 사건별로 기록에 외부화하고 기억을 비운다. 반면 변호사는 한 의뢰인을 여러 해 달고 다닌다. 매번 단기성의 wipe out을 할 수 없기 때문에 잔여 컨텍스트가 여전히 머리에 남게되는데, 이 부분이 AI와 함께 일하는 개발자의 업무 방식과 일치하는 지점이다.
축 3: 병렬성. 예전에는 한 번에 한 가지만 수행하던 내가 이제는 여러 AI 에이전트를 동시에 돌린다. 터미널 셋, 에이전트 둘, 브라우저에 프리뷰 하나. 그러나 여기서 한계가 발생한다. AI 는 무한한 병렬 실행을 하지만, 이에 따른 판단과 결정을 내려야 해야 하는 인간의 주의력은 여전히 직렬수행에 머물러 있다는 점이다.
이 세 축의 교차점에 뭐가 있는지 매트릭스로 그려봤다.
의사·판사는 오른쪽 아래에 있다. 결정 밀도는 높지만 wipe out이 가능하다. 내가 있는 자리는 오른쪽 위다. 한정된 앱을 장기로 들고 있고, 결정의 밀도는 의사·판사 처럼 높아졌으며, 여기에 병렬성까지 얹힌다.
이 사분면은 전통적으로 로펌 파트너의 자리 였다.
5. 변호사의 사분면, 그리고 결정 큐의 동시성
로펌 파트너의 하루를 상상해 보자. 여러 매터가 병렬로 돌고, 각 매터는 장기간 유지된다. 오전엔 A 의뢰인 서면 검토, 정오엔 B 의뢰인 전화, 오후엔 C 매터 전략 회의. 결정 밀도도 높고, 매터마다 컨텍스트가 두껍게 쌓여 있다.
그런데 파트너가 버틸 수 있는 이유가 있다. 판단이 그의 책상 위에 도달하기 전에 이미 파라리걸과 주니어 어소시에이트가 이들을 한 바퀴 필터링 하고, 또 매터별로 어떤 상황이 오면 어떻게 대응한다는 표준 대응이 프로토콜화되어 있기 때문에 파트너는 정말 그의 판단이 필요한 것만 본다는 것이다.
내가 지금 겪는 성장통과 비교해 보자. 여러 AI 에이전트가 동시에 "결정해주세요" 를 핑 날린다. 순차로 오지 않는다. 동시에 온다. 한쪽은 "이 방향으로 갈까요", 다른 쪽은 "이 에러는 어떻게 처리할까요", 또 다른 쪽은 "범위가 커지는데 어떻게 할까요".
그러면 나는 무엇이 되는가 파트너 + 파라리걸 + 비서를 한 사람이 겸직하는 상태가 된다. 판단 전 필터링을 해줄 사람이 없다. 타임 블록을 강제해 줄 법정 일정도, 회의실 예약도 없다. 핑이 울리면 울리는 대로 받아야 하고, 받은 순간부터 스위칭 비용이 시작된다.
이것이 내가 느꼈던 피로의 정체였다. 결정의 수가 문제가 아니라 결정의 동시 도착이 문제였다. 밀도가 아니라 결정 큐의 동시성.
6. 원칙 — 증거 기반 결정 (Evidence over Hypothetical)
이 구조가 보이고 나서야 내가 AI에게 받는 질문의 본질이 달리 보이기 시작했다.
그동안 나는 "A안과 B안 중 어느 쪽으로?" 같은 추상적 선택지를 받을 때, 나는 실제로 머릿속에서 A안과 B안을 각각 시뮬레이션해보며 판단했는데, 생각해보면 이건 사치스러운 일이다. AI 덕분에 생산 비용이 0에 수렴하는 시대에 인간의 머릿속 시뮬레이션이 가장 비싸다.
그래서 내가 도달한 규범은 이렇다.
생산 비용이 0에 수렴할수록, 물어보기 전에 만들어서 결과를 놓고 판단하게 유도하라.
"A로 할까요 B로 할까요" 대신 "A·B 두개 preview 만들어서 올려놨습니다. 확인해서 어느 쪽으로 할까요?" 를 받아야 한다. 의사도 판사도 그렇게 일한다. 증거를 보고 판단하지 가설만 보고 판단하지 않는다. 추상 선택지는 인간을 철학자로 만들고, 구체 결과물은 판사로 만든다.
이걸 이 글에서는 증거 기반 결정 원칙(Evidence over Hypothetical) 이라고 부르기로 한다. 이 원칙은 뒤에서 얘기할 대응 장치의 뿌리가 된다.
7. 대응은 두 갈래 — AI 측의 자동화, 인간 측의 스케줄링
결정 큐의 동시성을 다루는 방법을 찾다가 길이 두 갈래로 갈린다는 걸 알았다. 처음엔 한쪽은 "엔지니어링", 한쪽은 "개인 루틴"으로 갈라지는 줄 알았는데 더 자세히 보니 그게 아니었다. 진짜 경계는 다른 데 있다 — AI가 대신할 수 있는 일과, 인간만 할 수 있는 일.
갈래 1: 산출물의 자동화 — AI가 만들 수 있는 건 다 AI에게
AI가 일하는 환경을 조정하는 쪽이다. AI에게 "이런 유형의 결정은 혼자 내려도 된다"고 자율권을 주고, 반복되는 결정은 프로젝트별 표준 대응으로 문서화하고, 앞서 말한 증거 기반 패턴을 강제해 추상 질문 자체가 올라오지 않게 한다. CLAUDE.md, DECISIONS.md, 에이전트별 프리앰블, 서브에이전트 위임 패턴 — 다 이 갈래다.
여기서 한 발 더 나아가면, 변호사에게 필요한 케이스 파일도 사실 이 갈래로 흡수된다. "응답 끝낼 때마다 STATE.md 갱신해" 같은 한 줄 시스템 프롬프트로 끝난다. 결정 로그, 스위치 메모, 컨텍스트 요약 — AI가 산출할 수 있는 모든 문서는 다 하니스의 영역이다. 요컨대 파트너 책상 위에 올라오는 쟁점을 파라리걸 단계에서 걸러내고, 케이스 파일까지 정리해 올려두는 시스템을 엔지니어링으로 짓는 것이다.
갈래 2: 인간 스케줄러 — 직렬 주의력의 컨텍스트 스위칭 최적화
생각해보면 이건 OS의 스케줄러 문제와 정확히 같다. CPU가 한 번에 한 프로세스만 돌릴 수 있어서 어떤 프로세스를 언제 올리고, 언제 내리고, 컨텍스트 스위칭 비용을 어떻게 줄일지 OS가 정교하게 설계되는데, 갈래 2는 CPU 자리에 인간의 주의력이 들어간 것이다. 용어가 그대로 옮겨 붙는다.
- 스케줄링 정책: 들어오는 핑을 즉시 처리할지(인터럽트), 큐에 쌓아 안전한 지점에서 일괄 처리할지(쿠퍼러티브). "딥 워크" 류의 조언은 다 쿠퍼러티브 스케줄링 권고다. (어쩌면 터미널 알림을 끄는 것이 당신의 생산성을 높여줄지도 모른다.)
- 컨텍스트 스위칭 비용: OS는 사이클로, 인간은 "다시 매터에 머리를 올리는 데 걸리는 시간"으로 잰다. 케이스 파일은 캐시 워밍업이다 — 비워졌던 컨텍스트를 빠르게 재구성한다.
- 로컬리티: 같은 매터의 관련 작업을 같은 타임 블록에 묶는다. 캐시가 따뜻할 때 한꺼번에 처리하라는 얘기.
- 레이트 리미팅: 들어오는 핑이 너무 많으면 큐에 쌓아 스로틀한다. 절대 인터럽트로 받지 않는다.
위에서 소개했던 의사·판사 예시는 stateless에 가까운 단순 스케줄링이다 — 환자/사건마다 wipe out하면 그만이다. 변호사 예시는 매터별로 풍부한 컨텍스트를 짊어지고 다니는, 상대적으로 stateful한 스케줄링이고, 그래서 케이스 파일과 일정 블록 같은 정교한 스위칭 보조장치가 발달했다. 우리가 주목해야 할 방식도 대형 로펌의 시니어 변호사 쪽이 아닐까 생각해본다.
두 갈래가 분리되는 이유
같은 도구로 풀리지 않기 때문이다. 갈래 1은 AI가 산출할 수 있는 모든 것을 자동화하는 일 — 프롬프트, 스크립트, 파일 구조의 영역. 갈래 2는 그 산출물을 인간 한 사람의 직렬 주의력에 어떻게 분배할지 — 즉, 인간용 스케줄러를 튜닝하는 일 — 캘린더, 큐, 스위칭 의식의 영역.
그리고 이게 중요한데, 갈래 1이 아무리 완벽해져도 갈래 2의 부담이 0이 되지는 않는다. 오히려 갈래 1이 잘 될수록 갈래 2의 부담이 더 도드라진다 — 큐에 들어오는 산출물의 양이 늘어나니까. 멀티코어 시대에 OS 스케줄러가 더 정교해진 것과 같은 현상이다. 이게 내가 며칠 자문하면서 잡힌 피로의 진짜 정체였다.
8. 남는 것 — 판단의 질은 하니스와 스케줄러의 질
여기까지 정리하고 나니 한 가지가 선명해졌다. 만드는 사람에서 판단하는 사람으로의 이동은 되돌릴 수 없다는 것. 그리고 개발자로서 내가 개선해야 할 것이 바뀌었다는 것.
예전엔 내 실력 개선이라고 하면 더 깊이 아는 것, 더 빨리 짜는 것을 떠올렸다. 이제는 다르다. 판단의 질이 내 실력이다. 그리고 판단의 질은 하루에 몇 번 결정을 내리느냐가 아니라, 얼마나 잘 건조하고 맛보게 세팅했느냐에 달렸다.
달리 말해 — 개발자의 판단력은 자기 하니스와 스케줄러의 질과 같다. 증거를 언제 어떻게 올라오게 만드느냐 (하니스). 반복 결정을 얼마나 영리하게 패키징해두었느냐 (하니스). 자기 주의력을 어떤 시간 구조 안에서 돌리느냐 (스케줄러). 이 둘을 같이 설계하는 능력이 이 시대 개발자의 진짜 기술이다.
3분 진료실에서 본 그 선생님의 속도를 다시 생각한다. 그분이 그 속도로 판단할 수 있는 건 수십 년의 임상 경험 + 진료 가이드라인 + 차트 표준 + 전공의·간호사 분업이라는 거대한 하니스, 그리고 환자를 분단위로 끊어 받는 정교한 스케줄링 위에 서 있기 때문이다. 우리는 그 둘을 지금 만드는 중이다. 아직 많이 부족하고, 그래서 머리가 아프다. 하지만 방향은 이 쪽이다.
이 글 반응이 좀 괜찮다 싶으면 내가 시도해본 좀더 자세한 플레이북도 공유해보겠다.