이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 실시간 경매 플랫폼 백엔드를 혼자 설계하고 구현했습니다. 가장 도전적인 부분은 동시 입찰 처리였습니다. 동시에 두 사용자가 같은 금액으로 입찰할 때 둘 다 낙찰로 처리되는 버그가 부하 테스트에서 발견됐고, 원인이 SELECT-UPDATE 사이 레이스 컨디션이었습니다. PostgreSQL의 FOR UPDATE SKIP LOCKED를 써서 입찰 행에 배타적 락을 걸고, 트랜잭션 안에서 금액 비교·업데이트를 원자적으로 처리하도록 바꿨습니다. 이후 초당 500건 동시 입찰 테스트에서도 중복 낙찰이 0건이 됐습니다. 이 경험으로 동시성 버그는 개발 환경에서 잘 안 보이고 실제 부하에서 드러나므로, 처음부터 락 전략을 설계에 포함시키는 것이 중요하다고 보게 됐습니다.
가장 도전적이었던 경험 중 하나는 운영 중인 서비스의 레거시 코드를 멈추지 않고 바꾸는 것이었습니다. 초기 설계가 잘못된 모듈이 전체 시스템에 의존성이 퍼져 있었고, 한 번에 바꾸면 서비스 전체가 깨지는 구조였습니다. 스트랭글러 패턴을 참고해 신규 요청은 새 모듈로, 기존 요청은 레거시로 라우팅하는 분기 레이어를 먼저 만들었습니다.
피처 플래그로 전환 비율을 조정하면서 새 모듈이 안정적이면 기존 코드 경로를 하나씩 제거했습니다. 이 방식 덕에 전환 중에도 팀원들이 새 기능 개발을 계속할 수 있었습니다. 레거시 마이그레이션에서 한 번에 완벽하게 바꾸려는 시도가 가장 위험하다는 걸 배웠습니다.
도전적인 경험 중 성능 문제는 추측이 아닌 측정으로만 풀린다는 걸 직접 배운 케이스가 있습니다. 특정 API가 부하 테스트에서 응답이 급격히 느려지는 문제가 있었는데, 처음엔 DB 쿼리가 문제라고 짐작하고 캐싱을 먼저 적용했습니다. 응답은 조금 빨라졌지만 본질적인 문제가 해결되지 않아 쿼리 최적화를 계속 시도했는데 효과가 없었습니다. 그래서 멈추고 프로파일러를 써서 실제 병목 지점을 측정했더니, 문제는 외부 API 동기 호출이 직렬로 쌓이는 것이었습니다.
asyncio.gather로 병렬화하니 응답 시간이 5.8초에서 1.2초로 줄었습니다. 어디가 느릴 것 같다는 추측으로 시작하면 엉뚱한 곳을 최적화하는 데 시간을 씁니다. 성능 문제는 측정 결과가 가리키는 곳을 먼저 파야 한다는 걸 몸으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.