본문 바로가기

혼자 앱 개발하는 이야기

앱 출시하기 전까진 몰랐던 것들 - 혼자 앱 개발하는 이야기 #17

 

 

앱을 출시하고 나니 혼자 공부할 땐 보이지 않았던 것들이 많았다. 그 중 가장 고민했던 순서대로 네 가지를 꼽아봤다. 물론 이건 내 개인적인 경험이고, 정답이 아니다.

 

 

 

 

1. 일단 동작하게 만들자

 

 

 당연한 얘기다. 개발할 때 '완성도'와 '동작' 사이에서 뭘 우선시할 지 고민했다. 유지보수가 편한 구조, 가독성 높은 코드가 완성도를 높여줄 거라 믿었다. 혼자 공부할 땐 이 부분에만 집중했다. 회사에서 유지보수할 때도 메소드 하나를 잡고 가독성이 괜찮은지, 구조가 아름다운지를 따졌다. 

 앱 출시할 땐 달라야 했다. 처음엔 의도대로 코딩을 못해서 스트레스도 많이 받았다. 원하는 만큼 깔끔하게 코딩되지 않거나 메소드를 넣을 최적의 위치를 몰라 영 엉뚱한데다가 넣을 때면 혼자 못마땅해 하고, 개발을 미루기도 했다. 완벽함을 추구한다고 볼 수도 있지만, 다소 미련했던 것 같다. 개발기간이 계속 늘어나게 됐기 때문이다. 혼자하는 개발이라 기간의 압박이 덜한 편이었으나 스스로 정했던 기한을 한달이나 넘기자 마음이 급해졌다. 언제든 내 게으른 성질이 나타나서 개발을 때려칠 것만 같았다. 영영 출시 못하게 될까봐 걱정됐다.

 난 우선순위가 '출시'라는 것에 다시 집중했다. 조금 마음에 안 들어도 일단 기능이 동작하면 오케이. 나중에 코드리뷰로 다잡자고 스스로 다독였다. (이 다짐은 아직 이루어지지 않았다..) 타협을 하니 개발에 속도가 붙었다. 이 일을 계기로 결벽적인 가독성, 구조 집착도 중화시킬 수 있었다.

 

 

 

 

2. 예외처리는 중요하다 

 

 

 위에서 앱이 동작하게 만들어야 한다고 했는데, 생각한대로 돌아가게 하려면 예외처리는 필수다. 사용하는데 시도때도 없이 앱이 종료된다면? 앱 개발자 본인이 아닌 이상 사용자는 미련없이 앱을 삭제해버릴 것이다. 쓰고보니 애플 공식 문서에서 본 문장같다. 그땐 이렇게 중요한 줄 몰랐지... 혼자 공부할 땐 예외처리를 크게 신경 안 썼다. 학교에선 교수님들이, 직장에선 사수가 예외처리의 중요성을 그렇게 강조했는데도 신경 안썼던 걸 보면 역시 사람은 자기가 경험해봐야 아는 것 같다.

 그 중요성을 깨달은 건 '오늘모입지?'를 개발하고 QA할 때였다. 처음 테스트를 해보니 앱이 시도때도 없이 꺼졌다. 스크롤 내리는 속도가 조금만 빨라져도 종료, GPS를 꺼도 화면 종료, 사이드메뉴를 누르는데도 화면 종료. 어찌나 잘 꺼지는지 무슨 개복치인 줄 알았다. (....) 내가 만약 사용자였으면 지워도 오만번은 더 지웠을 거다. 

 강제종료를 피하려면 별 수 없다. 극한까지 예외상황을 짜낸다. 조건문에 전부 조건을 추가하고, 그밖의 모든 잘못은 try-catch가 잡게 하소서....쓰고나니까 무슨 고해성사 같은데, 다행히 이제 크리티컬한 예외는 없다. ...라고 말하고 싶지만 파이어베이스를 보니 꾸준히 크리티컬 크래시가 발생하고 있다. 젠장. 예외처리뷔우스의 띠.

 

 

 

