# 리멤버 Data Engineer 2차 모의면접

_기준일: 2026-08-24 · 예상 참석자: CTO, AI/Data 실장_

함께 볼 문서: [2차 준비 가이드](2026-08-24-remember-second-interview-prep.md) ·
[당일용 1장 요약](../briefs/2026-08-24-remember-second-interview-onepager.md)

정확한 면접 질문·시간·진행 방식은 공개되지 않았다. 이 대본은 제출 이력서,
과제, 1차 준비 자료와 공개된 리멤버 자료를 바탕으로 만든 연습용 시나리오다.

## 연습 방법

1. 질문을 읽은 뒤 5초 안에 답을 시작한다.
2. 첫 문장에는 결론만 말한다.
3. 본 답변은 60~90초, 추가 질문은 30초 안에 끝낸다.
4. 답변을 녹음하고 문서 마지막의 채점표로 확인한다.
5. 아래 `Needs confirmation`은 실제 경험을 적기 전까지 면접 답변으로 쓰지 않는다.

## 0부: 자기소개 (면접 시작 직후)

2차는 CTO와 AI/Data 실장이 들어오므로, 자기소개는 경력 나열이 아니라 이후
질문에서 쓸 이야기의 목차 역할을 한다. 지원 동기는 여기서 길게 말하지 않고
1번 질문으로 넘긴다.

첫 문장 (고정):

> 여러 곳에서 다른 이름으로 들어오는 데이터를 결국 같은 대상인지 판단해 연결해
> 온 데이터 엔지니어입니다.

### 60초 (기본, 당일 1장과 동일)

> 여러 곳에서 다른 이름으로 들어오는 데이터를 결국 같은 대상인지 판단해 연결해
> 온 데이터 엔지니어입니다. 초기 멤버로 합류한 보안 데이터 회사에서 5년간
> 오픈소스 제품·버전·취약점과 12종 리눅스 배포판의 보안 정보를 수집하고
> 연결했습니다. 표기 차이로 같은 제품이 갈라지고 다른 제품이 합쳐지는 문제를
> 식별 규칙, 원본 보존, 변경 이력, 재처리 구조까지 내려가 고쳤고, 수십억 행
> MySQL과 80개가 넘는 수집 작업을 운영했습니다. 이제 이 경험을 사람·회사·
> 기회를 연결하는 리멤버의 데이터에 적용해, AI와 제품이 믿고 사용할 수 있는
> 식별·정합성 기반을 맡고 싶습니다.

### 30초 (시간을 짧게 주거나 이미 이력서를 읽은 경우)

> 서로 다른 이름으로 들어오는 데이터를 같은 대상으로 식별하고, 그 판단을
> 검증하고 되돌릴 수 있게 만들어 온 데이터 엔지니어입니다. 초기 멤버로 합류한
> 보안 데이터 회사에서 5년간 오픈소스 제품·버전·취약점 데이터를 맡아 수십억 행
> MySQL과 80개가 넘는 수집 작업을 운영했습니다. 같은 식별·정합성 문제를
> 사람·회사·기회를 연결하는 리멤버의 데이터에서 맡고 싶습니다.

### 90초 (편하게 말씀해 달라거나 시간이 있을 때)

60초 답변을 그대로 말한 뒤, 아래 한 단락만 덧붙인다. 세 가지를 모두 늘어놓지
말고 면접 흐름에 맞는 하나를 고른다.

> 구체적으로는 세 가지 일을 했습니다. 첫째, 문자열 비교로 제품을 맞추던 구조를
> 식별자 정책과 테이블 구조까지 함께 바꿔 실행계획상 예상 스캔 행을 약 130만
> 에서 약 6,000으로 줄였습니다. 둘째, 수집 작업의 실행 환경을 Airflow와
> Kubernetes로 옮겨 주 70~100건이던 Pod 할당 실패를 1~5건으로 줄였습니다.
> 셋째, 데이터가 틀렸을 때 되돌릴 수 있도록 원본 보존과 변경 이력, 재처리
> 경로를 남기는 것을 기본 출고 조건으로 만들었습니다.

