3.1 아키텍처의 기본

개요와 동기

소프트웨어 아키텍처는 바꾸는 데 비용이 많이 드는 중요한 설계 결정의 집합입니다. 주요 구성 요소의 구조, 그 사이의 관계, 시스템 전체가 보여야 하는 속성입니다. 많은 사람이 하나의 일관된 제품을 만들 수 있게 해 주는 공유된 멘탈 모델이라고 생각하십시오. 작은 팀에서 아키텍처는 몇 사람의 머릿속에 살면서 해 나가는 동안 진화할 수 있습니다. 대규모 조직(수백 명의 엔지니어, 수십 개의 팀, 여러 제품, 여러 해의 로드맵)에서는 아키텍처가 모두를 조율하는 것이 됩니다. 분명하면 팀들이 부딪히지 않고 독립적으로 움직입니다. 모호하면 모든 팀 간 의존성이 협상이 되고 모든 인시던트가 고고학 프로젝트가 됩니다.

기업과 정부에서는 시스템이 오래 살고, 규제가 심하며, 부서 간에 공유되므로 기본기가 훨씬 더 중요합니다. 세금 시스템, 급여 플랫폼, 국가 건강 기록, 은행의 핵심 원장은 만든 사람들의 경력보다 오래 살 것입니다. 결합도, 데이터 소유권, 품질 속성에 대해 오늘 내리는 결정은 10년 이상 무엇이 가능한지를 제약합니다. 규제 기관과 감사자는 점점 더 문서화되고 방어 가능한 아키텍처를 기대합니다. 신뢰성, 보안, 프라이버시, 접근성이 나중에 덧붙인 것이 아니라 설계에 들어 있었다는 증거입니다. 기본기를 제대로 하는 것은 학문적인 일이 아닙니다. 새로운 의무에 적응하는 플랫폼과 처음부터 다시 지어야 하는 플랫폼의 차이입니다.

이 장은 기술 유행을 넘어 살아남는 오래가는 기본기를 다룹니다. 품질 속성(“-ilities”), 아키텍처상 중요한 요구 사항, 피트니스 함수와 진화적 아키텍처, C4와 arc42를 이용한 가벼운 문서화, 구조화된 트레이드오프 분석입니다. 대규모 팀이 우연이 아니라 의도적으로 아키텍처를 추론하게 해 주는 도구들입니다.

핵심 원칙

아키텍처는 정답이 아니라 트레이드오프에 관한 것입니다. 모든 중요한 결정은 한 품질을 다른 품질과 맞바꿉니다. 일은 그 거래를 의도적이고 투명하게 하는 것입니다.
품질 속성은 요구 사항입니다. 성능, 가용성, 보안, 유지보수성은 기능과 같은 엄밀함으로 명세되어야 하며, 아니면 마감 압박 아래 희생됩니다.
모든 요구 사항이 아키텍처상 중요한 것은 아닙니다. 희소한 설계 주의를 구조를 형성하거나, 바꾸기 어렵거나, 위험이 큰 요구 사항에 집중하십시오.
아키텍처는 진화할 수 있어야 합니다. 지식이 시작에서 가장 적으므로 대규모 선행 설계는 실패합니다. 점진적으로 설계하고 핵심 속성은 자동화된 검사로 보호하십시오.
다이어그램만이 아니라 결정을 문서화하십시오. 선택의 이유(그리고 기각된 선택지)가 결과의 그림보다 가치 있습니다.
만들지 않은 사람에게도 아키텍처가 읽히게 하십시오. 신규 입사자, 감사자, 미래의 유지보수자가 의도를 재구성할 수 있어야 합니다.
미룰 수 있는 결정은 미루고, 해야 하는 결정은 하십시오. 변경이 싼 곳에서는 선택지를 열어 두고, 늦은 확정이 비싼 곳에서만 일찍 확정하십시오.

권장 사항

품질 속성을 측정 가능한 시나리오로 명세한다

“시스템은 빨라야 한다”나 “고가용이어야 한다” 같은 모호한 목표는 테스트하거나 시행할 수 없습니다. 대신 각 품질 속성을 자극, 맥락, 측정 가능한 응답이 있는 구체적 시나리오로 쓰십시오. “동시 사용자 최대치가 5만 명에 이르면 검색 요청의 95%가 300ms 안에 완료된다.” 도메인에 중요한 속성들을 덮으십시오. 가용성, 성능, 확장성, 보안, 유지보수성, 관측 가능성, 접근성, 이식성, 비용 효율성입니다. 모두를 한꺼번에 최대화할 수 없으므로 소리 내어 순위를 매기십시오. 일관성을 최대로 맞춘 시스템은 가용성도 최대일 수 없습니다.

