Ubisam-MergeTool/doc/history/2026-09-23-12차.md

12차 진행 기록 (2026-09-23 ~)

지시서: ../작업지시/12차.md

A-1. 폴더 줄의 크기가 늘 0B (2026-09-27, 완료)

무엇이 문제였나

크기를 파일 줄에만 채웠다(FolderComparer 의 파일 루프에서 FileInfo.Length). 폴더 줄은 LeftSize · RightSize 가 0 인 채로 화면에 내려가 어느 폴더든 0 B 로 보였다. 어느 쪽이 더 큰지, 어느 폴더가 무거운지를 목록에서 알 수 없었다.

어떻게 고쳤나

Services/FolderSizeText.cs 를 새로 두었다. 화면 없이 검사할 수 있게 계산만 떼어 낸 것이다.

하는 일	함수
사람이 읽는 크기로 적기	Of(long bytes) — 1KB 미만은 바이트 그대로(999 B), 그 위는 소수 한 자리(1.5KB · 2.4MB · 3GB)
폴더 줄에 합계 채우기	FillFolderSizes(items) — 아래에서 위로, 폴더는 자기 아래 것들의 합

• 부르는 자리는 FolderComparer.Compare 의 ClassifyAll 다음, Tally 앞이다. 파일 갈래를 정하는 판단은 파일 크기를 보고 하므로(크기가 다르면 열지 않는다) 그보다 먼저 채우면 판단이 달라진다 — 그래서 뒤에 둔다.
• 걸러 낸 것은 합계에서도 빠진다. 포함 · 제외 규칙에 걸린 파일은 애초에 목록에 없으므로 따로 뺄 일이 없다.
• 한쪽에만 있는 폴더는 그쪽만 합계고 반대쪽은 0 이다(화면에는 -).
• 화면 쪽은 FolderViewModel.Describe 가 {크기} · {수정일} 을 만들 때 FolderSizeText.Of 를 쓰게 바꿨다. 예전에는 {바이트:N0} B 라 300,000 B 처럼 읽기 어려웠다.

값으로 확인한 것

시험 재료는 만들어 썼다(%TEMP%\mergehub-a1, 실제 업무 저장소는 읽지 않는다).

폴더	화면	탐색기 속성(파일 크기 합)
Docs	2.4MB · 2.4MB	2,500,000 · 2,500,000
Legacy(왼쪽만)	50KB · -	51,200 · 없음
NewOnly(오른쪽만)	- · 40KB	없음 · 40,960
Src	490.2KB · 491.7KB	502,000 · 503,500 (기본 제외 규칙에 걸린 Src\bin 9MB 는 빠짐)
Src\Core	472.7KB · 474.1KB	484,000 · 485,500
Src\Core\Motion	179.7KB · 181.2KB	184,000 · 185,500
Src\Ui	17.6KB · 17.6KB	18,000 · 18,000

• 파일 줄도 함께 읽기 쉬워졌다 — Unit0.cs 293KB · Home.cs 62.5KB / 64KB · manual.txt 2.4MB.
• 비교 시간: 4,608 줄(136MB · 파일 8,922개) 짜리 묶음에서 합계 채우기 0ms(빠른 비교 203ms 대비 0.0%). 디스크를 다시 읽지 않고 이미 만들어 둔 목록을 한 번 훑을 뿐이라 늘어날 여지가 없다.

하네스

FolderTest 88 → 111건(+23) · 실패 0.

• 글자 8건: 1KB 미만 · 1024 · 소수 한 자리 · 딱 떨어질 때 · MB · GB · TB 를 넘을 때 · 음수
• 합계 9건: 여러 겹 · 양쪽 따로 · 가운데 폴더 · 맨 안쪽 · 한쪽에만 있는 폴더 · 파일 줄은 그대로 · 탐색기 속성과 같은 값(양쪽)
• 걸러 내기 3건: 제외한 폴더 · 제외해도 다른 줄은 그대로 · 포함 규칙에 안 맞는 파일
• 판단이 안 바뀌는지 4건: 크기가 다른 이진 파일 · 같은 파일 · 한쪽에만 있는 폴더 · 하위 폴더를 안 볼 때

남긴 것

• 폴더 줄의 수정일은 그대로 비워 둔다. 폴더의 수정 시각은 안의 파일과 무관하게 바뀌어(윈도가 하위 항목을 더하거나 지울 때만 갱신) 사람이 기대하는 값과 다르다 — 크기만 적는 편이 오해가 적다.

A-2. 좌우로 나눠 보이기 (2026-09-27, 완료)

무엇이 문제였나

한 줄에 이름 | 상태 | 왼쪽(크기·수정일) | 오른쪽(크기·수정일) 이 늘어서 있었다. 이름이 한 번만 나오니 "이 줄이 어느 쪽 것인가"를 상태 글자를 읽어야 알 수 있었고, 한쪽에만 있는 항목도 - 한 글자로만 표시됐다.

어떻게 고쳤나

한 줄을 왼쪽 목록 · 가운데 상태 · 오른쪽 목록 세 칸으로 나눴다(11차 F-10 파일 비교와 같은 모양).

• 칸마다 자기 쪽 이름과 크기를 적는다. 그쪽에 없으면 그 칸을 통째로 비운다 — 빈칸이 "여기엔 없다"를 상태 글자보다 먼저 말해 준다. 없는 쪽 크기를 - 로 적던 것도 뺐다.
• 가운데 칸이 두 목록을 가르는 선이다(같음 · 다름 · 왼쪽만 · 오른쪽만).

줄마다 칸이 어긋나는 문제가 하나 있었다. TreeView 는 깊이만큼 줄 전체를 오른쪽으로 밀기 때문에, 칸 폭을 고정해도 깊은 줄일수록 가운데 · 오른쪽 칸이 오른쪽으로 밀려 두 목록으로 읽히지 않는다. 그래서 TreeDepthMarginConverter(새로 둠)로

1. 줄 바깥틀을 민 만큼 되돌리고(Negative=True, 깊이 × 19 DIP 음수 여백) — 칸 경계와 가운데 구분선이 줄마다 같은 자리에 온다,
2. 이름에만 다시 같은 값을 들여쓴다 — 계층은 그대로 보이고, 왼쪽 · 오른쪽 이름이 같은 높이 · 같은 들여쓰기로 맞는다.

트리 자체는 그대로 쓴다(목록 둘을 따로 두고 스크롤 · 펼침을 맞추는 길은 택하지 않았다) — 접기 · 펼치기, 선택, 복사 · 삭제, 걸러 보기, 더블클릭으로 파일 비교 열기가 손대지 않은 채로 남는다.

화면으로 확인한 것

판정 기준	결과
같은 이름이 같은 높이에 온다	Src > Core > Motion > Axis.cs 까지 네 겹 모두 양쪽 같은 줄 · 같은 들여쓰기
한쪽만 있는 항목이 어느 쪽인지 한눈에	Legacy(왼쪽만)는 오른쪽 칸이 빈칸, NewOnly(오른쪽만)는 왼쪽 칸이 빈칸
접기 · 펼치기	모두 펼침 · 모두 접기 모두 그대로. 칸 경계는 깊이가 달라도 한 자리
걸러 보기	왼쪽에만 2줄 · 오른쪽에만 2줄 · 같은 것만 2줄 · 다른 것만 6줄
복사 단추	Legacy 고르고 [→ 오른쪽으로 복사] → 확인 창(본 창 가운데) → 복사됨. 다시 비교하니 왼쪽만 1 · 같음 4 가 왼쪽만 0 · 같음 5 로
좁은 창	1750×1100(1166 DIP) 창모드에서도 세 칸(420+170+420 DIP) 이 다 보인다

