도움말 · 평가 측정표

왜인쇄 가이드는 틀리면 비용이 드는 정보입니다(도련 3mm, 잉크량 한도 같은 값). LLM이 문장을 새로 만들면 그럴듯하지만 틀린 값이 섞일 수 있어서, 답을 만들지 않고 가이드 원문 절을 찾아 그대로 보여 주는 쪽을 택했습니다. 대신 사용자가 가이드와 다른 단어로 물어도 찾아야 하니 단어 일치만으로는 부족했습니다.

어떻게자르기(청킹) 4종 × 임베딩 모델 4종을 질문 92개로 비교하고 임베딩(dense)과 단어 검색(2-gram BM25)을 각각 z-정규화해 0.5 : 0.5로 섞었습니다. 브라우저에서 돌리려고 multilingual-e5-small의 int8 ONNX(약 118MB)를 씁니다.

결과섞어 쓰기(하이브리드)가 MRR@10 0.98 수준으로 가장 좋았습니다. 2.3GB짜리 큰 모델(bge-m3·KURE-v1)과의 차이는 95% 구간이 겹쳐 구분되지 않았습니다. 그래서 브라우저에 올릴 수 있는 작은 모델로 정했습니다.

왜화면의 RGB는 인쇄 CMYK보다 넓은 색을 표현합니다. 어떤 색이 인쇄에서 얼마나 달라질지 찍기 전에 보여 주려면 변환을 직접 계산해야 합니다.

어떻게PDF 안 이미지 픽셀을 sRGB로 봅니다. 그다음 종이에 맞는 CMYK ICC 프로파일로 변환(LittleCMS wasm)한 뒤 다시 Lab으로 읽어 원본과 ΔE2000을 잽니다. 이미지가 인쇄 면적에서 차지하는 비율로 가중해 문서 전체 값도 냅니다. 종이 등급별 공개 프로파일 12개(ECI·ICC 레지스트리)를 씁니다.

결과같은 계산을 Python(Pillow의 LittleCMS)에서 따로 돌려 대조했고 값이 일치했습니다. 공개 테스트 사진 8장으로는 종이별 차이를 쟀습니다 (코팅지 평균 ΔE 4.48, 비코팅지 9.71, 판지 2.79 — 종이 색을 포함한 절대 비색 기준).

왜브랜드 종이를 직접 측정한 공개 프로파일이 없습니다. 없는 데이터를 있는 것처럼 쓰지 않으려고, 같은 등급의 공개 프로파일로 근사하고 근사했다고 화면에 표시합니다.

어떻게분광측색기로 잰 종이 흰색(Lab)을 입력하면, 프로파일이 가정한 종이 흰색에서 그 종이로 인쇄 색을 옮겨 ΔE를 다시 잽니다. 보정식은 측정 프로파일 12쌍을 비교해 골랐습니다(선형 방식이 9쌍에서 가장 좋음).

결과검증 스크립트에서 종이 흰색은 입력한 측정값으로 정확히 옮겨졌습니다. 가장 진한 색은 ΔE 0.1 안에서 그대로 남았습니다.

왜아닙니다. 학습하려면 “이 PDF를 이 종이에 찍었더니 이런 불량이 났다”는 정답 데이터가 필요합니다. 그런데 공개 데이터셋을 찾지 못했습니다 (검색에 걸린 것은 3D 프린팅·PCB·직물 결함이었고 인쇄 결함 논문은 데이터를 공개하지 않았습니다).

어떻게데이터가 없으니 근거 원문을 직접 확인한 점수표로 만들었습니다. 뒷묻음과 눌림, 색판 어긋남, 농도 얼룩이 점수 대상입니다. 점수는 PDF에서 읽은 값(최대 잉크량, 이미지 면적)과 사용자가 고른 종이·평량·후가공으로 매기고 이유마다 출처를 붙입니다.

결과원문과 대조하면서 근거가 틀린 규칙을 뺐습니다(예: ‘제본+코팅지’ 가점 — 원문은 오히려 코팅이 갈라짐을 줄인다고 했습니다). 줄무늬는 인쇄기 쪽 원인이라 예측하지 않습니다. 후가공은 PDF에 정보가 없어서 모를 때는 ‘판단 불가’로 둡니다.

