시스템 구조 - 구조설계서 작성(3/4)

소프트웨어 구조설계서 작성 과정은 그림을 그리는 것과 비슷하다. 문서의 앞부분인 기능적/비기능적 요구사항을 도출하고 사용자 화면을 구상하는 작업은 어떤 그림을 그릴지 고민하는 작업으로 볼 수 있고 시스템 구조와 컴포넌트 사양을 작성하는 일은 앞에서 구상한 그림을 직접 도화지에 표현하는 작업으로 볼 수 있다. 표현하는 작업은 스케치 작업과 스케치 한 바탕에 색을 칠하는 작업으로 나눌 수 있는데 이중 시스템 구조를 작성하는 일은 스케치 하는 작업에 해당한다.  전체 그림의 윤곽을 그리는 스케치 작업처럼 시스템 구조를 작성하는 일 또한 거시적인 시각에서 동작하는 소프트웨어의 전반적인 틀을 짜는 작업이다.

스케치는 한 번 마무리 되면 다시 되돌리기가 어렵다. 색을 입히는 도중 그림 상에서 배치가 마음에 안들면 도화지를 찢고 다시 그려야 한다. 편리한 소프트웨어를 이용해 그리더라도 이미 색을 입힌 다른 영역을 지워야 하는 수고를 감수해야 한다. 그렇기 때문에 색을 입히기 전까지 신중히 고민하게 되고 지우는 작업을 반복하기도 한다.  시스템 구조를 작성하는 일도 동일하다. 전체 구조를 바꾸는 일은 쉽지 않기 때문에 처음에 구조를 짤 때 다양한 요구사항을 고려해서 만들어야 한다. 구현 단계에 진입 한 후에는 사소한 요구사항을 수정하기 위해 전체를 바꿀 수 없기 때문에 충분한 시간을 들여 난감할 수 있는 상황을 미리 대처 하는 것이 중요하다. 개인적으로 나는 설계 문서 작성 작업 중에서 가장 힘든 작업이라고 생각한다.

그래도 이기적인 총무처럼 네이티브 애플리케이션인 경우에는 안드로이드에서 기본적으로 제공하는 구조를 따라가면서 설계해가면 된다. 그런데 OS나 서버처럼 대규모의 시스템인 경우엔 스케줄러처럼 커널 내부의 요구사항과 그래픽 라이브러리처럼 미들웨어단이 모두 엮여 있는 경우가 있어 쉽지가 않다. 다양한 요구사항을 훌륭하게 반영한 시스템 구조는 최적화가 잘 돼 편리하게 사용할 수 있을 것이고 그렇지 못한 소프트웨어는 기능은 모두 동작 할지 모르나 업데이트 하기도 어렵고 좀 시간이 지나면 버벅 거리게 될 수도 있다. 소프트웨어의 품질은 시스템 구조를 작성하는 데서 판가름 난다고 봐도 무방하다.

그런데 나처럼 혼자서 미리 만들어 본 사람들은 다른 종류의 어려움을 겪는다.. 바로 매우매우 귀찮다는것. 사실 처음부터 하는 것도 아니고 이미 만들어 놓은 코드를 보고 밑그림 하는 일인데도 마우스가 생각보다 움직이질 않았다. 공부도 열심히 해보겠다고 기계식 키보드도 샀는데 이때 만큼은 치기가 싫어질 정도니. 기능적/비기능적 요구사항을 작성 할 때는 의지에 가득 차 있었는데 UI 문서를 만들 때부터 조금씩 싫증나기 시작하더니 클래스 다이어그램까지 그려야 하는 시스템 구조를 작성 할때는 과거의 나를 책망하게 되기도 했다. 내가 왜 이런 일을 한다고 설쳤을까. 교육 받은지 꽤 오랜 시간이 흘러서 약발이 떨어진 것 같기도 하고. 첫 문장을 쓰기 전까지는 '이거 굳이 꼭 해야할까?'라는 생각 뿐이었다.

