개요

우편번호 마스터 동기화 배치(ZipcdSyncTasklet)를 신규 개발 후 Jenkins에서 실행했더니, cmm_road_cd_d 테이블은 정상적으로 bulk upsert 되는데 cmm_road_addr_d는 계속 실패했다.

에러 로그만 보면 SQL 파라미터 바인딩 문제처럼 보였지만, 실제 원인은 트랜잭션 매니저 충돌이었다.

프로젝트 구성

트랜잭션 매니저 설정

이 프로젝트는 JPA와 JdbcTemplate을 혼용하며, 두 곳에서 트랜잭션 매니저를 설정한다.

1. DefaultDataSourceConfig — JPA 트랜잭션 매니저 (@Primary)

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(
    basePackages = {"com.gsshop.greenhouse.crocus.domain"},
    entityManagerFactoryRef = "entityManagerFactory",
    transactionManagerRef = "transactionManager"
)
public class DefaultDataSourceConfig {

    @Primary
    @Bean(name = "dataSource")
    @ConfigurationProperties(prefix = "default.datasource")
    public DataSource dataSource() {
        return DataSourceBuilder.create().build();
    }

    @Primary
    @Bean(name = "entityManagerFactory")
    public LocalContainerEntityManagerFactoryBean entityManagerFactory(...) { ... }

    @Primary
    @Bean(name = "transactionManager")
    public PlatformTransactionManager transactionManager(
            @Qualifier("entityManagerFactory") EntityManagerFactory entityManagerFactory) {
        return new JpaTransactionManager(entityManagerFactory);  // ← JPA용 @Primary
    }
}

2. CrocusBatchApplication — 배치 인프라 설정

@EnableBatchProcessing
public class CrocusBatchApplication {

    // JPA 트랜잭션 매니저 (도메인과 동일하게 @Primary)
    @Primary
    @Bean(name = "transactionManager")
    public PlatformTransactionManager transactionManager(
            @Qualifier("entityManagerFactory") EntityManagerFactory entityManagerFactory) {
        return new JpaTransactionManager(entityManagerFactory);
    }

    // 배치 인프라(JobRepository, JobLauncher 등)용 설정
    @Bean
    public BatchConfigurer batchConfigurer() {
        return new BatchConfigurer() {
            private PlatformTransactionManager transactionManager;
            // ...

            @PostConstruct
            public void initialize() {
                if (this.transactionManager == null) {
                    // JobRepository 등 배치 인프라는 ResourcelessTransactionManager 사용
                    this.transactionManager = new ResourcelessTransactionManager();
                }
                MapJobRepositoryFactoryBean jrf =
                    new MapJobRepositoryFactoryBean(this.transactionManager);
                // ...
            }
        };
    }
}

핵심 포인트: 배치 인프라(JobRepository)는 ResourcelessTransactionManager를 쓰고, 실제 도메인 트랜잭션은 JpaTransactionManager(@Primary)를 쓴다.

호출 구조

ZipcdSyncTasklet.execute()                     ← @Transactional 없음
  └─ AddrDailyUpdateService.addrDailySync()    ← @Transactional 없음, try-catch로 예외 삼킴
       └─ AddressToZipcdServiceImpl
               .processRoadAddr()              ← @Transactional (JpaTransactionManager)
            └─ CmmRoadAddrDBulkRepository
                    .batchUpsert()             ← @Transactional + JdbcTemplate

에러 로그

2026-07-03 12:54:55.474 ERROR
  ❌ batchUpdate 중 에러 발생!!
  org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback;
    nested exception is java.sql.SQLException: No value specified for parameter 13

2026-07-03 12:54:55.479 ERROR
  addrDailyUpdate Batch Exception: ... No value specified for parameter 13

2026-07-03 12:54:55.543 INFO
  ******************** BATCH END ********************   ← 배치는 정상 종료처럼 보임

2026-07-03 12:54:57.681 ERROR
  org.springframework.orm.jpa.JpaSystemException:
    Transaction was marked for rollback only; cannot commit

삽질 — 코드 버그에 낚임

에러 메시지를 보고 "파라미터 13 바인딩이 안 됐다"는 것에 집중했다.

git 히스토리를 보니 실제로 중간 커밋에서 파라미터 13~16이 주석 블록 안에 들어간 버그가 있었다:

// 47c5a7d 커밋 상태 (12:52 커밋, 12:54 Jenkins 실행)
ps.setString(12, item.getUseYn());

/*
    ps.setTimestamp(13, toTimestamp(item.getCreatedAt()));  // ← 주석 안에 갇힘
    ps.setString(14, item.getCreatedBy());
    ps.setTimestamp(15, toTimestamp(item.getModifiedAt()));
    ps.setString(16, item.getModifiedBy());
*/

이 버그는 5분 뒤 ed61ba9 커밋에서 수정됐다. 그런데 수정된 코드로 재배포해도 여전히 같은 에러가 반복됐다.

실제 원인 — 트랜잭션 매니저 충돌

Step에 트랜잭션 매니저를 명시하지 않으면 어떻게 되나

StepBuilderFactory에 .transactionManager()를 지정하지 않으면, TaskletStep은 StepBuilderFactory에 주입된 트랜잭션 매니저를 그대로 쓴다.

이 프로젝트에서는 BatchConfigurer가 배치 인프라용으로 ResourcelessTransactionManager를 쓰도록 설정되어 있지만, StepBuilderFactory는 Spring Context의 @Primary 빈인 JpaTransactionManager를 주입받는다.

즉 Step의 기본 트랜잭션 매니저 = JpaTransactionManager.

문제 흐름

