29장. 행정 서류를 안전하게 처리하는 법

행정 양식에서는 서식이 곧 요구사항이고 채워 넣은 값은 어느 정본에서 왔는지 밝힐 수 있어야 한다. 기관이 배포한 한글 양식은 원본과 서식을 보존한 채 읽고 채우고 서명하고 검증해 제출본으로 관리한다. 서류 한 건이 끝났을 때 남는 것은 접수 기록, 값과 출처의 대응표, 작업 사본, 검증 기록, 제출 package 다섯 가지이고 다섯 가지가 남아야 같은 요청이 반년 뒤에 다시 왔을 때 처음부터 다시 하지 않는다. 메일함에 첨부파일이 하나 들어온다. 기관이 배포한 한글 양식이고 개인 신상을 적는 칸과 최근 연구 실적을 적는 칸이 한 문서 안에 섞여 있으며 서식을 바꾸면 반려된다는 안내가 붙어 있다. 마감은 사흘 뒤이고 비슷한 양식을 반년 전에도 채운 기억이 있지만 그때 무엇을 어디서 가져다 썼는지는 남아 있지 않다. 아래 서류는 앞선 장들과 같은 합성 사례이며 개인 신상 항목과 연구 실적 항목이 한 양식에 섞여 있고 서식을 바꾸면 반려된다는 성질만 실제 운영에서 일반화한 것이다. 실제 양식 이름, 기관 이름, 사업 이름, 개인 항목의 실제 값은 이 책에 싣지 않는다. 행정 서류가 다른 문서와 다른 점은 두 가지다. 하나는 서식이 요구사항의 일부라는 것이어서 표의 칸을 합치거나 행을 늘리는 순간 내용과 무관하게 반려된다. 그래서 원본을 그대로 둔 작업 사본에서 지정된 칸만 채운다. 다른 하나는 값의 출처가 문서 안에 남지 않는다는 것이다. 완성된 양식만 보면 모든 값이 똑같이 확정된 사실처럼 보이지만 실제로는 어떤 값은 정본에서 읽었고 어떤 값은 기억에서 나왔으며 어떤 값은 지난번 서류에서 복사되었다. 세 종류를 구분하지 않으면 틀렸을 때 어디를 고쳐야 하는지 알 수 없다.

행정 서류를 소유한 업무

서류를 받았을 때 가장 먼저 결정할 것은 어느 업무가 이 문서를 소유하는지다. 소유가 정해져야 원본을 어디에 둘지, 작성본을 어디에 만들지, 제출한 뒤 무엇에 연결할지가 함께 정해진다. 소유는 지금 열려 있는 폴더나 파일 이름에 들어간 단어 하나로 정하지 않고 이 일이 무엇의 결과이고 무엇을 만들어 내는지로 정한다. 정해진 뒤에는 그 작업 공간이 파일 이름과 배치와 검증과 완료 기준을 소유하고 다른 자리는 근거와 원자료만 공급한다. 서류는 그 서류를 발생시킨 일이 소유한다.

행정 서류가 한자리에 모이지 않는다는 것이 이 표의 실제 결과다. 학위 행정, 교과 행정, 교원 승급, 연구비 정산은 각각 다른 작업 공간에 살고 그 전부를 담는 상위 보관소는 없다. 서류를 한곳에 모으는 순간 그 서류가 어떤 일의 결과였는지가 지워지고 다음에 그것을 찾을 단서도 함께 사라진다. 서류를 모아 두기만 하는 폴더에는 규칙 문서를 두지 않는 편이 낫다. 판단이 반복되지 않는 자리에 규칙을 만들면 아무도 읽지 않는 문서가 하나 늘고 읽히지 않는 규칙은 실제 관례와 어긋난 채로 남는다. 소유를 잘못 정했을 때의 손실은 다음번에 나타난다. 같은 기관이 반년 뒤에 비슷한 서류를 요청하면 지난 작업을 찾지 못해 처음부터 다시 하고 그 과정에서 같은 서류의 두 번째 판이 다른 폴더에 생긴다. 판이 둘이 되면 어느 쪽이 실제로 제출된 것인지 알 수 없다. 판단이 애매하면 이 서류를 다시 찾을 때 어떤 일을 떠올릴 것인지를 묻고 그 일이 소유한다. 문서에 미팅이나 연구비 같은 단어가 들어 있다고 해서 그 이름의 폴더를 새로 추측해 만들지 않는다. 작성본은 해당 업무의 제출 package 안에 두고 여러 업무가 공유하는 이력 정본이나 개인정보 정본을 복사해 새 정본을 만들지 않는다. 정본이 둘이 되는 순간 한쪽만 갱신되고 어느 쪽이 현재 사실인지 알 수 없게 된다. 연구 지식을 담는 위키에는 공개 가능한 연구 내용과 다시 쓸 지식만 연결하고 고유 식별 번호, 계좌 정보, 개인 연락처, 서명 이미지는 넣지 않는다. 위키는 검색되라고 만든 공간이고 검색되면 안 되는 항목은 애초에 들어가면 안 된다.

서류 작업의 라우터인 문서 규칙 묶음

서류마다 판단이 반복되므로 판단의 결론을 모아 두는 자리가 따로 필요하다. 실제 운영에서는 행사 업무를 소유한 작업 공간 아래에 문서 규칙만 모은 묶음을 두고 그 안을 성격별 leaf로 나눈다. Leaf는 하나의 규칙만 소유하는 말단 문서를 뜻한다. 이 묶음이 소유하는 것은 반복 가능한 서류 작성 절차이고 서류 파일 자체는 그 서류를 발생시킨 업무의 폴더에 남는다. 절차의 정본과 서류의 보관 위치를 같은 것으로 읽으면 절차 한 줄을 고치려고 여러 업무 폴더를 뒤지게 되고 반대로 지난 서류를 찾으려고 규칙 문서를 뒤지게 된다. 원본과 작성본과 제출본을 어떻게 나누고 이름을 어떻게 붙이는지, 한글 양식을 다룰 때 무엇을 확인하는지, 개인 항목과 서명의 출처가 어디인지, 신분 증빙을 어떤 조건에서 첨부하는지, 이력 정본을 어떻게 갱신하는지가 각각 다른 leaf에 있다. 지급 서류를 처리할 때 투고 점검표 규칙을 읽을 필요는 없기 때문이다. 어느 작업 공간이든 골격과 진입 순서는 같다. 강제 규칙과 라우팅 표만 담은 얇은 문서가 입구이고 그 위키의 지도가 현재 규칙 표를 들고 있으며 변경 이력 문서가 구조와 규칙이 언제 왜 바뀌었는지를 담고 실제 절차와 실패 조건과 검증은 owner leaf에 있다.

