Home | Blog | 가이드

업무가 누락되는 이유 (또 다른 PM 툴로는 해결 안 됩니다)

업무가 계속 누락되고 있나요? 문제는 팀이나 도구가 아닌 도구 사이의 간극입니다. 시스템적인 해결책을 알아보세요.

By Ellis Keane · 2026-03-12

시장의 모든 프로젝트 관리 도구는 아무것도 사라지지 않는 곳이 되겠다고 약속합니다. 평균적인 팀이 이제 여섯 개에서 일곱 개의 도구를 동시에 사용하고, 각각이 엄숙하게 유일한 진실의 원천이라고 자처하는 반면, 실제 진실은 그 모든 곳에 분산되어 있고 어디에도 충실하게 기록되지 않는다는 점을 고려하면 흥미로운 홍보 문구가 아닐 수 없습니다. 업무가 누락되는 것은 특정 도구의 실패가 아닙니다 – 서로의 존재를 모르는 도구들에 작업을 분산시킨 자연스러운 결과입니다.

이것은 소프트웨어 문제가 아닙니다. 인간이라는 종의 문제입니다.

누락된 업무 하나의 해부: 포렌식 타임라인

작년에 함께 일했던 팀에서 실제로 누락된 특정 작업 하나를 추적해 보고 싶습니다 – 극적이어서가 아니라, 너무나 평범해서 그 누락이 팀에 약 일주일의 비용을 치르게 할 때까지 아무도 알아채지 못했기 때문입니다.

월요일, 오전 10시 14분. 디자이너가 Figma 파일에 댓글을 달아 설정 패널의 명암비에 관한 접근성 문제를 지적합니다. 리드 엔지니어를 @멘션합니다. 댓글은 Figma 안에 남아 있습니다 – 이 팀이 작업을 추적하는 곳이 아닙니다.

월요일, 오전 11시 02분. 엔지니어가 알림을 보고 Figma 파일을 열어 댓글을 읽고 "잘 잡았어요, 티켓 만들게요"라고 완전히 진심으로 답합니다. 45분쯤 후에 PR 리뷰에 빠져들어 완전히 잊어버립니다.

월요일, 오후 2시 30분. 같은 접근성 문제가 다가오는 릴리스에 관한 Slack 스레드에서 다시 불거집니다 – 누군가가 Figma 댓글과 연결했기 때문이 아니라, QA 엔지니어가 Lighthouse 감사를 실행해 같은 명암비 실패를 독립적으로 발견했기 때문입니다. 세 사람이 논의하고, 출시 전에 수정해야 한다고 동의하며, 누군가(누구인지 불분명한데, 이것이 문제의 일부입니다)가 "반드시 추적하겠다"고 말합니다.

화요일, 오전 9시 15분. 스탠드업. 아무도 명암비 문제를 언급하지 않습니다. Linear에 없으니 누구의 보드에도 나타나지 않습니다. 디자이너는 엔지니어가 티켓을 만들었다고 생각합니다. 관련 없는 리팩터링에 깊이 빠져 있는 엔지니어는 진심으로 잊어버렸습니다. QA 엔지니어는 Slack 스레드가 해결했다고 생각합니다. 모두의 추측은 완벽히 합리적이고 완전히 틀렸습니다.

목요일, 오후 4시. 릴리스가 배포되고, 명암비 문제도 함께 배포됩니다. 저시력 고객이 3일 후 지원을 통해 신고합니다. 실제 수정에 엔지니어가 약 20분이 걸리는 반면, 주변의 혼란 – 지원 티켓, 에스컬레이션, 어떻게 놓쳤는지에 대한 회고, 사과하는 커밋 메시지가 담긴 풀 리퀘스트 – 은 하루에 가까운 시간이 걸립니다.

금요일, 회고. 팀은 "티켓 관리를 더 철저히" 해야 한다고 동의합니다. 누군가 Slack 봇을 제안합니다. 다른 누군가는 주간 트리아지 회의를 제안합니다. 둘 다 완벽히 합리적인 아이디어이지만 실제로 일어난 일의 어느 것도 해결하지 않습니다.

진짜 문제는 도구가 아닙니다

