이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
GPU 프로그래밍을 처음 접한 것은 컴퓨터 그래픽스 수업에서 OpenGL과 C++로 기본 3D 장면을 렌더링하는 과제였습니다. CPU에서 처리하던 연산을 GPU로 옮기면서 처리 속도가 눈에 띄게 빨라지는 것을 직접 경험했습니다. 버텍스 셰이더와 프래그먼트 셰이더의 역할을 이해하고 나면, 3D 객체가 화면에 그려지는 파이프라인 흐름이 명확해졌습니다.
GLSL로 간단한 조명 계산 셰이더를 작성했는데, 각 픽셀에서 병렬로 실행되는 구조가 CPU 코드와 완전히 다른 사고 방식을 요구한다는 것을 배웠습니다. Python에서는 PyOpenGL로 프로토타이핑하고, 성능이 필요한 부분은 C++로 옮기는 방식을 실험해봤습니다. 한계는 렌더링 최적화나 복잡한 셰이더 효과는 아직 경험이 부족하다는 점입니다. GPU 프로그래밍은 병렬 처리에 맞는 알고리즘을 새로 설계하는 것이 결임을 배웠습니다.
그래픽스 수업에서 씬을 렌더링할 때 오브젝트가 많아질수록 FPS가 급격히 떨어지는 문제를 겪었습니다. RenderDoc으로 분석해보니 드로우 콜이 오브젝트 수만큼 개별 발행되고 있었고, CPU-GPU 통신 오버헤드가 병목이었습니다. 처음엔 셰이더를 손봐야 한다고 생각했는데, 원인은 렌더링 구조에 있었습니다.
같은 메시를 반복 그리는 오브젝트들을 인스턴싱으로 묶어 단일 드로우 콜로 처리하도록 수정했습니다. 나무 100개를 개별 드로우했던 씬에서 드로우 콜을 100개에서 1개로 줄이니, FPS가 22에서 67로 올라갔습니다. 이후엔 재질이 같은 오브젝트를 배칭으로 묶는 규칙을 씬 구조 설계 단계에 넣었습니다.
이 경험으로 GPU 병목은 셰이더 복잡도보다 드로우 콜 수가 먼저인 경우가 많다는 걸 배웠습니다.
GPU 프로그래밍에 관심이 생긴 뒤, 물리 시뮬레이션을 GPU에서 돌리는 프로젝트를 개인적으로 시작했습니다. 처음에는 Python과 ModernGL로 빠르게 프로토타입을 만들었는데, 파티클 1만 개를 CPU에서 처리하는 구조가 10FPS 이하로 떨어졌습니다.
CUDA의 컴퓨트 셰이더로 파티클 위치 계산을 GPU에 넘겼습니다. 각 파티클이 독립적으로 계산되는 구조라 스레드 1개당 파티클 1개를 배정했고, 렌더링 전에 컴퓨트 패스에서 위치를 먼저 갱신하는 방식으로 파이프라인을 구성했습니다. 처음엔 CPU-GPU 메모리 복사 타이밍을 잘못 짜서 결과가 한 프레임씩 밀렸는데, 동기화 순서를 고치면서 안정됐습니다.
이 경험으로 GPU는 반복 계산을 병렬로 쏟아내는 구조에 강하고, 문제를 그 구조로 다시 짜는 것이 시작임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.