대학생이 크몽에서 백만 원대짜리 풀스택 프로젝트 외주받은 썰

안녕하세요! 저는 현재 군 전역 후 복학을 앞두고 있는 컴공 1학년 개발자입니다.

 

저는 군 입대 전부터 웹 개발에 관심이 많았습니다. 그래서 대학교 동아리에서 프로젝트에 참여도 해보고, 개인적으로도 여러 토이 프로젝트를 개발하기도 하였습니다. 군 입대 이후에도 군대의 PC방이라고 할 수 있는 사지방 (사이버지식정보방)에서 꾸준히 프로젝트 개발과 공부를 병행하며 개발 실력을 키워나갔습니다.

최근 군 전역 이후에는 과연 "내가 만든 코드가 시장에서 경제적 가치가 있을까?"라는 궁금증이 생겨 무작정 크몽에 발을 들였습니다. 결과적으로 백만 원대 규모의 풀스택 개발 외주를 성공적으로 마무리했습니다. 오늘은 그 과정을 한 번 공유해볼까 합니다.

 

✨ 실속있고 예쁜 포트폴리오

저는 경력이 전혀 없는 학생 신분이었습니다. 이런 저에게 프로젝트를 맡길 사람은 없을 거라고 확신했죠. 그래서 가장 중요한 건 시각적인 신뢰라고 생각했습니다. 바로 실속있고 예쁜 포트폴리오를 내세우는 거였죠. 제가 내세운 포트폴리오는 두 가지였습니다.

 

• 포트폴리오 A (왼쪽): 대학교 동아리에서 만든 "자취방 체크리스트 앱" (프론트엔드)
• 포트폴리오 B (오른쪽): 군 복무 중 1인 개발한 "일용직 구인구직 플랫폼" (기획, 디자인, 백엔드 + 프론트엔드)

위 사진처럼 예쁜 상세 이미지를 정리해서 올려두었습니다. 상세 이미지에는 주요 기능을 소개하는 실제 앱의 UI를 포함시켰습니다. 실제로 이 두 개의 포트폴리오를 보고, 관련 내용의 프로젝트 외주 문의가 추가로 들어오기도 하였습니다. 특히 "지도" 기능이 포함된 포트폴리오 A와 "구인구직" 기능이 포함된 포트폴리오 B를 보고, 위치 기반 채용 앱 프로젝트 외주 문의가 오기도 하였습니다. (이 문의는 실제로 수주로 이어지진 않았습니다.)

 

🚇 명확한 노선

기획부터 디자인, 백엔드, 프론트엔드까지 혼자서 모든 것을 책임져야 하는 1인 풀스택 개발은 결코 만만한 작업이 아닙니다. 물리적인 시간의 한계가 명확하죠. 저는 이 한계를 극복하기 위해 Firebase와 같은 BaaS를 적극적으로 활용했습니다.

 

BaaS를 이용하면 서버 관리, 로그인 구현, 데이터베이스 설정과 같은 인프라 구축에 들어가는 시간을 크게 단축할 수 있습니다. 인프라 구축이라는 보이지 않는 곳에 시간을 쏟는 대신, 의뢰인이 실제로 눈으로 볼 수 있는 기능과 UI/UX를 위주로 구현하는 것에 집중할 수 있을 것이라 생각했습니다.

 

솔직히 저처럼 혼자서 프로젝트의 전 과정을 모두 도맡아야 하는 상황이라면, 무조건 BaaS를 사용하는 것을 추천드리고 싶습니다. 직접 서버를 구축하고 필요한 API를 모두 개발하는 것은 비효율적이기도 할 뿐만 아니라, 불완전한 결과물을 만들게 될 수도 있습니다. 혼자서 개발을 하다보면 시간에 쫓겨 코드 품질은 뒷전으로 밀려나고, 기능 구현에 매몰되는 경우가 있습니다. 그러다 보면 보안적인 허점이나 엣지 케이스 등을 놓치기 쉽습니다. 이는 곧 보안 사고나 사용자 경험 저하, 서비스 장애 등의 치명적인 문제로 이어질 수도 있습니다. 하지만 이미 검증된 시스템과 인프라를 제공하는 BaaS를 사용하면 이러한 문제에서 자유로워집니다. 대기업에서 제공하는 인프라를 내 서비스에서 그대로 사용할 수 있게 되는 거니까요.

 

