컨텍스트 스위칭의 진짜 비용: 500만 GitHub PR이 말해주는 것
500만 건 이상의 PR 데이터를 분석해 개발자의 컨텍스트 스위칭 비용을 측정했습니다. 진짜 병목은 예상치 못한 곳에 있습니다.
By Ellis Keane · 2026-03-29
대부분의 기사에서 인용하는 컨텍스트 스위칭 비용 – 방해 후 재집중하는 데 23분이 걸린다는 Gloria Mark의 UC 어바인 연구 – 는 실제 연구에서 나온 실제 결과입니다. 그러나 그 연구는 소프트웨어 엔지니어가 아닌 2008년의 일반 지식 근로자를 대상으로 했습니다. 그리고 23분에 하루 예상 방해 횟수(저자의 기분에 따라 보통 6~15회)를 곱하고 개발자 시급을 곱해 놀라운 연간 비용 수치를 뽑아내는 블로그 글 산업은 – 항상 머리를 감싸 쥔 스톡 사진과 함께 – 원래 연구가 의도하지 않은 일을 하고 있습니다.
저는 이 문제에 개인적인 이해관계가 있습니다. 이전 직장에서 – 과장이 아닙니다 – 어떤 날은 업무 시간의 80~100%를 그냥 인간 라우터로 보냈습니다. 코드를 작성하지도, 리뷰하지도 않고. 어떤 시스템도 서로 연결되지 않았기 때문에 사람과 도구 사이에서 정보를 전달했습니다. 그 경험이 Sugarbug를 만든 이유 중 하나지만, 동시에 표준 컨텍스트 스위칭 비용 계산기에 회의적인 이유이기도 합니다. 계산기는 방해를 측정합니다. 하지만 원래 해야 할 일에 한 번도 도달하지 못하는 날들은 측정하지 않습니다.
그래서 저희는 엔지니어링 업무에서 컨텍스트 스위칭이 실제로 무엇을 비용으로 치르는지 알고 싶었습니다. 추상적인 개발자 생산성 관점이 아니라, 팀이 매일 생산하는 산출물인 풀 리퀘스트로 측정하기로 했습니다. 수천 개의 오픈 소스 프로젝트에 걸친 500만 건 이상의 PR을 다룬 세 가지 대규모 연구의 결과를 종합하고, PR 리뷰 시간을 실제로 좌우하는 요인을 살펴봤습니다.
핵심 결과: 가장 비용이 큰 컨텍스트 스위칭은 흐름을 깨는 Slack 알림이 아닙니다. 리뷰 대기열에 하루 종일 방치된 풀 리퀘스트이며, 질문이 마침내 도착했을 때 작성자가 전체 멘탈 모델을 다시 구축해야 하는 상황입니다.
사용한 데이터셋
자체 스크레이퍼를 만들어 PR 1만 건을 독립적으로 분석한 것이 아닙니다. 두 편의 동료 심사 연구와 하나의 대규모 업계 데이터셋에서 결과를 종합하고, 그 결론을 서로 검증했습니다.
stat: "3.35M" headline: "Zhang 외가 분석한 풀 리퀘스트 수" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
세 가지 주요 데이터셋:
이를 2024년 DORA State of DevOps 보고서 및 Atlassian의 2024년 개발자 경험 보고서(2,100명 이상의 개발자를 대상으로 컨텍스트 스위칭, 개발자 생산성, 인간적 측면 조사)와 상호 참조했습니다.
대기열이 진짜 문제다
Zhang 외 연구는 PR이 최초 응답(첫 코멘트, 첫 리뷰, 어떤 형태로든 첫 반응)을 받기까지의 시간이 PR 전체 수명 분산의 58.7%를 설명한다는 것을 발견했습니다. 이는 데이터셋에서 관측된 가장 강력한 예측 변수로, PR 크기, 코드 복잡도, 변경 파일 수를 모두 앞섭니다! 비교가 안 됩니다.
코드 리뷰에서 컨텍스트 스위칭의 가장 큰 비용은 스위칭 자체가 아닙니다. 모든 사람이 다른 일로 바빠 스위칭하는 동안 형성되는 대기열입니다.
이것이 실제로 어떤 의미인지 생각해 보십시오. 엔지니어가 오전 10시에 PR을 열었습니다. 지정된 리뷰어는 자신의 피처 브랜치에 깊이 빠져 있거나, 회의 중이거나, Slack 메시지를 분류하는 중입니다(솔직히 아마 세 가지 모두 순서대로). PR은 방치됩니다. 오후 3시에 누군가 집어들 때쯤 작성자는 이미 완전히 다른 작업으로 넘어갔습니다. 이제 리뷰어가 질문을 보내면 작성자는 다섯 시간 전에 작성한 코드로 컨텍스트 스위칭해 돌아가 멘탈 모델을 재구성하고 답해야 합니다. 그 답변이 오후 4시 30분에 도착하지만, 리뷰어는 이미 퇴근했습니다.
PR은 또 하루 더 묵습니다.
데이터가 시사하는 것은 이것이 기강의 문제가 아니라 큐잉(queuing) 문제라는 것입니다. 그리고 그 대기열의 컨텍스트 스위칭 비용은 방해 계산기가 완전히 놓치는 방식으로 복리로 쌓입니다.
작은 PR로는 해결되지 않는다
이런 말은 들어봤을 겁니다: 작은 PR이 더 빠르게 리뷰되므로 PR을 작게 유지하세요. 틀린 말은 아니지만, 효과의 크기는 (정말로) 기대보다 작습니다.
Adadot의 30만 건 이상 PR 분석에서 PR 크기와 리드 타임 사이의 켄달 타우 상관계수는 고작 0.06으로 약한 연관성이었습니다. 다만 이 연구는 집계 수치에 대한 신뢰 구간을 보고하지 않았습니다. 100줄 미만의 PR이 1주일 내 완료될 확률이 약 80%라는 것은 훌륭하게 들립니다만, 누군가의 리뷰 대기열에 6일간 방치된 PR의 완료율과 같다는 걸 깨닫기 전까지는요!
stat: "0.06" headline: "PR 크기와 리드 타임 간 상관계수" source: "Adadot, 약 3만 명 개발자의 30만 건 이상 PR 분석(2023년)"
더 흥미로운 발견: 이 상관관계는 조직마다 크게 달라 0.1에서 0.7 가까이까지 범위가 있었습니다. 이는 PR 크기 자체가 병목이 아니라 PR을 둘러싼 리뷰 문화와 프로세스가 문제임을 시사합니다. 강한 리뷰 리듬을 가진 팀은 큰 PR도 효율적으로 처리합니다. 리뷰를 뒤로 미루는 팀은 어떤 크기의 PR이든 고생합니다.
SmartBear/Cisco 코드 리뷰 연구에서 나온 400줄 임계값은 유용한 휴리스틱으로 유효하며 – Adadot 데이터도 그 범위를 넘으면 리뷰 참여도가 떨어진다는 것을 확인했습니다. 그러나 근본적인 리뷰 리듬을 고치지 않고 PR 크기만 최적화하는 것은 (이를 시도한 모든 엔지니어링 매니저에 대한 진심 어린 애정과 함께 말하건대) 갑판 의자를 재배치하는 것과 같습니다.
모두가 동시에 모든 것을 리뷰하고 있다
멀티 리뷰 연구에서는 풀 리퀘스트의 62%에 여러 PR을 동시에 리뷰하는 개발자가 관여하고 있음을 발견했습니다. 더 중요한 것은 통계적으로 유의미한 상관관계가 발견됐다는 점입니다: 리뷰어당 동시 리뷰 수가 많을수록 PR 해결 지연이 길어졌습니다.
풀 리퀘스트의 62%에는 여러 PR을 동시에 리뷰하는 개발자가 관여하며, 멀티 리뷰는 더 긴 해결 시간과 직접 상관관계가 있습니다. attribution: 멀티 리뷰 풀 리퀘스트 연구, 760개 프로젝트에 걸친 180만 건 PR
메커니즘은 직관적입니다(이 연구가 관찰 연구라 인과관계 방향은 증명되지 않지만). 리뷰어가 PR #1에 착수해 diff를 읽으며 코드가 무엇을 하려는지 멘탈 모델을 형성하기 시작합니다. 그때 알림이 옵니다 – PR #2가 배포를 막고 있어 리뷰가 필요합니다. 리뷰어가 스위칭합니다. PR #1로 돌아왔을 때 멘탈 모델이 흐려져 diff 절반을 다시 읽어야 합니다.
이것을 8명의 엔지니어 팀으로 확장해 보십시오. 각자 2~3건의 PR이 열려 있고 2~3명의 동료를 위해 리뷰합니다. 조율 오버헤드가 저절로 설명됩니다. 또한 2024년 DORA 보고서에서는 '고성과자' 클러스터가 31%에서 22%로 줄었고 저성과자 클러스터는 17%에서 25%로 늘었습니다. DORA는 PR 리뷰 동시성을 요인으로 특정하지 않지만, 증가하는 조율 오버헤드는 이 변화의 그럴듯한 원인 중 하나입니다.
컨텍스트 스위칭 비용 추정이 틀린 점
컨텍스트 스위칭 비용 기사에서 널리 유통되는 '개발자 1인당 연간 5만 달러' 수치에 대해 솔직히 말씀드리겠습니다. 대부분 추정의 방법론은 이렇습니다: 23분의 재집중 시간을 가져와 하루 예상 방해 횟수(저자의 기분에 따라 보통 6~15회)를 곱하고, 개발자 시급을 곱한 뒤 연환산합니다.
문제는 수학이 틀린 것이 아닙니다. 문제는 모든 컨텍스트 스위칭을 동등하게 취급한다는 것입니다. 깊은 코딩에서 팀 점심 장소를 묻는 Slack 메시지로의 스위칭 – 이것은 컨텍스트 스위칭입니다. 어떤 PR 리뷰에서 완전히 다른 코드베이스의 다른 PR 리뷰로의 스위칭 – 이것도 컨텍스트 스위칭입니다. 그러나 인지적 비용은 비교가 안 됩니다. 이를 단일 시급으로 평탄화하면 진짜 피해가 어디서 발생하는지 가려집니다.
구체적으로 말하면: 전 직장에서의 전형적인 하루는 Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster, 수많은 Telegram과 Signal 채널을 오가는 것이었습니다 – 분명 예닐곱 개는 잊고 있을 겁니다. 지금은 소수의 도구(Signal, Obsidian, Figma, GitHub, 이메일, 캘린더)를 씁니다. 스위칭당 비용은 변하지 않았습니다. 변한 것은 주의를 경쟁하는 컨텍스트 수와 실제로 중요한 컨텍스트가 무엇인지입니다.
PR 데이터가 시사하는 것은, 비용이 큰 스위칭은 대기열을 만드는 것이지 흐름을 방해하는 것이 아니라는 점입니다. 즉시(몇 분 내) 리뷰 알림을 받아 50줄짜리 빠른 리뷰를 하는 개발자 – 이것은 높은 수익을 내는 짧은 방해입니다. 그 리뷰 요청을 다른 네 건과 함께 쌓아 내일 처리하는 개발자 – 이것은 리뷰어에게는 긴 방해이지만 작성자와 팀에게는 훨씬 큰 비용을 만듭니다.
비용 계산기가 측정하는 것
- 개별 방해 – 누군가의 흐름이 끊기는 빈도
- 재집중 시간 – 이전 작업으로 돌아가는 데 걸리는 시간
- 시급 곱셈 – 크고 무서운 연간 수치
PR 데이터가 실제로 보여주는 것
- 대기열 형성 – 최초 응답을 기다리는 PR
- 리뷰 동시성 – 여러 PR을 담당하는 리뷰어
- 연쇄 지연 – 작성자의 컨텍스트 스위칭이 리뷰어 지연을 복리로 증폭시킴
팀에 주는 시사점
팀 개발자의 컨텍스트 스위칭 비용을 줄이려 한다면, 실용적인 답변은 지루합니다 – 그래서 많이 다뤄지지 않는 것이겠죠. 도구도 아니고, 인증 프로그램이 있는 프로세스 프레임워크도 아닙니다. 리뷰 리듬입니다. (알아요, 알아요. 리뷰 리듬을 개선해서 승진한 사람은 아무도 없죠.)
LinearB의 2025년 엔지니어링 벤치마크는 3,000개 조직의 610만 건 PR을 바탕으로, 엘리트 사이클 타임(2.5일 미만)을 달성한 팀에 공통점이 하나 있음을 발견했습니다: PR을 신속하게 리뷰했습니다. PR 수가 적어서도, PR 크기가 작아서도(물론 그런 경우가 많았지만) 아니라, 리뷰 요청에 몇 시간 내 응답하는 것이 팀 규범이었지 뒤로 미루는 일이 아니었기 때문입니다.
참고로 Ben과 저 – 2인 팀 – 는 첫 PR 응답이 수시간이 아니라 수분 평균입니다. 이것은 기강에 대한 자랑이 아닙니다(저희는 그렇지 않습니다). 팀 합의입니다: 리뷰 요청은 대기열에 넣지 않는 유일한 알림입니다. CI 액션과 자동화 테스트가 기계적인 검사를 처리하므로, 실제 컨텍스트가 필요한 인간 리뷰는 짧고 즉시 이루어집니다. 합의가 먼저였습니다. 도구는 그것을 지속 가능하게 만들었을 뿐입니다.
실제로는 다음을 의미합니다:
- 사이클 타임뿐 아니라 최초 응답 시간을 측정하세요. DORA 메트릭을 추적하고 있다면 이것을 추가하세요. PR 처리량의 가장 강력한 예측 변수입니다(Zhang 외에 따르면 수명 분산의 58.7%를 설명합니다).
- 리뷰 동시성을 제한하세요. 리뷰어에게 보류 중인 리뷰 요청이 세 건이라면 네 번째는 좋은 리뷰를 받지 못합니다. 멀티 리뷰 데이터는 동시성과 지연 간의 명확한 연관성을 보여줬습니다. WIP 한도를 동시 리뷰 두 건으로 시작해 영향을 모니터링하세요.
- PR 크기만 독립적으로 최적화하지 마세요. 작은 PR은 좋지만, 실제로 리뷰를 하는 팀을 대체할 수 없습니다. 48시간의 리뷰 백로그를 가진 채 하루 50줄짜리 PR 20건을 생산하는 팀은, 당일 리뷰로 하루 200줄짜리 PR 5건을 생산하는 팀보다 상황이 나쁩니다.
- 리뷰가 진짜 업무임을 인정하세요. Atlassian의 2024년 조사에 따르면 개발자의 69%가 비효율로 주당 8시간 이상을 잃는다고 합니다. 리뷰가 그 비효율 중 하나일 필요는 없습니다 – 단, '진짜' 업무에 대한 방해가 아니라 1급 엔지니어링 활동으로 취급될 때에 한해서.
그리고 생산성 도구 업계의 누구도 (저희를 포함해, 솔직히 말하면) 큰 소리로 말하고 싶지 않은 부분이 있습니다: 엔지니어링 팀의 컨텍스트 스위칭 비용에 대한 가장 효과적인 개입은 도구가 아닙니다. PR이 언제 리뷰되는지에 대한 팀 합의입니다. 팀의 암묵적 규범이 "시간이 날 때 리뷰하겠다"라면, 아무리 많은 도구를 써도 PR 데이터가 드러내는 큐잉 연쇄를 막을 수 없습니다.
도구는 도움이 됩니다 – 탭 네 개를 열지 않고 PR의 전체 맥락을 볼 수 있으면 스위칭당 인지 부하가 줄고, 어떤 리뷰가 다른 사람의 업무를 막고 있는지 드러내면 우선순위를 정하는 데 도움이 됩니다. 하지만 핵심 레버는 합의이며, 합의는 무료입니다. 23분 계산기는 필요 없습니다.
가장 비용이 큰 컨텍스트 스위칭은 흐름을 깨는 알림이 아닙니다. 하루 동안 대기열에 방치된 리뷰 요청이며, 질문이 마침내 도착했을 때 작성자가 멘탈 컨텍스트를 재구성해야 하는 상황입니다.
시그널 인텔리전스를 받은 편지함에서 받아보세요.
자주 묻는 질문
Q: 개발자 한 명당 연간 컨텍스트 스위칭 비용은 얼마나 됩니까? A: 추정치는 다양하지만, 대부분의 기사가 시사하는 것보다 근거 연구는 빈약합니다. UC 어바인의 Gloria Mark 연구에 따르면 방해 후 재집중에 23분이 걸립니다. Atlassian의 2024년 조사에서는 2,100명 이상의 개발자 중 69%가 비효율로 주당 8시간 이상을 잃는다고 나타났습니다. 달러 환산 수치는 급여 가정, 방해 빈도, '스위칭' 정의에 크게 좌우되므로 저희는 PR 데이터에 집중했습니다.
Q: Sugarbug는 엔지니어링 팀의 컨텍스트 스위칭 감소에 도움이 됩니까? A: 네. Sugarbug는 Linear, GitHub, Slack, Figma 같은 도구를 단일 지식 그래프로 연결합니다. 엔지니어는 탭 네 개를 열지 않고도 관련 PR, Slack 토론, Figma 코멘트 등 작업의 전체 맥락을 확인할 수 있습니다. 목표는 스위칭 횟수를 줄이는 것이지, 도구 수를 줄이는 것이 아닙니다.
Q: 리뷰 지연을 최소화하는 이상적인 풀 리퀘스트 크기는 무엇입니까? A: Adadot의 30만 건 이상 PR 분석에 따르면 코드 100줄 미만의 PR은 1주일 내 완료 확률이 약 80%입니다. 400줄을 초과하면 리뷰 품질과 완료 속도가 모두 떨어집니다. 작은 PR은 리뷰어의 컨텍스트 스위칭 부담도 줄여 줍니다.
Q: Sugarbug는 GitHub 풀 리퀘스트와 통합됩니까? A: 네. Sugarbug는 GitHub 활동(PR, 코멘트, 리뷰, 상태 변경)을 수집하고 다른 도구의 관련 시그널과 연결합니다. Linear 이슈에서 PR이 생성되고 Slack 스레드에서 접근 방식이 논의됐다면, Sugarbug가 세 가지를 자동으로 연결합니다.
Q: '재집중에 23분'이라는 통계는 어디서 나온 것입니까? A: UC 어바인 Gloria Mark의 연구에서 나온 것으로, 'The Cost of Interrupted Work: More Speed and Stress'(CHI 2008)에 발표됐습니다. 연구에 따르면 방해 후 원래 작업으로 돌아가는 데 평균 23분 15초가 걸렸습니다. 이 연구는 소프트웨어 엔지니어가 아닌 일반 지식 근로자를 대상으로 했다는 점을 유의할 필요가 있습니다.