RobotAutomationDevelopment-Dept/Ubisam-MergeTool

ksj09406 c870eacfe8 작업지시-4차에 C 묶음(화면 구성 정리) 추가

경로 중복 · 하단 정보 흩어짐 · Git 원격 블록 접기 · 색 구분 범례 · ACTIONS 칸 나누기 다섯 가지.
3-Way 원본 칸 접기는 행 잠금을 건드리는 같은 성격이라 B-2 에 묶었다.

2026-09-09 16:01:41 +09:00

16 KiB

Raw Blame History

작업 지시 — MergeHub 4차 (로컬 머지툴 사용성)

대상: D:\Sorce\MergeTool\MergeHub (플러그인) · D:\Sorce\MergeTool\UbisamPlatform (셸) 전제: 1~3차 지시서는 모두 끝났다(진행상황.md). 이 지시서는 기능을 늘리는 것이 아니라 매일 쓰는 사람의 걸림돌을 없애는 것이 목적이다. 이 도구는 사내 로컬 환경에서 쓰는 머지툴이 우선이므로, 서버·협업 기능보다 "혼자 앉아서 파일 두 개 견주는 일"이 빨라지는 쪽을 먼저 본다.

공통 규칙

A → B → C 순서로 진행한다. A 는 작업한 것이 사라지는 문제라 제일 먼저다.

C(화면 구성)는 서로 얽히지 않아 순서를 바꿔도 되지만, 기능이 자리를 잡은 뒤에 손대는 편이 손이 덜 간다.
항목 하나를 끝낼 때마다 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다. 전부 끝내고 한 번에 보고하지 않는다.
항목 하나가 끝나면 doc/진행상황.md 의 대기/진행/완료를 갱신하고 로컬 커밋한다. 커밋 메시지는 한국어 한 줄.
푸쉬하지 않는다. 원격 저장소가 생기기 전까지 .git 에만 쌓아 둔다.
기존 검사 하네스 16벌(514건)은 계속 통과해야 한다. 로직을 건드리면 테스트를 먼저 늘린다.
빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 파일 잠금으로 빌드가 실패하므로 UbisamBase.Shell 을 먼저 종료한다.
플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고 doc/history/changelog.md 에 남긴다.
아래 넷은 지금 코드에 아예 없다(2026-09-09 확인). 있는 것을 고치는 게 아니라 새로 만드는 일이다 - 최근 목록 · 같은 줄 접기 · 다음 파일 이동 · 외부 편집기 호출.

A. 먼저 — 작업한 것이 사라지는 문제

A-1. 저장하지 않은 편집이 말없이 사라진다

증상: 파일 비교에서 LOCAL 을 고친 뒤 저장하지 않은 채 다른 파일을 열면 고치던 내용이 그대로 없어진다. 묻지도 않고 알리지도 않는다. 머지툴에서 이건 기능 부족이 아니라 결함에 가깝다.
먼저 어느 길로 들어와야 사라지는지 전부 찾아 목록으로 보고한 뒤 고친다. 최소한 이 길들을 본다. HomeViewModel.OnPlainCompareRequested · PickLeftFile / PickRightFile · 폴더 비교에서 더블클릭 (FolderViewModel.OpenInDiffCore) · 끌어다 놓기(DropFile · RouteDroppedPaths) · 폴더 검색 결과 열기 (OpenHitCore) · Git 탭에서 다른 파일 고르기 · 데모 전환 · 3-Way 켜고 끄기.
비교 규칙을 바꾸는 길은 건드리지 않는다. ReloadLinesFrom 은 편집을 지키도록 이미 만들어져 있다. 지금 안전한 길까지 확인 창을 붙이면 규칙 하나 바꿀 때마다 창이 떠서 못 쓴다. 어느 쪽인지 먼저 확인하고 손댄다.
묻는 창은 세 갈래다 — 저장 · 저장하지 않고 계속 · 취소. 확인 창은 플랫폼 것(MessageUtil)을 쓴다.
고친 것이 없으면(HasChanges == false) 묻지 않는다. 저장 없이 넘어가도 되는 경우까지 묻는 것이 더 나쁘다.
판정 기준: LOCAL 을 한 줄 고친 뒤 위에 적은 모든 길로 다른 파일을 열면 창이 뜬다. 취소 를 누르면 고치던 내용과 화면이 그대로 남는다. 고친 것이 없으면 창이 뜨지 않는다.

A-2. 내보낸 보고서에 만든 사람이 없다