추가로, Firebase에서는 Firebase Auth의 소셜 로그인이나 Firestore의 실시간 업데이트과 같은 유용한 기능들도 제공하고 있었습니다. 이러한 기능을 적절히 사용하여 복잡한 기능도 빠르고 안정적으로 구현할 수 있어 좋았습니다.

 

그래서 저는 아예 서비스 제목에 "Firebase"라는 문구를 대문짝만하게 박아버렸습니다. 현실적으로 BaaS 없이 혼자서 서비스를 만드는 것은 무리라고 생각하고, 사용할 기술 스택을 미리 정해버린 것이죠.

 

🌟 첫 의뢰 문의, 그리고 첫 주문

그렇게 서비스를 게시하고 하염없이 기다렸습니다. 처음 2주 동안은 문의가 전혀 오지 않았습니다. 사실 어느 정도 예상한 바이긴 했습니다. 경력도, 후기도 없는 학생 개발자에게 개발 의뢰를 맡길 사람은 없을 거라고 예상하고 있었죠.

 

하지만 서비스를 게시하고 약 2주가 지난 뒤, 첫 문의가 옵니다.

 

저는 설레는 마음을 억누른 채, 가장 먼저 준비된 기획서나 와이어프레임이 있으시냐 여쭤봤습니다. 일단 무슨 서비스를 만들고 싶으신지 알아야 제가 할 수 있는 일인지 아닌지 가늠해볼 수 있을 테니까요.

 

이후에 보내주신 기획서를 봤고, 제가 할 만한 일이라고 생각되어 대화를 더 이어나가게 됩니다.

 

사실 플랫폼을 통한 개발 외주에서 가장 어려운 것은 외주를 수주받는 것이라고 생각합니다. 첫 문의조차 서비스를 게시한 지 2주만에 왔고, 그 이후로도 5~6개의 문의가 추가로 왔지만, 실제로 개발에 돌입하게 된 건은 전혀 없었습니다. 지금 생각해보면 제가 이 단 한 건의 외주라도 수주할 수 있었던 건 엄청난 운이 따라주었기 때문이 아닐까 싶습니다. 🥹

 

🤝 모호한 요구사항 구체화하기

의뢰인님이 처음 제시하신 기획서는 다소 두루뭉술했습니다. "이런 기능이 있으면 좋겠어요." 수준이었죠. 여기서 그냥 알겠다고 하면 나중에 큰 문제가 생길 게 불 보듯 뻔했습니다.

 

만약 요구 사항이 애매모호한 채로 개발에 돌입하게 된다면, 개발 도중 또는 개발 이후에 갑자기 의뢰인이 추가 기능이나 기존 기능의 수정을 요구할 수도 있게 됩니다. 처음에 무엇을 어디까지 개발해야 할지, 요구 사항을 명확하게 정해놓지 않았기 때문에 요구를 단번에 거절하기 어렵겠죠. 잘못하면 분쟁으로까지 이어져 상당히 골치아픈 상황이 벌어질 수도 있다고 합니다 🤯

 

그래서 저는 처음 기획서를 받고 나서는 구체화할 필요가 있는 기능, 제가 질문드리고 싶은 것들을 정리해 구글 독스로 공유해드렸습니다. 요구 사항이 명확해질 때까지 질문하고 답변받고를 반복했습니다. 이 과정에서 시간이 조금 소모되었지만, 명확하게 하는 것이 서로에게 안전할 것이라고 생각했습니다. 사실 저도 외주를 받기 전, 인터넷에서 여러 개발 외주 후기를 찾아보았는데요. 모두가 하나같이 하는 말이 "개발 범위를 정확하게 정해놓아라.", "요구 사항을 명확하게 정리해라." 였습니다. 결국에는 제가 해야 하는 일의 범위를 딱 정해두라는 것이죠.

 

요구 사항이 어느 정도 정해지고 나서는 노션에 요구 사항을 예쁘게 정리하여 문서화하였습니다. 무슨 기능을 구현해야 하는지 마지막으로 한 번 더 정리하면서 개발의 방향성을 생각해볼 수 있어서 좋았습니다. 추가로 의뢰인님에게 이를 공유하여 최종적인 컨펌도 받을 수 있었구요.

 

