"그렇게 큰 거 아니에요.
이 메뉴 이름만 '제품소개'에서 '상품안내'로 바꿔주세요.
간단하죠?"
대표님 입장에선 정말 작은 수정입니다. 글자 네 자 바꾸는 건데, 왜 개발자는 "견적 내봐야 합니다", "생각보다 복잡할 수 있습니다" 하며 망설일까요?
외견상 단순해 보이는 수정이 실제로는 대규모 작업이 될 수 있기 때문입니다.
작은 수정이 큰 비용으로 이어지는 이유는 숨겨진 복잡도 때문입니다.
첫째, 메뉴 이름이 한 곳에만 있지 않습니다. 상단 메뉴, 하단 푸터, 모바일 메뉴, 사이트맵, 데이터베이스, 심지어 구글 애널리틱스 설정까지. 한 곳만 바꾸면 나머지는 옛날 이름으로 남아서 혼란스럽습니다.
둘째, 연관된 코드를 찾아야 합니다. 레거시에선 "제품소개"라는 문자열이 50군데 쓰일 수 있습니다. 하나하나 확인하고 바꿔야 합니다.
한 쇼핑몰 대표님이 "결제 버튼 문구를 '구매하기'에서 '지금 주문'으로 바꿔주세요" 하고 요청했습니다. 간단해 보였습니다. 개발자가 HTML 파일을 열어서 문구를 바꿨습니다. 화면에서 확인하니 잘 나왔습니다.
그런데 다음 날, 고객이 "결제가 안 돼요" 하고 문의했습니다. 확인해보니,JavaScript에서 버튼 문구를 체크하는 로직이 있었습니다. if (button.text == "구매하기") 이런 식으로요.
문구를 바꾸니 이 조건문이 작동 안 했고, 결제 프로세스가 깨진 겁니다.
급하게 JavaScript도 수정했습니다. 그런데 또 다른 문제가 생겼습니다. Google Analytics 이벤트 추적 코드에서도 "구매하기" 문구를 참조하고 있었습니다.
이벤트가 기록 안 돼서, 전환율 통계가 0%로 찍혔습니다. 마케팅팀이 "이번 주 전환율이 왜 이렇게 떨어졌나요?" 하며 당황했습니다.
결국 HTML, JavaScript, Analytics 설정, 그리고 다른 10여 곳을 모두 수정해야 했습니다. "버튼 문구 하나 바꾸는" 작업이 하루 종일 걸렸고, 그사이 결제 오류로 매출 손실도 발생했습니다.
또 다른 사례는 "로고 크기만 살짝 키워주세요"였습니다. CSS에서 width: 100px를 120px로 바꿨습니다.
데스크톱에서는 괜찮았습니다. 그런데 모바일에서 로고가 화면을 넘어가서 레이아웃이 깨졌습니다. 모바일용 CSS도 수정해야 했고, 타블렛용도, 작은 데스크톱용도 각각 조정해야 했습니다. "20px 키우는" 작업이 반나절 걸렸습니다.
왜 작은 수정이 이렇게 복잡할까요?
이유 1: 한 곳 수정이 아닙니다
레거시 시스템에선 같은 내용이 여러 곳에 중복돼 있습니다. 한 곳만 바꾸면 불일치가 생깁니다.
이유 2: 의존성을 파악해야 합니다
A를 바꾸면 B, C, D에 어떤 영향을 주는지 확인해야 합니다. 코드를 읽고 추적해야 합니다.
이유 3: 테스트가 필요합니다
수정 후 전체 기능이 잘 작동하는지 테스트해야 합니다. 데스크톱, 모바일, 여러 브라우저에서 확인해야 합니다.
이유 4: 문서와 설정도 업데이트해야 합니다
Google Analytics, 관리자 매뉴얼, FAQ, 여기저기 흩어진 관련 내용도 함께 바꿔야 일관성이 유지됩니다.
그래서 전문가는 "작은 수정"이라도 견적을 냅니다. 일단 코드를 분석하고, 영향 범위를 파악하고, 정확히 얼마나 걸릴지 계산합니다.
"5분이면 될 것 같은데요?" 하고 섣불리 답했다가 나중에 "생각보다 복잡해서 하루 걸렸습니다" 하면 신뢰가 떨어지니까요.
그렇다면 어떻게 해야 할까요?
방법 1: 수정 요청은 구체적으로
"메뉴 이름을 바꿔주세요"가 아니라 "상단 메뉴, 하단 푸터, 모바일 메뉴, 모두 일관되게 바꿔주세요"라고 요청하세요.
방법 2: 영향 범위 질문하기
"이 수정이 다른 곳에도 영향을 주나요?" 하고 물어보세요. 전문가가 미리 확인해드립니다.
방법 3: 테스트 요청하기
"수정 후 모바일에서도 테스트해주세요" 하고 명확히 요청하세요.
방법 4: 여러 수정은 한번에
작은 수정 10개를 매주 하나씩 요청하지 말고, 모아서 한번에 요청하세요. 효율적입니다.
방법 5: 긴급하지 않으면 천천히
"급해요!" 하면 검증 없이 급하게 하다가 실수합니다. 시간 여유를 주면 안전하게 진행됩니다.
작은 요구도 영향을 고려해야 합니다. "간단한 거잖아요?" 하는 말이 개발자를 압박하면, 제대로 확인 안 하고 급하게 하다가 사고가 납니다.
"작아 보여도 신중하게 해주세요" 하는 태도가 오히려 비용을 줄입니다. 천천히 확실하게 하는 게, 빨리 하다가 고치는 것보다 결국 빠릅니다.
'PHP 유지보수' 카테고리의 다른 글
| 보안 사고 한 번에 무너지는 중소기업의 현실 (0) | 2026.08.18 |
|---|---|
| 기존 사이트를 버리지 않고 5년 더 쓰는 방법 (0) | 2026.08.11 |
| 홈페이지가 느려지면 고객 마음도 떠난다 (0) | 2026.07.28 |
| 시스템 재구축 제안서가 과장일 수 있는 이유 (0) | 2026.07.21 |
| 사고 후 복구 비용은 평소 유지 비용의 10배 (0) | 2026.07.14 |