부서 간 협업: 모든 일을 회의로 하지 않고 운영하는 방법 (2026)

부서 간 협업이란 서로 다른 기능 조직의 사람들, 예컨대 제품팀과 고객지원팀, 영업과 물류, 병원 접수처와 수납 부서, 그리고 흔히 회사 밖 파트너까지 함께 하나의 업무를 끝내는 일입니다. 서로에게 보고하거나 서로의 회의에 앉아 있는 것이 아닙니다. 하나의 일을 끝내는 것이고, 그 일에는 책임지는 사람 한 명, 업무를 논의하는 장소 하나, 무엇을 결정했고 누가 무엇을 하는지 적은 기록 하나가 있습니다. 잘 운영되면 대부분 조용합니다. 각 기능 조직은 글을 쓰고, 책임자는 읽고, 두 조직이 이번 주 안에 선택지 중 하나를 골라야 할 때만 회의가 열립니다.

잘못 운영되면 달력이 일정으로 가득 찹니다. 업무를 넘길 때마다 동기화 회의가 열리고, 동기화 회의마다 후속 회의가 붙습니다. 실제로 일하는 사람들은 한 주를 나머지 절반을 맡은 사람들에게 설명하며 보냅니다. 이 가이드는 먼저 실무 요령을 다룹니다. 부서 간 업무가 취하는 세 가지 형태, 무너지는 네 곳, 정례 회의 없이 운영하는 다섯 가지 규칙입니다. 이어서 그대로 복사해 쓸 수 있는 한 페이지짜리 업무 협약, 작성 예시 세 가지, 팀이 이미 비용을 내고 쓰는 도구 안에서 업무가 놓이는 곳(문서화된 내용 기준), 그리고 그 업무가 이루어지는 채널을 모든 기능 조직이 각자의 언어로 읽을 수 있게 유지하는 한 가지 방법을 소개합니다.

부서 간 협업이란 무엇이고, 무엇이 아닌가

부서 간 업무는 세 가지 형태를 취하며, 문제의 대부분은 그중 하나를 다른 형태의 습관으로 운영할 때 생깁니다.

첫 번째 형태는 별도의 가이드가 있습니다. 이 글은 회의가 불어나는 두 번째와 세 번째 형태를 다룹니다. 기능 조직 네 곳이 참여하는 프로젝트에서 두 조직씩 짝지어 주간 동기화 회의를 하면, 일을 시작하기도 전에 한 주에 회의가 여섯 개입니다. 회의에서 답하는 요청 하나는, 한 사람이 답을 쓰는 데 걸린 시간만큼을 방 안의 모든 사람에게서 가져갑니다.

부서 간 협업은 부서 간 조율(interdepartmental coordination)과도 다릅니다. 조율은 각 부서가 자기 일을 하면서 서로 소식을 공유하는 것이고, 협업은 한 기능 조직만으로는 끝낼 수 없는 하나의 업무입니다. 판단 기준은 결과물입니다. 마케팅이 고객지원 없이 캠페인을 내보낼 수 있고 고객지원이 마케팅 없이 매크로를 쓸 수 있다면 그들은 조율하는 것이며, 일주일에 메시지 한 통이면 충분합니다. 양쪽이 함께 끝내야 출시가 끝난다면 협업하는 것이고, 함께 일할 공유된 장소가 필요합니다.

무너지는 곳: 네 가지 실패 지점

부서 간 업무는 킥오프에서는 좀처럼 실패하지 않습니다. 몇 주 뒤, 예측 가능한 네 곳에서 실패합니다.

