주니어 개발자 1년차의 회고록 (feat. 이제 시작이다!)

어느덧 개발자로 일을 시작한 지가 1년이 지났다 벌써 1년이라는 시간이 지났다는 게 안 믿어질 정도로 빠르게 흘러갔는데 스타트업에서 근무하다 보니 많은 리뉴얼을 경험했다 그동안 경험한것과 고민한것들을 적어 보려고 한다



취업성공과 첫 리뉴얼 작업!


완전 다른분야인 조선업에서 7년간 근무하다가 꿈에 그리던 개발자로 취업을 해 의욕과 열정이 넘쳐났던 시기였는데 입사했을 때는 앱을 전면 개편하는 리뉴얼 작업을 하고 있었고 거의 마무리 단계라 기능들이 거의 작업이 완료되어 있어서 간단한 작업들 과 camera를 사용하고 있는 코드 부분에서 코드 분리 및 리팩토링 그리고 출판사 정보를 보여주는 모달창 정도 만들고 앱에 대한 전반적인 이해를 하는데 시간을 썼다 그리고 중간중간 개선하고 싶은 부분, 분리하고 싶은 부분 등 생각날 때마다 메모 해 두었다가 사수와 함께 얘기하며 개선 방안을 찾아보았다.



새로운 라이브러리 도입과 두번째 리뉴얼!


1차 리뉴얼이 끝나고 버그 수정과 QA 수정을 하다 보니 어느새 새로운 기획안과 2차 리뉴얼 작업이 기다리고 있었다.. 이번에는 기획 회의 때부터 참여를 해서 많은 것을 접해 볼 수가 있었다 이때 새로운 라이브러리 2가지를 사용하기로 했는데



첫 번째는 style 부분에서 styled-compoent 를 사용했다. 기존에는 stylesheet를 사용했는데 생각보다 적은 인력으로 빠르게 개발을 해야 하는 상황이라 stylesheet와 인라인 스타일이 뒤섞여 있는 상태라 이참에 style을 한 가지만 사용하고 인라인 스타일을 최대한 쓰지 않도록 했다. styled-compoent는 태그 이름을 자기가 원하는 걸로 변경할 수 있는데 이게 가독성에 도움이 될 거 같다는 생각과 간편하게 props를 전달해 style을 변경할 수 있는 점이 좋아 선택했다.



두 번째로는 상태 관리 라이브러리 redux + redux-toolkit을 사용하였는데 그전에는 ContextAPI를 이용해 상태를 관리하였다. 그런데 서비스가 커짐에 따라 성능 문제에 대해 고민이 들었고 Context가 지니고 있는 상태가 바뀌면 해당 Context의 Provider 내부 컴포넌트들이 모두 리렌더링 되는 문제가 있었다. Redux의 최적화 와 devTool extenstion이 있어 디버깅이 편한 점 등 ContextAPI 보다 장점이 많아 redux와 toolkit을 사용하기로 했다



이때 리뉴얼 작업에서는 시험지 업로드, 다운로드 그리고 마이페이지와 메인 페이지 일부분 정도 맡아서 진행을 하였는데 기존에 List들은 다 ScrollView로 구성되어 있는 것들을 FlatList로 전환하여 초기 로딩 속도를 조금 더 빠르게 개선을 시켰다. 다운로드 부분은 해당 시험지를 클릭할 경우 pdf를 보여주는 페이지이며 카톡이나 디바이스 기기에 파일을 다운 받을수 있게 만들었다.



webview사용과 타입스크립트 적용 그리고 또 리뉴얼..?


이번 리뉴얼은 디자인과 많은 기능들이 변경되는 아주 큰 리뉴얼 작업이라 개발 기간이 나름? 합리적으로 주어졌는데 그래서 사수와 기술 스택 선정 회의를 하면서 그동안 적용해 보고 싶었던 라이브러리나 기술들을 얘기해 보며 어떤 것을 도입할지 결정하였다 이번에는 디바이스 기종에 상관없이 동일한 디자인을 보여주고 RN의 네이티브 환경 의존도를 낮춰 해결하기 까다로운 네이티브에서 발생하는 문제들을 신경 쓰지 않음으로써 개발 시간을 확보하고 싶다는 생각이 들어 웹뷰를 사용해 보기로 하였다.