### 이어질 질문에 연결하는 법

- `식별·정합성`을 말하면 2번(기술 결정)과 9번(false merge·false split)으로
  이어진다. 자기소개에서 결론까지 다 말하지 않고 한 문장으로 남긴다.
- `재처리`를 말하면 10번(중단선)과 12번(과제 확장)으로 이어진다.
- 리멤버 이야기는 마지막 한 문장만 하고, 이유는 1번에서 말한다.

### 경계

- 스택 이름부터 나열하지 않는다. 무엇을 맡았고 무엇을 고쳤는지 먼저 말한다.
- Spark·Kafka는 자기소개에서 먼저 꺼내지 않는다. 6번 질문에서 없다고 밝힌다.
- 배치형 CDC를 실시간 스트리밍이라고 말하지 않는다.
- AWS를 말해야 하면 EC2 위 self-managed MySQL 범위로만 말한다.
- 공식 직함과 실제 리딩 범위가 `Needs confirmation`이므로, 자기소개에서
  `팀을 이끌었다`고 말하지 않고 `맡아서 운영했다`로 말한다.
- 회사명·고객사명을 밝히지 않고 `보안 데이터 회사`, `고객사`로 말한다.
- 숫자는 위에 적힌 것만 쓴다. 응답시간·CPU·비용 절감률로 바꾸지 않는다.

## 1부: CTO 라운드

### 1. 왜 리멤버이며, 지금 이 역할이어야 합니까?

답변 축:

- 여러 원천에서 이름이 다른 대상을 식별·연결해 온 5년의 경험
- 명함·프로필·회사 데이터의 품질이 사람과 기회의 연결에 미치는 영향
- 행동 로그 집계보다 식별·정합성·재처리 문제를 오래 맡고 싶은 이유

첫 문장:

> 저는 서로 다른 이름으로 들어오는 데이터를 같은 대상으로 식별하고, 그 판단의
> 근거와 재처리 경로까지 만들어 온 데이터 엔지니어입니다. 이 경험이 사람·회사·
> 기회를 연결하는 리멤버의 데이터 문제와 가장 직접적으로 맞닿아 있습니다.

추가 질문:

- 다른 채용 플랫폼과 비교해 리멤버에서만 하고 싶은 일은 무엇입니까?
- 입사 후 어떤 문제부터 맡고 싶습니까?

#### 왜 이직하려고 합니까?

60~90초 답변:

> 현재 회사에는 초기 멤버로 합류해 5년 동안 공급망 보안 데이터를 수집하고,
> 서로 다른 제품·버전·취약점 정보를 같은 대상으로 식별하며, 그 결과가
> 운영 시스템에 반영되고 오류가 나면 재처리될 수 있도록 만드는 일을 해왔습니다.
> 이 과정에서 원본 보존,
> 정합성, 변경 이력, 재처리까지 데이터의 전체 흐름을 맡아 본 것이 제 강점이
> 되었습니다.
>
> 최근 공급망 보안 분야에서도 AI가 사람이 규칙으로 하나씩 풀던 문제를 더 빠르고
> 넓게 다루는 모습을 봤습니다. 저는 이것을 현재 일이 사라진다는 신호로 보지
> 않았습니다. 오히려 AI가 좋은 결과를 내려면 같은 대상을 정확히 식별하고,
> 어떤 원천과 규칙으로 만든 값인지 다시 확인할 수 있는 데이터 기반이 더
> 중요해진다고 느꼈습니다.
>
> 그래서 다음 단계에서는 제가 쌓은 식별·정합성 경험을 실제 사용자의 선택과
> 기회에 더 가까이 연결되는 제품에서 확장하고 싶었습니다. 리멤버는 명함,
> 프로필, 회사, 채용 기회를 연결하고 있고, AI가 활용될수록 사람과 회사를
> 정확히 연결하는 기반 데이터의 책임도 커지는 곳이라고 생각했습니다. 현재
> 회사를 벗어나기 위한 이직이라기보다, 지난 5년의 경험을 사람과 기회를 연결하는
> 문제로 넓히기 위한 선택입니다.

