2021년 회고 및 미래 계획

Notion에서 더욱 깔끔하게 읽을 수 있습니다.

https://glass-lily-8dc.notion.site/2021-8be2f1577d7c49e1836550788cb09746

2021년 회고 및 미래 계획

 

1년을 회고해보니 회고와 동시에 미래에 대한 계획도 어렴풋이나마 생기게 되어 정리해본다.

뒤돌아보니 회사에 근무한 6개월간 나름 치열하게 성장도했고 동시에 스스로에 대한 부족한 점도 알게되었지 않나 싶다. 가장 큰 건 관심 있는 분야가 생겼다는 것.

 

1. 첫 회사

2021년 6월 말에 BUSINESS CANVAS에 조인했다. 친구의 친구가 참여하고 있는 회사였는데 블포파 피칭데이에서도 등장하고 심지어 학교 수업 시간에도 언급되는 등 다양한 곳에서 언급이 되어 궁금증이 생겼다. 그래서 무작정 인턴 자리 없냐고 물어보고 없는 자리를 만들어 지원했었다. 지원 후에는 일반 정규직의 입사 절차인 코딩테스트 → 기술면접 → 팀핏 면접을 통해서 선발되었다.

 

생각해보면 당시의 마음가짐은 굉장히 가벼웠다. 첫 회사라기보다는 미래에 창업을 할 생각이 있어서 스타트업의 생리를 몸소 경험하고 배우고 싶어서 반쯤은 투자하는 기분으로 지원하였다. 그래서 제대로 된 이력서라기보다는 정리하고 있었던 개발 블로그와 github 주소를 첨부하였다. 자기 소개서는 우대 사항에 해당 되는 내역을 상세하게 적는 등 성의있게 적긴 했지만 분량은 A4 반장 정도로 비교적 간략하게 적어 보냈다.

 

당시에 보냈던 포트폴리오는 대략 아래처럼 생겼었다.

Portfolio

Portfolio

 

결론적으론 학기 중에 인턴으로 들어가서 일을하다가 정규직으로 전환되었다. 인턴 정도로 스쳐갈 회사라고 생각했는데 첫 회사가 되어버린 것이다. 물론 그 사이에 회사도 성장하여서 라운드가 높아졌다.

 

50억을 투자받고 시리즈 A 회사가 되었다.
비즈니스캔버스, 50억 투자유치..."글로벌 SaaS 기업 도약" - 머니투데이

 

초반에는...

• 익숙하지 않았던 프로젝트 구조
  • 첫 회사이기도 했고 사이드 프로젝트 이상의 프로덕션 레벨의 코드를 처음 접해보아서 초반에는 힘든 편이었다. 무엇보다 내가 알고 있는 구조가 아니었다.
  • 현재 폴더링과 모델링을 포함해 FE의 전반적인 구조를 개선하고 있는 리팩토링 작업을 하고 있음을 감안한다면, 내가 만약 그 때 더 노련했더라면 프론트 아키텍쳐 개선을 건의하고 주도할 수 있었을텐데란 생각이 든다. 이 건에 대해서 얻을 수 있는 것은 다음과 같았다.
    • 신규 입사자가 들어온 시기는 기존에 발견하지 못했던 결함(그것이 개발이든, 문화이든)을 발견할 수 있는 소중한 기회라는 것
    • 내 경험과 실력이 부족하다는 것
  • 프론트엔드 구조 개선이 이루어지면 이를 회사 기술 블로그에 정리해서 되새김질해볼 예정이다.