1. 업무 인계. 기능 조직 A가 자기 몫을 끝내고 B에게 알립니다. A의 채널에 올린 메시지일 수도 있고, B가 없던 회의일 수도 있으며, 휴가 중인 한 사람에게 보낸 이메일일 수도 있습니다. B는 늦게 시작하거나 잘못된 버전으로 시작합니다. 해법은 또 다른 회의가 아니라, 모든 인계를 글로 남기고 모든 기능 조직이 읽는 장소 하나입니다.
2. 책임 소재. 기능 조직 넷에 리드 넷, 그리고 이 업무는 프로젝트 소유입니다. 곧 아무의 것도 아니라는 말입니다. 각 리드는 자기 절반을 맡고, 이음매는 아무도 맡지 않습니다. 해법은 이름입니다. 어느 기능 조직 출신이든 결과물 전체에 대한 책임자를 한 명 두고, 그에게 다른 조직 누구에게든 일정을 요청할 권한을 줍니다.
3. 용어. "완료"는 엔지니어링에는 테스트 완료, 마케팅에는 공지 완료, 고객지원에는 문서화 완료를 뜻합니다. "고객"은 영업에는 병원이고 제품팀에는 간호사입니다. 부서 간 프로젝트의 회의 중 절반은 두 사람이 서로 다른 말로 합의하고 있었다는 사실을 확인하려고 존재합니다. 해법은 한 번 작성해서 업무가 이루어지는 곳에 두는 짧은 용어집입니다.
4. 기록. 결정은 네 기능 조직 중 두 곳 사이의 통화에서 내려졌습니다. 세 번째 조직은 일주일 뒤에 전해 듣고 결정을 다시 엽니다. 네 번째 조직은 끝내 듣지 못합니다. 해법은 결정을 내린 날 프로젝트 채널에 적는다는 규칙, 그리고 이유까지 남겨야 하는 결정을 위한 결정 로그입니다.

기능 조직들이 업무 언어를 공유하지 않을 때는 다섯 번째 실패 지점이 나타납니다. 개발팀은 한 나라에, 고객지원 데스크는 다른 나라에, 고객사의 프로젝트 리드는 세 번째 나라에 있는 경우입니다. 이때는 각 기능 조직이 자기 언어로 자기 채널을 쓰고, 모든 인계는 국경을 두 번 넘습니다. 한 번은 기능 조직 사이에서, 한 번은 언어 사이에서입니다. 아래 규칙은 이 경우도 염두에 두고 썼습니다. 해법은 같기 때문입니다. 장소 하나, 기본은 글로 쓰기, 그리고 그 장소에 요구되는 조건이 하나 더 붙습니다.

모든 일을 회의로 하지 않고 운영하는 방법

규칙은 다섯 가지입니다. 이 규칙은 정례 동기화 회의를 대체하며, 킥오프와 결정 회의는 대체하지 않습니다. 그 둘은 그대로 둡니다.

1. 업무 전체에 책임자 한 명. 킥오프에서, 업무의 가장 큰 부분을 맡은 기능 조직 가운데 한 곳에서 정합니다. 책임자가 모든 사람의 일을 하는 것은 아닙니다. 책임자는 어느 날이든 결과물이 어떤 상태이고 무엇을 기다리고 있는지 말할 수 있는 사람입니다. 각 기능 조직은 책임자에게 연락 담당자 한 명을 지정하고, 그 담당자가 자기 조직의 몫에 대해 답합니다. 기능 조직당 이름이 두 개, 곧 리드와 실무자가 있으면 이미 너무 많습니다. 책임자는 누구에게 물어야 하는지 알아야 합니다.

2. 채널 하나, 그리고 모두가 그 안에. 기능 조직별이나 조직 쌍별이 아니라 업무 하나당 채널 하나를 두고, 모든 기능 조직의 담당자와 업무에 참여하는 회사 밖 사람들을 모두 넣습니다. 통합 업체, 에이전시, 고객사 프로젝트 리드, 유통사 주문 담당자가 여기에 해당합니다. 이 채널에서 인계를 알리고, 질문을 하고, 결정을 적습니다. 프로젝트를 자기 조직 채널에서 논의하고 공유 채널에는 보고만 하는 기능 조직은 프로젝트를 둘 운영하는 셈이며, 그중 공유 채널 쪽이 더 느립니다.

3. 기본은 글, 회의는 결정을 위해. 인계, 질문, 현황, 위험의 기본 형식은 채널의 메시지입니다. 둘 이상의 기능 조직이 이번 주 안에 선택지 중 하나를 골라야 하고 그 선택에 사람들이 한 방에 모여야 할 때 회의를 잡습니다. 잡기 전에 확인할 기준은 이렇습니다. 이 회의는 어떤 결정을 내리는가? 답이 "모두에게 업데이트"라면 그것은 메시지입니다. 답이 "출시일에 대해 선택지가 세 개인데 마케팅과 고객지원의 의견이 갈립니다"라면, 회의 안건을 갖춘 25분짜리 회의이고, 끝날 때 결정을 다시 읽어 확인합니다.

