한글 양식 빈칸 채우는 세 가지 — 표 칸·누름틀·찾아 바꾸기를 같은 서식으로 대조

한 줄로

표로 된 신청서 더미를 직접 만들어 같은 값을 세 가지로 넣어 봤습니다. 표 칸에 대고 치기, 누름틀에 값 넣기, [성명] 같은 자리표시자를 찾아 바꾸기입니다. 나온 PDF 세 장은 150dpi로 그려 해시를 내 보니 화소 한 점까지 같았습니다. 갈리는 건 결과가 아니라 틀렸을 때입니다. 없는 누름틀 이름을 부르면 오류도 없이 문서가 그대로였고, 없는 자리표시자를 찾으면 False가 돌아왔고, 표 칸에서 커서를 한 칸 잘못 옮기면 값이 라벨 칸에 붙어 버렸습니다.

이런 분께

사내 신청서·확인서 같은 한글 양식에 이름만 바꿔 여러 장을 만들어야 하는 분입니다. 어느 방식으로 양식을 짜 둬야 나중에 덜 고생하는지가 궁금한 경우입니다.

실측 환경

양식과 값은 전부 지어낸 것입니다. 회사 서식이나 남의 신청서는 쓰지 않았습니다.

아래 숫자는 한글에서 같은 기능을 자동화(한글 COM)로 불러 얻은 것입니다. 메뉴를 눌러 보고 찍은 화면은 이 글에 없습니다.

더미 양식

빈칸이 오른쪽에 있는 흔한 꼴로 만들었습니다.

같은 표를 세 벌 만들었습니다. 오른쪽 칸을 그냥 비워 둔 것(A), 누름틀을 하나씩 심어 둔 것(B), [성명] 같은 자리표시자를 적어 둔 것(C)입니다. 파일 크기가 셋 다 다릅니다.

SaveAs KO3_55_form_A.hwp -> True (18944 바이트)   ← 빈칸
SaveAs KO3_55_form_B.hwp -> True (22016 바이트)   ← 누름틀 6개
SaveAs KO3_55_form_C.hwp -> True (19968 바이트)   ← [성명] 자리표시자
누름틀 목록 = '성명\x02연락처\x02소속\x02신청일\x02과정명\x02신청사유'

누름틀을 심은 B가 빈칸 양식 A보다 3,072바이트 큽니다. 무엇이 그만큼을 차지하는지는 뜯어보지 않았습니다.

2026-09-28 보강: 공식 도움말로 확인한 절차, 직접 화면 실행은 미확인

아래는 한컴오피스 2022 한/글 도움말로 확인한 메뉴 절차입니다. 이번 보강에서는 Windows·한글 화면을 실행하지 못했습니다. 앞뒤의 시간·크기·해시는 2026-09-18 자동화 실측 기록이며, 아래 메뉴를 손으로 따라 해서 새로 얻은 결과는 아닙니다. 먼저 양식을 다른 이름으로 저장해 작업용 사본을 만드세요.

누름틀에 이름을 붙이고 값 넣기

1. 표의 오른쪽 빈칸 안에 커서를 놓고 입력 > 개체 > 필드 입력을 엽니다. 대화 상자에서 누름틀 탭을 고릅니다.
2. 입력할 내용의 안내문에는 성명 입력, 필드 이름에는 성명을 넣고 넣기를 누릅니다. 안내문은 작성자에게 보이는 설명이고, 필드 이름은 자동화에서 그 칸을 찾는 이름입니다.
3. 나머지 오른쪽 칸에도 반복합니다. 이 글의 이름은 성명, 연락처, 소속, 신청일, 과정명, 신청사유입니다. 마지막 이름은 띄어쓰기 없이 신청사유로 맞춥니다.
4. 실제 내용을 채울 때는 문서에 보이는 성명 입력 안내문을 클릭하고 홍길동을 입력합니다. 다른 안내문도 눌러 연락처·소속·날짜·과정·사유를 채웁니다. 필드 이름 칸에 사람 이름을 넣는 것이 아닙니다.
5. 이미 있는 누름틀의 이름을 확인하거나 고치려면 누름틀 바로 앞이나 안에 커서를 두고 편집 > 고치기를 실행합니다. 자동화에 쓸 때는 여기의 이름을 정확히 옮깁니다. 들어 있는 값 전체를 바꾸려면 누름틀 안에서 F11을 한 번 눌러 내용만 선택한 뒤 새 값을 입력합니다.

