이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
멀티스레드 프로그래밍을 구현하면서 겪었던 문제는 경쟁 조건(race condition)이었습니다.
학부 운영체제 수업 과제에서 Java로 공유 자원에 여러 스레드가 동시에 접근하는 구조를 만들었을 때, 실행할 때마다 결과값이 달라지는 상황이 발생했습니다. 처음에는 로직 자체가 틀렸다고 생각했는데, 스레드 실행 순서가 보장되지 않아서 공유 변수 값이 덮어써지는 것이 원인이었습니다.
synchronized 키워드로 임계 구역을 보호하니 결과가 일관되게 나왔습니다. 이후 ReentrantLock을 써보면서 락의 범위를 더 세밀하게 조정할 수 있다는 것도 배웠습니다. 이 경험에서 멀티스레드는 실행 순서를 절대 가정하면 안 된다는 원칙을 몸으로 익혔고, 공유 자원이 생기는 순간 동기화 전략을 먼저 생각하는 습관이 생겼습니다.
멀티스레드 구현 중 겪은 두 번째 문제는 데드락이었습니다. 두 스레드가 서로 상대방이 보유한 락을 기다리면서 프로그램 전체가 아무 작업도 못하고 멈춰버리는 상황이 발생했습니다. 비정상 종료가 아니라 그냥 응답이 없는 상태여서 처음에는 원인을 찾는 데 오래 걸렸습니다. 스레드 덤프를 출력해보니 두 스레드가 서로를 기다리며 고착된 상태였습니다. 해결 방법은 락 획득 순서를 항상 동일하게 고정하는 것이었습니다. 두 스레드 모두 A 락 먼저, B 락 나중의 순서를 지키도록 수정하니 문제가 재현되지 않았습니다. 이 경험에서 공유 자원이 여러 개일 때는 락 획득 순서 규약을 설계 초반에 명시해야 나중에 찾기 어려운 버그를 예방할 수 있다는 걸 배웠습니다. 동기화 문제는 발생하기 전에 구조로 막는 것이 사후에 찾는 것보다 훨씬 쉽습니다.
멀티스레드를 구현하면서 겪은 또 다른 문제는 가시성(visibility) 문제였습니다. 한 스레드에서 변수 값을 수정했는데도 다른 스레드가 여전히 이전 값을 읽고 있는 상황이 발생했습니다. 처음에는 동기화 문제라 생각해서 synchronized를 먼저 시도했는데, 실제 원인은 JVM이 성능을 위해 각 스레드의 로컬 캐시에 변수 값을 따로 보관하는 것이었습니다.
volatile 키워드를 붙이자 모든 스레드가 메인 메모리에서 직접 읽고 쓰게 되면서 문제가 해결됐습니다. 그런데 volatile은 단순 읽기·쓰기에만 원자성이 보장되고 증가 연산 같은 복합 연산에는 `AtomicInteger`가 필요하다는 것도 그때 알게 됐습니다.
멀티스레드 버그는 재현이 안 되는 경우가 많아서 원인 파악까지 시간이 걸렸지만, 메모리 모델을 이해하고 나서야 도구 선택의 기준이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크래프톤 게임 서버 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.