[Batch Step] JpaTransactionManager tx 시작
  └─ addrDailySync() — @Transactional 없음, try-catch 있음
       └─ processRoadAddr() @Transactional (REQUIRED)
            └─ 이미 JPA tx가 있으므로 기존 tx에 참여
            └─ batchUpsert() @Transactional (REQUIRED)
                 └─ 이미 JPA tx에 참여
                 └─ JdbcTemplate 실행 중 SQLException 발생
                    → Spring @Transactional AOP: tx를 rollback-only 마킹
                    → 예외 rethrow

       ← processRoadAddr() @Transactional AOP: RuntimeException
            → REQUIRED 참여자이므로 직접 rollback 불가
            → rollback-only 마킹 유지, 예외 rethrow

  ← addrDailySync() try-catch에서 예외를 잡아버림 (rethrow 안 함!)
       → systemLogService.errorWithNewTransaction() 호출 (REQUIRES_NEW로 별도 tx 커밋)
       → 정상 return

[Batch Step] TaskletStep이 JPA tx 커밋 시도
  → tx는 이미 rollback-only 상태
  → "Transaction was marked for rollback only; cannot commit" 💥

핵심: addrDailySync()가 예외를 잡고 rethrow하지 않아서 Step은 "성공한 것처럼" 흘러갔고, 마지막에 Step의 JPA 트랜잭션이 커밋을 시도하다 터졌다.

cmm_road_cd_d는 왜 됐나

// processRoadCd — @Transactional 없음
public List<CmmRoadCdDDTO> processRoadCd(String toDate) throws Exception {
    // ...
    for (List<CmmRoadCdD> chunk : Lists.partition(cmmRoadCdDList, BULK_CHUNK_SIZE)) {
        cmmRoadCdDBulkRepository.batchUpsert(chunk);  // 청크별 독립 tx
    }
}

processRoadCd()에는 @Transactional이 없다. cmmRoadCdDBulkRepository.batchUpsert()의 @Transactional(REQUIRED)은 진행 중인 JPA tx가 없으므로 자기 자신이 tx를 열고 닫는다. 청크별로 독립적인 트랜잭션이 생성·완료되기 때문에 문제가 없었다.

반면 processRoadAddr()에는 @Transactional이 붙어 있어서, 내부의 batchUpsert()가 외부 Step tx에 참여하는 구조가 됐고 충돌이 발생했다.

해결 — Step에 트랜잭션 매니저 명시

// CrocusBatchConfig.java

@Autowired
private PlatformTransactionManager transactionManager; // JPA용 @Primary

// Before — 트랜잭션 매니저 미지정 (StepBuilderFactory 기본값 사용)
@Bean
public Step zipcdSyncTaskletStep() {
    return stepBuilderFactory.get("zipcdSyncTaskletStep")
            .tasklet(zipcdSyncTasklet)
            .build();
}

// After — JPA 트랜잭션 매니저 명시
@Bean
public Step zipcdSyncTaskletStep(
        @Qualifier("transactionManager") PlatformTransactionManager txManager) {
    return stepBuilderFactory.get("zipcdSyncTaskletStep")
            .transactionManager(txManager)   // ← 명시
            .tasklet(zipcdSyncTasklet)
            .build();
}

@Bean
public Job zipcdSyncTaskletJob() {
    return jobBuilderFactory.get("zipcdSyncTaskletJob")
            .start(zipcdSyncTaskletStep(transactionManager))
            .build();
}

.transactionManager(txManager)를 명시하면 Step이 어떤 트랜잭션 매니저를 쓰는지 명확해지고, 예외 발생 시 Step 레벨에서 롤백 처리가 의도대로 동작한다.

트랜잭션 매니저 설정 방법 정리

Spring Batch에서 트랜잭션 매니저를 제어하는 방법은 세 가지다.

1. Step 빌드 시 직접 지정 (권장)

@Bean
public Step myStep(PlatformTransactionManager txManager) {
    return stepBuilderFactory.get("myStep")
            .transactionManager(txManager)   // ← 명시적 지정
            .tasklet(myTasklet)
            .build();
}

Step마다 어떤 트랜잭션 매니저를 쓸지 명확하게 제어할 수 있다.

2. BatchConfigurer 커스터마이징

@Bean
public BatchConfigurer batchConfigurer(PlatformTransactionManager txManager) {
    return new DefaultBatchConfigurer(dataSource) {
        @Override
        public PlatformTransactionManager getTransactionManager() {
            return txManager;   // ← 모든 Step의 기본값이 됨
        }
    };
}

모든 Step에 동일한 트랜잭션 매니저를 적용하고 싶을 때 쓴다.

3. @EnableBatchProcessing 기본 동작 의존 (비권장)

아무것도 안 하면 @Primary PlatformTransactionManager 빈이 주입된다. 어떤 매니저가 쓰이는지 명시적이지 않아서 이번처럼 의도치 않은 충돌이 발생할 수 있다.

교훈

• Spring Batch Tasklet Step을 만들 때는 .transactionManager()를 항상 명시하자.
• addrDailySync()가 try-catch로 예외를 삼키는 구조가 문제를 더 복잡하게 만들었다. 예외를 삼킬 때는 트랜잭션 상태가 어떻게 되는지 반드시 고려해야 한다.
• 에러 로그에 명백한 코드 버그(파라미터 바인딩)가 보이면 거기에만 집중하게 된다. 트랜잭션 에러가 함께 찍히면 두 에러의 인과관계를 먼저 파악하는 게 중요하다.
• 마이그레이션 때도 같은 이슈로 고생했는데 또 당했다. 이번엔 기록으로 남긴다.

관련 구성 요약

LoL 트롤 신고 커뮤니티 + 전적 통계 서비스를 직접 만들어보는 과정을 기록합니다.

프로젝트 소개

whofeeding.gg는 League of Legends 전적 통계와 트롤 신고 커뮤니티를 결합한 웹 서비스입니다.

서비스 이름은 LoL 게임 중 채팅에서 자주 사용되는 문구나 단어를 사용하고 싶었는데 클로드가 알려줘서 북미 서버 기준일지 모르겠지만 알려주어 "who feeding?"(누가 킬을 내주고 있냐?)에서 착안했습니다.

