새로운 내용을 공부할 때
새로운 내용의 공부를 시작할 때 용어의 정의를 이해하지 못하거나 정확하게 알지 못한다면 그 용어가 포함된 문장을 이해하지 못합니다.
작은 단어 하나가 내용을 이해하지 못하게 하기 때문에 용어를 정확하게 이해하는 것이 중요합니다.

11 분 소요

1. HTTP 요청에서 Request Line이 포함하는 정보는 무엇이며, 각각 어떤 역할을 하나요?

점수 8 / 10 점

답변

HTTP 행동 메소드 ,URI 리소스 식별자 위치, HTTP 버전이 있습니다. 행동 메소드는 리소스 식별자에 어떤 요청을 하는지 확인할 수 있는 행동을 표시합니다. 식별자 위치는 해당 데이터의 위치는 계층적으로 표시하여 리소스의 추상적인 식별자 위치를 확인할 수 있습니다. 그리고 HTTP 버전을 통해서 어떤 방식으로 통신할 것인지 확인할 수 있습니다.

수정해야 하는 부분

  • “식별자 위치는 … 계층적으로 표시하여 리소스의 추상적인 식별자 위치를 확인할 수 있습니다.” → 좀 더 구체적으로 “URI가 리소스 경로(경로 파라미터 등)를 나타내며, 이를 통해 서버가 어떤 리소스(엔드포인트)에 접근해야 하는지 식별한다.” 정도로 보완 필요
  • “어떤 방식으로 통신할 것인지 확인할 수 있습니다.” → “HTTP/1.1, HTTP/2 등 버전에 따라 연결 방식이나 헤더 처리 방식이 달라질 수 있다는 점을 명시하면 좋습니다.”

10점짜리 답변 예시

Request Line은 Method, URI(경로), HTTP Version으로 구성됩니다.

  • Method: GET, POST, PUT, DELETE 등으로, 클라이언트가 해당 리소스에 대해 어떤 동작을 요구하는지 나타냅니다.
  • URI: 특정 리소스(엔드포인트)의 경로를 식별합니다. 예: /hello, /users/1
  • HTTP Version: HTTP/1.1, HTTP/2 등으로, 요청/응답 처리 방식과 프로토콜 기능을 결정합니다.

꼭 들어가야 할 키워드

  • Method(GET/POST/PUT/DELETE 등)
  • URI(경로)
  • HTTP Version(1.1, 2 등)

2. HTTP 응답에서 Status Line은 어떤 정보를 담고 있으며, 대표적인 Status Code 예시를 2~3개 들어 설명해보세요.

점수 7 / 10 점

답변

상태코드 , 상태 코드 메세지, 본문, 헤더가 있습니다 상태코드는 HTTP 응답에 정상처리인지 오류인지 확인할 수 있습니다 예) 404 코드는 해당 리소스 식별자 위치에서 찾을 수 없다는 의미입니다. 200 코드는 해당 요청이 정상 처리되었다는 것을 확인할 수 있습니다. 301 코드는 해당 요청은 접근 권한이 없다는 것을 의미합ㄴ디

수정해야 하는 부분

  • “상태 코드 메세지, 본문, 헤더가 있습니다” → Status Line은 HTTP Version, Status Code, Reason Phrase를 포함합니다. 본문(Body)나 헤더는 Status Line과는 별개 영역입니다.
  • “301 코드는 해당 요청은 접근 권한이 없다는 것을 의미” → 301은 “Moved Permanently(영구 리다이렉트)”입니다. 접근 권한이 없는 것은 403 Forbidden, 401 Unauthorized, 또는 302/307 등의 임시 리다이렉트와 구분 필요

10점짜리 답변 예시

Status Line은 HTTP Version, Status Code, Reason Phrase로 구성됩니다. 예: HTTP/1.1 200 OK

  • 200 OK: 요청이 정상 처리됨
  • 404 Not Found: 해당 리소스를 찾을 수 없음
  • 301 Moved Permanently: 리소스가 다른 위치로 영구 이동함 (클라이언트는 새 위치로 요청해야 함)