업무 소유 위키의 라우터
    ↓
그 위키의 지도와 최근 변경 이력
    ↓
해당 행사, 과제, 과목의 실제 폴더와 요청 원문
    ↓
양식 규칙 leaf + 필요한 개인정보, 이력, 지급 leaf
    ↓
기관 원본 → 작업 사본 → 검증본 → 제출 package

순서를 고정해 두는 이유는 건너뛰기 쉬운 단계가 정해져 있기 때문이다. 급할수록 요청 원문을 다시 읽지 않고 양식부터 열게 되고 그때 놓치는 것이 대개 파일 이름 규칙이나 함께 내야 하는 다른 서류다. 규칙 leaf를 읽는 단계도 자주 생략되는데 지난번에 겪은 실패를 적어 둔 자리가 바로 그 leaf다. 순서를 문서로 적어 두면 에이전트에게 맡길 때도 같은 순서를 그대로 지시할 수 있다. 연구 지식을 담는 위키와 이 묶음 사이에도 역할이 나뉘어 있다. 사람과 연락처, 문헌 근거, 저널 정보, 문체 참고는 연구 위키가 소유하고 폴더 배치와 파일 이름과 판 관리와 조판 확인과 검증 절차는 각 업무 작업 공간이 소유한다. 한쪽의 규칙을 다른 쪽에 옮겨 적지 않고 정본의 경로를 그대로 가리키며 라우팅 표에는 이 위키에 중복하지 않는다는 열이 따로 있다. 서명 이미지, 이력 정본, 본인 증빙 같은 실물 자산은 규칙 문서와 분리해 별도의 물리 폴더에 두고 다른 작업 공간은 그곳을 직접 가리켜 끌어다 쓴다. 이 계층에는 바로가기를 만들지 않고 모든 문서를 실제 파일로 둔다. 같은 기관이 반복해서 요구하는 관행은 기관별 leaf로, 같은 사업이 반복해서 쓰는 양식은 사업별 leaf로 증류하고 한 행사에서만 요구한 항목은 행사 폴더에 남긴다.

양식을 다루는 처리 계층이 맡는 일

한글 양식은 텍스트만 뽑아서는 다룰 수 없다. 병합된 셀, 중첩된 표, 체크박스, 사진칸, 서명 자리, 쪽마다 다른 조판이 문서의 의미를 이루고 있어서 내용을 옮기는 순간 요구사항의 절반이 사라진다. 그래서 이 작업에는 원본 서식을 보존한 채 문서를 읽고 채우고 확인하는 처리 계층이 필요하다. 그 역할을 맡을 수 있는 도구로 kordoc이 있다. 다만 도구의 판이 바뀌면 명령과 옵션과 지원 범위도 함께 바뀌므로 여기서 고정할 것은 어떤 역할이 반드시 있어야 하는가다. 한글 양식을 전담하는 처리 계층이 있으면 그것을 먼저 쓰고 그 계층이 못 하는 동작에만 예전 도구를 부른다. 읽는 쪽의 역할은 둘이다. 문서를 사람이 읽을 수 있는 형태로 옮기되 표의 구조를 무너뜨리지 않는 일, 그리고 빈칸과 그 옆의 label, 체크박스, 서명 자리를 목록으로 뽑아 주는 일이다. 쓰는 쪽의 역할은 셋이다. 원본 서식을 유지한 채 지정한 칸에만 값을 넣는 일, 기존 문장의 일부만 고쳐 반영하는 일, 기관 원본이 없는 내부 문서를 새로 만드는 일이다. 검증하는 쪽의 역할도 셋이어서 파일이 규격에 맞는지 보는 구조 점검, 조판 결과를 눈으로 볼 수 있게 그려 주는 시각 확인, 개인 식별 항목이 남아 있는지 찾아 주는 점검으로 나뉜다.

이 장에서 kordoc은 HWP·HWPX를 포함한 행정 문서를 읽고 채우며 결과를 그려 확인하는 처리 계층의 예다. 원본 서식 보존과 시각 검증이 필요한 이유를 보여 준다.

원본이 이진 형식으로 오면 원본 파일을 그대로 보존하고 열린 형식의 작업 사본을 만들어 거기서 작업한다. 한글 계열 원본을 다른 문서 형식으로 옮겨 편집하지 않는다. 편집기가 다르면 표의 폭과 줄바꿈이 미세하게 달라지고 그 미세한 차이가 반려 사유가 된다. 변환기가 오류를 내지 않았다는 것은 파일이 만들어졌다는 뜻이고 배치가 보존되었다는 보장은 어디에도 없다. 이 제약은 원본이 한글 형식일 때만 적용된다. 원래부터 다른 형식으로 만들어진 산출물은 그 형식 그대로 두고 형식을 통일한다는 이유로 한글로 바꾸지 않는다. 적용 범위를 좁게 못 박아 두지 않으면 모든 문서를 한 형식으로 몰아가는 정리 작업이 시작되고 그 과정에서 멀쩡하던 산출물의 조판이 깨진다. 조판 결과를 그려 보는 역할은 대개 화면을 쓰는 응용 프로그램을 부른다. 사람이 그 턴에 요청하지 않았는데 배경에서 도는 작업이 응용 프로그램을 앞으로 끌어내면, 창이 튀어 오르고 초점이 옮겨 가고 권한을 묻는 대화상자가 뜬다. 사람이 다른 일을 하는 중에 이런 일이 벌어지면 검증이 방해로 바뀌므로 화면을 건드리지 않는 경로로 돌리거나 사람이 요청한 시점에만 실행한다. 새 도구를 도입할 때 물을 것은 여덟 역할 중 무엇을 못 하는지다. 무엇으로도 메울 수 없는 역할이 있으면 그 서류는 이 경로로 처리하지 않는다. 실제로 자주 비는 자리는 시각 확인이고 파일이 열린다는 것과 사람이 볼 때 양식이 맞다는 것은 다른 조건이다.

