Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

이경규·2026년 7월 30일

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

EPUB 제작은 “문서를 변환해 .epub 확장자를 붙이는 일”이 아니다. 원고, 이미지, 목차, 메타데이터, 읽기 순서, 압축 구조가 서로 맞아야 하는 작은 웹사이트 패키징 작업에 가깝다. 변환 도구가 만든 첫 결과물은 초안이고, 검증과 수동 점검을 통과한 파일이 최종본이다.

얼마전 송도에서 열렸던 Vibe!Dive! 컨퍼런스에서 한빛 에디터님의 발표를 듣고 이전에 나 역시 책을 쓰고 epub 를 만들며 레퍼런스가 거의 없고 옛날 방식의 툴을 사용하는 방식이라 시행착오를 거쳤던 과정들이 생각나 이번 기회에 한번 정리해본다.

이 글은 특정 책의 제목·저자·출판사·ISBN·로컬 경로를 쓰지 않는다. 아래의 도서명, 저자명, 출판사명, ISBN은 모두 채워 넣을 자리표시자다. 공공기관 지원사업이나 공모전 제출 전에는 반드시 해당 연도 공고문과 검수 안내가 이 글보다 우선한다.

전체 흐름부터 잡자

원고·권리·표지 준비
        ↓
초안 EPUB 변환 또는 XHTML 패키지 생성
        ↓
Codex 구조 점검과 최소 수정
        ↓
EPUBCheck 자동 검증
        ↓
Sigil 수동 점검 + 실제 리더 확인
        ↓
공고문 제출 규격·권리·증빙 대조
        ↓
읽기 전용 최종 EPUB 보관·제출

중요한 원칙은 하나다. 생성용 작업 폴더, 검수용 복사본, 제출용 최종 파일을 분리한다. 자동 수정과 Sigil의 복구 기능을 원본에 바로 적용하면 원인을 추적하기 어렵고, 나중에 재제작하기도 힘들어진다.

1. 처음 한 번 설치할 도구

필수 1: Java + EPUBCheck

EPUBCheck는 EPUB의 패키지 구조, XHTML, OPF, 링크, 목차, 미디어 타입 등을 검사하는 표준 검증 도구다. macOS에서 먼저 Java가 있는지 확인한다.

java --version

명령을 찾지 못하면 Java 런타임을 설치한다. Homebrew를 이미 쓰는 경우에는 다음처럼 설치할 수 있다.

brew install --cask temurin
java --version

EPUBCheck는 Homebrew로 설치하는 방법이 가장 간단하다.

brew install epubcheck
epubcheck --version

Homebrew를 쓰지 않는다면 EPUBCheck 공식 배포 ZIP을 내려받아 압축을 풀고, 그 폴더의 epubcheck.jar와 lib/ 디렉터리를 함께 보관한다.

mkdir -p "$HOME/Tools/epubcheck"
cd "$HOME/Tools/epubcheck"
# 공식 Releases에서 내려받은 epubcheck-버전.zip 파일을 이 폴더에 둔 뒤
unzip epubcheck-버전.zip
java -jar epubcheck.jar --version

공식 문서는 macOS Homebrew 설치와 Java 기반 실행 방법을 함께 안내한다. EPUBCheck 설치 안내

필수 2: Sigil — 마지막 수동 점검용

Sigil은 EPUB을 열어 목차, XHTML, CSS, 이미지, 메타데이터를 사람이 직접 보는 편집기다. 자동 검사를 대체하지 않고, 자동 검사가 못 잡는 화면·목차·읽기 흐름 문제를 잡는 마지막 관문으로 쓴다.

Sigil 공식 다운로드에서 내 Mac 칩에 맞는 macOS 설치 파일을 받는다.
앱을 Applications로 옮긴다.
필요하면 공식 Releases의 SHA-256 값과 다운로드 파일을 대조한다.

Sigil의 macOS 지원 버전은 릴리스마다 바뀔 수 있으므로 설치 전 공식 다운로드 페이지를 확인한다. 현재 공식 페이지는 macOS용 Intel/Arm64 설치 파일과 서명 확인 방법을 제공한다.

권장 3: Calibre — 초안 변환과 리더 확인

