표준 소프트웨어에 맞춰 만든 하나의 베이스 매뉴얼이 여러 하드웨어에 탑재되고, 그 파생 모델이 여러 지역에 출시되면서 지역마다 언어와 사양이 달라진다면, 첫 출시부터 수십 개의 파생 매뉴얼이 동시에 제작되어야 합니다. 그런데 무엇이 얼마나 달라졌고 매뉴얼에 무엇을 적용해야 하는지를 한꺼번에 알려주는 채널은 없습니다. 이 백서는 한샘글로벌이 15년 이상 운영해 온 자동차 인포테인먼트 매뉴얼 프로그램을 바탕으로, 그 파악과 반영을 어떻게 해내는지를 설명합니다.
목차
핵심 요약
- 변경 정보는 한 곳에서 오지 않습니다. 개선을 위해 계속 바뀌는 소프트웨어, 플랫폼에 새로 추가되는 차종, 시장별 규제 정보가 각기 다른 조직에서 자기 몫만 전달합니다.
- 연 4~5건이면 감당됩니다. 하나의 베이스가 여러 하드웨어와 여러 지역으로 갈라지면 소스 매뉴얼만 수십 종이 되고, 언어가 곱해진 완성본은 수백 종에 이릅니다.
- 매뉴얼은 개발이 어느 정도 끝나야 시작할 수 있고, 제품의 시장 출시 일정에 맞춰 끝나야 합니다. 시작도 끝도 문서팀이 정할 수 없습니다.
- 기술문서 제작팀에게 가장 힘든 구간은, 저작도 번역도 아닌 변경점 파악입니다. 짧은 기간에 수십 개 파생의 내용을 정확히 알아내야 합니다.
- 한 건의 파생에서 판단해야 할 변경점은 차종이 다르면 약 50건, 지역이 다르면 약 100건입니다. 변경점은 두 모습으로 나타납니다. 문서 곳곳에 흩어져 반영되는 변경과, 하나의 사실이 문서 전체로 번지는 변경입니다.
- CMS와 모듈화는 변경이 챕터나 단락 단위로 떨어질 때 작동합니다. 실제 파생의 변경은 그 경계를 지키지 않습니다.
- 변경점 찾기의 자동화도 오랜 기간 검토했습니다. 패턴이 정해진 구간은 자동화했지만, 핵심 구간은 대체되지 않았습니다.
1. 변경을 알려주는 하나의 채널은 없습니다
제품이 양산으로 들어서기까지, 그리고 출시된 뒤에도 소프트웨어는 개선을 위해 계속 바뀌고, 메인 소프트웨어 플랫폼이 적용되는 하드웨어와 차종은 늘어나고, 출시 시장도 늘어납니다. 그때마다 매뉴얼은 다시 만들어집니다. 전문을 다시 쓰지는 않습니다. 바뀐 요소만큼 베이스 매뉴얼을 기준으로 수정합니다.
문제는 앞서 전달받은 자료 대비 어디가 얼마나 달라졌는지, 그래서 매뉴얼에 무엇이 적용되어야 하는지를 알려주는 채널이 하나로 존재하지 않는다는 점입니다. 수정이 발생하는 채널마다 자기 조직에서 관리하는 변경 내용만 전달하기 때문입니다. 소프트웨어는 개발이 끝난 뒤에도 양산에 이르기까지 개선을 위해 계속 바뀌고, 개발 조직은 바뀔 때마다 그 내용을 전달합니다. 한편에서는 같은 플랫폼에 새로운 차종이 추가되고, 다른 한편에서는 시장별 인증과 규제 정보가 들어옵니다. 각각은 자기 관점에서 정확하지만, 어느 것도 매뉴얼의 어느 파트에 어떤 식으로 반영되어야 하는지는 말해 주지 않습니다.
기술문서 제작팀은 이 흩어진 정보를 모아서 수정 작업을 준비합니다. 파생 매뉴얼 제작의 실제 출발점이 여기입니다. 누가 정리해 준 목록을 받아 작업을 시작하는 것이 아니라, 여러 경로에서 오는 조각들을 맞춰 하나의 그림을 만드는 일부터 시작합니다.
이 역할은 사내에 문서팀을 둔 조직에도, 전문 서비스 회사에 맡긴 조직에도 똑같이 존재합니다. 기술 문서 파생 작업은 누가 수행하든 이 파악이 끝나야 다음 공정이 시작되기 때문입니다.
2. 연 4~5건과 수십 종의 차이
연간 발생하는 모델 변경이 4~5건이라면, 수정 요소가 다양하고 경로가 여럿이어도 파생 매뉴얼 제작은 그리 어렵지 않습니다. 담당자가 각 경로를 챙기고 기억으로 연결할 수 있는 규모이기 때문입니다. 많은 조직이 이 규모에서 출발하고, 그래서 이 일을 관리의 문제로 인식하지 않습니다.
상황이 달라지는 지점은 분명합니다. 표준 소프트웨어에 맞춰 제작한 하나의 베이스 매뉴얼이 여러 종류의 하드웨어에 탑재되고 — 예를 들어 같은 인포테인먼트 플랫폼이 여러 브랜드의 여러 차종에 실리면서 차종마다 반영해야 할 차이가 생기고 — 그렇게 파생된 모델이 출시되는 지역이 여럿이어서 지역별로 기능과 사양이 바뀌어 적용해야 한다면, 첫 출시부터 하나의 베이스에서 수십 개의 파생 매뉴얼이 동시에 제작되어야 합니다. 여기서 세는 단위를 구분할 필요가 있습니다. 플랫폼 매뉴얼에서 차종과 지역으로 갈라지는 소스 매뉴얼이 수십 종이고, 여기에 시장별 언어가 곱해지면 출시일까지 완결해야 하는 문서는 수백 종에 이릅니다.
그리고 첫 출시 이후에도 설계가 바뀌고 소프트웨어가 업데이트되면, 파생 매뉴얼은 또다시 수십 개가 제작됩니다. 한 번의 변경이 한 건의 작업이 아니라 수십 건이 되는 구조입니다. 정보가 흩어져 있다는 조건은 그대로인데, 그 조건 위에 규모가 얹히면서 같은 일이 전혀 다른 난이도가 됩니다.
3. 시간은 양쪽에서 조여옵니다
매뉴얼 제작은 제품 개발이 어느 정도 완료된 뒤에야 비로소 시작할 수 있습니다. 화면과 사양이 확정되지 않으면 무엇을 쓸지 정할 수 없기 때문입니다. 그리고 제품의 시장 출시 일정에 맞춰 완료되어야 합니다. 시작은 개발 진척이, 끝은 시장 출시 일정이 정합니다. 어느 쪽도 기술문서 제작팀이 정할 수 없습니다.
그 사이 구간에 수십 개의 파생 매뉴얼의 내용을 정확하게 파악하고, 언어별로 제작해 완료해야 합니다. 이 시간이 충분한 경우는 많지 않습니다. 게다가 그 구간 안에서도 소프트웨어 업데이트와 설계 변경이 예고 없이 발생하고, 그때마다 파악부터 다시 시작됩니다.
가장 힘든 구간은 저작도 번역도 아닙니다. 그 짧은 시간 안에 수십 개 파생 매뉴얼의 내용을 정확하게 파악하는 일입니다. 정리된 하나의 채널이 없기 때문에, 이 파악은 결국 문서를 제작해야 하는 팀의 몫으로 남습니다. 그리고 이것이 만만치 않습니다.
여기서 실패하면 뒤의 모든 공정이 흔들립니다. 파악이 늦으면 일정이 밀리고, 파악이 부정확하면 오류가 그대로 수십 개 파생과 수십 개 언어판으로 복제됩니다.
4. 파악해야 할 것이 실제로 어떤 모습인지
그렇다면 그 짧은 시간에 파악해야 하는 대상은 실제로 어떤 모습일까요. 한 건의 파생에서 판단해야 할 변경점은 생각만큼 많지 않습니다. 동일 플랫폼에서 차종이 달라지는 경우가 약 50건, 차종은 같고 지역이 달라지는 경우가 약 100건 수준입니다. 문제는 개수가 아니라 그 변경점들이 문서에 어떤 모습으로 적용되는가입니다. 실제 완성본을 대조해 보면 두 축은 전혀 다른 양상을 보입니다.
흩어진 변경
차종이 달라지는 경우, 변경점 수는 50건 남짓이지만 그것이 문서에 적용되는 지점은 훨씬 많습니다. 표기 규칙 하나가 바뀌면 문서 전반의 해당 표기가 모두 바뀌고, 사양 하나의 차이가 여러 문장의 조건 표기를 건드립니다. 실제 대조에서 변경이 적용된 지점은 문서 전체에 흩뿌려져 있었고, 그중 절반 가까이가 한 문장 또는 한 항목 수준이었습니다. 판단은 한 번이지만 반영은 수백 곳에서 이뤄집니다.
차종에 따라 버튼 하나의 유무가 문장 안의 표기를 바꿉니다. 장비 사양에 따라 같은 문장에서 조건 태그가 붙었다 떨어집니다. 시장 차이가 겹치면 라디오 규격이 바뀌고, 같은 영어 안에서도 미국식과 영국식 철자가 갈립니다. 제작 시점 사이에 UI 표기 규칙이 개정되면 대소문자 표기까지 문서 전체에서 달라집니다. 이런 변경은 목록으로 전달되지 않습니다. 찾아내야 합니다.
연쇄하는 변경
지역이 달라지는 경우는 판단해야 할 변경점이 약 100건으로 더 많습니다. 다만 시장에 따라 편차가 큽니다. 사양과 언어가 유사한 인접 시장끼리는 콘텐츠의 90%대 후반이 동일하지만, 규제와 지원 서비스가 크게 갈리는 시장 사이에서는 그 폭이 훨씬 벌어집니다. 중요한 것은 남은 차이가 흩어져 있지 않고 연쇄한다는 점입니다.
갈림의 출발점은 하나였습니다. 카 커넥티드 서비스(CCS)가 한 시장에서는 제공되고 다른 시장에서는 제공되지 않는다는 사실입니다. 이 사실 하나가 문서 전체로 번집니다. 해당 서비스 챕터가 빠지는 것으로 끝나지 않고, 그 서비스를 기반으로 하는 무선 업데이트·알림·원격 진단 챕터가 함께 빠지고, 사용자 프로필의 로그인 설명이 달라지고, 제품 사양표의 통신 모듈 항목까지 삭제됩니다.
파급은 상호참조까지 내려갑니다. 한 시장의 매뉴얼에는 문제 해결 섹션에 무선 업데이트 챕터를 참조하라는 안내가 있는데, 그 챕터가 없는 시장의 매뉴얼에서는 문서 반대편의 이 안내 문장까지 수정되어 있었습니다. 챕터 하나를 들어내면 그것을 가리키던 모든 문장을 찾아야 합니다. 하나라도 놓치면 존재하지 않는 챕터를 안내하는 문장이 남습니다.
시장의 차이는 기술 사양에 그치지 않습니다. 한쪽 시장의 매뉴얼에만 있는 기능이 있습니다. 그 지역의 종교 관행을 지원하는 기능, 반려동물 동승을 위한 모드처럼, 시장의 생활 방식에 맞춘 기능은 다른 시장 매뉴얼에는 아예 등장하지 않습니다.
콘텐츠가 같아도 조판은 다시 흐릅니다. 90%를 넘게 동일한 문서라도 편집과 검수는 전체를 다시 통과해야 합니다.
완성된 매뉴얼만 보면 이 작업은 문장 몇 개가 바뀐 결과로 보입니다. 그러나 그 몇 개를 찾아내기까지의 과정은 산출물에 남지 않습니다. 이 백서가 데이터를 공개하는 이유가 그것입니다.
정리하면, 파악해야 할 대상은 두 종류입니다. 목록에 없는 채로 흩어져 있어 찾아내야 하는 변경과, 출발점은 하나지만 어디까지 번지는지 따라가야 하는 변경입니다. 이 둘을 수십 개 파생에서, 정해진 기간 안에 동시에 해내야 합니다.
5. 모듈화만으로는 부족합니다
이 지점에서 흔히 나오는 답이 CMS입니다. 콘텐츠를 모듈로 관리하면 파생마다 필요한 것만 조립되고 번역도 자동으로 연결된다는 것입니다. 맞는 말입니다. 다만 전제가 있습니다. 변경이 챕터나 토픽, 최소한 단락이라는 단위로 떨어져야 하고, 그 단위의 경계가 표준으로 고정되어 있어야 합니다. 그래야 시스템이 무엇을 바꿔 끼울지 알 수 있습니다.
그러나 실제 현장은 다릅니다. 라인업이 다양하고 지역향 출시가 많은 B2C 제품군에서는 변경이 모듈 단위로 이루어지지 않는 경우가 많습니다. 앞 장에서 본 대조 결과가 그것을 보여줍니다. 판단해야 할 변경점은 50건 남짓이어도, 그것이 적용되는 지점은 문서 전체에 흩어져 있고 그중 절반 가까이가 한 문장 또는 한 항목 수준이었습니다. 한 문장 안의 단어 하나, 조건 태그 하나가 달라지는 변경 앞에서 모듈의 경계는 의미를 잃습니다. 흩어진 반영 지점은 모듈로 잘라도 그대로 남습니다. 시스템은 어느 모듈을 바꿔야 하는지 알려주지 않습니다. 그 모듈 안의 어디가 달라졌는지를 아는 것은 여전히 사람의 일이기 때문입니다.
실제로 이 유형의 문서를 오래 다루는 조직은 재사용 단위를 챕터보다 훨씬 아래로 내립니다. 문장 단위로 콘텐츠를 축적하고, 그 문장이 어느 모델과 어느 시장에서 어떻게 쓰였는지를 이력으로 관리합니다. 그렇게 해도 무엇을 그대로 쓰고 무엇을 고칠지에 대한 판단은 남습니다. 체계가 하는 일은 판단을 대신하는 것이 아니라, 판단해야 할 지점이 빠짐없이 드러나게 만드는 것입니다.
6. 자동화가 멈추는 지점
그렇다면 이 변경점 파악 작업을 자동화할 수는 없을까요. 한샘글로벌은 오랜 기간 이 질문을 붙들었습니다. 결론부터 말하면, 일부 구간은 자동화했고 핵심 구간은 아직 대체하지 못했습니다.
자동화가 잘 듣는 구간은 분명합니다. 이미 완료된 두 문서를 기계적으로 대조해 차이 후보를 뽑아내는 일, 단위 표기와 명칭 일관성을 검사하는 일이 그렇습니다. 규칙으로 표현되는 작업이고, 사람보다 기계가 빠르고 무엇보다 매번 같은 결과를 냅니다. 실제로 이런 검사는 도구가 수행합니다.
문제는 그 앞 단계, 무엇이 달라졌는지를 알아내는 구간입니다. 변경 정보의 상당 부분은 관련 조직들이 주고받는 커뮤니케이션에 담겨 있습니다. 한 달치를 모으면 수천 건에 이르고, 각 건에는 이전 대화 내용이 길게 따라붙습니다.
처음에는 그 과거 내용을 걷어내면 될 것으로 보았습니다. 그러나 걷어낼 수 없었습니다. 어떤 변경은 여러 차례 논의를 거친 끝에 이전 상태로 되돌려 달라는 결론에 이르는데, 그 되돌아갈 상태가 바로 걷어내려던 과거 내용 안에 있기 때문입니다. 과거 기록은 잡음이면서 동시에 유일한 근거였습니다.
담당자가 실제로 쓰는 판단 기준과 패턴을 도구에 입력해 보기도 했습니다. 결과는 후보 목록이 지나치게 넓어지는 것이었습니다. 검증해야 할 양이 원래 자료를 직접 확인하는 것보다 오히려 늘어났습니다. 정확도가 조금 부족한 정도가 아니라, 자동화의 결과물이 원래의 일보다 큰 일이 되어 버린 것입니다.
숙련된 담당자는 수천 건을 다 읽지 않습니다. 발신자가 누구인지, 어느 시점의 어떤 이슈인지를 알기 때문에 대부분을 열어 보지 않고 지나갑니다. 되돌려 달라는 요청이 오면 어느 시점의 어떤 상태를 말하는지 맥락으로 압니다. 자동화가 대체하지 못한 것은 판단의 정확도가 아니라, 보지 않아도 되는 것을 아는 능력이었습니다.
이 능력에는 이름이 필요합니다. 우리는 이것을 체인지 인텔리전스(Change Intelligence)라고 부릅니다. 여러 조직에서 흩어져 오는 신호 가운데 매뉴얼에 영향을 주는 것을 알아보고, 묻지 않으면 오지 않을 정보를 먼저 물어 끌어오고, 변경이 어디까지 미치는지를 가늠하는 역량입니다. 도구에 담기지 않고 사람에게 쌓입니다.
한 가지 덧붙일 것이 있습니다. 이 병목은 대개 문서 제작 쪽으로 넘어옵니다. 변경 정보를 만들어 내는 조직들은 각자 자기 몫을 정확히 전달했고, 그것을 하나로 맞추는 일은 자기 업무가 아니기 때문입니다. 구조적으로 자연스러운 귀결입니다. 다만 그 결과, 정보를 가장 적게 가진 쪽이 정보를 종합하는 일을 맡게 됩니다. 발신 조직에서는 한 줄이면 될 확인이, 받는 쪽에서는 수천 건을 뒤지는 일이 됩니다.
7. 그래서 무엇이 필요한가
한샘글로벌이 이같은 파생 매뉴얼 제작 프로그램을 운영하며 갖춘 것은 일곱 가지입니다. 순서는 앞에서 본 문제의 순서를 따릅니다. 흩어진 정보를 모으고, 짧은 시간에 파악하고, 파악한 것을 놓치지 않고 반영하는 순서입니다.
- 변경 신호를 먼저 찾습니다. 여러 조직에서 오는 변경 정보를 기다리지 않습니다. 개발 조직과 설계 조직 사이에 오가는 커뮤니케이션에서 매뉴얼에 영향을 주는 신호를 먼저 포착하고, 문의와 일정 리마인드를 선제적으로 보내며 정보를 끌어옵니다. 앞 장에서 말한 체인지 인텔리전스가 실제로 작동하는 자리입니다.
- 차이점 목록을 직접 만듭니다. 대상 모델의 최신 화면 전체를 입수해 베이스와 대조하고, 사양서·UI 스트링 자료·인증 현황을 교차 확인해 차이점 목록을 직접 만듭니다. 이 목록을 고객과 검토해 사양을 확정한 뒤에야 저작이 시작됩니다. 파악을 작업의 일부가 아니라 독립된 공정으로 둡니다.
- 확인 요청은 선별해서 보냅니다. 확보한 자료로 판단이 서는 변경은 판단해서 결정 사항으로 알리고, 자료만으로 확정할 수 없는 것만 확인을 요청합니다. 모든 변경을 물으면 확인 부담이 고객에게 그대로 넘어가고, 회신이 늦어져 결국 일정이 밀립니다. 무엇을 묻지 않아도 되는지를 아는 것이 무엇을 물어야 하는지를 아는 것만큼 중요합니다. 요청을 보낼 때는 상대가 판단만 하면 되도록 만듭니다. 우리의 판단과 그 근거, 비교 대상이 한자리에 놓여 있어야 합니다. 받은 쪽이 근거를 다시 찾아봐야 한다면 그 요청은 확인이 아니라 또 하나의 숙제가 됩니다.
- 변경 이력을 남깁니다. 모든 변경을 문서에 기록해 저작, 편집, 현지화, 고객 확인까지 추적 가능하게 유지합니다. 확정 이전의 협의도 같은 단위에 쌓입니다. 한 변경점을 두고 여러 차례 왕복이 오가는 경우, 그 왕복이 시간순 대화가 아니라 해당 변경점 자리에 누적되므로, 나중에 이전 결정으로 되돌려야 할 때 그 결정이 어디 있는지 찾을 필요가 없습니다. 무엇이 왜 바뀌었는지가 남아야 다음 파생이 그 위에 얹히고, 담당자가 바뀌어도 이력이 남습니다.
- 파급을 끝까지 추적합니다. 챕터가 삭제되거나 이동하면 그것을 가리키던 모든 참조를 찾아 정리합니다. 연쇄하는 변경에서 가장 자주 누락되는 지점입니다.
- 문장 단위로 자산을 관리합니다. 문장 단위로 축적된 번역 자산이 다음 파생으로 상속되도록 정렬 상태를 유지합니다. 막판 수정 이후에도 이 정렬이 유지되어야 자산이 자산으로 남습니다.
- 다층 검수로 걸러냅니다. 전담 검수와 자동 검사가 단위 오류, 조작부 명칭 불일치, 깨진 상호참조처럼 작지만 치명적인 오류를 잡아냅니다. 자동화의 목적은 속도가 아니라 재현성입니다.
일곱 가지 중 앞의 하나는 사람에게 축적된 역량이고, 나머지는 문서화된 프로세스입니다. 둘 중 하나만으로는 이 일이 굴러가지 않습니다. 프로세스가 없으면 판단은 사람마다 달라지고, 이력이 남지 않아 다음 파생이 매번 처음부터 시작됩니다. 반대로 프로세스만 있고 변경을 알아보는 눈이 없으면, 정작 반영해야 할 것이 목록에 오르지 않은 채로 공정이 진행됩니다. 체계는 판단이 이뤄져야 할 자리를 만들고, 사람은 그 자리에서 판단합니다.
8. 사람의 암묵지가 필요한 공정
AI 시대에 특정 집단에 축적된 암묵지는 폐기 대상인 용어가 되고 있습니다. 그러나 수십 건의 파생 매뉴얼을 제작하는 현장은 다릅니다. 변경 정보가 끊임없이 오가는 커뮤니케이션 속에서 매뉴얼에 반영되어야 할 것을 캐치하고, 구조화하고, 적용하는 작업은 AI나 자동화가 적용되기 어렵습니다. 이 현장은 사람의 암묵지로 움직입니다. 다만 암묵지만으로 움직인다는 뜻은 아닙니다. 앞 장의 프로세스가 무엇을 언제 확인해야 하는지를 정해 두기 때문에, 암묵지가 엉뚱한 곳이 아니라 필요한 지점에서 쓰입니다.
그리고 이 암묵지의 효과적인 적용이 15년 이상 축적된 콘텐츠와 번역 메모리를 비로소 쓸 수 있게 해줍니다. 어떤 콘텐츠를 불러와 어떻게 변형할지, 어떤 번역 자산을 신뢰하고 어떤 부분을 다시 검증할지는 제품과 시장과 문서의 이력을 아는 전문가의 판단 안에서만 가치를 만듭니다.
그래서 이 유형의 작업에서 라이터에게 요구되는 것은 문장력이 아닙니다. 글쓰기의 자유도는 오히려 매우 낮습니다. 요구되는 것은 흩어진 변경을 빠짐없이 찾아내는 탐지력과, 연쇄하는 변경을 끝까지 따라가는 추적력입니다. 이 두 역량이 수십 개 파생과 수십 개 언어판의 무결점을 실제로 지켜 냅니다.
9. 제작 대행이 아니라 문서 운영
이런 문서는 건별 발주와 납품이라는 관계로는 잘 굴러가지 않습니다. 이번 파생의 변경을 판단하려면 지난 파생의 이력을 알아야 하고, 어느 조직에 무엇을 물어야 하는지도 알아야 합니다. 그 지식은 매번 다른 담당자에게 넘어가는 순간 손실됩니다. 제작 건마다 담당이 바뀌면 매번 처음부터 파악하는 비용이 발생하고, 그 비용은 대개 일정으로 청구됩니다. 한샘글로벌은 1990년 한국 최초의 테크니컬 라이팅 기업으로 출발해 국제 문서 표준에 따라 제품 매뉴얼을 백지에서부터 개발했고, 그 위에 수십개 언어로 현지화하는 작업을 진행해 왔습니다. 이 순서가 말해 주듯, 파생을 통제하는 일은 번역이 아니라 문서 엔지니어링이고 번역은 그 한 부분입니다.
10. 귀사의 문서팀에게 의미하는 것
하나의 베이스에서 여러 파생이 갈라지고, 그 전부가 같은 출시일을 맞춰야 하는 조직이라면 지금의 기술 문서 파생 작업을 두고 다음 질문에 답해 보실 수 있습니다.
- 이번 파생에서 무엇이 달라지는지, 착수 전에 목록으로 확인할 수 있습니까?
- 그 목록은 여러 조직에서 온 정보를 모아 만든 것입니까, 아니면 한 경로에서 온 것만 반영한 것입니까?
- 챕터 하나를 삭제했을 때 그것을 가리키던 문장이 몇 개인지 알 수 있습니까?
- 담당자가 바뀌어도 같은 품질과 같은 속도가 유지됩니까?
답이 특정 개인의 기억에 걸려 있다면, 그것이 지금의 리스크입니다.
대표 매뉴얼 한 종과 그 파생본 한 종을 비교해 보세요. 두 문서를 실제로 대조해 보면 변경이 어떤 모습으로 분포하는지, 어디에 누락 위험이 있는지가 드러납니다. 이 백서에 실린 데이터가 그렇게 얻은 결과입니다.