4. 매주 정해진 시각까지 서면 현황. 각 기능 조직은 매주 같은 요일, 정해진 시각 전에 채널에 세 줄을 올립니다. 완료, 다음, 막힘입니다. 책임자는 모두 읽고 결과물 전체에 대해 한 줄을 올립니다. 순조로움, 위험, 또는 일정이 바뀌었다면 변경 사실과 이유입니다. 주간 현황 회의는 이것을 소리 내어 읽는 일입니다. 서면 방식은 각 기능 조직에 한 시간 대신 5분이 들고, 참석하지 못한 사람도 읽을 수 있습니다. 팀 생산성을 높이는 방법에 이 교체의 계산이 나와 있습니다.

5. 기록 하나: 결정, 할 일, recap을 채널에. 결정은 전화나 복도에서 내렸더라도, 아니 오히려 그럴수록, 내린 날 날짜와 책임자를 붙여 채널에 적습니다. 모든 action item에는 이름과 날짜가 있어야 합니다. 회의가 열렸다면 그 recap은 같은 날 같은 채널에 올라가므로, 초대받지 않은 기능 조직도 묻지 않고 무엇이 결정되었는지 읽을 수 있습니다. 프로젝트가 끝나면 채널이 곧 기록입니다. 모든 인계, 모든 결정, 모든 recap이 일어난 순서대로 남습니다.

용어집은 여섯 번째 항목이며 한 번만 하면 됩니다. 킥오프에서 기능 조직마다 다르게 쓰는 용어 열 개를 골라 정의를 하나씩 붙여 채널에 게시하고 고정합니다. "완료", "고객", "출시", "배포 완료", "승인" 같은 프로젝트 고유의 말입니다. 20분이면 되고, "아, 그걸 말한 거였어요"가 유일한 결과였던 회의들을 없애 줍니다.

그대로 복사해 쓸 수 있는 부서 간 업무 협약

킥오프 때 프로젝트 채널에 노트로 올리고, 대괄호 부분을 채운 뒤 고정하세요. 한 페이지 분량입니다. 두 페이지가 되면 프로젝트 계획서가 끼어들려는 것입니다.

[프로젝트] — 부서 간 업무 협약
성과: [한 문장: 무엇을, 언제까지 끝내는가]
책임자: [이름, 기능 조직] · 스폰서: [이름] · 합의일: [날짜] · 리뷰: [날짜, 종료 시점 또는 중간]

기능 조직과 담당자
[기능 조직] — [이름], [담당 부분] 책임 · [기능 조직] — [이름], [부분] · [외부 파트너] — [이름], [부분]

업무가 이루어지는 곳
채널: [채널 하나]. 위의 모든 담당자가 [외부 파트너]를 포함해 이 채널에 있습니다. 인계, 질문, 위험, 현황은 발생한 날 이곳에 글로 올립니다. 이 프로젝트에 관한 어떤 것도 특정 기능 조직의 자체 채널에서 결정하지 않습니다.

회의를 여는 경우
둘 이상의 기능 조직이 한 방에 있어야 하는 선택지 간 결정. 안건과 결정할 질문을 붙여 소집하고, 25분으로 하며, 끝날 때 결정을 다시 읽고 같은 날 채널에 적습니다. 그 밖의 모든 것은 메시지입니다.

주간 현황
각 기능 조직은 [요일] [시각]까지: 완료 · 다음 · 막힘. 책임자는 [시각 + 2]까지: 순조로움 / 위험 / 일정 변경과 그 이유.

결정과 할 일
결정은 내린 날 날짜와 책임자를 붙여 여기에 적습니다. [무응답 규칙, 예: 영업일 하루 동안 이의가 없으면 동의로 간주]. 할 일에는 이름과 날짜가 있어야 하고, 없으면 할 일이 아닙니다.

용어집
[용어] — [정의 하나] · [용어] — [정의] · … (최대 열 개)

완료의 기준: [모든 기능 조직이 서명하는 체크리스트 — 테스트, 공지, 문서화, 청구]

이 협약은 일반 텍스트라서 Word 문서, Google Doc, Slack 캔버스, 채팅 메시지에 서식 변환 없이 붙여 넣을 수 있습니다.

작성 예시 세 가지

제품, 고객지원, 마케팅이 함께하는 기능 출시 — 직원 40명 규모의 소프트웨어 회사

발렌시아의 제품팀, 루마니아어로 일하는 클루지의 6인 고객지원 데스크, 부에노스아이레스의 마케팅 프리랜서. 기능 조직 셋, 언어 셋, 출시일 하나입니다.

