01. JPA(Java Persistence API)

JPA(Java Persistence API) 는 자바에서 ORM을 위한 표준 명세 입니다.

a. ORM(Object Relational Mapping)

데이터베이스를 Object로 다루는 기술입니다. 자바에서는 Object 는 객체를 의미합니다.

b. 다양한 JPA 구현체

JPA 를 실제로 동작하게 하는 여러 구현체가 있습니다. 스프링부트에서 어떤 구현체를 사용할지 개발자가 결정할 수 있지만 기본적으로 Hibernate 구현체를 사용하고 있습니다.

02. JPA 가 SQL 을 실행하는 과정

JPA 로 편하게 DB 를 조작하는 것은 DB 에 SQL 을 보내는 과정을 편하게 만든 것입니다. → 실제로 DB 에 SQL 을 보내는 것은 JDBC 가 담당하게 됩니다.

JDBC(Java Database Connectivity)

• 자바와 DB 사이의 통신 규약(인터페이스)입니다.
• 구현체는 DB-driver(mysql, mariadb, 등) 가 담당합니다.

03. JPA 핵심 키워드 & 동작원리

⭐ a. EntityManagerFactory

EntityManagerFactory 는 DB 연결에 필요한 모든 세팅을 미리 해놓습니다. 그리고 요청이 들어오면 EntityManager 생성에 사용됩니다.

⭐ b. EntityManager

EntityManager 는 DB 에 저장, 조회, 수정, 삭제하는 작업자 입니다.

• *Transaction 단위로 생성됩니다.

⭐ c. 엔티티

데이터베이스의 테이블 구조를 그대로 표현하는 역할을 가진 객체입니다.

@Entity
public class Book {

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

    private String name;

    private String author;
}

⭐ d. 영속성 컨텍스트

엔티티의 정보를 메모리에서 관리하는 임시 저장소. 데이터를 반영하기전 변경사항을 모두 기록합니다. 트랜잭션이 끝나면 모든 변경사항을 DB 에 반영합니다.

class Service {

        // 트랜잭션 시작
        @Transactional 
        public void doService() {

                // 1. 데이터 조회, 생성, 수정, 삭제 
                // ...
                // ...
        }
    // 트랜잭션 끝
}

i. 엔티티의 상태 ii. 영속성 컨텍스트의 4가지 특징

1. 1차 캐싱

   Book a = em.find(Book.class, "의문의책A"); // SELECT * FROM books WHERE id = '의문의책A'
   Book b = em.find(Book.class, "의문의책A"); // SELECT 쿼리 발생 X (1차 캐시 사용)

2. 동일성 보장

   Book a = em.find(Book.class, "의문의책A");
   Book b = em.find(Book.class, "의문의책A");
   

// 동일성 비교 true (같은 객체 반환) System.out.println(a == b);

3. 쓰기 지연
```java
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

//데이터 변경시 트랜잭션을 시작
transaction.begin(); // 트랜잭션 시작

em.persist(bookA); // (1) INSERT ...
em.persist(bookB); // (2) INSERT ...

// 쓰기지연은 persist 호출시 SQL 이 바로 실행되지 않습니다.
// (1, 2 의 sql 을 모았다가 보낸다.)
trasnaction.commit(); 트랜젝션 커밋

4. 변경감지 ```java

--> 트랜잭션 시작

// 영속 Book findBook = em.find(Book.class, "채식주의자"); findBook.setName("소년이온다");

// persist 호출 불필요합니다. // 변경된 속성은 트랜잭션 커밋 시 자동 반영 됩니다. // em.persist(findBook);

--> 트랜잭션 끝

## ⭐ 요약

`EntityManager`  는 실제로 엔티티를 DB 에 저장, 조회, 수정, 삭제하는 작업자입니다. 


`EntityManagerFactory` 는 DB 에 연결에 필요한 모든 세팅을 미리 해놓고 `EntityManager` 생성에 사용됩니다.