Tailwind CSS 와 React-Query 💾


webview 적용을 포함하여 이번에는 새로운 라이브러리들을 많이 써보기도 했는데 style 부분에서는 styled-compoent 대신 Tailwind CSS 를 사용하였다. styled-compoent는 View 쪽에서 깔끔한 면이 있어 좋긴 하지만 변수명을 짓는데 힘들었고 RN 쪽에서는 지원되지 않는 스타일이 있어 이번에 웹뷰로 넘어가면서 TailwindCSS를 적용하였다.



상태 관리는 Redux 와 Toolkit을 이용하여 관리를 하고 있었지만 서비스가 확장됨에 따라 API 추가에 따른 코드량이 많아지고 여러 파일들을 왔다 갔다 하며 관리하기 복잡한 점이 발생하여 이번에 서버 상태 관리인 React-query를 사용하기로 결정하였다. 확실히 Redux를 사용할 때 보다 코드가 눈에 띄게 줄어들었고 간편하게 작업할 수 있었는데 자체적으로 지원해주는 기능들이 많이 있어서 좋았다. 최소 3번은 데이터를 자동으로 요청이 가는 점과 무엇보다 isLoading, isSuccess, isFetching, isError 등 현재 데이터 상태를 알 수 있어 해당 상태에 맞게 처리할 수 있는 것이 좋았다. 그전에는 redux에서 따로 만들어야 했기 때문에 react-qeury를 사용함으로 써 편하게 데이터 상태에 따라 로직들을 처리 할 수 있었다.



react-query 도입과 기능들에 관해 도음 되는 글을 링크로 추가하였다 react-query 도입에 관해 고민 중이 거나 도입 초기인 분들도 꼭 읽어보면 도움이 많이 되는 글들이다.

카카오 페이 - https://tech.kakaopay.com/post/react-query-1/
배달의 민족 - https://techblog.woowahan.com/6339/



그리고 앱의 안전성을 한단계 더 올리고 싶어 타입스크립트를 적용하였는데 확실히 타입이나, 오타에 관한 에러들을 예방 할 수 있었다. 또한 함수의 매개변수나 객체안의 데이터의 타입을 지정하여 자동완성 기능과 해당 객체에 어떤 데이터가 들었는지 바로 알 수 있어 협업에도 유용했다. 하지만 역시 새롭게 배워야 할것이 많았는데 되도록 any를 사용 하지않고 최대한 타입을 활용하여 작성했다. 결국 새로운 라이브러리들을 많이 사용하다보니 공부해야 할 시간이 필요했고 결국 개발기간이 딱 알맞게 변해버렸다..



물음표를 던지며 개발하기 💡


자바스크립트로 만든 어플리케이션은 hot reload를 통해 코드를 변경하면 거의 바로 적용된 모습을 보여준다. 개발 시 아주 편리한 기능이지만 이 기능이 나에게 잘못된 코딩 습관을 가지게 했다. 그건 깊게 생각하지 않고 코딩을 하는 것이었는데 금방 금방 리로드가 되니 내가 작성한 코드가 정확한지 확인하지 않고 대충 적고 결과물을 돌려 보면서 오류를 찾게 되었다.



이렇게 하다 보니 정말 어이없는 실수와 조금만 생각하면 되는 문제들을 지나쳐 버렸다. 그래서 이때부터는 어떤 서비스 로직을 개발을 하기 위해 코딩을 시작할 때 바로 코드부터 작성하기 보다 생각과 고민을 먼저 했고



“이렇게 짰을 경우 이렇게 되어야 한다.“ 또는 “이럴 경우는 어떻게 되지?”, “재사용성이 가능하게 컴포넌트화를 할 수 있을까?” 등 설계적 고민과 재사용성 그리고 예외 처리에 대해 고민을 하면서 코드를 작성하기 시작했다. 이렇게 하다 보니 코드를 짜기까지 시간은 더 걸리지만 해당 기능 개발에 대해 조금 더 신중하게 접근할 수록 버그를 줄일 수 있었다.