성과: 일정 관리 기능이 12월 12일까지 모든 유료 고객에게 열리고, 도움말 문서가 게시되며, 공지가 발송된다.
책임자: Marta, 제품. 기능 조직: 제품 — Marta, 개발과 일정; 고객지원 — Andrei, 도움말 문서, 매크로, 첫 주 티켓; 마케팅 — Lucía, 공지와 인앱 메시지.
채널: #launch-scheduling. Lucía는 외부 멤버로 참여.
회의: 한 번. 출시 전주에, 고객지원의 테스트에서 문제가 발견될 경우 두 가지 롤아웃 방안 중 하나를 고르기 위해. 그 외에는 없음.
현황: 목요일 11:00(CET)까지 각 기능 조직, Marta는 13:00까지.
용어집: "완료" — 고객지원이 스테이징 계정에서 테스트, 도움말 문서 게시, 공지 예약; "고객" — 병원 소유주가 아니라 병원 접수 담당자.
완료의 기준: 용어집의 "완료" 세 줄 모두 충족, 그리고 Andrei의 첫 주 티켓 건수를 채널에 게시.

회의는 한 번 열렸고, 테스트 결과가 이미 채널에 올라와 있었기 때문에 롤아웃 방안은 18분 만에 정해졌습니다. 3개 기능 조직이 주간 동기화 회의를 하며 진행했던 지난 출시에서는 그런 회의가 열한 번이었습니다.

접수처, 간호, 수납이 함께하는 새 접수 절차 — 외부 통합 업체가 있는 병원

온라인 환자 접수를 도입하는 리옹의 한 병원. 접수처, 간호, 수납, 그리고 양식을 진료 소프트웨어에 연결하는 통합 업체가 참여합니다. 업체는 카사블랑카에 있는 회사로 프랑스어와 아랍어로 일합니다.

성과: 모든 신규 환자가 첫 방문 전에 온라인으로 접수 양식을 작성하고, 접수처는 같은 내용을 두 번 입력하지 않는다. 2월 1일부터.
책임자: Claire, 접수처 리드. 기능 조직: 접수처 — Claire, 양식의 질문과 첫날 절차; 간호 — Samir, 임상 항목; 수납 — Inès, 보험 항목과 내보내기; 통합 업체 — Youssef, 연결과 테스트 환경.
채널: #intake-online. Youssef는 프로젝트 기간 동안 참여.
회의: 두 번 — 간호와 수납이 환자가 반드시 답해야 하는 질문과 미뤄도 되는 질문을 고르는 항목 검토, 그리고 한 주 전의 go/no-go.
현황: 월요일 10:00까지 각 기능 조직, Claire는 12:00까지.
용어집: "완성된 양식" — 모든 항목이 아니라 필수 항목이 모두 채워진 양식; "라이브" — 통합 업체의 테스트 주소가 아니라 병원 자체 사이트에서 작동.
완료의 기준: 첫 주에 실제 환자 20명이 양식을 통과하고, 접수처가 다시 입력한 건은 0건이며, Youssef의 인수인계 노트가 채널에 있다.

요청: 재무가 영업에서 예측치를 받아야 할 때

프로젝트가 아닙니다. 한 기능 조직이 다른 조직에서 무언가를 한 번 필요로 하는 경우입니다. 협업 전체가 메시지 한 통입니다.

받는 사람: Pau (영업) · 보내는 사람: Inés (재무)
내용: 유통사별 1분기 예측치, 평소 쓰는 시트로.
기한: 목요일 16:00. 이사회 자료가 금요일 정오에 마감되기 때문.
중요한 이유: 생산 계획이 이 수치를 기준으로 잡히므로, 예측이 늦으면 계획도 늦어집니다.
어려울 경우: 화요일까지 알려 주세요. 지난 분기 수치를 쓰고 메모를 남기겠습니다.

내용, 기한, 이유, 대안이 갖춰진 요청은 회의 없이 답이 옵니다. 그것들이 빠진 요청은 회의가 됩니다.

이미 쓰고 있는 도구에서 부서 간 업무가 놓이는 곳

각 제품군에는 여러 팀에서 모인 그룹을 위한 자리가 있고, 각각 다른 지점에서 한계에 부딪힙니다. 대개 조직 밖의 사람이나 다른 언어를 읽는 구성원에게서입니다. 벤더 자체 페이지에 문서화된 동작만 다루며, 각 사실을 확인한 달을 함께 적었습니다.