DOCX·HTML·ODT 같은 원고를 초안 EPUB으로 바꾸거나, 생성한 EPUB을 별도 리더에서 열어 볼 때 쓴다. Calibre 공식 macOS 다운로드에서 앱을 설치한 뒤 응용 프로그램 폴더로 옮긴다.

macOS의 ebook-convert는 보통 앱 번들 안에 있다. 그래서 다음처럼 절대 경로로 먼저 실행하면 PATH 설정 없이도 된다.

"/Applications/calibre.app/Contents/MacOS/ebook-convert" \
  "원고.docx" "초안.epub" \
  --title "도서명" \
  --authors "저자명" \
  --language ko \
  --cover "cover.jpg"

위 명령은 초안을 얻기 위한 시작점이다. 변환 결과의 제목 구조, CSS, 목차가 그대로 제출 기준을 만족한다고 가정하면 안 된다. Calibre의 macOS CLI 위치는 공식 문서에서 확인할 수 있다.

선택 4: Pandoc — Markdown 중심 원고일 때

Markdown에서 HTML/XHTML 초안을 만들고 싶을 때만 설치한다.

brew install pandoc
pandoc --version

Pandoc은 원고 변환 도구일 뿐 EPUB 최종 검수 도구가 아니다. 변환 뒤의 EPUBCheck와 수동 검수는 생략하지 않는다.

2. 폴더부터 안전하게 나누기

my-book/
├── source/                 # 원고·이미지 원본, 수정 금지 백업
├── work/                   # 압축을 풀어 실제로 편집하는 EPUB 구조
├── review/                 # Sigil이 수정해도 되는 검수 복사본
├── dist/                   # 최종 EPUB만 보관
├── evidence/               # EPUBCheck 결과·스크린샷·체크리스트
└── README.md               # 버전, 변경 내역, 검수 결과

source/는 손대지 않는다. work/에서 고치고, 패키징 결과를 dist/에 새 파일명으로 만들며, Sigil은 review/의 복사본만 연다. 그래야 “Sigil이 자동으로 고친 뒤 무엇이 바뀌었는지 모르는” 사고를 피할 수 있다.

기존 EPUB을 작업 폴더로 풀 때는 다음처럼 한다.

mkdir -p work
unzip "source/초안.epub" -d work

압축을 풀었을 때 가장 바깥에는 보통 다음이 있어야 한다.

mimetype
META-INF/container.xml
OEBPS/              # EPUB 3 계열에서 흔한 콘텐츠 폴더 예시

일부 EPUB 2 프로젝트는 OEBPS/ 없이 XHTML·OPF·NCX가 최상위에 놓인다. 기존 구조를 억지로 섞거나 폴더명을 바꾸지 말고, META-INF/container.xml이 가리키는 OPF 위치를 기준으로 유지한다.

3. Codex에게 시킬 일과 시키면 안 되는 일

Codex는 원고를 읽고, 파일 관계를 대조하고, 반복 수정을 정확히 처리하는 데 좋다. 하지만 한 번에 “공모전 통과용 EPUB 만들어줘”라고 던지면 원본 훼손과 과도한 자동 수정이 생길 수 있다. 아래처럼 읽기 → 계획 → 최소 수정 → 검증 순서로 시킨다.

1단계: 읽기 전용 구조 점검 프롬프트

이 EPUB 작업 폴더를 읽기 전용으로 점검해줘.

- META-INF/container.xml이 가리키는 OPF를 찾고
- OPF manifest/spine, 목차(NCX 또는 nav), XHTML 내부 링크를 서로 대조하고
- 이미지·CSS·폰트의 실제 파일과 manifest 누락을 목록화하고
- 수정하지 말고, 오류·위험도·수정 순서만 제안해줘.

특정 도서의 제목, 저자, 출판사, ISBN은 출력하거나 로그에 쓰지 마.

2단계: 최소 수정 프롬프트

앞서 확인한 목록 중 다음 항목만 수정해줘.

1. 모든 XHTML의 xml:lang="ko"와 lang="ko" 누락
2. 목차가 가리키는 앵커와 실제 id 불일치
3. manifest에 없는 실제 패키지 파일 또는 manifest만 있고 없는 파일

원고 문장·표지 이미지·메타데이터 값은 바꾸지 말고,
수정 파일 목록과 각 변경 이유를 보고해줘.
수정 뒤 EPUBCheck를 실행하되, 실패하면 패키지 재생성 대신 오류 원인을 먼저 요약해줘.

