13. 하드웨어를 맡게된 PO - 자체 태블릿 제작기 ② (진행 업무)

지난 1편에선 자체 제작 태블릿을 만들게 된 제작 배경과 내가 맡았던 일에 대해 간략히 서술했다.

아래 3가지가 내가 맡았던 일이라고 요약했었는데, 

1. 맞춤형 태블릿 펌웨어(태블릿 os) 제작
2. 관련 운영 이슈 해결&안정화
3. history 문서 제작 및 인수인계 

 

이번 글에서는 이 일들에 대해 좀 더 자세하게 적어보고자 한다.  

 

1. 맞춤형 태블릿 펌웨어(태블릿 os) 제작

1) 펌웨어 가능사항 파악&정리

태블릿 제작에 있어 내가 맡았던 역할은 태블릿에 들어갈 펌웨어(태블릿 os, 운영체제 같은 것)를 기획하고 업체에 이에 대한 개발 요청을 하는 것이었다. 

 

이를 위한 첫 단추는 다음과 같았다.

1) 펌웨어로 제작 가능한 범위를 파악하고
2) 이를 바탕으로 펌웨어 요구사항 정의서 를 작성하는 것
(쉽게 말해, 개발 요청할 것을 정리한 요청서이다. 태블릿 업체는 해당 문서를 바탕으로 해서 개발 사항을 확정하고 개발을 진행한다.)

 

나는 실제로 펌웨어라는 용어 자체를 처음 들어봤을 정도로, 펌웨어라는 것 자체가 나에겐 매우 낯선 존재였다. 따라서 가장 첫 단계인 대체 어디까지가 펌웨어로 가능한 범위인지 파악하는 게 정말 어려웠다. 

 

그래서 나는 이 상황 속에서 내가 할 수 있는 최선을 다해 보기로 했다.

우선 해당 태블릿 업체가 타 테이블 오더 사에도 납품을 해본 경험이 있었기에,

태블릿 업체로부터, 테이블 오더 사들이 공통적으로 많이 적용하는 펌웨어들을 전달 받았다.
(이를 통해, 어떤 범위까지 펌웨어 개발이 가능한지 대략적으로 파악할 수 있었다.)

 

이렇게 전달받은 내용을 바탕으로 우리 회사가 취할 만한 펌웨어 사항들에 대해 1차 정리를 진행했다. 

 

 

그 뒤엔,

기존에 회사에서 일반 태블릿을 이용하며 발생했던 운영 이슈들을 취합했다.

 

태블릿 업체와 다방면으로 소통을 해가며 해당 태블릿 이슈들이, 펌웨어나 하드웨어 스펙적으로 해결을 할 수 있는 사항인지 파악했다. 또 이 이슈를 펌웨어를 통해 해결할 수 있다면, 어떤 방식들이 가능할지에 대한 여러 가능 안 들을 탐색하는 과정을 거쳤다. 이 과정을 통해 펌웨어 개발을 요청할 사항에 대해 2차 정리를 진행할 수 있었다. 

 

2) 펌웨어 요구사항 정의서 작성&전달

이렇게 펌웨어 개발을 요청할 사항이 내부적으로 어느 정도 정리된 후엔, 이를 문서 형태로 잘 정리해서 업체에 전달해야 했다. 따로 형식이 정해져 있지 않은 상황이었고, 나는 문서 작성 시 간결성도 중요하지만 결국 가장 중요한 건 "맥락"이라고 생각했다. 

태블릿 업체와 우린 다른 회사다. 소통에 시간/공간적 제약도 많고, 우리 회사 서비스에 대한 이해도도 낮을 수밖에 없다. 따라서, 어느 문서 보다 최대한 "맥락"을 잘 전달한 문서를 만들어야 해당 업체가 이해하기가 편할 것이라 생각했다. 

 

나는 다음과 같이 문서 양식을 만들었는데,

문서 양식 예시

[요청사항] 영역에는 "뭘 해주세요"를 최대한 간결히 적어, 요청할 사항을 한눈에 볼 수 있게 하려 했다. 

 

