첫 iOS앱 Grain App Store 출시 후기

약 삼 개월 반 정도의 개발 기간을 거쳐 세상 밖으로 나온 우리 앱!! Grain 후기를 적어보고자 한다.

결론부터 말하자면 앱 자체는 실패지만 성공적(?)인 경험이었다고 생각한다.

당당하게 앱스토어에 있는 Grain

개발 과정에서의 어려웠던 점

우선 시작부터 다사다난했다. 세 가지 정도 큰 이슈가 있었는데 첫째로 앱 볼륨을 줄이기 위해 API가 아닌 Url session 을 사용하여 데이터 통신을 하고자 하였고 그것을 익히기 위한 leaning curve로 인해 개발 due date 을 맞추는데 매우 매우 빠듯한 나날들이었다. 그냥 API를 사용할 걸 그랬나 백번 후회하던 나날들… 하지만 우리 팀원들의 노고 덕에 성공적으로 해냈지만 이것은 고난의 시작이었다. 첫 번째 문제는 해결했지만 생각보다 SNS 앱은 뷰마다 연동되어 있는 데이터들이 서로 거미줄처럼 얽혀 있는 경우가 많았고 이것은 우리의 기존 데이터 구조 설계를 훨씬 웃도는 일었기 때문에 기존의 구조를 뒤집어엎기를 몇 번을 반복해야 했다.

어느 정도 정리되었다고 생각했지만 SNS 앱인 만큼 사용자가 무언가를 입력하면 바로바로 데이터에 반영이 되어야 하는데 같은 방법을 사용해도 어떤 뷰에서는 되고 어떤 뷰에서는 안되는 문제점을 발견했다. 이 문제 때문에 몇 주를 고생했는지 모르겠다. 우선 원인부터 말하자면 앞서 말한 거미줄처럼 얽혀있는 데이터 구조 때문에 뷰가 점점 쌓여가고 뷰 자체가 지니고 있는 데이터 계층구조의 문제 때문에 서로 제대로 된 참조를 하지 않고 있었다. 다시 말하자면 데이터가 몇 겹으로 쌓이면서 보기엔 같아 보이지만 서로 다른 데이터 덩어리를 참조하고 있었기 때문에 바로 반영이 안되었던 것이다. 우리는 MVVM 아키텍처를 사용하였기 때문에 firebase에 저장된 데이터를 entity 형태로 받아오고 이것을 viewModel 을 거쳐서 view에 보여주는 구조를 하고 있는데 이 과정에서 view와 viewModel 사이에 참조 형태로 데이터를 주고받는다. 이 과정에서 viewModel의 가공된 데이터를 observableObject 프로토콜을 선언하여 publish 하고 상위 뷰에서부터 하위 뷰로 필요에 따라 StateObject, evironmentObject, observableObject로 참조 받아서 하위 뷰로 넘겨주는 형태를 하고 있다. 따라서 하위 뷰의 데이터는 viewModel과 직접적으로 데이터를 주고받는 것이 아닌 상위 뷰를 한 단계 거치게 되는데 이 과정에서 우리는 일부 데이터를 let 즉, 상수의 형태로 주고받았다. 단순한 구조에서는 문제가 보이지 않았지만 점점 구조가 심화되면서 입력한 값들이 바로 반영이 되는 것이 아닌 한번 나갔다가 들어와야 하는 문제가 생겼다. 따라서 우리는 초반에는 onChange modifier를 이용하여 하위 뷰에서 작동하였을 때 상위 뷰의 데이터를 fetch 하는 방식으로 일종의 꼼수(?)를 사용하여 해결했지만 일부 뷰에서는 이것조차 먹히지 않았다. 결국 제대로 된 참조의 형태로 우리가 데이터를 주고받고 있지 않다는 것을 깨닫고 상수의 형태가 아닌 ObservedObject 프로퍼티 래퍼의 형태로 모두 수정하여 이 같은 문제를 해결했다.

마지막 큰 이슈는 바로 애플 심사 리젝트! 나름 신경 쓴다고 썼는데 아래와 같은 사유로 리젝트 되었다.

