수익 화면 파트너별 기여 토글 레이아웃 깨짐 수정

system-revenue에서 파트너별 기여 상세 토글을 열면 레이아웃이 깨지는 버그를 수정했다. 변경 파일은 뷰/스타일 1개. 얼핏 단순해 보이지만, 수익 화면에서 레이아웃이 깨진다는 건 숫자가 화면에 제대로 표시되지 않는다는 뜻이라 생각보다 임팩트가 크다. 파트너별 기여 데이터는 단순 목록이 아니라 집계 계층이 있는 화면이고, 토글 하나가 열릴 때 그 아래 렌더링 되는 행 수가 파트너에 따라 달라지기 때문에 더 조심해야 하는 케이스다.

원인과 수정 내용

CSS 토글 UI는 동적 데이터가 채워지는 리스트 위에 얹으면 생각보다 깨지기 쉬운 패턴이다. 원인은 보통 세 갈래로 나뉨.

첫째, 부모에 overflow: hidden이나 고정 높이가 있는데 자식이 그 밖으로 나가려 하는 경우. 토글이 열릴 때 내부 컨텐츠가 잘리거나 아예 안 보인다. 둘째, 클래스를 토글하는 시점과 브라우저 레이아웃 재계산 타이밍이 맞지 않는 경우. JS로 클래스를 붙이자마자 높이를 읽으면 아직 갱신되지 않은 값이 나올 수 있다. 셋째, position: absolute 또는 relative인 요소들이 섞여 있어서 토글이 열릴 때 인접 행의 레이어링이 꼬이는 경우. 수익 화면처럼 테이블 행 안에 토글이 들어가는 구조에서 자주 나타남.

이번 케이스도 그 맥락이었고, 뷰 렌더링 로직과 스타일 두 군데를 함께 건드려야 깔끔하게 잡혔다.

토글 열림/닫힘 상태에 따라 클래스를 동적으로 핸들링하는 스크립트 쪽이 레이아웃 계산을 특정 시점에 다시 트리거하지 않고 있었음. 수정 포인트를 단순화하면 이런 패턴이다.

// Before: 토글 상태만 바꾸고 레이아웃 재계산 없음
toggle.addEventListener('click', () => {
  detail.classList.toggle('is-open');
});

// After: 열릴 때 높이 기준값 명시적으로 지정
toggle.addEventListener('click', () => {
  const isOpen = detail.classList.toggle('is-open');
  detail.style.maxHeight = isOpen ? detail.scrollHeight + 'px' : '0';
});

스타일 쪽은 overflow: hidden과 max-height transition을 같이 쓰는 패턴으로 정리했다.

.detail-panel {
  overflow: hidden;
  max-height: 0;
  transition: max-height 0.2s ease;
}

transition 없이 클래스만 토글하면 열리는 순간 레이아웃이 튀기 때문에, 부드럽게 펼쳐지면서 내부 요소가 잘리지 않도록 처리했다. scrollHeight로 실제 컨텐츠 높이를 읽어 max-height에 박아 넣는 방식이라 파트너별 기여 행이 몇 개든 자동으로 맞는다.

이 패턴의 트레이드오프가 하나 있는데, scrollHeight를 읽는 시점에 내부 컨텐츠가 다 채워져 있어야 한다는 점이다. 수익 집계처럼 동기 데이터로 채워지는 경우엔 문제없지만, 비동기 로딩이 섞이면 열린 직후 높이가 잘못 계산될 수 있다. 이번 화면은 해당 없었지만, 동일 패턴을 다른 곳에 가져다 쓸 때 주의할 부분.

버그 수정 프로세스

단순히 증상만 픽스하는 게 아니라 왜 발생했는지 원인을 파악하고 수정했다. 비슷한 패턴이 다른 곳에도 있는지 확인했고, 위험한 케이스는 함께 수정했음.

엣지 케이스를 꼼꼼히 따지는 게 귀찮아 보여도, 나중에 같은 버그로 다시 오는 시간 비용이 훨씬 크다. 파트너별 기여 집계 화면은 데이터가 많고 파트너 수에 따라 렌더링 케이스가 달라지기 때문에, 수정 후 한두 케이스만 확인하고 넘어가면 특정 조건에서만 재현되는 버그를 놓치기 쉽다.

수정 후 버그를 직접 재현해서 정상 동작 확인했다. 토글 열고 닫을 때 레이아웃이 안정적으로 유지되는지, 여러 파트너를 연속으로 토글해도 서로 간섭 없이 각자 열리는지까지 확인했고, 숫자 정합성도 관련 화면과 비교했음.

작업 후기

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 한다. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아온다. 이번 버그는 레이아웃 깨짐이었지만, 레이아웃이 깨지면 파트너 기여 숫자가 가려지거나 잘못된 위치에 보이는 시각적 혼란이 생기고, 그게 "데이터가 이상한 것 아닌가"라는 불신으로 번질 수 있다. 화면 버그가 데이터 신뢰 문제로 이어지기 전에 잡는 게 중요하다.

개발 방식에서 개인적으로 지키는 루틴:

• 변경 전 현재 동작 스크린샷이나 수치 메모
• 수정 후 같은 케이스로 확인
• 관련 화면이 있으면 숫자 cross-check
• 커밋 메시지는 "무엇을"보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉽다. 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중이고, 이번처럼 뷰 렌더링과 스타일을 동시에 건드리는 경우에도 두 변경의 의도를 커밋 메시지에 분리해서 설명하려 한다. 나중에 git blame으로 왜 바꿨는지 추적할 때 그게 실질적인 도움이 됨.

CSS 토글 버그처럼 "브라우저에서 직접 열어봐야 재현되는" 류는 코드만 읽어서는 잡기 어렵다. 이런 종류 수정은 항상 로컬에서 실제 렌더링까지 확인하고 커밋하는 걸 원칙으로 하고 있다.