공식 원본 확인이라는 첫 관문

한글 양식 처리에는 게이트가 순서대로 걸려 있고 첫 번째 게이트는 기관 원본을 확인하기 전에 작성을 시작하지 않는 것이다. 요청 원문과 첨부 목록에서 기관이 요구한 정확한 파일 형식, 파일 이름 규칙, 마감을 먼저 확인한다. 소유 업무의 폴더와 최근 내려받은 파일을 함께 뒤져 공식 원본을 찾고 확장자만 보지 않고 파일이 실제로 그 형식인지 확인한다. 확장자와 내용이 어긋난 파일은 흔하고 그 상태로 작업을 시작하면 마지막에야 문제가 드러난다. 원본은 작업 단위 폴더 안의 원본 자리에 그대로 두고 파일 이름과 받은 시각을 기록한다. 요청 원문이 요구사항의 정본이라는 점도 이 단계에서 고정한다. 파일 이름을 어떻게 붙일지, 어떤 형식으로 몇 건을 언제까지 내야 하는지는 모두 요청한 쪽이 정하며 그 내용은 요청 메일이나 공문에만 있다. 담당자가 전화로 알려 준 조건이나 동료가 기억하는 관행을 요구사항으로 삼으면 나중에 근거가 남지 않는다. 요청 원문에서 뽑은 조건은 접수 기록에 그대로 옮겨 적고 원문 자체도 업무 폴더에 함께 남긴다. 마감 뒤에 조건이 바뀌었다는 연락이 오는 경우가 있으므로 어느 시점의 요청을 근거로 작업했는지가 기록되어 있어야 한다.

1. 양식 하나를 골라 값을 채우지 않고 두 개의 문서만 만든다
2. 최근에 받은 양식이나 공개된 빈 양식을 하나 고른다
3. 원본을 원본 자리에 두고 파일 이름과 받은 시각을 적는다
4. 접수 기록을 한 장 만들어 요청 출처, 기관이 요구한 파일 형식과 이름 규칙, 마감, 이 서류를 소유하는 업무, 원본의 위치를 적는다

마감과 작업 시각은 미리 적는 원장에 남긴다. 원장은 시작과 종료를 짝으로 덧붙이기만 하는 방식이라, 시작만 있고 종료가 없는 줄이 그대로 남아 중간에 끊긴 서류를 드러낸다. 여러 건이 동시에 걸린 주간에는 어느 서류를 손대다 말았는지가 기억으로 복원되지 않는다. 가능하다면 원본부터 한 번 조판해 눈으로 본다. 쪽수, 표의 크기, 사진칸의 위치, 동의 문구가 든 상자, 서명 자리를 미리 봐 두면 작업 사본이 원본과 달라졌을 때 무엇이 달라졌는지 바로 안다. 공식 원본을 끝내 찾지 못했다면 비슷한 양식을 새로 만들거나 다른 형식의 대체본을 쓰지 않고 거기서 멈춘다. 기관에 원본을 다시 요청하는 것이 정답이고 자체 제작한 양식은 내용이 아무리 정확해도 반려된다. 이 관문이 막는 사고는 내용이 비슷한 과거 서류를 현재 기관의 원본으로 잘못 쓰는 일이고 과거 서류는 대개 잘 채워져 있어서 더 위험하다.

도구가 오류를 내지 않았다는 것을 내용이 맞다는 뜻으로 읽으면 이런 종류의 사고가 난다. 같은 작업 환경에서 실제로 있었던 일 하나가 이 형태였다. 텍스트 추출기가 가진 글자 수 상한을 쪽수 제한으로 착각한 채 논문을 넣었더니 본문이 Methods 중간에서 잘렸는데 추출은 성공으로 보고되었다. 잘린 뒤쪽에 있던 내용은 그 뒤의 모든 작업에서 없는 것으로 다뤄졌고 그것이 빠졌다는 사실은 결과물이 이상해진 다음에야 드러났다. 서류 작업에서 잘못된 원본을 붙잡는 일도 같은 구조를 갖는다. 양식이 열리고 조판이 되고 칸이 채워지는 동안 어느 단계도 오류를 내지 않으므로 원본이 옛 판이거나 다른 사업의 것이라는 사실은 제출 직전이나 제출한 뒤에 드러난다. 그래서 원본을 확인하는 일을 작업의 일부로 두지 않고 앞에 별도 관문으로 떼어 놓는다. 받은 원본은 손대지 않은 채로 두고 작업 사본을 따로 만들며 무엇을 원본으로 삼았는지를 원장에 먼저 적은 뒤에 첫 칸을 채운다.

읽기와 빈칸 목록

원본을 확보하면 문서를 칸 단위로 읽는다. 사람은 양식을 읽을 때 문맥으로 빈칸의 의미를 채우지만 처리 계층에는 그 문맥이 없으므로 어느 칸에 무엇이 들어가는지를 명시적으로 적어 주어야 한다. 빈칸 목록에는 각 칸의 label, 같은 label이 문서 전체에서 몇 번 나오는지, 체크박스가 몇 개이고 어떤 선택지인지, 서명 자리가 어디에 몇 개인지, 긴 글이 들어가는 칸이 어느 쪽에 있는지를 적는다. 목록 없이 채우기 시작하면 마지막에 어느 칸을 빠뜨렸는지 확인할 방법이 없다. 빈칸 목록은 제출 직전에 한 번 더 쓰인다. 채우기가 끝난 작업 사본을 목록과 나란히 놓고 칸마다 값이 들어갔는지, 들어간 값이 그 칸의 label과 맞는지를 대조한다. 대조 없이 완성본만 훑어보면 사람은 자기가 방금 채운 순서대로 읽기 때문에 빠진 칸을 건너뛴다. 특히 두 번째 쪽 이후의 체크박스와 표 안쪽의 작은 칸이 자주 비어 있고 비어 있어도 문서는 정상으로 보인다. 읽는 과정에서 특히 조심할 것이 반복되는 label이다. 여러 사람의 정보를 나란히 적는 양식에서는 성명이나 소속 같은 label이 여러 번 나오고 그중 하나만 본인 칸이다. 처리 계층이 label만 보고 모든 칸을 같은 값으로 채우면 다른 사람의 칸이 오염되고 서식은 멀쩡해 보이므로 사람이 검토할 때도 놓치기 쉽다. 병합되거나 중첩된 표를 보기 좋게 만들려고 구조를 평평하게 펴면 그 순간 원래 어느 칸이 어디에 속했는지를 잃는다. 문자 인식으로 얻은 값은 원문과 같은 신뢰도로 취급하지 않고 반드시 원본 화면과 대조한다.

