# 면접 CS 정리 Day 26 (풀스택 / Java·Spring·React)

면접 CS 정리 Day 26 (풀스택 / Java·Spring·React)

Q1. fail-fast vs fail-safe

문제
이터레이터 차이? ArrayList for-each 중 add하면?

답

• fail-fast: 순회 중 구조 변경 시 바로 실패 (ArrayList, HashMap)
• fail-safe: 복사본 등 순회로 예외 없이 진행 가능 (CopyOnWriteArrayList 등)

ConcurrentModificationException이 난다.

Q2. @Scheduled

문제
뭔지? 예외 나면 다음 실행은?

답
cron / fixedRate / fixedDelay로 주기 실행. @EnableScheduling 필요.

예외 시 그 실행은 실패·로그되고, 보통 다음 스케줄은 다시 돈다.
(스레드 고갈·무한 대기는 다음이 밀릴 수 있음)

Q3. 커버링 인덱스

문제
뭔지? SELECT 컬럼이 인덱스에 다 있으면?

답
필요한 컬럼이 인덱스에 전부 있어 테이블 본문을 안 보고 결과 생성.
테이블 I/O가 줄어 빠름. SELECT *면 커버링이 깨지기 쉽다.

Q4. OAuth2 Authorization Code / client secret

문제
Authorization Code 한 줄. 프론트에 secret 금지 이유.

답
사용자 동의 후 code를 받고, 서버가 code + secret으로 토큰 교환.

프론트에 secret 두면 JS/번들에 노출된다. 서버만 보관. SPA는 PKCE 등.

Q5. useReducer

문제
useState 대신 언제?

답
상태 필드가 많고 업데이트 규칙이 복잡할 때 dispatch + reducer로 관리.
로컬 상태용. 전역 공유는 Context/Redux 등과 조합. 라이브러리 아님(훅).

Q6. fail-fast (복습)

문제
ArrayList 순회 중 변경.

답
바로 실패 → ConcurrentModificationException.

Q7. useReducer (복습)

문제
전역인가? 언제?

답
전역 저장소 아님. 복잡한 로컬 상태 로직용 훅.

오늘 한 줄 암기

1. fail-fast = 순회 중 수정 → ConcurrentModificationException
2. @Scheduled 예외 나도 보통 다음 회차는 실행
3. 커버링 = 인덱스만으로 SELECT 완료
4. client secret = 서버만 / 프론트 노출 금지
5. useReducer = 복잡한 로컬 상태 (전역 X)

다음 목표

• useReducer를 Redux/전역이랑 섞지 않기
• 커버링 인덱스를 “인덱스 있다 = 커버링”으로 확대 해석하지 않기