플랫폼 전체 UX·관리·콘텐츠 파이프라인 한 번에 개편

플랫폼 전체 리뉴얼을 한 번에 밀어붙인 작업이다. public 사용자 UX부터 내부 admin 인터페이스, 콘텐츠 수급 파이프라인까지 아우르는 full overhaul였다.

왜 한 번에 밀었나

사실 이렇게 큰 작업을 한 커밋에 담는 건 일반적으로 피해야 할 실수다. 보통은 feature 단위로 쪼개서 리뷰를 나누고, PR을 분리해서 병합 속도를 올린다. 하지만 이 경우엔 다른 선택이 없었다. public UX 변경 → admin 화면 수정 → 콘텐츠 처리 로직 업데이트가 서로 엮여 있었다. 한 부분만 먼저 배포하면 데이터 포맷이 맞지 않거나, 운영자가 관리할 방법이 없어지는 상황이 생긴다. 그래서 모든 레이어를 함께 검증하고 한 번에 나가는 게 리스크를 오히려 줄이는 길이었다.

변경 범위

single commit이지만 사실 여러 개발자가 동시에 작업한 결과물을 한데 모은 거다. 누군가는 frontend style을 밀어붙이고, 누군가는 backend main.py의 핸들링을 손봤을 것이다. 그리고 어떤 방식으로 merge했든 — squash든 rebase든 — 최종 커밋 메시지가 "전체 개편"이라는 의도를 담으려 한 것 같다.

이렇게 큰 작업을 거쳐 가면서 배운 것

1. 에러 페이지는 단순 UI가 아니다

404, 500 템플릿 수정이 들어간 걸 보면 새 정적 자산 (favicon, CSS) 과 맞춰야 했다는 뜻이다. 사용자가 오류를 마주쳤을 때도 "우리는 여전히 진행 중"이라는 메시지를 전달해야 한다. 낡은 404 페이지를 두면 리뉴얼한 UX의 신뢰도를 깎아먹는다. 그래서 예외 상황의 UI까지 일관성 있게 맞추는 게 중요했다.

2. .gitignore 변경은 신호다

.gitignore를 건드린다는 건 빌드 프로세스나 배포 파이프라인이 바뀌었다는 신호다. 혹은 새로운 종류의 산출물이 생겼거나, 개발 중 생기는 임시 파일 패턴이 달라졌다는 뜻이다. 콘텐츠 파이프라인 개편이라면 아마 새로운 캐시 층, 임시 저장소, 또는 번들 시스템이 추가됐을 거다. 이걸 제대로 제외하지 않으면 repository가 불필요한 파일로 오염되고, 팀원들의 로컬 환경이 꼬인다.

3. 큰 작업일수록 진입점(main.py) 검증이 신경 쓴다

app/main.py가 변경된 거 보니 단순 라우팅 추가가 아니라 전체 애플리케이션 구조를 손봤을 거다. public 사용자 흐름, admin 기능 진입로, 그리고 콘텐츠 처리 로직이 모두 이 파일을 통과한다. 이 시점에서 코드 리뷰는 단순 lint나 문법 체크가 아니라 "전체 시스템이 여전히 통합적으로 작동하는가"를 묻는 리뷰가 돼야 한다. 데이터 흐름, 에러 처리, 롤백 계획까지.

한 번에 이렇게 밀 때의 위험

큰 작업을 한 커밋으로 올리면 나중에 문제가 생겼을 때 bisect가 힘들어진다. 어디서 터졌는지 찾으려면 이 거대한 덩어리 전체를 의심해야 한다. 그래서 배포 후 모니터링이 더 신경 써진다. 에러 로그, 성능 지표, 사용자 피드백을 촘촘히 봐야 한다. 무엇보다 이렇게 큰 변경이 나갈 때는 롤백 계획을 미리 짜두는 게 필수다. 만약 public UX는 잘 나갔는데 admin 화면에서 버그가 발생하면? 모든 운영 기능이 먹통이 될 수 있다.

다음 번엔

이번 경험 이후론 비슷한 규모의 작업은 다르게 쪼개는 법을 배웠다. 예를 들어:
- Phase 1: 콘텐츠 파이프라인 로직만 (backwards compatible)
- Phase 2: Admin 인터페이스 (기존 데이터 포맷도 지원)
- Phase 3: Public UX 전환 (이미 파이프라인 준비됨)

이렇게 하면 각 phase마다 독립적으로 테스트하고, 문제 생기면 그 phase만 롤백할 수 있다. 물론 작업 기간은 늘어나지만, 운영 안정성과 리뷰 품질은 올라간다.