5차 C-1: 병합을 끝까지 해 보고 걸린 것을 적는다

만든 저장소(파일 303개, 충돌 22개)로 MergeHub 만으로 병합해서
커밋까지 갔다. 지시서대로 고치지 않고 적기만 했다. 제품 코드는
바꾸지 않았다.

맞게 된 것: 병합 결과가 git 과 똑같다(UU 20 AA 1 UD 1 M 7).
3분할에서 충돌 6개를 6 -> 0 으로 줄였고, 파일 단위 Accept 는 고른
쪽과 바이트까지 같다. 부모 둘인 병합 커밋이 생겼다.

걸린 것 23가지. 심각한 다섯:
- 3분할로 푼 파일을 저장하면 CRLF 가 LF 로 바뀐다(커밋에 CR 0개)
- Save & Commit 이 실패라는데 파일은 이미 써지고 스테이징됐다
- 충돌 파일을 고르면 상대(Theirs) 칸이 안 나온다
- 상대가 지운 파일을 3분할이 다룰 줄 모른다
- 양쪽 새 파일에 Accept Both 를 누르면 BOM 이 가운데 하나 더 들어간다

기대값은 사본에서 git 으로 먼저 받아 대조했다. 실제 소스는
열지 않았다.

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

doc/history/2026-09-11-5차.md

@@ -336,3 +336,110 @@ new FileInfo(leftPath).Length    // 또 묻는다
 - 앱을 띄워 실제로 비교해 봤다. 세 번 모두 같은 요약이 나온다.
 
 전체 **698건 통과**(하네스 20벌) · 빌드 경고 0 · 오류 0. **실제 저장소는 열지 않았다.**
