안녕하세요!

K-DEVCON (이하 “데브콘”) 그로스 매니저 박종훈입니다.

어느새 곧 3월이 시작되려고 합니다.

저희 시스템 디자인 스터디는 약 한달간의 휴식 기간을 가지고 지난 2월 26일 다시 스터디를 시작하였습니다.

지난 기수에서의 스터디 인원들이 그대로 전원 참여하시겠다고 의사를 보여주셔서

이번 기수는 지난 기수의 분들로 진행하기로 결정하였습니다.

이번 1회차 스터디에서는 “호텔 예약 시스템” 의 디자인에 대해서 함께 이야기를 나눠보았습니다.

『가상 면접 사례로 배우는 대규모 시스템 설계 기초』에서는 항상 시스템 설계를 시작하기 전에, 어느 정도 규모를 가정할 것인지부터 명확히 설정합니다. 이 과정이 이후의 아키텍처와 기술 선택에 직접적인 영향을 미치기 때문입니다.

같은 스터디 운영자인 시온님은 특히 이 “가정의 현실성”을 꼼꼼하게 검토하시는 분입니다.

이번 챕터에서는 5천 개 호텔, 100만 개 객실을 기준으로 설계를 진행했는데, 이 수치가 과연 현실적인지에 대한 이야기가 자연스럽게 나왔습니다.

이에 대해 시온님이 직접 자료를 찾아보셨고, 실제로 책에서 예시로 든 메리어트의 경우 약 1만 개 호텔, 150만 개 이상의 객실을 보유하고 있다는 정보를 공유해주셨습니다. 책에서 제시한 5천 개 호텔, 100만 개 객실이라는 가정이 생각보다 비현실적인 수치는 아니라는 점을 확인해주신 셈이었습니다.

이와 관련해 제가 “항상 책에서 제시한 요구사항이 정말 현실적인지 먼저 점검하시는 것 같아요”라고 말씀드리자, 시온님은 이렇게 답해주셨습니다.

결국 우리가 풀어야 하는 문제는 ‘현실에서 발생할 수 있는 문제’이기 때문에, 실제로 일어나기 어려운 상황까지 지나치게 확장해서 고민할 필요는 없다고 생각해요.

기술적으로는 한계를 두지 않고 계속 확장해볼 수 있겠지만, 면접 상황에서는 특히 더 현실적인 범위 안에서 사고하는 것이 중요하다고 봅니다.

무엇보다 시스템 규모에 따라 적용해야 할 솔루션이 달라지기 때문에, 그 전제 자체를 꼼꼼히 확인하는 편입니다.

이 대화를 통해, 시스템 설계에서 중요한 것은 어떤 전제를 두고 문제를 정의하느냐라는 점을 다시 한 번 느끼게 되었습니다. 규모에 따라 아키텍처도, 데이터 저장 방식도, 캐시 전략도 모두 달라질 수 있기 때문입니다.

이번 시간에 논의할 호텔 예약 시스템의 경우, 다들 한 번 정도는 경험해 봤을 시스템 입니다.

책에서는 아래와 같이 하이레벨 디자인을 제시하였습니다.

책에서 제시한 기본적인 설계에 대해 다들 다른 의견은 없었기 때문에, 이번 시간에는 그 안에서 실제로 어떤 부분들을 더 고민해야 할지에 대해서 이야기를 나누어 보았습니다. 

이번 챕터에서는 마이크로 서비스를 통해서 디자인을 하는 모습을 보여주었고, 우리는 그에따라 마이크로 서비스를 설계할 때 어떤 부분들을 주의 해야하는지에 대해서 이야기를 나눠보았습니다.

많은 최신 서비스에서 마이크로 서비스로 설계를 시도하지만, 그에 따른 비용과 복잡성은 상당합니다.

과연 정말로 MSA 가 필요할까요? 사실 대부분의 시스템은 모놀리식으로도 충분할 수 있습니다.

서버 스펙을 더 이상 올릴 수 없거나, 조직 규모가 너무 커져 도메인을 강제로 찢어야 하는 상황오게 된다면 그 때가 MSA 도입을 위한 적절한 시점이 아닐까 생각해보았습니다.

하지만 반대의견을 내주신 분도 있으셨는데, 서비스의 규모가 커질대로 커진 후에 마이크로 서비스로의 분리를 시도하고 있지만, 이미 얽힐대로 얽혀있어서 분리에 매번 실패하고 있다는 사례를 공유해주신 스터디원 분도 있었습니다.

따라서 초기에는 모놀리식으로 시작하되, 도메인 간의 경계를 명확히 나누는 '모듈화'에 신경 쓰는 것이 현실적인 대안이 될 수 있습니다. 도메인이 명확하게 나눠져 있지 않은 상태로 MSA 를 시도한다면, 오히려 이는 더 큰 비용을 발생시킬 수도 있습니다.

결론적으로 MSA는 목적이 아닌 수단입니다. 기술적 유행보다는 우리 조직의 운영 능력과 서비스의 복잡도를 객관적으로 측정하여 결정해야 합니다.