1. 빈칸 목록을 만든다
2. 각 칸의 label, 같은 label의 반복 횟수, 체크박스, 서명 자리, 긴 글이 들어가는 칸을 적는다

값의 출처 결정

빈칸 목록이 끝나면 값을 채우기 전에 각 칸의 값이 어디서 오는지를 먼저 정한다. 기억나는 값부터 채우고 나중에 확인하려 들면, 다음에 같은 양식을 받았을 때 같은 탐색을 처음부터 반복하게 되고 값이 틀렸다는 것이 드러났을 때 어디서 온 값인지 되짚을 수 없다. 값과 출처를 나란히 적은 대응표는 작업 중에는 채우기의 근거가 되고 제출 뒤에는 검증의 근거가 된다. 서류 작업에서 축적되는 것은 이 대응 관계다.

신원 항목은 두 정본을 함께 본다. 이름, 소속, 직급, 학력은 현재 이력 정본과 개인정보 정본에서 각각 확인하고 기억이나 지난번 산출물이나 파일 이름에서 유추한 표기를 쓰지 않는다. 한 출처에 그 항목이 없다는 사실만으로는 확인을 마칠 수 없다. 두 번째 현재 출처를 열어 확인하고 두 출처가 서로 다르게 적고 있거나 표기를 정규화해야 하는 상황이면 거기서 멈추고 사람에게 묻는다. 로마자 표기, 기관 명칭의 개편, 직급의 영문 표기는 그럴듯한 답을 만들기 가장 쉽다. 그럴듯한 답이 한 번 서류에 들어가면 이후의 서류가 그 값을 복사하고 몇 해 뒤에는 기관마다 다른 표기가 등록된 상태가 된다. 대응표를 만드는 비용은 첫 서류에서 가장 크고 그 뒤로 급격히 줄어든다. 세 번째 서류쯤 되면 정본이 없는 항목이 무엇인지가 드러나는데 반복해서 출처를 적을 수 없는 항목은 정본을 새로 만들어야 한다는 신호다. 어떤 항목이 여러 곳에서 조금씩 다르게 나타난다면 정본이 여럿이라는 뜻이므로 하나를 정본으로 정하고 나머지를 참조로 내린다. 서류를 처리하면서 개인 자료의 정본 구조가 정리되는 것이 이 대응표의 부수 효과다.

1. 각 칸 옆에 값의 출처만 적는다. 값은 적지 않고 어느 정본의 어느 항목까지만 쓴다
2. 실제 개인 항목의 값은 이 과정에서 한 번도 입력하지 않는다
3. 출처를 적을 수 없는 칸에 표시를 남기고 그 칸이 왜 비었는지 한 줄로 적는다

성공 기준은 새 세션을 시작한 에이전트에게 접수 기록과 빈칸 목록만 주었을 때, 지금 채울 수 있는 칸과 채울 수 없는 칸을 구분하고 채울 수 없는 이유를 말할 수 있는가다. 출처를 적을 수 없다고 표시된 칸이 하나도 없다면 대개 목록을 덜 만든 것이다. 대부분의 양식에는 정본이 없는 항목이 최소한 하나는 있고 그 항목을 찾아내는 것이 이 작업의 실제 소득이다. 정본이 없는 항목을 알고 시작하는 것과 채우다가 막히는 것은 같은 서류에서도 걸리는 시간이 크게 다르다. 민감한 항목에는 별도의 경계가 걸린다. 고유 식별 번호, 계좌 정보, 신분 증빙은 광범위 검색의 대상에서 빼고 위키 색인과 작업 로그와 대화 재인용에도 넣지 않는다. 이 파일들이 제자리에 있는지 확인해야 할 때는 내용을 검색하는 대신 파일 권한을 검사한다. 내용을 훑는 확인은 그 자체로 값을 다시 노출하고 검색 기록에 흔적을 남기므로 감사 방법이 감사 대상을 늘리는 셈이 된다. 값을 모은 중간 파일은 제출 package 밖의 제한된 임시 위치에 두고 작업이 끝나면 남기지 않는다. 값을 명령의 인자로 직접 넘기면 그 값이 실행 기록에 남으므로 파일로 넘기거나 값을 가린 채 확인하는 경로를 쓴다. 대화창과 작업 로그에도 값을 적지 않는다. 로그에 남길 것은 어느 정본의 어느 항목을 읽어 어느 칸에 넣었다까지다.

채우기와 고치기와 새로 만들기의 선택

값의 출처가 정해지면 작업 방식을 고른다. 기관 양식에 빈칸이 분명하게 있으면 원본 서식을 유지한 채 지정한 칸에만 값을 넣는다. 원본에 이미 문장이 들어 있고 그중 일부만 바꿔야 하면 문서 구조를 옮기지 않고 해당 문장만 고쳐 반영한다. 기관 원본이 아예 없는 내부 보고서나 회의록은 새로 만드는 쪽이 맞고 이때는 원본 보존이라는 제약이 없으므로 판단이 단순해진다. 작업 방식과 상관없이 지키는 것은 원본 불변이다. 원본 파일은 열어서 보되 고치지 않고 작업은 언제나 사본에서 한다. 원본을 한 번 덮어쓰면 되돌리기 어렵기 때문에 이 규칙을 반드시 지킨다. 되돌릴 때는 동기화 서비스가 남긴 파일 버전 기록을 쓴다. 덮어쓰기 전에 현재 파일을 읽고 무엇을 어떻게 바꿀지 보여 준 뒤 승인을 받는 순서는 여덟 개 작업 공간 전부에 공통으로 적용한다.

