AI가 "방법이 없다"고 했을 때 "나도 잘 모르겠어, 어떡해?" 한마디로 30년치 자료를 살렸다

📝 한줄 요약

어떤 프로그램으로도 열리지 않던 30년 전 문서 375개를 포함해, 성경 주석 2,112개를
AI에게 물어보면 답하는 지식베이스로 만들었습니다. 최종 변환율 99.95%.

바쁘시면 이것만 읽어도 돼요:

• 상황: 30년간 쌓인 주석 자료 2,112개가 전부 옛날 한글(HWP) 파일. 찾아볼 수도, AI에게 물어볼 수도 없었음

• 1차 결과: 표준 변환 도구로 1,737개는 성공. 375개는 끝내 실패 — 1994~95년 포맷이라 현존하는 어떤 도구도 못 엶

• 전환점: AI가 "자동화가 전부 막혔다"고 보고했을 때 "나도 잘 모르겠어. 어떡해?" 한마디를 던짐 → 접근 자체가 바뀜

• 핵심 해결: 남의 프로그램에 의존하지 않고 파일 자체를 직접 뜯어서 해독 → 374개 복구

• 반전: 그중 151개는 내용이 압축돼 있었는데, AI가 옛날 압축 방식 64가지를 다 시도했다가 전멸 → 알고 보니 엉뚱한 곳만 뒤지고 있었던 것

• 합치기: 살려낸 374개를 다른 컴퓨터로 옮겨 기존 자료와 병합. 파일 지문 374/374 일치, 충돌 0건 → 2,111개 완성

• 최종 결과: 이제 롬 8:28 한 줄이면 해당 주석이 바로 나오고, 대화 중에 AI가 알아서 찾아 인용함

• 가장 큰 교훈: 전문 지식이 없어도 된다. AI가 "안 된다"고 할 때 모른다고 솔직히 말하고 되묻는 것만으로 길이 열렸다

🎯 이런 분들께 도움돼요

• AI 코딩 도구를 쓰는데 AI가 "못 하겠다"고 했을 때 어떻게 돌파하는지 궁금한 비개발자

• 전문 지식이 없어서 AI에게 뭘 요청해야 할지 모르겠는 분

• 오래된 한글·엑셀·워드 파일이 안 열려서 자료가 묶여 있는 분 (연구자, 교회·단체 자료 관리자)

• 흩어져 있는 내 자료를 AI가 찾아볼 수 있게 만들고 싶은 분

😫 문제 상황 (Before)

30년 가까이 쌓인 성경 주석 자료가 2,112개 있었습니다. 전부 한글(HWP) 파일이었죠.

문제는 이게 사실상 없는 자료나 마찬가지였다는 겁니다. 이유가 넷이었어요.

첫째, 찾아볼 수가 없었습니다.
주석은 처음부터 끝까지 읽는 자료가 아닙니다. 필요할 때 "그 구절 주석이 뭐라고 했더라" 하고 찾아보는 자료죠.
그런데 2,112개가 77개 폴더에 흩어져 있으니, 원하는 구절을 찾으려면 폴더를 하나씩 열어보는 수밖에 없었습니다.
사실상 못 찾는다는 뜻입니다.

둘째, AI에게 물어볼 수가 없었습니다.
AI에게 자료를 주고 물어보면 좋겠는데, HWP는 AI가 읽지 못합니다. 읽을 수 있는 형태로 바꾸는 게 전제 조건이었어요.

셋째, 자료가 사라질 것 같았습니다.
파일 날짜를 보니 1994~1995년. 30년 된 파일들이 하나둘 안 열리기 시작했습니다.
지금 안 살리면 영영 못 살린다는 느낌이 들었어요.

넷째, 포맷 자체가 낙후돼 있었습니다.
특정 프로그램이 있어야만 열리는 형식에 30년치 자료가 묶여 있는 게 불안했습니다.
어디서든 열리는 개방 형식으로 옮겨두고 싶었어요.

그래서 변환을 시작했습니다. 그리고 여기서부터 예상이 빗나가기 시작했습니다.

🛠️ 사용한 도구

• 도구: Claude Code (터미널에서 쓰는 AI 코딩 도구)

• 모델: Sonnet 5로 시작 → 막힌 시점에 Opus 4.8로 전환

• 특이사항: 컴퓨터 두 대(맥 + 윈도우)를 오가며 작업했습니다. 한쪽에서 막힌 걸 다른 쪽에서 풀고, 결과를 다시 합치는 방식이었어요

