[태그:] 유지보수

부제 : [개발자없는 개발팀의 개발블로그] 비용 안 들이고 시스템 구축하기

 

• 시작하는 말

IT 스타트업 생태계 언저리에 몇 년 기웃거렸지만, 나는 코드 한 줄도 못 쓰는 사람이다. 정보처리기술이 없다는 것에 대해 항상 부족함을 느꼈다. 엑셀을 중급 수준으로 할 수 있었고, 워드프레스로 웹사이트를 몇 개 만들어본 게 전부인 상태였다. 구글은 지난달 GDSS(Google Docs Spread Sheet)를 통해 앱을 만들 수도 있다고 발표했다. 클라우드-엑셀을 넘어서, 누구나 응용하면 정보처리엔진으로 활용할 수 있도록 사용방안을 소개하고 있다.

나에겐 두번째 사업인 비드폴리오를 운영하면서, 아웃풋에 대한 기대치를 낮추는 대신 인풋을 몇 배나 더 줄이는 것을 우선적인 목표로 잡았다. 초경량 린스타트업의 태도를 지향한 것은 나의 일습관이나 비용절감에 대한 집착도 영향을 미쳤겠지만, 시장규모가 나오지 않는 환경이 더욱 근본적인 이유다. 버티컬 중개 플랫폼의 경우, 적은 자원으로 사업체를 궤도에 올려야 하는데, 적은 자원으로 시스템을 구축하기가 어디 쉬운 일인가.

아무런 시스템이 없던 2개월차, 밤낮없이 일을 해도 동시관리 프로젝트 5건 넘기기 힘들었다. 지금은 매니저 1인당 동시응대 가능수량이 40건까지 올라갔으니 생산성이 최소 8배 이상 증가했다고 가늠할 수 있겠다. 임시방편으로 사용하기 시작했던 GDSS는 저렴한 비용과 관리효율성 측면에서 아주 만족스럽다.

물론 더 고도화된 시스템이 있다면 좋겠지만, 그것은 요리를 못하는 사장님이 식당을 운영하려는 것과 다르지 않다. 개발자가 1명이라도 있으면 적자가 날 정도로 매출규모가 적은 상황인데, 그 인원의 공백이 생겼을 때 무거운 시스템을 내가 다룰 수 없다면 사업이 위태해지기 때문이다. 어설프지만 사업운영에 필요한 핵심자원을 내재화했다는 데에서 안심이 된다.

근본없는 시스템을 공개하는 건 부끄러운 일이다. 그럼에도 이 글을 정리하는 이유는 우선 나를 위해서다. 얼마 전부터 생산성 증대의 정체기가 왔는데, 개선의 여지를 파악하고 싶다. 또 혹여나 GDSS를 유사한 방식으로 응용해 정보처리시스템을 구축한 사람이 있다면 연결되어 노하우를 공유할 수 있을지 기대해본다.

 

• 구글닥스로 고객응대 처리시스템 구축하기

비드폴리오 최초의 웹사이트를 만드는 데에는 1주일이 채 걸리지 않았고, 광고를 게시하자마자 30분만에 고객의 전화가 걸려왔다.

고객이 전화를 한 이유는 나에게 연락할 방법이 그것밖에 없었기 때문이다. 고객의 정보를 더 수월하게, 더 많이 받을 수 있도록 form을 만들어 삽입했다. form 서비스 중에서 손에 가장 손에 익었던 Google form을 4개월 정도 사용했다. 더 나은 서비스를 찾다가 form서비스의 시조새 격인 wufoo를 구입했다. 하지만 서베이몽키로 인수된 이후 몇 년째 나아진 것이 하나도 없었고 실망이 너무 커서 환불 받았다. 워드프레스 플러그인으로 연동되는 form 중에서 Caldera Form을 선택해 적용했다. Caldera Form은 TOP5에도 못 드는 비주류 폼이지만 내가 필요한 기능들을 가장 다양하게 구현할 수 있었다.

고객이 자신의 정보를 제출하는 방법은 총 7가지다. 전화, 이메일, 채널톡, Form 4가지다. (채널톡은 섬세한 설정 없이 채팅창만 열어두는 것은 오히려 비정형 대화로 유도하는 격이기에 지금은 사용하지 않고 있다.) 다양한 채널로 들어온 고객의 DB를 모두 개별적으로 관리하기는 힘들었다. 일부는 고객이 직접 제출한 정보인 RawData가 있었지만, 전화나 이메일로 받은 고객은 매니저가 직접 입력해야 했다. 때문에 통합적인 고객DB인 CDB(Client Data Base)시트를 만들었다. 고객이 직접 제출한 정보가 자동으로 연동되진 않고 매니저가 일일이 옮겨야 한다. DB를 직접 입력하고 만져야 하기 때문에 올바른 방법은 아니다. 정상적인 데이터베이스라면 입력기와 뷰어가 별도로 있어야 할 것이다.

