IEEE 1471

IEEE 1471 은 시스템의 아키텍처를 문서로 남길 때 무엇을 담아야 하는지 정해 줍니다. 출발점은 그 문서를 읽을 사람과 그 사람이 궁금해하는 것입니다. 궁금증마다 그림을 따로 그리게 합니다. 지금은 국제 표준 42010 이 이 표준의 뒤를 잇습니다.

쉽고 빠른 이해

무슨 일을 하나 — 아키텍처 문서에 꼭 들어갈 것을 정해 줍니다. 쇼핑몰 주문 시스템이라면 「이 문서를 누가 읽나」 목록과 그 사람들의 질문이 먼저 들어갑니다. 질문마다 그린 그림과 중요한 결정의 이유가 뒤따릅니다.

왜 이렇게 하나 — 이 표준 전에는 그림을 몇 장, 어떤 각도로 그릴지가 방법론마다 달랐습니다. 쓰는 낱말도 달라서 두 문서를 나란히 놓고 견주기 어려웠습니다.

어떻게 도나

1. 문서를 읽을 사람과 그 사람의 질문을 적습니다
2. 질문 묶음마다 「어떤 그림을 어떤 기호로 그릴지」 약속을 정합니다
3. 그 약속대로 이 시스템의 그림을 그리고 결정마다 이유를 붙입니다

대가 — 어떤 그림을 그릴지는 정해 주지 않습니다. 그래서 약속을 고르는 일이 팀 몫으로 남습니다. 그림이 여러 장이면 서로 어긋나지 않게 맞추는 품도 듭니다.

상세

이 절은 쇼핑몰의 주문 시스템 하나를 예로 삼습니다. 고객이 주문하면 주문 서버가 결제 서버를 부릅니다. 주문 내용은 데이터베이스에 남습니다. 이 시스템의 아키텍처 문서를 이 표준에 맞춰 쓴다면 무엇이 들어가는지를 차례로 봅니다.

이름과 문서 번호

IEEE 는 Institute of Electrical and Electronics Engineers(전기전자기술자협회)를 줄인 이름입니다. 전기·전자·컴퓨터 분야의 표준을 펴내는 단체입니다. 1471 은 이 단체가 이 문서에 붙인 번호입니다. 2000년 9월에 승인되어 IEEE Std 1471-2000 이라고도 적습니다.

정식 제목은 Recommended Practice for Architectural Description of Software-Intensive Systems 입니다. 우리말로 옮기면 「소프트웨어 비중이 큰 시스템의 아키텍처 기술에 관한 권장 실무」입니다.

IEEE 가 펴내는 표준 문서는 성격에 따라 갈립니다. 반드시 지켜야 할 요구를 담는 표준(standard)이 있고, 권하는 방법을 담는 권장 실무(recommended practice)가 있습니다. IEEE 1471 은 뒤쪽입니다.

제목의 「기술」은 테크놀로지가 아닙니다. description 을 옮긴 말이라 「적어 냄」이라는 뜻입니다. 「아키텍처 설명서」라고 읽으면 뜻이 맞습니다.

「소프트웨어 비중이 큰 시스템」은 소프트웨어가 설계와 동작에 큰 몫을 하는 시스템을 말합니다. 순수한 소프트웨어 제품만이 아닙니다. 하드웨어가 섞여 있어도 소프트웨어가 시스템 전체를 좌우하면 여기에 듭니다.

아키텍처와 그것을 적은 문서

소프트웨어 아키텍처는 시스템을 이루는 큰 덩어리와 그 사이의 관계입니다. 설계와 변경을 이끄는 원칙도 함께 가리킵니다. IEEE 1471 은 이것을 시스템의 근본적인 조직이라고 부릅니다.

이 구조는 아무도 적지 않아도 시스템 안에 있습니다. 주문 서버가 결제 서버를 부른다는 것은 문서가 없어도 코드에 박혀 있습니다. 아키텍처 기술은 그 구조를 겉으로 드러낸 산출물입니다. 문서 한 벌일 수도 있습니다. 위키 페이지 여러 장이나 모델링 도구 안의 그림 묶음일 수도 있습니다.

IEEE 1471 이 다루는 것은 아키텍처 자체가 아니라 이 산출물입니다. 구조를 적은 문서에 무엇이 들어가야 하는지를 정합니다.

이해관계자와 관심사

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

