가장 크게 달라진 부분은 Repository 대신 MyBatis Mapper를 사용하여 데이터베이스와 통신한다는 점이다.

이전 프로젝트에서는 JdbcTemplate을 이용하여 Repository 안에서 SQL을 직접 실행하였다. 반면 이번 프로젝트에서는 Mapper 인터페이스만 작성하고 SQL은 XML에서 관리하도록 구조가 변경되었다.

또한 Service 계층에서는 단순히 Mapper를 호출하는 것이 아니라 DTO와 Entity를 변환하고 필요한 비즈니스 로직을 수행하는 역할을 담당하였다.

이번 파트에서는 Mapper와 Service가 실제로 어떻게 동작하는지를 중심으로 정리하였다.

BoardMapper

📚 이전 프로젝트와 달라진 점

Repository 클래스가 없어지고 Mapper 인터페이스가 데이터 접근을 담당하게 되었다.

Mapper Interface

@Mapper
public interface BoardMapper {

    int insert(Board board);

    List<Board> findAll();

    Board findById(long id);

    int update(Board board);

    int delete(long id);
}

Mapper에는 SQL이 존재하지 않는다.

메서드만 선언하면 MyBatis가 XML에 작성된 SQL과 연결하여 실행한다.

MyBatis 내부 동작

BoardService

↓

BoardMapper.insert()

↓

MyBatis

↓

BoardMapper.xml

↓

INSERT SQL 실행

↓

Database

즉, 우리가 호출하는 것은 인터페이스의 메서드이지만 실제 실행은 XML에 작성된 SQL이 담당한다.

Spring은 실행 시 Mapper 인터페이스의 구현 객체(Proxy)를 자동으로 생성하여 주입한다.

따라서 개발자는 구현 클래스를 직접 만들 필요가 없다.

BoardService

Service의 역할

이번 프로젝트에서도 Service의 역할은 이전 프로젝트와 동일하다.

• Controller와 Mapper 연결
• 비즈니스 로직 수행
• DTO ↔ Entity 변환

하지만 Repository 대신 Mapper를 호출한다는 점이 달라졌다.

게시글 생성

public void create(BoardFormDTO dto) {
    boardMapper.insert(dto.toEntity());
}

Service에서는

BoardFormDTO

↓

toEntity()

↓

Board Entity

↓

BoardMapper.insert()

순서로 처리된다.

DTO 내부의 toEntity()를 이용하여 Entity를 만든 뒤 Mapper에 전달한다.

게시글 조회

조회에서는 조금 다른 흐름을 사용한다.

return boardMapper.findAll()
        .stream()
        .map(BoardViewDTO::fromEntity)
        .toList();

Stream API 활용

조회 결과는

List<Board>

이다.

하지만 화면에서는

List<BoardViewDTO>

가 필요하다.

그래서 Stream API를 이용하여

List<Board>

↓

stream()

↓

BoardViewDTO.fromEntity()

↓

List<BoardViewDTO>

로 변환한다.

기존 프로젝트에서는 반복문을 사용할 수도 있었지만, Stream API를 사용하면 객체 변환을 더 간결하게 작성할 수 있다.

게시글 수정

수정 과정은 다음과 같다.

게시글 조회

↓

Entity 수정

↓

Mapper.update()

코드를 보면

Board board = boardMapper.findById(id);

board.setTitle(dto.title());

boardMapper.update(board);

기존 데이터를 조회한 뒤 필요한 값만 변경하여 다시 저장하는 방식이다.

MemberMapper

MemberMapper에서 흥미로운 점은

List<MemberViewDTO> findAll();

이다.

BoardMapper는 Entity를 반환하지만,

MemberMapper는 처음부터 DTO를 반환한다.

즉,

Database

↓

MyBatis

↓

MemberViewDTO

로 바로 변환된다.

필드명이 동일하면 MyBatis가 자동으로 DTO에 값을 매핑할 수 있기 때문에 가능한 방식이다.

MemberService

MemberService 역시 구조는 동일하다.

memberMapper.insert(dto.toEntity());

입력 DTO를 Entity로 변환한 뒤 Mapper를 호출한다.

조회는

return memberMapper.findAll();

한 줄로 처리된다.

MemberMapper가 DTO를 바로 반환하기 때문에 Service에서 별도의 변환 과정이 필요하지 않다.

이 부분은 BoardService와 비교했을 때 가장 큰 차이점이다.

Board와 Member의 차이

같은 MyBatis를 사용하더라도 설계 방식에 따라 구현이 달라질 수 있다는 점을 확인하였다.

이번 프로젝트에서 새롭게 이해한 점

느낀 점

이번 프로젝트를 통해 MyBatis는 단순히 SQL을 실행하는 라이브러리가 아니라, Mapper 인터페이스와 XML을 연결하여 데이터 접근을 추상화하는 프레임워크라는 점을 이해하게 되었다. 또한 Board와 Member의 구현 방식을 비교하면서 항상 하나의 방식만 사용하는 것이 아니라, 상황에 따라 Entity를 반환한 뒤 Service에서 DTO로 변환할지, Mapper에서 DTO를 직접 반환할지 선택할 수 있다는 점도 새롭게 배울 수 있었다.

이전 Spring JDBC 프로젝트에서 사용했던 JdbcTemplate 대신 MyBatis Framework를 적용하여 게시판과 회원 관리 기능을 구현하였다.

기존 프로젝트에서는 Repository에서 SQL을 직접 작성하고 JdbcTemplate을 통해 실행했지만, 이번 프로젝트에서는 Mapper 인터페이스와 XML 매핑을 이용하여 SQL과 Java 코드를 분리하였다.

MVC 구조는 이전 프로젝트와 동일하지만, 데이터 접근 계층이 Repository에서 Mapper로 변경되면서 코드가 더욱 간결해졌고 SQL 관리도 쉬워졌다.

MyBatis를 사용하는 이유와 기존 프로젝트와 달라진 점도 중심으로 정리하였다.

MyBatis를 사용하는 이유

기존 프로젝트에서는 Repository 안에서 SQL을 작성하고 JdbcTemplate을 호출하였다.

이번 프로젝트에서는 Mapper 인터페이스만 작성하고 실제 SQL은 XML 파일에서 관리한다.

이처럼 Java 코드와 SQL을 분리하면 유지보수가 훨씬 쉬워진다.

프로젝트 구조 변화

기존 프로젝트

Controller
      ↓
Service
      ↓
Repository
      ↓
JdbcTemplate
      ↓
Database

이번 프로젝트

Controller
      ↓
Service
      ↓
Mapper
      ↓
MyBatis
      ↓
Database

기존 Repository가 담당하던 데이터 접근 역할을 MyBatis의 Mapper가 대신하게 되었다.

Controller 구조는 그대로 유지된다.

MVC 구조 자체는 이전 프로젝트와 동일하다.

BoardController 역시 요청을 받은 뒤 Service를 호출하고 결과를 View에 전달하는 역할만 수행한다.

@PostMapping
public String create(@ModelAttribute BoardFormDTO dto) {
    boardService.create(dto);
    return "redirect:/";
}

Controller는 게시글 저장 방법이나 SQL을 알지 못한다.

오직

• 요청 받기
• Service 호출
• View 반환

세 가지 역할만 담당한다.

이처럼 Controller가 데이터 처리 로직을 가지지 않는 점은 이전 프로젝트와 동일하지만, 내부적으로 Repository 대신 Mapper를 사용한다는 점이 가장 큰 차이이다.

게시글 조회 흐름

브라우저

↓

BoardController

↓

BoardService

↓

BoardMapper

↓

MyBatis

↓

Database

조회 결과는 다시

Database

↓

BoardMapper

↓

BoardService

↓

BoardController

↓

JSP

순서로 사용자에게 전달된다.

MVC 구조는 그대로 유지되면서도 데이터 접근 방식만 변경되었다는 점을 확인할 수 있었다.

MainController의 변화

MainController는 게시글 목록을 조회하는 기능을 담당한다.

model.addAttribute(
    "boards",
    boardService.findAll()
);

이 코드 역시 이전 프로젝트와 거의 동일하다.

달라진 점은 findAll() 내부 구현이다.

이전에는 Repository가 JdbcTemplate을 이용하여 조회했지만,

이번에는

BoardMapper.findAll()

↓

MyBatis

↓

SQL 실행

과정으로 변경되었다.

Controller 입장에서는 구현 방식이 변경되어도 동일한 메서드만 호출하면 된다.

MemberController 추가

이번 프로젝트에서는 게시판뿐 아니라 회원 관리 기능도 함께 구현하였다.

MemberController 역시 동일한 구조를 따른다.

@PostMapping
public String save(MemberFormDTO dto) {
    memberService.create(dto);
    return "redirect:/mem";
}

게시글과 회원 기능이 모두 같은 MVC 패턴을 사용하기 때문에 새로운 기능을 추가하더라도 프로젝트 구조가 일관되게 유지된다.

DTO 사용 방식의 변화

이번 프로젝트에서도 DTO를 사용하지만,

이전 프로젝트보다 변환 책임이 더 명확하게 분리되었다.

예를 들어 BoardFormDTO에는

public Board toEntity()

메서드가 존재한다.

즉,

사용자 입력

↓

BoardFormDTO

↓

toEntity()

↓

Board Entity

변환이 DTO 내부에서 이루어진다.

반대로 조회에서는

BoardViewDTO.fromEntity(...)

를 이용하여 Entity를 화면에 필요한 DTO로 변환한다.

Board Entity

↓

fromEntity()

↓

BoardViewDTO

이처럼 입력과 출력의 변환을 DTO가 직접 담당하도록 구성된 점이 이전 프로젝트보다 더 명확해졌다.

이번 프로젝트에서 새롭게 이해한 점

느낀 점

Spring MVC 구조는 이전 프로젝트와 크게 달라지지 않았지만, 데이터 접근 계층이 Repository에서 Mapper로 변경된 것만으로도 코드가 훨씬 단순해졌다. 특히 SQL을 Java 코드에서 직접 작성하지 않고 XML에서 관리하는 방식은 유지보수 측면에서 큰 장점이 있다는 것을 이해할 수 있었다.

또한 BoardFormDTO의 toEntity()와 BoardViewDTO의 fromEntity()를 통해 입력과 출력 데이터를 명확하게 분리하는 구조를 다시 확인하면서, 객체 간 책임을 나누는 설계가 프로젝트의 확장성과 가독성을 높여준다는 점을 체감하였다.

단순히 계좌 정보를 조회하거나 저장하는 기능을 구현하는 것을 넘어, Spring MVC의 전체 요청 처리 과정을 직접 구현하였다. 사용자가 브라우저에서 요청을 보내면 Controller가 이를 받아 Service를 호출하고, Service는 Repository를 통해 데이터베이스와 통신한 뒤 결과를 다시 Controller와 View(JSP)로 전달하는 전체 흐름을 경험할 수 있었다.

또한 DTO와 Entity를 분리하고, Repository 패턴과 Service 계층을 적용하면서 객체지향 설계 원칙(SRP, 역할 분리)이 실제 프로젝트에서 왜 중요한지 이해할 수 있었다.

이번 실습은 Spring Framework가 단순히 코드를 줄여주는 프레임워크가 아니라, 유지보수성과 확장성을 고려한 구조를 제공하는 프레임워크라는 점을 배우는 과정이었다.

프로젝트 전체 실행 흐름

프로젝트 구조

Browser

↓

DispatcherServlet

↓

Controller

↓

Service

↓

Repository

↓

Database

↓

Repository

↓

Service

↓

Controller

↓

JSP

↓

Browser

이번 프로젝트는 모든 요청이 위 구조를 따라 처리된다.

계좌 생성(Create)

사용자가

이름 입력

↓

등록 버튼 클릭

을 수행하면

다음과 같은 과정이 실행된다.

HTML Form

↓

POST /

↓

MainController

↓

AccountFormDTO 생성

↓

BankService.makeAccount()

↓

Account Entity 생성

↓

Repository.save()

↓

JdbcTemplate.update()

↓

INSERT SQL

↓

Database

내부 동작 설명

Controller에서는

@ModelAttribute

를 통해 HTML Form 데이터를 AccountFormDTO로 자동 변환한다.

Service에서는 DTO를 Entity로 변환한 뒤 Repository에 저장을 요청한다.

Repository에서는

INSERT INTO accounts(name)
VALUES(?)

를 JdbcTemplate로 실행하여 데이터베이스에 저장한다.

계좌 조회(Read)

조회는 다음과 같이 진행된다.

GET /account/3

↓

AccountController

↓

findAccount()

↓

Repository.findById()

↓

SELECT SQL

↓

Database

↓

Account Entity

↓

AccountViewDTO

↓

Model

↓

account.jsp

Repository는 Entity를 반환하고,

Service는

AccountViewDTO.fromEntity(...)

를 이용하여 화면에 필요한 DTO로 변환한다.

계좌 수정(Update)

수정은 조회보다 조금 더 많은 단계가 존재한다.

사용자 입력

↓

POST /account/{id}

↓

Controller

↓

AccountUpdateDTO

↓

Repository.findById()

↓

Entity 수정