op.gg와 같은 전적 조회 서비스는 다양하게 존재하지만, 트롤 유저를 커뮤니티 기반으로 신고하고 기록할 수 있는 서비스는 찾기 어려웠습니다. 이 간극을 직접 채워보고자 프로젝트를 시작하게 되었습니다.

프로젝트 목표

• Riot Games API 연동, Redis 캐싱, JPA 기반 통계 처리 등 백엔드 핵심 기술을 실제 서비스 수준으로 구현
• 기획부터 배포까지 전 과정을 직접 경험하며 풀스택 개발 역량 확보
• op.gg에 없는 커뮤니티 기반 트롤 신고 시스템으로 서비스 차별화

기술 스택

추후 추가 예정: Redis (캐싱), Docker, AWS EC2, GitHub Actions CI/CD

레퍼런스 분석 — op.gg

whofeeding.gg의 전적 기능은 op.gg를 레퍼런스로 삼아 설계했습니다.

op.gg가 제공하는 핵심 기능은 크게 네 가지입니다.

• 소환사 검색 — Riot ID(닉네임 + 태그)로 검색
• 전적 조회 — 최근 매치 목록, KDA, CS, 딜량 등 상세 스탯
• 챔피언 분석 — 티어 목록, 승률/픽률/밴률, 추천 빌드 및 룬
• 랭킹 — 서버 전체 LP 순위, 챔피언 장인 랭킹

이를 기반으로 whofeeding.gg만의 기능을 추가했습니다.

4대 핵심 기능

① 소환사 검색 & 전적

• Riot ID(닉네임 + 태그) 기반 소환사 검색
• 프로필 요약 (레벨, 아이콘, 마지막 업데이트 시각)
• 큐 타입별 랭크 정보 (솔로랭크 / 자유랭크 / 아레나 등 — 티어, LP, 승/패, 승률)
• 최근 매치 목록 (챔피언, KDA, CS/분, 딜량, 게임 시간, 승패)
• 매치 상세 페이지 (팀원 전체 스탯, 아이템 빌드 순서, 룬)
• 챔피언별 플레이 통계 (플레이 횟수, 승률, KDA)
• 선호 포지션 비율
• 자주 함께 플레이한 소환사

② 챔피언 분석

• 챔피언 티어 목록 (포지션별 필터)
• 챔피언별 승률 / 픽률 / 밴률
• 추천 빌드 (아이템 순서)
• 추천 룬 세트
• 카운터 챔피언 정보

③ 랭킹

• 서버 전체 랭킹 (LP 기준)
• 챔피언 장인 랭킹 (숙련도 기준)

④ 트롤 신고 커뮤니티 (차별점)

op.gg에 없는 whofeeding.gg만의 핵심 기능입니다.

• 소환사 신고 게시글 작성 (증거 스크린샷 첨부 가능)
• 신고 목록 및 상세 페이지
• 공감 / 비공감
• 댓글
• 신고 누적 기반 자체 제재 시스템
  • 신고 10회 이상 → 요주의 소환사 배지
  • 신고 30회 이상 → 트롤 인증 배지
  • 커뮤니티 투표 기반 명예의 전당

Riot Games API는 계정 정지 이력을 외부에 제공하지 않습니다. whofeeding.gg는 커뮤니티가 직접 트롤 이력을 기록하고 공유하는 방식으로 이 공백을 채웁니다.

패키지 구조

도메인 중심으로 패키지를 구성했습니다.

com.whofeeding
├── domain
│   ├── summoner      # 소환사
│   ├── match         # 매치 / 전적
│   ├── champion      # 챔피언 통계
│   └── report        # 트롤 신고
├── api               # Controller, DTO
├── client            # Riot API 연동
└── global            # 공통 예외처리, 설정

개발 로드맵

마치며

다음 편에서는 ERD 설계를 다룹니다. 소환사, 매치, 챔피언, 신고 도메인의 테이블을 어떻게 설계했는지, 그 과정에서 어떤 고민을 했는지 정리할 예정입니다.

2편 — ERD 설계로 이어집니다.

배경

우리 시스템의 주문분배(Order Distribution) 는 주문이 들어왔을 때 어느 물류센터에서 출고할지를 결정하는 핵심 배치다.

분배 로직의 핵심은 간단하다.

센터별 실제 가용재고 = 외부 시스템 재고 − 이미 분배된 주문 수량

여기서 "이미 분배된 주문 수량"을 계산하는 getAvailableQuantity 메서드에 N+1 문제가 숨어 있었고, 주석으로도 명시되어 있었다.

//TODO 대량으로 내릴때 성능 개선이 꼭 필요하다.
private Long getAvailableQuantity(Long attrPrdCd, DistributionStockVO skuStockDTO, ...) {
    ...
    ditributedQty = gsOrderItemRepository.getDistributedAndUndistributedSkuQuantity(
        skuId, CenterCodeEnum.valueOf(skuStockDTO.getCenterCode())
    );
    ...
}

문제 상황

호출 흐름

getAvailableCenterInventory(attrPrdCd, skuIds, ...)
  └─ getSkuStockBySkuIdSet(skuIds)          // 재고 조회: 1번 (OK)
  └─ for each DistributionStockVO {          // SKU 수만큼 반복
       getAvailableQuantity(...)             // ← 여기서 DB 쿼리 1번씩
         └─ getDistributedAndUndistributedSkuQuantity(skuId, centerCode) // N번!
     }

SKU가 10개면 DB 쿼리가 10번, 100개면 100번 날아간다.

문제 쿼리

// 기존: skuId 하나씩 개별 조회
public Long getDistributedAndUndistributedSkuQuantity(Long skuId, CenterCodeEnum centerCode) {
    sb.append("SELECT SUM(goics.quantity * sam.quantity) ");
    sb.append("  FROM GsOrderItem goi, GsOrderItemCenterSku goics, SkuAttrMap sam ");
    sb.append(" WHERE sam.skuId = :skuId ");      // ← 단건 조회
    sb.append("   AND goics.centerCode IN ('DCXX', :centerCode) ");
    // ...
}

