문제 상황

초기 관리자 기능은 하나의 AdminController와 AdminService에서 처리하도록 구현하였다.

AdminController
      ↓
AdminService
 ├── 대시보드
 ├── 신고 관리
 ├── 회원 관리
 ├── 판매자 신청 관리
 └── 상품 관리

관리자 기능이 추가되면서 하나의 Controller와 Service에 여러 도메인의 API와 비즈니스 로직이 집중되었다.

그 결과 특정 기능을 수정하기 위해 관련 없는 코드까지 함께 확인해야 했으며, 새로운 관리자 기능을 추가할 때 기존 클래스의 코드가 계속 증가하는 문제가 발생했다. 또한 Controller에서 여러 Service를 직접 의존하게 되면서 클래스 간 결합도 역시 높아졌다.

원인

기능의 구분 없이 관리자 기능이라는 큰 범위만을 기준으로 Controller와 Service를 구성한 것이 원인이었다.

특히 각 기능이 서로 다른 책임을 가지고 있음에도 하나의 Service에서 회원, 신고, 상품 등의 비즈니스 로직을 모두 처리하고 있었다.

해결

관리자 기능을 도메인별로 분리하여 각 기능이 독립적인 책임을 갖도록 구조를 변경하였다.

AdminMemberController  → AdminMemberService
AdminReportController  → AdminReportService
AdminSellerController  → AdminSellerService
AdminProductController  → AdminProductService

대시보드처럼 여러 도메인의 데이터를 하나의 응답으로 조합해야 하는 기능은 각 Service를 Controller에서 직접 호출하지 않고 AdminDashboardService가 조합하도록 구성하였다.

AdminDashboardController
          ↓
AdminDashboardService
     ┌────┼────┬────┐
     ↓    ↓    ↓    ↓
  Member Report Seller Product
  Service Service Service Service

이를 통해 Controller는 HTTP 요청과 응답 처리에 집중하고, 각 도메인의 비즈니스 로직은 해당 Service에서 담당하도록 책임을 분리하였다.

결과

• 관리자 기능별 책임이 명확해져 코드 탐색과 유지보수가 쉬워졌다.
• 특정 기능을 수정할 때 관련 없는 도메인의 코드를 확인해야 하는 범위를 줄였다.
• 새로운 관리자 기능을 추가할 때 기존 Controller와 Service의 코드 증가를 최소화할 수 있었다.
• Controller가 여러 도메인의 Service를 직접 의존하지 않도록 하여 의존 관계를 단순화하였다.
• 여러 도메인의 기능을 조합해야 하는 대시보드는 상위 Service에서 조합하도록 하여 각 도메인 Service의 책임을 유지할 수 있었다.

개선 후 구조

admin
├── dashboard
│   ├── AdminDashboardController
│   └── AdminDashboardService
│
├── member
│   ├── AdminMemberController
│   └── AdminMemberService
│
├── report
│   ├── AdminReportController
│   └── AdminReportService
│
├── seller
│   ├── AdminSellerController
│   └── AdminSellerService
│
└── product
    ├── AdminProductController
    └── AdminProductService

이번 개선을 통해 단순히 클래스를 분리하는 것에 그치지 않고, 각 기능의 책임과 의존 관계를 기준으로 구조를 재설계하여 기능 확장에 대응하기 쉬운 구조로 개선하였다.

Hibernate: select distinct p1_0.id,p1_0.board_type,p1_0.content,p1_0.created_at,p1_0.image_url,p1_0.is_hidden,p1_0.like_count,p1_0.member_id,m1_0.id,m1_0.created_at,m1_0.email,m1_0.last_login_at,m1_0.nickname,m1_0.oauth_access_token,m1_0.oauth_provider,m1_0.oauth_refresh_token,m1_0.onboarded,m1_0.password,m1_0.profile_image_url,m1_0.role,m1_0.shop_name,m1_0.shop_url,m1_0.sns_urls,m1_0.status,m1_0.username,p1_0.title,p1_0.view_count from post p1_0 left join comment c1_0 on c1_0.post_id=p1_0.id join member m1_0 on m1_0.id=p1_0.member_id where p1_0.board_type in (?,?,?,?) and p1_0.is_hidden=0 and (? is null or ?='' or lower(p1_0.title) like replace(lower(concat('%',?,'%')),'\\','\\\\') or lower(p1_0.content) like replace(lower(concat('%',?,'%')),'\\','\\\\') or lower(c1_0.content) like replace(lower(concat('%',?,'%')),'\\','\\\\')) order by p1_0.created_at desc limit ?
Hibernate: select count(distinct p1_0.id) from post p1_0 left join comment c1_0 on c1_0.post_id=p1_0.id where p1_0.board_type in (?,?,?,?) and p1_0.is_hidden=0 and (? is null or ?='' or lower(p1_0.title) like replace(lower(concat('%',?,'%')),'\\','\\\\') or lower(p1_0.content) like replace(lower(concat('%',?,'%')),'\\','\\\\') or lower(c1_0.content) like replace(lower(concat('%',?,'%')),'\\','\\\\'))
Hibernate: select m1_0.id,m1_0.created_at,m1_0.email,m1_0.last_login_at,m1_0.nickname,m1_0.oauth_access_token,m1_0.oauth_provider,m1_0.oauth_refresh_token,m1_0.onboarded,m1_0.password,m1_0.profile_image_url,m1_0.role,m1_0.shop_name,m1_0.shop_url,m1_0.sns_urls,m1_0.status,m1_0.username from member m1_0 where m1_0.username=?
Hibernate: select pl1_0.id,pl1_0.member_id,pl1_0.post_id from post_like pl1_0 where pl1_0.member_id=? and pl1_0.post_id in (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)
Hibernate: select count(c1_0.id) from comment c1_0 where c1_0.post_id=? and not(c1_0.is_hidden)

• 24번의 쿼리가 실행.

• 1.게시글 목록 조회 (1번): select distinct p1_0.id ... from post p1_0 ... limit ?

• 2.전체 게시글 수 카운트 (1번): select count(distinct p1_0.id) from post p1_0 ... (페이징 처리를 위해 전체 개수를 세는 쿼리)

• 3.로그인 회원 정보 조회 (1번): select ... from member m1_0 where m1_0.username=?

• 4.좋아요 누른 목록 조회 (1번): select ... from post_like pl1_0 where pl1_0.member_id=? and pl1_0.post_id in (...)

• 5.개별 댓글 개수 조회 (20번): select count(c1_0.id) from comment c1_0 where c1_0.post_id=? ... (이 부분이 게시글 개수만큼 반복되어 총 20번 실행됨)

• --> N+1문제 발생. 여기도 1번발 발생해서 총 5번만 발생되게 해야한다. 총계: 1 + 1 + 1 + 1 + 20 = 총 24번

''' commentRepository.countByPostIdAndIsHiddenFalse(p.getId())에서 문제 발생.

int countByPostIdAndIsHiddenFalse(Long postId); //게시글 하나당 댓글 개수를 조회하는 메서드 ---> 게시글이 20개면 20번 호출하니까 N+1이 발생하는 것 '''

• posts.map()이 게시글 개수만큼 반복 실행되면서 게시글마다 댓글 개수를 조회하는 SQL이 추가로 발생하였다.

  해결방법

• GROUP BY로 한 번에 조회
• 댓글 개수를 게시글마다 조회하지 않고, GROUP BY와 IN을 이용하여 모든 게시글의 댓글 개수를 한 번의 집계 쿼리로 조회하도록 변경.

''' SELECT post_id, COUNT(*) FROM comment WHERE post_id IN (...) AND is_hidden = false GROUP BY post_id; '''

• 조회한 결과를 Map<PostId, CommentCount> 형태로 저장한 뒤, PostResponse 생성 시 Map에서 댓글 개수를 조회하도록 수정

