MSG CTF (1st, 2nd)

담당 역할

Tech Stack

아키텍처 / ERD

1차는 인증 흐름이 중심입니다. 로그인에 성공하면 Access Token은 Authorization 헤더로, Refresh Token은 HttpOnly Cookie로 전달하고, JWT 필터가 만료 여부, tokenType, 블랙리스트 여부를 검증합니다. 이메일 인증 코드는 Redis에 5분 TTL로 저장합니다. 2차의 핵심 제출 흐름은 User → Challenge → History/TeamHistory → Challenge Score → Team Score로 이어집니다. 정답 제출 시 개인과 팀 중복 제출을 먼저 확인하고, 문제 단위 잠금 안에서 Challenge를 비관적 락으로 다시 읽어 solvers와 점수를 갱신한 뒤, 커밋 이후 팀 점수 재계산과 퍼스트 블러드 알림 같은 후처리를 분리했습니다.

1차 시스템 아키텍처

1차 README에 정리한 운영 구조입니다. 백엔드, 프론트엔드, DB, Redis, NGINX, Discord Bot이 함께 동작합니다.

2차 시스템 아키텍처

2차 대회 플랫폼의 팀 전체 구조입니다. 정답 제출과 채점, 순위와 마일리지, 디스코드 알림이 나뉘어 있습니다.

ERD

유저, 팀, 문제, 제출 기록, 점수, 토큰 데이터의 관계입니다.

주요 기능

• ✓[2차] 동시 플래그 제출 상황에서도 정답 기록, solvers, 동적 점수가 어긋나지 않도록, 1차 때 팀원이 넣은 문제 단위 Redisson 잠금 안에 DB 비관적 락과 실시간 solvers 계산을 더하고 후처리를 비동기로 분리했습니다.
• ✓[2차] 문제를 푼 팀에게 점수와 마일리지를 반영하고, 퍼스트 블러드 팀에는 보너스 마일리지를 지급하는 흐름을 구현했습니다.
• ✓[2차] 관리자가 문제를 검수할 때는 정답/오답만 확인하고 히스토리와 랭킹에는 반영되지 않도록 제출 흐름을 분리했습니다.
• ✓[2차] 팀 삭제 시 제출 기록, solvers, 다이나믹 스코어, 퍼스트 블러드, 팀원 소속, 결제 히스토리를 함께 정리하도록 운영 기능을 구현했습니다.
• ✓[2차] 유저 삭제 시 토큰/리더보드/제출 데이터는 제거하고, 문제 해결 히스토리는 익명화해 대회 기록 통계를 보존하도록 처리했습니다.
• ✓[1차] 회원가입 시 ID, 이메일, 비밀번호 형식과 중복 여부를 검증하고, 학교 이메일 도메인만 가입할 수 있도록 제한했습니다. 일반 회원가입 요청에서는 role을 항상 ROLE_USER로 고정해 사용자가 요청 본문으로 관리자 권한을 지정하지 못하도록 했습니다.
• ✓[1차] Gmail SMTP로 6자리 이메일 인증 코드를 전송하고, Redis에 인증 코드와 인증 완료 상태를 TTL 기반으로 저장했습니다. 인증 시도 횟수를 제한해 잘못된 코드 반복 입력을 방지했습니다.
• ✓[1차] 로그인 성공 시 Access Token과 Refresh Token을 분리 발급했습니다. Access Token은 Authorization 헤더로, Refresh Token은 HttpOnly Cookie와 DB에 저장해 토큰 재발급과 로그아웃 흐름을 구성했습니다.
• ✓[1차] 로그아웃 시 Refresh Token을 삭제하고 Access Token을 블랙리스트에 저장해 같은 Access Token으로 다시 인증되는 문제를 막았습니다. 만료된 블랙리스트 토큰은 스케줄러로 주기적으로 정리하도록 구현했습니다.
• ✓[1차] 문제 전체 조회와 특정 문제 상세 조회 API를 구현하고, 문제 상세 응답에 solvers 필드를 추가했습니다. 프론트엔드가 문제별 풀이 인원 정보를 함께 표시할 수 있도록 응답 데이터를 보강했습니다.

트러블슈팅

