리멤버 Data Engineer 면접 준비 가이드

기준일 2026-08-07 목적 제출 과제 방어, 직무 적합성, 운영 확장, 행동면접을 한 번에 연습하기 위한 비공개 준비 자료 1차 면접 2026-08-12 · Data Engineer 팀장, 팀원 1명 전형 순서 1차 통과 후 2차 진행 · 2차 면접 구성은 Needs confirmation

웹 문서 키워드 메모와 함께 열기 PDF 다운로드 연결 학습 예상 질문 ↔ 스터디 지도 면접 허브 이력서·포트폴리오·과제 아키텍처 모아 보기

웹 문서에서 청록색 점선 키워드에 마우스를 올리면 짧은 뜻이 먼저 보이고, 누르면(모바일은 탭) 쉬운 설명·전문가 설명·기억할 것이 그 자리에서 열린다. 면접관에게는 전문용어보다 무슨 문제였는지 → 왜 그 방법을 골랐는지 → 무엇으로 확인했는지를 먼저 전달한다.

1. 면접관이 먼저 알아야 할 내 일

한 문장으로 요약

여러 곳에서 이름과 표기 방식이 다르게 들어오는 데이터를 ‘결국 같은 대상인지’ 판단해 연결하고, 잘못 연결되거나 빠진 데이터를 다시 찾아 고칠 수 있게 만드는 일을 해 왔다.

다룬 데이터: 오픈소스 프로그램의 이름·버전, 취약점 번호, Linux 배포판별 보안 권고
반복된 문제: 같은 제품이 다른 이름으로 들어오거나, 다른 제품이 같은 것처럼 합쳐짐
내가 한 일: 어느 데이터를 같게 볼지 규칙을 정하고, 원본·변경 이력·재처리 경로를 남김
리멤버와의 연결점: 사람·회사·프로필을 같은 대상으로 식별하고 믿을 수 있게 유지하는 문제 구조가 닮아 있음

전문용어를 쉽게 바꿔 말하기

CVE·OSV: 소프트웨어 취약점에 붙이는 공통 번호와 공개 데이터
RAW / STG: 나중에 다시 확인할 수 있게 남긴 원본 / 대조하기 좋게 정리한 중간 데이터
MDM: 사람·회사처럼 핵심 대상을 하나의 기준 정보로 합쳐 관리하는 방식
멱등성: 같은 작업을 다시 실행해도 중복 반영되지 않는 성질
backpressure: DB가 감당할 수 없을 때 요청이 무한히 쌓이지 않게 속도를 늦추는 장치
collation: 대소문자·언어별 차이를 포함한 문자열 비교 규칙
reconciliation: 이관이나 재처리 뒤에 원본과 결과를 다시 대조해 누락·차이를 찾는 절차

2. 이 문서를 읽는 순서

1회차: 굵은 문장과 숫자만 읽고 답변의 뼈대를 익힌다.
2회차: 질문을 가리고 소리 내어 답한 뒤 이어질 질문까지 이어 간다.
3회차: 과제 수치와 사실 경계를 섞어 묻는 압박 면접으로 연습한다.
답변이 길어지면 상황 1문장 - 선택 2문장 - 검증 1문장 - 한계 1문장으로 줄인다.

면접 신호 지도

P0 · 데이터 정합성 원천의 의미, 키, NULL, 중복, 이력, 재처리, 검증을 한 흐름으로 설명한다.
P0 · Airflow 운영 재시도, 멱등성, backfill, 트랜잭션, 실패 복구의 실제 경계를 말한다.
P0 · 식별·매핑·MDM 동일 인물·회사 판단을 문자열 일치로 단정하지 않고 근거와 되돌림 경계를 둔다.
P0 · 이관 대상 집합 고정, 사전 대조, canary, go/no-go, rollback, 사후 reconciliation을 연결한다.
P1 · 규모와 관측 현재 단일 writer 가정을 인정하고 전환 조건과 지표를 말한다.
P1 · Remember Way 고객 영향, 가드레일이 있는 실행, 증거로 수렴하는 협업을 사례에 담는다.

이 문서의 안전선

확인된 결과와 운영 보완안을 구분한다.
Unknown, Needs confirmation은 답변을 꾸미라는 표기가 아니다. 확인 전에는 말하지 않는다.
제출 문서와 최신 사실이 다르면 최신 사실을 먼저 말하고 정정 책임을 인정한다.

3. 첫 90초: 자기소개, 전환 이유, Why Remember

첫 문장을 짧게 말한 뒤 경험과 지원 이유를 한 줄로 연결한다.

P0-01. 30초 자기소개를 해주세요.

답변 스크립트 저는 여러 곳에서 다른 이름으로 들어오는 데이터를 ‘결국 같은 대상인지’ 판단해 연결해 온 데이터 엔지니어입니다. 지난 5년간 오픈소스 제품과 버전, 취약점, 12종 Linux 배포판의 보안 정보를 맞춰 왔습니다. 잘못 연결되거나 빠진 데이터는 이름을 식별하는 규칙부터 저장 구조와 재처리 방법까지 고쳤습니다. 리멤버에서는 이 경험으로 명함·프로필·회사 데이터를 오래 믿을 수 있게 만들고 싶습니다.

이어질 질문 가장 가까운 사례는 컴포넌트 식별자 재설계와 원천 레지스트리 전수 대조입니다. 같은 제품이 이름과 대소문자 차이로 나뉘거나 다른 제품이 하나로 합쳐지는 문제를 키 정책과 원천 대조로 풀었기 때문입니다.

P0-02. 90초로 경력 흐름을 설명해 주세요.

답변 스크립트 저의 경력은 ‘잘못된 결과의 원인을 재현하고, 다시 발생하지 않게 구조를 고치는 일’로 이어져 있습니다. 석사 과정에서는 IoT 펌웨어를 실제로 실행해 취약점을 찾았고, 2021년부터는 오픈소스 제품과 버전, 취약점 데이터를 수집·연결·검증했습니다. 같은 데이터가 문자열 비교 규칙이나 식별자 차이로 나뉘고, 원본이 없어 오류를 다시 확인하지 못하는 일도 겪었습니다. 그래서 원본 보존부터 실행 환경, MySQL, 저장소, 백업과 모니터링까지 책임 범위를 넓혔습니다. 리멤버에서도 원본부터 최종 이용자가 보는 결과까지 한 흐름으로 확인하겠습니다.

이어질 질문 연구에서는 가설만 세우지 않고 실제 실행 결과와 원문을 다시 대조하는 습관을 익혔습니다. 이 방식이 데이터 누락과 불일치의 원인을 증거로 좁히는 정합성 분석으로 이어졌습니다.

P0-03. 왜 지금 Data Platform / Data Engineering으로 옮기려 하나요?

답변 스크립트 저는 현재 회사에서 수집부터 저장, 실행 환경, 배포와 모니터링까지 넓게 경험했습니다. 그중 가장 오래 붙잡고 성과를 낸 축은 식별·매핑·데이터 품질이었습니다. 이제 식별·매핑·마스터 데이터·정합성을 직무의 중심으로 더 깊게 다루는 팀에서 여러 원천의 품질·재처리·관측 기준까지 설계하는 엔지니어로 성장하고 싶습니다.

이어질 질문 현 회사를 부정적으로 평가해서 옮기려는 것은 아닙니다. 다음 단계에서는 사람·회사처럼 기준 정보가 계속 변하는 식별 문제를 더 깊게 다루고 싶고, 리멤버 직무가 그 문제와 직접 맞닿아 있기 때문입니다.

P0-04. 왜 다른 회사보다 리멤버인가요?

답변 스크립트 리멤버는 제가 해 온 ‘여러 표기를 같은 대상으로 연결하는 일’이 사람과 회사 데이터에서 직접 중요한 곳입니다. 주변 추천으로 명함과 프로필을 올린 뒤 스카우트 제안을 받고 공고를 봤습니다. 공고의 정교한 매핑, MDM, 데이터 정합성은 같은 회사가 여러 이름으로 들어와도 한 회사로 알아보고, 잘못 연결하지 않게 관리하는 일입니다. 이 품질이 프로필과 기회의 신뢰를 떠받치기 때문에 직접 지원했습니다.

이어질 질문 사람·기업 데이터의 의미와 개인정보 기준은 새로 배워야 합니다. 다만 원본을 남기고, 같은 대상을 판단한 근거와 변경 이력을 보존하며, 잘못된 결정을 검증하고 되돌리는 운영 원리는 그대로 적용할 수 있습니다.

4. 직무 적합성과 솔직한 경험 경계

운영 경험, 학습 중인 영역, 경험이 없는 영역을 분명히 나눈다.

P0-05. 이 직무에 바로 기여할 수 있는 강점은 무엇인가요?

답변 스크립트 저는 오류가 보이면 쿼리 하나를 고치거나 서버부터 늘리기보다, 데이터가 어디서 갈라졌는지를 먼저 찾습니다. 오픈소스 제품 데이터에서는 문자열 비교 규칙, 테이블 구조, 검색 인덱스와 식별자 규칙이 함께 엇갈려 있는 원인을 풀었습니다. 또 원천 누락을 조사할 때는 외부의 기준 목록과 우리 데이터를 전수 대조했습니다. 리멤버에서도 원본부터 최종 사용 데이터까지, 어느 경계에서 의미가 달라졌는지 먼저 확인하겠습니다.

이어질 질문 조사와 대안 작성, 구현은 제가 맡았습니다. 다만 중심 구조는 혼자 확정하지 않았고, 영향 범위가 컸기 때문에 팀장과 CTO 리뷰를 거쳐 결정했습니다.

P1-06. Spark·Kafka 경험이 부족한데 괜찮나요?

답변 스크립트 저는 Spark·Kafka·Flink를 프로덕션에서 운영한 경험이 없습니다. 대신 Python·SQL·Airflow·Kubernetes·MySQL로 수십억 행 DB와 80개가 넘는 크롤러의 스케줄링·pool/backoff, 재처리, 동시성, backpressure를 다뤘습니다. 현재 강점으로 먼저 기여하고, 분산 처리는 팀의 실제 데이터량과 지연 요구를 기준으로 실행 모델부터 학습하겠습니다.

