컨테이너리스와 스프링부트의 철학 질문

컨테이너리스 & 스프링 부트 문항별 평가 및 수정 안내

1. 컨테이너리스(Containerless)란 무엇이며, 이를 통해 얻을 수 있는 주요 이점은 무엇인가요?

8 / 10

• 컨테이너리스는 웹 서버를 운영하기 위한 서블릿 컨테이너를 개발자가 직접 설정하고 동작하지 않도록 하는 방식이다

수정해야 하는 부분

• “개발자가 직접 설정하고 동작하지 않도록 하는 방식”
  → “개발자가 별도의 서블릿 컨테이너 설정 및 관리를 하지 않고도 웹 애플리케이션을 동작시킬 수 있게 하는 방식”

10점짜리 답변 예시

컨테이너리스(Containerless)는 서블릿 컨테이너(Tomcat, Jetty 등)를 따로 설치하거나 설정하지 않고도 웹 애플리케이션이 동작할 수 있도록 하는 개념입니다. 스프링 부트에서 제공하는 내장 서버를 활용하면, 개발자는 서버 설정과 운영보다는 비즈니스 로직에 집중할 수 있습니다. 이를 통해 서버 설정 간소화, 배포 편의성, 개발 생산성 향상 등의 이점을 얻을 수 있습니다.

꼭 들어가야 할 키워드

• 컨테이너리스(Containerless)
• 내장 서버(Embedded Servlet Container)
• 서버 설정 간소화
• 배포 편의성
• 생산성 향상

---

2. 서블릿 컨테이너(Web Container)와 스프링 컨테이너(IOC 컨테이너)의 역할 차이점을 설명해보세요.

9 / 10

• 서블릿 컨테이너는 웹 컴포넌트 서블릿의 생명주기를 관리하며 스프링 컨테이너는 스프링 빈의 생명주기를 관리합니다.

수정해야 하는 부분

• (없음)
  (대체로 잘 설명하셨습니다. 생명주기와 책임 부분을 좀 더 명확히 언급해주면 좋습니다.)

10점짜리 답변 예시

서블릿 컨테이너는 웹 요청을 처리하기 위해 서블릿의 생성, 초기화, 요청 라우팅, 종료 등 서블릿의 라이프 사이클을 관리합니다.
스프링 컨테이너(ApplicationContext, IoC 컨테이너)는 애플리케이션 로직을 구성하는 스프링 빈(Bean)들의 라이프 사이클 및 의존성을 관리하며, 필요 시 의존성 주입(DI)을 통해 객체 간 결합도를 낮춰줍니다.

꼭 들어가야 할 키워드

• 서블릿 컨테이너: 라이프 사이클 관리, 요청 라우팅
• 스프링 컨테이너(IoC): 빈(Bean) 관리, 의존성 주입(DI)
• 라이프 사이클

---

3. 스프링 부트에서 내장 서블릿 컨테이너(Embedded Servlet Container)를 사용하는 이유는 무엇인가요?

9 / 10

• 외장 서블릿 컨테이너를 사용하게 된다면 서버마다 설정 파일을 각각 관리해야하며 기본적인 설정도 하나씩 개발자가 설정해야합니다. 내장 서블릿 컨테이너는 스프링 부트가 설정한 기본 값에 필요한 부분만 수정하여 여러 서버에 동일한 설정값으로 배포가 가능하다는 장점입니다.

수정해야 하는 부분

• “외장 서블릿 컨테이너를 사용하게 된다면 서버마다 설정 파일을 각각 관리해야…”
  → “외부 서블릿 컨테이너 사용 시 환경마다 세부 설정을 다르게 관리해야 할 수 있어 복잡도가 커진다는 점이 단점이 될 수 있습니다.”

10점짜리 답변 예시

스프링 부트에서 내장 서블릿 컨테이너를 사용하면, 개발자가 별도로 웹 서버(Tomcat, Jetty 등)를 설치하거나 설정할 필요 없이 하나의 실행 가능한 JAR(또는 WAR)로 패키징할 수 있습니다. 이를 통해 동일한 설정을 여러 환경에서 쉽게 적용할 수 있고, 서버 설정 부담을 덜어 개발 및 배포 속도를 높일 수 있습니다.

꼭 들어가야 할 키워드

