1일 프로젝트가 계획대로 되지 않았던 이유

과거 Tistory의 ‘1일짜리 개인프로젝트 후기’를 기반으로 다시 작성했다. 원래 글은 결과보다 실패한 계획을 솔직하게 기록한 글이었다.

원문: https://it-r-b.tistory.com/121

처음 계획은 너무 컸다

하루 안에 개인 프로젝트를 하나 만들면서 다음 기술을 한꺼번에 사용하려 했다.

• React
• Node.js
• Docker
• AWS
• STT
• Translate API

결과부터 말하면 계획 대부분을 완료하지 못했다.

최종적으로는 React와 Node.js 대신 익숙한 Spring과 JSP를 사용했고, Docker와 AWS 배포도 하지 못했다.

API도 번역 기능까지 연결하지 못하고 STT 기능 구현에서 마무리했다.

왜 실패했을까

1. 사용하지 않은 기술의 복구 비용을 계산하지 않았다

React와 Node.js를 이전에 공부했지만 한동안 사용하지 않았다.

‘전에 해봤으니 금방 다시 할 수 있겠지’라고 생각했지만 실제로는 프로젝트 초기 설정부터 다시 찾아봐야 했다.

기술을 한 번 배운 것과 당장 프로젝트에서 사용할 수 있는 것은 다르다.

2. 하루라는 시간에 비해 범위가 너무 넓었다

프론트엔드, 백엔드, 외부 API, 컨테이너, 클라우드 배포를 모두 하루에 넣으려 했다.

각 기술을 이미 능숙하게 다룬다고 해도 통합 과정에서 예상하지 못한 문제가 생길 수 있다.

하루 프로젝트라면 기술 개수를 늘리는 것보다 하나의 핵심 기능을 끝까지 완성하는 것이 더 현실적이었다.

3. MVP를 먼저 정하지 않았다

당시에는 ‘이 기술도 써보고 싶다’를 기준으로 범위를 잡았다.

지금 다시 한다면 기능을 다음처럼 나눌 것이다.

Must

• 음성을 입력받는다.
• STT로 텍스트를 얻는다.
• 결과를 화면에 표시한다.

Should

• 번역 API를 연결한다.

Could

• React로 UI 구현
• Docker 이미지 생성
• AWS 배포

Must가 끝난 다음에만 Should와 Could를 진행했어야 했다.

익숙한 기술로 되돌아간 선택

시간이 부족해지자 Spring과 JSP로 전환했다.

당시에는 이것을 실패처럼 느꼈지만, 지금 보면 제한 시간 안에 동작하는 결과물을 만들기 위한 선택이었다.

문제는 기술을 바꾼 것 자체가 아니라 처음부터 우선순위를 정의하지 않았다는 점이었다.

지금 다시 하루 프로젝트를 한다면

다음 규칙을 적용할 것 같다.

1. 목표 기능은 하나만 둔다.
2. 처음 30분 안에 동작하는 최소 골격을 만든다.
3. 새 기술은 최대 하나만 사용한다.
4. 배포는 처음부터 필수인지 선택인지 결정한다.
5. 시간별 중단 기준을 둔다.
6. 마지막 한 시간은 새로운 기능이 아니라 정리와 배포에 사용한다.

실패한 프로젝트도 기록할 가치가 있다

이 프로젝트에서 완성한 기능은 많지 않았다.

하지만 이후 프로젝트를 계획할 때 중요한 기준을 얻었다.

기술 스택의 개수가 프로젝트의 완성도를 의미하지 않는다.

작은 범위를 끝까지 완성하고, 그 다음 새로운 기술을 추가하는 방식이 결과적으로 더 많은 것을 배울 수 있다.