어제 오늘 내일

[Spring Boot 입문 - 4] 스프링 부트 동작 원리: 요청(Request)이 들어오면 벌어지는 일 본문

IT/SpringBoot

[Spring Boot 입문 - 4] 스프링 부트 동작 원리: 요청(Request)이 들어오면 벌어지는 일

hi.anna 2026. 2. 11. 00:36

지난 시간, 우리는 브라우저 주소창에 http://localhost:8080을 입력했고,

서버는 Whitelabel Error Page를 보여줬습니다.

우리는 그저 엔터 키 한 번 쳤을 뿐인데, 스프링 부트 내부에서는 엄청나게 바쁜 일들이 일어났습니다.

이 과정을 아주 유명한 비유인 '레스토랑'에 빗대어 설명해 드릴게요.

 

1. 스프링 부트 맛집 (Layered Architecture)

웹 애플리케이션의 구조는 흔히 3계층(Layer) 구조라고 부릅니다. 이걸 레스토랑으로 바꿔보면 이해가 빠릅니다.

  • 손님 (Client): 배고픈 사용자 (브라우저)
  • 웨이터 (Controller): 주문을 받고 서빙하는 역할
  • 요리사 (Service): 주문받은 요리를 실제로 만드는 역할
  • 창고지기 (Repository): 요리 재료를 꺼내오는 역할
  • 냉장고 (Database): 재료가 보관된 곳

 

2. 주문이 들어왔을 때의 흐름

여러분이 브라우저(손님)에서 "메인 화면 보여줘!"라고 요청했을 때, 서버 내부에서는 이런 '이어달리기'가 벌어집니다.

1단계: 주문 접수 (Controller)

손님이 웨이터를 부릅니다.

손님(Browser): "여기 파스타 하나 주세요!" (Request)
웨이터(Controller): "네, 알겠습니다."

  • 설명: 웹 브라우저의 요청(URL)을 가장 먼저 받는 곳이 Controller입니다. "이 URL은 내가 처리할게!" 하고 손를 드는 녀석이죠.

2단계: 요리 시작 (Service)

웨이터가 주방에 주문서를 넘깁니다.

웨이터(Controller): "셰프님, 파스타 주문 들어왔어요."
요리사(Service): "OK. 레시피대로 만들어보자. (지지고 볶고...)"

  • 설명: Service는 실제 핵심 업무(비즈니스 로직)를 처리합니다. 로그인을 처리하거나, 쇼핑몰 결제 금액을 계산하는 등 진짜 '일'을 하는 곳입니다.

3단계: 재료 가져오기 (Repository)

요리하다 보니 면이랑 소스가 필요하네요.

요리사(Service): "창고지기야, 파스타 면이랑 소스 좀 줘."
창고지기(Repository): "네, 냉장고에서 꺼내 드릴게요."

  • 설명: Repository는 데이터베이스(DB)와 대화하는 유일한 친구입니다. DB에서 데이터를 조회(SELECT)하거나 저장(INSERT)하는 역할을 담당합니다.

4단계: 서빙 (Response)

재료로 요리가 완성되었습니다. 이제 역순으로 나갑니다.

창고지기 → 요리사 → 웨이터 → 손님
웨이터(Controller): "주문하신 파스타 나왔습니다." (Response)

  • 설명: 처리가 끝난 데이터(결과물)는 다시 컨트롤러를 통해 브라우저에게 전달됩니다. 이때 HTML 파일이 전송되기도 하고, JSON 데이터가 전송되기도 합니다.

 

3. 그림으로 보는 구조 (Mermaid)

이 흐름을 한 장의 지도로 그리면 아래와 같습니다. (이 그림은 머릿속에 캡처해 두세요!)

 

4. 왜 이렇게 귀찮게 나눌까?

*"그냥 웨이터가 냉장고 가서 재료 꺼내고 요리까지 다 하면 안 되나요?"*

물론 됩니다. (실제로 아주 작은 프로그램은 그렇게 짜기도 합니다.) 하지만 식당이 커지면 어떻게 될까요?
웨이터 혼자 주문받고, 요리하고, 설거지까지 하면 가게는 100% 망합니다.

스프링 부트도 마찬가지입니다.

  1. 역할 분담: 각자 맡은 일만 전문적으로 합니다. (코드가 깔끔해짐)
  2. 유지 보수: 요리 레시피를 바꿔야 하면 '요리사(Service)'만 교육하면 됩니다. 웨이터는 몰라도 되죠. (수정이 쉬워짐)

이 구조가 바로 개발자들이 말하는 "관심사의 분리(Separation of Concerns)"입니다.

 

마무리

지난 시간에 본 에러 페이지는 왜 떴을까요?

  1. 손님(브라우저)이 요청을 보냈습니다.
  2. 그런데 가게에 웨이터(Controller)가 한 명도 없었습니다. (우리가 아직 코드를 안 짰으니까요!)
  3. 스프링 부트가 "어? 주문받을 사람이 없네?" 하고 에러 페이지를 띄운 것입니다.

이제 원인을 알았으니 해결할 차례입니다.
다음 시간에는 우리 가게의 첫 번째 직원, Controller(웨이터)를 직접 채용(코딩)해서 브라우저에 "Hello World"를 띄워보겠습니다.

다음 편에서 만나요! 👋

 

 

반응형
Comments