사이드 프로젝트를 그만 만드세요. 아무도 신경 쓰지 않습니다 — 불편한 계산

AI 요약

글쓴이는 README와 초기 커밋만 남긴 저장소가 아홉 개라고 밝히며, 사이드 프로젝트를 취업·학습·수익 창출 수단으로 삼는 관행을 따져봅니다. 프로젝트를 많이 만들어도 사용자가 없으면 성과가 쌓이지 않는다는 주장입니다.

포트폴리오의 신호가 약해진 이유

글쓴이는 채용 담당자가 지원자의 저장소를 직접 복제하거나 코드를 살펴보는 경우가 드물다고 말합니다. 이력서 첫 검토에 걸리는 시간이 평균 6~7초라는 눈 추적 연구를 언급하며, GitHub 링크를 눌러도 프로필과 기여 그래프 정도만 훑는다고 주장합니다. 여기에 AI가 몇 시간 만에 보기 좋은 앱을 만들어 배포할 수 있게 되면서, ‘사이드 프로젝트를 만들었다’는 사실만으로 개발 역량을 증명하기 어려워졌다고 봅니다. 누구나 쉽게 재현하는 결과물은 차별화 신호가 되기 힘들다는 논리입니다.

코드는 쉬워져도 사용자를 얻기는 어렵습니다

사업 가능성을 따질 때는 가입자 수가 아니라 7일 뒤에도 돌아와 기능을 다시 쓰는 사용자를 세라고 합니다. 글쓴이는 사이드 프로젝트 열 개 가운데 실제 사용자가 개발자 본인 한 명뿐인 경우가 대부분이라고 표현합니다. AI가 코드를 작성하는 수고를 줄여도 배포, 유지율, 신뢰를 해결해주지는 않습니다. 제품 개발에서 어려운 부분은 코드 작성이 아니라 낯선 사람이 서비스를 계속 쓰게 만드는 일이라는 설명입니다.

학습도 결과물과 구분해야 한다고 지적합니다. 튜토리얼을 따라 인증과 CRUD를 구현하고 배포하는 과정은 화면과 저장소를 남기지만, 익숙한 문법과 명령을 다시 익히는 데 그칠 수 있습니다. 글쓴이는 이런 종류의 지식은 AI가 먼저 대신하게 된 영역이라고 봅니다. 반면 실제 사용자의 불만과 이탈을 겪으며 쌓는 판단력은 단순한 구현으로 얻기 어렵다고 주장합니다.

실제 사용자에게 배포하며 얻은 경험

글쓴이가 계속 운영한 프로젝트는 하나뿐이며, 돈을 낸 낯선 사용자가 실제로 썼다고 합니다. 해당 서비스에는 데이터가 영구 저장되기 전에 요청 성공을 알리는 쓰기 경로가 있었습니다. 시연과 테스트에서는 문제가 없었지만, 재시도가 겹친 상황에서 성공 응답만 나가고 저장은 실패했습니다. 고객은 계정에 접근하지 못했고, 작업 기록도 남지 않았습니다. 글쓴이는 이 경험을 통해 저장 완료 전에 응답을 보내는 설계의 위험을 배웠다고 설명합니다. 튜토리얼이나 프로젝트를 더 만드는 일로는 얻기 어려운 교훈이었다는 것입니다.

만들기보다 배포하고 유지하기

글쓴이는 만들기를 그만두라는 뜻은 아니라고 선을 긋습니다. 즐거움을 위한 프로젝트는 계속 만들되, 취업이나 학습 전략으로 사이드 프로젝트의 개수를 늘리는 데 집중하지 말라고 제안합니다. 하나를 만들어 실제 낯선 사용자에게 내놓고, 불만과 환불 요청을 감당하며 계속 유지하라는 조언입니다. 사용자에게 의존받는 제품 하나가 결과물만 쌓인 저장소 여러 개보다 더 많은 판단력을 길러주고, 면접에서도 더 설득력 있는 경험이 될 수 있다고 주장합니다.

끝부분에서는 이 논리를 AI 에이전트 개발에도 연결합니다. 코드를 생성하는 작성자와 변경 사항을 깨뜨려 보려는 검토자를 분리하고, 사람이 병합을 결정하는 구조를 설명합니다. 생성된 코드의 양보다 실제 환경에서 안전하게 쓸 수 있는지 판단하는 과정이 중요하다는 관점입니다. 글쓴이는 이를 자신의 에이전트 플랫폼 xenition의 구조와 연결하며, 생성은 저렴해졌지만 결과를 검증하고 책임지는 판단은 여전히 사람의 몫이라고 말합니다.

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