2021.06 회고록 (이직 1개월차)

입사한 지 한 달, 이제 업무에 대해 이해하고 기본적으로 사용하는 아키텍처와 소스 코드 의도에 대해 파악이 된 것 같다. 친절하고 실력있는 동료들과 협업을 하며 내 능력치를 끌어올릴 수 있는 기회를 얻게 됐다는 것에 뿌듯했다.

온보딩을 하며 내가 가장 신경썼던 부분은 최대한 빠르게 업무에 적응하여 우리 팀의 업무를 분담하고 능력치를 키우며 적응하는 것이었다.
이를 위해, 나는 나름의 전략을 사용하여 적응하려고 노력했다.

1. '단순적용'이 아닌 '고민 후 적용' 
2. 청소라도해서 팀에 기여하자 (진짜 청소말고...)
3. 시행착오는 나 하나로 종결

내가 사용했던 전략(?)들 덕분에 도움이 됐던 것과 아쉬웠던 부분을 정리하고 회고하려 한다.

1. '단순적용'이 아닌 '고민 후 적용'

-> 온보딩 과제를 이해하고, 단순하게 구현하는 것이 아니라 왜 이 구조를 적용하고 어떻게 사용하는지, 회사에서 사용하는 프로덕트와 비슷하게 만들기 위해 고민하며 과제를 진행했다.(구조가 가진 장점과 단점도 자연스럽게 느낄 수 있었음)
회사에서는 MvRx architecture를 사용하여 프로젝트를 구성했고, 오래된 프로젝트는 Rx를, 비교적 최근 프로젝트는 코루틴을 비동기 처리에 사용하고 있었다. 나는 효과적인 업무를 하기 위해 상대적으로 약한 Rx 적용에 대해 고민하는 시간을 길게 가졌고, MvRx를 원활하게 사용하기 위해 근본적으로 구조가 나온 목적을 이해하려고 노력했다.

TL님 Tip이 있었다

• 비슷한 구조를 이해하면서 공부하면 도움이 될 수 있다. ex) MVI
• 한 번에 다 적용하려면 어렵다. 나눠서 공부하면 도움이 된다.
  ex) Clean Architecture, Dagger2 등

이 과정을 통해 MvRx는 MVVM이나 MVP와는 다른 장점과 단점을 파악할 수 있었다.

장점

-> 상태관리를 통한 애플리케이션 컨트롤

: 상태를 관리한다는 개념을 써본 사람과 안써본사람이 느끼는 차이가 클 것이라 생각한다. 기존에 MVVM이나 MVP로 개발해왔던 사람에게는 조금 추상적인 개념일 수 있다. 상태를 일괄적으로 처리할 수 있도록 지정해두고 상태의 변경점을 view에서 구독하며 화면에 출력 또는 로직을 수행하는 개념이다. 이 방법으로 개발자는 '화면의 IO'와 '상태의 변경'에 집중할 수 있고, 협업하는 동료들이 어떤 의도로 코드를 작성했는 지 쉽게 파악이 가능하다.(구조를 이해하는 개발자에 한하여..)
의도치 않은 상황과 사이드이펙트(side effect)를 최대한 억제할 수 있는 구조라는 생각이 들었다.

단점

-> 어느 정도의 진입장벽과 테스트(Unit, UI) 어려움

: MVVM, MVP만 사용했던 개발자들이 바로 도입할 때 어려움이 조금 있을 것이라 생각된다. MVP는 View에서 Presenter로, Presenter에서 View로 메서드를 호출하며 직관적으로 이해하기 좋았던 것 같다. MVVM의 경우 ViewModel의 데이터를 라이브데이터로 생성하고 구독하는 개념에서 살짝 더 이해가 어려웠던 것 같다.
여기서 MvRx는 상태를 컨트롤하고 구독하는 과정에서 한 단계 거시적으로 구조를 잡은 것처럼 느껴졌다. 그리고 상태를 컨트롤한다는게 말은 쉽지만 막상 코드로 접했을 때 이렇게 하면 되는건가?라는 의문을 계속해서 갖게 하는 과정이 있었다.

테스트에 대해 생각해보면 MVP가 MVVM보다 직관적인 호출 형태를 취하기 때문에 테스트를 작성하기에 상대적으로 더 쉬운 구조라 생각한다. 여기서 한 단계 더 추상적인 MvRx는 어떻게 테스트해야할지 아직 감이 잡히지 않는다. 또한 레퍼런스도 다른 아키텍처에 비해 부족하고 적용이 어렵다.
(잘하는 사람의 테스트를 보고 따라가면 좋겠지만 아직 프로덕트에 테스트가 도입되지 않아 아쉬웠다ㅜㅜ 다니면서 내가 도전해본다!!!)