하네스

FolderTest 111 → 118건(+7) · 실패 0 — 뿌리 여백 0 · 한 겹 19 · 세 겹 57 · 되돌리는 쪽은 음수 · 되돌린 뒤 다시 들여쓰면 제자리 · 위아래 여백은 안 건드림 · 깊이가 아니거나 음수면 0.

남긴 것

• 칸 폭은 고정(420 · 170 · 420 DIP)이다. 트리가 깊이마다 폭을 다르게 잡아서 비율(*) 폭을 쓰면 줄마다 칸이 달라진다 — 화면이 아주 좁으면 오른쪽 목록이 잘린다(1166 DIP 까지는 확인했다).

B-1. 2-Way 에서 양쪽으로 머지 (2026-09-27, 완료)

지시서에 남겨 둔 "정할 것"을 물어 정했다 — 두 파일 비교에서만 양방향(사용자 결정 2026-09-27). Git 모드에서 왼쪽은 지난 커밋이라 고쳐 쓸 파일이 없고, 네 칸(3-Way)의 BASE 는 공통 조상이라 거기에 쓰는 것이 뜻이 없다.

무엇이 문제였나

반영이 BASE → LOCAL 한 방향뿐이고 저장도 오른쪽 파일에만 됐다. 두 파일을 견주다 왼쪽이 맞는 경우 (오른쪽에서 잘못 지웠거나, 왼쪽 파일도 같이 맞춰야 하는 경우)에는 도구 밖에서 손으로 고쳐야 했다.

어떻게 고쳤나

무엇	어디
줄 반영 [<]	BASE 칸 여백(왼쪽에 있는 줄) · LOCAL 칸 여백(왼쪽에 없는 줄 - BASE 칸에는 그 줄 자체가 없어 달 자리가 없다)
칸마다 저장	ACTIONS 의 ◀ 왼쪽 저장 · 오른쪽 저장 ▶. 고친 것이 없는 쪽은 꺼진다
반영 규칙	Services/PaneText.cs(새로 둠) — 두 방향이 같은 규칙을 쓴다
되돌리기	편집 기록(LineEdit)에 Side 를 더해 어느 칸을 고친 편집인지 들고 다닌다. 한 스택에 쌓여 누른 차례대로 풀린다
저장 기준점	왼쪽 · 오른쪽을 따로 센다(_leftBaseline) — 한쪽을 저장해도 다른 쪽의 "저장할 것 있음"은 그대로

반영 규칙은 어느 쪽으로든 같다. 반대쪽에 줄이 있으면 그 글을 가져오고(없던 줄이면 생긴다), 반대쪽에 없으면 이 칸에서도 지운다. 머지 주석(설정 "머지 주석 넣기")도 양쪽 모두 남는데, 왼쪽에 넣는 주석은 LOCAL(파일이름) 을 출처로 적고 왼쪽에만 있는 줄로 들어간다 — 오른쪽 파일에는 섞이지 않는다.

MergeLine.HasBase · BaseNumber 가 이제 바뀔 수 있는 값이다(예전에는 정렬 결과라 고정이었다). BASE 칸 목록도 그 변화를 따라가게 했다(PaneView 의 live filtering) — 이게 없으면 왼쪽에 넣은 줄이 안 보이고 왼쪽에서 지운 줄이 빈 칸으로 남는다(화면 시험에서 실제로 걸려 고쳤다).

화면으로 확인한 것

시험 재료는 만들어 썼다(%TEMP%\mergehub-b1, left.cs · right.cs).

판정 기준	결과
왼쪽 파일에 반영 · 저장된다	값이 다른 줄 · 왼쪽에만 있는 줄 · 오른쪽에만 있는 줄 셋을 [<] 로 반영 → ◀ 왼쪽 저장 → 왼쪽 파일이 오른쪽 내용 + 머지 주석 2줄
오른쪽은 그대로다	오른쪽 파일 해시 07f16198… 저장 전후 같음. 오른쪽 저장 ▶ 은 고친 것이 없어 꺼져 있었다
되돌리기(11차 F-8)	Undo 세 번에 BASE 칸이 처음 모습으로(값 100 · 왼쪽에만 있던 줄 · 주석 사라짐), Redo 켜짐. 저장한 뒤라 ◀ 왼쪽 저장 은 다시 켜진다(저장한 글과 달라졌으므로 - F-8 의 뜻 그대로)
저장할 때 백업(11차 F-9)	{설정}\Backup\MergeHub\2026-09-27\…\left.20260927-191108.cs
두 파일 비교에서만	git mergetool 네 칸(--merge --base --local --remote --merged)에서 [<](새 단추) 0개 · ◀ 왼쪽 저장 안 보임. 네 칸의 기존 <(Take Mine · Take Theirs)는 그대로

하네스

TwoWayTest 29건 새로 · 실패 0 — 칸의 글 만들기 3 · 반영 규칙 7(양방향 · 한쪽에만 있는 줄 · 같은 줄 · 멱등) · 왼쪽으로 반영한 뒤 5 · 오른쪽으로 반영한 뒤 3(예전 길 그대로) · 양쪽 저장 기준점 5 · 로그 문구 4 · 기타 2.

남긴 것

• 왼쪽 칸은 타이핑으로는 못 고친다. 편집기는 오른쪽에만 겹쳐 있다 - 왼쪽은 [<] 로 반영해서 고친다 (지시서가 정한 것: "칸마다 저장 단추 · 왼쪽 칸에도 반영 단추 [<]").
• 왼쪽으로 반영한 줄에는 "머지 반영함" 색을 칠하지 않는다. 반영하고 나면 양쪽이 같아져 색이 필요 없다.

---

B-2. 프로그램 정보 창 (2026-09-27, 완료)

지시서의 "정할 것"을 물어 정했다(사용자 결정 2026-09-27).

• 넣을 것: 기본 4가지(프로그램 이름 · 버전 · 빌드 날짜 · 만든 사람) + 사내 문의처.
• 버전 출처: MergeHub.csproj 의 <Version> 을 실행 파일에서 읽는다. 12차 = 0.12.0.

어떻게 만들었나

값	어디서
이름 · 만든 곳	어셈블리의 Product(MergeHub) · Company(UbiSam) — csproj 에 적는다
버전	어셈블리 버전. 뒤가 0 인 자리는 떼고 적는다(0.12.0.0 → 0.12)
빌드 날짜	csproj 가 빌드할 때 박아 둔 값(AssemblyMetadata "BuildDate")
만든 사람 · 문의처	설정 프로그램 정보 > 만든 사람 · 사내 문의처. 비우면 만든 사람은 회사 이름, 문의처는 "적혀 있지 않습니다"