아키텍처상 중요한 요구 사항(ASR)을 식별한다

ASR을 일반 요구 사항에서 분리할 시간을 따로 두십시오. 요구 사항이 많은 구성 요소에 닿거나, 충족하는 데 비싸거나, 엄격한 제약을 부과하거나, 기술적으로 위험하면 아키텍처상 중요합니다. 규제 의무(데이터 거주, 보존, 감사 가능성), 고부하 시나리오, 기록 시스템인 레거시와의 통합, 엄격한 보안 경계가 대개 ASR입니다. 짧고 살아 있는 목록을 유지하고, 주요 설계 결정을 그 목록까지 추적해 리뷰어가 아키텍처가 왜 그런 모양인지 볼 수 있게 하십시오.

진화적 아키텍처와 피트니스 함수를 채택한다

아키텍처를 고정된 청사진이 아니라 안내된 방향으로 단계적으로 변하는 것으로 다루십시오. 피트니스 함수는 특정 아키텍처 특성이 유지되고 있는지 확인하는 자동화되고 객관적인 테스트입니다. 어떤 모듈도 금지된 계층에서 임포트하지 않음을 확인하는 빌드 시점 검사, p99 지연이 회귀하면 파이프라인을 실패시키는 성능 테스트, 알려진 취약한 의존성을 막는 보안 스캔, 어떤 서비스도 다른 서비스의 데이터베이스에 직접 연결을 갖지 않음을 확인하는 테스트입니다. 피트니스 함수는 아키텍처 의도를 지속적으로 시행되는 가드레일로 바꿉니다. 크고 변하는 팀 전반에 걸쳐 그 의도를 살려 두는 유일한 방법입니다.

C4와 arc42로 문서화한다

C4 모델로 구조를 네 가지 확대 수준(시스템 컨텍스트, 컨테이너, 컴포넌트, 코드)으로 설명해, 각 청중이 자기에게 맞는 수준을 읽고 어떤 단일 다이어그램도 모든 것을 말할 필요가 없게 하십시오. 둘러싼 서술의 템플릿으로 arc42를 쓰십시오. 목표, 제약, 컨텍스트, 해결 전략, 구성 블록, 런타임 시나리오, 배포, 횡단 관심사, 결정, 위험입니다. 개별 결정은 짧은 아키텍처 결정 기록(ADR)으로 남기십시오. 컨텍스트, 결정, 상태, 결과를 결정마다 한 파일로 코드와 함께 버전 관리합니다. 문서화 습관을 하나만 채택한다면 ADR로 하십시오. 큰 팀에서는 다른 무엇보다 값을 합니다.

구조화된 트레이드오프 분석을 실행하고 위험으로 설계를 이끈다

고위험 시스템에는 아키텍처 트레이드오프 분석 방법(ATAM) 같은 방법으로 후보 아키텍처를 우선순위가 매겨진 품질 속성 시나리오에 비추어 평가하십시오. 민감점(결정이 한 속성에 강하게 영향)과 트레이드오프점(여러 속성에 영향)이 드러납니다. 더 가볍게 하려면 위험 주도 설계를 채택하십시오. 위험에 비례해 설계 노력을 쓰는 것입니다. 위험이 낮고 잘 이해된 부분은 의례가 거의 필요 없습니다. 새롭고, 영향이 크거나, 되돌릴 수 없는 결정은 프로토타입, 스파이크, 공식 리뷰를 받을 가치가 있습니다.

장단점

접근 방식	장점	단점
무거운 선행 아키텍처	조율의 명확성. 범위가 고정된 프로그램에서 늦은 놀람이 적음	지식이 가장 적을 때 내린 결정. 느림. 변경에 취약
창발적 / 진화적 아키텍처	학습에 적응. 낭비가 적음. 빠른 전달을 지원	피트니스 함수 없이는 표류 위험. 강한 엔지니어링 규율 필요
공식 ATAM식 평가	엄밀하고 감사 가능. 숨은 충돌을 드러냄	시간과 전문성이 많이 듦. 작은 변경에는 과함
가벼운 ADR + C4	싸고, 읽기 쉽고, 점진적이며, 많은 팀으로 확장됨	최신으로 유지하는 규율만큼만 좋음