이어질 질문 제가 운영한 CDC는 약 1시간 단위로 binlog 파일을 전달하는 배치형 동기화입니다. Kafka 같은 실시간 스트리밍을 운영한 경험과는 처리 방식과 지연 기준이 다릅니다.

P1-07. OLAP DB 경험은 어느 수준인가요?

답변 스크립트 저는 StarRocks·ClickHouse 같은 OLAP DB의 프로덕션 운영 경험을 주장하지 않겠습니다. 과제에서는 연도별 전체 스냅샷 조인과 전수 검증에 DuckDB를 썼고, 실무에서는 MySQL 실행계획과 대규모 데이터 배치 운영 경험이 중심입니다. OLAP 전환은 소비 쿼리, 동시 사용자, freshness, 비용을 확인한 뒤 판단하겠습니다.

이어질 질문 분석용 대량 조회가 운영 트랜잭션을 방해하거나, 집계 응답시간과 동시 사용자 요구를 운영 DB에서 맞추기 어려워질 때 OLAP 계층을 검토합니다. 별도 저장과 동기화 비용보다 운영 DB 보호와 조회 성능의 이익이 커지는 시점이기 때문입니다.

P0-08. AWS 경험 범위를 정확히 말해 주세요.

답변 스크립트 제가 프로덕션에서 운영한 AWS 범위는 EC2입니다. MySQL과 애플리케이션을 EC2에서 직접 운영했고, RDS·S3·EFS 운영 경험은 없습니다. 제출 자료의 관련 태그는 최종 검수에서 놓친 잘못된 표기이며, 질문받으면 바로 정정하겠습니다.

이어질 질문 온프레미스 환경에서 SeaweedFS를 설계하고 데이터를 단계적으로 이관한 경험은 있습니다. 객체 저장소의 용량·복제·이관 문제를 다뤘지만, 이를 AWS S3 운영 경험이라고 표현하지는 않겠습니다.

P1-09. 개인정보가 많은 데이터는 어떻게 다루겠습니까?

답변 스크립트 제 확인된 경력은 보안 메타데이터 중심이라 리멤버의 개인정보 운영 경험이 있다고 말하지 않겠습니다. 입사하면 먼저 수집 목적, 접근 주체, 보존·삭제 규칙과 감사 경계를 확인하겠습니다. 파이프라인에는 최소 권한, 민감 필드 분리·마스킹, 재처리 산출물의 동일 정책, 접근 로그와 만료 절차를 넣고 실제 사내 기준에 맞추겠습니다.

이어질 질문 보안 데이터를 다룬 경험만으로 개인정보 운영을 잘 안다고 말할 수는 없습니다. 수집 목적과 보존 기간, 접근 권한, 법적 기준이 다르기 때문에 리멤버의 정책과 담당자 판단을 먼저 배워야 합니다.

5. 제출 과제: 30초 구조와 반드시 외울 수치

구조를 먼저 설명하고, 수치는 질문을 받았을 때 근거와 함께 꺼낸다.

P0-10. 과제 파이프라인을 30초로 설명해 주세요.

답변 스크립트 2022년과 2023년 회사 목록을 비교해 새로 생긴 회사, 바뀐 회사, 그대로인 회사를 구분하는 파이프라인을 만들었습니다. 먼저 입력 파일을 원본(RAW)으로 남기고, 중간 단계(STG)에서 사업자번호·주소·근로자수·날짜를 같은 형식으로 정리했습니다. 이후 사업자번호로 신규·변경·변경 없음을 나누고, 최종 목록·변경 이력·최근 원본에서 사라진 항목·8개 검증을 한 번에 커밋했습니다. DuckDB 파일을 한 작업만 쓰게 하기 위해 실행은 직렬로 제한했습니다.

이어질 질문 태스크 사이에는 큰 데이터 자체를 넘기지 않았습니다. XCom에는 연도, 파일 경로, 적용 정책, 처리 건수처럼 다음 태스크가 작업을 찾는 데 필요한 작은 정보만 전달했습니다.

P0-11. 왜 DuckDB를 선택했나요?

답변 스크립트 저는 이 과제를 행 단위 OLTP보다 연도별 CSV 전체 읽기, 집합 조인, 컬럼 비교와 전수 검증 문제로 봤습니다. DuckDB의 CSV 읽기, 컬럼 지향 실행, IS DISTINCT FROM, 단일 파일 재현성이 맞았습니다. 약 3만 행에서 성능을 과장하려는 선택은 아니었습니다. 여러 writer와 온라인 serving이 필요하면 중앙 DB나 warehouse로 옮기겠습니다.

이어질 질문 DuckDB 파일 하나에 여러 작업이 동시에 쓰는 구조에는 적합하지 않습니다. 현재 설계가 한 번에 한 회차와 한 writer를 전제로 하기 때문에 동시 쓰기가 필요해지면 중앙 DB나 다른 저장 구조로 바꿔야 합니다.

P0-12. 결과 수치를 설명해 주세요.

답변 스크립트 저는 2022년 30,513행을 초기 적재했고, 2023년 소스 23,261행을 처리했습니다. 공통 키 21,087개 중 4,000개 사업장이 바뀌었고 17,087개는 no-op이었습니다. 신규는 2,174개, 2023 소스에 없던 기존 키는 9,426개여서 최종 마스터는 32,687행, 활성 23,261행입니다. 컬럼 단위 UPDATE 이력은 5,196행이며 2023 STG와 활성 마스터의 불일치는 0건입니다.

이어질 질문 변경된 사업장은 4,000개지만 한 사업장에서 주소와 근로자수처럼 여러 속성이 함께 바뀔 수 있습니다. 변경 이력을 컬럼별로 한 건씩 남겼기 때문에 전체 이력은 5,196건입니다.

수치 압축 암기

30,513 + 2,174 = 32,687: 초기 마스터 + 신규 = 최종 마스터
21,087 = 4,000 + 17,087: 공통 키 = 변경 + no-op
23,261 + 9,426 = 32,687: 활성 + 최근 소스 부재
4,134→4,000: 정규화·재분류 뒤 집합 수준의 변경 후보 사업장 수가 줄었다.
3,086 - 210 = 2,876: 주소 변경 이벤트 후보에서 표기 차이 210건을 제외한 결과다.
5,196: 주소 2,876 + 근로자수 1,972 + 이름 310 + 날짜 30 + 업종 8
8/8, 불일치 0: 연도별 정합성 검사와 2023 최종 대조

6. 과제 방어: 키, NULL, 부재, SQL, MDM

입력에서 확인한 사실, 과제 정책, 운영에서 필요한 합의를 구분한다.

P0-13. 사업자등록번호를 왜 키로 썼고 어떻게 정규화했나요?

답변 스크립트 과제 원문이 Insert·Update 기준으로 사업자등록번호를 지정했기 때문에 업무 키로 썼습니다. 공백과 하이픈만 제거하고 ASCII 숫자 10자리가 아니면 제외했습니다. checksum 불일치 9개는 두 연도에 같은 키로 반복됐고 외부 정답이 없어 WARN과 원문을 남긴 채 반영했습니다. 모르는 값을 보정해 다른 사업장과 합치는 위험을 피했습니다.

이어질 질문 현재 파일에서는 중복 키가 0건이었습니다. 중복이 생기면 지금 자료에는 갱신시각이 없어 행 순서를 임시 기준으로 사용할 수밖에 없지만, 운영에서는 원천 우선순위와 이벤트 시각, 버전처럼 설명 가능한 선택 기준이 필요합니다.

P0-14. 2023년 빈 값을 왜 NULL로 덮어썼나요?

답변 스크립트 과제 문구의 ‘2023년 최신 정보로 갱신’을 literal rule로 적용했습니다. 주소 결측 2,249개 중 2,093개는 2022 값이 있어 추출 누락일 가능성도 보였습니다. 그래서 기본은 overwrite로 두고 preserve existing on null을 명시적 옵션으로 제공했으며 두 정책 모두 별도 기대값으로 8개 검증을 통과시켰습니다. 운영에서는 컬럼별 completeness 계약과 사업 소유자의 의미 확인이 먼저입니다.

이어질 질문 과제에서는 옵션별 결과를 재현하는 것이 답이지만, 운영 정책은 데이터 소유자와 함께 정해야 합니다. NULL이 미수집인지 삭제 요청인지 알 수 없는 상태에서 제가 하나의 보편 규칙을 정하면 실제 의미를 훼손할 수 있기 때문입니다.

P0-15. 2023년에 없는 9,426건을 왜 삭제하지 않았나요?

답변 스크립트 파일 부재만으로 폐업, 추출 누락, 공개 범위 변경을 구분할 수 없고 원문도 Delete를 요구하지 않았습니다. 그래서 다섯 업무 속성은 유지하고 is_active=false, absent_since_year=2023만 남겼습니다. strict 해석을 위해 부재를 무시하는 옵션도 뒀습니다. 제가 확인한 사실은 ‘최근 소스에 없었다’까지입니다.

이어질 질문 soft delete는 관리 컬럼 추가가 허용된 범위 안에서 선택했지만, 데이터 해석이 들어간 확장인 것은 맞습니다. ignore 옵션은 필수 다섯 업무 속성의 Insert·Update 결과를 그대로 재현하고, active·absent 상태만 운영 추적을 위해 별도로 관리했습니다.

P0-16. Insert·Update·no-op SQL은 어떻게 나눴나요?

답변 스크립트 기준은 간단합니다. 정리된 원천 데이터를 사업자번호로 기존 목록과 연결했습니다. 기존 키가 없으면 신규, 다섯 속성 중 하나라도 다르면 변경, 모두 같으면 변경 없음(no-op)으로 분류했습니다. SQL의 IS DISTINCT FROM을 써서 값에서 NULL로, 또는 NULL에서 값으로 바뀐 것도 놓치지 않았습니다. 변경이 없으면 최종 데이터와 변경 이력을 쓰지 않았습니다.

이어질 질문 비교할 컬럼이 다섯 개이고 어느 값이 바뀌었는지 컬럼별 이력을 남겨야 해서 직접 비교를 선택했습니다. Python과 SQL 사이에서 NULL·문자열 직렬화 규칙이 달라져 hash 결과가 어긋날 위험도 피할 수 있기 때문입니다.