왜맞춤법 교정은 틀린 지적 하나가 신뢰를 깎습니다. 그래서 많이 찾는 쪽(재현율)보다 지적이 맞는 쪽(정밀도)을 먼저 봤고 원고를 자동으로 고치지 않고 제안만 합니다.

결과두 검사 방식이 같은 사전을 봅니다. 오용·외래어 표기 사전은 public/data/korean-misuse.json 하나이고, 브라우저의 ‘바로 검사’와 교정 에이전트가 그 파일을 함께 읽습니다. 한쪽에만 낱말을 더하면 두 방식의 결과가 갈립니다.

결과검사 방식에 따라 얹히는 것이 다릅니다. 에이전트 검사에서는 여기에 Kiwi 오타 모델이 더해지고, 키를 넣으면 LLM 교정까지 붙습니다.

어떻게정답을 아는 평가셋을 만들어 비교했습니다 — 가이드 문단을 묶은 문서 60개에 오류 360개를 일부러 넣고 (사전에 있는 오용/없는 오용/무작위 오타/띄어쓰기/율·률), 규칙·Kiwi 형태소 모델·LLM의 조합 7가지를 쟀습니다. 지표는 오류 단위 재현율과 제안 단위 정밀도, 괄호는 문서 단위 부트스트랩 95% 구간입니다.

왜처음에는 무료 등급으로 끝까지 돌 수 있는지만 봤습니다. 교정은 문서마다 한 번 부르는 작업이니 그걸로 될 줄 알았는데, 실제로는 쪽마다 부릅니다 — 20쪽이면 스무 번입니다.

결과그래서 무료 등급으로는 끝나지 않았습니다. 20쪽짜리 잡지를 맡겼더니 분당 횟수 한도(429)에 걸려 5초·10초·20초를 기다렸다 다시 부르기를 되풀이하다가, 교정에만 116초를 쓰고 결국 실패했습니다. 기다리는 값을 치르는 쪽은 검수가 끝나기를 기다리는 사람입니다.

어떻게지금은 Claude claude-sonnet-5-5가 기본입니다(ANTHROPIC_API_KEY). 오탈자를 찾는 일은 오래 생각할수록 나아지는 종류가 아니라 생각을 끄고 부르고, 더 꼼꼼히 보고 싶으면 PG_LLM_EFFORT를 올립니다. 모델 이름은 ANTHROPIC_LLM_MODEL로 바꿉니다.

결과무료 Gemini는 받쳐 주는 길로 남겼습니다. Claude 열쇠가 없을 때, 그리고 잔액이 바닥났을 때 그쪽으로 넘어갑니다 — 느려도 도는 것이 멈춰 서는 것보다 낫습니다. 넘어가면 그렇게 적어서, 왜 갑자기 느려졌는지 알 수 있게 합니다.

왜한 덩어리로 다 하면 ‘무엇을 근거로 그렇게 판단했는지’가 섞입니다. 부서를 나누면 각자 할 수 있는 일(skill)과 등급이 공개됩니다. 주고받은 요청·결과도 기록에 남습니다.

어떻게총괄(오케스트레이터) 아래 사전 검사·색·종이·가이드·교정·보고서·원본 수정·안전 관문 9개가 각자 포트에서 돕니다. 주고받는 것은 정해진 계약(A2A)뿐입니다. 에이전트는 서로를 부를 때 자기 이름이 든 경로를 붙여 순환 호출과 홉 수를 막고, 모든 요청·결과는 공통 로그에 남습니다(입력 본문은 남기지 않습니다).

결과같은 검사를 ‘바로 검사’와 ‘에이전트 검사’ 두 방식으로 할 수 있습니다. 화면은 같습니다. 인쇄 검수에서 ‘에이전트 검사’를 고르면 바로 아래에서 의뢰별 구간 막대(워터폴)를 볼 수 있습니다. 누가 언제 몇 ms 걸렸는지 나옵니다.

