부스트캠프 멤버십 7~8주차 회고

이번 주차에는 2명이서 같이 프로젝트를 진행했다. 게더타운처럼 실시간으로 캐릭터를 움직일 수 있고, 채팅도 가능한 서비스를 개발하는 것이 목표였다. 프로젝트는 리액트와 익스프레스를 사용하였으며, 실시간 기능을 위해 소켓을 사용하여 개발을 진행했다. 기능 개발과 별개로 Nginx와 Docker과 같은 DevOps나 Github Action을 사용한 CI/CD를 공부하고 적용해보았다.

😂 무엇이 어려웠나?

Nginx & Socket

서버를 배포할 때, Nginx를 사용하여 Express 앱을 프록시해주었다. 그런데 Nginx와 Socket.io를 같이 사용할 때는, Nginx 설정에서 설정해주어야 할 프록시 헤더들이 있다.

http {
  server {
    listen 80;
    server_name example.com;

    location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;

      proxy_pass http://localhost:3000;

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }
  }
}

Socket.io Docs에 나온 것처럼 Upgrade와 Connection 헤더의 값을 설정해주어야 했다. 해당 설정이 없으면 ws 프로토콜로 웹소켓에 접근할 때 핸드쉐이킹 과정이 제대로 되지않아 문제가 발생한다.

이 내용이 너무 기본적인 내용이라 그런지, 검색을 해봐도 명확히 설명해주는 곳이 거의 없었다. 그래서 우선은 설정을 적용한 후 나중에 다시 찾아보았는데, 괜찮은 글들이 있어 나중을 위해 링크를 남긴다... nginx에서 WebSocket Proxy 설정하기, NGINX 웹 소켓 프록시 설정, HTTP Connection 헤더 쉽게 알아보기

Upgrade와 Connection Header는 Hop by Hop Header에 속한다. Hop by Hop 통신에서는 특정 두 서버 간에만 영향을 미치고, 다른 서버 간에는 영향을 미치지 않는다. 그렇기에 Hop by Hop Header들은 다음 서버로 전달되지 않는다. 하지만, 클라이언트와 서버의 연결을 Web Socket으로 업그레이드하기 위해서는 위 두가지 헤더가 필요하다. 그래서 해당 설정을 추가해줘서, 다음 서버로 헤더를 넘겨주는 것이다.

Nginx 설정에 해당 코드를 추가하는 것은 설명이 되었고, 본론적으로 Connection과 Upgrade 헤더를 쓰는 이유도 알아야한다.
Connection 헤더는 연결을 유지하거나 끊는 용도로 사용되지만, 해당 경우처럼 통신을 다른 프로토콜로 업그레이드 하는 경우에도 사용할 수 있다. 해당 패킷이 Upgrade될 패킷임을 웹서버가 알 수 있도록 Connection 헤더에 Upgrade 값을 넣어준 것이다.
Upgrade 헤더는 이름에서 알 수 있듯이, 통신을 업그레이드하는데 사용한다. 기존의 클라이언트에서는 Upgrade: websocket처럼 헤더를 보내주었을 것이다. 그러면 nginx에서 $http_HEADER 변수를 사용하여, 기존의 Upgrade 헤더의 값(websocket)을 다시 Upgrade 헤더의 값으로 설정해주는 것이다.

정말 기본적인 내용인데, 내용을 이해하는데 상당한 시간이 걸렸고 아직 많이 부족하다는 것을 다시금 느끼게 됐다. 그래도 이 문제를 겪으면서 배운 것도 많고, 상당히 재미있었으니 만족스러운 결과이다.

개발 중인 서버의 관리

이전 부커톤에서도 겪었던 문제이긴 하지만, 이번에도 두명이서 같이 개발을 하다보니 백엔드 서버의 위치에 대해 고민을 많이 했다. 기본적으로 페어 프로그래밍으로 같이 개발을 진행하였지만, 단순한 기능들은 서로 분업으로 개발을 진행하였다. 이 과정에서 백엔드 서버를 개발하는 과정에서 약간의 불편함이 있었다.