RAW DB가 CDB로 바로 연동되지 않는 것은 큰 문제가 아니다. 두 정보는 어차피 분절시켜야 하기 때문이다. 고객이 직접 제출한 정보가 무조건 옳은 것은 아니며, 그 정보만으로 거래를 진행시킬 수도 없다. 때문에 전담 매니저가 개입하고 판단해 고객의 프로젝트를 정제하는 과정을 거쳐야 하는 특성이 있다. 고객이 최초에 제출한 정보는 고객의 주문사항이 아니라, 고객을 파악할 수 있는 최소한의 정보로 여겨진다. 고객이 진짜 원하는 것을 정의해내는 것은 결국 전담 매니저의 몫으로 남는다. 때문에 CDB는 단순히 통합Intergrated되었다는 의미보다는 정제Refined되었다는 의미가 더 강하다.

정제된 고객의 정보를 관리하는 CDB의 최초 버전에는 고객의 컨택포인트와 2~3칸의 노트만 있었다. 어떤 종류의 정보를 받고, 기록해야 할지 몰랐기 때문이다. 고객이 수십명을 넘어가자 관리가 힘들었다. 그 고객이 어떤 상태이고, 어느 매니저가 배정되었는지 직관적으로 파악할 수 있어야 했다. 고객의 상태를 분류했다. [응대중/전형중/제작중/완료/취소] 5가지 색상의 약속을 정하고 상태가 바뀔 때마다 다시 바꿔 칠했다. 색상표시가 안 되어 있으면 찾아내기 힘들었으나, 색상을 일일이 표기하는 것은 번거로우며 휴먼에러도 발생할 수 밖에 없었다. 조건부서식으로 상태표기숫자에 따라 해당 행이 자동으로 색상이 적용되게 설정했다. 고객상태 분류 방법은 총 9가지로 늘어났다가, 13가지로 늘어났다가, 지금은 16종류가 되었다. 이제는 더 이상 늘릴 필요는 없어 보인다.

 

 

CDB시트의 칼럼 종류는 [정보취득창구/담당매니저/방문목적/고객입력정보/응대방향/공고제목/공고경로/비밀번호/적합제작사대상] 등 추가하며 사용하고 있다. 입력기와 뷰어가 별도로 없는 상황에서 데이터베이스를 직접 확인하고 입력하고 있다 보니 칼럼 종류가 너무 많아지면 매니저의 업무 직관성에 오히려 방해가 되었다.

고객을 응대한다는 것은 상당한 시간과 집중을 요구하는 일이었다. 고객과의 커뮤니케이션과정의 효율을 높이기 위해 이메일로 주고받았던 내용들만이라도 우선 표준화시켜야 했다. 매일 메일을 작성하는 데 3시간을 넘게 들였기 때문이다. 이전 고객에게 제공한 고객 경험을 미래 고객에게도 재사용해야 했다. 이를 위해서 고객의 상황이나 상태를 분류해야 했다. 고객을 응대한 경험이 100회를 넘어가자 중요하거나 자주 쓰였던 메일을 한 곳에 모아볼 수 있게 되었다. 그 아카이브에 접속하면 유사한 메일을 작성할 때 참고할 수 있었으므로 일을 조금 더 수월하게 처리할 수 있었다. 그 이후에는 각 단계마다 메일의 템플릿을 만들어 특정 부분만 변경해서 사용할 수 있게 했다.

보냈던 이메일을 쌓아두었던 시트는 FUW(Frequently Used Wordings)라고 이름을 붙였다. 처음에는 작성하는 데 3시간씩 걸렸던 메일도 10분만에 베껴쓸 수 있게 되었다. 메일의 템플릿이 규격화되고, 고객마다의 정보를 특정위치에 입력하는 과정을 로봇처럼 반복하다보니, 문득 이 과정을 기계에게 위임할 수 있겠다는 생각이 들었다. 작성하는 내용중 매번 들어가는 공통요소가 있었고, 변경이 필요한 정보를 입력하는 위치 또한 항상 일정했기 때문이다. 고객의 정보를 고정적인 위치에서 불러낼 수 있으면 메일을 자동으로 생성할 수 있어 보였다.

