후배를 위해 만든 서비스에 Qiita 사용자가 유입된 이야기

현재 개발 중이지만, 실제로 이곳에서 이용할 수 있습니다!!

지난번, 사내 Java 연수 커리큘럼에서 느낀 위화감으로부터,

초보자용 Java 학습 사이트를 만들기 시작했다는 기사를 공개했습니다.

솔직히 처음에는 가벼운 기사 소재 정도라는 감각으로,

「뭐, 몇 명에게 보여지고 끝이겠지」

정도로 생각하고 있었습니다.

하지만 공개 후,

Trace Room의 동작 확인을 위해 Firebase Authentication을 확인한 결과, 사내 후배 외에도 6명의 신규 사용자가 로그인해 주셨습니다.

이것은 개인적으로 상당히 충격적이었습니다.

지금까지,

• 기사를 쓰다
• 개발하다
• 공개하다

라는 것은 어느 쪽인가 하면 별개의 것으로 생각하고 있었습니다.

하지만 이번에,

Qiita 기사
↓
서비스로 액세스
...

라는 흐름이 실제로 발생했습니다.

게다가 저와 직접적인 관계가 없는 분들입니다.

이것은 상당히 큰 경험이었습니다.

이번에 Trace Room의 개선을 위해 Firebase Authentication을 확인하고 있었는데,

「어라, 사용자가 늘었네」

가 되었습니다.

이 순간,

「기사는 정말로 서비스 유입으로 이어지는구나」

를 실감했습니다.

지금까지는,

• PV
• LGTM
• 팔로워

와 같은 숫자만을 의식하고 있었습니다.

하지만 실제로 중요한 것은,

“사람이 행동했는가”

라는 것을 느꼈습니다.

현재의 구성은 상당히 심플합니다.

• React
• Firebase Authentication
• Firestore
• GitHub Pages

를 사용하고 있습니다.

Firebase를 사용함으로써,

• 로그인 관리
• Room Chat
• 실시간 동기화 (Real-time synchronization)
• Trace Room

등을 상당히 빠르게 테스트할 수 있습니다.

개인 개발이라면,

「우선 동작시킨다」

까지의 속도는 상당히 중요하다고 느끼고 있습니다.

현재 Trace Room에서는 전체 채팅을 도입하고 있습니다.

Firebase Firestore의 onSnapshot을 사용하여,

게시
↓
실시간 반영

을 수행하고 있습니다.

이 「지금 누군가가 만지고 있다」는 것이 보이는 감각, 상당히 재미있습니다.

• 전체 채팅 형식
• 실시간 동기화 (Real-time synchronization)
• 아이콘 표시
• 사용자 이름 표시
• 자동 스크롤
• 자신의 게시물만 삭제 가능
• Tracea (고정 AI 멘토)

등.

특히,

「자신의 게시물만 삭제할 수 있다」

는 최소한 필요하다고 느꼈습니다.

실시간 계열은,

「만드는 것」

보다,

「어떻게 운용할 것인가」

가 더 어렵습니다.

이번에 상당히 느낀 점이 이것입니다.

초보자용 서비스는,

문제를 늘리면 된다

는 것이 아닙니다.

실제로는,

「어디에서 멈추는가」

의 설계가 상당히 중요합니다.

예를 들어,

sum += i;

를 보고,

「+=가 뭐야?」

에서 멈춥니다.

하지만 많은 학습 사이트는,

「알고 있다는 전제」

로 진행합니다.

그래서 지금은,

• 전제 지식의 가시화
• 실행 트레이스 (Execution trace) 재생
• Tracea의 보충
• Room Chat

등을 조합하여,

「별도의 탭을 여러 개 열지 않아도 이해할 수 있는」

방향을 목표로 하고 있습니다.

이번 개발에서는 AI도 상당히 활용하고 있습니다.

AI는 틀림없이 강력합니다.

• UI 제안
• 컴포넌트 분리 (Component separation)
• Firestore 구성
• 상태 관리 (State management)

등, 생산성은 상당히 올라갑니다.

하지만 최근 상당히 느끼는 점은,

「생성된 코드를 붙여넣기만 하는 것」

으로는 자신의 기술력이 쌓이지 않는다는 것입니다.

예를 들어,

• 왜 이 구성인가
• 왜 onSnapshot을 사용하는가
• 왜 이 설계로 했는가
• Firestore 규칙은 안전한가

를 설명하지 못하면, 결국 나중에 막히게 됩니다.

그래서 최근에는 AI가 생성하게 한 뒤에,

• 이 설계의 트레이드오프 (Trade-off)는?
• 다른 접근 방식은?
• 이 구현의 위험 포인트는?

를 묻도록 하고 있습니다.

이번에 상당히 느낀 점은,

「완성하고 나서 공개한다」

보다,

“만들면서 발신한다”

는 쪽이 강하다는 것입니다.

특히 개인 개발이란,

• 만든다
• 발신한다
• 개선한다
• 사용자를 본다

를 고속으로 돌리는 게임이구나라고 느끼고 있습니다.

솔직히, 이 서비스 자체가 향후 어떻게 될지는 아직 모릅니다.

하지만,

「발신 → 유입 → 개선」

이라는 흐름을, 소규모일지라도 실제로 체험할 수 있었던 것은 상당히 큰 수확입니다.

이는 향후 다른 서비스를 만들 때에도 확실히 도움이 될 경험이라고 생각합니다.

아직 개발 도중이지만,

계속해서 개선해 나가겠습니다.