이직 준비를 시작하면 "지금 회사에서 한 일만으로 어필이 될까?" 하는 고민이 생기곤 해요. 막상 가고 싶은 회사의 JD를 열어보면 우리 회사에서는 안 써본 기술 스택이 절반이고요. 그래서 많은 분들이 야간과 주말에 사이드 프로젝트로 격차를 메우려 해요.
그런데 솔직히 말하면, 모든 사이드 프로젝트가 이직에 도움이 되지는 않아요. 이 글에서는 합격을 부르는 사이드 프로젝트와 그렇지 못한 사이드 프로젝트의 차이를 데이터와 후기를 바탕으로 정리하고, 주제 선정부터 결과물 정리, 이력서 어필까지 단계별로 살펴봅니다.
1. 사이드 프로젝트가 이직에서 갖는 진짜 무게
먼저 솔직하게 짚고 가요. 사이드 프로젝트는 "기회를 만들어주는 도구"이지, 실무 경험을 대체하는 도구가 아니에요.
실제 후기 하나를 볼게요. 한 개발자는 사이드 프로젝트를 바이럴시킨 후 스타트업 PO들에게서 직접 채용 커피챗 요청을 받았고, 직접 지원한 약 50곳 중 10%대의 서류 합격률을 만들어냈어요[2]. 분명한 기회 창출 효과예요. 다만 같은 후기는 기술 면접 단계에서 회사 프로젝트 경험 부족이 드러나 탈락하는 경우가 많았다고 솔직하게 적고 있어요[2].
게다가 사이드 프로젝트 자체는 흔한 활동이에요. 2024 Stack Overflow Developer Survey 기준 약 68%의 개발자가 취미로 코딩을 하고, 약 40%는 학습·전문성 개발 목적으로 일 외 코딩을 한다고 답했어요[4]. 즉 "사이드 프로젝트가 있다"는 사실 자체로는 차별화가 어렵고, 품질로 승부해야 한다는 뜻이에요.
핵심 메시지: 사이드 프로젝트는 "다음 직무에 필요한 역량의 증거"일 때만 이직에 통해요.
2. 합격을 부르는 사이드 vs 그렇지 못한 사이드
면접관들이 명시적으로 평가하는 기준이 있어요. 한 면접관 후기에 따르면 가치 있게 보는 글은 "사이드 프로젝트의 과정, 그중에서 어떤 결정을 어떤 생각으로 했는지 드러내는 글"이에요[3]. 이 기준을 그대로 가져와 비교 표로 정리하면 다음과 같아요.
항목 | 합격 부르는 사이드 | 그렇지 못한 사이드 |
|---|---|---|
주제 | 실제 문제 해결 | 튜토리얼/강의 클론 |
사용자 | 본인 외 실제 유저 존재 | 본인만 사용 / 미배포 |
기술 스택 | 지원 직무 JD와 정렬 | 무관하거나 자랑형 남발 |
결과물 | 배포 URL + 측정 지표 | 코드만 GitHub에 존재 |
의사결정 기록 | README에 트레이드오프·실패 포함 | 결과만 나열 |
트러블슈팅 | 추정·검증·재발 방지까지 기술 | 해결 결과만 한 줄 |
면접관 입장에서는 "강의를 따라했다"는 신호와 "스스로 결정했다"는 신호가 매우 다르게 읽혀요[3]. 그래서 단순 To-do 앱이나 강의 따라치기는 의미가 적어요.
3. 주제 선정 — 결과의 80%를 결정하는 단계
뭘 만들지가 정해지면 절반 이상은 끝난 셈이에요. 다음 세 가지 기준을 권해요.
1) 지원 직무의 JD와 기술 스택을 정렬하세요
가고 싶은 회사 3~5곳의 JD를 열어 공통적으로 등장하는 키워드 1~2개를 메인 스택으로 잡으세요. 백엔드라면 Redis 큐, 동시성 제어, 메시지 브로커 같은 것이요. 데이터 직군이라면 dbt, Airflow, BigQuery 같은 키워드가 자주 보일 거예요.
2) "실제로 누가 쓸 작은 문제"를 고르세요
거대한 SaaS를 만들기보다, 본인·주변·특정 커뮤니티의 작은 페인 포인트를 선택하세요. 사용자가 단 10명이라도 실제로 돌아가는 서비스라면 평가는 완전히 달라져요. 채용 시장에서 좋은 회사로 꼽히는 곳들의 공통 특징은 "유의미한 트래픽이 발생하고, 코드리뷰·배포 자동화가 구축되고, 코드 품질에 관심이 있는" 환경이에요[5]. 이 신호를 사이드에서도 흉내낼수록 평가가 좋아져요.
3) 시간 제약과 완결성을 먼저 결정하세요
6개월 짜리 야심작보다 2~4주에 끝까지 배포하는 작은 프로젝트가 훨씬 강해요. "추후 배포 예정"이라고 적힌 README는 채용 담당자에게는 "안 한 것"과 같아요.
4. 결과물 정리법 — README가 곧 포트폴리오예요
코드는 평가자가 모두 읽지 않아요. 평가는 대부분 README 한 페이지로 이루어진다고 봐도 무방해요. 백엔드 포트폴리오 가이드들이 공통으로 권하는 표준 구성은 다음과 같아요[1].
프로젝트 1줄 요약과 풀려고 한 문제
Demo / 배포 URL (없으면 평가 자체가 어려움)
제작 기간 & 참여 인원
사용 기술 스택과 선택한 이유
아키텍처/ERD 다이어그램
핵심 기능
트러블슈팅 경험 (추정 → 시도 → 검증 → 재발 방지)
정량 지표 (응답 시간, 트래픽, 쿼리 수 등)
회고와 한계, 다음 스텝
핵심은 "무엇을 했고, 어떻게 해결했고, 왜 그 기술을 선택했는지"를 보여주는 것이에요[1]. 면접관은 결과보다 추정·소거·확신·검증의 사고 과정을 보고 싶어해요[3]. 그러니 README에 "처음에는 X로 만들었는데 Y 문제가 생겨서 Z로 바꿨다" 같은 흔적을 남겨두세요.
수치는 작아도 괜찮아요. "평균 응답 200ms → 60ms", "월간 활성 사용자 12명", "DB 쿼리 N+1 → 1로 감소" 같은 측정 가능한 숫자 1~2개면 충분해요.
5. 이력서·면접에서 어필하는 프레이밍 (X-Y-Z 공식)
좋은 사이드 프로젝트를 만들었어도, 이력서 한 줄로 옮기지 못하면 평가받지 못해요. 추천하는 형식은 X-Y-Z 공식이에요.
X(무엇)을 만들어 Y(어떻게/지표)를 달성했고 Z(임팩트)를 가져왔다.
Before (약함):
Vue.js로 매칭 서비스 개발
After (강함):
동네 모임 매칭 웹 서비스 배포(X), Redis 기반 비동기 큐로 평균 응답 200ms→60ms 개선(Y), 베타 사용자 12명 대상 주간 매칭 성사율 70% 기록(Z)
이력서에 옮길 때는 트리업의 경험 관리 기능처럼 사이드 프로젝트의 의사결정·지표를 한 곳에 모아두면, 회사별 JD에 맞춰 이력서 빌더에서 매번 새로 쓰지 않고 재조합하기 편해요.
면접 대비도 같은 맥락이에요. 면접관은 결과보다 "왜 그 기술을 선택했나"를 거의 반드시 물어요[3]. 트레이드오프 두세 가지를 미리 정리해두세요. 예: "동시성을 처리해야 해서 Node.js의 비동기보다 백프레셔 제어가 쉬운 Redis 큐를 선택했고, 트래픽이 더 커졌다면 Kafka도 검토했을 것"처럼요.
6. 자주 빠지는 함정 5가지
마지막으로, 이력서 광탈을 부르는 흔한 실수예요.
튜토리얼/강의 카피 프로젝트 — 강의 그대로면 면접관이 즉시 알아채요[3].
미배포 + 코드만 GitHub — Demo URL 없으면 평가 대상에서 빠지기 쉬워요[1].
기술 스택 자랑형 — 작은 서비스에 마이크로서비스·Kubernetes 남발은 오히려 감점.
마지막 커밋 1년 전 — 한 번 만들고 방치된 흔적은 신뢰를 떨어뜨려요.
JD와 무관한 주제 — 백엔드 지원에 화려한 디자인 토이 프로젝트만 있다면 임팩트가 약해요.
면접관들이 부정적으로 평가한다고 명시한 글의 패턴은 "다른 블로그 복붙, 하루하루 학습 일기, 두서 없는 정리"예요[3]. README도 마찬가지예요.
마무리
정리하면 이렇게 다섯 가지예요. 작은 문제, JD와 정렬된 스택, 끝까지 배포된 결과물, 측정 가능한 지표, 의사결정의 흔적. 이 다섯을 갖추면 사이드 프로젝트는 "취미"가 아니라 "다음 직무의 증거"가 돼요.
그리고 잊지 마세요. 한 후기의 결론처럼 "개발자는 결국 개발로 승부"해요[2]. 사이드 프로젝트는 회사가 나를 한 번 더 보게 만드는 강력한 다리이지, 실무 역량의 대체품은 아니에요.
처음부터 거창할 필요는 없어요. 작은 프로젝트라도 끝까지 배포하고, 결정의 흔적을 README에 남기고, 한두 가지 숫자로 정리해두세요. 그 흔적이 모여 가고 싶은 회사로 가는 가장 강력한 증거가 돼요. 다음 직무를 미리 그려보고 싶다면 트리업의 커리어 탐색에서 직무별 핵심 역량을 살펴보는 것도 좋은 출발점이에요.
