반응형

 

OOP란?

객체지향 프로그래밍부터 REST API, Spring Boot의 IoC·DI까지

이번 학습에서는 Spring Boot로 REST API를 구현하기 전에 필요한 백엔드 개발의 기본 개념을 살펴보았다.

처음부터 Controller 코드를 작성하는 것이 아니라, Java 객체지향 프로그래밍과 SOLID 원칙을 먼저 학습한 뒤 REST API의 설계 방식, Spring과 Spring Boot의 특징, 개발 환경 구성, 마지막으로 IoC와 의존성 주입까지 이어지는 흐름이었다.

객체지향 프로그래밍
→ RESTful API 설계
→ Spring과 Spring Boot
→ 개발 환경 구성
→ Spring 컨테이너와 IoC·DI

위 다섯 가지 흐름으로 내용을 정리해보겠다.

1. 객체지향 프로그래밍과 SOLID 원칙

절차적 프로그래밍과 객체지향 프로그래밍

절차적 프로그래밍은 프로그램을 함수와 실행 순서 중심으로 구성한다.

입력
→ 함수 호출
→ 데이터 처리
→ 결과 출력

반면 객체지향 프로그래밍은 데이터와 해당 데이터를 처리하는 기능을 하나의 객체 안에 묶는다.

객체
= 상태를 저장하는 필드
+ 동작을 정의하는 메서드

 

구분 절차적 프로그래밍 객체지향 프로그래밍
기본 구조 함수 중심 클래스와 객체 중심
데이터 관리 함수 외부에서 처리 객체 내부에 캡슐화
재사용 함수 단위 클래스·상속·다형성
정보 보호 상대적으로 어려움 캡슐화를 통한 정보 은닉
적합한 대상 작고 단순한 프로그램 중대형·복잡한 시스템

 

객체지향 프로그래밍은 객체 단위로 기능을 나누기 때문에 프로그램의 규모가 커졌을 때 재사용과 유지보수에 유리하다.

클래스와 객체

클래스는 객체를 만들기 위한 설계도다.

public class Stock {

    String name;
    double price;

    public Stock(String name, double price) {
        this.name = name;
        this.price = price;
    }

    public void updatePrice(double newPrice) {
        this.price = newPrice;
    }
}

객체는 클래스를 기반으로 메모리에 생성된 실제 인스턴스다.

Stock scalaEdu = new Stock("스칼라 에듀", 15_000);
Stock scalaAI = new Stock("스칼라 AI", 17_500);

scalaEdu.updatePrice(15_800);

같은 클래스를 사용하더라도 각각의 객체는 독립적인 필드 값을 가진다.

클래스 Class
→ 객체를 만드는 설계도

객체 Object
→ 클래스로부터 생성된 실제 인스턴스

필드 Field
→ 객체의 상태와 정보

메서드 Method
→ 객체가 수행하는 기능

생성자 Constructor
→ 객체가 만들어질 때 초기값 설정

자료에서는 클래스, 객체, 필드, 메서드, 생성자와 함께 객체지향의 핵심 특성인 캡슐화·추상화·다형성·상속을 주요 용어로 정리한다.

캡슐화 (Encapsulation)

캡슐화는 객체의 필드를 외부에서 직접 변경하지 못하도록 숨기고, 공개된 메서드를 통해 접근하도록 만드는 것이다.

다음과 같이 필드를 공개하면 잘못된 값도 자유롭게 입력할 수 있다.

public class Stock {
    public double price;
}

Stock stock = new Stock();
stock.price = -1_000;

필드를 private으로 선언하고 메서드에서 검증하면 객체의 상태를 안전하게 보호할 수 있다.

public class Stock {

    private double price;

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        if (price <= 0) {
            throw new IllegalArgumentException(
                    "가격은 0보다 커야 합니다."
            );
        }

        this.price = price;
    }
}

캡슐화를 적용하면 다음과 같은 장점이 있다.

