Deep dive — 60분 런북

Opendoor 2라운드: 과거 프로젝트 하나를 60분 깊게. 스파인은 ERP-MES 하나 — 분 단위로 흐름을 몸에 붙여라.

1. 0-5분Opening & Context

   30초 인사 후 바로 시스템 한 줄 정의: 작업자가 공정 완료를 저장하면 MES가 기록하고, MES가 ERP에 원가 데이터를 전달하는 구조(작업자 → MES → ERP). 내 역할 명시: 이 트랜잭션 경계를 내가 재설계했다. 마지막에 면접관에게 선택권: 문제 발견 과정부터 갈지, 아키텍처부터 갈지.

   채점: 커뮤니케이션 — 회사/도메인 배경 없이도 면접관이 1분 안에 따라올 수 있게 맥락을 잡아주는 능력. 같이 일할 때 설명이 편한 사람인지.

   • 회사 소개 말고 시스템 정의부터: '작업자 저장 → MES 기록 → ERP 전달' 세 박스
   • 'I owned' — 팀이 아니라 내가 재설계했다고 첫 문장에서 박기
   • 5분 절대 넘기지 말 것. 배경이 길면 뒤의 트레이드오프 시간이 죽는다
   • 마지막에 'Where would you like me to start?'로 면접관을 끌어들이기
   🗣 이 스테이지 여는 문장

   “I'd like to walk through a production issue I owned end to end — our MES talking to ERP.”

   checking microphone…

2. 5-14분Problem & Stakes

   증상을 작업자 말 그대로 인용: 미국 작업자들이 '라인을 떠난 제품이 아직 생산 중으로 보인다'고 리포트. 추적 과정 서술: ERP 타임아웃 → @Transactional 전체 롤백 → 우리 로컬 기록까지 같이 증발. '공정은 앞으로 갔는데 시스템엔 아무것도 없다.' stakes를 숫자로: 월 20건 재처리, 운영자 신뢰 하락, 원가 데이터 정합성.

   채점: 오너십 + 근본원인 추적 — 증상에서 트랜잭션 경계까지 남 탓 없이 스스로 파고들었는지. 'ERP 팀 잘못' 프레임이 한 번이라도 나오면 감점.

   • 원인을 한 문장으로: 'Two writes were in one transaction — ours and theirs'
   • 월 20건 재처리라는 숫자로 stakes를 구체화
   • ERP를 비난하지 말 것 — 잘못된 건 외부 호출을 트랜잭션 안에 둔 우리 경계 설계
   🗣 이 스테이지 여는 문장

   “US operators reported products that left the line still showing in production — and we had recorded nothing.”

   checking microphone…

3. 14-28분Architecture Walk (draw the boxes)

   Before/After 두 줄 그림. Before: 작업자 → MES @Transactional[로컬 저장 + ERP 동기 호출] → ERP 실패 시 전부 롤백. After: 작업자 → MES @Transactional[로컬 저장 + staging row, postDate를 지금 스탬프] → 즉시 커밋·리턴, 별도 워커가 1분마다 staging을 drain해서 ERP 호출 후 status 갱신(pending/success/failed). 코드 레벨로 한 번: saveProductionState + stagingRepo.save가 한 트랜잭션, @Scheduled drain이 바깥.

   채점: 기술 명료성 — 박스 서너 개로 시스템을 그릴 수 있는지, 트랜잭션 경계가 정확히 어디인지 손으로 짚는지. 설계를 말이 아니라 그림으로 공유하는 협업 능력.

   • 박스는 A→B→C로 단순하게. 화살표에 'sync'/'async' 라벨만 추가
   • 'no external call in this tx' — 경계선을 손으로 짚으며 말하기
   • postDate를 저장 시점에 찍는 이유(영업일 보존)를 그림에 미리 표시 — 뒤의 질문 방어
   • 중간에 'Does this picture make sense so far?'로 끼어들 틈 주기
   🗣 이 스테이지 여는 문장

   “Let me draw the before and after — two writes were in one transaction, ours and theirs.”

   checking microphone…

