bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c28d2983a839e4cedd07d508beba45e87b697c34
2nd/10_Wiki/Topics/Architecture/Software_Architecture.md
T

23 KiB
Raw Blame History

category, tags, title, last_updated
category tags title last_updated
Unified
auto-consolidated
technical-documentation
Software Architecture
2026-05-02

Software Architecture

📌 Brief Summary

소프트웨어 아키텍처(Software Architecture)는 시스템을 추론하고 구축하는 데 필요한 청사진이자 기본적인 구조들의 집합으로, 소프트웨어 요소와 이들 간의 관계, 그리고 환경과 설계 원칙을 포함합니다 [1, 2]. 이는 시스템 구현 후 변경 비용이 매우 높기 때문에 시스템 개발 초기에 내려져야 하는 가장 전략적이고 핵심적인 결정의 집합입니다 [2, 3]. 적절한 아키텍처 패턴을 채택함으로써 시스템은 확장성, 유지보수성, 보안 및 내결함성과 같은 주요 품질 속성(Quality Attributes)을 확보하고 비즈니스 목표를 달성할 수 있습니다 [4-6].

소프트웨어 아키텍처는 시스템의 근본적인 구조와 청사진을 의미하며, 소프트웨어 요소와 그들 간의 관계 및 속성을 정의하는 거시적인 설계 규율입니다[1], [2], [3]. 이는 시스템의 확장성, 유지보수성, 성능, 보안 등의 품질 속성을 보장하기 위한 뼈대 역할을 하며, 개발 프로젝트 관리와 의사소통의 기준이 됩니다[4], [5], [6]. 아키텍처는 초기 설계 단계에서 결정되고 한 번 구현되면 변경 비용이 매우 높으므로, 비즈니스 목적과 트레이드오프(Trade-off)를 고려한 신중한 선택이 필수적입니다[7], [3].

