사이드 프로젝트 QA하는 법
새로운 모지또의 QA 방식
이번에 새로운 모지또를 출시했다. 개발 기간은 1년을 넘겼는데 쉽지 않은 과정이었다. 처음부터 앱을 다시 만드는 것이라 작업량이 많았고 이제는 직장 일과 병행해야 됐기에 더더욱 어려웠다.
(우리가 아예 처음 모지또를 만들 땐 직장인이 아닌 사람도 있었다..!)
하지만 그럼에도 우린 결국 완주했다. 팀원 모두 돈 한 푼 받지 않은 상황에서 오직 열정만으로 새로운 모지또를 완성해냈다.
기본적으로 팀원 모두가 모지또를 아끼기에 가능했을 거라 생각한다. 하지만 그 아끼는 마음만으로 1년이라는 긴 시간을 버티기는 어려웠을 것이다.
우리의 열정이 1년 동안 식지 않을 수 있었던 것엔 이번에 새롭게 시도한 QA 방식이 한몫했을 거라고 본다.
사이드 프로젝트 QA하는 법
목차
기존 QA 방식
새로운 QA 방식
새로운 QA 방식의 장점
이전 글
명칭 정리
모지또 : 이번에 새로 만든 모지또
(구)모지또 : 처음에 만들었던 모지또
기존의 QA 방식
(구)모지또를 만들 땐 앱을 완전히 다 만든 후에 QA를 진행했다. 당시엔 우리 모두 경험이 충분하지 않았기에 그게 당연한 일인 줄 알았다.
근데 (구)모지또를 다 만들고 돌아봤을 때 그런 방식이 사이드 프로젝트에 적합한가 의문이 드는 점들이 있었다.
하나씩 살펴보도록 하자.
1. 식어가는 열정
열정을 동력으로 하는 사이드 프로젝트에게 QA는 생각 이상으로 중요하다. QA를 통해 열정을 불타오르게 할 연료를 얻을 수 있기 때문이다.
팀원들과 함께 그렸던 앱이 손 안에서 실제로 작동하는 것을 보며 보람을 느낀다. 아마 사이드 프로젝트를 하면서 느낄 수 있는 가장 주요한 보람 중 하나라 할 수 있을 것이다.
그리고 그렇게 보람이라는 연료가 다시 주입되면 열정의 불꽃이 다시 타오른다.
그러니까 사이드 프로젝트에 있어 QA는 본래 의미에 더해 한 가지 의미를 더 갖는다고 볼 수 있다.
최종 검수 공정(본래 의미)
열정 연료 주유소
근데 이런 관점에서 보면 앱을 다 만든 후 QA를 하는 방식에는 문제가 있다. 바로 주유소가 시작점에서 너무 멀리 떨어져 있다는 점이다.
만약 목적지가 너무 멀리 떨어져 있다면 완주하기가 어려울 수 있다.(ex. 앱을 완전 처음부터 만드는 경우) 출발점에 섰을 때의 열정만을 갖고 프로젝트를 쭉 진행하게 될 수도 있기 때문이다.
실제로 우리도 (구)모지또를 만들 때 막판에 다들 지쳐버린 적이 있다. 다행히 열정이 완전히 식기 전에 QA를 시작하여 불꽃이 다시 피어오를 수 있었지만 위기는 위기였다.
만약 우리가 충분히 동기부여 되지 않은 팀이었다면 (구)모지또를 출시할 수 있었을까라는 생각도 든다.
열정은 영구 기관이 아니기에 연료를 주입해줄 주유소를 필요로 한다.
2. QA 쓰나미
누군가는 사이드 프로젝트 정도면 QA 금방 하지 않나라고 생각할 수도 있다. 하지만 항상 그렇지만도 않다.
우선 태도의 관점에서 보자면, 당연한 거겠지만, 절대 사이드 프로젝트라고 QA를 설렁설렁하지 않는다. 일반 사용자들이 우리 서비스가 사이드 프로젝트의 결과물임을 감안하고 사용해줄 리 없기 때문이다.
그리고 무엇보다 우리가 만드는 다이어리 앱엔 사용자의 소중한 기록이 저장된다. 다시는 돌아오지 않을 순간을 남겨놓은 기록들은 사용자의 중요한 정신적 자산이다.
그렇기에 더욱더 책임감을 갖고 QA를 하게 될 수밖에 없다. 최악의 경우엔 사용자의 정신적 자산(기록)이 소실되는 버그가 발생할 수도 있기 때문이다.
(모지또를 운영할수록 더욱더 경각심을 느낀다!)
근데 이런 상황에서 QA를 한 번에 몰아서 하게 되면 부담이 크다. 특히 아예 처음부터 앱을 만드는 경우엔 모든 기능을 다 살펴야 하기 때문에 더더욱 그렇다.
(구)모지또를 만들 때에도 나름 열심히 QA를 했지만 아무래도 사람인지라 놓치는 게 나오기도 했다. 빨리 출시하고 싶은 생각에 마음이 급해진 부분도 있었던 것 같다.
(구)모지또를 만들 때 위와 같은 문제를 겪다보니 새로운 모지또를 만들 땐 다르게 접근해야겠다는 생각이 들었다. 그래서 팀원들과 논의를 하여 새로운 QA 방식을 도입하기로 했다.
새로운 QA 방식
팀원들과 고민하여 새롭게 모지또를 만들 땐 쪼개서 QA를 하자고 결론을 내렸다. 각각의 사용자 스토리에 포함된 기능들을 순차적으로 개발하고 QA하기로 했다.
예를 들어서 아래와 같은 식이다.
개발 및 QA 순서(예시)
1. 사용자는 감정을 입력하고 쉐-킷을 한다.
2. 사용자는 결과 화면에서 칵테일을 확인한다.
3. 사용자는 캘린더 탭에서 칵테일을 둘러본다.
4. 사용자는 칵테일 탭에서 칵테일을 둘러본다.
5. 사용자는 리포트 탭에서 통계를 확인한다.
...
1번 스토리에 포함된 기능들이 개발되면 QA를 할 수 있도록 선 배포를 해준다. 그러면 1번 스토리에 대해 기획 및 디자인 QA를 진행한다.
그리고 1번 스토리에 대해 기획 및 디자인 QA가 이뤄지는 동안 2번 스토리에 대한 개발이 이어진다. 한 마디로 개발과 QA가 동시다발적으로 진행되는 것이다.
다소 정신없어 보이는데 그렇기에 최초에 스토리 설계를 잘하는 것이 중요하다.
우선 쉽지는 않겠지만 스토리 간의 디펜던시(의존성)를 최소화해야 한다. 스토리 간에 디펜던시가 너무 많이 걸려있다면 QA를 제대로 진행할 수 없다.
개발 및 QA 순서를 잡을 때 다른 스토리들이 디펜던시를 가장 많이 걸고 있는 스토리를 앞에 두는 것도 방법이다. 그러면 뒤로 갈수록 QA 진행이 수월해진다.
그리고 가급적이면 QA를 오래 봐야 하는 핵심 스토리를 앞 순서에 두는 게 좋다. 그래야 더 오랫동안 살펴볼 수 있으니까.
근데 아무리 설계를 잘하더라도 개발에서 어느 정도 고생을 하는 방식이긴 하다. 신규 기능 개발과 QA 이슈 해소를 동시에 봐야 하니까. 이번에 우리 팀 박뱅과 오뜨 그리고 수군이 참 많은 고생을 했다.
하지만 그럼에도 새로운 QA 방식은 그런 아쉬운 점을 상쇄할 만큼의 장점을 갖고 있었다.
새로운 QA 방식의 장점
이번에 새로운 QA 방식으로 모지또를 만들며 기대 이상의 장점을 경험할 수 있었다. 하나씩 살펴보자.
1. 주유 빈도의 증가
새로운 QA 방식을 통해 우리가 그렸던 결과물이 손 위에서 작동하는 걸 더 빨리 볼 수 있게 되었다. 그리고 이 덕분에 더 빠르게 보람을 느끼는 게 가능해졌다.
그래서 QA를 시작한 순간부터 작업 속도가 빨라졌다. 스토리 별로 순차적으로 개발 및 QA 작업이 진행되며 앱이 완성되어갈수록 가속도가 붙었다.
2. 적어진 QA 부담
스토리 별로 순차적으로 나눠서 살펴보게 되었기에 QA 부담도 확실히 줄었다. 또한 각 기능들을 더 오랫동안 살펴볼 수 있어 버그도 더 많이 잡아냈다.
실제로 새로 낸 모지또에선 아직 버그 제보가 없는 상황이다. 이 점은 (구)모지또와 비교했을 때 분명히 눈에 띄는 개선이다.
3. 열정의 연비 향상
QA를 하는 동안에는 팀원 모두가 함께 일한다는 느낌이 더 강하게 든다.
실제로 QA를 위해 팀원들이 한 자리에 모이는 경우가 많기도 하다. 글로 소통하는 것보단 실시간으로 함께 화면을 보며 이야기하는 게 빠르기 때문이다.
그리고 그렇게 함께 일하면 우리가 한 팀이라는 유대감이 강해지고 그에 따라 열정의 연비도 좋아진다. 혼자보다 함께 걸었을 때 더 멀리 갈 수 있다는 말처럼 우리는 함께일 때 더 오래 작업할 수 있다.
무한도전 - 같이 걸을까새로운 모지또를 만들 땐 QA를 이르게 시작했기에 이런 유대감을 다지는 과정도 빨리 가질 수 있었다. (구)모지또를 만들 때와 비교해보면 우리 팀은 확실히 전보다 끈끈해졌고 덜 지치게 되었다.
4. 어긋남 초기 교정
앱은 기본적으로 상세 기획서를 기반으로 만들어진다. 근데 상세 기획서의 설명이 미흡하여 의도된 바와 다르게 개발이 될 때도 있다.
그런 어긋남이 처음엔 미미하게 보일 수 있지만 개발이 진행되면 진행될수록 얘기가 달라진다. 어긋난 부분이 점점 더 뒤틀리고 앱 완성 시점엔 해결하기 어려울 정도로 고착화된다.
다행히도 이번엔 QA 시점을 이르게 가져간 덕분에 위와 같은 문제를 최소화할 수 있었다. 기획 혹은 디자인 의도와 다르게 개발된 곳은 빠르게 찾아내 바로잡았다.
이런 초기 교정이 분명 개발 기한을 단축하고 완성도를 높이는 것에 큰 도움이 되었을 거라 생각한다.
5. 백문이불여일견
우리가 PPT나 피그마에 그려낸 설계가 실제 앱으로 구현되었을 때 느낌이 다를 수 있다. 어찌 됐든 우리 상상만으로 그린 거기도 하니까.
이렇게 실제 앱에서 보니 별로인 점들을 기획, 디자인 입장에선 너무나 수정하고 싶은데 개발이 거의 다 마무리된 상황에선 쉽지 않다.
개발적으로 가능하든 불가능하든 입 밖으로 얘기를 꺼내기도 어려운 게 사실이다. 이미 다 개발이 되었는데 수정하자고 하는 거니까.
근데 스토리 별로 나눠서 QA를 하니 그런 지점들을 더 빨리 찾아내서 개선하는 게 가능했다. 개발 중인 덩어리가 상대적으로 작다보니 부담을 좀 더 내려놓고 의견을 나눌 수 있었다.
새로 도입한 QA 방식은 이렇게 생각 이상으로 장점이 많았고.. 실제로 프로젝트를 진행하면서도 체감할 수 있었다.
이번엔 특히 우리가 앱을 아예 처음부터 만들다 보니 더 그랬던 것 같다. 출발지와 목적지 간의 거리가 너무 멀어서 중간에 들를 주유소가 필수적이었을 것이다.
근데 만약 출발지와 목적지 간의 거리가 가까운 프로젝트라면 위의 장점이 잘 안 살 수 있을 것 같기도 하다. 오히려 개발의 작업량이 늘어 비효율적일 수도 있겠다.
하지만 우리와 같이 아예 앱을 처음 만들어야 하는 사이드 프로젝트라고 한다면 충분히 도입해볼 만한 방법이라 생각한다.
맺으며.
사실 앱을 처음부터 다시 만든다는 게 쉬운 일이 아니었다. 더군다나 우리 모두 (구)모지또를 만들며 한 차례 고생을 해본 사람들이었다. 다들 앱을 처음부터 다시 만든다고 했을 때 눈앞에 고생 길이 훤했을 것이다.
하지만 과거의 경험을 기반으로 우린 새로운 방식을 고민을 했고 그 덕분에 더 즐겁게 새로운 모지또를 만들 수 있었다.
물론 이 과정에서 개발자인 박뱅, 오뜨, 수군이 참 고생을 많이 했다. 개발하랴, QA 이슈 처리하랴.. 정신없었을 것이다. 그래서 어찌 보면 개발 입장에선 더 많은 힘을 들였을 수도 있겠다는 생각이 든다.
그래도 결론적으로 보면 그 덕분에 우리가 완주할 수 있었을 것이다. 조금 돌아가는 길일 수는 있어도 우리는 완주할 수 있는 길을 택했다.
목적지까지 함께 운전해준 팀원들에게 다시 한번 감사하게 된다.
우리 팀 파이팅!
모지또 파이팅!
