LLM WikiAccess-protected knowledge portal

WIKI

부릉 Data Engineer 서류 페르소나 리뷰 (CTO·CEO·기술팀장)

부릉 Data Engineer 서류 페르소나 리뷰 CTO·CEO·기술팀장 검토일 2026 07 19 대상 career/클로드이력서/부릉 data engineer/ 이력서 3쪽 PDF + 포트폴리오 11쪽 PDF 2026 07 19 재생성본 대조 공고 부릉 Data Engineer, 리멤버 323031, 마감 2026 07 31 공고 원문 ai/sources/career/2026 07 19 vroong data engineer

경로human/reports/2026-07-19-vroong-persona-resume-review.md
카테고리Reports
태그#airflow #infra #kubernetes #mysql #persona #portfolio #report #reports #resume #review #vroong

검토일: 2026-07-19 대상: career/클로드이력서/부릉-data-engineer/ 이력서 3쪽 PDF + 포트폴리오 11쪽 PDF (2026-07-19 재생성본) 대조 공고: 부릉 Data Engineer, 리멤버 323031, 마감 2026-07-31 (공고 원문: ai/sources/career/2026-07-19-vroong-data-engineer-posting.md) 방식: CTO, CEO, 데이터팀 기술팀장 관점의 독립 리뷰 3건.

한 줄 결론

세 리뷰 모두 판정 BORDERLINE — 서류 통과권이지만 제출 전 수정이 필요하다. 가장 심각한 문제는 세 리뷰가 동일하게 지적한 Debezium "직접 돌려 검증" 표현으로, 확인된 사실(비교 검토만, hands-on은 Maxwell FileSink PoC뿐)을 초과하는 유일한 주장이며 부릉의 우대사항(Debezium·Kafka CDC)과 정면으로 겹쳐 면접에서 반드시 검증당한다. 7월 17일 4사 비판 리뷰에서 이미 P0으로 지적됐으나 아직 수정되지 않았다.

필수 요건 8개 매칭 (기술팀장 평가)

요건판정
DE 경력 5년+충족(경계선 — 2021.06~, 약 5년 1개월)
비즈니스 담당자 협업부분 — 협업 상대가 전부 기술 조직 내부
파이프라인 설계·운영충족
DW·Data Mart 모델링미충족 — 근거 문장 자체가 없음(OLTP 모델링뿐)
Python·SQL충족 (EXPLAIN 수준 증거, 상위권)
AWS 실무부분 — 사실은 충족하나 서사가 "떠난 이야기"로 읽힘
Kubernetes 운영충족 (8개 중 가장 강함)
Airflow 구축·운영충족

우대: 비용·시스템 최적화 충족(94%·인덱스 53%), Debezium·Kafka CDC 부분, Spark 미충족, Terraform 미충족.

공통 P0 (세 리뷰 모두 지적)

  1. Debezium 수행 범위 과장 — 소개 "Debezium과 Maxwell은 직접 돌려 검증한 뒤",

경력 bullet "Debezium·Maxwell 직접 검증". "Debezium·Canal은 아키텍처·운영 요건 수준 비교 검토, Maxwell은 FileSink PoC로 직접 검증"으로 갈라 써야 한다. 정직하게 써도 충분히 좋은 이야기다.

  1. AWS 서사가 거꾸로 — AWS가 등장하는 곳이 전부 "비용 94% 절감"(=떠난 이야기).

AWS 위에서 운영하는 회사이므로 "운영 DB는 현재도 AWS에서 직접 운영 중"을 먼저 세우고, 이관은 워크로드별 비용 의사결정으로 프레임 전환.

  1. Streaming 공백에 무대응 — 공고 1번 업무가 Streaming인데 이력서가 침묵.

지어내지 말고 브릿지 한 문장: 배치형 CDC에서 검증한 멱등 적용·커서 관리·실패 분류를 스트리밍 환경으로 확장하고 싶다는 수준으로 간극 인지를 보여줄 것.

