원본 사이트를 보며 만들었고 질문을 하나하나 적어보는 것과 나중에 채워가는 것이 도움이 되리라 생각하고 적습니다.
Information
백엔드 개발자를 준비하면서 받았던 면접 질문, 학습했던 내용, 예상가능한 질문을 선별했습니다.
이 저작물은 CC BY-NC(저작자 표시-비영리)입니다.
기여를 통해서 더 좋은 컨텐츠가 될 수 있도록 해주세요.
이 컨텐스의 목표는 가능하면 간단하게 면접질문에 대답을 할 수 있도록 하는 것입니다.
당연히 세부적인 지식에 대한 꼬리 질문이 들어올 수 있으니, 깊이 있게 공부하는 것을 권장합니다.
신입 포지션에 대한 질문의 모음이기 때문에 경력직의 면접질문은 정리하지 않았습니다.
제가 Java를 주로 사용해서 타 언어에 대한 지식이 부족합니다. 보통 그 언어를 많이 사용해보았는지 정도의 문제가 출제됩니다. 기여가 가능하시다면 부탁드립니다.
백엔드 포지션은 면접 전 검증을 위해 과제 전형을 보는 경우도 많지만, 코딘테스트를 보는 경우가 훨씬 많습니다.
이 저장소를 잘 사용하기 위한 팁
문제를 보고 음성메모로 답을 해봅시다. 그리고 음성 메모를 들으면서 자신이 알고 있는 것이 잘 전달되는지 확인합시다.
문제에 대한 내용에 대한 답변은 상당히 간추린 내용이기 때문에, 누락되거나 불필요하다 판단하여 덜어낸 부분이 존재할 수 있습니다. 그리고 정답이라고 할만한 것이 존재하지 않는 문제도 존재하기 때문에 '이 사람은 이렇게 답변했겠구나' 정도로 받아들이시는 것을 권장합니다.
예제 답변 그대로 답변하면 좋겠지만, 최대한 짧고 간결하게 대답해야만 면접자 입장에서 좀 더 유리합니다. 궁금하면 면접관님께서 꼬리질문으로 깊이있게 물어보실 것이빈다.
추가로 아래 내용에 보충을 하고 싶다면, issue 혹은 PR로 기여를 해주세요. 저도 초보 개발자이기 때문에 틀리거나, 잘못되 내용이 있을 수 있습니다.
모의 면접을 도와줄 지인이 있다면 모의 면접을 부탁해서 실제 면접처럼 수행하면 더욱 실전에서 도움이 될 것 같습니다.
이 주제들을 가지고 학습을 하는 것도 도움이 많이 될 것이빈다.
면접 전 정보
과제 전형
과제 전형은 애플리케이션 서버를 만들거나, 아니면 특정 프로그램을 작성하는 과제로 나눠질 수 있습니다.
팁을 드리자면 출제 의도를 파악하려고 노력한 코딩을 하셔야합니다. 그리고, 면접에서 관련된 질문이 나올 수 있으니 사용해 본 기술이거나 처음 사용했더라도 학습을 해두셔야합니다. '왜 이 기술을 사용했는가?', '이 기술 말고 다른 선택지는 없는가?' 정도의 질문은 예상해 볼만한 질문이니 대비릴 해둡시다. 과제가 통과되었다면 끝난 것이 아닙니다. 그 과제에서 더 개선할 부분은 무엇인지, 확장 포인트는 어디인지까지 고민해봅시다.
과제 전형 자체가 약간 새로운 시도레 가깝기 때문에 정답은 없습니다. 본인이 할 수 있는 최선을 다해서 해당 언어의 철학에 맞는 코드를 작성해봅시다. 가령 객체지향 프로그래밍 언어라면, '재사용성', '변경에 유연함'을 염두해 두고 개선 포인트를 잡아봅시다. 또, 해당 회사의 기술스택을 확인하고 이를 적용할만하다면 적즉적으로 사용해 봅시다. 최신 기술에 유연한 사고를 갖고 있다는 인상을 줄 수도 있습니다.
코딩테스트
코딩테스트는 여러 플랫폼이 잇으며, 요즘은 프로그래머스를 많이 사용하고, 언어는 Python을 추천합니다.
제가 추천하는 학습 방법은 2개월 정도를 잡고 코딩테스트 관련 서적은 한 권 끝내거나, 우형별 문제를 푸는 것이고, 여유가 있다면 1~2시간 풀어보고(난이도마다 상이)풀었다면 시간 복잡도를 생각하고, 다른 풀이는 없는지 고민해봅시다. 대략 이 정도 수준의 공부를 하시고, 실력을 유지하기 위해서 꾸준히 한 두 문제씩 풀어봅시다. 저는 코딩테스트가 약한편이어서 더 많은 팁을 드릴 수 는 없을 것 같네요.
알고리즘 코딩테스트가 재밌다면 모르겠지만 저처럼 그리 즐겁지 않으신분은 너무 자존심을 깎아가면서 까지 준비하지는 마시는걸 추천드립니다.
안풀리면 풀이를 보고 이해하시고, 이해가 가지 않는 문제는 현재의 나에겐 너무 어려운 문제일 뿐입니다. 나중에 다시 풀 때, 풀이 없이 풀려고 노력해보고, 같은 과정을 반복해봅시다.
실제 코딩테스트를 볼 때에는, 코드에 주석을 달아두는 편이 유용합니다. 내가 어떻게 풀려고 했는지 의도를 전잘할 수 있기 때문입니다. 내가 작성한 코드를 문제와 함께 정리해둡시다. 합격한다면 어떤 질문이 나올지 생각해봅시다.
또, 너무 유형위주의 학습을 하다보면 모든 문제를 유형적으로 분류해서 풀려고 하는 잘못된 접근을 할 수도 있습니다.
문제를 이해하고, 문제를 해결할 수 있는 여러 방법을 고려해서 최적의 방법을 선택해봅시다. 문제를 해결하는 방법은 여러 방법이 있을 수 있습니다.
이 저작물은 크리에이티브 커먼즈 저작자 표시-비영리 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.
CS 관련 지식
네트워크
웹 통신의 큰 흐름:https://www.google.com/을 접속할 때 일어나는 일
면접 단골 문제입니다. 면접관 입장에서는 한 질문으로 많은 답변을 들을 수 있기 때문에 대부분의 면접자리에서 나왔던 문제입니다. OSI 7계층과도 연관지어 설명하라는 질문을 받은 적도 있습니다.
브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송 요청을 합니다. 이 때, Domain으로 요청을 보낼 수 없기 떄문에 DNS Lookup을 수행합니다.
DNS 룩업 과정은 크롬의 경우 브라우저 --> hosts 파일 --> DNS Cache의 순서로 도메인에 매칭되는 ip를 찾습니다.
hosts 파일
hosts파일이란 호스트 네임에 대응하는 IP주소를 저장하는 파일로서, DNS 서버에서 주소정보를 제공받지 않고도 서버의 위치를 찾게하는 파일 입니다.OS 별로 가지고 있으며, DNS 서버가 존재하기 전(1984)에 아이피 주소를 매핑하는 테이블로서 사용하였다.
현재는 그 역할을 DNS서버가 잘 해주고 있기 때문에 일반적인 상황에서 사용할 일을 드물다.
일반적으로 설명하는 DNS Lookup은 루트 도메인 서버에서부터 서브 도메인 서버순으로 찾게 됩니다.
이 요청은 찾은 IP주소와 함께 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 의해 패킷에 담기고 패킷에 제어정보를 덧붙여 LAN어댑터에 전송하고, LAN 어댑터는 이를 전기 신호로 변환시켜 송출합니다.
패킷은 스위칭 허브등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.
액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다. 고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 됩니다.
핵심부를 통과한 패킷을 목적지의 LAN에 도착하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사합니다.
웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘깁니다. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전잘된 방식 그대로 전동됩니다.
TCP와 UDP의 차이점에 대해서 설명해보세요.
TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램 단위로 정송하는 프로토콜입니다.
TCP는 가상회선을 만들어 신뢰성을 보장하도록 (흐름제어, 혼잡 데어, 오류 제어)하는 프로토콜로 따로 신뢰성을 보장하기 위한절차가 없는 UDP에 비해 속도가 느린 편입니다.
TCP는 그래서 파일 전송과 같은 신뢰성이 중요한 서비스에 사용되고,
UDP는 스트리밍, RTP와 같이 연속성이 더 중요한 서비스에 사용됩니다.
RTP(Real-time Transport Protocol)
실시간 음성 과 영상 및 데이터를 IP네트워크로 전송하는 표준 프로토콜
RTP는 RTCP(Real-time Control Protocol)를 이용해 데이터의 전달 상황을 감시 및 최소한의 제어 기능과 미디어 식별 기능들을 제공사용되는 분야:
전화, WebRTC, 텔레비전, 웹 기반의 푸시 투 토크 기능을 초함한 화상 통화 분야, 스트리밍 미디어를 수반하는 통시느 엔터테이먼트 시스템RTP에서 데이터를 일정하게 송신하는 방법:
송신가는 일정한 간격으로 데이터를 송신하지만, 인터넷이라는 망의 환경에 의해 지연이 다르게 되어 가변적인 간격으로 도착,
영향을 끼치는 종류로 대역폭, 네트워크 구조, 라우팅 방식, 전송 프로토콜의 종류
하지만 실시간 환경에서 수신 프로세스에 도착하는 전송 간경이 그대로 유지되는 것이 중요하기 때문에 버퍼를 이용해 가변적인 간격으로 도착하는 데이터를 즉시 수신사에 보내지 않고 지연 버퍼를 통해 다시 일정한 간격으로 보정해주는 역할을 수행RTP의 데이터 전송 프로토콜:
RTP는 빠른 전송 기능을 지우너하기 위해 UDP프로토콜위에서 구현되엉 ㅣㅅ으며, 데이터 그램의 분실이나 도착순서 변경등의 오류를 RTP에서 해결하는 구조로 이루어져있다.
포트 주소 기능을 이용하면 송수신 프로세스 간의 연결을 관리할 수 있다.
프로그램 하나를 단위로 하지 않고, 일부 기능이 개별적으로 구현되어 있다.
응용 서비스의 종류에 따라 요구조건이 다른 기능을 추가하는 형식을 취하고 있음
다수의 사용자가 하나의 세션을 사용하여 실시간 데이터 전송이 가능하게 만들어짐RTP는 두 종류의 RTP릴레이를 지원
믹서와 트랜슬레이터
데이터 전송 과정에 송수신 프로세스가 직접 데이터를 전송할 수 없는 상황인 방화벽 사용이나 데이터 형식이 상이한 경우 데이터를 중개하는 기능
믹서는 여러 송신 프로세스의 데이터그램을 적절히 조합해 새로운 데이터그램을 생성
ex) 영상과 음성을 믹싱하여 새로운 동영상 생성
트랜슬레이터는 입력되는 각 RTP데이터그램을 하나 이상의 출력용 데이터 그램을 만들어주는 것으로 수신자의 환경에 맞게 바꾸어 주는것을 의미
+) 하지만 UDP도 신회성을 UDP자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있습니다. 그래서 HTTP/3은 QUIC이라는 프로토콜을 기반으로 하는데, QUIC은 UDP기반으로 합니다.
즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있습니다.
출처 (자세한 설명이 나와 있으므로 해당 사이트를 꼭 들어가 확인하는 것을 추천합니다)
+) TCP와 UDP 헤더의 차이
이렇게 TCP는 기존에 규정되어 있는 수 많은 헤더의 값들로 인해 개발자가 직접 커스텀 할 수 잇는 자리가 남아있지 않다(옵션 필드의 최대 크기는 320 bits이다.)
즉 정확히 UDP는 데이터 전송을 제외한 그 어떤 기능도 정의도어 있지 않은 프로토콜 이기 때문에 신회성을 보장하지 않는것
google이 발표한 QUIC의 장점으로는
1. 연결 설정시 레이턴시 감소.
QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3 Way Handshake를 거치지 않아도 된다.
(사이트의 출처에 따르면 TCP + TLS는 3 RTT(Round Trip Trme), QUIC는 1 RTT가 요구된다고 한다.)
이것이 가능한 이유는 첫 번째 핸드 쉐이크를 거칠 때, 연결 설정에 필요한 정보와 데이터까지 한 번에 보내는 것이다.
TCP+TLS는 데이터를 보내기 전에 신뢰성있는 연결과 암호화에 필요한 모든 정보를 교환하고 유효성을 검사한 뒤에 데이터를 교환하지만, QUIC는 묻지도 따지지도 않고 그냥 바로 데이터부터 꽂아버리고 시작한다.TCP + TLS는 서로 자신의 세션 키를 주고 받아 암호화된 연결을 성립하는 과정을 거치고 나서야 세션 키와 데이터를 교환할 수 있지만, QUIC은 서로의 세션 키를 교환하기도 전에 데이터를 교환할 수 잇기 때문에 연결 설정이 더 빠르다는 것
단, 클라이언트가 서버로 첫 요청을 보낼 떄는 서버의 세션 키를 모르는 상태이기 떄문에 몬ㄱ적지인 서버의 COnnection ID를 사용하여 생성한 특별한 키인 초기화 키를 사용해 통신을 암호화 한다.
그리고 한 번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가, 다음 연결 떄는 캐싱해놓은 설정을 사용하여 바로 연결을 성립시키기 떄문에 0 RTT 만으로 바로 통신을 시작할 수도 있다.
참고로 지금은 TCP Fast Open과 TLS 1.3을 사용해 비슷한 과정을 통한 연결을 설정함으로써 TCP를 사용해도 동일한 이점을 가져갈 수 있지만,
패킷의 제한에 있더 더 큰 데이터를 주고 받아야 할 경우 QUIC가 여전히 유리하다고 한다.
TCP 3, 4 way handshake에 대해서 설명해보세요.
TCP가 가상회선을 만들고 제거하는 과정에 대해서 묻는 질문, TCP를 공부했다면 이정도는 알겠지 하고 묻는 문제이고, 실제 면접자리에서는 보통 네트워크에 대해 설명할 때, 직접 설명하는 편임
TCP 3 way handshake는 가상회선을 수립하는 단계입니다.
클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정입니다.
SYN, ACK 패킷을 주고 받으며, 임의의 난수로 SYN플래그를 전송하고, ACK플래그에는 1을 더한 값을 전송하빈다.
정확한 순서는 SYN(n) --> ACK(n+1), SYN(m) --> ACK(m+1) 순으로 일어납니다.
더 자세한 설명을 해주는 사이트 주소
간단한 비유를 들자면
1. (a가 b에게) b야 내말 잘 들리니?
2. (b가 a에게) ㅇㅇ 잘들려! a야 너도 내말 잘 들리니?
3. (다시 a가 b에게) ㅇㅇㅇ! 잘 들려!
같은 방식으로 서로 의사소통이 할 환경이 잘 구성되어 있는지 확인하는 과정이다.
[STEP 1]
A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는SYN_SENT 상태가 되는 것이다.[STEP 2]
이때 서버는 Listen 상태로 포트 서비스가 가능한 상태여야 한다. (Closed :닫힌상태) B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.[STEP 3]
A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다. 이때의 B서버 상태가 ESTABLISHED 이다.
왜 임의의 난수를 지정하느냐의 꼬리 질문이 나올 수 있습니다.
기존 요청과 구분하기 위해서 정도로 알고 있고, 그 이상은 생각해본적이 없네요.
TCP 4 way handshake는 TCP연결을 해제하는 단계로, 클라이언트는 서버에게 견결해제를 통지하고, 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제됩니다.
단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트측에서는 일정시간 대기하는데, 혹시 패킷이 나중에 도착할 수 있기 때문입니다.
HTTP와 HTTPS의 차이점에 대해서 설명해보세요.
http는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로책 수 있고, 수정할 수 있습니다. 따라서 보안이 취약해짐을 알 수 있습니다.
이를 보완하기 위해 나온 것이 https입니다. 중간에 암호화 계층을 거쳐서 패킷을 암호화합니다.
HTTPS에 대해 설명하고 SSL Handshake에 대해서 설명해보세요.
https는 http에 보안 계층을 추가한 것입니다. https는 제3자 인증, 공개키 암호화, 비밀키 암호화를 사용합니다.
제3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고,
공개키 암호화는 비밀키를 공유하기 위해 사용합니다.
비밀키 암호화는 통신하는 데이터를 암호화하는데 사용합니다.
이를 통해 통신하는 데이터를 암호화 할 수 있고, 통신하려는 상대를 보증할 수 있게 됩니다.
클라이언트는 TCP 3 way handshake를 수행한 이후 Client Hello를 전송합니다. 서버는 인증서를 보냅니다.(다른 정보들도 전송하나 검색을 통해 알 수 있는 부분입니다. 대개 그정도까지는 요구하지 않습니다.)
클라이언트는 받은 인증서를 신뢰하기 위해서 등록된 인증기관인지 확인합니다. 이 인증서는 인증기관의 개인키로 암호화되어 있고, 공개키로 검증할 수 있습니다.(브라우저에 내장되어 있음) 클라이언트는 사이트의 정보와 서버의 공개키를 얻을 수 있습니다.
서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냅니다.
서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신합니다.
제3자 인증: 인증서, 인증기관/공개키 암호화: 인증서, 비밀키 공유/비밀키 암호화: 통신과정
왜 공개키 암호화와 비밀?(대칭)키 암호화를 복합적으로 사용했는지도 질문을 받았습니다.
==> 공개키 방식은 일반적으로 대칭키에 비해 느리기 때문입니다.
+) 잘 이해가 안되어 추가 사이트를 찾아 보고 정리하겠습니다.(사이트)
SSL 동작 방식:
공개키 암호화 방식과 공개키의 단점을 보완한 대칭키 암호화 방식을 함께 사용한다.(공개키 방식은 느리다는 단점이 있다.)공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.
공개키 방식:
- A키로 암호화를 하면 B키로 복호화 할 수 있다.
- B키로 암호화를 하면 A키로 복호화 할 수 있다.
- 둘 중 하나를 비공개키 혹은 개인키라 부르며, 이는 자신만 가지고 있고 공개하지 않는다.
- 나머지 하나는 공개키ㅏ라 부르며 탕니에게 제공한다. 공개키는 유충이 되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전하다.
대칭키 방식:
- 암호화 할 때 사용하는 비밀번호를 키라고 한다. 대칭키는 동일한 키로 암호화, 복호화가 가능하다.
- 대칭키는 매번 랜덤으로 생성되어 누출되어도 다음번에 사용할 때에는 다른 키가 사용되기 때문에 안전하다.
- 공개키 보다 빠르게 통신할 수 있다.
이런 SSL방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지 보장하는 역할을 한다. 이러한 인증서를 발급하는 기관은 CA(Certificate authority)라고 부른다. 공인인증기관의 경우 브라우저는 미리 CA 리스트와 함께 각 CA의 공개키를 알고 있다.
인증서 발급 과정과 함께 어떤 식으로 사이트가 안전하게 사용자와 통신하는지 알아보자.
- 인터넷 사이트는 자신의 정보와 공개키를 인증기관에 제출한다.
- 인증기관은 제출된 데이터 검증절차를 거쳐 개인키로 사이트에서 제출한 정보를 암호화한다. ==> 인증서 발급
- 인증기관은 웹 브라우저에게 자신의 공개키를 제공한다.
여기까지가 인증서가 발급되는 과정이다. 사용자가 사이트에 접속할 경우 그 다음은 어떻게 될까?
- 사용자가 사이트에 접속하면 자신의 인증서를 웹 브라우저에게 보낸다.
- 웹 브라우저는 미리 받았던 인증기관의 공개키로 인증서를 해독하여 검증한다. 그러면 사이트의 공개키를 알 수 있게 된다.
- 이렇게 얻은 사이트 공개키로 대칭키를 암호화해서 다시 사이트에 보낸다.
- 사이트는 개인키로 암호문을 해독해 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고 받을 수 있게 된다.
(주목할 만한 점은 대칭키를 만들어 내는 주체가 웹 브라우저 즉 클라이언트 쪽이라는 사실이다..!)아 후의 통신의 서로의 대칭키를 통해 검증하며, 통신이 끊기면 대칭키는 버려지게 되어 안전한 사용이 가능하게 한다.
GET, POST의 차이점에 대해서 설명해보세요.
대개의 경우 애라의 HTTP메서드 질문을 더 많이 합니다. 하지만 둘의 차이만을 물을 수도 있습니다.
GET요청의 경우 서버에 존재하는 정보를 요청합니다.
이 때 반환되는 정보는 정보 자체가 아니라 정보의 표현입니다.(뒤의 내용은 REST와 연관이 있고, 굳이 답변하지 않으셔도 됩니다.) 일반적으로 Request Body는 입력하지 ㅇ낳는 것이 일반적이며, 레거시 시스템의 경우 요청을 받아들이지 않을 수 있습니다. 캐싱을 수행하기 때문에 캐싱되지 않는 요청을 GET요청이 맞지 않을 수 있습니다.
POST요청은 서버에 정보를 생성하는 것을 요청합니다. 예전 HTTP통신은 POST 요청으로 데이터 삭제, 수정도 form요청으로 같이 수행했습니다.
POST요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않습니다.
보통 Request Body에 요청하는 데이터를 담아 전송합니다.
HTTP 메서드와 이것이 하는 역할에 대해서 설명해보세요.
보통 REST API를 설계했다면 이해할 수 있을 정도로 설명하면 되는 것 같습니다.
OPTIONS, HEAD, TRACE의 존재에 대해서는 알아만 둡시다. 특시 TRACE는 몰라도 되는 것 같습니다. OPTIONS는 해당 uri에 대해 서버가 허용하는 메서드를 확인할 때 사용합니다. HEAD는 GET과 비슷하나 header만 가져옵니다.
- GET요청은 서버에 존재하는 데이터를 요청하는 것입니다. CRUD로 치면 R입니다.
- POST요청은 서버에 데이터를 생성하는 것을 요청합니다. CRUD로 치면 C입니다.
- PUT요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다. CRUD로 치면 C, U입니다.
- DELETE요청은 서버에 데이터를 제거할 것을 요청합니다. 존재하지 않아도 동일하게 동작합니다. CRUD의 D입니다.
- PATCH요청은 서버에 존재하는 데이터를 일부 수정합니다.
더 나아가서 불필요한 메서드는 허용하지 않고 필요한 메서드만 허용하는 Whitelist방식으로 관리합시다. 자세한 내용은 HTTP Method 취약점에 대해 검색합시다.
+) 이는 악의적인 사용자가 OPTIONS 메소드를 통해 보이진 않지만 사용가능한 메서드들을 확인하고 이를 통해 불필요한 데이터를 업로드하거나, 삭제하는 행위를 방지하기 위한 방법이다.
RESTful 이란 뭇이며, 이것에 대해서 아는대로 설명해보세요(보충 필요)
REST는 굉장히 난해한 개념입니다. 하지만 REST가 무엇인지 대략의 감은 잡아둡시다. REST API를 설계했다면 충분히 물어볼만한 질문입니다.
HTTP URI를 통해 자원을 표시하고 HTTP Method를 통해 자원에 대한 처리를 표현합니다.
사람이 읽을 수 있는 API라는 것이 특징입니다.
HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영합니다.
또한별도의 인프라 구축이 필요없습니다.
단점으로는 명확한 표준이 존재하지 않는다는 점,
RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점(그런 REST API로 괜찮은가 참고링크텍스트),
REST API가 분산환경에 적합하지 않다는 점(멱등성을 본장하기 힘들기 때문)
HATEOAS라는 개념이 있는데, 동적인 API를 제공ㅇ할 수 있게 됩니다.(모든 관련된 동작을 URI를 통해 알려줍니다.)
즉, 클라이언트가 API의 변화에 일일이 대응하지 않아도 된다든 장점을 가지고 있습니다.
CORS란 무엇이며 이것에 대해서 설명해보세요.
CORS는 웹개발을 하다가 흔히 만날 수 있는 이슈입니다. 개개는 프론트엔드 개발시에 로컬에서 API서버레 요청을 보낼 떄 흔하게 발생합니다.
서로 다른 도메인간에 자원을 공유하는 것을 뜻합니다. 대부분의 브라우저에서는 이를 기본적으로 차단하며, 서버측에서 헤더를 통해서 사용가능한 자원을 알려줍니다.
preflight request는 실제로 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. OPTIONS메소드로 여청하며 CORS를 허용하는지 확ㅇ니합니다.
CORS가 허용된 웹서버라면 사용가능한 리소스를 헤더에 담아 응답합니다.
OSI7계층과 그 존재 이유, TCP/IP 4계층에 대해 설명해보세요.
OSI 7계층은 네트워ㅡ 통신을 구성하는 요소들 7개의 계층으로 표준화한 것 입니다.
이렇게 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해집니다.
실제로 우리가 대부분 사용하는 네트워크는 TCP/IP 4계층입니다. 통신에 실제로 사용되는 계층이고 1, 2계층이 1 계층, 5, 6, 7계층이 4계층으로 운영됩니다.
운영체제
프로세스와 스레드의 차이를 설명해보세요.
프로세스는 실행중인 프로그램을 의미합니다.
(추가 설명: 프로그램이 메모리에 올라와 있고, OS의 스케줄러에 의해 CPU에 의해 처리되고 있는 프로그램을 뜻합니다.)
스레드는 실행제어만 분리한 것을 의미합니다.
(추가 설명: 스레드는 프로그램에서 하나의 실행흐름으로, 모든 프로그램은 하나 이상의 쓰레드를 가지고 있으며, 프로세스가 할당받은 자원을 이용하는 실행의 단위이다.)
메모리는 (Stack, Heap, Code, Data)영역이 있다.
스레드는 프로세스가 할당받은 메모리내에서 Stack 영역만을 고유로 가지고 있으며, 나머지 메모리 영역들(Heap, Code, Data)는 공유하여 사용한다.
이러한 공유 메모리 영역을 이유로 컨텍스트 스위칭이 빠르다는 장점도 있지만, 데이터를 덮어버린다든가 오용할 요지가 있어 더욱 신경써서 프로그래밍을 해야 합니다.
Context Switching이란?
CPU의 처리 속도는 하드디스크나 네트워크, 마우스, 키보드에 대한 처리보다 훨씬 빠르기 때문에 여러 작업을 번갈아 실행하는 것이 효율적인 사용입니다.
이것을 실행하기 위해선 현재 진행했던 Task(Process, Thread)의 상태를 저장하고 다음 진행할 Task의 상태값을 읽어 적용하는 과정을 말합니다.
프로그램의 상태(Context == PCB(Process Control Block))
인터럽트에 의해 context switching이 일어나게 되며 이 일 역시 자원(CPU)를 사용하는 일이므로 필요 이상의 context-switching은 오히려 성능 저하를 일으킬 수 있습니다.
이때 쓰레드에서 context- switching이 일어날 경우 Stack영역만 변경하면 되므로 시간이 더 단축됩니다.
동기와 비동기의 차이(블로킹, 넌 블로킹) / 장단점에 대해 섦여하시오.
동기/비동기는 두 개 이상의 무엇인가가 시간을 맞춘다/안맞춘달 구분할 수 있습니다.
동기 방식은 메서드 리턴 결과를 전달받는 시간이 일치하는 명령 실행 방식이빈다.
또 동기 방식은 한 함수가 끝나느 시간과 다음 함수가 시작하는 시간이 같습니다.
비동기 방식은 여러 개의 처리가 함께 실행되는 방식으로, 동기 방식에 비해 단위 시간단 많은 작업을 처리할 수 있습니다.
단, CPU나 메모리를 많이 상용하는 작업을 비동기로 처리하게 되면 과부하가 걸릴 수 있습니다.
프로그램의 복잡도 역시 증가합니다.
블로킹/논블로킹은 동기/비동기와 다른 관점으로, 내가 직접 제어할 수 없는 대상(IO/멀티스레드)을 상대하는 방법에 대한 분류이빈다.
블로킹 방식은 대상의 작업이 끝날 때 까지 제어권을 대상이 가지고 있는 것을 의미합니다.
논블로킹은 대상의 작업 완료여부와 상관없이 새로운 작업ㅇ르 수행합니다.
동기 논블로킹은 계속해서 polling을 수행하기 때문에 context switching이 지속적으로 발생해 지연이 발생합니다.
멀티 스레드 프로그래밍에 대해 설명해보세요.
멀티 스레드 프로그래밍은 하나의 프로세스에서 여러개의 스레드를 만들어 자원의 생성과관리의 중복을 최소화화는 것을 멀티 스레드프로그램이이라고 합니다.
장점:
- 멀티 프로세스에 비해 메모리 자원소모가 줄어듭니다.
- 힙 영역을 통해서 스레드간 통신이 가능하여 프로세스간 통신보다 간단합니다.
- 스레드의 컨텍스트 스위칭은 프로세스의 컨텍스트 스위칭보다 빠릅니다.
단점:
- 힙 영역에 있는 자원을 사용할 때는 동기화를 해야합니다.
- 동기화를 위해서 락을 과도하게 사용하면 성능이 저하될 수 있습니다.
- 하나의 스레드가 비정상적으로 동작하면 다른 스레드도 영향을 받을 수 있습니다.(종료)
Thread-safe 하다는 의미와 설계하는 법을 설명해보세요.
두 개 이상의 스레드가 race condition에 들어가거나 같은 객체에 동시게 접근해도 연산결과의 정합성이 보장될 수 있게끔 메모리 가시성이 확보된 상태를 의미합니다.
- java.util.concurrent 패키지 하위의 클래스를 사용합니다.
- 인스턴스 변수를 두지 않습니다.
- Singleton패턴을 사용합니다.(이 때, 일반적으로 구현하는 Singleton Pattern은 Thread-safe 하지 않습니다.
참고 - 동기화 블럭에서 연산을 수행합니다.
프로세스 동기화에 대해 설명해보세요.
다중 프로세스 환경에서 자원 등에 한 프로세스만이 접근가능하도록 하는 것입니다.
프로세스 동기화를 하지 않으면 데이터의 일관성이 깨지기 때문에 연산결과가 잘못 반환될 가능성이 존재하기 때문에 주의해야 합니다.
Race Condition(경쟁 상태): 여러 프로세스나 스레드가 동기화 메커니즘 없이 자원에 접근하려는 상황을 가리킵니다. 공유된 자원에 대한 접근 순서에 따라 실행 결과가 달라질 수 잇는 상황을 의미합니다.
Critical Section(임계 구역): 여러 스레드가 동시에 접근해서는 안되고 공유자원에 접근하는 코드블럭을 말합니다. 한 임계구역에 하나의 스레드 혹은 프로세스만 접근이 가능합니다. 임계 구역에 접근하는 것을 제어하기위해 세마포어, 뮤텍스와 같은 매커니즘을 사용합니다.
임계 구역 문제를 해결하기 위한 조건(모두 충족해야 함)
- 상호 배제(Mutual Exclusion): 한 프로세스가 임계구역에서 동작중이면 다른 프로세스는 접근할 수 없다.
- 진행(Progress): 임계구역에서 작업중인 프로세스가 없다면 임게구역으로 진입하려는 프로세스를 적절히 제어해 진입할 수 있도록 합니다.
- 유한 대기(Bounded Waiting): 한 프로세스가 임계영역으로 진입을 요청한 후 다른 프로세스는 진입이 유한한 횟수로 제한되어야 합니다.(기아상태 방지)
교착상태와 기아 상태의 해결방버에 대해 설명해보세요.
교착상태: 서로 다른 프로세스가 서로 점유하고 잇는 자원의 반납을 대기하고 있는 상태
발생 조건:
- 상호 배제: 한 번에 한 프로세스만 해당 자원을 사용할 수 있어야 합니다.
- 점유 대기: 할당된 자원을 가진 상태에서 다른 자원을 기다립니다.
- 비선점: 다른 프로세스가 자원의 사용을 끝낼 때 까지 자원을 뺏을 수 없습니다.
- 순환 대기: 각 프로세스가 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있습니다.
해결방법:
- 예방: 4가지 조건 중 하나라도 만족되지 않도록 합니다.
- 회피: 알고리즘을 데드락이 발생하지 않도록 합니다.
- 회복: 교착상태가 발생할 때, 해결합니다.
- 무시: 회복과정이 성능저하가 심하다면 그냥 무시합니다.
기아 상태(Starvation): 여러 프로세스가 부족한 자원을 점유하기 위해 경쟁할 때, 특정 프로세스가 영원히 자원 할당이 되지 않는 경우입니다.
우선순위를 변경합니다.(수선순위를 수시로 변경하거나, 오래 기다릴 수록 높은 우선순위를 부여합니다.)
세마포어와 뮤텍스의 차이에 대해 설명해보세요.
세마포어는 여러개의 프로세스가 접근 가능한 공유자원을 관리하는 방식이고, 뮤텍스가 될 수 있지만,
뮤텍스는 한 번에 한 개의 프로세스만 접근 가능하도록 관리하는 방식입니다.
따라서 뮤텍스는 세마포어가 될 수 없습니다.
또, 세마포어는 다른 프로세스가 세마포어를 해제할 수 있지만, 뮤텍스는 락을 획득한 프로세스만 락을 반환할 수 있습니다.