P1-17. 이 설계를 리멤버 MDM으로 어떻게 확장하겠나요?

답변 스크립트 리멤버의 사람·회사 데이터는 사업자번호 하나로 정답을 낼 수 없다고 보겠습니다. 먼저 정확히 일치하는 규칙으로 연결하고, 남은 데이터는 출처·시간·보조 식별자 근거를 점수화하겠습니다. 근거가 충분하면 자동 연결, 애매하면 사람 검토, 부족하면 보류로 나눕니다. 표본을 검사해 잘못 합친 비율과 같은 대상을 나눈 비율을 확인하고, 언제든 잘못된 연결을 풀고 이후 데이터를 다시 만들 수 있게 결정 근거와 버전을 남기겠습니다.

이어질 질문 문자열 유사도만으로는 동명이인과 이직, 법인 변경을 구분하기 어렵습니다. 이름 점수는 후보를 줄이는 데 쓰고, 최종 연결은 시간과 출처, 연락처, 회사 식별 근거를 함께 확인해야 합니다.

7. 과제 방어: Airflow, 멱등성, 트랜잭션, DQ

현재 구현이 보장한 범위와 운영에서 보완할 범위를 나눠 답한다.

P0-18. Airflow에서 어떤 운영 경계를 뒀나요?

답변 스크립트 Airflow에서 2022년 초기 적재와 2023년 갱신을 같은 작업 흐름으로 만들었습니다. 연도는 스케줄러가 전달한 기준 시간에서 가져오고, DuckDB에 두 작업이 동시에 쓰지 않게 한 번에 하나의 실행만 허용했습니다. 다만 이 제한은 연도 순서까지 자동으로 보장하지는 않아 이전 연도로 돌아가는 갱신은 별도 규칙으로 막았습니다. 파일이 없는 실행은 실패와 구분해 SKIPPED로 남겼고, 운영에서는 파일 도착 기한과 재처리 승인 절차가 추가로 필요합니다.

이어질 질문 SKIP만 보면 정상 미실행과 파일 미도착을 구분하기 어렵습니다. 태스크 실행 상태와 파일 도착 약속은 서로 다른 신호이기 때문에 운영에서는 도착 시각을 따로 감시하고 알림을 보내야 합니다.

P0-19. 재실행이 왜 안전한가요?

답변 스크립트 RAW와 STG는 해당 연도 스냅샷을 각각 한 트랜잭션에서 교체합니다. 같은 2023 스냅샷을 다시 적용하면 업무 속성과 마스터 행 수는 유지되고, Insert 0, 속성 Update 0, 변경 이력 증가 0입니다. 다만 등장한 키의 상태 컬럼 UPDATE와 RAW·STG 교체, 실행 기록은 다시 씁니다. 2023 뒤 2022를 넣는 역행은 merge 전에 막습니다.

이어질 질문 완전히 아무것도 쓰지 않는 것은 아닙니다. 확인한 키의 상태 UPDATE와 RAW·STG·실행 기록은 남고, 0인 것은 신규 Insert, 업무 속성 Update, 변경 이력 증가입니다.

P0-20. 회차 전체가 exactly-once인가요?

답변 스크립트 최종 업무 데이터는 ‘한 번만 반영된 것처럼’ 보이게 만들었지만, 실행 기록까지 완전히 한 번만 기록된다고 말할 수는 없습니다. 최종 목록, 변경 이력, 원본에서 사라진 항목과 8개 검증은 하나의 트랜잭션으로 묶었습니다. 그러나 성공 상태와 건수는 그 커밋 뒤에 따로 기록됩니다. 두 단계 사이에서 중단되면 데이터는 반영됐지만 상태는 실행 중으로 남을 수 있어, 실행 메타데이터까지 exactly-once라고 과장하지 않겠습니다.

이어질 질문 업무 데이터와 실행 기록이 같은 DB에 있으면 한 트랜잭션으로 묶겠습니다. 저장소가 분리돼 있으면 operation marker나 outbox를 남기고, 오래된 RUNNING 상태를 실제 업무 데이터와 다시 대조해 복구하겠습니다.

P0-21. 데이터 품질과 차단 기준은 무엇인가요?

답변 스크립트 키 결측·형식 오류, 근로자수 파싱 오류, 중복 탈락은 ERROR로 제외했습니다. has_valid_key는 더 넓은 is_valid와 분리했습니다. 속성 ERROR나 중복 탈락 행은 merge에서 제외하지만 업무 키가 유효하면 현재 소스에서 본 키로 계산해 잘못된 부재·비활성화를 막습니다. checksum·날짜 이상은 외부 정답 없이 고치지 않고 WARN, 주소 결측은 INFO로 남겼습니다. 실제 파일의 ERROR는 0건이고 2023은 WARN 29, INFO 2,249였습니다. 1% ERROR 허용률은 과제 기본값일 뿐 운영 SLA가 아니며 rule별 임계치가 필요합니다.

이어질 질문 검증 항목은 키 유일성, 행 수 증분, 분류 합계, 소스 키 포함 여부, 정책값 일치, NULL 보호, 활성 상태, 미래 last_seen_year 존재 여부의 여덟 가지입니다.

P0-22. 문서와 구현이 다른 부분이 있나요?

답변 스크립트 세 가지를 먼저 바로잡겠습니다. README는 절단 의심 주소 4건을 quarantine했다고 적었지만 실제로는 수동 프로파일링 후보이며 runtime rule이 없습니다. 대표 실행 로그는 동일 core를 쓴 CLI 경로이고, clean extraction에서는 Airflow 2022·2023 run도 같은 결과로 확인했습니다. 제출 문서는 107 tests, 현재 같은 최종 소스 재검증은 108 tests이므로 기록 시점을 나눠 말하겠습니다.

이어질 질문 코드와 테스트 결과는 확인했지만 문서의 각 문장을 실제 실행 산출물과 다시 대조하지 못했습니다. 문서도 검증 대상이라는 출고 기준이 빠져 있었기 때문에 생긴 검수 공백입니다.

8. 프로덕션 압박: 규모, 동시성, 이관, 관측, 스키마

현재 설계의 한계를 먼저 인정하고 전환 조건과 검증 순서를 말한다.

P1-23. 수백만 행으로 늘면 무엇부터 바꾸나요?

답변 스크립트 먼저 한 연도의 데이터를 모두 Python 메모리에 올리는 부분부터 바꾸겠습니다. 현재는 작은 과제에는 추적하기 쉽지만, 수백만 행에서는 메모리가 먼저 부족해집니다. DuckDB SQL이나 Arrow·Polars로 데이터를 메모리에 전부 올리지 않고 청크 단위로 처리하고, 스냅샷별 목록과 파티션을 두며, 실행 계획·디스크 임시 사용·메모리를 측정하겠습니다. 동시에 여러 작업이 쓰거나 소비자가 많아지면 단일 DuckDB 파일을 공유하지 않고 중앙 DB나 데이터 웨어하우스로 옮기겠습니다.

이어질 질문 단일 노드에서 메모리와 I/O, 처리시간 한계를 먼저 측정하겠습니다. 데이터를 나누고 전달하고 장애를 복구하는 분산 처리 비용보다 처리시간 단축과 확장 이익이 커질 때 Spark를 선택하겠습니다.

P0-24. 같은 연도 backfill이 동시에 돌면 안전한가요?

답변 스크립트 현재는 안전하다고 주장하지 않겠습니다. max_active_runs=1, 직렬 태스크, 짧은 연결이라는 단일 회차 가정에 기대고 있고 일부 STG·검증 조회가 run_id 대신 source_year 범위를 씁니다. 병렬화를 허용하려면 모든 접근을 run_id 또는 immutable snapshot으로 격리하고 (run_id, key) 유일성, lease, publish pointer를 두겠습니다.

이어질 질문 락만으로는 충분하지 않습니다. 락은 writer 충돌은 막지만 읽기 격리, 재시도 중복, 결과 공개 시점의 원자성까지 해결하지 못하므로 회차별 snapshot 경계가 필요합니다.

P0-25. 대규모 이관은 어떤 순서로 진행하나요?

답변 스크립트 이관은 ‘무엇을 언제 기준으로 옮기는지’를 고정하는 것부터 시작합니다. 먼저 원본과 새 저장소의 키, 행 수, 핵심 속성을 대조합니다. 실제 전환 전에 미리 실행하고 일부 대상만 먼저 옮겨 이후 사용처의 결과를 비교합니다. 어느 수준의 차이면 멈추거나 되돌릴지를 미리 합의하고, 전환 뒤에도 원본과 결과를 다시 대조합니다. 실제 IDC 이관에서 확인된 범위는 전후 테이블 행 수 대조입니다.

이어질 질문 실제 IDC 이관에서 명시적인 rollback을 실행했는지는 현재 기록으로 확인되지 않습니다. 제가 실제로 확인한 것은 전후 테이블 행 수 대조이며, rollback 절차는 운영 이관에서 필요하다고 보는 설계 원칙입니다.

P1-26. 무엇을 모니터링하고 언제 멈추나요?

답변 스크립트 freshness·latency·ERROR 비율·행 수 drift·no-op spike·중복·소스 대비 불일치를 함께 보겠습니다. 키 유일성이나 정책값 불일치처럼 마스터를 오염시키는 조건은 배포를 막고, checksum이나 의미 미확정 이상은 WARN과 판정 큐로 분리합니다. 임계치는 과거 baseline, 영향도, 오탐 비용을 보고 owner와 정하겠습니다.

이어질 질문 실시간 이상 감지에 항상 Kafka가 필요한 것은 아닙니다. 몇 초 안에 알아야 하는지와 원천이 변경 이벤트를 제공하는지를 먼저 확인하고, 허용 지연이 분 단위라면 micro-batch나 주기적인 metric 수집이 더 단순할 수 있습니다.

P1-27. 원천 스키마가 바뀌면 어떻게 대응하나요?

답변 스크립트 현재 과제는 헤더 이름과 순서가 다르면 fail closed하고 RAW를 보존합니다. 운영에서는 schema version, additive·required 컬럼 정책, 버전별 parser와 consumer contract test를 둡니다. breaking change는 dual-read와 backfill로 검증하고, 새 파서의 결과를 이전 기간에 재계산해 차이를 확인한 뒤 전환하겠습니다.

