4개월차 모의면접

 

 

 

 

 

멘토링을 시작한지 벌써 4개월 차,,,

이번 두달동안 공부한 인프라 내용을 바탕으로 두번째 모의면접을 실시하였다. 

눈물이,,,차올라서,, 고갤들어,,,

 

 

 

 

Q: 네트워크 OSI 7Layer에 대해 설명해주세요.

A: 네트워크 7계층은 총 7계층으로 이루어져 있으며 1계층은 물리계층으로 이진수의 흐름을 빛과 전기의 아날로그 신호로 변환하는 역할을 하며 더미허브와 같은 장비가 있고, 2계층은 데이터 링크 계층으로 MAC주소를 이용하여 데이터를 최종 목적지까지 전달하는 역할을 하며 대표 장비로는 L2 switch가 있고, 3계층은 네트워크 계층으로 IP주소를 이용하여 최초 목적지부터 최종목적지까지 데이터를 전달하는 역할을 하며 대표장비로는 router가 있습니다. 4계층은 전송 계층으로 Port번호를 이용하여 서버를 분리하고 데이터를 전달하는 역할을 수행하며 TCP, UDP와 같은 프로토콜이 있고 TCP의 경우에는 신뢰서 있는 데이터 전달을 보장하고 UDP의 경우에는 TCP보다 신뢰성이 떨어지지만 빠른 데이터 전달을 한다는 장점이 있습니다. 5계층과 6계층은 세션계층과 프레젠체이션계층인데 현대 TCP/IP모델에서는 사용되지 않고 있지만 세션계층은 TCP/IP 세션을 생성하고 없애는 역할, 프레젠테이션 계층은 데이터 표현의 역할을 맡고 있습니다. 마지막으로 7계층은 애플리케이션 계층으로 최종목적지를 나타내며 HTTP와 같은 프로토콜을 나타냅니다. 

 

+A: (이 대답에서 횡설수설하는 느낌이 느껴지고, 체계화해서 학습하지 않고 A-Z로 대답하면서 외운 것을 답하는 느낌이 느껴진 다는 피드백을 받게 되었다. 하나의 질문에 대해서는 간소화하여 1분이상 대답하면 안되고, 하나하나의 세부 답은 다음 질문으로 넘겨 추가적 답을 해야 한다는 피드백을 받게 되었다)

 

 

 

Q: OSI 7 Layer는 왜 사용되나요?

A: 단계별로 역할을 나누고 문제가 발생하였을 때 어느 부분에서 문제가 발생하였는지 확인하기 위해서 사용됩니다. 

 

+A: 통신이 일어나는 과정을 단계 및 역할 별로 파악할 수 있고, 문제가 발생하면 다른 단계의 장비 및 소프트웨어를 건드리지 않고도 이상이 생긴 단계만 확인하여 문제를 해결할 수 있다. 

 

 

Q: 그럼 구글 도메인을 입력했을때 발생하는 흐름을 OSI 7Layer로 설명해주시겠어요?

A: 먼저 요청이 들어오면 IP를 통해서... 다시 하겠습니다. 먼저 요청이 들어오면 DNS주소를 변환하고 HTTP 프로토콜을 통해서...(횡설수설)

 

출처 https://www.youtube.com/watch?v=6Aw4mTv7CYY&t=13s&ab_channel=SunnyClassroom

+A: 사용자가 웹 브라우저를 통해서 google.com을 입력하면 애플리케이션 계층에서 URL 주소 중 도메인 이름 부분을 DNS 서버에서 검색하여 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 HTTP 프로토콜을 사용하여 요청 메세지를 생성한다. 생성된 메세지는 TCP/IP 프로토콜을 사용하여 전달되는데 먼저 전송계층인 TCP 프로토콜에서 3-way handshake를 통해서 TCP연결이 수립되면 출-도착지 포트번호 등의 정보를 담고있는 TCP segment의 형태로 encode하여 TCP 패킷의 형태로 네트워크 계층으로 전송한다. 네트워크계층에서는 이를 받아 IP정보를 담고있는 IP 패킷의 형태로 encode하고 인터넷을 거쳐 해당 IP주소의 컴퓨터로 메세지가 전송된다. 데이터 링크 계층에서는 전달된 메세지에 MAC주소 등 이더넷 프레임을 encode하여 데이터를 전달하고 서버가 메세지를 단계별로 decode하여  request메세지를 읽은 서버는 생성된 응답을 다시 이더넷프레임 패킷 encapsulation, IP 패킷 encapsulation, TCP 패킷 encapsulation을 통해 TCP/IP 패킷을 만들고 어플리케이션 계층인 HTTP에서 전달받은 정보로 response메세지를 생성하여 이를 브라우저에게 데이터를 전송하고 브라우저는 response 메세지를 받아 파싱하여 화면에 렌더링 한다. 모든 연결이 종료되게 되면 TCP는 4-way handshake과정을 통해 연결을 종료하게 된다. 

 

