BITNA 개발일기: 2.0 릴리즈를 앞두고

#.
어느덧 BITNA가 처음으로 앱스토어에 올라간 지 2년이 지났습니다.

 

#.
지금부터 정리하는 의미랄까 돌아보는 의미랄까... 이 앱 개발이 어떤 식으로 진행되었는지에 대한 이야기를 조금 두서 없이 적어볼까 합니다.

실은 얼마 전까지만 해도 이런 글을 쓸 생각은 없었는데, 얼마 전에 앱스토어에 달린 리뷰 글을 보고서 '앱에 담긴 개발자의 의도와 그에 따른 개발 과정'을 정리해두는 것도 재미있지 않을까 하는 생각이 들었습니다. 참고로 리뷰 글은 다음과 같습니다:

 

(클릭하면 커져요)

 

무료이기엔 너무 좋다!

Karl Pestka

앱스토어의 앱에 대한 설명은 매우 부실하게 되어 있으나, 기본적으로 이 앱은 눈으로 볼 수 있는 형태의 메트로놈이며 다른 스마트폰과 동기화할 수 있는 기능이 있습니다. 우리 밴드는 무대 반대편에 있는 연주자들이 서로 신호를 확인할 수 있도록 해 주는 이런 앱을 찾고 있었어요. (역주: 연주자가 서로 멀리 떨어져 있는 상태에서 동일한 템포를 시각적으로 확인할 수 있는 앱을 찾으려고 했다는 의미인 듯 합니다)

여타 다른 메트로놈 앱들과는 달리 시각 패턴의 색상/밝기, 박자를 조작할 수 있으며, 성능을 위해 컨트롤러를 감출 수도 있습니다. (전체 화면을 번쩍이게 하거나, 특정한 도형이나, 뭐든간에요) 필요하다면 텍스트를 스크롤할 수도 있습니다.

BPM이나 설정을 변경하는 부분은 좀 투박하지만, 상당히 간단해서 별다른 설명 없이도 사용할 수 있습니다. 작고 못생긴 광고 창이 이런 앱이 공짜로 존재할 수 있도록 해 주겠죠. 어쨌든 컨트롤러를 화면 밖으로 치워버리면 광고도 같이 화면에서 사라지니까 괜찮습니다.

 

 

저는 이 리뷰를 읽고서 깜짝 놀랐습니다. 이 앱의 초기 아이디어와 정확히 일치했거든요. 물론 현재는 앱이 지향하는 바가 예전과 많이 달라졌지만요.

 

 

#.
기억을 더듬어 BITNA가 어떻게 만들어졌는지를 떠올려보면, 때는 2009년 여름으로 거슬러 올라갑니다. 첫 아이디어는 사실 비주얼 메트로놈이었습니다. 소리 대신에 시각적으로 박자를 맞추는 도구인 메트로놈 앱 구현에 대한 아이디어를 제일 처음 떠올렸고, 그 아이디어는 이내 '여러 사람의 메트로놈 신호가 동기화된다면, 밴드에서도 사용할 수 있지 않을까?'라는 생각으로 발전했습니다. 제가 개인적으로 악기를 다루고 있고, 밴드를 해본 적도 있기 때문에 자연스럽게 떠오른 생각이었지요. 하지만 이러한 '동기화 가능한 비주얼 메트로놈'이란 아이디어는 한참을 묻혀 있어야 했었습니다. 그 당시에는 제가 iOS(당시에는 iPhoneOS였지만)의 그래픽스 관련 지식이 전혀 없는 상태였거든요. 이런저런 것들을 하면서 2010년이 되었습니다.

2010년 초쯤에 BITNA를 본격적으로 만들어보기로 마음을 먹고 일을 시작했습니다. 기술적으로는 UDP 소켓을 사용하면 이런 앱을 개발할 수 있을거란 생각이 들었습니다. UDP 소켓의 특성에 대해서 알고 계신 분들에게는 익숙한 이야기이겠습니다만, UDP는 기본적으로 속도에 최적화된 네트워크 프로토콜입니다. UDP의 <속도>라는 특성을 살려서 동기화 로직을 구현할 수 있었고, 그렇게 만들어진 BITNA의 첫 프로토타입에는 Blur 패턴(달랑 하나!)과 함께 패턴을 동기화하는 로직이 포함되었습니다.

