사일로 현상, 회의는 쌓이는데 부서끼리는 왜 여전히 모를까요

마케팅팀은 매주 월요일 주간 회의를 하고, 영업팀은 화요일에 파이프라인 리뷰를 하고, 개발팀은 매일 데일리 스크럼을 해요. 회의는 분명히 열심히 하고 있는데, 정작 "그거 혹시 영업팀 회의에서 나온 얘기 아니었어?"라는 질문에 아무도 바로 답을 못 하는 순간이 있어요. 분기 말이 되면 세 팀이 같은 고객을 두고 서로 다른 메시지를 전달했다는 사실을 뒤늦게 알게 되기도 하고요. 회의록은 분명 어딘가에 쌓여 있는데, 그게 다른 부서 눈에는 전혀 보이지 않는 거예요. 이런 현상을 경영학에서는 "사일로 현상"이라고 불러요.

사일로 현상이란, 뜻과 원인

사일로 현상(organizational silos effect)은 원래 곡식을 저장하는 원통형 창고 '사일로(silo)'에서 온 말이에요. 창고마다 서로 다른 곡식이 분리되어 섞이지 않듯이, 조직 안의 부서들이 정보를 서로 공유하지 않고 각자 고립된 채 일하는 상태를 가리켜요. Asana가 정리한 자료에 따르면 조직 사일로는 정보 흐름이 최소화되어 비즈니스의 다른 부분과 단절된 팀을 뜻하고, 이로 인해 노력의 중복, 기회 놓침, 전체 효율성 저하 같은 문제가 반복적으로 발생한다고 해요.

사일로 현상이 생기는 이유

• 부서마다 사용하는 도구와 업무 프로세스가 달라서, 서로의 작업 맥락을 들여다볼 창구 자체가 없어요.

• 부서 간 목표나 평가 기준이 경쟁 구도로 설계되어 있으면, 정보를 공유할 유인이 오히려 줄어들어요.

• 상명하달식의 수직적 의사결정 구조에서는 옆 부서보다 위쪽 보고 라인에만 정보가 흐르기 쉬워요.

• 그리고 무엇보다, 회의 자체가 부서 단위로 닫혀 있어요. 마케팅 회의 내용은 마케팅팀 폴더에, 영업 회의 내용은 영업팀 폴더에 각각 쌓일 뿐, 서로 연결되지 않아요.

"사일로"라는 단어, 회사마다 다르게 써요

흥미로운 점은 "사일로"라는 말이 정반대의 의미로도 쓰인다는 거예요. 토스는 프로덕트 디자이너·개발자·데이터 분석가 등 5명 내외로 구성된 작은 자율 조직 단위를 "사일로"라고 부르고 있어요. 여기서 사일로는 의사결정을 빠르게 하기 위해 일부러 작게 쪼갠 팀을 뜻해요. 반면 경영학에서 말하는 "사일로 현상"은 그 반대로, 부서 간 정보가 고립되어 생기는 부작용을 가리키는 말이에요. 같은 단어를 쓰지만 하나는 '의도적으로 작게 나눈 자율 조직'을, 다른 하나는 '의도치 않게 서로 모르게 된 단절 상태'를 뜻하는 셈이에요. 글을 검색하다 두 의미가 섞여서 헷갈렸다면, 이 차이를 기억해두면 좋아요.

회의가 쌓여도 사일로가 사라지지 않는 이유

회의록 작성 도구나 녹음 앱을 도입해도 사일로 현상이 저절로 풀리지는 않아요. 녹음하고 요약하는 기능은 결국 '내 회의'를 더 잘 기록하는 데 초점이 맞춰져 있고, 그 기록이 다른 부서의 회의와 연결되는 구조는 따로 설계되어 있지 않은 경우가 많거든요. 마케팅팀 회의록이 아무리 꼼꼼해도, 영업팀 담당자가 그걸 찾아서 읽어볼 이유나 방법이 없다면 여전히 각자의 창고에 갇혀 있는 셈이에요. 결국 핵심은 "회의를 더 잘 기록하는 것"이 아니라 "기록된 회의끼리 서로 연결되는 것"이에요.

사일로를 허무는 접근, 뭐가 다를까요

조직이 사일로 현상에 대응하는 방식은 크게 몇 갈래로 나눌 수 있어요.

