[개발자의 서재] "실용주의 프로그래머" 31. 우연에 맡기는 프로그래밍

우연에 맡기는 프로그래밍

혹시 전쟁, 어드벤처, 공포 영화에서 주인공의 부주의한 행동으로 주인공 스스로 혹은 동료의 목숨을 잃는 것을 본 적이 있는가? 그들도 처음부터 그렇게 부주의하지는 않았다. 몇 번의 실험을 통해서 자신들은 죽지 않는다는 가설을 입증했고 그에 따라서 행동했을 뿐이다. 무엇이 문제였을까? 아마 순전히 운에 따른 실험 결과로 잘못된 가설을 증명했다고 착각한 것이 가장 큰 문제라고 생각한다.

 

개발자인 우리들 역시 매일매일 이러한 시험대에 오르고 있다. "여기서 굳이 확장성을 고려해야 하나?", "아직 성능 고려해서 최적화를 준비해야 할 시기는 아니지" 등 다양한 가정과 가설을 우리 멋대로 사실인양 코드에 작성하고는 한다. 우리는 어쩌다 가설이 참일 때만 성공적으로 동작하는 프로그램을 작성해서는 안된다. 대신 우리가 의도한 대로 동작하는 프로그램을 만들어야 한다.

• "우연에 맡기는" 경우를 조금 더 구분해보면 1) 우연적 구현, 2) 우연적 맥락, 3) 암묵적인 가정 이 세 가지로 나눌 수 있다. 책을 참고하면 더 자세한 설명을 볼 수 있지만 개발자가 의도하지 않은 혹은 개발자의 의도가 협업자에게 전달되지 않은 것이라고 생각하면 이해하기 쉬울 것 같다.

체크리스트

지금 맡고 있는 프로젝트의 코드가 우연에 맡기면서 작성되었는지 확인할 수 있는 체크리스트를 준비했다. 하나라도 포함되는 것이 있다면 개발 프로세스나 문서화가 제대로 이뤄지고 있는지 검토가 필요하다.

• 기능을 추가하거나 수정해야 할 때, 문제가 발생하지 않을 것이라고 확신할 수 없다.
• 문서화되지 않은 기능, 정책이 많다.
• 릴리스 기간이 점점 길어지고 있다.
• 컴포넌트가 실행되고 있는 인프라가 변경될 때, 정상적으로 동작하는지 확신할 수 없다.
• 기능을 개발한 작업자의 의도 혹은 가정이 조직 전체로 전파되지 않아서 버그가 발생한 적이 많다.

실천법

의도한 대로 동작하는 프로그램을 만들기 위해서는 최대한 이른 시기부터 관리가 필요하다. 애초부터 우연적인 요소가 프로그램에 포함되지 않도록 노력하는 것이 가장 효율적인 방법이다. 이를 지키기 위해 간단한 실천법을 공유한다.

1. 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다.
2. 맹목적으로 코딩하지 말라.
3. 신뢰할 수 있는 것에만 의존하라.
4. 가정을 문서로 남겨라.
5. 코드만 테스트할 것이 아니라 가정도 테스트해라.
6. 모든 작업의 우선순위를 정하라.
7. 꾸준히 리팩터링 하라.

• 이를 제대로 실천하기 위해서는 소프트웨어의 판매 전략도 개발팀에 공유되는 것이 중요하다고 생각한다. 앞으로 어떻게 판매될지, 활용될지를 알아야 최선의 선택을 할 수 있기 때문이다.

 

P.S. 35. 사악한 마법사

요즘은 프레임워크를 사용하면 기본적인 스켈레톤 코드는 전부 작성해주는 경우가 많다. 이런 경우도 위의 "우연에 맡기는" 경우에 포함된다. 자동으로 생성된 코드를 개발자가 이해하지 못하는 경우가 많기 때문이다. 더욱이 심각한 것은 자동 생성된 코드는 인터페이스로 분리하기도 어려운 편이 많기 때문에 프로그램의 중요한 부분에 자리잡게 된다.

 

그렇다고 이런 프레임워크를 사용하지 말자는 것은 아니다. 기능 추가가 어렵거나 성능 최적화가 어려워진다던지 프레임워크를 사용했을 때 무슨 문제가 발생할 수 있는지 정도는 알고 있어야 한다는 것이다.