꼭 들어가야 할 키워드

  • Status Line(Version, Status Code, Reason Phrase)
  • 200(OK), 404(Not Found), 301(Moved Permanently) 등

3. Content-Type 헤더의 역할은 무엇이며, 웹 애플리케이션에서 왜 중요한가요?

점수 8 / 10 점

답변

HTTP 바디에 인코딩이 어떤 것인지 확인 시켜주는 방법입니다. 서로 다른 나라의 서버가 다른 인코딩 방식을 사용하면 해당 파일을 읽을 수 없다곡 ㅏ

수정해야 하는 부분

  • “서로 다른 나라의 서버가 다른 인코딩 방식을 사용하면…” → Content-Type에는 인코딩(charset)뿐 아니라 MIME 타입(ex: application/json, text/html) 자체도 포함됨. “데이터 형식(JSON, HTML 등)과 인코딩(UTF-8 등)을 지정함으로써 클라이언트가 올바르게 해석할 수 있도록 돕는다.”로 보완 필요
  • 오탈자 “없다곡 ㅏ” 수정

10점짜리 답변 예시

Content-Type 헤더는 HTTP 메시지 바디에 담긴 데이터의 MIME 타입과 문자 인코딩 정보를 나타냅니다. 예: Content-Type: application/json; charset=UTF-8
이를 통해 클라이언트나 서버가 전송된 데이터의 형식을 정확히 해석할 수 있어, 웹 애플리케이션에서 매우 중요합니다.

꼭 들어가야 할 키워드

  • Content-Type
  • MIME 타입(application/json, text/html 등)
  • Charset(UTF-8 등)

4. 내장 톰캣(Embedded Tomcat) 방식을 사용할 때, ‘서버 설치 없이 애플리케이션 코드에서 톰캣을 실행한다’는 것이 구체적으로 무엇을 의미하나요?

점수 8 / 10 점

답변

서버 설치 없이 자바 코드로 구현된 톰캣 구현 코드를 스프링 부트가 작성하여 스프링 컨테이너가 초기화 될때 톰캣을 생성하여 디스패처서블릿을 등록하는 것을 말합니다.

수정해야 하는 부분

  • “스프링 부트가 작성하여 … ” → “스프링 부트가 제공하는 라이브러리 내부에 톰캣이 포함되어, 개발자가 별도 설치 없이 main() 메소드 실행만으로 톰캣이 구동되는 것” 정도로 설명 보완

10점짜리 답변 예시

내장 톰캣은 스프링 부트 애플리케이션 내부에 톰캣 서버가 라이브러리 형태로 포함되어, 별도의 WAR 배포나 톰캣 설치 없이도 main() 메소드 실행만으로 웹 서버를 구동할 수 있다는 것을 의미합니다.

꼭 들어가야 할 키워드

  • 내장 톰캣(Embedded)
  • main() 메소드로 서버 구동
  • 별도 설치 필요 없음

5. TomcatServletWebServerFactory는 어떤 책임을 가지고 있으며, 이를 통해 얻을 수 있는 장점은 무엇인가요?

점수 8 / 10 점

답변

톰갯을 생성하는 책임을 가지고 있습니다. 내부에 어떤 방식을 사용하던 톰캣을 반환하면 되기에 사용자는 톰캣 팩토리에 요청만 하면 됩니다.

수정해야 하는 부분

  • “톰갯” 오탈자
  • 조금 더 부연: “서블릿 컨테이너 설정(포트, 컨텍스트 경로 등)도 팩토리를 통해 일괄 관리 가능하다는 점” 설명 추가

10점짜리 답변 예시

TomcatServletWebServerFactory는 톰캣 서버 객체를 생성하고, 포트나 컨텍스트 경로, 서블릿 초기화 등의 설정 작업을 한 번에 처리하는 팩토리(Factory) 역할을 합니다. 개발자는 이 팩토리를 통해 일관된 방식으로 웹 서버를 구성할 수 있어, 구현 세부사항에 의존하지 않고도 유연하게 톰캣을 다룰 수 있습니다.

