Date: 2026-05-22

이 시리즈는 Claude 에이전트 팀을 구성해서 React + Spring Boot 포트폴리오 웹사이트를 만드는 과정을 기록한다. 1편에서는 VSCode 안에서 Claude를 채팅으로 쓸 수 있도록 환경을 세팅한다.

왜 Continue.dev인가?

GitHub Copilot Chat 대신 Continue.dev를 선택한 이유는 간단하다.

• 원하는 모델(Claude)을 직접 연결할 수 있다
• VSCode 채팅창에서 코드 파일을 컨텍스트로 넘기기 편하다
• 에이전트별 Custom Commands 등록이 가능하다
• 오픈소스라 설정을 내 마음대로 제어할 수 있다

전체 세팅 순서

1. Continue.dev 설치
2. Anthropic API 키 발급
3. Claude 모델 연결
4. 동작 확인

1단계 — Continue.dev 설치

VSCode Extensions 탭에서 Continue 검색 후 설치한다.

또는 터미널에서:

code --install-extension Continue.continue

설치하면 VSCode 좌측 사이드바에 Continue 아이콘이 생긴다.

2단계 — Anthropic API 키 발급

console.anthropic.com 접속 → API Keys 탭 → Create Key

⚠️ 키는 생성 시 한 번만 보여준다. 반드시 복사해서 안전한 곳에 저장할 것.

무료 크레딧이 있으니 처음엔 결제 없이 테스트 가능하다.

3단계 — Claude 모델 연결

Continue 설정 파일을 열어 Claude를 연결한다.

방법 1: UI에서 설정

Continue 사이드바 하단 설정 아이콘 → Add Model → Anthropic 선택 → API 키 입력

방법 2: config.json 직접 수정 (추천)

~/.continue/config.json 파일을 열어 아래 내용을 추가한다.

{
  "models": [
    {
      "title": "Claude Sonnet 4.6",
      "provider": "anthropic",
      "model": "claude-sonnet-4-6",
      "apiKey": "sk-ant-여기에_API_키_입력"
    }
  ]
}

⚠️ API 키를 절대 Git에 커밋하지 말 것. .gitignore에 config.json을 추가하거나 환경변수로 관리한다.

# .gitignore
.continue/config.json

4단계 — 동작 확인

VSCode에서 Cmd+L (Mac) 또는 Ctrl+L (Windows) 로 Continue 채팅창을 연다.

아래처럼 입력해보자.

안녕! 지금 어떤 모델이야?

Claude가 응답하면 성공이다.

에이전트 팀을 위한 Custom Commands 등록 (보너스)

이 시리즈의 핵심인 에이전트 역할 전환을 편하게 하려면 Custom Commands를 등록해두면 좋다.

~/.continue/config.json에 아래 내용을 추가한다.

{
  "models": [...],
  "customCommands": [
    {
      "name": "fe",
      "description": "Frontend Agent 모드로 전환",
      "prompt": "You are the Frontend Agent. Stack: React 18, TypeScript, Tailwind CSS. Only write frontend code. Always follow the conventions in CLAUDE.md."
    },
    {
      "name": "be",
      "description": "Backend Agent 모드로 전환",
      "prompt": "You are the Backend Agent. Stack: Spring Boot 3, Java 21, PostgreSQL. Only write backend code. Always follow the conventions in CLAUDE.md."
    },
    {
      "name": "qa",
      "description": "QA Agent 모드로 전환",
      "prompt": "You are the QA Agent. Review the code for bugs, security issues, and convention violations. Output a structured review report."
    }
  ]
}

채팅창에서 /fe, /be, /qa 를 입력하면 해당 에이전트 모드로 바로 전환된다.

다음 편 예고

2편에서는 실제 프로젝트 폴더를 만들고, 에이전트 팀의 두뇌인 CLAUDE.md 를 작성한다. LLM에게 장기 기억이 없는 이유와, 그걸 CLAUDE.md로 보완하는 원리도 같이 설명한다.

시리즈 전체 코드는 GitHub에서 공개 예정.

EC2 인스턴스 타입을 C5에서 M8i로 변경한 이후, Oracle DB의 idle 상태 TCP 연결이 7~10분 후 아무런 에러 없이 끊기는 현상이 발생했다. 원인은 최신 Nitro Card(Nitro v6) 의 기본 connection tracking idle timeout 변경이었다.

현상

EC2 인스턴스를 C5 → M8i로 변경 후, Oracle DB의 idle TCP 연결이 7~10분 후 알림 없이 끊기는 "silent drop" 발생. 애플리케이션 로그에는 아무런 에러가 찍히지 않는다.

원인

AWS EC2 Security Group의 Connection Tracking

AWS EC2의 Security Group은 stateful 방화벽이다. 연결 상태를 추적(connection tracking)해서 응답 트래픽을 자동으로 허용한다. 이 connection tracking에는 idle timeout이 존재하며, timeout이 만료되면 해당 연결 정보가 제거된다.

연결 정보가 제거된 후 패킷이 전송되면, Security Group은 이를 새로운 연결로 인식하지 못하고 drop한다. 이것이 바로 "silent drop" 현상의 원인이다.

C5 vs M8i: 무엇이 달라졌나

⚠️ 영향 범위: M8i뿐 아니라 Nitro v6를 사용하는 C8i, R8i 등 최신 세대 인스턴스 모두 해당된다. 이는 성능 최적화를 위해 AWS가 의도적으로 변경한 기본값이며, AWS 공식 문서에서도 안내하고 있다.

장애 흐름

• 0:00 — 애플리케이션 ↔ Oracle DB 사이에 TCP 연결 수립. HikariCP pool에 유지됨.
• 0:00 ~ 5:50 — 쿼리 없음. 연결은 idle 상태 유지.
• 5:50 (350초) — Nitro v6 connection tracking 테이블에서 해당 연결 정보 제거됨.
• 이후 쿼리 시도 — Security Group이 패킷을 신규 연결로 인식하지 못함 → silent drop → 커넥션 오류 발생.

조치

1. M8i → 7세대 인스턴스로 롤백 — 즉각적인 서비스 안정화 우선
2. 추후 최적 옵션 검토 — Nitro v6 전환 시 keepalive 튜닝 등 워크로드 특성에 맞는 설정 사전 검토 후 재전환 예정

근본 해결책: HikariCP Keepalive 설정

Nitro v6 인스턴스를 계속 사용해야 한다면, 350초 안에 keepalive 패킷을 보내도록 설정한다. 충분한 여유를 두고 2분(120,000ms) 으로 설정하는 것을 권장한다.

