앱 사례와 정착한 편집 관습에서 최소 프로토콜과 하이라키를 도출한다

[developer-1px]

Goal Anchor

• Outcome: 레포에 모인 앱·편집 사례와 오랫동안 정착한 편집 관습에서, 장기간 호환성을 지킬 최소 개념·공통 불변 조건·profile별 차이·책임 하이라키를 도출한 설계 초안을 만든다.
• Done: 사례 → 외부 근거와 반례 → 공통 계약 또는 profile 선택 → 기존 책임과의 연결을 검토할 수 있는 문서로 정리한다. 확정할 수 있는 결론과 아직 동결할 수 없는 질문을 구분하고, 이슈 댓글에는 학습에 필요한 근거·대안 비교·판단 요약·검증 결과·원문 자료를 남긴다.
• Don't: runtime 구현, 공개 API, Stable profile, package 배치를 변경하지 않는다. 새 범용 editor·command bus·profile registry를 도입하지 않는다. 조사 결과를 표준 완성이나 독립 구현 간 상호운용 인증으로 주장하지 않는다.

사용자에게 위임받은 설계 범위

사용자는 편집 문법을 이미 장기간 정착한 사실상 표준으로 보고, 여러 앱과 개념을 모아 그 공통 문법을 도출하려 한다. “디테일 전에 프로토콜과 하이라키를 먼저” 정하고 “30분 정도 알아서 진행”하도록 요청했다. 이어 “과정을 학습할 수 있게 이슈와 댓글”에 공부할 내용을 남기도록 요청했다.

이 작업의 산출물은 설계 초안이다. 기존 논의에서 나온 대상·선택·focus·편집 맥락, 편집 행위, 작업 경계, 결과·복원은 검증할 후보이며 새 API로 확정한 목록이 아니다. 앱별 기능의 합집합을 Core로 옮기는 것으로 해석하지 않는다. 특히 한 앱 안에서 객체·셀·내부 텍스트 편집이 중첩되는 사례를 살펴본다.

기존 자산과 경계

• standards/editing-grammar.md: 공통 규칙 EG-SELECT부터 EG-RESULT, profile별 결정, 적합성 증거와 장기 호환성을 연결하는 기존 Design Draft. 이번 초안도 이 정본 설계 문서를 발전시킨다.
• json-document의 여섯 member, Selection family, Editing session/history, 각 editor와 플랫폼 adapter의 기존 책임을 근거로 삼는다.
• Document·Rich Text·Order·Tree·Sheet·Database·Object·Kanban·Calendar·Annotation·Composer를 편집 사례로 조사한다. 같은 내부 구현 기반의 여러 사례를 독립 생태계 구현 증거로 세지 않는다.
• 외부 근거는 역사적 편집 지침, 현재 제품의 공식 동작 문서, W3C의 관련 명세·구현 지침을 구분해 사용한다. 단축키 일치와 의미 계약 일치를 구별한다.
• 편집 문법의 공통 규칙과 Hands profile을 적합성 테스트로 연결한다 #721 / #722의 적합성 구현과 Document의 동일 블록 내 offset 선택과 범위 확장을 반영한다 #723 / #724의 선택 보존 수정은 기존 자산이다. 이번에는 새 동작을 추가하거나 미구현 사례를 완료했다고 표시하지 않는다.

검토 가능한 완료 증거

1. 편집 사례별 대상·위치·선택·행위·중첩 맥락과 차이를 읽을 수 있다.
2. 공통 후보마다 근거와 반례 또는 성립 조건이 있고, 공유 의미와 profile 정책을 구분한다.
3. 의미의 분류, 계약의 구체화 관계, 실제 구현 의존 관계를 혼동하지 않는 하이라키를 제시한다.
4. 기존 EG 규칙·owner·적합성 증거와 연결하며, 새로 도출한 사항의 실행 검증 여부를 명시한다.
5. 문서 검사와 전체 diff 검토를 마치고 문서 PR로 제공한다. 조사 단계별 학습 댓글에는 확인 가능한 출처와 판단 요약을 남긴다.

[developer-1px]

작업 계획과 읽는 방법

이슈 본문의 Goal Anchor를 기준으로, 사례와 정착한 관습에서 최소 편집 계약·profile 차이·하이라키를 도출한다. 완료 증거는 근거와 반례가 연결된 설계 초안과 검증된 문서 PR이다. runtime·공개 API·Stable profile·package 배치는 그대로 유지한다.

사례 수집
  → 같은 동사에서 다른 대상·결과 찾기
  → 공통 후보를 반례로 검토하기
  → 의미 분류 / 계약 구체화 / 구현 의존 관계 구분하기
  → 기존 EG 규칙과 연결하고 문서 검증하기

댓글마다 확인한 사실, 설계 후보와 판단 요약, 기각한 대안, 검증 결과, 다음 질문을 기록한다. 구현 완료 여부와 새 제안의 검증 여부를 구분한다. 독자가 원문과 코드를 보고 결론을 재검토할 수 있는 학습 기록을 목표로 한다.

학습의 첫 질문은 **같은 Delete가 문자 제거·셀 값 비우기·행 제거로 달라져도 무엇이 같은 편집 문법인가?**이다. 단어 목록의 교집합만 뽑으면 이 차이를 잃고, 기능의 합집합을 만들면 작은 Core를 잃는다. 대상과 결과의 관계를 먼저 살펴본다.

