Eugenius1st.log

IoC(제어의 역전), DI(의존성 주입) 이해하기

Tue, 22 Sep 2026 08:25:30 GMT

IoC(제어의 역전), DI(의존성 주입) 이해하기

1. Spring의 IoC와 DI

💡 IoC, DI… 누구냐 넌?

Java를 배우고 Spring을 처음 접하면 가장 먼저 듣게 되는 용어 중 하나가 IoC와 DI입니다.

Spring으로 개발을 시작한 분들이 가장 많이 오해하는 부분은 IoC와 DI가 Spring에서 처음 만들어진 기능이라고 생각하는 것입니다.

하지만 IoC와 DI는 Spring만의 개념이 아닙니다.

IoC(Inversion of Control) → 설계 원칙
DI(Dependency Injection) → 디자인 패턴

즉, 객체지향적인 좋은 코드를 만들기 위한 개념이라고 이해하면 좋습니다.

설계 원칙과 디자인 패턴이라는 용어가 낯설다면 요리에 비유해보겠습니다.

2. 설계 원칙과 디자인 패턴

🧑‍🍳 김치볶음밥 맛있게 만드는 방법 — 설계 원칙

맛있는 김치볶음밥을 만들기 위한 원칙은 다음과 같습니다.

신선한 재료를 사용한다.
신 김치를 사용한다.
밥과 김치의 비율을 잘 맞춘다.
볶을 때 재료를 넣는 순서가 중요하다.

이처럼 좋은 결과물을 만들기 위해 지켜야 하는 기본적인 원칙이 설계 원칙이라고 볼 수 있습니다.

🍳 김치볶음밥 레시피 — 디자인 패턴

맛있는 김치볶음밥을 만들기 위한 구체적인 레시피는 다음과 같습니다.

오일을 두른 팬에 채 썬 파를 볶아 파 기름을 만든다.
준비한 햄을 넣고 볶다가 간장 한 스푼을 넣어 풍미를 낸다.
설탕에 버무린 김치를 넣고 함께 볶는다.
미리 식혀 둔 밥을 넣어 함께 볶는다.
참기름 한 스푼을 넣어 마무리한다.

즉, 원칙을 실제 코드나 작업 과정에서 적용하기 위한 구체적인 방법이라고 생각하면 됩니다.

3. 좋은 코드를 위한 Spring의 IoC와 DI

그렇다면 좋은 코드란 무엇일까요?

논리가 간단해야 한다.
중복을 제거하고 표현을 명확하게 해야 한다.
코드를 처음 보는 사람도 쉽게 이해하고 수정할 수 있어야 한다.
의존성을 최소화해야 한다.
새로운 기능을 추가하더라도 기존 구조를 크게 변경하지 않아야 한다.
...

좋은 코드를 작성하기 위해서는 신경 써야 할 부분이 정말 많습니다.

Spring은 개발자가 Java를 사용하여 이러한 좋은 코드를 작성할 수 있도록 도와주는 프레임워크입니다.

실생활에 비유한다면 요리 도구와 재료가 어느 정도 준비되어 있는 밀키트라고 볼 수 있습니다.

그리고 그중에서도 IoC와 DI는 Spring의 핵심 개념이라고 할 수 있습니다.

Spring에서는 IoC Container를 통해 객체의 생성과 관리 등을 담당합니다.

Spring Docs에서는 IoC를 DI(Dependency Injection)와 같은 의미로 설명하기도 합니다.

이를 간단하게 정리하면 다음과 같습니다.

DI 패턴을 사용하여 IoC라는 설계 원칙을 구현한다.

Spring의 IoC Container와 Bean에 대해서는 이후에 자세하게 알아보겠습니다.

4. 의존성이란?

💡 DI를 이해하려면 먼저 '의존성'을 이해해야 합니다.

우리가 다리를 다쳐서 목발을 사용하여 걷게 되었다고 생각해봅시다.

이 경우 우리는 걷기 위해 목발에 의존하고 있습니다.

코드에서도 마찬가지입니다.

어떤 객체가 다른 객체를 사용해야만 정상적으로 동작한다면, 한 객체가 다른 객체에 의존하고 있다고 표현할 수 있습니다.

4-1. Consumer와 Chicken의 강한 결합

public class Consumer {

    void eat() {
        Chicken chicken = new Chicken();
        chicken.eat();
    }