외부의 무분별한 값 변경 방지
→ 유효성 검사 가능
→ 내부 구현 변경의 영향 최소화
→ 유지보수와 디버깅 용이

자료에서도 필드를 private으로 숨기고 getter와 setter를 통해 접근하면 데이터 보호와 유효성 검사가 가능하다고 설명한다.

상속과 다형성 (Inheritance & Polymorphism)

상속은 부모 클래스의 필드와 메서드를 자식 클래스가 물려받는 개념이다.

public class Stock {

    protected String name;
    protected double price;

    public void printInfo() {
        System.out.println(name + ": " + price);
    }
}

public class PreferredStock extends Stock {

    private double dividendRate;

    @Override
    public void printInfo() {
        System.out.println(
                name + ": " + price
                + ", 배당률: " + dividendRate
        );
    }
}

다형성은 부모 타입 하나로 여러 자식 객체를 다룰 수 있는 성질이다.

Stock stock = new PreferredStock();
stock.printInfo();

변수의 타입은 Stock이지만 실제 객체가 PreferredStock이므로, 자식 클래스에서 재정의한 메서드가 실행된다.

상속
→ 부모의 속성과 기능을 자식이 물려받음

오버라이딩
→ 부모의 메서드를 자식이 다시 정의

다형성
→ 같은 메서드 호출이 실제 객체에 따라 다르게 동작

추상 클래스와 인터페이스

추상화는 복잡한 구현을 숨기고 외부에는 필요한 역할만 제공하는 것이다.

Java에서는 추상 클래스와 인터페이스를 이용해 추상화를 구현할 수 있다.

구분 추상 클래스 인터페이스
주요 목적 공통 상태와 구현 공유 객체가 따라야 할 역할과 규약 정의
인스턴스 필드 가질 수 있음 일반적으로 상수만 사용
생성자 사용 가능 사용 불가
메서드 구현 일부 구현 가능 default, static 메서드 구현 가능
다중 상속 불가능 여러 인터페이스 구현 가능 
public interface Valuable {

    void printInfo();

    default void updatePrice(double price) {
        System.out.println("가격: " + price);
    }
}

인터페이스를 사용하면 객체의 구체적인 클래스보다 해당 객체가 수행할 수 있는 역할에 집중할 수 있다.

SOLID 원칙

SOLID는 유지보수성과 확장성이 높은 객체지향 프로그램을 만들기 위한 다섯 가지 설계 원칙이다.

원칙 핵심 내용
SRP 하나의 클래스는 하나의 책임만 가져야 한다
OCP 기존 코드를 크게 수정하지 않고 기능을 확장할 수 있어야 한다
LSP 자식 객체가 부모 객체를 정상적으로 대체할 수 있어야 한다
ISP 하나의 큰 인터페이스보다 역할별 작은 인터페이스를 만든다
DIP 구체적인 구현이 아닌 추상화에 의존한다

자료에서는 SOLID를 유지보수성과 확장성을 높이는 설계 원칙으로 설명하며, 특히 DIP를 이후 학습하는 의존성 주입의 이론적 기반으로 연결한다.

DIP를 적용하지 않은 구조에서는 클래스 내부에서 구체적인 객체를 직접 생성한다.

public class Car {

    private SnowTire tire;

    public Car() {
        this.tire = new SnowTire();
    }
}

이 구조에서는 일반 타이어로 변경하려면 Car 클래스의 코드를 수정해야 한다.

인터페이스에 의존하도록 변경하면 구현체를 외부에서 전달할 수 있다.

public interface Tire {
    void roll();
}

public class Car {

    private final Tire tire;

    public Car(Tire tire) {
        this.tire = tire;
    }

    public void drive() {
        tire.roll();
    }
}

이 구조가 이후 Spring의 의존성 주입으로 이어진다.

2. RESTful API의 구조와 설계 원칙

웹 애플리케이션의 기본 구조

웹 애플리케이션은 클라이언트와 서버가 HTTP를 통해 데이터를 주고받는 프로그램이다.

Client
→ Web Server
→ WAS
→ Database