application.properties

spring.datasource.hikari.keepalive-time=120000

커스텀 prefix 사용 시:

# ❌ 무시됨
legacy.datasource.keepalive-time=120000

# ✅ HikariCP에 실제 적용됨
legacy.datasource.hikari.keepalive-time=120000

.hikari. 없이 설정하면 HikariCP에 적용되지 않고 무시된다. 반드시 hikari 네임스페이스를 포함해야 한다.

Bean으로 직접 등록하는 경우

@Bean
@ConfigurationProperties("legacy.datasource.hikari")
public HikariDataSource legacyDataSource() {
    return new HikariDataSource();
}

핵심 정리

• ✅ 원인: Nitro v6(M8i, C8i, R8i 등)은 TCP Established idle timeout이 5일 → 350초로 단축됨
• ✅ 현상: Idle 커넥션이 350초 후 Security Group에서 제거 → 다음 쿼리 시 silent drop
• ✅ 즉각 조치: 7세대 인스턴스로 롤백
• ✅ 근본 해결: HikariCP keepalive-time=120000 설정으로 350초 이내 keepalive 전송

⚠️ 참고: Nitro v6 인스턴스(M8i, C8i, R8i 등 최신 세대)로 전환 시 동일 현상 발생 가능. 워크로드의 idle 커넥션 특성을 사전에 반드시 검토할 것.

5편까지 Redis 동시성 제어와 Kafka 비동기 처리를 구현했다. 이번 편에서는 k6를 사용해서 실제로 동시 주문이 들어왔을 때 재고가 정확히 차감되는지 성능 테스트로 검증했다.

k6란?

k6는 JavaScript로 테스트 스크립트를 작성할 수 있는 오픈소스 성능 테스트 툴이다. Postman처럼 API를 호출하는데, 동시에 수백 명이 요청하는 상황을 시뮬레이션할 수 있다.

brew install k6

테스트 시나리오

목표: 재고 100개인 상품에 200명이 동시에 주문했을 때, 100건만 성공하고 나머지는 재고 부족으로 차단되는지 검증

테스트 스크립트

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    vus: 200,        // 동시 사용자 200명
    duration: '10s', // 10초 동안
};

export default function () {
    const token = 'Bearer {JWT토큰}';

    const payload = JSON.stringify({
        productId: 2,
        quantity: 1,
    });

    const params = {
        headers: {
            'Content-Type': 'application/json',
            'Authorization': token,
        },
    };

    const res = http.post('http://localhost:8080/order', payload, params);

    check(res, {
        '주문 성공 (201)': (r) => r.status === 201,
        '재고 부족 (400)': (r) => r.status === 400,
    });

    sleep(1);
}

테스트 결과

동시 사용자: 200명
재고: 100개
총 요청: 2000건

주문 성공 (201): 100건  ✅
재고 부족 (400): 1802건 ✅
평균 응답 시간: 54ms
최대 응답 시간: 689ms
처리량: 182건/s

200명이 동시에 요청했지만 딱 100건만 성공했다. 재고를 초과한 주문은 0건.

Redis 동시성 제어 핵심 코드

// StockService.java
public Long decreaseStock(Long productId, int quantity) {
    String key = "stock:" + productId;
    return redisTemplate.opsForValue().increment(key, -quantity);
}

public Long increaseStock(Long productId, int quantity) {
    String key = "stock:" + productId;
    return redisTemplate.opsForValue().increment(key, quantity);
}

// OrderServiceImpl.java
Long remainStock = stockService.decreaseStock(
        createOrderRequestDTO.getProductId(), createOrderRequestDTO.getQuantity()
);

// 재고 부족 체크
if (remainStock < 0) {
    stockService.increaseStock(createOrderRequestDTO.getProductId(), createOrderRequestDTO.getQuantity());
    throw new IllegalArgumentException("재고가 부족합니다.");
}

Redis의 increment 연산은 원자적(Atomic)으로 동작하기 때문에 동시에 여러 요청이 들어와도 정확하게 재고가 차감된다.

Redis가 없었다면?

DB에서 재고를 읽고 차감하는 방식은 아래와 같은 문제가 생긴다.

Thread A: 재고 조회 → 5개 남음
Thread B: 재고 조회 → 5개 남음  ← A가 차감하기 전에 읽음
Thread A: 재고 차감 → 4개
Thread B: 재고 차감 → 4개  ← 실제론 3개여야 하는데!

이런 Race Condition을 Redis의 원자적 연산으로 해결했다.

마치며

k6 성능 테스트를 통해 Redis 동시성 제어가 실제로 동작함을 검증했다.

5편에 걸쳐 DCommerce 프로젝트를 완성했다.

1편 - Entity 설계 + 회원가입
2편 - JWT 로그인
3편 - 상품 + 주문 API
4편 - Redis 동시성 제어
5편 - Kafka 비동기 이벤트
6편 - k6 성능 테스트 (현재)

처음에는 운영 업무만 하다 보니 직접 구조를 짜가며 해볼 기회가 많이 없었는데, 이번 프로젝트를 통해 Spring Boot + Redis + Kafka 조합을 직접 설계하고 구현하며 찍먹해볼 수 있었다.

4편에서 Redis로 동시성 문제를 해결했다. 이번 편에서는 Kafka를 도입해서 주문 완료 이벤트를 비동기로 처리하는 구조를 만들었다.

왜 Kafka인가?

주문이 완료되면 이메일 발송, 포인트 적립, 배송 시작 등 여러 작업이 필요하다. 이걸 동기로 처리하면 문제가 생긴다.

• 이메일 서버가 느리면 주문 API도 느려짐
• 포인트 서비스가 죽으면 주문도 실패

Kafka를 쓰면 주문 서비스는 메시지만 던지고 끝. 나머지 서비스들이 알아서 처리한다.

Kafka 핵심 개념

Topic — 메시지를 저장하는 공간. 우리 프로젝트에서는 order-complete.

Producer — 메시지를 Topic에 발행하는 쪽. 주문 서비스가 담당.

Consumer — Topic을 구독해서 메시지를 읽는 쪽. 이메일/포인트 서비스가 담당.

Consumer Group — 같은 Topic을 여러 서비스가 독립적으로 구독할 수 있음.

Offset — Consumer가 어디까지 읽었는지 기록. 장애 복구 시 이어서 읽기 가능.

구현

1. 의존성 추가

implementation 'org.springframework.kafka:spring-kafka'

2. KafkaConfig