꼭 들어가야 할 키워드

  • TomcatServletWebServerFactory
  • 팩토리 역할
  • 서블릿 컨테이너 설정(포트, 경로 등)

6. WebServer 인터페이스는 톰캣뿐 아니라 다른 서버 기술(예: Jetty, Undertow)도 추상화하기 위한 구조입니다. 이렇게 추상화하면 개발자가 얻을 수 있는 이점은 무엇일까요?

점수 9 / 10 점

답변

개발자가 어떤 라이브러리를 사용하더라도 톰캣에서 제티로 바꾸더라도 티가 안나게 변경이 가능합니다.

수정해야 하는 부분

  • 좀 더 구체적 예시: “의존성만 바꾸면 Tomcat → Jetty로 교체 가능”

10점짜리 답변 예시

WebServer 인터페이스로 추상화해두면, 의존성 교체만으로 Tomcat을 Jetty나 Undertow로 바꾸는 등 서버 구현체 교환이 쉬워집니다. 이는 프로젝트 환경이나 요구사항 변동에 맞춰 유연하게 대응할 수 있고, 코드 의존성도 최소화되는 장점이 있습니다.

꼭 들어가야 할 키워드

  • 추상화
  • 서버 구현체 교체 용이성
  • 유연성

7. ServletContextInitializer를 사용해 서블릿을 등록할 때, ‘URL 매핑’이란 무엇을 의미하며, 어떻게 설정할 수 있나요?

점수 7 / 10 점

답변

xml과 애노테이션을 사용하여 도메인을 제외한 URI와 일치하는 경우 해당 서블릿이 기능을 수행할 수 있는 것을 매핑이라고 합니다.

수정해야 하는 부분

  • “xml과 애노테이션을 사용하여” → Spring Boot나 Embedded Tomcat 환경에서는 servletContext.addServlet(...) 식으로 자바 코드에서 매핑 가능. XML은 전통적인 설정 파일 방식
  • 좀 더 예시: servletContext.addServlet("myServlet", new MyServlet()).addMapping("/hello");

10점짜리 답변 예시

URL 매핑이란, 특정 URL 패턴(예: /hello)과 서블릿을 연결해주는 설정을 말합니다. 예를 들어, servletContext.addServlet("myServlet", new MyServlet()).addMapping("/hello");를 통해 /hello로 들어온 요청을 MyServlet이 처리하도록 등록합니다.

꼭 들어가야 할 키워드

  • URL 매핑
  • servletContext.addServlet(…)
  • “/hello”와 서블릿 연결

8. HttpServlet 클래스를 상속받아 오버라이딩해야 하는 대표적인 메서드에는 무엇이 있고, 각각 어떤 목적을 갖나요?

점수 8 / 10 점

답변

service메소드가 있으며 get, post 메소드도 있습니다 get은 정보를 조회하고 post는 정보를 생성하는 목적으로 사용합니다.

수정해야 하는 부분

  • “service 메소드만 있다” → doGet(), doPost()가 대표적이며, service() 메소드는 이들을 분기하는 핵심 로직
  • PUT, DELETE 등도 언급 가능

10점짜리 답변 예시

  • service(): 모든 요청을 받아, 요청 메서드(GET, POST 등)에 따라 doGet/doPost 등을 호출하는 기본 분기 로직
  • doGet(): 클라이언트가 GET 방식으로 요청했을 때 로직 처리 (조회 목적)
  • doPost(): POST 요청 처리 (데이터 등록, 폼 전송 등)
  • 필요 시 doPut(), doDelete() 등도 오버라이딩 가능

꼭 들어가야 할 키워드

  • service(), doGet(), doPost()
  • HTTP 메서드 별 처리
  • 오버라이딩

9. 프론트 컨트롤러(Front Controller) 패턴이란 무엇이며, 이를 통해 얻을 수 있는 이점은 무엇인가요?

