[면접] 프로젝트 면접 (29~32)

29. HTTP METHOD 에 대해서 아는만큼, 중요하다고 생각하는 순서로 설정해주세요

  "HTTP 메서드의 중요성은 그 사용 빈도와 애플리케이션에서의 역할에 따라 다르지만, 일반적으로 가장 자주 사용되며 핵심적인 메서드부터 설명드리겠습니다. 첫 번째로, GET 메서드는 정보를 조회하는 가장 기본적인 방법으로, 웹 애플리케이션 개발에서 빼놓을 수 없는 메서드입니다. 두 번째로, POST 메서드는 서버에 데이터를 제출하여 리소스를 생성하는 데 사용되며, 폼 제출이나 메시지 전송에 주로 쓰입니다. 세 번째, PUT 메서드는 기존 리소스를 업데이트하거나 새 리소스를 생성할 때 사용됩니다. 네 번째, DELETE 메서드는 리소스를 삭제하는 데 사용되며, 마지막으로 PATCH 메서드는 리소스의 일부를 업데이트할 때 사용됩니다. 이 메서드들은 RESTful API 설계의 기본이 되며, 각기 다른 상황에서 데이터의 생성, 조회, 수정, 삭제를 가능하게 하는 중요한 역할을 합니다."

 

꼬리질문 > GET 메서드와 POST 메서드는 어떤 상황에서 각각 사용되며, 왜 그러한가요?
  "GET 메서드는 데이터를 조회할 때 사용되며, 서버에 어떠한 데이터도 변경하지 않는 안전한(사이드 이펙트가 없는) 요청에 적합합니다. 예를 들어, 사용자가 웹 페이지를 열거나 검색을 수행할 때 주로 GET 요청이 사용됩니다. GET 요청의 가장 큰 특징은 쿼리 파라미터를 URL에 포함시켜 데이터를 전송한다는 점이며, 이로 인해 캐싱, 북마크, 공유가 용이합니다.

반면, POST 메서드는 서버의 상태나 데이터를 변경할 때 사용됩니다. 사용자가 폼을 제출하거나 서버에 새 리소스를 생성할 때 주로 사용되며, 데이터는 요청 본문에 포함되어 서버로 전송됩니다. POST 요청은 데이터의 양에 제한이 없으며, 보안상 URL에 민감한 데이터를 노출시키지 않아야 하는 경우에 적합합니다.

이처럼 GET과 POST 메서드는 웹 애플리케이션에서 데이터를 처리하는 기본적인 방식을 제공하며, 각각의 메서드가 적합한 상황에서 사용되어야 합니다. 이를 통해 애플리케이션의 기능성과 효율성을 최대화할 수 있습니다."

 

30. 팔로우한 사용자들의 활동을 실시간으로 보려면 어떻게 해야할까요?

  "팔로우한 사용자들의 활동을 실시간으로 볼 수 있는 기능을 구현하기 위해서는, 서버와 클라이언트 간의 양방향 통신이 가능하게 하는 기술을 사용해야 합니다. 가장 일반적인 접근 방법은 웹소켓(WebSocket)을 활용하는 것입니다. 웹소켓을 사용하면 서버는 클라이언트의 초기 요청을 받은 후에도 클라이언트에 데이터를 지속적으로 푸시할 수 있게 되므로, 사용자가 페이지를 새로고침하지 않아도 최신 활동을 실시간으로 볼 수 있습니다.

또 다른 방법으로는 Server-Sent Events(SSE)를 사용할 수 있습니다. SSE는 서버에서 클라이언트로 텍스트 스트림을 실시간으로 전송할 수 있게 해주며, 웹소켓에 비해 구현이 간단합니다. 하지만 SSE는 클라이언트에서 서버로는 단방향 통신만 지원한다는 제한이 있습니다.

이러한 기술을 활용하여, 사용자가 팔로우하는 다른 사용자들의 활동 정보를 데이터베이스에 저장하고, 해당 정보가 업데이트 될 때마다 웹소켓 또는 SSE를 통해 연결된 모든 클라이언트에게 이를 알려주는 방식으로 실시간 업데이트 기능을 구현할 수 있습니다. 이 과정에서 메시지 큐나 스트림 처리 시스템을 활용하여 확장성과 안정성을 높일 수도 있습니다."

 

