연말회고 두둥등장! (요즘에 머쉬베놈에 빠져있음)

스타트업에서 개발자로 일한다는 것

올해초에 서울로 올라와서 취준을 하다가 운이 좋게 3월말이라는 빠른 타이밍에 지금의 회사에 합류해서 지금까지 개발자로 일하고 있다. 나와 내 대학동기들이 지겹게 겪었던 정보격차 문제, 관심 분야의 실제 직무를 체험하기 힘든 문제를 해결하는 회사이다. 수평적인 환경에서 독자적인 개인으로서 성장할 수 있는 환경도 마음에 들었다.

우리 회사는 데이터에 기반하여 의사결정을 한다. 그리고 끊임없이 실험한다. 처음에는 이 말이 잘 와닿지 않았는데 계속 일을 하다보니 피부로 와닿았다. 제품을 개선하거나 수정할 때 “이게 더 이쁘다.”, “이게 더 나아보인다.” 라는 추상적인 생각은 근거가 되지 않는다. “이 부분을 이렇게 바꾸면 제품의 어떤 면이 더 좋아져서 어떤 퍼널로의 전환율이 증가할 것이다.” 라는 가설을 세우고 A/B 테스트를 진행한다. 해당 url로 들어오는 유저들에게 A안 또는 B안을 보여주고 유저들의 행동을 분석한다. 실험이 끝나면 실험 결과를 분석하고 문서화해서 의사결정에 사용한다. 이렇게 유저들을 학습한다.

수평적인 문화를 바탕으로 구성원 누구나 눈치를 보지않고 목소리를 낼 수 있다. 그 목소리들이 누군가가 놓치고 있는 것을 캐치해줄 수 있었고, 누군가에게 발상의 전환점이 될 수 있었다.

대표님(사내에선 대표님이라고 안부름)이 중요하게 생각하시는 결정하는 연습을 계속하고 있다. 업무의 우선순위, 예상마감일 등을 스스로 결정하면서 자신의 업무를 관리한다. 그 과정속에서 독자적인 개인으로 성장하고 있다고 느낀다.

프론트엔드 팀내에서 나의 역할

기술적으로 괴롭히기

나의 팀내 주 역할은 기술적으로 괴롭히기라고 생각한다. 코드를 보다가 개선할만한 지점이 있거나 새로 적용해볼만한 기술들이 있으면 정리해서 프론트엔드 스크럼 때 공유했다. 다른 분들도 많이 공유를 해주셨다. 공유를 하면 잘 귀기울여주시고, 각자 생각하는 의견을 말씀해주셔서 피드백도 자유롭게 이루어졌다. 그런 팀원들이 정말 고맙고 같이 일을 할 수 있어서 고맙게 생각하고 있다.

프론트엔드팀 Datadog 관리자(?)

어쩌다보니 프론트엔드팀에서 Datadog 매니저님과 커뮤니케이션 하는 사람이 내가 되었다. 프론트엔드 팀에서 사용하고 있는 서비스의 요금도 내가 모니터링하고 관리하고 있다. 내가 Datadog에 가장 관심이 많아서였는지 Datadog이라는 미지의 세계를 가장 먼저 개척하고, 사용법을 요약해 팀내에 공유한적이 있다.

기억에 남는 활동들

Junction X Seoul 2020 해커톤

작년에 같이했던 팀원 한명이랑 회사 동료들 3명과 함께 참여했다. 포지션은 기획1, 디자인1, 프론트엔드3(?)이었다. serverless framework + lambda로 해커톤 규모의 백엔드 정도는 구현할 수 있을 거 같아서 내가 백엔드를 자처했다. 그렇게 나는 프론트엔드 + 가성비 백엔드(팀원피셜) 역할을 맡았다. 가성비 백엔드라는 별명이 매우 마음에 들었다. 🤣 작년에는 내 구현능력이 많이 부족했고, 핵심을 파악하지 못했어서 많이 아쉬운 부분이 있었다. 그래서 이번에는 코어 기능의 완전한 구현을 목표로 삼았다.

기획단계부터 개발단계까지 순조롭게 진행됐다. 작년에 참여했던 경험도 도움이 됐고 많이 비교가 됐다. 사이드 프로젝트가 아닌 해커톤이라는 걸 명심하고 주제와 서비스 타겟을 기준으로 아이디어들을 필터링했으며, 코어 기능을 중심으로 세부기능들을 가지치기 해나갔다. 그 결과 코어 기능을 만족스럽게 구현했고 발표자료도 잘 만들었다. 그리고 운이 좋게 해당 트랙에서 2등상을 수상할 수 있었다. 🎉

