1) 정규형 개념 (1NF ~ 3NF)

• 1NF(제1 정규형) : 모든 컬럼 값은 원자값(하나의 값)이어야 한다.
  • 2NF(제2 정규형) : 1NF + 부분 함수 종속 제거
  • 3NF(제3 정규형) : 2NF + 이행적 종속 제거

함수 종속 : X → Y는 “X가 정해지면 Y가 하나로 정해진다”는 의미

2) “주문” 테이블을 1NF → 2NF → 3NF로 분해

2-1. 비정규형(UNF) 예시

UNF_주문 (문제: 한 칸에 상품목록이 여러 개 들어감)

문제점

• 상품목록이 다중 값(리스트) → 1NF 위반
• 특정 상품 수량만 수정/삭제하기가 까다로움

2-2. 1NF 적용 (원자값으로 “행을 풀기”)

상품목록을 행으로 풀어 주문-상품 라인 아이템 형태로 만든다.

1NF_주문라인(임시)

• 각 컬럼은 원자값 → 1NF 만족
• 하지만 아직 중복이 많고(고객명/주소, 상품명/가격 반복) 규칙(함수 종속)에 어긋나는 구조가 남아 있다.

키(Primary Key) 가정

• 이 테이블의 PK를 (주문ID, 상품ID)로 잡으면 “한 주문에서 같은 상품은 한 번만 등장”한다고 가정할 수 있다.

2-3. 2NF 적용 (부분 함수 종속 제거)

(1) 현재 함수 종속(FD) 예시

• (주문ID, 상품ID) -> 수량
• 주문ID → 고객ID, 고객명, 고객주소 주문ID(키 일부)에만 의존
• 상품ID → 상품명, 상품가격 상품ID(키 일부)에만 의존

즉 PK가 복합키 (주문ID, 상품ID)인데,

• 고객 관련 컬럼은 주문ID만으로 결정
• 상품 관련 컬럼은 상품ID만으로 결정
  → 부분 함수 종속이므로 2NF 위반

(2) 2NF 분해 결과

부분 종속되는 속성을 각각의 테이블로 분리한다.

(A) Orders_2NF (주문)

(B) Products_2NF (상품)

(C) OrderItems_2NF (주문 상세)

이제 상품명/가격은 Products로, 고객명/주소는 Orders로 이동하여 2NF 만족

2-4. 3NF 적용 (이행적 종속 제거)

2NF까지 끝냈는데도 Orders_2NF 안을 보면:

• 주문ID → 고객ID
• 고객ID → 고객명, 고객주소 (고객ID가 고객 정보를 결정)
• 결과적으로 주문ID → 고객명, 고객주소가 이행적(간접)으로 성립

즉 주문ID → 고객ID → 고객명/주소 구조가 남아 있어 3NF 위반

3NF 분해 결과

고객 정보를 별도 테이블로 분리하고, 주문은 고객ID만 참조하도록 만듭니다.

(A) Customers_3NF (고객)

(B) Orders_3NF (주문)

(C) Products_3NF (상품) (2NF와 동일)

(D) OrderItems_3NF (주문 상세) (2NF와 동일)

이제 주문 테이블에는 “주문 자체”의 속성만 남고, 고객/상품 정보는 각 마스터 테이블에만 존재 → 3NF 만족한다.

1. 이슈 작성 목적

GitHub Issues는 다음과 같은 상황에서 사용된다.

• 새로운 기능(Feature) 구현
• 버그(Bug) 리포트 및 해결
• 리팩토링, 테스트 코드, 문서화 작업 요청
• 작업을 세분화하여 프로젝트 관리 효율 극대화
• 협업 시 작업 중복 방지 및 진행 상태 공유

2. 이슈 기본 구성 요소

✔ 1) 이슈 제목(Title)

• 간결하게 핵심을 담아쓰기
• [Feature] WebSocket 메시지 읽음 처리
• [Bug] JWT Refresh Token 검증 실패
• [Refactor] MemberService 비밀번호 검증 로직 개선 등등

✔ 2) 라벨(Label)

이슈의 성격을 빠르게 파악하기 위해 라벨을 적용합니다.

추천 라벨:

• feature
• bug
• refactor
• docs
• test
• hotfix
• enhancement

✔ 3) 본문(Body)

이슈 설명은 아래 4가지를 기본으로 구성합니다.

(1) Summary — 이슈 개요

이 이슈가 무엇을 위한 것인지 한 문장으로 설명합니다.

WebSocket 기반 채팅에서 메시지 읽음 처리 기능을 구현한다.

(2) Detail — 상세 설명

현재 상태와 해결해야 할 목표 상태를 구체적으로 작성합니다.

현재 메시지를 읽어도 읽음 상태가 서버에 저장되지 않아 다른 사용자에게 반영되지 않는다.
채팅방별로 유저의 lastReadMessageId 값을 저장하고 이를 기반으로 읽음 처리를 구현해야 한다.

(3) Acceptance Criteria — 완료 조건

개발이 끝났음을 판단할 수 있는 체크리스트를 작성합니다.

- [ ] 사용자가 채팅방을 구독하면 마지막 메시지 ID를 전달한다.
- [ ] 서버는 lastReadMessageId 계산 후 DB 또는 캐시에 저장한다.
- [ ] 읽음 상태를 WebSocket 이벤트로 전달한다.
- [ ] 명세서(ws-api.md)에 읽음 처리 플로우가 추가된다.

(4) Reference — 참고 자료

관련 문서, ERD, API 명세, PR 링크 등을 포함하면 큰 도움이 됩니다.

- ERD: /docs/chat_erd.png
- API 명세서: /docs/websocket-api.md
- 관련 PR: #23

3. 이슈 세분화 기준

큰 기능 단위는 반드시 작은 이슈들로 나누는 것이 좋습니다.
기능을 잘게 쪼개면 아래 장점이 있습니다:

• PR 크기가 작아져 리뷰가 쉬움
• 트러블슈팅이 쉬워짐
• 작업 책임 범위가 명확해짐
• 일정 관리 가능 (칸반 보드에서 트래킹하기 쉬움)

예: 채팅 서비스 기능 세분화

Polling (Short Polling)

HTTP 기반 가장 단순한 실시간 통신 방식

작동 방식

클라이언트가 일정 주기마다 반복적으로 HTTP 요청을 보냄
→ "새 데이터 있어?" → 서버는 즉시 응답

장점

• 구현이 매우 쉽다 (타이머 사용)
• 별도 서버 설정 없음 — 기존 HTTP로 끝

단점

• 데이터가 없어도 계속 요청 → 트래픽 낭비
• 실시간성이 떨어짐
  (데이터가 0.1초 전에 생겨도 다음 요청 때까진 모름)

Long Polling

Polling의 단점을 보완한 방식

작동 방식

1. 클라이언트가 HTTP 요청을 보냄
2. 서버는 데이터가 생길 때까지 연결 유지
3. 데이터 발생 시 응답 후 연결 종료
4. 클라이언트는 다시 요청 보내며 반복

장점

• Short Polling보다 훨씬 효율적
• 실시간성과 비슷한 수준으로 동작

단점

• 데이터가 너무 자주 발생하면
  연결을 계속 끊고 새로 맺어야 하므로 비효율
• 완전한 실시간 스트리밍 수준은 아님

SSE (Server-Sent Events)

HTTP 기반 실시간 단방향(Server → Client) 스트리밍

작동 방식

1. 클라이언트가 서버에 “구독 요청(EventSource)”
2. 서버가 연결을 유지한 채 필요할 때마다 이벤트 Push
3. 클라이언트는 받기만 가능 (단방향)
4. 서버로 데이터 보내려면 일반 HTTP 요청 사용

장점

• WebSocket보다 구현이 간단
• 자동 재연결, 이벤트 스트림 기반
• HTTP 인프라 그대로 사용 가능 (프록시, 로드밸런서 친화적)
• 단방향 실시간에 매우 적합

