존은 과거 은행에서 일했던 경험을 떠올렸습니다. 당시 그는 영업 담당자들이 주택 담보 대출 상환액을 계산하고 고객에게 그래프를 보여주는 데 도움이 되는 클라이언트 측 애플리케이션을 개발했습니다. 애플리케이션은 성공적이었지만, 나중에 담당자들은 휴대폰에서 사용할 수 있는 모바일 웹 버전을 요청했습니다. 처음에는 백엔드 메인프레임에 연결하는 것을 생각했지만, 메인프레임 개발자가 부족하여 대출 계산 객체를 웹 서비스로 감싸기로 결정했습니다. 웹 서비스는 테스트를 거쳐 잘 작동했지만, 때때로 재현하기 어렵고 진단하기 어려운 터무니없는 결과를 생성했습니다. 문제는 결국 단일 요청에 대한 범위가 지정되지 않은 싱글톤 객체로 인해 동시 요청이 서로 간섭했기 때문이라는 것이 밝혀졌습니다. 싱글톤 객체는 고유성을 적용할 필요가 없었던 원래 클라이언트 애플리케이션에서 남은 것이었습니다. 계산기는 상태를 유지했고, 애초에 싱글톤이어서는 안 되었을 가능성이 높습니다. 해결책은 간단했습니다. 싱글톤 패턴을 사용하지 않고 모든 요청이 계산기의 자체 인스턴스를 가져오도록 하는 것이었습니다. 이 경험은 패턴의 오용 사례를 보여주며, 소프트웨어 개발에 디자인 패턴을 적용할 때 신중한 고려가 얼마나 중요한지를 강조합니다. 이 이야기는 얼마나 간단해 보이는 문제에도 복잡한 원인이 있을 수 있으며, 코드와 설계를 신중하게 검토하면 간단한 해결책에 도달할 수 있음을 보여줍니다.