3. 앱의 품질을 높이는 건 아주 사소한 요소들

 

 

 사용자가 쓰기 좋은 앱의 기준이 뭘까? 디자인? 기능에 충실했으나 사용자는 3-5분 정도 있다가 앱을 떠났다. 개발할 땐 디자인만 이쁘면 저절로 퀄리티가 좋아지는 줄 알았다. 출시 직후 '오늘모입지?'는 조금 심심하고 정적인 앱이었다. 물론 사용자는 그렇게 세심하게 따지지 않을 것이다. 하지만 짧은 체류시간이 말해주었다. 앱에 볼거리가 없구나 라는걸. 

 그러던 중 네이버 테크 콘서트에서 한 연사를 들었다. 앱에서 애니메이션이 필수 기능은 아니다. 하지만 터치했을 때 햅틱 반응이 오거나 아이콘이 움직이는 등의 액션이 들어가면 사용자는 앱과 더 풍부하게 상호작용할 수 있다는 게 내용이었다. 연사는 서비스의 품질이 사소한 개선에서 나온다는 걸 알려주었다.

 조사하면서 본 명함플랫폼 '리멤버' 대표님 인터뷰도 인상적이었다. 당시 회사는 저예산이었고, 고객을 확보해야 하는 상황이었는데, 그때 그들은 기존 고객 유지에 신경을 썼다고 한다. 새로운 유저에 마케팅비를 쏟기보다는 기존 고객 피드백에 귀를 기울이고 개선에 집중한 것이다. '명함 사진을 편집할 때 모서리 처리를 더 깔끔하게 하는 것' '화면을 부드럽게 넘길 것' 사소한 기능일 지 몰라도 이 과정을 통해 기존 고객층이 탄탄해졌고, 입소문이 나서 성공할 수 있었다. 

 결국 돌아보면 사소하지만, 품질을 높이고 고객을 유지하는 건 이런 것들이다. 이제 백 투 베이직이다.

 

 

 

4. 내가 편한 개발? 사용자가 편한 개발?

 

 혼자 공부할 때는 당연히 내게 편한 방법만 썼다. 사용법이 한글로 써진 블로그가 있을 것, 사용자가 많이 쓸 것 이 두 가지를 충족하는 라이브러리가 1순위였다. 사용자를 위한 개발은 달랐다. 어떤 API가 더 좋은 정보를 제공할지 고민해야했다. 이에 관련된 얘기는 바로 이전 포스트에서 다뤘기 때문에 링크만 첨부하겠다.

 

 https://klala1203.tistory.com/337?category=748351

 

내가 기상청 API를 반드시 사용해야 하는 이유 - 혼자 앱 개발하는 이야기#16

집을 구하러 다닐 때의 일이다. 유명한 부동산앱을 깔아서 매일같이 살펴봤다. 그때 한창 집값 비싸다고 뉴스에서 난리였는데, 신기하게도 그 어플엔 조건좋은 싼 집들이 참 많았다. 그게 '허위 매물'이었다는 걸..

klala1203.tistory.com

 

 


 

 

 

적고나니 새삼 몰랐던 게 많구나 싶다. 여전히 계획표에는 수많은 계획들이 가득하다. 아직 역량이 부족해서 구현 못하는 것도 있고, 귀찮아서 할까말까 갈등하는 것도 많다. 이 정도면 괜찮지 않을까 안주하고 싶은 마음도 크다. 하지만 오늘 나를 계속 움직이게 만드는 리뷰가 도착했다. 

 

 

 리뷰를 보고 감동의 도가니에 빠져서 아침 출근길이 행복했다. 꾸준히 앱을 사용해주는 애정, 스토어에 피드백 남겨주는 정성 모두 감사했다. 한 명의 피드백일지언정, 마구 움직이게 만든다. 이 밖에도 보이지 않는 무수한 사용자들이 있을 거다. 그러니까 열심히 할 수 밖에. 절대 게을러지지 않을 거다. 이것 또한 앱 출시하기 전엔 몰랐을 새로운 경험이다. 결과가 어떻든 모든 경험이 전부 소중하다. 앱 출시하길 잘했다.