PDF 매뉴얼의 역발상: 문서 대신 시스템

백오피스 구축이 끝나면 마지막 산출물로 운영 매뉴얼 PDF가 하나 따라옵니다. 화면 하나하나를 캡처하고 번호를 매겨 설명을 붙인 문서입니다. 그리고 이 PDF는 인수인계 자리에서 한 번 열리고, 그 뒤로는 거의 열리지 않습니다. 화면이 개편될 때마다 캡처를 새로 찍어 넣는 사람이 없기 때문입니다.

매뉴얼을 만들고 나눠주면 끝난다는 생각

이 PDF가 무용해지는 원인을 "안 읽어서"로 보면 다음 대책이 안 나옵니다. 진짜 원인은 매뉴얼이 화면과 완전히 분리된 별도의 산출물이라는 데 있습니다. 화면 코드가 바뀌어도 매뉴얼 파일은 자동으로 따라오지 않고, 그걸 갱신할 책임을 누가 지는지도 계약서 어디에도 안 적혀 있는 경우가 많습니다.

이 방치가 실제로 비용이라는 것은 연구로도 확인됩니다. ACM 응용컴퓨팅 심포지엄에 발표된 리서치는 132건의 유지보수·개선 작업을 18개월간 추적했는데, 그중 문서화 부채(documentation debt)가 있던 작업은 프로젝트 최초 개발 공수 대비 약 47%의 추가 유지보수 노력과 약 48%의 추가 비용을 발생시켰습니다(ACM SAC 2016). 문서가 낡는 것을 방치하는 것과 아예 안 만드는 것 사이에 큰 차이가 없다는 뜻입니다.

PDF를 화면으로 옮기는 것만으로는 안 되는 이유

여기서 흔히 나오는 대안이 "그러면 PDF를 웹 페이지로 만들자"입니다. 저는 이것만으로는 문제가 안 풀린다고 봅니다. 매뉴얼을 PDF에서 웹으로 옮겨도, 그 웹 페이지 역시 화면 코드와 분리된 별도의 문서라면 갱신될 이유가 여전히 없습니다. 형태를 바꾸는 것과 갱신 구조를 바꾸는 것은 다른 일입니다.

문서를 쓰지 않고 문서를 만드는 구조를 만든다

매뉴얼 문제를 대할 때 흔히 "어떻게 하면 더 친절하고 이해하기 쉬운 문서를 쓸까"를 고민합니다. 저는 이 질문 자체가 틀렸다고 봅니다. 아무리 잘 쓴 문서도 화면이 바뀌는 순간 낡기 시작하고, 그 낡음을 막을 방법은 글솜씨에 없습니다. 진짜 물어야 할 질문은 "누가 이 설명을 언제 갱신하는가"이고, 이 질문에 답하려면 문서 한 편을 잘 쓰는 게 아니라 그 문서가 갱신되는 구조 자체를 만들어야 합니다.

이 역발상의 핵심은 설명을 별도 파일이 아니라 화면 자산의 데이터로 붙이는 데 있습니다. SI 모듈화를 다룬 글에서 화면을 PAGE의 패턴 단위로 등록하는 과정을 설명했습니다. 화면 하나가 패턴으로 등록될 때 그 패턴에는 이름, 태그, 소스, 데모, 문서 ID가 같이 붙습니다. 이 목록에 "이 화면을 어떻게 쓰는가"라는 설명 한 항목을 더하면, 그 설명은 더 이상 독립된 문서가 아니라 화면 자산의 일부가 됩니다.

이렇게 만들면 두 가지가 자동으로 따라옵니다. 첫째, 화면이 그 패턴을 계속 쓰는 한 설명도 계속 유효합니다. 둘째, 화면이 그 패턴에서 벗어나게 고쳐지면 그 사실 자체를 시스템이 감지해 "이 설명은 확인이 필요합니다"라고 표시할 수 있습니다. 사람이 매뉴얼을 기억해서 고치는 대신, 화면과 설명이 어긋나는 순간을 시스템이 대신 찾아 주는 구조입니다. 문서를 쓰는 사람을 더 부지런하게 만드는 대신, 게을러도 낡음이 조용히 숨지 않는 구조를 만드는 쪽이 더 오래간다고 저는 봅니다.

화면 안에 사는 가이드가 다르게 동작하는 방식

이 구조에서 가이드는 위치도 달라집니다. 파일을 찾아 열 필요 없이 화면의 "?" 버튼이나 도움말 아이콘을 누르면 지금 보고 있는 그 화면의 설명이 바로 뜹니다. 사용자가 매뉴얼을 찾아가는 것이 아니라 매뉴얼이 사용자가 있는 곳으로 옵니다.

