한빛미디어

  최근 팀장 직책을 맡게 되어서 기술서적보다는 설계나 관리에 관한 책을 좀 읽으려고 한다. 개발자로 사회생활에 첫 발을 내딛고 업무를 하다 보면 코더, 개발자, 프로그래머, 아키텍트 등 현재 자신의 모습과 자신이 되고자 하는 미래의 모습에 대해 고민하게 된다. 경험이 부족해서 시야가 좁을 수도 있지만, 내가 알기로는 한국에서는 개발 업무 자체가 속도가 굉장히 빠르고 설계보다는 결과물에 더 집중하는 것 같다. 지금도 오래되고 꽤 규모가 있는(규모가 큰 게 맞을까?) 솔루션을 개발하고 유지 보수하는데, 아무리 분석하고 설계해서 개발을 하더라도 초기에 만들어진 기능이나 코드 덕에 이계 한계에 다다랐다고 생각 중이다. 대화의 스킬이나 설득력이 부족해서 개발팀의 입장을 대변하는 건 참 어려운 것 같다. 하지만 이런 상황일수록 구조나 기능, 로직에 대한 설계가 중요한 게 아닌가 싶다. 하여튼 이런저런 이유로 아키텍트는 참 매력 있는 것이라고 생각을 했고 과연 책에서는 어떤 내용을 알려줄까 하는 궁금증이 생겼다.

  기대와는 다르게 책을 읽을수록 뭔가 잘 읽히지 않는다는 생각이 들었다. 용어나 개념, 접근법 등이 생소했을까? 이미 업무를 하며 녹아들어있는 부분인 것 같으면서도 이게 맞는지 아닌지 판단하기 어려운 부분도 있었다. 이렇게 판단하기 어려운 부분은 책을 제대로 이해했는지 의구심을 갖게 하고 더욱 읽기 힘들게 만들었다. 책 후반부에서는 분석이나 설계에 필요한 여러 가지 활동에 대해 설명해준다. 이 부분도 마찬가지로 이해가 쉽지 않다. 어떤 방법에 대해서 설명은 해주는데 목적과 수행하는 근거가 다소 부족한 것 같다. 다행히 챕터의 뒷부분에서 사례연구를 통해 이해가 좀 되긴 했지만 양이 턱없이 부족했다고 생각한다. 본인이 예시 등을 통한 설명에 익숙해서 그렇게 생각했을 수도 있다.

  어렵긴 했지만 공감되는 부분도 꽤 있었다. 분석을 오래 하면 좋지만, 쉬운 말로 가성비가 최적을 이루기 위해 고민해야 할 적당한 시점 - 균형 -에 대한 이야기가 대표적이다. 또 문제 해결을 위해 설계에 신경 써야 할 설계자의 태도에 대한 부분도 있다. 초기에는 적극적인 설계로 위험 요소를 줄이고 기준점 - 이것도 균형이 중요하겠다 - 이 지나면 수동적으로 모니터링해야 한다는 내용이다.

  업무를 하다 보면 개발팀 외부에서 여러 가지 요구 사항이 나오고 이걸 다 해야 할지 말아야 할지 고민이 많이 된다. 핵심 요구 사항을 알아내는 방법을 설명해주면서 제약으로 선택지를 줄이는 것에 대한 내용이 나온다. 할지 말지 고민하다 보면 결론 내기가 쉽지 않다. 하지만 이런 방법들에 대해 인식하고 있다면 훨씬 쉽게 결정을 할 수 있을 것 같다.

  아직 설계 방법 등에 대해 많이 경험해보질 않아서 전반적으로 어렵게 느껴졌을 수도 있지만 많은 방법을 알려주고 있는 만큼, 고민하는 것보다 여러 가지 방법을 하나씩 따라서 실행해보고 잘 맞는 방법을 찾는다면 좋은 아키텍트가 될 수 있지 않을까 하는 생각이 든다.

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