🔧 작업 과정

1. 1,737개는 됐습니다. 그런데 375개가 남았습니다

맥에서 먼저 시작했습니다. AI가 2,112개 파일을 살펴보더니, 한 종류가 아니라고 알려줬어요.

V3.00 포맷 — 1,737개
V2.00 / V2.10 — 201개
V1.20 — 174개

같은 HWP처럼 보여도 속은 세 가지로 나뉘어 있었습니다.
그리고 요즘 나온 변환 도구들은 최신 포맷만 전제하고 만들어져 있었습니다.

AI가 여러 경로를 시도한 끝에 파이프라인 하나를 찾아냈고, 1,737개가 한 번에 변환됐습니다. 실패 0건.

문제는 나머지였습니다. V1.20과 V2.x — 375개는 어떤 방법으로도 열리지 않았습니다.
AI는 이 375개를 목록 파일로 정리해뒀습니다. 첫 줄에 이런 문구와 함께요.

=== 변환 실패 파일 목록 (구형 HWP 포맷: V1.20 / V2.00 / V2.10
    — LibreOffice·hwpjs 모두 파싱 불가) ===

사실상 사망 선고였습니다.

2. 되긴 됐는데, 문장이 조각나 있었습니다

성공한 1,737개도 그냥 쓸 수 있는 상태가 아니었습니다. 열어보니 문장이 이상하게 끊겨 있었어요.

옛날 한글은 화면 폭에 맞춰 40자쯤에서 강제로 줄을 끊어 저장했는데,
변환 도구가 그 줄바꿈을 "여기서 문단이 끝났다"는 뜻으로 오해한 겁니다.
한 문장이 서너 조각으로 쪼개진 상태였죠.

AI가 규칙을 세워 복원했습니다. 문장 끝을 나타내는 부호로 끝나지 않은 조각은 다음 조각과 이어붙이되,
성경 구절 표시(창 1:1 같은)는 항상 독립된 줄로 유지하도록요.

여기에 더해, 변환 과정에서 따옴표나 괄호 앞에 백슬래시(\)가 11만 개 넘게 끼어 있는 것도 발견해 걷어냈습니다.

자동 정리 후에도 애매한 6건이 남았는데, AI가 임의로 고치지 않고 하나씩 보고했습니다.
그중 하나가 인상적이었어요.

요 2\3:33 → 백슬래시만 제거해 요 23:33으로.
다만 요한복음은 21장까지밖에 없으므로 이 구절 표기 자체가 원본에서 손상된 것으로 보인다고 덧붙였습니다.
원문 확인 없이는 정정할 수 없어 그대로 둔다고요.

시키지 않았는데 성경 구조를 대조해서 "이건 내가 고칠 수 있는 범위가 아니다"라고 선을 그은 겁니다.

3. 남은 375개 — 다른 컴퓨터에서 정면 돌파

맥에서 안 되는 375개를 윈도우로 가져와 다시 붙었습니다.

여기 하위폴더에 보면 hwp 파일들이 있어. 여기서 hwp 파일을 md파일로 변환하려고 하는데,
"변환실패_목록.txt"에 있는 파일들을 md파일로 변환하려고 해.
다른 파일들을 변환하지 않아도 괜찮아. 변환 가능한지 살펴봐줄래?

AI는 이 PC에 한컴오피스가 깔려 있는 걸 발견하고 방향을 잡았습니다.
"변환 도구가 없으면 원조 프로그램을 시키면 되지 않나?"

말은 맞는데, 현실은 달랐습니다.

• 한글을 자동으로 조종하기 → 접근 거부. 재시도하니 프로그램이 아예 멈춰버림

• 복사해서 붙여넣기 → 한글 창에서 복사를 눌러도 클립보드에 아무것도 안 들어옴

• 메뉴에서 "다른 이름으로 저장" 누르기 → 메뉴는 열리는데 클릭이 안 먹힘

여기서 AI가 한 행동이 인상적이었습니다. 복사가 안 되자 메모장을 열어서 똑같이 해봤어요.
메모장에서는 정상 작동. 즉 "내 방법이 틀린 게 아니라 한글 창에서만 복사가 막힌 것"을 특정한 겁니다.

그리고 이 과정에서 결정적인 사실 하나가 나왔습니다.
한글로 파일을 그냥 열어보니 — 내용이 멀쩡하게 다 보였습니다.