이어질 질문 컬럼 추가를 무조건 막지는 않습니다. 데이터 계약에 선택 컬럼 추가를 허용한다고 명시하되, 알 수 없는 변경이 기존 컬럼의 의미나 소비자 결과를 조용히 바꾸지 않도록 검사합니다.

9. 포트폴리오 기술 심층 질문

결과 수치의 단위와 본인·협업자의 책임 범위를 함께 말한다.

P0-28. 가장 복잡한 데이터 문제를 어떻게 풀었나요?

답변 스크립트 중앙 DB의 CPU가 비정상적으로 높아져, 느린 쿼리와 실행계획을 따라가며 원인을 좁혔습니다. 두 테이블의 문자열 비교 규칙(collation)이 달라 연결 조회에서 인덱스를 쓰지 못하고 있었습니다. 동시에 제품 식별자가 충돌하거나 대소문자 차이로 같은 제품이 나뉘는 문제도 발견했습니다. 그래서 비교 규칙, 테이블 구조, 인덱스, 식별자 정책을 함께 재설계했고, 실행계획의 예상 스캔 행이 약 130만에서 약 6,000으로 줄었습니다. 이는 응답시간이나 CPU 감소율을 잰 수치는 아닙니다.

이어질 질문 수치로 확인한 것은 실행계획상 예상 스캔 행이 약 130만에서 약 6,000으로 줄었다는 점입니다. 실제 응답시간과 CPU 감소율은 기록으로 확인되지 않았고, 식별자 충돌과 누락 구조를 수정한 사실은 확인됐습니다.

P0-29. 80개 넘는 크롤러의 DB 오류를 어떻게 줄였나요?

답변 스크립트 80개가 넘는 수집기가 각자 DB 연결과 재시도를 관리해 lock·connection 오류가 하루 3~4건씩 났습니다. 저는 모든 수집기가 같은 운영 규칙을 쓰도록 HTTP Broker API 하나로 DB 쓰기 요청을 모았습니다. 대기열에 크기 제한을 두고 작업자 수와 DB 연결 수를 통제했으며, 대기열이 차면 429 + Retry-After로 호출자가 나중에 다시 요청하게 했습니다. 같은 요청이 중복 반영되지 않도록 키와 upsert를 쓰게 했고, 각 담당자는 자기 수집기를 이관했습니다. 저는 공통 구조와 운영 규칙을 맡았고, 적용 후 4개월간 해당 오류는 0건이었습니다.

이어질 질문 대기열이 가득 찼을 때 요청을 계속 받아 내부 메모리에 쌓으면 장애가 더 커집니다. 그래서 429와 Retry-After로 현재 처리할 수 없다는 사실을 드러내고, 호출자가 정해진 시점에 다시 요청하도록 했습니다.

P0-30. 위험한 DB 변경을 어떤 근거로 진행했나요?

답변 스크립트 운영 DB의 인덱스를 많이 지우는 작업이라, ‘아마 안 쓸 것’이 아니라 지워도 되는 근거를 먼저 만들었습니다. 수집 DB는 전체 수집기의 쿼리를 조사했고, 배포 DB는 분석 엔진이 사용하는 95개 쿼리의 실행계획을 모두 확인했습니다. 인덱스 311개 중 해당 쿼리에서 쓰이지 않는 224개를 찾고 삭제 순서와 필요한 SQL 수정을 리뷰했습니다. 그 후 수집 DB는 9.6TB에서 4TB, 배포 DB는 2.6TB에서 1.2TB로 줄었고, 고객사 설치용 DB 생성 시간은 12시간에서 6시간으로 줄었습니다.

이어질 질문 외부에서 다시 받아야만 재처리할 수 있던 흐름을 RAW 선보존 구조로 바꿨습니다. 적용된 소스는 재처리 외부 요청이 0건이 됐지만, 2일→5분은 설계 산정 예시라서 실측 성과로 말하지 않겠습니다.

추가 심층 카드

MySQL 8.4 최대 약 30억 행 사전 검증에서 HDD 쓰기 회귀를 보고 innodb_flush_method 기본값 변화로 좁혔다. 하드웨어별 기준을 나누고 단계적으로 적용했다.
Kubernetes 용량 2노드에서 유휴 서버 4대를 worker로 더하고 pool·backoff·resource request를 함께 조정했다. Pod 할당 실패는 주 70~100건에서 주 1~5건 수준으로 줄었다. 최초 클러스터 설계자라고 말하지 않는다.
관측 10~20대 서버의 자원, DB, 수집 누락, 고객사 동기화 상태를 같은 시간축에서 봤다. 탐지 시간 감소율은 확인되지 않았다.

10. 행동면접: STAR, 협업, 90일, 공백 방어

검증된 사례만 쓰고, 확인되지 않은 갈등·실패·피드백은 답변으로 만들지 않는다.

P0-31. 장애를 임시 복구에서 구조 개선까지 가져간 사례는?

답변 스크립트 사내 범용 PC로 옮긴 뒤 수집 집중 시간의 쓰기·I/O와 M.2 발열이 겹쳐 월 10~20건의 운영 이슈가 났습니다. 저는 syslog, 스케줄, 네트워크를 같은 시간축으로 보고 먼저 수집 시간을 분산해 월 5건 미만으로 낮췄습니다. IDC 서버가 준비된 뒤 수집·배포·운영 DB를 분리하고 primary/replica, 백업, 모니터링을 다시 구성했습니다. 2024년 전환 뒤 확인된 이슈는 1~2건이며, AWS는 EC2에서 self-managed MySQL을 운영한 범위입니다.

이어질 질문 당시에는 바로 옮길 장비가 준비되지 않았습니다. 그래서 수집 시간을 먼저 분산해 서비스 영향을 낮추고, 장비가 준비된 뒤 검증 순서에 따라 DB 역할을 분리했습니다.

P0-32. 여러 담당자와 어떻게 협업했나요?

답변 스크립트 저는 공통 실행 환경과 크롤러별 도메인 로직의 소유권을 나눴습니다. Airflow·Kubernetes 자원, DB 접근 경계, 저장소와 모니터링은 제가 맡고 각 담당자는 자기 수집기 로직을 맡았습니다. 공통 변경의 범위·적용 순서·근거를 문서로 남기고 팀장·CTO 리뷰를 거쳤습니다. 각 담당자가 자기 크롤러를 이관했고, 저는 공통 구조와 운영 규칙을 맡았습니다.

이어질 질문 현재 정리된 자료에는 상대의 우려와 제 양보, 최종 결정까지 정확히 확인되는 의견 충돌 사례가 없습니다. 기억이 불분명한 이야기를 만드는 대신 면접 전 실제 사례 한 건을 다시 확인하겠습니다.

P1-33. 입사 후 90일 계획은?

답변 스크립트 30일까지 핵심 개체·키·매핑, 원천에서 소비자까지의 흐름, 담당자와 개인정보 경계를 익히겠습니다. 60일까지 한 원천이나 데이터 품질 문제를 맡아 기준값, 재처리, 중단선을 설명할 수 있게 하겠습니다. 팀 우선순위와 권한이 허용하면 90일까지 작은 개선 하나를 배포까지 이어가고, 결과·한계·재처리·되돌림 방법을 문서로 남기겠습니다. 대형 재설계보다 팀이 믿고 작은 범위를 맡길 수 있는 판단 방식을 먼저 증명하겠습니다.

이어질 질문 첫 과제는 고객 영향, 문제의 반복 빈도, 결과를 측정할 수 있는지, 잘못됐을 때 되돌릴 수 있는지를 기준으로 비교하겠습니다. 초기에 작은 범위를 고르는 이유는 팀의 운영 기준을 배우면서도 결과를 안전하게 확인할 수 있기 때문입니다.

P1-34. 반복되는 약점은 무엇인가요? (준비용 · 확인 전 사용 금지)

준비 메모 이 문항은 아직 면접용 답변이 아니다. 과제 README에 있어야 할 설계 판단을 다른 문서로 옮겼다가 독립 재리뷰에서 발견했고, 이후 요구사항-산출물 매핑, production-path 테스트, 깨끗한 압축 해제 E2E를 출고 조건으로 둔 사실은 확인됐다. 그러나 이것이 직장에서도 반복되는 개인 약점인지는 확인되지 않았다. 본인이 실제 반복 패턴이라고 확인하기 전에는 사용하지 않는다.

확인할 것 실제 반복 상황, 발생한 비용, 당시 본인 책임, 이후 행동 변화가 모두 기억과 기록에 맞는지 직접 확인한다. ‘완벽주의’ 같은 포장 문장으로 바꾸지 않는다.

P0-35. 실패 경험을 말해 주세요.

답변 스크립트 직장 실패가 아니라 최근 제출 과제의 사전 발견 near-miss로 답해도 되는지 먼저 묻겠습니다. 독립 재리뷰에서 README 필수 항목 누락, production에서 쓰지 않는 경로를 검증한 테스트, 재패키징 뒤 실행 권한 위험을 발견했습니다. 제출물 소유자의 검수 실패로 받아들이고 README 복구, production-path 테스트, 파일 모드·인코딩 검사, 한글 경로 clean extraction E2E를 추가했습니다. 제출 전 Airflow 두 회차 성공과 source-master 불일치 0을 확인했습니다.

이어질 질문 독립 재리뷰에는 AI 도구도 사용했습니다. 다만 도구가 지적한 내용을 요구사항과 실제 실행 결과로 확인하고 최종 제출을 결정한 책임은 제출자인 저에게 있습니다.

이어질 질문 현재 자료만으로는 손실과 제 책임을 함께 정확히 설명할 수 있는 직장 실패 사례가 확인되지 않습니다. 사실과 다른 답을 만들지 않고, 면접 전 실제 경험 한 건을 기록과 함께 다시 확인하겠습니다.

답변 금지 공백

대인 갈등 상대의 우려, 내 양보, 공통 증거, 최종 결정이 확인된 사건이 없다.
직장 개인 실패 실제 손실과 본인 책임이 함께 확인된 사건이 없다.
받은 피드백 누가 무엇을 지적했고 행동이 어떻게 바뀌었는지 확인된 사건이 없다.
위 세 항목은 그럴듯한 사례를 만들지 말고, 면접 전 실제 경험으로 채운다.