( 참고한 사이트 )

https://owlgwang.tistory.com/1

웹 브라우저에 URL을 입력하면 어떤 일이 일어날까?

https://steady-coding.tistory.com/505

[네트워크] TCP 3 way handshake & 4 way handshake

 

 

 

Q: Bastion 서버란 무엇인가요?

A: 악성 루트킷, 랜섬웨어등의 공격에서 Bastion서버를 재구성하여 서비스에 영향을 최소화하기 위한 서버를 말합니다. 만약 서비스가 DDoS 공격을 받게 되면 22번 포트에 Bastion서버의 22번 포트 보안을 집중해서 서비스 서버에 영향을 줄이는 것입니다. 

 

+A: Bastion 서버란 외부와 내부 네트워크 사이에서 일종의 게이트 역할을 수행하는 호스트로 보안 대책의 일환으로 사용되는 Bastion 호스트는 내부 네트워크를 향한 공격에 대해 방어하도록 설계되어 있습니다. 이때 Bastion 서버는 public subnet에 두어 public IP로 접근할 수 있도록 하고 내부 서버들은 Bastion 서버를 통해서만 접근이 가능하도록 설계하여 보안을 향상시킬 수 있습니다. 

 

 

 

Q: DDoS 공격을 받았을 때 어떻게 bastion서버가 사용되나요?

A: DDoS공격이 서비스의 22번 포트에서 발생한다고 하면 Bastion의 22번 포트를 열어두고 Bastion 서버의 보안에 집중하도록 합니다.

 

+A: DDoS공격이란 다수의 악의적인 사용자가 특정 사이트에 동시 접속하여 과도한 트래픽을 일으켜 정상적인 서비스를 방해하는 크래킹의 일종으로 이를 방지하기 위해서 공격받는 지점, 즉 어플리케이션에 도달할 수 있는 가능한 트래픽의 유형을 줄이는 방법을 사용할 수 있습니다. 여기서 bastion 서버를 사용하면 만약 22번 포트에 대해 공격을 받는다고 하여도 SSH 서비스 부분에만 장애가 발생하게 되어 서비스 서버는 영향을 최소화 할 수 있습니다. 

 

( 참고한 사이트 )

https://velog.io/@makeitcloud/%EB%9E%80-Bastion-host-%EB%9E%80

[란] Bastion host 란?

https://velog.io/@max9106/wtc-learning6

[새배내] 배포 인프라 미션을 하며 새로 배운 내용

 

 

Q: PUT과 PATCH의 차이점은 무엇인가요?

A: PUT의 경우 멱등성을 보장하는데 여기서 멱등성이란 동일한 요청을 여러번 보내도 같은 대답을 보내는지를 나타내는데 URI자원이 없는 경우 넘어오지 않은 정보에 대해 null로 처리하여 새로운 자원을 생성하고 PATCH의 경우 넘어온 정보에 대해서 수정을 진행하여 부분 교체가 이루어지는데 수정이 반복적으로 진행되어 멱등성을 보장하지 않습니다. 

 

+A: PUT과 PATCH 모두 자원을 업데이트할 목적으로 사용이 되는데, 여기서 PUT의 경우 넘어오지 않은 데이터에 대해서는 모두 null 값으로 처리하여 업데이트 하는 전체 교체가 이루어지는 반면 PATCH의 경우 넘어온 부분에 대해서만 수정을 진행하는 부분교체가 이루어 진다는 차이가 있습니다. 또, PUT의 경우 멱등성(동일한 요청을 여러번 반복하여도 같은 응답을 반환)이 지켜지는 방면에 PATCH의 경우 멱등성이 지켜지지 않는다는 차이가 존재합니다. 

 

 

 

Q: flyway란 무엇인가요 (데이터 베이스 스키마를 관리하는 방법으로 물어보셨던것 같다)?

A: flyway의 경우 데이터 베이스 버전을 설정하여 데이터 테이블을 관리합니다. 

 

