리멤버 Data Engineer 2차 면접 준비

_기준일: 2026-08-24_

연습 자료:

• CTO·AI/Data 실장 모의면접
• 당일용 1장 요약

지금 달라진 점

2차 면접에는 CTO와 AI/Data 실장이 참석한다고 전달받았다. 정확한 질문은 공개되지 않았고 면접 날짜·시간·형식도 아직 확인되지 않았다. 아래 내용은 패널 역할, 공고, 제출 자료, 1차 준비 기록, 리멤버의 공개 자료를 대조한 예상이다.

1차가 과제와 경력의 사실 여부를 확인하는 자리였다면, 2차에서는 같은 경험을 더 큰 질문으로 끌어올릴 가능성이 높다.

• 이 사람에게 중요한 데이터를 맡겨도 되는가.
• 기술 선택을 사업 목표, 고객 위험, 운영 비용과 연결할 수 있는가.
• AI가 쓰는 데이터의 오류 비용과 개인정보 경계를 알고 있는가.
• 모르는 기술과 실패를 숨기지 않고 학습 계획까지 말할 수 있는가.
• 빠르게 실행하면서도 되돌릴 수 있는 선을 그을 수 있는가.

리멤버는 공개 채용 페이지에서 Data-tech와 AI를 제품 방향으로 두고 있으며, 일하는 방식으로 고객 관점, 빠른 시도, 학습, 오너십, 솔직한 소통을 제시한다. 따라서 답변은 기술 이름보다 왜 이 판단을 했는지, 누가 영향을 받는지, 무엇으로 확인했고 어떻게 되돌리는지가 먼저 나와야 한다.

패널별로 보는 질문

CTO 예상 질문

1. 왜 지금 리멤버이며, 왜 Data Foundation인가요?

첫 문장은 이렇게 잡는다.

지난 5년 동안 서로 다르게 들어온 제품·버전·취약점 데이터를 같은 대상으로 식별하고, 잘못 연결된 원인을 규칙·스키마·재처리 구조까지 내려가 고쳤습니다. 리멤버에서는 이 문제가 사람·회사·기회를 연결하는 제품 신뢰와 직접 이어집니다. 제가 가장 오래 풀어 온 문제를 더 큰 사용자 데이터에서 깊게 맡고 싶어 지원했습니다.

뒤에는 실제 리멤버 사용자로서 명함·프로필·스카우트 제안을 경험한 사실과, 공고의 정교한 매핑·MDM·데이터 정합성을 연결한다. 회사 칭찬으로 끝내지 말고 입사 후 어떤 문제를 맡고 싶은지까지 말한다.

2. 본인이 내린 가장 중요한 기술 결정은 무엇인가요?

컴포넌트 식별자·테이블 재설계 사례를 우선 사용한다.

• 상황: 실행계획에서 약 130만 행을 훑는 구조였고, 문자열 비교 규칙과 식별자

정책이 함께 얽혀 있었다.

• 책임: 원인을 좁히고 변경 범위와 운영 위험을 설명해야 했다.
• 행동: 쿼리 하나만 손대지 않고 collation, 식별자 규칙, 테이블 구조를 함께

비교했다. 95개 쿼리의 실행계획을 확인하고 팀장·CTO 리뷰를 거쳐 변경했다.

• 결과: 예상 스캔 행이 약 130만에서 6,000으로 줄었다.
• 한계: 이 수치는 실행계획상 스캔 행이며 응답시간이나 CPU 감소율로 말하지 않는다.

CTO는 결과보다 다른 선택지는 무엇이었고 왜 버렸는가, 잘못되면 어떻게 되돌렸는가, 누가 승인했는가를 더 물을 수 있다.

3. 속도와 완성도가 충돌하면 어떻게 합니까?

범용 PC에서 수집 장애가 반복됐던 사례가 적합하다. 새 장비가 없던 동안에는 수집 시간을 분산해 월 10~20건의 이슈를 월 5건 미만으로 낮췄고, IDC 장비가 준비된 뒤 수집·배포·운영 DB를 분리했다. 답의 핵심은 즉시 완화, 근본 변경, 검증 후 전환을 나누는 것이다.

4. 입사 후 90일 안에 무엇을 하겠습니까?

• 30일: 핵심 개체·키·원천·소비자·개인정보 접근 경계를 익힌다.
• 60일: 한 원천 또는 한 품질 문제를 맡아 기준값, 중단선, 재처리 방법을 설명한다.
• 90일: 권한과 우선순위가 맞으면 작은 개선 하나를 배포하고 결과·한계·되돌림을

문서로 남긴다.

플랫폼을 다시 설계하겠다고 크게 약속하지 않는다. 팀의 판단 기준을 배우면서 작은 범위를 끝까지 소유하겠다는 답이 더 믿을 만하다.

5. Spark·Kafka 운영 경험이 없는데 어떻게 기여하겠습니까?

먼저 없다고 짧게 말한다. 이어서 Python·SQL·Airflow·Kubernetes·MySQL로 80개가 넘는 수집 작업, 재처리, 동시성, pool/backoff, 대규모 DB 운영을 맡은 경험을 설명한다. 학습 계획은 기술 강의 목록보다 실제 팀의 데이터량, 지연 목표, 장애 사례, 운영 대시보드를 먼저 이해하겠다고 말한다.