✅ 계획의 중요성

1인 개발 프로젝트라 하더라도, 프로젝트 계획를 세우는 것은 필수적이라고 생각했습니다. 예전에 제가 혼자 개발했던 토이 프로젝트에서 계획의 중요성을 절감했던 적이 있기 때문입니다.

 

제가 말하는 계획이라는 게, 단순히 '언제부터 언제까지 디자인, 그 다음에는 백엔드, 프론트엔드' 식의 기간 분배만을 말하는 게 아닙니다. 상술했다시피 요구 사항을 명확히 하는 것, 즉 MVP에 포함시킬 핵심 기능을 정하는 것도 계획에 포함됩니다. 어떤 언어와 어떤 프레임워크를 쓸지, 아키텍처를 정하는 것도 계획에 포함될 수 있고요. 데드라인을 정하는 것도 중요한 계획 중 하나라고 생각해요.

 

만약 이러한 계획을 전혀 세우지 않고 개발에 돌입하게 된다면요...

 

위 사진은 예전에 제가 혼자 개발했던 토이 프로젝트의 커밋 그래프입니다. 한동한 열심히 하다가 커밋이 끊긴 걸 볼 수 있죠. 매일 밤새워 코딩을 하는데 끝이 안 보였습니다. 버그는 계속 터지고, 진도는 안 나가는 것 같고, 넣고 싶은 기능은 계속 생겨나고... 결국에는 프로젝트를 켜는 횟수가 점점 줄어들다가 아예 포기해버렸습니다.

 

분명 처음 시작할 때는 넘치는 의욕과 함께 즐겁게 코딩할 수 있었습니다. 하지만 곧 길을 잃었습니다. 명확한 기능을 세워놓지를 않으니 개발하면서 계속 새로운 아이디어가 떠올랐습니다. '어? 다크 모드는 요즘 필수지 않나?', '댓글 기능도 넣으면 좋겠다.' 만들어야 할 기능은 계속 늘어나는데 혼자 모든 걸 개발하느라 진전이 되질 않습니다. 출시는 점점 미뤄지다가 결국에는 방치되어 버리는 것이죠.

 

정해진 기간 분배와 데드라인이 없다보니, 전체 과정 중에서 내가 지금 어디쯤 와있는지 알 수가 없었습니다. 체크리스트를 하나씩 지워나가는 과정에서 성취감을 얻고, 이를 원동력 삼아서 개발을 이어나가야 하는데, 그럴 수가 없었습니다. 결국에는 혼자 지쳐 포기하게 된 겁니다.

 

저는 이 토이 프로젝트의 실패를 교훈삼아, 이번 프로젝트에서는 같은 실수를 반복하지 않기 위해 나름의 상세한 계획을 짜려고 노력했습니다.

 

👑 MVP 중심 계획

우선 기간 분배부터 했습니다. 먼저 MVP 개발의 기한을 의뢰인님과 상의하여 정해놓고, 그 기간 안에서 디자인, 백엔드, 프론트엔드를 개발할 기간을 분배하는 것이죠. 개발 기한은 안전하게 제가 처음에 생각한 기간의 약 1.5배 정도로 잡았습니다.

 

저는 노션을 이용하여 이러한 계획을 시각화하였습니다. 계속 이 계획표를 보면서 개발을 하다보니, 길을 잃지 않을 수 있었습니다. 지금 제가 올바른 길을 걷고 있다는 것을 느낄 수 있어 좋았습니다. 또한 정해진 범위 안에서 개발이 진행될 때마다 일종의 쾌감을 느낄 수 있었습니다. 이는 제가 프로젝트를 끝까지 완주할 수 있는 힘이 되었던 것 같습니다.

 

앞서 정한 MVP 기능을 토대로 아키텍처를 확정했습니다. 무슨 프레임워크를 사용할지, 무슨 라이브러리를 쓸지, DB 스키마, 프로젝트 디렉토리 구조는 어떻게 할지 등 지금 정할 수 있는 것은 모두 미리 잡아놓았습니다.

 