@Configuration
public class KafkaConfig {

    @Bean
    public ProducerFactory<String, String> producerFactory(
            @Value("${spring.kafka.bootstrap-servers}") String bootstrapServers) {
        Map<String, Object> config = new HashMap<>();
        config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        config.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        config.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        return new DefaultKafkaProducerFactory<>(config);
    }

    @Bean
    public KafkaTemplate<String, String> kafkaTemplate(ProducerFactory<String, String> producerFactory) {
        return new KafkaTemplate<>(producerFactory);
    }

    @Bean
    public ConsumerFactory<String, String> consumerFactory(
            @Value("${spring.kafka.bootstrap-servers}") String bootstrapServers) {
        Map<String, Object> config = new HashMap<>();
        config.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        config.put(ConsumerConfig.GROUP_ID_CONFIG, "order-group");
        config.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        config.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        config.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        return new DefaultKafkaConsumerFactory<>(config);
    }

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory(
            ConsumerFactory<String, String> consumerFactory) {
        ConcurrentKafkaListenerContainerFactory<String, String> factory =
                new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory);
        return factory;
    }
}

3. OrderEventProducer

@Component
@RequiredArgsConstructor
public class OrderEventProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public void sendOrderComplete(Long orderId) {
        kafkaTemplate.send("order-complete", String.valueOf(orderId));
    }
}

4. OrderEventConsumer

@Component
public class OrderEventConsumer {

    private static final Logger log = LoggerFactory.getLogger(OrderEventConsumer.class);

    @KafkaListener(topics = "order-complete", groupId = "order-group")
    public void handleOrderComplete(String orderId) {
        log.info("주문 완료 이벤트 수신 — orderId: {}", orderId);
    }
}

5. OrderService에 이벤트 발행 추가

orderRepository.save(order);
orderItemRepository.save(orderItem);
orderEventProducer.sendOrderComplete(order.getId()); // 주문 완료 이벤트 발행

6. application.properties

spring.kafka.bootstrap-servers=localhost:9092

spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer

spring.kafka.consumer.group-id=order-group
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.auto-offset-reset=earliest

동작 확인

주문 API 호출 후 Kafka Topic에 메시지가 쌓이는 것을 확인했다.

kafka-console-consumer --topic order-complete --bootstrap-server localhost:9092 --from-beginning

orderId가 순서대로 출력되는 것을 확인했다.

At Least Once 전략

Kafka Consumer 전략은 크게 세 가지다.

우리 프로젝트는 At Least Once 전략을 채택했다. 중복 처리 방지는 orderId 기반 체크로 멱등성을 보장할 수 있다.

"At Least Once 전략을 사용하고, 중복 처리 방지를 위해 orderId 기반 멱등성을 보장했습니다."

마치며

이번 편에서 Kafka를 도입해서 주문 완료 이벤트를 비동기로 발행하는 구조를 완성했다. 다음 편에서는 성능 테스트와 README, GitHub 정리를 진행할 예정이다.

왜 동시성 문제가 발생할까?

기존 코드는 이런 흐름이었다:

1. DB에서 재고 조회
2. 재고 확인
3. 재고 차감
4. DB 저장

동시에 2명이 주문하면:

재고: 1개

A: 재고 조회 → 1개 있음
B: 재고 조회 → 1개 있음 (A가 아직 차감 안 함)
A: 재고 차감 → 0개
B: 재고 차감 → -1개 💥 overselling 발생!

재고가 마이너스가 되는 overselling 문제가 발생한다.

Redis로 해결하는 이유

Redis의 increment 연산은 원자적(Atomic) 으로 처리된다.

동시에 100명이 요청해도 Redis는 순서대로 하나씩 처리
→ 재고가 절대 음수가 되지 않음

Redis 설정

의존성 추가

implementation 'org.springframework.boot:spring-boot-starter-data-redis'

application.yml

spring:
  data:
    redis:
      host: localhost
      port: 6379

RedisConfig

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, String> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        return template;
    }
}

StockService 구현

Redis에 재고를 관리하는 서비스. 키 형식은 stock:{productId} 로 상품별로 관리한다.

@Service
@RequiredArgsConstructor
public class StockService {

    private final RedisTemplate<String, String> redisTemplate;

    private String getStockKey(Long productId) {
        return "stock:" + productId;
    }

    // 재고 초기화 (상품 등록 시 호출)
    public void initStock(Long productId, int quantity) {
        redisTemplate.opsForValue().set(getStockKey(productId), String.valueOf(quantity));
    }

    // 재고 차감 (원자적 연산 핵심!)
    public Long decreaseStock(Long productId, int quantity) {
        return redisTemplate.opsForValue().increment(getStockKey(productId), -quantity);
    }

    // 재고 증가 (차감 실패 시 롤백용)
    public void increaseStock(Long productId, int quantity) {
        redisTemplate.opsForValue().increment(getStockKey(productId), quantity);
    }

    // 재고 조회
    public int getStock(Long productId) {
        String value = redisTemplate.opsForValue().get(getStockKey(productId));
        return value == null ? 0 : Integer.parseInt(value);
    }
}

상품 등록 시 Redis 재고 초기화

public void createProduct(ProductCreateRequestDTO dto) {
    Product savedProduct = productRepository.save(product);
    stockService.initStock(savedProduct.getId(), savedProduct.getStockQuantity());
}

주문 시 Redis 재고 차감

@Transactional
public void createOrder(Long memberId, CreateOrderRequestDTO dto) {
    // Redis에서 원자적으로 재고 차감
    Long remainStock = stockService.decreaseStock(
            dto.getProductId(),
            dto.getQuantity()
    );

    // 재고 부족 시 롤백
    if (remainStock < 0) {
        stockService.increaseStock(dto.getProductId(), dto.getQuantity());
        throw new IllegalArgumentException("재고가 부족합니다.");
    }
}

왜 차감 후 체크하나? Redis increment는 차감 후 결과를 반환한다. 음수가 되면 재고 초과이므로 즉시 롤백하고 예외를 던진다.

동시성 테스트

재고 7개 상품에 10개 동시 요청:

for i in {1..10}; do
  curl -s -X POST http://localhost:8080/order \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"productId": 1, "quantity": 1}' &
done
wait

redis-cli GET stock:1

결과

시작 재고: 7개
동시 요청: 10개
결과 재고: 0개 ✅
성공: 7개 / 실패(재고 부족): 3개 ✅

재고가 음수가 되지 않고 정확히 0에서 멈췄다.

정리 포인트

