차콜 프로젝트 실패 회고 — 5개월의 기록

왜 이 글을 쓰는가

차콜 프로젝트는 2025년 9월부터 2026년 1월까지 8인 팀이 진행한 푸드트럭 중개 플랫폼이었다. 1월 쯔음 해체되었고, 프로젝트는 미완성으로 끝났다. 성공 사례만 포트폴리오에 올리는 것이 당연하게 여겨지지만, 실패에서 배운 것이 훨씬 더 구체적이었기 때문에 이 회고를 남긴다.

팀의 구성과 내 역할은?

PM 1명, 디자이너 1명 백엔드 2명, 프론트엔드 4명.

나는 이 중 프론트엔드의 팀원으로써 참여했다.

무엇을 만들려 했는가

푸드트럭 사장님과 개인들을 직접 연결하는 플랫폼을 만들고자 했으며, 사용된 프론트엔드 기술 스택은 아래와 같다.

Frontend: React19, tailwindcss, vite, tanstack query, clsx, jotai, lodash, react-hook-form, zod, storybook, swagger-typescript-api,
util: eslint, prettier, github, code rabbit.

무엇을 배웠는가

1. 짜임새 있는 개발 관리

먼저, 어려운 기술이나 내용들에 대해 먼저 article을 작성하며 공부하고 다른 사람들에게 설명하는 시간을 가졌다. React Query에 대해서 제대로 적용해보기 전이 었는데 미리 공부하고 시작하니 도움이 되었다.

일정 면에서도 노션을 사용하여 컨벤션을 확실히 정하고 정해지지 않은 사항에 대해서는 추가로 보완을 진행해서 코딩 스타일을 규격화했다. 또한 무작정 api 단위나 기능 단위로 하지 않고 뷰나 컴포넌트 단위로 담당을 세분화하여 분담이 적절하게 이루어졌다.

주기적으로 진행된 디스코드, 대면 회의도 중간중간 늘어지는 의욕을 가다듬는데 도움이 되었다.

2. 새로운 기술의 적극적 도전

storybook이라는 라이브러리를 처음 써보게 되었는데, 작성한 컴포넌트를 인터랙티브한 예시로 공유할 수 있는 웹페이지를 swagger처럼 발행해주었다. 이번에는 공통 컴포넌트 위주로 적용해서 맛보기 느낌이었는데 아직 규모가 작아서인지 크게 도움이 되는가는 체감하지 못했다.

prettier 설정이 제각각 달라서 자동정렬 시 실제로 작업하지 않은 내용도 변경 사항으로 찍히기도 하는 것을 막기 위해 전용 설정 파일을 공유하여 indent, space 등 형식을 맞췄다.

다만 아쉬웠던 건 tailwind class 정렬과 cursor는 vscode와 좀 다르게 적용되는 것 같아서 일치를 보기 어려웠다. 다음엔 이런 부분도 미리 정하고 테스트 후 시작한다면 더 좋겠다.

RHF+zod는 schema.ts 파일로 분리하여 일관되게 적용하려고 했고, Tanstack Query도 key 전용 파일로 분리하여 별도로 관리하고, Barrel import로 복잡한 import도 깔끔하게 만드는 등.. 여러 심화 기법들을 사용해보는 기회도 가졌다.

이런 부분에서 내가 모르는 부분에 대해서 확실히 모른다고 말하지 못한 것이 후회된다. 그러다가 schema, key 적용이 잘못되었다는 지적을 받고 리팩토링을 했어야 했는데 그 때 더 체감 되었다.

3. 적극적인 PR 리뷰 문화

그 간의 PR은 그저 브랜치를 병합하기 전에 다른 팀원에게 공지하는 용도에 가까웠었다. 차콜 프로젝트에서는 처음으로 devlop 브랜치를 두어 main은 안전히 보호했고, develop 브랜치로의 PR도 2명 이상의 approve가 있어야 가능하도록 정책을 설정했다.

메신저로 PR을 알리고 꼼꼼한 리뷰와 수정 요청들을 추가로 받으면서 코드를 개선할 수 있었다.

code rabbit이라는 ai 리뷰 툴도 사용해서 사람은 알아채기 어려운 문제도 해결하고, 나 스스로 PR을 올릴 때 반복된 지적 사항이 잘 해결되었는 지, 다른 문제는 없는 지 수차례 검토하며 완성도 있는 코드를 짜게 되었다.

그래서인지 나중에 차콜의 코드를 다시 보아도 노력한 흔적이 보이고, 고심했던 기억이 난다.

왜 중단되었는가?

사실 그 이유는 지금도 잘 모르겠다.

프론트엔드 개발 인원이 4명으로 훨씬 많아서 촉박한 개발 사이클을 체감하지 못해서였을 수도 있겠다.

개인적인 예상으로는 구체적인 시장 조사를 했을 때 상업성이 부족해보였거나, 다른 더 급하거나 중요한 일로 무기한 연기된 것이 아닌가 싶다..

다음에 다르게 할 것

기획에 대해서 더 적극적으로 물어보고, 참여하기
모르는 기술이나 컨벤션에 대해서는 한번 공부한 뒤, 물어보기
새로운 기술 도입에 대해서는 좀 더 보수적으로 접근하기

이 프로젝트가 끝난 뒤 두 달 동안은 사이드 프로젝트를 시작하기 싫었다. 그러나 지금 돌아보면, 실패의 원인이 명확하다는 것 자체가 배운 증거다.