놓친 작업은 사람의 문제가 아니다
프로젝트 관리에서 놓친 작업이 규율이나 기억력의 문제가 아닌 이유와, 팀에 자동 시스템이 필요한 시점.
By Ellis Keane · 2026-03-17
팀 전원이 함께 점심을 먹을 수 있을 만큼 작은 경우(적어도 이론적으로, 같은 도시에 동시에 있을 수 있다면), 아마 이 글을 읽을 필요가 없을 겁니다. 탭을 닫고 뭔가를 만드세요. 여러분의 규모에서 놓친 작업 문제는 수요일 오후 Slack 리마인더 하나로 해결됩니다. 진심입니다.
아직 여기 있나요? 그렇다면 프로젝트 관리에서의 놓친 작업에 대해 이야기해 봅시다. 더 구체적으로는, 팀이 일정 규모에 도달한 이후 왜 표준적인 조언이 통하지 않는지에 대해서요.
시작하기 전에
저희는 이 문제를 다루는 도구(Sugarbug)를 만들고 있습니다. 숨길 생각은 없습니다. 하지만 솔직히 말해, 이 글을 읽는 대부분의 팀에게는 저희가 만드는 것이 아직 필요하지 않습니다. 어쩌면 영원히 필요하지 않을 수도 있습니다. 그들에게 필요한 것은 왜 애초에 놓친 작업이 발생하는지를 이해하는 것입니다. 해결책은 원인에 따라 다르고, 원인은 대부분의 경우 사람들이 생각하는 것과 다르기 때문입니다.
왜 놓친 작업이 발생하는가
왜 놓친 작업이 발생하는지 대부분의 관리자에게 물어보면 익숙한 목록이 돌아옵니다. 누군가 잊었다, 누군가 주의를 기울이지 않았다, 누군가 프로세스를 따르지 않았다. 따라서 해결책은 더 나은 프로세스, 더 많은 리마인더, 매일 아침 사람들을 독려하는 스탠드업 봇일 것입니다.
물론, 때로는 그것이 진짜 문제인 경우도 있습니다. 엔지니어 한 명이 Linear 티켓 업데이트를 잊고 PM이 스프린트 리뷰 전에 확인하지 않았다면, 그것은 인적 실수이자 프로세스 격차입니다. 체크리스트를 추가하고 넘어가면 됩니다.
하지만 그것은 엔지니어링 관리자를 밤새 잠 못 이루게 하는 종류의 놓친 작업이 아닙니다. 진짜 고통스러운 것은, 모든 사람이 자신의 일을 하고, 프로세스를 따르고, 도구를 업데이트했음에도 불구하고 무언가가 빈틈에 빠지는 경우입니다. 빈틈이 사람과 작업 사이가 아니라, 한 도구와 다른 도구 사이에 있기 때문입니다.
이런 식입니다. 엔지니어가 GitHub 이슈를 닫는 PR을 올립니다. 그 이슈는 Linear 티켓과 연결돼 있고, 티켓은 "완료"로 이동합니다. 훌륭합니다. 하지만 원래 요청은 3주 전 Slack 대화에서 온 것이며, 그 자리에서 PM은 아무도 별도의 작업으로 기록하지 않은 후속 요구사항도 언급했습니다. 그 후속 사항은 2월의 Slack 스레드에 남아 있습니다. Linear에는 없습니다. GitHub에도 없습니다. 누구의 스프린트에도 없습니다. 기술적으로는 놓친 작업이지만, 어떤 개인도 그것을 떨어뜨린 게 아닙니다. Slack과 작업 추적기 사이의 구조적 빈틈에 빠진 것입니다.
이 패턴은 한 번 눈에 들어오기 시작하면 도처에서 나타납니다. 디자이너가 Figma에 엣지 케이스가 Notion 사양과 모순된다는 댓글을 남기지만, 그 기능을 담당하는 엔지니어는 Figma를 확인하지 않고, PM은 Linear 안에서만 살기 때문에 댓글을 보지 못합니다. 고객 성공 담당자가 통화에서 기능을 약속하고 이메일로 요약하지만, 그 특정 빈틈을 이어주는 사람이 없어 엔지니어링 백로그에는 들어가지 못합니다. 인시던트 사후 검토에서 세 가지 후속 항목이 식별되고 문서가 Slack에 공유되지만, 평소 그 일을 하는 사람이 그 주에 병가를 냈기 때문에 세 가지 중 두 가지는 결코 추적되는 작업이 되지 않습니다.
프로젝트 관리에서 가장 피해가 큰 놓친 작업은 사람과 작업 목록 사이의 빈틈이 아니라, 도구 간의 빈틈에서 발생합니다.
프로세스 해결책(그리고 그것이 통하지 않게 되는 시점)
저는 좋은 프로세스가 대부분의 팀에서 대부분의 문제를 해결한다고 진심으로 믿습니다. 무엇이 효과적인지 알려드리겠습니다. 런칭 전이기 때문에 지금 우리가 할 수 있는 최선은 유용함으로 신뢰를 쌓는 것이므로, 아무런 저의 없이 공유합니다.
주간 스윕. 1명(이상적으로는 PM 또는 엔지니어링 리드)이 매주 금요일 30분을 들여 Slack 스레드, 회의 노트, 이메일을 검토해 논의됐지만 추적되지 않은 것들을 건져냅니다. 지루하다고요? 물론입니다. 효과적이냐고요? 어느 정도까지는 놀랍도록 그렇습니다.
결정 로그. Slack 스레드나 회의에서 나온 모든 결정이 날짜, 결정자, 후속 조치와 함께 공유 문서(Notion, Google Docs, 무엇이든)에 기록됩니다. 단순하게 들립니다. 실제로도 그렇습니다. 네 개의 채널에서 주당 열다섯 개의 결정을 내리고 있고 어느 것이 기록됐는지 아무도 기억하지 못하기 전까지는요.
링크 규율. 모든 PR은 Linear 티켓을 참조합니다. 모든 Linear 티켓은 요구사항이 논의된 Slack 스레드와 연결됩니다. 모든 Notion 사양은 해당 Linear 에픽과 연결됩니다. 누군가 체인을 끊으면(그리고 반드시 누군가는 끊습니다. if의 문제가 아니라), 가시성도 함께 무너집니다.
이것들은 모두 좋은 관행입니다. 우리 자신도 이 모두의 버전을 사용하고 있습니다. 하지만 공통된 실패 모드가 있습니다. 인간이 매번, 영원히 일관되게 작고 지루한 일을 해야 한다는 의존성입니다. 그리고 그에 관한 연구 결과는 희망적이지 않습니다(연구를 인용할 필요도 없습니다. 5명 이상의 팀을 관리해본 적이 있다면 이미 알고 있으니까요).
프로세스 해결책이 확장되지 않는 시점
임계점이 있습니다. 정확한 숫자를 알려드릴 수 있으면 좋겠지만, 아직 파악하지 못했습니다(솔직히, 팀과 구성원의 규율에 따라 달라질 것입니다). 저희의 작업 경험칙은(벤치마킹된 데이터가 아닌 경험칙임을 명확히 하고 싶습니다), 네다섯 개의 도구, 10명 이상, 복수의 병렬 작업 흐름 근처에서 문제가 생기기 시작한다는 것입니다.
누군가 게을러졌기 때문이 아닙니다. 프로세스가 나빴기 때문도 아닙니다. 도구 간 연결의 양이 수동으로 추적할 수 있는 한 사람의 능력을 초과하기 때문입니다. 주간 스윕에 30분이 아닌 90분이 걸리고, PM은 대충 훑기 시작합니다. 결정 로그는 관리하던 사람이 휴가를 가고 아무도 이어받지 않아 낡아집니다. 링크 규율은 Linear와 GitHub에서는 유지되지만, 이 도구들이 동일한 종류의 구조화된 참조를 갖지 않아 Slack과 Figma에서는 무너집니다.
이것은(이 점을 명확히 하고 싶습니다) 확장성 문제이지, 규율 문제가 아닙니다. 저는 정말 뛰어난 PM과 엔지니어링 리드들이 이것으로 고군분투하는 것을 봐왔습니다. 빈틈 없이 운영하고, 아무것도 놓치지 않기를 진심으로 신경 쓰는 사람들이. 일정 규모가 되면 문제가 해결책을 능가합니다. 그것은 개인의 실패가 아닙니다. 도구 생태계가 자신들 사이의 연결을 제공하지 못하는 실패입니다.
"도구 사용에 정교해질수록 놓친 작업에 대한 더 복잡한 실패 표면을 얻게 됩니다. 저는 이것이 깊이 아이러니하다고 생각합니다." – Ellis Keane
그리고 이것이 진정으로 불공평하다고 생각하는 부분입니다. 팀이 도구를 더 잘 사용할수록, 도구 간 빈틈에 대한 표면적이 늘어납니다. Linear를 철저히 사용하고, Notion 사양을 최신 상태로 유지하고, 활발한 Figma 리뷰를 하고, 잘 정리된 Slack 채널에서 소통하는 팀은, 이메일과 스프레드시트만 사용하는 팀보다 더 많은 핸드오프 포인트를 갖습니다.
왜 당신의 도구가 도움이 되지 않는가
이 전체 문제에 대해 제가 진정으로 흥미롭다고 생각하고, 충분히 이야기되지 않는다고 생각하는 부분이 있습니다. 당신의 도구는 설계된 대로 정확히 하고 있습니다. Linear는 Linear 이슈 추적에 뛰어납니다. GitHub는 코드 변경 추적에 뛰어납니다. Notion은 문서 정리에 뛰어납니다. Slack은... Slack 역할을 하는 데 뛰어납니다(좋든 나쁘든).
하지만 그 중 어떤 것도 서로 간의 연결을 추적하도록 설계되지 않았습니다. 그리고 일, 진짜 일은 하나의 도구 안에서 일어나지 않습니다. 모든 도구를 가로질러 흐릅니다. 도구 간 핸드오프 포인트가 무언가가 사라지는 곳이며, 개별 도구를 아무리 개선해도 그것은 고쳐지지 않습니다. Linear를 이슈 추적에서 더 좋게 만들 수 있지만, 그것은 엔지니어링 리드가 모니터링하지 않는 채널에서 일어난 Slack 대화를 바탕으로 처음부터 이슈가 만들어졌어야 했을 때는 도움이 되지 않습니다.
실제로 무엇이 해결하는가
이 포스트에서 제품에 대해서는 의도적으로 모호하게 했습니다. 저희가 만드는 것을 사용하든 안 하든 유용하길 원했기 때문입니다. 하지만 여기까지 오셨으니(감사합니다), 실제 해결책이 어떤 모습인지에 대해 솔직하게 말씀드리겠습니다.
더 나은 작업 추적기가 아닙니다. 더 나은 프로세스도 아닙니다. 스탠드업 봇이나 주간 리뷰나 공유 스프레드시트도 아닙니다. 이것들은 모두 도움이 되고 소규모에서는 충분하지만, 모두 증상을 치료하는 것입니다.
실제 해결책은 도구 간의 연결을 모니터링하고 뭔가 맞지 않을 때 플래그를 표시하는 것입니다. Slack 결정이 티켓이 되지 않을 때. GitHub PR이 이슈를 닫았지만 미해결 댓글이 있을 때. Notion 사양이 사양 작성자가 보지 못한 대화에서 우선순위가 낮아진 요구사항을 참조할 때.
구체적으로 설명하기 위해 어떤 모습인지 살펴보겠습니다. 시스템이 Slack과 Linear 모두를 모니터링하고 있다고 가정해봅시다. #engineering의 대화에서 누군가 "이메일을 인증하지 않은 사용자의 경우도 처리해야 합니다"라고 말하는 것을 봅니다. 새로운 요구사항입니다. 그 요구사항이 48시간 내에 Linear 티켓으로 나타나지 않으면, 시스템이 플래그를 표시합니다. 당신을 향해 소리치는 알림이 아니라(아무도 그 이상은 필요 없습니다), PM이 금요일 스윕 중에 검토할 수 있는 "아직 추적되지 않은 결정" 뷰의 항목으로. Linear 티켓을 닫았지만 오픈된 리뷰 댓글이 여전히 있는 GitHub PR, 또는 사양이 작성된 이후 우선순위가 낮아진 기능을 참조하는 Notion 사양에도 같은 개념입니다.
이것을 내부적으로 구축하든(일부 팀은 웹훅, 메시지 큐, 적당한 양의 연결 코드로 합니다), 기성 제품을 사용하든, 놓친 작업을 사업 비용으로 받아들이든, 그것은 당신의 결정입니다. 저희는 이 답의 한 버전을 만들고 있지만, 그것이 유일한 버전이 아니며 많은 팀에게는 아직 올바른 것이 아닙니다.
이것이 언제 당신에게 올바른 것이 될지 알고 싶다면, 제 솔직한 경험칙은 이것입니다. 주간 스윕에 30분 이상 걸리고 여전히 놓치는 것들이 있다면, 수동 방식을 넘어선 것입니다.
---
주간 스윕에 30분 이상 걸리고 여전히 놓치는 것들이 있다면, 수동 방식을 넘어선 것입니다. Sugarbug는 자동으로 빈틈을 모니터링합니다.
Q: Sugarbug는 프로젝트 관리에서 놓친 작업을 어떻게 방지합니까? A: Sugarbug는 Linear, GitHub, Slack, Figma, Notion 등 여러 도구에 걸쳐 지식 그래프를 구축하고, 작업·대화·결정이 도구 간에 이동할 때 추적합니다. 무언가가 멈추거나 원래 요청과의 연결이 끊어지면, Sugarbug가 그것이 빈틈에 빠지기 전에 표면화합니다. 리마인더 시스템이 아닙니다. 도구 간 항목 사이의 관계를 이해하고, 그 관계가 끊어질 때 플래그를 표시합니다.
Q: Sugarbug는 Slack에서 논의됐지만 기록되지 않은 작업을 찾을 수 있습니까? A: 네. Sugarbug는 Slack 대화를 모니터링하고, 결정이나 액션 아이템이 논의됐지만 Linear의 작업이나 GitHub의 티켓으로 등록되지 않은 경우를 감지합니다. 누군가 조치를 취할 수 있도록 해당 빈틈에 플래그를 표시합니다. 얼마나 공격적으로 플래그를 표시해야 할지는 아직 다듬고 있지만(다른 모든 것 위에 통합 피로는 필요 없으니까요), 핵심 감지는 작동합니다.
Q: 놓친 작업을 수정하려면 도구가 필요합니까, 아니면 프로세스 문제입니까? A: 솔직히 말해 규모에 달려 있습니다. 두세 개의 도구를 사용하는 소규모 팀은 보통 더 나은 습관(주간 리뷰, 공유 문서, 링크 규율)으로 해결할 수 있습니다. 하지만 도구가 네다섯 개를 넘고 인원이 10명 이상이 되면, 수동 방식은 더 이상 확장되지 않으며 자동으로 연결을 추적하는 무언가가 필요합니다. 임계점은 팀마다 다르지만, 도달했을 때 알게 될 것입니다.
Q: 작업 추적기와 프로젝트 관리용 시그널 인텔리전스 시스템의 차이는 무엇입니까? A: 작업 추적기는 입력된 내용을 기록합니다. 시그널 인텔리전스 시스템은 도구 전반에서 실제로 일어나고 있는 일을 감시하고, 뭔가 맞지 않을 때 플래그를 표시합니다. 완료로 표시됐지만 미해결 댓글이 있는 작업, Slack에서 내려진 결정이 사양서에 반영되지 않은 경우 등입니다. 우리의 경험상 대부분의 빈틈이 실제로 발생하는 곳인, 인간이 기록하지 못한 것들을 잡아냅니다.