당신에게 꽃을

[디스코드 챗봇] 단지 정기적 알람을 보낼뿐인 node.js 봇 만들기

이지안 — Mon, 5 Feb 2024 19:16:13 +0900

발단 - 숙제를 독촉하는 알리미가 필요했다.

준비물부터 소개합니다.

- 디스코드 계정 (사용자 설정 -> 고급 -> 개발자 모드 on)

- AWS Lambda, Amazon EventBridge

- Node.js (20.x 버전 사용), discord.js

1. 디스코드에 새로운 봇을 생성하고, 액세스 토큰을 얻어옵니다.

discord.js의 공식 문서 링크로 설명을 대체합니다.

디스코드 어플리케이션(봇)을 생성하는 방법

디스코드 서버에 봇을 등록하는 방법

2. AWS Lambda 대시보드에 접속합니다.

현재 연결된 리전을 확인합니다. 엄청난 영향은 없지만 되도록 물리적으로 가까운 지역을 선택합니다.

저는 실수해서 미국 리전에 만들었는데, 테스트해보니 메시지 전송에 딜레이가 있긴 했습니다.

3. 새로운 함수를 생성합니다.

주황색 <함수 생성> 버튼 클릭

새로 작성

저는 런타임으로 Node.js 20을 골랐습니다.

4. 로컬에서 빈 폴더를 생성합니다.

로컬에 Node.js 20이 설치 된 상태여야 합니다.

생성한 폴더에서 터미널을 실행합니다.

<윈도우 컴퓨터 -> 생성한 폴더 내에서 우클릭 -> 터미널에서 열기>를 하시면 해당 폴더로 경로가 지정된 터미널이 열립니다.

터미널에 다음 명령어를 순서대로 쳐 주세요.

npm init -y
npm install discord.js

기다리신 후에, 아래와 같은 폴더 상태가 되면 됩니다.

node_modules 폴더가 중요합니다.

5. 아무 폴더에나 nodejs 라는 이름으로 폴더를 생성한 후, 방금 만들어진 node_modules 폴더를 하위로 옮겨넣습니다.

그리고 nodejs 폴더를 .zip 파일로 압축합니다.

이런 압축 파일을 만드시면 됩니다.

갑자기 이런 짓을 하는 이유는 AWS Lambda 함수에서 discord.js 패키지를 사용하기 위함입니다.

만들어진 nodejs.zip 파일을 이용해서 AWS Lambda 함수의 레이어(계층)을 설정해 줄 겁니다.

자세한 내용은 Deploy Node.js Lambda functions with .zip file archives에 나와있습니다.

6. AWS Lambda 대시보드에서 계층을 추가합니다.

<계층 생성> 버튼을 클릭합니다.

이름/런타임을 지정해 준 후, (5)번에서 만들었던 <nodejs.zip>파일을 올립니다.

하단의 생성 버튼을 누르시면 됩니다.

7. (3)번에서 생성했던 AWS Lambda 함수의 대시보드에 들어가서 쭉 스크롤을 내립니다.

<Add a layer> 버튼을 클릭합니다.

<사용자 지정 계층>을 선택 한 후, 방금 생성한 레이어를 선택합니다. <추가> 버튼을 누릅니다.

8. 패키지가 성공적으로 임포트 되었는지 확인합니다.

코드 최상단에 패키지 import 구문을 한 줄 써주고, 파란색 <Test> 버튼을 누릅니다.

수정 후 적용할때 <Deploy> 버튼이 활성화 되어있다면, <Deploy> 버튼을 눌러 준 후 <Test> 버튼을 눌러주세요.

<간접 호출> 버튼을 누릅니다.

성공하면 별다른 에러 메시지 없이 실행이 되고, 우측 상단의 Status가 Succeeded로 표시됩니다.

뭔가 잘못되었다면 error message가 응답됩니다.

9. 이제 코드를 칩니다.

저는 정말 단순하게, 특정 채널에 이미 지정된 메시지를 보낼겁니다.

엄청나게 짧은 코드

파란색 <Test> 버튼을 누르고 기다려보면 잘 갑니다

import { Client, GatewayIntentBits } from 'discord.js';
const client = new Client({ intents: [GatewayIntentBits.Guilds] })

// export const handler를 지우시면 동작하지 않습니다. 핸들러를 지정해야합니다.
export const handler = async (event) => {
  await client.on('ready', () => {
    const channel = client.channels.cache.get('디스코드 서버 채널 ID');
    channel.send('보낼 메시지를 입력하세요');
  });

  await client.login('당신의 디스코드 봇 액세스 토큰을 여기에 넣으세요');
};

디스코드 채널 ID는 <디스코드 앱 -> 봇이 적용된 서버 -> 봇이 메시지를 보낼 채널 이름에 커서를 대고 우클릭 -> 채널 ID 복사하기>를 누르시면 됩니다. 개발자 옵션이 켜져 있어야 해당 메뉴가 보여요.

여기까지 하셨으면 진짜 거의 다 하셨습니다!

9. 이벤트 트리거를 만듭니다.

<트리거 추가> 버튼을 눌러주세요.

EventBridge를 검색하고 선택합니다.

선택하시면 아래 추가 정보를 입력해야합니다.

<Create a new rule>, <Schedule expression>을 선택합니다.

저는 특정 요일마다 메시지를 보내는게 목적이여서, <Schedule expression>을 선택했습니다.

cron(30 18 ? * 4 2024-2025) // 24년에서 25년 사이에, 매주 수요일, 18시 30분마다

라는 뜻입니다. 작성법은 Cron expressions reference 문서를 읽어보시면 쉽게 조합할 수 있습니다.

룰 이름까지 지어준 후에 <추가> 버튼을 눌러주면 완료!

EventBridge 대시보드에 들어가시면 추가된 이벤트를 확인하실 수 있습니다.

이벤트 일정에 나온 날짜에 따라서 알아서 봇 메시지가 가게 됩니다.

딱 한 번만 끝까지 해보면 정말 쉽습니다!

다만 이 방법은 챗봇 서버가 항상 살아있는게 아니기 때문에,

유저와 상호소통하기에는 어려움이 있습니다.

단순한 리마인더 용도로 쓰신다면 좋을 듯 합니다.

사실 챗봇 커스텀을 하고 싶은게 아니라면 이미 잘 쓰이고 있는 기존 캘린더봇을 쓰면 됩니다...

감사합니다.

2023년 회고록

이지안 — Fri, 29 Dec 2023 21:48:50 +0900

안녕하세요, 이지안입니다.

개발자로는 4년차(만 3년) 회고입니다.

2022년 회고와 비슷한 순서로 진행하겠습니다.

* 주요 이벤트

* 기억에 남는 업무

* 독서 목록

* 익힌 기술

* 나의 무엇이 문제였을까? 회고와 느낀점

* 2024년에는

* 주요 이벤트

1) 8월 중순에 회사를 퇴사했습니다. 게임업계에서 두번째 퇴사입니다. 첫 직장은 1년 8개월, 두번째 직장은 1년 3개월 정도를 재직하였네요.

퇴사 사유는 두가지입니다. 기술 공부를 더 하며 스택 바운더리를 늘리고 싶었고, 후술할 재발성 질병 때문이었습니다.

2) 특정 질병 치료 목적으로 21년도 하반기부터 지속적인 약물치료를 받았었습니다. 해당 질병은 약까지 끊어야 완치 상태로 보는데, 치료약이 호르몬 조절 약물이었기에 단약 과정이 정말 힘들었습니다. 반년정도 시도 끝에 단약을 성공했고 글을 작성하고 있는 현재는 완치 판정을 받았습니다.

* 기억에 남는 업무

올해는 신규 타이틀을 개발하는 업무는 없었고, 신규 컨텐츠 개발, 라이브 이슈 대응, 최적화 등의 업무를 주로 진행했습니다. 그 중 가장 주요한 업무가 '최적화'였습니다.

23년 업무 내용을 요약하자면 "1ms라도 빠르게"였습니다.

제가 개발해왔던 "인스턴트(HTML5) 게임"은 웹브라우저 환경에서 구동되는 무설치 게임입니다.

게임 리소스가 유저가 사용하는 브라우저에 캐싱되어 있지 않다면, 항상 서버로부터 리소스를 새로 받아와야합니다.

페이스북 인스턴트 게임 출시 가이드라인에는 이런 내용이 명시되어 있습니다.

https://developers.facebook.com/docs/games/build/instant-games/game-performance

만약 게임 메인화면에 진입하는데 대충 1MB정도의 리소스 로드가 필요하다고 하면