메뉴와 각 항목의 근거는 한컴의 필드 입력: 누름틀입니다. 잘못된 이름을 넣어도 오류가 없었던 자동화 결과는 아래 「틀렸을 때 무엇이 남는가」에서 따로 확인할 수 있습니다.

[성명] 같은 자리표시자 찾아 바꾸기

1. 누름틀 대신 일반 글자로 [성명], [연락처]처럼 서로 다른 자리표시자를 오른쪽 칸에 적어 둡니다.
2. 편집 > 찾기 > 찾아 바꾸기를 열고 찾을 내용에 [성명], 바꿀 내용에 홍길동을 넣습니다. 찾을 방향은 문서 전체로 둡니다.
3. 바꾸기로 찾은 위치를 먼저 확인하고 다시 바꾸기를 누릅니다. 같은 자리표시자를 모두 같은 값으로 바꿀 때만 모두 바꾸기를 씁니다. 그때 표시되는 바꾼 횟수가 예상과 맞는지 봅니다.
4. 여섯 항목을 반복한 뒤 각 자리표시자를 다시 찾아 남은 것이 없는지 확인합니다. [도 검색해 대괄호가 남은 칸을 살펴봅니다. 선택한 블록 안에서만 바꾸지 않도록 문서 전체가 검색 범위인지 확인하세요.

대화 상자의 항목과 검색 범위는 한컴의 찾아 바꾸기를 기준으로 적었습니다. 표 칸에 바로 입력하는 방식은 오른쪽 칸을 하나씩 눌러 값을 넣은 뒤, 왼쪽 라벨에 값이 붙지 않았는지 확인하면 됩니다.

채운 한글 문서를 PDF로 저장하기

채운 HWP 사본을 저장한 다음 파일 > PDF로 저장하기를 엽니다. 저장 위치와 파일 이름을 지정하고, 저장 설정에서 저장 범위가 문서 전체인지 확인한 뒤 저장합니다. 이는 한컴의 PDF로 저장하기에 나온 경로입니다.

만든 PDF를 다시 열어 여섯 값, 남은 자리표시자, 쪽 수, 마지막 사유 칸과 그 아래 문장을 확인합니다. 빈 누름틀은 PDF에서 빈칸으로 보일 수 있으므로 안내문이 없다는 것만으로 다 채웠다고 판단하지 마세요. 긴 사유로 표가 늘어나는지는 아래 실측처럼 저장한 PDF에서 확인해야 합니다.

세 가지로 채운 결과

같은 값을 세 방식으로 넣고 각각 PDF로 저장했습니다.

눈으로는 구별이 안 됩니다. 그래서 세 PDF를 150dpi로 그려 화소 덩어리째 해시를 냈습니다.

① 표 칸 직접 입력   1240x1753 화소  sha256[:16]=11066f40de6a401c
② 누름틀에 값 넣기   1240x1753 화소  sha256[:16]=11066f40de6a401c
③ 찾아 바꾸기      1240x1753 화소  sha256[:16]=11066f40de6a401c
세 해시가 모두 같은가 = True

글꼴도 셋 다 INPILL+HCRBatang 한 벌, 쪽 수도 1쪽, PDF에서 뽑히는 글자도 186자로 같습니다. 파일 크기만 22,947 / 22,949 / 22,947바이트로 두 바이트 차이가 났습니다.

받는 사람이 보는 결과물만 놓고 보면 세 방식은 구별할 게 없습니다.

안 채운 채로 넘기면 — 여기서 갈린다

값을 하나도 넣지 않은 채 세 양식을 그대로 PDF로 저장해 봤습니다.

누름틀 양식은 문서 글자를 읽어 보면 "성명 입력" 같은 안내문이 나옵니다.

B_누름틀  본문글자='… / 성명 / 성명 입력 / 연락처 / 연락처 입력 / 소속 / 소속 입력 / …'

그런데 그 상태로 PDF를 만들면 안내문은 따라가지 않습니다.

A_빈칸       PDF에서 뽑은 글자: … 성명 / 연락처 / 소속 / 신청일 / 과정명 / 신청 사유
B_누름틀      PDF에서 뽑은 글자: … 성명 / 연락처 / 소속 / 신청일 / 과정명 / 신청 사유
C_자리표시자    PDF에서 뽑은 글자: … 성명 / [성명] / 연락처 / [연락처] / 소속 / [소속] / …

빈 양식 PDF의 크기도 A와 B가 16,198바이트로 같았고, C만 16,423바이트였습니다. 누름틀 안내문은 이번 PDF에서 뽑은 글자에 없었고, 자리표시자는 그냥 글자라서 빠뜨리면 [연락처]가 적힌 채로 상대에게 갑니다.

이게 두 방식의 진짜 차이입니다. 자리표시자 방식은 안 채운 칸이 눈에 확 띄고, 누름틀 방식은 안 채운 칸이 PDF에서 그냥 빈칸이 됩니다. 종이에 인쇄했을 때도 같은지는 확인하지 않았습니다.

이름만 바꿔 세 장

같은 양식을 열어 여섯 칸을 채워 세 장씩 뽑았습니다. 시간은 양식 파일을 여는 호출부터 PDF 저장이 끝날 때까지입니다.

①의 첫 장만 1.42초로, 둘째·셋째의 0.50초·0.51초보다 오래 걸렸습니다. 왜 첫 장만 그런지는 재지 않았습니다. 이건 자동화로 돌렸을 때의 시간이고, 사람이 손으로 칠 때의 시간은 아닙니다.

세 방식 모두 세 장이 다 1쪽으로 나왔고, 이름과 소속이 PDF에서 빠짐없이 검색됐습니다.

① 1장:O/O 쪽수1  2장:O/O 쪽수1  3장:O/O 쪽수1
② 1장:O/O 쪽수1  2장:O/O 쪽수1  3장:O/O 쪽수1
③ 1장:O/O 쪽수1  2장:O/O 쪽수1  3장:O/O 쪽수1

틀렸을 때 무엇이 남는가

세 방식에 흔한 실수를 하나씩 넣어 봤습니다.

누름틀 이름을 잘못 부르면 — 실제 이름은 성명인데 이름으로 값을 넣어 봤습니다.

PutFieldText('이름') 반환 = None | 예외 없음
넣은 뒤 본문 = '… / 성명 / 성명 입력 / 연락처 / 연락처 입력 / …'
실제 누름틀 목록 = '성명\x02연락처\x02소속\x02신청일\x02과정명\x02신청사유'

오류도 없고 되돌려 주는 값도 없습니다. 문서는 그대로입니다. 넣었다고 생각하고 그냥 저장하면 빈칸인 채로 나갑니다.

찾아 바꾸기 이름을 틀리면 — 없는 [이름]을 찾게 하면 False가 돌아옵니다.

AllReplace('[이름]'->'홍길동') 반환 = False
AllReplace('[성명]'->'홍길동') 반환 = True

적어도 못 찾았다는 사실은 알려 줍니다. 그리고 안 바뀐 칸은 [연락처]처럼 종이에 그대로 남으니 눈으로도 잡힙니다.

표 칸에 직접 칠 때 커서가 한 칸 밀리면 — 값이 라벨 칸으로 들어갑니다.

본문 = '… / 홍길동성명 /  / 010-0000-0000연락처 /  / 총무팀소속 /  / …'

홍길동성명처럼 라벨에 값이 붙고 오른쪽 칸은 비었습니다. 이건 한눈에 보이니 오히려 나은 편입니다.

긴 값을 넣으면 칸이 어떻게 되나

누름틀 양식의 신청 사유 칸에 81자와 567자를 각각 넣어 봤습니다.

PDF에서 가로줄 사이를 재 보면 이렇습니다.

81자  : 칸 높이(pt) = [31.1, 31.2, 31.0, 31.2, 31.2, 60.7]   표 아래끝 348.9pt
567자 : 칸 높이(pt) = [31.1, 31.2, 31.0, 31.2, 31.2, 364.4]  표 아래끝 652.6pt

앞 다섯 줄은 31pt(약 11mm)로 그대로인데 마지막 줄만 60.7pt(약 21mm), 567자에서는 364.4pt(약 129mm)까지 늘었습니다. 표 아래끝도 348.9pt에서 652.6pt로 내려갔고, "위 내용이 사실임을 확인합니다."라는 문장은 두 경우 모두 표 아래쪽에 있었습니다.

81자를 넣은 결과에서는 칸을 넘친 글자가 한 조각도 없었습니다. 글자 조각마다 자리를 재 표 테두리와 견줘 봤습니다.

가로줄 y = [132.5, 163.6, 194.8, 225.8, 257.0, 288.2, 348.9]
세로줄 x = [86.5, 309.1, 531.8]
칸을 넘친 글자 조각 수 = 0

이번 양식에서는 사유가 길어지자 칸이 커지고 표 아래끝이 내려갔습니다. 567자 쪽에서도 같은 넘침 검사를 돌리지는 않았습니다. 한 장에 딱 맞춰 만든 서식이라면 사유란에 긴 글을 넣는 순간 아래가 밀려 나가니, 값을 넣은 뒤 쪽 수를 한 번 세 보시는 게 안전합니다.

결과

실패한 것

• 표를 만들 때 칸 너비를 왼쪽 40mm, 오른쪽 110mm로 줬는데 들어가지 않았습니다. 빈 양식 PDF에서 세로줄을 재 보니 왼쪽 222.6pt(78.5mm), 오른쪽 222.7pt(78.6mm)로 거의 반반이었습니다. 이 글의 그림에서 라벨 칸이 넓어 보이는 것도 그래서입니다. 왜 안 먹었는지는 못 찾았습니다.
• 글자가 칸을 넘쳐 겹치는 장면을 만들려 했는데 만들지 못했습니다. 칸의 「줄 나눔」 값을 0·1·2로 바꿔 세 번 돌렸고 호출은 세 번 다 True를 돌려줬는데, 세 결과의 가로줄 위치가 [132.5, 163.6, 194.8, 225.8, 257.0, 288.2, 348.9]로, 칸 높이가 [31.1, 31.2, 31.0, 31.2, 31.2, 60.7]로 똑같이 나왔습니다. 설정이 닿지 않았는지, 닿았는데 결과가 같은 것인지는 가리지 못했습니다.
• 찾아 바꾸기 설정에 AllReplace 라는 항목이 있는 줄 알고 값을 넣다가 멈췄습니다. 그 이름은 없습니다.

ps.AllReplace = 1 -> AttributeError: … object has no attribute 'AllReplace'
있는 항목 = ['AllWordForms', 'AutoSpell', … 'ReplaceMode', 'ReplaceString', … 'WholeWordOnly']

• 문서를 닫아 가며 돌리던 중 한글과 끊긴 적이 한 번 있었습니다(RPC 서버를 사용할 수 없습니다). 같은 절차를 다시 밟았을 때는 나지 않았고, 대신 열린 문서가 하나뿐일 때 닫기를 불러도 문서 수가 1개 그대로였습니다. 끊긴 원인은 못 밝혔습니다.

확인하지 않은 것

• 한글 창을 띄워 메뉴를 눌러 보지 않았습니다. 2026-09-28에 메뉴 절차는 공식 도움말로 보강했지만, 직접 실행한 화면이나 손 입력 결과는 추가하지 않았습니다. 실측 수치는 같은 기능을 자동화로 불러 나온 결과입니다.
• 손으로 직접 쳤을 때 세 장에 몇 분이 걸리는지는 재지 않았습니다. 위 초 단위는 자동화가 낸 시간입니다.
• 칸을 합친 표, 여러 쪽짜리 양식, 도장란·서명란이 든 양식은 만들지 않았습니다. 6줄 2칸 한 장짜리만 봤습니다.
• 누름틀 안내문이 한글 화면에서 어떻게 보이는지는 그림으로 담지 않았습니다. 문서 글자를 읽어 안내문이 있다는 것만 확인했습니다.
• 인쇄기로 종이에 뽑았을 때도 안내문이 안 나오는지는 확인하지 않았습니다. PDF에서만 봤습니다.
• 긴 값 시험은 누름틀 양식으로만 했습니다. 나머지 두 방식으로도 같은지는 견주지 않았습니다.
• 기존 누름틀 하나의 이름을 여는 메뉴는 보강했지만, 다른 사람이 만든 양식에서 이름을 확인하거나 여러 누름틀 이름을 한꺼번에 조사하는 일은 직접 시험하지 않았습니다.
• 한글 Office 2022 말고 다른 판에서는 돌려 보지 않았습니다.

함께 보기

• 한글을 PDF로 저장할 때 표·그림·쪽번호가 그대로 나오는지
• 한글 표에 줄 추가하기
• 워드를 PDF로 — 세 가지 길이 무엇을 잃는지