• 내장 서블릿 컨테이너
• 설정 부담 감소
• 배포 편의성
• 실행 가능한 JAR

---

4. Tomcat, Jetty, Undertow 등 웹 컨테이너를 직접 설치했을 때와 스프링 부트 내장 컨테이너를 사용할 때의 차이점을 설명해보세요.

8 / 10

• 스프링 부트는 웹 컨테이너 설정을 추상화하여 같은 설정 코드로 설정 값을 변경할 수 있다는 장점이 있습니다.
  외부 컨테이너를 사용하는 경우 컨테이너가 변경되면 옵션 설정 코드를 다시 학습하여 설정해야합니다.

수정해야 하는 부분

• “스프링 부트는 웹 컨테이너 설정을 추상화하여 같은 설정 코드로 설정값을 변경할 수 있다는 장점이 있습니다.”
  → “스프링 부트는 내장 컨테이너를 사용해 웹 컨테이너별 설정을 추상화하므로, 의존성만 교체해도 Tomcat, Jetty, Undertow 등을 손쉽게 교체할 수 있습니다.”

10점짜리 답변 예시

외부 컨테이너를 직접 설치하면, 서버마다 혹은 컨테이너 종류마다 별도의 설정과 디렉터리 구조를 맞춰야 합니다. 반면 스프링 부트는 내장 컨테이너를 사용하는 방식으로 웹 서버와 애플리케이션을 하나의 패키지로 묶어 배포할 수 있습니다. 컨테이너를 교체하고 싶다면 의존성(Dependency)만 교체하면 되므로 유연성이 높고 개발 및 배포가 간단해지는 장점이 있습니다.

꼭 들어가야 할 키워드

• 외부 컨테이너 vs. 내장 컨테이너
• 설정 관리
• 의존성 교체
• 유연성

---

5. 서블릿 컨테이너가 하는 역할 중 ‘라이프 사이클 관리’와 ‘요청 라우팅’에 대해 구체적으로 설명해보세요.

9 / 10

• 서블릿 컨테이너는 웹 요청에 일치하는 서블릿 오브젝트의 생성 유무를 확인하고 없을 경우 생성하여 기능이 동작하도록 합니다. 요청 라우팅은 서블릿 컨테이너가 웹 요청의 주소를 보고 알맞은 서블릿으로 라우팅을 하는 것을 말합니다.

수정해야 하는 부분

• (없음)
  (본인이 작성하신 내용이 충분히 충실합니다.)

10점짜리 답변 예시

• 라이프 사이클 관리: 서블릿 객체를 생성, 초기화(init()), 서비스(service()), 종료(destroy())하는 과정을 총괄합니다. 필요한 시점에 서블릿을 만들고, 사용하지 않을 땐 메모리를 해제해 서버 리소스를 효율적으로 관리합니다.
• 요청 라우팅: HTTP 요청의 URL과 매핑 정보를 기반으로, 해당 요청을 처리할 서블릿(또는 스프링 MVC의 경우 DispatcherServlet)으로 전달해주는 역할을 합니다.

꼭 들어가야 할 키워드

• 라이프 사이클(init, service, destroy)
• 요청 라우팅(URL 매핑)
• 서블릿 객체 생성/종료

---

6. 스프링 부트가 ‘Opinionated(독선적) 설정’을 제공한다는 것은 어떤 의미이며, 개발 과정에서 어떤 장단점이 있나요?

9 / 10

• 스프링 부트는 스프링 부트가 생각하는 기본 설정으로 오브젝트 빈을 생성하여 관리해줍니다.
  만약 처음 개발을 시작하는 경우 빠른 기능 구현 및 테스트가 가능합니다.
  다만 애플리케이션에 개별 설정을 넣고자 하는 경우 스프링 부트 코드를 알고 변경해야하는 추가 학습이 필요합니다.

수정해야 하는 부분

• “스프링 부트는 스프링 부트가 생각하는 기본 설정으로 오브젝트 빈을 생성하여 관리해줍니다.”
  → “스프링 부트는 일반적으로 많이 사용하는 기술 조합과 설정값을 ‘기본’으로 제공해주는 방식입니다.”

10점짜리 답변 예시

