업무 도구를 위한 지식 그래프는 실제로 어떤 모습인가
업무 도구를 위한 지식 그래프는 구글의 팩트 박스가 아닙니다. Linear, Slack, Figma와 스타트업 툴 스택을 연결했을 때 실제 모습을 설명합니다.
By Ellis Keane · 2026-03-14
1876년, 멜빌 듀이는 익숙하게 들릴 문제를 안고 있었습니다. 도서관은 책으로 넘쳐났고, 각 기관은 자체적인 분류 체계를 갖고 있었습니다 – 아니, 더 흔하게는 아무 체계도 없었습니다. 관련된 세 권의 책에 걸쳐 사상의 흐름을 추적하려는 이용자는 그 책들이 존재한다는 것을 미리 알고, 각 책이 어디 있는지 알고, 서가 사이를 걸어 다닐 여유로운 오후를 확보해야 했습니다. 듀이의 십진분류법이 훌륭했던 것은 책을 정렬했기 때문이 아닙니다 (그것은 수백 년 동안 해온 일입니다). 주제 간의 관계를 인코딩했기 때문입니다 – 열역학, 야금학, 증기 공학이 서로 다른 층에 책이 있어도 연결되어 있다는 생각입니다.
150년 후, 우리는 어떻게 된 일인지 듀이 이전의 무질서한 도서관을 다시 만들어버렸습니다. 다만 서가는 SaaS 제품이고, 책은 Slack 메시지입니다. 업무 도구를 위한 지식 그래프는, 그 핵심에서, 듀이가 해결한 것과 동일한 문제를 해결하려는 시도입니다 – 관계의 인코딩 – 단, 현대 팀 협업의 혼란스럽고 파편화된 상황에 적용하는 것입니다. 발전이라고 할 수 있겠죠.
"지식 그래프"라는 용어는 "AI 기반"이나 "블록체인 활용"만큼 무분별한 자신감으로 사용됩니다 – 즉, 사용하는 거의 모든 사람이 서로 다른 의미로 씁니다. Google에도 있습니다 (룩셈부르크의 수도를 검색하면 알려주는 박스입니다). Neo4j에도 있습니다. 여러분 회사의 Notion 위키는 결코 그것이 아닙니다 – 그것을 판 컨설턴트가 무슨 말을 했든 상관없이. 그리고 이 모든 카테고리 혼란 속에서, 실제로 유용한 아이디어가 계속 사라지고 있습니다: 업무 도구를 위한 지식 그래프. Figma, Slack, Linear, GitHub 등의 도구 전반에서 팀이 하는 일의 관계를 매핑하는 살아있는 그래프입니다.
안개를 걷어내 보겠습니다.
"지식 그래프"가 실제로 의미하는 것 (그리고 의미하지 않는 것)
여기서 카테고리 혼란이 정말 물어뜯습니다. "지식 그래프"라고 하면 대부분의 사람들은 Google의 지식 패널을 떠올립니다 – 버락 오바마가 188cm이고 호놀룰루 출생이라고 알려주는 깔끔한 사이드바입니다. 그것은 정적인 사실의 웹입니다. 더 나은 타이포그래피를 가진 브리태니커 백과사전입니다. 물론 유용하지만, 업무 도구를 위한 지식 그래프가 하는 일과는 거의 관계가 없습니다.
신화는 이렇습니다: 지식 그래프는 사실의 큰 데이터베이스로, 아마도 멋진 시각화를 갖추고, 누군가 (또는 무언가)가 조직에 관한 모든 중요한 정보를 꼼꼼하게 입력한 것입니다. 기본적으로는 위키이지만, 페이지와 링크 대신 원과 선이 있는 것입니다.
메커니즘은 다릅니다. 직장 지식 그래프는 사실을 저장하지 않습니다 – 시그널 간의 관계를 저장합니다. 모든 Slack 스레드, 모든 Figma 댓글, 모든 Linear 상태 변경, 모든 병합된 PR은 시그널입니다. 그래프의 전체 역할은 이 시그널들이 어떻게 연결되는지 기억하는 것입니다: 이 대화가 저 결정에 영향을 미쳤고, 그 티켓을 만들었으며, 그것이 저 풀 리퀘스트에서 구현되었고, 3주 전 디자인 크리틱에서 최초 우려를 제기한 바로 그 사람이 리뷰했습니다.
시그널이 노드입니다. 연결이 엣지입니다. 그리고 엣지가 전부입니다 – 그것 없이는 그냥 검색 인덱스에 불과합니다.
"엣지가 이것을 데이터베이스가 아닌 그래프로 만드는 것입니다. 그것 없이는 개별 메시지를 찾을 수 있지만, 그 메시지가 속했던 결정이나 그것을 형성한 다른 여섯 개의 대화는 찾을 수 없습니다." – Chris Calo
(이미 검색 인덱스는 있습니다. Slack 검색이라고 합니다. 왜 그것으로는 충분하지 않은지는 나중에 설명하겠습니다.)
Notion 위키의 대형 묘지
메커니즘을 더 깊이 파고들기 전에, 잠시 사망한 것들에 경의를 표하겠습니다.
내가 함께 일해온 모든 스타트업 – 하나도 빠짐없이 – 은 Notion 위키를 갖고 있었습니다. 그리고 모두 똑같은 생명 주기를 따랐습니다: 누군가 (보통 팀에서 가장 정돈된 사람, 그 마음은 이해합니다)가 주말에 설정합니다. 멋집니다. 약 3주 동안 사람들이 실제로 사용합니다.
그러다 현실이 시작됩니다. 위키는 정보가 자연스럽게 존재하는 곳 – Slack 대화, Figma 댓글, Linear 티켓 – 에서 위키가 있어야 한다고 말하는 곳으로, 누군가가 물리적으로 정보를 옮겨야 합니다. 그것은 팀이 생성하는 모든 컨텍스트에 대한 수동 복사-붙여넣기 세금입니다. 그리고 말씀드리건대, 아무도 그 세금을 일관되게 납부하지 않습니다. 그것을 만든 정돈된 사람조차도, 왜냐하면 이제 그들은 실제 일을 하기에 너무 바빠서 실제 일을 하기 위해 세운 기념비를 유지할 수 없기 때문입니다.
6개월 후: 페이지의 절반은 낡았고, 4분의 1은 모순되며, 나머지는 누군가가 "일이 진정되면" 분명히 채울 예정이었던 빈 템플릿입니다. (일은 절대 진정되지 않습니다. 그것이 또 다른 신화입니다.)
지식 관리 업계는 20년 동안 같은 깨진 약속을 팔아왔습니다: 모든 것을 문서화하면 컨텍스트를 잃지 않을 것이라고. 훌륭한 이론입니다. 매번 같은 암초에 난파됩니다 – 인간은 실시간으로 문서화하지 않고, 그렇게 할 무렵에는 컨텍스트가 이미 사라지거나, 왜곡되거나, 아무도 더 이상 찾을 수 없는 Slack 메시지로 대체되어 있습니다.
업무 도구를 위한 지식 그래프가 실제로 저장하는 것
자, 메커니즘으로 돌아갑시다. 업무 지식 그래프는 두 가지를 저장합니다: 노드와 엣지.
노드 (사물)
- 태스크 – Linear 이슈, GitHub 이슈, Jira 티켓. 상태와 소유자가 있는 모든 것.
- 대화 – Slack 스레드, Figma 댓글 스레드, 이메일 체인. 개별 메시지가 아닌 의미의 단위로서의 스레드 토론.
- 사람 – 팀, 외부 연락처, 이해관계자. 각 사람은 인터랙션에서 그래프가 시간이 지남에 따라 구축하는 프로필을 가집니다. (채워 넣고 잊어버리는 프로필이 아닌. 실제 살아있는 프로필.)
- 결정 – 팀이 경로 B 대신 경로 A를 선택한 순간들. 이것들은 거의 항상 암묵적이며, 3명이 보고 11명이 봐야 했던 Slack 답글에 묻혀 있고, 어떤 결정 로그에도 명시되어 있지 않습니다. 좋은 지식 그래프는 어쨌든 그것들을 표면화합니다.
- 산출물 – PR, 디자인 파일, 문서, 미팅 녹화. 팀이 생산하는 것들.
엣지 (관계)
그래프는 노드가 어떻게 연결되는지도 저장합니다:
- 이 Slack 스레드는 이 Linear 이슈에 정보를 제공했다
- 이 사람은 이 결정에 참여했다
- 이 PR은 이 태스크를 구현했다
- 이 Figma 댓글은 이 디자인 리뷰를 차단했다
- 이 미팅은 이 세 가지 액션 아이템을 생성했다
엣지가 이것을 데이터베이스가 아닌 그래프로 만드는 것입니다. 그것 없이는 개별 메시지를 찾을 수는 있지만 – 그 메시지가 속했던 결정이나 그것을 형성한 다른 여섯 개의 대화는 찾을 수 없습니다.
아무도 문서화하지 않고도 시그널이 지식이 되는 방법
여기서 신화와 메커니즘이 가장 날카롭게 갈라집니다. 신화는 말합니다: 지식 베이스를 구축하고 유지하세요. 메커니즘은 말합니다: 이미 일어나고 있는 것을 관찰하고 자동으로 매핑하세요.
수동으로 유지해야 하는 지식 그래프는 다른 이름의 위키입니다. 3주 만에 끝납니다. (위의 묘지 참조.)
따라서 그래프는 자동이어야 합니다. 대략 이런 방식으로 작동합니다 – 단순화하고 있지만 뼈대는 맞습니다:
1. 시그널이 들어옵니다. 연결된 도구의 모든 웹훅, 폴링, 스크래핑은 시그널을 생성합니다 – Slack 메시지, Linear 상태 변경, Figma 댓글. 5~6개의 도구를 사용하는 10명 팀은 하루에 수백 개의 시그널을 생성합니다. 대부분의 사람들은 팀이 얼마나 많은 주변 컨텍스트를 생성하는지 깨닫지 못합니다. 필요할 때 찾을 수 없다는 것만 알 뿐입니다.
2. 시그널이 분류됩니다. 이것은 새로운 태스크입니까? 기존 태스크의 업데이트? 결정이 이루어지고 있습니까? 배경 소음? 분류는 가능한 한 프로그래밍 방식으로 이루어집니다 – Linear 이슈 번호를 참조하는 GitHub PR은 명확합니다. 더 모호한 시그널 (프로젝트에 관한 Slack 메시지일 수도 있고, 바나나 브레드 레시피를 공유하는 것일 수도 있는)에 대해서는 시스템이 엔티티 추출과 벡터 임베딩 유사도를 사용해 기존 그래프 노드와 매칭합니다. Slack 메시지의 임베딩이 기존 태스크 클러스터에 충분히 가까우면, 링크가 그래프의 엣지로 생성됩니다 – 공식 용어로는 프로퍼티 그래프 – 신뢰도 점수가 첨부됩니다. 임계값 이하? 컨텍스트로 저장됩니다. 어울리지 않는 연결에 강제로 넣지 않습니다.
3. 시그널이 연결됩니다. 분류된 시그널은 기존 노드에 연결됩니다. 누군가 Slack 스레드에서 Linear 이슈를 언급하면, 그 둘은 이제 연결됩니다. Figma 디자인에 댓글을 달았던 사람이 그것을 구현하는 PR도 열었다면, 그 연결은 자동으로 형성됩니다. 아무도 문서화할 필요가 없었습니다. 아무도 위키를 업데이트할 필요가 없었습니다. (이것이 Sugarbug로 우리가 구축하고 있는 것의 핵심입니다 – 팀이 그냥 작업하는 동안 링크는 백그라운드에서 이루어집니다.)
4. 그래프는 시간이 지남에 따라 더 똑똑해집니다. 크로스 도구 참조가 축적됨에 따라, 그래프는 팀이 실제로 어떻게 작동하는지에 대한 더 풍부한 그림을 구축합니다 – 누가 누구와 협업하는지, 어떤 도구가 어떤 종류의 결정을 담는지, 그리고 컨텍스트가 확실히 사라지는 곳. (우리 경험상, 그것은 거의 항상 디자인과 엔지니어링 사이의 인계 시점입니다. 매번. 이제쯤 해결됐어야 할 것 같은데.)
Slack 검색, Zapier, 대시보드가 이것이 아닌 이유
"하지만 ~로는 안 되나요?" 무리에 간단히 답하겠습니다. (나도 몇 년 동안 그 무리에 있었습니다. 모든 것을 시도해봤습니다.)
Slack 검색은 진정으로 과소평가되어 있습니다. 하지만 "검색 가능"과 "찾을 수 있음"은 근본적으로 다릅니다. Slack 검색은 무엇을 찾는지, 대략 언제 일어났는지 알 때 작동합니다. 한 주 동안 여러 채널에 걸쳐 이루어진 결정을 재구성하려 할 때 무너집니다. 특정 메시지가 아닌 대화 간의 관계를 찾고 있는데, Slack에는 그 모델이 없습니다.
Zapier와 Make는 기본적인 연결을 배선할 수 있습니다 – "Linear 이슈가 Done으로 이동하면 Slack에 게시" – 하지만 그것은 배관이지 이해가 아닙니다. Zapier는 무언가가 일어났다는 것을 압니다. 왜인지, 또는 그것이 앞선 것과 어떻게 연결되는지에 대한 개념이 없습니다. (이것이 워크플로 자동화 도구의 근본적인 비극입니다: 그것을 가장 필요로 하는 사람들이 구성할 시간이 가장 없습니다.)
대시보드는 말합니다: 열린 이슈: 47, 이번 주 병합된 PR: 12. 처리량 측정에는 유용합니다. 인과관계에는 쓸모없습니다. 대시보드는 "PR 1개 병합됨"이라고 말합니다. 그래프는 왜를 알려줍니다 – Figma 리뷰가 버그를 발견했고, 그것은 아무도 보지 않은 Slack 스레드에서 원래 보고되었습니다. 내러티브 없는 숫자는 장식입니다.
이것이 실제로 가능하게 하는 것
업무 도구를 위한 지식 그래프는 유지 관리하는 위키가 아닙니다 – 팀이 일하면서 형성되는 관계의 자동 지도입니다. 가치는 정보를 저장하는 데 있는 것이 아니라, 개별 도구가 볼 수 없는 시그널 간의 연결을 인코딩하는 데 있습니다.
연결된 시그널이 있으면 – 실제로는 수집 시작 후 며칠 내에 유용한 연결이 보이기 시작합니다, 몇 달이 아니라 – 이 개별 도구 중 어느 것도 지원하지 않는 것들을 할 수 있습니다:
메시지만이 아닌 결정을 찾습니다. 기능에 대한 Linear 이슈를 꺼내고, 그것과 관련된 모든 대화와 결정을 보고, 접근 방식이 처음 논의된 Figma 댓글까지 스레드를 추적합니다. 이전에는 세 명의 동료와 커밋 로그를 심문해야 했던 것이 연결된 노드의 간단한 탐색이 됩니다.
고고학 없이 미팅을 준비합니다. 엔지니어와의 일대일 미팅 전에, 그래프는 관련된 모든 것을 표면화할 수 있습니다 – 그들이 출시한 것, 막혀있는 것, 참여했던 대화, 아직 미결인 결정들. 속도 지표 대시보드 (그것은 모든 관련자에게 우울합니다)가 아니라, 실제로 무슨 일이 있었는지의 내러티브. 네 가지 다른 도구에서 컨텍스트를 끌어오는 데 30분을 쓰는 것과 앉을 때 준비가 되어 있는 것의 차이.
놓친 컨텍스트가 놓친 작업이 되기 전에 발견합니다. 3일 전 Figma 리뷰 요청에 응답이 없습니까? 그래프가 잡아냅니다. Linear 이슈가 1주일 전 "진행 중"으로 이동했는데 그 이후 커밋이 없습니까? 플래그가 달립니다. 이것들은 정교한 자동화가 아닙니다 – 연결된 데이터에 대한 패턴 인식이며, 그래프가 어떤 시그널이 어떤 태스크와 관련되는지 알기 때문에만 작동합니다.
인간 접착제가 되기를 멈춥니다. 이것이 저를 움직입니다. 대부분의 스타트업에는 팀의 결합 조직으로 기능하는 사람이 있습니다 (종종 창업자, 때로는 비정상적으로 부지런한 PM) – #design-feedback의 대화가 백로그의 티켓과 관련 있고, 그것이 지난 주 스탠드업에서 나온 것에 의해 차단되어 있었다는 것을 기억하는 사람. 그 사람은 하루 종일 머릿속에서 수동으로 지식 그래프의 역할을 하고 있습니다. 지치고, 확장되지 않으며, 휴가를 가면 팀 전체가 10 IQ 포인트를 잃습니다. 그래프는 휴가가 필요하지 않은 것으로 그 인간 라우팅 레이어를 대체합니다.
이것이 우리가 Sugarbug를 또 다른 대시보드가 아닌 지식 레이어로 구축한 이유입니다 – 도구에서 숫자를 집계하는 것이 아니라, 그것들을 통해 흐르는 시그널 간의 관계를 매핑합니다. 각 새로운 연결이 기존 연결을 더 의미 있게 만듭니다. 듀이도 승인했을 것입니다. (아마도. 다른 견해들은 잘 늙지 않았지만, 분류 부분은 확실했습니다.)
한 사람이 도구 간의 연결을 머릿속에 유지하는 것에 의존하기를 멈추세요. Sugarbug가 자동으로 관계를 매핑합니다.
Q: 누군가 Slack 메시지를 삭제하거나 Figma 댓글을 해결하면 그래프는 어떻게 됩니까? A: 시그널이 수집되어 연결되면, 원본 메시지가 삭제되거나 댓글이 해결되어도 그래프는 관계를 유지합니다. Slack이나 Figma에서 원본 콘텐츠가 사라져도, 엣지 –"이 대화가 이 결정에 정보를 제공했다"– 는 남습니다. 그것이 요점입니다: 그래프는 개별 도구가 폐기하는 컨텍스트를 보존합니다.
Q: Sugarbug의 지식 그래프는 비공개 채널과 DM을 처리합니까? A: 명시적으로 연결한 데이터 소스만 수집됩니다. 비공개 Slack 채널을 연결하면, 그 시그널은 그래프에 들어가고 Sugarbug 워크스페이스에 접근 권한이 있는 모든 사람이 볼 수 있습니다. 특정 채널을 구성하지 않는 한 DM은 스크래핑되지 않습니다. 데이터는 팀의 환경 내에 유지됩니다 – Sugarbug는 조직 간에 시그널을 공유하지 않습니다.
Q: 그래프는 주제와 무관한 Slack 잡담 같은 노이즈 시그널을 어떻게 처리합니까? A: 분류는 신뢰도 임계값을 사용합니다. 임계값을 초과해 기존 그래프 노드와 일치하는 시그널은 연결되고, 그 이하의 시그널은 연결에 강제되지 않고 연결되지 않은 컨텍스트로 저장됩니다. 시간이 지남에 따라 그래프가 더 많은 참조 포인트를 축적할수록, 분류기는 프로젝트 관련 토론과 일반 잡담을 더 잘 구별하게 됩니다. 우리 경험상, 첫 1~2주 후에 노이즈 대 시그널 비율이 눈에 띄게 떨어집니다.
Q: 지식 그래프를 직접 쿼리할 수 있습니까, 아니면 백그라운드에서만 사용됩니까? A: Sugarbug는 태스크 뷰와 미팅 준비 화면을 통해 그래프를 노출합니다 – 쿼리를 작성하지 않고도 연결된 컨텍스트를 볼 수 있습니다. 하지만 기반 데이터는 Sugarbug의 MCP 서버를 통해서도 접근할 수 있어, 더 깊이 파고들고 싶다면 맞춤 통합을 구축하거나 다른 도구에서 사용할 수 있습니다.
Q: 새 시그널이 그래프에 나타나는 데 얼마나 걸립니까? A: 웹훅 기반 소스 (GitHub, Linear 등)는 몇 초 내에 나타납니다. 폴링 소스 (Figma, Notion 등)는 스크래핑 간격에 따라 다릅니다 – 일반적으로 소스에 따라 30분에서 2시간마다. 실제로는 태스크를 확인하기 위해 앉을 무렵에는 관련 시그널이 이미 연결되어 있습니다.