서버의 배포를 내 nCloud 서버에 했었는데, 그러다보니 페어캠퍼가 백엔드 개발 이후 배포를 하는 과정에서 차질이 발생했다. 서버의 권한 관리나 민감한 정보를 관리하는 부분에서 불필요한 커뮤니케이션이나 실수가 종종 발생하였다.

개발을 할 때도 로컬에서 개발을 한 후, 따로 서버에 접근해서 배포를 계속 진행해야하니 여러모로 불필요한 소요도 많았다.

이 문제는 캠퍼분과 같이 Github Action을 이용한 CI/CD를 세팅하여 대부분 해결하였다. 이 것에 대한 말은 아래에서 더 하겠다...

✨ 무엇을 공부했나?

Socket.io

예전에 학교 수업에서 C로 Socket 연결을 해본 적이 있다. 그래서 그때의 기억을 떠올리며 Socket.io 문서를 보았을 때, 나는 충격을 금치 못하였다... 내가 생각했던 C에서의 Socket 레벨이 아닌 이미 추상화가 많이 되어 사용하기 편리한 소켓이었다. 덕분에 소켓을 연결하는 과정에서 시간을 쓰지 않고, 필요한 로직을 구현하는데 더 많은 시간을 쓸 수 있었다.

Socket.io에서 좋았던 점은 로직처리를 Event-Driven 방식으로 처리한다는 것이다. 특정 이벤트에 대한 동작을 정의해주고, 반대로 특정 이벤트와 데이터를 보내는 과정이 직관적으로 생각할 수 있어 좋았다.

위에서 설명한 것처럼 Nginx와 Socket.io를 같이 사용하면서 발생한 버그들이 있었다. 그 당시에는 왜 이런 것인지 이해가 안갔지만, 차근차근 공부하면서 더 많은 것들을 알게 되어 좋았다. 역시 사람은 실패에서 배우는 법인가 보다.

지난번보다 더 나아진 Nginx 지식 😎

조금 더 정확히 말하자면, Hop By Hop 통신이라는 개념에 대해 알게 되었다. 난 여러개의 서버를 걸쳐가더라도, 당연히 헤더와 같은 정보들은 유지되는줄 알았다. 그러나 Hop을 걸쳐가며 사라지는 헤더들이 있는 것을 배웠고, 그것을 유지시키는 방법 역시 배웠다. Nginx에서 제공하는 $http_HEADER 변수에 대해서도 알게 되었고, 아직 자세히는 모르지만 다른 변수들도 많다는 것을 알게 되었다.

아직은 많이 부족하지만, 계속 Nginx를 써보고 공부하다 보면 더 발전할 것이다. 나중에는 Nginx를 사용하여 로드밸런싱 하는 것도 해보고 싶다. 다음 그룹 프로젝트에서 적용해볼 수 있으면 좋겠다...

Docker

이번에는 Docker를 사용해봤다!! 웹 개발 공부를 하면서 해보고 싶었던 것 중 하나가 Docker + Nginx로 서버 기반을 만들어 보는 것이었다. 별다른 이유는 없었고... 멋져보였다. 저번 주에는 Nginx를 공부하고 적용해봤으니, 이번에는 개발을 진행하면서 틈틈히 Docker를 공부했었다. 그리고 주말에 Docker를 적용했고, 동료 캠퍼와 공유했었다.

서버를 이미지로 빌드하고, 컨테이너로 올려 실제 동작하는 것을 보니 정말 간단하고 느꼈다. 물론 아직은 기본적인 단계이고, 더 신경쓰고 고려해야할 부분이 많을 것이다. 그래도 한걸음씩 나아간다고 생각하니 마음이 뿌듯하다.

Github Action으로 CI/CD

Github Action을 통해 CI/CD를 적용할 수 있다는 것을 알게되었다. 이전부터 CI/CD를 써보고싶다고 생각을 했지만, 어디서부터 접근을 해야할지 막막했었다. 젠킨스라는 CI/CD 도구가 있는 것은 알고있었지만, 이를 위한 서버를 만들고 세팅을 하는 과정이 너무 긴 여정처럼 느껴졌다.

