Project Tech Log

Project Tech Log

목차

• 1주차 - 서비스 기획 + 개발 세팅 + 브랜치 전략
• 2주차 - 인프라 + 개발환경 설정(husky + ESLint)
• 3주차 - 캐릭터 애니메이션 + 실시간 움직임 표시
• 4주차 - 게임 예외상황 + socket test + 소켓 재연결 이슈
• 5주차 - 캐릭터 움직임 버그 + OAuth 로그인
• 6주차 - 사운드 + 도메인 + 엄격한 채팅 길이 검사 + 애니메이션 추가
• 7주차 - 리팩토링

1주차 - 서비스 기획 + 개발 세팅 + 브랜치 전략

기획, 어떤 아이템으로 정할 것인가?

• 웹 게임 (OX 퀴즈)
  • websocket으로 실시간 통신 구현 (실시간 협업 툴의 작동원리인 소켓 통신 경험)
  • MVC 패턴 실습이 가능
  • 게임 로직으로 인한 복잡성 관리를 경험
  • 팀이 개발하면서 재미를 느낄 수 있는 기획

개발 세팅 (개발 도구, 개발 환경, 코딩 컨벤션)

• 개발 도구 : VSCode
• 개발 환경 : Client, Server 둘 다 ES6+, ES Module 방식으로 구현
• 코딩 컨벤션 : ESLint를 사용해 컨벤션을 통일. airbnb를 따르고, 추가적으로 팀의 기호에 맞춰 세부사항을 조율
  • else 안 쓰고 if와 return을 이용해서만 분기
  • space 2칸 & 한 줄 100자 제한으로 들여쓰기를 줄이고 한 줄에 많은 내용이 들어갈 수 있게 했다.
  • Class의 private 메서드를 표현하기 위해 underscore를 사용
  • ES5 trailing comma를 사용 등

브랜치 전략

• git-flow를 참고하고 프로젝트 규모에 맞게 간략화
  • 궁금하다면, 이 링크를 참고!

이슈 관리 도구, CI 도구

• GitHub 프로젝트, GitHub issues
  • 학습 기간 동안 꾸준히 사용했던 도구들이고, github과 연동이 쉽고 잘 되어있다.
• travis
  • jenkins와 비교. jenkins와 다르게 서버가 따로 필요 없는 등 간단하고 필요한 기능(docker 환경 이용)들이 모두 지원됐기 때문에 채택했다.
  • 정리 링크

2주차 - 인프라 + 개발환경 설정(husky + ESLint)

인프라 구성 방향

• 프로젝트 구성은 Minimize + Dockerize

  • 사용할 서비스도 최소화한다.
  • React 파일 제공하는 서버 없이, production build react 파일을 정적 파일 배포 기능이 있는 NGINX에서 배포하기로 결정했다.
  • 이에 따라 사용할 서비스는 NGINX, Node.js app, MySQL 3가지로 정했다.
  • 또한 3가지 서비스는 NCP의 단일 서버를 사용해 docker-compose로 실행하기로 했다.

• Docker

  • Docker 학습 목적 (Docker의 확장 용이성 등)

Dockerize 이슈

• Production build React 파일을 가진 NGINX docker 이미지
  • 처음 생각했던 방식은 React 파일들이 있는 client 폴더로 이동한 뒤, npm run build를 통해 production build를 만들고, 만들어진 파일을 NGINX 설정 파일이 있는 폴더로 이동하고자 했다.
  • 하지만, dockerfile에선 폴더를 다른 폴더를 이동하는 명령어는 불가능했기에 client 폴더에 NGINX 설정 파일을 넣고, docker 이미지를 client 폴더에서 빌드 하기로 했다.
  • 또한 빌드 하는 과정에서 2가지 이미지를 사용하는데, 두 이미지 빌드 과정에서 파일이 공유되지 않는 문제가 있었다. 이를 COPY의 --from 옵션을 통해 해결할 수 있었다.

Travis CI 이슈

최신의 develop 브랜치 코드 적용하기

• Travis CI 처음 적용했을 때, 어떤 브랜치든 Pull Request 시 모두 개발 서버에 자동 배포될 수 있도록 설정했었다. 그 이유는 현재 작업 결과가 NCP의 개발 서버에서도 잘 작동하는지 바로 확인하고자 했기 때문이다.
• 그러나 반영된 결과물이 develop 브랜치에 있는 코드는 포함되지 않았었다. 그 이유는 PR 시 최신의 develop 브랜치가 자동으로 반영된 뒤 docker 이미지 빌드 하는 것이 아니고, PR를 한 브랜치에 있는 코드로만 docker 이미지를 빌드 하기 때문이었다.
• 이를 2가지 방법으로 해결하였는데, 먼저 Pull Request 시 develop을 해당 기능 구현 브랜치에 pull 받고 PR 보내는 것, 그리고 PR는 test만 하게 하고, 자동 배포는 develop, master 브랜치에 merge(push) 될 때만 실행되도록 설정했다.

