근무시간 외 고객지원에 관한 논의가 한 시간 동안 맴도는데, 정작 서로 다른 질문에 답하고 있을 수 있습니다. 한 사람은 더 빠른 응답을 주장하고, 다른 사람은 직원의 업무 부담을 걱정하며, 또 다른 사람은 ‘긴급’의 정의를 분명히 하자고 합니다. 세 가지 모두 중요하지만, 시간순 회의록으로만 남기면 하나의 논쟁이 진전 없이 이어진 것처럼 보일 수 있습니다.
다이얼로그 매핑(Dialogue Mapping)은 대화의 구조를 보여줍니다. 질문, 가능한 답, 그리고 각 답을 지지하거나 반대하는 이유를 연결합니다. 참여자들이 앞서 나온 모든 발언을 기억해야 하는 대신, 지금 분명히 하고 싶은 쟁점을 지도에서 짚을 수 있습니다.

다이얼로그 매핑은 회의에 무엇을 더하나요?
제프 콩클린(Jeff Conklin)의 다이얼로그 매핑은 사람들이 이야기하는 동안 진행자가 갱신하는 공유 화면을 사용합니다. 표기법의 바탕은 IBIS(Issue-Based Information System, 쟁점 기반 정보 시스템)입니다. 질문은 쟁점을, 아이디어는 가능한 답을 나타내며, 논거는 그 아이디어를 지지하거나 반대합니다.
진행자는 발언을 듣고 간결한 표현을 제안한 뒤, 말한 사람의 뜻을 제대로 담았는지 확인합니다. 참여자들이 도식의 순서대로 말할 필요는 없습니다. 앞선 대안을 논의하는 중에도 새로운 질문이 나올 수 있습니다.
대화 지도는 선택을 탐색하는 동안 판단의 이유를 기록합니다. 의사결정 기록부는 중요한 선택이 내려졌거나 의도적으로 보류됐을 때 그 결정과 이유를 남깁니다. 둘을 연결할 수는 있지만, 지도에 대안을 표시했다고 그 실행이 승인되는 것은 아닙니다.
답을 모으기 전에 질문부터 정리하세요
가상의 소프트웨어 고객지원팀이라면 ‘담당자가 근무하지 않는 시간에 들어온 고객의 긴급 요청을 어떻게 처리할까?’에서 시작할 수 있습니다. 특정 방식이 이미 옳다고 가정하지 않고 서비스 기대 수준, 요청 전달, 인력 배치를 논의할 여지가 생깁니다.
‘왜 당번제를 도입하지 않나요?’는 더 좁은 질문입니다. 제안한 답을 옹호하거나 거부하는 방향으로 대화를 구성합니다. 당번제가 여러 선택지 중 하나라면, 더 넓은 질문 아래의 아이디어 노드에 놓으세요.
참여자들은 자신들이 어떤 결정을 내릴 수 있는지도 알아야 합니다. 이 사례의 회의는 고객지원 관리자를 위해 선택지를 탐색하는 자리입니다. 기존 고객과의 약속은 여전히 제약 조건이며, 워크숍에서 이를 조용히 바꿀 수는 없습니다. 지원 범위를 줄인 대안을 제시하기 전에 관련 약정을 확인해야 합니다.
정의가 질문에 영향을 준다면 계속 보이게 둡니다. ‘긴급’은 서비스 중단, 핵심 업무가 막힌 상태, 단순히 강한 표현의 메시지 중 어느 것을 뜻할 수도 있습니다. ‘다음 근무시간 전까지 조치해야 하는 경우는 무엇인가?’라는 별도 질문을 추가하세요. 그 답에 따라 검토할 대안이 달라질 수 있습니다.
IBIS 요소를 일관되게 사용하세요
CogNexus의 IBIS 실무 안내서는 질문, 그 질문에 답하는 아이디어, 아이디어에 연결되는 찬성·반대 논거를 구분합니다. 질문, 아이디어, 논거 어디에서든 새로운 질문이 나올 수 있습니다. 화살표는 응답의 대상인 노드를 향하도록 그립니다. 즉, 아이디어에서 질문으로, 찬성·반대 논거에서 아이디어로, 새 질문에서 그 질문을 이끌어 낸 노드로 연결합니다. 복잡한 시각적 스타일보다 이러한 관계가 더 중요합니다.
| 요소 | 표현 예시 | 이 표현의 역할 |
|---|---|---|
| 질문 | 담당자가 근무하지 않는 시간의 긴급 요청을 어떻게 처리할까? | 모임이 탐색하는 쟁점을 이름 붙임 |
| 아이디어 | 내부 담당자가 돌아가며 대응한다 | 가능한 답 하나를 제시함 |
| 찬성 논거 | 담당자가 제품의 맥락을 알고 있다 | 해당 대안을 지지하는 이유를 제시함 |
| 반대 논거 | 당번제로 팀의 근무시간 외 업무가 늘어난다 | 해당 대안에 대한 반론을 제시함 |
| 추가 질문 | 어떤 경우에 제품 전문성이 즉시 필요한가? | 찬성 논거에서 나온 추가 조사 문제를 제시함 |
물음표, 아이디어 표시, 분명한 더하기·빼기 기호를 사용해 색상 없이도 역할을 읽을 수 있게 하세요. 노드 하나에는 생각 하나만 담습니다. ‘당번제는 비용이 많이 들고 사람들이 싫어할 것이다’에는 근거와 대응이 서로 다를 수 있는 두 가지 우려가 들어 있습니다.
찬성 논거라고 해서 자동으로 사실이 되는 것은 아닙니다. ‘외부 서비스가 더 저렴할 것이다’는 의미 있는 비교를 하기 전까지는 참여자의 주장입니다. 해당 대안에 주장을 연결한 뒤 비용에 관한 질문이나 확보한 근거의 참조를 추가하세요. 진행자가 요약한 표현이 곧 그 주장을 인정한다는 뜻이 되지 않도록 합니다.
고객지원의 세 가지 대안을 살펴보세요
팀은 세 가지 방식을 제안합니다. 내부 담당자가 돌아가며 대응하는 방식, 외부 서비스가 요청을 접수·분류하는 방식, 그리고 기존 약정이 허용하는 경우에 명확한 접수 경로를 두고 근무시간 중에 답하는 방식입니다. 이는 설명용 사례의 가능한 답이며 모든 고객지원 조직에 대한 권고는 아닙니다.
대안 1: 내부 담당자가 돌아가며 대응하기
제품 전문가는 내부 담당자가 어려운 사례를 이해할 수 있다고 말합니다. 그 이유를 당번제 아이디어 옆에 놓으세요. 다른 참여자는 근무시간 외 업무가 늘어난다고 지적합니다. 이를 막연한 ‘인력’ 가지 아래 숨기지 말고 반대 논거로 기록합니다.
업무 부담에 관한 우려는 ‘팀이 현실적으로 유지할 수 있는 대응 가능 시간은 어느 정도인가?’라는 새 질문을 만듭니다. 이는 ‘고객에게 더 빠른 도움이 필요한가?’와는 다른 대화입니다. 두 질문을 모두 보이게 두면 한 질문이 다른 질문의 답으로 오인되는 것을 막을 수 있습니다.
대안 2: 외부 서비스에 접수·분류 맡기기
한 참여자는 외부 서비스가 긴급 사례와 일반 질문을 구분할 수 있다고 제안합니다. 들어오는 모든 메시지를 내부 전문가에게 맡기지 않고도 일차 대응 범위를 확보할 수 있다는 점이 기대되는 장점입니다. 반론은 제품에 익숙하지 않은 담당자가 특이한 문제를 잘못된 곳으로 전달할 수 있다는 것입니다.
‘제공업체가 상위 담당자에게 넘겨야 할 사례를 얼마나 정확히 알아볼 수 있을까?’를 질문으로 기록하세요. 나중에 실제 예시를 제공업체와 검토할 수는 있지만, 지도에서 그 역량이 이미 입증된 것처럼 표현하면 안 됩니다.
대안 3: 접수 경로와 응답 시간 명확히 하기
이 대안은 즉각적인 응답이 필요하지 않은 사례의 기대 수준을 분명히 할 수 있습니다. 그러나 해당하는 긴급 사례를 더 빨리 해결하기로 한 약속까지 충족하지는 못합니다. 그 반론을 대안에 붙이고 실제 서비스 의무에 관한 질문과 연결하세요.
논의가 진행되면 외부 접수와 좁게 정의한 내부 대응 경로를 결합할 수도 있습니다. 진지하게 검토할 제안이 됐다면 새로운 아이디어로 추가하세요. 앞선 대안은 조용히 덮어쓰지 마세요. 그 대안들의 논거가 결합안이 나온 이유를 설명합니다.
어느 쪽도 편들지 않고 이견을 기록하세요
누군가 ‘그건 절대 안 된다’고 말하면 어떤 조건에서 무엇이 안 되는지 물어보세요. ‘담당자가 사례 분류에 필요한 정보에 접근할 수 없다’처럼 정리할 수 있습니다. 추가하기 전에 다시 읽어 주세요. 발언자는 접근 자체가 아니라 접근 시점에 관한 우려였다고 바로잡을 수도 있습니다.
두 사람이 어떤 주장에 이견을 보이면 그 차이를 명시합니다. 한 사람은 정말 긴급한 요청은 거의 없다고 생각하고, 다른 사람은 힘들었던 주말이 여러 번 있었다고 기억한다고 가정해 보세요. 더 자신 있게 말한 사람의 기억을 택하는 대신 ‘최근 요청 기록은 무엇을 보여주는가?’라는 질문을 추가합니다.
더하기와 빼기의 개수를 점수로 세지 마세요. 약한 이유 네 개가 반드시 지켜야 할 제약 하나보다 우선하지는 않습니다. 지도는 이유를 검토하게 돕는 것이지, 서로 다른 이유를 같은 가치의 표로 바꾸는 도구가 아닙니다.
모든 문장을 기록하려 하지도 마세요. 반복된 내용은 기존 노드를 가리킬 수 있고, 실질적으로 다른 조건은 별도 메모가 필요합니다. 진행자의 역할은 참여자들이 자신의 판단 과정을 알아볼 수 있게 유지하는 것입니다. 장식용 연결선을 붙인 녹취록을 만드는 것이 아닙니다.
Boardmix에서 공유 IBIS 지도를 만드세요
Boardmix를 열고 빈 캔버스 왼쪽에 핵심 질문을 놓습니다. 오른쪽에는 세 고객지원 대안의 아이디어 상자를 하나씩 추가합니다. 각 아이디어 주변에 찬성·반대 이유를 적을 공간을 충분히 남겨 두세요.
- 시작 노드에 물음표와 탐색할 질문의 정확한 문구를 적습니다. 논의 내내 보이게 유지하세요.
- 각 아이디어를 그 질문에 연결합니다. ‘내부 당번제’, ‘외부 접수·분류’처럼 짧고 중립적인 이름을 사용합니다.
- 관련 아이디어 옆에 +와 −를 표시한 별도 메모를 추가합니다. 가까이 놓였다는 사실만으로 의미를 짐작하지 않도록 각 이유를 해당 아이디어에 연결하세요.
- 내부 당번제의 논거 옆에 ‘어떤 경우에 전문성이 즉시 필요한가?’라는 질문을 추가합니다. 어떤 주장 때문에 나온 질문인지 연결선으로 표시합니다.
- 관련 주장 가까이에 근거 문서나 짧은 참조 표시를 둡니다. 모르는 값은 추측으로 채우지 말고 질문으로 남깁니다.

