일본 샤프와 세계 최초의 리눅스 PDA 앱 개발
한컴리눅스
회사 내 소문이 돌았다. 일본 SHARP사와 계약이 진행 중이라는 것이다. 일본 SHARP라면 세계적인 전자기기 회사로써 우리에게는 샤프펜으로도 유명하다. 가끔 소문만 돌다가 흐지부지 된 적이 여러 번 있어서 이번에도 해프닝이 아닐까 생각했으나 얼마 후 정식으로 계약을 했다는 공식 발표가 나왔다. 샤프는 일본 회사이기 때문에 일본 비즈니스를 담당하고 있던 나에게는 대단히 큰 뉴스가 아닐 수 없다. 프로젝트의 내용을 간단히 정리해 보자면 다음과 같다. 샤프에서 세계 최초로 리눅스 기반 PDA를 생산한다. 당시 시장을 리드하고 있는 경쟁 제품으로는 Palm사의 Palm 시리즈와 MS OS 기반의 HP iPaq. 손안에 쏙 들어오는 사이즈의 기기에 여러 가지 앱이 설치되어 있고 iPaq의 경우는 통화까지도 가능했다. 말 그대로 스마트폰의 시대가 이때부터 시작이 된 것이다. 이제 경쟁이 시작된 PDA 시장에 도전장을 내민 것이 샤프이고, 놀라운 것은 리스크가 커서 아무도 시도하지 않았던 리눅스 OS 기반으로 제작을 하기로 한 것이다. 제품명은 'Zaurus', 모델명은 'SL-5500'.
Sharp Zaurus SL-5500 PDA대단히 큰 규모의 계약이 성사되었고 전사적으로 이 프로젝트에 올인을 하게 되었다. 샤프로부터 PDA 샘플 3대가 도착했다. 실버 색상에 지금의 스마트폰 사이즈이며 아래 부분을 내리면 키보드가 펼쳐진다. 역시 세계적인 하드웨어 기술 회사의 제품에는 뭔가 새로움과 신비로움이 반짝거린다. 개발 1팀에서 앱 개발을 담당하기로 해서 두대가 배당되었고 나머지 한대는 PM 역할을 맡은 나에게 돌아왔다. 개발의 요점은 간단하다. 리눅스 기반에서 사무용 소프트웨어의 필수 앱인 오피스 프로그램 구현이다. 워드, 엑셀, 파워포인트 작성은 물론이고 MS OFFICE에서 작성된 문서의 읽기 및 편집이 가능해야 한다. 가장 큰 문제는 PDA의 총 저장공간이 16MB이기에 앱 사이즈가 1MB를 넘지 않아야 한다는 것이다. 지금이야 대부분 수백 GB 용량의 스마트폰이라 크게 구애를 받지 않지만 당시만 해도 앱 사이즈를 줄이기 위해서 기대하는 기능 구현 외에도 소스 코드를 최대한 간소화해야 하는 이중 부담이 있었다. 참고로 위 이미지 3번째 줄에 있는 3개의 앱이 최종 결과물이다.
일본 샤프에서 '기무라'상이 출장을 왔다. 이 프로젝트가 완료되기 전에는 못 돌아간다는 것이다. 비장한 각오로 가족과 떨어져 몇 개월간 말도 안 통하는 타국에서 샤프를 대표해 최선의 결과물을 끌어내는 것이 이번 출장의 목표다. 회사 내 유일하게 대화가 통하는 사람이 나다 보니 내 옆에 자리를 마련하였고 어쩔 수 없이 그와 스케줄을 맞추게 되었다. 지금까지는 주로 이메일을 통해 커뮤니케이션을 해 왔지만 담당자가 직접 개발 현장에 함께 하다 보니 업무 강도가 기존보다 훨씬 높아졌다. 매일 밤 10시 넘게까지 작업을 하였고 주말이나 공휴일도 사실상 의미가 없었다. 기무라상도 회사를 대표해 무거운 책임을 안고 한국에 온 만큼 잠자는 시간을 제외하고는 무서우리 만치 열심히 개발을 도왔다. 한국 사람으로서는 전혀 생각지도 못할 만큼의 집요한 테스트와 리포트 수준은 모두를 경악하게 만들었고 동시에 모두를 지치게 하곤 하였으나 그만큼 제품의 퀄리티는 완벽에 가까울 정도로 좋아지고 있었다. 개인적으로도 수개월간 얼마나 시달렸는지 말로 표현하기 힘들지만 이때의 경험과 눈높이가 몸속에 녹아들어 향후 업무 또는 사업에 지대한 영향을 준 것만은 부정할 수 없다.
다음은 샤프의 앱 테스트 과정이다. 깐깐하기로 유명한 일본 대표기업 샤프에서는 어떤 식으로 앱을 테스트하는지 간략히 기술해 보겠다. 앱 관련 스타트업 기업에 조금이라도 도움이 되었으면 한다.
1. 사양 설명서 작성
기대하는 사양을 가급적 명확히 정리해야 한다. 명확하게 정리가 안되면 개발팀과 PM팀 간 혼선이 생기며 몇 배로 작업 시간이 늘어난다. 일종의 기준이 되는 셈인데 부족하지도 과하지도 않은 합리적인 기준을 만들기 위해서는 무엇을 어떻게 만들까에 대한 많은 연구가 사전에 있어야 한다. 눈높이를 개발자에 맞추어서도 안되고 컴맹에 맞추어서도 안된다. 적당한 수준의 유저층을 찾아서 그들이 편하고 유용하게 사용할 수 있도록 하는 것이 목표다.
2. PM 1차 테스트
개발팀은 사양 설명서를 바탕으로 내부 회의를 거쳐 개발 스케줄을 잡는다. 정해진 기한까지 최선을 다해서 만든 결과물이 넘어오면 PM팀에서는 사양 설명서를 바탕으로 1차 테스트를 한다. 짧은 시간 내에 주로 큰 문제 위주로 검토를 한다. 작은 문제는 다음 프로세스에서 다루면 되며 큰 문제가 발견되면 개발팀에 수정 요청을 한다.
3. 버그 테스트 그룹 리포트
이 부분이 하이라이트이다. 개발 중인 앱을 한두 명이 아닌 수십 명이 테스트를 한다. 개발자도 아니며 직원도 아니다. 아르바이트로 고용된 완전 일반인이다. 일반 유저의 시각에서 앱을 사용해 보고, 무엇이 문제인지 무엇이 불편한지 아주 자세히 리포트를 받는다. 테스트 요원이 많으면 많을수록 좋다. 샤프의 경우 15명으로 구성이 되었다.
4. PM 리포트 확인 및 개발팀과 리뷰
이렇게 취합된 리포트를 PM은 분류 정리하여 직접 테스트를 해본다. 문제점 확인 후 관련성 있는 이슈들을 하나로 묶어서 보다 효율적으로 개선이 될 수 있도록 다시 한번 정리를 한다. 이렇게 정리된 최종 리포트를 바탕으로 개발팀과 회의를 하여 정해진 스케줄 내에 개선이 되도록 협조 요청한다.
5. 2번~4번 계속 반복
이 과정을 수 없이 반복해야 한다. 당연히 모두를 지치게 한다. 하지만 이런 과정 없이는 쓸만한 앱은 탄생하지 않는다. 일단 출시되면 사용자의 평가가 쏟아지는데, 그들을 버그 테스터라고 생각해서는 절대 안 된다. 다시 한번 강조하지만 한국은 아직도 이 부분의 중요성에 대해서 대충 넘어가려 한다. 한국뿐만 아니라 세계로 진출을 하고자 한다면 더더욱 이런 과정에 혼신의 힘을 쏟아야 한다.
약 3개월간의 노력 끝에 작품을 완성했다. 그동안 집보다 근처 찜질방에서 쪽잠을 잔 날이 더 많았다. 기무라상 본인이 그토록 악으로 깡으로 최선을 다하니 파트너였던 내가 어찌 편안히 쉴 수 있었겠는가. 주말은 고사하고 명절에도 일을 했으며 심지어 내가 주선하여 커플이 된 친구의 결혼식에도 못 갔다. 지금 생각하면 너무 억울하고 화가 난다. 하지만 모두 함께 이토록 고생하여 만든 앱을 탑재한 PDA가 전 세계로 판매가 될 것을 생각하면 참으로 뿌듯했다. 나중에 일본 아키하바라를 갔을 때 자우루스가 판매되고 있는 걸 보고 감명을 받은 기억이 지금도 생생하다. 모든 프로젝트가 종료되고 샤프에서 초대를 했다. 일본 교토 바로 옆 '나라'에 위치한 샤프 본사에 방문하는 행운을 얻은 것이다. 대표와 나, 그리고 일본법인장 3명이 방문을 하였는데, 최고 책임 부장이 따뜻하게 반겨주며 나에게 한마다 건넸다. "당신이 소문의 추상인가요?"
