이 문서는 rhwp가 어디로 가고 있으며, 각 버전을 언제 완성으로 볼 것인지 설명하는 기준 문서입니다.
현재 버전: v0.8.4
현재 목표: v1.0.0 — 조판 엔진 체계화, 한컴오피스와 같은 조판 구현
최근 검토: 2026-08-10, #4467
HWP와 HWPX는 공공기관, 학교, 기업에서 널리 쓰이지만 특정 회사의 프로그램과 운영체제에 크게 의존해 왔습니다. rhwp는 공개된 문서 형식과 실제 문서를 바탕으로, 누구나 한글 문서를 읽고 편집하고 저장할 수 있는 오픈소스 문서 엔진을 만듭니다.
사람뿐 아니라 AI도 같은 기능을 안전하게 사용할 수 있어야 합니다. 문서를 읽고 쓰는 것에 그치지 않고, 원본의 쪽 배치와 서식을 얼마나 잘 보존했는지 확인할 수 있어야 합니다.
처음 프로젝트를 시작할 때 세운 방향은 지금도 같습니다.
혼자 뼈대를 세우고, 함께 살을 붙이고, 모두의 것으로 완성한다.
0.5 ───────── 1.0 ───────── 2.0 ───────── 3.0
기반 조판 협업 공공 자산
여기서 숫자는 모든 작업을 차례대로 시작한다는 뜻이 아닙니다. 각 버전은 프로젝트가 공식적으로 완성했다고 선언할 목표와 성숙도를 나타냅니다. 뒤 버전의 기반이 먼저 마련되거나, 여러 버전의 작업이 필요에 따라 함께 진행될 수 있습니다.
현재 진행
v1.0 조판 ━━━━━━━━━━━▶ v1.0 완료
v2.0 협업 ━━━━━━━━━━━━━━━━━▶ v2.0 완료
v0.5.0에서 문서를 읽고 쓰고 화면에 그리는 기본 뼈대를 공개했습니다. 이후 v0.8.x 까지 HWP 3.0, HWP 5.0, HWPX와 HML 지원을 넓히고, 브라우저 편집기와 여러 출력 방식을 발전시켰습니다.
현재 rhwp에서는 v1.0 조판과 v2.0 협업 기반을 함께 발전시키고 있습니다.
조판에서는 같은 문서를 rhwp와 한컴오피스에서 열었을 때 쪽수, 표의 나뉨, 글자와 그림의 위치가 가능한 한 같아지도록 다듬고 있습니다. 문서를 편집한 뒤에도 이 배치가 안정적으로 다시 계산되어야 합니다.
협업은 예상보다 빠르게 성장했습니다. v1.0에 이르기 전인 2026년 8월 현재 이미 40명이 넘는 외부 기여자와 두 명의 공동 유지보수자(콜레보레이터)가 프로젝트에 참여하고 있습니다. 외부 기여자가 기능과 오류 수정을 제안하고, 공동 유지보수자와 메인테이너가 검토와 통합을 나누어 맡는 협업 체계가 실제로 운영되고 있습니다.
| 단계 | 상태 | 이루려는 것 |
|---|---|---|
| v0.5 기반 | 완료 | 문서를 읽고 쓰고 그릴 수 있는 공통 엔진 공개 |
| v1.0 조판 | 집중 진행 중 | 한컴오피스와 같은 쪽 배치와 안정적인 재조판 |
| v2.0 협업 | 함께 진행 중 | 사람이 함께 개발하고 AI와 외부 프로그램이 활용하는 열린 생태계 |
| v3.0 공공 자산 | 장기 목표 | 특정 회사에 종속되지 않는 실무용 한글 문서 기반 |
버전 상태는 작업의 시작 여부와 버전 전체의 완성을 구분합니다. 협업이 이미 활발하더라도 지속 가능한 역할 분담, 확장 기능의 호환성, 실패 복구와 유지 책임까지 갖춰야 v2.0을 완성으로 볼 수 있습니다.
v0.5의 목표는 다른 기능을 올릴 수 있는 공통 뼈대를 세우는 것이었습니다.
- HWP 5.0과 HWPX를 읽어 하나의 내부 문서 구조로 다룹니다.
- 문단, 표, 수식, 그림 등 주요 내용을 여러 쪽에 걸쳐 배치합니다.
- 수정한 문서를 다시 저장하고 열 수 있습니다.
- 명령줄 도구와 웹어셈블리(WebAssembly)를 통해 데스크톱과 브라우저에서 같은 엔진을 사용합니다.
- 웹 편집기와 VS Code 확장처럼 실제 사용자가 접하는 프로그램을 제공합니다.
v0.5.0은 2026년 3월 29일 공개되었습니다. 자세한 내용은 CHANGELOG의 0.5.0 기록에서 확인할 수 있습니다.
이 단계에서 기본 기능은 갖췄지만, 모든 문서가 한컴오피스와 같은 모양으로 나오는 것은 아니었습니다. 그 차이를 줄이는 것이 v1.0의 중심 과제입니다.
문서를 읽고 편집하고 다시 저장해도 쪽수와 배치가 예측 가능하게 유지되는 조판 엔진을 완성합니다. 현재 GitHub의 v1.0.0 목표는 이를 “조판 엔진 체계화 — 한컴 동일 조판 구현”으로 정의합니다.
- HWP 3.0, HWP 5.0, HWPX와 HML에서 읽은 내용이 같은 내부 문서 구조로 정확하게 이어져야 합니다.
- 줄과 쪽을 나누는 정보, 표와 다단, 각주·미주, 글자처럼 놓인 개체와 떠 있는 개체를 정확히 배치해야 합니다.
- 문서를 편집하면 영향을 받은 줄과 쪽을 다시 계산하고, 불필요하게 다른 쪽까지 흔들리지 않아야 합니다.
- SVG, 브라우저 화면, PNG와 PDF가 같은 조판 결과를 일관되게 그려야 합니다.
- 실제 문서에서 발견한 오류는 재현용 샘플과 회귀 테스트로 남기고, 필요한 경우 한컴오피스 출력과 눈으로 비교한 근거도 함께 남겨야 합니다.
- 저장 과정에서 잃을 수 있는 정보와 지원하지 않는 기능을 사용자에게 숨기지 않아야 합니다.
- v1.0.0에 남아 있는 이슈를 검토해 완료할 것, 다음 버전으로 넘길 것, 지원 범위에서 뺄 것을 구분합니다.
- 조판과 편집 오류를 고칠 때마다 재현 샘플, 회귀 테스트, 필요한 시각 비교 자료가 함께 남습니다.
- 지원하는 문서 형식의 저장과 다시 열기, 배포 대상별 출시 전 검증을 통과합니다.
- v1.0.0을 출시하면서 실제 지원 범위와 알려진 한계를 변경 기록에 함께 공개합니다.
실시간 공동 편집, 범용 플러그인 생태계, 클라우드 서비스, 모든 HWP 기능 지원은 v1.0의 완료 조건이 아닙니다. 필요한 기반 작업은 먼저 진행할 수 있지만, 사용자 요구와 검증 근거를 확인하고 각각 승인합니다.
관련 기술 기준은 파서 구조, 렌더링 엔진 설계, 표 배치 규칙, 글꼴 대체 전략, 문서 저장 기술 가이드에서 확인할 수 있습니다.
새로운 기여자가 문서 엔진을 함께 다듬고, 외부 프로그램과 AI가 같은 기능을 재사용할 수 있는 생태계를 만듭니다. 조판이 모두 완성된 뒤 협업을 시작하는 것이 아니라, 실제 기여와 검토 과정에서 발견한 문제를 다시 조판·편집·저장 품질에 반영하며 두 목표를 함께 발전시킵니다.
2026년 8월 현재 40명이 넘는 외부 기여자와 두 명의 공동 유지보수자가 참여하고 있습니다. 외부 기여 절차, 브라우저와 VS Code 확장, 명령줄의 JSON 출력, MCP 서버 같은 기반도 이미 있습니다. 이는 v2.0의 협업 체계가 실제로 작동하기 시작했다는 근거입니다. 다만 참여 인원이나 기능의 존재만으로 v2.0 전체가 완성된 것은 아닙니다.
rhwp를 기반으로 한 데스크톱·사내 뷰어·Google Docs·macOS·iOS·Android 앱과 여러 백엔드 연계도 다운스트림에서 활발히 성장하고 있습니다. v2.0은 업스트림의 참여 인원만 늘리는 단계가 아니라, 공통 엔진과 연결 규약을 중심으로 서로 다른 제품이 독립적으로 발전할 수 있는 생태계를 완성하는 단계입니다.
- 조판과 저장 방식이 안정되어 외부 기여와 확장 기능이 의지할 기준이 계속 넓어져야 합니다.
- 같은 요구가 여러 사용자와 외부 프로젝트에서 반복되는지 확인해야 합니다.
- 메인테이너와 공동 유지보수자가 검토와 통합을 나누고, 특정 개인에게 일이 몰리지 않아야 합니다.
- 새 확장 기능을 누가 얼마나 오래 유지할지, 호환성 비용을 공동체가 감당할 수 있는지 판단해야 합니다.
- 공동 편집과 원격 사용에는 충돌, 복구, 보안에 대한 명확한 원칙이 먼저 필요합니다.
- 외부 기여자가 시작하고 검증하며 병합까지 이어 갈 절차가 반복 가능하고, 여러 유지보수자가 이를 나누어 운영합니다.
- 플러그인, 확장, 외부 언어용 연결 기능이 지켜야 할 버전과 호환성 원칙을 공개합니다.
- 공동 편집이나 자동화 기능이 정상 동작뿐 아니라 충돌과 실패, 복구 과정까지 검증됩니다.
- 공식 배포 대상으로 지원하는 기능과 유지 책임을 분명히 밝힙니다.
- 실제 외부 사용자와 기여자가 이 생태계를 지속적으로 사용하는 사례를 확인한 뒤 v2.0을 출시합니다.
특정 회사나 운영체제에 얽매이지 않고, 공공기관·학교·기업·개인이 실제 업무에서 믿고 사용할 수 있는 한글 문서 기반을 완성합니다.
- v2.0의 확장과 협업 방식이 실제 사용자와 기여자를 통해 안정적으로 운영되어야 합니다.
- 장애 유무와 관계없이 다양한 사용자의 요구를 직접 확인해야 합니다.
- 공공 문서의 작성, 검토, 제출 과정을 끝까지 시험할 협력 기관과 유지 주체가 필요합니다.
- 공개 표준과 법적 요구사항을 검토할 수 있어야 합니다.
- HWP 기능마다 지원 수준, 한컴오피스와의 차이, 지원하지 않는 범위를 공개 자료로 확인할 수 있습니다.
- 키보드 사용, 화면 읽기 도구, 고대비 화면 등 접근성 검증을 통과합니다.
- 데스크톱, 웹, 모바일 환경에서 합의한 핵심 작업을 같은 수준으로 수행할 수 있습니다.
- 실제 공공·교육 문서를 만들고 편집하고 검토해 제출하는 전 과정을 재현할 수 있습니다.
- 특정 개인이 떠나도 유지·보안·의사결정이 이어지는 공동체가 운영됩니다.
rhwp 생태계는 하나의 저장소가 모든 완제품을 직접 만드는 방식으로 성장하지 않습니다. 이 저장소의 업스트림은 여러 제품이 함께 사용할 공통 엔진과 공식 배포 대상을 책임집니다. 다운스트림은 그 기반을 가져가 특정 운영체제, 조직, 업무와 사용자 경험에 맞는 제품으로 발전시킵니다.
이 경계는 다운스트림을 중요하지 않은 작업으로 구분하려는 것이 아닙니다. 공통 기반은 업스트림에서 함께 다듬고, 제품별 선택과 운영 책임은 각 다운스트림이 맡아야 양쪽이 빠르게 발전하면서도 한 저장소에 서로 다른 배포 정책과 유지 부담이 뒤섞이지 않습니다.
| 구분 | 업스트림이 책임지는 것 |
|---|---|
| 공통 문서 엔진 | HWP·HWPX·HWP3·HML 파싱, 내부 문서 구조, 조판, 편집, 저장과 여러 출력 방식 |
| 공통 Web/WASM 기반 | 브라우저와 임베드 환경에서 재사용하는 WebAssembly API, 웹 편집·렌더링 기반 |
| 공식 사용자 배포 대상 | Chrome·Edge·Firefox 확장 프로그램, VS Code 확장 프로그램, npm 패키지 |
| 공식 CLI 배포 | GitHub Release의 네이티브 CLI 아카이브와 체크섬 |
| 서비스 연계 표면 | 자동화와 백엔드 서비스가 사용할 CLI의 기계 판독 출력, MCP 서버와 공개 API 계약 |
| 공통 품질과 운영 | 호환성 원칙, 재현용 샘플, 회귀·시각 검증, 보안 수정, 문서와 공식 릴리스 |
CLI와 MCP는 특정 백엔드 서비스를 업스트림 안에 모두 구현하기 위한 기능이 아닙니다. 서로 다른 서비스가 rhwp를 안정적으로 호출할 수 있는 공통 연결 규약이며, 서비스별 인증·데이터 흐름·운영 정책은 각 다운스트림이 맡습니다.
다음과 같이 특정 제품이나 조직의 요구를 완성하는 작업은 별도 프로젝트에서 rhwp를 사용하거나 파생해 구현하는 것을 기본으로 합니다.
- Windows·Linux 데스크톱 앱과 macOS 전용 앱
- iOS·Android용 네이티브 앱
- 사내 HWP·HWPX 뷰어와 조직별 문서 업무 시스템
- Google Docs 등 특정 외부 서비스에 결합한 앱과 확장 기능
- 조직별 로그인, 권한, 저장소, 결재, 과금과 배포 정책
- 특정 고객이나 서비스에만 필요한 백엔드 연계와 사용자 화면
이러한 다운스트림들은 이미 여러 형태로 파생되어 성장하고 있습니다. 각 프로젝트는 제품 설계, 배포 채널, 사용자 지원, 보안과 데이터 처리, 운영체제별 패키징을 독립적으로 책임합니다. 다운스트림에서 사용된다는 사실만으로 그 제품이 rhwp의 공식 배포 대상이나 공식 지원 범위가 되는 것은 아닙니다.
| 변경하려는 것 | 권장 위치 |
|---|---|
| 여러 환경에서 함께 발생하는 파싱·조판·편집·저장 결함 | rhwp 업스트림 |
| 여러 다운스트림이 재사용할 공용 API, CLI·MCP 기능과 호환성 개선 | rhwp 업스트림 |
| 현재 공식 배포 대상의 공통 기능, 접근성, 보안과 배포 개선 | rhwp 업스트림 |
| GitHub Release 네이티브 CLI 아카이브와 체크섬 개선 | rhwp 업스트림 |
| 운영체제별 설치 패키지·설치 스크립트·컨테이너 이미지·설치용 GitHub Action | 우선 다운스트림에서 검증한 뒤 공식 편입 여부를 별도 논의 |
| 특정 운영체제용 완제품의 앱 셸, 제품 설치 프로그램, 자동 업데이트와 파일 연결 | 다운스트림 |
| 사내 정책, 특정 서비스 인증, 전용 화면과 업무 절차 | 다운스트림 |
| 새로운 플랫폼이나 배포 채널의 완제품 | 우선 다운스트림에서 검증한 뒤 공식 편입 여부를 별도 논의 |
한 변경에 두 범위가 함께 있다면 제품 코드는 다운스트림에 두고, rhwp에 필요한 범용 결함 수정이나 확장점만 재현 가능한 작은 이슈와 PR로 분리합니다. 새 공식 배포 대상을 제안할 때는 코드만 제출하지 않고 유지 담당자, 배포 권한, 보안 대응, CI와 장기 지원 책임을 먼저 합의해야 합니다.
버전은 프로젝트가 도달해야 할 큰 단계입니다. 아래 일곱 분야는 특정 버전에서 끝나는 일이 아니라, 프로젝트가 이어지는 동안 함께 다듬어야 합니다.
| 분야 | 계속 답해야 하는 질문 | 더 알아보기 |
|---|---|---|
| 문서 형식과 내부 구조 | 서로 다른 HWP 계열 문서의 의미를 잃지 않고 같은 구조로 다룰 수 있는가 | 파서 구조, HWP/HWPX 내부 구조 차이 |
| 조판과 화면 재현 | 쪽, 표, 글자, 그림이 한컴오피스와 설명 가능한 차이 안에서 배치되는가 | 렌더링 엔진 설계, 시각 검증 원칙 |
| 편집과 저장 | 편집한 문서가 내용과 서식을 잃지 않고 다시 열리는가 | 문서 저장 기술 가이드, 편집 취소·다시 실행 구조 |
| 제품과 사용 환경 | 명령줄, 브라우저, 편집기와 확장이 같은 엔진을 믿고 사용할 수 있는가 | 이 문서의 업스트림과 다운스트림 경계, 배포 가이드 |
| AI 활용과 자동화 | AI가 문서를 안전하게 읽고 쓰며 그 결과를 검증할 수 있는가 | AI 활용 세부 로드맵, 도구 추가 절차 |
| 기여와 운영 | 새로운 기여가 프로젝트 방향과 품질, 유지 책임을 지킬 수 있는가 | 기여 안내, PR 검토 절차 |
| 접근성과 공공 활용 | 누구나 실제 업무에서 사용할 수 있고 공동체가 오래 유지할 수 있는가 | 이 문서의 v3.0 목표. 구체적인 기준은 사용자 근거를 확보한 뒤 정합니다. |
초기 로드맵은 “AI 조판 파이프라인”이라는 방향을 제시했지만, 어떤 도구와 검증이 필요한지까지 설명하지는 않았습니다. kevin9327 기여자는 이 부분을 단계별로 다시 해석하고 구체화했습니다.
- #2659: 명령줄 오류 처리부터 JSON 출력, 편집, 배포와 MCP 연결까지 이어지는 첫 제안
- #3608: AI가 사용할 수 있는 기능의 범위와 세부 목표
- #3880: 기능, 신뢰성, 사용 가능성, 표준화 사이의 선후 관계
- #3907: R1~R100 전체 지도와 근거 수준
- 저장소의 세부 문서: 각 항목의 현재 상태, 시작 조건과 완료 기준
이 문서들은 위의 “AI 활용과 자동화” 분야를 자세히 설명합니다. R과 M 번호는 rhwp의 제품 버전이나 출시 순서가 아닙니다. 세부 로드맵에 항목이 있다는 이유만으로 작업이 시작되는 것도 아닙니다. 현재 제품 목표와 사용자 요구, 검증 근거를 확인한 뒤 개별 작업으로 진행합니다.
| 표시 | 뜻 |
|---|---|
| 완료 | 출시되거나 병합된 결과가 현재도 유효하고 회귀 검증이 있다 |
| 구현 확인 | 기능이나 측정 결과가 실제로 있지만 버전 전체가 끝난 것은 아니다 |
| 설계됨 | 합의된 설계 문서가 있지만 구현 완료는 아니다 |
| 이슈에서 검토 중 | GitHub 이슈에서 범위와 다음 행동을 논의하고 있다 |
| 장기 구상 | 방향은 있지만 시작에 필요한 사용자 요구와 근거가 아직 부족하다 |
| 알고 싶은 것 | 확인할 곳 |
|---|---|
| 프로젝트가 어느 단계로 가는가 | 이 ROADMAP.md |
| v1.0.0에서 지금 무엇을 처리하는가 | GitHub v1.0.0 목표와 개별 이슈 |
| 새 기능을 rhwp에 기여할지 별도 제품으로 만들지 | 이 문서의 업스트림과 다운스트림 경계와 CONTRIBUTING |
| 기능이 실제로 어떻게 동작하는가 | 기술 문서 지도가 안내하는 현재 기준 문서와 코드 |
| 기여와 병합은 어떤 절차를 따르는가 | CONTRIBUTING과 프로젝트 작업 절차 |
| 어떤 기능이 출시되었는가 | CHANGELOG과 GitHub Releases |
- 버전 번호는 각 목표의 성숙도와 완료 기준을 나타내며 고정된 출시 날짜나 작업의 엄격한 시작 순서를 약속하지 않습니다. 필요한 기반은 먼저 시작할 수 있고 여러 버전의 작업은 함께 진행될 수 있습니다.
- 완료라고 표시할 때는 출시, 병합, 측정, 회귀 검증처럼 다른 사람이 확인할 수 있는 근거를 붙입니다.
- 버전의 완료 기준을 바꿀 때는 관련 이슈에서 영향과 다음 버전으로 넘길 항목을 검토합니다.
- 세부 로드맵을 추가할 때는 어느 버전과 분야를 설명하는지, 기존 문서와 무엇이 다른지 먼저 밝힙니다.
- 진행률, 테스트 수, 열린 이슈 수는 여러 문서에 복사하지 않고 그 값을 관리하는 원본으로 연결합니다.
- 이 로드맵은 방향을 설명하는 문서이며, 그 자체가 구현이나 PR 병합을 승인하지는 않습니다.
- 2026-02-10: 초기 개발 로드맵에 제품화, 배포, AI 연동 계획을 기록했습니다.
- 2026-03-28: README에
0.5 → 1.0 → 2.0 → 3.0공개 비전과 이정표를 추가했습니다. - 2026-07~08: kevin9327 기여자가 #2659, #3608, #3880, #3907에서 AI 활용 분야를 근거와 완료 기준 중심으로 구체화했습니다.
- 2026-08-10: #4467에서 프로젝트 로드맵을 README와 분리하고, 그 관리 방식을 제품 전체로 넓혔습니다.
- 2026-08-10: v1.0 이전에 이미 40명이 넘는 외부 기여자와 두 명의 공동 유지보수자가 참여한 현실을 반영해, v1.0 조판과 v2.0 협업이 함께 진행되는 구조로 설명을 바로잡았습니다.