3단계: 사람이 맡아야 할 판단

저작권·초상권·폰트·이미지·인용 허가의 보유 여부
공고문에서 요구하는 판형, 파일명, DRM, ISBN, 제출 서류
원고의 사실성·오탈자·문체·독자 적합성
Sigil에서 보이는 줄바꿈, 빈 페이지, 이미지 크기, 표지 인상

Codex가 파일을 고쳐도 이 판단의 책임이 사라지지는 않는다.

4. EPUB 구조에서 반드시 맞춰야 하는 것

`mimetype`: 첫 번째이며 압축하지 않는다

EPUB ZIP의 첫 항목은 정확히 mimetype이어야 하고 압축하지 않는다. 내용은 아래 한 줄이다.

application/epub+zip

`META-INF/container.xml`: OPF의 안내판

이 파일이 패키지의 OPF 위치를 가리킨다. OPF를 다른 폴더로 옮겼다면 여기와 함께 고쳐야 한다.

OPF: 메타데이터·manifest·spine

OPF는 세 역할을 함께 한다.

메타데이터: 제목, 제작자, 언어, 식별자, 출판 정보 등
manifest: 패키지 안에서 실제로 쓰는 XHTML, CSS, 이미지, 폰트, 목차 파일 목록
spine: 독자가 책장을 넘길 실제 읽기 순서

공모·유통 제출이라면 공고문이 요구하는 메타데이터 항목을 빠짐없이 채운다. 다만 연도별 공고가 ISBN·출판사명·표지 크기·EPUB 버전을 다르게 정할 수 있으므로, 이 글의 자리표시자 예시를 그대로 제출하지 않는다.

<dc:title>도서명</dc:title>
<dc:creator>저자명</dc:creator>
<dc:language>ko</dc:language>
<dc:identifier>식별자 또는 ISBN</dc:identifier>

XHTML: 문서가 아니라 XML 규칙으로 작성한다

EPUB 2 호환을 요구하는 경우 특히 XHTML 문법이 중요하다.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko" lang="ko">
<head>
  <title>장 제목</title>
  <link rel="stylesheet" type="text/css" href="../Styles/stylesheet.css"/>
</head>
<body>
  <h1 id="chapter-01">1장. 장 제목</h1>
  <p>본문은 문단 태그로 작성합니다.</p>
</body>
</html>

자주 깨지는 부분은 다음과 같다.

&를 &로 이스케이프하지 않음
<h1>을 열고 </h2>로 닫음
문단 구분을 긴 <br/> 연속으로 처리함
이미지 제목만 있고 실제 h1~h6 제목이 없음
lang 또는 xml:lang 누락
CSS 클래스는 남았는데 정의가 없거나, 사용하지 않는 클래스가 과도하게 남음

목차: EPUB 2는 NCX, EPUB 3은 nav를 기준으로 확인

현재 공고가 EPUB 2를 요구하면 toc.ncx, EPUB 3을 요구하면 XHTML navigation document(nav)가 기준이 된다. 변환기가 두 파일을 함께 만들었다고 해도 실제 spine 순서, 제목, 앵커가 일치하는지 확인한다.

목차 항목 → XHTML 파일 → #id 앵커 → 실제 h1~h6 제목

이 네 단계 중 하나라도 끊기면 자동 검사에 통과해도 독자에게는 깨진 목차가 된다.

5. 안전하게 패키징하기

패키징 전에는 반드시 작업 폴더에서 테스트하고, 제출용 파일은 새 이름으로 만든다. 아래 예시는 mimetype, META-INF, OEBPS 구조를 쓰는 EPUB 3형 프로젝트다.

cd work
mkdir -p ../dist
OUT="../dist/제출전_검수본.epub"

# 실수로 기존 최종본을 덮어쓰지 않게 막는다.
test ! -e "$OUT" || { echo "이미 결과 파일이 있습니다: $OUT"; exit 1; }

# 1) mimetype을 첫 항목·무압축으로 넣는다.
zip -X0 "$OUT" mimetype

# 2) 나머지 파일을 압축한다.
zip -Xr9 "$OUT" META-INF OEBPS

최상위에 XHTML·CSS·OPF·NCX가 있는 EPUB 2형 프로젝트라면 기존 구조를 유지한다.

