The Law of Unintended Consequences

좋은 의도가 항상 좋은 결과로 이어지지는 않는다

복잡한 시스템을 변경할 때는 예상치 못한 결과가 발생할 수 있음을 항상 염두에 두어야 한다.

실무에서 소프트웨어의 기능을 추가하거나 버그를 수정하는 일은 자주 접하는 업무입니다.

개발자는 변경에 앞서 발생할 수 있는 위험과 그 영향 범위, trade off 를 파악하려고 노력합니다. 그러나 시스템을 아무리 잘 이해하고 있더라도 우리가 미처 파악하지 못한 변수(Unknown Unknowns) 를 모두 예측할 수는 없습니다.

때로는 문제를 해결하기 위한 변경이 예상치 못한 부작용을 일으키기도 합니다.

이 법칙은 사회학자인 로버트 K. 머턴(Robert K. Merton) 이 20세기에 이 용어를 널리 알렸다고 알려져있습니다.

변경에 따른 3가지 경우

시스템의 변경은 항상 의도한 결과만 가져오지는 않습니다. 때로는 기대하지 않았던 이점을 가져오기도 하고 반대로 부작용을 일으키거나 기존 문제를 더욱 악화시키기도 합니다.

이러한 결과는 크게 세 가지 유형으로 나눌 수 있습니다.

예상치 못한 이점 (Unexpected Benefits)

변경을 계획할 당시에는 의도하지 않았지만 결과적으로 긍정적인 효과가 나타나는 경우입니다.

• 유지보수성 향상 목적으로 공통 로직 분리 → 의도치 않은 테스트 작성과 기능 확장도 쉬워질 수 있습니다.
• 일관성을 위한 로깅 구조 개선 → 의도치 않은 로그 분석, 장애 대응 속도가 향상될 수 있습니다.

예상치 못한 부작용 (Unexpected Drawbacks)

변경 자체는 의도한 목적을 달성했지만 그 과정에서 예상하지 못한 부정적인 영향이 발생하는 경우입니다.

• 사용자 편의 UI 개선 → API 호출 빈도 증가로 서버 부하가 커질 수 있습니다.
• 알림 기능을 강화 → 알림의 양이 많아져 정작 중요한 알림을 놓치는 경우가 생길 수 있습니다.

역효과 (Perverse Results)

문제를 해결하기 위해 취한 조치가 오히려 기존 문제를 악화시키거나 원래 달성하려던 목적과 반대되는 결과를 초래하는 경우입니다.

• 보안강화 목적으로 잦은 비밀번호 변경 강제 → 사용자가 비밀번호 끝의 숫자만 바꾸는 습관으로 인해 오히려 보안이 약화될 수 있습니다.

어떻게 대비할까?

예상치 못한 결과를 완전히 방지할 수는 없지만 문제가 발생했을 때 빠르게 발견하고 대응할 수 있도록 준비할 수는 있습니다.

변경 범위를 축소하자

한 번에 많은 것을 변경할수록 영향을 받는 범위가 넓어지고 문제가 발생했을 때 원인을 파악하기도 어려워집니다.

가능하다면 변경을 작은 단위로 나누어 단계적으로 적용합시다. 변경 범위를 제한하면 문제가 발생하더라도 원인을 좁히기 쉽고 기존 상태로 되돌리는 부담도 줄일 수 있습니다.

테스트

테스트는 변경이 의도한 대로 동작하는지 확인하는 수단입니다. 당연히 모든 테스트를 통과했다고 해서 예상치 못한 결과까지 모두 방지할 수 있는 것은 아닙니다.

모니터링

테스트 환경에서 발견하지 못한 문제는 실제 운영 환경에서 나타날 수 있습니다. 따라서 변경 이후에도 시스템의 상태와 사용자의 반응을 지속적으로 관찰해야 합니다.

오류율이나 응답 시간 같은 지표뿐 아니라 실제 사용 방식이나 업무 흐름에 예상하지 못한 변화가 생기지는 않았는지도 살펴봐야 합니다.

마치며

복잡한 시스템에서는 아무리 신중하게 계획하더라도 모든 결과를 사전에 예측할 수는 없습니다. 변경의 영향을 충분히 검토하고 테스트하더라도, 실제 환경에서는 예상하지 못한 문제가 발생할 수 있습니다.

핵심은 모든 부작용을 완벽하게 예방하는 것이 아닙니다. 예상하지 못한 결과가 발생할 수 있음을 인정하고 이를 빠르게 발견하고 대응할 수 있도록 준비하는 것입니다.

기능을 추가하거나 변경할땐 의도한 결과뿐 아니라 그 변화가 시스템과 사용자에게 어떤 영향을 미칠지도 함께 살펴보는것도 큰 도움이 될것 같습니다.