작업지시-5차: 실제 소스에 맞추기 다섯 항목

지금까지 시험용 파일로만 확인했다. 실제 저장소를 재 보고 나온 것들로 채웠다.
CP949 67개 · XAML 400개 · 폴더 비교 12초 · 실전 병합.
대용량 성능은 답이 나와 미룬 것에서 뺐다 - 가장 큰 파일이 7479줄이고 다 빠르다.

doc/작업지시/5차.md

@@ -0,0 +1,124 @@
+# 작업 지시 — MergeHub 5차 (실제 소스에 맞추기)
+
+대상: `D:\Sorce\MergeTool\MergeHub` (플러그인) · `D:\Sorce\MergeTool\UbisamPlatform` (셸)
+전제: 1~4차 지시서는 모두 끝났다([../진행상황.md](../진행상황.md)).
+
+**이번 지시서가 앞과 다른 점** — 지금까지는 시험용 파일로만 확인했다.
+5차는 **실제 소스(`D:\Sorce\LGE-OC6-Inline-CylinderTypeWelder`)를 재 보고 나온 것**들이다.
+아래 숫자는 2026-09-10 에 실제로 센 값이다.
+
+| 잰 것 | 값 |
+|---|---|
+| 소스 파일 | 2,115개 · 426,723줄 |
+| 갈래 | **C# 1,691개(382,176줄) · XAML 400개(42,477줄)** · .h 24개 |
+| 가장 큰 파일 | `RTC6Wrap.cs` 7,479줄 (428KB) |
+| BOM 없는 한글 파일 | 420개 — 그중 **CP949 가 67개** |
+| 폴더 비교(4,503개) | **12.2초** |
+| 7,479줄에서 편집 | 글자 31ms · 엔터 31ms · 재정렬 222ms (문제 없음) |
+
+---
+
+## 공통 규칙
+
+- **A → B → C 순서로 진행한다.** A 는 잘못 되면 남의 소스를 망가뜨리는 문제라 제일 먼저다.
+- **항목 하나를 끝낼 때마다** 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다.
+- **항목 하나가 끝나면 기록을 세 군데에 남기고 로컬 커밋한다**(4차 D-2 에서 정한 규칙).
+  1. **상세**는 `doc/history/YYYY-MM-DD-주제.md` — 원인 · 판단 · 확인한 결과
+  2. [../진행상황.md](../진행상황.md) 은 **대기 → 완료로 상태만**
+  3. [../history/changelog.md](../history/changelog.md) 에 한 줄 — 날짜 · 무엇을 왜 · 커밋
+- **푸쉬하지 않는다.**
+- **실제 저장소(`LGE-OC6-...`)를 고치지 않는다.** 읽기만 한다. 시험이 필요하면 사본을 뜬다.
+  이건 남의 작업물이고, 우리 도구가 망가뜨리면 되돌릴 방법이 없다.
+- 기존 검사 하네스 17벌(571건)은 계속 통과해야 한다. 로직을 건드리면 **테스트를 먼저 늘린다.**
+- 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 `UbisamBase.Shell` 을 먼저 종료한다.
+- 플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고
+  `UbisamPlatform/doc/history/changelog.md` 에 남긴다.
+
+---
+
+## A. 남의 소스를 망가뜨릴 수 있는 것
+
+### A-1. CP949 파일 67개를 잘못 읽으면 한글이 깨진다
+
+- 실제 소스에 **BOM 없는 한글 파일이 420개**, 그중 **67개가 CP949** 다(예: `AXA.cs`).
+  나머지 353개는 BOM 없는 UTF-8 이다. **한 저장소 안에 두 인코딩이 섞여 있다.**
+- `TextFile.Detect` 가 이 판단을 하고 있는데, **실제 파일로 맞는지 확인한 적이 없다.**
+  잘못 읽으면 화면에서 한글이 깨져 보이고, 그대로 저장하면 **파일이 실제로 망가진다.**
+- **먼저 확인만 한다.** 67개 CP949 파일과 353개 UTF-8 파일을 전부 열어(또는 `TextFile.Read` 로 훑어)
+  한글이 제대로 읽히는지 세어 보고 **숫자로 보고한다.** 틀리는 파일이 있으면 그 다음에 고친다.
+- 저장 쪽도 본다. `저장 형식 = 원본 유지` 가 CP949 파일을 **CP949 로 되돌려 쓰는지** 확인한다.
+  사본으로 시험하고 **바이트 단위로 견준다** - 눈으로 보면 모른다.
+- **판정 기준**: CP949 67개 · UTF-8 353개를 열어 한글이 깨지는 파일이 **0개**다.
+  사본을 열어 한 글자도 고치지 않고 저장했을 때 **바이트가 그대로**다.
+
+### A-2. 커밋·체크아웃 뒤에 저장 안 한 편집이 조용히 사라진다
+
+- 4차 A-1 에서 여덟 군데를 막았지만 **`RefreshCommits` → `LoadCommitAsync` 는 일부러 두었다.**
+  프로그램이 목록을 다시 세우는 자리라 그 한가운데 확인 창을 띄우면 무엇에 답하는지 알 수 없고,
+  취소해도 목록은 이미 새로 세워진 뒤라 되돌릴 자리가 없기 때문이다.
+- 남은 구멍인 것은 맞다. Git 탭에서 커밋·체크아웃·pull 을 하면 고치던 내용이 다시 읽힌다.
+- **막는 자리를 바꿔서 푼다.** 목록을 다시 세우는 자리가 아니라 **Git 작업을 시작하는 자리**에서 묻는다.
+  그 순간에는 아직 아무것도 바뀌지 않았으므로 취소가 뜻이 있다.
+- **판정 기준**: LOCAL 을 고친 채 Git 탭에서 커밋·체크아웃을 누르면 묻는다.
+  취소하면 Git 작업도 일어나지 않고 편집도 그대로다.
+
+---
+
+## B. 실제 소스에 맞추기
+
+### B-1. XAML 색칠이 사실상 없다
+
+- 실제 소스에 **XAML 이 400개 · 42,477줄**이다. C# 다음으로 많다.
+  그런데 지금 XAML 은 주석과 따옴표만 알아본다(`LanguageProfile.Markup`).
+  **태그 이름 · 속성 이름 · 속성 값이 전부 같은 색**이라 사실상 평문이다.
+- 3차 D-2 에서 C++ 전처리 지시문을 넣었는데, **정작 실제 소스에는 .h 가 24개뿐**이었다.
+  힘을 쓴 자리가 어긋나 있었다.
+- 태그 이름 · 속성 이름 · 속성 값 · 주석 네 가지만 갈라도 읽기가 크게 달라진다.
+  마크업은 단어 단위가 아니라 <b>꺾쇠 안인지 밖인지</b>로 갈리므로 지금 토크나이저에 그대로 얹기 어렵다.
+  얹을 수 있는지부터 보고, 아니면 마크업용 갈래를 따로 둔다.
+- **판정 기준**: 실제 XAML 파일(예: `UCManual*.xaml`)을 열었을 때 태그와 속성이 눈으로 갈린다.
+  C# 파일의 색칠은 달라지지 않는다.
+
+### B-2. 폴더 비교가 실제 저장소에서 12초 걸린다
+
+- 4,503개를 견주는 데 **12.2초**다. 멈춘 것처럼 보이지는 않지만(취소도 되고 진행도 보인다) 길다.
+- **먼저 무엇이 오래 걸리는지 재고 보고한다.** 폴더를 훑는 시간인지, 파일을 여는 시간인지,
+  화면에 트리를 세우는 시간인지. 재지 않고 고치면 엉뚱한 데를 고친다.
+- 줄일 수 있는 자리를 찾아 고친다. 크기·수정 시각이 같으면 내용을 안 여는 길은 이미 있다(빠른 비교).
+  **기본 동작을 바꾸지는 않는다** - 빠른 비교는 틀릴 수 있어 사용자가 고르는 것으로 남긴다.
+- **판정 기준**: 같은 저장소를 다시 비교했을 때 **눈에 띄게 빨라진다.**
+  결과(전체·다름·한쪽만 개수)는 고치기 전과 똑같다.
+
+---
+
+## C. 실전 투입
+
+### C-1. 실제 저장소로 병합을 한 번 끝까지 해 본다
+
+- 지금까지 3-Way 병합은 **데모 저장소로만** 확인했다. 실제 소스로 해 본 적이 없다.
+- **사본을 떠서** 한다(`LGE-OC6-...` 원본은 건드리지 않는다).
+  브랜치 두 개를 만들어 같은 파일을 양쪽에서 고치고, 병합 → 충돌 → MergeHub 로 해결 → 커밋까지 간다.
+- **고치지 말고 먼저 적는다.** 걸린 것 · 헷갈린 것 · 느린 것을 그대로 적어 보고한다.
+  그 목록이 6차 지시서가 된다.
+- **판정 기준**: 사본 저장소에서 충돌 하나를 MergeHub 만으로 해결해 커밋까지 끝낸다.
+  그 과정에서 나온 문제를 목록으로 남긴다.
+
+---
+
+## 이번 지시서에서 하지 않는 것
+
+- **대용량 파일 성능** — 잴 필요가 없어졌다. 실제 소스의 가장 큰 파일이 **7,479줄**이고,
+  거기서 글자 31ms · 엔터 31ms · 전체 재정렬 222ms 로 다 빠르다. 미룬 것 목록에서 뺀다.
+- 같은 줄 접기(4차 B-2) · 외부 편집기(4차 B-4) — 미룬 그대로 둔다.
+- 로그인·권한 — 로컬 도구가 우선이다.
+
+---
+
+## 보고 형식
+
+항목마다 이렇게 적는다.
+
+- 무엇이 원인이었는지 한두 줄 (재 보는 항목이면 잰 값)
+- 어떤 파일을 어떻게 고쳤는지
+- 실제로 실행해 확인한 결과
+- 커밋 해시

