늦게까지 불을 껐다고 성과가 되진 않습니다

PM의 진짜 가치는 당장 터진 불을 빠르게 끄는 것이 아니라, 제품이 가야 할 방향을 제시하고 팀이 함께 문제를 풀 수 있는 시스템을 만드는 데 있습니다.

남들의 요청을 즉각 해결해 줄 때 느끼는 '내가 필요한 사람'이라는 착각에 빠지다 보면, 정작 PM 본연의 과제는 야근 시간으로 밀려나게 됩니다. 내가 모든 불을 다 끄려 하면 나 자신이 먼저 소진되고 팀도 함께 성장할 수 없습니다. 번아웃을 막고 진짜 우선순위를 사수하기 위한 실전 가이드를 정리했습니다.

• SLA (Service Level Agreement): 서비스 수준 합의서. 이슈 발생 시 시급성과 중요도에 따라 대응 시간과 담당자를 미리 정의해 두는 규칙.

• Focus Time (집중 시간): 실시간 알림을 끄고 회의나 긴급 요청의 방해 없이 고차원의 기획 및 전략 수립에 몰두하는 시간.

• Async Communication (비동기 소통): 실시간 대화 대신 텍스트 문서나 티켓 시스템(Jira, Notion 등)을 활용해 각자의 작업 호흡을 깨지 않고 소통하는 방식.

• Triage (트리아지): 쏟아지는 응급 환자 중 치료 순서를 정하듯, 인입된 이슈의 심각도를 판단하여 우선순위를 분류하는 작업.

오늘의 Y's Insight는 다양한 프로덕트를 런칭하며 현장의 시행착오를 겪어온 8년 차 멘토 Lina님이 작성했습니다.

1. '필요한 사람'이 되는 달콤한 함정과 '공동 소방수'의 필요성

신규 비즈니스 기능을 배포하고 나면 현장의 온갖 요청이 PM에게 몰려듭니다. "이 버튼 클릭 시 오류가 나요"라는 정당한 리포트부터, 배포와 무관한 단순 네트워크 오류인데도 "이번 배포 때문에 안 되는 거 아니냐"며 다급하게 밀려오는 문의, 그리고 영업팀의 "이 기능 당장 내일까지 고쳐주세요"라는 긴급 호출까지 다양합니다.

이런 요청을 즉각 해결해 주다 보면 이상하게 뿌듯한 기분이 듭니다. '내가 이 회사에 꼭 필요한 사람이구나', '나 없으면 안 돌아가는구나'라는 자부심에 더 친절하고 바쁘게 응대하게 되죠.

저 역시 새로운 환경에 적응하던 시기에 같은 함정에 빠진 적이 있습니다. 이해관계자와 동료들에게 '믿을 수 있는 사람'으로 각인되고 싶어서, 근무시간에는 들어오는 문의에 최대한 빠르게 답하고 동료의 부탁을 늘 제 일보다 앞에 두었습니다. 그러다 보니 정작 계획대로 써야 할 문서는 매번 주말로 밀렸고, 어느 순간부터는 '주말 중 하루는 원래 일하는 날'이라고 스스로 당연하게 받아들이고 있더군요. 그렇게 인정받고 있다고 믿었는데, 이상하게 몸과 마음은 점점 더 빠르게 소진되고 있었습니다.

하지만 이건 위험한 '영웅 심리'의 함정입니다. 내가 모든 불을 다 끄려고 하면 결국 나부터 타버립니다. 더 큰 문제는 PM이 모든 문제를 독점 처리하면서 조직 전체가 스스로 문제를 해결하는 프로세스를 만들 기회를 빼앗는다는 점입니다. 당장은 내가 없으면 안 될 것 같더라도, PM 혼자 전담 소방수가 되는 게 아니라 팀원 누구나 문제를 보고 대응할 수 있는 '공동 소방수' 시스템을 만드는 것으로 관점을 전환해야 합니다.

2. 모든 불에 물을 뿌리지 마세요: 심각도에 따른 우선순위

울리는 모든 경보에 똑같이 물통을 들고 뛰어갈 필요는 없습니다. 응급실에서 환자의 위중도에 따라 치료 순서를 정하듯, 인입된 이슈도 심각도에 따라 트리아지(Triage)해야 합니다.

• P0 (치명적 불): 결제 마비, 핵심 기능 불능 등 비즈니스에 즉각적 타격을 주는 이슈 → 즉시 대응

• P1 (번지는 불): 당장 비즈니스가 멈추진 않지만 방치하면 커지는 이슈. 주요 기능의 부분 오류, 같은 문의 반복 인입 → 당일 내 대응 계획을 세워 처리

• P2/P3 (그을리는 불): 특정 기기의 텍스트 깨짐, 단발성 접속 해프닝 → 기록 후 백로그(Backlog)로 이관