근데 만들어놓고 보니 이게 - 훌륭했습니다! (자화자찬이라고밖에 할 수 없겠습니다만) 프로토타입을 만들어서 실제로 보자마자, 저는 여러 사람이 이 앱을 들고 공연장에서 붕붕 휘두르는 광경을 떠올렸죠. 그 순간 BITNA는 '동기화할 수 있는 야광봉'이란 새로운 컨셉을 갖게 되었고, 몇 개의 패턴이 추가되었습니다. 여기까지 약 3개월 정도의 시간이 걸렸고, 초기 버전이 2010년 3월에 앱스토어에 릴리즈되었습니다. 다음 동영상은 당시 초기버전의 영상입니다. (지금과는 모습이 많이 다르고, 동기화하는 부분은 40초 부근에서 시작됩니다)

http://www.youtube.com/watch?v=dU1opfnPEDo

 

 

#.
첫 버전을 릴리즈하던 당시에는 사람들이 이 앱에 관심을 가져줄 거라고 크게 착각했습니다. 물론 그렇게 되지 않으리란 것을 금방 깨닫긴 했지만요. 여러 이유가 있었겠지만 1. 기본적으로 조작성과 UI가 이해하기 어려웠고, 2. 그렇다고 (다른 야광봉Glowstick 앱에 비해) 이펙트가 눈에 띄게 멋진 것도 아닌데다가, 3. 실제로 사용하는데에 제약(동기화하려는 장치들이 동일한 무선랜 네트워크에 접속해 있어야 하는)이 너무 심했습니다. 첫 번째와 두 번째 문제는 디자이너를 데려다 UI를 개선한다던가의 방법을 쓸 수 있었겠지만, 세 번째 문제는 그 당시엔 딱히 해결할 방법을 찾지 못했습니다.

'동기화'가 메인 기능 중 하나이다 보니 각 장치의 시간을 동일하게 맞추는 작업이 필요했는데, 이 기능은 각각의 기기가 UDP 소켓을 사용해 서로 빠르게 패킷을 주고 받는 것으로 구현되어 있었습니다. 이 방식은 로컬 네트워크에서만 사용할 수 있었죠. 외부에 있는 별도의 서버를 이용하는 방법을 고민해 보지 않은 것은 아니었습니다만, 기술과 비용의 문제가 있었습니다. 먼저, BITNA는 한국 사용자만을 대상으로 개발된 앱이 아니었습니다. 무슨 이야기냐면, 별도의 서버를 사용하자니 개별 기기와 서버 사이의 통신 속도가 중요해지고, 통신 속도를 고려하자니 전 세계의 사용자를 커버하려면 전 세계의 사용자들이 빠르게 접속할 수 있는 서버가 필요했습니다. 작은 메시지를 빠르게 많이 주고받는 BITNA의 특성 상 서버의 성능이 좋을 필요는 없지만, 서버의 반응 속도가 빨라야 했습니다. 이런 조건에 맞는 환경을 만들려면 사용자와 서버 간에 반응 속도가 빠른 네트워크가 필요했고, 하나의 서버로 전 세계에 빠른 네트워크 접속 속도를 제공할 수는 없으니, 그렇다면 전 세계(모든 국가까지는 아니더라도)에 여러 대의 서버를 두어서 개별 사용자가 각국의 네트워크를 통해 자기에게 가까운 서버에 빠르게 접속할 수 있도록 해야 했습니다.