↓

Repository.update()

↓

UPDATE SQL

↓

Database

Service에서는

먼저 기존 Entity를 조회한다.

그 이후

account.setName(...)

으로 값을 변경한 뒤

Repository.update()를 호출한다.

계좌 삭제(Delete)

삭제 과정은 가장 단순하다.

GET /account/3/delete

↓

Controller

↓

Service

↓

Repository

↓

DELETE SQL

↓

Database

Repository에서는

DELETE FROM accounts
WHERE id=?

를 수행한다.

MVC 전체 요청 흐름

브라우저

↓

DispatcherServlet

↓

Controller

↓

Service

↓

Repository

↓

JdbcTemplate

↓

Database

↓

Repository

↓

Service

↓

Controller

↓

Model

↓

JSP

↓

브라우저

이 흐름이 Spring MVC 프로젝트의 핵심이라는 것을 이해하였다.

계층별 역할

각 계층이 자신의 역할만 수행하도록 설계되어 있기 때문에 유지보수가 쉬워진다.

Spring MVC를 사용하는 이유

느낀 점

배운 점

📌 최종 정리

이번 Spring MVC 프로젝트는 단순히 CRUD 기능을 구현하는 것이 아니라 웹 애플리케이션이 요청을 처리하는 전체 구조를 이해하는 과정이었다. Controller는 사용자의 요청을 받아 적절한 Service를 호출하고, Service는 비즈니스 로직을 수행하며 Repository를 통해 데이터베이스와 통신한다. Repository는 JdbcTemplate을 활용하여 SQL을 실행하고, 조회한 Entity는 필요한 정보만 담은 DTO로 변환되어 다시 Controller와 JSP로 전달된다.

이번 실습을 통해 Controller → Service → Repository → Database라는 계층형 구조와 MVC 패턴의 장점을 체감할 수 있었으며, 역할을 명확히 분리하는 설계가 유지보수성과 확장성을 높인다는 점을 이해하게 되었다. 또한 DTO와 Entity를 분리하고 JdbcTemplate, RowMapper, @Transactional을 활용하는 방법을 익히면서 앞으로 Spring Data JPA, MyBatis, 대규모 Spring Boot 프로젝트를 학습하는 데 필요한 핵심 기반을 다질 수 있었다.

Repository와 Service 계층을 분리하여 사용하는 이유를 학습하였다. 이전 JDBC 프로젝트에서는 Main 클래스가 Repository를 직접 호출하여 데이터를 처리했지만, 이번 프로젝트에서는 Controller → Service → Repository 구조를 적용하여 계층별 역할을 명확하게 분리하였다.

또한 JdbcTemplate과 RowMapper를 이용하여 기존 JDBC 코드보다 훨씬 간결하게 데이터베이스를 다루는 방법을 익혔으며, @Transactional을 통해 여러 작업을 하나의 트랜잭션으로 관리하는 방법도 함께 학습하였다.

그리고 Spring은 단순히 JDBC를 대신해 주는 프레임워크가 아니라 객체 간의 역할을 명확하게 나누고 유지보수성을 높여주는 구조를 제공하는 프레임워크라는 점을 이해하게 되었다.

1) AccountRepository

public interface BankAccountRepository {

    void save(Account account);

    void update(Account account);

    List<Account> findAll();

    Account findById(long id);

    void deleteById(long id);

}

이번 프로젝트에서는 Repository를 인터페이스로 먼저 작성하였다.

인터페이스에는

• 저장
• 조회
• 수정
• 삭제

기능만 정의하였다.

실제 SQL은 작성하지 않는다.

즉,

무엇을 할 것인가

만 정의한다.

실제로

어떻게 할 것인가

는 구현 클래스가 담당한다.

인터페이스를 사용하는 이유

예를 들어

현재는

SQLAccountRepository

를 사용하지만

나중에는

MongoRepository

또는

RedisRepository

로 변경할 수도 있다.

Controller와 Service는

Repository가 어떻게 구현되어 있는지 알 필요가 없다.

오직

save()

findAll()

findById()

만 알고 있으면 된다.

Repository 추상화 구조

Controller

↓

Service

↓

AccountRepository

↓

SQLAccountRepository

이러한 구조를

다형성(Polymorphism)

이라고 한다.

2) SQLAccountRepository

@Repository
@RequiredArgsConstructor
public class SqlAccountRepository
        implements AccountRepository {

    private final JdbcTemplate jdbcTemplate;

}

기존 JDBC에서는

Connection

PreparedStatement

ResultSet

을 모두 직접 생성해야 했다.

하지만 Spring에서는

JdbcTemplate

하나만 있으면

이 모든 과정을 내부에서 자동으로 처리해 준다.

즉,

개발자는

SQL만 작성하면 된다.

JdbcTemplate 내부 동작

JdbcTemplate

↓

Connection 생성

↓

PreparedStatement 생성

↓

SQL 실행

↓

ResultSet 반환

↓

Connection 종료

이 과정을 Spring이 모두 대신 수행한다.

INSERT

jdbcTemplate.update(query, account.getName());

update() 메서드는

INSERT

UPDATE

DELETE

모두 수행할 수 있다.

반환값은

영향 받은 행(Row)의 개수이다.

SELECT

여러 개 조회

jdbcTemplate.query()

한 개 조회

jdbcTemplate.queryForObject()

를 사용하였다.

RowMapper

Repository에는

private static final RowMapper<Account>

가 존재한다.

RowMapper는

ResultSet을

객체로 변환하는 역할을 수행한다.

즉,

ResultSet

↓

Account 객체

변환기 역할을 한다.

RowMapper 흐름

SELECT

↓

ResultSet

↓

RowMapper

↓

Account

↓

List<Account>

JdbcTemplate의 장점

3) BankService & BankServiceImpl

@Service
@RequiredArgsConstructor
public class BankServiceImpl implements BankService{

    private final AccountRepository repository;

}

Service는

Controller와 Repository 사이에서

중간 역할을 수행한다.

즉,

Controller는

Repository를 모른다.

Repository 역시

Controller를 모른다.

둘 사이를

Service가 연결한다.

Service 흐름

Controller

↓

BankService

↓

Repository

계좌 생성

Account account =
        Account.builder()

        .name(dto.name())

        .build();

FormDTO를

Entity로 변환하였다.

그 이후

repository.save(account);

를 호출한다.

계좌 조회

Repository는

Entity를 반환한다.

하지만

Controller는

ViewDTO를 원한다.

그래서

AccountViewDTO.fromEntity(...)

를 호출하여

DTO로 변환하였다.

계좌 수정

수정 과정은

조금 더 복잡하다.

DTO

↓

Repository.findById()

↓

Entity

↓

이름 변경

↓

Repository.update()

즉,

기존 Entity를 조회한 뒤

필드만 변경하여

Repository에게 전달한다.

@Transactional

@Transactional

은

여러 작업을

하나의 작업처럼 처리한다.

예를 들어

계좌 생성

↓

로그 저장

↓

알림 발송

세 작업 중

하나라도 실패하면

모두 취소된다.

이를

Rollback이라고 한다.

Transaction 흐름

BEGIN

↓

SQL1

↓

SQL2

↓

SQL3

↓

COMMIT

(실패 시 ROLLBACK)

Service 계층을 사용하는 이유

Service를 분리하면

Controller가 훨씬 단순해지고

비즈니스 로직을 한곳에서 관리할 수 있다.

느낀 점

Spring MVC 프로젝트에서 Entity와 DTO(Data Transfer Object)를 분리하여 사용하는 이유를 학습하였다. 이전 JDBC 프로젝트에서는 Repository가 반환한 Entity를 그대로 사용하였지만, 이번 프로젝트에서는 사용 목적에 따라 AccountFormDTO, AccountUpdateDTO, AccountViewDTO를 각각 따로 만들어 사용하였다.

사용자의 입력을 받는 객체와 화면에 보여주는 객체, 그리고 실제 데이터베이스에 저장되는 객체는 서로 역할이 다르다는 점을 이해하게 되었다.

또한 Java Record를 이용하여 DTO를 작성하면서 불필요한 코드를 줄이고, Builder Pattern을 이용해 Entity를 생성하는 방법도 함께 익힐 수 있었다.

1) Account(Entity)

@Getter
@Setter
@Builder
public class Account {

    private long accountId;

    private String accountName;

    private String createdDate;

}

Account Entity는 데이터베이스의 accounts 테이블과 대응되는 객체이다.

예를 들어 데이터베이스에 다음과 같은 데이터가 있다고 가정해 보자.

Repository가 이 데이터를 조회하면 다음과 같은 객체가 만들어진다.

Account account = Account.builder()
        .id(1L)
        .name("홍길동")
        .createdAt("2026-07-20")
        .build();

Entity는 데이터베이스의 실제 데이터를 표현하는 객체이기 때문에 CRUD 과정에서 가장 많이 사용된다.

이번 프로젝트에서는 Lombok의 @Builder를 활용하여 객체를 생성하였다.

Builder Pattern을 사용하면 생성자의 매개변수 순서를 기억할 필요가 없으며, 필요한 값만 선택적으로 설정할 수 있어 코드의 가독성이 크게 향상된다.

Entity의 역할

Database

↓

Account(Entity)

↓

Repository

↓

Service

Entity는 항상 Repository와 Service 사이에서 실제 데이터를 전달하는 역할을 수행한다.

Builder Pattern을 사용하는 이유

2) AccountFormDTO & AccountUpdateDTO

📚 오늘 배운 내용

public record AccountCreateDTO(
        String accountName
) {
}

public record AccountModifyDTO(

        long accountId,

        String accountName

) {
}

DTO를 하나만 사용하지 않고 용도에 따라 분리하였다.

1. 계좌 생성

계좌를 생성할 때는 사용자가 입력하는 값이 이름뿐이다.

이름 입력

↓

AccountFormDTO

따라서 id는 필요하지 않다.

2. 계좌 수정

수정은 다르다.

어떤 계좌를 수정할지 알아야 하기 때문에

id

+

변경할 이름

두 정보가 모두 필요하다.

그래서

AccountUpdateDTO

를 별도로 만들었다.

이처럼 작업 목적에 따라 DTO를 분리하면 필요한 데이터만 전달할 수 있어 코드가 더욱 명확해진다.

DTO를 분리하는 이유

각 DTO는 하나의 목적만 수행하도록 설계하였다.

Record를 사용하는 이유

DTO는 데이터를 저장하고 전달하는 역할만 수행한다.

따라서

• Getter
• equals()
• hashCode()
• toString()

이 자동 생성되는 Record가 매우 적합하다.

코드도 훨씬 간결해진다.

실무에서도 요청(Request)마다 DTO를 분리하는 경우가 많다.

예를 들어 회원 기능이라면 다음과 같이 구성할 수 있다.

• MemberCreateRequest
• MemberUpdateRequest
• MemberLoginRequest
• MemberResponse

하나의 DTO를 재사용하기보다 기능별로 DTO를 분리하여 관리하는 것이 일반적이다.

3) AccountViewDTO

public static AccountViewDTO fromEntity(Account entity){

    return new AccountViewDTO(

            entity.getId(),

            entity.getName(),

            entity.getCreatedAt()

    );

}

Service에서는 Repository가 반환한 Entity를 그대로 JSP에 전달하지 않는다.

대신

Entity

↓

ViewDTO

↓

JSP

순서로 변환한다.

이 과정을 담당하는 메서드가

fromEntity()

이다.

즉,

Account

객체를

AccountViewDTO

로 변환하는 역할을 수행한다.

왜 Entity를 직접 넘기지 않을까?

예를 들어 Entity에 다음과 같은 정보가 추가되었다고 가정해 보자.

• password
• 주민등록번호
• 계좌 비밀번호

이 객체를 그대로 View에 전달하면 민감한 정보가 노출될 수 있다.

하지만 ViewDTO에는 필요한 데이터(id, name, createdAt)만 담기므로 불필요한 정보의 노출을 막을 수 있다.

Entity와 DTO의 관계

Database

↓

Entity

↓

Repository

↓

Service

↓

ViewDTO

↓

Controller

↓

JSP

느낀점

기존 JDBC 프로젝트를 Spring Framework 기반으로 발전시키면서 Spring MVC(Model-View-Controller) 구조를 직접 구현해 보았다. 이전에는 main() 메서드에서 직접 Repository를 호출하여 CRUD를 수행했지만, 이번 프로젝트에서는 Controller → Service → Repository 구조를 적용하여 각 계층의 역할을 분리하였다.

또한 JSP를 View로 사용하면서 사용자의 요청(Request)이 어떻게 Controller로 전달되고, Controller가 Service와 Repository를 거쳐 데이터를 조회한 후 다시 View로 전달하는지 전체적인 흐름을 이해할 수 있었다.

Spring Boot를 사용할 때는 이러한 과정이 자동으로 이루어진다고만 생각했는데, 이번 실습을 통해 MVC 패턴이 왜 필요한지, 그리고 각 계층이 어떤 역할을 수행하는지를 보다 깊게 이해할 수 있었다.

1) MainController

@Controller
@RequestMapping("/")
@RequiredArgsConstructor
public class MainController {