단발성 불편함이나 현업의 조급함 때문에 핵심 기획을 내려놓아서는 안 됩니다. 한 발 물러서서 "지금 이 불을 당장 안 끄면 프로덕트가 망하는가?"를 자문해 보세요. 일부 불은 잠시 타게 두더라도 근본 원인을 찾아 우선순위대로 해결하는 결단이 필요합니다.

3. Focus Time의 핵심: 남들 일할 때 대응하고 밤에 기획하는 걸 당연해하지 마세요

많은 시간 관리 이론에서 "주 n회, n시간씩 집중 시간을 캘린더에 블로킹하라"고 당부합니다. 하지만 실제 현장에서 매주 정해진 틀을 사수하기란 결코 쉽지 않습니다.

여기서 우리가 정말 경계해야 할 것은 "낮에는 온갖 문의 대응을 해주고, 내 본업(기획/분석)은 퇴근 후나 주말에 하면 되지"라는 생각입니다. 앞서 고백했던 저의 '주말 하루 출근'이 바로 이 생각의 결과였습니다. 남들 일하는 시간에 소방수 노릇을 하느라 진짜 집중 시간을 업무 외 시간으로 미루는 것은, 한번 당연해지고 나면 되돌리기가 훨씬 어렵습니다.

이론적인 수치에 목매기보다, 내 상황에 맞게 주중에 단 1~2시간이라도 '방해받지 않는 시간'을 계획해 보세요. 그리고 낮 일과 시간 안에 그 시간을 반드시 포함하려는 의도적인 노력이 필요합니다.

4. 바쁜 하루가 성과를 보장하지는 않습니다

하루 종일 쏟아지는 슬랙 메시지에 1분 만에 답장하고, 수십 개의 이슈를 즉각 처리했다고 해서 훌륭한 PM이 되는 것은 아닙니다. 회사가 PM에게 진짜 기대하는 것은 '얼마나 불을 잘 끄는가'가 아니라 '어떤 임팩트로 제품을 성장시켰는가'입니다.

바쁘게 응대하고 있다는 안도감은 진짜 어렵고 머리 아픈 '문제 정의'와 '전략 기획'을 뒤로 미루게 만드는 핑계가 되기 쉽습니다.

그래서 저는 일주일에 한 번, 이번 주 업무를 두 줄로 나눠 적어보기를 권합니다. 한 줄에는 '내가 대응한 것'(문의 처리, 버그 수습, 긴급 요청), 다른 한 줄에는 '내가 만들어낸 것'(PRD, 의사결정, 개선된 프로세스)을 적는 겁니다.

오해하지 않았으면 하는 것은, '대응한 것'이 많다고 해서 무조건 잘못하고 있다는 뜻은 아니라는 점입니다. 배포 직후처럼 대응이 곧 본업인 시기도 있고, 매주 새로운 기획을 할 일이 있는 것도 아니니까요. 이 기록의 목적은 자책이 아니라 관찰입니다. 몇 주, 몇 달간 꾸준히 적다 보면 '지금은 대응에 힘을 쏟을 시기'인지, '슬슬 만드는 쪽으로 무게를 옮겨야 할 때'인지 스스로 밸런스를 느끼고 잡아갈 수 있게 됩니다. 남이 정해준 기준이 아니라 내 기록이 알려주는 감각이라 더 오래갑니다.

• 문의 처리 창구 하나로 일원화하기: 개인 DM으로 오던 모든 문의를 공용 채널이나 티켓으로 모아, 나 외의 동료도 현황을 볼 수 있게 하세요. 이것이 곧 실시간 응답 압박에서 벗어나 각자의 작업 호흡을 지키는 비동기 소통(Async Communication)의 시작입니다.

• 낮 시간대 'Focus Block' 딱 1개 설정하기: 오늘 하루 중 1시간이라도 좋으니 업무 시간 내 알림을 끄고 내 기획서에만 집중하는 시간을 만들어 보세요.

• 이슈 등급별 대응 기준(SLA) 팀과 합의하기: "P0은 즉시, P1은 당일 내, P2 이하는 백로그 검토"처럼 심각도별 대응 시간을 미리 정해두세요. 매번 "이거 급한 거예요!"라는 말에 흔들리는 대신, 내 판단이 아닌 '팀이 합의한 기준'으로 답할 수 있게 됩니다.

물론 전담 CS나 QA 인력이 부족한 초기 조직에서는 PM이 직접 불을 꺼야 하는 순간이 반드시 존재합니다. 배가 가라앉고 있는데 "제 R&R이 아닙니다"라고 할 수는 없으니까요.

하지만 중요한 것은 '지금 내가 임시로 불을 끄고 있다'는 사실을 인지하는 것입니다. 문제 해결 후에는 "다음번에 이와 비슷한 문의가 올 때 PM을 거치지 않고 현업이 직접 확인하게 만들려면 어떤 FAQ나 프로세스가 필요한가?"를 고민해 보세요. 그래야 나도 살고, 팀도 함께 일하는 문화가 만들어집니다.