사용자 도구

사이트 도구


사이드바

blog:start

시연빌드의 위험성

시연빌드

시연빌드는 본격적으로 프로덕션 단계에 들어가기 전에 더 적은 비용을 들여 프로덕션을 고려하지 않은 구현을 통해 미래에 개발할 게임을 실제로 동작하는 상태로 만들어보는 겁니다. 여기서 분명 누군가 의문을 가질 수 있습니다. 그런 것을 우리는 좀 더 고상한 단어로 '프로토타입'이라고 하지 않느냐고요. 네. 맞습니다. 방금 이야기한 목표를 달성하기 위해 우리가 개발하는 것을 '프로토타입' 또는 '프로토타입 빌드'라고 말하고 이 행동을 멋지게 '프로토타이핑'이라고 이야기합니다. 하지만 시연빌드는 이와는 조금 다릅니다. 프로토타입이 개발팀 내부를 향한 용어라면 '시연빌드'는 개발팀에 적대적인 팀 외부를 향한 용어입니다. 말 그대로 팀에 적대적인 팀 외부에 시연하기 위한 빌드를 말합니다. 제작방식은 비슷합니다. 프로덕션을 고려하지 않고 최대한 싼 비용으로 개발합니다. 하지만 팀에 적대적인 환경에 시연해야 하므로 팀 내에서 적당히 눈감아줄만한 부분에 갑작스레 비용을 집중하기도 하고 게임의 핵심을 공유하기보다는 게임이 완전히 완성됐을 때의 상태를 만드는데 집중하기도 합니다. 그래서 프로토타입빌드와는 달리 시연빌드는 별도로 'Siyeon Build'라는 별도 용어를 사용해야 할지도 모릅니다.

장점

프로토타입에 비해 시연빌드는 팀 외부를 설득하기에 적당합니다. 팀 외부는 여러 층으로 구성되어 있는데 그 중 하나는 팀에 돈을 대는 스폰서 또는 스폰서처럼 행동하는 경영진입니다. 이들은 게임에 대한 이해가 있다고 스스로 생각하고 있지만 게임의 핵심을 보여주면 실제 게임과 구분하지 못하고 아직 게임이 엉망진창이거나 개발팀이 아직 프로젝트의 방향을 결정하지 못했다고 생각합니다. 때문에 이들에게 의사를 전달하기 위해서는 실제 게임에 가까운 형태를 보여줘야 하고 이는 제한적으로나마 실제로 동작해야 합니다. 이 정도가 되면 개발팀 내부를 설득하는 일은 쉽습니다. 디자이너들은 이 상태를 양산하기 위해 어떤 작업이 필요한지 거의 정확하게 예상할 수 있고 엔지니어들 역시 이미 프로덕션 코드를 이미 머릿속에 그리고 있을지도 모릅니다. 아티스트들은 이미 과거부터 미래의 프로덕션에 사용할 에셋을 제작하기 시작했습니다. 같은 빌드로 스폰서들을 설득할 수도 있고 업계 고위 관계자들에게 동작하는 상태를 보여주고 의미있는 의견을 구할 수도 있습니다. 출시까지는 아직 흘러야 할 세월이 많이 남았지만 마치 게임에 현 시대에 존재하는 듯한 착각을 불러일으켜 모두를 기쁘게 하는 평가를 들을 여지도 있습니다.

공포

다만 이 시연빌드가 이 시연빌드의 상태에 대한 이해도가 상대적으로 낮은 사람들에게 공유된다는 점은 위험합니다. 너무 무섭지만 실제로 종종 일어나는 일입니다. 팀 외부에서 시연빌드를 요구하고 시연빌드를 시연 받는 분들 상당수는 시연빌드와 프로덕션빌드의 차이를 이해하지 못합니다. 이미 사람들을 태우고 테스트트랙을 주행할 수 있는 사이버트럭이 있는데 왜 당장 양산을 시작하지 않느냐는 이야기와 비슷합니다. 프로덕션에 사용하기에는 위험한 온갖 기능을 아슬아슬하게 이어붙여 제한된 환경과 제한된 시나리오상에서 동작하게 만들어놨더니 시연을 받는 분이 대뜸 '이제 거의 완성된거같으니 플랫폼 붙여서 출시합시다'라고 말한다거나 '아직 준비되지 않은 컨텐츠는 출시 후 +4주 내에 업데이트하면 되지 않겠냐는 등 아직 프로덕션 단계에 진입하지도 않은 프로젝트의 '시연빌드'를 보고 장밋빛 환상에 빠져 개발팀이 감당할 수 없는 요구사항을 늘어놓을 수 있습니다.

그래서 '프로토타입'이 아닌 '시연빌드'는 위험합니다. 만약 이를 개발해야 한다면 방금 이야기한 공포가 현실이 되지 않도록 기대치를 잘 조절하고 회사 전체에 개발과정을 이해시켜야만 합니다.

· 2019-11-24 13:38

튜토리얼

너절한 이야기 대신 결론으로 바로 넘어가세요.

미신

