S(*). Architect

이 글의 목적소프트웨어 아키텍처 본편 25편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.25편 동안 본 개념을 한 장 지도로 다시 본다아키텍처에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다아키텍처 지식이 어떤 직업·역할과 맞닿는지 정리한다손으로 확인하는 방법과 읽을거리를 남긴다1. 25편이 만든 큰 그림아키텍처는 한 패턴 이름이 아니라 트레이드오프를 기록하고 운영하는 일이다.Part핵심 질문기억할 키워드0~1 기초무엇이 아키텍처이고 누가 무엇을 걱정하나concern, 품질 속성, 트레이드오프2 스타일구조를 어떻게 나누나레이어드, 헥사고날, MSA, EDA3 원칙모듈·도메인을 어떻게 묶나SOLID, 결합·응집, Bounded Context4 분산여러 노드..

학습 목표Strangler Fig 패턴으로 레거시를 점진 퇴출하는 흐름을 설명할 수 있다.Branch by Abstraction으로 구현 교체 전 경계를 만들 수 있다.트래픽 램프·병행 운영·롤백 플랜을 웨이브 단위로 설계할 수 있다.앞서 본 팀 토폴로지·ADR·CDC·outbox를 마이그레이션 프로그램에 연결할 수 있다.문제 상황legacy-shop-monolith — 단일 WAR, 공유 Oracle, 14년 이력2년 빅뱅 재작성 프로젝트 중단 — 아무 것도 프로덕션 안 감MSA 설계·C4·팀 맵은 있는데 트래픽 80%는 여전히 모놀리스주문 API 분리 시도 — dual write로 재고 불일치 3건 /주결제 모듈 떼 내려 했으나 URL 그대로 — 고객 앱 배포 없이 내부 만 바뀜 실패롤백 플랜 없이 ..

학습 목표Conway's Law가 아키텍처·조직에 미치는 영향을 설명할 수 있다.Team Topologies 4유형(stream-aligned·platform·enabling·complicated-subsystem)을 구분할 수 있다.상호작용 모드(collaboration·X-as-a-Service·facilitating)를 팀 설계에 적용할 수 있다.앞서 본 MSA·Bounded Context와 팀 경계를 정렬하는 방법을 설명할 수 있다.문제 상황마이크로서비스 12개인데 팀은 프론트 / 백엔드 / DBA — 서비스 소유 없음플랫폼 팀이 배포 티켓 만 — stream 팀 대기 3일주문 장애에 결제·재고·알림 팀 동시 소집 — 엔드투엔드 오너 없음아키텍트 4명이 모든 PR gate — 병목CDC·검색 인덱..

학습 목표서비스 메시가 K8s Service·Ingress와 다른 문제(L4/L7 내부 통신·보안·관측)를 해결하는지 설명할 수 있다.sidecar 프록시와 control plane·data plane 역할을 구분할 수 있다.mTLS(PeerAuthentication)로 서비스 간 암호화·신원을 적용하는 방식을 설명할 수 있다.VirtualService·DestinationRule로 traffic split·retry·timeout을 코드 없이 정책화할 수 있다.canary 배포와 mesh 트래픽 분할을 연계하고 도입 트레이드오프를 평가할 수 있다.문제 상황서비스 20개 — 각 팀이 retry·timeout·circuit breaker 라이브러리 제각각평문 ClusterIP 통신 — Pod 탈취 시 내부..

학습 목표동기 vs 비동기 서비스 간 통신의 결합·지연·일관성 트레이드오프를 설명할 수 있다.REST와 gRPC를 동기 IPC 관점에서 비교·선택할 수 있다.메시지 큐·이벤트 기반 비동기 통신의 역할을 설명할 수 있다.Saga로 분산 트랜잭션을 보상(compensating) 으로 다루는 방식을 설명할 수 있다.문제 상황주문 API p99 2.8s — Payment·Inventory·Points 순차 REST, hop마다 +400msPayment 503 → Order 503 — caller가 전체 실패, 재고는 이미 예약됨모바일이 Catalog 20번 호출 — BFF 없이 chatty REST팀 A는 JSON REST, 팀 B는 Protobuf gRPC — Gateway에서 변환 지옥"비동기로 바꿨다"는데..

학습 목표Part 2에서 본 아키텍처 스타일을 한 표로 비교할 수 있다.모놀리스·MSA·EDA를 팀·도메인·트래픽·운영 기준으로 선택할 수 있다.모듈러 모놀리스·하이브리드가 현실적인 중간 지점임을 설명할 수 있다.스타일 선택을 ADR로 기록해야 하는 이유를 설명할 수 있다.문제 상황"우리도 MSA 해야 하나?" — 경쟁사만 보고 결정레이어드 → 헥사고날 → MSA → Kafka까지 한 번에 도입운영·조직이 따라오지 못함모놀리스인데 마이크로서비스 급 배포 파이프라인만 6개월MSA인데 공유 DB + 동기 체인 7홉 — 최악의 조합스타일 논쟁이 6개월 — 품질 속성·제약 없이 취향 싸움2년 뒤 "왜 MSA 했지?" — 결정 근거 문서 없음레이어드·헥사고날·MSA·EDA를 각각 봤다. 이번 편은 무엇을 언제 고..

학습 목표마이크로서비스(MSA) 가 독립 배포·소유권·장애 격리를 목표로 하는 아키텍처 스타일임을 설명할 수 있다.서비스 분해 기준(비즈니스 capability, bounded context)을 설명할 수 있다.API Gateway와 BFF의 역할 차이를 설명할 수 있다.Database per service·장애 격리 원칙과 분산 monolith 함정을 설명할 수 있다.문제 상황모놀리스 하나에 팀 8개가 같은 repo에 PR을 낸다릴리스 한 번에 전체가 묶인다결제 모듈만 스케일하고 싶은데 WAS 전체를 20대로 늘린다CPU는 주문 API가, 결제는 idle재고 API 장애가 주문·결제·알림까지 연쇄 503동기 호출 체인에 타임아웃·격리 없음"MSA 전환" 후에도 하나의 PostgreSQL에 40개 테이블..

학습 목표소프트웨어 아키텍처가 무엇이고 왜 필요한지 설명할 수 있다.아키텍트와 개발자의 역할 차이를 설명할 수 있다.아키텍처의 주요 산출물과 품질 속성을 구분할 수 있다.22편 로드맵을 보고 학습 순서를 잡을 수 있다.1. 소프트웨어 아키텍처란?구조(Structure) 와 설계 결정(Design Decision) 의 집합컴포넌트가 무엇인지, 어떻게 연결되는지왜 이 구조를 선택했는지 (트레이드오프)코드만이 아니다배포 단위, 데이터 흐름, 통신 방식, 운영 방식까지 포함"동작하는 코드"와 "오래 가는 구조"는 다르다아키텍처 vs 디자인 (개요)아키텍처: 변경하기 어려운 결정 (기술 스택, 서비스 분해, 통신 패턴)디자인: 모듈·클래스 수준의 결정 (2편에서 상세)왜 필요한가시스템이 커질수록 구조 없이는 변경..