머릿속에 올려 둔 상태가 비용이다
버그를 추적할 때 개발자의 머릿속에는 여러 조각이 동시에 떠 있습니다. 호출 경로, 의심되는 변수, 방금 확인해서 배제한 가설, 다음에 확인할 지점 같은 것들입니다. 이 구조는 파일이나 문서가 아니라 작업 기억 안에 있습니다.
중단은 이 구조를 날려 버립니다. 자리로 돌아와도 코드는 그대로지만 머릿속 상태는 다시 쌓아야 합니다. 개발자들이 방해에 유독 민감한 것은 예민해서가 아니라 실제로 복구 비용이 크기 때문입니다.
이 때문에 코딩에는 25분이 짧게 느껴지는 경우가 많습니다. 자리에 앉고 10분쯤 지나야 상태가 채워지는데, 그 직후에 알람이 울리는 셈입니다.
작업 종류에 따라 세션을 다르게
개발 업무는 성격이 균일하지 않습니다. 한 가지 길이로 하루 전체를 운영할 이유가 없습니다.
- 새 기능 설계·복잡한 디버깅: 50~90분. 진입 비용이 크므로 길게 잡고, 대신 하루 두세 번으로 제한합니다.
- 코드 리뷰: 25~30분. 한 번에 오래 하면 후반부의 리뷰 품질이 눈에 띄게 떨어집니다.
- 리팩터링·테스트 작성: 25분. 단위가 잘게 나뉘어 있어 짧은 세션과 잘 맞습니다.
- 빌드나 CI를 기다리는 시간: 세션 취급하지 않습니다. 이 틈에 새 작업을 시작하면 둘 다 망가집니다.
- 장애 대응 중: 뽀모도로를 적용하지 않습니다. 외부에서 리듬이 정해지는 상황입니다.
복귀 지점을 남기는 습관
중단이 불가피하다면 복귀 비용을 줄이는 쪽으로 대비할 수 있습니다. 가장 값싼 방법은 자리를 뜨기 전 30초를 쓰는 것입니다.
지금 무엇을 확인하던 중이었는지, 다음에 무엇을 볼 차례였는지를 한 줄로 적어 두세요. 주석이든 메모든 상관없습니다. 일부러 실패하는 테스트를 하나 남겨 두거나, 컴파일되지 않는 상태로 커서를 두는 방식도 널리 쓰입니다. 돌아왔을 때 무엇부터 볼지 화면이 알려 주기 때문입니다.
휴식이 끝나고 돌아왔을 때 이 한 줄이 있으면 복구 시간이 몇 분 단위로 줄어듭니다.
소리와 알림 설정
코딩 중 음악에 가사가 있으면 언어 처리 자원이 겹칩니다. 코드를 읽고 쓰는 일 자체가 언어 작업이기 때문에 간섭이 생기기 쉽습니다. 가사 없는 음악이나 브라운노이즈처럼 정보가 없는 소리가 대체로 안전합니다.
알림은 종류별로 나눠 처리하세요. 장애 알림처럼 즉시 봐야 하는 것만 소리로 남기고, 나머지는 배지도 끄는 것이 좋습니다. 화면 구석의 숫자 하나가 주의를 계속 끌어당깁니다.
팀 차원에서 할 수 있는 것
개인의 노력만으로는 한계가 있습니다. 팀이 함께 정하면 훨씬 쉬워지는 규칙들이 있습니다. 오전을 회의 없는 시간대로 정하는 것, 질문을 즉답이 필요한 것과 비동기로 처리할 것으로 구분하는 것, 회의를 특정 요일에 몰아 잡는 것이 대표적입니다.
이런 합의는 개인의 집중을 지키는 동시에 팀 전체의 처리량을 늘립니다. 방해를 줄이는 것은 배려의 문제가 아니라 생산성의 문제입니다.