들어가며: 소방 호스 앞에 선 사람
월요일 아침, 여러분은 멋진 계획을 세웁니다. "오늘은 결제 모듈 리팩터링을 끝내야지." 커피를 내리고 자리에 앉습니다.
9시 12분, 슬랙. "@당신 어제 배포한 거 때문에 알림이 안 가는 것 같아요." 9시 34분, 다른 팀에서 DM. "급한데 이 데이터 좀 뽑아줄 수 있어요?" 10시, 갑자기 잡힌 회의. 11시, 고객 문의로 인한 긴급 디버깅. 점심도 거르고 처리하다 보니 어느새 오후 5시. 정작 리팩터링은 한 줄도 못 건드렸습니다.
이런 날이 한 번이면 사고지만, 매일이면 그것이 여러분의 직무입니다. 많은 엔지니어, 특히 운영을 겸하거나 플랫폼/SRE/지원 성격의 일을 하는 사람은 **계획된 일보다 쏟아져 들어오는 일(adhoc work)**이 더 많은 환경에서 삽니다. 마치 소방 호스(firehose)에서 물을 마시려는 것 같습니다.
이 글은 그 호스를 막는 법이 아닙니다. 호스는 막히지 않습니다. 대신 **쏟아지는 물줄기 속에서도 익사하지 않고, 정말 중요한 일까지 해내는 시스템**을 만드는 법입니다.
1. 먼저 현실을 인정하라
가장 흔한 실수는 "원래는 계획대로 되어야 하는데 오늘만 운이 나빴다"고 생각하는 것입니다. 한 달간 매일 그랬다면, 그건 예외가 아니라 패턴입니다. 인터럽트는 버그가 아니라 사양입니다.
이 인정이 왜 중요할까요? 현실을 부정하면 잘못된 계획을 세우기 때문입니다. 인터럽트가 하루 2~3시간을 잡아먹는 환경에서 "오늘 8시간짜리 집중 작업"을 계획하면, 매일 실패하고 매일 자책하게 됩니다.
[잘못된 멘탈 모델]
하루 8시간 = 전부 계획된 일에 쓸 수 있는 시간
[현실에 맞는 멘탈 모델]
하루 8시간 = 인터럽트 버퍼 3시간 + 계획된 일 4시간 + 잡무 1시간
→ 계획된 일은 처음부터 4시간 기준으로 잡는다
현실을 인정하면 두 가지가 가능해집니다. 첫째, 달성 가능한 계획을 세웁니다. 둘째, 인터럽트 자체를 "관리해야 할 업무"로 보고 시스템을 설계하기 시작합니다.
2. 트리아지 — 모든 불이 같은 불은 아니다
응급실에서는 환자가 오는 순서가 아니라 위중한 순서로 치료합니다. 이것이 트리아지(triage)입니다. 쏟아지는 일도 똑같이 분류해야 합니다. 들어온 순서대로 처리하는 것은 가장 나쁜 전략입니다.
간단한 분류 기준을 머릿속에 둡니다.
[즉시 분류 4단계]
P0 지금 멈추고 처리 : 서비스 장애, 돈/보안 직결, 데이터 유실 위험
P1 오늘 안에 : 고객 막힘, 마감 임박, 다른 사람을 블로킹
P2 이번 주 안에 : 중요하나 시간 여유 있음
P3 언젠가 / 안 함 : 있으면 좋지만 급하지 않음
핵심 질문 세 가지로 빠르게 가릅니다.
1. **이게 지금 누군가를 막고 있나?** (블로킹 여부)
2. **지금 안 하면 나중에 비용이 커지나?** (시간 민감도)
3. **나만 할 수 있는 일인가?** (위임 가능성)
세 질문에 모두 "아니오"라면, 그 일은 거의 항상 나중으로 미뤄도 됩니다. 그런데 우리는 자꾸 "방금 들어온 일"이라는 이유만으로 그것을 P0처럼 다룹니다. 최신성 편향을 경계해야 합니다.
3. 인테이크를 체계화하라
인터럽트가 사방에서, 온갖 채널로 들어오면 트리아지조차 불가능합니다. DM으로, 멘션으로, 복도에서, 회의 끝에 "아 그리고 한 가지만 더". 그래서 첫 번째 시스템은 **들어오는 통로를 하나로 모으는 것(intake funneling)**입니다.
[흩어진 인테이크] [모아진 인테이크]
슬랙 DM ────┐ 모든 요청
멘션 ───────┤ → #team-requests 채널
복도 대화 ──┼──→ 카오스 vs 또는 요청 폼/티켓 하나로
이메일 ─────┤ → 한 곳에서 트리아지
회의 끝 ────┘ → 추적 가능
실천 방법은 환경마다 다릅니다.
- 요청 전용 채널이나 폼을 만들고, "급한 일은 여기에 올려주세요"로 안내합니다.
- DM으로 오는 요청은 정중히 공개 채널로 유도합니다. "여기 올려주시면 팀이 같이 보고 우선순위를 정할 수 있어요."
- 구두 요청은 "슬랙으로 한 줄 남겨주시겠어요? 안 그러면 제가 까먹을 수 있어서요"라고 부탁합니다.
이렇게 하면 세 가지를 얻습니다. 요청이 기록으로 남고, 한곳에서 비교·트리아지할 수 있고, 무엇보다 **요청의 양 자체가 가시화**됩니다. "이번 주에 23건이 들어왔다"는 데이터가 생기면, 인력 충원이나 프로세스 개선을 설득할 근거가 됩니다.
4. 배치 처리와 집중 시간 확보
인터럽트의 진짜 비용은 그 일 자체가 아니라 **맥락 전환(context switching)**입니다. 깊은 집중에 들어가는 데 15~20분이 걸리는데, 5분짜리 인터럽트 하나가 그 20분을 통째로 날립니다.
대책은 두 가지입니다.
4.1 배치 처리 — 인터럽트를 모아서 한 번에
작은 요청들을 들어올 때마다 즉시 처리하지 말고, 모아서 정해진 시간에 한꺼번에 처리합니다.
[나쁜 패턴] [배치 패턴]
요청1 → 즉시처리 → 복귀(20분) 요청1 ─┐
요청2 → 즉시처리 → 복귀(20분) 요청2 ─┼→ 모아둠
요청3 → 즉시처리 → 복귀(20분) 요청3 ─┘
= 집중 60분 손실 11시·15시 두 번에 몰아서 처리
= 집중 손실 최소화
"즉답이 친절"이라는 통념을 의심해야 합니다. 대부분의 요청은 한두 시간 안에만 답하면 충분합니다.
4.2 집중 시간을 캘린더에 못 박아라
비어 있는 시간은 인터럽트로 채워집니다. 그래서 집중 시간은 **명시적으로 예약**해야 합니다.
[일과 설계 예시]
09:00-09:30 인테이크 트리아지 (어제·아침 쌓인 요청 분류)
09:30-12:00 집중 블록 (캘린더에 "집중" 표시, 알림 끔)
12:00-13:00 점심
13:00-13:30 인터럽트 배치 처리 1
13:30-16:00 집중 블록 2
16:00-16:30 인터럽트 배치 처리 2 + 내일 준비
물론 P0가 터지면 집중 블록도 깨집니다. 그건 당연합니다. 중요한 건 "기본값"을 집중에 두고, 인터럽트가 그 예외가 되게 하는 것입니다. 반대가 되면 안 됩니다.
5. 긴급의 함정
쏟아지는 일 속에서 가장 위험한 것은 **모든 것이 긴급해 보이는 착시**입니다. 요청하는 사람은 거의 항상 "급하다"고 말합니다. 그게 통하면 빨리 처리되니까요. 모두가 급하다고 하면, 진짜 급한 것이 묻힙니다.
"긴급함은 전염된다. 한 사람이 급하다고 하면
다음 사람도 급하다고 한다. 결국 모두가 급해지고,
아무것도 진짜로는 급하지 않게 된다."
함정에서 벗어나는 법은 긴급함을 사실로 받아들이지 말고 **검증**하는 것입니다.
- "언제까지 필요하세요?" — 막연한 "ASAP"에 구체적 기한을 묻습니다. "오늘 6시까지요"와 "이번 달 안에요"는 천지차이입니다.
- "이걸 못 받으면 무슨 일이 생기나요?" — 진짜 영향이 있는지 확인합니다.
- "지금 제가 하는 X를 멈추고 이걸 먼저 하는 게 맞을까요?" — 트레이드오프를 상대에게 보여줍니다.
마지막 질문이 특히 강력합니다. 대부분의 사람은 여러분이 무엇을 하고 있는지 모릅니다. "당신 요청을 위해 결제 버그 수정을 멈춰야 합니다"라고 알리면, 상당수는 "아, 그럼 천천히 해도 돼요"로 바뀝니다.
6. 기대치를 관리하라
쏟아지는 일을 다루는 핵심은 빨리 일하는 것이 아니라 **기대치를 솔직하게 관리하는 것**입니다. 사람들이 화나는 건 일이 늦어져서가 아니라, 언제 될지 모른 채 기다려서입니다.
[기대치 관리 응답 템플릿]
확인 + 분류 + 시점:
"확인했어요. 지금 P0 장애 대응 중이라, 이건 오늘 오후에 보고
내일 오전까지 답드릴게요. 더 급하면 알려주세요."
거절(부드럽게) + 대안:
"이번 주는 X 마감 때문에 어려울 것 같아요.
다음 주 월요일에 시작하거나, Y님이 더 빨리 도와줄 수도 있어요."
여기서 중요한 두 가지 원칙:
1. **침묵하지 마라.** "처리 중"이라는 한마디가 없으면, 상대는 무시당한다고 느낍니다. 당장 못 해도 "받았고, 언제 보겠다"는 신호는 즉시 줍니다.
2. **과하게 약속하지 마라.** "금방 해드릴게요"라고 해놓고 못 지키면 신뢰가 깎입니다. 차라리 여유 있게 약속하고 일찍 끝내는 편이 낫습니다(under-promise, over-deliver).
7. 반복되는 일은 자동화하거나 문서화하라
쏟아지는 요청을 자세히 보면, 상당수가 **똑같은 종류의 반복**입니다. "이 데이터 좀 뽑아줘", "이 권한 좀 줘", "이거 어떻게 하더라". 같은 요청을 매번 손으로 처리하면 영원히 호스에 깔립니다.
여기에 임팩트의 지렛대가 있습니다. 인터럽트를 처리하는 것에서, 인터럽트를 **줄이는 것**으로 한 단계 올라가는 것입니다.
[반복 요청 대응 사다리]
1단계: 매번 손으로 처리 (가장 비효율)
2단계: 셀프서비스 문서로 안내 ("여기 가이드 보세요")
3단계: 셀프서비스 도구/스크립트화 (요청자가 직접 처리)
4단계: 근본 원인 제거 (애초에 요청이 안 생기게)
예를 들어 "권한 좀 줘"가 일주일에 다섯 번 온다면, 셀프서비스 권한 신청 폼 하나로 다섯 번을 0으로 만들 수 있습니다. 문서화도 마찬가지입니다. 같은 질문에 세 번째 답하고 있다면, 그 답을 문서로 만들고 다음부터는 링크만 보냅니다.
이때 중요한 습관: **문제를 해결하면서 동시에 문서를 남기는 것.** 나중에 따로 정리하려 하면 영원히 안 합니다. 인터럽트를 처리하는 그 순간, 5분 더 들여 다음 사람(혹은 미래의 나)을 위한 기록을 남깁니다.
8. 번아웃을 막는 법
쏟아지는 일은 단지 비효율의 문제가 아니라 **소진의 문제**이기도 합니다. 항상 켜져 있어야 하고, 늘 누군가의 긴급에 반응해야 한다는 감각은 사람을 갉아먹습니다. 심리학자 크리스티나 마슬라크(Christina Maslach)는 번아웃의 핵심 요인으로 과부하와 함께 **통제감 상실**을 꼽았습니다. 인터럽트 주도 업무가 위험한 건 바로 이 통제감을 빼앗기 때문입니다.
대책은 통제감을 조금씩 되찾는 것입니다.
- **온/오프 경계를 만든다.** 항상 켜져 있을 필요는 없습니다. 점심시간, 집중 블록, 퇴근 후에는 알림을 끕니다. 진짜 P0는 다른 경로(전화, 온콜)로 옵니다.
- **온콜을 순환시킨다.** 인터럽트 대응을 한 사람이 전담하면 그 사람이 탑니다. 팀에서 "오늘의 당번"을 돌리면, 나머지는 집중할 수 있고 부담이 분산됩니다.
- **작은 승리를 기록한다.** 인터럽트만 처리한 날은 "아무것도 못 했다"는 느낌이 듭니다. 하지만 사실은 23건의 요청을 해결한 것입니다. 처리한 일을 기록으로 남기면, 자기 효능감과 평가 근거를 동시에 얻습니다.
- **데이터로 도움을 요청한다.** 인테이크 데이터(주당 요청 수, 소요 시간)가 쌓이면, "지금 구조로는 지속 불가능하다"를 감정이 아니라 숫자로 말할 수 있습니다.
9. 개인의 기술을 넘어 — 조직 차원의 협상
지금까지의 방법은 대부분 개인이 혼자 할 수 있는 것들입니다. 하지만 쏟아지는 일의 근본 원인이 구조에 있다면, 개인의 영웅적 노력만으로는 한계가 옵니다. 어느 시점에는 위로, 그리고 옆으로 협상해야 합니다.
이때 가장 강력한 무기는 3장에서 모아둔 **인테이크 데이터**입니다. 감정이 아니라 숫자로 말할 수 있기 때문입니다.
[데이터 없는 호소]
"너무 바빠요. 인터럽트가 많아서 일을 못 하겠어요."
→ 주관적 불평으로 들림. 다들 바쁘다.
[데이터 있는 협상]
"지난 4주간 주당 평균 71건의 임시 요청이 들어왔고,
대응에 1인당 주 14시간이 쓰였습니다. 그래서 계획된 로드맵 작업이
매주 절반밖에 진행되지 못했습니다. 세 가지 방안을 제안드려요."
→ 의사결정 가능한 제안으로 들림.
협상에서 제시할 수 있는 선택지들:
- **인력/온콜 추가:** 요청량이 한 사람이 감당할 수준을 넘었음을 보여줍니다.
- **셀프서비스 투자:** 반복 요청을 없앨 도구를 만들 시간을 공식적으로 확보합니다. "지금 2주를 투자하면 앞으로 매주 10시간을 아낍니다."
- **기대치 공식화:** 요청에 대한 SLA를 팀 차원에서 합의합니다. "P2 요청은 3일 내 응답"처럼.
- **우선순위 조정:** "이 인터럽트를 계속 받으려면 로드맵의 X를 미뤄야 한다"를 명시적으로 테이블에 올립니다.
핵심은 인터럽트 부하를 **개인의 인내력 문제가 아니라 팀의 자원 배분 문제로** 재정의하는 것입니다. 그래야 지속 가능한 해법이 나옵니다. 혼자 더 빨리 마시는 것은 해법이 아니라 번아웃의 지연일 뿐입니다.
10. 사례: 호스를 시스템으로 바꾼 플랫폼 팀
한 회사의 3인 플랫폼 팀은 사내 개발자들의 온갖 요청에 시달렸습니다. 배포 권한, 환경 설정, 트러블슈팅 요청이 DM으로 하루 수십 건씩 들어왔고, 팀은 늘 지쳐 있었으며 정작 플랫폼 개선은 한 발짝도 못 나갔습니다.
그들은 4주에 걸쳐 시스템을 바꿨습니다.
1. **인테이크 통합**: 모든 요청을 전용 채널 하나로 모았습니다. 첫 주 데이터가 충격이었습니다. 주당 87건, 그중 60%가 단 세 종류의 반복 요청.
2. **트리아지 도입**: 들어온 순서가 아니라 P0~P3로 분류했습니다.
3. **반복 제거**: 가장 많던 세 종류를 셀프서비스 문서와 스크립트로 만들었습니다. 4주 차에 주당 요청이 87건에서 31건으로 줄었습니다.
4. **집중 시간 확보**: 줄어든 인터럽트 덕에 매일 오전을 플랫폼 개선에 쓸 수 있게 되었습니다.
석 달 뒤 그 팀은 같은 인원으로 더 많은 일을 해냈고, 야근은 줄었습니다. 호스를 막은 것이 아니라, 호스 앞에 수도꼭지와 컵을 둔 것입니다.
11. 실전 체크리스트
쏟아지는 일에 휩쓸린다고 느낄 때:
- [ ] 인터럽트를 예외가 아니라 사양으로 받아들이고 계획에 버퍼를 넣었는가?
- [ ] 들어온 순서가 아니라 P0~P3로 트리아지하고 있는가?
- [ ] 요청 인테이크가 한곳으로 모이고 기록으로 남는가?
- [ ] 작은 요청을 배치로 모아 처리하는가?
- [ ] 집중 시간을 캘린더에 명시적으로 예약했는가?
- [ ] "급하다"는 말을 검증하는가? (기한·영향·트레이드오프 질문)
- [ ] 받았다는 신호와 예상 시점을 즉시 주는가? (침묵 금지)
- [ ] 반복 요청을 문서/자동화/근본 제거로 줄이고 있는가?
- [ ] 온/오프 경계, 온콜 순환으로 번아웃을 관리하는가?
- [ ] 처리한 일과 인테이크 데이터를 기록해 두는가?
12. 두 가지 모드를 의식적으로 오가기
쏟아지는 일을 잘 다루는 사람을 가까이서 보면, 그들은 한 가지 모드에 갇혀 있지 않습니다. 두 개의 모드를 의식적으로 오갑니다.
[반응 모드 vs 창작 모드]
반응(reactive) 모드 : 인터럽트에 응답. 빠른 판단, 가벼운 맥락.
슬랙을 켜두고, 짧은 작업을 처리.
창작(creative) 모드 : 깊은 집중. 큰 맥락을 머리에 올리고 본질을 만든다.
알림을 끄고, 한 가지에 몰입.
문제는 이 두 모드가 잘 섞이지 않는다는 것입니다. 창작 모드에 막 들어가려는 순간 인터럽트 하나가 반응 모드로 끌어내리면, 다시 들어가는 데 큰 비용이 듭니다. 반대로 반응 모드여야 할 시간에 깊은 작업을 붙들고 있으면, 막힌 동료들이 기다리며 답답해합니다.
핵심은 **모드를 섞지 않고 블록으로 나누는 것**입니다. 오전은 창작, 오후 일부는 반응 — 이렇게 시간대로 모드를 배정합니다. 그리고 자신이 지금 어느 모드인지 자각합니다. "지금 나는 반응 모드인가 창작 모드인가? 이 시간에 맞는 일을 하고 있는가?"라는 짧은 질문 하나가 하루의 결을 바꿉니다.
이 자각이 없으면 우리는 하루 종일 어중간한 회색지대에 머뭅니다. 집중하려다 알림에 반응하고, 반응하려다 집중에 미련을 두면서, 어느 쪽도 제대로 못 하는 상태. 쏟아지는 일 속에서 가장 흔한 소진의 형태가 바로 이 회색지대입니다. 모드를 선명하게 나누는 것만으로도, 같은 양의 일이 훨씬 덜 지치게 됩니다.
마치며
쏟아지는 일을 다루는 사람은 종종 보이지 않는 영웅입니다. 그들이 묵묵히 불을 꺼주는 덕에 다른 사람들이 계획대로 일할 수 있습니다. 하지만 영웅적으로 더 많은 물을 마시는 것은 답이 아닙니다. 그렇게는 결국 익사하거나 소진됩니다.
진짜 답은 시스템입니다. 트리아지로 우선순위를 가리고, 인테이크를 모아 가시화하고, 배치로 집중을 지키고, 반복을 자동화로 없애고, 경계로 자신을 지키는 것. 이렇게 하면 호스는 여전히 쏟아지지만, 여러분은 그 안에서 헤엄칠 수 있습니다. 그리고 더 나아가, 그 물줄기를 조금씩 길들여 갈 수 있습니다.
물을 더 빨리 마시려 하지 마십시오. 물길을 다스리는 사람이 되십시오.
참고 자료
- Cal Newport, *Deep Work* (집중과 맥락 전환의 비용)
- Christina Maslach & Michael Leiter, *The Truth About Burnout* (번아웃과 통제감)
- Google SRE Book, sre.google — 인터럽트와 온콜 관리, "Dealing with Interrupts"
- Will Larson, lethain.com — 운영 부하와 시스템적 접근
- Atlassian — 인시던트/요청 트리아지 가이드 (atlassian.com)
- Greg McKeown, *Essentialism* (선택과 거절)
현재 단락 (1/142)
월요일 아침, 여러분은 멋진 계획을 세웁니다. "오늘은 결제 모듈 리팩터링을 끝내야지." 커피를 내리고 자리에 앉습니다.