MACTA

🔨 실시간 경매 플랫폼 MACTA

SK쉴더스 루키즈 지능형 애플리케이션 개발 5기 Mini Project 3 - 4조

배포 주소: https://macta.store

MACTA: 사용자가 상품을 등록하고 실시간 입찰에 참여할 수 있는 경매 플랫폼으로, 경매 마감 직전에 트래픽이 집중되는 상황과 다양한 보안 위협 환경에서도 안정적으로 동작하도록 설계된 서비스

낙관적 락 기반 동시성 제어를 통해 마감 직전 입찰 경쟁에서 발생할 수 있는 Race Condition, 중복 갱신, 데이터 무결성 문제를 방지
WAF를 ALB 앞단에 구성하여 매크로성 반복 요청, DDoS, SQL Injection, XSS, 패킷 위변조 등 비정상 트래픽을 사전에 차단하도록 구성
Kubernetes 기반 배포 환경을 구축하여 애플리케이션 컨테이너를 안정적으로 운영하고, 트래픽 증가 상황에서도 서비스 확장과 복구 가능
Rolling Update 전략을 적용하여 새로운 버전 배포 시에도 기존 Pod와 신규 Pod를 순차적으로 교체함으로써 서비스 중단을 최소화

📌 Application

경매 비즈니스 로직

사용자가 경매 상품에 입찰하면 서버에서 경매 진행 상태, 종료 시간, 현재 최고 입찰가를 먼저 확인한 뒤 입찰 가능 여부를 판단
입찰 금액은 현재 최고 입찰가보다 높은 경우에만 허용하여 낮은 금액 입찰이나 동일 금액 중복 입찰이 저장되지 않도록 검증
음수 금액, 0원 입찰, 필수 값 누락, 종료된 경매에 대한 입찰 요청 등 비정상 요청을 사전에 차단하도록 입력값 검증을 수행
유효한 입찰이 등록되면 경매의 현재 최고가와 최고 입찰자 정보를 함께 갱신하여 이후 사용자에게 최신 입찰 상태가 반영되도록 처리
경매 종료 시점에는 경매 상태를 CLOSED로 변경하고 마지막 최고 입찰자를 최종 낙찰자로 확정하여 거래 단계로 이어질 수 있도록 구성
댓글 및 답글 기능을 제공하여 상품 상세 페이지에서 구매 문의, 판매자 답변, 사용자 간 질의응답

경매 종료 스케줄링

백엔드 스케줄러가 일정 주기로 실행되며 진행 중인 경매 목록에서 종료 시간이 지난 경매를 조회
만료 대상 경매를 선별할 때 이미 종료 처리된 경매는 제외하여 중복 종료 처리와 불필요한 상태 변경이 발생하지 않도록 구현
종료 시간이 지난 경매는 추가 입찰을 받을 수 없도록 상태를 변경하고, 현재 최고 입찰 내역을 기준으로 낙찰자를 확정
입찰자가 존재하지 않는 경매는 낙찰자 없이 종료 상태로 처리하여 결제 및 배송 단계가 생성되지 않도록 분기
스케줄러 기반 자동 처리를 통해 관리자가 직접 경매를 마감하지 않아도 정해진 시간에 경매가 종료

결제 및 배송

낙찰자 결제

판매자 배송

경매가 종료되고 낙찰자가 확정되면 해당 낙찰자를 기준으로 거래 정보가 생성되며 결제 대기 상태로 전환
낙찰자는 마이페이지 또는 거래 화면에서 낙찰 상품과 최종 결제 금액을 확인한 뒤 결제 절차를 진행 가능
결제 완료 시 거래 상태를 결제 완료로 변경하고 판매자가 배송 정보를 입력하거나 배송을 시작할 수 있는 단계로 이어지도록 처리
판매자는 결제 완료된 거래를 기준으로 배송을 진행하며, 배송 상태 변경 내역이 구매자 화면에도 반영
거래 진행 단계에 따라 결제 대기, 결제 완료, 배송 진행, 거래 완료 등의 상태를 관리하여 사용자별로 필요한 액션만 노출
낙찰자와 판매자의 역할을 구분하여 결제는 낙찰자만, 배송 처리는 판매자만 수행할 수 있도록 권한 흐름을 분리

동시성 제어

@Entity
@Table(name = "auctions")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Builder
public class Auction {

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

    @Column(name = "current_price", nullable = false)
    private Long currentPrice;

    @Version
    @Column(nullable = false)
    private Long version;

    public void updateCurrentPrice(Long bidPrice) {
        this.currentPrice = bidPrice;
    }
}

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class BidService {

    private final AuctionRepository auctionRepository;

    @Transactional
    public void placeBid(Long auctionId, Long bidPrice) {

        Auction auction = auctionRepository.findById(auctionId)
                .orElseThrow();

        // 현재 최고가보다 높은 경우만 입찰 허용
        if (bidPrice <= auction.getCurrentPrice()) {
            throw new IllegalArgumentException("INVALID_BID_PRICE");
        }

        // Optimistic Lock 기반 최고가 갱신
        auction.updateCurrentPrice(bidPrice);
    }
}