    private final BankService bankService;

    @GetMapping("/")
    public String index(Model model){

        model.addAttribute(
                "accounts",
                bankService.getAccounts()
        );

        return "index";

    }

}

이번 실습에서는 사용자가 브라우저에서

http://localhost:8080/

를 요청하면

가장 먼저 DispatcherServlet이 요청을 받는다.

DispatcherServlet은

"/"

URL을 처리할 Controller를 찾는다.

그 결과

@GetMapping("/")

이 실행된다.

Controller에서는

bankService.getAccounts();

를 호출하여

Service에게

"전체 계좌 목록을 가져와."

라고 요청한다.

Controller는

SQL을 작성하지 않는다.

DB와 직접 연결하지도 않는다.

오직

사용자의 요청을 받고

Service를 호출한 뒤

결과를 View로 전달하는 역할만 수행한다.

조회된 데이터는

model.addAttribute()

를 이용하여

JSP에게 전달된다.

model.addAttribute(
        "accounts",
        bankService.getAccounts()
);

Model 객체는

일종의

Map<String,Object>

처럼 동작한다.

즉,

accounts

라는 이름으로

JSP에게 데이터를 전달하는 것이다.

JSP에서는

${accounts}

를 이용하여 사용할 수 있다.

마지막으로

return "index";

를 반환하면

ViewResolver가

/WEB-INF/views/index.jsp

를 찾아 사용자에게 화면을 보여준다.

Spring MVC 요청 흐름

브라우저

↓

DispatcherServlet

↓

MainController

↓

BankService

↓

Repository

↓

Database

↓

Repository

↓

Service

↓

Controller

↓

Model

↓

index.jsp

↓

브라우저

이번 실습을 통해

Spring MVC는

각 객체가 자신의 역할만 수행하도록 설계되어 있다는 점을 이해하였다.

POST 요청

@PostMapping("/")

에서는

새로운 계좌를 생성한다.

bankService.makeAccount(dto);

가 호출되면

Service가 Repository에게

INSERT를 요청한다.

그리고

return "redirect:/";

를 수행한다.

Redirect를 사용하는 이유

처음에는

왜

return "index";

를 하지 않고

redirect:/

를 사용하는지 이해되지 않았다.

하지만

POST 요청 후

바로 JSP를 반환하면

새로고침(F5)을 했을 때

POST 요청이 다시 실행된다.

즉,

계좌가

두 번 생성될 수 있다.

이를

중복 제출(Double Submit)

문제라고 한다.

그래서

POST가 끝나면

다시

GET 요청을 보내도록

Redirect를 사용하는 것이다.

이를

PRG(Post Redirect Get) 패턴

이라고 한다.

2) AccountController

@GetMapping("/{accountId}")
public String showAccount(
        @PathVariable long accountId,
        Model model
){

    AccountViewDTO accountDto =
            bankService.findAccount(accountId);

    model.addAttribute(
            "account",
            accountDto
    );

    return "account";

}

이번 Controller에서는

URL에 포함된 값을

직접 변수로 받아왔다.

예를 들어

/account/3

이라는 요청이 들어오면

Spring은

@PathVariable long accountId

에

자동으로

3

을 넣어준다.

즉,

개발자가

직접

request.getParameter()

를 사용할 필요가 없다.

Spring이 자동으로 처리해준다.

수정 기능에서는

@ModelAttribute

를 사용하였다.

@PostMapping("/{id}")

↓

사용자가 입력한

name=홍길동

↓

Spring

↓

AccountFormDTO

자동 생성

↓

Service 호출

이 과정이 자동으로 이루어진다.

삭제 기능 역시

@GetMapping("/{id}/delete")

를 이용하여

Repository에게

삭제를 요청한다.

Controller는

삭제 SQL을 작성하지 않는다.

Service에게

삭제를 요청할 뿐이다.

Account 수정 흐름

사용자

↓

account.jsp

↓

POST /account/3

↓

AccountController

↓

BankService

↓

Repository

↓

UPDATE SQL

↓

DB

↓

Redirect

↓

GET /account/3

Spring MVC가 편리한 이유

예전 JDBC에서는

Scanner scanner

로 데이터를 입력받았다.

하지만

Spring에서는

HTML Form만 작성하면

자동으로

DTO 객체가 생성된다.

즉,

사용자 입력을

직접 파싱할 필요가 없다.

느낀 점

앞에서 학습한 Driver Loading, Connection 생성, SQL 실행, Repository 패턴을 하나로 연결하여 CRUD(Create, Read, Update, Delete) 기능을 직접 수행하였다. 단순히 SQL을 실행하는 것이 아니라 사용자의 입력을 받아 데이터를 저장하고, 조회한 데이터를 수정한 뒤 삭제하는 일련의 과정을 경험하면서 JDBC가 실제 애플리케이션에서 어떻게 사용되는지 이해할 수 있었다.

데이터베이스와 객체를 연결하는 전체 흐름을 처음부터 끝까지 직접 구현해 보면서 Spring Boot와 JPA가 내부적으로 수행하는 역할을 더욱 명확하게 이해할 수 있었다.

1) MyCRUD

public class CrudExample {

    public static void main(String[] args) {

        BanchanRepository repository = new BanchanRepository();

        Scanner inputScanner = new Scanner(System.in);

        System.out.print("추가할 반찬 이름 : ");

        String menuName = inputScanner.nextLine();

        repository.save(new SideDish(0, menuName));

        List<SideDish> dishes = repository.findAll();

        System.out.println(dishes);

    }

}

이번 프로그램은 CRUD를 하나의 흐름으로 연결하였다.

가장 먼저 Repository 객체를 생성하였다.

BanchanRepository repository =
        new BanchanRepository();

Repository는

• INSERT
• SELECT
• UPDATE
• DELETE

모든 SQL을 담당한다.

따라서 Main에서는 SQL을 작성하지 않는다.

객체지향적으로 역할을 분리한 것이다.

다음으로 Scanner를 이용하여

사용자의 입력을 받았다.

Scanner inputScanner =
        new Scanner(System.in);

입력받은 문자열은

repository.save(...)

를 호출하면서 데이터베이스에 저장된다.

Main 클래스는

저장 방법을 모른다.

단지 Repository에게

"저장해줘"

라고 요청만 한다.

이것이 Repository 패턴의 가장 큰 장점이라는 것을 이해하였다.

CRUD 실행 과정

사용자 입력

↓

Scanner

↓

Repository.save()

↓

PreparedStatement

↓

INSERT SQL 실행

↓

Database 저장

프로그램은 이 순서대로 동작한다.

조회(Read)

데이터 저장 후

List<SideDish> dishes =
        repository.findAll();

을 호출하였다.

Repository는

SELECT 문을 실행하고

ResultSet을 읽은 뒤

Record 객체를 생성하여

List로 반환한다.

Main에서는

SQL이 어떻게 실행되는지 전혀 알 필요가 없다.

수정(Update)

수정 과정에서는

먼저

repository.findById(...)

를 호출하였다.

조회한 데이터를 이용하여

새로운 Record를 생성하였다.

SideDish updatedDish =
        new SideDish(

                oldDish.id(),

                oldDish.name() + "(수정)"

        );

그 이후

repository.update(updatedDish);

를 호출하여

데이터를 수정하였다.

삭제(Delete)

삭제는

repository.deleteById(id);

한 줄로 수행하였다.

Repository 내부에서는

DELETE SQL이 실행된다.

삭제가 성공하면

executeUpdate()

반환값이

1이 된다.

실패하면

0이 된다.

이를 이용하여

삭제 성공 여부를 확인할 수 있다는 점을 배웠다.

CRUD 전체 흐름

사용자 입력

↓

Main

↓

Repository

↓

DBUtil

↓

Connection

↓

PreparedStatement

↓

Database

↓

ResultSet

↓

Repository

↓

Main

↓

사용자 출력

이번 실습을 통해

JDBC는 단순히 SQL을 실행하는 기술이 아니라

각 객체들이 서로 역할을 분담하며 하나의 흐름으로 동작한다는 점을 이해하였다.

객체지향 관점에서 본 구조

객체마다 역할을 분리하였기 때문에

유지보수가 쉬워지는 구조라는 것을 느꼈다.

느낀 점

여러 실습을 반복하면서 JDBC의 전체 흐름을 하나의 그림으로 정리하니 각 객체의 역할이 명확하게 구분되었다.

Driver Loading

↓

Connection 생성

↓

PreparedStatement 생성

↓

SQL 실행

↓

ResultSet 반환

↓

객체 생성

↓

Repository 반환

↓

Main 출력

이 흐름을 기준으로 코드를 다시 읽어보니, 이전에는 각각 독립적으로 보였던 클래스들이 하나의 과정 안에서 서로 협력하고 있다는 점을 이해할 수 있었다.

또한 PreparedStatement는 SQL과 데이터를 분리하여 SQL Injection을 방지하고, Repository는 데이터 접근을 담당하며, DBUtil은 연결을 생성하는 역할만 수행하는 등 각 클래스가 하나의 책임만 가지도록 설계되어 있다는 사실도 배울 수 있었다.

📌 최종 정리

이번 JDBC 학습은 단순히 SQL을 실행하는 방법을 배우는 것이 아니라, 자바 애플리케이션이 데이터베이스와 어떻게 통신하는지에 대한 전체 흐름을 이해하는 과정이었다. Driver를 로딩하여 연결을 준비하고, DBUtil을 통해 Connection을 생성하며, PreparedStatement로 안전하게 SQL을 실행하고, ResultSet을 객체로 변환하여 Repository를 통해 반환하는 일련의 과정을 직접 구현하면서 데이터 접근 계층의 역할을 명확하게 이해할 수 있었다.

또한 CRUD 기능을 하나씩 구현하며 객체지향 설계와 Repository 패턴의 장점을 체감하였고, 이러한 구조가 이후 학습할 Spring Boot, MyBatis, Spring Data JPA에서도 동일한 개념으로 확장된다는 점을 알게 되었다.

단순히 SQL을 실행하는 단계에서 더 나아가 객체를 데이터베이스에 저장하고 관리하는 Repository 패턴을 구현해 보았다. 이전까지는 SELECT 문을 실행하여 데이터를 조회하는 것에 집중했다면, 이번에는 Create, Read, Update, Delete(CRUD)를 하나의 Repository 클래스에 모아 관리하면서 객체지향적인 데이터 접근 방식을 경험하였다.

또한 record를 이용하여 데이터를 표현하고, DBUtil 클래스로 데이터베이스 연결을 공통화하면서 유지보수성과 재사용성을 높이는 방법도 함께 학습하였다.

1) 객체 생성 (Record)

public record SideDish(
        long sideDishId,
        String sideDishName
) {
}

이번 실습에서는 Java의 Record를 이용하여 반찬 정보를 저장하는 객체를 생성하였다.

기존 클래스를 작성하려면 다음과 같은 코드가 필요하다.

• 필드 선언
• 생성자
• Getter
• equals()
• hashCode()
• toString()

하지만 Record는

public record SideDish(
        long sideDishId,
        String sideDishName
){}

한 줄만 작성하면 위 기능들이 자동으로 생성된다.

또한 Record는 생성 이후 값을 변경할 수 없기 때문에 데이터가 의도치 않게 수정되는 것을 방지할 수 있다.

특히 데이터베이스에서 조회한 데이터를 표현하는 객체는 대부분 값을 변경할 필요가 없기 때문에 Record가 매우 적합하다는 점을 알게 되었다.

기존 클래스와 Record 비교

왜 Record를 사용할까?

데이터를 저장하기 위한 객체는

• 데이터를 계산하는 기능보다
• 데이터를 전달하는 역할이 훨씬 많다.

따라서

"데이터만 표현하는 객체"

에는 Record가 가장 적합하다는 것을 배웠다.

2) DBUtil

public class DBConnectionUtil {

    private DBConnectionUtil(){}

    public static Connection openConnection()
            throws SQLException{

        Class.forName("org.postgresql.Driver");

        return DriverManager.getConnection(
                URL,
                USER,
                PASSWORD
        );

    }

}

DB 연결은 모든 Repository에서 공통적으로 수행된다.

만약 DB 연결 코드를

• 회원 Repository
• 게시판 Repository
• 주문 Repository

마다 작성한다면

동일한 코드가 수십 번 반복된다.

그래서

DBUtil

클래스를 만들어

Connection 생성 기능을 하나로 모아두었다.

이후에는

Connection conn = DBUtil.getConnection();

한 줄만 작성하면 된다.

이러한 구조는

유지보수성과 재사용성을 크게 높여준다.

Utility Class의 장점

환경 변수를 사용하는 이유

실습에서는

System.getenv()

를 사용하였다.

그 이유는

DB 비밀번호를

String PASSWORD="1234";

처럼 코드에 작성하면

GitHub에 업로드될 위험이 있기 때문이다.

환경 변수는 운영체제에 저장되므로

소스 코드가 공개되어도 비밀번호는 노출되지 않는다.

실무에서는

• Spring Boot
• application.yml
• DataSource
• HikariCP

를 이용하여 Connection을 관리하지만

결국 내부적으로는

