아키텍처 기술

아키텍처 기술은 시스템의 큰 구조를 글과 그림으로 적어 내서 여러 사람이 같은 구조를 보게 해 줍니다. 이 이름의 「기술」은 테크놀로지가 아니라 「적어 냄」이라는 뜻입니다. 한 장에 다 담지 않습니다. 읽는 사람이 묻는 질문마다 다른 각도의 그림을 따로 그립니다.

쉽고 빠른 이해

무슨 일을 하나 — 시스템의 구조를 문서와 그림 묶음으로 남깁니다. 쇼핑몰 주문 시스템이라면 「서버가 몇 대 어디에 있나」 그림, 「코드 묶음끼리 누가 누구를 부르나」 그림, 「왜 결제를 큐로 넘겼나」 메모가 한 묶음입니다.

왜 하나 — 구조가 머릿속에만 있으면 사람마다 다르게 기억합니다. 그 사람이 팀을 떠나면 구조를 아는 사람도 사라집니다. 새로 온 개발자와 운영 담당과 보안 담당은 저마다 다른 것을 묻습니다.

어떻게 도나

1. 누가 이 문서를 읽고 무엇을 물을지 먼저 적습니다
2. 질문 묶음마다 어떤 그림을 어떤 기호로 그릴지 정합니다
3. 그 약속대로 그림을 그리고 결정마다 이유를 붙입니다

대가 — 코드가 바뀌어도 문서는 저절로 안 바뀝니다. 그림이 여러 장이면 서로 어긋나지 않게 맞추는 품도 듭니다.

상세

이 절은 쇼핑몰의 주문 시스템 하나를 예로 삼습니다. 고객이 주문하면 주문 서버가 결제를 부릅니다. 주문 내용은 데이터베이스에 남습니다. 아키텍처와 그 기술을 가르는 데서 시작해서, 기술 한 벌을 이루는 요소를 하나씩 봅니다.

아키텍처와 그것을 적은 것

건물은 도면이 없어도 서 있습니다. 도면은 그 건물을 종이에 옮겨 적은 것입니다. 전기 기사와 배관공은 같은 건물을 두고 서로 다른 도면을 펴 봅니다.

소프트웨어 아키텍처는 시스템을 이루는 큰 덩어리와 그 덩어리 사이의 관계입니다. 어디서 무엇을 갈라 놓을지 정한 원칙도 함께 가리킵니다. 이 구조는 아무도 적어 두지 않아도 시스템 안에 있습니다. 주문 서버가 결제 서버를 부른다는 사실은 문서가 없어도 코드에 박혀 있습니다.

아키텍처 기술은 그 아키텍처를 겉으로 드러내는 산출물입니다. 영어 이름은 architecture description 입니다. 형식은 정해져 있지 않습니다. 문서 한 벌이어도 됩니다. 위키 페이지 여러 장이나 모델링 도구 안의 그림 묶음이어도 됩니다.

이름의 「기술」

이 이름의 「기술」은 「기술 스택」의 기술이 아닙니다. description 을 옮긴 말이라 「적어 냄」이라는 뜻입니다. 한자로는 記述입니다. 「아키텍처 설명서」라고 읽으면 뜻이 맞습니다.

없으면 생기는 일

구조를 적어 두지 않으면 구조는 몇 사람의 기억에만 남습니다. 같은 팀이어도 기억하는 그림이 조금씩 다릅니다. 새로 온 사람은 코드를 거슬러 읽으며 구조를 짐작해야 합니다.

바꾸기 전에 견줄 수도 없습니다. 「결제를 동기 호출로 둘까, 큐로 넘길까」를 따지려면 지금 구조와 바꾼 뒤 구조가 둘 다 적혀 있어야 합니다. 적혀 있어야 여럿이 같은 그림을 보고 이야기합니다.

이해관계자와 관심사

아키텍처 기술은 무엇을 그릴지부터 정하지 않습니다. 누가 읽을지부터 정합니다. 이 시스템에 이해가 걸린 사람이나 집단을 이해관계자(stakeholder)라고 부릅니다. 주문 시스템이라면 개발자, 운영 담당, 보안 담당, 기획자가 이해관계자입니다.

