특히 단순 CRUD 구현을 넘어서:

• Offset Pagination (Page)
• Cursor Pagination (Slice)
• Java Stream API
• 객체 그래프 탐색
• @Valid 기반 검증 처리

등 실무에서도 자주 등장하는 개념들을 직접 API로 구현해보며 익힐 수 있었습니다.

그리고 이번 미션에서는:

• 내가 진행중인 미션 조회 API
• 내가 작성한 리뷰 조회 API
• Validation 예외 처리

를 중심으로 구현을 진행했다.

1. Page와 Slice

Spring Data JPA에서는 페이지네이션을 위해 Page와 Slice를 제공함

1) Page

: 전체 데이터 수까지 함께 조회하는 방식

Page<Participate>

특징

• 전체 페이지 수 제공
• 전체 데이터 개수 제공
• count query 추가 실행

사용 예시

PageRequest pageRequest =
        PageRequest.of(page, 3);
Page<Participate> participatePage =
        participateRepository
                .findAllByMemberIdAndStatus(
                        memberId,
                        ParticipatedStatus.CHALLERGING,
                        pageRequest
                );

2) Slice

: 다음 페이지 존재 여부만 확인하는 방식

Slice<Review>

특징

• count query 실행 X
• 다음 데이터 존재 여부만 확인
• cursor pagination에 적합

사용 예시

Slice<Review> reviewSlice =
        reviewRepository
                .findByMemberIdAndIdLessThanOrderByIdDesc(
                        memberId,
                        cursor,
                        pageable
                );

2. Java Stream API

• 컬렉션 데이터를 선언형 방식으로 처리하기 위한 API이고,
• 반복문 대신 stream을 사용하여 가독성을 높일 수 있음

map()

map()은 데이터를 다른 형태로 변환할 때 사용

return missionList.stream()
        .map(MissionConverter::toMissionPreviewDTO)
        .toList();

의미 Mission 객체 → MissionPreviewDTO 변환

3. 객체 그래프 탐색

JPA에서는 연관관계를 통해 다른 Entity 데이터에 접근할 수 있음

예를 들어:

Participate
 └── Mission

관계가 존재할 때:

participate.getMission()

을 통해 Mission 객체에 접근 가능

사용 예시

Mission mission = participate.getMission();
mission.getContent()
mission.getPoint()
mission.getEndDate()

장점

1. 객체지향적인 코드 작성 가능
2. JOIN SQL을 직접 작성하지 않아도 됨

주의점

: Lazy Loading으로 인해 N+1 문제가 발생할 수 있다.

4. @Valid vs @Validated

@Valid

• Java 표준 Validation Annotation
• 주로 Request Body 검증 시 사용함

  @RequestBody @Valid MissionReqDTO.CreateMission dto

@Validated

• Spring에서 제공하는 확장 Validation 기능

특징 :

1. 그룹 검증 가능
2. 클래스 레벨 검증 가능

차이점 정리

미션 정리

미션 1) 내가 진행중인 미션 조회 API

• Offset 기반 페이지네이션(Page) 적용
• Request Body를 통해 memberId를 전달받도록 구현
• ParticipatedStatus.CHALLERGING 상태의 미션만 조회하도록 구현
  

미션 2) 내가 생성한 리뷰 조회 API

• Cursor 기반 페이지네이션(Slice) 적용
• 사진 데이터 제외 후 리뷰 정보만 반환
• 정렬 기준을 query parameter로 분기 처리

1. sort=id→ 최신 리뷰(ID DESC)
2. sort=stars → 별점 기준 정렬(STARS DESC)

미션 3) Validation 적용

• Request Body DTO에 Validation Annotation 적용

  1. @NotBlank
  2. @NotNull
  

• @Valid를 통한 요청값 검증 적용
  

  

• GeneralExceptionAdvice에서 MethodArgumentNotValidException 처리 구현

  

이번 주차에서는 단순 CRUD 구현을 넘어 실제 서비스에서 자주 사용되는 페이지네이션과 Validation 처리 방식을 직접 구현해볼 수 있었다.

특히:

• Offset Pagination과 Cursor Pagination의 차이
• Page와 Slice의 사용 목적
• 객체 그래프 탐색
• Validation 예외 처리

등을 직접 API에 적용해보며 개념을 더 명확하게 이해할 수 있었습니다 !

이번 주차부터는 Spring Boot에서 가장 중요하다고 느껴지는 JPA를 본격적으로 학습했다.
단순히 CRUD를 구현하는 것을 넘어서 객체와 데이터베이스를 어떻게 연결하고 관리하는지에 대한 흐름을 이해할 수 있었고
실제로 연관관계 매핑과 API 구현까지 진행해보며 JPA의 동작 방식을 조금 더 체감할 수 있었다.

1. 객체 지향과 RDB의 패러다임 차이

자바는 객체 중심으로 데이터를 관리하지만, 데이터베이스는 테이블 중심으로 데이터를 저장한다. 이 과정에서 객체 ↔ 테이블 변환 작업이 반복되며 패러다임 불일치가 발생한다. 예를 들어 JDBC만 사용할 경우:

• 직접 SQL 작성
• 객체와 테이블 매핑
• CRUD 반복 작업

등을 개발자가 모두 처리해야 한다. 이 문제를 해결하기 위해 등장한 것이 JPA이다.

2. JPA란?

JPA(Java Persistence API)는 자바 ORM 기술의 표준 인터페이스이다. 객체와 데이터베이스 테이블을 자동으로 매핑해주며, 반복적인 SQL 작성을 줄여준다.

대표 구현체:

• Hibernate
• JPA의 핵심 장점:
• 객체 중심 개발 가능
• 생산성 증가
• 유지보수 편리
• SQL 자동 생성
  

3. 영속성 컨텍스트(Persistence Context)

JPA의 핵심 개념 중 하나로, 엔티티를 관리하는 논리적 공간이다.

주요 기능:

• 1차 캐시
• 변경 감지(Dirty Checking)
• 쓰기 지연 SQL 저장소
• 지연 로딩

1차 캐시

같은 엔티티를 다시 조회할 경우 DB가 아닌 캐시에서 조회한다. → 불필요한 SQL 감소

변경 감지(Dirty Checking)

엔티티 값을 수정하면 JPA가 변경 사항을 자동으로 감지한다.

member.setName("UMC");

별도의 update 쿼리를 작성하지 않아도 commit 시점에 UPDATE SQL이 실행된다.

4. flush와 commit 차이

flush

• 변경 내용을 DB에 반영
• 트랜잭션은 유지됨

commit

• flush 이후 최종 저장
• 트랜잭션 종료

즉:

flush → SQL 반영
commit → 최종 확정

5. 연관관계 매핑

JPA에서는 객체 간 관계를 어노테이션으로 표현한다.

대표 어노테이션:

• @ManyToOne
• @OneToMany
• @OneToOne

예시:

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;

6. 즉시 로딩 vs 지연 로딩

즉시 로딩(EAGER)

연관 객체를 함께 조회한다.

장점:

• 바로 사용 가능

단점:

• 불필요한 조회 발생 가능
• N+1 문제 발생 위험

지연 로딩(LAZY)

실제로 사용할 때 조회한다.

장점:

• 성능 최적화에 유리
• 실무에서 많이 사용

7. N+1 문제

연관 데이터를 조회하는 과정에서 불필요한 쿼리가 반복 실행되는 문제이다.

예시:

• 회원 목록 조회 1번
• 회원마다 게시글 조회 N번
• → 총 N+1번 SQL 실행* : 성능 저하의 주요 원인이 된다.
  

8. JPQL

JPQL은 엔티티 객체를 대상으로 작성하는 객체 지향 쿼리 언어이다. SQL과 유사하지만 테이블이 아닌 엔티티 기준으로 동작한다.

@Query("SELECT m FROM Member m WHERE m.name = :name")

9. Fetch Join과 @EntityGraph

Fetch Join

연관 엔티티를 한 번의 쿼리로 함께 조회하는 기능 → N+1 문제 해결에 사용

@EntityGraph

Fetch Join을 어노테이션 기반으로 편리하게 사용하는 방식

@EntityGraph(attributePaths = {"orders"})

Repository 메서드와 함께 사용할 수 있어 코드가 간결함

이번주차 과제

6주차 미션 PR

미션 1) 마이페이지 조회 API 구현

GET /members/home/my

• memberId를 기반으로 사용자 정보 조회하도록 memberId params 추가
• 사용자 이름, 이메일, 포인트 반환
• 실행결과

미션 2) 리뷰 작성 API 구현

POST /review/markets/{marketId}

• memberId와 marketId를 기반으로 리뷰 작성 기능 구현
• 리뷰 저장 후 reviewId 및 성공 메시지 반환
• 실행결과

미션 3) 진행중 / 완료 미션 조회 API 구현

GET /mission

• memberId와 ParticipatedStatus(CHALLENGING / COMPLETE)를 기반으로 참여 미션 목록 조회
• Pageable 기반 페이징 처리 구현
• @query + JOIN FETCH를 사용하여 Mission 연관 데이터 조회

@query + JOIN FETCH를 사용하여 Mission 연관 데이터 조회
@Query(""" 
    SELECT p 
    FROM Participate p 
        JOIN FETCH p.mission m 
        WHERE p.member.id = :memberId 
        AND p.status = :status 
""")

• 실행 결과

미션 4) 홈 화면 지역별 진행 중인 미션 조회 API 구현

GET /mission/home

• regionName 기반으로 특정 지역의 진행중(IN_PROGRESS) 미션 목록 조회
• Pageable 기반 페이징 처리 구현
• @query + JOIN FETCH를 사용하여 Market, Region 연관 데이터 조회

  @Query(""" 
  SELECT m FROM Mission m 
  JOIN FETCH m.market mk 
  JOIN FETCH mk.region r WHERE r.name = :regionName 
          AND m.missionStatus = :status 
  """)

• 실행결과

6주차 스터디 느낀점

이번 주차를 통해 JPA가 단순히 SQL을 대신 작성해주는 기술이 아니라, 객체 중심으로 개발할 수 있도록 도와주는 ORM 기술이라는 점을 이해할 수 있었다.

특히 연관관계 매핑과 지연 로딩, Fetch Join을 직접 적용해보며 성능 최적화 관점에서도 많은 고민이 필요한 기술이라는 점을 느꼈고

앞으로는 단순 기능 구현을 넘어 쿼리 최적화와 객체 그래프 탐색 흐름까지 함께 고려하며 개발하는 연습을 해야겠다고 생각했습니다 .

이번 주차에서는 단순히 API를 만드는 것이 아니라, Spring Boot에서 계층을 어떻게 나누고 응답과 예외를 어떻게 관리하는지 학습했습니다.

특히 포인트 5가지

• Controller / Service / Repository 역할
• DTO 사용 이유
• ApiResponse를 통한 응답 통일
• Exception Handling 구조
• Swagger를 이용한 API 테스트

를 중심으로 정리했습니다.

1. Controller / Service / Repository 구조

1-1. Controller

Controller는 클라이언트의 요청을 가장 먼저 받는 계층입니다.

Controller의 주요 역할

• HTTP 요청 받기
• Request Body / Query Parameter 매핑
• Service 호출
• 결과 응답 반환

예시:

@RestController
@RequestMapping("/members")
@RequiredArgsConstructor
public class MemberController {

    private final MemberService memberService;

    @PostMapping
    public ApiResponse<MemberResDTO.MemberInfoDTO> getMember(
            @RequestBody MemberReqDTO.MemberRequestDTO request
    ) {
        return ApiResponse.onSuccess(
                memberService.getMember(request)
        );
    }
}

1-2. Service

Service는 실제 비즈니스 로직을 처리하는 계층이다.

Service의 주요 역할:

• 요청 데이터 처리
• Repository 호출
• 비즈니스 로직 수행
• 응답 DTO 반환

예시:

@Service
@RequiredArgsConstructor
@Transactional
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberResDTO.MemberInfoDTO getMember(Long memberId) {

        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new MemberException(MemberErrorCode.NOT_FOUND));

        return MemberConverter.toMemberInfoDTO(member);
    }
}

1-3. Repository

Repository는 DB와 직접 통신하는 계층이다.

JPA에서는 JpaRepository를 상속받아 사용함

public interface MemberRepository extends JpaRepository<Member, Long> {}

기본적으로 다음 메서드를 제공한다.

• save()
• findById()
• delete()
• findAll()

또한 메서드 이름만으로 커스텀 조회도 가능하다.

findByEmail(String email)

2. DTO를 사용하는 이유

DTO(Data Transfer Object)는 계층 간 데이터 전달 객체이다. 이번 주차에서는 Request DTO와 Response DTO를 분리해서 사용했다.

DTO를 사용하는 이유

• 요청/응답 구조를 명확하게 관리 가능
• Entity 직접 노출 방지
• 안정성 증가
• 유지보수 용이

record vs static class

record

public record MemberDTO(String name, String email) {}

특징:

• 코드가 간결함
• 불변 객체 생성
• Java 16 이상 지원

static class

@Getter
@AllArgsConstructor
public static class MemberDTO {
    private String name;
    private String email;
}

특징:

• 유연한 구조 설계 가능
• 확장성이 높음

3. ApiResponse를 이용한 응답 통일

프로젝트에서는 API 응답 형식을 통일해서 사용했다.

{
  "isSuccess": true,
  "code": "COMMON200",
  "message": "성공입니다.",
  "result": {}
}

응답 통일의 장점

• 프론트엔드와 협업이 쉬움
• 성공/실패 구조 일관성 유지
• 유지보수 편리
• 에러 처리 단순화

ApiResponse 예시

public class ApiResponse<T> {

    private Boolean isSuccess;
    private String code;
    private String message;
    private T result;
}

여기서 제네릭 를 사용해 다양한 타입의 응답을 처리할 수 있다.

4. Exception Handling

예외 상황에서도 응답 형식을 통일하기 위해 @RestControllerAdvice를 사용했다.

구조 Exception 발생→ ControllerAdvice에서 감지→ ApiResponse 형태로 반환

예시:

@RestControllerAdvice
public class GeneralExceptionAdvice {

    @ExceptionHandler(ProjectException.class)
    public ResponseEntity<ApiResponse<Void>> handleException(
            ProjectException e
    ) {
        return ResponseEntity
                .status(e.getErrorCode().getStatus())
                .body(ApiResponse.onFailure(e.getErrorCode(), null));
    }
}

5. Optional 사용 이유

JPA의 findById()는 Optional을 반환한다.

memberRepository.findById(id)

따라서 값이 없을 경우를 안전하게 처리할 수 있다.

.orElseThrow(() -> new MemberException(...))

이를 통해 NullPointerException을 방지할 수 있다.

이번 주차에서 느낀 점

이번 주차를 진행하면서 단순히 “API가 동작하는 것”보다 “왜 계층을 분리하는지”를 이해하는 것이 중요하다는 걸 느꼈다.

특히 ApiResponse와 Exception Handling 구조를 직접 적용해보면서, 프로젝트 전체의 응답 형식을 통일하는 이유를 체감할 수 있었다.

또한 DTO를 통해 Entity를 직접 노출하지 않는 구조가 유지보수 측면에서 훨씬 안전하다는 점도 이해하게 되었다.

그런 다음 이미 설치된 react가 있기 때문에, 바로 프로젝트 생성을 했다.

❶ 프로젝트 생성하기

% npm create vite@latest 

해당 명령어를 입력하게 되면

쥬륵주륵 설치가 될거고

이렇게 local: http://localhost:5713/ 이 나오면 프로젝트가 생성되고 실행된 것 (접속하려면 command누른채로 커서 클릭해야함!!)

접속하게 되면 리엑트 자체의 기본 화면이 나온다 (이 화면이 나오면 성공)

하나의 터미널에서 서버를 띄운 상태로 개발은 이어갈 수 없음. 그래서 서버를 닫아야하는데, 그때는 컨트롤c를 누르면 됨 !!

그리고 개발을 계속 하는 전공자나, 팀프로젝트로 진행되는 프로젝트로 하는 거라면 git을 사용하는게 좋다. (팀프로젝트가 아니더라도 이 프로젝트의 과정을 처음부터 끝까지 남기기 위해선?..)

그치만 깃이 은근.... 비전공자가 사용하기엔 위험도 있고, 공부는 필요해서 구조 다 잡고 배포할 때 그때 깃에 올려도 충분함!

그래서 지금 적는 깃 설정은 건너 뛰어도 됨!//

❷ git 연결해두기

우선, 정말 처음이라 깃 계정도 없다 ! 하면 https://github.com 여기서 가입부터 해야함

계정이 있다면 바로 시작

레포지토리에 들어가서 오른쪽 상단을 보면 new 버튼이있음

이름 설정하고 하단에 readme on으로 켜주고, 다른 사람들한테 이 파일 보이지 않게 하려면 private로 바꿔주면 된다! (전 이게 개인 프로젝트니까 private로 생성했습니다)

❸ 프로젝트에 깃 연결하기

yujin_portfolio % cd yujin_blog
yujin_blog % git init
yujin_blog % git remote add origin https://github.com/yujining3827/yujin-site.git

origin 뒤의 https://github.com/yujining3827/yujin-site.git 이 링크는

여기서 바로 복붙 아이콘 눌러서 가져오면 됩니다.

yujin_blog % git add .
yujin_blog % git commit -m "init: react project"

초기 프로젝트 세팅을 저장하는 명령어고

yujin_blog % git push -u origin main --force

함부로 쓰면 안되는 git 명령어지만, 지금 로컬을 전체 덮어쓰기로 올리는 명령어입니다ㅎ,,

명심할게 정말 함부로 쓰면 안된다 !! 이정도??

이렇게 하면 정상적으로 깃에 반영됨

깃헙 해당 레포에서 실시간으로 확인 가능 !

3주차에서는 HTTP 통신과 스프링의 기본 동작 원리에 대해 학습했다면, 이번 4주차에서는 드디어 실제 Spring Boot 프로젝트를 생성하고 구조를 설계하는 단계로 넘어갔다.

단순히 코드를 작성하는 것이 아니라, 어떻게 구조를 설계할 것인지를 고민하는 단계였다는 점이 가장 중요했다.

📌 아키텍처 구조란?

아키텍처 구조는 쉽게 말하면 프로젝트의 뼈대를 설계하는 것이다.

단순히 코드를 작성하는 것이 아니라,

어떤 기준으로 파일을 나눌지 어떤 역할을 어디에 둘지 어떻게 확장할 수 있게 만들지

를 미리 고민하는 과정이다.

✔ 왜 필요한가?

• 유지보수가 쉬워짐
• 기능 추가 시 영향 범위 최소화
• 협업 시 구조 이해가 쉬움

📌 아키텍처 구조의 종류

1️⃣ 계층형 아키텍처

Controller
Service
Repository

이렇게 역할 기준으로 나누는 방식으로 대부분의 기본적인 Spring 구조

2️⃣ 도메인형 아키텍처

기능(도메인) 기준으로 구조 분리

예:

user
mission
review

각 도메인 안에 controller / service / repository 포함

📌 이번 과제에서 사용한 구조

이번 미션에서는 도메인형 아키텍처를 기반으로 프로젝트를 구성했다.

워크북 기준 도메인을 보면

사용자
미션
리뷰

로 나눌 수 있었고,

내 ERD를 기준으로 다음과 같이 구성했다.

< 도메인 분리 >

사용자 user, preference, food_category user_term_agreement, term, notification

미션 mission, participate, market, region

리뷰 review

📌 프로젝트 세팅

1️⃣ Spring Boot 프로젝트 생성

• Gradle (Groovy)
• Spring Web
• Spring Data JPA
• MySQL Driver
• Lombok

2️⃣ 환경 설정 (application.yml)

spring:
  application:
    name: "umc10th"

  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: ${DB_URL}
    username: ${DB_USER}
    password: ${DB_PW}

  jpa:
    database: mysql
    database-platform: org.hibernate.dialect.MySQLDialect
    show-sql: true
    hibernate:
      ddl-auto: update

👉 민감 정보는 .env로 분리해서 관리

📌 도메인형 패키지 구조

domain
 ├── user
 ├── mission
 ├── review
 ├── notification
 ├── term
 ├── region
 └── preference

global
 ├── config
 ├── exception

각 도메인 내부 구조:

controller
service
repository
entity
dto
converter

📌 Swagger 설정

Swagger는 API 문서를 자동으로 생성하고 테스트할 수 있는 도구이다.

❶ 의존성 추가

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:3.0.1'

❷ SwaggerConfig

@Configuration
public class SwaggerConfig {

    @Bean
    public OpenAPI swagger() {
        Info info = new Info()
                .title("UMC10th")
                .description("10기 Swagger")
                .version("0.0.1");

        return new OpenAPI()
                .info(info)
                .addServersItem(new Server().url("/"));
    }
}

❸ 결과 확인

http://localhost:8080/swagger-ui/index.html 로 접속하면 API 문서를 UI로 확인 가능

📌 핵심 개념 정리

1. DTO

• 계층 간 데이터 전달 객체
• Entity 직접 노출 방지

2. Converter

• DTO ↔ Entity 변환 담당
• 역할 분리 & 유지보수성 증가

3. DDD vs 도메인형 아키텍처

• DDD → 설계 철학
• 도메인형 아키텍처 → 코드 구조 방식

📌 느낀 점

이번 4주차를 하면서 가장 크게 느낀 점은 “코드를 잘 짜는 것보다 구조를 잘 짜는 게 더 중요하다”는 것이었다.

처음에는 단순히 프로젝트를 생성하는 단계라고 생각했는데, 실제로는

ERD를 기반으로 도메인을 나누고 구조를 설계하고 확장성을 고려하는

설계 중심의 단계였다.

📌 마무리

이번 주차에서는 단순한 코드 작성이 아닌 구조 설계의 중요성을 배울 수 있었다.

다음 주차에서는 이 구조 위에 실제 API를 구현해보면서 더 깊이 이해해보고 싶다.

이번 3주차에서는 스프링의 핵심 개념인 IoC와 DI를 시작으로, 객체 생성부터 HTTP 요청 처리까지의 전체 흐름을 학습했습니다.

특히 부록 1~4를 통해 Bean 생성 → Filter → DispatcherServlet → 응답 처리까지 실제 실행 흐름을 따라가며 스프링의 내부 구조를 이해하는 데 집중했습니다.

3주차 워크북 정리

1. Spring이 무엇인가 → “프레임워크”

Spring은 자바 애플리케이션을 쉽게 만들도록 도와주는 프레임워크

핵심은 “뼈대 제공”

자주 쓰는 기능 구조를 미리 만들어둠 개발자는 그 안에 코드만 채움

2. 프레임워크 vs 라이브러리 → “제어권 차이”

** ★ 라이브러리 ** : 내가 필요할 때 호출 제어권 → 개발자

*★ 프레임워크 * : 내가 코드를 넣으면 알아서 실행 제어권 → 프레임워크

3. IoC → 제어권이 넘어간 상태

프레임워크를 쓰면 발생하는 핵심 개념 제어의 역전 (IoC)

객체 생성 / 실행 흐름 / 생명주기 → 개발자가 아니라 프레임워크가 관리

즉, “내가 실행하는 구조” → “프레임워크가 실행하는 구조”

4. DI → IoC를 실제로 구현하는 방법

IoC만으로는 추상적이기 때문에 이를 구현하는 방법이 필요한데, 그게 DI

객체가 필요한 의존성을 직접 생성 ❌ 외부에서 주입받음 ⭕

5. 왜 DI가 필요한가 → 결합도 문제 해결

문서에서 핵심 예시: 커피 머신

기존 (강한 결합)

• CoffeeMachine 내부에서 직접 객체 생성
• 부품 바꾸려면 전체 코드 수정 필요

DI 적용 (느슨한 결합)

• 인터페이스 + 외부 주입
• Bean만 바꾸면 동작 변경 가능

결과

• 유지보수 쉬움
• 확장 쉬움

6. Spring에서 IoC + DI가 어떻게 구현되는가

★ “컨테이너” 개념 ★

Spring 컨테이너

• 객체(Bean)를 생성하고 관리
• 의존성 자동 주입

Bean

• Spring이 관리하는 객체

동작 흐름

• 클래스 정의
• 어노테이션으로 관계 설정
• 컨테이너가 객체 생성
• 필요한 곳에 주입

7. DI 방식 (구체화 단계)

DI를 실제 코드로 적용하는 방법

① 생성자 주입 (권장)

• 필수 의존성 보장
• 객체 생성 시 완성됨

  ② Setter 주입

• 런타임 주입
• Null 위험

  ③ 필드 주입

• 간단하지만 구조 파악 어려움
• 테스트 어려움

8. 웹 구조로 확장 → Servlet 등장

서블릿 HTTP 요청을 처리하는 자바 프로그램

흐름

1. 요청 → Servlet Container
2. Servlet 실행
3. 응답 반환

9. Spring에서의 Servlet → DispatcherServlet

Spring은 서블릿을 더 발전시킴 ** 핵심: DispatcherServlet **

모든 요청을 받는 중앙 컨트롤러 요청 → Controller로 전달 → 응답 생성

전체 흐름

Spring (프레임워크) → 제어권이 프레임워크로 이동 (IoC) → 의존성도 외부에서 관리 (DI) → 이를 컨테이너 + Bean으로 구현 → 웹에서는 Servlet으로 요청 처리 → Spring은 DispatcherServlet으로 통합 관리

개념 핵심 요약

• Spring은 프레임워크다
• 프레임워크는 제어권을 가져간다 → IoC
• 객체 관리도 외부에서 한다 → DI
• 이를 Spring 컨테이너 + Bean으로 구현
• 웹 요청은 Servlet이 처리
• Spring에서는 DispatcherServlet이 전체 흐름 제어