BITNA는 어디까지나 개인적인 흥미로 시작된 프로젝트였고, 당연히 전 세계에 여러 대의 서버를 운영할 비용 따위는 전혀 없었습니다. 특정 국가만 타겟으로 운영하는 방법도 있었겠지만 거기까지 고민하자니 고민의 방향이 별로 생산적이지 않다고 느꼈고, 결국 앱을 개선하려는 노력 자체가 시들해지면서 BITNA 자체는 별다른 반응을 얻지 못하고 사장되었습니다. 영국, 네덜란드 등에 매니악한 사용자가 몇 명 생기긴 했습니다만, 매니악한 유저를 통해서라도 알려지기 시작할 수 있을만한 앱은 아니었습니다. 무엇보다도, 위에 언급한 세 번째 문제(세계 각국의 서버!)를 해결하지 않고서는 이 앱을 성공시킬 방법이 없다고 생각했죠.

 

 

#.
그 이후에는 Mug라는 새로운 개인 프로젝트를 시작했습니다. 어떻게 보면 BITNA의 연장이라고도 볼 수 있는 프로젝트인데 ... 최대한 간단히 설명하자면 <사용자가 현재 자신의 위치에서 사용할 수 있는 컨텐츠를, 자동으로 사용자에게 전달해주는 시스템>을 개발하는 프로젝트입니다. 예를 들어 박물관에서 Mug 앱을 실행하면 자동으로 박물관에서 제공하는 오디오 안내 서비스가 표시되어 해당 컨텐츠를 사용할 수 있게 해준다던가, 그러한 서비스를 제공하는데 필요한 모바일 앱과 서버를 개발하는 프로젝트죠.

이 프로젝트 또한 성공하지 못한 상태입니다만, 이 프로젝트를 진행하면서 그 동안 꽤 오래 손을 놓고 있었던 웹 개발의 트렌드를 다시 살펴볼 수 있는 기회가 생겼습니다. 그리고 서버와 관련된 새로운 트렌드 중 클라우드 서비스를 실제로 접할 기회를 얻게 되었습니다. 사실 클라우드 가상화 서비스(혹은 그냥 가상화 서비스)를 예전에 접해본 적이 없었던 것은 아닙니다만, 몇 년 전까지만 해도 클라우드 가상화 서비스는 그야말로 '비용 절감' 이외에는 메리트가 전혀 없던 기술이었습니다. 비용은 확실히 실제 서버 구축에 비해 저렴하긴 했지만 서버의 반응 속도는 일정하지 않았고, 백그라운드에서 대량의 처리를 해야할 경우에나 고려해 볼 수 있는 기술이었습니다. BITNA에 적용하기에는 서버의 반응 속도가 걱정이 되었고, 그나마 클라우드 서비스 중 전 세계를 커버할 수 있다는 아마존의 EC2조차 BITNA를 개발할 당시에는 미국과 유럽 서버만 있었습니다. (일정 시간 무료로 사용할 수 있다는 것은 몰랐었습니다. 알았다면 한 번 시도라도 해 봤을텐데)

어쨌든, Mug 프로젝트를 진행하면서 국내에 가상 서버 호스팅으로 운영되는 서버를 구축해 운영하기 시작했습니다. 말 그대로 '싼 맛에 쓰는' 서버였지만 생각 외로 반응 속도가 괜찮았습니다. 이 정도면 BITNA 서버를 구축해서 돌려봐도 괜찮겠다는 생각이 들었고, 가상화 서비스에서 운영되는 서버가 이 정도라면 클라우드 서비스도 어느 정도 성능이 나와주지 않을까 싶더라구요. 그래서 앞서의 세 가지 문제를 다시 검토하기 시작했습니다.

 

 

#.
첫 번째 문제는 새로운 UI를 만들어 해결을 보려고 했으나, 최대한 빨리 작업을 진행해야 하는 상황이었습니다. 디자이너를 섭외하여 비용과 시간을 들일 생각도 했지만 그에 상응하는 결과물이 나올지도 미지수였고요. 저 혼자 이걸 해결하려면 어떤 방식의 UI를 만들어야 할까 고민하다가 '차라리 Geek 느낌의 UI를 만들자'라는 방침을 정했습니다. 어차피 이런 복잡한(실제로 기능 보면 복잡하긴 합니다;) 앱을 잘 사용하는 사람들은 Geek이 대다수일 것이고, 같이 앱을 동기화해서 노는 사람들은 FOLLOW 버튼만 누르는 케이스가 대부분일테니, 그런 사람들에게 익숙한(하다못해 친숙한) UI를 만들자는 생각을 한 거죠. 그렇게 방침을 정하고 나니 어떤 것을 만들지는 비교적 수월하게 결정할 수 있었습니다.