클라이언트는 브라우저나 모바일 앱처럼 서버에 요청을 보내는 프로그램이다.

Web Server는 정적인 콘텐츠를 제공하고, WAS는 비즈니스 로직을 실행해 동적인 결과를 생성한다.

구분 Web Server WAS
주요 역할 정적 콘텐츠 제공 동적 콘텐츠 생성
처리 대상 HTML, CSS, JavaScript, 이미지 비즈니스 로직, DB 연동
대표 예시 Nginx, Apache Tomcat, JBoss
DB 연동 일반적으로 직접 처리하지 않음 가능

웹 애플리케이션은 클라이언트, Web Server, WAS와 DB가 연결된 구조로 동작하며, 서버는 Java와 Spring Boot 같은 기술로 구현할 수 있다.

RESTful API란?

REST는 Representational State Transfer의 약자로 웹의 구조를 활용해 자원을 다루는 아키텍처 스타일이다.

RESTful API의 핵심은 자원과 행위를 구분하는 것이다.

자원 Resource
→ URI의 명사로 표현

행위 Action
→ HTTP Method로 표현
HTTP Method 의미
GET 자원 조회
POST 자원 생성
PUT 자원 전체 수정
PATCH 자원 일부 수정
DELETE 자원 삭제 
GET    /users
POST   /users
GET    /users/3
PUT    /users/3
PATCH  /users/3
DELETE /users/3

자료에서는 RESTful API를 자원을 명사로 표현하고 HTTP 메서드로 해당 자원을 다루는 웹 기반 API로 정의한다.

URI와 URL

URI는 자원을 식별하는 모든 방법을 의미한다.

URL은 URI 중에서도 자원의 위치와 접근 방법을 나타내는 식별자다.

URI
├─ URL: 자원의 위치를 이용해 식별
└─ URN: 자원의 이름을 이용해 식별

모든 URL은 URI다.
하지만 모든 URI가 URL인 것은 아니다.

REST API 설계 규칙

좋은 REST API를 설계할 때는 다음 기준을 지키는 것이 좋다.

설계 기준 예시
URI에는 자원을 나타내는 명사 사용 /users, /products
행위는 HTTP 메서드로 표현 GET /users
전체 자원은 복수형으로 통일 /products
자원 관계는 계층적으로 표현 /users/10/orders
필터·검색·정렬은 쿼리 파라미터 사용 /users?age=20
처리 결과에 맞는 상태 코드 사용 200, 201, 400, 404
응답은 일반적으로 JSON 사용 {"id":1,"name":"Alice"}
각 요청은 독립적으로 처리 Stateless

자료에서는 URI를 명사와 복수형으로 작성하고, 동작은 HTTP 메서드로 표현하며, 각 요청을 독립적으로 처리하는 것을 주요 설계 원칙으로 제시한다.

OpenAPI Specification

API가 많아지면 개발자마다 API 사용법을 다르게 이해할 수 있다.

이를 방지하기 위해 API의 URI, 요청 파라미터, 요청 본문과 응답 형식을 명세로 정의한다.

OAS는 REST API를 기술하고 문서화하기 위한 표준 포맷이다.

API 명세 작성
→ 문서 자동 생성
→ Mock 서버 생성
→ 테스트 자동화
→ 서버·클라이언트 코드 생성

OAS는 YAML 또는 JSON 형식으로 작성할 수 있으며 과거에는 Swagger Specification이라는 이름으로 불렸다.

Swagger 생태계에는 다음과 같은 도구가 있다.

도구 역할
Swagger Editor API 명세 작성과 미리보기
Swagger UI API 명세를 웹 문서로 표현
Swagger Codegen 서버와 클라이언트 코드 생성
OpenAPI Generator 다양한 언어와 프레임워크 코드 생성
SwaggerHub API 명세 협업 플랫폼

3. Spring과 Spring Boot

spring vs spring boot

Spring이란?

Spring은 Java 기반의 오픈소스 애플리케이션 프레임워크다.