[부록]

이 포스팅을 시작하며 첨부한 이번주 워크북 자료 사진인데, 이번주는 부록도 있어서 부록에 해당하는 내용까지 정리해보겠습니다.

부록 ① - 스프링 해체 분석기 - Bean

1-1 핵심 흐름

Application 실행
→ ComponentScan
→ Bean 정의 수집
→ Bean 생성 (싱글톤)
→ 의존성 분석
→ DI 수행
→ ApplicationContext에 저장

1-2 주요 개념

** ApplicationContext**

• Bean을 생성 / 관리 / 조회하는 컨테이너

** Bean 생성 과정**

• 클래스 스캔
• Bean 정의 등록
• 싱글톤 객체 생성

** DI (의존성 주입)**

• 생성 시점에 자동 주입
• 타입 기반으로 Bean 탐색 후 주입

1-3 내부 동작 핵심

** AbstractAutowireCapableBeanFactory** : Bean 생성 + DI 수행 핵심 엔진

** BeanPostProcessor** : Bean 생성 후 개입하는 후처리 단계

** AutowiredAnnotationBeanPostProcessor** : @Autowired 찾아서 실제 주입 수행

1-4 핵심 정리

★ Spring은 실행 시점에 객체를 모두 생성하고, 의존성까지 연결해 둔다

부록 ② - 스프링 해체 분석기 - 전체 구조

2-1 전체 흐름

Filter → DispatcherServlet → Interceptor → Controller → 응답

2-2 단계별 흐름

1. ** Filter **

• 요청 전처리
• 서블릿 컨테이너에서 실행

2. ** DispatcherServlet **

• 모든 요청을 받는 Front Controller
• 전체 흐름 제어

3.** HandlerMapping **

• URL → Controller 매핑

4.** HandlerAdapter **

• Controller 실행 방식 결정

5.*Interceptor *

• Controller 전/후 처리
• preHandle → 실행 → postHandle → afterCompletion

6.** Controller ** Controller

• 비즈니스 로직 실행

7. ** 응답 처리 **

1)** HTML (SSR)** : ViewResolver → View 렌더링 2) JSON (REST) : HttpMessageConverter → JSON 변환

부록2 핵심 정리★★★

DispatcherServlet이 중심이 되어 요청을 적절한 Controller로 전달하고 응답을 생성한다

부록 ③ - 스프링 해체 분석기 - 필터

3-1 Filter 개념

Filter란? Servlet 전에 요청을 가로채는 객체

3-2 실행 구조

ApplicationFilterChain

→ Filter1 → Filter2 → Filter3 ...

*순차적으로 실행

3-3 동작 방식

doFilter(request, response, chain)

→ 로직 수행 → chain.doFilter()

다음 필터 호출

3-4 핵심 구성

FilterChain

• 필터들을 순서대로 실행하는 구조

ApplicationFilterChain

• 실제 필터 실행 담당
• Tomcat 내부에서 관리

주요 메서드

• init → 초기화
• doFilter → 실행
• destroy → 종료

3-5 확장 구조

• GenericFilterBean : 기본 필터 구현 클래스
• OncePerRequestFilter :요청당 1번만 실행 보장

3-6 핵심 흐름

요청 → FilterChain 실행 → 모든 Filter 통과 → Servlet 전달

부록3 핵심 정리 ★★★

Filter는 요청을 가장 먼저 처리하며, 여러 개가 체인 형태로 순차 실행된다

부록 ④ - 스프링 해체 분석기 - 서블릿 & 핸들러

4-1 시작 지점

ApplicationFilterChain
→ servlet.service(request, response)

→ 필터를 모두 통과한 요청이 서블릿으로 진입

4-2 어떤 서블릿이 처리하나?

구조:

HttpServlet → FrameworkServlet → DispatcherServlet

• DispatcherServlet이 핵심이지만
• 실제 호출은 HttpServlet부터 시작됨

4-3 HttpServlet 역할

기능

• HTTP 메서드 판단
• GET / POST / PUT / DELETE ... : 요청 메서드에 따라 분기 처리

흐름

service()
→ doGet / doPost ...

: HTTP 요청 종류 결정

4-4 FrameworkServlet 역할

기능

• ApplicationContext 기반 기능 제공
• 요청 처리 전 환경 세팅

하는 일

• Context 세팅
• 인터셉터 준비
• request/response 확장 처리

핵심 흐름

HttpServlet.service()
→ FrameworkServlet.service()
→ super.service() (다시 HttpServlet)
→ doGet/doPost 실행
→ processRequest()

: 구조상 “핑퐁” 형태로 실행됨

4-5 DispatcherServlet 진입

시작

FrameworkServlet
→ DispatcherServlet.doService()

doService 역할

• 요청 전처리
• 필요한 정보 request에 세팅
  

핵심 진입 doService() → doDispatch()

4-6 doDispatch (핵심 메서드)

: DispatcherServlet의 핵심 로직

전체 흐름

1. HandlerMapping → Handler 찾기
2. HandlerAdapter → 실행 방법 찾기
3. Interceptor preHandle
4. Handler 실행 (Controller)
5. 응답 처리
6. Interceptor postHandle / afterCompletion

4-7 HandlerMapping

역할 : 요청 → Controller 매핑

내부 동작

• MappingRegistry에서 정보 조회
• @RequestMapping 기반 매칭

4-8 HandlerAdapter

역할 : 다양한 Controller 실행을 통일

이유

Controller 구현 방식이 다양하기 때문:

• @Controller
• HttpServlet
• 인터페이스 기반 등

주요 Adapter : RequestMappingHandlerAdapter (가장 많이 사용)

내부 동작 handle() → invokeHandlerMethod() → invokeAndHandle()

4-9 Controller 실행 과정

내부 처리

• 파라미터 바인딩
• ModelAndView 준비
• 실제 메서드 호출

실행 방식 :리플렉션 + 프록시 (AOP 기반)

4-10 응답 처리

JSON 처리 흐름

HandlerMethodReturnValueHandler
→ RequestResponseBodyMethodProcessor
→ HttpMessageConverter

실제 변환 MappingJackson2HttpMessageConverter → JSON 직렬화

특징

• JSON → ModelAndView 안 거침
• 바로 응답 반환

4-11 후처리

Interceptor

postHandle
→ afterCompletion

마지막 단계

• 이벤트 발행
• 스레드 정리

3주차 워크북과 부록들은 단순히 개념을 외우는 것이 아니라, Bean 생성부터 요청 처리까지의 흐름을 한 번에 연결해서 이해할 수 있었던 주차였습니다.

앞으로는 코드 작성뿐만 아니라, 내부에서 어떤 일이 일어나는지까지 함께 생각하며 학습해보려고 합니다.

2주차 개념 요약

0주차와 1주차에서 데이터베이스 설계와 쿼리 작성을 진행했다면, 이번 2주차에서는 설계한 데이터를 실제 서비스 API로 연결하는 과정을 다루었다.

이전 주차에서 ERD를 고민하는 과정 자체가 결국 API를 큰 틀에서 설계하는 과정이었다는 점이 인상적이었다.

이번 주차의 핵심은

API Endpoint 설계 요청(Request) / 응답(Response) 데이터 설계

그리고 이 모든 내용을 문서화한 것이 바로 API 명세서이다.

API란?

API는 단순히 “클라이언트와 서버를 연결하는 것”이 아니라, 복잡한 내부 로직을 감추고, 외부에서 쉽게 사용할 수 있도록 만든 인터페이스 라는 개념으로 이해하는 것이 더 정확함.

REST API

REST는 HTTP 기반의 아키텍처로, 자원(Resource) + HTTP Method 로 API를 설계함.

HTTP Method 핵심

멱등성 (Idempotency)

→ 같은 요청을 여러 번 보내도 결과가 같아야 하는 성질

RESTful 설계 핵심 규칙

• URI에 동사 사용 ❌
• 자원은 복수형
• 계층 구조 표현 가능
• 필요 시 Path Variable 사용

API 구성 요소

핵심 키워드

#1. RESTful API란?

#2. 멱등성이란?

#3. HTTP 메서드 종류

미션과제 - API 명세서 작성

이번 주차에서는 내가 설계한 ERD를 기반으로 실제 API 명세서를 작성해봤는데

1. Home 마이데이터 조회

Endpoint GET /api/home/my

Header Authorization: Bearer {accessToken}

Response

{
  "nickname": "yujin",
  "email": "test@example.com",
  "phoneNumber": "01012345678",
  "phoneNumberStatus": 1,
  "userPoint": 12000
}

2. Home 지역 미션 조회

Endpoint GET /api/home

Query

regionName=안암동&page=0&size=10

Response

{
  "content": [
    {
      "missionId": 1,
      "marketName": "안암 분식",
      "point": 500,
      "content": "떡볶이 먹기"
    }
  ],
  "page": 0,
  "size": 10,
  "hasNext": true
}

3. 리뷰 작성

Endpoint POST /api/review

Request

{
  "marketId": 3,
  "regionId": 1,
  "stars": "FIVE",
  "content": "맛있어요!"
}

Response

{
  "reviewId": 10,
  "message": "리뷰가 작성되었습니다."
}

4. 미션 목록 조회

Endpoint GET /api/mission

Query

regionName=안암동&page=0&size=10

Response

{
  "content": [
    {
      "missionId": 3,
      "marketName": "치킨집",
      "point": 1000,
      "status": "in_progress"
    }
  ],
  "page": 0,
  "size": 10,
  "hasNext": false
}

5. 미션 완료

Endpoint

POST /api/mission/completed

Request

{
  "missionId": 12
}

Response

{
  "message": "미션이 완료되었습니다."
}

6. 회원가입

Endpoint POST /api/signup

Request

{
  "name": "홍길동",
  "gender": "FEMALE",
  "birth": "2002-05-10",
  "addressLine1": "서울",
  "addressLine2": "안암동",
  "email": "test@test.com",
  "phoneNumber": "01012345678",
  "type": "kakao",
  "agreeId": 1
}

Response

{
  "userId": 1,
  "message": "회원가입이 완료되었습니다."
}

📌 마무리

이번 2주차에서는 단순히 DB를 설계하는 것을 넘어,

★ 데이터를 어떻게 API로 노출할 것인지 ★ 프론트와 어떻게 소통할 것인지

까지 고민해보는 과정이었습니다.

또한 API 명세서를 작성하면서 단순히 기능 구현이 아니라 “다른 개발자가 이해할 수 있는 구조”로 만드는 것이 중요하다는 점을 깨달았다.

다음 3주차에서는

• Spring Boot에서 실제 API를 구현하고
• 컨트롤러와 서비스 계층을 통해
• 지금 설계한 API를 코드로 연결하는 과정을 학습하게 된다.

0주차에서 데이터베이스 구조를 설계했다면, 이번 1주차에서는 해당 ERD를 기반으로 실제 데이터를 조회하는 쿼리를 작성해보는 과정이다.

단순히 SQL 문법을 사용하는 것이 아니라, 요구사항을 어떤 쿼리로 풀어낼 수 있을지 고민하는 데에 초점을 두었다.

1주차 개념 요약

1주차에서는 0주차에 설계한 ERD를 바탕으로, 요구사항을 실제 SQL 쿼리로 어떻게 풀어낼지를 학습했다. 즉, 이번 주차의 핵심은 단순히 테이블 구조를 이해하는 것을 넘어, 필요한 데이터를 효율적으로 조회하는 방법을 익히는 데 있다.

먼저 요구사항을 보고 어떤 쿼리가 필요한지 판단하는 연습을 했다. 단순 조건 조회는 WHERE 절만으로 해결할 수 있지만, 여러 테이블의 정보가 함께 필요할 때는 JOIN 이 필요하다. 예를 들어 특정 지역의 미션을 조회하려면 미션, 가게, 지역 테이블을 연결해서 원하는 조건으로 필터링해야 한다. 이 과정을 통해 하나의 요구사항을 보고 어떤 테이블들이 연결되어야 하는지 생각하는 습관이 중요하다는 점을 배웠다.

또한 JOIN과 서브쿼리(Subquery) 의 차이도 다뤘다. JOIN은 두 개 이상의 테이블을 결합해서 한 번에 결과를 조회하는 방식이고, 서브쿼리는 쿼리 안에 또 다른 쿼리를 넣어 조건이나 결과를 만드는 방식이다. 일반적으로는 JOIN이 더 효율적인 경우가 많지만, 상황에 따라 서브쿼리가 더 직관적이고 가독성이 좋은 경우도 있다. 따라서 중요한 것은 무조건 한 가지 방식만 고집하는 것이 아니라, 가독성과 성능을 함께 고려하여 선택하는 것이다.