11. 역질문, 사실 가드, 최종 리허설

우선순위 역질문

“이 역할의 새 입사자가 첫 90일에 독립적으로 소유하길 기대하는 소스나 매핑 문제는 무엇이며, 성공을 어떤 증거로 판단하시나요?”
“최근 데이터 정합성 이슈 하나를 어떻게 발견했고, 어떤 조직과 해결했으며, 결과를 어떤 지식으로 남겼나요?”
“매핑 정확도와 freshness가 충돌할 때 팀이 포기하지 않는 가드레일과 최종 판단권은 어디에 있나요?”
“오매핑과 미매핑을 어떤 지표·샘플링·현업 피드백으로 보고, 품질을 누가 판정하나요?”
“원천이나 매핑 로직 변경 뒤 재처리, downstream 영향, rollback을 어떤 절차로 검증하나요?”
“직접적이고 열린 커뮤니케이션이 팀의 의견 차이에서 잘 작동했던 실제 예를 하나 들어주실 수 있나요?”

사실 가드

AWS는 EC2 only + self-managed MySQL. RDS·S3·EFS 생산 경험 없음.
Spark·Kafka·Flink·dbt·Snowflake 생산 경험 없음. OLAP DB 직접 운영 경험을 만들지 않음.
CDC는 약 1시간 단위 binlog 파일의 배치형 동기화. 실시간 스트리밍으로 말하지 않음.
EF-Fuzz는 2020년 석사학위 논문·원 연구, FIRM-COV는 이를 확장한 2021년 IEEE Access 공동 논문, 제3저자.
130만→6,000은 실행계획상 스캔 행 수. 응답시간·CPU 감소율이 아님.
ETL 2일→5분은 설계 산정 예시. 결과로 사용하지 않음.
DML Broker의 0건은 적용 후 4개월 동안의 기록, IDC 전환 뒤 운영 이슈는 확인된 1~2건.
약 10개 고객사 배포·일상 운영은 기술지원팀, 저는 설계·구현·재현·개선·기술 지원을 담당.
공식 직급, lead 시점, 구체적 갈등·직장 실패·받은 피드백은 Needs confirmation.

20분 리허설 체크리스트

[ ] 30초·90초 소개를 각각 시간 안에 말한다.
[ ] 30,513 / 23,261 / 21,087 / 2,174 / 9,426 / 32,687 / 4,000 / 17,087 / 5,196을 의미와 함께 말한다.
[ ] NULL과 소스 부재를 사실, 정책, 운영 보완으로 나눈다.
[ ] business commit과 ops metadata 사이의 seam을 먼저 인정한다.
[ ] 규모·동시성 질문에서 현재 단일 writer 가정을 숨기지 않는다.
[ ] 모든 성과 수치에 대상과 기간을 붙인다.
[ ] 갈등·실패·피드백 공백은 실제 경험으로 채우기 전 사용하지 않는다.
[ ] 역질문은 면접 중 이미 답한 항목을 빼고 3개만 고른다.

출처 노트

공식 JD: https://career.rememberapp.co.kr/job/posting/319051
팀 조사 산출물: .omo/teams/team-4eac0841/artifacts/01-role-company.md, 02-assignment-defense.md, 03-candidate-story.md, 05-behavioral-panel.md
과제 장기 기록: ai/repo-notes/remember-data-engineer-assignment-claude.md, ai/worklog/2026/2026-W30.md
지원자 근거: ai/wiki/people/, ai/wiki/projects/, ai/wiki/academic/, ai/sources/career/
제출 패키지 근거: career/클로드이력서/리멤버앤컴퍼니-data-engineer/과제/

이 문서는 공개 회사 자료와 로컬 검증 기록을 바탕으로 만든 면접용 요약이다. 리멤버 내부 스택, 데이터 규모, 팀 구조와 평가 기준은 공개 자료만으로 확정하지 않았다.

키워드 메모 — ① 기초 약어

본문에서 청록색 점선이 있는 단어를 누르면 해당 메모로 이동한다. 풀네임을 외우기보다 쉬운 설명으로 먼저 뜻을 잡고, 전문가 설명으로 면접에서 필요한 경계를 확인한다.

DB / SQL · Database / Structured Query Language

쉽게 DB는 데이터를 정리해 보관하는 공간이고, SQL은 그 데이터에 무엇을 찾고 바꿀지 요청하는 언어다. 전문가 설명 Database는 구조화된 데이터를 저장·조회·변경하는 시스템이다. SQL은 관계형 데이터베이스의 정의·조회·변경을 표현하며, 실행계획과 인덱스에 따라 같은 질의도 비용이 달라진다. 이 문서에서 기억할 것 DB 오류나 성능 문제는 서버 크기만 보지 않고 쿼리, 인덱스, 연결 수, 쓰기 순서를 함께 확인한다.

API / HTTP · Application Programming Interface / Hypertext Transfer Protocol

쉽게 API는 프로그램끼리 정해진 방식으로 부탁하는 창구이고, HTTP는 그 부탁을 웹에서 주고받는 규칙이다. 전문가 설명 API는 요청·응답의 입력, 출력, 오류 계약을 정의한다. HTTP는 method, status code, header, body로 그 계약을 전달하며 429처럼 호출자가 취할 행동까지 상태 코드로 표현할 수 있다. 이 문서에서 기억할 것 HTTP Broker API는 여러 수집기의 DB 쓰기 요청을 한 창구로 모아 연결 수와 대기량을 통제했다.

CSV / NULL · Comma-Separated Values / 값 없음

쉽게 CSV는 표를 텍스트 파일로 저장하는 형식이고, NULL은 값이 0이나 빈 문자열인 것이 아니라 값이 없다는 표시다. 전문가 설명 CSV는 구분자·인용부호·인코딩 규칙에 따라 파싱 결과가 달라질 수 있다. NULL은 unknown 또는 not applicable을 나타낼 수 있어 비교와 집계에서 별도 규칙이 필요하다. 이 문서에서 기억할 것 NULL을 임의로 빈 값이나 삭제로 해석하지 않고 원천 사실과 적용 정책을 분리한다.

ETL / DML · Extract, Transform, Load / Data Manipulation Language

쉽게 ETL은 데이터를 가져와 정리한 뒤 저장하는 흐름이고, DML은 DB의 행을 넣고 바꾸고 지우는 명령이다. 전문가 설명 ETL은 extract·transform·load 단계의 데이터 이동을 뜻한다. DML은 INSERT, UPDATE, DELETE, MERGE처럼 데이터 상태를 변경하는 SQL 범주다. 이 문서에서 기억할 것 재처리를 위해 원본을 먼저 보존하고, 업무 데이터 변경과 실행 기록을 구분한다.

CPU / I/O · Central Processing Unit / Input and Output

쉽게 CPU는 계산을 하고, I/O는 디스크나 네트워크에서 데이터를 읽고 쓰는 일이다. 전문가 설명 데이터 작업의 병목은 계산, 메모리, 디스크, 네트워크 중 어디에서 기다리는지에 따라 해법이 달라진다. HDD와 M.2는 저장장치 특성이 달라 같은 DB 설정도 결과가 다를 수 있다. 이 문서에서 기억할 것 성능 문제는 CPU 사용률 하나로 결론내리지 않고 실행계획과 디스크 쓰기, 처리 시간대를 함께 본다.

E2E / CLI · End-to-End / Command-Line Interface

쉽게 E2E는 처음 입력부터 마지막 결과까지 전 과정을 확인하는 테스트이고, CLI는 명령어로 프로그램을 실행하는 화면이다. 전문가 설명 End-to-End test는 실제 실행 경로와 통합 지점을 검증한다. CLI는 사람이 명령행에서 쓰는 진입점이며, 운영 스케줄러가 사용하는 경로와 다르면 별도 검증이 필요하다. 이 문서에서 기억할 것 테스트가 통과했다는 말보다 실제 운영 경로와 깨끗한 압축 해제 환경에서 끝까지 실행됐는지를 확인한다.

STAR · Situation, Task, Action, Result

쉽게 경험을 상황, 맡은 일, 실제 행동, 결과의 네 단계로 나눠 말하는 행동면접 답변 틀이다. 전문가 설명 행동면접은 과거 행동으로 미래 행동을 예측한다. STAR는 상황과 과제를 짧게 깔고 본인의 행동과 측정 가능한 결과에 시간을 쓰게 만들어, 팀 성과와 본인 기여를 구분해 듣고 싶은 면접관의 질문 구조와 맞는다. 이 문서에서 기억할 것 상황 1문장 - 선택 2문장 - 검증 1문장 - 한계 1문장 압축 틀은 STAR를 이 문서 답변에 맞게 줄인 것이다.

Near-miss · 사고 직전에 발견한 결함

쉽게 실제 사고로 이어지기 전에 미리 발견해서 고친 문제를 말한다. 전문가 설명 안전공학에서 온 말로, 사고는 아니지만 사고가 될 뻔한 사건을 뜻한다. 소프트웨어에서는 출고 전 리뷰나 검증에서 잡힌 결함이 여기에 해당하고, 원인 분석과 재발 방지 대상은 실제 장애와 동일하게 다룬다. 이 문서에서 기억할 것 제출 과제의 실패 답변은 실제 손실이 아니라 사전 발견 near-miss라는 경계를 먼저 밝히고 시작한다.

키워드 메모 — ② 식별과 데이터 품질

CVE / OSV · Common Vulnerabilities and Exposures / Open Source Vulnerabilities

쉽게 공개된 소프트웨어 취약점을 여러 도구가 같은 대상으로 알아볼 수 있게 붙인 번호와 데이터 형식이다. 전문가 설명 CVE는 공개 취약점의 공통 식별자이고, OSV는 패키지 생태계와 영향 버전을 기계가 읽기 쉽게 표현하는 공개 스키마·데이터베이스다. 서로 다른 출처를 연결할 때 식별자와 버전 범위를 함께 검증해야 한다. 이 문서에서 기억할 것 제 업무에서는 제품명·버전·취약점 식별자를 연결하고 원문과 결과를 대조했다.

