개념
문서는 데이터가 아니라 의존성이다
업무 시스템에서 "첨부파일 업로드가 된다"는 확인은 거의 아무것도 보장하지 않는다. 그 파일은 목록에 이름으로 표시되고, 브라우저에서 미리보기로 렌더링되고, 결재 문서에 붙어 결재선을 따라 흐르고, 기안 본문과 합쳐져 하나의 PDF 로 만들어지고, 보존 연한 동안 보관되고, 나중에 다른 시스템으로 이관된다. 각 단계가 서로 다른 구현을 쓰고, 각 단계마다 포맷을 다르게 이해한다.
그래서 문서 기능의 결함은 "업로드 실패" 형태로 오지 않는다. "올라가긴 했는데 미리보기에서 표가 깨진다", "결재 PDF 에서 글꼴이 바뀐다", "특정 문서만 변환이 안 된다" 형태로 온다. 이런 결함은 문서마다 재현되기도 하고 안 되기도 해서, 재현 문서를 특정하지 못하면 조치도 확인도 불가능하다. 이 레슨의 절반은 어떤 문서로 시험할 것인가 에 관한 것이다.
HWP 와 HWPX — 두 포맷을 구분한다
국내 공공 문서의 기본 포맷은 한글 문서다. 여기에는 계열이 둘 있고, 시험 설계에서 이 둘을 구분하지 않으면 결함 분류가 엉킨다.
| 구분 | HWP | HWPX |
|---|---|---|
| 구조 | 바이너리 복합 문서 | XML 기반 패키지(압축 컨테이너 안에 XML 문서들) |
| 표준 | 제품 고유 포맷 | KS X 6101 「개방형 워드프로세서 마크업 언어(OWPML) 문서 구조」 를 따르는 개방형 포맷 |
| 특징 | 오래된 문서 대부분이 이 형식 | 기계 판독이 쉬워 검색·추출·변환에 유리 |
KS X 6101 은 XML 기반의 개방형 워드프로세서 마크업 언어를 정의한 한국산업표준이다. 제정 연도와 현행 개정판, 표준의 정확한 명칭 표기는 e나라 표준인증(standard.go.kr)에서
조회해 인용한다 — 이 레슨은 표준 번호와 성격까지만 확인해 적었고, 개정 이력은 원문 확인 대상으로 남긴다.
QA 관점에서 둘을 구분해야 하는 이유는 명확하다. 같은 기능이 두 포맷에서 다르게 동작한다. 변환 라이브러리가 HWPX 만 지원하거나, 미리보기가 HWP 에서만 표를 잃거나, 텍스트 추출이 한쪽에서만 되는 상황이 흔하다. 시험 대상 시스템이 어느 포맷을 어디까지 지원한다고 선언했는지를 먼저 확정하고, 선언되지 않은 조합은 "미지원"이 맞는지 요구사항으로 되돌린다.
세 갈래 — 뷰어·편집기·변환
문서를 다루는 기능은 세 가지로 나뉘고, 각각 시험 관점이 다르다.
뷰어(보기). 문서를 화면에 표시한다. 시험 관점은 렌더링 충실도 다. 표 구조, 병합된 셀, 다단 편집, 글상자, 도형, 수식, 머리말·꼬리말, 쪽 번호, 이미지 위치, 글꼴 대체가 확인 대상이다. 글꼴이 가장 자주 깨진다 — 작성자 PC 에만 있던 글꼴이 서버에 없으면 대체 글꼴로 렌더링되고, 줄바꿈 위치가 바뀌면서 쪽 수가 달라진다. 쪽 수가 달라지면 "3쪽 표 참조" 같은 본문 서술이 틀어진다.
편집기(작성·수정). 시스템 안에서 문서를 만들거나 고친다. 시험 관점은 왕복(round-trip) 무결성 이다. 열었다가 그대로 저장했을 때 내용이 보존되는가, 편집 후 저장한 문서를 원래 편집기에서 열 수 있는가, 스타일과 서식이 유지되는가. 왕복을 두 번·세 번 반복했을 때 누적 손실이 생기는지도 본다.
변환. HWP → PDF, HWP → HWPX, 문서 → 이미지, 문서 → 텍스트 등이다. 시험 관점은 정보 손실의 허용 범위 다. 변환은 본질적으로 손실을 포함하므로, "손실 없음"이 아니라 "무엇까지 유지되어야 합격인가"를 먼저 정해야 한다. 이 기준이 없으면 변환 결함은 영원히 "원래 그런 것"과 "결함" 사이에서 논쟁한다.
[변환 합격 기준의 예 — 기준을 문장으로 고정한다]
· 본문 텍스트는 문자 단위로 일치한다 (공백·줄바꿈 제외)
· 표의 행·열 수와 병합 구조가 유지된다
· 쪽 수가 원본과 같다
· 이미지가 모두 포함되며 위치가 같은 쪽에 있다
· 글꼴은 지정 글꼴 목록 안에서 대체될 수 있다 (대체 목록을 문서로 고정)
· 머리말·꼬리말·쪽 번호가 유지된다대표 문서 세트 — 이 레슨의 핵심
문서 호환성 시험을 "몇 개 열어 보기"로 하면 결과를 신뢰할 수 없다. 필요한 것은 대표 문서 세트 다. 근거를 갖고 구성한 고정된 문서 묶음이고, 회귀 시험에서 매번 같은 것을 쓴다. 구성 원칙은 셋이다.
1. 실제 업무 문서에서 뽑는다. 발주 기관이 실제로 쓰는 서식 — 기안문, 보고서, 공문, 계약 서류, 통계표 — 을 확보한다. 개인정보와 비공개 정보를 제거한 사본 으로 만들고, 제거 절차를 기록으로 남긴다(레슨 5 의 데이터 반출 통제와 이어진다). 인터넷에서 받은 임의의 문서로 만든 세트는 기관의 실제 서식 특성을 대표하지 못한다.
2. 위험 요소별로 채운다. 실제 문서만 모으면 특정 구조가 빠진다. 아래 축을 표로 만들고 각 칸을 채울 문서를 지정한다. 실제 문서에 없는 칸은 합성 문서 를 만들어 채운다.
[구조] 단순 텍스트 / 복잡한 표(병합·중첩) / 다단 / 글상자·도형 / 수식 / 차트
[서식] 표준 글꼴만 / 특수 글꼴 포함 / 다국어(한자·일본어·특수문자) / 이모지
[크기] 1쪽 / 30쪽 / 200쪽 / 용량 상한 근처 / 상한 초과(거부 확인용)
[자산] 이미지 없음 / 고해상도 이미지 다수 / 개체 연결 / 외부 참조
[버전] 구버전 편집기로 작성 / 최신 편집기로 작성 / 다른 제품에서 변환해 온 문서
[포맷] HWP / HWPX / 각각의 암호 설정본 / 손상된 파일(오류 처리 확인용)3. 각 문서에 기대 결과를 붙인다. 세트의 값은 문서 자체가 아니라 "이 문서에서 무엇을 확인하는가" 에 있다. 문서마다 확인 항목과 기대 결과를 적은 목록을 함께 관리한다.
DOC-014 30쪽 통계 보고서 (병합 셀 표 12개, 차트 4개, 특수 글꼴 1종)
확인: 미리보기에서 표 병합 구조 유지 / PDF 변환 후 쪽 수 30 / 차트 이미지 포함
기대: 글꼴은 대체 목록의 고딕 계열로 치환 가능 (본문 줄바꿈 위치 변경 허용 안 함)
출처: OO과 2025년 상반기 보고서 (개인정보 제거 2026-03-11, 담당 OOO)세트가 완성되면 버전을 붙여 형상 관리에 넣는다. 문서가 바뀌면 결과가 바뀌므로, 어떤 세트로 시험했는지가 기록돼야 결과를 비교할 수 있다. 이 세트는 사업이 끝난 뒤 운영 단계의 회귀 시험에서도 그대로 쓰이고, 다음 고도화 사업의 착수 자산이 된다.
암호 걸린 문서와 손상된 파일을 반드시 넣는다. 둘 다 정상 처리 대상이 아니라 오류 처리 확인 대상 이다. 시스템이 멈추거나 내부 오류를 노출하지 않고 사용자에게 이해 가능한 안내를 주는지가 판정 기준이다. 이 두 칸이 빠진 세트가 대부분이다.
첨부·미리보기·전자결재 연동
문서가 시스템 안에서 지나가는 경로를 그려 두면 시험 지점이 드러난다.
업로드 → 저장(원본 보관) → 바이러스 검사 → 변환(미리보기용·PDF)
→ 목록 표시 → 미리보기 → 다운로드
→ 기안 첨부 → 결재선 이동 → 결재 완료 문서 생성(본문+첨부 병합)
→ 시행·발송 → 보존·이관각 화살표가 실패 지점이다. 특히 자주 깨지는 곳은 이렇다.
| 지점 | 대표적 실패 | 확인 방법 |
|---|---|---|
| 업로드 → 저장 | 파일명 인코딩 손상, 용량 상한 불일치, 동일 파일명 충돌 | 한글·공백·특수문자·긴 파일명, 상한 경계값, 같은 이름 연속 업로드 |
| 바이러스 검사 | 검사 지연으로 타임아웃, 검사 실패 시 상태 미정의 | 대용량 파일, 검사 서버 무응답 상황 |
| 변환 | 특정 구조에서만 실패, 변환 큐 적체, 실패 후 재시도 없음 | 대표 문서 세트 전수, 동시 다건 업로드 |
| 미리보기 | 표·글꼴 깨짐, 큰 문서 로딩 실패, 권한 없는 사용자 접근 | 세트 전수 + 직접 URL 접근 시도 |
| 결재 문서 생성 | 본문·첨부 병합 순서 오류, 쪽 번호 중복, 첨부 누락 | 첨부 0·1·다수, 대용량 첨부, 중간 결재자 첨부 추가 |
| 보존·이관 | 원본이 아닌 변환본만 남음, 메타데이터 유실 | 보존 연한 정책 확인 후 저장 실체 점검 |
"결재 완료 후 원본이 남는가" 는 특히 중요하다. 미리보기용 변환본만 보관하고 원본을 지우는 구현이 실제로 존재하고, 이것은 공문서 보존 요건과 충돌할 수 있다. 요구사항에 명시가 없으면 질문으로 올린다.
메신저·화상회의·문서 협업 도구 연동
사내 메신저, 화상회의, 문서 협업 도구와의 연동은 대개 "알림을 보낸다", "회의를 잡는다", "문서를 공유한다" 수준의 한 줄 요구로 온다. 연동 지점을 나누면 시험 대상이 드러난다.
[인증·계정] 사용자 매핑(사번 ↔ 도구 계정), 퇴사·휴직 계정, 토큰 만료·갱신
[발신] 알림 전송, 재시도, 중복 발송 방지, 수신자 부재·비활성 계정
[수신·콜백] 회의 생성 결과 수신, 상태 변경 웹훅, 순서 뒤바뀜, 중복 수신
[자원] 회의실·라이선스 한도 초과, 동시 회의 수 제한
[권한] 공유 문서의 접근 범위, 외부 참여자 허용 여부
[시간] 시간대·서머타임, 반복 일정, 일정 변경·취소 전파
[장애] 도구 측 장애 시 업무 시스템이 멈추는가 (연동 실패의 전파 범위)마지막 줄이 설계 결함으로 이어지는 가장 큰 항목이다. 알림 전송 실패가 본래 업무(결재 상신)를 실패시키면 안 된다. 이 확인은 정상 경로 시험에서 절대 나오지 않는다 — 연동 대상을 의도적으로 끊고 업무를 수행해 봐야 나온다. 시험 환경에서 외부 도구를 끊는 방법(모의 서버, 방화벽 차단)을 미리 준비한다.
중복과 순서 도 단골이다. 웹훅은 재전송되고, 순서가 보장되지 않는다. 같은 콜백이 두 번 와도 결과가 같은지(멱등성), 늦게 도착한 오래된 상태가 최신 상태를 덮어쓰지 않는지를 확인한다.
연동 시험에서 QA 가 가장 먼저 확보해야 할 것은 연동 대상 도구의 시험 테넌트 다. 운영 테넌트에서 시험하면 실제 사용자에게 알림이 가고, 그 사고는 한 번으로 끝나지 않는다. 테넌트 확보는 리드 타임이 길어서 착수 시점에 요청해야 한다.
실무에서 왜 필요한가
문서 호환성 결함은 사용자가 가장 먼저 보고 가장 오래 기억하는 결함 이다. 결재 문서의 표가 깨져 나오면 그 시스템은 "못 쓰는 시스템"이 된다. 기능 목록상으로는 한 줄짜리 항목이지만 사용자 수용에 미치는 영향은 그 이상이다.
동시에 이 영역은 재현 문서를 특정하지 못하면 아무것도 진행되지 않는 영역이기도 하다. "가끔 깨진다"는 결함 보고는 조치도 확인도 불가능하다. 대표 문서 세트를 만들어 두면 결함 보고가 "DOC-014 에서 재현"이 되고, 조치 후 확인도 같은 문서로 끝난다. 이 세트는 사업 종료 후에도 남아 운영 회귀와 다음 사업의 자산이 된다.
연동 쪽은 이유가 다르다. 협업 도구 연동은 요구사항이 가장 얇게 쓰이는 영역 이라서, QA 가 연동 지점을 나눠 질문하지 않으면 설계 자체가 비어 있는 채로 개발된다. 위 일곱 축은 요구사항 정제 회의에 그대로 가져갈 수 있는 질문 목록이다.