이번 주차에서 특히 중요한 개념은 페이징(Paging) 이다. 목록 조회 시 모든 데이터를 한 번에 가져오면 성능 문제가 발생하기 때문에, 데이터베이스에서 필요한 만큼만 잘라서 조회해야 한다. 이를 위해 LIMIT 과 OFFSET 을 사용하는 Offset 기반 페이징을 먼저 학습했다. 이 방식은 구현이 단순하고 페이지 번호로 이동하기 쉽다는 장점이 있지만, 뒤로 갈수록 성능이 떨어지고 중간에 데이터가 추가되면 중복 조회나 누락이 발생할 수 있다는 단점이 있다.

이러한 문제를 보완하기 위해 Cursor 기반 페이징도 학습했다. Cursor Paging은 마지막으로 조회한 데이터를 기준으로 다음 데이터를 가져오는 방식이다. 보통 PK처럼 고유한 값을 기준으로 삼으면 안정적으로 다음 페이지를 조회할 수 있다. 다만 별점처럼 중복 가능한 값만 커서로 사용하면 같은 결과가 반복될 수 있기 때문에, 정렬 기준 컬럼과 PK를 함께 사용해 고유한 커서를 만들어야 한다는 점이 중요하다.

정리하면 1주차는 요구사항을 SQL로 해석하는 방법, JOIN과 서브쿼리의 차이, 그리고 Offset / Cursor 기반 페이징의 원리와 차이점을 이해하는 주차였다. 결국 이번 주차를 통해, 좋은 쿼리란 단순히 동작하는 쿼리가 아니라 요구사항을 정확히 반영하면서도 성능과 확장성을 함께 고려한 쿼리라는 점을 배울 수 있었다.

핵심 키워드

#1. DB Join이란?

#2. Join 종류들

1. INNER JOIN

SELECT *
FROM table1
INNERJOIN table2
ON table1.id= table2.id;

• 두 테이블에서 조건이 일치하는 행만 반환
• MySQL에서는 다음이 동일하게 취급된다

JOIN
INNER JOIN
CROSS JOIN

2. LEFT JOIN (LEFT OUTER JOIN)

SELECT *
FROM table1
LEFTJOIN table2
ON table1.id= table2.id;

• 왼쪽 테이블 기준
• 오른쪽 테이블에 값이 없으면 NULL 반환

문서 예시도 존재

If there is no matching row for the right table in a LEFT JOIN,
a row with all columns set to NULL is used for the right table.

3. RIGHT JOIN

SELECT *
FROM table1
RIGHTJOIN table2
ON table1.id= table2.id;

• 오른쪽 테이블 기준
• MySQL 문서에서는 LEFT JOIN 사용을 권장

4. CROSS JOIN

SELECT *
FROM table1
CROSSJOIN table2;

• Cartesian Product
• 모든 행 조합 생성

문서에서도 설명

INNER JOIN and , produce a Cartesian product if no condition exists

5. NATURAL JOIN

SELECT *
FROM t1NATURALJOIN t2;

• 같은 이름의 컬럼을 자동으로 join

문서 설명

NATURAL JOIN uses all columns that exist in both tables

#3. 트랜잭션이란?

위 처럼 공식 문서엔 나와있었고,

한마디로 트랜잭션이란? 데이터를 조작하기 위한 하나의 논리적인 작업 단위를 말한다.

주요 명령어

• START TRANSACTION : 트랜잭션 시작
• COMMIT : 변경 내용 저장
• ROLLBACK : 작업 취소

출처 : 2024 유선배 SQL개발자 과외노트

#4. Join on 과 where의 차이점

미션 과제

1) 리뷰 작성하는 쿼리

0주차 과제에서 리뷰작성 관련한 table은 만들지 않았어서 해당 리뷰 작성 화면에서 필요한 data를 기준으로 review table 작성했습니다.

INSERT INTO review (
    user_id,
    market_id,
    stars,
    content,
    created_at,
    updated_at,
    deleted_at
)
VALUES (
    '닉네임1234',
    ?,
    'FIVE',
    '음 너무 맛있었어요 포인트도 얻고 맛있는 맛집도 알게 된것 같아 너무나도 행복한 식사였답니다. 다음에 또 올게요!!',
    NOW(),
    NOW(),
    NULL
);

2) 내가 진행중, 진행완료한 미션 모아보는 쿼리 (페이징포함)

쿼리를 작성하려고 보니까, 테이블 정의상 status 는 mission 테이블에 있다.

mission.status
-- in_progress / expired / challenging / participated

그런데 의미를 보면

• in_progress : 미션 자체가 게시중
• expired : 미션 자체가 만료됨
• challenging : 내가 진행중
• participated : 내가 완료함

이 중 뒤의 두 개는 유저별 상태라서 같은 미션이라도 어떤 유저는 아직 참여 안 했고, 어떤 유저는 진행 중이고, 어떤 유저는 완료했을 수 있기 때문에 participate 테이블에 있는 게 더 자연스러울거 같다는 생각이 들어서 수정했다.

SELECT
    m.id AS mission_id,
    m.content,
    m.point,
    m.end_date,
    mk.id AS market_id,
    mk.name AS market_name,
    CASE
        WHEN p.status = 'challenging' THEN '진행중'
        WHEN p.status = 'participated' THEN '진행완료'
    END AS mission_status,
    p.created_at AS participate_created_at
FROM participate p
JOIN mission m ON p.mission_id = m.id
JOIN market mk ON m.market_id = mk.id
WHERE p.user_id = ?
  AND p.status IN ('challenging', 'participated')
  AND p.deleted_at IS NULL
  AND m.deleted_at IS NULL
  AND mk.deleted_at IS NULL
ORDER BY p.created_at DESC
LIMIT 10 OFFSET 0;

3) 마이 페이지 화면 쿼리

SELECT
    name AS nickname,
    email,
    phone_number,
    phone_number_status,
    user_point
FROM user
WHERE id = 1
  AND deleted_at IS NULL;

4) 홈 화면 쿼리 (현재 선택된 지역에서 도전이 가능한 미션 목록, 페이징 포함)

SELECT
    mk.id AS market_id,
    mk.name AS market_name,
    m.point,
    m.content,
    m.end_date
FROM mission m
JOIN market mk
    ON m.market_id = mk.id
JOIN region r
    ON mk.region_id = r.id
WHERE r.name = ?
  AND m.status = 'in_progress'
  AND m.deleted_at IS NULL
  AND mk.deleted_at IS NULL
ORDER BY m.created_at DESC
LIMIT 10 OFFSET 0;

📌 마무리

이번 1주차에서는 ERD를 기반으로 요구사항을 SQL 쿼리로 풀어내는 과정을 경험했다.

특히 JOIN을 활용한 다중 테이블 조회, 서브쿼리와의 차이, 그리고 페이징 처리 방식까지 다루면서 단순 조회를 넘어서 실제 서비스에서 필요한 형태의 쿼리를 구성하는 방법을 이해할 수 있었다.

다음 주차에서는 한 단계 더 나아가, 리소스 중심의 RESTful 설계가 무엇인지 이해하고, API 명세서를 작성하는 과정을 통해 DB 설계와 쿼리를 실제 API로 연결하는 흐름을 학습할 예정이다.

이전에 SWU UMC 7기에서는 Plan 파트로 참여했으며,
졸업 전 Spring Boot를 한 번 더 정리해보고자 UMC Spring Boot로 다시 참여하게 되었습니다.

개념 정리

0주차 개념 요약

0주차에서는 데이터베이스를 어떻게 설계해야 하는지를 중심으로 학습했다. 백엔드에서 DB 설계는 단순히 테이블을 만드는 작업이 아니라, 요구사항을 데이터 구조로 바꾸는 과정이라는 점이 핵심이다.

먼저 DB와 DBMS, 그리고 RDB와 NoSQL의 차이를 짚었다. RDB는 테이블 간 관계를 기반으로 데이터를 관리하며, 중복을 줄이고 데이터 일관성과 정확성을 유지하는 데 강점이 있다. 반면 NoSQL은 대량 데이터 처리와 빠른 성능이 중요한 상황에서 주로 사용된다. 상황에 따라 SQL과 NoSQL을 함께 사용할 수도 있는데, 예를 들어 읽기 성능이 중요한 경우 Redis 같은 캐시를 추가로 도입할 수 있다.

이후 본격적으로 ERD 설계를 다루었다. ERD는 테이블, 속성, 관계, 제약조건을 시각적으로 정리한 것으로, 프로젝트 초기에 와이어프레임이나 요구사항이 나오면 이를 바탕으로 설계를 시작하게 된다. 결국 DB를 설계한다는 것은 ERD를 작성한다는 것과 거의 같은 의미로 볼 수 있다.

ERD를 작성할 때는 먼저 요구사항을 보고 어떤 데이터를 저장해야 할지 판단해야 한다. 이 과정에서 테이블명과 속성명 스타일을 통일하고, PK 이름 규칙도 일관되게 가져가는 것이 중요하다. 또 속성별로 NULL 허용 여부, 길이 제한, enum 사용 여부 같은 제약조건을 설정해야 한다. 이때 제약조건은 임의로 정하기보다 PM과 충분히 협의하며 결정하는 것이 중요하다.

추가로 Soft Delete 개념도 중요하게 다뤄졌다. *회원 탈퇴처럼 데이터를 바로 지우기보다 deleted_at 같은 값을 두어 삭제 여부만 표시하면, 복구 기능이나 탈퇴 후에도 남아야 하는 데이터 처리가 쉬워진다. *실제 서비스에서는 이런 방식이 자주 사용된다.

관계 설정에서는 특히 다대다(N:N) 관계를 어떻게 설계할지가 핵심이었다. 예를 들어 사용자-책 대여, 책-해시태그, 사용자-책 좋아요 관계는 모두 다대다 관계이므로, 이를 그대로 한 테이블에 담지 않고 중간 테이블(매핑 테이블) 을 두어 설계해야 한다. 이렇게 해야 데이터 중복을 줄이고 정규화된 구조를 유지할 수 있다.

마지막으로, ERD는 처음부터 완벽해야 하는 것이 아니라 구현 가능한 수준으로 빠르게 설계하고, 개발하면서 계속 수정해 나가는 것이 중요하다는 점도 강조되었다. 결국 좋은 설계란 이론적으로만 완벽한 설계가 아니라, 현재 요구사항을 잘 반영하면서도 이후 변경에 대응할 수 있는 설계라고 정리할 수 있다.

ERD를 작성 (예시 실습)

각 테이블 작성

설계 과정에서 고민한 부분

• 소셜 로그인 시 카카오 uid를 어떻게 저장할 것인가
• 책 좋아요 기능을 별도 테이블로 분리할 필요성
• 알림은 단순 내용보다 type 기반 설계가 필요함
• 삭제 데이터를 관리하기 위한 Soft Delete 적용

👉 특히 Soft Delete는 실제 서비스에서 매우 중요하며, 삭제 여부를 deleted_at으로 관리하는 방식이 일반적으로 사용된다.

모법 답안

핵심 키워드 정리

미션 과제 말고 직접 조사하는 과제가 있는데

주요 내용들에 대해 조사해보고, 자신만의 생각을 통해 정리해보세요!
레퍼런스를 참고하여 정의, 속성, 장단점 등을 적어주셔도 됩니다.
조사는 공식 홈페이지 Best, 블로그(최신 날짜) Not Bad

라는 멘트를 보고, 공식 문서를 보고 최대한 찾고 싶었다

#1. PK, FK 란

#2. ERD란?

#3. 연관관계란? 그리고 연간관계를 설정하는 방법은?

연관관계(Association)란 두 개 이상의 엔티티가 데이터베이스의 조인(join) 개념을 바탕으로 서로 연결되는 관계를 의미한다. 관계형 데이터베이스에서는 보통 외래 키(Foreign Key)를 통해 테이블 간 관계를 맺고, JPA에서는 이를 엔티티 간 관계로 매핑한다. 연관관계의 종류에는 @ManyToOne, @OneToMany, @OneToOne, @ManyToMany가 있다.

연관관계는 JPA에서 어노테이션을 사용해 설정할 수 있다. 예를 들어 @ManyToOne은 여러 자식 엔티티가 하나의 부모 엔티티를 참조하는 관계를 나타내며, @JoinColumn을 사용해 외래 키 컬럼을 지정할 수 있다. 또한 연관관계는 한쪽만 참조하는 단방향 관계와 양쪽이 서로 참조하는 양방향 관계로 나뉜다. 양방향 관계에서는 외래 키를 실제로 관리하는 연관관계의 주인(owning side) 이 하나만 존재하며, 보통 자식 엔티티 쪽이 주인이 된다.

#4. 정규화란?

위 처럼 공식 문서엔 나와있었고,

한마디로 정규화란? 데이터 정합성(데이터의 정확성과 일관성을 유지하고 보장)을 위해 엔터티를 작은 단위로 분리하는 과정을 말한다.

정규화를 할 경우 데이터 조회 성능은 처리조건에 따라 향상되는 경우도 있고 저하되는 경우도 있지만 입력, 수정, 삭제 성능은 일반적으로 향상된다고 볼 수 있다.

