제목 그대로 무려 1명의 유저가 사용하는 서비스 개발을 마쳤다😐
성공했지만 실패했다.
작은 것을 만들고 큰 것을 얻었다.
LOL은 인생이다.
무슨 미친 소리인가 생각했다면?
정상이다.
하지만 읽고 나면 이해가 될 것이다!
꼭 전부 읽어주면 좋겠다.
1. LOL 밴픽 시뮬레이터 프로젝트의 시작💪
평화로운 오후.
LOL 프로팀 코치를 하고 있는 친구와의 대화 내용이다.
- 나 : 요즘엔 일하는 거 어떻냐?
- 친구 : "아 맞다 너 뭐 좀 만들 수 있냐? 일하는데 개 답답함🤦♂️🤦♂️🤦♂️"
- 나 : "으음..? ㅇ..예에?? 뭘요? 😲"
이어서 심도 있는 대화가 오고 갔고,
친구는 곧바로 업무지시를 하기 시작했다.
이렇게 정말 갑자기, 상당히 즉흥적으로
친구의 업무 환경 개선을 위한 프로젝트가 시작됐다!!
2. 고객의 불만사항 파악
코치는 선수들의 모든 경기를 모니터링하고, 분석하고, 전략을 짜야한다.
이를 위해 항상 필요한 정보는 양 팀의 밴픽 데이터이다.
친구는 (이하 고객이라 부르겠다😜)
양 팀의 밴픽 데이터를 자료화하는 방식과 구조가 불만이었다.
일단 해결을 위해 여러 불만 사항들과 그로 인한 문제점을 정리했다.
문제점 1. 대회 클라이언트와 일반 클라이언트의 UI 일관성이 없다❌
프로팀에서는 경기의 종류에 따라 사용되는 클라이언트가 다르다.
고객은 밴픽 데이터를 화면 캡처를 통해 정리하고 있었는데,
문제는 각 클라이언트가 관전자에게 제공하는 UI가 다르다는 것이었다.
캡처마다 화면구성이 달라 일관적이지 못했고
캡처물을 가지고 회의를 하거나 자료 통계를 낼 때 불편했다고 한다.
문제점 2. 캡쳐를 위해 항상 대기하고 있어야 한다❌
코치들은 관전자 권한으로 게임에 참여하게 된다.
LOL을 해본 사람은 알겠지만
밴픽 과정은 상황에 따라 길어질 수도 혹은 빠르게 끝날 수도 있다.
이론상 짧으면 6분 정도. 길면 12분까지도 소요된다.
양 팀의 밴픽이 끝나고 게임 시작 전까지 대략 30초~ 1분의 시간이 주어진다. ( 클라이언트, 게임 모드에 따라 상이하다. )
이 짧은 시간이 문제가 되었는데,
30초~ 1분이라는 주어진 시간 내에 화면 캡쳐를 하지 못하면 그대로 게임이 시작되어 버린다는 것이다.
상황에 따라 평균 10분 정도 자리를 지키고 있어야 했다.
선수들의 밴픽과정을 지켜보면서 코칭 할 때에는 겸사겸사 같이 해결하면 됐지만
그렇지 않은 때에도 자리를 지켜야 한다는 강제적인 상황은 당연히 스트레스일 것이다.
💩을 참은 적도 있다고 한ㄷ...
만약 혹시나 캡쳐 타임을 놓치고 나면...
우리 고객님은 엉엉 울며, 기존 캡처본에 짜깁기하여 직접 만들었다고 한다.
구글 검색을 통해 나오는 여러 밴픽 툴을 사용 해봤지만
모두 토너먼트 드래프트 모드 룰대로 시뮬레이션하는 방식이라 불편했고,
이 역시 UI가 달라, 불만사항 1에 해당하는 문제가 또 발생했다.
이에 포기하고 직접 만드는 걸 택했다고 한다.
시간이 배로 들었다.
문제점 3. 즉각적으로 변경되는 상황에 대응하기 어렵다❌
스크림은 팀 간의 연습 경기이기 때문에 실제 대회 경기와는 달리 룰에 있어서 비교적 자유롭다.
예를 들면, 스크림에서는
탑-정글-미드-원딜-서폿 포지션 순서를 맞추지 않고 게임을 시작할 때도 있고,
밴픽 진행 중 혹은 밴픽이 모두 끝난 후에도 양 팀 합의하에 리방을 해서
기존과 다른 밴픽으로 진행하는 경우도 있다고 한다.
또 스펠 같은 경우 빈번하게 변경되기 마련이다.
이런 즉각적으로 데이터가 변경되는 상황에서의 대응이 어려웠다고 한다.
예를 들면
1. 미처 캡쳐하지 못했는데 리방을 해버린다거나...
2. 이미 캡쳐했는데 스펠만 띵 하고 바뀐다거나...
3. 선수 한 명의 픽만 바꾸려고 리방 했을 때
암묵적으로 아무 챔피언으로 밴카드를 채워 빨리 진행시킨다거나...
3. 문제의 해결과 개발 시작!
모든 불만을 해결할 수 있는 방법은 아주 간단했다.
[시간제한 없고, 순서 상관없이 자유롭게 선택, 수정이 가능한 밴픽툴] 을 만드는 것.
항상 일관된 UI로 자료 저장이 가능할 것이고,
경기 전, 경기 중, 경기 후 언제든지 캡쳐가 가능하니 캡쳐를 위해 자리를 지킬 필요도 없을 것이고,
선택 수정이 항상 자유롭다면, 즉각적인 변화에도 대처가 가능할 것이다.
개발 시작 전 크게 2가지 정도만 생각했던 것 같다.
- 구현해야 할 기능들은 어떤 게 있지?
- 개발이 끝난 이후에 새로운 챔피언이 나오거나 하면 어떻게 하지 ??
(어떠한 준비 없이 개발을 시작한 것이 훗날 엄청난 재앙과 함께 깨달음을 주는 계기가 되었다🤯)
그리 많은 생각을 하지 않고 바로 CRA로 개발을 시작했는데,
대략적인 화면의 레이아웃을 만들고 생각했던 기능을 하나씩 붙여나가는 방식으로 개발했다.
우선 필수 기능을 우선적으로 구현했다. (밴, 픽, 스펠 선택 기능)
패치 버전 업데이트마다 코드를 직접 수정해야 하는 일을 만들지 않기 위해
라이엇이 제공하는 API를 사용했고, 이를 통해
서비스는 항상 최신 버전의 챔피언, 스펠 이미지를 사용할 수 있게 되었다.
이후 고객이 원하는 부가적인 기능들을 추가해 나갔다.
고객이 원하는 기능을 구현하고 난 뒤에는
더 편리하게 사용할 수 있도록 기능의 동작을 수정하는 식으로 발전시켰다.
ex) 검색 기능 사용 후 챔피언 선택을 확정하면, 검색 창이 자동 초기화 되도록 수정 -> 추가 검색이 편해졌다!
누군가 사용한다고 생각하니 사용자 경험을 계속 생각하게 됐다.
위의 과정을 계속 반복하면서 필요한 기능들이 모두 구현되었고,
한 달 정도의 개발 끝에 배포를 하게 되었다.
4. 프로젝트 성공!?
배포를 끝내자마자 바로 고객님께 사용을 요청했다. ( 뒤지게 설렜다... )
그리고 실제 사용을 마친 고객님께선 극찬을 아끼지 않으셨다👍
배포 후 고객이 실 사용하는 3주 정도의 시간 동안 추가 기능 요청이나, 불만사항이 없었고
어제 마지막 PR 후 개발을 마무리했다.
5. 서비스로 인해 개선된 업무효율
이 부분은 개인적으로 궁금해서 대화를 통해 단순 계산해 보았다.
- 관리하는 평균 경기 수
= 월 130경기 (1일 6경기 기준) - 밴픽 과정 평균 소요 시간
= 10분 - 여러 변수로 인해 직접 자료를 만드는 평균 횟수
= 월 65회 (1일 3경기 이상) - 직접 자료를 만들 때 평균 소요 시간
= 8분 - 서비스 사용시 평균 소요 시간
= 1분
절약된 시간
1번 X 2번 = 21시간 30분 ( 밴픽이 끝나길 기다리며 다른 업무 못하는 시간 )
3번 X 4번 = 8시간 40분 (직접 자료 만드는 시간)
합 = 월 평균 30시간 10분
기존보다 더 소요된 시간
1번 X 5번 = 월 평균 2시간 10분 (내 서비스로 자료 만드는 시간)
고객님은 월 평균 28시간을 아끼게 되었다.
물론 여러 조건들을 생각하지 않고 해본 단순 계산이지만
1달에 하루가 넘는 시간과, 스트레스까지 줄였으니 대 성공이다!
똥을 참지 않아도 되는 것까지 하면 이건... 그야말로..
6. 정말 성공일까...? ( feat. 시뮬레이션 없는 시뮬레이터🤷♂️)
고객은 상당히 만족했고 실제로도 엄청난 시간을 절약하며, 스트레스까지 줄였다.
자 여기까지만 본다면 이토록 성공적일 수가 없다.
하지만... 이 서비스에는 옥의 티가 있다.
바로 시뮬레이션 기능이 없는 시뮬레이터 프로젝트라는 것이다.
사실 처음 프로젝트를 시작할 때에는
'내 친구에게 필요한 기능을 만들어 주는 것' 이 목표였다.
그렇게 개발하던 중 '모든 사람들이 사용할 수 있는 롤 밴픽 시뮬레이터의 구현'으로 목표를 확장시켰었다.
친구에게 필요한 빠른 밴픽 모드와
일반적인 lol 유저들이 사용할 수 있는 토너먼트 드래프트 모드로 나누어 개발하려고 했고,
빠른 밴픽 모드의 개발이 끝난 후 1차 배포까지만 하더라도
각 모드의 기능은 비슷하니 금방 만들 수 있겠다 생각했었다.
내 처참한 코드를 되돌아보기 전까지만 해도 말이다.
6-1. 빠른 개발, 정말 나쁜 코드, 그리고 멸망
LCK 프로 팀들은 시즌이 시작되기 몇 주 전부터 본격적으로 스크림(연습경기) 도 많아지곤 하는데,
최대한의 효율을 위해 시즌 전까지 빠르게 개발하려고 노력했다.
그러다 어느 순간부터는 점점 코드가 더러워지고 구려지는 걸 느낄 수가 있었는데..
그때마다 남은 시간을 생각하며 코드보다 기능 구현에 초점을 맞추게 되었다..
한 달이라는 시간 동안 개발에만 몰두한 덕분에 나름대로 정해놓은 제작 기간 내에 완성할 수 있었고
친구에게 좋은 업무용 툴을 선물할 수 있었다.
급한 일은 끝냈으니, 충분한 시간을 통해 천천히 드래프트 모드를 구현하려 했는데 그럴 수 없었다.
생산성을 위한 컴포넌트 분리도 되어있지 않았고,
디렉터리 구조도 분리되어 있지 않았다.
.scss 파일 하나에 모든 스타일이 들어있었다.
이미 내 코드는 엉망이 되어있었다.
내가 싸지른 똥을 치우려
급하게 컴포넌트, 디렉터리, 스타일을 모두 나누고 정리했지만, 이미 늦었다.
분리하고 나니 15개 정도의 컴포넌트로 나뉘었는데,
전역에서 엄청난 개수의 props를 각 depth의 컴포넌트로 전부 전달해야 했다.
이미 하나의 파일에서 엄청난 수의 state와 함수로 동작하도록 구현했기 때문이다.
각 컴포넌트끼리의 결합도가 엄청나게 높아져서 어떻게 손을 댈 수가 없었다.
며칠간 코드를 정리하기 위해 노력했지만,
지금의 내 능력으로는 도저히 진전이 없었고 개발을 중단하기로 했다.
그렇게 토너먼트 드래프트 모드는 개발하지 못했고,
시뮬 없는 시뮬레이터 프로젝트가 완성되었다.
6-2. 초기 설계의 중요성
나는 초기 설계라는 개념 자체가 없었다.
프로젝트 초기 단계에서 해야 할 컴포넌트, 디렉터리 구조 설계 등을 하지 못했고 바로 개발을 시작했다.
흘러가는 대로 개발했고, 결국 프로젝트 미완성으로 이어졌다.
7. 프로젝트를 통해 얻은 것들
7-1. 개발 필수 규칙
1. 꼭 충분한 초기 설계를 하고 개발할 것.
2. 사용하는 기술의 본질을 이해하고 사용할 것.
3. 내가 적은 코드에 발목 잡히는 일이 없도록 노력할 것.
앞으로의 또 다른 개발에 있어서 내가 꼭 지켜야 할 규칙을 정할 수 있었다.
만약 조금이라도 생각하며 개발했다면, 지금쯤 드래프트 모드 개발이 끝나지 않았을까 싶다.
아쉽지만 내 업보라고 생각하면서 앞으로는 위의 철칙들을 꼭 지켜보려 한다.
7-2. 소통의 중요성
개발 과정중에 고객의 기습 기능 추가 요청이 있었다.
애초에 깊은 설계를 한 건 아니지만,
기존에 생각해놓은 틀에서 벗어난 요청이 들어오니 당황스러웠다.
하지만 고객은 처음부터 내가 고려할 줄 알았다고 한다.
서로 충분했다고 생각한 소통이
충분하지 않았다는 것으로 결론지었다.
앞으로 수없이 많은 개발을 할 테고, 수없이 많은 소통을 할 것이다.
대상은 이번처럼 고객이 될 수도 있고, 디자이너가 될 수도 있고, 개발자가 될 수도 있다.
조금 더 구체적으로 계획하고 소통해야
서로 띠용~? 하는 상황이 최대한 줄어들지 않을까 하는 생각을 했다.
7-3. 마무리
닥치는 대로 적다 보니,
며칠 머리통 깨지며 포스팅했던 실행 컨텍스트 포스트만큼 길어졌다.
실제로 유저가 사용할 서비스를 개발해 보는 것도,
요구하는 대로 개발하는 것도,
피드백을 주고받으며 서비스를 수정하는 것도,
그리고 그 프로젝트가 실제로 사용되는 것도
전부 처음이었다.
'내 개발 실력이 누군가에게 도움은 될 수 있는 정도구나'라는 기쁨도 있었지만,
'갈 길이 한참 남았구나'라는 좌절도 있었다.
그럼에도 멈추고 싶기보다는 더 빨리 가고 싶은 생각만 든다.
이번 프로젝트는
성공했지만, 실패했다.
작은 것을 만들고 큰 것을 얻었다.
LOL은 인생이다.
'프로젝트' 카테고리의 다른 글
| S-HOOK - 서비스 런칭 [Week 7 ~ 8] (2) | 2023.08.23 |
|---|---|
| S-HOOK - 좋은 서비스를 위한 길 [Week 5 ~ 6] (4) | 2023.08.05 |
| S-HOOK - 기초가 중요하다 [Week 3 ~ 4] (3) | 2023.07.24 |
| S-HOOK - 그토록 바라던 첫 팀 프로젝트의 시작 [Week1 ~ 2] (1) | 2023.07.13 |