서비스 단계별로 개선하기

안녕하세요. 스포카 UX 디자이너 남유정입니다.

서비스를 만드는 회사나 팀에서는 많은 경우 애자일, 린 등의 방법론을 실천하기 위해 노력합니다. 하지만 실무를 진행하다 보면 여러 가지 상황들로 인해 길을 잃습니다. 추정시간은 이미 예측을 벗어났고, 목표했던 배포 날짜도 한참 지나가 버립니다. 특히 서비스 대규모 업데이트를 앞둔 경우, 이러한 문제는 더욱 심화됩니다.

이번 포스팅에서는 서비스 개선을 위해 대규모 업데이트를 목표했다가, 단계별로 서비스를 최적화하는 방식으로 전략을 선회하면서 이를 위해 어떤 과정을 거쳤는지를 실사례를 들어 소개합니다.

스프린트 단위로 일하는데, 서비스는 워터폴한 아이러니

실무를 하다 보면 서비스 배포 주기를 늘어지게 하는 요인은 여러 가지가 있습니다. 특히 저희의 발목을 잡았던 주된 요인은 다음과 같았습니다.

• 기존 코드로 인해 기능 추가 및 디자인 개선이 어려워 새로 만드는 결정을 함
• 별도의 제품 라인을 만들어서 신규 서비스를 선보여야 하는 비즈니스 상황이 발생함
• 요구사항을 모아보니 서비스 설계가 비대해졌음
• 서비스 사용 환경상 잦은 배포가 쉽지 않은 경우가 있음
• 때로는 잦은 업데이트로 인한 고객이 피로감을 호소함

이런 일들을 겪으면서, 업무는 매주 스프린트 단위로 진행하면서도 서비스 배포 주기가 짧게는 1달, 길게는 6개월을 넘기기도 하는 기형적인 상황이 발생했습니다. 버그를 고치거나 사소한 요구사항을 반영하는 이슈들은 그나마 스프린트 주기와 일관성을 가졌지만, 새 기능을 업데이트 하거나 신제품을 선보이는 프로젝트를 진행할 때에는 일정이 엿가락처럼 늘어지곤 했습니다.

• 신기능이나 신규 서비스는 운영 중인 제품이 아니라 사용하는 고객이 없음
• 사용하는 고객이 없으니 피드백이나 인입이 없어, 타임라인에 둔감해짐
• 특히 기존 제품을 리뉴얼 하려고 할 때
  • 코드 유지보수가 어렵고, 크고 작은 빚이 많아서 새로 만드는 선택을 함
  • 멀쩡히 돌아가는 기존 기능을 똑같이 새로 만드는 비용이 추가됨
  • 릴리즈 시기가 미뤄지면서 그간 수집된 요구사항이 더 추가됨
• 미뤄짐의 무한 반복

이런 문제를 반복하던 중, 저희는 전환점이 되는 사건을 맞이했습니다.

가장 많이 쓰는, 개선점이 산처럼 쌓인 서비스 개선을 시작하다

저희는 2017년 3분기에, 도도 포인트 어시스트라는 프로그램을 개선하고자 마음먹었습니다. 결제 후 점원이 매장 POS나 컴퓨터에서 결제 금액을 입력하면 적립할 포인트를 계산해주는 프로그램이며, 다음과 같은 특징을 갖고 있습니다.

1. 도도 서비스 라인업 중 유일한 윈도 설치형 프로그램
2. 구형 POS가 많은 한국 매장 환경상, 윈도 XP까지 동작을 커버해야 하는 제품
3. 홀로 분리된 개발환경, 회사 내 윈도 개발인력 많지 않음
4. 상기한 이유로, 2012년경부터 메이저 업데이트 없이 유지보수만 하던 제품
5. 덕테이핑된 코드와 서비스 설계, 디자인이 매우 많이 남아있는 제품
6. 그럼에도 POS를 주로 쓰는 한국 특성상 고객이 가장 많이 사용하는 프로그램

이 서비스를 개선하기로 결정한 만큼, 몇 년 동안 쌓여있던 요구사항을 모아서 신기능을 추가하고 전체 설계를 개편하면서 최신 디자인도 반영하는 거대한 목표를 세웠습니다. 더불어 신기능 설계와 디자인을 진행하는 동안 POS 기기와 도도 포인트 프로그램 간 통신 환경 안정화까지 도모하는 큰 마일스톤도 함께 진행하기로 했습니다. 그래서 통신 환경 안정화를 우선 진행하는 약 3주간, 리뉴얼할 서비스의 전체 기능 설계와 디자인 작업을 완료했습니다.

01. 배포 전략을 재고하다

