[초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업

이 트랙의 경험 요약

NHN NSC슬롯팀 2024.06 ~ 2025.11 슬롯 게임 백엔드 경험 기반 질문 은행으로, 슬롯 엔진 추상화·RCC 시스템 설계·동시성 처리·성능 최적화·AI 도구 도입 5개 주제를 커버한다.
CJ 올리브영 커머스플랫폼 웰니스개발팀 면접의 도메인 모델링, 캐싱 전략, 비동기 처리, 대용량 처리 역량 검증 영역과 직접 매핑되도록 설계되었다.
각 질문은 후보자의 실제 경험 증거(SlotTemplate/BaseSlotService, RCC, StampedLock, AliasMethod, Cursor Rules)를 기반으로 구성되었으며, 면접관 의도와 압박 방어 포인트를 포함한다.

메인 질문 1. 슬롯이 5종 이상 쌓인 시점에 SlotTemplate과 BaseSlotService를 도입해 엔진을 추상화했다고 하셨는데, 그 설계 결정의 배경과 구체적인 구조를 설명해 주세요.

면접관이 실제로 보는 것

반복 경험 후 추상화 타이밍을 판단하는 설계 감각이 있는지, 즉 과도한 사전 설계와 지연된 리팩터링 사이의 균형을 실무에서 어떻게 잡는지 평가한다.
인터페이스와 추상 클래스를 실제 문제 해결에 어떻게 적용했는지, 특히 Java의 interface default 메서드 한계를 인지하고 구조를 선택했는지 확인한다.

실제 경험 기반 답변 포인트

슬롯 5종 이상 구현 후 라인·웨이·클러스터 세 가지 페이 방식이 공통 추상화 축임을 발견했다. 처음부터 추상화하면 잘못된 경계를 그을 가능성이 높아 반복을 충분히 경험한 뒤에 설계했다.
SlotTemplate으로 페이 방식 자체를 추상화해 슬롯마다 직접 구현하던 페이 계산을 PayCalculator 주입으로 전환했다. 슬롯은 getPayCalculator()만 반환하면 되고, 페이에 참여하지 않는 심볼 처리도 이 레이어에서 어드민 설정으로 관리하도록 추가했다.
SlotService 인터페이스에 default 구현이 점점 늘어나는 문제를 BaseSlotService 추상 클래스로 해소했다. Java interface default는 상태를 가질 수 없어 스프링 빈 주입이 필요한 공통 로직을 수용할 수 없었다.
ExtraConfig 생성 책임을 SlotConfigFactory에서 각 슬롯 서비스로 이동해 새 슬롯 추가 시 팩토리 코드를 수정하지 않아도 되는 구조를 만들었다.

1분 답변 구조

상황: 슬롯 5종 이상 구현 후 라인·웨이·클러스터 페이 계산 로직이 슬롯마다 중복 구현되고 있었고, SlotService 인터페이스에 default 구현이 늘어나 테스트 가능성이 떨어지고 있었다.
결정: 반복을 충분히 경험한 뒤에야 올바른 공통점이 보인다는 판단으로, SlotTemplate으로 페이 방식을 추상화하고 BaseSlotService로 공통 구현을 추출했다. ExtraConfig 생성 책임도 팩토리에서 각 슬롯 서비스로 이동했다.
결과: 새 슬롯 추가 시 슬롯 특화 로직만 구현하면 되고, 기존 슬롯 코드를 건드리지 않는 확장 구조가 완성됐다. 이후 AI 에이전트가 신규 슬롯을 구현할 때도 이 구조가 참조 코드로 활용됐다.

압박 질문 방어 포인트

"왜 처음부터 추상화하지 않았나요?" → 처음부터 추상화하면 잘못된 경계를 그을 가능성이 높다. 실제로 여러 슬롯을 직접 만든 뒤에야 페이 방식이라는 올바른 추상화 축이 보였다. 이른 추상화의 비용이 반복 구현의 비용보다 더 크다고 판단했다.
"인터페이스 대신 추상 클래스를 선택한 이유가 무엇인가요?" → Java의 interface default 메서드는 상태를 가질 수 없다. 공통 구현에 스프링 빈 주입이 필요한 상태 있는 로직이 포함되어 있어 추상 클래스가 적합했다. 인터페이스는 계약 정의 역할로 유지하고, 공통 구현은 추상 클래스에 두는 계층 구조를 선택했다.

피해야 할 약한 답변

"공통 로직이 있으면 무조건 추상화하는 것이 좋다" — 추상화 타이밍과 근거 없이 일반론만 말하는 답변으로, 왜 그 시점이었는지 설계 의도가 없다.
"슬롯마다 코드가 중복되어 있어서 정리했다" — 중복 제거 외에 페이 방식 추상화, ExtraConfig 책임 이동, 테스트 가능성 개선 등 설계 결정의 맥락이 빠진 답변이다.

꼬리 질문 5개

F1-1. WayPayCalculator를 INSTANCE 싱글턴으로 만든 이유는 무엇인가요? 멀티스레드 환경에서 상태가 없다는 걸 어떻게 보장했나요?

F1-2. SlotTemplate에 '페이에 참여하지 않는 심볼' 기능을 추가했는데, 이 요구사항이 슬롯별 처리가 아닌 추상 레이어에 있어야 했던 이유는 무엇인가요?

F1-3. BaseSlotService에서 추상 메서드로 선언한 것과 기본 구현을 제공한 것을 어떤 기준으로 구분했나요?

F1-4. ExtraConfig 책임을 팩토리에서 서비스로 이동했을 때, 기존 슬롯들을 마이그레이션하는 과정에서 어떤 어려움이 있었나요?

F1-5. slot-config-model 모듈로 Config 응답 객체를 분리한 이유가 메타 서비스 이관 준비라고 하셨는데, 실제 이관은 어느 단계까지 진행됐나요?

메인 질문 2. RTP 보장을 위해 스핀 결과를 미리 캐시하는 RCC 시스템을 직접 설계하셨는데, 핵심 아키텍처 결정과 그 과정에서 부딪힌 가장 어려운 문제를 설명해 주세요.

면접관이 실제로 보는 것

복잡한 비즈니스 요구사항(RTP 보장)을 시스템 아키텍처로 번역하는 능력을 평가한다. 유저 경험을 해치지 않으면서 백그라운드 처리로 목표를 달성하는 비동기 설계 사고를 확인한다.
슬롯별 다른 로직을 조건 분기 없이 처리하는 인터페이스 추상화 적용 능력과, 분산 환경 동시성 처리에서 낙관적 락과 DB 유니크 키 중 상황에 맞는 선택을 했는지 확인한다.

실제 경험 기반 답변 포인트

핵심 설계: 백그라운드에서 '좋은 결과'를 미리 생성해 DB에 캐시하고, RTP 보장이 필요한 시점에 캐시에서 꺼내 제공한다. 유저 입장에서 일반 스핀과 동일하게 보인다.
비동기 설계 선택: 캐시 생성을 스핀 응답 흐름에서 완전히 분리했다. 캐시 히트 시 다음 캐시 생성을 비동기 트리거해 유저 응답 시간에 영향 없이 캐시를 미리 준비한다.
RccSpinResultAnalyzer를 인터페이스로 추상화해 슬롯별 캐시 조건 판단 로직을 조건 분기 없이 구현체 주입으로 처리했다. 슬롯 33처럼 개인화 데이터 구조가 특수한 경우도 별도 구현체로 수용했다.
동시성: 낙관적 락 검토 후 캐시 생성 충돌 빈도 특성상 DB 유니크 키 + 예외 처리 조합을 선택했다. 중복 생성 시 유니크 키 위반 예외는 다른 인스턴스가 이미 생성했다는 의미이므로 재시도 없이 넘어가면 된다.
초기 설계에서 놓친 케이스: 잭팟 처리(GameMode별 JackpotService 분기, NoOpJackpotService 필요), 시뮬레이터 캐시 생성 문제, RTP-FREE 상태 중 치환 요청 처리를 운영하며 순차 보완했다.

1분 답변 구조

상황: 순수 확률 기반 슬롯의 짧은 세션 RTP 편차 문제로 유저가 오랫동안 보상을 받지 못하는 케이스가 발생했고, 유저 경험을 해치지 않으면서 RTP를 보장하는 시스템이 필요했다.
결정: 백그라운드 비동기 캐시 생성으로 스핀 응답 흐름과 분리하고, RccSpinResultAnalyzer 인터페이스로 슬롯별 조건 차이를 수용했다. 동시성은 DB 유니크 키 + 예외 처리로 단순하게 처리했다.
결과: 슬롯 6종 대응, 유저 스핀 응답 시간 영향 없이 RTP 보장 달성. RccCacheStatisticsService로 캐시 부족 모니터링 체계도 함께 구축했다.

압박 질문 방어 포인트

"캐시가 없으면 어떻게 되나요? 유저가 계속 나쁜 결과를 받나요?" → 캐시 없음 시에는 일반 스핀 결과를 반환한다. RCC는 RTP 보장 강화를 위한 보조 수단이지 모든 스핀을 캐시로 처리하는 구조가 아니다. RccCacheStatisticsService로 캐시 부족 슬롯·베팅 인덱스 조합을 모니터링하고 생성 속도를 튜닝해 대응한다.
"DB 유니크 키로 동시성을 막는 게 충분한가요?" → 이 구조에서 중요한 건 정확히 하나의 레코드가 아니라 충분한 양의 캐시를 만드는 것이다. 중복 생성 시 예외가 발생해도 다른 인스턴스가 이미 생성했다는 의미이므로 문제가 없다. 분산 락은 단순성 대비 운영 비용이 높고 이 케이스에는 과잉이다.

피해야 할 약한 답변

"RTP 보장을 위해 좋은 결과를 미리 캐시한다" — 왜 비동기인지, 슬롯별 다른 조건을 어떻게 처리했는지, 동시성 문제를 어떻게 해결했는지 설계 근거가 전혀 없는 표면적 답변이다.
"동시성 문제는 synchronized나 분산 락으로 처리했다" — 실제 선택한 DB 유니크 키 방식의 근거가 없고, 분산 환경에서 synchronized의 한계를 모르는 답변이다.

꼬리 질문 5개

F2-1. RccCacheStatisticsService에서 캐시 부족을 감지했을 때 어떤 후속 액션을 취하도록 설계했나요? 알림인가요, 자동 생성 증가인가요?

F2-2. 슬롯 2, 7번처럼 개인화 데이터가 있는 슬롯에서 캐시 생성 시 개인화 데이터를 어떻게 처리했나요? 사용자별로 캐시가 달라지나요?

F2-3. FREE_ENTRY 캐시 조건을 '다음 상태가 BASE인 것'으로 결정한 이유는 무엇인가요? 보너스→보너스 결과를 캐시하지 않는 트레이드오프는 무엇인가요?

F2-4. 캐시 생성 판단 쿼리에 복합 인덱스를 추가했다고 하셨는데, game_id·bet_index·cache_type·used 순서로 결정한 근거는 무엇인가요?

F2-5. RTP-FREE 상태 중 치환 요청 케이스를 처음에 놓쳤다고 하셨는데, 이런 상태 전이 케이스를 다음에는 어떻게 사전에 발견할 수 있을까요?

메인 질문 3. 다중 서버 환경에서 정적 캐시 데이터를 RabbitMQ로 동기화하면서 갱신 도중 NPE가 발생했다고 하셨는데, StampedLock 도입 결정의 근거와 구체적인 설계를 설명해 주세요.

면접관이 실제로 보는 것

Java 동시성 도구(synchronized, ReentrantReadWriteLock, StampedLock)의 차이를 실무 문제에서 이해하고 상황에 맞는 선택을 할 수 있는지 평가한다.
읽기가 압도적으로 많은 캐시 구조에서 갱신 중 일관성을 보장하면서 읽기 성능을 희생하지 않는 설계 감각을 확인한다.

실제 경험 기반 답변 포인트

문제 재현: refreshAll() 중 clearAllStaticData() 완료 후 새 데이터 로드 전 다른 스레드가 조회하면 NPE 발생. 갱신은 어드민 설정 변경 시만 발생하지만, 발생 시 반드시 막아야 하는 문제였다.
StampedLock 선택 근거: 갱신 빈도가 낮고 읽기가 압도적으로 많은 구조에 적합하다. synchronized는 읽기 병렬화가 안 되고, StampedLock의 tryReadLock은 타임아웃 지정으로 갱신 완료 대기 의도를 명확하게 표현할 수 있었다.
설계: 갱신 시 writeLock으로 읽기 스레드를 차단하고, 조회 시 tryReadLock에 2.5초 타임아웃을 설정해 갱신이 완료될 때까지 대기하도록 했다. 2.5초는 갱신 작업 예상 소요 시간 기반으로 결정했다.
추가 개선: Alias 테이블을 게임별 개별 쿼리에서 IN 절 일괄 조회로 변경해 게임 수십 개 환경에서 쿼리 수를 O(n)에서 O(1)로 줄였다.

1분 답변 구조

상황: 어드민 설정 변경 → RabbitMQ 메시지 → refreshAll() 실행 중 clear 완료 후 새 데이터 로드 전에 다른 스레드가 조회하면 NPE가 발생했다.
결정: 갱신 빈도가 낮고 읽기가 압도적으로 많은 구조에 StampedLock을 선택했다. writeLock으로 갱신 구간을 보호하고 tryReadLock 2.5초 타임아웃으로 조회 스레드가 갱신 완료를 대기하도록 설계했다.
결과: 갱신 중 일시적 NPE가 완전히 해소됐고, 읽기 성능에 대한 영향이 최소화됐다. StaticDataManager 인터페이스로 데이터 타입별 init/refresh/clear 책임도 함께 분리했다.

압박 질문 방어 포인트

"2.5초 타임아웃이면 스핀 응답 시간에 영향을 주지 않나요?" → 갱신은 어드민 설정 변경 시에만 발생하고 빈도가 매우 낮다. 갱신 중 요청이 들어오는 케이스 자체가 드물고, 타임아웃 내에 갱신이 완료되면 정상 응답한다. 타임아웃이 만료되는 경우는 갱신이 예상보다 오래 걸리는 이상 상황으로, 이 경우 별도 처리 로직을 두었다.
"synchronized나 ReentrantReadWriteLock 대신 StampedLock을 선택한 이유가 무엇인가요?" → synchronized는 읽기 병렬화가 불가능해 읽기 압도적인 구조에서 불필요한 직렬화가 발생한다. StampedLock의 tryReadLock 타임아웃 지정이 갱신 완료 대기라는 설계 의도를 더 명확하게 표현했다.

피해야 할 약한 답변

"synchronized를 쓰면 해결된다" — 읽기 병렬화 포기, 읽기 압도적인 캐시 구조에서 성능 트레이드오프를 인식하지 못한 답변이다.
"StampedLock이 빠르다고 해서 썼다" — 낙관적 읽기와 tryReadLock 타임아웃의 차이, 이 구조에서 타임아웃 방식을 선택한 설계 근거가 없는 답변이다.

꼬리 질문 5개

F3-1. StaticDataManager 인터페이스의 구현체가 여러 개라면 StampedLock 인스턴스를 구현체마다 가지나요, 아니면 공유하나요? 그 선택의 근거는 무엇인가요?

F3-2. tryReadLock 타임아웃이 2.5초 만료되면 어떻게 처리하도록 설계했나요? 예외를 던지나요, 아니면 기본값을 반환하나요?

F3-3. Alias 테이블 일괄 조회로 개선했을 때 IN 절 파라미터가 게임 수에 비례해 커질 수 있는데, 이 쿼리의 성능 한계는 어떻게 판단했나요?

F3-4. RabbitMQ 메시지가 유실되면 캐시 정합성이 깨질 수 있는데, 이 케이스를 어떻게 처리했나요? 주기적 전체 갱신 같은 폴백이 있었나요?

F3-5. PostCommitUpdateEventListener가 트랜잭션 커밋 이후에 발동한다고 했는데, 커밋 전 메시지 발행이 발생하지 않는다는 걸 어떻게 보장했나요?

메인 질문 4. 슬롯 스핀 성능 최적화 과정에서 AliasMethod 도입과 SecureRandom에서 ThreadLocalRandom으로 전환을 결정했는데, 각 결정의 근거와 측정 결과를 설명해 주세요.

면접관이 실제로 보는 것

성능 문제를 추측이 아닌 측정(JMH) 기반으로 접근하는 엔지니어링 태도와, 도구 선택 시 보안 특성의 필요성을 상황에 맞게 판단하는 역량을 평가한다.
ThreadLocalRandom 필드 저장 버그처럼 Java 동시성 API의 미묘한 오용 패턴을 인지하고 수정한 경험이 있는지 확인한다.

실제 경험 기반 답변 포인트

AliasMethod 도입: 가중치 랜덤 선택을 누적합 O(n) 방식에서 사전 테이블 기반 O(1) 방식으로 전환했다. 테이블 생성은 슬롯 초기화 시 1회만 수행하고, 매 스핀마다 호출되는 pick()은 랜덤 2회로 항상 O(1)이다.
SecureRandom → ThreadLocalRandom: JMH로 1000만 번 기준 측정 결과 ThreadLocalRandom(70.241 ops/s) vs SecureRandom(1.197 ops/s), 약 58배 차이를 확인했다.
SecureRandom 선택 근거 부재 확인: 슬롯은 서버가 결과를 결정하고 클라이언트에 전달하는 구조다. 공격자가 내부 랜덤 상태에 접근할 경로가 없으므로 암호학적 예측 불가능성이 필요한 시나리오가 아니다. SecureRandom은 OS 엔트로피 풀 사용과 내부 synchronized 처리로 멀티스레드 환경에서 락 경합이 발생한다.
ThreadLocalRandom 오용 패턴 수정: ThreadLocalRandom.current()를 필드로 저장하면 초기화 스레드에 귀속된 인스턴스가 고정된다. 다른 스레드에서 해당 필드를 사용하면 스레드 안전하지 않다. 매번 current()를 호출하도록 수정했다.

1분 답변 구조

상황: 시뮬레이터 100만 스핀에서 슬롯 1종당 10분 이상 걸리는 병목이 있었다. 가중치 선택 O(n)과 SecureRandom 내부 락 경합이 주요 원인이었다.
결정: AliasMethod로 가중치 선택을 O(1)로 전환하고, JMH 측정으로 58배 성능 차이를 확인한 뒤 SecureRandom을 ThreadLocalRandom으로 교체했다. 슬롯 구조상 암호학적 보장이 불필요하다는 근거도 명확히 정리했다.
결과: 시뮬레이터 처리 시간이 대폭 단축됐고, ThreadLocalRandom 필드 저장 버그도 함께 발견해 수정했다. 이 개선은 실제 스핀 응답 경로에도 동일하게 적용됐다.

압박 질문 방어 포인트

"SecureRandom이 더 안전한데 왜 바꿨나요? 게임 보안에 문제가 없나요?" → 슬롯은 서버가 결과를 결정하고 클라이언트에 전달하는 구조다. 클라이언트가 서버의 랜덤 생성 내부 상태에 접근할 방법이 없으므로 다음 결과를 예측할 수 없다. 암호학적 보장이 필요한 케이스는 내부 상태가 외부에 노출될 때인데, 이 구조에서는 해당하지 않는다.
"AliasMethod 테이블 생성 비용은 어떻게 처리했나요?" → 테이블 생성은 SlotAliasMethodMaker.of()로 슬롯 초기화 시점에 1회만 수행한다. StaticDataLoader가 슬롯 데이터를 메모리에 올릴 때 함께 생성되므로 런타임 스핀 경로에는 생성 비용이 없다.

피해야 할 약한 답변

"SecureRandom이 더 안전해 보여서 사용하지 말아야 한다" — 암호학적 보장의 필요성을 상황에 맞게 판단하지 않고 결론만 말하는 답변이다. 왜 이 케이스에서 불필요한지 근거가 없다.
"코드에 있어서 바꿨다" — 측정 근거, 선택 기준, 성능 차이를 모르는 답변으로 성능 문제 해결 역량을 드러내지 못한다.

꼬리 질문 5개

F4-1. AliasMethod에서 가중치를 정규화하는 과정의 부동소수점 오차가 실제 RTP 정확도에 영향을 줄 수 있는데, 이 부분을 어떻게 검증했나요?

F4-2. ThreadLocalRandom을 시뮬레이터(멀티스레드)와 일반 스핀(단일 요청) 양쪽에서 사용했는데, 두 컨텍스트에서 동작 차이가 있었나요?

F4-3. JMH 벤치마크 설계 시 JVM 워밍업(warmup iterations)이나 GC 영향을 어떻게 처리했나요?

F4-4. 실제 슬롯 스핀에서 AliasMethod와 ThreadLocalRandom 전환 후 프로덕션 응답 시간에 측정 가능한 개선이 있었나요? 시뮬레이터 외에 실스핀 영향도 측정했나요?

F4-5. ThreadLocalRandom 필드 저장 버그가 실제로 어떤 증상으로 나타났나요? 어떻게 발견했고, 수정 전 얼마나 오래 운영됐나요?

메인 질문 5. Cursor Rules를 20개 이상 직접 구축하고 신규 게임 3종을 에이전트 단독으로 구현했다고 하셨는데, 어떤 문제를 해결하기 위해 이 접근을 선택했고 어떻게 동작하도록 설계했나요?

면접관이 실제로 보는 것

AI 도구를 단순 활용에 그치지 않고 도구화(툴링)까지 주도한 경험이 있는지, 즉 복잡한 도메인 컨텍스트를 에이전트가 재사용할 수 있는 형태로 문서화하는 설계 역량을 평가한다.
개인 성과를 팀 표준으로 전파한 경험을 통해 기술 리더십과 팀 생산성 기여 역량을 확인한다.

실제 경험 기반 답변 포인트

문제 정의: 슬롯 도메인은 RTP 계산, 페이 방식, 게임 기계학, 스핀 타입별 흐름 등 컨텍스트가 방대해 에이전트가 코드만 보고는 설계 의도를 파악하기 어렵다. 컨텍스트 없이 에이전트에 맡기면 기존 추상화와 맞지 않는 코드가 생성됐다.
Cursor Rules를 도메인 지식 공급 수단으로 활용: 슬롯 엔진 구조(SlotTemplate/BaseSlotService), 게임 타입별 스핀 흐름, 확장 포인트, 테스트 패턴 등 20개 이상 규칙을 구축했다. Rules는 에이전트의 컨텍스트 창에 자동 주입된다.
에이전트 단독 구현 가능 조건: 도메인 컨텍스트가 Rules에 충분히 문서화되어 있어야 하고, 기존 추상화 레이어(SlotTemplate/BaseSlotService)가 참조 코드 역할을 할 수 있는 구조여야 한다. 추상화가 먼저 안정화된 뒤에 에이전트 협업이 실효성 있게 동작했다.
팀 전파: Slot 44(Fortune Blessing), 41(Bingoing), 47(Boogie Turkey)를 에이전트 협업으로 구현한 경험을 팀 내에 활용 방법으로 전파해 반복 개발 사이클을 단축했다.

1분 답변 구조

상황: 슬롯마다 유사한 구조가 반복되지만, 도메인 컨텍스트 없이 에이전트에 맡기면 기존 추상화와 맞지 않는 코드가 생성됐다. 매번 컨텍스트를 직접 설명하는 비용도 컸다.
결정: 슬롯 엔진 구조, 확장 포인트, 타입별 스핀 흐름을 Cursor Rules로 문서화해 에이전트 컨텍스트를 자동 공급하도록 설계했다. SlotTemplate/BaseSlotService 추상화가 안정화된 뒤 Rules와 결합해 에이전트 단독 구현이 가능해졌다.
결과: Slot 44, 41, 47 에이전트 협업 구현 완료. AbstractSlotTest 기반 테스트 템플릿으로 에이전트 생성 코드도 동일한 검증 체계에서 확인했다. 팀 전파로 반복 개발 사이클 단축에 기여했다.

압박 질문 방어 포인트

"에이전트가 생성한 코드의 품질을 어떻게 검증했나요?" → 에이전트 생성 코드를 직접 리뷰하고, SlotSimulator로 RTP와 게임 흐름을 검증했다. AbstractSlotTest 기반 테스트 템플릿이 있어 에이전트 생성 코드도 동일한 테스트 프레임워크로 확인 가능했다. 에이전트를 맹신하지 않고 설계 의도를 아는 개발자가 반드시 검토하는 워크플로를 유지했다.
"Cursor Rules 20개의 유지보수 부담은 어떻게 처리했나요?" → SlotTemplate·BaseSlotService 추상화가 안정화되면서 Rules의 변경 빈도도 줄었다. 신규 슬롯 추가나 엔진 구조 변경 시 해당 Rules를 함께 업데이트하는 관행을 팀 내에 만들었다. Rules는 코드 변경 시 자연스럽게 함께 갱신하는 부속 문서로 취급했다.

피해야 할 약한 답변

"Cursor에 물어보면 코드를 써준다" — 도메인 컨텍스트 공급 설계, Rules 구조화, 품질 검증 체계에 대한 이해 없이 도구 사용법만 말하는 답변이다.
"AI 도구를 써서 빠르게 개발했다" — 어떤 문제를 해결하기 위해 어떤 구조로 동작하도록 설계했는지, 팀에 어떻게 기여했는지 설계 의도와 영향이 없는 답변이다.

꼬리 질문 5개

F5-1. Cursor Rules 20개 중 에이전트 동작에 가장 영향이 컸던 규칙은 어떤 내용이었나요? 그게 핵심이었던 이유는 무엇인가요?

F5-2. 에이전트 단독 구현이 가능했던 슬롯과 직접 개발해야 했던 슬롯의 차이는 무엇이었나요? 어떤 케이스에서 에이전트 협업을 포기했나요?

F5-3. SlotTemplate/BaseSlotService 추상화와 Cursor Rules는 상호보완적이라고 하셨는데, 추상화가 먼저였나요 Rules가 먼저였나요? 순서가 중요했나요?

F5-4. 팀원들이 Cursor Rules를 활용하도록 전파하는 과정에서 저항이나 어려움이 있었나요? 어떻게 설득했나요?

F5-5. 에이전트 협업 개발 방식이 코드 리뷰, 테스트 커버리지, 기술 부채 측면에서 일반 개발 방식과 어떤 트레이드오프가 있었나요?

최종 준비 체크리스트

SlotTemplate의 PayCalculator 주입 구조, WayPayCalculator 싱글턴의 멀티스레드 안전성 근거, BaseSlotService와 interface default 메서드의 차이를 설명할 수 있는가
RCC 캐시 생성 동시성을 낙관적 락 대신 DB 유니크 키 + 예외 처리로 처리한 트레이드오프와 캐시 없음 시 폴백 동작 방식을 설명할 수 있는가
StampedLock writeLock/tryReadLock 2.5초 타임아웃의 근거, 타임아웃 만료 시 처리 방식, ReentrantReadWriteLock 대비 선택 이유를 설명할 수 있는가
AliasMethod O(1) 선택의 테이블 구성 원리, SecureRandom 대신 ThreadLocalRandom을 선택한 보안 근거, JMH 58배 측정 결과, ThreadLocalRandom 필드 저장 버그를 설명할 수 있는가
Cursor Rules 20개의 도메인 컨텍스트 공급 설계 의도, 에이전트 생성 코드 품질 검증 방법, 추상화 레이어와 Rules의 상호 의존 관계를 설명할 수 있는가

[초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업

이 트랙의 경험 요약

NHN NSC슬롯팀 2024.06 ~ 2025.11 슬롯 게임 백엔드 경험 기반 질문 은행으로, 슬롯 엔진 추상화·RCC 시스템 설계·동시성 처리·성능 최적화·AI 도구 도입 5개 주제를 커버한다.
CJ 올리브영 커머스플랫폼 웰니스개발팀 면접의 도메인 모델링, 캐싱 전략, 비동기 처리, 대용량 처리 역량 검증 영역과 직접 매핑되도록 설계되었다.
각 질문은 후보자의 실제 경험 증거(SlotTemplate/BaseSlotService, RCC, StampedLock, AliasMethod, Cursor Rules)를 기반으로 구성되었으며, 면접관 의도와 압박 방어 포인트를 포함한다.

메인 질문 1. 슬롯이 5종 이상 쌓인 시점에 SlotTemplate과 BaseSlotService를 도입해 엔진을 추상화했다고 하셨는데, 그 설계 결정의 배경과 구체적인 구조를 설명해 주세요.

면접관이 실제로 보는 것

반복 경험 후 추상화 타이밍을 판단하는 설계 감각이 있는지, 즉 과도한 사전 설계와 지연된 리팩터링 사이의 균형을 실무에서 어떻게 잡는지 평가한다.
인터페이스와 추상 클래스를 실제 문제 해결에 어떻게 적용했는지, 특히 Java의 interface default 메서드 한계를 인지하고 구조를 선택했는지 확인한다.

실제 경험 기반 답변 포인트

슬롯 5종 이상 구현 후 라인·웨이·클러스터 세 가지 페이 방식이 공통 추상화 축임을 발견했다. 처음부터 추상화하면 잘못된 경계를 그을 가능성이 높아 반복을 충분히 경험한 뒤에 설계했다.
SlotTemplate으로 페이 방식 자체를 추상화해 슬롯마다 직접 구현하던 페이 계산을 PayCalculator 주입으로 전환했다. 슬롯은 getPayCalculator()만 반환하면 되고, 페이에 참여하지 않는 심볼 처리도 이 레이어에서 어드민 설정으로 관리하도록 추가했다.
SlotService 인터페이스에 default 구현이 점점 늘어나는 문제를 BaseSlotService 추상 클래스로 해소했다. Java interface default는 상태를 가질 수 없어 스프링 빈 주입이 필요한 공통 로직을 수용할 수 없었다.
ExtraConfig 생성 책임을 SlotConfigFactory에서 각 슬롯 서비스로 이동해 새 슬롯 추가 시 팩토리 코드를 수정하지 않아도 되는 구조를 만들었다.

1분 답변 구조

상황: 슬롯 5종 이상 구현 후 라인·웨이·클러스터 페이 계산 로직이 슬롯마다 중복 구현되고 있었고, SlotService 인터페이스에 default 구현이 늘어나 테스트 가능성이 떨어지고 있었다.
결정: 반복을 충분히 경험한 뒤에야 올바른 공통점이 보인다는 판단으로, SlotTemplate으로 페이 방식을 추상화하고 BaseSlotService로 공통 구현을 추출했다. ExtraConfig 생성 책임도 팩토리에서 각 슬롯 서비스로 이동했다.
결과: 새 슬롯 추가 시 슬롯 특화 로직만 구현하면 되고, 기존 슬롯 코드를 건드리지 않는 확장 구조가 완성됐다. 이후 AI 에이전트가 신규 슬롯을 구현할 때도 이 구조가 참조 코드로 활용됐다.

압박 질문 방어 포인트

"왜 처음부터 추상화하지 않았나요?" → 처음부터 추상화하면 잘못된 경계를 그을 가능성이 높다. 실제로 여러 슬롯을 직접 만든 뒤에야 페이 방식이라는 올바른 추상화 축이 보였다. 이른 추상화의 비용이 반복 구현의 비용보다 더 크다고 판단했다.
"인터페이스 대신 추상 클래스를 선택한 이유가 무엇인가요?" → Java의 interface default 메서드는 상태를 가질 수 없다. 공통 구현에 스프링 빈 주입이 필요한 상태 있는 로직이 포함되어 있어 추상 클래스가 적합했다. 인터페이스는 계약 정의 역할로 유지하고, 공통 구현은 추상 클래스에 두는 계층 구조를 선택했다.

피해야 할 약한 답변

"공통 로직이 있으면 무조건 추상화하는 것이 좋다" — 추상화 타이밍과 근거 없이 일반론만 말하는 답변으로, 왜 그 시점이었는지 설계 의도가 없다.
"슬롯마다 코드가 중복되어 있어서 정리했다" — 중복 제거 외에 페이 방식 추상화, ExtraConfig 책임 이동, 테스트 가능성 개선 등 설계 결정의 맥락이 빠진 답변이다.

꼬리 질문 5개

F1-1. WayPayCalculator를 INSTANCE 싱글턴으로 만든 이유는 무엇인가요? 멀티스레드 환경에서 상태가 없다는 걸 어떻게 보장했나요?

F1-3. BaseSlotService에서 추상 메서드로 선언한 것과 기본 구현을 제공한 것을 어떤 기준으로 구분했나요?

F1-4. ExtraConfig 책임을 팩토리에서 서비스로 이동했을 때, 기존 슬롯들을 마이그레이션하는 과정에서 어떤 어려움이 있었나요?

F1-5. slot-config-model 모듈로 Config 응답 객체를 분리한 이유가 메타 서비스 이관 준비라고 하셨는데, 실제 이관은 어느 단계까지 진행됐나요?

메인 질문 2. RTP 보장을 위해 스핀 결과를 미리 캐시하는 RCC 시스템을 직접 설계하셨는데, 핵심 아키텍처 결정과 그 과정에서 부딪힌 가장 어려운 문제를 설명해 주세요.

면접관이 실제로 보는 것

복잡한 비즈니스 요구사항(RTP 보장)을 시스템 아키텍처로 번역하는 능력을 평가한다. 유저 경험을 해치지 않으면서 백그라운드 처리로 목표를 달성하는 비동기 설계 사고를 확인한다.
슬롯별 다른 로직을 조건 분기 없이 처리하는 인터페이스 추상화 적용 능력과, 분산 환경 동시성 처리에서 낙관적 락과 DB 유니크 키 중 상황에 맞는 선택을 했는지 확인한다.

실제 경험 기반 답변 포인트

핵심 설계: 백그라운드에서 '좋은 결과'를 미리 생성해 DB에 캐시하고, RTP 보장이 필요한 시점에 캐시에서 꺼내 제공한다. 유저 입장에서 일반 스핀과 동일하게 보인다.
비동기 설계 선택: 캐시 생성을 스핀 응답 흐름에서 완전히 분리했다. 캐시 히트 시 다음 캐시 생성을 비동기 트리거해 유저 응답 시간에 영향 없이 캐시를 미리 준비한다.
RccSpinResultAnalyzer를 인터페이스로 추상화해 슬롯별 캐시 조건 판단 로직을 조건 분기 없이 구현체 주입으로 처리했다. 슬롯 33처럼 개인화 데이터 구조가 특수한 경우도 별도 구현체로 수용했다.
동시성: 낙관적 락 검토 후 캐시 생성 충돌 빈도 특성상 DB 유니크 키 + 예외 처리 조합을 선택했다. 중복 생성 시 유니크 키 위반 예외는 다른 인스턴스가 이미 생성했다는 의미이므로 재시도 없이 넘어가면 된다.
초기 설계에서 놓친 케이스: 잭팟 처리(GameMode별 JackpotService 분기, NoOpJackpotService 필요), 시뮬레이터 캐시 생성 문제, RTP-FREE 상태 중 치환 요청 처리를 운영하며 순차 보완했다.

1분 답변 구조

상황: 순수 확률 기반 슬롯의 짧은 세션 RTP 편차 문제로 유저가 오랫동안 보상을 받지 못하는 케이스가 발생했고, 유저 경험을 해치지 않으면서 RTP를 보장하는 시스템이 필요했다.
결정: 백그라운드 비동기 캐시 생성으로 스핀 응답 흐름과 분리하고, RccSpinResultAnalyzer 인터페이스로 슬롯별 조건 차이를 수용했다. 동시성은 DB 유니크 키 + 예외 처리로 단순하게 처리했다.
결과: 슬롯 6종 대응, 유저 스핀 응답 시간 영향 없이 RTP 보장 달성. RccCacheStatisticsService로 캐시 부족 모니터링 체계도 함께 구축했다.

압박 질문 방어 포인트

"캐시가 없으면 어떻게 되나요? 유저가 계속 나쁜 결과를 받나요?" → 캐시 없음 시에는 일반 스핀 결과를 반환한다. RCC는 RTP 보장 강화를 위한 보조 수단이지 모든 스핀을 캐시로 처리하는 구조가 아니다. RccCacheStatisticsService로 캐시 부족 슬롯·베팅 인덱스 조합을 모니터링하고 생성 속도를 튜닝해 대응한다.
"DB 유니크 키로 동시성을 막는 게 충분한가요?" → 이 구조에서 중요한 건 정확히 하나의 레코드가 아니라 충분한 양의 캐시를 만드는 것이다. 중복 생성 시 예외가 발생해도 다른 인스턴스가 이미 생성했다는 의미이므로 문제가 없다. 분산 락은 단순성 대비 운영 비용이 높고 이 케이스에는 과잉이다.

피해야 할 약한 답변

"RTP 보장을 위해 좋은 결과를 미리 캐시한다" — 왜 비동기인지, 슬롯별 다른 조건을 어떻게 처리했는지, 동시성 문제를 어떻게 해결했는지 설계 근거가 전혀 없는 표면적 답변이다.
"동시성 문제는 synchronized나 분산 락으로 처리했다" — 실제 선택한 DB 유니크 키 방식의 근거가 없고, 분산 환경에서 synchronized의 한계를 모르는 답변이다.

꼬리 질문 5개

F2-1. RccCacheStatisticsService에서 캐시 부족을 감지했을 때 어떤 후속 액션을 취하도록 설계했나요? 알림인가요, 자동 생성 증가인가요?

F2-2. 슬롯 2, 7번처럼 개인화 데이터가 있는 슬롯에서 캐시 생성 시 개인화 데이터를 어떻게 처리했나요? 사용자별로 캐시가 달라지나요?

F2-4. 캐시 생성 판단 쿼리에 복합 인덱스를 추가했다고 하셨는데, game_id·bet_index·cache_type·used 순서로 결정한 근거는 무엇인가요?

F2-5. RTP-FREE 상태 중 치환 요청 케이스를 처음에 놓쳤다고 하셨는데, 이런 상태 전이 케이스를 다음에는 어떻게 사전에 발견할 수 있을까요?

메인 질문 3. 다중 서버 환경에서 정적 캐시 데이터를 RabbitMQ로 동기화하면서 갱신 도중 NPE가 발생했다고 하셨는데, StampedLock 도입 결정의 근거와 구체적인 설계를 설명해 주세요.

면접관이 실제로 보는 것

Java 동시성 도구(synchronized, ReentrantReadWriteLock, StampedLock)의 차이를 실무 문제에서 이해하고 상황에 맞는 선택을 할 수 있는지 평가한다.
읽기가 압도적으로 많은 캐시 구조에서 갱신 중 일관성을 보장하면서 읽기 성능을 희생하지 않는 설계 감각을 확인한다.

실제 경험 기반 답변 포인트

문제 재현: refreshAll() 중 clearAllStaticData() 완료 후 새 데이터 로드 전 다른 스레드가 조회하면 NPE 발생. 갱신은 어드민 설정 변경 시만 발생하지만, 발생 시 반드시 막아야 하는 문제였다.
StampedLock 선택 근거: 갱신 빈도가 낮고 읽기가 압도적으로 많은 구조에 적합하다. synchronized는 읽기 병렬화가 안 되고, StampedLock의 tryReadLock은 타임아웃 지정으로 갱신 완료 대기 의도를 명확하게 표현할 수 있었다.
설계: 갱신 시 writeLock으로 읽기 스레드를 차단하고, 조회 시 tryReadLock에 2.5초 타임아웃을 설정해 갱신이 완료될 때까지 대기하도록 했다. 2.5초는 갱신 작업 예상 소요 시간 기반으로 결정했다.
추가 개선: Alias 테이블을 게임별 개별 쿼리에서 IN 절 일괄 조회로 변경해 게임 수십 개 환경에서 쿼리 수를 O(n)에서 O(1)로 줄였다.

1분 답변 구조

상황: 어드민 설정 변경 → RabbitMQ 메시지 → refreshAll() 실행 중 clear 완료 후 새 데이터 로드 전에 다른 스레드가 조회하면 NPE가 발생했다.
결정: 갱신 빈도가 낮고 읽기가 압도적으로 많은 구조에 StampedLock을 선택했다. writeLock으로 갱신 구간을 보호하고 tryReadLock 2.5초 타임아웃으로 조회 스레드가 갱신 완료를 대기하도록 설계했다.
결과: 갱신 중 일시적 NPE가 완전히 해소됐고, 읽기 성능에 대한 영향이 최소화됐다. StaticDataManager 인터페이스로 데이터 타입별 init/refresh/clear 책임도 함께 분리했다.

압박 질문 방어 포인트

"2.5초 타임아웃이면 스핀 응답 시간에 영향을 주지 않나요?" → 갱신은 어드민 설정 변경 시에만 발생하고 빈도가 매우 낮다. 갱신 중 요청이 들어오는 케이스 자체가 드물고, 타임아웃 내에 갱신이 완료되면 정상 응답한다. 타임아웃이 만료되는 경우는 갱신이 예상보다 오래 걸리는 이상 상황으로, 이 경우 별도 처리 로직을 두었다.
"synchronized나 ReentrantReadWriteLock 대신 StampedLock을 선택한 이유가 무엇인가요?" → synchronized는 읽기 병렬화가 불가능해 읽기 압도적인 구조에서 불필요한 직렬화가 발생한다. StampedLock의 tryReadLock 타임아웃 지정이 갱신 완료 대기라는 설계 의도를 더 명확하게 표현했다.

피해야 할 약한 답변

"synchronized를 쓰면 해결된다" — 읽기 병렬화 포기, 읽기 압도적인 캐시 구조에서 성능 트레이드오프를 인식하지 못한 답변이다.
"StampedLock이 빠르다고 해서 썼다" — 낙관적 읽기와 tryReadLock 타임아웃의 차이, 이 구조에서 타임아웃 방식을 선택한 설계 근거가 없는 답변이다.

꼬리 질문 5개

F3-2. tryReadLock 타임아웃이 2.5초 만료되면 어떻게 처리하도록 설계했나요? 예외를 던지나요, 아니면 기본값을 반환하나요?

F3-3. Alias 테이블 일괄 조회로 개선했을 때 IN 절 파라미터가 게임 수에 비례해 커질 수 있는데, 이 쿼리의 성능 한계는 어떻게 판단했나요?

F3-4. RabbitMQ 메시지가 유실되면 캐시 정합성이 깨질 수 있는데, 이 케이스를 어떻게 처리했나요? 주기적 전체 갱신 같은 폴백이 있었나요?

F3-5. PostCommitUpdateEventListener가 트랜잭션 커밋 이후에 발동한다고 했는데, 커밋 전 메시지 발행이 발생하지 않는다는 걸 어떻게 보장했나요?

메인 질문 4. 슬롯 스핀 성능 최적화 과정에서 AliasMethod 도입과 SecureRandom에서 ThreadLocalRandom으로 전환을 결정했는데, 각 결정의 근거와 측정 결과를 설명해 주세요.

면접관이 실제로 보는 것

성능 문제를 추측이 아닌 측정(JMH) 기반으로 접근하는 엔지니어링 태도와, 도구 선택 시 보안 특성의 필요성을 상황에 맞게 판단하는 역량을 평가한다.
ThreadLocalRandom 필드 저장 버그처럼 Java 동시성 API의 미묘한 오용 패턴을 인지하고 수정한 경험이 있는지 확인한다.

실제 경험 기반 답변 포인트

AliasMethod 도입: 가중치 랜덤 선택을 누적합 O(n) 방식에서 사전 테이블 기반 O(1) 방식으로 전환했다. 테이블 생성은 슬롯 초기화 시 1회만 수행하고, 매 스핀마다 호출되는 pick()은 랜덤 2회로 항상 O(1)이다.
SecureRandom → ThreadLocalRandom: JMH로 1000만 번 기준 측정 결과 ThreadLocalRandom(70.241 ops/s) vs SecureRandom(1.197 ops/s), 약 58배 차이를 확인했다.
SecureRandom 선택 근거 부재 확인: 슬롯은 서버가 결과를 결정하고 클라이언트에 전달하는 구조다. 공격자가 내부 랜덤 상태에 접근할 경로가 없으므로 암호학적 예측 불가능성이 필요한 시나리오가 아니다. SecureRandom은 OS 엔트로피 풀 사용과 내부 synchronized 처리로 멀티스레드 환경에서 락 경합이 발생한다.
ThreadLocalRandom 오용 패턴 수정: ThreadLocalRandom.current()를 필드로 저장하면 초기화 스레드에 귀속된 인스턴스가 고정된다. 다른 스레드에서 해당 필드를 사용하면 스레드 안전하지 않다. 매번 current()를 호출하도록 수정했다.

1분 답변 구조

상황: 시뮬레이터 100만 스핀에서 슬롯 1종당 10분 이상 걸리는 병목이 있었다. 가중치 선택 O(n)과 SecureRandom 내부 락 경합이 주요 원인이었다.
결정: AliasMethod로 가중치 선택을 O(1)로 전환하고, JMH 측정으로 58배 성능 차이를 확인한 뒤 SecureRandom을 ThreadLocalRandom으로 교체했다. 슬롯 구조상 암호학적 보장이 불필요하다는 근거도 명확히 정리했다.
결과: 시뮬레이터 처리 시간이 대폭 단축됐고, ThreadLocalRandom 필드 저장 버그도 함께 발견해 수정했다. 이 개선은 실제 스핀 응답 경로에도 동일하게 적용됐다.

압박 질문 방어 포인트

"SecureRandom이 더 안전한데 왜 바꿨나요? 게임 보안에 문제가 없나요?" → 슬롯은 서버가 결과를 결정하고 클라이언트에 전달하는 구조다. 클라이언트가 서버의 랜덤 생성 내부 상태에 접근할 방법이 없으므로 다음 결과를 예측할 수 없다. 암호학적 보장이 필요한 케이스는 내부 상태가 외부에 노출될 때인데, 이 구조에서는 해당하지 않는다.
"AliasMethod 테이블 생성 비용은 어떻게 처리했나요?" → 테이블 생성은 SlotAliasMethodMaker.of()로 슬롯 초기화 시점에 1회만 수행한다. StaticDataLoader가 슬롯 데이터를 메모리에 올릴 때 함께 생성되므로 런타임 스핀 경로에는 생성 비용이 없다.

피해야 할 약한 답변

"SecureRandom이 더 안전해 보여서 사용하지 말아야 한다" — 암호학적 보장의 필요성을 상황에 맞게 판단하지 않고 결론만 말하는 답변이다. 왜 이 케이스에서 불필요한지 근거가 없다.
"코드에 있어서 바꿨다" — 측정 근거, 선택 기준, 성능 차이를 모르는 답변으로 성능 문제 해결 역량을 드러내지 못한다.

꼬리 질문 5개

F4-1. AliasMethod에서 가중치를 정규화하는 과정의 부동소수점 오차가 실제 RTP 정확도에 영향을 줄 수 있는데, 이 부분을 어떻게 검증했나요?

F4-2. ThreadLocalRandom을 시뮬레이터(멀티스레드)와 일반 스핀(단일 요청) 양쪽에서 사용했는데, 두 컨텍스트에서 동작 차이가 있었나요?

F4-3. JMH 벤치마크 설계 시 JVM 워밍업(warmup iterations)이나 GC 영향을 어떻게 처리했나요?

F4-5. ThreadLocalRandom 필드 저장 버그가 실제로 어떤 증상으로 나타났나요? 어떻게 발견했고, 수정 전 얼마나 오래 운영됐나요?

메인 질문 5. Cursor Rules를 20개 이상 직접 구축하고 신규 게임 3종을 에이전트 단독으로 구현했다고 하셨는데, 어떤 문제를 해결하기 위해 이 접근을 선택했고 어떻게 동작하도록 설계했나요?

면접관이 실제로 보는 것

AI 도구를 단순 활용에 그치지 않고 도구화(툴링)까지 주도한 경험이 있는지, 즉 복잡한 도메인 컨텍스트를 에이전트가 재사용할 수 있는 형태로 문서화하는 설계 역량을 평가한다.
개인 성과를 팀 표준으로 전파한 경험을 통해 기술 리더십과 팀 생산성 기여 역량을 확인한다.

실제 경험 기반 답변 포인트

문제 정의: 슬롯 도메인은 RTP 계산, 페이 방식, 게임 기계학, 스핀 타입별 흐름 등 컨텍스트가 방대해 에이전트가 코드만 보고는 설계 의도를 파악하기 어렵다. 컨텍스트 없이 에이전트에 맡기면 기존 추상화와 맞지 않는 코드가 생성됐다.
Cursor Rules를 도메인 지식 공급 수단으로 활용: 슬롯 엔진 구조(SlotTemplate/BaseSlotService), 게임 타입별 스핀 흐름, 확장 포인트, 테스트 패턴 등 20개 이상 규칙을 구축했다. Rules는 에이전트의 컨텍스트 창에 자동 주입된다.
에이전트 단독 구현 가능 조건: 도메인 컨텍스트가 Rules에 충분히 문서화되어 있어야 하고, 기존 추상화 레이어(SlotTemplate/BaseSlotService)가 참조 코드 역할을 할 수 있는 구조여야 한다. 추상화가 먼저 안정화된 뒤에 에이전트 협업이 실효성 있게 동작했다.
팀 전파: Slot 44(Fortune Blessing), 41(Bingoing), 47(Boogie Turkey)를 에이전트 협업으로 구현한 경험을 팀 내에 활용 방법으로 전파해 반복 개발 사이클을 단축했다.

1분 답변 구조

상황: 슬롯마다 유사한 구조가 반복되지만, 도메인 컨텍스트 없이 에이전트에 맡기면 기존 추상화와 맞지 않는 코드가 생성됐다. 매번 컨텍스트를 직접 설명하는 비용도 컸다.
결정: 슬롯 엔진 구조, 확장 포인트, 타입별 스핀 흐름을 Cursor Rules로 문서화해 에이전트 컨텍스트를 자동 공급하도록 설계했다. SlotTemplate/BaseSlotService 추상화가 안정화된 뒤 Rules와 결합해 에이전트 단독 구현이 가능해졌다.
결과: Slot 44, 41, 47 에이전트 협업 구현 완료. AbstractSlotTest 기반 테스트 템플릿으로 에이전트 생성 코드도 동일한 검증 체계에서 확인했다. 팀 전파로 반복 개발 사이클 단축에 기여했다.

압박 질문 방어 포인트

"에이전트가 생성한 코드의 품질을 어떻게 검증했나요?" → 에이전트 생성 코드를 직접 리뷰하고, SlotSimulator로 RTP와 게임 흐름을 검증했다. AbstractSlotTest 기반 테스트 템플릿이 있어 에이전트 생성 코드도 동일한 테스트 프레임워크로 확인 가능했다. 에이전트를 맹신하지 않고 설계 의도를 아는 개발자가 반드시 검토하는 워크플로를 유지했다.
"Cursor Rules 20개의 유지보수 부담은 어떻게 처리했나요?" → SlotTemplate·BaseSlotService 추상화가 안정화되면서 Rules의 변경 빈도도 줄었다. 신규 슬롯 추가나 엔진 구조 변경 시 해당 Rules를 함께 업데이트하는 관행을 팀 내에 만들었다. Rules는 코드 변경 시 자연스럽게 함께 갱신하는 부속 문서로 취급했다.

피해야 할 약한 답변

"Cursor에 물어보면 코드를 써준다" — 도메인 컨텍스트 공급 설계, Rules 구조화, 품질 검증 체계에 대한 이해 없이 도구 사용법만 말하는 답변이다.
"AI 도구를 써서 빠르게 개발했다" — 어떤 문제를 해결하기 위해 어떤 구조로 동작하도록 설계했는지, 팀에 어떻게 기여했는지 설계 의도와 영향이 없는 답변이다.

꼬리 질문 5개

F5-1. Cursor Rules 20개 중 에이전트 동작에 가장 영향이 컸던 규칙은 어떤 내용이었나요? 그게 핵심이었던 이유는 무엇인가요?

F5-2. 에이전트 단독 구현이 가능했던 슬롯과 직접 개발해야 했던 슬롯의 차이는 무엇이었나요? 어떤 케이스에서 에이전트 협업을 포기했나요?

F5-3. SlotTemplate/BaseSlotService 추상화와 Cursor Rules는 상호보완적이라고 하셨는데, 추상화가 먼저였나요 Rules가 먼저였나요? 순서가 중요했나요?

F5-4. 팀원들이 Cursor Rules를 활용하도록 전파하는 과정에서 저항이나 어려움이 있었나요? 어떻게 설득했나요?

F5-5. 에이전트 협업 개발 방식이 코드 리뷰, 테스트 커버리지, 기술 부채 측면에서 일반 개발 방식과 어떤 트레이드오프가 있었나요?

최종 준비 체크리스트

SlotTemplate의 PayCalculator 주입 구조, WayPayCalculator 싱글턴의 멀티스레드 안전성 근거, BaseSlotService와 interface default 메서드의 차이를 설명할 수 있는가
RCC 캐시 생성 동시성을 낙관적 락 대신 DB 유니크 키 + 예외 처리로 처리한 트레이드오프와 캐시 없음 시 폴백 동작 방식을 설명할 수 있는가
StampedLock writeLock/tryReadLock 2.5초 타임아웃의 근거, 타임아웃 만료 시 처리 방식, ReentrantReadWriteLock 대비 선택 이유를 설명할 수 있는가
AliasMethod O(1) 선택의 테이블 구성 원리, SecureRandom 대신 ThreadLocalRandom을 선택한 보안 근거, JMH 58배 측정 결과, ThreadLocalRandom 필드 저장 버그를 설명할 수 있는가
Cursor Rules 20개의 도메인 컨텍스트 공급 설계 의도, 에이전트 생성 코드 품질 검증 방법, 추상화 레이어와 Rules의 상호 의존 관계를 설명할 수 있는가

[초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업

이 트랙의 경험 요약

메인 질문 1. 슬롯이 5종 이상 쌓인 시점에 SlotTemplate과 BaseSlotService를 도입해 엔진을 추상화했다고 하셨는데, 그 설계 결정의 배경과 구체적인 구조를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 2. RTP 보장을 위해 스핀 결과를 미리 캐시하는 RCC 시스템을 직접 설계하셨는데, 핵심 아키텍처 결정과 그 과정에서 부딪힌 가장 어려운 문제를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 3. 다중 서버 환경에서 정적 캐시 데이터를 RabbitMQ로 동기화하면서 갱신 도중 NPE가 발생했다고 하셨는데, StampedLock 도입 결정의 근거와 구체적인 설계를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 4. 슬롯 스핀 성능 최적화 과정에서 AliasMethod 도입과 SecureRandom에서 ThreadLocalRandom으로 전환을 결정했는데, 각 결정의 근거와 측정 결과를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 5. Cursor Rules를 20개 이상 직접 구축하고 신규 게임 3종을 에이전트 단독으로 구현했다고 하셨는데, 어떤 문제를 해결하기 위해 이 접근을 선택했고 어떻게 동작하도록 설계했나요?

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

최종 준비 체크리스트

댓글

[초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업

이 트랙의 경험 요약

메인 질문 1. 슬롯이 5종 이상 쌓인 시점에 SlotTemplate과 BaseSlotService를 도입해 엔진을 추상화했다고 하셨는데, 그 설계 결정의 배경과 구체적인 구조를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 2. RTP 보장을 위해 스핀 결과를 미리 캐시하는 RCC 시스템을 직접 설계하셨는데, 핵심 아키텍처 결정과 그 과정에서 부딪힌 가장 어려운 문제를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 3. 다중 서버 환경에서 정적 캐시 데이터를 RabbitMQ로 동기화하면서 갱신 도중 NPE가 발생했다고 하셨는데, StampedLock 도입 결정의 근거와 구체적인 설계를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 4. 슬롯 스핀 성능 최적화 과정에서 AliasMethod 도입과 SecureRandom에서 ThreadLocalRandom으로 전환을 결정했는데, 각 결정의 근거와 측정 결과를 설명해 주세요.

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

메인 질문 5. Cursor Rules를 20개 이상 직접 구축하고 신규 게임 3종을 에이전트 단독으로 구현했다고 하셨는데, 어떤 문제를 해결하기 위해 이 접근을 선택했고 어떻게 동작하도록 설계했나요?

면접관이 실제로 보는 것

실제 경험 기반 답변 포인트

1분 답변 구조

압박 질문 방어 포인트

피해야 할 약한 답변

꼬리 질문 5개

최종 준비 체크리스트

댓글