단점

• 클라이언트 → 서버 방향은 지원 X
• 다량의 양방향 실시간 통신에는 부적합

언제 쓰면 좋을까?

WebSocket

클라이언트 ↔ 서버 간 양방향 실시간 통신

작동 방식

• 최초 한번 HTTP 기반 Handshake
• 이후 HTTP가 아닌 WebSocket 프로토콜로 전환
• 양방향/연결 유지 상태에서 바로 전송

장점

• 완전한 실시간
• 양방향 통신
• 메시지 헤더가 가벼워 효율적

단점

• 서버 구현 난이도 ↑
• 상태를 유지해야 하므로 관리 비용 ↑
• 프록시/로드밸런서 환경에서 설정 필요

기술 비교 요약표

어떤 상황에서 무엇을 사용할까?

결론

실시간 처리의 핵심: 양방향 통신

웹소켓(WebSocket)은 서버와 클라이언트가 동시에 데이터를 주고받을 수 있는 기술입니다.
전화 통화 방식과 매우 비슷한 구조를 가집니다.

전화 통화에 비유한 실시간 통신

한 번 연결되면 끊기 전까지 계속 유지되고, 양방향으로 실시간 통신이 가능하다.

WebSocket(WS) 프로토콜이란?

WebSocket은 기존 HTTP 요청을 기반으로 프로토콜을 업그레이드하여 실시간 양방향 통신을 수행하는 기술입니다.
HTTP를 대체하는 것이 아니라 HTTP에서 출발하여 WebSocket으로 변경(Upgrade) 되는 개념입니다.

WebSocket URL

WebSocket 작동 원리

1. Handshake (HTTP 업그레이드 요청)

초기 요청은 HTTP GET 으로 전송됩니다.

📌 Client

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: (랜덤 키)
Sec-WebSocket-Version: 13

📌 Server

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: (계산된 응답 키)

➡ 의미:
"HTTP로 만나서 WebSocket으로 대화하자" 라는 합의 완료.

2. 프로토콜 전환 (Connection Open)

HTTP → WebSocket 으로 변경되고 연결이 유지됩니다.

🔹 HTTP

• 요청 후 응답하면 연결 종료

🔹 WebSocket

• 연결을 유지하고, 끊기 전까지 계속 사용 (Stateful)

3. 양방향(Full Duplex) 실시간 통신

📌 주요 사용 사례

• 채팅 시스템
• 실시간 알림
• 온라인 게임
• 주식/코인 시세 전송
• 실시간 지도/위치 공유

TCP란 무엇인가?

WebSocket은 TCP 위에서 동작합니다.
TCP는 인터넷의 안전하고 정확한 배송 서비스라고 할 수 있습니다.

TCP의 3가지 핵심 특징

TCP 연결 과정 — 3-Way Handshake

➡ 이후 데이터 전송이 시작됩니다.

WebSocket과 TCP의 관계

📌 WebSocket이 실시간 통신을 효율적으로 수행할 수 있는 이유
→ TCP가 순서 보장 + 신뢰성 + 연결 유지를 제공하기 때문입니다.

WebSocket이 필요한 이유 정리

결론

• WebSocket은 HTTP 요청에서 시작하여 WebSocket으로 업그레이드된다.
• WebSocket은 TCP의 연결 위에서 실시간 양방향 통신을 제공한다.
• 실시간 정보 업데이트가 필요한 모든 시스템의 핵심 기술이다.

2025.11.19

1. Spring Security의 필요성

표준화된 단일 인증/인가 체계 제공

• ID/Password, OAuth, JWT 등 다양한 인증 방식을 통합적으로 지원

세션 및 토큰 관리 기능 제공

• 세션 기반 인증 / JWT 기반 인증 모두 지원

암호화와 비밀번호 보안 강화

• BCrypt 같은 강력한 해시 알고리즘으로 비밀번호를 안전하게 저장

권한 제어 기능 제공

• URL 단위, Method 단위(@PreAuthorize)에서 Role 기반 접근 제어

웹 보안 취약점 방어

• CSRF 토큰 자동 생성
• 로그인 성공 시 세션ID 자동 재발급 → CSRF, 세션 고정 공격 방어

2. 인증(Authentication) / 인가(Authorization)

• 인증(Authentication): 사용자가 누구인지 식별하는 과정
• 인가(Authorization): 인증된 사용자가 특정 자원에 접근 가능한지 확인하는 과정

3. 세션 기반 인증 vs 토큰 기반 인증(JWT)

4. 인증 → 인가 → 응답 처리 흐름

1. 클라이언트에서 요청이 들어오면 Spring Security FilterChain을 통과
2. UsernamePasswordAuthenticationFilter가 ID/PW 추출
3. AuthenticationManager가 UserDetailsService로 사용자 정보 검증
   • 성공 → Authentication 객체 생성 후 SecurityContext에 저장
   • 실패 → ExceptionTranslationFilter가 401 처리
4. FilterSecurityInterceptor가 권한 확인
   • 권한 없음 → 403 반환
   • 권한 있음 → Controller로 전달
5. Controller에서 정상 응답 반환

5. Spring Security 구조

Security Filter Chain

• 요청 URL에 매칭되는 필터 체인이 선택되어
  여러 보안 필터가 순서대로 인증/인가 처리

DelegatingFilterProxy

• 서블릿 컨테이너 필터
• 실제 보안 처리는 FilterChainProxy로 위임하는 브릿지 역할

FilterChainProxy

• 요청과 매칭되는 SecurityFilterChain 선택 및 실행

6. 주요 동작 필터

UsernamePasswordAuthenticationFilter

• 로그인 요청에서 사용자명/비밀번호 추출
• 인증 성공 시 Authentication 생성 → SecurityContext 저장

ExceptionTranslationFilter

• 인증 실패(401), 접근 거부(403) 예외 처리

FilterSecurityInterceptor

• 최종 권한 체크
• 접근 가능 여부 결정

7. 주요 컴포넌트

AuthenticationManager

• 로그인 요청 검증
• Authentication 객체 반환

UserDetailsService

• DB에서 사용자 정보 조회
• 비밀번호 검증

SecurityContext

• 인증된 사용자 정보를 저장
• 요청마다 SecurityContextHolder로 관리

8. 요청 흐름 (Spring Boot)

1. 클라이언트가 /login으로 인증 요청 (ID/PW)
2. DelegatingFilterProxy가 요청을 Security Filter Chain으로 전달
3. UsernamePasswordAuthenticationFilter가 ID/PW 추출 후
   AuthenticationManager에게 인증 위임
   • 내부적으로 AuthenticationProvider →
     UserDetailsService + PasswordEncoder 사용
4. 인증 성공 → Authentication 생성 → SecurityContext 저장
   인증 실패 → ExceptionTranslationFilter가 401 응답 처리
5. FilterSecurityInterceptor가 URL/메서드 권한 체크
   • 권한 없음 → 403
6. 권한 통과 후 Controller → Response 반환

2025.11.03

1) Builder란

1.1 문제 상황: 텔레스코핑 생성자(파라미터 폭탄)

// 나쁨: 어떤 값이 무엇인지, 순서를 외우기 어렵다
new Product("MacBook", "M3 Max", 3890000, 20, "노트북", null);

• 가독성↓: 인자의 의미가 불명확
• 안전성↓: 순서 실수 시 컴파일이 통과해도 런타임 버그
• 옵셔널 필드가 많아질수록 생성자가 폭발

1.2 해결: Builder 패턴

• 필드명을 키로 값을 채워 넣음 -> 가독성↑, 안전성↑
• 옵셔널은 필드만 선택적으로 넣을 수 있음
• 불변 DTO 조합에 적합하다

@Getter
@Builder
public class ProductDto {
    private final String name;
    private final String description;
    private final int price;
    private final int stockQuantity;
    private final String category;
    private final String imageUrl;
}

