TIL - 2024/07/08

오늘 모의면접을 봤다.

면접은 공통 질문 2개 + 선택 질문 2개 + cs 질문 1개 이렇게 공지를 해주셨다.

아래는 내가 준비하고 정리한 질문들이다. 이 질문들이 정답은 아니다! 그냥 외우려고 쓴것뿐

 

----------JPA에서 Lazy Loading과 Eager Loading의 = 특징 및 차이점 / 각각의 장단점에 대해 설명해 주세요.

특징 및 차이점과 각각의 장단점
지연 로딩은 필요한 시점에 데이터를 로드하고, 즉시 로딩은 엔티티가 로드될 때 즉시 데이터를 로드합니다.
지연 로딩은 초기 로딩 시 db 쿼리를 최소화하고, 메모리 효율성이 좋아지는 장점이 있고, 단점은 n+1문제가 발생할 수 있습니다.
즉시 로딩의 장점은 한 번에 모든 데이터가 로드되어 쿼리 최적화가 되며, 코드가 단순해집니다. 하지만 단점은
초기 로딩 비용과 메모리 사용량이 많아집니다.

lazy loading에서 사용이 안 된 연관 객체는 어떻게 되는가?
지연 로딩에서 사용되지 않은 연관 객체는 프록시 객체로 남아 있으며, 실제로 접근할 때까지 데이터베이스에 쿼리를 보내지 않습니다

LAZY 로딩을 했을 때 트랜잭션 관점에서 어떤 점을 주의해야 할까요?
객체가 영속 상태일 때는 지연 로딩이 가능하지만, 준영속 또는 비영속 상태일 때는 불가능합니다.
 따라서 트랜잭션이 끝난 후 지연 로딩을 시도하면 프록시 노세션 에러가 발생할 수 있습니다.

EAGER와 LAZY가 어디에 적용되었는가?
이 글은 즉시 로딩이 필요한 필드나 연관 관계에 적용되고
레이지는 필요한 시점에 로딩해도 되는 필드나 연간 관계에 적용됩니다.


----------------@@JPA에서 N+1 문제를 해결하기 위한 방법을 설명해 주세요.

 (예를 들어, 1개의 쿼리로 10개의 부모 엔티티를 조회한 후, 각 부모 엔티티의 자식 엔티티를 조회하기 위해 10개의 추가 쿼리가 실행되어 총 11개의 쿼리가 발생합니다)

일단 N+1 문제는 데이터베이스 쿼리 성능 문제로, 1개의 쿼리로 N 개의 엔티티를 조회한 후,
각 엔티티에 대해 추가로 1개의 쿼리를 실행하는 문제입니다

해결하는 방법은 fetch join , batchsize , entity graph, subselect가 있습니다.

fetchjoin은 jpql에서 'join fetch'를 사용하여 연관된 엔티티를 한 번의 쿼리로 함께 로드 됩니다.

배치 패칭을 사용하여 여러 엔티티를 한 번에 로드하고, Batch Size로 한 번에 가져올 엔티티 수를 설정합니다.

엔티티 그래프를 정의하여 필요한 엔티티를 함께 로드합니다.

서브 셀렉트(Subselect) 패치를 사용하여 연관된 엔티티를 서브 쿼리로 한 번에 로드합니다

batchsize를 이용했을 때 size를 결정하는 기준
 db 성능과 메모리 사용량 트랜잭션 처리량을 기준으로 결정합니다.

EAGER와 FetchJoin의 차이는 무엇인가?
이 글은 엔티티 로드 시 연관된 모든 데이터를 즉시 로드하고
패치 조인은 특정 쿼리에서만 연관된 데이터를 함께 로드합니다.

-------------------------@@통합 테스트와 단위 테스트의 차이점과 각각의 장단점에 대해서 설명해 주세요.

통합 테스트와 단위 테스트는 상호작용을 하는지에 따라 나뉩니다!
상호작용을 하지 않는 단위 테스트 일 경우 말 그대로 다른 모듈과 독립적으로 실행됩니다.
장점은 빠른 피드백을 제공하고 문제 발생 시 원인 파악이 쉽습니다.
단점은 실제 사용 환경과 다른 경우가 많아 모든 오류를 잡지 못할 수도있습니다.
그와 반대로 상호작용을 하는 통합 테스트는 여러 모듈이 상호작용하는 테스트 상황이며,
실제 db, 네트워크와 연동하여 테스트합니다.
장점은 실제 사용 환경과 유사한 상황에서 테스트 가능하며 전체적인 동작을 확인 가능합니다.
단점은 실행 시간이 오래 걸릴 수 있으며, 문제 발생 시 원인 파악이 어려울 수 있습니다.


테스트 코드 작성에 대해 어떻게 생각하는지 (좋다, 나쁘다)