어디서나 같은 점이 두 가지 있습니다. 그룹의 기록, 곧 협약, 인계, 결정은 입력된 언어로만 존재하고, 다른 언어를 읽는 구성원은 메시지 하나씩 읽는 사람별 번역본이나 누군가 만들어 준 사본을 읽게 됩니다. 그리고 회의가 남기는 것은 채널 옆에 놓인, 그 방의 언어로 쓰인 문서입니다. 통화가 끝난 뒤 녹취록과 요약은 어디로 가는가에 더 자세한 설명이 있습니다.

프로젝트 전체를 채널 하나에서 운영하는 방법

InterMIND는 업무가 채널 안에 놓이는 커뮤니케이션 공간이어서, 다섯 가지 규칙이 자연스럽게 자리 잡을 곳이 있습니다. 출시, 접수 프로젝트, 유통사 온보딩마다 채널을 만들고, 모든 기능 조직의 담당자를 회사 밖 사람까지 포함해 넣습니다. 외부 멤버는 이메일로 무료 계정에 참여하며, 참여하기 전의 채널 기록을 읽을 수 있고, 채널에서 시작하는 모든 통화에 들어옵니다. 업무 협약과 용어집은 노트로 게시하고 고정합니다. 노트는 제목과 굵은 줄을 쓸 수 있는 서식 있는 메시지이며, 나중에 자체 메뉴에서 편집할 수 있습니다. 그래서 새 담당자가 가장 먼저 읽는 것은 프로젝트가 어떻게 돌아가는지 적은 그 페이지입니다.

각 기능 조직은 자기 언어로 쓰고 채널을 자기 언어로 읽습니다. 클루지 데스크는 목요일 현황을 루마니아어로 쓰고, 발렌시아 팀은 스페인어로 읽고, 부에노스아이레스의 Lucía도 스페인어로 읽습니다. 원문은 원하는 사람이라면 누구나 토글 한 번이면 볼 수 있습니다. 채널에 올린 파일, 곧 예측 시트, 항목 목록, 통합 업체의 인수인계 문서는 자동으로 요약되고, 그 요약은 공유된 PDF나 Office 문서처럼 각 독자의 언어로 열립니다. 하나뿐인 회의가 열릴 때는 채널에서 클릭 한 번으로 시작하고, 채널의 멤버가 곧 참석자 명단이 됩니다. 협약이나 선택지 목록은 Share to conference로 영상 타일 옆 모두의 화면에 띄워집니다. 공유하는 사람이 방 안 사람들이 지켜보는 가운데 실시간으로 편집하고, 각 참석자는 그것을 자기 언어로 읽습니다. 통화가 끝나면 recap은 회의 자체의 녹취록을 바탕으로 작성되며, 요약, 녹취록, 녹화본으로 이루어지고, 이메일, 채널 메시지, 캘린더 일정의 링크로 도착합니다. 로그인한 모든 멤버가 자기 언어로 읽을 수 있습니다. 어느 멤버든 편집할 수 있고, 모든 편집은 작성자와 수정 이력을 남기며, 채널은 지난 세션의 recap을 모두 보관합니다. 그래서 그 자리에 없던 기능 조직도 아무에게 묻지 않고 무엇이 결정되었는지 읽을 수 있습니다. 채널 밖 도구가 전할 내용이 있다면, 곧 티켓 시스템, 빌드 파이프라인, 통합 업체의 모니터링이 그렇다면, 채널의 호스트가 그 도구에 고유한 주소를 하나 줍니다. 그러면 이메일이 발신자 이름과 첨부 파일을 그대로 둔 채 일반 메시지로 채널에 도착합니다. 호스트는 어떤 주소로든 recap 사본을 추가로 보낼 수도 있어서, go/no-go의 recap이 아무도 전달하지 않아도 CRM이나 트래커의 수신 메일함에 도착합니다.

부서 간 프로젝트의 사람들이 모두 프로젝트 회사의 구성원인 것은 아니고, 모두가 오래 참여하는 것도 아닙니다. 통합 업체, 프리랜서, 유통사의 담당자는 이메일로 무료 계정을 만들어 채널의 외부 멤버로 참여하고, 다른 사람들과 똑같이 자기 언어로 읽습니다. 계정이 없는 사람은 회의 한 건의 게스트입니다. 고객사의 재무 이사는 링크로, 휴대폰으로, 무료로 go/no-go에 참여해 자기 언어로 실시간 통역을 듣고, 이후에 기록은 받지 않습니다. 기록은 채널의 멤버가 받습니다.