꼬리질문 > 웹소켓 대신 Server-Sent Events(SSE)를 사용하는 경우는 어떤 상황인가요? 
  "Server-Sent Events(SSE)는 클라이언트에서 서버로의 통신이 필요하지 않거나, 단방향 데이터 스트림이 요구되는 경우에 이상적인 선택입니다. 예를 들어, 실시간 뉴스 피드, 주식 가격 업데이트, 또는 실시간으로 변경되는 대시보드 정보 등을 사용자에게 전달하는 상황에서 SSE를 사용할 수 있습니다. SSE는 HTTP 프로토콜을 사용하므로, 웹소켓에 비해 구현이 간단하고 기존의 웹 인프라와 호환성이 높다는 장점이 있습니다. 또한, 자동 재연결 기능이 내장되어 있어 네트워크 연결이 끊겼을 때 서버로부터 다시 연결을 시도하는 로직을 간소화할 수 있습니다. 그러나 클라이언트에서 서버로의 이벤트를 전송해야 하는 인터랙티브한 어플리케이션에서는 양방향 통신을 지원하는 웹소켓이 더 적합할 수 있습니다. 따라서, 애플리케이션의 요구 사항과 특성을 고려하여 두 기술 중 적절한 것을 선택해야 합니다."

 

31. 예약 구매 시 발생할 수 있는 문제들의 트레이드 오프 시 어떤 기준으로 우선순위를 매기셨나요?

  "예약 구매 시스템에서 발생할 수 있는 다양한 문제들에 대한 우선순위 설정은 서비스 운영과 고객 경험에 미치는 영향력을 기준으로 하였습니다. 가장 중요하게 다룬 문제는 서비스 불가 상태로, 트래픽 몰림으로 인한 서버 다운이 이에 해당합니다. 이는 서비스의 가용성과 신뢰성을 직접적으로 저하시키기 때문에 최우선으로 해결해야 하는 문제로 인식되었습니다.

두 번째로 중요도를 둔 문제는 상품 페이지의 재고 수 불일치였습니다. 이는 고객의 구매 결정에 혼란을 주고, 서비스에 대한 불신을 조성할 수 있기 때문에, 고객 만족도와 직결되는 중요한 요소로 간주되었습니다.

세 번째는 결제 화면 진입 후 결제 불가 문제로, 고객이 구매 결정을 한 후 마지막 단계에서 겪는 문제이기 때문에 고객 만족도에 큰 영향을 미칩니다.

네 번째 문제인 최종 결제 수 초과는 재고 관리의 신뢰성을 떨어뜨리며 고객 신뢰 손상을 초래할 수 있습니다.

마지막으로, 오픈 시간 이전 구매 가능 문제는 상대적으로 중요도가 낮지만, 운영 정책 및 보안에 관련된 중요한 문제로 인식되었습니다.

이러한 문제들의 트레이드 오프는 서버 용량 증설, 실시간 재고 관리 시스템 도입, 결제 시스템의 안정성 개선 등과 같은 해결 방안을 도입하는 것과 연관되어 있습니다. 각 해결책은 단기적으로는 비용 증가와 기술적 복잡성 증가라는 한계를 가지지만, 장기적으로는 고객 만족도 향상과 서비스 신뢰성 강화를 통해 경쟁력을 증진시킬 수 있습니다. 따라서 우선순위는 이러한 장단기적 영향을 고려하여 결정되었습니다."

 

꼬리질문 > 서버 다운과 같은 서비스 불가 상태를 예방하기 위해 어떤 기술적 조치를 취하셨나요?
  "서비스 불가 상태, 특히 트래픽 몰림으로 인한 서버 다운을 예방하기 위해, 우리 팀은 여러 기술적 조치를 취했습니다. 첫째로, 서비스의 부하 분산을 위해 로드 밸런서를 도입했습니다. 이는 고객의 요청을 여러 서버에 균등하게 분배하여 단일 서버에 과부하가 발생하는 것을 방지합니다. 둘째로, 자동 확장성이 있는 클라우드 인프라를 사용하여 트래픽의 변동에 따라 서버 용량을 실시간으로 조절할 수 있게 했습니다. 이를 통해 예기치 않은 트래픽 증가에도 원활하게 대응할 수 있습니다. 셋째, 재고 관리와 결제 시스템의 안정성을 높이기 위해 분산 데이터베이스 시스템을 적용하고, 트랜잭션 관리를 강화했습니다. 마지막으로, 장애 대응 계획을 수립하고 정기적인 스트레스 테스트를 실시하여 시스템의 안정성을 지속적으로 모니터링하고 개선해 나갔습니다. 이러한 조치들을 통해, 우리는 서비스의 가용성과 신뢰성을 크게 향상시킬 수 있었습니다."

 