이 쿼리가 루프마다 실행되므로, SKU N개 → DB 쿼리 N번이 보장된다.

해결

핵심 아이디어

루프 안에 있는 DB 조회를 루프 밖으로 꺼내고, IN 절로 한 번에 처리한다.

1) 배치 조회 메서드 추가

기존 메서드는 그대로 두고, Set<Long> 을 받아 Map<skuId, qty> 를 반환하는 배치 버전을 추가했다.

// 인터페이스
Map<Long, Long> getDistributedSkuQuantityBatch(Set<Long> skuIds, CenterCodeEnum centerCode);
Map<Long, Long> getDistributedAndUndistributedSkuQuantityBatch(Set<Long> skuIds, CenterCodeEnum centerCode);

// 구현 — GROUP BY로 skuId별 합계를 한 방에
public Map<Long, Long> getDistributedAndUndistributedSkuQuantityBatch(Set<Long> skuIds, CenterCodeEnum centerCode) {
    sb.append("SELECT sam.skuId, SUM(goics.quantity * sam.quantity) ");
    sb.append("  FROM GsOrderItem goi, GsOrderItemCenterSku goics, SkuAttrMap sam ");
    sb.append(" WHERE sam.skuId IN :skuIds ");    // ← IN절로 전체 조회
    sb.append("   AND goics.centerCode IN ('DCXX', :centerCode) ");
    sb.append(" GROUP BY sam.skuId ");
    // ...

    Map<Long, Long> result = new HashMap<>();
    for (Object[] row : (List<Object[]>) query.getResultList()) {
        if (row[1] != null) {
            result.put(Long.parseLong(row[0].toString()), Long.parseLong(row[1].toString()));
        }
    }
    return result;
}

2) 서비스 리팩터링

getAvailableCenterInventory에서 루프 전에 배치 조회를 한 번 실행하고, 루프 안에서는 Map 룩업만 한다.

// 기존 구조
for (DistributionStockVO skuStockDTO : skuStockBySkuIdSet) {
    // 루프마다 DB 쿼리 1번
    getAvailableQuantity(attrPrdCd, skuStockDTO, distributionTypeEnum);
}

// 개선 구조
// 1. 루프 전: 전체 skuId를 한 번에 배치 조회
Map<String, Map<Long, Long>> distributedQtyByCenterAndSku =
    batchFetchDistributedQuantities(attrPrdCd, skuStockBySkuIdSet, distributionTypeEnum);

// 2. 루프 안: Map 룩업만 (DB 호출 없음)
for (DistributionStockVO skuStockDTO : skuStockBySkuIdSet) {
    getAvailableQuantity(attrPrdCd, skuStockDTO, distributedQtyByCenterAndSku);
}

batchFetchDistributedQuantities는 센터 코드별로 skuId를 그룹핑해 배치 쿼리를 날린다. 분배 타입이 REDISTRIBUTION이냐 아니냐에 따라 다른 배치 메서드를 호출한다.

private Map<String, Map<Long, Long>> batchFetchDistributedQuantities(
        Long attrPrdCd, List<DistributionStockVO> skuStockList,
        DistributionTargetItem.DistributionTypeEnum distributionTypeEnum) {

    // 센터 코드별로 skuId 수집
    Map<String, Set<Long>> skuIdsByCenterCode = new HashMap<>();
    for (DistributionStockVO stock : skuStockList) {
        if (stock.getCenterCode().equals(GUNPO_CENTER_CODE)
                || stock.getCenterCode().equals(ICHEON_CENTER_CODE)) {
            skuIdsByCenterCode
                    .computeIfAbsent(stock.getCenterCode(), k -> new HashSet<>())
                    .add(stock.getSkuId());
        }
    }

    // 센터 코드별로 배치 쿼리 1번씩
    Map<String, Map<Long, Long>> result = new HashMap<>();
    for (Map.Entry<String, Set<Long>> entry : skuIdsByCenterCode.entrySet()) {
        String centerCode = entry.getKey();
        CenterCodeEnum centerCodeEnum = CenterCodeEnum.valueOf(centerCode);
        Map<Long, Long> qtyMap;

        if (distributionTypeEnum == REDISTRIBUTION) {
            if (attrPrdCd.equals(96528474001L)) {  // 기존 긴급 로직 유지
                qtyMap = Collections.emptyMap();
            } else {
                qtyMap = gsOrderItemRepository.getDistributedSkuQuantityBatch(
                    entry.getValue(), centerCodeEnum);
            }
        } else {
            qtyMap = gsOrderItemRepository.getDistributedAndUndistributedSkuQuantityBatch(
                entry.getValue(), centerCodeEnum);
        }
        result.put(centerCode, qtyMap);
    }
    return result;
}

getAvailableQuantity는 DB 쿼리를 제거하고 Map 룩업으로 바뀐다.

// 변경 후 — DB 호출 없음
private Long getAvailableQuantity(Long attrPrdCd, DistributionStockVO skuStockDTO,
        Map<String, Map<Long, Long>> distributedQtyByCenterAndSku) {
    Long result = skuStockDTO.getAvailqty();
    Long skuId = skuStockDTO.getSkuId();
    String centerCode = skuStockDTO.getCenterCode();

    if (centerCode.equals(GUNPO_CENTER_CODE) || centerCode.equals(ICHEON_CENTER_CODE)) {
        Long distributedQty = distributedQtyByCenterAndSku
                .getOrDefault(centerCode, Collections.emptyMap())
                .get(skuId);   // ← Map 룩업 (O(1))

        if (distributedQty != null) {
            result -= distributedQty;
        }
    }
    if (centerCode.equals(ICHEON_CENTER_CODE)) {
        result -= getDC01DesignatedSkuQuantity(skuId);
    }
    return result;
}

변경 전후 비교

현재는 군포 센터만 필터링해 사용하므로 N번 → 1번으로 줄어든다.

기존 특수 케이스 처리