• [2차] 동시 제출 시 Redisson 락 타임아웃 문제문제 상황50개의 플래그 제출 요청이 동시에 들어오면 Redisson 분산 락의 waitTime 10초 안에 모든 요청이 락을 획득하지 못했다기존 제출 흐름은 락 내부에서 히스토리 저장, 퍼스트 블러드 판정, 팀 점수 계산, 다이나믹 스코어링, 전체 팀 재계산까지 순차 처리했다요청당 약 320~370ms가 소요되면서 10초 안에 약 25개 요청만 정상 처리되고, 나머지는 Try again later 또는 504 timeout으로 실패할 수 있었다해결 방안락 없이 가능한 검증과 오답 처리는 먼저 수행하고, 락 내부에서는 중복 재검증, History/TeamHistory 저장, DB 비관적 락 기반 Challenge 재조회, solvers/points 갱신만 처리하도록 범위를 줄였다결과PR 동시성 테스트 기준 성공률을 50%(25/50)에서 100%(50/50)로 개선했고, 평균 응답 시간은 약 5초에서 약 52ms 수준으로 줄였다
• [2차] 동적 점수 정합성 문제문제 상황동시에 여러 팀이 같은 문제를 풀면 solvers 증가 순서와 팀 점수 재계산 시점이 어긋나 팀마다 다른 점수가 반영될 수 있었다비동기 처리만으로 후처리를 분리했을 때도 여러 스레드가 같은 Challenge를 읽고 수정하면서 Lost Update가 발생할 수 있었다해결 방안락 획득 후 영속성 컨텍스트를 정리하고, Challenge를 비관적 락으로 다시 조회해 최신 solvers 기준으로 points를 계산했다이후 영향받은 팀 점수를 재계산하도록 제출 흐름을 정리했다결과여러 팀이 같은 문제를 동시에 풀어도 solvers와 팀 점수가 어긋나지 않고, Lost Update 경로가 사라졌다
• [2차] 팀 삭제 후 대회 데이터 정합성 문제문제 상황팀을 삭제하면 해당 팀이 푼 문제의 solvers, 다이나믹 스코어, 퍼스트 블러드, 팀원 소속 정보가 함께 바뀌어야 했다제출 기록만 삭제하면 랭킹, 문제 점수, 퍼스트 블러드가 실제 데이터와 어긋날 수 있었다해결 방안팀 히스토리와 개인 히스토리를 정리하고, 영향받은 문제들의 점수와 퍼스트 블러드를 다시 계산했다이후 전체 팀 점수를 재계산했다결과팀을 삭제해도 랭킹, 문제 점수, 퍼스트 블러드가 실제 데이터와 어긋나지 않는다
• [2차] 유저 삭제 트랜잭션 롤백 문제문제 상황유저 삭제 중 히스토리를 먼저 익명화한 뒤 loginId 기준으로 다시 삭제하려 하면서 삭제 대상 조회가 불가능해지고 트랜잭션이 롤백되는 문제가 있었다모든 데이터를 단순 삭제하면 대회 문제 풀이 통계까지 함께 사라지는 문제도 있었다해결 방안삭제 대상과 보존 대상의 의존성을 분리했다토큰, 제출 기록, 리더보드처럼 유저에 강하게 묶인 데이터는 삭제하고, History는 삭제 대신 익명화했다결과삭제 요청이 롤백 없이 끝나고, 유저를 지워도 대회 풀이 통계는 남는다
• [1차] 회원가입 권한 상승 가능성문제 상황초기 회원가입 요청에서 role 값을 사용자가 직접 전달할 수 있으면, 일반 사용자가 요청 본문에 admin 권한을 넣어 가입을 시도할 수 있었다해결 방안일반 회원가입에서는 요청 role을 신뢰하지 않고 ROLE_USER로 고정했다관리자 계정 생성은 별도 관리자 API 흐름으로 분리해 공개 회원가입과 권한 부여 책임을 나눴다결과외부 사용자가 회원가입 API만으로 관리자 권한을 얻을 수 있는 경로를 차단했다
• [1차] 이메일 인증 코드 만료와 반복 시도 문제문제 상황학교 이메일 인증 없이 회원가입이 가능하거나, 인증 코드를 무제한으로 시도할 수 있으면 대회 참가자 검증이 약해질 수 있었다해결 방안인증 코드는 Redis에 5분 TTL로 저장하고, 인증 성공 상태는 30분 TTL로 저장했다잘못된 인증 시도는 email 기준으로 카운트하고 5회를 넘으면 인증 코드와 시도 횟수 키를 삭제하도록 처리했다결과학교 이메일 인증을 회원가입의 필수 단계로 만들고, 만료/오입력/반복 시도 상황을 명확히 제어했다
• [1차] 로그아웃 후 Access Token 재사용 문제문제 상황초기 로그아웃 흐름은 Refresh Token 삭제 중심이어서, 이미 발급된 Access Token이 만료 전까지 남아 있으면 같은 토큰으로 인증 요청이 가능할 수 있었다해결 방안로그아웃 시 Access Token을 블랙리스트 테이블에 저장하고, JwtFilter에서 블랙리스트 토큰이면 요청을 거부하도록 수정했다토큰 만료 시간이 지난 블랙리스트 데이터는 30분 주기 스케줄러로 삭제했다결과로그아웃된 Access Token의 재사용을 서버 측에서 차단하고, 블랙리스트 데이터가 무기한 쌓이지 않도록 관리했다

아쉬웠던 점