계기

원래 프로그래밍을 업으로 삼는 것에 대한 고민은 학부 4학년으로 미뤄두고 싶었다. 그러다가 2학년 즈음에 병역에 대해 고민하면서 산업기능요원 복무 제도로 내 전문성을 향상하는 것이 의미 있다고 판단했다.

구직을 시작하려니 실제로 일해본 경험이 없어 3~4번 정도 서류와 면접 단계에서 쓴맛을 봤다. 아무래도 허들이 높다고 생각해서 중단하고 인턴 프로그램을 찾아봤다.

플라네타리움

인턴십은 포트폴리오로 사용 가능한 프로젝트 단위로 진행되어 채용 과정에서 레퍼런스로 삼을 수 있도록 최대한 도우며, 추후 현업에서 필요한 지식을 멘토와 함께 습득할 수 있도록 합니다. — 엔지니어링 인턴 — 플라네타리움 인재 영입

탈중앙 온라인 게임을 만드는 플라네타리움의 인턴 프로그램을 보게 되었다. 대개 쓰는 “채용”(사람을 골라서 고용함)과 달리 “인재 영입"이라는 키워드를 써서 다른 회사와 달라 보았다.

인턴 프로그램이 블록체인 관련 업무에 맞춰져 있지만, 자사 게임의 서비스 중 블록체인 탐색기가 React + TypeScript 기반으로 만들어져 있는 것이 생각났다. 보편적인 웹 프론트엔드의 기술 스택과 겹쳐 혹시나 웹 프론트엔드 업무가 필요하지 않은지 지원 문의를 드렸다.

안녕하세요. 웹 프론트엔드 분야로 경험을 쌓는 중인 학생입니다.

혹시 공고로 적어주신 분산 시스템 도메인과 달리, 웹 프론트엔드로 포트폴리오를 도움을 받을 수 있을지 궁금합니다.

보내는 이력서와 플라네타리움에서 원하는 도메인 지식이 많이 다르지만, 충분히 맘에 드는 서류라고 느낀다면 답장 부탁드리겠습니다.

마침 내부에서 웹 기술로 만든 게임 론처가 프로토타입에서 정식 제품으로 바뀌면서 팀에 도움에 될 것 같다는 회신을 받았고, 바로 과제 테스트를 다음 과정으로 안내받았다.

제출한 과제가 통과되고 실무진 면접을 진행했다. 아이스브레이킹 차원으로 과제에 대한 피드백을 여쭤보았고, 긍정적인 의견을 받아 긴장감이 줄어든 상태에서 면접에 응하게 되었다.

면접에서 알게 된 점이라면, 회사가 질문할 권리를 갖듯이, 서류를 보고 어떤 생각이 들었는지, 어느 부분이 좋았고 아쉬웠는지 등 피드백을 구하는 정도는 괜찮다고 생각한다. 단, 지원자에 대한 피드백은 입사 결정의 판단 기준이기에 너무 부정적인 피드백은 상대적으로 얻기 어려운 것 같다.

구두로 피드백을 부탁하는 것은 플라네타리움 뿐만 아니라 다른 회사도 어느 정도 개방적인 태도를 보였다. 회사의 문화마다 다를 수도 있지만 이게 안 된다면 대화가 아닌 심문이라고 나는 생각한다.

블록체인

입사 첫 주 동안은 회사 구성원과 소통하는데 필요한 최소한의 도메인 지식을 학습했다. 기본적인 암호학 개념(비대칭키 알고리즘의 종류, 전자 서명, 결정적 계산1) 학습, 블록체인 프로토타입 제작 과제를 수행했다.

블록체인 기술을 다뤄본 것은 처음이긴 하지만, 나는 이미 분산화 체계에 대한 개념을 Git으로 경험해봤었다. 그래서 아주 어렵지는 않았고 추상화하면 아래와 유사하다고 생각한다.

블록체인Git
블록 해시커밋 해시
체인 재구성리베이스

인턴쉽을 수료할 즈음에 탈중앙 게임의 특이한 기술적인 문제를 회사 기술 블로그에 정리해서 올리기도 했다.

론처 목표 달성하기

내가 합류했을 당시 회사의 상황은 CBT 겸 게임의 정식 출시를 준비하고 있었다.

게임 론처의 경우 블록체인 노드2와 강한 의존성 관계가 있어서, 노드의 작업이 예기치 않게 중단되면 론처도 연달아 꺼지는 등 초기 이탈률이 60% 정도의 심각한 상황이였다.

이런 상황에서 나는 론처의 이탈률을 10% 이내로 낮추는 온보딩 스프린트3 4에 참여를 했다.

팀을 위한 기여