만약 아키텍처가 잡혀있지 않다면, 코드를 한 줄 짤 때마다 '상태 관리는 뭘로 하지?', '스타일링은 어떻게 하지?'와 같은 고민을 계속하게 됩니다. 이런 의사 결정과 개발을 번갈아 가면서 하다 보면 피로도가 쌓이게 됩니다. 개발할 때는 개발에만 집중할 수 있도록 하는 것이 효율적인 셈이죠. 그 방법이 바로 아키텍처를 미리 정해두는 것입니다.

 

특히 DB 구조를 미리 짜놓는 것은 필수라고 생각했습니다. 제가 사용할 예정인 Firebase의 데이터베이스인 Firestore의 경우, Collection 구조를 미리 짜놓지 않으면 나중에 쿼리가 불가능하거나 데이터 중복이 심해질 수도 있습니다. 특히 아키텍처 설계 단계에서 '누가 어떤 데이터에 접근할 수 있는지'를 미리 정해두지 않으면, 서비스에 보안 구멍이 생길 수도 있습니다.

 

🚀 구현의 전장 속 세 가지 전략

계획을 짠 이후에는, 디자인과 개발의 연속이었습니다. 약 두 달이라는 시간 동안 1인 개발자로서 디자인, 프론트엔드, 백엔드를 모두 완수해야 했던 이 기간은 제 인생에서 상당히 밀도 높은 시간이었습니다. 이 과정에서 프로젝트를 무사히 완주하게 해 준 저만의 세 가지 핵심 전략을 공유하고자 합니다.

1. 지속적인 소통

외주 개발에서는 의뢰인의 신뢰를 사는 것도 꽤 중요하다고 생각했습니다. 의뢰인 입장에서 거금을 들여 맡긴 프로젝트가 어떻게 돌아가는지 알 수 없다면 큰 불안을 느낄 것이라 생각했습니다. 저는 이 불안을 신뢰로 바꾸기 위해, 과하다 싶을 정도로 지속적인 소통을 이어나갔습니다.

주요 로직이 완성되거나 페이지 한 개를 구현할 때마다, 직접 화면을 녹화하거나 스크린샷을 찍어 크몽 메시지로 전송했습니다. "게시글 작성 구현이 완료되었습니다! 이어서 프로필 페이지 개발 시작 예정입니다!" 같은 식이었죠. 이렇게 시각적인 결과물을 지속적으로 공유하자, 의뢰인님은 저에게 신뢰를 갖게 되신 것 같았습니다.

 

이 과정은 단순히 보고를 위한 것이 아니라, 피드백 주기를 짧게 유지하는 효과도 있었습니다. 개발이 한참 진행된 후에 수정을 요청받는 것이 아니라, 중간 단계에서 즉시 방향을 수정할 수 있어 시간 낭비를 막는 장치가 되었습니다.

2. AI와의 협업

제가 디자인부터 풀스택 개발까지 혼자 해낼 수 있었던 배경에는 AI라는 강력한 사수가 있었습니다. 개발 과정에서의 모든 결정과 구현을 혼자 하기에는 솔직히 벅찼습니다. 다행히도 저는 대학생 신분이었어서 GitHub Pro를 무료로 사용할 수 있었고, 여기에는 Copilot Pro 요금제도 포함되어 있었습니다. 정말 넉넉한 한 달 사용량 덕분에 개발 내내 코파일럿 AI의 도움을 톡톡히 받을 수 있었습니다. 잠시 딴 얘기를 하자면, 대학생 분들은 무조건 GitHub Student Pack 받으시길 강력히 추천드립니다. 꼭 개발 뿐만이 아니어도, 깃허브 홈페이지에서 고성능 AI 모델을 무료로 사용할 수 있게 됩니다!!!

 

저는 AI를 코드 리뷰어로 적극 활용했습니다. 아시는 분들은 아실테지만, 기능을 구현하고 메인 브랜치에 PR을 올리면 코파일럿이 코드 리뷰를 해주는 기능이 있습니다. 저는 이 기능을 이번 프로젝트에서 처음 사용해봤는데 이거 진짜 물건입니다. 제가 수정한 코드들을 분석해서 진짜 사람처럼, 아니 웬만한 사람보다 더 꼼꼼하게 리뷰를 달아줍니다. 코드를 어떻게 수정할지도 같이 알려주고, 이걸 바로 반영할 수도 있습니다.