''' List postIds = posts.stream() .map(Post::getId) .toList();

Map<Long, Integer> commentCountMap = commentRepository.countCommentsByPostIds(postIds) .stream() .collect(Collectors.toMap( row -> (Long) row[0], row -> ((Long) row[1]).intValue() ));

final List finalLikedPostIds = likedPostIds;

return posts.map(p -> new PostResponse( p.getId(), p.getTitle(), p.getContent(), p.getBoardType().name(), p.getImageUrl(), p.getMember().getNickname(), p.getViewCount() + postRedisService.getCachedViewCount(p.getId()), p.getLikeCount(), p.getCreatedAt(), p.getMember().getProfileImageUrl(), finalLikedPostIds.contains(p.getId()), commentCountMap.getOrDefault(p.getId(), 0) )); ''' Hibernate: select distinct p1_0.id,p1_0.board_type,p1_0.content,p1_0.created_at,p1_0.image_url,p1_0.is_hidden,p1_0.like_count,p1_0.member_id,m1_0.id,m1_0.created_at,m1_0.email,m1_0.last_login_at,m1_0.nickname,m1_0.oauth_access_token,m1_0.oauth_provider,m1_0.oauth_refresh_token,m1_0.onboarded,m1_0.password,m1_0.profile_image_url,m1_0.role,m1_0.shop_name,m1_0.shop_url,m1_0.sns_urls,m1_0.status,m1_0.username,p1_0.title,p1_0.view_count from post p1_0 left join comment c1_0 on c1_0.post_id=p1_0.id join member m1_0 on m1_0.id=p1_0.member_id where p1_0.board_type in (?,?,?,?) and p1_0.is_hidden=0 and (? is null or ?='' or lower(p1_0.title) like replace(lower(concat('%',?,'%')),'\','\\') or lower(p1_0.content) like replace(lower(concat('%',?,'%')),'\','\\') or lower(c1_0.content) like replace(lower(concat('%',?,'%')),'\','\\')) order by p1_0.created_at desc limit ? Hibernate: select count(distinct p1_0.id) from post p1_0 left join comment c1_0 on c1_0.post_id=p1_0.id where p1_0.board_type in (?,?,?,?) and p1_0.is_hidden=0 and (? is null or ?='' or lower(p1_0.title) like replace(lower(concat('%',?,'%')),'\','\\') or lower(p1_0.content) like replace(lower(concat('%',?,'%')),'\','\\') or lower(c1_0.content) like replace(lower(concat('%',?,'%')),'\','\\')) Hibernate: select m1_0.id,m1_0.created_at,m1_0.email,m1_0.last_login_at,m1_0.nickname,m1_0.oauth_access_token,m1_0.oauth_provider,m1_0.oauth_refresh_token,m1_0.onboarded,m1_0.password,m1_0.profile_image_url,m1_0.role,m1_0.shop_name,m1_0.shop_url,m1_0.sns_urls,m1_0.status,m1_0.username from member m1_0 where m1_0.username=? Hibernate: select pl1_0.id,pl1_0.member_id,pl1_0.post_id from post_like pl1_0 where pl1_0.member_id=? and pl1_0.post_id in (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) Hibernate: select c1_0.post_id,count(c1_0.id) from comment c1_0 where c1_0.post_id in (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) and c1_0.is_hidden=0 group by c1_0.post_id ''' --> sql문이 5번만 실행.

기존 코드를 분석해 본 결과, 실무 환경에서는 치명적일 수 있는 두 가지 문제점을 발견했습니다.

1. 조회수(Views) 무한 새로고침 어뷰징 및 DB 부하 기존의 조회수 증가 로직은 다음과 같이 아주 단순했습니다.

java

// As-Is: 기존 BoardService 로직 @Transactional public PostResponse incrementViewCount(Long postId) { Post post = postRepository.findById(postId) .orElseThrow(() -> new IllegalArgumentException("게시글을 찾을 수 없습니다."));

post.incrementViewCount(); // DB의 조회수 + 1

return new PostResponse(...);

} 문제점:

한 명의 유저가 F5(새로고침)를 100번 누르면 조회수가 그대로 100이 올라가는 어뷰징에 무방비했습니다. 유저가 게시글을 클릭할 때마다 무조건 DB에 UPDATE 쿼리가 날아갑니다. 트래픽이 몰릴 경우 DB 커넥션이 고갈되고 엄청난 병목 현상이 발생할 수 있습니다. 2. 좋아요(Likes) 동시성 문제 및 DB Lock 좋아요 기능 역시 PostLike라는 매핑 테이블을 두어 정석대로 구현했습니다.

java

// As-Is: 기존 BoardService 로직 @Transactional public boolean toggleLike(Long postId, String username) { Post post = postRepository.findById(postId)... Member member = memberRepository.findByUsername(username)... Optional existingLike = postLikeRepository.findByMemberAndPost(member, post);

if (existingLike.isPresent()) {
    postLikeRepository.delete(existingLike.get());
    post.decrementLikeCount(); // 취소 시 감소
} else {
    postLikeRepository.save(new PostLike(member, post));
    post.incrementLikeCount(); // 클릭 시 증가
}

} 문제점: 로직 자체는 흠잡을 데가 없지만, 동시성(Concurrency) 측면에서 위험합니다. 유명인의 게시물에 수백 명이 동시에 좋아요를 누르게 되면, 1번 게시글(Row)에 수많은 쓰레드가 동시에 UPDATE 쿼리를 날리게 됩니다. 이는 심각한 DB Lock 경합을 유발하여 서버 장애로 이어질 수 있습니다.

🛠 해결 방안: Redis 인메모리 캐시 도입 (To-Be) 관계형 데이터베이스(RDBMS)에 직접 쿼리를 때리는 기존 방식을 버리고, 응답 속도가 매우 빠른 Redis(인메모리 데이터 저장소)를 활용한 아키텍처로 전면 개편하기로 결정했습니다.

1. 조회수 개편 (중복 방지 및 스케줄러 동기화) 중복 방지: 사용자의 식별자(username 또는 IP)를 조합하여 view:post:{postId}:user:{identifier}라는 키를 생성합니다. 이 키에 TTL(만료시간)을 24시간으로 걸어두어, 하루 동안은 같은 글을 여러 번 봐도 조회수가 오르지 않도록 방어했습니다. Write-Back 패턴 (Batch): 조회수를 올릴 때 DB에 UPDATE를 치지 않고, Redis의 post:views:{postId} 카운터만 INCR 시킵니다. 그리고 Spring Scheduler를 이용해 5분마다 한 번씩 Redis에 쌓인 조회수를 긁어모아 DB에 벌크 업데이트(Bulk Update)를 치도록 설계했습니다. DB 부하가 획기적으로 줄어듭니다.
2. 좋아요 개편 (Set 자료구조 활용) Redis Set 활용: 좋아요를 누른 유저 목록을 Redis의 Set 자료구조(post:likes:{postId})로 관리합니다. SISMEMBER 명령어로 중복 여부를 O(1) 속도로 파악하고, SADD/SREM으로 토글 처리를 합니다. 실시간 렌더링 + 비동기 처리: 사용자가 버튼을 누르면 Redis에서 즉시 카운트(SCARD)를 올려 프론트엔드에 빠르게 응답(200 OK)을 내려줍니다. 그리고 무거운 DB Insert/Delete 작업은 @Async를 활용하여 백그라운드 스레드에서 비동기로 처리하여 사용자 경험(UX)을 극대화했습니다. 💡 회고 및 결론 MVP 단계에서는 "일단 돌아가는 코드"를 짰다면, 이번 리팩토링을 통해 "실무에서 트래픽을 견딜 수 있는 튼튼한 아키텍처"에 대해 깊게 고민해 볼 수 있었습니다.