내 친구가 연말회고 때 인용했던 말이 있다. "최고의 복지는 동료다." 이 때 나는 해커톤에 나가자고 하면 기쁜 마음으로 승낙해주는 동료들이 있다는 것이 참 고마웠다.

오픈소스 컨트리뷰톤

작년에는 여유가 없어서 참여하지 못했던 컨트리뷰톤이었다. 올해 컨트리뷰톤 신청 당시에는 회사 업무가 널널해서 충분히 소화할 수 있을 것이라고 생각했는데 거짓말처럼 컨트리뷰톤 활동 시작시점부터 회사 업무가 많아져서 컨트리뷰톤에 시간을 많이 쓰지 못했다. 처음 2주간은 회의에 참여하는 것이 활동의 전부였다. 회의에 참여해도 무슨 내용인지 이해하기 힘들었고 잘 따라가는 다른 멘티분들이 대단해보이고 부러웠다. 스트레스를 많이 받아서 포기할까 하는 생각도 들었다. 내 목표는 PR 최소 1개 작성 이었는데, 뭐라도 해보자는 생각으로 프로젝트 코드를 쭉 읽어보면서 오타를 찾아냈다. 이렇게 많은 사람들이 유지보수하는 프로젝트에는 오타가 별로 없을 줄 알았는데 5개나 찾았다. 생각보다 많아서 놀랐다.

Fixing typos by donghoon-song · Pull Request #4404 · mochajs/mocha

원래 오픈소스 입문은 오타찾기나 번역이라고 했다 😎 이렇게 PR을 올리고 merge가 되니까 뭐라도 했다는 뿌듯함과 자신감이 생겼다. 최소한의 목표를 이뤘던 나는 그 후로 오기가 생겨서 뭐라도 한개만 더 해보자라는 마음가짐으로 task를 찾게 되었다.

Fix: Broken wallaby logo on mochajs.org #4430 by donghoon-song · Pull Request #4431 · mochajs/mocha

위의 PR을 올리면서 디버깅하는 실력이 많이 늘었다. 패키지들을 타고 타고 들어가다보니까 이슈를 해결할 수 있었다.

