15장 - 아키텍처란?

아키텍처란?

아키텍처라는 단어는 권력과 신비로움을 연상케 합니다.

중대한 결정, 기술적 정취의 정점, 고수준의 문제에 집중해야 함 등이 떠오릅니다.

 

다른 프로그래머만큼 많은 작업은 하지 않을 수 있지만 아키텍트는 코드와 동떨어지면 안 됩니다.

아키텍처란 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치, 의사소통하는 방식에 따라 정해집니다.

 

가장 중요한 것은 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되어야 합니다.

 

아키텍처의 목적으로 시스템의 동작도 중요하지만 주된 목적은 시스템의 생명주기를 지원하는 것입니다.

궁극적인 목표로 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화해야 합니다.

 

개발

만약 5명 이내의 팀이라면 잘 정의된 컴포넌트, 인터페이스가 없어도 잘 협력하여 모노리틱 시스템을 개발할 수 있습니다.

오히려 개발 초기에 아키텍처 관련 제약들이 방해가 된다고 느낄 수 있습니다.

 

다른 한편 일곱 명씩으로 구성된 총 다섯 팀이 시스템을 개발합니다.

이때 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않습니다.

 

배포

시스템을 사용하기 위해서는 반드시 배포해야 합니다.

배포 비용이 높으면 시스템의 유용성은 떨어집니다.

따라서 아키텍처는 시스템을 쉽게 배포할 수 있도록 만들어야 합니다.

 

만약 MSA를 도입한다면 컴포넌트 경계가 뚜렷해지고 인터페이스가 안정되어 시스템을 쉽게 개발할 수 있다고 생각할 수 있습니다.

하지만 배포할 시기에 위협적으로 늘어난 마이크로서비스를 발견하게 됩니다.

각 서비스들을 서로 연결하기 위해 작동 순서를 결정하는 과정에서 오작동이 발생할 수 있습니다.

 

만약 아키텍처가 배포 문제를 초기에 고려했다면 이와는 다른 결정을 내렸을 것입니다.

더 적은 서비스, 서비스와 프로세스 수준의 컴포넌트를 혼합하며, 통합된 도구를 사용하여 상호 연결을 관리했을 것입니다.

 

운영

아키텍처가 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 작습니다.

보통 소프트웨어의 수정보다는 하드웨어를 더 투입해서 해결할 수 있습니다.

 

시스템을 쉽게 운영하는 아키텍처가 바람직하지 않다는 말은 아니지만 운영보다는 개발, 배포, 유지보수 쪽으로 더 기웁니다.

 

유지보수

시스템에서 가장 많이 드는 비용입니다.

새로운 기능은 항상 발생하고, 결함은 피할 수 없으며, 이 결함을 수정하는데 엄청난 인적 자원이 소모됩니다.

 

유지보수의 비용 = 탐사입니다.

 

탐사는 새로운 기능을 추가하거나 결함을 수정할 때 어떤 코드를 고치는 게 최선일지, 그리고 어떤 전략을 쓰는 게 최적 일지를 결정할 때 드는 비용입니다.

 

특히 이런 수정이 이루어질 때 의도치 않은 결함이 발생할 가능성은 항상 존재하며, 이로 인한 위험부담 비용이 추가됩니다.

 

따라서 시스템 컴포넌트를 분리하고, 안정된 인터페이스를 두어 서로 격리하는 것은 미래의 추가될 기능에 대한 길을 밝혀줄 수 있습니다.

 

선택사항 열어 두기

 

좋은 아키텍트는 결정되지 않는 사항 수를 최대화한다.

기억이 잘 안 날 수 있지만 책 초반에 소프트웨어의 두 가지 가치인 행위적 가치와 구조적 가치에 대해 설명했습니다.

이 중 소프트웨어를 부드럽게(soft) 만드는 구조적 가치가 더 중요합니다.

기계의 행위를 쉽고 빠르게 변경하는 방법이 더 중요하기 때문입니다.

 

이런 유연성은 시스템의 형태, 컴포넌트의 배치와 상호 연결되는 방식에 크게 의존합니다.

이때 소프트웨어를 부드럽게 유지하려면 중요치 않은 세부사항을 선택사항으로 열어두어야 합니다.

 

시스템은 보통 정책과 세부사항으로 나뉩니다.