[비고] 영역에는 최대한 맥락을 상세히 포함하려 했는데

1. 해당 요청사항이 나오게 된 배경이 무엇인지 
2. 해당 요청사항을 통해서 해결하려는 문제가 무엇인지를 최대한 자세히 적으려 했다. 
(ex. 실제 매장에서 테이블 오더 이용과정에서 하드웨어 이슈로 ~~ 한 상황이 있었고, 우린 펌웨어로 이 문제를 해결하고 싶다.)

 

결국에 나는 전문 펌웨어 기획자/개발자는 아니기에, 태블릿 업체에 비해서 펌웨어 자체에 대한 지식/이해도는 떨어질 수밖에 없다. 따라서 구체적인 설루션(ex. ~~~를 해주세요)을 제시하기보단, "우리는 현재 이러이러한 상황에 처해있어서 뭐든 이 문제를 해결할 방법이 필요해"라는 걸 업체에 전달해 주는 게 오히려 더 적합한 설루션이 나올 수 있을 거라 생각했다. 결국 어떤 문제의 해결이 필요한지만 잘 전달한다면, 비 전문가인 우리가 생각한 것보다 더 좋은 설루션을 그쪽에서 떠올려 줄 수 있다고 생각했기 때문이다.

 

3) 추가 소통을 통한 개발사항 확정

이렇게 문서를 전달했다고 업체 측에서 바로 개발에 들어갈 순 없었다.

업체 측에선 "그래서 이러이러한 기능들 원하는 것 맞지?"라고 추가 확인을 여러 번 요청했다. 이렇게 소통하는 과정에서 내가 전달한 요청사항 중 빠져 있는 것들도 꽤 있다는 걸 발견하게 된다. 

 

처음엔 "왜 이걸 빠트린 거야?"라고 생각했지만, 업체와 소통하는 과정에서 그것들 중 대부분은 업체가 누락한 것이 아니니라는 것을 알게 됐다.

1) 같은 기능인데 워딩만 내가 사용한 것과 차이가 있거나
2) 기본적으로 제공되는 기능이라 업체 측에선 문서에 따로 적지 않았던 것이다.

 

이런 상황을 겪으며 외부업체와의 협업에 있어 중요한 요소에 대해 배울 수 있었던 것 같다. 서로 간의 소통방식/업무방식에 익숙해지는 과정이 정말 중요하다는 것이다. 실제로 1차 펌웨어 제작 시기엔 시행착오가 꽤 많았지만, 서로의 방식에 대한 인지가 어느 정도 된 후였던 2차 펌웨어 제작 시기에는 문서 검토 및 소통이 매우 효율적으로 진행됐다. 이를 직접 몸으로 겪어보며, 업체와의 협업에서 유의할 요소에 대해 좀 더 확실히 느낄 수 있던 것 같다. 

 

4) 펌웨어 테스트

가장 힘들었던 테스트 과정..

 

이렇게 추가적인 소통까지 마친 후, 펌웨어 개발 사항을 확정할 수 있었다. 개발 사항 확정 후 일정시간이 지난 후, 태블릿 업체 측에선 개발한 펌웨어에 대한 테스트 파일과 목업 태블릿을 보내왔다. 우리가 요청한 하드웨어 디자인/스펙과, 펌웨어 파일이 정상적으로 동작하는지를 테스트하는 과정이었다. 

 

요청한 펌웨어 사항들이 빠집 없이 잘 들어가 있는지를 파악하면서도, 그 외 별도의 이슈가 발생하진 않는지를 확인했어야 했다.(예를 들면 갑자기 태블릿 전원이 꺼진다던가, 테이블 오더 앱 이용 중 앱이 튕긴 다던가)

지금 와서 돌이켜 보면 이 작업이 가장 까다롭고 힘들었던 것 같은데, 그랬던 이유를 몇 가지 적어보면 다음과 같다.

 

테스트 전용 tool을 익혀야 함

