개요
- 기획
1) 아이디어 배경
2) 디자인
3) 데이터구조
4) 적용하고자 했던 기술 - 배운 점
- 데이터 스키마 구성
- 아쉬운 점
- 반복된 코드(제네릭의 필요성)
- 업데이트 방향
1) 반복된 코드 제거
2) 백업, 복구기능 추가
3) 통계탭 추가
4) 메세지기능 추가
22월 9월 7일부터 10월 5일까지 처음으로 앱의 기획에서부터 출시를 경험하였다. 경험을 보다 확실하게 기억하기 위해 회고를 진행하였다.
1. 기획
1) 아이디어 배경
-
이번 앱 아이디어의 시작은 아내로부터 얻을 수 있었다. 평소 피아노 개인레슨을 하는 아내는 수업은 어렵지 않지만, 그외 부가적인 일들이 번거롭다 하였다. 가령 예를 들어 레슨 완료 후 어머님들에게 비슷한 내용의 메세지(레슨비, 교제비 등 안내 문자)를 반복적으로 보내는 일이 번거롭다 하였다. 그래서 이러한 번거로움을 덜어줄 수 있는 앱을 만들어보면 어떨까 하는 것으로부터 시작되었다.
-
번거로움을 덜어주는 구체적인 방법으로 비슷한 내용의 문자를 템플릿으로 작성해 레슨이 완료될 때 메세지 버튼만 누르면 해당 템플릿이 작성된 화면을 띄워주는 것을 생각했다.
2) 디자인
-
이러한 안을 가지고 Figma를 활용해 구현될 앱의 뷰들을 구체화하였다. 머릿속으로 뷰의 구성을 생각했던 것과 달리 구체화보니 실제 필요한 앱의 구성 요소의 차이를 확인할 수 있었다. 단순하게 학생들의 이름이 표시되고, 이름을 누르면 메세지 화면이 켜지는 과정을 생각했었는데, 구체화 과정을 통해 학생 등록 화면, 메인 화면, 학생 세부정보 화면 등으로 구체화됨을 확인할 수 있었다.
-
화면 구성
| 1) 메인, 등록, 세부화면 |
|---|
 |
| 2) 캘린더 화면 |
|---|
 |
| 3) 세팅화면 |
|---|
 |
3) 데이터
-
뷰를 구체화 함으로써 각 뷰에서 다룰 데이터의 형식에 대해 고민해볼 수 있었다. 처음 기획 당시 다뤄야할 데이터에 대한 고려는 학생에 한정되었다. 학생정보만 표시함으로써 필요정보가 충분할 것으로 여겼다. 그러나 앞서 말한 구체화된 뷰마다 필요데이터가 나눠짐으로써 데이터구조가 세분화되었다. 학생정보, 레슨정보, 진행정보 등이 나눠질 수 있었다.
-
디자인과 데이터 구조를 잡으니 개발 공수기간을 세울 수 있었다.(이때까지만 해도 개발 공수 기간이 생각보다 여유 있다 생각했다.)
| 1) 데이터 구조 |
|---|
 |