단순히 비즈니스 로직을 구현하는 것을 넘어, DB 트랜잭션을 최소화하고 캐시 서버를 적재적소에 활용하는 것이 백엔드 개발자의 진짜 핵심 역량이라는 것을 깨닫는 귀중한 트러블슈팅 경험이었습니다. 앞으로 남은 동기화 스케줄러 로직 구현과 프론트 연동 테스트도 꼼꼼히 진행할 예정입니다! 🚀

JWT(JSON Web Token)는 로그인 후 서버가 사용자에게 발급하는 인증 토큰이다.

기존 Session 방식은 서버가 로그인 정보를 저장하지만,

JWT 방식은 사용자 정보와 권한을 토큰에 담아 클라이언트가 보관한다.

이후 요청마다 JWT를 보내면 서버는 토큰만 검증하여 로그인 여부를 판단한다.

전체 흐름

로그인 요청
      ↓
Controller
      ↓
Service
      ↓
DB에서 회원 조회
      ↓
비밀번호 검증
      ↓
JWT 생성
      ↓
클라이언트에게 JWT 반환
      ↓
클라이언트가 JWT 저장
      ↓
이후 모든 요청에 JWT 포함
      ↓
JwtFilter가 JWT 검증
      ↓
SecurityContext에 인증 정보 저장
      ↓
Controller / Service 실행

1. 로그인 요청

사용자가 로그인 버튼을 누르면

POST /api/auth/login

으로 요청이 들어온다.

Controller

@PostMapping("/login")
public ResponseEntity<LoginResponse> login(
        @Valid @RequestBody LoginRequest request) {

    LoginResponse loginResult = memberService.login(request);
    return ResponseEntity.ok(loginResult);
}

Controller의 역할은 매우 단순하다.

• 로그인 요청 받기
• Service 호출
• 결과 반환

실제 로그인 로직은 모두 Service에서 처리한다.

2. 회원 조회

Service에서는 먼저 username이 존재하는지 확인한다.

Member member = memberRepository.findByUsername(loginRequest.getUsername())
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 유저"));

실행 순서

입력한 username
        ↓
MemberRepository
        ↓
DB 조회
        ↓
Member 반환

회원이 없다면 로그인은 실패한다.

3. 비밀번호 검증

DB에는 평문 비밀번호가 저장되지 않는다.

예를 들어 사용자가 입력한 비밀번호가

1234

라고 해도,

DB에는 BCrypt로 암호화된 값만 저장된다.

$2a$10$......

비밀번호 비교는

passwordEncoder.matches(
        loginRequest.getPassword(),
        member.getPassword()
);

가 수행한다.

Spring Security가

입력한 비밀번호
        ↓
BCrypt 암호화
        ↓
DB의 암호화된 비밀번호와 비교

를 자동으로 수행한다.

일치하지 않으면

throw new IllegalArgumentException("비밀번호 불일치");

가 발생한다.

4. JWT 생성

로그인이 성공하면 JWT를 생성한다.

String token = jwtUtil.generateToken(
        member.getUsername(),
        member.getRole().name()
);

예를 들어

username = sleepy
role = SELLER

이라면

generateToken("sleepy", "SELLER");

가 호출된다.

5. JwtUtil에서 토큰 생성

토큰 생성 메서드

public String generateToken(String username, String role)

에서 JWT를 만든다.

현재 시간 저장

Date now = new Date();

토큰 발급 시간을 저장한다.

Subject 저장

.setSubject(username)

내 프로젝트에서는 username을 저장한다.

subject = sleepy

권한 저장

.claim("role", role)

role = SELLER

발급 시간

.setIssuedAt(now)

만료 시간

.setExpiration(...)

설정한 시간이 지나면 토큰은 사용할 수 없다.

Signature 생성

.signWith(secretKey, SignatureAlgorithm.HS256)

SECRET_KEY로 서명(Signature)을 만든다.

이 서명이 있기 때문에

• username 변경
• role 변경
• 토큰 위조

를 하면 검증에 실패한다.

JWT 완성

.compact();

실행 후

eyJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiJzbGVlcHkiLCJyb2xlIjoiU0VMTEVSIn0
.
xxxxxxxxxxxxxxxx

와 같은 JWT가 생성된다.

6. 로그인 응답

Service는

return LoginResponse.builder()
        .memberId(member.getId())
        .accessToken(token)
        .username(member.getUsername())
        .email(member.getEmail())
        .nickname(member.getNickname())
        .role(member.getRole())
        .build();

를 반환한다.

Controller는 JSON으로 변환하여 응답한다.

{
  "memberId": 1,
  "username": "sleepy",
  "nickname": "슬리피",
  "role": "SELLER",
  "accessToken": "eyJhbGc..."
}

7. 클라이언트가 JWT 저장

Flutter에서는

• SecureStorage
• SharedPreferences

등에 저장한다.

로그인은 여기서 끝난다.

8. 이후 모든 요청

상품 등록 요청을 한다고 가정하면

POST /api/products

Header에 JWT를 함께 보낸다.

Authorization: Bearer eyJhbGc...

JWT가 신분증 역할을 한다.

9. JwtFilter 실행

Spring Security는 Controller보다 먼저 JwtFilter를 실행한다.

Authorization 헤더를 가져온다.

String header = request.getHeader("Authorization");

값은

Bearer eyJhbGc...

Bearer를 제거한다.

String token = header.substring(7);

최종적으로

eyJhbGc...

토큰만 남는다.

10. JWT 검증

Claims claims = Jwts.parserBuilder()
        .setSigningKey(secretKey)
        .build()
        .parseClaimsJws(token)
        .getBody();

이 과정에서

• 토큰 서명 검증
• SECRET_KEY 검증
• 토큰 위조 여부 확인
• 만료 시간 확인
• JWT 형식 확인

을 모두 수행한다.

검증이 성공하면

String username = claims.getSubject();
String role = claims.get("role", String.class);

를 통해 사용자 정보를 가져온다.

11. SecurityContext에 저장

List<GrantedAuthority> authorities =
        List.of(new SimpleGrantedAuthority("ROLE_" + role));

UsernamePasswordAuthenticationToken auth =
        new UsernamePasswordAuthenticationToken(
                username,
                null,
                authorities
        );

SecurityContextHolder.getContext().setAuthentication(auth);

이 순간부터 Spring Security는

현재 요청은

username = sleepy
ROLE = SELLER

인 사용자가 로그인한 요청이라고 인식한다.

12. Controller 실행

@PostMapping
public void create(Authentication authentication) {

    String username = authentication.getName();
}

authentication.getName()으로 현재 로그인한 사용자의 username을 얻을 수 있다.

또한

@PreAuthorize("hasRole('SELLER')")

가 있다면

SecurityContext에 저장된 권한을 검사하여

ROLE_SELLER

가 있을 때만 메서드를 실행한다.

없다면

403 Forbidden

을 반환한다.

최종 흐름

사용자
   │
   │ POST /login
   ▼
Controller
   │
   ▼
MemberService.login()
   │
   ├── DB에서 회원 조회
   ├── BCrypt 비밀번호 검증
   ├── JwtUtil.generateToken()
   │      ├── username 저장
   │      ├── role 저장
   │      ├── 발급 시간 저장
   │      ├── 만료 시간 저장
   │      └── SECRET_KEY로 서명
   │
   ▼
JWT 생성
   │
   ▼
클라이언트에 반환
   │
   ├── SecureStorage / SharedPreferences 저장
   │
   ▼
이후 모든 요청
Authorization: Bearer JWT
   │
   ▼
JwtFilter
   │
   ├── Authorization 헤더 확인
   ├── Bearer 제거
   ├── JWT 서명 검증
   ├── 만료 시간 확인
   ├── username 추출
   ├── role 추출
   └── SecurityContextHolder에 Authentication 저장
   │
   ▼
Spring Security
   │
   ├── @PreAuthorize 권한 검사
   └── Authentication 객체 제공
   │
   ▼