결과켜져 있는 에이전트가 모두 이 검수에 참여하는 것은 아닙니다. 원본 수정(designcraft)은 무엇을 올렸는지에 따라 자리가 바뀝니다 — 편집 파일(IDML)로 맡기면 안전 관문 다음에 서서 교정을 원본에 반영하고, PDF로 맡기면 고칠 원본이 없어 아예 서지 않습니다. 그래서 목록을 ‘이 검수에 참여’와 ‘이 검수에 참여하지 않는 에이전트’로 갈라 두었습니다. 섞어 두면 되는 날과 안 되는 날이 같은 화면으로 보입니다.

왜검수는 PDF로 하는데 PDF는 고칠 수 없습니다. 인디자인이 만든 PDF에서 글자를 집어 바꾸는 길이 없어서, 결국 사람이 원본을 열고 하나씩 다시 찾아 고쳐야 했습니다. 항목이 수십 개면 그 과정에서 빠뜨립니다.

어떻게편집 파일(IDML)로 검수를 맡기면 됩니다. 올린 원본을 DesignCraft가 열어 검수용 PDF를 뽑고, 그 PDF로 검수한 다음, 교정 제안이 있으면 검수가 끝난 자리에서 “원본에 바로 반영할까요?”를 묻습니다. 그렇다고 하면 그 글자를 찾아 바꾸고 PDF와 IDML로 다시 내보냅니다. 교정 한 건마다 다시 찾습니다 — 한글은 글자당 3바이트라 앞을 고치면 뒤 위치가 전부 밀리는데, 다시 찾으면 밀린 자리가 따라옵니다.

결과바뀐 쪽의 수정 전·후를 나란히 보여 주고, 어떤 항목이 반영됐고 무엇이 왜 실패했는지 줄마다 적습니다. 고친 뒤에는 원본 검사를 한 번 더 돌립니다. 한글을 라틴 글꼴 자리에 넣으면 글자가 없고(글리프), 글이 길어지면 넘칩니다.

결과파일 하나보다 폴더째 올리는 편이 좋습니다. IDML은 사진을 링크로만 들고 있어서, 파일 하나만 올리면 인쇄용 사진이 따라오지 않습니다(화면에 보이는 그림은 IDML이 품은 저해상 미리보기라 인쇄에는 못 씁니다). InDesign에서 파일 → 패키지로 만든 폴더를 통째로 올리면 옆의 Links 사진과 Document Fonts 글꼴까지 같이 올라가 그대로 열립니다. 글자 교정만 하고 고친 IDML만 받을 거면 파일 하나로도 됩니다.

왜상태를 바꾸는 행동은 모델이 잘못 판단하면 되돌리기 어렵습니다. 그래서 판단하는 쪽과 실행을 허가하는 쪽을 갈라 두었습니다.

어떻게행동마다 등급을 둡니다 — 조회는 관문 없음, A는 바로 실행, B는 다른 에이전트가 교차 검증해야 실행, C는 사람이 승인해야 실행.

어떻게등급은 요청이 아니라 행동 주인의 공개 카드에서 읽습니다. 요청에 ‘등급 A’라고 적어 보내도 무시합니다.

어떻게그 밖의 거절 조건도 있습니다. 하루 누적 한도를 넘으면 거절하고, 무엇이든 확인되지 않으면 역시 거절합니다(fail-closed).

결과지금 이 앱에서 상태를 바꾸는 행동은 검수 보고서 파일 쓰기(A)와 원본 수정 반영(A) 둘입니다. 그 보고서의 ΔE도 색 에이전트가 다시 계산해 일치할 때만 그대로 적힙니다. B·C 동작(교차 검증, 사람 승인, 승인 기한 만료, 하루 한도)은 코드와 테스트로 남아 있습니다 — 돈이 오가는 행동을 이 앱에 두지 않았기 때문입니다.

결과바로 검사 — 아무 데도 가지 않습니다. PDF 해석·색 변환·검색 모델이 모두 보시는 분의 브라우저 안에서 돕니다. 종이·인쇄소 데이터도 이 앱이 들고 있는 파일이라 받아 갈 것이 없습니다.

