Software Architecture 101 스터디 4-5주차 회고를 공유합니다. 이번 주차에서는 이벤트 주도 아키텍처(EDA), 공간 기반 아키텍처(SBA), 마이크로서비스(MSA), 그리고 ADR(Architecture Decision Records)을 다뤘는데요, 현업 경험담이 많이 오가면서 정말 알찬 시간이었습니다.
Part 1. 이벤트 주도 아키텍처 (EDA)
첫 번째 주제는 분산 시스템의 꽃이라 불리는 이벤트 주도 아키텍처였습니다. 가장 먼저 이벤트와 메시지의 차이를 정리했는데, 이벤트는 "어떤 일이 일어났음"을 알리는 비동기 통지이고, 메시지는 특정 수신자에게 "무언가를 하라"는 명령에 가깝습니다.
가장 많은 이야기가 오갔던 토론 주제는 이벤트 페이로드를 어디까지 담을 것인가에 대한 것이었습니다. ID만 전달하는 Thin Event는 가볍지만 수신 측에서 다시 DB 조회가 필요하고, 전체 데이터를 담는 Fat Event는 바로 처리가 가능하지만 결합도가 높아집니다. 프론트엔드와 백엔드의 시각차와도 비슷한 딜레마인데, 결국 트레이드오프를 결정하는 것이 아키텍트의 역할이라는 결론에 도달했습니다.
현업 사례로는 해외 네트워크 환경이 좋지 않은 곳에서 이미지 업로드 시, 일단 사용자에게 OK 응답을 주고 실제 처리는 백그라운드 이벤트로 돌려 반응성을 극대화한 경험이 공유되었습니다.
Part 2. 공간 기반 아키텍처 (SBA)
두 번째 주제는 공간 기반 아키텍처였습니다. 핵심 전제는 "DB는 확장이 어렵다"는 것인데, 웹 서버는 스케일 아웃이 쉽지만 DB는 트래픽 폭주 시 병목이 됩니다. 이를 해결하기 위해 인메모리 데이터 그리드(IMDG)를 활용하여 메모리에서 먼저 처리하고 DB에는 나중에 기록하는 방식을 사용합니다.
캐싱 전략에서는 모든 노드가 같은 데이터를 갖는 복제 캐시와, 데이터를 여러 노드에 쪼개 저장하는 분산 캐시의 차이를 논의했습니다. 잘 바뀌지 않는 데이터에는 복제 캐시가, 실시간 재고처럼 변동이 큰 데이터에는 분산 캐시가 적합합니다.
가장 와닿았던 건 현업 경험담이었는데, 이사/청소 견적 서비스에서 선착순 트래픽 폭주 시 DB 락을 걸면 시스템이 멈추고 안 걸면 데이터가 꼬이는 상황, 그리고 월말 보험 청구가 밤 9시~11시에 몰리는 수강 신청 전쟁 같은 상황에서 인메모리 처리가 어떻게 활용되는지 생생한 이야기가 오갔습니다.
Part 3. 마이크로서비스 아키텍처 (MSA)
MSA의 핵심은 서비스를 얼마나 적절하게 나누느냐(Granularity)에 달려 있습니다. 너무 잘게 나누면 네트워크 비용이 증가하는 모래알 안티 패턴에 빠지고, 너무 크게 나누면 모놀리스와 다를 바 없게 됩니다. 핵심 원칙은 "트랜잭션 경계를 넘나들지 마라"입니다. 결제와 재고 차감처럼 한 몸처럼 움직여야 하는 기능은 굳이 나누지 않는 것이 정답일 수 있습니다.
마지막으로 ADR(Architecture Decision Records)에 대한 세션이 진행되었습니다. 아키텍처 결정을 어려워하는 이유는 "해본 적이 없어서" 혹은 "책임지기 싫어서"인 경우가 많고, 결정을 미룰수록 리스크와 비용은 기하급수적으로 증가합니다.
특히 인상적이었던 통찰은 ADR이 단순히 미래의 동료를 위한 것만이 아니라, AI 시대를 위한 준비이기도 하다는 점입니다. AI 코딩 에이전트가 도입될 때, 코드보다 "왜 이런 결정을 내렸는가"라는 맥락이 담긴 ADR 문서가 가장 중요한 학습 데이터가 될 것이라는 이야기가 깊은 공감을 얻었습니다.
이번 스터디를 통해 다시 한번 느낀 건 "모든 아키텍처에는 정답이 없고 트레이드오프만 존재한다"는 것입니다. 반응성이 중요하면 이벤트 기반, 트래픽 폭주가 예상되면 공간 기반, 조직이 감당할 수 있다면 마이크로서비스를 선택하되, 그 모든 결정의 맥락을 ADR로 남기는 것이 아키텍트의 핵심 책무라는 점을 확인하며 마무리했습니다. 감사합니다.