Controller → Service → Repository → DB

정리

• Controller : 로그인 요청을 받아 Service를 호출한다.
• Service : 회원 조회, 비밀번호 검증, JWT 생성까지 담당한다.
• JwtUtil : JWT 생성과 검증을 담당한다.
• JwtFilter : 요청마다 JWT를 검사하고 SecurityContext에 인증 정보를 저장한다.
• SecurityContextHolder : 현재 요청의 로그인 정보를 저장한다.
• Spring Security : SecurityContext를 이용하여 인증과 권한 검사를 수행한다.

Spring Boot와 JPA에서는 엔티티(Entity)나 DTO 객체를 생성할 때 가장 많이 사용하는 패턴 중 하나이다.

Builder Pattern을 사용하는 이유

객체의 필드가 많아질수록 생성자(Constructor)나 Setter를 사용하는 방식에는 여러 문제가 발생한다.

Builder Pattern은 이러한 문제를 해결하기 위해 사용된다.

1. 생성자의 문제점

예를 들어 Member 객체를 생성한다고 가정해보자.

Member member = new Member(
    "kim",
    "1234",
    "김승호",
    "kim@test.com",
    Role.BUYER,
    LocalDateTime.now()
);

이 코드를 보면 "1234"가 비밀번호인지, "김승호"가 닉네임인지 한눈에 알아보기 어렵다.

또한 같은 타입(String)이 여러 개라면 순서를 잘못 입력해도 컴파일 오류가 발생하지 않을 수 있다.

예를 들어

Member member = new Member(
    "kim",
    "김승호",   // password 자리에 nickname이 들어감
    "1234",
    "kim@test.com",
    Role.BUYER,
    LocalDateTime.now()
);

이처럼 매개변수의 순서를 실수해도 잘못된 객체가 생성될 수 있다.

2. Setter의 문제점

Setter를 사용하면 다음과 같이 객체를 생성할 수 있다.

Member member = new Member();

member.setUsername("kim");
member.setPassword("1234");
member.setNickname("김승호");

하지만 객체가 생성되는 도중 예외가 발생하면

Member member = new Member();

member.setUsername("kim");

// 예외 발생

비밀번호도 없고 닉네임도 없는 불완전한 객체가 만들어질 수 있다.

또한 JPA에서는 Entity의 Setter를 무분별하게 사용하는 것을 권장하지 않는다.

3. Builder Pattern 사용

Builder Pattern을 사용하면 다음과 같이 객체를 생성할 수 있다.

Member member = Member.builder()
        .username("kim")
        .password("1234")
        .nickname("김승호")
        .email("kim@test.com")
        .role(Role.BUYER)
        .build();

각 값이 어떤 필드에 들어가는지 코드만 봐도 바로 알 수 있다.

또한 필드의 순서를 자유롭게 작성할 수 있다.

Member member = Member.builder()
        .role(Role.BUYER)
        .nickname("김승호")
        .username("kim")
        .password("1234")
        .email("kim@test.com")
        .build();

순서를 바꿔도 동일한 객체가 생성된다.

build()는 무슨 역할을 할까?

Builder는 객체를 바로 생성하지 않는다.

Member.builder()

를 호출하면 Builder 객체가 생성된다.

.username("kim")
.password("1234")
.nickname("김승호")

를 호출하면서 Builder 내부에 값만 저장한다.

마지막에

.build()

를 호출하면 저장된 값들을 이용해 Member 객체를 생성한다.

즉,

builder()
    ↓
Builder 객체 생성
    ↓
필드 값 저장
    ↓
build()
    ↓
Member 객체 생성

이라는 순서로 동작한다.

Lombok의 @Builder

Lombok의 @Builder를 사용하면 Builder 클래스를 직접 작성하지 않아도 자동으로 생성해준다.

예를 들어

@Builder
public class Member {

    private String username;
    private String password;
}

만 작성하면 내부적으로 Builder 클래스가 자동 생성되어

Member.builder()
        .username("kim")
        .password("1234")
        .build();

와 같이 사용할 수 있다.

실제 프로젝트 예시

회원가입에서 Member 객체를 생성하는 코드이다.

Member member = Member.builder()
        .username(request.getUsername())
        .email(email)
        .password(passwordEncoder.encode(request.getPassword()))
        .nickname(request.getNickname())
        .role(Role.BUYER)
        .createdAt(LocalDateTime.now())
        .onboarded(true)
        .build();

memberRepository.save(member);

동작 순서는 다음과 같다.

Member.builder()
      ↓
Builder 생성
      ↓
username 저장
      ↓
email 저장
      ↓
password 저장
      ↓
nickname 저장
      ↓
role 저장
      ↓
build()
      ↓
Member 객체 생성
      ↓
memberRepository.save()
      ↓
DB 저장

Builder Pattern의 장점

• 코드의 가독성이 좋아진다.
• 어떤 값이 어떤 필드에 들어가는지 한눈에 알 수 있다.
• 생성자의 매개변수 순서를 신경 쓰지 않아도 된다.
• Setter를 남발하지 않아도 된다.
• 불완전한 객체 생성을 방지할 수 있다.
• 필드가 많아질수록 유지보수가 쉬워진다.

정리

Spring Boot와 JPA에서는 Entity나 DTO를 생성할 때 Builder Pattern을 많이 사용한다.

Builder Pattern은 객체를 단계적으로 생성하여 가독성, 안정성, 유지보수성을 높여주는 패턴이며, 실무에서도 가장 많이 사용하는 객체 생성 방식 중 하나이다.

엔티티는 생성부터 삭제까지 다음과 같은 4가지 상태를 가진다.

비영속(Transient)
        ↓
영속(Persistent)
        ↓
준영속(Detached)
        ↓
삭제(Removed)

1. 비영속(Transient)

비영속 상태는 영속성 컨텍스트가 관리하지 않는 새로운 객체이다.

Product product = new Product();

이 객체는 단순히 JVM 메모리에만 존재하며 DB와는 아무런 관계가 없다.

특징

• 영속성 컨텍스트가 관리하지 않는다.
• DB에 저장되지 않는다.
• Dirty Checking이 동작하지 않는다.

2. 영속(Persistent)

영속 상태는 영속성 컨텍스트가 엔티티를 관리하는 상태이다.

Product product = productRepository.findById(1L).get();

또는

productRepository.save(product);

이후부터 해당 엔티티는 영속성 컨텍스트의 관리 대상이 된다.

특징

• 1차 캐시를 사용할 수 있다.
• Dirty Checking이 동작한다.
• 쓰기 지연(Write Behind)이 적용된다.
• 트랜잭션 종료 시 변경 사항이 자동으로 DB에 반영된다.

예를 들어

@Transactional
public void update() {

    Product product = productRepository.findById(1L).get();

    product.setPrice(30000);

}

save()를 호출하지 않아도 Dirty Checking으로 인해 UPDATE SQL이 자동으로 실행된다.

3. 준영속(Detached)

준영속 상태는 영속성 컨텍스트가 더 이상 엔티티를 관리하지 않는 상태이다.

예를 들어

entityManager.detach(product);

를 호출하면 해당 엔티티는 준영속 상태가 된다.

특징

• 영속성 컨텍스트의 관리 대상이 아니다.
• Dirty Checking이 동작하지 않는다.
• 객체를 수정해도 DB에 반영되지 않는다.

4. 삭제(Removed)

삭제 상태는 삭제가 예약된 상태이다.

productRepository.delete(product);

또는

entityManager.remove(product);

를 호출하면 삭제 상태가 되며,

트랜잭션이 Commit되면 DELETE SQL이 실행된다.

DELETE
FROM product
WHERE id = 1;

Entity 생명주기 정리

한 줄 요약

• 비영속 : new로 생성한 객체
• 영속 : JPA가 관리하는 객체
• 준영속 : JPA가 더 이상 관리하지 않는 객체
• 삭제 : 삭제가 예약된 객체