제출본의 이름에는 확장자 앞에 본인 제출본임을 나타내는 접미사를 붙인다. 국문 서류와 영문 서류에 각각 정해진 접미사가 있고 그 규칙은 모든 작업 공간에서 같다. 최종이나 진짜최종이나 날짜를 붙인 이름은 이 접미사를 대신하지 못한다. 날짜가 붙은 파일이 세 개면 어느 것이 제출본인지는 여전히 알 수 없고 최종이라는 단어는 사흘이면 두 번 나온다. 접미사가 하는 일은 이 파일이 기관 원본에서 파생된 본인 제출본이라는 사실을 이름만 보고 판정하게 만드는 것이고 그래서 원본 양식에는 어떤 경우에도 이 접미사가 붙지 않는다. 파일이 놓이는 폴더도 같은 원리로 정해져 있다. 받은 원본은 원본 폴더에 두고 지금 제출하는 산출물은 작업 단위 폴더의 루트에 둔다. 최신본을 초안 폴더나 현재 폴더 아래로 내리면 무엇을 제출하는지 확인하는 데 폴더를 세 번 열게 되고 급할 때 그 세 번이 잘못된 파일을 고르게 만든다. 새 판이 나오면 직전 판을 같은 레벨의 지난 판 폴더로 밀어내고 중간 산출물과 미리보기 이미지는 그 아래나 작업 공간 밖의 임시 폴더에 둔다. 작업 폴더 루트에 임시 폴더를 만들면 그 폴더가 다음 주에는 제출 대상처럼 보인다. 반복되는 label을 자동으로 채우지 않게 막는 장치가 이 단계의 안전장치다. 한 label이 여러 칸에 걸릴 때 처리 계층이 자동으로 진행하는 대신 멈추도록 설정해 두면, 다른 사람의 칸을 채우는 사고가 구조로 막힌다. 처리 계층이 멈췄을 때 그것을 빠르게 넘기려고 안전장치를 꺼 버리는 것이 이 단계에서 가장 위험한 선택이다.

별도 단계로서의 서명과 날인

서명은 다른 칸을 채우는 일과 성격이 다르다. 다른 칸의 값은 사실의 전사이지만 서명은 그 문서의 내용에 사람이 동의한다는 표시다. 서명 이미지가 자동으로 배치되었다는 것과 사람이 그 내용에 동의했다는 것은 별개이고 순서도 사람이 전체를 읽은 뒤에 서명이 들어가야 맞다. 서명 이미지는 공식 자산 폴더에서 가져오고 배경이 투명한지 확인한다. 배치 방식에는 정해진 답이 있다. 서명 자리를 나타내는 표시 위에 이미지를 올리고 형식이 그 배치를 지원하면 본문 앞에 뜨는 개체로 둔다. 표시 앞뒤에 이미지를 인라인으로 끼워 넣는 것으로 끝내지 않는데 인라인으로 붙이면 그 줄의 높이가 이미지만큼 늘어나 아래 내용이 통째로 밀리고 쪽 배치가 원본과 달라지기 때문이다. 표시가 문서에 여러 번 나오면 몇 번째 자리인지 지정해서 넣고 중첩된 표나 텍스트 상자 안에 서명 자리가 있을 때 처리 계층이 경고를 내면 배치가 성공했다고 간주하지 않는다.

구조를 훑는 검사만으로 서명된 양식이 완성되었다고 말하지 않는다. 조판 결과를 그려서 서명이 그 영역 위에 놓였는지, 다른 글자를 가리지 않는지, 잘리지 않았는지, 표 배치를 깨지 않았는지를 눈으로 본다. 서명 이미지가 지정된 영역을 조금 벗어나거나 옆 칸의 글자를 덮는 일은 흔하고 파일 구조만 보면 어느 쪽도 오류로 나타나지 않는다. 위치가 어긋났으면 보정한 뒤 다시 그려 보고, 확인할 방법이 없다면 서명을 붙이지 않고 사람이 출력본에 직접 서명하는 경로로 돌린다. 서명을 별도 단계로 떼어 놓는 진짜 이유는 책임의 소재다. 서명한 문서에 사실과 다른 내용이 있으면 그 책임은 서명한 사람에게 있고 문서를 어떤 방식으로 만들었는지는 책임의 크기를 바꾸지 않는다. 에이전트가 채운 값이 정확하다는 것과 그 문서의 진술에 사람이 동의한다는 것은 서로 다른 판정이며 뒤의 판정은 위임할 수 없다. 그래서 서명 직전에 전체를 처음부터 읽는 단계를 절차에 넣어 두고 급할 때도 이 단계는 줄이지 않는다.

서명을 붙이는 동작에는 두 단계가 있고 선은 그 사이에 있다. 앞 단계는 배치이고 뒤 단계는 그 배치를 서명 행위로 인정하는 일이다. 배치는 맡긴다. 표시가 있는 자리를 찾아 이미지를 그 위에 올리고 형식이 지원하면 본문 앞에 두어 표시를 덮게 하고 조판 결과를 그려 위치가 맞는지 확인하는 데까지가 여기 들어간다. 인정은 맡기지 않는다. 서명된 양식은 기관에 제출되면 사람이 그 내용에 동의했다는 기록이 되고 그 동의를 에이전트가 대신 표시할 자리는 없기 때문이다. 그래서 배치가 끝난 파일은 완성본으로 넘어가지 않고 사람이 열어서 확인할 대상으로 넘어간다. 확인할 방법이 없는 형식이거나 조판 결과를 그려 볼 수 없다면 이미지를 붙이지 않고 사람이 출력본에 직접 서명하는 경로로 돌리는데 확인하지 못한 서명이 붙은 파일은 붙지 않은 파일보다 위험하다.

구조 검증과 시각 검증의 병행