호스트가 공간을 제공하며, 유료 요금제에서는 이전 28일간의 활성 멤버에 대해서만 비용을 냅니다. 회의에 참여했거나, 채팅에 글을 썼거나, 어시스턴트에게 질문한 멤버입니다. 조용해진 멤버는 비용 없이 접근 권한을 유지하고, 팀 밖에서 온 채널 참여자는 집계되지 않습니다. 프로젝트에 필요한 방식입니다. 12월에 2주 동안 채널에 있다가 2월까지 조용했던 수납 리드는 그 사이 비용이 들지 않고, 돌아오면 자신이 떠난 자리에서 기록을 찾을 수 있습니다.

• 완성된 recap 열어 보기 — 여러분의 recap을 작성하는 것과 같은 코드로 만든 실제 기록입니다.
• 라이브 데모 체험하기 — 가입 없이, 말하면 방 안의 말이 청취자별로 번역되어 들립니다.

기술로서의 부서 간 협업은 어떤 도구에서도 살아남습니다. 누군가는 여전히 책임자를 정하고, 인계를 글로 쓰고, 결정이 없는 회의를 거절해야 합니다. 살아남을 필요가 없는 것은 두 번째 일입니다. 각 기능 조직의 기록 사본을 손으로, 자기 언어로, 다른 사본들보다 한 버전씩 늦게 관리하는 일 말입니다.

FAQ

부서 간 협업이란 무엇인가요?

부서 간 협업이란 제품, 영업, 고객지원, 재무, 운영 등 서로 다른 기능 조직의 사람들이, 흔히 회사 밖 파트너와 함께, 어느 한 기능 조직만으로는 끝낼 수 없는 하나의 업무를 함께 끝내는 일입니다. 각 부서가 자기 일을 하면서 서로 소식을 공유하는 조율과는 다릅니다. 세 가지 형태가 있습니다. 상설 부서 간 팀, 기한이 있는 부서 간 프로젝트, 한 기능 조직이 다른 조직에 보내는 일회성 요청입니다.

부서 간 협업의 예시는 무엇인가요?

기능 출시가 그렇습니다. 제품팀이 만들고, 고객지원이 도움말 문서를 쓰고 첫 주 티켓을 받고, 마케팅이 공지를 보내며, 셋이 모두 끝나야 출시가 끝납니다. 다른 예로는 접수처, 간호, 수납, 외부 통합 업체가 함께 온라인 접수를 도입하는 병원, 영업, 물류, 재무가 유통사의 주문 담당자를 채널에 넣고 신규 유통사를 온보딩하는 수출업체, 인사팀과 채용 부서가 함께하는 채용 라운드가 있습니다. 어느 경우든 한 사람이 성과 전체를 책임지고, 모든 기능 조직에 연락 담당자가 한 명씩 있습니다.

부서 간 협업은 왜 중요한가요?

조직이 내놓는 업무의 대부분은 한 기능 조직 안에 들어맞지 않기 때문입니다. 출시, 새 프로세스, 신규 고객, 새 시장은 모두 여러 기능 조직의 몫이 맞물려야 하고, 시간과 품질은 그 몫들 사이의 이음매에서 새어 나갑니다. 아무도 알리지 않은 인계, 한 기능 조직이 듣지 못한 결정, 두 조직이 다르게 쓴 단어가 그런 예입니다. 잘 운영된 부서 간 협업은 이음매를 눈에 보이게 만들고, 책임자 한 명, 채널 하나, 기록 하나로 상대 조직이 무엇을 했는지 알아내는 것이 유일한 목적이던 회의를 없앱니다.

부서 간 협업을 어떻게 개선하나요?

효과가 큰 순서대로 다섯 가지를 바꿉니다. 기능 조직별이 아니라 결과물 전체에 책임자를 한 명 둡니다. 모든 기능 조직의 담당자와 외부 관계자를 그 업무를 위한 채널 하나에 넣고, 다른 곳에서는 논의하지 않습니다. 글쓰기를 기본으로 삼고, 회의는 선택지 사이의 결정에만 잡습니다. 현황 회의는 정해진 요일에 기능 조직별 세 줄의 서면 보고로 대체합니다. 모든 결정은 내린 날 채널에 적고, 모든 할 일에는 책임자와 날짜를 붙입니다. 킥오프에서 만드는 열 개 용어의 용어집은 또 한 종류의 회의를 없애 줍니다.