DriverManager를 이용한 Connection 생성 과정을 거친다.

이번 실습은 그 원리를 직접 구현해본 경험이었다.

3) BanchanRepository

Repository 패턴이란?

Repository는

데이터베이스와 직접 통신하는 역할만 담당하는 클래스

이다.

즉,

Controller가 SQL을 직접 작성하지 않는다.

Service도 SQL을 작성하지 않는다.

오직 Repository만 SQL을 작성한다.

Repository 구조

Controller

      │

      ▼

Service

      │

      ▼

Repository

      │

      ▼

Database

이 구조를 사용하면

각 클래스의 역할이 명확하게 분리된다.

CRUD 구현

이번 Repository에서는

를 모두 구현하였다.

save() 구현 과정

객체 생성

↓

Connection 생성

↓

PreparedStatement 생성

↓

executeUpdate()

↓

COMMIT

데이터 저장은

SELECT가 아니라

INSERT 문을 실행하므로

executeUpdate()를 사용하였다.

update()

수정은

ID를 기준으로 수행하였다.

UPDATE banchan

SET name=?

WHERE id=?

ID가 동일한 데이터를 찾아

새로운 이름으로 변경하였다.

이 과정에서

Primary Key의 중요성을 이해할 수 있었다.

delete()

삭제 역시

ID를 이용하였다.

삭제 성공 여부는

executeUpdate()

가 반환하는

영향 받은 행(Row)의 개수로 확인하였다.

0이면

삭제 실패

1이면

삭제 성공이다.

Transaction을 사용하는 이유

이번 실습에서는

START TRANSACTION

↓

SQL 실행

↓

COMMIT

순서로 작성하였다.

트랜잭션은

여러 작업을 하나의 작업처럼 처리하기 위한 기능이다.

만약 중간에 오류가 발생하면

ROLLBACK을 수행하여

원래 상태로 되돌릴 수 있다.

CRUD 전체 흐름

사용자 요청

↓

Repository 호출

↓

Connection 생성

↓

PreparedStatement 생성

↓

SQL 실행

↓

ResultSet 또는 실행 결과 반환

↓

Connection 종료

이 흐름이

JDBC CRUD의 핵심이라는 것을 이해하였다.

느낀 점

데이터베이스에 연결한 이후 실제 SQL을 실행하는 방법을 학습하였다. 단순히 SQL을 실행하는 것에서 끝나는 것이 아니라 Statement와 PreparedStatement의 차이점, SQL Injection이 발생하는 이유, 그리고 조회 결과를 ResultSet으로 받아 객체로 변환하는 과정까지 직접 구현해보면서 JDBC의 핵심 기능을 이해할 수 있었다.

1) UseStatement

public class StatementExample {

    public static void main(String[] args) {

        String inputId = "1234' OR '1'='1";

        try (Connection connection = DBUtil.getConnection()) {

            String sql =
                    "SELECT * FROM users WHERE id = '%s'"
                            .formatted(inputId);

            Statement statement = connection.createStatement();

            ResultSet resultSet = statement.executeQuery(sql);

            while (resultSet.next()) {

                System.out.println(resultSet.getString("id"));
                System.out.println(resultSet.getString("name"));
                System.out.println(resultSet.getInt("age"));

            }

        } catch (SQLException e) {

            e.printStackTrace();

        }

    }

}

가장 먼저 사용자의 입력을 SQL 문자열 안에 직접 포함하였다.

String sql =
        "SELECT * FROM users WHERE id = '%s'"
                .formatted(inputId);

만약 사용자가

admin

을 입력하면 SQL은

SELECT * FROM users
WHERE id='admin'

이 된다.

하지만 실습에서는

1234' OR '1'='1

을 입력하였다.

그러면 실제 실행되는 SQL은

SELECT *
FROM users
WHERE id='1234'
OR '1'='1'

가 된다.

여기서

'1'='1'

은 항상 참(True)이므로 WHERE 조건이 모두 참이 되어 모든 사용자가 조회된다.

즉,

사용자의 입력이 데이터가 아니라 SQL 명령으로 실행되어 버린 것이다.

이것이 SQL Injection이다.

SQL Injection이 위험한 이유

Statement의 동작 과정

사용자 입력
      │
      ▼
SQL 문자열 생성
      │
      ▼
Statement
      │
      ▼
DB에서 SQL 그대로 실행
      │
      ▼
ResultSet 반환

Statement는 사용자가 입력한 문자열을 그대로 SQL로 해석하기 때문에 보안상 매우 위험하다.

2) UsePreparedStatement

public class PreparedExample {

    public static void main(String[] args) {

        String searchId = "1234' OR '1'='1";

        try (Connection connection = DBUtil.getConnection()) {

            String sql =
                    "SELECT * FROM users WHERE id = ?";

            PreparedStatement preparedStatement =
                    connection.prepareStatement(sql);

            preparedStatement.setString(1, searchId);

            ResultSet resultSet =
                    preparedStatement.executeQuery();

            while (resultSet.next()) {

                System.out.println(resultSet.getString("id"));
                System.out.println(resultSet.getString("name"));
                System.out.println(resultSet.getInt("age"));

            }

        } catch (SQLException e) {

            e.printStackTrace();

        }

    }

}

PreparedStatement는 SQL과 데이터를 분리한다.

String sql =
        "SELECT * FROM users WHERE id = ?";

여기서

?

는 아직 값이 없는 자리이다.

이후

preparedStatement.setString(1, searchId);

가 실행되면

사용자의 입력은 SQL이 아니라

단순 문자열 데이터

로 전달된다.

즉,

1234' OR '1'='1

이라는 문자열은

SQL 코드가 아니라

그냥 하나의 문자열로 인식된다.

따라서 SQL Injection이 발생하지 않는다.

Statement와 PreparedStatement 비교

내부 동작 과정

SQL 작성
SELECT * FROM users WHERE id = ?
            │
            ▼
SQL 먼저 컴파일
            │
            ▼
?에 값만 전달
            │
            ▼
DB 실행
            │
            ▼
ResultSet 반환

SQL 구조와 데이터가 분리되므로 매우 안전하다.

3) UseResultSet

record UserInfo(
        String userId,
        String userName,
        int userAge
) {}

PreparedStatement preparedStatement =
        connection.prepareStatement(sql);

ResultSet resultSet =
        preparedStatement.executeQuery();

while (resultSet.next()) {

    UserInfo userInfo =
            new UserInfo(

                    resultSet.getString("user_id"),
                    resultSet.getString("user_name"),
                    resultSet.getInt("user_age")

            );

    System.out.println(userInfo);

}

SELECT가 실행되면 ResultSet 객체가 생성된다.

ResultSet은

데이터 여러 개를 저장하는 것이 아니라

현재 한 행(Row)을 가리키는 커서(Cursor)를 가지고 있다.

처음에는

Before First

위치에 있다.

resultSet.next();

를 호출하면

첫 번째 행으로 이동한다.

다시 next()

↓

두 번째 행

↓

세 번째 행

↓

없으면 false

를 반환한다.

즉,

while(resultSet.next())

는

데이터가 존재하는 동안 반복하는 코드이다.

ResultSet 구조

Before First
      │
      ▼
첫 번째 행
      │
      ▼
두 번째 행
      │
      ▼
세 번째 행
      │
      ▼
After Last

Alias를 사용하는 이유

이번 실습에서는

SELECT

id AS user_id,
name AS user_name,
age AS user_age

FROM users

처럼 Alias를 사용하였다.

그 이유는

• 컬럼명이 겹칠 수 있기 때문
• JOIN 시 이름을 구분하기 위해
• 코드 가독성을 높이기 위해

이다.

Record를 사용하는 이유

조회 결과를

UserInfo

객체로 변환하였다.

객체를 사용하면

• 데이터 전달이 편리하다.
• 여러 값을 하나의 객체로 관리할 수 있다.
• 가독성이 좋아진다.

이는 이후 Repository 패턴에서도 동일하게 활용된다.

느낀 점

Java 프로그램과 데이터베이스를 연결하는 JDBC(Java Database Connectivity)의 가장 기본적인 동작 과정을 학습하였다. Driver를 직접 로딩하고 Connection 객체를 생성하면서 JDBC가 어떻게 동작하는지 이해할 수 있었다.

1) DriverLoading

public class DriverExample {

    public static void main(String[] args) {

        try {

            Class.forName("com.mysql.cj.jdbc.Driver");

            System.out.println("Driver Loading Success");

        } catch (ClassNotFoundException e) {

            System.out.println("Driver Loading Failed");
        }

    }

}

데이터베이스에 연결하기 전에 가장 먼저 JDBC Driver를 JVM에 등록하는 과정을 수행하였다.

Class.forName() 메서드는 문자열 형태로 전달받은 클래스를 메모리에 로드하는 기능을 수행한다.

Class.forName("com.mysql.cj.jdbc.Driver");

가 실행되면 MySQL Driver 클래스가 JVM에 로드되고 DriverManager 내부에 자동으로 등록된다.

이후 프로그램에서

DriverManager.getConnection(...)

을 호출하면 DriverManager는 현재 등록되어 있는 Driver들 중 연결 가능한 Driver를 찾아 데이터베이스 연결을 수행한다.

최근 JDBC에서는 Driver가 자동 등록되기 때문에 직접 호출하지 않아도 되는 경우가 많지만, 내부 동작 원리를 이해하기 위해서는 Driver Loading 과정이 매우 중요하다는 것을 알게 되었다.

또한 Driver 클래스가 존재하지 않으면 프로그램은 Driver를 찾을 수 없으므로 ClassNotFoundException이 발생하며, 이를 처리하기 위해 try-catch 문을 사용하였다.

2) GetConnection

public class ConnectionExample {

    public static void main(String[] args) {

        try {

            Connection databaseConnection = DBUtil.getConnection();

            System.out.println(databaseConnection.getMetaData().getURL());

        } catch (SQLException e) {

            e.printStackTrace();

        }

    }

}

Driver를 등록한 이후 실제 데이터베이스와 연결을 수행하였다.

Connection databaseConnection = DBUtil.getConnection();

을 호출하면 내부적으로 DriverManager가 실행된다.

DBUtil에서는

• URL
• USER
• PASSWORD

를 환경 변수에서 읽어와 Connection 객체를 생성한다.

이처럼 DB 연결 정보를 별도의 Utility 클래스로 분리하면 여러 클래스에서 동일한 Connection 생성 코드를 반복해서 작성하지 않아도 된다.

또한 민감한 정보(DB 계정과 비밀번호)를 소스 코드에 직접 작성하지 않아 보안 측면에서도 장점이 있다.

Connection 객체가 생성되면 데이터베이스와의 통신이 가능한 상태가 되며, 이후 Statement나 PreparedStatement를 생성하여 SQL을 실행할 수 있다.

JDBC 연결 과정

실습을 통해 JDBC의 연결 과정은 다음과 같은 순서로 이루어진다는 것을 이해하였다.

Java Program
      │
      ▼
Class.forName()
      │
      ▼
DriverManager
      │
      ▼
Connection 생성
      │
      ▼
Statement / PreparedStatement 생성
      │
      ▼
SQL 실행
      │
      ▼
ResultSet 반환

단순히 Connection만 생성하는 것이 아니라, JDBC는 위와 같은 흐름으로 데이터베이스와 통신한다는 점을 이해하는 것이 중요하다고 느꼈다.

1) Bean Scope란?

Spring에서는 Bean이 언제 생성되고 언제 소멸되는지를 Scope를 통해 결정한다.

기본적으로 Spring Bean은 Singleton으로 생성된다.

@Component
public class ExampleBean {
}

@Scope를 지정하지 않으면 Singleton으로 관리된다.

이번 예제에서는 기존 Singleton 외에

• Request Scope
• Session Scope

두 가지 Scope를 학습하였다.

2) Request Scope

Request Scope Bean은

@Component
@RequestScope
public class RequestScopeBean {
}

HTTP 요청이 들어올 때마다 새로운 Bean이 생성된다.

즉,

GET /scope

↓

RequestScopeBean 생성

↓

응답 완료

↓

Bean 소멸

요청이 끝나면 Bean도 함께 제거된다.

새로고침(F5)을 하면

첫 번째 요청

↓

RequestScopeBean A

두 번째 요청

↓

RequestScopeBean B

처럼 항상 새로운 객체가 생성된다.

3) RequestScopeBean에서 UUID를 사용하는 이유

RequestScopeBean에는

private final String uuid;

가 존재한다.

생성자에서

UUID.randomUUID();

를 호출하여 고유한 UUID를 생성한다.

UUID를 사용하는 이유는

매 요청마다 새로운 Bean이 생성되었는지 확인하기 위해서이다.

예를 들어

첫 번째 요청

UUID

A123...

두 번째 요청

UUID

F928...

UUID가 계속 바뀌는 것을 통해 새로운 Bean이 생성되었음을 확인할 수 있었다.

4) 생성 시간을 저장하는 이유

RequestScopeBean에서는

private final ZonedDateTime creationTime;

도 함께 저장한다.

생성자에서

creationTime = ZonedDateTime.now();

를 실행한다.

즉,

요청

↓

Bean 생성

