콜로세움 1차 비대면 면접 — 셀프 CS 질답 리스트 (2026-06-10 20:00 슬롯)

1. 회사 컨텍스트 & 도메인 추정

확인된 시그널 (출처 명시)

• 사업 도메인: 글로벌 3PL 풀필먼트 + AI 기반 물류 SaaS 'COLO AI' — OMS(주문관리) + WMS(창고관리) + TMS(운송관리) 통합 단일 플랫폼. (colosseum.kr blog, colosseum.global SCM 노하우)
• 규모/성장: 2019년 설립, 80명+ 임직원 중 R&D 40% (40명 추정), 국내외 53개 물류센터 네트워크, 2025-06 시리즈B 270억 원 유치, Pre-Unicorn 지정, 2027년 IPO 도전. (invest news, ZDNet Korea, KED Global)
• 글로벌 시그널: Asan Voyager 선정 (한국 스타트업 미국 진출 지원), 日 다이와코퍼레이션 MOU. (venturesquare)
• 조직 구조: P&E (Product & Engineering) / S&O / PM / BM 4개 Division. 면접 포지션 = P&E Backend Engineer. (colosseum.global hiring)
• 기술 리더십 시그널: P&E Dev2 Manager가 Kotlin/Java API + 마이크로서비스 9년 경력으로 표기됨 — Kotlin/Java + MSA 스택 추정 강 신호. (getprog.ai profile)

도메인 추정 (추정/예상 마커)

• 추정 1: COLO 시스템은 MSA 구조 — OMS/WMS/TMS가 별도 서비스로 분리되어 이벤트 기반 통신할 가능성 높음. 풀필먼트 도메인 특성상 주문 생성 → 재고 차감 → 피킹/패킹 → 출고 → 배송 흐름 전반에 분산 트랜잭션·idempotency가 핵심.
• 추정 2: 53개 물류센터 + 다이와 글로벌 연동 → 멀티 리전/멀티 테넌트 데이터 모델 필요. 셀러·창고·캐리어 3-side 마켓플레이스.
• 추정 3: AI 솔루션 언급 → ML 추론 파이프라인·데이터 적재(Kafka/Kinesis 추정) 영역도 P&E와 인접.
• 추정 4: 채용 페이지에 구체 스택 미공개 — colosseum.career.greetinghr.com 리다이렉트만 존재. 면접에서 현재 스택 확인 역질문 권장.

(추정 근거 기반: 풀필먼트 동종 업계 통념 + LinkedIn 리더십 스택 시그널. 면접 중 직접 검증 필수.)

2. 본인 카드 연결 표 (★ 매칭 자료)

면접 답변에 즉시 끌어다 쓸 본인 카드:

★ 표시 질문 = 위 카드 중 1개 이상으로 직접 답할 수 있는 질문.

3. 자료구조 / 알고리즘 (6개)

기본기 검증 + 풀필먼트 도메인 사례 매칭.

1. Q: 7년 차에 자료구조를 실무에서 의식적으로 고른 사례가 있었나요?
2. 의도: 후보가 자료구조를 "면접용 지식"으로만 알고 있는지 vs 실 의사결정에 쓰는지 분리.

3. Hook: ★ TMS 워커에서 작업 큐를 ConcurrentLinkedQueue + 우선순위 형태로 다룬 사례. "기본은 BlockingQueue, 우선순위가 필요해서 PriorityBlockingQueue로 갈아탔다" 식 결정 narrative.

4. Q: HashMap과 ConcurrentHashMap의 차이, 그리고 ConcurrentHashMap이 어떻게 lock-free에 가깝게 구현되는지?

5. 의도: JVM/동시성 동시 검증, CAS·세그먼트(Java 7) → 노드 기반(Java 8) 진화 알고 있는지.

6. Hook: "Java 8부터 synchronized 블록 + CAS로 노드 단위 락" 한 줄 + size()가 정확하지 않은 이유.

7. Q: 100만 건의 주문 중 미배송 건만 빠르게 조회해야 하면 어떤 자료구조/인덱스 전략을 쓰겠어요?

8. 의도: 도메인(풀필먼트) 적용 + DB 인덱스 사고력 동시 검증.

9. Hook: 부분 인덱스(Postgres) 또는 status별 복합 인덱스((status, created_at)). 카디널리티 낮을 때 인덱스 우회 가능성 언급.

