소프티어 부트캠프 (WAS · DingDong)

be-was-2025

• Java 소켓 기반 WAS 직접 구현 (Spring 미사용)
• 소켓 수용 · 스레드 관리 · HTTP 파싱 · 정적 파일/템플릿 응답
• @RequestMapping · @RequestParam · @Body · @Cookie 애노테이션 라우팅
• 타입 안전 이종 컨테이너, 실제·테스트 DB 연결 분리

DingDong

• 대학생 통학 셰어 버스 예매 서비스
• 반경 3km · 최대 15명 배차 (Tmap API)
• 강의 시간표 기반 예매 시간 추천
• 백엔드 3 · 프론트엔드 2, 데일리 스크럼·회고

주요 경험

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

사건 상세

사용자 진술에 따르면, 단일 인스턴스 제약 아래 본인은 예약 요청을 애플리케이션 측 수신 순서에 따라 처리하는 기술적 도전을 목표로 삼았다. Nginx 뒤 단일 스레드 조절기에서 버스 ID별 요청을 한 번에 하나씩 통과시키는 구조를 제안했다. 동료는 사용자의 클릭 순서가 네트워크와 Nginx를 거치며 바뀔 수 있으므로 엄밀한 순서 보장에 큰 자원을 들이지 말자는 입장이었다. 최종적으로 공정한 세마포어를 채택했다. 설계 선택 당시 임박한 일정과 성과 지표 산출·발표 자료 준비에 필요한 시간을 고려했고, 조절기까지 구현했다면 모두 마치기 어려웠을 것으로 판단했다. 기억상 본인은 멀티스레드에서 요청 순서가 보장되지 않는다는 우려를 설명했다. 동료와 테스트 방식을 함께 구상했으며 코드는 동료가 작성한 것으로 기억한다. 1ms 단위로 시도한 테스트에서는 순서 뒤바뀜을 재현하지 못해 더 진행하지 않았다. 이는 2026-09-18 사용자 진술을 기록한 draft다. 저장소에서 공정성 설정 세마포어와 CountDownLatch를 사용한 동시성 테스트는 코드로 확인했다. 해당 테스트 본문이 동료의 커밋에서 추가된 사실도 Git 이력으로 확인했다. 사용자는 그 실험으로 ReservationConcurrencyTest.java를 지목했지만, 현행 파일에는 기억한 1ms 간격 조정과 순서 역전 검증이 보이지 않는다. 당시 실행 방식과 팀 합의 과정은 아직 확인되지 않았다. 관련 역량은 협업과 기술적 판단이다.