엔지니어링과 프로덕트 사이의 데이터 사일로
PM과 엔지니어는 서로 다른 도구, 언어, 타임라인으로 작업합니다. 사일로가 어떻게 형성되는지, 무엇이 진짜 해결책인지 살펴봅니다.
By Ellis Keane · 2026-03-16
어느 순간부터 "프로덕트-엔지니어링 정렬"은 그냥 이루어지는 것이 아니라 직함이 되어 버렸습니다. 같은 Slack 워크스페이스를 쓰고, 같은 스탠드업에 참석하고, 이론상 같은 목표를 향해 일하는 두 스마트한 그룹이 서로가 무엇을 하는지 실제로 이해할 수 있도록, 오직 그 목적만을 위해 전담 인력을 고용하는 회사가 늘고 있습니다. 이런 상황을 만드는 엔지니어링과 프로덕트 사이의 데이터 사일로는 사람의 문제가 아닙니다. 도구의 문제입니다.
PM과 엔지니어는 충분히 소통하고 있습니다. 문제는 완전히 다른 시스템에서 작업한다는 것이고, 그 시스템들 사이에 형성되는 사일로는 구조적입니다 – 현대 팀이 도구를 선택하는 방식의 아키텍처에 내재되어 있습니다. "더 자주 정렬하자"는 말은 도구 자체가 서로를 인식하지 못한다는 문제를 전혀 해결하지 못합니다.
두 가지 현실
여기서는 Sugarbug를 구축해 온 저희 자신의 경험을 이야기하겠습니다. 매일 이것을 체험하고 있기 때문에 추상적인 버전보다 구체적인 이야기가 더 유용하다고 생각합니다.
PM 쪽(저희의 경우 주로 저)은 Notion을 중심으로 생활합니다. 스펙이 그곳에 작성되고, 우선순위가 추적되고, 고객 대화가 기록되고, 기능 요청이 매주 늘어나는 목록에 정리됩니다. Notion은 "왜"가 사는 곳입니다 – 왜 무언가를 만드는지, 고객이 실제로 무슨 말을 했는지, 특정 결정 뒤에 있는 전략적 맥락. 지저분하고 방대하며, 코드 한 줄이 작성되기 전에 가장 중요한 사고가 일어나는 곳입니다.
반면 엔지니어들은 Linear와 GitHub에서 생활합니다. Linear에는 태스크, 스프린트 사이클, 의존성 체인과 블로킹 이슈가 있습니다. GitHub에는 코드, 풀 리퀘스트, 구현 세부 사항에 대해 (바라건대) 건설적으로 논쟁하는 리뷰 스레드가 있습니다. 거기에 "어떻게"와 "언제"가 삽니다 – 무언가가 어떻게 만들어지고, 언제 출시되며, 무엇이 방해가 되는지.
두 현실 모두 정확하고, 둘 다 필수적이며, 완전히 서로에게서 단절되어 있습니다. 그 사이의 간격이 요건이 낡아가고 재작업이 쌓이는 곳입니다.
엔지니어링과 프로덕트 사이의 데이터 사일로가 실제로 형성되는 방식
이것이 의도적인 선택이라고 생각하기 쉽습니다 – 누군가가 정보를 분리해 두기로 결정했다고. 실제로는 아무도 해롭게 의도하지 않은 완전히 합리적인 행동을 통해 사일로가 형성됩니다.
PM이 Notion에 스펙을 작성하고, 엔지니어링 채널에 Slack 링크를 공유하며, 핸드오프가 완료되었다고 생각합니다. 엔지니어는 스펙을 읽고, 그로부터 세 개의 Linear 이슈를 만들고 작업을 시작합니다. 여기까지는 모든 것이 잘 작동하고 있습니다.
그런데 스펙이 바뀝니다 – 고객 대화가 우선순위를 바꾸거나 비즈니스 맥락이 변합니다. PM은 Notion 문서를 업데이트하고 Slack에 변경에 대한 메모를 남깁니다. 코딩 세션에 집중하고 있는 엔지니어는 몇 시간 동안 Slack 메시지를 보지 못합니다. 그 시점에 이미 세 기능 중 두 개를 구식 스펙 기준으로 만들어 버렸고, Linear의 세 번째 이슈는 더 이상 존재하지 않는 요건을 여전히 참조하고 있습니다.
여기서 누구도 부주의하지 않았습니다. 누구도 "소통에 실패"하지 않았습니다. 정보는 한 시스템에 있었고 작업은 다른 시스템에서 이루어졌으며, 둘을 연결하는 조직은 적절한 사람이 보기 전에 다른 스레드에 묻혀 버린 Slack 메시지였습니다.
이런 일이 모든 스펙, 모든 스프린트, 모든 분기에 걸쳐 반복되며 격차가 쌓입니다. 프로덕트가 일어나고 있다고 생각하는 것과 엔지니어링이 실제로 만들고 있는 것 사이의 간격은, 누군가가 적시에 메시지를 알아채는 것에 의존하는 모든 핸드오프마다 벌어집니다.
"더 나은 커뮤니케이션"이 해결책이 되지 않는 이유
액션 아이템이 "변경 사항을 더 선제적으로 소통하라"인 회고에 참석한 적이 있습니다. 애정을 담아 말씀드리자면, 그것은 조직 차원에서 누군가에게 "그냥 더 정리정돈을 잘 하라"고 말하는 것과 같습니다. 실행 가능하게 들리고, Confluence 페이지를 생산적으로 보이게 하며, 문제를 일으킨 시스템에 대해서는 아무것도 바꾸지 않습니다. 저희는 같은 회고 액션 아이템을 세 번 실행했습니다 – 확인했습니다.
커뮤니케이션을 개선해도 엔지니어링과 프로덕트 사이의 데이터 사일로가 해결되지 않는 이유는, 커뮤니케이션은 이미 일어나고 있기 때문입니다 – 데이터는 존재하고, 결정은 이루어지고 기록됩니다. 다만 서로를 인식하지 못하는 도구에 기록될 뿐입니다.
Notion은 스펙이 세 개의 Linear 이슈로 분해되었다는 것을 모릅니다. Linear는 이슈 뒤에 있는 요건이 두 시간 전에 Notion에서 바뀌었다는 것을 모릅니다. GitHub는 검토 중인 PR이 PM의 Notion 보드에서 우선순위가 낮아진 기능을 구현하고 있다는 것을 전혀 모릅니다. 각 도구는 설계된 대로 정확히 기능하고 있습니다 – 다만 함께 기능하도록 설계되지 않았을 뿐입니다.
"월요일 아침을 주말 동안 돈을 내고 쓰는 도구들이 조용히 현실과 괴리되지 않았는지 확인하는 데 보낸다는 것에는 일종의 어두운 코미디가 있다." – Ellis Keane
그래서 일어나는 일은, PM이 스펙이 바뀔 때마다 Notion에서 Linear로 변경 사항을 수동으로 미러링하고, 엔지니어는 Slack에서 PM에게 "이게 아직도 계획인가요?"라고 묻고, 리드는 월요일 아침에 보드를 교차 참조하며 격차를 확인합니다. 저희는 이론상 이미 서로를 알고 있어야 할 도구들 사이의 수동 데이터 동기화에 해당하는 일에 주당 몇 시간을 소비하는 것을 목격해 왔습니다.
시스템 수정이 실제로 어떤 모습인지
두 도구 사이의 간격을 볼 때의 본능은 다리를 놓는 것입니다 – Zapier 자동화, 웹훅, 동기화 스크립트. 단순하고 예측 가능한 워크플로(Linear 이슈가 "완료"로 이동하면 Notion 상태를 업데이트)에는 그것으로 충분히 작동합니다.
하지만 엔지니어링과 프로덕트 사이의 데이터 사일로에는 상태뿐 아니라 컨텍스트 스위칭이 포함됩니다. PM은 상태 필드만 변경한 것이 아니라 세 개의 Linear 이슈 중 두 개에 대한 "완료"의 의미를 바꾸는 스펙 단락을 다시 작성했습니다. 단순한 상태 웹훅은 diff 로직과 시맨틱 매핑을 추가하지 않으면 요건 수준의 변경을 놓칩니다. 대부분의 팀은 그것까지 구축할 기회를 얻지 못합니다.
실제로 필요한 것은 "이 Notion 페이지가 이 Linear 이슈와 연결되어 있다"는 것만이 아니라 "스펙의 이 섹션이 이 이슈의 요건을 설명하고 있으며, 그 섹션이 변경되었다"는 것처럼 도구 간 데이터 관계를 이해하는 무언가입니다. 목표는 누군가가 변경을 알아채고 전파하는 것에 의존하는 것이 아니라, 스펙 편집을 영향 받는 이슈에 자동으로 매핑하는 것입니다.
그것이 동기화 레이어와 지식 그래프의 차이입니다. 동기화 레이어는 도구 간에 데이터를 복사합니다. 지식 그래프는 데이터가 어떻게 관련되는지 추적하고, 그 관계가 변할 때를 감지하며, 알아야 할 사람들에게 변경 사항을 표시합니다.
저희는 이런 방식으로 작동하도록 Sugarbug를 구축하고 있습니다 – PM과 엔지니어가 이미 사용하는 도구들(Notion, Linear, GitHub, Slack, Figma)을 지식 그래프로 연결해 스펙, 태스크, 코드, 대화 간의 관계를 유지합니다. 아직 초기 단계입니다(솔직히 스케일에서 시맨틱 diff 감지를 신뢰성 있게 만드는 방법에 대해 아직 많은 것을 해결하지 못했습니다), 하지만 핵심 그래프는 작동하고 있으며 재작업이 되었을 스펙 드리프트 상황을 이미 포착하고 있습니다.
엔지니어링과 프로덕트 사이의 데이터 사일로는 사람들이 소통을 잘 못해서가 아니라 도구가 구조적으로 단절되어 있기 때문에 형성됩니다. 해결책은 커뮤니케이션 채널을 추가하는 것이 아니라 관계 수준에서 데이터를 연결하는 것입니다.
이번 주에 할 수 있는 것
"Sugarbug를 쓰는 것만이 답"이라고 주장하려는 것이 아닙니다. 지금 당장, 이미 쓰고 있는 도구로 프로덕트-엔지니어링 데이터 사일로의 최악의 영향을 줄이기 위해 할 수 있는 일들이 있습니다.
교차 참조를 명시적으로, 양방향으로, 담당자를 두고 만드세요. 모든 Notion 스펙 하단에는 거기서 생성된 이슈들로의 링크가 담긴 "Linear 이슈" 섹션이 있어야 하고, 모든 Linear 이슈는 소스 스펙으로 링크백해야 합니다. 스펙당 교차 참조를 담당할 1명을 지정하세요 – 팀 전체가 아니라, 이름이 명시된 1명을. 저희는 "모두가 책임진다"는 버전을 시도했고 (예상대로) 아무도 책임지지 않았습니다. 링크는 시간이 지나면 어차피 drift되겠지만, 담당자가 있으면 drift가 발견될 때 누구에게 알릴지 알 수 있습니다.
리마인더가 아닌 트리거를 갖는 "스펙 변경" 의식을 만드세요. 스펙이 실질적으로 변경될 때(오타가 아니라 – 실제 요건 변경), PM은 Notion 탭을 닫기 전에 연결된 Linear 이슈를 업데이트합니다. 나중에가 아니라, "기회가 되면"도 아니라 – 탭을 닫기 전에. 영향 받는 각 이슈에 대한 코멘트는 한 줄이어야 합니다: 무엇이 변경되었는지, 업데이트된 섹션으로의 링크, 그리고 이슈의 수락 기준이 여전히 유효한지. 업데이트를 물리적 동작(탭 닫기)에 연결하는 것이 누군가의 기억에 의존하는 것보다 효과적임을 알게 되었습니다. 기억이야말로 애초에 사일로가 형성된 방식이기 때문입니다.
15분짜리 금요일 우선순위 매칭 점검을 실시하세요. 1명이 (주 단위로 로테이션하며) PM의 Notion 상위 5개 우선순위와 엔지니어링 스프린트의 상위 5개를 나란히 펼쳐 확인합니다. 질문은 "이것들이 동일한가?"가 아닙니다 – 동일하지 않을 것이고, 그것은 괜찮습니다. 질문은 "이 중 어느 것이 서로 적극적으로 모순되는가?"입니다. PM의 1순위가 스프린트 어디에도 없다면, 그것은 월요일에 해야 할 대화이지 상태 업데이트가 아닙니다.
이것들은 수동 프로세스이며, 유효 기간이 있습니다. 엔지니어 5명과 PM 2명이라면 번거롭지만 작동합니다. 엔지니어 15명, PM 3명, 그리고 Figma를 섞는 디자인 팀이 되면 도구 간 관계는 누구도 손으로 추적할 수 없을 만큼 빠르게 늘어납니다. 하지만 최악의 프로덕트 엔지니어링 정렬 격차가 어디에 있는지 알려줄 것입니다 – 그리고 결국 모든 것을 자동화하더라도 그 진단 가치는 노력에 값합니다.
장기적인 해결책이 Sugarbug든 다른 무엇이든(저희는 분명히 올바른 것을 구축하고 있다고 생각하지만, 저는 편향되어 있습니다), 프로덕트 매니지먼트와 엔지니어링 협업 문제는 도구 자체가 시맨틱 수준에서 연결되고 사람이 앱 간에 컨텍스트 스위칭 하는 것이 아니라 결정을 내리는 데 집중할 수 있을 때 비로소 해결됩니다.
수동 교차 참조가 작동하고 있다면, 계속되는 한 그것을 사용하세요. 커뮤니케이션에 대한 같은 회고 액션 아이템을 반복하고 있다면, 문제는 여러분의 사람이 아닙니다. 데이터 아키텍처입니다.
Notion, Linear, GitHub, Slack을 하나의 지식 그래프로 연결하여 스펙 변경이 담당 엔지니어에게 자동으로 표시되도록 하세요.
Q: 프로덕트-엔지니어링 팀에 Sugarbug를 설정하는 데 얼마나 걸리나요? A: 도구당 초기 연결은 몇 분이면 됩니다 – OAuth로 Linear, GitHub, Notion, Slack, Figma를 인증하면 Sugarbug가 즉시 지식 그래프 구축을 시작합니다. 기존 데이터를 수집하고 스펙, 이슈, 대화 간의 관계를 매핑하기 시작하므로 하루 이틀 안에 실질적으로 활용할 수 있습니다. 온보딩 플로우는 아직 다듬고 있지만, 계정을 연결하는 것 외에 아무것도 설정할 필요가 없도록 하는 것이 목표입니다.
Q: Sugarbug가 Linear, Notion 또는 기존 도구를 대체하나요? A: 아니요. Sugarbug는 기존 도구 옆에서 그것들을 연결합니다 – 어느 것도 대체하지 않습니다. PM은 계속 Notion에 스펙을 작성하고, 엔지니어는 Linear와 GitHub에서 계속 작업하며, Sugarbug는 그 사이의 관계를 유지해 이동 중에 컨텍스트 스위칭이 발생하지 않도록 합니다. 이미 사용하는 도구들을 연결하는 조직이라고 생각하세요.
Q: Sugarbug는 Notion 스펙이 변경될 때 담당 엔지니어에게 알림을 보낼 수 있나요? A: 그것이 바로 저희가 구축하고 있는 핵심 부분입니다. Notion에서 스펙이 변경되면, Sugarbug는 어떤 Linear 이슈가 연결되어 있는지 파악하고 해당 이슈를 담당하는 엔지니어에게 변경 사항을 표시합니다. 시맨틱 감지 부분(어떤 변경이 실질적이고 어떤 것이 표면적인지 파악하는 것)은 아직 개선 중이지만, 도구 간 연결과 기본 변경 감지는 작동하고 있습니다.
Q: 동기화 도구와 지식 그래프의 차이는 무엇인가요? A: 동기화 도구는 앱 간 상태 변경을 복사합니다 – Linear 이슈가 "완료"로 이동하면 Notion 체크박스를 업데이트하는 식입니다. 지식 그래프는 데이터가 어떻게 관련되는지 추적합니다: 이 스펙이 이 세 이슈의 요건을 설명하고 있고, 수락 기준이 변경되었으며, 아직 출시되지 않은 두 이슈에 영향을 미칩니다. 그 차이는 변경이 상태 수준이 아닌 시맨틱한 경우에 가장 중요합니다.
Q: 프로덕트-엔지니어링 정렬은 커뮤니케이션 문제인가요, 데이터 문제인가요? A: 저희 경험상 거의 항상 커뮤니케이션 문제로 오진되는 데이터 문제입니다. 팀은 소통하고 있습니다 – 다만 서로를 인식하지 못하는 도구들을 통해 이루어질 뿐입니다. 그 도구들 간의 데이터 흐름을 개선하면 아무리 많은 회고나 동기화 회의로도 해결하지 못했던 정렬 문제가 해소되는 경향이 있습니다.