Opinionated 설정이란, 스프링 부트가 “일반적으로 가장 적합하다”고 여겨지는 라이브러리와 설정값을 미리 제공한다는 의미입니다.
장점: 개발자가 세세한 설정을 몰라도 빠르게 프로젝트를 시작하고, 효율적으로 애플리케이션을 구성할 수 있습니다.
단점: 특정 환경이나 성능 튜닝이 필요한 상황에서는 기본 설정을 커스터마이징해야 하며, 이를 위해서는 스프링 부트 내부 동작이나 자동 설정(Auto Configuration)을 어느 정도 이해해야 합니다.

꼭 들어가야 할 키워드

• Opinionated Defaults
• 자동 설정(Auto Configuration)
• 커스터마이징
• 장단점(간편 vs. 유연성)

---

7. 전통적인 스프링 MVC 애플리케이션 설정과 스프링 부트의 자동 설정(Auto Configuration) 방식의 차이점을 설명해보세요.

8 / 10

• 전통적인 스프링은 톰캣 설정, 소스코드 설정을 추가로 학습하는 과정이 생깁니다.

수정해야 하는 부분

• “전통적인 스프링은 톰캣 설정, 소스코드 설정을 추가로 하는 과정이 생깁니다.”
  → “전통적인 스프링 MVC 프로젝트는 pom.xml(또는 Gradle 설정)에서 필요한 라이브러리와 버전을 일일이 맞추고, web.xml 또는 복잡한 XML 설정이 필요했지만, 스프링 부트는 Starter와 자동 설정을 통해 이런 과정을 크게 단순화합니다.”

10점짜리 답변 예시

전통적인 스프링 MVC 애플리케이션은 web.xml, spring-servlet.xml 등의 XML 설정 파일을 많이 사용하고, 서블릿 컨테이너(Tomcat 등)를 별도로 설치해 의존성 및 환경 설정을 직접 관리해야 했습니다.
반면 스프링 부트는 자동 설정(Auto Configuration) 기법을 통해, 많이 쓰이는 라이브러리와 공통 기능들을 Starter 형태로 제공하여 XML 설정 없이도 애너테이션 기반으로 빠르게 웹 애플리케이션을 구성할 수 있습니다.

꼭 들어가야 할 키워드

• 전통적인 스프링 MVC
• web.xml, XML 설정
• 스프링 부트 자동 설정(Auto Configuration)
• Starter

---

8. 스프링 부트가 제공하는 Starter(예: spring-boot-starter-web) 구조가 가지는 장점은 무엇인가요?

9 / 10

• 스프링으로 웹 개발을 위해서 필요한 라이브러리와 지금 버전에 가장 호환이 잘되는 버전으로 자동으로 설정합니다.

  개발자는 버전 관리와 당장 웹 개발에 필요한 의존성을 학습하거나 찾아보지 않고 빠르게 개발이 가능한 장점이 있습니다.

수정해야 하는 부분

• (없음)
  (이미 잘 설명해 주셨습니다.)

10점짜리 답변 예시

Starter는 해당 기능(웹, JPA, Security 등)에 필요한 라이브러리와 호환성 있는 버전을 모듈 형태로 묶어둔 것입니다. 이를 사용하면 개발자는 개별 라이브러리를 찾고 버전을 일일이 맞출 필요가 없으며, 필요한 기능을 바로 의존성만 추가하면 됩니다. 따라서 생산성 향상 및 버전 호환성 보장이라는 장점이 있습니다.

꼭 들어가야 할 키워드

• Starter
• 버전 호환성
• 의존성 관리
• 생산성

---

9. 스프링 부트 애플리케이션 실행 시, main() 메소드에서 내장 컨테이너가 어떻게 동작을 시작하는지 대략적인 과정을 설명해보세요.

8 / 10

• 스프링 부트가 자바 소스 코드로 동작할 수 있게 웹 컨테이너를 스프링 부트 버전에 구현하였습니다. 그리고 스프링 부트를 초기화 하는 과정에 웹 컨테이너를 설정 값으로 초기화하고 디스패처서블릿을 해당 웹 컨테이너에 서블릿으로 등록하여 동작합니다.

수정해야 하는 부분