`EntityManagerFactory` 는 애플리케이션 시작시 딱 한번 만들어지고 애플리케이션이 종료될때까지 유지됩니다.


 EntityManagerFactory 를 만들려면 `DataSource` 가 정상적으로 생성되어야합니다.


 EntityManager 는 EntityManagerFactory 로부터 생성되며 `Transaction`  단위로 생성되고 종료됩니다.

 `영속성컨텍스트`  는 엔티티를 메모리에서 관리하는 임시 저장소입니다.


 ---

 ## 4. 인증인가 기초(쿠키, 세션, 토큰)

 ## ⭐ 01. 인증인가
 ![](https://velog.velcdn.com/images/loaded_diaper/post/213bb1b1-8eda-4e35-84de-b5b8bd9e908d/image.png)

a. 인증(Authentication) 
>누구인가 확인하는 단계 
![](https://velog.velcdn.com/images/loaded_diaper/post/93cdeb09-9471-4ca8-844c-edbea2b180d0/image.png)

b. 인가(Authorization) 
>자격을 확인하는 단계
![](https://velog.velcdn.com/images/loaded_diaper/post/2ecaf2a2-d044-461f-9858-df10d0902c1b/image.png)

## ⭐ 02. 쿠키
> 브라우저의 저장공간

![](https://velog.velcdn.com/images/loaded_diaper/post/c28b9781-7b70-4e09-9021-56727ab9bd7d/image.png)

### 쿠키인증의 한계
![](https://velog.velcdn.com/images/loaded_diaper/post/8df66b3d-1a61-4b64-b226-9b351f3ef1bf/image.png)


## ⭐ 03. 세션
>클라이언트와 서버의 연결을 나타내는 하나의 상태
![](https://velog.velcdn.com/images/loaded_diaper/post/16485669-8c1e-4cce-93e2-45c55398a43e/image.png)

 ### 세션의 한계
![](https://velog.velcdn.com/images/loaded_diaper/post/0e8eb433-7978-48f3-9185-6a51e033e01f/image.png)


## ⭐ 04. 토큰
>의미 있는 불규칙한 문자열
 ![](https://velog.velcdn.com/images/loaded_diaper/post/4fe7aeb1-f7c0-4bc2-a822-b61bca157a9b/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/218d217c-dafd-436e-bc5e-b199c7169330/image.png)

### 토큰인증방식의 한계
암호화가 아닙니다 - 단순한 문자열(Base64 적용)


## ⭐ 요약
![](https://velog.velcdn.com/images/loaded_diaper/post/a95face2-5a8a-4b14-9234-118d815e2fb6/image.png)


---

## 5. 연관관계

## ⭐ 01. 데이터베이스 모델링
>어떤 서비스를 만들 때 필요한 데이터들을 정리하고 구조화하는 작업(테이블 명세 + ERD)
![](https://velog.velcdn.com/images/loaded_diaper/post/2d0db63a-5efa-46ab-a435-581a4a9a61f5/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/1a0cfcec-7f8f-4e7d-949b-29e9f40545dd/image.png)


### 연관관계
>객체(엔티티) 가 서로 연결되어 있는 모습을 연관관계 라고 합니다. (JPA 와 다른 ORM 에서 사용하는 용어).

a. 연관관계 주인
b. 부모-자식 관계
c. 단방향과 양방향 연관관계


## ⭐ a. 연관관계 주인
>연관관계가 있는 테이블 사이에서
 물리적으로 다른테이블의 외래키를 소유하고 있는 테이블/엔티티를 연관관계의 주인이라고 표현합니다. 

![](https://velog.velcdn.com/images/loaded_diaper/post/05fe0921-f2b3-4dca-bec9-35885602cfed/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/d6d40e6e-c21b-4532-b038-2ff360e8bf98/image.png)

## ⭐ b. 부모 - 자식 관계
>비즈니스 관점에서 한 도메인이 다른 도메인을 포함하는 논리적인 관계를 의미합니다.

- 부모: 포함하고 있는 도메인
- 자식: 포함되는 도메인

![](https://velog.velcdn.com/images/loaded_diaper/post/7679cb3a-b662-402b-913c-5ac4ce9286c6/image.png)

수강생은 연관관계 부모-자식 관계에서 `자식` 이다. 

수업은 연관관계 부모-자식 관계에서 `부모` 이다. 

### 연관관계 정리
![](https://velog.velcdn.com/images/loaded_diaper/post/0af24e5d-fe6a-4804-ab1a-0d9d61e96d61/image.png)

## ⭐ i. 단방향

> 한쪽에서만 다른 엔티티를 참조하는 상황 (`@ManyToOne`)

## ⭐ ii. 양방향

> 엔티티(객체) 들이 서로 참조하는 상황(`@OneToMany`)


## cascadeType 그리고 orphanRemoval
>양방향 연관관계를 더 멋지게? 사용하는 방법

## a. cascadeType

> 양방향 연관관계(@OneToMany) 에서 부모 엔티티를 PERSIT 하거나 REMOVE할때 연관된 자식 엔티티에게도 그 작업을 자동으로 적용할지 결정하는 설정
>![](https://velog.velcdn.com/images/loaded_diaper/post/97b91768-8577-461f-aed1-fcce42360720/image.png)

## b. orphanRemoval 
>부모와의 연관관계가 끊겨 있는 엔티티를 자동으로 삭제할지 결정하는 기능 
→ 부모 없는 엔티티 → 고아(orphan) 이라고 표현합니다. 
![](https://velog.velcdn.com/images/loaded_diaper/post/e389eb60-5bcd-4a9d-8de7-319b7d96b1bb/image.png)

## c. 조합 정리(cascadeType + orphanRemoval) 
 ![](https://velog.velcdn.com/images/loaded_diaper/post/4263d8c5-180e-416e-bb3c-a7385d51e847/image.png)


## ⭐ 05. 양방향 연관관계의 위험성
>양방향 연관관계 사용시 객체의 상태가 양쪽에 존재하기 때문에 어떤 값을 DB 에 반영해야하는지 JPA 가 자동으로 판단할 수 없는 모호한 상황이 발생할 수 있습니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/1534765b-9456-488a-8ddb-d39deb9edcc7/image.png)

실무는 대부분 단방향


---

## 6. 스프링의 예외처리 원리
![](https://velog.velcdn.com/images/loaded_diaper/post/b0ce93a8-8e92-49aa-856d-dcfa64429430/image.png)

## 01. 예외 처리 복습 
>예외 처리 라고 하는 것은 크게 두가지로 나누어져 있습니다. 

예외 처리 
1. 직접 처리
2. 전파 후 처리(책임전가)

## 예외 종류
a. 체크예외(Exception) 
- `RuntimeException` 을 제외한 Exception 클래스를 상속받은 모든 하위 클래스
- 반드시 명시적으로 예외를 처리해야합니다.
- 컴파일러가 컴파일 단계에서 검사해줍니다. 

b. 언체크예외(UncheckedException) 
- `RuntimeException` 클래스를 상속 받은 모든 하위 예외 클래스
- 처리방식은 똑같지만 예외처리를 강제하지 않습니다.
- 컴파일 단계에서 검사해주지 않습니다. 

### 정리
 ![](https://velog.velcdn.com/images/loaded_diaper/post/137d12fa-01a5-4b11-b074-74ec6e320b61/image.png)


## ⭐ 4. 논의 - 언제 check / unchecked 를 사용해야할까?
>프로그램 실행 흐름안에서 직접 처리시 복구가능성이 있는 상황이라면 `checked` 그렇지 않다면 `unchecked` 를 사용합니다. 
 ![](https://velog.velcdn.com/images/loaded_diaper/post/f31748a9-4186-4573-ab3d-8dde808dca36/image.png)

![](https://velog.velcdn.com/images/loaded_diaper/post/3c8e2b45-c83b-4f13-8000-2c731e5d8f00/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/63d8c003-9e10-4a9f-9c51-92932a3858eb/image.png)

## ⭐ 스프링 예외처리 흐름
>예외가 발생하면 /error 경로로 BasicErrorController 를 호출해서 에러 응답 본문을 만들어줍니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/4e9130b9-f26d-42e3-a0a5-392499a592d7/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/990075e3-0bbc-489d-8359-78b231b20a76/image.png)

## 예외처리 흐름 살펴보기 - 필터  
a. 필터 
>스프링필터는 WAS 와 DispatcherServlet 사이에 위치합니다. 이 위치 덕분에 모든 요청 응답에 대한 공통작업(보안검사, 요청/응답 기록 등) 처리에 적합한 역할을 합니다. 
![](https://velog.velcdn.com/images/loaded_diaper/post/f5a33055-f025-4b96-88a5-3d5f05ae8a0a/image.png)

## ⭐ 05. ExceptionResolver
>스프링은 3가지 resolver 를 활용해 예외처리시 사용할 상태코드, 에러메시지 등을 미리 설정합니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/c5edd8f4-ebcb-4d7b-9a8e-4ef7841aaf85/image.png)

스프링에서 예외가 발생했을때  **c → b → a**  순차적으로 예외를 처리하려고 시도합니다.

1. DefaultHandlerExceptionResolver
2. ResponseStatusExceptionResolver
3. *(현업사용) ExceptionHandlerExceptionResolver

### 1. DefaultHandlerExceptionResolver

- 스프링에서 기본적으로 정의해놓은 표준 예외(메시지, 상태코드)를 처리하는 resolver 입니다.
- BasicErrorController 통해서 예외를 처리합니다.
- 파일참고: DefaultHandlerExceptionResolver.java 참고

### 2. ResponseStatusExceptionResolver

- @ResponseStatus  로 설정한 예외를 처리하는 resolver 입니다.
- BasicErrorController 통해서 예외를 처리합니다.

### ⭐ c. ExceptionHandlerExceptionResolver
커스텀하게 특정 예외에 상태코드, 메시지, 응답 본문을 만들어 줄 수 있습니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/20ce57e7-206f-4e91-a78a-264862fa36d1/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/be9da2d4-e6a7-4403-b9eb-9d861d037780/image.png)



















































































** 출처: 내일배움 스파르타 코딩 클럽**

처음에는 상태 검증 로직이 잘못된 줄 알았는데, 원인은 전혀 다른 곳에 있었다.

문제 상황

주문 목록 조회 API는 아래처럼 구현되어 있었다.

@GetMapping
public ResponseEntity<OrderApiResponse<OrderListResponseDto>> getOrders(
        @SessionAttribute(name = SessionConst.ADMIN_ID) Long adminId,
        @ModelAttribute OrderListSearchRequestDto requestDto
) {
    OrderListResponseDto responseDto = orderService.getOrders(adminId, requestDto);

    OrderApiResponse<OrderListResponseDto> response = OrderApiResponse.success(
            HttpStatus.OK.value(),
            "주문 목록 조회 성공",
            responseDto
    );

    return ResponseEntity.ok(response);
}

서비스에서는 status 값이 들어오면 enum 변환을 통해 유효한 상태값인지 검증하도록 작성해두었다.

OrderStatus orderStatus = null;

if (requestDto.getStatus() != null && !requestDto.getStatus().isBlank()) {
    try {
        orderStatus = OrderStatus.valueOf(requestDto.getStatus());
    } catch (IllegalArgumentException exception) {
        throw new ApiException(ErrorCode.INVALID_ORDER_STATUS);
    }
}

이 상태에서 아래 요청을 보냈다.

GET /api/orders?status=REA

REA는 유효한 주문 상태값이 아니므로, 당연히 INVALID_ORDER_STATUS 예외가 발생해서 400 Bad Request가 나와야 한다고 생각했다.

그런데 실제 결과는 200 OK였다.

처음에 의심했던 부분

처음에는 서비스 로직이 이상하다고 생각했다.

• OrderStatus.valueOf(...)가 잘못된 걸까?
• 예외 처리가 이상한 걸까?
• 혹시 status 검증이 호출되지 않는 걸까?

코드만 계속 보고 있으면 원인을 찾기 어려웠다. 그래서 실제로 서비스에 어떤 값이 들어오는지 확인해보기로 했다.

원인 확인 방법

OrderService의 getOrders() 메서드 맨 위에 아래 로그를 찍었다.

System.out.println("status = " + requestDto.getStatus());
System.out.println("sortBy = " + requestDto.getSortBy());
System.out.println("direction = " + requestDto.getDirection());

그리고 다시 같은 요청을 보냈다.

GET /api/orders?status=REA

콘솔 결과는 이렇게 나왔다.

status = null
sortBy = orderedAt
direction = desc

여기서 원인이 확실해졌다.

쿼리파라미터로 status=REA를 보냈는데도 DTO 안에는 null로 들어오고 있었다.

즉, 문제는 상태 검증 로직이 아니라 아예 status 값이 DTO에 바인딩되지 않고 있었다는 점이었다.

왜 이런 일이 발생했나

문제의 DTO는 아래처럼 작성되어 있었다.

@Getter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

겉보기에는 문제가 없어 보였지만, 여기엔 setter가 없었다.

이번 API는 GET 요청이고, 컨트롤러에서는 @ModelAttribute를 사용해서 쿼리파라미터를 DTO에 바인딩하고 있었다.

그런데 @ModelAttribute 방식으로 값을 채울 때는 현재 구조에서는 setter가 있어야 필드에 값이 정상적으로 들어갔다.

즉,

• status=REA를 요청으로 보냄
• 하지만 DTO에 setter가 없음
• 그래서 status 필드에 값이 안 들어감
• 결국 requestDto.getStatus()는 null
• 상태 검증 로직이 실행되지 않음
• 전체 주문 목록이 그대로 조회됨

이 흐름이었다.

왜 sortBy, direction은 값이 있는 것처럼 보였을까

처음에 sortBy = orderedAt, direction = desc가 찍혀서 바인딩이 되고 있는 줄 착각할 수 있었다.

하지만 이 값들은 요청에서 들어온 게 아니라, DTO에 미리 설정해둔 기본값이었다.

private Integer page = 1;
private Integer size = 10;
private String sortBy = "orderedAt";
private String direction = "desc";

즉,

• status는 바인딩 실패 → null
• sortBy, direction은 바인딩 성공이 아니라 기본값 출력

이었던 것이다.

이 부분 때문에 문제를 처음에 더 늦게 파악했다.

해결 방법

해결은 간단했다. DTO에 @Setter를 추가했다.

@Getter
@Setter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

그리고 다시 같은 요청을 보냈다.

GET /api/orders?status=REA

이번에는 콘솔에 이렇게 찍혔다.

status = REA
sortBy = orderedAt
direction = desc

이제는 status 값이 DTO에 정상적으로 들어왔고, 서비스의 상태값 검증 로직도 제대로 동작했다.

최종 응답도 기대한 대로 바뀌었다.

• 400 Bad Request
• errorCode = INVALID_ORDER_STATUS

해결 전 / 해결 후

해결 전

• status=REA 요청
• DTO의 status 값이 null
• 상태 검증 로직이 실행되지 않음
• 전체 주문 목록이 200 OK로 조회됨

해결 후

• status=REA 요청
• DTO의 status 값이 "REA"로 정상 바인딩됨
• OrderStatus.valueOf("REA")에서 예외 발생
• INVALID_ORDER_STATUS와 함께 400 Bad Request 반환

이번 문제에서 배운 점

1. 로직보다 먼저 “실제 입력값”을 확인해야 한다

처음에는 검증 코드가 틀린 줄 알았다. 하지만 실제 문제는 DTO에 값이 안 들어오는 것이었다.

코드를 오래 붙잡고 있기보다, 서비스에 어떤 값이 실제로 들어오는지 먼저 확인하는 게 훨씬 빠르다는 걸 배웠다.

2. @RequestBody와 @ModelAttribute는 바인딩 방식이 다르다

이전에는 POST 요청에서 @RequestBody를 많이 다뤄서 DTO 바인딩을 비슷하게 생각하고 있었다.

하지만 이번 경험으로 차이를 더 분명히 이해했다.

• @RequestBody → JSON 본문 바인딩
• @ModelAttribute → 쿼리파라미터 바인딩

겉보기엔 둘 다 DTO를 받는 것 같지만, 실제로는 동작 방식이 다르다는 점을 체감했다.

3. 기본값이 있으면 바인딩 문제를 놓치기 쉽다

sortBy, direction이 계속 값이 찍히니까 처음에는 바인딩이 잘 되고 있다고 착각하기 쉬웠다.

하지만 그 값은 요청에서 들어온 값이 아니라 DTO 기본값이었다.

즉, 기본값이 들어간 DTO를 디버깅할 때는 “이 값이 진짜 요청에서 들어온 값인지, 그냥 기본값인지”를 꼭 구분해야 한다는 걸 배웠다.

정리

이번 트러블 슈팅의 핵심은 이 한 문장으로 정리할 수 있다.

@ModelAttribute로 받는 DTO에 setter가 없어서 쿼리파라미터가 바인딩되지 않았고, 그 결과 상태값 검증 로직이 동작하지 않았다.

처음에는 서비스 로직 문제처럼 보였지만, 실제로는 DTO 바인딩 문제였다.

작은 로그 출력 하나로 원인을 바로 확인할 수 있었고, DTO에 @Setter를 추가해서 해결할 수 있었다.

최종 코드

Controller

@GetMapping
public ResponseEntity<OrderApiResponse<OrderListResponseDto>> getOrders(
        @SessionAttribute(name = SessionConst.ADMIN_ID) Long adminId,
        @ModelAttribute OrderListSearchRequestDto requestDto
) {
    OrderListResponseDto responseDto = orderService.getOrders(adminId, requestDto);

    OrderApiResponse<OrderListResponseDto> response = OrderApiResponse.success(
            HttpStatus.OK.value(),
            "주문 목록 조회 성공",
            responseDto
    );

    return ResponseEntity.ok(response);
}

DTO

@Getter
@Setter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

유저 생성 기능을 추가한 뒤 서버 실행 중 아래와 같은 에러가 발생했다.

Error starting ApplicationContext
Application run failed
...
Not a managed type: class com.schedule2.entity.User

처음에는 맨 위의 Application run failed 만 보고 원인을 찾으려고 했는데, 이 문장은 단순히 “애플리케이션 실행이 실패했다” 는 요약일 뿐이었다.

실제 원인은 에러 로그를 아래로 내려가며 확인한 Caused by 부분에 있었다.

에러 흐름은 다음과 같았다.

• UserController 생성 실패
• UserService 생성 실패
• UserRepository 생성 실패
• 최종 원인: Not a managed type: class com.schedule2.entity.User

즉, JPA가 User 클래스를 엔티티로 관리되는 타입으로 인식하지 못해서 UserRepository를 생성할 수 없었고, 그 결과로 서비스와 컨트롤러도 연쇄적으로 생성되지 못한 것이었다.

원인

User 엔티티가 JPA 엔티티로 제대로 등록되지 않은 상태였다.

해결 방법

User 클래스에 엔티티 관련 설정이 제대로 들어가 있는지 확인했다.

@Entity
@Table(name = "users")
public class User extends BaseEntity {

그리고 저장/빌드 상태까지 다시 확인한 뒤 서버를 재실행하니 문제가 해결되었다.

이번에 배운 점

스프링 에러 로그를 볼 때는 맨 위 요약 문장만 보면 안 되고, 반드시 아래쪽의 Caused by 와 가장 마지막의 구체적인 에러 문장을 확인해야 한다.

즉,

• 위쪽: 어떤 작업이 실패했는지
• 아래쪽: 왜 실패했는지

이 순서로 읽는 습관이 중요하다.

Trouble Shooting - getCreatedAt() / getUpdatedAt() 메서드가 인식되지 않은 문제

유저 생성 기능을 구현하면서 UserService에서 아래 코드를 작성했을 때 에러가 발생했다.

savedUser.getCreatedAt()
savedUser.getUpdatedAt()

처음에는 BaseEntity에 createdAt, updatedAt 필드와 getter를 만들어 두었기 때문에 User 엔티티에서도 당연히 사용할 수 있을 것이라고 생각했다.

하지만 원인은 User 엔티티가 BaseEntity를 상속받고 있지 않았기 때문이었다.

기존 코드는 다음과 같았다.

public class User {

이 상태에서는 User 클래스가 BaseEntity의 필드와 메서드를 물려받지 못하므로 getCreatedAt()과 getUpdatedAt()을 사용할 수 없다.

그래서 클래스 선언부를 아래처럼 수정했다.

public class User extends BaseEntity {

수정 후에는 User 엔티티가 BaseEntity의 공통 필드와 메서드를 상속받게 되었고, createdAt, updatedAt, getCreatedAt(), getUpdatedAt()을 정상적으로 사용할 수 있었다.

정리

• getCreatedAt()이 안 잡힌 이유: User가 BaseEntity를 상속하지 않았기 때문
• 해결 방법: User extends BaseEntity로 수정
• 배운 점: 공통 필드/공통 메서드를 부모 클래스에 만들었더라도, 자식 클래스가 상속하지 않으면 사용할 수 없다

### `save()` 결과를 다시 변수에 담는 이유

```java
Schedule savedSchedule = scheduleRepository.save(schedule);

처음 만든 schedule 객체는 아직 DB에 저장되기 전 상태라서 id, createdAt, updatedAt 같은 값이 비어 있을 수 있다.

하지만 save()로 DB에 저장하고 나면

• id가 생성되고
• createdAt, updatedAt 같은 값도 채워질 수 있다.

그래서 저장 결과를 savedSchedule에 다시 담아서 저장 후 최종 상태의 객체를 사용한다.

즉,

• schedule = 저장 전 객체
• savedSchedule = 저장 후 값이 반영된 객체

라고 이해하면 된다.

// 일정 전체 조회 기능
public List<ScheduleResponseDto> getAllSchedules() {

    // 1. DB에서 일정 전체 조회하기
    List<Schedule> scheduleList = scheduleRepository.findAll();

    // 2. 응답 DTO들을 담을 빈 리스트 만들기
    List<ScheduleResponseDto> responseDtoList = new ArrayList<>();

    // 3. 조회한 일정들을 하나씩 꺼내서 응답 DTO로 바꾸기
    for (Schedule schedule : scheduleList) {

        ScheduleResponseDto responseDto = new ScheduleResponseDto(
                schedule.getId(),
                schedule.getUsername(),
                schedule.getTitle(),
                schedule.getContents(),
                schedule.getCreatedAt(),
                schedule.getUpdatedAt()
        );

        // 4. 만들어진 응답 DTO를 리스트에 담기
        responseDtoList.add(responseDto);
    }

    // 5. 최종 응답 리스트 반환하기
    return responseDtoList;
}

일정 전체 조회 로직 정리

getAllSchedules() 메서드는 DB에서 일정 전체를 조회한 뒤,
그 결과를 그대로 반환하지 않고 ScheduleResponseDto 리스트로 바꿔서 반환한다.

흐름은 다음과 같다.

1. scheduleRepository.findAll()로 DB에 저장된 일정들을 모두 조회한다.
2. 조회한 결과는 List<Schedule> 형태로 받아온다.
3. 응답용 리스트(List<ScheduleResponseDto>)를 새로 만든다.
4. 반복문을 사용해서 Schedule 객체를 하나씩 꺼낸다.
5. 각 Schedule 객체를 ScheduleResponseDto로 변환한다.
6. 변환한 DTO를 응답용 리스트에 담는다.
7. 최종적으로 DTO 리스트를 반환한다.

즉,
엔티티 리스트를 그대로 주는 것이 아니라, 응답용 DTO 리스트로 변환해서 반환하는 과정이라고 이해하면 된다.

DB 세팅

ddl-auto 옵션 간단 정리

Spring JPA에서 ddl-auto 옵션은 애플리케이션 실행 시
테이블을 어떻게 다룰지 정하는 설정이다.

• create
  실행할 때 테이블을 새로 생성한다.

  기존 데이터가 사라질 수 있어서 개발 중 테스트용으로만 주로 사용한다.

• update
  엔티티 변경 사항을 기준으로 테이블 구조를 맞춰준다.
  기존 데이터는 유지되기 때문에 개발 중 가장 많이 사용한다.

• none
  JPA가 테이블 생성이나 수정에 관여하지 않는다.
  DB를 직접 준비한 경우에 사용한다.

• validate
  엔티티와 테이블 구조가 맞는지만 검사한다.
  테이블을 새로 만들거나 수정하지 않기 때문에 제출용이나 최종 점검용으로 많이 사용한다.

스프링이란? → IoC 컨테이너

스프링은 IoC 컨테이너 를 제공해주는 프레임워크입니다. → 핵심 기능은 IoC 기반의 DI 을 제공하는 ApplicationContext 라는 IoC 컨테이너입니다.

⭐ 개념1 - 스프링컨테이너(IoC 컨테이너)

애플리케이션이 시작될때 스프링컨테이너(IoC 컨테이너) 는 애플리케이션 실행에 필요한 객체를 생성하고 각 객체에 필요한 의존성을 주입합니다. 스프링컨테이너는 이렇게 생성한 객체를 미리 생성해두고 관리하기 때문에 요청이 들어오면 요청처리에 적합한 객체를 활용해 요청을 처리합니다.

⭐ 개념2 - 스프링빈(SpringBean)

IoC 컨테이너에 의해서 생성되고 관리되는 객체를 스프링빈(SpringBean) 이라고 합니다.

⭐ 스프링기술 - 컴포넌트 스캔(Component Scan)

스프링의 자체 기능 - 자바 객체를 스프링 빈으로 등록하는 기술 컴포넌트스캔 을 활용해서 자바 클래스를 스프링 빈 등록 대상으로 지정할 수 있습니다.

다양한 어노테이션 종류들

• @Component
• @RestController
• @Controller
• @Service
• @Repository
• etc

⭐ web 기술 - 요청 연결 매핑(Request Mapping)

• @RequestMapping() - 보통 클래스 레벨에서 공통 경로 잡을 때 사용
  • @GetMapping() - 조회. 데이터 가져올 때 (목록 조회, 상세 조회)
  • @PostMapping() - 생성. 새 데이터 만들 때 (회원가입, 글 작성)
  • @PatchMapping() - 부분 수정. 기존 데이터 일부만 바꿀 때 (이름만 변경)
  • @DeleteMapping() - 삭제. 데이터 지울 때 (글 삭제, 회원 탈퇴)

⭐ web 기술 - 클라이언트에서 데이터를 받아오는 방법

1. @RequestBody

   클라이언트가 HTTP 요청 바디로 데이터를 전송할때 사용해야합니다.

POST example.com/schedule

"title": "코딩"

 @PostMapping("/requestbody")
    public String useRequestBody(@RequestBody DataTransferObject dto) {
        System.out.println("message = " + dto.getMessage());
        return "response 문자열";
    }

2. @PathVariablle

   클라이언트가 URL 경로로 데이터를 전송할 때 사용해야합니다.

GET example.com/schedule/1

@GetMapping("/schedule/{id}")
public String find(@PathVariable Long id) {
    return "조회 ID: " + id;
}

3. @RequestParm

   클라이언트가 URL 쿼리 파라미터로 데이터를 전송할때 사용해야합니다.

   GET example.com/schedule?title=코딩

   @GetMapping("/schedule")
   public String search(@RequestParam String title) {
    return "검색어: " + title;
   }

⭐ JPA 기술 - 데이터베이스를 다루는 방법

a. 엔티티

엔티티는 자바 클래스와 DB 테이블을 연결해주는 개념입니다.

@Entity

b. repository

JpaRepository 를 활용해서 인터페이스를 만들면 스프링이 알아서 ScheduleRepository클래스를 구현해줍니다!

public interface ScheduleRepository extends JpaRepository<Schedule, Long> {}

• 자동으로 구현된 기능:
  • 전체 조회 - findAll()
  • 단건조회 - findById(…)
  • 저장 - save()
  • 삭제 - delete()

⭐ 3 계층

⭐ 요약

• 스프링이 관리하는 객체를 스프링 빈이라고 한다.

• 스프링 빈을 보관하고 관리하는 곳을 Ioc컨테이너라고 한다.

• @Component, @Service, @Repository 등이 붙은 클래스를 자동으로 찾아서 스프링 빈으로 등록하는 기술을 컴포넌트스캔 이라고 합니다.

• 클라이언트가 URL 경로에 데이터를 보낼 때 사용하는 어노테이션은 @PathVariable 이다. 요청예시: GET /schedule/1

• 클라이언트가 HTTP 요청 바디로 데이터를 보낼 때 사용하는 어노테이션은 @RequestBody 이다. 요청예시: POST /schedule {"title": "코딩"}

• 클라이언트가 쿼리 파라미터로 데이터를 보낼 때 사용하는 어노테이션은 @RequestParam 이다. 요청예시: GET /schedule?title="코딩"

• 자바 클래스와 DB 테이블을 연결해주는 설계도 역할을 하는 것을 엔티티(entity) 라고 합니다.

베이직 2회차

객체간의 결합도를 통한 3계층 이해(DI, IoC)

의존(Dependency)

객체지향 프로그래밍에서는 객체들이 서로 상호작용합니다. 이 과정에서 한 객체가 다른 객체를 필요하게 되는데 이 관계를 의존(Dependency) 라고 표현합니다.

⭐ 의존성 주입(Dependency Injection)

Car 라는 객체가 필요로 하는 객체(의존객체: Engine) 를 외부에서 생성해서 Car 에 주입해주는 것을 의존성 주입이라고 합니다.

⭐ 객체간의 결합도

객체간의 의존성을 어떻게 설정해주느냐에 따라서 객체간의 결합도가 달라집니다.

1단계 - 직접 의존 + 스스로 생성

필요한 의존 객체를 직접 생성하는 구조

• 강한 결합
• 변경에 취약

2단계 - 직접 의존 + 외부에서 생성

의존 객체를 외부에서 생성해서 전달받는 구조

• 생성 책임이 외부로 분리됨
• 하지만 여전히 구체적인 클래스에 의존

3단계 - 추상화에 의존

구현체가 아니라 추상화(인터페이스)에 의존하는 구조

• 구현체 자유롭게 변경 가능
• 느슨한 결합

⭐ 다형성

하나의 형태(인터페이스/부모클래스)로 여러가지 형태(구현체) 를 다룰 수 있는 성질

⭐ IoC(제어 역전: Inversion of Control)

프로그램 제어흐름을 외부(제 3의 주체) 로 넘기는 설계원칙 → 스프링에서는 IoC 개념을 컨테이너 형태로 제공해줍니다.

⭐ 스프링의 의존성 주입 방법

1. 생성자 주입

   @Service
   public class MemberService {...}

   @RestController
   public class MemberController {
    private final MemberService memberService;
   
        @Autowired // 생략 가능
    public UserController(MemberService memberService) {
        this.memberService = memberService;
    }
   }

   @Autowired생략가능

2. 필드주입

   @Service
   public class MemberService {...}

   @RestController
   public class MemberController {
   
        @Autowired
    private MemberService memberService;
   
    ...
   }

3. 세터주입

   @Service
   public class MemberService {...}

   @RestController
   public class MemberController {
    private MemberController memberService;
   
        @Autowired
    public void setMemberService(MemberController memberService) {
        this.memberService = memberService;
    }
   
        ...
   }

⭐ 정리

⭐ 요약

• 하나의 데이터타입으로 다양한 구현체를 다룰 수 있는 성질을 다형성 이라고 합니다.

• 프로그램 제어흐름을 외부로 넘기는 설계 원칙을 제어 역전(IoC: Inversion of Control) 라고 합니다.

• 구현체가 아닌 인터페이스에 의존하면 Car 코드를 수정하지 않고도 Engine 을 자유롭게 교체할 수 있었습니다. 이를 느슨한 결합 결합이라고 합니다.

• 객체가 필요로 하는 B객체(의존객체) 를 외부에서 생성해서 주입해주는 것을 의존성주입(DI: dependency Injection) 이라고 합니다.

• private Engine engine = new ElectricEngine(); 처럼 의존 객체를 직접 생성하면 엔진을 교체하려고 할때 코드를 수정해야합니다. 이를 강한 결합 결합이라고 합니다.

출처: 내일배움스파르타

오늘은 자바 객체지향 과제를 진행하면서 Setter를 무조건 만드는 것이 꼭 좋은 것은 아니라는 점을 다시 정리하게 되었다. 처음에는 클래스 필드를 만들면 자연스럽게 Getter, Setter를 전부 작성하는 습관이 있었는데, 과제를 진행하고 피드백을 들으면서 중요한 값은 함부로 바뀌지 않도록 설계하는 것이 더 객체지향적이라는 점을 이해하게 되었다.

1. 처음에는 왜 Setter를 다 만들게 될까?

자바를 처음 배우면 보통 이렇게 배운다.

• 필드는 private으로 숨긴다
• Getter로 값을 조회한다
• Setter로 값을 수정한다

그래서 자연스럽게 모든 필드에 대해 Getter, Setter를 전부 만드는 습관이 생긴다.

예를 들어 Product 클래스가 있으면 이렇게 작성하기 쉽다.

public class Product {

    private String productName;
    private long productPrice;
    private String productDescription;
    private int productStock;

    public Product(String productName, long productPrice, String productDescription, int productStock) {
        this.productName = productName;
        this.productPrice = productPrice;
        this.productDescription = productDescription;
        this.productStock = productStock;
    }

    public String getProductName() {
        return productName;
    }

    public void setProductName(String productName) {
        this.productName = productName;
    }

    public long getProductPrice() {
        return productPrice;
    }

    public void setProductPrice(long productPrice) {
        this.productPrice = productPrice;
    }

    public String getProductDescription() {
        return productDescription;
    }

    public void setProductDescription(String productDescription) {
        this.productDescription = productDescription;
    }

    public int getProductStock() {
        return productStock;
    }

    public void setProductStock(int productStock) {
        this.productStock = productStock;
    }
}

처음에는 이 방식이 정석처럼 보인다. 하지만 이렇게 하면 객체의 중요한 정보가 외부에서 너무 쉽게 변경될 수 있다.

2. 무분별한 Setter가 왜 문제일까?

예를 들어 상품 가격, 상품명, 재고는 중요한 데이터다. 그런데 Setter를 전부 열어두면 밖에서 이렇게 바꿀 수 있다.

product.setProductPrice(-10000);
product.setProductName("이상한 상품명");
product.setProductStock(-5);

이렇게 되면 객체가 스스로 자신의 상태를 지키지 못한다. 즉, 객체가 안전하지 않다.

객체지향에서는 단순히 필드를 숨기는 것만 중요한 것이 아니라, 그 값을 누가, 언제, 어떤 방식으로 바꿀 수 있는지까지 통제하는 것이 중요하다.

3. Getter는 조회, Setter는 수정이다

오늘 다시 정리한 중요한 포인트는 이것이다.

• Getter는 객체의 값을 읽기 위해 사용한다
• Setter는 객체의 값을 바꾸기 위해 사용한다

문제는 “조회”보다 “수정”이 훨씬 위험하다는 점이다.

값을 읽는 것은 비교적 안전하지만, 값을 수정하는 순간 객체 상태가 달라진다. 그래서 수정 메서드는 정말 필요한 경우에만 열어두는 것이 좋다.

4. 현재 단계에서는 Setter가 꼭 필요하지 않았다

이번 커머스 과제에서 만든 클래스들은 대략 이런 역할을 가진다.

• Product : 상품 1개 정보
• Category : 카테고리 이름 + 상품 목록
• Customer : 고객 정보
• CommerceSystem : 프로그램 흐름 제어

이 단계에서 대부분의 객체는 조회가 중심이었다.

예를 들면:

• 상품명을 출력한다
• 가격을 출력한다
• 설명을 출력한다
• 카테고리 이름을 출력한다
• 고객 정보를 확인한다

즉, 값을 읽는 것은 많이 하지만 중간에 값을 계속 수정할 필요는 거의 없었다.

그래서 Setter를 모두 둘 필요가 없다고 판단했다.

5. 불필요한 Setter를 제거한 방향

예를 들어 Category는 생성될 때 이름과 상품 목록이 정해지면, 실행 중에 굳이 계속 이름을 바꿀 필요가 없다.

그래서 이런 식으로 최소한의 구조로 가져가는 것이 더 자연스럽다.

public class Category {

    private String categoryName;
    private List<Product> products;

    public Category(String categoryName, List<Product> products) {
        this.categoryName = categoryName;
        this.products = products;
    }

    public String getCategoryName() {
        return categoryName;
    }

    public List<Product> getProducts() {
        return products;
    }
}

Customer도 마찬가지다.

public class Customer {

    private String customerName;
    private String email;
    private String grade;

    public Customer(String customerName, String email, String grade) {
        this.customerName = customerName;
        this.email = email;
        this.grade = grade;
    }

    public String getCustomerName() {
        return customerName;
    }

    public String getEmail() {
        return email;
    }

    public String getGrade() {
        return grade;
    }
}

이렇게 하면 객체를 만들 때 필요한 값을 넣고, 그 이후에는 필요한 정보만 조회하는 구조가 된다.

6. Setter 대신 더 의미 있는 메서드를 만드는 것이 좋다

오늘 공부하면서 가장 인상 깊었던 부분은 무조건 setXXX()를 만드는 것보다, 의도가 드러나는 메서드를 만드는 것이 더 좋다는 점이다.

예를 들어 상품 재고는 나중에 주문 기능이 생기면 바뀔 수 있다. 그런데 이렇게 작성하는 것보다:

product.setProductStock(29);

이렇게 작성하는 것이 훨씬 자연스럽다.

product.decreaseStock(1);

왜냐하면 setProductStock(29)는 그 값이 왜 29가 되었는지 문맥이 잘 드러나지 않는다.

반면 decreaseStock(1)은 “재고를 1개 줄인다”는 의도가 명확하다.

즉, Setter는 단순 수정이고 의미 있는 메서드는 행동 중심 설계에 더 가깝다.

7. 캡슐화와도 연결된다

이번 과제 Step 4가 캡슐화였는데, Setter를 줄이는 방향은 캡슐화와도 연결된다.

캡슐화는 단순히 private을 붙이는 것만이 아니라 객체 내부 상태를 안전하게 관리하는 것이다.

즉:

• 필드는 private으로 숨기고
• 필요한 값은 Getter로 조회하고
• 수정은 꼭 필요한 경우에만 허용하고
• 가능하면 의미 있는 행동 메서드로 표현한다

이런 방식이 더 좋은 캡슐화라고 느꼈다.

8. 오늘 정리한 기준

앞으로는 필드를 만들 때 무조건 Setter를 만들지 않고, 아래 기준으로 생각해보려고 한다.

Setter가 필요 없는 경우

• 생성 시 값이 정해지고 이후 잘 바뀌지 않는 경우
• 외부에서 함부로 수정되면 안 되는 중요한 정보
• 현재 단계에서 조회만 필요한 경우

Setter 대신 다른 메서드가 더 좋은 경우

• 값 수정에 명확한 의도가 있는 경우
• 단순 대입이 아니라 “행동”을 표현해야 하는 경우

예:

• setProductStock() 보다 decreaseStock()
• setOrderStatus() 보다 completeOrder()

9. 오늘 느낀 점

예전에는 Getter, Setter를 모두 만드는 것이 좋은 습관이라고만 생각했다. 하지만 오늘은 “모든 Setter가 좋은 것은 아니다”라는 점을 분명히 이해하게 되었다.

객체지향에서 중요한 것은 단순히 클래스를 나누는 것이 아니라, 객체가 자신의 데이터를 어떻게 지키는지 설계하는 것이었다.

특히 이번 커머스 과제를 하면서 Product, Category, Customer 같은 클래스는 지금 단계에서 조회가 중심이기 때문에 불필요한 Setter를 열어두지 않는 것이 더 적절하다고 느꼈다.

10. 한 줄 요약

Setter는 무조건 만드는 것이 아니라, 정말 필요한 경우에만 열어두고, 가능하면 객체의 의도가 드러나는 메서드로 설계하는 것이 더 객체지향적이다.

생성자 주입이 왜 좋은가?

이전에는 Scanner를 CommerceSystem 안에서 직접 생성할지, 아니면 Main에서 만들어서 넘길지 고민했다.

예를 들면 이런 두 방식이 있다.

1. 클래스 내부에서 직접 생성하는 방식

public class CommerceSystem {

    private Scanner scanner = new Scanner(System.in);

}

2. 생성자로 전달받는 방식

public class CommerceSystem {

    private Scanner scanner;

    public CommerceSystem(Scanner scanner) {
        this.scanner = scanner;
    }
}

이 두 방식 중에서 객체지향적으로 더 깔끔한 방법은 생성자 주입 방식이다.

1. 생성자 주입이란?

생성자 주입은 클래스가 필요한 객체를 스스로 만들지 않고, 밖에서 전달받는 방식이다.

예를 들면:

Scanner scanner = new Scanner(System.in);
CommerceSystem commerceSystem = new CommerceSystem(scanner);

이 구조는 이런 흐름이다.

1. Main이 필요한 객체를 생성한다.
2. CommerceSystem은 생성자를 통해 그 객체를 전달받는다.
3. 전달받은 객체를 필드에 저장해서 사용한다.

즉, CommerceSystem이 Scanner를 직접 만들지 않고 이미 준비된 Scanner를 받는 구조다.

2. 왜 직접 생성하지 않고 전달받는 것이 좋을까?

이유 1. 역할이 더 분명해진다

Main은 프로그램 시작점이고, 필요한 객체를 준비하는 역할을 맡는다.

CommerceSystem은 준비된 객체를 받아서 실제 기능을 수행하는 역할을 맡는다.

즉 역할이 이렇게 나뉜다.

• Main : 준비 담당
• CommerceSystem : 실행 담당

이 구조가 더 자연스럽다.

만약 CommerceSystem 안에서 Scanner를 직접 만든다면, CommerceSystem은 기능 수행뿐 아니라 객체 생성까지 같이 하게 된다.

그러면 역할이 조금 섞인다.

이유 2. 코드가 더 일관적이다

이미 CommerceSystem은 products도 밖에서 받고 있다.

public CommerceSystem(List<Product> products, Scanner scanner) {
    this.products = products;
    this.scanner = scanner;
}

즉 products는 밖에서 받고, scanner만 내부에서 직접 만들면 설계가 통일되지 않는다.

반면 둘 다 밖에서 전달받으면 흐름이 깔끔하다.

• 필요한 객체는 모두 Main이 준비한다.
• CommerceSystem은 전달받은 것만 사용한다.

이런 구조가 더 읽기 쉽고 설계 의도가 분명하다.

이유 3. 나중에 변경하기 쉬워진다

처음에는 Scanner(System.in)을 쓸 수 있다. 그런데 나중에는 입력 방식이 달라질 수도 있다.

예를 들어:

• 파일에서 입력받기
• 테스트용 입력값 사용하기
• 다른 입력 객체로 변경하기

만약 CommerceSystem 안에서 직접 new Scanner(System.in)을 써버리면, 입력 방식을 바꾸려면 CommerceSystem 코드를 직접 수정해야 한다.

하지만 생성자 주입 구조라면 CommerceSystem은 그대로 두고, Main에서 어떤 Scanner를 넘길지만 바꾸면 된다.

즉 변경에 더 유연하다.

이유 4. 테스트하기 쉬워진다

지금 단계에서는 테스트 코드까지 깊게 안 가도 되지만, 구조적으로는 이것도 큰 장점이다.

직접 생성하는 방식은:

private Scanner scanner = new Scanner(System.in);

이렇게 고정돼 있어서 테스트할 때 다루기 불편하다.

반면 생성자 주입은:

public CommerceSystem(Scanner scanner) {
    this.scanner = scanner;
}

이렇게 되어 있으니, 테스트할 때 원하는 입력 객체를 넣어볼 수 있다.

즉 외부에서 조립 가능하다는 점이 장점이다.

3. 직접 생성 방식과 생성자 주입 방식 비교

직접 생성 방식

public class CommerceSystem {

    private Scanner scanner = new Scanner(System.in);

}

이 방식의 특징:

• 편해 보인다
• 바로 쓸 수 있다
• 하지만 클래스가 도구를 직접 만들고 있다
• 변경과 테스트에 불리하다

생성자 주입 방식

public class CommerceSystem {

    private Scanner scanner;

    public CommerceSystem(Scanner scanner) {
        this.scanner = scanner;
    }
}

이 방식의 특징:

• 처음엔 조금 더 길어 보인다
• 하지만 구조가 더 깔끔하다
• 필요한 객체를 외부에서 조립할 수 있다
• 역할 분리가 명확하다

4. 현재 프로젝트에 적용하면

Main.java

Scanner scanner = new Scanner(System.in);

CommerceSystem commerceSystem = new CommerceSystem(products, scanner);
commerceSystem.start();

scanner.close();

CommerceSystem.java

private List<Product> products;
private Scanner scanner;

public CommerceSystem(List<Product> products, Scanner scanner) {
    this.products = products;
    this.scanner = scanner;
}

이 구조의 장점은 명확하다.

• Main이 필요한 객체를 준비한다.
• CommerceSystem은 전달받은 객체를 사용한다.
• 설계가 일관적이다.

5. 초보자 눈높이로 이해하면

이걸 아주 쉽게 생각하면:

직접 생성 방식

CommerceSystem이 말한다.

“상품도 내가 받고, Scanner는 내가 직접 만들게.”

생성자 주입 방식

Main이 말한다.

“필요한 재료는 내가 다 준비해줄게. 너는 그걸 받아서 일만 하면 돼.”

두 번째가 더 깔끔하지 않나?

즉 생성자 주입은 필요한 재료를 밖에서 넣어주는 방식이라고 생각하면 된다.

6. 생성자 주입의 핵심 정리

생성자 주입이 좋은 이유는 다음과 같다.

• 역할 분리가 더 명확하다
• 객체 생성 책임이 Main에 모인다
• 설계가 일관적이다
• 변경에 유연하다
• 테스트하기 쉽다

7. 내가 이번에 이해한 점

이번 과제를 하면서 느낀 점은, 단순히 “동작만 하면 된다”가 아니라 누가 만들고, 누가 받고, 누가 사용하는지를 나누는 것이 중요하다는 점이었다.

특히 Scanner처럼 작은 객체 하나도 어디서 생성하는지가 설계 차이를 만든다는 걸 알게 됐다.

처음에는 CommerceSystem 안에서 직접 new Scanner(System.in)을 해도 된다고 생각했지만, 생성자 주입 방식으로 바꾸고 나니 코드의 역할이 더 분명해지고 구조도 더 자연스러워졌다.

한 줄 요약

생성자 주입은 클래스가 필요한 객체를 직접 만들지 않고, 밖에서 전달받아 사용하는 방식이며, 역할 분리와 유지보수 측면에서 더 좋은 설계이다.

정수 전용 계산기에서 실수까지 처리하도록 확장해보기

계산기 과제를 진행하면서 처음에는 int만 사용하는 계산기를 만들었다. 즉, 정수끼리만 계산할 수 있는 구조였다.

예를 들어 이런 입력은 가능했다.

• 1 + 2
• 10 - 3
• 5 * 4

하지만 이런 입력은 처리할 수 없었다.

• 1.5 + 2.3
• 5 / 2 = 2.5

즉, 기존 계산기는 정수 전용 계산기였다.

그런데 과제를 진행하면서 실수도 받을 수 있게 확장하라, 그리고 제네릭을 활용하라는 요구사항이 나왔다.

처음에는 “그냥 int를 double로 바꾸면 되는 거 아닌가?” 라고 생각했지만, 과제의 핵심은 단순히 실수 계산이 아니라 여러 숫자 타입을 더 유연하게 받을 수 있는 구조를 이해하는 것이었다.

이번 글에서는 계산기 과제를 통해 배운 제네릭과 Number의 역할, 그리고 왜 doubleValue()를 사용했는지를 정리해보려고 한다.

1. 처음 계산기는 왜 한계가 있었을까?

기존 계산 메서드는 이런 느낌이었다.

public int calculate(int a, int b, OperatorType operatorType) {
    int result = 0;

    if (operatorType == OperatorType.ADD) {
        result = a + b;
    } else if (operatorType == OperatorType.SUBTRACT) {
        result = a - b;
    } else if (operatorType == OperatorType.MULTIPLY) {
        result = a * b;
    } else if (operatorType == OperatorType.DIVIDE) {
        result = a / b;
    }

    return result;
}

이 구조의 문제는 명확했다.

• a, b가 int라서 정수만 받을 수 있다
• 나눗셈 결과도 정수로 잘릴 수 있다
• 실수 입력인 1.2, 2.5를 받을 수 없다

예를 들어:

5 / 2

를 계산하면 수학적으로는 2.5여야 하지만, 정수 계산에서는 2가 나와버린다.

즉, 정수 타입에 너무 묶여 있는 구조였다.

2. 그럼 그냥 double로 바꾸면 되지 않을까?

처음에는 이런 생각을 했다.

public double calculate(double a, double b, OperatorType operatorType)

이렇게 바꾸면 정수도 받을 수 있고, 실수도 받을 수 있다.

실제로 이 방식도 동작은 한다. 하지만 과제에서는 여기서 한 걸음 더 나아가 제네릭을 사용해서 여러 숫자 타입을 받을 수 있는 구조를 이해하는 것이 중요했다.

즉 핵심은

단순히 double 계산기를 만드는 것이 아니라, 숫자 타입에 유연한 계산기 구조를 만드는 것

이었다.

3. 제네릭(Generic)이란?

제네릭은 쉽게 말하면

타입을 나중에 정하는 문법

이다.

예를 들어 아래 코드를 보자.

public class Box<T> {
    private T item;
}

여기서 T는 아직 정해지지 않은 타입이다.

나중에 사용할 때

• Box<String>
• Box<Integer>

처럼 실제 타입을 넣어서 사용할 수 있다.

즉 T는 일종의 임시 타입 이름이다.

4. 계산기에서 왜 제네릭이 필요했을까?

계산기의 입력값은 이제

• 정수일 수도 있고
• 실수일 수도 있다

즉 어떤 때는 Integer, 어떤 때는 Double이 들어올 수 있다.

그런데 이런 서로 다른 숫자 타입을 하나의 계산기 메서드가 받을 수 있으면 좋겠다고 생각했다.

그래서 계산기 클래스를 이렇게 바꿨다.

public class ArithmeticCalculator<T extends Number> {
}

5. T extends Number는 무슨 뜻일까?

이 문장은 처음 보면 조금 어렵게 느껴진다.

public class ArithmeticCalculator<T extends Number>

하지만 뜻은 생각보다 단순하다.

• T = 나중에 정해질 타입
• extends Number = 그런데 아무 타입이나 안 되고, 숫자 타입만 허용

즉 이 계산기는

• Integer
• Double
• Long
• Float

같은 숫자 타입만 받을 수 있다는 의미다.

반대로 이런 건 받을 수 없다.

• String
• Student

즉 이 코드는 한 줄로 이렇게 해석할 수 있다.

숫자 타입만 받을 수 있는 계산기 클래스를 만들겠다

6. Number는 무엇인가?

Number는 자바에서 숫자 타입들의 부모 클래스 같은 존재다.

대표적으로 이런 클래스들이 Number 계열이다.

• Integer
• Double
• Long
• Float

즉 Number는 “숫자 타입들의 공통 부모” 라고 이해하면 편하다.

그래서 T extends Number라고 쓰면, 정수도 가능하고 실수도 가능한 구조를 만들 수 있다.

7. 실제 계산기 코드는 어떻게 바뀌었을까?

기존 Calculator 클래스를 ArithmeticCalculator로 바꾸고, calculate 메서드를 이렇게 수정했다.

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

public class ArithmeticCalculator<T extends Number> {

    private List<Double> results = new ArrayList<>();

    public double calculate(T num1, T num2, OperatorType operatorType) {

        double num1Double = num1.doubleValue();
        double num2Double = num2.doubleValue();

        double result = 0;

        if (operatorType == OperatorType.ADD) {
            result = num1Double + num2Double;
        } else if (operatorType == OperatorType.SUBTRACT) {
            result = num1Double - num2Double;
        } else if (operatorType == OperatorType.MULTIPLY) {
            result = num1Double * num2Double;
        } else if (operatorType == OperatorType.DIVIDE) {
            result = num1Double / num2Double;
        }

        results.add(result);
        return result;
    }
}

8. 여기서 왜 doubleValue()를 썼을까?

이 부분이 가장 중요했다.

double num1Double = num1.doubleValue();
double num2Double = num2.doubleValue();

num1, num2는 T extends Number이기 때문에 실제로는 Integer일 수도 있고 Double일 수도 있다.

예를 들면:

• num1 = Integer 3
• num2 = Double 2.5

이런 식이다.

그런데 계산을 하려면 타입을 하나로 통일하는 게 편하다. 그래서 계산 전에 모두 double로 바꾼 것이다.

Number 계열은 공통적으로 doubleValue() 메서드를 가지고 있기 때문에, 어떤 숫자 타입이 들어와도 double로 바꿀 수 있다.

예를 들어:

Integer a = 3;
Double b = 2.5;

System.out.println(a.doubleValue()); // 3.0
System.out.println(b.doubleValue()); // 2.5

즉 doubleValue()는

어떤 숫자 타입이 오든 계산하기 편한 double로 통일하는 역할

을 한다고 이해하면 된다.

9. 왜 결과는 List<T>가 아니라 List<Double>로 저장했을까?

처음에는 나도 이런 생각을 했다.

입력 타입이 T니까 결과도 List<T>로 저장하면 되는 거 아닌가?

그런데 곰곰이 생각해보면 문제가 있다.

예를 들어 계산기가 Integer를 받는다고 해도 나눗셈 결과는 실수가 될 수 있다.

5 / 2 = 2.5

즉 입력 타입이 Integer라고 해서 결과도 항상 Integer가 되는 건 아니다.

그래서 결과 저장은 아예

private List<Double> results = new ArrayList<>();

이렇게 Double 타입으로 통일했다.

이렇게 하면

• 정수 결과도 저장 가능 (3 → 3.0)
• 실수 결과도 저장 가능 (2.5 → 2.5)

즉 결과를 더 유연하게 저장할 수 있다.

10. App에서는 어떻게 입력을 처리했을까?

입력값은 더 이상 nextInt()로 바로 받을 수 없었다. 왜냐하면 1.2 같은 실수 입력도 받아야 하기 때문이다.

그래서 입력은 먼저 문자열로 받고, 그 문자열이 정수인지 실수인지 판단해서 숫자로 바꾸는 방식을 사용했다.

System.out.print("첫 번째 숫자를 입력하세요: ");
String input1 = scanner.next();

System.out.print("두 번째 숫자를 입력하세요: ");
String input2 = scanner.next();

Number num1 = parseNumber(input1);
Number num2 = parseNumber(input2);

그리고 parseNumber() 메서드는 이렇게 만들었다.

private static Number parseNumber(String number) {
    if (number.contains(".")) {
        return Double.parseDouble(number);
    } else {
        return Integer.parseInt(number);
    }
}

즉

• "3" 입력 → Integer
• "1.5" 입력 → Double

로 처리하도록 만든 것이다.

이렇게 하면 App 입장에서는 정수와 실수를 구분해서 적절한 숫자 타입으로 바꾸고, 계산기에는 Number로 넘겨줄 수 있게 된다.

11. 정리하면 이번 과제에서 배운 핵심은?

이번 제네릭 과제를 하면서 정리된 핵심은 이렇다.

1) 제네릭은 타입을 유연하게 만든다

ArithmeticCalculator<T extends Number>

이렇게 하면 정수와 실수 같은 여러 숫자 타입을 받을 수 있다.

2) Number는 숫자 타입들의 공통 부모다

Integer, Double 같은 숫자 타입을 하나의 공통 타입으로 다룰 수 있게 해준다.

3) doubleValue()는 계산 전에 타입을 통일하는 역할을 한다

정수든 실수든 상관없이 double로 바꿔 계산하면 훨씬 편하다.

4) 결과는 Double로 저장하는 것이 자연스럽다

입력은 정수일 수도 있지만, 결과는 실수가 될 수 있기 때문이다.

12. 느낀 점

처음에는 T extends Number가 굉장히 추상적으로 느껴졌다. 하지만 계산기처럼 “정수도 받고 실수도 받고 싶다”는 상황에 적용해보니, 왜 이런 문법이 필요한지 조금 이해가 됐다.

이번 과제를 통해 느낀 건,

제네릭은 단순히 어려운 문법이 아니라, 타입을 더 유연하고 재사용 가능하게 만드는 도구라는 점이었다.

그리고 Number와 doubleValue()를 함께 사용하면 정수와 실수를 하나의 계산 흐름 안에서 자연스럽게 다룰 수 있다는 것도 알게 되었다.

마무리

이번 계산기 과제에서 제네릭과 Number를 적용해보면서 기존의 정수 전용 계산기를 정수와 실수 모두 처리 가능한 계산기로 확장할 수 있었다.

한 줄로 정리하면:

T extends Number는 숫자 타입만 받게 제한하는 것이고, doubleValue()는 그 숫자들을 계산하기 쉬운 형태로 통일하는 역할을 한다.

처음에는 조금 어렵게 느껴졌지만, 직접 계산기에 붙여보면서 제네릭이 “왜 필요한지”를 조금은 이해할 수 있었던 시간이었다.

Java 계산기 과제에서 Enum 이해하기

char 대신 왜 enum을 쓰는지 처음부터 정리

계산기 과제를 진행하면서 STEP 3에서 enum을 활용하라는 요구사항을 만났다. 처음에는 솔직히 이렇게 생각했다.

+, -, *, /는 그냥 문자니까 char로 하면 되는 거 아닌가?

실제로 STEP 1, STEP 2까지는 char 타입으로도 계산기를 충분히 만들 수 있었다. 하지만 STEP 3에서는 단순히 “동작하는 계산기”를 넘어서, 연산자 타입을 더 명확하고 안전하게 관리하는 방식으로 코드를 개선하는 것이 핵심이었다.

이번 글에서는 내가 계산기 과제를 하면서 이해한 enum이 무엇인지, 왜 계산기에서 enum을 쓰는지, 기존 코드에 어떻게 연결했는지를 정리해보려고 한다.

1. enum이란 무엇인가?

enum은 정해진 값들만 가질 수 있도록 만든 특별한 타입이다.

예를 들어 이런 것들이 있다.

• 요일: 월, 화, 수, 목, 금, 토, 일
• 계절: 봄, 여름, 가을, 겨울
• 상태: 대기중, 진행중, 완료
• 연산자: 더하기, 빼기, 곱하기, 나누기

이런 값들은 공통점이 있다.

값의 종류가 미리 정해져 있다.

자바에서는 이렇게 정해진 종류만 있는 값들을 표현할 때 enum을 사용한다.

예를 들어 계산기의 연산자를 enum으로 만들면 이렇게 표현할 수 있다.

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE
}

이제 OperatorType은 새로운 타입이 되고, 이 타입은 오직 아래 네 값만 가질 수 있다.

• OperatorType.ADD
• OperatorType.SUBTRACT
• OperatorType.MULTIPLY
• OperatorType.DIVIDE

즉, enum의 핵심은

아무 값이나 들어오지 못하게 하고, 정해진 값만 다루게 만드는 것

이라고 이해하면 된다.

2. 기존 계산기에서는 왜 char를 썼을까?

처음 만들었던 계산기에서는 사용자가 사칙연산 기호를 직접 입력했다.

예를 들면 이런 식이다.

char operator = scanner.next().charAt(0);

그리고 계산할 때는 이렇게 비교했다.

if (operator == '+') {
    result = a + b;
} else if (operator == '-') {
    result = a - b;
} else if (operator == '*') {
    result = a * b;
} else if (operator == '/') {
    result = a / b;
}

이 방식은 동작은 잘 한다. 하지만 문제는 char 타입은 연산자만 넣는 타입이 아니라는 점이다.

즉 아래 같은 값도 모두 들어갈 수 있다.

• 'a'
• '?'
• '1'

즉 char는 그저 “문자 한 글자”를 저장하는 타입일 뿐이고, “연산자 전용 타입”은 아니다.

여기서 enum을 쓰는 이유가 생긴다.

3. 계산기에서 enum을 쓰는 이유

계산기에서는 사실 연산자의 종류가 딱 4개로 정해져 있다.

• 더하기
• 빼기
• 곱하기
• 나누기

즉 아무 문자나 들어오는 게 아니라 정해진 연산자만 관리하고 싶다는 요구가 있다.

이럴 때 enum을 사용하면 코드가 훨씬 명확해진다.

기존 방식

char operator = '+';

enum 방식

OperatorType operatorType = OperatorType.ADD;

둘 다 결국 더하기를 의미하지만, OperatorType.ADD 쪽이 훨씬 의미가 분명하다.

'+'는 그냥 문자 하나처럼 보이지만, ADD는 누가 봐도 “더하기 연산자”라는 걸 알 수 있다.

즉 enum을 쓰면

• 의미가 더 명확해지고
• 잘못된 값을 관리하기 쉬워지고
• 연산자의 종류를 타입 차원에서 제한할 수 있다

는 장점이 있다.

4. 계산기에 enum을 어떻게 붙였는가?

사용자는 여전히 +, -, *, /를 입력한다. 하지만 프로그램 내부에서는 이 문자를 바로 계산에 쓰지 않고, 먼저 enum 값으로 바꾸도록 했다.

즉 흐름은 이렇게 바뀐다.

예전 방식

'+' -> 바로 Calculator에 전달

enum 적용 후 방식

'+' -> OperatorType.ADD 로 변환 -> Calculator에 전달

즉 사용자 입력은 여전히 문자지만, 프로그램 내부 계산 로직은 enum 기반으로 동작하게 바꾼 것이다.

5. OperatorType enum 만들기

먼저 연산자의 종류를 enum으로 정의했다.

package com.example.calculator;

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE
}

이제 OperatorType은 계산기에서 사용하는 연산자 타입이 되었다.

6. 문자 입력을 enum으로 바꾸는 메서드 추가

문제는 사용자가 입력하는 값은 +, -, *, / 같은 문자라는 점이다. 그래서 이 문자를 enum 값으로 변환해주는 메서드가 필요했다.

package com.example.calculator;

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE;

    public static OperatorType fromChar(char operator) {
        if (operator == '+') {
            return ADD;
        } else if (operator == '-') {
            return SUBTRACT;
        } else if (operator == '*') {
            return MULTIPLY;
        } else if (operator == '/') {
            return DIVIDE;
        } else {
            throw new IllegalArgumentException("잘못된 연산자입니다.");
        }
    }
}

이 메서드는 말 그대로 문자(char)를 받아서 OperatorType으로 바꾸는 역할을 한다.

예를 들어:

OperatorType type = OperatorType.fromChar('+');

이렇게 하면 결과는:

OperatorType.ADD

가 된다.

즉, 사용자 입력을 프로그램 내부에서 안전하게 사용할 수 있는 enum 값으로 바꾸는 과정이라고 보면 된다.

7. 기존 Calculator 클래스 수정하기

원래 Calculator 클래스는 char를 매개변수로 받았었다.

기존 코드

public int calculate(int a, int b, char operator) {
    int result = 0;

    if (operator == '+') {
        result = a + b;
    } else if (operator == '-') {
        result = a - b;
    } else if (operator == '*') {
        result = a * b;
    } else if (operator == '/') {
        result = a / b;
    }

    results.add(result);
    return result;
}

이제는 char 대신 OperatorType을 받도록 바꾸었다.

수정 후 코드

public int calculate(int a, int b, OperatorType operatorType) {
    int result = 0;

    if (operatorType == OperatorType.ADD) {
        result = a + b;
    } else if (operatorType == OperatorType.SUBTRACT) {
        result = a - b;
    } else if (operatorType == OperatorType.MULTIPLY) {
        result = a * b;
    } else if (operatorType == OperatorType.DIVIDE) {
        result = a / b;
    }

    results.add(result);
    return result;
}

여기서 핵심 변화는 두 가지였다.

1. 매개변수가 char에서 OperatorType으로 바뀜
2. 비교 대상이 '+' 같은 문자에서 OperatorType.ADD 같은 enum 값으로 바뀜

이렇게 바꾸니 계산 로직이 훨씬 의미 중심으로 읽히기 시작했다.

8. App 클래스에서는 어떻게 연결했는가?

사용자 입력은 그대로 문자로 받았다.

char operator![](https://velog.velcdn.com/images/loaded_diaper/post/3c15d636-f7a5-4d3c-af62-619e293eb424/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/2b29aaa4-8fab-4ea9-9c49-699f0e312eb9/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/f04d90c3-ea63-4161-88c9-4f473e001d2c/image.png)
 = scanner.next().charAt(0);

그다음 바로 Calculator에 넘기는 대신, 먼저 enum으로 바꿨다.

OperatorType operatorType = OperatorType.fromChar(c);

그리고 이 enum 값을 Calculator에 전달했다.

int result = calculator.calculate(a, b, operatorType);

즉 App 클래스의 역할은

• 입력 받기
• 입력받은 문자를 enum으로 변환하기
• Calculator에 넘기기

가 되었다.

9. enum을 적용하면서 느낀 점

처음에는 솔직히 “문자 하나 받아서 if문으로 계산하면 되는데 굳이 enum까지 써야 하나?” 라는 생각이 들었다.

하지만 직접 적용해보니 enum의 장점이 조금씩 보이기 시작했다.

1) 코드 의미가 더 분명해진다

'+'보다는 OperatorType.ADD가 훨씬 읽기 쉽다.

2) 정해진 값만 다룬다는 것이 코드에서 드러난다

연산자는 아무 문자나 들어오는 값이 아니라, 정해진 4가지 중 하나라는 사실이 코드 구조에 반영된다.

3) 나중에 확장하기 좋다

지금은 단순히 연산 종류만 관리하지만, 나중에는 각 enum에 기호, 설명, 계산 로직까지 붙일 수도 있다.

즉 enum은 단순히 “문법 하나 더 배운 것”이 아니라 정해진 종류를 더 안전하게 표현하는 방식이라는 걸 느꼈다.

10. 정리

이번 계산기 과제에서 enum을 적용하면서 가장 중요하게 느낀 점은 다음과 같다.

• enum은 정해진 값들만 가지는 타입이다.
• 계산기의 연산자처럼 종류가 미리 정해져 있는 값에 잘 어울린다.
• 기존에는 char로 직접 비교했지만,
• enum을 사용하면 의미가 더 분명하고 안전한 코드가 된다.
• 사용자 입력은 문자로 받더라도, 프로그램 내부에서는 enum으로 변환해서 처리할 수 있다.

한 줄로 정리하면:

계산기에서 enum을 사용한다는 것은 연산자를 단순한 문자로 다루는 것이 아니라, 정해진 연산 타입으로 명확하게 관리하겠다는 의미였다.

마무리

처음에는 enum이 조금 추상적으로 느껴졌지만, 계산기처럼 연산자 종류가 명확한 예제에 직접 붙여보니 왜 필요한지 이해가 됐다.

이번 과제를 통해 단순히 “계산이 되게 만드는 것”에서 한 걸음 더 나아가, 코드를 더 명확하고 구조적으로 표현하는 방법을 조금씩 배우고 있다는 느낌이 들었다.

다음에는 enum뿐만 아니라 제네릭, 람다, 스트림도 계산기 과제에 어떻게 연결되는지 차근차근 정리해보고 싶다.

getter 공식

public 필드타입 get필드이름첫글자대문자() {
    return 필드이름;
}

setter 공식

public void set필드이름첫글자대문자(필드타입 필드이름) {
    this.필드이름 = 필드이름;
}

getter / setter를 만들 때 초보자가 자주 헷갈리는 것

1) getter는 return이 필요하다

getter는 값을 꺼내오는 거니까 return이 있어야 한다.

틀린 예:

public String getName() {
    name;
}

맞는 예:

public String getName() {
    return name;
}

2) setter는 보통 void다 setter는 값을 저장하는 역할이라 보통 반환값이 없다.

맞는 형태:

public void setName(String name) {
    this.name = name;
}
```![](https://velog.velcdn.com/images/loaded_diaper/post/e4edacdf-2b57-41e5-ac46-bd3046bba676/image.png)

오늘 간단한 자바 계산기를 만들다가, 계산 결과를 출력한 뒤 "exit"를 입력하면 반복문이 종료되어야 하는데 계속 다시 첫 번째 숫자를 입력하세요:가 뜨는 문제가 있었다.

처음에는 if (answer.equals("exit")) 비교가 잘못된 줄 알았는데, 원인은 Scanner 입력 방식 차이와 입력 버퍼에 남아 있는 엔터값 때문이었다.

문제 상황

내가 작성한 계산기 코드는 대략 이런 구조였다.

package com.example.calculator;

import java.util.Scanner;

public class Calculator {

    public static void main(String[] args) {

        Scanner scanner = new Scanner(System.in);
        int result = 0;

        while (true) {

            System.out.print("첫 번째 숫자를 입력하세요: ");
            int a = scanner.nextInt();

            System.out.print("두 번째 숫자를 입력하세요: ");
            int b = scanner.nextInt();

            System.out.print("사칙연산 기호를 입력하세요: ");
            char c = scanner.next().charAt(0);

            if (c == '+') {
                result = a + b;
            }
            else if (c == '-') {
                result = a - b;
            }
            else if (c == '*') {
                result = a * b;
            }
            else if (c == '/') {
                if (b == 0) {
                    System.out.println("나눗셈 연산에서 분모(두번째 정수)에 0이 입력될 수 없습니다.");
                    continue;
                } else {
                    result = a / b;
                }
            }

            System.out.println("결과: " + result);

            System.out.print("더 계산하시겠습니까? (exit 입력 시 종료): ");
            String answer = scanner.nextLine();

            if (answer.equals("exit")) {
                break;
            }
        }
    }
}

실제로 발생한 문제

예를 들어 아래처럼 입력했다.

첫 번째 숫자를 입력하세요: 1
두 번째 숫자를 입력하세요: 2
사칙연산 기호를 입력하세요: +
결과: 3
더 계산하시겠습니까? (exit 입력 시 종료): exit
첫 번째 숫자를 입력하세요:

분명히 exit를 입력했는데도 반복문이 종료되지 않았다.

심지어 어떤 경우에는 아래와 같은 에러도 발생했다.

java.util.InputMismatchException

처음에 헷갈렸던 부분

처음에는 이렇게 생각했다.

• "exit" 비교를 equals()로 했으니 문제없다
• exit를 입력했는데 왜 break가 안 걸리지?
• if문의 break를 밖으로 빼야하나?

그런데 문제는 문자열 비교가 아니라, answer 변수에 실제로 "exit"가 저장되지 않고 있었다는 점이었다.

원인: nextInt(), next()와 nextLine()의 차이

1. nextInt()와 next()는 값만 읽는다

nextInt()와 next()는 입력값 자체만 읽고, 사용자가 마지막에 누른 엔터(\n)는 입력 버퍼에 남겨둘 수 있다.

예를 들어 사용자가 +를 입력하고 엔터를 누르면, 프로그램 입장에서는 +는 읽었지만 엔터는 남아 있을 수 있다.

2. 그 다음 nextLine()은 남아 있던 엔터를 먼저 읽는다

문제는 여기서 발생했다.

String answer = scanner.nextLine();

나는 이 줄이 exit를 읽을 거라고 생각했지만, 실제로는 바로 직전에 남아 있던 엔터만 읽고 끝나버렸다.

즉, answer에는 "exit"가 아니라 빈 문자열 "" 이 들어가게 된 것이다.

그래서 아래 조건문은 false가 된다.

if (answer.equals("exit")) {
    break;
}

실제로는 이런 느낌이었던 셈이다.

if ("".equals("exit")) {
    break;
}

당연히 종료되지 않는다.

왜 InputMismatchException까지 발생했을까?

반복문이 종료되지 않고 다시 처음으로 돌아가면, 프로그램은 또 숫자를 입력받으려고 한다.

int a = scanner.nextInt();

그런데 나는 방금 exit를 입력한 상태였다.

즉, 프로그램 입장에서는 정수를 입력받아야 하는 자리에 "exit"가 들어온 것이다.

그래서 이런 예외가 발생했다.

java.util.InputMismatchException

이 에러의 뜻은 간단하다.

숫자를 받아야 하는데 숫자가 아닌 값이 들어왔다.

해결 방법

해결 방법은 남아 있는 엔터를 먼저 한 번 비워주고, 그 다음 실제 사용자 입력을 받는 것이다.

수정한 코드

System.out.print("더 계산하시겠습니까? (exit 입력 시 종료): ");
scanner.nextLine();          // 남아 있는 엔터 제거
String answer = scanner.nextLine();   // 실제 입력 받기

if (answer.equals("exit")) {
    break;
}

이렇게 순서를 바꾸니 정상적으로 동작했다.

왜 이 코드는 제대로 동작할까?

이제 입력 흐름은 이렇게 된다.

연산자 입력 직후

char c = scanner.next().charAt(0);

• +는 읽음
• 엔터는 남아 있을 수 있음

첫 번째 nextLine()

scanner.nextLine();

• 남아 있던 엔터 제거

두 번째 nextLine()

String answer = scanner.nextLine();

• 이제 진짜 내가 입력한 exit를 읽음

조건 확인

if (answer.equals("exit")) {
    break;
}

• 이번에는 answer에 실제로 "exit"가 들어 있으므로 종료됨

내가 배운 점

이번 트러블 슈팅을 하면서 가장 크게 느낀 건 Scanner의 입력 방식 차이를 정확히 이해해야 한다는 것이었다.

nextInt()

• 숫자만 읽음
• 엔터는 남을 수 있음

next()

• 공백 전까지 한 단어만 읽음
• 엔터는 남을 수 있음

nextLine()

• 엔터 전까지 한 줄 전체를 읽음

즉, nextInt()나 next() 뒤에 바로 nextLine()을 쓰면 내가 원하는 입력이 아니라 남아 있던 엔터를 먼저 읽어버릴 수 있다.

최종 코드

package com.example.calculator;

import java.util.Scanner;

public class Calculator {

    public static void main(String[] args) {

        Scanner scanner = new Scanner(System.in);
        int result = 0;

        while (true) {

            System.out.print("첫 번째 숫자를 입력하세요: ");
            int a = scanner.nextInt();

            System.out.print("두 번째 숫자를 입력하세요: ");
            int b = scanner.nextInt();

            System.out.print("사칙연산 기호를 입력하세요: ");
            char c = scanner.next().charAt(0);

            if (c == '+') {
                result = a + b;
            }
            else if (c == '-') {
                result = a - b;
            }
            else if (c == '*') {
                result = a * b;
            }
            else if (c == '/') {
                if (b == 0) {
                    System.out.println("나눗셈 연산에서 분모(두번째 정수)에 0이 입력될 수 없습니다.");
                    continue;
                } else {
                    result = a / b;
                }
            }

            System.out.println("결과: " + result);

            System.out.print("더 계산하시겠습니까? (exit 입력 시 종료): ");
            scanner.nextLine();
            String answer = scanner.nextLine();

            if (answer.equals("exit")) {
                break;
            }
        }

        scanner.close();
    }
}

마무리

이번 문제는 단순히 break나 equals()의 문제가 아니라, 입력 버퍼와 Scanner 메서드의 동작 방식을 이해해야 해결할 수 있는 문제였다.

처음에는 왜 exit가 안 먹는지 감이 안 왔지만, 원인을 하나씩 따라가 보니 결국 남아 있던 엔터가 문제라는 걸 알 수 있었다.

앞으로 Scanner를 사용할 때는 특히 nextInt(), next(), nextLine()을 섞어 쓸 때 입력 버퍼를 꼭 의식해야겠다고 느꼈다.

---

컬렉션(Collection)이란?

배열의 한계

// 배열은 길이가 고정됨
int[] numbers = new int[3];
numbers[0] = 10;
numbers[1] = 20;
numbers[2] = 30;
numbers[3] = 40; // ❌ 요소 추가시 에러발생

선언 방법

컬렉션객체<자료형> 변수이름 = new 컬렉션객체<자료형>();

// 객체<다룰 데이터: 정수> 변수이름 = new 컬렉션객체생성자<정수>();
ArrayList<Integer> arrayList = new ArrayList<Integer>();

ArrayList<Integer> arrayList = new ArrayList<>();
arrayList.add(10);
arrayList.add(20);
arrayList.add(30);
arrayList.add(40); // ✅ 정상 동작 (길이 제한 없음)

• 배열과 다르게 컬렉션은 길이를 동적으로 변경할 수 있습니다.(추가 삭제 시 유연하게 길이가 변경됩니다.)

컬렉션 종류와 특징

List 인터페이스를 구현한 ArrayList

// List 를 구현한 ArrayList
ArrayList<String> names = new ArrayList<>();
names.add("Spartan");      // 1 번째 요소 추가
names.add("Steve");        // 2 번째 요소 추가
names.add("Isac");         // 3 번째 요소 추가
names.add("1");
names.add("2");

 // ✅ 순서 보장
System.out.println("names = " + names);

// ✅ 중복 데이터 허용
names.add("Spartan");
System.out.println("names = " + names);

// ✅ 단건 조회
System.out.println("1 번째 요소 조회: " + names.get(0)); // 조회 Spartan

// ✅ 데이터 삭제
names.remove("Steve"); 
System.out.println("names = " + names);

Set 인터페이스를 구현한 HashSet

// Set 을 구현한 HashSet
HashSet<String> uniqueNames = new HashSet<>();

// ✅ 추가
uniqueNames.add("Spartan");
uniqueNames.add("Steve");
uniqueNames.add("Isac");
uniqueNames.add("1");
uniqueNames.add("2");

// ⚠️ 순서를 보장 안함
System.out.println("uniqueNames = " + uniqueNames); 
uniqueNames.get(0); // ❌ get 사용 불가

// ⚠️ 중복 불가
uniqueNames.add("Spartan");
System.out.println("uniqueNames = " + uniqueNames); 

// ✅ 제거
uniqueNames.remove("Spartan");
System.out.println("uniqueNames = " + uniqueNames); 

Map 인터페이스를 구현한 HashMap

// Map 을 구현한 HashMap
HashMap<String, Integer> memberMap = new HashMap<>();

// ✅ 추가
memberMap.put("Spartan", 15);
memberMap.put("Steve", 15); // ✅ 값은 중복 가능
memberMap.put("Isac", 1);
memberMap.put("John", 2);
memberMap.put("Alice", 3);

// ⚠️ 순서 보장 안함 
System.out.println("memberMap = " + memberMap);

// ⚠️ 키 중복 불가: 값 덮어쓰기 발생
memberMap.put("Alice", 5);
System.out.println("memberMap = " + memberMap);

// ✅ 조회: 15
System.out.println(memberMap.get("Steve"));

// ✅ 삭제 가능
memberMap.remove("Spartan"); 
System.out.println("memberMap = " + memberMap);

// ✅ 키 확인
Set<String> keys = memberMap.keySet();
System.out.println("keys = " + keys);

// ✅ 값 확인
Collection<Integer> values = memberMap.values();
System.out.println("values = " + values);

예외(Exception)란?

의도하지 않은 예외

public class Main {
    public static void main(String[] args) {
        System.out.println("프로그램 시작");
        int result = 10 / 0; // ❌ 예외 발생 (ArithmeticException)
        System.out.println("이 문장은 실행되지 않음");
    }
}```

```java
Exception in thread "main" java.lang.ArithmeticException: / by zero
    at chapter3.exception.Main.main(Main.java:8)

Process finished with exit code 1

의도적인 예외 - throw

public class Main {
    public static void main(String[] args) {
        int age = 10;
        if (age < 18) {
                // ✅ 의도적으로 예외를 발생시키는 부분
            throw new IllegalArgumentException("미성년자는 접근할 수 없습니다!");
        }
        System.out.println("....");
    }
}

예외 구조와 종류

예외 전파

RuntimeException - UncheckedException

try-catch 활용

public class ExceptionPractice {
    public void callUncheckedException() {
        if (true) {
            System.out.println("언체크 예외 발생");
            throw new RuntimeException(); // ✅ 예외발생 
        }
    }
}

public class Main {
    public static void main(String[] args) {
        // 예외 실습 객체 인스턴스화
        ExceptionPractice exceptionPractice = new ExceptionPractice();

        // ✅ 언체크 예외 호출
        exceptionPractice.callUncheckedException();

        // ❌ 예외처리를 해주지 않았기 때문에 프로그램이 종료됩니다.
        System.out.println("이 줄은 실행되지 않습니다."); 
    }
}

public class Main {

    public static void main(String[] args) {
        ExceptionPractice exceptionPractice = new ExceptionPractice();

        // ✅ 상위로 전파된 예외처리
        try {
            exceptionPractice.callUncheckedException();

        } catch (RuntimeException e) { // ✅ 예외처리
            System.out.println("언체크 예외 처리");   

        } catch (Exception e) {
            System.out.println("체크 예외 처리");
        }

        System.out.println("프로그램 종료");
    }
}

Exception - CheckedException

try-catch 활용

public class ExceptionPractice {

    public void callCheckedException() {
            // ✅ try-catch 로 예외 처리
        try { 
            if (true) {
                System.out.println("체크예외 발생");
                throw new Exception();
            }
        } catch (Exception e) {
            System.out.println("예외 처리");
        }
    }
}

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

        // 예외 실습 객체 인스턴스화
        ExceptionPractice exceptionPractice = new ExceptionPractice();

        // ✅ 체크예외 호출
        exceptionPractice.callCheckedException();
    }
}

throws 활용

public class ExceptionPractice {

    public void callCheckedException() throws Exception { // ✅ throws 예외를 상위로 전파
        if (true) {
            System.out.println("체크예외 발생");
            throw new Exception();
        }
    }
}

package chapter3.exception;

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

        // 예외 실습 객체 인스턴스화
        ExceptionPractice exceptionPractice = new ExceptionPractice();

        // 체크 예외 사용
        // ✅ 반드시 상위 메서드에서 try-catch 를 활용해 주어야합니다.
        try {
            exceptionPractice.callCheckedException();
        } catch (Exception e) {
            System.out.println("예외처리");
        }
    }
}

챕터3-2 : Optional - null 을 다루는 법

Optional 이란?

Optional 이 왜 필요한가?

public class Student {

    // 속성
    private String name;

    // 생성자

    // 기능
    public String getName() {
        return this.name;
    }
}

public class Camp {

    // 속성
    private Student student;

    // 생성자

    // 기능: ⚠️ null 을 반환할 수 있는 메서드
    public Student getStudent() {
        return student;
    }

    public void setStudent(Student student) {
            this.student = student;    
    }
}

public class Main {

    public static void main(String[] args) {

        Camp camp = new Camp();
        Student student = camp.getStudent(); // ⚠️ student 에는 null 이 담김
        // ⚠️ 아래 코드에서 NPE 발생! 컴파일러가 잡아주지 않음
        String studentName = student.getName(); // 🔥 NPE 발생 -> 프로그램 종료
        System.out.println("studentName = " + studentName);
    }
}

NULL 을 직접 처리의 한계

public class Main {
    public static void main(String[] args) {
        Camp camp = new Camp();
        Student student = camp.getStudent();

        String studentName;
        if (student != null) { // ⚠️ 가능은하지만 현실적으로 어려움
            studentName = student.getName();
        } else {
            studentName = "등록된 학생 없음"; // 기본값 제공
        }

        System.out.println("studentName = " + studentName);
    }
}

Optional 활용하기

import java.util.Optional;

public class Camp {

    // 속성
    private Student student;

    // 생성자

    // 기능
    // ✅ null 이 반환될 수 있음을 명확하게 표시
    public Optional<Student> getStudent() {
        return Optional.ofNullable(student);
    }

    public void setStudent(Student student) {
            this.student = student;    
    }
}

public class Main {

    public static void main(String[] args) {

        Camp camp = new Camp();

        // isPresent() 활용시 true 를 반환하고 싶을때 활용
        // Student newStudent = new Student();
        // camp.setStudent(newStudent);

        //  Optional 객체 반환받음
        Optional<Student> studentOptional = camp.getStudent();

        // Optional 객체의 기능 활용
        boolean flag = studentOptional.isPresent(); // false 반환
        if (flag) {
            // 존재할 경우
            Student student = studentOptional.get(); // ✅ 안전하게 Student 객체 가져오기
            String studentName = student.getName();
            System.out.println("studentName = " + studentName);

        } else {
            // null 일 경우
            System.out.println("학생이 없습니다.");
        }
    }
}

import java.util.Optional;

public class Camp {

    // 속성
    private Student student;

    // 생성자

    // 기능
    // ✅ null 이 반환될 수 있음을 명확하게 표시
    public Optional<Student> getStudent() {
        return Optional.ofNullable(student);
    }
}

import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        Camp camp = new Camp();

        // ✅ Optional 객체의 기능 활용 (orElseGet 사용)
        Student student = camp.getStudent()
                              .orElseGet(() -> new Student("미등록 학생"));

        System.out.println("studentName = " + student.getName());
    }
}

fork, clone 차이

Pull Request 생성과 개념 이해

챕터5-1 : 프로젝트 관리하기 (2) - 브랜치 전략 1

Dev, Stage, Prod Branch 구성

📚 Git에서 Dev, Stage, Prod 브랜치 구성을 사용하는 이유는 개발, 테스트, 그리고 배포 단계를 명확히 구분하여 안정성과 협업 효율성을 높이기 위함입니다. 각 브랜치의 역할과 구성 방식은 다음과 같습니다.

1️⃣

Dev 브랜치 (Development Branch)

역할

• 새로운 기능 개발(feature)과 버그 수정(bugfix)을 포함한 모든 작업의 기반 브랜치입니다.
• 개발자들이 가장 활발히 작업하는 브랜치로, 실험적 코드와 아직 완전하지 않은 변경 사항도 포함될 수 있습니다.

특징

• 이 브랜치의 상태는 안정적이지 않을 수 있으며, 테스트가 완벽히 이루어지지 않은 상태의 코드가 포함됩니다.

병합 흐름

• 개발 완료 후, stage 브랜치로 병합.

2️⃣

Stage 브랜치 (Staging Branch)

역할

• 배포 전의 최종 테스트 환경을 제공하며, 통합 테스트(Integration Test)와 품질 보증(QA)이 이루어지는 단계입니다.
• 실질적으로 배포 준비가 완료된 코드를 포함합니다.

특징

• dev 브랜치에서 충분히 검증된 코드를 이 브랜치로 병합하여 테스트.
• 테스트 환경에서는 실제 운영 환경(Prod)과 유사한 설정을 사용하여 예상치 못한 문제를 미리 발견합니다.

병합 흐름

• dev → stage로 병합 후 테스트 진행.
• 테스트 통과 후, prod 브랜치로 병합.

3️⃣ Prod 브랜치 (Production Branch)

역할

• 실제 사용자가 접근하는 프로덕션 환경의 코드를 포함하는 브랜치입니다.
• 이 브랜치의 코드는 반드시 안정적이고, 배포 가능한 상태여야 합니다.

특징

• 사용자가 직접 사용하는 서비스의 모든 변경 사항은 이 브랜치에 반영됩니다.
• 긴급 수정이 필요한 경우, hotfix/ 브랜치를 사용하여 Prod 브랜치에서 작업 후 바로 병합할 수도 있습니다.
• 버전 태그(tag)를 통해 배포 이력을 관리하는 경우가 많습니다.

병합 흐름

• stage → prod로 병합하여 배포.

📚 master (최근 생성되는 브랜치에서는 모두 main), develop은 우리가 앞전에 봤기 때문에 스킵하지만, 여기서 hotfix, release, feature 3개 브랜치의 용도에 대해서는 이해할 필요가 있습니다.

feature 브랜치

역할

• 새로운 기능 개발을 위한 브랜치입니다.
• 보통 develop 브랜치에서 분기하여 작업을 시작하고, 개발이 완료되면 다시 develop 브랜치로 병합됩니다.

작명 규칙

• feature/login-page, feature/api-integration 등 기능 이름을 포함.

사용 시점

• 특정 기능이나 개선 사항을 독립적으로 작업.
• 코드 리뷰와 기본 테스트를 거친 후 develop 브랜치에 병합.

2️⃣

release 브랜치

역할

• 배포 전 최종 테스트 및 QA(품질 보증)를 위한 브랜치입니다.
• develop 브랜치에서 분기하며, 모든 버그가 수정되고 테스트를 통과하면 master 브랜치에 병합됩니다.
• 테스트 중 발견된 버그는 release 브랜치에서 바로 수정한 후 병합.

사용 시점

• 새로운 릴리스를 준비할 때.
• 안정화 작업 완료 후 master 및 develop에 병합.

3️⃣ hotfix 브랜치

역할

• 프로덕션에서 발생한 긴급 버그를 수정하기 위한 브랜치입니다.
• master 브랜치에서 바로 분기하며, 수정이 완료되면 다시 master와 develop 브랜치로 병합됩니다.

사용 시점

• 프로덕션에서 긴급한 수정이 필요할 때.
• 예: 치명적인 보안 결함, 서비스 중단 이슈 등.

작명 규칙

• hotfix/critical-bug, hotfix/payment-error 등.

Git의 기본 - 분산형 버전 관리 시스템

git 의 작업 흐름을 시각적으로 나타내는 구조도

1.Working Tree

2. Working Directory

3. Stage Area

4. Local Directory

1. git commit

2. snapshot

3. Head

4. Branch

5. Merge

1번째 오류

팀 레포를 clone 받는 건 성공했는데, 내 브랜치에서 push를 하려고 하니 403 에러가 났다.

원인은 권한 문제였다.

clone은 public 레포라서 가능했지만, push는 쓰기 권한이 있어야 가능한 작업이었다. 즉, 팀 레포에 collaborator 또는 write 권한이 없어서 막힌 상태였다.

2번째 헷갈렸던 점

다른 분들이 올린 코드를 어떻게 승인 하는지 몰랐는데 팀원분 덕분에 찾을 수 있었다.

팀장님께서 과제 순서를 잘 정리해주셔서 강의를 다 듣지 못한 상태에서 잘 완료 한 것 같다.

1. 저장소 복제

2. 새 브렌치

3. 위에 브렌치가 바꼈는지 확인 후 내이름.md 파일 생성 후 작성하기

4. 커밋 및 푸시

5. 풀 리퀘스트

6. 다른 사람 문서에 코멘트 하나씩 달기.

7. 코멘트 달린거 확인 후 팀원들이 승인해주면(수정할게 더 없다고 판단되면) Merge pull request를 누르기

챕터2-1 : 클래스와 객체

# 챕터2-2 : JVM 메모리 영역

챕터2-3 : 레퍼클래스(기본형 참조형)

챕터2-4 : static - 클래스가 공유하는 공간

챕터2-5 : final - 변하지 않는 값

챕터2-6 : 인터페이스 - 표준화의 시작

챕터2-7 : 객체지향 PART 1 - 캡슐화(접근제어자)

챕터2-8 : 객체지향 PART 2 - 상속

챕터2-9 : 객체지향 PART 3 - 추상화

# 챕터2-10 : 객체지향 PART 4 - 다형성

첫 번째 반복문 for

문법: for 문의 구조

break문

continue문

두 번째 반복문 while

세 번째 반복문 do-while

챕터1-9 : 배열 - 데이터 관리의 시작

배열(Array)

배열 탐색

향상된 for 문 - 현업에서 많이 활용됩니다

2차원 배열(Two-Dimensional Array)

2차원 배열을 직접 탐색

자바 기초 문법을 다시 복습할 수 있는 시간이어서 좋았다.

1. 카드가 안 뜨는 게 오류인지 정상인지 헷갈렸다

처음 GET /places를 연결했을 때 화면에 카드가 안 떴다. 처음에는 코드 오류라고 생각했지만, 실제로는 mockAPI에 데이터가 없어서 응답이 빈 배열([])이었던 상태였다.

이 과정에서 중요한 건 “안 보이는 것”과 “오류”를 구분하는 것이었다.

확인 방법은 아래 순서로 했다.

• Console에 에러가 있는지 확인
• Network에서 GET /places 요청 상태 코드 확인
• Response가 []인지 확인

결과적으로 이번 경우는 오류가 아니라 정상 작동인데 데이터가 없는 상태였다.

2. 프론트 필드와 서버 필드 이름이 달랐다

HTML 폼에서는 위치 입력칸 id가 location이었는데, mockAPI에는 address 필드로 저장해야 했다. 즉, 프론트에서 입력받은 값을 서버가 원하는 구조로 바꿔줘야 했다.

예를 들어:

• 프론트: location
• 서버: address

이 경험을 통해 프론트 필드명과 서버 필드명이 항상 같을 필요는 없지만, 중간에서 정확히 매핑해주는 코드가 필요하다는 걸 배웠다.

3. call, description 필드를 처음에는 제대로 안 맞췄다

처음에는 HTML에는 description이 있는데 mockAPI에는 해당 필드가 없었고, 반대로 mockAPI에는 call이 있는데 폼에는 입력칸이 없었다.

이 상태에서는 입력한 값이 제대로 저장되지 않거나, 임시값으로 처리해야 하는 문제가 생겼다.

그래서 최종적으로는

• HTML에 call 입력칸 추가
• mockAPI에 description 필드 추가
• POST 요청 body에 둘 다 포함

하는 방식으로 맞췄다.

이 과정을 통해 프론트와 백엔드는 필드 구조가 맞아야 제대로 동작한다는 걸 느꼈다.

4. 삭제와 수정에서는 id가 핵심이었다

삭제와 수정 기능을 구현하면서 id의 중요성을 확실히 느꼈다.

• 삭제는 어떤 데이터를 지울지 알아야 하고
• 수정은 어떤 데이터를 수정할지 알아야 한다

그래서 카드마다 data-id를 넣고, 그 값을 기준으로

• DELETE /places/:id
• PUT /places/:id

를 요청했다.

이 과정에서 id는 단순 번호가 아니라 데이터를 식별하는 핵심 값이라는 걸 이해하게 됐다.

5. 수정 기능은 상태 관리가 필요했다

등록 기능은 폼 값을 읽어서 POST만 보내면 됐지만, 수정 기능은 더 복잡했다.

수정 버튼을 누르면

• 기존 데이터를 폼에 채워야 하고
• 지금이 등록 모드인지 수정 모드인지 구분해야 하고
• 제출할 때 POST가 아니라 PUT을 보내야 했다

그래서 editingId라는 변수를 두고 수정 중인 데이터를 구분했다.

이 과정을 통해 수정 기능은 단순히 값만 바꾸는 게 아니라, 현재 상태를 관리하는 로직이 필요하다는 걸 배웠다.

마무리

오늘 mockAPI로 CRUD를 구현하면서 느낀 건, 프론트와 백엔드 연결은 단순히 fetch 하나로 끝나는 게 아니라는 점이었다.

중간에는 항상 이런 확인이 필요했다.

• 지금 안 되는 이유가 오류인가?
• 데이터가 없는 정상 상태인가?
• 프론트 필드와 서버 필드가 맞는가?
• 어떤 id를 기준으로 수정/삭제할 것인가?

이번 작업을 통해 폼 입력 → API 요청 → 서버 데이터 변경 → 다시 화면 반영이라는 웹 서비스의 기본 흐름을 직접 경험할 수 있었다.