48일차-7/24 토 -항해99

하루 회고

• 내 기획에 좋은 느낌이 들었다.

나는 1주차 부터 6주차까지 모든 팀에서 내 기획을 구현해왔다. 어떤 팀을 만나던 미리 준비한 기획이 있었고, 항상 내 기획이 채택되어 왔다. 그래서 이번에도 기획을 했고, 모두의 마음을 샀다.

하지만 마음을 사는 것, 그것으로는 부족하다. 나는 왠지 이 상태로 시작한다면 중간에 팀원들중 누군가라도 지금 이 코드를 왜 짜는지 목적을 잃을 것이라는 생각이 들었다. 미리부터 걱정한다 라고 생각할 수도 있지만 원래 걱정은 미리부터 하는거다. 누군가 중간에 길을 잃기 전에 초반에 기획과 이 프로젝트에 대해 잘 설명했다.
솔직히 하루 종일 설명을 했고 같은 부분을 꽤 많이 반복해서 설명했다. 5번 이상 같은 부분을 설명한 파트도 있었다. 하지만 팀원들이 프로젝트를 이해하고 시작하는게 기획자인 나에겐 정말 중요하다고 생각됐다.
  이것이 회사를 운영하는 CEO님들이 직원들에게 회사일을 내일처럼 생각해라 라는 마인드인가..?
  너무 꼰대 스럽지않나 라고 생각될 수 있지만, 이 역할을 수행하니 십분 이해가 된다.

이런 기획자가 되는 경험을 항해99에서 매 주차마다 하니 이런 부분까지 생각하게 되어서 정말 좋은 경험이 되고 있다. 나중에 회사의 기획자로서 일을 해봐도 좋을 것 같다. 아직 갈길은 머니까 항해가 끝나고 계속 기획해서 토이프로젝트 경험을 많이 하고 싶다. 취직을 위함이 아니라 정말 회사를 다니면서도 기획과 토이프로젝트들을 해보고싶다는 욕심이 생긴다.

주저리 주저리

• 우리 14조 올랜덤으로 구성되었지만 끝은 랜덤이 아닌 무조건 완성되어 구현이 된다는 마인드.
    그리고 나의 개발은 while true로 계속 될거니까 매 순간 최선을 다하자는 마인드이다.

오늘 배운 것

• WebSocket "기존 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜.

일반 Socket통신과 달리 HTTP 80 Port를 사용하므로 방화벽에 제약이 없으며 통상 WebSocket으로 불린다.

접속까지는 HTTP 프로토콜을 이용하고, 그 이후 통신은 자체적인 WebSocket 프로토콜로 통신하게 된다." 웹 소켓은 HTTP(Hyper Text Transfer Protocol)를 사용하는 네트워크 데이터 통신의 단점을 보완하는데 그 목적이 있다.

• 모든 HTTP를 사용한 통신은 "클라이언트가 먼저 요청을 보내고, 그 요청에 따라 웹 서버가 응답하는 형태이며 웹 서버는 응답을 보낸 후 웹 브라우저와의 연결을 끊는다. 양쪽이 데이터를 동시에 보내는 것이 아니기 때문에 이러한 통신 방식을 반이중 통신(Half Duplex)라고 한다."

WebSocket 이전엔 HTTP 요청방식인 Polling이나 Long Polling, Streaming등의 방식으로 해결했었다.

• Polling "클라이언트가 평범한 HTTP Request를 서버로 계속 요청해 이벤트 내용을 전달받는 방식. . 가장 쉬운 방법이지만 클라이언트가 지속적으로 Request를 요청하기 때문에 클라이언트의 수가 많아지면 서버의 부담이 급증한다.. HTTP Request Connection을 맺고 끊는 것 자체가 부담이 많은 방식이고, 클라이언트에서 실시간 정도의 빠른 응답을 기대하기 어렵다."
• Long Polling "클라이언트에서 서버로 일단 HTTP Request를 요청한다.. 이 상태로 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 Response 메세지를 전달하며 연결이 종료된다.. 곧이어 클라이언트가 다시 HTTP Request를 요청해 서버의 다음 이벤트를 기다리는 방식.. polling보다 서버의 부담이 줄겠으나, 클라이언트로 보내는 이벤트들의 시간간격이 좁다면 polling과 별 차이 없게 되며, 다수의 클라이언트에게 동시에 이벤트가 발생될 경우 서버의 부담이 급증한다."
• Streaming "Long Polling과 마찬가지로 클라이언트 -> 서버로 HTTP Request를 요청한다.. 서버 -> 클라이언트로 이벤트를 전달할 때 해당 요청을 해제하지 않고 필요한 메세지만 보내기(Flush)를 반복하는 방식. . Long Polling과 비교하여 서버에 메세지를 보내지 않고도 다시 HTTP Request 연결을 하지 않아도 되어 부담이 경감된다고 한다."
• WebSocket "웹소켓은 클라이언트가 접속 요청을 하고 웹 서버가 응답한 후 연결을 끊는 것이 아닌 Connection을 그대로 유지하고 클라이언트의 요청 없이도 데이터를 전송할 수 있는 프로토콜이다. 프로토콜의 요청은 [ws://~]로 시작한다." 웹소켓은 HTTP환경에서 전이중 통신(Full Duplex, 2-way communication)을 지원하기 위한 프로토콜이며 RFC6455에 정의되어 있다. HTTP 프로토콜에서 HandShaking을 완료한 후, HTTP로 동작하지만, HTTP와는 다른 방식으로 통신을 한다.
• 주요 특징 "WebSocket이 기존의 TCP Socket과 다른 점은 최초 접속이 일반 HTTP Request를 통해 HandShaking 과정을 통해 이뤄진다는 점이다.

HTTP Request를 그대로 사용하기 때문에 기존의 80, 443 포트로 접속을 하므로 추가 방화벽을 열지 않고도 양방향 통신이 가능하고, HTTP 규격인 CORS 적용이나 인증 등 과정을 기존과 동일하게 가져갈 수 있는 것이 장점이다."

• 언제 써야 효율적인가? "웹소켓은 서비스를 동적으로 만들어 주지만, Ajax, Streaming, Long polling 기술이 더 효과적일 경우도 있다. 예를 들어, 변경 사항의 빈도가 자주 일어나지 않고, 데이터의 크기가 작은 경우 Ajax, Streaming, Long polling 기술이 더 효과적일 수 있다. 즉, 실시간성을 보장해야 하고, 변경 사항의 빈도가 잦다면, 또는 짧은 대기 시간, 고주파수, 대용량의 조합인 경우 WebSocket이 좋은 해결책이 될 수 있다."