핵심 긴장은 확실성과 적응성 사이에 있습니다. 고정 가격 정부 프로그램과 안전이 핵심인 시스템은 늦은 변경이나 실패의 비용이 막대하므로 더 많은 선행 엄밀함과 공식 평가 쪽으로 기웁니다. 빠르게 움직이는 제품 조직은 자동화로 보호되는 진화적 접근 쪽으로 기웁니다. 대부분의 대규모 조직은 둘 다 필요합니다. 되돌릴 수 없고 영향이 큰 결정과 횡단 관심사에는 더 무거운 거버넌스를, 나머지 모든 곳에는 더 가볍고 창발적인 설계를. 두 극단은 각자의 방식으로 실패합니다. 과도한 아키텍처링은 여러 해를 낭비하고 아무것도 내놓지 못하며, 과소한 아키텍처링은 확장하거나 감사할 수 없는 엉킴을 낳습니다.

팀과 논의할 질문

품질 속성 둘이 부하 아래서 충돌하면 어느 쪽이 이기며, 그 우선순위를 적어 두었습니까? 모든 아키텍처는 거래를 강제합니다. 최대 일관성은 가용성을 깎고, 엄격한 보안은 지연을 더하고, 공격적 캐싱은 감사 가능성과 싸웁니다. 큰 팀에서 위험은 서로 다른 스쿼드가 조용히 다른 우선순위를 가정해 하나는 처리량에 최적화하고 다른 하나는 엄격한 일관성을 지키며, 충돌이 인시던트 중에야 드러나는 것입니다. 기업과 정부 환경에서 규제 기관은 어떤 속성을 왜 보호했는지 물을 것이므로, 순위는 민간 전승이 아니라 명시적이고 방어 가능해야 합니다. 품질 속성 시나리오를 가져와 순서가 모호하지 않을 때까지 쌍마다 소리 내어 순위를 매기십시오. 그다음 승자를 피트니스 함수로 인코딩해 우선순위가 마감 압박 아래서 침식되지 않고 유지되게 하십시오.
최근 결정 중 어느 것이 한 방향 문이었으며, 양방향 문보다 더 많은 검토를 받았습니까? 위험 주도 설계는 결정을 되돌리기 어려운 정도에 비례해 설계 노력을 쓰라고 말하지만, 대부분의 팀은 모든 변경을 대체로 같은 의례로 리뷰합니다. 그러면 싸고 되돌릴 수 있는 선택에 주의가 낭비되는 반면, 되돌릴 수 없는 것(법적 기록에 굳어진 데이터 모델, 공개 API 계약, 핵심 데이터 저장소)은 너무 적은 이의 제기로 빠져나갑니다. 지난 분기의 중요한 결정을 뽑아 되돌릴 수 있는 정도로 정렬하고, 되돌릴 수 없는 것들이 프로토타입, 스파이크, 공식 리뷰를 받았는지 물으십시오. 오래 사는 기업과 정부 시스템에서 잘못된 한 방향 문의 비용은 10년간 누적되므로 추가 엄밀함은 여러 배로 돌아옵니다. 프로세스의 무게를 diff의 크기가 아니라 결정의 되돌릴 수 있는 정도에 맞추십시오.
다음의 위험이 크고 되돌리기 어려운 결정에는 누가 그 자리에 있어야 하며, 어떤 시나리오로 선택지를 채점하겠습니까? ATAM 방식의 구조화된 트레이드오프 리뷰는 결정이 되돌릴 수 없고 여러 품질 속성에 동시에 닿을 때 비용을 회수하며, 그 힘은 참석한 사람들에게서 옵니다. 전달, 보안, 운영, 그리고 결과를 느끼는 정책이나 비즈니스 소유자입니다. 그중 한 목소리라도 빼면 캐싱 선택이 감사 가능성 요구 사항을 조용히 깨뜨리는 식으로 충돌을 빌드 후에 발견합니다. 우선순위가 매겨진 품질 속성 시나리오를 채점 기준으로 가져오고, 한 선택지가 단일 속성을 크게 흔드는 민감점과 여러 속성을 움직이는 트레이드오프점을 찾으십시오. 원하는 산출물은 기각한 선택지와 그 이유를 기록한 짧은 ADR이어서, 결정을 내린 사람들이 떠난 뒤에도 추론이 살아남게 하는 것입니다. 곧 있을 결정 중 이를 정당화할 것이 없어 보인다면 그 자체가 확인할 가치가 있습니다. 지평선에 되돌릴 수 없는 결정이 없는 대규모 프로그램은 대개 충분히 멀리 보고 있지 않기 때문입니다.
신규 입사자나 외부 감사자에게 서면 아키텍처만 있다면, 시스템이 왜 그런 모양인지 재구성할 수 있으며, 마지막으로 그것을 시험한 것은 언제입니까? 몇몇 시니어의 머릿속에 사는 아키텍처는 단일 장애점입니다. 그 사람들이 떠나면 되돌리기 어려운 모든 결정의 이유도 함께 떠나고, 다음 팀은 인시던트를 통해 다시 배웁니다. 대규모 조직에서 아키텍처의 가독성(현실과 맞는 C4 다이어그램, arc42 서술, 기각된 선택지를 기록한 ADR)은 수십 개 팀이 회의 없이 같은 시스템을 추론하게 해 주는 것입니다. 최근 ADR과 현재 다이어그램을 가져와 구성 요소를 만들지 않은 사람에게 건네고, 사람에게 물어야 하기까지 얼마나 가는지 지켜보십시오. 기업과 정부 환경에서 감사자는 정확히 이 연습을 할 것이며, 작년 시스템을 설명하는 문서는 없는 것보다 나쁩니다. 인증해야 하는 바로 그 사람들을 오도하기 때문입니다. 서면 기록의 신선도를 측정 가능한 속성으로 다루고, 그것을 참으로 유지하는 데 피트니스 함수나 리뷰 주기를 뒷받침하십시오.
아키텍처 특성 중 어느 것이 오늘 자동화된 피트니스 함수로 보호되며, 어느 것이 여전히 모두가 규칙을 기억하는 데 의존합니까? 위키 페이지나 리뷰어의 기억에만 사는 의도는 마감이 오는 순간 침식됩니다. 계층화 규칙, 데이터베이스 공유 금지 경계, 지연 예산이 바로 팀이 압박 아래서 자르는 것이기 때문입니다. 크고 빠르게 변하는 코드베이스에서 살아남는 유일한 의도는 빌드가 시행하는 의도이므로, 주장하는 특성과 실제로 검사하는 특성 사이의 간극이 진짜 아키텍처 위험입니다. 중요한 특성을 나열하고 각각을 시행됨, 수동 리뷰됨, 보호되지 않음으로 표시하고, 피트니스 함수가 더 일찍 잡았을 표류를 리뷰가 잡은 최근 세 번을 가져오십시오. 규제되고 공공의 시스템에서는 이것이 두 배로 중요합니다. 규제 기관은 데이터 거주나 감사 가능성을 의도했는지가 아니라 그것이 지속적으로 유지되었음을 어떻게 증명하는지 물을 것이고, 초록색 파이프라인은 정책 문서보다 훨씬 강한 답이기 때문입니다. 실패가 일어나기 쉽고 비싼 특성을 먼저 자동화하고, 일부는 수동으로 남을 것임을 받아들이십시오.
요구 사항이 아키텍처상 중요한지 결정할 때 누가 그 판단을 내리며, ASR 목록이 전부가 되거나 아무것도 아니게 되지 않게 어떻게 합니까? 아키텍처상 중요한 요구 사항에 이름을 붙이는 가치는 선택성에서 옵니다. 모든 요구 사항을 중요하게 다루면 설계가 멈추고, 아무것도 중요하게 다루지 않으면 구조적이고, 위험하고, 바꾸기 어려운 것들이 보호되지 않은 채 빠져나갑니다. 큰 팀에서 유혹은 각 스쿼드가 지역적으로 결정하게 두는 것인데, 이는 한 그룹의 “사소한” 선택이 다른 그룹의 구조를 제약할 때 일관성 없는 기준과 팀 간 놀람을 낳습니다. 현재 ASR 목록, 사용한 기준(많은 구성 요소에 닿음, 충족에 비쌈, 엄격한 제약, 기술적으로 위험), 경계를 소리 내어 시험할 몇 가지 경계선상의 요구 사항을 가져오십시오. 기업과 정부에서 데이터 거주, 보존, 감사 가능성 같은 규제 의무는 거의 항상 중요하며 협상할 수 없으므로, 누가 목록을 소유하는지, 어떻게 리뷰되는지, ASR을 추가하거나 빼는 결정이 어떻게 기록되는지 밝히십시오. 아무도 다스리지 않는 ASR은 정밀 조사 아래서 아무도 변호하지 않을 요구 사항이기 때문입니다.

