이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Golang으로 URL 배치 크롤러를 만들며 고루틴을 처음 깊이 써봤습니다. 수백 개의 URL을 순차 처리하면 너무 느려서, 고루틴과 WaitGroup으로 동시 처리 수를 제어하는 구조를 만들었습니다. 처음엔 고루틴을 무제한으로 띄웠다가 메모리가 급증하는 문제가 생겼고, channel을 세마포어로 활용해 동시 실행 수를 20개로 제한했습니다. 결과 수집은 뮤텍스로 보호한 슬라이스에 쓰는 방식과 결과 채널로 받는 방식을 비교해봤는데, 채널 방식이 경쟁 조건 위험이 적고 코드도 더 직관적이었습니다. Go의 동시성 모델이 다른 언어와 다른 점은 스레드 대신 고루틴이라 생성 비용이 낮다는 것인데, 그 감각을 실제 코드를 짜며 익혔습니다.
동시성 버그는 재현이 어려워서 처음 설계할 때 더 신경 써야 하는 자리라는 걸 배웠습니다.
Golang 동시성 기능에서 지표가 분명해진 경험은 고루틴 수를 늘렸을 때 처리량 변화를 측정한 케이스였습니다. 동시 실행 고루틴 수를 높이면 무조건 빠를 것이라고 생각했는데, 일정 수 이상부터는 오히려 처리량이 줄어드는 것을 측정에서 확인했습니다.
외부 API 호출이 병목인 경우에는 고루틴을 늘려도 API 응답 속도가 한계를 정한다는 걸 이해했습니다. 동시성에서 고루틴 수는 많을수록 좋은 것이 아니라, 병목이 어디에 있는지에 따라 적절한 수가 달라진다는 결이 생겼습니다.
Golang 동시성 기능에서 안전을 의식하게 된 경험은 뮤텍스 없이 공유 자원을 수정했을 때 데이터 경쟁이 발생한 케이스였습니다. 처음에는 고루틴 여러 개에서 슬라이스에 동시에 쓰는 코드를 만들었는데, -race 플래그로 빌드해서 실행하니 데이터 경쟁이 탐지됐습니다.
채널로 수집하는 방식으로 바꾼 뒤 경쟁이 사라졌습니다. Go에서 고루틴 간 공유 자원 접근은 명시적으로 보호하지 않으면 재현이 어려운 버그가 생기고, `-race` 플래그로 조기 탐지하는 것이 나중에 찾는 것보다 비용이 낮다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.