이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 수업과 팀 프로젝트에서 멀티스레드 환경의 버그를 처음 직접 경험했습니다. 가장 먼저 맞닥뜨린 건 데이터 경쟁(Race Condition) 문제였는데, 같은 변수를 여러 스레드가 동시에 쓰면서 결과가 실행마다 달라지는 상황이었습니다. synchronized 키워드로 임계 구역을 보호하면서 접근 순서를 직렬화해서 일관성을 확보했습니다. 데드락은 두 스레드가 서로 다른 순서로 잠금을 획득하려다가 서로 기다리는 상황에 빠지는 케이스를 실습에서 경험했고, 잠금 획득 순서를 전역적으로 통일하는 방식으로 해결했습니다. 스레드 풀 크기를 너무 크게 설정하면 컨텍스트 스위칭 비용이 오히려 성능을 낮추는 경험도 했습니다.
멀티스레드 버그는 재현이 어려워서 예방하는 설계가 사후 디버깅보다 훨씬 낫다는 걸 배웠습니다.
학부 프로젝트에서 멀티쓰레드 환경으로 자원 공유 코드를 처음 짰을 때, 가끔 프로그램이 멈추는 현상이 생겼습니다. 데드락이라는 건 이론으로만 알고 있었는데 직접 마주치자 어디서 막혔는지 찾는 것부터 막막했습니다. jstack으로 스레드 덤프를 분석해보니 두 스레드가 서로 다른 락을 반대 순서로 잡으려다 막혀 있었습니다. A 스레드는 락1 → 락2 순서로, B 스레드는 락2 → 락1 순서로 잡으려는 구조였습니다. 해결책은 단순했습니다. 모든 스레드에서 락 획득 순서를 동일하게 강제하자 데드락이 사라졌습니다. 이 경험으로 멀티쓰레드 코드에서는 락 순서를 설계 단계에서 문서화해두는 게 중요하다는 걸 배웠습니다.
인턴 프로젝트에서 요청별 사용자 컨텍스트를 전역 변수로 저장했다가, 동시 요청이 들어오면 서로 다른 사용자 정보가 섞이는 버그가 생겼습니다. 처음에는 synchronized로 잠금을 걸었는데, 잠금 범위가 너무 넓어져 처리량이 절반으로 줄었습니다. 공유 자원의 경합이라는 근본 구조를 바꾸지 않으면 해결이 안 된다는 걸 느꼈습니다. 결국 ThreadLocal을 써서 스레드마다 독립적인 컨텍스트를 갖도록 바꿨습니다. 잠금 없이도 각 요청이 서로 간섭 없이 처리됐고, 처리량이 회복됐습니다.
공유를 막는 것이 잠금을 쓰는 것보다 더 근본적인 해결인 경우가 있다는 걸 이 경험으로 처음 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.