AI가 만든 문서의 완료 판정
품앗이가 AI와 함께 일하며 남긴 기록을 다른 조직이 다시 쓸 수 있게 옮긴 글입니다. 묶음 전체는 한글 문서를 AI로 다루기에서 볼 수 있습니다.
요지
AI가 만든 문서가 다 됐는지는 받는 사람이 여는 프로그램에서 그려진 화면으로 판정합니다. 압축 구조 검사, XML 검사, 검증 명령 통과는 파일이 깨지지 않았다는 뜻일 뿐 화면이 맞다는 증거가 아니었습니다. 이 글은 그 판정과 함께, 양식의 모양을 정하는 기준과 문서 속 숫자를 다루는 법을 우리 기록에서 모았습니다.
1. 렌더한 화면이 판정이다
우리 기록에 따르면 형식마다 판정하는 자리가 다릅니다.
| 형식 | 판정하는 자리 |
|---|---|
| HWPX | 한컴 오피스, 또는 rhwp를 엔진으로 쓰는 HOP |
| DOCX | 워드나 구글 문서 |
| 모든 쪽을 그림으로 뜬 것 |
우리 기록에 따르면 HWPX를 고친 뒤 본문 글자만 확인하고 「완료」를 붙였는데, 실제로는 표 셀이 위아래로 겹쳐 읽을 수 없는 상태였습니다. 워드 표도 XML에 값이 다 들어간 것을 확인하고 넘어갔다가 구글 문서에서 열어 보니 깨져 있던 회차가 있습니다.
HWP를 보려고 오픈소스 오피스 프로그램으로 렌더하는 것은 판정이 되지 않습니다. 기록에 따르면 그 프로그램은 한글 문서를 제대로 그리지 못해서, 거기서 깨진 것이 원본 문제인지 렌더 문제인지 가를 수 없기 때문입니다. 리눅스 기계라면 HOP이나 한컴의 웹 문서 서비스로 봅니다.
사람에게 HWPX를 넘길 때는 PDF 변환본과 본문 발췌를 같이 넘깁니다. 받는 사람에게 한글 프로그램이 없을 수 있다는 것을 알면서 HWPX 하나만 보내는 일은 다시 하지 않기로 했습니다.
워드 표의 셀 병합은 행마다 셀 수를 세어 검산합니다. 기록에 따르면 행을 합치는 계산이 한 칸 어긋나서, 한 회차의 셀이 다음 회차 자리까지 내려가 있었습니다. 행마다 셀 개수를 세고 같은 글자가 두 번 나오는 셀을 찾자 이 밀림이 잡혔습니다. 글자만 뽑아서는 이런 밀림이 보이지 않습니다.
오피스 프로그램이 망가져 워드를 그림으로 뜰 수 없던 날에는 pandoc으로 HTML을 만들고, 표 테두리와 한글 글꼴 스타일을 넣어 브라우저로 화면을 떠서 봤습니다. 다만 pandoc이 만든 HTML은 셀 너비를 반영하지 않아서, 글자가 칸을 넘치는지 마지막으로 확인하는 일은 워드나 구글 문서에서 했습니다.
2. 양식의 꼴은 누가 채우는지가 정한다
한 교육기관의 활동가가 만든 자동화 산출물을 검토할 양식을 요청받은 기록이 있습니다. 처음에는 사람이 빈칸을 채우는 온라인 설문 양식으로 설계했습니다. 그런데 그 활동가도 자기 AI에게 물어서 양식을 채울 것이라는 지적을 받고 설계를 바꿨습니다.
AI가 채우는 양식이라면 설문 양식은 최악입니다. AI가 설문 화면을 채울 수 없으니 사람이 AI의 답을 설문 칸에 옮겨 적는 이중 수고가 생깁니다. 그래서 AI에 그대로 붙여 넣을 수 있는 글 한 덩어리로 바꿨습니다. 작성 지시와 출력 형식을 한데 묶은 것입니다.
AI는 「잘 작동합니다」처럼 그럴듯한 말을 지어내기 쉽다고 품앗이는 봅니다. 그래서 양식에 근거 칸을 반드시 두었습니다. 모든 주장 옆에 코드 위치, 실행 결과, 화면 캡처 같은 출처를 적게 하고, 근거가 없으면 「미검증」이라고 쓰게 했습니다. 그러면 검토하는 사람이 받자마자 거를 수 있습니다. 양식을 설계할 때 먼저 묻는 질문은 이것입니다. 이 양식을 누가, 무엇으로 채우는가?
3. 중간본 숫자를 문서에 손으로 적지 않는다
한 의료복지사협의 소견서 작성 규칙을 만든 기록입니다. 일부 데이터로 만든 중간본 규칙 문서에 문장 틀 수, 규칙 표 행 수, 전체 건수를 손으로 적었습니다. 전체 데이터로 다시 돌리자 다른 산출물의 숫자는 다 바뀌었는데, 그 문서 안 숫자만 중간본 그대로였습니다. 동료 AI가 그 문서를 검토하며 다섯 군데를 짚었고, 짚은 것이 전부 맞았습니다.
고친 방법은 문서에 숫자가 들어갈 자리를 비워 두고, 문서를 만드는 프로그램이 표의 행 수를 세어 그 자리를 채우게 한 것입니다. 손으로 적은 숫자는 중간본이 최종본이 되는 순간 반드시 어긋난다고 그 기록은 적습니다.
같은 작업에서 산출물을 입력 파일 위에 덮어쓰는 바람에, 다음 실행 때 프로그램이 그 산출물을 다시 입력으로 읽어 머리글과 개념표가 두 번 들어갔습니다. 산출물과 입력은 다른 경로에 두고, 같은 경로를 써야 한다면 프로그램이 여러 번 돌아도 결과가 같게 만듭니다.
남은 시간도 짐작으로 말하지 않습니다. 그 작업의 중간 보고에 「남은 분량 약 1시간 10분」이라고 적었는데, 실제 처리 속도로 계산하니 2시간이었습니다. 남은 건수를 실제로 잰 처리 속도로 나눠서 말합니다.
처방 정리
- 완료는 받는 사람이 여는 프로그램에서 그려진 화면으로 판정한다.
- 한글 문서를 넘길 때는 PDF 변환본과 본문 발췌를 같이 넘긴다.
- 셀 병합은 행마다 셀 수와 중복 글자로 검산한다.
- AI가 채울 양식은 붙여 넣는 글 한 덩어리로 만들고, 근거 칸을 둔다.
- 문서 속 숫자는 생성기가 세게 하고, 산출물을 입력 위에 덮어쓰지 않는다.
- 남은 시간은 남은 건수를 잰 속도로 나눠서 말한다.
도구 메모
- HWPX 점검:
rhwp dump로 본문을,hwpxctl validate로 구조를 본 뒤 HOP으로 연다. - 워드 화면 뜨기:
pandoc 문서.docx -o 문서.html --standalone으로 만든 뒤 머리에 표 테두리와 한글 글꼴 스타일을 넣고, 브라우저 자동화 도구로 전체 화면을 뜬다. - 셀 병합 검산: 표를 행 단위로 읽어 행마다 셀 수와 바로 아래 행과 같은 글자가 있는지를 출력한다.
관련 노드
- 허브: 한글 문서를 AI로 다루기
- HWP 읽기: 표 안 글자를 잃지 마라
- HWPX 고치고 만들기
- 워드, 구글 문서, PDF로 낼 때
- 라이브를 실험장으로 쓰지 마라: 7절 「눈으로 보는 결과물은 그려서 본다」가 이 글의 1절과 같은 원칙입니다.
- 「끝났다」를 무엇으로 판정하나
- AI에게 문서교정을 맡길 때, 검산과 빨간펜