모바일 앱 개발을 하며 배운 점 - 출시 완료, 그렇게 3개월이 흘렀다.

https://play.google.com/store/apps/details?id=com.mantto

만또 Mantto - Google Play 앱

만또가 어떻게 나오게 되었나? 당시를 회상하며...

이전에 학교를 다니며 활동했던 DSC 동아리에서 2020년 9월 학기 중에 협업 프로젝트를 진행했었다.

재능 공유 플랫폼을 만들어 보자는 얘기가 나와 3개월 동안 프로젝트를 진행했었다. ( 당시 나는 4학년 막학기였다. )

백엔드 개발자 1명, 프론트 엔드 개발자 2명 ( 나 포함 ) , 디자이너로 구성된 팀이었고, 기획부터 앱 플로우 차트 등을 같이 생각하면서 차근차근 만들어 나갔다.

• 당시 나는 개발자가 되기로 맘 먹고 시작한 개발 공부를 처음부터 시작한 기간이 8개월이 안된 때였다. 프론트엔드 쪽 기본기라 볼 수 있는 HTML, CSS, JS를 어느정도 공부해둔 상태였고 Node.js 공부를 아주 약간 공부했던 때였기 때문에, React 를 프로젝트에 적용해 보면서 공부해보자는 마음으로 시작했다. ( 당시 코드숨이라는 리액트에 TDD 를 공부할 수 있는 코드 리뷰 프로그램도 참여한 상태였다. )

어쨋든, 개발 공부와 프로젝트 두마리 토끼를 모두 잡기 위해 시작했다.

개발 공부 + 프로젝트 + 막학기 졸업 시험 = 헬 / 두마리 아니, 세마리 토끼?

욕심이 부른 화일까, 개발 공부 ( 코드숨 프로젝트 ) + DSC 프로젝트 + 막학기 졸업 시험 / 중간 - 기말 고사 가 겹치면서 아주 바쁜 학기를 보냈다.

 

재능 공유 플랫폼 만들기 프로젝트에 대해...

- 백엔드 개발자는 1명이었다. API 명세와 AWS 에 서버 배포를 준비했다. DJango 를 사용했었고, DB 는 MySQL 이었다.

 > 왜 서버 배포를 먼저 준비했나?

가장 큰 문제였는데, 로컬 서버를 통합할 생각을 하지 못했다. 예를 들면, DJango 로컬 개발 서버와 React Native 프론트 로컬 개발 서버가 서로 통신하려면, 연결지어야 하는데 에뮬레이터를 돌리는 과정에서 로컬 서버 연결 에러가 계속 발생했다. 나중에 알고 보니 localhost 설정이 잘못된 결과였다. 아무튼 당시에는 해결하지 못했었기 때문에 일단 AWS 에 서버 배포를 해달라고 요청했었다.

< 해당 이슈 관련 stackoverflow >

https://stackoverflow.com/questions/33704130/react-native-android-fetch-failing-on-connection-to-local-api

React Native Android Fetch failing on connection to local API

이제 안 사실이지만, 가장 간단하고 편한게 ngrok 로 로컬 서버를 아주 빠르게 배포하면 된다. ( 로컬호스트로 port 설정하고 localhost -> 127.0.0.1 로 바꾸고 해도 에뮬레이터랑 연결 안되는 경우가 종종 있다 => 서버 url 을 바꿀 때마다 무조건 react native cache 는 리셋 해줘야 한다. )

- 프론트 엔드 개발자는 나를 포함한 개발자 2명이었다. React Native 0.63 버전 ( 2020.09 latest version ) https://github.com/facebook/react-native/releases/tag/v0.63.0 를 사용하기로 하고, 스타일은 styled-components 와 상태관리는 react redux / redux - thunk 를 사용하기로 했다. 나머지 한분이 이번 프로젝트에 개발을 배우기 위해서 들어오셨기 때문에 개발에 대한 지식과 경험이 전무했다. ( 나중에 듣기론 CSS 조금 해보셨다고 하셨다 )

디자이너 - 현업에서 웹 디자인을 하셨던 분이셨다. ( 파트 타임으로 일하고 계셨던 4학년 막학기 디자이너셨다. )

전반적인 기획과 디자인을 담당하셨다.

 

개발 일정, 그리고 마무리

개발은 백엔드와 프론트엔드가 HTTP 로 통신하기로 하였기 때문에, 명확히 구분되어 진행되었다.

Github 에 Organizaton 을 만들어 진행했고, API 명세를 만들어서 진행했다.

브랜치를 나눠 진행했다 -  front / backend

마무리는 다 짓지 못하고 끝났다. 이유는 아무래도 공부하기 위해서 한 프로젝트다 보니 다들 학교 공부에 바빠 일정이 조금씩 밀리더니 마지막 스퍼트 개발 이후 최종 발표로 마무리 되었다. 아래는 발표 한달 전 앱 시연 영상이다.