이해관계자가 시스템을 두고 궁금해하거나 걱정하는 것을 관심사(concern)라고 부릅니다. 운영 담당은 「서버가 몇 대이고 하나가 죽으면 어떻게 되나」를 묻습니다. 보안 담당은 「카드 번호가 어느 구간을 지나가나」를 묻습니다.

관심사가 다르면 답이 되는 그림도 다릅니다. 한 장에 다 그리면 운영 담당은 보안 표시를 건너뛰며 읽어야 합니다. 보안 담당은 서버 대수를 건너뛰며 읽어야 합니다. 그래서 이 표준은 그림을 관심사별로 나눕니다.

관점과 뷰

건물 도면에 빗대 보겠습니다. 「전기 배선도는 이런 기호로 이렇게 그린다」는 약속이 하나 있습니다. 그 약속을 따라 어느 한 건물의 배선을 그린 종이가 따로 있습니다. 약속은 어느 건물에나 씁니다. 종이는 그 건물 하나의 것입니다.

관점(viewpoint)은 앞의 약속에 해당합니다. 한 종류의 그림을 그리는 규칙입니다. 어떤 관심사에 답하는 그림인지, 어떤 기호를 쓰는지, 어떻게 그리고 어떻게 검토하는지를 적어 둡니다. 특정 시스템에 매이지 않아서 다른 시스템에도 다시 씁니다.

뷰(view)는 그 규칙을 따라 이 시스템 하나를 그려 낸 결과물입니다. 배포 관점이 「서버와 네트워크를 상자와 선으로 그린다」고 정해 두었다고 합시다. 주문 시스템의 배포 뷰는 그 규칙을 이 시스템에 적용해 그린 것입니다.

뷰는 모델을 하나 이상 담습니다. 모델은 뷰 안에 든 도표 하나하나입니다. 주문 시스템의 배포 뷰라면 서버 배치도가 그런 모델입니다. 지금까지 나온 낱말을 운영 담당의 질문 하나로 이으면 이렇습니다.

flowchart TD
    S["이해관계자 · 운영 담당"] -->|품는다| C["관심사 · 서버가 몇 대인가"]
    C -->|이 관심사를 다루는 규칙| V["관점 · 배포 관점"]
    V -->|이 규칙대로 그린다| W["뷰 · 주문 시스템의 배포 뷰"]
    W -->|담는다| M["모델 · 서버 배치도"]

위의 세 칸은 시스템을 가리지 않습니다. 운영 담당과 그 질문과 배포 관점은 다른 쇼핑몰에도 똑같이 있습니다. 아래 두 칸만 이 주문 시스템의 것입니다.

관점과 뷰를 가른 까닭

둘을 가르면 관점을 다시 쓸 수 있습니다. 조직은 경험으로 관점을 모아 둡니다. 새 시스템을 맡으면 그중에서 골라 꺼냅니다. 뷰만 시스템마다 새로 그립니다.

관점을 같은 꼴로 적어 두면 문서끼리 견줄 수도 있습니다. 두 팀이 서로 다른 그림을 그렸어도 「어느 관심사에 답하는 어느 관점의 뷰인가」로 맞대어 볼 수 있습니다.

이 표준 전에도 아키텍처를 여러 그림으로 나눠 그리는 방법은 있었습니다. 다만 그림을 몇 장, 어떤 각도로 그릴지는 방법론마다 달랐습니다. 쓰는 낱말도 달라서 두 방법론으로 쓴 문서를 나란히 놓고 견주기 어려웠습니다.

4+1 뷰가 그런 방법론의 하나입니다. 논리·개발·프로세스·물리 네 그림에 시나리오를 더해 아키텍처를 그립니다. 이 표준의 낱말로 옮기면 다섯 그림은 미리 골라 둔 관점 다섯 개가 됩니다.

정해 주지 않는 것

IEEE 1471 은 어떤 관점을 쓰라고 정하지 않습니다. 시스템마다 이해관계자와 관심사가 다르기 때문입니다. 공장 설비를 움직이는 제어 장치와 사내 게시판은 걱정할 것부터 다릅니다. 관점은 문서를 쓰는 쪽이 고릅니다.

그림의 표기도 정하지 않습니다. UML(Unified Modeling Language, 통합 모델링 언어)은 소프트웨어 구조를 그림으로 그리는 표준 기호 체계입니다. 이 표준 아래서 UML 은 관점이 고를 수 있는 표기 가운데 하나입니다.

