나는 지난 8월부터 지금까지 6개월 동안 웹 메모라는 서비스를 개발 중이다. 그 중간에 우테코 프리코스를 준비하고 진행하는 기간이 있었어서 이를 제외하면 실질적인 개발 기간은 약 4개월 정도 된다. 지난 4개월 동안 서비스에는 참 많은 변화들이 있었고 서비스는 발전해왔다. 웹 메모라는 서비스는 지난 4개월 동안 어떻게 변화해왔고, 꾸준히 발전시키기 위해서 어떤 노력을 해왔는지 이야기해보고자 한다.
프로젝트를 시작하게 된 계기
프로젝트를 시작하기로 결심한 날은 지난 8월 7일로 거슬러 올라간다. 나는 기존에 Untitled 라는 노션 페이지에 평소 읽은 아티클과 영상을 기록하고 있었다. 기록을 한 이유는 기록을 하며 내 머릿 속에서 한 번 더 정리를 하고, 훗날 다시 찾아보며 복습하기 위함이었다. 그런데 아티클을 읽을 때면 매 번 노션에 제목, url을 적고 분할한 양쪽 화면을 오가며 요약을 작성해야했다. 매 번 아티클을 읽을 때마다 실천하기에는 어지간히 번거로운 작업이었다. 아티클 읽은 것을 기록하는데까지 너무 많은 선행 작업이 필요한 것이다. 이러한 번거로움 때문에 아티클 읽기를 포기한 적도 여럿 있었다.
이런 불편함을 몸소 느꼈고 이를 내가 직접 해결해보면 어떨까?하는 생각에서 웹 메모라는 서비스를 만들게 되었다. 이번 섹션에서는 이 웹 메모라는 서비스를 어떻게 지속적으로 발전시켜왔는지 살펴.보고자 한다. 처음 서비스를 출시했을 때부터 현재까지의 발전 과정을 버전별로 살펴보며, 각 단계에서 어떤 변화가 있었는지 알아보자.
v0.0.1부터 v1.8.4까지 발전시키며
v0.0.1 : 첫 서비스의 출시
가장 초기 버전에서는 요약 기능만 담은 서비스를 출시했다. 긴 아티클을 읽을 때 핵심을 빠르게 파악해 핵심 위주로 내용을 읽기 위함이었다. 위와 같이 내용 요약이라는 핵심 기능만을 갖춘 상태로 v0.0.1의 서비스를 시장에 처음으로 선보였다. 그 날은 서비스를 개발한지 20일 째인 8월 27일이었다.
v0.1.0 : Daisy UI를 이용한 디자인의 통일성
v0.0.1에서는 요약 내용이 웹페이지를 가린다는 치명적인 단점이 있었다. 그래서 이를 개선하고자 확장 프로그램의 side panel 기능을 활용했다. 이제는 웹페이지의 화면을 가리지 않고 우측 사이드패널에서 요약 내용을 확인할 수 있게 되었다. 또한 DaisyUI라는 TailwindCSS 기반 컴포넌트 라이브러리를 사용해서 디자인의 통일성을 갖추었다.
v0.2.0 : 메모 기능 추가
뭔가 2% 부족했다. 아니 20% 부족했다. 요약만으로 서비스라 하기에는 너무나도 부족한 거다. 그래서 내가 평소에 하고 있던 고민과 이 서비스를 결합하면 어떨까 생각을 했다. 그 결과 요약을 저장할 수 있는 기능과 메모를 할 수 있는 기능을 추가했다.
그리고 이제 서비스의 핵심 기능을 요약에서 메모로 변경함에 따라 서비스명도 Page Summary에서 Page Memos로 변경했다.
v1.0.0 : 기존 Chrome Storage에서 Supabase Database로 마이그레이션
기존에는 Chrome Storage에 사용자 데이터를 저장하는 방식이었다. 이 방식은 사용자가 확장 프로그램을 제거하면 데이터가 날아간다는 것과, 최대 용량이 많지 않다는 점, 확장 프로그램 안에서만 데이터를 확인할 수 있다는 단점이 존재했다. 그래서 이를 Supabase Database로 마이그레이션해야겠다고 결심했다. 이를 위해 OAuth와 Supabase Auth, Supabase Database를 활용했다.
자세한 내용은 Supabase 데이터베이스로 사용자별 데이터 관리하기 참고 바란다.
v1.1.0 : 웹사이트로 확장
기존에는 메모를 확장 프로그램의 New Tab에서 확인을 해야했다. 확장 프로그램에 배포하기 위해서는 매 번 심사를 거쳐야해서 빠르게 사용자에게 새로운 기능을 추가하거나, 버그를 수정해 제공하기가 어렵다는 한계가 있었다. 그래서 웹사이트로 확장하기로 결심했다.
v1.2.0 : Daisy UI에서 ShadcnUI로 마이그레이션
DaisyUI는 커스텀에 한계가 있다는 단점이 있었다. 특히 웹사이트로 확장한 이후 스타일을 수정하거나 추가하는 것이 어려웠다. 또한 디자인 시스템을 새로 구축하기 위해서는 더 많은 커스터마이징이 가능한 UI 라이브러리가 필요했다. 그래서 Shadcn UI로 마이그레이션을 진행했고 이를 통해 더 세밀한 디자인 조정이 가능해졌다.
v1.3.0 ~ v1.8.0
위시리스트, 캘린더 뷰, 메모 관리, 유튜브 영상 요약, 메모 저장 이슈 해결 등 많은 업데이트들이 있었다.
v.1.8.4
마침내 아래와 같은 모습을 갖춘 서비스가 되었다.
현재는 웹사이트와 로그인 정보를 연동해 확장 프로그램에서 저장한 메모를 웹사이트에서 확인 및 관리할 수 있는 형태가 되었다. 더 자세한 업데이트 내용은 webmemo.site/update에서 확인할 수 있다.
프로젝트가 지금까지 지속적으로 성장해올 수 있었던 핵심은 '빠른 배포'였다고 생각한다. 처음부터 '요약 어떻게 하지..', '요약 기능만 가진 서비스를 출시해도 될까..'하는 고민을 했으면 지금까지 꾸준히 발전할 수 없었을 것이다. 일단 개발하고, 일단 배포하고, 그리고 일단 출시를 해서 지켜보았다. 그리고 사용자가 조금씩 유입이 되었다.
비록 많은 사용자는 아니지만 사용자가 이 서비스를 사용하고 있다는 사실 하나만으로도 나에게는 큰 동기가 되었다. 사용자들이 내가 만든 서비스의 버튼을 하나하나 누르고, 인풋에 키보드를 타이핑한다는 사실이 나에게는 너무나도 큰 떨림이자 설렘으로 다가왔다. 사용자가 이 서비스를 사용하며 불편함을 해소할 생각에 뿌듯하기도 하고, 한편으로는 '인풋에 입력하다가 데이터가 저장 안 되면 어떡하지?', '저장이 안돼서 사용자가 이탈하면 어떡하지?'하는 마음에 걱정이 들기도 했다.
이러한 뿌듯함과 걱정은 곧 프로젝트를 지속할 수 있는 원동력이 되었다. 사용자들이 서비스를 이탈하지 않았으면 좋겠고 더 많은 사용자가 입소문을 타서 유입이 되었으면 하는 욕심이 생겼다. 그런 마음에 서비스를 계속해서 개선하고, 오류를 고치고, 배포하고 하는 과정을 지속해올 수 있었다.
정리하면 빠른 배포를 통해 사용자에게 서비스를 제공하고 일찍이 사용자(나를 포함)가 유입되며 사용자를 실망시키고 싶지 않은 책임감이 생겼고, 이러한 감정들이 프로젝트를 지속적으로 성장시키기 위한 원동력이 되었다.
프로젝트의 지속적인 성장을 위한 것
1) 안정적인 배포 : CD
서비스는 빠르게 개발하고 배포되는 것이 중요하다. 우리가 만든 새로운 기능, 혹은 수정한 버그가 빠르게 배포되어 사용자에게 전달이 신속하게 될수록 우리는 사용자와 더 가깝다고 느끼게 된다. 조금 전에 배포 버튼을 눌렀는데 지금 당장 사용자에게 가치가 전달이 되고, 나 또한 테스트를 해볼 수 있다면 사용자와 개발자 간의 거리가 한층 더 가까워진다고 할 수 있다.
빠르게 배포하면 사용자한테도 그만큼 빨리 좋아진 게 간다. 실시간으로 피드백을 받고 대응할 수 있다는 것은 서비스의 지속적인 발전을 위한 핵심 요소다. 나도 내가 고친 걸 바로 확인할 수 있어 좋다.
빠르게 배포하기 위해서는 자동화된 배포 시스템을 구축해야 한다. 이를 우리는 CD(Continuous Delivery)라고 한다. 자동화된 배포 시스템이 있다면 우리는 코드를 작성하고 테스트하는 데만 집중할 수 있으며, 배포 과정에서 발생할 수 있는 실수도 줄일 수 있다. CD는 서비스를 만드는 초반에 구축할수록 좋다.
2) 모니터링
사용자에게 에러가 발생했을지 서버 로그를 항상 보고 있을 수는 없다. 또한 서버가 아니라 클라이언트 단에서 예상치 에러가 못한 에러가 발생할 수 있다. 만약 사용자가 ‘어, 에러가 발생했네. 개발자에게 보고해야겠다!’라는 예상을 했다면 이는 잘못된 생각이다. 대부분 사용자는 에러가 발생하면 서비스를 이탈을 하지 보고를 하지 않는다. 그렇기에 우리는 에러를 최소화하는 것이 최우선이며, 그 다음으로는 예상치 못한 에러가 발생했을 때를 대비해야한다.
예상치 못한 에러가 발생했을 때를 대비해, 서비스에 모니터링 시스템을 도입해야 한다. 나는 Sentry의 Alert 기능을 활용해서 즉시 이메일로, 이메일 알림 활성화로 휴대폰으로 메시지가 전송되도록 했다. 에러가 발생하면 휴대폰으로 즉시 알림이 오기 때문에 빠르게 대응할 수 있게 되었다.
3) 매주 회고
프로젝트를 주기적으로 돌아보는 것이 중요하다. 매일 개발만 하며 앞으로 가기만 하다 보면 내가 올바른 방향으로 가고 있는지 인지하기 어렵기 때문이다. 그래서 우리는 주기적인 회고를 통해 목표로 잘 가고 있는지 확인할 필요가 있다.
나는 회고록이라는 노션 페이지에 이에 대한 기록을 하는 중이다. 매주 토요일, 이번 주에는 어떤 작업을 했는지 돌아보고 내가 기존에 세웠던 계획을 얼마나 이루었는지 체크한다. 그리고 부족한 점이 있다면 이를 어떻게 개선할지, 잘한 점이 있다면 이를 앞으로도 어떻게 실천할지를 생각하고 이를 바탕으로 다음 주 액션 아이템을 만든다. 마지막으로 내 목표와 얼마나 가까워지고 있는지 확인하고 이를 바탕으로 다음주 계획을 세운다.
이를 통해 매주 내 프로젝트가 발전하고 있다는 성취를 느끼며 프로젝트에 대한 동기부여를 지속할 수 있다. 이는 후술할 내용인 동기 중 내적 동기에 큰 힘이 된다.
매주 회고를 하는 것에서 더 나아가 매일 회고를 하는 것도 중요하다. 한 주는 하루하루가 쌓여 만들어지기 때문이다. 매일 회고는 매주 회고하는 것처럼 중간에 목표를 수정하지는 않는 것이 좋다. 왜냐하면 하루하루 실천을 했을 때는 아무것도 알 수 없기 때문이다. 적어도 1주일, 1달은 실천해봐야 이 목표와 계획이 잘못되었는지, 잘하고 있는지를 판단할 수 있기 때문이다. 그렇기에 나는 매일 '오늘 내 기존 계획을 얼마나 이루었는지', 오늘 든 생각은 무엇인지, 고민, 걱정이 무엇인지에 대해 적어보고 이를 해결하기 위해서, 계획을 더 잘 이루기 위해서는 앞으로 어떻게 해야 하는지 돌아본다.
4) 성장 중심 프로젝트
프로젝트는 말 그대로 성장 놀이터이다. 내가 만들고 싶은 기능을 만들어 볼 수 있고 사용해보고 싶던 기술을 도입할 수 있고, 또한 새롭게 배운 패턴을 적용해볼 수도 있다. 개발자에게 있어서는 천국이라 할 수도 있다.
채용 공고를 먼저 살펴보자. 자격 요건 중에 'UX'가 부족한가? 그럼 UX를 공부하자. UX에는 어떤 게 있고 무엇이 좋은 UX이고, 어떻게 해야 UX를 개선할 수 있는지. 그리고 이를 바탕으로 내가 만들고 있던 서비스에 하나씩 적용해보는 거다. 여기서 핵심은 '학습'이 아니라 '프로젝트'에 초점이 맞춰져야 한다는 것이다. 왜냐하면 우리는 우리의 실력을 '무엇을 알고 있느냐'가 아니라 '무엇을 할 수 있느냐'로 증명해야 하기 때문이다. '무엇을 할 수 있느냐'는 곧 '무엇을 해봤느냐'로 증명할 수 있을 것이다.
프로젝트는 '무엇을 해봤느냐'를 증명하기에 가장 최적화된 공간이다. WebGL을 배워보고 싶은가? 지금 당장 WebGL을 이용한 주식 사이트를 만들어보자!
5) 블로깅
프로젝트 개발은 모래성을 쌓는 과정이라면 블로깅은 모래성에 물을 적셔 단단하게 만드는 과정과 같다. 프로젝트 개발은 퍼즐 조각의 모양별로 모으는 작업이라면, 블로깅은 모아둔 퍼즐 조각을 하나씩 맞추는 작업과 같다.
나는 요즘 프로젝트를 개발하며 경험한 것들을 위주로 글을 작성하고 있다. 블로깅을 하며, 프로젝트를 개발할 때는 개발하느라 급급해 지나쳤던 지식의 빈틈을 알게 되었고, '우선 구현을 해야지'라는 생각으로 무심코 지나쳤던 헷갈리는 것들을 알게 되었다. 마지막으로, 개발을 한 내 경험을 한 번 더 정리할 수 있게 되었다.
프로젝트를 개발하며 노션에 전부 기록을 했다. 하지만 이는 기록 용도가 커 나 혼자만 알아보기 쉽게 작성한 것들이 많다. 처음에 나는 이 정도로 충분할 줄 알았다. 하지만 블로깅은 남을 어느 정도 의식하며 기록을 해야 하기에 남들이 이해할 수 있도록 설명하는 데에 신경을 쓰고, 신경을 쓰다 보니 머릿속에서 체계적으로 정리가 되고, 비로소 내 것이 되고, 끝내 더 오랫동안 기억에 남게 된다는 장점이 있다.
또한 블로깅은 내 프로젝트를 계속해서 개발하고 싶은 내적 동기가 되었다. 블로거라면 프로젝트를 개발하며 문득 그런 생각이 들 때가 있을 것이다. '이거, 좋은 블로그 소재가 되겠는데?' 보통 어려운 문제를 맞닥뜨리거나 새로운 기술을 도입하려고 할 때, 혹은 서비스에 큰 변화를 주려고 할 때 이런 생각이 든다. 이런 순간들이 블로그 글감이 되어 개발에 대한 동기부여가 되고, 이는 다시 프로젝트를 지속하게 만드는 원동력이 된다.
정리하면, 프로젝트를 개발하며 새롭게 알게 된 점, 어려웠던 점, 프로젝트에 대한 전반적인 모든 것들은 블로그 소재가 된다. 프로젝트 개발은 곧 블로깅에 대한 동기가 되고, 블로깅은 곧 프로젝트 개발에 대한 동기가 되는 것이다.
6) 직접 사용
나는 지금까지 적지 않은 서비스들을 개발해왔다. 하지만 서비스의 대상은 대부분 '나'가 아닌 '다른 사람'이었다. 그러다 보니 내가 직접 애용해 사용할 일은 드물었다. 그저 '개발하기 위해', '테스트하기 위해' 서비스를 사용하는 것이 전부였다. 서비스에 애착이 가지 않고, 손이 가지 않으니 관심도 점점 떨어졌다.
하지만 이번 서비스는 달랐다. 다른 사람이 아닌 내 불편함을 해소하기 위해 만든 서비스이고, 그 누구보다 '기록'에 열정적인 나이고 서비스 또한 '기록'에 중점을 둔 서비스였기 때문이다. 나는 매일 이 서비스를 사용했다. 아티클을 읽으며 메모를 하고, 읽고 싶은 아티클이 있으면 위시리스트에 추가했다. 직접 서비스를 사용하다 보니 느껴지는 불편한 점들이 한두 가지가 아니라는 걸 느꼈다. 예를 들어, 메모를 실수로 삭제했는데 다시 복구할 방법이 없다는 사실에 좌절한 적이 있다. 그날 당장 삭제한 메모를 복구하는 기능을 만들었다. 이제는 안심하고 메모를 삭제하고 서비스를 이용할 수 있게 되었다.
내가 직접 서비스를 사용하며 이 서비스의 충성 고객이 되는 것이다. 사용자 입장에서 서비스를 고민하기에 가장 최고의 방법이라 생각한다. 내가 만든 서비스가 이렇게 부족한지 몰랐다. 신경 써야 할 것들이 이렇게 많은지 몰랐다. 내 서비스의 사용자가 되어 직접 사용을 해보니 하나하나 체감하게 되었다.
앞으로는 내가 만든 서비스를 애용하고 사랑하는 개발자가 되어야겠다고 생각했다. 그 전에 내가 이미 애용하는 서비스를 개발하거나, 애용할 수 있는 서비스를 만드는 것만큼 행복한 일이 없을 거라 생각한다. 내가 평소 애용하는 서비스를 내가 직접 개발한다라.. 생각만 해도 행복하다.
꿈이 생겼다.
‘내가 평소 애용 하는 서비스를 개발하거나, 애용할 서비스를 개발하는 개발자가 되는 것’이다.
나날이 행복하지 않을까?
나는 웹 메모 서비스를 개발하며 ‘개발자 하기를 잘했다’고 생각한 순간이 한 두번이 아니다. 웹 메모 서비스를 사용하며 큰 뿌듯함을 느꼈고, 사용자가 하나 둘 늘고, 사용자들이 메모를 실제로 추가하는 것을 보며 날아갈 듯이 기뻤다.
자기 효능감
이는 이전에 자존감 수업에서 읽은 자존감의 요소 중 하나인 자기 효능감(내가 얼마나 쓸모있는 사람인지 느끼는 것)과 연관이 있는 듯하다. 내가 만든 서비스를 너무 잘 사용하며, 잘 사용하는 사람들을 보며 내가 얼마나 쓸모 있는 사람인지 느낀 것이다. 그리고 자존감의 향상은 곧 행복감으로 이어져 행복을 느낀 것이다.
7) 지속적인 UX개선
나는 서비스를 사용하며 가장 중요하게 생각하는 건 UX이다. 서비스를 만드는 것은 결국 사용자를 위해 만드는 것이다. 그 사용자가 내가 될 수도, 가족이 될 수도, 전국민이 될 수도 있다. 결국 핵심은 '사용자'다. 그럼 사용자에게 가장 중요한 건 사용자가 직접 느끼는 '사용자 경험'이라 할 수 있다. 사용자가 '이 서비스 좋네', '이 서비스를 사용하면 기분이 좋아'라고 느껴야 이 서비스를 다시 찾게 된다.
나는 지속적으로 서비스를 사용하며 '어떻게 하면 사용자가 더 편하다고 느낄까?'를 고민했다. 그리고 지속적으로 사용자 경험을 개선해왔다.
예를 들어, 메모를 작성할 때 로딩 상태를 명확하게 보여주지 않으면 사용자는 '내 메모가 저장되고 있는 건가?'하고 불안해한다. 그래서 저장 중일 때는 스켈레톤 UI를 보여주고, 저장이 완료되면 토스트 메시지로 피드백을 주도록 개선했다. 또한 페이지 전환 시 애니메이션을 추가해 자연스러운 화면 전환을 구현했고, 에러가 발생했을 때는 단순히 '에러가 발생했습니다'가 아니라 '어떤 문제가 발생했고, 어떻게 해결할 수 있는지'를 안내하도록 했다.
이런 작은 개선들이 쌓여 서비스를 쓸 때의 경험을 조금씩 낫게 만든다. UX 개선은 한 번에 끝나지 않고 계속 해나가야 하는 일이다. 이에 대한 자세한 내용은 성능이 곧 UX다: 웹 서비스 성능과 사용자 경험 개선 여정, 사용자 경험 개선하기를 참고 바란다.
8) 피드백 시스템 구축
사용자가 서비스를 사용하다가 '이건 서비스 측에 문의하고 싶어!'라는 생각이 들 수 있다. 그때 가장 하단으로 내려 이메일을 확인하고, 이메일에 로그인을 하고, 메일 내용을 작성하는 것은 사용자에게 너무 많은 절차를 만드는 것이라 생각했다. 나 또한 이메일은 귀찮은 나머지 작성을 하려다가도 안 하고는 했다. 그래서 사용자에게 피드백을 작성하기 위한 절차를 줄여야겠다고 생각했다.
서비스 가장 상단의 '의견 보내기'를 누르면 모달이 뜨며 즉시 피드백을 전송할 수 있다. 그리고 이는 AWS SNS를 사용해 나에게 문자로 전송이 된다. 피드백을 받으면 즉시 확인하고 대응할 수 있게 되었고, 사용자 입장에서도 번거로운 절차 없이 간편하게 의견을 전달할 수 있게 되었다.
실제로 시스템을 구축한 뒤로는 사용자가 불편함을 느낄 때 바로 의견을 보낼 수 있게 되면서, 나도 개선점을 더 빨리 파악할 수 있게 되었다.
이에 대한 자세한 내용은 Supabase Webhook으로 실시간 SMS 알림 구현하기 (feat. AWS Lambda, API Gateway, SNS)를 참고 바란다.
9) 내적 동기
동기에는 내적 동기와 외적 동기가 있다. 내적 동기는 내가 서비스를 만들며 스스로 느끼는 성취감, 뿌듯함, 그리고 매일매일 열심히 기록을 해나가며 얻는 행복감과 같은 긍정적인 감정이다. 외적 동기는 사용자 수, 서비스 리뷰 등과 같은 외부적인 요인으로부터 오는 동기이다.
서비스 개발을 처음 시작할 때는 내적 동기가 강했다. 오로지 내가 평소 느끼는 불편함을 해소하기 위해 만든 서비스이고, 기능을 하나하나 추가할 때마다 느껴지는 성취감은 곧 내가 서비스를 지속적으로 개발할 충분한 동기가 되었다. 그런데 어느 순간부터 사용자가 하나둘 생기기 시작하고, 사용자 수가 느는 것에 집착을 하기 시작했다. 사용자 수가 7명이 늘은 날에는 하루 종일 기분이 날아갈 것 같고, 사용자가 5명이 줄은 날에는 우울해하고는 했다. 기분에 따라 내 서비스에 대한 애정도 늘었다가 식기도 했다.
이렇듯 외적 동기는 외부의 상황에 따라 오르고 내린다. 사용자 수가 늘면 기쁘고 서비스에 대한 애정이 커지고, 반대로 사용자 수가 줄면 우울해지고 서비스에 대한 애정이 줄어든다. 이렇게 외적 요인에 일희일비를 하면 점점 외적 동기는 줄어들게 된다. 일희일비하다 보면 지치기 마련이며, 한편으로는 내 외적 동기를 더 이상 믿을 수 없기 때문이다.
그렇기에 우리는 외적 동기보다 내적 동기를 키우는 데 집중해야 한다. 위에서 이야기한 것들을 예시로 하나씩 살펴보면 다음과 같다.
- 매주 회고를 통해 ‘내가 이번 한주도 열심히 살아왔구나’하는 성취감을 느낀다.
- 성장 중심 프로젝트를 통해 ‘프로젝트에서 이 기능을 개발하면 내가 그만큼 성장할 수 있겠구나’하는 성장에 대한 기대를 가진다.
- 블로깅을 통해 ‘프로젝트에서 만드는 기능 하나하나, 막힌 점, 배운 점들이 모두 블로그의 소재가 되는 구나’하는 뿌듯함을 느낀다.
내적 동기는 서비스를 더 개선하고 발전시키고 싶어 하는 욕심을 만들며, 서비스를 개선하고 발전시키면 이는 곧 또 다른 내적 동기를 불러일으킨다. 이렇게 선순환 구조를 만들게 된다. 위의 것들을 하나씩 실천해보며 서비스에 대한 내적 동기를 만들어보는 건 어떨까?
맺으며
지금까지 웹 메모 서비스가 v0.0.1부터 v1.8.4까지 발전시켜온 과정과, 프로젝트를 지속적으로 성장시키기 위한 다양한 방법들을 살펴보았다. 지금까지 돌아보면 가장 중요했던 건 '속도'와 '지속성'이었다. '빠른 배포'를 통해 서비스를 신속하게 사용자에게 제공하고, 실제 사용자들의 피드백을 받아 개선하는 과정이 프로젝트의 성장 동력이 되었다. 이러한 빠른 순환을 위해 CD를 구축하고, Sentry를 통한 모니터링 시스템을 도입했으며, 매주 회고를 통해 방향성을 점검했다.
또한 나는 프로젝트를 단순한 개발 과제가 아닌 성장의 놀이터로 바라보려고 했다. 새로운 기술을 도입하고, UX를 개선하며, 블로깅을 통해 경험을 공유하는 과정은 프로젝트와 개발자 모두의 성장을 이끌었다. 특히 직접 서비스를 사용하면서 느낀 불편함을 개선하고, 사용자의 피드백을 적극적으로 수용한 것이 서비스의 품질을 높이는 데 큰 도움이 되었다.
마지막으로, 외적 동기에 일희일비하지 않고 내적 동기를 키우는 데 집중했던 것이 프로젝트의 지속적인 발전을 가능하게 했다. 매주의 회고, 블로깅, 성장 중심의 개발 접근은 강력한 내적 동기를 만들어내는 선순환을 이루었다.