JPA 전체 흐름

JPA
    ↓
Hibernate
    ↓
@Transactional
    ↓
영속성 컨텍스트
    ↓
Entity(영속 상태)
    ↓
1차 캐시
    ↓
Dirty Checking
    ↓
Write Behind
    ↓
Flush
    ↓
Commit
    ↓
Database

영속성 컨텍스트(Persistence Context)는 JPA가 엔티티(Entity)를 관리하는 메모리 공간이다.

개발자가 엔티티를 조회하거나 저장하면 DB와 바로 통신하는 것이 아니라, 먼저 영속성 컨텍스트에서 엔티티를 관리한 후 필요할 때 DB와 동기화한다.

Application
    ↓
JPA(Hibernate)
    ↓
영속성 컨텍스트
    ↓
Database

1. 1차 캐시(First Level Cache)

영속성 컨텍스트는 조회한 엔티티를 메모리에 저장한다.

예를 들어

Product p1 = productRepository.findById(1L).get();
Product p2 = productRepository.findById(1L).get();

처음 조회할 때만 SQL이 실행된다.

SELECT * FROM product WHERE id = 1;

두 번째 조회는 영속성 컨텍스트의 1차 캐시에서 가져오기 때문에 SQL이 실행되지 않는다.

장점

• 불필요한 DB 조회를 줄일 수 있다.
• 같은 트랜잭션 내에서 조회 성능이 향상된다.

2. Dirty Checking(변경 감지)

JPA는 조회한 엔티티의 변경 사항을 자동으로 감지한다.

@Transactional
public void updatePrice() {

    Product product = productRepository.findById(1L).get();

    product.setPrice(30000);

}

save()를 호출하지 않아도 트랜잭션이 종료될 때 JPA가 변경 내용을 감지하여 UPDATE SQL을 실행한다.

UPDATE product
SET price = 30000
WHERE id = 1;

장점

• 개발자가 직접 UPDATE SQL을 작성하지 않아도 된다.
• 코드가 간결해지고 객체 중심 개발이 가능하다.

3. 쓰기 지연(Write Behind)

save()를 호출했다고 해서 바로 INSERT SQL이 실행되는 것은 아니다.

productRepository.save(product);

먼저 영속성 컨텍스트에 저장한 뒤,

트랜잭션이 Commit 되는 시점에 SQL을 한꺼번에 실행한다.

save()

↓

영속성 컨텍스트 저장

↓

Commit

↓

Flush

↓

INSERT / UPDATE / DELETE 실행

장점

• SQL을 모아서 실행하므로 성능을 향상시킬 수 있다.
• 트랜잭션 단위로 데이터를 일관성 있게 관리할 수 있다.

4. Flush

Flush는 영속성 컨텍스트의 변경 내용을 데이터베이스와 동기화하는 작업이다.

Flush가 발생하면

• INSERT
• UPDATE
• DELETE

SQL이 실행된다.

하지만 Flush는 Commit과 다르다.

• Flush : DB와 동기화
• Commit : 실제 트랜잭션 확정

정리

한 줄 요약

• 영속성 컨텍스트는 JPA가 엔티티를 관리하는 메모리 공간이다.
• 1차 캐시를 통해 같은 엔티티를 반복 조회해도 DB를 다시 조회하지 않는다.
• Dirty Checking을 통해 엔티티 변경을 자동으로 감지하여 UPDATE SQL을 생성한다.
• 쓰기 지연을 통해 SQL을 즉시 실행하지 않고 Commit 시점에 한꺼번에 실행한다.
• Flush는 영속성 컨텍스트의 변경 내용을 DB와 동기화하는 과정이다.

JPA에서 연관 엔티티를 언제 조회할지 결정하는 옵션이다.

1. LAZY (지연 로딩)

연관 엔티티를 실제로 사용할 때 조회한다.

@ManyToOne(fetch = FetchType.LAZY)
private Seller seller;

예를 들어 상품을 조회하면 상품만 가져오고,

Product product = productRepository.findById(1L).get();

이 시점에는 Seller를 조회하지 않는다.

하지만

product.getSeller().getName();

을 호출하는 순간 판매자를 조회하는 SQL이 실행된다.

장점

• 필요한 데이터만 조회하여 성능이 좋다.
• 실무에서 기본적으로 많이 사용된다.

단점

• 잘못 사용하면 N+1 문제가 발생할 수 있다.

2. EAGER (즉시 로딩)

부모 엔티티를 조회할 때 연관 엔티티도 함께 조회한다.

@ManyToOne(fetch = FetchType.EAGER)
private Seller seller;

상품을 조회하면 판매자를 사용하지 않아도 함께 조회한다.

장점

• 연관 엔티티를 바로 사용할 수 있다.

단점

• 필요 없는 데이터까지 조회할 수 있어 성능이 저하될 수 있다.
• 연관관계가 많아질수록 예상하지 못한 SQL이 실행될 수 있다.

@ManyToOne과 @OneToOne의 기본 FetchType은 EAGER이다. 실무에서는 대부분 LAZY로 변경하여 사용한다.

N+1 문제란?

LAZY 상태에서 부모 엔티티를 조회한 후 연관 엔티티를 반복해서 접근하면 추가 SQL이 계속 실행되는 문제이다.

예시

List<Product> products = productRepository.findAll();

for (Product product : products) {
    System.out.println(product.getSeller().getName());
}

실행되는 SQL

-- 1번
SELECT * FROM product;

-- 상품 개수만큼 반복
SELECT * FROM seller WHERE id = 1;
SELECT * FROM seller WHERE id = 2;
...

상품이 100개라면

• 상품 조회 : 1번
• 판매자 조회 : 100번

➡️ 총 101번의 SQL이 실행된다.

이를 N+1 문제라고 한다.

Fetch Join

Fetch Join은 연관 엔티티를 부모 엔티티와 함께 한 번에 조회하는 방법이다.

@Query("""
select p
from Product p
join fetch p.seller
""")
List<Product> findAllWithSeller();

실행되는 SQL

SELECT *
FROM product p
JOIN seller s
ON p.seller_id = s.id;

이후

product.getSeller().getName();

을 호출해도 추가 SQL이 발생하지 않는다.

즉,

• 상품 조회 + 판매자 조회를 한 번의 SQL로 처리한다.
• N+1 문제를 해결할 수 있다.

정리

사용 방식

• 기본은 LAZY를 사용한다.
• 연관 엔티티가 필요한 조회에서는 Fetch Join 또는 @EntityGraph를 사용한다.
• EAGER는 예기치 않은 성능 문제를 유발할 수 있어 일반적으로 권장되지 않는다.

1. ArrayList란?

ArrayList는 Java에서 가장 많이 사용하는 컬렉션(Collection) 중 하나로, 크기가 자동으로 늘어나고 줄어드는 동적 배열(Dynamic Array) 이다.

일반 배열(Array)은 크기를 한 번 정하면 변경할 수 없지만, ArrayList는 데이터를 추가하거나 삭제할 때 내부적으로 크기를 자동으로 조절해 준다.

예를 들어 일반 배열은 다음과 같이 크기를 미리 지정해야 한다.

int[] arr = new int[5];

반면 ArrayList는 크기를 지정하지 않아도 된다.

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

데이터를 계속 추가하면 내부적으로 더 큰 배열을 생성하고 기존 데이터를 복사하여 저장 공간을 늘려준다.

2. 왜 ArrayList를 사용할까?

예를 들어 회원 정보를 저장한다고 가정해보자.

배열을 사용하면

String[] users = new String[100];

100명을 초과하면 더 이상 저장할 수 없다.

하지만 ArrayList는

ArrayList<String> users = new ArrayList<>();

회원이 계속 추가되어도 자동으로 크기가 증가한다.

