크로스툴 프로젝트 가시성은 신화다
대시보드가 크로스툴 프로젝트 가시성 약속을 지키지 못하는 이유와, 팀 작업이 Linear, GitHub, Slack, Notion에 분산될 때 실제로 효과적인 것.
By Ellis Keane · 2026-03-17
시장의 모든 프로젝트 관리 도구는 크로스툴 프로젝트 가시성을 약속합니다. 이 약속은 거의 20년 동안 계속됐는데, "대시보드"라는 단어가 "실제로 무슨 일이 일어나고 있는지 아는 것"의 대체어가 된 때부터입니다.
그리고 솔직히, 대시보드는 꽤 좋아졌습니다. 세련되고, 실시간이며, 색상으로 구분됩니다. 스프린트별, 담당자별, 레이블별, 그리고 Jira 운영자가 창의적이었다면 달의 위상별로도 필터링할 수 있습니다. 유일한 문제는 – 사실 사소한 문제로, 언급할 가치도 없지만 – 팀의 누구도 하나의 도구 안에서만 작업하지 않는다는 것입니다.
아무도 이야기하지 않는 가시성 문제
크로스툴 프로젝트 가시성이 의미해야 하는 것: 무언가를 열면 프로젝트 상태를 볼 수 있다. Linear 보드 상태가 아니라, GitHub 리포지토리 상태가 아니라, Slack 채널 요약이 아니라 – 실제 작업의 상태를.
실제로는 이런 일이 일어납니다. 디자이너가 Figma에 엣지 케이스를 지적하는 댓글을 남깁니다. 엔지니어가 그것을 발견하고 (만약 그날 Figma를 확인했다면) GitHub 이슈를 엽니다. 그 이슈가 Slack 스레드에서 논의됩니다. 누군가 스레드에서 원래 Linear 티켓을 참조하지만, GitHub 이슈에는 다시 연결하지 않습니다. 3일 후, 엔지니어링 매니저가 Linear를 열고 티켓이 "진행 중"으로 표시된 것을 봅니다. Figma 댓글, GitHub 이슈, Slack 논의에 대해서는 전혀 모릅니다. Linear의 관점에서는 모든 것이 순조롭게 진행되고 있습니다.
이것은 가시성 문제가 아닙니다. 정보 토폴로지 문제입니다. 데이터는 존재합니다 – 단지 네 개의 도구에 흩어져 있고, 그 사이를 연결하는 조직이 없을 뿐입니다.
대시보드가 크로스툴 프로젝트 가시성에 실패하는 이유
크로스툴 프로젝트 가시성의 표준적인 답변은 "대시보드를 만들어라"입니다. 다양한 API에서 데이터를 가져와 한 곳에 표시하고 끝냅니다.
저도 이런 대시보드를 만들어봤습니다. (사실 한 번 이상 만들었는데, 첫 번째 것이 얼마나 잘 작동했는지 짐작할 수 있을 겁니다.) 문제는 기술적인 것이 아닙니다. API는 존재합니다. 데이터는 접근 가능합니다. 문제는 데이터를 집계하는 것과 컨텍스트를 이해하는 것은 같지 않다는 것입니다.
대시보드는 Linear에 14개의 열린 이슈가 있고 GitHub에 7개의 열린 PR이 있다고 알려줄 수 있습니다. 하지만 그 PR 중 3개가 그 이슈 중 2개와 관련이 있고, 두 이슈 모두 지난 수요일 같은 Slack 스레드에서 논의됐으며, 디자이너가 이미 Figma에서 우려 사항을 지적했는데 이슈나 PR 어디에도 다루어지지 않았다는 것은 알려줄 수 없습니다.
대시보드는 집계합니다. 연결하지 않습니다. 크로스툴 프로젝트 가시성은 항목을 나란히 표시하는 것이 아니라, 항목 간의 관계를 이해하는 것이 필요합니다.
대시보드는 모자이크를 제공합니다. 필요한 것은 지도입니다.
더욱이, 그 대시보드의 업데이트 속도를 높여도 도움이 되지 않습니다. 대응하는 GitHub PR이 세 개의 미해결 댓글과 함께 리뷰 중인 채로 Linear 티켓이 "완료"로 이동하는 것을 실시간으로 볼 수 있습니다. 대시보드는 두 사실을 모두 보여줍니다. 하지만 티켓과 PR이 관련되어 있다는 것을 모르기 때문에, 이 두 사실이 서로 모순된다는 것은 보여주지 않습니다.
"대응하는 GitHub PR이 세 개의 미해결 댓글과 함께 리뷰 중인 채로 Linear 티켓이 '완료'로 이동하는 것을 실시간으로 볼 수 있습니다. 대시보드는 두 사실을 모두 보여주지만 – 이 두 사실이 서로 모순된다는 것을 알지 못합니다." – Chris Calo
연결이 노드보다 더 중요합니다. 도구 간의 관계를 이해하는 시스템은 각 도구를 별도의 우주로 취급하는 실시간 대시보드보다 더 나은 크로스툴 프로젝트 가시성을 제공합니다.
실제로 효과적인 것
그렇다면 대시보드가 크로스툴 프로젝트 가시성의 답이 아니라면, 무엇이 답일까요?
간단한 방법이 있으면 좋겠습니다 – 모든 것을 해결하는 명명 규칙이나 레이블 분류 체계가 있다면. 하지만 없습니다. 저는 이전 직장에서 약 6개월 동안 명명 규칙 접근법을 시도했는데, 말할 수 있는 것은 "PROJ-123"이 누군가 커밋 메시지에 포함하는 것을 잊을 때까지는 완벽하게 작동한다는 것입니다. 그것은 1~2주 안에 전체 시스템이 조용히 무너질 만큼 자주 일어납니다.
실제로 효과적인 것은 도구 전반에 걸쳐 스스로 연결을 해결하는 시스템입니다. 계속 정보를 입력해야 하는 시스템이 아니라 (일관되게 하는 사람은 없습니다 – 아무도 안 합니다), 기존 도구에서 읽어 관계를 스스로 추론하는 시스템입니다. 작동 원리는 마법이 아닙니다: webhook 이벤트와 API 폴링 데이터를 수집하고, 도구 전반에 걸쳐 식별자를 정규화하며 (Slack 스레드에서 언급된 Linear 이슈 ID, 티켓 키와 일치하는 GitHub 브랜치 이름, Notion 문서에 붙여넣은 Figma 파일 URL), 무엇이 무엇에 연결되어 있는지 그래프를 구축합니다. 어려운 부분은 개별 링크가 아니라 – 인간에게 기록 관리를 요청하지 않고 이 모든 것을 지속적으로 유지하는 것입니다.
훌륭한 엔지니어링 매니저가 어떻게 컨텍스트를 구축하는지 생각해보십시오. Linear와 GitHub를 나란히 열어 놓고 이슈 번호를 수동으로 상호 참조하지 않습니다. Slack 채널을 읽고, 누가 무엇에 대해 이야기하는지 알아차리고, 지난주 Figma 논의가 방금 머지된 PR과 연결된다는 것을 기억하고, 멘탈 모델을 구축합니다. 가시성은 연결을 이해하는 데서 옵니다. 더 많은 화면을 응시하는 데서가 아니라.
문제는 이 멘탈 모델이 확장되지 않는다는 것입니다. 한 사람의 머릿속에 존재합니다. 그 사람이 휴가를 가면 가시성도 함께 사라집니다.
이를 위한 도구를 채택할 준비가 되지 않은 경우 (솔직히, 대부분의 팀은 아직 준비되지 않았습니다), 오늘부터 할 수 있는 일들이 있습니다. 프로젝트당 한 명을 "컨텍스트 키퍼"로 지정하여 주간 요약에서 명시적으로 도구를 상호 참조하게 합니다. 링크 규칙에 합의합니다: 모든 PR 설명에 Linear 티켓 URL을 포함하고, 모든 Slack 결정을 관련 Notion 문서에 붙여넣습니다. 활성 프로젝트의 Figma 댓글을 검토하는 Slack 리마인더를 설정합니다. 이것들 중 어느 것도 좋지 않습니다 – 모두 수동이고, 모두 인간이 기억하는 것에 의존합니다 – 하지만 대시보드가 전체 그림을 제공하는 척하는 것보다는 낫습니다.
지식 그래프 접근법
이것이 작업 도구를 대시보드의 데이터 소스가 아닌 그래프의 노드로 취급하는 아이디어의 배경입니다. 잘 들어보세요 – 학문적으로 들리지만 실제로는 그렇지 않습니다.
세 명의 엔지니어가 접근법에 대해 논쟁한 Slack 스레드. 디자이너가 제약을 지적한 Figma 댓글. 기능을 추적하는 Linear 티켓. 그것을 구현하는 GitHub PR. 원래 스펙이 담긴 Notion 문서. 이것들은 다섯 개의 별개의 것이 아닙니다 – 같은 작업에 대한 다섯 가지 관점입니다.
그래프로 모델링하면, "모든 도구를 한 곳에서 볼 수 있나요?"라는 질문이 "이 작업 주변의 모든 컨텍스트를 볼 수 있나요?"로 바뀝니다. 이것은 근본적으로 다른 질문이며, 프로젝트가 제대로 진행되고 있는지 파악하려 할 때 실제로 중요한 질문입니다.
그래프는 정보가 어느 도구에 있는지 신경 쓰지 않습니다. 그것이 무엇을 의미하고 다른 모든 것과 어떻게 연결되는지에 관심이 있습니다. Figma 댓글이 같은 엣지 케이스를 참조하는 GitHub PR의 댓글 – 그것들은 두 곳에서 일어나는 같은 대화입니다. 도구 전반에 걸쳐 가시성을 제공한다고 주장하는 시스템은 그것을 알아야 합니다.
실제로는 어떻게 보이는가
구체적인 예를 들어보겠습니다. 추상적인 이야기는 충분히 들었지만, 화요일 오후에 이것이 실제로 무엇을 의미하는지 궁금할 것입니다.
팀이 새로운 온보딩 플로우를 구축하고 있다고 가정합시다. 디자이너는 일주일 동안 Figma에서 반복 작업을 하고 있습니다. 엔지니어는 Linear 티켓을 열고, 세 개의 하위 작업으로 나누고, 첫 번째 작업을 시작했으며 – GitHub에 PR이 올라와 있습니다. 한편, PM은 2주 전 Notion에 스펙을 작성하여 세 가지 요구 사항을 개요화했는데, 그 중 하나는 엔지니어도 디자이너도 보지 못한 Slack 대화에서 우선순위가 낮아졌습니다.
대시보드를 엽니다. 보이는 것: Figma에 활동이 있습니다. Linear에 세 개의 하위 작업, 하나 진행 중. GitHub에 열린 PR이 있습니다. Notion에 스펙이 있습니다. Slack에는... Slack에는 모든 것이 있어서 도움이 안 됩니다. 모든 것이 순조로워 보입니다. 출시할까요?
하지만 엔지니어는 이틀 전 Slack 스레드에서 조용히 우선순위가 낮아진 요구 사항을 기반으로 구축하고 있습니다. 아무도 엔지니어에게 말하지 않았습니다. 디자이너에게도 말하지 않았습니다. Notion 스펙에는 여전히 그것이 나열되어 있습니다. 대시보드는 이 아티팩트들이 연결되어 있다는 것을 알지 못하기 때문에 모순을 표시할 수 없습니다 – 각 도구의 상태를 독립적으로 알 뿐입니다.
이제 같은 상황에서, 작업을 추적하는 시스템이 Notion 스펙, Linear 하위 작업들, GitHub PR, Figma 이터레이션, 그리고 그 Slack 스레드가 모두 같은 온보딩 플로우의 일부임을 이해하고 있다고 상상해보십시오. 그 사이의 참조와 언급을 추적해왔습니다. 충돌을 표면화할 수 있습니다: "이 하위 작업의 기본 요구 사항이 우선순위가 낮아졌습니다 – 머지 전에 확인하는 것이 좋을 수 있습니다." 이것은 대시보드 데이터가 아닙니다. 프로젝트가 제대로 진행되고 있는지에 대한 실제 가시성입니다.
이것이 필요 없을 때
솔직한 이야기입니다 (이것은 진심이며, 영업 멘트를 위한 준비가 아닙니다). 팀이 5명이고 두 개의 도구를 사용한다면, 크로스툴 프로젝트 가시성 소프트웨어가 필요 없습니다. Slack 채널과 주간 동기화가 필요합니다. 그 규모에서는 멘탈 모델이 충분히 확장됩니다. 모두가 문자 그대로 또는 비유적으로 같은 방에 앉아 있기 때문에, 모두가 서로 무엇을 하고 있는지 알고 있습니다.
문제는 한 사람이 전체 그림을 유지할 수 없을 만큼 팀이 성장했을 때 시작됩니다. 제 경험으로는, 그것은 세 번째 또는 네 번째 도구 채택 즈음으로, 작업 스트림이 겹치기 시작하고 월요일 아침 스탠드업의 절반이 "잠깐, 그걸 몰랐어"가 될 때입니다.
그 임계값을 넘어섰다면 – 팀이 서로의 작업에 대한 인식이 채택한 도구 수에 반비례한다는 것을 알아차렸다면 – 실제로 점들을 연결하는 무언가가 필요합니다.
---
Sugarbug는 작업 도구 전반 – Linear, GitHub, Slack, Figma, Notion 등 – 에 걸쳐 지식 그래프를 구축하므로, 크로스툴 프로젝트 가시성은 구축하는 것이 아니라 존재하는 것이 됩니다. 대기 목록에 참여하기
---
크로스툴 프로젝트 가시성을 위해 직접 구축하고 유지해야 하는 대시보드가 필요하지 않아야 합니다. Sugarbug가 지식 그래프를 구축하므로 자동으로 전체 그림을 볼 수 있습니다.
Q: Sugarbug은 크로스툴 프로젝트 가시성을 제공합니까? A: 네. Sugarbug는 API를 통해 Linear, GitHub, Slack, Figma, Notion 및 기타 도구에 연결한 후, 모든 도구에서 작업, 대화, 사람을 연결하는 지식 그래프를 구축합니다. 각 도구의 데이터를 개별적으로 표시하는 대시보드 대신, Sugarbug는 항목 간의 관계를 이해합니다 – Slack 토론, GitHub PR, 동일한 기능에 관한 Linear 티켓은 모두 연결됩니다.
Q: Sugarbug는 수동 태그 없이 Linear와 GitHub 간의 작업을 추적할 수 있습니까? A: Sugarbug는 Linear와 GitHub 모두에서 시그널을 지속적으로 수집합니다. GitHub PR이 Linear 이슈를 참조하거나, 누군가 Slack 스레드에서 Linear 작업을 논의하면, Sugarbug는 지식 그래프에서 해당 항목들을 자동으로 연결합니다. 수동 태그 없이, 명명 규칙 없이, "커밋 메시지에 프로젝트 코드를 추가하세요" Slack 메시지도 없이.
Q: 기존 도구를 교체하지 않고 프로젝트 가시성을 확보할 수 있습니까? A: 물론입니다. Sugarbug는 기존 스택 옆에서 작동합니다. Linear, GitHub, Slack, Notion을 교체하는 것이 아니라 이들로부터 읽어 통합 뷰를 구축합니다. 팀은 이미 알고 좋아하는 도구를 계속 사용할 수 있습니다. Sugarbug는 그 사이의 연결을 가시화할 뿐입니다.
Q: 프로젝트 가시성에서 대시보드와 지식 그래프의 차이는 무엇입니까? A: 대시보드는 여러 소스의 데이터를 단일 화면에 집계하지만, 각 데이터 포인트는 여전히 고립되어 있습니다 – Linear 이슈는 GitHub PR 옆에 표시된 Linear 이슈일 뿐입니다. 지식 그래프는 도구 전반에 걸쳐 항목을 연결하여 Slack 스레드, GitHub PR, Linear 이슈가 모두 같은 작업의 일부임을 이해합니다. 그래프는 컨텍스트를 제공하고, 대시보드는 데이터를 제공합니다.