개선 전 코드에는 특정 상품(attrPrdCd = 96528474001L)에 대해 REDISTRIBUTION 시 분배 수량을 0으로 처리하는 긴급 로직이 있었다.

if (attrPrdCd.equals(96528474001L)) {
    ditributedQty = 0L;  // 긴급 로직
}

배치화 후에도 이 케이스는 유지된다. 해당 상품이면 배치 쿼리 자체를 건너뛰고 빈 맵을 넣어두면, map.get(skuId) 가 null을 반환하고 차감 없이 그대로 통과한다.

정리

반복문 안에서 I/O가 일어나고 있다면 항상 의심해야 한다.

1. 루프 안 DB 조회 → 루프 밖으로 꺼내 IN 쿼리 + Map 전처리
2. 리턴 타입을 Long → Map<Long, Long> 으로 바꾸면 호출부 시그니처도 자연스럽게 정리된다
3. 기존 특수 케이스(긴급 로직, null 처리)는 루프 밖에서도 동일하게 적용할 수 있다

N+1은 작은 데이터일 땐 눈에 안 띄지만, 주문이 몰리는 시간대에 분배 배치가 느려지는 원인이 된다.

대규모 물류센터의 출고확정 플로우를 처음부터 설계하고, 성능 병목을 찾아 개선하고, 재고 오판단 버그를 잡기까지의 기록입니다.

배경

GS리테일 슈퍼마켓 물류센터에는 TC(Transfer Center, 크로스도킹 센터) 라는 운영 방식이 있습니다. DC(Distribution Center)와 달리 TC는 상품이 입고되자마자 출고 준비를 하는 구조인데, 재고가 시스템상으로 존재하는 시간이 극히 짧고 입고와 출고가 거의 동시에 일어납니다.

이 TC 환경에서 출고확정(Dispatch Confirm) 이란 — "오늘 입고된 물량을 점포별로 배분해서 실제로 출고했다" 는 사실을 시스템에 확정짓는 작업입니다. 이 한 번의 확정 작업 안에 재고 차감, ERP 인터페이스 송신, 출고결과 반영, RSHP 재고 이동, 미출 결재 생성까지 모두 일어납니다.

이 출고확정 시스템을 신규 개발하고, 이후 발생한 성능 문제와 재고 버그를 개선했습니다.

1. 출고확정 플로우 설계

전체 흐름

출고확정 API 하나를 호출하면 내부에서 아래 단계가 순서대로 실행됩니다.

① 사전 검증 (9단계 Error/Warning)
② 미출 결재 문서 자동 생성
③ ShipmentItem 상태 → COMPLETED
④ TC 재고 → 출고 스테이지 Outbound (LPN 기반 FIFO 배분)
⑤ 출고결과 반영 + 출고마감 (병렬)
⑥ TC 잔여재고 → RSHP 로케이션 이동

단계별로 실패하면 이전 단계를 보상(Compensate)하는 구조로 설계했습니다.

사전 검증 — Error vs Warning 분리

확정 버튼을 누르기 전에 사용자에게 미리 알려주는 검증 단계가 있습니다. 여기서 중요한 설계 결정 하나는 Error와 Warning을 분리한 것입니다.

Error는 절대적인 차단 조건이고, Warning은 사용자가 인지하고 진행할 수 있는 조건입니다. 처음에는 전부 Error로 만들었다가, 현장 운영 피드백을 받고 이 구조로 개편했습니다.

이 검증 단계에서 조회해야 하는 데이터가 많기 때문에 CompletableFuture로 병렬 조회를 적용했습니다.

// 7개 조회를 동시에 실행
CompletableFuture<Map<InventoryCompareKey, Long>> tcInventoryFuture =
    CompletableFuture.supplyAsync(() ->
        toInventoryMap(inventoryFacade.findInventoryGroupByLpnId(centerCode, TC_STAGE)), executor);

CompletableFuture<Map<InventoryCompareKey, Long>> rshpInventoryFuture =
    CompletableFuture.supplyAsync(() ->
        toInventoryMap(inventoryFacade.findInventoryGroupByLpnId(centerCode, RSHP_STAGE)), executor);

CompletableFuture<Map<String, SkuCenterVO>> skuCenterFuture = ...;
CompletableFuture<Map<String, VendorSupplierVO>> vendorSupplierFuture = ...;
// ... 3개 더

CompletableFuture.allOf(tcInventoryFuture, rshpInventoryFuture, ...).join();

LPN 기반 FIFO 재고 배분

TC 재고는 LPN(License Plate Number) 단위로 관리됩니다. 출고 수량을 LPN에 배분할 때 선입선출 원칙을 지켜야 하는데, 이를 위해 아래 우선순위로 정렬했습니다.

// 유통기한 빠른 것 → 입고일 빠른 것 → 수량 배분
Comparator<InventoryGroupByLpnIdVO> inventoryPriority = Comparator
    .comparing(v -> v.getExpiredDate() == null ? 1 : 0)
    .thenComparing(v -> v.getExpiredDate() != null ? v.getExpiredDate() : LocalDate.MAX)
    .thenComparing(v -> v.getReceivedDate() != null ? v.getReceivedDate() : LocalDate.MAX);

배분은 LPN별 잔여수량 Map을 유지하면서 요청 수량이 소진될 때까지 순차 차감하는 방식입니다. 복수의 LPN에 걸쳐 한 품목이 나뉘어 있는 경우도 자연스럽게 처리됩니다.

부분 실패 보상 트랜잭션

재고 outbound는 SKU 단위로 병렬로 처리되는데, 일부 SKU가 실패해도 나머지 성공한 SKU는 정상 처리되어야 합니다. 이를 위해 실패한 SKU에 한해서만 ShipmentItem 상태를 이전으로 되돌리는 보상 로직을 구현했습니다.

// 실패한 SKU 목록
Set<String> failedSkuCodes = failures.stream()
    .map(x -> x.groupKey().skuCode())
    .collect(Collectors.toSet());

