여러 도구에서 작업을 놓치지 않고 추적하는 방법
여러 도구에서 작업을 추적하려는 팀은 결국 스프레드시트를 만든다. 왜 실패하는지, 그리고 시스템 수준의 해결책이 무엇인지 알아보자.
By Ellis Keane · 2026-03-13
최고의 시스템은 11일 동안만 지속됐다
내가 여러 도구에서 작업을 추적하기 위해 사용한 최고의 시스템은 스프레드시트였다. 깔끔하고 논리적이며 보기 좋게 색으로 구분되어 있었고, 현실에 먹히기 전까지 약 11일 동안 지속됐다 – 이것은 내가 파악한 바로는, 유지하는 사람들이 얼마나 똑똑하든, 얼마나 많은 조건부 서식 규칙을 정성스럽게 적용했든 관계없이, 모든 수동 추적 시스템의 보편적인 반감기다.
Linear 티켓, 있는 경우 GitHub PR, 컨텍스트를 담은 Notion 문서 링크, 그리고 실제로 무슨 일이 일어나고 있는지를 반영해야 하는 상태 필드에 대한 열이 있었다. 모두 완벽히 합리적이었고, 2주 안에 완전히 포기됐다. 왜냐하면 6인 팀의 누구도 도구 자체가 자신을 추적할 수 없다는 이유만으로 존재하는 스프레드시트를 업데이트하기 위해 실제 업무에서 컨텍스트 스위칭을 하고 싶지 않았기 때문이다. 추적 작업에 대한 작업이라는 이 전체 과정은 1인당 하루 약 30분을 소비했으며, 분기에 걸쳐 계산하면 정말 우울한 숫자가 된다. 우리는 사실상 누군가 확인할 때쯤에는 이미 틀린 문서를 유지하기 위해서만 정규직 직원 1명분의 시간을 지불하고 있었다.
하지만 이런 점이 있다: 정보는 항상 거기에 있었다 – 모든 이슈에는 상태가 있었고, 모든 PR에는 리뷰 상태가 있었고, 접근 방식이 바뀐 Slack 스레드에는 누구든 필요로 하는 모든 컨텍스트가 있었다. 문제는 정보가 없었던 것이 아니라 – 각 도구가 전체 그림의 자신의 작은 구석만 알고 있었고, 그것들을 연결하는 유일한 것이 각 조각을 어디서 봤는지에 대한 누군가의 기억이었다는 것이다. 그 기억이 실패하면 (그리고 결국은 항상 실패하며, 보통 가장 중요한 날에), 작업은 나중에 재구성하기가 정말 어려운 방식으로 놓쳐졌다.
왜 다른 도구로 여러 도구의 작업을 추적할 수 없는가
우리 업계에는 도구 간 작업 추적의 해결책이 더 나은 도구라는 지속적인 믿음이 있다 – 더 스마트한 프로젝트 관리 플랫폼, 더 강력한 대시보드, 팀이 하는 모든 것에 걸쳐 전설의 "단일 창"을 마침내 제공할 무언가. 프로젝트 관리 업계는 지난 10년 동안 정확히 이런 제품들을 구축해왔다. 지금 이 시점에 수십 개가 있으며, 수십 개가 있다는 사실은 어느 하나가 문제를 얼마나 잘 해결했는지에 대해 무언가를 알려줄 것이다. 첫 번째가 효과가 있었다면 37번째는 필요하지 않았을 것이다.
"첫 번째가 효과가 있었다면 37번째는 필요하지 않았을 것이다." – Ellis Keane
나는 한동안 그 신화를 믿었다. 이 도구들 중 여럿을 시도했고 (모두 이름을 대지는 않겠지만, 이 길을 걸어봤다면 아마 같은 것들 몇 가지를 시도했을 것이다), 그것들 모두 같은 근본적인 한계를 공유했다: 여전히 단일 도구였다. GitHub 데이터를 Slack 스레드 및 Notion 페이지와 함께 집계하는 대시보드는 스프레드시트보다 낫지만, 여전히 "작업"이 무엇인지에 대한 자신만의 모델을 강요하고 다른 모든 사람의 모델을 자신의 스키마에 억지로 맞추려 한다. 정보는 평탄화되고, 관계는 사라지며, 결국 이미 접근할 수 있던 데이터의 매우 비싼 읽기 전용 뷰가 남는다.
그리고 내가 거의 희극적으로 완벽하다고 생각하는 재귀적인 부분이 있다: 통합 설정, 매핑 구성, 또 다른 대시보드 유지, 또 다른 앱 확인을 요구하는 "단일 창"은 도구 피로를 줄이는 것이 아니라 – 늘리고 있다. 이제 n개가 아닌 n+1개의 도구가 있고, n+1번째 도구의 전체 역할은 다른 n개를 감시하는 것이다. 즉, 그 정확도는 감시하는 도구의 수와 해당 도구가 API를 변경하는 빈도에 정비례하여 저하된다. 너무 많은 도구가 있어서 도구를 관리하는 도구를 채택하고, 그 도구가 제대로 작동하지 않으면 격차를 메워야 했던 도구가 남긴 격차를 채우기 위해 또 다른 도구를 채택한다. 어느 시점에 한 발 물러서서 SaaS 구독의 루브 골드버그 기계를 만들었다는 것을 깨닫는다. 그리고 실제 작업 – 이 모든 도구가 지원해야 했던 것 – 은 도구 덕분이 아니라 도구에도 불구하고 이루어지고 있다.
신화는 이것이 가시성 문제라는 것이다 – 한 곳에서 모든 것을 볼 수 있다면 괜찮을 것이라고. 실제로는 관계의 문제다. 각 도구가 작업이 무엇인지에 대한 자신의 모델을 가지고 있고 그 모델들은 근본적으로 호환되지 않기 때문에 단일 도구는 여러 도구에 걸쳐 작업을 추적할 수 없다. 그것들을 나란히 표시하는 대시보드는 모델을 호환 가능하게 만들지 않는다. 그저 비호환성을 더 보기 좋게 만들 뿐이다.
도구 간 추적이 실패하는 것은 데이터를 볼 수 없어서가 아니라 데이터가 어떻게 연결되는지 이해하는 도구가 없기 때문이다. 대시보드는 다섯 곳의 사실을 보여주지만, 그 사실들이 모두 같은 작업에 관한 것임을 알지 못한다.
각 도구가 실제로 보는 것
추상화가 실제 상황이 얼마나 나쁜지를 숨기고 있다고 생각하기 때문에 구체적으로 살펴보겠다.
단일 작업 – 새 API 엔드포인트 구현을 예로 들어보자. Linear에서는 상태, 담당자, 우선순위, 사이클을 가진 이슈다. GitHub에서는 리뷰 상태, CI 검사, 머지 상태를 가진 PR (또는 아마 두 개 – 백엔드용과 클라이언트용)이다. Slack에서는 누군가 접근 방식에 대해 질문하고 세 사람이 40개의 메시지에 걸쳐 토론하다가 완전히 다른 설계에 도달한 스레드다. Notion에는 두 사람이 기여하고 Slack 대화가 모든 것을 바꾼 후 한 사람이 업데이트하는 것을 잊어버린 RFC 페이지가 있다. 그리고 Figma 어딘가에는 처음에 전체 변경을 촉발한 원래 디자인에 대한 댓글이 있다.
다섯 개의 도구, 하나의 작업, 그리고 그 도구들 중 어느 것도 다른 네 개가 같은 것에 대해 이야기하고 있다는 것을 알지 못한다. Figma 댓글은 RFC가 존재하는지 모른다. Slack 스레드는 티켓이 있다는 것을 모른다. GitHub은 접근 방식이 바뀌었다는 것을 모른다. 각 도구는 자신의 도메인을 아름답게 추적한다 – 문제는 여러 도구에 걸친 작업의 전체 생명주기를 보는 단일 도구가 없다는 것이다.
인간의 기억은 이 모든 섬들의 다리이며, 인간의 기억 (통화 중에 Slack 스레드를 놓친 경험이 있는 사람이라면 누구나 말할 수 있듯이)은 전체 프로젝트 가시성을 구축하기에는 우울할 정도로 유한한 자원이다.
작업이 사라지는 세 가지 방법
도구 간 추적이 수십 개의 작업에 걸쳐 실패하는 것을 보고 (그리고 솔직히 우리 자신도 상당한 수의 실패에 기여한 후), 패턴이 보이기 시작했다. 실제로 세 가지 뚜렷한 실패 모드가 있으며, 다른 수정이 필요하기 때문에 이름을 붙이는 것이 유용하다고 생각한다.
유령 작업. 작업은 하나의 도구에 존재하지만 다른 도구에는 표시되지 않는다. 누군가 이슈를 등록하고, 관련 PR이 누구도 연결하지 않은 채 이루어지며, 접근 방식에 대한 논의가 이슈 작성자가 없는 채널에서 이루어지고, 3주 후 작업은 조용히 완료하고 넘어간 사람을 제외한 모두에게 막혀있는 것처럼 보인다. 작업은 완료됐다 – 아무도 모른다.
오래된 상태. 실제 진행 상황이 다른 곳에서 추적되기 때문에 하나의 도구에서 작업 상태가 현실과 동기화되지 않는다. 티켓은 여전히 "진행 중"이라고 표시되지만 PR은 어제 머지됐다. 문서는 "초안"이라고 표시되지만 팀은 이미 아무도 북마크하지 않은 스레드에서 다른 접근 방식을 승인했다. 소위 진실의 출처를 확인하는 사람은 누구든 잘못된 그림을 얻고, 오래된 데이터를 기반으로 결정이 내려진다.
고아 컨텍스트. 이것이 가장 미묘하며, (내 경험상 적어도) 가장 실제 피해를 일으키는 것이다. 작업의 방향을 바꾸는 대화가 일어난다 – 아무도 예상하지 못한 제약이나 누군가가 생각해낸 더 나은 접근 방식일 수 있다 – 하지만 그 대화는 결코 원래 사양에 반영되지 않는다. 2주 후, 누군가 원래 요구 사항을 기반으로 작업을 집어들고, 잘못된 것을 구축하며, 팀은 스프린트 분량의 작업을 잃는다. 컨텍스트는 항상 존재했다 – 단지 작업이 알지 못한 도구에 살아있었을 뿐이다.
세 가지 실패 모두 같은 근본 원인을 가지고 있다: 도구들이 무슨 일이 일어나고 있는지에 대한 모델을 공유하지 않는다. 그것들은 인간의 주의 다리를 가진 섬이며, 인간의 주의는 항상 부족한 자원이다.
지금 바로 할 수 있는 것 (아무것도 사지 않고)
시스템 수준의 수정에 들어가기 전에 (그리고 이것이 영업 피치로 가는 빌드업이 아니라고 약속한다 – 글쎄, 완전히는 아니지만), 규율과 몇 가지 가벼운 프로세스 변경만으로 도구 간 추적 실패를 실제로 줄이는 데 도움이 되는 몇 가지가 있다. 우리는 무언가를 구축하기 전에 이것들을 모두 시도했으며, 그 중 일부는 더 나은 도구로도 여전히 중요하다.
모든 작업에 표준 홈을 지정한다. 상태의 진실 출처로 하나의 도구를 선택하고 (우리에게는 Linear) 어디서 대화가 일어나든 상태를 변경하는 결정은 24시간 내에 반영된다는 팀 규칙을 만든다. 이것은 문제를 해결하지 않지만, 오래된 상태 실패 모드를 상당히 줄인다.
주간 고아 컨텍스트 스윕을 만든다. 일주일에 한 번, 누군가 (교대로) 지난 주의 Slack 스레드를 스캔하고 결정이나 방향 변경이 관련 티켓이나 문서에 캡처됐는지 확인한다. 15분의 의도적인 브리징은 예상보다 더 많은 놓쳐진 컨텍스트를 잡아낸다.
크로스 링크를 철저히 사용한다. PR을 열 때 이슈를 연결한다. 작업에 대한 Slack 스레드를 시작할 때 첫 번째 메시지에 티켓 URL을 넣는다. 문서를 업데이트할 때 스레드에서 언급한다. 이것은 지루하고 수동적이며 아무도 하고 싶지 않다 (그래서 시간이 지남에 따라 저하된다), 하지만 작동하는 동안은 잘 작동한다.
오래된 상태 SLA를 설정한다. 티켓이 5영업일 동안 업데이트되지 않았고 관련 PR이나 스레드에 활동이 있으면 표시한다. 이것은 누군가 눈으로 확인하는 주간 Linear 필터만큼 간단할 수 있다.
이것들 중 어느 것도 영구적인 해결책이 아니다 – 모두 인간이 일을 기억하는 것에 의존하는데, 이것이 바로 우리가 신뢰할 수 없다고 확인한 자원이다 – 하지만 문제가 구조적인 수정을 정당화할 만큼 심각한지 파악하는 동안 피해를 의미 있게 줄인다.
진짜 수정이 어떻게 보이는가 (그리고 우리가 아직 파악 중인 것)
여기서 주의하고 싶다. 너무 많이 약속하는 도구들에 대해 냉소적인 여러 단락을 쓴 후, 마지막으로 하고 싶지 않은 것은 돌아서서 같은 종류의 약속을 하는 것이다. 그러니 우리가 생각하는 진짜 수정이 무엇인지, 우리 자신도 이 중 일부를 아직 진행 중이라는 솔직한 주의와 함께 설명하겠다.
핵심 인사이트 – 말하고 나면 명백하게 들린다는 것을 알지만, 여기에 이르는 데 시간이 걸렸다 – 는 또 다른 대시보드가 필요하지 않다는 것이다. 지식 그래프가 필요하다. 도구에서 나온 데이터의 읽기 전용 집계가 아니라, 도구 전반에 걸친 항목 간의 관계를 능동적으로 이해하는 것이 필요하다. PR이 설명에 이슈 번호를 참조하고, 누군가 둘 다 언급하는 스레드에서 접근 방식을 논의하고, 디자인 댓글이 원래 사양에 링크되는 경우, 지식 그래프는 명시적인 참조 매칭, 콘텐츠 간의 의미적 유사성, 관련 활동의 시간적 근접성을 통해 이것들을 자동으로 연결할 수 있다 – 누구도 수동으로 연결할 필요 없이.
---
Sugarbug은 분산된 도구를 살아있는 지식 그래프로 연결합니다. 작업, 사람, 대화 – Slack, GitHub, Notion, Figma 등 전반에 걸쳐 자동으로 연결됩니다. 실행 시간이 길수록 더 스마트해집니다. 작동 방식 보기
---
이것이 우리가 Sugarbug으로 구축하는 것이다. 기존 도구에 연결하고 (새로운 것을 채택하지 않는다 – 팀이 이미 알고 있는 것을 계속 사용한다) 모든 것이 어떻게 관련되는지에 대한 그래프를 구축한다. 그래프 접근 방식은 세 가지 실패 모드 모두를 잡을 수 있음을 의미한다: 유령 작업은 누구도 티켓에 연결하지 않아도 시스템이 PR 활동을 보기 때문에 감지된다. 오래된 상태는 이슈가 업데이트되지 않아도 시스템이 코드가 머지됐다는 것을 알기 때문에 표시된다. 고아 컨텍스트는 작업 소유자가 보고 있지 않은 곳에서 대화가 일어나도 시스템이 스레드 결정을 영향을 받는 작업에 연결하기 때문에 표면화된다.
이것들 모두를 아직 동등하게 잘 해내지 못했다는 것을 솔직히 말해야 한다 – 그리고 대화 의도를 이해하는 것은 아직 정말 어렵기 때문에 고아 컨텍스트 문제가 루프에 인간의 판단 없이 완전히 해결 가능한지 정말 모른다. 유령 작업 감지는 탄탄하고, 오래된 상태 표시는 진행되고 있으며, 컨텍스트 표면화가 우리가 밀고 있는 프론티어다. 하지만 아키텍처는 새로운 각 연결이 모든 기존 연결을 더 스마트하게 만들고, 그 복합 효과가 솔직히 이 프로젝트에서 내가 가장 흥미롭다고 생각하는 부분이다.
우리에게 일어난 변화
도구 간 추적이 부분적으로라도 제대로 되었을 때 가장 놀라운 점은 시간 절약이 얼마나 구체적으로 느껴지는가다. 분기별 검토에서 추상적인 생산성 지표가 아니다 – 접근 방식이 왜 바뀌었는지 설명한 스레드를 찾아 매일 아침 Slack에서 20분을 보내는 것을 멈췄고, "X는 어떻게 됐어?"라고 물어보고 누군가가 세 곳을 확인한 후에야 대답할 수 있을 때까지 기다리는 것을 멈췄다.
우리 팀은 (대략적인 추정, 대조 연구가 아님) 집합적으로 하루에 2~3시간을 내가 작업에 대한 작업이라고만 설명할 수 있는 것에 쓰고 있었다: 추적 문서 업데이트, 도구 간 컨텍스트 검색, 자동으로 연결됐어야 할 점들을 수동으로 연결하기. 추적이 실제로 작동할 때 – 시스템이 어디에 무엇이 있는지 알고 있다고 신뢰할 수 있을 때 – 몇 가지가 변한다.
상태 회의는 짧아지거나 완전히 사라진다. 우리는 일일 스탠드업에서 주 2회 체크인으로 이동했지만, 더 나은 비동기 습관도 그 변화에 기여했을 것이기 때문에 그 모든 것을 도구 덕분이라고 하기는 조심스럽다. 필요할 때 컨텍스트가 나타난다 – 작업을 집어들면 관련 스레드, 문서, 댓글이 이미 연결되어 있어서 관여하기 전에 무슨 일이 있었는지 재구성하는 처음 15분을 보내지 않는다. 그리고 더 적은 것들이 놓쳐진다 – 제로는 아니지만 (어떤 시스템도 그것을 완전히 없앤다고 생각하지 않는다), 극적으로 적어지며, 이것은 도구 사이의 틈에서 작업이 조용히 사라지는 것을 수년간 본 후 작은 기적처럼 느껴진다.
이것의 일부가 피치처럼 읽힌다는 것을 알고, 모든 엣지 케이스에 걸쳐 완전히 제공하는 것이 아니라 아직 이를 향해 구축하고 있다는 것을 솔직히 말하고 싶다. 하지만 방향이 옳다고 느껴지며, 초기 결과는 이를 끝까지 해낼 것에 헌신할 만큼 고무적이었다.
도구 간 틈에서 작업을 잃는 것을 멈추세요. Sugarbug은 Linear, GitHub, Slack, Notion을 하나의 살아있는 지식 그래프로 연결합니다.
Q: Sugarbug은 GitHub, Slack, Notion 및 기타 도구의 작업을 자동으로 추적할 수 있나요? A: 네. Sugarbug은 GitHub, Slack, Notion, Linear, Figma, 이메일, 캘린더에 연결하여 모든 도구에 걸쳐 관련 항목을 연결하는 지식 그래프를 구축합니다. PR이 이슈를 참조하고 누군가 스레드에서 접근 방식을 논의하면, Sugarbug은 이것들이 모두 같은 작업의 일부임을 이해합니다 – 수동 연결이 필요 없습니다.
Q: Sugarbug은 프로젝트 관리 대시보드와 어떻게 다른가요? A: 대시보드는 도구의 데이터를 단일 뷰로 집계하지만 관계를 이해하지 못하는 읽기 전용 스냅샷입니다. Sugarbug은 도구 간에 작업, 사람, 대화를 연결하는 살아있는 지식 그래프를 구축하며, 실행 시간이 길수록 더 스마트해집니다. 어디에 무엇이 있는지 보여줄 뿐만 아니라 놓쳐질 것들을 포착합니다.
Q: 여러 도구에서 작업을 추적하는 것이 정말 그렇게 많은 문제를 일으키나요? A: 우리 경험상, 그렇습니다 – 그리고 보통 팀이 측정하기 시작할 때까지 깨닫는 것보다 더 많이. 개별 도구가 나쁜 것이 아닙니다. 문제는 컨텍스트가 도구 간에 분산되어 전체 그림을 아는 단일 도구가 없다는 것입니다. 행동해야 하는 사람이 다른 곳에서 관련 대화가 있었다는 것을 몰라 작업이 지연됩니다.
Q: 기존 도구와 함께 Sugarbug을 사용할 수 있나요? A: 그것이 바로 핵심입니다. Sugarbug은 기존 워크플로 도구를 대체하는 것이 아니라 연결합니다. 팀이 이미 알고 있는 것을 계속 사용하고, Sugarbug은 모든 것을 연결하는 인텔리전스 레이어를 구축합니다. 마이그레이션 없음, 일상적인 작업을 위한 새로운 UI 학습 없음.
도구 간 틈에서 사라지는 작업으로 시간을 잃고 있는 팀이라면, Sugarbug이 한번 살펴볼 가치가 있을 것입니다.