관심사(concern)는 이해관계자가 시스템에 대해 궁금해하거나 걱정하는 것입니다. 기능, 구조, 비용, 안전, 고치기 쉬움이 모두 관심사가 됩니다. 관심사 분리라는 말의 그 관심사와 같은 낱말입니다.

같은 시스템을 두고도 사람마다 관심사가 다릅니다. 주문 시스템에서 관심사를 질문 꼴로 적으면 대략 이렇게 갈립니다. 표의 질문 하나하나가 관심사 하나입니다.

네 관심사는 그림 한 장으로 답이 안 됩니다. 모듈 그림에는 서버 대수가 안 보입니다. 서버 그림에는 카드 정보가 지나는 길이 안 보입니다. 그래서 아키텍처 기술은 관심사 묶음마다 그림을 따로 둡니다.

관점과 뷰

관심사 묶음 하나에 답하는 그림을 그리려면 먼저 약속이 필요합니다. 어떤 관심사에 답하는지, 무슨 기호로 그리는지, 그린 것을 어떻게 읽는지를 정해 둬야 합니다. 이 약속 묶음이 관점(viewpoint)입니다.

예를 들어 배포 관점은 「어느 프로그램이 어느 서버에서 도나」에 답하는 약속입니다. 상자는 서버, 상자 안의 이름은 프로그램, 선은 네트워크 연결로 그린다고 정해 둡니다. 운영 담당이 주로 이 관점의 그림을 읽습니다.

뷰(view)는 그 약속대로 특정 시스템을 그린 결과물입니다. 주문 시스템의 배포 뷰에는 「주문 서버 두 대, 결제 서버 한 대, 데이터베이스 한 대」가 그려집니다. 관점이 서류 양식이라면 뷰는 그 양식에 채워 넣은 서류 한 장입니다.

둘을 가르는 까닭은 약속을 다시 쓰기 위해서입니다. 배포 관점을 한 번 정해 두면 결제 시스템을 그릴 때도 같은 약속으로 그립니다. 그러면 다른 시스템의 배포 뷰도 같은 방법으로 읽을 수 있습니다.

한 벌을 이루는 요소

지금까지 나온 요소는 서로 물려 있습니다. 이해관계자는 관심사를 갖습니다. 관점은 그 관심사 일부를 맡아 답할 약속을 세웁니다. 뷰는 그 약속대로 그려집니다.

flowchart TD
    subgraph 기술["아키텍처 기술 한 벌"]
        S["이해관계자"] -->|갖는다| C["관심사"]
        P["관점"] -->|답할 것을 고른다| C
        P -->|그리는 약속을 준다| V["뷰"]
    end
    V -->|드러낸다| A["아키텍처"]

그림 아래쪽의 아키텍처가 묶음 밖에 있다는 점을 보면 됩니다. 아키텍처는 시스템 안에 있습니다. 아키텍처 기술은 그것을 드러내는 묶음입니다.

뷰 사이의 대응

뷰가 여러 장이면 서로 맞아야 합니다. 모듈 뷰에 있는 「결제 모듈」이 배포 뷰에서는 어느 서버에서 도는지 이어져 있어야 합니다. 이 이음이 없으면 두 뷰가 서로 다른 시스템을 그린 것처럼 읽힙니다.

뷰 사이의 요소를 이어 주는 관계가 대응(correspondence)입니다. 「모듈 뷰의 결제 모듈은 배포 뷰의 결제 서버에서 돈다」가 대응 하나입니다. 대응을 적어 두면 한 뷰를 고칠 때 함께 고쳐야 할 뷰를 찾을 수 있습니다.

결정과 근거

아키텍처 기술은 구조만 담지 않습니다. 왜 그렇게 정했는지도 담습니다. 내린 결정의 이유와 고르지 않은 대안을 적은 것을 근거(rationale)라고 부릅니다.

주문 시스템이 결제를 메시지 큐로 넘기기로 했다고 합시다. 근거에는 「결제 서버가 느려져도 주문 접수는 멈추지 않게 하려고」가 적힙니다. 버린 대안인 「결제 서버를 바로 부르는 동기 호출」과 버린 이유도 함께 적힙니다.