    public static void main(String[] args) {
        Consumer consumer = new Consumer();
        consumer.eat();
    }
}

class Chicken {

    public void eat() {
        System.out.println("치킨을 먹는다.");
    }
}

위 코드에서 Consumer와 Chicken의 관계를 살펴보겠습니다.

Consumer가 직접 Chicken 객체를 생성하고 있습니다.

Chicken chicken = new Chicken();

즉, Consumer가 Chicken이라는 구체적인 클래스에 강하게 의존하고 있습니다.

현재 코드가 실행되는 데에는 문제가 없습니다.

하지만 만약 Consumer가 치킨이 아니라 피자를 먹고 싶어진다면 어떻게 해야 할까요?

Chicken chicken = new Chicken();

이 부분을 Pizza로 변경해야 합니다.

만약 음식의 종류가 계속 추가된다면 Consumer의 코드도 계속 수정해야 합니다.

이러한 관계를 강한 결합 또는 강한 의존성이라고 합니다.

5. Interface를 이용한 약한 결합

그렇다면 어떻게 하면 결합을 약하게 만들 수 있을까요?

Java의 Interface와 다형성을 활용할 수 있습니다.

public class Consumer {

    void eat(Food food) {
        food.eat();
    }

    public static void main(String[] args) {
        Consumer consumer = new Consumer();

        consumer.eat(new Chicken());
        consumer.eat(new Pizza());
    }
}

interface Food {
    void eat();
}

class Chicken implements Food {