( 최종 발표 영상이 없어서 이걸로 대신했다. )

발표는 내가 했었다. - 발표 도중 에러가 나서 많이 당황했었다. ( 로컬 서버로 돌렸다. )- 어쨌든 잘 마무리 했다.

앱 1차 시연 영상

그리고 약 1년 후...

출시도 못한 채, 묻혀있었던 프로젝트를 다시 살려보고 싶은 마음이 컸다. 그러다 우연히 가깝게 지내던 지인으로부터 평소 이 프로젝트에 대해 얘기를 했었는데, 지인이 다니던 회사 대표님께서 이 프로젝트에 관심이 있다는 얘기를 해줬다.

 

찾아온 기회 서울로...!

이 프로젝트에 대해 얘기드리면서 설득을 했다. 대표님께서는 이전에 기획하고 창업했던 프로젝트의 개발 기간이 차일피일 계속 미뤄지면서 계획이 틀어지게 되었고 포기하고 어플 창업을 접을 생각을 하고 계셨었다.

하지만, 재능 공유 플랫폼을 만들어보고 싶은 마음을 가지고 계셨기 때문에 내가 예전에 했던 프로젝트에 대해 말씀드리자 굉장히 맘에 들어하셨다. 결국, 같이 해보자는 최종 확인을 받고 6월 말 급히 서울로 올라가게 된다.

( 당시 마침, 일반 학점을 채우기 위해 현장 실습을 신청했던 4개월 기간이 마무리 된 시점이었기 때문에 바로 합류가 가능했다. ) - 웹 서비스 개발로 들어갔다. 프론트 엔드만 개발 할 줄 알았지만, 웹 풀스택 개발을 하게 되었다.

모카 클래스 - https://mochaclass.com/

모바일 앱 개발의 시작!

올라온 당시 6월 말경이었고, 구성원들은 대표님, 디자이너 1명, 프론트엔드 개발자 1명, 그리고 나 총 4명이었다.

지금까지 공부했던 모든 개발 지식들을 총 동원해서 전체 앱 개발 아키텍처를 설계하기 시작했다.

이전에 이 회사에서 진행했던 프로젝트가 무너지면서 남겨진 것들을 보니...

1. 메일 플러그 -> 기업 메일이 등록 되어 있었다.

2. NHN Cloud -> AWS 랑 비슷한 클라우드 호스팅 서비스다.

이 두가지를 활용해서 전체 아키텍처를 설계 하였다.

 

백엔드 - > Typescript / Node.js, express / Docker / Docker-compose / GraphQL / apollo-server /tslint

 

왜 이 기술스택들을 선택했나?

이렇게 묻는다면, 설명을 차근차근 해볼 생각이다.

기술 선택에는 항상 이유가 따라야 한다. 

 

1. TypeScript .

이유 ?

   -  정적 타입 언어를 고른 이유의 가장 큰 이유는 디버깅이 쉬워지고, 코드를 읽고 해석하는데 기존 자바스크립트보다 명확해질 수 있다. 하지만, 타입 스크립트를 사용하는게 처음이었고, 이전에 공부했던 자바와 비슷한 느낌을 받았다. ( 자바스크립트 의 superset! )

function 의 arguments 와 return value 의 타입을 함수를 정의할때 정해줘야 하기 때문에 한눈에 이 함수의 역할을 알기 쉬워진다.

그리고 바벨 설정을 따로 하지 않고도 ES6 최신 문법을 Node.js 환경에서 사용가능하다는 점이다.

타입스크립트에서 자바스크립트로 컴파일 하면서 tsconfig 설정에 따라서 컴파일러가 바벨이 해주는 트랜스파일도 해줘서 편하다.

common js 를 default 로 지원해주는 Node.js... 그리고 최신 JS 문법을 쓰고 싶은 나...!

 

( 제네릭이나, 인터페이스 사용을 해보려고 했으나, 구현에 급급해서 사용해보진 못했다. 앞으로 더 공부하면 꼭 써볼 생각이다. )

 

써보면서 느낀점 ?

  -  확실히 디버깅이 수월했다. tslint 를 설정해둔 덕분에 vscode 가 값이 쓰이지 않거나 다른 타입 값이 들어가면 즉시 밑줄로 에러를 알려준 덕분에 수정사항을 반영할 때 아주 편리했다. ( 물론 함수에 매개변수가 추가되면 기존 함수에서 빠지거나 추가되는 값과 해당 타입을 수정해줘야 하는 번거러움은 있다 )

 

2. Node.js, Express .

이유 ?