점수 7 / 10 점

답변

프론트 컨트롤러 패턴은 모든 웹 기능을 서블릿으로 등록하는 것은 유지보수와 확장성이 떨어지게 기때문입니다.

수정해야 하는 부분

  • “…유지보수와 확장성이 떨어지게 기때문입니다.” → 실제 설명이 빠져 있음. “모든 요청을 단일 진입점(Front Controller)에서 먼저 처리함으로써 공통 로직을 재사용, 관리하기 쉽게 한다”로 보완

10점짜리 답변 예시

프론트 컨트롤러(Front Controller) 패턴은 모든 HTTP 요청을 단일 진입점(서블릿 등)으로 받게 하고, 공통 로직(인증, 로깅 등)을 처리한 뒤에 적절한 핸들러(컨트롤러)로 분기해주는 구조입니다. 이를 통해 중복 코드를 줄이고, 변경 사항이 생겼을 때 중앙 집중식으로 관리할 수 있으므로 유지보수성과 확장성이 좋아집니다.

꼭 들어가야 할 키워드

  • 단일 진입점
  • 공통 로직 처리
  • 유지보수성 / 확장성

10. DispatcherServlet이 스프링 MVC에서 프론트 컨트롤러로 작동할 때, 어떤 과정을 거쳐 컨트롤러(핸들러) 메서드로 요청을 전달하나요?

점수 9 / 10 점

답변

웹 요청의 URI를 보고 일치하거나 담당할 수 있는 컨트롤러를 조회합니다. 그리고 컨트롤러에 필요한 파라미터와 요청하는 데이터를 파싱해서 일치하는지 확인하고 전달합니다

수정해야 하는 부분

  • 추상적이라 조금만 보완. “HandlerMapping → HandlerAdapter → 컨트롤러 호출”의 흐름

10점짜리 답변 예시

  1. DispatcherServlet이 요청을 받음
  2. HandlerMapping을 통해 URI/메서드와 매핑된 컨트롤러(핸들러)를 찾음
  3. HandlerAdapter를 사용해 컨트롤러 메서드를 호출할 수 있는 형태로 변환
  4. 컨트롤러가 비즈니스 로직 수행 후 결과(모델, 뷰 정보 등)를 반환
  5. DispatcherServlet이 뷰 렌더링 또는 JSON 변환 등을 처리해 최종 응답 완성

꼭 들어가야 할 키워드

  • HandlerMapping
  • HandlerAdapter
  • 컨트롤러 메서드 호출

11. 서블릿 기반의 프론트 컨트롤러 패턴에서, ‘공통 처리 로직’을 한곳에 모아두면 어떤 장점이 있을까요?

점수 9 / 10 점

답변

공통 처리 로직을 모아서 처리하는 경우에 모든 핸들러에게 공통적으로 적용되므로 수정사항이 생기더라도 변경해야하는 부분이 작아져 유지보수와 확장하기 유용합니다.

수정해야 하는 부분

  • 표현을 조금 더 다듬으면 좋음. (대체로 괜찮음)

10점짜리 답변 예시

공통 처리(인증, 로깅, 예외 처리 등)를 중앙 집중화하면, 변경 사항이 생겼을 때 프론트 컨트롤러만 수정하면 되어 각각의 컨트롤러를 일일이 수정할 필요가 없습니다. 이는 중복 코드를 제거하고, 유지보수성과 확장성을 크게 높여줍니다.

꼭 들어가야 할 키워드

  • 공통 처리 로직
  • 중앙 집중화
  • 중복 제거

12. 코드 예시에 나온 requestURI.equals("/hello") && "GET".equals(method)와 같은 분기 로직이 많아지면 유지보수가 어렵습니다. 이를 개선하기 위한 대표적인 방법은 무엇인지 간단히 설명해보세요.

점수 7 / 10 점

답변

서블릿 구현 메서드 중에 세부 사항 메서드로 내부에서 getService와 같이 메소드로 HTTP 메서드를 구분할 필요가 없습니다.