MDM · Master Data Management

쉽게 여러 시스템에 흩어진 사람·회사 같은 핵심 정보를 하나의 믿을 만한 기준으로 관리하는 방식이다. 전문가 설명 MDM은 master entity의 식별, 매핑, 대표값 선택, 변경 이력, 품질, 소유권을 함께 관리한다. 단순 중복 제거가 아니라 어떤 근거로 합쳤고 누가 고쳤는지까지 추적해야 한다. 이 문서에서 기억할 것 문자열이 비슷하다는 이유만으로 합치지 않고 출처·시간·식별 근거와 되돌림 경계를 둔다.

Golden Record · 단일 기준 레코드

쉽게 여러 곳에서 온 정보 중 현재 가장 믿을 만한 값을 모아 만든 대표 레코드다. 전문가 설명 Golden record는 entity resolution 뒤에 survivorship rule을 적용한 기준 표현이다. 원천을 덮어쓰는 결과가 아니라 선택된 값과 출처, 규칙 버전, 수동 보정 이력을 함께 가져야 한다. 이 문서에서 기억할 것 ‘최종값’만 남기지 않고 그 값이 어느 원천에서 왜 선택됐는지를 남긴다.

False Merge / False Split · 잘못 합침 / 잘못 나눔

쉽게 다른 사람을 같은 사람으로 합친 오류가 false merge이고, 같은 사람을 둘로 나눈 오류가 false split이다. 전문가 설명 두 오류는 비용이 다르므로 하나의 accuracy만으로 평가하기 어렵다. 자동 연결 임계치, 수동 검토 구간, 차단 규칙을 업무 위험에 맞춰 나눠야 한다. 이 문서에서 기억할 것 개인정보가 섞일 수 있는 사람 데이터에서는 잘못 합치는 오류를 더 보수적으로 막아야 할 수 있다.

Provenance / Survivorship · 출처 계보 / 대표값 선택 규칙

쉽게 provenance는 값이 어디에서 왔는지이고, survivorship은 여러 값 중 무엇을 대표값으로 남길지 정하는 규칙이다. 전문가 설명 Provenance는 source, ingest time, transform, rule version을 추적한다. Survivorship은 source priority, recency, completeness, human override를 이용해 속성별 승자를 정한다. 이 문서에서 기억할 것 연결 결과와 대표값 선택을 분리하고, 잘못된 규칙을 바꾸면 다시 계산할 수 있게 한다.

RAW / STG · Raw Data / Staging Data

쉽게 RAW는 받은 그대로의 원본이고, STG는 비교하고 검증하기 좋게 정리한 중간 데이터다. 전문가 설명 RAW는 재현과 감사의 기준이므로 가능한 한 불변으로 보존한다. STG는 타입 변환, 표준화, 중복 판정 같은 처리 결과를 담고 실행 회차와 연결돼야 한다. 이 문서에서 기억할 것 결과가 잘못됐을 때 외부에서 다시 받지 않고 RAW에서 재처리할 수 있어야 한다.

DQ · Data Quality

쉽게 데이터가 빠지거나, 겹치거나, 늦거나, 형식이 틀리지 않았는지 확인하는 일이다. 전문가 설명 Data Quality는 completeness, uniqueness, validity, consistency, freshness, reconciliation을 규칙과 지표로 관리한다. 오류마다 중단·경고·정보 수준을 구분해야 한다. 이 문서에서 기억할 것 마스터를 오염시키는 키 오류는 막고, 정답이 불명확한 이상은 경고와 판정 대상으로 분리한다.

Reconciliation · 원본과 결과의 대조

쉽게 데이터를 옮기거나 다시 처리한 뒤 원본과 결과가 정말 같은지 다시 맞춰 보는 절차다. 전문가 설명 Reconciliation은 row count만 보지 않고 key coverage, aggregate, checksum, 핵심 속성, 누락·중복을 비교한다. 분리 저장소의 실행 상태가 어긋났을 때 복구 판단에도 사용한다. 이 문서에서 기억할 것 ‘작업 성공’ 로그만 믿지 않고 실제 데이터 결과를 원본과 대조한다.

Collation / Checksum · 문자열 비교 규칙 / 내용 검증값

쉽게 collation은 대소문자와 언어를 어떻게 비교할지 정한 규칙이고, checksum은 내용이 같은지 빠르게 확인하는 요약값이다. 전문가 설명 Collation 차이는 조인 결과와 인덱스 사용 여부를 바꿀 수 있다. Checksum은 변경 탐지에 유용하지만 직렬화, NULL, 컬럼 순서 규칙이 같을 때만 비교할 수 있다. 이 문서에서 기억할 것 문자열 비교와 hash는 편리하지만 규칙이 다르면 같은 데이터를 다르다고 판단할 수 있다.

Quarantine · 격리 보관

쉽게 문제가 있는 데이터를 버리지 않고, 최종 결과에서만 빼서 따로 모아 두는 방식이다. 전문가 설명 격리 테이블은 어떤 행이 어떤 규칙에 왜 걸렸는지 규칙 이름·심각도·원문과 함께 남긴다. 삭제와 달리 원인 조사와 재처리가 가능하고, ERROR(반영 제외)와 WARN(반영하되 확인 필요)처럼 심각도별 처리를 나눌 수 있다. 이 문서에서 기억할 것 과제의 ops_quarantine은 키를 쓸 수 없어 제외한 행과, 반영은 했지만 사람이 봐야 하는 행을 함께 기록한다.

키워드 메모 — ③ 파이프라인과 재처리

Airflow / DAG · Apache Airflow / Directed Acyclic Graph

쉽게 Airflow는 작업 순서와 시간을 관리하는 도구이고, DAG는 어떤 작업 다음에 무엇을 실행할지 그린 흐름도다. 전문가 설명 Airflow는 scheduler와 executor를 통해 task instance를 실행한다. DAG는 순환이 없는 의존성 그래프이며 데이터 자체보다 실행 순서, 재시도, 상태, backfill을 조정한다. 이 문서에서 기억할 것 큰 데이터는 태스크 사이에 직접 넘기지 않고 경로와 회차 같은 작은 정보만 전달한다.

Idempotency · 멱등성

쉽게 같은 작업을 다시 실행해도 데이터가 두 번 들어가거나 결과가 달라지지 않는 성질이다. 전문가 설명 멱등성은 stable key, upsert, immutable input, transaction boundary를 이용해 재시도가 같은 상태로 수렴하게 만든다. 단순히 ‘중복이 우연히 없었다’는 뜻은 아니다. 이 문서에서 기억할 것 실패 후 재실행과 backfill을 안전하게 하려면 먼저 어떤 키와 범위를 같은 작업으로 볼지 정한다.

Transaction · 트랜잭션

쉽게 여러 변경을 하나의 묶음으로 처리해 전부 성공하거나 전부 취소되게 하는 단위다. 전문가 설명 Transaction은 atomicity, consistency, isolation, durability를 경계 안에서 보장한다. 서로 다른 저장소를 쓰면 하나의 DB 트랜잭션만으로 전체 exactly-once를 만들 수 없다. 이 문서에서 기억할 것 업무 데이터와 실행 기록이 같은 저장소인지 다른 저장소인지에 따라 실패 복구 방법이 달라진다.

Backfill / Data Interval · 과거 재처리 / 처리 대상 시간 구간

쉽게 backfill은 빠졌거나 바뀐 과거 데이터를 다시 처리하는 일이고, data interval은 이번 실행이 맡은 시간 범위다. 전문가 설명 Backfill은 현재 시각이 아니라 논리적 데이터 구간을 기준으로 실행해야 재현 가능하다. 동일 구간 동시 실행, 입력 변경, 결과 공개 시점을 함께 통제해야 한다. 이 문서에서 기억할 것 같은 연도 재처리는 회차별 snapshot과 run_id로 격리해야 한다.

CDC / Binlog · Change Data Capture / Binary Log

쉽게 CDC는 원본 DB에서 바뀐 내용만 따라가는 방식이고, binlog는 MySQL이 변경 내용을 순서대로 남기는 기록이다. 전문가 설명 CDC는 insert, update, delete 이벤트와 순서를 소비자에게 전달한다. Binlog 기반 CDC는 위치나 GTID, schema change, 재시작 지점을 관리해야 한다. 이 문서에서 기억할 것 제 경험은 약 1시간 단위 binlog 파일을 전달한 배치형 CDC이며 실시간 Kafka 운영 경험은 아니다.

Full Load · 전체 적재

쉽게 변경분만 받기 전에 기존 데이터를 처음부터 한 번 모두 옮기는 작업이다. 전문가 설명 Full Load는 snapshot 시점, 분할 키, 병렬도, 원본 DB 부하, 타입 변환, 검증을 관리한다. 이후 CDC와 연결할 때 snapshot 중 발생한 변경의 누락·중복을 막아야 한다. 이 문서에서 기억할 것 전체 적재와 CDC는 별도 작업이 아니라 정확한 기준 시점에서 이어져야 한다.

Upsert · Update or Insert

쉽게 같은 키가 있으면 고치고 없으면 새로 넣는 한 가지 저장 방식이다. 전문가 설명 Upsert는 unique key와 충돌 정책을 이용해 재시도를 멱등하게 만들 수 있다. 다만 잘못된 키를 쓰면 정상 레코드를 덮어쓸 수 있으므로 식별 규칙이 먼저다. 이 문서에서 기억할 것 중복 방지만 볼 것이 아니라 어떤 키를 같은 요청으로 판단하는지 설명해야 한다.

Exactly-once / Checkpoint · 정확히 한 번 처리 / 처리 위치 저장점

쉽게 exactly-once는 결과가 한 번만 반영된 것처럼 보이게 하는 성질이고, checkpoint는 어디까지 처리했는지 적어 둔 위치다. 전문가 설명 분산 시스템의 exactly-once는 범위가 제한적이다. 재처리 가능한 입력, checkpoint, idempotent sink, transaction 또는 deduplication이 함께 있어야 end-to-end 결과를 통제할 수 있다. 이 문서에서 기억할 것 업무 데이터는 한 번 반영된 것처럼 만들었지만 실행 기록까지 완전히 한 번이라고 과장하지 않는다.

