플머의 개발 연구소

많은 사람들이 앱 서비스를 개발하여 성공하기를 갈망한다.

아무래도 휴대폰이 필수 기기가 된 이 시대에 사용자에게 쉽게 다가가기 위한 서비스가 앱이기 때문일 것이다.

웹 또한 인터넷을 통해 쉽게 접근이 가능하지만, 외부에 있다던지 밤 늦게 침대에서 자유롭게 사용하기에는 휴대폰만한게 없기 때문에 앱이 접근성 면에서는 더욱 유리하다.

앱은 사용자가 접근하기에는 매우 편리한 서비스지만, 웹에 비해 개발에 신경써야할 것이 더 많다고 생각한다.

다양한 이유가 있지만 간단히 말하면, 웹은 인터넷 하나로 통하지만, 앱은 Android, IOS 두가지 플랫폼을 신경써주어야 하기 때문이다.

앱 개발에 관심을 갖는 사람들은 많지만 정작 개발하려면 어떻게 시작해야할지 막막하고,

자신이 직접 개발을 하지 않고 외주 등을 통해 진행하려한다해도 최소한의 개발이 어떻게 진행되는지는 알아야 할 것이다.

이에 따라, 나는 앱 서비스 개발에 대해 전혀 감을 잡지 못하는 분들에게 최소한의 개발 과정을 이해시키고

사업을 진행하는데 있어서 도움이 되길 바라는 마음에서 이 글을 쓴다.

(참고로 앱에 대해 한정해서 얘기하지만 전반적으로 웹이든, 다른 분야든 어느 정도 통용은 된다.)

먼저 서비스 개발의 모든 것은 아이디어를 떠올리는 것부터 시작된다.

'이 앱을 만들면 성공할 것 같다.', '이 앱은 기존에 없는 앱이다', '이건 무언가 불편한데...', '이렇게 하면 재밌겠다.' 등등 내가 겪은 무언가를 통하거나 여러 이유에서 새로운 서비스를 만들어야겠다는 필요성을 느끼게 된다.

이제 여기서 서비스 개발을 위해 다음 단계를 진행하게 되는데,

이 단계에서 많은 사람들이 착각하는 것이 이 상태에서 바로 개발을 진행하려한다는 것이다.

개발자를 만나서 '지금 내가 이런 아이템을 생각하고 있습니다. 이렇게 만들어주세요.' 이렇게 말하면,

제대로 된 개발자라면 거절하거나, 정리된 기획 문서를 요구한다.

물론, 돈이 궁하다던지, 경험이 별로 없는 개발자 혹은, 추후 리스크를 감수할 수 있는 개발자라면 그냥 받아서 진행하는 경우도 있다. 이 경우 순탄하게 개발이 진행되는 경우는 흔치 않다.

갑자기 잠수를 탄다던지, 중간에 포기를 선언한다던지 하는 경우가 꽤 드물지 않게 존재한다.

그 이유는 개발자가 생각하는 개발의 규모와 외뢰자가 생각하는 개발의 규모가 다르기 때문이다.

애초에 정확한 설계도가 없는 상태에서 각자가 생각하는 것이 동일할 수가 없기 때문에 어쩌면 당연한 것이다.

아이디어를 떠올렸다면 '기획'을 진행해야 한다. 기획이란 아이디어를 구체화시키는 것이라 보면 된다.

기획에는 많은 것들이 내포되어있다. 시장성 조사, 사업계획서 작성, 스토리보드 작성, 추후 추진 계획 등...

여기서는 개발 진행에 필요한 최소한의 것만 설명할 것이다.

개발자가 원활하게 개발을 진행하려면 스토리보드 & 와이어프레임이 필요하다.

(아주 간단한 앱이라면 구두로만 해도 진행은 가능하다.)

위를 보면 앱 화면들이 나열되어있다.

내가 만들고 싶은 아이디어를 구체화 시키는 작업이 필요한데, 개발자를 쉽게 이해시키고 개발을 요청하기 위해

위와 같이 내가 만들 앱의 모든 화면을 구현해놓은 것을 스토리보드라 한다.

