이번에는 작년 4월부터 시작하여 8월 말 마무리를 한 AR을 이용한 위치기반 서비스 모바일 앱 Capsule Time에 대한 회고를 포스팅 하고자 합니다.

Capsule Time github

1. 시작 그리고 기획 📄

작년 4월 1학기 졸업 작품을 만드는 것을 목표로하는 캡스톤 디자인 수업을 듣게되었다. 팀은 바로 직전 학기에 컴퓨터공학설계 수업에서 같이 마르코 프로젝트를 진행한 멤버와 그대로 이어서 진행하였다. 여기까지는 아주 순조롭고 기분이 좋게 잘 진행이 되었다. 하지만 뒤에서 내용이 나오겠지만 우리 팀은 기획부터 마무리까지 계속해서 문제에 부딪혔다.

어떤 재밌는 걸 만들까 들뜬 우리 팀은 여러가지 아이디어를 생각하고 모여서 회의를 진행하도록 계획을 세웠다. 거듭해서 회의를 진행했고 어떤 걸 해야할지 머릿속에 꽂히는 것이 하나도 없었다. 그러던 중에 하나의 모바일 앱을 발견하였는데 바로 사이버 폭력 백신 앱이였다.

사이버 폭력 백신 App

고등학생의 입장에서 나의 폰이 학생의 폰이 되어 사이버 폭력을 경험해보는 체험 앱이였는데, 실제 피해자 고등학생이 된 것과 같이 느껴볼 수 있었다. 우리 팀은 이 앱을 가지고 여러가지를 얘기를 하였는데 그 중 하나의 아이디어가 떠올랐다. 사이버 폭력의 주제를 스토커로 바꾸어서 스토커에 관련된 시나리오를 만들고 그 시나리오를 체험할 수 있는 앱을 만들어보는 것이었다. 이 아이디어를 떠올린 밤, 우리는 여러 자료들을 수집했고 신나서 여러가지 시나리오를 밤새 얘기를 했다. 어떤 내용이 확 와닿게 할 수 있을 지 생각하고 다 같이 읽어보기도 했다. 그렇게 시나리오를 마무리 하고 다음 회의에서는 어떤 언어로 어떻게 개발할 지에 대해서 조사하고 어느 것을 공부하기 시작해야하는 지 알아보고 얘기를 해보기로 하였다. 그리고 나는 하나씩 조사를 진행했는데, 조사를 진행하면 할 수록 이 아이디어를 구현하기 위한 내용이 별게 없었다. 그렇게 조사를 진행하면서 이 아이디어가 졸업 작품 수준의 내용이 아니라고 생각이 들었고 아쉬운 점이 많이 느껴졌다. 다음 회의 시간이 되고 내가 들었던 생각을 팀원들에게 얘기를 했다. 그리고 팀원 모두의 의견이 무언가의 내용이 추가 된다거나 새롭게 아이디어를 만들어야 된다는 식으로 흘러갔다.

상황이 이렇게 되자 스토커 앱의 시나리오와 이전 아이디어 회의에 대한 시간적 비용이 많이 부담스러웠다. 하지만 그렇다고 계속 이 아이디어 내용만으로 진행하기에는 아쉬움이 너무 많았다. 서로의 생각을 얘기해보았고 우리 팀 모두의 의견이 공부 기간과 개발 기간의 여유도 중요하지만 보여주고자 하는 아이디어 기획이 가장 중요하다는 생각이었다. 그렇게 다시 아이디어 회의를 돌입했다. 이전만큼 여유롭게 아이디어를 회의를 할 수 없기 때문에 3일을 연속으로 계속 만나기로 하였다. 그렇게 3일 동안 거의 12시간 씩은 붙어서 회의를 진행하였고 마지막 3일 차에 타임 캡슐이라는 내용으로 얘기가 시작되었다.

팀원 중 한명이 타임 캡슐 내용을 꺼내었다. 나는 그 내용을 듣자마자 재미있을 것 같은 느낌이 들었다. 그래서 몇개의 의견을 내보았는데 직접 묻는 것과 같이 위치 기반 서비스를 이용하는 것들이였다. 다들 한 두개의 의견을 내기 시작했고 AR이라는 키워드가 생겨나게 되었다. 이렇게 팀원 모두가 만족할만한 아이디어가 탄생하게 되었고 구체적인 기획을 시작했다.