경매 마감 직전에 여러 사용자의 입찰 요청이 동시에 들어오는 상황에서도 데이터 무결성을 보장하기 위해 **낙관적 락(Optimistic Lock)**을 적용
Auction 엔티티에 @Version 필드를 두어 같은 경매 데이터를 동시에 수정하려는 요청이 발생하면 버전 충돌을 감지
입찰 처리 시 현재 최고가 검증과 최고가 갱신을 하나의 트랜잭션 안에서 수행하여 검증 시점과 저장 시점의 데이터 불일치를 줄임
동시에 들어온 입찰 요청 중 먼저 커밋된 요청만 경매 정보를 갱신하고, 이후 충돌이 발생한 요청은 실패 처리되어 잘못된 최고가 덮어쓰기를 방지
동일 경매에 대한 중복 갱신과 Race Condition 문제를 방지하여 최종 입찰가와 낙찰자 정보가 일관되게 저장

실시간 알림

사용자가 참여한 경매에서 새로운 입찰, 경매 종료, 낙찰 결과와 같은 이벤트가 발생하면 알림 데이터가 생성
입찰자, 낙찰자, 판매자처럼 이벤트와 관련된 사용자에게 필요한 알림만 전달되도록 수신 대상을 구분
사용자가 서비스 이용 중 중요한 경매 상태 변화를 즉시 확인할 수 있도록 실시간 알림 형태로 이벤트를 전달
읽지 않은 알림 개수를 사용자별로 관리하여 마이페이지 또는 알림 영역에서 확인하지 않은 알림 수를 표시할 수 있도록 구성
사용자가 알림을 확인하면 읽음 상태로 변경하여 이미 확인한 알림과 새로 도착한 알림을 구분할 수 있도록 구현

인증 및 인가

JWT 기반 인증 방식을 적용하여 로그인 성공 시 발급된 토큰으로 사용자의 요청을 식별 가능
보호된 API 요청에서는 토큰의 유효성을 검증하고 인증된 사용자 정보가 필요한 비즈니스 로직에 전달되도록 구성
로그인한 사용자만 입찰 등록, 결제 진행, 마이페이지 조회, 관심 상품 관리와 같은 주요 기능을 사용할 수 있도록 제한
상품 수정 및 삭제 요청에서는 요청 사용자와 상품 등록자를 비교하여 판매자 본인만 상품 정보를 변경할 수 있도록 검증
거래 정보, 입찰 내역, 배송 처리 기능에서는 낙찰자와 판매자의 역할을 구분하여 타인의 거래 정보를 임의로 수정할 수 없도록 제어
인증되지 않은 요청이나 권한이 없는 요청은 비즈니스 로직 실행 전에 차단하여 사용자 데이터가 노출되거나 변경되지 않도록 처리

마이페이지

사용자가 등록한 경매 상품 목록을 제공하여 판매 중인 상품, 종료된 상품, 낙찰 여부를 한 화면에서 확인 가능
사용자가 참여한 입찰 내역을 제공하여 입찰한 상품, 입찰 금액, 경매 진행 상태, 낙찰 여부를 추적
낙찰된 거래와 판매 중인 거래의 진행 상태를 사용자 기준으로 분리하여 결제 필요 여부와 배송 처리 필요 여부를 확인할 수 있도록 구성

🚀 Infrastructure & Deployment

AWS 네트워크 분리

Public Subnet에는 외부 요청을 수신하는 **ALB(Application Load Balancer)**와 Private Subnet의 아웃바운드 통신을 위한 NAT Gateway를 배치
Private Subnet에는 실제 애플리케이션이 실행되는 EKS, 세션 및 실시간 처리에 활용되는 Redis, 영속 데이터를 저장하는 RDS MariaDB를 구성하여 내부망 기반으로 운영
외부 사용자는 ALB까지만 접근 가능하며, 애플리케이션 Pod와 데이터베이스는 Private 네트워크 내부에서만 통신하도록 분리
데이터베이스와 캐시 계층을 외부에 직접 노출하지 않아 공격 표면을 최소화하고, 장애 발생 시에도 네트워크 계층별로 문제 범위를 분리해 대응할 수 있도록 설계

GitOps 기반 CI/CD

