입사 후 반년이 지났다.
이전 직장에서는 Technical Strategist 라는 이름의 전략 담당을 하였고, Front-end engineer 로도 잠시 일했었고, Product Manager로도, Product Owner 로도 일을 했었다. 여러 제품을 분석하고 적절한 제품을 설계하여, 해당 로드맵대로 일이 되게 만드는 게 내가 맡은 일 중 가장 중요한 일이었다.
현재는 Front-end Dev의 Tech Lead를 담당하고 있다. 기술적인 방향성을 결정하기도 하고, 직접 개발에 참여하기도 하고, 설계를 도와주기도 하고, 문서를 작성하는 방향을 잡기도 하고, 개인 성장에 도움이 될 만한 다양한 활동들을 수행하였다. 그러나, 어떤 일이던 정리하지 않으면 어떤 일을 했는 지 알기 어려운 법이다.
이 글에서는 입사 후 내가 했던 일들에 대해 작성해본다.
FE 파트 만들기
현재 FE 조직에는 5명의 팀원이 존재하여, 나를 포함한 6명이 함께 일을 하고 있다. 처음에는 나를 포함하여 2명이었는데, 짧은 시간에 규모를 3배까지 늘린 것이다. 채용 전략은 굉장히 심플하였는데, 믿을만한 조직이라는 걸 외부에 지속하여 어필하고 우리가 어떤 인재를 원하는가에 대해 지속하여 어필한 것이다.
조직에서 블로그를 대화 수단으로 많이 사용하였는데, 이게 큰 도움이 되었다고 스스로 생각하고 있고 외부에서도 그 경로로 가장 많이 입사를 하게 되었다고 알려주었다. 처음 조직을 만들어나가는 과정이 그렇게 순탄했다고 말하기는 어렵다. 그 사이에 코로나 유행이 다시 확산되고, 입사하고서 오프라인에서 한 번도 뵈지 못한 분도 계셨었고, 최근에야 이사짐을 싸기 위해 출근해서 처음으로 뵌 분도 계셨었다.
조직 구성원이 늘어나면서 FE 파트의 Tech Lead 로서 고민해야할 포인트가 많아졌는데, 협업을 어떻게 해야할 지에 대한 고민도 있었지만 구성원 개인 성향을 파악하고 가장 적절한 형태로 피드백을 주는 것이었다. 어떤 분은 마이크로 매니징을 원하는 경우도 있고, 어떤 분은 적절히 피드백만 주는 것으로 만족하는 경우도 있다.
일하는 방식 만들기
기존 회사에서 했던 경험 중 좋았던 경험들을 적극적으로 활용하였다. Asana 라는 태스크 매니저를 도입하여 태스크를 조금 더 면밀하게 관리할 수 있게 하였고, 사람이 늘어나면서 기술 문서 작성에 조금 더 힘을 쏟아달라고 하였으며, 테스트가 무엇보다 중요하니 테스트 커버리지를 늘려달라 요청하였다.
이 과정에서 OKR 을 적극적으로 활용하고자 하였는 데, 지금 OKR이 잘 정착하였냐 물어보면 그렇지는 않다 생각한다. 이는 나의 부족함도 가장 큰 원인이라 생각한다. OKR에 대해 더 많이 공부하고, 더 많이 usecase를 찾아서, 더 많이 조직에 녹여낼 수 있었어야 했다.
우리 조직에서 하고 있는 것들을 몇가지 공유하자면,
- 모든 FE 개발자는 성장 레벨이 존재하고, 성장 레벨을 통해 본인이 현재 어느정도 실력임을 가늠할 수 있다. 자신의 성장 레벨은 조직 내에서 투명하게 공개되고, 조직 외부에도 성장 레벨 기준을 공개하고 있다.
- 커밋에는 gitmoji를 사용한다. gitmoji를 사용하는 이유는, 단순히 로그를 잘 보고싶어서라기 보다 커밋을 잘게 쪼개기 위한 연습에 가깝다. 의미있는 수준으로 커밋을 쪼개는 데에 gitmoji 만한게 없다고 생각한다.
- 어떤 경우라도 스프린트 (2주) 내에 조직 차원에서 개인 스터디 시간을 부여하고 있다. 이는 업무에 너무 매몰되지 않고 지속하여 새로운 지식을 습득하고 경험하는 데에 리소스를 쏟아달라는 나의 부탁이기도 하다.
- Kudos card (칭찬 카드)를 통해 서로를 칭찬하는 문화가 있다. 좋은 조직을 만드는 데 서로에게 칭찬할 수 있는 문화가 기본이 되어야 한다고 생각하며, <매니지먼트 3.0>에서 채택하였다. 우리는 Hey! Taco를 사용한다. (유료다)
무엇보다 코드 리뷰를 중요하게 여기고 있는 데, 이는 코드 리뷰가 효과적인 제품 개발 수단이기 보다 효과적인 커뮤니케이션 수단이라고 생각하고 있기 때문이다. 제품 개발을 가장 빨리 하는 방법은 한 사람이 제품 하나를 맡고 죽이되든 밥이되든 만들어나가는 것이라고 생각한다.
하지만 제품 개발을 제대로 하는 방법은 서로 지속하여 커뮤니케이션하고, 코드에서 느껴지는 나쁜 냄새를 찾아내서 없애나가는 것이다. 어떤 코드가 나빠보이는 데 이유가 명확하지 않다면 그런 영역을 서로 커뮤니케이션 할 수 있어야 좋은 코드가 나온다고 생각한다.
적절한 기술 고민하기
프런트엔드 분야는 리액트가 사실상 정복하고 있다고 생각한다. 리액트를 쓰지 않을 수 있지만, 리액트와 비슷한 도구는 누구나 사용하고 있다. 대부분의 기업이 Vue, React, Angular, Preact, Svelte 중 하나는 사용하고 있다.
하지만 나는 언제나 라이브러리가 정답이라는 생각은 가지고 있지 않다. 라이브러리를 사용했을 때 예상하지 못한 이슈가 발생하면, 해당 이슈가 해결될 때까지 손 놓고 기다릴 수밖에 없는 상황이 닥치는 데 그런 상황을 제어할 수 있을 때 좋은 제품이 나온다 생각한다. 어떤 제품을 어떤 테크 스택으로 구현해야할 지 고민이 들 때에는 이전 직장에서 있었던 경험을 곱씹어 본다.
나는 주니어 였고 당시에 리액트가 굉장히 유행하던 시절인데 우리는 리액트를 사용하지 않고 있었다. 커리어에 대한 고민, 걱정같은 게 생기던 무렵이었다. 그러다가 언젠가 회의에서 ‘저희 리액트 쓰면 안되요?’ 라고 물어보았고, 그 때 들었던 답변이 ‘라이브러리는 우리가 사용하는 도구지, 우리가 도구에 지배되면 안돼요’ 라는 이야기였다.
테크 스택이라는 건 결국 그 시기에 가장 적절한 결정을 내리는 것에 불과하다. 지금은 정답이라고 생각했던 게 추후에 정답이 아닐 수도 있다. 그러니 코드를 설계하면서 도구의 장단점을 충분히 파악한 후에 현재 상황에서 가장 적절한 결론을 내리는 게 중요하다 생각한다.
예를 들어, DOM을 깊이있게 사용해야하는 애플리케이션을 개발해야할 때 리액트는 그렇게 좋은 선택이 아닐 수 있다. 리액트는 애초에 DOM을 직접 제어하는 걸 권장하고 있지도 않고, 언제나 상태가 리액트 컴포넌트에서 관리되는 걸 기대하고 있다.
그래서 테크 스택을 정하기 전에는 우리가 처한 상황을 분석하고, 스펙을 파악하고 난 후에 가장 적절한 테크 스택을 고르는 게 좋다고 생각한다. 때로는 바퀴를 재발명하는 게 옳은 선택이 되기도 하고, 때로는 기존에 있던 제품을 가져다 쓰는 게 옳은 선택이 되기도 한다.
매니지먼트
존경하는 피터 F 드러커 교수님이 작성한 매니지먼트라는 책에서, 지식 노동자는 돈만 보고 움직이지 않고 기업에서 자아를 실현하는 데에 초점을 맞춘다고 하였는 데 매니저가 되고 나니 그 말이 무엇인 지 이해가 된다.
적절한 수준의 보상은 당연히 중요하지만, 기대할 수 있는 보상 수준이 비슷하다면 사람은 자아실현을 할 수 있는 더 나은 조직을 꿈꾸게 된다. 그러니 내 역할은 사람들이 현재 속한 조직이 더 나은 조직이라고 인지할 수 있도록 조직을 꾸려나가는 일이다.