부서 간 협업의 어려움은 무엇인가요?

네 가지가 반복됩니다. 한 기능 조직이 상대가 읽지 않는 곳에서 알리는 인계, 각 기능 조직이 자기 절반만 맡고 이음매는 아무도 맡지 않는 책임 분산, "완료", "고객", "승인"이 기능 조직마다 다른 뜻으로 쓰이는 용어 문제, 두 기능 조직 사이에서 내려진 결정을 듣지 못한 세 번째 조직이 다시 여는 기록 문제입니다. 기능 조직들이 언어를 공유하지 않을 때는 다섯 번째가 나타납니다. 각자 자기 채널을 쓰고, 모든 인계가 국경을 두 번 넘습니다. 해법은 모두 같은 모양입니다. 관련된 모든 사람이 읽는, 글로 쓰인 장소 하나입니다.

부서 간 협업과 부서 간 조율(interdepartmental)은 어떻게 다른가요?

부서 간 조율은 각 부서가 자기 일을 해내면서 서로 소식을 공유하는 것으로, 영업과 재무 사이의 월간 업데이트가 그 예입니다. 부서 간 협업은 여러 기능 조직의 작업을 합쳐야 하는 하나의 결과물이며, 결과에 대한 책임자가 한 명 있습니다. 제품, 고객지원, 마케팅이 각자 끝내고 그 몫이 맞물려야 출시가 끝납니다. 판단 기준은 한 기능 조직이 그 성과를 혼자 내놓을 수 있는지 여부입니다. 혼자 할 수 있다면 일주일에 메시지 한 통이면 충분하고, 할 수 없다면 기능 조직들에게는 공유된 장소와 공유된 책임자가 필요합니다.

부서 간 협업에는 어떤 역량이 필요한가요?

재능보다는 대부분 글쓰기 습관입니다. 인계를 무엇을, 누가, 언제까지로 서술하는 것, 질문에 기한과 이유를 붙이는 것, 결정을 책임자와 함께 한 문장으로 쓰는 것, 회의를 요청하기 전에 다른 기능 조직의 현황을 읽는 것입니다. 책임자에게는 두 가지가 더 필요합니다. 어느 기능 조직에든 일정을 요청할 수 있는 권한, 그리고 결정이 없는 회의를 거절하는 규율입니다. 모두에게는 프로젝트가 쓰는 열 개의 단어에 합의하고 그것을 쓰려는 의지가 필요합니다.

부서 간 협업은 어떻게 측정하나요?

결과물과 달력으로 측정합니다. 협약에 적힌 날짜까지 성과가 출시되었고 모든 기능 조직의 "완료" 줄이 사실이었는가? 프로젝트에 회의가 몇 번 열렸고, 그중 몇 번이 채널에 기록된 결정을 내렸는가? 인계 중 몇 건이 받는 기능 조직이 묻기 전에 채널에 공지되었는가? 회의가 적고, 회의마다 기록에 결정이 남은 채 제때 출시되는 프로젝트는 협업을 잘하는 것입니다. 기능 조직 쌍마다 주간 동기화 회의를 하면서 아무도 결정을 찾지 못하는 프로젝트는 값비싸게 조율하고 있는 것입니다.

출처: Microsoft Learn — Shared channels in Microsoft Teams; Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Translate a message in Microsoft Teams; Google Chat — Use Automatic Translation in Chat; Google Meet — "Take notes for me" in Google Meet; Slack — Pricing; Slack — Export your workspace data; Slack — Guide to AI features in Slack; Slack — Meeting agenda template (canvas); WhatsApp — How to export your chat history; WhatsApp blog — Introducing message translations. Microsoft Learn의 공유 채널 페이지는 2026년 11월에 확인했고, Teams 회의 노트 페이지, Slack 캔버스 템플릿 페이지, Google "Take notes for me" 페이지는 2026년 10월에, Teams 메시지 번역 페이지, Slack 요금·내보내기·AI 기능 페이지, Google Chat 번역 페이지, WhatsApp 페이지는 2026년 8월에 확인했습니다. 벤더는 시간이 지나면서 요금제, 기능, 지원 언어 목록을 바꿉니다. 최신 상태는 각 벤더의 페이지에서 확인하세요. 예시로 든 팀은 가상의 사례입니다.