검증은 세 층으로 나눠서 한다. 내용 층에서는 필수 칸이 모두 채워졌는지, 날짜와 금액과 체크박스가 정확한지, 동의 문구가 요구된 그대로인지를 본다. 여기에는 문서에 남으면 안 되는 것을 걷어 내는 확인도 들어간다. 초안을 만드는 과정에서 들어간 지시문, 작업 계획, 도구가 남긴 상태 문구, 조수 어투의 안내 문장이 본문에 섞여 있는 경우가 실제로 있고 서식이 맞으므로 다른 층에서는 걸리지 않는다. 구조 층에서는 파일 묶음과 내부 참조가 규격에 맞는지, 문서가 정상적으로 열리는지를 본다. 배치 층에서는 쪽수가 원본과 같은지, 표의 행과 열이 유지되었는지, 서명이 제자리에 있는지, 글자가 칸을 넘치거나 겹치거나 잘리지 않았는지를 조판 결과로 본다. 구조 오류가 0건이어도 배치는 얼마든지 어긋나 있을 수 있고 기관 담당자가 실제로 보는 것은 조판된 결과다. 시각 확인에서 흔히 생기는 실수는 대표 쪽 한 장만 보는 것이다. 값을 넣은 모든 쪽, 긴 표가 있는 쪽, 서명이 있는 쪽, 그리고 마지막 쪽은 매번 본다. 마지막 쪽을 따로 세는 이유는 내용이 한 줄 늘어났을 때 밀려난 부분이 거기서 드러나기 때문이다.

확인한 결과는 그 업무를 소유한 위키의 로그 문서에 덧붙인다. 작업 폴더 루트에 진행 메모나 변경 기록 파일을 따로 만들지 않는데 폴더 루트에 문서가 늘어나면 무엇이 제출 대상인지가 흐려지기 때문이다. 로그 한 항목의 형식은 고정되어 있다. 무엇이 이 작업을 촉발했는지, 그때 원본이 어떤 상태였는지, 무엇을 실행했는지, 무엇을 확인했는지, 무엇을 발견했는지, 무엇을 결정했는지, 무엇이 남았는지, 어떤 산출물이 나왔는지를 적는다. 확인 결과에는 다섯 가지 상태 라벨을 쓴다. 확인됨, 불일치, 미확인, 보류, 재실행필요다. 라벨을 강제하는 이유는 확인하지 못한 것을 이상 없음으로 적지 않게 만드는 것이고 조판을 그려 보지 못했으면 미확인이며 그 상태로는 제출 게이트를 통과하지 못한다. 값 자체는 적지 않고 칸의 이름과 판정만 적는다. 이 기록이 있으면 같은 양식을 다음에 받았을 때 지난번에 어긋났던 자리부터 확인하게 되고 어긋나는 자리는 양식마다 정해져 있는 편이라 두세 번 처리한 양식에서는 이 기록이 그 양식의 위험 지도가 된다.

개인정보와 제출 package

제출 package는 보내는 파일만 모아 둔 폴더다. 공식 원본, 검증을 통과한 작성본, 기관이 요구한 최소 증빙만 넣고 나머지는 넣지 않는다. 작업용 중간 문서, 값을 모아 둔 파일, 미리보기 이미지, 실패한 변환본은 모두 제외한다. 게이트를 통과하지 못한 파일을 제출 폴더에 남기지 않는 것이 마지막 게이트이고 실패본이 섞여 있으면 언젠가 실수로 그것이 첨부된다. 저장하고 내보내고 첨부하기 전에 삽입한 신원 항목을 하나씩 확인한 출처와 대조한다. 대조하지 못했거나 출처와 어긋난 항목은 사소한 흠으로 보지 않고 진행을 막는 결함으로 다룬다. 파일 이름은 기관이 지정한 규칙이 있으면 그것을 따르고 없으면 언어별 접미사 규칙을 적용한다. 신분 증빙과 금융 정보 사본은 요청한 기관과 담당자와 메일 도메인을 확인한 뒤 요구된 한 종류만 첨부하고 증빙을 첨부해 보내는 일에는 사전 승인이 별도로 걸린다.

발송은 사람이 최종 책임진다. 에이전트는 수신자와 제목과 본문과 첨부 목록을 갖춘 초안까지 만들고 거기서 멈추며 사람이 그 초안을 보고 명시적으로 승인한 뒤에야 발송한다. 메일 보내 달라거나 회신해 달라는 말은 초안을 만들어 보여 주고 기다리라는 뜻으로 읽는다. 초안을 고쳤으면 고친 것을 다시 보여 주고 새 승인을 받으며 앞선 승인은 고쳐진 초안에 적용되지 않는다. 제출 뒤에 남기는 연결이 다음 서류의 출발점이 된다. 발송한 메일과 실제로 보낸 파일을 해당 업무의 폴더에 함께 두면, 나중에 기관이 제출 내용을 물어 왔을 때 무엇을 언제 보냈는지 바로 답할 수 있다. 연구 위키에는 그 서류에서 얻은 재사용 가능한 규칙만 올라가고 파일 자체는 올라가지 않는다. 개인 항목을 어디서 읽었는지는 대응표에 남지만 그 항목의 값은 어느 기록에도 남기지 않는다.

첫 번째 사례인 외부 평가와 자문 서류

외부 기관이 평가 위원을 위촉하면서 서류 여러 건을 한꺼번에 요청한다. 요청 묶음에서 서류 목록과 각각의 마감을 먼저 뽑고 그중 어느 것이 개인 신상을 적는 서류이고 어느 것이 판단을 적는 서류인지 구분한다. 위촉을 수락하는 서류와 비밀 유지를 약속하는 서류와 지급을 위한 서류는 개인 항목을 옮겨 적는 작업이고 평가 의견을 적는 서류는 자료를 읽고 판단하는 작업이다. 원본은 각각 그대로 보존하고 반복되는 개인 항목은 두 정본을 교차 확인해 필요한 항목만 읽어 채운다. 지급 서류에는 가장 민감한 개인 정보가 모인다. 금융 정보와 신분 증빙을 함께 요구하는 경우가 많고 요청하는 쪽도 무엇이 최소한인지 정확히 알려 주지 않는 경우가 있다. 이전에 다른 기관에 보냈던 증빙 묶음을 그대로 재사용하면 이번 기관이 요구하지 않은 정보까지 함께 나가므로 증빙은 서류마다 새로 고른다. 여기서 지킬 경계는 개인 항목 채우기와 내용 판단을 같은 자동화 단계로 합치지 않는 것이다. 개인 항목은 정본과 대조하면 맞았는지 알 수 있지만 평가 의견은 대조할 정본이 없고 읽은 사람의 판단이 근거다. 하나의 흐름으로 합치면 검증 방법이 있는 쪽의 통과가 검증 방법이 없는 쪽의 통과로 오인된다. 서명과 세 층 검증을 마친 뒤 하나의 제출 package와 발송 초안을 만들고 발송 여부는 사람이 결정한다.

