4+1 뷰

4+1 뷰는 소프트웨어 아키텍처 하나를 네 방향에서 나눠 그립니다. 한 장에 다 담은 그림은 무엇을 그린 건지 흐려지기 때문입니다. 네 그림은 저마다 다른 사람의 물음에 답합니다. 다섯째인 「+1」은 몇 가지 사용 장면으로 네 그림이 서로 맞는지 확인합니다.

쉽고 빠른 이해

4+1 뷰는 시스템 설계도를 한 장이 아니라 여러 장으로 나눠 그립니다. 쇼핑몰이라면 「어떤 기능 덩어리가 있나」, 「무엇이 동시에 도나」, 「코드는 어떻게 나눴나」, 「어느 서버에 올렸나」를 따로 그립니다.

한 장에 다 그리면 상자 하나가 프로그램인지 코드 묶음인지 서버인지 알 수 없습니다. 같은 그림을 보고 개발자와 운영자가 서로 다른 것을 읽습니다.

순서는 이렇습니다.

1. 기능, 실행, 코드, 서버의 네 관점마다 그림을 하나씩 그립니다
2. 「고객이 주문하고 결제한다」 같은 중요한 사용 장면을 몇 개 고릅니다. 이 장면이 이름 속 「+1」입니다
3. 그 장면을 네 그림 위에서 따라가며 빠진 데가 없는지 봅니다

대가는 그림이 여러 벌로 늘어난다는 것입니다. 시스템이 바뀔 때마다 여러 장을 같이 고쳐야 합니다. 그래서 작은 시스템이면 몇 장을 빼거나 합칩니다.

상세

이 절은 먼저 그림 한 장이 왜 모자란지를 봅니다. 그다음 네 그림이 각각 무엇을 보여 주는지, 다섯째인 사용 장면이 왜 「+1」인지를 차례로 짚습니다. 예로는 온라인 쇼핑몰의 주문 시스템 하나를 끝까지 씁니다.

상자와 화살표 한 장의 한계

소프트웨어 아키텍처는 시스템을 이루는 큰 덩어리들과 그것들이 이어지는 방식을 말합니다. 이것을 설명하는 문서에는 흔히 상자와 화살표로 된 그림이 한 장 들어갑니다. 예를 들어 「주문」, 「결제」, 「데이터베이스」 상자가 화살표로 이어진 그림입니다.

이런 그림은 깔끔해 보이지만 읽는 사람마다 다르게 읽습니다. 「주문」 상자는 돌고 있는 프로그램일 수도 있고 소스 코드의 한 묶음일 수도 있습니다. 서버 한 대를 그린 것일 수도 있습니다. 화살표도 함수 호출인지, 코드끼리의 의존인지, 데이터가 흐르는 방향인지 그림만으로는 모릅니다.

이렇게 뒤섞이는 까닭은 그림 한 장이 여러 사람의 물음에 한꺼번에 답하려 들기 때문입니다. 기획자는 기능이 궁금합니다. 개발자는 코드 구조가 궁금합니다. 운영자는 서버를 어떻게 놓았는지가 궁금합니다.

뷰와 이해관계자

4+1 뷰는 그림을 나눠서 이 문제를 풉니다. 한 관점에서만 본 아키텍처 그림을 뷰라고 부릅니다. 데이터베이스의 뷰나 화면의 뷰와는 다른 말입니다. 「보는 방향」이라는 원래 뜻에 가깝습니다.

뷰 하나는 한 가지 물음에만 답합니다. 그래서 상자와 화살표가 무엇을 뜻하는지가 그 뷰 안에서는 하나로 정해집니다. 프로그램과 서버가 한 그림에 섞이지 않습니다.

뷰마다 그 그림을 주로 보는 사람이 따로 있습니다. 시스템이 어떻게 만들어지는지에 이해가 걸린 사람을 이해관계자라고 부릅니다. 최종 사용자, 개발자, 운영자, 프로젝트 관리자가 모두 이해관계자입니다.

논리 뷰

논리 뷰는 시스템이 사용자에게 주는 기능을 어떤 덩어리들이 나눠 맡는지 그립니다. 주문 시스템에서는 회원, 상품, 주문, 결제 같은 업무 개념이 상자가 됩니다. 화살표는 「주문은 상품 여러 개를 담는다」, 「결제는 주문 하나에 붙는다」 같은 관계입니다.

논리 뷰는 서버도 코드 파일도 신경 쓰지 않습니다. 기능이 무엇으로 이루어졌는지만 봅니다. 그래서 최종 사용자나 기획자처럼 업무를 아는 사람과 이야기할 때 씁니다. 객체 지향으로 설계한다면 주요 클래스와 그 관계를 그린 그림이 여기 들어갑니다.

