소프트웨어 아키텍트(SA) 정의, 하는 일, 되는 방법, Design Thinking 4가지 원칙 알아보기

이번 글에서는 소프트웨어 아키텍트(Software Architect, SA)에 대해서 알아보겠습니다. 소프트웨어 아키텍트 기본 개념, 하는 일, 소프트웨어 아키텍트가 되는 방법과 Design Thinking 4가지 원칙 등에 대해서 알아보겠습니다.

 

글의 순서는 아래와 같습니다.

• 소프트웨어 아키텍트란?
• 소프트웨어 아키텍트가 하는 일
• 소프트웨어 아키텍트가 되려면 어떻게 해야 할까
• Design Thinking 4가지 원칙(소프트웨어 아키텍트 기본 역량)

 

소프트웨어 아키텍트란 무엇인가?

소프트웨어 아키텍트는 이해관계자(고객, PM, 개발자)가 원하는 아키텍처를 작성할 수 있는 능력을 가진 사람입니다. 엔지니어 레벨에서 보면, 소프트웨어 시스템 구축을 위한 소프트웨어 아키텍처를 설계하고 구축할 수 있는 고급 엔지니어입니다.

 

소프트웨어 아키텍트는 소프트웨어 시스템, 프로그램, 애플리케이션 기획 및 제안 단계부터 분석, 설계, 개발, 테스트, 이행까지 모든 단계에 걸쳐서 일을 합니다. 따라서 이해관계자와의 지속적인 대화를 시스템의 목표를 명확하게 할 수 있어야 합니다.

 

또한 소프트웨어 아키텍처를 수립하는 과정에서 발생하는 다양한 논쟁과 상충 사안을 해결할 수 있어야 합니다. 그리고 소프트웨어 아키텍처가 시스템 구축에 정확하게 반영되도록 처음부터 끝까지 lead, help, check 해야 합니다.

 

소프트웨어 아키텍트에 대한 개념을 정리해 보면 다음과 같습니다.

• 소프트웨어 아키텍처를 작성할 수 있는 능력을 가진 사람
• 소프트웨어 아키텍처를 설계할 수 있는 고급 엔지니어
• 이해관계자와 목표 달성을 위해 지속적인 대화를 하는 Communication의 달인
• 다양한 논쟁과 상충 사안을 해결하는 협상 전문가
• 시스템, 소프트웨어, 프로그램, 애플리케이션 개발에 처음부터 끝까지 리드하는 리더

 

소프트웨어 아키텍트가 하는 일

소프트웨어 아키텍트는 소프트웨어가 고객의 비즈니스 목표 달성을 위한 요구사항들을 만족시키도록 소프트웨어 아키텍처를 설계하고 구현합니다.

 

구체적으로 소프트웨어 아키텍트가 하는 일은 아래 6가지로 볼 수 있습니다.

