한빛미디어

개발을 진행할 때 아키텍칭은 정말로 중요하다.

아키텍칭 없이 시작한 개발과 아키텍칭을 충분히 진행하고 개발에 착수한 개발물의 결과는 상당한 차이가 있기 때문이다.

가령 10만 줄에 달하는 프로젝트를 진행할 때, 추후의 기능 확장성과 각 컴포넌트 간의 의존성 그리고 스케일 아웃 등의 관계를 고려하지 않고 코드를 짠다면, 이 프로젝트가 2년, 3년 후에 휴지통에 처박히는 것은 어찌 보면 당연한 수순이기 때문이다.

또한 어찌 보면 아키텍칭은 관련 소프트웨어의 수명과 연관되어 지속적이고 꾸준히 이뤄져야 할 요소이다. 즉 프로젝트가 처음 시작할 때 단 한 번만 수행하고 끝나는 행위가 아닌, 개발 중에도 서비스 중에도 수시로 아키텍처적인 고민과 개선이 이뤄져야만 한다.

이러한 관점에서 봤을 때, 개발자와 아키텍칭 사이의 관계는 결국 때려야 땔 수가 없는 관계다. 개발이 이뤄진다면 곧 그와 관련된 간단한 명세가 적어도 하나쯤은 있어야 함을 의미하기 때문이다.

이러한 관점에서 보았을 때, 개발자로써 아키텍트를 어떻게 이해야 할지, 혹은 아키텍트만 전문적으로 하는 직군의 업무를 꿈꿀 때 기본적으로 알아야 하는 지식과 이를 활용할 수 있는 가이드가 있다면 상당한 도움이 될 것이란 생각이 들었다.

그렇기에 이번에 "개발자에서 아키텍트로"라는 책을 한빛미디어 리뷰 도서로 신청하였고, 관련 내용을 간략하게나마 정리해보았다.

【책의 구성】 '개발에서 아키텍트로"의 책의 구성은 어떠한가?.

이 책은 총 3개의 파트로 구성되어 있다. 1파트는 "소프트웨어 아키텍처"에 관한 내용을 다루고 있고 2파트는 "아키텍처 설계의 기초"에 대해서 다루고 있다. 3파트는 "아키텍트의 은색 도구상자(실버 블렛)"에 대해서 정리되어 있다.

솔직히 파트 3은 간략하게 한번 읽어보고 필요할 때마다 참고하여 실무에 적용하면 좋을 것이란 생각이 들었다. 아~ 이런 방법이 있구나. 정도로 이해하고 추후 필요할 때 도입하는 형태로 말이다. (왜냐하면 해당 사항들은 지식을 전달하기보단 책의 소주제에서 설명하는 것처럼 "문제를 이해하고 싶을 때", "해결책을 찾고 싶을 때"와 같이 특정 상황에 놓였을 때 이를 해결하기 위한 실천 방향 (액티비티)에 관한 가이드이기 때문이다.)

파트 1은 말 그대로 "아키텍트"는 무엇을 하는 사람이고 무엇을 해야 하는지에 대해서 설명하고 있다. 거의 모든 책들의 시작과 유사하다. 다만 조금 다른 점이 있다면 "아키텍트"로써 문제를 해결해야 할 때, 어떤 접근법으로 접근하면 좋은지에 대해서 술 해져있다. 그런데 문제는 내용이 솔직히 좀 뻔한 것들이었다. 학부에서 소프트웨어 설계 혹은 소프트웨어 개발론에 관한 전공 과목을 한 번쯤 들어본 사람이라면 누구든 이해할 수 있는 내용들이다. 솔직히 약간 진부한 감이 없잖아 있는 파트이다.

파트 2의 내용이야말로 이 책의 핵심이라 할 수 있다. 아키텍처에 관한 설계와 이에 대한 기초에 대해서 정리하고 있는데, 내용을 이해하기엔 크게 어려움이 없다. 솔직히 기획자나 디자이너도 읽어두면 좋을 것이란 생각이 든다.

해당 파트의 각 챕터별 내용을 간략하게나마 몇 가지 요약하면 다음과 같다

3 챕터 : 설계 전략 고안하기

 이 장에서 가장 인상적이었던 내용은 설계를 굉장히 디테일하게 한다고 해서 프로젝트 개발 기간이 짧아지진 않는다는 것이었다. 오히려 설계 기간이 너무 길면 길수록 이에 따라 프로젝트 개발 기간이 늘어난다는 그래프 자료가 상당히 인상적이었다.

그렇다면 얼마만큼의 시간을 설계에 투자해야 가장 효율적인 일정 산정이 가능할까? 답은 없다였다. 왜냐하면 개발하려는 소프트웨어의 목적과 취지가 다양하며 또한 개발과정에서 사용되는 소프트웨어 개발론적 접근 방식 역시 상당히 다양하다.

