지시서 5차: 실제 소스를 더 읽지 않는다

여기는 머지툴을 만드는 자리다. 남의 저장소를 읽을 까닭이 더 남아
있지 않고, 읽는 동안 사고가 날 여지만 있다. 이미 받아 둔 숫자
(XAML 400개, CP949 67개, 4,503개에 12.2초)는 그대로 쓴다.

B-2 와 C-1 을 그에 맞게 다시 썼다. 둘 다 큰 재료가 필요한데,
이제 우리가 만들어 쓴다. 만든 묶음은 몇 번을 돌려도 같은 값이
나와서 재기에는 오히려 낫다. C-1 에는 그 한계도 같이 적었다 -
만든 소스에는 진짜 코드의 지저분함이 없다.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

doc/history/changelog.md

@@ -8,6 +8,7 @@
 
 | 날짜 | 항목 | 커밋 |
 |---|---|---|
+| 2026-09-11 | **지시서 5차 고침** — 실제 소스를 더 읽지 않기로 함. 시험 재료는 우리가 만든다. B-2·C-1 을 그에 맞게 다시 씀 | 아래 |
 | 2026-09-11 | **5차 B-1** — XAML 태그·속성·값을 갈라 칠함. 여러 줄에 걸친 여는 태그도 이어진다. 줄 넘김 상태를 깃발 묶음으로 넓혔다 | 아래 |
 | 2026-09-11 | **5차 A-2** — Git 작업을 시작하는 자리에서 묻게 함. 가려서 묻는 것은 접고 전부 묻는다. 덤으로 4차 A-1 이 새던 자리 셋을 막음 | 아래 |
 | 2026-09-11 | **5차 A-1** — 실제 저장소 2,091개로 인코딩을 확인(깨짐 0). 판별 코드가 두 군데 복사돼 있던 것을 한 곳으로 모으고, CP949 를 한 이름으로 부르게 함 | 아래 |

doc/작업지시/5차.md

@@ -4,8 +4,13 @@
 전제: 1~4차 지시서는 모두 끝났다([../진행상황.md](../진행상황.md)).
 
 **이번 지시서가 앞과 다른 점** — 지금까지는 시험용 파일로만 확인했다.
-5차는 **실제 소스(`D:\Sorce\LGE-OC6-Inline-CylinderTypeWelder`)를 재 보고 나온 것**들이다.
+5차는 **실제 소스를 한 번 재 보고 나온 것**들이다.
-아래 숫자는 2026-09-10 에 실제로 센 값이다.
+아래 숫자는 2026-09-10 에 실제로 센 값이다. 그 값은 그대로 둔다.
+
+> **2026-09-11 부터 실제 소스를 더 보지 않는다.** 여기는 머지툴을 만드는 자리다.
+> 남의 저장소를 읽을 까닭이 남아 있지 않고, 읽는 동안 사고가 날 여지만 있다.
+> 재료가 필요하면 **우리가 만든 시험용 묶음**을 쓴다.
+> 그래야 같은 시험을 몇 번이고 똑같이 돌릴 수 있어 오히려 재기에 낫다.
 
 | 잰 것 | 값 |
 |---|---|
@@ -27,8 +32,9 @@
   2. [../진행상황.md](../진행상황.md) 은 **대기 → 완료로 상태만**
   3. [../history/changelog.md](../history/changelog.md) 에 한 줄 — 날짜 · 무엇을 왜 · 커밋
 - **푸쉬하지 않는다.**
-- **실제 저장소(`LGE-OC6-...`)를 고치지 않는다.** 읽기만 한다. 시험이 필요하면 사본을 뜬다.
+- **실제 소스를 열지 않는다.** 고치지 않는 것은 물론이고 읽지도 않는다(2026-09-11 결정).
-  이건 남의 작업물이고, 우리 도구가 망가뜨리면 되돌릴 방법이 없다.
+  시험 재료는 **우리가 만들어 쓴다.** 남의 작업물이고, 우리 도구가 망가뜨리면 되돌릴 방법이 없다.
+  이미 받아 둔 숫자는 그대로 쓴다 - 다시 재려고 남의 폴더를 열 일이 아니다.
 - 기존 검사 하네스 17벌(571건)은 계속 통과해야 한다. 로직을 건드리면 **테스트를 먼저 늘린다.**
 - 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 `UbisamBase.Shell` 을 먼저 종료한다.
 - 플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고
