😀 자신과 팀소개를 부탁드립니다.

안녕하세요. 대학생을 위한 단 하나의 캘린더, NETY 를 운영중인 Unipus 입니다.

저는 NETY 개발자 고려대학교 컴퓨터학과 19학번 김민규입니다.
2023년 하반기에 연고대실전창업학회 인사이더스에서 하진님을 만나 팀을 결성했습니다.

🤗 프로덕트 소개좀 해주세요~

2023년 8월에 런칭하여 10개월차 운영중입니다.

NETY 는 현재
- 누적 6만명의 사용자
- 1,700+ 개의 동아리
- 2024 4월 기준 MAU 1.8만명

을 기록하고 있습니다.

4월 12일 앱스토어 생산성 부분 17위 등극!

인생을 살면서 가장 고민이 많고, 새로운 것을 많이 접해야하는 시기가 대학생입니다.

대학생을 타겟으로 하는 정보는 너무나도 분산되어 있어서, 이를 찾는데 시간이 많이 걸리거나 아예 접하지 못하는 경우가 정말 많습니다.

ex.
"학사 일정" -> 학교 포털
"축제/이벤트 일정" -> 에브리타임, 링커리어, 이벤터스 ...
"동아리 일정" -> 카카오톡 투표
"내 일정" -> 구글 캘린더

NETY는 "대학생을 위한 단 하나의 캘린더" 를 목표로 삼고,

1. 대학생에게 필요한 일정 정보를 잘 모아서 보여주자
2. 대학생 개인의 일정과 동아리 일정을 잘 관리할 수 있도록 도와주자

위 2가지 가치를 제공하고 있습니다.

iOS: https://apps.apple.com/kr/app/id6451339766?l=en-GB
AOS: https://play.google.com/store/apps/details?id=com.unipus.nety
WEB (베타): https://nety.unipus.net

⁉ 프로덕트를 만들게 된 계기는 무엇인가요?

NETY 는 정말 많은 피봇을 거쳐 현재의 서비스가 되었습니다.

처음에는 "고질적인 동아리 운영진의 문제"를 해결하고자 시작했습니다.

모임을 관리해주는 솔루션은 정말 다양하나, 각 동아리 운영진의 니즈에 모두 부합하는 솔루션은 없었습니다.

저희가 1,700 개가 넘는 동아리를 만나면서 느꼈던 니즈의 예시는 다음과 같습니다.
1. 배드민턴 동아리는 가용한 코트가 한정되어 있기에, 선착순으로 동아리 일정에 참여할 수 있는 부원을 모집하고 싶어합니다.
2. 출결 관리가 엄격히 이뤄지는 학회는, 각 부원의 출석을 엑셀을 통한 수작업이 아닌 자동화된 방법으로 관리하고 싶어합니다.
3. 독서토론 동아리는 매주 같은 책을 택한 부원이 한 조를 이뤄 독서 모임을 합니다. 이때, 매 일정마다 여러 개의 단톡방을 만들어 관리하기가 어렵습니다.

이외에도 동아리별 파일 드라이브, 기수 관리 시스템, 동아리 공지 시스템 등 각 동아리 운영진의 니즈에 맞추어

NETY는 "동아리 운영에 특화된 공유 캘린더 관리 솔루션"을 제공하고 있습니다.

하지만, 수익화에 어려움을 겪었고 이후 다음과 같은 앱 내에 녹여보았습니다.

1. 소개팅 서비스
2. 번개 서비스
3. 동아리는 취향 공동체 -> 취향 기반 커뮤니티 서비스를 만들어보자!

각 서비스 모두가 "유지될 만큼의 지표" 는 발생하였지만, 저희 팀이 원하는 J-Curve 를 보여주지 못했습니다.
이때 성장세가 지지부진해서, 유저 수가 2만 명에서 3만 명 넘어가는 것이 정말 힘들었습니다.

그렇게 운영을 이어나가던 중,

1. "동아리 운영진의 문제" 중 가장 중요한 것은 "동아리 일정 관리" 이고
2. "동아리 일정" 은 대학생 일정의 일부분이다.

→ 그렇다면, 대학생의 분산된 일정을 우리가 한 곳에 모아보자!

라는 생각으로 가입만 하면

- 해당 학교의 학사일정
- 해당 학교내에서 열리는 이벤트 (교내 버스킹, 강연 등)
- 수도권에서 열리는 이벤트 (일일호프, 강연, 공연, 공모전 등)
- 개인 일정
- 동아리 일정

모두를 한 번에 볼 수 있는 캘린더로 서비스의 큰 축을 바꾸었습니다.

지금까지 시도한 것 중 가장 높은 전환률과 리텐션을 보여주고 있습니다.
*기존의 서비스들도 유지보수 중입니다.

4월 30일 앱스토어 생산성 부분 20위

😱 개발은 어떻게 진행이 됬나요?

저희 팀의 목표는 항상 "빠르게 개발하고, 유저 피드백을 듣는 것" 이었습니다.

1. 최대한 빠르게 개발하고
2. 지표와 유저의 피드백을 통해 서비스를 개선해나감과 동시에
3. 다른 기획을 계속 시도해보기

