처음으로 사용자의 지갑을 열다(ft. 서비스 출시 후기)

얼마 전 진행 중인 프로젝트에 대해 펀딩 사이트 '텀블벅'에서 펀딩을 진행했고, 6월 20일에 성공적으로 펀딩을 마무리하고 펀딩 참여자들에게 베타 버전 서비스를 전달하는 데 성공했다! 총 62명이 펀딩에 참여해 주었고, 총모금액은 609,234원에 달했다. 노력해준 모든 팀원들에게 정말 감사하다는 말을 전하고 싶다.

 

사실, 실제 사용자 경험을 바탕으로 소프트웨어를 만드는 것은 이전에도 여러 번 있었고, 그때가 오히려 더 많은 이용자를 기록했다. 하지만 이번 경험이 특별한 이유는 처음으로 내가 만든 소프트웨어를 돈을 받고 판매한 것이기 때문이다! 모두가 알겠지만, 사용자가 지갑을 연다는 것은 정말 어려운 일이다. 좋은 제품, 기획, 마케팅이 모두 집중되어 사용자를 설득해야만 가능한 일이다. 나는 개발 팀장으로서 좋은 제품과 기획으로 사용자를 설득하는 책임을 가지고 최선을 다했다.

 

펀딩 성공! 나도 몰래 후원한건 안비밀이다.

 

물론, 우리는 앱 스토어나 결제 시스템을 통한 판매가 아니라 펀딩이라는 특별한 방법을 사용했기에, 다른 의견을 가진 사람들도 있을 수 있지만, 우리 팀의 상황을 고려하면 펀딩은 적절한 수단이었다. 또한, 우리가 제공한 것은 베타 버전 이용권과 출시 후 유로 버전 3개월 이용권이 전부였기 때문에, 제품을 통해 사용자를 설득하는 것 외에는 지갑을 열게 할 다른 방법이 없었다

 

이번 베타 버전을 출시하면서 사실 정말 쉽지 않았다. 이전에도 서비스를 출시한 경험은 있었지만 이번 프로젝트는 실제 돈을 받기에 부담도 컸고 프로젝트의 규모와 난이도도 어려웠기에 우여곡절이 정말 많았다. 하지만 그렇기 떄문에 배우는 것도 정말 많은 프로젝트인 것 같다. 이번 글에서는 내 이번 경험을 살려 실제 상용화된 서비스를 배포하면서 내가 느낀 것들을 정리해보고자 한다.

 

 

1. 완벽할 수 없다

이번 경험으로 가장 깊게 느낀 사실이다. 몇 달 동안 고생하여 만든 결과물을 사용자에게 처음 보여주는 것이기에, 아무리 작은 부분이라도 서비스를 개선하기 위해 끊임없이 노력했다. 그럼에도 불구하고, 부족한 부분이 계속 보였다. 아니, 오히려 더 많이 알아갈수록, 지식의 저주에 빠진 것 마냥 부족한 부분이 더욱 잘 보인다고 해야 할까? "이런 형편없는 상태로 출시를 한다고? 출시를 미뤄야 하나?"라고 생각한 적도 있었다.

 

그러나 완벽함을 추구하기 위해 배포 일정을 미루는 것은 정답이 아니다. 소프트웨어의 성질 상 완벽함은 이루기 어려운 것 같다. 반복적인 작은 주기를 가지고 계속 수정하며, 조금씩 이상적인 상태에 가까워지는 것이 내가 할 수 있는 유일한 일인 것을 깨달았다.

 

사실, 완벽을 추구하는 것이 소프트웨어 분야에서 항상 정답은 아니다. 소프트웨어 산업에서는 고객의 요구사항이 빠르게 변하기 때문에, 가설 설정과 실험, 그리고 끊임없는 변화가 필요하다. 완벽을 추구하는 것은 이러한 과정에 방해가 되며, 경제적으로도 비효율적이다. 이 이유 때문에 우리가 펀딩을 먼저 시도한 것이기도 하다. 우리가 만드는 게 정말 사용자에게 필요한 것인가? 이 사실에 대한 검증이 필요했다. 펀딩 결과로 1차 검증은 성공한 듯하다.

 

그럼에도 불구하고 첫 출시는 특별하지 않는가..? 정말 며칠 동안 정신없이 최선을 다했다… 팀원들이 모두 열심히 해준 것을 알기에 그에 걸맞은 서비스를 출시하고 싶었다. 배포 10일 전부터 과부하 상태에서 작업했기에, 배포 후 즉시 탈진한 느낌이 들었다. 서버라도 터졌으면 아마 나도 쓰러졌을 것이다. 다행히 그런 일은 없었고, 평화롭게 꿀잠 잘 수 있었다.

배포 이후 남긴 글, 기획팀 사람들은 나를 CTO라고 불러주신다. 감사하지만 부끄럽고 웃기다.

 

 

2. 하나의 공통 목표와 소통

이번 출시 과정에서 느낀 점 중 하나는, 프로젝트가 성공하려면 모든 구성원이 하나의 공통 목표를 가져야 한다는 것이다. 하지만 이는 결코 쉽지 않으며, 이를 위해선 소통이 중요하다는 것을 깨달았다. 출시 과정에서 정말 다양한 우여곡절이 있었지만, 가장 힘들었던 순간은 출시 며칠 전 진행한 최종점검 회의였다.

 