CEO 관점 추가 P0

(주문·배송·정산)에 왜 옮겨지는가"로 닫을 것. 근거 없는 물류 애정 고백은 금지.

첫 페이지 상단으로.

회사이므로 bullet 첫 문장은 사업 언어로.

CTO 관점 추가 P0

Kafka 트랜잭셔널 EOS와의 차이, DDL 경로 멱등성을 반드시 파고든다. "멱등 적용(effectively-once)"으로 용어를 정확히 하고 답변 카드 준비. (기술팀장도 동일 지적 — 주장 범위를 스스로 좁히라는 취지.)

늘었는지 답할 수 없으면 과장으로 읽힘. 1회로 고정하고 나머지 삭제.

식별자 정책, 계층화)을 브릿지 문단으로 쓰고 "정식 dimensional modeling은 학습 중"을 솔직히 밝히는 편이 무대응보다 낫다.

3~4건 등은 근거를 즉답할 수 있게 준비. (검토자에게는 미검증으로 보였으나 실제로는 근거 있음 — 9.6→4TB는 워크로그·portfolio 수정 커밋(adad15a), 66.7억 행·914GB와 701GB>178GB는 Confluence DAT-3313/3314 실측, 3~4건은 본인 확인 수치. 서류 수정이 아니라 면접 답변 준비 항목.)

기술팀장 관점 추가 P0 (포트폴리오)

도발적 주장. "at-least-once 전달 + 멱등 UPSERT(DML 한정, DDL 별도 경로)"로 주장 범위를 스스로 좁힐 것.

(설계 산정)"로 분리하고, "외부 요청 0건"에 "적용한 소스부터"라는 조건 복원.

공통 P1

JD 관련도순으로 앞 5개 배치 또는 6~7건으로 축소.

근거인데 한 줄뿐 — 구체화 가치 있음.

언어로 재서술.

흐트러져 읽힘 — PDF 최종본 검사).

참고 — 좋게 평가된 점

장애를 근본 원인까지 추적하는 방식은 두 리뷰 모두 최상급 평가.

순서를 잡는 데 집중했습니다" — 절감 숫자보다 순서 감각.

면접 대비 메모 (CTO 화이트보드 예상 5문항 + 답변 가능성)

  1. 배달 주문·기사 위치 이벤트의 Kafka 실시간 파이프라인 설계 — 원리(파티셔닝 키,

멱등 컨슈머, 순서 보장)는 CDC 경험에서 유추 가능하나 컨슈머 그룹 리밸런싱·lag· EOS 프로듀서 등 운영 디테일에서 공백 노출. 부분 답변 가능, 준비 필수.

  1. "직접 만든 CDC 대신 Debezium을 썼다면?" — 기각 논리(TCP 제약, Kafka Connect

운영 부담)로 방어 가능. 단 Debezium 문구를 안 고치면 "직접 돌려봤다면서요?"에서 무너짐.

  1. 주문 데이터 Data Mart 모델링(팩트/디멘전) — 가장 취약. Kimball 용어·SCD·그레인

공백이 화이트보드에서 노출됨. 서류 통과 시 사전 학습 필수.

  1. 배치 파이프라인의 지연·중복·누락 감지·복구 — 가장 강함. 전수 대조·멱등 백필·

version_id·커서 분리로 실전 답변 가능.

  1. Airflow 80개 크롤러 동시성·백필 — pool·backoff·시급성 주기 설계로 강하게 답변

가능.

대등하게 논의 가능. Kafka 구체론(파티션 수, consumer group rebalance, lag, 윈도우·워터마크)에서 막힐 것 — 막혔을 때 "제 배치 경험에선 이렇게 대응했는데 스트리밍에선 뭐가 다른가"로 되묻는 태도가 통과 조건.

풀어본 실제 사례 하나 / AWS를 떠나지 않는 회사에서 첫 6개월 비용 절감 접근.

검토 근거