예약 처리 순서 보장을 둘러싼 아키텍처 의견 차이

경험 정보

• 프로젝트: 소프티어 부트캠프 DingDong (softeer-was-dingdong)
• 사건 시점: 2025.01~2025.03 프로젝트 중, 정확한 날짜 확인 필요
• 정리 상태: draft
• 관련 역량: 협업, 기술적 판단
• 관련 문항: 미연결 (협업·기술적 의사결정 문항 후보)
• 마지막 확인: 2026-09-18

상황과 과제

사용자 진술에 따르면 부트캠프에서는 단일 인스턴스만 허용했고, 그 환경에서 예약 처리 효율을 높이는 것이 중요했다. 예약 요청의 처리 순서를 어떤 수준까지 보장할지를 두고 동료와 의견이 달랐다.

본인의 제안과 판단

본인은 기술적 도전 목표로 예약 요청을 애플리케이션 측 수신 순서에 따라 엄밀히 처리하려 했다. Nginx 뒤에 단일 스레드 예약 요청 조절기 프로세스를 두고, 버스 ID별로 한 번에 요청 하나만 Spring Boot 서버로 통과시키는 구조를 제안했다. 멀티스레드 실행 순서는 스레드 생성 순서와 같다고 보장되지 않고, 공정한 lock 또는 semaphore도 요청의 최초 도착 순서 자체를 보장하지 않는다는 점을 근거로 들었다. 기억상 본인은 팀에 멀티스레드 서버의 동작 원리와 순서가 엄밀히 보장되지 않는다는 우려를 설명했다. 이는 당시의 제안과 주장으로, 단일 스레드 조절기 구현은 확인되지 않았다.

동료의 반론

동료는 Nginx와 네트워크를 거치므로 사용자가 실제로 예약 버튼을 누른 시각의 순서대로 서버가 처리하는 것은 불가능하다고 보았다. 따라서 이미 바뀔 수 있는 순서를 엄밀히 보장하는 데 큰 자원을 쓰지 말자는 입장이었다.

최종 선택과 결과

사용자 진술에 따르면 최종적으로 공정한(fair) 세마포어를 사용하는 예약 처리 구조를 채택했다. 설계를 선택하던 당시 임박한 일정과 성과 지표 산출·발표 자료 준비에 필요한 시간을 고려했다. 본인은 단일 스레드 조절기를 추가로 구현했다면 프로젝트를 모두 마치기 어려웠을 것으로 판단했다. 어떤 날짜가 임박했는지와 이를 팀에 어떻게 설명했는지는 아직 확인되지 않았다. 기억상 순서 뒤바뀜을 재현하려는 테스트에서 1ms 단위로 스레드 동작을 조정했으나 우려한 현상이 나타나지 않아 이 문제를 더 진행하지 않았다. 사용자는 테스트 방식을 동료와 함께 구상했고, 코드 작성은 동료가 했던 것으로 기억한다. 사용자는 당시의 테스트로 저장소의 ReservationConcurrencyTest.java를 지목했다. 현행 파일은 CountDownLatch로 예약 요청을 동시에 시작하지만, 기억한 1ms 간격 조정이나 순서 역전 검증은 파일에서 확인되지 않았다. 당시 실행 방식 또는 미커밋 수정 여부는 미확인이다. 재현되지 않았다는 관찰이 순서 보장 자체의 증명은 아니다. 공정한 세마포어가 사용자의 클릭 순서나 서버 최초 도착 순서를 보장했다는 뜻도 아니다. 팀 논의의 정확한 순서와 테스트의 세부 결과는 미확인이다.

근거와 확인 수준

• 2026-09-18 사용자 직접 진술: 단일 인스턴스 제약, 양측 제안과 근거, 공정한 세마포어 채택, 설계 선택 당시의 임박한 일정과 지표·발표 준비로 인한 시간 제약. 저장소 코드에서 버스 일정별 StoppableSemaphore(..., true) 초기화와 예약 경로의 tryAcquire() 호출은 확인했다. 이는 공정성 설정이 있는 세마포어를 사용했다는 근거이며, 엄밀한 요청 순서 보장의 근거는 아니다.
• 2026-09-18 Git 이력 확인: 예약 동시성 테스트의 latch 기반 본문은 동료의 2025-02-22 커밋 017ca2bd에서 추가됐다. 커밋 작성자는 코드 작성의 근거이며, 테스트를 함께 구상했다는 부분은 사용자 기억에 따른다.
• 2026-09-18 코드 확인: ReservationConcurrencyManager.java와 StoppableSemaphore.java에서 예약 세마포어 사용을 확인했다. ReservationConcurrencyTest.java는 CountDownLatch로 동시 요청을 시작해 좌석 수 관련 동작을 시험한다. 사용자가 기억하는 실험의 파일로 이 테스트를 확인했다. BusSubscriptionLockManagerTest.java는 latch로 시작을 맞춘 뒤 5ms 또는 10ms 간격으로 구독 락을 시도하지만 예약 처리의 순서 검증 테스트와는 구분된다. 현행 파일에서 1ms 간격의 순서 역전 검증은 확인되지 않았다.
• 요청 순서 보장의 기준 지점(조절기 수신 시점 등)은 추가 확인 필요하다.

남은 질문

• 사용자가 기억한 1ms 단위 조정은 현행 ReservationConcurrencyTest.java에 없는데, 당시 미커밋 수정이나 실행 조건이 있었는가?
• 단일 인스턴스 제약은 단일 서버/배포 인스턴스를 뜻하는가? 별도 프로세스는 허용되었는가?
• 채택한 공정한 세마포어를 버스별로 어떻게 적용했고, 동시 예약 처리의 정확성을 어떻게 검증했는가?