Q3 되어서 적어보는 Q1 회고

몇 년 동안 한 주에 2번 정도 하던 지인들과의 회고 모임이 끝났습니다. 그리고 이번에 이직을 하면서 기록의 중요성을 느꼈어요. 기록이 없으면 그저 생각 속에서 스쳐 지나가버리더라구요. 제가 과거에 무엇을 했는지 얼마나 성장했는지 알고 알릴려면 기록을 해야 겠구나 싶더라구요. 

회사에서 매주 회고 모임을 진행하니 더 이상의 회고 모임 가입은 그만 두고 스스로 포스팅 하며 되돌아보기로 했습니다! (지금 이 시점에도 다른 모임 하나를 추천 받았는데 할까 말까 정말 고민이입니당ㅠㅠ 다른 분야 사람들 만날 수 있는게 흔치 않아서..)

 

생각보다 TMI라 아무도 안 읽었으면 좋겠지만 그래도 누군가가 읽고 피드백 해준다면 행복할 것 같은.. 우선 적어봅니당 .. 🐮

 

---

Q1 (1 ~ 3월)

프로젝트의 연속

작년 22년 6월 부터 시작한 프로젝트가 23년 2월에 끝이 났어요. 끝났습니다. 원래 프로젝트를 시작하고 유지보수까지 담당하게 되는데 회사 내부 사정으로 인해 2월까지 모두 마무리 하기로 했어요. e 커머스 앱이었고 투입인원이 너무 적어 모두 몸이 갈리다 싶이 개발을 했고, 팀원이 몇번이나 바뀌는 고통스러운 프로젝트였습니다. 

 

이 프로젝트 범위가 특정 기능을 제외하고 모든 커머스 기능이 가능해야 했고, 거의 대부분을 네이티브로 개발해야 했으며 커뮤니티 기능이 있어 html 코드로 글을 쓰고 편집까지 가능해야 했습니다.. 

내부적으로 사용하고 있었던 아키텍쳐는 mvc였고 개발 속도랑 러닝 커브가 없다는 점에서 계속 채택해 사용하고 있었어요. 이번 프로젝트는 하나의 화면에서 가능한 화면 전환이 정말 많았고 정말 많았고 정말 많았습니다. 뷰 간의 dependency가 상황마다 달라져서 개발 중간 중간에도 고민이 굉장히 많았습니다. 결국 코드량이 많아진다거나 코드가 읽기 어려워진다는 단점에도 불구하고 화면 전환과 dependency 관리를 위해 mvvmc를 사용했어요. 대부분의 라이브러리는 회사 내부에서 사용하는 라이브러리를 사용해서 개발했습니다. 그러나.. 이것이 발목을 잡을 줄은 몰랐어요. 

 

개발만 잘하는 건 중요하지 않다. 

내부에서 mvc만 사용하다보니 추후에 사람이 부족한 상황에서 mvvmc를 아는 팀원이 없어 추가 인원투입이 불가능하다는 피드백을 들었습니다. 같이 프로젝트를 진행하는 사람끼리 스택 공유가 되면 충분할 것이라 생각했는데 아니었어요. 하나의 기술을 도입하기 위해서는 팀원 모두의 참여와 노력이 필요했었고 이 필요성을 설득시키는 방법 또한 중요했어요. 
팀원의 참여를 끌어내기 위해 이것이 왜 필요한지 설명하는 것, 이를 설명하기 위한 설득과 커뮤니케이션을 배우는 것, 그리고 이를 뒷받침 하기 위해 제가 설득하려 하는 라이브러리, 기술을 잘 알고 있을 필요가 있었어요. 

3월에 CTO와 면담하는 시간에 이 생각을 공유했었어요.

이후에는 제가 사용하고 있는 것, 도입하고 싶은 것에 대해 자료를 만들어서 내부 팀원에게 공유 부터 했는데 실직적으론 도움이 안되었어도 팀원 분들이 이런 것도 있구나 하는 시간이 되었던거 같습니다.

 

산출물의 퀄리티가..

2022년 포함 거의 6개월은 밥먹고 잠자는 시간을 제외하고 코딩만 했었어요. 그렇게 했는데도 그 많은 양을 다 치지 못했고 몇몇 기능을 빼야 했습니다. API가 미뤄지면 한없이 미뤄지고 이로 인해 네이티브에서 정해진 시간을 맞추지 못해서 생기는 힘든 일들이 정말 많았어요. 점점 제가 봐도 산출물의 퀄리티가 엉망이었어요. 코드가 저 자신이라고 생각하다보니 정말 속상했었어요. 

나중에 돌아보니 이를 계기로 배운 것들이 정말 많습니다. 우선 코드는 저마다의 사정이 있다는 것. 기존의 프로젝트 유지보수를 맡게 되거나 이전에 자신이 짜놓은 코드를 보면 왜 이렇게 작성되었지 하는 의문이 생길 때가 있는데 다 이유가 있다는 것입니다. 아무리 부족한 코드라 해도 그 당시의 상황이 여건이 안되었거나 이 코드가 그 상황에서 그 개발자에게 최선이었다는 것. 코드로 개발자를 판단하는 것이 아니라 함께 어떻게 하면 더 나은 코드를 작성해서 개선할 수 있을지에 대한 태도로 바뀌는 경험이었어요. 

 

라이브러리 파헤쳐서 다시 만들기

html 에디터를... 네이티브 코드로 만들고, 다시 불러와서 수정도 할 수 있는 그런 기능이 있었어요. 당시 레퍼런스로 보여주신 것이 네이버 블로그 에디터였는데 정말 눈앞이 캄캄하더라구요 ㅋㅋㅋㅋㅋ

