나의 첫 앱 개발 프로젝트 - 출근부 앱 개발기

앱 개발기

1. 시작하며...

시작은 아마 올해 2월 말 정도였어요. React Native 배우겠다고, 강의 사서 듣고 있었는데, 클라이언트(엄마)가 직원들 출근 관리 하는 앱이 좀 불편해져서 간단하게 하나 앱을 만들어 줄 수 있냐고 했어요. 그 때의 실력으론 아무것도 못 해서 공부하고 나중에 한다고 말하고 미뤘었죠. (뭐 지금도 잘하는 건 아니지만)

그리고, 학교 생활하다보니 1학기가 끝났어요. 기말 쯤 되니까 저번에 만들어 둔, wasureta를 수정하면서, DB가 별 거 없다는 걸 알게되고, 8월 초 부터 시작하게됐어요. 1인 프로젝트로, 총 개발 기간은 3주 정도 걸렸네요.

아무튼, React Native도 거의 처음이고 앱 개발 프로젝트도 처음이지만, 그냥 대가리 박치기로 시작했죠. (요새 느끼는 거지만, 언어만 배우면 그 이후는 강의나 책을 읽는 거 보다 그 때 그 때 찾아보면서 대가리 박치기하는게 젤 나은 거 같아요.)

 

 

2. 구상하기

이번에 프로젝트를 하면서 젤 크게 느낀 건, 디자이너의 필요성이였어요. 혼자서, 기획, 디자인, 프론트, 백을 다 하려고 하니까, 다른건 커버가 되도 디자인은 커버가 안 되더라고요. figma를 통해서 디자인을 많이 한다는 이야기를 듣고, figma로 도안을 먼저 짰었어요.

개발 시작 전 figma로 짠 원안이다.

이 때는 어떻게 디자인 해야하는 지도 몰라서, 관리자 메뉴 내부도 확정을 못 한 상태였어요. DB는 supabase를 쓰고, 서버는 저번에 못 썼던 koyeb으로 결정했어요. (koyeb에는 저사양의 무료 서버를 무제한 대여해준다. 서버가 미국이고, api요청이 없으면 sleep상태가 된다.)

 

 

3. 프론트 엔드

ReactNative는 되게 직관적으로 동작해요. 크게 어려움은 없지만, 웹에서도 느꼈던 html css는 너무 답답해요. div(RN에선 View)를 씌우냐 안 씌우냐에 따라 다르고, 똑같은 가운데 정렬을 하고 싶어도 상황마다 방법이 너무 달라요. (사실 이러면 그냥 html css파트를 그냥 ai한테 짬 때리고 적당히 손봐주면 되요. 이번에 대학생 gemini 1년 무료 이벤트도 하거든요)

React에서는 컴포넌트 별로 파일을 계속 쪼개야만 하는 게 장점으로 다가와요. 제가 원래 파일을 잘 안 쪼개는 스타일인데, 오히려 쪼개니까 ui별로 나뉘어서 좋더라고요.

 

 

4. 백 엔드

여기서부터 이제 문제가 많이 발생했어요. RN은 사실 웹과 흡사하기 때문에 기존에 해봐서 별 문제가 안 됐어요. 하지만, 이걸 만들기 전엔 api가 뭔지도 몰랐어요. 알아본 결과 백 엔드에는 Java, node.js, python 이렇게 3개가 쓰이는 거 같더라고요. 저는 당연히 python flask를 골랐어요. 백준도 python으로만 하거든요. (필자는 Java문법도 모르고 정보처리 기능사를 땄다.)

 

 

Flask로 시작

flask로 어느 정도 만들다보니, 확정을 안 시켜놓은 ui가 문제가 되서, ui를 조금 손 봐줬어요. 그리고 flask로 어느정도 만들고 나니까, RESTful 이라는 개념을 친구를 통해서 알게 되었어요. 아뿔사, 이전까진 POST가 GET의 상위호환인줄 알고 모든 요청을 POST로 때리고, api는 동사로만 쓰고, 로그인 기능은 POST로 때리고 보안 안 해도 괜찮은 거 아님? 이러는 Restless를 하고 있었지 뭐예요...

한 python 파일에 아무렇게나 api를 만들기 시작한게, 경로도 마음대로라, 10개가 넘어가니 짠 본인도 헷갈리기 시작했어요. 멀리가려면 업보는 청산해야죠. RESTful로 바꾸려고 마음을 먹었을 때, FastApi를 알게되요. 한편, 제대로 ui를 확정 짓고 시작하지 않아서, 바꾸는 김에 데이터베이스 테이블을 갈아 엎었어요.

 

FastApi로 변경