// 실패 SKU의 ShipmentItem만 롤백
List<SmRoomTcDispatchCompleteItemQRO> failedSkuItems = confirmableItems.stream()
    .filter(x -> failedSkuCodes.contains(x.getSkuCode()))
    .toList();
compensateShipmentItems(failedSkuItems);

// 성공 SKU는 계속 진행
List<SmRoomTcDispatchCompleteItemQRO> successItems = confirmableItems.stream()
    .filter(x -> !failedSkuCodes.contains(x.getSkuCode()))
    .toList();

미출 결재 자동 생성

출고수량 < 원주문수량인 경우(미출), 사유 코드와 함께 Approval 시스템에 결재 문서를 자동 생성합니다. 운영자가 별도로 결재 요청을 올리지 않아도 출고확정 시점에 자동으로 연동됩니다.

TC 잔여재고 → RSHP 자동 이동

TC 출고확정 후에는 "입고수량 - 출고수량" 에 해당하는 물량이 TC 로케이션에 남습니다. 이 잔여분은 RSHP(Receiving Shipment Hold Point) 로케이션으로 옮겨야 다음 날 작업에 영향을 주지 않습니다.

입고수량(100) - 출고수량(80) = 20 → TC → RSHP 자동 이동

이 계산과 이동도 출고확정 흐름의 마지막 단계로 자동 처리됩니다.

2. 인터페이스 송신 병목 개선 — 80% 처리시간 단축

문제 발견

출고확정이 완료된 이후 ERP(Oracle 레거시 시스템)로 출고 데이터를 인터페이스 송신하는 부분이 있습니다. 초기 구현은 아래와 같이 단순한 반복문이었습니다.

// AS-IS: N건 순차 처리
order = orderRepository.save(order);  // JPA dirty checking → N번 UPDATE

for (TeSmTcshpSndCO co : teSmTcshpSndCOS) {
    interfaceSendManager.sendAfterValid(targetTable, co, userCode);  // 1건씩 INSERT
}

Wave 1회에 처리하는 주문아이템이 수백 건 규모이다 보니, 건수가 늘어날수록 처리시간이 선형으로 증가했습니다.

개선 1 — Bulk UPDATE 전환

JPA dirty checking으로 개별 UPDATE하던 방식을 PostgreSQL의 UPDATE ... FROM (VALUES ...) 구문으로 변경했습니다.

-- 수백 건을 단 1번의 SQL로
UPDATE goods_dispatch_retailer_order_item
SET shipped_quantity = dt.shipped_quantity,
    insufficient_type = dt.insufficient_type,
    modified_at = dt.modified_at
FROM (
  VALUES
    (101, 80, NULL, '2025-06-05 09:00:00'::TIMESTAMP),
    (102, 50, 'STOCK_SHORTAGE', '2025-06-05 09:00:00'::TIMESTAMP),
    (103, 30, NULL, '2025-06-05 09:00:00'::TIMESTAMP)
    -- ... N건
) AS dt(id, shipped_quantity, insufficient_type, modified_at)
WHERE goods_dispatch_retailer_order_item.id = dt.id

BulkUpdateManager는 엔티티 클래스의 @Table, @Column 어노테이션을 리플렉션으로 읽어 SQL을 동적으로 생성합니다. 테이블명/컬럼명을 하드코딩하지 않아도 됩니다.

// 사용 방법
bulkUpdateManager.bulkUpdate(
    GoodsDispatchRetailerOrderItem.class,  // 엔티티 클래스 → 테이블명 자동 추론
    List.of("id"),                          // WHERE 조건 필드
    updateRows                              // 변경할 값들
);

개선 2 — 인터페이스 송신 병렬화

인터페이스 INSERT도 4개 스레드로 병렬 처리하도록 변경했습니다.

// TO-BE: 4 thread 병렬 전송
final ExecutorService executor = Executors.newFixedThreadPool(4);

List<CompletableFuture<Void>> futures = teSmTcshpSndCOS.stream()
    .map(co -> CompletableFuture.runAsync(
        () -> interfaceSendManager.sendAfterValid(targetTable, co, userCode),
        executor
    ))
    .toList();

CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
    .get(300, TimeUnit.SECONDS);

처리시간 개선 추정

Aurora PostgreSQL 환경 기준, DB INSERT/UPDATE RTT를 510ms로 가정했을 때:

건수가 많아질수록 효과는 더 커집니다. Wave 규모가 500건이면 약 6배 단축입니다.

3. 협력사 기준 누락으로 인한 재고 오판단 버그

이 버그를 찾기까지 꽤 시간이 걸렸습니다. 현상은 분명한데 원인을 특정하기 어려운 케이스였습니다.

증상

TC 출고확정 후 가끔 아래 현상이 발생했습니다.

• TC 로케이션에 남아 있어야 할 재고가 없어짐
• RSHP로 이동되어야 할 물량이 처리되지 않음
• 동일 상품인데 협력사가 다른 경우에 집중적으로 발생

원인 분석

재고를 집계할 때 key를 skuCode만으로 사용하고 있었습니다.

// AS-IS (버그): 상품코드만으로 재고 매핑
Map<String, Long> inventoryBySkuCode = tcInventoryList.stream()
    .collect(Collectors.groupingBy(
        InventoryGroupByLpnIdVO::getSkuCode,
        Collectors.summingLong(InventoryGroupByLpnIdVO::getTouchableQuantity)
    ));

TC에는 동일한 상품이 다른 협력사로 입고될 수 있습니다. 예를 들어 SKU001이 A협력사와 B협력사에서 각각 입고되는 경우, 두 재고는 완전히 다른 것으로 취급해야 합니다. 그런데 상품코드만으로 집계하면 두 재고가 합쳐지면서 배분 로직이 엉키게 됩니다.

상황:
  TC 재고 A협력사/SKU001 = 100개
  TC 재고 B협력사/SKU001 = 50개

출고 요청:
  B협력사/SKU001 = 60개