제 환경 기준으로 단순 계산하면 0.01초 내외가 걸리는데요,

인도(약 35.74Mbps)는 0.2초, 필리핀(약 25Mbps)은 0.32초가 걸립니다.

몇 초 차이나지 않지만 리소스 로드 시간이 늘어날수록 더 많은 유저가 이탈합니다.

제 X회사들은 글로벌 원빌드로 게임을 서비스했었습니다.

한국의 빠른 인터넷 환경을 상정하고 고용량 리소스를 많이많이 넣어서 개발하게 되면 글로벌 NRU(신규유저) 수치가 아주 처참해집니다.

플랫폼에서 피쳐드를 받게 되더라도, 게임 진입이 오래 걸리는 순간 유저가 이탈합니다.

서론이 길었으나 중요한 점은 "리소스 이슈를 최대한 줄여 초기 유저 이탈과 손실을 막아야 한다"가 인스턴트 게임 플랫폼에서의 핵심이었습니다.

이를 위해 택한 방법은 다음과 같습니다.

1) 아틀라스 묶기

: 드로우콜을 줄이려고 하는 목적도 있지만, 뒤에 나올 2번을 하기 위해 필수적입니다.

게임의 지면이 '게임 로비', '메인 플레이 스테이지'로 나눠져 있다고 가정하겠습니다. 단순하게 '게임 로비'에서 쓰는 그래픽 리소스 끼리는 같은 아틀라스에 묶어두면 됩니다. '메인 플레이 스테이지'에 쓰는 그래픽 리소스는 또 다른 아틀라스에 묶습니다. 그러면 이론적으로는 지면마다 1장의 아틀라스를 사용합니다. (여담, 모바일 환경에서는 아틀라스 크기가 1024*1024를 넘으면 렌더링 되지 않는 기기가 있습니다. 유의해야합니다.)

2) 지연로딩(Lazy loading)

: 특정 리소스를 사용하는 지면에 유저가 접속하려 할 때, 필요한 리소스를 로드합니다. 또는 '게임 로비'에 접속이 완료되어 컨텐츠가 모두 렌더링 된 이후에 다른 지면에서 쓰일 리소스들을 추가 로드합니다. 상황에 따라 두 가지를 섞어서 사용했습니다. 만약 '게임 로비', '메인 플레이 스테이지' 두 지면 모두에 등장해야 하는 공통 리소스가 있다면, 그 공통 리소스들끼리 하나의 아틀라스를 만듭니다.

매 컨텐츠가 추가될 때마다 빌드 나가기 전에 위 작업을 열심히 합니다.

기술적 스킬이라기보단 단순한 분류작업에 가깝지만 저 작업만으로도 속도 이득을 굉장히 많이 봅니다.

사실 클라이언트 개발자의 메인 잡은 리소스 폴더 정리가 아닐까 하는 생각도 들었습니다.

그 외에 사용한 기타 꼼수도 있는데, 게임개발에 관련된 얘기보다는 웹브라우저에 관련된 얘기에 가깝습니다.

- SPA 프레임워크와 HTML5 게임 엔진을 같이 사용: 브라우저에 게임 엔진이 로드되어 게임 씬 하나가 렌더링 완료되는 시간보다는 SPA 렌더링 완료가 더 빠릅니다. '게임 로비'같이 단순한 레이아웃의 화면을 빠르게 보여줄 때에는 SPA나 단순 HTML/CSS/JS를 사용해도 좋습니다. HTML5 게임이라서 꼭 하나의 >>게임 엔진<<만 사용해서 빌드해야 한다는 편견은 없는 편이 성능에 더 이롭습니다. (그러나 프레임웤을 추가할수록 빌드 과정은 번거롭습니다...)

- HTML link 태그 사용: 모든 HTML5 게임은 루트가 되는 html 파일을 가지고 있습니다. 예를 들면 index.html입니다. 해당 파일에 <link rel=” dns-prefetch” href=”게임서버도메인”>과 같이 게임 서버 도메인을 미리 알립니다. DNS 조회와 캐싱에 약간의 레이턴시 절약 효과를 기대할 수 있습니다. 시험삼아 사용해보았는데, 유저 수에 유의미한 변동이 있지는 않지만 아주 미세한 성능 이득을 보긴 했습니다. 필수로 사용되는 리소스에도 적절한 태그를 걸어 프리로드하면 약간의 이득이 있습니다. 하지만 라이브 테스트 결과 모바일 환경에서는 최대 3개까지 사용하는 것이 적절하고, 더 사용하면 오히려 웹페이지의 초기 리소스 다운로드 속도가 느려집니다.

돌이켜보면 제 업무 루틴은 상당히 단순했네요.

신규 컨텐츠 개발 -> 리소스 정리 -> 빌드 취합 -> 라이브 퍼널 모니터링 -> 이슈 대응 및 최적화

위 과정을 보통 1~2주 단위로 반복했습니다.

* 독서 목록

- 프론트엔드 성능 최적화 가이드

- 개발자의 글쓰기

- 학교에서 알려주지 않는 17가지 실무 개발 기술

- 이토록 쉬운 유니티 게임 프로그래밍

-> 올해는 주로 가볍게 읽을 수 있는 책들만 골라서 완독했습니다. 다 재미있고 유익한 내용이에요.

* 익힌 기술

1) 라이브 데이터 관련된 업무를 볼일이 종종 있었기에 SQL 쿼리 실력이 약간 상승했습니다. 더불어 구글 스프레드시트/앱스 스크립트/빅쿼리 활용 능력이 늘었네요.

2) 개인적으로 유니티와 C# 공부중입니다. 저는 3년간 타입스크립트를 썼는데, C#을 배우려니 비슷하면서도 헷갈리는 부분이 많아서 흥미로워요. '아니 C#은 이게 돼?/안돼?'가 매 순간의 연속이에요.

* 나의 무엇이 문제였을까? 회고와 느낀점

"중요한 것은 꺾이지 않는 마음"이라는 말이 생각이 나요.

회사에 소속되어 있을 때, 업무를 볼 때의 내가 어땠나 생각해보면 후회되는 일이 많아요.

'프로젝트 팀을 옮기고 랜딩이 잘 안 된다고 느꼈을때, 내가 그 프로젝트의 전체 골조와 코드를 더 자세히 보고 파악했더라면 랜딩 이슈가 없지 않았을까?'

'이런 기초적인 게임 개발 스킬도 모르고 있었다니, 나는 게임 업계에 있을 자격이 없는거 아닐까?'

'내가 퍼포먼스 요구사항을 상기하고 지켰더라면 터지지 않았을 라이브 이슈가 아닐까?'

그런 생각이 반복되다가, '아, 나는 공부가 부족한가봐.'하고 기가 꺾였습니다.

'좀 쉬면서 공부도 다시 하고, 병도 완치 판정을 받자'라는 생각이 들면서 회사를 관두었는데,

돌이켜보면 회사에서 배울수 있는 것도 분명 많이 있을 텐데 하는 생각이 들어서 아쉬운 결정입니다.

진득하고 완결성있게 일을 수행할 수 있도록 자기효능감을 높여야 할 것 같습니다.

지레 겁 먹고 아예 시도하지 않거나, 사소한 부분을 신경쓰느라 전체를 보지 못했던 일들이 정말 아쉬웠던 한 해였습니다.

* 2024년에는

1) 사 둔 강의와 책을 다 보자

2) 프로젝트를 완성하고 문서화하자

언제나 동료분들, 선후배분들께 감사하는 마음입니다.

어떤 사건이 있던 배울 점이 있다고 느낍니다.

항상 소원하시는 바 이루셨으면 좋겠습니다.

새해 복 많이 받으세요!

[독서록] 이토록 쉬운 유니티 게임 프로그래밍

이지안 — Mon, 7 Aug 2023 14:53:26 +0900

https://www.yes24.com/Product/Goods/119809574

이토록 쉬운 유니티 게임 프로그래밍 - 예스24

유니티를 배우는 가장 완벽한 기초이 책에서는 유니티 엔진 설치부터 시작하여, 게임 개발에 꼭 필요한 C# 문법을 학습하고 실제 게임 개발에서 활용되는 게임 UI 구성, 캐릭터 이동, 그래픽 처리

www.yes24.com

* 본 글은 루비페이퍼 서평단에 당첨되어 무료로 책을 제공받은 후 작성된 글입니다.

개요

2023년 06월 28일에 발매된 책으로, 게임 개발 또는 유니티 엔진에 갓 입문하신 분들께서 가볍게 읽기 좋은 책입니다.