증상: 결과 내보내기 로 뽑은 파일 머리글에 만든 때 는 있는데 누가 뽑았는지가 없다(CompareReport.Head). 남에게 보내라고 만든 기능이라 작성자가 없으면 결재나 메일에 붙였을 때 되묻게 된다.
이름은 머지 주석과 같은 자리에서 가져온다. 설정 MergeCommentAuthor → 비었으면 git config user.name → 그것도 없으면 윈도우 계정. 지금 MergeNote.Build 가 하는 판단과 같은 함수를 쓴다 - 같은 사람이 같은 화면에서 뽑았는데 주석과 보고서에 다른 이름이 찍히면 그 자체가 버그다.
파일 비교 · 폴더 비교 두 보고서 모두 해당된다.
판정 기준: 뽑은 파일 머리글에 만든 사람이 나오고, 그 이름이 반영한 줄 주석에 찍히는 이름과 같다.

B. 매일 쓰는 마찰 줄이기

B-1. 최근 비교 목록

왜 필요한가 - 같은 짝을 반복해서 연다. 경로를 매번 다시 고르는 것이 지금 제일 잦은 마찰이다.
파일 짝(왼쪽·오른쪽)과 폴더 짝을 따로 기억한다. 최근 것이 위. 상한은 10~20개.
파일 비교 · 폴더 비교 화면 위쪽에서 목록을 펼쳐 고르면 그 짝으로 바로 연다.
저장 자리는 플랫폼 설정 폴더(D:\UbisamConfig) 쪽이다. 설정 화면을 어지럽히지 않는다 - 사람이 손으로 고칠 값이 아니다. MergeHubSettings 에 넣을지 파일을 따로 둘지는 구현자가 정하되 그 까닭을 적는다.
없는 경로를 목록에서 자동으로 지우지 않는다. 네트워크 드라이브나 USB 는 잠깐 안 보일 뿐인데 지워 버리면 다시 찾아 들어가야 한다. 흐리게 보여 주고, 열려고 할 때 없다고 알린다.
판정 기준: 프로그램을 껐다 켜도 최근 짝이 남아 있고, 목록에서 하나를 고르면 두 칸이 채워지며 비교가 열린다.

B-2. 같은 줄 접기

왜 필요한가 - 3000줄짜리에 차이가 5개면 2900줄을 스크롤해서 지나간다. 읽는 값이 가장 크게 줄어드는 항목이다.
차이 앞뒤 몇 줄(기본 3줄, 설정 가능)만 남기고 그 사이의 같은 줄을 한 줄로 접는다.
접힌 자리에는 몇 줄이 접혔는지 적는다(예: 같은 줄 128개). 누르면 그 자리만 펼친다.
켜고 끄는 스위치를 둔다. 기본은 꺼짐이고 마지막 상태를 기억한다 - 처음 여는 사람이 "줄이 없어졌다"고 놀라면 안 된다.
어려운 곳을 미리 짚어 둔다. 여기서 막히면 보고하고 상의한다.
- 2-Way 두 칸, 3-Way 네 칸이 같은 자리에서 함께 접혀야 한다. 행 잠금(같은 줄이 같은 높이)이 깨지면 그 순간 머지툴이 아니다.
- 줄 번호는 접힌 뒤에도 원래 파일의 번호여야 한다. 다시 매기면 안 된다.
- 차이 이동(Alt+↑↓) · 미니맵 · 폴더 검색으로 들어온 줄 짚기가 접힌 상태에서도 맞아야 한다.
- 편집기는 투명한 TextBox 한 장이 스크롤 주인이다. 접힌 줄을 편집기에서 어떻게 다룰지가 이 항목의 핵심이다.
곁들여 — 3-Way 에서 원본 세 칸을 접는 토글도 여기서 함께 한다. 2560 화면에서 칸이 넷이면 칸당 500px 남짓이라 코드 폭이 모자란다. 대개는 MERGED 와 원본 하나만 보면 된다. 가로로 칸을 접는 일과 세로로 줄을 접는 일은 행 잠금을 건드린다는 점에서 같은 성격이라 묶는다. 화면 구성 항목(C 묶음)에 넣지 않은 까닭이 그것이다.
판정 기준: 3000줄에 차이 5군데인 파일을 열면 화면 한 장에 다섯 군데가 다 보인다. 접었다 펴도 줄 번호와 좌우 정렬이 그대로다. 3-Way 에서도 네 칸이 같은 자리에서 접힌다. 원본 칸을 접으면 MERGED 가 넓어지고, 펼치면 네 칸이 원래 자리로 돌아온다.

B-3. 폴더 비교에서 다음 다른 파일로 바로 넘어가기