일반 앱을 테스트하는 것처럼 앱만 다운로드하면 되는 게 아니었다. 테스트용 펌웨어파일을 다운로드하기 위해선 복잡한 전용 tool을 이용해야 했는데, 이 tool의 사용방법을 익히는 과정이 꽤 어려웠다. 업체 측에선 해당 tool 이용방법이 담긴 설명서 파일을 전달해 줬지만, 설명서 대로 동작하지 않는 부분들도 많았다. 그래서 하나하나 몸으로 부딪히고, 해당 업체 직원분께 통화를 계속하며 tool의 이용방법을 익히고 겨우 테스트를 했던 게 생각이 난다. 

 

앱 기능과 엮여있는 펌웨어는 더 복잡했다

간단한 펌웨어 사항은 해당 업체 측에서 개발도 쉽고, 잘 반영됐는지 확인만 하면 되기에 테스트도 쉬웠다.

(ex.  태블릿 밝기를 00%가 기본값, 태블릿 특정 설정에 대해 [off 상태]를 기본값 등)

 

반면에, 테이블 오더 앱의 기능과 엮여있는 펌웨어의 경우 펌웨어 개발 및 테스트가 정말 어려웠었다. 해당 펌웨어를 구현하기 위해선 우리 쪽에서도 테이블 오더 앱에 코드를 삽입해야 하고, 해당 업체 측에서도 별도의 코드 작업이 필요했다.

태블릿 업체의 작업만으로 끝나는 간단한 펌웨어와는 달리, 양쪽 회사의 작업이 필요한 것이다. 물론 같은 회사였다면 빨리 끝날 사항이라고 생각한다. 하지만 서로 쓰는 프로그래밍 언어도 다르고, 태블릿 업체의 경우 우리 서비스에 대한 이해도가 낮은 상황이었다. 코드 스크린샷도 여러 번 보내고 통화/문자도 정말 여러 번 해가며 한 단계 한 단계 개발하고 테스트했던 게 기억이 난다. (최소 며칠~몇 주간 여기에 묶여 있었던 듯..)

 

또, 상황 상 해당 태블릿 업체 직원 중 내가 소통할 수 있는 사람은 해당 업체의 영업팀이 유일했다. 따라서 개발적인 소통이 많이 필요했던 앱 기능 관련 펌웨어는 소통에 있어서 더 어려울 수밖에 없었다. (태블릿 업체 개발자와 소통을 위해선 몇 다리를 거쳐서야 소통이 가능했기 때문)

 

테스트 횟수가 정말 많았다

테스트를 해야 하는 횟수 자체도 정말 많았는데, 테스트 파일을 1~2번이 아니라 거의 10번은 받아 테스트했다. 특정 파일을 점검하고 난 후 최종파일을 확인하면, 포함되어 있던 게 다시 빠져있기도 하고 이전엔 발견이 안 됐었던 별도의 이슈가 발생하기도 하고...(거의 찐찐최종 마지막 급 파일을 정말 여러 번 확인했던 게 기억난다. 태블릿 업체 담당자 분도 중간에서 엄청 고생하셨지 않았을까 싶다)

 

부담감과 책임감

태블릿 제작 프로젝트를 주도해서 담당하는 것 자체가 나에겐 꽤나 부담감과 책임감을 요했다.

당시, 재고 상황상 자체 제작한 태블릿이 이때까진 입고되어야 한다는 시기가 정해져 있었다. 입고 시기가 정해져 있다는 건, 펌웨어가 정상적으로 테스트 완료되어야 하는 시점도 정해져 있다는 의미였다.

(펌웨어 개발이 완료되어야 해당 펌웨어를 탑재되어 태블릿이 제작하고 출고할 수 있기 때문)

 

