_예상 참석자: CTO, AI/Data 실장 · 일정·시간·방식: Needs confirmation_
답변 규칙
결론 1문장, 상황·내 책임, 선택지·판단 기준, 검증 결과, 한계·다음 행동
본 답변은 60~90초, 추가 질문은 30초. 기술 이름보다 고객 위험, 운영 비용, 검증과 되돌림을 먼저 말한다.
60초 자기소개
여러 곳에서 다른 이름으로 들어오는 데이터를 결국 같은 대상인지 판단해 연결해 온 데이터 엔지니어입니다. 초기 멤버로 합류한 보안 데이터 회사에서 5년간 오픈소스 제품·버전·취약점과 12종 리눅스 배포판의 보안 정보를 수집하고 연결했습니다. 표기 차이로 같은 제품이 갈라지고 다른 제품이 합쳐지는 문제를 식별 규칙, 원본 보존, 변경 이력, 재처리 구조까지 내려가 고쳤고, 수십억 행 MySQL과 80개가 넘는 수집 작업을 운영했습니다. 이제 이 경험을 사람·회사· 기회를 연결하는 리멤버의 데이터에 적용해, AI와 제품이 믿고 사용할 수 있는 식별·정합성 기반을 맡고 싶습니다.
질문별 첫 문장
- 왜 리멤버:
제가 오래 풀어 온 식별·정합성 문제가 사람과 기회의 연결이라는 제품 결과와 직접 만나는 곳이기 때문입니다. - 왜 이직:
현재 회사를 벗어나려는 선택보다, 지난 5년의 식별·정합성 경험을 실제 사용자의 선택과 기회에 더 가까운 문제로 넓히려는 이직입니다. - 중요한 결정:
쿼리 하나를 고치는 대신 식별자 규칙과 테이블 구조를 함께 바꾼 결정입니다. - AI 기여:
모델보다 먼저 같은 사람과 회사를 일관되게 식별하고 값의 원천과 규칙을 다시 찾을 수 있게 해야 합니다. - 부족한 스택:
Spark·Kafka 프로덕션 운영 경험은 없지만, Airflow·Kubernetes·MySQL에서 재처리·동시성·부하·장애 문제를 직접 풀었습니다. - 90일:
30일은 구조와 경계를 배우고, 60일은 품질 문제 하나를 소유하며, 90일에는 작은 개선의 결과와 되돌림을 남기겠습니다. - 장점:
흔들리지 않고 끝까지 마무리하는 것과, 다른 팀의 요구를 일단 받아들이고 기준을 찾는 유연함입니다. - 단점:
작은 세부를 놓칠 때가 있어 저를 믿는 대신 검산과 리뷰 같은 확인 장치를 만듭니다. - 갈등:
엔진 쪽 판정 값을 데이터에 미리 넣어 달라는 요청을 두고, 데이터가 책임질 수 있는 값과 애플리케이션이 판정할 값의 기준을 맞춘 경험이 있습니다. - 협력:
데이터 파트의 결과는 판정 엔진 팀이 소비하기 때문에, 테이블 구조와 역할 경계를 엔진 팀과 함께 정해 왔습니다. - 마지막 할 말:
부족한 부분도 그대로 말씀드렸고, 함께 일하게 되면 90일 계획처럼 작은 문제부터 끝까지 소유해 결과로 보여드리겠습니다.
이야기와 숫자
| 질문 | 이야기 | 말할 숫자 | 넘지 말아야 할 선 |
|---|---|---|---|
| 기술 결정 | 컴포넌트 식별자·테이블 재설계 | 예상 스캔 행 130만에서 6,000 | 응답시간·CPU 감소율 아님 |
| 속도와 신뢰 | 범용 PC 완화 후 IDC 분리 | 월 10~20건, 완화 후 5건 미만, 전환 뒤 1~2건 | AWS는 EC2 self-managed MySQL |
| 운영 안정성 | DML Broker | 관련 오류 일 3~4건, 적용 뒤 4개월 0건 | 고객사 일상 운영은 기술지원팀 |
| 공통 플랫폼 | Airflow·Kubernetes | 80개 넘는 작업, Pod 실패 주 70~100건에서 1~5건 | 개별 수집기 로직은 담당자 소유 |
| 품질·재처리 | 리멤버 과제 | 신규 2,174·변경 4,000·무변경 17,087·부재 9,426 | 단일 writer, 메타데이터 원자성 경계 |
| AI 검증 | AI PR 리뷰 | secret scan·SHA 고정·미매핑 시 실패 | AI가 최종 승인하지 않음 |
AI/Data 판단 기준
- false merge와 false split은 사용처의 오류 비용을 먼저 묻는다.
- 중단선은 고객·개인정보 피해, 재처리 가능성, 기준값 유무로 정한다.
- 정확도와 최신성은 추천·외부 노출·정산·내부 분석을 나눠 판단한다.
- 원천, 규칙 버전, 품질 상태, 격리, 재처리 이력을 남긴다.
- 개인정보 복제본에도 접근·보존·삭제·감사 조건을 전파한다.
아직 채워야 하는 답변
- 의견 충돌: 패턴 답변은 채움(2026-08-27, 모의면접 5번). 구체 사건 1건의
시점·테이블·최종 결정권자는 Needs confirmation
- 실제 실패와 이후 바뀐 출고 조건:
Needs confirmation - 받은 피드백과 행동 변화:
Needs confirmation - 공식 직함과 실제 리딩 범위:
Needs confirmation - 주요 작업이 고객·제품·동료에게 만든 구체적인 변화:
Needs confirmation
정정과 금지선
- 제출 자료의 AWS 태그는 실제 EC2 self-managed MySQL 범위로 정정한다.
- 배치형 CDC를 실시간 스트리밍이라고 말하지 않는다.
- 리멤버 공개 스택을 본인의 운영 경험으로 말하지 않는다.
- AI가 현재 일을 대체해서 이직한다고 말하지 않는다.
- 공급망 보안이나 현재 회사를 낮게 평가하지 않는다.
- 검증하지 않은 매출·사용자·비용 절감 수치를 만들지 않는다.
- 1차에서 이미 AWS 범위를 바로잡았다면 2차에서 먼저 길게 반복하지 않는다.
마지막 역질문
CTO:
빠른 실행과 데이터 신뢰가 충돌했을 때 멈추는 선은 무엇이고, 최근 그 판단이 필요했던 사례는 무엇이었나요?
AI/Data 실장:
사람·회사 매핑에서 false merge와 false split의 비용을 어떻게 나누고, 자동 판정과 사람 검토의 경계를 어떤 지표로 조정하시나요?
입장 전 확인
- 일정·접속 링크 또는 장소·면접 시간·추가 참석자
- 자기소개와 핵심 사례 세 개를 녹음해 각 90초 이하인지
- 실패·피드백 답변을 실제 경험으로 채웠는지, 갈등 답변의 구체 사건
1건(시점·결정권자)을 특정했는지
- 역질문 두 개 중 면접 중 이미 답을 들은 질문을 지웠는지