이전편 : 꼰대 상사도 한 번에 통과시키는 hwpx 편집 스킬 만들기(1)
🤓 순서
알고보니 Skill 6개(혹은 그 이상)를 한번에 만들려고 하고 있었다
묘하게 수정 포인트를 헛짚는 AI
피드백을 주었을 때 AI가 돌아가는 지점을 파악하다.
알게된 점
1. 알고보니 Skill 6개(혹은 그 이상)를 한번에 만들려고 하고 있었다
1편에서 AI로부터 내용 중심의 교정본을 받은 뒤 수정가이드를 3페이지 정도 써서 전달했습니다. 그리고 이번 2주차 스터디에서 다음의 내용을 배웠습니다.
하나의 큰 Skill을 더 작은 Skill로 나누고, 필요한 Skill을 조합해 실행하며, 이들을 묶어주는 Umbrella를 설계해보기
AI에게 이 프로젝트에서 배운 것을 적용할 수 있는지 물어봤습니다.
사실 저는 기존 한글 보고서의 내용을 보존하면서 서식을 고치는 작업을 하나의 skill로 보았고, 저번주 차에서 skill 하나 만들어 보라길래 현재 업무상 가장 있으면 좋을 것 같은 일을 하나 골라 만들기 시작했거든요.
그런데 답변을 보고나니 제가 만드려던 하나의 skill 안에 다음 일이 모두 들어 있다는 걸 알았습니다.
원본 파일을 보호하고 해시 기록하기
문서의 텍스트와 구조 추출하기
내용과 서식 문제 진단하기
승인된 문구 수정하기
줄바꿈·들여쓰기·페이지 균형 고치기
실제 한글 2020에서 다시 저장하기(실제로 여기가 제일 지인짜 시간 오래 걸립니다. 심지어 결국 수동으로 저장했어요.)
PDF로 전체 페이지를 확인하기
최종 제출 가능한 상태인지 판정하기(와.. AI가 죽어도 통과를 안시켜줘요)
skill이 한 개다, 혹은 여러 개다는 단순한 개수 문제가 아니라,
기능에 따라 달라질 수 있는 책임과 판단을 하나로 집중시키거나, 잘못 짝지을 수 있는 사안이었습니다.
문서를 고치는 역할과, 제대로 고쳐졌는지 판정하는 역할이 같은 책임하에 있었고, 저장에 성공하는 것과 보기 좋은 문서를 만드는 것도 하나의 성공으로 합쳐졌습니다.
그래서 이 일을 다음과 같은 책임으로 나누어봤습니다.
korean-public-document-workbench
│
├─ intake-inspector
│ └─ 원본 보호, 해시 기록, 구조와 분석 자료 추출
│
├─ drafter
│ └─ 메모와 근거 자료로 새 공문서 초안 작성
│
├─ content-patcher
│ └─ 승인된 문구와 표 데이터만 수정
│
├─ report-layout-repairer
│ └─ 줄바꿈, 내어쓰기, 페이 지 균형 교정
│
├─ hancom-native-finalizer
│ └─ 실제 한글에서 재저장하고 PDF와 재개방 증거 생성
│
└─ release-evaluator
└─ 모든 증거를 모아 최종 출고 여부 판정이 여섯 개를 벌써 독립 Skill로 완성한 것은 아닙니다.
현재 실제 실행 진입점은 여전히 기존 hwp-report-polisher 하나입니다. 이번에는 먼저 기존 절차를 여섯 개의 책임으로 나눈 설계 참고안을 만들고, 실제 작업을 할 때 어느 책임을 사용했고 어디로 되돌아갔는지 기록해보기로 했습니다.
하나의 정식 skill로 인정할 분리 기준은 다음과 같았습니다.
독립적으로 호출할 이유가 있는가
입력과 출력이 분명한가
완료 조건이 다른가
실패했을 때 그 역할만 다시 실행할 수 있는가
즉, Skill의 개수가 아니라 실패의 책임자가 구분되는지를 먼저 보기로 했습니다.
2. 묘하게 수정 포인트를 헛짚는 AI
저번 1편의 반성으로 가이드도 넣었고, 작업 단계도 나눴겠다, 이번에 수정할 3페이지짜리 보고서 test1을 첨부하며 얼마나 좋은 결과를 낼지 기대했습니다.
제 요청은 단순했습니다.
문서를 진단하고, 수정하고, 실제 한글에서 저장한 뒤 최종 결과를 검증해줘. 그리고 어떤 Skill을 왜 사용했는지 같이 설명해줘.
이 요청에는 보고서의 내용을 바꾸는 Content Patcher는 생략한 Circuit으로 진행했습니다.
이번 작업을 통해 저는
Skill은 망치, 렌치, 스패너, 드라이버, 가위와 같이 쓰임이 다른 개별적인 공구,
Umbrella는 전기나 통신 작업임을 확인 후 펼치는 다용도 작업용 공구 세트,
Circuit은 그런 작업용 공구 중 필요에 따라 무엇을 쓰는지의 순서 정도로 이해하게 되었습니다.
Inspector
→ Layout Repairer
→ Hancom Finalizer
→ Release Evaluator작업 과정에서 내리는 AI의 수정 판단은 가이드 주기 전보다는 훨씬 나아졌습니다.
같은 항목에서 일부 줄만 다른 페이지로 고립되면 안된다는 것을 알고, 페이지 배분을 위해 노력하는 모습이 그럴 듯하게 보였습니다.
그렇지만 묘하게 헛다리를 짚는 경우도 눈에 띄었습니다.
특히 수정 가능한 범위를 좁게 보고 다소 소극적으로 변경을 가하는 것이 꼭 융통성 없는 사람에게 일을 시키면 저러는 건가 생각이 들었습니다.
최종 결과에는 다음 검사가 붙었습니다.
원본 파일 불변
HWPX ZIP/XML 구조 정상
원본과 최종본의 의미 Markdown 동일
한글 2020 네이티브 저장 성공
저장본 냉간 재개방 성공
Hancom PDF 생성 성공
두 PDF 엔진의 페이지 수 일치
전체 3페이지 잘림·겹침 없음
마지막 형제 항목 고립 없음
검사를 꼼꼼히 하는 것 자체는 마음에 들었는데, AI가 어떻게 수정을 할 지 다 봐버린 입장에서는 중간에 다 멈추고 바로 피드백을 주고 싶은 마음도 조금 들었습니다.
그래도 그런 마음을 참았고 마침내
최종 교정본과 함께 VERIFIED / PASS 판정을 내렸습니다.
하지만 제 역할을 이제부터 시작이었습니다.
결국 AI가 만든 ‘최종 교정본’을 제가 다시 전체 교정했습니다. 그리고 어디가 달라졌는지 설명한 피드백 PDF까지 만들어 AI에게 돌려줬습니다.
3. 피드백을 주었을 때 AI가 돌아가는 지점을 파악하다.
여기서 이번 Skill 분리 실습이 실제로 시작됐습니다.
이전 같았으면 AI에게 이렇게 말했을 것입니다.
내가 고친 문서를 보고 다음부터 잘해줘.
그러면 기존의 큰 Skill 설명서에 규칙 몇 줄이 추가됐을 것입니다.
이번에는 단순히 문서를 다시 고치는 것이 아니라, AI 결과와 사용자 교정본의 차이를 추출하고 어떤 차이를 다음 문서에도 적용할 규칙으로 승격할지 판단하는 경로를 거쳤습니다.
비교 결과는 다음과 같았습니다.
문자 스타일 변경: 1건
문단 스타일 변경: 37건
문단 구조 변경: 7건
실효 페이지 나눔 변경: 1건
가장 큰 차이는 줄간격이었습니다.
AI 결과에서는 일부 본문을 155%까지 줄여 형제 항목을 묶었습니다. 제 교정본에서는 상위 섹션을 다음 페이지로 배치한 뒤 페이지에 따라 200%와 220%를 사용했습니다.
처음 AI는 160~180%를 일반 본문의 안전한 범위처럼 다루고 있었습니다.
하지만 제가 제공했던 가이드에서 155%는 형제 항목을 한 페이지에 유지할 수 있는 최소선이었습니다. 180%를 한도로 설명하지는 않았었습니다.
그래서 저는 일반 본문에서 최대 250%까지 허용할 수 있다고 다시 확인시켰고, 제가 수정할 때 적용한 값인 220%를 새로운 정답으로 고정하지 않도록 하였습니다.
이번 문서에서 보기 좋았다는 이유로 모든 보고서에 220%를 적용하면, 새로운 규칙이 아니라 새로운 사고가 시작될 수 있기 때문입니다.
전역 규칙으로 승격한 것은 다음 판단 방식이었습니다.
상위 섹션을 먼저 페이지에 배분하고, 155~250% 범위에서 페이지 또는 완결된 의미 묶음 단위로 줄간격을 조정한 뒤 전체 페이지를 다시 확인한다.
비교 과정에서 예상하지 못한 문제가 하나 더 발견됐습니다.
기존 비교 도구는 사용자 교정본과 AI 결과를 비교한 뒤, 처음에는 중요한 내어쓰기 차이를 제대로 보고하지 못했습니다.
사람 눈에는 두 번째 줄의 시작 위치가 확실히 달랐는데, 비교 결 과에서는 핵심 차이가 비어 있거나 단순한 선행 공백 변화처럼 나타났습니다.
원인을 확인해보니 HWPX의 문단 내어쓰기 속성을 잘못 이해하고 있었습니다.
이 속성은 이름만 보면 indent일 것 같지만, 실제 HWPX에서는 core namespace의 intent라는 이름을 사용합니다. 게다가 문단 속성 ID가 새로 생성되면 ID 자체를 비교해서도 안 되고, 실제 적용된 속성값을 비교해야 했습니다.
'내어쓰기면 내어쓰기지, 왜 이렇게 구별을 해야하는 걸까...' 라는 생각도 들었지만 결론적으로 이러한 철저한 구별을 통해 저의 피드백으로 인해 되돌아가야 할 지점이 어디인지 명확히 할 수 있었습니다.
Layout Repairer로 돌아간 피드백
내어쓰기는 특정 위치를 무조건 정답으로 고정하지 않는다
같은 계층 문단의 지배적인 기준을 찾아 문서 전체를 통일한다
마지막이 아닌 페이지의 큰 공백을 마지막 페이지보다 먼저 고친다
줄간격은 개별 문단이 아니라 페이지나 의미 묶음 단위로 조정한다
자동 줄바꿈 꼬리를 계층 표지 없는 새 문단으로 만들지 않는다
Inspector와 비교 도구로 돌아간 피드백
문자 스타일만 비교하지 않는다
줄간격과 실제 내어쓰기 속성도 추출한다
keepWithNext,pageBreakBefore, 문단의pageBreak를 비교한다문단 속성 ID가 아니라 실제 유효값을 비교한다
동일한 텍스트가 여러 번 나올 때는 문서 순서만 보고 잘못 짝짓지 않는다
Evaluator로 돌아간 피드백
한글에서 저장됐다는 사실과 페이지 품질을 분리한다
마지막이 아닌 페이지에서 없앨 수 있는 큰 공백을 검사한다
마지막 페이지 50% 미만을 무조건 실패로 처리하지 않고 재배치 검토 신호로 사용한다
어절 중간 분리는 문서 종류와 관계없이 BLOCK으로 유지한다
전각·반각 기호까지 조직 보고서의 품질 규칙에 포함한다
기존 방식이었다면 이 모든 변화가 hwp-report-polisher에 “희주 피드백 반영”이라는 한 묶음으로 들어갔을 것입니다.
책임을 나눠놓으니 피드백이 어디로 가야 하는지가 달라졌습니다.
문서가 보기 좋지 않았던 것은 Layout Repairer의 문제였습니다.
그 차이를 감지하지 못한 것은 Inspector와 비교기의 문제였습니다.
그런데도 PASS를 낸 것은 Evaluator의 정책 문제였습니다.
실패한 것은 하나의 문서였지만, 고쳐야 할 대상은 하나가 아니었습니다.
4. 알게 된 점
1) Skill을 나누는 기준은 작업 순서가 아니다.
처음에는 작업을 여섯 단계로 나누면 Skill 여섯 개가 되는 줄 알았습니다.
실제로 더 중요했던 기준은 '이 단계가 실패했을 때, 누가 새 결과를 만들어야 하는가?' 입니다.
실패의 Owner가 달라질 때 Skill의 경계 도 생겼습니다.
2) 기술적 PASS와 사람이 말하는 완성은 다르다.
첫 결과는 거짓 PASS는 아니었습니다.
파일은 정상적으로 열렸고, 원본은 보존됐고, 의미도 유지됐습니다.
다만 그 PASS가 증명한 범위보다 제가 기대한 ‘잘 다듬어진 보고서’의 범위가 더 넓었습니다.
사용자의 눈이 발견한 차이를 다시 비교 가능한 속성과 정책으로 바꾸자, 다음부터 검사할 수 있는 범위가 넓어졌습니다.
3) 사용자 교정본의 모든 값을 그대로 규칙으로 만들면 안 된다.
제 교정본에서 200%와 220%가 사용됐다고 해서 이를 모든 문서의 고정값으로 만들지는 않았습니다.
마지막 문단에 장평 98%, 자간 -2%가 사용된 것도 마찬가지였습니다.
그 숫자는 이번 문서에서 성공한 사례입니다.
전역 규칙으로 남긴 것은 다음과 같습니다.
허용 범위 안에서 최소한으로 조정할 것
같은 역할의 문단 하나만 유난히 다르게 만들지 않을 것
페이지 또는 의미 묶음 전체를 함께 볼 것
모든 변경 후 전체 페이지를 다시 렌더할 것
사례값과 규칙을 구분하지 않으면, 사람의 피드백을 반영한다면서 새로운 하드코딩을 만들 수 있습니다.
작업 내용이나 피드백은 보고서 내용의 보안 상 올리기가 어렵네요.
대략 이렇게 보냈습니다.
한국 사업 계획의 예
