소프트웨어 아키텍처

프로그램을 이루는 큰 덩어리들과 그 덩어리들이 서로 맺는 관계입니다. 어디에서 무엇을 갈라 놓을지 정한 결정들도 함께 가리킵니다. 코드 한 줄과 달리 나중에 되돌리기가 어렵습니다.

상세

집을 지을 때는 방을 몇 개 둘지, 벽을 어디에 세울지를 먼저 정합니다. 벽지 색은 사는 동안에도 바꿀 수 있습니다. 벽을 옮기려면 집을 뜯어야 합니다.

이 말이 가리키는 것은 셋입니다. 시스템을 이루는 덩어리들입니다. 그 덩어리들이 서로 맺는 관계입니다. 그리고 그렇게 갈라 놓기로 한 결정들입니다. 덩어리 하나가 무엇을 맡는지, 무엇을 안 맡는지가 여기서 정해집니다. 누가 누구를 부르는지, 누가 누구를 모르는 채로 있어도 되는지도 마찬가지입니다.

소프트웨어는 다 지은 뒤에도 계속 바뀝니다. 코드 한 줄 단위의 결정과 갈리는 자리는 되돌리는 값입니다. 함수 안쪽은 마음에 안 들면 다시 쓰면 됩니다. 덩어리와 덩어리 사이의 약속은 그 위에 이미 다른 것들이 얹혀 있어서 혼자 바꿀 수 없습니다. 여러 사람이 그 약속 위에서 동시에 일하기로 한 것이기도 합니다. 그래서 이 결정은 개인의 취향이 아니라 합의의 대상이 됩니다.

무엇을 근거로 정하느냐도 갈립니다. 기능 하나를 어떻게 구현할지는 그 기능만 보면 정할 수 있습니다. 덩어리를 어떻게 가를지는 기능이 아닌 것들에 끌려 정해집니다. 얼마나 견디는지, 얼마나 자주 손대게 되는지, 한쪽이 멈췄을 때 나머지가 어떻게 되는지 같은 것들입니다.

배경

프로그램이 커지면 어려운 자리가 옮겨 갑니다. 문장 하나를 어떻게 쓰느냐보다 덩어리와 덩어리 사이를 어떻게 이어 놓았느냐가 발목을 잡습니다. 그런데 그 사이를 가리킬 말이 마땅치 않으면 논의가 각자의 감각으로 굴러갑니다.

Perry 와 Wolf 는 1992년 논문에서 그 자리를 연구 대상으로 세우겠다고 적었습니다. 그들은 1980년대에 소프트웨어 공학 연구의 초점이 소프트웨어 설계 자체에서 멀어졌다고 진단합니다. 설계와 설계 과정을 소프트웨어 프로세스와 그 관리라는 더 넓은 맥락에 통합하는 쪽으로 옮겨 갔다는 것입니다. 그 통합의 한 결과로 설계를 위해 만들어진 표기법과 기법 상당수가 구현 언어에 흡수되었다고 적습니다. 이 통합이 설계와 구현의 구분을 혼동시키지는 않더라도 흐리는 경향이 있었다고 덧붙입니다.

같은 논문은 1990년대가 소프트웨어 아키텍처의 시대가 될 것이라고 믿는다고 적습니다. 「설계」와 대비되는 말로 「아키텍처」를 쓰는 이유도 밝힙니다. 성문화, 추상화, 표준, 정식 훈련, 그리고 양식이라는 관념을 불러오기 위해서입니다. 논문은 이미 확립된 여러 건축 계통 분야에 기대어 직관을 세운다고 적습니다. 그 직관 위에 요소와 형식과 근거라는 세 부분으로 이뤄진 모델을 제시합니다. Kruchten 은 1995년 글에서 이 공식을 Boehm 이 손본 형태로 인용합니다. 소프트웨어 아키텍처는 요소와 형식과 근거 또는 제약의 묶음이라는 것입니다.

예시

Kubernetes

공식 문서는 클러스터가 제어 평면 하나와, 컨테이너화된 애플리케이션을 돌리는 노드라 불리는 워커 머신 집합으로 이뤄진다고 적습니다. 제어 평면은 클러스터 안의 워커 노드와 파드를 관리합니다. 제어 평면의 구성 요소들은 스케줄링 같은 클러스터 전역의 결정을 내립니다. 클러스터 이벤트를 감지해 거기에 반응하기도 합니다. 디플로이먼트의 레플리카 필드가 충족되지 않았을 때 새 파드를 띄우는 일이 그 예로 적혀 있습니다.