타임라인을 보면, 시그널은 처음부터 존재했습니다 – 월요일 아침에 Figma에, 월요일 오후에는 Slack에. 세 사람이 각각 같은 문제를 파악하고, 논의하고, 중요하다고 동의했습니다. 정보는 정확하고, 가시적이었으며, 완전히 쓸모없었습니다. 가시성이 행동으로 전환되는 유일한 장소로의 도약을 아무도 실행하지 않았기 때문입니다.

작업 트래커에는 마케팅 자료에서 거의 논의되지 않는 근본적인 한계가 있습니다: 누군가 이미 입력한 작업만 추적할 수 있다는 것입니다. Figma 댓글은 Linear의 세계에 존재하지 않습니다. 세 사람이 무언가를 해야 한다고 결정한 Slack 대화도 존재하지 않습니다. 각 도구는 우수한 내부 검색 기능을 갖춘 폐쇄된 시스템이며, 옆에서 무슨 일이 일어나는지 전혀 인식하지 못합니다. 프로젝트 관리 업계는 20년간 더 나은 담벼락 정원을 만들어 왔고, 담벼락 사이의 공간에서 물건이 사라지는 것에 놀라워해 왔습니다.

해결책이 단순히 "더 나은 통합"이라면 편할 텐데 – 돈으로 해결할 수 있는 문제니까요. 하지만 "티켓 만들게요"라고 말한 엔지니어는 부주의했던 것이 아닙니다 – 그는 주의가 필요한 PR 리뷰에 빠져들었고, Figma 댓글에는 다시 알림 버튼이 없어서 컨텍스트 스위칭을 버텨내려면 순전히 그의 기억에 의존해야 했습니다. "반드시 추적하겠다"고 말한 QA 엔지니어는 부주의에서 비롯된 애매함이 아니었습니다 – Slack에서 "누군가 이걸 추적해야 한다"고 말하는 것은 실제로는 아무에게도 위임하지 않았음에도 구체적인 행동처럼 느껴집니다. 인테이크 폼, Slack-to-Jira 봇, "아직 티켓화되지 않은 것 있나요?"라는 스탠드업 필수 질문으로 이 간극을 메우려는 팀을 봐왔습니다 – 솔직히 일부는 한동안 효과가 있습니다(Slack 봇을 약 3개월 운영했는데 결국 사람들이 반사적으로 무시하기 시작했습니다. 자동화된 잔소리의 피할 수 없는 운명입니다).

불편한 진실은(솔직히 깔끔한 해결책이 있는지 자신이 없습니다), 직장에서 업무가 빠져나가는 것은 너무 많은 채널에 걸쳐 주의가 분산될 때 인간의 주의가 작동하는 방식의 결과라는 것입니다. 우리는 일관성 없는 생물입니다 – 쉽게 산만해지고, 피곤하며, 방관자 효과의 영향을 받습니다 – 아무리 훈련을 해도 오늘 서른 번 컨텍스트 스위칭을 했고 그때마다 머릿속에 있던 것을 조금씩 잃었다는 사실을 극복하지는 못합니다.

"누군가 문제를 파악했다"와 "누군가 문제를 추적했다" 사이의 간극에 대부분의 놓친 작업이 있습니다. 그 간극은 도구 문제가 아닌 인간의 주의력 문제이므로, 도구를 더 추가해도 거의 해결되지 않습니다.

실제로 도움이 되는 것들 (솔직한 주의사항 포함)

비용이 들지 않으면서 진짜 차이를 만드는 네 가지 방법이 있습니다. 각각의 한계에 대해서도 솔직하게 이야기하겠습니다. 어떤 것을 완전한 해결책인 양 내세우는 것은 정직하지 않으니까요.

순환 시그널 담당자. 팀에서 한 명씩, 주 단위로 순환하여, 추적되어야 하지만 추적되지 않는 것을 Slack 스레드와 회의록에서 찾는 역할을 맡깁니다. 방관자 문제를 명시적인 할당으로 바꾸기 때문에 제대로 운영될 때는 놀랍도록 효과적입니다 – 한 사람이 간극을 소유합니다. 한계는 시그널 담당자가 Figma 댓글, PR 리뷰 스레드, 이메일을 동시에 모니터링할 수 없다는 것입니다(할 수는 있지만 금방 풀타임 업무가 됩니다).

