wordcraft 딥다이브
— 글자 하나가 문서와 화면과 PDF가 되기까지

1프로젝트 한줄 요약

WordCraft는 Word 문서를 읽고 편집하고 여러 형식으로 저장하는 기능을 Rust 크레이트로 나누고, 그 위에 여러 사용 창구를 올린 워드프로세서입니다. DOCX 입출력뿐 아니라 문단·표·머리글·각주·글꼴·줄바꿈·페이지 나누기를 직접 다룹니다. GitHub 설명의 “clean-room reimplementation”은 프로젝트가 공개 규격과 독립 구현을 지향한다는 선언입니다. 완전한 Word 호환을 보증하는 문구로 읽어서는 안 됩니다.

가장 먼저 기억할 문장은 이것입니다. 문서와 명령을 UI와 분리했기 때문에, 같은 편집 기능을 사람과 자동화 도구가 함께 사용할 수 있습니다.

예를 들어 format.bold는 버튼 이름만이 아닙니다. crates/engine/src/cmd/format.rs::specs()에 등록된 명령 ID이며, 단축키 Mod+B와 매개변수 설명도 함께 가집니다. UI와 자동화가 같은 기능을 부르는 연결 고리를 이 ID에서 찾을 수 있습니다.

2왜 주목받는가

2-1. 빠른 관심 증가와 독립적인 구현 목표

TrendShift Monthly #22 선정 프로젝트입니다. 2026-10-07에 생성되어 2026-10-23 GitHub 기준 스타 15,592개, 포크 4,228개를 기록했습니다. 짧은 기간에 관심을 모은 것은 확인 가능한 사실이지만, 스타가 증가한 정확한 원인을 이 수치만으로 증명할 수는 없습니다.

주목할 요인으로는 익숙한 대형 제품을 Rust로 다시 구현하는 목표, Linux·BSD·웹까지 아우르는 진입점, 그리고 CLI·MCP 자동화가 있습니다. 이는 README의 목표와 소스 구성을 근거로 한 해석입니다. 성능·호환성·인기도 사이의 인과관계를 측정한 결과는 아닙니다.

2-2. 경쟁 제품과는 무엇을 비교해야 할까

이 비교는 제품 순위표가 아닙니다. 초보 개발자에게 중요한 장점은 화면에서 보이는 기능과 파일 형식 내부 구현을 한 저장소에서 연결해 볼 수 있다는 점입니다. 다른 제품보다 빠르거나 DOCX를 더 정확하게 처리한다는 비교 실험은 제시하지 않습니다.

2-3. “97.1%”를 읽는 올바른 방법

docs/parity-checklist.md에는 카탈로그 기능 513개 중 498개에 명령이 있다(97.1%)고 적혀 있습니다. 반면 README의 카탈로그 수치는 약 97%, 실무 준비도는 약 60%라는 자체 추정입니다. 명령의 존재, 기능의 깊이, 실제 문서 보존은 서로 다른 지표입니다.

기능 목록에 명령이 있다는 사실은, 복잡한 Word 문서가 손실 없이 왕복 저장된다는 뜻이 아닙니다. 표를 넣는 명령이 있어도 셀 병합·페이지 분할·스타일 상속·다른 프로그램과의 교환까지 확인해야 합니다.

2-4. AI가 들어 있는 편집기인가

MCP 서버가 있다는 것과 언어 모델이 내장됐다는 것은 다릅니다. crates/mcp/src/lib.rs는 외부 클라이언트의 요청을 편집 세션에 연결합니다. 프로젝트의 문서도 외부 에이전트 제어와 앱 안의 어시스턴트를 구분합니다. 이 연결 구조를 이해하면 일반 프로그램에 자동화 인터페이스를 붙이는 방법을 배울 수 있습니다.

3기술 스택 전체 지도

이 저장소의 “백엔드”는 주로 프로세스 안에서 움직이는 문서 엔진을 뜻합니다. 루트에는 package.json, pyproject.toml, go.mod, Dockerfile이 없습니다. 빌드의 중심은 Cargo.toml과 Cargo.lock입니다.

3-1. Rust 작업 공간과 버전 읽기

# Cargo.toml — 실제 설정 일부
[workspace]
resolver = "3"
members = ["crates/*", "apps/*", "xtask"]