SNS 앱의 경우 문제가 있는 게시물을 게시할 경우 문제가 되거나 차단당할 수 있다는 강력한 경고 문구를 언급해야 하고 유저가 게시물을 신고할 수 있는 신고 기능 그리고 상대 유저를 유저가 직접 차단하는 기능을 포함해야 했다. 앞의 두 가지의 경우에는 크게 어려운 부분은 아니었기에 쉽게 구현했지만 차단이라니… 단순히 말해 기능 하나지만 앞서 말한 매우 복잡한 데이터 구조 안에서 차단한 유저의 정보를 걸러내고 차단당한 상대방의 계정에서 나의 정보를 볼 없게 하는 일이기에 정말 막막했다. 여러 가지 방법이 있겠지만 우리는 차단한 유저가 올린 게시물을 filter 하는 방식을 사용했다. 내가 차단을 하는 순간 DB 상의 상대방의 차단한 사람 컬렉션에 내 아디가 들어가고 내가 차단한 사람 컬렉션의 상대방의 ID가 들어가며 해당 유저가 게시한 게시물 중 눌렀던 좋아요 와 저장된 글을 모두 삭제한다. 그리고 해당 과정이 버튼을 누름과 동시에 바로 반영이 되어야 하는데 우리는 Google Firebase를 사용하였기 때문에 noSQL 형태의 DB에서 이러한 작업을 해내기가 매우 까다로웠다. 그 과정까지 기록하기에는 책 한 권을 써도 부족할 만큼 지루하고 긴 작업이기에 생략하지만 고된 작업 끝에 우리는 차단 기능을 성공할 수 있었다.

그 외에도 디자이너의 부재로 10번도 더 바뀌었던 디자인 콘셉트와 앱 아이콘, 지도의 POI(Point of Interest)를 제공하지 않아 우리가 직접 Place 정보를 수집하고 모아야 했던 일, 제대로 된 style guide 와 design system 없이 작업해서 중구난방이던 코드와 디자인 통일 작업을 했던 일, 데이터가 20개 이상 안 불러와져서 재귀 함수를 이용해서 해결했던 일, 출시했는데 로그인에 오류가 있던 일 등 정말 수도 없이 많은 고비들이 있었다. 하지만 팀원들과 같이 힘을 합쳐 무사히 출시를 할 수 있었다.

개발 외적 아쉬움

​ 많은 고민을 하고 제작했지만 많은 부분들이 부족했다. 핵심적으로 우리가 생각한 문제는 다음과 같다.

1. 사용자가 이미 instagram이 있는데 굳이 Grain을 이용할 이유를 찾지 못했다.

SNS를 하는 일은 생각보다 많은 에너지가 소모되는 일이다. 하나의 게시물을 올리기 위해 수십 장의 사진을 찍고 그것을 보정하고 적절한 글과 해시태그와 함께 게시를 하고 그것의 반응을 살피는 일은 결코 짧은 시간 안에 하기 힘든 일이다. 하지만 networking의 목적으로 그러한 수고스러움도 마다않고 수많은 사람들이 SNS를 한다. 우리의 앱은 “필름 카메라 사용자를 위한”이라는 조금의 차별점은 존재하지만 그것은 우리 앱이 차지할 수 있는 케파의 범위가 아닌 instagram 사용자와 상당 부분 겹치는 교집합의 영역이었다는 것을 간과했다. 누구라도 충분히 알 수 있는 부분이었지만 우리는 기술적인 부분에 매몰되어 간단한 문제를 파악하지 못한 채 이어갔다.

2. SNS의 본질과 필름 카메라의 성질을 제대로 파악하지 못했다.