스토리보드에서 어떤 버튼을 터치하면 어디로 연결이 되는지 등의 정보를 와이어로 연결해준 것을 와이어프레임이라고 한다. 와이어프레임이 있어야 앱 화면간의 유기적인 동작 구조를 이해할 수 있기 때문이다.

뭐 스토리보드만 있어도 개발이 불가능한건 아니니 스토리보드만 요청하는 경우도 있기는 하다.

어쨌든 저러한 스토리보드 작성을 본인이 직접 하던가, 앱 기획자를 외주로 구하던지 해서 만들어내야 한다.

애초에 앱에 대한 지식이 별로 없다면 본인이 작성하여도 이해시키기 어려울 가능성이 높으므로 앱 기획자를 고용하는게 순탄하게 진행할 수 있는 방법일 것이다.

스토리보드 작성을 위한 툴은 여러가지가 있는데, 대표적으로 Adobe XD, Sketch, Axure 등이 있다.

기획자마다 작업하는 툴이 다를 수 있고, 되도록 내가 원하는 툴로 작업해줄 것을 요청하는게 좋다.

Sketch는 인기가 많은 툴이지만 맥OS에서만 구동이 가능하고 나의 경우 주로 윈도우 환경에서 작업하기 때문에,

기획 문서를 요청시 Adobe XD로 작업을 요구한다. 규모에 따라 다르지만 보통 기획 작업은 3~6주 정도 걸린다.

자, 그럼 스토리보드를 진행 완료하고 그 다음 작업은 무엇일까?

바로 앱 디자인이다. 앱 기획자는 디자이너가 아니기 때문에, UX/UI 디자인을 고려하기 어려운 경우가 많다.

그렇기에 깔끔하고 유저들이 사용하기 쉬운 디자인을 구현하기 위하여 앱 디자인을 진행하게 된다.

앱 디자인은 저렇게 만들어진 스토리보드를 앱 디자이너에게 넘겨주기만 하면 된다.

그럼 앱 디자이너는 저 스토리보드에 새로운 디자인을 씌워서 넘겨줄 것이다.

(참고로 기획자가 작성한 스토리보드 수준의 디자인만으로 충분하다면 굳이 앱 디자인을 진행하지 않고 맡겨도 된다.)

앱 디자인 기간은 보통 화면 개수에 따라 달라지게 되는데, 보통 3~4주 정도 걸리게 된다.

단가의 경우 디자이너마다 다르지만, 앱 화면 하나당(중복화면 제외) 단가 2~6만원으로 잡고 진행하는 듯 하다.

여기까지 완료되었으면 이제는 개발자에게 요청할 수 있는 단계가 된다.

개발자는 스토리보드를 넘겨받으면 자신이 이 스토리보드를 보고 어느정도 일정 내에 소화 가능한지, 어느정도 비용이 들 것인지를 산정하게 된다.

여기서가 중요한데, 개발을 어떤 방식으로 진행할지에 대한 부분을 결정해야 한다.

앱 개발하는 방법은 여러가지가 있는데, 크게 웹앱, 하이브리드앱, 크로스플랫폼 앱, 네이티브 앱 4개 단계로 나눠진다.

[웹앱]

웹앱은 모바일 웹이라고 보면 된다. 개발 단가는 가장 싼 편에 속하지만, 브라우저로 접근해야된다는 단점이 있다.

웹이기 때문에 구현하고나면 Android/IOS 상관없이 접속이 가능하다.

[하이브리드 앱]

모바일 웹을 네이티브로 감싼 앱이라고 보면 된다. 즉, 기기에서 아이콘을 눌러서 앱을 실행하지만 그 내부는

웹뷰(브라우저)로 되어있는 것이다. 웹앱보다 편리한 접근을 원하거나, 푸시 알림 등의 네이티브 기능이 필요할 때

하이브리드 앱으로 구현을 한다. 이전에는 네이티브로 Android/IOS 각각 브라우저로 감싸서 별도의 결과물을 만들어냈지만, 최근에는 크로스플랫폼 개발툴을 이용하여 Android/IOS 결과물을 동시에 만들어내기도 한다.

어쨌든 결국엔 웹앱을 감싼 것이기 때문에 퀄리티면에서는 조금 부족할 수밖에 없다.

[크로스플랫폼 앱]

Android/IOS 개발을 동시에 진행하지만 최종적으로는 각각의 결과물을 만들어준다.

