Software Architect Architecting Architecture: 소프트웨어 아키텍처와 설계의 역할

아키텍처 (Architecture)?
혹시 아키텍처를 한글로 번역하는 고민을 해 보셨나요? 아쉽지만 아키텍처는 한글이 따로 없습니다.
경우에 따라 어떤 사람은 아키텍처를 "구조" 라는 단어로 떠올릴 수 있는데,
구조는 Structure 라는 따로 용어가 있다는건 다 아시죠?

 

 

소프트웨어 개발에서 소프트웨어 아키텍처(Software Architecture)는 종종 논란의 중심에 서 있습니다. 일부 개발자는 정교하고 아름다운 시스템 아키텍처를 설계하고도, 소프트웨어 아키텍처 자체에 대해 거부감을 표하기도 합니다. 이들의 거부감은 때로는 관료적인 설계 과정, 비현실적인 아키텍트의 태도, 또는 실질적인 소프트웨어가 아닌 다이어그램을 만들며 시간을 낭비한 경험에서 비롯됩니다. 하지만 이러한 문제들은 소프트웨어 아키텍처 자체의 본질적인 요소가 아닙니다.

 

아키텍트(Architect), 아키텍팅(Architecting), 아키텍처(Architecture)의 구분

소프트웨어 아키텍처는 직무(아키텍트), 과정(아키텍팅), 산출물(아키텍처)로 구분될 수 있습니다. 이 세 가지를 명확히 이해하면 소프트웨어 개발 과정에서 발생할 수 있는 혼란을 줄일 수 있습니다.

1. 직무: 아키텍트(Architect)

소프트웨어 개발 조직에서 “소프트웨어 아키텍트”라는 직함은 흔히 사용됩니다. 그런데 일부 아키텍트는 현실적인 개발 과정과는 동떨어진 선언을 하는 데 그칠 수 있습니다. 실제 업무 정의가 모호하거나, 조직 내에서 역할을 인정받지 못하는 경우가 많습니다. 반면, 어떤 아키텍트는 소프트웨어 구축 과정 전반에 깊이 관여하며 실질적인 기여를 합니다.

 

이 점에서 중요한 사실은 “아키텍트”라는 직함과 역할 자체가 소프트웨어 설계의 필수 조건은 아니라는 점입니다.

모든 개발자는 자신이 참여하는 시스템의 아키텍처를 이해해야 하며, 아키텍처 설계 과정에서 능동적인 역할을 할 수 있어야 합니다. 아키텍트라는 직함이 중요할 수도 있지만, 궁극적으로 중요한 것은 팀 전체가 아키텍처를 설계하고 이해하는 과정에 참여하는 것입니다.

2. 과정: 아키텍팅(Architecting)

소프트웨어 아키텍팅은 프로젝트 초기에는 없던 시스템을 프로젝트 종료 시 실행 가능한 시스템으로 전환시키는 과정입니다. 소프트웨어 개발 조직에서는 잉러한 과정을 다양한 방식으로 진행할 수 있습니다. 일부 팀은 사전 설계(up-front design)를 통해 시스템을 구상합니다. 또 다른 팀은 개발과 설계를 병행하며 점진적으로 시스템을 구축합니다.

 

여기서 흥미로운 점은 아키텍팅 과정(프로세스)이 어떤 방식이든 결과적으로 나오는 시스템의 아키텍처와는 독립적이라는 점입니다.

예를 들어, 한 팀이 3계층 아키텍처를 설계했다고 가정해보겠습니다. 완성된 소프트웨어만 보고 해당 팀이 어떤 설계 방식을 채택했는지 정확히 파악하기는 어렵습니다. 결국, 팀이 설계 과정에서 선택한 프로세스는 중요하지만, 그보다 더 중요한 것은 팀이 만들어내는 결과물 자체입니다.

3. 산출물: 아키텍처(Architecture)

완성된 소프트웨어 시스템은 아키텍처라는 엔지니어링 산출물을 보여줍니다. 이는 자동차의 설계와 유사합니다.

예를 들어, 자동차를 보면 그 설계를 통해 전기차, 하이브리드 자동차, 또는 내연기관 자동차라는 특성을 알 수 있습니다.

이 자동차의 유형은 설계 과정이나 설계자의 직함과 독립적입니다. 즉, 어떤 방식의 아키텍처를 채택했든, 결과적으로 전기차라는 결과물이 만들어질 수 있습니다.

 

소프트웨어 시스템도 동일합니다. 완성된 소프트웨어를 보면 특정한 설계 패턴을 확인할 수 있습니다. 예를 들어:

• 음성 인터넷 전화(VoIP) 네트워크에서 동료 간 협력(peer-to-peer) 노드
• 정보 기술(IT) 시스템에서 다중 계층 설계(3-Tier)
• 인터넷 시스템에서 병렬 처리 MapReduce 노드

흥미로운 점은, 때로는 제대로 된 설계 프로세스 없이 조립된 소프트웨어라도 그 아키텍처는 여전히 드러난다는 점입니다.

 

---

마치며... 소프트웨어 아키텍처, 팀의 공통 언어

소프트웨어 아키텍처는 단순히 문서화된 다이어그램이 아니라, 팀의 모든 구성원이 시스템을 이해하고 동일한 방향으로 나아가기 위한 공통 언어입니다.

 

아키텍처는:

• 프로젝트의 방향을 설정하는 나침반이며,
• 복잡한 시스템의 복잡성을 관리하는 도구입니다.

모든 개발자가 자신의 시스템 아키텍처를 이해하고 아키텍팅 과정에 기여할 때, 비로소 소프트웨어 아키텍처는 그 가치를 발휘합니다. 아키텍트만의 전유물이 아니라 팀 전체의 협업 결과물임을 기억해야 할 것입니다.

 

이제부터는 “Software Architect”라는 직함에 얽매이지 않고, “Architecting Architecture”의 과정에서 팀 전체가 성장할 수 있는 방법을 고민하는 시간을 가져보면 어떨까요?