미디 쪽의 디바이스를 어느 정도 아시는 분들은 이미 아실 것 같긴 하지만, 사실 BITNA의 현재 UI에는 Korg 사의 컨트롤러 디자인이 반영되어 있습니다. 제가 개인적으로 Korg사의 컨트롤러들을 좋아하거든요. Tempo의 붉은 LED라든가, 버튼을 탭했을 때 붉게 점등되는 부분 등은 거의 그대로 가져온 셈이죠. 문자 표시 창도 그대로 반영할까 하다가, 비슷하게 만들어 봤더니 너무 눈에 안 들어오더라구요. 그래서 LED 스타일의 폰트 대신 그냥 일반적인 폰트를 사용하는 쪽을 택했습니다.

 

BITNA앱과 Korg사의 microKONTROL입니다. 결과물은 별로 닮아보이지 않는군요 (...)

 

 

#.
두 번째 문제는 약간 시간이 필요한 문제이기도 했습니다. 시각적 효과라는 것이 고민해서 여러 효과를 만들어 보고, 사람들의 반응을 체크해서 괜찮은 효과를 골라내는 반복적이고 시간이 드는 작업이 될 게 뻔했거든요. 그래서 이 부분은 약간 얄팍하게 접근하기로 했는데 ... 나름의 해법은 전광판 기능을 추가하는 것이었습니다. 물론 요즘은 전광판의 종류도 굉장히 많아지고, 전광판의 디자인도 개성있는 것들이 많습니다. 제가 디자이너도 아니고 디자인에 어떤 감각이 있는 것도 아니다보니 그런 것을 고민해서 만들 수 있는 상황은 아니라는 판단이 섰구요. 고민 끝에 '동기화가 가능하다는 특성을 살려서 여러 개의 기기를 마치 대형 전광판처럼 사용할 수 있게- 텍스트가 연속적으로 흘러가게 하는 기능을 구현하자!'라는 아이디어를 떠올렸습니다. 이거라면 다른 전광판 앱과 확실히 차별화가 가능한 요소이면서, 디자인적인 고민은 좀 덜 해도 될 것 같다는 생각이 들었습니다. 그 외에도 패턴이 추가되긴 했습니다만(Love, Box, Line 등이 이 과정에서 새로 추가되었습니다) 사실 그 패턴들은 그냥 재미로 넣은 측면이 강합니다.

2011년 11월이 되어서야 거의 1년여만에 작업을 재개했고, 먼저 첫 번째 문제와 두 번째 문제에 대한 제 나름의 답을 적용하기 시작했습니다. (세 번째 문제에 대해서는 아래에 나옵니다) 그 과정에서 UI 개선과 전광판 기능 추가와 함께 대규모 사용자나 대규모 텍스트에 대한 지원 부분도 추가했고(현재는 이론상 5만여대가 동기화 가능하고, 텍스트는 48만자를 쓸 수 있습니다. 하지만 과연 그럴 일이 있을까요? ;;), 광고 등도 추가했습니다. 사실 광고는 광고 수입에 대한 기대... 가 완전히 없다고는 할 수 없고요; 그것도 이유이긴 하지만 또 하나의 이유는 사용자 통계를 얻고 싶어서였습니다. 사용자 통계를 내는 로직을 은밀히 심을 수도 있었지만 그런건 제 성미에 맞질 않았고, 아예 대놓고 광고를 뿌려버리면 사용자가 '아 광고를 서버에서 받아오는구나'라고 확실히 알 수 있으니까요. 물론 기기에서 광고를 받게 되면 광고측 서버에 로그가 남게 되고, 그 데이터를 가지고 저는 얼마나 많은 사용자가 BITNA를 사용하는지 대략적으로 추측할 수 있으니까 더 낫지 않을까 하고 생각했죠.