프로젝트를 한창 진행하던 중, 사소한 요구사항 응대를 위해 결제 금액을 편하게 입력할 수 있도록 00 버튼을 추가하는 간단한 이슈를 진행했습니다. 그런데 이 기능을 업데이트하고 나서 매장의 항의가 빗발쳤습니다. 00 버튼을 추가하는 김에, 숫자 패드 배열을 최신 버전으로 변경하고 중복으로 있는 액션 버튼을 하나로 줄인 간단한 이슈였습니다. 하지만 업데이트를 진행한 날, 강도 높은 여러 매장의 피드백을 듣고 급하게 00 버튼을 제외한 모든 변경사항을 롤백해야만 했습니다.

롤백 후 검토해보니, 이 변경사항은 문제가 있을 수밖에 없었습니다. 결제 금액을 입력하여 적립 포인트를 계산하는 행위는 매우 간단한 행동처럼 보이지만 다음과 같은 특징이 있었습니다.

• 이 행동의 수행 횟수는 매장의 일일 결제 횟수와 같으며, 매우 빈번하게 수행됩니다.
• 행동의 수행 시간은 짧은데, 클릭 이벤트가 매우 많이 일어나는 행동입니다.
  • 하루 200번의 결제가 일어나고, 평균 결제 금액이 12,350원이라고 가정할 경우, 각 결제당 6회(숫자 패드 5회, 적립 버튼 1회)의 클릭, 하루 총 1,200번의 클릭 이벤트가 발생합니다.
• 하루 1,200번의 클릭이 발생하는 화면의 배열을 하루아침에 바꿈으로써, 매장의 혼란이 극대화될 수밖에 없었습니다.
  • 특히 이 행동은 수행할 때의 집중도가 상대적으로 얕고, 화면의 배열을 거의 외우다시피 하여 순간적으로 수행하는 것이라 더욱 문제가 되었습니다.
  • 집중도가 높고 여러 화면을 넘나들어야 하는 전체 흐름이 긴 행동은, 버튼 배열과 디자인의 변경사항에 상대적으로 혼란을 덜 겪습니다. (예, 목록에서 고객을 찾아 선택하여 메시지를 작성하고 발송함)

이 일을 겪은 후 제품 개선 진행에 대한 팀 내 불안감이 커졌습니다. 큰 규모의 업데이트를 생각하며 일을 진행하고 있었으나, 더욱 신중하게 접근하지 않으면 나중에 더 큰 반발이 있을 수도 있겠다는 사실을 뼈저리게 느꼈습니다.

02. 고객이 부담스러워하지 않는 단위로 배포하자

이 문제를 해결하고자, 부분 배포 전략을 수행하는 것을 제안했습니다. 제안한 내용은 다음과 같습니다.

• 우리가 가장 중요하게 해결하고자 하는 문제가 무엇인가?
  • 리뉴얼 자체가 목적이 아니다. 해결하려는 문제를 다시 분명히 하자.
• 고객이 최대한 자연스럽게 업데이트 내용을 받아들일 수 있는 순서와 단위로 배포하자.
  • ‘이번 업데이트의 개선사항은 무엇입니다.’를 한 마디로 설명할 수 있는 단위로 나누자.
  • 기존의 행동 흐름에서 자연스럽게 연결되는 시나리오를 가진 기능을 먼저 배포하자.
  • 새로운 기능을 추가한다면, 기존의 행동, 디자인과 공통 속성이 있는 것을 먼저 배포하자.
  • 몇 년간 고객이 학습한 부분을 계승하면서 최신 디자인 기조를 담을 수 있도록 하자.
• 각 단위는, 작업부터 실 배포까지 추정 기준 2주일 내로 가능한 단위인지 점검하자.

이에 따라 리뉴얼할 사항들을 쪼개서 전체 리스트업 하고, 새롭게 단위를 나누어 우선순위를 배열했습니다.

03. 배포 단위에 맞게 중간 전략을 설정하다

우선순위를 재배열한 후, 이상적인 상태의 설계와 디자인을 쪼개서 현 버전에 부분적으로 신기능이 들어가도 전체 서비스 사용 흐름과 디자인에 문제가 없도록 중간 단계를 재설정했습니다. 또한 기능을 구현하고 있는 동안에는, 바로 다음에 구현될 기능만 잘라 워킹 프로토타입을 만들어서 내부 테스트를 다시 수행했습니다.

04. 검증 단계를 더 추가하다

기능 구현 이후에는 로컬에서 QA를 하는 것이 아니라, 나이틀리 빌드¹ 배포 버전으로 실 서버에서 동작하는 제품을 사용하면서 QA를 진행할 수 있도록 했습니다. 이 과정에서 서비스 교육팀, CS팀 등과도 함께 QA를 진행하여, 변경사항에 대한 사내 공유를 강화했습니다.