게임 튜토리얼 하면 반사적으로 튀어나오는 미신 같은 이야기. 누구나 이해할 수 있고 게임의 핵심을 잘 설명해야 한다는 것. 실제로 그런지 생각해본 적이 있습니다. 과연 누구나 이해할 수 있는 설명이 가능한 것인지 의심스러웠습니다. 가령 글을 쓸 때 독자를 예상해 그들에게 맞는 표현을 사용하라는 이야기를 듣곤 합니다. 하다못해 팀에서 기획서를 작성할 때도 그 기획서를 읽을 사람이 어떤 직군인지, 심지어는 누구인지에 따라 설명 방법이나 설명 순서를 바꾸는 요령을 이야기하기도 합니다. 그런데 유독 튜토리얼은 누구나 이해할 수 있어야 한다는 요구사항을 반사적으로 되뇌이는 상황이 올바른지 의심해보게 됐습니다.

가령 어떤 사람은 게임에 익숙하고 또 다른 사람들은 익숙하지 않습니다. 튜토리얼의 미신에 따라 게임을 처음 해 보는 사람이 게임을 실행하고 있을 수도 있습니다. 하지만 이런 일은 실제로는 일어나지도 않을 뿐더러 이 모든 상황을 고려해 만든 튜토리얼은 게임의 주 고객들을 좌절시킵니다. 가령 현대의 모바일게임에 익숙한 사용자가 게임을 시작한다 칩시다. 이 사용자는 이미 게임 시작 전에 나오는 뻔하디 뻔한 컷씬을 생략하고 빨리 메인화면으로 넘어가 어떤 컨텐츠들이 있는지 눌러보고 싶어합니다. 그런데 컷씬에 섞여있는 망할놈의 튜토리얼은 나에게 화면 왼쪽 아래에 있는 가상패드를 움직여 캐릭터를 몇 발자국 걷게 하고 또 오른쪽 아래에 있는 아직 하나만 열려 있는 허접한 스킬버튼을 몇 번 눌러보게 합니다. 아니 이런건 오늘 아침에 플레이한 게임에도 똑같이 하던 동작이니까 이제 그만 넘어가줬으면 싶지만 튜토리얼을 끝내기 전에는 게임이 다음으로 넘어가질 않습니다. 이 튜토리얼이 길어질수록 사용자는 이 과정 자체에 좌절합니다. 루프물 장르의 영화나 소설에서 반복되는 상황을 끝없이 견디는 주인공은 일반인들에겐 없는 강력한 멘탈을 가지고 있습니다. 하지만 보통 사람인 우리 사용자들에게 이미 수 십 번은 반복했을 똑같은 동작을 가르치는 튜토리얼을 또 시키면 이들은 정신이 붕괴되어버릴지도 모릅니다. 더이상 못 견디고 게임을 꺼버릴 겁니다. 운이 좋다면 삭제되지 않을 수도 있지만 항상 운이 좋을 수 있는 게임이 얼마나 될른지 모르겠습니다.

먼 미래에 출시될 디아블로4를 생각해봅시다. 부푼 기대를 안고 지난 수 십 년에 걸쳐 마우스와 키보드 조작을 단련한 지금 당장이라도 검지손가락으로 악마를 때려잡을 준비가 된 혈압이 올라 현기증을 호소하는 사람들 앞에 모든 UI를 잠가놓고 '마우스 커서를 움직여 몬스터를 클릭하십시오' 같은 튜토리얼을 시도했다가는 포럼이 욕설로 도배되든지 마우스를 부숴버리든지 적어도 둘 중 한가지 사건은 일어날겁니다. 튜토리얼 뿐만 아니라 그 어떤 게임 장치도 모든 사용자에게 알맞게 구성하는 건 불가능합니다. 누구나 이해할 수 있는 튜토리얼, 원숭이도 이해할 수 있는 기획서 같은 것은 전설로만 전해내려오고 그 누구도 실체를 본 적 없습니다. 누군가 이런걸 요구한다면 최대한 빨리 도망치는 것 이외에는 방법이 없습니다.

타겟팅