6. AI 도구를 어디까지 믿습니까?

사내 CI/CD 중앙 흐름에 AI PR 리뷰를 넣은 사례를 쓴다.

• 외부 모델 호출 전에 secret scan을 통과시켰다.
• 실행 도구 버전은 움직이는 main 대신 commit SHA로 고정했다.
• 변경 경로 매핑이 없으면 조용히 통과시키지 않고 실패시켰다.
• AI 지적은 요구사항, 테스트, 실제 실행 결과로 다시 확인했다.
• 최종 판단과 제출 책임은 본인에게 있다고 말한다.

과제에 AI를 썼는지 물으면 숨기지 않는다. 어느 파일이든 설계 이유를 설명하고 실행 결과로 방어할 수 있다는 쪽으로 답한다.

7. 의견 충돌, 실패, 받은 피드백을 말해 주세요.

의견 충돌은 2026-08-27 사용자 제공 재료로 채웠다(모의면접 5번): 엔진 쪽 판정 값을 데이터에 미리 넣어 달라는 요청과, 데이터가 책임질 수 있는 값만 받고 나머지는 애플리케이션 판정으로 나눈 기준. 구체 사건 1건의 시점·최종 결정권자는 아직 Needs confirmation이다.

아래 두 사례는 여전히 확인되지 않았다.

• 실제 손실과 내 책임, 복구, 이후 출고 조건 변화가 있는 실패 1건
• 누가 어떤 피드백을 줬고 내 행동이 어떻게 달라졌는지 보이는 사례 1건

면접 전에 실제 경험을 하나씩 적는다. 기억이 불분명하면 과제의 near-miss를 직장 실패는 아니다라고 밝히고 사용한다. 그럴듯한 갈등을 새로 만들지 않는다.

AI/Data 실장 예상 질문

1. 데이터 엔지니어가 AI 품질에 어떻게 기여할 수 있습니까?

모델 성능을 논하기 전에 같은 사람과 회사를 일관되게 식별하고, 어떤 원천과 규칙으로 만들어진 값인지 다시 찾을 수 있어야 합니다. 잘못 합친 레코드는 학습·추천·검색 전체에 오염을 퍼뜨리고, 같은 대상을 나눈 레코드는 신호를 희석합니다. 그래서 식별 결정의 근거와 버전, 품질 지표, 재처리 경로를 남기는 일이 AI 품질의 입력 조건이라고 봅니다.

직접 모델을 운영했다고 말하지 않는다. 본인의 강점은 AI가 믿고 사용할 수 있는 데이터의 식별·정합성·출처·재현성을 만드는 데 있다고 선을 긋는다.

2. 잘못 합치는 것과 같은 대상을 나누는 것 중 무엇이 더 위험합니까?

정답 하나를 고르기 전에 사용처를 묻는다.

• 자동 메시지·추천·외부 노출처럼 잘못된 연결의 피해가 크면 false merge를 더

강하게 막는다.

• 내부 분석처럼 일부 누락을 후속 보정할 수 있으면 false split 허용 폭이 달라질

수 있다.

• 정확 일치, 근거 점수, 사람 검토, 보류의 네 단계로 나눈다.
• precision·recall과 표본 검수, 현업 수정 이력으로 기준을 다시 조정한다.

3. 데이터 품질 문제에서 언제 멈추고 언제 경고만 남깁니까?

판단 기준은 세 가지로 답한다.

1. 잘못 반영됐을 때 고객·개인정보·후속 시스템에 미치는 피해
2. 재처리로 회복 가능한지와 원본이 남아 있는지
3. 정상 변동과 오류를 구분할 기준값이 있는지

키 중복, 필수 컬럼 파싱 실패, 원본 대비 건수 급감처럼 결과를 믿기 어려우면 중단한다. 체크섬 불일치처럼 사실은 남길 수 있으나 정답을 단정할 수 없으면 격리하거나 경고하고 사람 확인으로 넘긴다.

4. 정확도와 최신성이 충돌하면 무엇을 우선합니까?

사용처별 SLA를 먼저 확인한다. 모든 데이터를 같은 기준으로 처리하지 않는다. 의사결정 대시보드, 추천, 외부 노출, 정산처럼 오류 비용이 다른 소비자를 나누고, 확정 데이터와 잠정 데이터를 구분해 공개한다. 최신 데이터를 빠르게 보여주더라도 출처 시점, 품질 상태, 재처리 가능 여부를 함께 남긴다.

5. 과제를 실서비스 규모와 실시간 처리로 바꾸면 무엇이 달라집니까?

• 현재 DuckDB 단일 writer와 max_active_runs=1 가정을 먼저 인정한다.
• 원천 변경 로그, 기준점, 재처리 단위, 중복 제거 키를 먼저 정한다.
• Full Load와 CDC가 만나는 지점에서 누락·중복 검산을 둔다.
• 업무 반영과 실행 메타데이터가 다른 저장소라면 exactly-once라고 과장하지 않는다.
• 처리량보다 backlog, freshness, 오류율, 격리 건수, source-to-target reconciliation을

