같은 회사인데 왜 이렇게 다를까 - 각자의 '지도'로 움직이는 조직 이야기

같은 프로젝트, 서로 다른 세계

개발자로 일하다 보면 이런 경험 있으시죠. 분명 같은 프로젝트를 하고 있는데 기획자랑 말이 안 통하고, 디자이너는 또 다른 이야기를 하고, 임원 보고 들어가면 완전히 다른 차원의 질문이 튀어나오는 그런 순간이요. 그럴 때마다 "왜 우리는 소통이 안 될까"라고 자책하기 쉬운데요, "The Work Runs on Different Maps"라는 글이 바로 이 현상을 "서로 다른 지도를 들고 같은 도시를 돌아다니는 것"에 비유하면서 재미있게 풀어냈거든요.

각자의 머릿속에 그려진 지도

여기서 말하는 "지도"는 이게 뭐냐면요, 같은 일을 보더라도 각자의 머릿속에서 그려지는 구조가 완전히 다르다는 거예요. 개발자 머릿속에는 API 엔드포인트, 데이터베이스 스키마, 배포 파이프라인, 레거시 코드의 지뢰밭 같은 게 지도처럼 펼쳐져 있어요. 그런데 PM의 지도를 열어보면 완전히 달라요. 유저 스토리, 릴리스 일정, OKR 진행도, 이해관계자 목록이 그려져 있거든요. 디자이너는 또 다른 지도를 봐요. 사용자 플로우, 컴포넌트 일관성, 접근성 기준, 에지 케이스에서의 UI 변화 같은 거요. 임원 지도는 한 단계 더 추상적이에요. 매출, 리텐션, 번다운 차트, 경쟁사 움직임이 그 안에 있죠.

이 글이 던지는 핵심 통찰은 "누가 맞고 누가 틀리냐"가 아니라 "아무도 전체를 보지 못한다"는 점이에요. 각자의 지도가 각자의 일을 하기에는 최적화되어 있지만, 그 지도끼리 겹치는 영역이 생각보다 훨씬 작거든요. 예를 들어 "이 기능 언제 나와요?"라는 질문에 개발자는 "QA 끝나면요"라고 답하고, PM은 "다음 스프린트 목요일이요"라고 답하는데, 둘 다 거짓말을 하는 게 아니에요. 서로 다른 지도에서 서로 다른 랜드마크를 보며 말하는 것뿐이죠.

콘웨이의 법칙부터 팀 토폴로지까지

사실 이런 관점은 갑자기 튀어나온 이야기는 아니에요. 도널드 쇤의 "성찰적 실천가" 개념이나 멜빈 콘웨이의 콘웨이 법칙(조직의 소통 구조가 시스템 구조에 그대로 투영된다는 법칙)과 맞닿아 있어요. 최근에는 "팀 토폴로지(Team Topologies)" 같은 책이 "스트림 정렬팀"과 "인지 부하" 개념으로 이 문제를 다루고 있고, 요즘 뜨거운 플랫폼 엔지니어링 논의도 결국 개발자 지도와 인프라 지도를 어떻게 이어 붙일까의 문제예요. "DevEx(개발자 경험)"라는 용어가 유행하는 것도 같은 맥락이고요.

실무에서 바로 써볼 수 있는 것들

한국의 많은 회사가 아직도 "요구사항 문서만 정확하면 다 해결된다"고 믿는 경향이 있는데, 이 글은 그 생각을 살짝 흔들어요. 문서가 아무리 상세해도 각자의 해석 틀이 다르면 결과물은 반드시 갈리거든요. 실무에서는 이렇게 시도해볼 만해요.

첫째, 회의를 시작할 때 "우리가 지금 어떤 지도를 보고 있는지"를 맞추는 30초를 가지세요. "오늘은 엔지니어링 관점에서 이 문제를 볼 겁니다"라고 선언만 해도 대화의 결이 달라져요. 둘째, 결정이 어긋날 때 "누구 말이 맞냐"가 아니라 "이 결정에는 어느 지도가 더 적합한가"를 물어보세요. 성능 문제는 개발자 지도가, 릴리스 일정은 PM 지도가 더 정확한 거거든요. 셋째, 다른 직군의 지도를 억지로라도 한 번씩 읽어보세요. 디자이너의 피그마 파일, PM의 로드맵 문서, CS팀의 티켓 로그 같은 걸 한 달에 한 번 정도만 열어봐도 시야가 넓어져요.

마무리

결국 핵심은 "소통이 부족해서" 일이 어긋나는 게 아니라 "근본적으로 다른 렌즈를 쓰고 있어서"일 수 있다는 거예요. 소통을 더 늘린다고 지도 자체가 합쳐지진 않거든요. 오히려 "우리는 원래 다른 지도를 본다"는 전제를 먼저 공유하는 게 첫걸음이에요. 여러분 팀에서는 어떤 지도가 가장 지배적인가요? 그리고 그 지도 때문에 보이지 않는 사각지대를 느낀 적이 있으신가요?