본문 내용 약 630p짜리 책으로 두깨감이 있으나, 대부분의 내용이 스크린샷과 간결한 설명으로 이루어져 있어 독서에 크게 부담이 되지 않는 개발서입니다.

장점

- 스텝 바이 스텝으로 차근차근 쓰여진 설명

- 부담 없이 읽을 수 있는 수준의 따라하기 쉬운 난이도

- 스크립트(코드)를 생략해서 보여주지 않고, 한 줄의 코드가 수정될 때도 항상 전체 스크립트를 보여줌

- 3D 슈팅 게임 구현에 정말 필요한 내용만 설명되어 있어 중도하차의 위기감이 적었음

아쉬운 점

- 게임 개발에 대한 지식이 전혀 없는 상태에서 게임 하나를 완성하기까지의 과정을 설명한 책이다. 따라서 다음 내용에 대한 설명은 별도로 하지 않는다: 게임 성능 최적화, 유니티 라이프 사이클, 코루틴에 대한 자세한 설명(간단한 내용은 나옴) 등

- '이 개념을 모르더라도 일단 한번 만들어 봐'라는 느낌이 있다. 예를 들어 람다식 함수에 대한 자세한 설명은 나오지 않는데, 후반부 스크립트에 람다식 함수를 사용한다. 싱글톤 패턴 구현 부분에서 '인스턴스'에 대한 설명이 한두장 정도로 간략히 등장하는데, 독자가 입문자라고 가정할 경우 내용이 어렵지 않을까 싶었다.

후기

저는 개발서 한 권을 처음부터 끝까지 다 읽기 힘들어하는 사람입니다. 주로 필요할 때 필요한 부분만 찾아서 읽어요.

그러나 이 책은 이틀만에 완독을 하는...! 제 개발서 독서 역사상 신기록을 세운 책입니다. 너무 쉽고 재미있었어요. 설명은 간결하고 직관적인 편이고, 스크린샷 비중이 많은 것이 좋았습니다.

유니티/C#에 관련된 내용을 이것저것 담으려면 책이 두꺼워지고, 무거워지고, 읽기 힘들어지는건 당연한 일 같습니다. 이 책은 입문 난이도에 접하기 편한 책이었습니다. 코루틴같은 입문 초기에 직관적으로 이해하기 어려운 개념들을 마음의 준비 없이 접하게 되면 쉽사리 완독을 포기하게 되는 경우가 왕왕 있는데, 그런 걸림돌이 되는 파트들을 최대한 줄여주어서 매우 편한 마음으로 읽을 수 있는 책이었습니다.

유니티 게임 개발에 입문하시는 분들께 추천드리고픈 책이었습니다.

[Unity] 유니티 URP 패키지 설치 크래시 문제 해결

이지안 — Sun, 19 Mar 2023 11:34:02 +0900

- 버전: Unity 21.3.19f1

- OS: 윈도우 10

유니티 프로젝트에 Universal RP를 install 하고 나서 무슨 짓을 해도 유니티 크래시가 나면서 종료되는 버그가 발생했습니다.

주요 오류 메시지는 다음과 같습니다.