📖 Core Content

  • 소프트웨어 아키텍처의 본질 및 범위 소프트웨어 아키텍처는 시스템이 요구하는 기능적 요구사항과 성능, 신뢰성, 확장성, 보안 등의 비기능적 요구사항(품질 속성)이 구조적으로 어떻게 실현되는지에 초점을 맞춥니다 [5, 7]. 이는 거시적인 시스템 구조를 정의하는 반면, 소프트웨어 디자인 패턴은 개별 컴포넌트나 클래스 내부의 특정 문제를 해결하는 미시적인 솔루션이라는 점에서 차별화됩니다 [8-10]. 아키텍처는 시스템 구조뿐만 아니라, 그러한 구조적 선택을 이끈 아키텍처 결정(Architectural Decisions)과 그에 대한 근거(Rationale)의 집합을 모두 포함합니다 [11].

  • 아키텍처 결정 및 평가 방법론 적절한 아키텍처 패턴은 단순한 유행이 아니라 명확한 품질 요구사항을 기반으로 선택되어야 합니다 [6]. ISO/IEC 25010과 같은 품질 모델을 이용해 기능 적합성, 성능 효율성, 호환성 등을 우선순위화합니다 [6, 12]. 이후 ATAM(Architecture Tradeoff Analysis Method)과 같은 방법론을 통해 시나리오 기반으로 각 구조의 장단점(Trade-offs)과 리스크를 면밀히 분석하고, 프로토타이핑을 통해 조기 검증을 수행합니다 [13-15]. 이러한 모든 설계 결정 사항은 ADR(Architecture Decision Record)을 통해 맥락과 대안, 결과를 꼼꼼히 문서화하여 향후 시스템이 진화하더라도 의사결정의 근거를 보존해야 합니다 [16-18].

  • 주요 아키텍처 패턴 및 특성 현대 소프트웨어 공학에서 활용되는 대표적인 패턴은 다음과 같습니다.

    • 계층형 아키텍처(Layered Pattern): 프레젠테이션, 비즈니스, 데이터 계층 등 수평적으로 책임을 분리하여 유지보수성과 테스트 용이성을 높이는 가장 고전적이고 친숙한 모델입니다 [19, 20].
    • 클라이언트-서버 및 P2P(Client-Server & P2P): 중앙 서버가 자원과 데이터 제어를 전담하는 클라이언트-서버와 달리, P2P는 모든 노드가 클라이언트이자 서버 역할을 동시에 수행하여 중앙 서버의 병목과 단일 장애점(SPOF)을 제거합니다 [21-23].
    • 마이크로서비스 아키텍처(Microservices Pattern): 애플리케이션을 작고 독립적으로 배포 가능한 비즈니스 도메인 서비스들의 집합으로 분할하여(주로 '서비스당 데이터베이스' 원칙 사용), 빠른 배포 파이프라인과 극대화된 수평적 확장성을 제공합니다 [24-26].
    • 이벤트 기반 아키텍처(Event-Driven Pattern): 상태 변화(이벤트)를 비동기적으로 생산하고 소비하는 구조로, 극단적으로 낮은 결합도(Loose Coupling)와 대용량 트래픽의 실시간 처리에 최적화되어 있습니다. 브로커(Broker)와 메디에이터(Mediator) 토폴로지로 나뉩니다 [27-29].
    • 마이크로커널 아키텍처(Microkernel Pattern): 최소한의 핵심 기능을 담은 코어 시스템에 특화된 플러그인 모듈들을 결합하여 유연한 기능 확장성을 제공합니다 [30, 31].
    • 도메인 중심 아키텍처(Hexagonal, Clean, Onion): 의존성 방향을 내부의 비즈니스 로직으로 향하게 만들어 데이터베이스, UI 등 기술적 세부사항으로부터 핵심 도메인을 완벽히 격리하는 의존성 역전을 실현합니다 [32].
    • 공간 기반 아키텍처(Space-Based Pattern): 관계형 데이터베이스의 병목을 없애기 위해 메모리 내 데이터 그리드(In-memory Data Grid)를 분산 공유하여 동시성과 대규모 부하를 처리합니다 [33, 34].
  • 아키텍처의 본질과 원칙 소프트웨어 아키텍처는 "모든 것은 트레이드오프다(Everything is a trade-off)"와 "어떻게(how)보다 왜(why)가 더 중요하다"는 두 가지 근본 법칙을 따릅니다[7]. 아키텍처 설계는 단순한 기술적 트렌드가 아니라 시스템이 해결해야 할 비즈니스 목적, 부하 프로필, 그리고 ISO/IEC 25010과 같은 표준 기반의 품질 요구사항(성능 효율성, 호환성, 상호작용 능력 등)에 맞춰 결정되어야 합니다[8], [9].
  • 아키텍처 패턴(Architecture Pattern) vs 디자인 패턴(Design Pattern) 아키텍처 패턴과 디자인 패턴은 흔히 혼용되나 적용 범위가 다릅니다. 아키텍처 패턴은 마이크로서비스, 계층형, 이벤트 기반 아키텍처 등 전체 시스템의 구조와 컴포넌트 간 상호작용을 다루는 거시적(Macro-level) 솔루션입니다[10], [11], [3]. 반면, 디자인 패턴(예: 싱글톤, 팩토리 패턴)은 단일 모듈이나 클래스 내에서 발생하는 반복적인 문제를 해결하는 미시적(Micro-level) 솔루션입니다[12], [3].
  • 핵심 아키텍처 활동 (Core Architecture Activities) 아키텍처 설계는 네 가지 반복적인 핵심 활동을 포함합니다[13]. 요구사항을 수집하고 아키텍처에 유의미한 영향을 미치는 요소를 파악하는 '분석(Analysis)', 도출된 요구사항을 바탕으로 설계를 창조하는 '합성/설계(Synthesis)', ATAM(Architecture Tradeoff Analysis Method) 등의 기법을 이용해 설계가 요구사항을 충족하는지 평가하는 '평가(Evaluation)', 그리고 환경 변화에 맞춰 시스템을 유지보수하고 적응시키는 '진화(Evolution)'입니다[13], [14], [15].
  • 조직 구조와 콘웨이의 법칙 (Conway's Law) 아키텍처 결정은 조직의 형태와 불가분의 관계를 맺습니다. "시스템 설계는 조직의 통신 구조를 모방하게 된다"는 콘웨이의 법칙에 따라, 소프트웨어 아키텍처는 기술적 요구뿐만 아니라 개발 팀의 규모, 역량, DevOps 성숙도 등 조직적 맥락과 완벽히 부합해야 성공적으로 유지될 수 있습니다[16], [17].

⚖️ Trade-offs & Caveats

소프트웨어 아키텍처 결정에는 "모든 것은 트레이드오프(Everything is a trade-off)"라는 제1법칙이 존재하며 완벽한 아키텍처는 없습니다 [3, 14].

  • 분산 시스템의 복잡성과 비용: 마이크로서비스(MSA)나 이벤트 기반 아키텍처는 뛰어난 자율성과 확장성을 주지만, 분산 트랜잭션 처리(Saga 패턴 등 적용 필요), 네트워크 지연, 비동기 디버깅, 다중 데이터베이스 간의 데이터 최종 일관성(Eventual Consistency) 등 막대한 운영 및 설계 복잡성을 야기합니다 [35-37].
  • 서버리스(Serverless)의 제약: 서버리스는 인프라 관리 부담을 줄이고 사용량만큼만 비용을 지불하지만, 벤더 종속(Vendor Lock-in) 문제와 함께 일정 시간 비활성화 시 발생하는 콜드 스타트(Cold Start) 지연 시간 문제가 있어 실시간 응답이 필수적인 서비스에는 치명적일 수 있습니다 [38-40].
  • 오버 엔지니어링의 위험: 작은 규모의 팀이나 단순한 CRUD 애플리케이션에 트렌드라는 이유만으로 MSA를 도입하면 오히려 생산성이 하락할 수 있습니다 [41, 42]. 이 경우 철저히 모듈화된 단일 배포 단위인 모듈형 모놀리스(Modular Monolith)를 채택하는 것이 확장성을 열어두면서 운영 복잡도를 낮추는 훌륭한 대안이 됩니다 [43, 44].
  • 아키텍처 부식(Erosion): 초기 설계와 실제 구현 코드 사이에 괴리가 생기며 기술 부채가 누적되는 아키텍처 부식 현상이 일어날 수 있으므로, 지속적인 컴플라이언스 체크와 엄격한 ADR 관리가 요구됩니다 [45].
  • 성능(Performance) vs 유연성 및 확장성(Flexibility & Scalability) 모놀리식이나 계층형(Layered) 아키텍처는 초기 개발이 빠르고 하나의 코드베이스에서 관리되므로 특정 환경에서는 성능적 이점이 있으나, 시스템이 커질수록 잦은 변경과 부분적인 확장이 불가능해지는 한계가 있습니다[18], [19]. 반대로 마이크로서비스 아키텍처(MSA)나 이벤트 기반 아키텍처(EDA)는 구성 요소를 분리하여 유연성과 수평적 확장성을 극대화하지만, 서비스 간 네트워크 통신 오버헤드, 복잡한 디버깅, 분산 데이터 일관성(Eventual Consistency) 관리라는 막대한 운영 복잡성 비용을 치러야 합니다[20], [21], [22].
  • 아키텍처 침식 (Architecture Erosion) 소프트웨어 개발 수명 주기가 진행됨에 따라, 의도했던 아키텍처와 실제로 구현된 아키텍처 간의 격차가 벌어지는 '아키텍처 침식'이 발생할 수 있습니다[23]. 이는 기술 부채의 축적, 아키텍처 규칙 위반, 지식의 증발 등으로 인해 발생하며, 결과적으로 시스템의 성능을 저하시키고 유지보수 비용을 기하급수적으로 증가시킵니다[24].
  • 의사결정의 지연과 분석 마비 (Analysis Paralysis) 잘못된 아키텍처를 선택할 것에 대한 두려움으로 인해 설계 결정을 미루는 안티패턴(Anti-pattern)이 발생할 수 있습니다. 이는 개발 진행을 방해하므로, 적절한 피드백 수용과 함께 "마지막 책임 순간(last responsible moment)"에 결정을 내리고, 프로토타이핑을 통해 조기에 리스크를 검증해야 합니다[25], [26].

🔗 Knowledge Connections

Related Concepts

[아키텍처 설계 사상 및 패러다임]

  • 마이크로서비스 아키텍처 (Microservices Architecture)

    • 연결 이유: 현대 엔터프라이즈급 확장성과 애자일한 조직 구조를 지원하는 핵심 아키텍처 패턴입니다 [46, 47].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 배포 파이프라인 구성, 도메인 분리, 서비스 간 비동기 메시징 기반 협업, 그리고 마이크로서비스 섀시 및 API 게이트웨이 등의 분산 컴포넌트 전략.

  • 이벤트 기반 아키텍처 (Event-Driven Architecture)

    • 연결 이유: 시스템의 결합도를 극한으로 낮추고 실시간 데이터 스트리밍과 높은 동시성을 처리하기 위해 활용되는 아키텍처입니다 [28, 48].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브로커(Choreography) 방식과 메디에이터(Orchestration) 방식의 통제 수준 차이, 큐(Queues)와 스트림(Streams)을 활용한 이벤트 관리 메커니즘과 상태 회복.

  • 헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)

    • 연결 이유: 비즈니스 핵심 로직을 데이터베이스 및 프레임워크와 같은 기술적 세부사항으로부터 완벽히 보호하는 아키텍처 지침입니다 [32, 49].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 포트(Port)와 어댑터(Adapter)를 이용한 의존성 역전 원칙, 뛰어난 테스트 용이성, 그리고 클린 아키텍처 및 어니언 아키텍처와의 구조적 상호작용.