AS-IS 동작:
  SKU001 총재고 = 150개 → 출고 가능 판정 ✓
  BUT 배분 시 B협력사 재고 50개 소진 후 A협력사 재고 10개 추가 차감 ← 문제!
  → A협력사 재고 10개 영문도 모르게 소멸
  → B협력사 RSHP 이동 계산도 틀어짐

수정

재고 비교 단위에 협력사 코드를 포함하는 복합키를 도입했습니다.

// TO-BE: (센터, 협력사, 상품) 복합키
private record InventoryCompareKey(
    String centerCode,
    String vendorSupplierCode,  // ← 핵심 추가
    String skuCode
) {}

// 재고 집계 시 협력사 기준 엄격 적용
Map<InventoryCompareKey, List<InventoryGroupByLpnIdVO>> inventoryByKey =
    tcInventoryList.stream()
        .sorted(inventoryPriority)  // FIFO 정렬
        .collect(Collectors.groupingBy(x ->
            new InventoryCompareKey(
                x.getCenterCode(),
                x.getVendorSupplierCode(),  // 협력사 분리
                x.getSkuCode()
            )
        ));

출고 배분, TC→RSHP 이동 계산, 재고 부족 validation까지 모두 이 복합키 기준으로 동작하도록 일관되게 변경했습니다.

수정 후 동작:
  A협력사/SKU001 재고 = 100개 (별도 관리)
  B협력사/SKU001 재고 = 50개 (별도 관리)

출고 요청 B협력사/SKU001 = 60개:
  → B협력사 재고 50개로 부족 판정 → 명확한 오류 메시지 출력
  → A협력사 재고는 영향 없음 ✓

교훈

재고 시스템에서 "같은 상품"이라는 개념은 생각보다 훨씬 좁습니다. 물류 도메인에서는 동일 SKU라도 협력사, 입고일, 유통기한에 따라 완전히 다른 재고로 취급해야 하는 경우가 많습니다. 집계 단위를 설정할 때 도메인 전문가와 함께 "무엇이 같고 무엇이 다른가"를 명확히 정의하는 게 중요하다는 걸 이 버그를 통해 배웠습니다.

마무리

실제 물류 현장에서 수십만 건의 상품이 오가는 시스템을 처음부터 설계하고 운영하면서, 성능 숫자 뒤에 있는 도메인 이해가 얼마나 중요한지 크게 느낀 프로젝트였습니다.

개요

회사에서 나는 매일 재고 입출고 및 기타상황에 따라 발생되는 입출고 데이터와 정산데이터를 통해 생성 비교되는 배치인 일수불데이터 배치와 매달 첫 영업일 마감작업을 위한 정합성 배치를 사용하며 운영업무를 진행해왔다. 마감작업은 매달 첫 영업일 오후 특정시간대까지 마감데이터를 생성하여 타부서에 넘기고 그걸 토대로 협력사에게 대금이 지급되는 예민한 업무인데 마감데이터를 검증하기위한 검증 배치가 너무 오래걸리고 가끔은 일수불들을 다시 생성해야하는 최악의 경우도 발생되어 곤욕을 치루기도 했다.. 그래서 적어도 당일에 배치를 통한 시간 병목은 없애자라는 생각으로 우선 배치를 개선해보기로했고 아래 두 배치를

일수불(일별 수입불출) 집계 배치와 정합성 검증 배치에서 두 가지 성능 문제를 발견하고 개선했다.

개요

회사에서 나는 매일 재고 입출고 및 기타 상황에 따라 발생되는 입출고 데이터와 정산 데이터를 통해 생성·비교되는 배치인 일수불(일별 수입불출) 데이터 배치와, 매달 첫 영업일 마감 작업을 위한 정합성 검증 배치를 운영해왔다.

마감 작업은 매달 첫 영업일 오후 특정 시간대까지 마감 데이터를 생성해 타부서에 넘기고, 그걸 토대로 협력사에 대금이 지급되는 예민한 업무다. 그런데 마감 데이터를 검증하기 위한 검증 배치가 너무 오래 걸리고, 가끔은 일수불을 다시 생성해야 하는 최악의 상황도 발생해 곤욕을 치르기도 했다.

적어도 배치 자체로 인한 시간 병목은 없애자는 생각으로 두 배치를 개선해보기로 했다.

• 처리 대상: 약 20만 3천 건
• 기존 소요 시간: 47분
• 개선 후 소요 시간: 17분 (64% 단축)

문제 1. 일수불 생성 — N+1 쿼리

문제 상황

집계된 VO N건을 저장할 때, 건마다 SKU 정보를 개별로 DB 조회하고 있었다.

// insert() 내부 — VO 1건 처리할 때마다 실행
Optional<Sku> skuOpt = skuMRepository.findById(statsDailyCollectPayVO.getAttrPrdCd());

루프에서 스레드풀(4개)에 태스크를 제출하는 구조였기 때문에, 결과적으로 SELECT * FROM sku WHERE id = ? 쿼리가 N번 날아갔다.

for (StatsDailyCollectPayVO vo : resultList) {
    executor.submit(new StatsDailyCollectPayRunnable(service, vo));
    // ↑ 각 태스크 내부에서 DB 조회 1번씩
}

여기서 놓치기 쉬운 함정이 있다.
스레드를 4개로 병렬 처리해도 총 쿼리 수는 줄어들지 않는다.
스레드는 실행을 병렬화할 뿐, 쿼리 횟수 자체를 줄이지 않기 때문이다.

데이터가 늘수록 배치 시간이 선형으로 증가하는 구조였다.

두 번째 문제도 숨어 있었다.
MD 영업그룹 코드를 캐싱하는 mdSaleGrpMap이 각 Runnable마다 새 Map으로 초기화되고 있었다.

// StatsDailyCollectPayRunnable 생성자
public StatsDailyCollectPayRunnable(StatsDailyCollectPayService service, StatsDailyCollectPayVO target) {
    this.service = service;
    this.target = target;
    this.mdSaleGrpMap = new ConcurrentHashMap<>(); // 스레드마다 빈 Map으로 시작
}

