한빛미디어

최근에 회사에서 개발중인 서비스 이슈로 '아키텍트'와 직접 대화를 나누면서 팀 내 본인의 역할, 서비스의 방향성, 앞으로의 개선 방향 등 크고 작은 주제들에 대해 논의할 기회가 있었다. 본인이 개발자로서 일을 한지 15년 가량 되었지만 실제로 아키텍트 포지션의 인력이 하는 일을 가까이서 보게 된 것은 처음이었고, 그 분이 조직을 변화시켜 나가는 과정 속에서 아키텍트라는 업이 내 생각보다 다양한 일을 해야 한다는 것을 알게 되었다.

때마침 한빛미디어에서 이 도서가 출간되었고 리뷰할 수 있는 기회를 얻게 되었다. 현재는 자세한 아키텍처 스타일에 관련된 챕터 외에는 가볍게 읽은 상태이다.

도서를 읽으며 본인이 메모해둔 부분 중 몇몇 부분을 공유해본다. 이 단편적인 정보 조각들만 살펴보아도 아키텍트 업이 궁금한 사람들에게 이 도서가 어떠한 도움을 줄 수 있는지 설명이 되리라 믿는다. 파트 2에서는 다양한 아키텍처 스타일을 소개하고 있는데, 서비스를 만들기 위한 전체 시스템의 설계 방법에 대한 참고가 될 것이다.

.

소프트웨어 아키텍트는 어떤 일을 하는 사람들인가? 끊임없이 변화하는 생태계 안에서 뭔가 결정을 내리는 사람들이다.

아키텍처란 예술과 마찬가지로 context 로서만 이해할 수 있다. 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것이다. 모든 아키텍처는 그 context의 결과물이다.

아키텍트는 알려지지 않은 미지의 것들을 설계할 수 없기 때문에 'Big Design Up Front (일단 설계부터 확실하게)' 방식으로 진행하기 어렵다. 모든 아키텍처는 알려지지 않은 미지의 것들(Unknown unknowns) 때문에 자꾸 되풀이된다. 우리가 필요한 것은 진화하는 아키텍처(Evolutionary architecture)이다.

소프트웨어 아키텍처 설계시, '어떻게'보다 '왜'가 중요하다. 왜 다른 것보다 그런 선택을 하게 되었는지 설명하는 것은 어렵다.

아키텍처는 모든 것이 다 트레이드오프이다. 배포 환경, 비즈니스 동인, 회사 문화, 예산, 기간, 개발자 스킬 세트 등 여러 팩터들이 영향을 미친다. 아키텍처는 정답도, 오답도 없다. 오직 트레이드오프만 있을 뿐. 프로그래머는 장점은 잘 알지만 트레이드오프는 하나도 모른다. 아키텍트는 둘 다 잘 알아야 한다.

아키텍트는 어떻게 해야 코딩 실무 능력을 잃지 않으면서도 일정 수준의 기술 깊이를 유지할 수 있을까? 개념 증명(POC. proof of concept)을 자주 해보는 것이다. 아키텍트가 결정 장애를 극복하는 가장 좋은 방법은, 실제로 각 제품을 응용한 예제 코드를 짜보고 실행 결과를 비교해보는 것이다.

개발자가 아키텍처를 구현할 수 있게 제약조건이나 틀을 만들어 개발팀과 소통하라. 제약 조건을 너무 많이 설정하거나 너무 느슨하게 적용해서는 안 된다.

아키텍처는 물론 삶의 모든 것에서 더 나은 사람으로 거듭날 수 있는 가장 검증된 방법은 바로 연습입니다. 여러분이 신입 아키텍트이건 경력 아키텍트이건 각자의 기술 폭은 물론, 아키텍처를 설계하는 기술을 끊임없이 갈고 닦기 바랍니다. 불행히도 정답은 없습니다.

.

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