Schema / Data Contract · 데이터 구조 / 데이터 계약

쉽게 schema는 컬럼과 타입의 모양이고, data contract는 생산자와 사용자가 그 데이터를 어떻게 주고받을지 정한 약속이다. 전문가 설명 Data contract는 schema뿐 아니라 의미, owner, SLA, 품질, 호환성, 변경 절차를 포함한다. additive change와 breaking change를 구분하고 consumer test로 검증한다. 이 문서에서 기억할 것 모르는 변경을 조용히 통과시키지 않고 허용된 변경과 중단할 변경을 미리 정한다.

XCom · Airflow cross-communication

쉽게 Airflow에서 앞 태스크가 뒤 태스크에게 작은 쪽지를 남기는 저장소다.

전문가 설명 XCom은 Airflow 메타데이터 DB에 key-value로 저장되는 태스크 간 전달 채널이다. 메타데이터 DB를 거치기 때문에 대용량 데이터를 넣으면 스케줄러와 DB가 함께 느려지고, 직렬화 가능한 작은 값만 넣는 것이 원칙이다. 이 문서에서 기억할 것 과제에서는 XCom에 연도, 파일 경로, 정책, 처리 건수 같은 작은 정보만 넘기고 데이터 본문은 DuckDB에 뒀다.

Outbox / Operation Marker · 전송 보류함 / 작업 표식

쉽게 두 저장소를 완전히 한 번에 바꿀 수 없을 때, ‘이 작업을 어디까지 했다’는 표식을 함께 남겨 나중에 맞춰 볼 수 있게 하는 방법이다. 전문가 설명 Outbox 패턴은 업무 데이터와 같은 트랜잭션 안에 보낼 메시지(또는 상태 변경 기록)를 먼저 커밋하고, 별도 프로세스가 그 기록을 읽어 두 번째 저장소에 반영한다. Operation marker는 재시작 시 미완료 작업을 식별해 복구하는 기준점이 된다. 이 문서에서 기억할 것 업무 데이터와 실행 기록 저장소가 분리되면 marker나 outbox를 남기고, 오래된 RUNNING 상태를 실제 데이터와 대조해 복구한다고 답한다.

Lease / Publish Pointer · 실행 임차권 / 공개 지점 포인터

쉽게 lease는 ‘지금은 나만 이 작업을 한다’는 기한이 있는 자물쇠이고, publish pointer는 ‘사용자에게 보여줄 완성본은 이것’이라고 가리키는 화살표다. 전문가 설명 Lease는 유효기간이 있어 잡은 쪽이 죽어도 기한이 지나면 다른 실행이 이어받을 수 있다는 점에서 일반 락과 다르다. Publish pointer는 결과를 회차별 불변 스냅샷으로 만들어 두고 검증이 끝난 스냅샷으로 포인터만 원자적으로 바꾸는 공개 방식이다. 이 문서에서 기억할 것 동시 backfill을 허용하려면 락 하나가 아니라 run_id 격리, lease, publish pointer가 함께 필요하다고 답한다.

Dual-read · 이중 읽기 검증

쉽게 옛 방식과 새 방식으로 같은 데이터를 두 번 읽어서 결과가 같은지 비교한 뒤에 새 방식으로 갈아타는 방법이다. 전문가 설명 파서·스키마·저장소를 바꿀 때 일정 기간 두 경로를 병행 실행하고 결과 차이를 기록한다. 차이가 0이거나 설명 가능할 때만 전환하므로, breaking change를 운영 데이터로 검증하는 안전망이 된다. 이 문서에서 기억할 것 스키마 breaking change는 dual-read와 과거 기간 재계산으로 차이를 확인한 뒤 전환한다고 답한다.

Fail Closed · 이상 시 차단

쉽게 확실하지 않으면 일단 멈추는 동작 방식이다. 반대말은 이상해도 일단 통과시키는 fail open이다. 전문가 설명 입력 계약(헤더, 스키마, 인코딩)이 어긋났을 때 추측으로 계속 진행하면 오염이 하류로 퍼진다. Fail closed는 오염 확산 비용이 중단 비용보다 클 때 선택하고, 대신 명확한 오류 메시지와 재개 절차를 함께 둬야 한다. 이 문서에서 기억할 것 과제는 헤더가 다르면 fail closed하고 RAW를 보존해, 규칙이 확정된 뒤 다시 처리할 수 있게 했다.

키워드 메모 — ④ 운영 기준과 처리 엔진

Backpressure / Queue / Connection Pool · 유입 제어 / 대기열 / DB 연결 묶음

쉽게 일이 들어오는 속도가 처리 속도보다 빠를 때 잠시 줄을 세우고, 넘치면 더 받지 않도록 하는 장치다. 전문가 설명 Bounded queue는 메모리 사용을 제한하고, connection pool은 동시 DB 연결 수를 제한한다. Backpressure는 지연을 숨기지 않고 거절이나 속도 조절 신호를 upstream에 전달한다. 이 문서에서 기억할 것 대기열이 차면 429 + Retry-After를 반환해 호출자가 나중에 다시 요청하게 했다.

SLA / Freshness / Latency · Service Level Agreement / 최신성 / 지연시간

쉽게 SLA는 어느 수준까지 제공하겠다는 약속이고, freshness는 데이터가 얼마나 최신인지, latency는 처리에 얼마나 걸렸는지다. 전문가 설명 Freshness는 원천 이벤트 시각과 사용 가능 시각의 차이이고, latency는 각 처리 구간의 소요 시간이다. SLA는 측정 방법, 허용 범위, 위반 대응까지 합의해야 한다. 이 문서에서 기억할 것 파이프라인 성공 여부와 파일이 제시간에 도착했는지는 다른 지표로 본다.

Canary / Go-No-Go / Rollback · 일부 시험 / 진행 판단 / 되돌리기

쉽게 canary는 작은 범위로 먼저 시험하고, go/no-go는 계속할지 멈출지 판단하며, rollback은 문제가 생기면 이전 상태로 돌아가는 절차다. 전문가 설명 안전한 이관은 사전 기준값, 제한된 대상, 관찰 시간, 중단 임계치, 복구 경로를 배포 전에 정한다. Rollback 가능 여부는 schema와 양방향 변경 여부에 따라 달라진다. 이 문서에서 기억할 것 이관 전에 어떤 차이면 멈추고 무엇을 기준으로 되돌릴지 합의한다.

OLTP / OLAP · Online Transaction Processing / Online Analytical Processing

쉽게 OLTP는 서비스의 짧은 저장·조회에, OLAP는 많은 데이터를 읽고 집계하는 분석에 맞춘 방식이다. 전문가 설명 OLTP는 낮은 지연의 작은 트랜잭션과 동시 쓰기를 중시한다. OLAP는 대량 스캔, 컬럼 기반 처리, 집계 성능을 중시하며 데이터 복제와 최신성 비용이 따른다. 이 문서에서 기억할 것 분석 조회가 운영 DB를 방해하고 분리 비용보다 이익이 커질 때 OLAP 계층을 검토한다.

DuckDB · 단일 프로세스 분석용 데이터베이스 제품명

쉽게 별도 서버 없이 파일이나 메모리의 데이터를 빠르게 분석하는 작은 분석 DB다. 전문가 설명 DuckDB는 in-process columnar OLAP engine이다. 벡터화 실행과 파일 직접 조회에 강하지만, 하나의 파일에 여러 writer가 동시에 쓰는 중앙 서비스용 DB와는 목적이 다르다. 이 문서에서 기억할 것 작은 과제에서는 추적이 쉽지만 동시 쓰기와 대규모 분산 처리가 필요하면 다른 저장소를 검토한다.

Apache Spark · 분산 데이터 처리 엔진 제품명

쉽게 한 대에서 처리하기 어려운 큰 데이터를 여러 컴퓨터에 나눠 계산하는 도구다. 전문가 설명 Spark는 driver가 작업을 계획하고 executor가 partition 단위로 처리한다. shuffle, skew, serialization, retry 비용이 있어 단일 노드 한계를 측정한 뒤 선택해야 한다. 이 문서에서 기억할 것 프로덕션 운영 경험은 없으며 분산 비용이 정당화되는 조건을 학습하고 있다.

Apache Kafka · 분산 이벤트 로그 플랫폼 제품명

쉽게 데이터 변경이나 이벤트를 순서 있는 줄에 보관해 여러 소비자가 각자 읽게 하는 시스템이다. 전문가 설명 Kafka는 topic을 partition으로 나누고 offset으로 소비 위치를 관리한다. 순서 보장은 partition 안에서만 성립하며 consumer group, retention, replay를 함께 설계한다. 이 문서에서 기억할 것 프로덕션 Kafka 경험은 없고, 제 CDC 경험은 약 1시간 단위 파일 동기화다.

Apache Flink · 상태 기반 스트림 처리 엔진 제품명

쉽게 계속 들어오는 이벤트를 멈추지 않고 계산하는 분산 처리 도구다. 전문가 설명 Flink는 event time, watermark, keyed state, checkpoint를 이용해 stateful stream processing을 수행한다. 정확성은 source와 sink가 checkpoint에 어떻게 참여하는지에 달려 있다. 이 문서에서 기억할 것 Flink도 프로덕션 경험으로 말하지 않고 개념과 선택 기준만 설명한다.

Backoff · 재시도 간격 늘리기

쉽게 실패한 요청을 바로 다시 보내지 않고, 잠깐 기다렸다가, 또 실패하면 더 길게 기다렸다가 다시 보내는 방식이다. 전문가 설명 Exponential backoff는 재시도 간격을 지수적으로 늘리고, 여러 클라이언트가 같은 시각에 몰리지 않게 무작위 지연(jitter)을 더한다. 재시도 횟수 상한과 함께 써야 장애 중인 대상에 부하를 더하는 retry storm을 막는다. 이 문서에서 기억할 것 크롤러 스케줄링에서 pool과 backoff를 함께 조정해 DB와 클러스터가 감당할 수 있는 속도로 요청을 늦췄다.

Primary / Replica · 주 DB / 복제 DB