나중에야 알게 됐지만 저사양 기기에서는 광고를 실으면 꽤 무거운 것 같더라구요. 하지만 아직 남은 작업이 많은 관계로 일단은 내버려두었습니다. (...)

 

 

#.
BITNA의 첫 릴리즈로부터, 현재 시점까지 BITNA 자체가 크게 히트하진 못했습니다. 기존의 전광판이나 야광봉 앱과도 좀 다른 개념이고, 그렇다고 시각적인 효과가 매우 훌륭하다던가 이런 것도 아니고, UI도 좀 괴상하고, 한 마디로 대중화되기 어려운 앱이니까요. 결국 성공적인 앱을 만들겠다는 목적 없이 아이디어를 그냥저냥 마음 가는대로 적용하다보니 이런 결과물이 나왔고, 사용자들 또한 그에 맞는 반응을 보이고 있는게 아닐까 하는 생각이 듭니다.

어쨌든 최근 들어서는 이용자가 꽤 증가하긴 해서, 이용자 통계를 보면 하루에 1000여명 이상이 사용하고 있습니다. 하지만 아이튠즈 순위에서 Top 10에 들었다든가 한 적은 없습니다. 아, 최근에 유니버셜 앱 버전으로 변경한 탓인지 앱스토어의 아이패드 앱 순위에 올라간 적은 있었습니다 (...)

딱히 아이패드용으로 더 유용한 기능을 넣은 것도 아닌데 이렇게 순위에 올라가니 이건 기분이 좋다고도 할 수 없고 나쁘다고도 할 수 없고 ... 난감하네요.

지인이 개그콘서트에 BITNA가 등장했다고 해서 직접 찾아보고 캡쳐했습니다. 기왕에 쓰실 거면 좀 더 화려한 패턴을 사용하시지 왜 가장 밋밋한 패턴을... 총체적으로 애매하네요 orz

 

 

#.
그리고 최근 한 달 동안에는 세 번째 문제에 도전했습니다.

클라우드 서비스를 통해서 문제를 해결하려고 마음먹고 나니, 의외로 여러 클라우드 서비스에서 서버나 서비스를 운용하는데 관련된 자료를 찾아보기가 어렵더라구요. 있다고 해도 그 자료의 내용을 서비스 별로 함께 비교하기가 상당히 어려워서 어떤 클라우드 서비스를 선택해야 하는지 결정하기가 어려웠습니다. 사실 대중적으로 알려진 클라우드 서비스들는 '클라우드 서비스'라는 이름만 달고 있을 뿐이지, 실제 제공하는 기능들의 면면을 보면 특징이나 추구하는 바가 서비스마다 서로 완전히 다른 경우가 많습니다. 클라우드 서비스를 도입하고 싶다면 직접 몇 가지 서비스를 조사해보고 그 서비스에 작은 프로젝트를 올려본다든지의 검토 과정이 필수적인 것 같습니다.

어쨌든 그래서 - 무식하게 직접 몇 개의 클라우드 서비스를 테스트해보기로 했습니다. 저는 Mug 프로젝트를 진행하면서 Python 기반의 웹 프레임워크인 Django를 사용했었는데, 이 프레임워크가 워낙 마음에 들어서 앞으로도 계속 사용하기로 결정을 했기 때문에 Python 웹 프로그래밍이 가능한 클라우드 호스팅 서비스를 찾았습니다. 그 과정에서 Python 웹 프로그래밍이 가능한 호스팅/플랫폼을 제공하는 여러(그리고 다양한) 클라우드 서비스가 있다는 것과, 그 중 상당수가 기본 기능을 무료로 시험해 볼 수 있도록 해 준다는 사실도 알게 되었습니다.