그 어떤 게임 장치도 모든 사람에게 맞출 수 없기 때문에 튜토리얼을 설계하기에 앞서 반드시 고객을 선택해야 합니다. 애초에 프로젝트를 시작하기 전에 우리의 주 고객은 어떤 사람들인지 정의해 둬야 하지만 실제 프로젝트 제안에 너무 쉽게 '우리는 백화점 게임이므로 모든 종류의 고객을 타겟으로 한다'는 엔씨소프트 도서관 바닥에 난 구멍으로 떨어져 2층 나무데크에 처박혀도 시원찮을 소리를 당당히 하는 사람들이 널려있는 마당에 튜토리얼을 제작할 시점 - 안타깝게도 런칭 직전 - 까지 주요 고객이 명확하지 않다고 해서 그렇게 놀랄 것은 없습니다. 아직 완전히 늦지는 않았습니다. 게임의 나머지 부분은 핵심 고객을 설정하지 못해 제각각으로 만들어져 결국 게임에 가장 익숙한 고객들만이 접근하게 되겠지만 적어도 튜토리얼만은 이 참사를 벗어날 가능성이 아직은 있습니다. 이 튜토리얼을 플레이할, 이 튜토리얼에서 이탈하지 않고 무사히 메인화면에 도달할 혹은 도달해야만 하는 고객들이 어떤 사람인지 정합니다. 가령 이미 그 고객의 폰은 왼쪽 아랫부분을 하도 눌러대서 화면이 변색된 상태일 수 있습니다. 이런 사람들에게 캐릭터를 움직여보라고 하면 혈압이 올라 폰을 내던질겁니다. 이들에게는 - 만약 게임에 그런게 있다면 - 전투나 스킬시스템의 특징, 핵심 성장구조 정도를 알려주고 나머지는 스스로 둘러보게 하는 편이 나을 겁니다. '모든 사람들이 이해할만한' 튜토리얼을 만드느라 시간을 소모하지 않아도 되고 이미 다 아는 것을 몇 분에 걸쳐 멍청한 방식으로 설명하는 튜토리얼에 좌절하지 않아도 됩니다.

너절하게 이야기했지만 요약하면 이렇습니다.

결론

  1. 모든 고객을 만족시키는 튜토리얼은 부두다. 이런 주장을 들으면 도망쳐라.
  2. 고객은 프로젝트 시작 단계에 이미 특정되어 있어야 한다.
  3. 만약 그렇지 않다면 하는 수 없이 튜토리얼 제작 전에 이 튜토리얼을 통과할 고객을 특정해야 한다. 이미 도망치기엔 늦었다.
· 2019-11-25 11:54

문단간격

결론은 맨 아래에 있습니다.

자포자기

십 수년 전에 기획서는 모두 위키에 작성하게 될 거라고 생각했습니다. 개발팀 내에서 작성하는 문서는 결국 누군가에게 공유하기 위한 것이었습니다. 공유하고 설득하고 개발을 진행하고 보고하는 등 맥락과 목적은 조금씩 다르지만 결국 미래의 나를 포함한 누군가에게 공유되어야만 했습니다. 단지 '문서'라는 이름 때문에 습관처럼 워드를 사용해 작성하고 있었지만 이 도구는 '공유'의 어떤 면도 도와준다고 보기 어려웠습니다. 그냥 공유하기 어려웠습니다. 문서가 변경되면 변경사항을 다시 공유하기도 어려웠고 어디가 변경됐다고 알려주기도 어려웠고 어느 것이 최신 버전인지 알려주기도 어려웠고 또 공유 자체를 일관된 방식으로 하기도 어려웠습니다. 누군가는 메일에 첨부했고 누군가는 메신저로 전송했으며 또 다른 누군가는 공유폴더에 복사해놓고 그 주소를 보내기도 했습니다. 예상하시다시피 이 모든 행동과 결과로 항상 워드로 작성한 문서를 공유하려면 항상 혼돈을 겪어야만 했습니다. 공유한 이후에도 결코 혼돈은 끝나지 않았고요. 때문에 위키는 이런 문제를 말끔하게 해결할 방법이라고 생각했습니다. 하지만 시간이 흐른 지금 모든 사람들을 워드에서 끌어내 위키에 문서를 작성하게 떠미는 일 역시 그리 간단하지 않은 일임을 절실히 깨달았고 더이상 그런 시도를 하지 않게 됐습니다. 다만 그렇게 익숙한 워드로 문서를 작성할 때 일어날 수 있는 여러 가지 문제를 완화할 부드러운 방법을 찾아 제안하고 실천하는 정도가 내가 팀에서 할 수 있는 적당한 수준의 기여라는 사실도 깊히 깨달았습니다. 그 연장에서 워드 문서의 기본 본문서식 두 가지의 차이를 이야기하려고 합니다.

표준, 간격 없음

워드의 기본 스타일에는 본문 서식이 두 개 있습니다. '표준'과 '간격 없음'입니다. 이들 둘은 동양식 문서와 서양식 문서의 특징을 구분하고 잘 정돈'되어 보이는 문서를 만드는데 핵심 역할을 합니다. '표준'은 문단 사이에 한 줄보다 작은 간격이 생깁니다. 그래서 문단을 구분할 때 엔터를 한 번 누르면 엔터를 두 번 누른 휑한 간격보다는 좁은 알맞게 보기 좋은 간격이 생깁니다. '간격 없음'은 이 문단 사이의 간격이 없이 엔터키를 누르면 한 줄에 해당하는 줄간격만 생깁니다. 그래서 엔터를 한 번 누르면 바로 이어서 다음 줄에 이어서 글을 작성할 수 있고 문단 간격이 없으므로 빽빽한 상태가 됩니다.