배포 방식에 따른 설정

• master와 develop 브랜치에 merge 될 때만 배포하고 싶었다. 그런데 merge 관련 설정이 존재하지 않았다.
  • master나 develop 브랜치에 merge가 되면 push가 일어난다.
  • master와 develop 브랜치에 push 할 때만 배포하도록 설정했다.

husky + ESLint

• 프로젝트 setting을 하며 ESLint rule을 정하고 VScode 설정을 했다. 또한 husky라는 commit lint를 발견하였고 commit style도 통일성을 주고 싶었다. 하지만 husky rule 설정 변경에서 조금 어려운 부분이 있었다. 우리가 사용할 type으로 husky 설정을 바꿔야 하는데 리서치해도 잘 나오지 않았다. -> package.json에서 commitlint 설정에 rule을 적용할 수 있었다.

3주차 - 캐릭터 애니메이션 + 실시간 움직임 표시

canvas

• 많은 움직임이 실시간으로 표현되어야 한다. DOM의 직접적인 조작보다 성능이 훨씬 빠른 canvas를 사용했다.

sprite

• 걷는 모양을 보여주기 위해 일정 프레임마다 이미지를 바꿔줘야 했는데, 이미지의 경로를 변경(img.src = "...") 하거나 이미지 객체를 재생성(new Image()) 하는 것보다 그려내는 영역만 바꿔주는 것(drawImage(...))이 비용이 더 적기 때문에 sprite 이미지를 사용했다.

캐릭터:캔버스 = 1:1

• 캐릭터가 움직인 후에는 그전 위치의 캐릭터 이미지는 지워줄 필요가 있다. 그런데 그렇게 되면 겹치는 영역에 있던 다른 캐릭터가 지워지는 이슈가 있었기 때문에 캐릭터가 생성될 때마다 새로운 canvas를 생성해서 각각 canvas를 가지게 했다.
• 하나의 canvas에서 매번 모든 캐릭터를 지웠다가 다시 그릴 수도 있었지만, 여러 캐릭터의 움직임이 빈번하게 일어나는 서비스에서 매 움직임마다 모든 캐릭터를 지우고 다시 그려주는 것보다는 각각의 canvas에서 일이 수행되게 하는 게 더 효율적이라고 판단했다.

requestAnimationFrame

• 움직이는 애니메이션을 위해, 캐릭터 이미지를 모션에 맞게 바꾸고 위치를 이동시키는 로직을 일정 프레임마다 반복적으로 수행해야 했다. 이를 위해 setTimeout이 아니라 requestAnimationFrame 함수를 재귀적으로 호출하는 방식을 선택했다. 이 함수는 브라우저가 실제 화면을 그리는 주기에 따라 지정된 함수를 호출하기 때문에, 자바스크립트로 작성된 로직이 프레임 시작 시에 호출되도록 보장한다. 이런 방식으로 하면 프레임이 누락될 일도 없고, 일정 간격으로 로직을 수행하는 것이 보장되기 때문에 매끄러운 애니메이션을 표현하기 위해 적절하다고 판단했다.

캐릭터 움직임 실시간 표시

• 모든 캐릭터의 움직임이 모든 사용자들에게 동일하게 보여야 했다. 이를 위해서 서버에서 여러 유저들의 키보드 입력을 받아 움직일 수 있는 위치인지 계산 후, 모든 유저들에게 해당 캐릭터의 움직임을 알려주게 했다.

충돌 검사

• 다이내믹한 게임 요소를 위해, 여러 캐릭터의 움직임을 실시간으로 보여줄 뿐만 아니라 다른 캐릭터가 있는 위치에는 이동하지 못하게 해서 서로 길을 막을 수 있게 하려고 했다. 캐릭터 간 충돌을 검사하기 위해서는 각 이미지 간의 거리 값을 계산하거나 겹쳐져 있는 픽셀의 투명도 값을 검사해야 했는데, 게임 엔진 없이 모든 픽셀 값을 빠르게 계산하기에는 무리가 있다고 판단했다. 그래서 캐릭터마다 위치할 수 있는 칸을 만들고, 각 칸에는 하나의 캐릭터만 들어갈 수 있게 해서 충돌과 비슷한 인터랙션을 구현했다.