데이터는 살아있다. 꺼낼 방법이 없을 뿐이다.

4. "어떡해?" — 여기가 전환점이었습니다

AI가 결론을 냈습니다. "자동화가 전부 막혔습니다. 수동으로 하시거나…"

솔직히 이 순간이 제일 답답했습니다.

375개를 하나씩 열어서 복사하는 건 며칠짜리 노가다입니다. 그건 알겠는데,
문제는 제가 아무것도 도와줄 수가 없었다는 것이었어요.

전문 지식이 없으니 "그럼 이 방법은?" 하고 대안을 제시할 수도 없고,
AI가 한 말이 정말 맞는 말인지 판단할 능력도 없었습니다.
뭘 요청해야 할지조차 모르는 상태. 여기서 대부분 포기하지 않을까 싶었어요.

그래서 그냥 모델을 더 똑똑한 걸로 바꾸고, 아는 척을 완전히 포기하고 있는 그대로 물었습니다.

나도 잘 모르겠어. 어떡해?

그랬더니 답이 이렇게 돌아왔습니다.

"막막할 만해. 근데 아직 안 해본 가장 유망한 방법이 하나 남아 있어 —
파일 형식을 직접 뜯어서 파싱하는 것."

남의 프로그램에 부탁하는 걸 포기하고, 파일 자체를 직접 해독하겠다는 거였습니다.
30년 전 파일이라 구조가 단순할 거라는 계산이었죠.

몇 분 뒤, 파일 속 숫자들의 규칙을 찾아냈다며 첫 결과를 보여줬습니다.

***** 열왕기하 21장 새벽강해 *****
1. 아버지 히스기야의 선정을 이어받지 못함.
히스기야 왕은 산당을 제하고, 우상숭배를 버리고, 하나님 보시기에 선한 왕이었고...

30년 동안 잠겨 있던 글자가 화면에 그대로 나온 순간이었습니다.

AI의 "안 됩니다"를 그냥 받아들였다면 여기서 끝났을 겁니다.
돌이켜보면 AI는 "이 방법이 막혔다"고 보고했을 뿐, "모든 방법을 다 써봤다"고 한 적이 없었어요.

5. 글자는 나오는데 번호가 사라졌습니다

문제는 그다음이었습니다. 글은 나오는데 뭔가 허전했어요.

AI에게 "진짜 한글 프로그램으로 열어서 화면이랑 비교해봐" 라고 시켰더니 차이가 드러났습니다.

원본에는 이렇게 되어 있었는데,

Ⅰ.내용 분해와 조직
  ①질문 ; 요한의 제자들과 바리새파 사람들은 금식을...
    ㄱ.결혼 잔치 때 신랑의 친구들이...

변환 결과에는 Ⅰ, ①, ㄱ 같은 번호가 전부 빠져 있었습니다. 목차 구조가 통째로 날아간 셈이죠.

옛날 한글은 일반 글자와 ① 같은 기호를 서로 다른 번호표로 저장하고 있었는데,
그 규칙을 몰라서 전부 버리고 있었던 겁니다. 기호 몇 개를 표본 삼아 규칙을 역으로 계산해내자 번호가 전부 살아났습니다.

이 "원본과 대조하기"는 이후에도 계속 효자 노릇을 했습니다.
한자가 엉뚱한 글자로 바뀐 것(戰亂이 掠傑로)도, 마지막에 빈 문서 판정도 전부 여기서 잡혔거든요.

6. 151개가 통째로 깨진 사건 — 그리고 반전

전체를 한 번 돌려봤습니다. 결과가 충격적이었어요.

성공 224개 / 본문 없음 151개

151개가 통째로 깨져서 나왔습니다. 글자가 하나도 안 나오고 외계어만 가득했죠.

원본이 손상된 걸까 싶었는데, AI가 그중 하나를 한글로 열어보더니 —
내용이 가득 차 있었습니다. 파일 문제가 아니라 우리 방법 문제였어요.

AI는 잘 되는 파일과 안 되는 파일을 나란히 놓고 비교해서, 파일 안에 "압축됨" 표시가 있다는 걸 찾아냈습니다.
본문이 zip처럼 압축돼 있어서 그냥 읽으면 외계어로 보였던 겁니다.

그래서 압축을 풀어야 하는데… 여기서 긴 삽질이 시작됩니다.