doc/진행상황.md

@@ -53,12 +53,39 @@
 
 ---
 
+## 5차 — 실제 소스에 맞추기 (2026-09-10 ~)
+
+지시서: [작업지시/5차.md](작업지시/5차.md). 지금까지는 시험용 파일로만 확인했다.
+5차는 실제 소스(`LGE-OC6-Inline-CylinderTypeWelder` · 2,115개 · 426,723줄)를 재 보고 나온 것들이다.
+
+### A. 남의 소스를 망가뜨릴 수 있는 것
+
+| 상태 | 항목 |
+|---|---|
+| 대기 | A-1 CP949 파일 67개를 잘못 읽으면 한글이 깨진다 |
+| 대기 | A-2 커밋·체크아웃 뒤에 저장 안 한 편집이 조용히 사라진다 |
+
+### B. 실제 소스에 맞추기
+
+| 상태 | 항목 |
+|---|---|
+| 대기 | B-1 XAML 색칠이 사실상 없다 (400개 · 42,477줄) |
+| 대기 | B-2 폴더 비교가 실제 저장소에서 12초 걸린다 |
+
+### C. 실전 투입
+
+| 상태 | 항목 |
+|---|---|
+| 대기 | C-1 실제 저장소로 병합을 한 번 끝까지 해 본다 |
+
+---
+
 ## 3~4주차로 미룬 것
 
 디테일이라 지금 붙잡을 일이 아니다.
 
 - 로그인·권한
-- 대용량 파일 성능 (수만 줄) — 실제 소스 크기를 확인한 뒤 판단
+- ~~대용량 파일 성능~~ — 잴 필요가 없어졌다(2026-09-10). 실제 소스의 가장 큰 파일이 7,479줄이고 편집·이동·재정렬이 모두 빠르다
 - 같은 줄 접기 (4차 B-2) — 차이 이동만으로 부족하다고 느끼는 순간이 오면 그때
 - 외부 편집기로 열기 (4차 B-4) — 설정 값 두 개를 채우는 수고가 얻는 것보다 컸다