모놀리스와 MSA 차이, 기획서에 녹이는 법

📌 목차

1. 모놀리스 시스템이란
2. MSA란 무엇인가
3. 모놀리스 vs MSA, 표로 비교하기
4. 실무 팁 3가지
5. 마무리
6. FAQ

신규 서비스 기획 회의에서 개발팀이 "이건 처음부터 MSA로 가는 게 맞을까요, 아니면 모놀리식으로 시작할까요"라고 물어본 적이 있습니다. 저는 그때 두 단어의 뜻은 어렴풋이 알았지만, 기획서에 뭐라고 반영해야 할지는 감이 안 왔습니다.

결국 "개발팀 판단에 맡기겠습니다"로 넘어갔는데, 몇 달 뒤 기능 하나를 급하게 추가하려다 배포 범위가 예상보다 훨씬 커진 걸 보고서야 그 결정이 기획 초반부터 함께 고민해야 할 사안이었다는 걸 알았습니다.

이번 글에서는 모놀리스와 MSA가 각각 무엇인지, 두 구조가 실무에서 어떻게 다른지, 그리고 그 차이를 기획서에 어떻게 녹여야 하는지 정리해보겠습니다.

1. 모놀리스 시스템이란

모놀리스(Monolith)는 회원, 주문, 결제, 알림 같은 여러 기능이 하나의 코드베이스와 하나의 배포 단위로 묶여 있는 구조입니다. 기능마다 서버를 따로 두지 않고, 애플리케이션 전체를 한 덩어리로 빌드하고 배포합니다.

원룸을 떠올리면 이해가 쉽습니다. 침실, 주방, 거실이 벽으로 나뉘어 있지 않고 한 공간에 모여 있는 구조입니다. 공간을 나누는 절차가 없으니 처음 살림을 차릴 때는 빠르고 간편합니다.

초기 서비스에서 모놀리스를 선택하는 이유도 비슷합니다. 기능 간 호출이 함수 호출 수준으로 끝나기 때문에 개발 속도가 빠르고, 배포도 한 번에 처리되어 관리 포인트가 적습니다. 다만 서비스가 커질수록 기능 하나를 고치기 위해 전체를 다시 빌드하고 배포해야 하고, 특정 기능에서 발생한 장애가 전체 서비스로 번지기 쉽다는 부담이 따라옵니다.

2. MSA란 무엇인가

MSA(Microservice Architecture, 마이크로서비스 아키텍처)는 회원, 주문, 결제, 알림 같은 기능을 각각 독립된 서비스로 쪼개고, 서비스끼리는 API로 통신하게 만드는 구조입니다. 서비스마다 코드베이스와 배포 파이프라인이 따로 있어서, 하나를 고쳐도 다른 서비스는 그대로 둘 수 있습니다.

비유하자면 여러 전문점이 모인 상가와 비슷합니다. 정육점, 채소가게, 반찬가게가 각자 자기 가게를 운영하지만, 손님은 상가 하나를 오가며 필요한 걸 사갑니다. 가게 하나가 리모델링을 해도 옆 가게 영업에는 지장이 없습니다.

이 구조의 장점은 서비스별로 독립 배포가 가능하고, 한 서비스에서 장애가 나도 다른 서비스로 전파되는 범위를 줄일 수 있다는 점입니다. 트래픽이 몰리는 서비스만 따로 확장하는 것도 가능합니다. 반면 서비스 간 통신을 설계해야 하고, 운영해야 할 서버와 배포 파이프라인이 늘어나면서 관리 복잡도와 초기 구축 비용이 함께 올라갑니다.

3. 모놀리스 vs MSA, 표로 비교하기

두 구조의 차이를 실무 기준으로 정리하면 다음과 같습니다. 어느 쪽이 우월하다기보다, 서비스 상황에 따라 적합한 선택이 달라진다는 점이 핵심입니다.

