<“같은 Notion을 보고 있는데, 왜 이해가 다를까?”>
한 회의에서 PO가 말했습니다.
“이 페이지에 이미 다 있어요.”
하지만 개발자는 고개를 저었고, 디자이너는 시안을 꺼냈고, 영업팀은 “그게 고객 입장에서 어떤 의미냐”고 되물었습니다. 툴은 하나였지만, 모두가 다른 화면을 보고 있었던 것이죠. 이건 단순한 커뮤니케이션 문제가 아닙니다. 툴의 관점(view) 이 다르기 때문입니다.
이 시퀀스는 각 직군이 하나의 중앙 허브(SSoT) 를 기준으로 정보를 주고받는 흐름을 시각화한 것 입니다.
모두가 같은 데이터를 보지만, 관점이 다르기 때문에 해석이 달라지는 구조를 담고 있습니다.
<업무에 따른 툴 뷰 구조>
① – PO의 뷰: “흐름”을 본다
PO는 툴을 기능보다 흐름(Flow) 으로 봅니다.
핵심 질문: “이 툴은 일의 시작과 끝을 잇고 있는가?”
관심 포인트: 의사결정, 일정, 우선순위, 의존성
툴 예시: Notion(기획 흐름), Jira(이슈 트래킹), Linear(우선순위 관리)
[PO의 툴 뷰 구조]
PO에게 툴은 ‘시간의 지도’라고 봐야 합니다. 툴이 단절되면 일정이 꼬이고, 일정이 꼬이면 전략이 흔들리죠. PO의 툴은 목적지를 그리는 지도여야 합니다.
② 개발자의 뷰: “정확성”을 본다
개발자는 툴을 정확성(Accuracy) 으로 봅니다.
핵심 질문: “명세가 완전한가?”
관심 포인트: 태스크 정의, 버전, 상태, 재현 가능성
툴 예시: Jira, GitHub, Linear, Swagger
[개발자의 툴 뷰 구조]
개발자에게 툴은 ‘계약서’ 같습니다. 요구사항이 명확하지 않으면, 작업은 언제든 무효가 되기 때문입니다.
PO가 말하는 ‘흐름’보다, 개발자는 ‘정의’를 신뢰합니다. 개발자의 툴은 불확실성을 줄이는 방패죠.
③ 디자이너의 뷰: “맥락”을 본다
디자이너는 툴을 맥락(Context) 으로 봅니다.
핵심 질문: “이 화면은 어디에서, 누구에게 쓰이는가?”
관심 포인트: 사용자 흐름, 감정선, 인터랙션
툴 예시: Figma, FigJam, Notion(디자인 가이드)
[디자이너의 툴 뷰 구조]
디자이너에게 툴은 ‘이야기판’ 입니다.
각 화면은 독립된 결과가 아니라, 하나의 서사인 셈이죠. 툴이 분리되면 맥락이 끊기고, 감정의 흐름이 사라져 버립니다. 디자이너의 툴은 감정을 설계하는 도화지와 같습니다.
④ 영업의 뷰: “결과”를 본다
영업은 툴을 결과(Result) 로 봅니다.
핵심 질문: “이게 고객한테 무슨 가치가 있나?”
관심 포인트: 고객 피드백, 실적 지표, 캠페인 반응
툴 예시: CRM(Salesforce, Hubspot), GA, Notion(세일즈 자료)
[영업의 툴 뷰 구조]
영업에게 툴은 ‘현장의 리듬’입니다.
데이터가 늦게 업데이트되면 기회를 잃게 되죠. 툴은 문서가 아니라, 행동의 속도를 만들어야 합니다. 영업의 툴은 지금을 기록하는 시간표와 같기 떄문입니다.
<그래서, 각자의 툴을 어떻게 연결할까>
모든 직군이 자신만의 ‘툴 언어’를 가집니다.
그래서 PO가 Jira를 열어보며 흐름을 확인할 때, 개발자는 그걸 명세서로 읽고, 디자이너는 감정선이 끊긴다고 느끼고, 영업은 “이게 고객과 무슨 상관이냐”고 묻게 되죠.
[해결책은 ‘공통의 인터페이스’를 설계하는 것]
1️⃣ 단일 데이터 소스(SSoT) – 모든 정보는 한 곳에서 출발
2️⃣ Cross-link 구조 – PO·Dev·Design·Sales의 툴이 링크로 엮여야 함
3️⃣ Context Bridge – 각자의 툴 맥락을 번역해주는 ‘요약 페이지’ 존재
<툴 브리지 체크리스트>
각 직군이 참조하는 ‘최종 문서’가 다르다
PO 문서와 개발 이슈가 실시간으로 동기화되지 않는다
디자인 산출물의 히스토리가 개발 단계에서 누락된다
영업팀은 고객 피드백을 다른 툴에 별도 정리한다
서로 다른 툴에서 데이터를 엑셀로 뽑아 수동 정리한다
→ 3개 이상 해당되면, 당신의 조직은 이미 툴 사일로(Silo)에 들어와 있다고 봐야 합니다.
[직군별 툴 뷰 통합 구조]
<마치며-툴은 역할을 나눌뿐>
툴은 역할을 나누지만, 좋은 팀은 시선을 합칩니다.
각자의 툴을 이해하는 순간, 서로의 언어가 다르다는 걸 인정하게 됩니다. 그때부터 툴은 단순한 시스템이 아니라, 협업의 언어가 됩니다.