"Redis의 increment 연산은 싱글스레드 기반의 원자적 연산으로, 동시 요청이 몰려도 순서대로 처리되어 overselling을 방지합니다. 10개 동시 요청 테스트에서 재고 초과분은 정상적으로 차단됨을 확인했습니다."

오늘 배운 것

• Redis Key-Value 구조와 활용법
• increment 원자적 연산으로 동시성 문제 해결
• overselling 문제와 해결 방법
• 재고 차감 후 음수 체크 + 롤백 패턴
• 동시성 테스트 방법 (curl 병렬 요청)

요구사항 정의

상품 API

1. 상품 등록 — 상품명, 가격, 재고수량 입력받아 등록
2. 상품 목록 조회 — 전체 상품 목록 조회
3. 상품 단건 조회 — 상품 ID로 특정 상품 조회, 없으면 예외

주문 API

1. 주문 생성 — 로그인한 회원만 가능 (JWT 필요)
              상품 ID + 수량으로 주문 생성
              재고 부족 시 예외
              주문 생성 시 재고 차감
2. 내 주문 목록 조회 — 로그인한 회원의 주문 목록 조회

정적 팩토리 메서드 (Static Factory Method)

new 키워드 대신 static 메서드로 객체를 생성하는 패턴.

// 일반 생성자
ProductListResponseDTO dto = new ProductListResponseDTO(product.getId(), product.getName(), ...);

// 정적 팩토리 메서드
ProductListResponseDTO dto = ProductListResponseDTO.from(product);

장점

첫째, 이름을 줄 수 있다

// 이게 뭘 만드는지 한눈에 알아?
new ProductListResponseDTO(1L, "상품명", 1000, 10);

// 이건?
ProductListResponseDTO.from(product);  // Product로부터 DTO 만든다

둘째, Entity 변경이 한 곳에 집중된다

Product 필드가 추가되거나 바뀌면 from() 메서드 하나만 고치면 된다.

셋째, Setter가 필요 없어진다

Setter 없이 객체를 불변으로 만들 수 있다.

"정적 팩토리 메서드는 객체 생성의 의도를 명확히 하고, 변환 로직을 한 곳에 모아 유지보수성을 높이기 위해 사용합니다."

상품 API 구현

ProductService

@RequiredArgsConstructor
@Service
public class ProductServiceImpl implements ProductService {

    private final ProductRepository productRepository;

    @Override
    public void createProduct(ProductCreateRequestDTO dto) {
        if (dto.getPrice() < 0) {
            throw new IllegalArgumentException("가격이 음수입니다.");
        }
        if (dto.getStockQuantity() < 0) {
            throw new IllegalArgumentException("재고가 0보다 작습니다.");
        }

        Product product = Product.builder()
                .name(dto.getName())
                .price(dto.getPrice())
                .stockQuantity(dto.getStockQuantity())
                .build();

        productRepository.save(product);
    }

    @Override
    public List<ProductListResponseDTO> getProductList() {
        List<Product> all = productRepository.findAll();
        List<ProductListResponseDTO> result = new ArrayList<>();
        for (Product product : all) {
            result.add(ProductListResponseDTO.from(product));
        }
        return result;
    }

    @Override
    public ProductDetailResponseDTO getProductDetail(Long id) {
        Product product = productRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 상품입니다."));
        return ProductDetailResponseDTO.from(product);
    }
}

포인트: orElseThrow() 활용 Optional.get()을 바로 쓰면 NPE 위험이 있다. orElseThrow()로 값이 없을 때 명확한 예외를 던져야 한다.

ProductController

@RequiredArgsConstructor
@RestController
@RequestMapping("/product")
public class ProductController {

    private final ProductService productService;

    @PostMapping
    public ResponseEntity<Void> createProduct(@RequestBody ProductCreateRequestDTO dto) {
        productService.createProduct(dto);
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }

    @GetMapping
    public ResponseEntity<List<ProductListResponseDTO>> getProductList() {
        return ResponseEntity.ok(productService.getProductList());
    }

    @GetMapping("/{productId}")
    public ResponseEntity<ProductDetailResponseDTO> getProductDetail(@PathVariable Long productId) {
        return ResponseEntity.ok(productService.getProductDetail(productId));
    }
}

포인트: 등록 API는 201 Created 반환

"등록 API는 자원이 생성됐음을 명확히 하기 위해 200 OK 대신 201 Created를 반환했습니다."

주문 API 구현

재고 차감 설계 — 도메인 메서드

재고 차감 로직을 Product Entity 안에 메서드로 만들었다.

재고 차감 로직 → Product 도메인 메서드
재고 차감 호출 → OrderService

Entity가 자기 상태를 스스로 변경하는 방식 — Setter 없이 안전하게 처리한다.

// Product.java
public void decreaseStockQuantity(int quantity) {
    if (this.stockQuantity < quantity) {
        throw new IllegalArgumentException("재고가 부족합니다.");
    }
    this.stockQuantity -= quantity;
}

OrderService

@RequiredArgsConstructor
@Service
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final ProductRepository productRepository;
    private final OrderRepository orderRepository;
    private final OrderItemRepository orderItemRepository;

    @Transactional
    @Override
    public void createOrder(Long memberId, CreateOrderRequestDTO dto) {
        // 1. 회원 조회
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new IllegalArgumentException("등록된 회원이 아닙니다."));

        // 2. 상품 조회
        Product product = productRepository.findById(dto.getProductId())
                .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 상품입니다."));

        // 3. 주문 생성
        Order order = Order.builder()
                .member(member)
                .orderPrice((long) (dto.getQuantity() * product.getPrice()))
                .orderStatus(OrderStatus.ORDERED)
                .orderedAt(LocalDateTime.now())
                .build();

        // 4. 주문아이템 생성 (주문 당시 가격 스냅샷)
        OrderItem orderItem = OrderItem.builder()
                .order(order)
                .product(product)
                .quantity(dto.getQuantity())
                .orderPrice(product.getPrice())
                .build();

        // 5. 재고 차감
        product.decreaseStockQuantity(dto.getQuantity());

        // 6. 저장
        orderRepository.save(order);
        orderItemRepository.save(orderItem);
    }
}

포인트 1: @Transactional

재고 차감, 주문 저장, 주문아이템 저장이 하나의 트랜잭션으로 묶여야 한다. 중간에 하나라도 실패하면 전부 롤백된다.

// Spring 거로 임포트해야 함
import org.springframework.transaction.annotation.Transactional;
// Jakarta 거 아님!

