면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
졸업 프로젝트에서 로그 수집·분석 파이프라인을 설계했습니다. 하루 수백만 건의 이벤트를 처리해야 해서, 단일 서버로는 처리량이 부족했습니다. Kafka로 이벤트를 버퍼링하고 컨슈머를 병렬로 늘리는 구조를 택했고, 처리량이 기존 단일 처리 대비 4배로 늘었습니다. 장애 상황을 대비해 컨슈머 그룹 오프셋을 주기적으로 커밋하고, 재시작 시 중복 처리를 최소화하는 방식도 설계에 포함했습니다.
스토리지 비용을 줄이기 위해 오래된 로그는 컬럼형 포맷으로 변환해 보관했고, 쿼리 속도가 JSON 대비 크게 향상됐습니다. 대용량 시스템은 처리량 설계보다 장애 복구 설계가 더 어렵다는 결을 배웠습니다.
대용량 데이터를 다루던 프로젝트에서 특정 날짜 범위 쿼리가 수십 초씩 걸리는 병목이 생겼습니다. 원인을 분석해 보니 테이블에 파티션이 없어 전체 스캔이 발생하는 구조였습니다. 날짜 기반 파티셔닝을 적용하고 자주 조회되는 컬럼에 인덱스를 추가했더니 쿼리 시간이 3초 이내로 줄었습니다. 배치 처리 측에서도 청크 단위로 나눠 처리하는 방식으로 메모리 오버플로 없이 대량 적재가 가능하게 했습니다. 단순히 하드웨어를 늘리기 전에 데이터 접근 패턴을 먼저 분석하는 것이 더 효과적이라는 점을 이 경험으로 배웠습니다.
실행 계획(EXPLAIN)을 읽고 병목을 추적하는 습관도 이때 들었습니다.
대용량 로그 데이터를 장기 보존하는 시스템을 설계할 때 스토리지 비용이 예상보다 빠르게 증가하는 문제가 있었습니다. 원인을 분석했더니 원본 JSON 형식 그대로 저장하고 있어 압축이 전혀 되지 않는 구조였습니다. Parquet 형식으로 변환하고 Snappy 압축을 적용했더니 동일한 데이터 기준 스토리지 용량이 약 70% 줄었습니다. 추가로 컬럼형 저장 구조 덕분에 특정 컬럼만 조회하는 분석 쿼리의 속도도 크게 빨라졌습니다. 이 경험에서 대용량 데이터 처리는 처리량과 비용을 함께 고려해 형식을 선택하는 것이 중요하다는 점을 배웠습니다.
직렬화 형식과 압축 알고리즘의 트레이드오프를 이해하고 나면 설계 선택이 훨씬 명확해집니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.