N° 01 — 목록
'Software Architecture/Architectural Styles' (12)
-
Software Architecture/Architectural StylesArchitectural Styles - 12. 아키텍처 스타일 비교
아키텍처 스타일 비교 — 같은 요구, 다른 정답한 스타트업이 주문 시스템을 설계한다고 하자. 요구사항은 명확하다 — 하루 10만 건 주문, 결제 연동, 재고 관리, 향후 확장 가능성. 이 요구사항을 놓고 열두 가지 스타일 중 어느 것을 고를까. 정답은 "그때그때 다르다"가 아니라 "주어진 품질 속성 우선순위에 따라 다르다"다. 같은 기능(주문 처리)이라도, 어느 품질 속성(확장성·단순성·독립 배포·강한 일관성)이 결정적인가에 따라 정답이 갈린다. 이 글은 지금까지 다룴 열한 가지 스타일을 같은 잣대로 비교하고, 선택의 기준을 정리한다.비유로 감 잡기 — 집의 골조 선택같은 "3가족이 사는 집"을 짓는다고 하자. 세 가지 옵션이 있다고 가정한다.단독주택 한 채 — 모두가 한 지붕 아래 산다. 공간 효율 좋..
-
Software Architecture/Architectural StylesArchitectural Styles - 11. 마이크로커널과 서버리스
마이크로커널과 서버리스 — 코어를 최소화하는 두 형태Eclipse IDE를 켜보자. 핵심은 작다 — 플랫폼 런타임, 번들 시스템, 워크벤치. 그 위에 수백 개의 플러그인이 얹혀 있다. JDT(Java 개발 도구), CDT(C/C++), PyDev(Python), Git 통합, 디버거, 마켓플레이스에서 다운받는 수천 개의 확장. 핵심 코어는 플러그인이 뭘 하는지 모른다 — 그저 정해진 확장점(extension point)으로 플러그인이 참여할 뿐이다. 이 구조의 이름이 마이크로커널(microkernel)이다. 반대 극단에 AWS Lambda 같은 서버리스(serverless) FaaS가 있다 — 함수 하나가 코어 없이 그 자체로 실행 단위. 두 스타일은 다른 것 같지만, "코어를 최소화하고 확장에 집중한다..
-
Software Architecture/Architectural StylesArchitectural Styles - 10. 파이프라인
파이프라인 아키텍처 — 단계별로 흐르는 구조터미널에서 한 번쯤 이런 명령을 쳐봤을 것이다.cat access.log | grep "404" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20이 한 줄은 다섯 개의 프로그램(cat, grep, awk, sort, uniq)이 '파이프'(|)로 연결돼, 앞의 출력이 뒤의 입력으로 흘러간다. 각 프로그램은 자기 일만 하고, 다른 단계가 뭘 하는지 모른다. 이 간결한 구조가 파이프라인(pipeline) 또는 파이프-필터(pipe-filter) 아키텍처 스타일이다. Doug McIlroy가 1964년에 제안하고 1973년 Unix에 구현된 이후로, 데이터 처리 시스템의 자연스러운 형태가 됐다.이 글이 다루는 질문..
-
Software Architecture/Architectural StylesArchitectural Styles - 09. 이벤트 소싱
이벤트 소싱 — 상태를 이벤트의 누적으로 저장하기은행 통장을 펼쳐보자. 잔액은 단 하나의 숫자로 표시되지만, 그 숫자가 어떻게 됐는지를 보여주는 건 '거래 내역'이다. 7월 1일 입금 100만 원, 7월 5일 출금 30만 원, 7월 10일 입금 50만 원. 이 내역들을 순서대로 적용하면 잔액 120만 원이 나온다. 잔액은 '계산된 결과'고, 거래 내역이 '진짜 데이터'다. 은행이 잔액만 저장하고 내역을 버리면, "왜 120만 원이지?"라는 질문에 답할 수 없다. 이벤트 소싱(event sourcing)은 이 은행 통장 모델을 소프트웨어에 적용한 것이다 — 현재 상태를 덮어쓰지 않고, 상태 변경을 이벤트로 append-only 저장한다. 현재 상태는 이벤트를 재생해 계산한다.이 글이 다루는 질문: 상태를 ..
-
Software Architecture/Architectural StylesArchitectural Styles - 08. CQRS
CQRS — 명령과 질의를 가르는 선택한 전자상거래 시스템의 접근 패턴을 보자. 주문 생성(쓰기)은 하루 10만 건, 주문 조회(읽기)는 하루 1억 건이다. 1000 대 1의 비율이다. 그런데도 같은 Order 모델, 같은 OrderRepository, 같은 DB를 쓴다. 읽기 최적화(인덱스, 캐싱, 복제본)를 하려 해도 쓰기 모델에 영향을 줘서 함부로 못 건드린다. 쓰기 트랜잭션의 무결성을 지키려면 읽기 성능을 희생해야 하고, 읽기 성능을 올리려면 쓰기 무결성이 흔들린다. 이 교착에서 빠져나오는 한 방법이 CQRS(Command Query Responsibility Segregation)다. 명령(쓰기)과 질의(읽기)를 아예 다른 모델로 가르는 것.이 글이 다루는 질문: 같은 모델로 읽고 쓰는 게 항상..
-
Software Architecture/Architectural StylesArchitectural Styles - 07. 이벤트 기반 아키텍처
이벤트 기반 아키텍처 — 비동기가 만드는 새로운 일관성결제 서비스가 3초 걸린다고 하자. 모놀리스에서 동기 호출로 묶여 있으면, 주문은 결제가 끝날 때까지 3초 대기한다. 요청이 몰리면 스레드 풀이 고갈되고 전체 장애로 번진다. 이 장면을 이벤트 기반으로 바꾸면 — 주문은 접수만 하고 'OrderPlaced' 이벤트를 발행한다. 결제 서비스는 그 이벤트를 받아 자기 속도로 처리한다. 주문은 결제가 3초 걸리든 30초 걸리든 영향받지 않는다. 이게 이벤트 기반 아키텍처(event-driven architecture)의 약속이다.이 글이 다루는 질문: 비동기 이벤트가 푸는 문제는 무엇이고, 그 대가로 요구하는 것은 무엇인가. 푸는 문제는 '결합과 장애 전파'고, 대가는 '강한 일관성과 디버깅 단순함'이다.비..