QA가 완료된 후에는 전체 고객에게 바로 배포하지 않고, 부분 배포 기간을 1주일 두어 적어도 30명의 고객이 1주일간 사용해보고 크리티컬한 문제가 없다고 판단된 후 전체 배포를 진행했습니다.

효과

신규 기능이 올라갈 때의 프로세스를 전체적으로 변경한 후, 다음과 같은 장점을 경험했습니다.

1. 예측 가능한 작업 추정

추정 기준 2주일 이내로 배포할 단위를 설정했기 때문에, 추정 예측이 훨씬 높아졌습니다.

2. 업데이트 내용에 집중된 고객 피드백 수집

하루 수십 번~수백 번을 사용해야 하는 제품이기 때문에 고객이 업데이트로 인한 변경사항을 학습해야 하는 피로도가 지나치게 높으면, 개선된 부분에 대한 피드백을 듣기 어려웠습니다. 최악의 경우에는 새로운 기능에 대한 피드백을 듣기도 전에 손에 익은 예전 버전으로 롤백해달라는 요구를 듣기도 했습니다. (실제로 릴리즈의 형태로 업데이트를 강행한 제품은 지금도 종종 이런 문제가 있습니다.)

하지만 배포전략 변경 이후에는 한 번의 업데이트에 고객이 집중할 수 있는 하나의 변경 사항을 제공함으로써, 고객은 업데이트된 하나의 기능에만 집중하여 사용할 수 있고, 저희도 업데이트한 기능에 집중된 피드백을 들을 수 있었습니다.

3. 활발한 사내 공유

부분 배포하기로 전략을 수정한 것은, 고객뿐 아니라 사내에서도 효과를 발휘했습니다.

처음 진행한 내부 테스트는 리뉴얼할 제품의 전체 설계와 디자인을 완료하여 제품 전체를 워킹 프로토타입으로 만들고, 약 20분 동안 1명당 10여 개의 과업을 수행하게 하여 피드백을 받는 방식으로 진행했습니다. 사내 직원이라 해도 개편 내용을 그날 처음 확인하는 것이라 변경사항이 지나치게 많기 때문에, 다소 분산된 의견이 수집되었습니다. 또한, 과업 수행 시간이 길어 테스트의 집중도가 저하되는 문제도 있었습니다.

그러나 배포 전략 변경 이후에는 배포될 단위별로 워킹 프로토타입을 다시 쪼개서 만들고, 한 번에 하나의 내용에 대해서만 테스트를 진행한 후 피드백을 수집했습니다. 덕분에 훨씬 몰입이 높은 환경에서 테스트가 진행되었고, 한 내용에 대한 심층적인 피드백을 수집할 수 있었습니다.

또한 내부 테스트 자체가 제품 변경사항에 대한 사내 홍보 역할을 하는 부차적인 효과도 있었습니다. cafe study 형식²으로 내부 테스트를 진행하니, 곧 배포를 앞둔 신기능이 무엇인지 사내에 자연히 홍보가 되어, 타 부서에서도 여러 채널로 배포 일정을 먼저 물어오기도 했습니다.

특히 서비스 교육팀이나 CS팀에는 얼마 전에 눈으로 확인하고 피드백을 준 내용이 업데이트된다는 안정감을 줌과 동시에, 고객이 한 번에 이해할 수 있는 단위만큼 업데이트되기 때문에 업데이트로 인한 인입량이 감소하여 해당 부서의 부담도 줄였습니다.

염두에 둘 것

1. 어떤 점이 개선되었는지 고객에게 쉽게 안내해야 합니다.

고객이 업데이트를 실행한 전/후 어떤 점이 개선되는지, 또는 어떤 기능이 추가되는지 안내하는 것은 매우 중요합니다. 설명이 필요 없을 정도로 서비스 설계를 잘 했다 하더라도 아무런 안내가 없다면, 시간을 들여 업데이트를 진행한 고객에게 개선점을 스스로 찾으라고 하는 꼴이 됩니다. 사소한 버그를 수정했다 하더라도, 어떤 부분을 수정하고 개선한 것인지 간결하고 구체적으로 안내되면 고객에게 기본적인 신뢰감을 줄 수 있습니다.

2. 업데이트를 기꺼이 수행한 고객을 실망하게 하지 않아야 합니다.

업데이트 이후 ‘이상하다. 버그 없네’ 할 수 있다면 좋겠지만, 대개 예상치 못한 문제가 발생할 확률은 항상 존재합니다. 이때 자칫 단계별 배포 작업에만 집중하면 다음 스텝에 배포할 내용을 구현하는 것만 계획하고, 업데이트 직후 모니터링을 소홀히 하기 쉽습니다.