우리 앱의 콘셉트 상 앱의 게시물은 오롯이 필름 카메라로 찍은 사진을 올려야 한다는 콘셉트 하에 제작되었다. 하지만 우리의 앱은 사용자가 올리는 게시물을 ‘필름 카메라로 찍은 사진’으로 제한할 명분도 방법도 없는 상태에서 그저 콘셉트만 가지고 제작되었다. 사용자가 만들어가는 앱의 의미를 강조하고자 화이트 앤 블랙으로 심플한 디자인으로 바꾸어놓고 정작 필름 카메라만 올리세요라고 하니 모순이 생긴 것이다. 그리고 직접 게시물도 올리고 여러 가지 시도를 위해 필름 카메라를 사서 사진을 열심히 찍어봤지만 생각보다 필름 한 롤을 채우는 일도, 그것을 인화하러 가는 수고를 감수하는 일도, 고성능 스마트폰을 두고 매번 비싼 값의 필름을 구입해 사진을 찍는 것도 마냥 쉬운 일이 아니고 긴 시간을 요한다는 것을 느꼈다. 이것은 우리 앱의 게시물 업로드 주기, 소위 말해 1일 1스타라는 하루에 게시물 하나를 올리는 일은 꿈도 꿀 수 없는 것이다. 적은 게시물과 사용자는 SNS의 흥미를 떨어트릴 수밖에 없는 요소로 작용하였다.

3. 기술의 성숙의 부족과 인간 중심의 개발의 세 가지 요소의 균형 부족

새로운 기술은 초기에는 부족한 기술에 대한 욕구를 충족시켜주기를 원한다. 즉 기술을 중요시한다는 것이다. instagram은 초기에 DM 기능도 스토리 기능도 없는 그냥 사진에 필터를 적용해서 올리는 그저 그런 심심한 앱에 불과했다. 그래서 기존 facebook을 더 많이 이용했다. 하지만 여러 가지 기술들이 추가되었고 초기 사용자들의 앱 사용의 숙달과 일반 사용자가 원하는 성능의 수준에 도달하였을 때 비로소 인간 중심의 개발의 세 가지 요소가 균형을 이뤄야 한다. Donald Norman에 의하면 기술, 마케팅, 사용자 경험이 성숙한 소비자 중심의 제품을 개발하는 단계에서 요구되는 세 개의 버팀목이라고 표현하고 있다. 하지만 우리의 앱은 기술의 성숙을 요하는 단계에서 정체된 채 멈춰있었고 기술과 사용자 경험을 위주로 개발을 하긴 했지만 마케팅적인 측면을 외면하고 있었던 것은 분명한 사실이었다. 즉 세 가지 요소의 균형도 기술적인 성숙도 아직 이뤄지지 못한 채 멈춰버린 앱이 되어버린 것이다.

결론

이러한 문제들과 어려움을 겪으면서 Agile process의 중요성을 여실히 느꼈다. 우리는 waterfall model에 너무나도 익숙해져 있어서 앱의 방향성이 아닌 앱의 완성된 형태를 예상하고 개발을 하게 된다. 하지만 쉬운 문제도 내부에서는 보이지 않을 때가 너무나도 많다. 그리고 급변하는 트렌드와 사용자들의 니즈 그리고 성능의 향상에 실시간을 발맞춰나가지 않으면 살아남을 수 없다. 직접 느끼는 문제에 직면하기 전까지 어떠한 수정도 없이 그저 우리의 계획대로 달려왔기 때문에 완성하고 출시한지 며칠 만에 무언가 잘못됐음을 인지하였다. 하지만 그 과정에서 얻을 수 있었던 것도 상당히 많았다. 우선 앱을 출시까지 했다는 경험, 여러 가지 기술적인 시도, 앞으로 앱을 만들 때 이번과 같은 시행착오를 피할 수 있는 방법들을 익혔다.

우리는 결과물에 집착하고 실패를 두려워한다. 한 번에 성공하기를 바라지만 이것은 분명 우리에게 독이 되는 생각일 것이다. 분명한 guidline과 체계를 만들고 그것 안에서 끊임없이 검증하고 수정하며 발전해나가는 과정이 함께한다면 한 번에 성공은 아닐지라도 더 나은 방향으로 가고 있음에는 믿어 의심치 않는다.

앱스토어 링크