'표준'은 마치 이 블로그 페이지에 문단을 구분하는 것처럼 글 덩어리 하나와 다른 글 덩어리 하나를 구분할 때 사용합니다. 문단 사이에 엔터를 한 번만 누르면 예쁜 간격이 생깁니다. 줄간격이 없을 때 엔터를 두 번 누른 휑한 것보다 좁지만 문단 간격이 없는 글에서 줄간격만으로 구분하는 답답한 간격보다는 약간 더 넓은 딱 알맞은 너비입니다. '간격 없음'은 '번호 매기기'나 '글머리 기호'로 구분한 목록을 만들 때 사용합니다. 만약 '표준' 본문 스타일로 번호 매기기 기능을 사용해 목록을 작성하면 목록의 구성요소 사이에 휑한 공간이 생길 겁니다. 이 공간은 문단 사이를 예쁘게 구분하기에는 적당한 간격이지만 각각의 줄로 구분된 목록 사이를 구분하기에는 너무 넓은 간격입니다. 문서를 읽는 입장에서도 목록은 서로 가까이 붙어있어야 목록으로 인식하기 쉽습니다. 그러려면 목록을 작성할 때는 본문 스타일을 '간격 없음'으로 바꾼 다음 목록이 끝나고 다시 서술로 이어질 때는 '표준'으로 변경해서 용도에 맞는 본문 스타일을 사용해야 합니다.

아무말

개인적으로는 이 차이가 서양식 문서와 동양식 문서작성 문화의 차이에서 온다고 생각합니다. 서양식 보고서는 주로 서술식으로 작성됩니다. 보존연한이 끝나 공개되는 오래된 정부 보고서나 논문, 업계의 전설들이 산업의 여명기에 작성한 기획서들을 살펴보면 여러 문단이 길게 늘어서 있습니다. 문장을 통해 설명하고 설명이 끝나면 다음 문단으로 넘어가 설명을 이어가거나 새로운 주제를 설명합니다. 반면 동양의 문서는 개조식으로 작성되어 있습니다. 가령 행정기관 웹사이트에 아무렇게나 널려있는 hwp 파일을 열어보면 모든 글자들이 답답한 표 안에 갇혀있거나 글자는 문장을 이루는 대신 글 머리 기호를 앞에 놓고 거의 음슴체에 가까운 문장으로 짧게 끝맺는 형식으로 작성되어 있습니다. 이 차이 때문에 서술식 문서에는 '표준' 본문 스타일이 어울리지만 개조식 문서에는 '간격 없음' 본문 스타일이 어울립니다. 우리가 실제로 작성하는 문서는 이들이 적당한 비율로 섞여 있으므로 작성하는 부분에 따라 본문 스타일을 바꿔 가며 작성하는 것이 좋습니다.

결론

  1. 서술식: 표준
  2. 개조식: 간격 없음
· 2019-11-24 14:22

바이크컴퓨터비즈니스

모험 실패

지난주에 트림원 바이크컴퓨터 사용기를 작성한 다음 다른 사람들이 작성한 사용기가 있을지 검색해봤습니다. 결과 대부분은 광고성 게시물이었는데 일부는 아직 제품을 사용해보기도 전에 제품 겉모양과 주요 화면 사진을 올려놓고 앞으로가 기대된다고 하는 내용이기도 했습니다. 당연히 별 도움이 안 됐습니다. 그러다가 문득 한 자전거동호회 게시판에서 바이크컴퓨터를 잘 만드는 일이 그렇게 어려운 일인지 의문을 가지는 글을 봤습니다.가민이나 와후가 만드는 기계를 보면 그리 훌륭하지 않은데 이런 기계는 간단히 생각하면 GPS센서를 비롯한 몇몇 센서를 내장하고 이들의 값을 기록해 fit 파일로 뽑아주기만 하면 될 것 같은데 왜 이리 문제가 많은 제품이 시장에서 지배적인 위치를 차지하고 있는지 알 수 없다는 내용이었습니다.

불만

사실 지금 주력으로 사용하는 가민 엣지 바이크컴퓨터는 사용할수록 불만이 쌓여 갑니다. 지난 퍼머넌트1)에는 완주를 얼마 안 남기고 짧은 터널 하나를 지나는데 코스가 먹통이 돼버렸습니다. 코스 시작부분과 끝부분은 보통 시내주행인 경우가 많아 코스파일을 참고하지 않기 곤란했습니다. 다행히도 함께 주행한 동료의 똑같은 가민 기계는 같은 상황에서 먹통 상태가 풀려 별 일 없이 완주할 수 있었습니다만 제 가민은 거의 끝날 무렵에야 코스를 다시 참조할 수 있었습니다. 그나마 신호대기할 때 기계를 껐다 켜서 정상이 된 것이었습니다.