포인트 2: OrderItem에 가격 스냅샷 저장

상품 가격이 나중에 바뀌어도 주문 당시 가격을 유지하기 위해 OrderItem에 orderPrice를 따로 저장한다.

OrderController

@RequiredArgsConstructor
@RequestMapping("/order")
@RestController
public class OrderController {

    private final OrderService orderService;

    @PostMapping
    public ResponseEntity<Void> createOrder(
            HttpServletRequest request,
            @RequestBody CreateOrderRequestDTO dto) {
        Long memberId = (Long) request.getAttribute("memberId");
        orderService.createOrder(memberId, dto);
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }
}

포인트: memberId는 JWT에서 꺼낸다

JwtInterceptor에서 토큰 검증 후 request.setAttribute("memberId", memberId)로 저장해뒀기 때문에 Controller에서 request.getAttribute("memberId")로 꺼내 쓸 수 있다.

API 테스트

상품 등록

POST http://localhost:8080/product
Content-Type: application/json

{
    "name": "맥북 프로",
    "price": 3000000,
    "stockQuantity": 10,
    "description": "M3 Pro 칩셋"
}

주문 생성

POST http://localhost:8080/order
Authorization: Bearer {JWT토큰}
Content-Type: application/json

{
    "productId": 1,
    "quantity": 2
}

@Builder.Default 주의사항

@Builder와 컬렉션 초기화를 함께 쓸 때 경고가 발생한다:

// 경고 발생
private List<OrderItem> orderItemList = new ArrayList<>();

// 해결
@Builder.Default
private List<OrderItem> orderItemList = new ArrayList<>();

@Builder는 기본값 초기화를 무시하기 때문에 @Builder.Default를 붙여야 빌더로 생성할 때도 빈 리스트가 초기화된다.

오늘 배운 것

• 정적 팩토리 메서드 패턴과 장점
• orElseThrow()로 안전한 Optional 처리
• 도메인 메서드로 Entity 상태 변경 (Setter 없이)
• @Transactional로 원자적 트랜잭션 처리
• JWT에서 memberId 꺼내는 방법
• 201 Created vs 200 OK 차이
• @Builder.Default 사용법

JWT란?

JWT(JSON Web Token)는 로그인 인증에 사용되는 토큰 방식이야.

핵심 포인트: 서버는 토큰을 저장하지 않는다.

일반적인 세션 방식은 서버가 로그인 상태를 저장하지만, JWT는 다르다. 서버는 Secret Key로 서명만 해서 클라이언트에게 토큰을 발급하고, 이후 요청마다 그 서명이 유효한지만 검증한다. DB 조회 없이.

그래서 JWT의 장점은 Stateless(무상태) — 서버가 상태를 저장하지 않아도 된다.

JWT 동작 흐름

① 클라이언트 → 서버: email + password 전송
② 서버 → DB: 유저 조회
③ DB → 서버: 유저 정보 반환
④ 서버: 비밀번호 검증 + JWT 생성 (서명)
⑤ 서버 → 클라이언트: JWT 반환
⑥ 이후 API 요청 시: Authorization: Bearer {token} 헤더에 포함
⑦ 서버: 서명 검증 (DB 조회 없이!)

JWT 구조

JWT는 3개 파트로 구성된다:

header.payload.signature

eyJhbGc... . eyJ1c2VySWQiOjF9 . SflKxwRJSMeKKF2QT4...

• header — 알고리즘 정보 (HS256)
• payload — 담을 데이터 (userId, email, 만료시간)
• signature — 위 두 개를 Secret Key로 서명한 값

서명이란?

서명은 "내가 만든 토큰이 맞다"는 증명이다.

누군가 payload를 { userId: 99 }로 바꾸면? Secret Key가 없으니 signature를 다시 못 만든다. 서버가 검증할 때 "이 서명 이상한데?" 하고 바로 거부한다.

"payload가 중간에 변조되지 않았다는 걸 Secret Key로 보증하는 것"

의존성 추가

build.gradle에 JWT 라이브러리 추가:

implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

application.yml에 Secret Key 설정:

jwt:
  secret: mysecretkey12345678901234567890123456789012
  expiration: 86400000  # 24시간 (ms)

JwtProvider 구현

JWT 생성, 검증, userId 추출 3가지 기능을 담당하는 유틸 클래스:

@Component
public class JwtProvider {

    @Value("${jwt.secret}")
    private String secretKey;

    @Value("${jwt.expiration}")
    private long expiration;

    // 토큰 생성
    public String generateToken(Long userId, String email) {
        return Jwts.builder()
                .setSubject(String.valueOf(userId))
                .claim("email", email)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + expiration))
                .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()), SignatureAlgorithm.HS256)
                .compact();
    }

    // 토큰 검증
    public boolean validateToken(String token) {
        try {
            Jwts.parserBuilder()
                    .setSigningKey(Keys.hmacShaKeyFor(secretKey.getBytes()))
                    .build()
                    .parseClaimsJws(token);
            return true;
        } catch (Exception e) {
            return false;
        }
    }

    // userId 추출
    public Long getUserId(String token) {
        String subject = Jwts.parserBuilder()
                .setSigningKey(Keys.hmacShaKeyFor(secretKey.getBytes()))
                .build()
                .parseClaimsJws(token)
                .getBody()
                .getSubject();
        return Long.parseLong(subject);
    }
}

왜 try-catch로 검증하나? 토큰이 만료되거나 서명이 틀리면 Jwts가 예외를 던진다. 그걸 잡아서 false를 반환하는 방식으로 유효성을 검증한다.

로그인 API 구현

MemberRepository

@Repository
public interface MemberRepository extends JpaRepository<Member, Long> {
    boolean existsMemberByEmail(String email);
    Optional<Member> findByEmail(String email);  // 로그인용 추가
}

MemberService

@Override
public LoginResponseDTO login(LoginRequestDTO loginRequestDTO) {
    // 1. 이메일로 유저 조회
    Member member = memberRepository.findByEmail(loginRequestDTO.getEmail())
            .orElseThrow(() -> new IllegalArgumentException("가입되지 않은 회원입니다."));

    // 2. 비밀번호 확인
    if (!passwordEncoder.matches(loginRequestDTO.getPassword(), member.getPassword())) {
        throw new IllegalArgumentException("비밀번호가 틀렸습니다.");
    }

    // 3. JWT 발급
    String token = jwtProvider.generateToken(member.getId(), member.getEmail());

    return new LoginResponseDTO(member.getId(), token);
}