엔터프라이즈 애플리케이션에서 필요한 객체 관리, 웹 개발, 데이터 접근, 트랜잭션과 보안 기능을 제공한다.

특징 설명
경량 프레임워크 필요한 모듈만 선택적으로 사용
IoC 객체 생성과 관리를 프레임워크가 담당
DI 객체 사이의 의존성을 외부에서 주입
AOP 로깅·보안·트랜잭션 같은 공통 기능 분리
모듈화 Web, Data, Security 등을 선택해 사용
테스트 용이성 Mock 객체와 DI를 활용한 단위 테스트

자료에서는 Spring을 복잡한 Java 개발을 단순화하는 컨테이너이자 IoC·DI·AOP를 중심으로 하는 엔터프라이즈 Java 프레임워크로 설명한다.

Spring과 Spring Boot의 관계

Spring Boot는 Spring을 대체하는 별도의 프레임워크가 아니다.

Spring의 기능을 더 쉽게 설정하고 실행할 수 있게 만든 도구다.

구분SpringSpring Boot

구분 Spring Spring Boot
목적 유연한 엔터프라이즈 애플리케이션 개발 Spring 프로젝트의 빠른 시작
설정 직접 설정해야 하는 부분이 많음 자동 설정 제공
서버 별도 WAS가 필요한 경우가 많음 내장 Tomcat 제공
의존성 라이브러리를 개별적으로 관리 Starter로 한 번에 관리
실행 WAR 배포 방식 실행 가능한 JAR

Spring은 2003년에 등장했고, Spring Boot는 2014년에 복잡한 설정을 줄이고 빠르게 Spring 애플리케이션을 실행하기 위해 등장했다.

Spring 생태계

Spring은 목적에 따라 다양한 프로젝트를 제공한다.

프로젝트 주요 역할
Spring Boot 자동 설정과 실행 환경
Spring Data JPA 데이터베이스 연동과 Repository
Spring Security 인증과 인가
Spring Batch 대용량 일괄 처리
Spring Cloud 클라우드와 마이크로서비스
Spring WebFlux 비동기·논블로킹 웹 개발

일반적인 백엔드 프로젝트에서는 Spring Boot, Spring Data JPA와 Spring Security를 함께 사용하는 경우가 많다.

Spring Boot의 핵심 특징

Spring Boot는 반복적인 Spring 설정을 자동화한다.

Starter 추가
→ 클래스패스와 환경 확인
→ 필요한 설정 자동 적용
→ Bean 자동 등록
→ 내장 서버 실행
기능 설명
Auto-Configuration 라이브러리와 환경을 감지해 설정 자동 적용
내장 서버 Tomcat 등을 별도로 설치하지 않아도 실행
Starter 기능별 필수 라이브러리 묶음
어노테이션 설정 복잡한 XML 설정 감소
운영 기능 헬스체크와 메트릭 제공
간단한 배포 JAR 파일로 빌드해 바로 실행

Spring Boot는 “설정보다 관례”라는 철학을 기반으로 일반적인 설정을 자동으로 구성한다.

4. Spring Boot 개발 환경 구성

필요한 도구

이번 실습에서는 다음과 같은 도구를 사용한다.

JDK 21
+ VS Code
+ Java·Spring Extensions
+ Spring Initializr
+ Maven 또는 Gradle
+ Postman

JDK는 Java 프로그램을 컴파일하고 실행하는 환경이다.

자료에서는 JDK 21 설치와 함께 VS Code에 Java 및 Spring 관련 Extension을 설치하도록 안내한다.

Spring Initializr

Spring Initializr는 Spring Boot 프로젝트의 기본 구조를 자동으로 생성해 주는 도구다.

실습 프로젝트는 다음과 같이 구성한다.

Project: Maven
Language: Java
Packaging: Jar
Java: 21

주요 의존성은 다음과 같다.

Lombok
Spring Configuration Processor
Spring Web
Spring Data JPA
H2 Database