// 사용
ProductDto dto = ProductDto.builder()
    .name("MacBook Pro 17")
    .description("M3 Max 칩")
    .price(3_890_000)
    .stockQuantity(20)
    .category("노트북")
    .imageUrl("https://...")
    .build();

2) Lombok @Builder 핵심 옵션

2.1 사용법

• DTO: 클래스 레벨 @Builder 권장 (불변 DTO 지향)
• 엔티티(JPA):
  • @NoArgsConstructor(protected) + 빌더 생성자에 @Builder 붙이기 권장
  • 무분별한 필드 세터보다 의미 있는 생성 경로를 제공

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "products")
public class Product extends BaseTimeEntity {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable=false) private String name;
    @Column(nullable=false) private String description;
    @Column(nullable=false) private int price;
    @Column(nullable=false) private int stockQuantity;
    @Column(nullable=false) private String category;
    private String imageUrl;

    @Builder // ← 생성자에 붙여 의도된 생성 흐름 강제
    private Product(String name, String description, int price, int stockQuantity,
                    String category, String imageUrl) {
        this.name = name;
        this.description = description;
        this.price = price;
        this.stockQuantity = stockQuantity;
        this.category = category;
        this.imageUrl = imageUrl;
    }
}

2.2 자주 쓰는 추가 기능

• @Builder.Default : 빌더 미지정 시 기본값 유지

  @Builder
  public class ItemDto {
      @Builder.Default
      private String status = "ACTIVE"; // builder().build() 시에도 ACTIVE 유지
  }

• @Singular : 컬렉션 필드를 addXxx() 식으로 누적

  @Singular
  private List<String> tags; // .tag("a").tag("b").build()

• toBuilder=true : 기존 객체를 복제 후 일부만 변경

  ItemDto changed = original.toBuilder().status("PAUSED").build();

2.3 JSON·검증과의 궁합

• DTO는 @Getter 필수 (JSON 직렬화용)
• 요청 DTO는 @NotNull, @Positive 등 Bean Validation으로 선제 검증\
• 엔티티를 직렬화 대상에 직접 쓰지 말고 DTO로 분리 (N+1, 순환참조 방지)

3) from()이란

3.1 정의

• 정적 팩토리 메서드로, 보통 엔티티 → DTO 변환 로직을 한 곳에 모아둠.
• 서비스/컨트롤러에서 변환 코드를 흩뿌리지 않고 캡슐화.

@Getter
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class PostProductResponse {
    private Long id;
    private String name;
    private String description;
    private int price;
    private int stockQuantity;
    private String category;
    private String status;
    private String imageUrl;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
    private String message;
    private String warning;

    public static PostProductResponse from(Product p, String message, String warning) {
        return PostProductResponse.builder()
            .id(p.getId())
            .name(p.getName())
            .description(p.getDescription())
            .price(p.getPrice())
            .stockQuantity(p.getStockQuantity())
            .category(p.getCategory())
            .status(p.getStockQuantity() > 0 ? "AVAILABLE" : "OUT_OF_STOCK")
            .imageUrl(p.getImageUrl())
            .createdAt(p.getCreatedAt())
            .updatedAt(p.getUpdatedAt())
            .message(message)
            .warning(warning)
            .build();
    }
}

3.2 DTO에서 사용하는 이유

• 중복 제거: 변환 규칙을 한 곳에서 관리
• 변경 용이: 필드 추가/명 변경 시 from()만 수정하면 전역 반영
• 테스트 용이: 변환 규칙 단위 테스트 가능

4) 설계 방법

1. DTO는 불변 + @Builder + @Getter
   • 생성 이후 변경 불가 → 사이드이펙트 최소화
2. 엔티티 생성 경로 통일
   • @Builder 생성자만 허용(세터 지양)
   • 의미 있는 필수값만 인자로 받게 설계
3. from()로 변환 로직 캡슐화
   • 서비스/컨트롤러에서 변환 코드 제거, 테스트 쉬움
4. 검증은 요청 DTO에서
   • @Valid + Bean Validation으로 최대한 앞단에서 걸러내기
5. HTTP 응답 코드 일관성
   • 중복/권한/검증 실패/리소스 없음 등 표준 상태코드 매핑
6. DB 제약으로 이중 보호
   • @Table(uniqueConstraints=...) 또는 컬럼 unique = true
   • 동시성 상황을 DB가 보조

5) 한 줄 요약

• Builder: "필드명 기반"으로 안전하고 읽기 쉬운 객체 생성을 만든다.
• from(): 엔티티 -> DTO 변환 규칙의 단일 진실(SSOT) 을 제공한다.
• 둘을 함께 쓰면 가독성/유지보수성/테스트 용이성이 크게 향상된다.

2025.10.23

쿠키(Cookie), 세션(Session), JWT(Json Web Token) 정리

쿠키 (Cookie)

개념: 클라이언트(웹 브라우저)에 저장되는 작은 데이터 파일로, 사용자의 상태나 설정 정보를 저장하기 위해 사용됩니다.

주요 특징:

• 서버가 브라우저에 전달하고, 브라우저가 이를 저장함.
• 이후 요청 시 자동으로 쿠키를 포함해 서버에 전송.
• 주로 로그인 유지, 팝업 미표시 설정, 장바구니 정보 등에 사용됨.

구성 요소: | 항목 | 설명 | |------|------| | Name | 쿠키 이름 (고유 식별자) | | Value | 쿠키 값 | | Domain | 쿠키가 적용되는 도메인 | | Path | 쿠키가 적용되는 경로 | | Expires | 만료 시점 (없으면 세션 쿠키로 브라우저 종료 시 삭제) |

저장 위치: 클라이언트(웹 브라우저)

만료 시점: 쿠키 생성 시 지정 가능 (브라우저 종료 후에도 유지 가능)

보안: 취약 (클라이언트에서 쉽게 접근 가능)

세션 (Session)

개념: 서버에서 일정 시간 동안 클라이언트의 상태를 유지하기 위해 사용하는 기술입니다.

주요 특징:

• 서버가 클라이언트마다 고유한 세션 ID를 발급.
• 해당 ID는 쿠키 형태로 클라이언트에 저장되어 요청 시 서버가 이를 이용해 클라이언트를 식별.
• 로그인 정보 등 민감한 데이터를 서버에 저장하기 때문에 보안성이 높음.

동작 방식:

1. 클라이언트가 서버에 요청을 보냄.
2. 서버가 세션을 생성하고 세션 ID를 클라이언트에 전달.
3. 클라이언트는 세션 ID를 쿠키로 저장.
4. 이후 요청마다 쿠키에 담긴 세션 ID를 함께 전송.
5. 서버는 세션 ID로 클라이언트를 식별하여 동일 사용자임을 인식.

저장 위치: 서버

만료 시점:

• 브라우저 종료 시
• 클라이언트 로그아웃 시
• 서버에서 설정한 유효시간 만료 시

보안: 비교적 안전 (서버 저장 방식)

JWT (Json Web Token)

개념: 서버가 클라이언트를 인증하기 위해 JSON 형태로 인코딩된 토큰을 발급하고, 클라이언트가 이를 직접 보관하는 무상태(stateless) 인증 방식입니다.

주요 특징:

• 인증 정보가 서버가 아닌 토큰 내부에 포함됨.
• 서버는 요청 시 토큰의 서명을 검증해 신뢰할 수 있는 사용자임을 확인.
• 세션과 달리 서버에 상태 정보를 저장하지 않음 → 확장성 우수.

구조: JWT는 3부분으로 구성됩니다.

Header.Payload.Signature

동작 방식:

1. 사용자가 로그인 요청을 보냄.
2. 서버가 사용자 인증 후 JWT를 생성하여 클라이언트에 전달.
3. 클라이언트는 JWT를 LocalStorage 또는 쿠키에 저장.
4. 이후 요청 시 Authorization: Bearer <JWT> 헤더로 전달.
5. 서버는 토큰 서명을 검증하여 사용자 식별.