[아키텍처 의사결정 및 검증 도구]

  • ATAM (Architecture Tradeoff Analysis Method)

    • 연결 이유: 아키텍처가 품질 요구사항에 얼마나 잘 부합하는지 평가하고 트레이드오프를 체계화하는 평가 방법론입니다 [13, 14].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템의 민감도와 잠재적 리스크를 시나리오 기반으로 도출하여, 아키텍처 결정이 조직의 비즈니스 목표에 미치는 영향을 객관화하는 절차.

  • ADR (Architecture Decision Records)

    • 연결 이유: 아키텍처 결정 사항을 문서화하여 시스템 구조의 유지보수성과 맥락 보존을 지원하는 도구입니다 [16, 17].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 의사결정 당시의 기술적·비즈니스적 배경, 거절된 대안 및 예상 결과를 기록함으로써, 조직의 구조 변경이나 인력 교체 시에도 '설계 의도'가 변질되는 아키텍처 부식(Erosion)을 방지하는 원리.

Deeper Research Questions

  • 분산 아키텍처(마이크로서비스) 환경에서 데이터베이스가 개별 분리됨에 따라 발생하는 분산 트랜잭션 및 최종 일관성(Eventual Consistency) 문제를 Saga 패턴과 CQRS를 활용하여 어떻게 효과적으로 제어할 수 있는가? [28, 36]
  • 콘웨이의 법칙(Conway's Law)이 조직 구조(팀 크기, 데브옵스 숙련도)와 아키텍처 패턴 결정에 어떠한 영향을 미치며, 성공적인 마이크로서비스 이전을 위해 선행되어야 할 조직적 변화는 무엇인가? [42, 50]
  • 대규모 트래픽을 처리하는 시스템에서 이벤트 기반 아키텍처의 이벤트 스트리밍(예: Kafka)과 공간 기반 아키텍처(Space-Based)의 인메모리 데이터 그리드(IMDG) 방식을 병합(Hybrid)하여 성능을 최적화하는 전략과 그 한계는 무엇인가? [34, 51, 52]
  • 클린 아키텍처 또는 헥사고날 아키텍처의 의존성 규칙이 초기 개발 비용을 상승시킴에도 불구하고 엔터프라이즈 장기 유지보수 및 보안 경계(Security Boundaries) 형성에서 얻는 트레이드오프의 경제적 가치는 어떻게 증명할 수 있는가? [32, 53, 54]
  • 빈번히 변동하는 부하(Burst Workload)를 가진 애플리케이션에 대해, 콜드 스타트를 극복하기 위한 서버리스(Serverless)와 모듈형 모놀리스(Modular Monolith)를 혼합 적용하는 전략적 분기점(Tipping Point)은 어디인가? [55-60]

Practical Application Contexts

  • Implementation: 비즈니스 핵심 로직과 인프라의 결합도를 낮추기 위해 코드베이스 구현 시 헥사고날 아키텍처의 포트(인터페이스)와 어댑터를 적용하여 독립적인 단위 테스트가 가능하게 설계함 [49, 61, 62].
  • System Design: C4 모델 등 가벼운 다이어그램 도구를 통해 각 컴포넌트 간 관계와 제약사항을 시각화하고, ATAM을 통해 극단적인 로드(예: 10분 내 사용자 두 배 증가) 시나리오에 대한 시스템 병목을 평가 후 적절한 분산 패턴을 적용 [13, 14, 63].
  • Operation / Maintenance: 서킷 브레이커(Circuit Breaker) 패턴을 도입해 마이크로서비스 통신 중 발생하는 연쇄 장애를 격리하고, ADR을 위키에 보관해 새롭게 합류한 데브옵스 팀원들의 온보딩 속도를 높임 [16, 37, 64].
  • Learning Path: 단순한 계층형 아키텍처(N-Tier)로 시작하여 시스템 설계의 기초와 관심사의 분리를 배운 뒤, 점진적으로 도메인 주도 설계(DDD)와 비동기 메시지 패싱(EDA), 최종적으로 분산 클라우드 네이티브 패턴(MSA, Serverless) 순으로 확장 학습 [44, 65].
  • My Project Relevance: 기한과 자원이 한정된 초기 스타트업 MVP 프로젝트에 마이크로서비스를 무리하게 도입하기보다, 우선 모듈형 모놀리스 혹은 단일 서버리스 기능으로 빠르게 시장 검증을 수행하고 향후 확장을 대비한 모듈 분리(Clean Architecture 적용)를 수행함 [66, 67].

Adjacent Topics

  • 도메인 주도 설계 (Domain-Driven Design, DDD)
    • 확장 방향: 마이크로서비스 패턴에서 각 서비스를 식별하고 책임을 격리하는 논리적 경계(Bounded Context)를 정의하기 위한 비즈니스 모델링 기법의 연계 탐구 [26].
  • 소프트웨어 디자인 패턴 (Software Design Patterns)
    • 확장 방향: 전체 아키텍처 수준이 아니라 각 계층이나 모듈 내부에서 반복되는 코딩 수준의 구현 문제(객체 생성, 구조, 행위)를 재사용 가능한 방식으로 해결하는 원리 이해 [8].

Last updated: 2026-05-02

Related Concepts

[관계 유형 A: 아키텍처 설계 및 평가 프레임워크]

  • ATAM (Architecture Tradeoff Analysis Method)

    • 연결 이유: 아키텍처를 시스템의 비즈니스 목표와 품질 속성에 비추어 체계적으로 평가하기 위해 SEI에서 개발한 방법론입니다[27], [28].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상적인 요구사항 대신 구체적인 '시나리오'를 활용하여 아키텍처의 트레이드오프(Trade-offs)와 민감점(Sensitivity points), 잠재적 리스크를 분석하는 원리를 이해할 수 있습니다[27], [28].

  • ADR (Architecture Decision Record)

    • 연결 이유: 복잡한 시스템 개발에서 아키텍처에 관한 주요 결정 사항을 문서화하는 핵심 도구입니다[29], [30].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 결정의 맥락, 선택 이유, 대안 및 리스크를 명확히 기록하여 시간이 지나거나 팀원이 변경되더라도 아키텍처의 개념적 무결성을 유지하고 아키텍처 침식을 방지하는 방법을 배울 수 있습니다[25], [29].

[관계 유형 B: 주요 아키텍처 패턴 유형]

  • 마이크로서비스 아키텍처 (Microservices Architecture)

    • 연결 이유: 거대한 모놀리식 구조를 비즈니스 도메인별로 작고 독립적인 서비스로 분할하는 현대 소프트웨어 생태계의 대표적 패턴입니다[31], [32].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 배포 및 확장성의 이점과 함께, 분산 트랜잭션 처리(Saga 패턴 등) 및 서비스 간 결합도를 낮추는 고급 설계 원칙을 이해할 수 있습니다[33], [22].

  • 이벤트 기반 아키텍처 (Event-Driven Architecture)

    • 연결 이유: 상태 변화(이벤트)를 중심으로 컴포넌트가 비동기적으로 상호작용하여 시스템 처리량과 실시간 반응성을 극대화하는 패턴입니다[34], [35], [22].
    • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 간 극단적인 느슨한 결합(Loose Coupling)을 이루는 방식과, 이벤트 흐름을 제어하는 브로커(Broker) 및 메디에이터(Mediator) 토폴로지의 설계상 차이를 깊이 파악할 수 있습니다[36], [37].

Deeper Research Questions

  • 모놀리식 아키텍처에서 마이크로서비스 아키텍처로의 마이그레이션 시 발생하는 분산 데이터의 '최종 일관성(Eventual Consistency)' 문제를 보완하기 위해 Saga 패턴은 어떻게 동작하며 어떤 한계가 있는가?
  • 조직의 의사소통 구조가 소프트웨어 시스템 구조를 결정한다는 '콘웨이의 법칙(Conway's Law)'은 팀 규모와 DevOps 환경을 고려한 실제 아키텍처 설계 단계에 어떻게 적용될 수 있는가?
  • 이벤트 기반 아키텍처(EDA) 설계 시 워크플로우 제어를 위해 '브로커(Broker)' 토폴로지와 '메디에이터(Mediator)' 토폴로지를 결정짓는 구체적인 비즈니스 요구사항과 트레이드오프 기준은 무엇인가?
  • 소프트웨어 수명 주기 동안 발생하는 '아키텍처 침식(Architecture Erosion)'을 식별하고 예방하기 위한 자동화된 분석 기법 및 리팩토링 전략은 무엇이 있는가?
  • 비즈니스 로직을 외부 기술 스택으로부터 완전히 분리하는 클린 아키텍처(Clean Architecture)나 헥사고날 아키텍처(Hexagonal Architecture)는 의료나 금융 같은 고보안·고규제 도메인에서 어떤 구조적 이점을 극대화하는가?

