MoonCommit DevLog

[이커머스 백오피스] 프로젝트 시작과 설계 기록

mooncommit — Sat, 25 Apr 2026 03:54:17 +0900

프로젝트 시작 "이커머스 백오피스 서비스"

이번 프로젝트는 관리자 회원가입/인증, 관리자 관리, 고객 관리, 상품 관리, 주문 관리 기능을 포함하고 있고,

나는 관리자 부분을 맡았다. 프로젝트 초반에는 기능 구현보다 협업 방식과 공통 구조를 먼저 맞추는 일이 더 중요했고, 이번 글에서는 그 과정을 정리해보려고 한다.

✔️ 프로젝트를 시작하고 가장 먼저 한 일

가장 먼저 한 작업은 테이블 명세서, ERD, API 명세서를 정리하는 것이었다.

요구사항을 읽어보니 관리자, 고객, 상품, 주문까지 도메인이 여러 개였고 각 도메인이 서로 연결되어 있었다.

그래서 먼저 아래 순서로 전체 구조를 잡았다.

테이블 명세서 작성
ERD 작성
API 명세서 작성
GitHub 저장소 생성 및 협업 세팅
공통 작업 진행
역할 분담 후 각자 브랜치에서 개발

이 과정을 거치면서 느낀 점은 구현 전에 명세를 먼저 정리하는 과정이 생각보다 훨씬 중요하다는 것이었다.
코드는 나중에 바꿀 수 있어도, 구조를 잘못 잡으면 기준이 명확하지 않아 수정 범위가 너무 커질 것 같다는 생각이 들었다.

테이블 명세서, ERD, API 명세서

이 과정은 내가 참여하지는 못했지만 프로젝트를 진행하며 왜 첫 과정으로 했는지 이유를 알 수 있었다.

관리자 테이블 명세서

이름, 이메일, 비밀번호, 전화번호, 역할, 상태, 승인일시, 거부일시, 거부사유
테이블 명세서로 정리되어 있으니, 어떤 필드가 필요한지 명확하게 보였다.

ERD

각 도메인이 어떤 관계를 가지는지 생각할 수 있다.

상품은 등록한 관리자와 연결된다.
주문은 고객과 연결된다.
CS 주문의 경우 주문 등록 관리자와도 연결된다.
주문은 주문 상품과 연결된다.

관리자 API 명세서

승인, 거부, 다건 조회, 단건 조회, 정보 수정, 역할 수정, 상태 수정, 삭제
내 프로필 조회, 내 프로필, 비밀번호 변경

나중에 엔티티를 만들 때 "이 필드가 왜 필요한지", "이 상태값이 어느 API에서 쓰이는지" 쉽게 이해할 수 있었다.

GitHub 저장소를 만들고 협업 방식을 맞춘 과정

명세 작업 이후 다시 합류 하여 GitHub 저장소를 만들고 협업 환경을 세팅했다.

기본 엔티티, enum, 예외 처리, BaseEntity 같은 공통 작업을 먼저 맞춘 뒤, 역할을 나누어 각자 브랜치를 생성하도록 진행했다.

이 방식이 중요했던 이유는 공통 기준 없이 각자 개발을 시작하면 나중에 코드 스타일과 구조가 서로 달라질 수 있기 때문이다.

예를 들어

어떤 사람은 상태값을 문자열로 저장하고
어떤 사람은 enum으로 만들고
어떤 사람은 예외 RuntimeException으로 던지고
어떤 사람은 ResponseEntity를 직접 반환하는 식이면

프로젝트 전체 코드가 통일되지 않게 된다.

GitHub 기본 흐름

git init
git remote add origin <원격저장소주소>
git checkout -b master
git add .
git commit -m "init: 프로젝트 초기 세팅"
git push -u origin main

이후 각자 역할에 따른 브랜치를 만들어서 작업했다.

git checkout master
git pull origin master
git checkout -b feat/admin

작업 후에는 아래처럼 커밋하고 push한 뒤 PR을 생성하는 방식으로 진행한다.

git add .
git commit -m "feat : admin ... 추가"
git push -u origin feat/admin

README에 정리한 협업 규칙

협업 과정에서 혼란을 줄이기 위해 README에 규칙을 정리했다.

master 브랜치에 직접 push 하지 않는다.
각자 브랜치를 생성하여 작업한다.
작업 완료 후 Pull Request로 병합한다.
작업 전 최신 master 브랜치를 pull 받는다.
커밋 타입은 feat, fix, refactor를 사용한다.
커밋 메시지는 커밋타입 : 제목 형식으로 작성한다.
커밋은 기능 단위로 나눈다.
클래스 작명은 도메인 + 액션 + 요청/응답 + Dto 형식으로 작성한다.

공통 엔티티 BaseEntity를 먼저 만든 이유

프로젝트를 하다 보면 거의 모든 테이블에서 공통으로 필요한 필드가 있다.

대표적으로 생성 시간, 수정 시간 → 모든 엔티티마다 반복해서 작성하지 않기 위해 공통 부모 클래스로 BaseEntity를 만들었다.

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {

    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;
}

createdAt : 데이터가 처음 생성된 시간
updatedAt : 데이터가 마지막으로 수정된 시간
여러 엔티티에서 공통으로 사용할 수 있는 시간 필드를 한 곳에서 관리

문자열 대신 enum을 사용한 이유

관리자 도메인을 설계하면서 역할과 상태를 문자열이 아니라 enum으로 분리했다.

관리자 역할 enum

public enum AdminRole {
    // 슈퍼 관리자
    SUPER_ADMIN,
    // 운영 관리자
    OPERATIONS_ADMIN,
    // CS 관리자
    CS_ADMIN
}

관리자 상태 enum

public enum AdminStatus {
    // 활성
    ACTIVE,
    // 비활성
    INACTIVE,
    // 정지
    SUSPENDED,
    // 승인대기
    PENDING,
    // 거부
    REJECTED
}

허용된 값만 사용할 수 있다.
오타를 줄일 수 있다.
상태 비교가 더 명확해진다.
나중에 비즈니스 로직을 작성할 때 가독성이 좋아진다.

// 예를 들면
if (admin.getStatus() != AdminStatus.ACTIVE) {
    throw new AdminNotApprovedException();
}

관리자 엔티티를 설계하면서 배운 점

이번 과제에서 관리자는 회원가입 후 바로 사용 가능한 것이 아니라 승인 과정을 거쳐야 한다.

참고해 아래와 같이 만들었다.

@Getter
@Entity
@Table(name = "admins")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Admin extends BaseEntity {

    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; // 관리자 고유 식별자

    @Column(nullable = false, length = 20)
    private String name; // 관리자 이름

    @Column(nullable = false, unique = true, length = 255)
    private String email; // 로그인에 사용하는 이메일

    @Column(nullable = false, length = 255)
    private String password; // 암호화된 비밀번호 저장

    @Column(nullable = false, length = 20)
    private String phone; // 전화번호

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private AdminRole role; // 슈퍼 관리자 / 운영 관리자 / CS 관리자 구분

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private AdminStatus status; // 활성 / 비활성 / 정지 / 승인대기 / 거부 상태 관리

    private LocalDateTime approvedAt; // 관리자 승인 시각
    private LocalDateTime rejectedAt; // 관리자 거부 시간
    private String rejectionReason; // 관리자 거부 사유

    public Admin(String name, String email, String password, String phone, AdminRole role, AdminStatus status) {
        this.name = name;
        this.email = email;
        this.password = password;
        this.phone = phone;
        this.role = role;
        this.status = status;
    }
}

⭐️ 예외 처리를 먼저 설계한 이유

이번에 가장 크게 배운 것 중 하나는 예외 처리도 설계의 일부 라는 점이었다.

관리자 로그인만 생각해봐도 케이스가 정말 많았다.

이메일이 존재하지 않을 수 있다.
비밀번호가 다를 수 있다.
승인 대기 상태일 수 있다.
거부된 상태일 수 있다.
정지된 상태일 수 있다.
비활성 상태일 수 있다.

서비스 로직은 항상 성공 케이스와 실패 케이스를 함께 고려해야 한다.

그렇기 때문에 공통 부모 예외를 먼저 만들고, 그 아래에 도메인별 예외를 세분화하는 구조를 잡았다.

예외 처리의 부모 클래스 : ServiceException

모든 비즈니스 예외의 부모가 되는 클래스이다.

@Getter
public class ServiceException extends RuntimeException {

    private final HttpStatus status;

    public ServiceException(HttpStatus status, String message) {
        super(message);
        this.status = status;
    }
}

서비스 계층에서 발생하는 비즈니스 예외를 공통 형식으로 처리하기 위한 커스텀 예외 클래스
부모 클래스

이 클래스를 만든 이유는, 예외가 발생했을 때 단순히 메시지만 전달하는 것이 아니라 HTTP 상태코드와 메시지를 함께 담기 위해서였다.

이 구조를 사용하면 하위 예외 클래스들은 각각 자신에게 맞는 상태코드와 메시지를 지정할 수 있다.

관리자 관련 예외 정리

관리자 도메인에서 필요한 예외를 다음과 같이 정리했다.

PasswordMismatchException → 400, "비밀번호가 일치하지 않습니다."
AdminNotFoundException → 404, "관리자를 찾을 수 없습니다."
DuplicateEmailException → 400, "이미 사용중인 이메일입니다."
InvalidPasswordException → 400, "이메일 또는 비밀번호가 올바르지 않습니다."
UnauthorizedException → 401, "로그인이 필요합니다."
TokenMissingException → 401, "인증 토큰이 없습니다."
TokenExpiredException → 401, "인증 토큰이 만료되었습니다."
AccessDeniedException → 403, "접근 권한이 없습니다."
AdminAlreadyProcessedException → 400, "이미 처리된 관리자입니다."
InvalidAdminInputException → 400, "입력값이 올바르지 않습니다."
AdminNotApprovedException → 401, "승인되지 않은 관리자입니다."
SelfRoleChangeNotAllowedException → 400, "자신의 역할은 변경할 수 없습니다."
InvalidRoleException → 400, "유효하지 않은 역할입니다."
InvalidAdminStatusException → 400, "변경할 수 없는 상태입니다."

코드 예시

public class AdminNotFoundException extends ServiceException {
    public AdminNotFoundException() {
        super(HttpStatus.NOT_FOUND, "관리자를 찾을 수 없습니다.");
    }
}

고객, 상품, 주문 관련 예외도 도메인별로 분리

예외는 관리자 도메인만 있는 것이 아니라 고객, 상품, 주문 도메인에도 각각 필요하다.

✔️ 고객

CustomerNotFoundException → 404, "고객을 찾을 수 없습니다."

✔️ 상품 관련

ProductNotFoundException → 404, "상품을 찾을 수 없습니다."
DiscontinuedProductException → 400, "단종된 상품은 주문할 수 없습니다."
SoldOutProductException → 400, "품절된 상품은 주문할 수 없습니다."
OutOfStockException → 400, "재고가 부족합니다."

✔️ 주문 관련

OrderNotFoundException → 404, "주문을 찾을 수 없습니다."
InvalidOrderStatusException → 400, "주문 상태를 변경할 수 없습니다."
OrderCancelNotAllowedException → 400, "준비중 상태에서만 취소할 수 있습니다."

이렇게 도메인별로 나누어서 정리하니 예외 이름만 봐도 어떤 상황인지 알 수 있었다.

같은 실패여도 이유는 각각 다르기 때문에 예외도 구체적으로 나눠야 한다는 걸 배웠다.

HTTP 상태코드도 함께 이해하기

배운 점

지금은 공통으로 사용하는 예외 처리, 엔티티, enum 같은 기본 구조를 잡는 단계까지 진행했다. 이 과정에서 개인 프로젝트와 팀 프로젝트는 시작 방식부터 다르다는 걸 많이 느꼈다. 개인 프로젝트에서는 테이블 구조를 대략만 잡고 바로 구현에 들어가도 괜찮았는데, 팀 프로젝트에서는 기능 구현 전에 전체 구조와 공통 규칙을 먼저 맞추는 게 훨씬 중요했다.

