이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
고성능 데이터 처리 시스템에서 가장 먼저 고려하는 건 처리할 데이터의 특성입니다. 배치성 데이터인지 실시간 스트리밍인지, 한 번에 들어오는 양과 빈도에 따라 아키텍처 방향이 완전히 달라집니다. 수업 프로젝트에서 로그 데이터를 처리하는 파이프라인을 설계할 때, 실시간 집계가 필요한 부분과 배치로 처리해도 되는 부분을 먼저 구분하는 것이 효율적이라는 걸 배웠습니다. 모든 데이터를 실시간으로 처리하려 하면 비용과 복잡도가 급격히 올라가기 때문에, 요구사항에 맞는 처리 방식을 선택하는 것이 설계의 핵심이라고 느꼈습니다.
요구사항에 맞지 않는 복잡한 설계는 비용과 장애 원인을 동시에 키웁니다.
확장 가능한 데이터 처리 시스템에서 중요하게 생각하는 건 수평 확장이 가능한 구조입니다. 단일 노드 성능을 높이는 방향보다, 처리량이 늘어날 때 노드를 추가해서 대응할 수 있는 설계가 장기적으로 유리합니다. 수업에서 MapReduce 개념을 배우면서, 데이터를 독립적인 단위로 쪼개서 병렬 처리하는 방식이 왜 대규모 시스템에서 표준이 됐는지를 이해했습니다. 개인 프로젝트에서 Python으로 배치 처리 스크립트를 만들었을 때, 단일 프로세스로는 처리 시간이 너무 길어서 멀티프로세싱으로 바꾼 경험이 있습니다. 설계 초반부터 확장성을 염두에 두는 것이 나중에 재작업을 줄이는 방법이었습니다.
데이터 처리 시스템 설계에서 놓치기 쉬운 부분은 데이터 품질 관리라고 생각합니다. 빠르게 많이 처리하는 것에만 집중하다 보면 잘못된 데이터가 그대로 흘러서 분석 결과 자체가 틀리는 상황이 생깁니다. 팀 프로젝트에서 외부 API로 받은 데이터를 바로 분석에 쓰다가, 중간에 값이 빠진 레코드가 섞여서 집계가 틀리는 문제가 생겼습니다. 그 이후로는 파이프라인 입구에서 검증 단계를 먼저 넣는 것이 중요하다는 걸 배웠습니다. 처리 속도만큼 데이터를 신뢰할 수 있는지를 확인하는 단계가 시스템 설계의 일부여야 한다고 생각합니다.
신뢰할 수 없는 데이터를 빠르게 처리하는 것은 빠르게 잘못된 결론을 내리는 것과 같습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.