수정해야 하는 부분

  • 답이 조금 모호함. 스프링 MVC처럼 매핑(애노테이션)을 사용하거나, HandlerMapping 구조로 분리하는 방식 등이 대표적

10점짜리 답변 예시

요청 URL과 메서드에 대한 분기를 맵 구조나 스프링의 @GetMapping(“/hello”) 같은 애노테이션 매핑을 활용해 자동화하면, if-else 분기문을 최소화할 수 있습니다. 예를 들어, “URL → 핸들러 메서드”를 매핑 테이블로 관리하면, 새로운 URL이 추가되어도 매핑 정보만 등록하면 되므로 유지보수가 용이합니다.

꼭 들어가야 할 키워드

  • 매핑 구조 (애노테이션, Map 등)
  • if-else 분기 최소화
  • 유지보수성

13. 컨트롤러(핸들러) 분리란 무엇이고, 이렇게 분리함으로써 얻을 수 있는 이점은 무엇인가요?

점수 9 / 10 점

답변

핸들러 분리는 웹 기능을 별도의 오브젝트로 분리하는 것을 말합니다. 오브젝트로 분리하게 되면 컨트롤러 끼리 코드 변경시에도 영향이 적어지며 필요한 의존성만 사용하면 되기에 유지보수나 확장에도 편리합니다. 그리고 객체지향적으로 웹 기능이라는 역할에만 수행하면 되므로 확장에도 유리해집니다.

수정해야 하는 부분

  • (없음) → 이미 잘 설명하셨습니다.

10점짜리 답변 예시

컨트롤러 분리는 각 요청 경로별로 전담하는 클래스를 나누어, 코드 응집도를 높이고 기능별로 독립시켜 관리하는 방식입니다. 이를 통해 컨트롤러 간 의존성이 줄어들고, 변경 범위가 축소되어 유지보수가 쉬워지며, 개발 팀 간 분업도 용이해집니다.

꼭 들어가야 할 키워드

  • 핸들러(Controller) 분리
  • 응집도 상승
  • 변경 범위 축소

14. 스프링 부트가 제공하는 “컨테이너리스(Container-less)” 방식은 전통적인 WAR 파일 배포와 어떤 점에서 차별화되나요?

점수 8 / 10 점

답변

기존 과 동일 어떤 환경에서 jvm만 설치되어있다면 실행환경에 대한 설정이 코드에 있기에 서버의 수를 늘리거나 줄일때도 웹 서버에 대한 설정을 하지 않고 동일하게 유지할 수 있습니다.

수정해야 하는 부분

  • “기존 과 동일” → 문맥상 불필요
  • WAR 파일 배포 시, 외부 톰캣 설치 필요. 컨테이너리스는 JAR에 톰캣 포함

10점짜리 답변 예시

컨테이너리스 방식은 애플리케이션이 내장 톰캣을 포함해 단일 JAR 형태로 배포됩니다. 반면 전통적인 WAR 배포는 외부 서버(Tomcat 등)에 WAR 파일을 올려야 하므로 서버 설치 및 설정이 별도로 필요합니다. 컨테이너리스 방식은 서버 설정을 코드 내부에서 일원화할 수 있고, 어떤 환경이든 JVM만 있으면 동일하게 실행 가능하다는 이점이 있습니다.

꼭 들어가야 할 키워드

  • Container-less
  • 내장 톰캣
  • 단일 JAR 배포 vs. WAR 배포

15. HTTP 메서드(GET, POST, PUT, DELETE 등)는 리소스에 대한 어떤 개념을 표현하기 위한 것인가요? (힌트: CRUD)

점수 9 / 10 점

답변

get은 리소스 조회, post는 리소스 생성, put은 리소스 전체 필드 변경, delete는 리소스 삭제를 의미합니다.

수정해야 하는 부분

  • 설명 잘하셨습니다. PUT의 경우 부분 업데이트일 땐 PATCH를 사용하기도 함

10점짜리 답변 예시