이뿐만 아니라, 반복적인 코드 작성도 AI한테 맡겨 구현 시간을 꽤 단축할 수 있었습니다. 정형화된 스타일링 코드나, 디자인을 코드로 옮기는 단순한 작업은 대부분 AI한테 맡기고, 저는 데이터 흐름 설계나 최적화 등의 더 고차원적인 문제에 집중했습니다. 결과적으로 예상했던 기간보다 훨씬 빠른 시간 내에 기능을 완성할 수 있었습니다. 결국 AI는 저에게 단순한 도구가 아니라, 1인 개발의 생산성을 2~3배 뻥튀기시켜주는 치트키였습니다.

3. 지속적인 계획 확인

개발하다 보면 어느덧 처음 세웠던 계획은 잊고, 당장 만들고 싶은 기능에만 매몰되기 쉽습니다. 저는 예전 토이 프로젝트의 실패를 반복하지 않기 위해, 매일 개발을 시작하기 전과 마무리하기 전, 반드시 투두 리스트를 확인했습니다. '오늘 내가 짠 코드가 이번 기능 구현을 달성하는 데 기여했는가?'라고 자문했습니다. 개발하면서 '이 기능을 더 예쁘게 만들 수 있을 것 같은데?'라는 생각이 들 때마다, 계획표를 보며 스스로를 다잡았습니다.

 

Done is better than perfect.

 

체크리스트에서 항목을 하나씩 지워나갈 때마다 느낀 성취감들은, 제가 계속해서 개발에 집중할 수 있도록 하는 원동력이 되었습니다.

 

🤑 마무리 및 정산

결국 이 세 가지가 맞물려 돌아가면서, 무모해 보였던 첫 외주 도전을 성공적으로 마무리할 수 있었습니다. 정산 신청을 하고 며칠 뒤 제 계좌에 실제로 찍힌 정산금은 제가 이제껏 만져본 돈 중 가장 무게감이 컸습니다. 동시에 제가 가진 기술로 이 정도의 수익을 창출했다는 사실이 신기하기도 하였습니다.

 

저의 코드가 누군가에게 가치를 제공하고 실제 수익을 창출하는 경험은 정말 짜릿한 경험이었습니다. 하지만, 돈도 돈이지만, 저에 대한 확신을 어느정도 갖게 될 수도 있었습니다. '과연 내가 학교 밖에서도 통할까?'라는 의문이 '내 코드는 시장에서도 어느 정도 경쟁력이 있다.'라는 약간의 자신감으로 바뀌었습니다.

 

물론 이번 외주는 운이 좋았던 면이 큽니다. 그래서 저는 여기서 안주하지 않고, 이번 프로젝트를 초석 삼아 저의 능력을 더 키우고 더 매력적인 포트폴리오를 만들기 위해 준비하고 있습니다. 복학 후에도 기회와 시간이 된다면, 외주 업무를 받으면서 개발자로서의 커리어를 키워보고 싶네요.

 

마치며: "일단 시작해보세요"

이 글을 읽는 대학생 개발자분들 중에도 외주를 고민하는 분들이 있으시다면, "일단 자신의 프로젝트를 예쁘게 포장해서 올려봐라"고 말씀드리고 싶습니다. 직접 의뢰인과 부딪히며 배우는 것들은 학교에서 절대 배울 수 없는 경험이라고 생각합니다. 저 역시 이제 2학년으로 올라가는 복학생에 불과하고, 2년 전만 해도 리액트를 그렇게 잘 다루진 못 했습니다. 군대에서 차근차근 공부하고 토이 프로젝트를 만들며 실력을 쌓아올린 것이죠.

 

물론 쉽지 않았습니다. 계속되는 코딩에 지치기도 했고, 중간에 몇 번 바뀐 요구사항에 짜증나기도 했습니다. 하지만 결국엔 그러한 과정들은 제가 한 층 더 성장할 수 있었던 좋은 계기가 되었습니다.

 

생각보다 기회는 가까이 있습니다. 긴 글 읽어주셔서 감사합니다.