결과에이전트 검사 — 만든 사람의 PC로 갑니다. 에이전트는 서버를 빌리지 않고 개발자 PC에서 돕니다(127.0.0.1에서만 듣고, 바깥에는 Cloudflare 터널로 창구 하나만 엽니다). 올린 파일은 그 PC의 폴더에 저장되고, 에이전트끼리는 파일 내용 대신 해시(pdf_ref)만 주고받습니다. 서버가 다시 뜨면 의뢰 목록은 지워집니다.

결과원본 수정에 올린 편집 파일도 같은 PC입니다. 폴더째 올려도 그 PC의 작업 폴더에만 풀립니다. DesignCraft는 그 폴더 밖을 읽지도 쓰지도 못하게 가둬 놓고 띄웁니다(--automation-read-root·--write-root). 고친 PDF와 편집 파일도 같은 폴더에 생깁니다. 받아 갈 수 있는 쪽은 그 의뢰를 넣은 본인뿐입니다.

결과선택 기능 두 개만 밖으로 나갑니다 — LLM 교정을 켜면 교정할 본문이 Claude API로 가고(기본 꺼짐. 잔액이 바닥나면 Gemini API로 넘어갑니다), LangSmith 추적을 켜면 에이전트·소요 시간·관문 결정만 갑니다(본문·입력값은 공통 로그에 애초에 남기지 않아 나갈 것이 없습니다).

왜에이전트는 PC 한 대인데 그 주소는 누구에게나 열려 있습니다. 주인을 가리지 않으면 남의 파일 이름과 소통 기록이 그대로 보이고, 남의 질문에 대신 답까지 할 수 있습니다. 그렇다고 쓰려면 먼저 계정부터 만들라고 하는 것도 과합니다 — 한 번 검수해 보려고 온 사람에게는 그 자체가 벽입니다.

어떻게로그인은 선택입니다. 하지 않아도 검수는 전부 됩니다. 대신 화면을 열면 서버가 난수로 만든 익명 토큰을 하나 내주고, 브라우저가 그것을 localStorage에 둡니다. 누구인지는 담기지 않고, 하는 일은 “이 브라우저가 넣은 의뢰만 이 브라우저에 보인다”뿐입니다.

어떻게로그인하면 그때까지 한 것이 계정으로 옮겨 갑니다. 구글이 서명한 ID 토큰에는 계정마다 고유한 번호(sub)가 들어 있습니다. 그 번호에 묶인 토큰을 새로 받고, 들고 있던 익명 토큰을 서버에 한 번 내밀어 그 토큰 몫의 의뢰를 전부 계정으로 옮깁니다. 옮기고 나면 로컬에 있던 익명 토큰은 지웁니다.

결과그래서 로그인 뒤에는 기기가 바뀌어도 같은 계정으로 들어오면 지난 검수가 그대로 보입니다. 로그인 전에는 그 브라우저를 벗어나지 못합니다 — 사이트 데이터를 지우면 함께 사라집니다.

결과받아 두는 것은 구글 계정 번호와 이름·이메일·프로필 사진뿐입니다. 계정 번호도 그대로 쓰지 않고 서버 비밀로 해시해서 씁니다. 의뢰 기록과 로그에 남는 값이라, 새면 계정 번호까지 같이 샙니다. 이름·이메일·사진은 화면 오른쪽 위에 누구로 로그인했는지 보여 주는 데만 쓰고 서버에 저장하지 않습니다. 비밀번호는 지나가지도 않고, 검사에는 아무것도 쓰지 않습니다.

결과아이디·비밀번호를 직접 받지 않는 이유는 간단합니다 — 받으면 보관해야 하고, 보관하는 순간 샐 것이 생깁니다. 구글이 서명한 ID 토큰의 서명·발급자·청중(이 앱의 클라이언트 ID)·기한만 확인합니다. 청중 확인이 핵심입니다. 그것이 없으면 아무 앱에나 로그인해서 받은 토큰을 그대로 들이밀 수 있습니다.