다 같이 시장 조사와 여러 기사들을 검색해보기 시작했고 모두가 만족한 아이디어라 그런지 구체적인 기획은 금방 진행이 되었다. 자료 조사가 끝난 후 먼저 어떠한 시나리오로 타임 캡슐을 심고 열람하고 할 수 있는지 얘기를 진행했고 어떤 것을 강점으로 만들 수 있는지 회의를 했다. 강점, 약점, 시나리오 등을 모두 정리를 끝으로 회의를 마무리했다. 그리고 설계 부분은 어떤 것을 공부해서 구현할 수 있을 지 조사해보고 다음 회의때 얘기해보기로 했다.

2. 설계(Design) 📝

회의 시간이 되고 우리 팀은 먼저 개발 기술 설계 이전에 필요한 앱 화면이 어느 것이 있고 앱 화면이 흘러가는지 전체적인 사용 흐름을 작성했다. 어떤 페이지가 필요할 지 생각해본 내용은 다음과 같았다. 로그인과 회원가입 화면, 자신의 타임 캡슐과 타임 캡슐의 날짜 등을 확인할 수 있는 화면, 지도로 확인할 수 있는 화면, AR로 직접 캡슐을 볼 수 있는 화면, 개인 프로필과 설정 화면이 필요했다. 그리고 이것을 토대로 아이패드를 이용해서 흐름을 작성했다.

설계 스케치

전체적인 화면을 작성하니 어떤 화면에 어느 것이 들어가야할 지 보이기 시작했다. 그래서 다음으로 구체적으로 화면에는 어떤 것들이 있어야 하는지 와이어 프레임 형태로 스케치를 진행했다. 와이어 프레임을 하다보니 생각보다 해야할 것이 많았다. 그리고 추가하고싶은 다른 기능들이 떠올랐는데 하다보니 너무 방대해졌다. 그러다가 결국 덕지덕지 붙인 첨가물들을 다 제거하고 우리 아이디어의 장점을 최대한 살리는 방향으로 계속 이어나갔다.

기술 설계도

계속해서 팀원들과 어떤 프레임 워크와 도구들을 이용해서 개발을 할 지 얘기를 해나갔다. 이전 회의에서 어느 부분 개발을 맡으면 좋은 지에대해 서로 얘기를 나누었었는데, 서버와 AR, 모바일 앱으로 나뉘었었고 그 중 나는 서버를 맡았었다. 그래서 이번 회의에 node js와 mysql를 이용한 rest api 서버를 얘기를 꺼냈고 서버는 이걸로 진행하게 되었다. 이어서 모바일 앱은 react native와 java를 고민했었는데, react native로 개발을 하는 것보다 이전 프로젝트에서 경험이 있던 java를 선정하였다. 그리고 AR 개발로는 ARCore를 사용할 수 있는 unity를 선택했다. 이렇게 전체적인 기술 스택이 순조롭게 결정이 났다. 하지만 문제가 있었는데 우리 모두 이 기술 스택과 rest api에 경험이 없다는 것이었다. 그래서 rest api와 DB 같은 경우 내가 빠르게 여러가지 테스트 개발을 진행해본 다음 어떻게 진행하면 좋을지 DB 스키마는 어떤 식으로 구성하면 좋을 지에 대해서 그때 끄때 얘기해보는 식으로 하게되었다. 그리고 다음 회의까지 각자 최대한 공부를 하고 몇몇 기능에 대한 프로토타입을 만들어오기로 했다.

3. 개발(Development) 🧑‍💻

드디어 기획이 끝나고 개발에 돌입하기 시작했다. 나는 rest api 개발을 맡았기 때문에 rest api 가 무엇이고 어떻게 통신을 해야하는 지, 어떤식으로 구성하여 코드를 짜면 좋을 지에 대해 공부를 하고 테스트 코드를 뽑아보는 방식으로 개발을 진행했다.

첫 번째는 nodejs가 어떤 것이고 어떻게 하면 서버를 만들 수 있는 지에 대해 공부를 했다. 이것 저것 구글링을 했고 express라는 것을 알게되었다. javascript 문법에 대해 하나도 모르는 나였기에 처음에 찾고 공부하고 하는 이 과정이 너무 어려웠다. nodejs를 검색해서 알아보면 javascript가 나오고 여러 nodejs 튜토리얼 코드들은 최신 js 문법과 이전 js 문법이 섞여 있었다. 이런 어려움을 부딪힐때마다 너무 힘들었다. 하지만 튜토리얼 코드가 왠지 모르게 동작을 하고 내가 원하는 대로 만들고나서 이런 힘든 내용들은 모두 잊게되었다. 이 과정에 푹 빠져서 "아 왜 안되지.." "오 됐다 !!" 를 반복하면서 밥 먹는 것을 잊고 하루에 12시간씩을 개발에 집중한 적도 있었다.