+A: flyway란 데이터 베이스의 형상관리를 목적으로 하는 툴인데, 데이터 베이스의 DDL 이력을 쌓아서 DDL이 어떻게 변화되었는지 관리하는 툴로 사용됩니다. 

 

 

 

Q: 그럼 flyway를 운영할 때 사용할 수 있나요?

A: ...엇...네...!

,,, ^^

 

+A: flyway가 운영중인 서비스에서 데이터 유실, 참조 무결성 제약 등의 문제를 해결하기 위해 DB를 점진적으로 migration하는 방법을 이용하는 것이기 때문에 운영중인 서비스에서의 어려움을 해결할 수 있어 사용됩니다. 로컬에서 개발중일 때는 h2 등 in-memory 형태의 데이터 베이스를 사용하여 빠르게 개발합니다. 

 

( 참고한 사이트 )

https://sabarada.tistory.com/193 [flyway] flyway를 통해 DDL 형상관리를 하자 - Spring Boot (Java API) 편 안녕하세요. 오늘은 flyway를 이용하여 로컬 환경에서 DDL의 형상관리를 하는 방법을 알아보도록 하겠습니다. flyway flyway는 데이터베이스의 형상관리를 목적으로 하는 툴입니다. 데이터베이스의 sabarada.tistory.com

 

 

Q: 성능을 개선하는 방법에는 무엇이 있나요?

A: 성능을 개선하는 방법으로는 리버스 프록시를 이용해서는 gzip압축, 캐시 사용, TLS, HTTP/2 설정 등을 이용하여 성능을 개선할 수 있고 서버에서는 redis 캐시를 이용해서 성능을 개선할 수 있습니다. 

 

+A: 인터넷 구간 성능을 개선하기 위해서는 캐싱설정, CDN 사용, keep-alive 설정, gzip 압축, 이미지 압축, 불필요한 다운로드 제거, 불필요한 작업 지연로딩, 스크립트 병합하여 요청수 최소화, HTTP 프로토콜 개선 등의 방법이 존재한다. Reversy Proxy에서는 캐싱 설정, keep-alive 설정, gzip 압축, HTTP2를 사용하여 하나의 TCP연결로 다수의 클라이언트의 요청을 처리하게 함으로서 성능을 개선시킬 수 있고 JS의 측면에서는 불필요한 다운로드 제거, 불필요한 작업을 지연로딩, 스크립트 병합하여 요청수 최소화 등의 방법을 이용하여 성능을 개선시킬 수 있습니다. 

 

 

 

Q: TLS 사용이 성능을 개선시키나요?

A: 보안성을 향상시키는데 사용됩니다.

 

+A: TLS는 TCP와 같은 신뢰성 있는 데이터 전송 위에서 사용할 수 있는 데이터 암호화 프로토콜입니다. 일반적으로 TLS의 경우 암호화 키를 상호 교환하기 위해서 2 RTT를 필요로하는데 TCP 연결에 1 RTT가 필요하여 총 3 RTT가 소요되게 됩니다. RTT를 포함한 성능 개선을 위해 TLS 계층에서 사용될 수 있는 방법은 RFC 5077 Stateless TLS Session Resumption(세션 티켓을 사용하여 1 RTT로 축소)을 사용하거나 RFC 8446 TLS 1.3(TLS연결의 정보를 포함하고 있다가 조건이 만족되면 암호화 데이터 같이 보냄으로서 0 RTT로 축소(TCP Fast Open과 유사))를 사용하는 방법이 있습니다. 

 

( 참고한 사이트 )

https://www.saturnsoft.net/network/2019/03/26/quic-http3-2/

QUIC과 HTTP/3 - 2. 기존의 성능 개선 기법 및 한계

 

 

 

Q: 리버스프록시에서 각각의 역할이 어떻게 성능을 개선시키나요?

A: gzip압축의 경우 전송하는 파일의 크기를 줄여 전송 비용을 줄일 수 있고 캐시의 경우 이전 자원을 재활용해서 비용을 줄일 수 있습니다. CDN의 경우에는 여러 노드를 가진 네트워크에 컨텐츠를 저장하여 가까운 노드에서 컨텐츠를 저장하고 받아오는 프록시 역할을 하면서 성능을 향상시킬 수 있습니다.

 

