1) JPA 변경감지(Dirty Checking)와 UPDATE 쿼리 시점
-
“트랜잭션 종료 시 UPDATE가 나간다”는 말은 보통 커밋 과정에서 flush가 발생하며 SQL이 전송된다는 의미.
-
일반적인 흐름
-
엔티티 값 변경 → 영속성 컨텍스트가 변경사항을 기억
-
commit 직전 자동 flush → 변경감지 수행 → UPDATE SQL 전송 → commit 확정
-
-
중요한 포인트
-
flush = SQL 전송
-
commit = 트랜잭션 확정
-
flush는 commit 전에 일어나기도 함(예: JPQL 실행 전 자동 flush 등)
-
2) Redis Pub/Sub 정리 + “원자 연산만으로 동시성 제어가 안 되는 이유”
2-1. Redis Pub/Sub
- Publisher가 채널에 메시지 발행 → Subscriber가 실시간 수신
장점
- 구조 단순, 빠른 실시간 알림/이벤트 브로드캐스트에 좋음
단점(핵심)
-
메시지 영속 저장 없음
-
구독자가 없거나 오프라인이면 유실
-
retry/재처리/내구성이 필요한 “메시지 큐” 용도엔 부적합(이 경우 Streams/Kafka/RabbitMQ 등 고려)
-
2-2. Redis 원자적 연산이 동시성 제어를 “완전히” 못하는 이유
-
Redis의 atomic은 보통 “명령 1개 단위” 보장
-
현실 로직은 대개 GET → 조건 검사 → SET 같은 복합 연산이라 중간에 끼어들면 깨짐
예: 재고 감소에서
- 단순 DECR는 원자적이지만, 0 이하 방지 같은 조건이 붙으면 한 명령으로 끝나지 않음
해결 방향
-
Lua Script로 “복합 로직 전체를 원자적으로”
-
혹은 분산락(Redisson) 으로 임계구간 직렬화
3) OAuth, “인가”가 왜 헷갈리는지 + OIDC의 정확한 의미
3-1. 인증 vs 인가
-
OAuth의 본질은 “로그인”이 아니라 권한 위임(인가):
-
비밀번호를 직접 주지 않고도, 토큰으로 리소스 접근 권한을 위임하는 모델
3-2. 그런데 왜 “소셜 로그인”이라고 부르나?
-
사용자 입장에서는 “구글/카카오로 들어가서 로그인 완료”처럼 보이기 때문
-
하지만 기술적으로는
-
OAuth2로 access token 발급 → userinfo 조회 → 우리 서비스 로그인 처리(세션/JWT 발급)
-
이 과정을 업계에서 관용적으로 “소셜 로그인”이라 부름
-
3-3. OpenID Connect(OIDC)는 뭐냐?
-
OIDC는 OAuth2 위에 얹힌 ‘인증’ 표준 레이어
-
OAuth2에 더해 id_token(JWT) 개념을 제공 → “사용자가 누구인지”를 표준 방식으로 증명
-
핵심 구분
-
외부 Provider가 발급: id_token(사용자 인증 정보가 담긴 JWT)
-
우리 서비스가 발급: 우리 서비스용 JWT(access/refresh)
-
참고: 실무에선 “OAuth2만으로도” userinfo 조회 기반 소셜 로그인 구현을 많이 함
4) 프로세스에서도 데드락이 생기냐?
생김. 데드락은 스레드/프로세스 둘 다 발생 가능
-
대표 예시
- 파일 락, 세마포어/뮤텍스, DB 트랜잭션(row lock 충돌) 등
-
DB는 데드락 감지 시 보통 한 트랜잭션을 강제로 롤백시키기도 함(MySQL 등)
5) EC2 + GitHub Actions + Docker로 CI/CD 흐름
흐름의 핵심
-
코드 push → GitHub Actions 트리거
-
Actions에서 빌드/테스트(CI)
-
통과하면 Docker image build
-
이미지를 레지스트리(ECR/GHCR/DockerHub) 에 push
-
Actions가 EC2로 SSH(또는 SSM) 접속해서
-
docker pull
-
docker compose up -d(또는 컨테이너 재시작)
-
필요시 헬스체크/로그 확인
-
6) “트랜잭션 범위보다 락 범위를 작게”의 의미
DB row lock(SELECT ... FOR UPDATE)은 보통 트랜잭션과 함께 가는 경우가 많지만,
Redis 락/분산락/JVM 락 같은 애플리케이션 레벨 락은 트랜잭션과 분리 가능
“락 범위를 작게”의 의도:
-
동시성 충돌이 실제로 발생하는 임계 구간만 잠그고
-
나머지(검증, 알림, 외부 호출 등)는 락 없이 처리
이유: 락을 오래 잡으면 병목/대기/데드락 위험 증가
7) CS 기본기: 재귀 vs 반복
반복
- for/while로 상태를 직접 관리, 스택 부담 적음, 안정적
재귀
함수가 자기 자신 호출, 문제를 쪼개기 쉬워 직관적인 경우가 있음(트리/DFS/분할정복)
단점
호출 스택이 쌓여 깊으면 StackOverflow 가능
8) “힙이 동적 할당을 담당한다”의 의미
-
실행 중 new로 생성되는 객체/배열은 힙(Heap) 에 생성됨(동적 할당)
-
지역 변수(참조 변수)는 보통 스택(Stack) 에 있고, 힙 객체를 가리킴
-
Java는 해제를 직접 하지 않고 GC가 처리
오늘은 면접 질문 관련 공부를 집중적으로 했습니다.