그나마 코스 기능은 누구나 상상하는 자동차용 내비게이션의 아름다운 턴 바이 턴 내비게이션과는 거리가 먼 오픈스트리트맵에 코스 궤적을 보여주고 이탈 경로를 띄워주는 수준일 뿐입니다. 프로필 개념은 GPS센서를 제어하고 데이터스크린 종류를 자동으로 변경해주지만 또 센서를 변경해주지는 않습니다. 인도어 트레이닝을 할 때도 계속해서 자전거 뒷바퀴에 달린 속도센서를 검색하고 배터리 1%가 아쉬운 장거리라이딩에서는 인도어 트레이너를 찾고 있습니다. 최근에는 그나마 개선됐지만 코스 파일을 집어넣으려면 컴퓨터에 연결해서 GPX 파일을 수동으로 복사해야 했고 2백킬로미터가 넘는 큰 코스파일을 로딩할라 치면 이게 기계가 멈춘건지 아니면 그냥 시간이 오래 걸릴 뿐인지 구분하기도 어려웠습니다.제조사에서 담아주는 맵은 또 어떤가요. 전 세계를 길 몇 개로 축소한 실제 주행에 아무 도움이 안되는 맵이 기본으로 들어있어 맵을 전문적으로 제작하는 기능이 없는 수입사에서 제공하는 맵을 사용하거나 오픈스트리트맵을 적당한 파일 크기로 잘라주는 서비스를 사용해야만 합니다. 맵을 전문적으로 제작하는 회사들의 지도에 비해 우울한 수준이지만 그거라도 없으면 우리는 간신히 전국의 고속도라만 표시된 수준의 맵을 사용해야만 합니다.

이런 온갖 문제에도 불구하고 가민 기계를 계속해서 사용하는 이유가 있긴 합니다. 일단 이 비즈니스를 거의 처음 만들어낸 회사 중 하나이다 보니 지금까지 긴 시간에 걸쳐 시행착오를 겪었습니다. 덕분에 바닥부터 시작하려고 보면 막막할 법도 한 싸이클링 다이나믻그나 프로필 개념, 데이터필드 구성 같은 기초적인 구성을 빠뜨리지 않습니다. 너무 당연한 기능 같지만 정작 다른 기계에는 쉽게 누락돼있습니다. 또 같은 기계를 사용하는 사람들이 많아 문제가 생겼을 때 도움을 받기도 쉬운 편입니다. 그래서 많은 문제가 있음에도 그럭저럭 버틸 수 있는 것이기도 하고요. 가령 장거리 라이딩 후 저장하려다가 그대로 기계가 벽돌이 됐을 때 당황하지 않고 파일시스템에서 삭제 플래그가 붙은 임시 파일을 복원해내는 것은 아마도 가민 기계 사용자가 더 적었다면 얻기 힘든 도움이었을지도 모릅니다. 물론 애초에 기계가 먹통이 되지 않았어야 하지만요.

상황이 이렇다 보니 위에서 이야기한 바이크컴퓨터를 더 잘 만들어낼만한 회사가 없을지 의심해보는 것도 당연합니다. 하지만 트림원 바이크컴퓨터의 꼴을 보며 이 비즈니스는 생각보다 간단하지 않다는 결론을 내렸습니다. 슬슬 4년째 써 오고 있는 가민 엣지 520의 교체주기가 앞으로 한 두 시즌 안에 돌아올 것 같은데 아마도 높은 확률로 다시 가민 기계를 살 겁니다. 이유를 나열해보겠습니다.

요구사항

일단 하드웨어부터 그리 간단하지 않습니다. GPS센서, 기압계, 나침반, 온도센서, 무선모뎀, 무션센서, 주변광센서, 스토리지, CPU, 배터리를 적당히 작은 공간에 밀어넣은 기계를 상상하는 것은 간단할 법도 합니다. 여기에 이 기계는 지속적인 진동을 견딜 수 있어야 하고 낙차 같은 강한 충격으로부터 망가지지 않아야 합니다. 또 기온 범위보다 더 넓은 온도 범위에서도 동작해야 하고 그러면서도 너무 무겁지는 않아야 합니다. 잠수 수준의 방수기능은 필요하지 않지만 폭우 속에서도 동작해야 하고 연속으로 며칠씩 - 적어도 90시간 - 동작할 수 있어야 합니다. 여기까지가 최소한의 하드웨어 요구사항입니다.

또 요구사항

다음은 소프트웨어인데 일단 이 장치를 구동할 소프트웨어가 있어야 합니다. 라이딩을 시작하고 종료하고 랩을 기록하고 현재 위치를 지도 위에 표시하고 현재 주행 궤적과 구간정보를 항상 비교해 구간에 진입하면 별도로 시간을 측정하고 여러 센서로부터 얻은 정보를 화면에 표시하되 중간에 센서와 통신이 끊기거나 잘못된 값이 입력될 때 이를 곧이곧대로 화면에 표시하지 않고 적당한 값을 실시간으로 추측해야 합니다. 사용자가 필요한 값을 화면에 표시하도록 화면 구성을 변경할 수 있어야 하고 표준을 잘 준수하지 않지만 묘하게 사용자가 많은 이상한 센서를 잘 지원해야 합니다. 때로는 다른 회사에서 만든 하드웨어의 특정 펌웨어 리비전에서 발생한 문제를 바이크컴퓨터 수준에서 해결해야 할 수도 있습니다.

또 또 요구사항

