[회고] 모아도 개인회고

모아도 프로젝트가 끝났다.

 

이것으로 UMC 2기 활동이 종료 되었다.

 

처음 프로젝트를 신청할 때, 가장 관심이 가던 프로젝트 였다.

 

교통약자를 위한 지도를 만든다는 아이디어를 통해 "내가 가진 지식으로 세상을 더 편리하고 재미있게 만들자"는 나의 목표에 다가갈 수 있을 것 같아 지원하게 되었다.

 

함께 배우고자 하는 열정있는 팀원들과 그런 팀원들을 이끌었던 기획자, 사용자들이 더 쉽게 사용할 수 있도록 UI 배치 등에 많은 신경을 썼던 디자이너와 한 팀을 이루고 프로젝트를 진행한 것은 정말 좋은 기회였다.

 

기획부터 디자인, 개발과 함께 실제 플레이스토어 런칭까지 해볼 수 있었다.

 

사용자들이 실제로 다운받아 사용하는지는 알 수 없지만, 누군가는 필요에 의해 교통약자를 위한 지도를 찾게 될 것이고, 이 어플이 그들에게 도움이 되기를 바란다.

---

0. 프로젝트를 통해 얻고 싶었던 것

프로젝트를 통해 얻고 싶었던 것은 "목표에 다가가는 것"이었다.

 

"세상을 더 편리하고 재미있게 만들자"라는 목표에 다가가기 위해 이 프로젝트에 참여했다.

 

1. 좋았던 점(Liked)

공공데이터를 원없이 사용해볼 수 있었다.

 

처음에는 모든 데이터를 크롤링 해야 하나 라고 생각을 했으나, 공공데이터 포탈을 통해 대부분의 데이터를 제공받을 수 있다는 사실을 알게 되었다.

 

또한, 이때까지 했던 프로젝트들이 단기성 프로젝트 였다면 이번에 진행했던 모아도 프로젝트는 약 두 달동안 진행되어 기존에 경험했던 프로젝트들 보다 기간이 길었다.

 

기간이 길었던 만큼 더 많은 기능들을 완성도 높게 구현할 수 있었다.

 

2. 배운 점(Learned)

이번 프로젝트에 백엔드 리드개발자 역할을 맡았다.

 

나는 부족한 점이 많다. 하지만, 다른 팀원들보다 비교적 경험이 많았고 그 경험들을 통해 느꼈던 시행착오 등을 팀원들과 공유하기 위해 리드개발자를 하게 되었다.

 

내가 협업을 하며 느꼈던 시행착오는 "방향성"이었다.

 

어떤 역할이 주어졌을 때, 어떤 것 부터 해야 하며 내가 하고 있는 것이 맞는 것인지 의문이 든 적이 있었다.

 

그런 상황에서 내가 노력한 부분은 "왜 내가 이 역할을 해야 하고, 어떤 부분이 내 역할에서 중요한 것인가"를 떠올리는 것이었다.

 

기획 단계에서 계획된 기능들은 매우 많을 것이다. 

 

이 많은 기능들중 어떤 기능이 핵심이고, 우선순위를 가지는지 파악하는 것이 중요하다고 생각한다.

 

따라서, 이번 프로젝트에서 팀원들에게 이런 나의 시행착오를 공유하고 "방향성"을 잡을 수 있도록 돕기 위해 노력했다.

 

이 과정에서, 나 또한 "이 프로젝트에서 왜 백엔드가 필요한 것인가"에 대한 고민을 하게 되었다.

 

공공API가 있고 프론트엔드에서 직접 요청을 보낸 후, 데이터를 받아올 수 있고 로그인 기능을 만들지 않았기 때문에 사용자의 정보를 저장할 일도 없는데 백엔드가 왜 필요한가에 대한 고민이었다.

 

이 고민을 해결하기 위해 무작정 의료정보 공공데이터를 받아와 봤다.

 

단순히 브라우저에서 받아오기만 하는데 브라우저가 버티지 못하고 강제로 종료되었다.

 

이후 간단한 임시 서버를 만들어 데이터를 받아오니 전체 데이터가 수만건이었다.

 

여기서 우리가 맡은 역할의 "당위성"과 "방향성"을 찾게 되었다.

 

이 프로젝트에서 백엔드는 "수 많은 데이터를 받아오고 사전에 가공하는 작업을 위해 필요한 것"이라는 생각이 들었다.

 

또한, 목적이 정해졌으니 "의미있는 데이터의 선별과 가공"이라는 방향성도 함께 정해졌다.

 

나는 나의 생각을 팀원들과 공유했고, 팀원들은 나의 생각에 동의하고 열심히 따라와 주었고 성공적으로 우리의 역할을 완료할 수 있었다.

 

이 프로젝트를 통해 다시 한 번 자신의 역할에 대한 "당위성"과 "방향성"에 대한 인식이 중요하다는 점을 배우게 되었다.

 

3. 부족했던 점(Lacked)

공공데이터를 이용해 받아온 데이터를 가공하는 과정이 효율적이지 않다고 생각한다.

 

병원의 경우 운영 시간에 대한 데이터만 10개 이상 받아오게 되는데, 이 많은 데이터를 일일이 for문을 돌리고 그 안에서 if문을 사용해 운영 시간이 없는 경우를 확인했다.

 

이 방법보다 더 효율적인 방법이 있을 것 같지만 지금의 나로서는 저 방법이 최선인 것 같다.

 

전체 의료시설 정보를 약 70,000개 정도 받아오게 되었는데, 저 방식으로 데이터를 가공하는데 약 5분이 걸렸다.

 

사용자 또는 프론트엔드 측에서 실수로라도 해당 주소로 접근하여 업데이트가 진행되는 것을 방지하기 위해 해당 경로를 주석처리 했다.

 

의료시설 정보에 변경이 생겨 데이터를 업데이트 해야 한다고 하면, 관리자가 직접 주석을 해제하고 데이터를 업데이트 하는 동안 서버를 중지시켜야 한다는 단점이 존재한다.

 

4. (스스로 에게)바라는 점(Longed For)

알고리즘에 대한 공부를 해야겠다는 생각이 들었다.

 

이때까지는 많지 않는 데이터를 이용했기 때문에 시간복잡도 등을 신경쓰지 않아도 됐었다.

 

하지만, 이번 프로젝트를 통해 알고리즘에 대한 지식이 중요하다는 생각이 들었고, 아는 만큼 효율적인 백엔드 구성이 가능할 것 이라는 생각이 들었다.

 

따라서, 이 프로젝트 이후 꾸준히 알고리즘에 대한 학습을 해야 겠다는 생각이 들었다.