@@ -79,9 +85,13 @@
 - **판정 기준**: 실제 XAML 파일(예: `UCManual*.xaml`)을 열었을 때 태그와 속성이 눈으로 갈린다.
   C# 파일의 색칠은 달라지지 않는다.
 
-### B-2. 폴더 비교가 실제 저장소에서 12초 걸린다
+### B-2. 폴더 비교가 큰 저장소에서 12초 걸린다
 
-- 4,503개를 견주는 데 **12.2초**다. 멈춘 것처럼 보이지는 않지만(취소도 되고 진행도 보인다) 길다.
+- 4,503개를 견주는 데 **12.2초**다(2026-09-10 실제 소스에서 잰 값). 멈춘 것처럼 보이지는 않지만
+  (취소도 되고 진행도 보인다) 길다.
+- **재는 데 쓸 폴더는 우리가 만든다.** 실제 소스는 더 열지 않는다.
+  깊이·파일 수·크기 분포를 비슷하게 맞춘 묶음을 한 번 만들어 두고 그것으로 고치기 전후를 견준다.
+  만든 묶음이라 **몇 번을 돌려도 같은 값**이 나온다 - 오히려 재기에 낫다.
 - **먼저 무엇이 오래 걸리는지 재고 보고한다.** 폴더를 훑는 시간인지, 파일을 여는 시간인지,
   화면에 트리를 세우는 시간인지. 재지 않고 고치면 엉뚱한 데를 고친다.
 - 줄일 수 있는 자리를 찾아 고친다. 크기·수정 시각이 같으면 내용을 안 여는 길은 이미 있다(빠른 비교).
@@ -93,14 +103,18 @@
 
 ## C. 실전 투입
 
-### C-1. 실제 저장소로 병합을 한 번 끝까지 해 본다
+### C-1. 병합을 한 번 끝까지 해 본다
 
-- 지금까지 3-Way 병합은 **데모 저장소로만** 확인했다. 실제 소스로 해 본 적이 없다.
+- 지금까지 3-Way 병합은 **데모 저장소로만** 확인했다. 데모는 파일이 다섯 개다.
-- **사본을 떠서** 한다(`LGE-OC6-...` 원본은 건드리지 않는다).
+  <b>한 번도 "긴 파일 여러 개에서 충돌이 여기저기 난" 상황을 겪어 본 적이 없다.</b>
-  브랜치 두 개를 만들어 같은 파일을 양쪽에서 고치고, 병합 → 충돌 → MergeHub 로 해결 → 커밋까지 간다.
+- **저장소는 우리가 만든다.** 실제 소스는 열지 않는다.
+  데모보다 훨씬 크게 - 파일 수백 개, 그중 몇 개는 수천 줄, C# 과 XAML 을 섞어서 - 만들어 두고
+  브랜치 두 개에서 같은 파일을 양쪽에서 고친 뒤, 병합 → 충돌 → MergeHub 로 해결 → 커밋까지 간다.
+- **이 방법의 한계를 알고 한다.** 만든 소스는 진짜 코드의 지저분함이 없다.
+  여기서 안 걸렸다고 실제에서 안 걸린다는 뜻은 아니다. 그래도 데모 다섯 파일보다는 훨씬 낫다.
 - **고치지 말고 먼저 적는다.** 걸린 것 · 헷갈린 것 · 느린 것을 그대로 적어 보고한다.
   그 목록이 6차 지시서가 된다.
-- **판정 기준**: 사본 저장소에서 충돌 하나를 MergeHub 만으로 해결해 커밋까지 끝낸다.
+- **판정 기준**: 만든 저장소에서 충돌 하나를 MergeHub 만으로 해결해 커밋까지 끝낸다.
   그 과정에서 나온 문제를 목록으로 남긴다.
 
 ---

doc/진행상황.md

@@ -57,7 +57,9 @@
 
 진행 기록: [history/2026-09-11-5차.md](history/2026-09-11-5차.md)
 지시서: [작업지시/5차.md](작업지시/5차.md). 지금까지는 시험용 파일로만 확인했다.
-5차는 실제 소스(`LGE-OC6-Inline-CylinderTypeWelder` · 2,115개 · 426,723줄)를 재 보고 나온 것들이다.
+5차는 실제 소스(2,115개 · 426,723줄)를 한 번 재 보고 나온 것들이다.
+2026-09-11 부터는 실제 소스를 더 보지 않는다 - 여기는 머지툴을 만드는 자리이고,
+시험 재료는 우리가 만들어 쓴다. 이미 받아 둔 숫자는 그대로 쓴다.
 
 ### A. 남의 소스를 망가뜨릴 수 있는 것