Spring Initializr에서 프로젝트 정보와 의존성을 선택하면 실행 가능한 Spring Boot 프로젝트의 기본 구조가 생성된다.

프로젝트 디렉터리 구조

src
├─ main
│  ├─ java
│  │  └─ 실제 Java 소스
│  └─ resources
│     ├─ application.yml
│     ├─ static
│     └─ templates
├─ test
│  └─ java
pom.xml

 

경로 역할
src/main/java Controller, Service 등 Java 코드
src/main/resources 설정과 리소스 파일
application.yml Spring Boot 환경 설정
static CSS, JavaScript, 이미지
templates Thymeleaf 같은 템플릿
src/test/java 테스트 코드
pom.xml Maven 의존성과 빌드 설정
target Maven 빌드 결과

자료에서는 Maven 프로젝트의 소스, 설정, 테스트와 빌드 결과가 각각 정해진 표준 디렉터리에 저장된다고 설명한다.

Maven과 Gradle

Maven과 Gradle은 Java 프로젝트의 빌드와 의존성 관리를 자동화하는 도구다.

Maven

Maven은 pom.xml에 프로젝트 설정을 작성한다.

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>
            spring-boot-starter-web
        </artifactId>
    </dependency>
</dependencies>

대표적인 명령은 다음과 같다.

mvn clean
mvn compile
mvn test
mvn package
mvn spring-boot:run
mvn dependency:tree

Maven은 프로젝트의 라이브러리, 빌드, 테스트와 배포 과정을 표준화하며 모든 설정을 pom.xml에서 관리한다.

Gradle

Gradle은 Groovy 또는 Kotlin DSL을 사용한다.

plugins {
    id 'org.springframework.boot' version '3.3.0'
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation(
        'org.springframework.boot:spring-boot-starter-web'
    )
}

Gradle은 증분 빌드, 캐시와 병렬 처리 등을 지원해 대규모 프로젝트에서 빠른 빌드가 가능하다.

Maven
→ XML 기반, 표준화와 학습이 쉬움

Gradle
→ DSL 기반, 유연하고 빌드 속도가 빠름

Spring Boot 실행 클래스

Spring Boot 애플리케이션의 시작점은 @SpringBootApplication이 붙은 클래스다.

@SpringBootApplication
public class BasicApplication {

    public static void main(String[] args) {
        SpringApplication.run(
                BasicApplication.class,
                args
        );
    }
}

@SpringBootApplication은 자동 설정, 컴포넌트 스캔과 설정 클래스 기능을 함께 제공한다.

SpringApplication.run()이 실행되면 Spring 컨테이너와 내장 서버가 시작된다.

5. Spring 컨테이너와 IoC·DI

IoC란?

IoC는 Inversion of Control, 즉 제어의 역전을 의미한다.

일반적인 Java 코드에서는 개발자가 객체를 직접 생성한다.

public class OrderService {

    private OrderRepository repository =
            new OrderRepository();
}

이 방식은 OrderService가 특정 Repository 구현체에 직접 의존하기 때문에 결합도가 높다.

IoC를 적용하면 객체 생성과 관리를 Spring 컨테이너가 담당한다.

public class OrderService {

    private final OrderRepository repository;

    public OrderService(
            OrderRepository repository
    ) {
        this.repository = repository;
    }
}

기존 방식
→ 개발자가 new로 객체 생성

IoC 방식
→ Spring 컨테이너가 객체 생성과 관리

IoC를 적용하면 구체적인 구현체를 쉽게 교체할 수 있고 테스트와 유지보수가 쉬워진다.

IoC 컨테이너

Spring의 IoC는 컨테이너를 통해 구현된다.

컨테이너는 Spring이 관리하는 객체인 Bean을 생성하고 연결하며, 전체 생명주기를 관리한다.

역할 설명
Bean 생성 설정 정보와 어노테이션을 바탕으로 객체 생성
의존성 주입 필요한 객체들을 자동 연결
생명주기 관리 생성부터 초기화와 소멸까지 관리
설정 관리 application.yml 등의 외부 설정과 연동