빌드 날짜를 어셈블리에 박는 까닭 — 실행 파일(PE) 머리의 시각 자리를 읽어 보니 요즘 SDK 는 결정적 빌드라 그 자리에 내용 해시가 들어간다(날짜로 읽으면 2100년 같은 값). 그래서 csproj 에서 빌드 시각을 박고, 못 찾을 때만 PE 시각 → 파일 수정 시각 순으로 물러난다(ProgramInfoReader.ChooseBuildDate). 파일 수정 시각을 첫째로 두지 않는 까닭은 복사 · 압축 풀기로 바뀌기 때문이다.

창은 [단축키] 옆 [정보] 단추로 연다. 단축키 창과 같은 규칙 — 이미 떠 있으면 새로 띄우지 않고 앞으로 가져온다. [정보 복사] 로 네 줄을 그대로 클립보드에 담는다(결함을 알릴 때 첫 질문이 늘 "어느 버전이냐" 라서).

화면으로 확인한 것

판정 기준	결과
버전이 실제 실행 파일 값과 같다	창 0.12 ↔ MergeHub.dll 어셈블리 버전 0.12.0.0
빌드 날짜가 실제 값과 같다	창 2026-09-27 19:51 ↔ 실행 파일에 박힌 BuildDate 2026-09-27 19:51
창을 닫아도 화면 상태가 그대로다	닫기 전후 화면 같음(BASE · LOCAL 칸 · 선택 줄 · ACTIONS 상태 그대로)
설정에서 받은 값	만든 사람 · 문의처를 적으니 그대로 보이고, 비우면 회사 이름 · 안내 글

하네스

AboutTest 28건 새로 · 실패 0 — 버전 글 5 · PE 시각 읽기 9 · 빌드 날짜 고르기 4 · 적혀 있지 않은 칸 4 · 실제 실행 파일 대조 5(버전 · 박힌 날짜 · 창에 적을 값 한 벌 · 문의처 빈칸)

남긴 것

• 만든 사람 · 사내 문의처는 비워 두었다. 사람 이름 · 연락처는 지어낼 값이 아니다 - 설정 > MergeHub > 프로그램 정보 에서 적으면 그때부터 창에 나온다.
• 버전은 차수에 맞춰 손으로 올린다(12차 = 0.12.0). 올리는 자리는 csproj 한 곳이다.

B-3. 칸 아래에 무엇이 달라졌는지 (2026-09-27, 완료)

무엇이 문제였나

요약이 창 맨 아래 상태 줄 한 곳에만 있었다("총 7줄 · 남은 차이 3줄"). 칸이 둘 · 넷이 되면서 이 칸에 몇 줄이 있고 저쪽과 무엇이 다른가는 눈으로 세야 했다.

어떻게 고쳤나

• 칸마다 한 줄을 칸 아래에 붙였다 — 6줄 · 추가 1 · 삭제 1 · 수정 1. 다른 것이 없으면 6줄 · 같음, 0 인 칸은 아예 적지 않는다(0 을 늘어놓으면 읽을 것만 는다).
• 가운데(칸 사이 틈) 아래에 진행 — 위에 3 / 7(몇 번째 차이를 보고 있나), 아래에 남은 2(아직 다른 줄). 틈이 48 DIP 라 두 줄로 짧게 적는다. 남은 것이 없으면 아랫줄은 비운다.
• 세는 규칙은 Services/PaneSummary.cs(새로 둠)에 모았다.

칸을 기준으로 읽는다 — 추가 는 이 칸에만 있는 줄, 삭제 는 저쪽에는 있는데 이 칸에 없는 줄, 수정 은 양쪽에 있고 글이 다른 줄이다. 그래서 두 칸의 추가 · 삭제는 서로 거울이 된다. 무시 규칙에 걸린 줄과 우리가 넣은 머지 주석은 차이로 세지 않는다(화면 색 · 차이 이동과 같은 기준) — 다만 줄 수에는 들어간다(파일에 있는 줄이므로).

3분할에서는 네 칸 모두 BASE(공통 조상)와 견준다 — "누가 무엇을 고쳤나" 가 그 화면에서 읽어야 할 것이라서다. BASE 칸 자신은 견줄 것이 없어 4줄 · 기준 이라고만 적는다.

화면으로 확인한 것

판정 기준	결과
반영 · 되돌리기 · 저장마다 숫자가 따라간다	반영 전 6줄 · 추가 1 · 삭제 1 · 수정 1(양쪽) · 남은 3 → [>] 하나 → 오른쪽 8줄 · 추가 1 · 수정 1 · 왼쪽 6줄 · 삭제 1 · 수정 1 · 남은 2 → Undo → 처음 값 그대로
3분할에서도 칸마다 맞는 숫자	LOCAL(Mine) 4줄 · 수정 1 · BASE 4줄 · 기준 · REMOTE(Theirs) 4줄 · 수정 1 · MERGED 4줄 · 수정 1 · 가운데 - / 1 · 남은 1
긴 파일에서 느려지지 않는다	5만 줄 × 두 칸 × 네 번 = 22ms(한 번에 3ms 남짓). 목록을 한 번 훑을 뿐 파일을 다시 읽지 않는다

하네스

SummaryTest 25건 새로 · 실패 0 — 두 칸 요약 7 · 다른 것이 없을 때 4 · 세지 않는 줄 3 · 세 칸(BASE 기준) 5 · 가운데 진행 5 · 긴 파일 1.

남긴 것

• 맨 아래 상태 줄의 "파일 전체" 요약은 그대로 둔다 — 칸 요약과 다른 값이다(전체 줄 수 · 남은 차이 · 편집 건수).
• 가운데 진행은 두 줄뿐이다. 틈을 넓히면 더 적을 수 있지만, 틈은 잇는 선(11차 F-10)의 자리라 좁게 두었다.

C-2. 플랫폼 탭 줄 크기 줄이기 (2026-09-28, 완료 · 배포됨)

플랫폼(D:\Sorce\ubsrepo) 쪽이라 모든 사내 프로그램에 함께 간다. 지시서 원칙대로 코드와 값은 다 만들고 배포는 사용자 확인 뒤에 한다 — 아래 "배포" 참고.

무엇을 얼마나 줄였나

Themes/ShellStyles.xaml 의 Ubisam.Style.SidebarItem.Horizontal(하단 탭 줄 항목) 한 곳이다.

값	전	후
위아래 여백	13 / 14	9 / 10
아이콘	22×22	20×20
아이콘 아래 틈	7	5
글자	13.5	12.5
항목 높이(DIP)	74	61

값으로 잰 것

2560×1600 · 배율 150% · 셸 배율 1.2 에서 실제 화면 픽셀로 쟀다.

	전	후
탭 줄 높이	133px	109px (−24px, −18%)
파일 비교 코드 칸 높이	1,081px	1,105px
코드 줄 수(줄 높이 23px)	47줄	48줄 (+1)

배율 1.2 기준으로는 89 → 73px 이다(사용자가 말한 "95px" 과 같은 자리 - 재는 방법에 따라 테두리 · 밑줄이 붙는다).

글자 · 아이콘이 작아졌지만 한글 라벨(폴더 비교 · 파일 비교 · 화면 잠금 · 바탕화면 · 종료)은 잘리지 않고, 선택 밑줄 · 탭 접기 띠 · 오른쪽 동작 항목도 그대로다(화면 확인).

