동치미

2026.06 ~ 2026.07

동네 마트의 전단 상품을 온라인으로 확인하고, 사용자가 현재 위치를 기반으로 주변 마트의 할인 상품과 전단 정보를 쉽게 조회할 수 있도록 제공하는 서비스

Kotlin
Spring Boot
JPA
PosgreSQL
Redis
Kotlin Coroutines

Service ↗

프로젝트 소개

팀 구성: 기획 3명, 디자인 2명, FE 5명, BE 2명

[SOPT 38기 APPJAM 프로젝트]

동네 마트의 전단 상품을 온라인으로 확인하고, 사용자가 현재 위치를 기반으로 주변 마트의 할인 상품과 전단 정보를 쉽게 조회할 수 있도록 제공하는 서비스입니다.

프로젝트 내용

엑셀 상품 일괄 등록의 비동기·병렬 처리

해결 방법

이를 해결하기 위해 먼저 사용자 요청과 실제 AI 분석 작업의 실행 흐름을 분리했습니다. 엑셀 업로드 요청에서는 작업 정보만 생성하고 빠르게 응답한 뒤, 실제 상품 분석과 저장은 백그라운드 작업으로 처리하도록 변경했습니다.

AI 분석 내부에서도 상품 전체를 한 번에 무제한 병렬 처리하지 않았습니다. 전체 상품을 일정한 청크 단위로 나누고, 각 청크 내부의 상품 분석을 Kotlin Coroutine으로 병렬 실행했습니다. 이를 통해 외부 API 응답을 기다리는 I/O 대기 시간을 다른 상품의 분석으로 활용할 수 있도록 했습니다.

상품 하나를 처리할 때도 카테고리 분류와 이미지 매칭처럼 서로 결과에 의존하지 않는 작업은 async 기반으로 동시에 실행하고, 두 결과가 모두 필요한 시점에 await하도록 구성했습니다. 따라서 상품 간 병렬 처리와 상품 내부 AI 작업 병렬 처리를 함께 적용했습니다.

다만 외부 AI API에 동시에 너무 많은 요청을 보내면 429 Too Many Requests나 timeout이 발생할 수 있기 때문에, Semaphore를 이용해 동시에 실행할 수 있는 AI 요청 수에 상한을 두었습니다. 단순히 가능한 만큼 많은 Coroutine을 생성하는 것이 아니라, 애플리케이션이 감당할 수 있는 범위 안에서만 외부 호출이 실행되도록 제한했습니다.

즉 처리 구조를 다음과 같이 구성했습니다.

블루/그린 배포 중 작업 유실을 막는 DB 기반 분산 작업 큐 설계

해결 방법

이를 해결하기 위해 비동기 작업 자체를 애플리케이션 메모리가 아니라 DB에 영속화했습니다.

product_import_jobs 테이블에 작업 상태와 원본 엑셀 파일 정보, 재시도 횟수, 작업 소유자, lease 만료 시각 등을 저장하고, 각 인스턴스가 주기적으로 처리 가능한 작업을 polling하도록 구성했습니다.

여러 인스턴스가 동시에 같은 작업을 가져가는 것을 막기 위해 작업 선점 쿼리에 FOR UPDATE SKIP LOCKED를 적용했습니다. 한 Worker가 특정 작업을 선점하면 해당 row에 lock을 잡고, 다른 Worker는 기다리지 않고 다음 처리 가능한 작업을 가져가도록 했습니다.

작업 선점 시에는 locked_by, locked_until을 함께 갱신해 현재 어떤 Worker가 작업을 소유하고 있는지 관리했습니다. Worker가 정상적으로 작업을 완료하지 못하고 종료되더라도 lease가 만료되면 다른 Worker가 해당 작업을 다시 가져갈 수 있도록 했습니다.

처리 대상은 신규 PENDING 작업뿐 아니라 lease가 만료된 IN_PROGRESS 작업도 포함했고, attempt_count를 기준으로 최대 재시도 횟수를 넘은 작업은 다시 선점하지 않도록 구성했습니다.

즉 작업의 실행 권한을 프로세스 메모리가 아니라 DB의 상태와 lease를 기준으로 관리해, 배포나 인스턴스 장애 이후에도 다른 Worker가 미완료 작업을 이어받을 수 있도록 했습니다.

Kafka나 AWS SQS 같은 메시지 브로커도 검토했지만, 실제 작업량이 하루 수십 건 수준인 서비스에서 별도의 메시징 인프라를 추가하면 배포, 모니터링, 장애 대응 대상이 늘어난다고 판단했습니다. 현재 트래픽에서는 PostgreSQL polling만으로 충분한 처리량을 확보할 수 있어 기존 DB를 이용한 작업 큐를 선택했습니다.

파일 단위 재처리와 단일 트랜잭션 반영으로 재시도 안정성 확보

해결 방법

이를 피하기 위해 작업 단위를 개별 상품이 아니라 엑셀 파일 전체로 관리했습니다.

미완료 작업을 다시 선점하면 중간 지점부터 이어서 처리하지 않고 원본 엑셀 파일을 기준으로 전체 분석을 처음부터 다시 수행했습니다. 대신 분석 중에는 실제 상품 데이터를 DB에 부분적으로 저장하지 않고, 모든 상품의 AI 분석이 완료된 뒤 최종 결과를 한 번에 반영했습니다.

최종 저장 단계는 단일 트랜잭션으로 처리해 작업 도중 오류가 발생하면 전체 변경이 롤백되도록 했습니다. 이를 통해 재시도가 발생하더라도 이전 실행에서 일부 상품만 남아 중복 등록되는 상황을 방지했습니다.

즉 작업 실행 자체는 at-least-once로 다시 수행될 수 있지만, DB 반영은 하나의 트랜잭션으로 묶어 멱등하게 처리하도록 구성했습니다.

이 방식은 상품 하나마다 복잡한 checkpoint를 관리하는 것보다 구현이 단순하고, 한 번의 엑셀 업로드가 하나의 논리적 작업이라는 서비스 특성과도 맞았습니다.

동치미

프로젝트 소개

프로젝트 내용

엑셀 상품 일괄 등록의 비동기·병렬 처리

블루/그린 배포 중 작업 유실을 막는 DB 기반 분산 작업 큐 설계

파일 단위 재처리와 단일 트랜잭션 반영으로 재시도 안정성 확보

Redis Pub/Sub과 DB의 역할 분리

상품명 전처리를 통한 LLM 이미지 매칭 정확도 개선

외부 기술 구현 교체를 고려한 멀티모듈 구조 설계