콜로세움 면접 CS 웜업 (2026-06-10) — 답변 라인 회고

Context

• 2026-06-11(목) 14:00 콜로세움 코퍼레이션 [P&E] Backend Engineer 1차 비대면 면접 대비 D-1 세션.
• 회사 = 풀필먼트 SaaS (OMS+WMS+TMS 통합 COLO AI). 부릉 TMS 도메인 직격.
• 운영 패턴: jini=면접관/코치 모드, wansu=답변 다듬기. 항승=답변 화자.
• 진행: 20:30~21:30 슬롯에서 동시성 → 트랜잭션 isolation → 멱등성 → 외부 의존성 fallback → DLQ/Saga → 워커 동시성 + stuck job 6 카드 소화.
• 본 회고는 2025-06-11 면접 직전 다시 펼쳐 보기 위한 답변 라인 보존 + 운영 회고 통합본.

시뮬레이션에서 닫은 6 카드 — 답변 라인

각 카드는 질문 → 본인 답변 골자 → 면접관 압박 라인 → 시니어 답변 정정형 4-층으로 압축한다.

1. TMS 워커 동시성 (claim race)

• 질문: "같은 주문에 두 워커가 붙는 충돌을 어떻게 막았나?"
• 본인 답: 미할당 row를 pull 방식으로 가져옴. 충돌 미관찰. Redis lock은 fallback 후보.
• 압박 라인: SELECT 후 UPDATE 2-step이면 race 여지. PG라면 SELECT ... FOR UPDATE SKIP LOCKED가 정석.
• 시니어 정정: "트래픽 규모에서 충돌이 안 나서 SKIP LOCKED까지 안 갔고, 지금 다시 본다면 PG 표준 패턴으로 미리 깔겠다." ← 한도 인식 + 학습 자세 둘 다 보여주는 라인.

2. @Transactional ≠ 동시성 보장

• 질문: "Spring @Transactional만 붙여도 race는 막히나?"
• 정답 라인: 아니다. 트랜잭션은 원자성·격리성 보장이지 동시 읽기 차단은 아니다. race를 막으려면 SELECT FOR UPDATE, UPDATE ... WHERE 조건 원자 한 방, 또는 @Version 낙관적 락 셋 중 하나.
• DB별 디폴트 (자주 헷갈리는 지점):
• MySQL InnoDB = REPEATABLE READ
• PostgreSQL = READ COMMITTED
• 결론은 동일 — 디폴트로는 race 못 막는다. PG는 SERIALIZABLE까지 올려야 진짜 직렬화.
• 항승 카드: TMS 엔진=PG, TMS 매니저 서버=MySQL. 답변은 엔진 PG 기준으로 일관 — 매니저 MySQL 섞으면 "어느 DB 얘기냐" 파고듦.

3. 멱등성 — "중복 방지"와 "응답 일관성" 분리

• 질문: "외부 콜백/주문 수신 중복 시 같은 요청을 두 번 처리하지 않게 어떻게 잡았나?"
• 본인 답: TMS는 클라이언트=부릉 내부 서버라 위험도 낮음. 노크 = 장바구니 id + Redis lock. 클래스101 결제/정산 = 멱등성 키 DB UK + 조회로 방지.
• 압박 라인: UK 충돌 시 2xx 응답 재현이냐, 409로 막기만이냐.
• 시니어 정정: "고객-facing이면 응답 재현까지, 내부 정합성 방지가 핵심이면 에러 응답으로 충분. 즉 비즈니스 표면에 따라 보장 수준을 달리 잡았다."
• 콜로세움 맥락 follow-up: OMS+WMS+TMS 통합 = "내부 콜이지만 외부처럼 다뤄야 하는 회색지대." 방어 라인 → "느슨하게 연결된 모듈 통합이라면 멱등성 키 + 결과 캐시로 응답 재현까지 깔 것."

4. 외부 의존성 — fallback / 차단 / circuit breaker