나는 본래 UX와 연관된 업무에 관심을 두고 참여를 했다. 그러나 품질 확인에 대한 업무를 첫 과업으로 직접 설정했다. 왜냐하면 팀에서 감행하는 코드 수정의 빈도가 목표 달성을 위해 잦아졌고, 이런 상황에서 가장 큰 부채는 품질 확인을 자동화하는 것으로 판단했다.

세부적인 업무 내용으로 프로그램에 논리적 오류는 없는지 검사하는 정적 타입 확인과, 사용 시나리오를 검증하는 종단 테스트 자동화를 도입했다. 기계가 무결함을 검증해주니까 마치 안전벨트가 생긴 것 같았고, 일종의 hotfix 같은 사후 수정을 어느 정도 예방하는 데에 득을 봤다.

종단 테스트를 작성하면서 원래 명세에 누락된 기능을 되짚어 보게 되어 의외였다. 기존에는 비밀번호 재설정 버튼이 재설정 기능이 아닌 키 무효화 기능을 안내했다. 이런 페이지 전환이 오랜 시간 의도된 구현으로 동료 모두 착각하고 있었고, 나는 이 누락을 종단 테스트를 기술하면서 찾아내게 되었다.

자아를 투영한 기여

UX 글쓰기와 상호작용

론처의 문구를 조금 더 사용자 친화적으로 수정하고, 불친절한 상호작용을 적절히 수정하는 것으로 이탈률을 줄이는 목표에 내 나름대로 기여했다.

피드백에 적극적인 게임 커뮤니티, 디스코드로 운영되고 있어 위 채팅을 직접 참조 가능합니다.

피드백에 적극적인 게임 커뮤니티, 디스코드로 운영되고 있어 위 채팅을 직접 참조 가능합니다.

주로 설정 페이지를 새로 작업하며 더 나은 문구를 고민했고, 그 외의 페이지의 문구 개선은 게임 커뮤니티의 기여를 반영했다. 아래의 목록은 내가 개선한 상호작용 요소 중에 기억나는 4가지를 뽑아봤다.

  • 설정 값 저장 시 론처 재시작, 이전에는 사용자에게 수동 재시작을 부탁했다.
  • 유효하지 않은 비밀번호를 입력하면 입력 필드에 빨간 경계선이 생기는데, 다시 타이핑하면 이 스타일을 초기화 시켰다.
  • 가입 시 패스워드 강도 힌트 주기, 위 항목까지 고려하며 두개의 입력 필드를 관찰해야 하니 경우를 나누기가 꽤 까다로웠다.
  • 키보드 사용자의 접근성을 챙기기 위해 텍스트 스타일의 버튼으로 링크가 쓰였던 걸 버튼 컴포넌트로 변경했다.

의미있는 마크업과 오버엔지니어링

개발자 패널을 열어 비교해본 마크업. 왼쪽이 이전이고, 오른쪽이 이후이다. #root > .layout > .container 처럼 필요 이상의 마크업 깊이를 #root로써 한 단계로 줄였다.

개발자 패널을 열어 비교해본 마크업. 왼쪽이 이전이고, 오른쪽이 이후이다. #root > .layout > .container 처럼 필요 이상의 마크업 깊이를 #root로써 한 단계로 줄였다.

프로토타입에서 시작한 론처의 UI는 “이러고 저러다 보니 그렇게 된” 코드 구성에 가까웠다. 모든 레이아웃을 마진과 패딩을 사용해서 물리적으로 잡아두고 있었고 마크업을 의미 있게 서술하지 않았다.

페이지마다 공통된 마크업의 골격을 손보는 것을 우선 순위로 두었다. 상용 서비스를 다루게 되었을 때 웹 접근성을 꼭 신경 쓰고 싶어서 alt 어트리뷰트나 WAI-ARIA 등 접근성 힌트를 신경 쓰면서 작업을 했다.

그러나 동료에게 데스크톱 앱이기 때문에 접근성의 중요도가 낮다는 피드백을 받았다. 소수 케이스를 고려해야 한다고 내가 주장할 수도 있겠지만, 내가 나간 뒤에 그 코드는 유지되지 않거나 레거시가 될 수 있다고 생각해서 그 작업을 중단했다.5

비자아적 프로그래밍이라고, 나 자신과 내가 작성한 코드를 분리해서 사고하라는 개념이 있다. 작성한 코드가 비판받더라도 내 자신이 부정당하는 것은 별개이기 때문이다. 비슷한 맥락으로 내 자아의 어떤 요소와 제품의 목표는 별개일 수도 있고, 그 자아가 투영된 욕구는 팀에서 별로 도움되지 않을 수도 있다.

게임 커뮤니티를 위한 기여