결과로그인한 토큰은 기한과 함께 이 브라우저에 둡니다. 그래서 새로 고쳐도 로그인이 풀리지 않습니다. 기한이 지난 것은 읽지도 않고, 로그아웃하면 지웁니다. ‘바로 검사’는 계산이 전부 브라우저 안에서 끝나니 보낼 곳도, 가릴 주인도 없습니다. MCP로 들어올 때는 로그인 창을 띄울 수 없어 미리 발급한 토큰을 씁니다.

결과의뢰 목록은 에이전트를 다시 켜도 남습니다. 끝난 의뢰와 만든 문서는 공통 로그와 같은 파일(SQLite)에 적어 두고, 켤 때 다시 올립니다. 다만 돌던 중에 꺼진 의뢰는 되살리지 않습니다 — 멈춘 자리를 적어 둘 수가 없어서, 목록에 두면 ‘이어서’를 눌러도 아무 일도 일어나지 않습니다. 만든 문서는 원본 폴더가 남아 있는 것만 올립니다(열지도 받지도 못하는 줄은 빼 둡니다).

결과지우고 싶으면 그 자리에서 지웁니다. ‘에이전트 상태 · 의뢰 추적 · 소통 기록’의 의뢰를 고르는 줄에 지우는 단추가 있습니다. 의뢰 하나만 지울 수도, 내 의뢰를 모두 지울 수도 있고, 소통 기록과 만들어진 쪽 그림까지 같이 지웁니다. 로그인 여부와 상관없습니다 — 주인을 가리는 값은 로그인이 아니라 토큰이고, 그건 익명으로 써도 있습니다. 되돌릴 수 없어서 한 번 더 묻습니다.

왜그 값은 이미 파일 안에 있습니다. 손으로 적게 하면 오타 한 번에 ‘페이지 크기가 설정과 다름’이 모든 쪽에 뜨고, 사람은 파일을 의심합니다. 실제로 틀린 것은 입력 칸입니다.

어떻게파일을 고르는 순간 1쪽의 TrimBox(재단 후 완성 크기)를 읽어 가로·세로를 채웁니다. 도련은 MediaBox와 TrimBox 사이에 남은 폭에서 잽니다. 사방이 다르게 들어간 파일이 있어서 가장 좁은 쪽을 씁니다. 읽은 치수가 목록의 판형과 1mm 안에서 맞으면 그 판형을 골라 둡니다.

결과무엇을 어디서 읽었는지 칸 아래에 그대로 적습니다 — 쪽 수, 치수, 판형 이름, 도련, 읽은 상자 이름까지. 자동으로 채운 값은 어디서 왔는지 보여야 사람이 되돌릴 수 있습니다.

어떻게결과 위의 두 버튼이 서로 다른 글을 만듭니다. 검수 결과 전체는 사람이 읽는 글이라 메일·메신저에 그대로 붙입니다. 교정 목록은 기계가 읽는 줄(쪽 | 원래 내용 | 수정할 내용)이라 다른 도구에 넣을 때 씁니다 — 이 앱에서 원본에 반영하는 데는 복사가 필요 없습니다(편집 파일로 맡기면 검수 끝에 물어봅니다).

결과에이전트 검사에서는 검수 보고서 파일도 만들 수 있습니다. 상태를 바꾸는 일(A 등급)이라 안전 관문을 거치고, 보고서에 적히는 ΔE는 색 에이전트가 다시 계산해 일치할 때만 들어갑니다.

왜화면에서만 쓸 수 있으면, 원고를 쓰는 자리에서 쓰려고 할 때마다 사람이 파일을 날라야 합니다.

어떻게됩니다. 같은 에이전트를 MCP 서버로도 엽니다(pg_agents.mcp_server). 같은 PC에서 켜면 띄운 사람이 주인이라 설정만 하면 바로 돌고, 다른 PC에서 붙일 때는 python -m pg_agents.mktoken으로 받은 토큰이 있어야 합니다.

