비행일정관리앱 개발 후기

왜 이런 앱을 배포했는가?

일반 직작 9-6 근무로 살아가는 일반 직장인의 일과를 쫓아가는 일은 가족으로서 크게 신경을 쓸 일은 아니지만

비행 기장으로 지내는 가족의 일정을 확인하는 것은 꼭 필요한 일이다.

옷을 준비하고 오붓한 시간을 보내는 등 가족으로서 알아야할 그리고 기장이 다음 비행을 준비하는 가장 기본적인 일이기 때문인데

내가 받아본 일정표는 마치 엑셀로 뽑아놓은 것처럼 보기에 불편했으며 항공사에서는 이를 관리할 수 있는 서비스가 전혀 없었다.

내가 해야할 것은 무엇인가?

개발자의 입장에서 생각해보면 이런 문제를 두고 어떤 서비스를 만들 수 있을까?

• 비행 일정을 보기좋게 앱으로 만들자
• 날씨 정보도 가져와 볼까?
• 돈도 벌 수 있도록 광고도 달아야지!

문제 발생

비행 일정을 관리하는 기업에서 API를 가져오면되는거 아니야? 라고 생각한다면 나도 가장먼저 생각한 부분이다.

하지만 CrewConnex에서 돌아온 대답은 개인이 서비스 개발을 위해 API를 제공할 수 없으며 항공 데이터는 보여줄 수 없다는 대답이 돌아왔다.

여기서 발생하는 문제점은 2가지가 발생한다.

• 이미지 한장의 데이터를 어떻게 DB에 입력을 해야할까?
• 데이터 노출 위험

---

극복 계획

OCR

가장 먼저 생각한 아이디어는 이미지 내부의 글자를 데이터화 시키는 OCR 기술을 사용해 DB에 저장시키는 것이었다.

AWS EC2를 사용할 계획이었기 때문에 Amazon Textract으로 사용하기로 했다.

Amazon Textract?

사실 OCR 기술이지만 AWS에서 사용하는 기술이며 솔직히 개발에 대한 사용 후기 혹은 블로그 정보가 너무나도 적었으며 Document를 봐도 이해하기는 어려워 사용하기 까다로웠다.

데이터 노출

마지막까지 너무 어려운 문제였다.

서비스는 항공사 기장과 가족 만 가입할 수 있도록 해야하며 공개되어서는 안되었는데 방법을 찾아야 했다.

때문에 다른 유명 서비스들은 어떤 방식을 고수하고 있는지 확인했고 마침 '블라인드' 였다.

블라인드는 가입시 기업 이메일을 사용하기 때문에 재직을 증명할 수 있었고 해당 메일을 사용한다면 가족 인증 정보 전달, 가입 이메일 전달 등 다양한 정보 전달을 안전하게 전달 할 수 있게된 것이다.

배포하는 데 뭐가 어려웠는지?

비용과 EC2의 메모리 그리고 용량을 최적화 할 수 있는 인스턴스 합의점을 찾는 것이 가장 어려웠다.

용량관리는 (Docker의 도입)?

Back-End를 감당 가능한 최소한의 비용이 가능한 t2.small 인스턴스를 선택했고 인스턴스 내부에 코드를 두는 것이 아닌 Docker를 배치에 이미지 및 컨테이너로 관리한다면 용량을 절반은 줄일 수 있을 것이라 생각했다.

메모리는(swap-file 도입)?

Docker는 용량의 개선을 도와주지만 메모리 관리에서는 한계점이 존재한다. t2.small으로는 부족한 메모리를
swap-file을 이용하여 2G 정도 늘려주는 방법을 선택했다.

---

배포하면서 배운 점이 무엇인지?

사용자 친화적

배포하는 기술보다는 서비스 차원에서 사용자가 어떤것을 원하는지 고민하는 과정에서 배울것이 더 많았다.

• 사용자가 안심하고 사용할 수 있는
• 정확한 데이터를 관리할 수 있는가
• UI는 사용자 친화적인가

비행 기장이 필요한 정보가 무엇일까를 조사한 결과 일정에 이어서 날씨 정보였다.

도착지 날씨를 알아야 조종 방식이 바뀔 수 있다고 하니 DB에 국가별 위도 / 경도를 추가하여 Open-Weather에 전달하여 데이터를 가져왔다.

Flutter의 도입

Flutter 도입으로 새로운 프레임워크를 접할 수 있었다.

빠른 개발과 완만한 러닝곡선을 가지는 모바일 프레임워크를 찾던중에 Flutter를 도입한다면 좋겠다 생각했다.

솔직하게 개발기간 지연을 막기위해 좋게 말한다면 GPT주도개발로 진행했지만 아무 지식도 없이 Flutter프레임워크를 사용하는것은 온전히 기술을 사용할 수 없을 것으로 생각하여 이론적 배경부터 학습하여 장점을 최대화 하려 노력했다.

마치며

1년 6개월 계획 6개월 개발 의 기간을 거쳐 2년의 기간동안 서비스 개발의 쉼표를 찍었다.

마침표가 아닌 쉼표인 이유는 앞으로도 지속적으로 개발을 진행해야하기 때문이며, 이직할때 써먹어야하니까...

앞으로도 활발하게 사용할 것이며 몇몇의 유저들이 도입될지 모르겠지만 SQS 유지를 위해 지속적으로 관심을 가지고 개발을 할 예정이다.