저장 위치: 클라이언트 (LocalStorage, SessionStorage, 또는 쿠키)

만료 시점: 토큰 내부 exp(만료 시간) 필드로 지정.

보안: 안전하지만 토큰 탈취 시 재발급 필요 (서버가 상태를 저장하지 않기 때문)

쿠키, 세션, JWT 비교 요약

정리 요약

• 쿠키: 클라이언트 중심, 단순 데이터 저장
• 세션: 서버 중심, 로그인 상태 유지
• JWT: 무상태 인증, 서버 부담 감소 및 확장성 향상

2025.10.16

ORM이란

ORM(Object-Relational Mapping) : 객체지향 프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블을 자동으로 매핑해주는 기술.

** 주요 특징** - 객체와 테이블 간의 데이터 변환 자동화 - SQL을 직접 작성하지 않아도 CRUD 가능 - 패러다임 불일치 문제를 해결함

** 패러다임 불일치란** 데이터베이스는 한 칸에 String, Integer 같은 단일 값만 넣을 수 있지만, 자바 객체는 List, Object 등을 포함할 수 있는 구조적 차이를 말한다.

JDBC란

JDBC(Java Database Connectivity) 자바 프로그램에서 데이터베이스에 접속하고 SQL문을 실행하기 위한 API. 직접 SQL을 작성하고 결과를 처리해야 하므로 코드가 복잡하고 유지보수가 어려움.

JPA란

JPA(Java Persistence API) Java와 관계형 데이터베이스 간의 패러다임 불일치 문제를 해결하여 데이터베이스 작업을 객체지향적으로 수행할 수 있도록 지원하는 ORM 기술의 표준 인터페이스.

• JPA는 인터페이스 이므로 단독 사용 불가.
• 구현체로 대표적으로 Hibernate를 사용.
• Hibernate는 내부적으로 JDBC를 이용해 DB와 통신.

JPA 계층 구조

Spring Data JPA

Spring에서 JPA를 쉽게 사용할 수 있도록 제공하는 추상화된 모듈.

• Repository 인터페이스만 정의하면 CRUD 기능 자동 제공.
• 복잡한 EntityManager 사용 없이 간단하게 데이터 처리 가능.

Entity란

Entity는 데이터베이스 테이블과 1:1로 매핑되는 Java 클래스.

관련 어노테이션

• @Entity → 해당 클래스가 JPA 엔티티임을 선언 (즉, 데이터베이스 테이블과 매핑되는 클래스임을 나타냄.)

• @Table(name = "members") → 엔티티와 매핑할 데이터베이스 테이블 이름을 지정한다. (지정하지 않으면 클래스 이름이 테이블 이름으로 사용됨.)

• @Id → 기본 키(Primary Key)를 지정한다. (각 엔티티는 반드시 하나의 @Id 필드를 가져야 한다.)

• @GeneratedValue → 기본 키 자동 생성 전략을 지정한다. (예: MySQL에서는 GenerationType.IDENTITY 사용)

• @Column → 엔티티 필드와 데이터베이스 컬럼의 매핑 정보를 지정한다. 속성 예시:

  • name : 컬럼명 지정
  • length : 문자열 길이 제한
  • nullable : null 허용 여부
  • unique : 유니크 제약 조건 설정

@NoArgsConstructor(access = AccessLevel.PROTECTED) Lombok 어노테이션으로 기본 생성자를 protected로 생성하여 외부에서 임의로 객체 생성을 제한.

Spring Layer Architecture

Spring 애플리케이션의 3계층 구조

Controller Layer

• HTTP 요청을 받고 응답을 반환하는 역할
• 요청 파라미터 검증, 예외 처리 담당

해야 할 일 - @RestController 또는 @Controller 사용 - 요청 매핑 (@GetMapping, @PostMapping 등) - 요청 데이터 DTO로 받기 - 응답 데이터 반환 (JSON)

Service Layer

• 비즈니스 로직 처리 계층
• 핵심 로직, 트랜잭션, 데이터 검증 수행

해야 할 일 - @Service 사용 - 여러 Repository 호출 및 조합 - 비즈니스 규칙, 데이터 검증 - 트랜잭션 경계 설정 (@Transactional)

Repository Layer

• 데이터베이스와 직접 상호작용
• Spring Data JPA의 JpaRepository를 상속받아 CRUD 자동화

해야 할 일 - CRUD 메서드 정의 또는 쿼리 메서드 작성 - 쿼리 최적화 및 데이터 매핑

계층 간 통신 규칙

✅ 허용

• 상위 → 하위 계층 호출

• 동일 계층 내 통신

  ❌ 금지

• 하위 → 상위 계층 호출

• 계층 건너뛰기 (Controller → Repository 직접 접근 금지)

DTO란 (Data Transfer Object)

데이터를 계층 간 전달하기 위한 순수한 데이터 객체.

역할 - Controller에서 클라이언트의 요청(JSON 등)을 DTO로 변환 - DTO → Entity 변환 후 DB 저장 - Entity → DTO 변환 후 응답 반환

예시

public class MemberDTO {
    private String name;
    private String email;
}

2025.10.14

📦 Properties of HTTP Request Methods

Optional: 있을 수도 있고 없을 수도 있다.

개념 정리

🔸 Safe (안전성)

• GET 메서드는 데이터를 조회만 하므로 안전하다.
• POST, PUT, DELETE, PATCH는 데이터를 생성·수정·삭제하기 때문에 안전하지 않다.

🔸 Idempotent (멱등성)

• 한 번 호출하든 여러 번 호출하든 결과가 같다.
• GET, PUT, DELETE는 멱등성을 보장한다.
• POST는 멱등성을 보장하지 않는다.

멱등성이 중요한 이유

1. 요청 실패 시 재시도 가능
   → 항상 같은 결과면 여러 번 요청해도 문제 없음
   → 멱등성이 없으면 중복 요청으로 데이터가 중복 생성될 수 있음
2. 캐시 가능성
   • GET, HEAD, POST는 캐시 가능
   • 일반적으로는 GET, HEAD만 캐시로 사용

캐시(Cache)

• 클라이언트가 한 번 요청한 데이터를 임시 저장하여,
  매번 서버에 재요청하지 않고 빠르게 접근할 수 있도록 하는 기술.

상태 코드 (HTTP Status Codes)

REST API / RESTful API 디자인 규칙

1. 동사보다는 명사, 단수보다는 복수 사용
   • /users O /getUsers X
2. 마지막에 / 붙이지 않기
3. _ 대신 - 사용, 대문자 사용하지 않기
4. 확장자(.svg, .png, .exe) 포함하지 않기
5. 계층적 구조 설계
   • /users/1/posts 처럼 상위-하위 관계 표현

Annotation (어노테이션)

자바 코드에 메타데이터를 추가하여,
컴파일러나 런타임에서 특정 동작을 수행하도록 하는 기능

예시:

• @Override : 상속받은 메서드를 재정의
• @Autowired : 스프링이 자동으로 의존성 주입
• @RestController, @Service, @Repository : 역할 지정

복잡한 기능을 단순하게 사용할 수 있도록 도와준다.

Lombok 라이브러리

반복적인 코드(보일러플레이트)를 자동으로 생성해주는 라이브러리

• @Getter, @Setter : getter/setter 자동 생성
• @ToString : toString() 자동 생성
• @AllArgsConstructor : 모든 필드를 매개변수로 받는 생성자 생성
• @NoArgsConstructor : 기본 생성자 생성
• @Slf4j : Logger 객체 자동 생성 (로그 출력용)

보일러플레이트 코드란?

getter/setter, 생성자, toString() 등
반복적으로 작성되는 코드들을 의미한다.

2025.10.13

학습 주제

List를 이용한 상품 탐색(binary search / linear search) 구현 및
성능 비교(performance test)

문제 1: 문자열(String) 비교 방식

상황

binarySearch(String productName)을 구현할 때
“문자열을 기준으로 좌/우를 어떻게 비교해야 하는지” 감이 안왔다.