개발자가 애플리케이션 코드를 변경하면 GitHub Actions가 자동으로 테스트 및 빌드 과정을 수행하고, Docker Image를 생성한 뒤 Amazon ECR에 Push
배포 대상 이미지 태그와 Kubernetes 설정은 Infra Repository의 Manifest로 관리하여, 애플리케이션 코드와 배포 상태를 명확히 분리
Argo CD가 Infra Repository의 변경 사항을 감지하고, 선언된 Manifest와 실제 EKS 클러스터 상태를 비교하여 자동으로 동기화
배포 이력과 설정 변경이 모두 Git에 남기 때문에 추적 가능성, 롤백 용이성, 운영 일관성을 확보

무중단 배포

Kubernetes Rolling Update 전략을 적용하여 기존 Pod를 한 번에 종료하지 않고, 새로운 버전의 Pod를 순차적으로 생성한 뒤 트래픽을 전환
신규 Pod가 Readiness Probe를 통과한 경우에만 서비스 트래픽을 받을 수 있도록 구성하여, 준비되지 않은 애플리케이션으로 요청이 전달되는 상황을 방지
배포 중 문제가 발생하면 이전 ReplicaSet으로 되돌릴 수 있어 서비스 중단 시간 최소화와 빠른 장애 복구가 가능
실시간 입찰 서비스 특성상 배포 중에도 사용자의 입찰 요청과 WebSocket 연결 흐름이 최대한 유지되도록 가용성 중심의 배포 방식을 적용

🔐 Security & Network

AWS WAF 적용

AWS WAF를 ALB 앞단에 배치하여 애플리케이션 서버로 요청이 전달되기 전에 1차 보안 필터링을 수행
SQL Injection, XSS, 비정상 User-Agent, 과도한 반복 요청 등 웹 취약점을 노리는 트래픽을 사전에 차단
Rate Limit Rule을 적용하여 특정 IP에서 짧은 시간 동안 과도하게 요청하는 패턴을 제한하고, 입찰 API나 로그인 API에 대한 악성 반복 호출을 완화
보안 규칙을 인프라 계층에서 적용함으로써 애플리케이션 코드 변경 없이도 공통 보안 정책을 일관되게 유지

HTTPS / WSS 암호화 통신

ACM(AWS Certificate Manager) 인증서를 활용하여 사용자와 서비스 간 통신에 HTTPS를 적용
실시간 알림과 입찰 상태 전달에 사용되는 WebSocket 역시 WSS(WebSocket Secure) 기반으로 구성하여 양방향 통신 구간을 암호화
전송 구간에서 발생할 수 있는 패킷 위변조, 스니핑, 중간자 공격(MITM) 위험을 줄이고 사용자 인증 정보와 거래 데이터를 보호
브라우저 보안 정책에 맞는 안전한 연결을 제공하여 로그인, 결제, 실시간 알림 같은 주요 기능이 신뢰된 채널에서 동작하도록 구성

Secret 관리

DB 비밀번호, JWT Secret, Redis 접속 정보, 외부 API Key와 같은 민감 정보는 Git Repository와 Kubernetes Manifest에 직접 저장하지 않도록 분리
민감 값은 AWS SSM Parameter Store에 저장하고, 클러스터 내부에서는 External Secrets Operator를 통해 Kubernetes Secret으로 동기화하여 사용
Secret 변경 시 애플리케이션 설정 파일이나 Manifest를 직접 수정하지 않아도 되어 비밀 값 노출 위험과 운영 실수를 줄임
코드와 설정 저장소에는 Secret의 실제 값이 아닌 참조 구조만 남기므로, 협업 과정에서도 민감 정보 유출 가능성을 최소화

IRSA 기반 AWS 권한 관리

Pod 내부에 장기 Access Key를 직접 저장하지 않고, **IRSA(IAM Roles for Service Accounts)**를 적용하여 AWS 권한을 부여
Kubernetes ServiceAccount와 IAM Role을 연결해 특정 Pod가 필요한 AWS 리소스에만 접근할 수 있도록 최소 권한 원칙을 적용
예를 들어 S3 업로드가 필요한 Pod에는 S3 관련 권한만 부여하고, 다른 Pod에는 해당 권한이 전달되지 않도록 역할을 분리
Access Key 유출 위험을 제거하고, 워크로드 단위로 권한을 추적할 수 있어 보안성과 감사 가능성을 높임

Private S3 통신

S3 Gateway VPC Endpoint를 적용하여 Private Subnet의 애플리케이션이 인터넷을 거치지 않고 AWS 내부 네트워크를 통해 S3에 접근하도록 구성
이미지 업로드 및 조회 과정에서 S3 트래픽이 외부 인터넷 경로로 나가지 않도록 하여 네트워크 보안성과 전송 안정성을 강화
S3 Bucket Public Access를 비활성화하여 외부 공개 접근을 차단하고, 필요한 요청만 애플리케이션과 IAM 정책을 통해 제어
VPC Endpoint와 Bucket 정책을 함께 사용해 허용된 네트워크와 권한 주체만 S3를 사용할 수 있도록 접근 제어 범위를 명확히 제한