포인트 1: orElseThrow() 활용 Optional.isPresent() 체크보다 훨씬 깔끔하다. 값이 없으면 바로 예외를 던진다.

포인트 2: passwordEncoder.matches() 사용 비밀번호는 BCrypt로 암호화되어 저장되므로 평문과 직접 비교하면 안 된다. matches(평문, 암호화된값)으로 비교해야 한다.

LoginResponseDTO

@Getter
@AllArgsConstructor
public class LoginResponseDTO {
    private Long memberId;
    private String token;
}

MemberController

@PostMapping("/login")
public ResponseEntity<LoginResponseDTO> login(@RequestBody LoginRequestDTO loginRequestDTO) {
    LoginResponseDTO response = memberService.login(loginRequestDTO);
    return ResponseEntity.ok(response);
}

JwtInterceptor 설정

로그인, 회원가입 URI는 토큰 검증 없이 통과시키도록 설정:

@Component
@RequiredArgsConstructor
public class JwtInterceptor implements HandlerInterceptor {

    private final JwtProvider jwtProvider;

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response, Object handler) throws Exception {
        String uri = request.getRequestURI();

        // 로그인, 회원가입은 토큰 검증 스킵
        if (uri.startsWith("/member/login") || uri.startsWith("/member/signUp")) {
            return true;
        }

        String authHeader = request.getHeader("Authorization");
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            response.setStatus(401);
            return false;
        }

        String token = authHeader.substring(7);
        if (!jwtProvider.validateToken(token)) {
            response.setStatus(401);
            return false;
        }

        Long memberId = jwtProvider.getUserId(token);
        request.setAttribute("memberId", memberId);
        return true;
    }
}

테스트 결과

POST http://localhost:8080/member/login

{
    "email": "test@test.com",
    "password": "1234"
}

응답:

{
    "memberId": 1,
    "token": "eyJhbGciOiJIUzI1NiJ9.eyJ..."
}

주의사항: ddl-auto 설정

개발 중 ddl-auto: create로 설정하면 서버 재시작 시 테이블이 드롭되고 데이터가 날아간다. 데이터를 유지하려면 update로 변경해야 한다.

spring:
  jpa:
    hibernate:
      ddl-auto: update  # create → update

오늘 배운 것

• JWT 구조와 Stateless 인증 방식
• 서명(Signature)의 역할 — 변조 방지
• JwtProvider 구현 (생성/검증/추출)
• passwordEncoder.matches()로 암호화 비밀번호 비교
• Optional.orElseThrow() 패턴
• ddl-auto: create vs update 차이

다음 포스팅: 상품 API + 주문 API 구현

프로젝트 개요

대용량 주문 처리 API 서버를 만들면서 Java 백엔드 기술을 정리합니다.

기술 스택

• Spring Boot 3.2.x
• Java 17
• MySQL + JPA
• Redis
• Kafka
• JWT 인증

ERD 설계

주문 시스템에 필요한 테이블 5개를 설계했습니다.

Member ─ 1:N ─ Order ─ 1:N ─ OrderItem ─ N:1 ─ Product
                 │
                1:1
                 │
             Delivery

order_items에 price를 따로 저장하는 이유

주문 당시 가격을 스냅샷으로 저장합니다. 상품 가격이 나중에 변경되더라도 주문 이력은 결제 시점 금액을 유지해야 하기 때문입니다.

Entity 설계

Member.java

@Builder
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Getter
@Entity
public class Member {

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

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

    @Column(nullable = false)
    private String password;

    private String userName;

    @OneToMany(mappedBy = "member")
    private List<Order> orderList;

    @CreationTimestamp
    private LocalDateTime createdAt;
}

Order.java

@Getter
@Table(name = "orders")
@Entity
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ORDER_ID")
    private Long id;

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

    @OneToMany(mappedBy = "order")
    private List<OrderItem> orderItemList = new ArrayList<>();

    @OneToOne(mappedBy = "order", fetch = FetchType.LAZY)
    private Delivery delivery;

    @Enumerated(EnumType.STRING)
    private OrderStatus orderStatus;

    private Long orderPrice;

    @Enumerated(EnumType.STRING)
    private PaymentStatus paymentStatus;

    @Enumerated(EnumType.STRING)
    private OrderType orderType;

    private LocalDateTime orderedAt;
    private LocalDateTime paidAt;
}

OrderItem.java

@Getter
@Table(name = "ORDER_ITEM")
@Entity
public class OrderItem {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ORDER_ITEM_ID")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private Order order;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id")
    private Product product;

    private int quantity;
    private int orderPrice;
}

Product.java

@Getter
@Table(name = "product")
@Entity
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "PRODUCT_ID")
    private Long id;

    private String name;
    private int price;
    private int stockQuantity;
    private LocalDateTime createdAt;
}

Delivery.java

@Getter
@Table(name = "deliveries")
@Entity
public class Delivery {

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

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private Order order;

    private String address;

    @Enumerated(EnumType.STRING)
    private DeliveryEnum status;

    private LocalDateTime createdAt;
}

연관관계 정리

mappedBy란?

양방향 연관관계에서 연관관계의 주인을 지정합니다. 주인이 아닌 쪽은 외래키를 관리하지 않고 조회만 가능합니다.

// Order가 주인 — member_id 외래키 관리
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;

// Member는 주인 아님 — 읽기만 가능
@OneToMany(mappedBy = "member")
private List<Order> orderList;

FetchType.LAZY를 쓰는 이유

연관된 Entity를 실제로 사용할 때 쿼리를 날립니다. EAGER는 연관 Entity를 무조건 즉시 로딩해서 불필요한 쿼리가 발생할 수 있습니다.

회원가입 API

MemberRepository.java

@Repository
public interface MemberRepository extends JpaRepository<Member, Long> {
    boolean existsMemberByEmail(String email);
}

MemberService.java

public Long signUp(SignUpRequest signUpRequest) {
    // 이메일 중복 체크
    boolean isAlreadyMember = memberRepository.existsMemberByEmail(signUpRequest.getEmail());
    if (isAlreadyMember) {
        throw new IllegalArgumentException("이미 가입된 회원 이메일입니다.");
    }

    // 비밀번호 암호화
    String encodePassword = passwordEncoder.encode(signUpRequest.getPassword());

    // 빌더 패턴으로 객체 생성
    Member member = Member.builder()
            .email(signUpRequest.getEmail())
            .password(encodePassword)
            .userName(signUpRequest.getUserName())
            .build();

    memberRepository.save(member);
    return member.getId();
}