AI는 "1990년대 초 파일이니 그 시절 특유의 압축 방식이겠지"라고 추측하고,
옛날 압축 방식 64가지 조합을 전부 시도했습니다. 결과는 전멸.

심지어 중간에 "성공했다!"는 신호가 떴는데, 열어보니 이런 상태였어요.

붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡붡…

성공 여부를 판단하는 기준 자체가 잘못돼서, 같은 글자만 반복되는 쓰레기를 정답으로 착각한 거였죠.
AI가 스스로 이걸 발견하고 "문서에 실제로 있는 단어가 나오는지"로 기준을 바꿔 다시 64가지를 돌렸습니다. 또 전멸.

여기서 AI가 포기 대신 자기 가정을 의심했습니다.

"압축이 실제로 어디서부터 시작하는지부터 확인해보자."

확인해보니 압축된 내용은 파일의 한참 뒤쪽에서 시작하고 있었는데,
지금까지의 탐색은 파일 앞부분만 뒤지고 있었습니다. 시작점에 닿지도 못한 채 64가지를 돌렸던 거예요.

찾는 범위를 넓히자 곧바로 답이 나왔습니다.
심지어 옛날 방식도 아니고 오늘날에도 흔히 쓰는 표준 압축 방식이었어요.

알고리즘이 틀린 게 아니라, 엉뚱한 곳만 보고 있었던 것이었습니다.

압축을 풀자 151개가 한꺼번에 살아났습니다. 최종적으로 374개 성공, 실패 0개.
끝까지 안 나온 1개는 AI가 한글로 열어 확인한 결과 원본이 그냥 백지였습니다. 꺼낼 게 없었던 거죠.

7. 요약을 안 믿길 잘했습니다

"성공 374개"라는 요약은 완벽해 보였습니다. 그런데 결과물을 훑어보다가 이상한 걸 봤어요.

3. 하나님께서 첫째날 무엇을 창조하셨습니까?
. 하나님께서 각 피조물들을 무엇으로 창조하셨습니까?     ← "4."의 4가 없다
. 하나님께서 그 지으신 것들을 …                        ← 5도 없다
6. 하나님께서 각기 종류대로 …                           ← 6은 멀쩡
. 하나님께서 각 피조물의 자리를 …                       ← 7도 없다

1, 2, 3, 6은 멀쩡한데 4, 5, 7만 실종. 우연이 아니었습니다.

앞서 5번에서 기호를 살리려고 규칙을 완화했는데, 그 부작용으로 특정 숫자가 기호로 오인되어 통째로 먹히고 있었던 겁니다.
에러도, 경고도, 실패 표시도 없었습니다. 요약 숫자만 봤다면 절대 못 잡았을 버그였어요.

AI가 기호도 살리고 숫자도 지키는 방식으로 규칙을 다시 짜서 둘 다 해결했습니다.

8. 이제 합쳐야 하는데 — 말이 안 통한 순간

살려낸 374개를 원래 자료와 합칠 차례였습니다. 이렇게 요청했어요.

야 devlog.md 읽어보면 알텐데, 이거 기존의 자료랑 합치려고 하거든.
기존의 자료로 이거 가져가려면 어떡해?

AI는 양쪽 폴더를 대조해서 "374개 전부 짝이 맞고, 충돌 0건이니 그냥 부어넣으면 된다"며
방법 세 가지를 정리해줬습니다. 그런데 마지막에 이런 걸 덧붙였어요.

"한 가지 확인이 필요해. '기존의 자료'가 정확히 뭘 말하는 거야?
이 PC의 원본 폴더를 말하는 거면 그대로 진행하면 되는데,
혹시 이전에 성공했던 나머지 파일들의 모음을 말하는 거라면 — 드라이브를 다 훑어봤는데 그런 폴더가 없어."

제 말이 애매했던 겁니다. 제가 말한 "기존 자료"는 맥에 있는 1,737개였는데,
AI는 같은 PC 안의 폴더로 알아들을 수밖에 없는 상황이었어요.

그건 다른 컴퓨터에 있어. 그래서 374개만 따로 다른 컴퓨터에 이동해서 합치려고

이 한 문장으로 전제가 통째로 뒤집혔습니다. 같은 PC 안의 폴더 합치기가 아니라 다른 기계로의 이관이었으니까요.
AI가 제시했던 방법 세 개는 전부 무효가 됐습니다.