• “스프링 부트를 초기화 하는 과정에 웹 컨테이너를 설정 값으로 초기화하고 디스패처서블릿을 해당 웹 컨테이너에 서블릿으로 등록하여 동작합니다.”
  → 좀 더 구체적으로, “SpringApplication.run()이 실행되면, 내부적으로 내장 컨테이너를 초기화하고 DispatcherServlet을 등록한 뒤, 애플리케이션 컨텍스트를 로딩합니다.”

10점짜리 답변 예시

1. SpringApplication.run(메인클래스.class, args)가 호출됩니다.
2. 스프링 부트는 내장 컨테이너(Tomcat 등) 인스턴스를 생성하고, 해당 컨테이너에 DispatcherServlet을 서블릿으로 등록합니다.
3. 이와 동시에 스프링 컨테이너(ApplicationContext)를 초기화하고, 필요한 빈(Bean)을 생성합니다.
4. 모든 설정이 끝나면 서버 포트가 열리고, HTTP 요청을 받을 준비가 완료됩니다.

꼭 들어가야 할 키워드

• SpringApplication.run()
• 내장 컨테이너 초기화
• DispatcherServlet 등록
• ApplicationContext 로딩

---

10. 스프링 컨테이너(ApplicationContext)와 서블릿 컨테이너가 상호작용하는 방식을 간단히 설명해보세요.

9 / 10

• 서블릿 컨테이너가 웹 요청을 받으면 모든 요청을 디스패처 서블릿이 받습니다. 디스패처 서블릿은 해당 웹 요청을 핸들할 수 있는 핸들러를 스프링 컨테이너에 요청하면 스프링 컨테이너는 해당 웹 요청을 처리하고 응답합니다. 디스패처 서블릿은 스프링 컨테이너가 반환한 값을 가지고 서블릿 컨테이너에게 전달하면 서블릿 컨테이너는 웹 클라이언트에게 응답 패킷에 담아서 반환합니다.

수정해야 하는 부분

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

10점짜리 답변 예시

1. 서블릿 컨테이너(예: Tomcat)가 HTTP 요청을 받습니다.
2. 이 요청은 DispatcherServlet으로 전달되며, DispatcherServlet은 스프링 컨테이너(ApplicationContext)에 해당 요청을 처리할 핸들러(Controller 빈 등)를 조회합니다.
3. 스프링 컨테이너에서 비즈니스 로직을 실행하고, 결과(모델, 뷰)를 DispatcherServlet으로 반환합니다.
4. 서블릿 컨테이너는 DispatcherServlet으로부터 최종 응답을 받아 클라이언트에게 전송합니다.

꼭 들어가야 할 키워드

• 서블릿 컨테이너, DispatcherServlet
• 스프링 컨테이너
• 핸들러(Controller) 조회
• 응답 전송

---

11. 스프링 부트가 개발자에게 ‘비즈니스 로직’에만 집중할 수 있도록 돕는 핵심적인 이유는 무엇인가요?

8 / 10

• 반대로 비즈니스 로직외에 다른 로직까지 개발자가 집중하게 된다면 엔터프라이즈 환경에서 유지보수와 확장하기 어렵기 때문입니다. 기술을 추가할 때마다 학습을 해야하고 해당 기술을 비즈니스 로직에 추가하게 된다면 객체지향 프로그래밍을 하기 어려워지기에 스프링은 비즈니스 로직에만 집중할 수 있도록 외부 기술등을 오브젝트로 분리하여 빠른 개발을 위해서 입니다.

수정해야 하는 부분

• “반대로 비즈니스 로직외에 다른 로직까지 개발자가 집중하게 된다면 엔터프라이즈 환경에서 유지보수와 확장하기 어렵기 때문입니다.”
  → 의미는 좋지만, 좀 더 스프링 부트가 제공하는 편의 기능들을 강조하면 좋습니다. 예: 자동 설정, 공통 인프라 추상화 등

10점짜리 답변 예시

스프링 부트는 자동 설정, 의존성(Starter) 관리, 내장 서버 등을 제공하여 개발자가 서버 설정이나 복잡한 인프라 설정에 신경 쓸 필요를 최소화합니다. 결과적으로 개발자는 핵심 비즈니스 로직에만 집중할 수 있고, 생산성과 유지보수성이 높아집니다.

꼭 들어가야 할 키워드

• 자동 설정
• 비즈니스 로직 집중
• 인프라 추상화
• 생산성