HTTP 메서드는 리소스에 대한 CRUD 동작을 표준화한 개념입니다.

  • GET: 리소스 조회
  • POST: 새 리소스 생성 (혹은 처리)
  • PUT: 리소스를 업데이트(전체 치환)
  • DELETE: 리소스 삭제

꼭 들어가야 할 키워드

  • CRUD(Create, Read, Update, Delete)
  • HTTP 메서드

16. HttpStatus와 HttpHeaders처럼, HTTP 스펙을 자바 코드로 추상화해둔 클래스 또는 상수들을 활용하면 어떤 이점이 있을까요?

점수 8 / 10 점**

답변

소스 코드 변경없이 http스펙을 구현한 클래스를 사용할 수 있습니다.

수정해야 하는 부분

  • 조금만 보완: “직접 상수나 숫자 코드를 다루지 않아도 되어 가독성과 유지보수성이 높아진다.”

10점짜리 답변 예시

이런 추상화 클래스(상수)를 사용하면, 숫자 상태코드(200, 404 등)를 직접 다루지 않아도 되고, 오타나 상수 충돌을 줄일 수 있어 가독성과 유지보수성이 높아집니다. 또한 IDE 자동완성이나 Javadoc을 통해 HTTP 스펙을 쉽게 파악할 수 있습니다.

꼭 들어가야 할 키워드

  • HttpStatus, HttpHeaders
  • 추상화, 상수
  • 가독성, 유지보수성

17. 핸들러(Controller) 메서드가 수행해야 하는 ‘비즈니스 로직’과 ‘웹 요청/응답 처리 로직’을 분리하면 어떤 면에서 코드 가독성과 유지보수성이 향상되나요?

점수 9 / 10 점

답변

두 로직은 변경 시기와 주기등이 다릅니다. 따라서 분리되지 않았다면 하나의 로직을 수정할 때 관련 없는 코드로 영향을 받았는지 확인하기 위해 추가 테스트가 필요합니다. 로직을 분리한 경우에는 서로 영향이 없기에 수정이나 추가에도 영향이 적습니다.

수정해야 하는 부분

  • 아주 잘 작성됨. 간단히 표현만 조금 다듬으면 됨

10점짜리 답변 예시

웹 요청/응답 처리는 컨트롤러 레벨에서 담당하고, 비즈니스 로직은 별도 서비스 레벨에서 담당하면, 각각의 수정이 상호 영향을 덜 미치게 됩니다. 이는 관심사 분리(SoC) 원칙에 부합하며, 가독성과 테스트 용이성을 높여줍니다.

꼭 들어가야 할 키워드

  • 관심사 분리(SoC)
  • 테스트 용이성
  • 유지보수성

18. 스프링 MVC(@Controller, @GetMapping 등)는 어떻게 서블릿 + 프론트 컨트롤러 패턴을 추상화하여 제공하나요? 큰 흐름을 간단히 설명해보세요.

점수 8 / 10 점

답변

해당 메서드가 붙어있으면 스프링 컨테이너 컨트롤러 핸들러에 오브젝트로 등록합니다. 그래서 디스패처 서블릿이 웹 요청을 받아 url을 가지고 컨트롤러 핸들러에서 일치하는 핸들러를 조회합니다. 조회하여 일치하는 경우가 있을경우 웹 요청 객체의 파라미터를 컨트롤러 양식에 맞게 바인딩을 하고 실행합니다. 그 뒤 결과를 핸들러에게 받아서 반환 타입과 애노테이션을 확이낳여 웹 서비스로 넘어갈지 json으로 반환할지 결정합니다.

수정해야 하는 부분

  • “확이낳여” 오탈자
  • 전반적으로 매우 잘 설명. doGet/doPost를 대신해 @GetMapping, @PostMapping 등 쓰는 구조로 보완 가능