MemberController.java

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

    private final MemberService memberService;

    @PostMapping("/signUp")
    public ResponseEntity<Long> signUp(@RequestBody SignUpRequest signUpRequest) {
        memberService.signUp(signUpRequest);
        return ResponseEntity.ok().build();
    }
}

API 호출 테스트

POST http://localhost:8080/member/signUp
Content-Type: application/json

{
    "email": "test@test.com",
    "password": "1234",
    "userName": "홍길동"
}

오늘 배운 것

• JPA Entity 설계 및 연관관계 매핑 (1:N, N:1, 1:1)
• mappedBy로 연관관계 주인 지정
• @Builder + @NoArgsConstructor 함께 쓰는 법
• Entity에 @Setter를 쓰면 안 되는 이유
• 이메일 중복체크 + 비밀번호 암호화 적용

Primary Key는 테이블에서 각 행(row)을 유일하게 식별하는 컬럼입니다.

즉 중복될 수 없고 NULL도 허용되지 않습니다.

예시

CREATE TABLE member (
    id BIGINT PRIMARY KEY,
    email VARCHAR(255),
    name VARCHAR(100)
);

여기서 id가 PK입니다.

PK 특징

• 유일성 (Uniqueness)

• 같은 값이 존재할 수 없습니다.
• NOT NULL
• 테이블당 하나만 존재
• Index 자동 생성
• 대부분의 데이터베이스에서는 Primary Key를 생성하면 자동으로 Index가 생성됩니다.

2. Foreign Key (FK)

Foreign Key는 다른 테이블의 PK를 참조하는 컬럼입니다. 즉 테이블 간 관계(Relation) 를 만들기 위한 키입니다.

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    member_id BIGINT,
    FOREIGN KEY (member_id) REFERENCES member(id)
);

orders.member_id → member.id 관계가 Foreign Key입니다.

FK의 역할

Foreign Key는 데이터 무결성(Data Integrity) 을 보장합니다.

3. Unique Key

Unique Key는 중복을 허용하지 않는 제약조건입니다. 즉 식별자 역할이 아니라 데이터 중복 방지 목적으로 사용됩니다.

UK 특징

• 중복 불가능

• NULL 허용 (DB에 따라 여러 개 가능)
• 여러 개 생성 가능
• Index 생성
• 식별자 역할은 아님

CREATE TABLE member (
    id BIGINT PRIMARY KEY,
    email VARCHAR(255) UNIQUE
);

4. Composite Key (복합키)

Composite Key는 여러 컬럼을 합쳐서 하나의 PK로 사용하는 것입니다.

JPA에서 Composite Key 매핑

JPA에서는 복합키를 사용할 때 두 가지 방법이 있습니다.

1️⃣ @IdClass

@Entity
@IdClass(OrderItemId.class)
public class OrderItem {

    @Id
    private Long orderId;

    @Id
    private Long productId;

}

public class OrderItemId implements Serializable {

    private Long orderId;
    private Long productId;

}

2️⃣ @EmbeddedId

@Entity
public class OrderItem {

    @EmbeddedId
    private OrderItemId id;

}

@Embeddable
public class OrderItemId implements Serializable {

    private Long orderId;
    private Long productId;

}

1. 들어가기 (Why?)

• 이 개념을 공부해야 하는 이유
• 실무에서 IoC/DI가 중요한 상황 설명

2. 기본 개념 정리 (What?)

• IoC (Inversion of Control)

  • 정의
  • 특징

• DI (Dependency Injection)

  • 정의
  • 주입 방식 (생성자, Setter, 필드)

• Spring Container & Bean

  • Bean 개념
  • ApplicationContext 역할

3. 동작 과정 (How?)

• IoC 컨테이너가 Bean을 생성하고 관리하는 흐름
• 의존성 주입이 일어나는 과정
• Bean LifeCycle (생성 → 주입 → 초기화 → 소멸)

4. 내부 동작 원리 (Deep Dive)

• ApplicationContext 동작 과정
• Bean 등록 및 주입 과정 설명
• AOP/프록시와 연결되는 지점

5. 실무 인사이트 (Real World)

• IoC/DI가 테스트 코드에 미치는 영향
• 아키텍처 설계 확장성에 기여하는 사례
• 실제 프로젝트에서 부딪힌 문제 (예: 순환 참조)

6. 자주 하는 실수 & 베스트 프랙티스

• 필드 주입(@Autowired) 남용의 문제점
• 생성자 주입 권장 이유
• 순환 참조 문제 해결 방법
• Bean 등록 중복 방지 전략

7. 정리 (Summary)

• IoC 핵심 요약
• DI 핵심 요약
• 오늘 글을 통해 얻을 수 있는 교훈 한 줄

8. 참고 자료

• Spring 공식 문서
• 토비의 스프링 (이일민 저)
• 기타 참고 블로그/자료

• 문제 번호: 11050
• 푼 날짜: 2025-08-31

📌 문제 요약

이항 계수가 무엇인지 이해하고 공식화 하면 되는 문제!

💡 접근 아이디어

1. 이항계수 공식을 적용하자
2. 헷갈려서 나누는 분모를 자꾸 여러번틀림

🛠️ Java 구현

package BaekJoon.basic.bruteForce;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Q11050 {

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        StringTokenizer st = new StringTokenizer(br.readLine());
        int a = Integer.parseInt(st.nextToken());
        int b = Integer.parseInt(st.nextToken());

        if(b ==1){
            System.out.println(a);
            return;
        }else if(b==0){
            System.out.println(1);
            return ;
        }

        int ans = 1;

        for(int i=0; i<b; i++){
            ans *= a-i ;
        }

        ans = ans/makeFactorial(b);

        System.out.println(ans);
    }

    public static int makeFactorial(int n ){
        int result = 1 ;
        for(int i=1; i<=n; i++){
            result *= i;
        }
        return result;
    }
}

스스로 피드백 해보기

> 구글링해서 공식을 다시 알게됐고 오랜만에 팩토리얼 사용

• 문제 번호: 1032
• 푼 날짜: 2025-08-31

📌 문제 요약

배열을 입력받아 n개의 배열에서 다른값을 가진 인덱스에 ? 를 넣어주면되는 문제

💡 접근 아이디어

1. 숫자를 입력받아보자
2. 숫자만큼 String[] 배열을 입력받아보자
3. 배열을 비교하고 다르면 ? 를 넣는것을 구현해보자

🛠️ Java 구현