+
+
+---
+
+## C-1. 병합을 한 번 끝까지 해 본다 (2026-09-14, 완료)
+
+지시서대로 **고치지 않고 적기만 했다.** 제품 코드는 한 줄도 안 바꿨다.
+
+### 무엇으로 했나
+
+실제 소스는 열지 않기로 했으므로(2026-09-11) 병합할 저장소를 만들었다. 데모는 파일이 다섯 개라
+"긴 파일 여러 개에서 충돌이 여기저기 난" 상황을 한 번도 겪어 보지 못했다.
+
+| 모양 | 값 |
+|---|---|
+| 파일 | 303개 (C# 240 · XAML 60 · 그 밖 3) |
+| 큰 파일 | 3,000~7,000줄짜리 5개 |
+| 브랜치 | `feature/mine` 에 서서 `feature/theirs` 를 MergeHub 로 병합 |
+
+현장에서 나올 법한 충돌을 일부러 넣었다.
+
+| | 넣은 것 | 파일 |
+|---|---|---|
+| A | 같은 줄을 양쪽이 다르게 고침 | 15 |
+| B | 같은 파일, 다른 자리를 고침 (자동 병합되어야 함) | 7 |
+| C | 양쪽이 똑같이 고침 (충돌 아님) | 3 |
+| D | 큰 파일에 충돌 덩어리 6개씩 흩어 놓음 | 2 |
+| E | XAML 여러 줄 태그 안에서 충돌 | 1 |
+| F | 내가 고쳤는데 상대가 지움 | 1 |
+| G | 양쪽이 같은 이름으로 새 파일을 만듦 | 1 |
+| H | CP949 한글 파일에서 충돌 | 1 |
+| I | 상대가 줄바꿈을 CRLF 에서 LF 로 바꾼 파일 | 1 |
+
+**기대값은 사본에서 git 으로 먼저 받았다.** `git merge` 결과 UU 20 · AA 1 · UD 1 · M 7, 충돌 22개.
+
+### 끝까지 갔다
+
+- MergeHub 의 병합 결과가 **git 과 똑같다** (UU 20 · AA 1 · UD 1 · M 7).
+- 큰 파일은 3분할로 열어 [다음 충돌] 과 Take Mine/Theirs 로 **6 → 0** 까지 줄였다. 고른 대로 들어갔다.
+- 나머지는 충돌 탭의 파일 단위 Accept 로 풀었다. **고른 쪽 파일과 바이트까지 같다.**
+- 22개를 다 풀자 [병합 커밋] 이 켜졌고, **부모 둘인 병합 커밋**이 생겼다. 워킹트리 Clean · 충돌 표시 남은 파일 0.
+- 상대가 지운 파일은 Accept Theirs 로 지워졌다. 자동 병합 파일은 양쪽 고친 것이 다 들어갔다.
+- CP949 파일은 네 칸 모두 한글이 바르게 나오고, XAML 은 네 칸 모두 B-1 색칠이 된다.
+
+**판정 기준을 만족했다** — 만든 저장소에서 MergeHub 만으로 충돌을 풀어 커밋까지 끝냈다.
+다만 **가는 길에 걸린 것이 스물세 가지**다(적을 때는 스물일곱이었는데 같은 뿌리를 합쳤다). 아래가 6차의 재료다.
+
+### 걸린 것 — 파일이나 이력을 망가뜨리는 것
+
+| # | 무엇 | 근거 |
+|---|---|---|
+| 1 | **3분할로 푼 파일을 저장하면 CRLF 가 LF 로 바뀐다.** git 에는 파일 전체가 바뀐 것으로 나온다. 상태바는 CRLF, 저장 형식은 "원본 유지"였다. CP949 파일도 같다 | 커밋에 CR 0개 (바탕은 줄마다 CRLF). 105,025B → 101,810B. 줄끝 무시하면 12줄 차이인데 3,367줄이 바뀐 것으로 나온다 |
+| 2 | **Save & Commit 이 "실패"라고 하는데 파일은 이미 써지고 스테이징됐다.** 남은 충돌이 있으면 커밋에서 막히지만 그 앞 단계는 이미 끝난 뒤다 | 충돌 22 → 21. 화면은 "실패: 아직 해결되지 않은 충돌이 21건" |
+| 3 | **충돌 파일을 고르면 상대(Theirs) 칸이 안 나온다.** BASE 와 내 것 두 칸뿐이다. 3-Way 콤보에서 브랜치를 골라야 세 칸이 된다. 상대가 무엇을 바꿨는지 모른 채 풀게 된다 | 충돌 갈래가 지역 변수 `threeWay` 만 켜고 `IsThreeWay` 는 안 켠다 |
+| 4 | **상대가 지운 파일을 열면 REMOTE 칸이 비고, 범례는 "Theirs only 89" 라고 한다.** 실은 내 쪽에만 있는 줄이다. 진짜 물음은 "남길까 지울까" 인데 3분할에는 지우는 길도, 상대가 지웠다는 말도 없다 | 충돌 탭에만 "상대쪽 삭제" |
+| 5 | **양쪽 새 파일에 Accept Both 를 누르면 바이트째 이어 붙인다.** 가운데 BOM 이 하나 더 들어가고 같은 class 가 두 번 나와 빌드가 안 된다 | 결과 파일 안에 EF BB BF 두 번 |
+
+### 걸린 것 — 헷갈리거나 막히는 것
+
+| # | 무엇 |
+|---|---|
+| 6 | "실패" 한 Save & Commit 뒤에도 화면은 **저장 안 한 편집**으로 여긴다. 다른 파일을 고르거나 Git 탭에서 Accept 를 누를 때마다 확인 창이 다시 뜬다 (2번의 다른 얼굴) |
+| 7 | 그 확인 창이 **엉뚱한 파일 이름**을 댄다. 고친 것은 Unit0.cs 인데 "ToBeDeleted.cs 에 저장하지 않은 편집". 새로 고른 파일 이름을 가져다 쓴다 |
+| 8 | Git 모드에는 **커밋 없이 저장하는 길이 없다.** Ctrl+S 도 Save & Commit 이다. 병합 중에 파일 하나씩 풀어 둘 수가 없다 |
+| 9 | 병합 뒤 파일 비교 탭의 **파일 목록이 비어 있다.** 그 탭의 [새로고침] 을 눌러야 나온다. 앱을 새로 켜도 같다 |
+| 10 | 충돌 탭 목록을 **두 번 눌러도 3분할로 안 넘어간다** |
+| 11 | 안내 글이 "**홈 탭**에서 해결하세요" 라고 한다. 홈 탭은 없다 |
+| 12 | 3분할의 MERGED 칸 **줄 번호가 네 자리에서 잘린다.** 2950~2959 가 전부 "295" |
+| 13 | 커밋 메시지가 **처음 연 충돌 파일 것으로 굳는다.** 앱을 껐다 켜도, 병합 커밋 뒤에도 "Merge: Common/Util/Unit15.cs 충돌 해결" |
+| 14 | 병합 커밋 메시지가 브랜치 이름이 아니라 **"Merge commit '1742d8f...'"** 이고, git 의 주석 줄 **"#Conflicts:" 와 파일 목록**이 그대로 남는다 |
+| 15 | Take Theirs 한 자리마다 **머지 주석** "// [김승준] 2026-09-14" 가 소스에 들어간다. 병합 결과에 사람이 안 고른 줄이 생긴다 (설정으로 켠 기능 - 병합에서도 켜져야 하는지 따질 일) |
+| 16 | 충돌 탭에서 Accept 할 때마다 **저장소 전체를 다시 읽는다.** 한 개 약 1.7초. 22개면 기다리는 것만 40초쯤. 여러 개를 골라 한 번에 풀 수 없다 |
+| 17 | 상태바 인코딩·줄바꿈이 결과가 아니라 **충돌 표시가 들어간 워킹트리 파일**을 읽는다. 양쪽 다 CRLF 인 파일도 "혼합" 으로 나온다 |
+| 18 | 상태바 "남은 차이 6줄" 은 충돌을 다 정해도 그대로다. "남은 충돌" 은 오른쪽 칸에만 나온다 |
+| 19 | 파일 콤보에서 다른 파일을 고르는 **한가운데서** 확인 창이 뜬다. 고른 파일이 바뀌었는지 아닌지 불분명하다 |
+| 20 | 병합 커밋 뒤 파일 비교 탭이 어정쩡하게 남는다. 목록은 비고, 3분할 틀에 병합과 상관없는 파일이 BASE 칸에만 뜬다 |
+
+### 걸린 것 — 사소한 것
+
+| # | 무엇 |
+|---|---|
+| 21 | 병합 로그에 "충돌 22건 - 해결이 필요합니다." 가 두 번 찍힌다 |
+| 22 | 충돌 탭 목록의 종류 표시가 들쭉날쭉하다. 상대쪽 삭제만 표시되고 양쪽 새 파일은 표시가 없다. 몇 개 풀었는지(0/22)도 없다 |
+| 23 | 로그가 CP949 를 "ks_c_5601-1987" 로 적는다. 5차 A-1 에서 모은 이름이 이 자리에는 안 갔다 |
+
+(번호를 6차에서 쓰기 좋게 심각한 것부터 다시 매겼다. 적은 순서와는 다르다.)
+
+### 6차로 넘길 때 보는 순서
+
+1. **1·2·6·8 은 한 뿌리다.** 병합 중에 "파일 하나를 풀어서 저장한다" 는 동작이 없고, 커밋까지 한 번에 묶여 있다.
+   저장만 하는 길을 따로 두고, 그 길이 저장 형식(인코딩·줄바꿈)을 따르게 하면 네 가지가 같이 풀린다.
+2. **3·9·10·11 도 한 뿌리다.** 충돌 목록에서 3분할 화면까지 가는 길이 끊겨 있다.
+   충돌 파일을 고르면 세 칸이 바로 뜨고, 충돌 탭에서 한 번에 넘어가게 하면 된다.
+3. **4·5 는 파일 단위 충돌**(지움 · 양쪽 새 파일)을 줄 단위 화면이 다룰 줄 모르는 것이다.
+
+### 시험 도구 쪽 사고 (제품 결함 아님)
+
+자동 조작이 콤보 항목을 UIA 로 고르는 중에 확인 창이 떴고, 그 호출이 돌아오지 않은 채 확인 창이 입력을 안 받게 굳었다.
+앱을 끄고 새로 띄웠다. 그 사이 파일에는 **아무것도 안 써졌다** (크기 · 스테이징 · 남은 충돌 수로 확인).
+사람이 마우스로 고를 때는 이렇게 굳지 않는다. 다만 19번은 사람에게도 헷갈리는 자리라 남겼다.
+
+### 다시 해 보려면
+
+시험 저장소는 `C1Repo` 로 만든다(씨앗 고정 · 몇 번을 돌려도 같다). 실제 소스를 열지 않는다.
+만든 소스에는 **진짜 코드의 지저분함이 없다** - 여기서 안 걸렸다고 실제에서 안 걸린다는 뜻은 아니다.
+
+코드는 바꾸지 않았으므로 검사는 그대로 698건 통과(하네스 20벌) · 빌드 경고 0 · 오류 0.

doc/history/changelog.md

@@ -8,6 +8,7 @@
 
 | 날짜 | 항목 | 커밋 |
 |---|---|---|
+| 2026-09-14 | **5차 C-1** — 만든 저장소(303개 · 충돌 22)로 병합을 MergeHub 만으로 커밋까지 해 봄. 고치지 않고 걸린 것 23가지를 적음. 가장 큰 것은 3분할 저장이 CRLF 를 LF 로 바꾸는 것 | 아래 |
 | 2026-09-11 | **5차 B-2** — 폴더 비교를 훑기·가리기·세기 세 걸음으로 나눔. 메타데이터를 한 번만 묻고 가리는 일은 여러 갈래로. 전체 3.4배 · 빠른 4.7배 | 아래 |
 | 2026-09-11 | **지시서 5차 고침** — 실제 소스를 더 읽지 않기로 함. 시험 재료는 우리가 만든다. B-2·C-1 을 그에 맞게 다시 씀 | 아래 |
 | 2026-09-11 | **5차 B-1** — XAML 태그·속성·값을 갈라 칠함. 여러 줄에 걸친 여는 태그도 이어진다. 줄 넘김 상태를 깃발 묶음으로 넓혔다 | 아래 |

doc/진행상황.md

@@ -79,7 +79,7 @@
 
 | 상태 | 항목 |
 |---|---|
-| 대기 | C-1 실제 저장소로 병합을 한 번 끝까지 해 본다 |
+| **완료** | C-1 병합을 한 번 끝까지 해 본다 — 커밋까지 갔다. 걸린 것 23가지(심각 5)가 6차 재료 |
 
 ---