개발자의 컨텍스트 스위칭 줄이는 하루 설계

오전 10시, 드디어 머릿속에 코드가 그려지기 시작했다. 이 함수가 저기로 흘러가고, 저 상태가 여기서 바뀌고. 그 순간 슬랙이 울린다. "잠깐 이것 좀 봐주실 수 있나요?"

5분짜리 질문이었다. 그런데 자리로 돌아오니, 아까 머릿속에 있던 그 그림이 없다. 어디까지 했더라. 이 브랜치가 뭐였지. 다시 쌓아 올리는 데 20분. 그리고 11시엔 회의가 있다.

퇴근길에 이런 생각을 한 적 있을 것이다. 오늘 하루 종일 바빴는데, 코드는 한 줄도 못 짰네. 당신이 집중력이 약해서가 아니다. 하루가 그렇게 설계되어 있었을 뿐이다.

컨텍스트 스위칭의 실제 가격표

조지아텍 연구자 크리스 파닌(Chris Parnin)은 프로그래머 86명의 작업 세션 1만 개를 분석했다. 결과는 개발자라면 누구나 몸으로 아는 사실을 숫자로 확인해준다.

• 중단당한 프로그래머가 코드 편집을 재개하기까지 10~15분이 걸렸다.
• 코드를 편집하던 도중 중단당한 경우, 1분 안에 작업을 재개한 비율은 10%뿐이었다.
• 프로그래머가 하루에 얻는 방해 없는 2시간 블록은 단 한 번 정도였다.

프로그래밍이 유독 취약한 이유가 있다. 코드를 짜는 동안 머릿속에는 변수 상태, 호출 흐름, 시도하려던 설계가 임시로 얹혀 있다. 이 "작업 기억 위의 탑"은 어디에도 저장되지 않기 때문에, 중단되는 순간 무너지고 처음부터 다시 쌓아야 한다.

UC 어바인의 글로리아 마크(Gloria Mark) 연구팀이 측정한 일반 지식노동자의 수치도 비슷하다. 중단 후 원래 작업으로 완전히 돌아오기까지 평균 23분. 하루에 스위칭이 대여섯 번이면, 오후가 통째로 복구 비용으로 사라진다.

하루를 다시 설계하기

컨텍스트 스위칭은 의지로 막을 수 없다. 슬랙을 무시하는 데도 의지력이 들고, 그 의지는 오후가 되면 흐려진다. 필요한 건 참는 힘이 아니라 구조다.

1. 딥워크 블록을 달력에 먼저 박는다. 하루에 방해 없는 2시간이 한 번뿐이라면, 그 한 번을 운에 맡기지 말자. 오전 중 가장 정신이 맑은 시간대에 2시간 블록을 고정하고, 그 시간엔 슬랙 알림을 끈다. 회의 요청이 들어와도 그 블록만은 지킨다. 블록을 설계하는 구체적인 방법은 타임박싱 완벽 가이드에 정리해뒀다.

2. 응답을 모아서 처리한다. 슬랙과 코드 리뷰는 "올 때마다"가 아니라 "정해진 시간에" 확인한다. 예를 들어 11시 30분, 15시, 17시 30분에 30분씩. 대부분의 메시지는 세 시간 안에만 답해도 아무 일도 일어나지 않는다. 즉답이 필요한 팀이라면, 팀 차원에서 "긴급은 전화, 나머지는 배칭"을 합의하는 것부터가 설계다.

3. 중단당하기 전에 메모 하나를 남긴다. 회의가 코앞이라 어차피 끊길 상황이라면, 끊기기 직전에 "다음에 할 첫 행동"을 한 줄 적는다. "UserService 테스트 3번째 케이스부터" — 이 한 줄이 복구 시간 15분을 2분으로 줄인다. 머릿속 탑을 저장하는 유일한 방법은 밖에 적어두는 것이다.

4. 회의는 한쪽 벽으로 몬다. 오후 2시 회의 하나는 오후 전체를 죽인다. 회의 전엔 "곧 끊길 테니" 깊은 일을 못 시작하고, 회의 후엔 복구에 시간이 든다. 가능하다면 회의를 오후 이른 시간대에 연달아 배치해서, 조각나는 시간대를 하나로 모은다.

첵앤두로 이 설계를 굴리기

이 설계의 약점은 하나다. 달력에 블록을 그리는 건 쉬운데, 지키는 건 어렵다는 것.

첵앤두는 그 지키는 부분을 맡는다. 아침에 오늘의 딥워크 블록과 배칭 시간을 타임블록으로 잡아두면, 블록이 시작될 때 앱 푸시로 알려주고, 끝날 때 실제로 했는지 확인한다. 어제 못 지켰으면 오늘 다시 물어본다. 혼자만의 다짐은 사흘을 못 가지만, 끝까지 쫓아오는 코치가 있으면 이야기가 달라진다.

오늘 하루 중 딱 한 블록만 지켜보자. 방해 없는 2시간은 하루에 한 번뿐이니까, 그 한 번을 설계로 확보하는 것이다.