리멤버 Data Engineer 2차 모의면접

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

함께 볼 문서: 2차 준비 가이드 · 당일용 1장 요약

정확한 면접 질문·시간·진행 방식은 공개되지 않았다. 이 대본은 제출 이력서, 과제, 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점 이상을 목표로 한다.

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