목록으로
업무 생산성 개선을 위한 AI 활용
‘통과’ 전에 실패본부터 넣었다 — Codex로 만든 한글 PDF 3층 교차검증
PDF 구조·추출 텍스트·페이지 이미지를 교차 확인하고, 알려진 깨짐을 먼저 넣어 검사기가 실제로 잡는지 검증한 실패우선 문서 QA 사례입니다.
🤖 활용 AI 도구
OpenAI Codex 데스크톱
### 1. 어떤 상황에서 AI를 활용했나요?
2026년 8월 30일, 다른 공모전의 공식 HWP에서 작성 항목을 확인해 검토 가능한 작품 시안을 제작하는 작업을 진행했습니다. HWP를 일반 방식으로 PDF에 직접 변환한 첫 결과는 원래 의도와 달리 204쪽까지 늘어났고, 본문 한글도 누락되었습니다. 이 직접 변환 경로는 폐기했습니다. 이후 공식 항목을 근거로 내용을 별도 DOCX에 새로 작성해 A4 5쪽 시안으로 만들었습니다. 두 결과물은 같은 파일을 축소한 것이 아니라 서로 다른 제작 경로의 산출물입니다.
이 경험에서 가장 큰 문제는 ‘파일이 열리는가’만으로는 문서가 정상인지 판단할 수 없다는 점이었습니다. 페이지가 비정상적으로 늘거나 한글이 사라져도 변환 프로그램은 완료로 표시할 수 있습니다. 그래서 변환을 반복하는 대신, 공식 원본을 기준으로 결과를 서로 다른 증거에서 확인하는 QA 절차를 만들었습니다.
### 2. 어떤 AI를 어떻게 활용했나요?
OpenAI Codex 데스크톱을 단순 문장 작성기가 아니라 문서 QA 오케스트레이터로 사용했습니다. 204쪽 비정상 변환본은 사용하지 않고 공식 원본을 보존했습니다. 이후 공식 HWP의 작성 항목을 확인하고, 그 항목에 맞춰 새 DOCX 작품 시안을 제작했습니다. 문서 생성은 python-docx, PDF 변환은 LibreOffice, 구조·텍스트 검사는 pypdf, 페이지 렌더는 Poppler, 잉크 비율 계산은 Pillow를 사용했습니다.
새 DOCX를 A4 PDF로 렌더링한 뒤 다음 검사를 연속으로 실행했습니다.
1. PDF가 strict parse에서 오류 없이 열리는지 확인
2. 내부 목표 페이지 수인 5쪽인지 확인
3. 작업자가 회귀 기준으로 정한 핵심 문자열 7개가 모두 추출되는지 확인
4. 한글 글리프와 PDF 내 폰트 포함 여부 확인
5. 공식 원본과 결과 파일의 SHA-256 해시 기록
6. 렌더링한 모든 페이지를 눈으로 확인해 잘림·빈 페이지·겹침·깨진 글자 점검
AI가 문서를 만든 뒤 스스로 ‘괜찮다’고 선언하게 하지 않았습니다. PDF 구조, PDF 추출 텍스트, 페이지 이미지라는 3층을 중심으로 폰트와 파일 동일성 확인용 해시까지 대조하게 했습니다. 공식 원본 보존은 이 3층 검사의 바깥에서 별도 원칙으로 유지했습니다.
여기서 한 단계 더 나아가 검사기 자체를 시험했습니다. 최종본은 그대로 두고 복제본에 ① 내부 핵심 문구 1개 교체, ② 끝에 본문 없는 페이지 1쪽 추가라는 두 결함을 통제해 넣었습니다. 여기에 실제 작업에서 발생했던 ③ 한글 글꼴 경로 오류의 1쪽 재현본을 비교했습니다. 결함이 무엇인지 아는 상태에서 각 검사가 실제로 경고하는지 확인했습니다.
### 3. 활용 결과 어떤 변화가 있었나요?
직접 변환 결과는 204쪽이었고 한글이 누락되어 사용할 수 없었습니다. 그 경로를 폐기하고, 공식 항목을 근거로 별도 DOCX를 새로 작성해 A4 5쪽 PDF 시안으로 정리했습니다. 최종 시안은 strict parse를 통과했고 내부 핵심 문자열 7개와 포함 폰트를 확인했으며 파일 동일성·이력 확인을 위해 해시도 기록했습니다.
실패 주입 결과도 남겼습니다. 문구 교체는 내부 핵심 문자열 비교가 잡았습니다. 본문 없는 추가 페이지는 목표 5쪽과 실제 6쪽의 불일치, 그리고 마지막 쪽 잉크 비율 0.2293%가 내부 저잉크 기준 1%보다 낮아 탐지했습니다. 실제 글꼴 경로 오류의 동일 1쪽 재현본은 정상본보다 잉크가 38.8% 줄었지만 검사에 둔 ‘50% 감소’ 고정 규칙은 놓쳤고, 사람이 1쪽 비교 이미지를 보고 발견했습니다. 이후 정상 최종본은 전 페이지를 시각 검수했습니다. 이 미탐 결과를 숨기지 않고 기록하면서 ‘자동 규칙만으로 충분하다’는 가정을 버렸습니다.
가장 큰 변화는 ‘변환 완료’를 ‘작업 완료’로 보지 않게 된 것입니다. 페이지 수, 핵심 문구, 파싱, 폰트, 렌더 가운데 하나라도 기준을 충족하지 못하면 결과를 사용하지 않는 방식으로 바뀌었습니다. 같은 계열의 QA를 구조가 다른 13쪽 문서에도 적용해 전 페이지 검수를 마쳤습니다.
### 4. 나만의 방식 또는 개선 포인트는 무엇인가요?
첫째, 정상의 기준을 파일 생성 여부가 아니라 검증 가능한 내부 조건으로 바꿨습니다. 이 사례의 합격 기준은 ‘목표 A4 5쪽, 내부 핵심 문자열 7개, strict parse 통과, 한글 폰트 확인, 해시 기록’이었습니다. 5쪽과 7개는 공고의 공식 요건이 아니라 이 작품에 맞춰 작업자가 정한 회귀 기준입니다. 그리고 정상본을 믿기 전에 알려진 결함 복제본을 넣어 검사기가 경고하는지도 확인했습니다.
둘째, 한 가지 검사에 의존하지 않았습니다. 텍스트 추출만 보면 배치가 깨진 사실을 놓칠 수 있고, 화면만 보면 문자열 누락을 놓칠 수 있습니다. 실제로 고정 50% 잉크 감소 규칙은 동일 1쪽의 한글 누락을 놓쳤습니다. 그래서 결정론적 규칙은 페이지 수·내부 핵심 문구·파싱을 맡고, Codex는 페이지 이미지의 누락·잘림·겹침 후보를 찾으며, 사람은 원본과 정상 최종본의 전 페이지를 대조해 최종 승인하도록 역할을 나눴습니다.
셋째, 같은 실패를 반복하지 않았습니다. HWP 직접 변환이 204쪽을 만든 즉시 그 경로를 폐기하고 공식 항목 확인과 새 DOCX 제작으로 바꿨습니다. 중간 렌더에서 한글 글리프가 누락됐을 때도 내용 재작성 대신 변환기가 인식하는 한글 글꼴 경로를 바로잡았습니다.
넷째, 원본과 작업본을 분리했습니다. 공식 HWP 원본은 수정하지 않고 보존하며 최종 DOCX·PDF의 해시를 남겼습니다. 이 방식이 모든 오류를 자동으로 없애지는 않지만, ‘열리지만 잘못된 문서’를 마지막까지 놓치는 위험을 줄이고 사람이 확인할 지점을 분명하게 만듭니다.
### 5. 다른 사람도 따라 할 수 있나요?
1. 공식 원본을 별도 폴더에 보존하고 SHA-256 해시를 기록합니다.
2. 목표 페이지 범위, 내부 핵심 문구, 용지 크기, 필요한 글꼴처럼 합격 조건을 먼저 적습니다. 이 값들이 공식 요건인지 내부 회귀 기준인지 구분합니다.
3. 직접 변환 결과가 비정상이면 같은 방식의 재시도를 중단하고 형식에 맞는 전용 추출 경로로 내용을 확보합니다.
4. 원본의 항목·요건을 뼈대로 DOCX를 제작합니다. 새 제안 문장·수치는 목표 또는 가정으로 구분하고, 확인되지 않은 사실은 추가하지 않습니다.
5. PDF로 렌더링하고 모든 페이지 이미지를 확인합니다.
6. strict parse, 페이지 수, 내부 핵심 문자열, 폰트, 해시를 자동 검사합니다.
7. 최종본의 복제본에 핵심 문구 누락·본문 없는 추가 페이지·글꼴 누락 같은 알려진 결함을 하나씩 넣고, 각 검사가 실제로 경고하는지 확인합니다.
8. 규칙 검사가 놓친 시각 오류는 페이지 이미지 검수에서 찾고, 사람이 원본과 비교해 수정 여부를 결정합니다.
9. 조건 하나라도 실패하면 최종 폴더로 옮기지 않고 원인 단계로 돌아갑니다.
다른 문서에서는 ‘5쪽’과 ‘7개’만 해당 원본에 맞게 바꾸면 같은 절차를 적용할 수 있습니다. 핵심은 AI에게 글을 잘 쓰라고만 요청하는 것이 아니라, 실패 조건과 확인 증거를 먼저 주는 것입니다.
2026년 8월 30일, 다른 공모전의 공식 HWP에서 작성 항목을 확인해 검토 가능한 작품 시안을 제작하는 작업을 진행했습니다. HWP를 일반 방식으로 PDF에 직접 변환한 첫 결과는 원래 의도와 달리 204쪽까지 늘어났고, 본문 한글도 누락되었습니다. 이 직접 변환 경로는 폐기했습니다. 이후 공식 항목을 근거로 내용을 별도 DOCX에 새로 작성해 A4 5쪽 시안으로 만들었습니다. 두 결과물은 같은 파일을 축소한 것이 아니라 서로 다른 제작 경로의 산출물입니다.
이 경험에서 가장 큰 문제는 ‘파일이 열리는가’만으로는 문서가 정상인지 판단할 수 없다는 점이었습니다. 페이지가 비정상적으로 늘거나 한글이 사라져도 변환 프로그램은 완료로 표시할 수 있습니다. 그래서 변환을 반복하는 대신, 공식 원본을 기준으로 결과를 서로 다른 증거에서 확인하는 QA 절차를 만들었습니다.
### 2. 어떤 AI를 어떻게 활용했나요?
OpenAI Codex 데스크톱을 단순 문장 작성기가 아니라 문서 QA 오케스트레이터로 사용했습니다. 204쪽 비정상 변환본은 사용하지 않고 공식 원본을 보존했습니다. 이후 공식 HWP의 작성 항목을 확인하고, 그 항목에 맞춰 새 DOCX 작품 시안을 제작했습니다. 문서 생성은 python-docx, PDF 변환은 LibreOffice, 구조·텍스트 검사는 pypdf, 페이지 렌더는 Poppler, 잉크 비율 계산은 Pillow를 사용했습니다.
새 DOCX를 A4 PDF로 렌더링한 뒤 다음 검사를 연속으로 실행했습니다.
1. PDF가 strict parse에서 오류 없이 열리는지 확인
2. 내부 목표 페이지 수인 5쪽인지 확인
3. 작업자가 회귀 기준으로 정한 핵심 문자열 7개가 모두 추출되는지 확인
4. 한글 글리프와 PDF 내 폰트 포함 여부 확인
5. 공식 원본과 결과 파일의 SHA-256 해시 기록
6. 렌더링한 모든 페이지를 눈으로 확인해 잘림·빈 페이지·겹침·깨진 글자 점검
AI가 문서를 만든 뒤 스스로 ‘괜찮다’고 선언하게 하지 않았습니다. PDF 구조, PDF 추출 텍스트, 페이지 이미지라는 3층을 중심으로 폰트와 파일 동일성 확인용 해시까지 대조하게 했습니다. 공식 원본 보존은 이 3층 검사의 바깥에서 별도 원칙으로 유지했습니다.
여기서 한 단계 더 나아가 검사기 자체를 시험했습니다. 최종본은 그대로 두고 복제본에 ① 내부 핵심 문구 1개 교체, ② 끝에 본문 없는 페이지 1쪽 추가라는 두 결함을 통제해 넣었습니다. 여기에 실제 작업에서 발생했던 ③ 한글 글꼴 경로 오류의 1쪽 재현본을 비교했습니다. 결함이 무엇인지 아는 상태에서 각 검사가 실제로 경고하는지 확인했습니다.
### 3. 활용 결과 어떤 변화가 있었나요?
직접 변환 결과는 204쪽이었고 한글이 누락되어 사용할 수 없었습니다. 그 경로를 폐기하고, 공식 항목을 근거로 별도 DOCX를 새로 작성해 A4 5쪽 PDF 시안으로 정리했습니다. 최종 시안은 strict parse를 통과했고 내부 핵심 문자열 7개와 포함 폰트를 확인했으며 파일 동일성·이력 확인을 위해 해시도 기록했습니다.
실패 주입 결과도 남겼습니다. 문구 교체는 내부 핵심 문자열 비교가 잡았습니다. 본문 없는 추가 페이지는 목표 5쪽과 실제 6쪽의 불일치, 그리고 마지막 쪽 잉크 비율 0.2293%가 내부 저잉크 기준 1%보다 낮아 탐지했습니다. 실제 글꼴 경로 오류의 동일 1쪽 재현본은 정상본보다 잉크가 38.8% 줄었지만 검사에 둔 ‘50% 감소’ 고정 규칙은 놓쳤고, 사람이 1쪽 비교 이미지를 보고 발견했습니다. 이후 정상 최종본은 전 페이지를 시각 검수했습니다. 이 미탐 결과를 숨기지 않고 기록하면서 ‘자동 규칙만으로 충분하다’는 가정을 버렸습니다.
가장 큰 변화는 ‘변환 완료’를 ‘작업 완료’로 보지 않게 된 것입니다. 페이지 수, 핵심 문구, 파싱, 폰트, 렌더 가운데 하나라도 기준을 충족하지 못하면 결과를 사용하지 않는 방식으로 바뀌었습니다. 같은 계열의 QA를 구조가 다른 13쪽 문서에도 적용해 전 페이지 검수를 마쳤습니다.
### 4. 나만의 방식 또는 개선 포인트는 무엇인가요?
첫째, 정상의 기준을 파일 생성 여부가 아니라 검증 가능한 내부 조건으로 바꿨습니다. 이 사례의 합격 기준은 ‘목표 A4 5쪽, 내부 핵심 문자열 7개, strict parse 통과, 한글 폰트 확인, 해시 기록’이었습니다. 5쪽과 7개는 공고의 공식 요건이 아니라 이 작품에 맞춰 작업자가 정한 회귀 기준입니다. 그리고 정상본을 믿기 전에 알려진 결함 복제본을 넣어 검사기가 경고하는지도 확인했습니다.
둘째, 한 가지 검사에 의존하지 않았습니다. 텍스트 추출만 보면 배치가 깨진 사실을 놓칠 수 있고, 화면만 보면 문자열 누락을 놓칠 수 있습니다. 실제로 고정 50% 잉크 감소 규칙은 동일 1쪽의 한글 누락을 놓쳤습니다. 그래서 결정론적 규칙은 페이지 수·내부 핵심 문구·파싱을 맡고, Codex는 페이지 이미지의 누락·잘림·겹침 후보를 찾으며, 사람은 원본과 정상 최종본의 전 페이지를 대조해 최종 승인하도록 역할을 나눴습니다.
셋째, 같은 실패를 반복하지 않았습니다. HWP 직접 변환이 204쪽을 만든 즉시 그 경로를 폐기하고 공식 항목 확인과 새 DOCX 제작으로 바꿨습니다. 중간 렌더에서 한글 글리프가 누락됐을 때도 내용 재작성 대신 변환기가 인식하는 한글 글꼴 경로를 바로잡았습니다.
넷째, 원본과 작업본을 분리했습니다. 공식 HWP 원본은 수정하지 않고 보존하며 최종 DOCX·PDF의 해시를 남겼습니다. 이 방식이 모든 오류를 자동으로 없애지는 않지만, ‘열리지만 잘못된 문서’를 마지막까지 놓치는 위험을 줄이고 사람이 확인할 지점을 분명하게 만듭니다.
### 5. 다른 사람도 따라 할 수 있나요?
1. 공식 원본을 별도 폴더에 보존하고 SHA-256 해시를 기록합니다.
2. 목표 페이지 범위, 내부 핵심 문구, 용지 크기, 필요한 글꼴처럼 합격 조건을 먼저 적습니다. 이 값들이 공식 요건인지 내부 회귀 기준인지 구분합니다.
3. 직접 변환 결과가 비정상이면 같은 방식의 재시도를 중단하고 형식에 맞는 전용 추출 경로로 내용을 확보합니다.
4. 원본의 항목·요건을 뼈대로 DOCX를 제작합니다. 새 제안 문장·수치는 목표 또는 가정으로 구분하고, 확인되지 않은 사실은 추가하지 않습니다.
5. PDF로 렌더링하고 모든 페이지 이미지를 확인합니다.
6. strict parse, 페이지 수, 내부 핵심 문자열, 폰트, 해시를 자동 검사합니다.
7. 최종본의 복제본에 핵심 문구 누락·본문 없는 추가 페이지·글꼴 누락 같은 알려진 결함을 하나씩 넣고, 각 검사가 실제로 경고하는지 확인합니다.
8. 규칙 검사가 놓친 시각 오류는 페이지 이미지 검수에서 찾고, 사람이 원본과 비교해 수정 여부를 결정합니다.
9. 조건 하나라도 실패하면 최종 폴더로 옮기지 않고 원인 단계로 돌아갑니다.
다른 문서에서는 ‘5쪽’과 ‘7개’만 해당 원본에 맞게 바꾸면 같은 절차를 적용할 수 있습니다. 핵심은 AI에게 글을 잘 쓰라고만 요청하는 것이 아니라, 실패 조건과 확인 증거를 먼저 주는 것입니다.
