같은 품목과 수량이 들어 있는 표라도 누구에게 왜 보내느냐에 따라 문서의 역할이 달라진다. 이 작업에서는 매입처에 보내는 문서를 거래명세서라고 부르던 흐름을 다시 살피게 됐다. 공급처에 보내는 것은 출고를 요청하는 문서이고 실제 거래명세서는 공급처가 보내 준다는 지적이었다. 나는 이 대목을 단순한 이름 수정으로 읽지 않는다. 프로그램의 용어가 회사의 실제 일하는 방식과 맞아야 직원과 대표가 같은 상태를 이해할 수 있기 때문이다.
제목은 문서가 증명하는 범위를 말한다
발주·출고요청서는 상대에게 무엇을 보내 달라고 요청한다. 그 문서를 만들었다고 물건을 받았거나 매입 금액을 확정한 것은 아니다. 반면 공급처에서 받은 거래명세서는 실제 내용과 대조할 원본이다. 내부에서 만드는 매입 내역은 또 다른 기록이다. 서로 비슷한 표를 사용하더라도 같은 이름을 붙이면 요청, 증빙, 내부 기록의 차이가 사라진다.
그래서 보관된 표시 코드에는 문서 종류에 따라 제목과 상대 명칭, 계좌와 서명란의 유무를 나누는 규칙이 있다. 공급처에 보내는 요청서에 우리 입금계좌나 인수 서명을 무조건 넣을 이유는 없다. 기존 서식이 있으니 그대로 쓰는 편리함보다 받는 사람이 어떤 행동을 해야 하는지 먼저 생각해야 한다. 출력물은 프로그램 바깥에서도 읽히므로 화면의 도움말에만 의미를 맡길 수 없다.
내부 코드와 사용자에게 보이는 말을 분리했다
직원이 사용하던 출하 문서를 납품확인서로 부르고 싶다는 요청도 있었다. 여기서 표시 이름을 고친다고 저장된 전표 종류나 과거 연결을 전부 다른 값으로 바꿔야 하는 것은 아니다. 보관된 구현은 내부 종류를 유지하면서 화면과 출력의 제목을 바꾸는 경로를 보여 준다. 회사의 말에 맞추는 수정이 기존 기록의 정체성을 바꾸지 않도록 책임을 나눈 것이다.
이런 구분이 없으면 제목 한 줄을 고치려다 검색 조건, 보고서 분류와 연결 문서까지 바뀔 수 있다. 나는 용어를 수정할 때 어디에서 읽는지 목록부터 적는 편이 좋다고 본다. 작성 화면, 목록, 상세, 인쇄, 이미지와 복사 글이 같은 문서를 다르게 부르면 직원은 어느 것이 최신인지 헷갈린다. 표시 계약을 공유하면 수정 범위와 빠뜨린 지점도 확인하기 쉬워진다.
복사와 전달 완료는 다른 행동이다
요청서 이미지를 복사했다는 사실로 업체에 전달했다고 기록하면 안 된다. 직원이 붙여넣기 전에 다른 내용을 복사했을 수도 있고 메시지를 보내지 않았을 수도 있다. 파일을 내려받는 일도 같다. 프로그램이 실제로 수행하는 일이 클립보드 준비라면 버튼은 그 일을 설명해야 한다. 외부 전송을 하지 않는데 발송 완료라고 안내하면 사용자의 다음 판단을 잘못 이끈다.
따라서 준비와 저장, 확정과 실제 전달 확인을 나누는 편이 좋다. 클릭 횟수만으로 외부 업무의 완료를 추정하지 않고, 전달을 확인하는 사람이 별도 표시를 남길 수 있다. 대표가 현황을 볼 때도 문서 준비가 끝난 건과 실제 업체가 요청을 받은 건을 구별할 수 있어야 한다. 문구를 쉽게 만드는 일은 짧게 쓰는 데서 끝나지 않고 버튼의 약속과 실제 동작을 맞추는 작업이다.
회사의 말을 존중하면서 모호함은 줄인다
업무에서 오래 쓰던 말은 바꾸기 어렵다. 개발자가 정확한 용어를 정해 일방적으로 덮는 방식도 적절하지 않다. 어떤 상황에서 누가 그 말을 쓰고, 그 말을 들으면 무엇이 끝났다고 이해하는지 확인해야 한다. 같은 단어가 요청과 확정 두 의미로 쓰인다면 제목이나 부가 설명에서 차이를 드러낼 수 있다. 회사에 맞춘 프로그램은 회사의 언어를 배우되 모호한 상태를 그대로 늘리지 않아야 한다.
검토용 합성 문서를 만들어 고객, 공급처, 내부 직원의 자리에서 각각 읽어 보자. 받는 사람이 해야 할 일, 금액의 의미, 전달 여부와 수령 여부가 설명되는지 살핀다. 이번 글은 선택한 대화와 표시 코드, 당시 변경 기록을 근거로 작성했다. 실제 업체에 문서를 보내거나 출력을 다시 시험한 결과는 아니다. 기능을 덜고 더하는 맞춤 제작에는 이처럼 문서의 이름과 버튼 한 문장을 회사의 실제 흐름에 맞추는 일도 포함된다.