이것이 작동되기 위해서는 고객의 정보를 CDB에서 불러낼 수 있어야 했다. 고객의 정보가 300개를 넘어갈 즈음이었다. 고객 마다의 고유 번호는 입력된 순서대로 매겨져 있었지만, 이를 ProjectCode를 부여하기로 했다. 컴퓨터가 고유의 Data를 구분할 수 있으면서, 사람이 보더라도 간략하게나마 직관적으로 코드를 파악할 수 있도록 년월일6자리에 고유번호2자리를 붙이기로 약속을 정했다. 19052703은 19년 월 27일 3번째로 들어온 프로젝트를 칭하는 식이다.

이제 FUW에서 ProjectCode만 입력하면 십수개의 이메일이 자동 생성되고, 그 중에서 골라서 발송하면 된다. GDSS에서 제공되는 부가기능인 Mail Sender를 사용하면 Gmail로 가지 않고도 바로 발송시킬 수 있지만 상황별로 메일의 종류가 80개를 넘어가는 경우엔 큰 도움이 되지 않아서 나는 사용하지 않았다.

시스템의 도움없이 중개를 하던 과정에서 가장 복잡하고 어려웠던 것은 미팅일정을 조율하는 일이었다. 한 번 작성하는 데에 최소 30분씩 걸렸고, 미팅시간이 잘못 조율되면 큰 사고로 이어지기 때문에 실수하지 않으려 발송 전에 2번씩 체크하느라 정신이 날카로워질 수 밖에 없었다. 이 과정에 들어가는 시간뿐만 아니라 정신노동의 부담을 덜어내는 것이 과제였다. 미팅일정 안내메일 생성기가 작동하려면 파트너스의 정보도 단번에 불러들일 수 있어야 했다.

파트너스의 Code는 숫자가 아닌 닉네임을 부여하기로 했다. 주식시장의 기업코드의 형태로 할지, 중복이 없이 이메일로 할지 고려했으나, 모두 직관성이 떨어졌다. 매니저가 Code를 외우거나, 조회하는 별도의 과정이 필요했기 때문이다. 우리가 매일 부르는 구어로 닉네임을 쓰기로 했다. 닉네임은 회사이름을 단순화시킨 것인데 [무조건 한글로 적을것, 띄어쓰기는 없앨 것, ㈜없이, ‘프로덕션’이나 ‘스튜디오’는 제외]의 약속을 지켜 입에 잘 붙는 것으로 정했다.

GDSS로 만들어진 시스템의 가장 큰 장점은 유지보수 비용이 저렴하다는 것이다. 고객에 대한 데이터규격이나 파트너스 평가기준을 업데이트하는 일은 일반적인 개발팀에서는 주 단위의 작업이 요구될 것이다. 나도 연동된 시트들이 늘어날수록 주요 구조 변경에 따른 부가작업이 늘어나는 것은 어쩔 수 없지만, 여전히 계획만 확실하다면 반나절만에 리팩토링을 끝낼 수 있다.

파트너스의 정보도 처음에는 구글form으로 받았다. 서비스 공급자인 파트너스가 제출한 정보 또한 거래중개에 바로 쓸 수가 없다. 온라인 상에서 심사를 강화하거나 form을 더 정교하게 만들어도 불가능하다. 근본적으로 일을 받고 싶은 공급자 입장에서는 무조건 자신들이 잘한다고 주장하기 때문이다. 중개 플랫폼을 대상으로 영업을 하려는 공급자가 너무 많은 탓에 정보보다는 노이즈가 더 많았다. 노이즈를 제거하는 일은 받은 정보와 기록하는 정보의 분절로 해결한다. 모든 파트너스는 방문심사를 거쳐야 하며, 이 과정에서 파트너스의 DB를 정제Refined해서 관리하게 되었다. 중개자는 단순히 연결만 하면 되는 게 아니라, 검증과 심사의 역할까지 수행해야 한다는 것을 뒤늦게 깨달았다.

정제된 파트너스 정보에는 파악, 분류, 평가, 심사, 활동기록 등 여러 가지 의미들이 포함되어 있다. 세부 항목들을 따지면 40가지가 넘는다. 처음에는 제작실력이 얼마나 뛰어난지를 위주로 측정했다. 지금은 제작실력은 3가지 항목으로 줄여버렸고 사업안정성과 서비스가치제안능력 등 고객만족요인에 더 밀접한 영향을 미치는 요소를 파악하기 위해 노력중이다. 이 과정은 내 예상보다 훨씬 어려웠고, 할 일도 많았으며, 복잡했다. 지금까지 7차 업데이트가 이뤄졌다. 시스템 구현의 문제도 있었지만 내 주관적 평가가 개입되는 문제도 있었다. 인문대학원을 나온 친구에게 사회조사방법론을 1일 과외받고 객관적 지표를 만드는 법을 흉내냈다.