아키텍처 기술 언어도 고를 수 있습니다. 아키텍처를 그리려고 따로 만든 표기 언어를 이렇게 부릅니다. 팀이 만든 기호도 관점에 적어 두면 쓸 수 있습니다.

뷰끼리 위아래도 두지 않습니다. 코드 구조를 그린 뷰가 으뜸이고 나머지는 거기서 끌어낸다고 보지 않습니다. 모든 뷰가 각자의 관심사에 답하는 같은 무게의 그림입니다.

문서를 만드는 절차도 정하지 않습니다. 다 쓴 문서에 무엇이 들어 있어야 하는지만 말합니다.

따른다고 말하려면 갖출 내용

어떤 아키텍처 문서가 IEEE 1471 을 따른다고 말하려면 아래가 들어 있어야 합니다. 오른쪽 칸은 주문 시스템 문서라면 무엇을 적는지입니다.

표에서 눈여겨볼 줄은 마지막 둘입니다. 그림이 여러 장이면 서로 어긋나는 데가 생깁니다. 이 표준은 어긋남을 다 없애라고 하지 않습니다. 알고 있는 어긋남을 적어 두라고 합니다. 읽는 사람이 두 그림 중 무엇을 믿을지 헤매지 않게 하려는 것입니다.

근거는 결정의 이유입니다. 그림은 「결제를 큐로 넘긴다」는 결과만 보여 줍니다. 이유가 안 적혀 있으면 몇 해 뒤에는 아무도 왜 큐를 썼는지 모릅니다. 결정 하나마다 이유를 짧은 글로 따로 남기는 방식으로는 아키텍처 결정 기록이 있습니다.

국제 표준으로 옮겨 간 판

IEEE 1471 은 지금 새로 따르는 표준이 아닙니다. 국제 표준으로 옮겨진 뒤 개정판이 이 표준을 대신했습니다. 새 판 이름 앞의 ISO·IEC 는 함께 펴낸 기관 이름입니다. ISO 는 International Organization for Standardization(국제표준화기구), IEC 는 International Electrotechnical Commission(국제전기기술위원회)입니다.

1471 은 소프트웨어 비중이 큰 시스템에 한정했습니다. 2011 판은 그 범위를 시스템 일반으로 넓혔습니다.

1471 에서는 아키텍처 문서 하나만 이 표준을 따르는지 따졌습니다. 이렇게 표준을 따르는지 따지는 것을 적합성(conformance)이라고 합니다. 2011 판은 적합성을 따지는 대상을 둘 더 늘렸습니다.

하나는 아키텍처 프레임워크입니다. 한 분야에서 함께 쓰기로 정한 관점 묶음을 이렇게 부릅니다. 다른 하나는 앞에서 본 아키텍처 기술 언어입니다.

이해관계자 · 관심사 · 관점 · 뷰 · 근거라는 뼈대는 1471 이 세웠습니다. 이 뼈대는 새 판에도 이어집니다. 오래된 책과 논문이 IEEE 1471 이라는 이름으로 설명하는 내용이 지금의 42010 과 대부분 겹치는 까닭입니다.

관련 항목

IEEE 1471 과 42010 이 정의하는 개념

이해관계자 · 관심사 · 아키텍처 관점 · 아키텍처 뷰 · 모델 종류 · 아키텍처 근거 · 대응 (아키텍처) · 소프트웨어 집약 시스템

IEEE 1471 을 잇거나 곁에 선 표준

ISO/IEC/IEEE 42010 · ISO/IEC/IEEE 42020 · ISO/IEC/IEEE 42030 · IEEE 1016 · RM-ODP · ISO/IEC/IEEE 12207

관점을 미리 묶어 내놓은 프레임워크와 방법

아키텍처 프레임워크 · 4+1 뷰 · Views and Beyond · TOGAF · DoDAF · 자크만 프레임워크 · C4 모델 · arc42

관점 안에서 고르는 표기와 언어

UML · SysML · ArchiMate · AADL · 아키텍처 기술 언어 · 배포 다이어그램

관점이 다루는 관심사의 갈래

관심사 분리 · 기능 요구사항 · 비기능 요구사항 · 품질 속성

아키텍처 문서 곁에서 결정을 남기고 평가하는 방법

아키텍처 결정 기록 · ATAM · 아키텍처 평가 · 설계 문서 · docs as code

IEEE 1471 이 속하는 상위 분야

소프트웨어 아키텍처 · 아키텍처 기술 · 시스템 아키텍처 · 엔터프라이즈 아키텍처 · 소프트웨어 공학 · 시스템 공학