네이티브에 비해 생산성이 월등하다. 하지만, 네이티브 종속적인 기능을 구현할 때는 개발에 어려움이 생길 여지가 있다.

최근 스타트업들이 대부분 이 크로스플랫폼 앱으로 개발을 진행한다. 아무래도 네이티브로 진행할 경우 안드로이드, IOS 개발자를 각각 구하여 각각 개발해야 하기 때문에 매우 비효율적이기 때문이다.

성능이나 퀄리티면에서도 하이브리드 앱과는 다르게 네이티브에 가깝게 구현할 수 있다.

[네이티브 앱]

휴대폰의 능력을 100% 활용하여 앱을 개발할 수 있다. 단, 안드로이드, IOS 각각 개발을 따로 진행해야한다는 점이 단점이다. 네이티브 종속적인 기능을 활용해야 하는 경우가 아니라면 크로스플랫폼 앱 개발로 진행하는 것을 추천한다.

개발 시간이 크로스플랫폼 앱 개발에 비해 거의 2배 이상 들게 되며, 비용 또한 상당히 높아지게 된다.

위 개발 방법 중 자신이 개발할 앱이 어느쪽에 적합한지 확인한 후에 개발자에게 요청하게 된다.

앱의 개발 기간은 프로젝트 내용에 따라 천차만별이다. 또 위의 개발 방식에 따라서도 달라지게 된다.

아주 간단한 프로젝트는 1개월만에도 만들어지기도 하지만, 복잡한 프로젝트는 최소 6개월~1년이 걸리기도 한다.

즉, 자신이 생각하는 프로젝트 규모에 따라 적절한 개발 인력을 산정하는 것도 중요하다.

그리고 개발이 시작된다면, 적어도 1주일에 한번 정도라도 주기적인 미팅으로 개발 진행 단계를 파악할 것을 권장한다.

그냥 개발자만 믿고 놔두다가는 마지막에 가서 어떤 오류에 부딪혀서 계속 고민중이라느니,

다른 사정이 있어서 못했다는 등의 이유로 거의 개발이 되어있지 않는 경우도 종종 존재한다.

실제로 이러한 경우로 프로젝트가 무산되는 경우도 꽤 있다.

개발이 완료되면 최종적으로 스토어에 올리는 작업을 진행하게 된다.

(보통은 테스트 단계에서 테스트 버전으로 미리 등록된다.)

이 경우 스토어에 앱에 대한 디테일한 정보를 개발자에게 알려주고 세팅을 요청할 수도 있다.

그리고 추후 유지보수를 위해 개발자에게 소스코드 또한 반드시 넘겨 받는다.

이제 앱이 심사를 받고 심사가 끝나게 되면 실제로 스토어에서 개발한 앱을 검색할 수 있게 된다.

당연히 앱의 활성화를 위해 마케팅은 개발 단계에서든지, 개발 이후에서든 진행을 해야할 것이다.

나름 간단하게 쓴다고 썼는데, 별 내용이 없는 듯한데도 너무 길어진 듯 하다.

추가적으로 궁금한 사항은 댓글 등을 통해 메일을 남겨주시거나 하면 답변드리겠습니다.

플러터는 크로스플랫폼 개발 툴이다.

여기서 크로스플랫폼 개발이라 하면 Android/IOS 모바일 개발을 동시에 할 수 있는 것을 말한다.

나는 안드로이드 개발만 하다가 IOS 개발까지 해야함에 따라 크로스플랫폼 개발을 고려하게 되었다.

처음 크로스플랫폼을 접할 때 크로스플랫폼이 가질 수 있는 한계에 대해 매우 고심했고,

다양한 크로스플랫폼을 최대한 비교하여 가장 효율적이고 개발에 가장 유리할 수 있는 크로스플랫폼을 찾고자 했다.

크로스플랫폼을 쓰고자 하는 목적은 보통 생산성에 맞추어져 있다.

구현하고자 하는 기술에 문제가 되지 않는다면 크로스플랫폼 개발은 매우 효율적이고 올바른 선택이 될 것이다. 네이티브로 개발한다면 안드로이드와 IOS 플랫폼을 각각 개발하여 두배의 시간 혹은 두배의 인력이 드는데 크로스플랫폼을 쓴다면 비용적으로나 시간적으로나 매우 유리해지기 때문이다.

