2024 소프트웨어 마에스트로 회고

시작

4월부터 시작했던 소마는 6월까지는 팀빌딩과 기획으로 학교와 병행했다.
핏이 잘 맞는 팀원들을 만나 순조롭게 진행되는 것 같았다. 다만

 

 

본격적인 개발 시작 즈음, 팀원분의 조기 취업으로 프로젝트를 FE 팀원과 둘이서 진행하게 되었다...

 

기획, 개발, 운영까지 해야하는 상황에서 두명에서 진행하기엔 쉽지 않아 보였다. 다행이 다른 팀원분과 둘이서라도 으쌰으쌰 완성해보기로 했다.

기획

기획단계에서 주제를 잡는 것 부터 난항을 겪었다.

개발자만 모여서 기획을 진행하다보니, 사용자가 필요한 서비스를 만드는 것, 서비스를 만들면서 성장할 수 있는 주제를 선정하기 위해 고민했던 것 같다

 

 

아이디어 기획시 고려했던 사항

• 사용자가 가지고 있는 페인포인트가 무엇인가?
• 기존 서비스와 차별성을 갖는 어떤 기능으로 페인포인트를 해결할 것인가?
• 해당 문제를 기술적으로 해결 가능한가? (반드시 기술로만 해결 해야하는가?)
• 6개월이라는 시간 내에 시장에 검증이 가능한가?
• 서비스를 개발, 운영해가면서 성장할 포인트가 있는가?

그래프 뷰를 통한 의미 기반 논문 검색 및 추천 서비스

최근 연구와 제품 개발이 밀접한 연관을 맺으면서 R&D에 대한 수요가 많아지며 논문 출판 및 연구가 폭발적으로 증가했다.
전문적인 학술용어 및 배경지식이 없다면 논문에 대한 진입 장벽은 크게 작용한다.
이를 해결하는 키워드 없이 추상적인 설명만으로 탐색할 수 있는 논문 탐색 서비스

주제가 결정된 이후, 시장조사, 예상 사용자 인터뷰 등을 진행하면서 구체적인 기능들을 기획했다.

 

 

개발

AI

서비스를 개발하기 위해 선행지식이 너무 부족했다. 백엔드 및 서버 지식밖에 없던 나에게 모델 서빙 및 데이터 파이프라인은 생소한 내용들이었다.

 

또한 해당 모듈을 혼자 구현해도, 애자일 스프린트에서 FE 팀원과 소통하기 위해서는 해당 개념자체를 간단히라도 정리할 필요가 있었다.

본격적인 개발에 앞서, 간단한 코드와 함께 개념을 정리해서 전달하려고 했다. 추후 스크럼에서도 구체적인 코드보다 추상적인 이해를 우선시한 뒤 의사결정을 했던 것 같다.

• Vector Embedding
• KNN indexing vs ANN indexing
• Search Reranking
• OpenSearch (vector store)

Architecture

모델 서빙 및 데이터 파이프라인이 포함된 아키텍처를 구상하는데 어려움을 많이 겪었다. 멘토님들에게 도움과 AWS 기술 블로그에서 여러가지 레퍼런스를 찾아가며 AWS 기반 인프라 아키텍처를 구성했다.

https://www.amazonaws.cn/en/blog-selection/amazon-opensearch-services-vector-database-capabilities-explained/

 

사용할 AWS 서비스들이 많았고 이에 대한 세세한 변경사항들이 많을 것으로 예상되어 인프라 구성 초기부터
aws cdk를 적극 활용하여 각 인스턴스와 연결들 관리를 진행했다.

 

운영

실 서비스를 약 한달간 운영했다. 이 때, 스프린트 단위에 devops cycle을 적용했다

1. firebase event tracking으로부터 유저 데이터 수집
2. 수집한 유저 데이터를 통한 task planning 및 우선순위 설정
3. 빠른 기능 개발 및 배포 자동화
4. 배포 이후 sentry, cloudwatch를 통한 에러 및 장애 대응
5. 수집한 데이터를 통해 다음 스프린트 반복

Firebase Event tracking & GA

확인하고 싶었던 지표는 다음과 같다.

• 사용자가 얼마나 우리의 검색을 만족하는가?
• 메인 기능을 얼마나 활용하는가?
• 한번이라도 검색을 한 사용자가 얼마나 다시 서비스를 사용하는가?

때문에 디테일한 사용자의 활동을 추적할 필요가 있었다. 때문에 custom event를 정의하고 이를 측정했다.

 

해당 수집한 데이터를 통해서 GA에서 커스텀 레포트를 통해 검색에 대한 만족도를 측정했다.

측정한 데이터를 통해 배포한 기능에 대한 검증 및 정량적인 사용자 지표로 활용해 다른 스프린트 태스크를 결정했다.

CI/CD

FE, BE, Search 각 서버에 빠른 배포를 수행하기 위해 모든 배포를 자동화했다.

의사 결정

서비스를 런칭한지 한달만에 MAU 8K를 달성하며 서비스에 대한 검증을 진행했다.

 

이 기능을 만들면 사용자가 좋아하지 않을까? 라는 가설을 세우고 이를 검증하는 지표로 유저 트래킹 데이터를 활용했는데, 데이터 기반 의사결정을 한 이후에 확연히 다른 사용자의 반응을 확인 할 수 있었다.

 

다만 이러한 정량적인 지표는 아직 고정 사용자가 쌓이지 않고 무작위의 트래픽도 포함하기에 사용자 전체의 의도를 반영하기엔 어렵다고 생각한다.

 

 

때문에 정량적인 지표와 함께 정성적인 지표(실 사용자 인터뷰, 관련 서비스 제공자)와 함께 기능에 대한 검증을 진행했다.

 

사실 이외에 Google Ads, 채널 홍보 등 다양한 유저 획득 및 유지 방법에 대해 고민했지만, 회고에서는 임팩트 있던 활동만 돌아보았다.

 

개발 태스크 + 운영 + PO 의 역할을 모두 수행하다보니, 모든 내용을 깊게 하기엔 어려웠던 것 같다.

하지만 세웠던 가설을 검증해나는 과정에서 단순히 개발자의 포지션에서 벗어나 직접 의사결정을 하는 과정이 굉장히 흥미로웠다.