Ubisam-MergeTool/doc/작업지시/5차.md

작업 지시 — MergeHub 5차 (실제 소스에 맞추기)

대상: D:\Sorce\MergeTool\MergeHub (플러그인) · D:\Sorce\MergeTool\UbisamPlatform (셸) 전제: 1~4차 지시서는 모두 끝났다(../진행상황.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 은 대기 → 완료로 상태만
  3. ../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개뿐이었다. 힘을 쓴 자리가 어긋나 있었다.
• 태그 이름 · 속성 이름 · 속성 값 · 주석 네 가지만 갈라도 읽기가 크게 달라진다. 마크업은 단어 단위가 아니라 꺾쇠 안인지 밖인지로 갈리므로 지금 토크나이저에 그대로 얹기 어렵다. 얹을 수 있는지부터 보고, 아니면 마크업용 갈래를 따로 둔다.
• 판정 기준: 실제 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) — 미룬 그대로 둔다.
• 로그인·권한 — 로컬 도구가 우선이다.

---

보고 형식

항목마다 이렇게 적는다.

• 무엇이 원인이었는지 한두 줄 (재 보는 항목이면 잰 값)
• 어떤 파일을 어떻게 고쳤는지
• 실제로 실행해 확인한 결과
• 커밋 해시