좋다고 생각합니다. 테스트 코드 는 코드의 안정성과 신뢰성을 높이고, 변경사항이 생겼을 때,
기존 기능이 제대로 동작하는지 확인할 수 있습니다.

프로젝트를 하면서 겪어본 적이 있는가? 있다면 무엇이었는가?

단위 테스트를 겪어봤습니다. 각 서비스 메서드의 기능을 독립적으로 테스트하여, 로직의 정확성을 검증했습니다. 
이를 통해 코드 변경 시 발생할 수 있는 회귀 버그를 방지할 수 있었습니다


------------------------레이어별로 나누어서 Slice Test 를 하는 이유에 대해서 설명해 주세요.

레이어 별로 나누어서 Slice Test를 하는 이유는 각 레이어의 기능을 독립적으로 검증하기 위해서입니다.
 독립적인 검증을 통해 문제를 빠르게 식별하고 해결할 수 있습니다. 또한, 테스트 실행 시간이 짧아져 빠른 피드백을 받을 수 있습니다.
 필요한 레이어만 설정하여 테스트 환경을 간단하게 구성할 수 있고, 특정 레이어에서 발생하는 문제를 쉽게 디버깅할 수 있습니다
 전체 애플리케이션을 로드하지 않고 필요한 부분만 로드하여 리소스를 효율적으로 사용할 수 있습니다

--------------------------------------------------------JPA와 Hibernate의 차이점은 무엇인가요?

jpa는 자바 객체와 관계형 db 간의 매핑을 정의합니다. 구현체가 없습니다.
hibernate는 jpa의 구현체 중 하나이며, 가장 널리 사용되는 orm 프레임워크입니다.
자바 객체를 db 테이블과 매핑하여 crud 작업을 쉽게 수행할 수 있습니다.

orm 이란?
(Object-Relational Mapping)이며 객체와 데이터베이스 간의 관계를 정의하고, 
SQL을 직접 작성하지 않고도 데이터베이스 작업을 할 수 있도록 지원합니다

-------------------------------------QueryDSL을 사용하여 복잡한 동적 쿼리를 작성하는 방법을 설명해 주세요.

querydsl은 안전한 sql 쿼리를 자바 코드로 작성할 수 있게 해주는 라이브러리입니다.
엔티티 클래스를 생성하고, QueryDSL용 Q 클래스를 만듭니다.
그다음, JPAQueryFactory를 사용하여 쿼리를 작성하면 됩니다!


----------------------------------테스트 코드를 직접 짰을 때, 느낀 테스트 코드 작성의 필요성을 설명해 주세요.

테스트 코드를 작성하면서 코드 안정성을 높이고, 변경 시 회귀 버그를 방지할 수 있음을 느꼈습니다.
 문제를 조기에 발견하고 수정하여 개발 효율성을 크게 향상시켰습니다

---------------------------------------------------------------------------------------------------
프로젝트에서 좋아요 기능을 구현할 때, 특정 사용자가 특정 게시글을 이미 좋아요 했는지 확인하는 방법을 설명해 주세요.

좋아요 테이블에서 사용자 id와 게시글 id를 기준으로 조회하면 됩니다! 쿼리로 실행하여
 결과가 존재하는지 보면 됩니다. ( select * from likes where user_id = ? and post_id = ? )


-------------------------------주제 : 트랜잭션 트랜잭션을 검색을 통해 공부하시고, 꼬리 질문까지 준비해 주세요.

트랜잭션은 데이터베이스의 상태를 변화시키기 위해 수행되는 작업의 단위입니다.
 트랜잭션의 주요 특징은 ACID 속성입니다.

acid란?

Atomicity (원자성): all or nothing! 모든 연산이 전부 성공하거나 전부 실패합니다.

Consistency (일관성): 데이터베이스의 모든 상태는 항상 일관성을 유지해야 합니다.    // 일관성이란 : db가 트랜잭션 완료 후에도 모든 규칙과 제약 조건을 유지하는 것을 의미

Isolation (독립성): 각 트랜잭션은 독립적으로 실행됩니다.

Durability (지속성): 트랜잭션이 완료되면 결과는 영구적으로 저장됩니다.

트랜잭션의 격리 수준
Read Uncommitted: 다른 트랜잭션에서 아직 커밋 되지 않은 변경 사항을 읽을 수 있습니다.
Read Committed: 다른 트랜잭션이 커밋 한 변경 사항만 읽을 수 있습니다.
Repeatable Read: 트랜잭션이 시작된 후 다른 트랜잭션이 커밋 한 변경 사항을 읽을 수 없습니다.
Serializable: 여러 트랜잭션이 동일한 레코드에 동시 접근할 수 없으므로, 팬텀 리드를 방지합니다. (가장 높은 격리 수준)

트랜잭션 단계
시작: 트랜잭션 시작.
연산 수행: SQL 연산 실행.
커밋 또는 롤백: 성공 시 커밋, 실패 시 롤백.