배포

이 항목만 빌드하면 D:\UbisamPlatform\bin 에 바로 반영된다. 처음에는 배포본을 백업해 두고 잠깐 바꿔치기해서 시험하고 되돌렸는데, 그 뒤 새 플랫폼(D:\Sorce\ubsrepo)을 빌드하면서 함께 나갔다.

• 영향: 이 플랫폼으로 만든 모든 프로그램의 하단 탭 줄이 함께 작아진다. 기능 · 배치는 그대로고 높이만 준다.
• 배포 확인 (2026-09-28): 배포본 UbisamBase.Core.dll 이 지금 소스의 빌드 결과와 해시가 같고(BA27EE48…, 738,304바이트, 04:09), 실제로 켜서 잰 하단 탭 줄이 111px · 항목 109px(배율 150% 기준 72.7 DIP)로 "후" 값과 맞았다. 앞서 적었던 "지금 배포 폴더에는 예전 것이 그대로" 는 그 뒤 빌드로 낡은 글이 되어 고쳤다.

F-1. 하단 탭에 메모장 자리 (2026-09-28, 완료)

사용자가 정한 것 — 메모 + 파일 열기 둘 다, 저장 단추 없이 계속 남는다, 이름은 메모 1 · 메모 2 번호만, 편집기는 줄 번호 · 글자 크기 · 줄바꿈 + 찾기/바꾸기.

무엇을 만들었나

• Services/Memos.cs — Memo(한 장) · MemoBook(번호 · 이름 · 넘기기 · 닫기, 계산만) · MemoStore(보관, {설정 폴더}\Memo\).
• ViewModels/MemoViewModel.cs — 새 메모 · 파일 열기 · 저장 · 다른 이름으로 · 닫기 · 자동 보관 · 되살리기.
• Views/MemoView.xaml(.cs) — 동작 한 줄 · 메모 탭 줄 · 찾기/바꾸기 줄 · 줄 번호 편집기 · 아래 상태 줄.
• AppSetup — 하단 탭 맨 뒤에 넣었다. 앞 세 탭의 차례가 바뀌면 손버릇도 바뀐다.

문서 탭(12차 E-2)과 같은 모양을 쓴다 — 탭 줄 · 저장 안 한 가운뎃점 · Ctrl+Tab · 가운데 단추로 닫기. 두 화면이 서로 다르게 움직이면 배우는 것이 둘이 된다.

메모는 문서 탭과 달리 글을 스스로 들고 있다 — 메모는 원래 작은 글이고, 이름 없는 메모에는 다시 읽어 올 파일 자체가 없다.

하네스

MemoTest 69건 통과 — 번호 매기기(빈 번호 다시 쓰기) · 파일 이름 겹칠 때 폴더 덧붙이기 · 같은 파일 두 장 금지 · 이름 붙이기 · 넘기기 · 닫기 자리 · 떠 있는 장 표시 · 글로 옮기고 되읽기(빈칸 · 한글 · UNC) · 파일로 쓰고 되읽기 · 옛 글 파일 치우기 · 되살려 담기.

화면으로 확인 (값)

확인	값
세 장 만들어 각각 쓰기	메모 1 메모 2 메모 3 · 가운뎃점 3개 · 글이 섞이지 않음
손 멈춘 뒤	보관본 01.txt 02.txt 03.txt 목록.txt
강제 종료 → 다시 켜기	세 장이 차례 · 글 그대로(저장 단추를 누른 적이 없다)
찾기/바꾸기	Ctrl+F 로 펴짐 · 사과→포도 모두 바꾸기 3곳
닫기	고친 메모는 세 갈래로 물음 · [취소] 면 그대로 3장 · [저장하지 않고 닫기] 면 2장 · 빈 메모는 묻지 않음
줄 번호	40줄에서 번호 40개, 글과 한 줄씩 맞음
다른 탭	폴더 비교 · 파일 비교 그대로 · 탭을 오가도 메모 글 40줄 그대로

하네스 29벌 1,934건 통과 · 실패 0, 화면 여덟 벌 모두 통과(빌드 경고 0 · 오류 0).

화면을 보고 고친 세 가지 (사용자 보고)

(가) 다른 탭에 갔다 오면 메모 글이 비어 보였다. 탭을 오가면 화면이 다시 만들어지는데 그때 편집기가 잠깐 비어 있다. 그 틈에 글을 거두면 빈 글로 메모를 덮어썼다. 편집기가 지금 어느 장을 싣고 있는지(_shown)를 두고, 맞지 않으면 거두지 않게 했다.

(나) 줄 번호와 글이 어긋났다. 줄 번호를 TextBlock 으로 그렸더니 줄 높이가 조금씩 달라 아래로 갈수록 벌어졌다. 편집기와 같은 종류(TextBox) 로 바꾸고 글꼴 · 크기 · 여백을 같은 값으로 두니 같은 자로 줄을 잰다.

(다) 글이 칸 한가운데에서 시작했다. 플랫폼 입력 칸 스타일이 글 칸(PART_ContentHost)을 세로 가운데에 붙박아 둔다 — 한 줄짜리 칸을 겨냥한 값이다. VerticalContentAlignment 로는 안 풀려(템플릿 안에 박힌 값) 그 칸을 직접 늘려 맨 위부터 쓰게 했다.

시험 도구

시험 스크립트가 변수 이름을 $keep 로 써서 라이브러리의 $Keep(되돌릴 설정 파일 목록)을 덮어쓰고 있었다 — 그래서 시험이 끝나도 설정이 안 돌아왔다(두 번 겪고 나서야 찾았다). 이름을 갈랐다. 묻는 창을 찾는 도구도 단추 이름을 저장하지 않고 계속 로 못 박아 두어, 말이 다른 창(저장하지 않고 닫기)을 못 알아봤다 — 앞부분만 맞춰 보게 했다.

D-1. 폴더 비교 위쪽을 한 줄로 · 옵션은 서랍으로 (2026-09-28, 완료)

먼저 재현 (화면, 값)

위쪽이 먹던 높이	305px (배율 150% 기준 203 DIP) · 네 줄
무엇이 있었나	① 경로 두 개 + 최근 ② 빠른 비교 · 하위 폴더 · 보기 · 포함 · 제외 · [비교] · [취소] ③ 폴더 안 찾기 한 벌 ④ 색 구분 범례

비교하기 전에도 네 줄이 그대로 있었고, 자주 쓰는 [비교] 는 옵션 줄 끝에 묻혀 있었다.

고친 것

• 위 한 줄: […] 왼쪽 경로 ⇆ […] 오른쪽 경로 [최근▾] 켠 옵션 [비교] [취소] [옵션 ▾]
  • 폴더 고르기는 글자 대신 … 로. 경로 칸 바로 앞에 두어 어느 쪽 것인지 헷갈리지 않는다.
  • 좌우 바꾸기(⇆) 를 새로 넣었다(사용자 결정) - 반대로 견주려고 두 번 고르지 않아도 된다.
  • 최근 목록은 화살표만 남겼다.