하지만 그렇다고 모든 엔터티를 무작정 분리하면 안 되기 때문에 정규화를 하기 위한 일정한 룰이 존재함 !

정규화 종류 (대표단계) - 제1정규형 - 모든 속성은 반드시 하나의 값만 가져야 한다 - 제2정규형 - 엔티티의 모든 일반 속성은 반드시 모든 주식별자에 종속되어야 한다. - 제3정규형 - 주식별자가 아닌 모든 속성 간에는 서로 종속될 수 없다.

출처 : 2024 유선배 SQL개발자 과외노트

#5. 반 정규화란?

위 처럼 공식 문서엔 나와있었고,

한마디로 반정규화란? 데이터의 조회 성능을 위해 데이터의 중복을 허용하거나 데이터를 그룹핑하는 과정을 말한다.

여기서 주의해야 할 점은 조회 성능은 향상될 수 있으나 입력, 수정, 삭제 성능은 저하될 수 있으며 데이터 정합성 이슈가 발생할 수 있다는 점이다.

반정규화의 과정은 정규화가 끝난 후 거치게 되며 정규화와 마찬가지로 일정한 룰이 존재한다

반정규화 종류 - 테이블 반정규화 - 테이블 변합, 분할, 추가 - 컬럼 반정규화 - 중복 칼럼 추가, 파생 칼럼 추가, 이력 테이블 컬럼 추가 - 관계 반정규화(중복 관계 추가) - 업무 프로세스상 JOIN이 필요한 경우가 맣아 중복 관계를 추가하는 것이 성능 측면에서 유리할 여우 고려

출처 : 2024 유선배 SQL개발자 과외노트

#6. DB에서의 상속관계 표현은 어떻게 하는가?

#7. 인덱스란?

위 처럼 공식 문서엔 나와있었고,

주요 특징으로는

• 인덱스를 통하여 레코드를 빠르게 접근할 수 있다.
• 데이터 베이스의 물리적 구조와 밀접한 관계가 있다.
• 레코드의 삽입/삭제가 자주 발생 시 인덱스의 개수를 최소화하는 것이 효율적이다.
• 하지만 인덱스가 많아질수록 INSERT, UPDATE, DELETE 성능은 저하될 수 있다.

• B 트리
  • m차 B 트리는 근노드와 단말 노드를 제외한 모든 노드가 최소 m/2개, 최대 m개의 서브 트리를 가지는 구조이다.
  • 한 노드에 있는 키 값은 오름차순을 유지한다.
  • 근노드로부터 탐색 , 추가, 삭제가 이뤄진다.

출처 : 절대족보 이기적 정보처리기사 필기 2026

week0 주차 워크북 미션

주어진 IA(기획 플로우)와 와이어 프레임(디자인 프로토타입)을 보고 직접 데이터베이스를 설계하기

데이터베이스 설계 조건은 ?!

#1. 로그인/회원가입 파트

보이는 조건들을 정리해보면

1. 로그인은 4가지 방법으로 가능함
2. 이용 약관은 5개 - 필수도 있고 선택도 있음
3. 개인정보는 이름, 성별, 생년월일, 주소1, 주소2를 받고
4. 음식 종류를 선택가능 - 16개가 주어지고 선택은 다중선택 가능

CREATE TABLE `user` (
    `id`    Long    NOT NULL,
    `name`    String(15)    NOT NULL,
    `gender`    enum    NOT NULL    COMMENT '남 : MALE, 여 : FEMALE, 선택안함 : NONE',
    `birth`    LocalDate    NOT NULL,
    `address_line_1`    String(125)    NOT NULL,
    `address_line_2`    String(125)    NOT NULL,
    `created_at`    LocalDateTime    NOT NULL,
    `updated_at`    LocalDateTime    NOT NULL,
    `deleted_at`    LocalDateTime    NOT NULL,
    `agree_id`    Long    NOT NULL,
    `type`    enum    NOT NULL    COMMENT '카카오 : kakao, 네이버 : naver,  애플 : apple, 구글 : google'
);

CREATE TABLE `agree_conditions` (
    `id`    Long    NOT NULL,
    `agree_1`    int    NOT NULL,
    `agree_2`    int    NOT NULL,
    `agree_3`    int    NOT NULL,
    `agree_4`    int    NOT NULL,
    `agree_5`    int    NOT NULL,
    `created_at`    LocalDateTime    NOT NULL,
    `updated_at`    LocalDateTime    NOT NULL,
    `deleted_at`    LocalDateTime    NOT NULL
);

CREATE TABLE `food_cartegory` (
    `id`    Long    NOT NULL,
    `name`    String(15)    NULL
);

CREATE TABLE `preference` (
    `id`    Long    NOT NULL,
    `cartegory_id`    Long    NOT NULL,
    `user_id`    Long    NOT NULL
);

#2. 홈 파트

우선, 미션 관련 테이블을 만들기 전에 상단에 보이는 포인트 내역, 알림여부에 대한 data 구조를 기존 table에서 추가했습니다.

CREATE TABLE `user` (
    `id`    Long    NOT NULL,
     ... 생략

    `user_point`    String(20)    NOT NULL,
    `alram_status`    int    NOT NULL    COMMENT '새로운 알림 있으면 : 1, 없으면 : 0'
);

CREATE TABLE `alram` (
    `id`    Long    NOT NULL,
    `Field`    LocalDateTime    NOT NULL,
    `updated_at`    LocalDateTime    NOT NULL,
    `deleted_at`    LocalDateTime    NULL,
    `user_id`    Long    NOT NULL
);

그런 다음 미션카드 데이터를 저장하기 위해 가게정보, 미션정보 그리고 기타 지역 정보 table, 참여 미션 테이블 등을 추가 했습니다.

#3. 미션 파트

다른 추가적인 데이터 입출력보다는, 3번째 page에 사장님 구분 번호 9자리에 대한걸 어떻게 처리할지 고민 해봤었다.

방법1. 미션이 생성될 때 자동 증가되며 생성되는 미션 고유 id인 값을 보여주기 방법2. 미션 고유 id를 그럼 자동증가가 아닌, 9자리 랜덤생성으로 할지 방법3. 미션 성공요청시에 생성되는 인증번호를 따로 만들지

일단 이에 대한 과제 제한 사항은 없었기 때문에, 현재는 구현 단순성을 위해 1번 방식을 선택했지만,향후에는 인증번호 기반 구조(3번)도 고려할 수 있다.

#4. 기타

남은 페이지들을 확인해보니

기존 회원 table, 알림 table, 약관 동의 table, 참여 미션 table 에 조금씩 수정한다면, 다 보여줄 수 있는 데이터들 이였다

01. 회원 table

CREATE TABLE `user` (

    ...

    // 추가 항목

    `email`    String(20)    NULL,
    `phone_number`    String(20)    NULL,
    `phone_number_status`    int    NULL    DEFAULT 0    COMMENT '인증 전 : 0, 인증 후 : 1',

    ...

);

02. 알림 table 이전 화면에서는 알림이 어떻게 표시되는지 알 수 없어서 추가하지 않았었던, 알림 table을 완성시켜봐야할거같아요

CREATE TABLE `alram` (
    `id`    Long    NOT NULL,
    `title`    String(50)    NOT NULL,
    `detail`    String(255)    NOT NULL,
    `created_at`    LocalDateTime    NOT NULL,
    `updated_at`    LocalDateTime    NOT NULL,
    `deleted_at`    LocalDateTime    NULL,
    `user_id`    Long    NOT NULL
);

03. 약관 동의 table 새로운 이벤트 수신, 리뷰 답변 알림, 문의 내역 답변 알림 3개에 대한 알림 수신 설정을 할 수 있음

04. 참여 미션 table 참여 미션 또한 생성시간이 있어야하고, ui에서도 참여 완료 시간이 찍혀야하기 때문에 꼭 필요한 것을 알 수 있음

CREATE TABLE `participate` (
    ...

    // 추가 항목
    `created_at`    LocalDateTime    NOT NULL,
    `updated_at`    LocalDateTime    NOT NULL,
    `deleted_at`    LocalDateTime    NULL,
    ...
);

미션 최종 ERD

📌 마무리

0주차에서는 단순한 DB 구조 설계가 아니라,
요구사항을 기반으로 데이터를 어떻게 구조화할 것인지에 대해 고민하는 과정이었습니다.

특히,

• N:N 관계를 중간 테이블로 분리하는 것
• Soft Delete를 고려한 설계
• 확장성을 고려한 컬럼 설계

이 세 가지가 핵심 포인트였다.

다음 주차에서는 이렇게 설계한 ERD를 기반으로
실제 데이터를 조회하는 쿼리를 작성해보며,
DB 설계가 어떻게 실제 기능으로 이어지는지 학습할 예정입니다.

1. 조건부 렌더링 (Conditional Rendering)

조건부 렌더링은 특정 조건에 따라 서로 다른 UI를 보여주는 방식이다. React에서는 JSX 내부에서 조건을 활용해 화면을 제어한다.

❶ if문을 사용한 조건부 렌더링

: 가장 기본적인 방식은 if문을 사용해 return 값을 분기하는 것이다.

if (isLogin){
  return <Logout />
}
return <Login />

• 조건에 따라 완전히 다른 컴포넌트를 렌더링 할 때 적합
• JSX 내부가 아니라 함수 상단에서 분기
  

❷ 삼항 연산자 (? :)

: JSX 내부에서 가장 많이 사용하는 방식

{isLogin ? <Logout /> : <Login />}

특징 :

• JSX 안에서 바로 사용 가능
• 간결하지만 복잡해지면 가독성 저하
  

❸ AND 연산자 (&&)

: 조건이 true일 때만 렌더링

{isLogin && <Logout />}

특징 :

• false일 경우 아무것도 렌더링되지 않음
• "조건이 참일 때만 보여주기"에 적합
  

❹ 변수에 조건 결과 저장

: 조건 결과를 변수에 저장 후 JSX에서 사용

let message
if (isLogin) {
  message = "환영합니다"
} else {
  message = "로그인해주세요"
}

return <p>{message}</p>

→ 복잡한 조건일 때 가독성 향상

❺ 조건에 따른 클래스명 적용

<div className={isActive ? "active" : "inactive"} />

또는

<div className={isActive && "active"} />

→ 스타일 제어에 매우 자주 사용됨

⭐️ 조건부 렌더링 핵심 정리

• 조건은 state 또는 props 기반으로 결정된다.
• JSX 내부에서는 삼항, && 연산자 사용.
• 복잡하면 변수 분리.
• UI 제어는 결국 "상태 기반 분기" 이다.
  

2. 반복 렌더링 (List Rendering)

배열 데이터를 기반으로 여러 요소를 반복해서 출력하는 방식이다.

❶ map() 메서드 사용

: React에서 가장 표준적인 반복 렌더링 방식

{items.map((item, index) => (
  <li key={index}>{item}</li>
))}

특징:

• 배열을 JSX 배열로 변환
• 가장 권장되는 방법
  

❷ key의 중요성

: 반복 렌더링 시 반드시 key 속성 필요

<li key={item.id}>{item.name}</li>

이유 :

• React가 요소를 구분하기 위해 필요
• 효율적인 리렌더링을 위해 사용
• index는 최후의 수단
  

❸ for문 사용

for (let i=0; i<items.length; i++) {
  elements.push(<li key={i}>{items[i]}</li>)
}

• 가능은 하지만 JSX 문법상 map보다 불편
• 실무에서는 거의 map 사용
  

❹ forEach는 사용하지 않음

forEach는 값을 반환하지 않기 때문에 직접 JSX로 사용 불가 → 별도 배열에 push 후 렌더링해야 함

❺ reduce 사용

items.reduce((acc, item) => {
  acc.push(<li key={item}>{item}</li>)
  return acc
}, [])

• 가능하지만 가독성 측면에서 map이 더 적합

3. 조건부 + 반복 렌더링 조합

{itens.length > 0 ? (
  items.map(item => <li key={item.id}>{item.name}</li>)
) : (
  <p>데이터가 없습니다</p>
)}

또는

{items.length === 0 && <p>데이터가 없습니다</p>}

→ 실제 프로젝트에서 매우 자주 사용

7장 전체 핵심 요약

1. 조건부 렌더링은 상태 기반 UI 제어 방식이다.
2. 삼항 연산자와 && 연산자가 가장 많이 사용된다.
3. 반복 렌더링은 map이 표준 방식이다.
4. key는 필수이며, 고유값을 사용하는 것이 가장 좋다.
5. 조건과 반복은 항상 함께 사용된다.

4장에서 상태(state)의 개념을 이해했다면, 7장에서는 그 상태를 기반으로 화면을 어떻게 제어할 것인지를 배우는 단계였습니다.

이제 개념 정리는 마쳤으니, 다음 글에서는 이를 실제로 적용한 3주차 과제 카운터 앱과 리스트 앱 구현 과정을 정리해보겠습니다.