이렇게 개발을 하다보니 express를 이용해서 어떻게 URL을 나누고 route 하는 지, mysql과 연결하여 하는 지를 알게 되었고 가장 필요하다고 생각한 DB 내용을 모델링을 해보았다.

최종 DB 모델링(ERD)

여기까지 진행을 하고 다시 회의 시간이 되었다. 이번 회의때 모두가 어느 부분까지 공부와 개발을 하고 나온 결과가 어떤 것인지 공유를 했고 진행하면서 어려운 점에 대해서 얘기를 나누었다. 나는 서버 부분에서 rest api를 이용하여 어떻게 정보를 주고받는지에 대한 전체적인 틀을 설명했고 어떻게 통신해야 할지에 대한 내용을 말하여 방법을 결정했다. 그리고 다음 회의 전까지 어느 내용까지 해야할지를 정했는데 이 때부터 안드로이드 App에 같이 참여하게 되었다. 안드로이드 App 개발을 맡은 팀원이 어려움을 느끼기도 했고 rest api를 개발하고 테스트 할 때 안드로이드 App 개발을 같이 진행하면 좋기 때문에 그렇게 진행하게 되었다.

Api 개발 시작

회의가 끝나고 나는 안드로이드 Java에 대해서도 공부를 하기 시작했다. 이미 node js에서 어려움을 많이 부딪혀서 그런지 Java 공부에서는 비교적 어려움이 덜 느껴졌다. 먼저 로그인과 회원가입 기능을 구현하는 것부터 시작을 했다. 레이아웃을 만들고 retrofit2를 이용해서 url에 원하는 요청을 하는 식으로 진행을 했고 받아온 유저 정보가 DB와 같은 지(로그인) 확인 하는 EndPoint와 user 정보를 받아와 DB에 저장하는(회원가입) EndPoint, 유저 정보를 수정하는 EndPoint, 삭제하는 EndPoint를 rest api로 구성을 완료했다. 이렇게 Json을 이용해서 rest api로 통신하는 시스템을 익히고 나니 다른 것들도 금방 할 수 있을 것 같은 느낌이 들었다.

회원가입

다음으로는 감이 전혀 안잡혔던 이미지를 주고 받는 api를 만드는 작업을 시작했다. 해본적이 없던 부분이였기 때문에 이미지는 바이너리이기 때문에 Json에 내용을 채워넣듯이 할 수 없고 다른 방식이 있겠지 하고 생각을 하고 있었다. 하지만 여러가지를 구글링해서 알아보았는데, 이미지는 이미지 서버에서 URL을 통해서 주고 받는 것이였다. 그리고 어떠한 타입으로 주고 받는지 알아보았는데 mime을 사용하여 jpg와 png 등을 주고 받을 수 있는 것을 발견할 수 있었다. 발견하고 후에는 postman을 이용해서 파일을 전송하고 서버에서 전송을 받아 저장하는 것은 쉽게 할 수 있었다. 하지만 안드로이드 앱에서 문제가 생겼다. 첫 번째는 폰에 저장된 사진을 불러오는 부분이였다. 예제 코드를 따라서 하는데 안드로이드 버전이 올라가면서 보안이 업데이트 되었고 예제랑은 다른 경로를 통해 사진을 불러와야 하는 문제였다. 여차저차 문제를 해결하고 나니 두 번째 문제에 부딪혔는데, 사진을 폰으로 직접 찍어서 받아오는 부분이였다. 이 부분 또한 안드로이드 버전이 올라가면서 문제를 일으킨 것 이였다. 그리하여 시행착오가 지나고 회원가입이 완료가 되었다.

회원 가입을 완료하고 나니 중간 발표까지 3주 정도가 남게되었다. 하지만 우리 팀의 목표 기능까지 해야할 일이 4가지 정도가 남아있었고 지금까지 개발 속도로 보았을 때 시간이 빠듯했다. 4개의 내용은 다음과 같았다.

  • 남은 부분
    1. 캡슐 로그 만들기
    2. UI-UX
    3. Capsule Map
    4. AR, 캡슐 맵, 내 부분 통합
    5. 결과 ppt 만들기