• 옵션 서랍: 빠른 비교 · 하위 폴더 포함 · 보기 · 포함 · 제외를 [옵션 ▾] 안으로. [폴더 안 찾기] 도 여기에 뒀다.
• 켠 옵션 표시: 서랍에 넣으면 "내가 뭘 켜 뒀더라" 를 알 수 없게 된다 - 특히 제외 규칙은 켠 줄 모르고 "왜 이 파일이 안 보이지" 로 이어진다. 기본과 다른 것만 한 줄에 짧게 적는다(FolderOptionText). 기본 그대로면 아무것도 적지 않는다 - 늘 떠 있는 글은 눈에 띄지 않는다.
• 찾기: 늘 한 줄을 먹던 것을 Ctrl+F 로 부를 때만 편다. Esc · [찾기 접기] 로 접는다.
• 색 범례: 위에서 빼고 아래 상태 줄로 내렸다 - 색은 목록을 보는 동안 필요한 것이라 결과 요약 옆이 제자리다.

화면으로 확인 (값)

확인	값
위쪽 높이	305px → 77px (203 → 51 DIP, −75%)
한 줄에 있는 것	[…] ⇆ […] · 최근 · [비교] [취소] [옵션 ▾] · 켠 옵션
좌우 바꾸기	누르면 두 경로가 맞바뀌고, 다시 누르면 되돌아온다
옵션 서랍	빠른 비교 · 하위 폴더 · 보기 · 포함 · 제외 · [폴더 안 찾기] 모두 있음
켠 옵션 표시	빠른 비교를 켜면 줄에 "빠른 비교", 처음 제외 규칙이 있어 "규칙 1"
찾기	Ctrl+F 로 77 → 158px, Esc 로 다시 77px
비교	그대로 동작(전체 2개 · 다름 2 · 왼쪽만 0 · 오른쪽만 0 · 같음 0)
없어지지 않은 것	결과 내보내기 · 줄 단위 비교 · 양쪽 복사 · 양쪽 삭제 · 색 구분(아래로)
좁은 창(1920px = 1280 DIP)	여전히 77px 한 줄, [비교] · [옵션] 다 보임

하네스 FolderTest 118 → 131건(D-1 +13), 전체 28벌 1,865건 통과 · 실패 0(빌드 경고 0 · 오류 0).

화면을 보고 고친 것

[옵션 ▾] 를 ToggleButton 으로 뒀더니 플랫폼 기본 스타일이 스위치 모양이라 같은 줄의 다른 단추와 따로 놀았다. 여느 단추로 바꾸고 누를 때마다 서랍을 여닫게 했다. 최근 목록도 폭을 못 박지 않아 넓게 벌어지던 것을 고쳤다.

E-1. 꺼도 작업 내용이 남아 있게 (2026-09-28, 완료)

E-2 가 만든 보관함(탭이 사라져도 고친 글이 짝 이름으로 남는 자리)을 그대로 파일로 옮겨 적는 일이다. 새로 정할 것은 언제 쓰고 언제 되살리는가뿐이었다.

어디에 · 어떤 모양으로

{설정 폴더}\Session\MergeHub\ — 11차 F-9 백업과 다른 자리다. 백업은 "저장하기 전 파일", 이것은 "저장하지 않은 편집" 이라 뜻도 수명도 다르다.

목록.txt          차례 · 짝 경로 · 캐럿 · 스크롤 · 저장 형식 · 보고 있던 탭 · 그때 파일의 자취
01-오른쪽.txt      저장하지 않은 오른쪽 글(있을 때만)
01-왼쪽.txt        저장하지 않은 왼쪽 글(12차 B-1, 있을 때만)

• JSON 을 쓰지 않는다(최근 목록과 같은 까닭). 사람이 열어 보고 손으로 고칠 수 있고, 무엇보다 글 안에 무엇이 들었든(따옴표 · 줄바꿈 · 제어 문자) 본문을 따로 파일로 두면 탈이 없다.
• 원본 글은 담지 않는다. 파일에서 다시 읽으면 되고, 담아 두면 그 사이 파일이 바뀌었을 때 낡은 것을 보여 준다. 대신 그때 파일의 길이 · 마지막으로 쓴 때(FileStamp)만 적어 두고, 다를 때 알린다.
• 목록은 맨 나중에 쓴다 — 목록이 있다는 것이 곧 글 파일이 다 있다는 뜻이다.
• 못 읽거나 못 써도 조용히 넘어간다. 보관 때문에 프로그램이 안 켜지거나 저장이 막히면 안 된다.

언제 쓰나

때	어떻게
글자가 멈춘 뒤	2초에 한 번(DispatcherTimer). 글자마다 쓰면 큰 파일에서 걸린다
탭을 옮길 때 · 닫을 때 · 새 짝을 열 때	그 자리에서 바로 — 그 순간이 곧 끄기 직전일 수 있다
고친 것이 생기거나 없어질 때	2초 뒤에 한 번(저장하면 보관본이 빠져야 한다)

쓰는 일은 다른 실로 넘긴다(Task.Run). 지금 화면의 상태를 뜰 때 ParkCurrentTab 을 쓰지 않는다 - 그쪽은 되돌리기 목록을 글 단위로 눌러 담는데(FlattenHistory), 2초마다 이력을 주무를 까닭이 없다. 보관할 것은 글과 자리뿐이고 되돌리기 이력은 되살리지 않기로 정했다(사용자 결정).

언제 되살리나

켤 때 묻지 않고 그대로(사용자 결정). 다만 사용자가 지금 열라고 한 것이 먼저다 - 충돌 파일 열기 · git mergetool · 폴더 비교에서 고른 파일이 있으면 그것을 연다. 설정의 기본 저장소 · 기본 짝보다는 앞선다.

되살리는 것은 탭 짝 · 저장하지 않은 글 · 캐럿 · 스크롤 · 어느 탭을 보고 있었는지다. 원본 글은 파일에서 다시 읽고 그 위에 편집을 얹는다(E-2 의 ResumePendingTab 이 하던 그대로). 두 파일이 다 없어진 짝은 되살릴 자리가 없으므로 버린다.

하네스

SessionTest 65건 통과 — 글로 옮기고 되읽기(빈칸 · 한글 · UNC 경로, 알아볼 수 없는 줄 건너뛰기) · 파일로 쓰고 되읽기 · 보관할 것이 없으면 치우기 · 고친 것 없는 줄 빼고 번호 다시 매기기 · 옛 글 파일 치우기 · 글 파일이 없어져도 넘어가기 · FileStamp · 보관함을 내주고 되받기.

화면으로 확인 (값)

두 짝을 열어 둘 다 고치고 작업 관리자로 끄듯 강제로 끝낸 뒤 다시 켰다.

확인	값
손을 멈춘 뒤	보관본 01-오른쪽.txt · 02-오른쪽.txt · 목록.txt 생김
강제 종료 뒤	보관본 그대로 남음
다시 켜면	묻지 않고 탭 2개 되살아남(alpha.cs · bravo.cs), 이름 · 차례 그대로
보고 있던 탭	bravo 의 고친 글 그대로 · 가운뎃점 2개
다른 탭	alpha 의 고친 글도 그대로 · 서로 섞이지 않음
한쪽을 저장	가운뎃점 2 → 1 · 파일에 써짐
둘 다 저장	가운뎃점 0 · 보관본이 치워짐
다시 켜면	되살릴 것 없음 · 설정의 기본 짝이 열림
원본이 그 사이 바뀌면	고친 글 되살아나고 "그 사이 파일이 바뀌었습니다 … 저장하면 바뀐 파일을 덮어씁니다" 알림