10. Q: 정렬 알고리즘 중 실무에서 자주 마주치는 변형이 있다면?

11. 의도: Timsort(Java Arrays.sort 객체 정렬)·외부정렬·stable sort 필요성 인지.

12. Hook: Collections.sort가 Timsort라 partially sorted 데이터에 O(n) 가까이 수렴. 안정 정렬이 필요한 사례(다중 키 정렬) 1개.

13. Q: LRU 캐시를 직접 구현한다면? Java 표준 라이브러리는 어떻게 쓰나요?

14. 의도: LinkedHashMap(access order) 활용 인지 + 동시성 보강 방식.

15. Hook: LinkedHashMap.removeEldestEntry override 또는 Caffeine maximumSize. 동시성 필요 시 Collections.synchronizedMap vs Caffeine 차이.

16. Q: ★ 도메인 이벤트 30종을 한 클래스에서 분기하는 거대한 switch가 있다면 어떻게 리팩토링할까요?

17. 의도: OOP·DDD 감각 + 변경에 닫혀 있는 구조 인지.
18. Hook: 전략 패턴 + Map<EventType, Handler> 등록. ★ TMS 워커에서 작업 타입별 handler 분리 경험으로 잇기.

4. 네트워크 (7개)

HTTP/2·gRPC·idempotency·LB — MSA + 글로벌 동기 통신 가정.

1. Q: HTTP/1.1과 HTTP/2의 차이, 어떤 상황에서 HTTP/2가 의미가 있나요?
2. 의도: 멀티플렉싱·헤더 압축(HPACK)·서버 푸시 인지 + 실무 적용 판단.

3. Hook: 동일 origin에 많은 작은 요청(SPA 자산, MSA API 게이트웨이) 시 HTTP/2 + ALPN. HTTP/1.1 keep-alive 한계(head-of-line).

4. Q: gRPC를 안 써본 후보라면 — Protobuf의 forward/backward compatibility 규칙 설명해보세요.

5. 의도: 스키마 진화 + MSA 운영 감각.

6. Hook: 필드 번호 고정, 새 필드는 optional, 삭제 시 reserved 표기. wire format은 tag-length-value라 unknown 필드 무시 가능.

7. Q: ★ 결제·주문 API를 외부에 노출할 때 idempotency를 어떻게 보장하나요?

8. 의도: 도메인 핵심 + 실무 경험 검증.

9. Hook: idempotency key + DB unique 제약 + 결과 캐싱. ★ TMS 워커에서 중복 처리 방지 위해 (job_id, attempt) unique 사용한 사례.

10. Q: L4 / L7 로드밸런서 차이, 그리고 Sticky session이 필요한 상황은?

11. 의도: 네트워크 계층 인지 + stateless 설계 압력 이해.

12. Hook: L4=TCP/UDP, L7=HTTP 헤더 기반. WebSocket·세션 일관성이 깨질 때만 sticky. 가능하면 stateless + Redis 세션이 우선.

13. Q: WebSocket과 SSE(Server-Sent Events) 중 풀필먼트 현장 PDA 알림 시스템에 무엇을 고르겠어요?

14. 의도: 단방향 vs 양방향 트레이드오프, 도메인 적용 사고.

15. Hook: 알림만이면 SSE(HTTP/1.1 호환·재연결 표준). PDA에서 서버로 스캔 이벤트 양방향 필요하면 WebSocket. 모바일 네트워크 끊김 대응이 가장 중요.

16. Q: TLS handshake가 왜 비싼가요? mTLS는 언제 쓰나요?

17. 의도: TLS 1.2 vs 1.3 round trip + 보안 계층.

18. Hook: TLS 1.3은 1-RTT(0-RTT 옵션). MSA 내부 서비스 인증에 mTLS — 서비스 메시(Istio) 자동화.

19. Q: 외부 캐리어 API에 timeout 500ms로 설정했는데 간헐적으로 retry가 5번까지 일어나면 어떤 문제가 생길 수 있나요?

20. 의도: retry storm·idempotency·circuit breaker 동시 검증.
21. Hook: backoff + jitter, circuit breaker(half-open), idempotency key. retry는 멱등 보장이 선행 조건.

5. 데이터베이스 (7개)