따라서 펌웨어 테스트 시기엔, 업체 측에서 새로운 버전이 완성되었으니 테스트해보라고 연락이 오면 다른 업무를 제쳐두고 테스트 업무를 진행할 수밖에 없었다. 게다가 업체 측에서 새로운 파일을 언제 보내줄지 확신할 수 있는 상황이 아니었다. 비정기적으로 계속 업무시간을 조금씩 뺏길 수밖에 없었다. 이렇게 고생해서 테스트를 했는데, 또 무언가 빠져있는 게 나오면 이에 대해 수정해 달라고 업체 측과의 소통을 또 진행해야 하는 것도 꽤나 큰 부담이었던 것 같다. 

 

당시 상황상 회사 내 다른 직원분들이 test를 도와줄 수 있는 상황이 안 됐었고, 자연히 test를 거의 나 혼자 해나갈 수밖에 없었다. 또 해당 시기에 test와 관련해서 계속 내가 업체와 소통을 하다 보니, 나중엔 업체 측에서 펌웨어 test 외에 다른 소통까지 나를 통해 하게 되었고, 점점 이 프로젝트에서의 role이 넓어졌던 게 생각이 난다. 

 

엎친데 덮친 격으로 당시 나는 회사 차원에서 정말 중요하고, 꽤나 복잡한 신기능의 출시 또한 전담하고 있었다. (회사 내에서도 아무도 해본 적 없는 유형의 기능이랄까) 이렇게 개인적으로도 업무가 꽤나 몰렸던 시기여서 더 쉽지 않았던 것 같다.

 

그래도 이 상황에서 생각했던 건 책임감이었다. 내가 여기서 대충 test를 하고 넘어가버리면, 이걸로 인해 문제가 발생하고 그에 따른 운영적 비용이 많이 생길 수 있다. 이는 결국 매장 사장님들의 불편과 다른 직원분들의 고생으로 이어질 수밖에 없다는 생각에 내가 할 수 있는 한 최대한 꼼꼼히 보려고 노력했던 게 기억이 난다. 

 

2.  관련 운영 이슈 해결&안정화

1) 설치 업체 Guide 문서 제작

이렇게 여러 번의 test 끝에 펌웨어가 확정되고 태블릿에 제작되었다. 하지만 태블릿이 제작되었다고 끝은 아니었다. 제작된 태블릿을 효율적으로 매장에 공급하는 과정이 필요했다.

 

새롭게 제작된 태블릿은 이전 일반 태블릿과는 하드웨어적, 소프트웨어적으로 다른 지점들이 꽤 있었다. 만약 이런 변경지점과 특수성에 대한 제대로 된 안내가 없이 나간다면, 테이블 오더 설치 담당자와 매장 사장님들에게 큰 혼란이 있을 수밖에 없었다. 

 

따라서 테이블 오더 설치 담당자분들을 위한 설치 시 유의사항을 담은 Guide 문서를 만들었었다.

제작된 태블릿의 특수성과, 매장 사장님들께 설치 시 알려주어야 할 사항들을 담은 문서였는데 초반엔 시행착오가 있긴 했지만 그래도 안정적인 태블릿 설치에 조금이나마 일조했다고 생각한다.

2) 내부 운영/CX Guide

외부 설치 업체 외에도, 보다 효율적인 고객응대를 위해 내부 운영/CX 담당자분들을 위한 Guide도 필요했다. 테이블 오더를 3~4개월 운영하면서 중요하다고 느낀 지점이, 운영이슈 발생 시 이에 대한 history 및 응대 방법들을 그때그때 아카이빙 해놓고 매뉴얼화를 시키는 것이었었다.

 

그래서 이 자체태블릿의 경우엔 초반부터 운영팀 분들과 함께 신규 CX 문의가 인입되면 최대한 이에 대한 history를 그때그때 뉴얼에 기록해놓으려고 했던 것 같다. 초반엔 번거로운 작업일 수 있어도, 결국에 CX 문의는 비슷한 문의가 반복적으로 들어오는 경우가 많기 때문에 이에 대해 내부 Guide 및 매뉴얼을 만들어서 동일 문의 인입 시 빠르게 응대할 수 있도록 노력했다. 

3) 업체 측에 이슈 파악 요청 