+A: gzip 압축을 통해 대역폭과 전송시간 절약할 수 있고 캐시를 통해서는 이전 자원을 재활용 하므로 네트워크 비용을 줄일 수 있습니다. 리버스 프록시에서 부하분산을 통하여 부하가 많아지는 상황에서 사용량을 최적화하고, 처리량을 최대화하며 응답 시간을 최소화 하고 단일 리소스의 오버로드를 방지함으로서 성능을 개선시킬 수 있습니다. 

 

 

Q: CDN이 작동하면 리버스 프록시가 역할을 하지 못하나요?

A: ...이 부분에 대해서 학습을 하지 못한 것 같습니다. 

 

( ✨ 멘토님께 여쭤보고 추가 답변 받음 )

+A: 역할을 나누어 사용할 수 있다. CDN이란 프록시 서버의 네트워크를 의미하며 사용자와 최대한 가까운 위치에서 콘텐츠를 전달하여 트래픽 분산을 통해 성능을 개선시키는 방법인데 CDN는 리버스 프록시로 동작하면서 컨텐츠 캐시 서버의 역할을 수행하기 때문에 리버스 프록시의 역할도 담당한다. 정적파일 정리, Route53 GEO location , 캐싱(Static & Dynamic Caching), 압축(cloudfront 압축(gzip)방식 적용), http2설정 등의 역할을 CDN에서 대신 해줄 수 있지만, 리버스프록시의 다른 역할(부하분산 등의 역할)은 리버스 프록시를 두어서 리버스 프록시가 담당하도록 할 수 있다. CDN을 쓰는 이유는 리버스 프록시를 아끼기 위해서라기 보다는 원하는 데이터를 얻기 위해서 우리가 배포한 서버까지 가야하는데 전국에 작은 규모로 많이 퍼진 CDN을 사용하여 가까운데서 가져오도록해 성능을 늘리는데에 있다. 

 

( 참고한 사이트 )

https://superuser.com/questions/1291848/is-a-reverse-proxy-works-the-same-as-like-a-cdn

Is a Reverse proxy works the same as like a CDN

https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

https://velog.io/@joshua_s/CDN-%EC%84%9C%EB%B9%84%EC%8A%A4%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-%EC%86%8D%EB%8F%84%EB%A5%BC-%EC%98%AC%EB%A6%AC%EA%B8%B0

CDN 서비스를 이용하여 속도를 올리기

https://lascrea.tistory.com/167

AWS CloudFront(CDN)

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=kletgdgo&logNo=222235080499

(Cache) CDN 개념과 활용방법 정리

 

 

Q: 그럼 redis 캐시와 local 캐시의 차이점은 무엇인가요?

A: ...이 부분에 대해서 깊게 공부하지 못한 것 같습니다. 

 

( 생각해보니 조금은 단순하고 당연한 대답 😭 )

+A: local 캐시의 경우 local에서만 사용되는 캐시로 외부저장소의 네트워크 통신을 통해 캐시 저장소에 접근하고 데이터를 가져오는 과정드으이 오버헤드가 없기 때문에 속도는 빠르지만 local에서만 작동하기 때문에 다른 서버와 데이터 공유가 어렵습니다. 하지만 global 캐시의 경우(ex) redis) 여러 서버에서 Cache Server에 접근하여 사용하는 캐시로 local 캐시에 비해 네트워크 트래픽을 사용하여 상대적으로 느리지만 별도의 Cache Server를 이용하기 때문에 서버간의 데이터 공유가 쉽습니다. 또한 데이터를 복제(Replication)하거나 분산(Sharding)하여 저장할 수 있습니다. 

 

( 참고한 사이트 )

https://dev-jj.tistory.com/entry/%EC%BA%90%EC%8B%9CCache-Local-Cache-Global-Cache

•  

캐시(Cache) Local Cache & Global Cache

 

 

 

 

Q: CPU에서의 병목현상을 해결하는 방법은 무엇인가요?

A: CPU에서의 병목현상이 CPU를 처리량이 많아서 대기행렬이 발생하고 있을 떄와 CPU의 사용률이 오르지 않을 때로 나눌 수 있는데 대기행렬이 발생할 때는 scale out을 통해서 처리할 수 있고 사용률이 낮은 경우에는 네트워크 I/O나 디스크 I/O를 확인하여 해결할 수 있습니다.

 