두 번째 사례인 과제 수행 중 인력 등록

수행 중인 과제에 인력을 등록하는 서류는 값의 출처가 두 갈래로 갈리는 전형적인 경우다. 한쪽은 등록 대상자의 개인 항목이고 다른 쪽은 과제 자체의 항목이다. 먼저 과제 소유 위키에서 그 과제가 제안 단계인지 수행 단계인지, 현재 참여 역할과 협약 기간이 무엇인지 확인한다. 제안서에 적힌 값과 협약 이후의 값이 다른 경우가 드물지 않고 제안서의 값을 그대로 쓰면 행정에서 되돌아온다. 이 서류의 작성본은 과제 폴더가 소유하고 절차는 문서 규칙 묶음이 소유하는데 서류를 행사 업무 쪽에 만들어 두면 연차 보고나 변경 신청에서 이 등록 건을 다시 찾을 때 아무도 그곳을 떠올리지 못한다. 등록 대상이 본인이 아닌 경우에는 개인 항목의 취급이 한 단계 더 조심스러워진다. 다른 사람의 정보를 대신 채우는 일은 그 사람이 제출한 자료의 범위 안에서만 하고 부족한 항목을 추정해 메우지 않는다. 이전 과제에서 같은 사람의 정보를 다룬 적이 있더라도 그때의 값이 현재도 유효한지는 알 수 없으므로 다시 받는다. 대신 채운 서류는 서명 전에 그 사람이 직접 확인하도록 하고 확인했다는 사실을 기록에 남긴다. 값이 서로 어긋날 때의 처리가 이 서류의 핵심이다. 참여 기간이나 인건비 관련 수치가 과제의 행동 기록과 협약 원문과 행정 요청에서 서로 다르게 나타나는 일이 실제로 생기는데 이때 에이전트가 그럴듯한 하나를 골라 채우면 불일치가 문서 안으로 들어가 사라진다. 불일치는 보고할 사실이므로 세 값을 나란히 적어 사람에게 올리고 어느 것이 맞는지는 담당 부서에 확인한 뒤 채운다.

세 번째 사례인 강의계획서와 교과 행정

수업 관련 서류에서 반복되는 실수는 지난 학기 문서를 현재 학기의 출처로 쓰는 것이다. 먼저 활성 학기와 해당 과목의 소유 폴더를 찾고 지난 학기 강의계획서는 문장 구조를 참고하는 자료로만 쓴다. 현재 학기의 일정, 과목 코드, 평가 비율, 이수 구분은 학사 공지와 학기 정본에서 다시 읽는다. 학기가 바뀌면 조용히 바뀌는 값이 있고 그중 평가 비율과 과목 코드는 틀리면 정정 절차로 이어지므로 비용이 크다. 기관 원본이 있으면 채우거나 부분만 고치고 원본이 없는 내부 계획서에만 새로 만드는 방식을 쓴다. 교과 행정 서류는 값의 양이 많고 대부분이 기계적이라는 점 때문에 자동화 유혹이 가장 큰 영역이기도 하다. 주차별 주제, 교재, 평가 항목처럼 반복되는 칸이 많아 한 번 채워 두면 다음 학기에 그대로 쓰고 싶어지는데 반복되는 칸일수록 조용히 바뀐 값이 섞여 들어가고 대부분 맞기 때문에 검토할 때도 넘어가기 쉽다. 지난 학기 문서를 출발점으로 쓰되 각 칸이 이번 학기 정본과 일치하는지는 칸 단위로 확인한다. 수업 날짜는 서류 안에서 검증되지 않는 값이라 따로 대조한다. 강의 일정 정본과 서류에 적은 주차별 날짜를 나란히 놓고 공휴일과 보강 일정까지 맞춰 본다. 서류만 보면 날짜는 언제나 그럴듯해 보이고 어긋난 것은 학기가 시작한 뒤에야 드러난다. 이 대조는 처리 계층이 대신할 수 없는 종류의 확인인데, 두 값이 서로 다른 정본에 있고 어느 쪽이 맞는지를 사람이 결정해야 하기 때문이다.

수업 업무를 소유한 작업 공간의 배치는 학기 폴더 하나를 작업 단위로 삼는다.

학교-수업/
├── AGENTS.md
├── wiki/
│   ├── index.md                 업무 라우터
│   ├── layout.md                폴더 지도와 자료의 소유 위치
│   ├── conventions.md           학기와 과목과 수정본의 이름 규칙
│   ├── calendar-routing.md      일정 라우팅
│   └── log.md                   구조와 규칙의 변경 이력
├── {학년도}{학기}-{과정}/         학기 단위 작업 폴더
├── {지난 학기}/                  지난 것을 접는 자리
├── textbooks/                   교재
└── {행정 업무}/                  개설 신청, 종합시험, 성적 같은 반복 업무

폴더 이름은 예시이고 학년도와 학기와 과정을 어떤 순서로 붙일지는 각자의 정렬 방식에 맞춘다. 작업 단위가 학기와 과정의 조합이어서 같은 과목이라도 학기가 다르면 다른 폴더가 되고 학기가 끝나면 지난 학기를 한 폴더로 접는다. 교재와 참고 자료와 반복되는 행정 업무는 학기에 매이지 않으므로 학기 폴더 밖에 따로 있다. 이 위키는 다섯 문서로 끝나 앞선 장들이 보여 준 작업 공간들보다 눈에 띄게 얇다. 규칙의 양은 그 업무가 얼마나 자주 판단을 요구하는지에 따라 정해졌고 서류와 과제를 다루는 공간이 두꺼운 것도 같은 이유에서다. 얇다고 해서 층을 생략하지는 않아서 이 위키도 원자료와 위키와 규칙이라는 같은 세 층을 문서에 선언한다. 원자료는 학기와 과목 폴더에 실제로 놓인 자료이고 위키는 반복해서 다시 쓰는 위치 정보와 배치 기준이며 규칙은 최상위 규칙 파일이 소유한다. 세 층을 선언해 두면 문서를 하나 더 만들지 정할 때 그 내용이 어느 층에 속하는지부터 묻게 되고 어느 층에도 속하지 않는 문서는 만들지 않는다.

따라해보기