공들여서 만든 태블릿이지만, 항상 그렇듯 실제 필드에선 우리가 예상치 못한 이슈들이 어느 정도는 발생할 수밖에 없다. 이런 이슈들엔 내부에서 해결할 수 있는 것들도 있었지만, 태블릿 업체의 원인 파악 지원이 필요한 결함들도 적지만 있었다.

 

이때는 적절한 이슈레이징을 통해 해당 업체를 움직이는 능력이 필요했다.

 

결국 업체 측에서도 추가적으로 원인 파악을 하거나, 수정 작업을 하는 것은 본인들 리소스를 쓰는 것이기에 수동적일 수밖에 없는데, 이런 상황에서 업체를 움직일 수 있는 것은 결국 증거와 정량적인 수치를 제시하는 것이라는 걸 배우게 됐다. 

 

다음은 특정 이슈 발생 시 내가 업체 측에 제시했던 이슈레이징 예시이다.

 

a. 정량적 수치 제시

우리 매장 중 해당 태블릿을 쓰는 매장이 몇십 개가 있다. 그중 몇 곳에서 특정 문제가 동시에 발생했다. 앱 로그인 해당 문제가 찍히지 않았다. 또, 전체가 발생한 이슈라면 우리 앱의 버그일 수 있겠지만, 일부만 발생한 것으로 보아 태블릿 하드웨어 혹은 세팅 문제인 것 같다. 

 

b. 실제 고객 Vocie 전달

매장들로부터 인입된 고객센터 항의 보이스 캡처본은 이렇다. 꽤나 큰 불편을 사장님들이 겪고 있다.

 

c. 문제 재현

우리가 ip카메라를 구입한 후 동일한 환경을 재현해 봤다. 실제 해당 이슈가 발생한다는 게 녹화되었다. 이게 녹화본이다.

 

=> 결국 이런 다양한 증거/ 정량적 수치를 제시하니 업체도 움직일 수밖에 없었다. 이때 업체와의 소통에 있어 한 단계 더 배웠던 것 같다.

 

3. history 문서 제작 및 인수인계

마지막으로 회사를 나오기 전에 했던 업무 중 태블릿 관련 history를 문서화하고, 이를 다른 직원분들께 교육해 드리는 기회가 있었다. 이때 가장 크게 느낀 것은 "내가 알고 있는 것들을 남들에게 잘 전달하는 것의 중요성"이었다.

 

당시 제작 했던 history 문서 중 일부(보안상 blur 처리)

 

 

특정 업무/지식에 대해 본인이 전문성을 가지는 것은 물론 좋은 것이다. 또 해당 업무의 담당자가 생기는 것이므로 업무 효율성 측면에선 좋아 보일 수도 있다. 하지만 해당 정보를 회사 내에 특정 사람만 알게 되면, 관련된 정보가 필요하거나 문제가 터졌을 시 해당 사람이 없으면 해결할 수가 없어진다. 특히 해당 인원이 휴가를 가거나 퇴사를 하거나 하면 문제가 더 커질 것이다.

 

실제로 테이블 오더/자체 태블릿 운영을 하면서 이 부분을 정말 많이 느꼈었다. 내 머릿속의 지식을 잘 문서화하는 것, 그리고 단순히 문서화를 떠나서 이것들을 다른 사람들에게 잘 전달하고 알려주는 것의 중요성을 느끼게 되었다. 

 

이게 회사 전체적으로 봤을 땐 좀 더 더 큰 시너지가 날 수 있는 길이라는 것을 느꼈으며, 왜 사람들이 문서화/공유/인수인계의 중요성을 말하는지 직간접적으로 느꼈던 순간인 것 같다.

---

 

이번 글에선 내가 태블릿 제작과 관련해 진행한 업무들에 대해서 좀 더 자세히 적어보았다. 

다음 글에선 [자체 태블릿 제작기] 글의 마지막 내용으로, 업무를 진행하는 과정에서 배우고 느낀 점들에 대해 조금 더 적고 마무리하려고 한다.

 

 

Profile:

Linkedin