코딩스토리

Clean Architecture 스터디[15장] 아키텍처란? 본문

Clean Architecture

Clean Architecture 스터디[15장] 아키텍처란?

라크라꾸 2022. 2. 6. 20:26

아키텍처의 주 목적

  • 시스템의 생명주기를 지원
  • 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해준다.
  • 시스템의 수명과 관련된 비용은 최소화 하고, 프로그래머의 생산성은 최대화 하는 데 있다.

 

개발

개발하기 힘든 시스템이라면 수명이 길지도 않고 건강하지도 않을 것이다.

시스템 아키텍처는 개발팀이 시스템을 쉽게 개발할 수 있는 구조여야 한다.

 

배포

소프트웨어 시스템이 사용될 수 있으려면 반드시 배포할 수 있어야 한다. 배포 비용이 높을수록 시스템의 유용성은 떨어진다.

소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 목표를 두어야 한다.

 

운영

아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적이다.

좋은 소프트웨어 아키텍처는 시스템을 운영하는데 필요한 요구도 알려준다.

  • 시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급(first-class) 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야 한다.
  • 이를 통해 시스템을 이해하기 쉬워지며, 따라서 개발과 유지보수에 큰 도움이 된다.

 

유지보수

유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다.

 

가장 큰 비용은 탐사(spelunking)와 이로 인한 위험부담에 있다.

  • 탐사: 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는게 최선인지, 그리고 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용이다.

아키텍처를 신중하게 만들면 이 비용을 크게 줄일 수 있다.

  • 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다.

 

선택사항 열어두기

  • 소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다.
  • 열어둬야 할 선택사항 - 중요치 않은 세부사항
  • 모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다.
    1. 정책 - 시스템의 진정한 가치가 살아있는 곳(모든 업무 규칙과 업무 절차를 구체화)
    2. 세부사항 - 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않음(입출력장치, 데이터베이스, 웹 시스템, 서버 프레임워크, 통신 프로토콜 등)

 

아키텍트의 목표

  • 시스템 정책을 가장 핵심적인 요소로 식별
  • 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축

 

장치 독립성

1960년대에 프로그래머는 많은 실수를 저릴렀는데, 대표적인 실수 중 하나는 코드를 입출력 장치와 결합해버린 일이다. 프린터로 인쇄할 일이 생기면, 해당 프린터를 제어하는 입출력 명렁어를 직접 사용해서 코드를 작성했다.

  • 이러한 코드는 장치 종속적(device dependent)이다.

 

처음에는 이 전략도 효과가 있었다.

카드 판독기에서 카드를 읽어야 할 경우에도 카드 판독기와 직접 상호작용하도록 코드를 작성했다.  천공카드에 구멍을 뚫어야 할 경우에도 카드 천공기를 직접 조작하는 코드를 잘성했는데, 이러한 방식이 실수였다는 것을 어떻게 알았을까?

  • 큰 규모의 천공카드 뭉치기는 관리하기가 어려웠다.
  • 잃어버리거나 찢어지거나 구멍이 뚫리고 서로 섞이거나 떨ㅇ어뜨릴 수 있었다.
  • 개별 카드를 잃어버릴 수도 있었고, 다른 카드가 추가되기도 했다.
  • 결국 데이터 무결성이 중요한 문제로 대두되었다.

해결책

  • 해결책은 자기테이프였다
  • 자기테이프는 떨어뜨리더라도 레코드가 섞이지 않았다. 단순히 테이프를 전달ㄹ하는 과정에서 레코드가 우연히 사라지거나, 또는 비어 있는 레코드가 추가되지 않았다.
  • 이처럼 테이프는 훨씬 안전하고, 더 빨리 읽고 쓸 수 있고, 맥업용 복사본도 매우 쉽게 만들 수 있었다.

문제점

  • 우리가 만든 모든 소프트웨어는 오직 카드 판독기와 카드 천공기를 조작하도록 작성되었다.
  • 자기 테이프를 사용하려면 이들 프로그램을 다시 작성해야 하는데, 너무 큰 작업이다.

 

장치 독립성을 생각

입출력 장치를 소프트웨어 함수로 추상화했고, 해당 함수는 천공카드와 같은 단위 레코드를 처리한다.

프로그램은 운영체제의 서비스를 호출하고, 해당 서비스가 추상화된 단위 레코드 장치를 처리한다.

오퍼레이터가 해당 추상 서비스를 카드 판독기, 자기 테이프, 아니면 또 다른 단위 레코드 장치 중 어디에 연결해야 하는지를 운영체제에 알려줌

 

동일한 프로그램을 아무런 변경 없이도 카드에서 읽고 쓰거나 테이프에서 읽고 쓸 수 있게 되면서 개방 폐쇄 원칙이 탄생하게 되었다.

 

 

광고 우편

장치 독립성을 이용해 어떤 장치를 사용할지 전혀 모른채, 그리고 고려하지 않고도 프로그램을 작성할 수 있엇다고 한다.

이러한 프로그램에는 형태가 있었는데, 이 형태는 정책을 세부사항으로부터 분리했다.

  • 어떤 장치를 사용할지에 대한 결정을 연기시켰다.

 

물리적 주소 할당

시스템에서 고수준의 정책을 물리적 구조로부터 독립시킴으로써 애플리케이션과 하드웨어를 분리할 수 있다.

 

Comments