Practical Application Contexts

  • Implementation: 아키텍처 패턴의 원칙(예: 헥사고날 아키텍처의 포트와 어댑터)에 따라 코드 베이스의 패키지 구조를 분리하고, 비즈니스 로직과 외부 데이터베이스 인터페이스의 의존성을 역전시켜 기술 교체가 용이한 코드를 구현합니다.
  • System Design: 트래픽의 스파이크 현상이나 데이터 처리량(ISO 25010 기반 성능 효율성) 등을 예측하여, 단일 배포가 유리한 모듈형 모놀리스로 시작할지 처음부터 높은 확장성의 피어-투-피어(P2P) 또는 마이크로서비스를 채택할지 결정하는 청사진을 설계합니다.
  • Operation / Maintenance: ADR(Architecture Decision Record)을 지속적으로 업데이트하여 시스템 변화 내력을 투명하게 관리하며, 분산 아키텍처의 경우 서킷 브레이커나 분산 로깅 등을 운영 환경에 도입하여 장애 격리와 복구 능력을 강화합니다.
  • Learning Path: 가장 기본이 되는 계층형 아키텍처(Layered Architecture)의 원리를 이해한 후 -> 디자인 패턴과 도메인 주도 설계(DDD)를 학습하고 -> 마이크로서비스, 서버리스 등의 분산 아키텍처 설계로 넘어가며 -> 마지막으로 ATAM을 통해 여러 아키텍처의 장단점을 평가하는 역량을 기릅니다.
  • My Project Relevance: 현재 진행 중인 프로젝트의 팀 규모, 예산, 예상 트래픽(Context)을 분석하여, 오버엔지니어링(예: 무리한 MSA 도입)을 피하면서도 향후 비즈니스 확장에 대비할 수 있는 구조적 뼈대를 선택하는 데 직접적인 기준이 됩니다.

Adjacent Topics

  • 도메인 주도 설계 (Domain-Driven Design)
    • 확장 방향: 마이크로서비스 아키텍처 등에서 서비스를 분할하는 논리적 기준인 '바운디드 컨텍스트(Bounded Context)'를 설정하고 비즈니스 규칙을 중심에 두는 상세한 도메인 모델링 기법으로 이해를 확장합니다.
  • 서버리스 컴퓨팅 (Serverless Computing)
    • 확장 방향: 개발자가 서버 인프라를 전혀 관리하지 않고 이벤트 트리거에 따라 함수 단위로 코드가 실행 및 과금되는 클라우드 네이티브 아키텍처의 최전선 기술로 시야를 넓힙니다.
  • 소프트웨어 설계 패턴 (Software Design Patterns)
    • 확장 방향: 아키텍처가 시스템의 뼈대라면, 객체 생성, 구조, 행위 등 컴포넌트 내부에서 발생하는 반복적 문제에 대해 유연하게 대응할 수 있는 미시적인 설계 도구(GoF 디자인 패턴 등)로 학습을 전개합니다.

Last updated: 2026-05-02

Reference in New Issue View Git Blame Copy Permalink