프로세스 뷰

프로세스 뷰는 시스템이 돌아가는 동안 무엇이 동시에 실행되는지 그립니다. 상자는 따로 도는 실행 단위입니다. 화살표는 그 사이에 오가는 요청이나 메시지입니다.

실행 단위의 대표가 프로세스입니다. 운영체제가 메모리를 따로 떼어 주고 돌리는 프로그램 하나를 말합니다.

프로세스 하나 안에서 여러 흐름을 나란히 돌리기도 합니다. 그 흐름 하나하나가 스레드입니다. 스레드도 프로세스 뷰에서 상자 하나가 됩니다.

주문 시스템에서는 주문 요청을 받는 API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스) 프로세스가 상자 하나입니다. 결제를 뒤에서 처리하는 워커 프로세스가 또 하나입니다. 두 프로세스 사이에는 큐를 둡니다. API 프로세스가 주문을 큐에 넣으면 워커 프로세스가 꺼내 결제합니다.

프로세스 뷰에서는 성능과 동시성이 드러납니다. 요청이 몰리면 어느 프로세스를 늘려야 하는지, 워커 프로세스가 죽으면 무엇이 멈추는지를 여기서 봅니다. 주로 보는 사람은 시스템 통합 담당자입니다. 따로 만든 부품을 한 시스템으로 엮고, 요청이 몰려도 버티도록 맞추는 일을 합니다.

개발 뷰

개발 뷰는 소스 코드가 어떻게 나뉘어 있는지 보여 줍니다. 상자는 모듈이나 패키지, 라이브러리 같은 코드 묶음입니다. 화살표는 「이 코드가 저 코드를 가져다 쓴다」는 의존입니다.

주문 시스템을 예로 들면 order 모듈과 payment 모듈, 둘이 같이 쓰는 common 라이브러리가 상자가 됩니다. 코드를 레이어로 나눴다면 의존 방향도 여기 그립니다. 컨트롤러는 서비스만 부르고 서비스는 저장소만 부른다는 식입니다.

개발 뷰는 개발자와 관리자가 봅니다. 어느 팀이 어느 모듈을 맡을지, 무엇을 먼저 빌드해야 하는지가 이 그림에서 정해집니다. 구현 뷰라고도 부릅니다.

물리 뷰

물리 뷰는 소프트웨어를 어느 기계에 올려 돌리는지 그립니다. 상자는 서버나 네트워크 장비 같은 하드웨어입니다. 화살표는 그 사이의 네트워크 연결입니다.

주문 시스템은 로드 밸런서 뒤에 API 서버 두 대를 둡니다. 로드 밸런서는 들어온 요청을 여러 서버에 나눠 주는 장비입니다. 그 옆에 워커 서버 한 대와 데이터베이스 서버가 따로 놓입니다. 데이터베이스를 복제해 두었다면 주 서버와 복제 서버를 따로 그립니다.

물리 뷰의 핵심은 프로세스 뷰에서 그린 실행 단위가 어느 서버에 올라가는지입니다. 아래 그림에서 바깥 상자는 서버입니다. 그 안의 이름은 그 서버에서 도는 프로세스입니다. 데이터베이스 서버 안에서는 데이터베이스 프로그램이 프로세스로 돕니다.

flowchart TD
    LB["로드 밸런서"]
    subgraph S1["API 서버 1"]
        A1["API 프로세스"]
    end
    subgraph S2["API 서버 2"]
        A2["API 프로세스"]
    end
    subgraph S3["워커 서버"]
        W["워커 프로세스"]
    end
    subgraph D1["데이터베이스 주 서버"]
        P["데이터베이스 프로세스"]
    end
    subgraph D2["데이터베이스 복제 서버"]
        R["데이터베이스 프로세스"]
    end
    LB --> S1
    LB --> S2
    S1 --> D1
    S2 --> D1
    S3 --> D1
    D1 -->|복제| D2

API 프로세스는 두 대에 똑같이 올라가 있습니다. 워커 프로세스는 따로 한 대를 씁니다. 세 서버가 모두 데이터베이스 주 서버로 연결됩니다. 서버를 꾸리고 운영하는 사람이 이 그림을 주로 봅니다. 배포 뷰라고도 부릅니다.

네 뷰에서 상자와 화살표가 뜻하는 것

네 뷰를 나란히 놓으면 같은 상자와 화살표가 뷰마다 다른 것을 가리킵니다.

처음에 본 한 장짜리 그림이 헷갈렸던 것은 이 네 줄을 한 그림에 섞었기 때문입니다.

시나리오와 「+1」