왜 필요한가 - 지금은 파일 하나를 보고 폴더 탭으로 돌아갔다가 다음 파일을 다시 열어야 한다. 다른 파일이 스무 개면 이 왕복을 스무 번 한다.
파일 비교 화면에 이전 파일 · 다음 파일 을 둔다. 단축키도 함께 준다(Ctrl+PageUp · Ctrl+PageDown 을 먼저 검토).
폴더 비교에서 열었을 때만 켜진다. 그냥 파일 두 개를 연 경우에는 넘어갈 목록이 없으므로 꺼져 있어야 한다.
지금 화면에 보이는 목록 순서를 그대로 따른다. 필터로 "코드가 다른 것만" 을 걸어 뒀으면 그 안에서만 움직인다.
몇 번째인지 보여 준다(예: 3 / 27).
저장하지 않은 편집이 있으면 A-1 규칙을 그대로 탄다.
판정 기준: 폴더 비교에서 파일 하나를 열고, 폴더 탭으로 돌아가지 않고 다른 파일 전부를 차례로 훑을 수 있다.

B-4. 외부 편집기로 열기

왜 필요한가 - 크게 고칠 때는 결국 쓰던 편집기로 간다. 지금은 경로를 복사해서 직접 찾아 열어야 한다.
왼쪽·오른쪽을 각각 연다. 설정에 편집기 경로를 둔다. 비어 있으면 윈도우가 정한 기본 프로그램으로 연다 - 아무것도 설정하지 않은 사람에게도 동작해야 한다.
가능하면 지금 보고 있는 줄 번호까지 넘긴다. 편집기마다 인자가 다르므로 (Notepad++ -n<줄>, VS Code -g <파일>:<줄>) 인자 틀도 설정 값으로 둔다. 기본값은 파일 경로만.
밖에서 고치고 돌아오면 다시 읽을지 묻는다. 창이 다시 활성화될 때 파일 수정 시각을 확인하는 정도면 된다. 묻지 않고 자동으로 다시 읽으면 이쪽에서 고치던 것이 날아간다.
판정 기준: 버튼을 누르면 그 파일이 외부 편집기에서 열린다. 밖에서 고치고 돌아오면 다시 읽을지 묻고, 예 를 누르면 바뀐 내용이 반영된다.

C. 화면 구성 정리

기능을 더하는 것이 아니라 자리를 되찾는 일이다. 코드를 나란히 읽는 도구에서 가로·세로 한 줄은 그대로 읽을 수 있는 코드 양이다.

C 묶음은 서로 얽히지 않으므로 어느 것부터 해도 된다. 값이 큰 순서로 적었다.

C-1. 같은 경로가 세 군데 나온다 (파일 비교)

지금: ① 위 툴바에 기준 파일... · 내 파일... 옆의 잘린 경로 ② 패널 머리글의 BASE · 파일이름.cs ③ 그 아래 경로 상자의 전체 경로. 셋이 같은 것을 말한다.
③ 경로 상자가 패널마다 세로 40px 남짓을 먹는다. 3-Way 는 칸이 넷이라 그만큼 곱해진다.
머리글 한 줄로 합치고 전체 경로는 툴팁으로 옮긴다. 위 툴바의 잘린 경로는 읽을 수 없으므로 뺀다.
경로를 드래그해서 복사할 수 있는 것은 지킨다. 지금 읽기전용 TextBox 를 쓰는 까닭이 그것이다 (HomeView.xaml 의 경로 줄 주석 참고). 복사 방법이 사라지면 안 된다 - 대안(우클릭 복사 등)을 함께 낸다.
행 잠금을 깨지 않는다. 지금 경로 줄은 BASE·LOCAL 의 높이를 맞추려고 자리를 맞춰 둔 것이다. 줄을 없애거나 합칠 때 두(네) 칸의 01행이 여전히 같은 높이여야 한다.
판정 기준: 2-Way·3-Way 모두에서 코드가 두 줄 이상 더 보이고, 각 칸의 01행이 같은 높이에 있다. 경로 전체는 어딘가에서 여전히 읽고 복사할 수 있다.

C-2. 아래쪽 정보가 세 군데로 흩어져 있다