그래도 한번 하기로 마음먹은 일인데 끝장은 봐야하지 않겠나. 문서 만들고 나면 뿌듯한 기분이 들 것 같기도 하고 교육 받았던 내용을 복습하는 효과가 있을 것 같기도 하고. 정 안되면 두툼한 포트폴리오라도 만들자는 생각으로 월요일 밤마다 꾸역꾸역 작성해갔다. 훗날 이직할 곳에서 과연 높게 봐줄지 모르겠다. 뭐 적어도 없는 것 보다는 낫겠지. 혼잣말이 길었다.

시스템 구조는 큰 그림을 설명하는 작업이기 때문에 추상적으로 설명하게 된다. 특히 첫 장부터 문서별로 Distributed니 Layered Architecture니 하며 그림만 딱 보여주는 경우가 많다. 그림만 보고선 구현의 방향만 짐작하게 될 뿐 구체적인 구현 방법은 감이 오지 않는데 이는 당연한 일이다. 그림을 그릴 때도 스케치로는 대충 어떤 그림이 나오겠거니 예상은 할 수 있지만 무슨 색으로 그려질지, 어떤 물감을 사용할 지는 알 수 없다.. 설계 문서 또한 세부 적인 요소들을 거시적인 관점에서 요약해야 하기 때문에 각 요소들을 꼼꼼하게 작성하는 일은 한계가 있다. 시스템의 윤곽을 소개하는 것이 이 문서의 목적이다.

단, 세부적으로 표현하진 못할지라도 독자에게 뒤에 컴포넌트 사양에서 어떻게 다뤄질 지 예상할 수 있도록 작성해야 한다. 그림 그리는 일과는 다르게 구조설계서를 작성하는 일은 다른 개발자에게 설명하는 것이 목적이다. 스케치는 작가 혼자서 이해하고 색칠할 수 있으면 그만이지만 시스템 구조는 작성자 뿐만 아니라 같이 개발할 동료 또한 시스템에 대해서 이해 해야 한다. 위 목적에 충분히 부합해서 작성할 수 있다면 잘 쓴 시스템 구조라 볼 수 있다. 이렇게 글을 쓰고 나니 검토해야 할 것 같은 의무감이 솟는다...

그림 1. MVC 패턴 개념도

구현한 사항을 반영해 작성하다 보니 이기적인 총무는 여러 개의 화면을 가지고 있고 각 화면에 표시할 데이터와 이 둘을 통제하는 컨트롤러가 존재하는 기본적으로 MVC 구조를 따르는 시스템이었다. 기본적으로 문서 작성은 모든 시스템 환경을 포괄 할 수 있도록 썼고 세부 단락에서 안드로이드에 해당하는 경우 구현 방법에 대해서 작성 했다.

그림 2. Android향 MVC

Controller에서는 Android App의 생명 주기의 요소인 Activity, Fragment 요소를 넣었다. View는 기본적으로 사용하는 XML 파일과 추가로 필요한 기능인 Additional Feature 내용을 넣었다. Model에서는 기본적인 데이터베이스 요소화 Activity에서 제공하는 모델 요소를 교집합으로 표현했다. 그림을 보고난 후에 글을 읽으면 이해하기 쉬울 것 같다는 느낌이 든다.

그림 3. 클래스 다이어그램

시스템에 존재하는 MVC를 클래스로 보고 각 클래스들의 요소와 각각의 관계를 표현한다. 그림을 보면 클래스들이 매우 많고 각각의 관계도 복잡해보이는데 실제로 시스템 상에서 존재하는 요소들이다. 이렇게 까지 표현했다면 꽤 꼼꼼히 스케치를 그렸다고 본다. 색 칠할 때는 각 클래스들이 갖고 있는 변수와 함수를 표현하기만 하면 된다.

그림 4. 테이블 관계도

클래스 뿐만 아니라 모델에 해당하는 데이터베이스에 대해서도 설명해야한다. 여기선 시스템 상에 존재하는 테이블의 종류와 각각의 역할 그리고 이들 간의 매핑 관계를 설명 했다.