각 구성 요소가 어디에 놓이는지, 무엇을 맡는지는 문서가 하나씩 적어 놓았습니다. API(Application Programming Interface, 응용 프로그램 인터페이스) 서버는 Kubernetes API 를 노출하는 제어 평면의 구성 요소입니다. 문서는 이 서버가 제어 평면의 앞단이라고 적습니다. kubelet 은 클러스터의 각 노드에서 도는 에이전트입니다. 여러 경로로 전달된 파드 명세 묶음을 받습니다. 거기 적힌 컨테이너들이 돌고 있는지, 건강한지 확인합니다.

flowchart TD
    subgraph CL["클러스터"]
        subgraph CP["제어 평면"]
            API["API 서버"]
        end
        subgraph ND["노드"]
            KL["kubelet"]
        end
        subgraph PD["파드"]
            CT["컨테이너"]
        end
    end
    CP -->|관리| ND
    CP -->|관리| PD
    KL -->|돌고 있는지 확인| CT

무엇을 얻으려고 이렇게 갈랐는지도 같은 문서에 적혀 있습니다. 프로덕션 환경에서 제어 평면은 대개 여러 대의 컴퓨터에 걸쳐 돕니다. 클러스터도 대개 여러 노드를 돌립니다. 그렇게 해서 결함 감내와 고가용성을 제공합니다.

PostgreSQL

공식 문서는 PostgreSQL 이 사용자마다 프로세스를 두는 클라이언트/서버 모델을 구현한다고 적습니다. 이 모델에서 모든 클라이언트 프로세스는 정확히 하나의 백엔드 프로세스에 연결됩니다. 연결이 몇 개나 들어올지 미리 알 수 없다고 적습니다. 그래서 연결이 요청될 때마다 새 백엔드 프로세스를 낳는 감독 프로세스를 두어야 합니다. 이 감독 프로세스의 이름은 postmaster 입니다. 지정된 포트에서 들어오는 연결을 기다립니다.

덩어리 사이의 통신 수단도 문서가 정해 두었습니다. 백엔드 프로세스들은 세마포어와 공유 메모리를 써서 서로, 그리고 인스턴스의 다른 프로세스들과 통신합니다. 동시 데이터 접근 내내 데이터 무결성을 보장하기 위해서입니다.

sequenceDiagram
    participant 클라이언트
    participant postmaster
    participant 백엔드
    클라이언트->>postmaster: 연결 요청
    postmaster->>백엔드: 새 프로세스를 낳는다
    클라이언트->>백엔드: 질의를 평문으로 보낸다
    백엔드-->>클라이언트: 가져온 행

역할 분담은 질의 처리에서 드러납니다. 연결이 맺어지면 클라이언트 프로세스는 자기가 붙은 백엔드 프로세스로 질의를 보냅니다. 질의는 평문으로 전송됩니다. 클라이언트 쪽에서는 파싱이 일어나지 않습니다. 백엔드 프로세스가 질의를 파싱합니다. 실행 계획을 만들어 그 계획을 실행합니다. 가져온 행들은 맺어진 연결로 클라이언트에 돌려보냅니다.

영국 법무부의 아키텍처 결정 기록

Modernising Lasting Power of Attorney 서비스는 결정을 문서 한 건씩으로 남깁니다. 여덟 번째 기록의 제목은 OPG(Office of the Public Guardian, 공공후견인청) 데이터베이스와의 통합입니다.

맥락 칸에는 이 데이터베이스가 자기네 위임장 데이터를 전부 담고 있어 통합이 필요하다고 적혀 있습니다. 그리고 OPG 의 여러 부분이 이 데이터베이스를 쓴다고 적습니다. 케이스 매니저, 외부 스캐닝 서비스, 공개 서비스, 내부 서비스와 API 가 그 몇 가지로 열거되어 있습니다.

결정 칸은 한 문장입니다. 내부 API 를 거쳐 OPG 데이터베이스와 통합해야 한다는 것입니다. 케이스 관리 시스템이나 데이터베이스 자체에는 직접 붙지 않습니다. 결과 칸에는 최선의 통합 방법을 탐색해야 한다고 적혀 있습니다. 프로세스와 데이터 모델도 정의해야 합니다. 데이터 일관성을 위해 케이스 관리 작업과 새 흐름이 맞아떨어지게 하려는 것입니다.