지금: 왼쪽 아래 Diff 요약 총 43 라인 · 차이 10 라인 / 가운데 1행 1열 | 차이 - / 5 | UTF-8 · LF · C# / 그 아래 편집 0건 · 되돌리기 0건 · 남은 차이 10 라인 | 코드 검사 이상 없음.
비슷한 숫자가 세 군데 있다 - 차이 10 라인 · 차이 - / 5 · 남은 차이 10 라인. 어느 것을 봐야 할지 헷갈린다.
한 줄로 합친다. 자리 규칙을 정해 둔다 - 왼쪽은 지금 위치(행·열), 가운데는 진행(차이 3/5 · 남은 10줄 · 편집 2건), 오른쪽은 파일 정보(UTF-8 · LF · C# · 코드 검사).
줄이 하나 줄어드는 만큼 코드가 그만큼 더 보인다.
판정 기준: 아래쪽이 한 줄이 되고, 같은 뜻의 숫자가 두 번 나오지 않는다.

C-3. Git 탭에서 지금 못 쓰는 것이 위쪽 4분의 1을 차지한다

지금: 저장소 연결 블록에 원격 URL · 이름 · 클론 · 원격 추가 · 원격 삭제 · Gitea 계정 · 토큰 · Fetch · Pull · Push 가 있다. 원격 저장소가 없어 전부 비활성이다(GitView.xaml).
이 프로젝트는 로컬 머지툴이 우선이고 푸시도 하지 않는다. 그런데 화면에서는 원격이 제일 넓다.
지우지 않는다. 접는다. 사내 Gitea 가 생기면 다시 필요하다. 펼침 상태를 기억한다.
접었을 때 남는 것은 로컬 경로 · 폴더... · 열기 한 줄이다.
판정 기준: 접으면 세로 100px 이상이 브랜치 목록·이력으로 가고, 펼치면 지금과 똑같다. 껐다 켜도 접힌 상태가 그대로다.

C-4. 색 구분 범례를 읽는 것에서 쓰는 것으로

지금: 색 구분 | BASE와 다름 5 | 머지 반영함 0 | 직접 수정 0 | 추가 5 | 삭제 0 | 무시 0 | 자리 옮김 0 | 줄 안에서 바뀐 부분 이 늘 한 줄을 차지한다. 0건인 것도 그대로 자리를 잡는다.
두 가지를 한다.
- 0건인 갈래는 흐리게 한다. 있는 것과 없는 것이 한눈에 갈린다.
- 개수를 누르면 그 갈래로 이동한다. 추가 5 를 누르면 추가된 줄만 차례로 훑는다. 이러면 범례가 설명이 아니라 도구가 되고, 색 이름을 외울 필요가 없어진다.
이동은 이미 있는 차이 이동(Alt+↑↓)과 같은 방식으로 움직인다. 새 이동 규칙을 만들지 않는다.
판정 기준: 0건 갈래가 눈에 띄게 흐리다. 추가 N 을 누르면 첫 추가 줄로 가고, 다시 누르면 다음 추가 줄로 간다.

C-5. ACTIONS 칸이 매번 쓰는 것과 한 번 정하는 것을 섞어 놨다

매번 쓰는 것: Accept · 이 덩어리 반영 · Undo/Redo · 차이 이동 · 저장.
한 번 정하면 그대로인 것: 저장 형식 두 칸 · 비교 규칙 네 개(공백 비교 · Aa 구분 · 필터 끔 · 줄바꿈 끔) · 편집 잠금.
뒤쪽을 접는다(예: ▸ 비교 규칙). 접힌 상태를 기억한다. 오른쪽 칸 폭을 그만큼 코드에 돌려준다.
차이 이동 버튼의 자리를 다시 본다. 가장 자주 누르는데 손이 가장 먼 오른쪽 끝에 있고, 정작 차이 3 / 5 표시는 아래쪽 상태바에 있다. 개수와 이동 단추를 같은 자리에 둔다 - C-2 와 함께 하면 자연스럽다.
규칙을 바꾸면 화면을 다시 그리므로 반영·편집 표시가 유지되는지 확인한다(3차 E-5 에서 한 번 깨졌던 자리다).
판정 기준: 접으면 코드 폭이 눈에 띄게 넓어지고, 펼치면 지금과 같다. 차이 이동을 누르는 손이 짧아진다. 규칙을 바꿔도 반영한 줄 색이 그대로다.

이번 지시서에서 하지 않는 것

번호를 붙여 두는 이유는 나중에 "왜 안 했나" 를 다시 묻지 않기 위해서다.

로그인·권한 — 로컬 도구가 우선이라 뒤로 미룬다.
대용량 파일 성능(수만 줄) — 실제 사내 소스 크기를 확인한 뒤 판단한다.
비교 창 여러 개(3차 D-4) — 사용자 판단으로 뺀 항목이다. 되살리지 않는다.

보고 형식

항목마다 이렇게 적는다.

무엇이 원인이었는지 한두 줄 (새로 만드는 항목이면 어떤 판단을 했는지)
어떤 파일을 어떻게 고쳤는지
실제로 실행해 확인한 결과
커밋 해시

16 KiB Raw Blame History