1. 엔지니어링 관점에서의 문제 정의(Define the problem form an Engineering Perspective)
2. 시스템 분할과 책임 할당(Partition the System and Assign Responsibilities)
3. 큰 그림 유지(Keep an Eye on the Bigger Picture)
4. 품질 속성 간 균형(Decide Trade-offs among Quality Attributes)
5. 기술적 부채 관리(Manage Technical Debt)
6. 팀의 아키텍팅 기술 증대(Grow the Team's Architecture Skills)

 

엔지니어링 관점에서의 문제정의란 소프트웨어 아키텍처 설계를 할 때 사람 중심의 설계 원리를 가지는 것을 의미합니다. 소프트웨어의 특징(Feature) 외에도 품질과 설계 제약에 대해서도 관심을 기울여야 합니다. 

 

시스템 분할과 책임 할당이란 소프트웨어 시스템을 분할해 각 파트에 대한 책임자를 할당하는 작업을 의미합니다. 시스템을 분할하고 각 영역을 담당자들에게 할당하면 원활한 시스템, 소프트웨어 구축이 가능합니다.

 

큰 그림을 유지하는 일은 소프트웨어 시스템을 실제 세계의 문맥에서 작동시키는 것을 의미합니다. 소프트웨어 아키텍트가 설계하고 구축한 아키텍처가 실제로 조화롭게 작동해야 합니다.

품질 속성 간 균형을 잡는 일은 하나의 품질 속성 목표를 얻기 위해서는 다른 품질 속성을 포기하거나 비중을 낮추는 것을 의미합니다.

 

예를 들어, 높은 가용성(품질 속성)을 얻기 위해서는 중복 컴포넌트를 도입해야 하는데, 그러면 비용이 증가하기 때문에 높은 가용성 수준을 포기하는 결정하는 것입니다.

 

기술적 부채 관리는 비즈니스 요구에 맞는 기술 결정을 할 때, 현재 설계 수준과 필요한 설계 수준의 차이를 조절하는 것을 의미합니다.

 

팀의 아키텍팅 기술 증대란 팀원들이 이해할 수 있는 설계와 기술을 공유하는 것입니다. 아키텍팅은 설계 과정에서 부터 팀원과 함께하는 협업이기 때문에 필요합니다.

 

소프트웨어 아키텍트가 되는 방법

소프트웨어 아키텍트는 소프트웨어 개발자로 커리어를 시작해야 합니다.

 

소속된 팀에 소프트웨어 아키텍트가 있다면, 개발을 하면서 아키텍트에게 자문을 구하고, 협업하면서 도제식으로 배울 수 있습니다. 하지만 소속된 팀에 아키텍트가 없다면, 아래 방법에 따라서 스스로 아키텍트로 성장해야 합니다.

 

소프트웨어 아키텍트는 소프트웨어 설계에 대해서 생각하고, 리딩하는 사람임을 명심해야 합니다. 따라서 품질 속성에 초점을 맞춰서 생각해야 합니다.

 

품질 속성에 대한 질문을 갖고 일을 합니다. 그리고 팀에서 품질 속성들 간에 Trade-off를 어떻게 하는지를 항상 관심을 갖고 기록해야 합니다. 만약 설계 결정을 문서화하는 일이 있다면 자원하고, 책임을 가져야 합니다.

 

소프트웨어 아키텍트는 평균적으로 3개에서 5개 정도의 시스템을 개발합니다. 여러 개의 시스템 개발을 통해서 기술적 책임을 갖습니다. 그리고 이를 통해서 프로젝트 포트폴리오를 만들어야 합니다.

 

포트폴리오에 있는 소프트웨어 시스템들을 기술하고, 무엇을 배웠는지를 정리해야 합니다. 아래 내용을 참고해서 작성해 두면 좋습니다.

• 소프트웨어 시스템의 이해 관계자, 관련자는 누구인가?
• 소프트웨어 시스템의 비즈니스 목표는 무엇인가?
• 높은 수준의 솔루션은 어떤 것인가?
• 어떤 기술들이 관련 있나?
• 어떤 기술적 이슈와 리스크가 있었고, 어떻게 극복했는가?
• 다시 이 일을 한다면, 어떻게 더 잘할 수 있는가?

 

Design Thinking 4가지 원칙

Design Thinking 설계 사고는 문제와 해결책을 이해관계자와 소프트웨어의 영향을 받는 사람 관점에서 생각하는 방식입니다. 

 

Design thinking 4가지 원칙은 아래와 같습니다.

• Human Rule : 모든 디자인은 사회적인 영향을 미친다.
• Ambiguity rule : 옵션을 열어두기 위해 애매함은 일부 허용한다.
• Redesign rule : 유사하게 설계된 기존 솔루션을 참고한다.
• Tangibility rule : 아키텍처를 명확하게 표현한다.

Human Rule은 Design for Human입니다. 즉, 기본적으로 설계는 사람 중심으로 작성되어야 합니다. 사용자, 이용자, 영향받는 사람을 위해 이해 당사자 들과 함께 설계해야 하고, 설계가 팀의 중심에 있어야 합니다.

 

Ambiguity Rule은 옵션 사항들을 위해서 일부 애매함을 허용하는 것입니다. 일반적으로 공학에 있어서 애매함은 위험합니다. 하지만 아키텍처는 품질 속성에 있어서 옵션을 두어야 합니다. 이는 기대 품질 속성을 만족시키기 위해 필요합니다.

 

Redesign rule은 디자인의 재사용을 고려하는 것을 의미합니다. 주어진 문제와 유사한 문제에 대해 기존에 적용된 솔루션 패턴이 있다면 활용할 수 있어야 합니다. 기존에 유사하게 설계된 솔루션을 참조하거나 고도화할 수 있어야 합니다.

 

Taingibility rule은 아키텍처가 구체적으로 보이도록 하는 것을 의미합니다. 아키텍처 구조가 프로그램 소스 코드에만 반영되어 있다면, 아키텍처가 잘 보이지 않습니다. 코드는 읽기 힘들고, 품질 속성과 설계 이유 등을 설명하지 않기 때문입니다.

 

따라서 아키텍처에 대해서 구체적으로 명시하고, 다른 사람과 공유할 수 있어야 합니다. 아키텍처 구조 그림을 그리기, 프로토타이핑, 모델링 등을 하는 등의 방식을 활용해 아키텍처를 명확하게 표현하고 공유할 수 있습니다.

 

---

※ 함께 보면 좋은 글

 

1. 소프트웨어 아키텍처 정의, 역할, Desing Mindset

 

소프트웨어 아키텍처 정의, 역할, Design Mindset 알아보기