30초 답변:

> 현재 회사에서 5년 동안 공급망 보안 데이터의 수집, 식별, 정합성, 재처리까지
> 맡으며 데이터 엔지니어로서 기반을 만들었습니다. AI가 발전하는 과정을 보면서
> 모델의 결과가 좋아질수록 신뢰할 수 있는 원천과 식별 기준이 더 중요해진다는
> 점을 확인했습니다. 이제는 그 경험을 사람·회사·기회를 연결하는 리멤버의
> 데이터에 적용해, 실제 사용자의 선택에 더 가까운 문제를 맡고 싶어 이직을
> 결심했습니다.

압박 질문:

- 공급망 보안의 전망이 좋지 않다고 판단한 것입니까?
- AI가 데이터 엔지니어의 일도 줄일 수 있는데 왜 리멤버입니까?
- 현재 회사에서 같은 도전을 이어갈 수는 없습니까?

답변 경계:

- 공급망 보안이나 현재 회사를 낮게 평가하지 않는다.
- AI를 이직의 원인으로 두지 않고, 데이터 기반의 중요성을 확인한 계기로 둔다.
- `사용자와 더 가까운 문제`가 무엇인지 사람·회사 식별과 기회 연결로 설명한다.
- 현재 회사에 없는 기회나 내부 사정을 확인 없이 단정하지 않는다.

### 2. 본인이 내린 가장 중요한 기술 결정을 설명해 주세요.

사용할 이야기: 컴포넌트 식별자·테이블 재설계

- 상황: 실행계획에서 예상 스캔 행이 약 130만인 구조
- 책임: 쿼리뿐 아니라 문자열 비교와 식별자 정책까지 원인을 좁혀야 했음
- 판단: 단기 쿼리 수정, 인덱스 추가, 식별자·테이블 구조 변경을 비교
- 실행: 95개 쿼리 실행계획 확인, 팀장·CTO 리뷰 후 변경
- 결과: 실행계획상 예상 스캔 행 약 6,000
- 한계: 응답시간이나 CPU 감소율을 측정한 수치로 바꾸지 않음

압박 질문:

- 인덱스만 추가하지 않은 이유는 무엇입니까?
- 되돌려야 했다면 어떤 순서로 했겠습니까?
- 본인이 결정한 범위와 CTO가 승인한 범위를 나눠 말해 주세요.

### 3. 속도와 데이터 신뢰가 충돌했을 때 어떻게 판단합니까?

사용할 이야기: 범용 PC 장애 완화와 IDC 분리

답변 축:

- 새 장비가 없을 때 수집 시간을 분산해 월 10~20건의 문제를 월 5건 미만으로 완화
- IDC 장비가 준비된 뒤 수집·배포·운영 DB 역할을 분리
- 전환 뒤 월 1~2건 수준으로 감소
- 즉시 완화와 구조 변경의 출고 조건을 분리

압박 질문:

- 임시 조치가 오래 남지 않도록 무엇을 기록했습니까?
- 완벽한 해결을 기다리지 않고 배포한 기준은 무엇입니까?

### 4. 실패한 경험과 그 뒤 바뀐 출고 조건을 말해 주세요.

`Needs confirmation`:

- 실제로 잘못된 결과나 지연이 발생한 사건:
- 당시 내가 맡은 범위와 놓친 신호:
- 피해를 줄이기 위해 바로 한 일:
- 이후 새로 추가한 테스트·검토·모니터링 조건:
- 같은 문제가 다시 생겼는지 확인한 기간과 결과:

겸손한 성공담을 실패처럼 말하지 않는다. 직장 실패가 떠오르지 않으면 과제의
near-miss를 사용하되 `실제 운영 장애는 아니었다`고 먼저 밝힌다.