if (productName.compareTo(midProduct.getName()) == 0) {
    ...
}

✅ 해결 방법

• String.compareTo() 메소드 사용.
  • compareTo()는 사전순 비교를 수행하며
    반환값이 양수/음수/0이면 각각 오른쪽/왼쪽/같음을 의미함.
  • 정렬된 리스트 에서만 사용이 가능하다.

int cmp = productName.compareTo(midProduct.getName());
if (cmp < 0) right = mid - 1;
else if (cmp > 0) left = mid + 1;
else return mid;

배운 점

문자열 비교는 ==이 아니라 .compareTo() 또는 .equals()로 해야 한다.
“왼쪽/오른쪽” 판단은 compareTo()의 반환값으로 처리한다.

문제 2: List<Product> 자동 생성 및 정렬

상황

10,000개의 상품 데이터를 자동으로 생성해야 했음.
상품명은 "Product_0001" ~ "Product_10000" 형태여야 함.

✅ 해결 방법

• String.format("Product_%04d", i) 사용 → 0패딩된 문자열 생성

for (int i = 1; i <= 10000; i++) {
    String name = String.format("Product_%04d", i);
    products.add(new Product(name));
}

배운 점

정렬된 리스트를 전제로 하는 binary search에서는
반드시 동일한 기준으로 정렬해야 한다.
문자열 포맷팅(String.format)은 숫자형 인덱스를 문자열로 표현할 때 매우 유용하다.

문제 3: binarySearch() 비교문 작성 실수

상황

SearchEngine 클래스의 이진탐색 구현 중

if (productName.compareTo(productName) == 0)

처럼 자기 자신끼리 비교하는 코드가 되어버림 → 항상 0 반환.

어려움의 본질

• 비교 대상이 중간값(midProduct)이 아니라, 자기 자신(productName)이었음.
• 결과적으로 탐색이 제대로 이루어지지 않음.

✅ 해결 방법

• 비교 기준을 명확히 구분:
  • 왼쪽(right)/오른쪽(left) 이동 판단은 productName vs midProduct.getName() 비교로 수정.

int compare = productName.compareTo(midProduct.getName());
if (compare == 0) return midProduct;
else if (compare < 0) right = mid - 1;
else left = mid + 1;

배운 점

“무엇을 무엇과 비교하고 있는가”를 항상 명확히 해야 한다.
특히 문자열 비교에서는 compareTo()의 인자를 잘못 넣으면 논리 전체가 무너진다.

추가 : 숫자 표기 10_000 vs 10000

상황

코드에 generateProducts(10_000)처럼 숫자 사이에 _를 사용하는 사람이 있어서 찾아봤다.

• _는 단순히 가독성을 높이는 숫자 구분자이며,
  실제 값은 동일 (10_000 == 10000).

• 언더스코어는 Java 7 이후 숫자 리터럴 내에서 자유롭게 사용 가능함을 확인.

• 성능이나 계산 결과에는 전혀 영향 없음.

int a = 10_000; // = 10000

배운 점

_는 단순한 “시각적 구분자”일 뿐, 값의 의미는 변하지 않는다.

오늘 배운 핵심 요약

오늘 스트림 개념을 정리하면서 쓰레드와 헷갈리는 부분이 있어서 추가로 학습한 내용을 정리했다.

1. 쓰레드(Thread) 개념

• 정의: CPU가 실제로 작업을 수행하는 최소 실행 단위.
• 특징
  • 하나의 프로세스 안에 여러 개의 쓰레드 존재 가능 → 멀티쓰레딩
  • 각각의 쓰레드는 독립된 실행 흐름을 가짐
  • 동시성(Concurrency), 병렬성(Parallelism) 구현의 핵심

2. 스트림(Stream) 개념

• 정의: 자바 8에서 도입된 데이터 처리 API
  (배열, 컬렉션의 요소를 필터링·매핑·집계 같은 연산을 SQL처럼 선언적으로 다룰 수 있음)
• 특징
  • 원본 데이터 변경 X (불변성)
  • 중간 연산(filter, map 등)은 지연실행 → 최종 연산(collect, forEach 등) 시 수행
  • 내부 반복 (반복문 로직을 직접 안 짜도 됨)
  • 병렬 처리 지원 (parallelStream)

3. 스트림에서 단일 쓰레드 vs 멀티 쓰레드

(1) 단일 쓰레드 스트림 (stream())

• 기본 스트림은 단일 쓰레드에서 순차 처리.
• 내부적으로 하나의 쓰레드만 사용하므로 데이터는 입력 순서대로 처리됨.
• 작은 데이터, 순서 중요한 경우 적합.

list.stream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .forEach(System.out::println);

실행 순서: 한 쓰레드가 처음부터 끝까지 순차적으로

(2) 멀티 쓰레드 스트림 (parallelStream())

• 내부적으로 ForkJoinPool (공용 스레드 풀, 기본적으로 CPU 코어 수만큼의 워커 스레드) 사용.
• 데이터를 여러 조각으로 나누고 병렬로 처리한 후 최종적으로 합침.
• 대량의 데이터 처리 시 성능 향상 가능.
• 단, 작은 데이터에서는 오히려 성능 저하 (스레드 관리 오버헤드 때문).
• 순서 보장이 필요하다면 forEachOrdered() 사용해야 함.

list.parallelStream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .forEach(System.out::println); // 순서 보장 X

실행 순서: 여러 쓰레드가 동시에 조각을 나눠서 처리

최종 정리

• 쓰레드(Thread) → CPU 실행 단위 (작은 범위, 저수준)
• 스트림(Stream) → 데이터 처리 API (큰 범위, 고수준)
• 단일 스트림(stream) → 순차 처리 (1개의 쓰레드)
• 병렬 스트림(parallelStream) → 병렬 처리 (여러 쓰레드, ForkJoinPool 활용)

1. 알고리즘 성능 분석

• 알고리즘 성능 분석이란?
  문제를 해결하는 여러 알고리즘 중에서, 주어진 시간과 자원 제약 안에서 가장 효율적인 방법을 찾기 위해 성능(시간, 메모리 등)을 평가하는 과정.

• 시간 복잡도 (Time Complexity)

  • 입력 크기 n에 따른 알고리즘의 실행 시간을 분석
  • Big-O 표기법을 사용: O(1), O(log n), O(n), O(n log n), O(n^2) 등

• 공간 복잡도 (Space Complexity)

  • 알고리즘 실행 시 필요한 메모리 사용량 분석
  • 예: 재귀 호출의 스택 메모리, 추가 배열/자료구조 사용량 등

2. 알고리즘 문제해결 5단계

1단계: 문제 이해 및 요구사항 분석

• 문제를 정확히 읽고 해석하기
• 입력과 출력 형식, 제약 조건 정리
• 예시 입력/출력으로 문제 의도 파악

2단계: 접근 방법 구상하기

• 유사 문제/패턴 떠올리기
• 사용할 수 있는 알고리즘 유형 고려하기 (완전 탐색, DP, Greedy 등)
• 해결 아이디어의 시간·공간 효율성 예측

3단계: 세부 설계 및 검토

• 알고리즘 절차를 단계별로 구체화
• 발생할 수 있는 예외 상황 점검
• 극단적인 입력값(엣지 케이스) 고려
• 시간/공간 복잡도 분석 필수

4단계: 코드 작성 및 구현

• 설계한 알고리즘을 실제 코드로 변환
• 가독성 있는 변수명, 함수명 사용
• 구현 과정에서 알고리즘의 효율성 점검

5단계: 테스트와 디버깅

• 다양한 테스트 케이스 실행 (일반, 극단, 예외 상황)
• 오류 발생 시 디버깅
• 실행 시간이 길 경우 알고리즘/자료구조 최적화
  • 중복 연산 제거 (메모이제이션)
  • 불필요한 탐색 제거 (가지치기)
  • 적절한 자료구조 선택 (예: 해시, 우선순위 큐)

