조금 늦긴 했지만 22년을 되돌아보는 겸, 글을 남겨본다.
새로운 회사로 이직한 지 1년이 지났다. 새로운 비즈니스를 발굴하면서 새로운 사람들과 기술을 접하게 되었다. 이 모든 새로운 것들이 나를 설레이게 만들었다. 새로운 도메인을 배우는 것은 사업적인 영역과 기술적인 영역을 동시에 고려하며 배워나가는 과정이었고, 새로운 사람들을 만나면서 서로 대화를 나누며 생각을 공유하는 것이 즐거웠으며, 새로운 기술을 사용하면서 끊임없이 공부하는 것이 나를 성장시켰다. 물론 과정이 좋았지만 결과가 좋지 않은 경우도 있었고, 그래서 즐거움에 비해 보람을 느끼기 어려운 경우도 많았던 한 해였다.
작년 회고에는 분명 "2022년은 자신을 좀 더 돌보면서 생활하는 한 해가 되어야겠다고 다짐해본다."
라는 표현으로 끝을 맺었는데, 이를 생각보다 잘 이룬 것 같아서 만족한다. 건강을 챙기려 헬스를 다녔고, 다이어트를 병행하며 규칙적인 생활을 하는 루틴을 만들었다. 물론 잠과 일 사이에 운동이라는 루틴이 하나 추가된 게 끝이어서 조금 아쉽지만, 새로운 루틴을 한 번 만들고 나니 다른 루틴은 금방 만들 수 있지 않을까하는 자신감이 생겼다. 물론 건강 말고도 업무적인 영역에서도 발전이 있었다. 팀원들과 스터디를 진행하면서 조직 문화나 기술적인 영역에서 시야를 넓힐 수 있었고, 실제로 사용 중인 기술 스택에 대한 이해도도 꽤 높일 수 있었다. 특히 팀 내에서는 SSR에 대한 관심도가 매우 높았는데, 다른 분들이 작성하신 코드를 보면서 SSR 처리에 대한 방식을 꽤 많이 배울 수 있었다.
2022년엔 무엇을 했는가?
디자인 시스템의 구현
2022년 중 가장 기억에 남는 이벤트라고 하면, 디자인시스템 구축인 것 같다. 아쉽고, 또 아쉽지만, 처음부터 욕심을 부려서 완벽하게 하자고 했던 나에게 정말 많은 후회가 든다. 시니어 개발자분께서 굉장히 많은 방향성을 잡아주시고, 방법론, 가이드라인, 벤치마킹 등 많은 영역에서 조언을 주시고 작업했는데, 코드를 작성하는 건 사실 어려운 일이 아니었지만, 어려운 일은 그것을 만들어내는 인터페이스 구현, DX의 고려, 문서 작성 그리고 디자인시스템 가이드라인을 정립하는 일들이었다. 특히 디자이너분들과 많은 대화를 나누면서 느꼈던 부분은 디자인시스템 컴포넌트를 정의하고 나서, 이것을 가지고 제한적인 디자인을 하게 될 때 발생하는 문제, 그리고 디자이너분들 서로 간에 디자인시스템 컴포넌트를 공유해서 사용하도록 하는 것도 생각보다 쉽지 않음을 느꼈다. 개발적인 부분에서도 마찬가지이지만, 특정 컴포넌트가 퍼블리쉬되고, 브레이크 체인지가 생길 때 등 이런 영역들을 다른 개발자분들과 소통하는 것이 쉽지는 않았던 것 같다. 내가 기여한 영역은 아주 작고 단단한 영역의 컴포넌트들이었는데, 생각보다 많은 곳에서 잘 사용되었고, 개발자분들도 DX적으로 꽤 만족해하셔서 다행이었다. 물론 좀 더 복합적인 컴포넌트 구현체에 대한 고민을 하지 못했던 부분은 여전히 아쉽고, 처음부터 완벽하게 만들려는 욕심이 화를 불렀다고 생각한다. 당연하지만 말이지만, 이번 기회를 경험 삼아 다음에 기회가 생긴다면 만든다면 더 잘 만들어보기로.
새로운 언어, Rescript를 접했다
Rescript(이하 리스크립트)라는 언어에 접했다. 물론 처음에는 쉽지 않았다.
- TS에 비해 적은 레퍼런스와 좁은 생태계
Option
에 대한 처리를 어떻게 해야 하는지에 대한 고민- JIT 컴파일러의 최적화를 위해 설계된 여러 타입들(
array
list
tuple
/Record
Object
)을 어떤 상황에 적절히 설계하여야 하는지에 대한 고민 - (타입스크립트와 비교하고 싶진 않지만..) 비교적 컴파일 전 후의 코드가 비슷한 TS와 달리, 간혹 런타임과 다르게 코드를 작성해야하는 케이스들
- 항상 immutable한 데이터가 보장되는 언어에서 간혹 불변성이 보장되지 않는 케이스들(특히 DOM을 다룬다거나 하는 경우)을 다루어야 할 때 생기는 문제들
초기에는 위의 문제들이 꽤나 개발과정에 있어 괴롭힘을 당했는데, 특히 복잡한 영역을 머릿속으로 디버깅을 하며 코드를 작성하거나, 컴파일된 JS를 확인하면서 코드를 작성해야했다. 그럼에도 불구하고 “힌들리-밀너 기반의 타입 추론으로 명확히 추론해주는 강타입 언어”라는 장점, 그리고 직관적인 타입 작성 문법은 타입을 이해하는데 쏟는 시간의 비약적으로 줄여주어서, 지금은 언어에 대한 만족감은 꽤나 높다.
물론 초기 장벽과 달리 언어에 꽤나 익숙해지면서 느낀 단점도 있다. 자바스크립트 생태계에서는 외부 라이브러리에 대한 의존이 매우 큰데, 외부 라이브러리를 사용하기 위해 리스크립트로 호환시키기 위한 작업이 필요할 수 밖에 없다. 이를 내부적으로 “바인딩”이라는 표현하는데, 라이브러리를 바인딩하다보면 타입스크립트의 특징인 Structural Type System
을 리스크립트의 Nominal Type
으로 바꾸는 경험은 그렇게 좋지만은 않았다. 다만, 바인딩을 하면서 TS의 멀티타입과 같은 영역을 완전히 새로운 인터페이스로 정의하면서 사용하는 방법들을 고려할 수 있는데, 타입을 정의하는 바인딩의 영역에서 벗어나 새로운 라이브러리를 창조한다는 시야로도 바라볼 수 있다. (예를 들어 이런 케이스)
좋은조직을 알아가기
21년 회고록에 남겼듯이, 좋은 조직이란 무엇인가에 대한 답이 궁금했는데, 큰 조직에서 일할 수 있게 되면서 여러 시행착오를 많이 겪을 수 있었다. 조직이 크다 보니, 역할에 따른 조직이 세분화되어있고, 그러다 보니 개인이 전문적인 기술을 가진 영역에서 일하는 공간이 만들어졌다. 그러다 보니 뛰어난 역량이 발휘될 수밖에 없었던 환경이었고, 조직 내부에 계신 분들 모두가 자신의 영역에서 매우 출중하고 훌륭한 사람들이 모여있다고 느꼈다.
그렇지만 “스쿼드 조직이 유연하게 대처하기에 정말 좋은 조직구조인가?”라는 질문에는 명쾌한 답을 내놓지 못할 것 같다. 팀은 스쿼드단위로 활동하되, 디자인시스템과 같은 TF의 목적 조직으로도 활동하긴 했으나, 회사 문화에 따라서 다르게 느껴지는 영역 때문인지, 내가 생각했던 원하던 구조는 아니었던 것 같다. 오히려 이전에 경험했던 작은 조직이 좀 더 빠르게 움직일 수 있고, 개개인의 의사 결정 권한이 큰 영역이 나에게는 더 잘 맞았던 것 같기도 하다. 무엇보다 큰 조직에서는 개인의 의사결정 영역이 줄어들기 때문에, 새로운 의견을 내더라도 조직 내 많은 사람들의 상황과 의견을 고려할 수 밖에 없었고, 그 의견이 결과로 도출되기보단 오히려 의견의 수준에서 멈추게 되는 부분이 많았다. 그런 상황이 반복되면 사람이 소극적이게되고, 자연스레 내가 이해할 수 없는 프로덕트가 만들어지기도 하고, 결국 개발자로서 프로덕트에 대한 애정도 많이 떨어지게 된다고 생각한다. 물론 내가 좀 더 적극적으로 밀어붙였다면 많이 달라졌을까 하는 고민도 했지만, 큰 조직에서는 내가 모난돌이 될 것 같다는 생각이 사람을 소극적으로 만들 수 밖에 없었던 것 같다.
“좋은 조직이란 무엇인가”에 대해 질문에 대한 답은 여전히 답을 찾지 못했지만, 계속 찾아보기로.
그외에..
GraphQL
과Relay
를 현업에서 처음 사용해보았다. 개발 경험이 정말 좋다. 특히 릴레이를 사용할 때 마다 최고의 DX에 감탄하곤 한다. 릴레이는 앞으로도 계속 사용하고 싶을 정도로 정말 좋은 라이브러리이다. 그렇지만UI Driven development
vsData Driven development
에 대한 결정은 늘 어렵다.- 친구들에게 코딩을 알려주었다. 이전에 코드리뷰어로 활동했던 경험과는 사뭇 다르게 느껴졌는데, 생각보다 좋은 결과가 있어서 만족스럽다.
- 운동을 정말 열심히 다니게 되었다. 꾸준함의 결실이 있으면 좋겠다.
23년에는..
- 블로그를 많이 소홀히 해서 아쉽다. 노션에는 블로그에 게시하기 위해 작성 중인 글이 많은데, 다듬지 못해서 올리지 못한 글이 많다. 마저 다듬어서 꼭 게시해야겠다는 다짐을 해본다.
- 내가 더 좋아하는 취미를 찾기 위해 노력할 예정이다. 같은 팀으로 일하면서, 좋아하는 일을 찾아 다양한 활동을 즐기는 분이 계셨는데, 인생을 즐기는 모습이 멋있으셨고 본받고 싶었다. 나에게도 운동이라는 새로운 취미가 생겼지만, 올해는 새로운 취미를 하나 이상 만들어 보기를 목표로 삼아 본다.
22년에도 여전히 워커홀릭의 삶을 살았던 것 같은 아쉬움을 뒤로하고, 23년에는 재미있고 좋은 일들만 가득하기를.