4. 28-40분The Hard Decisions & Trade-offs

   결정 1: 트랜잭션 분리(1차 수정)에서 왜 멈추지 않았나 — 롤백은 사라졌지만 동기 ERP 호출이 피크 시간 UI 행을 유발해서 호출 자체를 저장 경로에서 빼냄(2차). 결정 2: eventual consistency 수용 — 회계 쪽 postDate 우려를 'ERP 처리 시점이 아니라 MES 저장 시점에 스탬프'로 해결. ERP 팀 매니저와 30분 대화로 합의, 단독 결정 아님. 트레이드오프 4개를 묻기 전에 먼저: 최대 1분 지연, 빈 폴링 비용, 실패 행 수동 재시도, 자정 넘기면 postDate drift.

   채점: 트레이드오프 정직성 + 첫 원리 사고 — Opendoor가 가장 깊게 보는 구간. 단점을 스스로 먼저 말하는지, 결정 근거가 패턴 이름이 아니라 원리(경계, 일관성 모델)인지.

   • 트레이드오프는 질문 받기 전에 먼저 깐다: 'ERP now lags the floor by up to a minute'
   • 'I went to the ERP team manager first, CC'd my manager' — 단독 플레이 아님을 명시
   • 버즈워드 금지: 'outbox pattern'이란 단어보다 동작 설명이 먼저. 이름은 맨 마지막에
   • 왜 2단계로 갔는지 솔직하게 — 처음부터 완벽하지 않았다는 게 오히려 신뢰 신호
   🗣 이 스테이지 여는 문장

   “The hard part wasn't the code — it was accepting eventual consistency on financial data.”

   checking microphone…

5. 40-46분What I'd Do Differently

   면접관이 묻기 전에 회고를 먼저: 처음부터 비동기로 설계했어야 했다 — 'don't keep one foot in the synchronous world.' 지금이라면 두 가지를 깊게: 1분 폴링 대신 CDC(Debezium)로 staging 테이블 tail, ERP 호출에 dedup key로 멱등성 보장(재시도가 이중 전기 못 내게). 나머지(지수 백오프 + dead-letter, 파티셔닝)는 한 줄씩만. 마지막에 Opendoor 도메인 연결: offer 수락 시 offer + outbox row를 한 트랜잭션에, 결제 타임아웃이 수락을 롤백하면 안 된다.

   채점: 자기비판 + 성장 가능성 — 본인 설계의 한계를 스스로 말하는지, 개선안이 나열이 아니라 구체적인지. 같이 일하면 피드백을 받는 사람인지.

   • 개선안 4개 중 2개만 깊게(CDC, 멱등성) — 4개 나열은 외운 티가 난다
   • Opendoor 연결은 한 문장만: 'same shape as an offer accept plus a payment worker'
   • 회고는 변명 없이: 'I'd do X' 형태로, 'we couldn't because...'가 아니라
   🗣 이 스테이지 여는 문장

   “Looking back, I'd ship the asynchronous design from day one, not as a second iteration.”

   checking microphone…

6. 46-51분Results & Metrics

   숫자 세 개를 정확한 단위로: 해당 이슈 티켓 거의 0, SOP 에러 카테고리 약 90% 감소, 처리 시간 60% 단축. 출처를 바로 붙이기: Jira의 SOP 에러 카테고리 전후 트렌드, 90%는 카테고리 전체 기준이고 특정 이슈는 거의 0. 측정 못 한 건 못 했다고: 정확한 지연 분포 같은 건 안 쟀다.

   채점: 정직성 — 숫자를 어떻게 쟀는지 설명 가능한지. 부풀리지 않는지. 측정의 한계를 스스로 말하는 사람인지.

   • 'about ninety percent' — 정확한 척 하지 말고 'about' 유지, 출처(Jira 트렌드)는 한 문장
   • 숫자 말하고 멈추기. 부풀리는 부연 설명이 신뢰를 깎는다
   • 90%와 0의 차이를 스스로 구분해서 말하면(특정 이슈 vs 카테고리) 정직성 가산점
   🗣 이 스테이지 여는 문장

   “Specific-issue tickets dropped to near zero — about ninety percent off the whole category.”

   checking microphone…

7. 51-60분Their Digging Questions

   예상 8문은 이미 준비됨(followUps): 원래 트랜잭션 구조 / 발견 경위 / 왜 1차에서 안 멈췄나 / eventual consistency 반대 / 90% 측정 방법 / 배치 실패 시 롤백 플랜 / ERP 계약을 단독으로 바꿨나 / 회고. 모르면 'I didn't measure that, but here's how I'd find out.' 범위가 넓어지면 보조 스토리로 피벗: 엣지 설계 → gateway, 마켓별 규칙 → multi-plant, 중복 검증 → validation. 끝에 역질문 1개.

   채점: 압박 속 일관성 — 파고들수록 디테일이 깊어지는지 흔들리는지. 모르는 것에 솔직한지. 즉석에서 같이 사고할 수 있는 동료인지.

   • 답을 외우지 말고 구조로: 증상→경계→분리→비동기→postDate→숫자 순서만 기억
   • 모르는 숫자는 즉석 추정 금지 — '어떻게 측정할지'로 답하기
   • 범위 넓히면 한 줄 티저로 피벗: 'I hit a similar boundary problem in our gateway...'
   • 역질문 준비: 'How does Opendoor handle the offer-accept-to-payment boundary today?'
   🗣 이 스테이지 여는 문장

   “That's the core of it — happy to go deeper anywhere you'd like.”

   checking microphone…

소재 보강: ERP-MES 스토리 · STAR (impact) · 피벗 카드: gateway, multi-plant, validation