버그 수정과 구조적 문제 해결은 어떻게 다를까?

버그를 고치는 것과 문제를 해결하는 것은 다릅니다. 버그 수정은 지금 보이는 증상을 없애는 일이고, 구조적 문제 해결은 그 증상이 생길 수 있었던 이유를 다루는 일입니다. 연차가 올라갈수록 후자의 비중이 커집니다.

세 가지 층으로 나눠 보기

증상만 고치면 같은 유형의 문제가 다른 곳에서 다시 나옵니다. 구조까지 내려가야 그 종류의 문제가 생기기 어려운 상태가 됩니다.

구조까지 내려가는 과정

1. 증상을 정확히 기술합니다. 언제부터, 어디에서, 얼마나 자주 생겼는가.
2. 원인을 좁힙니다. 가설을 세우고 로그·재현·실험으로 하나씩 확인합니다. 추측으로 고치지 않습니다.
3. "왜"를 한두 번 더 묻습니다. 이 원인이 왜 코드에 들어올 수 있었는가, 왜 배포 전에 걸러지지 않았는가.
4. 재발 방지 수단을 고릅니다. 아래 중 비용 대비 효과가 큰 것을 선택합니다.

재발 방지의 수단들

• 막는 장치: 입력 검증, 중복 방지 키, 타입 제약 등 코드나 구조에서 막는다
• 알아채는 장치: 모니터링과 알림으로 빨리 발견한다
• 확인하는 장치: 테스트로 같은 실수를 배포 전에 걸러낸다
• 구조 변경: 문제가 생기기 쉬운 설계 자체를 바꾼다
• 팀의 방식: 문서, 체크리스트, 리뷰 기준으로 공유한다

버그 하나에 이 다섯 가지를 모두 적용할 필요는 없습니다. 문제의 영향과 반복 가능성에 따라 가볍게 또는 깊게 선택합니다.

모든 버그를 구조적으로 풀어야 할까

그렇지 않습니다. 영향이 작고 다시 생길 가능성이 낮은 버그에 큰 구조 개편을 하는 것은 오히려 낭비입니다. 구조적 해결이 정당한 신호는 이런 것들입니다.

• 같은 유형의 문제가 반복된다
• 문제가 생겼을 때 영향이 크다 (돈, 데이터, 신뢰)
• 고칠 때마다 다른 곳이 깨질까 두렵다
• 원인 파악에 매번 너무 오래 걸린다

좋은 판단은 "언제 구조를 건드리고, 언제 가볍게 고치고 넘어갈지"를 구분하는 것입니다.

이력서와 면접에서는 이렇게 보인다

예시(재구성한 문장입니다)

• 버그 수정: 중복 결제 오류 수정

• 구조적 해결: 재시도 시 같은 요청이 두 번 처리되는 문제를 분석해 요청마다 고유 키를 부여하는 방식으로 처리 구조를 변경. 같은 유형의 오류를 배포 전에 찾는 테스트를 추가하고, 발생 시 알림이 오도록 구성

두 번째 문장에는 원인 분석, 구조 변경, 재발 방지(테스트·알림)가 모두 들어 있습니다. 면접관은 여기서 "이 사람은 문제가 생긴 뒤의 일까지 책임지는구나"를 읽습니다.

내 경험을 점검해 보기

• 최근에 고친 버그 중 두 번 이상 반복된 것이 있는가
• 그 버그의 "왜 가능했는가"를 설명할 수 있는가
• 고친 뒤에 같은 유형을 막기 위해 남긴 것이 있는가 (테스트, 알림, 문서, 기준)
• 팀의 다른 사람도 같은 문제를 피할 수 있게 공유했는가

정리

버그 수정은 문제를 없애는 일이고, 구조적 해결은 같은 문제가 다시 생기기 어렵게 만드는 일입니다. 증상을 고친 뒤에 한 걸음 더, "왜 이게 가능했지?"를 물어보는 습관이 개발자의 역할을 넓혀 줍니다.