이 방식이 실제로 문의를 줄인다는 근거도 있습니다. 가트너는 AI를 포함한 자동화된 대응이 고객 문의의 45% 이상을 처리한다고 발표했고, 젠데스크의 2026년 CX 트렌드 데이터는 기업 고객 지원 조직의 1차 문의 처리율 중앙값을 41.2%로, 상위 25%를 58.7%로 보고했습니다(두 수치 모두 eesel의 정리를 통해 재인용). 다만 같은 자료가 지적하듯 이런 수치는 업체마다 "처리"를 다르게 정의해서 벤더 발표 자료(30~60%)와 독립 설문조사(10~25%) 사이에 세 배 가까운 차이가 납니다. 저는 이 격차 자체가 중요한 정보라고 봅니다. 화면 안에 붙은 도움말이 문의를 줄이는 방향은 분명하지만, 정확히 몇 퍼센트인지는 그 조직이 직접 재기 전에는 벤더의 숫자를 그대로 믿을 수 없습니다.

가이드가 담을 수 있는 세 가지 형태

화면 안에 사는 가이드도 형태는 여러 가지일 수 있습니다. 가장 가벼운 형태는 항목별 툴팁입니다. 입력 칸이나 버튼에 마우스를 올리면 그 항목 하나에 대한 설명이 뜨는 방식이고, 만들기는 쉽지만 화면 전체를 처음 보는 사람에게는 도움이 덜 됩니다. 다음은 단계별 투어입니다. 화면에 처음 들어왔을 때 순서대로 화살표와 설명을 띄우며 흐름을 안내하는 방식이고, 신입 직원의 첫 사용에는 효과적이지만 매번 뜨면 숙련된 직원에게는 방해가 됩니다. 마지막은 검색 가능한 도움말 패널입니다. 화면 옆에 접어 둔 패널을 펼치면 그 화면과 관련된 설명 전체를 검색해 볼 수 있는 방식이고, 세 형태 중 만드는 비용이 가장 크지만 운영 중 예외 상황을 물을 때 가장 쓸모가 있습니다.

저는 이 셋을 하나만 고르는 문제로 보지 않습니다. 화면의 복잡도와 그 화면을 얼마나 자주 쓰는 직원인지에 따라 셋을 섞어야 한다고 봅니다. 매일 쓰는 단순한 화면은 툴팁 정도로 충분하고, 어쩌다 한 번 쓰는 복잡한 화면(예를 들어 월말에만 여는 정산 화면)은 투어와 검색 패널이 같이 필요합니다. 다만 형태가 무엇이든, 그 내용이 화면 자산에 붙어 있지 않으면 앞서 말한 낡는 문제는 그대로 남습니다.

이 화면 가이드가 제품이 되는 조건

여기까지는 한 고객사의 매뉴얼 문제입니다. 이걸 제품화한다는 것은, 이 가이드 모듈을 그 고객사 하나만이 아니라 비슷한 백오피스를 쓰는 여러 고객사에 같이 붙일 수 있어야 한다는 뜻입니다. 로그인 화면, 발주 승인 화면처럼 PAGE에 이미 패턴으로 있는 화면이라면, 그 패턴을 쓰는 다른 고객사에도 기본 가이드를 그대로 붙이고 그 회사만의 예외 부분만 덧붙이면 됩니다.

이 지점에서 앞선 SI 모듈화 글의 논지가 그대로 다시 적용됩니다. 화면의 몇 퍼센트가 공통 패턴이었는지 재는 것처럼, 가이드도 몇 퍼센트가 패턴에서 그대로 오고 몇 퍼센트가 고객사 고유의 설명인지를 나눠야 합니다. 전부 공통으로 만들면 그 회사만의 업무 흐름을 못 담고, 전부 개별로 만들면 다시 PDF 때와 같은 문제, 즉 아무도 갱신 책임을 안 지는 문서가 하나 더 생깁니다.

이 아이디어가 틀릴 수 있는 지점

이 방식에도 전제가 있습니다. 화면이 애초에 패턴 단위로 만들어져 있어야 가이드도 패턴 단위로 붙습니다. 처음부터 화면마다 따로 짠 프로젝트라면, 가이드도 화면마다 따로 만들어야 하고 그러면 PDF와 비용 구조가 크게 다르지 않습니다. 그래서 저는 이 아이디어가 모듈화된 화면 자산이 이미 있는 조직에서만 온전히 성립한다고 봅니다. 모듈화 없이 가이드 화면만 먼저 만들면, 결국 화면 개편 때마다 다시 손봐야 하는 또 하나의 산출물이 늘어날 뿐입니다.