나는 먼저 캡슐 로그 만들기를 진행을 했다. 안드로이드 부분과 캡슐 로그 부분을 둘 다 만들어야 하다 보니 시간이 꽤나 오래 걸렸다. 처음에는 api 작업을 먼저 진행했다. 타임 캡슐 정보를 의미하는 캡슐 로그에 대한 get, post, put, delete를 모두 만들어야 했는데, 로그인과 회원가입을 만들 때 사진 정보를 보내는 작업의 경험이 있다보니 수월했다.

캡슐 로그 기능

캡슐 로그 Api

get 같은 경우 캡슐 로그를 보는 곳에도 필요하지만 다른 팀원이 작업중인 AR 부분에서 몇 미터 이내에 캡슐에 대한 정보를 뿌려주는 api도 필요하고 지도에서 모든 캡슐의 위치를 보는 부분도 필요해서 추가적으로 더 작업이 필요했다. 안드로이드 작업 부분 또한 이미 통신 작업을 했던 경험이 있고 화면에 리스트를 보여주는 기본적인 코드 튜토리얼이 인터넷에 많이 있어서 어려움이 없었다.

UI/UX 개발

로그인과 캡슐 로그 부분이 끝나는 동안 원래 안드로이드 앱 부분을 맡았던 팀원이 GUI 디자인을 진행하고 있었고 나는 캡슐 로그 기능이 구현됨과 완성된 GUI를 갖고 UI/UX 작업을 진행했다. 이 작업에서 레이아웃에 대한 비율 개념이 없었던터라 고정된 픽셀 값으로 마진, 패딩등을 작업을 해서 나중에 전체적으로 다시 수정한 기억이 있다.

이제 남은 기간은 단 몇 일뿐이었는데 여러가지 문제가 있었다. 하나는 캡슐 맵이 완성이 되지 않는 것이였다. 다른 팀원 한 명이 맡은 개발 부분이였는데 비교적 러닝커브가 높았던 나에게 SOS 요청이 들어왔고 결과적으로 같이 새롭게 만들어서 해결을 했다.

다른 문제는 우리 팀의 작업 결과물은 총 3가지로 분리되어 있다는 것이였다. 캡슐 맵, 로그인과 캡슐 로그, AR 이렇게 3가지 였는데 캡슐 맵과 로그인,캡슐로그 부분은 같은 개발 환경에서 진행한 작업물이라 쉽게 합칠 수 있었는데, AR은 유니티 3D로 개발이 되었기 때문에 JAR 파일로 export하여 붙이는 작업에서 애를 굉장히 많이 먹었다. 이렇게 우리 팀은 엄청나게 밤을 새가면서 간신히 목표 기한까지 맞추어 위에 5가지 남은 부분 작업을 모두 끝맞칠 수 있었고 중간 결과 발표를 뿌듯한 마음으로 할 수 있었다.

중간 발표 결과 PPT

4. 두 번째 Cycle과 버그 픽스 🛠

중간 발표에서 우리 팀은 더 추가 개발할 기능 내용으로 아래에 내용을 발표했다.

  1. 개인설정 기능
  2. 댓글 기능
  3. 친구 기능
  4. 유저 검색 기능
  5. 캡슐 맵 클러스터링

발표가 끝나고 교수님과 다른 팀 학생들로부터 여러 피드백을 받을 수 있었는데, 그 중 하나는 친구 기능이 굳이 필요한 이유 에 관한 피드백을 받았다. 발표가 끝나고 우리 팀은 받은 피드백을 바탕으로 이 내용에 대해서 회의를 했는데 결론은 우리 어플에서는 친구 기능을 굳이 만들 이유가 없었다. 그래서 우리 팀은 친구 기능을 넣고자 했을 때의 생각으로 다시 돌아가서 생각을 시작했다. 우리 팀이 친구 기능을 생각한 목적은 타임 캡슐을 혼자 만들 수 있겠지만 친구들과 특별한 추억을 공유하기 위함이었다. 잊고 있었던 핵심 목적을 다시 떠올릴 수 있게 되었고 그러기 위해서 친구 기능을 어떻게 활용하면 좋을 까 에 대해서 이야기를 나누어 보았다. 이야기가 된 내용으로 최종적으로 친구와 같이 타임 캡슐을 묻고 동일한 시점에 같이 열어볼 수 있는 기능을 떠올리게 되었다.

두 번째 설계 스케치 일부

회의를 계속 이어나아가서 위에 5가지의 기능을 하나하나 다시 살펴보기 시작했다. 그리고 이 기능에 대해서 "우리가 생각한 내용이 어떤 것인지", "구체적인 기능의 내용이 어떤 것인지" 의 내용을 정리를 했고 결과적으로 어떻게 시퀀스를 설계할지 아이패드로 그려서 내용을 정리를 마무리 했다.