검증은 docs:evaluate, 문서 링크·코드 근거 확인, 전체 diff의 범위·모순 검토로 한다. 현재 문서만 변경하므로 새 runtime 테스트나 브라우저 인증을 완료 증거로 대신하지 않는다. 기존 적합성 테스트는 문서에 연결된 현재 증거를 확인할 때 사용한다.

관찰된 위험은 두 가지다. 여러 내부 editor가 공통 Session을 쓴다는 사실을 독립 구현의 합의로 오해할 수 있고, 현재 구현의 제한을 영구 표준으로 굳힐 수 있다. 각 사례의 증거 수준과 반례를 함께 기록해 판별한다.

[developer-1px]

학습 1 — 오래된 명령을 찾는 것과 오래된 의미를 찾는 것은 다르다

관찰. Apple의 1992년 Macintosh Human Interface Guidelines는 선택 후 작업하는 관습을 설명하면서도 텍스트·배열·그래픽 선택을 구분한다. 특히 표의 필드 전체를 다루는 경우와 필드 안의 텍스트를 편집하는 경우를 구별한다. Windows의 표준 Edit 메뉴에도 Undo/Redo·Cut/Copy/Paste·Delete·Select All이 반복된다.

이 자료들은 사용자의 “이미 정착한 편집 문법을 도출한다”는 출발점을 뒷받침한다. 다만 모든 앱의 정확한 단축키·삭제 방식·Undo 묶음까지 30년간 동일했다는 증거는 아니다.

레포에서 확인한 차이. Sheet의 Cut은 primary rectangle의 값을 null로 비우고 셀 구조를 유지한다. Database의 record.delete는 record를 제거한다. Document의 Copy는 블록 전체이고 Rich Text는 structured slice다. 같은 동사라도 대상과 결과를 빼면 계약을 설명할 수 없다.

설계 판단. 프로토콜의 단위는 명령 이름만이 아니라 작업을 받을 편집 맥락 + 대상/위치 + 의도 → 관찰 가능한 결과여야 한다. 이 표기는 설명을 위한 문법이며 새 command envelope API 제안은 아니다.

기각한 대안. 앱별 메서드를 하나의 전역 union으로 합치는 방식은 Delete/Clear, 구조 선택/내부 텍스트 선택의 차이를 가린다. 각 앱의 기능 목록을 Core에 계속 추가하는 방식도 장기 약속의 범위를 불필요하게 키운다.

읽을 자료와 확인할 질문.

• Apple HIG 1992, 인쇄 쪽수 286–300: PDF 뷰어에서는 310–324쪽(1부터 세는 쪽수)에 해당한다. “선택”이라는 단어 아래 어떤 종류의 대상을 구분하는지 읽어볼 수 있다.
• Microsoft 표준 메뉴: 명령 어휘의 일관성과 그 명령의 대상별 의미는 어디서 갈라지는가? Windows 7 시대 지침이라는 범위를 유지한다.
• Sheet 구현, Database 구현: cut과 record.delete가 실제로 바꾸는 값을 비교하면 차이가 보인다.

다음 검토는 이 공통 후보가 성립하지 않는 편집기를 찾는 것이다. 반례는 설계의 실패를 숨길 이유가 아니라, 영구 계약의 범위를 정할 증거다.

[developer-1px]

학습 2 — 반례로 공통 규칙의 적용 범위를 좁히기

관찰한 반례.

처음 떠올리기 쉬운 일반화	확인한 반례	설계에 남길 구별
선택 작업은 언제나 Undo 대상이 아니다	GIMP는 Scissors Select로 선택을 완성한 작업과 Quick Mask 전환의 Undo를 설명한다	현재 레포의 일시적 Selection과 raster 선택 제작의 History 정책
이동은 Copy → 즉시 제거 → Paste다	Finder는 Clipboard에 있는 파일을 붙여넣는 시점에 원래 위치에서 이동하는 동작을 제공한다	현재 EG-CUT의 즉시 제거 계약과 다른 transfer profile
복사는 저장 값을 그대로 옮기면 된다	Excel은 수식을 복사할 때 상대 참조를 바꾸지만 수식 이동에서는 참조를 유지한다	payload의 보존 의미와 대상 위치에 따른 재해석
모든 편집은 미리 선택된 객체가 필요하다	레포의 annotation.create는 새 annotation을, event.create는 시간 구간을 직접 받는다	Selection에서 얻는 대상, 명시 대상, 삽입 위치

판단. “내용을 바꾸지 않는다”와 “History에 남기지 않는다”는 서로 다른 명제다. 현재 EG-SELECT/EG-HISTORY는 레포의 기존 Selection·Editing 동작을 설명하고 실제 테스트가 있다. 이 계약을 깨지 않고 적용 범위를 명시할 수 있다. GIMP를 같은 profile이라고 선언하거나, 반례를 수용한다며 기존 테스트의 의미를 바꾸지는 않는다.