Add support for node v8 option ‘prof’ parameter (#4433) by donghoon-song · Pull Request #4439 · mochajs/mocha

Update eslint version by donghoon-song · Pull Request #4443 · mochajs/mocha

이슈 해결과정을 정리해서 블로그 글로 남겨보기도 했다.

초보 컨트리뷰터의 Mocha issue 해결 도전기

중도 포기하는 분들도 계셨지만 열심히 참여하다보니 어느새 활동을 마무리할 수 있었고 상도 받을 수 있었다. 컨트리뷰톤을 통해 오픈소스를 바라보는 관점이 달라졌다. 활동전에는 미지의 영역이고, 어렵게만 보이던 것들이 어느정도 눈에 들어오기 시작했으며 다른 기여활동으로 이어지기도 했다. 조금이나마 성장했다는 확신을 할 수 있는 계기가 되었다. 그리고 추후에 사내 컴포넌트 패키지를 관리하는데도 큰 도움이 되었다.

[OpenSource] 초보 컨트리뷰터의 Nuxt docs PR 도전기

Figma - agit webhook 연동

디자이너 분들과 협업을 하다가 개발했다. 개발자는 아무래도 피그마(디자인툴)를 자주 보지는 않기 때문에 디자인 변경사항을 실시간으로 체크할 수 없다. 또한 디자이너분들이 어떤 것을 요청했을 때, 작업이 됐는지, 확인은 했는지 여부가 불투명하여 커뮤니케이션 비용이 발생한다.

그래서 디자이너님들이 특정 조건으로 메시지를 남기면 아지트(협업툴)에 프론트 개발자를 담당자로 해서 글이 남겨지도록 만들었다. 나는 메시지에 [개발팀] 이라는 텍스트가 포함되면 발동하도록 조건을 걸어놨다.(아주 간단) 그러면 개발자는 피그마를 계속 확인하지 않아도 꼭 필요한 메시지를 비동기적으로 받을 수 있다. 피그마에서는 디자이너분들끼리의 코멘트와, 개발자에게 보내는 메시지가 분리된다. 또한, 아지트에서 각 코멘트에 대한 업무 진행 상황을 투명하게 체크할 수 있다.

정말 간단한 로직과 기능임에도 불구하고 팀원들은 아주 잘써주고 있고, 생산성도 많이 향상되었다. 이렇게 팀원들의 생산성 향상에 기여했다.

프론트엔드와 백엔드의 코드 분리

기존 레거시 시스템은 laravel framework 위에서 blade template engine으로 vue파일을 렌더링하는 구조이다. 이렇게 laravel에 의존적인 구조여서 프론트엔드의 자유도가 낮았다. routing을 백엔드에서 주로 담당해서 vue store를 제대로 활용할 수 없었고 뭔가를 수정할 때 백엔드 개발자의 도움이 필요한 경우도 많았다. 또한 사용하려고 하는 패키지 중에 잘 호환되지 않는 패키지들도 있었다.

그래서 오랜시간 PS(Problem Solving)세션과 회의를 거쳐 점진적으로 코드를 분리하기로 결정했다. 새로운 프로젝트에서는 Nuxt framework를 사용하기로 했다. SEO가 필요한 페이지에서 SSR을 부분적으로 적용할 수 있다는 점이 가장 큰 장점이었다.

Design System 개발

Component package 개발 link

• 코멘토에서 쓰이는 Component들을 디자이너들과 함께 Design System화하는 중이다.
• 양도 많고 복병들이 있어 난이도도 높았지만 하고 싶었던 업무이고, 완성하고 난 뒤 얻을 수 있는 생산성, 재사용성을 생각하며 즐겁게 만들고 있다.
• 모든 작업은 개별 branch에서 이루어지며 develop branch로의 모든 merge는 PR을 통해 이루어지며 최소한 한명의 리뷰어가 리뷰를 남겨야하고, CI test를 모두 통과해야 merge할 수 있다.

프론트팀은 디자이너팀의 동의를 받아 패키지를 공개하기로 결정했다. 이 결정을 하기까지는 많은 고민이 있었다. 공개 하는 것도 버전1이 만들어지면 공개할지, 미완성상태에서 공개할지도 고민을 많이 했다. 아무래도 주니어들끼리 작업하다보니 서투른 부분도 있고 비효율적인 로직도 있어 공개하기 부끄러운 마음도 있었다.

하지만 그걸 무릅쓰고 공개를 하는 이유는 그 반대의 사고과정을 거쳐 찾았다. 지나가다 볼 누군가가 피드백을 주면 그걸 자양분삼아 더 발전시킬 수 있을 것이라는 생각을 했고, 아직 완성되지는 않았지만 완성해 가는 과정, 개선해나가는 과정을 공개적으로 진행하는 것도 누군가에게는 자극, 누군가에게는 도움이 될 수 있을 것이라고 생각했다.

CI

• chromatic 도입

  • visual test tool

  • chromatic을 이용하면 storybook을 빌드할 때마다 해당 버전과 비교할 base 버전과의 UI상의, code상의 차이를 보여준다. 구성원들이 차이를 비교하면서 변경 사항을 approve해야 리뷰가 통과된다.

    [Storybook] Storybook visual test with Chromatic

  • PR을 올리거나 올린 상태에서 변경사항이 생기면 chromatic github action이 동작한다.

  • slack에 연동하여 빌드될때마다 메시지가 오고, 결과물을 바로 확인 및 리뷰할 수 있게 했다. 리뷰가 완료되면 완료 메시지도 보내준다. 팀원들이 PR을 확인하기까지의 시간이 대폭 감소하였으며, 자신의 PR이 리뷰됐는지도 빠르게 확인할 수 있어 좋았다.

• build test 도입
  • 정말 간단하게 github action을 통해 build를 해보는 test이다.
  • 처음에는 이런게 필요할지 몰랐지만 작업을 하다보니 필요성을 느껴서 만들었다.
  • 당연히 되어야 할 것도 테스트 해야한다. 는 마음가짐이 이때 생겼다.
  • 코드 상에서 실수를 해서 빌드가 안되거나, merge를 했는데 lint에서 통과를 못해서 빌드가 안되는 경우를 방지할 수 있었다.

CD

• shipjs 도입

  • 오픈소스 라이브러리를 배포하는 것은 간단하지 않았다.

  • 버저닝, npm에 배포, 태그 생성, changelog 작성 등의 일련의 과정들로 이루어졌다.

  • 이 과정들을 항상 수동으로 하기에는 실수도 많이 나고, 리소스가 많이 들겠다고 생각했다.

  • 마침 JSConf Korea 2020에서 이은재님께서 shipjs라는 라이브러리를 소개해주셔서 사용중이다.

    JSConf Korea 2020 - 발표자 | 이은재

  • 사용하다가 변수명 오타를 발견해서 기여를 한건 덤이다!

    fix: typo in GitHubAction config by donghoon-song · Pull Request #928 · algolia/shipjs

  • 나의 작은 발자취를 남길 수 있었다. 😎

    

• storybook deployer 도입

  • storybook deployer라는 툴을 이용해 공식 버전의 스토리북을 배포한다.
  • 이것도 배포할 때 자동으로 실행될 수 있도록 github-action에 등록해두었다.
  • 현재는 github pages에서 호스팅하고 있다. link

TODOS

• 번들러 변경
  • Rollup을 통해 Single File Component 형식으로 필요한 컴포넌트만 import해서 사용하는 구조로 패키지화하려고 하였으나 밑바닥부터 새로 세팅하는 과정에서 에러들을 발견했고, 시간이 오래 걸려서 잠시 보류해두었다. 내년에 해결해보려고 한다.
  • 현재는 vue-cli-service의 build 명령어를 사용해서 패키지화하고 있다.
• 패키지 경량화
  • 현재 패키지 파일이 굉장히 크다. 아직은 세팅에 미숙해서 최적화 및 경량화 하는 방법을 적용하지 못했고, 차차 공부하면서 적용해볼 생각이다. (웹팩 주니어이다. 🐣)
• 단위 테스트 코드 작성
  • jest를 이용해 단위 테스크 코드를 모두 작성하고 개발과정에 넣고 싶었다.
  • 하지만 구현해야 할 컴포넌트의 양이 너무 많아서 보류 중이다.
  • 내년에는 열심히 테스트를 작성해서 CI과정에 넣고 싶다.

Datadog

개발팀에서 Datadog을 도입했다. 프론트엔드의 경우 모니터링할 툴이 없었는데 Datadog의 도입으로 여러가지 지표 확인, 로깅, 테스팅, 유저 분석, 알람 등이 가능해졌다. 서비스가 커져감에 따라 이 기능들의 필요성은 더욱 증가할 것이라고 생각했고 정말 중요하게 생각했다.

처음 체험기간을 거치고 나서, 팀장님이 꼭 필요한 기능이 아니면 구독을 해지하는 가지치기를 하려고 하셨다. 처음 그말을 듣고 겸사겸사 쓰면 안될까? 하는 생각이 들었는데 시간이 지나고보니 팀장님의 뜻을 이해할 수 있었다. 모든 것은 비용이다. 굳이 필요로 하지 않는 서비스를 이용하는데 돈을 낼 필요는 전혀 없으며 우리가 꼭 사용해야 할 서비스는 누가 들어도 설득될만한 이유를 바탕으로 하고 있어야 함을 말이다.

솔직히 그 이유를 작성하기가 꽤 어려웠다. 아직 Datadog의 기능들에 익숙해지지 않아 기본적인 사용법 정도밖에 숙지를 못했다. 하지만 최대한 설득해보려고 노력했다. 설득하는 과정도 성장의 과정이라고 생각했다. 또한, 지금뿐만이 아니라 장기적인 관점에서 꼭 필요하다고 생각했다.

연말회고를 하는 지금 시점에서 돌이켜보면 굉장히 잘한 선택이라고 생각한다. 현재는 데이터독을 그때보다 더 잘 활용하고 있다. Front End단에서 기본 로그말고도 custom logger를 개발해 특정 이벤트 모니터링에 활용하며, 이슈 해결용에도 쓰고 있다. 모니터링을 하지 않을 땐 발견하기 쉽지 않았던 이슈들도 발견해서 고칠 수 있었고 로그를 활용하는 것도 점점 익숙해졌다. 핵심 활용 사례들을 노션에 정리해서 계속 쌓아가고 있다.

마법이 마법이 아니게 되는 순간

어떤 유명한 개발자분이 기초가 부족하면 그 기술이 마법처럼 보인다. 라고 말씀하셨다. 내가 초반에 겪었던 현상이었다. 하지만 시간이 지날수록 어떤 패키지나 프레임워크의 코드를 뜯어보는 경우가 생기면서 신기했던 마법들이 마법이 아니게 되는 순간들이 찾아왔다. 결국엔 모두 기초를 기반으로 한 코드 덩어리들이라는 생각이 들었다. 아직은 많이 부족하지만 조금씩 성장해감을 느낄 수 있었다. 물론 그 코드들을 보고 한번에 이해할 수는 없어 여러번 읽어야 겨우 이해할 수 있는 상태지만 이해할 수 있는 근육을 키우고 싶다.

2021년에는

2021년에는 업무에 더 능숙해지고 싶고, 그만큼의 여유를 만들고 싶다. 그 여유를 가지고 생각만 하고 못해봤던 것들을 해보고 싶다. 2020년에 기술도입이 많았다. 많은만큼 아직 깊이가 쌓이지 않았다. 그 기술들과 기초지식들의 깊이를 쌓고 싶다. 그래서 남들에게 설명할 수 있을 때까지, 질문을 해도 답해줄 수 있을 때까지 익히고 싶다.