특히 예외 처리를 커스텀 방식으로 설계해본 건 처음이라 새롭게 배운 점이 많았다. 그리고 공통 구조를 먼저 잡아두니깐 아직 기능 코드를 시작하지 않았지만, 틀이 잡히는 느낌이어서 신기했다. 생각해야 하는 범위가 넓어져서 어렵기도 했지만, 이런 식으로 구조를 먼저 고민해본 경험 자체가 나한테는 의미 있고 성장할 수 있는 기회라고 생각한다.

정말 뜻깊은 과정이었다 ◡̈⋆*

Spring Boot 일정 관리 트러블 슈팅

mooncommit — Thu, 23 Apr 2026 10:20:57 +0900

Trouble Shooting List

Port already in use
Schedule 생성자에서 값이 null로 저장되는 문제
400 Bad Request
author 필드 제거 후 연관관계 적용
Schedule 생성 시 userId로 User를 못 찾는 문제
세션 검증 적용 후 userId 제거
(User) 형변환(캐스팅) 오류
수정/삭제 시 본인 확인

1. Port already in use

Problem

Web server failed to start. Port 8081 was already in use.

Cause

이전에 실행했던 서버가 종료되지 않은 채로 다시 실행하려고 해서 발생

✅ Solution

lsof -i :8081
kill -9 [PID숫자]

2. Schedule 생성자에서 값이 null로 저장되는 문제

Problem

일정 생성 시 title, content, author가 null로 저장됨

Cause

Schedule 생성자에서 필드에 값을 할당하지 않음

// 문제 코드
public Schedule(String title, String content, String author) {
    super(); // title, content, author 할당 안 함
}

✅ Solution

public Schedule(String title, String content, String author) {
    this.title = title;
    this.content = content;
    this.author = author;
}

3. 400 Bad Request

Problem

{
    "status": 400,
    "error": "Bad Request"
}

Cause

포스트맨에서 GET 요청을 POST로 잘못 보냄

✅ Solution

포스트맨에서 HTTP 메서드를 GET으로 변경

4. author 필드 제거 후 연관관계 적용

Problem

Lv2에서 Schedule 엔티티의 author(String) 필드를 User 연관관계로 변경하면서 Service, DTO 등 여러 곳에서 오류 발생

Cause

author 필드를 제거하고 User 객체로 바꾸면서 연관된 코드들을 전부 수정해야 했음

✅ Solution

Schedule 엔티티에서 author 제거 후 @ManyToOne 연관관계 추가

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private User user;

DTO에서 String author → Long userId로 변경
Service에서 userId로 User 조회 후 Schedule 생성

5. Schedule 생성 시 userId로 User를 못 찾는 문제

Problem

Schedule 생성 시 request.getUserId()로 User를 찾아야 하는데 UserRepository가 ScheduleService에 없어서 오류 발생

✅ Solution

ScheduleService에 UserRepository 추가

private final ScheduleRepository scheduleRepository;
private final UserRepository userRepository; // 추가

6. 세션 검증 적용 후 userId 제거

Problem

Lv4 로그인 구현 후 기존에 클라이언트가 userId를 직접 보내던 방식이 보안상 위험함

Cause

클라이언트가 다른 사람의 userId를 넣어서 요청할 수 있음

✅ Solution

userId 대신 세션에서 로그인한 유저를 꺼내서 사용

// Controller
HttpSession session = servletRequest.getSession();
User user = (User) session.getAttribute("loginUser");
scheduleService.save(request, user);

// Service - 기존
User user = userRepository.findById(request.getUserId()).orElseThrow();

// Service - 변경 후
public CreateScheduleResponseDto save(CreateScheduleRequestDto request, User user) { ... }

7. (User) 형변환(캐스팅) 오류

Problem

session.getAttribute("loginUser") 반환 타입이 Object라서 User 타입으로 바로 사용 불가

✅ Solution

(User)로 캐스팅해서 사용

User user = (User) session.getAttribute("loginUser");

8. 수정/삭제 시 본인 확인

Problem

로그인한 유저가 다른 사람의 일정을 수정/삭제할 수 있는 문제

✅ Solution

Service에서 로그인한 유저와 일정 작성자의 이메일을 비교

if (!user.getEmail().equals(schedule.getUser().getEmail())) {
    throw new RuntimeException("본인 일정만 수정할 수 있습니다.");
}

모든 트러블 슈팅 해결 완료⎝⍥⎠

[TIL] Cookie / Session (로그인 인증)

mooncommit — Wed, 22 Apr 2026 17:28:58 +0900

Spring Boot Lv4 로그인 기능 구현을 위해 Cookie와 Session 개념을 공부했다.

왜 Session이 필요한가?

HTTP는 기본적으로 무상태(Stateless) 프로토콜이다.

즉, 서버는 각 요청을 독립적으로 처리하기 때문에 이전 요청을 기억하지 못한다.

✔️ 1번 요청: "나 스파르타야, 로그인할게"
✔️ 2번 요청: "나 스파르타야, 장바구니 보여줘"
⭐️ 서버 입장에서는 1번이랑 2번이 같은 사람인지 알 수 없다

그래서 "나는 로그인한 사람이야!" 를 증명할 수단이 필요 → Session

Cookie vs Session

✔️ 비유로 알아보기

  세션 = 놀이공원 입장 명부 (서버에 있음)
  쿠키 = 내 손목에 찍힌 도장 (브라우저에 있음)

  손목 도장(쿠키)을 보여주면 서버가 명부(세션)에서 확인하는 것!

✔️ 전체 흐름

1. 클라이언트가 이메일 + 비밀번호로 로그인 요청
2. 서버가 확인 후 세션 생성 (세션 ID : abc123)
3. 서버가 세션 ID를 쿠키에 담아서 브라우저에 전달
4. 이후 요청마다 브라우저가 쿠키(세션 ID)를 자동으로 서버에 전송
5. 서버가 세션 ID로 "이 사람 로그인한 사람이구나!" 확인
6. 로그아웃 시 세션 삭제

⭐️ 핵심 : 기억하는 건 세션(서버), 전달해주는 건 쿠키(브라우저)

HttpSession에 대해서 알고 가자

session 객체는 HttpSession 타입이다.
setAttribute, getAttribute, invalidate 메서드는 직접 구현할 필요 없이, 기본으로 제공된다!

HttpSession 기본 제공 메서드

주요 메서드

HttpSession session = request.getSession();

// 세션에 데이터 저장
session.setAttribute("loginUser", user);

// 세션에서 데이터 꺼내기
session.getAttribute("loginUser");

// 세션 전체 삭제 (로그아웃)
session.invalidate();

getSession() vs getSession(false)

// getSession()        → 세션이 없으면 새로 생성
// getSession(false)   → 세션이 없으면 null 반환 (생성 X)

HttpSession session = request.getSession(false); // 로그인 확인 시 사용

getSession() → 세션 있으면 가져오고, 없으면 새로 생성
getSession(false) → 세션 있으면 가져오고, 없으면 null 반환

실제 구현 패턴

✔️ 로그인 API

@PostMapping("/login")
public ResponseEntity<?> login(
        @RequestBody LoginRequestDto request,
        HttpServletRequest servletRequest) {

    // 세션 생성
    HttpSession session = servletRequest.getSession();

    // 로그인 성공 시 세션에 유저 저장
    session.setAttribute("loginUser", user);

    return ResponseEntity.ok(...);
}

✔️ 세션 확인 (로그인 필요한 API)

@GetMapping
public ResponseEntity<?> getSchedules(HttpServletRequest servletRequest) {

    HttpSession session = servletRequest.getSession(false);

    if (session == null || session.getAttribute("loginUser") == null) {
        throw new RuntimeException("로그인이 필요합니다.");
    }

    // 이후 로직 처리
}

✔️ 로그아웃 API

@PostMapping("/logout")
public ResponseEntity<Void> logout(HttpServletRequest servletRequest) {
    HttpSession session = servletRequest.getSession(false);
    if (session != null) {
        session.invalidate(); // 세션 삭제
    }
    return ResponseEntity.ok().build();
}

Lv4 로그인 구현 실습

1. UserRepository에 이메일 조회 메서드 추가

Optional<User> findByEmail(String email);

JPA가 메서드 이름만 보고 자동으로 쿼리를 만들어 준다.

2. LoginRequestDto 생성

public class LoginRequestDto {

    private String email;
    private String password;

    public String getEmail() {
        return email;
    }

    public String getPassword() {
        return password;
    }
}

이메일, 비밀번호 필드 추가

3. UserController에 로그인 API 추가

@PostMapping("/login")
public ResponseEntity<String> login(
        @RequestBody LoginRequestDto request,
        HttpServletRequest servletRequest) {
        
        // Service에 이메일, 비밀번호 확인 요청해서 유저 가져오기
}

4. UserService에 Login 메서드 추가

// Login
@Transactional(readOnly = true)
public User login(LoginRequestDto request) {
    // 1. request 값 꺼내오기
    String email = request.getEmail();
    String password = request.getPassword();
    
    // 2. email로 유저 찾기
    User findUser = userRepository.findByEmail(email)
            .orElseThrow(() -> new RuntimeException("유저를 찾을 수 없습니다."));
    
    // 3. 찾은 유저 비밀번호 가져오기
    String findPassword = findUser.getPassword();
    
    // 4. 비밀번호 비교하기 (틀리면 예외처리)
    if (!password.equals(findPassword)) {
        throw new RuntimeException("비밀번호가 맞지 않습니다.");
    }
    
    // 5. 유저 반환
    return findUser;
}

5. UserController - 세션 저장

// 1. service에서 찾은 유저 가져오기
User user = userService.login(request);

// 2. 세션 가져오기 (없으면 새로 생성)
HttpSession session = servletRequest.getSession();

// 3. 세션에 유저 저장하기
session.setAttribute("loginUser", user); // 키, 값

// 4. 반환 객체 만들기
ResponseEntity<String> response = new ResponseEntity<>("로그인 성공", HttpStatus.OK);

// 5. 반환
return response;

Cookie는 servletRequest.getSession() 호출하면 Spring이 자동으로
세션 생성, 세션 ID를 쿠키에 담아서 브라우저에 전달

Postman 테스트

users 테이블 정보

로그인 성공

로그인 실패

실습하며 헷갈린 부분 정리

✔️ HttpServletRequest가 뭔지?

클라이언트가 서버에 보낸 요청 정보를 담고 있는 객체
세션, 쿠키, 헤더 등을 꺼낼 수 있다

✔️ 세션 처리는 Controller vs Service?

세션 처리는 Controller 담당
Service는 비즈니스 로직만 담당하고, 세션 저장은 Controller가 담당

✔️ session.setAttribute("키", 값)

"키" → 세션에 저장할 때 쓰는 이름표, 나중에 꺼낼 때 이 이름으로 찾는다.
값 → 실제로 저장할 데이터, 이번 실습에는 유저 객체를 저장
예시 : session.setAttribute("loginUser", user) → "loginUser"라는 이름으로 user 객체 저장

✔️ getSession() vs getSession(false)

getSession() → 세션 없으면 새로 생성 (로그인할 때)
getSession(false) → 세션 없으면 null 반환 (다른 API에서 확인할 때)

느낀 점

오늘 Lv4 로그인 기능을 구현하면서 처음에는 막막할 줄 알았는데, Cookie와 Session 개념을 먼저 공부하고 실습에 들어가니 생각보다 어렵지 않았다.

어려웠다기보다는 처음 써보는 기능이라 코드에 어떻게 녹여야 할지 감이 잡히지 않았다. 특히 HttpServletRequest가 왜 필요한지 이해하는 데 시간이 걸렸는데, 여기저기 알아본 결과 "클라이언트가 보낸 요청 봉투" 라고 생각하니 자연스럽게 이해가 되었다.

session.setAttribute()도 처음엔 낯설었지만 키와 값의 개념을 이해하고 나서는 전혀 어렵지 않았다.

이번 실습때는 바로 코드부터 보지 않고 개념부터 내가 헷갈리지 않을 정도로 잡고 시작했더니 전보다 수월했다. 앞으로도 처음 접하는 개념은 먼저 확실히 이해하고 코드로 넘어가는 방식으로 공부법을 바꿔야겠다!

️ NEXT

수정/삭제 API에 세션 검증 추가 (비밀번호 검증 → 로그인 여부 확인으로 변경)
지금까지 배운 내용을 새로운 주제로 처음부터 혼자 구현해보기

TIL 끝⎝⍥⎠⎝⍢⎠⋆◡̎⋆