여기에 세월이 흘러 스마트폰과 연동기능이 필요해졌습니다. 스마트폰으로부터 날씨를 받아 표시하고 전화나 텍스트메시지를 표시해야 합니다. 스마트폰을 통해 종료된 라이딩을 기록하고 실시간으로 함께 라이딩하는 사람들과 떨어진 거리를 표시하고 기록을 온라인에 업로드하고 온라인으로부터 사용자가 관심있다고 표시한 구간정보를 실시간으로 다운로드할 수도 있어야 합니다. 이런 기능을 하는 앱은 적어도 아이폰과 안드로이드폰용으로 각각 개발해야 하고 다른 서비스에 연동하려면 앱과 다른 서비스 사이를 이어주는 웹서비스를 개발해야 할 수도 있습니다. 스트라바처럼 고도정보를 보정하기 위해 별도의 지리정보데이터를 운용해야 할 수도 있고 가민커넥트처럼 같은 장비를 사용하는 사람들의 단순한 소셜네트워크서비스를 만들어야 할 수도 있습니다.

결론

적어놓고 보니 확실히 그리 간단한 비즈니스는 아닙니다. 바이크컴퓨터 하드웨어와 그걸 구동할 소프트웨어를 한 벌만 만들면 진입할 수 있었던 비즈니스였던 시대가 분명 있었을 겁니다. 하지만 현대의 바이크컴퓨터비즈니스는 생각보다 많은 플랫폼에 걸쳐 생각보다 많은 하드웨어와 소프트웨어를 개발해야 하고 여기에 생각보다 많은 시행착오를 거쳐야 합니다. 이걸 단기간에 따라잡기는 쉽지 않습니다. 얼마전에 받은 한국 회사의 바이크컴퓨터는 엉망이지만 그렇게까지 기분 나빠하지는 않았습니다. 이제 이 비즈니스가 그리 쉽게 기존 업계를 따라갈 수 있는 비즈니스가 아니라는 사실을 잘 알게 되었으니까요. 이번 시행착오를 통해 앞으로 바이크컴퓨터를 구입할 때 좀 더 보수적인 시각으로 기계를 알아볼 겁니다. 이런 소비자의 시각까지 다해져 이 비즈니스는 정말로 쉽게 진입할 수 없는 곳이 되겠다 싶은 생각입니다.

· 2019-11-24 11:26

트림원 바이크컴퓨터 사용기

빠른 결론: 사지마세요. 사용기 부분만 읽으려면 현실부터 시작하세요. 아니면 결론만 보세요.

기대

1년 전에 킥스타터에 '트림원'이라는 바이크컴퓨터 백킹2)이 올라왔습니다. 그때까지도 바이크컴퓨터는 대강 가민 엣지 시리즈가 가장 많이 사용됐습니다. 새롭게 나타난 와후 엘리먼트가 그나마 괜찮아 보였고 브라이튼을 비롯한 군소 장치들은 저걸 도대체 왜 돈 내고 구입하는지 이해하기 어려운 수준의 적은 사용자 수와 신뢰성 없는 동작을 보여줬습니다. 그렇다고 가민 엣지 시리즈가 훌륭했던 것은 아닙니다. 바이크컴퓨터 시장에 거의 처음부터 있던 덕분에 오랜 기간에 걸쳐 적당한 수준의 기능과 신뢰성을 확보한 정도입니다. 현대에 이르러 배터리시간, 코스 내비게이션, 외부장치 연결 기능은 형편 없는 수준이었습니다. 배터리시간을 제외한 나머지 주제는 가민 엣지 바이크컴퓨터에 비해 스마트폰이 압도적으로 더 잘 했고 그렇게 몇 년 지나자 바닥에 떨어져 깨인 눈물젖은 $1000 짜리 스마트폰과 멍청한 가민 엣지 사이에 비집을 만한 기회가 생기는 듯 보였습니다. 그 자리에 트림원 바이크컴퓨터가 나타났습니다.

가민 엣지를 사용하는 사람들의 배터리시간 평가는 딱 두 가지입니다. 가민 배터리가 한번도 부족해본 적이 없는 사람들과 '항상' 배터리가 부족한 사람들입니다. 제 경우는 후자였고 이유는 한번에 12시간 이상 라이딩할 일이 많았기 때문입니다. USB포트가 둘 달린 외장배터리는 장거리라이딩에 항상 전조등과 바이크컴퓨터를 항상 충전하고 있었습니다. 그러지 않고서는 장거리 라이딩을 도저히 버틸 수가 없었습니다. 가민 엣지는 스펙 상으로는 15시간 정도 동작한다고 적혀있지만 실제로 코스 내비게이션 기능 사용, 낮은 기온에 노출, 여러 센서에 연결하는 등 적극적으로 활용하기 시작하면 10시간도 채 안되는 시점에 배터리 부족 경고가 나타나곤 합니다. 자전거 핸들은 항상 USB케이블이 너덜너덜 감겨있었고 낙차라도 한번 했다가는 이 모든 장비가 한번에 바닥에 내팽개쳐질 수 있었습니다. 불만이 슬슬 커질 무렵 킥스타터에 나타난 트림원의 컨셉은 꽤 흥미로웠습니다.