위의 3가지가 매우 중요했기 때문에

확장성 있는 아키텍처를 설계하고 개발하는 것이 중요했습니다.

하지만, 저희 팀은 "이 서비스다!" 하는 확신도 없었고, 가는 와중에 정말 많은 변화를 겪을 것이라고 생각했기 때문에,

팀의 사이즈에 비해 과도한 Clean Architecture 를 추구하지 않고, 추상화 Layer 를 적당히 두어서 어느정도의 유동성을 확보하였습니다.

각 개발 분야에서 좋았던 점 아쉬웠던 점 몇가지만 얘기해보겠습니다.

프론트엔드- Flutter

6월에 개발을 시작하여 8월 런칭을 목표로 잡았기 때문에, 빠른 개발이 정말 중요했습니다.

원래 웹 개발만 해보았었으나, 무조건 앱이 필요하다고 생각해 iOS, Android 두 플랫폼 출시를 목표로 하였고,
Native 로 개발 한다면 절대 2개월 안에 런칭할 수 없다고 생각해 Flutter 를 선택했습니다.

프론트엔드 개발에서 후회하는 것

1. code generation 을 너무 많이 썼다. (json_serializable, copywith, retrofit, isar)
: 처음에는 편하다고 생각했지만, 이후에 코드가 너무 많아져서 build 가 너무 길어져서 관리하기 힘들었습니다.

2. 앱 업그레이드를 어떻게 할 것인지 고려하지 않고 첫 출시를 진행했다.
: 앱 출시가 처음이다보니, 업그레이드까지 생각을 미처 하지 못하고 출시를 했었습니다.

초기 유저는 이미 많았는데, 에러도 처음에 정말 많아서.. 이후 유저분들에게 한 분 한 분 연락드리며 업데이트를 부탁하기도 했었습니다.

3. 처음부터 flutter_hooks 를 적용하지 않았다.

프론트엔드 개발에서 후회하지 않는 것

1. 바로 개발하기 보단, 많은 리서치를 하여 기존 개발자분들의 레버리지를 활용했다.
: 먼저, 기획을 프론트엔드 - 백엔드 - DB 의 가장 작은 단위까지로 쪼개었습니다.

이후 바로 개발하지 않고, 참고할 만한 best practice 가 있는지, 기획 사항에 대한 미리 구현된 library 가 있는지 조사하고 정말 많이 도움을 받았습니다.

2. 배포 자동화를 해두었다.

: 벌써 빌드가 100 회가 넘었습니다. fastlane 으로 미리 자동화 해두는 것을 정말 추천합니다.
https://deku.posstree.com/ko/flutter/fastlane/
(주요 라이브러리: riverpod, flutter_hooks, retrofit, dio, fcm, isar)

백엔드- Fast API(Python)

원래 다니던 회사에서 FastAPI 를 사용했어서 익숙했고, 사용 경험이 정말 좋았어서 깊게 공부해보고 싶은 마음이 있어 선택했습니다.

NETY 는 크게 5가지의 서비스로 나뉘어져 있습니다.

1. 일정 관리 서비스
2. 소개팅 서비스
3. 번개 서비스
4. 커뮤니티 서비스
5. 각 서비스에 부착된 채팅 서비스

메인 서비스 (1, 2, 3, 4), 채팅을 담당하는 서비스 (5) 2가지로 나눠 만들었습니다.

*처음엔 채팅 서비스를 FastAPI 하나로 구현했었으나 이후에 Go 기반 Centrifugo 및 Centrifugo front-end 로 FastAPI 를 사용해 채팅 서비스를 분리하였습니다.
https://centrifugal.dev/

채팅 서비스는 저희 주력 기능이 아니기 때문에, 제가 직접 구현하는 것 보다는 거인의 어깨 위에 올라타는 것이 중요하다고 생각했습니다.

이미 구현된 Scalable real-time messaging server 인 Centrifugo 를 저희 Cluster 에 올리고,

FastAPI 를 통해 Centrifugo 와 통신하는 방식으로 구현하였습니다.

백엔드 개발에서 후회하는 것

1. 확장이 어려운 Table 구조를 만들어 두었었다.
   

: 예를 들면,
- Account 테이블에 firebase token 을 하나만 저장해두었어서, 다중 기기 알람을 지원하려고 할 때 어려움을 겪었었습니다.
- Kakao Location 주소만 저장할 수 있게 만들어 두었어서, 이후 Naver Map 으로 장소 정보를 옮길 때 힘들었었습니다.

할 수 있는 만큼 테이블 분리를 해두는 것이 중요하다고 생각합니다.

2. 제일 중요한 기능을 소화하는 부분에 너무 특이한 라이브러리 (sqlmodel) 를 사용했다.

: sqlalchemy 가 python 의 대표 ORM (java Hibernate 유사) 입니다.

이를 Wrapping 하여 편의 기능을 추가한 것이 sqlmodel 인데, 결국 불편하게 sqlalchemy 를 사용하는 모양이 되어버렸습니다.

 → 중요한 라이브러리는 커뮤니티에서 공신력 있는 것을 사용해야 한다고 생각합니다.