[workspace.package]
version = "0.10.0"
edition = "2024"
license = "MIT OR Apache-2.0"
rust-version = "1.95"

3-2. 편집 코어 · 파일 입출력

위 선언은 루트 Cargo.toml, 잠금 버전은 Cargo.lock 기준입니다. 잠금 파일에는 간접 의존성이 요구하는 다른 버전도 함께 있을 수 있습니다. 예를 들어 thiserror 1.x도 있지만, 작업 공간의 직접 선언은 2.x입니다.

3-3. 텍스트 · 조판 · 출력

craft-pdf와 [patch.crates-io]의 krilla는 storytold/craft-libs의 리비전 c3487320b2d1de657b860b3c8abb44e1f2b32bd8을 가리킵니다. 따라서 버전 번호만 보고 일반 배포판과 완전히 같다고 가정하면 안 됩니다.

3-4. 프론트엔드 · 플랫폼 접점

웹 의존성은 apps/wordcraft-web/Cargo.toml에 있습니다. apps/wordcraft-web/src/web.rs::start()는 Canvas를 찾아 eframe::WebRunner를 시작합니다. React 컴포넌트를 공유하는 방식이 아니라, Rust UI와 엔진을 함께 재사용하는 방식입니다.

3-5. 인프라 · 빌드 · 품질 관문

CI는 wasm32-unknown-unknown 타깃과 clippy·rustfmt를 설치하고 cargo xtask ci를 호출합니다. 추가 글꼴 저장소 craft-fonts도 고정 리비전으로 받아 CRAFT_FONTS_DIR로 전달합니다. “같은 코드”에 더해 “같은 글꼴”도 레이아웃 재현성에 영향을 준다는 예입니다.

웹과 데스크탑의 재사용은 파일 접근과 운영체제 기능을 경계 밖으로 밀어내는 설계에서 시작됩니다. “Rust로 썼다”는 사실만으로 모든 플랫폼에서 같은 동작이 자동 보장되지는 않습니다.

4아키텍처 심화 분석

4-1. 전체 시스템 구조

도식의 화살표는 주요 데이터 흐름입니다. 모든 상자의 직접 의존성을 나열한 그래프는 아닙니다. 엔진은 레이아웃과 출력 기능을 사용하지만, 문서 모델이 UI를 알아야 할 이유는 없습니다. 이 방향을 유지하면 창 없이도 변환하고 검사할 수 있습니다.

4-2. 패턴 ① 명령 등록부: 기능을 한곳에서 설명하기

crates/engine/src/lib.rs의 CommandSpec은 기능의 ID·이름·위치·단축키·매개변수 설명과 실행 함수를 묶습니다. Registry::new()는 명령 목록과 ID 조회용 HashMap을 만듭니다. crates/engine/src/cmd/mod.rs::registry()가 영역별 specs() 결과를 합칩니다.

// crates/engine/src/lib.rs — CommandSpec의 필드 일부
pub id: &'static str,
pub params: &'static str,
pub mutates: bool,
pub enabled: fn(&Session) -> Option<&'static str>,
pub run: fn(&mut Session, &Value) -> CmdResult,

enabled는 실행 불가 이유가 있으면 Some(reason)을 돌려줍니다. mutates는 문서를 바꾸는 명령인지 표시합니다. CommandSpec::new()는 기본적으로 변경 명령을 만들며, .pure()는 그 표시를 끕니다. 이 메타데이터는 실행 취소와 보호 검사에 사용되므로 정확해야 합니다.

1. crates/engine/src/cmd/format.rs::specs()에서 format.bold를 찾습니다.
2. 단축키 Mod+B, 매개변수 {"value"?: bool}, 실제 처리 함수 연결을 봅니다.
3. Session::run()이 ID를 조회하고 enabled를 검사하는 부분으로 이동합니다.
4. crates/mcp/src/lib.rs::Headless::answer()의 engine.execute 분기도 같은 함수를 호출하는지 확인합니다.

{"value"?: bool}은 사람이 읽는 매개변수 설명 문법입니다. 그 자체가 유효한 JSON 요청은 아닙니다. 실제 호출은 {"value": true}처럼 씁니다. 또한 UI는 대화상자를 먼저 띄울 수 있습니다. WordApp::run()의 화면 처리를 거쳐 엔진으로 들어가는 흐름과, 곧바로 Session::run()을 부르는 흐름을 구분해야 합니다.