풀필먼트 = 재고·주문·정산. 트랜잭션 격리·복제 지연·N+1 핵심.

1. Q: ★ @Transactional의 격리 수준 기본값과, 본인이 격리 수준을 명시적으로 바꾼 사례?
2. 의도: ACID 깊이 + 실 운영 경험.

3. Hook: 기본 Isolation.DEFAULT(DB default). MySQL=REPEATABLE READ, Postgres=READ COMMITTED. ★ 정산 일치성 작업에서 SERIALIZABLE 고려했지만 deadlock 빈도로 어드바이저리 락 + READ COMMITTED 조합으로 우회한 사례.

4. Q: 재고 동시 차감(여러 셀러가 동일 SKU)을 어떻게 풀까요?

5. 의도: 도메인 핵심 + 락/CAS 사고.

6. Hook: SELECT FOR UPDATE(비관적) vs version 컬럼(낙관적) vs Redis 분산락. 핫 SKU는 큐로 직렬화. 재고 0 처리 별도 이벤트.

7. Q: MySQL InnoDB와 PostgreSQL의 MVCC 구현 차이는?

8. 의도: 단순 암기가 아닌 vacuum/undo 운영 영향까지.

9. Hook: MySQL=undo log 기반 → long transaction이 undo 부풀림. Postgres=tuple version → autovacuum이 dead tuple 정리. 둘 다 long-running tx가 같은 통증을 다른 부위에 만든다.

10. Q: ★ N+1 문제, JPA에서 어떻게 진단하고 해결하나요?

11. 의도: 실무 빈출 + 도구 친숙도.

12. Hook: p6spy·hibernate statistics·spring.jpa.show-sql. 해결은 @EntityGraph·fetch join·DTO projection. ★ 부릉에서 운송 리스트 + 화주 정보 한 화면 조회 시 fetch join + LIMIT/OFFSET 충돌 → DTO projection으로 분리한 사례.

13. Q: 인덱스를 추가하면 무조건 빨라지나요? 거꾸로 느려지는 사례?

14. 의도: 인덱스 비용·옵티마이저 추정 인지.

15. Hook: write 비용·인덱스 미사용 시 cardinality 통계 stale로 인한 잘못된 plan. 카디널리티 낮으면 풀스캔이 더 빠른 경우 + FORCE INDEX 임시 해결과 통계 갱신.

16. Q: Read Replica의 복제 지연(replica lag)이 사용자에게 어떻게 노출될 수 있고, 어떻게 완화하나요?

17. 의도: 분산 DB 운영 감각.

18. Hook: "주문 직후 미러 페이지에 안 보이는" 클래식 케이스. write-after-read 경로는 primary로, 또는 sticky cursor(GTID 기반)·세션 hint.

19. Q: 풀필먼트의 정산 영역에 SAGA 패턴을 도입한다면 어떤 단계에 보상 트랜잭션이 필요할까요?

20. 의도: 분산 트랜잭션 + 도메인 적용 동시.
21. Hook: 주문 생성 → 재고 hold → 결제 → 출고 → 정산. 각 단계 실패 시 보상(재고 release, 환불, 정산 reverse). orchestration vs choreography 트레이드오프 — 풀필먼트는 orchestration이 추적 쉬움.

6. JVM / Spring (7개)

7년 BE 시니어에게 가장 깊게 들어올 가능성 높은 축.

1. Q: JVM 메모리 구조(heap·metaspace·stack·direct)를 간단히 설명해보세요. 어떤 OOM이 가장 흔한가요?
2. 의도: 기본기 + 운영 감각.

3. Hook: heap 영역(young/old)·metaspace(클래스 메타)·direct(NIO)·thread stack. 흔한 OOM은 java.lang.OutOfMemoryError: Java heap space — 누수 후보는 cache·정적 컬렉션·classloader leak.

4. Q: G1GC와 ZGC의 차이, 둘 중 어떤 워크로드에서 어느 쪽을 고르나요?

5. 의도: 최신 GC 흐름 + 실 선택 사고.

6. Hook: G1=region 기반·STW 짧음·throughput·heap 큰 워크로드. ZGC=sub-ms pause·매우 큰 heap·latency 민감. Spring Boot 3 + JDK 21이면 ZGC generational 옵션 검토.