24시간 트리아지 SLA. 잠재적으로 실행 가능한 것으로 플래그된 모든 것은 하루 안에 정리합니다: 티켓화, 기존 티켓에 연결, 또는 – 대부분의 팀이 생략하는 이 부분 – 이유와 함께 명시적으로 기각. 그 기각이 매우 중요합니다. 누군가가 그 시그널을 보고 "아니오"라고 결정했다는 것을 의미합니다. 시그널을 무기한 공중에 떠 있게 내버려 두는 것보다 훨씬 낫습니다.

Slack 이모지 태깅. 티켓 이모지를 사용해 "이건 티켓이 필요해"를 의미하게 합니다. 누구든 어떤 메시지에도 태그할 수 있고, 2초면 됩니다. 시그널 담당자가 매일 아침 태그된 메시지를 확인합니다. 민망할 정도로 저기술이고 짜증날 정도로 효과적입니다 – 누군가 금요일 오후 4시 55분에 메시지를 태그하고 월요일까지 아무도 확인하지 않을 때까지는요.

PR 리뷰 체크포인트. 머지 전에: "이 리뷰의 댓글 중 티켓화가 필요한 것이 있었나요?" 한 가지 질문, 아마도 10초. 리팩터링 경고와 "나중에 이걸 고쳐야 해" 메모가 GitHub의 끝없는 아카이브 속으로 사라지는 것을 막습니다.

이것들은 모두 좋은 습관이며 하나하나 권장합니다. 하지만 공통된 한계가 있습니다: 인간이 일관되게 무언가를 기억하는 것에 의존하고(여기서 다시 종의 문제가 등장합니다), 우리는 그걸 잘 못합니다. 더 많은 누락을 잡을 수 있습니다. 전부는 아닙니다.

효과적인 것

순환 시그널 담당자 – 매주 순환하는 한 명이 도구 간 간극을 명시적으로 담당
24시간 트리아지 SLA – 실행 가능한 시그널을 하루 안에 분류하거나 명시적으로 기각
Slack 이모지 태깅 – 시그널에 티켓이 필요하다는 2초 플래깅
PR 리뷰 체크포인트 – 머지 전 한 가지 질문으로 추적이 필요한 댓글 포착

실패하는 것

개인 규율 – 인간이 지속적으로 기억하는 것에 의존 – 그렇게 하지 않는다
자동화된 알림 봇 – 모든 자동 알림처럼 결국 무시됨
PM 도구 추가 – 입력된 적 없는 작업은 추적 불가
"더 나은 통합" – UI 간극을 메우지만 인간의 주의 간극은 메우지 않음

프로젝트 관리 업계는 20년간 더 나은 담벼락 정원을 만들어 왔고, 담벼락 사이의 공간에서 물건이 사라지는 것에 놀라워해 왔습니다. attribution: Ellis Keane

도구가 아닌 간극을 감시하기

Chris와 제가 Sugarbug를 만들면서 계속 돌아온 질문이 있었습니다: 도구 자체가 아니라 도구 사이의 공간을 감시할 수 있다면 어떨까?

Sugarbug가 하는 일이 바로 그것입니다 – API를 통해 기존 설정에 연결하고, 소스 전반의 시그널을 연결하는 그래프를 구축합니다. Figma 댓글, Slack 스레드, PR 리뷰 댓글 모두 같은 그래프의 노드가 되어 서로, 그리고 관련된 사람들과 연결됩니다. 아무도 추적하지 않는 시그널이 들어오면, Sugarbug는 회고의 소재가 되기 전에 올바른 사람에게 그것을 표시합니다.

더 어려운 분류 문제 중 일부는 아직 개선 중이라는 것을 솔직하게 말씀드리고 싶습니다. "회의에서 큰 소리로 생각하는 것"과 "실제 실행 항목을 파악하는 것" 사이의 경계선은 어디일까요? 이것이 진짜 어려운 문제이며, 어떤 시스템도 – 우리 것을 포함해 – 100% 정확할 수 있다고 생각하지 않습니다. 하지만 핵심 루프 – 도구 전반의 시그널을 관찰하고, 실행 가능한 것을 분류하고, 추적되지 않은 것을 표시하는 – 는 작동하며, 실행한 것과 기각한 것으로부터 학습하면서 시간이 지남에 따라 개선됩니다.

