Replies: 1 comment
-
|
case-by-case 비일관성.. 충격적입니다.. 일관된 출력이 없다는 점이 정말로 안타깝습니다 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
오늘 사이클의 한 장면
PR #434 (그림 자동 크롭 정정) 검토 중 발견된 정황입니다.
samples/exam_kor.hwp1쪽 상단 헤더 이미지에 대해 세 가지 한컴 환경의 PDF 출력을 비교 했습니다.세 PDF 가 모두 다릅니다.
같은 hwp, 같은 한컴 제품군, 그러나 버전과 도구별로 다른 조판. 더 흥미로운 건 시험지 원본의 정황입니다 — JPEG 이미지에 "국어 영역(A 형)" 이라는 텍스트가 박혀 있었습니다. 2014년 A형/B형 수능 시절의 잔재. 시험지 조판자는 의도적으로 그 텍스트를 보존했습니다. 한컴은 박스 비율에 맞춰 자동 크롭 하여 "(A 형)" 부분을 잘라냈습니다 — 이쁘게 보이도록.
저는 이 순간 한 가지 질문에 부딪혔습니다. "누가 정답인가?"
한컴의 기술부채 — 다섯 가지 층위
오늘 사이클의 16건 PR 을 처리하며 누적된 정황입니다.
1. 정답지 자체의 분열
위키 페이지 "한컴 PDF 환경 의존성" 에 정리한 정황입니다.
발견 정황 I 까지는 "한컴 2010 + 한컴 2022 편집기는 일관 (35쪽)" 으로 정리했습니다. 발견 정황 II 가 그 가정을 다시 무너뜨렸습니다. 한컴 자신도 자기 포맷의 단일 권위 구현을 보장하지 못합니다.
2. 자동 처리의 자의성
이미지 자동 크롭 케이스가 명확합니다. 시험지 조판자가 의도적으로 "(A 형)" 을 박아둔 자료를 한컴이 박스 비율 맞춰 자동 크롭하면, 결과물은 원본 의도와 달라집니다.
"한컴이 정답" 이라는 가정은 한컴이 사용자 의도를 가장 잘 보존한다 는 전제 위에 섭니다. 그 전제가 자동 처리 영역에서 무너집니다. 한컴은 "이쁘게 보이도록" 처리하는 코드를 넣었고, 그게 항상 사용자 의도와 일치하지 않습니다.
본 사이클에서 작업지시자 시각 판정 시 마주친 흥미로운 순간 — rhwp 의 출력이 (자동 크롭 안 함) 시험지 조판자 의도에 더 부합 하는 케이스가 있었습니다. "정답 추격" 의 방향성이 문제가 되는 지점입니다.
3. case-by-case 비일관성
이미 메모리화한 원칙입니다 (feedback_hancom_compat_specific_over_general).
오늘 사이클의 PR 들 — #391 (다단 누적), #406 (inline TAC), #408 (orphan vpos), #410 (chart), #424 (vpos anchor), #434 (crop) — 본질적으로 모두 한컴 비일관성에 대응하는 케이스별 가드 입니다. 알고리즘 정정이 아닙니다. 일반화하면 다른 케이스가 깨집니다.
v0.7.6 사이클의 광범위 회귀 정황 (외부 PR #320 등 다수) 이 정확히 이 함정에 빠진 사례입니다 — "하나의 케이스를 위해 일반화한 알고리즘" 이 다른 케이스들을 깨뜨렸습니다. v0.7.7 가 회귀 정정 사이클이 된 이유.
4. 자기 라운드트립 ≠ 한컴 호환
이미 메모리화 (feedback_self_verification_not_hancom). Discussion #188 에서 짚은 정황의 다른 면입니다.
스펙은 공개됐습니다. 그러나 한컴 편집기의 실제 파서/렌더러 구현이 스펙과 다른 정황 이 존재합니다. 스펙만 따른 직렬화는 한컴이 거부할 수 있습니다. PR #428 (그룹 내 그림 직렬화) 검토 시 작성자에게 보강 요청한 이유입니다.
이는 스펙 vs 실제 구현 간 격차 이고, 외부 구현체가 스펙만 보고 호환을 보장할 수 없는 정황을 만듭니다.
5. 영역 확장의 long tail
발견 정황 I (페이지 분할) → 발견 정황 II (이미지 자동 크롭). 새 영역마다 새로운 비일관성 발견 입니다.
오늘 사이클의 미해결 이슈들이 이를 보여줍니다:
각각이 다른 영역, 다른 처리 경로입니다. 무한 long tail.
운영의 기술 — 대응 전략
이 정황에서 메인테이너로서 내린 운영 결정들입니다.
1. 작은 단위 PATCH 빠른 회전
본 사이클에서 v0.7.8 을 PATCH 로 묶어 빠르게 머지했습니다. 신규 API 3건 + 신규 모듈 (paint, opt-in) 포함했지만 PATCH. SemVer 정석으로는 MINOR 가 맞습니다.
이유:
메모리로 등록 했습니다.
2. 메인테이너 직접 시각 검증을 머지 게이트로
CI 통과 + 자동 회귀 테스트 통과 + 컨트리뷰터의 PDF 비교 자료가 있어도, 마지막 게이트는 메인테이너가 한컴 정답지와 직접 비교 합니다.
이유 (feedback_v076_regression_origin):
3. 일반화보다 케이스별 명시 가드
PR 리뷰 시 "이 알고리즘이 모든 케이스를 다룬다" 보다 "이 케이스는 명시적으로 이렇게 처리한다" 를 우선합니다. 코드는 더 verbose 해지지만 회귀 위험이 낮습니다.
본 사이클 PR #410 (Task #409) 가 좋은 예 —
prev_has_overlay_shape가드를Picture (non-TAC) + TopAndBottom + vert=Para라는 3 조건 명시 로 좁혔습니다. 일반화하면 다른 케이스 회귀.4. 환경 의존성 자료 공개
오늘 한컴 2010 / 2020 / 한컴독스 3종 PDF 를
samples/에 commit 했습니다. 위키 페이지 보강 + README.md / README_EN.md 에 위키 링크 추가. 모든 컨트리뷰터와 fork 사용자가 환경별 차이를 시각적으로 비교 할 수 있도록 정답지 자료 공유."단일 한컴 정답지" 가정의 위험을 외부에 명시하는 것이 메인테이너의 책무 라고 판단했습니다.
5. 자기 라운드트립 테스트의 함정 인식
PR #428 검토 시 작성자에게 보강 요청한 사례:
Document::default + 수동 push → serialize → parse) 은 항상 참인 무의미한 테스트 입니다CONTRIBUTING.md 에 정책으로 반영하는 것을 다음 사이클 후보로 검토 중입니다.
결론 — 운영의 기술이 절실한 시점
본 통찰의 결론은 단순합니다.
한컴의 기술부채 (포맷 비일관성 + 자기 환경 분열 + 자동 처리의 자의성 + 스펙 vs 구현 격차 + 무한 long tail) 가 rhwp 의 무한 정정 사이클의 origin 입니다.
이 정황에서 우리가 선택할 수 있는 것은:
저는 운영 전략을 선택했습니다. 이유:
오늘 PR 리뷰 사이클 마치고 작업지시자로서 다시 새겨두는 건 — "너무 많은 걸 묶어 완성도를 높이려는 행위가 위험요소를 키운다" 는 인식. 운영의 기술은 완성을 추구하는 것이 아니라 위험을 분산하는 것 입니다.
시리즈 글
참고 자료
Beta Was this translation helpful? Give feedback.
All reactions