이견

이 낱말의 정의 문장은 한 벌이 아닙니다.

ISO/IEC/IEEE 42010 워킹그룹 사이트는 이 표준의 정의 항을 옮겨 적어 두었습니다. 시스템이 자기 환경 안에서 갖는 근본적인 개념이나 속성으로, 그 요소들과 관계들에, 그리고 그 설계와 진화의 원칙들에 체현된 것입니다. 같은 페이지는 어느 철학을 따르든 아키텍처는 추상이지 산출물이 아니라고 적습니다. 표준은 아키텍처의 표현과 문서화에 쓰는 산출물을 가리킬 때 아키텍처 기술이라는 다른 말을 쓴다고 덧붙입니다. 같은 페이지가 앞선 판인 IEEE 1471:2000 의 정의도 나란히 적어 둡니다. 그쪽은 시스템의 근본적인 조직으로, 그 구성 요소들과 그것들이 서로 및 환경에 대해 맺는 관계, 그리고 설계와 진화를 이끄는 원칙들에 체현된 것이었습니다.

SEI(Software Engineering Institute, 소프트웨어공학연구소)는 소프트웨어 아키텍처의 현대적 정의와 고전적 정의와 서지적 정의의 목록을 모았다고 스스로 적습니다. 그 목록 안에서 Bass 와 Clements 와 Kazman 은 2003년 판 Software Architecture in Practice 에서 이렇게 적었습니다. 프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 그 시스템의 구조 또는 구조들입니다. 이 구조는 소프트웨어 요소들과 그 요소들의 밖에서 보이는 속성들과 그것들 사이의 관계로 이뤄진다는 것입니다.

같은 목록은 Perry 와 Wolf 의 1992년 정의를 특정한 형식을 갖는 아키텍처 요소들의 집합이라고 옮깁니다. 그들이 처리 요소와 데이터 요소와 연결 요소를 구분했다고 덧붙입니다. 이 분류는 대체로 다른 대부분의 정의와 접근에도 이어집니다. Garlan 과 Perry 의 1995년 정의도 실려 있습니다. 프로그램이나 시스템의 구성 요소들의 구조와 그것들 사이의 관계, 그리고 시간에 따른 그 설계와 진화를 지배하는 원칙과 지침입니다. SEI 는 이 정의가 자기네 기관의 주간 토론 모임에서 나왔다는 것까지 밝혀 적습니다.

결정 쪽에 무게를 두는 정의는 따로 있습니다. 워킹그룹 사이트는 최근의 정의들이 아키텍처를 결정의 망으로 강조해 왔다고 적습니다. 그 자리에서 Kruchten 의 The Rational Unified Process 를 인용합니다. 그쪽에서 아키텍처는 소프트웨어 시스템의 조직에 관한 유의미한 결정들의 집합입니다. 시스템을 이루는 구조적 요소들과 그 인터페이스의 선택이 거기에 들어갑니다. 그 요소들 사이의 협력으로 명세되는 행위, 그 요소들을 점점 더 큰 하위 시스템으로 조합하는 방식, 이 조직을 이끄는 아키텍처 양식도 함께 들어갑니다. SEI 의 목록도 같은 정의를 1999년 Rational Unified Process 의 것으로 나란히 싣고 있습니다.

어느 쪽이 맞는지는 여기서 판정하지 않습니다. 한쪽은 요소와 관계와 원칙으로 적습니다. 다른 쪽은 구조와 밖에서 보이는 속성으로 적습니다. 또 다른 쪽은 유의미한 결정들의 집합으로 적습니다.

관련 항목

가르는 방식

레이어드 · 헥사고날 · 클린 아키텍처 · 마이크로서비스 · 모놀리스 · 모듈러 모놀리스 · 이벤트 주도 · 파이프-필터 · CQRS(Command Query Responsibility Segregation, 명령과 조회 책임 분리) · 아키텍처 양식

겨냥하는 성질

품질 속성 · 결합도 · 응집도 · 관심사 분리 · 확장성 · 가용성 · 바꾸기 쉬움

적어 두는 형식

아키텍처 결정 기록 · 아키텍처 기술 · 4+1 뷰 · C4 모델 · 컨텍스트 다이어그램

조직과 얽히는 개념

콘웨이의 법칙 · 경계 컨텍스트 · 도메인 주도 설계 · 팀 경계

자주 터지는 문제

신 객체 · 순환 의존 · 기술 부채