주요 컨테이너 인터페이스는 다음과 같다.

BeanFactory
→ 가장 기본적인 IoC 컨테이너

ApplicationContext
→ BeanFactory 기능에 이벤트·환경설정 등의 기능 추가

WebApplicationContext
→ Spring MVC와 연결되는 웹 전용 컨테이너

자료에서는 실제 Spring 애플리케이션에서 ApplicationContext가 가장 널리 사용되는 IoC 컨테이너라고 설명한다.

POJO

POJO는 Plain Old Java Object의 약자다.

특정 프레임워크의 규칙이나 클래스를 반드시 상속하지 않는 순수한 Java 객체를 의미한다.

public class Product {

    private String name;
    private int price;
}

Spring은 일반적인 POJO를 Bean으로 등록하고 필요한 기능을 외부에서 결합한다.

따라서 비즈니스 객체가 Spring의 내부 구현에 지나치게 종속되는 것을 줄일 수 있다.

의존성 주입

DI는 객체가 필요한 다른 객체를 직접 생성하지 않고 외부에서 전달받는 방식이다.

IoC
→ 객체 관리 제어권을 컨테이너에 위임하는 원리

DI
→ 컨테이너가 객체 사이의 의존관계를 연결하는 방법

주입 방식은 크게 세 가지다.

방식설명특징

방식 설명 특징
생성자 주입 생성자로 의존 객체 전달 가장 권장
Setter 주입 Setter 메서드로 전달 선택적 의존성에 적합
필드 주입 @Autowired를 필드에 사용 간단하지만 테스트 어려움

생성자 주입을 권장하는 이유

@Service
public class OrderService {

    private final OrderRepository repository;

    public OrderService(
            OrderRepository repository
    ) {
        this.repository = repository;
    }
}

생성자 주입에서는 의존성을 final로 선언할 수 있다.

이는 객체가 생성된 이후 의존성이 변경되지 않도록 보장한다.

생성자 주입의 주요 장점은 다음과 같다.

장점 의미
불변성 생성 후 의존성을 변경할 수 없음
필수 의존성 보장 필요한 객체 없이 생성 불가
테스트 용이성 Mock 객체를 생성자로 전달 가능
순환 참조 감지 시작 시점에 문제 발견 가능
가독성 생성자만 보면 필요한 객체 확인 가능

자료에서도 생성자 주입은 불변성과 필수 의존성을 보장하고, 테스트가 쉬우며 순환 참조를 조기에 발견할 수 있어 권장된다고 설명한다.

동일한 타입의 Bean이 여러 개일 때

하나의 인터페이스를 구현한 Bean이 여러 개라면 Spring은 어떤 객체를 주입해야 할지 결정하지 못할 수 있다.

@Repository("mysqlRepository")
public class MySqlOrderRepository
        implements OrderRepository {
}

@Repository("mongoRepository")
public class MongoOrderRepository
        implements OrderRepository {
}

특정 Bean을 선택할 때는 @Qualifier를 사용한다.

@Service
public class OrderService {

    private final OrderRepository repository;

    public OrderService(
            @Qualifier("mongoRepository")
            OrderRepository repository
    ) {
        this.repository = repository;
    }
}

기본 Bean을 지정할 때는 @Primary를 사용할 수 있다.

@Repository
@Primary
public class DefaultOrderRepository
        implements OrderRepository {
}

@Qualifier
→ 사용할 Bean을 이름으로 직접 선택

@Primary
→ 여러 Bean 중 기본적으로 선택될 Bean 지정

Bean 생명주기

Spring Bean은 다음과 같은 생명주기를 가진다.

Bean 정의 탐색
→ Bean 생성
→ 의존성 주입
→ 초기화 콜백
→ 서비스 로직 수행
→ 소멸 콜백

@PostConstruct는 Bean 생성과 의존성 주입이 끝난 뒤 한 번 호출된다.

@PreDestroy는 컨테이너가 종료되기 직전에 한 번 호출된다.

@Service
public class UserService {

