모두가 그런 것은 아니겠지만, 흔히 오픈소스 프로젝트를 고를 때, 보통 이렇게 할 겁니다. GitHub 스타 수, README 확인, 괜찮아 보이네.. 하고 클론.
저도 그랬습니다.
숏폼 영상 자동 생성 프로젝트를 위해 오픈소스를 찾던 중, README가 깔끔하고 스타도 꽤 있는 것을 발견했습니다. 기능 설명도 명확하고, 데모 영상도 있었던 만큼, 믿음직스러웠죠. 바로 포크하고 로컬에 클론했습니다.
결과요? 패키지 버전 충돌로 실패. 패키지 버전 조정 후, 추가 시도 후 실패. 결국, 해당 오픈소스의 이슈에 가서 비슷한 버그로 pr 요청이 있길래, 그대로 따라해도 실패. 웹 구동이 되어도 내부 로직에 문제가 있어서 실패.
거의 1시간 가량 소모하다가 포기했습니다.
README에서는 Docker 빌드 후, 실행만 하면 된다더니, 까면 깔수록 끝도 없더군요.
이런 경험 이후, 오픈소스를 고르는 방식을 바꿨습니다.
README는 프로젝트의 첫인상입니다. 다만, 첫인상이 좋다고 결과를 보장하지는 않죠. 잘 작성된 README는 프로젝트가 좋다는 증거가 아닌, 문서화를 잘했다는 증거일 뿐이죠.
스타 수의 착각: 스타는 관심이지 품질을 보장해주지는 않습니다. 2년 전, 바이럴 타서 스타가 많지만, 방치된 프로젝트도 수두룩하죠.
데모 영상: 화려한 데모 영상이 있어도, 그게 최신 버전에서 재현되는지는 별개 문제입니다.
마지막 커밋 날짜: README보다 이게 더 중요할 때가 많습니다. 6개월 이상 커밋이 없다면, 해당 오픈소스 속 의존성 패키지들이 충돌을 일으킬 확률이 높죠.
여러 프로젝트를 평가하면서 만든 체크리스트입니다.
(1) 재현 용이성 - 가장 먼저, 실행 안 되면 끝
가장 먼저 확인합니다. 아무리 기능이 좋아도 내 환경에서 돌아가지 않으면 의미가 없죠.
체크 포인트:
탈락 기준: 문서대로 따라해도 실행이 안 되거나, 삽질이 과하게 필요하면 즉시 탈락
(2) 기능 적합성 - 내 목적에 맞는가
실행이 된다면 이제 기능을 봅니다. 비슷한 기능이 아니라 내가 필요한 기능이 있는지가 핵심입니다.
제 경우 숏폼 영상 생성이 목적이었기에, 전체 파이프라인(스크립트 -> TTS -> 영상 결합 -> 자막 -> 렌더링)이 실제로 연결되어 동작하는지를 봤습니다.
단계별로 체크합니다.
(3) 유지보수/확장성 - 6개월 후에도 쓸 수 있는가
단기 실험용이 아닌, 실제 프로젝트에 쓸 거라면, 유지보수 상태를 봐야 합니다.
체크포인트:
(4) 기술 스택 적합성 - 내 프로젝트에 붙일 수 있는가
좋은 프로젝트여도 내 스택과 맞지 않으면 비용이 커지죠.
체크포인트:
제 경우 Next.js 프로젝트에 붙여야 했기 때문에, Docker + FastAPI로 제공되는 프로젝트가 가장 이상적이었습니다.
(5) 운영/제품화 - 실서비스로 갈 수 있는가
MVP를 넘어 실제 서비스로 만들 계획이라면, 운영 관점도 봐야 합니다.
체크포인트:
처음 시도했던 오픈소스, 가칭 S는 재현 용이성에서부터 패키지 충돌과 Docker 실패, 이후의 기능 적합성 테스트의 경우에도 잔버그로 인해 진행도 못했으므로 탈락이었습니다.
하지만 기준으로 평가하면: 재현 용이성에서부터 탈락했기 때문에 나머지는 평가할 필요가 없었습니다. 1시간 가량 삽질하기 전에, 이슈 탭에 수두룩하게 쌓여있는 미해결 설치 문제들을 보고 더 빨리 판단할 수 있었을거니까요.
제가 사용하는 평가 템플릿입니다. 숏폼 영상 자동 생성 프로젝트용으로 작성했기에, 기능 적합성 항목은 본인 프로젝트에 맞게 수정해서 쓰시면 됩니다.
핵심은 순서대로 평가하고, 탈락하면 즉시 중단하는 것입니다. 앞에서 걸리면 과감히 다음 후보로 넘어가세요.
https://closed-mousepad-38b.notion.site/2d0e77b9d79e8036821df232c7a3051b?source=copy_link
오픈소스 선택에 정답은 없지만, 최소한 README와 스타 수만 보고 결정하는 실수는 피할 수 있습니다.
이 템플릿이 여러분의 삽질 시간을 줄여주길 바랍니다!