[TIL] Spring 숙련 - JPA & Cookie/Session 정리

mooncommit — Thu, 16 Apr 2026 16:28:05 +0900

To Do List

ResponseEntity 이해
JPA 어노테이션 (@Entity, @Id, @GeneratedValue 등)
연관관계 (@ManyToOne, @JoinColumn)
Cookie/Session 인증/인가
Bean Validation (@Valid 등)

Part 1 : ResponseEntity

✔️ 개념 설명

Spring에서 API를 만들 때, 클라이언트에게 응답을 돌려줄 때 쓰는 클래스

일반적으로 그냥 값만 리턴할 수도 있지만, ResponseEntity를 쓰면

HTTP 상태 코드 (200, 400, 404 등)
응답 헤더
응답 바디 (데이터)

이 세 가지를 한 번에 제어할 수 있다.

✔️ 예시 비교

ResponseEntity 없이

@GetMapping("/user/{id}")
public UserResponseDto getUser(@PathVariable Long id) {
    return userService.getUser(id);
}

→ 데이터는 주지만, HTTP 상태 코드를 직접 제어 못함

ResponseEntity 사용

@GetMapping("/user/{id}")
public ResponseEntity<UserResponseDto> getUser(@PathVariable Long id) {
    UserResponseDto user = userService.getUser(id);
    return ResponseEntity.ok(user); // 200 OK + 데이터
}

자주 쓰는 패턴

// 200 OK
return ResponseEntity.ok(data);

// 201 Created (생성 성공)
return ResponseEntity.status(HttpStatus.CREATED).body(data);

// 400 Bad Request
return ResponseEntity.badRequest().body("잘못된 요청입니다");

// 404 Not Found
return ResponseEntity.status(HttpStatus.NOT_FOUND).body("유저를 찾을 수 없습니다");

️ 실전 예시(전체 흐름)

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    @PostMapping
    public ResponseEntity<UserResponseDto> createUser(@RequestBody UserRequestDto requestDto) {
        UserResponseDto responseDto = userService.createUser(requestDto);
        return ResponseEntity.status(HttpStatus.CREATED).body(responseDto); // 201
    }

    @GetMapping("/{id}")
    public ResponseEntity<UserResponseDto> getUser(@PathVariable Long id) {
        UserResponseDto responseDto = userService.getUser(id);
        return ResponseEntity.ok(responseDto); // 200
    }
}

⭐️ Key Point ⭐️

상황코드HTTP 상태

조회 성공	ResponseEntity.ok(data)	200
생성 성공	ResponseEntity.status(CREATED).body(data)	201
잘못된 요청	ResponseEntity.badRequest().body(msg)	400
찾을 수 없음	ResponseEntity.status(NOT_FOUND).body(msg)	404

Part 2 : JPA 어노테이션

✔️ 개념 설명

JPA는 Java 객체와 데이터베이스 테이블을 자동으로 연결해주는 기술

어노테이션을 클래스/필드에 붙여주면 JPA가 알아서 테이블을 만들고 관리

✔️ 핵심 어노테이션 살펴보기

@Entity

@Entity
public class User {
    // 이 클래스가 DB 테이블과 연결된다는 선언
}

이 클래스가 DB 테이블과 매핑된다고 JPA에게 알려주는 것
@Entity가 없으면 JPA가 그냥 일반 클래스로 취급

@Id

@Entity
public class User {
    @Id  // 이 필드가 기본 키(PK)야!
    private Long id;
}

테이블의 Primary Key가 될 필드에 붙인다

@GeneratedValue

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;  // DB가 알아서 1, 2, 3... 자동 증가
}

PK를 자동으로 생성하는 전략을 설정
IDENTITY = DB가 알아서 번호 매겨줌 (MySQL의 AUTO_INCREMENT)

️ 실전 예시(전체 Entity)

@Entity
@Table(name = "users")  // 테이블 이름을 "users"로 지정 (생략하면 클래스명 그대로)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)  // NOT NULL 조건
    private String username;

    @Column(nullable = false, unique = true)  // 중복 불가
    private String email;

    private String password;
}

이렇게 클래스 하나를 만들면 테이블이 자동으로 생성

id	username	email	password
1	hong	hong@test.com	1234
2	kim	kim@test.com	5678

@Repository

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // JPA가 기본 CRUD를 자동으로 제공
    // save(), findById(), findAll(), delete() 등등
}

DAO 역할을 하는 인터페이스에 붙인다
JpaRepository<엔티티, PK타입> 를 상속받으면 기본 CRUD 메서드 사용 가능

DAO (Data Access Object)란?
데이터베이스에 접근하는 역할만 담당하는 객체 (데이터 조회 / 저장 / 수정 / 삭제)

@NoArgsConstructor / @AllArgsConstructor / @RequiredArgsConstructor (feat. Lombok)

JPA는 기본 생성자가 반드시 필요

@Entity
@NoArgsConstructor  // 기본 생성자 자동 생성 (JPA 필수!)
@AllArgsConstructor // 전체 필드 생성자 자동 생성
@RequiredArgsConstructor // final 필드만 생성자 생성
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
    private String email;
}

@Getter / @Setter (feat. Lombok)

JPA Entity에서 필드에 접근하려면 getter/setter가 필요한데, Lombok으로 자동 생성

@Entity
@Getter         // 모든 필드의 getter 자동 생성
@Setter         // 모든 필드의 setter 자동 생성
@NoArgsConstructor
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
}

단, Entity에 @Setter는 신중하게 써야 한다.
아무데서나 값을 바꿀 수 있어서 나중에 버그 찾기 힘들어지기 때문에 필요한 메서드만 따로 만드는 것을 추천!

️ 최종 실전 Entity 예시

@Entity
@Getter
@NoArgsConstructor
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String username;

    @Column(nullable = false, unique = true)
    private String email;

    private String password;

    // 생성자는 필요한 필드만 받아서 직접 만들기
    public User(String username, String email, String password) {
        this.username = username;
        this.email = email;
        this.password = password;
    }
}

Part 3 : 연관관계 (@ManyToOne, @OneToMany)

✔️ 개념 설명

DB 테이블끼리 관계가 있을 때 JPA에서 표현하는 방법이다

예시 : 게시글(Post) 과 유저(User) 관계

유저 1명은 게시글을 여러 개 쓸 수 있다
게시글 1개는 한 명의 유저가 작성

@ManyToOne - 많은 쪽에 붙인다

@Entity
@Getter
@NoArgsConstructor
public class Post {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;
    private String content;

    @ManyToOne  // Post → User
    @JoinColumn(name = "user_id")  // FK 컬럼 이름 지정
    private User user;
}

posts 테이블에 user_id 컬럼이 자동으로 생긴다

id	title	content	user_id
1	안녕	내용1	1
2	반가워	내용2	1
3	잘가	내용3	2

@ManyToOne 읽는 법 : "나(Many)는 저쪽(One)에 속해있어!"

Many (많은 쪽)	One (하나인 쪽)
게시글 (여러개)	유저 (1명)
학생 (여러명)	반 (1개)
주문 (여러개)	고객 (1명)
댓글 (여러개)	게시글 (1개)

@OneToMany - 일반적으로 잘 안 쓴다

@Entity
@Getter
@NoArgsConstructor
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    @OneToMany(mappedBy = "user")  // Post의 user 필드랑 연결
    private List<Post> posts = new ArrayList<>();
}

단방향을 기본으로 쓴다. @ManyToOne만 쓰는 게 기본이고,
@OneToMany는정말 필요할 때만 추가한다. 양방향으로 하면 관리가 복잡해짐!

@JoinColumn

@ManyToOne
@JoinColumn(name = "user_id")  // DB의 FK 컬럼 이름
private User user;

어떤 컬럼으로 JOIN할지 지정
생략하면 JPA가 자동으로 이름 만들어주는데, 명시적으로 써주는 게 좋다!

️ 전체 흐름 예시

// 유저 저장
User user = new User("스파르타", "moon@test.com", "1234");
userRepository.save(user);

// 게시글 저장 (유저 연결)
Post post = new Post("제목", "내용", user);
postRepository.save(post);

// 게시글에서 유저 정보 가져오기
Post findPost = postRepository.findById(1L).orElseThrow();
String username = findPost.getUser().getUsername(); // "스파르타"

⭐️ Key Point ⭐️

어노테이션	의미	사용 위치
@ManyToOne	많은 → 적은	Post에서 User를 참조
@OneToMany	적은 → 많은	필요할 때만 사용
@JoinColumn	FK 컬럼 지정	@ManyToOne 옆에

단방향 원칙 기억하기! @ManyToOne 하나만 쓰는 게 기본!
@OneToMany는 진짜 필요할 때만 추가! (거의 없음)

Part 4 : Cookie/Session 인증/인가

✔️ 개념 설명

로그인 기능을 만들 때 사용하는 방법

왜 Cookie/Session이 필요할까?

HTTP의 특징 - "무상태(Stateless)"

HTTP는 기본적으로 요청이 끝나면 상태를 기억 못한다!

클라이언트: "나 스파르타야, 로그인할게!"
서버: "오케이 로그인 됐어!"

-- 1초 후 --

클라이언트: "내 게시글 목록 줘!"
서버: "너 누구야...?"  // 기억 못함!!

이 문제를 해결하는 게 Cookie/Session 이다.

Cookie vs Session 차이

	Cookie	Session
저장 위치	클라이언트 (브라우저)	서버
보안	상대적으로 취약	상대적으로 안전
용량	작음 (4KB)	큼

동작 흐름

1. 로그인 요청
클라이언트 → 서버: "아이디/비밀번호 보낼게!"

2. 서버가 Session 생성
서버: "맞네! Session 만들어서 저장해놓을게"
서버 메모리: { "ABC123": { userId: 1, username: "스파르타" } }

3. Cookie에 SessionId 전달
서버 → 클라이언트: "이 SessionId(ABC123) 가지고 있어!"
브라우저: 쿠키에 ABC123 저장

4. 다음 요청부터 자동으로 Cookie 전송
클라이언트 → 서버: "게시글 줘!" + Cookie(ABC123)
서버: "ABC123으로 조회해보니 스파르타네! 게시글 줘야겠다"

실제 코드

️ 로그인 (Session 저장)

@PostMapping("/login")
public ResponseEntity<String> login(
        @RequestBody LoginRequestDto requestDto,
        HttpServletRequest request) {

    // 1. 유저 확인
    User user = userService.login(requestDto);

    // 2. Session 생성 & 저장
    HttpSession session = request.getSession();
    session.setAttribute("loginUser", user.getId());

    return ResponseEntity.ok("로그인 성공!");
}

️ 로그아웃 (Session 삭제)

@PostMapping("/logout")
public ResponseEntity<String> logout(HttpServletRequest request) {

    // Session 무효화 (삭제)
    HttpSession session = request.getSession(false);
    if (session != null) {
        session.invalidate();
    }

    return ResponseEntity.ok("로그아웃 성공!");
}

️ 인가 (로그인한 사람만 접근 가능)

@GetMapping("/posts")
public ResponseEntity<?> getPosts(HttpServletRequest request) {

    // Session에서 로그인 정보 확인
    HttpSession session = request.getSession(false);
    if (session == null || session.getAttribute("loginUser") == null) {
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
                             .body("로그인이 필요합니다!");
    }

    // 로그인 된 경우만 실행
    Long userId = (Long) session.getAttribute("loginUser");
    return ResponseEntity.ok(postService.getPosts(userId));
}

⭐️ Key Point ⭐️

로그인  → Session 생성 → Cookie에 SessionId 저장
요청마다 → Cookie 자동 전송 → 서버가 Session 확인
로그아웃 → Session 삭제

인증(Authentication) = "너 누구야?" (로그인 확인)
인가(Authorization) = "너 이거 해도 돼?" (권한 확인)

Part 5 : Bean Validation (@Valid 등)

✔️ 개념 설명

클라이언트가 보내는 데이터를 검증하는 방법

예를 들어 회원가입할 때 :

이메일 형식이 맞는지
비밀번호가 최소 8자 이상인지
이름이 비어있지 않은지

이런 걸 일일이 if문으로 체크하면 너무 번거롭기 때문에

어노테이션 하나로 검증할 수 있게 해주는 게 Bean Validation이다!