+A: CPU에서의 병목현상은 먼저 CPU의 사용률이 높고 처리량이 많아서 대기행렬이 발생하고 있을 때와 응답 속도가 느릴때, CPU의 사용률이 낮을 때로 나눌 수 있다. 첫번째의 경우에는 CPU를 코어수가 많은 것으로 변경하거나 서브를 추가하여 병렬처리하도록 하여 처리량을 늘릴 수 있다. 그 다음, 응답 속도가 낮은 경우를 해결하는 첫번째 방법에는 클럭 수(초당 명령 처리 수)를 늘려 처리 능력을 향상시키는 방법을 이용할 수 있다. 하지만 클럭수를 늘리는 데에는 한계가 있고 public cloud를 사용할 때 cpu 클럭 수를 제어할 수 없다는 단점이 있어 극적인 개선 효과는 기대하기가 어렵다. 따라서 두번째 방법으로 처리를 분할하여 다수의 CPU 코어에게 병렬 처리로 동시 처리를 시키는 방법이 존재한다. 여기서 중요한 점은 처리를 병렬화 할 수 있는가가 된다. 세번째로 CPU 사용률 자체가 오르지 않을 때는 디스크 I/O나 네트워크 I/O에서 막히는 경우가 많이 때문에 발생하는 문제로 이 문제는 CPU 병목 현상보다 어플리케이션이 CPU, 메모리, I/O등의 하드웨어 리소스를 제대로 활용하지 못하는 것이 문제가 된다. 이 문제를 해결하기 위해서는 첫번째로 처리 다중화를 이용하여 쓰레드를 여러개 가동하여 동기 I/O 명령을 스레드 단위로 병행해서 실행하여 I/O 부하와 CPU 사용을 늘릴 수 있다. 두번째 방법은 I/O 를 비동기화하여 프로세스가 I/O 처리 완료를 기다리지 않고 다음으로 넘어갈 수 있도록 하는 것이다. CPU처리와 I/O 처리를 동시에 진행하기 때문에 사용상태가 개선될 수 있다. 

 

 

 

Q: CPU의 scale up과 scale out이 무엇이며 차이가 무엇인가요?

A: scale out은 cpu 자체의 수를 늘리는 것이고 scale up은 cpu 하나의 성능을 향상시키는 것입니다. 

 

( ✨ 리소스단위로 따로 설명하지 않기 때문에 device에서는 얘기하지 않으므로 scale-out, scale-up이 아닌 '코어를 늘린다', '클럭수를 늘린다'의 설명으로 진행하자 )

+A: CPU에서의 scale up은 코어 수를 늘리거나 서브를 추가하는 것을 의미하며 scale up은 클럭수(초당 명령 처리 수)를 늘려 처리 능력을 향상시키는 것을 의미하였습니다. 

 

 

 

Q: 이해가 잘 되지 않는데요. CPU에서의 두가지 경우 모두 scale out을 하면 병목현상을 해결할 수 있는 것은 마찬가지 아닌가요?

A: CPU 처리량이 많아서 대기행렬이 발생하고 있는 경우에는 CPU사용량이 많으므로 scale out을 통해서 해결하고 CPU의 응답 속도가 느린 경우에는 scale up을 통해서 처리하고 CPU 사용률이 낮은 경우에는 어디서 문제가 발생했는지...(횡설수설) 문제가 발생하는 환경을 파악하여 원인을 파악합니다.

 

+A: 두가지 문제 모두 CPU 수를 늘리는 방법으로 문제를 해결할 수 있으며 대신 응답속도가 느린 경우에는 처리를 병렬화하여 다수의 CPU 코어에게 병렬로 동시처리를 시켜야 합니다. 

 

 

 

 

 

 

( 아래부터는 내가 준비한 질문 )

---

Q: Restful API란 무엇인가요?

A: RESTful API란 Representational State Transfer로 자원에 대한 행위를 HTTP Method로 표현하고 자원을 URI로 표현하는 REST아키텍쳐를 스타일 을 따르면서 구현된 시스템을 말한다. REST는 자원 기반 구조의 4가지 속성 Addressablity(모든 정보를 URI를 통해 표현 가능), Connectedness(리소스는 주변의 연관 리소스와 연결되어 표현 가능), Statelessness(모든 요청은 1회성이고 이전 요청에 여향받지 않음), Homogeneous Interface(HTTP에서 제공하는 기본 method와 추가 method 2가지 총 6가지로 모든 동작을 정의)의 특징을 가진다. 

 

Q: Restful API의 특징은 무엇인가요?