package BaekJoon.basic.bruteForce;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Q1032 {

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        int n = Integer.parseInt(br.readLine());

        String[] arr = new String[n];

        for (int i = 0; i < n; i++) {
            arr[i] = br.readLine();
        }

        int len = arr[0].length();

        StringBuilder sb = new StringBuilder();

        for (int i = 0; i < len; i++) {
            char c = arr[0].charAt(i);
            boolean isSame = true;

            for (int j = 1; j < n; j++) {
                if (arr[j].charAt(i) != c) {
                    isSame = false;
                    break; 
                }
            }

            if (isSame) {
                sb.append(c);
            } else {
                sb.append("?");
            }
        }


        System.out.println(sb);

    }
}

스스로 피드백 해보기

> 두달만에 문제를 풀어서 브론즈1부터 시도해보았다

> 입출력 연습으로 느껴져서 할만했다

> 근데 2번 틀렸다 flag로 구분할때 좀 헷갈려서 index를 초과되게 append되어 에러가 났었고 break로 불필요한 구분제거했다

• 문제 번호: 1107
• 푼 날짜: 2025-06-10

문제 링크

https://www.acmicpc.net/problem/1107

📌 문제 요약

💡 접근 아이디어

다음에 떠 올려 봐야할 것

🛠️ Java 구현

package BaekJoon.basic;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Q1476 {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder sb = new StringBuilder();

        StringTokenizer st = new StringTokenizer(br.readLine());
        int e = Integer.parseInt(st.nextToken());
        int s = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());

        int year = 0;

        while(true) {
            year++;  
            if ((year - e) % 15 == 0 && (year - s) % 28 == 0 && (year - m) % 19 == 0) {
                break;
            }
        }

        System.out.println(year);

    }
}

스스로 피드백 해보기

> 구현력이 아직 매우 부족하다.

• 문제 번호: 1476
• 푼 날짜: 2025-06-08

📌 문제 요약

각 주기가 있고 15, 28, 19.. 각 주기에 값이 주어지면 공통 주기로 인해 몇년인지 구하는 문제

💡 접근 아이디어

1. 1 16 16 의 첫번째 테스트 케이스 분석
2. 16년 일때 지구의 값이 1인데 16%15가 1임을 확인
3. 각 주기의 나머지를 통해 년도를 구해본다.
4. 주어진 주기 E,S,M 의 값의 나머지가 모두 0이면 해당 년도가 정답이다.

🛠️ Java 구현

package BaekJoon.basic;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Q1476 {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder sb = new StringBuilder();

        StringTokenizer st = new StringTokenizer(br.readLine());
        int e = Integer.parseInt(st.nextToken());
        int s = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());

        int year = 0;

        while(true) {
            year++;  
            if ((year - e) % 15 == 0 && (year - s) % 28 == 0 && (year - m) % 19 == 0) {
                break;
            }
        }

        System.out.println(year);

    }
}

스스로 피드백 해보기

> 구현력이 아직 매우 부족하다.

BOJ 3085 | 사탕 게임 🍬

• 문제 번호: 3085
• 푼 날짜: 2025-06-08

📌 문제 요약

N×N 보드에 다양한 색 사탕이 있고,
인접한 사탕을 한 번 교환할 수 있다.
이때 가장 긴 연속 같은 색 사탕 길이를 구하는 문제.

💡 접근 아이디어

1. 보드의 모든 칸 (i,j)에 대해
2. 우측 (i,j+1) 또는 아래 (i+1,j)와 교환
3. 교환 후 현재 보드에서 calculateMaxCandies() 호출 → 최대 연속 길이 계산
4. 원상복구
5. 최댓값 갱신

calculateMaxCandies()는 다음과 같이 구현:

• 각 행과 각 열에 대해
  • 인접 같은 컬러면 count++, 다른 컬러면 최대값 갱신 후 count = 1 재설정

🛠️ Java 구현

package BaekJoon.basic;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class Q3085 {

    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder sb = new StringBuilder();

        int maxLen = 0;

        int N = Integer.parseInt(br.readLine());

        char[][] board = new char[N][N];

        for (int i = 0; i < N; i++) {
            board[i] = br.readLine().toCharArray();
        }

        for(int i=0; i<N; i++) {
            for(int j=0; j<N; j++){

                if(j <N-1){
                    swap(board,i,j,i,j+1);
                    maxLen=Math.max(maxLen,calculateMaxLength(board,N));
                    swap(board,i,j,i,j+1);
                }

                if(i < N-1){
                    swap(board,i,j, i+1,j);
                    maxLen = Math.max(maxLen,calculateMaxLength(board,N));
                    swap(board,i,j,i+1,j);
                }

            }
        }

        System.out.println(maxLen);

    }

    public static void swap(char[][] board, int x1, int y1 , int x2, int y2){
        char temp = board[x1][y1];
        board[x1][y1] = board[x2][y2];
        board[x2][y2] = temp;
    }

    public static int calculateMaxLength (char[][] board, int N) {
        int maxLen = 0;

        for(int i=0; i< N ; i++){
            int countRow = 1;
            int countCol = 1;

            for(int j=1; j<N; j++) {
                if (board[i][j] == board[i][j - 1]) {
                    countRow++;
                } else {
                    maxLen = Math.max(maxLen, countRow);
                    countRow = 1;
                }

                if (board[j][i] == board[j - 1][i]) {
                    countCol++;
                } else {
                    maxLen = Math.max(countCol, maxLen);
                    countCol = 1;
                }
            }

            maxLen= Math.max(maxLen,countRow);
            maxLen = Math.max(maxLen,countCol);
        }

        return maxLen

    }
}

스스로 피드백 해보기

> 구현력이 아직 매우 부족하다.

> 문제를 제대로 읽지않는다.

> 정의 내리는것을 귀찮아하지말아라.

📚 개요

• 책 제목: Effective Java
• 저자: Joshua Bloch
• 공부 범위: (예: Item 1 ~ Item 5)
• 목표: (예: "자바 코드를 더 안전하고 깔끔하게 작성하는 방법을 학습")

🗂️ 학습한 아이템 요약

✅ Item 1: (아이템 제목)

• 핵심 내용 요약
• 왜 중요한가?
• 예시 코드

  // 예시 코드
  
  
  
  

원하면

• "Item 1~5 양식 예시"나
• "Item별 블로그 꾸미기용 이모지 추천"
• "효율적인 블로그 연재 계획 짜는 방법" 도 추가로 만들어줄게.

추가로 받을래? ✨
(예: "응, Item 1~5 양식도 보여줘!" 이런 식으로 알려줘!)