설계
누구나 머리속에 그리는 설계가 있습니다. 표현하지 않을뿐!
어느 날 심사원이 저를 불러 다그칩니다.
"아니 설계한 것이 맞습니까?"
"네, 설계는 했을 겁니다. 문서를 못찾으셨거나 아니면, 문서로 표현하지 않았을지도..."
"아니! 그럼 어떻게 설계를 했다고 보증할수 있죠? 그 근거가 있으면 알려주세요."
소프트웨어 프로세스 인증 심사를 받을 때 이런 일이 있었습니다. 검색엔진을 만드는 프로젝트를 수행했는데, 설계활동을 했는지 알 수 없다고 말합니다. 그래서 제가 개발 당시 개발 프로젝트 책임자(PM)에게 가서 물어보았습니다.
"이거 검색엔진 설계도 없나요? 상세설계는 있는데, 아키텍처 설계가 없는 것 같아서요."
"심사원분들에게 전달해야하는데 찾기가 어렵네요."
PM이 말했습니다.
"설계를 했느니 코딩을 했겠죠."
네 PM말도 맞고, 심사원 말도 맞습니다. 분명 개발자는 설계를 했습니다. 누구나 알 수 있도록 표현하지 않았을 뿐입니다. 즉, 문서로 설계도를 작성하지 않았습니다. 계획에 설계활동을 명시해서 개발자는 설계를 했지만 머리 속에 있을 뿐입니다. 보통 개발 프로세스가 도입되지 않은 SW개발업체는 설계도를 문서상에 잘 그리지 않습니다. 그렸다해도 몇년이 지나면 사라지기도 합니다. 물론 이건 다른 문제이긴 합니다. 여하튼 그들의 머리속에는 분명 존재합니다. 그러니 구현을 했겠지요. 문제는 복불복 일 수 있다는 겁니다. 머리 속에 있는건 어떻게 바뀔지 모르니깐요. 더 심각한것은 변경이 일어나거나 테스트 활동, 또는 유지보수 결함(이슈)발생할 때 입니다. 더구나 그 개발자가 퇴사를 한다면 더 큰 문제이겠죠. 그래서 개발자는 자기가 그린 설계를 문서로 표현해 놓아야 합니다. 그래야 이해관계자들이 그것을 보고 결함을 찾거나 수정하거나 개선할 수 있습니다. 공학적으로 따지자면 사전에 알아야할 것들이 많아서 공학자가 아닌 분들도 이해할 수 있게 쉽고 간단한 수준에서 풀어보고자 합니다.
결국, 큰 그림과 상세 그림만 그리면 됩니다. 큰 그림은 보통 아키텍처 설계를 말하고 작은 그림은 상세 설계라고들 합니다. 전체 구성도를 그리고 그 구조를 이루는 요소들을 상세하게 어떻게 구현할 건지 그림을 그리는 겁니다. 여기에 추가적으로 데이터 관점으로 그리고 업무나 서비스 흐름 관점으로 그려놓는다면(데이터, 인터페이스 설계 등) 더 할 나위 없겠죠.
아키텍처 모델의 하나로 MVC(Model/View/Controller) 모델: 모바일 앱 구현모델로 쓰임여기서 큰 그림, 즉 아키텍처는 요소(객체, 모듈 등)와 요소(객체, 모듈)들의 관계(요소와 요소들간의 정황 또는 문맥)를 위 그림과 같이 그림으로 작성한 것인데요. 이것들을 통해서 결과물의 비기능적인 사항들을 구현하는 것입니다. 예를 들자면 성능이 원하는 만큼 나올까? 나중에 문제가 생기면 유지보수가 쉬울까? 혹시라도 보안이 취약한 것은 아닐까? 라는 물음들을 확인할 수 있습니다. 이런 것들을 통해 서비스나 SW의 품질을 평가 할 수 있습니다. 그럼 상세 설계는 무엇을 말할까요? 네, 기능에 대한 밑그림입니다. 공학적으로 이야기하면 기능은 '입력 대비 출력'입니다. 상세 설계는 입력에는 무엇이 들어가고 출력에는 무엇이 나오고, 이것들이 어떤 로직을 통해서 처리되는 건지 보여주는 것이죠. 좀더 추가하자면 예외처리 같은 것들도 고려해주면 좋을 겁니다. 사실 사용자가 어떤 입력을 넣을지 모르거든요. 숫자만 넣어야 하는데, 문자를 넣으면 어떻게 할지 고려해주어야 합니다.
설계라 하면 정말 많은 이야기를 할 수 있겠지만, 이 정도만 알아도 충분히 설계를 하실 수 있으리라 생각합니다. 구현을 하기전에 먼저 큰 그림과 상세 그림을 그리자! 큰 그림은 요소들간의 관계를 표현한 것이고 상세그림은 요소(기능) 하나하나를 어떻게 만들고 소통하는지 보여주는 것이다. 라고 생각하면 됩니다.
FYI.
상위설계(큰 그림): 아키텍처 설계, 데이터 설계, 인터페이스 정의, 사용자 인터페이스 등
하위설계(작은 그림): 모듈 설계, 자료구조 설계, 알고리즘 설계 등.
설계의 원리: 분할과 정복, 추상화, 단계적 분해, 모듈화, 정보은닉.
