3주차 과제 리뷰 (4팀) #4
Description
3주차 과제도 수고하셨습니다! :)
역시 지난주에 이어서 이번 주에도 굉장히 잘 정리해주셨습니다!
잘 정리한 부분이 많기 때문에, 잘한 부분에 대한 언급(칭찬)은 제외하고
부족한 부분과 예상 추가질문을 위주로 피드백 드리겠습니다-!
RDBMS vs NOSQL
피드백
- RDB를 사용할 때 성능 향상을 위해 서버 자체의 성능을 Scale-up하는 방법 밖에 없다고 답변하는 것은 추천드리지 않습니다. 실무에서는 RDB를 사용하는 케이스가 더 많은데요, DB의 성능이나 DB 용량이 문제가 되는 경우에는 서버 성능을 늘리기도 하지만 한계가 있기 때문에 샤딩(Sharding)을 통해 문제를 해결하기도 합니다. 때문에 무조건 Scale-up만 가능하다고 답변하는 것은 오해를 불러올 수 있습니다. 신입 개발자에게 샤딩까지 물어볼 회사는 많지 않겠지만, 샤딩에 대해서 개략적으로라도 알고 계시는 것이 좋습니다.
예상 추가질문
- 진행하신 프로젝트들에서는 어떤 DB를 사용하셨고, 왜 사용하셨나요?
인덱스
예상 추가질문
- 프로젝트를 하시거나 공부를 하실 때 인덱스를 직접 설정해보셨나요?
트랜잭션
예상 추가질문
- MySQL을 사용하셨다 했는데, MySQL InnoDB의 기본 트랜잭션 격리 수준(Isolation Level)은 무엇인가요?
- 그리고 해당 격리 수준에서 발생할 수 있는 Non-repeatable Read(Phantom Read)에 대해 설명해주실 수 있나요?
- Oracle DB의 기본 트랜잭션 격리 수준(Isolation Level)은 무엇인가요?
JPA
예상 추가질문
- JPA를 사용하실 때, JPA가 생성해주는 쿼리를 직접 수정(튜닝)해야하는 경우에는 어떻게 하셨나요?
- JPA에서 지연로딩(Lazy Loading)을 사용할 때 프록시 객체가 쓰이는 이유를 아시나요?
- 프로젝트에서 JPA를 사용하셨는데, Primary Key 생성 전략은 어떤 것을 선택하셨고 그 이유는 무엇인가요?
- Optimistic Lock에 대해 설명해주세요.
- Optimistic Lock은 Application 레이어에서 사용되는 lock인가요? 아니면 DB에서 사용되는 lock인가요?
- 그렇다면 Pessimistic Lock은 어느 레이어에서 사용되는 lock인가요?
- Pessimistic Lock에 대해 설명해주세요.
- Pessimistic Lock은 데드락의 가능성이 없나요?
- 일반적인 Web Application에서는 Optimistic Lock과 Pessimistic Lock 중 어느 것을 주로 사용하나요?
정규화
피드백
- 저도 국비지원학원에서 정규화에 대해 자세히 배워서 면접에서도 정규화에 대한 질문이 나올거라 예상하고 열심히 공부했었는데요, 지금까지 단 한번도 면접에서 정규화 관련 질문을 받아본 적이 없습니다. 정규화는 알아두시면 좋지만, DBA가 되실게 아니라면 우선순위는 낮추셔도 좋습니다. 아무래도 신입 개발자가 DB모델링을 직접 할 일이 없기 때문에 면접에서도 물어보지 않는 회사들이 많은 것 같아요.
SQL
피드백
- 간단한 SQL문제는 신입개발자를 채용하는 스타트업이나 중소규모의 회사에서 제출하는 경우가 많습니다. 때문에 기본적인 CRUD와 Inner Join 까지는 간단한 예제를 풀어보시는 것이 좋습니다. (검색해보시면 예제들을 찾을 수 있습니다)
- 특히 실무에서는 join을 사용하는 일이 많기 때문에 inner join, outer join, straight join 등의 차이를 정확하게 이해하시는 것이 좋습니다.
- 그리고 실무에서 쿼리 성능으로 인해 쿼리 튜닝이 필요해지는 경우는, 신입 개발자가 쿼리에서 In절에 서브쿼리를 사용해서 테이블 풀스캔이 발생하는 경우가 많은데요, in절을 사용할때 주의점도 알아두시면 좋습니다.
예상 추가질문
- 실행계획(explain) 사용법과 사용 이유를 아시나요?
- 보통 DB에 쿼리를 날린다고 표현하는데요, DB에 요청된 쿼리가 어떻게 실행되는지, 그 실행 과정에 대해 아시나요?
- 답변 예시
- Parser가 쿼리 파싱해서 DB가 이해할 수 있도록 변경 (문법오류 확인)
- 파싱된 쿼리를 Optimizer에 전달
- Optimizer는 파싱된 쿼리를 가지고, 인덱스의 유무, 데이터 분산 또는 편향 정도 등의 통계 정보를 참고해서 여러 실행계획을 세우고, 비용을 연산해서 가장 낮은 비용의 실행계획을 선택한다.
- 이때 비용 평가는 카탈로그 매니져(통계정보 저장소)의 데이터를 기반으로 이루어진다.
- Optimizer는 한정된 통계로 인해 최적화를 못할 수 있다.
- 선택된 실행계획을 DBMS는 절차적 코드로 변환하고 데이터 접근 수행
RESTful API
피드백
- RESTful API에서 중요한 것은 URI나 Http method 활용이 아닙니다. 이 부분은 부수적인 것이고, RESTful API의 개념에 대해 묻는 질문에는 면접관이 원하는 답이 아닐 가능성이 높습니다.
- RESTful API의 가장 중요한 특징은 Stateless(무상태)입니다. 즉, Server가 API를 요청하는 Client의 어떠한 상태도 저장하지 않는다는 것이고, 이 말은 Client가 Server에 종속되지 않는다는 것입니다.
- 따라서 Client는 매 요청마다 자신을 인증할 수 있는 Token이나 Key 등을 Request에 포함시켜 전송하게 됩니다.
- Client가 Server에 종속되지 않는게 중요한 이유는 반대의 경우(=Stateful)를 생각하면 이해하기 쉽습니다.
- 반대로 Stateful하다면(상태가 있다면), 대규모 환경에서 동일한 웹서버를 다수 배치해 로드밸런싱하는 경우 각 Server가 Client의 상태, 세션을 공유할 수 있는 Redis 같은 별도의 시스템이 필요합니다.
- 하지만 Stateless한 RESTful API는 Client의 요청(호출)을 어느 Server라도 동일하게 처리할 수 있습니다.
- 즉, 어떤 Server라도 Client들의 요청에 응답할 수 있다는 것은, 서버 환경이 분산되었든 아니든, Client쪽에서는 Server쪽에 신경 쓸 필요 없이 API 호출만 하면 원하는 결과를 받을 수 있다는 점에서 RESTful API가 활용되는 것입니다.