검증 없이 짜면

//   검증 없이 짜면 이렇게 됨
@PostMapping("/signup")
public ResponseEntity<String> signup(@RequestBody SignupRequestDto requestDto) {

    if (requestDto.getUsername() == null || requestDto.getUsername().isEmpty()) {
        return ResponseEntity.badRequest().body("이름을 입력해주세요!");
    }
    if (requestDto.getEmail() == null || !requestDto.getEmail().contains("@")) {
        return ResponseEntity.badRequest().body("이메일 형식이 맞지 않습니다!");
    }
    if (requestDto.getPassword() == null || requestDto.getPassword().length() < 8) {
        return ResponseEntity.badRequest().body("비밀번호는 8자 이상이어야 합니다!");
    }
    // ... 끝도 없이 계속됨
}

@Valid 사용하면?

// @Valid 사용하면 이렇게 깔끔해짐!
@PostMapping("/signup")
public ResponseEntity<String> signup(@Valid @RequestBody SignupRequestDto requestDto) {
    // 검증은 DTO에서 알아서 다 해줌!
    userService.signup(requestDto);
    return ResponseEntity.ok("회원가입 성공!");
}

자주 쓰는 검증 어노테이션

@Getter
public class SignupRequestDto {

    @NotBlank(message = "이름은 필수입니다!")
    // null, "", "   " 모두 거부
    private String username;

    @Email(message = "이메일 형식이 올바르지 않습니다!")
    // hong@test.com 같은 형식인지 체크
    private String email;

    @Size(min = 8, max = 20, message = "비밀번호는 8~20자여야 합니다!")
    // 글자 수 체크
    private String password;

    @Min(value = 1, message = "나이는 1살 이상이어야 합니다!")
    @Max(value = 150, message = "나이는 150살 이하여야 합니다!")
    // 숫자 범위 체크
    private int age;

    @NotNull(message = "약관 동의는 필수입니다!")
    // null만 거부 (빈 문자열은 허용)
    private Boolean agreeTerms;
}

️ @NotNull vs @NotEmpty vs @NotBlank 차이

String a = null;     // null
String b = "";       // 빈 문자열
String c = "   ";    // 공백만 있는 문자열
String d = "홍길동"; // 정상

@NotNull  → null만 거부   → b, c, d 통과 / a 거부
@NotEmpty → null, "" 거부 → c, d 통과   / a, b 거부
@NotBlank → null, "", "  " 모두 거부 → d만 통과

문자열 검증할 땐 @NotBlank를 제일 많이 쓴다! 공백만 입력하는 경우까지 막아줌

검증 실패할 때 처리 방법

@Valid 검증이 실패하면 MethodArgumentNotValidException이 발생한다.

이걸 @ExceptionHandler로 잡아서 처리할 수 있다!

@RestControllerAdvice  // 전역 예외 처리 클래스
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<String> handleValidationException(
            MethodArgumentNotValidException e) {

        // 첫 번째 에러 메시지만 꺼내기
        String errorMessage = e.getBindingResult()
                .getAllErrors()
                .get(0)
                .getDefaultMessage();

        return ResponseEntity.badRequest().body(errorMessage);
        // 예: "이름은 필수입니다!" 반환
    }
}

✔️ 전체 흐름 정리

클라이언트: POST /signup  { username: "", email: "잘못된형식", password: "123" }
                ↓
Controller: @Valid 검증 시작!
                ↓
검증 실패! MethodArgumentNotValidException 발생
                ↓
GlobalExceptionHandler가 잡아서 처리
                ↓
클라이언트: 400 Bad Request "이름은 필수입니다!"

⭐️ 자주 쓰는 어노테이션 정리

@NotBlank	문자열 필수 입력 (공백 불가)
@NotNull	null 불가
@Email	이메일 형식 체크
@Size(min, max)	문자열 길이 체크
@Min(value)	최솟값 체크
@Max(value)	최댓값 체크
@Pattern(regexp)	정규식으로 형식 체크

다음 글 : [Spring 숙련] 일정 관리 앱 만들기 - 일정 CRUD 구현

[TIL] Spring 개념 정리 | DI / IoC / Bean / MVC 요청 흐름

mooncommit — Wed, 15 Apr 2026 23:57:02 +0900

To Do List

DI (Dependency Injection, 의존성 주입)
IoC (Inversion of Control, 제어의 역전)
Spring Bean (빈 스코프 & 생명주기)
왜 Spring Bean은 기본적으로 싱글톤으로 설계했을까?
요청이 들어왔을 때, 디스패처 서블릿이 컨트롤러를 어떻게 찾아주는가

Part 1 : DI (Dependency Injection, 의존성 주입)

의존성은 무엇일까?

코드에서 A가 B를 사용한다면, "A는 B에 의존한다" 라고 말한다.

️ 코드 예시

public class OrderService {
    private PaymentService paymentService = new PaymentService(); // 직접 생성
    
    public void order() {
        paymentService.pay();
    }
}

OrderService는 PaymentService에 의존하고 있다.

코드에서 OrderService가 PaymentService를 직접 new로 생성했는데 왜 문제일까?

"직접 만들지 말고, 외부에서 받아라"

// DI 적용 전 — 내가 직접 생성
public class OrderService {
    private PaymentService paymentService = new PaymentService();
}

// DI 적용 후 — 외부에서 주입받음
public class OrderService {
    private PaymentService paymentService; // 선언만

    // 생성자를 통해 외부에서 주입
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

OrderService는 PaymentService가 어떻게 만들어졌는지 몰라도 된다. 그냥 주어진 걸 사용하기만 하면 된다.

그래서 나중에 PaymentService를 MoonPayService로 바꿔도 OrderService 코드는 전혀 수정할 필요가 없다.

✔️ DI를 해주는 3가지 방법

// 방법 1 : 생성자 주입 (Spring에서 가장 권장하는 방법)
@Service
public class OrderService {
    private final PaymentService paymentService;

	@Autowired // 생략 가능
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

// 방법 2 : Setter 주입
@Service
public class OrderService {
    private PaymentService paymentService;

    @Autowired
    public void setPaymentService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

// 방법 3 : 필드 주입 (간단하지만 권장하지 않음)
@Service
public class OrderService {
    @Autowired
    private PaymentService paymentService;
}

생성자 주입을 사용하는 이유는 final로 선언할 수 있어서 값이 바뀌지 않게 만들 수 있고,
테스트할 때도 직접 값을 넣어주기 쉽기 때문이다.

Part 2 : IoC (Inversion of Control, 제어의 역전)

IoC는 “제어권이 뒤집혔다”는 의미다.
원래는 내가 직접 객체를 만들고 흐름을 제어하지만, IoC에서는 이 제어를 스프링이 대신 관리해준다.

// 내가 제어 (IoC 없음)
PaymentService pay = new PaymentService();
OrderService order = new OrderService(pay);
order.order();

IoC가 적용되면 객체 생성과 흐름을 제어하는 권한이 나에게서 프레임워크(Spring)로 넘어간다.

// Spring이 제어 (IoC 있음)
// 개발자는 그냥 이것만 씀
@Autowired
private OrderService orderService; // Spring이 알아서 만들고 주입해줌

개발자는 객체를 어떻게 만들지 직접 구현하는 게 아니라, 어떤 것이 필요한지만 선언하면 된다.

DI와 IoC의 관계 정리

IoC는 개념이고, DI는 그걸 구현하는 방법이다.

IoC : 제어권을 프레임워크(Spring)에게 넘긴다는 설계 개념
DI : 필요한 객체를 직접 생성하지 않고 외부에서 주입받는 방식

즉, Spring은 IoC를 실현하기 위해 DI를 사용한다고 보면 된다.
정리하면 DI는 “내가 직접 new 하지 않고 받는 것”, IoC는 “그 제어권 자체가 Spring으로 넘어간 것”이다.

Part 3 : Spring Bean — 빈 스코프 & 생명주기

✔️ Bean이 무엇일까?

Spring이 IoC 컨테이너에서 직접 관리하는 객체를 Bean(빈) 이라고 한다.

그냥 new OrderService()로 직접 만든 객체는 빈이 아니다.
Spring 컨테이너에 등록되어서, Spring이 생성하고 주입하고 소멸까지 관리해주는 객체만 빈이라고 한다.

빈 스코프 (Bean Scope)

스코프 = "이 빈을 얼마나 넓은 범위에서 공유하냐"

자주 쓰는 스코프 3가지

싱글톤 : 컨테이너에 하나만 만들어두고 모두가 함께 사용한다. Spring의 기본값이다.

프로토타입 : 요청할 때마다 새로운 객체를 만들어준다. 각각 독립적인 상태가 필요할 때 사용한다.

리퀘스트 : 웹 요청이 들어올 때 생성되고, 요청이 끝나면 사라진다. 같은 요청 안에서는 하나를 공유한다.

빈 생명주기 (Lifecycle)

빈이 태어나서 죽기까지의 전체 흐름

Spring 컨테이너 시작
    ↓
1. 빈 생성 (객체 new)
    ↓
2. 의존관계 주입 (DI)
    ↓
3. 초기화 콜백 (@PostConstruct)  "다 준비됐으면 이 메서드 실행해줘"
    ↓
4. 사용 (비즈니스 로직 실행)
    ↓
5. 소멸 전 콜백 (@PreDestroy)    "죽기 전에 이 메서드 실행해줘"
    ↓
Spring 컨테이너 종료

️ 코드 예시

@Component
public class DatabaseConnector {

    @PostConstruct
    public void init() {
        // 빈이 완전히 준비된 직후 실행
        // DB 연결 풀 초기화, 캐시 로딩 등
        System.out.println("DB 연결 초기화!");
    }

    @PreDestroy
    public void cleanup() {
        // 빈이 소멸되기 직전 실행
        // DB 연결 종료, 리소스 반납 등
        System.out.println("DB 연결 종료!");
    }
}

@PostConstruct는 의존성 주입이 모두 끝난 후 실행된다.
생성자에서는 아직 주입이 안 끝났을 수 있기 때문에, 초기화 로직은 여기서 처리하는 것이 좋다.

Part 4 : 왜 Spring Bean은 기본적으로 싱글톤으로 설계했을까?

이건 단순히 “그렇게 만들어진 것”이 아니라, 분명한 이유가 있다. 웹 서버의 특성을 먼저 이해해야 한다.

✔️ 웹 서버 환경

실제 서비스에서는 수천 명이 동시에 요청을 보낸다.

이때 요청마다 OrderService, UserService, PaymentService를 매번 new로 생성하면 메모리가 금방 부족해진다.

그래서 Spring은 기본적으로 싱글톤을 사용한다.

✔️ 첫째, 메모리 효율
OrderService 같은 서비스 객체는 상태가 없고 로직만 있기 때문에 하나만 만들어 여러 요청이 함께 사용해도 문제없다.

✔️ 둘째, 성능
객체를 생성하는 데는 메모리 할당과 초기화 비용이 든다. 요청마다 반복하면 낭비가 크지만,

싱글톤은 한 번만 만들어 재사용하므로 훨씬 효율적이다.

✔️ 셋째, Spring의 DI 구조와 잘 맞는다.
Spring은 객체를 한 번 생성해두고 필요한 곳에 주입하는 방식이기 때문에, 싱글톤 구조가 자연스럽게 어울린다.

싱글톤의 주의점은?

싱글톤은 상태(인스턴스 변수)를 가지면 위험하다.

// 위험한 코드!
@Service
public class OrderService {
    private int orderCount = 0; // 인스턴스 변수 (상태)

    public void order() {
        orderCount++; // 여러 사용자가 동시에 이걸 바꾸면?
    }
}

싱글톤 객체는 모든 사용자가 함께 쓰기 때문에, 사용자 A가 바꾼 값을 사용자 B도 보게 될 수 있다. 이게 동시성 문제다.

그래서 Spring 빈은 상태를 가지지 않는 방식으로 설계하는 것이 중요하다.
메서드 안에서만 사용하는 지역변수는 괜찮지만, 여러 요청이 함께 쓰는 인스턴스 변수는 문제가 될 수 있다.

// 올바른 코드
@Service
public class OrderService {
    // 인스턴스 변수 없음. 상태 없음.

