만들어야 산다

2월 설 전에 주문한 책상이 오늘 도착했다. 한달 조금 넘게 걸렸다. 거의 기억에서 잊혀져갈쯤 배송 연락이 왔고 의 여우가 '네가 오후 4시에 온다면 난 오후 3시부터 행복해질거야' 라고 친 대사처럼 난 어제부터 행복해지기 시작했었다. 한달보다 하루가 길 수도 있구나..? 기사님 두분이서 오셔서 몇 번 드르륵-드르륵 하시더니 금방 조립해주셨다. F1 피트-인 보는 줄. 캬, 암튼 뭔가 건강한 근무환경이 된 것 같아 뿌듯하다. 아이템도 생겼으니 또 열심히 허슬링해보자. 그 와중에 아빠의 책상이 신기하고 부러웠던지 '잉차잉차' 하면서 자기 책상을 옆에 설치한 솔이. ㅎㅎ 심지어 저것도 높낮이 조절이 된단다 '잉~~' 하면서. 잘해보자 우리.

넷플릭스 다큐를 보다가 벤포드의 법칙(Benford's Law)이라는게 있다는걸 알았다. 실세계에서 존재하는 많은 수치 데이터의 10진법 값에서 수의 첫째 자리의 확률 분포를 관찰한 결과, 첫째 자리 숫자가 작을 확률이 크다는 법칙이다. 즉, 자연스럽게(인위적이지 않은) 생긴 임의의 숫자들이 아래와 같은 확률적인 분포를 띈다는 것이다. (위키) 처음 듣고 보는거라 이놈들이 어디서 또 약을 파나하면서 시청했는데 점점 빠져들었다. 회계에서 비공식적(?)으로 활용되기도 한단다. 가령, 엔론의 회계분식 장부에서는 인위적으로 맞춘듯한 수치들이 있어서 자연스럽지 못해 이 법칙에 어긋난다거나 하는 것들.. IT 분야에서는 이미지의 위조 혹은 딥페이크(Deep Fake) 영상을 탐지하는 연구에도 사용된다는 내용도 나왔..

프로그래머블한 동영상 인코딩 방법을 찾는 중에 발견한 튜토리얼인데 설명이 너무 좋고 쩔어서 클립해두고 종종 찾아보다가 중국어로 번역된 부분이 있길래 나도 기여해보고자하는 마음에 번역을 시작해보고자 한다. 번역 작업 자체는 깃헙으로 하고 PR을 올릴터이지만 그 작업 과정 중에 메모해둘만한게 있다면 이곳에 기록해두려고 포스트도 하나 파본다. 번역 완료, PR 올림. 후기 - 하루에 1-2시간씩 4일 정도 걸림 - 오래 걸린 부분은 PTS 부분 - 개념은 이해 되는데 원문 내용이랑 잘 매치가 안됨. 따로 다뤄야할 듯 - 단어를 있는 그대로 최대한 번역하려고 하다보니 너무 자연스럽지 않은 직역체였음 - 그래서 마지막에 전체적으로 손보면서 군더더기 같은 것들은 빼고 문체도 조금 다듬었음 - 약간 지루한 느낌인데 ..

드디어 앱들을 배포할 시간이 되었다. 배포할 컴포넌트들은 게임 에뮬레이터와 인코딩을 담당하는 기판(Gipan)과 이를 WebRTC 혹은 유저 인터렉션으로 이어주는 오락기(Orakki), 그리고 이것들을 코디네이션하고 주요비즈로직을 담고 있으며 프론트의 API서버인 아줌마(Azumma), 프론트앱인 애새끼(Esekki, 이건 따로 안다뤘음)가 있다. 이번 포스팅에서는 이것들을 어디에 어떤식으로 배포할지를 다뤄보겠다. 물론 답은 정해져 있는데 어디에? AWS에 어떻게? EKS(k8s)를 이용해서 배포해보고자한다. 그리고 이 배포 관련 형상을 관리하는 프로젝트르의 메타포는 아저씨(Azussi)로 한다. 그 옛날 내가 다니던 오락실에서 난닝구 입은 아저씨가 오락실 문앞을 청소하시고 드라이버를 들고 조명이나 오락..

이번에 다룰 컴포넌트는 오락실 오락기의 코어에 가깝다고 할 수 있는 기판이다. 기판을 뜯어보면서 어떤식으로 동작하는지 살펴보고 그 중에서도 비디오 인코딩(오디오 인코딩은 파라미터나 고려할 것들이 비디오에 비해 상대적으로 제한적이라 생략) 관련 부분을 좀더 자세히 살펴보고자 한다. 아키텍처 위 그림은 기판의 쓰레드 구성, 의존하는 모듈, 제어 및 데이터의 흐름을 한곳에 담아보려고 그려보았다. 부연을 해보자면, 쓰레드는 크게 네가지가 있다. 메인 쓰레드 - 롬(Rom)매니저를 통해 필요한 게임롬들을 다운로드하고 프레임콜백을 등록하는 등의 초기화를 수행한 후에 에뮬레이터를 실해시킨다. 프레임콜백이 호출되면 채널을 통해 인코더쓰레드에게 프레임 데이터를 전달한다. 커맨드 처리 쓰레드 - IPC로부터 입력된 Key..

왜 WebRTC 인가? 아무래도 게임이다보니 유저의 입력과 그것이 반영된 화면의 갱신 사이에 딜레이가 있으면 원활한 플레이를 할 수가 없다. 롤할때 젤 많이 하는 소리가 가족분들 안부 묻는거고 그 다음이 아마 핑(ping)계일거다. 그래서 인코딩한 패킷을 가장 빨리 전달할 수 있는 프로토콜을 골라야한다. 오락기의 라이브스트리밍을 위한 프로토콜을 고르기 위해 대표적으로 언급되는 RTMP, HLS, WebRTC를 비교해봤다. 가장 중요한 요소는 얼마나 Low-latency 인지 얼마나 Browser에서 잘 지원되는지였다. 요소 RTMP HLS WebRTC Browser Support Flash 기술이 들어간 Plugin 이 필요함 표준은 따로 있지만(MPEG-DASH) 거의 De-facto 처럼 많이 쓰임 ..

이번에 다룰 컴포넌트는 오락기이며 학습해볼만한 주제는 메시지큐로 잡아봤다. 유스케이스 오락기는 외부에서 요청할만한 엔드포인트를 가지 않는 백엔드 컴포넌트로써 다음과 같은 유스케이스가 있다. - WebRTC 세션을 맺기 위해 아줌마를 거쳐서 클라이언트와 Signaling (SDP/ICE Exchange)을 하게 되는데 이때 아줌마와 통신을 위해 메시지큐(RabbitMQ)를 이용 - 게임(에물레이션)이 돌아가는 기판으로부터 IPC를 통해 인코딩된 비디오/오디오 패킷을 가져오고 유저의 컨트롤데이터를 기판에 전송하기 위해서도 메시지큐(Nanomsg)를 이용 비슷하면서도 다른 두 사례를 통해 각각이 사용하는 메시지큐의 특징과 용법 등을 알아보고 RabbitMQ를 이용한 간단한 수제 RPC 프레임워크인 mqrpc ..

이번 포스팅부터는 오락실의 각 컴포넌트를 소개하면서 학습이 되었던 주제들을 하나씩 뽑아보고자 한다. 일단 이 한 문장을 지르긴 했는데 잘 될지 모르겠다. 일단 첫번째 대상은 프론트의 API 서버이자 오락실의 주요 비즈니스 로직을 담당하는 아줌마 컴포넌트이다. 이 컴포넌트의 주요 기능과 여기에 적용했던 클린 아키텍처에 대해서 간단히 소개해보고 소감을 정리해보겠다. 아줌마 소개 아줌마의 주요 기능은 간단하다. 아래와 같다. 플레이어 및 게임 API 플레이어 생성 내 플레이어 정보 (코인 등) 조회 게임 목록 조회 게임 실행 게임 참가 가능 여부 조회 오락기 드라이버 게임 실행시 오락기 Pod(프로세스)을 프로비저닝(Provisioning) 오락기와 프론트 사이의 중개 역할 시그널링(WebRTC) API SD..

Scalability를 고려한 서비스 레벨로 아키텍쳐링을 다시 해본다. 메타포 개발의 반이 이름짓기라고 했던가. 서비스 컴포넌트들의 이름을 짓기 위해 이런 저런 고민을 하다가 실제 오락실에서 접할 수 있는 요소들을 비유로 지어보면 어떨까 싶었다. 오락실의 문을 열고 들어가면 아줌마가 나를 반긴다. 천원을 드리며 "돈바꿔주세요" / "너 이돈 어디서 났어!?" 하며 아줌마와 가볍게 인사를 나눈뒤, 오는내내 설레였던 그 오락기 앞으로 발을 옮긴다. 오락기는 웅장하다. 큰 화면과 조이스틱 그리고 동전 넣는 곳이 보인다. 오락기 위에 쌓아둔 동전이 야속하게 사라진다. 가끔 오락기가 돈을 먹거나 문제가 생기면 아줌마가 열쇠로 오락기를 연다. 그 틈으로 보이는 오락기 안쪽으로 반짝반짝 빛나는 초록색 기판이 보인다...

프로토타이핑을 통해 기술적으로 구현이 가능함을 검증해봤다. 이제 조금더 서비스 버전으로 만들기 위한 고민을 할 차례다. 그렇다고 너무 거창하게 갈 필요는 없고 최소한의 필수 기능, 유저의 핵심동선(core-loop)만 집중해서 가본다. 코어루프 게임 목록 미리 나열된 게임 목록을 확인할 수 있다. 게임 하나씩 기간별로 로테이션을 할지 걍 몇가지 풀어놓을지 조금 고민도 했었는데 Don't be so serious! 일단 되는대로 몇개만 풀어 놓는 방식으로 해보기로. 게임 시작 게임 목록에서 '게임 시작' 액션으로 게임을 하나 실행한다. 이렇게 게임 콘솔이 실행(부팅)되고 나면 코인을 넣어서 플레이. 게임 공유 시작된 게임은 각각 고유한 아이디가 포함된 URL을 갖게 되는데 이 링크를 직접 복사해서 친구들한..