AI가 묻지 않고 실행했다면 엉뚱한 폴더에 374개를 부어넣었을 겁니다.
승인 전에는 아무것도 복사하지 않고 기다린 게 사고를 막았어요.

9. 옮기는 것도 그냥 옮기지 않았습니다

다른 컴퓨터로 옮기는 거라면 이야기가 달라집니다. 저쪽에서 무슨 일이 일어나는지 제가 볼 수 없으니까요.

AI는 시키지도 않았는데 안전장치를 겹겹이 깐 패키지를 만들었습니다.

• 파일 지문 목록 — 374개 전부의 지문을 기록해뒀다가, 저쪽에서 대조. 전송 중 깨진 파일이 있으면 거기서 중단

• 리허설이 기본값 — 실행 명령을 따로 주기 전까지는 아무것도 복사하지 않고 결과만 보여줌

• 덮어쓰기는 별도 승인 — 기존 파일과 충돌하면 목록만 뽑아주고 멈춤. 덮어쓰려면 명시적으로 한 번 더 허락해야 함

• 사후 검증 — 복사가 끝난 뒤 지문을 다시 확인

그리고 직접 다섯 가지 상황을 돌려서 검증까지 했습니다. 빈 폴더에 넣어보고, 일부러 충돌을 만들어서
보호 장치가 정말 막는지 확인하고, 복사 전후 목록이 완전히 일치하는지까지요.

"다른 컴퓨터로 옮긴다"고 말한 시점부터 검증까지 끝나는 데 7분이 걸렸습니다.
"될 겁니다"로 끝내지 않고 실제로 돌려본 게 핵심이었어요.

여기서 걸림돌이 하나 있었는데, 좀 웃겼습니다.
30년 전 포맷의 한글 인코딩과 그렇게 싸웠는데, 마지막에 발목을 잡은 건 요즘 쓰는 윈도우 셸이었어요.
스크립트에 한글 주석을 넣었더니 셸이 그걸 못 읽고 에러를 냈습니다. AI가 원인을 찾아 바로 고쳤고요.

10. 합쳐졌습니다 — 그리고 숫자가 맞았습니다

패키지를 맥으로 옮겨 검증했습니다.

• 파일 지문 374개 전부 통과 — 전송 중 손상 0

• 실패 목록과 대조: 374개 전부 정확히 1:1 매칭

• 목록에는 있는데 안 온 1개(SH0205)도 "원본이 백지"라는 설명과 일치

• 기존 자료와 충돌 0건

여기서 소름 돋는 게 하나 있었습니다.

윈도우 쪽 최종 집계는 V1.20 174개 / V2.00 31개 / V2.10 169개 = 374개였고,
맥에서 만든 실패 목록은 174개 / 31개 / 170개 = 375개였습니다.

서로 모르는 두 작업의 숫자가 독립적으로 일치했고, 딱 하나 차이 나는 게 그 백지 문서였습니다.
어느 쪽도 상대를 참고하지 않았는데 맞아떨어진 거죠. 이게 "제대로 됐다"는 가장 확실한 증거였습니다.

최종 2,111개. 변환율 99.95%.

11. 그런데 진짜 목적은 변환이 아니었습니다

파일이 2,111개로 정리됐지만, 처음 시작한 이유는 "찾아보고 싶다"였습니다.
폴더에 2,111개가 있는 건 2,112개가 있는 것과 크게 다르지 않았어요. 여전히 못 찾으니까요.

AI와 상의하다가 처음에 나온 아이디어는 "통독용 뷰어 앱"이었는데, 제가 이렇게 말했습니다.
주석은 읽는 게 아니라 찾아보는 자료다. AI가 이 관찰을 받아들여 방향을 바꿨습니다.

그래서 만든 게 검색 색인이었습니다. AI가 한 일은 이랬어요.

• 66개 폴더를 성경 66권에 1:1로 연결. 폴더 이름만으로 애매한 것들은 안에 든 파일 이름까지 열어서 교차 확인

• 각 문서를 절 단위 조각으로 분해 → 12,563개 조각

• 조각마다 "이건 로마서 8장 28절" 같은 정보를 붙여 검색 가능하게

1차 결과는 91%였습니다. 그런데 AI가 나머지를 들여다보다가 뭔가 발견했어요.

"절 번호가 없는 설교 노트 파일들도, 본문 안에 스스로 '본 문 : 창 22:9-21' 같은 선언을 해두고 있다."

