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

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

Q1. PUT vs PATCH

문제
HTTP PUT과 PATCH의 차이, 실무에서 각각 언제 쓰는가?

답

• PUT: 리소스 전체 교체. 빠진 필드가 있으면 null로 덮일 수 있음
• PATCH: 부분 수정. 요청으로 온 필드만 변경

생성은 보통 POST, 전체 수정은 PUT, 일부 수정은 PATCH.

Q2. 생성자 주입을 선호하는 이유

문제
Spring에서 필드 주입(@Autowired on field)보다 생성자 주입을 선호하는 이유는?

답

1. 테스트 시 mock 객체를 생성자로 넣기 쉽다
2. final로 필수 의존성을 명확히 하고 불변으로 유지할 수 있다
3. 의존성 누락 시 객체 생성이 실패해서 문제를 빨리 발견한다

참고
생성자 주입이 순환참조를 “막아 주는” 것은 아니다.
순환이면 기동 시 바로 실패해서 설계를 고치게 만든다.

Q3. 인덱스가 있는데도 느린 이유

문제
인덱스를 만들었는데도 쿼리가 느릴 때 의심할 원인 2가지는?

답

1. 조건 때문에 인덱스를 못 탐 (함수 감싸기, LIKE '%keyword', 타입 불일치)
2. 선택도가 낮거나, 가져와야 할 행이 너무 많음

실행계획(EXPLAIN)에서 type = ALL, key = NULL 여부를 먼저 본다.

Q4. GET으로 데이터를 바꾸면 안 되는 이유

문제
왜 GET으로 서버 상태를 변경하면 안 되는가?

답

• GET은 safe해야 한다 → 조회만, 상태 변경 X
• 브라우저 프리페치, 크롤러, 캐시가 GET을 자동 호출할 수 있음
• URL/로그/히스토리에 남아 의도치 않은 변경·노출이 생길 수 있음

변경은 POST / PUT / PATCH / DELETE를 사용한다.
(POST가 무조건 더 보안에 강하다기보다, 메서드 의미가 다르다.)

Q5. React list의 key

문제
리스트 렌더링에서 key에 id를 쓰고 index를 잘 안 쓰는 이유는?

답
key는 React가 어떤 항목을 재사용/추가/삭제할지 구분하는 식별자다.

index를 key로 쓰면 삽입·삭제·순서 변경 시 항목이 잘못 매칭되어
input 값이 밀리거나 불필요한 리렌더가 발생할 수 있다.
그래서 고유한 id를 사용한다.

Q6. 트랜잭션 전파 REQUIRED

문제
@Transactional의 기본 propagation REQUIRED는
트랜잭션이 있을 때 / 없을 때 각각 어떻게 동작하는가?

답

• 트랜잭션 없음 → 새로 시작
• 트랜잭션 있음 → 기존 트랜잭션에 참여

한 줄: 있으면 쓰고, 없으면 만든다.
보너스: REQUIRES_NEW는 기존 트랜잭션과 분리해 무조건 새 트랜잭션을 연다.

Q7. CORS

문제
CORS가 무엇인가? Spring에서 정석으로 어떻게 해결하는가?

답
브라우저가 다른 Origin(스킴 + 호스트 + 포트)으로 요청할 때
보안상 제한하는 정책이다.

서버에서 허용 Origin/메서드/헤더를 설정한다.
(Spring: CorsConfiguration, Security CORS 등)

로컬 개발에서는 프론트 개발 서버 프록시로 우회하기도 한다.

오늘 한 줄 암기

1. PUT = 전체 교체 / PATCH = 부분 수정
2. GET = 조회만 (safe)
3. REQUIRED = 있으면 참여, 없으면 생성
4. React key = 고유 id
5. CORS = Origin이 다를 때 브라우저 제한