기각한 대안. 예외를 전부 Host-specific으로 밀어내면 사람이 이미 사용하는 편집 문법을 프로토콜에서 잃는다. 반대로 모든 차이를 즉시 Core의 새 기능으로 수용하면 공통 계약이 기능 목록이 된다. 의미가 다른 경우 profile의 성립 조건으로 설명하고 그 owner에서 검증할 질문을 남기는 편이 맞다.

공부할 자료.

• GIMP Undoing: 무엇이 문서의 내용이고 무엇이 복원할 작업인지 서로 다른 질문임을 보여준다. 이 공식 문서의 모든 세부 동작을 직접 실행 검증한 것은 아니다.
• Apple Mac 단축키 — Finder: Option-Command-V의 Finder 이동 의미를 텍스트 편집의 같은 키 조합과 비교할 수 있다.
• Excel 수식 이동·복사: 값의 동일성과 참조 의미의 보존이 달라지는 작은 사례다.
• Annotation의 명시적 생성 의도: selection.set과 annotation.create의 입력을 비교해 볼 수 있다.

이번 관찰은 새 raster/file editor를 구현하자는 범위 확장이 아니다. 기존 11개 사례만으로 보편성을 주장할 수 없음을 드러내는 외부 반례다.

[developer-1px]

학습 3 — 하이라키에서 ‘종류’, ‘조합’, ‘의존’을 구별하기

관찰. APG Grid는 셀 탐색과 내부 caret 조작을 구분한다. Keynote도 텍스트 상자 자체를 선택하는 상태와 내부 글을 편집하는 상태를 구분한다. 레포에서는 DocumentTextControl이 native range를 투영하고, registerWebVirtualSelectionScope는 전체 텍스트 선택·Copy 영역과 editable target 우선 처리를 맡는다. 부분적인 소유자는 이미 존재한다.

설계 후보.

공통 편집 규칙
  ├─ 대상별 구체화: model · position · selection · 연산 · 교환 · 복원
  └─ 입력별 구체화: key · pointer · IME · focus · 중첩 · lifecycle
              │ 두 축을 조합하고 함께 검증
              v
         Hands profile
              │ 여러 Hand와 외부 서비스를 조합
              v
       Application / Host

이것은 계약이 구체화되는 관계다. Core → Editing → Hands → App처럼 읽는 순서나 package import graph만으로 이 관계를 대신할 수 없다. Sheet가 Rich Text를 상속하는 것도 아니고, 셀 편집을 시작할 때마다 별도 History를 만들어야 한다는 뜻도 아니다.

분리해서 남긴 용어.

• Selection range의 focus: 범위의 한 endpoint.
• 입력 focus: 지금 입력을 받는 곳. Toolbar로 옮겨져도 명령의 편집 대상이 사라지는 것은 아니다.
• Calendar scope: "this" | "this-and-following" | "all": 반복 일정의 변경 범위. 입력을 받을 편집 맥락과 다르다.
• JSONDocument의 주소: 현재 JSON 값 안의 위치. 같은 대상의 identity나 DOM 위치와 같다고 가정하지 않는다.

기각한 대안. 모든 중첩을 범용 Scope 클래스 하나로 선언하면 DOM focus, model subtree, History 귀속을 우연히 묶을 위험이 있다. 이번에는 실제 필요한 진입·수신자·거절·복귀 규칙을 사례로 명시하고 새 runtime 추상화는 만들지 않는다.

검증할 반례. 내부 text editor가 Delete를 거절했을 때 바깥 객체가 삭제된다면, 두 editor 각각의 단위 테스트가 통과해도 조합 계약은 실패한다. 따라서 현재의 원자적 편집 테스트와 별도로 중첩 수신자·실패 전파를 관찰해야 한다. 이번 문서에는 이 사례를 미실행 후보로 표시한다.

읽을 자료.

• APG Grid — 셀 내부 편집: 같은 키를 두 편집기가 동시에 처리할 수 없는 이유를 볼 수 있다.
• Keynote의 텍스트 상자: 객체 선택과 내부 텍스트 편집을 비교할 수 있다.
• W3C Selection API의 Background: 새 절충안을 만들었다가 기존 구현들과 맞지 않아 되돌린 역사를 명세 자체가 설명한다. 현재 문서는 Working Draft다. ‘단순한 설계’와 ‘이미 쓰이는 계약에 맞는 설계’가 다를 수 있다는 사례로 읽으면 좋다.

[developer-1px]

학습 4 — 근거의 강도와 설계의 강도를 맞추기

외부 자료와 내부 구현을 비교한 결과를 다음처럼 구분했다.

판단 대상	근거와 수준	이번 설계의 판단
선택·편집·교환·복원이라는 오래된 어휘와 역할	Apple 1992 지침, Windows 표준 메뉴, 현재 제품 설명. 역사적 지침과 반복된 관습	stable: 공통 의미를 도출할 기반. 모든 세부 동작의 동일성을 뜻하지 않음
객체·셀 전체와 내부 텍스트를 구별하는 조작	Apple의 표/그래픽 설명, APG Grid, Keynote. 제품 관습과 구현 지침	stable: 중첩에서 입력 수신자를 구별할 근거. 범용 Scope API 채택 근거는 아님
정확한 History 단위·selection 기록·transfer 시점	GIMP 선택 도구, Finder 이동, 레포의 typing/gesture/local History	contested: 맥락에 따라 서로 다른 관습이 타당함. Profile이 명시해야 할 부분
이 레포의 단일 editing API가 외부 표준이라는 주장	내부 11개 사례와 세 editor의 공통 runner	absent: 같은 profile의 독립 구현 합의에 대한 증거가 아직 없음