cd work
mkdir -p ../dist
OUT="../dist/제출전_검수본.epub"
test ! -e "$OUT" || { echo "이미 결과 파일이 있습니다: $OUT"; exit 1; }
zip -X0 "$OUT" mimetype
zip -Xr9 "$OUT" META-INF *.xhtml *.css *.opf *.ncx images

두 명령을 섞어 쓰지 않는다. 특히 mimetype을 나중에 넣거나 일반 압축으로 넣는 실수가 많다.

패키지 첫 항목은 바로 확인한다.

zipinfo -1 "$OUT" | head -n 1
# 기대값: mimetype

6. 자동 검증: EPUBCheck를 통과시켜도 끝이 아니다

epubcheck "dist/제출전_검수본.epub"

Homebrew 설치가 아니라 JAR을 쓰는 경우에는 다음처럼 실행한다.

java -jar "$HOME/Tools/epubcheck/epubcheck.jar" "dist/제출전_검수본.epub"

제출용 목표는 오류 0건, 경고 0건이다. “리더에서 열린다”는 말은 검증 결과가 아니다.

수정이 필요할 때는 다음 순서를 지킨다.

EPUBCheck 메시지 확인
        ↓
원본 EPUB이 아니라 work/의 원인 파일 수정
        ↓
새 파일명으로 재패키징
        ↓
EPUBCheck 재실행
        ↓
결과를 evidence/에 날짜와 함께 저장

오류 메시지를 무작정 정규식으로 일괄 치환하지 않는다. 한 번의 자동 치환으로 제목 닫는 태그나 내부 앵커를 넓게 망가뜨리는 일이 흔하다. 수정 전후의 파일 목록과 EPUBCheck 결과를 남기면 Codex도 다음 오류를 훨씬 정확하게 고칠 수 있다.

패키지 외의 빠른 사전 검사