최종적으로 테스트 대상을 아마존의 EC2, 구글의 Google App Engine, Heroku 등으로 좁혔습니다. EC2는 가상화 서비스를 직접 제공하고 있고(실제 OS가 구동되는 가상 머신 서버를 운영하는 방식), GAE나 Heroku는 개발자가 개발한 프로그램을 해당 서비스의 서버에 배포해서 운영할 수 있는(이쪽은 직접 서버를 운영할 필요는 없습니다) 환경을 제공합니다. 그런 다음에는, 각 서비스의 실제 성능을 (대략적으로라도) 파악해야 했습니다. 크게 두 가지 방식이었는데, 간단한 프로그램 코드를 작성해서 각각의 서비스에 올려보고 해당 서버의 가장 가까운 곳에 있는 EC2 가상 머신을 통해 접속해서 반응 속도를 체크하는 방식과, 거꾸로 해당 서비스가 있는 지역의 특정 서버에 요청을 날려서 반응을 측정하는 방식이었습니다. 뭐 이외에도 CPU 성능이나 디스크 입출력에 대한 간단한 테스트도 수행하긴 했습니다만, 일단 제게 가장 중요한 성능 요소는 네트워크 반응 속도였습니다. 네트워크 반응 속도를 체크하는 과정에서는 직접 OS를 통해 각종 유틸리티를 활용할 수 있는 환경을 제공해 주는 EC2 서비스가 정말 큰 도움이 되었습니다.

그리고 어쨌든 최종적으로, 손은 많이 가지만 다양한 방식으로 구성할 수 있는 EC2를 사용하기로 결정했습니다.

 

#.
2012년 3월, API 서버 개발이 끝났고, 아마존 EC2 서버에 배포 작업도 완료되었습니다. 그리고 앱스토어에는 BITNA 2.0 버전을 제출하고 승인을 기다리고 있습니다. 안드로이드의 BITNA 2.0 버전은 이미 릴리즈할 준비가 끝났지만, iOS 버전과의 동시 릴리즈를 위해서 아직 배포를 하지 않고 있는 상태이구요.

 

#.
이게 현재까지의 이야기입니다.

이 앱이 앞으로 어디로 갈지, 과연 어디까지 갈 수 있을지는 저도 잘 모르겠습니다. 훗날 어딘가의 콘서트장에서 수천 명이 BITNA를 사용해 떼거지로 빛의 물결을 만드는 모습을 제가 보게 되는 날이 올 수 있을지도 잘 모르겠고요. 무난한(혹은 얄팍한) 컨셉의 앱을 만들어서 돈을 벌거나 유명해지는 것보다는, 뭔가 컨셉 자체가 이상하거나 심지어는 괴상하더라도 독특한 앱을 만들어 보고 싶었습니다. 그리고 그런 앱을 만들어보겠다는 생각이 지금 세계 각국 어딘가의 IDC에서 실행되고 있는 아마존 EC2 서버 인스턴스 7개, iOS와 안드로이드 앱으로 구체화되었고요.

 

#.
문득, 이 정도의 앱을 개발하고 앱을 위한 글로벌한 인프라를 구축하는데 그리 큰 비용도, 큰 노력도 들지 않는 시대를 살고 있다고 생각하니 약간 감동적이기까지 합니다. 저는 맥북에어 한 대로 이 모든 프로그램을 개발하고 있고, 아마존 EC2 서버에도 (1년이라는 제한은 있지만, 어쨌든 지금은) 호스팅 비용을 내고 있지 않습니다. 한국에 있는 백업 서버 한 대에만 월 25,000원 정도의 호스팅 비용을 물고 있고요.

제 아이디어로 세계에 얼마만큼의 영향을 끼칠 수 있을까요. 아니, 어쩌면 쓸데없고 이상한 아이디어 취급을 받을 지도 모르죠. 그렇지만, 개인이 이렇게 손쉽게 전 세계에 영향을 끼칠 수 있는 가능성이 있는 시대를 살고 있다는 감각만큼은, 실로 멋집니다.

 

스티브 잡스, 제프 베조스, 귀도 반 로섬에게 감사하고 싶은 밤입니다 : )