트랜잭션에서 데이터 복구 방법
데이터 복구는 로그를 통해 가능합니다. 트랜잭션 로그에 모든 변경 사항을 기록하고, 롤백 시 로그를 이용해 이전 상태로 복구합니다.

팬텀 리드
팬텀 리드는 트랜잭션이 두 번 같은 쿼리를 실행할 때, 
첫 번째 쿼리와 두 번째 쿼리 사이에 다른 트랜잭션이 레코드를 삽입하여 결과가 달라지는 현상입니다.

팬텀 리드와 Repeatable Read의 차이는 무엇인가요?

Repeatable Read는 동일한 트랜잭션 내에서 동일한 데이터를 여러 번 읽을 때 일관성을 보장하지만,
 팬텀 리드는 동일한 트랜잭션 내에서 레코드가 삽입되거나 삭제되는 것을 방지하지 않습니다

트랜잭션을 코드에서 사용하는 방법
트랜잭션은 주로 @Transactional 어노테이션을 사용하여 관리합니다. 
이 어노테이션을 메서드나 클래스에 붙이면, 해당 범위 내에서 트랜잭션이 자동으로 시작되고 종료

fetch join의 단점
fetch join은 메모리 사용량이 많아질 수 있고, 페이징이 불가능하다는 단점이 있습니다. 

 // 왜? 연관된 모든 데이터를 한 번에 로드하기 때문에 메모레 사용량 많음

상위 트랜잭션이 없는 상태에서 save 성공 후 delete
상위 트랜잭션이 없는 상태에서 save 성공 후 delete를 하면,
 save는 커밋 되고 delete는 별도의 트랜잭션으로 동작하여, 최종적으로 해당 데이터는 삭제됩니다.

Transactional 어노테이션을 사용하면 내부적으로 어떤 동작이 일어나나요?
Transactional 어노테이션을 사용하면 스프링은 AOP를 통해 해당 메서드 실행 전 트랜잭션을 시작하고,
 메서드가 정상적으로 완료되면 커밋 하며, 예외가 발생하면 롤백 합니다
------------------------------------------------------------------------------------------------

일단 나는 이렇게 면접을 준비하고 봤다. 하지만 튜터님과의 피드백을 통해서 내가 준비한 면접에서의 대답은

일단 개념 설명 밖에없다. 튜터님은 개념을 말하기보다는, 개념은 누구나 다 안다.  예를 들어 5명이 최종면접이다

그럼 이 5명이 최종 면접까지 왔다는 건 다 비슷한 실력이고, 비슷한 개념은 다 안다. 그래서 이 5명에서 나는 조금 더  

특별해야 면접관이 나를 기억해 준다. 즉, 내가 위에서 말한 것처럼 개념만 쌸라쌸라 하지 말고, 이 개념을 통해서

내가 직접 코드를 구현하거나 프로젝트로 진행하거나 내가 겪은 상황과 엮어서 말을 해야 한다. << 나는 이 생각을

전혀 하지 못했었다. 튜터님이 말하고 곰곰이 생각해 보니, 내가 면접관이어도 개념만 말하는 것보단, 개념은 뭐 인터넷 치면 10분이면 다 외우니, 책에 없는, 강의에 없는, 내가 직접 겪은 상황과 빗대어 말하면 더욱 면접관한테 인상적일 거 같다.

이 말을 듣고 면접을 어떻게 준비해야 될지 조금 알아차린 거 같다.

그리고 딱 질문을 들었을 때 말하기 전까지 약 n 초동안 1. 키워드 뽑기 2. 문장 나열하고 병합하기 3. 정렬하기

이 3가지를 다 할 수 있게 연습을 해야 한다. 일단 나는 키워드 뽑기는 어느 정도 할 수 있다고 생각한다. 근데 문장 나열하고 병합한 다음 정렬하기가 좀 힘들다. 물론 면접은 많이 연습해서 들으면 바로바로 딱 딱 나와야 한다.

일단 말이 ~다 이렇게 끝내야 한다. ~고, ~고,~고, 이렇게, 나열을 이상하게 하면 상대 면접관도 녹음하고

녹화하는 것이 아닌, 그 자리에서 평가를 하고, 이해를 하기 때문에, 문장을 잘 만들고 말을 정확히 해야 한다.

 

그리고 모르는 질문이나, 이런 게 나왔을 때, 이거는 튜터님마다 조금 다른 거 같다. 면접관마다 다른 거고,
나의 튜터님은 답변을 매뉴얼을 만들어 놓으라고 하셨다. 그래야 조금 더 스무스하게, 잘 넘길 수 있다고 하셨다.
나도 그렇게 생각한다.
면접을 20분 정도 보고, 피드백과 조언을 1시간 정도해 주셨는데 매우 유익한 시간이었다.
면접 준비, cs 준비, 최종 프로젝트, 앞으로 빡셀 거 같지만 파이팅이다.