구분	모놀리스	MSA
배포 단위	애플리케이션 전체 한 번에	서비스별로 독립 배포
장애 영향 범위	한 기능 장애가 전체로 번지기 쉬움	장애를 해당 서비스로 격리하기 쉬움
초기 개발 속도	빠름	서비스 간 통신 설계가 먼저 필요해 상대적으로 느림
확장 방식	전체 단위로 확장	트래픽이 많은 서비스만 선택적으로 확장
운영 복잡도	낮음	서비스 수만큼 높아짐
적합한 단계	초기 서비스, 소규모 조직	기능·트래픽이 커지고 팀이 서비스 단위로 나뉜 조직

이 글은 2026.09 기준으로 작성되었으며, 각 구조를 지원하는 클라우드·인프라 도구의 세부 기능은 계속 바뀌므로 최신 내용은 해당 서비스의 공식 문서를 확인하시기 바랍니다.

4. 실무 팁 3가지

팁1. 기획서엔 구조보다 '왜 이 구조인가'를 먼저 쓴다

아키텍처 항목에 "MSA로 진행"이라고만 적으면 나중에 아무도 그 이유를 기억하지 못합니다. 서비스 규모, 팀 구성, 확장 계획 중 무엇을 근거로 이 구조를 택했는지 한두 문장이라도 함께 남겨두세요. 이유가 남아있어야 팀이 바뀌거나 상황이 바뀌었을 때 재검토 여부를 판단할 수 있습니다.

팁2. 아키텍처 결정은 기획 초기에 개발팀과 함께 확인한다

아키텍처는 기획서를 다 쓴 뒤 개발팀에 넘기고 나서 정해지는 게 아니라, 기능 범위와 우선순위를 잡는 시점부터 함께 논의해야 하는 사안입니다. 초반에 이 구조를 왜 택했는지 확인해두면, 이후 기능 추가나 일정 협의 때 "왜 이 작업이 오래 걸리는지"를 서로 이해한 상태로 대화할 수 있습니다.

팁3. 향후 확장 시나리오를 기획서에 한 줄이라도 남긴다

지금은 모놀리스로 시작하더라도, 트래픽이 늘거나 팀이 커졌을 때 어느 기능부터 분리할 가능성이 있는지 한 줄이라도 적어두세요. 이 메모가 있으면 나중에 구조 전환을 논의할 때 처음부터 다시 분석하지 않고 기존 기획 맥락 위에서 이야기를 시작할 수 있습니다.

5. 마무리

오늘 내용 3줄 요약

• 모놀리스는 기능을 하나로 묶어 빠르게 시작하기 좋고, MSA는 기능을 나눠 독립적으로 운영하기 좋습니다.
• 어느 쪽이 정답이 아니라, 서비스 규모와 팀 구조에 따라 적합한 구조가 달라집니다.
• 기획서에는 구조 이름보다 그 구조를 택한 이유와 향후 확장 가능성을 남기는 것이 중요합니다.

지금 진행 중인 프로젝트의 기획서에 아키텍처 관련 항목이 비어있다면, 개발팀과 짧게라도 이야기 나눈 뒤 한 줄이라도 채워보세요. 여러분 팀은 아키텍처 결정을 기획서 어느 항목에 남기고 계신가요. 댓글로 공유해주시면 다음 글에서 다뤄보겠습니다.

6. FAQ

Q. 기획자가 MSA를 몰라도 되나요?

구현 세부 사항까지 알 필요는 없지만, 기능 하나를 고칠 때 왜 여러 서비스가 함께 영향을 받는지, 혹은 왜 영향이 없는지 정도는 이해하고 있어야 일정과 범위를 현실적으로 협의할 수 있습니다.

Q. 소규모 서비스도 처음부터 MSA로 시작해야 하나요?

팀 규모가 작고 기능도 아직 확정되지 않은 초기 단계라면, 서비스 간 통신을 설계하고 운영하는 부담이 먼저 발목을 잡을 수 있습니다. 많은 팀이 모놀리스로 먼저 시작해 필요한 기능부터 분리해나가는 방식을 택합니다.

Q. 기획서에 아키텍처 내용을 얼마나 자세히 써야 하나요?

구조를 설계하는 문서가 아니므로 기술적으로 상세히 쓸 필요는 없습니다. 선택한 구조, 그렇게 정한 이유, 향후 변경 가능성 정도를 한두 문단으로 남기는 것으로 충분합니다.