초안 리뷰에서 보완한 점. Tree의 실제 코드를 확인하니 Copy와 제거는 descendantClosure로 숨은 후손까지 포함한다. 따라서 “편집은 보이는 선택만 바꾼다”는 규칙은 부적절하다. Selection과 실제 작업 대상·영향 범위를 구별하도록 표를 고쳤다. Calendar의 반복 범위도 같은 구별이 필요하다.

현재 EG 규칙을 바꾸는 대신 적용 범위를 명시했다. 범위 확장의 anchor 규칙은 anchor를 가진 family에 적용하고, 현재 즉시 제거하는 Cut을 Finder 같은 지연 이동의 규칙이라고 주장하지 않는다. 기존 profile의 약속은 유지하며 공통 규칙의 보편성 주장을 좁히는 것이 이번 설계 수정이다.

작게 유지하는 기준. Profile이라는 말로 모든 결정을 자유롭게 남겨 두면 표준이 되지 않는다. 하나의 profile revision 안에서는 대상·작업·결과·실패·History 경계의 답이 고정되어야 한다. 공통 규칙이 답을 정하는 항목과 profile이 답을 채우는 항목을 구별하고, 채운 답을 이전 vector로 계속 검증해야 한다.

검증 현황. docs:evaluate 통과. 설계 문서의 내부 Markdown 링크 28개 대상 존재 확인, code fence 5개 균형 확인. 새 사례는 미실행 후보로 명시했다. Runtime·공개 API·기존 behavior vector는 변경하지 않았다.

다음 판정. 기존 적합성 증거를 재실행하고 최종 diff를 이슈의 완료 조건과 대조한다. 문서의 분량 증가 비용을 줄이기 위해 중복된 책임 흐름 그림은 하나로 합쳤다.

[developer-1px]

학습 5 — 초안을 검증 가능한 약속으로 바꾸는 마지막 검토

원문을 다시 대조하니 Apple HIG 1992 인쇄 쪽수 290–291에도 Shift-click 확장의 addition과 fixed-point 방식이 함께 나온다. 그래서 EG-SELECT의 anchor 보존을 “anchor가 있는 모든 범위 선택”에 적용한다고 읽힐 문장을 현재의 고정 anchor 전이로 좁혔다. 기존 EG 문장과 구현을 바꾼 것은 아니다. 학습 1의 PDF 뷰어 쪽수 안내도 1부터 세는 쪽수 기준으로 바로잡았다.

이 사례가 보여주는 검토 방법은 다음과 같다.

1. 공통 후보를 한 문장으로 쓴다.
2. 오래된 지침과 현재 구현에서 반례를 찾는다.
3. 타당한 반례가 있으면 성립 조건을 명시하거나 profile이 결정할 부분으로 분리한다.
4. 기존 profile의 소비자 결과가 유지되는지 확인한다.
5. 새 후보는 시작 상태·작업·관찰 결과로 적고, 미검증 항목을 통과 결과에 섞지 않는다.

대안 비교의 결론. 기존 구현 이름만 하나로 합치면 의미의 차이가 사라지고, 모든 차이를 Host 정책으로 남기면 재사용 가능한 약속이 사라진다. 이번 초안은 공통 의미와 profile에서 채울 답을 구분하고, 그 답의 정본 owner를 유지한다. 새 기능이나 범용 scope runtime을 추가하지 않은 이유도 여기에 있다.

검증 결과. 공통 적합성 5 files / 51 tests 통과. 문서 검사·내부 링크·전체 diff 검토 통과. 기존 EG 규칙 9개와 owner 표를 보존했고 변경 파일은 standards/editing-grammar.md 하나다. 최종 원문 대조에 따른 설명 보완도 같은 문서 범위에서 처리했다.

PR #726에 검토할 설계가 있다. 현재 단계는 문서 PR이며 merge나 Stable admission을 완료한 상태가 아니다. 중첩된 편집의 진입·거절·복귀, profile 간 교환, 여러 편집 맥락의 History 귀속은 문서의 검증 질문으로 남아 있다.

[developer-1px]

결과와 학습 순서

PR #726에 설계 초안을 정리했다. 최종 commit은 c8570dc7이며 CI Plan·Package·Site가 통과했다. External kit은 이번 변경에 대한 실행 계획에서 skipped다. 문서 검사, 기존 공통 적합성 51개 테스트, 내부 링크 28개와 GitHub 렌더링의 표 10개·코드 블록 5개도 확인했다.

이 순서로 읽으면 설계가 어떻게 도출됐는지 따라갈 수 있다.

1. 오래된 명령과 오래된 의미를 구별하기
2. GIMP·Finder·Excel 반례로 공통 규칙의 범위 좁히기
3. 하이라키의 종류·조합·의존 구별하기
4. 근거의 강도에 맞춰 설계 판단하기
5. 초안을 검증 가능한 약속으로 검토하기