먼저 관측한다.

리멤버가 공개한 CDC 레이크 구조를 이해하고 있다는 점은 보여주되, Debezium·MSK· Glue·S3 Tables·StarRocks를 직접 운영했다고 말하지 않는다.

6. 개인정보가 포함된 데이터 파이프라인은 어떻게 다르다고 봅니까?

보안 메타데이터 경험을 개인정보 운영 경험으로 바꾸지 않는다. 수집 목적, 접근 주체, 보존·삭제, 마스킹, 재처리 산출물, 감사 로그, 만료 절차를 먼저 확인한다. AI 학습이나 검색용 복제본도 원본과 같은 접근·삭제 정책을 따라야 한다고 답한다.

7. AI/Data 조직과 어떻게 협업하겠습니까?

모델이나 분석 결과가 틀렸을 때 데이터 문제라는 말로 끝나지 않도록 입력 시점, 식별 규칙 버전, 결측·격리 상태, 재처리 이력을 함께 볼 수 있게 하겠다고 답한다. 지표 정의자는 AI/Data·제품 담당자와 합의하고, 데이터 엔지니어는 그 정의가 파이프라인에서 재현되는지와 변경 시 영향 범위를 책임지는 그림이 좋다.

준비할 이야기 6개

각 이야기는 60~90초로 말한다.

1. 결론 한 문장
2. 실제 상황과 내가 맡은 범위
3. 선택지와 판단 기준
4. 실행과 검증 결과
5. 한계와 다시 한다면 바꿀 점

면접 전에 반드시 채울 네 칸

아래는 현재 자료만으로 답을 확정하면 안 된다.

공식 직급과 Data Engineer·Data Part Lead 표기 차이도 한 문장으로 정리한다. 정확한 직함과 책임 범위는 본인 확인 전 임의로 확정하지 않는다.

위험한 답변

• 공개된 리멤버 스택을 본인의 운영 경험처럼 말하기
• 배치형 CDC를 실시간 스트리밍으로 설명하기
• AWS 경험을 RDS·S3·EFS까지 넓히기
• AI가 코드를 만들었다 또는 AI 없이도 다 할 수 있다로 책임을 피하기
• 도구 이름부터 길게 말하고 고객·사업 문제를 뒤에 붙이기
• 검증되지 않은 매출, 사용자, 비용 절감 효과를 만들기
• 공식 직급과 리딩 범위를 확인 없이 키우기

제출 자료의 AWS 태그 오기를 1차에서 정정하지 않았다면, 2차 초반에 20초로 먼저 정정한다. 1차에서 이미 바로잡았다면 같은 설명을 길게 반복하지 않는다.

역질문

CTO에게는 둘 중 하나를 고른다.

1. “리멤버가 Data-tech와 AI를 제품 성장의 축으로 두고 있는데, 앞으로 1년 동안

기술 조직이 반드시 풀어야 하는 데이터 문제는 무엇이며 이 역할이 어디까지 소유하길 기대하시나요?”

1. “빠른 실행과 데이터 신뢰가 충돌했을 때 CTO님이 멈추는 선은 무엇이고,

최근 그 판단이 필요했던 사례는 무엇이었나요?”

AI/Data 실장에게는 둘 중 하나를 고른다.

1. “사람·회사 매핑에서 false merge와 false split의 비용을 어떻게 나누고,

자동 판정과 사람 검토의 경계를 어떤 지표로 조정하시나요?”

1. “AI/Data 조직이 새 Data Engineer에게 첫 90일 안에 독립적으로 맡기고 싶은

원천이나 품질 문제가 있다면 무엇이며, 완료를 어떤 증거로 판단하시나요?”

면접 중 이미 답을 들은 질문은 빼고 두 개만 묻는다.

4시간 준비 순서

모의면접에서는 답변마다 다음 다섯 항목만 채점한다.

• 첫 10초 안에 결론이 나왔는가.
• 내가 맡은 범위가 분명한가.
• 선택지와 판단 기준이 있는가.
• 숫자의 대상과 기간이 붙었는가.
• 한계와 다음 행동이 있는가.

공개 자료에서 확인한 방향

• 리멤버 채용 페이지는 Data-tech와 AI를 제품

방향으로 설명하고, 고객 관점·빠른 시도·학습·오너십·솔직한 소통을 일하는 방식으로 제시한다.

• AWS 기술 블로그 1부는

수억 건의 명함 분석 환경에서 Incremental Update와 실시간·준실시간 분석을 목표로 Aurora MySQL, CDC, Glue, S3 Tables를 연결한 공개 사례를 설명한다.

• AWS 기술 블로그 2부는

compaction, snapshot, orphan file, 모니터링, StarRocks 도입처럼 운영 단계에서 생긴 선택과 비용을 다룬다.

이 공개 구조는 회사의 문제를 이해하기 위한 자료다. 내부 기준값, 현재 조직 구조, 면접 평가표, 본인의 운영 경험을 증명하는 자료로 사용하지 않는다.