아키텍처의 "역할"이란?

아키텍처란?

소프트웨어 아키텍처란 무엇인지, 소프트웨어 아키텍트는 무슨 일을 하며, 언제 그 일을 하는지에 대해 알아보자.

소프트웨어 아키텍트라면 코드에서 탈피해 고수준의 문제에 집중해야한다는 거짓말에 속아 넘어가면 안된다. 결국 아키텍트도 프로그래머이고, 코드에 동떨어지지 않게 팀원들의 생산성을 극대화 할 수 있는방향으로 설계를 해주어야한다. 이 때 직접 코드를 작성하지 않는다면 프로그래머를 지원하는 작업 또한 제대로 수행할 수 없다.

소프트웨어 시스템의 아키텍처는 개발, 배포, 운영, 유지가 쉽도록 시스템을 컴포넌트로 분할하는 방법, 컴포넌트를 배치하는 방법, 컴포넌트의 의사 소통방식을 정하는 것이다. 아키텍처는 시스템의 동작여부와 거의 관련이 없으며 동작여부는 수동적이며 피상적인 것이고 본질적인 부분이 아니다.

즉 아키텍처의 주된 목적은 시스템 생명주기를 지원해서 개발자가 시스템을 쉽게 이해하고, 개발하고, 유지보수하고, 배포할 수 있게하여 생산성을 극대화하는 것이다.

그렇다면 아키텍처가 개발, 유지보수, 배포에 어떤 영향을 미치는지 알아보자.

• 개발
  아키텍처는 쉽게 개발할 수 있도록 지원을 해줘야한다. 그 예시로 팀의 구성원이 적다면 아키텍처 관련 제약들이 오히려 방해가 된다고 생각해서, 잘 정의된 컴포넌트와 인터페이스 없이 monolitic 시스템을 개발하게 된다. 수많은 시스템에서 아키텍처가 결여되는 이유가 바로 이 때문이다. 일정에만 쫓겨 일하는게 주가 되면 결국 이 monolitic의 아키텍처로 귀착이 될것이다.

• 배포
  소프트웨어 시스템이 사용되려면 반드시 배포를 해야하고, 배포의 비용이 높을수록 시스템의 유용성은 떨어지기 마련이다. 따라서 아키텍처는 한번에 쉽게 배포할 수 있도록 도와주어야 한다. 예시로 MSA를 사용하기로 결정하면 컴포넌트의 경계를 뚜렷하게 나눠 각 컴포넌트 별로 쉽게 개발이 가능하지만, 컴포넌트를 서로 연결하기 위해 설정하고 순서를 결정하는 과정에서 에러가 발생해 배포가 어려워질 수 있다. 결론은 컴포넌트와 프로세스 수준을 하이브리드 형태로 사용해 배포를 쉽게 할 수 있어야 한다.

• 운영
  좋은 소프트웨어 아키텍처는 시스템을 운영하는데 필요한 요구를 알려준다. 시스템 아키텍처가 개발자에게 시스템의 운영 방식을 잘 드러낸다면, 유스케이스와 기능 , 시스템의 필수 행위를 상위 요소로 격상시켜 개발자가 가져야할 목표를 인식시킨다. 이렇게 시스템의 이해도를 높여 개발과 유지보수에 큰 도움을 준다.

• 유지보수
  유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 가장 비용이 많이 발생하며 많은 인적 자원이 소모된다. 주의를 기울여 신중하게 아키텍처를 만든다면, 시스템에 새로운 기능을 추가하거나 결함을 수정할 때 걸리는 시간을 줄이고 좋은 전략을 세울 수 있게된다. (시스템의 확장성, 장애 위험 제거)

더 나은 아키텍처를 설계하기 위한 "선택사항 열어두기"

소프트웨어 아키텍처는 행위적 가치보다 구조적 가치를 우선시해야하며, 그 이유는 소프트웨어를 더 유연하게 해 행위를 쉽고 빠르게 변경하기 위해서이다. 그리고 유연한 소프트웨어를 위해 아키텍처는 선택사항을 가능한 한 많이, 오래 열어둘 수 있어야 한다. 그렇다면 선택사항이 무엇인지 왜 열어두어야 하는것인지 살펴보자.

우선 소프트웨어 시스템은 주요한 두가지 구성요소로 분해할 수 있는데, 이것이 정책과 세부사항이다. 정책은 시스템의 핵심적인 가치를 정의하는 부분이며 세부사항은 사람, 외부 시스템, 프로그래머 정책과 소통할 때 필요한 요소이다. 이 때 정책에 무관하게 세부사항을 사용할 수 있는 형태로 아키텍처를 설계하여 선택사항을 열어둔다면, 시스템을 만드는 과정에서 더 많은 정보를 얻어 제대로 된 결정을 내릴 수 있다.

예를 들어, 개발 초기에 데이터베이스 시스템을 선택하지 않고 아키텍처를 설계하면 시스템이 관계형, 분산형, 계층형 중 어떤 데이터베이스가 어울리는지 다양한 시도를 거쳐 나중에 검토 및 판단을 할 수 있는 것이다. 이러한 점들 때문에 선택사항을 열어 결정을 연기하거나 변경할 수 있도록 시스템을 구성해야한다.

선택사항을 열어둔 이유 예시 "장치 독립성"

옛날 옛적 처음 프린터가 생길 당시 천공카드를 통해 데이터를 인쇄했고 그에 맞춰 코드가 작성되었다. 하지만 천공카드의 관리가 어려워지고 자기 테이프가 등장해 모든 소프트웨어가 자기테이프를 위한 코드를 다시 작성해야 하는 고충을 겪었고, 이로 인해 입출력 장치를 소프트웨어 함수로 추상화 했다. "출력한다"로 추상화 시키고 운영체제가 어느 장치에 연결해야하는지 전달받는 방식으로 말이다.(OCP의 등장)

클린 아키텍처의 저자는 개인화된 광고(편지지의 이름을 각각 달리하여 우편에 부침)의 일을 이러한 장치 독립성을 활용해 훨씬 더 많은 인쇄를 수행할 수 있었다고 한다.

• [컴퓨터(자기 테이프 인식) -> 라인프린터(편지지 인쇄)] 에서
• [컴퓨터 -> 자기 테이프에 편지 내용 입력 -> 테이프 드라이브(자기 테이프 인식) -> 오프라인프린터 5대(편지지 인쇄)]

이 외에도 저자는 대규모 회계 시스템을 만들어 데이터 레코드를 저장할 때 디스크의 물리적 구조에 맞춰 소프트웨어를 작성해 데이터를 저장했다. 하지만 디스크를 업그레이드하거나 구조가 변경되면 과거 데이터의 이전하는것이 어려워졌고 유지보수 또한 문제가 생겨버려서, 디스크의 물리적 구조에 의존하지 않게 상대 주소를 사용했다고 한다.

앞선 사례처럼 이렇게 선택사항을 열어두어 세부사항의 결정시간을 늘린다면, 세부사항을 정책으로부터 신중하게 가려내고 정책과 세부사항이 결합되지 않도록 엄격하게 분리할 수 있다고 이야기 한다.

결론

- 아키텍처의 주된 목적은 시스템 생명주기를 지원해서 개발자가 시스템을 쉽게 이해하고, 개발하고, 유지보수하고, 배포할 수 있게하여 생산성을 극대화하는 것이다.

- 아키텍처를 통해 선택사항을 열어두어 시스템의 개발 비용을 줄일 수 있도록 합리적인 선택을 할 수 있게 만들자.