하네스 28벌 1,852건 통과 · 실패 0, 화면 여섯 벌 모두 통과(빌드 경고 0 · 오류 0).

빠르기에 대해 말할 수 있는 것과 없는 것

5,003줄(113KB) 짝에서 글자를 보내 보니 글자당 31ms 로 4줄짜리와 같았다 - 앱이 입력에 밀리지 않는다. 보관은 손을 멈춘 뒤 한 번, 다른 실에서 107KB 를 적었다.

다만 "글자를 친 뒤 화면에 보이기까지" 는 값으로 확정하지 못했다. 그것을 재려면 편집기 글을 UIA 로 읽어야 하는데, 5,003줄 창에서는 그 읽기가 타이핑보다 훨씬 오래 걸려(한 번에 수 초) 값이 통째로 오염된다. 재는 법을 따로 마련해야 한다.

시험 도구도 함께 고쳤다

E-1 이 도니 지난 시험이 남긴 "저장하지 않은 편집" 이 다음 시험에서 되살아나 화면이 달라졌다 (e3-verify 가 왼쪽 7줄 대신 14줄을 봤다). 시험마다 보관 자리를 치우고 시작해 끝에 되돌리도록 Backup-Cfg · Restore-Cfg 를 고쳤다 - 기능이 제대로 도는 증거이기도 하다.

B-1 을 쓰다 나온 것 (2) - [<] 단추가 있는 줄만 글이 밀린다 (2026-09-28, 사용자 보고)

사용자가 그림으로 짚어 준 것이 이것이었다. 아래 "왼쪽 줄 번호" 건은 이것을 쫓다 따로 찾은 다른 흠이다.

먼저 재현 (화면, 값)

[<] 단추가 보이는 줄만 코드가 오른쪽으로 밀려, 같은 칸 안에서도 줄마다 글 시작 자리가 달랐다.

BASE                                LOCAL
  01  class Axis                      01  class Axis
  02  {                               02  {
< 03      int speed = 100;            03 >     int speed = 200;      ← 밀림
< 04      // left only line           04  void Home() { }
  05  void Home() { }                 05 > <     void Stop() { }     ← 더 밀림
  06  }                               06  }

오른쪽 칸은 단추가 하나 늘 때마다 한 칸씩 더 밀렸다.

까닭

단추가 든 칸의 폭이 Auto 였다. 단추가 안 보이는 줄에서는 0 이 되고 보이는 줄에서는 단추 폭만큼 벌어지니, 그 줄만 뒤 칸이 통째로 오른쪽으로 밀린다. Visibility="Collapsed" 는 자리까지 없앤다 - 자리를 지키려면 칸 폭이 고정이어야 한다.

• BASE 는 [<] 가 맨 앞 칸(Auto)이라 번호까지 함께 밀렸다.
• LOCAL 은 [<] 가 번호 뒤 칸(Auto)이라 코드만 밀렸다.

고친 것

GutterBothWaysWidth 를 두고 두 칸이 같은 값을 쓴다. 화면이 모드에 따라 0 ↔ 단추 폭으로 갈아 끼운다(ApplyGutterReserve).

• 두 파일 비교: 단추 폭만큼 늘 잡아 둔다 - 단추가 없는 줄도 같은 자리에서 글이 시작한다.
• Git 모드 · 네 칸: [<] 가 아예 없으므로 0 - 여백이 예전 그대로라 코드 칸이 좁아지지 않는다.
• 편집기 여백(EditorGutterMargin)도 같은 값만큼 민다. 투명한 편집기와 아래 표시층이 어긋나면 캐럿이 글자와 다른 자리에 선다.
• 글자 크기(11차 F-5)를 바꾸면 단추 폭도 따라 바뀌므로, 잡아 두는 자리도 CodeFontMetrics 한 벌에서 나온다.

화면으로 확인 (값)

확인	값
두 파일 비교 BASE	여섯 줄 모두 x=137 (전에는 단추 줄만 달랐다)
두 파일 비교 LOCAL	여섯 줄 모두 x=1283
글자 크기 키운 뒤	모두 한 x(147)
Git 모드(회귀)	모두 한 x(459) · 여백 예전 그대로

남겨 둔 것

BASE 줄 끝의 [>](LOCAL 에서 지운 줄 되살리기, 11차 F-10)는 아직 Auto 다. 이것은 왼쪽 가장자리를 밀지 않고 오른쪽에서 코드 칸을 조금 좁힐 뿐이라 눈에 띄지 않는다. 워드랩을 켜면 그 줄만 접히는 자리가 달라질 수 있다 - 워드랩은 기본이 꺼짐이고, 손대면 네 칸 폭을 다시 맞춰야 해서 이번에는 두었다.

B-1 을 쓰다 나온 것 - 왼쪽 줄 번호가 밀린다 (2026-09-28, 사용자 보고)

먼저 재현 (화면, 값)

왼쪽 6줄 · 오른쪽 8줄(오른쪽에만 있는 줄 둘)로 열고, 오른쪽에만 있는 줄을 [<] 로 왼쪽에 넣었다.

	왼쪽 칸 번호
연 직후	01 02 03 04 05 06
한 줄 넣은 뒤	01 02 · 03 04 05 06
두 줄 넣은 뒤	01 02 · 03 04 05 · 06

· 는 번호가 비어 있는 줄이다. 왼쪽 파일은 8줄이 됐는데 번호는 6까지만 있고, 새로 들어간 줄에는 번호가 없다. 저장하면 8줄로 써지므로 "몇 번째 줄을 고쳤나" 를 번호로 짚을 수가 없다.

까닭

8차 B-3 에서 만든 RenumberMerged 는 오른쪽(MERGED) 칸만 다시 번호를 맨다. 그때는 BASE 가 얼어 있었다. 12차 B-1 로 왼쪽에도 반영할 수 있게 되면서 왼쪽 줄이 늘고 줄게 됐는데, 왼쪽은 정렬기가 처음 준 번호를 그대로 달고 있었다. MergeLine.BaseNumber 의 설명에는 이미 "이제 두 파일 비교에서는 … 번호도 따라 바뀐다" 고 적혀 있었지만 실제로 다시 매기는 자리가 없었다 - 적어 둔 뜻과 코드가 어긋나 있었다.

고친 것

RenumberBase 를 RenumberMerged 옆에 두고, 그릴 때마다(UpdateSummaries) 왼쪽에 있는 줄만 1부터 다시 맨다.

• 두 파일 비교에서만(BothWays). Git 모드 · 네 칸의 BASE 는 지난 커밋 · 공통 조상이라 고칠 수 없고, 그때 번호는 그 파일의 번호이므로 건드리면 안 된다.
• "머지 반영함" 표시의 열쇠를 함께 옮긴다. 그 표시는 BASE 줄 번호로 붙들려 있어서(_appliedBaseNumbers), 번호만 바꾸면 규칙을 한 번 건드리는 순간 엉뚱한 줄이 반영함으로 칠해진다. 번호가 실제로 달라질 때만 옛 번호 → 새 번호로 옮겨 담는다(안 바뀌면 손대지 않는다 - 연 직후가 그렇다).

