면접 CS 정리 Day 7 (풀스택 / Java·Spring·React)
Q1. Optional
문제Optional을 왜 쓰는지? null 대신 쓰는 이유를 한 줄로.
답
“값이 없을 수 있음”을 타입으로 명시하고,isPresent / orElse / ifPresent 등으로 빈 값 처리를 강제하려고 쓴다.
참고: 자동으로 NPE를 막아 주진 않는다. get()을 막 쓰면 예외가 날 수 있다.
주로 반환값에 쓰고, 필드/파라미터 남용은 피한다.
Q2. 트랜잭션 전파 REQUIRED
문제REQUIRED 전파(기본)에서 트랜잭션이 있을 때 / 없을 때 각각 어떻게 되나?
답
- 트랜잭션 없음 → 새로 시작
- 트랜잭션 있음 → 기존 트랜잭션에 참여
한 줄: 있으면 쓰고, 없으면 만든다.
Q3. CORS
문제
CORS가 뭔지 한 줄, Spring에서 정석 해결은?
답
브라우저가 다른 Origin(스킴 + 호스트 + 포트) 요청을 제한하는 정책.
Spring에서 허용 Origin/메서드/헤더를 설정한다.
(CorsConfiguration, Security CORS, 또는 API별 origin 설정)
같은 Origin이 아니라 다른 Origin일 때 발생한다.
Q4. HTTP 상태코드
문제200 / 201 / 400 / 500 각각 언제 쓰는지 한 줄씩.
답
200: 요청 성공 (조회·수정 등 일반 성공)201: 생성 성공 (Created)400: 클라이언트 오류 (잘못된 요청)500: 서버 내부 오류
Q5. AOP와 @Transactional
문제
Spring AOP가 뭔지 한 줄, @Transactional이랑 어떻게 연결되는지 한 줄.
답
AOP는 로깅·트랜잭션처럼 API마다 반복되는 공통 관심사를 분리해 적용하는 기법이다.@Transactional은 AOP 프록시로 메서드 진입/종료 시 트랜잭션을 시작하고 커밋/롤백한다.
Q6. MyBatis #{} vs ${}
문제
MyBatis #{} / ${} 차이 한 줄씩.
답
#{}: PreparedStatement 바인딩 → SQL Injection 방어에 유리 (기본)${}: 문자열 그대로 치환 → 위험. 테이블명 등 꼭 필요할 때만
Q7. 중복 생성 방지 + POST 멱등
문제
프론트 연타로 주문이 2번 생길 수 있을 때,
DB에서 막는 방법 하나 + HTTP 관점에서 POST가 위험한 이유 한 줄.
답
- DB:
(user_id, create_dt)등 조합에 UNIQUE 제약 - HTTP:
POST는 호출마다 새로 생성될 수 있어 멱등이 아님
→ 재시도/연타 시 중복 생성이 나기 쉽다
(프론트 클릭 방지만으론 부족, DB가 최종 방어선)
오늘 한 줄 암기
- Optional = “없을 수 있음”을 타입으로 명시
REQUIRED= 있으면 참여, 없으면 생성- CORS = 다른 Origin
- AOP 프록시 =
@Transactional - POST는 멱등 X → UNIQUE 등으로 중복 방어
다음 목표
- CORS “같은 Origin” 오해 교정
REQUIREDvsREQUIRES_NEW차이 한 번 더