A: RestAPI는 HTTP 프로토콜의 인프라를 그대로 사용하므로 HTTP 프로토콜의 장점(서버-클라이언트 구조, 무상태 프로토콜, 비연결성)과 함께 계층화 구조(클라이언트는 REST API서버만 호출하고 REST 서버는 다중계층으로 구성, 중간매체 사용 가능), 캐싱가능, 인터페이스 일관성(URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스를 사용)등의 특징을 지니고 있다. 

 

Q: 엔티티의 생명주기(상태)에 대해서 설명해주세요.

A:

• 비영속 : 영속성 컨텍스트와 전혀 관계 없는 상태
• 영속 : 영속성 컨텍스트에 관리되는 상태
• 준영속 : 영속성 컨텍스트에서 저장되었다가 불리된 상태
• 삭제 : 삭제된 상태 (영속성 컨텍스트와 데이터 베이스에서 entity 삭제)

 

Q: 엔티티 컨텍스트의 사용 이유(장점)에 대해 설명해주세요.

A: 

• 엔티티의 동일성을 보장
• 트랜잭션을 지원하는 쓰기 지연 -> 트랜잭션 커밋시점에 쿼리 날라감
• 변경 감지(더티 체킹) 기능
• 지연 로딩 기능

 

Q: JPA 저장 동작 과정을 설명해주세요.

A: JPA의 경우 트랜잭션 실행 단위안에서 동작하며 객체를 생성하고 엔티티 매니저에 의해서 생성된 객체를 영속성 컨텍스트에 등록한다. 이때 해당 객체는 1차 캐시에 저장되어 영속상태가 된다. 또한 insert 쿼리는 쓰기지연 SQL저장소에 저장이 되어 트랜잭션이 끝나는 시점에 쓰기 지연 SQL 저장소에 있는 쿼리문들이 flush가 되고 트랜잭션 커밋이 이루어진다.

 

Q: JPA 수정 동작 과정을 설명해주세요.

A: 수정할 엔티티를 조회하면 조회한 엔티티가 1차 캐시에 올라가고 영속상태가 되어 영속성 컨텍스트가 관리하는 상태가 된다. 조회한 데이터의 수정이 이루어지면 변경감지 기능을 이용하여 현재 1차 캐시의 엔티티와 1차 캐시에 등록된 상태의 스냅샷과 비교해서 변경내역을 확인하고 update 쿼리를 쓰기지연 저장소에 저장한다. 저장된 쿼리는 트랜잭션 커밋 끝나기 전에 실행된다. 

 

Q: JPA에서 기본 생성자가 필요한 이유와 기본 생성자가 private 일 수 없는 이유는 무엇인가요?

A: Spring Data JPA 에서 동적으로 객체를 생성할 때 Reflection API를 사용하게 되는데 Java Reflection 이란 구체적인 클래스 타입을 알지 못해도, 그 클래스의 메소드, 타입, 변수들에 접근할 수 있도록 해주는 자바 API(접근 제어자와 상관없이 런타임 시점에 클래스 객체를 동적으로 생성)를 말한다. 여기서 Java Reflection이 가져올 수 없는 정보 중 하나가 바로 생성자의 인자 정보들이기 때문에 기본 생성자 없이 파라미터가 있는 생성자만 존재한다면 java Reflection이 객체를 생성할 수 없게 된다. 따라서 JPA에서는 기본 생성자가 필요하다. 추가로 지연로딩이 적용될 때 진짜 객체를 상송받아 해당 기본 생성자를 이용하는 proxy 객체를 이용하는데 상속받을 부모의 기본 생성자가 private이라서 생성에 실패하기 때문에 기본생성자는 private일 수 없다. 

 

( 참고한 사이트 )

https://dundung.tistory.com/222

Reflection API와 JPA, Spring Bean

 

Q: 특정 엔티티를 영속화 할때 연관 엔티티도 영속화하고 싶으면 어떻게 해야하나요?

A: Cascade를 이용하여 영속성 전이를 이용하여 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할 수 있다. 단, 이는 연관관계를 맺어준다는 것은 아니며, 자식이 부모를 2개이상 가지고 있을 때 사용하면 안된다(단일 소유자를 지니고 라이프 사이클이 동일할 때 사용해야 한다).

 

Q: 사용자 로그인 인증방식에는 무엇이 있나요?