오늘은 3주차 스터디 범위인 4장과 7장 중, 먼저 4장 ‘컴포넌트 상태’ 에 대한 개념 정리를 해보려고 합니다.

4장. 컴포넌트 상태 리액트 애플리케이션이 단순한 정적 페이지를 넘어 동적으로 변화하는 UI를 제공 할 수 있는 이유는 바로 상태 관리 덕분입니다.

이 장에서는 리액트에서 컴포넌트의 상태를 어떻게 정의하고, 어떻게 변경하며, 왜 상태로 관리해야 하는지를 살펴봅니다.

🅠 변수로 데이터를 관리하면 왜 문제가 생길까?

리액트 컴포넌트에서 데이터를 정의하는 가장 간단한 방법은 자바스크립트의 let이나 const 키워드를 사용하는 것입니다.

export default function App(){
  let name = '철수';
  const age = 20; 

  return (
    <div>
      <p>{name}</p>
      <p>{age}</p>
    </div>
  );
}

이 코드는 정상적으로 화면에 값을 출력합니다.

하지만 다음과 같이 값을 변경해보면 문제가 발생합니다.

export default function App(){
  let name = '철수';
  const age = 20;

  const nameChange = () => {
    name = '영희';
    console.log(name);
  };

  return (
    <div>
      <p>{name}</p>
      <p>{age}</p>
      <button onClick={nameChange}>이름 변경</button>
    </div>
  );
}

버튼을 클릭하면 콘솔에는 "영희"가 출력됩니다. 하지만 화면에는 여전히 "철수"가 표시됩니다. 왜 이런 일이 발생할까요?

리액트는 일반 변수의 변경을 감지하지 못하기 때문입니다.

즉, let이나 const로 선언한 변수는 값이 바뀌어도컴포넌트가 다시 렌더링되지 않습니다.

🅐 그래서 등장한 개념, 상태(state)

리액트에서는 화면에 영향을 주는 데이터는 단순한 변수가 아니라 상태(state) 로 관리해야 합니다.

컴포넌트의 상태란,

컴포넌트 내부에서 관리되는 데이터로, 사용자와의 상호작용에 따라 변경될 수 있는 값

을 의미합니다.

상태가 변경되면 리액트는 해당 컴포넌트를 자동으로 리렌더링합니다. 이 덕분에 UI가 실제 데이터 변화와 동기화됩니다.

1. 컴포넌트의 상태란?

• 리액트에서 상태(state)는 시간으니 흐름에 따라 변경되는 데이터이다.
• 일반 변수(let 등)는 값이 바뀌어도 리렌더링이 발생하지 않는다.
• 화면에 반영되어야 하는 값은 반드시 상태로 관리해야 한다.
• 상태가 변경되면 리액트는 해당 컴포넌트를 자동으로 다시 렌더링한다.
• 리렌더링은 변경된 부분만 효율적으로 반영된다.

핵심 : 화면에 영향을 주는 데이터는 상태로 관리한다.

2. userState 훅 (기본 상태 관리)

❶ userState 기본 구조

const [state, setState] = useState<Type>(initialState);

• state : 현재 상태 값
• setState : 상태 변경 함수
• <Type> : useState 훅으로 정의할 상태 값의 타입을 제네릭으로 지정 (생략가능)
• initialState : 초기값 특징 :
• 배열 구조 분해 할당 사용
• setState 호출 시 리렌더링 발생

❷ 상태 변경 방법

(1) 값 직접 변경

setCount(count + 1);

(2) 함수형 업데이트 (이전 값 기반)

setCount(prev => prev + 1);

→ 연속 호출, 비동기 업데이트 상황에서는 함수형 업데이트 권장

❸ useState 동작 흐름

1. useState로 상태 선언
2. 이벤트 발생
3. setState 호출
4. 상태 변경
5. 컴포넌트 재렌더링

❹ 여러개의 상태 관리

const [name, setName] = useState('');
const [age, setAge] = useState(0);

• 상태는 여러 개 선언 가능
• 각 상태는 독립적으로 관리 됨

❺ 초기값과 타입

• 초기값이 null 인 경우 타입 명시 필요 (TypeScript)
• 숫자, 문자열, 객체 등 다양한 타입 가능

  const [user, setUser] = useState<User | null>(null);

3. 상태 관리 시 주의사항

❶ 상태는 직접 변경하지 않는다

count = count + 1  ❌
setCount(count + 1)  ✅

❷ 여러번 setState 호출 시 주의

setCount(count + 1);
setCount(count + 1);

→ 기대값과 다를 수 있음 → 함수형 업데이트 사용 권장

❸ 리액트 훅 사용 규칙

• 컴포넌트 최상단에서만 호출 조건문, 반복문 내부에서 호출 금지

4. 상태 끌어올리기 (State Lifting)

• 여러 컴포넌트가 동일 상태를 공유해야 할 경우
• 공통 부모 컴포넌트로 상태를 이동

  App
  ├─ CountDisplay
  └─ CountButtons

• 상태는 부모(App)에 위치
• props로 하위 컴포넌트에 전달

핵심 : 상태는 가장 가까운 공통 부모에 둔다

5. 상태 관리 패턴

❶ 상태와 변경 함수를 함께 props로 전달

<Child count={count} setCount={setCount} />

❷ 변경 로직을 부모에서 정의 후 함수만 전달

const increment = () => setCount(count + 1);
<Child increment={increment} />

→ 책임 분리 측면에서 더 권장되는 방식

6. useReducer (상태 로직이 복잡할 때)

기본 구조 :

const [state, dispatch] = useReducer(reducer, initialState);

구성요소 :

• state : 현재 상태
• dispatch : 액션 전달 함수
• reducer : 상태 변경 로직 함수
• initialState : 초기 상태

특징 :

• 상태 변경 로직을 한 곳에 모아 관리
• 복잡한 상태 구조에 적합
• 액션 기반 업데이트

7. 리액트 개발자 도구

• Components 탭 → props, state 확인
• Profiler → 렌더링 성능 분석
• 어떤 컴포넌트가 왜 렌더링 되는지 추적 가능

4장 핵심 정리

• 화면에 영향을 주는 값은 상태로 관리한다.
• 상태 변경은 setState를 통해 이루어진다.
• 상태는 공통 부모에 위치시킨다.
• 복잡한 상태는 useReducer를 사용한다.
• 리렌더링은 상태 변경에 의해 발생한다

이번 글에서는 4장의 핵심 개념을 정리해보았습니다. 다음 글에서는 7장 조건부 렌더링과 반복 렌더링을 정리하고, 이후 3주차 과제 구현까지 이어서 기록해보겠습니다.

컴포넌트

컴포넌트는 UI를 구성하는 독립적이고 재사용 가능한 단위입니다. 리액트는 이러한 컴포넌트를 조합하여 하나의 애플리케이션을 완성합니다.

예를 들어 하나의 웹 페이지는 다음과 같이 나눌 수 있습니다.

• header : 로고, 네비게이션 바
• nav : 웹사이트 메뉴
• article : 주요 콘텐츠
• section : 세부 콘텐츠
• aside : 광고, 추가 정보
• footer : 저작권 정보, 연락처

추상화(abstraction)

위 사진처럼 웹 페이지를 기능 단위로 나누는 과정을 추상화라고 합니다. 추상화는 복잡한 구조를 단순하게 표현함으로써 전체 시스템을 더 명확하게 이해하고 관리할 수 있도록 해줍니다

컴포넌트 예시

Header 컴포넌트

//Header 컴포넌트 : 로고와 내비게이션 바
function Header(){
    return(
        <header>
         <h1>My Website</h1>
         <Nav />
        </header>

    );
}

Navigation 컴포넌트

//Navigation 컴포넌트 : 웹 사이트 메뉴

function Nav(){
    return(
        <nav>Home | About | Services | Contact</Nav>
    );
}

Article 컴포넌트

// Article 컴포넌트: 주요 콘텐츠

function Article(){
  return( 
    <article>
      <h2> Main Article</h2)\>
    </article>
  );
}

Section 컴포넌트

// Section 컴포넌트: 세부 콘텐츠

function Article(){
  return( 
    <section>
      <h3>More Details(/h3)
    </section>
);
}

Aside 컴포넌트

// Aside 컴포넌트: 광고, 추가 정보

function Aside() ({
    return( 
      <aside>
        <h3>Related Links</h3>
      </aside>
    );
}

Footer 컴포넌트

// Footer 컴포넌트: 저작권 정보, 연락처

function Footer() { 
    return ( 
      <footer>
        <p>©2025 My Website. All rights reserved.</p> 
      </footer>
    );
}

App 컴포넌트

// App 컴포넌트: 모든 컴포넌트를 조합해 전체 페이지 구성

function App() {
    return ( 
      <div>
        <Header/>
          <Article/>
          <Aside/>
        <Footer/>
      </div>
    );
}

컴포넌트 단위로 구성했을 때의 이점

1. 재사용 가능 한 번 만든 컴포넌트는 여러 곳에서 반복적으로 사용할 수 있습니다. 예를 들어 Header와 Footer는 대부분의 페이지에서 공통으로 사용됩니다.
   
2. 유지보수 용이 컴포넌트를 작은 단위로 나누면 문제가 발생했을 때 어디에서 오류가 발생했는지 빠르게 파악할 수 있습니다. 또한 수정 시 다른 부분에 영향을 최소화할 수 있습니다.
   
3. 로직 분리 가능 UI와 비즈니스 로직을 분리할 수 있습니다. 화면을 담당하는 컴포넌트와 데이터를 처리하는 로직을 구분하면

가독성과 유지보수성이 향상됩니다.
4. 복잡한 상태 관리 가능 컴포넌트를 세분화하면 상태 변경 시 필요한 부분만 리렌더링되어 불필요한 렌더링을 줄일 수 있습니다.

plus

컴포넌트는'너무 세분화하면 관리가 어렵고, 너무 뭉뚱그리면 재사용성과 유지보수성이 떨어진다' 는 점입니다. 따라서 목적에 맞게 적절한 수준으로 나누는 것이 가장 중요합니다.

여기까지가 컴포넌트에 대한 기초 이론 정리였고

2주차 과제

✔ 요구사항

1. 버튼 클릭 로직은 부모 컴포넌트에서 관리
2. 버튼 텍스트와 클릭 이벤트는 props로 전달
3. +1 → count 증가
4. -1 → count 감소
5. Reset → count 0 초기화
6. Alert → 현재 count 값 출력
7. 공통 Button 컴포넌트 생성

해당 과제 해결 과정을 보여드리려 합니다

🛠 구현 과정

Step 1. 폴더 구조 설계

src
 ├── components
 │     └── Button.tsx
 │
 ├── App.tsx
 └── main.tsx

• components/ : 재사용 가능한 UI 컴포넌트
• App.tsx : 상태 및 로직 관리
  

이처럼 파일 구성 했고,

Step 2. 코드 작성

// components/Button.tsx 코드
type ButtonProps = {
    text: string
    onClick: () => void
  }

  function Button({ text, onClick }: ButtonProps) {
    return <button onClick={onClick}>{text}</button>
  }

  export default Button

• 버튼 UI 담당
• props로 값과 함수 전달받음

// app.tsx 코드
import { useState } from "react"
import Button from "./components/Button"

function App() {
  const [count, setCount] = useState(0)

  const handleIncrease = () => setCount(count + 1)
  const handleDecrease = () => setCount(count - 1)
  const handleReset = () => setCount(0)
  const handleAlert = () => alert(count)

  return (
    <div>
      <h1>Count: {count}</h1>

      <Button text="+1" onClick={handleIncrease} />
      <Button text="-1" onClick={handleDecrease} />
      <Button text="Reset" onClick={handleReset} />
      <Button text="Alert" onClick={handleAlert} />
    </div>
  )
}

export default App

코드는 이렇게 완성한 후 실행시켜보니

과제 조건에 전부 만족하는 화면과 기능이 나왔습니다. 이번 과제를 통해 개념을 직접 코드로 구현해볼 수 있었습니다.

컴포넌트는 단순히 화면을 나누는 것이 아니라, 역할을 나누는 설계 방식이라는 점을 이해하게 되었습니다.

JSX란

JSX는 JavaScript XML의 약자로, 자바스크립트 코드 안에서 HTML과 유사한 문법으로 UI를 작성할 수 있게 해주는 문법 확장이다.

JSX는 브라우저가 직접 이해하는 문법이 아니라, 빌드 과정에서 일반 자바스크립트 코드(React.createElement)로 변환되어 실행된다.

예시:

const element = <h1>Hello, React!</h1>

React.createElement('h1', null, 'Hello, React!')

JSX의 문법적 특징

JSX는 HTML과 문법이 매우 유사하기 때문에 처음 접하는 사람도 어렵지 않게 사용 할 수 있습니다. 하지만 HTML과는 조금 다른 JSX만의 규칙이 몇 가지 존재합니다.

[1] 하나의 루트 요소로 반환하기 JSX에서 작성하는 컴포넌트는 반드시 하나의 루트 요소만 반환해야 합니다. 여러 요소를 반환하려면 하나의 부모 요소로 감싸거나 Fragment를 사용해야합니다 컴포넌트는 반드시 하나의 루트 요소만 반환해야 한다.

// 잘못된 예
return (
  <h1>Hello</h1>
  <p>React</p>
)


// 올바른 예시 1 - 부모 요소로 감싸기
return (
  <div>
    <h1>Hello</h1>
    <p>React</p>
  </div>
)


// 올바른 예시 2- 부모 요소로 감싸기
return (
  <>
    <h1>Hello</h1>
    <p>React</p>
  </>
)

[2] 모든 태그 닫기 HTML에서는 빈 태그를 닫지 않아도 되지만, JSX에서는 모든 태그를 반드시 닫아야 합니다.

// 잘못된 예시
<img src="logo.png">


// 올바른 예시
<img src="logo.png" />

[3] 태그 속성은 카멜 케이스로 작성하기 JSX에서는 HTML 속성명을 카멜 케이스로 작성해야 합니다. class나 for처럼 자바스크립트 예약어와 충돌하는 속성은 className, htmlFor와 같이 다른 이름으로 대체합니다

// 잘못된 예시
<div class="box"></div>
<label for="name">이름</label>

// 올바른 예시
<div className="box"></div>
<label htmlFor="name">이름</label>

이유: class, for는 JavaScript 예약어이기 때문.

[4]표현식은 중괄호 안에서 사용하기 JSX 내부에서는 {} 안에 자바스크립트 표현식을 사용할 수 있음

const name = "Yujin"
return <h1>Hello, {name}</h1>

*연산도 가능함

return <p>{1 + 2}</p>

단, if문이나 for문은 직접 사용할 수 없다.(표현식만 가능)

[5] 인라인 스타일은 객체로 지정하기 HTML에서는 style 속성을 문자열로 스타일을 지정하지만, JSX에서는 자바스크립트 객체로 지정합니다.

// html
<div style="color: red;"></div>

// JSX
<div style={{ color: 'red' }}></div>

<div style={{ backgroundColor: 'black' }}></div>
<br>

1) style 값은 객체, 2) 속성명은 카멜 케이스