나는 크로스플랫폼 개발 툴 중 자마린, 리액트 네이티브, 플러터 셋중에 무엇을 사용할지 고민을 하였다.

자마린의 경우 나는 C#도 주로 사용했던 언어였기 때문에 그 접근성 때문에 고민했었고,

리액트 네이티브는 자바스크립트 기반인 부분에 이끌렸다. 자마린과 양대 산맥이기도 하고...

플러터의 경우는 자마린, 리액트네이티브 사이에서 혜성처럼 갑자기 떠오른 느낌이었고,

다트라는 조금 낯선 언어(그래봤자 자바와 비슷한 느낌)를 사용하지만 구글에서 밀고 있기도 하고, 여러 자료를 찾아본 결과 UI 구현에 대해 상당한 강점이 있으리라 판단했다. 

서론이 길었는데 내가 내린 판단은 플러터를 사용했을 때 가장 생산성 높은 개발을 이룰 수 있다라는 것이다.

우선, UI 구현 자체가 매우 수월하다. 초보자들도 복잡한 UI를 플러그인만 잘 갖다사용하여도 어렵지 않게 구현해낼 수 있다. UI가 별거 아닌 작업처럼 보이지만, 다이나믹한 UI를 구현하기 위해서는 상당한 시간을 할애해야 한다.

다른 개발툴을 플러터만큼 파보지 않아서 판단하기에 오류가 있을 수 있지만, 

UI 생산성은 자마린, 리액트 네이티브도 따라오기 어려울 것 같다는 판단이 든다.

사실 이 UI 구현에 대한 장점만으로도 플러터를 사용할 이유는 충분했다.

네이티브 개발시 레이아웃 구성이나, 다이나믹한 UI를 구현할 때마다 꽤 시간을 들여야 했던 것을 떠올려보면,

플러터는 그 시간을 날로 먹는(?) 수준으로 줄여준다. 거의 로직에만 신경 쓸 수 있도록 말이다.

한가지 더 기대하고 있는 것은 기획 디자인 툴인 Adobe XD에서 'XD To Flutter' 기능을 출시할 예정에 있다.

(얼마 전 출시는 된 상태인 것 같은데 어느 정도 수준인지 확인해보지는 못했다.)

현재 제플린에서 Flutter Extension을 제공하고 있지만, 경험자에게 듣기로는 수동으로 작업하는게 더 빠를 정도로 코드 변환이 매우 지저분하다고 한다. 그래서 XD To Flutter 기능이 완벽하게 출시된다면 UI 작업은 개발자가 거의 신경을 쓰지 않아도 될 수준이 되지 않을까 싶다. 디자이너가 넘겨준 XD파일을 그대로 변환시키면 될 것이므로..

하지만, 역시나 단점도 존재한다. 내가 꼽은 단점은 아직 플러터가 리액트네이티브나 다른 크로스플랫폼에 비해 활성도가 떨어진다는 점이다. 자료가 타 개발 도구에 비해 부족하다는 것. 예를 들어, 원하는 기능을 구현할 때 해당 기능에 대한 플러그인이 존재하면 가져다쓰면 금방 개발 가능하지만, 없다면 그에 해당하는 플러그인을 직접 만들어야 한다. 

혹은 존재하더라도 베타 버전의 플러그인이라 다른 플러그인과 충돌하여 컴파일에 오류가 발생하거나 하는 등의 문제도 존재한다. 그래도 이 부분은 점점 개선이 될 것으로 생각하고 있다. 내가 플러터를 접한지 1년이 안되었는데 그 사이에도 문제가 있었던(혹은 베타였던) 플러그인이 많이 개선되었다.

개발에 대한 안정성만 놓고 보면 아직까지는 리액트 네이티브가 한 수위라고 생각되지만,

UI 개발 생산성에 대한 매력이 너무 크기 때문에, 그 외 자료 부족 등의 불편한 부분은 감안할 정도라고 본다.

플러터로 간단한 앱부터, 플랫폼 수준의 앱까지 개발해보았는데, 앞으로도 플러터를 애용할 것 같다.