그냥 단순 코드 구현이 아니라 고민과 함께 했기에 구조를 적용하며 느꼈던 것들이 더 기억에 오래 남고 내 것으로 남는 느낌을 받았다. 아쉬운 점이 있다면 너무 깊은 고민과 이해가 안될 때 뇌정지로 인한 더딘 진행... 퍼포먼스가 내 욕심보다는 안나왔던 것 같다. 좋은 팀원들이 급하게 생각하지 말고 천천히 하라고 잘하고 있다고 해주는 것으로 큰 힘이 되었고, 이런 동료들이 있다는 것에 감사했다ㅜㅜ
앞으로도 '고민 후 적용'하며 내 성장에 집중하려고 한다. 그리고 나의 성장으로 또 회사에 기여하며 긍정적인 피드백을 계속해서 만들어내고 싶다.

* MvRx에 대해서는 개인적인 공부와 실험들을 가지고 다시 정리해서 따로 글을 올릴 예정이다.(대단한거 아니고 내 공부용으로!)

2. 청소라도해서 팀에 기여하자 (진짜 청소말고...)

-> 작고 번거로운 업무라도 적극적으로 맡아 처리하면서 기여할 수 있는 부분을 최대한 찾으려고 노력했다.(3rd party 서비스 종료로 인한 프로덕트 수정)
: '배달통'서비스 종료로 프로덕트에 흩어져있는 관련 소스들을 정리해야하는 이슈가 있었다. 프로덕트 내에 있는 소스를 확인해보고 내가 할 수 있는 수준의 업무라는 생각을 하게 되었다. 먼저 이 이슈에 대해 언급하며 업무를 맡아 처리했다.

사소하고 귀찮은 업무지만, 아직 미숙하게 적응하고 있는 내가 할 수 있는 일이라면 먼저 맡아서 처리하려고 노력했다. 이러한 과정을 통해 나는 노력으로 조금씩이나마 업무에 기여 할 수 있게되었다.

처음에 미숙하여 어떤 부분에 있어서 다른 팀원들보다 일을 덜 하는 경우가 생길 수 있다. 그러나 그것을 당연하게 생각하기보다는 미숙한만큼 다른 노력으로라도 채우기위한 노력이 있다면 좋을 것 같았다. 내가 일할 때 이런 생각을 하는 새로운 팀원이 있다면 반가울 것 같았고, 내가 먼저 그런 사람이 되고 싶었다.

3. 시행착오는 나 하나로 종결

-> 업무처리 중 동료들의 기억이 가물가물한 처리, 다른 팀에 요청했던 과정을 위키에 문서로 남겨 다른 사람의 시행착오를 줄이기 위해 노력했다.
: 당연한 이야기지만 시행착오는 적을수록 좋다. 물론 시행착오를 통해 더 깊은 지식을 습득하는 경우도 있지만(CS한정이라 생각됨) 회사 시스템 특성에 따른 시행착오는 최대한 줄여나가는 것이 생산성 향상과 쓸데없는 비용을 줄이는 데 효과적이라 생각한다.
그럼 이런 시행착오를 줄이는 것에 기여할 수 있는 방법이 있다면? 해야지!
크고 대단한 시행착오를 줄일 수 있으면 더 좋겠지만 작은 것이라도 시행착오를 줄이기 위해 문서화하여 처리하려 했다.

내가 했던 시행착오를 똑같이 하는 상황을 없애려는 노력은 앞으로도 계속해서 좋은 습관으로 남기고 싶다.

아쉬웠던 것

말한 전략들을 모두 완벽하게 해냈으면 좋았겠지만 아주아주 미약하게 적용한 것 같다. 하지만 생각하지 않고 업무에 임했으면 그 미약함마저 없지 않았을까...?
다만 업무적응과 회사적응이라는 합리적인? 변명으로 계속해오던 공부와 사이드 프로젝트를 내려놓았던 것이 아쉽다. 분명 할 수 있는 시간들이 많이 있었는데 더욱 격렬하게 밍기적거리고 싶었다. 이 밍기적거림이 습관이 되지 않게 다시 정신차려야지..