아키텍처 참조 (엔터프라이즈 아키텍트 / 설계 권한)
규제가 적용되는 EU/프랑스 컨텍스트(은행, 의료, 국방)용. 규제 세부사항은 변경될 수 있음: "확인"으로 표시된 모든 사항은 결과물에 사용하기 전에 현재 공식 텍스트와 대조하여 확인해야 함.
참조 색인
references/togaf-archimate.md— 아키텍처 작업을 구성하거나(ADM 단계, 결과물, 거버넌스, 규정 준수 검토) ArchiMate로 모델링할 때(레이어, 요소, 관계, 뷰포인트) 읽기. 전체 경로${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— 프랑스 IS 맵(존/쿼티에/일로, 카토그래피), 스키마 디렉터, 애플리케이션 포트폴리오 평가(TIME) 또는 합리화/폐기 계획을 생성하거나 사용할 때 읽기. 전체 경로${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— 아키텍처 결정 기록 또는 결정 매트릭스(Nygard, MADR, Y-문, 가중치 기준, 가상 예시)를 작성하거나 검토할 때 읽기. 전체 경로${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
관련 결과물 템플릿: ${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md, interface-contract.md, flow-matrix.md.
규제 세부사항(GDPR, DORA, NIS2, HDS, II 901, IGI 1300…)은 sector-compliance 스킬과 해당 섹터 참조(${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/)에 있음; 이 스킬은 아키텍처 영향만 다룸.
1. 역할: 설계 권한
소유: 아키텍처 원칙 및 표준; 목표 아키텍처 및 로드맵; 구조적 결정(ADR); 도메인 및 전문가 간 일관성; 만료 기한이 있는 예외(데로가시옹); 아키텍처 규정 준수 검토; 아키텍처 수준의 기술 부채 등록. 소유하지 않음: 보안 위험 수용(비즈니스 위험 소유자/동등 기관, RSSI가 조언); 개인 데이터 결정(컨트롤러, DPO가 조언); 예산/일정 중재(COPIL); 프로덕션 변경(CAB).
검토 게이트
| 게이트 | 시기 | 확인 사항 |
|---|---|---|
| G0 범위 지정 | 노트 드 카드라주 | 목표/로드맵과의 적합성, 식별된 옵션, 규제 범위, 데이터의 주권 등급 |
| G1 설계 | DAT / 인터페이스 계약 초안 | 원칙 준수, NFR 수량화, 통합 패턴, 데이터 소유권, 보안 아키텍처, 복원성 |
| G2 사전 빌드 | 설계 확정 | ADR 수락, 예외 서명, 흐름 매트릭스 완료, 운영/재해 복구 설계 |
| G3 사전 라이브 | 실행/중단 결정 전 | as-built 대 DAT, 발생한 부채 등록, DR 테스트 완료, DORA 등록/종속성 맵 업데이트 |
검토 결과: 규정 준수 / 조건부 규정 준수(조치 + 날짜) / 예외(위험 소유자 + 만료일) / 규정 미준수(차단).
2. 아키텍처 원칙
형식(TOGAF 스타일): 이름 — 설명 — 근거 — 영향. 10-15개 유지, 각각 검토에서 테스트 가능해야 함. 규제된 통합 컨텍스트를 위한 기본 세트:
| # | 원칙 | 테스트 가능한 영향 |
|---|---|---|
| P1 | 설계상 비즈니스 연속성 | 모든 중요 기능은 설계상 명시된 RTO/RPO를 충족하고 테스트되어야 함 |
| P2 | 설계 및 기본 설정에 의한 보안 및 개인정보 보호(GDPR 제25조) | 설계 전 데이터 분류(DICT); 최소 권한; 전송 중 및 저장 중 암호화 |
| P3 | 데이터 도메인별 단일 진실 공급원 | 각 데이터 엔터티는 하나의 마스터 시스템과 명명된 소유자를 가짐; 다른 시스템은 관리되는 사본을 보유 |
| P4 | 관리형 인터페이스를 통한 느슨한 결합 | 다른 애플리케이션의 데이터베이스에 직접 액세스 불가; 모든 교환은 계약된 API, 메시지 또는 파일을 통해 이루어짐 |
| P5 | 구축 전 구매 전 재사용 | ADR에서 달리 명시하지 않는 한 기존 공유 플랫폼(MFT, API 게이트웨이, IAM, 스케줄링) 사용 |
| P6 | 표준 및 개방형 형식 | 개방형 프로토콜/형식 선호; 독점 형식은 복원성 계획 필요 |
| P7 | 복원성 및 종료 | 모든 외부 서비스에는 종료 계획이 있음; 데이터는 문서화된 형식으로 내보낼 수 있음 |
| P8 | 운영성은 요구사항임 | 모니터링, 로그, 스케줄링, 재시작 및 DEX가 솔루션과 함께 설계되어야 함 |
| P9 | 추적 가능성 및 감사 가능성 | 종단 간 상관관계 ID; 법적 요구사항에 따라 감사 추적 보존 |
| P10 | 분류에 따른 데이터 상주 및 주권 | 호스팅 선택은 데이터 클래스에서 파생됨(§6 참조) |
| P11 | 단순성 및 합리화 | 기존 구성 요소가 적합하지 않은 경우에만 새 구성 요소 도입; 모든 교체와 함께 폐기 계획 수립 |
| P12 | 제공 체인 자동화 | 코드로서의 인프라 및 배포, 재현 가능한 환경 |
3. 목표 아키텍처와 전환 아키텍처
- 기준선(as-is), 목표(to-be, 일반적으로 3-5년), 전환 아키텍처(플래토: 안정적이고 운영 가능하며 가치를 제공하는 중간 상태), 갭 분석(추가, 제거, 변경된 사항), 로드맵(작업 패키지, 종속성, 폐기 날짜).
- 각 전환은 자체적으로 운영 가능해야 함(지원, 모니터링, DR 적용, 문서화) — 프로젝트가 거기서 중단될 수 있음.
- 공존 브리지(임시 동기화, 이중 쓰기 방지, 반부패 계층)는 일급 구성 요소입니다: 소유자, 비용, 폐기 날짜, 부채 항목.
- "임시"에 폐기 날짜가 없으면 영구적이 됩니다: G1에서 거부하십시오.
- 레거시가 크고 문서화가 제대로 안 된 경우 빅뱅 교체보다 점진적 마이그레이션(스트랭글러 피그: 파사드 뒤의 새 시스템으로 점진적으로 기능 라우팅)을 선호하십시오.
4. 통합 아키텍처(매크로 수준)
상세 설계는 통합 전문가의 몫입니다. 아키텍트는 패턴과 규칙을 설정합니다.
| 패턴 | 적합한 경우 | 피해야 할 경우 | 주의사항 |
|---|---|---|---|
| 포인트 투 포인트 | 소수의 안정적인 흐름, 전술적 | 많은 소비자, 빈번한 변경 | 스파게티(n² 링크), 중앙 모니터링 없음 |
| 허브 앤 스포크 / EAI / ESB | 다양한 이기종 시스템, 변환, 중앙 거버넌스 | 허브가 병목/비즈니스 로직 모놀리스가 되는 경우 | 버스에서 비즈니스 로직을 제외하십시오 |
| MFT를 통한 파일 전송 | 배치, 대용량, 파트너 교환, 레거시(은행/IBM i에서 매우 일반적) | 실시간 요구사항 | 무결성 검사, 명명, 마감 시간, 재전송, 암호화, 부인 방지 |
| API 주도(시스템/프로세스/경험 레이어) | 재사용 가능한 서비스, 디지털 채널, 파트너 API | 대량 데이터 이동 | API 관리, 버전 관리, 할당량, OAuth2/mTLS |
| 이벤트 기반(pub/sub, 이벤트 스트리밍, CDC) | 분리된 반응, 실시간 전파, 많은 소비자 | 시스템 간 강력한 트랜잭션 일관성 필요 | 순서 지정, 멱등성, 스키마 진화, 재생, 이벤트 소유권 |
| 데이터 플랫폼(DWH, 레이크, 레이크하우스, 데이터 메시) | 분석, 규제 보고, ML | 운영 트랜잭션 통합 | 계보, 품질, 보존, 민감 데이터 분리 |
| MDM / 레페렌티엘 | 공유 마스터 데이터(고객, 제품, 조직, 환자 ID) | 단일 자연 소유자가 있는 데이터 | 거버넌스 및 관리 노력이 실제 비용임 |
경험 법칙: 호출자가 지금 실제로 답이 필요한 경우에만 동기 호출; 도메인 간에는 기본적으로 비동기; 모든 흐름을 장애에 대비하여 설계(지수 백오프 재시도, 데드 레터, 재생, 멱등성 있는 소비자); 이중 쓰기보다 아웃박스 패턴 사용; 범위가 제한된 범위 내에서만 표준 데이터 모델(엔터프라이즈 차원의 표준 데이터 모델은 거의 살아남지 못함); 모든 계약 버전 관리; 하나의 종단 간 상관관계 ID.
5. 비기능적 요구사항
모든 NFR을 수량화하십시오. "고가용성"은 요구사항이 아닙니다.
| 범주 | 메트릭/질문 | 함정 |
|---|---|---|
| 가용성 | 기간 대비 %, 서비스 시간, 허용된 계획 가동 중단 시간 | 종속성 체인 무시; 인프라가 아닌 서비스 측정 |
| 연속성 | 비즈니스 기능별 RTO/RPO(DMIA/PDMA), MTPD | 비동기 복제로 RPO 0 약속; 배치 재시작 무시 |
| 성능 | 처리량, p95/p99 지연 시간, 배치 창, 피크 계수, 성장 | 평균이 아닌 피크 테스트; 월말 피크 무시 |
| 확장성 | 목표 시점의 볼륨, 탄력성 | 비용을 비선형적으로 확장하는 라이선스 모델 |
| 보안 | DICT 등급, IAM, 암호화, 로깅, 분리 | 설계 후 보안 부착 |
| 운영성 | 모니터링, 경고, 로그, 재시작, 스케줄링, 자동화 | 라이브 후 DEX 작성 |
| 관찰 가능성 | 추적, 메트릭, 로그, 상관관계, 비즈니스 KPI | 미들웨어 간 종단 간 보기 없음 |
| 복원성 | 종료 계획, 내보내기 형식, 종료 시간 및 비용 | 계약상으로만 존재하고 테스트되지 않음 |
| 상호운용성 | 표준(예: 결제의 ISO 20022, 의료의 HL7 FHIR — 섹터 의무 사항 확인) | 표준의 로컬 방언 |
| 규정 준수/상주 | 데이터 위치, 보존, 법적 보류, 감사 | 백업 및 로그가 합의된 영역 외부에 저장됨 |
| 유지보수성 | 업그레이드 주기, 벤더 지원 날짜 | 프로젝트 중간에 지원 종료 |
| 지속 가능성 | 리소스 효율성(프랑스의 RGESN 에코디자인 가이드라인 — 상태 확인) | 과도하게 큰 비프로덕션 환경 |
가용성 치트 시트(연간): 99 % ≈ 3.65일; 99.5 % ≈ 1.83일; 99.9 % ≈ 8.76시간; 99.95 % ≈ 4.38시간; 99.99 % ≈ 52.6분; 99.999 % ≈ 5.3분. 직렬 체인: A = A1 × A2 × … ; 중복 쌍: A = 1 − (1 − A1)(1 − A2)(독립적 장애 가정 — 거의 완전히 사실이 아님). RPO/RTO 일관성: RPO는 복제 모드 및 백업 빈도에 의해 제한됨; RTO에는 탐지, 결정, 장애 조치, 데이터 복구, 배치 따라잡기 및 파트너 재동기화가 포함됨 — 기술적 전환 시간만이 아님.
6. 클라우드 전략 및 주권
먼저 분류하고, 그다음 호스팅: 데이터 클래스가 호스팅 옵션을 결정합니다.
| 데이터/시스템 클래스 | 일반적인 호스팅 옵션(현행 규칙에 대해 확인) |
|---|---|
| 공개/내부, 비민감 | 표준 통제를 통해 퍼블릭 클라우드 허용 가능 |
| 개인 데이터(GDPR) | EU 호스팅 선호; EEA 외부 전송은 5장 근거 및 전송 영향 평가 필요 |
| 건강 개인 데이터(프랑스) | HDS 인증 호스팅 제공업체 필요(Code de la santé publique, Art. L.1111-8); 최근 HDS 참조는 EEA 내 데이터 위치 요구사항 추가 — 현재 버전 및 전환 날짜 확인 |
| 국가 서비스, 국가 운영자 및 지정 GIP의 특별 민감 데이터(données d'une sensibilité particulière) | SecNumCloud 인증 제안, 또는 ANSSI가 동등하다고 인정하는 EU/EEA 인증: SREN 법 제31조(2024), 2026년 4월 14일 데크레 n° 2026-272, 2026년 8월 12일 아레테; "cloud au centre" 독트린(2021, 2023 업데이트)은 기대를 다른 국가 IS로 확장 — 해당 텍스트의 면제 제도 |
| Diffusion Restreinte (DR) | II 901에 따라 인증된 시스템; 특정 호스팅 제약 — 확인 |
| 기밀(Secret / Très Secret, IGI 1300) | 전용 인증 인프라; 퍼블릭 클라우드는 일반적으로 제외됨 |
| 은행 중요 또는 중요 기능 | DORA 타사 요구사항, 아웃소싱 규칙(EBA 가이드라인) 및 필요한 경우 감독자 통지에 따라 허용 — 확인 |
SecNumCloud: 요구사항 참조 v3.2(2022년 3월 8일; 2026년 8월 12일 아레테에 의해 승인된 버전)에 대한 클라우드 서비스 제공업체의 ANSSI 인증. 기술 보안 요구사항 외에도 §19.6은 비EU 역외법으로부터 보호: EU에 설립된 제공업체, 비EU 주주는 개별적으로 24%, 집합적으로 39%로 제한, 데이터는 EU에 저장되고 서비스는 EU에서 관리 및 감독됨. "주권" 마케팅 라벨은 인증이 아닙니다: 인증서와 정확한 서비스 범위를 요청하십시오. 역외 노출: 데이터 클래스에 대한 비EU 법적 액세스 위험(예: 미국 CLOUD Act, FISA s.702) 평가; 고객 보유 키(HSM/BYOK/HYOK)를 사용한 암호화는 위험을 줄이지만 항상 제거하지는 않음. 복원성 조항(계약 + 아키텍처): 종료 계획 및 지원 기간; 금지적인 비용 없이 문서화된 개방형 형식으로 데이터 및 메타데이터 내보내기; 삭제 인증서; 문서 및 구성 내보내기; 종료 중 서비스 연속성; 통지 기간; 하위 프로세서 목록; 감사 권리. EU 데이터 법(Regulation (EU) 2023/2854, 제6장)은 2025년 9월 12일부터 적용: 제공업체는 전환을 지원해야 하며 2027년 1월 12일까지 실제 전환/송신 비용만 청구할 수 있고, 그 이후에는 청구할 수 없음. 아키텍처 지원 요소: 이식 가능한 워크로드(컨테이너, IaC), 표준 데이터베이스 또는 문서화된 마이그레이션 경로, 핵심 기능에 대한 독점 PaaS와의 긴밀한 결합 방지(ADR이 수락하지 않는 한), 정기적인 종료 테스트(최소한 다른 곳으로 내보내기 + 복원). 클라우드 마이그레이션 옵션(6R/7R): 폐기, 유지, 재호스팅, 재배치, 재플랫폼, 리팩터링, 재구매 — 포트폴리오 평가에서 애플리케이션별로 결정(도시화 참조 참조).
7. 기술 부채 관리
- 유형: 아키텍처(잘못된 패턴, 결합), 노후화(지원 종료 버전), 코드, 데이터(품질, 중복), 운영(수동 단계), 문서, 보안(지연된 수정).
- 등록: 항목, 유형, 위치, 원인(ADR을 통한 의도적 / 우발적), 이자(기간당 비용 또는 위험), 원금(수정 비용), 소유자, 마감일, ADR/면제에 대한 링크.
- 노후화 달력: OS, DB, 미들웨어, 런타임, ERP 버전, IBM i 릴리스에 대한 벤더 지원 종료 날짜; 24개월 이내에 종료되는 모든 항목에 플래그 지정.
- 자금 조달: 명시적 용량 예약(일반적으로 인용되는 제공 용량의 15-20% — 조직별); 프로젝트의 면제로 인한 부채는 해당 프로젝트에서 비용이 책정됨.
- 중요 기능에 영향을 미치는 부채는 ICT 위험입니다: IT 백로그뿐만 아니라 위험 프레임워크에도 보고하십시오.
8. DORA ICT 위험: 아키텍처 관점
Regulation (EU) 2022/2554, 2025년 1월 17일부터 적용, RTS/ITS로 보완됨. 아래 조항 번호는 참고용입니다: 결과물에서 인용하기 전에 EUR-Lex에서 확인하십시오.
| DORA 주제 | 아키텍처 기여 |
|---|---|
| ICT 위험 관리 프레임워크(제6조) | 문서화된 통제로서의 아키텍처 원칙, 표준 및 목표 아키텍처 |
| 식별(제8조) | ICT 자산 및 정보 자산 인벤토리; 비즈니스 함수, 프로세스 및 타사에 대한 종속성 매핑 |
| 보호 및 예방(제9조) | 보안 아키텍처, 암호화, ID 관리(IDM/IGA), 개발 보안(S-SDLC) |
| 탐지(제10조) | 로깅, 모니터링, 이상 탐지, SIEM/SOAR 아키텍처 |
| 대응 및 복구(제11조) | DRP 및 BCP 아키텍처, RTO/RPO, 장애 조치, 격리 기능, 커뮤니케이션 계획 |
| 학습 및 진화(제13조) | 사후 분석에서 아키텍처 피드백 루프, 원칙/표준 업데이트 |
| 타사 위험(제28-44조) | 아웃소싱 아키텍처, 복원성 체인에 있는 타사 매핑, 종료 계획, 계약 조항 |
| ICT 위험 관리 보고(제18조) | 아키텍처 지표(KRI): 중요한 종속성 수, 딘 감소, 기술 부채에 대한 위험 노출 |
종속성 맵(DORA 제8조): 모든 중요 또는 중요한 함수에 대해, 이 함수를 지원하는 ICT 자산(애플리케이션, 데이터베이스, 미들웨어, 인프라), 내부/외부 종속성, 통신 흐름을 문서화하십시오. 이 맵은 ICT 위험 관리의 기초입니다. 아키텍처 수준에서 유지 관리하십시오. 침투 테스트: 아키텍처는 침투 테스트 범위(공격 표면, 중요한 경로, 격리 경계)를 정의합니다. DORA는 중요 ICT 자산에 대한 위협 기반 침투 테스트(TLPT)를 요구합니다. ICT 위험 등록(아키텍처 관점): 아키텍처와 관련된 항목(예: 중요한 종속성의 단일 장애 지점, 복원성 목표에 미치지 못하는 노후화된 구성 요소, 문서화되지 않은 수동 프로세스, 라이브 종료 계획 없음)을 ICT 위험 체계에 보고하십시오.
9. 복원성 및 지속 가능성 체크리스트 — 추가
이는 교차 전문가 일관성 검토 중 하나입니다(§10 참조).
복원성 작업 목록
- 각 외부 서비스에 대해 문서화된 종료 계획이 있습니까? 계약서에 있습니까? 연습/테스트를 거쳤습니까?
- 데이터 내보내기는 문서화된 개방형 형식으로 금지적인 비용 없이 가능합니까? 데이터 양에 대해 측정되었습니까?
- 배포 스크립트(IaC)를 다시 실행하여 다른 제공업체에서 유사한 인프라를 처음부터 프로비저닝할 수 있습니까?(시간 측정)
- PaaS 기능은 이전에 대한 장벽입니까?(ADR이 달리 명시하지 않는 한 기본값은 아니오)
- 라이선스 모델은 볼륨에 따라 선형적으로 비용이 증가합니까? 계약에 전환/해지 조건이 있습니까?
- 중요 기능에 대해 최소 한 번 DR 테스트가 수행되었습니까?
- 복원성은 비용 및 예산 계획에 포함됩니까?
지속 가능성 작업 목록
- RGESN/RESG 에코디자인 가이드라인이 검토되었습니까? 현재 상태는 무엇입니까? 일반적인 부문에서 더 구체적인 지침이 있습니까?
- 데이터 저장은 필요한 것에 비례합니까? 보존 정책이 설정되었습니까? 아카이빙/삭제 프로세스가 있습니까?
- 비프로덕션 환경(테스트, 스테이징, DR)이 과도하게 프로비저닝되지 않았습니까? 사용하지 않을 때 축소할 수 있습니까?
- 데이터 전송이 최적화되었습니까?(압축, 차등 동기화, 네트워크 홉 감소)
- 아키텍처가 자원 효율적인 기술을 선호합니까?(예: 해석형보다 컴파일형, 데몬보다 서버리스)
10. 교차 전문가 일관성 검토 체크리스트(아키텍처 관점)
이 체크리스트는 설계 권한이 모든 전문 분야(보안, 데이터, 통합, 인프라, 규정 준수)의 결과물이 서로 일관성이 있고 아키텍처 원칙 및 목표 아키텍처와 충돌하지 않도록 하는 데 도움이 됩니다. 하나의 검토 단계로 사용하십시오.
일반
- 모든 전문가(보안, 데이터, 통합, 네트워크, 인프라, 규정 준수, 비용 관리)가 목표 아키텍처 및 로드맵의 동일한 버전을 참조합니까?
- 각 도메인의 ADR이 호환됩니까?(충돌하는 결정이 없습니까?)
- 섹터 규제(NIS2, DORA, GDPR, HDS, II 901…)가 모든 관련 문서에서 동일하게 해석됩니까? (sector-compliance 참조 확인)
- 각 도메인은 동일한 우선순위, 가정 및 제약 조건(예산, 일정, 사용 가능한 기술)에서 작동합니까?
아키텍처
- 목표 아키텍처는 모든 도메인의 계획을 통합하고 일관된 엔드투엔드 경로를 제공합니까?
- 전환 아키텍처에 갭(누락된 구성 요소, 해결되지 않은 종속성)이 있습니까?
- 전문 분야 간에 갭/충돌이 있습니까?(예: 보안은 네트워크 분할을 요구하지만 통합은 데이터 스트림이 경계를 가로지르도록 요구함)
- 각 전문 분야는 아키텍처 원칙에 대한 영향 또는 예외를 문서화했습니까? (ADR, 면제)
데이터
- 각 중요 데이터 엔터티에 대해 소유자와 마스터 시스템이 명명되었습니까?
- 데이터 분류(DICT 등급, GDPR, 건강, DR…)가 모든 구성 요소에서 일관됩니까? (정의, 전파, 애플리케이션 간 불일치 없음)
- 데이터 흐름이 문서화되었습니까? (흐름 매트릭스: 각 흐름의 소스, 소비자, 빈도, 프로토콜, 볼륨, 기술)
- 데이터 보존 정책이 모든 곳에서 동일합니까? (규정 준수 요구사항과 충돌이 있습니까?)
통합
- 모든 작업에서 통합 패턴이 일관됩니까? (일부는 API를 사용하고 다른 일부는 파일 교환을 사용하지만, 동일한 흐름에 대해 둘 다 사용하는 경우는 없습니까?)
- 흐름은 가용성의 직렬 체인 또는 공유 타사에 대한 공동 종속성을 생성합니까?(계산된 집계 가용성은 수용 가능합니까?)
- 비동기 흐름의 경우: 소비자 오류(데드 레터, 재시도)가 관리됩니까? 이벤트 순서가 보장됩니까?
- 동기 흐름의 경우: 시간 초과, 서킷 브레이커, 폴백이 정의되었습니까?
- CDC / 데이터 복제 흐름의 경우: idempotency가 관련 소비자에 의해 처리됩니까? 스키마 진화가 계획되었습니까?
보안
- IAM 아키텍처(인증 프로토콜, 권한 부여 모델, ID 페더레이션, IDM/IGA)가 모든 구성 요소에 적용됩니까? (사용자 지정 또는 불일치 없음)
- 네트워크 분할 모델(존, VPC, 방화벽 규칙, 서비스 메시 정책)이 모든 작업에서 동일합니까? 작업 간 갭(놓친 흐름, 차단된 필수 흐름)이 있습니까?
- 암호화 정책(전송 중, 저장 중, 키 관리, BYOK/HYOK)이 모든 구성 요소에 적용됩니까?
- 보안 모니터링(SIEM, SOC, 로그 수집)이 모든 구성 요소를 포괄합니까? 로그 형식과 전송이 표준화되었습니까?
- 취약성 관리 프로세스(CVE 스캐닝, 패치 주기)가 모든 구성 요소에 적용됩니까?
인프라 / 운영
- 모든 구성 요소가 용량 계획(CPU, RAM, 스토리지, 네트워크)을 공유된 가정 및 예측을 기반으로 하여 일관되게 정의했습니까?
- 인프라 자동화(IaC, 구성 관리)가 모든 환경(개발/스테이징/프로덕션/DR)에서 설정되었습니까?
- DR 계획이 모든 구성 요소를 포괄합니까? (장애 조치 순서, 데이터 동기화, 복구 테스트)
- 모니터링 및 경고가 모든 구성 요소를 포괄합니까? (중앙 집중식 대시보드, 종단 간 가시성)
- 스케줄링 및 배치 창이 조정되었습니까? (월말 배치 경합, 리소스 경합)
비용 / 조달
- 각 구성 요소의 라이선스, 인프라 및 운영 비용이 추정되고 예산에 포함됩니까?
- 타사 서비스 계약에 필요한 SLA(가용성, 성능, 지원)가 포함됩니까? SLA가 아키텍처 가정(종속성 체인 계산)과 일치합니까?
- 타사 또는 오픈 소스 구성 요소에 대한 라이선스가 사용 모드 볼륨에 대해 확인되었습니까?
이 목록은 완전하지 않습니다. 프로젝트별 문제(예: 여러 데이터 센터의 지리적 위치, 다양한 법적 관할권, 마이그레이션 일정이 있는 여러 공급업체 간 상호 작용, 공동 외부 플랫폼에 대한 공유 타사 종속성)에 의해 확장되어야 합니다.
검토가 체크리스트 어딘가에서 불일치를 발견하면(예: 두 전문 분야가 동일한 흐름에 대해 서로 다른 통합 패턴을 가정함, 데이터 소유자와 마스터 시스템이 명명되지 않음, DR 계획이 모든 PR을 포괄하지 않음), 전문 분야는 디자인 권한이 중재하는 동기화 워크샵에서 이를 해결해야 합니다. 합의에 도달하면 ADR 또는 문서 업데이트로 문서화하십시오.
일반적인 불일치 사례: 보안은 모든 네트워크 경계에서 암호 해독/재암호화를 원하지만, 이는 데이터가 프록시/게이트웨이에 의해 해독될 때 중요한 데이터에 대한 종단 간 데이터 기밀성 또는 온-프레미스 -> 파일럿 -> 관리형 데이터 레이크 경로를 통한 CDC 복제의 경우 성능에 영향을 미칠 수 있음; 성능 테스트는 최대 부하에서 100밀리초 미만의 지연 시간을 요구하지만, 지리적 분산 아키텍처의 물리적 제한으로 인해 200밀리초를 초과함. US CLOUD Act 적용 하이퍼스케일러에 중요 기능을 배치하는 은행 아키텍처는 적절한 경우 SecNumCloud 및 역외 위험 완화를 요구할 수 있음.