    private final UserRepository repository;

    public UserService(
            UserRepository repository
    ) {
        this.repository = repository;
    }

    @PostConstruct
    public void init() {
        System.out.println("Bean 초기화");
    }

    @PreDestroy
    public void destroy() {
        System.out.println("Bean 자원 정리");
    }
}

초기화 단계에서는 외부 연결이나 데이터를 준비할 수 있고, 소멸 단계에서는 파일·네트워크 연결·스레드 풀과 같은 자원을 정리할 수 있다.

전체 흐름 다시 보기

지금까지 학습한 내용은 다음과 같이 연결된다.

객체지향 프로그래밍
→ 객체의 역할과 책임을 분리

SOLID
→ 변경에 유연한 설계 원칙 적용

REST API
→ 클라이언트와 서버의 통신 규칙 정의

Spring
→ 객체 관리와 웹 개발 기능 제공

Spring Boot
→ 반복 설정과 실행 환경 자동 구성

IoC Container
→ Bean 생성과 생명주기 관리

Dependency Injection
→ 객체 간 의존성을 외부에서 연결

Spring은 객체지향과 SOLID 원칙에서 설명한 느슨한 결합을 IoC와 DI를 통해 실제 애플리케이션에 적용한다.

핵심 정리

객체지향 프로그래밍

클래스
→ 객체를 만드는 설계도

객체
→ 메모리에 생성된 실제 인스턴스

필드
→ 객체의 상태

메서드
→ 객체의 동작

객체지향의 핵심 특성

캡슐화
상속
다형성
추상화

REST API

URI
→ 자원을 명사로 표현

HTTP Method
→ 자원에 대한 행위 표현

Stateless
→ 각 요청을 독립적으로 처리

Spring Boot

자동 설정
+ Starter
+ 내장 서버
+ 실행 가능한 JAR

IoC와 DI

IoC
→ 객체 생성과 관리 권한을 컨테이너에 위임

DI
→ 필요한 객체를 외부에서 주입

권장되는 DI 방식

생성자 주입
→ 불변성
→ 필수 의존성 보장
→ 테스트 용이
→ 순환 참조 조기 발견

복습 질문

  1. 절차적 프로그래밍과 객체지향 프로그래밍은 프로그램을 구성하는 단위가 어떻게 다른가?
  2. 클래스, 객체, 필드와 메서드는 각각 무엇을 의미하는가?
  3. 필드를 private으로 선언하면 어떤 장점이 있는가?
  4. 상속과 다형성은 서로 어떻게 연결되는가?
  5. SOLID의 DIP는 Spring의 DI와 어떤 관계가 있는가?
  6. REST API에서 URI에는 명사를, 행위에는 HTTP 메서드를 사용하는 이유는 무엇인가?
  7. Web Server와 WAS는 각각 어떤 역할을 수행하는가?
  8. Spring과 Spring Boot의 차이는 무엇인가?
  9. Starter를 사용하면 어떤 설정이 간단해지는가?
  10. IoC와 DI는 각각 무엇을 의미하는가?
  11. 생성자 주입이 필드 주입보다 권장되는 이유는 무엇인가?
  12. 동일한 인터페이스 타입의 Bean이 여러 개일 때 @Qualifier와 @Primary는 어떻게 사용하는가?
  13. @PostConstruct와 @PreDestroy는 각각 언제 호출되는가?
반응형

'개발 > SKALA 4기' 카테고리의 다른 글

[SKALA] 컴포넌트 스캔과 Spring 컨테이너, HTTP 요청 바인딩 정리  (0) 2026.07.29
[SKALA] Spring Boot 설정 관리와 MVC·Actuator 정리  (0) 2026.07.29
[SKALA] LLM 모델과 Transformer 아키텍처 이해  (0) 2026.07.23
[SKALA] Prompt 설계 및 Context Engineering  (1) 2026.07.23
[SKALA] 데이터 전처리와 상관·회귀분석 정리  (0) 2026.07.23

티스토리툴바