4-3. 패턴 ② 스냅샷과 쓰기 시 복사: 실행 취소 비용 줄이기

crates/doc/src/lib.rs의 문서 본문은 다음 타입으로 표현됩니다.

// 실제 문서 블록 타입
pub enum Block {
    Para(Paragraph),
    Table(Table),
}

pub type Blocks = Vec<Arc<Block>>;

Arc는 여러 곳이 같은 값을 참조하도록 돕습니다. 문서를 복제하면 블록을 가리키는 참조를 공유하고, 수정할 때 Document::para_mut() 등에서 Arc::make_mut를 통해 공유 중인 블록을 필요한 만큼 복제합니다. 이것이 쓰기 시 복사입니다.

따라서 “문서 복제는 무료”라고 말하면 부정확합니다. 블록 안의 내용은 공유할 수 있어도 바깥 벡터와 일부 메타데이터의 복제 비용은 남습니다. 이 설계의 이점은 매번 모든 문단과 큰 그림 바이트까지 통째로 복사하는 일을 줄인다는 데 있습니다.

crates/engine/src/session.rs의 Undo는 문서뿐 아니라 선택 영역·다음 입력에 적용할 서식도 보관합니다. Session::undo()는 저장된 상태를 현재 상태와 교체하고, 현재 상태를 다시 실행 스택에 넣습니다. 같은 파일의 MAX_UNDO는 500입니다.

Session::run()은 변경 명령을 실행하기 전 문서·선택·undo/redo 스택 등을 보관합니다. 처리 함수는 catch_unwind 안에서 호출되며, 일반 오류나 잡힌 panic으로 실패하면 보관한 편집 상태를 복구하는 분기로 갑니다. 문서 보호의 사후 검사에서 거부되는 경우도 고려합니다.

4-4. 패턴 ③ 공통 중간 표현과 캐시: 배치와 출력을 분리하기

crates/layout/src/lib.rs::layout()은 Document를 DocLayout으로 바꿉니다. DocLayout에는 페이지 목록과 문단 위치를 찾는 인덱스가 있습니다. 그다음 crates/layout/src/display.rs::page_display()가 Vec<Draw>를 만듭니다.

Draw는 “이 위치에 글리프·선·도형을 그린다”는 공통 언어입니다. crates/render/src/lib.rs::render_page()는 page_layers()를 이용해 픽셀을 만들고, crates/pdf/src/lib.rs::export() 쪽은 page_display()를 이용해 PDF를 만듭니다. 화면 이미지를 PDF 한 장에 붙이는 방식만으로 처리하지 않습니다.

속도 쪽의 핵심은 LayoutCache입니다. 내부의 Key는 문단 리비전뿐 아니라 폭·목록 라벨·표·각주·그리드·변경 내용 표시 등 배치 조건을 담습니다. Ctx::para_labelled()는 키가 있으면 기존 Arc<ParaLayout>을 재사용하고, 없으면 para::layout_para()를 호출합니다. hits와 misses도 셉니다.

캐시를 잘 만드는 일은 결과를 저장하는 일보다, 결과를 바꾸는 모든 입력을 찾아내는 일에 가깝습니다. 글자가 같아도 문단 폭이나 글꼴이 달라지면 줄바꿈 결과를 다시 계산해야 합니다.

4-5. 패턴 ④ 어댑터와 제한된 입력: 바깥세상을 통제하기

파일 형식은 crates/engine/src/io.rs::open_bytes()와 save_bytes()에서 연결됩니다. 실제 분기는 read_bytes()와 crates/engine/src/io_ext.rs::open()·save() 등을 거칩니다. 확장자만 믿지 않고 내용의 시그니처가 모순되는 경우도 분기하며, 최종적으로 공통 Document를 주고받습니다.

MCP도 같은 생각입니다. crates/mcp/src/backend.rs::Backend는 call()·has_ui()·describe()라는 경계를 정의합니다. Headless는 프로세스 내부의 세션, Remote는 앱의 루프백 제어 포트에 연결됩니다. 도구를 정의하는 쪽이 두 구현의 연결 방식을 매번 알 필요가 없습니다.

파일 어댑터에는 크기 제한도 중요합니다. crates/docx/src/package.rs::Package::open_limited()는 선언된 크기뿐 아니라 실제 압축 해제 크기도 확인합니다.

