KPT 회고로 프로젝트 실패 회고하기

개요

최근 개인프로젝트를 중단하고 뭘 잘못했었는지 회고해보자는 생각에 여러 발표들과 글을 읽으면서 회고 방식에 대해 고민해봤다.

회고하는 방법은 많았지만 그 중에서 KPT회고가 내가 뭘 잘못했고 잘했는지 구조있고 명확하게 정리할 수 있을거 같아 KPT로 프로젝트를 왜 실패하게 됐는지, 왜 그렇게 생각했고 중단했는지 정리해봤다.

 

KPT 회고란 무엇인가?

https://brunch.co.kr/@jinha0802/35

https://techblog.woowahan.com/2677/

왜 프로젝트를 하게 됐는지?

아침마다 여러 회사들의 기술 블로그를 보면서 편하게 블로그 링크를 모아놓고 쉽게 관리할 수 있도록 하면 좋지않을까 생각해봤다. 크롬 북마크를 조금 더 편하게 사이트를 저장하고 디자인을 추가해서 관리할 수 있도록하는 북마크 확장 기능이 생각이 났고 비슷한 서비스로는 노션 웹클리퍼, infinite dashboard처럼 생산성 도구로써 사용될 수 있지 않을까 생각했다. 뿐만 아니라 생각나는 기능도 많고 참고할만한 자료도 많아서 좋은 아이디어라고 느껴져 바로 시작해봤다.

처음엔 그냥 간단하게만 만들자고 생각해서 브라우저에서 로컬스토리지로 구현했다가 확장시켜 실제 서비스로 돌려보고자 서버를 추가하고 디자인을 추가해보고자 했다.

https://www.notion.so/web-clipper,

https://chrome.google.com/webstore/detail/infinite-dashboard-new-ta/meffljleomgifbbcffejnmhjagncfpbd

지금 생각해보니 각 블로그를 크롤링해서 며칠마다 업데이트하는게 어땠을까 싶다.

왜 중단하게 됐는지?

사실 생각했던 기능은 구현을 했다. 그게 너무 간단했던 구조라서 그렇지 오히려 구현보다는 실제 서버를 배포하고자 클라우드에 올리는 과정과 Nest.js 프레임워크를 처음 사용하면서 서버 구축 삽질했던 시간 등 처음 접하던 부분이 문제였다.

하지만 이러한 부분도 단순히 트러블이었을 뿐 진짜 문제는 아니었다.

내가 생각했던 문제는 스스로도 사용 안할것같은 기능을 구현하면서 목표도 없이 구조만 변경하고 있었고 이런 점이 내가 생각했던 진짜 생산성 도구와 점점 멀어진다고 생각했기 때문이다.

이걸 느낀 순간 바로 중단을 했고 동시에 어디서 잘못된건지, 어떻게 하면 좋았을지 생각해보기 시작했다.

이걸 KPT 구조를 통해 작성해보려고 한다.

Keep

새로운 기술을 배우는 과정

스스로 기술을 배우는데 좋은 방법은 직접 써보면서 생각해보는 것이었다. 중간에 살짝 아쉬운 부분이 있었지만(일단 구현 먼저해) 그래도 기존에 어려움을 느껴서 사용을 꺼렸던 도커라던지 여러 기술들을 직접 사용해보니 예전보단 확실히 개발 전반적인 이해도가 높아졌다고 느꼈다.

추가적으로 새로운 기술들을 왜 사용해야하는지만 느낀다면, 기술을 사용함으로써 개선이 체감된다면 상당히 재밌고 집중도 잘 됐다.

따라서 구현하고 싶은게 생각났을 때, 과하지 않게 필요성을 찾아보고 직접 써보는 것도 좋을거같다.

 

문제해결과정 문서화

배포하면서 이슈를 문서화했다.

특히 도커쪽 이슈가 많았고 내가 잘못 설정한건지 자료가 잘못된건지 여러 자료들을 참고하면서 안됐던 이슈들을 해결하고 내가 겪었던 경험위주로 작성하면서 다음에 비슷한 이슈를 만났을 때 금방 해결할 수 있었다.

이렇게 문서화 하는 것으로도 크게 얻어가는 것들이 많았다.

 

Problem

부족한 계획

적절한 목표관리와 이 프로젝트를 하면서 뭘 얻고자하는지, 일정 계획, 개발, 완성도, 서비스 관리 등등 웹서비스를 하고자했으면서도 전혀 고려되지않은 계획으로 인해 개발하면서도 내가 무엇을 하고있는지 명확하게 정리하기 어려웠다. 이후 정리하긴했지만 우선순위 등 아무것도 정하지않고 시작만 했던 프로젝트는 프로젝트가 아니라 이어붙이기가 아니었을까 생각한다.

 

시분할 개발