    public void order(int count) {
        int localCount = count; // 지역변수는 각 스레드마다 독립적이라 안전
        // 비즈니스 로직...
    }
}

Spring 빈이 기본적으로 싱글톤인 이유는 웹 환경에서 많은 요청을 처리할 때 메모리와 성능을 효율적으로 사용할 수 있고, 서비스 객체는 보통 상태가 없어서 여러 요청이 함께 사용해도 안전하기 때문이다.

Part 5 : 요청이 들어왔을 때, 디스패처 서블릿이 컨트롤러를 어떻게 찾아주는가

이걸 이해하려면 3단계로 나눠서 보면 된다.

✔️ 1단계 : 전체 흐름을 먼저 큰 그림으로 이해하기
✔️ 2단계 : 핵심 구성 요소가 무엇인지 파악하기
✔️ 3단계 : 각 단계를 하나씩 자세히 살펴보기

1단계 : 큰 그림

DispatcherServlet = 프론트 컨트롤러란
모든 클라이언트 요청을 가장 먼저 받는 입구 역할, 요청을 직접 처리하지 않고, 어디로 보낼지 “교통정리”만 함

흐름을 말로 푼다면

클라이언트 요청이 들어온다
DispatcherServlet이 받는다 (입구)
어떤 컨트롤러가 처리할지 찾는다 (Handler Mapping)
실제 컨트롤러 실행 (Handler Adapter 통해서)
결과(ModelAndView) 받음
View 찾아서 렌더링
최종 응답 반환

2단계 : 핵심 부품들
Spring MVC 핵심 구성요소

Spring MVC는 DispatcherServlet을 중심으로 "누가 처리할지 찾고 → 실행하고 → 결과를 화면으로 바꿔주는 구조"이다.

DispatcherServlet

모든 요청의 시작점 (입구)
클라이언트 요청 = 무조건 여기로 들어옴
전체 흐름을 컨트롤하는 "총괄 관리자"

HandlerMapping

"이 요청 누가 처리함?" 담당
서버 시작 시 : @RequestMapping, @GetMapping 등 전부 스캔, URL ↔ Controller 매핑 테이블 생성

@RequestMapping

정보를 쭉 스캔해서 URL과 컨트롤러를 매핑해 저장

HandlerAdapter

실제로 컨트롤러를 실행시켜주는 어댑터
왜 필요할까? : 컨트롤러가 여러 종류일 수 있다. (@Controller, 옛날 방식 등) 어댑터가 중간에서 형식 맞춰서 실행

Controller

개발자가 작성한 비즈니스 로직 결과로 ModelAndView 또는 @ResponseBody (JSON) 를 반환

ViewResolver

컨트롤러가 "home"이라는 뷰 이름을 반환하면, 실제 파일 경로 (/templates/home.html)로 변환해주는 역할

한 줄 정리
DispatcherServlet → HandlerMapping → HandlerAdapter → Controller → ViewResolver

3단계: 단계별 초세세 흐름

① HandlerMapping 조회 — "이 URL 담당이 누구야?"

서버가 처음 뜰 때, Spring이 @Controller 달린 클래스들을 다 스캔해서 이런 표를 만든다.

GET /users         →  UserController.getUsers()
POST /orders       →  OrderController.createOrder()
GET /products/{id} →  ProductController.getProduct()

요청이 들어오면 디스패처 서블릿이 이 표에서 URL을 찾아서 담당 컨트롤러 메서드를 꺼낸다.

이게 HandlerMapping의 역할

② HandlerAdapter — "컨트롤러를 표준 방식으로 실행"

컨트롤러를 찾았다고 바로 실행할 수 있는 건 아니다.
디스패처 서블릿이 컨트롤러를 직접 호출하면, 컨트롤러 방식이 바뀔 때마다 디스패처 서블릿 코드도 함께 수정해야 한다.

그래서 다양한 컨트롤러를 일관된 방식으로 실행하기 위해 중간에 HandlerAdapter를 두었다.

DispatcherServlet → HandlerAdapter.handle() → 실제 컨트롤러 메서드 호출

어댑터가 파라미터 바인딩(@PathVariable, @RequestParam, @RequestBody 파싱)도 여기서 다 처리해준다.

③ Controller 실행 → ModelAndView 반환

컨트롤러가 실행되고, 두 가지 방식으로 결과를 돌려준다.

// 방식 1 : 뷰 이름 반환 (서버사이드 렌더링)
@GetMapping("/home")
public String home(Model model) {
    model.addAttribute("username", "home");
    return "home"; // → ViewResolver가 home.html 찾아줌
}

// 방식 2 : JSON 반환 (REST API)
@GetMapping("/api/users")
@ResponseBody  // 또는 클래스에 @RestController
public List<User> getUsers() {
    return userList; // → 뷰 없이 바로 JSON으로 직렬화
}

@ResponseBody가 붙으면 ViewResolver를 아예 안 거치고 바로 HTTP 응답 바디에 JSON을 쓴다.

④ ViewResolver — "뷰 이름을 실제 파일로"

"home"  →  /templates/home.html
"error" →  /templates/error.html

application.properties에 이렇게 설정해두면

spring.thymeleaf.prefix=classpath:/templates/
spring.thymeleaf.suffix=.html

"home" 이라는 이름만 받아도 알아서 /templates/home.html 파일을 찾아서 렌더링해준다.

전체 흐름

1. 브라우저가 GET /users 요청 전송

2. DispatcherServlet이 요청 수신
   (모든 요청의 단일 진입점)

3. HandlerMapping에게 물어봄
   "GET /users 담당 컨트롤러가 누구야?"
   → UserController.getUsers()반환

4. HandlerAdapter에게 실행 요청
   "이 컨트롤러 메서드 실행해줘"
   → 파라미터 바인딩, 실행

5. UserController.getUsers()실행
   → "users" 뷰 이름 + User 데이터 반환

6. ViewResolver에게 뷰 이름 전달
   "users"라는 이름의 실제 파일 찾아줘
   → /templates/users.html 반환

7. users.html에 데이터 채워서 HTML 완성
   → 클라이언트에게 응답

️ 디스패처 서블릿은 직접 하지 않고,
✔️ "누가 할지"는 HandlerMapping한테 물어보고
✔️ "실행"은 HandlerAdapter한테 시킨다.

정리 끝⎝⍢⎠

Layer Architecture + JPA로 User CRUD API 만들기

mooncommit — Thu, 9 Apr 2026 20:06:56 +0900

2026. 04. 09

TO DO LIST

3 Layer Architecture 구조 이해하기 Done
Entity, JPA 개념 잡기 Done
Repository, Service, Controller 작성하기 Done
DTO (Request / Response) 설계하기 Done
User CRUD API 완성 (저장, 조회, 수정, 삭제) Done
ResponseEntity로 HTTP 상태코드 응답 처리하기 Todo

···

Architecture

3 Layer Architecture 란?

오늘 실습의 핵심 뼈대. 역할에 따라 계층을 나눠서 코드를 관리하는 구조다. 각 계층이 딱 자기 역할만 하도록 분리하는 게 핵심이다.

Client → Controller → Service → Repository → DB

계층	역할
Controller	요청을 받고 응답을 돌려주는 창구
Service	비즈니스 로직 처리 (Request → Entity → Response)
Repository	DB에 직접 접근하는 유일한 계층

Entity

Entity가 뭔지 이해하는 데 시간이 걸렸다

처음엔 그냥 클래스 아닌가 싶었는데, JPA를 쓰면 이 클래스가 DB 테이블이랑 1:1로 매핑된다는 걸 배웠다. DB의 행(row) 하나 = Java 객체 하나.

@Getter
@Entity
@Table(name = "users")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(length = 50, nullable = false)
    private String name;

    @Column(unique = true, nullable = false)
    private String email;
    private String address;
}

@NoArgsConstructor(access = AccessLevel.PROTECTED) — JPA는 내부적으로 기본 생성자가 필요하다. 근데 외부에서 new User()처럼 텅 빈 객체를 만드는 건 막고 싶어서 PROTECTED로 설정한다. JPA는 쓸 수 있되, 개발자가 실수로 쓰는 건 컴파일 타임에 막아주는 안전장치.

JPA & Repository

SQL 없이 DB를 다루는 방법

JPA는 Java 코드로 DB를 다룰 수 있게 해주는 기술이다. 우리가 Java로 메서드를 호출하면 JPA가 알아서 SQL로 번역해서 DB에 보내준다.

Repository는 JpaRepository를 상속받는 것만으로 기본 CRUD 기능을 다 가져온다. 코드 안에 아무것도 안 써도 된다.

public interface UserRepository extends JpaRepository<User, Long> {
    // 아무것도 안 써도 save, findById, findAll, delete 다 됨
}

JpaRepository<User, Long> — 첫 번째는 다룰 엔티티, 두 번째는 그 엔티티의 PK 타입. User의 id가 Long이라서 Long을 넣었다.

DTO

Entity를 그대로 쓰면 안 되는 이유

처음엔 Entity를 그대로 반환하면 되지 않나 싶었는데, 두 가지 문제가 있다는 걸 배웠다. 첫째로 password 같은 민감한 정보까지 노출될 수 있고, 둘째로 DB 구조가 바뀌면 API 응답도 같이 바뀌어버린다.

DTO	용도	특징
CreateUserRequest	클라이언트 → 서버	id 없음, final 없음 (Spring이 채워줌)
CreateUserResponse	서버 → 클라이언트	id 있음, final 있음 (값 변경 불가)

Request에 id가 없는 이유 — id는 DB가 자동 생성하는 값이라 클라이언트가 아직 알 수 없다. 저장되고 나서야 id가 생기기 때문에 Response에만 id가 들어간다.

Service

비즈니스 로직이 뭔지 알게 됐다

Service는 데이터를 저장하는 곳이 아니라, 받아서 처리하고 넘겨주는 곳이다. Request를 Entity로 변환 → Repository에 저장 → 결과를 Response로 변환해서 반환하는 흐름을 담당한다.

@Transactional
public CreateUserResponse save(CreateUserRequest request) {
    User user = new User(
        request.getName(), request.getEmail(), request.getAddress()
    );
    User savedUser = userRepository.save(user);

    return new CreateUserResponse(
        savedUser.getId(), savedUser.getName(),
        savedUser.getEmail(), savedUser.getAddress()
    );
}

Controller

@RestController vs @Controller

옛날 방식은 서버에서 HTML까지 직접 만들어서 돌려줬다. 요즘은 프론트엔드가 화면을 담당하고 서버는 JSON 데이터만 주고받기 때문에 @RestController를 쓴다. @Controller에 JSON 자동 변환이 더해진 것!

@RestController
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @PostMapping("/users")
    public CreateUserResponse createUser(@RequestBody CreateUserRequest request) {
        return userService.save(request);
    }

    @GetMapping("/users/{userId}")
    public GetOneUserResponse getOneUser(@PathVariable Long userId) {
        return userService.getOne(userId);
    }

    @PutMapping("/users/{userId}")
    public UpdateUserResponse update(@PathVariable Long userId,
                                         @RequestBody UpdateUserRequest request) {
        return userService.update(userId, request);
    }

