Architecture Decision Recordarc42의 의사결정 기록 템플릿
1. 소개와 목표
요구사항, 추진 요인에 대한 간단한 설명, 요구사항의 발췌(또는 요약). 주요 이해관계자에게 가장 높은 우선순위를 갖는 아키텍처의 상위 3개(최대 5개) 품질 목표. 아키텍처에 대한 기대와 함께 정리한 중요한 이해관계자 표.
1.1 요구사항 개요
내용
기능 요구사항, 추진 요인에 대한 간단한 설명, 요구사항의 발췌(또는 요약). (있기를 바라는) 요구사항 문서로의 링크와 그것을 어디에서 찾을 수 있는지에 대한 정보.
동기
최종 사용자의 관점에서 시스템은 비즈니스 활동에 대한 지원을 개선하거나 품질을 향상시키기 위해 만들어지거나 수정됩니다.
형식
간단한 텍스트 설명으로, 아마도 표 형식의 사용 사례 형식. 요구사항 문서가 있다면 이 개요는 그 문서들을 참조해야 합니다.
이 발췌는 가능한 한 짧게 유지하십시오. 이 문서의 가독성과 요구사항 문서와의 잠재적 중복 사이의 균형을 맞추십시오.
1.2 품질 목표
내용
주요 이해관계자에게 충족이 가장 중요한 아키텍처의 상위 3개(최대 5개) 품질 목표. 우리는 정말로 아키텍처를 위한 품질 목표를 뜻합니다. 프로젝트 목표와 혼동하지 마십시오. 둘은 반드시 동일하지는 않습니다. ISO 25010 표준은 관심을 가질 만한 잠재적 주제에 대한 훌륭한 개요를 제공합니다.
동기
가장 중요한 이해관계자의 품질 목표를 알아야 합니다. 그것이 근본적인 아키텍처 결정에 영향을 미치기 때문입니다. 이러한 품질에 대해 매우 구체적으로 하고 유행어는 피하십시오. 아키텍트로서 자신의 작업 품질이 어떻게 평가될지 모른다면 …
형식
가장 중요한 품질 목표와 구체적인 시나리오를 우선순위 순으로 정리한 표.
1.3 이해관계자
내용
시스템의 이해관계자, 즉 다음에 해당하는 모든 사람, 역할 또는 조직에 대한 명시적 개요
아키텍처를 알아야 하는
아키텍처에 대해 설득되어야 하는
아키텍처나 코드와 함께 작업해야 하는
업무를 위해 아키텍처 문서가 필요한
시스템이나 그 개발에 대한 결정을 내려야 하는
동기
시스템 개발에 관여하거나 시스템의 영향을 받는 모든 당사자를 알아야 합니다. 그렇지 않으면 개발 과정 후반에 불쾌한 놀라움을 겪을 수 있습니다. 이러한 이해관계자가 작업의 범위와 상세 수준, 그리고 그 결과를 결정합니다.
형식
역할 이름, 사람 이름, 그리고 아키텍처와 그 문서에 대한 그들의 기대를 담은 표.
2. 제약
설계 및 구현 결정이나 관련 프로세스에 대한 결정에서 팀을 제약하는 모든 것. 때로는 개별 시스템을 넘어 조직과 회사 전체에 유효할 수 있습니다.
내용
소프트웨어 아키텍트의 설계 및 구현 결정이나 개발 프로세스에 대한 결정의 자유를 제약하는 모든 요구사항. 이러한 제약은 때로는 개별 시스템을 넘어 조직과 회사 전체에 유효합니다.
동기
아키텍트는 설계 결정에서 어디까지 자유로운지, 그리고 어디에서 제약을 지켜야 하는지 정확히 알아야 합니다. 제약은 항상 다루어져야 하지만 협상 가능할 수도 있습니다.
형식
설명이 달린 제약의 간단한 표. 필요하면 기술적 제약, 조직적 및 정치적 제약, 관례(예: 프로그래밍 또는 버전 관리 지침, 문서화 또는 명명 규칙)로 세분할 수 있습니다
3. 맥락과 범위
시스템을 (외부) 통신 상대(인접 시스템과 사용자)로부터 구분합니다. 외부 인터페이스를 명시합니다. 비즈니스/도메인 관점(항상) 또는 기술적 관점(선택)에서 보여 줍니다
내용
시스템 범위와 맥락은 이름 그대로 시스템(즉 범위)을 모든 통신 상대(인접 시스템과 사용자, 즉 시스템의 맥락)로부터 구분합니다. 그럼으로써 외부 인터페이스를 명시합니다.
필요하다면 비즈니스 맥락(도메인 특화 입력과 출력)을 기술적 맥락(채널, 프로토콜, 하드웨어)과 구분하십시오.
동기
통신 상대와의 도메인 인터페이스와 기술적 인터페이스는 시스템의 가장 중요한 측면에 속합니다. 그것들을 완전히 이해하도록 하십시오.
형식
다양한 맥락 다이어그램
통신 상대와 그 인터페이스의 목록.
3.1 비즈니스 맥락
내용
모든 통신 상대(사용자, IT 시스템 등)의 명세와 도메인 특화 입력 및 출력 또는 인터페이스에 대한 설명. 선택적으로 도메인 특화 형식이나 통신 프로토콜을 추가할 수 있습니다.
동기
모든 이해관계자는 시스템의 환경과 어떤 데이터가 교환되는지 이해해야 합니다.
형식
시스템을 블랙박스로 보여 주고 통신 상대와의 도메인 인터페이스를 명시하는 모든 종류의 다이어그램.
또는(추가로) 표를 사용할 수 있습니다. 표의 제목은 시스템 이름이며, 세 개의 열에는 통신 상대의 이름, 입력, 출력이 들어갑니다.
3.2 기술적 맥락
내용
시스템을 환경과 연결하는 기술적 인터페이스(채널과 전송 매체). 추가로 도메인 특화 입력/출력의 채널로의 매핑, 즉 어떤 입출력이 어떤 채널을 사용하는지에 대한 설명.
동기
많은 이해관계자가 시스템과 그 맥락 사이의 기술적 인터페이스를 바탕으로 아키텍처 결정을 내립니다. 특히 인프라나 하드웨어 설계자가 이러한 기술적 인터페이스를 결정합니다.
형식
예: 인접 시스템으로의 채널을 기술하는 UML 배치 다이어그램과, 채널과 입출력 사이의 관계를 보여 주는 매핑 표.
4. 솔루션 전략
아키텍처를 형성하는 근본적인 결정과 솔루션 전략의 요약. 기술, 최상위 분해, 최상위 품질 목표를 달성하기 위한 접근 방식, 관련 조직적 결정을 포함할 수 있습니다.
내용
시스템 아키텍처를 형성하는 근본적인 결정과 솔루션 전략에 대한 짧은 요약과 설명. 여기에는 다음이 포함됩니다
기술 결정
시스템의 최상위 분해에 대한 결정, 예: 아키텍처 패턴이나 설계 패턴의 사용
핵심 품질 목표를 달성하는 방법에 대한 결정
관련 조직적 결정, 예: 개발 프로세스 선택이나 특정 작업의 제3자 위임.
동기
이러한 결정은 아키텍처의 초석을 이룹니다. 그것들은 다른 많은 상세한 결정이나 구현 규칙의 토대입니다.
형식
이러한 핵심 결정에 대한 설명을 짧게 유지하십시오.
문제 기술, 품질 목표, 주요 제약을 바탕으로 무엇을 결정했고 왜 그렇게 결정했는지 동기를 밝히십시오. 세부 사항은 다음 섹션(구조적 세부 사항은 섹션 5, 횡단 관심사는 섹션 8)을 참조하십시오.
솔루션 접근 방식의 목록이나 표를 사용할 수 있습니다.
5. 빌딩 블록 뷰
시스템의 정적 분해, 소스 코드의 추상화로, 적절한 상세 수준까지 화이트박스(블랙박스를 포함)의 계층으로 보여 줍니다.
내용
빌딩 블록 뷰는 시스템을 빌딩 블록(모듈, 컴포넌트, 서브시스템, 클래스, 인터페이스, 패키지, 라이브러리, 프레임워크, 계층, 파티션, 티어, 함수, 매크로, 연산, 데이터 구조 등)으로 정적 분해한 것과 그 의존성(관계, 연관 등)을 보여 줍니다
이 뷰는 모든 아키텍처 문서에서 필수입니다. 집에 비유하면 이것은 평면도입니다.
동기
추상화를 통해 구조를 이해할 수 있게 만들어 소스 코드에 대한 개요를 유지하십시오.
이를 통해 구현 세부 사항을 드러내지 않고 추상적인 수준에서 이해관계자와 소통할 수 있습니다.
형식
빌딩 블록 뷰는 블랙박스와 화이트박스(아래 그림 참조)의 계층적 모음과 그 설명입니다.
5.1 전체 시스템의 화이트박스
여기에서는 다음 화이트박스 템플릿을 사용하여 전체 시스템의 분해를 기술합니다. 여기에는 다음이 포함됩니다
개요 다이어그램
분해에 대한 동기
포함된 빌딩 블록의 블랙박스 설명. 이에 대해 다음 대안을 제공합니다:
포함된 모든 빌딩 블록과 그 인터페이스에 대한 짧고 실용적인 개요를 위해 하나의 표 사용
블랙박스 템플릿(아래 참조)에 따라 빌딩 블록의 블랙박스 설명 목록 사용. 선택한 도구에 따라 이 목록은 하위 장(텍스트 파일), 하위 페이지(위키) 또는 중첩된 요소(모델링 도구)가 될 수 있습니다.
(선택 사항:) 빌딩 블록의 블랙박스 템플릿에서 설명되지 않지만 화이트박스를 이해하는 데 매우 중요한 중요 인터페이스.
인터페이스를 명시하는 방법이 매우 많으므로 그에 대한 특정 템플릿은 제공하지 않습니다.
가장 좋은 경우에는 예시나 단순한 시그니처로 충분할 것입니다.
5.2 레벨 2
여기에서는 레벨 1의 (일부) 빌딩 블록의 내부 구조를 화이트박스로 명시할 수 있습니다.
시스템의 어떤 빌딩 블록이 그렇게 상세한 설명을 정당화할 만큼 중요한지 결정해야 합니다. 완전성보다 관련성을 선호하십시오. 중요하거나, 놀랍거나, 위험하거나, 복잡하거나, 변동성이 큰 빌딩 블록을 명시하십시오. 시스템의 평범하거나, 단순하거나, 지루하거나, 표준화된 부분은 생략하십시오
5.2.1 빌딩 블록 1의 화이트박스
빌딩 블록 1의 내부 구조를 명시합니다.
화이트박스 템플릿(위 참조)을 사용하십시오.
6. 런타임 뷰
중요한 사용 사례나 기능, 중요한 외부 인터페이스에서의 상호작용, 운영 및 관리, 그리고 오류 및 예외 동작을 다루는 시나리오로서의 빌딩 블록 동작.
내용
런타임 뷰는 다음 영역의 시나리오 형태로 시스템 빌딩 블록의 구체적인 동작과 상호작용을 기술합니다:
중요한 사용 사례나 기능: 빌딩 블록은 그것들을 어떻게 실행합니까?
중요한 외부 인터페이스에서의 상호작용: 빌딩 블록은 사용자 및 인접 시스템과 어떻게 협력합니까?
운영 및 관리: 기동, 시작, 정지
오류 및 예외 시나리오
비고: 가능한 시나리오(시퀀스, 워크플로)를 선택하는 주요 기준은 아키텍처적 관련성입니다. 많은 수의 시나리오를 기술하는 것은 중요하지 않습니다. 대표적인 선택을 문서화하는 편이 낫습니다.
동기
시스템의 빌딩 블록(의 인스턴스)이 런타임에 어떻게 작업을 수행하고 통신하는지 이해해야 합니다. 정적 모델(빌딩 블록 뷰, 배치 뷰)을 읽고 이해하는 데 덜 적극적이거나 덜 능숙한 이해관계자에게 아키텍처를 전달하기 위해 주로 문서에 시나리오를 담게 될 것입니다.
형식
시나리오를 기술하는 표기법은 많습니다. 예를 들어
(자연어로 된) 번호 매긴 단계 목록
액티비티 다이어그램 또는 순서도
시퀀스 다이어그램
BPMN 또는 EPC(이벤트 프로세스 체인)
상태 기계
등.
6.n 런타임 시나리오 n (1, 2, 3 등)
런타임 다이어그램이나 시나리오에 대한 텍스트 설명을 삽입하십시오.
이 다이어그램에 묘사된 빌딩 블록 인스턴스 사이 상호작용의 주목할 만한 측면에 대한 설명을 삽입하십시오.
7. 배치 뷰
환경, 컴퓨터, 프로세서, 토폴로지를 포함한 기술 인프라. (소프트웨어) 빌딩 블록의 인프라 요소로의 매핑.
내용
배치 뷰는 다음을 기술합니다:
지리적 위치, 환경, 컴퓨터, 프로세서, 채널과 네트워크 토폴로지 같은 인프라 요소와 기타 인프라 요소를 포함하여 시스템을 실행하는 데 사용되는 기술 인프라, 그리고
(소프트웨어) 빌딩 블록의 해당 인프라 요소로의 매핑.
시스템은 흔히 개발 환경, 테스트 환경, 운영 환경 같은 서로 다른 환경에서 실행됩니다. 그러한 경우 관련된 모든 환경을 문서화해야 합니다.
특히 소프트웨어가 둘 이상의 컴퓨터, 프로세서, 서버 또는 컨테이너를 가진 분산 시스템으로 실행되거나 자체 하드웨어 프로세서와 칩을 설계하고 제작하는 경우 배치 뷰를 문서화하십시오.
소프트웨어 관점에서는 빌딩 블록의 배치를 보여 주는 데 필요한 인프라 요소를 포착하는 것으로 충분합니다. 하드웨어 아키텍트는 그 이상으로 나아가 포착해야 할 어떤 상세 수준으로든 인프라를 기술할 수 있습니다.
동기
소프트웨어는 하드웨어 없이는 실행되지 않습니다. 이 기반 인프라는 시스템 및/또는 일부 횡단 관심사에 영향을 줄 수 있고 실제로 줄 것입니다. 따라서 인프라를 알아야 합니다.
형식
최상위 수준의 배치 다이어그램은 이미 섹션 3.2에 자체 인프라를 하나의 블랙박스로 둔 기술적 맥락으로 포함되어 있을 수 있습니다. 이 섹션에서는 추가 배치 다이어그램을 사용하여 그 블랙박스를 확대합니다.
UML은 그 뷰를 표현하기 위한 배치 다이어그램을 제공합니다. 인프라가 더 복잡할 때는 아마도 중첩된 다이어그램과 함께 사용하십시오.
(하드웨어) 이해관계자가 UML 배치 다이어그램보다 다른 종류의 다이어그램을 선호한다면, 인프라의 노드와 채널을 보여 줄 수 있는 어떤 종류든 사용하게 하십시오.
7.1 인프라 레벨 1
(보통 다이어그램, 표, 텍스트의 조합으로) 다음을 기술하십시오:
시스템의 여러 위치, 환경, 컴퓨터, 프로세서 등으로의 분산과 그것들 사이의 물리적 연결
이 배치 구조에 대한 중요한 정당화나 동기
인프라의 품질 및/또는 성능 특성
소프트웨어 산출물(빌딩 블록)의 인프라 요소로의 매핑
여러 환경이나 대체 배치의 경우, 관련된 모든 환경에 대해 arc42의 그 섹션을 복사하십시오. **
7.2 인프라 레벨 2
여기에는 인프라 레벨 1의 (일부) 인프라 요소의 내부 구조를 포함할 수 있습니다.
선택한 각 요소에 대해 레벨 1의 구조를 복사하십시오.
8. 횡단 관심사 개념
전반적이고 원칙적인 규정과 시스템의 여러 부분(→ 횡단)에 관련된 솔루션 접근 방식. 개념은 흔히 여러 빌딩 블록과 관련됩니다. 도메인 모델, 아키텍처 패턴과 스타일, 특정 기술 사용 규칙, 구현 규칙 같은 다양한 주제를 포함하십시오.
내용
이 섹션은 횡단 관심사 개념(관행, 패턴, 규정 또는 솔루션 아이디어)을 기술합니다. 그러한 개념은 흔히 여러 빌딩 블록과 관련됩니다. 많은 다양한 주제를 포함할 수 있습니다.
동기
개념은 아키텍처의 개념적 무결성(일관성, 동질성)의 토대를 이룹니다. 따라서 그것은 시스템의 내적 품질을 달성하는 데 중요한 기여입니다.
여기가 그러한 개념의 일관된 명세를 위해 우리가 템플릿에 마련한 곳입니다.
이러한 개념 중 다수는 여러 빌딩 블록과 관련되거나 영향을 미칩니다.
형식
형식은 다양할 수 있습니다:
어떤 구조든 가능한 개념 문서
특히 기술적 개념을 위한 예시 구현
아키텍처 뷰의 표기법을 사용한 횡단 모델 발췌 또는 시나리오
이 섹션의 구조
시스템에 가장 필요한 주제만 골라 이 섹션에서 각각에 레벨 2 제목(예: 8.1, 8.2 등)을 부여하십시오.
- 앞서 언급한 다이어그램의 모든 주제를 다루려고 시도하지 마십시오.
배경
시스템 내의 일부 주제는 흔히 여러 빌딩 블록, 하드웨어 요소 또는 개발 프로세스에 관련됩니다. 그러한 횡단 주제를 관련된 빌딩 블록, 하드웨어 요소 또는 개발 프로세스의 설명에서 반복하는 대신 중앙의 한 곳에서 전달하거나 문서화하는 것이 더 쉬울 수 있습니다.
특정 개념은 시스템의 모든 요소와 관련될 수 있고, 다른 개념은 몇 가지에만 관련될 수 있습니다.
9. 아키텍처 결정
근거를 포함한 중요하고, 비싸고, 결정적이고, 대규모이거나 위험한 아키텍처 결정.
내용
근거를 포함한 중요하고, 비싸고, 대규모이거나 위험한 아키텍처 결정. 여기서 “결정”이란 주어진 기준에 따라 하나의 대안을 선택하는 것을 뜻합니다.
아키텍처 결정을 이 중앙 섹션에 문서화해야 할지, 아니면 로컬하게(예: 한 빌딩 블록의 화이트박스 템플릿 안에) 문서화하는 편이 나을지는 판단에 따라 결정하십시오. 중복된 텍스트는 피하십시오. 아키텍처의 가장 중요한 결정을 이미 담아 둔 섹션 4를 참조하십시오.
동기
시스템의 이해관계자는 당신의 결정을 이해하고 거슬러 추적할 수 있어야 합니다.
형식
모든 중요한 결정에 대한 ADR(아키텍처 의사결정 기록)
중요도와 결과에 따라 정렬된 목록 또는 표, 또는
결정별로 별도 섹션을 둔 더 상세한 형식
배경(ADR에 대하여)
더 작은 문서 조각은 읽고, 작성하고, 유지하기가 더 쉽습니다. 아키텍처 결정에 관해서는 개발 팀이 흔히:
결정은 예를 들어 소스 코드에서 보이기 때문에 알지만
그 결정 뒤의 동기는 놓칩니다(Nygard 2011 참조)
따라서 몇 가지 중요한 결정을 그 동기와 추론과 함께 문서화해야 합니다
결정에 대한 우리의 제안
아키텍처상 중요한 결정, 즉 구조, 품질 특성, 중요한(특히 외부) 의존성과 인터페이스, 또는 구축 기법에 영향을 미치는 결정의 모음을 유지하십시오(이 제안을 해 준 Michael Nygard에게 감사드립니다).
10. 품질 요구사항
고수준 개요를 제공하는 품질 트리와 함께 시나리오로 표현한 품질 요구사항. 가장 중요한 품질 목표는 섹션 1.2.(품질 목표)에 기술되어 있어야 합니다.
내용
이 섹션은 관련된 모든 품질 요구사항을 담습니다.
이러한 요구사항 중 가장 중요한 것은 이미 섹션 1.2.(품질 목표)에 기술되었으므로 여기서는 참조만 해야 합니다. 이 섹션 10에서는 완전히 달성되지 않아도 높은 위험을 만들지 않는 (하지만 있으면 좋은) 덜 중요한 품질 요구사항도 담아야 합니다.
동기
품질 요구사항은 아키텍처 결정에 많은 영향을 미치므로 이해관계자에게 어떤 품질이 정말로 중요한지 구체적이고 측정 가능한 방식으로 알아야 합니다.
추가 정보
https://quality.arc42.org 의 포괄적인 Q42 품질 모델을 참조하십시오.
10.1 품질 요구사항 개요
내용
품질 요구사항의 개요 또는 요약.
동기
흔히 수십 개(심지어 수백 개)의 상세한 품질 요구사항을 마주합니다. 이 개요 섹션에서는 예를 들어 범주나 주제를 기술하는 방식으로(ISO 25010:2023이나 Q42가 제안하는 대로) 요약하려고 해야 합니다
이러한 요약 설명이 이미 정확하고, 충분히 구체적이며 측정 가능하다면 섹션 10.2를 건너뛸 수 있습니다.
형식
각 줄에 범주나 주제와 품질 요구사항의 짧은 설명을 담은 간단한 표를 사용하십시오. 또는 마인드맵을 사용하여 이러한 품질 요구사항을 구조화할 수도 있습니다.
문헌에는 일반적인 용어 “품질”을 루트로 두고 “품질”이라는 용어를 트리 형태로 정제하는 품질 속성 트리라는 아이디어도 기술되어 있습니다. [Bass+21]은 이 목적을 위해 “Quality Attribute Utility Tree”라는 용어를 도입했습니다.
10.2 품질 시나리오
내용
품질 시나리오는 품질 요구사항을 구체적으로 만들고 그것이 (인수 기준의 의미에서) 충족되었는지 판단할 수 있게 해 줍니다. 시나리오가 구체적이고 측정 가능하도록 하십시오.
두 종류의 시나리오가 특히 유용합니다:
사용 시나리오(응용 시나리오 또는 사용 사례 시나리오라고도 함)는 특정 자극에 대한 시스템의 런타임 반응을 기술합니다. 여기에는 시스템의 효율이나 성능을 기술하는 시나리오도 포함됩니다. 예: 시스템은 사용자의 요청에 1초 이내에 반응한다.
변경 시나리오는 시스템이나 그 직접적인 환경의 수정 또는 확장의 원하는 효과를 기술합니다. 예: 추가 기능이 구현되거나 품질 속성에 대한 요구사항이 바뀌고, 변경의 노력이나 기간이 측정된다.
형식
상세한 시나리오의 전형적인 정보에는 다음이 포함됩니다:
짧은 형식(Q42 모델에서 선호):
맥락/배경: 어떤 종류의 시스템이나 컴포넌트이며, 환경이나 상황은 무엇인가?
출처/자극: 누가 또는 무엇이 행동, 반응 또는 동작을 시작하거나 촉발하는가.
메트릭/인수 기준: 척도나 메트릭을 포함한 응답
시나리오의 긴 형식(SEI와 [Bass+21]이 선호)은 더 상세하며 다음 정보를 포함합니다:
시나리오 ID: 시나리오의 고유 식별자.
시나리오 이름: 시나리오의 짧고 설명적인 이름.
출처: 시나리오를 시작하는 개체(사용자, 시스템 또는 이벤트).
자극: 시스템이 처리해야 하는 촉발 이벤트나 조건.
환경: 시스템이 자극을 경험하는 운영 맥락이나 조건.
산출물: 자극의 영향을 받는 시스템의 빌딩 블록 또는 기타 요소.
응답: 자극에 대한 반응으로 시스템이 보이는 결과나 동작.
응답 척도: 시스템의 응답을 평가하는 기준이나 메트릭.
함께 보기
2023년 1월부터 arc42는 실용적인 품질 모델을 제공하며, 이는 품질 요구사항에 #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable 같은 해시태그나 레이블을 붙일 것을 제안합니다.
11. 위험과 기술 부채
알려진 기술적 위험이나 기술 부채. 시스템 안이나 주변에 어떤 잠재적 문제가 있습니까? 개발 팀이 무엇 때문에 괴로워하고 있습니까?
내용
식별된 기술적 위험이나 기술 부채의 우선순위 순 목록
동기
“위험 관리는 어른을 위한 프로젝트 관리다”(Tim Lister, Atlantic Systems Guild.)
이것이 아키텍처의 위험과 기술 부채를 체계적으로 발견하고 평가하기 위한 좌우명이 되어야 하며, 이는 전반적인 위험 분석과 대책 계획의 일부로 관리 이해관계자(예: 프로젝트 관리자, 제품 책임자)에게 필요할 것입니다.
형식
위험 및/또는 기술 부채의 목록으로, 아마도 위험을 최소화, 완화 또는 회피하거나 기술 부채를 줄이기 위한 제안된 조치를 포함합니다.