분야별 관점

스타트업. 의례는 거의 0에, 기록은 거의 완전하게 유지하십시오. 공식 ATAM 워크숍과 무거운 템플릿은 건너뛰되, 풀기 고통스러울 선택(데이터 저장소, 모놀리스 대 서비스, 인증 제공자)에 대해 짧은 ADR 열두 개 정도는 쓰고 초기 고객이 실제로 느끼는 두세 개의 품질 속성 시나리오를 고정하십시오. 희소한 자원은 엔지니어링 주의이므로, 테넌트 격리처럼 실패하면 여러분을 침몰시킬 특성만 보호하고 나머지는 창발적이고 바꾸기 싸게 두십시오.

소기업. 전담 아키텍트도 빠듯한 예산도 없으니, 비용이 거의 들지 않는 기본기에 기대십시오. 소수의 품질 속성을 구체적 숫자로 이름 붙이고, 되돌리기 어려울 모든 것에 ADR을 쓰고, 무거운 구조적 결정은 선택한 플랫폼이나 벤더가 짊어지게 두십시오. 맞춤 인프라를 만들기보다 잘 지원되는 스택을 사는 쪽을 선호하고, 벤더의 문서화된 아키텍처를 처음부터 저술해야 하는 것이 아니라 물려받는 제약으로 다루십시오.

