planning ·
기획자를 위한 웹/앱 구조 ⑤ "서버"라는 말의 네 가지 층위, 그리고 모놀리식과 MSA
회의에서 가장 혼란을 만드는 단어가 “서버”다. 같은 단어가 네 가지 다른 것을 가리키며 동시에 쓰인다.
| 층위 | 실체 | 현장에서 이렇게 들린다 |
|---|---|---|
| ① 물리 서버 | 데이터센터에 실제로 있는 컴퓨터(하드웨어) | “IDC에 서버 한 대 더 들어가요” — 요즘은 직접 만질 일이 드묾 |
| ② 가상 서버 (VM·인스턴스) | 물리 서버를 쪼개 빌려 쓰는 단위. AWS EC2 등 클라우드에서 “서버 한 대”의 기본 단위 | ”인스턴스 하나 더 띄울게요” = 서버(②)를 한 대 늘림 — 스케일 아웃 |
| ③ 컨테이너 (Docker) | 한 서버 안에서 프로그램별로 나눈 칸막이 포장. 옮기기 쉬워 배포의 표준이 됨 | ”컨테이너 재시작했어요” = 특정 프로그램 하나만 껐다 켬 |
| ④ 프로세스 | 실행 중인 프로그램 그 자체 — 웹서버·WAS·DB | ”WAS 죽었어요” = ④ 층위. 서버(②)는 멀쩡하고 프로그램만 죽은 것 |
“서버 죽었어요”를 들으면 어느 층위인지 물어보자. 대부분의 일상 장애는 ③·④ 층위이고 재시작으로 복구된다.
사람을 가리키는 “서버 (개발자)“까지 치면 다섯 번째 용법이다. “서버에서 처리할게요”는 대부분 “백엔드 코드에서 처리하겠다(④)“는 뜻이지, 컴퓨터를 새로 사겠다는 뜻이 아니다.
백엔드를 몇 덩어리로 만들 것인가 — 모놀리식과 MSA
같은 백엔드라도 한 덩어리로 만들 수도, 여러 조각으로 나눌 수도 있다.
| 모놀리식(monolithic) | MSA(마이크로서비스) | |
|---|---|---|
| 구조 | 백엔드 전체가 하나의 프로그램(WAS 하나) | 기능별로 독립된 작은 서비스 여러 개(주문·회원·결제 서비스…) |
| 배포 | 작은 수정도 전체를 다시 배포 | 바뀐 서비스만 따로 배포 |
| 장애 | 한 곳 문제가 전체 중단으로 번질 수 있음 | 주문 서비스가 죽어도 로그인은 됨 — 부분 장애 |
| 비용 | 단순하고 초기 개발이 빠름 — 소규모 팀 표준 | 운영 복잡도·인력이 큼 — 서비스 간 통신·모니터링 부담 |
정답이 있는 선택이 아니라 규모에 따른 트레이드오프다. 대부분의 서비스는 모놀리식으로 시작한다.
기획자 감각: “MSA로 전환하자”는 말은 수개월짜리 아키텍처 공사 제안이다. 반대로 MSA 조직에서는 기능 하나가 여러 서비스에 걸치면 팀 간 조율이 일정의 변수가 된다 — “이 기능, 몇 개 서비스에 걸치나요?”가 좋은 질문.
시리즈 전체 보기: ① 요청과 응답 · ② 정적/동적 웹 · ③ 다섯 명의 등장인물 · ④ 라이브러리와 프레임워크 · ⑤ 서버의 층위와 MSA · ⑥ 주소와 환경 · ⑦ 상태코드와 통역표 · ⑧ UML과 용어사전