화면으로 확인 (값)

왼쪽 7줄(왼쪽에만 있는 줄 하나) · 오른쪽 8줄로 다시 잡고 봤다.

확인	값
연 직후	01 … 07 · 왼쪽 줄 수 = 파일 줄 수 7
오른쪽 줄 둘을 왼쪽에 넣음	01 … 09 로 이어짐 · 왼쪽 9줄
왼쪽에만 있는 줄을 반영	번호가 이어짐 · 번호 빠진 줄 0
되돌리기	번호가 이어짐 · 번호 빠진 줄 0
왼쪽 저장	저장한 파일 9줄 = 칸의 끝 번호 09 · 넣은 줄이 파일에 있음
Git 모드(회귀)	BASE 번호 그대로 이어짐

하네스 27벌 1,787건 통과 · 실패 0, E-2 화면 세 벌도 그대로 통과(빌드 경고 0 · 오류 0).

아직 확인하지 못한 것

"왼쪽에만 있는 줄을 [<] 로 빼면 왼쪽 줄 수가 하나 준다" 는 것은 값으로 확정하지 못했다. 따로 열어 한 번만 누르면 잘 빠지는데(3줄 → 2줄 확인), 다른 반영을 몇 번 한 뒤에 같은 것을 하면 시험 도구가 읽은 줄 칸이 낡아 옆 줄 단추를 누르는 일이 생겨 값이 흔들렸다. 번호 쪽 불변식(늘 1부터 이어지고 빠진 번호가 없다)은 어느 경우에도 지켜졌다. 빼는 길 자체가 제대로 도는지는 따로 봐야 한다.

E-2. 여러 짝을 동시에 (문서 탭) (2026-09-28, 완료)

먼저 재현 (화면, 값)

단계	값
짝 A 열기	오른쪽 15줄 · public int Version = 2;
고치고 저장하지 않음	16줄 · 마지막 줄 // E2-MARK-ALPHA · [오른쪽 저장 ▶] 켜짐 · 아래 줄 "남은 차이 3줄 · 편집 1건"
다른 짝 열기	모달 "a-right.cs 에 저장하지 않은 편집이 있습니다" · [취소] [저장하지 않고 계속] [저장하고 계속]
[저장하지 않고 계속]	화면이 15줄로 돌아감 — 고친 글이 사라졌다(원본 파일은 안 바뀜)

한 번에 한 짝만 들기 때문이다. 짝을 바꾸는 순간 앞 짝의 편집 글이 갈 곳이 없어서 묻고, 버리면 그대로 사라진다.

고친 방식

탭마다 HomeViewModel 을 따로 만들지 않았다. 이 화면은 GitWorkspace 의 여러 사건과 한 자리짜리 약속 (ConfirmDiscardEdits · ConfirmLeaveCommit)에 물려 있다 — 여럿을 만들면 같은 사건에 여러 화면이 동시에 반응하고 약속은 마지막 것만 남는다. 그래서 화면은 하나로 두고 탭이 편집만 맡는다.

• Services/DocTabs.cs (새로 만듦) — 계산만 한다(화면 없이 검사할 수 있다).
  • DocTab : 짝 하나 · 이름(Title) · 저장 안 한 표시(IsDirty) · 떠 있는지(IsCurrent) · 맡아 둔 편집(Parked)
  • DocTabState : 파일에 없는 것만 담는다 — 고친 글 · 왼쪽 글(B-1) · 되돌리기/다시하기 이력 · 두 기준점 · 캐럿 자리 · 스크롤 행 · 저장 형식. 파일에서 다시 읽을 수 있는 것(원본 글 · 줄 정렬)은 담지 않는다 — 담아 두면 파일이 그 사이 바뀌었을 때 낡은 것을 보여 준다.
  • 이름 짓기 : 파일 이름, 양쪽이 다르면 왼 ↔ 오(최근 목록 RecentPair.Label 과 같은 규칙). 같은 이름이 겹치면 갈릴 때까지 위 폴더를 한 겹씩 덧붙인다(Unit0.cs 가 여러 폴더에 있는 사내 소스 때문).
  • 보관함 : 탭을 닫거나 짝을 바꿔 탭 자체가 사라져도 고친 글은 짝 이름으로 남는다(50개). ◀ ▶ 로 훑다가 앞 파일로 돌아왔을 때 고친 것이 사라지면 그것이 곧 E-2 가 없애려던 일이다. E-1(껐다 켜도 남는 편집)은 이 보관함을 파일로 옮겨 적으면 된다.
  • 상한 20 : 넘으면 저장할 것 없는 탭 가운데 가장 오래 안 본 것을 닫는다. 고친 탭은 절대 닫지 않는다(넘겨서라도 연다).
• ViewModels/HomeViewModel.Tabs.cs (새로 만듦) — 화면과 이어 주는 자리. ParkCurrentTab(맡기기) · ResumePendingTab(되살리기) · OpenPairInTab · EnsureTabForCurrentPair · GoToTab · 명령 네 개(ActivateTab · CloseTab · NextTab · PreviousTab).
• HomeViewModel.cs 세 군데만 고쳤다.
  • OnPlainCompareRequested : 두 파일 비교끼리 짝을 바꿀 때 묻지 않는다. Git · 네 칸에서 넘어올 때는 그대로 묻는다.
  • MoveFile(◀ ▶) : 묻지 않고 지금 탭의 짝만 바꾼다(사용자 결정 — 탭이 늘지 않아 목록을 훑기 좋다).
  • LoadPlainFilesAsync : 맨 앞에서 EnsureTabForCurrentPair, 맨 끝(파일을 다 읽은 뒤)에서 ResumePendingTab.
• HomeView.xaml : 맨 위에 문서 탭 줄. ItemsControl 이 아니라 ListBox 다 — ItemsControl 은 UIA 에 "컨트롤" 로 보이지 않아 화면 시험이 탭 줄을 아예 못 읽고, 키로 옮기는 것도 공짜로 얻을 수 없다. 고르기가 곧 탭 옮기기다. 탭이 둘 이상일 때만 보인다(한 짝만 볼 때 줄을 낭비하지 않는다).
• 단축키 : Ctrl+Tab · Ctrl+Shift+Tab · Ctrl+W(notepad++ · 브라우저와 같은 손버릇). 가운데 단추로도 닫힌다.
• 닫을 때 · 옮길 때 묻지 않는다 — 글이 보관함에 남기 때문이다.

원본 파일이 그 사이 바뀌었으면

되살리고 알린다. 사용자가 아까운 것은 자기가 고친 글이다. "파일을 연 시점"은 새로 읽은 글로 두어 [전체 되돌리기]가 지금 파일로 가고, 고친 글은 편집으로 남는다 — 그래야 어느 쪽도 잃지 않는다. 알림으로 "저장하면 바뀐 파일을 덮어씁니다" 를 말해 준다.

화면을 켜 놓고 보다 고친 두 가지 (2026-09-28)