7. Q: ★ Spring @Transactional이 private 메서드에 안 먹히는 이유, 그리고 self-invocation 함정?

8. 의도: AOP 프록시 모델 정확히 이해.

9. Hook: CGLIB/JDK proxy는 외부 호출만 가로챔. self-invocation 시 AopContext.currentProxy() 또는 동일 클래스 분리. ★ 부릉에서 트랜잭션이 안 걸려서 추적 1시간 → self-invocation으로 결론 난 사례 있으면 자연스럽게.

10. Q: Spring Boot 부팅 과정에서 @Autowired 의존성 주입이 어느 시점에 일어나나요?

11. 의도: Bean 생명주기 + 순환 의존성 디버깅 인지.

12. Hook: BeanFactory → BeanDefinition 로딩 → 인스턴스화 → property/autowire 주입 → BeanPostProcessor(pre/post) → InitializingBean.afterPropertiesSet → ready. 순환 의존성은 setter 주입 또는 @Lazy.

13. Q: Spring AOP와 AspectJ의 차이, 그리고 메서드 진입 횟수 카운트하는 어드바이스를 어떻게 짤까요?

14. 의도: AOP 정확한 모델 + 메트릭 코드 감각.

15. Hook: Spring AOP=프록시 기반(메서드 단위, 외부 호출만). AspectJ=바이트코드 위빙(필드·생성자·private 가능). @Around + Micrometer counter.

16. Q: CompletableFuture와 Project Reactor 중 어떤 걸 골라야 하는 상황이 있을까요?

17. 의도: 비동기 모델 차이 + Spring WebFlux 선호 분리.

18. Hook: CF=단일 값·blocking 호출 합성. Reactor=스트림·backpressure·WebFlux 전체 스택. 부분 도입은 멘탈 부담 크니 팀 단위 결정이 맞다는 판단 추가.

19. Q: Kotlin coroutine과 Java virtual thread(JDK 21+) 중 무엇을 고르겠어요?

20. 의도: 최근 JDK 흐름 + Kotlin 친화도(콜로세움 스택 시그널).
21. Hook: virtual thread는 기존 blocking 코드 그대로 + 경량 스레드. coroutine은 structured concurrency + suspend 문법 — 명시적 취소·예외 전파 강함. 신규 Kotlin 스택이면 coroutine이 자연스러움.

7. 시스템 디자인 (7개)

풀필먼트 도메인 가중치. ★ 다수.

1. Q: ★ 풀필먼트 주문 시스템을 설계하세요. 셀러가 주문을 등록하면 창고 PDA까지 흐르고, 출고 결과가 셀러에게 알림됩니다.
2. 의도: 도메인 직접 사고 + MSA 분해.

3. Hook: OMS(주문 수집) → 이벤트(Kafka/SQS) → 재고 hold(WMS) → 피킹 큐 → 출고 → TMS → 알림(Webhook/Push). 각 경계에 idempotency key. ★ 부릉 TMS 흐름과 거의 1:1 대응이라 경험적으로 답변 가능하다고 톤 잡기.

4. Q: ★ 다수의 셀러가 동시에 동일 SKU 재고를 차감할 때 race condition을 어떻게 해결하나요?

5. 의도: 동시성 + DB + 분산 시스템 종합.

6. Hook: 비관적 락 vs 낙관적 락 vs 큐 직렬화 + Redis 분산락. 핫 SKU는 큐로 직렬화 + 단일 워커가 가장 단순. ★ TMS 워커에서 작업 단위 직렬화 경험.

7. Q: 풀필먼트 API에 rate limit을 도입한다면 어떤 알고리즘과 저장소를 쓸까요?

8. 의도: 알고리즘 + 분산 환경.

9. Hook: token bucket vs sliding window. 분산은 Redis Lua 스크립트로 원자성. 셀러별·키별·엔드포인트별 다층 구조.

10. Q: 알림(셀러에게 출고 완료) 시스템에서 메시지 큐로 Kafka/SQS/RabbitMQ 중 무엇을 고르고, 그 이유는?

11. 의도: 메시지 큐 차이 정확히 + 트레이드오프.

12. Hook: Kafka=로그·재처리·고처리량. SQS=관리 비용 낮음·AWS lock-in 허용 시. RabbitMQ=routing·priority queue 풍부. 알림은 retention 짧고 fan-out 적음 → SQS도 충분. 데이터 파이프라인까지 보면 Kafka.