대기업. 과제는 많은 팀과 여러 해의 로드맵에 걸친 일관성이므로 공유 장치에 투자하십시오. 아키텍처 길드, 공통 품질 속성 시나리오 집합, 코드 옆에 저장된 ADR, 어떤 단일 리뷰어도 규모에서 단속할 수 없는 경계를 시행하는 CI의 피트니스 함수입니다. 되돌릴 수 없는 횡단 결정에는 구조화된 트레이드오프 분석을 쓰고, C4 다이어그램을 설계 리뷰의 공유 지도로 유지하고, 그룹들이 지역적으로는 합리적이지만 전역적으로는 충돌하는 선택을 멈추도록 ASR 목록을 중앙에서 다스리십시오.

정부. 오래 살고 규제되는 시스템은 문서화되고 방어 가능한 아키텍처를 호의가 아닌 조달과 책임성의 요구 사항으로 만듭니다. 데이터 거주, 보존, 감사 가능성, 접근성을 감사자가 직접 읽을 수 있는 arc42 설명에 쓰인 아키텍처상 중요한 요구 사항으로 다루고, 정책 및 보안 담당자를 포함한 가벼운 트레이드오프 워크숍을 열어 충돌(캐싱 대 감사 가능성 같은)이 코드 전에 종이 위에서 드러나게 하십시오. 책임 있는 공무원이 실사를 보여 줄 수 있을 만큼 추론의 흔적을 완전하게 유지하고, 공공 기관을 10년간 단일 벤더에 묶는 것보다 분명한 출구 옵션이 있는 아키텍처를 선호하십시오.

사례

스타트업. 여섯 명 규모의 시드 단계 SaaS 팀은 공식 프로세스 대신 공유 문서에 아키텍처를 두지만, 되돌리기 고통스러울 결정은 여전히 적어 둡니다. 약 열두 개의 ADR(왜 문서 저장소 대신 Postgres인지, 왜 서비스 대신 모듈러 모놀리스인지, 왜 그 인증 제공자를 골랐는지)을 기록하고 초기 고객에게 실제로 중요한 두 개의 품질 속성 시나리오를 고정합니다. “가입이 2초 안에 완료된다”와 “어떤 고객도 다른 테넌트의 데이터를 읽을 수 없다”입니다. 일곱 번째와 여덟 번째 엔지니어를 채용했을 때, 그 메모 덕에 신입들은 일이 왜 이렇게 되어 있는지 모두를 방해하며 묻는 대신 첫 주에 출시합니다.