• 피어 코드 리뷰
  • 코드 리뷰 자체가 처음이었다. 그런데 merge protection 규칙이 최소 2명 이상의 리뷰를 받아야만 merge가 가능하게끔 설정이 되어 있었고, FE가 나를 포함해 3명밖에 없었기 때문에 결과적으로 내가 리뷰를 하지 않으면 merge가 되지 않았었다.
    • 프로젝트의 전체적인 그림 자체도 명확하지 않은 상태에서 리뷰를 해야만했고, 설사 approve를 하더라도 merge된 이후에 문제가 발생하면 리뷰자인 내가 책임을 물어야 할 것 같아서 부담스러웠다.
    • 게다가 내가 할당 받은 ticket 처리에도 시간이 부족했었는데 리뷰를 진행하다보니 context switching의 비용이 컸었다.
  • 결국 리뷰가 늦어져 개발 속도가 늦어지게 되었다.
    • 이 문제는 내가 성장하면서 일부 해소가 되었다.
    • 리뷰에 너무 큰 의미와 책임을 두게 되면 오히려 리뷰가 악효과를 가져오게 되는 것을 경험했다. 그렇다고 대충하라는 말은 아니지만 장고 끝에 악수 둔다는 말이 있지 않은가.
    • 돌이켜보면 프로세스 자체의 개선이 불가능했을까 생각이들지만, 오히려 이렇게 빡빡했기 때문에 사수가 없는 스타트업에서 그나마 코드 퀄리티를 유지하기 위한 최선의 방법이 아니었나 싶다.
    • 현재는 기존 멤버들의 성장 + 훌륭하신 분들의 입사로 리뷰 적체 문제는 상당 부분 해결되었다.
• 온보딩
  • 온보딩은 ‘신규 입사자니 이 시간 동안 잘 적응하세요'가 아니라 ‘이 시간 안에 자신의 쓸모를 입증하라’는 것에 가깝다고 생각한다. toxic한 생각일지도 모르겠지만, 적어도 나는 그렇게 느꼈다.
    • 다른 회사에가서 다른 경험을 하면 또 달라질지도 모르는 일이다...
  • 런웨이를 계산해나가면서 하루하루 일을 진척시키는 것이 스타트업 때문에 이 사람이 필요한지 아닌지가 상당히 빨리 판가름나는 편이다.

 

2. 개발

컨벤션의 중요성

• 프로젝트의 규모가 커질수록 규칙을 정하는 것은 매우 중요해진다.
  • 특히 css를 우습게 보면 안된다. 프로젝트의 규모가 커질수록 정말 걷잡을 수 없어진다.
    • NHN css convention을 참고해서 자체적으로 CSS Convention을 기존 멤버분이 사용하고 계셨는데 천만다행인 일이다.
    • 프로젝트가 커지면서 z-index repository를 만들어 관리하고 있다. 잘못 관리하면 서비스가 복잡해질수록 정말 지옥을 맛볼 수 있다. (vscode 소스 코드를 참고함)
• 이 모든 것들을 위해서 eslint, stylelint, prettier formatter를 pre-commit 시점에서 git hook을 통해 작동하도록 만들었다.
  • stylelint가 자동으로 내가 설정한대로 (심지어 css-in-js도) fix해주기 때문에 css convention을 수동으로 확인하지 않아도 되어서 리뷰 시간이 매우 많이 단축되었다.
  • import 순서에 대하여 prettier-plugin-sort-imports를 통해 formatter단에서 해결하는 방법과 eslint-plugin-import를 통해서 lint단에서 해결하는 방법 사이에서 결론적으론 eslint-plugin-import를 만족스럽게 사용하고 있다.
  • react-hooks/exhaustive-deps rule은 정말이지 최고다.

 

FE에서의 도메인 주도적인 설계의 필요성

• 엄격한 DDD를 말하는 것이 아니다.
• bizdev팀 ↔ 기획팀 ↔ 개발팀 간의 용어를 통일할 필요성을 느꼈다.
  • 이건 여러 팀과 멤버들이 노력해주어서 어느 정도 통일이 된 상태이다.
  • 특히 서비스 특성상 한 entity가 다른 entity의 역할을 겸임할 수 있어서 말을 하다보면 우리 스스로가 헷갈리는 경우가 많았다.
    • ex - 우리가 정의한 ‘Document’가 Document도, Folder도, Resource도 될 수 있는