13. Q: ★ 캐시 invalidation 전략 — 재고 캐시가 stale하면 어떤 일이 일어나나요?

14. 의도: 캐싱의 어려움 인지.

15. Hook: 오버셀(과판) → 환불 비용. write-through + short TTL + 결정 시점은 DB read. 읽기 캐시는 disposable이라는 원칙. ★ TMS에서 운송 리스트 캐시했다가 stale 이슈 본 사례.

16. Q: 글로벌 다이와 연동(일본)을 가정할 때, 시간대·통화·인보이스 포맷 차이를 어떻게 모델링하나요?

17. 의도: 글로벌화 + 도메인 모델링 감각.

18. Hook: 시간은 항상 UTC + 표시 시점 변환. 통화는 금액 별도 + currency code + 정산 시점 환율 스냅샷. 비즈니스 시점/환율은 immutable 스냅샷이 안전.

19. Q: ★ 풀필먼트 SaaS의 멀티 테넌시를 어떻게 설계할까요?

20. 의도: SaaS 도메인 핵심 + 격리/비용 트레이드오프.
21. Hook: schema-per-tenant vs row-level(tenant_id). 53개 창고면 row-level + 적극적 인덱스가 운영 단순. 대형 셀러는 별도 DB로 분리 가능 — hybrid 전략.

8. 동시성 / 멀티스레딩 (5개)

★ TMS 워커 직접 연결.

1. Q: synchronized·ReentrantLock·AtomicInteger 세 가지의 차이와 어디에 쓸지?
2. 의도: 동시성 기본 + 비용 인지.

3. Hook: synchronized=언어 차원·monitor enter/exit·JIT 최적화 잘 됨. ReentrantLock=tryLock·fair·condition. AtomicInteger=CAS·lock-free·짧은 critical section. 대부분 synchronized로 충분, 명시적 락은 condition이 필요할 때.

4. Q: ★ Thread pool 크기는 어떻게 정하나요? 부릉 TMS 워커에서 어떻게 했나요?

5. 의도: 실 경험 검증 + Little's law 인지.

6. Hook: CPU bound = N(cores). I/O bound = N × (1 + wait/compute). ★ TMS 워커는 외부 API 호출 비중이 커서 50-100 스레드 풀로 운영, 큐 백프레셔는 LinkedBlockingQueue 한계 + RejectedExecutionHandler로.

7. Q: CompletableFuture.allOf와 anyOf 차이, 그리고 부분 실패 시 어떻게 처리하나요?

8. 의도: 비동기 합성 + 예외 처리.

9. Hook: allOf는 모든 결과 합성·하나 실패 시 전체 예외. 각 future에 exceptionally 또는 handle 부착해 부분 실패 허용. 완전한 fan-out + 부분 허용 패턴은 CompletableFuture<List<Either<Error, T>>>.

10. Q: ★ 같은 작업이 두 워커에서 동시에 처리되는 걸 막으려면?

11. 의도: 분산 락·idempotency 동시.

12. Hook: DB unique 제약(작업 id) 또는 Redis SET NX EX. ★ TMS 워커에서 (job_id, lease_until) 패턴 + 워커 죽으면 lease 만료로 다른 워커가 인계. 단순 락보다 lease가 운영에 강함.

13. Q: Kotlin coroutine의 Dispatchers.IO와 Dispatchers.Default 차이, 어디에 어떤 걸 쓰나요?

14. 의도: Kotlin 친화도(콜로세움 스택).
15. Hook: Default=CPU bound·스레드 풀 작음(cores). IO=blocking I/O·필요 시 확장. blocking DB 호출·OkHttp 동기 호출은 IO. virtual thread가 나오면 이 구분도 줄어들 가능성.

9. 인프라 / 배포 (5개)

★ EKS 셀프서비스 직접 연결.

1. Q: ★ K8s에서 Pod이 갑자기 죽는 이유 5가지를 말해보세요.
2. 의도: 운영 경험 + 디버깅 깊이.

3. Hook: OOMKilled(memory limit), Evicted(node pressure), Liveness fail, CrashLoopBackOff(앱 자체), Node 자체 죽음. ★ EKS 셀프서비스에서 가장 많이 받았던 문의가 OOMKilled — requests/limits 가이드 + JVM -XX:MaxRAMPercentage 정책 정리한 경험.