그러던 도중 이번 프로젝트에서 Github Action을 사용하여 CI/CD를 구성해보라는 요구사항이 나왔었다. 비록 선택사항이라 하지않아도 됐었지만, 나는 이 요구사항만은 꼭 해보고 싶었다. 다행히 내 동료 캠퍼분도 이 요구사항만큼은 꼭 해보자고 하였다. 그래서 개발을 진행하면서 꾸준히 공부하고, 주말에 같이 모여서 CI/CD를 구현해보았다.

아무래도 처음 해보는 작업이라 어떤 식으로 구성하는 것이 좋은지는 잘 몰랐다. 그래서 여러 게시글들을 참고하였고, 우리가 중요하게 여기는 것들이 포함되도록 구성하였다.

CI는 우리가 정한 Lint 규칙이 제대로 적용되었는지, Typescript 빌드가 제대로 되는지를 보았다.
CD는 우리가 nCloud 서버에 배포를 진행하였기에, SSH 접근으로 nCloud에서 레포지토리를 최신화하고 pm2를 reload하는 방식으로 구성하였다. 한가지 아쉬운 점은 위에서 말했듯이 Docker를 사용해보았는데, 아직 경험과 지식이 적어서 CD과정에 추가하지는 못하였다. 다음 그룹 프로젝트에서는 꼭... 해보고 싶다!

협업!

같이 공부하고 개발하는 경험은 많으면 많을수록 좋다고 생각한다. 이번 프로젝트가 2인 페어 프로그래밍으로 진행되면서, 또 한번의 색다른 경험을 할 수 있어서 좋았다. 그리고 웹 개발을 다른 사람들과 같이 해본 적은 이전의 부커톤을 제외하면 없었기 때문에 더 좋은 기회였던 것 같다.

이번 프로젝트에서는 협업을 위해 여러가지 툴들을 사용하였다.
우선 코드의 통일성을 위해 esLint와 Prettier를 사용했다. 사실 나는 esLint는 약간 접해보았지만, Prettier는 처음 접해보는 것이었다. 혼자 개발을 할때는 Prettier의 도움이 없이도 나의 기준에 맞게 코드를 작성하는 것이 쉬웠다. 그러나 이번에는 같이 개발을 해야하니 Prettier를 통해 코드 포맷을 통일시키려 했고, 나는 매우 만족했다. 아무래도 개발을 하다보면 코드 포맷이 지저분해지거나 어떻게 해야할지 애매할 때가 있다. 그럴 때, 우리가 설정한 대로 Prettier가 포맷을 맞추어주니 굉장히 편했다. 다음부터는 혼자 개발할 때도 프로젝트 부피가 커질 것 같으면 Prettier를 쓰는걸 고려해봐야겠다.

페어 프로그래밍을 위해서 VSCode의 Live Share Extension를 사용하였다. 줌으로 같이 얘기하면서 Live Share를 이용해 같이 개발을 하거나, 상대가 개발하는 것을 지켜보았다. 이 Live Share가 생각보다 좋다고 느낀 것이, 나는 단순히 편집기 정도만 공유되는 줄 알았다. 그런데 터미널 뿐만 아니라 내 로컬로 실행한 서버 프로그램에도 접근이 가능했다. 이러한 기능들이 페어 프로그래밍을 하는데 큰 도움이 되었다. 코드의 작성 뿐만 아니라 프로그램의 테스팅까지 같이 도와줄 수 있었기에 정말 좋았었다.

같이 협업한다는 것이 점차 중요해지다보니 이와 관련된 도구들 역시 점점 발전해나가는 것 같다. 아는 것이 힘이라고, 이런 도구들을 잘 알면 알수록 협업하는 것도 점차 쉬워질 것 같다.

🎈 맺음말

학습 스프린트는 이번이 마지막이다. 이제 다음주부터는 6주동안 그룹 프로젝트를 진행한다. 학습 스프린트를 하면서 얻은 경험들이 그룹 프로젝트에 큰 도움을 줄 것이다. 그룹 프로젝트에서는 더 많은 것을 배우고, 더 많은 경험을 하여야겠다.