4주차 - 게임 예외상황 + socket test + 소켓 재연결 이슈

게임 예외 상황

• 웹게임이라는 특성상, 게임 중에 방 나가기 버튼을 막아놓아도 뒤로가기나 탭 닫기를 통해 언제든지 게임을 쉽고 빠르게 나갈 수 있었다. 때문에 예상보다 너무 잦은 유저들의 이탈로 인해 게임 진행상의 예외 상황이 많았다.
• 게임이 진행되지 않는 상태에선 유저의 잦은 유입/이탈이 예외 상황을 발생시키진 않았지만, 게임 진행 중에서 유저가 나가게 된다면, 게임 로직이 쉽게 뒤엉켜 살아있는 유저가 없는데도 게임이 계속 진행되는 등의 버그 및 예외 상황을 마주하였다. 이를 해결하기 위해, 게임 시작 후 매 라운드의 시작 및 종료 시점에 인원 및 현재 라운드를 확인하여 게임 진행에서의 예외 사황을 제거할 수 있었다.

socket 재연결 이슈

• 한번 연결되면 계속 해당 socket으로 유저를 구분해서 서비스를 이용하게 하고 싶었다. 그런데 서비스에 소켓 연결을 해서 접속 후에, 일정 시간이 지나면 연결이 끊기고 다시 재연결되는 이슈가 있었다. socket.io를 이용한 연결의 기본 옵션이 polling 방식이기 때문이었는데, 옵션으로 websocket을 줘서 해당 이슈를 해결할 수 있었다.
• polling 방식은 주기마다 요청을 보내고 응답을 받으면서 연결을 유지하는 방식이기 때문에 연결이 주기적으로 끊기고 오버헤드도 발생한다. websocket 방식은 connection을 계속 유지하기 때문에 오버헤드도 적고 연결이 주기적으로 끊기지도 않는다.

socket test

• socket test에 대한 자료가 많지 않아서 어려움을 겪었지만 socket-io를 활용하면 mock client를 생성할 수 있고, 서버는 번들링된 app.js를 이용해서 테스트를 위한 서버로 생성해 줄 수 있었다. mock client와 생성한 서버를 이용해서 socket test를 작성했다.
• 위 방법으로 특정 socket event에서 제대로 된 응답과 데이터가 오는지 확인할 수 있었고, event들간의 흐름도 테스트할 수 있었다.

5주차 - 캐릭터 움직임 버그 + OAuth 로그인

캐릭터 움직임 버그

• 실제 서버에서 저장하고 있는 캐릭터들의 위치와, 실제로 클라이언트가 표시하는 화면에서 보이는 위치가 다른 이슈가 발견되었다. 더불어 여러 사용자간에도 서로가 위치가 다르게 보였다.
• 원인1: 소켓
  • 소켓 통신은 연결지향이기 때문에, 무차별적으로 들어오는 사용자들의 입력에 대해 제어하기가 힘들었다. 거의 동시다발적으로 들어오는 움직임 이벤트들은 모두 비동기로 병렬적으로 실행된다. 그리고 대부분 같은 자원을 사용하기 때문에, 동일 자원을 동시에 읽고 쓰면서 자원이 원하지 않게 변경되어 위치가 꼬이는 버그가 발생했다.
• 원인2: requestAnimationFrame
  • 매끄러운 애니메이션을 위해 requestAnimationFrame 함수를 사용했는데, 이 함수는 성능과 최적화를 위해 화면이 보이고 있지 않을 때는 (다른 탭에 가있거나 탭이 내려가 있을 때) 애니메이션을 수행하지 않다가 다시 화면이 보일 때 수행한다. 그런데 소켓 이벤트는 정상적으로 수행되기 때문에, 다른 탭에 가있는 동안의 다른 캐릭터 움직임은 표현되지 않다가 화면을 다시 보는 순간 하나의 움직임만 보여주기 때문에 위치가 다르게 표시되는 이슈가 발생했다.
• 해결: 움직임 이벤트 처리 큐(Queue) 구현
  • 서버에서 하나의 움직이는 로직이 끝날 때까지는, 새로 들어온 움직임 이벤트를 큐에 저장해놓고 이전 로직이 끝난 후에 수행될 수 있도록 해서 이벤트를 순차적으로 제어했다. 클라이언트에서도 마찬가지로, 동일한 캐릭터의 움직임 이벤트에 대해 큐로 제어해서 순차적으로 실행되게 했다. 화면이 보이지 않는 동안에도 큐에 쌓아놨다가 화면을 다시 볼 때 순차적으로 큐에 있는 로직을 수행하는 방법으로 이슈를 해결했다.