[6] 주석은 중괄호 안에 작성하기 JSX 내부에서는 중괄호 안에서 작성해야 함

return (
  <div>
    {/* 이 부분은 주석입니다 */}
    <h1>Hello</h1>
  </div>
)

JSX는 HTML과 매우 유사하지만, 실제로는** 자바스크립트 위에서 동작하는 문법 확장** 이다.

HTML과의 차이점을 정확히 이해하는 것이 리액트 컴포넌트를 작성하는 첫 단계라고 느꼈다.

웹 서비스를 처음부터 끝까지 구현하려면 프론트엔드 역량도 필요하다고 느꼈고, 그 시작으로 React를 공부하기로 결심 했다.

복학 전 한 학기 동안 집중적으로 학습하기 위해 소학회 프론트엔드(React) 파트에 지원했다.

소학회에서 시작부터 8주간은 스터디를 진행하는데 이번 기수는 해당 교재를 기반으로 스터디를 진행하며, 8주간의 학습 내용을 기록해보려 한다.

Node.js 설치 여부 확인

Vite를 사용하려면 Node.js가 필요하므로, 터미널에서 아래 명령어로 설치 여부를 확인했습니다.

% node -v
% npm -v

• node -v : Node.js 버전 확인
• npm -v : npm(Node Package Manager) 버전 확인

Vite로 리액트 프로젝트 생성

그럼 이제, 프로젝트를 생성해 보겠습니다

% npm create vite@latest

프로젝트 생성 시 교재와 동일하게 React + TypeScript 템플릿을 선택했다.

리액트 프로젝트 실행

% npm run dev로 프로젝트 실행하기

처음 실행하면, 기본 실행화면이 이렇게 뜰 겁니당

생성한 프로젝트의 구조

Vite로 프로젝트를 생성하면 아래 그림처럼 기본 폴더와 파일 구조가 자동으로 생성됩니다

Tip : scaffolding

Vite와 같은 도구를 사용해 프로젝트의 기본 구조와 설정 파일을 자동으로 생성하는 과정을 스캐폴딩(scaffolding) 이라고 합니다. 이를 통해 복잡한 환경 설정을 직접 하지 않고도 명령어 한 줄로 리액트 애플리케이션의 기본 틀을 빠르게 만들 수 있습니다.

test : Hello, React! 띄우기

src/main.tsx랑 src/App.tsx를 아래처럼 수정하면

// src/main.tsx

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
// import './index.css' 
import App from './App.tsx'

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <App />
  </StrictMode>,
)

// src/App.tsx

export default function App(){
  return (
    <div> Hello, React!</div>
  )
}

성공입니당 🎉

React 기본 실행 흐름

1. npm run dev 실행
2. Vite가 index.html을 로드
3. index.html이 main.tsx를 불러옴
4. main.tsx가 App.tsx를 렌더링
5. 화면에 React 컴포넌트가 출력

React 기본 구조

프로젝트에 있는 여러 폴더와 파일 중에서 애플리케이션을 실행하는 데 특히 중요한 파일은 package.json, index.html, main.tsx , App.tsx

package.json package.json 파일은 프로젝트의 핵심 설정파일

index.html 터미널에서 npm run dev 명령어를 입력해 개발 서버를 실행하면 Vite 개발 서버는 내부적으로 index.html 파일을 자동으로 로드합니다. 이 파일 안에는 리액트 애플리케이션을 실행하는 데 필요한 최소한의 HTML 구조가 들어 있음

main.tsx index.html 파일에서 <script src="/src/main.tsx">로 main.tsx 파일을 불러오면 그때부터 리액트 코드가 실행됨 main.tsx 파일은 리액트 애플리케이션을 초기화하고 구성하는 역할을 함

App.tsx 리액트 파일 중 첫 글자가 대문자로 시작하고 확장자가 .tsx나 .jsx인 파일을 컴포넌트라고 합니다. 일반적으로 확장자 앞에 붙은 이름을 사용해 해당 컴포넌트 파일을 저장합니다. 예를들어 App.tsx 파일은 App 컴포넌트라고 합니다

소학회 1주차 과제

• Vite로 리액트 프로젝트 생성,
• JSX로 간단 자기소개 페이지 구현

function Profile() {
  return (
    <section>
      <h1>자기소개</h1>
      <p>안녕하세요 저는 소프트웨어융합학과 22학번 정유진입니다</p>
    </section>
  )
}

type InfoProps = {
  label: string
  value: string
}

function Info({ label, value }: InfoProps) {
  return (
    <p>
      <strong>{label}</strong>: {value}
    </p>
  )
}

function Skills() {
  const skills = ['Java', 'Springboot','Python','React','Javascript', 'TypeScript']

  return (
    <ul>
      {skills.map(skill => (
        <li key={skill}>{skill}</li>
      ))}
    </ul>
  )
}

export default function App() {

  return (
    <main>
      <Profile />

      <Info label="관심 분야" value="Frontend / Backend" />
      <Info label="학습 도구" value="Vite + React / springboot" />

      <h4>기술 스택</h4>
      <Skills />

    </main>
  )
}

코드 설명

App 컴포넌트는 최상위 컴포넌트이고,

• Profile 컴포넌트로 기본 소개를 보여주고
• Info 컴포넌트를 여러 번 사용해 정보 영역을 구성하고
• Skills 컴포넌트로 기술 스택을 출력했습니다. → 3개의 하위 컴포넌트

[1] Profile 컴포넌트 - 정적인 UI : 자기소개 제목과 간단한 소개 문장을 담당합니다.

• section 태그로 하나의 루트 요소를 유지했고
• JSX 기본 규칙에 맞게 단일 루트로 반환

[2] Info 컴포넌트 + props 설명

Info 컴포넌트는

• label과 value를 props로 받아서 같은 형태의 정보를 재사용할 수 있도록
• InfoProps 타입을 정의해서 props의 타입을 명확히 지정

→ 관심 분야, 학습 도구 같은 정보를 같은 컴포넌트로 반복해서 렌더링 가능

[3] Skills 컴포넌트 : 배열 데이터를 JSX에서 렌더링하는 방식을 사용

• skills 배열을 선언하고
• map 함수를 이용해 <li> 목록으로 변환
• JSX 안에서 JavaScript 표현식을 사용하기 때문에 중괄호 {}를 사용했습니다.
• 또한 리스트 렌더링 시 key 속성을 지정해야 한다는 JSX 규칙에 따라 각 li에 key를 추가했습니다.

*_ key는 React가 변경된 요소를 효율적으로 추적하기 위해 사용하는 고유 식별자이다._

여기까지 1장 끝났고, 2장.JSX개요 까지 1주차 스터디라 다음 편에서 2장 개념 정리 진행하겠습니다

그래서 끝나지 않은 카카오 소셜 로그인 개발 ㅜㅜ

🔥 문제 상황 OAuth2 기반 소셜 로그인이라서, 카카오에서 로그인 성공하면 access token을 하나 주는데, Authorization: Bearer {카카오 access token}

*❌ 우리 서버는 이걸 이해 못 함. * 왜냐면 우리는 내부적으로 JWT 기반 인증 방식을 사용하고 있었고, 카카오 access token은 우리 시스템의 JWT가 아니기 때문!!....

✨ 해결 방법

1. kakaoLogin(code) 호출 후 2. 우리 JWT 발급 ⭐️ ⭐️ ⭐️ 사용자 정보 기반으로 → access token + refresh token 생성 → LoginResponseDto에 담아서 클라이언트에 응답

하나의 LoginResponseDto로 합치기

@Data
@Getter
@AllArgsConstructor
public class LoginResponseDto {
    private String message;
    private String accessToken;
    private String refreshToken;
    private Long userId;
}

컨트롤러도 해당 Dto 사용하도록 변경

@RestController
@RequestMapping("/oauth")
@RequiredArgsConstructor
public class OAuthController {

    private final KakaoOAuthService kakaoOAuthService;

    @GetMapping("/kakao/callback")
    public ResponseEntity<LoginResponseDto> kakaoCallback(@RequestParam String code) {
        LoginResponseDto loginResponse = kakaoOAuthService.kakaoLogin(code);
        return ResponseEntity.ok(loginResponse);
    }
}

KakaoAuthService.java 일부

public LoginResponseDto kakaoLogin(String code) {
        String kakaoAccessToken = getKakaoAccessToken(code);

        HttpHeaders headers = new HttpHeaders();
        headers.setBearerAuth(kakaoAccessToken);
        headers.setContentType(MediaType.APPLICATION_JSON);
        HttpEntity<?> request = new HttpEntity<>(headers);

        ResponseEntity<String> response = restTemplate.exchange(
                "https://kapi.kakao.com/v2/user/me",
                HttpMethod.GET,
                request,
                String.class
        );

        try {
            ObjectMapper objectMapper = new ObjectMapper();
            JsonNode root = objectMapper.readTree(response.getBody());

            String kakaoId = root.path("id").asText();
            String nickname = root.path("properties").path("nickname").asText();
            String email = root.path("kakao_account").path("email").asText(null);

            Optional<User> optionalUser = userRepository.findByUsername(kakaoId);

            User user = optionalUser.orElseGet(() -> {
                User newUser = new User();
                newUser.setUsername(kakaoId);;
                newUser.setNickname(nickname);
                newUser.setPassword("");
                newUser.setType(UserType.PER);
                newUser.setProvider("kakao");
                return userRepository.save(newUser);
            });

            // JWT 토큰 생성
            String accessToken = jwtUtil.generateAccessToken(user);
            String refreshToken = jwtUtil.generateRefreshToken(user);

            String message = "카카오 로그인 성공";
            return new LoginResponseDto(message, accessToken, refreshToken, user.getId());

        } catch (Exception e) {
            throw new RuntimeException("카카오 사용자 정보 파싱 실패", e);
        }
    }

결과를 보면

일반 로그인

카카오 로그인 결과

이제 소셜 로그인도 로컬 로그인과 똑같이 JWT 기반 인증으로 통일 성공 ! 다음엔 까먹지 않고 한번에 jwt까지 개발하도록 ^^

카카오 소셜로그인 구현 진행 순서

1. 카카오 개발자 사이트 가입 & 앱 생성