    @DeleteMapping("/users/{userId}")
    public void delete(@PathVariable Long userId) {
        userService.delete(userId);
    }
}

···

오늘 학습을 마치며

아직도 많이 어렵지만 어노테이션 하나하나가 왜 붙는지 어떤 역할을 하는지 공부하며 실습해보니 약간은 알 것 같다.

JAVA에서 하던 것처럼(속성, 생성자, 기능 / Main에서 객체 생성) 흐름은 비슷했다.

하지만 Spring은 클라이언트에서 Http 요청을 하면 Layer Architecture 패턴으로 흘러가고 의존성 주입,

그리고 서로 데이터를 주고 받을 때 DTO를 사용하고 또 Entity에서 데이터를 받아

그걸 넘기고 저장하고 이런 흐름인 것 같다. 계속 코딩하다보니 약간의 패턴이 보였다.

아직 많은 컴포넌트가 낯설게 느껴져서 많이 해보며 익숙해져야 할 것 같다.

내일은 ResponseEntity로 HTTP 상태코드까지 응답에 담는 걸 해볼 예정이다.

[TIL] Spring - 실전에 필요한 개념

mooncommit — Wed, 8 Apr 2026 23:55:09 +0900

오늘은 튜터님의 말씀을 듣고, 실전 위주 중요 포인트를 공부했다.

To Do List · 2026.04.08

01 Spring Boot 개념
02 IoC / DI
03 Controller → Service → Repository 흐름
04 MVC 패턴
05 주요 어노테이션
06 Lombok
07 Thymeleaf
08 URL 매핑 어노테이션
09 application.properties
10 프로젝트 폴더 구조

1. Spring Boot란?

Java로 웹 개발을 쉽게 할 수 있게 만든 프레임워크.

기존 Spring은 설정이 너무 복잡했는데, Spring Boot는 그 복잡한 설정을 자동으로 해준다

요즘 Java 백엔드 개발은 거의 다 Spring Boot로 한다.

2. IoC와 DI (Spring의 핵심 원리)

IoC (제어의 역전)

Java에서는 내가 직접 객체를 만들었지만, Spring에서는 Spring이 대신 만들고 관리해준다.

//   순수 Java 방식 - 내가 직접 객체 생성
UserService userService = new UserService();
userService.doSomething();

// ☺️ Spring 방식 - Spring이 알아서 만들어서 넣어줌
@Autowired
UserService userService;   // 선언만 하면 끝!

️ Spring이 관리하는 객체를 'Spring Bean'이라고 한다.
@Component , @Controller , @Service , @Repository 가 붙으면 자동으로 Bean이 된다.

DI (의존성 주입)

Spring이 필요한 객체를 자동으로 넣어주는 것. @Autowired를 쓰면 된다.

@Service
public class MemoService {

    @Autowired
    MemoRepository memoRepository;  // Spring이 자동으로 넣어줌

    public List<Memo> getMemos() {
        return memoRepository.findAll();
    }
}

3. 전체 흐름 (요청이 들어올 때)

사용자가 URL을 요청하면 이 순서로 처리된다.

다시 역순으로 반환

️ DispatcherServlet은 Spring이 알아서 관리해줌. 개발자는 Controller / Service / Repository만 만들면 된다

4. MVC 패턴

애플리케이션을 세 가지 역할로 나눠서 개발하는 방식

5. @Controller — URL 요청 처리

사용자의 HTTP 요청을 받아서 처리하는 클래스

@Controller
public class MemoController {

    @Autowired
    MemoService memoService;

    // GET /memos → 메모 목록 조회
    @GetMapping("/memos")
    public String getMemos(Model model) {
        List<Memo> memos = memoService.getMemos();
        model.addAttribute("memos", memos);  // View로 데이터 전달
        return "memo-list";                  // memo-list.html 렌더링
    }

    // POST /memos → 메모 저장
    @PostMapping("/memos")
    public String createMemo(@RequestParam String contents) {
        memoService.createMemo(contents);
        return "redirect:/memos";  // 저장 후 목록으로 이동
    }

    // GET /memos/1 → 특정 메모 조회
    @GetMapping("/memos/{id}")
    public String getMemo(@PathVariable Long id, Model model) {
        Memo memo = memoService.getMemo(id);
        model.addAttribute("memo", memo);
        return "memo-detail";
    }
}

️ @PathVariable은 URL의 {id} 부분을 받고, @RequestParam은 폼에서 입력한 값을 받는다.

6. @Service — 비즈니스 로직

실제 기능(비즈니스 로직)을 담당하는 클래스. Controller와 Repository 사이에 위치한다.

@Service
public class MemoService {

    @Autowired
    MemoRepository memoRepository;

    // 전체 메모 조회
    public List<Memo> getMemos() {
        return memoRepository.findAll();
    }

    // 특정 메모 조회
    public Memo getMemo(Long id) {
        return memoRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("메모 없음"));
    }

    // 메모 저장
    public void createMemo(String contents) {
        Memo memo = new Memo(contents);
        memoRepository.save(memo);
    }

    // 메모 삭제
    public void deleteMemo(Long id) {
        memoRepository.deleteById(id);
    }
}

7. @Repository — DB 접근

DB에서 데이터를 조회하고 저장하는 역할. JpaRepository를 상속받으면 기본 CRUD가 자동으로 생긴다!

@Repository
public interface MemoRepository extends JpaRepository<Memo, Long> {

    // ✅ 자동 제공되는 메서드:
    // findAll()           → 전체 조회
    // findById(id)        → id로 조회
    // save(memo)          → 저장/수정
    // deleteById(id)      → 삭제
    // count()             → 개수 세기
    // existsById(id)      → 존재 여부 확인

    // 필요하면 직접 추가도 가능:
    List<Memo> findByContentsContaining(String keyword);
}

️ 인터페이스만 만들면 Spring이 구현체를 자동으로 만들어줌. 직접 SQL 안 써도 된다!

8. @Entity — DB 테이블 매핑

이 클래스가 DB 테이블과 1:1로 연결된다는 표시. JPA가 자동으로 테이블을 만들어준다.

@Getter                          // getter 자동 생성 (Lombok)
@Entity                          // DB 테이블과 연결
@Table(name = "memos")           // 테이블 이름 지정
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Memo {

    @Id                          // Primary Key
    @GeneratedValue(strategy = GenerationType.IDENTITY)  // AUTO_INCREMENT
    private Long id;

    @Column(nullable = false, length = 100)
    private String contents;

    public Memo(String contents) {
        this.contents = contents;
    }
}

️ @NoArgsConstructor(access = AccessLevel.PROTECTED)
JPA는 빈 생성자가 필요하지만 public으로 열면 불완전한 객체가 만들어질 수 있어서 protected로 막는다.

9. Lombok — 반복 코드 자동 생성

매번 getter/setter/생성자를 직접 쓰는 게 귀찮으니까 어노테이션 하나로 자동 생성해주는 도구

@Builder 예시

@Builder
@Getter
public class Memo {
    private Long id;
    private String contents;
}

// 사용할 때 - 필요한 것만 골라서 설정 가능
Memo memo = Memo.builder()
        .id(1L)
        .contents("오늘 할 일")
        .build();

10. Thymeleaf — View 화면 만들기

서버에서 HTML을 동적으로 만들어주는 템플릿 엔진. Controller에서 보낸 데이터를 HTML에 채워준다.

Controller에서 데이터 보내기

@GetMapping("/memos")
public String getMemos(Model model) {
    List<Memo> memos = memoService.getMemos();
    model.addAttribute("memos", memos);      // "memos" 이름으로 데이터 전달
    model.addAttribute("title", "메모 목록");
    return "memo-list";  // templates/memo-list.html 렌더링
}

memo-list.html에서 데이터 받기

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<body>

    <!-- ${변수명}으로 데이터 꺼내기 -->
    <h1 th:text="${title}">기본 제목</h1>

    <!-- th:each로 리스트 반복 -->
    <ul>
        <li th:each="memo : ${memos}">
            <span th:text="${memo.id}">id</span>.
            <span th:text="${memo.contents}">내용</span>
        </li>
    </ul>

    <!-- th:if로 조건문 -->
    <p th:if="${memos.isEmpty()}">메모가 없어요!</p>

    <!-- 폼에서 데이터 전송 -->
    <form th:action="@{/memos}" method="post">
        <input type="text" name="contents" placeholder="메모 입력">
        <button type="submit">저장</button>
    </form>

</body>
</html>

11. URL 매핑 어노테이션

@Controller
public class MemoController {

    @GetMapping("/memos")          // GET  /memos      → 목록 조회
    @PostMapping("/memos")         // POST /memos      → 저장
    @GetMapping("/memos/{id}")     // GET  /memos/1    → 단건 조회
    @DeleteMapping("/memos/{id}")  // DELETE /memos/1  → 삭제
}

12. application.properties — 설정 파일

DB 연결, JPA 설정 등 앱 전반적인 설정을 하는 파일. 위치: src/main/resources/application.properties

# ===== MySQL 연결 설정 =====
spring.datasource.url=jdbc:mysql://localhost:3306/데이터베이스명?useSSL=false
spring.datasource.username=root
spring.datasource.password=비밀번호
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

# ===== JPA 설정 =====
spring.jpa.hibernate.ddl-auto=update        # 테이블 자동 생성/수정
spring.jpa.show-sql=true                    # 실행 SQL 콘솔에 출력
spring.jpa.properties.hibernate.format_sql=true  # SQL 예쁘게 출력

# ===== Thymeleaf 설정 =====
spring.thymeleaf.cache=false  # 개발 중에는 false (수정 즉시 반영)

️ ddl-auto=update → 코드 변경 시 테이블 자동으로 업데이트. 개발할 때 편리하다!

13. 어노테이션 총정리

14. 초보자를 위한 Spring Boot 개발 순서

과제나 실습을 할 때 어떻게 시작해야 할지 막막해서 쉽게 접근할 수 있는 방법을 찾아봤다.

1단계 Entity 만들기 (데이터 구조 설계)

DB 테이블과 연결될 자바 객체를 가장 먼저 만든다.
"내가 어떤 데이터를 다룰 것인가" 정해져야 그 다음 단계가 진행 (메모 제목, 내용, 작성자 등)

2단계 Repository 만들기 (DB 통로 확보)

Entity를 DB에 저장하고 불러올 인터페이스를 만든다.
JPA를 상속받기만 하면 save(), findAll() 같은 강력한 기능을 바로 쓸 수 있는 '도구'가 생기는 단계이다.

3단계 Service 만들기 (비즈니스 로직 구현)

핵심 기능을 코딩한다.
Repository라는 도구를 활용해 실제로 "메모를 수정한다", "리스트를 역순으로 보여준다" 같은 알맹이 기능을 만드는 과정

4단계 Controller 만들기 (사용자 연결)

브라우저 요청(URL)을 받아 서비스와 연결해 준다.
앞서 만든 기능들을 사용자가 실제로 클릭하거나 접속해서 사용할 수 있게 문을 열어주는 최종 단계이다.

TODAY POINT

Spring은 어노테이션만 잘 붙이면 나머지는 알아서 해준다.

Controller → Service → Repository 이 흐름만 머릿속에 넣으면 과제 시작 가능.

어려운 게 당연하다.

오늘 학습을 마치며

스프링은 처음 접하다 보니 @ 어노테이션 들도 낯설고 종류도 많아서 막막하게 느껴졌다.

하지만 튜터님께서 “원래 배울 것이 많고 시간이 오래 걸리는 분야지만, 지금은 실습과 실무에 필요한 부분 위주로 학습하면 된다”고

말씀해 주셔서 방향을 잡을 수 있었다. 정말 다행이다 ꒰⍢꒱ ༘*

모든 내용을 이해하려 하다가, 꼭 필요한 핵심에 집중하자고 생각하니 학습 범위가 정리되는 느낌이었다.

Spring의 핵심은 'Controller → Service → Repository' 이 세 가지인 것 같다. 확실히 학습하고 넘어갈 것이다⎝⍥⎠

내일은 이 흐름 속에서 각 계층이 어떤 역할을 하고, 어떤 요소들로 구성되는지 더 구체적으로 학습해볼 예정이다.

스프링을 접한 지 이제 이틀째인 만큼 조급해하지 않고 차근차근 익혀나가면서,

내일부터는 본격적으로 과제에도 도전해볼 생각이다. 화이팅!

[TIL] Spring 시작하기

mooncommit — Tue, 7 Apr 2026 23:17:39 +0900

작성일 : 2026-04-07
강의 : 입문 Spring

오늘 들은 강의

✔️ chapter 1-1 OT - 스프링으로 백엔드 개발 시작하기

✔️ chapter 1-2 스프링을 위한 클래스(Class)와 객체(Object)

✔️ chapter 1-3 스프링을 위한 인터페이스(Interface)

✔️ chapter 1-4 개발환경 구성

✔️ chapter 1-5 꼭 알아야할 기본 개발 용어

✔️ chapter 1-6 라이브러리와 프레임워크

✔️ chapter 1-7 HTTP(1)

✔️ chapter 1-8 HTTP(2)

✔️ chapter 1-9 API 이해하기

✔️ chapter 1-10 Annotation과 Lombok

✔️ chapter 1-11 스프링 프로젝트 시작 & 의존성 관리 (Gradle/Maven)

✔️ chapter 1-12 Servlet 개념

✔️ chapter 1-13 Servlet 기반 영화 추천 API 실습

️ 오늘 배운 핵심 개념