3. 알고리즘 유형

• 구현 (Implementation) & 시뮬레이션 (Simulation)

  • 단순히 문제의 요구사항을 그대로 코드로 옮겨 구현하는 방식

• 완전 탐색 (Brute Force)

  • 가능한 모든 경우를 탐색 (효율성은 낮지만 정답 보장)

• 그리디 (Greedy) 알고리즘

  • 매 순간 최적이라고 생각되는 선택을 반복 → 전역 최적 보장 여부는 문제 특성에 따라 다름

• 백트래킹 (Backtracking)

  • 모든 경우를 탐색하되, 불가능한 경우는 조기에 탐색 중단 (가지치기)

• 분할 정복 (Divide and Conquer)

  • 문제를 작은 부분 문제로 나눠 해결 후, 결과를 합치는 방식 (예: 병합 정렬, 퀵 정렬)

• 동적 계획법 (Dynamic Programming, DP)

  • 부분 문제의 해를 저장하여 중복 계산을 줄임 (메모이제이션, 점화식 기반)

4. 좋은 알고리즘을 선택하는 기준

1. 입력 크기 (n): n이 작으면 단순 탐색도 가능, 크면 최적화 필요
2. 제약 조건: 시간 제한, 메모리 제한 고려
3. 정확성 vs 효율성: 빠르지만 근사값만 주는 알고리즘도 선택 가능
4. 문제 유형: 최단 경로 → 다익스트라, 최적화 → DP/Greedy, 탐색 → DFS/BFS

1. 스택(Stack)

개념과 특징

• LIFO (Last In, First Out) 구조 → 마지막에 들어온 데이터가 먼저 나간다.
• 대표적 활용: 함수 호출(콜 스택), 실행 취소(Undo), 수식 계산 등

기본 연산

• push(item): 데이터 삽입
• pop(): 데이터 삭제 및 반환
• peek(): 최상단(top)의 데이터 확인 (삭제 X)
• isEmpty(): 비어있는지 확인

장단점

• 장점: 구현 단순, 빠른 연산 (O(1))
• 단점: 메모리 제한(배열 기반), 중간 요소 접근 불가

응용 예시

• 문자열 뒤집기
• 웹 브라우저 방문 기록 (뒤로/앞으로)
• DFS(깊이 우선 탐색)
• 괄호 유효성 검사

2. 큐(Queue)

개념과 특징

• FIFO (First In, First Out) 구조 → 먼저 들어온 데이터가 먼저 나간다.
• 대표적 활용: 대기열(프린터, 은행 번호표), 프로세스 스케줄링

기본 연산

• enqueue(item): 데이터 삽입 (뒤에서)
• dequeue(): 데이터 삭제 및 반환 (앞에서)
• peek(): front 데이터 확인
• isEmpty(): 비어있는지 확인

큐의 변형

• 원형 큐(Circular Queue): 공간 낭비 해결
• Deque(Double Ended Queue): 양쪽에서 삽입/삭제 가능
• Priority Queue: 우선순위에 따라 꺼내는 순서 결정

장단점

• 장점: 공정한 순서 보장, 구현 단순
• 단점: 배열 기반 구현 시 메모리 낭비 가능

응용 예시

• BFS(너비 우선 탐색)
• 운영체제 프로세스 스케줄링
• 네트워크 데이터 버퍼 관리

3. Stack vs Queue 비교

구분 Stack (스택) Queue (큐)

구조 LIFO (후입선출) FIFO (선입선출) 삽입 위치 Top (맨 위) Rear (뒤) 삭제 위치 Top (맨 위) Front (앞) 시간 복잡도 O(1) O(1) 주요 응용 재귀, 되돌리기, DFS 대기열, BFS, 스케줄링

4. 자바 설계 예시

Stack 구현 (ArrayList 활용)

class Stack {
    private List<Integer> list = new ArrayList<>();

    public void push(int value) {
        list.add(value);
    }

    public int pop() {
        if (list.isEmpty()) throw new RuntimeException("Stack is empty");
        return list.remove(list.size() - 1);
    }

    public int peek() {
        if (list.isEmpty()) throw new RuntimeException("Stack is empty");
        return list.get(list.size() - 1);
    }

    public boolean isEmpty() {
        return list.isEmpty();
    }
}

Queue 구현 (LinkedList 활용)

class Queue {
    private LinkedList<Integer> list = new LinkedList<>();

    public void enqueue(int value) {
        list.addLast(value);
    }

    public int dequeue() {
        if (list.isEmpty()) throw new RuntimeException("Queue is empty");
        return list.removeFirst();
    }

    public int peek() {
        if (list.isEmpty()) throw new RuntimeException("Queue is empty");
        return list.getFirst();
    }

    public boolean isEmpty() {
        return list.isEmpty();
    }
}

1. 인터페이스 (Interface)

• 설계의 표준: 클래스가 따라야 할 최소한의 공통 규칙을 정의.\
• 목적: 일관성을 유지하면서 클래스가 고유한 특색을 확장할 수 있도록 함.\
• 특징:
  • 모든 메서드는 기본적으로 public abstract (Java 8 이후 default, static 메서드 허용).\
  • 모든 변수는 public static final (상수).\
  • 다중 상속 가능 (interface A extends B, C).\
• 사용 키워드:
  • implements → 클래스가 인터페이스를 구현할 때.\
  • extends → 클래스 → 클래스 상속 / 인터페이스 → 인터페이스 상속.

2. 캡슐화 (Encapsulation)

• 정의: 외부에서 직접 접근하지 못하게 하고, 접근을 제어하는 것.\
• 방법:
  • 멤버 변수는 private으로 선언.\
  • getter, setter 메서드를 통해 접근.\
• 장점: 데이터 보호, 유지보수 용이, 코드 안정성 향상.

3. 상속 (Inheritance)

• 정의: 부모 클래스의 속성과 메서드를 자식 클래스가 물려받아 사용하는 것.\
• 목적: 코드 재사용성, 확장성.\
• 관련 키워드:
  • super → 부모의 생성자, 변수, 메서드 호출.\
  • 메소드 오버라이딩(Overriding): 부모 메서드를 자식이 재정의.\
  • 접근 제어자는 부모보다 좁게는 불가능, 더 넓게는 가능.

4. 추상 클래스 (Abstract Class)

• 정의: 공통 기능을 제공하면서, 일부 메서드 구현을 강제.\
• 특징:
  • abstract 키워드 사용.\
  • 추상 메서드는 구현이 없음 → 반드시 자식 클래스에서 구현해야 함.\
  • 인스턴스 생성 불가 (new 불가).

5. 추상화 (Abstraction)

• 정의: 불필요한 세부 사항은 감추고 본질적인 것만 표현하는 것.\
• 목적: 복잡성을 줄이고 핵심 로직에 집중.\
• 방법:
  • 인터페이스, 추상 클래스 사용.\
  • 예: 자동차 → "운전한다"는 기능만 신경, 엔진 구조는 감춤.

6. 다형성 (Polymorphism)

• 정의: 하나의 타입으로 여러 객체를 다룰 수 있는 성질.\
• 조건: 상속과 오버라이딩이 전제.\
• 형변환:
  • Upcasting: 자식 → 부모 (자동 형변환, 자식 고유 기능 X).\
  • Downcasting: 부모 → 자식 (강제 형변환 필요).

Parent p = new Child(); // 업캐스팅
Child c = (Child) p;    // 다운캐스팅

7. 예외 처리 (Exception Handling)

• try-catch: 예외 발생 시 프로그램 비정상 종료를 막음.\
• throw: 의도적으로 예외 발생 가능.\
• 예외 구분:
  • RuntimeException (Unchecked Exception): 컴파일러가 예외처리 강제 X.\
  • Exception (Checked Exception): 반드시 예외처리 필요. 미처리 시 컴파일 에러.\