위 문제와 비슷했는데 하나의 기능을 완성하지않고 이거 조금, 저거 조금씩 돌려가며 개발을 했다. 이건 거의 함정에 빠지는 것과 비슷했는데, 브랜치명을 로그아웃 이슈 해결로 만들어놓고 디자인을 수정하고 머지한적도 있었고 열심히 만들어놓고 뒤늦게 필요없는 기능이라고 생각해서 삭제해버린적도 있다.

문제 혹은 목표를 잘 나눠서 설정하고 하나의 문제, 목표에 집중하는 것이 필요하다고 생각했다.

 

기술을 먼저 고려하고 서비스를 고려했다. (중요)

이게 제일 중요했는데, 프로젝트를 중단한 결정적인 계기가 됐다.

내가 만든 북마크 서비스의 구조는 다음과 같다. 웹 브라우저 ↔ 서버 ↔크롬 익스텐션이었는데 구조만 이어져있지 솔직히 따로 놀고 있었고 구조를 잘못 설계했다고 생각한다. 익스텐션을 사용하기 위해 웹에서 로그인하고 키를 받고 익스텐션에 넣고 연결한 뒤, 이후 클립한다면 웹에서 다시 확인가능하다.

처음엔 상관없지 않을까 싶어 계속했는데 이후 배포하려고보니 익스텐션에서 접근한다면 웹에서 등록해줘야한다는 것과 웹으로 접속한다면 익스텐션을 따로 설치해야한다는 서비스를 사용함에 있어서 불편함이 생긴다고 느꼈고, 이것 뿐만 아니라 사용자가 직접 웹사이트에 접근하거나 웹사이트에 접근하기 위해 따로 설정을 하거나 동작을 해야한다. 이렇게 정리해보니 굳이 서비스를 이용할 필요성이 있냐고 생각해본다면 당연히 아니라고 생각한다. 내가 위에서 생각했던 여러 도구들은 사용자 입장에선 단순히 설치만 한다면 이용할 수 있다. 그렇다면 나는 왜 이런 구조로 개발을 하게 되었을까 생각해봤다.

이건 기술을 먼저 고려했기 때문이다. 나는 Next.js가 편하고 웹 개발자를 목표로하니까 포트폴리오로 사용하려면 웹 서비스로 제공해야겠다고 생각하고 시작했다. 큰 실수를 하고 있다는 것을 아래 영상을 보면서 깨닫게 되었는데 영상의 김범준 대표님께서 개발자는 단순히 코딩하는 사람이 아니라 주어진 비즈니스 문제를 해결하는 사람으로 생각하라는 것이었다.

 

배달의민족 CEO에게 뽑고 싶은 개발자를 물어보았다

이 말을 들으니 바로 무엇이 문제였는지 이해가 됐다. 거기서 생각났던 의문이 바로 웹으로 개발해야했을까? 라는 의문이었다. 여러 비슷한 서비스들을 사용해보면서 왜 이 서비스가 이런 기술을 통해 서비스를 제공하는지 생각해본적 크게 없었다. 하지만 이번에 이런 경험들을 겪고 어떤 문제가 있었는지를 생각해보면서 가장 중요했던게 서비스를 먼저 고려해야된다는 것, 그리고 기술은 단순히 도구라는 것이다.

굳이 웹이 아니더라도 더 좋은 방식으로 서비스할 수 있다면 그것을 선택하는 것이 당연하다. 이건 내가 개발을 이해하는데 있어서 정말 중요했다고 생각한다.

 

왜 Next.js를 쓰는건지 왜 React를 쓰는 것인지를 고민하게 되었고 더 좋은 거 있다면 당연히 그거 써야지. 기술에 얶매이지않는 개발자가 되야겠다고 느꼈다.

 

이렇게 생각하고 보니 면접 질문에서 왜 Redux 쓰셨나요? 왜 이거 쓰셨나요? 이런 질문들이 왜 면접에서 자주 나오는지 이해하게 되었다. 물론 신입 개발자 입장에서 생각해보면 일반적이고 형식적인 질문이라고 생각되지만 나중에 이것 또한 나만의 생각으로 말할 수 있을거 같다.

그래서 다시 돌아와서 내가 서비스를 설계했던 시간으로 돌아가 다시 고민해본다면 굳이 웹서비스가 아닌 서비스를 우선적으로 고려해서 사용하기 쉬운 쪽으로 더 중요하게 고민해봤을 거 같다.

 

Try

길게 잡지 않기

항상 아침시간대, 점심 먹기전까진 무조건 공부를 한다. 순수하게 3~4시간은 되는 거 같은데 이후엔 쉬다가 다른 공부, 예를 들면 학교 공부나 수업들을 듣곤하는데 아침에 막혀서 못했거나 부족했던 부분을 굳이 이후 시간에 채우려고 하지 않았다.

하지만 이번에 계획 없이 길게 늘어진 것을 생각해보면 목표를 설정하고 최대한 목표만 집중해서 단기간에 해결하기 위해 시도해보는 것도 좋을거같다. 스프린트나 해커톤처럼.

 

 

회고

다음에 회고할 때도 KPT로 써봐야겠다. 생각보다 잘 떠오른다