론처의 세부 목표 중에 국제화 업무를 자원해서 맡았다.

한국어 화면영어 화면
한국어 화면영어 화면

하드코딩 된 론처 문구를 국제화 모듈에 호환되는 포맷으로 대체하는 초기 작업을 해두고, 문구가 새로 추가될 때마다 게임 커뮤니티의 번역 참여자 분들에게 공지를 해두었다.

나는 게임 번역 퍼블리싱으로 커뮤니티 활동을 해본 적이 있어서 추억을 돌아보게 되었다. 덕분에 더 재미있게 작업을 진행했다.

나는 게임 번역 퍼블리싱으로 커뮤니티 활동을 해본 적이 있어서 추억을 돌아보게 되었다. 덕분에 더 재미있게 작업을 진행했다.

마치며

론처의 이탈률 감소를 10%를 두었지만 실제로 내가 인턴쉽을 수료했을 시점에 40%로 낮춰진 거로 기억한다. 그러나 실제 가능성보다 더 높게 설정하는 것이 OKR에서 지향하는 바라 크게 아쉽진 않다.

개인적으로 아쉬웠던 것은 회사 전략상 블록체인 업무를 주류로 두고 있어 내가 맡는 프론트엔드 업무가 뒤로 밀려나는 것이었다. 그렇지만 회사 전략은 게이머도 납득할만한 적정한6 운영이라는 점, 그리고 온보딩 ‘스프린트’는 임시 조직이라는 점을 고려하면 납득할 수밖에 없는 상황이었다.

그렇지만 인턴으로서 프로토타이핑만 하다 가는 것이 아닌, 주도적으로 서비스에 관여하는 점, 게임 커뮤니티와 소통해본 경험, 상용 게임의 스태프 롤에 내 이름이 들어가서 뿌듯했다.

인턴쉽 과정에서 블록체인 관련 업무가 열려 있었지만, 2개월 동안 내가 지향하는 전문성인 웹 프론트엔드 업무와 전혀 다른 블록체인 기술 숙련을 병행하는 일을 하기에는 업무 부담이 크다고 판단했다. 7 블록체인 업무까지 관여했더라면 아마 주어진 프론트엔드 업무의 절반만 가능했을 것 같다.

정보 공개에 관대한 회사 문화 덕에 내가 한 업무를 글로 작성할 수 있었다. 현재 나는 제품을 위한 과업을 주도적으로 설정할 수 있으면서 전문화된 웹 프론트엔드 그룹이 있는 스타트업을 찾고 있다.


  1. 해싱할 대상이 '1234'1234가 아닌, 단일 형식 1234으로 제공 되어야 한다는 이야기다. 첫번째 예시는 두가지의 해시 결과가 나와 결정적이지 않는다. ↩︎

  2. 블록체인 네트워크에 참여하는 컴퓨터를 의미한다. ↩︎

  3. 스프린트는 목표를 같이 달성하는 그룹을 지칭한다. 플라네타리움은 OKR을 이용하고 있는데, 자세한 소개와 사례는 Spoqa 기술 블로그 | 스포카가 OKR로 목표를 달성하기까지.에 가장 잘 설명되어 있는 것 같다. ↩︎

  4. 목표은 꼭 조직이 아니라도 개인 차원에서 세울 수도 있는데, 나는 “팀에게 도움이 되는 기여를 하자"를 목표로 두고, 핵심 결과로 “제품의 품질 향상 하기"를 두었다. ↩︎

  5. 접근성 업무와 비슷하지만 다른 결과로, 팀 차원에서 논리적 속성 개념에 익숙하지 않아 내가 관여한 로그인 페이지와 설정 페이지의 일부분만 Flex 레이아웃을 사용했다. 모든 UI의 레이아웃을 적절히 바꾸는 것은 작업량에 비해 중요도가 상대적으로 낮아서 오픈소스 프로젝트로 바뀐 뒤의 기여로 미루는 것을 생각했다.  ↩︎

  6. 회사의 목표는 탈중앙 게이밍 경험을 개척하는 레퍼런스 제품을 만드는 것이고, 그 게임의 기반이 되는 블록체인 네트워크 체계는 제품의 신뢰성과 직결하기에 정말 중요하다. ↩︎

  7. 모범사례가 있는 전통적인 서버를 겸했다면 이야기가 달라졌을지 모르겠다. 플라네타리움의 블록체인 업무는 소개한 회사 블로그의 내용처럼 게임에 특화된 P2P 라이브러리 — libplanet, 게임 클라이언트 SDK — lib9c, 게임 클라이언트 전용의 블록체인 노드 서비스 — NineChronicles.Standalone를 직접 개발해서 새로운 기술적 문제에 봉착하고 있다. ↩︎