2026-10-27 (화) 개발일지
오늘은 Lepons Cockpit에서 패널 분할 경계를 드래그할 때 크기가 마우스보다 덜 따라오는 버그를 잡았다. 처음엔 마우스 이벤트 핸들러 문제라 생각했는데, 파보니 2분할만 고려한 계산 로직이 3분할 이상에서 깨지고 있었다. 리뷰 중 우연히 발견했는데, 고치고 나니 왜 그동안 못 본 건지 의아할 정도로 단순한 원인이었다.
패널 분할 경계 드래그 — 2분할 기준 계산을 다중 분할로 확장
증상: 패널이 3개 이상일 때 경계를 드래그하면 마우스 움직임보다 패널 크기가 덜 따라온다. 2분할일 때는 문제가 없다. 영향 범위는 분할 수가 3~8개인 모든 레이아웃. 엣지 케이스라 실제 사용자가 겪을 확률은 낮았지만, 경계를 자주 조정하는 사용자라면 매번 2분할로 줄였다 늘려야 해서 경험이 나빴다.
단서 수집 + 첫 가설: 리뷰 중 pane-size.ts 코드를 읽다가 문득 크기 변화가 이상해 보여서 재현해봤다. 3분할 상태에서 오른쪽 경계를 끌면 내 의도보다 2/3 크기밖에 따라오지 않았다. 처음엔 마우스 이벤트의 clientX 계산이 잘못된 줄 알고 splitPane 함수의 핸들러를 샅샅이 봤다. 하지만 pointerdown/pointermove에서 얻는 좌표는 정상이었다. renderPanes와 updateSplitLimits의 파라미터도 문제없었다.
원인 추적 — 사고의 진화: 좌표가 정상이라면 계산 단계에서 뭔가 잘못됐을 거라 생각해 pane-size.ts의 분할 크기 계산 부분을 집중적으로 봤다. 한 가지 패턴이 눈에 띄었다: 분할 경계를 움직일 때 새 너비를 결정하는 로직이 containerWidth / 2 식으로 항상 2분할 기준의 비율을 반환하고 있었다. 예를 들어 3분할에서 한 칸의 너비를 늘리면, 나머지 칸은 남은 공간을 분할 수로 나누는데, 이때 분할 수를 3이 아닌 2로 가정한 계산이 들어가 있었다. 결과적으로 드래그한 칸은 제대로 늘어나도, 나머지 칸들이 예상보다 적게 줄어들어 마우스와의 차이가 누적됐다.
핵심 전환점:
containerWidth / 2를 발견하고 “아, 분할 개수가 하드코딩됐구나” 싶었다. 2분할일 때만 우연히 맞았고, 3분할부터는 틀어지는 구조였다.
이 로직을 누가 언제 넣었는지 git log를 뒤져보니, 초기 프로토타입에서 “항상 2분할만 있다”는 가정으로 작성한 코드가 그대로 남아 있었다. 그 뒤 4분할, 8분할로 확장하면서 계산 부분은 고치지 않은 것이다.
해결 — 무엇을 바꿨나: pane-size.ts의 분할 크기 계산 함수를 현재 분할 수를 인자로 받아 동적으로 나누도록 수정했다. before/after는 아래와 같다.
| 항목 | 이전 | 이후 |
|---|---|---|
| 너비 계산 | containerWidth / 2 |
containerWidth / paneCount |
| 나머지 분할 재분배 | 고정 2분할 기준 | paneCount만큼 균등 분배 |
| 드래그 시 증분 반영 | 비율 깨짐 | 모든 분할에 균등하게 적용 |
다른 옵션으로는 각 분할의 절대 너비를 저장하고 비율로 관리하는 방법도 있었지만, 현재 구조가 상태를 최소로 유지하는 설계라 균등 분배+드래그 증분 방식을 유지했다. 커밋은 브랜치에 반영했다.
검증 + 남은 과제: npm test로 기존 473개 테스트 중 472개 통과, 0 실패. pane-size.test.ts에 3분할·4분할 드래그 시뮬레이션 케이스를 추가했다. 실제 빌드해서 앱을 띄워 3분할 드래그를 반복해봤다 — 이제 마우스와 정확히 같은 비율로 따라온다. 남은 과제는 없고, 이 로직이 다른 레이아웃(세로 분할)에서도 같으 원칙이 적용되는지 확인했으나 모두 pane-size.ts 하나로 처리되므로 영향 범위는 동일하다.
오늘의 한줄
인터페이스 계산 로직은 항상 가장 단순한 가정(2분할)에 기반하면 다중 분할에서 깨진다 — “한 군데만 고칠게”를 의심하자.