• throws 키워드: 현재 메소드가 아닌 상위 메소드로 예외를 전달.\
• 예외 전파: 예외는 발생 지점에서 처리되지 않으면 상위 메소드로 계속 전파됨.

8. Optional

• 목적: null 안전하게 다루기 위한 컨테이너 객체.\
• 장점: NullPointerException 방지.\
• 특징: 값이 있을 수도 있고, 없을 수도 있음.

9. 컬렉션 (Collection)

• 정의: 자바에서 제공하는 자료구조 모음.

ArrayList

• 크기 가변적, 중복 가능, 순서 유지.\
• add, get, remove 메소드 사용.

HashSet

• 순서 보장 X, 중복 불가.\
• add, remove 사용 가능.\
• get 불가능 (순서 없음).

HashMap

• 키-값 구조, 키 중복 불가.\
• put, get, remove, keySet, values 메소드 제공.

10. 제네릭 (Generics)

• 정의: 클래스, 메소드 등에 타입 매개변수 <T>를 지정.\
• 장점: 코드 재사용성, 타입 안정성.\
• 특징:
  • 컴파일 시 타입 체크.\
  • 다운캐스팅 필요 없음.

class Box<T> {
    private T value;
    public void set(T value) { this.value = value; }
    public T get() { return value; }
}

11. 익명 클래스 & 람다

• 익명 클래스: 이름이 없는 클래스, 일회성 정의.\
• 람다식: 익명 클래스를 더 간결하게 표현.\
• 함수형 인터페이스: 추상 메서드 1개만 선언 가능.

Runnable r = () -> System.out.println("람다식 실행");
new Thread(r).start();

12. 스트림 (Stream)

• 목적: 데이터를 효율적으로 처리하는 흐름 제공.\
• 단계:
  1. 데이터 준비 (stream(), parallelStream())\
  2. 중간 연산 (map, filter, sorted)\
  3. 최종 연산 (collect, forEach, count)

List<String> names = Arrays.asList("A", "B", "C");
names.stream().filter(s -> s.equals("B")).forEach(System.out::println);

13. 쓰레드 (Thread)

• 정의: 독립적으로 실행되는 작업 단위.\
• 싱글 쓰레드: 한 번에 하나의 작업.\
• 멀티 쓰레드: 병렬 작업 가능 → 성능 향상.

구현 방법

1. Thread 클래스 상속 → run() 오버라이드.\
2. Runnable 인터페이스 구현 (권장).

주의사항

• 실행 시 반드시 start() 사용.\
• join() → 특정 쓰레드 종료까지 대기.

class MyThread extends Thread {
    public void run() {
        System.out.println("Thread 실행");
    }
}

public class Main {
    public static void main(String[] args) throws InterruptedException {
        MyThread t = new MyThread();
        t.start();
        t.join();
        System.out.println("메인 종료");
    }
}

클래스와 객체

• 클래스(Class): 객체를 생성하기 위한 설계도.
• 객체(Object): 클래스에서 생성된 실체.
• 인스턴스화(객체화): new 키워드를 사용하여 객체를 생성하는 것.

클래스 내부 구성

• 속성(Field): 객체의 상태(데이터)를 저장.
• 생성자(Constructor): 객체 생성 시 호출되는 특별한 메서드.
  • 생성자를 정의하지 않으면 컴파일러가 기본 생성자(매개변수 없는 생성자)를 자동 제공.
  • 직접 생성자를 정의하면 기본 생성자는 자동으로 제공되지 않음.
  • 매개변수를 맞추지 않으면 컴파일 에러 발생.

2. JVM 메모리 영역

자바 프로그램 실행 시 JVM은 메모리를 다음 영역으로 나눔:

• Method Area (메서드 영역)
  • 클래스 정보(메타데이터), static 변수, 상수, 메서드 코드 저장.
• Stack Area (스택 영역)
  • 메서드 호출 시 지역 변수, 매개변수 저장.
  • LIFO(Last-In First-Out) 구조.
• Heap Area (힙 영역)
  • new 키워드로 생성된 객체와 배열 저장.
  • 변수에는 객체의 주소(참조 값) 가 저장됨.

3. Wrapper Class

• 정의: 기본 자료형(Primitive type)을 객체로 다룰 수 있도록 감싼 클래스.
• 종류:
  • int → Integer
  • double → Double
  • boolean → Boolean
  • char → Character 등

사용 이유

• 기본형을 객체처럼 다루기 위함.
• 제네릭, 컬렉션, 매개변수 등에서 객체 타입만 지원할 때 필요.
• 데이터 처리 기능(메서드 제공)이 있어 편리.

오토박싱 & 언박싱

• 오토박싱(Auto-boxing): 기본형 → 래퍼 클래스
• 언박싱(Unboxing): 래퍼 클래스 → 기본형

int a = 10;
Integer b = a;   // 오토박싱
int c = b;       // 언박싱

래퍼 클래스는 힙 영역의 객체를 참조하기 때문에 기본형보다 처리 속도가 느릴 수 있음. 빠른 연산에는 기본형을 쓰는 것이 권장됨.

4. static

• 정의: 클래스 차원에서 공유되는 멤버.
• 특징:
  • 객체 생성 없이 클래스명.변수,메서드 로 접근 가능.
  • 프로그램 시작 시 메모리에 올라가고 종료될 때까지 유지됨.
  • 메서드 영역(Method Area)에 저장됨.
• 인스턴스 멤버: 객체마다 독립적으로 생성, 힙 영역에 저장됨.
• static은 남발 시 메모리 낭비와 설계 혼란을 줄 수 있으므로 꼭 필요할 때만 사용.

5. final

• final 변수: 상수(값 변경 불가).
• final 메서드: 오버라이딩 불가.
• final 클래스: 상속 불가.

불변 객체

• 내부 상태를 변경할 수 없는 객체.
• final + setter 메서드 없음 으로 설계.
• 대표 예시: String, Integer 등 래퍼 클래스.

1. 형 변환

(1) 다운캐스팅 (명시적 형 변환)

• 큰 데이터 타입 → 작은 데이터 타입
• 직접 형 변환을 해주어야 함
• 데이터 손실 발생 가능

double d = 3.14;
int i = (int) d; // 3 (소수점 이하 손실)

(2) 업캐스팅 (자동 형 변환)

• 작은 데이터 타입 → 큰 데이터 타입
• 자동으로 변환되므로 별도의 코드 불필요

int a = 10;
double b = a; // 10.0

2. 연산

(1) % 모듈러 연산

• 나머지를 구하는 연산
• 시간 계산, 짝/홀수 판별 등에 자주 사용

int n = 10;
System.out.println(n % 2); // 0 → 짝수
System.out.println(n % 3); // 1

(2) 연산자 우선순위

• 산술 → 비교 → 논리 → 대입
• 논리 연산자: ! → && → ||

(3) 문자열 비교

• 문자열은 == (메모리 주소 비교 ) 대신 .equals() 사용

String s1 = "hello";
String s2 = new String("hello");

System.out.println(s1 == s2);       // false (주소 비교)
System.out.println(s1.equals(s2));  // true (값 비교)

3. 배열

(1) 정적 배열

• 크기 고정, 한 번 정하면 변경 불가

int[] arr = new int[3]; // 크기 3

(2) 동적 배열

• 크기 변경 가능
• Java에서는 ArrayList로 구현

import java.util.ArrayList;

ArrayList<Integer> list = new ArrayList<>();
list.add(10);
list.add(20);
System.out.println(list); // [10, 20]

4. 반복문

(1) for문

• 반복 횟수가 명확할 때 사용

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

(2) while문

• 조건이 참일 때 반복 실행

int i = 0;
while (i < 5) {
    System.out.println(i);
    i++;
}

(3) do-while문

• 최소 1회 실행 보장

int i = 0;
do {
    System.out.println(i);
    i++;
} while (i < 5);

(4) 향상된 for문 (for-each)