즉, 데이터 개수를 미리 알 수 없는 경우 ArrayList가 매우 유용하다.

3. 선언 방법

정수 저장

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

문자열 저장

ArrayList<String> list = new ArrayList<>();

사용자 객체 저장

ArrayList<User> users = new ArrayList<>();

4. 주요 메서드

1) add()

데이터를 추가한다.

ArrayList<String> list = new ArrayList<>();

list.add("Java");
list.add("Spring");
list.add("MySQL");

결과

[Java, Spring, MySQL]

특정 위치에 추가

list.add(1, "Python");

결과

[Java, Python, Spring, MySQL]

2) get()

특정 위치의 데이터를 가져온다.

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

출력

Java

3) set()

특정 위치의 데이터를 수정한다.

list.set(1, "JavaScript");

결과

[Java, JavaScript, Spring, MySQL]

4) remove()

인덱스로 삭제

list.remove(1);

값으로 삭제

list.remove("Spring");

5) contains()

데이터가 존재하는지 확인한다.

list.contains("Java");

결과

true

6) size()

저장된 데이터의 개수를 반환한다.

System.out.println(list.size());

5. 반복문으로 출력하기

일반 for문

for (int i = 0; i < list.size(); i++) {
    System.out.println(list.get(i));
}

향상된 for문

for (String language : list) {
    System.out.println(language);
}

6. ArrayList의 내부 동작

ArrayList는 내부적으로 배열(Array) 을 사용한다.

예를 들어

list.add("A");
list.add("B");
list.add("C");

메모리 구조는 다음과 같다.

Index
 0    1    2
+----+----+----+
| A  | B  | C  |
+----+----+----+

만약 저장 공간이 모두 찼는데 새로운 데이터를 추가하면

기존 배열

[A][B][C]

↓

더 큰 배열 생성

[A][B][C][ ][ ][ ]

새로운 배열을 생성한 뒤 기존 데이터를 복사하고, 마지막에 새로운 데이터를 추가한다.

7. 시간복잡도

왜 get()은 O(1)일까?

ArrayList는 내부적으로 배열을 사용한다.

배열은 메모리 공간에 연속적으로 저장되기 때문에 원하는 위치를 바로 계산하여 접근할 수 있다.

list.get(3);

처럼 특정 인덱스를 바로 조회할 수 있으므로 시간복잡도는 O(1) 이다.

왜 add(중간)은 O(N)일까?

예를 들어

[10][20][30][40]

여기에 15를 두 번째 위치에 삽입하면

[10][15][20][30][40]

이 되어야 한다.

이를 위해 기존의

• 20
• 30
• 40

을 한 칸씩 뒤로 이동해야 한다.

데이터를 이동하는 작업이 발생하기 때문에 시간복잡도는 O(N) 이다.

왜 remove(중간)도 O(N)일까?

예를 들어

[10][20][30][40]

에서 20을 삭제하면

[10][30][40]

가 되어야 한다.

이때 뒤에 있는 데이터들을 모두 앞으로 한 칸씩 이동해야 하므로 역시 O(N) 이다.

8. Array와 ArrayList 비교

9. 코딩테스트에서 ArrayList를 사용하는 경우

ArrayList는 다음과 같은 상황에서 자주 사용된다.

• 입력의 개수를 미리 알 수 없는 경우
• 그래프의 인접 리스트 구현
• 결과를 동적으로 저장해야 하는 경우
• BFS, DFS에서 인접 노드 저장
• 데이터를 순차적으로 관리해야 하는 경우

정리

• ArrayList는 크기가 자동으로 조절되는 동적 배열이다.
• 내부적으로 배열을 사용하며 필요할 때 더 큰 배열을 생성해 데이터를 복사한다.
• 조회(get)는 O(1)로 매우 빠르다.
• 중간 삽입(add)과 삭제(remove)는 데이터 이동이 발생하므로 O(N)이다.
• Java 실무와 코딩테스트에서 가장 많이 사용하는 컬렉션 중 하나이므로 반드시 익혀두는 것이 좋다.

1. String

특징

• 문자열을 저장하는 객체
• 문자열을 수정하면 새로운 객체가 생성됨

String str = "Hello";
str += " World";

기존 문자열이 수정되는 것이 아니라 새로운 String 객체가 만들어진다.

자주 사용하는 메서드

1. length()

문자열 길이 반환

String str = "Hello";

System.out.println(str.length()); // 5

시간복잡도 : O(1)

2. charAt(index)

특정 위치 문자 반환

String str = "Hello";

System.out.println(str.charAt(1)); // e

시간복잡도 : O(1)

3. substring()

문자열 자르기

String str = "Hello";

System.out.println(str.substring(1));     // ello
System.out.println(str.substring(1,4));   // ell

• 시작 포함
• 끝 미포함

4. indexOf()

문자의 위치 찾기

String str = "banana";

System.out.println(str.indexOf("a")); // 1
System.out.println(str.indexOf("z")); // -1

없으면 -1 반환

5. contains()

포함 여부 확인

String str = "Hello";

System.out.println(str.contains("ell")); // true

반환형 : boolean

6. equals()

문자열 비교

String a = "abc";
String b = "abc";

System.out.println(a.equals(b));

※ == 사용 금지

7. split()

문자열 분리

String str = "A,B,C";

String[] arr = str.split(",");

결과

A
B
C

8. replace()

문자 변경

String str = "Hello";

System.out.println(str.replace("l","x"));

출력

Hexxo

9. toUpperCase()

대문자 변환

str.toUpperCase();

10. toLowerCase()

소문자 변환

str.toLowerCase();

String에서 자주 나오는 코테 패턴

• 문자 하나씩 탐색(charAt)
• 문자열 자르기(substring)
• 문자열 비교(equals)
• 문자열 포함 여부(contains)
• 문자열 분리(split)
• 특정 문자 찾기(indexOf)
• 대소문자 변환

StringBuilder

특징

• 문자열 수정이 많을 때 사용
• String보다 훨씬 빠름
• 가변(Mutable)

생성

StringBuilder sb = new StringBuilder();

또는

StringBuilder sb = new StringBuilder("Hello");

append()

문자열 추가

sb.append("A");
sb.append("B");

결과

AB

insert()

문자 삽입

sb.insert(1,"X");

ABC

↓

AXBC

delete()

삭제

sb.delete(1,3);

• 시작 포함
• 끝 미포함

deleteCharAt()

한 글자 삭제

sb.deleteCharAt(2);

replace()

문자 변경

sb.replace(1,3,"AB");

reverse()

문자열 뒤집기

sb.reverse();

코테에서 매우 자주 사용

setCharAt()

특정 문자 변경

sb.setCharAt(2,'A');

charAt()

특정 문자 조회

sb.charAt(1);

toString()

StringBuilder → String 변환

String result = sb.toString();

String vs StringBuilder

코테에서 언제 사용할까?

String

• 문자열 비교
• 문자열 자르기
• 문자 탐색
• split 사용

StringBuilder

• 문자열 이어붙이기
• 문자열 뒤집기(reverse)
• 문자열 수정
• 반복문에서 문자열 생성

꼭 외워야 하는 메서드

String

• length()
• charAt()
• substring()
• equals()
• contains()
• split()
• indexOf()
• replace()
• toUpperCase()
• toLowerCase()

StringBuilder

• append()
• insert()
• delete()
• deleteCharAt()
• replace()
• reverse()
• setCharAt()
• charAt()
• toString()

@GetMapping("/create")
public String create(QuestionForm questionForm) {
    return "question_form";
}

// 내부적으로는 아래와 같은 코드와 동일하게 작동함:
model.addAttribute("questionForm", new QuestionForm());

2. 수동 바인딩 방식 (Model 이용)

@GetMapping("/create")
public String create(Model model) {
    model.addAttribute("questionForm", new QuestionForm());
    return "question_form";
}

