# 히스토리를 모른다는 것

매일 수정하는 GNOSS LV5·2023년 1월 10일
1

On my way

목록 보기
1/1

히스토리맨

이직한지 얼마 되지 않아 바로 프로젝트에 들어가게 되었다.
기존의 1년 넘게 다닌 회사에서는 프로젝트의 시작점에 입사하게 되었었고 혼자서 개발을 진행하면서 내가 하고싶은대로 프로젝트를 진행했었다.

프로젝트 빌드부터 배포까지 진행하면서 모든 파일들과 설정을 내가 진행하였고 추후에 다른 분들이 합류하셔서 함께 일을 함에도 모든 회의에 참여하며 진행을 했었다.

그때 여러 직군에 계신분들도 그렇고 함께 개발하는 개발자분들도 그렇고 내가 이 프로젝트의 히스토리라고 하시면서 장난스레 부른 경험이 생각이 난다.
그때 당시에는 이게 어떻게 나에게 영향을 주고 있는지 몰랐었다.
다른 코드를 보기 전까지는…

11월부터..

새로운 회사에 입사하게 되었다. 어느정도 규모가 큰 회사에 입사한 경험이 처음이라 정신이 없었다.
체계적인 온보딩, 필수 교육시스템들, 이전의 프로젝트와 내가 하던 토이프로젝트와는 비교할 수 없을만큼 큰 사이즈의 프로젝트가 기다리고 있었다.

다른 큰 기업에 다니는 주변사람들의 이야기를 들었을 때는 한달정도는 코드를 보면서 파악하고 회사의 분위기를 읽는 시간이 주어진다고 했었다. 그리고 실제로 입사후 당분간은 내가 회사를 나온건지 커피를 마시러 온건지 모를정도로 계속 커피를 마셨던거 같다 ㅎㅎ
기본적으로는 코드를 보면서 회사에 적응을 시켜주기 위해서 많은 분들이 먼저 오셔서 말을 걸어주셨고 천천히 회사의 분위기에 익숙해져가곤 했다.

하지만 기존에 스타트업에 종사하기도 했었고 성격상 일이 주어지지 않으면 내가 잘 나아가고 있는지에 대해 불안함을 계속 느끼는 성격이라서 마음이 평온하지는 못했었던것 같다.
그래서 뭐라도 할 일이 없을까? 하고 여기저기 둘러보면서 회사 내부의 망을 둘러보기도 하고 코드를 보면서 이해하려고 노력했었던것같다.
차라리 프로젝트가 주어졌으면 좋겠다… 하고 생각을 했다. 하지말걸…

12월부터..(11.5월부터..?)

안드로이드 팀은 상대적으로 인원이 부족했고, iOS에 비해 싱크가 떨어져있었다. 그래서 생각보다 빠르게 프로젝트에 투입되게 되었다. 처음에는 간단한 버그를 수정하는 일부터 시작했다. 이전의 프로젝트였다면 … 1시간정도 걸릴것 같은? 아주 짧은 버그였다.
이슈를 보자마자 대충 어떤 문제일지 생각이 났고 경험들을 통해서 이렇게 바꾸면 되겠다 하고 프로젝트를 여는 순간 공통의 늪에 빠지게 되었다.

Utils함수를 변경하는부분이였는데 프로젝트 전반에 사용하고 있었기 때문에 내부를 함부로 바꿀 수 없었다. 또한 파고파고 들어가도 계속해서 함수들끼리 엮여있었는데 로그를 찍다가 중간에는 디버깅을 켰던것같다.
그리고 코틀린으로만 개발을 진행하다가 자바 코드를 오랜만에 만나게 되었는데 ㅎㅎㅎㅎ… 많이 어색했다. 수줍게 인사하고 다시 파악하려고 하는데 어찌나 무언가가 이상하던지…

아무튼 받자마자 수정을 하고 올릴까? 하다가 겨우 이 한두줄이 나에게 바란것일까 라는 생각을 갖게 되었다.
그래서 시작했다. 수정을.

일단 자바코드에서 코틀린으로 변환하고 공통으로 사용할수 있게끔 세팅을 시작했다.
한두줄짜리 일을 Class째로 바꾸는 작업으로 ~
그렇게 혼자서 일을 키웠는데 History에 대한 중요성과 주변 신규 입사자들로부터 용감하다라는 평가를 받았던것 같다. 그때는 이거 하나 바꾼게 왜 그럴일이지? 라고 생각했지만 지금 생각해보니 사이드이펙트걱정을 한건지 안한건지 모르고 용감하기 짝이 없었다. ㅋㅋ 덕분에 프로젝트에 대해서 구경을 열심히 했던것 같다.

그렇게 큰 일은 아니였지만 빌드할때마다 생기는 사이드이펙트들을 경험하면서 즐겁게 했었던것 같다.
이또한 큰 프로젝트를 받기 전까지는..

12월부터…

