처음 IT 분야에서 일을 시작했을 때 소프트웨어 설계자라는 직책이 나의 관심을 끌었었다. 소프트웨어 혹은 애플리케이션 아키텍트라는 이름이 아름답고 우아하게 보였다. 그리고 아키텍트가 되기로 마음먹었었다.

아키텍트가 되기 위해서는 코딩, 아키텍처, 패턴, 커뮤니케이션 스킬 등 다양한 주제를 깊이 있게 공부하고 경험해야 했다. 나에게 아키텍트가 된다는 것은 훌륭한 개발자가 되고 아키텍처에 대해서 최대한 아는 것을 의미했기 때문이다.

우리는 일반적으로 수석 개발자나 우수한 개발자가 자신은 아키텍트라고 말하는 것을 본다. “Role of the Software Architect”에서 Simon Brown은 소프트웨어 아키텍트가 되는 것은 간단한 일이 아니라고 말한다. 점진적으로 역할을 수행하는데 필요한 경험과 자신감을 얻게 되는 과정이 필요하다. Simon Brown은 아키텍트를 역할로 간주하므로 한 사람이 수행하거나 팀에서 공유될 수 있다.

이번 글에서는 내가 생각하는 아키텍트의 역할을 정리해 보았다. 프로젝트 수행 시마다 아래의 역할을 잘 수행하려고 노력 중이다.

<이미지 출처: https://unsplash.com/photos/mfB1B1s4sMc>

아키텍트의 역할

Architectural Drivers

비즈니스 목표를 이해하고 솔루션을 제공하고 기능 및 비기능적 요구사항과 환경의 제약을 고려하여 아키텍처를 수립해야 했다. 소프트웨어 설계자는 비기능 요구 사항 및 제약 조건이 아키텍처에 큰 영향을 미치기에 이를 고려해야 한다는 점을 인식해야 한다.

소프트웨어 설계

소프트웨어 설계는 아키텍트에게는 정말 중요한 역할이다. 아키텍처 드라이버에서 제기하는 문제를 해결하고 시스템의 전체 구조에 대한 비전을 만드는 방법에 관한 것이다. 디자인 패턴과 최상위 디자인 접근 방식에 능숙해야 하고 기술 선택도 잘 해야 한다.

기술적 위험

아키텍트는 프로젝트에서 사용할 기술을 선택해야 한다. 이 행위는 위험 관리에 대한 부분이기도 하다. 복잡성이나 불확실성에 대한 리스크를 줄이고 이익이 있는 곳에서는 리스크를 도입해야 한다. 이 과정에서 가장 중요한 것은 성숙된 기술을 사용하는 것이다. 대부분의 경우에 새로운 기술에 대한 경쟁 우위 유혹을 받을 수 있다. 명심할 점은 소프트웨어 세계에서의 얼리어답터는 해당 기술의 버그를 찾아주는 선구자 역할을 수행할 수 있다.

아키텍처 진화

소프트웨어 아키텍처의 결과는 유지 관리 및 확장이 쉬운 소프트웨어야 한다. 아키텍트는 담당한 소프트웨어가 성장하도록 설계해야 한다.

코딩

아키텍트도 개발자이다. 이 점을 잊으면 안 된다. 대부분 사람들은 아키텍트가 되면 코딩할 필요가 없다고 생각한다. 이것은 매우 위험한 생각이다. 소프트웨어 아키텍트가 된다는 것은 코딩 작업등에 반드시 참여한다는 의미는 아니지만, 설계 및 구현에 대한 부분을 전달하는데 지속적으로 참여해야 함을 의미한다. 코딩에 대한 기반이 없으면 주도하고 나아갈 수 없다.

품질 보증

버그가 많은 제품을 출시하는 경우에는 아키텍트의 역할에 대한 의미가 퇴색된다. 품질에 대한 보증은 아키텍트 역할의 일부로 간주해야 한다. 코딩 표준, 디자인 원칙 및 도구 그리고 프로젝트의 품질을 보장하기 위한 기준선이 필요하다. 아키텍트가 설계한 것이 프로젝트 전반에 일관되게 구현되고 있는지 상시 확인해야 한다. 이런 행위를 아키텍처 원칙 준수라고 한다.

결론

소프트웨어 아키텍트가 되려면 정말 많은 일을 해서 경험을 쌓아야 한다는 사실을 알아야 한다. 어려운 의사 결정을 내리고 책임을 질 준비가 되어 있어야 한다. 가장 중요한 점은 실패하지 않을 제품을 제공할 것을 보장해야 한다.