HWP 파싱 타임아웃:
원인·수정·검증

01 문제점

케빈랩 HWP는 한글에서 정상적으로 열리고, 원본의 문제 구간도 HWP 구조상 정상입니다. 그런데 hwp_hwpx_parser의 하이퍼링크 사전 탐색 코드가 특정 제어 문자를 14바이트만 소비해, 남은 바이트를 다시 같은 제어 문자로 오인했습니다. 그 뒤 읽을 수 있는 바이트가 부족해도 현재 위치를 옮기지 않아 무한 반복이 발생했고, 추출 작업이 600초 후 타임아웃되었습니다.

02 본문 레코드에서 필요한 설명

HWP 본문은 글자만 이어진 텍스트가 아닙니다. 문단 안에는 글자와 함께 “여기부터 목차 필드가 시작된다”, “문단이 끝났다”처럼 문서 구조를 알리는 제어 문자가 들어 있습니다. 케빈랩의 문제 레코드는 태그 67 (문단 텍스트)이고, 본문 길이는 정확히 18바이트입니다.

03 해결방안

1. 0x0003 Field Start를 발견하면 14바이트가 아니라 16바이트를 하나의 확장 제어 문자로 처리합니다.
2. 남은 길이가 16바이트보다 짧으면, 불완전한 제어 문자를 억지로 해석하지 말고 해당 문단의 사전 탐색을 안전하게 끝냅니다.
3. 어떤 제어 문자 분기에서도 반복문 위치 i가 이동하거나 종료되는지 보장합니다. 이 안전장치가 있어야 새 RFP에서 예외적인 데이터가 와도 무한 루프가 나지 않습니다.
4. 케빈랩 원본을 회귀 테스트로 추가하고, 전체 HWP 코퍼스의 결과가 바뀌지 않는지 비교합니다.

04 다른 HWP 파일들은 왜 됐었나

다른 HWP가 모두 “제어 문자가 없어서” 성공한 것은 아닙니다. 96개 HWP 중 83개에 0x0003 Field Start가 있었고, 총 677회 등장했습니다. 다만 케빈랩은 그 Field Start가 문단의 거의 끝에 있어서, 잘못 14바이트를 건너뛴 뒤 남은 03 00 0d 00을 다시 읽는 순간 이동할 여지가 없어졌습니다.

05 소스 수정해야 되는 부분

문제가 있는 함수는 _extract_hyperlink_texts_from_para입니다. 현재 로컬 검증은 설치된 라이브러리 파일에서 했지만, 팀 적용 시에는 해당 라이브러리의 관리 가능한 포크 또는 패치된 버전으로 반영해야 합니다.

if code == 0x03:
    text_start = i + 14
    ...
    i += 14

if code == 0x03:
    field_start_size = 16
    if i + field_start_size > len(para_data):
        break
    text_start = i + field_start_size
    ...
    i += field_start_size

06 Test 결과