2013-02: SW 설계란 무엇인가?

SW설계란 무엇일까? 어떻게 하면 잘 할 수 있을까? 매일 출근해서 SW버그랑 싸우다 보면 설계라는 말은 안드로메다 저편의 한줄기 외로운 별 같다는 생각이 든다.

최근에 회사에 Architect라는 role이 생겼는데, 지금 속해있는 파트처럼 작은 규모의 Utility를 개발하는 부서라면 특히 더 필요하다는 생각이 들었다. 작은 app이 큰 설계를 가지면 무겁고 번거로우며 반대로 큰 app이 영세한 설계를 가지면 자잘한 SW버그가 끊이지 않을 것이기 때문이다. 

1. 최종 SW size에 대한 고려 

최종적으로 만들어지게 될 SW의 크기, 즉 LOC(Line of Code)를 생각해야만 한다. 향후 커질 app이라면 큰 설계로 시작해야 하며 그렇지 않은 작은 app이라면 오히려 패턴 이런거는 최소한으로 사용하고 어떤 문제가 생겼을 때 쉽게 관련 부위를 찾을 수 있도록 계층을 많이 두지 않는 것이 중요하다. 작은 app에서는 interface이런 것도 개발시가 아니라 구조 개선시에만 사용해야 할 것이다. 

Android application 기준으로 

  2만 LOC 이하는 작고 빠른 설계 (bottom-up)  

  5만 LOC 이하는 생각 있는 설계  (top-down) 

  그 이상은 전문 설계자(designer? architect?)를 두는게 꼭 필요하다고 생각한다.  

2. Tree형 구조에 대한 고려 

가장 이상적인 형태는 Tree형태의 패키지 구조일 것이다. 

Application을 기준으로 보면

[UI module] -> [엔진 module] -> [Util classes] 

으로 이렇게 일방향 호출만 발생하고, 물론 UI부분이 유틸리티에는 언제든지 접근할 수 있다. 하지만 실제로 이렇게 되는가 하는 문제는 남아있다. 

개발하다 보면 순환참조가 필연적으로 발생하게 된다. 한군데만 고치면 SW버그를 수정할 수 있다면 나라도 일단 모면할 것이다. 오히려 정공법만 했다가 다시 원복을 하게 되어 더 큰고민에 빠진 사례를 주변에서 몇번 목격을 했다. 다수의 클래스를 변경한 경우 Side effect 발생의 가능성도 risk 차원에서 고려를 해야 한다. 

하지만 기본 원칙은 최대한 방사형 tree로 구성되는 게 옳다. 너무 깊지 않게..

패키지에 파일이 3개 이하로 들어있다면 과감하게 없애라!!  

3. 이름은 소중한 것이다. 

내가 몇년전에 담당한 어떤 SW는 Use case 5~6개를 구현하기 위해 Java file이 108개나 투입된 적이 있었다. 그렇게 된 이유는 전체를 먼저 (개발자의 임의로) 패키지를 3단구성정도.. 즉 , controller , manager , bridge , implementation 등의 레이어를 미리 가정한 후에 거기에 걸맞는 클래스들을 만들었던 것이다. 

그렇게 되면 그 설계자의 원래 idea를 모르는 사람은 도저히 유지보수를 할 수 없다. 최근에 본 어떤 source code에는 

LanguageController 

LanguageConfigurator

LanguageInfo 

LanguageFactory 

라는 클래스가 존재한다. Info는 자료구조 혹은 Value object라고 해서 그렇다고 치자. 그렇다면 도대체 Controller와 Configurator와 Factory는 무슨 차이람 말인가? 만약에 여기에 LanguageManager, LanguageBuilder, LanguageFacade라는 클래스들까지 들어갔다면... 와우@.@ 

이름은 소중한 것이다. 유사한 의미의 단어는 보는 사람으로 하여금 그것을 구별하는데 혼란을 가중시킬 뿐이다. 쓸데 없는 상상력을 심어줄 필요는 없다. 

4. 언제 리팩토링할 것인가? 

의기가 충천할 몇년전까지는 난 단연코 '매번'해야 한다고 대답했을 것이다. 운이 좋게도 2년이상 같은 SW를 맡아본 경험이 3번이나 있고.. 그것만 6년.. ㄷㄷ.. 그때마다 새롭게 '재설계'할 수 있는 기회가 주어졌기 때문이다. 

하지만 지금은 생각이 달라졌다. 수시로 출시되는 product line을 맞추기 위해서는 그렇게 매번 했다가는 넘쳐나는 side effects의 향연으로 매일밤을 별과 함께 지새우게 될 것같는 생각이 들어서 이다. 

정확한 답은 모르겠다. 

시간이 지나면 설계의 견고함은 무너지고, 설계가 변경되야 하는데...하는데..하면서 냄세(smells bad)나는 구조로 변질되게 된다. 

정답은.. 때때로? 눈치껏? 

내 생각엔 그게 바로 경험인 것 같다. 경험있는 개발자가 리스크를 최소화하면서 가장 효과적으로 구조를 변경 consulting 해야 하는 것이다. 

그런 역할이 아키텍트(Architect)라고 생각한다. 

Notes

SW 설계에 대한 얘기는 한도 끝도 없을 주제이다. 어떻게 초기 설계할 것인가? 어떻게 나빠져버린 구조에 대한 구조개선을 할 것인가? 어떻게 변경하는게 risk를 최소화할 것인가? Test에 유리한 구조는 무엇인가? 가능하면 설계시에 Test하기 쉽도록 guide할 수 있는 방안은 무엇인가?

틈나는 데로 다소 중복이 되더라도 글을 써볼 생각이다.

2013.7.13 @ Home