32. Blocking과 NonBlocking에 대해 말씀해주세요.

  "블로킹(Blocking)과 넌블로킹(Non-Blocking)은 프로그래밍에서 I/O 작업이나 다른 리소스에 접근할 때의 동작 방식을 설명하는 용어입니다. 

블로킹 방식은 호출된 함수가 자신의 작업을 모두 마칠 때까지 호출한 함수의 실행을 멈추게 하는 동기 처리 방식을 의미합니다. 예를 들어, 파일 시스템에서 데이터를 읽을 때, 블로킹 호출은 데이터 읽기 작업이 완료될 때까지 프로그램의 다음 줄로 넘어가지 않습니다. 이는 프로그램의 흐름이 단순해지는 장점이 있지만, I/O 작업의 완료를 기다리는 동안 CPU가 다른 유용한 작업을 할 수 없다는 단점이 있습니다.

반면, 넌블로킹 방식은 호출된 함수가 즉시 반환하여 호출한 함수가 실행을 계속할 수 있도록 하는 비동기 처리 방식을 말합니다. 넌블로킹 호출은 데이터 읽기 같은 작업이 완료되지 않았더라도 대기하지 않고 즉시 제어권을 반환합니다. 그 결과, 프로그램은 다른 작업을 계속 처리할 수 있으며, 작업 완료 여부는 폴링(Polling), 콜백(Callback), 프로미스(Promise), 이벤트 리스너(Event Listener) 등 다양한 방법으로 확인할 수 있습니다. 넌블로킹 방식은 시스템 자원을 효율적으로 사용할 수 있지만, 프로그램의 흐름 관리가 복잡해질 수 있다는 단점이 있습니다.

결국, 블로킹과 넌블로킹의 선택은 애플리케이션의 요구 사항, 성능 목표, 그리고 개발의 복잡성을 고려하여 결정되어야 합니다."

 

꼬리질문 > 블로킹과 넌블로킹 방식을 사용할 때, 어떤 상황에서 각각의 방식을 선택하는 것이 적합한가요?
  "블로킹 방식은 작업의 완료가 현재 실행 흐름에 중요하거나, 다른 작업으로의 전환 비용이 높을 때 적합합니다. 예를 들어, 서버가 시작할 때 필요한 설정 파일을 로드하는 경우, 파일 읽기 작업의 완료를 보장받아야만 서버가 정상적으로 기능할 수 있으므로 블로킹 방식이 선호됩니다. 이러한 상황에서는 작업의 완료를 기다리는 것이 전체 시스템의 안정성과 정확성을 보장하는 데 중요합니다.

넌블로킹 방식은 시스템의 자원을 효율적으로 활용하고, 동시에 다수의 작업을 처리해야 하는 고성능 애플리케이션에 적합합니다. 예를 들어, 웹 서버가 다수의 사용자 요청을 동시에 처리해야 하는 경우, 각 요청을 넌블로킹 방식으로 처리함으로써, 한 요청이 I/O 작업에 의해 블로킹되는 동안에도 다른 요청들을 계속 처리할 수 있습니다. 이는 리소스의 유휴 상태를 최소화하고 전체적인 시스템의 처리량을 높이는 데 기여합니다.

따라서, 블로킹 방식은 단일 작업의 완료가 중요한 경우나 작업 흐름이 간단하고 예측 가능할 때 유리하며, 넌블로킹 방식은 시스템의 처리량과 자원 활용도를 최대화하고자 할 때, 특히 비동기적 작업 처리가 필수적인 고성능 서버나 애플리케이션 개발에 적합합니다."