두 번째 사이클의 설계가 끝나고 다시 개발 작업에 들어가게 되었다. 첫 번째 사이클의 설계가 튼튼하지 못했던 탓인지 이전에 개발했던 코드들의 부족한 점이 보이기 시작했고 팀원들이 개발을 진행하는 도중에 Api의 버그들이 발견하기 시작했다. 버그를 고치기 위해 변경된 내용과 문제가 발생할 수 도 있는 내용을 리포트로 공유를 하여 버그를 수정했다. 이것과 동시에 새로운 기능의 개발을 진행하였고 첫 번째 사이클처럼 어떻게 구현해야하지? 의 내용보단 문제가 없이 구현하는 것에 집중을 하면서 개발을 진행했었던 것이 기억이 난다.

현재까지 rest Api 서버와 Blob Storage 서버를 개인 PC로 이용하고 있었는데, 중간 중간 자리를 비우게 되는 경우가 생기게되어 아마존의 클라우드 서비스인 AWS EC2를 freetier로 사용하는 것을 고려하게 되었다. 단순히 AWS에 nodejs와 mysql 등을 설치하여 서버를 구성할 수도 있었지만 Docker를 접해볼겸 Docker를 이용해서 서버의 내용을 옮겼고 클라우스 서비스에 서버 구성을 하는 것으로 개발이 끝나게 되었다.

5. 프로젝트 마무리

최종 App 화면

개발이 끝난 후 우리 팀은 완성된 내용을 잘 정리한 ppt와 아이템을 소개하는 UCC, 포스터를 만들었고 최종 발표를 잘 마쳤다. 또한 교수님의 추천으로 캡스톤 디자인 경진대회와 IT 서비스 학회에서 추진하는 졸업작품 논문에 capsule time을 선보였다. 캡스톤 디자인 전시회를 끝으로 프로젝트는 성공적으로 끝이났고 캡스톤 디자인 전시회 장려상, IT 서비스 학회 졸업작품 논문 우수상의 결과를 내었다.

수상 내역

6. 나의 생각

이 프로젝트를 진행하면서 당시에 많은 성장을 이뤄내었다. 자바스크립트와 자바를 다룬 적이 없던 내가 기획한 내용대로 개발을 완료했다는 사실이 많이 뿌듯했다. 개발 실력의 성장 말고도 협업하는 것에서 많은 것을 경험 할 수 있었다. 부족한 실력으로 프로젝트를 리드해나가야 했는데 많은 어려움에 부딪혔고 이것이 나를 더 강하게 성장시켰다. 기획 단계의 요구사항분석과 내용을 정리하고 관리하는 것, 다 같이 개발할 내용(시퀀스)를 만드는 의사소통, 다음 단계로 나아가기 위한 단계별 기간 설정, 혼자가 아닌 같이하는 개발에서의 발생하는 문제 등에 대해서 배울 수 있었다.

회고록을 적으면서 몇가지 생각이 들었다. 하나는 현재 42서울 과정에서 동료 학습이라는 것을 알아가고 있는 상황인데, 이 프로젝트에 적용했으면 좋았을 것 같은 내용들이 생각이 들었다. 시퀀스를 다 같이 만들 때, 시퀀스 다이어그램을 제대로 작성하여 모두가 내용을 정확히 공유하는 등에 대한 내용들이 부족했던 것 같다. 이 프로젝트에서는 시퀀스 다이어그램까지 작성을 하지 않고 아이패드로 자료를 공유하는 방식을 하였었는데 나중에 다시 회의를 해야되는 문제가 생겼었던 것들이 생각이 났다. 다른 하나는 구글 스토어에 배포를 할 수 있을 정도로 만들어 봤으면 어땠을 까 하는 아쉬운 생각이 들었다.

앞으로 내가 성장해야할 점이 무엇인지 뚜렷해졌다. 협업을 잘 하기위한 스킬들이 많이 부족하다고 느꼈다. 다른 여러사람과 프로젝트를 진행하고 많은 의사소통을 하고 잘 기록하는 능력을 키워야겠다고 느꼈다. 또한, 실제로 배포를 해보는 프로젝트를 진행하는 것이 필요하다고 느꼈다. 실제로 배포된 프로그램을 관리하는 경험이 필요하다고 느꼈다.

⤧  Next post 42서울 오픈스튜디오 프로젝트 개발기 - 1 ⤧  Previous post ft_printf 구현하기