스마트폰은 더 강력한 CPU와 거대한 배터리가 달려있습니다. 기압계와 나침반, GPS센서도 달려있고요. 이 장치는 장거리 라이딩에 필요한 모든 기능을 수행할 수 있지만 단 하나, 그 비싼 가격에 비해 부서지기 쉬웠습니다. 자전거 핸들은 생각보다 각박한 환경이었고 굳이 낙차하지 않더라도 강한 진동이 몇 백 킬로미터 동안 유지되면 멀쩡한 유리에도 금이 가기 일쑤였습니다. 그런데 바이크컴퓨터를 앞에 달고 스마트폰은 저지 뒷주머니나 파우치에 넣고 있어도 바이크컴퓨터가 스마트폰의 자원을 끌어다 사용한다는 아이디어는 훌륭해 보였습니다. GPS도 갖다 쓰고 고도계도 나침반도. 거기에 파워미터나 케이던스센서도 끌어다 쓴다면 자전거 앞에 달린 바이크컴퓨터는 거의 모니터 역할만 해도 괜찮습니다. 그렇게 배터리를 절약하면 저는 스마트폰 배터리만 신경쓰면 됐고 모니터를 켜지 않는 이상 스마트폰의 배터리는 생각보다 훨씬 강력했습니다. 그렇게 훨씬 오랜시간 배터리를 유지할 수 있다는 트림원의 컨셉은 매력적이었습니다. 최대 100시간 이상도 유지할 수 있다는 주장이 꽤 신빙성 있어 보였습니다. 그렇게 30만원 가까운 금액을 내고 백킹했습니다.

시간이 흘러 시즌온 할 즈음이 됐지만 '예상대로' 기기 배송은 딜레이됐습니다. 저는 여전히 익숙한 가민 엣지를 들고 시즌을 시작했고 여전히 달리는 내내 충전 케이블이 핸들에 감겨 있었고 비슷한 가격대의 가민 신제품3)이 나왔습니다. 그렇게 또 한 시즌이 지나가고 11월 초에는 자전거 출퇴근을 마무리하고 실내자전거4) 로 전환하면서 이번 시즌을 마무리했습니다. 그런데 시즌을 마무리하기 직전에 반 년 늦게 제품 제작이 완료되어 배송을 시작했고 실외 시즌을 접기 직전에 실제 물건을 손에 쥘 수 있었습니다.

현실

위에서 스마트폰의 자원을 끌어 쓰는 바이크컴퓨터를 설명했지만 사실은 좀 회의적인 생각도 있었습니다. 현대의 바이크컴퓨터는 생각보다 더 많은 역할을 하고 또 생각보다 더 많은 기술의 집합입니다. 가령 하드웨어를 만들 수 있다 하더라도 스마트폰을 끌어들인 이상 하드웨어의 펌웨어, 아이폰 소프트웨어, 안드로이드 소프트웨어, 웹 서비스 등 바이크컴퓨터 하나를 위해 신경써야 할 분야가 너무 많았습니다. 또 스트라바5)처럼 GPS센서에만 의존한 고도 오차를 보정하기 위해 자체 지리정보데이터베이스를 구축한 사례도 있었습니다. 간신히 하드웨어와 펌웨어 개발력을 가진 조그만 회사가 진입하기에는 그리 만만하지 않은 장치였습니다. 그래서 온전히 동작하지 않을 가능성이 더 높을 거라고 예상하고 기대치를 낮추던 중이었습니다. 일단 벽돌이 아닌 물건이 배달된 것 만으로도 한 75%정도는 성공이라고 생각했습니다. 며칠 안 남은 자전거 출근길에 트림원 바이크컴퓨터를 거치하고 출발했습니다. 물론 이 기계를 조금도 신뢰할 수 없었으므로 가민 엣지 역시 주머니에 넣어뒀습니다. 리모트의 스타트 버튼을 누르자 주머니에 있던 가민 엣지도 기록을 시작했습니다.

짧은 남은 시즌 기간 동안 트림원을 달고는 1000킬로미터도 채 달리지 않았습니다. 하지만 지금까지의 결론은 기 기계를 단독 사용해 내년 브레베 시즌을 시작하지는 않으리라는 것입니다. 이유는 한 가지로 요약됩니다. 동작을 예상할 수가 없었습니다. 일단 이 기계는 위에서 이야기한 '센서 몇 가지가 달린 스마트폰 모니터'라는 컨셉에서 벗어나지 않았습니다. 하지만 마치 자신이 아이폰이기나 한 것처럼 지금 어떤 동작을 하고 있는지 이해할 수가 없습니다.