시간이 남을 때마다 틈틈히 RN으로 개발한 개인 프로젝트 앱을 리뉴얼 했는데 이 앱 또한 타입 스크립트로 전환하고 버그와 기능들을 업데이트하고 중요한 위젯을 적용시키는데 성공했다! 하지만 ios만 적용을 하여 추후 코틀린을 공부하여 안드로이드 부분도 위젯을 개발하여야 한다. 캘린더 부분도 수정을 하였다.



Next.js로 마이그레이션!


그전에는 webview 통신하는 과정이 복잡하여 로그를 찍는 것과 webview 통신 과정에서 알 수 없는 오류들을 해결하고 빠른 페이지 전환과 속도를 위해 nextjs를 도입하여 마이그레이션을 하기로 결정했다. 필수적인 데이터들만 webview와 통신하고 나머지는 webview 에서 모든 것을 처리할 수 있도록 만들었다. nextjs 의 장점인 SSR, SSG 를 적극적으로 사용하였는데 Data Fething 이 최초의 한번만 필요하는 곳에는 SSG를 적용하였는데 빌드할때 API를 한번만 호출하여 미리 html을 만들어 두다 보니 페이지 이동시 데이터를 다시 불러 올 필요가 없어 페이지 이동이 빠른 장점이 있었다 SSR을 사용하면 필요한 데이터를 next 서버에서 받아오니 로딩시간도 줄어들어 사용자 경험을 조금 더 개선 할 수 있었다 nextjs 에서 자체적으로 지원하는 기능들이 많이 있고 공식문서가 정말 잘 되어있다 꼭 한번 읽어보길 권장한다



앱 전반적으로 모달창을 많이 사용하는데 이번에는 react-portal 을 사용하여 모달창을 만들어 사용했으며 framer-motion 을 사용하여 애니메이션까지 적용하였다. 이 부분은 react-portal을 이용하여 어떻게 모달창을 만들었는지 따로 글을 쓸 예정이다



TDD에 관하여 ❔


NextJS로 전환을 결정하고 준비하였을 때 Next.js에 대해 공부도 하였지만 이번에 TDD 를 도입하고 싶어 이것저것 알아보고 테스트를 진행하였다. 신규 기능 그리고 기능 고도화로 인해 코드 수정 및 리팩토링을 할 때 조금은 자유롭고? 코드들을 탄탄하게 가져가기 위해서는 테스트 코드가 꼭 필요하다고 생각이 들어 이번 기회에 도입하려고 준비를 많이 했지만 결과적으로 도입에는 실패하였다.



먼저 러닝 커브가 존재했으며 기존의 코드들은 테스트 코드를 짜기에 적합하지 않았다. 또한 라이브러리와 hook에 대한 테스트를 위해 mocking 을 하여야 하며 이것 또한 여러 테스트 코드에서 사용할 수 있게 생각해 만들어야 했다. 그리고 어떻게 하면 테스트 코드를 잘 짤 수 있을까에 대한 고민에 꽤 많은 시간이 소요가 되었다. 당분간은 디자인을 전부 변경하는 리뉴얼은 없고 기능 추가와 서비스 고도화에 초점이 맞춰있으니 다시 TDD 에 도전 해봐야겠다 지금 당장은 도입하기 힘들더라도 미리 공부는 하고 있어야겠다는 생각이 든다.



1년 동안 정말 치열하게 살아왔다 늘 배울 것이 넘쳐나 숨 쉴틈을 주지 않았지만 1년 전에 비해 정말 많은 것을 경험하고 배웠다 그리고 성장했다고 생각한다. 하지만 정말 이제 시작이다. 배워야 할 것과 생각해야 할 것들이 더 많아졌고 책임감도 더 들었나 나의 실수로 인해 유저가 불편을 겪지 않게 그래서 회사가 피해를 입지 않게 책임감을 가지고 개발해야겠다. 개발은 여전히 재밌고 오늘보다 내일이 더 성장하는 개발자가 되고 싶다.