---

12. 스프링 부트가 제공하는 기본 설정(Opinionated Defaults)을 커스터마이징해야 하는 상황은 언제, 어떻게 발생하나요?

9 / 10

• 제가 생각하는 기본 설정을 변경해야하는 경우는 기본 서버 포트번호, 데이터베이스 드라이브, 커넥션 풀 선택, 톰캣 쓰레드 갯수등이 있다고 생각합니다. 사용자 서버 환경과 서비스에 따라 정답이 없기 때문에 이런 경우에 커스터마이징이 필요합니다.

수정해야 하는 부분

• (없음)
  (이미 예로 들은 포트번호, DB 설정 등 매우 적절합니다.)

10점짜리 답변 예시

예를 들어, 기본적으로 8080 포트를 사용하지만 특정 환경에서는 8081처럼 다른 포트를 사용해야 할 수 있습니다. 또는 내장 톰캣 대신 Jetty를 쓰고 싶거나, DB 커넥션 풀 설정(최대 커넥션 수 등)을 튜닝해야 할 때도 커스터마이징이 필요합니다. 이 경우 application.yml 또는 application.properties에서 값을 변경하거나, 별도의 Configuration 클래스를 통해 설정을 오버라이드하면 됩니다.

꼭 들어가야 할 키워드

• 기본 설정 변경(포트, DB, 스레드 풀 등)
• application.yml / properties
• 커스터마이징
• 환경별 설정

---

13. 컨테이너리스와 서버리스(Serverless)의 개념적 유사점과 차이점을 간단히 비교해보세요.

8 / 10

• 컨테이너리스와 서버리스는 모두 개발자가 해당 부분을 신경을 덜 쓰도록 하기 위함입니다. 컨테이너리스는 웹 컨테이너를 동작하기 위해서 필요한 설정이나 최적의 기본 설정을 대신하여 빠른 웹 컴포넌트를 개발할 수 있습니다. 서버리스는 서버를 동작하기 위해 필요한 설정이나 최적의 설정을 대신하여 빠른 애플리케이션을 개발할 수 있습니다. 차이점은 컨테이너리스는 특정 기술에 대한 설정이라면 서버리스는 서버를 동작하기 위한 과정을 말합니다.

수정해야 하는 부분

• “차이점은 컨테이너리스는 특정 기술에 대한 설정이라면 서버리스는 서버를 동작하기 위한 과정을 말합니다.”
  → 좀 더 명확하게 “컨테이너리스는 서블릿 컨테이너 관리를 신경 쓰지 않는 것이고, 서버리스는 클라우드 인프라 전체(서버) 관리를 신경 쓰지 않는 것” 등으로 구분

10점짜리 답변 예시

• 유사점: 둘 다 개발자가 인프라나 환경 설정을 직접 관리하는 부담을 줄여, 비즈니스 로직에 집중하도록 돕는다는 점에서 비슷합니다.
• 차이점: 컨테이너리스는 주로 웹 컨테이너(Tomcat, Jetty 등) 수준에서 설정 및 관리를 최소화하는 개념이고, 서버리스는 AWS Lambda, Azure Functions처럼 서버 인프라(운영체제, 스케일링 등) 자체도 클라우드가 알아서 관리하는 개념입니다.

꼭 들어가야 할 키워드

• 컨테이너리스 vs. 서버리스
• 인프라 관리(서블릿 vs. 서버)
• 비즈니스 로직 집중

---

14. 스프링 부트에서 XML 대신 YAML/Properties 파일을 설정 파일로 주로 사용하는 이유는 무엇인가요?

8 / 10

• XML은 태그를 통해 상위, 하위 계층을 나누게 됩니다. 계층이 길어진다면 상위 계층을 조회하거나 하위 계층을 조회하기에는 어렵습니다.

  그래서 한눈에 상위 계층과 하위 계층에 대한 불필요한 계층확인 과정이 생략됩니다.

수정해야 하는 부분

• “XML은 태그를 통해 상위, 하위 계층을 나누게 됩니다. 계층이 길어진다면 상위 계층을 조회하거나…”
  → 좀 더 간결하게. XML 설정이 장황해지기 쉽고, YAML/Properties는 가독성이 좋아 변경이 편하다는 점을 강조