그래서 변경 가능한 오픈 소스를 사용하기로 했습니다. 그런데 개발하면 개발할 수록 기존의 코드 가지고는 기획과 디자이너가 원하는 기능과 디자인을 구현할 수 없더라구요. 결국 일부분을 뜯어 고치고 추가하기로 했습니다. 

이때 html과 js는 웹팀에서 굉장히 많은 도움을 주셨고, 네이티브에서 html 처리는 안드로이드 팀에서 조언을 해주셨어요. 덕분에 자칫하면 오래 걸리고 힘들었을 개발을 아주 재밌게 그것도 원하는 기능으로 구현해 낼 수 있었어요. 

다시 한번 이것이 팀이구나, 나도 다른 팀에 도움이 필요하면 적극적으로 도와야 겠다는 생각이 들었습니다. 다른 분야의 각자가 함께 시너지를 낼 때 각자의 분야를 배우고, 좋은 결과물을 도출해 낼 수 있습니다. 

그리고 첨에는 라이브러리를 수정해서 사용하려 하니 겁이 나기도 했는데 결과물이 만들어지니 재미있더라구요. 가끔 라이브러리 깡(코드를 보겠다는 뜻임)을 해보고 있습니다. 다른 사람 코드 보는게 굉장히 도움이 많이 되는거 같아요.

 

나는 iOS 개발 계속 할거야 

쉴틈없이 코딩만 하다 2월에 프로젝트가 끝나고 나니 갑자기 생각이 많아지더라구요. 전 iOS 개발이 너무 좋아요. 사용자랑 가장 밀접하게 닿아 있고, 특히 iOS의 유려한 UI/UX를 개발할 수 있다는 게 너무 멋진일 같아요. 그런데도 갑자기 의문이 들더라구요. 즐겁게 하던 일이 몸도 마음도 힘들게 하니 iOS를 그만 둘까 했지만 아무리 생각해도 iOS 개발이 좋더라구요. 

3월에는 나는 과연 어떤 개발자가 되고 싶은지, 왜 iOS 개발자여야 하는지 생각하는 시간을 보냈어요. 

제가 처음에 iOS 개발을 시작했을 때 받았던 것 처럼 다른 사람에게 도움이 되는 개발자가 되고 싶고, 앱을 사용할 때 사용자가 와 이 앱 너무 멋지다 예쁘다 사용하기 편리하다라는 앱을 만들고 싶어요. 프로덕트의 아이덴티티를 살려서 기획자와 디자이너의 의도를 충분히 담은 그런 앱을 만들고 있고 만드는 개발자가 되고 싶었습니다. 그리고 무엇 보다 주변에서 앱을 사용하고 피드백 주시는게 너무 기쁘고 재밌었어요. 

그래서 결론은! 저는 iOS 개발 계속 할겁니다! ㅎㅎㅎㅎ

 

여러 활동들

작년에 필라테스 등록해서 열심히 하다가 마무리 하고 주짓수를 했습니당. 몇 개월 하진 않았지만 정말 재밌었어요. 주짓수라는 운동을 제 생에 해볼 일이 있을까 싶었는데 회사 분들이 열심히 추천해 줘서 해볼 수 있었어요. 너무 아프고 아프고 아팠지만 나중에 꼭 더 배우고 싶었습니다. 1분기에 무리해서 면연력이 안좋아졌는지 건강이 너무 안 좋아서 힘들더라구요 필라테스 보다 훨씬 몸이 좋아지는 것 같았지만 필라테스가 저한테 더 맞는거 같기도.. 

그리고 2월 28일에 데뷰를 다녀왔어요! 개발팀 다 같이 가서 원하는 세션 들었는데 개발 더 열심히 하고 싶은 마음이 뿜뿜하더라구요! 네이버 개발자 분들 너무 멋있습니다. 이때 코틀린으로 서버, 네이티브 개발하는 내용이 제일 인상 깊었는데 코틀린을 배워 둘까 싶더라구요.

작년에는 전시회도 많이 갔는데 23년도 들어서 자주 못간거 같아요 ㅠㅠ 3월 초에 조용히 혼자 전시회에 다녀왔는데 생각해 볼 시간이 많아서 좋았습니다. 저는 전시회 가면 직업병인지 앱 디자인에 어떻게 적용하면 좋을까 이런 생각들이 많이 들어요. 

막상 피그마 켜서 디자인 해보면 디자이너들에게 감사한 마음이 들어요 ㅋㅋㅋㅋ 보기 좋은 디자인과 사용자를 고려한 UI/UX는 다른감이 있는 것 같아요. 하지만 언젠가는 UI/UX에도 욕심내고 싶은 개발자 입니다. 그리고.. 전시회 자주 가고 싶어요.

데뷰 쏘카 부스에서 이메일 등록한 사람들 대상으로 북콘서트 참가 신청을 받았는데 당첨이 되서 다녀왔어요! 리더의 생각 재밌고 감명 깊게 읽었어요. 북콘서트 가기 전에 책 한권 사서 다 읽고, 당일에 싸인까지 받아왔어요. 

연차가 쌓일 수록 개발만 잘하는 개발자가 아니라 커뮤니케이션과 리딩 역활이 중요하다고 느끼고 있고, 유지보수와 리팩토링을 하면서 마주했던 문제들에 대해 다른 회사에서 일하시는 CTO님 생각을 들을 수 있어서 좋았어요. 

팀장님께 책 선물해야 한다면 이 책을 추천추천 합니당.