이 값은 기본 DOCX 패키지 읽기의 예산이며, 앱 전체의 최대 메모리 사용량은 아닙니다. take(room + 1)로 한도보다 한 바이트 더 읽고 초과 여부를 검사하는 방식까지 살펴보세요. 파일을 여는 기능은 정상 문서를 지원하는 일과, 비정상 입력의 비용을 제한하는 일을 함께 해야 합니다.

5디렉토리 구조 해부

작업 공간은 라이브러리 크레이트 16개, 앱 3개, 개발 도구 xtask로 구성됩니다. 루트 설정을 포함한 Cargo.toml은 21개입니다. docs/architecture.md에는 15개 크레이트라고 적혀 있지만, 그 문서는 과거 커밋의 구조를 설명합니다.

5-1. 코드 규모

커밋 3a4770e의 저장소 파일에서 확장자별 줄바꿈을 센 값입니다. 주석·빈 줄·테스트·예제·빌드 도구를 포함하며, 의존성 저장소와 빌드 산출물은 포함하지 않습니다. 별도로 번역 자료 .tsv는 26개, 68,192줄입니다. 번역 행 수를 Rust 코드 줄 수에 더하지 않았습니다.

crates/ui-egui는 Rust 69,007줄, crates/engine은 63,196줄, crates/docx는 34,669줄, crates/layout은 30,877줄입니다. “순수 Rust”라는 중심 기술과 별개로, 제품을 완성하려면 UI·형식 호환·테스트에 많은 코드가 필요하다는 사실을 보여 줍니다.

5-2. 처음 읽을 때의 순서

1. crates/geom/src/lib.rs: 길이 단위를 이해합니다.
2. crates/doc/src/lib.rs: Block, Document, Pos를 봅니다.
3. crates/engine/src/cmd/format.rs: 기능 한 개가 등록되는 모습을 읽습니다.
4. crates/engine/src/session.rs: 그 명령의 실행·실패·취소를 따라갑니다.
5. crates/layout/src/display.rs: 편집 결과가 그리기 목록이 되는 경계를 봅니다.

6학습 포인트 (기술별)

6-1. Rust 타입으로 문서의 규칙 표현하기

Block이 Para와 Table로 나뉘면, 호출자는 “이 블록이 어떤 종류인가”를 match로 분기합니다. Option은 값의 부재를, Result는 실패할 수 있는 작업을 드러냅니다. 잘못된 문서 위치를 받는 Document::para_mut()가 어떤 오류를 돌려주는지부터 읽어 보세요.

6-2. 유니코드와 글꼴: 글자 하나가 픽셀 하나가 아닌 이유

crates/fonts/src/lib.rs::shape_run()은 방향 정보를 포함해 글리프를 배치하는 경로입니다. crates/fonts/src/word.rs::resolve()는 요청한 글꼴·굵기·기울임을 실제 글꼴로 연결합니다. 같은 파일의 대체 목록에는 Calibri에 대응하는 Carlito, Cambria에 대응하는 Caladea 등이 있습니다.

실습 아이디어: 가나다, 결합 악센트가 있는 문자열, 영문과 숫자가 섞인 문장을 고릅니다. UTF-8 바이트 수·유니코드 문자 수·사용자가 인식하는 글자 수가 같은지 생각하고, crates/doc/src/cluster.rs와 crates/layout/src/tests_ligature.rs에서 관련 경계를 찾아보세요.

6-3. 파일 포맷: 읽기 성공과 보존 성공 구별하기

DOCX는 본문 XML 하나만 있는 파일이 아닙니다. 스타일·번호 매기기·그림·관계 정보가 함께 들어 있습니다. crates/docx/src/read/mod.rs::read()에서 모델로 읽고, crates/docx/src/write/mod.rs::write_as()에서 문서 종류(Flavor)에 맞는 패키지로 씁니다.

Document::passthrough는 원래 형식의 일부 데이터를 바이트로 보관합니다. 매크로 프로젝트를 보관하는 경로도 있지만, 보관과 실행 지원은 별개입니다. 실습 아이디어: “보여 주기”, “편집하기”, “모르는 데이터를 유지하기”를 세 열로 나누어 지원 상태를 기록하세요.

6-4. 테스트: 성공 예시보다 지켜야 할 성질 찾기