10점짜리 답변 예시

XML 설정은 태그를 중첩해 표현하므로 파일이 복잡해지고, 설정 변경 시 문법적 오버헤드가 큽니다. 반면 YAML/Properties는 가독성, 간결성, 수정 편의성이 뛰어나고, 환경 변수와 연동하기도 쉽습니다. 그래서 스프링 부트는 YAML 또는 Properties 파일을 통해 손쉽게 환경별 설정을 관리할 수 있도록 권장합니다.

꼭 들어가야 할 키워드

• YAML, Properties
• 간결성, 가독성
• 환경별 설정
• XML 대안

---

15. 스프링 부트를 모르는 개발자가 프로젝트를 시작했을 때, 어떤 점에서 빠르게 개발 가능하다고 느낄 수 있을까요?

9 / 10

• 스프링 부트를 모르는 개발자라도 개발하려는 영역과 필요한 접근 방식을 선택한다면 추가로 필요한 라이브러리나 설정값을 입력하지 않아도 몇가지 애노테이션을 활용해서 기능을 개발할 수 있다는 점이 빠르게 개발 가능하다고 느낄거같습니다.

수정해야 하는 부분

• (없음)
  (핵심을 잘 짚어주셨습니다.)

10점짜리 답변 예시

프로젝트를 생성할 때, Starter 의존성만 추가하면 웹 서버, DB, 테스트 등 필요한 라이브러리가 자동으로 설정되므로, 환경 설정에 대한 고민 없이 바로 컨트롤러, 서비스 로직 개발을 시작할 수 있습니다. 또한 @SpringBootApplication 애너테이션 하나로 부가 설정이 대부분 해결되므로, 금방 웹 애플리케이션을 구동해볼 수 있다는 점에서 빠르게 개발 가능함을 느끼게 됩니다.

꼭 들어가야 할 키워드

• Starter 의존성
• @SpringBootApplication
• 빠른 프로젝트 시작
• 자동 설정

---

16. 스프링 부트 프로젝트에서 Tomcat을 Jetty로 교체하고 싶다면 어떤 설정을 변경해야 할까요?

9 / 10

• 의존성 추가에 제티를 추가하고 톰캣을 제외하면 자동 구성 설정이 제티 코드로 교체하여 웹 컨테이너를 동작시킵니다.

수정해야 하는 부분

• (없음)
  (의존성 교체 방법이 정확합니다.)

10점짜리 답변 예시

일반적으로 Gradle이나 Maven에서 spring-boot-starter-tomcat을 제거하고, spring-boot-starter-jetty를 추가하면 됩니다. 그러면 스프링 부트가 Tomcat 대신 Jetty를 내장 컨테이너로 사용하게 됩니다.

꼭 들어가야 할 키워드

• 의존성 교체
• spring-boot-starter-tomcat → spring-boot-starter-jetty
• 내장 컨테이너 변경

---

17. 스프링 부트의 독선적인 철학(Opinionated Approach)은 대규모 프로젝트보다 소규모/중소형 프로젝트에만 적합하다는 의견에 대해 어떻게 생각하나요?

9 / 10

• 아닙니다. 대규모 프로젝트라도 기본적인 스프링 부트가 제시하는 설정을 따라 기능을 개발할 수 있고 그 부분중 일부만 커스텀하여 사용할 수 있습니다. 반대로 소규모나 중소형 프로젝트라고 할지라도 배포 환경에 따라 기본 설정이 아니라 스프링이 제시하는 설정을 바꿀 수 있기 때문에 먼저 사용해보는 것이 좋다고 생각합니다.

수정해야 하는 부분

• (없음)
  (이미 의견을 잘 주셨습니다.)

10점짜리 답변 예시

스프링 부트는 프로젝트 규모에 관계없이 유연한 커스터마이징이 가능합니다. 대규모 프로젝트에서도 초기 설정과 의존성을 쉽게 관리할 수 있고, 필요한 부분만 오버라이드하면 되므로, 오히려 규모가 커질수록 스프링 부트의 자동 설정과 빠른 의존성 관리가 큰 도움이 됩니다. 따라서 대규모 프로젝트에도 충분히 적합합니다.

꼭 들어가야 할 키워드