↓

생성 시간 저장

이 된다.

새로고침할 때마다 생성 시간이 계속 변경되는 것을 확인할 수 있었다.

5) Session Scope

Session Scope Bean은

@Component
@SessionScope
public class SessionScopeBean {
}

으로 선언하였다.

Session Scope는

사용자(Session)마다 하나의 Bean을 생성한다.

즉,

브라우저 접속

↓

Session 생성

↓

SessionScopeBean 생성

이후에는

새로고침을 여러 번 해도

같은 Bean을 계속 사용한다.

6) SessionScopeBean의 count

SessionScopeBean에는

private int count = 0;

가 존재한다.

그리고

public void increment() {
    count++;
}

를 호출할 때마다

0

↓

1

↓

2

↓

3

으로 값이 증가한다.

새로고침을 반복해도 count가 유지되는 이유는

Session Scope Bean이 동일한 객체를 계속 사용하기 때문이다.

7) ScopeController

Controller에서는

@RequiredArgsConstructor
@Controller
@RequestMapping("/scope")
public class ScopeController {

를 사용하였다.

생성자 주입을 통해

private final RequestScopeBean requestScopeBean;

private final SessionScopeBean sessionScopeBean;

을 주입받는다.

그리고

sessionScopeBean.increment();

를 호출하여 방문 횟수를 증가시킨다.

이후

model.addAttribute(...)

를 이용하여

Request Bean과 Session Bean 정보를 View로 전달한다.

8) Request Scope와 Session Scope 차이

이번 예제에서 가장 중요한 내용은

두 Scope의 생명주기 차이였다.

새로고침을 했을 때

Request Bean은

UUID

A

↓

B

↓

C

처럼 계속 변경된다.

반면

Session Bean은

UUID

X

↓

X

↓

X

로 유지된다.

또한 count 역시

1

↓

2

↓

3

처럼 계속 증가한다.

이를 통해 Request Scope는 요청마다 새로 생성되고,

Session Scope는 같은 Session 동안 유지된다는 점을 확인하였다.

🔄 전체 실행 흐름

브라우저

↓

GET /scope

↓

DispatcherServlet

↓

ScopeController

↓

RequestScopeBean 생성

↓

SessionScopeBean 조회

↓

count 증가

↓

Model 저장

↓

scope.jsp

↓

브라우저 응답

Singleton · Request · Session Scope 비교

1) GET 요청과 POST 요청 분리

이번 예제에서는 화면을 보여주는 역할과 사용자가 입력한 데이터를 처리하는 역할을 분리하였다.

@GetMapping
public String page() {
    return "shirt";
}

GET 요청은 단순히 화면(shirt.jsp)을 반환한다.

실행 흐름

브라우저

↓

GET /shirt

↓

DispatcherServlet

↓

ShirtController.page()

↓

shirt.jsp

반면,

@PostMapping
public String register(...) {

POST 요청은 사용자가 입력한 데이터를 서버에서 처리한다.

즉,

조회와 저장을 서로 분리하여 구현하는 방식을 학습하였다.

2) @ModelAttribute와 Data Binding

Servlet에서는 사용자가 입력한 값을 직접 꺼내야 했다.

String name = request.getParameter("name");

int price =
Integer.parseInt(
request.getParameter("price")
);

Spring MVC에서는

@PostMapping
public String register(
        @ModelAttribute ShirtDTO shirtDTO
)

한 줄만 작성하면 된다.

Spring이 내부적으로

ShirtDTO dto = new ShirtDTO();

dto.setName(...);

dto.setPrice(...);

를 자동으로 수행한다.

이 과정을 Data Binding이라고 한다.

즉,

브라우저 입력값

↓

Spring

↓

DTO 생성

↓

Setter 호출

↓

Controller 전달

과정이 자동으로 이루어진다.

3) Lombok을 이용한 DTO 작성

이번 DTO는 Lombok을 이용하여 작성하였다.

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString
public class ShirtDTO

각 어노테이션의 역할은 다음과 같다.

특히 Data Binding 과정에서는 Spring이

new ShirtDTO()

를 생성한 뒤 Setter를 호출하기 때문에

기본 생성자와 Setter가 반드시 필요하다는 점을 이해하였다.

4) HttpSession

Controller에서는 Session 객체도 함께 전달받는다.

@PostMapping
public String register(
        @ModelAttribute ShirtDTO shirtDTO,
        HttpSession session
)

Session은 사용자마다 독립적으로 유지되는 저장 공간이다.

사용자가 입력한 데이터를

session.setAttribute(
        "shirt",
        shirtDTO
);

를 이용하여 Session에 저장하였다.

동작 과정은 다음과 같다.

Controller

↓

HttpSession

↓

사용자 정보 저장

↓

다음 요청에서도 사용 가능

Model은 현재 요청에서만 사용할 수 있지만,

Session은 여러 요청에 걸쳐 데이터를 유지할 수 있다는 차이를 이해하였다.

5) Redirect

데이터 저장 후

return "redirect:/shirt";

를 반환하였다.

Redirect는 JSP를 바로 실행하는 것이 아니라

브라우저에게

/shirt로 다시 요청하세요.

라고 응답하는 방식이다.

동작 과정은 다음과 같다.

POST /shirt

↓

Controller

↓

redirect:/shirt

↓

브라우저

↓

GET /shirt

↓

shirt.jsp

즉, POST 요청 이후 새로운 GET 요청이 발생한다.

6) Redirect를 사용하는 이유

만약

return "shirt";

를 사용하면

사용자가 새로고침(F5)을 눌렀을 때

POST 요청이 다시 실행된다.

POST

↓

상품 등록

↓

새로고침

↓

POST

↓

상품 또 등록

이처럼 같은 데이터가 중복 저장될 수 있다.

Redirect를 사용하면

POST

↓

Redirect

↓

GET

↓

새로고침

↓

GET만 실행

이 되어 중복 저장을 방지할 수 있다.

이러한 패턴을

PRG(Post-Redirect-Get)

패턴이라고 한다.

7) Model과 Session의 차이

Step2에서는

model.addAttribute(...)

를 사용하였다.

Step3에서는

session.setAttribute(...)

를 사용하였다.

둘의 차이는 다음과 같다.

즉,

Model은 화면을 위한 데이터,

Session은 사용자 상태를 유지하기 위한 데이터라는 점을 이해하였다.

🔄 전체 실행 흐름

브라우저

↓

GET /shirt

↓

shirt.jsp 출력

↓

사용자 입력

↓

POST /shirt

↓

DispatcherServlet

↓

Spring Data Binding

↓

ShirtDTO 생성

↓

Session 저장

↓

redirect:/shirt

↓

브라우저

↓

GET /shirt

↓

shirt.jsp 출력

Step2와 Step3 비교

Step2는 데이터를 화면으로 전달하는 과정이었다면,

Step3는 사용자가 입력한 데이터를 서버가 처리하는 과정을 학습하는 단계였다.

1) Controller란?

Servlet에서는 HttpServlet을 상속받아 doGet()이나 doPost()를 구현했지만,

Spring MVC에서는 Controller가 요청을 처리한다.

@Controller
@RequestMapping
public class FoodController {

@Controller가 붙으면 Spring이 해당 클래스를 Bean으로 등록하고, DispatcherServlet이 요청이 들어왔을 때 적절한 Controller를 찾아 실행한다.

2) URL Mapping

Controller 내부에서는 @GetMapping을 이용하여 GET 요청을 처리한다.

@GetMapping
public String index(Model model) {

브라우저에서

GET /

요청이 들어오면 DispatcherServlet이 해당 메서드를 실행한다.

실행 흐름

브라우저

↓

DispatcherServlet

↓

FoodController.index()

3) DTO(Data Transfer Object)

이번 예제에서는 화면으로 전달할 데이터를 DTO에 담아 전달하였다.

public record FoodDTO(
        String name,
        int price
) {
}

DTO는 여러 데이터를 하나의 객체로 묶어서 전달하기 위한 객체이다.

예를 들어

FoodDTO food =
        new FoodDTO("미소라멘", 12000);

객체 안에는

FoodDTO

name = 미소라멘

price = 12000

가 저장된다.

4) Model을 이용한 데이터 전달

Controller에서는 Model 객체를 이용하여 View(JSP)로 데이터를 전달한다.

model.addAttribute(
        "food",
        new FoodDTO("미소라멘", 12000)
);

Model은 Controller와 View 사이에서 데이터를 전달하는 저장 공간이다.

동작 과정은 다음과 같다.

Controller

↓

Model

↓

JSP(View)

JSP에서는

${food.name}

${food.price}

처럼 사용할 수 있다.

5) FoodDTO를 Model에 저장하는 이유

데이터를 하나씩 전달하는 것도 가능하다.

model.addAttribute("name", "미소라멘");
model.addAttribute("price", 12000);

하지만 전달해야 하는 데이터가 많아질수록 코드가 복잡해진다.

DTO를 사용하면

model.addAttribute("food", foodDTO);

한 줄만으로 여러 데이터를 전달할 수 있어 유지보수가 쉬워진다.

6) ViewResolver 동작 과정

Controller는 JSP의 전체 경로를 반환하지 않는다.

return "index";

ViewResolver가 자동으로

prefix

↓

/WEB-INF/views/

↓

index

↓

suffix

↓

.jsp

를 붙여

/WEB-INF/views/index.jsp

를 찾아 이동한다.

따라서 Controller는 JSP 위치를 알 필요 없이 View 이름만 반환하면 된다.

7) record와 Getter

FoodDTO는 record를 사용하였다.

public record FoodDTO(
        String name,
        int price
)

record는

food.name();
food.price();

와 같이 접근할 수 있지만,

JSP의 EL(Expression Language)는

${food.name}

형태로 값을 조회하기 때문에 Getter가 필요하다.

그래서

public String getName() {
    return name;
}

public int getPrice() {
    return price;
}

를 직접 작성하였다.

🔄 전체 실행 흐름

브라우저

↓

GET /

↓

DispatcherServlet

↓

FoodController.index()

↓

FoodDTO 생성

↓

Model 저장

↓

return "index"

↓

ViewResolver

↓

/WEB-INF/views/index.jsp

↓

JSP 렌더링

↓

브라우저 응답

Servlet과 Spring MVC 비교

Spring MVC는 Servlet에서 직접 처리하던 대부분의 작업을 어노테이션 기반으로 자동 처리해주기 때문에 코드가 훨씬 간결해졌다.

1) WebApplicationInitializer

기존 Java 프로그램은 main() 메서드에서 시작하지만,

Spring Web MVC는 Tomcat이 애플리케이션을 실행하며 WebApplicationInitializer가 시작점 역할을 한다.

public class WebAppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) {

실행 흐름

Tomcat 시작
    ↓
WebApplicationInitializer 실행
    ↓
Spring Container 생성
    ↓
DispatcherServlet 등록

2) Spring Container 생성

AnnotationConfigWebApplicationContext context =
        new AnnotationConfigWebApplicationContext();

context.register(WebConfig.class);

여기서 Spring Container가 생성되고, WebConfig를 읽어 Bean을 생성한다.

3) DispatcherServlet 등록

DispatcherServlet dispatcherServlet =
        new DispatcherServlet(context);

DispatcherServlet은 모든 HTTP 요청을 가장 먼저 받아 적절한 Controller에게 전달한다.

브라우저
    ↓
DispatcherServlet
    ↓
Controller
    ↓
View

4) URL Mapping

registration.addMapping("/");

"/"로 매핑했기 때문에 모든 요청은 DispatcherServlet을 거친다.

/
/food
/shirt
/login

↓

DispatcherServlet

5) WebConfig

@Configuration
@EnableWebMvc
@ComponentScan("org.example.webmvc")

각 어노테이션의 역할

6) ViewResolver

return "index";

Controller에서는 View 이름만 반환한다.

ViewResolver가

return "index"

↓

/WEB-INF/views/index.jsp

로 변환한다.

7) ResourceHandler

정적 리소스(CSS, JS, Image)의 경로를 등록한다.

registry
    .addResourceHandler("/resources/**")
    .addResourceLocations("/resources/");

🔄 전체 실행 흐름

Tomcat 실행

↓

WebApplicationInitializer

↓

Spring Container 생성

↓

WebConfig 읽기

↓

DispatcherServlet 등록

↓

브라우저 요청

↓

DispatcherServlet

↓

Controller

↓

ViewResolver

↓

JSP

↓

브라우저

1) 계층 분리(Layered Architecture)

가장 먼저 도메인 객체(Book), 서비스(Service), 저장소(Repository)를 분리하여 객체지향적인 구조를 설계하는 방법을 학습하였다.

각 계층의 역할

Service는 데이터를 직접 저장하지 않고 Repository에게 저장을 요청하며, Main은 Service만 호출하도록 역할이 분리되어 있다.

이를 통해 각 클래스가 하나의 책임만 가지도록 설계하는 것이 객체지향 설계의 기본이라는 것을 이해하였다.

2) Interface를 사용하는 이유

BookRepository는 저장 기능만 정의하고 실제 저장 방법은 구현하지 않는다.

BookRepository
        ▲
        │
