일화

설계 포럼에서 참석자 한 명이 불완전한 추상화에 적절한 흥미로운 일화를 제공했다. 이 참석자는 스마트 장비의 구성을 촉진하는 소프트웨어 도구를 개발하고 있었다. 도구를 출시하기 한 주 전, 도구에 메모리 누수가 일어난다는 사실을 알았다. 잽싸게 메모리 누수 전문가를 컨설턴트로 초빙하여 실행 시점 메모리 누수의 원인을 파악하기 시작했다.

과거 경험을 바탕으로 컨설턴트는 적절하게 정리하지 않은 몇몇 객체 때문에 메모리 누수가 발생함을 어렵지 않게 추측할 수 있었다. 따라서 컨설턴트는 실행 시간에서 언제 어떻게 객체가 삭제되는지 검사하기 시작했다. 컨설턴트는 객체를 생성하는 체계적인 절차가 있음에도 불구하고 생성된 객체가 궁극적으로 어떻게 삭제되는지는 거의 관심이 없음을 알아냈다. 대다수 개발자는 생성된 객체를 삭제하는 과정을 완전히 무시하는 듯이 보였다!

왜 이런 현상이 발생했는지 컨설턴트는 더 깊이 파고 들기로 했다. 그는 프로젝트 아키텍트가 개발자에게 설계 문서를 넘겨줄 때 ‘생성’ 메서드만 열거한 것이 문제의 원인임을 밝혀냈다. 질문을 받은 프로젝트 아키텍트는 소프트웨어 개발자들이 자신의 설계안에 객체 생성으로 표시된 메서드를 실제로는 ‘생성과 삭제’ 메서드 양쪽을 위한 견본용 틀로 이해했을 것이라고 말했다. 이 아키텍트는 생성된 객체는 정리할 필요가 있으며, 코드를 작성하는 소프트웨어 개발자는 객체 삭제 역시 신경 써야 한다고 조언했다.

컨설턴트는 코드를 작성할 책임이 있는 소프트웨어 개발자들에게도 역시 질문을 했다. 그러자 자신들은 ‘아키텍트가 초안을 작성한 설계를 엄격하게 따라야 한다’고 전달받아서 아키텍처 퇴조나 개발자 부문에서 과도한 엔지니어링은 있을 수 없다고 했다. 결국 설계에서 명시적으로 알아차리지 못한 고려 사항은 거의 신경을 쓰지 않거나 간과하는 경향이 개발자 사이에서 만연해 있었던 것이다.

이 일화에서는 다음 두 가지 통찰력을 얻을 수 있다.

• 아키텍트는 매우 세심하고 성실하게 의사소통의 내용을 설계 문서로 전달해야 한다. 설계의 엄격한 검토는 앞서 언급한 상황처럼 문제점을 외부에 공개하는 데 필요하다.

• 아키텍처가 작성한 설계에서 필요하다면 개발자가 피드백을 할 수 있도록 허용하는 건강한 환경을 프로젝트 팀에 만들 필요가 있다. 사실상 애자일에 기반한 차세대 개발 방법론은 설계와 아키텍처의 ‘집합적인 소유권’이라는 아이디어를 낳게 한다. 이것은 모든 팀원이 설계에 책임을 지며, 설계 결정 과정에 모든 사람이 참여하여 고품질 설계를 만드는 해법을 의미한다.