대기업. 다국적 은행이 열두 개의 지역 결제 시스템을 통합하면서 작은 아키텍처 길드를 세웁니다. 길드는 여덟 개의 품질 속성 시나리오(“초당 1만 건의 트랜잭션을 손실 0으로 처리”, “15분 안에 리전 복구” 포함)를 정의하고, 약 마흔 개의 ADR을 수집하고, CI(지속적 통합)에서 피트니스 함수를 시행합니다. 어떤 서비스도 다른 도메인의 데이터베이스에 쓸 수 없고, 모든 서비스 간 호출은 추적되어야 하며, 치명적 CVE(Common Vulnerabilities and Exposures)가 있는 의존성은 빌드를 실패시킵니다. C4 컨텍스트 및 컨테이너 다이어그램이 모든 설계 리뷰의 공유 지도가 되고 팀 간 통합 분쟁이 급격히 줄어듭니다.

정부. 한 국가 기관이 급여 플랫폼을 현대화하는데, 법이 데이터 거주, 7년 감사 가능성, 접근성 적합성의 보장을 요구합니다. 기관의 아키텍트들은 이를 ASR로 다루고 감사자가 직접 검토하는 arc42 설명에 적습니다. 전달 팀, 보안, 정책 담당자와 함께 가벼운 ATAM 워크숍을 열어 두 후보 아키텍처를 비교하고, 선호된 설계의 캐싱 전략이 감사 가능성 요구 사항과 충돌함을 발견합니다. 코드 한 줄 전에 종이 위에서 그 트레이드오프를 잡은 덕에 몇 달의 재작업을 아끼고, 책임 있는 장관에게 실사의 문서화된 증거를 줍니다.

비즈니스 사례: 동기, ROI, TCO

아키텍처 기본기의 수익은 대부분 피한 비용이어서 예산을 적게 주기 쉽고 건너뛰기에는 비쌉니다. 도입 비용은 소소합니다. 경험 많은 아키텍트 몇 명의 시간, 몇 번의 워크숍, 문서화 템플릿, 피트니스 함수를 위한 약간의 CI 투자이며, 대개 프로그램 예산의 한 자릿수 작은 퍼센트입니다. 도입하지 않는 비용은 나중에, 그것도 할증과 함께 옵니다. 명세되지 않은 품질 속성이 프로덕션에서 실패할 때의 재작업, 문서화되지 않은 결합이 의무화된 변경을 막을 때의 긴급 재플랫폼, 아무도 시스템을 이해하지 못해 길어지는 인시던트, 전달을 멈추거나 벌금을 부르는 감사 실패입니다.

리더십에게는 선택 가능성과 위험을 중심으로 논거를 세우십시오. 좋은 아키텍처 기본기는 미래 변경의 비용(수십 년 시스템 수명 동안 전달 속도와 총소유비용에 대한 직접적 지렛대)을 낮추고, 심각한 인시던트의 빈도와 지속 시간을 줄이며, 규제 기관과 감사자가 이제 요구하는 문서의 흔적을 만들어 냅니다. ADR 습관만으로도 새 리더십 팀이 “우리는 왜 이렇게 만들었습니까?”라고 물었을 때 법의학적 조사 대신 몇 분 안에 답을 얻는 첫 순간 본전을 뽑습니다. 할 수 있는 곳에는 숫자를 붙이십시오. 피한 대규모 재아키텍처링 한 번, 피한 감사 실패 한 번의 비용을 그 실천의 작은 지속 비용과 견주어 보십시오.

안티패턴과 함정

상아탑 아키텍처. 다이어그램은 만들지만 코드를 건드리거나 전달 팀과 대화하지 않는 아키텍트. 그들의 설계는 무시되거나 만들 수 없습니다.
형용사로서의 품질 속성. 숫자도 시나리오도 없이 “확장 가능, 안전, 신뢰할 수 있음”이라 하여, 검증하거나 맞바꿀 방법이 없는 것.
대규모 선행 설계. 이해가 가장 약할 때 결정을 못 박으며 첫 코드 줄 전에 모든 세부를 확정하는 것.
거짓말하는 문서. 작년 시스템을 설명하는 다이어그램. 오도하므로 없는 것보다 나쁩니다.
이력서 주도 설계. ASR을 충족하려는 것이 아니라 경력을 쌓으려고 기술을 고르는 것.
도금. 요구 사항이 요청한 적 없는 규모, 유연성, 일반성을 위해 엔지니어링해 비용과 복잡성을 영구히 더하는 것.
아키텍처 가드레일 없음. 대규모 팀 전반에서 구조를 보존하는 데 피트니스 함수 대신 선의에 의존하는 것.

성숙도 모델