우리 개발팀은 출시를 위해 필요한 기능을 모두 개발했다고 확신하고 있었지만, 기획팀과 경영팀은 몇 가지 기능이 빠져있다고 판단했던 것이다. 즉, 각 부서가 서로 다른 그림을 그리고 있던 것이다. 완전 아마추어스러운 실수였다. 배포에 어떤 기능을 포함할지, 그리고 각 기능이 사용자 관점에서 어느 수준까지 작동해야 하는지를 사전에 명확히 정해야 했다. 그러나 어느 순간부터 모든 부서가 출시 준비에 바빠 소통을 제대로 하지 않았던 것이다.

 

개발팀 입장에서는 특정 기능은 베타 버전에 포함할 수 없으며, 다른 기능은 시간과 자원의 부족으로 제한된 수준에서만 가능하다고 전달했다고 생각으나 기획팀과 경영팀은 이를 완전히 다르게 이해하고 있었다. 이번 배포가 고되게 된 것도 이때분이다. 덕분에 개발팀은 며칠간 부족한 기능을 채우기 위해 추가적으로 작업할 수밖에 없었다.

 

앞으로 어떻게 고칠 것인가?

그렇다면 어떻게 이런 일이 발생하지 않도록 할 수 있을까? 우선 배포 전에 어떤 기능이 포함되는지, 그리고 각 기능이 어느 수준까지 작동하는지에 대해 기획팀과 경영팀 등 모든 이해관계자들이 모여 상세한 명세를 작성하는 시간을 확보하기로 했다. 우리의 개발팀은 스프린트 단위로 작업을 진행하므로, 앞으로 이 작업은 스프린트 계획 회의에서 진행할 예정이다.

 

다음 단계는 배포할 작업에 대한 추정을 통해 작업 마감일을 조정하는 것이다. 추정은 기본적으로 불안정하기 때문에, 보다 경제적이고 정확한 추정을 위해 애자일의 반복 주기를 통해 쌓은 데이터를 활용해야 한다. 우리 팀은 지라를 이용하여 스토리 포인트로 작업량을 추정하였고, 이를 근거로 추정을 진행할 계획이다.

 

 

3. E2E 테스트의 필요성

이 일화는 출시 직전에 있었던 일인데, 당시 조금이라도 더 나은 서비스를 전달하기 위해 끊임없이 수정 후 배포를 하고 있던 중이었다. 우리의 코드베이스에는 테스트 코드를 잘 작성하고 있어서, 대부분의 문제들은 배포 파이프라인에서 발견되어 프로덕션까지 문제가 전달되지 않았다. 그래서 어느 정도 안전하게 출시 전에 배포를 계속할 수 있었다.

 

그러나 이제 개발을 중단하고 출시를 하려던 순간, 내가 생각했던 사용자의 비즈니스 주요 경로가 제대로 작동하지 않는 것을 발견한 것이다. 완전히 초 비상인 순간이었다. 식은땀이 줄줄 흐르고 있었다.

공백의 30분..너무 많은 일이 있었다

롤백을 고려했지만, 다행히도 문제를 빠르게 진단하고 수정 후 배포할 수 있었다. 이로 인해 큰 문제는 발생하지 않았지만 너무나 식겁했던 일이었다.

 

어떻게 예방할 수 있을까?

왜 문제를 더 일찍 발견하지 못했을까? 테스트 코드는 잘 작성되어 있었지만, 대부분이 유닛 및 통합 테스트로 이루어져 있었기 때문이다. 따라서 실제 브라우저 환경에서 모든 모듈이 통합되어 사용자의 주요 비즈니스 경로가 정상적으로 작동하는지 검증하는 것은 불가능했다.

 

따라서, 개발자가 만든 모듈이 애플리케이션 수준에서 사용자가 사용할 때 제대로 작동하는지 확인할 수 있는 E2E 테스트를 배포 파이프라인에 추가할 필요성을 느꼈다. 마침 사이드 프로젝트에서 Cypress로 E2E 테스트를 작성한 경험이 있으므로, 이 경험을 활용하여 배포 파이프라인에 추가할 계획이다

 

또한, 위에 ‘하나의 공통 목표와 소통’ 개선사항을 고려하여 배포할 기능의 명세를 테스트 코드로 작성해 보면 어떨까? 이런 ATDD(인수 주도 개발)를 적용하면 개발팀의 안정성과 생산성을 향상할 수 있을 것 같다는 생각도 든다. 이 부분은 조금 더 검토한 후에 추진할 계획이다.

 

 

마무리하며

이번 글에서는 최근에 오랫동안 준비해 왔던 프로젝트를 출시하면서 느낀 점 3가지를 정리해 보았다. 특히 이번 프로젝트는 실제로 사용자로부터 돈을 받는 서비스이기 때문에 더 큰 부담감과 책임감을 느꼈고, 그만큼 사건과 사고가 많았던 것 같다. 그러나 그만큼 많은 것을 배울 수 있었다.

 

매번 사건이나 사고 없이 출시 및 배포를 원하지만, 항상 배포 전에는 마음이 편한 적이 없는 것 같다. 그러나 이번 경험을 통해 좀 더 발전하여, 다음 배포 시에는 더 잘할 수 있을 것이라 믿는다. 항상 못난 팀장이라 팀원들을 고생시키는 것 같아서 미안하다. 다음에는 더 잘해서 팀원들 고생 좀 덜 시키고 싶다.