특히 Otter.ai는 공식 발표에서 자사의 Conversational Knowledge Engine이 '엔터프라이즈 전반의 전통적인 정보 사일로를 허문다'고 소개했어요. 부서마다 따로 쓰던 회의 기록을 하나의 조직 단위 지식 그래프로 통합해, "이 클라이언트 관련해서 최근에 무슨 얘기 나왔어?" 같은 질문에 여러 회의를 가로질러 답하는 방향으로 가고 있다는 점에서, 사일로 문제의 핵심이 '회의를 더 잘 쓰는 것'이 아니라 '회의끼리 연결하는 것'이라는 걸 업계 전체가 확인해주고 있는 셈이에요.

출처: Otter(Otter.ai, Inc.) App Store 공식 스크린샷. 한 번의 마케팅 회의 요약 안에 "Align on pricing with Sales team"처럼 다른 부서와 맞물린 액션 아이템이 함께 기록되는 화면이에요.

미키는 부서 간 회의 맥락을 어떻게 연결하나요

미키는 회의가 끝날 때마다 그 안에서 언급된 사람·프로젝트·결정 사항을 온톨로지 구조로 연결해요. 그래서 마케팅 회의에서 나온 '신제품 런칭 일정' 얘기와 영업 회의에서 나온 '같은 제품의 고객 피드백' 얘기가 서로 다른 부서, 다른 시간에 이뤄졌어도 같은 맥락으로 묶일 수 있어요. 회의가 끝난 뒤에는 그 내용을 마인드맵으로 정리하거나, 슬랙 채널에 공유하거나, 노션 문서로 연결하거나, 프레젠테이션 초안으로 바로 이어갈 수 있고요. 이렇게 쌓인 회의들이 팀 전체가 함께 물어볼 수 있는 팀 에이전트로 이어지는 거예요. 온톨로지 기반 지식 관리가 왜 필요한지는 회의 100개가 쌓이면 회사에 무슨 일이 생길까요 글에서, 지식 그래프의 개념 자체는 지식 그래프란 무엇인가요 글에서 더 자세히 다루고 있어요.

자주 묻는 질문

Q. 사일로 현상은 왜 하필 회의에서 두드러지나요?

결정과 맥락이 가장 먼저 만들어지는 자리가 회의이기 때문이에요. 문서나 메일은 결과만 남기지만, 회의에서는 '왜 그렇게 결정했는지'까지 오가요. 그런데 그 회의가 부서 단위로만 기록되고 끝나면, 결정의 배경이 다른 부서에는 아예 전달되지 않아요.

Q. 사일로 조직이 다 나쁜 건가요?

아니에요. 토스처럼 의도적으로 작은 자율 팀 단위를 '사일로'라고 부르며 빠른 의사결정을 추구하는 경우도 있어요. 문제가 되는 건 의도치 않게 부서끼리 정보가 단절되는 '사일로 현상' 쪽이에요. 작은 팀으로 조직을 쪼개더라도, 팀 간 정보가 흐르는 구조가 따로 설계되어 있다면 사일로 현상과는 다른 이야기예요.

Q. 미키가 사내 모든 문서를 통합하는 지식관리시스템(KMS)인가요?

아니에요. 미키는 노션이나 컨플루언스 같은 전사 위키를 대체하지 않고, 회의라는 특정 데이터에 한정해서 맥락을 연결하는 도구예요. 회의 밖에서 만들어지는 문서나 보고서까지 아우르는 범용 지식관리시스템을 표방하지는 않아요.

Q. 부서 간 회의를 연결하려면 뭐부터 시작하면 되나요?

전사 조직개편처럼 큰 결정을 먼저 할 필요는 없어요. 지금 하고 있는 회의부터 녹음하고 기록을 남기는 것만으로 시작할 수 있어요. 기록이 하나둘 쌓이기 시작하면, 그다음부터는 그 기록들을 어떻게 연결할지의 문제가 돼요.

마무리

사일로 현상은 조직 구조를 통째로 바꾼다고 당장 해결되는 문제가 아니에요. 오히려 매일 열리는 회의들이 서로 연결되지 않은 채 각자의 창고에 쌓이고 있다는 사실을 인정하는 데서 시작해요. 미키는 그 회의들을 온톨로지로 엮어서, 부서가 달라도 같은 맥락을 공유할 수 있는 팀 에이전트를 만들어가고 있어요. 어느 부서의 회의든 상관없이 궁금한 걸 물어보면 답이 나오는 환경이 필요하다면, micky.pro에서 미키를 먼저 만나보세요.