FastApi는 이름 그대로 flask보다 빠르다는 장점을 가져요. (어처피 본인 프로젝트는 supabase에서 가져오는 시간이 1초는 걸리기에 의미 없다) 이 뿐 만이 아니라, flask에서는 코드 작성하면서 문법 오류 난 상태로 고민을 좀 하고 있으면 서버가 꺼져버리는데, FastApi에선 그 api만 문제가 생기고 서버가 유지 되요. 또한, /docs 경로에 자동으로 모든 api의 목록인 docs를 만들어줘요.

위와 같이, 자동으로 docs를 만들어준다.

그렇게 Restful과 FastApi로 바꾸고 나니, 개발자인 저도 알아보기가 한결 편해졌어요.

 

JWT 권한 인가

자 이제 보안 업보를 치뤄야죠. 지금까진 POST로 하면 되는 거 아님? 하면서 아무 보안을 안 했어요. 하지만, 관리자 전용 api를 일반 사용자가 접근하게 해서는 안 되죠. 이 권한을 확인 시켜주는게 바로 JWT의 토큰이예요. 토큰을 통해서, 사용자의 정보를 알 수 있어요. 딕셔너리 형태의 정보를 암호화한 토큰을 통해서 말이죠. 다른 암호 중에 또 신기한 게 bcrypt는, 암호화할 때, salt를 붙이는 데, 실행할 때 마다 암호화 값이 매번 달라져요. 하지만, 그 입력에 대해서, 그 입력이 매번 바뀌는 암호화된 값과 일치하는 지를 확인할 수 있는 신기한 라이브러리였어요.

 

 

5. 의사소통 issue

자 어느 정도 만들어서, 클라이언트(엄마)에게 보여줬어요. 클라이언트는, 출근부 페이지를 다른 방식으로 보길 원했고, pdf다운로드 기능과 웹으로 보기를 원했어요. 또한, 연차 페이지는 달 기준이 아닌, 사람 기준으로 보길 원했죠. 그리고 각종 수정기능들을 까먹었네요.

아, 원하는 방식으로 하려고 하니까 DB 테이블을 또 바꿔야하네요. 이번이 아마 3번째 row변경일 거예요. 그러면 그걸 바꾸는 api도 다시 바꿔야 하네요. 아무튼 다시 하면 되죠.

pdf다운로드는 python으로 pdf를 한 땀 한 땀 만드는 대신, html을 생성하고 html을 pdf로 바꾸는 라이브러리를 쓰는 게 더 편한 거 같아요. html을 통해서 하면, 더 자유롭고 빠르게 생성을 할 수 있으니까요.

 

 

6. expo, koyeb(by docker) 빌드

wasureta때 처럼 이번에도 백엔드는 docker를 이용하기로 했어요. koyeb에서는 docker를 지원하거든요. koyeb에서는 github과 연결을 하면, 새 커밋이 생길 때 마다 서버를 실행시켜줘요. 이 때 docker를 선택 해두면, github에 올라간 dockerfile을 보고 그 dockerfile을 통해서 자체적으로 빌드를 해 줍니다. 이 도커를 하는 과정에서, pdf로 다운 받을 때, 한글 폰트가 없어서 그걸 다운 받는데 많은 애를 먹은 기억이 있네요. 도커에서 그 한글 폰트를 다운 받도록 하고, 시스템을 한글로 설정해야해요. 제 경우는, 시스템 설정을 안 해서 문제였었어요.

프론트 엔드는 expo를 통해서 만들었기에, eas build를 이용해야해요. 빌드를 하는데는, 얼마 안 걸리지만, 큐에서 많은 시간이 걸려요. --local을 통해서 build를 할 순 있지만, 윈도우에선 안 되죠. wsl과 라즈베리파이를 통해서 이를 --local로 해보려고 했지만, 또 각종 의존성 문제들 땜에 실패했어요. 그래서 큐에 넣고 잠이나 자러갔죠. build 명령어 치고 컴퓨터 꺼도 되거든요.

신기하게 얘도 github에서 commit을 끌어오는 구조였다. 무려 큐 시간은 2시간 반이 걸렸고, 빌드는 8분 밖에 안 걸렸다. 진짜 다시는 경험하고 싶지 않은 불쾌함이였어요.

 

 

7. 최종결과

아무튼 그래서 나온 최종 결과본.

처음 구상할 때의, figma와는 꽤 달라졌어요. 이번 프로젝트를 통해서, 디자이너가 필요한 이유를 절실히 느꼈어요. (DB만 3번을 갈았거든요) 그리고, 백엔드에 상당한 관심이 생기게 되네요. 프론트는 재미없지만, 백은 굉장히 흥미로웠네요.

이 프로젝트의 깃헙 주소는 아래 첨부해요. (별 건 없지만...)

https://github.com/SodiumD5/AttendanceApp