- 가장 큰 이유 중 하나는 Node.js 는 자바스크립트 런타임 환경을 제공하기 때문에 같은 언어로 풀스택 개발이 가능하다는 점이다. Node.js 하나로 여러 라이브러리를 쌓아가면서 백엔드 환경을 구축해도 되지만, Express 프레임워크를 사용해서 조금 더 빠른 환경 구축이 가능하기 때문에 적용하였다. ( 빠른 것도 중요하다. - 이놈의 deadline )

 

3. Docker / Docker-compose .

이유 ?

- 백엔드 배포 환경에서 cloud hosting service 사용시, VPC, 가용영역, 라우트 테이블, 보안그룹 설정을 한 후 인스턴스를 생성할 때, CentOS, Ubuntu 등을 default OS 로 설정해서 생성이 가능한데 해당 인스턴스로 ssh 설정을 한 뒤 로컬 터미널로 접속하면, 그야말로 아무것도 없는 컴퓨터이다. 거기서 내가 개발한 백엔드 환경과 일치하도록 여러가지 환경 설치를 하게 되면, 너무 피곤해진다. -> ( 실제로 설치도 일일히 다 해봤었다. ) 만약, 환경 버전이 업데이트가 되거나 했을 때, 그것도 다시 루트에서 재설치를 해줘야 하는 귀찮음/까다로움이 생기기 때문에 도커를 사용하기로 했다.

=> 써본 경험상 너무 편하다.

단점은

- 도커의 경우 이미지, 컨테이너, 볼륨 등이 한번 설정되고 나면, 남기 때문에 제대로 관리 해주지 않으면, 메모리 용량이 무시무시하게 커진다. 안그래도 저비용의 인스턴스는 메모리 용량이 많지 않기 때문에 자칫하면 용량이 오버될 수 있기 때문에 자주 docker rm 을 해줘야 한다. ( 여기서 메모리는 보조 기억장치를 얘기한다, 물론 AWS S3 용량을 키워서 인스턴스에 붙여 주면 해결은 된다. )

- 메인 메모리 문제도 있는 것 같다. 갑자기 로컬에서 돌릴 때는 잘 됐던게 안되는 경우가 있는데 이럴 경우는 도커가 차지하는 메인 메모리가 그 환경을 돌리기에 부족할 경우 문제가 생길 때가 있는 것 같다. 인스턴스 최대 용량이 2G 라면

2G 초과하는 메모리를 차지하게 되는 도커 환경의 경우 문제가 있게 된다.

Docker 컨테이너 내에서 오버커밋으로 너무 많은 프로세스가 동작하여, 어떤 프로세스가 메모리가 필요한데 물리적 메모리와 가상 메모리(스왑)을 모두 다 사용해서 새로운 메모리를 할당하지 못할 경우 OOM Killer가 동작한다. 
OOM Killer는 메모리를 확보하기 위해 자신만의 알고리즘을 이용해서 종료시킬 프로세스를 선택하고 종료시킨다.

결론 ?

- 도커 사용을 통해서 빠른 환경 구축 및 유지 보수를 위해 사용하기로 했다. ( 이후 자동 배포도 구현하는 것이 목표 )

4. GraphQL / Apollo - client, server
이유?

- graphQL 을 이전에도 사용해본 경험상 개발 경험이 좋았다. 특히 프론트엔드 / 백엔드 개발자 사이에 소통 및 협업에 필요한 api 명세를 따로 작성해주지 않아도 개발을 진행하는데 문제가 전혀 없었기 때문이다. 리소스가 적은 상황에서 활용하기에 좋은 방법이라고 생각했다.

apollo-client / apollo-server 가 서로 연동되어 작동되면서 구현상 흔히 발생하는 에러가 최소화되도록 다양한 full management 기능들이 많아 개발자는 서비스 구현에 더 많이 투자할 수 있어 선택했다.
단점은 ?

- 구현 당시 (2021년 8월) 에는 multipart/form-data 를 업로드 하는 기능이 구현되어 있지 않아 우회하는 작업을 해줘야 했다. 계속 개발되어 가고 있었기 때문에 지금은 해결 되었을 것이다.

우회하는 방법으로 당시 NHN Cloud 를 사용했기 때문에 해당 클라우드 사에서 제공하는 파일 업로드 API 를 활용했다.

위 스택의 경우, 이전 회사에서 사용해봤던 경험을 살려 경험이 없던 0년차 백엔드 개발자가 API 개발을 하기에는 좋은 선택이었다.
이전 회사에서 많이 배웠고 궁금증을 가지고 각각의 기술 스택들을 학습해둔 덕분에 응용할 수 있었다.

어려움이 많았지만, 이때 배웠던 것들이 기억에 많이 남을 정도로 많이 성장하고 좋은 기억으로 남아있다.