최신 업데이트 버전을 바로 설치한 고객은 우리 서비스를 가장 활발히 사용하고 있는 고객일 것입니다. 하지만 업데이트를 일찍 진행한 고객일수록 문제를 빨리 밟을 확률은 더 높습니다. 특히 단계적으로 배포하여 업데이트 횟수를 늘린다면, 서비스를 활발히 쓰는 고객이 문제를 겪게 될 빈도는 더욱 늘어납니다.

따라서 단계별로 배포 횟수를 늘릴수록 테스트 코드를 추가하고 QA 프로세스를 강화해야 합니다. 그럼에도 문제가 발생했다면 빠르게 문제를 해결할 수 있도록, 업데이트 직후에는 모니터링과 문제 상황에 대응할 여유 슬롯을 두는 것을 잊지 않아야 합니다.

여담

1. 이상적인 시나리오와 디자인 작업의 필요성에 대하여

이번에는 약 3주간의 기간을 거쳐, 리뉴얼할 제품의 이상적인 전체 시나리오와 디자인 원칙을 먼저 확립하고 이를 팀 내에 공유한 후, 최종 목표로 가기 위한 쿠션 역할을 하는 중간 전략을 다음에 설정하는 방식으로 프로젝트를 진행했습니다. 중간에 전략을 변경한 것이긴 하지만, 최초에 작업한 이상적인 상태의 제품 설계는 중간 전략을 설정할 때 ‘기준선’의 역할을 함과 동시에, 팀 내에 제품의 전체 방향성을 공유하는 매개의 역할을 했습니다.

이러한 효과를 체험했으므로 다음에도 프로젝트 수행시 제품 설계와 디자인의 최종 목표에 대한 작업을 선행하려 합니다. 하지만 이때 작성하는 이상적인 시나리오와 디자인은 ‘반드시 그렇게 되어야 하는 목표’가 아닌, 공유와 매개, 중간 전략을 위한 기준이 되는 역할을 해야 합니다. 또한 이번에는 이 작업에 3주가량 시간을 썼는데, 보다 최적화할 수 있는 방향을 모색하고 있습니다.

2. ‘레거시’라는 단어의 제한적인 사용에 대한 팀 내 논의

서비스를 오랜 기간 운영하다 보면, 자연히 팀 내에서 ‘레거시(legacy)’라는 단어를 자주 사용하게 됩니다. 하지만 현재 고객이 사용하고 있는 서비스를 받치고 있는 코드나 디자인을 습관적으로 레거시라고 이야기하는 것은, 서비스를 ‘뜯어고쳐야 할 대상’으로만 바라보게 되는 부작용이 있어, 이 단어를 최대한 자제하여 사용하자는 팀 내 논의가 있었습니다.

4. 함께 읽으면 좋은 아티클 소개

Things You Should Never Do, Part I 트렐로 서비스를 개발한 것으로 유명한 프로그래머 Joel Spolsky의 글입니다. 이미 돌아가는 서비스의 코드가 엉망이라고 생각한다고 하여, 섣불리 재작성을 시도하는 것을 ‘절대 하지 말아야 할 일’이라고 이야기합니다. 코드 뿐 아니라 서비스 설계와 디자인에도 적용되어야 할 내용입니다. 이 아티클이 수록된 책은 한국어로도 번역되어 있습니다.

마치며

저희는 아래와 같은 상황에서 많은 시행착오를 겪으며, 안정적으로 기존 서비스의 개선 프로젝트를 실행하는 방법을 이번에 배웠다고 생각합니다.

• 서비스를 운영한 지 7년 차. 제품 설계와 디자인, 코드 모든 것에 많은 빚이 남아있었습니다.
• 그러다보니 전체 서비스를 개편하는 설계를 하고, 디자인을 전면 개편하고, 코드도 뒤엎는 시도를 2016년부터 지속하여 수행했습니다.
• 그 과정에서 제품을 만드는 사람과 이를 받아들여야 하는 고객 모두가 매우 힘들다는 것을 경험했습니다.

여러 해 동안 서비스를 유지보수 해온 팀이라면, 제품 개선에 자연히 많은 욕심이 생깁니다. 하지만 기존의 시나리오와 디자인, 코드 베이스로 오랜 기간 서비스를 해왔다면, 현재의 서비스 또한 어느 정도 ‘고객이 이해하고 사용할 수 있는 상태’라는 믿음을 가져야 합니다. 또한, 서비스를 무조건 대규모로 개선하려고 하는 시도가 자칫 이를 사용하는 고객을 더욱 괴롭게 하는 일이 되어서는 절대로 안 될 것입니다.

이번 경험을 계기로 크리에이터 팀 내에서는 이 내용을 백서처럼 공유하고 프로세스를 정하여, 다른 프로젝트를 수행할 때에도 최대한 비슷한 방식의 프로세스를 밟기 위한 정규화를 진행하고 있습니다. 읽어주셔서 감사합니다.