서비스 공급자를 평가하는 과정은 네 단계에 걸쳐 개선되었다. 처음에는 각 제작사의 사무실을 방문해 백지의 노트에 대화내용을 기록해나갔다. 두 번째 단계에서는 필수 질문을 몇 가지 만들어서 공통적으로 활용했다. 세 번째 단계에서는 필수 질문과 선택적 질문을 구분해서 대화가 풍부해지도록 유도했다. 네 번째 단계에서는 인터뷰하는 도중에도 실시간으로 파트너스를 평가할 수 있도록 Refiner를 만들었다.

좌측의 리파이너에 입력하면 Refined DB의 데이터 순서와 일치된 data set이 생성된다.

상대적으로 덜 중요하게 여긴 일이지만, 최초 제출된 RawDB가 관리되지 않고 소실되던 상황을 해결할 방법을 찾았다. Caldera Form의 Processor기능을 활용해 GDSS의 특정 시트로 데이터를 누적시킬 수 있었다. 이전의 방법대로라면 웹사이트 상에서 제출된 고객의 정보를 확인하기 위해서 [워드프레스관리자 > form플러그인설정 > form선택 > 데이터확인] 과정을 거쳐야했기에 시간과 단계가 오래 걸렸는데 클릭을 몇 번이라도 더 줄였다. Caldea Form은 한국어를 인식하지 못하는지 데이터를 엑셀에서 불러들이면 깨지는 현상이 발생했는데 GDSS에 직접 연동하자 해당 문제를 신경쓰지 않아도 되었다.

그리고 form에 정보가 입력되는 순간, 관리자에게 메일을 자동으로 발송하는 기능도 설정했다. 덕분에 Gmail의 검색창으로 고객 정보를 조회할 수 있었다. 모바일 디바이스에서 GDSS 앱을 켜고 접속하는 데에는 로딩이 느려 20초 이상 걸렸는데 Gmail 앱을 켜고 들어가면 10초 내외로 찾아낼 수 있었다. 메일을 자동으로 보내게 하려면 WP Mail SMTP라는 것을 설정해야 했다. 어떻게 한 건지 기억은 안 나지만, 3일 정도 걸렸으며 당시 너무 무섭고 어려웠었다는 기억은 선명하다.

데이터 관리의 자동화는 소홀했던 편인데, 데이터가 자동으로 돌아가도록 만들어 놓으니 몇 가지 통계를 낼 수 있게 되었다. 예를 들어 우리 플랫폼에서 가장 돈을 많이 벌어간 제작사, 지원은 적게 했으나 승률이 높은 제작사, 고생은 많이 하고 돈은 못 번 제작사 등을 솎아낼 수 있게 되었다. 이런 재밌는 통계를 내는 아이디어는 무궁무진하지만, 우리의 생산성 향상에 별 도움이 안 되기 때문에 그 이상의 작업은 진행하고 있지 않다.

서비스 공급자 입장에서 자신과 상관없는 프로젝트 알림을 받게 되면 그 또한 스팸으로 여기게 된다. 어차피 계약을 맺는 곳은 한 업체니, 그 과정에서의 경쟁을 줄여야 공급자의 출혈경쟁을 방지하고 오랫동안 플랫폼에서 활동할 수 있도록 장려할 수 있다. 때문에 비드폴리오에 등록되는 프로젝트는 매니저들의 검토를 거쳐 10~20곳의 제작사에게 배포된다. 서로의 시간을 5분씩 빌리는 것은 큰 수고가 아니다. 이 과정은 사람 매니저들이 상호 의견을 주고 받도록 하는 것이 핵심이기 때문에, 기계적으로 처리하는 것은 불가능하다. 매니저들이 프로젝트에 적합한 공급자를 추려내는 데에 집중할 수 있도록 보조도구를 만들고, 선정된 제작사에게 이메일을 보내기 편하도록 이메일 묶음을 만들어주는 추출기도 만들었다.

=index(Refined_DB!$1:$259,match(C5,Refined_DB!B:B,0),3)

매니저는 하루에도 전화를 20통씩 한다. 모르는 번호로 전화가 자주 오는데, 기존 고객인지, 감독님인지 파악할 수 있도록 번호 조회기도 만들었다.