위의 조건으로만 보아도 이를 특정 시간만큼만 설계하면 최상의 효율적인 일정을 산출할 수 있다고 말하는 것은 사기에 가깝다고 할 수 있다.

단, 관련 프로젝트를 사전에 진행해본 유경험자가 있고 이에 대한 각 구성원들의 방향성이 어느 정도 뚜렷한 상태라면 이를 위해서 적정 수준의 설계를 진행한 후, (필자의 경우, 본 프레임이라고 한다(bone frame)) 개발을 진행하며 유연한 자세로 프로젝트의 아키텍칭에 대처하는 것도 하나의 좋은 방법이 될 수 있을 것이란 생각이 들었다.

4 챕터 : 이해관계자와 공감하기

 "공감은 설계를 이끄는 힘이다" 이 챕터에서 가장 마음에 드는 문구였다. 맞는 말이다. 개발이건 뭐건 우리가 일하는 이유는 커스터머 즉 고객의 고충을 공감하고 이를 해결해 주는 것에 있는 것이다. 결국 이해관계자들 간의 요구 사항과 각각의 상충되는 필요사항을 적절히 융화하여 그들 모두를 최대한 만족시킬 수 있는 결과물을 도출하는 것이 분야를 막론하고 우리가 일하는 목적인 것이다.

이 장에서는 이러한 이해관계자들 간의 요구를 적절히 파악하기 위해서 "이해관계자 맵"을 활용할 것을 권장하고 있다. 처음에는 무엇인가 했는데, 결국 관계도를 그리는 것이었다. 각 이해관계 그룹 간에 필요한 내용들을 그래프로 잘 표시하고 각 그룹의 요구 사항을 잘 도식화하여 이에 대한 궁극의 공감점을 형상하는 방법을 이해시키는 것의 해당 챕터의 목적이라 할 수 있을 것이다.

하지만 이해관계자의 도표를 잘 그리고 그들의 요구 사항을 잘 도식화했다고 해서 이에 만족하고 끝내서는 안됨을 명심하도록 하자.

앞서 언급한 것과 같아 고객은 그들의 고충이 해결되길 원하는 것이지, 이해당사자들 간에 각자의 요청 사항만을 탁상공론으로 끝내길 원하지 않는다는 사실을 말이다.

10 챕터 : 설계 시각화하기

 "여러분이 만든 상상 속으로 끌여들이세요". 모든 아이디어는 결국 추상화를 통해 그림으로 보다 직관적으로 표현이 가능하다. 말로 설명하는 것은 직관성이 부족하므로 그림으로 그려서 그 의미를 보다 구체화하여 전달하면 훨씬 이해하기에 좋다.

단, 여기서 우리가 명심해야 할 사항이 있다면, 그림을 잘 그릴 필요는 없다는 점이다. 오직 의미를 잘 전달할 수 있는 수준의 그림이면 된다. 졸라맨 스타일이건 피카소가 울고 갈 정도의 걸작 수준의 그림이건 오직 구성원 간의 컨센서스를 맞추기 위한 의미만을 잘 전달할 수 있으면 되는 것이다. 따라서 그림을 잘 그리는 것보단, 의미를 잘 전달하는 데에 중점을 두는 스케치법을 익혀두도록 하자.

【 "개발자에서 아키텍트로"를 읽고서…….】

 이번 도서를 리뷰를 읽으며 가장 와닿았던 점은 아키텍칭은 한 번하고 끝나는 것이 아니라는 점이었다. 시대가 변하면 새로운 기술도 나오고 그에 맞는 다양한 개발 방법론이 재기된다. 그렇기에 이에 맞게끔 서비스 구조는 수시로 그 구조의 형태를 바꿔가며 시대에 맞게끔 탈바꿈해야만 한다. 만약 이런 과정을 반복하지 않게 되면.. 결국 그 코드와 프로젝트는 레거시 괴수로 변해 엄청난 리소스를 잡아먹게 될 것이 자명하기 때문이다.

어느 분야가 되었건 어느 산업이 되었건 지속적인 공부와 자기 개발은 필수가 된 시대인 것 같다. 평생직장이라는 말은 이제 거의 옛말이 되었고 직업과 일하는 형태도 지속적으로 변화하고 있는 것이 지금의 세계이다.

그렇기에 서두에서 언급한 것과 같이, 자신의 미래와 패스를 너무 자세히 설계하기보단 가장 중요한 구심점을 세우고 그것을 중심으로 어느 정도 유연하게 현실을 파악하고 적응하는 것이 필요해 보인다.

만약 본인의 직업이 프로그래머라면 위의 소양은 반드시 갖춰야 할 것이란 생각이 든다.

 #본 도서는 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

###### 감사합니다 ######