백엔드 개발에서 후회하지 않는 것

1. ORM 을 적극 활용했다.

: 인턴하였던 예전 회사에서 raw sql 을 작성하며 서비스 로직을 완성시킨 적이 있는데, schema migration 할 때마다 정말 고역이었고 로직 적는 것도 한세월이었습니다.

2. dto based schema migration 을 적용하였다. (`alembic`)
: 서비스 자체의 변경, 새로운 서비스 추가하는 일이 정말 많았는데 큰 도움이 돼주었습니다.
(주요 라이브러리: FastAPI, sqlalchemy, alembic, asyncio)

DataBase, Infra

- 일정 로컬 저장을 위한 프론트엔드 데이터베이스 —> Isar
- 메인 서비스 정보 저장 → PostgreSQL
- cache, pub sub, rate limit → Redis
- 실시간 채팅 메시지 저장 → MongoDB
- Kubernetes → AWS EKS
- ArgoCD 를 설치하여 gitops 방식으로 배포하였습니다.
- 이미지 저장 → AWS S3
- Redis instance → AWS Elasticache
- PostgreSQL instance → AWS RDS
- MongoDB instance → MongoDB Atlas
- Docker 저장소 → DockerHub
- Error Logging → NewRelic

DB, Infra 후회하는 것

1. AWS 는 비싸다.
2. Full Managed MongoDB 인 Atlas 도 정말 비싸다.
3. IaaC (Terraform) 을 적용했다.

: Terraform 으로 AWS 인프라 구성하였을 때는 뿌듯하고 편리했습니다. 처음에 S3 에 terraform state 저장해서 막 이것저것 해볼 떄는 재밌었습니다.
하지만, 서비스가 추가되면서 Terraform 을 사용하는 것이 더 복잡해졌고, 결국 AWS Console 에서 직접 인프라를 구성하는 경우가 많아졌습니다.

즉, Terraform 자체에 대한 공부에 쏟는 시간이 너무 많았습니다.

 → 본질적인 문제 해결이 아닌, 툴에 대한 공부에 시간을 쏟는 것은 피해야 한다는 생각이 들었습니다.

소규모라면 더욱이, Console 에서 빠르게 구성하고 서비스에 집중하는 것이 낫다는 생각이 듭니다.

DB, Infra 후회하지 않는 것

1. VPC 를 잘 나누어, service node, Elasticcache, RDS 를 분리해두었다.
: 이런 구조를 갖고 시작할 때, bastion host tunneling 으로 RDS 에 접속하여 개발하는 것이 귀찮다고 생각했었지만, 지금 돌이켜보니 보안상 마음이 편해져서 좋습니다.
단, 이젠 돈이 많이 나와도 AWS 에서 벗어날 엄두가 나질 않습니다.

2. AWS Credit 을 많이 이용했다.
: 사업자 있으면 많이 지원해주십니다. 처음엔 인프런, 이후엔 메가존클라우드에서 지원을 받았었습니다. 꼭 이용해보세요.
https://www.inflearn.com/partners/aws

3. GitOps 를 적용했다.
: ArgoCD 를 사용하였습니다.
정말 편리하고, github 커밋수가 정말 많아 보이는 효과를 줍니다.

렛플에 시니어 개발자분들이 많은 것으로 알고있습니다. 이후에 저의 더 많은 개발 관련 생각들을 들고와 보겠습니다! 

개발자 선배님들의 많은 피드백 부탁드립니다.

👍 재미있었던 것은 무엇이었나요?

저는 혼자 카카오톡 채널에 응대하며 유저들의 피드백을 바로 반영합니다.
며칠이 지나고 기획, 기능, 디자인, 마케팅 을 개선해서 유저를 만족시키고,
그 기획이 또 다른 유저들을 끌어들여서, 서비스가 성장하는 것을 보는 것이 개발자로서 가장 행복한 일이었습니다.

저희 팀은 항상 "당장 실행할 수 있는 것" 을 미덕으로 생각했고, 단기적인 목표를 잡고 달려가는 것에 최적화 되어 있습니다.

단기적인 목표를 향해 돌진하면서 때로는 먼 숲을 보지 않아 헤맬 때도 있었습니다.
지금 돌이켜보면, 미션과 비전을 명확히 하고 달렸어야 더욱 효율적으로 목표를 향해 나아갔겠구나 하는 아쉬움도 남습니다.
하지만 스타트업이란 아쉬움의 집합이고, 아쉬움이라는 합집합의 크기를 줄이는 자들의 싸움이니까요.

결코 아쉽지 않은 한 가지 부분은,
저희 팀은 이 길에 들어와 후회없이 달렸다는 점입니다.
대세라고 보기는 어려운 B2C 서비스를 선택해 지금까지 저희가 달려온 길에 자부심과 뿌듯함을 느낍니다.

많은 변모를 거듭한 저희의 서비스 네티, 종착지는 누구도 모르지만,

적어도 대학생 분야에서는 모두가 알 수 있는, 삶의 질을 개선시킨 서비스가 되어 보겠습니다.

꾸준히 네티, 그리고 저희를 지켜봐주세요.

감사합니다.