• 질문: "외부 의존 서비스 일시 장애 시 어떻게 복구?"
• 본인 답 (강함): 상황별로 다른 패턴 선택.
• TMS T API → OSRM → 단순 계산식 (graceful degradation, 품질 저하 감수 가능)
• 결제 PG 장애 → 사전 차단 + 안내 (UX 우선)
• 부릉 ↔ 노크 배달 대행 → circuit breaker (정합성 우선 + 본 서비스 장애 전파 차단)
• 압박 라인: silent degradation. fallback이 매끄러울수록 "문제 났는데 아무도 모르는" 상태가 진짜 무서움.
• 시니어 정정: "실패 자체는 exception 기반 모니터링으로 잡았지만, fallback 성공 후 품질 저하는 고객 문의 기반으로 대응. 지금이라면 fallback 발생률 + 결과 품질 지표 알람화." ← reactive→proactive 본인 입으로 인정.

5. DLQ — at-least-once 전제

• 질문: "비동기 메시지 처리 실패는 어떻게?"
• 본인 답: 노크=RDB-as-MQ (Axon 프레임워크, 빠른 도입). 클래스101=Kafka. DLQ=재시도 후 알람 → 온콜 수동.
• RDB-as-MQ 방어 라인: "Kafka 운영 비용 회피 + 주문 트랜잭션과 같은 begin/commit으로 묶어 결과적으로 outbox 패턴."
• outbox 한 줄 정의 = "이벤트 발행을 DB 트랜잭션 안에 같이 욱여넣는 트릭." 같은 DB에 outbox 테이블 row INSERT 원자 + 별도 워커 polling → 실제 발송.
• 항승 케이스 = 작업 큐가 outbox 테이블 역할 + 워커 polling = dispatcher. 이름만 안 붙였을 뿐 패턴은 맞음.
• 답변 라인 = "당시엔 outbox라는 용어를 쓰진 않았지만, 결과적으로 outbox 패턴이었습니다."

6. 워커 동시성 + stuck job + TTL

• 질문: "워커 여러 대일 때 같은 row 중복 소비는? 워커 죽으면 stuck job은?"
• 본인 답: Axon 프레임워크가 RDB event store + 토큰 저장소로 1차 방어. 운영상 중복 소비 관찰됨. 정합성 필요 핸들러는 idempotent, 중요도 낮은 건 throw+모니터링. version 컬럼 낙관적 락 1순위, Redis lock은 보조.
• 압박 라인: exactly-once 보장으로 포장하지 마라. at-least-once 전제로 소비자 쪽 방어.
• idempotent 처리 구체화: business key (예: order_id) 기반 현재 상태 보고 이미 목표 상태면 no-op, 아니면 상태 전이.
• 추가 압박: state-check이 원자적이냐. SELECT status → if completed return; else UPDATE = race. UPDATE ... SET status='completed' WHERE id=? AND status='pending' = 조건부 단일 UPDATE로 affected rows 검사 = 안전.
• Redis lock TTL 함정: "TTL이 처리 시간보다 짧으면 정상 처리 중 lock 만료 → 다른 워커 진입." 방어 라인 = "TTL은 여유있게 + idempotency(version + state check)로 이중 방어. Redis lock=1차 직렬화, idempotency=2차 안전망."

닫힌 답변의 중심 문장

이 6 카드를 관통하는 한 줄 = "Redis lock은 정합성 보장이 아니라 1차 직렬화. 최종 안전망은 DB version / state check / idempotency."

면접에서 이 문장이 핵심 이유 — 7년차한테 면접관이 듣고 싶어하는 것은 도구 나열이 아니라 도구 간 책임 분리. "Redis lock을 정합성 보장 수단으로 말하는 순간 TTL 만료/락 유실/DB 미반영 질문 3종 세트가 바로 따라 붙는다." (wansu 코칭 인용)

내일 웜업에서 보강할 빈 자리 — 볼륨/관측성 한 카드만

오늘 슬롯에서 의식적으로 미뤄둔 빈 자리. 면접관이 들어올 가능성이 높은 자리.