4. Q: ★ EKS와 ECS의 차이, 본인은 왜 EKS를 골랐나요?

5. 의도: 클라우드 운영 의사결정.

6. Hook: EKS=K8s 표준·생태계·learning curve 비용. ECS=AWS native·운영 단순·lock-in. ★ 부릉에서 EKS를 고른 이유는 팀 단위 셀프서비스가 필요했고, K8s 생태계(ArgoCD·Prometheus)가 그 형태에 더 맞아서.

7. Q: 배포 전략(blue-green, canary, rolling) 중 풀필먼트 OMS 배포에 무엇을 권하시겠어요?

8. 의도: 도메인 + 운영 사고.

9. Hook: 주문 처리 중단이 비용 큼 → rolling + readiness probe + graceful shutdown(preStop). 신규 기능은 canary + feature flag. blue-green은 stateful 마이그레이션 비용이 커서 OMS엔 잘 안 맞음.

10. Q: 관측성(observability) 3축 — 로그·메트릭·트레이스 — 각각 어떤 도구를 쓰셨고, 가장 가치 있었던 한 가지는?

11. 의도: 운영 깊이 + 의견 보유.

12. Hook: 로그=Loki/CloudWatch, 메트릭=Prometheus + Grafana, 트레이스=Jaeger/X-Ray. 분산 추적이 가장 비싸지만 MSA 도입 후 ROI 가장 큼 — "어디서 시간이 걸렸는가"를 정확히 알려줌.

13. Q: ★ CI/CD 파이프라인에서 풀필먼트처럼 재고가 살아있는 서비스를 안전하게 롤백하는 절차는?

14. 의도: stateful 시스템 배포 감각.
15. Hook: 코드 롤백은 kubectl rollout undo로 빠름. DB 스키마 변경은 expand-contract(forward compatible) — 롤백을 항상 가능 상태로 유지. ★ EKS 셀프서비스 표준 가이드에 destructive migration 금지 룰 추가했던 경험.

10. 도메인 specific 추정 질문 (5개)

수집 시그널 기반 추정. 면접관 의도 자체가 도메인 fit 보는 것이므로 답하기보다 질문 흐름 끌기 권장.

1. Q: (추정) 셀러가 주문 1만 건을 일괄 업로드합니다. 어떻게 처리하시겠어요?
2. 의도: 벌크 처리 + 비동기 + idempotency.

3. Hook: 동기 응답은 접수 확인만, 실 처리는 비동기 큐. chunk 단위 처리 + 진행률 조회 API. 실패 row만 재시도 가능하게 row-level 결과 저장.

4. Q: (추정) 창고 PDA가 오프라인 상태로 스캔한 데이터를 나중에 동기화합니다. 충돌을 어떻게 해결할까요?

5. 의도: 오프라인 우선(Offline-First) 설계 + CRDT/타임스탬프.

6. Hook: 기기별 monotonic id + 서버 정렬. 재고 차감 같은 critical 이벤트는 서버 확정 시점에 검증 — 오프라인 시점 idempotency key가 충돌이면 서버가 거절하고 PDA에 정정 알림.

7. Q: (추정) 다이와 글로벌 연동에서 외부 API 스펙이 자주 바뀝니다. 어떻게 변화에 강한 통합층을 만드나요?

8. 의도: 외부 통합 패턴.

9. Hook: Anti-Corruption Layer — 외부 모델 ↔ 내부 모델 어댑터 분리. 계약 테스트(Pact) + 통합 환경 모니터링 + 알림. 외부 변경을 내부에 전염시키지 않는 것이 핵심.

10. Q: (추정) AI 추론 결과(예: 출고 시간 예측)를 OMS에 반영합니다. 추론 실패 시 fallback은?

11. 의도: ML 시스템 + 안정성.

12. Hook: 추론은 항상 fallback 가능한 기본값과 함께. 추론 결과를 캐시 + TTL, 실패 시 룰 기반 추정으로 회귀. AI는 disposable이라는 원칙.

13. Q: (추정) 53개 물류센터에서 들어오는 실시간 이벤트를 어떻게 한 곳에서 집계하나요?

