사소한 수정이 시스템 전체에 미친 파장

"버튼 색깔만 좀 바꿔주세요."

5분이면 끝날 일이라 생각했습니다. CSS 파일 열어서 background: red 하나만 바꿨죠.
그런데 그 버튼이 결제 흐름 전체를 깨뜨렸습니다. 작은 수정도 위험하다는 걸, 그날 뼈저리게 배웠습니다.

오래된 쇼핑몰이었습니다. 결제 프로세스가 여러 단계로 나뉘어 있었고, 각 단계마다 "다음" 버튼이 있었죠. 고객이 "빨간색으로 바꿔달라"고 해서, CSS에서 .btn-next 클래스의 배경색을 빨강으로 바꿨습니다.

그런데 문제는, 같은 .btn-next 클래스가 관리자 페이지의 "상품 등록" 버튼에도 쓰이고 있었다는 점입니다. 그리고 그 버튼 색깔이 JavaScript 조건문에 걸려 있었습니다.

// 오래된 레거시 코드
if ($('.btn-next').css('background-color') == 'rgb(0, 123, 255)') {
    // 파란 버튼이면 일반 상품 등록
    submitNormal();
} else {
    // 다른 색이면 할인 상품 등록
    submitDiscount();
}

믿기 어렵지만, 실제로 이런 코드가 있었습니다. 버튼 색깔로 로직을 구분한 거죠.
버튼을 빨강으로 바꾸는 순간, 모든 상품이 "할인 상품"으로 등록되기 시작했습니다. 재고 관리가 꼬이고, 정산이 틀어지고, 고객 주문까지 영향을 받았습니다.

발견까지 3일

더 큰 문제는, 이 버그를 3일 동안 몰랐다는 점입니다. 관리자는 "상품은 잘 등록되네?" 하고 지나갔고, 고객은 결제가 잘 돼서 불만이 없었습니다.
하지만 내부적으로는 재고 수량이 마이너스로 떨어지고, 할인가 적용이 중복으로 들어가며 정산 금액이 틀어졌죠.

회계팀에서 "이번 달 매출이 이상한데요?"라고 연락이 왔고, 그제야 로그를 뒤져서 원인을 찾았습니다.

원복과 수습

당장 CSS를 원래대로 되돌렸고, 잘못 등록된 상품 수백 개를 일일이 수정했습니다.
며칠 밤을 새웠습니다. 고객한테는 "죄송합니다, 버튼 색깔 변경은 시스템 영향 때문에 보류됩니다"라고 사과했죠.

근본 원인

코드를 뜯어보니, 시스템 전체가 이런 식의 "암묵적 의존성"으로 가득했습니다. CSS 클래스명, HTML ID, 심지어 텍스트 내용까지 JavaScript와 PHP가 하드코딩으로 참조하고 있었죠.

if (strpos($html, '빨간 버튼') !== false) {
    // 특별 처리
}

이런 코드가 수십 군데 있었습니다. 10년 동안 여러 개발자가 덧붙이고 땜질하며 만든 결과물이었습니다.

재발 방지

이후 다음 원칙을 세웠습니다.

1. 사소한 수정도 테스트 서버에서 먼저: 색깔 하나, 텍스트 한 줄도 반드시 테스트 환경에서 확인
2. 전체 기능 회귀 테스트: 주요 프로세스(회원가입, 로그인, 주문, 결제)를 매번 점검
3. 코드 리뷰: 수정 전후 diff를 반드시 다른 사람이 확인
4. 하드코딩 제거: CSS 속성이나 텍스트를 조건문에 쓰지 않기
5. 변경 이력 기록: "누가, 언제, 왜 수정했는지" 문서화

교훈

레거시 시스템은 "나비효과의 세계"입니다. 작은 변경 하나가 예상 못 한 곳에서 큰 문제를 일으킵니다. "이 정도야 괜찮겠지"란 생각이 가장 위험합니다.

작은 수정도 위험합니다. 반드시 신중하게, 테스트 환경에서, 충분한 검증 후에 적용하세요. "급하게" 고치면 "두 배로" 시간 잡아먹습니다. 유지보수는 신중함입니다.