우테코/피드줍줍 운영 기록기

 
피드줍줍 서비스를 실운영하면서 발생한 일을 기록하려고 합니다. 피드줍줍의 현재 상황,

앞으로의 방향성에 대해서 이야기를 해보려고 합니다.

---

피드줍줍의 현재 상황

 

MVP 개발이 끝난 피드줍줍을 활성화시키기 위해서 많은 노력을 했습니다.
 

그중 가장 먼저 한 일은 캠퍼스에 대해 불편함/피드백을 작성할 수 있는 QR 코드 붙이기였습니다.

 
피드줍줍 서비스를 사용자들에게 처음으로 알린 작업이었는데요, 감사하게도 많은 우테코 크루분들이 캠퍼스에서 불편했던 점, 개선점을 올려주셨습니다.
 
하지만 문제점이 있었는데요, 저희 팀 내부에서 해결할 수 없는 피드백들이 다수 존재했습니다. 

 
 
해당 피드백을 해결하기 위해서는 코치님들의 도움이 필요하다고 생각했고, 담당 코치님들께 해당 피드백에 대해 관심이 있으시다면 관리자 역할을 부탁드렸습니다.
 
긍정적인 답변을 기대했었지만, 저희가 생각치 못한 부분이 있었습니다.
 
코치님으로부터 받은 피드백은, “피드백은 받을 준비가 되어있는 사람이 받아야한다. 본인이 원하지 않았는데 피드백을 준다면 이는 좋은 경험이 아닐 수도 있다.”였습니다. 전혀 생각지 못한 부분이었지만, 금방 납득할 수 있었습니다. 
 
우테코 캠퍼스에서의 피드백들은 관리자가 적절한 답변을 달아줄 수 없는 상황이라고 판단해 다양한 타깃층을 추가로 찾아보았습니다. 이후에 저희가 새롭게 정의한 타깃층은 피드백이 필요한 '사람들'입니다.
 
여기서 중요한 것은 관리자 -> 사람들로 도메인 개념이 변경되었는데요, 피드줍줍을 사용하는 관리자를 장소를 관리하는 관리자로 한정짓지 않고,  조직 혹은 특정 상황에서 피드백이 필요한 사람들로 구체화를 시켰습니다. 예를 들자면, 세미나 혹은 강연 후 Q&A를 진행하는 사람들이 있습니다. 이를 위해 한 명의 admin이 여러 조직을 가질 수 있도록 추가 기능을 구현하기도 했습니다.
 
코치님들의 피드백을 토대로 타깃층을 구체화시키니, 프로젝트의 방향성이 보다 뚜렷해지지 않았나 싶습니다. 이 시기는 데모데이가 얼마 남지 않은 시기였는데요, 새로 수립한 타겟층이 적절한지 알아보기 위해 우테코 데모데이에서 피드줍줍을 홍보해 봤습니다.

---

우테코 데모데이

 
 데모데이 때 참여 팀들의 피드백을 피드줍줍으로 받으면 좋겠다는 생각이 들었고, QR코드를 만들어 각각의 팀들에게 나눠주었습니다. 각 팀들은 저희가 수립한 타겟층이기도 했고요. 감사하게도 대부분의 팀들이 피드줍줍을 통한 피드백받기에 대해 긍정적이었습니다.
 
이 활동을 통해서 조직의 관리자 플로우에 대해 여러 팀들에게 피드백을 받을 수 있었고, 사용자 플로우에 대해서도 개선사항을 많이 받을 수 있었습니다.

나가아 저희는 추가 타겟층을 모색하고 있었는데요, 우테코 강의 시간에 비교적 가벼운 건의사항은 피드줍줍을 이용할 수 있겠다는 생각이 들었고, 백엔드 코치님들께 피드줍줍 사용을 건의해 보았습니다.

코치님들께서 긍정적인 반응을 보여주셨고, 이후에 백엔드 수업 때 지속적으로 피드줍줍을 사용하고 있습니다. 

 