이걸 추가로 인식하게 하자 91% → 94%로 올랐습니다.
저는 이런 게 있는지도 몰랐는데, AI가 자료를 읽다가 찾아낸 겁니다.

마지막으로 이 검색을 Claude Code 스킬로 등록해서, 이제는 명령을 따로 칠 필요도 없어졌습니다.
대화 중에 성경 구절 얘기가 나오면 AI가 알아서 주석을 찾아 인용해줍니다.

그리고 스킬 설명에 AI가 한계를 스스로 명시해뒀습니다.
"커버리지 94%", "원문 미연결", "자료가 두 장르로 섞여 있음" — 나중에 이걸 인용할 때 과신하지 말라고요.

✅ 결과 (After)

Before vs After

결과물

• 최종 변환 문서 2,111개 (약 29MB)

• 검색 색인 12,563개 조각, 그중 94%에 장·절 정보 부착

• 구절로 찾는 조회 도구 + Claude Code 스킬(자동 조회)

• 재실행 가능한 구형 HWP 변환기 + 사용 설명서 + 개발 기록

품질 확인: 포맷 종류마다 한글로 직접 열어 화면과 한 줄씩 대조했고,
본문은 물론 Ⅰ Ⅱ, ①②, ㄱㄴ 같은 목차 번호와 한자(戰亂, 豫告)까지 정확히 일치했습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. AI가 "막혔다"고 하면 그냥 되물어보세요. ⭐
   나도 잘 모르겠어. 어떡해? — 이 한마디가 전부를 바꿨습니다.
   전문 지식으로 대안을 제시할 필요가 없습니다. 모른다고 솔직히 말하고 되묻는 것만으로 충분했어요.
   AI는 "이 방법은 막혔다"고 보고했을 뿐, "모든 방법을 다 써봤다"는 뜻이 아니었거든요.

2. 결과를 원본과 직접 대조하게 시키세요.
   진짜 프로그램으로 열어서 화면이랑 비교해봐 — 이 지시 하나가 숨은 오류를 다 잡았습니다.
   AI가 자기 결과만 들여다보면 "원래 이런가 보다" 하고 넘어갑니다.
   목차 번호 누락도, 한자 오류도, 빈 문서 판정도 전부 대조에서 나왔습니다.

3. 막혔을 때 더 똑똑한 모델로 바꿔보세요.
   막힌 시점에 모델 등급을 올리고 같은 질문을 다시 했더니 접근 자체가 달라졌습니다.

4. "안 된다"는 진단도 한 번 의심하게 하세요.
   "64가지를 다 해봤는데 안 됩니다"가 사실은 엉뚱한 곳만 뒤진 것이었습니다.
   방법을 의심하기 전에 전제를 의심하라고 요청하면 방향이 바뀝니다.

5. 내 말이 애매하면 AI가 되묻게 두세요.
   "기존 자료랑 합쳐줘"에서 AI가 바로 실행하지 않고 "그게 정확히 뭐냐"고 물어봐서 사고를 막았습니다.
   파일을 지우거나 덮어쓰는 작업에서는 "실행 전에 확인받아"라고 미리 못 박아두면 훨씬 안전합니다.

이렇게 하면 안 돼요

1. 요약만 보고 끝내지 마세요.
   "성공 374개"는 완벽해 보였지만, 실제 파일을 열어보니
   목록의 숫자 4·5·7이 조용히 사라져 있었습니다. 에러도 경고도 없이요.
   결과물을 직접 몇 개는 끝까지 훑어봐야 합니다.

2. AI의 첫 "불가능" 판정을 최종 결론으로 받아들이지 마세요.
   여기서 멈췄다면 375개는 그대로 묻혔을 겁니다.

3. 중간 점검 없이 전체를 한 번에 돌리지 마세요.
   먼저 1~2개로 확인하고, 원본과 맞는지 본 다음에 전체를 돌리는 게 훨씬 빠릅니다.

4. 파일을 옮기거나 합칠 때 바로 실행시키지 마세요.
   "먼저 리허설로 뭐가 일어날지만 보여줘"를 습관으로 만드세요.
   특히 결과를 내가 눈으로 확인할 수 없는 곳(다른 컴퓨터, 외장 디스크)이라면 필수입니다.

🌍 다른 업무에 적용한다면?