### 5. 동료나 리더와 의견이 충돌한 경험은 무엇입니까?

사용할 이야기: 엔진 쪽 판정 값을 데이터에 미리 넣어 달라는 요청 (사용자 제공
2026-08-27, 반복된 패턴)

첫 문장:

> 판정 엔진 쪽에서 판단해야 할 값을 미리 계산해 데이터로 넣어 달라는 요청을
> 두고, 어디까지가 데이터의 일이고 어디부터가 애플리케이션의 일인지 기준을
> 맞춘 경험이 있습니다.

답변 축:

- 상대가 걱정한 것: 조회 시점에 바로 쓸 수 있는 값이 데이터에 있길 원했고,
  엔진이 매번 판정을 수행하는 비용과 복잡도를 줄이고 싶어 했다.
- 내가 주장한 것: 판정 결과를 행으로 미리 전개하면 원본에 없는 조합까지
  행이 늘어나 DB가 비대해지고, 조회 속도·저장 비용이 나빠지며, 판정 규칙이
  바뀔 때마다 데이터 전체를 다시 만들어야 한다.
- 내가 양보하거나 바꾼 것: 요청을 거절로 끝내지 않았다. 데이터 파트가 근거를
  갖고 판단·검증·재처리까지 책임질 수 있는 값은 받아서 데이터로 만들고,
  그렇지 않은 판정은 매칭 시점에 애플리케이션에서 수행하는 기준으로 나눴다.
  판정에 필요한 근거 데이터(키·조건·출처)는 데이터 쪽에서 정리해 제공했다.
- 함께 확인한 근거: 행 수와 용량 증가 추정, 판정 규칙 변경 시 재처리 범위.
- 최종 결정권자와 확정 문구: `Needs confirmation` — 면접 전에 구체 사건
  1건(언제, 어떤 테이블, 누가 결정)을 특정해 적는다.
- 이후 변화: 원본이 말하는 단위로만 행을 저장하고 판정은 매칭 시점으로
  옮기는 원칙이 이후 설계의 기본이 됐다.

압박 질문:

- 상대가 맞았던 부분은 무엇입니까? → 조회 비용 우려는 실제 문제였다. 그래서
  근거 데이터를 정리해 제공하는 쪽으로 답했다고 말한다.
- 결정이 반대로 났다면 어떻게 실행했겠습니까? → 전개 데이터의 재처리 경로와
  규칙 버전을 남기는 조건을 걸고 실행했겠다고 말한다.

경계: 진행 중인 OS 패키지 취약점 테이블 재설계(원본 단위 그레인, 호스트 판정을
매칭 시점으로 이동)는 이 원칙을 뒷받침하는 사례로만 쓴다. 구버전 테이블의
비대(371만 행, 데이터 10.4GB+인덱스 4.3GB)가 엔진 요청에서 비롯됐는지는
확인되지 않았으므로 갈등 사건 자체로 말하지 않는다.

### 6. Spark·Kafka 운영 경험이 없는데 왜 뽑아야 합니까?

첫 문장:

> Spark와 Kafka를 프로덕션에서 운영한 경험은 없습니다. 대신 Python·SQL·
> Airflow·Kubernetes·MySQL 환경에서 80개가 넘는 수집 작업의 재처리, 동시성,
> DB 부하와 장애 대응을 맡아 파이프라인 운영의 기본 문제를 직접 풀었습니다.

이어 말할 근거:

- Pod 할당 실패 주 70~100건에서 1~5건으로 감소
- DML Broker 적용 뒤 4개월 동안 관련 오류 0건
- 새 도구 이름보다 팀의 데이터량·지연 목표·장애 이력·관측 지표부터 학습

하지 말아야 할 말:

- 공개된 리멤버의 Debezium·MSK·Glue·S3 Tables를 직접 운영한 것처럼 설명
- 배치형 CDC를 실시간 스트리밍으로 바꾸어 표현

### 7. 입사 후 90일 계획을 말해 주세요.

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

압박 질문:

- 개선 대상을 고르는 기준은 무엇입니까?
- 90일 동안 배포하지 못해도 남겨야 할 결과는 무엇입니까?

## 2부: AI/Data 실장 라운드

### 8. 데이터 엔지니어가 AI 품질에 어떻게 기여합니까?

첫 문장:

> 모델에 들어가기 전에 같은 사람과 회사를 일관되게 식별하고, 값이 어떤 원천과
> 규칙에서 나왔는지 다시 찾을 수 있어야 합니다. 저는 그 식별·정합성·출처·
> 재처리 조건을 만드는 쪽에서 기여할 수 있습니다.

추가 질문:

- 모델 지표는 좋은데 사용자 불만이 늘면 어디부터 확인하겠습니까?
- 학습 데이터의 규칙이 바뀌었을 때 무엇을 버전으로 남기겠습니까?

### 9. false merge와 false split 중 무엇이 더 위험합니까?

답변 축:

- 자동 메시지·추천·외부 노출에서는 잘못 합친 피해가 커 false merge를 우선 방지
- 내부 분석처럼 누락을 보정할 수 있으면 false split 허용 폭을 별도로 결정
- 정확 일치, 근거 점수, 사람 검토, 보류로 처리 경계를 나눔
- precision·recall, 표본 검수, 현업 수정 이력으로 기준을 조정

압박 질문:

- 하나의 임계값으로 운영하면 왜 안 됩니까?
- 정답 데이터가 부족하면 기준을 어떻게 만들겠습니까?

### 10. 어떤 품질 오류에서 파이프라인을 멈춥니까?

판단 기준:

1. 고객·개인정보·후속 시스템에 미치는 피해
2. 원본을 이용한 재처리 가능 여부
3. 정상 변동과 오류를 구분할 기준값 존재 여부

중단 예시: 키 중복, 필수 컬럼 파싱 실패, 원본 대비 설명되지 않는 건수 급감.

경고·격리 예시: 정답을 단정할 수 없는 체크섬 차이, 일부 비필수 값의 이상,
사람 검토가 필요한 낮은 식별 점수.

### 11. 최신성과 정확성이 충돌하면 무엇을 우선합니까?

첫 문장:

> 사용처의 오류 비용과 복구 가능성을 먼저 보겠습니다. 추천·외부 노출·정산과
> 내부 탐색용 분석에 같은 기준을 적용하지 않겠습니다.

확정·잠정 데이터를 구분하고 원천 시점, 품질 상태, 재처리 가능 여부를 함께
노출한다. `정확성이 항상 우선` 또는 `최신성이 제품에서는 우선`처럼 하나로
단정하지 않는다.

### 12. 제출 과제를 실서비스 규모로 옮기면 무엇을 바꾸겠습니까?

반드시 인정할 현재 한계:

- DuckDB 단일 writer
- `max_active_runs=1`
- 업무 데이터와 실행 메타데이터 사이의 원자성 경계

확장 순서:

1. 원천 변경 로그와 기준점 결정
2. Full Load와 CDC 접점의 누락·중복 검산
3. 멱등 키와 재처리 단위 정의
4. backlog·freshness·오류율·격리 건수·원천 대 대상 검산 관측

### 13. 개인정보가 AI 학습이나 검색용으로 복제되면 무엇을 확인합니까?

- 수집 목적과 사용할 수 있는 범위
- 접근 주체와 최소 권한
- 마스킹·보존·삭제 정책
- 재처리 산출물과 임시 파일의 만료
- 감사 로그와 삭제 요청 전파

보안 메타데이터를 운영한 경험을 개인정보 운영 경험으로 바꾸어 말하지 않는다.

### 14. AI 도구의 결과를 어디까지 믿습니까?

사용할 이야기: AI PR 리뷰 자동화

- 외부 모델 호출 전 secret scan
- 실행 도구를 commit SHA로 고정
- 변경 경로 매핑이 없으면 실패
- AI 지적을 요구사항·테스트·실행 결과로 재검증
- 승인과 제출 책임은 사람에게 유지