최종 설계 문서는 11개 사례 → 최소 질문 → 중첩과 반례 → 하이라키 → 기존 EG·owner·적합성 → 새 검증 질문 순서로 읽을 수 있다.

본문의 완료 조건은 모두 설계 초안과 검증 결과에 연결했다. Runtime·public API·Stable profile·package 배치 변경은 없고, 기존 EG 규칙 9개와 owner 표를 보존했다. 원래 checkout의 작업 파일은 보존하고 별도 clone의 issue-725-editing-grammar-derivation에서 작업했다.

현재 상태는 pr-open이다. 설계 작업은 마쳤으며 merge와 표준 동결은 별도 단계다. 남은 설계 질문은 중첩 편집의 진입·거절·복귀, profile 간 payload 교환, raster/file 적용 범위, 여러 편집 맥락의 History 귀속이다. 이 질문들을 구현 완료로 표시하거나 후속 구현 이슈로 자동 확대하지 않았다.

[developer-1px]

추가 조사 — 조합 경계를 30분 더 살펴보기

사용자가 “30분만 더 조사 위주로 진행해 지금처럼 이슈에다가 읽을 거리 주는 식으로” 요청했다. 앞의 설계 초안과 학습 기록을 이어서, 다음 질문을 조사한다.

1. 내부 텍스트와 바깥 셀·객체가 함께 있을 때, 어떤 편집기가 입력을 받고 언제 위임·거절·복귀하는가?
2. 편집 맥락이 바뀌면 Undo의 대상과 작업 단위는 어떻게 정해지는가?
3. 서로 다른 편집기 사이에서 Copy/Paste가 보존하는 의미와 손실·실패는 어떻게 약속되는가?

대상은 인간의 편집 동작과 이를 연결하는 protocol이다. 1차 비교 대상은 플랫폼의 공식 command routing·편집·History·Clipboard 계약과 실제 제품 지침이다. 독립 editor framework의 공개 구현은 이 계약을 실현하는 형태를 비교할 때 사용한다. 라이브러리의 최신 API 모양을 오래된 보편 문법의 증거로 쓰지 않는다.

표준(standard), 권장 지침(bp), 반복된 관습(de-facto), 아직 수렴하지 않은 제안(frontier)을 구분한다. 댓글에는 읽은 원문이 무엇을 입증하는지와 한계, 작은 비교 사례, 레포와의 연결을 남긴다.

이번 회차는 조사와 학습 기록에 집중한다. 기존 PR #726은 설계 초안으로 유지하며 runtime·public API·package 변경과 merge는 진행하지 않는다. 발견한 사항을 후속 구현 이슈로 자동 확대하지 않는다.

[developer-1px]

학습 6 — 명령을 보낸 곳, 받을 곳, 실행 가능 여부는 별개의 질문이다

읽은 근거. Cocoa는 명시된 target으로 action을 보내거나, target이 없으면 responder chain에서 수신자를 찾는다. WPF는 command source·target·parameter를 구분하고 CanExecute로 현재 실행 가능 여부를 질의한다. GTK의 action은 이름·enabled 상태·인자 type을 갖고 application/window/widget에 귀속된다. 서로 다른 플랫폼의 공개 계약에서 같은 책임 구별이 반복된다.

Toolbar 버튼 / 메뉴 / 키 입력
          │ 명령을 요청
          v
     수신할 편집 대상 결정
          │ 현재 상태에서 실행 가능한가
          v
     해당 대상의 편집 실행
          │
          v
     성공·거절 결과를 관찰

작은 예제. 문서 A에서 문장을 선택한 뒤 Toolbar의 Copy 버튼을 누른다. 클릭을 받은 곳은 버튼이지만, 복사할 내용은 A가 가진 선택이다. 따라서 “입력 focus 하나가 모든 대상과 상태를 대표한다”는 해석은 부족하다. WPF는 키보드 focus를 잃어도 영역 안의 logical focus를 기억할 수 있는 구조도 설명한다.

레포에 대한 판정. 앞의 초안에서 구별한 Selection·입력 수신자의 방향은 외부 계약에 close하다. 다만 지금의 Scope라는 새 타입 하나로 모두 묶을 근거는 더 약하다. GTK에서 action의 target은 인자 값을 뜻하는 문맥도 있어, 다른 플랫폼의 같은 이름을 그대로 대응시키면 오히려 의미가 틀어진다.

Cocoa의 menu validation은 수신자를 먼저 찾은 뒤 그 대상의 실행 가능 여부로 메뉴를 활성화한다. “메서드가 있다”, “지금 할 수 있다”, “실제로 성공했다”를 같은 상태로 읽지 않게 한다. 이 사실만으로 모든 플랫폼이 동일한 실패 전파 규칙을 제공한다고 단정할 수는 없다.

근거의 수준. 각 자료는 특정 플랫폼의 공식 API 계약 또는 지침이다. 세 플랫폼에서 역할 구별이 반복되는 것은 안정된 설계 관습의 근거지만, 하나의 범용 command API나 wire format의 표준을 입증하지는 않는다.

읽을거리와 관찰 포인트.