정책은 모든 업무 규칙과 절차를 구체화합니다.

세부사항은 정책이 가진 행위에는 영향을 미치지 않습니다(데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜)

 

 

예시는 다음과 같습니다

- 개발 초기에는 데이터베이스 시스템을 선택할 필요가 없습니다.

고수준의 정책은 어떤 종류의 DB를 사용할지 신경 쓰면 안 됩니다. 

신중한 아키텍트라면 고수준의 정책이 어떤 데이터베이스를 사용하는지 관계없이 만들어야 합니다.

 

- 개발 초기에는 REST를 적용할 필요가 없습니다.

고수준의 정책은 외부 세계의 인터페이스에 대해 독립적이어야 합니다.

마이크로서비스 프레임워크 또는 SOA 프레임워크를 적용할 필요가 없습니다.

다시 한번 말하자면, 고수준의 정책이 이런 것들을 신경 쓰면 안 됩니다.

 

이를 통해 세부사항에 다양한 선택지들을 비교, 실험하여 더 많은 정보로 결정을 내릴 수 있습니다.

 

 

장치 독립성

과거의 컴퓨터에서는 코드와 입출력 장치를 직접 결합해 버렸습니다. (큰 실수)

따라서 장치 종속적인 코드가 탄생했습니다.

 

천공 카드가 불편해서 자기 테이프로 편리하게 진화하였지만 우리가 만든 소프트웨어는 장치 종속적이었습니다.

따라서 자기 테이프 전용 프로그램을 다시 작성해야 했습니다.

 

오늘날의 운영체제는 입출력 장치를 소프트웨어 함수로 추상화했습니다.

따라서 동일한 프로그램을 아무런 변경 없이 카드에서 읽고 쓰거나 테이프에서 읽고 쓸 수 있게 되었습니다.

개방 폐쇄 원칙이 탄생한 순간이지만 이름이 붙기 전입니다.

 

 

 

광고 우편

광고 우편으로 장치 독립성과 고수준 정책, 세부사항 예시를 보여줍니다.

 

처음에는 비싼 IBM 360과 라인 프린터 하나만을 사용해서 인쇄했습니다.

이 방식은 값비싼 기계를 너무 오래 점유했습니다.

 

따라서 라인 프린터 대신 자기 테이프를 사용하도록 운영체제에게 지시했습니다. (입출력 추상화됨)

이제 IBM 360은 10여 분 만에 자기 테이프를 가득 쏟아내기 시작했습니다.

 

이후 자기 테이프를 오프라인 프린터 5개에 연결하여 오랜 시간 동안 수십만 장의우편을 인쇄하였습니다.

 

바로 장치 독립성이 지닌 가치로 이런 문제를 해결할 수 있었습니다.

 

또한 정책은 이름과 주소 레코드에 대한 서식이었으며 세부사항은 장치였습니다.

 

 

물리적 주소 할당

트럭 운전수 조합을 위한 대규모 회계 시스템 사례입니다.

이때 디스크 드라이브에 여러 Agent, Employer, Member의 레코드를 저장하였는데 크기가 제각각 이었습니다.

이때 디스크의 섹터 크기를 레코드의 크기와 매핑시켜 소프트웨어가 디스크의 상세 구조를 알도록 만들었습니다.

 

이때 새로운 디스크 드라이브로 업그레이드해야 한다면?

 

이전의 디스크에서 과거 데이터로 읽어 들여 새로운 디스크로 기록하는 특수 프로그램을 작성해야 했습니다.

 

어느 날 노련한 프로그래머가 합류하고 주소 할당 체계를 변경하여 상대 주소로 변경하였습니다.

 

변환 루틴이 디스크의 물리적 구조를 알게 하고 이를 통해 상대 주소가 필요하면 실린더/헤더/섹터 번호로 변환할 수 있었게 되었습니다.

 

이로써 시스템에서 고수준의 정책이 디스크의 물리적 구조로부터 독립되었습니다.

 

 

 

 

결론

아키텍트는 정책과 세부사항이 결합되지 못하게 엄격하게 분리해야 합니다.

이를 통해 정책은 세부사항에 대한 어떤 지식도 가지지 못하게 합니다.

좋은 아키텍트는 세부사항에 대한 결정을 가능한 오랫동안 미룰 수 있는 방향으로 정책을 설계합니다.