A: 세션(서버 저장)을 이용한 로그인 방식과 쿠키(방문자 저장)를 이용한 방식이 존재하는데, 세션을 이용한 로그인 방식의 경우 서버가 클라이언트 상태를 유지하고 있으므로 사용자의 로그인 여부 확인이 용이 하다는 특징이 있지만 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로 다수의 요청 발생시 부하가 심해지고 로드 밸런싱을 사용한 서버 확장을 이용하고자 하는 경우 세션의 관리가 어려워 진다는 단점이 있다. 

 

( 참고한 사이트 )

https://millo-l.github.io/Session-%EA%B8%B0%EB%B0%98-%EC%9D%B8%EC%A6%9D%EB%B0%A9%EC%8B%9D/

Session 기반 인증 방식

 

Q: DI(의존관계 주입)이란 무엇인가요?

A: 객체(Bean)를 스프링 컨테이너에 등록하고, 스프링 컨테이너에서 멤버 변수에 객체를 주입할 수 있게 해주는 것이다. (프레임워크에 의해 동적으로 주입되는 여러 객체간의 결합)

 

( 참고한 사이트 )

https://bbeomgeun.tistory.com/141

스프링 - 의존 관계와 DI, Ioc 컨테이너

 

Q: IOC(제어의 역전)이란 무엇인가요?

A: 

• 의존성 주입의 상위 개념
• 스프링 컨테이너가 필요에 따라 개발자 대신 인스턴스의 생성부터 소멸까지 컨테이너가 대신 Bean들을 관리 및 제어해주는 것을 말한다. (프레임워크)
• IOC 컨테이너는 DI를 통해 주입
• 프로그램 제어권을 프레임 워크가 가져가는 것으로 DI를 통해 달성
• 생성된 객체의 생명주기 전체에 대한 권리와 관리를 프레임워크가 담당, 개발자는 비지니스 로직에만 집중

 

Q: 스프링에서 IOC, DI를 사용하는 이유는 무엇인가요?

A: OCP, DIP, SRP

• single resposibility principle (SRP) : 단일 책임 원칙 (하나의 책임에만 집중(Bean 생성, 연결, 실행의 책임 분리)한다)
• Open/closed principle(OCP) : 개방-폐쇄 원칙 (확장에 열려있음)
• Liskov substitution principle (LSP) : 리스코프 치환 원칙
• Interface segregation principle (ISP) : 인터페이스 분리 원칙
• Dependency inversion principle (DIP) : 의존관계 역전 원칙 (추상화에 의존, 구체화에 의존하지 않음 -> 확장성 증가)

 

 

 

 

 

 

🌱 모의 면접 후기 

이번 모의 면접을 통해서 피드백을 받은 것이 많은데 먼저 공부한 내용을 말할 때 암기식으로 공부한 것이 많이 느껴지고 강의자료에서 조금만 벗어나도 많이 혼란스러워 하는 느낌이 난다는 피드백을 받았다. 🫠 (기본이 탄탄하지가 않아서 그렇다...!) OSI 7계층에 대한 질문과 답을 할 때 장비, 프로토콜, 특징에 대한 대답이 일관적이지가 않고 많이 섞여있고 체계화 되지 않은 느낌이 많이 났고, 한 질문 당 답변이 1분 이상 지속되면 안되고 간소화해서 답을 말한 후 다음 질문에서 추가적으로 답하는 것이 좋다는 것을 알게 되었다. 또, 한 질문에 추가 질문이 나오면 많이 혼란스러워 해서  추가질문에 대한 답을 알고 깊게 학습해야 한다는 피드백도 받았다. 추가질문에 답하지 못했던 flyway 추가부분이나 성능부분, CPU 병목을 설명하는 부분에 대해서는 추가적으로 공부를 진행해야 했다. 몽따 외워버린 OSI 7계층도 주절주절 말하니 혼란스런 공간이 되어버린,,, 🤦‍♀️

 

 

 

 

저번 모의면접때 내가 피드백을 너무 못드려서, 이번 모의 면접때 내가 질문자가 되어 답변을 듣고 드리는 피드백을 조금 더 자세하게 드리고 싶어서 메모를 하면서 진행을 해서 피드백을 더 상세히 드릴 수 있었던 것 같다! 이번 학습할 때는 주어진 것들에 대한 답을 어떻게 말해야 할지를 위주로 공부했다면, 다음부터는 내가 공부한 자료를 토대로 가상 질문을 뽑아보고 추가질문까지 예상해보는 방식으로 공부를 진행해야 겠다! 💪