14. 의도: 이벤트 스트리밍 + 데이터 인프라.
15. Hook: Kafka topic per 이벤트 종류 + Flink/Kafka Streams로 집계. 또는 더 단순하게 센터별 producer → 중앙 topic → 컨슈머 그룹. 운영 비용 보면 처음엔 단순 SQS + Lambda도 합리.

11. 면접관 역질문 카드 (4개)

phase 2 인터뷰 raw + 본인 가치 기준 반영.

1. (R&R) P&E Division 안에서 OMS·WMS·TMS 팀이 분리되어 있나요, 아니면 풀스택 BE가 횡단합니까? 그리고 신규 입사자가 처음 6개월간 가장 많이 만나는 도메인은 어디일까요?

2. 왜: 본인이 "어디에 배치될지"가 직접적 매칭. 부릉 TMS 경험이 어디에 가장 잘 살아날지 검증.

3. (기술 의사결정) Kotlin/Java + MSA로 추정하고 있는데, 신기술 도입(예: virtual thread, Kotlin coroutine, ZGC)은 누가 어떤 사이클로 결정하나요?

4. 왜: 의사결정 권한 분포와 실험 문화 검증. 시니어로서 실험 권한이 있는지가 6개월 임팩트의 전제.

5. (도메인 깊이) "실재하는 마찰을 직접 줄이는 제품"에 공감해서 지원했는데, 콜로세움에서 셀러/창고 운영자가 가장 자주 마주치는 마찰 1순위는 무엇인가요? 그게 P&E가 푸는 문제인가요, 아니면 S&O가 푸는 문제인가요?

6. 왜: 본인 가치 기준(yhs-profile §3)에 직접 연결. 기능 페인이 BE에 닿는지를 확인.

7. (IPO/성장) 2027년 IPO를 목표로 한다고 들었는데, 그 시점까지 P&E가 가장 크게 변할 영역은 어디일까요? (예: 글로벌 멀티 리전, 정산 시스템 강화, 데이터 인프라)

8. 왜: 본인의 3년 임팩트 영역을 사전에 그려보기 위함. 부릉에서 본 적 있는 흐름이 여기서도 반복될지 확인.

12. 오늘 20:00-21:00 슬롯 운영 가이드

우선순위 순서

1. 시스템 디자인 (§7) + DB (§5) + JVM/Spring (§6) — 시니어 대상 핵심 영역. ★ 표시 우선.
2. 동시성 (§8) + 인프라 (§9) — TMS·EKS 카드 직접 연결.
3. 네트워크 (§4) — idempotency·WebSocket만이라도.
4. 자료구조 (§3) + 도메인 추정 (§10) — 시간 남으면.

답변 위험 패턴 (재확인)

• narrative 재현 금지 → "그때 그런 일이 있어서…" 대신 현재 의사결정 톤.
• 강점 평가절하 금지 → "잘 모르겠어요" 대신 "세 가지 옵션 중 X를 골랐고, 이유는…".
• 수동 마무리 금지 → 답변 끝에 "이 부분은 콜로세움에서는 어떻게 푸시나요?" 역질문으로 전환.
• flattery 금지 → "좋은 회사라서" 대신 구체 시그널 1개 인용.

출처: yhs-interview-raw, yhs-profile, feedback_interview_answer_risks.

13. 참고

• 콜로세움 1차 비대면 면접 준비 (6/11) — 본 문서의 모(母) 문서.
• yhs-profile — 정체성·강점·가치.
• yhs-strength-cases — 예약배송·구독 정산 강점 사례 raw.
• 2026-05-22 채널톡 면접 시뮬레이션 — 위험 패턴 5종 원전.
• 2026-05-24 네트워크 HTTP/2·WebSocket·TLS — 네트워크 영역 복습 자료.
• 2026-05-23 OS·DB CS 면접 — DB·동시성 복습.
• 2026-05-24 DB 인덱스·네트워크 — 인덱스 깊이 복습.
• Neural VRP 산업 적용 현황 — 콜로세움 면접 사이드 트랙 리서치.

외부 출처

• 콜로세움 공식 블로그 (colosseum.kr)
• 콜로세움 채용 (colosseum.global)
• Invest News — 270억 시리즈B (2025)
• KED Global — 글로벌 확장
• P&E Dev2 Manager LinkedIn 시그널

복습 일정