2023 겨울 돌아보기

 

이미 2월은 한 달도 전에 끝났지만, 늦게라도 회고를 올린다.

1년 단위로 회고를 하려니까 뭔가 사건은 많았는데 추적하기 버거운 양이라서 앞으로는 분기마다 1번씩은 회고하려고 한다.

 

직장: 기술

작년 11월, 3.0.0 버전 메이저 업데이트 이후에 겨울 동안은 규모가 큰 작업을 하지는 않았다. 그래도 좀 중요한 작업을 꼽자면…

• 12월에 ReactorKit, Realm 사내 세미나를 진행했다.
• 테스트 코드를 아주 일부 도입했다.
• 세미나로 추진력을 얻어 1월에는 회원가입 마케팅 동의 페이지에 ReactorKit을 최초로 도입했다. ReactorKit은 프로젝트 일부에만 도입할 수 있다는 장점이 있어 좋다.
• 앱 내 다운로드된 클립 파일이나 캐시 등을 전부 삭제할 수 있는 기능을 만들었다. 앱 내 샌드박스의 /documents, /tmp, /library 디렉터리에 어떤 것들이 저장되는지 알 수 있었다.
• 플레이어, 전자책 동시이용 서비스를 지원했다. TTS를 이용할 때는 플레이어를 날려버려야 해서 MPRemoteCommand와 MPNowPlayingCenter를 조작해야 했다. 더 잘 알게 된 계기가 됐다고 생각한다.
• 겨울 막바지에 privacy manifest 도입이 필요하다는 것을 깨닫고 팀에 공유한 뒤 업데이트 필요한 패키지들을 리스트업했다. WWDC는 미리미리 챙겨봐야 한다.
• 중첩 콜렉션뷰에서 재사용을 제대로 하지 못하고 있는 이슈 라이징이 있었다. 해결은 했지만, 여전히 중첩 콜렉션뷰에 대한 의문이 남아 있다.
• 페이지 전환 애니메이션 작업을 지원했다. 스크롤뷰와 CAAffineTransform에 대해 잘 알 수 있는 계기가 됐다.

 

직장: 사람

• 2월 막바지에 우리 팀에 웹개발자 한 분이 새로 들어오셨다. 작년 8월에 웹개발자 분이 입사하셨을 때는 사수도 없고 어려운 상황이었어서 개발, 기획, 디자인팀과 한 번씩 식사를 주선해드리며 정서적으로 정착하실 수 있도록 도움을 드렸다.
• 이번에는 그렇게까지 할 건 없었다. 8월에 이미 오신 분께서 잘 도와주신다. 웹과 협업할 일이 아주 많지는 않지만, 요즘은 그냥 가끔 식사 같이 하고 어려운 건 없는지 한 번씩 가볍게 여쭤보고 있다.
• 결국 혼자 일하는 게 아니다 보니 사람이 중요함을 느껴서 살뜰하게는 아니더라도 넘 매정하지 않게 챙기려고 한다.

 

직장: 어떤 것이 가장 좋은 것인가?

• 개발자는 언제나 좋은 코드를 위해 노력해야 하는가? 물론 그렇다.
• 그런데 스타트업 1년을 다니고 돌아보니 개발자도 결국 직장인이다. 피고용인은 고용된 회사의 이익을 위해 일정 시간 동안 일하고 그 대가로 급여를 받는다.
• 기술 부채가 심각한 경우에는 이를 위한 일정을 따로 내는 것이 필요하지만 그럴 시간을 낼 수 없는 경우에는 코드 베이스의 상태가 더 나빠지지 않도록, 협업 일정을 우선으로 해서 이익을 낼 수 있도록 최선을 다해야 한다.
• 이것이 직장인 개발자로서의 개인적인 생각이다.
• 혼자 개발한다면 최신 기술 사용하고 스택도 내 마음대로 구성할 수 있겠지만 회사에선 그럴 수 없다. 어떤 기술을 도입하고자 하면 함께 일하는 동료가 겪을 러닝 커브와 기술을 익히는 데 필요한 시간적인 비용을 생각해야 하고, 사이드 이펙트 및 전환 비용 등을 꼼꼼히 따져본 뒤 신중하게 결정해야 한다.
• 특히 요즘처럼 채용 시장이 어려운 시기에는 무조건 퇴사하기보다는 머무르는 것을 선택하고, 현재 회사에서 이룰 수 있는 것들은 이루고, 공부하고, 대화하고, 설득하고, 또 설득당하기도 하며 다음 스텝을 준비해야 한다고 생각한다.
• 결론은… 참선하자.

 