MemoryBookRepository

이처럼 인터페이스를 사용하면 구현체를 자유롭게 변경할 수 있으며, Memory 저장 방식에서 Database 저장 방식으로 변경하더라도 Service는 수정하지 않아도 된다.

즉, 구현이 아닌 추상화에 의존하도록 설계하는 것이 객체지향 설계의 중요한 원칙임을 이해하였다.

3) Repository 구현

MemoryBookRepository에서는 HashMap을 이용하여 간단한 메모리 저장소를 구현하였다.

HashMap

1 → Book

2 → Book

3 → Book

save()는 HashMap의 put()을 이용하여 저장하고,

findBook()은 get()을 이용하여 조회한다.

실제 데이터베이스 대신 HashMap을 사용하지만 Repository의 역할 자체는 동일하다는 점을 이해하였다.

4) 생성자 주입(Dependency Injection)

Step2에서는 Service가 Repository를 직접 생성하지 않고 생성자를 통해 전달받도록 변경하였다.

기존 방식

private BookRepository repository = new MemoryBookRepository();

변경 후

public BookServiceImpl(BookRepository repository)

이 구조에서는 BookServiceImpl이 어떤 Repository를 사용할지 알 필요가 없으며, 외부에서 필요한 구현체를 전달받기만 한다.

이를 생성자 주입(Constructor Injection) 이라고 하며, 객체 간의 결합도를 낮추는 중요한 방법이라는 것을 학습하였다.

5) Spring Bean과 ApplicationContext

Spring에서는 객체를 직접 생성하지 않고 Spring Container가 생성 및 관리한다.

ApplicationContext를 생성하면 Spring은 설정 클래스를 읽고 Bean을 생성한다.

ApplicationContext context =
new AnnotationConfigApplicationContext(AppConfig.class);

이후에는

BookService service =
context.getBean(BookService.class);

처럼 필요한 객체를 Spring Container에게 요청하여 사용할 수 있다.

이를 통해 객체 생성 책임이 개발자에서 Spring으로 이동한다는 점을 이해하였다.

6) @Configuration과 @Bean

AppConfig 클래스에서는 Spring에게 어떤 객체를 Bean으로 등록할 것인지 알려준다.

@Configuration

은 설정 클래스라는 의미이며,

@Bean

은 Spring이 관리할 객체를 등록하는 역할을 한다.

BookRepository Bean을 생성한 뒤,

BookService Bean 생성 시 Repository를 전달하여 객체 간의 의존성을 연결하는 과정을 확인하였다.

7) @Component와 Component Scan

Step3부터는 @Bean 대신 @Component를 이용한 자동 Bean 등록 방식을 학습하였다.

@Component

가 붙은 클래스를

@ComponentScan

이 자동으로 탐색하여 Bean으로 등록한다.

즉,

@Component

↓

Component Scan

↓

Spring Bean 등록

이라는 흐름으로 동작한다는 것을 이해하였다.

실무에서는 @ComponentScan을 사용하는 방식이 가장 일반적이다.

8) Bean Scope

Bean이 몇 개 생성되는지를 결정하는 Scope에 대해서도 학습하였다.

Singleton

Spring의 기본 Scope이며 객체를 하나만 생성한다.

getBean()

↓

같은 객체 반환

따라서

bean1 == bean2

는 true가 된다.

Prototype

Prototype Scope는 getBean()을 호출할 때마다 새로운 객체를 생성한다.

getBean()

↓

새 객체 생성

따라서

bean1 == bean2

는 false가 된다.

Singleton은 프로그램 전체에서 하나의 객체를 공유하며, Prototype은 독립적인 객체가 필요할 때 사용된다는 차이를 이해하였다.

9) Bean 생명주기(Lifecycle)

Bean이 생성되고 소멸되는 과정도 학습하였다.

객체 생성

↓

@PostConstruct

↓

객체 사용

↓

@PreDestroy

Singleton Bean은 생성과 소멸 모두 Spring이 관리하지만,

Prototype Bean은 생성만 Spring이 담당하며 소멸은 직접 관리해야 한다는 차이를 알게 되었다.

10) 의존성 주입 방식 비교

Spring에서 사용하는 세 가지 의존성 주입 방식을 비교하였다.

생성자 주입은 객체 생성 시 반드시 필요한 의존성이 모두 주입되므로 가장 안전한 방식이라는 점을 이해하였다.

또한 Lombok의

@RequiredArgsConstructor

를 사용하면 생성자를 직접 작성하지 않아도 final 필드를 포함한 생성자가 자동 생성된다는 것도 학습하였다.

11) 순환 참조(Circular Dependency)

객체가 서로를 참조하는 순환 참조 문제도 실습하였다.

A

↓

B

↓

A

생성자 주입에서는 Spring이 Bean 생성 단계에서 순환 참조를 감지하여 예외를 발생시키기 때문에 문제를 빠르게 발견할 수 있다.

반면 필드 주입이나 Setter 주입에서는 객체 생성은 가능하지만, 서로의 메서드를 계속 호출하여 StackOverflowError가 발생할 수 있다는 점을 확인하였다.

이를 통해 생성자 주입이 권장되는 또 하나의 이유를 이해하였다.

직면한 문제

학습 초기에는 Spring이 객체를 어떻게 생성하는지, Bean과 일반 객체의 차이가 무엇인지 명확하게 이해되지 않았다.

의존성 주입 역시 단순히 "객체를 넣어준다" 정도로만 이해하고 있었기 때문에 생성자 주입과 필드 주입의 차이가 잘 와닿지 않았다.

특히 순환 참조 예제에서는 생성자 주입에서는 애플리케이션 시작 단계에서 예외가 발생하는 반면, 필드 주입에서는 실행 중 StackOverflowError가 발생하는 이유를 이해하는 데 어려움을 겪었다.

해결을 위해 시도한 방법

Main → Service → Repository → HashMap으로 이어지는 호출 흐름을 단계별로 추적하면서 객체가 생성되는 순서와 메서드가 호출되는 과정을 분석하였다.

Step1부터 Step4까지 변경된 부분만 비교하면서 왜 코드가 수정되었는지 확인하였고,

특히 생성자 주입, 필드 주입, Setter 주입을 각각 비교하여 장단점을 정리하였다.

Singleton과 Prototype은 getBean()을 여러 번 호출했을 때 반환되는 객체를 비교하면서 Scope의 차이를 확인하였다.

마지막으로 순환 참조 예제를 통해 생성자 주입과 필드 주입에서 발생하는 문제를 직접 확인하면서 Spring이 생성자 주입을 권장하는 이유를 이해할 수 있었다.

느낀 점

이번 학습을 통해 Spring은 단순히 객체를 대신 생성해주는 프레임워크가 아니라, 객체 간의 관계를 관리하고 의존성을 연결해주는 컨테이너라는 것을 이해하게 되었다.

또한 객체지향 설계에서는 구현보다 추상화에 의존하도록 설계하는 것이 유지보수성과 확장성을 높인다는 점도 알게 되었다.

특히 생성자 주입이 단순히 권장되는 코딩 스타일이 아니라 테스트 용이성, 객체 불변성 보장, 순환 참조 방지 등 다양한 장점을 가진 설계 방식이라는 것을 실습을 통해 체감할 수 있었다.

📚 오늘 배운 내용 요약

1) 상속과 오버라이딩

public class Example01 {

    public static void main(String[] args) {

        Developer dev = new Developer("Tom", "Java");

        BackendDeveloper backend =
                new BackendDeveloper("Jane", "Spring");

        dev.work();
        backend.work();
    }
}

class BackendDeveloper extends Developer {

    String version = "2.0";

    BackendDeveloper(String name, String skill) {
        super(name, skill);
    }

    @Override
    void work() {
        System.out.println(name + "이 백엔드 개발을 수행합니다.");
    }
}

class Developer {

    String version = "1.0";
    String name;
    String skill;

    Developer(String name, String skill) {
        this.name = name;
        this.skill = skill;
    }

    void work() {
        System.out.println(name + "이 개발을 수행합니다.");
    }
}

• BackendDeveloper가 Developer 상속
• 부모 생성자는 super()로 호출
• work() 메서드를 재정의하여 기능 확장
• 같은 메서드 호출이지만 실제 객체 타입에 따라 다르게 실행

2) 접근 범위와 상속

class Engineer {

    protected String secret = "SECRET";

    void work() {
        System.out.println("작업 수행");
    }
}

class SoftwareEngineer extends Engineer {

    @Override
    public void work() {

        super.work();

        System.out.println("추가 작업 수행");
    }
}

• protected 필드는 자식 클래스 접근 가능
• super를 통해 부모 기능 재사용
• 오버라이딩 시 접근 범위를 줄일 수 없음

3) 업캐스팅과 다운캐스팅

Animal animal = new Dog();

animal.eat();

if(animal instanceof Dog dog){
    dog.eat();
}

• 업캐스팅은 자동 수행
• 다운캐스팅은 명시적으로 수행
• instanceof로 안전성 확보

4) 추상 클래스

abstract class Fruit {

    abstract int getPrice();

    void info() {
        System.out.println("과일 정보");
    }
}

class Apple extends Fruit {

    @Override
    int getPrice() {
        return 1000;
    }
}

• Fruit는 직접 생성 불가
• 하위 클래스가 반드시 구현
• 공통 기능은 부모에서 제공

5) 인터페이스

interface Playable {
    void play();
}

interface Streamable {
    void stream();
}

class SmartTV implements Playable, Streamable {

    @Override
    public void play() {
        System.out.println("재생");
    }

    @Override
    public void stream() {
        System.out.println("스트리밍");
    }
}

• 인터페이스는 기능 명세 제공
• 클래스는 여러 인터페이스 구현 가능
• 다중 상속 문제 해결

6) Wrapper Class

List<Integer> scoreList =
        new ArrayList<>();

Integer value = 100;

int number = value;

• Generic에는 기본형 사용 불가
• Wrapper 클래스 사용 필요
• 자동 Boxing/Unboxing 지원

7) Generic

class Storage<T> {

    private T data;

    public void setData(T data) {
        this.data = data;
    }

    public T getData() {
        return data;
    }

    public <K> K echo(K value) {
        return value;
    }
}

• T는 클래스 전체에서 사용
• 자료형을 외부에서 결정
• String, Integer 등 다양한 타입 활용 가능

🚨 직면한 문제 : Generic 이해 부족

문제 상황

수업 중 다음 코드가 이해되지 않았다.

Box<String> box1 = new Box<>();

Box<Integer> box2 = new Box<>();

특히 T가 무엇인지, 왜 String이나 Integer를 넣을 수 있는지 혼란스러웠다.

해결 과정

Generic이 없는 경우

class StringBox {

    private String value;
}

class IntegerBox {

    private Integer value;
}

타입마다 클래스를 새로 만들어야 한다.

Generic 사용

class Box<T> {

    private T value;
}

사용 시

Box<String> textBox = new Box<>();

Box<Integer> numberBox = new Box<>();

컴파일러가 자동으로 타입을 결정한다.

최종적으로 이해한 내용

Generic의 장점

오늘 배운 점

Generic은 "여러 타입을 받는다"가 아니라

"클래스나 메서드를 정의할 때 타입을 나중에 결정하도록 미루는 기술"

이라는 것을 이해하게 되었다.

특히 List, List, Map<String,Integer> 같은 컬렉션들이 모두 Generic을 기반으로 동작한다는 점을 알게 되었고, 앞으로 Spring과 Java 컬렉션을 사용할 때 Generic 문법을 훨씬 자연스럽게 읽을 수 있을 것 같다.

📚 오늘 배운 내용 요약

1) 객체 생성과 메모리 구조

public class Example01 {

    public static int totalCount = 0;

    public static void main(String[] args) {

        Instructor instructor = new Instructor();

        System.out.println(instructor.name);

        Instructor copiedInstructor = instructor;

        copiedInstructor.name = "김강사";

        instructor.speak("학생", 10);

        System.out.println(instructor.name);
    }
}

class Instructor {

    String name;
    int age;

    static int count;

    void speak(String target, int number) {

        System.out.println(target);
        System.out.println(this.name);

        Example01.totalCount++;
    }
}

• new를 통해 힙 메모리에 객체 생성
• 참조 변수는 객체 주소 저장
• 동일한 객체를 여러 참조 변수가 가리킬 수 있음
• this를 통해 현재 객체의 필드 접근
• static 변수는 객체가 아닌 클래스에 소속

2) 클래스와 인스턴스

public class Example02 {

    public static void main(String[] args) {

        Vehicle vehicleA = new Vehicle();
        vehicleA.model = "소나타";

        Vehicle vehicleB = new Vehicle();
        vehicleB.model = "아반떼";

        vehicleA.increaseSpeed();
        vehicleA.increaseSpeed();

        vehicleB.increaseSpeed();
    }
}

class Vehicle {

    String model;
    int speed;

    void increaseSpeed() {
        speed += 10;
    }
}

• 객체마다 별도의 필드 공간 보유
• 같은 클래스라도 다른 인스턴스는 독립적
• == 는 객체 주소 비교

3) 메서드와 오버로딩

class Calculator {