근거가 없으면 뒤에 온 사람은 그 결정을 되돌려도 되는지 판단할 수 없습니다. 이유가 남아 있으면 「그 조건이 아직 맞나」만 확인하면 됩니다. 결정 하나를 짧은 문서 하나로 남기는 아키텍처 결정 기록, 줄여서 ADR(Architecture Decision Record)이 근거를 남기는 흔한 방법입니다.

관점을 미리 묶어 둔 틀

팀마다 관점을 처음부터 지으면 품이 많이 듭니다. 그래서 자주 쓰는 관점을 미리 묶어 둔 틀이 여럿 있습니다. 이런 틀이 아키텍처 프레임워크입니다. 소프트웨어 개발자가 자주 만나는 묶음은 아래 셋입니다.

어느 틀을 고르든 아키텍처 기술의 뼈대는 같습니다. 읽는 사람과 그들의 관심사가 먼저 있습니다. 관점과 뷰는 그 관심사에 답합니다. 틀은 그 관점 목록을 미리 채워 줄 뿐입니다.

상자와 선이 무엇을 뜻하는지까지 정해 둔 언어도 있습니다. ArchiMate 가 그런 언어입니다. 이런 기호 체계가 아키텍처 기술 언어입니다. 이런 언어를 쓰면 관점마다 기호를 새로 정하지 않아도 됩니다.

이 낱말들을 정한 표준

아키텍처 기술 한 벌에 어떤 요소가 들어가야 하는지는 국제 표준 ISO/IEC/IEEE 42010 이 정합니다. 문서 형식이나 그림 기호는 정하지 않습니다. 앞에서 본 이해관계자, 관심사, 관점, 뷰, 대응, 근거가 그 요소입니다.

이름 앞머리는 이 표준을 함께 낸 세 기관(International Organization for Standardization · International Electrotechnical Commission · Institute of Electrical and Electronics Engineers)의 머리글자입니다.

쓰는 때와 덜 쓰는 때

아키텍처 기술은 읽는 사람이 많을수록 값이 커집니다. 여러 팀이 한 시스템을 나눠 맡을 때, 사람이 자주 바뀔 때, 큰 구조 변경을 앞두고 대안을 견줄 때가 그렇습니다. 감사나 인증 심사가 구조 문서를 요구하는 분야에서도 씁니다.

혼자 만드는 작은 프로그램이나 곧 버릴 시제품에서는 덜 씁니다. 묻는 사람이 적으니 적는 품이 돌려받는 것보다 큽니다. 이때는 결정 몇 개만 ADR 로 남기는 식으로 줄이기도 합니다.

대가는 낡음입니다. 코드는 매일 바뀌어도 그림은 누가 고치기 전까지 그대로 남습니다. 낡은 그림은 없는 그림보다 독자를 더 멀리 데려갑니다. 그래서 문서를 코드 저장소에 같이 두고 코드와 함께 리뷰하는 docs as code 방식을 쓰기도 합니다.

관련 항목

아키텍처 기술 한 벌을 이루는 요소

이해관계자 · 관심사 · 아키텍처 관점 · 아키텍처 뷰 · 아키텍처 모델 · 모델 종류 · 대응 (아키텍처) · 아키텍처 근거 · 아키텍처 결정

이것이 드러내는 대상

소프트웨어 아키텍처 · 아키텍처 양식 · 품질 속성 · 관심사 분리 · 시스템 아키텍처 · 엔터프라이즈 아키텍처

관점을 미리 묶어 둔 프레임워크

아키텍처 프레임워크 · 4+1 뷰 · C4 모델 · Views and Beyond · TOGAF · RM-ODP · arc42

그림을 그리는 언어와 표기

아키텍처 기술 언어 · UML · SysML · ArchiMate · 컨텍스트 다이어그램 · 배포 다이어그램 · 컴포넌트 다이어그램

근거와 결정을 남기는 문서

아키텍처 결정 기록 · MADR · Y-statement · 설계 문서 · docs as code

아키텍처 기술과 그 작업을 다루는 표준

ISO/IEC/IEEE 42010 · IEEE 1471 · ISO/IEC/IEEE 42020 · ISO/IEC/IEEE 42030

기술을 바탕으로 구조를 따지는 평가 방법

ATAM · 아키텍처 평가 · 아키텍처 리뷰