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

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

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

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

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

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

낙찰자 결제

판매자 배송

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

@Entity@Table(name = "auctions")
@Getter@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor@BuilderpublicclassAuction {
@Id@GeneratedValue(strategy = GenerationType.IDENTITY)
privateLongid;
@Column(name = "current_price", nullable = false)
privateLongcurrentPrice;
@Version@Column(nullable = false)
privateLongversion;
publicvoidupdateCurrentPrice(LongbidPrice) {
this.currentPrice = bidPrice;
}
}

@Service@RequiredArgsConstructor@Transactional(readOnly = true)
publicclassBidService {
privatefinalAuctionRepositoryauctionRepository;
@TransactionalpublicvoidplaceBid(LongauctionId, LongbidPrice) {
Auctionauction = auctionRepository.findById(auctionId)
.orElseThrow();
// 현재 최고가보다 높은 경우만 입찰 허용if (bidPrice <= auction.getCurrentPrice()) {
thrownewIllegalArgumentException("INVALID_BID_PRICE");
}
// Optimistic Lock 기반 최고가 갱신auction.updateCurrentPrice(bidPrice);
}
}

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

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

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

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

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

• 개발자가 애플리케이션 코드를 변경하면 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 연결 흐름이 최대한 유지되도록 가용성 중심의 배포 방식을 적용

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

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

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

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

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

• Backend Repository
• Frontend Repository
• Infra Repository

이새연(팀장)	김어진	김현석	박미정	임서연	장성욱