같은 MD ID라도 다른 스레드가 이미 조회했다는 걸 모르고 외부 API를 또 호출했다.
캐시가 스레드 간에 공유되지 않으니 사실상 캐시 효과가 없었던 것이다.

해결

1) SKU 조회 — 루프 전에 IN 쿼리로 한 번에 벌크 조회

// 루프 전: 전체 attrPrdCd를 Set으로 모은 뒤 IN 쿼리 1번
Set<Long> attrPrdCdSet = resultList.stream()
        .map(StatsDailyCollectPayVO::getAttrPrdCd)
        .filter(Objects::nonNull)
        .collect(Collectors.toSet());

Map<Long, Sku> skuMap = skuRepository.findByIdIn(attrPrdCdSet)
        .stream()
        .collect(Collectors.toMap(Sku::getId, s -> s));

// 루프: DB 조회 없이 Map.get()으로 즉시 반환
for (StatsDailyCollectPayVO vo : resultList) {
    executor.submit(new StatsDailyCollectPayOptimizedRunnable(service, vo, mdSaleGrpMap, skuMap));
}

// 변경 전
Optional<Sku> skuOpt = skuMRepository.findById(attrPrdCd); // DB 호출

// 변경 후
Sku sku = skuMap.get(attrPrdCd); // Map 조회 (DB 호출 없음)

쿼리 N번 → 1번으로 줄었고, 처리 시간이 데이터 증가에 관계없이 거의 일정해졌다.

2) mdSaleGrpMap — 스레드 간 공유 + computeIfAbsent로 최초 1회만 호출

// Processor에서 하나의 Map을 생성해 모든 Runnable에 전달
Map<String, String> mdSaleGrpMap = new ConcurrentHashMap<>();

for (StatsDailyCollectPayVO vo : resultList) {
    executor.submit(new StatsDailyCollectPayOptimizedRunnable(service, vo, mdSaleGrpMap, skuMap));
}

// 변경 후: 같은 key는 최초 1회만 외부 API 호출
String saleGrpCd = mdSaleGrpMap.computeIfAbsent(mdId, k -> {
    CmmMdidMDTO cmm = externalBegoniaCmmMdidMFacade.getByMdid(k);
    return (cmm != null) ? cmm.getSaleGrpCd() : null;
});

문제 2. 정합성 검증 — 순차 실행 & 개별 저장

문제 상황

정합성 검증은 외부 시스템(SMTC) 조회와 DB 조회를 순차 실행하고 있었다.

// 두 호출 사이에 의존성이 전혀 없는데 순서대로 실행
List<RcvpayCheckDTO> smtcList =
        externalBegoniaPrhFacade.getPrhDtRcvpayCheckList(targetDateStr); // 외부 API 호출
List<StatsDailyCollectPay> auroraList =
        statsDailyCollectPayRepository.findAllByPrdMoveDt(targetDate);   // DB 조회

두 호출의 결과가 서로에게 필요하지 않음에도 직렬로 실행되어 응답 시간이 단순 합산되었다.

또한 검증 결과 로그를 DB에 저장할 때 save()를 3번 개별 호출했다.

systemLogRepository.save(makeSystemLog("smtcOnly", ...));   // 트랜잭션 1번
systemLogRepository.save(makeSystemLog("auroraOnly", ...)); // 트랜잭션 2번
systemLogRepository.save(makeSystemLog("notEqual", ...));   // 트랜잭션 3번

해결

1) 두 조회를 CompletableFuture로 병렬 실행

CompletableFuture<List<RcvpayCheckDTO>> smtcFuture = CompletableFuture.supplyAsync(
        () -> externalBegoniaPrhFacade.getPrhDtRcvpayCheckList(targetDateStr));
CompletableFuture<List<StatsDailyCollectPay>> auroraFuture = CompletableFuture.supplyAsync(
        () -> statsDailyCollectPayRepository.findAllByPrdMoveDt(targetDate));

// 둘 다 완료될 때까지 대기
List<RcvpayCheckDTO> smtcList = smtcFuture.join();
List<StatsDailyCollectPay> auroraList = auroraFuture.join();

Before: 외부 API(500ms) → DB 조회(300ms) = 800ms
After:  외부 API(500ms) ┐ 동시 실행
        DB 조회(300ms)  ┘ = 500ms (더 느린 쪽이 기준)

2) 개별 save() → saveAll() 1번

systemLogRepository.saveAll(Arrays.asList(
        makeSystemLog("smtcOnlyCollectPayCheckService", smtcOnly.toString(), targetDateStr),
        makeSystemLog("auroraOnlyCollectPayCheckService", auroraOnly.toString(), targetDateStr),
        makeSystemLog("notEqualCollectPayCheckService", notEqual.toString(), targetDateStr)
));

트랜잭션 3번 → 1번, DB 왕복 3번 → 1번으로 줄었다.

결과

회고 — 이런 문제를 빠르게 발견하려면

이번 개선에서 얻은 핵심 패턴은 하나다.

반복문 안에서 I/O가 일어나고 있는가?

• 반복문 안 DB 조회 → N+1 의심, 루프 밖으로 꺼내서 벌크 처리
• 반복문 안 외부 API 호출 → 캐싱 또는 배치 처리 검토
• 멀티스레드인데 각 스레드가 독립적으로 같은 데이터를 조회 → 공유 캐시 도입

20만 건이면 루프 안의 1ms짜리 작업 하나가 200초(3분 20초)다.
findById() 하나가 아무리 빠르더라도 N번 불리면 누적된다.

반복문을 볼 때 "이 안에 있는 코드 중 루프 밖으로 꺼낼 수 있는 게 있나?" 를
먼저 확인하는 습관이 배치 성능 개선의 출발점이다.

정리

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

    }
}

스스로 피드백 해보기

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

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

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