실패한 프로젝트 얘기해본 적 있으세요? 저는 사실 실패 얘기 할 때마다 좀 주저하게 돼요. “그거 왜 안 했어?” 같은 질문이 두려워서일 수도 있고요. 근데 최근에 정리하다 보니, 실패한 프로젝트에서 배운 게 성공한 것보다 훨씬 많더라고요. 그래서 오늘은 제가 지난 3년간 실패한 사이드 프로젝트 5개를 까볼려고요.
왜 실패 얘기를 하냐면요
지난주에 우연히 3년 전 노션 페이지를 열어봤어요. “2023년 목표”라고 적힌 페이지였는데요, 거기에 적힌 프로젝트 5개 중에 완성한 게 하나도 없더라고요. 처음엔 좀 부끄러웠어요. “나 뭐 했지?” 싶어서요.
근데 자세히 읽어보니까 그때 시도했던 게 지금 하는 일의 밑거름이 된 게 많더라고요. 지난 1년 블로그 운영하면서도 그때 실패했던 경험들이 생각나서 “이건 이렇게 하면 안 되겠다” 판단한 경우가 꽤 있었고요.
그래서 실패도 기록해두면 자산이 된다는 걸 깨달았어요. 혹시 저처럼 실패한 프로젝트 숨겨두신 분들 있으면, 같이 보면서 배운 것들 정리해보면 좋을 것 같아요.
첫 번째 실패: 뉴스레터, 구독자 12명의 비명
2023년 초에 IT 뉴스레터를 시작했어요. “매주 하나씩만 보내면 되잖아?” 생각했거든요. 근데 3주 만에 접었어요. 구독자는 12명이었고, 그중 3명은 제 가족이었어요.
출처: Unsplash
왜 실패했나 돌아보면, 타겟이 너무 모호했어요. “IT에 관심 있는 사람”이라고 했는데, 그게 누구인지 구체적으로 정의하지 않았거든요. 그러다 보니 어떤 뉴스를 골라야 할지도 모르겠고, 글을 쓸 때도 “누가 읽지?” 계속 고민하게 되더라고요.
배운 점은 명확했어요. 누구를 위한 건지 모르면, 아무도 위한 게 아니다. 지금은 블로그 쓸 때도 “이걸 읽을 사람이 누구지?” 먼저 생각해요. SEO 글 쓸 때도 타겟 독자를 먼저 정하고 시작하니까 훨씬 수월해졌고요.
뉴스레터 실패 요약
- 원인: 타겟 불분명, 지속할 동기 부족
- 배운 점: 구체적인 독자 페르소나 설정 필수
- 이후 활용: 블로그 타겟 독자 정의에 적용
두 번째 실패: 앱 아이디어 메모장, 메모만 하다 끝남
“이런 앱 있으면 좋겠다” 생각만 하고 메모장에 적어둔 게 30개 넘게 있어요. 근데 하나도 만들지 못했어요. 이것도 일종의 실패라고 생각해요.
문제는 실행 없는 아이디어는 자산이 아니라는 거. 계속 새로운 아이디어만 쫓다 보니, 하나도 완성하지 못했어요. “이게 진짜 괜찮은가?” 검증도 안 하고 메모만 하니까, 나중엔 “내가 뭘 적었더라?” 상태가 되더라고요.
그래서 지금은 아이디어를 적으면 바로 다음 단계를 함께 적어요. “이 기능 하나만 먼저 만들어보자”라든가, “비슷한 앱 3개만 찾아보자” 같은 거요. 그리고 n8n으로 자동화할 때도 “이거 필요한가?” 먼저 물어보고 시작해요.
세 번째 실패: 유튜브 채널, 4개 영상 후 침묵
2023년 여름에 유튜브 채널을 만들었어요. “블로그만큼은 아니어도 영상도 해보자” 싶어서요. 근데 4개 올리고 말았어요. 조회수는 평균 50뷰 정도였고요.
실패 원인은 블로그랑 똑같이 하려고 했다는 거예요. 글 쓰듯이 대본 짜서 읽고, 썸네일도 블로그처럼 만들고요. 근데 유튜브는 유튜브만의 룰이 있더라고요. 후킹, 썸네일, 첫 30초, 이런 것들요.
배운 건 플랫폼마다 맞는 방식이 다르다는 거. 블로그에서 잘 되는 방식을 유튜브에 그대로 가져오면 안 됐어요. 지금은 새로운 플랫폼 들어갈 때 “이거 어떻게 돌아가는지”부터 파악해요.
네 번째 실패: 프리랜서 포트폴리오 사이트, 완성하고 안 올림
이게 제일 어이없는 건데요, 프리랜서용 포트폴리오 사이트를 다 만들어놓고 안 올렸어요. “아직 부족해” 생각하면서요. 3개월 동안 수정만 하다가 결국 다시는 열어보지 않게 됐어요.
문제는 완벽주의. “이 정도면 올려도 되겠다” 기준이 계속 올라가더라고요. 처음엔 “메인만 완성하면 돼” 했다가, “어바웃 페이지도 더 예쁘게”, “프로젝트 설명도 더 자세하게”, 이러다 보니 끝이 안 났어요.
지금은 일단 내놓고 고친다는 원칙을 세웠어요. 애드센스 승인받을 때도 완벽한 사이트 만들려다가 2달 버렸는데, 그냥 최소한으로 만들어서 승인받고 천천히 고치는 게 낫더라고요.
다섯 번째 실패: 팀 프로젝트, 의견 차이로 흐지부지
친구랑 같이 프로젝트 해보려고 했어요. “너 기획, 나 개발” 이렇게 나누고요. 근데 2주 만에 끝났어요. 의견 차이 때문이었어요. “이 기능 넣자” “아니 빼자” 이런 게 계속되다가, 결국 둘 다 흥미를 잃었거든요.
배운 건 협업은 기술보다 합의가 먼저. 무슨 기능을 넣을지보다, “어떻게 결정할지”를 먼저 정했어야 했어요. 지금은 누군가랑 같이 일할 때 “결정은 누가 어떻게?”부터 이야기해요.
실패에서 발견한 공통 패턴
5개 실패를 돌아보니까 공통점이 있더라고요.
- 시작은 쉽게, 끝내는 더 쉽게: 아무 준비 없이 시작했다가, 조금만 어려워도 포기했어요.
- 검증 없이 진행: “이거 정말 필요한가?” 안 물어보고 그냥 만들었어요.
- 완벽 추구: “아직 준비 안 됐어” 핑계로 계속 미뤘어요.
- 플랫폼 이해 부족: 블로그 방식을 다른 데 그대로 적용하려고 했어요.
이런 패턴을 알고 나니까, 지금은 프로젝트 시작할 때 체크리스트를 만들어요. “타겟은?”, “최소 기능은?”, “언제까지?” 이런 것들요. 그리고 2주 안에 결과 내놓기를 목표로 해요. 길어지면 흐지부지되니까요.
실패 기록하는 법, 저는 이렇게 해요
지금은 실패한 프로젝트도 꼭 기록해요. “왜 실패했나?”, “다음엔 어떻게?” 적어두는 거죠. 그러면 나중에 비슷한 상황에서 “아, 그때 이래서 안 됐지” 떠올릴 수 있어요.
기록은 간단하게 해요. 날짜, 프로젝트 이름, 실패 이유, 배운 점 이렇게 4가지만요. 복잡하게 하면 안 적게 되더라고요.
장단점, 솔직하게 말하면요
실패 기록의 장점은 비슷한 실수를 줄일 수 있다는 거예요. 저도 뉴스레터 실패 이후로는 타겟 없이 시작하는 일이 없어졌고요. 그리고 실패를 두려워하지 않게 됐어요. “어차피 기록해두면 자산 되니까” 생각하니까요.
근데 단점도 있어요. 실패 기록만 보고 있으면 “나는 왜 이것밖에 못 했지” 위축될 때가 있어요. 그래서 저는 성공 기록도 같이 적어요. 작은 것도 꼭요. “오늘 블로그 조회수 1 더 올랐다” 같은 거요.
지금 도전 중인 건 잘될까요?
솔직히 모르겠어요. 지금도 몇 개 사이드 프로젝트 진행 중인데, 이것도 실패할 수 있어요. 근데 이전과 다른 건, 실패해도 배울 게 있다는 걸 안다는 거요. 그리고 실패 기록해두면 나중에라도 써먹을 수 있고요.
혹시 사이드 프로젝트 고민 중이신가요? “이거 실패하면 어쩌지” 걱정하지 마시고, 일단 시작해보세요. 실패해도 기록해두면 자산이 돼요. 저도 그렇게 해서 지금까지 왔거든요.
여러분은 어떤 실패 경험 있으신가요? 댓글로 공유해주시면 같이 배워보아요.