이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
비동기 환경에서 동시성 문제를 처음 경험한 건 토이 프로젝트에서였습니다. 공유 자원을 여러 비동기 작업이 동시에 읽고 쓰는 구조였는데, 데이터가 간헐적으로 이상한 값이 되는 현상이 생겼습니다. 처음엔 원인을 찾는 데 이틀이 걸렸습니다. 로그를 봐도 특정 조건에서만 재현됐고, 비결정론적 동작이라 반복 재현도 어려웠습니다. 결국 뮤텍스를 사용해서 공유 자원 접근을 직렬화하는 방식으로 해결했습니다. 하지만 그 과정에서 락을 잘못 걸면 데드락이 생긴다는 걸 직접 경험했습니다. 두 작업이 서로의 락을 기다리면서 멈춰버린 상황이었는데, 타임아웃을 추가해서 임시 해결했습니다. 아직 실무 수준의 최적화는 모르지만, 동시성 문제는 재현이 어려우니 설계 단계에서 접근 패턴을 먼저 정하는 것이 중요하다는 걸 배웠습니다.
동시성 문제를 해결할 때 저는 락보다 구조 자체를 바꾸는 방향을 먼저 고민하는 편입니다. 공유 자원에 여러 작업이 동시에 접근하는 것 자체를 줄이면 문제가 단순해지기 때문입니다. 학부 프로젝트에서 채팅 기능을 구현할 때, 메시지를 직접 처리하지 않고 큐에 넣고 순서대로 처리하는 방식을 택했습니다. 처음엔 복잡해 보였는데, 구현하고 나니 동시 접근 문제가 자연스럽게 사라졌습니다. 다만 큐가 처리 속도를 따라가지 못하는 상황이 생겼고, 큐가 쌓이면 응답이 느려지는 문제를 뒤늦게 발견했습니다. 용량 제한과 처리 속도 모니터링을 추가하면서 해결했지만, 성능 문제를 미리 고려하지 못한 것이 아쉬웠습니다. 비동기 설계에서는 분리가 해결책이 될 수 있지만, 분리 자체가 새로운 문제를 만들기도 한다는 걸 배웠습니다.
프론트엔드 프로젝트에서 레이스 컨디션을 처음 경험했습니다. 검색 입력창에서 빠르게 타이핑하면 먼저 요청한 결과보다 나중 결과가 더 빨리 오는 경우가 있었는데, 화면에 이전 요청의 결과가 덮어씌워지는 현상이 발생했습니다. 처음엔 서버 문제인 줄 알았습니다. 디버깅하다가 응답 순서가 요청 순서와 다를 수 있다는 걸 알게 됐고, 그게 비동기 환경의 특성이라는 걸 처음 제대로 이해했습니다. 해결은 각 요청에 식별자를 붙이고, 가장 마지막 요청의 응답만 반영하는 방식으로 했습니다. 이미 오래된 요청은 무시하는 구조였습니다. 구현하면서 취소 가능한 요청(AbortController) 방식도 공부했는데, 실제로 적용하는 건 다음 프로젝트에서 해보려 합니다. 비동기에서는 응답 순서를 믿으면 안 된다는 게 가장 큰 배움이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.