3. 명시적 @ModelAttribute 방식

@GetMapping("/create")
public String create(@ModelAttribute("questionForm") QuestionForm form) {
    return "question_form";
}

= 같은 곳에 유효성 검사를 추가하면 코드 중복이 발생한다.

• 도메인 지식 같은 경우 -> Domain(Entity)에 유효성 검사를 해야한다.

• 도메인 지식과 무관하게 데이터 그 자체가 유효한가에 대한 검사 -> DTO에서 해야한다.

  @Getter
  @Setter
  @Entity
  public class Food {
   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Integer id;// 고유 번호
  
   @Column(length = 50)
   @Size(max = 50)
   private String foodname; // 식품명
  
   @Column(length = 30)
   @Size(max = 30)
   private String kind; // 종류
  
   private List<String> createDate;//날짜
  
   private String storageArea; // 구역
  
  
  

private LocalDateTime modifyDate; // 최종 수정 날짜

@ManyToOne// 작성자와의 관계 설정
private SiteUser siteuser;

private String imagePath; //이미지 경로

}

```

• @Size를 추가하여 유효성 검사를 추가했다.

  @Getter
  @Setter
  @Entity
  public class FoodFormDto {
   @NotEmpty(message="식품 이름은 필수 항목입니다.")
   @NotNull
   private String foodName;
  
   @NotEmpty(message="식품 종류 선택은 필수 항목입니다.")
   @NotNull
   private String kind;
  
   @NotEmpty(message="유통기한은 필수 항목입니다.")
   @NotNull
   private List<String> createDate;//날짜
  
   @NotEmpty(message="영역은 필수 항목입니다.")
   @NotNull
   private String storageArea;
  

• 입력 폼에 대한 @NotEmpty @NotNull을 이용하여 유효성 검사를 추가했다.

- Data Transfer Object란 의미로 폼에서 전달받은 데이터를 객체로 변환하는것.

• dto로 받은 데이터는 최종적으로 데이터베이스로 저장.

1. 데이터를 form을 통해 Post 요청으로 데이터를 요청.

• 폼 데이터를 전송 받아 DTO 객체에 담아야한다. -> post 요청
• 폼 데이터를 DTO에 담기 -> 컨트롤러에 매개 변수로 담는다.
• 폼과 DTO 필드를 연결하자 -> 타임리프를 통해 mapping
• DTO를 데이터베이스에 저장하자 -> DTO를 엔티티로 변환하자.
• repository로 엔티티를 db에 저장하자 -> repository.save(Entity);

// foodcreate_form.html

<form class="container" action="/api/food" method="post">
 <div class="mb-3">
            <label for="foodName" class="form-label">식품명</label>
            <input type="text" name="foodName" id="foodName" class="form-control" placeholder="ex) 버터 치킨 카레">
</div>
<div class="mb-3">
            <label for="createDate" class="form-label">유통 기한</label>
            <input type="text" name="createDate" id="createDate" class="form-control" placeholder="ex) 25/01/01">
</div>
</form>

  DTO

public class FoodFormDto{

private String foodName;
private String createDate;

// 전송 받은 이름과 날짜를 저장하는 생성자 추가
public foodFormDto(String foodName,String createDate){ 
this.foodName = foodName;
this.createDate = createDate;
}
// dto를 entity로 변환
public Food toEntity(){
return new food(null,foodName,createDate);
}

@Controller
public class foodcontroller(FoodFormDto foodFormDto){
@Gemapping("/api/food")
public String create(FoodFormDto foodFormDto){
Food food = foodFormDto.toEntity();
this.foodrepository.save(food);

}

@Entity
public class Food{
@Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;// 고유 번호

    @Column(length = 50)
    private String foodname; // 식품명

    private String createDate; // 제조일자
}

public Food(String foodname,String createDate){
this.foodname = foodname;
this.createDate = createDate;
}

1. 개요

본 문서는 Spring Boot 3 기반의 유통기한 기록, 문의사항, 보충 리스트 관리 웹/모바일 반응형 웹사이트 구축에 대한 설계 과정, MVC 패턴 적용, 요구사항 정의한다.

2. 시스템 설계

2.1 아키텍처

• 프론트엔드: 반응형 디자인 (BootStrap)
• 백엔드: Spring Boot 3 (RESTful API), Spring Data JPA (데이터베이스 연동), Thymeleaf (서버 사이드 렌더링)
• 데이터베이스: MySQL 또는 H2 (개발 환경)
• 웹 스토리지: HTML5 Web Storage (localStorage 또는 sessionStorage)

  2.2 MVC 패턴

• Model: 데이터베이스 엔티티 (Entity) 및 데이터 처리 로직 (Service)
• View: Thymeleaf 템플릿 (웹 페이지)
• Controller: RESTful API 엔드포인트, 웹 페이지 요청 처리

  2.3 주요 기능

• 유통기한 기록: 제품별 유통기한 등록, 수정, 삭제, 조회
• 문의사항 관리: 사용자 문의 등록, 답변, 조회
• 보충 리스트 관리: 유통기한 기반 보충 필요 제품 목록 생성, 보충 수량 기록, 웹 스토리지 연동

3. 요구사항 정의

3.1 기능 요구사항

<1> 식품 리스트 관리

• 제품 정보 (제품명, 유통기한, 종류) 등록/수정/삭제
• 제품 정보 검색 기능
• 페이징 기능
• 유통기한 임박/만료 제품 목록 조회 < 변경 UI >
• 카드로 제품들을 정리

<2> 보충 리스트

• 보충 리스트 관리
• 현장에서 보충 수량 입력으로 웹 스토리지 저장
• 보충 완료 목록 조회
• 보충 이력 조회
• 리스트 검색 기능

  <3> 문의 사항

• 문의사항 관리
• 사용자 문의 등록 (제품, 문의 내용)
• 관리자 답변 등록
• 문의 목록 조회 (사용자, 관리자)
• 문의 검색 기능 (제품, 내용)

3.2 비기능 요구사항

• 반응형 디자인: 다양한 기기 (PC, 태블릿, 모바일) 지원
• 성능: 빠른 응답 속도, 대용량 데이터 처리
• 보안: 사용자 인증/인가, 데이터 암호화
• 사용성: 직관적인 UI/UX, 쉬운 사용법
• 확장성: 새로운 기능 추가 용이
• 유지보수성: 코드 가독성, 유지보수 용이

4. 개발 과정

• 요구사항 분석 및 설계: 기능 요구사항, 비기능 요구사항 정의, 시스템 아키텍처 설계
• 데이터베이스 설계: ERD 작성, 테이블 설계
• 백엔드 개발: Spring Boot 3, Spring Data JPA, RESTful API 개발
• 프론트엔드 개발: BootStrap -> 반응형 디자인 적용
• 웹 스토리지 연동: 보충 리스트 데이터 웹 스토리지 저장/관리
• 테스트: 단위 테스트, 통합 테스트, 시스템 테스트
• 배포: 서버 배포, 운영 환경 설정
• 유지보수: 버그 수정, 기능 개선, 성능 최적화

5. 기술 스택

• Spring Boot 3: 백엔드 프레임워크
• Data JPA: 데이터베이스 연동
• Thymeleaf: 서버 사이드 렌더링
• Bootstrap: 반응형 디자인 프레임워크
• MySQL/H2: 데이터베이스
• HTML5 Web Storage: 웹 스토리지

6. 문서화

• 요구사항 정의서
• 시스템 설계서
• 데이터베이스 설계서
• API 명세서
• 테스트 계획서
• 사용자 매뉴얼

스프링 컨테이너 생성

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext -> 스프링 컨테이너이자 인터페이스
• 스프링 컨테이너 xml기반,Annotation을 기반으로 자바 설정 클래스로 만들 수 있다.

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성

• 스프링 컨테이너에 (key : 빈이름(메소드명),value : 빈 객체(메소드 반환명 impl)
• 구성 정보 = AppConfig.class
• 이러한 구성 정보를 지정하고 활용한다.

2. 스프링 빈 등록

• 빈 이름은 메서드 이름 사용.
• 빈 이름 직접 부여 가능

  @Test
  @Bean(name:'sprintHi')
  public ~~

3.스프링 빈 의존관계 설정(DI)

• 메소드의 반환값을 의존하는 메서드로 입력.

  @Bean
  public MemberService memberService(){
  return new MemberServiceImpl(memberRepository());
  }
  

@Bean public MemberRepository memberRepository(){ return new MemberMeberRepository(); }

### 컨테이너에 등록된 모든 빈 조회
-> 스프링 컨테이너에 등록한 빈들이 잘 등록 되었는가?
1. 내부 bean + 등록한 bean 출력
2. 내부 bean만 출력

### 스프링 빈 조회 방법
1. ac.getBean(빈이름,타입)
2. ac.getBean(타입)
3. 예외발생시(NoSuchBeanDefinitionException) 예외를 사용하여 조회

### 스프링 빈 조회 - 동일한 타입이 둘 이상일때
- 같은 타입의 스프링 빈일때 오류 발생 -> 빈이름 저장하여 조회
- ac.getBeansOfType() -> 모든 빈 조회 가능

정의: 분할정복 방식을 사용해 데이터를 분할하고 분할한 집합을 합치는 알고리즘이다.

• 시간 복잡도는 O(nlogn)

• 배열의 크기를 n이라 할때, 분할 할때 마다 배열의 크기가 n/2씩 감소. 이때 분할하는데 걸리는 시간은 O(log n)

• 정복(합병)할때 마다 두 배열을 비교하면서 작은 요소부터 차례로 결과 배열에 추가. 이 과정에서 최대 (n)개의 요소를 비교하게 되므로, 두 개의 배열을 합치는 데 걸리는 시간은 O(n)

• 대량의 데이터 정렬에 주로 사용.

public class sort {
    public static void merge(int A[], int low, int mid, int high) {
        //정렬할게요.
        int B[] = new int[high + 1];
        int h = low; //임시 배열 B의 low.
        int i = low; //배열 A의 low
        int j = mid + 1; // 배열 A의 mid +1
        int k;

        while (i <= mid && j <= high) {
            if (A[i] < A[j]) {
                B[h] = A[i]; //작은 놈이 임시 배열 low 지수에 저장.
                i++; // 왼쪽 배열 포인터 증가
            } else{
                B[h] = A[j];
                j++;// 오른쪽 배열 포인터 증가
            }
            h++; //임시배열도 저장할 포인터를 1만큼 증가.
        }

        // 비교할게 없다면?
        if (i > mid) { // 오른쪽 배열을 싹다 대입.
            for (k = j; k <= high; k++) {
                B[h] = A[k];
                h++;
            }
        }else { // 왼쪽 배열을 싹다 임시배열 B에 대입.
            for (k = i; k <= mid; k++) {
                B[h] = A[k];
                h++;
            }
        }

        /*while (i <= mid) {
            B[h] = A[i];
            i++;
            h++;
        }
        while (j <= high) {
            B[h] = A[j];
            j++;
            h++;
        }

         */

        for (k = low; k<=high; k++) {
            A[k] = B[k];
        }
    }

    public static void printArray(int A[]) {
        for (int i = 0; i < A.length; i++) {
            System.out.print(A[i] + " ");
        }
    }

    public static void mergeSort(int A[], int low, int high) { //합병할게요
        if (low < high) {
            int mid = (low+high) /2;
            mergeSort(A,low,mid);
            mergeSort(A,mid+1,high);
            merge(A,low,mid,high);
        }
    }

    public static void main(String[] args) {
        int A[] = {91, 82, 13, 85, 68, 70, 98, 24};
        System.out.println("정렬전");
        printArray(A);
        System.out.println("정렬후");
        mergeSort(A,0,A.length-1);
        printArray(A);
    }
}

정의 : 분할정복 알고리즘으로 부분적으로 나누어가면서 정렬하는 방법.

• 시간 복잡도 최악: O(n^2) 평균: O(n*logn)

• java에서 Arrays.sort()로 사용한다.

Quick Sort 실행 방식

1. 배열을 두 부분으로 나눈다. i) 배열 내 기준 요소보다 작으면 앞부분 배열에 위치, 크면 뒷부분 배열에 위치한다.

2. 각 분할된 부분을 재귀적으로 정렬한다.

package javastudy;

public class quickSort {
  public static void qs(int a[], int low, int high) {
    if (low < high) {
      int s = partition(a, low, high); // 기준 pivot
      qs(a, low, s - 1); // 왼쪽 배열
      qs(a, s + 1, high); // 오른쪽 배열
    }
  }

  public static int partition(int a[], int low, int high) {
    int pivot = a[low]; // 피벗을 배열의 첫 번째 요소로 설정
    int i = low + 1;
    int j = high;

    while (i <= j) {
      while (i <= high && a[i] <= pivot) {
        i++;
      }
      while (j >= low && a[j] > pivot) {
        j--;
      }
      if (i < j) { // i가 j보다 작을 때만 교환
        int tmp = a[i];
        a[i] = a[j];
        a[j] = tmp;
      }
    }
    // 피벗을 올바른 위치에 배치
    a[low] = a[j];
    a[j] = pivot;

    return j; // 피벗의 최종 위치 반환
  }

  public static void printArray(int a[]) {
    for (int num : a) {
      System.out.print(num + " ");
    }
    System.out.println(); // 배열 출력 후 줄바꿈
  }

  public static void main(String[] args) {
    int a[] = {8, 5, 6, 2, 4};
    printArray(a);
    qs(a, 0, a.length - 1); // 배열의 크기를 사용하여 인덱스 설정
    printArray(a);
  }
}

정의 : 자신의 위치를 찾아 삽입하는 정렬 알고리즘.

• 정렬된 부분 (A[0]), 정렬 되지 않은 부분 (A[1] ... A[n-1])으로 구분하여 정렬.
• 시간복잡도 : O(n^2)

package javastudy;

public class insertSort {
  public static void is(int a[]) {
    int n = a.length;
    for (int i = 1; i < n; i++) {
      int insertionKey = a[i]; // 삽입할 현재 요소
      int j = i - 1;

      while (j >= 0 && a[j] > insertionKey) {
        a[j+1] = a[j]; // 한칸 뒤로
        j = j-1; // 왼쪽 index로 이동
      }
      a[j+1] = insertionKey; // 현재 요소 삽입
    }
  }

  public static void printArray(int a[]) {
    for (int num : a) {
      System.out.print(num+ " ");
    }
  }

  public static void main(String[] args) {
    int A[] = {8, 5, 6, 2, 4};
    System.out.println("정렬 전");
    printArray(A);
    System.out.println("정렬 후");
    is(A);
    printArray(A);
  }
}

정의 : 전체 배열에서 가장 작은 요소를 찾고, 그 요소를 첫번째 요소와 교환하는 정렬.

• 시간 복잡도 : O(n^2)

package javastudy;

public class selectionSort {
  public static void ss(int a[]) {
    int n = a.length;


    for (int i = 0; i < n - 1; i++) {
      int min = i;
      for (int j = i+1; j < n; j++) {
        if (a[min] > a[j]) {
          min = j;
        }
      }
        if (min != i) {
          int tmp = a[i];
          a[i] = a[min];
          a[min] = tmp;
        }

    }
  }

  public static void printArray(int a[]) {
    for (int num : a) {
      System.out.print(num+" ");
    }
  }

  public static void main(String[] args) {
    int A[] = {8, 5, 6, 2, 4};
    System.out.println("정렬 전");
    printArray(A);
    System.out.println("정렬 후");
    ss(A);
    printArray(A);

  }

}