• Cocoa Event Architecture — Action Messages: event를 받은 객체와 action의 target이 어떻게 갈라지는지 읽는다. Archive 문서다.
• Cocoa Enabling Menu Items: target 탐색과 validation의 순서를 확인한다.
• WPF Commanding Overview: 같은 Paste 명령을 서로 다른 대상에 연결하는 예제를 본다. 설명한 CommandTarget 동작은 RoutedCommand의 계약이다.
• WPF Focus Overview — Logical Focus: 현재 입력 수신과 영역 안에서 기억하는 focus가 왜 다른지 본다.
• GTK Actions: action의 이름·인자·enabled·scope와 표시용 label/icon을 구별한다.

다음 질문은 수신자를 결정한 뒤의 거절이 다른 편집기로 넘기는 신호와 어떻게 다른가이다. API 모양을 통일하는 것보다 먼저 검증해야 하는 조합 의미다.

[developer-1px]

학습 7 — ‘적용되지 않음’, ‘편집 거절’, ‘이벤트 차단’을 같은 실패로 묶으면 안 된다

명령 후보를 이어서 찾는 동작은 정착한 구현 방식이다. 이미 맡은 편집의 거절을 다른 대상으로 재해석하는 동작과 구별해야 한다. 앞선 초안의 중첩 편집 규칙을 적용할 때 필요한 조건이다.

ProseMirror의 공식 Commands 안내는 적용할 수 없는 명령이 아무 변경 없이 false를 반환하도록 한다. chainCommands는 첫 성공 후보까지 순서대로 시도한다. 기본 Backspace도 선택 삭제 → 뒤쪽 블록 결합 → 앞 노드 선택이라는 후보들을 거친다. 이것은 여러 편집을 모두 수행하는 transaction 묶음이 아니다. 따라서 “Backspace에는 하나의 동작만 있다”, “fallback은 언제나 잘못이다”라는 일반화는 반례를 만난다. ProseMirror Guide — Commands

DOM은 이벤트 전파 중단과 기본 동작 취소를 별개의 flag로 정의한다. defaultPrevented는 취소 flag를 알려주며, 우리 document commit의 성공 여부를 표현하지 않는다. DOM Standard — Event

이를 현재 레포의 계약과 대조하면 세 질문이 드러난다. 아래 표는 새 반환 타입 제안이 아니라 사례를 판별하는 표다.

상황	다음에 확인할 질문	현재 확인 가능한 근거
이 명령 후보가 현재 선택에 적용되지 않음	다른 후보가 같은 맥락에서 적용되는가?	ProseMirror의 명령 연결
이 Web binding이 paste 형식을 지원하지 않음	native 처리 또는 다른 명시적 수신자가 맡는가?	현재 Web 테스트는 편집 callback과 preventDefault를 호출하지 않음
지원하는 paste를 맡았지만 편집이 거절됨	거절 결과와 기존 document 상태가 보존되는가?	현재 Web 테스트는 기본 동작 취소 후 editing.rejected를 확인
이벤트 전파를 중단함	기본 동작도 취소해야 하는가? 편집 결과는 무엇인가?	DOM의 별개 flag이므로 별도 판단 필요

로컬 읽기: clipboard-rejection.test.ts. 이번 라운드에서는 테스트 내용을 읽어 대조했으며 재실행하거나 중첩 브라우저 동작을 재현하지 않았다.

초안의 후보 규칙은 다음처럼 좁혀 읽는 편이 정확하다.

수신자가 편집을 맡고 거절했다면, 별도로 정의한 위임 계약 없이 그 거절을 바깥 대상의 다른 편집 허가로 해석하지 않는다.

이것은 모든 플랫폼에서 증명된 보편 규칙이 아니라 현재 설계의 보존 후보다. 특히 ProseMirror의 false는 ‘후보가 적용되지 않는다’는 의미이며 우리 EditingResult.ok: false와 자동으로 대응하지 않는다. 두 boolean을 기계적으로 연결하면 위 표의 구별을 잃는다.

근거 강도: DOM 이벤트 구별은 해당 플랫폼의 standard; ProseMirror 연결은 해당 구현의 공개 계약이며 인접 비교 대상이다. 중첩 편집의 거절 이후 경로에 대한 생태계 전체 합의는 아직 absent로 둔다. 이 레포가 선택할 안전한 계약과 외부에서 이미 정착한 규칙을 구별한다.

읽으면서 확인할 질문: 셀 내부의 텍스트 삭제가 거절되었을 때, 셀 전체를 지우는 것은 같은 명령의 다음 후보인가, 수신 대상이 달라지는 새 명령인가? 코드 설계 전에 이 경계가 사례로 답해져야 한다.

[developer-1px]

학습 8 — Undo의 공통 문법은 오래됐지만, History의 범위는 하나로 굳지 않았다

후속 정리: 사용자와 확인한 방향은 편집 Undo 시 선택을 함께 복원하는 기본 Profile을 제공한다는 것이다. 아래의 다양한 History 정책은 그 기본값의 적용 범위와 변형을 설명한다. 사용자 전제 정리, 기본값을 뒷받침하는 구현 근거

Undo를 제공한다는 약속과 ‘어떤 기록을 한 번 되돌리는가’라는 약속을 분리해야 한다. 입력 focus, 기록의 소유자, 기록에 포함할 변경, 한 step의 묶음은 서로 다른 결정이다.