이제보니 쉽지 않았다. 지난 2달.
이번에는 프로젝트를 진행하게 되었다. 목적 조직이라고 해야할까? 프로젝트를 위해서 잠시 한개의 팀이 만들어지고 각자의 직무에 맞추어서 일을 진행했다. 이전의 회사에서는 원하는 것이 있으면 담당자에게 바로 연락을 했겠지만 새로운 회사에서는 모든것이 처음이니 조심스럽게 진행했다. 두번씩 팀장님께 확인받아가면서 진행을 했다.

소통이야 사람을 대하는 일이 다 비슷하다고 생각하기에 어렵지 않았지만 어려웠던건 역시 개발이였다.
기존 화면에 대한 개선이였는데 기존 화면의 코드가 오래되어서 수정하고 싶다는 생각을 하고 있었다.

그래서 주어진 시간의 첫주는 기존 코드를 파악하고 최소한으로 변경하여 어느정도 기능을 완성하려 하였으나 interface가 많이 바뀌면서 다시 작성해야겠다는 생각을 했고 고민이 시작되었다.
기존 코드의 구조가 낯설기도 하였고 내심 속으로는 이렇게 하지 말고 다르게 바꾸면 어떨까 라는 생각을 갖고있었다.

또한 내가 여기에서 기존 코드를 조금씩 수정한다면 스스로도 우물안 개구리가 될것 같았던 느낌을 받았던것 같다.(정확하게는 친구가 옆에서 잊고있었던 나의 도전의식에 불을 붙이긴 했다.)
그래서? 했다. 처음에는 네트워크 모듈까지 건드려가면서 수정을 시도했다. Rx + livedata로 되어있던걸 Coroutine과 Flow로 변경하려고 얼마나 끙끙댔는지 모르겠다.
거의다 변경했지만 변경하던 도중 di가 문제가 생겼다. Dagger를 사용하는 현 프로젝트와 Hilt만 사용해봤던 내가 충돌한거다.
1 : 1 이라면 수정하겠는데 Rx + livedata + dagger → Coroutine + flow + hilt로 변경하려니 도저히 프로젝트 기간내에 시간이 될것같지 않았고 추후에 진행할 작업으로 메모해놓고 다시 처음부터 시작해야했다.

그렇게 구조를 변경하고 완료했다고 느낄정도로 개발을 진행해서 마무리를 지었다.
그리고 QA분들과 배포 약속전에 팀 내부적으로 코드리뷰를 진행했고 어느정도 정리를 했던것같다.
이제 대망의 약속 전 마지막 2일에 미리 룰루랄라 🎵 올려야지~

는 개뿔. 아뿔싸다.

1월부터..

정초부터 큰일났다. 난생 처음 정동진에가서 올 한해 무사하게 보내게 해달라고 빌기까지했는데..

코드리뷰하면서 개발자분들이 봐주시던거 외적으로 문제가 발생했다. 기존에 앱 전반적으로 사용하고 있었던 로직이 있었는데 그부분을 모두가 놓친것이였다. 마지막날에 발견을 해버려서 내가 낯설어 하던 구조가 왜 있었는지에 대해서 설명을 듣고 깨닫게 되었다. 역시 모든 코드에는 이유가 있고 그렇게 만들수 밖에 없었던 히스토리가 있다라는 개발 격언을 몸소 깨닫는 순간이였다.

그리고 나에게 남은시간은 없었다.
부랴부랴 프로젝트팀에 메일을 보내고 일주일의 시간을 받아 최대한 빠르게 개발을 진행하였다.
UI구조적인 문제라서 네트워크 비즈니스로직에 대한 부분은 다시 구성할 필요는 없었지만 모델링을 새롭게하고 UI를 새롭게 짜다보니 비교 → 수정 → 오류 해결 → 로직추가 → 비교 → 수정 … 의 무한 반복을 시작했다.
결론은 모두가 도와준 덕분에 4일만에 끝이났고 나는 야근몬이 되면서 언제 우리 회사의 서버가 붙고 떨어지는지 알게되었다 ^^….알기 싫었는데

파란만장한 입사후기가 끝나고 나서 몇가지 깨달음을 얻었다.

  1. 히스토리에는 이유가 있다.
    1. 그 사람들은 나같은 생각을 안하거나 못한게 아니다. 이유가 있다.
    2. 지금 내가 짠 코드도 언젠가는 히스토리가 될것이다. 커밋이든 뭐든 최대한 흔적을 남겨놓자.
  2. 공통 모듈의 중요성
    1. 프로젝트가 이렇게 큰데 언제 하나하나 따로 만들거냐? 대부분이 공통으로 되어있었고 히스토리를 모르는 만큼 내가 수정한 부분이 어디에 영향을 미치는지 눈으로 직접 확인을 해야만 한다.
      그렇지 않으면 내가 개발하지 않은 이상한 구석에서 터질수 있기 때문에 항상 조심해야한다.
    2. 무언가를 새로 생성할때에는 이 모든부분에 대해서 고려를 해야한다. 다음에 십중팔구 다시 재사용할 것이기 때문이다.
  3. 갓-팀원
    1. 정말 감사합니다.
    2. 죽을뻔했는데 살려주셔서 감사합니다.
    3. 그리고 저도 언젠가는 도움이 되겠습니다.
profile
러닝커브를 따라서 등반중입니다.

0개의 댓글