# Overview # 첫 취업 싸피 1학기를 수료하고 2학기 프로젝트를 시작하기 전에 취업을 했다 싸피 2학기도 좋은 경험이겠지만 실무에 뛰어들고 싶다는 마음이 더 컸다
회사 생활은 만족스러웠다 내가 생각했던 것보다 권한이 많이 주어져서 자율적으로 일할 수 있었다 무엇보다 제품 개발에 빠르게 투입될 수 있었던 점이 좋았다 온보딩 기간을 거치고 바로 메이저 버전 개발을 들어갔다 메인 기능 중 하나를 맡아서 개발을 한 덕에 빠르게 실력이 늘 수 있었다
온보딩 기간 동안 레거시 코드를 어떻게 개선할지, 어떤 기술을 적용해볼 수 있을지 생각해봤다 이 기간 동안 프로젝트에 대한 이해는 크게 늘지 않았다 공자가 들으면 잊어버리고 보면 기억하고 직접 하면 이해한다고 한 것처럼 직접 개발을 할 때 프로젝트에 대한 이해가 크게 늘었다 # 프로젝트 기여 ## Redux, Redux Saga를 TS로 포팅 컴포넌트 쪽은 TS가 적용되어 있었지만 Redux와 Redux Saga는 그렇지 않았다 복잡한 로직은 Redux와 Saga 쪽에 있는데 JS로 되어 있어서 코드를 파악하기 어려웠다(TS는 종종 주석을 대체한다) 또한 런타임 전에 알 수 있는 오류를 런타임에 가서 아는 경우가 잦았다 이런 문제들을 해결하기 위해서 Redux와 Saga를 TS로 포팅했다
프로젝트적으로 봤을 때 프로젝트의 안정성을 높였다는 점에서 의미가 컸다고 생각한다 개인적으로도 이 작업을 하면서 TS에 대한 이해도가 높아졌다 JS 코드베이스를 TS로 변경하는 작업에 노하우도 생겼다 JSDoc과 타입 정의(d.ts)를 잘 사용하면 점진적으로 TS로 변경하는 건 그리 어렵지 않았다
문제는 이 과정에서 잘못된 타입이 지정될 수 있다는 거다 객체의 키를 `number`로 쓰기도 하고 `string`으로 쓰기도 하는 등 문제가 발생했는데 이것도 하나의 글을 쓸 만큼 중요한 주제다 ## 순환참조 해결 리액트 프로젝트를 하면서 순환참조를 생각해 본 적은 한번도 없었다 애초에 다른 모듈을 사용할 때 순환참조인지 아닌지를 고려하지도 않았다 그런데 이번에 순환참조로 인해 문제가 발생했다
개발을 진행하다 보면 Jest나 Storybook이 망가지는 경우가 있었다 당시엔 망가지는 이유를 몰라서 그냥 문제가 되는 커밋을 revert 하는 선에서 해결했었다 나중에 시간을 들여서 확인해보니 Jest를 돌릴 때 특정 위치에서 특정 모듈을 import하면 OOM이 발생한다는 걸 알게 됐다 해당 모듈은 내부에서 순환참조가 많이 일어나고 있었다 순환참조가 개발환경에 악영향을 주고 있었다
그래서 개발기간이 끝난 후 순환참조를 모두 제거하는 작업을 했다 자동으로 순환참조를 해결해주는 툴이 있지 않을까 해서 찾아봤지만 찾을 수 없었다 직접 하나씩 제거해야만 했다 몇 백 개의 import 경로를 다 수정하다 보니 진저리가 났다 만약 새로운 프로젝트를 하게 된다면 순환참조 방지는 꼭 해야겠다고 다짐했다 # 오픈소스 기여 올해는 두 가지 오픈소스에 기여를 했다 하나는 npyjs이고 다른 하나는 underscore.js다 - **npyjs** npyjs는 백엔드에서 보낸 python numpy 자료형을 JS로 파싱하는 라이브러리다 npyjs는 가벼우면서 잘 작동했는데 타입 정의가 없었다 그래서 타입 추론이 잘 되도록 타입 정의를 만들어서 기여했다 - **underscore.js** underscore는 JS utility 라이브러리다 underscore의 get 함수를 쓸 일이 있었는데 타입이 JS 동작과 달랐다 타입에선 두 번째 인자로 `Array`을 줄 수 있었는데 실제로는 `Array`였다 올바른 타입으로 고쳐서 DefinitelyTyped에 기여했다
오픈소스 기여를 TS로 해보니 왜 TS가 강력한지 알게 되었다 JS 코드를 수정하지 않고 타입을 추가할 수 있다는 게 TS의 큰 장점이었다
그러나 이런 장점이 단점이 되기도 한다 underscore처럼 기능과 타입이 다른 경우가 생긴다 특히 underscore는 기능 저장소와 타입 저장소가 분리되어 있어서 서로 맞추기가 힘들다
이런 경험을 하고 나니 라이브러리를 고를 때 TS로 되어 있는지를 꼭 보게 됐다 # 함수형 프로그래밍 함수형 프로그래밍(FP)에 다시 도전했다 FP는 학부에서도 몇 번 도전했다가 포기하곤 했었다 당시에는 하나의 프로젝트를 오래 관리할 일이 없다 보니 좋은 코드에 대한 고민을 할 기회가 많지 않았다
무엇보다 FP 생태계가 그다지 친절하지 않았다 3년 전만 해도 윈도우에서 하스켈을 설치하는 건 고문이었다 그런데 이제는 그렇지 않다 [GHCup](https://www.haskell.org/ghcup/)을 이용하면 별다른 설정 없이 VSCode에서 하스켈 코드를 짤 수 있게 됐다 개발환경이 쉽게 구축되니 코드에 집중할 수 있었다
하스켈을 공부를 하다 보니 이걸 왜 좋다고 하는지는 알겠는데 과연 이걸 회사 프로젝트에 적용할 수 있을까 하면 회의적이었다 예를 들어 TS는 언어 차원에서 사이드 이펙트를 막지 않기 때문에 IO 모나드를 써야할 이유가 없다
이런저런 고민을 하면서 잠시 하스켈을 내려놓았다가 최근에 아이디어가 떠올랐다 nullish value(undefined와 null)를 참조할 때 Maybe 모나드와 Either 모나드는 써볼 수 있지 않을까? 이 둘은 개념이 그렇게 어렵지 않아서 다른 사람에게 소개하기도 좋고 해결하는 문제도 명확하다 이것도 시간을 내서 정리해 봐야겠다 # 마치며 보람찼고 재미있는 한 해였다 아직 풀어야 할 문제가 많아서 지루하지 않다
다만 내년에는 건강을 챙겨야 할 것 같다 개발은 스프린트가 아니라 마라톤이기 때문에

회고

2023년 회고