• Opinionated Approach
• 유연한 커스터마이징
• 대규모 프로젝트 적용 사례
• 자동 설정의 이점

---

18. 스프링 부트가 자동 설정을 통해 지원하는 대표적인 기능(예: 보안, 메트릭, 외부 설정 등)에는 어떤 것이 있나요?

8 / 10

• 데이터베이스 접근 방법, 커넥션 풀 설정, 톰캣 기본 설정, 네트워크 연결, 레디스 설정, 보안 설정등 다양합니다.

수정해야 하는 부분

• “데이터베이스 접근 방법, 커넥션 풀 설정, 톰캣 기본 설정, 네트워크 연결, 레디스 설정, 보안 설정등 다양합니다.”
  → 내용 자체는 맞지만, 스프링 부트 Actuator나 Security, JPA, Cache 등의 대표 기능을 좀 더 구체적으로 언급해주면 좋습니다.

10점짜리 답변 예시

• Spring Security: spring-boot-starter-security를 통해 로그인, 권한, 인증 처리 등을 자동 구성
• Spring Data JPA: DB 접근과 ORM 매핑을 자동 구성
• Actuator: 서버 모니터링, 메트릭, 헬스 체크 엔드포인트 제공
• Caching: Redis 등 캐시 스토리지와의 연동 간단화
• 외부 설정: application.yml/properties 파일과 환경 변수를 자동으로 매핑

꼭 들어가야 할 키워드

• Spring Security
• Spring Data JPA
• Actuator
• Caching
• 외부 설정

---

19. DispatcherServlet이 스프링 컨테이너와 웹 컨테이너 사이에서 담당하는 역할은 무엇인가요?

9 / 10

• 웹 컨테이너에게 요청을 받아 스프링 컨테이너에게 필요한 핸들러를 호출해주는 역할과 응답 결과를 웹 컨테이너에게 반환해주는 중간 프론트 컨트롤러 역할을 합니다.

수정해야 하는 부분

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

10점짜리 답변 예시

DispatcherServlet은 “프론트 컨트롤러”로서 웹 컨테이너(서블릿 컨테이너)로부터 HTTP 요청을 전달받아, 스프링 컨테이너(빈, 핸들러, 인터셉터 등)에 해당 요청 처리를 위임합니다. 처리 결과(뷰, 모델)를 받아 다시 웹 컨테이너에 전달해 클라이언트 응답으로 돌려주는, 양측을 이어주는 중추적인 역할을 합니다.

꼭 들어가야 할 키워드

• 프론트 컨트롤러
• 요청 위임
• 스프링 컨테이너 연동
• 응답 반환

---

20. 스프링 부트 애플리케이션에서 배포 시 단일 JAR로 만들어 배포할 수 있는데, 이 방식이 가지는 장점은 무엇인가요?

9 / 10

• 어떤 서버에 배포를 하던 스프링 부트 프로젝트에 설정한 웹 컨테이너 설정으로 실행할 수 있습니다. 서버가 윈도우가 되었던, 리눅스가 되었던 환경에 상관없이 같은 설정을 가진 웹 컨테이너를 배포할 수 있다는 것이 장점이기에 여러 서버를 실행하고 소멸하고 증가하는 등 동적으로 변경되는 일이 많을 수록 jar의 장점이 발휘된다고 생각합니다.

수정해야 하는 부분

• “어떤 서버에 배포를 하던… 여러 서버를 실행하고 소멸하고 증가하는 등 동적으로 변경되는 일이 많을 수록 jar의 장점이 발휘된다고 생각합니다.”
  → 좀 더 구체적으로, “서버 환경 의존성을 최소화하고, Docker나 클라우드 환경에서 스케일링이 쉬워진다” 등을 명시하면 좋습니다.

10점짜리 답변 예시

단일 JAR로 배포하면, 내장 서버와 필요한 라이브러리가 전부 포함되어 있으므로 서버 환경(OS, 별도 웹 서버 설치 여부 등)에 의존하지 않고 어느 환경에서든 동일하게 동작합니다. 클라우드나 도커 환경에서 컨테이너 이미지를 생성할 때도 설정이 단순해 확장성과 이식성이 높습니다.

꼭 들어가야 할 키워드

• 단일 JAR
• 내장 서버 포함
• 환경 독립성
• 배포 편의성
• 확장성