만들어 놓고 실제 설정으로 켜서 눈으로 보다 찾았다. 둘 다 사용자가 고르게 했다.

(가) 켜자마자 가운뎃점이 붙었다. 설정에 C# 중괄호 맞춤이 켜져 있으면 .cs 를 여는 것만으로 "저장할 것 있음" 이 되어, 손대지도 않은 탭에 점이 붙었다. 늘 붙어 있는 점은 뜻이 없다. "저장하지 않은 편집이 있습니다" 를 묻는 자리(WillAskBeforeDiscard)는 이미 스타일 맞춤만 바뀐 것을 빼고 세고 있었다 — 점도 같은 기준(HasTypedEdits)을 쓰게 했다. 맡길 때도 같다(스타일로만 바뀐 글은 맡기지 않는다 — 다시 열면 똑같이 만들어진다).

(나) 긴 짝 이름이 탭 줄을 많이 먹었다. WeldController_기준.cs ↔ WeldController_내작업.cs 하나가 421px(280 DIP), 탭 줄의 1/9 를 차지하고 뒤가 잘려 WeldController_내작... 으로 보였다. 사내 소스에는 이름이 살짝만 다른 짝이 흔하다. 양쪽이 같은 부분은 한 번만 적게 했다(사용자 결정).

	전	후
탭 이름	WeldController_기준.cs ↔ WeldController_내작...	WeldController_기준 ↔ 내작업.cs
탭 폭	421px	288px (−32%, 잘림 없음)

뒤쪽은 확장자일 때만 접는다. 글자 단위로 같은 꼬리를 세면 낱말 가운데서 잘린다 — a-left.cs ↔ a-right.cs 에서 t.cs 가 같다고 a-lef ↔ right.cs 가 되어 읽을 수 없었다(하네스에서 걸렸다). 앞이 한 글자만 같은 것은 접지 않는다(abc.cs ↔ axy.cs 는 그대로).

하네스

DocTabTest 106건 통과 — 이름 짓기(겹칠 때 폴더 덧붙이기 · 한쪽만 있는 짝) · 저장 표시 · 같은 짝 두 탭 금지 · Replace · 닫기 자리 이동 · Ctrl+Tab 돌기 · 상한 · 보관함(짝 바꿔도 · 닫아도 · 모두 닫아도 · 치워도 되살아남 · 50개 한도) · 같은 부분 접기(사내 소스 짝 · 앞뒤가 다 겹치는 짝 · 한 글자만 같으면 접지 않음 · 폴더까지 겹치는 경우).

화면으로 확인 (값)

확인	값
폴더 비교에서 두 번 누르기	alpha.cs → 탭 1개(줄 안 보임) · bravo.cs → 탭 2개 alpha.cs | bravo.cs
짝을 바꿀 때	묻는 창이 뜨지 않는다
저장 안 한 표시	alpha 만 고쳤을 때 가운뎃점 1개 → 둘 다 고치면 2개
탭을 오간 뒤	alpha 15줄(E2-MARK-ALPHA 그대로) · bravo 15줄(E2-MARK-BRAVO 그대로) · 서로 섞이지 않음
되돌리기	Undo 가 그 탭 것만 되돌리고 Redo 로 돌아옴 · 다른 탭은 그대로
Ctrl+Tab	alpha 로 넘어가고 그 탭의 편집도 그대로
저장	그 탭의 가운뎃점만 사라짐(2 → 1) · 저장 단추 꺼짐 · 파일에 실제로 써짐 · 다른 파일은 안 바뀜
탭 닫기	묻지 않음 · 한 짝만 남자 탭 줄이 사라짐 · 오류 글 0

회귀로 함께 본 것.

• ◀ ▶ 로 훑기 : 1 / 2 → 2 / 2 → 1 / 2, 탭이 늘지 않고(0개 = 줄 안 보임) 돌아오니 고친 글 그대로(15줄).
• 켤 때 저절로 열리는 짝(설정의 기본 짝)에서 고친 것도 탭이 맡는다 — EnsureTabForCurrentPair 를 넣기 전에는 그 짝만 탭이 없어 편집이 사라졌다(화면에서 찾아 고쳤다).
• Git 모드로 넘어갈 때는 여전히 묻는다(탭이 맡을 수 없는 자리). 데모 전환은 예전부터 두 번 묻는다 — 화면이 한 번(데모 폴더를 바꿉니다), GitWorkspace 가 한 번(Git 작업을 합니다: 데모 저장소 열기). 이번 변경과 무관하다.
• 하네스 전체 27벌 1,777건 통과 · 실패 0(빌드 경고 0 · 오류 0).

시험 도구를 런처에 맞추기 (2026-09-28)

새 플랫폼부터 프로그램을 UbisamBase.Launcher.exe 로 켜고, 런처가 셸을 같은 프로세스 안에 올린다 (별도 프로세스로 띄우면 디버거가 안 붙어서 소비 프로젝트 중단점이 안 걸린다 — 런처 주석). 그래서 창을 든 프로세스 이름이 UbisamBase.Shell 에서 UbisamBase.Launcher 로 바뀌었고, 예전 이름만 찾던 화면 시험 도구가 전부 "창이 안 뜬다" 로 멈춰 있었다.

	전	후
켜는 파일	UbisamBase.Shell.exe	UbisamBase.Launcher.exe (없으면 셸로 되돌아감)
창 주인 프로세스	UbisamBase.Shell 만	UbisamBase.Launcher · UbisamBase.Shell 둘 다

• a2lib.ps1 에 Shell-Procs · Shell-Proc · Stop-App 을 두고 Start-App · Get-Win 이 그것을 쓰게 했다. 런처가 업데이트 진행 창(제목 없는 창)을 먼저 띄우는 경우를 대비해 제목이 있는 창을 먼저 고른다.
• 스크립트 76개 · 156곳을 함께 고쳤다(옛 이름만 찾던 Get-Process, 지금 빌드 자리를 가리키던 실행 경로). 고치기 전 파일은 스크래치패드 _prelauncher\ 에 그대로 뒀다.
• 확인: 문법 검사 187개 통과, 끄기 → 켜기 → 창 찾기 → 네 탭 넘기기 → 단추 찾기 → 끄기까지 실제로 돌았고, 설정 · 창 자리 네 파일은 해시 그대로 되돌렸다.
• 시험 도구일 뿐 제품 코드는 바뀌지 않았다.

여기까지의 하네스 (2026-09-27)

A-1 · A-2 · B-1 · B-2 · B-3 을 넣은 뒤 30벌 1,830건 통과 · 실패 0(빌드 경고 0 · 오류 0).

• 새로 만든 것: TwoWayTest 29건(B-1) · AboutTest 28건(B-2) · SummaryTest 25건(B-3)
• 늘어난 것: FolderTest 88 → 118건(A-1 +23 · A-2 +7)
• 나머지 26벌은 그대로 통과 — MergeLine.HasBase · BaseNumber 를 바뀔 수 있는 값으로 바꾼 것이 정렬 · 이동 · 3-Way · 저장 길에 영향을 주지 않았다는 뜻이다(MergeSaveTest 350 · NoteTest 93 · MemberTest 83 포함).