압박 질문:

- AI가 놓친 오류의 책임은 누구에게 있습니까?
- 민감한 데이터가 프롬프트에 들어가지 않는다는 것을 어떻게 확인합니까?

## 3부: 짧은 연속 질문

각 질문에 30초 안으로 답한다.

1. 가장 자신 있는 기술 하나와 그 한계는?
2. 운영 중 지표 하나만 볼 수 있다면 무엇을 보겠는가?
3. 데이터 정답을 누가 결정해야 하는가?
4. 재처리가 안전하다는 증거는 무엇인가?
5. 기술 부채를 제품 담당자에게 어떻게 설명하는가?
6. 최근 받은 불편한 피드백은 무엇이었는가? `Needs confirmation`
7. 공식 직함과 실제 리딩 범위를 나눠 말해 달라. `Needs confirmation`
8. 제출 이력서의 AWS 범위를 정확히 말해 달라.

AWS 범위 답변:

> 실제 운영 경험은 EC2 위 self-managed MySQL입니다. 제출 자료의 RDS·S3·EFS
> 표기는 검수에서 놓친 오기입니다. 1차에서 이미 정정했다면 2차에서는 질문이
> 나올 때만 짧게 답하겠습니다.

## 4부: 인성·마무리 질문 (2026-08-27 사용자 제공 재료로 작성)

### 15. 성격의 장점과 단점을 말해 주세요.

장점 (60초):

> 흔들리지 않고 끝까지 마무리하는 것이 장점입니다. 주변에서 마음이 단단하다는
> 말을 자주 듣고, 아내는 저를 힘든 일이 있어도 자기 일을 끝까지 책임지는
> 사람이라고 말합니다. 초기 멤버로 합류한 지금 회사에서 5년 동안 장애와 재처리
> 같은 궂은 상황을 포함해 한 도메인의 데이터를 계속 맡아 온 것도 그 성격
> 덕분이라고 생각합니다. 또 하나는 유연함입니다. 다른 팀의 요구나 갑작스러운
> 변경도 일단 받아들이고 기준을 찾는 편이라, 협업에서 감정적인 충돌을 만든
> 적이 거의 없습니다.

단점 — 기본 답변 (30~60초):

> 작은 세부를 놓칠 때가 있습니다. 오타나 표기 실수 같은 것을 제 눈으로는 잘
> 못 잡습니다. 그래서 저를 믿는 대신 확인 장치를 만듭니다. 제출 과제에서도
> 파이프라인 안에 검산 여덟 개를 넣어 실행마다 스스로 검증하게 했고, 문서와
> 코드는 리뷰와 자동 검사를 거친 뒤 내보냅니다.

단점 — 추가 질문이 오면 (두 번째 단점):

> 한번 아니라고 판단한 것은 쉽게 바꾸지 않는 고집이 있습니다. 분위기나
> 다수결로는 잘 설득되지 않고, 납득할 수 있는 근거가 나와야 바뀝니다. 대신
> 그걸 알기 때문에, 의견이 갈리면 어떤 근거를 보면 제 판단을 바꿀지 먼저
> 말해 두려고 합니다.

경계:

- `착하다`는 말은 면접에서 직접 쓰지 않는다. 협업에서 트러블이 없었다는
  사실로 보여준다.
- 단점을 장점처럼 포장한 답(`너무 꼼꼼해서`)을 만들지 않는다. 실제 약점과
  실제 보완 장치를 말한다.

### 16. 다른 팀과 협력한 경험을 말해 주세요.

사용할 이야기: 판정 엔진 팀과의 취약점 테이블 재설계 협의 (진행 중)

첫 문장:

> 데이터 파트가 만든 결과는 판정 엔진 팀이 소비하기 때문에, 테이블 구조와
> 역할 경계를 엔진 팀과 함께 정하는 일이 협업의 중심입니다. 최근에는
> OS 패키지 취약점 수집 재설계를 엔진 팀과 역할을 나눠 진행하고 있습니다.