    int sum(int a, int b) {
        return a + b;
    }

    String sum(String a, String b) {
        return a + b;
    }

    int sum(int... numbers) {

        int result = 0;

        for (int value : numbers) {
            result += value;
        }

        return result;
    }
}

• 메서드 이름은 동일
• 매개변수 타입이나 개수가 다르면 오버로딩 가능
• 가변인자로 여러 개의 값 처리 가능

4) 생성자(Constructor)

class User {

    String name;
    int age;
    String address;

    User() {
    }

    User(String name, int age) {

        this.name = name;
        this.age = age;
    }

    User(String name, int age, String address) {

        this(name, age);
        this.address = address;
    }
}

• 생성 시 초기값 설정
• 생성자끼리 재사용 가능
• this()를 이용해 코드 중복 제거

5) static

class CounterUtil {

    static int count = 0;

    static void increase() {
        count++;
    }

    static void increase(int amount) {
        count += amount;
    }
}

• 객체 없이 사용 가능
• 모든 객체가 같은 값 공유
• 유틸리티 기능 구현에 적합

6) Nested Class와 static 내부 클래스

public class Example06 {

    public static class Helper {

        static int count;

        public static void increase() {
            count++;
        }
    }
}

• 특정 클래스 내부에 정의
• 관련 기능을 묶어서 관리 가능

7) 접근 제어자

public class User {

    private String password;

    public String name;
}

• private은 외부 접근 차단
• public은 모든 곳에서 접근 가능

8) 캡슐화(Encapsulation)

class ProductManager {

    private String productName;
    private int productPrice;

    public void setProductName(String productName) {

        if(productName.length() != 3){
            return;
        }

        this.productName = productName;
    }

    public void setProductPrice(int productPrice) {

        if(productPrice < 1 || productPrice > 1000){
            return;
        }

        this.productPrice = productPrice;
    }
}

• 직접 수정 불가
• Setter를 통한 검증 수행
• 객체 상태 보호 가능

🚨 직면한 문제와 해결 과정

문제 1. static은 언제 사용하는가?

고민한 내용

시도한 방법

class User {

    static int totalUserCount;
    int age;
}

해결

배운 점

• 공통 데이터는 static 사용
• 객체 상태 데이터는 인스턴스 변수 사용

문제 2. 오버로딩은 왜 필요한가?

고민한 내용

calculator.sum(1, 2);
calculator.sum("1", "2");
calculator.sum(1, 2, 3);

해결

배운 점

• 이름보다 행위가 중요
• 매개변수로 기능 구분 가능

문제 3. 객체(Object)와 인스턴스(Instance)의 차이

고민한 내용

해결

예시

Car myCar = new Car();

• Car → 클래스
• new Car() → 객체
• myCar → 객체를 참조하는 변수
• 생성된 Car → 인스턴스

배운 점

객체와 인스턴스는 거의 같은 의미로 사용되지만,

• 클래스 입장에서 보면 "인스턴스"
• 실제 존재하는 데이터 입장에서 보면 "객체"

라고 이해하면 된다.

최종 정리

1) while 반복문과 switch 표현식

import java.util.Scanner;

public class Example01 {
    public static void main(String[] args) {

        Scanner scanner = new Scanner(System.in);

        while (true) {
            System.out.println("포켓몬을 선택하세요.");
            System.out.println("1. 이상해씨 2. 꼬부기 3. 파이리 4. 피카츄");

            int selectedNumber = scanner.nextInt();

            String pokemonName = switch (selectedNumber) {
                case 1 -> "이상해씨";
                case 2 -> "꼬부기";
                case 3 -> "파이리";
                case 4 -> "피카츄";
                default -> "";
            };

            if (pokemonName.isBlank()) {
                System.out.println("잘못된 입력입니다.");
            } else {
                System.out.println("선택한 포켓몬 : " + pokemonName);
                break;
            }
        }
    }
}

• 사용자가 올바른 번호를 입력할 때까지 반복
• switch 표현식으로 포켓몬 이름 반환
• 빈 문자열 여부를 검사하여 유효성 체크
• 정상 입력 시 break로 반복 종료

2) for문과 while문

public class Example02 {
    public static void main(String[] args) {

        for (int number = 1; number <= 9; number++) {
            System.out.println(number);
        }

        int count = 1;
        while (count <= 9) {
            System.out.println(count++);
        }

        for (int number = 9; number >= 1; number--) {
            System.out.println(number);
        }

        for (int dan = 1; dan <= 9; dan++) {
            for (int multiplier = 1; multiplier <= 9; multiplier++) {
                System.out.println(dan + " * " + multiplier +
                        " = " + dan * multiplier);
            }
        }
    }
}

• 정방향 반복과 역방향 반복 구현
• 이중 for문으로 구구단 출력
• 내부 반복문이 모두 종료된 후 외부 반복문 진행

03. 배열(Array)

import java.util.Arrays;

public class Example03 {
    public static void main(String[] args) {

        int[] scores = new int[5];

        scores[0] = 100;

        System.out.println(scores[0]);
        System.out.println(scores.length);

        System.out.println(Arrays.toString(scores));

        int[][] matrix = {
                {1,2,3},
                {4,5,6}
        };

        System.out.println(Arrays.deepToString(matrix));
    }
}

• 배열 생성 후 값 저장
• 배열 길이 확인
• 2차원 배열 출력

04. 배열 순회와 2차원 배열

String[] fruits = {"apple", "banana", "cherry"};

for (int index = 0; index < fruits.length; index++) {
    System.out.println(fruits[index]);
}

for (int index = fruits.length - 1; index >= 0; index--) {
    System.out.println(fruits[index]);
}

• 정방향 탐색
• 역방향 탐색
• 2차원 배열은 이중 반복문 사용

05. 향상된 for문 (for-each)

char[] alphabetArray = {'a','b','c'};

for(char alphabet : alphabetArray){
    System.out.println(alphabet);
}

• 배열 요소를 직접 순회
• 인덱스 없이 접근 가능
• 읽기 전용으로 사용

06. List와 ArrayList

import java.util.ArrayList;
import java.util.List;

public class Example06 {

    public static void main(String[] args) {

        List<Integer> numberList = new ArrayList<>();

        numberList.add(10);
        numberList.add(20);

        System.out.println(numberList.get(0));

        numberList.set(1, 100);

        numberList.remove(0);

        System.out.println(numberList);
    }
}

• List 타입으로 선언
• ArrayList 객체 생성
• 추가, 조회, 수정, 삭제 수행

07. Map과 HashMap

import java.util.HashMap;
import java.util.Map;

public class Example07 {

    public static void main(String[] args) {

        Map<String, Integer> fruitPriceMap = new HashMap<>();

        fruitPriceMap.put("사과", 1000);
        fruitPriceMap.put("바나나", 2000);

        System.out.println(fruitPriceMap.get("사과"));

        fruitPriceMap.put(
                "체리",
                fruitPriceMap.getOrDefault("체리", 0)
        );

        for(Map.Entry<String, Integer> item
                : fruitPriceMap.entrySet()) {

            System.out.println(item.getKey());
            System.out.println(item.getValue());
        }
    }
}

• Key-Value 구조 사용
• getOrDefault로 NullPointerException 예방
• entrySet으로 전체 순회

08. Set과 HashSet

오늘 배운 내용

실습 코드

import java.util.HashSet;
import java.util.Set;

public class Example08 {

    public static void main(String[] args) {

        Set<String> memberSet = new HashSet<>();

        memberSet.add("철수");
        memberSet.add("철수");
        memberSet.add("영희");

        System.out.println(memberSet);

        System.out.println(memberSet.contains("영희"));

        memberSet.remove("철수");
    }
}

• 중복 데이터 저장 불가
• contains로 존재 여부 확인
• remove로 삭제 가능

직면한 문제와 해결 과정

문제 1. ArrayList 와 List 의 차이

고민한 내용

ArrayList<Integer> scoreList = new ArrayList<>();

List<Integer> scoreList = new ArrayList<>();

해결하기 위해 시도한 것

결론

List<Integer> scoreList = new ArrayList<>();

실무에서는 구현체보다 인터페이스에 의존하는 것이 객체지향 원칙에 더 적합하다.

문제 2. HashMap<String,Integer> 와 Map<String,Integer> 의 차이

고민한 내용

HashMap<String, Integer> productMap = new HashMap<>();

Map<String, Integer> productMap = new HashMap<>();

해결하기 위해 시도한 것

차이점 정리

이를 통해 배운 점

객체지향 프로그래밍에서는 구현체(HashMap, ArrayList)가 아니라 인터페이스(Map, List)에 의존하도록 설계하는 것이 유지보수와 확장성 측면에서 유리하다.

Map<String, Integer> itemMap = new HashMap<>();
List<Integer> scoreList = new ArrayList<>();

앞으로 컬렉션을 선언할 때는 특별한 이유가 없다면 인터페이스 타입(List, Map, Set)을 우선 사용하는 습관을 가져야겠다고 느꼈다.

자바스크립트 최상위 전역 객체인 window 우리가 쓰는 alert(), setTimeout(), 그리고 HTML 문서를 다루는 document까지 전부 이 window라는 객체의 주머니 속에 들어있다.

console.log(this); // 브라우저 환경에선 이게 바로 window 객체
window.alert("안녕"); // 원래는 이렇게 써야 하지만
alert("안녕"); // 전역 객체라서 window. 을 생략해도 브라우저가 다 알아듣는다.

2. DOM (Document Object Model): HTML을 객체 트리로 바꾼 지도

브라우저는 텍스트로 된 HTML 파일을 읽으면, 자바스크립트가 알아들을 수 있는 객체(Object)들의 거대한 나무 트리 구조로 메모리에 다시 그린다. 이게 바로 DOM이다.

과거에 쓰던 getElementsByClassName 같은 구식 API는 브라우저 상태가 바뀔 때마다 값이 실시간으로 변해서 버그를 만들기 쉬웠다. 이제는 CSS 선택자 문법을 그대로 쓰는 querySelector 시리즈가 표준이다.

const p1 = document.querySelector("p"); 
// -> 문서 전체에서 '가장 먼저 나오는 딱 하나의 p 태그'만 가져옴

const p4 = document.querySelectorAll(".job"); 
// -> 클래스명이 'job'인 모든 p 태그들을 묶어서 NodeList라는 주머니에 담아줘
// 주머니 통째로는 다루기 힘드니 p4[0], p4[1]처럼 인덱스로 꺼내 쓰거나 
// ...p4 (스프레드 연산자)로 알맹이만 풀어서 쓴다.

textContent vs innerHTML (보안의 핵심)

자바스크립트로 화면에 글자를 집어넣을 때, 무심코 innerHTML을 쓰면 대형 사고가 날 수 있다.

// ❌ 위험한 코드
box.innerHTML = `<button onclick="alert('해킹!')">클릭</button>`;

innerHTML은 사용자가 입력한 문자열에 <script>나 onclick 같은 위험한 HTML 마크업이 섞여 있어도 그걸 그대로 브라우저에 실행시켜 버린다. (이걸 XSS 공격이라고 한다.)

box.textContent = content;

반면 textContent는 주입된 문자열을 단순 '텍스트'로만 취급한다. 사용자가 아무리 악성 스크립트를 밀어 넣어도 화면에는 그냥 글자 그대로 보여주기 때문에 훨씬 안전하다. 게다가 브라우저가 화면을 새로 계산(렌더링)할 필요가 없어서 속도도 훨씬 빠르다.

3. Event: 유저의 행동에 반응하는 신호

이벤트는 유저가 클릭을 하거나, 키보드를 누르는 등의 '사건'을 자바스크립트에게 알려주는 신호다.

이벤트 연결 방식의 진화 (03_event-listener.html)

이벤트를 연결하는 방식은 크게 세 단계를 거쳐 발전했다.

1. 인라인 방식: <button onclick="..."> (HTML과 JS가 뒤섞여 유지보수가 최악이라 절대 금지)
2. DOM 프로퍼티 방식: btn.onclick = function() { ... }

• 치명적인 약점이 있다. 변수에 값을 대입하는 형식이라 새로운 함수를 등록하면 이전 함수가 지워지고 덮어쓰기가 된다.

3. addEventListener (현대 표준):

btn3.addEventListener("click", () => { console.log("첫 번째 할 일"); });
btn3.addEventListener("click", () => { console.log("두 번째 할 일"); });
// 덮어쓰지 않고 대기열에 쌓여서 두 작업이 모두 안전하게 실행된다.

폼 제출을 멈추는 마법

form.addEventListener("submit", (event) => {
  event.preventDefault(); // 브라우저의 기본 행동을 막는다.
});

HTML의 <form> 태그는 제출(submit) 버튼을 누르면 무조건 페이지를 새로고침하면서 서버로 날아가려는 기본 동작이 있다. 현대 웹(SPA)에서는 페이지 새로고침 없이 자바스크립트가 부드럽게 데이터를 처리해야 하므로, event.preventDefault()를 최상단에 적어 브라우저의 기본 동작을 억제해야 한다.

4. BOM & Web Storage