• 배열이나 컬렉션 전체를 순회할 때 사용

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

for (int n : numbers) {
    System.out.println(n);
}

5. 조건문

(1) if문

• 조건이 참일 때만 실행

int n = 10;

if (n > 0) {
    System.out.println("양수");
}

(2) if-else문

• 조건에 따라 두 가지 경우 처리

int n = -5;

if (n >= 0) {
    System.out.println("양수");
} else {
    System.out.println("음수");
}

(3) if-else if-else문

• 여러 조건 분기 처리

int score = 85;

if (score >= 90) {
    System.out.println("A");
} else if (score >= 80) {
    System.out.println("B");
} else {
    System.out.println("C 이하");
}

(4) switch문

• 값에 따라 분기 처리

int day = 3;

switch (day) {
    case 1:
        System.out.println("월요일");
        break;
    case 2:
        System.out.println("화요일");
        break;
    case 3:
        System.out.println("수요일");
        break;
    default:
        System.out.println("기타 요일");
}

자바기본 문법에 대한 공부를 진행했고, 그것에 대한 TIL을 적었다.

1. 자바의 플랫폼 독립성

• 작성 → 컴파일 → 실행 과정
  1. .java (자바 소스파일)
  2. Javac 컴파일러 → .class (바이트코드)
  3. JVM(Java Virtual Machine) → OS에 맞게 실행

핵심 이유 : 바이트코드는 특정 운영체제에 종속되지 않고, JVM만 있으면 실행 가능하다.

2. 컴퓨터의 기억 장치

(1) 주 기억 장치 (RAM)

• 프로그램 실행 중 데이터 임시 저장
• 휘발성: 전원 끄면 내용 사라짐
• 빠른 속도로 CPU와 통신 가능

(2) 보조 기억 장치 (HDD/SSD)

• 영구 저장 장치
• RAM보다는 속도 느림

3. 메모리 관리 방식

• 메모리는 1바이트 단위로 주소가 매겨져 관리됨
• 1바이트 = 8비트
• 비트(bit): 메모리 최소 단위 (0 또는 1 저장)
• 저장 공간은 1비트 증가 시마다 2배 확장 (2진수 원리)

4. 자바 기본 자료형 (Primitive Types)

5. 변수의 특징

선언과 초기화

int age = 25;
double pi = 3.14;
String name = "홍길동";

오늘은 전에 사둔 spring 강의를 마저 보면서 새로운 해시맵인 ConcurrnetHashMap을 알게 되어서 ConcurrnetHashMap이 무엇인지 알아볼 것이다.

1. Map 소개

Map은 Java 컬렉션 프레임워크의 인터페이스로, 키(Key)와 값(Value) 쌍을 저장하는 자료구조입니다.

• 각 키는 유일(unique)해야 하고, 값은 중복될 수 있습니다.
• 대표적인 메서드:
  • put(key, value) : 데이터 추가
  • get(key) : 키에 해당하는 값 조회
  • remove(key) : 데이터 삭제
  • containsKey(key) : 특정 키 존재 여부 확인

2. Map의 주요 구현체

Java에는 다양한 Map 구현체가 존재하며, 각기 다른 특성과 사용 목적이 있습니다.

(1) HashMap

• 가장 일반적으로 사용되는 Map 구현체
• 해시 테이블을 기반으로 데이터 저장
• 순서를 보장하지 않음
• null 키 1개와 null 값 여러 개 허용

(2) LinkedHashMap

• 입력된 순서(또는 접근 순서)를 유지
• 순서 보장이 필요한 경우 사용

(3) TreeMap

• 키를 자동으로 정렬 (기본은 오름차순)
• 내부적으로 Red-Black Tree 사용
• 범위 검색이나 정렬이 필요할 때 적합

(4) Hashtable

• HashMap과 유사하지만, 모든 메서드가 동기화 처리됨
• 레거시 클래스라 잘 사용하지 않음

(5) ConcurrentHashMap

• 멀티스레드 환경에서 안전한 Map
• Hashtable보다 효율적 (버킷 단위로 락을 걸어 성능 향상)
• null 키와 null 값은 허용하지 않음

3. ConcurrentHashMap 소개

특징

• 스레드 안전(Thread-safe)
  여러 스레드가 동시에 접근해도 데이터가 깨지지 않음
• 부분 락(lock striping)
  전체 맵이 아니라 일부 버킷에만 락을 걸어 성능을 높임
• 읽기 연산은 락 없이
  대부분의 get()은 락 없이 진행 → 빠른 조회 가능
• null 불가
  null 키와 null 값은 허용하지 않음

언제 사용할까?

• 멀티스레드 환경에서 공유 데이터를 저장/조회할 때
• 동시성 문제가 생기지 않으면서 빠른 성능이 필요한 경우
• 예: 캐시(Cache) 시스템, 스레드 간 데이터 공유

4. 코드 예시

import java.util.concurrent.ConcurrentHashMap;

public class ConcurrentHashMapExample {
    public static void main(String[] args) {
        // ConcurrentHashMap 생성
        ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();

        // 데이터 추가
        map.put("apple", 10);
        map.put("banana", 20);

        // 데이터 조회
        System.out.println("apple: " + map.get("apple")); // apple: 10

        // 값 수정 (동기적으로 안전하게 처리)
        map.compute("apple", (k, v) -> v + 1);
        System.out.println("apple after update: " + map.get("apple")); // apple after update: 11

        // 키 존재 여부 확인
        if (map.containsKey("banana")) {
            System.out.println("banana exists!");
        }

        // 멀티스레드 환경에서 안전하게 접근 가능
        Runnable task = () -> {
            for (int i = 0; i < 5; i++) {
                map.merge("banana", 1, Integer::sum);
            }
        };

        Thread t1 = new Thread(task);
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
    }
}

오늘은 남은 과제 2개 진행했고, 진행하면서 발생한 에러 정리와 해결한 방법을 공유한다.

1. JSP 파일 위치 문제

문제:

• JSP 파일이 src/main/resources/web/WEB-INF/jsp/에 위치
• Spring Boot가 JSP를 찾지 못해 404 오류 발생

해결:

# 올바른 위치로 JSP 파일 이동
mkdir -p src/main/webapp/WEB-INF/jsp
cp -r src/main/resources/web/WEB-INF/jsp/* src/main/webapp/WEB-INF/jsp/

원인: Spring Boot는 src/main/webapp/WEB-INF/jsp/ 경로에서 JSP 파일을 찾음

2. Servlet API 버전 충돌

문제:

• javax.servlet vs jakarta.servlet API 충돌
• Spring Boot 3.x는 jakarta.servlet 사용

해결:

• Spring Boot 방식으로 컨트롤러 변경
• @WebServlet → @Controller + @GetMapping/@PostMapping
• HttpServlet 상속 → Spring MVC 방식

3. 의존성 주입 설정

문제:

• MenuService를 직접 인스턴스화하여 사용
• Spring의 의존성 주입 활용 안 함

해결:

// Before
private final MenuService menuService = new MenuService();

// After
private final MenuService menuService;

public MenuController(MenuService menuService) {
    this.menuService = menuService;
}

4. JSP 뷰 리졸버 설정

문제:

• JSP 파일을 찾지 못하는 404 오류

해결: application.properties에 올바른 설정 추가:

spring.mvc.view.prefix=/WEB-INF/jsp/
spring.mvc.view.suffix=.jsp

5. CH5 서블릿/JSP 사용 실패 이유

Spring Boot 3.x에서 JSP 지원 제한

• 문제: Spring Boot 3.x부터 JSP 지원이 공식적으로 제한됨

• 에러: JSP 파일들이 404 에러로 접근 불가

• 원인:

  • Spring Boot 3.x는 Jakarta EE 기반으로 변경
  • JSP 컴파일러 설정이 복잡해짐
  • 내장 톰캣에서 JSP 처리 방식 변경

  따라서 마지막 과제는 JSP 대신 Thymeleaf로 해결했다.