이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AWS 데이터 처리 서비스와 Spark를 활용한 경험은 학교 프로젝트에서 S3에 저장된 대용량 로그 파일을 EMR 클러스터에서 Spark로 분석한 것이 있습니다. 로컬에서 처리하기 어려운 수십 GB의 로그를 파티셔닝과 필터링을 먼저 적용해 필요한 데이터만 추출하는 방식으로 처리했습니다. Spark에서 DataFrame API를 사용해 집계와 조인을 수행하고, 결과를 S3에 다시 저장했습니다. AWS Glue를 통해 스키마를 자동 탐색하고 카탈로그를 구성하는 방법도 실습했습니다. 로컬 환경과 달리 클러스터 설정과 IAM 권한 관리가 추가로 필요하다는 점도 경험했습니다.
클라우드 기반 데이터 처리는 스케일보다 비용과 권한 설계가 함께 고려돼야 한다는 것을 배웠습니다.
EMR에서 Spark 작업을 돌릴 때 처리 시간이 예상보다 10배 이상 걸리는 문제를 직접 디버깅한 경험이 있었습니다. 학교 프로젝트에서 30GB 로그 파일을 처리하는 작업이 3시간 넘게 걸렸는데, 처음에는 인스턴스 크기 문제라고 생각했지만 실제 원인은 파티션 수가 너무 적어서 병렬 처리가 안 된 것이었습니다.
Spark UI에서 스테이지별 처리 시간을 확인하고 나서야 원인을 찾았습니다. 파티션 수를 조정하자 처리 시간이 40분으로 줄었고, 인스턴스 비용은 그대로였습니다. 로그나 UI 없이 성능 문제를 감으로 해결하려 하면 원인을 잘못 짚는다는 걸 그때 배웠습니다. 지금은 Spark 작업이 느리면 먼저 UI에서 병목 스테이지를 확인하는 습관을 유지합니다.
데이터 처리 작업에서 비용과 시간을 수치로 기록하지 않으면 개선 여부를 알 수 없다는 걸 경험했습니다. 처음에는 작업이 '빠른 것 같다'는 느낌으로만 판단했는데, 같은 데이터를 두 가지 방법으로 처리한 결과를 실제로 측정해 보니 비용 차이가 3배였습니다. 느낌으로는 비슷해 보였지만 AWS 비용 대시보드 수치는 달랐습니다. 그 이후로는 파이프라인을 실행할 때 처리 시간·비용·오류율을 간단한 표로 기록하는 루틴을 만들었습니다. 기록이 쌓이면 설정 변경 전후를 비교할 수 있어서 개선 방향을 판단하기 쉬웠습니다.
수치 없는 최적화는 방향을 잃기 쉽다는 것을 그때 배웠습니다. 지금은 파이프라인 실행 후 기본 수치 세 가지를 항상 기록합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.