crates/engine/src/tests.rs::hostile_params_never_panic()는 명령에 엉뚱한 매개변수를 넣습니다. null, 잘못된 타입, 매우 큰 크기와 좌표 등이 포함됩니다. 파일 작업 일부는 제외하고, 명령 실행 뒤 선택 영역 보정과 레이아웃까지 이어 갑니다.

Rust 파일 전체의 #[test] 표기는 3,928회, proptest! { 형태의 속성 테스트 매크로 호출은 16곳입니다(줄 시작의 호출만 집계하며, 네임스페이스 접두사는 포함하고 문자열 안의 예시는 제외). 이는 정적 텍스트 집계이며, 조건부 컴파일·매크로를 반영한 실행 테스트 수나 통과 결과가 아닙니다. README의 약 800개 테스트라는 서술과는 집계 시점·방법을 구별해야 합니다.

6-5. 의존성 규칙도 자동으로 검사하기

xtask/src/layers.rs::TABLE은 크레이트의 계층을 지정합니다. UI_MIN_LAYER = 6과 UI_CRATES 목록은 낮은 계층에 UI 의존성이 스며드는 것을 검사합니다. 같은 계층의 예외는 INTRA_LAYER_ORDER처럼 명시합니다. 오래된 설명 문서보다 실제 검사표를 따라가야 하는 이유이기도 합니다.

아키텍처 규칙을 사람의 기억에만 맡기지 않고, 어기면 검사에서 드러나도록 만드는 방법을 배울 수 있습니다. 자신의 작은 프로젝트에서도 “도메인 모델은 UI를 가져오지 않는다” 같은 한 가지 규칙부터 적용해 볼 수 있습니다.

7하드웨어 / 시스템 요구사항

소스와 배포 문서는 여러 운영체제를 다루지만, 모든 기기에 공통인 공식 최소 RAM·CPU 수치는 제시하지 않습니다. 다음 표는 확인 가능한 조건과 학습용 제안을 나눈 것입니다. 압축된 문서의 파일 크기만으로 실행에 필요한 메모리를 판단할 수는 없습니다.

7-1. Linux에서 Rust 외에 필요한 것

.github/workflows/ci.yml은 pkg-config, libxkbcommon-dev, libwayland-dev, libx11-dev, libxcursor-dev, libxrandr-dev, libxi-dev, libgtk-3-dev, libfontconfig1-dev, libfreetype-dev, mesa-vulkan-drivers를 설치합니다. 이는 Ubuntu CI의 개발 환경 목록이며, 모든 배포판에서 같은 이름의 패키지를 요구한다는 뜻은 아닙니다.

7-2. CPU와 GPU가 각각 하는 일

crates/render/src/lib.rs::default_threads()는 데스크탑에서 사용 가능한 병렬도에 따라 작업 스레드를 1~8개 범위로 고릅니다. 병렬도 조회 실패 시 기본값은 2이고, WASM 분기는 0입니다. 즉, 웹판은 같은 방식의 렌더 작업 스레드를 만들지 않습니다.

페이지의 픽셀화는 vello_cpu, UI의 표시 경로는 egui/wgpu가 담당합니다. CPU 렌더러를 쓴다고 그래픽 환경이 무관한 것은 아닙니다. apps/wordcraft/src/graphics.rs에는 Windows의 그래픽 백엔드와 드라이버 문제를 다루는 코드도 있습니다.

7-3. 글꼴도 시스템 의존성이다

글꼴이 없으면 대체 글꼴을 사용하고, 글자 폭이 달라지면 줄 수와 페이지 수가 바뀔 수 있습니다. 코드의 대체 목록은 호환성을 높이는 전략이지 모든 문서의 동일한 페이지 나누기를 보증하는 장치는 아닙니다. 문서를 비교할 때는 파일뿐 아니라 설치 글꼴과 화면 배율도 기록하세요.

8직접 해볼 수 있는 실습 과제

첫 과제는 소스 읽기만으로 완성할 수 있습니다. 실행 명령이 있는 과제는 해당 버전의 CLI를 준비한 개인 실습 환경을 전제로 합니다. 문서 예시는 학습자가 작성할 실습 입력이며, 실행 성공이나 출력 모양을 미리 보증하는 결과물이 아닙니다.