: 내 앱 만들고, REST API 키랑 Redirect URI(로컬 주소 포함) 등록하기 (예: http://localhost:8080/oauth/kakao/callback)

2. Spring Boot에 카카오 OAuth 연동 라이브러리 세팅

: 스프링 시큐리티 + OAuth2 클라이언트 의존성 추가 : application.yml에 카카오 클라이언트 ID, 시크릿, 리다이렉트 URI 설정

3. OAuth2 로그인 설정 (SecurityConfig에 등록)

: 카카오 로그인 URL 및 콜백 처리 설정 : 토큰 받아서 사용자 정보 조회, 회원가입 또는 로그인 처리

4. 테스트

: 로컬에서 http://localhost:8080/login-kakao 같은 URL 만들어서 테스트 : 로그인이 성공하면 JWT 토큰 발급하거나 세션 생성

🔹 카카오 개발자 사이트 가입 & 앱 생성

1. https://developers.kakao.com/ 이 사이트에서 앱 생성

2. 기본으로 제공해주는 정보 동의 설정

*추가적인 정보도 받아올수있지만, 일단 가장 간단한 방법으로 구현해두려 함

3. RedirectURI 등록

사용설정을 on 해주면 리다이렉트 URI를 등록할 수 있게 된다 http://localhost:8080/hackathon/api/oauth/kakao/callback 로 설정

4. 의존성 확인

implementation 'org.springframework.boot:spring-boot-starter-web'
implementation 'org.springframework.boot:spring-boot-starter-security'
implementation 'com.fasterxml.jackson.core:jackson-databind'

5. REST API 키 복사해두기

이 경로에 있으니 번거롭지 않게 하려면 복사해두는걸 추천합니다 .!

6. application.yml에 추가

kakao:
  client-id: ${OAUTH_KAKAO_CLIENT_ID}
  redirect-uri: ${OAUTH_KAKAO_REDIRECT_URI}

7. [프론트] 로그인 버튼에서 카카오 로그인 페이지로 리다이렉트

예시 리다이렉트 주소 https://kauth.kakao.com/oauth/authorize?client_id=7b56421a48b08f9dc4dd3e9f246b3a54&redirect_uri=http://localhost:8080/hackathon/api/oauth/kakao/callback&response_type=code

8. [백엔드] 카카오에서 authorization code 받기

@GetMapping("/kakao/callback")
public ResponseEntity<?> kakaoCallback(@RequestParam String code) {
    // code를 access token으로 바꾸고
    // 사용자 정보 요청해서 처리
}

9. 카카오 AccessToken 요청 & 사용자 정보 요청

public String getKakaoAccessToken(String code) {
        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);

        MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
        params.add("grant_type", "authorization_code");
        params.add("client_id", clientId);
        params.add("redirect_uri", redirectUri);
        params.add("code", code);

        HttpEntity<MultiValueMap<String, String>> request = new HttpEntity<>(params, headers);

        ResponseEntity<String> response = restTemplate.postForEntity(tokenUri, request, String.class);

        try {
            ObjectMapper objectMapper = new ObjectMapper();
            JsonNode root = objectMapper.readTree(response.getBody());
            return root.path("access_token").asText();
        } catch (Exception e) {
            throw new RuntimeException("카카오 Access Token 파싱 실패", e);
        }
    }

10. 받은 토큰으로 사용자 정보 조회

HttpHeaders headers = new HttpHeaders();
headers.setBearerAuth(accessToken);
headers.setContentType(MediaType.APPLICATION_JSON);
HttpEntity<?> request = new HttpEntity<>(headers);

ResponseEntity<String> response = restTemplate.exchange(
        "https://kapi.kakao.com/v2/user/me",
        HttpMethod.GET,
        request,
        String.class
);

11. 사용자 정보(json)에서 ID (or email) 추출 후 DB에 회원이 있으면 로그인, 없으면 자동 회원가입

try {
   ObjectMapper objectMapper = new ObjectMapper();
   JsonNode root = objectMapper.readTree(response.getBody());

   String kakaoId = root.path("id").asText();
   String nickname = root.path("properties").path("nickname").asText();
   String email = root.path("kakao_account").path("email").asText(null);

   Optional<User> optionalUser = userRepository.findByUsername(kakaoId);

   User user = optionalUser.orElseGet(() -> {
   User newUser = new User();
   newUser.setUsername(kakaoId); // ID를 username으로
   newUser.setPassword("");
   newUser.setProvider("kakao");
   newUser.setEmail(email); // 추가 가능
   return userRepository.save(newUser);
   });

   return new KakaoUserDto(email, nickname, accessToken);

} 

12. JWT 발급해서 클라이언트에 전달

@Getter
@AllArgsConstructor
public class KakaoUserDto {
    private String email;
    private String nickname;
    private String accessToken;
}

1. 의존성 추가하기

// swagger-ui
implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.2.0'

2. application.yml

springdoc:
  api-docs:
    path: /api-docs
  swagger-ui:
    path: /swagger-ui

3. 접속해보기

http://localhost:8080/hackathon/api/swagger-ui/index.html#/

참고 저는 기본 url을 /hackathon/api/ 여기까지 해놨었습니다

4. 필요시 Controller에 어노테이션 추가

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

    @GetMapping("/login")
    @Operation(summary = "로그인", description = "로그인 성공시 토큰반환")
    public ResponseEntity<LoginResponseDto> login(@RequestBody LoginRequestDto request){
        // ...
    }
}

어노테이션 @Operation을 통해 api 이름과 설명을 적어줄 수 있습니다

위와 같이 설정한 결과 예시

[진행할 순서는]

• User 엔티티 + DB 연결
• 일반 회원가입/로그인 (비밀번호 암호화)
• JWT 발급 및 인증 흐름 적용
• 소셜 로그인 (구글 또는 카카오) + JWT 연동

1️⃣ User 엔티티 + DB 연결

🔹 프로젝트 생성하기

너무나 당연한 소리였죵 ?

🔹 user 엔티티

🔹 DB 생성 및 연결

CREATE TABLE user (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL,
    provider VARCHAR(50) NOT NULL
);

이렇게 DB를 만들고

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

  jpva:
    hibernate:
      ddl-auto: update
    show-sql: true
    database-platform: org.hibernate.dialect.MySQLDialect

연결을 위한 application.yml을 작성해줍니다

2️⃣ 일반 회원가입/로그인 (비밀번호 암호화)

🔹 1. UserRepository 생성

: JPA로 User 엔티티 저장/조회 처리

public interface UserRepository extends JpaRepository<User, Long> {
    User findByUsername(String username);
}

🔹 2. UserController 생성

: 회원가입용 POST 엔드포인트 (/signup) : 로그인용 POST 엔드포인트 (/login)

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

    @Autowired
    private UserService userService;

    @PostMapping("/signup")
    public String signup(@RequestParam String password, @RequestParam String provider) {
        userService.signup(password, provider);
        return "회원가입 성공!";
    }

    @PostMapping("/login")
    public String login(@RequestParam Long id, @RequestParam String password) {
        boolean success = userService.login(id, password);
        return success ? "로그인 성공!" : "로그인 실패!";
    }
}

아 그리고 저는 api 기본 경로를

server:
  servlet:
    context-path: /hackathon/api

로 미리 넣어둬서

[실제 api 호출 경로는] POST /hackathon/api/users/signup POST /hackathon/api/users/login 이렇게 됩니다

🔹 3. UserService 생성

: 비밀번호 암호화 (BCrypt 사용) : 회원정보 저장 & 검증

@Service
public class UserService {

    private final UserRepository userRepository;
    private final BCryptPasswordEncoder passwordEncoder;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
        this.passwordEncoder = new BCryptPasswordEncoder();
    }

    public User signup(String rawPassword, String provider) {
        String encodedPassword = passwordEncoder.encode(rawPassword);

        User user = new User();
        user.setPassword(encodedPassword);
        user.setProvider(provider);

        return userRepository.save(user);
    }

    public boolean login(Long id, String rawPassword) {
        return userRepository.findById(id)
                .map(user -> passwordEncoder.matches(rawPassword, user.getPassword()))
                .orElse(false);
    }
}

이렇게 넣고, Cannot resolve method 'setPassword' in 'User' 같은 오류가 난다면 User.Entity에서 @Setter @Getter 어노테이션을 넣었는지 확인하고 없다면, 추가해주세요

@Getter @Setter
@Entity
public class User {
        ...
}

🔹 4. Spring Security 설정

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .cors(...)                    // 1.CORS 설정 (프론트 도메인 허용)
        .csrf(csrf -> csrf.disable()) // 2.CSRF 비활성화 (JWT 사용 시 필수)
        .sessionManagement(...)       // 3.세션 안 씀 (stateless, JWT 기반 인증을 위해)
        .authorizeHttpRequests(...)   // 4.인증/비인증 경로 지정
        .addFilterBefore(...)         // 5.JWT 필터를 UsernamePasswordAuthenticationFilter 전에 끼워넣음
}

이 로직으로 짜봤습니다 5번 JWT 필터를 넣으려고

@Component
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain
    ) throws ServletException, IOException {

        // TODO: 여기에 JWT 인증 로직 구현 예정
        filterChain.doFilter(request, response);
    }
}

이와 같이 JwtAuthenticationFilter.java 를 security 하위에 생성 해 두었고 원래 작성하려했던 SecurityConfig.java 로 다시와서

import java.util.Arrays;
import java.util.List;

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Value("${frontend.domain:localhost}")
    private String frontendDomain;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain securityFilterChain(org.springframework.security.config.annotation.web.builders.HttpSecurity http) throws Exception {
        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource())) // cors 설정
                .csrf(csrf -> csrf.disable()) // CSRF 비활성화
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) //세션 x

                // 임시 전체 허용
                .authorizeHttpRequests(auth -> auth
                        .anyRequest().permitAll()
                )
                .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); // JWT 필터

        return http.build();
    }

    private CorsConfigurationSource corsConfigurationSource() {
        return request -> {
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedOriginPatterns(Arrays.asList(
                    "https://" + frontendDomain,
                    "http://localhost:3003",
                    "https://localhost:3003",
                    "https://localhost:8080"
            ));
            config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE", "OPTIONS"));
            config.setAllowedHeaders(List.of("*"));
            config.setExposedHeaders(List.of("Authorization"));
            config.setAllowCredentials(true);
            config.setMaxAge(3600L);
            return config;
        };
    }
}

이렇게 완성했습니다.

3️⃣ JWT 발급 및 인증 흐름 적용

JWT 토큰을 발급하고 인증하는 로직을 적용하기 위해서 security>jwt 디렉토리를 만들었고

이렇게 3개 클래스에 대해 만들어봤습니다

JwtAuthenticationFilter.java

HTTP 요청에 포함된 JWT 토큰을 검사하여 사용자의 인증 정보를 확인하고, 인증된 사용자만 서비스에 접근할 수 있도록 하는 필터 역할을 합니다.

@Component
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain
    ) throws ServletException, IOException {

        // TODO: 여기에 JWT 인증 로직 구현 예정
        filterChain.doFilter(request, response);
    }
}

로그인시 토큰 발급이 목적이기에, 아직 JWT 인증 로직은 구현 전입니다

JwtUtil.java

JWT 토큰의 생성, 서명, 검증, 만료 시간 처리 등 JWT와 관련된 핵심 유틸리티 기능을 담당합니다.

@Component
public class JwtUtil {

    @Value("${JWT_SECRET}")
    private String SECRET_KEY;

    private final long ACCESS_EXP_TIME = 1000L * 60 * 60; // 1시간

    private Key getSigningKey() {
        return Keys.hmacShaKeyFor(SECRET_KEY.getBytes(StandardCharsets.UTF_8));
    }

    public String generateAccessToken(User user) {
        return Jwts.builder()
                .setSubject(user.getUsername()) // subject: username
                .claim("userId", user.getId())   // 추가 클레임
                .claim("type", "access")
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + ACCESS_EXP_TIME))
                .signWith(getSigningKey(), SignatureAlgorithm.HS256)
                .compact();
    }

    public String generateRefreshToken(User user) {
        Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Asia/Seoul"));
        calendar.set(Calendar.HOUR_OF_DAY, 9);
        calendar.set(Calendar.MINUTE, 0);
        calendar.set(Calendar.SECOND, 0);
        calendar.set(Calendar.MILLISECOND, 0);

        if (calendar.getTimeInMillis() <= System.currentTimeMillis()) {
            calendar.add(Calendar.DATE, 1); // 다음 날 9시
        }

        return Jwts.builder()
                .setSubject(user.getUsername())
                .claim("type", "refresh")
                .setIssuedAt(new Date())
                .setExpiration(calendar.getTime())
                .signWith(getSigningKey(), SignatureAlgorithm.HS256)
                .compact();
    }

}

여기도 일단, 발급이 중요한 로직이기에, 발급 부분만 구현 해봤습니다 .!

TokenStatus.java

JWT 토큰의 유효성 상태(인증 성공, 만료, 무효 등)를 나타내는 상태 값을 정의하는 enum 클래스입니다.

public enum TokenStatus {
    AUTHENTICATED,
    EXPIRED,
    INVALID
}

결과확인

1. POST /hackathon/api/users/signup

회원가입 성공이라는 메시지와 함께, userId를 반환합니다

2. user의 비밀번호도 DB에 암호화되어 저장

3. POST /hackathon/api/users/login

해당 유저의 username과 password로 로그인시, 토큰 발급과 응답값 출력 성공

다음 편에서, 소셜 로그인 (구글 또는 카카오) + JWT 연동에 대해 써보겠습니다