구구 & 네오의 수업

 

이 과정에서 지속적인 유저들을 확보했고, 실사용을 하면서 다양한 버그들을 마주할 수 있었습니다

---

실사용을 하면서 발견한 버그

 

내부적으로 QA를 진행하고 버그가 없었다고 생각하고 있었지만, 부자연스러운 흐름에서의 다양한 버그들이 존재했습니다. 기존에는 찾지 못했던 버그들이었지만, 수업 때 백엔드 크루들이 사용하면서 다양한 버그들을 찾을 수 있었습니다.

구체적으로는 다음과 같은 버그들이 존재했습니다.
- 좋아요 무한 요청
- 좋아요 무한 취소
- 웹 페이지를 거치지 않고 직접적인 api 요청을 통해 비정상적인 응원하기 값 설정

 

정상적인 flow에서는 일어나지 않는 일들이지만, 악의적으로 api를 요청하면 일어나는 버그들이었습니다. 이 부분은 프로젝트에 꽤나 치명적인 오류들이기에, 최대한 빨리 문제를 해결했습니다. 하지만 피드백을 남기는 과정은 비로그인이기 때문에 명확한 한계점 또한 존재했습니다. ex) 쿠키를 지우면 좋아요를 다시 누를 수 있다던지

 

이에 대해서는 추가적으로 많은 고민을 해볼 것 같습니다. 좋아요 값의 신뢰성을 유지하기 위해 로그인을 도입한다던지, 아니면 이번에 수정한 쿠키를 사용해 상황을 추적해 본다던지 등등...

 

 

추가적인 문제점

데이터가 쌓여서일까, 애플리케이션이 느려졌다는 피드백을 받았습니다. 특정 API에서 성능 저하가 일어나 사용자가 불편함을 겪는 상황이 발생했습니다. 데이터가 지속적으로 쌓이면 언젠간 발생할 문제였지만, 이렇게 빨리 발생할 줄은 몰랐습니다. 이 문제를 해결하기 위해서, 모든 API에 대해 성능 테스트를 진행하고, 병목지점을 찾아 TPS를 개선해보려고 합니다. 

---

앞으로 피드줍줍의 방향성

 

한 달 뒤면 우아한 테크코스 8기의 프리코스를 시작합니다. 저희 팀은 8기 프리코스 때, 선배 기수들에게 간단한 Q&A (선배들에게 물어보세요)를 진행하려고 합니다. 작년도 프리코스 기준으로 백엔드 약 1,600명 , 프론트 약 500명이 지원한 것으로 알고 있습니다.
 
선배들과의 Q&A를 진행하려면 넉넉하게 2,500 ~ 3,000 명 정도가 원활하게 사용할 수 있는 아키텍처를 만들어야 합니다. 지금 상황에서도 서비스가 느리다는 피드백을 받았으니, 성능 개선을 하고 가용성과 안정성을 추가로 챙겨야 할 것 같습니다. 이 과정에서 기술적으로 많은 것을 배울 수 있을 것 같아요. 물론 이 과정에서 오버엔지니어링이 되지 않도록 조심해야 할 것 같습니다.

---

마지막으로

 

큰 수치는 아니지만, MAU 227명을 달성했습니다. 이 과정에서 개발적인 부분뿐만 아니라, product를 어떻게 성장시킬 수 있을까? 에 대한 고민을 많이 했던 것 같습니다.

이전에 참여한 정부지원사업 얼루가 프로젝트에서는 적극적으로 기획/마케팅에 참여를 하지 않아 잘 몰랐었는데, 개발자도 적극적으로 product를 어떻게 성장시킬지 고민하는 게 굉장히 중요하다고 느꼈습니다. 빠르게 AI가 발전하고 있는 가운데, 개발자는 단순히 개발만 하는게 아니라, 전반적인 상품(서비스)을 관리할 수 있는 자질이 있어야겠다는 생각 또한 드네요.

긴 글 읽어주셔서 감사합니다.