비즈니스를 멈추지 않으면서 6년간 쏘카 존 관리 시스템의 레거시 코드·테이블 구조를 점진적으로 개선한 경험을 담았다. 테스트 코드를 작성하려다 70~100개 컬럼 테이블 문제를 발견하고, ERD를 고치려다 코드도 함께 고쳐야 했다. 기술 이야기인 동시에 이원화 리스크를 조직에서 허락받기 위한 신뢰 구축의 이야기이기도 하다.
핵심 포인트- 70~100개 컬럼 테이블에 type 컬럼 분기로 대부분 NULL — 역할별 테이블 분리로 ERD 자체가 비즈니스를 읽히도록 개선
- 컬럼 삭제 안전 순서: 코드 참조 제거·배포 → 3가지 확인(SELECT* 제거/이원화 정합성/코드 전수) → ALTER TABLE DROP COLUMN
- MySQL 8.0 Online DDL: Metadata Lock은 수 ms, 리빌드 중 SELECT/INSERT/UPDATE 모두 가능 — Table Lock이 아님
- 이원화 시작 시 "현재 상태/목표 상태/롤백 방법" 3문서 작성이 조직 허락의 근거
- Postman Team Workspace에 "이 장애가 발생하면 이 API를 이 순서로" 시나리오 기록 → 장애 대응 병목이 사람에서 문서로
상세 정리- 시작 계기: 테스트 작성 시도 → 컬럼 70~100개 entity 세팅에 1시간 이상 → ERD 파악 → 비즈니스·코드·ERD 불일치 발견
- 문제 1: 매매/근로/용역 계약서가 하나의 테이블에 type 컬럼 분기, 해당 type 아닌 컬럼은 전부 NULL — 초기 설계 + 요구사항 누적 결과
- 문제 2: M:N 테이블이 type 값에 따라 "데이터 묶음"과 "메타 정보"라는 전혀 다른 역할 수행, ERD만으로 파악 불가
- 핵심 원칙: "비즈니스, 코드, ERD는 일맥상통해야 한다. 셋이 어긋나면 구조를 아는 한 사람에게 시스템이 종속된다"
- 이원화 리스크 관리: 3문서(현재 상태/목표 상태/롤백 방법) → 이원화 도중 담당자가 빠져도 이어받거나 되돌릴 수 있음
- 컬럼 삭제 Phase 3 진입 조건: SELECT* 포함 해당 컬럼 쿼리 소멸 + 이원화 데이터 이중 적재 정합성 + 코드 참조 전수 완전 제거
- MySQL 8.0 Online DDL: MDL 획득(수ms) → 리빌드(Online 읽기/쓰기 가능) → MDL 해제(수ms), 참조 쿼리 없으면 MDL 구간도 무영향
- 6년 성과: 테이블당 컬럼 70~100개 → 20~30개, 20개 테이블 400개 컬럼 변경, 테스트 케이스 0 → 350개
- Postman 팀 워크스페이스: 10개 시스템 API + 장애 시나리오 문서화 → 가용 인원이 담당자 없이 직접 대응, 수십분 → 수분
- Confluence ERD 10개 시스템: 개발팀보다 PM·사업 담당자가 더 많이 활용, "이 데이터 어디?" 질문에 링크 하나로 답변
왜 읽나대규모 마이그레이션 없이 비즈니스를 멈추지 않고 6년간 점진적으로 고쳐온 전략을 담았다. MySQL Online DDL 안전 절차, 이원화 3문서 패턴, Postman 장애 시나리오 문서화까지 바로 쓸 수 있는 체크리스트가 포함되어 있다.