BOM은 주소창, 타이머, 방문 기록 등 HTML 문서 바깥의 '브라우저 자체'를 제어하는 도구 모음이다. 오늘 가장 흥미로웠던 부분은 데이터를 브라우저에 저장하는 Web Storage와 클립보드 복사 API다.

sessionStorage vs localStorage

두 저장소 모두 서버를 거치지 않고 내 브라우저에 키-값 형태로 데이터를 쓱 저장해 두는 공간이다.

• sessionStorage: 현재 열려 있는 탭(세션) 안에서만 살아있다. 탭을 닫으면 데이터가 사라진다. (임시 입력 폼 저장)
• localStorage: 컴퓨터를 끄든 브라우저를 닫든 지우기 전까지 영원히 살아있다. (다크모드 설정값 유지)

스토리지 쓸 때 주의점

웹 스토리지는 무조건 문자열(String)만 저장한다. 자바스크립트 객체({})를 그대로 넣으면 브라우저가 강제로 문자로 바꾸면서 데이터가 깨져버린다.

const o = { name: "윌", job: "백반집 사장" };

// ❌ 나쁜 예시
localStorage.setItem("o", o); 
console.log(localStorage.getItem("o")); // 출력: "[object Object]" (데이터가 다 깨져서 복구 불가)

//  좋은 예시 (JSON)
localStorage.setItem("o2", JSON.stringify(o)); 
// -> 객체를 문자열 형태('{"name":"윌",...}')로 변환(직렬화)해서 안전하게 보관

const savedO2 = JSON.parse(localStorage.getItem("o2"));
// -> 꺼낼 때는 다시 진짜 자바스크립트 객체로 조립(역직렬화)
console.log(savedO2.name); // "윌"

5. Clipboard API

웹 페이지에서 흔히 보는 "링크 복사하기" 버튼의 원리도 직접 구현해 보았다. 최신 브라우저의 navigator.clipboard API를 쓴다.

document.querySelector("#copy").addEventListener("click", async () => {
  try {
    // OS의 클립보드 메모리를 건드리는 건 시간이 걸리는 작업이라 '비동기(async/await)'로 처리한다
    await navigator.clipboard.writeText("내가 복사하고 싶은 텍스트!");
    alert("클립보드에 복사 완료");
  } catch (error) {
    console.error("복사 실패:", error);
  }
});

브라우저가 클립보드를 보호하는 이유

만약 아무 제약이 없다면, 나쁜 웹사이트가 유저 몰래 자바스크립트로 내 클립보드에 악성 코드를 심거나 내 클립보드에 있던 비밀번호를 훔쳐 갈 수 있을 것이다. 그래서 브라우저는 두 가지 강력한 자물쇠를 채워놨다.

1. 반드시 사용자가 버튼을 직접 클릭(click 이벤트)했을 때만 작동할 것
2. 보안이 철저한 https:// 환경에서만 작동할 것

오늘은 자바스크립트에서 단순 문법 수준을 넘어 실제 언어의 동작 원리와 자료 처리 방식, 객체지향 개념까지 폭넓게 학습했다. 처음에는 하나의 개념만 익히는 것이 아니라 너무 많은 개념들이 한 번에 등장해서 내용을 따라가는 것 자체가 쉽지 않았다. 하지만 각 개념이 어떤 문제를 해결하기 위해 등장했는지 이해하면서 조금씩 흐름이 보이기 시작했다.

오늘 학습한 내용은 크게 다음과 같다.

• Map / Set 자료구조
• 고차함수(sort, map, filter, reduce)
• 객체 복사(얕은 복사 / 깊은 복사)
• 객체지향 프로그래밍 기초
• 생성자 함수와 class
• private field / getter / setter
• 상속 / static / super
• 예외 처리(try-catch)

1) Map

기존 객체(Object)도 key-value 구조를 저장할 수 있지만, Map은 key-value 저장을 위해 더 명확하게 설계된 자료구조라는 것을 배웠다.

const userInfo = {};
userInfo.name = "철수";
userInfo["user age"] = 20;

Object는 데이터를 저장할 수 있지만 반복문 사용이 불편하다.

for (const item of userInfo) {
    console.log(item);
}

이 코드는 실행되지 않는다.

Object는 iterable 객체가 아니기 때문이다.

그래서 Object는 데이터를 꺼내려면:

Object.keys(userInfo);
Object.values(userInfo);
Object.entries(userInfo);

같은 별도 변환이 필요하다.

Map은 더 명확하다.

const studentMap = new Map();

studentMap.set("name", "영희");
studentMap.set("age", 22);

studentMap.get("name");

studentMap.has("age");

for (const [key, value] of studentMap) {
    console.log(key, value);
}

Map은 단순히 Object와 비슷한 구조가 아니라 key-value 저장 목적에 특화된 자료구조이다.

2) Set

Set은 중복을 허용하지 않는 자료구조다.

const uniqueNumbers = new Set();

uniqueNumbers.add(100);
uniqueNumbers.add(100);
uniqueNumbers.add(200);

결과:

Set {100, 200}

같은 값은 자동 제거된다.

배열 중복 제거에도 활용 가능하다.

const duplicatedList = [1, 1, 2, 2, 3, 3];

const cleanedList = [...new Set(duplicatedList)];

결과:

[1, 2, 3]

Set은 단순한 저장 구조가 아니라 중복 데이터 정리라는 매우 실용적인 문제를 빠르게 해결하는 자료구조이다.

3) 고차함수

고차함수는:

함수를 인자로 받거나 함수를 반환하는 함수

sort

기본 정렬:

const scoreList = [1, 13, 5, 8];

console.log(scoreList.sort());

결과:

[1, 13, 5, 8]

예상과 다르게 동작했다.

이유:

기본 sort는 숫자 비교가 아니라 문자열 비교를 하기 때문이다.

그래서 비교 함수를 직접 전달해야 한다.

scoreList.sort((left, right) => left - right);

오름차순 정렬.

내림차순

scoreList.sort((left, right) => right - left);

map

배열의 각 요소를 변환한다.

const rawNumbers = [1, -2, 3, -4];

const absoluteNumbers = rawNumbers.map((value) => Math.abs(value));

결과:

[1, 2, 3, 4]

map은 기존 배열을 수정하지 않고 새로운 배열을 만든다.

원본 보존 + 변환 구조.

filter

조건에 맞는 데이터만 남긴다.

const numberPool = [1, 2, 3, 4, 5, 6];

const evenNumbers = numberPool.filter((value) => value % 2 === 0);

결과:

[2, 4, 6]

filter는 단순 반복문이 아니라 조건 기반 데이터 선별 도구이다.

reduce

배열을 하나의 값으로 줄인다.

const basket = [10, 20, 30];

const totalPrice = basket.reduce((prev, current) => prev + current);

과정:

10 + 20 = 30
30 + 30 = 60

결과:

60

reduce는 처음에는 어렵게 느껴졌지만, 결국 "누적 계산" 구조라는 점을 이해했다.

4) 객체 복사

오늘 매우 중요하게 배운 개념.

처음에는:

const originalData = {
    profile: {
        age: 20
    }
};

const copiedData = originalData;

이렇게 하면 복사된다고 생각할 수 있지만, 실제로 같은 객체를 가리킨다.

즉:

originalData.profile.age = 30;

하면

copiedData.profile.age

도 같이 바뀐다.

이유:

객체는 값이 아니라 메모리 주소를 저장하기 때문이다.

얕은 복사

const shallowCopy = { ...originalData };

겉 객체만 복사.

하지만 내부 중첩 객체는 공유.

깊은 복사

const deepCopy = structuredClone(originalData);

중첩 객체까지 완전 복사.

복사는 단순히 "같은 값 만들기"가 아니라 메모리 참조 구조를 이해해야 하는 문제라는 것을 배웠다.

5) 객체지향과 생성자 함수

객체 리터럴:

const playerInfo = {
    nickname: "전사",
    hp: 100
};

생성자 함수:

function UserProfile(userName, department) {
    this.userName = userName;
    this.department = department;
}

생성:

const member = new UserProfile("민수", "개발");

생성자 함수는 같은 구조의 객체를 여러 개 만들기 위한 템플릿 역할을 한다는 점을 이해했다.

6) class

현대 객체지향 방식.

class Member {
    constructor(memberName) {
        this.memberName = memberName;
    }

    sayHello() {
        console.log(`${this.memberName}입니다.`);
    }
}

생성:

const userA = new Member("철수");

class는 생성자 함수보다 훨씬 읽기 쉽고 구조적으로 객체 설계가 명확했다.

7) private / getter / setter

private:

class BankAccount {
    #balance = 0;

    get balance() {
        return this.#balance;
    }

    set balance(amount) {
        this.#balance = amount;
    }
}

private은 내부 데이터 보호.

getter/setter는 직접 접근 대신 통제된 접근 방식.

즉 객체 내부 상태 보호 구조라는 것을 이해했다.

8) 상속

class Animal {
    speak() {
        console.log("동물 소리");
    }
}

class Dog extends Animal {
    speak() {
        super.speak();
        console.log("멍멍");
    }
}

상속은 기존 기능 재사용.

super는 부모 기능 호출.

9) static

class Counter {
    static totalCount = 0;
}

instance마다 가지는 값이 아니라 클래스 전체가 공유하는 값이라는 점을 이해했다.

10) 예외 처리

기본 구조

try {
    const user = null;
    user.name = "철수";
} catch (error) {
    console.log(error);
}

에러 발생 시 프로그램 종료 방지.

에러 종류 구분:

if (error instanceof TypeError) {
    console.log("타입 에러");
}

예외 처리는 단순 에러 숨기기가 아니라 프로그램 안정성을 위한 필수 처리라는 점을 배웠다.

직면한 문제

오늘 가장 큰 문제는 너무 많은 개념을 한 번에 학습했다는 점이었다.

이번 학습에서는 단순 문법 몇 개만 배운 것이 아니라:

• 자료구조
• 함수형 프로그래밍
• 메모리 구조
• 객체지향
• 클래스
• 상속
• 예외 처리

까지 한 번에 등장했다.

그래서 개념이 서로 섞여서 처음에는 머릿속에서 정리가 잘 되지 않았다.

특히 어려웠던 부분은:

• Map과 Object 차이
• 얕은 복사 / 깊은 복사
• this
• private field
• static
• super
• reduce
• instanceof

같은 개념들이었다.

처음에는 각각 따로 보였고 왜 필요한지도 잘 이해되지 않았다.

처음에는 내용을 처음부터 끝까지 한 번에 이해하려고 했다.

하지만 이 방법은 효과적이지 않았다.

새 개념이 계속 추가되면서 이전 개념까지 헷갈리기 시작했기 때문이다.

class를 이해하려고 하면 this가 필요했고, 상속을 이해하려면 class 구조가 먼저 이해되어야 했고, 예외 처리를 보려면 객체 개념도 어느 정도 이해가 필요했다.

그래서 방식을 바꿨다.

1. 큰 범위를 작은 단위로 나눴다

한 번에 전체 이해하려 하지 않고:

PART 1

• Map
• Set
• 고차함수

PART 2

• 복사
• 객체지향

PART 3

• class
• 상속

PART 4

• 예외처리

이렇게 분리해서 학습했다.

2. 코드 한 줄씩 해석했다

단순히 결과만 보지 않고:

const copied = original;

이 코드가

"복사인지"

"주소 공유인지"

직접 해석했다.

3. 개념보다 동작 원리를 먼저 이해하려고 했다

처음엔 reduce 문법이 어렵게 느껴졌지만

prev + current

흐름을 직접 따라가면서 이해했다.

4. ChatGPT에게 계속 질문했다

헷갈리는 개념을 바로 질문했다.

• 왜 객체 복사가 같이 바뀌지?
• 왜 super를 먼저 호출해야 하지?
• 왜 private은 밖에서 못 쓰지?

질문하면서 개념을 정리했다.

방대한 내용을 작은 개념 단위로 쪼개서 코드 중심으로 이해하기

한 번에 암기하려고 하면 실패했지만,

"이 코드가 왜 이렇게 동작하지?"

이 관점으로 접근하니 이해가 훨씬 쉬워졌다.

복잡한 개념일수록 암기보다 구조적인 이해가 중요하다는 점이었다.

처음에는 내용이 너무 많아서 압도되는 느낌이 있었다.

하지만 자세히 보면 모든 개념은 연결되어 있었다.

각각 따로 떨어진 개념이 아니라 하나의 흐름이었다.

또 하나 배운 점은

이해되지 않는 상태에서 그냥 넘어가면 뒤에서 더 크게 막힌다는 점이었다.

특히 객체지향 부분은 앞 개념 이해가 부족하면 계속 어려워진다.

그래서 막히는 부분을 바로 정리하는 습관이 중요하다고 느꼈다.

그리고 코드 학습에서 중요한 것은:

단순히 "이 문법을 외우는 것"이 아니라

"왜 이 문법이 필요한가?"

를 이해하는 것이라는 점도 느꼈다.

한 줄 회고

방대한 내용을 한 번에 이해하려 하기보다, 코드를 중심으로 작은 개념 단위로 나누어 동작 원리를 이해하는 방식이 훨씬 효과적이라는 것을 배웠다.