Kimgisa's IT Story

본 내용은 Code Complete 2nd p.136~138에 실린 내용입니다.

복잡성 관리의 중요성

 소프트웨어 프로젝트에 대한 보고서에서 프로젝트 실패의 원인을 보고할 때, 프로젝트가 실패하는 주된 요인으로 기술적인 이유를 들고 있는 경우는 거의 없다. 프로젝트의 거의 대부부은 품질이 떨어지는 요구 사항, 계획 수립, 관리 등의 이유로 실패한다. 하지만 프로젝트가 기술적인 이유 때문에 실패한 경우에는 그 원인을 복잡성의 관리 부족에서 찾을 수 있다. 소프트웨어에서는 어느 누구도 무엇이 일어나는지 모를 정도로 복잡성이 증가한다. 프로젝트에서 특정한 영역의 코드를 변경했을 때 다른 부분에 대한 어떤 영향을 미치는지 완벽하게 이해하는 사람이 없을 정도의 시점에 도달하면, 더 이상 발전할 수 없게 된다.

[Key Point] 복잡성 관리는 소프트웨어 개발에서 가장 중요한 기술적인 주제이다. 개인적으로 소프트웨어의 기본적인 기술적 의무는 복잡성을 관리하는 것이라고 생각한다.

 복잡성은 소프트웨어 개발의 새로운 특징이 아니다. 컴퓨터 분야의 선구자인 Edsger Dijkstra는 컴퓨팅의 한 비트에서부터 수백 메가 바이트(또 다른 표현으로는 1부터 10의 9승)에 이르는 거리를 재는 작업이라고 지적하였다.(dijkstra 1989). 이 엄청난 비율은 정말 어마어마한 것이다. Dijkstra는 이 내용을 "이 의미론적 수준의 숫자와 비교해 볼 때, 보통의 수학 공식은 평범하다. 심오한 개념적인 계층 구조에 대한 필요성을 불러일으킴으로써, 자동 컴퓨터는 우리에게 역사에 없던 새로운 본질적인 문제들을 제시하였다."라고 표현하였다. 물론 소프트웨어는 1989년보다 훨씬 복잡해졌고, Dijkstra가 말한 1부터 10의 9승 비율은 오늘날에는 1부터 10의 15승이 되었다. Dijkstra는 현대적인 컴퓨터 프로그램을 보관할 수 있을 만큼 큰 두뇌를 가진 사람은 아무도 없다고 지적한 바 있다. 이 말은 곧 소프트웨어 개발자인 우리들이 절대로 전체 프로그램을 억지로 한번에 두뇌에 밀어 넣으려고 해서는 안 된다는 것을 의미한다. 최종 목표는 한번에 생각해야 하는 프로그램의 양을 최소화하는 것이다. 마치 곡예에서 공이나 접시를 다루듯이 정신을 다루는 것과 같다. 여러분이 한번에 다루어야 하는 공의 개수가 많아지면 많아질수록 공을 떨어뜨릴 확률도 높아지게 되고, 결국 이는 설계 상에서나 코드 상에서의 오류를 야기한다.

 소프트웨어 아키텍처 수준에서는 시스템을 서브시스템으로 나누어 문제의 복잡성을 줄인다. 인간은 복잡한 부분 하나보다 여러 개의 간단한 정보를 더 빠르게 이해한다. 모든 소프트웨어 설계 기술의 목표는 복잡한 문제를 간단한 부분으로 나누는 것이다. 서브시스템이 독립적일수록, 보다 안전하게 한 번에 복잡한 부분의 한 부분을 집중적으로 살펴볼 수 있다. 주의 깊게 정의된 객체는 한 번에 하나의 기능에만 집중할 수 있도록 작업을 분활한다. 패키지도 통합의 상위 수준에서 동일한 장점을 제공한다.

루틴을 짧게 유지하면 머리를 더 적게 쓸 수 있다. 구현 수준에서의 용어보다는 문제 도메인 수준에서의 용어로 프로그램을 작성하고 추상화 수준을 높이면 머리를 더 적게 쓸 수 있다.

결론적으로, 인간의 선천적인 한계를 보완할 줄 아는 프로그래머는 자신뿐만 아니라 다른 사람도 이해하게 쉽고 오류가 적은 코드를 작성한다.


복잡성을 해결하기 위한 방법
비용이 지나치게 많이 드는 비효율적인 설계는 다음과 같은 상황에서 발생한다.

• 간단한 문제를 복잡하게 해결할 때
• 복잡한 문제를 간단하고 잘못된 방법으로 해결할 때
• 복잡한 문제를 부적절하고 복잡하게 해결할 때

Dijkstra가 지적했듯이, 현대적인 소프트웨어는 선천적으로 복잡하며, 아무리 노력해도 결국엔 실제 세계 문제가 내포하고 있는 선천적인 복잡성에 부딪히게 될 것이다. 다음은 복잡성을 관리하기 위한 두 가지 접근 방법이다.

• 한 번에 처리해야 하는 본질적인 복잡성의 양을 최소화한다.
• 비본질적인 복잡성이 불필요하게 증가하지 않도록 한다.

일단 소프트웨어에서 다른 기술적인 목표들이 복잡성 관리보다 중요하지 않다는 사실을 이해하게 된다면, 설계 시 고려해야 할 사항들이 간단해진다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

문제상황 : AbstractJpaTests 를 상속받아 작성한 스프링 통합테스트 코드를 실행했더니, 다음과 같은 에러메시지가 발생하였다.

protected boolean shouldUseShadowLoader()

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.