가령 제조사는 스마트폰과 연동해 장시간 배터리가 유지될 거라고 주장했지만 브롬톤으로 고작 100킬로미터를 달린 날 집에 돌아와보니 가민 엣지는 65%, 트림원은 38%의 배터리 용량이 남아있다고 표시됐습니다. 이 추세라면 가민은 가장 짧은 브레베를 감당해낼 수 있겠지만 트림원은 그럴 수 없었습니다. 문제는 배터리가 아니라 왜 이런 결과가 나왔는지 제가 알 수 없다는 점에 있습니다. 가령 스마트폰과 어떤 이유로는 연결이 끊겨 트림원 기계에 달린 센서들을 직접 사용한 결과일 수 있습니다. 그렇다면 스마트폰과 연결은 어떻게, 왜, 언제부터 끊어졌는지 알 수 있어야 합니다. 그래야 예상하고 대응할 수 있으니까요. 하지만 이 기계는 아무런 피드백도 주지 않았습니다. 그냥 조용히 모드를 전환한 모양이고 그냥 조용히 배터리를 낭비하고 있었습니다. 제가 눈치채기 전까지 제게 아무런 신호도 보내지 않았습니다. 사실은 그래도 괜찮았습니다. 트림원에 문제가 생기면 그냥 주머니에서 가민을 꺼내 바꿔 달면 그만이었으니까요. 하지만 30만원이나 낸 기계의 동작을 신뢰할 수 없어 가민을 항상 백업으로 들고다니는 시나리오를 상상하지는 않았습니다.

알루미늄으로 된 껍데기는 깔끔하고 예쁩니다만 이걸 들고 연말 페스티브5006) 라이딩을 할 수 있을지 의심스럽습니다. 이 깔끔은 표면은 영하 10도 미만의 기온을 기기 안쪽으로 원활하게 전달해 배터리 안의 화학반응을 가민 엣지보다도 효과적으로 멈출 거라고 예상합니다. 또 가민 마운트와 호환되지만 평평한 뒷면 덕분에 기기를 정확하게 조준해서 거치하기 어렵습니다. 아이폰 기준으로 소프트웨어는 동작하기는 하지만 특유의 투박하고 아이폰 사용자들의 감을 따라오지 못하는 인터페이스를 자랑하며 가민 특유의 '막무가내 업데이트'도 여전합니다. 난 지금 스타트 누르고 출발해야 하는데 막무가내로 펌웨어 업데이트 하는 건 분명 가민으로부터 배워왔을 겁니다. 스마트폰 없이는 센서 하나 추가할 수 없고 인도어 사이클링에 사용할 수도 없고 또 스마트폰 없이는 밝기를 조절할 수 조차 없습니다. 모니터 컨셉은 훌륭하지만 이렇게까지 컨셉을 유지할 필요가 있었나 싶을 정도입니다.

결론

이 기계는 여전히 가능성이 있고 여전히 괜찮은 컨셉입니다만 이 기계에 30만원과 1년을 투자해서 얻은 결론은 우리들이 가민 엣지 바이크컴퓨터를 사용하며 가민을 욕하는 것과 달리 이 비즈니스는 생각보다 복잡한 기술적 디테일을 요구한다는 점이었습니다. 이 디테일을 달성하려면 시간이나 돈이나 인력 중 적어도 둘 이상은 갖춰야 하고요. 하지만 트림원의 제조사가 이들 중 적어도 하나를 갖추고 있을지 의문입니다. 쿨하게 스마트폰 앱을 단독으로 사용할 때 고도정보를 기록하지 않는다는 말로부터는 자체 지리정보를 운용하는 스트라바가, 고작 100킬로미터 주행에 70% 넘는 배터리를 소모해버리는 점으로부터는 이제 전용 외장배터리를 지원하는 가민 엣지가, 폰과 연결이 끊기자 그대로 사라져버린 코스 내비게이션은 스마트폰의 음성안내 기능이 떠올랐습니다. 제대로 동작하는 파워미터가 드물다는 점 같은 건 이야기하지도 않았습니다. 라이딩에 크리티컬하지도 않은 것 같아서요. 그리도 다시 한 번 이 비즈니스가 가민 엣지가 구린 것 만큼 그리 간단하지 않다는 점을 느꼈습니다. 다시 한 번, 이 기계는 여전히 가능성이 있고 여전히 괜찮은 컨셉입니다. 하지만 그건 소프트웨어가 훨씬 더 정교해졌을 때 이야기입니다. 그 전에는 이 기계는 추천할 수 없습니다. 또 한편으로는 이 기계에 정교한 소프트웨어가 들어갈 때까지 개발자들이 버틸 수 있을지도 걱정스럽습니다.

추가.

저녁에 즈위프트 타면서 켜놔봤는데 1시간 내내 케이던스와 심박을 제대로 표시했지만 (파워미터 화면은 내가 안 만들어놔서 못 봄) 나중에 로그를 뽑아보니 처음 6분 23초어치만 남아있었습니다. 오동작은 둘째 치고 그냥 동작 자체를 이해할 수가 없어요. 킥스타터를 통한 제품이 아니었다면 좀더 많이 열받아 내 돈을 돌려받기 위해 강력하게 노력했을 것 같습니다. 다시 한번 이야기하지만 제대로 된 소프트웨어 지원이 있기 전에는 절대로 구입하지 마세요. (다행히도 딱히 구입할 방법은 없는 것 같지만.)

<< 새 항목 | 오래된 항목 >>

blog/start.txt · 마지막으로 수정됨: 2019-11-24 10:54 저자 neoocean