ProjectCode를 해체하면 날짜를 추출할 수 있다. 하지만 이는 단순 숫자일 뿐, 서식상에서 날짜로 인식되는 정보가 아니다. 19052703에는 년/월/일/순번의 정보만 있기 때문에 주 단위의 구분은 불가능하지만 월간 단위로는 끊어낼 수 있다. 일련을 규칙대로 개수를 세어 데이터를 만들어낼 수 있다. 그리고 이 표를 직관적인 차트로 바꾸면 플랫폼 운영상태를 파악할 수 있는 DASHBOARD가 된다.

이 외에도 제작중 특이사항을 기록하고 관리하는 별도의 시트를 만들었고, 비용처리하는 시트도 만들어 회계업무를 간소화시켰다. 월단위로 쏟아져 나오는 마케팅 데이터들도 연동해 성과를 측정할 수 있다. 꾀를 좀 부려 응용하고자 한다면 가능성이 무궁무진하지만 너무 시스템에만 매몰되어 있는 것 같아 요즘은 지나친 고도화에 집착하진 않으려 자중하고 있다.

10년 전, MIT에서 콜라병을 따서 잔에 부어 마시는 과정을 147단계로 구분했다는 발표를 듣고 충격 받았다. 당시엔 왜 그런 연구를 무엇을 위해 한 것인지 이해하지 못했다. 단지 연속 동작이 그렇게나 많은 최소 행위 단위로 분절될 수 있다는 사실에 놀라기만 했다. 요즘은 반대의 의미로 놀란다. 그렇게나 많은 행위의 묶음을 의식하지 않고도 인간의 두뇌는 연속 행위로 인지하고 처리해낸다는 사실.

내가 수행하던 과업을 시스템에 위임해 생략시키려는 시도는 매번 순탄하진 않았다. 그 행위가 가시적이며 측정가능하고 선형적으로 이뤄져 있다면 별 어려움이 없었다. 하지만 실제 세상은 정성적이며 비체계적이고 순서상으로 일관성없는 행위가 더 많았다. 그런 영역의 업무는 당분간 인간이 계속 수행해야 할 것이며, 그런 영역의 일이라면 집중력을 높일 수 있는 환경을 제공하거나 판단을 돕는 보조도구를 통해 정신노동의 생산성을 높여야 할 것이다.

 

• 맺음말

정신을 차리고 보니 어느덧 두번째 사업을 하고 있다. 시간도 1년 10개월이 지났다. O2O로 불리다가 온디맨드로 불리기도 하는 이런 종류의 사업 유행이 한풀 꺾이고 있다. 대부분 사라지고 일부는 남았다. 흑자로 전환하지 못하고 사라진 사업체의 문제는 무엇이었을까? 결국 문제는 생산성이다. 애초부터 생산성이었고 앞으로도 생산성일 것이다. 생산성은 온전히 나에게 달린 문제다.

1년만 일렀어도 지금의 시스템은 구현이 불가능했을 것이다. 또 3년쯤 후라면 유사한 수준의 생산효율을 낼 수 있는 방법론과 보조도구들이 일반화될 것이다. 놀랄 일도, 새로운 현상도 아니다. 10년 전에는 수천만원 들었던 웹사이트를 지금은 몇 만원에도 만들어낼 수 있다. 수기를 문서로 작성하던 시기에 타자기가 도입되고, 다시 워드프로세서로 넘어간 흐름과 다르지 않은 것이다. 나는 시기적으로 혜택을 받은 것일 뿐이며, 머지않아 이 또한 보편화될 것이다.

GDSS에 대한 이야기를 했지만, 적은 자원으로 정보처리능력을 확보할 수 있는 한 가지 방안일 뿐이다. 이 것은 보조도구일 뿐, 정보처리방법의 유일한 해결책도 아니다. 이 외에도 도움될 수단과 방법이 있다면 확보해 정보처리능력을 키워야 한다. 그리고 정보처리능력 또한 플랫폼 운영의 전부가 아니다. 그리고 플랫폼 운영 또한 회사의 전부가 아니다.

 

—

비드폴리오는 이렇게 일하고 있습니다. 마케팅 담당자 채용 중입니다. 사업기획분야도 채용중입니다. 플랫폼 사업을 운영하며 축적되는 경험자산을 토대로 추가 사업을 검토중입니다. 영상광고시장에 뜻과 비전이 있는 분이라면  robin@vidfolio.kr