내일배움캠프 초반에 배운 내용들이 많이 나와서 오늘 처음 배운 것들을 위주로 정리해 보았다.

프레임워크는 frame(틀) + work(일하다)의 합성어. 개발자가 틀 안에서 개발하도록 강제한다.

라이브러리는 개발 중 필요한 기능을가져다 쓰는 도구 모음이다. 프레임워크 = 라이브러리들의 모음이라고 볼 수 있고,

그 안에서 라이브러리들이 호환되도록 세팅되어 있다.

제어권	프레임워크가 내 코드를 호출	내가 라이브러리를 호출
목적	전체 구조(frame)를 잡기 위해	특정 기능 구현을 위해
예시	Spring, Django, Rails	Lombok, Jackson, Guava

프레임워크 장점 : 코드 일관성 ↑, 팀 협업 편함, 보안 기능 기본 제공, 테스트 환경 통합

프레임워크 단점 : 초기 학습 비용 높음, 버전 호환성 문제, 구조 변경 자유도 낮음

️ 스프링(Spring) 프레임워크

자바(Java) 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크. 핵심은

"개발자는 스프링을 사용하여 비즈니스 로직에 더 집중할 수 있다" 는 것이다.

Spring 사용 전후를 보면 확 와닿는다

BEFORE (Spring 없이 - 소켓 직접 처리)

// 요청 파싱, 헤더 처리, JSON 파싱, 응답 작성... 모두 직접 구현해야 함
public void handleRequest(Socket clientSocket) throws IOException {
    BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
    // ... HTTP 요청 파싱, JSON 수동 파싱, 응답 작성 등 수십 줄
}

AFTER (Spring 사용)

@RestController
public class SpringCalculator {
    @PostMapping("/api/add")
    public Map<String, Integer> add(@RequestBody Map<String, Integer> numbers) {
        int result = numbers.get("a") + numbers.get("b");
        return Map.of("result", result);
    }
}

인프라와 기술적 복잡성은 Spring이 처리 → 개발자는 로직에만 집중!

️ HTTP 상태 코드 (Status Code)

HTTP 요청에 대한 처리 상태를 응답하는 코드. 100 단위 숫자의 의미만 알면 된다!

코드의미대표 예시

1xx	정보 (처리 중)	잘 사용 안 함
2xx	성공	200 OK, 201 Created, 204 No Content
3xx	리다이렉션	OAuth 로그인 시 자주 등장 (카카오, 구글 로그인 등)
4xx	클라이언트 에러	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	서버 에러	500 Internal Server Error, 503 Service Unavailable

자주 쓰는 코드 정리:

200 OK : 요청 성공
201 Created : 새 리소스 생성 성공
204 No Content : 성공했지만 응답 데이터 없음 (삭제 성공 시)
400 Bad Request : 요청 형식이 잘못됨 (예: GET API에 POST로 요청)
401 Unauthorized : 인증 필요 (로그인 안 됨)
403 Forbidden : 인증은 됐지만 권한 없음 (일반 유저 vs 관리자)
404 Not Found : 리소스 없음 (숨기기 용도로 쓰기도 함)
500 Internal Server Error : 서버 내부 오류

️ Annotation

자바 코드에 @로 메타데이터를 추가해 특별한 의미나 동작을 부여하는 것. 복잡한 기능도 어노테이션 하나로 쉽게 사용할 수 있다.

public class LogitechMouse implements Mouse {
    @Override  // ← 이게 어노테이션! 인터페이스에 없는 메서드면 에러 표시해줌
    public void leftClick() { ... }
}

️ Lombok

보일러플레이트 코드(getter/setter/생성자 등 반복 코드)를 어노테이션으로 자동 생성해주는 라이브러리

어노테이션역할

@Getter / @Setter	모든 필드의 getter/setter 자동 생성
@ToString	toString() 자동 생성
@NoArgsConstructor	기본 생성자 생성
@AllArgsConstructor	모든 필드를 받는 생성자 생성
@RequiredArgsConstructor	final 필드만 받는 생성자 생성
@Slf4j	로그용 Logger 객체 자동 생성

// Lombok 사용 예시
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class User {
    private String name;
    private int age;
    // getName(), setName(), getAge(), setAge(), 생성자 모두 자동 생성!
}

느낀 점

초반에 배운 내용들이 많이 겹쳐 있어서 정리하며 공부하니 챕터 1은 많이 어렵지 않았다.

Spring 사용 전후 코드 비교가 제일 인상 깊었다. 복잡한 걸 어노테이션 몇 개로 줄일 수 있다는 게 신기했고,

"그래서 스프링을 쓰는구나" 라고 느낄 수 있었다.

[TIL] 알고리즘 기초 개념 정리

mooncommit — Fri, 3 Apr 2026 20:58:45 +0900

알고리즘 강의 챕터 1-2

알고리즘 시간복잡도 빅오표기법 코딩테스트

1. 알고리즘이란?

알고리즘(Algorithm) : 문제를 해결하기 위한 단계적 절차나 규칙

요리 레시피처럼, 시작부터 끝까지 순서대로 무엇을 해야 하는지 적어놓은 것.

알고리즘을 왜 배울까?

논리적 사고력 향상	체계적·논리적인 사고방식을 기를 수 있음
효율적인 문제 해결	더 빠르고 효율적인 코드 작성 가능
취업 (코딩테스트)	문제 이해도 + 구현 능력 + 효율적 해결 능력을 종합 평가

알고리즘 표현 방법

의사코드 (Pseudocode)

프로그래밍 언어와 유사하지만 문법에 얽매이지 않음
단계별 논리 흐름을 구조적으로 표현하기 좋음
실제 코드로 옮기기 쉬움

FUNCTION findMax(numbers):
    max ← numbers[0]
    FOR i = 1 TO length(numbers) - 1
        IF numbers[i] > max THEN
            max ← numbers[i]
    RETURN max

Ꙭ̮ 자연어 표기법

일상적인 언어로 설명 → 비전문가도 쉽게 이해
전체 흐름과 핵심 아이디어를 빠르게 전달
단, 모호한 표현이 생기지 않도록 주의

1. 첫 번째 숫자를 최댓값으로 저장한다.
2. 두 번째 숫자부터 순서대로 확인한다.
   - 현재 숫자가 최댓값보다 크면, 최댓값을 갱신한다.
3. 모든 숫자 확인 후, 최댓값을 반환한다.

자신만의 언어로 문제 해결 아이디어를 표현하는 것이 중요. 의사코드와 자연어를 혼용해도 OK!

2. 좋은 알고리즘의 조건

조건핵심 내용예시

정확성	같은 입력 → 항상 같은 올바른 결과	[1,3,2] 정렬 → 항상 [1,2,3]
효율성	시간·공간 복잡도가 적절해야 함	버블정렬 대신 퀵정렬
명확성	각 단계가 누가 봐도 이해하기 쉬움	변수명 tmp → totalAmount
확장성	다양한 상황에 적용 가능, 수정·디버깅 용이	새로운 로그인 방식을 쉽게 추가 가능한 구조

3. 알고리즘 성능 분석

시간복잡도란?

알고리즘이 문제를 해결하는 데 얼마나 많은 시간이 필요한지를 표현하는 방법 → 정확한 실행 시간이 아닌,

입력 크기 증가에 따른 실행 시간의 증가 추세를 나타냄.

공간복잡도(메모리)도 있지만, 사용자가 직접 체감하기 어렵기 때문에 시간복잡도를 더 중요하게 봄.

빅오(Big-O) 표기법

O(1)	배열 인덱스 접근, 스택/큐 삽입·삭제	입력 크기와 무관, 항상 동일한 시간
O(log N)	이진 탐색	입력이 커져도 로그 값으로만 증가
O(N)	배열 순차 탐색, 최대/최솟값 찾기	입력과 시간이 비례
O(N log N)	병합정렬, 퀵정렬, 힙정렬	가장 효율적인 비교 기반 정렬
O(N²)	버블/삽입/선택 정렬, 2중 반복문	입력의 제곱으로 시간 증가
O(2^N)	부분집합 생성	지수적으로 증가
O(N!)	순열 생성	팩토리얼로 폭발적 증가

시간복잡도 계산 방법

명령문 개수를 세고 → 가장 큰 항만 남기기

// 실행 횟수 분석 예시 : 1부터 n까지의 합
int sum = 0;           // 1회
for(int i = 0; i < n; i++) {   // 초기화 1회 + 조건 n+1회 + 증감 n회
    sum += i;          // n회
}
System.out.println(sum); // 1회

// 전체 : 1 + 1 + (n+1) + n + n + 1 = 3n + 4
// → 최고차항만: O(n)

n 이 매우 커지면 작은 항들의 영향은 미미해짐
상수항은 실행 환경에 따라 달라지므로 제거
증가 추세가 핵심이지, 정확한 횟수는 중요하지 않음

T(n) = 5n³ + 100n² + 200n + 1000
→ 최고차항: 5n³
→ 계수 제거: n³
→ 최종: O(n³)

코딩테스트 시간 제한 기준 (테스트 케이스당 1~2초)

시간복잡도데이터 크기 상한비고

O(log N)	10^18	N이 매우 커도 빠름
O(N)	10^8 (1억)	1초에 수행 가능
O(N log N)	10^6 (백만)	N=10^7이면 약 2.3초
O(N²)	10^4 (만)	2중 반복문 주의
O(2^N)	20	N=30만 돼도 10초 이상
O(N!)	10	N이 조금만 커져도 불가

문제의 입력 크기 N을 먼저 파악하고, 허용 시간 안에 드는 알고리즘을 선택해야 한다!

4. 알고리즘 문제 풀이 5단계

절대 문제를 읽자마자 코딩하지 말 것!
문제를 제대로 이해하지 않고 시작하면 → 잘못된 방향으로 구현 → 디버깅에 몇 배의 시간 소요

STEP 1. 문제 이해 및 요구사항 분석

문제를 천천히 정독
예제 입출력으로 의도 파악
입력/출력 형식 정확히 파악
제약 조건과 규칙 정리

STEP 2. 접근 방법 구상

비슷한 유형의 문제 떠올리기
어떤 알고리즘 유형인지 판단
문제 해결 절차를 단계별로 도식화

STEP 3. 세부 구현 설계 및 검토

의사코드로 각 단계 표현
예외 상황과 극단적인 케이스 고려
시간복잡도 분석

STEP 4. 코드 작성 및 구현

설계한 아이디어를 실제 코드로
변수명·함수명을 명확하게

STEP 5. 테스트와 디버깅

예시 입출력 테스트
극단적인 케이스 테스트 (0, 음수, 최대값 등)
시간 초과 시 → 아이디어 수정, 자료구조 최적화, 메모이제이션, 백트래킹 고려

5. 알고리즘 주요 유형 정리

구현 & 시뮬레이션

구현 : 요구사항을 그대로 코드로 옮기는 능력
시뮬레이션 : 주어진 시나리오·규칙을 차례대로 실행
인덱스 범위, 예외 처리 실수가 많으니 꼼꼼하게!

완전 탐색 (Brute Force)

모든 경우의 수를 탐색해 정답 도출
입력 규모가 작을 때 유리, 정답 보장
반복문 or 재귀 함수로 구현

그리디 (Greedy)

매 순간 가장 최선의 선택 → 전체 최적해
적용 조건: 탐욕 선택 속성 + 최적 부분 구조
빠르고 직관적이지만 조건 불만족 시 오답

백트래킹 (Backtracking)

완전 탐색 + 유망하지 않은 경우 가지치기
탐색 범위를 줄여 효율 향상
주로 재귀 함수로 구현

분할 정복 (Divide and Conquer)

분할 → 정복(해결) → 병합
분할된 하위 문제들은 서로 독립적이어야 함
대표: 병합정렬, 퀵정렬, 이진탐색

동적 계획법 (DP)

큰 문제 → 작은 부분 문제로 나눠 해결 결과를 저장(메모이제이션) 후 재활용
적용 조건: 최적 부분 구조 + 중복되는 부분 문제
점화식을 올바르게 세우는 것이 핵심!

알고리즘 선택 가이드

문제 파악
  ↓
입력 크기 N 확인 → 시간복잡도 허용 범위 계산
  ↓