읽은 근거	실제로 정하는 것	일반화하면 안 되는 것
AppKit Undo Architecture	responder chain에서 manager를 찾고 문서 manager나 view 전용 manager를 사용할 수 있음. 기본 field/cell 편집 기록에는 focus 수명과 연결된 동작도 있음	모든 view마다 반드시 별도 History를 생성한다는 규칙
Qt QUndoGroup	여러 stack 가운데 active stack을 명시적으로 선택하고 공통 Undo/Redo action을 연결	focus 이동 자체가 기록 소유권·수명을 자동 결정한다는 규칙
Yjs UndoManager	shared type 범위, trackedOrigins, 시간 기반 묶음과 stopCapturing()을 구별	Undo가 항상 전역 문서의 직전 snapshot 전체를 복원한다는 규칙

AppKit 문서는 2011년의 공식 아카이브다. 당시의 설계 근거로 읽으며 현재 모든 macOS 앱의 동작이라고 주장하지 않는다. Qt는 독립적인 현재 native framework 계약이다. Yjs는 협업 구현이라는 인접 비교 대상이며 이것만으로 협업 Undo의 유일한 표준을 입증하지 않는다.

Undo 요청
   |
   +-- 어느 History를 실행하는가?       수신·routing
   +-- 어떤 변경을 기록해 두었는가?     문서 범위·origin·정책
   +-- 무엇을 한 번에 되돌리는가?       grouping
   +-- 내용 외 무엇을 복원하는가?       selection·view 상태
   +-- 외부 변경이 끼어들면 어떻게 하는가? 복원 알고리즘·유효성

기존 초안에서 한 가지 설명은 더 좁혀야 한다. ‘일시적 selection이므로 Undo 대상이 아니다’도 보편 명제가 아니다. AppKit은 document 상태에 포함하지 않는 view selection도 사용자 편의를 위해 Undo에 등록할 수 있다고 설명한다. 이는 앞서 본 GIMP의 mask 제작보다 직접적인 반례다. ‘저장되는 상태인가?’와 ‘Undo로 되돌릴 상태인가?’는 별개 축이다. 같은 AppKit 문서의 Undo and the Control and View Layers

현재 레포와의 거리:

• EditingHistory를 교체 가능한 owner로 둔 방향은 위 사례들과 close하다. history.ts
• 현재 selection-only는 문서 History entry를 만들지 않으며, 외부 document 변경은 local inverse History를 비운다. 이는 명시된 구현 정책이다. 모든 편집기의 역사적 공통 규칙으로 승격할 근거는 없다. session-history.test.ts
• 같은 문서를 보는 A/B view가 어떤 manager를 공유하고 Undo 후 어느 view의 selection을 복원할지는 아직 unknown이다. 현재 owner 연결 API가 있다는 사실과 그 조합의 동작이 검증됐다는 사실은 다르다.

판정: ‘명령과 History 수신처를 구별한다’는 설계 경향은 stable; 모든 문서·view·selection에 적용할 단일 History 범위는 absent다. 기존 EG-SELECT·EG-HISTORY는 현재 profile의 계약으로 보존하되, 다른 profile의 적합성을 판정할 때 이 정책을 보편 전제로 쓰지 않아야 한다.

읽을 때의 사고 실험: 같은 문서에서 A는 문장을 쓰고 B는 객체를 옮겼다. A로 돌아와 Undo하면 ‘B의 마지막 변경’, ‘A의 마지막 변경’, ‘A의 현재 입력 draft’ 중 무엇을 되돌리는가? 정답을 먼저 하나 고르는 대신 각 동작에 필요한 History 귀속 계약을 적어 보면 하이라키가 드러난다.

[developer-1px]

학습 9 — Copy/Paste의 공통점은 ‘하나의 만능 payload’보다 ‘표현을 사이에 둔 교환’에 있다

서로 다른 편집기가 각자의 document model을 유지하면서도 내용을 교환한다. 이 경계가 오래된 플랫폼 자료에서 반복된다.

Windows는 같은 내용을 여러 clipboard format으로 제공하고 수신자가 이해하는 표현을 선택하는 방식을 설명한다. Apple의 pasteboard 아카이브도 하나의 item을 RTFD·RTF·plain text처럼 여러 표현으로 제공해 서로 다른 앱의 능력을 연결한다. Qt의 QMimeData.formats() 역시 표현과 우선순위를 노출한다. API 모양은 다르지만 교환 내용과 표현을 구별하는 방향은 stable로 볼 근거가 있다. Windows Clipboard Formats, Apple Pasteboard, Qt QMimeData

원본 편집기의 대상
        |
       Copy
        |
  교환 가능한 표현들
  +-- 원본 구조 표현
  +-- HTML 등 교환 표현
  +-- plain text
        |
  수신 가능한 표현 선택
        |
  대상 model·schema·위치에 맞춰 해석
        |
      Paste 편집

위 트리는 설명용이다. 모든 editor에 HTML이나 특정 JSON schema를 강제하는 제안이 아니다. 여러 item과 한 item의 여러 표현도 같은 개념이 아니다.