쉽게 primary는 쓰기를 받는 원본 DB이고, replica는 그 변경을 따라가며 복사해 두는 DB다. 전문가 설명 Replica는 읽기 부하 분산과 장애 시 승격(failover)에 쓰인다. 복제는 비동기가 흔해 primary와 replica 사이에 복제 지연이 있을 수 있고, 방금 쓴 데이터를 replica에서 못 읽는 경우를 설계에서 고려해야 한다. 이 문서에서 기억할 것 IDC 전환에서 수집·배포·운영 DB를 분리하고 primary/replica, 백업, 모니터링을 다시 구성했다.

Micro-batch · 잘게 나눈 주기 배치

쉽게 데이터를 실시간으로 한 건씩 처리하는 대신, 몇 초에서 몇 분 단위로 조금씩 모아 자주 처리하는 방식이다. 전문가 설명 이벤트 단위 스트리밍보다 구현과 운영이 단순하면서 지연을 분 단위 이하로 낮출 수 있다. 허용 지연이 초 단위가 아니라면 스트리밍 인프라 없이 기존 배치 도구로 충분한 경우가 많다. 이 문서에서 기억할 것 허용 지연이 분 단위면 Kafka 없이 micro-batch나 주기적 metric 수집이 더 단순할 수 있다고 답한다.

Arrow / Polars · 컬럼 메모리 포맷 / 고속 DataFrame 라이브러리

쉽게 Arrow는 여러 도구가 데이터를 복사 없이 주고받게 하는 공통 메모리 형식이고, Polars는 그 형식 위에서 빠르게 표 데이터를 처리하는 Python 라이브러리다. 전문가 설명 Apache Arrow는 컬럼 지향 in-memory 포맷으로 엔진 간 zero-copy 교환을 목표로 한다. Polars는 Rust로 구현된 DataFrame 엔진으로 lazy 실행과 스트리밍 모드를 지원해, pandas가 메모리에 다 올리는 데이터를 청크로 나눠 처리할 수 있다. 이 문서에서 기억할 것 수백만 행 확장 답변에서 Python 전체 적재 대신 DuckDB SQL·Arrow·Polars 같은 컬럼 지향 처리로 바꾸겠다고 말한다.

Data Warehouse · 분석 전용 중앙 저장소

쉽게 여러 시스템의 데이터를 분석하기 좋게 한곳에 모아 둔 큰 창고 DB다.

전문가 설명 운영 DB와 분리된 분석 전용 저장소로, 대량 스캔·집계에 맞는 컬럼 지향 구조와 동시 사용자 관리를 제공한다. 여러 작업이 동시에 쓰고 여러 팀이 읽는 중앙 지점이라는 점이 단일 파일 엔진과 다르다. 이 문서에서 기억할 것 여러 writer와 소비자가 필요해지는 시점이 단일 DuckDB 파일에서 중앙 DB나 warehouse로 옮기는 전환 조건이다.

키워드 메모 — ⑤ 리멤버 공개 아키텍처

Debezium / Kafka Connect / MSK · CDC 커넥터 / 커넥터 실행 틀 / Managed Streaming for Apache Kafka

쉽게 Debezium이 DB 변경을 읽고, Kafka Connect가 그 연결 작업을 실행하며, MSK가 AWS에서 Kafka를 관리해 주는 조합이다. 전문가 설명 Debezium source connector는 DB log를 change event로 변환한다. Kafka Connect는 task, offset, retry를 관리하고, Amazon MSK는 Kafka broker 운영을 관리형으로 제공한다. 이 문서에서 기억할 것 공개 자료에서 확인한 리멤버 흐름을 이해하기 위한 학습 내용이며 제 운영 경험은 아니다.

S3 Tables / Iceberg · Amazon Simple Storage Service Tables / Apache Iceberg

쉽게 큰 분석 데이터를 파일로 싸게 보관하면서도 DB 테이블처럼 버전과 구조를 관리하는 방식이다. 전문가 설명 S3 Tables는 S3의 관리형 table bucket이고 Iceberg table format을 사용한다. Iceberg는 snapshot, metadata, schema evolution, partition evolution을 통해 파일 집합을 테이블처럼 관리한다. 이 문서에서 기억할 것 저장 공간만 보는 것이 아니라 metadata와 maintenance, 조회 엔진 연결까지 하나의 운영 범위로 본다.

Compaction / Snapshot / Orphan File · 파일 합치기 / 시점 상태 / 참조되지 않는 파일

쉽게 작은 파일은 합치고, 과거 상태는 snapshot으로 남기며, 아무 테이블에서도 쓰지 않는 파일은 안전하게 정리하는 작업이다. 전문가 설명 Compaction은 small file을 재작성해 조회 비용을 낮춘다. Snapshot retention과 orphan file removal은 복구 기간과 저장 비용을 함께 고려해야 하며 순서를 잘못 잡으면 필요한 파일을 지울 수 있다. 이 문서에서 기억할 것 maintenance가 켜졌다는 설정만 믿지 않고 파일 수와 snapshot 나이로 실제 동작을 확인한다.

PyIceberg · Apache Iceberg의 Python 라이브러리 제품명

쉽게 Python으로 Iceberg 테이블의 파일, snapshot, 구조 정보를 읽고 관리하는 도구다. 전문가 설명 PyIceberg는 catalog와 metadata table을 통해 snapshot lineage, manifest, data file 통계를 조회하고 commit을 수행할 수 있다. 엔진 쿼리 밖에서 운영 상태를 관측하는 데 유용하다. 이 문서에서 기억할 것 파일 개수와 크기, 최신 snapshot 시각을 읽어 compaction과 적재 상태를 확인한다.

Lake Formation / IAM · 데이터 레이크 권한 관리 / Identity and Access Management

쉽게 IAM은 AWS 자원에 누가 접근할지 정하고, Lake Formation은 데이터의 테이블·컬럼·행 수준까지 더 세밀하게 통제한다. 전문가 설명 IAM은 principal의 API 권한을 제어한다. Lake Formation은 catalog resource와 data location을 연결해 table, column, row filter 권한과 감사를 관리한다. 이 문서에서 기억할 것 저장소 접근 권한과 실제 데이터 열람 권한을 같은 것으로 보지 않는다.

AWS Glue / PySpark · 관리형 데이터 통합 서비스 / Spark의 Python API

쉽게 Glue는 AWS가 실행 환경을 관리해 주는 데이터 작업 서비스이고, PySpark는 Python으로 Spark 작업을 작성하는 방법이다. 전문가 설명 AWS Glue job은 managed Spark runtime에서 JDBC 읽기, partitioning, type conversion, Iceberg write를 수행할 수 있다. 병렬도를 높일수록 원본 DB 부하와 작은 파일도 함께 늘 수 있다. 이 문서에서 기억할 것 Full Load에서는 속도만 높이지 않고 원본 DB 보호와 행 수·키·타입 검증을 함께 본다.

EKS / Kubernetes · Elastic Kubernetes Service / 컨테이너 오케스트레이션 플랫폼

쉽게 Kubernetes는 여러 서버에서 컨테이너를 배치하고 복구하는 시스템이고, EKS는 AWS가 그 제어 영역을 관리해 주는 서비스다. 전문가 설명 Kubernetes는 Pod를 node에 scheduling하고 request, limit, probe, rollout으로 수명주기를 관리한다. EKS는 managed control plane을 제공하지만 workload 용량과 장애 대응은 여전히 운영 범위다. 이 문서에서 기억할 것 제 경험은 Kubernetes worker와 자원 정책 운영이며 EKS 프로덕션 경험으로 바꾸어 말하지 않는다.

StarRocks / ClickHouse · 저지연 OLAP 데이터베이스 제품명

쉽게 많은 데이터를 빠르게 집계하고 대시보드나 분석 API에 결과를 제공하는 분석 DB다. 전문가 설명 StarRocks와 ClickHouse는 컬럼 기반 MPP OLAP 계열이다. StarRocks는 Iceberg catalog, vectorized execution, materialized view를 이용한 저지연 서빙 구성을 지원한다. 이 문서에서 기억할 것 리멤버 공개 자료의 서빙 계층을 이해한 내용이며 직접 운영 경험을 주장하지 않는다.

Materialized View / P95 / P99 · 미리 계산한 결과 / 95·99 백분위 지연

쉽게 materialized view는 자주 쓰는 계산 결과를 미리 저장한 것이고, P95·P99는 느린 요청까지 포함해 대부분의 사용자가 얼마나 기다리는지 보는 수치다. 전문가 설명 Materialized view는 반복 집계 비용을 줄이지만 refresh 지연과 원본 일관성을 관리해야 한다. P95와 P99는 전체 요청 중 각각 95%, 99%가 그 시간 안에 끝났다는 percentile이다. 이 문서에서 기억할 것 평균만 보지 않고 느린 구간과 결과 최신성을 함께 봐야 실제 사용자 경험을 설명할 수 있다.

12. 이어서 읽을 리멤버 Data Engineering 스터디

외우기 위한 목록이 아니다. 공개 채용 공고와 기술 글에서 확인된 전체 흐름을 먼저 읽고, 면접 답변의 선택 이유를 자기 말로 바꾸는 데 쓴다.

시리즈 시작: 리멤버 공개 자료로 보는 Data Engineering
1. 식별·매핑·MDM: 다른 레코드를 같은 사람과 회사로 연결하기
2. Full Load·CDC: 초기 이관과 실시간 변경 사이의 누락·중복 막기
3. S3 Tables 운영: compaction·snapshot·orphan file을 함께 보는 이유
4. PyIceberg 관측: 파일과 스냅샷으로 레이크하우스 상태 읽기
5. Lake Formation 권한: IAM·테이블·컬럼·행 제어를 분리하기
6. Glue·PySpark Full Load: 운영 DB를 보호하며 수십억 행 옮기기
7. StarRocks·Iceberg 서빙: 운영 DB와 실시간 분석 질의를 분리하기
기존 스터디까지 포함한 전체 지도: 예상 질문 ↔ 스터디 연결 지도

새로 추가한 7편은 기존 스터디와 겹치지 않는 항목만 다룬다. Airflow, Spark, Kafka, 일반 Iceberg, 데이터 품질·계약·이관, MySQL, Kubernetes, 개인정보는 기존 글을 연결 지도에서 이어서 읽는다.