이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
클라우드 환경에서 데이터 확장성을 확보하려면 수평 확장이 가능한 구조를 처음부터 설계해야 합니다. 파티셔닝 전략과 샤딩 키 설계가 잘못되면 나중에 수정 비용이 크게 발생합니다. 신뢰성을 위해서는 데이터 복제와 WAL(Write-Ahead Log) 기반 내구성 보장이 기본이고, 장애 시 자동 복구 경로도 설계 단계에서 포함해야 합니다. 수업 프로젝트에서 AWS S3 + Athena 구조를 설계하면서, 데이터 레이크의 파일 포맷 선택이 쿼리 성능과 비용 모두에 영향을 준다는 걸 배웠습니다. 확장성과 신뢰성은 서로 트레이드오프가 생기는 경우가 있고, 서비스 특성에 맞는 균형점을 찾는 것이 설계의 핵심이라고 생각합니다.
초기 설계 단계에서 확장성을 고려하지 않으면 이후에 구조를 뜯어야 하는 비용이 커지기 때문에, 아키텍처 결정의 타이밍이 중요하다고 생각합니다.
클라우드 환경에서 컴플라이언스 요건을 운영 중에 수동으로 확인하는 방식은 규모가 커지면 한계가 생깁니다. 대신 인프라 코드(IaC)에 정책을 조건으로 넣어서 요건에 맞지 않는 리소스가 생성되지 않도록 하는 방식이 더 안전합니다. 수업 케이스에서 Terraform에 암호화 설정이 없는 S3 버킷 생성을 차단하는 정책 조건을 추가하는 방식을 실습했습니다. 이렇게 하면 개발자가 실수로 컴플라이언스 요건을 놓치더라도 자동으로 방지됩니다. 사후 감사보다 사전 방지가 컴플라이언스 비용을 낮춥니다.
정책이 코드에 들어가면 실수가 차단됩니다. IaC가 컴플라이언스 일관성을 만듭니다. 사전 방지가 사후 감사보다 비용이 낮습니다.
클라우드 환경의 신뢰성 설계에서 RTO(복구 목표 시간)와 RPO(복구 목표 시점)를 먼저 정의하는 것이 기술 선택을 결정합니다. RPO가 0에 가까워야 한다면 동기 복제가 필요하고, 몇 분의 데이터 손실을 허용한다면 비동기 복제로 비용을 낮출 수 있습니다.
수업 설계 과제에서 RPO 1분, RTO 5분 기준을 정하고, 멀티 리전 비동기 복제 + 자동 페일오버 구조를 선택했습니다. 기준 없이 '이중화하면 된다'는 방향은 비용과 복잡도만 높이고 실제 보장을 못 하는 경우가 있습니다. RTO·RPO가 아키텍처 선택을 결정합니다.
기준 없는 이중화는 보장이 없습니다. 신뢰성 설계는 숫자로 시작합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.