이번 경험의 핵심은 "옛날 한글 파일"이 아니라
"표준 도구가 실패했을 때, 전문 지식 없이도 포기하지 않는 법" 입니다.

• 옛날 엑셀·워드·한글 파일이 안 열릴 때 — 같은 접근으로 내용만이라도 꺼낼 수 있습니다

• 회사 전용 프로그램에서 데이터를 못 빼낼 때 — 저장된 파일 자체를 살펴보는 길이 있습니다

• 흩어진 내 자료를 AI가 쓰게 하고 싶을 때 — "변환 → 정리 → 색인 → 스킬 등록" 흐름은 어떤 자료에도 그대로 적용됩니다
  (회의록, 계약서, 논문, 강의 노트 전부 같은 방식)

• 컴퓨터 두 대를 오가며 작업할 때 — 지문 목록 + 리허설 + 사후 검증 3종 세트는 어떤 이동에도 씁니다

• "이건 원래 안 돼요"라는 말을 들었을 때 — 정말 안 되는 건지 한 번은 확인해볼 가치가 있습니다

🚀 앞으로의 계획

1. 성경 원문 연결 — 지금은 주석만 있어서, 구절 원문과 나란히 보려면 원문 확보가 필요합니다.
   개역한글·개역개정은 저작권 소관이 있어 라이선스 확인이 선행돼야 하는 상태입니다

2. 의미 검색 추가 — 지금은 키워드가 정확히 맞아야 찾힙니다.
   "은혜로 구원받는다" 같은 문장으로도 관련 주석이 나오게 만드는 게 다음 단계입니다

3. 변환기 공개 — 구형 HWP를 푸는 도구가 사실상 없는 상황이라,
   같은 문제로 곤란한 분들이 쓸 수 있도록 변환기와 설명서를 공개할 계획입니다

📋 재사용 가능한 프롬프트

프롬프트 1: 변환 가능성부터 진단시키기

[폴더 경로]에 있는 파일들을 [원하는 형식]으로 변환하려고 해.
지금 도구로는 실패하는데, 변환 가능한지 먼저 살펴봐줄래?
안 되면 왜 안 되는지 원인부터 알려줘.

프롬프트 2: 막혔을 때 되묻기 (가장 중요) ⭐

나도 잘 모르겠어. 어떡해?

• 정말 이게 전부입니다. 아는 척하지 말고 그대로 던지세요.

• 조금 더 강하게 밀고 싶다면: 아직 안 해본 방법이 정말 하나도 없어? 다른 각도로 접근해볼 수 있을까?

프롬프트 3: 원본과 대조 검증시키기

변환 결과가 원본이랑 진짜 같은지 확인해줘.
[원래 프로그램]으로 파일을 직접 열어서 화면이랑 한 줄씩 비교하고,
빠지거나 깨진 부분이 있으면 찾아줘.

프롬프트 4: 전체 작업 전 표본 검증

전체를 돌리기 전에 먼저 2~3개만 변환해서 결과를 보여줘.
내가 확인하고 괜찮으면 그때 전체를 진행하자.

프롬프트 5: "안 된다"는 결론 의심하기

지금까지 시도한 방법이 다 실패했다고 했는데,
혹시 방법이 아니라 전제가 틀렸을 가능성은 없을까?
찾는 위치나 범위, 조건 자체를 다시 점검해줘.

프롬프트 6: 안전하게 옮기고 합치기

이 결과물을 [다른 컴퓨터 / 다른 폴더]의 기존 자료와 합치려고 해.
바로 복사하지 말고, 먼저 리허설로 뭐가 일어날지만 보여줘.
파일이 깨지지 않았는지 확인할 수단이랑, 기존 파일과 겹치면
덮어쓰기 전에 나한테 물어보는 장치도 같이 만들어줘.

프롬프트 7: 내 자료를 AI가 찾아보게 만들기

[폴더 경로]에 있는 문서들을 내가 필요할 때 찾아볼 수 있는 형태로 만들고 싶어.
이 자료는 처음부터 읽는 게 아니라 [찾는 기준: 예-날짜, 구절, 고객명]으로
찾아보는 자료야. 어떤 구조가 좋을지 먼저 제안해줘.

프롬프트 8: 작업 기록 남기기

지금까지 진행한 모든 과정을 개발 기록으로 정리해줘.
내가 요청한 것, 네가 실행한 것, 중간에 실패했다가 수정해서 성공한 이야기까지
빠짐없이 자세하게 적어줘.