- 요구사항 그대로 구현 → 구현/시뮬레이션
- N이 작고 모든 경우 탐색 → 완전 탐색
- 매 순간 최선 선택이 전체 최적 → 그리디
- 완전 탐색 + 가지치기 → 백트래킹
- 독립적 하위 문제로 분할 가능 → 분할 정복
- 중복 부분 문제 + 최적 부분 구조 → DP
  ↓
필요 시 알고리즘 조합 (예: 백트래킹 + DP)

6. 실습 문제 풀이

실습 1 - 배열에서 최댓값 찾기 (O(N))

문제 : 정수 배열에서 최댓값을 찾아라.

자연어 풀이 설계

1. 배열의 첫 번째 원소를 최댓값으로 설정한다.
2. 두 번째 원소부터 마지막 원소까지 순서대로 비교한다.
   - 현재 원소가 최댓값보다 크면, 최댓값을 갱신한다.
3. 모든 비교가 끝나면 최댓값을 반환한다.

Java 구현

public class FindMax {
    public static int findMax(int[] numbers) {
        int max = numbers[0]; // 첫 번째 원소를 최댓값으로 초기화

        for (int i = 1; i < numbers.length; i++) {
            if (numbers[i] > max) {
                max = numbers[i]; // 더 큰 값 발견 시 갱신
            }
        }
        return max;
    }

    public static void main(String[] args) {
        int[] arr = {3, 7, 1, 9, 4, 6};
        System.out.println("최댓값: " + findMax(arr)); // 출력: 9
    }
}
// 시간복잡도: O(N) - 배열을 한 번 순회

실습 2 - 1부터 N까지의 합 (O(N) vs O(1) 비교)

문제 : 1부터 N까지의 합을 구하는 두 가지 방법을 비교하라.

자연어 풀이 설계

방법 1 - 반복문:
  1. sum = 0으로 초기화한다.
  2. 1부터 N까지 반복하며 sum에 더한다.
  3. sum을 반환한다.

방법 2 - 가우스 공식:
  1. N * (N+1) / 2 를 계산하여 바로 반환한다.

Java 구현

public class SumComparison {

    // 방법 1: 반복문 - O(N)
    public static int sumLoop(int n) {
        int total = 0;
        for (int i = 1; i <= n; i++) {
            total += i;
        }
        return total;
    }

    // 방법 2: 가우스 공식 - O(1)
    public static int sumGauss(int n) {
        return n * (n + 1) / 2;
    }

    public static void main(String[] args) {
        int n = 1000000;
        long start, end;

        // 방법 1 시간 측정
        start = System.nanoTime();
        int result1 = sumLoop(n);
        end = System.nanoTime();
        System.out.println("반복문 결과: " + result1);
        System.out.println("반복문 실행 시간: " + (end - start) + " ns");

        // 방법 2 시간 측정
        start = System.nanoTime();
        int result2 = sumGauss(n);
        end = System.nanoTime();
        System.out.println("\n가우스 공식 결과: " + result2);
        System.out.println("가우스 공식 실행 시간: " + (end - start) + " ns");
    }
}
// → N이 클수록 가우스 공식의 압도적인 속도 차이를 체감할 수 있음

실습 3 - 거스름돈 문제 (그리디 알고리즘)

문제 : 500원, 100원, 50원, 10원 동전으로 N원을 거슬러줄 때 최소 동전 개수를 구하라.

자연어 풀이 설계

1. 동전을 큰 단위부터 작은 단위 순으로 준비한다: [500, 100, 50, 10]
2. 남은 금액을 N으로 초기화한다.
3. 가장 큰 동전부터 순서대로:
   - 현재 동전으로 최대한 많이 거슬러준다 (나눗셈)
   - 남은 금액을 업데이트한다 (나머지)
   - 남은 금액이 0이면 즉시 종료
4. 사용된 동전 개수를 반환한다.

핵심 아이디어 : 큰 단위가 작은 단위의 배수 → 탐욕 선택 속성 성립

Java 구현

import java.util.*;

public class CoinChange {

    public static int coinChange(int[] coins, int target) {
        Arrays.sort(coins); // 오름차순 정렬

        int remaining = target;
        int count = 0;

        // 큰 단위부터 (뒤에서부터 순회)
        for (int i = coins.length - 1; i >= 0; i--) {
            count += remaining / coins[i];   // 해당 동전으로 거슬러줄 수 있는 개수
            remaining %= coins[i];           // 남은 금액 갱신

            if (remaining == 0) return count; // 0원이면 조기 종료
        }
        return count;
    }

    public static void main(String[] args) {
        int[] coins = {500, 100, 50, 10};
        Scanner scanner = new Scanner(System.in);
        int target = scanner.nextInt();
        System.out.println(coinChange(coins, target));
    }
}

테스트 케이스 (입력출력설명)

1260	6	500×2 + 100×2 + 50×1 + 10×1
830	7	500×1 + 100×3 + 10×3
0	0	거스름돈 없음
500	1	500원 1개

시간복잡도 : O(K) — K는 동전 종류 수 (이 경우 K=4이므로 사실상 O(1))

핵심 정리

알고리즘 공부의 핵심은 코드 암기가 아니라, 문제를 보고 "어떤 방식으로 접근할지" 생각하는 능력을 키우는 것이다.

알고리즘 = 문제를 해결하는 단계적 절차
좋은 알고리즘 = 정확성 + 효율성 + 명확성 + 확장성
시간복잡도 → 빅오 표기법으로 증가 추세 파악
문제 풀이 순서 : 이해 → 구상 → 설계 → 구현 → 테스트 (코드 먼저 X!)
알고리즘 유형 : 구현, 완전탐색, 그리디, 백트래킹, 분할정복, DP

다음 챕터에서는 자료구조와 탐색 알고리즘을 다룰 예정⎝⍢⎠

[TIL] Java 컬렉션 - HashSet과 HashMap

mooncommit — Thu, 2 Apr 2026 15:16:57 +0900

️ HashSet

Set 인터페이스를 구현한 컬렉션이다.

특징

순서를 보장하지 않는다
중복을 허용하지 않는다
get() 사용 불가

주요 메서드

HashSet<String> set = new HashSet<>();

set.add("값");       // 추가
set.remove("값");    // 제거

이럴 때 사용!

중복 없이 데이터를 관리할 때 : 예를 들어 장바구니에 같은 상품이 중복으로 담기는 걸 방지할 때 활용할 수 있다.

⭐️ 구글에서 가져온 예시

import java.util.HashSet;

class Main {
    public static void main(String[] args) {
        HashSet<Integer> evenNumber = new HashSet<>();

        // Using add() method
        evenNumber.add(2);
        evenNumber.add(4);
        evenNumber.add(6);
        System.out.println("HashSet: " + evenNumber);

        HashSet<Integer> numbers = new HashSet<>();
        
        // Using addAll() method
        numbers.addAll(evenNumber);
        numbers.add(5);
        System.out.println("New HashSet: " + numbers);
    }
}

✔️ 실행 결과

HashSet: [2, 4, 6]
New HashSet: [2, 4, 5, 6]

HashMap

Map 인터페이스를 구현한 컬렉션이다.

특징

키(Key) - 값(Value) 구조로 데이터를 저장한다
키는 중복 불가, 값은 중복 가능
순서를 보장하지 않는다
키가 중복되면 값이 덮어씌워진다

주요 메서드

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

map.put("키", 값);      // 추가
map.get("키");          // 조회
map.remove("키");       // 제거
map.keySet();           // 키 확인
map.values();           // 값 확인

이럴 때 사용!

상품명과 수량처럼 짝을 이루는 데이터를 관리할 때 — 장바구니에서 상품명: 수량 형태로 저장할 때 활용할 수 있다.

⭐️ 구글에서 가져온 예시

import java.util.*;  
  
public class Scaler {  
    public static void main(String[] args)  
    {  
        HashMap<String, Integer> hashMap = new HashMap<>(); 
        
       // 해시맵 생성 (이름 -> 문자열, 셀 번호 -> 정수)
        hashMap.put("Boyd Redding", 140);  
        hashMap.put("Andy Dufresne", 142);  
        hashMap.put("Heywood", 146);  
        hashMap.put("Brooks", 145);  
        hashMap.put("Tommy", 148);

 
        // 향상된 for 루프를 사용하여 해시맵을 순회
        
        //Iterating keys
        for(String name: hashMap.keySet())  
        {  
            //Printing keys and their corresponding values
            System.out.println(name + ":" + hashMap.get(name));  
        } 
        
        //Map.Entry as a reference to the entrySet elements (key -> value)
        for(Map.Entry<String, Integer> entry: hashMap.entrySet())  
        {  
            System.out.println(entry.getKey() + ":" + entry.getValue());  
        }
        
    }
}

✔️ 실행 결과

Printing elements with keySet method:
Boyd Redding:140
Andy Dufresne:142
Heywood:146
Brooks:145
Tommy:148

Printing elements with entrySet method:
Boyd Redding:140
Andy Dufresne:142
Heywood:146
Brooks:145
Tommy:148

ArrayList vs HashSet vs HashMap 비교ArrayList

ArrayList

순서 있고 중복 허용되는 목록이 필요할 때 사용

HashSet

중복 없는 목록이 필요할 때

HashMap

상품명: 수량 처럼 연결된 데이터를 관리할 때

HashMap으로 장바구니 구현하기

장바구니에 같은 상품이 중복으로 담기면 안 되고,
상품마다 수량을 관리해야 하기 때문에 `HashMap`을 활용했다.

CommerceSystem에 먼저 장바구니 활용을 해보고 잘 되면 그 때 메서드를 분리할 계획이다.

CommerceSystem 필드에 HashMap을 추가했다.

private HashMap<Product, Integer> cart = new HashMap<>();

- `Key` → `Product` (상품 객체)
- `Value` → `Integer` (수량)

Value 에는 int 같은 기본 자료형이 올 수 없다.
그래서 int 대신 래퍼클래스(Wrapper Class)인 Integer을 사용한다.

선택한 상품: iPhone 15 | 1,350,000원 | Apple의 최신 스마트폰 | 재고: 30개
위 상품을 장바구니에 추가하시겠습니까?
1. 확인        2. 취소
1 <-

// 1번을 누르면 나오는 메뉴입니다.
iPhone 15가 장바구니에 추가되었습니다.

이렇게 출력되게 만들어 볼 것이다.

️ HashMap 메서드

메서드	역할
put(key, value)	추가
get(key)	조회
remove(key)	제거
containsKey(key)	키(key) 존재 여부 확인

HashMap 메서드를 사용해 만들어주었다.

System.out.print("입력 : ");
int addCart = scanner.nextInt();
// 1 선택 : 추가 / 2 선택 : 취소 continue; 그 외 : 올바른 숫자를 입력하세요
// 1이면 추가
if (addCart == 1) {
// 여기서 이미 있으면 + 1 담아주기(put 메서드)
	if (cart.containsKey(selectedProduct)) {
		cart.put(selectedProduct, cart.get(selectedProduct) + 1);
        System.out.println(cart.get(selectedProduct));
		// 없으면 그냥 한 개 담아주기
	} else {
	cart.put(selectedProduct, 1);
    }
    System.out.println(selectedProduct.getProductName() + "가 장바구니에 추가되었습니다.");
	 // 만약 2를 선택하면 취소
} else if (addCart == 2) {
continue;
// 1, 2 외 다른 것을 입력
} else {
System.out.println("올바른 번호를 입력하세요");
continue;
}

먼저 입력값에 따라 `if-else`로 분기 처리했다.

✔️ 1을 입력하면 장바구니에 추가된다. 이때 `containsKey()` 메서드로 이미 담긴 상품인지 확인한다.

✔️ 이미 있으면 → `get()`메서드(조회)로 현재 수량을 꺼내서 +1 후 다시 `put()`메서드(추가)

✔️ 같은 상품이 없으면 수량 1로 `put()`

✔️ 2를 입력하면 취소 후 `continue`로 다시 메인으로 돌아간다.

✔️ 그 외 입력은 안내 메시지 출력 후 `continue`로 다시 돌아간다.

장바구니 추가 성공⎝⍢⎠

느낀 점

몰랐던 클래스나 메서드를 배우고 그걸 활용해 완성해 가는 과정이 너무 재밌는 것 같다.

처음에는 객체 생성도 어려웠는데 정말 많이 성장한 것 같다 ㅎㅎ 앞으로도 화이팅!