아래 블록은 AI 도구의 채팅창에 그대로 붙여 넣는 프롬프트다. 수업 작업 공간을 처음 세울 때 쓰는 프롬프트다. 꺾쇠 안은 자기 경로와 표기로 바꾼다.

<수업 작업 폴더 경로>에 수업 작업 공간을 만들어 줘.
- 최상위에 AGENTS.md 하나와 wiki/ 하나를 두고 나머지는 학기 폴더로 둔다
- 학기 폴더 이름은 {학년도}{학기}-{과정} 형식으로 고정한다
- 교재는 textbooks/에 두고 개설 신청과 종합시험과 성적 같은 반복 업무는
  각각 별도의 행정 업무 폴더에 두며 학기 폴더 안에 넣지 않는다
- wiki/에 다섯 문서만 만든다. index.md는 업무 라우터, layout.md는 폴더 지도와
  자료의 소유 위치, conventions.md는 학기와 과목과 수정본의 이름 규칙,
  calendar-routing.md는 일정 라우팅, log.md는 구조와 규칙의 변경 이력이다
- layout.md 첫머리에 원자료와 위키와 규칙 세 층이 각각 어디인지 한 줄씩 적는다
- AGENTS.md에는 다음 세 줄을 강제 규칙으로 적는다
  1. 지난 학기 문서를 현재 학기의 값 출처로 쓰지 않는다
  2. 학기가 끝나면 그 학기 폴더를 지난 학기 폴더 아래로 옮긴다
  3. 옮기거나 덮어쓰기 전에 대상 목록을 먼저 보여주고 내 승인을 기다린다
- 여섯 번째 문서를 만들 이유가 생기면 만들기 전에 나에게 먼저 물어본다

처리를 멈춰야 하는 경우

자동화 절차에서 가장 중요한 설계는 어디서 멈추는가다. 다음 상황에서는 진행하지 않고 사람에게 올린다.

• 암호나 보호 설정 때문에 원본을 읽을 수 없다.
• 기관이 배포한 공식 원본을 찾지 못했다.
• 같은 label이 여러 번 나오는데 어느 칸이 누구의 것인지 특정할 수 없다.
• 형식을 바꾼 작업 사본에서 표, 개체, 쪽 배치가 원본과 달라졌다.
• 제출 시스템이 어떤 형식을 받는지 확인되지 않았다.
• 개인 항목의 출처가 서로 충돌하거나 필요한 항목이 현재 정본에 없다.
• 삽입한 신원 항목 중 확인한 출처와 대조하지 못한 것이 남아 있다.
• 서명 위치와 넘침을 조판 결과로 확인할 수 없다.
• 문서 내용이 법적 동의, 예산, 인사, 평가처럼 사람의 최종 판단을 요구한다.

멈췄다는 사실 자체도 기록에 남긴다. 어느 단계에서 왜 멈췄는지, 사람에게 무엇을 물었는지, 그 답이 무엇이었는지를 적어 두면 같은 조건이 다음에 나타났을 때 다시 물을 필요가 없다. 여러 번 반복해서 같은 이유로 멈춘다면 그 조건은 규칙으로 올릴 후보이며 대개 특정 기관이나 특정 사업의 관행에서 온다. 한 번만 나타난 조건은 그 서류의 기록에만 남긴다. 멈춤 기록이 쌓이면 어떤 종류의 서류가 사람의 시간을 실제로 잡아먹는지가 드러나고 그것이 다음 해에 무엇을 정비할지 정하는 근거가 된다. 행정 서류에서 진짜 손실을 만드는 것은 조용히 잘못 채워진 문서가 제출되는 상황이다. 앞의 아홉 항목은 모두 자동으로 그럴듯한 답을 만들 수 있지만 그 답이 맞는지는 문서 안에서 확인할 수 없다는 공통점을 가진다. 확인할 수 없는 자리에서 진행하면 오류가 발견되지 않은 채 기관에 남고 정정에는 작성보다 훨씬 큰 비용이 든다. 멈추는 조건을 미리 문서로 적어 두면 그 판단이 그날의 마감 압박에 좌우되지 않는다.

밀어붙인 쪽과 되돌린 쪽의 경계는 지금 설정 파일에 그대로 남아 있다. 도구를 실행하는 층에는 승인 게이트가 거의 없다. 기본값이 묻지 않는 것이고 샌드박스도 넓게 열려 있으며 도구 하나하나에 사람 승인을 강제해 둔 항목은 전체 설정에서 손에 꼽는다. 읽고 정리하고 초안을 만드는 일에서는 확인을 걸어 봤자 매번 승인만 누르게 되고 그 습관이 붙으면 정작 확인이 필요한 순간에도 승인을 누른다. 그래서 기계적으로 강제한 것은 두 가지로 줄였다. 하나는 이메일 발송이고 다른 하나는 일정 변경이다. 이 둘의 공통점은 밖으로 나가면 되돌릴 수 없다는 것이고 나머지 경계는 지침 문장과 작업별 프롬프트가 지킨다. 각 작업의 프롬프트에는 같은 금지 목록이 반복해서 적혀 있다. 자동으로 메일을 보내지 않고 댓글을 자동으로 달지 않고 메일과 파일과 문서를 지우지 않고 예약 작업의 정의를 만들거나 고치거나 멈추거나 지우지 않는다.

되돌린 자국도 남아 있다. 일정 변경을 코드로 막은 가드는 같은 사고가 반복된 뒤에 만들어졌다. 요청의 단계를 식별하는 키를 두고 완료되었거나 위임되었거나 외부 대기이거나 억제된 상태는 같은 키로 다시 열 수 없게 했다. 사람이 자동 생성된 일정을 지우면 지웠다는 표식이 남아 같은 키가 다시 만들어지지 않는다. 운영 로그에는 아침에 허용되어 있던 동작이 같은 날 저녁에 읽기 전용으로 바뀐 기록도 있다. 권한이 좁아지는 방향으로 움직인 시점은 모두 사고 뒤였고 미리 좁혀 둔 적은 없다. 이 순서를 뒤집을 수 있다고 믿지 않는 편이 낫다는 것이 3년 동안 남은 판단이고 그래서 자동화를 설계할 때 실제로 정하는 것은 잘못이 생겼을 때 그것이 사람에게 도착하는 경로가 몇 개이고 그중 몇 개가 사람이 열어 봐야만 작동하는지다.