프로젝트가 끝났다고 판단하는 기준은 무엇인가요?

본문

저자는 다양한 종류의 프로젝트를 자주 만듭니다. 예상보다 커지는 프로젝트도 있고, 새로운 것을 시험하기 위한 실험도 있으며, 이미 존재하는 도구를 쓰는 대신 아주 특정한 문제 하나를 해결하려고 직접 만든 작은 유틸리티도 있습니다. 그러다 최근에는 프로젝트가 언제 실제로 끝나는지 생각하게 됐다고 말합니다. 여기서 말하는 ‘끝’은 단순히 버려졌거나, 언젠가 다시 작업할 것이라고 생각하며 폴더 안에 남겨둔 상태가 아닙니다. 프로젝트가 의도한 역할을 다하고 더 이상 반드시 확장해야 할 이유가 없는 상태를 뜻합니다.

작동하는 순간 시작되는 기능 확장

소프트웨어를 완성하면 곧바로 더 많은 기능을 붙이고 싶어지는 경향이 있다고 설명합니다. 기본 기능이 작동하면 계정 기능이 필요하지 않을지, 여러 기기에서 동기화해야 하지 않을지, API를 제공할 수 있지 않을지, SaaS(Software as a Service)로 만들 수 있지 않을지 생각하게 됩니다. 처음에는 원하지도 않았던 기능을 열일곱 개쯤 추가하는 상황까지 이어질 수 있습니다. 물론 작은 프로젝트가 실제 사용 목적을 발견하면서 성장하는 경우도 있고, 그런 확장이 합리적일 때도 있습니다. 하지만 어떤 경우에는 단지 한 가지 일을 하는 도구가 필요했고, 실제로 그 도구가 그 일을 해냈다면 목표는 이미 달성된 것입니다.

저자는 모든 프로젝트가 열두 개의 통합 기능, 가격 페이지, 5년짜리 로드맵을 가져야 하는 것은 아니라고 말합니다. 기술적으로 추가할 수 있다는 사실만으로 그런 기능을 추가해야 하는 것은 아닙니다. 프로젝트의 가치는 앞으로 얼마나 커질 수 있는지가 아니라, 처음 만들게 된 목적을 충족했는지로 판단할 수도 있습니다.

‘만들 수 있을까?’에서 시작한 프로젝트

저자의 프로젝트는 대체로 “이걸 내가 만들 수 있을까?”라는 질문에서 출발합니다. 새로운 라이브러리를 시험하고 싶어서 시작할 수도 있고, 특정 기술이 어떻게 작동하는지 알아보고 싶어서 만들 수도 있습니다. 작은 유틸리티가 필요할 때도 있고, 새벽 1시에 떠오른 우스운 아이디어를 실제로 구현해보고 싶을 때도 있습니다. 이때 중요한 결과는 반드시 공개 제품이나 사업이 아닙니다.

처음 알고 싶었던 내용을 배우고, 원했던 기능을 수행하는 결과물이 만들어졌다면 저자는 그것을 미완성 프로젝트로 보지 않습니다. 프로젝트를 통해 얻으려 했던 것을 얻었기 때문입니다. 예를 들어 클릭 다섯 번을 줄여주는 작은 유틸리티도 만들 가치가 있고, 특정 개념을 이해하게 해준 실험도 가치가 있습니다. 주로 웃기기 위해 만든 엉뚱한 애플리케이션 역시 마찬가지입니다. 그것이 제품이나 비즈니스, 혹은 개발자의 개인 브랜드로 발전하지 않아도 제작에 사용한 시간이 정당화될 수 있습니다.

취미가 유지보수 업무로 바뀌는 순간

새로운 것을 시작하는 일을 좋아하는 사람에게는 이 기준이 특히 중요하다고 말합니다. 모든 프로젝트를 계속 유지하고, 개선하고, 언젠가는 수익화해야 하는 대상으로 취급하면 실험 하나하나가 또 다른 책임으로 변하기 때문입니다. 그렇게 되면 취미로 시작한 개발이 관리해야 할 업무 목록으로 바뀔 수 있습니다. 저자는 취미를 직업처럼 느끼게 만드는 방식은 원하지 않는다고 분명히 말합니다.

반대로 프로젝트가 자연스럽게 커지는 경우도 있습니다. 작은 아이디어로 시작했지만 계속 새로운 기능이 떠오를 수 있고, 다른 사람이 사용하면서 좋은 개선안을 제안할 수도 있습니다. 만든 프로젝트 자체를 좋아해서 계속 만지는 과정이 즐거울 수도 있습니다. 이런 확장은 문제라고 보지 않습니다. 저자는 실제로 원할 때 더 큰 프로젝트를 만드는 일을 좋아한다고 말합니다. 다만 프로젝트가 성장하지 않았다는 이유만으로 그 프로젝트를 만든 일이 가치 없었다고 판단할 필요는 없다고 강조합니다.

완료 기준은 성장 규모가 아니라 목적 달성

저자는 일부 프로젝트가 그저 존재하도록 내버려두는 데 점점 익숙해지고 있다고 말합니다. 버그를 발견하면 아마 수정하겠지만, 6개월 뒤 새로운 기능을 추가하고 싶어지면 그때 추가하면 됩니다. 그렇다고 해서 지금 당장 모든 가능성을 구현해야 하는 것은 아닙니다. 이미 만들었고, 작동하며, 자신이 그 결과물을 좋아한다면 그것으로 충분할 수 있습니다.

이 관점에서 프로젝트의 완료 기준은 기능 목록의 길이나 사용자 수, 통합 수, 상업적 확장 가능성이 아닙니다. 프로젝트를 시작한 이유가 무엇이었는지, 그 이유를 충족했는지, 만드는 과정에서 얻으려던 지식이나 결과를 얻었는지가 기준이 됩니다. 저자는 때로 프로젝트에 할 수 있는 가장 좋은 일은 그것을 그대로 두고 다른 것을 만드는 것이라고 말합니다. 그리고 자신에게는 이미 다음 아이디어가 있을 가능성이 높다고 덧붙이며, 독자에게 각자의 프로젝트가 실제로 끝났다고 판단하는 시점과 미완성 프로젝트 묘지에 해당하는 프로젝트들이 있는지 묻습니다.

원문: dev.to / 번역·요약: Trawling