목표는 10분 안에 정리. 새 카드를 만들 필요 없이 이미 닫은 6 카드 위에 숫자 한 줄 + 도구 한 줄만 얹는 작업.

위험 패턴 5종 점검 (interview_answer_risks)

오늘 답변 라인을 다음 5종 위험 패턴과 대조한 결과:

도구 부풀리기 위험도 확인 — Axon framework 사용 시 "프레임워크가 처리 vs 우리가 추가로 깐 안전망" 분리 라인이 이미 깔려 있어 안전.

세션 운영 — 다음 면접 준비에 재활용할 자산

면접 답변 외에 운영 측면에서 명시적으로 보존할 패턴들.

A. 페르소나 R&R — 면접관 vs 다듬기

• jini = 면접관/코치 모드: 질문 던지기 + 면접관 압박 라인 예측 + 도메인 맥락(OMS↔WMS↔TMS) 깔기.
• wansu = 답변 다듬기 + 위험 차단: 한 줄 정정형 답변 + 단정 표현 차단 + DB별 디폴트 같은 미세 사실 보강.
• 둘 다 켜져 있으면 질문 → 본인 답 → wansu 정정 → jini follow-up의 4박자가 자연스럽게 돈다. 이번 세션에서 가장 효율이 좋았던 흐름.

B. 팔로우만 / 사인 프로토콜

이번 세션에서 발견한 세션 안에서 페르소나 입을 막는 신호 패턴.

• "팔로우만 해주세요" → wansu가 능동 정정 멈추고 읽기만. 답변 흐름이 너무 끊기지 않게 하는 장치.
• "사인" → 읽기 모드 해제 신호. jini한테 잘못 걸린 적 1회 발생 → 회수.
• 학습: 대상 페르소나를 명시적으로 호명하는 것이 필수 (이번에는 "@완수는 팔로우만"으로 명시했지만, jini와 wansu 모두에게 동시에 잘못 적용된 적이 있었음 → 메시지 prefix에 대상 명확화 권장).

C. 일정 슬립 보정 — 지나간 슬롯도 옮길 가치 있음

• 20:00~21:00 슬롯 → 슬립으로 인해 20:30~21:30으로 변경 요청 노트만 하고 GCal 미반영 → 이미 지난 후 회고 단계에서 사용자 직접 지적.
• 학습: 일정 변경 요청이 들어오면 즉시 calendar MCP 호출까지 갈 것. "MCP 재연결되면" 같은 deferred 표현은 위험. 회고 자료의 정합성도 떨어짐.
• 보강: GCal 디스크립션에 원래 슬롯 → 변경 슬롯 + 변경 사유를 남겨두면 회고 시점에 슬립 자체가 데이터로 남는다 (적용함).

D. 캘린더 중복 일정 — 캘린더가 다르면 1차 조회에서 놓침

• 같은 시간대(6/11 12:30~13:30) 일정 2건이 primary 캘린더와 업무(이직) 캘린더에 각각 존재 → schedule-manager가 1차 조회 시 캘린더 1개만 봐서 "중복 없음" 잘못 보고.
• 학습: 일정 중복 점검은 모든 owner 캘린더에 대해 list-events 수행해야 함. 일정 생성 시에도 카테고리=이직이면 업무 캘린더로 통일 룰 재확인.

Action Items

• [ ] 내일 12:30 웜업: 볼륨/관측성 카드 10분 정리 (위 표 3행).
• [ ] 면접 시작 30분 전 이 문서 다시 열기 → 6 카드 정정형 답변 한 번씩 음독.
• [ ] 면접 후: 실제 질문 vs 시뮬레이션 카드 적중률 회수 회고 (별도 doc).

참조

• 면접 준비 본문서 — learning/2026-06-11-colosseum-interview-prep.md
• CS 53문항 리스트 — learning/2026-06-10-colosseum-cs-questions.md
• 채널톡 면접 회고 (선행 교훈) — learning/2026-05-27-channeltalk-interview-retrospective.md
• Redis 분산락 정합성 (직전 학습) — learning/2026-05-22-redis-lock-db-commit-mismatch.md