개발자에서 아키텍트로

프로그래밍 면접을 볼 때 어느 정도 연차가 되면 시스템 디자인에 대한 시간이 들어간다. 매니저나 그 이상의 직급에서는 코딩 인터뷰보다 더 많은 시간이 할당되는 경우도 봤다. 코딩 인터뷰와 가장 큰 차이점은 딱 맞아 떨어지는 정답은 없다는 점이다. 그래서 대부분의 회사에서 시스템 디자인 인터뷰에 대해서 안내할 때 “정답이 있는 건 아니다"라는 이야기를 한다. 하지만 또 어느 정도는 납득할 수 있고 수긍할 수 있는 아키텍처라는 게 존재하고 그래서 아키텍처에도 패턴이 있다. 하지만 이 패턴을 외운다고 해도 바로 옳은 답을 할 수 있진 않다. 그래서 아키텍처는 어렵고 경험이 필요하다.

이 책은 아키텍트가 되려면 어떻게 해야 하는지 여러가지 측면에서 다루는 데 다른 책들과는 특히 구분되는 면은 비기술적인 면도 중요하게 다룬다는 점이다. 예를 들어 4장은 “이해관계자와 공감하기”, 5장 “아키텍처 핵심 요구사항 알아내기”는 시스템의 관계자들과 협의를 하고 무엇을 최선으로 할지 결정하는 방법을 설명하는 데 다른 아키텍처 관련 서적에서는 쉽게 보기 힘든 부분이다. 실제로 업무를 하면 다른 부서의 매니저들이나 개발자들 뿐만 아니라 product owner와 같은 비즈니스 관련자들과 협의가 개발 방향에 큰 영향을 미친다. 이 때 어느 정도의 트레이드 오프를 통해 개발쪽에서 원하는 설계 방향을 유지하면서 비지니스 목표 달성에 협조하는 게 설계를 하는 사람의 몫이 된다.

또 다른 특징은 문서화를 강조한다는 점이다. 10장 “설계 시각화하기”, 11장 “아키텍처 문서화하기”를 통해 체계적인 문서화로 아키텍처 설계의 결과뿐만 아니라 과정도 같이 보여줘야 한다고 설명한다. 맥락이 없이 결론만 보게 되면 과정에서 논의되었지만 어떤 이유로 배제되었던 다른 아키텍처를 다시 설명해야 할 수도 있고, 다른 목표와 상충되어 일단은 포기하고 가기로 했던 부분을 왜 빠뜨렸냐고 묻는 사람이 생길 수도 있는데, 이런 불필요한 낭비를 줄일 수 있다는 점에서 아키텍처 문서화 역시 중요하다.

마지막으로 Part 3 “아키텍트의 은색 도구상자"에 있는 여러가지 활동이 독특한데, 모든 활동을 따라할 필요도 없고 가능하지도 않겠지만, 체계적인 회의를 하고 싶을 때 도움이 될 자료들이 많이 있다. 이런 개발과 무관해 보이는 업무 방식이 실제로는 잘 활용하면 업무 생산성을 높이는 데 도움이 된다는 점을 감안하면 여기 나오는 여러가지 활동을 잘 사용하면 아키텍처 설계뿐만 아니라 일반적인 개발 업무에서도 도움이 될 거 같다.

 

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