이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
GPU 병렬 처리 아키텍처를 이해한 뒤 성능 최적화에 접근하는 방식이 달라졌습니다. 워프 단위로 스레드가 묶여 실행되기 때문에, 분기 조건이 스레드마다 다르면 직렬화가 발생해 성능이 크게 떨어지는 구조를 이해하고 나서 커널 설계 방향이 바뀌었습니다.
메모리 대역폭이 병목인 경우가 많았습니다. 연산 집약적인 커널보다 메모리 접근이 많은 커널이 더 느린 경우도 있어, 접근 패턴을 분석해 공유 메모리를 중간 버퍼로 활용하는 방식으로 전역 메모리 접근을 줄였습니다.
Nsight 같은 프로파일러로 점유율과 메모리 트랜잭션 효율을 측정하는 것이 핵심이었습니다. 추측으로 최적화하는 것보다 측정 먼저, 최적화 다음의 순서를 지켜야 실질적인 개선이 이뤄진다는 것을 배웠습니다.
GPU 성능 최적화 작업에서 직접 커널 코드를 짜면서 배운 것은 처음 작성한 코드와 최적화된 코드가 크게 다르다는 것이었습니다. 처음에는 기능이 맞게 작동하도록 짰는데, 프로파일러로 측정하니 메모리 접근 패턴이 비효율적이라는 것을 알게 됐습니다. 인접한 스레드가 메모리의 인접한 위치를 접근해야 캐시가 효율적으로 동작하는데, 처음 짠 코드에서는 스레드 인덱스와 메모리 접근 패턴이 맞지 않아 지연이 컸습니다. 접근 패턴을 맞추도록 데이터 배치를 바꾸니 속도가 개선됐는데, 이 최적화를 이해하고 적용하는 데 직접 작성하고 측정해본 경험이 가장 도움이 됐습니다. 최적화 효과가 예상보다 크지 않은 경우도 있었는데, 프로파일러로 확인하니 그 구간이 전체 실행 시간에서 차지하는 비중이 작아서였습니다. GPU 성능 최적화는 병목이 어디 있는지 먼저 측정하지 않으면 효과 없는 곳에 시간을 쓰게 된다는 것을 이 경험에서 배웠습니다.
GPU 성능 최적화를 하면서 성능을 높이면 코드 가독성이 낮아지는 트레이드오프를 경험했습니다. 메모리 접근을 줄이기 위해 공유 메모리를 직접 관리하거나 연산 순서를 바꾸는 방식은 성능은 개선됐지만, 처음 코드를 이해하지 못하면 왜 이런 구조인지 파악하기 어려웠습니다. 다른 팀원이 코드를 유지보수할 때 최적화 의도를 이해하지 못하고 수정하면 성능이 다시 떨어지는 경우도 있었습니다. 또한 특정 GPU 구조에 맞게 최적화된 코드가 다른 세대 하드웨어에서는 오히려 성능이 나쁜 경우도 있었는데, 하드웨어에 의존적인 최적화는 이식성을 낮춘다는 것을 배웠습니다. 성능 최적화의 효과를 장기적으로 유지하려면 코드와 주석으로 최적화 의도를 남기는 것이 중요하다는 것을 이 경험에서 배웠습니다. GPU 최적화는 일회성 작업이 아니라 하드웨어 변화에 따라 지속적으로 재검토해야 하는 작업이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.