• fetching해온 데이터를 model에 맞게 class로 wrapping하고 관련 조작 함수들을 메서드화해서 관리하는 방법론을 멤버분이 제안해주셨는데, 아직 작업이 끝나지 않았지만 복잡했던 비즈니스 로직이 점차 자리를 잡아가는 것 같다.
  • flutter의 방식을 차용한 것인데, 이런 사례만 보아도 다른 영역을 공부해두는 것은 언젠가 도움이 되는 것 같다.

 

기술에 대한 깊은 이해에 대한 추구 필요

• 번들링
  • 기존 프로젝트에서는 neutrino.js라는 라이브러리를 사용하고 있었으나 javascript → typescript 마이그레이션을 위해서 싹 밀어버리고 webpack를 활용해서 바닥부터 다시 빌드했다.
    • 솔직히 ‘작동한다’에 가깝지 ‘잘짰다'는 아닌 것 같다.
  • 이 과정에서 번들러에 대한 공부를 이것저것 살펴보았다. 지금은 없어졌지만 회사에서 browser extension을 만들면서 newTab을 vite.js로 번들했는데 매우 빨라서 놀랐다.
• 내가 typescript를 알고 있는 것이 맞나
  • Components props 타이핑 좀 해주는 수준이 아니라 제대로 알고 있는지에 대한 의문이 들기 시작했다. 나는 타입스크립트에게 정말 내 의도를 이해시키고 있는 것인가?
  • [April 2020] Epilogue & Session 3. 타입스크립트에게 내 의도를 이해시키는 방법 - 김혜성 님
• FE의 배후에 놓인 기술들이 어쩌면 나의 edge가 될 수 있을 것 같다는 생각이 든다. javascript가 아닌 타 언어를 활용해서 프론트엔드의 성능이나 DX를 향상시킬 수 있는 것이 매우매우 매력적이라고 생각한다.
  • Go언어로 만들어진 esbuild를 보면서 FE에 이런 분야가 존재한다는 것을 알고서는 관심이 가게 되었다.
  • Go와 Rust를 배우고 싶다
  • swc와 같은 프로젝트를 보고 내가 모르는 것이 너무 많다는 것을 느꼈다
  • [A6] swc와 웹 개발의 미래
• 상반기 즈음에 진행할 browser extension 개선 프로젝트를 rollup + 모노레포로 구성해보고 싶다.
• Web 3.0을 공부해보고 싶다.
  • buildspace 가입만 해놓은 상태
  • buildspace

 

오픈소스를 만들어보다 (⇒ 개밥먹기도 시도해보자)

부끄럽지만 이렇게라도 연습을 해보고있다.

솔직히 메인테인을 할 정도의 프로젝트는 아닌 것 같다.

ko-fuzzy

typed-design-system

 

2022년에는 가능하다면

한국어+영어 조합에서 사용 가능한 client-side 검색 기능 라이브러리를 만들어서 배포해보고 제대로 메인테인을 해보고 싶다. 추가적으로 이렇게 만든 오픈소스 라이브러리를 회사 내에도 도입하여 개밥먹기를 해보고 싶기도 하다.

 

개발 문화 조성에 대하여