해결해야 할 것들

• 모듈화의 필요성을 느낀다. 우리 프로젝트의 경우 모듈 간 커플링이 강한 것들이 좀 많고, 어느 화면에서든지 이용할 수 있는 싱글턴 서비스가 있다. 어떻게 모듈화할지 좀 고민하는 중이다.
• 결국 모듈화하려는 건 타겟을 나눠 빌드할 수 있는 방법 찾기의 일환이다. 현재 우리 앱은 모놀리스로 구성되어 있고, 작은 기능 하나만 고쳐도 전체 앱을 다 빌드해서 시간이 오래 걸린다. 이 부분을 꼭 해결하고 싶다.

 

 

잡담

• 실무에 ReactorKit을 도입하기로 한 뒤부터 뒷탈이 없도록 열심히 공부해갔다. 그러다 보니 오히려 사이드 프로젝트에 적용할 때보다 더 빨리 성장한 것 같다. ㅎㅎ
• 테스트 코드 역시 마찬가지다. 솔직히 테스트 코드를 짤 때 어디부터 어디까지가 테스트 영역인가? 자동화된 UI 테스트는 반드시 필요한가? 그렇다면 범위는 어디인가? 동작을 가능하게 하는 사전 구현은 어디에서 해야 하는가? 테스트 1개는 몇 개의 기능을 검사해야 할까? 많이 해도 될까? 등등… 아직도 여러 가지 의문이 남아 있다.
• 그리고 요즘따라 학교에서 배운 것들… 다 쓸모있었구나 느끼고 있다. 이런 기본적인 것들 어디다 써먹나 했는데 다 쓸모가 있었다. 게다가 너무나 핵심적인 가치들이라 거의 신주단지 뫼시듯이 중요하게 생각해야 하는 것들이었다.
• ‘왜 그래야 하는가?’를 자주 생각하게 된다. “이거 쓰려구요” → “그걸 쓰면 뭐가 좋은데요?” → “이런이런 게 좋아요” → “그 장점이 왜 필요하죠?” → “우리 프로젝트에 이런 문제가 있고…” → “다른 대안도 있는데 굳이 그것을 선택한 이유는?” 등등… 거의 5why급으로 파고들어가서 내 스스로 이유를 잘 설명할 수 있어야 한다고 생각한다.

 

개인사

• 다니던 헬스장을 옮겨서 아침 운동을 다니고 있다. 6시부터 열어서 아침에 운동하고 출근할 수 있는 게 제일 좋다.

 

총평

• 잘했는데 조금 더 잘할 수 있었다.
• 테스트 코드를 도입한 건 좋았지만 좀 더 정교한 테스트 코드를 위해 심화 응용이 필요하다. 테스트 코드만을 위해 공부하기보다는 기존 사이드 프로젝트에 적용하는 것을 목표로 테스트하며 배워야할 것 같다.
• 모듈화의 꿈은 빨리 이룰 수 있도록 일정 조정이 필요하다.
• Structured 결제했으니까 시간 조정 잘 해서 유익하게 사용해야겠다...

 

2024 봄 목표

• 최근 사이드 프로젝트에 합류하게 됐는데, 일과 사이드 프로젝트 모두 잘 진행하고 싶다. 사이드 프로젝트에는 ReactorKit과 더불어 FlexLayout, PinLayout을 도입하고 Tuist도 살짝 경험해볼 예정이다.
• 테스트 코드를 짜다가 한계에 부딪혀서, 좀 더 꼼꼼히 자료를 수집한 다음 다시 정밀한 테스트를 위해 노력할 예정이다. 일단 XCTest부터 잘 써야 한다.
• 모듈러 아키텍처에 관심을 두고 있는데 정확히 어떻게 시도해야 하고, 레거시를 모듈러로 바꾸려면 어떤 것부터 해야 하는지 모호한 상태이다. 사례 위주로 찾아보고 적용하려 한다.
• 이제는 SwiftUI로 앱 만들기를 더는 미룰 수 없을 듯하다. 예제 앱을 만들어본 다음 Combine을 경험해보고, 최종적으로 TCA까지 경험해 pure SwiftUI와 어떻게 다른지 비교해보려 한다. Flux 패턴을 기반으로 한 ReactorKit 경험이 있으니 TCA가 그렇게 어렵지는 않을 거라고…? 기대한다.