OAuth 로그인

• JWT
  • 현재 사용자가 로그인한 사용자인지 판별하기 위해 cookie에 사용자의 github id를 가지고 있는 JWT를 저장하였다. JWT의 특성상 cookie를 변경하면 복호화가 제대로 되지 않기 때문에 수정되지 않은 사용자의 정보만 정상적으로 복호화하여 사용할 수 있다.
  • 사용자의 github id는 민감한 정보는 아니지만 조작하면 안되는 정보이기 때문에 JWT가 적합하다고 판단했다.
• GitHub OAuth app을 2개 생성한 이유
  • github oauth app을 생성할 때 Homepage URL과 Authorization callback URL이 필요하다. 그런데 development에서의 url과 prodcuction mode일 때의 url이 다르기때문에 github oauth app을 2개 생성하여 하나는 development mode일 때 사용하고 하나는 production mode에서 사용하였다.

6주차 - 사운드 + 도메인 + 엄격한 채팅 길이 검사 + 애니메이션 추가

라운드가 끝날 때마다 등장하는 애니메이션

• 한 라운드가 끝날 때마다 타노스 이미지를 canvas requestAnimationFrame을 이용해 나타나게했다. 그런데 문제는 requestAnimationFrame은 탭을 보지 않는 상태에서는 실행시키지않고 다시 탭을 볼 때 실행시키기 때문에 다른 탭을 보다가 돌아오면 한번에 타노스가 여러번 등장했다. 사용자가 현재 탭을 보고 있는지 알기 위해서 Page Visibility API를 사용했다. 그래서 사용자가 보고 있지 않다면 애니메이션을 실행시키지 않는다.

사운드

• 웹 게임이기 때문에 너무 많은 사운드 요소보다는, 가볍게 배경 음악과 게임 시작/끝 사운드 효과만 넣기로 했다.
• 사운드 재생이나 볼륨 등을 시각적으로 보여줄 필요가 없었기 때문에, 사운드를 위해 컴포넌트를 만들어 쓰거나 별도의 모듈을 설치해 사용하기보다 html5 audio 를 사용했다.
• audio를 일반 변수에 저장하면, 컴포넌트가 리렌더링 될 때마다 가끔씩 중복 생성 및 재생되는 이슈가 있어서 하나로 유지하기 위해 audio 객체를 리액트 state로 만들었다. 이렇게 만든 state를 가지고 커스텀 훅을 만들 수도 있었는데, 하나의 컴포넌트에서만 사용해서 재사용성이 거의 없었기 때문에 컴포넌트 내부 state로만 사용했다.

도메인 + SSL 설정

• 도메인은 Google Domains에서 구입했다. 구입한 경로를 적용하기 위해선 SSL 인증서를 발급 받아야 했는데, 이는 Let's Encrypt의 Certbot를 이용했다.
• 처음에는 docker-compose를 통해 실행중인 NGINX의 설정을 변경하여 SSL 인증서를 특정 폴더에 저장하고자 했으나, 제대로 작동되지 않았다. 이를 해결하기 위해, 실행 중인 docker 컨테이너를 모두 멈추고, 새로운 NGINX 이미지를 docker를 통해 실행해 인증서를 받을 수 있었다. 또한 받은 인증서를 docker volume을 이용해 인증서가 저장된 폴더를 지정해서 SSL 인증서 적용시킬 수 있었다.

채팅 검사

• 채팅을 할 때마다 캐릭터 위에 말풍선이 그려지게 적용했기 때문에, 글자수로만 채팅을 검사하는 것이 아니라 말풍선 안에 글자들이 모두 들어가는지 확인해야 했다.
  • 채팅창 도배와는 다르게 말풍선을 이용한 도배는 캐릭터를 가리는 등 유저 경험을 크게 망칠 수 있다.
  • UTF-8에서 가장 길이가 긴 글자는 위와같은 문제 때문에 적은 수의 글자만 타이핑할 수 있게 해야했다.
• canvas context의 길이측정 메소드를 사용해 사용중인 폰트, 폰트 크기에 맞춰 canvas에 그려지는 실제 텍스트의 길이를 측정했다.
• 팀에서 정한 말풍선 높이에 맞춰서 글자를 잘라줬다.

7주차 - 리팩토링

• 매직넘버 상수화
• 함수 작은 단위로 쪼개기
• 중복코드 없애기 (함수 만들기)
• 통일성을 위해 빠진 주석 추가 및 보완
• 변수, 함수명 고민해보기