## 들어가며 4월 중순 퇴사를 하고, 엘리와 이탈리아 여행을 한 달여간 다녀왔다. 당시 여행의 끝이 다가왔을 때는 약간 지쳐서 돌아왔는데 몇달이 지난 지금 봤을 때는 한 2주 정도는 더 있다가 올걸 하는 아쉬움이 남는다. 인생에서 퇴사하고 가는 첫 장기 여행이었고 돌아와도 어차피 회사를 다시 가는 게 아니라 그런가 어쩌면 지금도 여행을 계속하고 있는지도 모르겠다. 아니면, 5년 전 마지막에 마지막까지 내 사업을 엘리와 하고 있던 그 순간으로 돌아온 것도 같다. 각설하고, 이제 내 일을 시작하려면 다시 내 손으로 무언가를 다시 만들어야 했는데, 꽤 긴 시간 코딩을 손에서 놓고 있었기 때문에 다시 어디서부터 시작해야 할지 고민했을 때 간단한 프로젝트를 하나 만들어보는 것을 목표로 하면 좋겠다고 생각했다. 그래서 사업을 준비하면서 쉬는 기간 동안 사이드 프로젝트를 하나 해보는 것을 목표로 하고 귀국하였고, 아내와 함께 5월 말부터 본격적으로 일을 시작했다. 해당 회고는 프로젝트 전반적인 회고 1편과 풀스택 개발과 LLM을 활용하면서 정리한 회고 2편으로 정리를 하려고 한다. ## Scrumble 프로젝트 목표 Scrumble 프로젝트는 내가 투데잇을 할 때도 그리고 그 뒤에 다른 회사에 다닐 때도 계속했던 데일리 스크럼 미팅을 기반으로 한다. 사실 작년부터 회사에 다니면서 해보고 싶은 프로젝트였고 당시 팀에서 Confluence 로 데일리 미팅 노트를 작성하고 있었는데, 인원도 많아지고 팀도 나눠지고 하다 보니 쓰기가 굉장히 불편해졌는데 다음의 현상/불편들이 있었다. - 쓰는 사람만 쓰고 안 쓰는 사람은 안 쓴다. - 지나간 기록을 쉽게 볼 수가 없다. (Confluence 에서도 DataTable 을 지원하지만, DataTable 은 대부분 사용성이 구리다. 마치 DB나 엑셀에 값을 입력하는 느낌) - 30명이 넘는 인원인데, 노트 하나에 너무 많은 인원이 담겨 있어서 한눈에 보기가 힘들다. 내가 생각한 이 노트의 문제점은 팀이 작든 크든 그 옛날 evernote, dropbox paper, notion 으로 쓰든, Confluence 든 할 거 없이 업무와의 직접적 연결이 느슨해지기 시작하는 시점에 데일리 노트의 활용성이 급격하게 떨어졌고, 결국 팀원들의 컨디션이나 간단한 일상 공유까지도 잘 작동하지 않으면서 최종적으로는 해당 노트의 팀 내 커뮤니케이션 기능도 확연히 떨어지게 되었다. 팀원으로서는 쉽게 쓰고 커피챗이나 미팅을 자주 하지 않더라도 팀 내 커뮤니케이션을 활발하게 하는 것을 목표로 하지만 단순히 체크인 점수나 일상 점수만으로는 그 필요성이 확연히 떨어지는 것을 느꼈기 때문에 그날의 업무 Todo를 편리하게 작성할 수 있는 기능까지를 목표로 한다. 물론 Slack 과 같은 커뮤니케이션 툴이나 Jira 나 Asana 같은 프로덕트 관리 툴을 대신할 생각도 아니고 제품 포지셔닝이 그쪽은 아니기 때문에 최대한 해당 툴들과 통합을 목표로 한다. 다시, 프로젝트의 목표를 정리하면, - Main: 앞으로 우리 팀에서 쓸 수 있는 데일리 스크럼 서비스를 만들자 (MVP) - Sub: 팀이 본격적인 개발 프로젝트로 넘어가기 전까지 충분히 적응하고 연습하는 시간을 가지자 (업무 스킬 및 협업 관점에서)  *(완전 초기에 작성한 PRD 문서)* ## 프로젝트 셋업 ### 업무 환경 나는 열정보다 시스템을 믿는 사람이고, 재능보다 환경을 믿는 사람이다. (상대적인거지 재능과 열정이 중요하지 않다는 건 아니다.) 그래서 항상 무슨 일을 할때 일이 되게끔 하는 걸 굉장히 중요하게 여기는데 (모든 이해관계자의 Economy 가 일치한다던가, 비용과 시간이 적게 든다던가) 아무래도 집이라는 환경에서 모든 일을 해야하는 상황이다보니 이러한 고민이 많았고, 여전히 그 답을 찾아가고 있는 중이다. 대부분의 작업은 집에서 했다. #### 집 환경과 시스템 관점에서 집은 최적의 공간이 아니다. 우리 집이 방이 엄청 많은 것도 아니고 말이다. 그래도 엘리는 그 전에 법인 운영 시 거의 버려지다시피 한 사무실을 매달 몇십씩 꼬박꼬박 냈던 기억이 있다 보니 결국 지금은 비용 관점에서 집이라는 환경이 최선의 선택지였다. 두 개의 모니터와 M4 max. 밥을 직접 해 먹을수도 있는 최적의 공간. 물론 3개월 동안 일을 해보면서 느낀 건, 빨리 비용을 확보해서 장기적으로는 사무실을 구하는 게 맞을 것 같다. #### 생활 사이드 프로젝트지만, 풀타임으로 하는 사이드 프로젝트이다 보니 하루 종일 집에만 있을 위험이 있었다. 그래서 철저하게 하루 시간표를 세웠다. 엘리와 헬스장 출근을 출근이라고 생각하고 업무 사이클을 잡아가기 시작했다. 처음 한 달은 대부분 잘 지켜졌는데 두 달째 프로젝트 막바지가 다가오니 결국은 사이클이 깨지면서 마구잡이로 일을 하기 시작했다. 쉽게 이해를 돕자면, 잘 지켜질때는.. 10시 취침, 5시 30분 기상 -> 아침 운동 후 -> 출근이라는 거의 갓생 루틴이었다면.. 프로젝트 막바지에는.. 새벽 4시 취침, 12시 기상 -> 점심 먹고 -> 2시부터 일 시작.. 정도로 망가진 상태다. 마지막에는 결국 이런 생활에 둘 다 지쳐서 프로젝트 마무리를 위한 워케이션을 다녀오기도 했다. 코로나 시절 재택근무를 거의 안 해서 몰랐던 집에서 일하는 어려움을 몸소 느끼고 있다. ### 커뮤니케이션 엘리와 나 둘이서 (내가 회사 다닐 때도) 사이드 프로젝트를 진행하곤 했지만, 거기에 리모트 객원 멤버 한 명(조지-백엔드 개발 인턴)이 있었고, 둘이서 하더라도 모든 기록을 오프라인에만 남길 수는 없기에.. Slack, Notion, Jira, Confluence 부터 이전에 써보았던 Linear 나 Asana 등 다양한 툴들이 있는데.. 비용도 줄여야 하고 작은 팀이다 보니 이것저것 사용했을 때 결국 어마어마한 구독료에 Lock In 이 되는 경험을 했다보니.. 사실 그런데도 불구하고 Slack, Notion, Linear 정도로 정했던 상황이었는데 엘리가 ClickUp 이라는 슈퍼앱을 가지고 와서 ClickUp 을 선택하게 되었다. ClickUp 은 말그대로 Slack + Notion + Linear 라서, 커뮤니케이션을 위한 채널 채팅, 마크다운 문서화, 프로젝트 관리까지 다른 SaaS 1개 구독료로 세가지 기능을 다 쓸 수 있는 서비스이다. 알아보니 한국에서는 잘 안쓰는 서비스인 것 같다. All in One 좋아하는 한국 특성상 홍보가 많이 안된게 오히려 신기한 부분. 쓰다 보니 확실히 Slack, Notion, Linear 보다 10% 정도는 부족한 부분들이 보이지만, 그 세 개가 하나의 툴에서 유기적으로 통합되었을 때 가치가 워낙 크다 보니 정말 잘 쓰고 있다. 오히려 반대로 말하면 각 서비스의 기능들을 90%씩은 구현한 거니까 그걸 있는 그대로 잘 동작하게 구현하는 게 얼마나 대단한 건지 개발을 해본 사람들은 알 것이다. 하여튼 커뮤니케이션은 ClickUp 을 사용하면서 깔끔하게 해결. - 1인당 30$ -> 1인당 10$ - Slack 채널 채팅, Notion 문서화 모두 잘 지원 - 위에서 말한 10%는 각 솔루션을 딥하게 사용하다 보면 느끼는 차이점인데, 엄청 불편하지는 않음 - Project Management 도 직관적으로 필요한 기능만 잘 제공 ## 1차 MVP 기능 목표 1차 MVP 목표는 - 인증 - 스페이스 관리 - 체크인/체크아웃 작성 - 투두 리스트 작성 - 피드 페이지 - 실시간 댓글 및 리액션 - 실시간 알림 페이지 사실 1차 MVP 목표 기준으로 기능을 얼추 완성을 했지만, 중간에 이대로는 부족하다고 기능을 더 넣어야 한다고 하다가 한 주 정도를 버린 것 같다. - 결국 8주안에 마무리 될 MVP가 12주로.. 돌아보니 1차 기능 목표도 모두 구현이 되었고, 프로젝트의 원래 목표였던, - Main: 앞으로 우리 팀에서 쓸 수 있는 데일리 스크럼 서비스를 만들자 (MVP) - Sub: 팀이 본격적인 개발 프로젝트로 넘어가기 전까지 충분히 적응하고 연습하는 시간을 가지자 (업무 스킬 및 협업 관점에서) 도 얼추 달성했다. 물론 중간에 잘못된 의사결정과 여러 가지 삽질, 그리고 일을 안 한 시간까지 포함하면 전체 기간에서 한 3주 정도는 빼야 할 것 같다. 자세한 이야기는 아래 회고에서 이어서 하겠다. ## 회고 ### Keep #### Daily Dog Fooding Daily Dog Fooding. 아마 앞으로 프로젝트에서도 핵심이 될 사항이긴 한데, 직접 쓰기 위해 만드는 서비스이다보니 확실히 그냥 끝내기 위해서 라기보다 어떻게 하면 더 잘만들 수 있을까 고민을 많이 하게 되었다. 이전 회사에서는 메이커가 직접 유저가 될 수 없는 서비스이다보니 한계가 있었는데 확실히 매일 쓰면서 단순한 버그부터 개선 지점, 더 필요한 부분을 계속해서 더 파낼 수 있었다. 당장 고객이 없을때 Dog Fooding 은 메이커에게 최고의 장치다. #### Hands-On From Scratch 기술 회고에서 조금 더 자세하게 쓰겠지만 Golang(Fiber + Entgo) + Redis + PostgreSQL 로 백엔드를 Nextjs 로 프론트엔드를 풀스택으로 작업하면서 프로젝트의 완전 end to end를 내 손으로 모두 작업해 보면서 지난 몇 년간 손 놓았던 코드를 다시 손에 익히느라 진땀도 뺐지만, 월 200달러 내 친구 Claude Code 와의 협업을 통해서 그래도 혼자서 hands-on 으로 충분히 프로젝트 개발을 할 수 있는 상태가 되었다. #### 즐거움 사실 이전 회사에서 프로젝트를 하면서 만들면서 즐거움을 느낀 게 언제인가 싶다. 내가 쓰는 서비스라던가 하는 그런 걸 떠나서 그냥 매일매일 코딩하는게 즐거웠다. 사실 회사에서 DDD 를 도입하던 시점부터 나는 코드에서 손을 뗐었는데 초기 DDD/Clean Architecture Layer 설계부터 CQRS 도입, Event Driven 까지 하고 싶은 건 최대한 다 해봤다. 프론트엔드는 내 주 분야는 아니었지만, 스타일을 하나씩 수정해 보고 만들어가는 즐거움과 괴로움을 모두 느끼면서 여하튼 리누스 토발즈의 리눅스 그냥 재미로 개발까지는 아니더라도 충분히 내 손으로 직접 만들어가는 즐거움을 찾은 게 정말 중요한 시기였다. #### 멘토링 나는 가르치는 걸 좋아하는 사람인데, 잘 가르치는 게 무엇인지 고민을 하던 시기에 강의도, 가르치는 것도 관두었다. 그게 참.. 교육의 어려운 지점이다. 가르치는 게 아닌 잘 가르치는 것. 조지가 개발자로서 커리어를 이어가게 하려고 도와주고 싶었고 그 목적으로 프로젝트에 합류시켰다. 조지는 아직 백엔드 개발로는 거의 초입문자 수준이지만 이제 API 하나 정도는 스스로 만들 수 있는 수준이 되었다. 중간중간 내가 화도 내고 답답해하는 모습도 많이 비추었다. 항상 그럴 때마다 밑천이 드러나서 부끄럽다. 그래도 회사에 다니면서 파트 타임으로 하면서도 끝까지 포기하지 않는 조지가 기특해서 최대한 많이 알려주려고 했다. 여전히 멘토링이라는 것은 어렵다. 사람마다 수준도 해야 할 말도 다르고, 사실 개발이나 이런 스킬들은 일종의 도구에 불과하고 어떻게 일해야 하는지, 또 어떻게 같이 일해야 하는지, 얘기해야 하는지를 모르는 사람들이 많으므로 진심으로 수준 높은 S급 팀에서 서로 커뮤네케이션을 하려면 잘한 일을 말하기보다 못하거나 어려운 얘기를 할 수 있게 계속 끌어내는 게 좋은 멘토링이다. 당연히 내가 감정적인 되면 하등 그 방향으로는 도움이 안 된다. 세상 사람들은 AI가 발전하고 있으니, AI가 교육도 대체할 거라 쉽게 말한다. 하지만 AI는 도구다. 질문을 잘해야 답변도 잘한다. 초보자들은 질문을 못 한다. 실패에 대한 내성도 약하다. 과정에서 계속 그러한 부분들을 이끌어내고 극복할 수록 돕는 것이 내가 멘토로서 정말 어렵지만 계속 공부하고 플레잉 코치로서 같이 뛰면서 코칭하는 스킬들도 계속 공부해 보려고 한다. ### Problem #### 커뮤니케이션 부재 이번에 주로 듀오로 프로젝트를 이끌어가면서 느낀 가장 큰 문제점이다. 엘리가 프로덕트 디자이너로 가져가고 있는 프로젝트 방향성과 내가 개발자 이전에 프로덕트 매니저로 가져가고 있는 프로젝트 방향성이 어긋나는 부분이 종종 생겼는데.. 매일 옆에서 같이 일을 했지만, 정기적으로 미팅을 하거나 커뮤니케이션을 충분히 하지 못했다. 각자 실무 작업 퍼포먼스를 내기 위해 집중하다 보니 10시간 넘게 같은 공간에 앉아 있는데 말 한마디 없이 나는 코딩하고 엘리는 디자인하고 하는 시간이 잦았다. 또 내가 직접 모든 걸 개발할 수 있다 보니 간단한 거는 내가 그냥 추가해 버린다거나 충분한 커뮤니케이션 하지 않고 개인적인 판단으로 기능 명세를 변경해서 구현한다 든가 하는 이슈가 있었다. 물론 그 뒤에 충분한 회고를 통해서 데일리 미팅 시간을 잡았지만, Scrumble 프로젝트를 하면서 Scrumble 하지 않았던 가장 큰 문제. #### 과도한 기능 스펙 과도한 기능 스펙. 초기 MVP 는 사실 정말 사용 가능한 기본 수준이었고, 우리가 생각한 차별성을 가진 최소 기능 연동 (LLM 연동 리포트나 서드파티 연동)이 빠진 버전이었다. 그래서 각자 더 넣고 싶은 기능들이 있었고 해당 기능들을 완성해서 넣어야 한다는 충분히 커뮤니케이션 되지 않은 합의로 인해 갑자기 일정이 과도하게 늘어지기 시작했다. 돌아보면 2달 정도에 릴리즈가 될 수 있었던 MVP를 결국 3달 가까이 끌어오게 된 근본적인 원인은 그러한 기준과 그러한 이슈를 충분히 커뮤니케이션 하지 못하고 각자 작업에만 매달린 결과이다. #### 데드라인 부재 데드라인 부재. 데드라인은 없었던 건 아니다. 다만, 이게 외부 공개 프로젝트나 더더욱이나 사업성을 생각하고 시작한 프로젝트가 아니다 보니 결국 위의 두 가지 문제가 겹치면서 한주만 더 해보시죠. 한주만 더 해보시죠. 하다가 결국 일정이 흐지부지 늘어나기 시작했다. 그 많은 사이드 프로젝트들이 실패하는 이유도 아마 대부분 비슷할 건데, 대부분 90%까지 프로젝트를 거의 끝내지만, 나머지 10% (배포를 위한 준비, 미뤄두었던 필수 기능 구현 등)이 사실 기존에 했던 90% 만큼 에너지를 내야 하는 작업이다. 즐겁지 않은 작업이기 때문에.. 아마 돌아보면 그런 것들이 겹쳐서 더 많은 기능을 넣어야 한다고 주장했던 것도 같다. #### 즐거움만큼 큰 괴로움 Claude Code 나 Cursor 등 기타 툴들이 바이브 코딩과 함께 유행하면서 마치 딸깍 한 번으로 코딩 모르고 개발할 수 있는 것처럼 약을 팔지만, 사실 간단한 서비스가 아닌 이상에야 결국 코드를 사람이 손을 대야하고, 기능이 많아지면서 A를 수정하면 B가 문제가 생기는 경우도 허다하거나 Context 를 잘못 파악한 AI 가 중복된 로직을 만들거나 Architecture Layer 를 무시하고 자체적으로 무언가를 만드는 등 여러 문제가 생긴다. 특히, 간간이 해왔던 백엔드와 달리 프론트엔드는 정말 오랜만이어서 하나부터 열까지 다 삽질이었는데 레이아웃/스타일 이슈부터 실시간 처리까지 Claude code 만 두들겨서 딸깍으로 문제 해결이 안 되어서 이런저런 context 를 줘가며 괴롭히다가 내가 코드를 직접 수정해서 바로 해결된 문제도 꽤 많았다. 여하튼 코드 작성하는 즐거움만큼이나 괴로움도 컸는데, 아직 도입 못 한 tiptap 적용이나 필수 기능 구현 등에서는 간단하지만, 하고 싶지 않은 설정 작업들이 그랬다. #### 잘못된 판단 고민 부족 워크스페이스를 기본적으로 생성하는 SaaS 의 성격을 띄고 있다 보니 기본적인 인증 토큰이 서비스에 로그인하는 유저 인증과 워크스페이스 내의 멤버로 인증하는 부분이 나뉘어져 있었는데 처음에 빠르게 개발한다는 이유로 그러한 디테일을 고민하지 않고 평소 하던 대로 유저 인증만 가지고 진행했다. 그렇게 서비스를 얼추 마무리하는 시점에 크게 잘못된 걸 깨달았다. 결국 모든 API 설계와 인증 체계를 멤버로 마이그레이션 했는데 이 작업만 전체 검증 및 테스트까지 포함해서 얼추 3,4일은 한 것 같다. 하기 싫어서 작업을 미룬 거까지 합치면 일주일 넘게 걸렸다. 그리고 처음부터 tiptap 을 가져가려고 했는데 과할 것 같다고 해서 작업은 중단했는데 그때가 프로젝트 초기라 복잡도가 낮은 상태에서 적용하고 마이그레이션 했으면 금방했을건데 지금 작업하려니 엄두가 안나는 부분. 그냥 golang orm 으로 Entgo 를 쓰다보니 그냥 썼는데 생각보다 Clean Architecture Layer 가 명확할때 그 장점이 많이 상쇄되는 부분 등등.. (이건 추후 기술 회고에서 다시 풀어보겠다.) 솔직히 냉정하게 보았을 때 아무리 코드를 손에서 좀 놓았다고 한들, 감 떨어졌다고 생각되는 판단들이 꽤 있었고 결국 프로젝트 릴리즈 시점에 신나게 두들겨 맞고 있다. 아프다. #### 루틴 이슈 앞서 생활에서도 언급했듯이 처음 지켜나가려고 했던 데일리 루틴이 무너지면서 생활적으로나 정신적으로 중간에 둘 다 한번 위기가 왔다. 그래서 긴급조치로 워케이션을 택했는데 다행히도 좋은 선택이었고 어느 정도 다시 정리가 되어서 돌아왔지만, 초반에 잘 지켜나갔던 만큼의 루틴 상태로 현재 돌아오고 있지 않아서 다시 가다듬어야 하는 이슈이다. 프로젝트 막바지에 Scrumble 에 매일 쓰여져있고 매주 회고 리포트에 보면 루틴 유지가 힘들다는 것이 거의 8할이다. 처음 시작하는 용기보다 다시 시작하는 용기가 더 어렵다. 다시 갓생? 프로젝트를 시작해 보자 ### Try #### 커뮤니케이션 사실 문제점의 상당수는 결국 엘리와 산책을 통해 얘기하면서 솔루션을 찾고 다시 판단하고 해소되었다. 결국 정기적인 미팅도 중요하고 조금 더 커뮤니케이션을 활발하게 가져가는 것도 중요하다. 지금 일하는 공간(집 거실)을 조금 더 커뮤니케이션 하기 적합한 공간으로 엘리가 맞춰가고 있는데, 나는 데일리 미팅과 주간 미팅 일정을 만들어서 다음 프로젝트에서는 절대 문제점으로 커뮤니케이션이 부족하다는 말은 나오지 않게 하겠다. 부족한 것보다 차라리 과한게 더 나은 것 같다. #### 부끄럽지 않으면 너무 늦은 것이다. > If you are not embarrassed by the first version of your product, you've launched too late. > *리드 호프먼 (링크드인 창업자)* 부끄럽지 않으려고 어느 순간 처음 MVP 에서 벗어나서 너무 과도한 기술 스펙을 얘기하기 시작했다. 사실 내가 쓰려고 만든 건데, 만들고 나서 계속 다듬어도 되는 건데 말이다. 엘리가 중간에 회고를 통해서 '불특정 다수를 대상으로 무언갈 해보려다가 시간 낭비를 했는데 *토니가 제 1고객이다* 라는 생각으로 접근하니 빠르게 진행이 되었다.' 라는 말이 정말 중요했다. 결국 마무리와 본격적인 사업 준비와 다음 프로젝트로 넘어가기 위해서 이 정도에서 릴리즈하고 마무리를 하기로 했다. 다음 프로젝트는 훨씬 더 빠르게 마무리할 것이다. #### 몰입 루틴도 몰입을 위한 하나의 중요한 도구이다. 그런데 여기서 말하는 건 꼭 일하는 시간만의 몰입은 아니다. 살면서 이렇게 시간이라는 자원이 넘치는 시기가 거의 없었는데 막상 그 시간이 되니 조금 시간을 막 쓰는 경향이 있다. 여기서 막 쓴다는 건 내가 온전히 그 시간에 집중하고 몰입하고 있지 못하는 얘기다. 그렇게 하루하루를 허비하면 또 후회만 남을까 봐. 매일매일 정신을 차린다. 놀 때도 노는 것에 온전히 몰입하자. 더 이상 하루 시간의 대부분은 다른 일(회사 일)을 하면서 다른 생각을 하면서 행복을 좇는 것보다 내가 원래 생각했던 것처럼 온전히 지금 시간에 몰입해야 한다. 연습이 사실 필요한 부분이다. 더 노력해야지. '할 땐 하고 쉴 땐 쉬자'가 요즈음 이런 환경에서(집에서 일하고 시간이 자유로운 환경) 특히 더 어려운 부분이 있는 것이다. ### Lesson Learned - **완벽한 MVP는 모순이다** - 부끄러워도 빨리 출시하자 - **듀오 프로젝트 = 과도한 소통** - 10시간 같이 있어도 대화는 필수 - **실패해도 다시 한번** - 루틴이 망가졌다고 포기하지 말자, 다시 일어서면 된다 - **AI는 마법이 아니다** - 결국 사람이 코드를 이해해야 한다 - **Dog Fooding이 답이다** - 내가 1호 고객이 되자 ## 나가며 사이드 프로젝트이지만 풀타임으로 했고.. 어느 날은 20시간 앉아서 코딩하는 날이 있는가 하면 어느 날은 3일 내내 키보드에 손도 안 댄 날도 있다. 매년 아침 일찍 출근해 빌딩 안에서 일하며 밤늦게 퇴근하는 여름을 보냈었는데, 안 그래도 유독 더웠던 여름에 집에서 일하니 정말 여름을 정통으로 느꼈다. Scrumble 은 사실 이전 회사에서도 계속 개인적으로 시도해 보고 싶었던 프로젝트였고, 지금도 매일매일 사용하면서 쓰고 있기 때문에 무척 마음에 든다. 아직 목표로 했던 기능 마일스톤까지는 한참이지만 이제 다른 프로덕트를 개발하면서 차근차근 업데이트를 해보려고 한다. 여차저차 3개월의 여정에서 느낀 건 역시 온전히 내 시간을 써서 개발을 시작하니 나의 안 좋은 습관, 밑천이 온전히 드러나는 부분이 많았고 그 전 회사에서 내가 얼마나 많은 부분을 남의 손을 빌려 일을 해결했는지 확연히 드러나 느껴지는 순간들이었다. 반대로 말하면 이런 것들을 스스로 해결해 나가면서 더 빠르게 성장할 수 있는 환경에 던져진 것이다. 회사는 안락했지만 역시 성장을 위해서는 스스로 모든 걸 마주할 수 있는 용기가 필요한 법이다. 만족스러운 날도 있지만 그렇지 않은 날들도 있다 보니 계속 글로 뭔가를 남기거나 정리하는 걸 미루고 이렇게 쓰는 것도 아쉬운 부분 중 하나다. 프로젝트에 대한 기록은 매일 남겼지만, 주기적으로 일기라도 썼으면 조금 더 나아졌을까 싶다. 자주자주 기록하고 돌아보자. 창업 준비를 하면서 시작한 사이드 프로젝트인데 어느새 이게 주가 되었던 시간이었다. 이제 손도 풀었고 웜업도 마쳤으니 이번 프로젝트에서 배운 여러 가지 사항을 다음 프로젝트에서도 잘 적용해 보고 같은 실수를 반복하지 않기 위해 노력해보자. 과정도 중요하고 성과도 중요하지만 결국 마무리를 하지 않으면 그 어떤 것도 가치를 발하기 힘들다. 다음 프로젝트를 위한 Try에서 적은 Action Item 외에도 나 자신을 마주 보고 계속 정면 돌파 해나가야겠다. 그리고 즐거움을 잊지 않기 위해 더 열심히 할 것이다. > "A warrior does not give up what he loves, he finds the love in what he does." > "전사는 자신이 사랑하는 것을 포기하지 않는 법이야. 자기가 하는 일에서 사랑을 찾는 사람이지" > "A warrior is not about perfection or victory or invulnerability. He's about absolute vulnerability." > "전사는 완벽하거나 언제나 승리하거나 완전무결한 존재가 아니야. 그는 압도적인 절망 속에서도 일어나지" > > - Peaceful Warrior > - 평화로운 전사 중에서  *(워케이션 중 마이 데스크)*  *(Scrumble 워케이션 중 체크아웃 노트)* *기술 회고에서 계속* --- - 이전 회고 - [[4년간의 IHFB 회고]] - 다음 회고 -