여기에 중요한 반례가 있다. 가장 풍부한 표현을 읽었다고 사용자가 원하는 Paste 의미까지 결정되는 것은 아니다. Word는 같은 문서/다른 문서/다른 앱에서의 붙여넣기 설정을 구별하고, 원본 서식 유지·서식 병합·텍스트 전용을 제공한다. 즉, 표현을 읽을 수 있는 능력과 어떤 변환을 원하는지라는 정책은 다르다. Word — Control the formatting when you paste text

현재 레포에서는 이 구별의 일부가 이미 보인다.

단계	확인한 현재 동작	남은 계약 질문
표현 만들기	Rich Text가 구조·HTML·plain 표현을 순서대로 제공	각 표현이 무엇을 보존하고 무엇을 잃는가?
읽을 표현 찾기	Web binding은 우선순위에 따라 첫 유효한 decode를 선택. 잘못된 JSON 뒤 HTML 선택 테스트가 있음	‘해석 불가’와 ‘사용자에게 중요한 의미가 손실됨’을 어떻게 구별하는가?
실제 붙여넣기	payload를 선택한 뒤 editor의 paste를 실행. 그 편집이 거절되면 다른 표현을 자동 재시도하지 않음	거절 이후 더 단순한 표현으로 바꾸는 경우는 별도 정책·새 시도인가?
외부 교환	현재 테스트는 정해진 payload/표현 사례를 검증	서로 다른 독립 editor의 실제 교환과 원본 ID·참조·schema 처리까지 검증했는가?

로컬 읽기: Rich Text 표현, Web 표현 선택 테스트, Web binding.

비교 판정: 여러 표현과 editor별 수신 해석을 둔 현재 방향은 close; 하나의 공통 wire schema로 모든 편집 장르를 통일한다는 근거는 absent다. 같은 format 이름만으로 내용 의미까지 호환된다고 인증해서도 안 된다.

읽을 때의 질문: 굵은 글씨가 있는 표를 문자열 입력창에 붙여넣으면 무엇을 보존해야 하는가? ‘문자열만 받는 대상’과 ‘표를 지원하지만 지금은 읽기 전용인 대상’에서 fallback을 같은 이유로 실행해도 되는가? 이 구별이 학습 7의 ‘후보 탐색과 거절’에 연결된다.

[developer-1px]

학습 10 — 사용자 전제 보정: 유연한 기반 위에, 정착한 default를 Profile의 계약으로 제공한다

조사 중 사용자가 의도를 더 명확히 했다. Core는 여러 정책을 수용할 수 있게 유지하고, 사람들이 이미 익숙한 편집 동작은 기본 Profile로 제공한다. Cmd+Z → Undo, 편집 Undo 시 선택 영역의 복원이 대표 예다.

이 전제를 이후 판단의 기준으로 삼는다. 학습 7–9의 반례는 기본값을 포기할 이유가 아니라, 기본 Profile의 적용 범위와 변형을 가르는 근거다. 예외가 존재한다는 사실만으로 널리 정착한 기본 동작을 계속 미결정 상태에 두지 않는다.

프로토콜 기반
  |  여러 model·입력·History 정책을 수용하는 계약
  |
  +-- 기본 Profile
  |     정착한 편집 관습을 구체적인 기본 동작으로 약속
  |     입력 → 의도 → 결과·선택·History까지 검증
  |
  +-- 명시적인 다른 Profile 또는 허용된 선택
        다른 정책이 필요한 맥락의 차이를 설명

이는 설명상의 구분이며 새 package나 중앙 profile registry를 만들자는 제안이 아니다. 기존의 대상별 계약과 입력별 계약을 조합해 Hands profile로 검증하는 구조 안에서 구체화할 수 있다.

특히 Undo에 대해 두 가지를 분리한다.

질문	이번에 확인한 사용자 의도와 기본 계약 후보
편집을 Undo하면 무엇이 돌아오는가?	문서 내용과 편집 전 선택을 함께 복원하는 것을 기본으로 제공
선택만 이동해도 새 Undo step을 만드는가?	별도의 History 정책. 앞의 선택 복원 약속과 독립적으로 정할 수 있음
Cmd+Z는 무엇을 뜻하는가?	macOS 기본 입력 계약에서 Undo. 어떤 History가 수신하는지는 조합된 편집 맥락의 계약

‘선택 영역도 Undo에 포함’은 우선 편집과 함께 선택을 복원한다는 뜻으로 이해했다. 선택 이동을 독립 Undo step으로 기록하자는 요구로 확대 해석하지 않는다.

기본 Profile을 쓰는 사용자에게는 이것이 실제로 믿을 수 있는 약속이어야 한다. 따라서 이후 기본 동작을 바꿀 때도 호환성을 검토해야 한다. 확장이 가능하다는 이유로 같은 Profile 이름 아래 관찰 가능한 동작을 임의로 바꾸면 안정화 목표를 잃는다. 다만 어느 옵션을 Profile 안에서 허용하고 어느 차이를 다른 Profile로 식별할지는 구체적 사례로 정할 사항이다.

이후 조사 질문도 ‘모든 앱이 반드시 똑같은가?’에 머무르지 않고, **‘어떤 동작을 기본으로 제공할 근거가 충분하며, 어떤 차이를 명시해야 사용자의 예상이 보존되는가?’**로 좁힌다.

이번 댓글은 사용자의 설계 전제를 기록한 것이다. 런타임·공개 API·기존 PR은 변경하지 않았다.