    @Override
    public void eat() {
        System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {

    @Override
    public void eat() {
        System.out.println("피자를 먹는다.");
    }
}

이번에는 Consumer가 Chicken이나 Pizza에 직접 의존하지 않습니다.

대신 Food라는 인터페이스에 의존하고 있습니다.

void eat(Food food) {
    food.eat();
}

Chicken과 Pizza는 모두 Food를 구현하고 있기 때문에 Consumer는 어떤 음식이 들어오더라도 사용할 수 있습니다.

consumer.eat(new Chicken());
consumer.eat(new Pizza());

이처럼 인터페이스를 활용한 다형성을 사용하면 구체적인 구현체에 대한 의존성을 줄일 수 있습니다.

이러한 관계를 약한 결합(Loose Coupling) 또는 약한 의존성이라고 합니다.

6. 주입이란?

💡 그렇다면 '주입'은 무엇일까요?

우리가 주사기를 통해 백신을 몸속에 주입하듯이,

코드에서의 주입(Injection)도 필요한 객체를 해당 객체에 전달하는 것을 의미합니다.

대표적인 주입 방법에는 다음과 같은 것들이 있습니다.

필드 주입
메서드 주입
생성자 주입

6-1. 필드에 직접 주입

public class Consumer {

    Food food;

    void eat() {
        this.food.eat();
    }

    public static void main(String[] args) {
        Consumer consumer = new Consumer();

        consumer.food = new Chicken();
        consumer.eat();

        consumer.food = new Pizza();
        consumer.eat();
    }
}

interface Food {

    void eat();
}

class Chicken implements Food {

    @Override
    public void eat() {
        System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {

    @Override
    public void eat() {
        System.out.println("피자를 먹는다.");
    }
}

Consumer가 직접 Chicken을 생성하여 사용하는 것이 아니라,

외부에서 Food 객체를 전달받아 사용하고 있습니다.

consumer.food = new Chicken();

또는

consumer.food = new Pizza();

즉, 필요한 객체를 Consumer의 food에 주입하고 있습니다.

6-2. 메서드를 통한 주입

이번에는 setter 메서드를 이용해 객체를 주입해보겠습니다.

public class Consumer {

    Food food;

    void eat() {
        this.food.eat();
    }

    public void setFood(Food food) {
        this.food = food;
    }

    public static void main(String[] args) {
        Consumer consumer = new Consumer();

        consumer.setFood(new Chicken());
        consumer.eat();

        consumer.setFood(new Pizza());
        consumer.eat();
    }
}

interface Food {

    void eat();
}

class Chicken implements Food {

    @Override
    public void eat() {
        System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {

    @Override
    public void eat() {
        System.out.println("피자를 먹는다.");
    }
}

이번에는 다음과 같은 setFood() 메서드를 만들었습니다.

public void setFood(Food food) {
    this.food = food;
}

그리고 외부에서 원하는 객체를 전달합니다.

consumer.setFood(new Chicken());

또는

consumer.setFood(new Pizza());

이처럼 setter와 같은 메서드를 통해 필요한 객체를 전달하는 방식도 의존성 주입입니다.

6-3. 생성자를 통한 주입

마지막으로 생성자를 이용해 객체를 주입할 수 있습니다.

public class Consumer {

    Food food;

    public Consumer(Food food) {
        this.food = food;
    }

    void eat() {
        this.food.eat();
    }

    public static void main(String[] args) {

        Consumer consumer = new Consumer(new Chicken());
        consumer.eat();

        consumer = new Consumer(new Pizza());
        consumer.eat();
    }
}

interface Food {

    void eat();
}

class Chicken implements Food {

    @Override
    public void eat() {
        System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {

    @Override
    public void eat() {
        System.out.println("피자를 먹는다.");
    }
}

Consumer의 생성자를 살펴보면 다음과 같습니다.

public Consumer(Food food) {
    this.food = food;
}

그리고 객체를 생성할 때 필요한 Food 객체를 전달합니다.

Consumer consumer = new Consumer(new Chicken());

또는

Consumer consumer = new Consumer(new Pizza());

이렇게 생성자를 통해 의존 객체를 전달하는 방식을 생성자 주입이라고 합니다.

7. 제어의 역전(IoC)이란?

💡 마지막으로 제어의 역전은 무엇일까요?

처음 코드를 다시 살펴보겠습니다.

public class Consumer {

    void eat() {
        Chicken chicken = new Chicken();
        chicken.eat();
    }
}

여기서는 Consumer가 직접 Chicken 객체를 생성합니다.

즉,

Consumer
   ↓
Chicken 생성
   ↓
Chicken 사용

객체의 생성과 사용에 대한 제어권이 Consumer에게 있습니다.

따라서 새로운 음식이 필요하다면 Consumer의 코드를 직접 수정해야 합니다.

7-1. 의존성 주입을 사용하면?

이번에는 Consumer가 필요한 Food를 외부에서 전달받도록 변경했습니다.

public class Consumer {

    void eat(Food food) {
        food.eat();
    }
}

이제 Consumer는 어떤 구체적인 음식이 만들어지는지 직접 알 필요가 없습니다.

외부에서 만들어진 객체를 전달받아 사용하기만 하면 됩니다.

consumer.eat(new Chicken());
consumer.eat(new Pizza());

즉, 객체의 생성과 전달에 대한 제어가 Consumer 밖으로 이동했습니다.

이를 제어의 역전(IoC, Inversion of Control)이라고 합니다.

8. IoC와 DI 정리

전체 흐름을 정리하면 다음과 같습니다.

기존 방식

Consumer
   │
   ├── Chicken 객체 생성
   │
   └── Chicken 사용

Consumer가 직접 필요한 객체를 생성하기 때문에 구체적인 구현체에 강하게 결합되어 있습니다.

DI를 적용한 방식

외부
 │
 ├── Chicken 생성
 │
 └── Consumer에게 전달
          │
          ↓
       Food 사용

Consumer는 필요한 객체를 직접 생성하지 않고 외부에서 전달받습니다.

따라서 객체 생성에 대한 제어권이 Consumer에서 외부로 이동하게 됩니다.

이것이 제어의 역전(IoC)입니다.

그리고 외부에서 필요한 객체를 전달해주는 구체적인 방법이 의존성 주입(DI)입니다.

⭐ 핵심 정리

개념	의미
의존성	한 객체가 다른 객체를 필요로 하는 관계
약한 결합	구체적인 구현체보다 인터페이스 등에 의존하는 구조
주입(Injection)	필요한 객체를 외부에서 전달하는 것
DI	객체가 필요한 의존성을 외부에서 주입받는 디자인 패턴
IoC	객체의 생성·사용 등에

데이터 설계와 연관관계

Thu, 17 Sep 2026 13:12:42 GMT

```sql
-- orders 테이블
CREATE TABLE orders
(
    id          BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    user_id     BIGINT         NOT NULL,
    total_price DECIMAL(10, 2) NOT NULL,
    status      VARCHAR(20)    NOT NULL,
    created_at  TIMESTAMP               DEFAULT CURRENT_TIMESTAMP,
    updated_at  TIMESTAMP      NOT NULL DEFAULT CURRENT_TIMESTAMP
);
```

orders가 user_id를 가짐으로서 관계 정의가 되고 join이 가능한 것이 연관관계이다. user입장에서는 order의 id 여러개를 가질 수 있다.

1:N 이라고한다. 하나의 row가 N개의 row를 가지는 것을 말한다.

이를 엔티티에서 표현해야한다.

1. user관점에서 order 표현

2. order관점에서 user 표현

N:N 을 표현하는 설계 원칙

user 과 order 가 N:N이라면 1:N 을 중첩시킬 수 있는 mapping table을 만들어야 한다.

JPA Entity

Wed, 16 Sep 2026 13:03:28 GMT

핵심 어노테이션

@Entity
- 이 클래스가 JPA가 관리해야 하는 엔티티임을 표시합니다. 필수 어노테이션입니다.
- 주의: 기본 생성자(no-args constructor)가 반드시 필요하며, final 클래스에는 사용할 수 없습니다.
@Table(name = "...")
- 엔티티 클래스가 매핑될 데이터베이스 테이블의 이름을 지정합니다.
- 만약 생략하면, 엔티티 클래스 이름을 테이블 이름으로 사용합니다. (예: User -> user)

네이밍 규칙

DB는 무조건 스테이크 자바는 카멜 케이스가 표준이다.

DB예약어는 주의해야 한다. USER, ORDER, GROUP 등은 데이터베이스의 예약어일 수 있다. 따라서 컬럼명이나 테이블명으로 사용하면 예기치 않은 오류가 발생할 수 있으므로 피하는것이 좋다. 부득이 한경우 @Table(name = "백틱order백틱") 로 백틱으로 감싸서 처리하라.

그렇다고 order_info 이런식으로 하지말라. 명시적인 하나의 단어로 하라. 만약 저렇게 하면 상위에 order 에 있다고 느껴진다. order가 존재하지도 않는데 order_info로 만들면 개발자들이 헷갈린다.

테이블명 단수VS복수

ORM에서만 단수형을 써라

전통적인 방식 (복수형 - users)
- 데이터베이스 관점에서는 테이블을 데이터의 '집합(Collection)'으로 봅니다. 따라서 '사용자들의 모음'이라는 의미로 users, orders처럼 복수형을 사용하는 것이 일반적이었습니다.
ORM/JPA 관점 (단수형 - user)
- 최근 ORM이 널리 쓰이면서 생긴 경향입니다. ORM은 User라는 엔티티 클래스(객체) 하나가 user라는 테이블 하나와 1:1로 매핑된다고 봅니다. 즉, 객체의 관점을 따라 단수형으로 이름을 일치시키는 것이 더 직관적이라는 것입니다.

가끔가다 테이블을 ORM처럼 단수형으로 쓰는 회사도 있긴 함

상태(Boolean) 타입 필드 네이밍
- Java/API 네이밍 (is- / has- / can-)
  - Boolean 타입의 필드명은 그 자체로 '참/거짓'으로 답할 수 있는 질문이 되도록 짓는 것이 가장 좋습니다. is~로 시작하는 네이밍은 자바빈 표준 명세에 따른 규칙으로, 여러 프레임워크(Lombok, Jackson 등)가 이를 자동으로 인지하여 가독성과 개발 편의성을 높여줍니다.
  - 가독성: if (user.isActive()) 처럼 코드가 자연스러운 영어 문장처럼 읽힙니다.
- 대표 접두사
  - is~: 상태를 나타낼 때 (e.g., isActive, isDeleted, isVisible)
  - has~: 소유나 포함 여부를 나타낼 때 (e.g., hasProfileImage, hasCoupon)
  - can~: 가능/권한 여부를 나타낼 때 (e.g., canPurchase, canComment)

Yn쓰는 경우도 있다. 요새는 잘 안쓴다.

Entity 역할?

엔티티는 데이터를 사용하는게 아니다. 그냥 표현해 놓은 것 뿐. 클래스 기반의 데이터 set이다.

Repository

Entity를 기반으로 메소드를 정의해둔 것이다. interface채로 entity들을 추상화해둘 수 있다.

즉, User Table(특정 테이블 전용) SQL명령어 모음집 이다. @Repository를 붙여야만 한다.

@Service, @Repository는 스프링이 실행할때 인스턴스화 해서 갖고있다.

@Repository
public interface UserRepository extends JpaRepository {

  // 이건 인터페이스다. 인터페이스는 이 자체만으로는 실행 불가하고 '구현체가 필요하다.'
  Optional findByEmail(String email);
  // 이건 구현체를 만들어주고 이 안에 쿼리가 들어가는 것이다.즉 뒷단에서 움직이는 것이고 우리가 하는건 구현체일뿐. 볼 수 없다. 빌드 클래스 파일 열어야할듯

}

ORM과 Hibernate

Tue, 15 Sep 2026 14:01:24 GMT

ORM이란

객체와 테이블을 자동 매핑하여 SQL없이 객체 중심으로 데이터 다루게 해줌. SQL보단 객체 중심의 코드로 비즈니스 로직에 집중할 수 있다. 객체 모델만 수정하면 되므로 유지보수에도 용이하다.

Hibernate

ORM개념을 구현한 대표적인 프레임워크

JPA

여러개의 데이터베이스를 호환시킬 수 있는 규칙

ORM 트렌드

스몰 쿼리를 이용, 중복쿼리 조합 사용. 객체베이스로 올라오니 쿼리 베이스가 아니라 list, set, map과 같은 자료구조 연산자들을 사용해서 최적화 할 수 있는 여지가 남았다.

과거 프로젝트 보면, 서비스로직이 텅 비어있고 xml파일에 수십줄의 코드가 쓰여있는 경우가 많다. 이는 어떤 코드인지 해석할 수가 없다. 그리고 중복 쿼리를 조합해서 쓸 수 없다. 강사님: 아예 mybatis 자체가 없어져도 된다고 생각한다.

Entity

자바가 이해할수있는 파일

Layered 패턴

Tue, 15 Sep 2026 13:10:04 GMT

Layered 패턴

API동작 방식은 아래와 같다.

API /member=> 동작 기대: member테이블에서 member 정보를 받아온다.

API정의 => /member
Member 목록 조회
/SELECT * FROM MEMBER
DB 쿼리 실행
MEMBER 데이터 습득
데이터 가공
Response

Layered 패턴이란, 이 일련의 행위를 3개로 나누는 것이다.

controller => API 정의(핸들러)
service => API 요청 가공, 쿼리의 응답 가공, 에러처리, 트랜젝션 처리, 필터처리 등등..(로직)
repository = > 쿼리를 정의, DB와 소통(자원 제공)

디렉토리 구조 예시

src
└── main
    ├── java
    │   └── com.example.demo
    │       ├── domain               # 📌 도메인별 패키지
    │       │   └── member
    │       │       ├── controller   # Member 관련 HTTP 요청 처리 (API 엔드포인트)
    │       │       ├── service      # Member 관련 비즈니스 로직 구현
    │       │       ├── dto          # Member 관련 데이터 전송 객체 (Request/Response)
    │       │       ├── entity       # Member 데이터베이스 테이블과 매핑되는 객체
    │       │       └── repository   # Member 데이터베이스 접근 로직 (JPA 인터페이스)
    │       │
    │       ├── common               # 📂 여러 도메인에서 공통으로 사용하는 코드
    │       │   └── util             # 유틸리티 클래스 (e.g., 날짜, 암호화 등)
    │       │
    │       └── global               # 🌍 애플리케이션 전역에 적용되는 코드
    │           └── config           # 각종 설정 클래스 (e.g., SecurityConfig)
    │
    └── resources
        ├── db/migration/            # DB 마이그레이션 스크립트 (Flyway, Liquibase)
        ├── application.yml          # 애플리케이션 주요 설정 파일
        └── static/                  # CSS, JS, 이미지 등 정적 리소스

yml 파일

들여쓰기가 중요하다, 이걸로 설정을 작성한다.

이상적인 개발 환경

회사가서 해야하는 부분

local => 개인 pc (local DB) => stage or dev 데이터를 개인pc 로컬로 덤프 / 편의상 DEV 보라는 회사도 있지만, 좋지 않음. 프론트는 ? => 원칙상 local에 붙어야 한다. qa가 제대로 확인이 안되므로 개발 되기 전까진 로컬에 덤프뜨라고 해도 할 수 있지 못하기 때문에 안한다. 그래서 K8s(쿠버네티스 사용) 별도의 브랜치마다 서버 환경 설정
dev => dev 서버(spring) -> DEV DB
stage => stage 서버 + 운영 DB
prod => 운영 서버 + 운영 DB

build gradle

dependencies 는 외부 라이브러리를 뭘 쓸거다라는 설정이다.

implementation: import 하는 것(spring-boot-starter-web을 땡겨와야 spring boot프로젝트가 된다, starter-undertow, starter-data-jpa orm관련한 걸 땡겨온다, starter-security 로 인증인가 필터처리 라이브러리를 땡겨온다. starter-validation 은 api 특정 속성,패턴 들에 기인해서 정의하고 싶을 때 검증하기 위한 라이브러리, starter-acurator 은 어떤 부하가 오는지 헬스 체크다.이는 생각보다 중요하다. querydsl 데이터베이스 쿼리를 작성할 수 있게 도와주는 프레임워크, springdoc OPEN API사양을 바탕으로 API문서 자동 생성해주는 라이브러리, flyway 는 자동버전관리 프레임워크, mapstructure 추상화 라이브러리, jjwt는 json을 파싱해주는 것이다. lombok 은 어노테이션 패키지)
compileOnly: 컴파일 할때만 실행하는 라이브러리(lombok), 따라서 이 아래부터 순서가 중요하다. 정상 동작이 안된다. 라이브러리를 땡기는 작업들을 먼저 한다음에 진행해줘야 한다. 아래는 다 실행할 것을을 적재한다.
runtimeOnly:
annotationProcessor: 프로그램이 실행될때 특정 코드를 자동화해서 만들어준다.

@Configuration

@Configuration 어노테이션을 붙이면 설정 파일이 된다.

형상관리 파일

이게 파일명 규칙이다.

db.migration이라는건 yml파일 안에 있는 locations에 있는 Flyway설정 위치로 맞춰야 한다.

Spring

Tue, 15 Sep 2026 11:47:05 GMT

왜 스프링인가?

죽어도 바뀌지 않아서, 일관성이 있다. => 그래서 욕먹긴 한다고 함.

또한 넓은 범위의 회사를 대응할 수 있다.

톰캣, 서블릿, 그리고 스프링 컨테이너의 구조

톰캣 (Tomcat) - 웹 서버 & 서블릿 컨테이너

역할: 클라이언트(웹 브라우저)로부터 오는 HTTP 요청을 가장 먼저 받는 관문입니다. 마치 건물의 "안내 데스크"와 같습니다.

웹 서버 VS 웹 어플리케이션 이 둘에 대한 설명을 명확하게 할 수 있는가?

웹 서버는 ? 톰캣이다. 웹 어플리케이션은? 스프링이다.+ 톰캣 포함.

웹 어플리케이션은 웹사이트 전체를 포함한 하나의 서비스이다. 일반 사용자들이 사용할 수 있는 프로그램이 웹 어플리케이션이고 이 안에서 통신을 위해 사용하는 프로그램이 웹 서버이다.

전통적인 웹의 라우팅 방식(php)

사용자 -> API요청 -> DNS(http://eugenius.com/member->192.168.0.1) -> PC PC(Tomcat(웹서버) /member 탐색)

이는 톰캣에 파일 넣는 전형적인 방식이라 복잡한 엔드포인트를 만들어 내는데 한계점이 있다. 그래서 하나로 퉁치고 분기처리 해주는 프로그램이 필요했다. 그래서 생긴것이 "서블릿" 이다.

사용자 -> API요청 -> DNS(http://eugenius.com/member->192.168.0.1) -> PC PC(Tomcat(웹서버) -> 서블릿 -> 스프링)

서블릿

역할: 톰캣으로부터 요청을 넘겨받는 스프링의 중앙 통제실 또는 "교통 경찰"입니다.

이 공통된 하나의 엔드포인트 서블릿으로 들어오면 여러개의 자원에 접근 가능하도록 분기처리 해준다. 즉, 스프링이 이해할 수 있는 형태로 변환해주는 것이 서블릿이다.

(구조적으로 보면 스프링이 서블릿을 추상화 해놓은것. 어찌보면 한몸이다. 서블릿의 역할은 스프링을 컨트롤 하는 것이다.)

http://eugenius.com/member -> tomcat -> 서블릿(/member) -> SPRING(MemberController)

이렇게 하면 member에 대한 코드들을 return 받는다. 쿠키나 헤더는 다 서블릿을 통해 접근을 한다.

서블릿은 스프링 앞단에서 작동하는 통신 리소스라고 정리!

서블릿은 나중에 딥다이브 해라. 그래야 http프로토콜 이해하는데 도움이 되고, 면접 때 필요할 것이다.

React Native + 카카오맵 웹뷰 삽질

Tue, 30 Jun 2026 02:07:19 GMT

HealingTrip 카카오맵 WebView 스터디

React Native WebView + Kakao Maps JS SDK 로컬 개발 중 겪은 문제와 해결 과정 정리

대상: HealingTrip FE (Expo + react-native-webview + Vite 지도 페이지)

1. 배경 / 목표

아키텍처 원칙

WebView = 멍청한 지도 렌더러, 데이터·상태·UI = 전부 RN

영역	담당
장소 fetch, 필터, 바텀시트, 검색	React Native
지도 렌더링, 마커, 카메라	WebView (Kakao JS SDK)
RN ↔ WebView 통신	`{ type, payload }` 메시지 프로토콜

구성

web/map/ ← Vite로 빌드하는 지도 전용 페이지 (main.js)

components/map/ ← MapWebView.tsx

hooks/ ← useMapBridge.ts (브릿지 + MAP_READY 큐)

app/(tabs)/map/ ← 지도 탭 화면

지도 페이지는 EXPO_PUBLIC_MAP_URL (로컬: http://localhost:5174)로 WebView에 로드.

2. 겪었던 증상 (시간순)

증상 A: 빨간/빈 화면만 보임

Mac 브라우저 http://localhost:5174 → 지도 OK
RN WebView → HTML만 보이거나 지도 없음

초기 가설 (틀린 것들)

❌ HTTPS가 아니라서? → 같은 HTTP인데 다른 Vite 앱(5174)은 WebView에서 됨
❌ localhost 접속 불가? → load start/end 로그 나옴, HTML 렌더됨
❌ 시뮬레이터 문제? → iOS 시뮬레이터 Safari에서는 동일 URL OK

증상 B: HTML/텍스트는 보이는데 지도만 안 보임

WebView에서
디버그 텍스트는 보임
시뮬레이터 Safari에서는 텍스트 + 지도 둘 다 OK
→ WebView 자체 문제가 아니라, 카카오 SDK 초기화/렌더링 문제

증상 C: Metro 로그로 단계 추적

로그	의미
`PAGE_BOOT`	main.js 실행됨
`SDK_LOADING`	SDK script 요청 시작
`SDK_SCRIPT_LOADED`	sdk.js 로드 완료
`MAP_INIT_START`	initMap 진입 시도
`MAP_INIT_POLL` + `hasMapCtor: false`	kakao.maps는 있는데 Map 생성자가 영원히 안 생김
`MAP_INIT_ATTEMPT` → `MAP_READY`	드디어 성공

3. 근본 원인

한 줄 요약

카카오 SDK 1차 스크립트(dapi.kakao.com)는 로드됐지만, Map 생성자를 등록하는 2차 모듈(daumcdn.net 등) 요청이 iOS WebView ATS에 막혔다.

SDK 로딩 2단계

1단계: sdk.js (dapi.kakao.com) → kakao.maps + load() 함수만 생김 ✅

2단계: 내부 모듈 (daumcdn.net) → kakao.maps.Map 생성자 등록 ❌ (ATS 차단)

그래서 디버그 로그가 이렇게 나왔다:

{

"hasKakao": true,

"hasMaps": true,

"hasMapCtor": false,

"hasLoad": true,

"mapsKeys": ["onloadcallbacks", "readyState", "load", "apikey", ...]

}

껍데기만 있고 Map이 없는 상태. kakao.maps.load() 콜백도 영원히 안 불림.

Safari vs RN WebView

	Safari	RN WebView (WKWebView)
sdk.js	✅	✅
daumcdn.net 모듈	✅	❌ (ATS)
kakao.maps.Map	✅	❌

같은 URL, 같은 HTML인데 WKWebView만 실패 → 네트워크 정책(ATS) 차이.

4. 해결 방법

핵심 fix: `app.json` ATS 설정

Expo app.json → prebuild → ios/Info.plist에 반영.

"NSAppTransportSecurity": {

"NSAllowsLocalNetworking": true,

"NSExceptionDomains": {

"kakao.com": {

"NSIncludesSubdomains": true,

"NSExceptionAllowsInsecureHTTPLoads": true,

"NSExceptionRequiresForwardSecrecy": false

"daum.net": { ... 동일 ... },

"daumcdn.net": { ... 동일 ... }

}

도메인	용도
`kakao.com`	SDK API (`dapi.kakao.com`)
`daum.net` / `daumcdn.net`	지도 타일·내부 모듈 CDN

Android 로컬 dev: "usesCleartextTraffic": true

네이티브 재빌드 필수

app.json 변경은 Metro reload로 반영 안 됨.

npx expo prebuild --clean --platform ios # Info.plist 재생성

npx expo run:ios --no-build-cache # 재빌드

--clear는 expo start 전용. run:ios는 --no-build-cache.

재빌드 후:

MAP_INIT_ATTEMPT → MAP_READY {"width":402,"height":690}

5. 디버깅 과정에서 시도했던 것들

효과 있었던 것

조치	효과
`app.json` ATS (daumcdn.net)	근본 해결
단계별 `postMessage` 로그	원인 좁히기 (hasMapCtor)
`main.js`에서 dynamic script load	HTML `onload` 속성보다 WebView에서 안정적
`#map` flex 100% + `map.relayout()`	레이아웃 이슈 예방
`domStorageEnabled` 등 WebView props	카카오맵 일반 권장 설정

효과 없었거나 2차적인 것

조치	판단
HTTP vs HTTPS 가설	로컬 HTTP 다른 앱은 WebView OK → 원인 아님
`messageQueue` / 폴링 / maps.load 재시도	ATS 해결 전엔 Map 자체가 안 생김
`autoload=true/false` 전환	ATS 없으면 둘 다 Map 안 생김
HTML

Eugenius1st.log

IoC(제어의 역전), DI(의존성 주입) 이해하기

IoC(제어의 역전), DI(의존성 주입) 이해하기

1. Spring의 IoC와 DI

💡 IoC, DI… 누구냐 넌?

2. 설계 원칙과 디자인 패턴

🧑‍🍳 김치볶음밥 맛있게 만드는 방법 — 설계 원칙

🍳 김치볶음밥 레시피 — 디자인 패턴

3. 좋은 코드를 위한 Spring의 IoC와 DI

4. 의존성이란?

💡 DI를 이해하려면 먼저 '의존성'을 이해해야 합니다.

4-1. Consumer와 Chicken의 강한 결합

5. Interface를 이용한 약한 결합

6. 주입이란?

💡 그렇다면 '주입'은 무엇일까요?

6-1. 필드에 직접 주입

6-2. 메서드를 통한 주입

6-3. 생성자를 통한 주입

7. 제어의 역전(IoC)이란?

💡 마지막으로 제어의 역전은 무엇일까요?

7-1. 의존성 주입을 사용하면?

8. IoC와 DI 정리

기존 방식

DI를 적용한 방식

⭐ 핵심 정리

데이터 설계와 연관관계

1. user관점에서 order 표현

2. order관점에서 user 표현

N:N 을 표현하는 설계 원칙

JPA Entity

핵심 어노테이션

네이밍 규칙

테이블명 단수VS복수

Entity 역할?

Repository

ORM과 Hibernate

ORM이란

Hibernate

JPA

ORM 트렌드

Entity

Layered 패턴

Layered 패턴

Layered 패턴이란, 이 일련의 행위를 3개로 나누는 것이다.

디렉토리 구조 예시

yml 파일

이상적인 개발 환경

build gradle

@Configuration

형상관리 파일

Spring

왜 스프링인가?

톰캣, 서블릿, 그리고 스프링 컨테이너의 구조

톰캣 (Tomcat) - 웹 서버 & 서블릿 컨테이너

전통적인 웹의 라우팅 방식(php)

서블릿

React Native + 카카오맵 웹뷰 삽질

HealingTrip 카카오맵 WebView 스터디

1. 배경 / 목표

아키텍처 원칙

구성

2. 겪었던 증상 (시간순)

증상 A: 빨간/빈 화면만 보임

증상 B: HTML/텍스트는 보이는데 지도만 안 보임

증상 C: Metro 로그로 단계 추적

3. 근본 원인

한 줄 요약

SDK 로딩 2단계

Safari vs RN WebView

4. 해결 방법

핵심 fix: app.json ATS 설정

네이티브 재빌드 필수

5. 디버깅 과정에서 시도했던 것들

효과 있었던 것

효과 없었거나 2차적인 것

핵심 fix: `app.json` ATS 설정