앱 만들기 전에 읽어주세요(1)
원대한 꿈이 현실의 벽에 부딪쳐 조각나고 조각을 붙들고 헤엄치는 이야기
대학원에서 여러가지 코딩언어와 지식을 배우는데 현실에서 써먹어 보고 싶다는 생각이 매우 간절했다. 개인적으로는 코딩이나 기술이란게 실제와 접목하지 않으면 무쓸모처럼 느껴지니.
2년전, 앱 기획자로 10년을 일한 지인을 오랫만에 만났다. 같이 등산을 하다가 여러가지 앱에 대해서 얘기하게 됐다. 반려동물 SNS 앱에 대한 얘기를 하다보니 앱이 만들어보고 싶어졌다. 지인과 대화하다 보니 앱 만드는 것이 대수롭지 않은 일인것 처럼, 나 같은 문외한도 할 수 있을것 같은 생각이 들었다. 인터넷을 찾아보니 앱 하나 만들어서 일하지 않고도 앱으로 수익화하는 사람들의 얘기에 '그래, 바로 이거다! 내가 원하는거!!'라는 생각이 들었다. 쉽게 돈벌자. 노마드 라이프. 부푼꿈을 안고 우리 둘다 앱 만드는 수업을 등록했다.
1타 쌍피 - React Native(Expo)
앱을 배포하기 위해서는 아이폰(iOS)의 '앱스토어', 갤럭시(Android)의 '플레이스토어'에 앱을 올려야 한다. 아이폰과 갤럭시는 운영체계가 다르기 때문에 같은 앱을 2가지 언어로 개발해서 따로 올려야 한다. 앱 한개 만드는것도 버거운데 2개를 만들어야 하다니?! 그때 당시에는 어림도 없어 보였다.
폭풍 리서치를 했다. 그러던 중에 한가지 언어로 개발해서 아이폰, 갤럭시 둘다 출시할 수 있는 선택지가 있다는 것을 알게됐다! React Native 혹은 Flutter라는 한가지 언어로 개발하면 그것이 가능하다는 것.
하지만 이 엄청난 장점 뒤에는 엄청난 단점도 숨어있었다.
Expo는 React Native 쓰는걸 더 간단하게 쓸 수 있게 포장해 놓은 라이브러리다. 나중에 알았다. 실무에서는 이걸 거의 쓰지 않고 그냥 간단한 토이 프로젝트 정도할 때만 쓴다는 것을... 아무튼 수업만 들으면 몇달안에 앱을 하나 만들 수 있다는 광고에 넘어가서 몇십만원을 주고 등록했다. 수업을 듣다가 똑같이 따라하는데 계속 뭐가 안됐다. 버전이 끊이없이 업그레이드 되서 안되고. 버전이 바뀌면서 라이브러리끼리 호환이 안되고. Mac이라서 안되고. 그냥 엉망이었다. 결국 만들다가 포기했다.
1년이 흘렀다.
2번째 도전
대학원에서 코딩과 데이터베이스, 운영체제 등을 배우고 조금 더 자신감이 생겼다. 그래서 작년 여름에 앱 만들기에 다시 도전하기로 마음먹었다. 이번에는 대학원 같이 다니는 10살 어린 친구와 도전했다. (참고로 대학원에서는 앱 만드는 방법 따윈 가르치지 않았다.) 이번에는 기초부터 제대로 배우자 싶어서 HTML, CSS, Javascript, React Native 등의 기초 수업을 듣기 시작했다. 배울게 너무 많아서 거북이 걸음으로 진행됐다.
앱 만드는 프로세스 전반에 대해서 얘기하는 유튜브나 책을 찾았는데 없었다. 좀 놀랐다. 시장에 수많은 앱이 쏟아지는데 전반적인 프로세스를 다루는 변변한 콘텐츠가 없다니.. 유튜브에는 엄청 간단한 앱 (시장에 내 놓을수 없는 수준의 앱에 관한 것이나 취업시 포트폴리오 정도로 쓸수 있는 앱), 몇분안에 완성, 이런것들만 넘쳐났다... 그런것들은 도움이 하나도 안됐다. 파편적인 콘텐츠 밖에 없었다. UI/UX. 프론트앤드. 백앤드. 이런것들이 어떻게 유기적으로 연결되는지는 찾을 수 없었다. 상황이 이러니 그냥 또 하면서 부딪히는 수밖에..
우선 뭘 해야하지??
막막...
와이어프레임, UI, UX, 프런트, 백앤드 등 등 처음에는 너무 혼란스러웠다. (단어들은 막상 알고나면 별거 없다. 뒷걸음질치지 말지어다. 알아야 되는 단어 다 알려드릴께요.)
문과적 시점에서 가급적이면 쉽게 전체적인 프로세스를 정리해보고 싶다. 나는 아래의 프로세스를 몸으로 직접 체험하면서 배우는데 6개월 이상의 시간을 썼다. 여러분들은 같은 실수 하지 않기를.. ^^
1. 설계 (Wireframe)
집을 지을때 가장 먼저 건축 설계를 한다.
앱을 만들때도 마찬가지다. 설계를 먼저해야 한다.
설계를 어떻게 해?
앱은 매우 많은 페이지로(화면으로) 구성되어 있다.
설계란 페이지들의 배열과 페이지 안의 내용을 정하는 것이다.
내 앱에 총 3개의 화면이 있다고 해보자.
앱을 처음 실행했을 때 페이지1(로그인 화면)이 나온다.
그 페이지에는 2가지 버튼이 있다.
첫번째 버튼을(로그인버튼) 누르면 페이지2(유저의 메인화면)로 이동한다. 두번째 버튼을 누르면 페이지3(회원가입)으로 이동한다.
화면 설계를 위해서는 figma라는 디자인 툴을 이용해도 되고, 그냥 종이에 펜으로 그려도 된다. (https://www.figma.com/) 깔끔하고 다른 사람들도 쉽게 알아볼수만 있다면 상관없다. 이때는 디자인적인 요소는 고려하지 않아도 된다. 앱의 기능적인 부분만 정의하는 것이다.
2. 디자인 (UI, UX)
페이지(화면) 구성을 마쳤다.
그럼 화면에 디자인을(색, 모양 등) 입혀야 한다.
앱에 관심 있는 사람이라면 UI(User Interface) 와 UX(User Experience)는 한번쯤 들어봤을 것이다.
이게 도대체 뭔가??
쉽다. 영어를 알면 더 직관적이다.
UI는 사용자가 직접 보는 화면. 한마디로 앱의 비쥬얼적인 모든 것이다. 앱의 전체적인 색 (바탕색, 버튼색, 글자색), 글씨체, 글씨크기, 화면구성 등.
UX는 말그대로 앱 사용자의 경험에 대한 것이다.
화면 구성을 어떻게 했을 때 앱의 유저들이 쉽고 직관적이라고 생각하는가? 구구절절한 설명없이도 사용자가 이 버튼을 누르거나 swipe을(미는동작)하면 자연스럽게 원하는 화면으로 전환되는가 아니면 이 화면이, 이 버튼들이 도대체 어떤 목적을 갖고 만들어졌는지 혼란스럽거나 화면에서 사용자가 원하는 정보를 제공하지 못한다면 UX가 별로라고 말할 수 있겠다. 유저는 그러면 정말 짜증이 나고 앱을 꺼버리고 다시 쳐다보지 않을 가능성이 높다. 앱 사용자의 경험이 좋고 편하면 UX가 잘됐다고 말하고 아니면 UX가 안 좋다고 말할수 있다. 몇년전에 쏘카앱을 다운받아서 처음으로 써봤다. 쓰기가 너무 힘들었다. 디자인은 심플하고 예뻤다. 이런 것은 UI가 잘 됐지만 UX가 별로라고 말할 수 있겠다.
앱이 비쥬얼적인 면도 중요하지만 더 중요한 것은 사용자의 경험이다. 아무리 예뻐도 사용자가 불편하면 다시 사용하지 않을 확률이 높다. 불편을 감수하더라도 가격적으로 엄청 메리트가 있는 않는이상. 쏘카 앱은 한번쓰고 다시는 쓰지 않는다.
위에서 우리는 화면 설계를 끝냈다.
이제는 페이지마다 디자인을 해야한다. 페이지가 100개라면 100개 화면을 다 디자인 해야한다.
할일 진짜 많죠?? 엄청 많습니다.
자, 이제 2가지 선택지가 있습니다.
1. 본인이 직접 디자인 한다.
2. 디자이너에게 맡긴다.
결론: 고생하지 마시고 가급적이면 그냥 디자이너에게 맡기세요. ^^
처음에는 그냥 '우리가 다 해보자' 마인드로 했다. figma에서 열정적으로 색, 버튼, layout (화면구성)도 이렇게 저렇게 바꿔봤다. 그치만 내 앱과 내가 아는 대기업들 앱과 너무 비교되서 (카톡, 당근, 인스타그램) 디자인을 계속 바꾸고 삽질을 계속한다. (디자인을 바꾸면 프론트앤드를 업데이트해야하기 때문에) 내가 하면 이렇게 해도 이상하고 저렇게 해도 이상하다. ㅋㅋ
앱 시장은 초기시장이 아니다. 사람들은 이미 세련된 UI에 익숙해져 있다.
내가 출시할 앱은 아무도모른다 내 가족과 친구이외에는...(심지어 그들도 별로 관심없다)
그렇기 때문에 사람들의 눈에 조금이라도 더 들려면 디자인이라도 평균 이상이거나 예뻐야 한다. 내가 디자인 전공, 미대전공이 아닌데 이걸 할 수 있을까? 이쪽으로 워낙 재능이 있는 사람이 아니라면 못할 가능성이 높다.
내 앱을 동생한테 보여주고 신랄하게 비판받은 뒤 그냥 돈주고 디자이너에게 맡겼다.
그리고 후회했다. 진작맡길껄...
디자이너는 크몽에서 구했다. (https://kmong.com/)
싸지는 않다. 그러나 장기적인 관점에서는 무조건이다. 돈은 주로 화면수로 (페이지수) 받는다. 내 와이어프레임 보내주면 실력있는 디자이너들은 UI하면서 UX적인 팁도 알려주고 엄청 도움이 많이 된다. 돈을 조금 더 내면 일러스트레이터랑도 협업해서 결과물을 준다. 기간은 짧으면 1주일에서 길면 몇주가 걸리기도 하지만 생각보다 그들은 금방 결과물을 준다. 내 앱은 기능이 너무 너무 뛰어나서 디자인적인 요소 같은거 필요치 않다고 한다면 뭐.. 부럽습니다 ^^
3. 프론트앤드 (Frontend)
프론트앤드, 백앤드.
이 단어는 업계에게 가장 많이 쓰는 단어중에 하나이다.
쉽다. 영어로 직역해보자.
프론트앤드 - 앞쪽.
백앤드 - 뒤쪽.
프론트앤드랑 백앤드는 앱을 코딩으로 만들어 낸다는 뜻이다.
코딩은 이제서야 등장한다. 두둥.
난 작년에만 해도 앱 = 코딩이라고 생각했었지. (아뉘아뉘)
그럼 앞쪽이 뭐야?
사용자의 관점에서 봤을때 앱 화면에서 보여지는 모든 것들을 코드로 짜서 만들어내는게 프론트앤드다. 우리가 위에서 화면 설계를 했고, 페이지마다 구성을 했고 (layout), 각 화면의 디자인까지 했다. 그럼 이제 그 디자인과 구성에 맞게 화면을 만들어 내야 한다. 그게 프론트앤드다.
우리는 프론트앤드로 React Native라는 페이스북에서 만든 오픈소스를 썼다. React Native에 호환되는 수많은 라이브러리 (library)들이 있다. 라이브러리는 뭘까? 그냥 남이 코딩하기 쉽게 만들어 놓은 도구다. 예를들어, 내가 요렇게 생긴 버튼을 만들려면 코딩 100줄이 필요하다. 하지만 라이브러리를 쓰면 코딩 1줄로 가능. 프론트앤드 언어를 선택할 때는 그래서 사람들이 많이 쓰는 언어를 선택하는게 좋다. 왜냐면 그만큼 많은 라이브러리들이 나와 있을 가능성이 크기 때문에. 라이브러리의 장점은 쉬운 코드. 단점은 내 입맛에 딱! 맞는 라이브러리를 찾기 힘들다.
React Native의 최대 장점은 하나의 언어로 아이폰/갤럭시 두군데서 다 출시 가능하다는 점이다. 그치만 이것 빼고 다 단점이다. 아이폰/갤럭시 전용 언어가 아니기 때문에 버벅거리기도 하고 문제가 생기면 어디서 생긴 건지 모르고. React native 가 오픈소스여서 몇년전에 라이브러리 만든 사람이 관리 안하면 (돈을 안 받기 때문에 관리가 안되는 경우가 태반이다 ㅋㅋ) 라이브러리가 새로운 React native 버젼과 호환이 안되고 없어지는 경우도 많다. React native 전문가 구하기도 엄청 어렵다. 힘들어서 하는 사람이 많지 않은듯..
내가 처음부터 다시 한다면 무조건 아이폰/갤럭시 둘 중 하나를 정해서 개발할 것 같다. 과욕이 참사를 불렀다.
4. 백앤드 (Backend)
앱의 뒤쪽이 왜 필요할까?
앱의 뒤쪽이 항상 필요한 것은 아니다.
앱의 뒤쪽이 필요한 경우는 주로 다음과 같은 경우다.
1. 데이터베이스에(db) 정보를 저장하고 가져와서 화면에서 보여줘야 하는 경우.
2. 다른 유저들과 소통하면서 다른 유저들이 올린 글/사진/영상을 보고 내가 올리는 글/사진/영상을 다른 유저들과 공유하고 싶을 때. 한마디로 SNS적인 요소가 있다면 무조건 뒤쪽이 필요하다.
앱의 뒤쪽이 필요없는 경우.
- 사진/영상 없는 일기앱. 매일 짧은 글을 내 폰에 저장하고 그 글들은 나만 볼 수 있다.
사진/영상은 크기가 크다. 그래서 사진/영상은 주로 뒤쪽에 저장해 두고 앱이 실행됐을 경우 필요한 사진/영상만 꺼내서 보여주는 경우가 많다. 사진/영상을 앱에 저장하게 되면 앱이 용량이 크고 무거워져서 앱이 잘 안돌아가거나 내 모바일폰의 전반적인 성능에 영향을 주는 경우가 많다.
즉, 우리가 아는 거의 모든 앱들은 백앤드를 신경써야 한다.
우리는 백앤드에 대해서 무지했다. 데이터베이스 수업을 들었지만 앱의 db는 어떻게 해야하는지 알수 없어서 제일 쉬워 보이는 Amazon Amplify를 선택했다. 왜? 제일 쉬워보여서.
하지만... 역시나... 쉬워보이는건 대부분 예쁜 독버섯이다.
Amazon Amplify가 엄청 쉬운것 처럼 포장되어 있으나 나중에 엔지니어 지인에게 물어보니 실무에서는 사용하는 사람들이 거의 없고 Amazon 사이트에서 documentation(사용설명서) 정말 최악이였다. 틀리거나 아예 없는 경우도 허다하고 자기들 마음대로 코드 바꿔서 갑자기 우리가 쓰는 코드가 안 돌아가기도 한다. ㅠㅠ 우리는 몰라서 어쩔수 없었다지만 진짜 비추입니다.
앱은 보여지는 디자인 부분도 중요하지만 진짜 백앤드 뒤쪽이 중요하다. 그래서 백앤드 전문가가 아니라면 왠만하면 전문가 쓰는걸 추천한다.
다음 글에서는 앱을 만들때 주의사항과 앱 마케팅, 수익화 등에 대해서 얘기해 보려고 합니다.