결과만든 것은 패키지로 받으세요. ‘작업 만들기’의 패키지(zip) 받기를 누르면 편집 파일(idml)과 함께 쓴 사진(Links)과 글꼴(Document Fonts), 그리고 PDF가 한 폴더에 담깁니다 — 인쇄소에 그대로 넘기면 되는 모양입니다. 편집 파일만 받는 단추는 두지 않았습니다 — 그것만 받으면 사진이 따라오지 않습니다(올릴 때 폴더째 올려야 하는 것과 같은 이유입니다 — IDML은 사진을 담지 않고 경로로 가리키기만 합니다). 글꼴이 들어가 수십 MB가 되고, 라이선스가 담는 것을 막는 글꼴은 엔진이 뺍니다. 눈으로 보기만 할 때는 PDF 받기 한 장이면 됩니다.

결과검수뿐 아니라 만드는 일도 그 자리에서 됩니다. make_document로 문서를 만들고(이때 name에 “홍길동_명함”처럼 부탁한 것이 드러나는 이름을 주면 그대로 파일 이름이 됩니다 — 안 주면 전부 새 문서.idml이라 두 개만 만들어도 어느 것인지 알 수 없습니다),compose_document에 “전단 맨 위에 제목” 식으로 말하면 할 일을 짜 주고,edit_document가 그것을 문서에 넣습니다. 쓸 수 있는 것을 찾을 때는 list_engine_commands를 씁니다.

결과주소로 열면 두 가지가 달라집니다 — check_pdf(path=…)는 막히고(그 path는 서버 PC의 파일이라, 멀리서 남의 PC 파일을 고르는 길이 됩니다) 파일을 올려야 하며, 보고서 쓰기는 쓰기 권한이 있는 토큰만 통합니다.

왜검수도 수정도 남이 만든 파일이 있어야 시작됩니다. 원본이 아예 없는 사람에게 “인디자인에서 먼저 만들어 오세요”라고 하면 거기서 끝납니다. DesignCraft는 인디자인 엔진이라 만드는 일도 하므로, 만드는 자리를 열어 두었습니다.

어떻게만드는 일은 클로드·커서에서 말로 시킵니다. 이 앱을 그쪽에 MCP로 붙여 두고 “A4 전단 한 장 만들어 줘. 위에 큰 제목, 가운데 사진 자리, 아래 연락처” 하고 적으면 됩니다. 붙이는 방법은 위 1~3번에 있습니다.

결과이 화면은 그 일을 글로 따라 봅니다. 넣을 것도 누를 것도 없습니다 — 시키신 순간부터 채팅방처럼 한 줄씩 쌓입니다. 글 넣기 “가을 정기연주회” · 1쪽 · 왼쪽에서 12mm, 위에서 14mm 자리에 186×46mm · 36pt 굵게처럼, 글상자를 어디에 놓고 어떤 글꼴로 무슨 글을 넣는지가 그대로 적힙니다. 엔진이 받은 명령 이름도 옆에 작게 남깁니다.

결과다 되면 아래 칸에서 쪽 그림과 검사 결과를 보고, IDML·PDF로 받거나 그대로 인쇄 검수로 넘길 수 있습니다 — 편집 파일로 맡기는 길이라 검수 끝에 원본 수정까지 이어집니다.

결과인쇄소 지도는 공공데이터의 인허가 자료로 만듭니다. 지도에서 찾을 수 없는 자리(좌표를 도로 단위로만 추정한 것)와 폐업으로 확인된 곳은 빼고 보여 줍니다. 추정 좌표를 그대로 찍으면 거기 없는 업체를 있다고 가리키게 됩니다.

결과종이 안내는 검수에서 고르는 종이 489종을 같은 데이터로 펼쳐 놓은 화면입니다. 등급별 프로파일과 잉크량 한도를 함께 봅니다.

결과출처는 이 앱이 쓴 자료를 전부 적은 목록입니다 — 데이터·ICC 프로파일·모델·라이브러리·근거 문헌, 직접 만든 것까지. 링크가 없는 항목은 유료 규격이거나 원문이 사라진 것이고, 그 사실을 그대로 적었습니다.