• 테크 블로그 개설 및 활성화 시도
  • 처음에는 gatsby로 개발 블로그를 직접 만드려고 했다.
    • 실제로 github action을 통해서 간단한 배포 프로세스도 만들었지만, 지속적으로 블로그의 개발적 퀄리티에 신경을 쓸 리소스가 없다고 판단하였다. 결국에는 미디엄 블로그를 열었다.
  • 블로그는 만들어졌지만 팀원들이 자발적으로 글을 쓰게 만들어야 한다.
    • 현재 회사에선 팀원간 사이가 돈독(?)한 편이라서 알게된 것을 공유하는데 거리낌이 없는 편이다. 공부하기 좋은 자료가 생기면 가장 먼저 올리는 곳이 slack이다.
    • 회사에서 일을 통해 얻게된 지식을 글로 정리하는 것은 개발자 채용에도 도움이 되고 회사의 인지도를 높이는데도 도움이 된다.
    • 글쓰기를 의무로 만드는 것은 의미가 없다. 현재 회사에 적극적으로 어필해서 개발 블로그 작성에 포상금이 주어지도록 만들었다.
    • 그러나 개인 블로그가 아닌 회사의 이름을 달고 쓰는 개발 블로그는 부담감이 심한 편이다. 솔직히 지금까지 글이 딱 1개밖에 없다. 블로그를 만든지 얼마 안 되었으니까 좀 더 지켜보자...

 

자기 PR

• CV역할을 할 영문 버전의 개인 블로그를 만들어야 할 필요성
  • 현재 블로그는 신변잡기적인 내용까지 잡다하게 들어가 있다. CV 역할을 할 깔끔한 영문 블로그가 필요
    • 영문 블로그에는 지금처럼 아무 글이나 적지 말고 깊이 있고 핵심적인 글만 올려야 한다. 대표적인 예시로는 아래와 같은 블로그들이 참고해볼만 하다
      • TK
      • Anthony Fu
• 내가 새롭게 배운 것들을 녹여낸 사이드 프로젝트 개발의 필요성
  • 사실상 github에 있는 다양한 코드들은 내가 알고 있는 것들, 배운 것들과 어느 정도 괴리가 생긴 편이다.
  • 현재 시점으로 보니 과거에 짠 내 코드들이 더럽다고 느껴지는 부분이 많다.

 

etc

• 주말을 앞두고 배포를 진행하는 것은 좋지 못한 생각이다.

 

3. 비즈니스

• 회사의 오너로써
  • 작동하는 것 / 쓸 수 있는 것 / 팔 수 있는 것
    • 트위터에서 어떤 분이 말씀하신 분류인데, 정말로 절묘하다고 생각한다. 이 셋 사이의 차이는 정말로 크다.
  • 직원이 불만없이 일에 몰입할 수 있는 환경을 조성하는 것도 대표의 능력이다
  • 데이터 기반 제품 개발과 의사 결정의 중요성
  • 시장 크기 >>>>>>> 팀 >>>>>>>>>>>>>> 아이디어
    • 학교에서 지속적으로 공부한 내용이지만 체감해보니 그 정도가 다른 것 같다. 정말로 처음의 아이디어 그 자체로서는 아무 의미가 없다.
  • valuation은 정말로 협상의 영역이다. 같은 지표와 결과를 가지고서도 초기 기업의 valuation은 10배 이상 차이가 날 수도 있다. 정말이다.
• 회사의 직원으로써
  • 개발팀이 핸들을 잡고 있는 회사로 가야 한다.
    • 핸들을 쥐고 있다면 적극적으로 운전해야할 책임이 있다. 위에서 주는 것만 한다는 입장도 존중하지만 아직은 내 성격이 그걸 받아들이기에 쉽지 않은 것 같다.
    • 특히, 부채 청산 기간은 개발자가 책임지고 얻어내야 한다. 기술 부채가 비즈니스적으로 어떤 결과를 불러올지 제일 잘 알고 있는 사람이기 때문이다.
  • FE에 대한 생각이 어떠한가. 단순히 '뷰 찍는 사람' 정도로 생각한다면 실제로도 그 정도 일밖에 안하고 있을 가능성이 높다. 다행히도 지금 회사는 너무 좋은 편.
  • 면접을 통해 해당 회사의 내부 분위기를 파악하라고는 하지만 사실 면접으로는 제대로 알 수가 없다. 그럼에도 불구하고 낮은 퇴사율은 좋은 회사와 유의미한 관계가 있는 듯하다.