1단계: 시작. 아키텍처가 암묵적이고 개인의 머릿속에 삽니다. 문서화된 품질 속성도, ADR도, 공유 다이어그램도 없습니다. 구조는 인시던트 중에 발견되고, 모든 팀 간 의존성이 처음부터 다시 협상됩니다.
2단계: 발전. 일부 팀이 되돌리기 아플 결정을 적어 두고 핵심 다이어그램을 스케치하지만 실천은 일관되지 않습니다. 한 스쿼드는 ADR을 유지하는데 다른 스쿼드는 하나도 없고, 품질 속성은 측정 가능한 시나리오가 아니라 형용사로 이름 붙고, 문서는 프로젝트 사이에서 낡아 갑니다.
3단계: 표준화. 품질 속성 시나리오와 아키텍처상 중요한 요구 사항이 문서화된 조직 전체 표준에 따라 명세되고 우선순위가 매겨집니다. ADR이 일상이고 코드 옆에 저장되며, C4와 arc42 문서는 공통 템플릿으로 유지되고, 모든 팀에서 중요한 결정에 구조화된 트레이드오프 리뷰가 요구됩니다.
4단계: 관리. 아키텍처가 주장되는 것이 아니라 기준선에 대해 측정됩니다. CI의 피트니스 함수가 p99 지연, 계층화 위반, 추적되지 않은 호출, 취약한 의존성 같은 특성을 보고하고, ADR 커버리지와 문서 신선도가 지표로 추적되며, 트레이드오프 리뷰는 우선순위가 매겨진 시나리오에 비추어 선택지를 채점하고, 합의된 기준선에 대한 표류는 놀람이 아니라 정의된 대응을 촉발합니다. 감사자는 서술만이 아니라 측정된 증거에 의지할 수 있습니다.
5단계: 오케스트레이션. 아키텍처가 조직 전체에서 지속적이고 적응적으로 진화합니다. 피트니스 함수와 인시던트 데이터가 어떤 특성이 중요하고 설계 노력이 어디로 가는지에 되먹임되고, ASR 목록, 품질 속성 우선순위, 가드레일은 의무와 위험이 이동함에 따라 다시 범위가 정해지며, 실천은 전달, 보안, 위험 계획과 통합되어 플랫폼이 처음부터 다시 지어지는 대신 새 요구 사항에 적응합니다.

논의를 위한 아이디어

가장 중요한 시스템에서 협상할 수 없는 품질 속성 세 가지는 무엇이며, 오늘 각각을 측정 가능한 시나리오로 진술할 수 있습니까?
결정이 “아키텍처상 중요”해서 그냥 하는 대신 ADR을 쓸 만하다고 어떻게 판단합니까?
현재 코드 리뷰가 놓치는 표류를 피트니스 함수가 어디서 잡겠습니까?
조직이 과도하게 아키텍처링하고 있습니까, 과소하게 하고 있습니까, 어느 쪽인지 알려 주는 증거는 무엇입니까?
팀의 팀 구조에서 아키텍처에 책임지는 사람은 누구이며, 상아탑과 완전한 무정부를 어떻게 둘 다 피합니까?
외부 감사자가 오늘 적혀 있는 것으로부터 아키텍처의 의도를 어떻게 재구성하겠습니까?

핵심 요점

아키텍처는 되돌리는 데 비용이 많이 드는 결정의 집합입니다. 그 트레이드오프를 의도적으로 하고 기록하십시오.
품질 속성을 측정 가능한 시나리오로 명세하고 구조를 형성하는 아키텍처상 중요한 요구 사항을 식별하십시오.
점진적으로 설계하고 핵심 아키텍처 특성을 자동화된 피트니스 함수로 보호하십시오.
C4 다이어그램, arc42 서술, 코드 옆에 둔 결정별 ADR로 가볍지만 진실하게 문서화하십시오.
엄밀함을 위험에 맞추십시오. 되돌릴 수 없고 영향이 큰 결정에는 무거운 분석을, 나머지 모든 곳에는 가벼운 프로세스를.
비즈니스 사례는 피한 재작업, 더 짧은 인시던트, 더 빠른 미래 변경, 감사 준비된 증거입니다.

참고 문헌과 더 읽을거리

Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures
Simon Brown, Software Architecture for Developers (and the C4 model)
Mark Richards and Neal Ford, Fundamentals of Software Architecture
George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
Michael Nygard, “Documenting Architecture Decisions” (the ADR pattern)
Gernot Starke and Peter Hruschka, arc42 documentation template
Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
ISO/IEC 25010, Systems and software quality models