실시간 논의에서는 한 사람이 보드를 갱신하고, 참여자들은 말로 표현을 바로잡을 수 있습니다. 동시 편집 때문에 판단 과정을 따라가기 어려워지지 않도록 미리 합의하세요. 도형과 연결선은 사람이 직접 관리하는 지도를 이룹니다. 그림 자체가 IBIS 규칙을 강제하거나 논거를 자동 평가하지는 않습니다.
다음 질문에 근거가 필요하다면 지도를 더 그리기 전에 확인하세요
이 사례에서 팀은 어떤 요청에 실제로 근무시간 외 전문 대응이 필요한지, 기존 약속이 무엇을 요구하는지 모르면 대안을 비교할 수 없다는 것을 발견할 수 있습니다. 대화를 더 한다고 그 사실이 생기지는 않습니다. 두 질문을 보이게 남기고 지도로 왜 중요한지 설명하세요.
근거가 돌아오면 관련 주장에 붙이고 대안을 다시 검토할 수 있습니다. 이후 고객지원 관리자가 운영 방식을 선택하면 결정을 기록하고 판단 근거를 연결하세요. 나중에 검토하는 사람이 왜 그 선택을 했는지, 아직 해결되지 않은 어떤 우려를 감수했는지 모두 알 수 있어야 합니다.