FormatException: Input string was not in a correct format.
System.Number.ThrowOverflowOrFormatException (System.Boolean overflow, System.String overflowResourceKey) (at <03bd9b261dff4c2b8b568aca27f561b2>:0)
System.Number.ParseInt32 (System.ReadOnlySpan`1[T] value, System.Globalization.NumberStyles styles, System.Globalization.NumberFormatInfo info) (at <03bd9b261dff4c2b8b568aca27f561b2>:0)
System.Int32.Parse (System.String s) (at <03bd9b261dff4c2b8b568aca27f561b2>:0)
Unity.Burst.BurstCompilerOptionsInternal.DeserialiseStringArraySafe (System.String input) (at <a2dd15248a25411e914af2a2c82fb63f>:0)
Burst.Compiler.IL.Jit.JitCompilerService.GetAssemblyPaths (System.String folders) (at <a2dd15248a25411e914af2a2c82fb63f>:0)
Burst.Compiler.IL.Jit.JitCompilerService.EnsureLibraryCacheLoaded (System.String assemblyPaths) (at <a2dd15248a25411e914af2a2c82fb63f>:0)
Burst.Compiler.IL.Jit.JitCompilerService.CompileInternal (System.String fullMethodName, System.String assemblyPaths, System.IntPtr userdata, Unity.Burst.NativeDumpFlags dumpFlags, System.IntPtr compilerCallbackPointer, System.IntPtr logCallBack, System.String compilerFlags) (at <a2dd15248a25411e914af2a2c82fb63f>:0)
Unity.Burst.LowLevel.BurstCompilerService:GetDisassembly(MethodInfo, String)
Unity.Burst.BurstCompiler:SendRawCommandToCompiler(String)
Unity.Burst.CommandBuilder:SendToCompiler()
Unity.Burst.BurstCompiler:SendCommandToCompiler(String, String)
Unity.Burst.BurstCompiler:RequestSetProtocolVersion(Int32)
Unity.Burst.Editor.BurstLoader:.cctor()
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes(Type[])


////

Assertion failed on expression: 'exception == SCRIPTING_NULL'
UnityEngine.StackTraceUtility:ExtractStackTrace ()
Unity.Burst.BurstCompiler:SendRawCommandToCompiler (string) (at Library/PackageCache/com.unity.burst@1.8.2/Runtime/BurstCompiler.cs:771)
Unity.Burst.BurstCompiler/CommandBuilder:SendToCompiler () (at Library/PackageCache/com.unity.burst@1.8.2/Runtime/BurstCompiler.cs:98)
Unity.Burst.BurstCompiler:SendCommandToCompiler (string,string) (at Library/PackageCache/com.unity.burst@1.8.2/Runtime/BurstCompiler.cs:787)
Unity.Burst.BurstCompiler:RequestSetProtocolVersion (int) (at Library/PackageCache/com.unity.burst@1.8.2/Runtime/BurstCompiler.cs:654)
Unity.Burst.Editor.BurstLoader:.cctor () (at Library/PackageCache/com.unity.burst@1.8.2/Runtime/Editor/BurstLoader.cs:213)
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes (System.Type[])

원인은 해당 유니티 프로젝트 경로에 알파벳이 아닌 특수문자나 한글이 들어가 있기 때문이었습니다.

저의 경우엔 ms가 강제로 지정해준 한글 사용자 이름 때문에...

해결 방법은 유니티 프로젝트 경로 내에 한글이 들어가지 않도록 프로젝트 폴더 위치를 이주시키는 것입니다.

저는 E드라이브 파티션을 새로 만들고 그곳으로 프로젝트를 이주하여 문제를 해결했습니다.

도움이 되셨으면 좋겠습니다!

2022년 회고록

이지안 — Tue, 27 Dec 2022 19:10:01 +0900

안녕하세요, 이지안입니다.

제가 2021년에는 개인적인 악재가 있어서 회고를 진행하지 않았는데요,

2022년에는 한 해를 충분히 돌아볼 여유가 생겨 회고를 남깁니다.

개발자로서는 3년차(만 2년) 회고가 되겠네요.

회고는 다음 순서로 진행하겠습니다.

* 주요 이벤트

* 기억에 남는 장애와 해결법

* 독서 목록

* 익힌 기술

* 느낀 점

* 2023년에는

* 주요 이벤트

1) 4월에 첫 회사를 퇴사하고, 5월에 현회사에 입사했습니다. HTML5 클라이언트 개발자라는 큰 카테고리 안에서 이직을 했지만, 게임 개발 엔진을 Egret engine에서 Cocos creator로 바꾸게 되었습니다.

2) 11월 말부터 12월 말까지 약 한달간 요양 목적의 휴직을 했습니다. 원인은 잦은 재발성 질병이었고, 현재는 많이 나아져서 복직을 준비중입니다.

* 기억에 남는 장애와 해결법

1) Cocos creator 2.4.6 스크롤뷰가 프리뷰 환경에서만 동작하고, 빌드 환경에서는 동작하지 않았던 이슈: Module config 설정에서 스크롤뷰 체크를 누락하여 엔진에서 해당 코드가 빠졌습니다. 특정 기능이 빌드 환경에서 동작하지 않는다면 Project -> Project Settings -> Module config에 들어가서 빠진 모듈이 있는지 점검해봅시다.

2) 게임 종료를 검사하는 플래그 변수 값이 임의의 알 수 없는 시점에 덮어씌워져서 특정 상황에 게임이 종료되지 않던 이슈: 해당 플래그 변수 값을 JS Proxy를 이용해, 재현스텝대로 디버깅하여 덮어씌워지는 시점을 찾아내어 픽스했습니다. 해당 내용에 대한 자세한 정보는 [JS/TS] Proxy 사용하여 Object의 값 변화 감지 글에서 확인할 수 있습니다.

3) IOS 13 이하 환경에서의 JS 문법 호환성 (예를들면 Optional chaining operator ?.은 IOS 13 이하 환경에서 동작하지 않음): 웹팩 번들러를 사용하는 경우 https://webpack.kr/configuration/optimization/#optimizationminimize를 참고하여 minify 옵션을 끄고 npm run build를 수행, 이후 두 가지 해결 방법이 있습니다. 첫번째는 Mac PC에 문제가 발생한 아이폰을 물리적으로 연결하여 디버깅 하는 방법이고, 두번째는 발생 error를 catch하여 sentry나 자체 DB로 전송한 후 확인하는 방법입니다. 저는 상황에 따라 두가지 방법을 다 활용했는데, 이슈를 미리 예방하는 방법도 있습니다. https://caniuse.com/ 에서 JS 문법을 수시로 확인해 보는 것 입니다. 하지만 항상 생각지도 못한 부분에서 '이게 지원이 안 돼?' 하는 상황이 발생하니, sentry등을 활용해 프로덕션 환경에서 에러를 수시로 포집하는 것이 좋습니다. (단, 앞에서 디버깅 용도로 사용한 minify 되지 않은 코드는 프로덕션에 실제로 배포되면 안 되겠죠...)

* 독서 목록

- 게임 프로그래밍 패턴: 필요할 때마다 내용을 확인

- 구글 엔지니어는 이렇게 일한다: 4/5 읽음

- 소프트웨어 아키텍처 101: 1/10 읽음, 느끼기에 굉장히 어려움

- 프론트엔드 성능 최적화 가이드: 1/3 읽음, 최근에 읽기 시작한 책으로 쉽고 재미있음

-> 전체적으로 완독의 필요성을 느꼈습니다.

* 배운 기술

1) Cocos creator 2.4.6 / 3.X 버전: 아직 3D 다루는 것은 서툴러서 개인적으로 연습 중 입니다.

2) Vue.js 3: 기초가 되는 라이프사이클부터 Vuex, mitt.js (EventBus) 등의 사용법을 주로 익혔습니다. 실무에서는 vue를 브릿지 클라이언트로 활용했습니다.

대충 이런 느낌

* 느낀점

1) 의사소통은 중요하다: 이전 회사에서는 기획자/서버 담당자에게 무언가를 여쭤보는것에 망설임이 있었는데, 현 회사에서는 협업자분들과 편한 마음으로 소통하려고 노력했고, 모르는 것이 생길 때마다 망설이지 않고 곧바로 자리로 찾아가서 물어보는 연습을 많이 했습니다. 덕분에 커뮤니케이션 미스로 생기는 시간 손실이 많이 줄었으며, 현재 팀 기획자분과 합도 잘 맞아서 즐겁게 일을 했습니다.

2) 멘탈관리도 중요하다: 한 회사를 오래 다닐 수 있는 비결은 역시 멘탈이라고 느꼈습니다. 좋은 동료들과 티타임도 나누면서 회사를 즐겁게 다니는게 평정심 유지(?)에 이롭다고 느꼈고, 좋은 팀을 만나 성장할 수 있었던 한 해라고 생각합니다.

3) 나의 평소 속도보다 조금 더 빠르게: 22년 한 해는 조급해하지 않고 제 속도대로 자기개발을 해 왔는데, 전체적으로 해오던 일들에 완결성이 떨어진다는 느낌을 받았습니다. 무언가를 끝내기 위해서는 어느정도 추진력이 필요하다고 느꼈습니다.

* 2023년에는

1) 그래픽스, 쉐이더 공부를 해 보자

2) 게임을 완성해서 출시해보자

3) 개발서 완독 후 블로그에 독서록을 남겨보자

4) 꾸준한 운동과 건강관리를 하자

이상으로 2022년 회고를 마치려고 합니다.

항상 모든 만남과 가르침에 감사하고, 21년 22년 통틀어 여러 은사님들께 많이 배웠습니다.

감사합니다. 새해 복 많이 받으세요.

Git Branch 전략

이지안 — Fri, 29 Jul 2022 15:03:25 +0900

깃 브랜치 전략은 왜 쓸까요?
- 보편적으로 통용되는 브랜치 운용 방법
- 다수의 개발자 간 협업 과정에서 제품 개발 및 배포를 원활하게 돕기 위해 사용
대표적인 Git Branch 전략
- Git flow - git-flow cheatsheet
- Trunk Based Development - Trunk Based Development
- Github flow

Git Flow

일반적으로 master, develop, feature, release, hotfix 5개의 브랜치를 운영합니다. 이 중 가장 중요한 브랜치는 master와 develop 브랜치로, 나머지 브랜치는 팀 내 필요성에 따라 운영하기도 합니다.
- master: 가장 근본이 되는 브랜치로 배포된 / 또는 당장 배포 가능한 제품의 코드를 가지고 있는 브랜치입니다.
- develop: 메인 개발이 진행되는 브랜치로 출시 예정 버전의 개발이 진행되는 브랜치입니다. master 브랜치를 따 옵니다.
- feature: 하나의 기능을 개발하는 브랜치로, 해당 기능이 개발 완료되면 develop 브랜치로 merge합니다. 보통 origin에 푸시하지 않고 로컬에서만 관리합니다.
- release: master 브랜치로 배포를 보내기 전에 QA를 진행하기 위한 코드를 가지고 있는 브랜치입니다. 또는 이미 배포 나간 버전을 관리하기 위해 사용합니다. 추후에 marster 브랜치로 merge합니다.
- hotfix: master 브랜치의 내용을 배포한 후에 버그가 생겼을 때 긴급 수정을 진행하는 브랜치입니다. 추후에 marster와 브랜치로 merge합니다.
장점:
- CI/CD 적용이 용이합니다. master 브랜치에 푸시를 하면 즉시 프로덕션 배포를 시키는 형태로 많이 사용합니다.
- PR(Pull Request)에 대한 꼼꼼한 검토가 가능합니다.
- 저장소에 관여하는 사람이 많을 때 브랜치가 우후죽순 생겨나는 것을 막을 수 있습니다.
단점:
- Git flow 전략에 대한 사전 지식이 있어야 합니다. 또한 빠르게 제품을 완성하고 싶을 때 해당 전략은 부적절 할 수 있습니다. (기본적으로 각 브랜치끼리 merge 할 때마다 PR을 거쳐 한다는 것이 전제이기 때문에…)
- 사용하지 않는 브랜치가 생깁니다. 특히 release 브랜치는 master와 용도 구분이 다소 모호합니다.
- 관리하는 브랜치 자체가 많고, merge하는 단위가 크다보니 merge시 충돌이 많이 발생합니다.

Trunk Based Development

master 단일 브랜치를 중심으로 운용합니다. master 외의 브랜치를 만들지 않거나, 금방 지울 소규모의 작업용 브랜치를 생성해서 작업 후 master 브랜치에 merge하고 작업용 브랜치는 지웁니다.
장점:
- 빠르고 유동적인 애자일 개발 방법론에 적합합니다. (PR을 하지 않습니다.)
- 작은 규모로 단기 브랜치를 생성하고 빈번하게 master에 merge하여 대규모 충돌을 피합니다.
단점:
- CI/CD를 적용한 경우, master 브랜치에 푸시된 내용은 즉시 프로덕션에 반영되기 때문에 master 브랜치에 변경사항을 반영하기 전에 철저한 테스트가 이루어져야합니다. 즉, master 브랜치의 내용은 항상 유효하면서 배포 가능한 상태여야 합니다.

깃 브랜치 전략, 꼭 써야 할까요?

조직 상황에 맞게 채택/사용하면 됩니다.
다만 범용적으로 통용되는 만큼 개념은 알아두면 좋습니다.
@: 프로젝트 용량이 커질 경우 레포지토리를 브랜치처럼 쪼개서 다루는 방법도 존재

참고자료

Trunk-based Development vs. Git Flow

(알아두면 개발팀장가능) GitFlow vs Trunk-based 협업방식

[JS/TS] Proxy 사용하여 Object의 값 변화 감지

이지안 — Fri, 24 Jun 2022 19:05:27 +0900

개요: JS의 Proxy getter/setter를 사용하여 Object의 값이 변경 될 때마다 특정 기능을 수행하도록 하여 디버깅을 원활하게 합니다.

1) 다음 코드를 편한 곳에 삽입합니다. 꼭 static이 아니여도 상관 없으며, 저는 편의상 Utils 클래스에 넣어두었습니다.

class Utils {
    static proxyWatcher(v, callback) {
        return new Proxy(v, {
            set: (obj, prop, value) => {
                obj[prop] = value;
                callback(obj);
                return true;
            },
            get: (obj, prop) => {
								// 값 변화 감지만을 목적으로 한다면 getter 설정이 꼭 필요하진 않습니다.
                return prop in obj ? obj[prop] : undefined;
            },
        });
    }
}

2) 감시하고픈 Object에 다음과 같이 위 메소드를 사용합니다.

let someObject = {value : 0};
someObject = Utils.proxyWatcher(someObject, (obj) => {
  // setter 실행시 수행할 callback 동작을 넣어줍니다. 아래는 예제입니다.  
	console.warn("DEBUG   :::::   " + obj.value);
 });

3) 이제 Object 내부의 값이 업데이트 될 때마다 콜백 함수가 실행됩니다. (예제는 JS 환경에서 동작시켰으므로 살짝 코드가 다릅니다만 충분히 응용 가능하실 것이라고 생각...)

주의사항: 중첩된 Object 내부의 값 변화는 위 코드만으로 감지하지 못합니다. Object.keys()와 forEach() 등을 활용하여 응용 코드를 작성한 뒤 사용하시면 됩니다.

[HTML5] Egret Engine 관련 미세팁

이지안 — Tue, 14 Dec 2021 11:03:32 +0900

Egret Engine 5.X 버전과 2019년 이전에 출시된 FairyGUI SDK는 호환이 되지 않는다.
Egret Engine 5.X 버전에서 FairyGUI를 사용하려면 publish dialog창에서 Use binary format을 반드시 체크
- https://en.fairygui.com/docs/sdk/egret#steps-for-usage
Egret Pro - Unity 사이에서 3D 리소스를 json 형식으로 추출할 수 있다.
- https://github.com/egret-labs/egret3d-unityplugin
Egret이 공식 지원하는 라이브러리
- https://github.com/egret-labs/egret-game-library
Web Audio API 브라우저/OS 지원 정보
- https://www.cnblogs.com/martinl/p/6005424.html
- 현재 Egret 엔진은 오디오, WebAudio, QQAudio, NativeAudio의 4가지 사운드 호환 모드를 제공합니다. 괄호 안의 숫자는 index.html 파일에서의 audioType 유형입니다. (참고로 일부 모바일 기기에서는 WebAudio를 기본 옵션으로 지정해 주어야 사운드/성능 이슈가 생기지 않습니다. ex-아이패드 프로)
  - NativeAudio (0): 패키징 솔루션에서 사용하는 오디오입니다.
  - QQAudio (1): html 페이지에 " https://qzonestyle.gtimg.cn/qzone/hybrid/lib/jsbridge.js "(Qzone에서 사용하는 js API)를 지정 qq空间하고 Android 모델 에서 실행합니다 .
  - WebAudio (2): IOS 시스템 버전이 7 이상인 모든 IOS 버전 브라우저 Egret 3.2.0 이후 Android도 기본적으로 WebAudio를 사용합니다. 앱이 WebAudio를 지원하지 않는 경우 자동으로 오디오 모드로 변경됩니다.
  - 오디오 (3): WebAudio 및 QQAudio를 제외한 기타 모든 웹 브라우저 또는 플랫폼. 가능한 문제는 사운드 재생이 지연되고 한 번에 하나의 오디오만 존재할 수 있다는 것입니다.
Egret Engine 공식 튜토리얼 문서
- https://docs.egret.com/engine/docs/getStarted/helloWorld
- https://github.com/egret-labs/egret-docs
Egret 5.2 버전 이상으로 엔진 업그레이드시 가이드
- https://github.com/egret-labs/egret-docs/blob/master/Engine2D/projectConfig/upgradev52/README.md
- 추가적으로 Egret Compiler 설치 필요
Egret 라이브러리 중 assetsManager.js 사용시 반드시 RES.loadConfig() 호출 필요 (RES 라이브러리의 5.4.X 이상 버전용으로 추정됨)
Egret 프로젝트 생성 후 수정할 파일 목록
- tsconfig.json https://docs.egret.com/engine/docs/projectConfig/tsconfig
- egretProperties.json 라이브러리 추가 및 라이브러리 위치 변경
- launch.json 소스맵, 로컬서버 및 포트, 루트, preLaunchTask 등 설정 가능
로그 출력 패널 설정
- Egret Engine · Egret Engine Docs

[HTML5] 게임 엔진 종류 소개

이지안 — Sun, 14 Nov 2021 17:39:16 +0900

최초 글 작성 시기가 오래되어서 더이상 업데이트 되지 않는 엔진이 있어

2023년 12월 27일자로 수정된 내용이 있습니다 :) 참고바랍니다.

이 글에서는 HTML5 게임 클라이언트 개발에 주로 쓰이는 엔진/프레임워크들을 소개합니다.

0. 서론

2020년 12월 31일, 어도비 플래시가 공식적으로 지원 종료되었습니다.

어도비는 2017년 하반기즈음에 플래시 지원 종료 의사를 밝혔는데요, 국내 시장에서는 이미 플래시 게임의 인기가 한 풀 꺾인 후였지만, 북미나 러시아 등 해외에서는 페이스북등의 플랫폼을 통해 여전히 수많은 플래시 게임들이 라이브 서비스 중이였습니다. 당시 라이브로 플래시 게임을 운영중이던 게임사들은 플래시->HTML5 포팅 작업을 시작합니다.

이식(移植) 또는 포팅(porting)은 컴퓨터 과학에서 실행 가능한 프로그램이 원래 설계된 바와 다른 컴퓨팅 환경(이를테면 CPU, 운영 체제, 서드 파티 라이브러리 등)에서 동작할 수 있도록 하는 과정을 가리킨다 - 위키피디아

또한 멀티플랫폼에 대한 수요가 높아지면서, 웹브라우저만 구동된다면 하드웨어 종류를 가리지 않고 플레이 가능한 HTML5 게임의 수요도 증가했습니다.

HTML5 게임 제작에 주로 선택된 프레임워크/엔진들에는 Cocos creator, PixiJS, Phaser, Unity tiny 등이 있었고, 각 개발사는 여러가지 기술 검토 후에 이들 중 하나의 엔진을 골라 포팅을 시작했습니다.

지금부터 각 프레임워크/엔진들의 특징과 장단점에 대해 간단히 써 보려 합니다. 여러분께서 각 엔진을 고르시는 대에 좀 더 도움이 되었으면 합니다.

1. Unity WebGL 빌드와 Unity Tiny(지원종료)

요약: 모바일 네이티브용으로 개발된 게임을 WebGL 포팅하는 데에는 제약조건이 많다. 23년 현재 타이니는 개발이 중단 된 것으로 보인다.

Unity는 대략 5.X 버전부터 WebGL 빌드를 지원했어요. (공식문서 링크)

Technical limitations - Unity 매뉴얼

Web technology imposes restrictions on Unity web applications which are designed to run in web browsers. Make sure you are aware of the following technical limitations before you build your application for the Web platform.

docs.unity3d.com

Unity는 emscripten 컴파일러 툴체인을 사용하여 Unity 런타임 코드(C 및 C++로 작성 )를 WebAssembly로 교차 컴파일하는 방식을 통해 WebGL 빌드가 가능하다고 해요.

단, Unity WebGL 빌드에는 다음과 같은 제약조건이 있어요.

주로 플랫폼의 한계 때문에 Unity의 일부 기능은 WebGL 빌드에 사용할 수 없습니다. 구체적으로 설명하면 다음과 같습니다.
- 스레드는 지원되지 않습니다. JavaScript에서 스레딩이 지원되지 않기 때문입니다. Unity에서 성능을 높이기 위해 스레드를 내부적으로 사용하는 경우와 스크립트 코드 및 관리 dll에서 스레드를 사용하는 경우 모두 스레딩이 지원되지 않습니다. 기본적으로 System.Threading 네임스페이스 안에 있는 것은 모두 지원되지 않습니다.
- WebGL 빌드는 Visual Studio에서 디버그할 수 없습니다.
- 보안 문제로 인해, 브라우저에서는 네트워킹을 위한 IP 소켓의 직접 액세스를 허용하지 않습니다.
- WebGL 그래픽스 API는 몇 가지 제한이 있는 OpenGL ES 2.0 및 3.0과 동일합니다.
- WebGL 빌드에서는 Web Audio API 기반 커스텀 백엔드를 오디오에 사용합니다. 기본 오디오 기능만 지원됩니다.
- WebGL은 AOT 플랫폼이므로 System.Reflection.Emit를 사용하여 코드를 동적으로 생성할 수 없습니다. 다른 모든 IL2CPP 플랫폼, iOS, 그리고 대부분의 콘솔도 마찬가지입니다.

사실 JS 환경이나 WebAssembly에서 스레드 비슷한 것을 아예 지원하지 않는 것은 아닙니다, 그러나 Unity의 WebGL빌드에서는 모종의 문제(?)로 아직까지는 완성형의 지원이 되지 않고 있는 듯 합니다. (WebGL 멀티쓰레딩에 관한 포럼 글)

또한 당연한 이야기이지만, Unity WebGL 빌드로 게임을 제작할 경우 몇가지 성능 최적화에 대해 신경 써 주는 것이 게임 플레이 환경에 이롭다고 하네요. 이 내용에 대해서는 유니티 공식 문서에 다음과 같이 친절히 설명되어 있어요.

WebGL 메모리	WebGL에서 메모리를 관리하는 방법.
WebGL: 브라우저 스크립팅과 상호 작용	WebGL에서 브라우저 스크립팅에 사용되는 다양한 방법.
WebGL 성능 고려 사항	WebGL 성능 고려 사항.
WebGL 빌드 디버깅 및 문제 해결	WebGL 빌드 디버깅 및 문제 해결.
WebGL의 커서 잠금 및 전체 화면 모드	WebGL에서 커서 잠금 및 전체 화면 모드 지원.
WebGL 입력	WebGL에서 지원되는 입력 유형을 나열합니다.
WebGL 네트워킹	WebGL에서 네트워킹을 사용하는 방법.

<Unity WebGL 빌드, 장점>

이론상으로는 기존 유니티 프로젝트를 그대로 WebGL 빌드 할 수 있어요. (Unity User Manual 2023.2의 빌드 메뉴얼)

실제로 많은 경량 게임들이 유니티로 제작되어 웹 환경에서 서비스되는것을 확인할 수 있습니다.

<Unity WebGL 빌드, 단점>

23년말 기준으로 HTML5 게임의 핵심은 '빠르고 가볍게 돌아가는 컨텐츠' 인 것 같아요. 웹브라우저 환경에서 실행되는 컨텐츠임을 전제하기 때문에 많은 유저가 버벅임이나, 느린 로딩 속도를 견디지 못하고 실행 도중에 이탈합니다.

Unity WebGL 빌드는 기존 유니티 프로젝트를 거의 그대로 사용할 수 있어 모바일용 빌드를 그대로 HTML5 포팅 할 수 있을 것 같아 편리하다는 생각이 들지만...

환경 차이가 있겠으나, 유니티 2D 프로젝트를 하나 생성해서 아무 작업 없이 WebGL 빌드를 뽑아보니 대략 2.4MB의 용량이 나옵니다. 다른 HTML5 엔진들은 깡통빌드 용량이 1MB 내외입니다. 속도가 핵심인 HTML5 게임에서 1MB 차이는 치명적일 수 있어요.

더불어 3D로 제작된 프로젝트의 경우 더더욱 최적화가 안 된 결과물이 등장합니다. 폴리곤 많고 매끄러운 그래픽의 게임을 Unity WebGL로 포팅하는 것은 플랫폼 서비스 특성상 힘들 것 같습니다. (다만, 플랫폼 특성상 힘들다는 것이지 기술적 불가능에 대한 이야기는 아닙니다 -> 빌드 사이즈를 줄이는 것에 대한 유니티 포럼 글 )

또한 공식 문서에 따르면 모바일 기기 호환성을 보장하지 않습니다. 일부 모바일 기기에서는 빌드가 작동하지 않을 가능성이 있습니다.

요약하자면 플랫폼에 맞춤화된 최적화를 진행하기가 힘듭니다.

따라서 보다 편리하게 유니티로 HTML 5 개발을 하기 위해서는 아래서 언급하는 Unity Tiny 런타임을 별도로 설치하는 것이 좋아요. 2023년 12월 현재는 업데이트가 중단 된 것으로 보여요.

<Unity Tiny, 장점>

유니티 패키지 매니저를 통해 설치 할 수 있는 Unity Tiny의 대표적인 장점으로는, Unity 엔진 자체가 가장 메이저한 게임 엔진이라는 점이에요. 현재 Unity Tiny는 실험적인 개발 단계이나, Unity에서 지속적으로 개발을 진행 중인 만큼 발전 가능성이 크다고 할 수 있을 것 같아요.

엔진 자체의 GUI 서포팅도 잘 되어서 입문자도 tiny 공식 유튜브를 시청하며 비교적 쉽게 사용 방법을 배울 수 있어요. GUI가 Unity 베이스이기 때문에 기존에 유니티로 게임 개발을 하시던 분들이 엔진 사용에 쉽게 적응할 수 있다는 것도 큰 장점 중 하나에요.

또한, Unity Tiny 모드를 사용하여 작업하면 별도의 로컬 서버를 구축할 필요 없이 게임을 웹브라우저로 실행하여 디버그 할 수 있다는 것도 장점 중 하나에요.

<Unity Tiny, 단점>

모바일/PC 네이티브 타겟으로 개발된 게임을 Unity tiny로 WebGL 포팅하는 것은 굉장히 공수가 많이 들어요. Unity tiny는 기존 유니티의 MonoBehaviours를 사용하지 않기 때문이에요. (tiny 2기준)

또한 Tiny는 현재 실험적인 개발 단계를 거치고 있어 관련 개발 자료가 PixiJS나 Phaser에 비해 많지 않아요.

결국 일반적인 방법으로는 Unity를 사용해 네이티브 게임&플래시 게임을 HTML5게임으로 손쉽게 포팅할 수는 없어요. 그러나 Unity를 사용해 처음부터 HTML5 게임을 개발하여 라이브 서비스 단계까지 가는 것은 가능해요!

2. PixiJS

요약: 빠르고 간단한 2D WebGL renderer PixiJS! 하지만 프레임워크는 아니다.

WebGL 3D 렌더러에 three.js가 있다면 2D에서는 PixiJS가 있다고 할 수 있죠.

"어라...엔진이라면서 왜 라이브러리랑 비유를 해요...?"

그것은 PixiJS는 다음 기능을 기본으로 제공하지 않기 때문입니다. (공식문서 발췌)

사용자 설정 관리
오디오 라이브러리
개체 스크립팅
모바일 앱 빌드
UI 라이브러리
개발 환경과 편집기

Unity나 Game Maker studio등의 게임 엔진을 주로 접해보신 분들은 '게임 엔진'임에도 불구하고 위 기능들이 없는 것이 다소 생소할 수 있어요.

저도 이전까지 '엔진'에 대해 인식할때 UI 라이브러리가 포함되어있는 형태의 엔진들을 주로 떠올렸거든요. 그래서 개발 환경을 따로 구축한 뒤 라이브러리를 import해서 사용하는 PixiJS의 존재를 접했을 때 굉장히 새로웠습니다.

위와 같이 Pixi.js는 monolithic하기보다는 micro service적 면모를 많이 가지고 있어요. 전용 편집기가 없다는 점, 별도 task runner의 도움을 받는게 편리하다는 점 등등, 지금까지 보아왔던 '게임 엔진'들과는 사용의 방향성이 다르다고 생각이 듭니다. 깃허브 공식 레포지토리에서 자체적으로 다양한 플러그인을 제작해 배포하고 있고, 지원이 되는 서드파티도 많아서 범용성에는 문제가 없습니다.

<Pixi.js, 장점>

Pixi.js는 단일 라이브러리만 가지고는 게임을 만들기에는 다소 가벼울 수 있는 엔진이에요. 그러나 WebGL 2D 렌더링에 관련된 기능들만 들어있기 때문에 굉장히 빠르고 가벼워요. 또한 사용자가 원하는 대로 각종 라이브러리를 붙여 개발 환경을 구축할 수 있다는 점이 큰 장점이 되는 경우도 많아요.

Pixi.js는 게임만이 아닌 다양한 HTML5 웹페이지에 유연한 적용이 가능해요. 배포 방식 또한 일반 웹페이지를 배포하는 것과 동일합니다. 아래의 웹페이지들은 Pixi.js를 사용하여 만들어졌다고 해요. 들어가 보시면 정말 화려하다는 것을 느끼실 수 있으실 거에요.

- inicio

- https://art4globalgoals.com/en

The art of achieving #GlobalGoals

Check out Leon Löwentraut’s artistic interpretations of the Global Goals and help erase our planet’s 17 biggest issues.

art4globalgoals.com

<Pixi.js, 단점>

가볍다!는 것이 단점일 수 있는 엔진이에요. 일단 개발 환경을 엔진단에서 준비해주지 않으니, 개발자가 개발 초기에 따로 챙겨야 할 것들이 있습니다. 대표적으로 다음과 같은 것들이 있으면 좋아요.

웹 서버 - 필수
UI 서드파티 - 주로 tilemap 플러그인, Spine 플러그인, Fairy GUI 등을 사용할 수 있어요.
오디오 라이브러리
Task Runner - gulp.js, Grunt 등을 사용할 수 있어요.

결국 Pixi.js 단일 환경으로는 게임을 만들기가 어렵다는 점, 게임 엔진보다는 그래픽 렌더러로 주로 이용된다는 점이 단점으로 작용합니다.

3. Phaser

요약: 가장 접하기 무난하고 유명한 프레임워크

Phaser는 HTML5 게임 개발에 입문했을때 가장 무난하게 접할 수 있는 프레임워크에요. 공식 홈페이지의 가이드 문서 뿐만 아니라 한국어로 된 블로그 개발 자료도 많아서, 개발 도중 어려움이 닥쳤을 때 도움을 받기가 타엔진들에 비해 상대적으로 쉽기도 해요.

Phaser는 Phaser2와 Phaser3로 나뉘어요. Phaser2는 WebGL 렌더링을 위해 Pixi.js를 사용하고 있어요. 그러나 Phaser3에서는 자체 개발한 WebGL 렌더러를 사용하고 있다고 합니다. 이외에도 디테일에서 많은 차이가 있어요. 아쉽지만 Phaser2로 만들어진 게임의 엔진을 Phaser3로 손쉽게 업그레이드 하는 것은 불가능해요.

이 파트에서는 Phaser3 위주로 설명을 드릴 건데요, Phaser3도 ‘음...? 게임엔진...?’스러운 부분이 있어요. 다음 부분들은 Phaser3를 이용하기 위해서 사용자가 직접 선택하고 구축해야 하는 것들이에요.

로컬 웹 서버
IDE 개발 환경
UI 라이브러리 또는 플러그인 - 엔진 자체에 붙어있지는 않습니다.
Task Runner - Grunt를 권장해요

위 준비 과정을 얼핏 보면 Pixi.js와 비슷하다는 느낌을 받기도 해요. 그러나 Phaser는 게임 프레임워크로서 게임 제작 자체에 최적화가 되어 있어요. 다음과 같은 기능을 지원하고 제어해요.

애니메이션 / IO / 장면 / 사운드 관리자
Time step
게임 루프와 생명주기

<Phaser3, 장점>

Phaser의 최대 장점은 ‘게임 개발’자체에 치중된 UX를 제공하고, 이에 따라 수많은 참고자료를 얻을 수 있도록 생태계가 형성되어 있다는 점이에요. 제가 리서치를 하면서 본 HTML5 게임 엔진/렌더러 중 Phaser의 개발자료와 정보가 압도적으로 많았어요.

다양한 개발자료, 튜토리얼, 커뮤니티
Pixi.js 보다는 HTML5 게임 제작에 최적화된 UX를 제공

<Phaser3, 단점>

Phaser의 단점은 Pixi.js의 단점을 축소해 놓은 느낌이에요. 초기 구축 단계에서 사용자가 신경 쓸 부분이 일부 있답니다.

로컬 웹서버 미지원
UI Editor는 별도
3D 미지원
자체적으로 모바일 앱 빌드를 지원하지는 않습니다.

그러나 이러한 일부 귀찮음을 감수하면 Phaser는 사용자 입장에서 굉장히 파워풀한 엔진이에요. 아무리 엔진 자체가 잘 만들어졌어도, 개발 생태계가 제대로 구축되지 않아 관련 자료를 얻기가 힘들면 엔진 사용자도 자연스레 줄게 되고, 포럼이 작아지고...엔진 업데이트가 되지 않고...같은 극단적인 악순환이 생기기도 하니까요.

4. Cocos Creator

요약: UGUI에 익숙한 개발자를 구원해줄 HTML5 제작 엔진, Cocos2d-x와는 다른 엔진이니 헷갈려서 설치하지 말자.

성능에 엄청나게 예민한 컨텐츠를 만드는게 아닌 이상 저는 Cocos Creator를 강력 추천합니다.

엔진의 기본 사용법이나 GUI가 Unity와 거의 동일하기 때문에 디자이너, 기획자와 협업이 무척 용이합니다.

<Cocos Creator, 장점>

UGUI와 굉장히 흡사한 GUI를 제공, 기존 Unity나 Game Maker 사용자라면 굉장히 쉽게 적응 가능
오픈소스, 무료
로컬 웹서버를 지원하여 따로 구축 작업을 하지 않아도 됨

<Cocos Creator, 단점>

Pixi.js, Phaser보다는 결과물이 무겁고 용량이 큼, 최적화가 필요
엔진에 자잘한 버그와 오류가 꽤 있는 편인데, 빨리 픽스되지 않는 편
Cocos Creator 3.X와 Cocos Creator 2.X가 있는데, 3버전은 하위호환을 지원하지 않는다. API가 완전히 다름
쉐이더나 인스펙터 커스텀등의 기능을 머리 잡아 뜯지 않고 사용하려면 필히 3.X 버전을 사용하자. 메뉴얼이 더 친절하다.

X. 결론 및 요약

* "단순 빌드 용량"의 경우 <minify 여부/엔진 버전/프레임워크 포함여부>등에 따른 용량 변경등을 자세히 고려하여 적은 것은 아니며, 깡통빌드일 경우의 대략적인 참고 수치로 봐주시면 됩니다. 최적화하기에 따라 용량은 천차만별이 될 수 있어요.

	Unity WebGL	PixiJS	Phaser	Egret	CocosCreator
로컬 웹서버 지원	○	X	X	○	○
다양한 개발 자료	○	○	○	X	○
Task Runner 필요 여부	X	△	△	X	X
GUI 서포팅	○	X	X	X	○
3D 지원 여부	○	X	X	△	○
지원언어	C#	JS/TS	JS/TS	JS/TS	JS/TS
과금 형태	2023 LTS 이후로는 정책에 따라 과금	오픈소스	오픈소스	오픈소스	오픈소스
단순 빌드 용량	2MB 이상	1MB 미만	1MB 미만	1MB 미만	1MB 미만

2020년 0년차 회고록

이지안 — Sat, 9 Jan 2021 22:06:11 +0900

안녕하세요, 지안입니다.

2020년은 다사다난한 한 해였는데 요, 코로나 19 팬데믹 와중에도 많은 도움을 주셨던 주변인 분들께 감사했고, 더불어 이 글을 봐주시는 모든 분들께 작년 한 해 고생 많으셨다는 말씀 먼저 드립니다.

2020년에 좋은 기회가 있어 개발자로 취업을 하게 되어, 짧게나마 0년 차 회고록을 남깁니다.

작년 한 해 제 타임라인은 다음과 같습니다.

1-2분기: 본과 4학년 1학기 재학, 졸업작품 마무리, 비전공자분들과 함께 HTML/JS/CSS 스터디 프로젝트 진행
3분기: 취업 준비 및 면접 진행, 웹에이전시에서 웹프론트엔드 개발자로 단기 근무
4분기: HTML5 웹게임 클라이언트 개발자로 근무

회사 업무를 제외한 주요 진행 프로젝트는 다음과 같습니다.

Intelligent UI Assistant 리엔지니어링 (AWS EC2, Firebase storage, JS, TensorFlow 1.5 Keras): 졸업작품입니다. 영상처리/딥러닝을 통해 하나의 레이어로 합쳐진 이미지에서 개별 UI 컴포넌트들을 분리하는 웹 애플리케이션입니다.
Team Cook (HTML, JS, CSS, Firebase realtime DB): 자취생에게 유용한 간단한 요리 레시피 추천 사이트입니다. HTML/CSS로 간단한 웹페이지 구축을 하고 JS와 firebase를 이용해 레시피 데이터를 불러와 웹페이지에 뿌려주었습니다.
Unity Vuforia 스터디: AR 증강현실을 이용한 간단한 어플리케이션 제작을 했습니다. AR 오브젝트를 터치하면 상호작용을 하는 등의 기능을 포함하고 있습니다.

2020년에는 졸업작품 마무리와 취업 준비가 겹쳐 신규 프로젝트를 많이 진행하지 못하여 아쉬웠습니다. 그래도 기억에 남는 몇 가지에 대해 기록을 남겨봅니다.

IUA(Intelligent UI Assistant

IUA(Intelligent UI Assistant)는 2019년 말에 초기 버전 제작을 했었습니다. 그러나 이 버전에서는 가장 중요한 딥러닝 모델이 동작하지 않았습니다...() 당시 사용했던 모델은 CUDA를 설치해야 동작이 가능했는데, 파이썬 버전 충돌 문제 등으로 팀원 세 명 모두가 환경 구축에 애를 먹는 와중에 1차 심사가 다가왔습니다. 딥러닝 모델은 실행도 못 해본 상태였고 결국 모델 없이 웹페이지만 제출했던 기억이 납니다...()
그리고 알맹이 없던 이 프로젝트를 2020년에 재제작했습니다. 작업용 하드웨어를 바꾸고 나니 환경 구축 문제도 해결이 되어서 별 다른 문제 없이 제작이 가능할 줄 알았는데요, 팀원 중 한 분이 개인 사정으로 중도 휴학을 하시면서 문제가 생겼습니다. 데이터 라벨링 일손이 부족해졌어요. 웹페이지 구축, 서버 개발 및 연결은 제가 맡고, 딥러닝 모델 제작과 데이터 라벨링은 남은 학우님께서 맡아주셨습니다. 그래도 최종 심사일까지 일정이 촉박해서 서버는 파이썬 소켓, DB는 firebase, 호스팅은 AWS EC2를 사용한 혼종이 탄생했던... 프로젝트였습니다. 학습에 사용한 이미지 데이터도 30-40개 정도로 매우 적었습니다. 그래도 생각보다 모델 학습 결과가 좋아서 놀랐던 프로젝트였습니다. (주요 기능도 다 제대로 동작은 했다는 게 놀라웠습니다.) 모델 제작에 힘써주신 학우님께 감사의 말씀 올립니다 :D

Team Cook

Team Cook 프로젝트는 좋은 스터디 경험이 되었는데요, 이 프로젝트는 비전공자 세 분과 한 팀을 이루어 약 한 달 정도의 기간 동안 진행했습니다. 팀원 분들께 'DB에서 값을 불러와 웹페이지에 뿌려준다'는 개념과 그 방법을 설명드리는 것이 난이도가 있었습니다. 처음에는 공식 문서와 예제 링크를 참고 자료로 사용하였는데, 저희가 만들던 프로젝트와는 구조가 상이하다 보니 이해에 난해한 부분이 있었습니다. 추후에 저희 프로젝트 구조에 맞는 예제 코드와 주석을 작성해서 드리는 방식으로 문제를 해결했습니다.

이 프로젝트는 목적상 DB를 붙이거나 호스팅을 할 필요까지는 없었는데, 아무래도 제가 욕심이 있어 DB에서 데이터 값을 불러오자고 제안을 했습니다. 다행히 팀원분들이 흔쾌히 승낙을 해 주시고 프로젝트 마무리까지 힘써 주셔서 서로에게 좋은 결과로 남았던 것 같습니다.

여담으로 해당 프로젝트를 AWS에 올리고 나서 특정 사진 하나가 출력이 안 되는 문제가 있었는데, 해당 리소스 파일의 확장자명이 .JPG로 대문자였습니다... 기본 사진 확장자인 jpg와 png 외의 파일을 AWS 서버에 올리려면 따로 설정을 해 줘야 한다는 사실을 알게 되었습니다.

2020년 한 해 맡았던 주요 업무는 다음과 같습니다.

음악 라이브러리 웹사이트 개발 및 유지보수 (D3.js, Mongoose, Angular.js, NodeJS): 약 11만여 개 음원을 보유하고 있는 음원 서치 웹사이트 프로젝트에 투입됐습니다. 각 음원이 가진 무드 태그에 따라 D3 그래프를 생성하여 유저에게 시각화된 자료를 제공하는 기능을 주력으로 개발했습니다. 그 외 음원 검색 기능 수정 및 개선 등의 기타 유지보수를 맡았습니다. (약 한 달)
BubbleCoCo HTML5 포팅 개발 및 유지보수 (TS, Egret, fairy GUI): 2019년 말 어도비 플래시 지원 종료로 인해 기존 플래시 게임을 HTML5 게임으로 전환하는 포팅 작업을 진행했습니다. 클라이언트 개발을 맡았습니다.
프로젝트 코드 리팩토링: 사내에서 제가 작성했던 코드에 대한 리팩토링을 진행했습니다. (진행했으나, 아직도 많은 code smell이 남아있어 아쉽지만, 그래도 진행에 의의를 둡니다...)
HTML5 웹게임 광고 추가 작업: 주로 인터스티셜 광고 기능 추가 작업을 진행했습니다.

새로 배운 기술에는

Angular.js / NodeJS / TypeScript / Egret Engine / FairyGUI / Unity (Vuforia 위주) / GCP 등이 있습니다.

기억에 남는 장애와 대응으로는

CSS filter 브라우저 호환성: png 파일에 필터를 씌워 색과 투명도 처리를 변경해야 하는 기능이 있었는데... 해당 기능에 CSS 필터나 mix-blend-mode를 적용하였을 때 브라우저마다 색이 달라 보이거나, 익스플로러의 경우 해당 태그를 아예 지원하지 않는 경우가 있었습니다. (해결 못 했습니다ㅎ)
로컬라이징 언어 디폴트 설정: 해당 서비스는 접속 시에 서버에서 접속 국가 정보를 받아와서 뷰를 생성 시에 로컬라이징을 하는 기능이 있었습니다. 영어 외 3종 언어를 지원하고 있었는데, 실제 라이브 서비스를 가보니 서버에서 해당 4종 외 언어를 날리는 경우가 있었고, 해당 경우에 대한 예외처리가 없어서 유저들이 서비스에 접속 자체를 못 하는 사태가 발생했습니다. 클라이언트 코드에 특정 세션마다 빅쿼리로 로그 메시지를 심었고, 로딩->스타트 세션에서 데이터가 튀는 것을 확인하여 해당 부분에서 일어나는 코드를 추적해 로컬라이징 문제임을 발견하고, 예외처리를 추가하여 픽스하였습니다.

그 외에도 자잘한 실수를 많이 했는데, 배운 점은

1. 코드는 되도록 방어적으로, 예외처리를 잘해 둘 것

2. 코드 컨벤션을 준수할 것: 저는 프로젝트 진행 중에 투입된 인력이었는데, 이미 기존에 짜인 프로젝트의 코딩 스타일을 따라서 코드를 작성하고 있었기에 코드 컨벤션을 준수했을 때의 장점에 대한 체감이 거의 없었습니다. 그러나 추후에 CTO님께 코드 리뷰를 받으면서 스타일을 준수하지 않았을 시에 엉망이 되는 프로젝트들에 대한 이야기를 듣게 되었고 (제가 받은 프로젝트가 그랬습니다...) 아키텍처나 스타일에 일관성이 없을 때, 유지보수 시에 많은 비용이 낭비된다는 사실을... 이슈 처리하면서 체감하게 되었습니다. 특히 전임자가 직렬로 여려명이었는데 전부 퇴사한 상태고, 코드와 아키텍처 스타일이 다 다른 프로젝트를 상반기에 맡았었는데 이땐 정말 기능 하나 찾아서 고치기 힘들었던 기억이 납니다. 모쪼록 기본기란 일관성 있게 정리를 잘하는 것이라고 깨달았습니다.

글을 마무리하면서

사실 2019년에 비하면 2020년은 진행한 프로젝트도 적고, 대회도 하나밖에 나가지 않아 '좀 더 노력할 걸'이라는 아쉬움이 많이 남았습니다. 그래도 현업에서 나름대로 가치 창출(?) 할 수 있었다는 점, 코드 리뷰를 가장 많이 받은 한 해였다는 점이 유의미한 것 같습니다. 항상 물어본 것에 대해 친절히 알려주시는 업계 선배님, 동료님들께 감사하는 바입니다.

어찌어찌 웹개발을 하다가 현재는 웹게임 클라이언트 개발자라는 다소 특수한 포지션에서 일을 맡고 있습니다. 웹, 게임 양 쪽 개발 지식을 모두 알아야 하는 만큼 2021년엔 더욱 정진해야겠다는 생각이 듭니다.

이상 긴 글 읽어주셔서 감사합니다.

같이 발전하는 2021년이 되었으면 합니다 :)

이만 줄이겠습니다!