# XHTML과 OPF·NCX가 XML로 잘 닫혔는지 확인
xmllint --noout work/OEBPS/Text/*.xhtml
xmllint --noout work/OEBPS/package.opf

# 작업 구조가 최상위 EPUB 2형이라면 경로를 그 구조에 맞춘다.
xmllint --noout work/*.xhtml work/*.opf work/*.ncx

이 검사는 모든 EPUB 규격을 대체하지 않는다. XML 문법 실수를 빨리 찾는 용도이고, 최종 판정은 EPUBCheck다.

7. Sigil로 한 번 더 보는 최종 수동 점검

EPUBCheck가 통과해도 독서 화면은 망가질 수 있다. 그래서 최종본을 Sigil용 복사본으로 만들고 다음 순서로 확인한다.

cp "dist/제출전_검수본.epub" "review/수동점검본.epub"

Sigil 점검 순서

review/수동점검본.epub만 Sigil로 연다. source/나 dist/ 원본을 바로 열지 않는다.
Sigil이 구조 복구를 제안하면 메시지를 읽고, 별도 복사본에서만 수락한다. 자동 복구 뒤에는 수정된 파일 목록을 확인한다.
Book Browser에서 XHTML, CSS, 이미지가 빠지지 않았는지 본다.
목차 패널에서 첫 장부터 마지막 장까지 실제 위치로 이동하는지 누른다.
표지, 제목 페이지, 첫 장, 이미지가 많은 장, 표가 있는 장, 마지막 장을 Preview로 확인한다.
다음 항목을 사람 눈으로 판정한다.

확인 항목	통과 기준
표지	잘리지 않고, 세로·가로 화면에서 제목이 읽힘
목차	모든 항목이 실제 장·절의 제목 위치로 이동
제목	장·절의 읽기 계층이 자연스럽고 이미지 제목도 텍스트 제목을 가짐
본문	긴 빈 페이지, 문단 겹침, 과도한 줄바꿈이 없음
이미지·표	작은 화면에서 핵심 글자가 읽히고 잘리지 않음
링크	외부 링크·각주·내부 링크가 의도한 위치로 이동
스타일	한 장만 폰트·여백·정렬이 깨지지 않음

Sigil에서 수정했다면 그 파일을 곧바로 제출하지 않는다. 다시 work/에 변경점을 반영하고, 새 EPUB를 패키징한 뒤 EPUBCheck를 다시 실행한다. Sigil은 화면 점검과 구조 보조 도구이지, 검증 기록을 대신 만드는 도구가 아니다.

가능하면 Apple Books, Calibre Viewer처럼 서로 다른 리더 한 곳에서도 열어 본다. 리더별 CSS 지원이 달라서 한 프로그램에서만 보던 문제를 발견할 수 있다.

8. 공공기관 지원사업·공모전 제출 전 게이트

기술 검수 통과는 선정·통과를 보장하지 않는다. 공모전은 파일 규격 외에도 공고 적합성, 권리, 제출 서류, 납기, 품질을 본다. 따라서 제출 직전에 아래 세 묶음을 분리해 체크한다.

A. 공고문 우선 체크

이번 공고가 요구하는 EPUB 버전(EPUB 2/3), DRM 여부, 파일명, 용량, 표지 규격
ISBN·출판 정보·제작일·접근성 메타데이터의 요구 여부
업로드 방식, 마감 시각, 재제출 가능 여부
결과물 외에 필요한 원고, 계약·권리, 정산·검수 증빙 서류

이 항목은 해마다 바뀌므로 과거 공고나 다른 기관의 체크리스트를 복사해 쓰지 않는다. 현재 공고문을 체크리스트의 첫 줄에 붙인다.

B. 권리·원본성 체크

원고, 표지, 삽화, 사진, 폰트, 인용문, 데이터에 필요한 이용 권한이 있는가
생성형 AI나 외부 소스가 포함됐다면, 해당 공고의 고지·권리 정책과 충돌하지 않는가
출처·라이선스·계약·허가 증빙을 제출 폴더 밖의 안전한 증빙 폴더에 정리했는가
타인의 개인정보, 계정 정보, 비공개 계약 내용을 EPUB이나 검수 스크린샷에 넣지 않았는가

C. 기술·독서 경험 체크

EPUBCheck 0 오류·0 경고 결과를 보관했는가
Sigil과 실제 리더에서 표지·목차·본문·이미지를 확인했는가
mimetype이 첫 항목이며 무압축인지 확인했는가
OPF manifest와 실제 패키지 파일이 일치하는가
spine 읽기 순서와 목차 순서가 일치하는가
최종 파일 해시와 검수 날짜를 기록했는가

shasum -a 256 "dist/제출전_검수본.epub" > evidence/제출전_검수본.sha256
epubcheck "dist/제출전_검수본.epub" > evidence/epubcheck_결과.txt 2>&1

해시는 “내가 검증한 파일”과 “제출한 파일”이 같은지 나중에 확인하게 해 준다. 제목이나 저자명 같은 서지 정보가 노출될 수 있는 공용 스크린샷을 만들 필요는 없다.

9. 제출 직전, Codex에 마지막으로 시킬 검토

다른 에이전트에게 무작정 전체를 고치게 하지 말고, 다음처럼 읽기 전용 최종 검토를 요청한다.

dist/ 안의 EPUB을 읽기 전용으로 최종 검토해줘.

- EPUBCheck 실행 결과를 요약하고
- zip 첫 항목이 mimetype인지 확인하고
- container.xml → OPF → manifest/spine → 목차 → XHTML 앵커 연결을 점검하고
- 개인정보·비밀값·로컬 절대 경로가 EPUB 본문이나 메타데이터에 들어갔는지 확인해줘.

파일을 수정·재패키징·외부 업로드하지 말고,
통과/보류와 보류 사유만 짧게 보고해줘.

이 검토가 끝나면 제출 파일을 다시 만들지 않는다. 수정이 필요할 때만 work/로 돌아가 새 버전을 만들고, EPUBCheck와 Sigil 점검을 처음부터 반복한다.

최종 체크리스트

[ ] 원고·이미지·폰트의 권리와 공고 적합성 확인
[ ] 작업용·검수용·제출용 파일 분리
[ ] container.xml이 올바른 OPF를 가리킴
[ ] OPF의 metadata / manifest / spine 정합
[ ] XHTML의 XML 문법, lang, 제목 계층, 내부 링크 확인
[ ] 목차(NCX 또는 nav)와 실제 앵커·읽기 순서 일치
[ ] mimetype 첫 항목·무압축 패키징
[ ] EPUBCheck 0 오류·0 경고
[ ] Sigil에서 표지·목차·본문·이미지 수동 점검
[ ] 다른 리더 한 곳에서 재확인
[ ] 공고문 제출 규격·권리·서류 대조
[ ] EPUBCheck 결과와 최종 파일 SHA-256 보관

EPUB은 자동화하기 좋은 형식이지만, 제출 품질은 자동화만으로 나오지 않는다. Codex는 반복 검사와 파일 관계 정리에 쓰고, EPUBCheck는 규격에 쓰고, Sigil과 실제 리더는 사람 눈의 최종 검수에 쓰면 된다. 이 세 역할을 분리하면 “열리기는 하는 EPUB”이 아니라, 재현 가능하게 검증한 제출용 EPUB을 만들 수 있다.

공식 참고 자료

이경규

iOS 앱 개발자

이전 포스트

GPT-5.6 멀티 에이전트 실전 사용법: Codex에서 여러 AI 개발자를 병렬로 일시키는 방법

다음 포스트

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

전체 흐름부터 잡자

1. 처음 한 번 설치할 도구

필수 1: Java + EPUBCheck

필수 2: Sigil — 마지막 수동 점검용

권장 3: Calibre — 초안 변환과 리더 확인

선택 4: Pandoc — Markdown 중심 원고일 때

2. 폴더부터 안전하게 나누기

3. Codex에게 시킬 일과 시키면 안 되는 일

1단계: 읽기 전용 구조 점검 프롬프트

2단계: 최소 수정 프롬프트

3단계: 사람이 맡아야 할 판단

4. EPUB 구조에서 반드시 맞춰야 하는 것

`mimetype`: 첫 번째이며 압축하지 않는다

`META-INF/container.xml`: OPF의 안내판

OPF: 메타데이터·manifest·spine

XHTML: 문서가 아니라 XML 규칙으로 작성한다

목차: EPUB 2는 NCX, EPUB 3은 nav를 기준으로 확인

5. 안전하게 패키징하기

6. 자동 검증: EPUBCheck를 통과시켜도 끝이 아니다

패키지 외의 빠른 사전 검사

7. Sigil로 한 번 더 보는 최종 수동 점검

Sigil 점검 순서

8. 공공기관 지원사업·공모전 제출 전 게이트

A. 공고문 우선 체크

B. 권리·원본성 체크

C. 기술·독서 경험 체크

9. 제출 직전, Codex에 마지막으로 시킬 검토

최종 체크리스트

공식 참고 자료

GPT-5.6 멀티 에이전트 실전 사용법: Codex에서 여러 AI 개발자를 병렬로 일시키는 방법

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

0개의 댓글

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지

전체 흐름부터 잡자

1. 처음 한 번 설치할 도구

필수 1: Java + EPUBCheck

필수 2: Sigil — 마지막 수동 점검용

권장 3: Calibre — 초안 변환과 리더 확인

선택 4: Pandoc — Markdown 중심 원고일 때

2. 폴더부터 안전하게 나누기

3. Codex에게 시킬 일과 시키면 안 되는 일

1단계: 읽기 전용 구조 점검 프롬프트

2단계: 최소 수정 프롬프트

3단계: 사람이 맡아야 할 판단

4. EPUB 구조에서 반드시 맞춰야 하는 것

mimetype: 첫 번째이며 압축하지 않는다

META-INF/container.xml: OPF의 안내판

OPF: 메타데이터·manifest·spine

XHTML: 문서가 아니라 XML 규칙으로 작성한다

목차: EPUB 2는 NCX, EPUB 3은 nav를 기준으로 확인

5. 안전하게 패키징하기

6. 자동 검증: EPUBCheck를 통과시켜도 끝이 아니다

패키지 외의 빠른 사전 검사

7. Sigil로 한 번 더 보는 최종 수동 점검

Sigil 점검 순서

8. 공공기관 지원사업·공모전 제출 전 게이트

A. 공고문 우선 체크

B. 권리·원본성 체크

C. 기술·독서 경험 체크

9. 제출 직전, Codex에 마지막으로 시킬 검토

최종 체크리스트

공식 참고 자료

GPT-5.6 멀티 에이전트 실전 사용법: Codex에서 여러 AI 개발자를 병렬로 일시키는 방법

Long-Horizon Agent 설계: Codex와 Claude가 몇 시간·며칠짜리 작업을 끝까지 이어가는 방법

0개의 댓글

`mimetype`: 첫 번째이며 압축하지 않는다

`META-INF/container.xml`: OPF의 안내판