{
  "commands": [
    {"command": "text.insert", "params": {"text": "Rust로 문서를 만듭니다."}},
    {"command": "select.text", "params": {"text": "Rust"}},
    {"command": "format.bold", "params": {"value": true}}
  ],
  "save": ["lesson.docx", "lesson.pdf"]
}

# CLI가 준비된 실습 환경에서 사용하는 예
wordcraft-cli run --script lesson.json
wordcraft-cli text lesson.docx
wordcraft-cli inspect lesson.docx

완료 기준: 재개방한 DOCX의 본문과 서식 정보를 검사하고, PDF의 모양도 별도로 확인합니다. text 출력에 문장이 보이는 것만으로 굵은 서식까지 보존됐다고 결론 내리지 않습니다. 매개변수의 true를 잘못된 타입으로 바꿨을 때의 처리도 소스에서 추적하세요.

실습의 완료 기준은 명령을 한 번 실행하는 것이 아니라, 바뀐 것과 보존돼야 할 것을 증거로 설명하는 것입니다.

9관련 기술 심화 학습 로드맵

매주 읽은 내용을 작은 표·그림·입력 예시로 남기는 학습 계획입니다. 모든 기능을 구현하는 일정이 아니라, 한 기능의 앞뒤를 설명할 수 있도록 범위를 늘리는 순서입니다. Rust를 처음 배운다면 1주차를 충분히 늘려도 좋습니다.

명령은 crates/engine/src/cmd/에서 등록되고, 실행은 crates/engine/src/session.rs의 Session::run()으로 모입니다. 2주차에 고른 명령 하나를 마지막 주까지 계속 따라가면 학습 범위가 덜 흩어집니다.

9-1. 막혔을 때 되돌아갈 질문

• 타입을 모르겠다: 값이 무엇을 뜻하는지와 “없을 수 있는가·실패할 수 있는가”부터 적습니다.
• 호출 관계가 복잡하다: 명령 ID를 검색한 뒤 등록·실행·출력 세 지점만 먼저 잇습니다.
• 성능 코드를 모르겠다: 캐시를 없앴을 때 계산해야 할 원래 결과를 먼저 설명합니다.
• 호환성 문서가 모순된다: 문서의 날짜·커밋과 구현·회귀 테스트의 근거를 분리합니다.

다른 프로젝트로 가져갈 지식은 Word의 메뉴 개수보다, 상태·계산·출력·플랫폼 경계를 나누는 판단력입니다.

10핵심 키워드 사전

길이 단위는 crates/geom/src/lib.rs의 PT_PER_IN, TWIPS_PER_PT, EMU_PER_PT에서 확인할 수 있습니다. 단위를 한곳에 모으면 DOCX의 수치와 화면의 좌표를 연결할 때 변환 규칙이 흩어지는 일을 줄일 수 있습니다.

11참고 링크

11-1. 프로젝트와 소스 근거

• 공식 저장소 · v0.10.0 릴리스 · TrendShift
• README · alpha 단계와 로드맵 · 미완성 영역
• 작업 공간과 직접 의존성 · 의존성 잠금 버전
• CommandSpec과 Registry · Session과 실행 취소
• 공통 그리기 목록 · 제한된 DOCX 패키지 읽기
• MCP 사용 문서 · 앱 제어 프로토콜 · 기능 카탈로그 체크리스트
• 계층 규칙 검사 · GitHub Actions 품질 관문

11-2. 관련 기술의 공식 학습 자료

• The Rust Programming Language · 소유권·열거형·오류 처리 입문
• Cargo 작업 공간 문서 · 공통 설정과 패키지 관리
• egui 0.36.2 문서 · UI가 매번 상태를 읽고 화면을 만드는 방식
• wasm-bindgen 공식 안내 · Rust와 브라우저의 경계
• ECMA-376 규격 · OOXML 문서와 패키징
• Unicode 양방향 텍스트 알고리즘 · Unicode 텍스트 경계 규칙
• MCP 공식 문서 · 도구·리소스·전송 방식의 개념

11-3. 현재 상태 (2026-10-23 확인)

커밋 날짜와 push 날짜는 같은 개념이 아닙니다. 기준 커밋의 기록 시각은 2026-10-22T22:06:08-06:00으로, UTC로 환산하면 2026-10-23입니다. 날짜만 비교할 때는 시간대도 고려해야 합니다.