MSA 에서는 각 서비스가 독립된 데이터베이스를 가지게 됩니다. 이로 인해 기존의 단일 서비스(데이터베이스)에서 사용하던 방식대로 원자성을 보장받기 어려워집니다.

여러 서비스를 거치는 비즈니스 로직 중 단 한 곳에서만 오류가 발생해도 데이터 불일치라는 치명적인 문제가 생길 수 있기 때문입니다.

이때 SAGA 패턴은 각 단계의 성공 여부에 따라 적절한 보상 트랜잭션을 실행하여, 시스템 전반의 일관성을 안정적으로 유지해주는 역할을 합니다.

"일반적인 업무에 Saga 패턴까지 도입하는 건 과하지 않을까?"라는 의문이 들 수도 있습니다. 하지만 고객의 자산이 오가는 금융 서비스라면 이야기가 달라집니다. 단 1원의 오차도 허용되지 않는 상황에서 보상 처리가 얼마나 중요한지, 실제 사례를 통해 그 절실함을 공감해 보는 시간을 가졌습니다.

한 스터디 회원분 께서는 오케스트레이션 방식을 사용한 토스뱅크의 사례 영상도 공유해주셨습니다. 

영상에서도 소개 된 것 처럼 SAGA 패턴은 크게 2가지 방식으로 나눠지게 됩니다.

코레오그래피(Choreography): 각 서비스가 이벤트를 발행하고 구독하며 알아서 보정 처리를 수행합니다.

오케스트레이션(Orchestration): 중앙 서버(코디네이터)가 전체 흐름을 제어하며 실패 시 각 서비스에 취소 이벤트를 전달합니다.

어떤 방식이 절대적으로 우월한 것은 아닙니다. 시스템의 복잡도와 팀의 운영 역량에 맞춰 적합한 방식을 선택하거나 적절히 혼합하여 사용하는 전략이 무엇보다 중요합니다.

저희는 스터디에서 실제 적용해본 사례들도 함께 이야기를 나눠보았습니다.

책에서는 아래와 같은 이미지를 보여줍니다.

물론 실제 서비스가 위와 완전히 동일한 형태로 구성되지는 않았을 것입니다. 책에서는 이해를 돕기 위해 추상화된 구조를 보여준 것이라 생각합니다. 그래서 “실제 환경에서는 어떻게 구성될까?”라는 질문을 중심으로 이야기를 나누어 보았습니다.

한 회원은 MongoDB 를 통해 샤딩을 한 사례를 공유해주었는데요. 샤드 키를 적절하게 잡지 못해 자동 리밸런싱이 발생되었고, 이로 인해 에러가 발생했던 사례를 공유해주시기도 하였습니다. “자동” 이긴 하지만, 리밸런싱 중에는 에러가 발생될 수 있습니다. 이러한 문제를 클라우드 서비스 제공업체에 문의를 해보았지만, 어플리케이션 레벨에서 재시도 로직을 구현하라는 원론적인 답변만 돌아와 아쉬움이 있었다고 합니다. 결과적으로 봤을 때 샤드의 개수를 너무 크게 잡았던 것 같다 라고도 코멘트를 주셨어서 실제 얼마나 데이터가 들어올지 현실적으로 예상을 해보는 것이 중요할 것 같다고 생각되었습니다.

16개의 DB와 커넥션을 맺고 있는건 리소스 측면에서 부담이 되지 않을까 하는 의견도 있었습니다.

어플리케이션 차원에서 먼저 분할을 해보는건 어떨까 하는 의견도 있었습니다.

어플리케이션 그룹 1에서는 1-4번 DB 와 연결, 어플리케이션 그룹 2에서는 5-8번 DB 와 연결 하는 식으로요. Proxy 도 좋은 옵션이 되지 않았을까도 생각이 듭니다.

결국 샤딩도 MSA와 마찬가지로, 실제 데이터 규모를 현실적으로 예측한 뒤에 도입 여부를 판단하는 것이 중요할 것 같습니다.

스터디에서 더 많은 이야기들을 함께 나눠보았지만, 리뷰글은 여기서 마무리 해보겠습니다.

이번 스터디에서는 오버엔지니어링과 관련된 이야기를 많이 나눠본 것 같습니다. 항상 상황에 따라 적절한 기술을 선택하는 것이 중요한 것 같습니다.

우리 스터디에서는 실제 사례들을 통해 문제를 어떻게 해결해 나갔을까 많은 고민을 해보고 이야기를 나눠보고 있습니다. 이번주도 다들 열심히 참여해주셔서 더 풍성한 스터디가 될 수 있었습니다.

✅ 직접 스터디를 개설해보고 싶은 분이 계시다면, K-DEVCON에서 운영을  도와드리겠습니다. 데브콘의 '랩짱'에 도전하여 커뮤니티 성장을 함께 이끌어주세요! 슬랙을 통해 운영진에게 DM 부탁드리겠습니다😉