4) 기술
사용하고자 한 기술은 다음과 같다.
- Realm
- Repository Pattern
- MVC
- SnapKit
- FSCalendar
- IQKeyboard
2. 배운 점
- 데이터 스키마 구성
-
처음 데이터를 구성할 당시 입력된 정보를 하나의 데이터 테이블로 구성하였다. 입력정보(이름, 주소, 연락처, 레슨 시작일, 레슨횟수, 레슨비)를 바탕으로 정보를 관리하는 것이 문제 없을 것으로 여겨졌다. 그러나 등록화면에서 넘어가 메인화면으로 표시될 때, 실제 필요한 정보는 입력정보 전체가 필요한 것이 아니었다. 세부정보 화면으로 넘어갈 경우 레슨 진행정보가 추가될 필요가 있었다. 캘린더 화면에서 레슨한 날짜를 추가하여 정보를 표시할 필요도 요구되었다. 뷰의 구성을 통해 데이터 구조 분할의 필요성을 알게 되었다.
-
그렇다면 한명의 학생에 대한 정보가 여러 테이블로 나눠질 경우 각 테이블간 일치 데이터를 어떻게 찾을 수 있을 것인가? 이 부분에 대한 고민이 가장 컸다. 테이블 간 고유의 값을 공유하고 있어야 고유 값을 기준으로 각 테이블에서 데이터 추출이 가능한 점이었다. 각 테이블에서 갖고 있는 정보를 살펴보면 고유 정보로 여기기 어려웠다. 예를 들어 이름은 동명이인이 있을 수 있다. 주소, 핸드폰 번호의 경우 같은 부모를 가진 학생 2명이 있을 수도 있다.
-
이에 대한 고민을 하던 중 realm 데이터 생성시 학생 테이블의 Primary key인 ObjectID를 다른 테이블(레슨, 진행정보)의 Primary key 로 사용하는 아이디어를 떠올렸다. 해당 Key값의 경우 생성시 고유 값으로 생성되어 다른 테이블에서 Primary key로 쓰더라도 다른 정보와 겹치지 않을 것이라 생각했다. 그러나 멘토와 팀원들의 피드백으로 통해 위 아이디어가 놓치는 점을 확인할 수 있었다. 테이블은 고유의 Primary 값을 가져야 하며, 그 값은 참조하는 형태가 되어서는 안된다. 참조의 부분은 Foreign Key를 통해 해결할 수 있는 점이었다. 각 테이블은 Primary key로 ObjectID를 갖되, 특별히 학생의 ObjectID를 레슨, 진행 테이블의 Foreign key로 가짐으로써 서로의 데이터를 참조할 수 있도록 구조를 만든 것이다.
-
이를 통해 각 뷰에서 데이터를 호출할 때, 각 뷰의 Foregin key 가 일치한 데이터만 뽑아 CRUD(생성 , 읽기, 업데이트 및 삭제)을 처리할 수 있게 되었다.
프로젝트 아쉬운 점
- 반복된 코드(제네릭의 필요성)
- 앱 출시를 통해 가장 크게 아쉬웠던 점은 반복된 코드를 많이 작성하였다. 작성된 코드를 보면서 스스로 이렇게 반복된 내용을 작성하면 안되는 줄 알면서도 시간의 부족함이라는 자기 합리화에 빠져 반복된 코드를 무척 많이 만들었다. 예를 들어 Repository Pattern을 사용함에 있어 각 테이블에서 공통적으로 사용하는 코드가 있다. fetch(), fetchFilter(), updateCheck(), deleteData() 등이 있다. 이러한 메소드의 매개변수의 타입을 제네릭으로 처리하면 단 3줄로 끝날 코드가 3번을 반복함으로써 9줄이 되었다. 제네릭에 대한 필요성을 절실히 느꼈던 순간이다. 이를 공부해보고 적용해봐야지 라는 생각이 들었음에도 그 순간은 빠르게 구현하는 마음이 앞서 이와 같은 실수를 저질렀다.
| 1) 반복된 코드 |
|---|
|
4. 업데이트 방향
- 처음으로 앱 출시를 진행하면서 공수기간에 대한 압박이 컸다. 특히 데이터를 처리하고 CRUD에서 생기는 오류를 처리함에 어려움이 있어 공수기간이 길어졌고 이에 따라 반복된 코드를 사용하거나, 추가하지 못한 기능이 많다. 이를 개선하기 위한 방향으로 업데이트를 진행하려고 한다.
1) 반복된 코드 제거
- 아쉬웠던 점에서 언급한 곳 외에도 많은 곳에서 반복된 코드를 쓰고 있다. 이처럼 반복된 코드를 없애는 방향으로 개선 방향을 잡고 있다.
2) 백업, 복구기능 추가
- 처음 기획 당시 백업, 복구기능을 포함시켰다. 그러나 공수 기간이 딜레이되고, 출시 기한을 맞추지 못하는 상황이 되어 우선적으로 심사 받기에 문제없는 상태로 구현하기 위해 백업, 복구 기능을 제외한 상태로 출시하게 되었다. 사용자에게 보다 효율적인 사용을 돕기 위해 백업, 복구 기능을 추가할 예정이다.
3) 통계탭 추가
- 현재 제공하고 있는 주요 기능은 메세지 기능이다. 그러나 기능이 단순하기에 앱의 의존성을 높이기 어려울 것으로 여겨진다. 주어진 데이터를 가공하여 사용자에게 추가적인 정보를 제공하고자 한다. 예를 들어 월별 수입, 일별 수입, 학생별 수입 등의 정보를 별도의 통계탭을 생성하여 제공한다면 앱 사용 의존성을 높일 수 있을 것이라 생각된다.
4) 메세지 기능추가
- 현재는 정해진 템플릿의 내용만 메세지로 첨부하여 제공한다. 사용자가 메세지 보내는 번거로움을 덜기 위해 제작된 앱이지만, 메세지를 받는 회원 역시 객관적인 정보를 받을 수 있다면 사용자에게 더 큰 도움이 될 것이로 생각된다. 사용자가 레슨 완료 후 체크하는 버튼 기능에 횟수 뿐 아니라, 레슨 내용을 추가로 기입하도록 한다. 추후 메세지를 보낼 때, 템플릿 내용 뿐 아니라 작성한 메모 내용을 스크린 샷으로 찍어 제공한다면 사용자와 더불어 회원에게도 필요한 정보를 제공하는데 도움을 줄 수 있을 것으로 생각된다.