답변 축:

- 상황: 기존 수집 구조의 오탐이 보고돼 테이블 구조를 다시 설계해야 했고,
  그 구조는 엔진 팀의 판정 방식과 맞물려 있어 혼자 결정할 수 없었다.
- 내 역할: 원본 전체(문서 6만여 건, 항목 약 715만 개)를 실측해 행 수와
  커버리지를 숫자로 만든 설계안을 문서로 제시했다. 기존에 합의된 문서와
  다른 제안은 일방적으로 바꾸지 않고 `결정 필요` 안건으로 올렸다.
- 역할 경계: 수집·정합성·재처리는 데이터 파트가, 호스트 판정은 매칭 시점에
  엔진 쪽이 맡는 방향으로 협의했다. 협의에서 역할 분담과 마감(9월 말)을
  합의했다.
- 상태: 진행 중인 일이므로 `완료했다`고 말하지 않는다. 설계 협의 단계까지
  진행됐다고 말한다.

예전 사례가 더 맞는 질문이면: Airflow·Kubernetes 공통 실행 환경. 실행
환경과 스케줄은 내가 맡고 각 수집기 로직은 담당자가 소유하는 구조로, 80개가
넘는 수집 작업을 여러 담당자와 함께 운영했다 (Pod 할당 실패 주 70~100건에서
1~5건으로 감소).

### 17. 마지막으로 하고 싶은 말이 있습니까?

기본 (30초):

> 오늘 제 답변에는 잘한 일과 함께 부족한 부분도 그대로 말씀드렸습니다. 저는
> 지난 5년 동안 서로 다르게 들어오는 데이터를 같은 대상으로 식별하고, 그
> 판단을 검증하고 되돌릴 수 있게 만드는 일을 해왔습니다. 사람과 회사와 기회를
> 연결하는 리멤버의 데이터는 이 경험이 가장 직접적으로 쓰이는 곳이라고
> 생각합니다. 함께 일하게 된다면 말씀드린 90일 계획처럼 작은 문제부터 끝까지
> 소유해 결과로 보여드리겠습니다. 시간 내주셔서 감사합니다.

활용 규칙:

- 면접 중 대답이 미진했던 질문이 있으면, 위 문장 대신 그 답변 하나를 20초로
  보완하는 데 쓴다.
- 이미 면접에서 한 말을 그대로 반복하지 않는다. 짧게 끝내는 것이 길게 잘
  말하는 것보다 낫다.

## 역질문

면접 중 이미 답을 들은 것은 지우고 패널별 한 개씩만 묻는다.

CTO에게:

> 빠른 실행과 데이터 신뢰가 충돌했을 때 CTO님이 멈추는 선은 무엇이고, 최근
> 그 판단이 필요했던 사례는 무엇이었나요?

AI/Data 실장에게:

> 사람·회사 매핑에서 false merge와 false split의 비용을 어떻게 나누고,
> 자동 판정과 사람 검토의 경계를 어떤 지표로 조정하시나요?

## 녹음 채점표

각 항목을 0~2점으로 채점한다. 질문당 8점 이상을 목표로 한다.

| 항목 | 0점 | 1점 | 2점 |
|---|---|---|---|
| 결론 | 10초 안에 없음 | 늦지만 확인됨 | 첫 문장에 있음 |
| 책임 범위 | 팀 이야기만 함 | 일부 구분 | 내가 한 일과 타인이 한 일을 구분 |
| 판단 | 선택지가 없음 | 이유만 있음 | 선택지와 판단 기준이 있음 |
| 근거 | 추상적 결과 | 숫자 또는 검증만 있음 | 대상·기간이 붙은 숫자와 검증이 있음 |
| 한계 | 과장하거나 회피 | 한계만 인정 | 한계와 다음 행동을 함께 말함 |

합계가 낮은 답변은 문장을 더 붙이지 말고, 빠진 항목 하나만 보강한다.