첫 서비스 배포 후기

회사에 입사하고 다사다난한 생활을 지내고 마침내 앱을 배포했다.

앱이 출시된지 2주정도 지난 시점에서 뒤를 돌아보며 다사다난 했던 첫 서비스 배포 후기를 남기려 한다!!

 

1. 1인 개발은 너무 힘들다 하지만 한 번 정도는 해볼만 하다...?!?

 처음 입사했을 땐 회사에서 바이앱스라는 업체를 이용하여 카페24에서 호스팅한 웹앱을 서비스 하고 있어서 그 웹앱을 관리하는 업무를 했었다. 이 때 까지만 해도 이미 작업된 코드를 수정하는 업무여서 큰 어려움이 없었으나 고난과 역경은 개발을 시작한 이후 시작 됐다.

 첫 번째 역경은 설치된 모듈끼리 버전이 꼬였는지 도저히 잡을 수 없는 에러가 발생했던 것이었다.

구글에 검색해도 불분명한 답변만 계속 되고 회사에 계신 백앤드 시니어분도 구체적인 답변을 주시지 못하셔서 애를 먹다 결국 레파지토리를 새로 생성하여 설정을 다시 하니 해결이 됬던 기억이 난다.

이 때 모듈간 버전 관리의 중요성과 사람들이 왜 버전업을 망설이는지 이해가 됐고, 이후부터는 새롭게 추가되는 모듈이 있을 경우 깃 관리에 더 신경을 쓰게 된 계기가 되었다.

 두 번째 역경은 결제쪽 웹뷰를 이용할 때 발생했었다.

회사 내부 사정상 페이플이라는 pg사를 이용해서 개발했어야 했는데 rn관련 모듈을 지원하지 않아 직접 구현해야 하는 상황이었다.

pg사에서 제공되는 api들을 rn에서 사용하려 애를 써봐도 답이 없어 혼자서 고군분투 하다가 결국 찾았던 답은 그냥 웹뷰로 서버에서 랜더링된 페이지를 뿌려주는 방법이었다.

하여 웹뷰에서 페이지가 라우팅 되면서 발생하는 로그를 추적하여 결제 결과에 따라 분기 처리를 진행하여 여차저차 구현을 완료했다.

결제쪽 구현을 진행하면서 결제가 어떻게 돌아가는지 공부도 많이 되었고 rn으로 개발할 수 있는 제한적인 환경에 대해서도 이해하는 계기가 되었다.

 세 번째 역경은 카카오 소셜 로그인 구현중 ios에서 앱으로 연결이 안되고 웹앱으로만 로그인 되던 이슈가 있었다.

이 이슈는 개인적인 실수 때문에 발생한 에러인데 라이브러리 가이드에서는 info.plist 파일에 특정 카카오 버전의 앱스킴을 입력해줘야 실행되는 라이브러리 였으나 나는 글로벌하게 카카오 앱스킴을 입력해서 앱이 켜지지 않는 이슈가 있었다.

이를 통해 당연히 되겠다고 생각하던 것들이 당연하지 않다는 것을 깨닳고 조금 더 꼼꼼히 보는 습관을 가지게 되었다.

 

2. 공식 문서에 모든 답이 있다

 제목 그대로 공식 문서에는 모든 답이 있다.

개발 초기 새로운 스텍을 적용하거나 기능을 개발할 때 그냥 구글링을 통해서 얻은 결과로 구현을 진행하고 공식 문서는 가볍게 읽고 참고하는 정도만 진행했는데 이게 큰 잘못이라는 것을 깨닳게 되었다.

rn같은 경우 지원해주는 테그나 기능들이 프레임워크에 한정된 기능들이 많았고(flatlist와 같이 대용량 랜더링 시에는 해당 테그를 사용해야한다) 해당 기능들에 대해서 재대로 알지 못한 상태로 개발을 진행하다 보니 코드 작성에 대한 패턴이 꼬이고 이전에 작성한 코드를 다시 리펙토링해야 하는 결과를 야기했다.

예전부터 개발에 임할 때 깊게 이해하고 개발을 해야된다는 생각을 가지고 있었지만 정확히 어떤게 깊게 이해하는건데? 라고 하면 답을 내릴 수 없었는데 프로젝트를 진행하며 기본적인 것들을 아는 것부터 깊게 이해하는 것이 아닌가 라는 생각을 가지게 되는 계기가 되었다.

 

3. 이름이 반이다

 사실 이 내용은 이번 프로젝트를 진행하며 재대로 적용하지 못해서 아쉬운 부분이다.

개발자 친구들이랑 이야기 하면서 들었던 이야기 중에 자기네 프로젝트에서는 함수 이름 하나를 정하는데 회의만 3시간을 넘게 한다는 이야기를 듣고 과장이 심하다라는 생각을 했었는데 지금와서는 이 이야기가 거짓말이 아니라는 것을 새삼스럽게 느끼게 되었다.

 앱 개발 초기 개발할 사항들이 많다 보니 컴포넌트 이름이나 state이름을 지을 때 그냥 생각나는데로 짓다보니 정확한 규칙이 없었고 이렇게 계속 짓다 보니까 나중에 코드를 리펙토링 하려고 보니까 각 컴포넌트와 함수들이 어떤 기능을 하는지 재대로 읽어보지 않으면 알 수가 없었다. 그러다 보니 개발 시간이 점점 늘어나게 되었고 결국엔 리펙토링 할 때마다 이름을 다시 짓게 되는 참사가 벌어졌다...

 좋은 코드 작성이 하고 싶다고 인터넷을 뒤지며 검색했을 때 이름을 재대로 지으라는 말은 가볍게 무시하고 코드가 이뻐야 된다는 생각을 가지고 있던 나를 반성한다...

 

4. 에러 핸들링은 할 수 있는데로 최대한 세부적으로 하자

 이 부분은 라이브 하고 나서 겪은 일이다.

카카오 로그인의 경우 앱 출시 전 얼마 남지 않은 상태에서 추가되다 보니 급하게 준비하게 되다 보니 예외 처리를 세부적으로 구조를 잘 그리지 못하고 제너럴하게 분기를 처리해서 에러가 발생해도 어떤 에러인지 확인이 안됬다.

그러다 보니 cs를 처리할 때 원인 파악이 안되서 원인 파악하려고 급하게 재배포를 하는 이슈가 있었다. sentry를 사용해서 에러가 발생하면 다 잡을 수 있을 것이라 생각했는데 예상된 범위내에서 에러가 발생하면 답이 없다는 것을 깨닳고 항상 보험은 2개 이상 들어야 한다는 것을 알게 되었다.

 

마무리...

 짧다하면 짧고 길다하면 긴 개발 기간 동안 나름대로 고군분투 하며 결국 배포에 성공했다.

솔직히 배포할 때 까지만 해도 현실감 제로였는데 라이브 돼서 사람들이 사용하고 있는 모습을 보니

뿌듯하기도 하고 아쉽기도 한 것이 말로 설명할 수 없는 기분이 든다.

 사실 뿌듯한 감정보다는 아쉬운 감정이 더 많이 드는 것 같다. 조금만 더 신경 썻더라면...

개발 환경이 조금만 더 좋았더라면 어땠을까 하는 생각들이 아직도 꼬리에 꼬리를 물고 있다.

그래도 이번 프로젝트를 진행하며 잃은 것 보다는 얻은게 더 많을 것이라는 생각으로 다음 프로젝트에서는

했던 실수는 또 하지 않길 바라며 이만 마치려 한다!!