---

Sugarbug는 도구 사이의 간극을 감시하여 아무것도 빠져나가지 않도록 합니다. 작동 방식 보기

---

업무 누락의 진짜 비용

포렌식 타임라인의 접근성 문제로 돌아가 보겠습니다. 하류 비용을 분명히 할 가치가 있기 때문입니다.

엔지니어링 수정에 20분이 걸렸습니다. 총 비용 – 지원 티켓, 고객 에스컬레이션, 내부 조사, 회고, 수정 PR – 은 세 명에게 분산된 하루에 가까웠습니다. 시그널 하나 누락, 약 여섯 시간의 낭비. 그 수치만 보면 끔찍하지 않지만, 제 경험상 8명에서 10명 규모의 팀은 스프린트당 서너 개의 시그널을 놓치며, 격주로 6시간에서 8시간의 낭비가 쌓입니다.

정량화하기 더 어려운 비용(그리고 더 비싼 비용이라고 생각합니다)은 주변의 배경 불안감입니다 – 멀티툴 팀의 모든 엔지니어가 안고 다니는 "내가 뭔가 잊고 있나?"라는 낮은 울림. 과도한 확인, "화요일에 그 건, 놓치지 않았는지 확인하려고요"라는 DM, 시스템이 컨텍스트를 유지한다는 것을 아무도 믿지 않아서만 존재하는 상태 회의. 스프린트 보고서에는 나타나지 않지만, 사람들이 자신의 일에 대해 느끼는 방식에는 확실히 나타나는 인지적 부하입니다. For a practical system to address this, see our guide on keeping work from slipping through the cracks. We also cover the dropped-ball pattern in project management for the organisational angle, and recovering after dropping the ball for when something has already been missed.

시그널 인텔리전스를 받은 편지함으로 받아보세요.

자주 묻는 질문

Sugarbug는 어떻게 업무 누락을 방지하나요?

Sugarbug는 API를 통해 도구에 연결하고, 시그널, 사람, 작업 항목 간의 관계를 매핑하는 지식 그래프를 구축합니다. 한 도구에 실행 가능한 것이 나타났지만 어디에도 추적되지 않은 경우, Sugarbug는 그것에 플래그를 달고 관련 컨텍스트와 연결하여 놓친 작업이 되기 전에 올바른 사람이 행동할 수 있도록 합니다.

Sugarbug는 프로젝트 관리 도구인가요?

아닙니다 – 이미 사용 중인 어떤 PM 도구 옆에도 자리합니다. Sugarbug는 Linear, Asana, Jira를 대체하지 않습니다. 도구 사이를 이동하는 시그널을 감시하고 간극으로 사라질 것들을 잡아냅니다.

팀이 프로젝트 관리 도구를 사용해도 업무가 누락되는 이유는 무엇인가요?

PM 도구는 명시적으로 입력된 작업만 추적할 수 있어, 상류의 모든 것에 대해 눈이 멉니다 – 누군가 우려를 제기한 Slack 스레드, 문제를 예측한 PR 댓글, 결정이 내려졌지만 기록되지 않은 회의. 대화와 티켓 사이의 간극이 대부분의 놓친 작업이 발생하는 곳입니다.

Sugarbug는 기존 프로젝트 관리 설정과 함께 사용할 수 있나요?

네. 현재 워크플로를 완전히 유지합니다. Sugarbug는 기존 도구에 연결하고 그 위에 시그널 감시 레이어를 추가합니다 – 일하는 방식을 바꾸라고 요구하지 않고, 그냥 하는 동안 더 적은 것이 빠져나가도록 할 뿐입니다.

"내가 뭔가 잊고 있나?"라는 낮은 울림이 익숙하게 들린다면, 바로 그 문제를 해결하기 위해 Sugarbug를 만들었습니다. 대기 목록에 참여하기.