평소에 '무엇을 만들고 싶다.'라는 생각은 많이 했다. 하지만 실제로 실행하고, 한 달 이상 개발을 해본 서비스는 Sprinters가 처음인 것 같다. 그만큼 재밌었고, 몰입하는 시간이 좋았다.
도입배경
코드잇에는 '스프린트 미션'이란 게 있다. 팀 프로젝트 기간을 제외한 시간에는 큰 틀에서 두 가지를 진행하게 되는데 하나는 강의 수강, 그리고 나머지 하나는 단계별 스프린트 미션 제출이다.
Sprinters는 스프린트 미션의 참여도를 높이기 위해 만들었다. 수강생들의 스프린트 미션 진행 단계와 순위를 노출시키고, 이를 통해 경쟁 심리를 일으켜 미션 참여도를 높이고 싶었다.
미션 진행 중에는 공부한 내용들을 기록할 수 있게 TIL(Today I Learned)까지 추가했다.
어느 정도 완성한 후, 수강생들에게 공유했지만 며칠이 지나도 실제로 사용하는 수강생은 없었다. 당시에는 그래도 몇 명은 사용할 줄 알았는데 내 예상과는 달랐다. 고민 끝에 내린 결론은, 확장이 필요하다 생각했다. 학습 플랫폼 성격에 맞는 가이드 문서나 강의 자료를 볼 수 있도록 만들었다.
수강생들이 자연스럽게 강의 자료를 보러 방문을 하고, 그 과정에서 다른 기능들도 한 번쯤은 둘러보는 것을 기대했다. 그래서 초기에는 강의 자료를 모아놓는 '라이브러리' 구현에 시간을 많이 투자했다.
다음으로, 익명 Q&A 페이지를 개발했다. 라이브 세션이나 강의가 끝난 이후에도 질문이 적은 게 혹시 '질문 자체가 부담스러워서 하지 않는 것은 아닐까?'라는 생각으로 만들었다. 익명으로 질문을 하여 심리적 부담을 낮추고, 보다 가볍게 질문하기를 바랐다.
이렇게 스프린트 미션, TIL, Q&A, 라이브러리까지 총 네 개의 섹션을 개발했다. 여기서 추가적인 섹션을 더 확장할 수도 있지만, 기존 섹션의 완성도를 높이고 기능을 고도화하는 것이 더 우선이라 판단했다.
실제 서비스 모습 갖추기
사실 Sprinters에 계정 삭제 기능을 최근에 추가했다. 그만큼 서비스 완성도가 충분히 갖춰지지 않은 상태였다. Sprinters에 한 번 발을 들이면 못 나왔었다.
개발 초기에 가장 신경 썼던 부분은 메타 태그와 썸네일, 파비콘, ...랜덤 프로필 이미지였다. 버셀 도메인 네임을 사용하고, 아무도 공유하지 않는 글에 대한 걱정을 하고 있었던 것이다. 단단히 착각을 하고 있었다.
안 그래도 싱글 스레드형 인간인데, AI로 이미지를 만드는 데 몇 시간씩 쏟고, 바꾸고, 또 바꿨다. 이미지 생성 하느라 새벽 늦게 자기도 했다. 그래도 결과는 현재까지 만족 중이다. 파비콘과 기본 프로필 이미지가 아주 마음에 든다.
기억은 잘 안 나지만, 비슷한 시기에 SSR 전환을 시도했던 것 같다. 기능을 확장하다 보니 SSR과 스트리밍 렌더링, 서버측 API 요청이 필요하게 되어, 마이그레이션을 했다. 여기서 약간의 후회가 있다면 Next.js로 마이그레이션 하지 않았다는 것.
React Router v7의 프레임워크 모드로 도전을 했다. Remix 프레임워크가 궁금하기도 했고, 이번 기회에 한 번 제대로 이해해보자는 생각으로 접근했다.
하지만 진행하면서 느낀 지점은 명확했다. 현재 시점에서는 RSC(React Server Components)를 활용할 수 없다는 점과, 기존에 Next.js에서 익숙해진 개념들을 그대로 적용하지 못하는 데서 오는 답답함이 컸다.
결국 단순히 새로운 걸 배운다는 기대감보다는 익숙한 패러다임과의 간극에서 오는 마찰을 더 크게 체감한 경험이었다. 특히, AI를 활용해 단기간에 기능들을 빠르게 추가하다 보니 더 그랬던 것 같다. 그래도 이미 시작한 만큼, 어느 시점에는 시간을 따로 확보해 공부해보려 한다.
어쨌든, 시행착오를 거치며 개발을 이어가고 있다. SSR과 스트리밍 구조를 적용해 초기 화면 렌더링 시간을 개선했고, 라이브러리 상세 페이지의 경우 번들 크기를 기존 대비 약 1/10 수준까지 줄이기도 했다.
사실 번들 크기를 줄였다고 말하기엔 다소 민망한 부분이 있다. 초기에는 로더에서 필요한 데이터만 선별해 반환한 것이 아니라 데이터를 통째로 내려보내고 있었고, 그로 인해 크기가 불필요하게 커졌던 것이었다.
해당 로직은 AI가 구현한 부분이었고, 그 과정에서 이를 인지하지 못한 채 그대로 넘어갔다. 배포 이후에야 문제를 발견하게 됐다. 이번 일을 통해, 주기적으로 코드를 직접 들여다보는 시간이 반드시 필요하다는 것을 느꼈다. 구현 속도와 구조에 대한 이해 사이의 간극이 커지는 순간, 결국 그 비용은 뒤늦게 돌아올 것이다.
다음으로, 기록(구 TIL) 섹션에 집중했다. 초기에는 기능이라곤 글 작성 -> 작성 완료 흐름이 끝이었다. 이후 직접 TIL을 작성해보면서 느낀 불편함과 개선이 필요한 지점을 기준으로, 필요한 기능들을 하나씩 보완해 나갔다.
수정 - 수정 기능이 없었다. 참 아이러니하다. 그보다 먼저 댓글 기능을 구현했다. 돌이켜보면 작성한 내용보다 사람들의 반응이 더 궁금했던 영향이 컸던 것 같다. TIL을 추가한 지 약 6일이 지난 뒤에야 수정 기능을 개발했다.
WYSIWYG 전환 - 글 작성과 편집 화면의 방식을 재구성했다. 보다 몰입도 높은 글쓰기 환경을 만드는 것이 목표였다. 이를 위해 참고한 서비스는 Medium이었다. 내가 알고 있는 글쓰기 플랫폼 중 가장 규모가 크고, 오랜 고민을 거쳐 설계된 인터페이스라고 생각했다. 에디터 도구에 Tiptap을 선택한 것은 적절한 판단이었다. 확장성과 커스터마이징 측면에서 유연했고, 필요한 기능을 점진적으로 추가해 나가기에도 구조가 잘 설계되어 있었다. 결과적으로 초기 단순한 글쓰기 흐름에서 시작해 점차 기능을 고도화하는 과정과도 잘 맞아떨어졌다고 생각한다.
코드 블록 고도화 - 코드 블록 사용성을 개선하고, 이 과정에서 Shiki를 도입했다. Shiki는 VS Code 수준의 정확한 토큰화를 얻을 수 있고, 결과물이 HTML 문자열이라 서버에서 통째로 처리해 클라이언트로 보낼 수 있다. 즉, 서버측 처리가 가능해서, 무거운 에셋이 클라이언트 번들에 포함될 일이 없다. 그리고 제공되는 테마들이 완성도가 높아서, 별도의 커스텀이 필요없다는 점도 좋았다.
이탈 방지 기능 - 글 작성 중에 실수로 탭을 닫거나, 새로고침을 한 경험들 한 번씩은 있지 않을까? 이로 인해 글의 내용이 모두 사라지면 진짜 글 쓰기 싫어진다. 그래서 만들었다.
이미지 업로드 - 글만으로 충분할 때도 있지만, 이미지 첨부가 필요할 때가 있다. 다만, 이미지 업로드는 예상보다 단순한 작업이 아니었다. 이미지 업로드 시점, 이미지 클린업 작업 등 여러 시나리오에 대한 고민이 필요했다.
임시저장 - 이탈 방지 기능과 함께 우선순위가 높았던 기능 중에 하나였다. 글쓰기의 장점 중 하나는 어느 순간이든 다시 글을 이어 쓸 수 있다는 것이다. 흐름이 끊기더라도 언제든 다시 이어갈 수 있다. 그런 점에서, 임시저장 기능은 필수라고 생각했다. 임시저장도 우여곡절이 많았다. 어느 동작이 더 자연스럽고 복잡하지 않게 사용할 수 있을까를 많이 고민했다. 이것도 기회가 되면 글로 더 자세히 풀어보고 싶다.
TIL -> 기록으로 도메인 변경 - 기능을 개선해 나가면서, 'TIL'이라는 이름이 글쓰기 형태에 제약을 두는 것 같았다. 더 다양한 형태의 글쓰기를 담아낼 수 있는 구조가 필요하단 생각이 들어서 TIL을 '기록'으로 확장했다. Sprinters라는 서비스 방향성과도 결이 맞는 이름으로 잘 지었다고 생각한다. 관련 로직들의 변수와 함수 네이밍, 그리고 DB 쪽도 수정을 해야했지만 AI 덕분에 비교적 수월하게 작업을 할 수 있었다.
여기까지가 기록 섹션의 개선 사항들이다. 기록 섹션을 더 개선하고 싶었지만, 마음 한편에는 계정 삭제 기능이 너무나 필요할 것 같았다. 아니, 필요하다. 그래서 프로필/설정 페이지와 함께 계정 삭제 기능도 개발했다.
중간점검 마무리
한 번쯤은 이렇게 정리하는 시간을 가져보고 싶었다. 아직 추가하고 싶은 것들이 산더미지만, 쓰고싶은 글도 산더미다. 지금은 구현을 잠시 멈추고, 공부하는 시간이 필요할 것 같다.
거의 두 달 동안 치열하게 고민하고, 신나게 만들었다. 무언가를 만들 때는, 가볍게 시작하는 것이 나에게 맞는 방식인 것 같다. 가볍게 시작하고, 살을 붙여나가는 과정이 재밌다.
그리고 AI를 활용하면서, 다양한 시도를 훨씬 빠르게 검증할 수 있었다. 프롬프트만으로 코드를 생성하거나 제거할 수 있다 보니, 변경에 대한 부담이 크게 줄었다. 덕분에 구조를 고민하거나 실험적인 접근을 해보는 데에도 심리적 장벽이 낮아졌다.
어쩌면 구현 과정에서 불필요한 것에 에너지를 쓰지 않고, 집중하고 싶은 지점에만 몰입할 수 있었기 때문에 더 재미있게 느껴졌던 것일지도 모르겠다.