10점짜리 답변 예시

  1. @Controller(혹은 @RestController)와 @GetMapping("/hello") 등의 애노테이션을 사용해 핸들러 메서드를 선언
  2. DispatcherServlet(프론트 컨트롤러)이 요청을 수신하여, 내부적으로 HandlerMapping을 통해 해당 메서드를 찾음
  3. HandlerAdapter가 파라미터 바인딩 등의 로직을 자동 처리하고, 메서드를 호출
  4. 결과(모델, 뷰 등)를 DispatcherServlet에 반환해, 뷰 렌더링 혹은 JSON 변환
    • 이 모든 과정을 서블릿과 프론트 컨트롤러 패턴이 추상화되어 제공하기 때문에, 개발자는 핸들러 메서드 작성에만 집중할 수 있음

꼭 들어가야 할 키워드

  • @Controller, @GetMapping
  • DispatcherServlet, HandlerMapping, HandlerAdapter
  • 추상화

19. Binding(매개변수 바인딩)이란 무엇이며, “웹 파라미터를 자바 변수로 변환”하는 과정을 직접 구현하면 어떠한 점들을 고려해야 할까요?

점수 9 / 10 점

답변

쿼리스트링인지, 바디에 어떤 컨텐트타입으로 작성되어있는지 확인하여 컨텐트 타입에 맞는 포멧으로 데이터를 분리하여 오브젝트를 생성하거나 바인딩을 합니다.

수정해야 하는 부분

  • 매우 잘 설명. 조금 더 “숫자 변환, 날짜 변환, 예외 처리” 등에 대한 예시를 덧붙이면 좋음

10점짜리 답변 예시

Binding은 URL 쿼리 파라미터나 폼 데이터, JSON 바디 등을 자바 객체(예: DTO, VO)로 변환하는 과정입니다. 직접 구현한다면,

  • Content-Type(JSON, XML, multipart 등)
  • 데이터 형 변환(문자열 → 숫자/날짜)
  • 예외 처리(형 변환 실패 시)
    등을 고려해야 하며, 스프링은 이러한 로직을 MessageConverter와 DataBinder 등으로 자동 처리합니다.

꼭 들어가야 할 키워드

  • Binding(매개변수 바인딩)
  • Content-Type
  • 데이터 형 변환

20. 이번 내용에서 “서블릿, 톰캣, HTTP 프로토콜 기본기”가 스프링 MVC 디버깅이나 확장에 왜 중요한 배경 지식이 되는지, 구체적인 예시와 함께 설명해보세요.

점수 9 / 10 점

답변

서블릿과 http프로토콜의 동작 방식을 이해해야 디스패처 서블릿이 어떤 역할을 하고 우리가 등록한 웹 서비스 서블릿을 활용하는지 알 수 있습니다.

수정해야 하는 부분

  • 부연 예시: “에러 발생 시 서블릿 단계에서의 문제인지, 스프링 MVC 핸들러 로직 문제인지 파악할 수 있다.” 등

10점짜리 답변 예시

스프링 MVC 내부는 결국 서블릿(DispatcherServlet)을 기반으로 동작하고, HTTP 요청/응답 규칙(메서드, 헤더, 바디)을 철저히 준수합니다. 따라서

  • 에러 로그나 디버깅 시, 서블릿 레벨 문제인지 스프링 레벨 문제인지 구분 가능
  • 톰캣의 포트나 스레드 설정을 커스텀해야 할 때, 서버 구조를 알고 있으면 쉽게 처리 가능
  • RESTful 설계를 제대로 하려면 HTTP 메서드, 상태코드 이해가 필수
    이런 이유로 서블릿/톰캣/HTTP를 이해하면 스프링 MVC를 디버깅, 확장할 때 훨씬 유리합니다.

꼭 들어가야 할 키워드

  • 서블릿(DispatcherServlet)
  • HTTP 요청/응답 규칙
  • 톰캣 서버 구조
  • 디버깅/확장성

태그:

카테고리:

업데이트:

댓글남기기

참고

TIL) 해시와 탐색에 대해서

2 분 소요

데이터베이스 해시 파일과 해시 인덱스를 공부하는 도중 이 내용은 정리하면 좋을 거같아서 TIL을 작성하려고 해요