네 뷰를 다 그려도 그것들이 서로 맞는지는 아직 모릅니다. 논리 뷰의 「결제」가 프로세스 뷰의 어느 실행 단위에서 돌고 물리 뷰의 어느 서버에 올라가는지 이어 봐야 합니다. 이 일을 다섯째 뷰인 시나리오가 맡습니다.

시나리오는 시스템이 쓰이는 중요한 장면 몇 개입니다. 「고객이 상품을 담아 주문하고 결제한다」가 그런 장면입니다. 요구사항 전부가 아니라 구조에 영향이 큰 것만 추립니다.

사용자가 시스템으로 이루려는 일 하나를 처음부터 끝까지 적은 것을 유스케이스라고 합니다. 시나리오는 그런 유스케이스 가운데 몇 개를 골라 둔 것입니다.

장면 하나를 네 뷰 위에서 차례로 따라갑니다. 주문 장면이라면 뷰마다 확인하는 것은 이렇습니다.

어느 줄에서 막히면 그 뷰에 빠진 것이 있다는 뜻입니다.

시나리오는 새 구조를 보태지 않습니다. 네 뷰에 이미 있는 상자와 화살표를 다시 쓸 뿐입니다. 그래서 다섯이라 하지 않고 「4+1」이라 부릅니다.

시나리오는 두 번 쓰입니다. 설계하는 동안에는 장면을 따라가며 필요한 상자를 찾아냅니다. 설계가 끝난 뒤에는 네 뷰가 그 장면을 다 받아 내는지 검증합니다. 테스트를 짤 때 출발점으로도 씁니다.

다 그리지 않아도 되는 경우

모든 시스템에 다섯 뷰가 다 필요하지는 않습니다. 서버 한 대에서만 돈다면 물리 뷰에 그릴 것이 거의 없습니다. 프로그램이 프로세스 하나로만 돈다면 프로세스 뷰도 뺄 수 있습니다.

아주 작은 시스템은 논리 뷰와 개발 뷰가 거의 같아집니다. 업무 개념 하나가 코드 묶음 하나와 맞아떨어지기 때문입니다. 그때는 둘을 한 장으로 합칩니다. 시나리오는 시스템 크기와 상관없이 쓸모가 있습니다.

거꾸로 팀이 여럿이고 서버가 여러 대로 흩어진 시스템일수록 뷰를 나눠 얻는 것이 커집니다. 궁금한 것이 서로 다른 사람이 그만큼 많기 때문입니다.

그림이 늘어나는 대가

뷰를 나누면 그림이 여러 벌로 늘어납니다. 같은 「주문」이 논리 뷰에서는 개념으로, 개발 뷰에서는 모듈로, 프로세스 뷰에서는 실행 단위로 따로 나옵니다. 하나가 바뀌면 나머지도 같이 고쳐야 합니다.

고치지 않고 두면 그림끼리 어긋납니다. 코드는 이미 모듈을 다시 나눴습니다. 그런데도 개발 뷰는 옛 모양을 보여 줍니다. 그림이 많을수록 이렇게 낡는 그림도 늘어납니다.

다른 기록 방법과의 경계

4+1 뷰는 「누가 무엇을 궁금해하나」로 그림을 나눕니다. C4(Context, Container, Component, Code 네 단계의 머리글자) 모델은 같은 시스템을 얼마나 가까이 들여다보나로 그림을 나눕니다. 시스템 전체 그림에서 시작해 한 단계씩 확대해 들어갑니다.

4+1 뷰의 그림들은 구조가 어떻게 생겼는지를 보여 줍니다. 왜 그렇게 정했는지는 그림에 잘 안 남습니다. 그 이유는 아키텍처 결정 기록 같은 글이 따로 남깁니다.

관련 항목

4+1 뷰가 속하는 상위 분류

소프트웨어 아키텍처 · 아키텍처 기술 · 아키텍처 양식 · 설계 문서

4+1 뷰를 이루는 다섯 뷰

논리 뷰 · 프로세스 뷰 · 개발 뷰 · 물리 뷰 · 시나리오

각 뷰가 그리는 구성 요소

클래스 · 프로세스 · 스레드 · 모듈 · 패키지 · 서버 · 로드 밸런서 · 큐 · 워커 · 복제

뷰를 나누는 기준이 되는 개념

이해관계자 · 관심사 분리 · 유스케이스 · 기능 요구사항 · 비기능 요구사항 · 품질 속성 · 동시성

뷰 안에 그려지는 아키텍처 양식

레이어드 · 마이크로서비스 · 모놀리스 · 모듈러 모놀리스 · 이벤트 주도

아키텍처를 기록하는 다른 방법

C4 모델 · 아키텍처 결정 기록 · UML · IEEE 1471 · 컨텍스트 다이어그램