이력서에 사이드 프로젝트를 다섯 개 적었는데 면접에서 아무도 묻지 않았다면, 프로젝트가 부족해서가 아닙니다. 결론부터 말씀드리겠습니다. 개발자 사이드 프로젝트가 힘을 잃은 이유는 완성도가 아니라 신호의 값이 떨어졌기 때문입니다. 무언가를 만들었다는 사실은 이제 지원자를 구분해주지 않습니다. 지금 변별력을 만드는 것은 만든 결과물이 아니라, 무엇이 잘못됐고 그때 무엇을 했는지의 기록입니다.
개발자 사이드 프로젝트의 신호 값이 떨어진 이유
경제학자 마이클 스펜스가 1973년에 정리한 신호 이론의 핵심은 단순합니다. 신호는 비용이 들 때만 정보를 전달합니다. 누구나 쉽게 흉내 낼 수 있는 신호는 아무것도 구분하지 못합니다.
동작하는 웹 서비스를 하나 만드는 비용이 어떻게 변했는지 보겠습니다. 깃허브 옥토버스 2025 보고에 따르면 2025년 한 해 동안 새 저장소 1억 2,100만 개가 만들어졌습니다. 분당 230개꼴입니다. 같은 해에 개발자 3,600만 명이 새로 합류했고, 이들 중 80%가 가입 첫 주에 코파일럿을 사용했습니다.
주말 이틀이면 로그인과 결제가 붙은 데모가 나옵니다. (저도 만들어 봤고, 놀랍도록 빨랐습니다.) 문제는 그 데모가 저를 설명해주지 않는다는 것입니다. 채용 담당자 입장에서 보면 이력서에 적힌 “OO 서비스 개발”이라는 한 줄은 이제 튜토리얼을 따라간 사람과 시스템을 설계한 사람을 구분하지 못합니다. 신호가 싸지면 신호로서의 기능이 사라집니다.
시장이 부족해하는 것은 생산이 아니라 검증입니다
그러면 무엇이 비싼 신호로 남았을까요. 스택 오버플로 2025 개발자 설문이 힌트를 줍니다. 응답자의 84%가 AI 도구를 쓰거나 쓸 계획이라고 답했지만, 결과물의 정확성을 신뢰하지 않는다는 응답이 46%로 전년 31%에서 크게 올랐습니다. 신뢰한다는 응답 33%보다 높습니다. 가장 큰 불만으로는 66%가 “거의 맞지만 정확히는 틀린” 답을 꼽았고, 45%는 AI가 만든 코드를 디버깅하는 데 시간이 더 든다고 답했습니다.
이 숫자들이 말하는 바는 분명합니다. 코드를 만들어내는 능력은 흔해졌고, 그 코드가 맞는지 판별하는 능력이 병목이 됐습니다. AI가 작성한 코드를 누가 검증하는가라는 질문이 팀마다 실무 과제로 올라온 이유도 같습니다.
사이드 프로젝트가 증명해야 할 것도 이 지점으로 옮겨갔습니다. 만들 수 있다는 증거가 아니라, 만든 것이 틀렸을 때 알아챌 수 있다는 증거입니다.
면접이 실제로 채점하는 것은 결정입니다
채용 연구 쪽 근거도 같은 방향을 가리킵니다. 새킷 연구진이 2022년에 인사선발 도구들의 메타분석 추정치를 다시 계산했을 때, 기존 값들이 범위 축소 보정 과정에서 과대추정되어 있었다는 점이 드러났습니다. 그리고 재계산 이후에도 직무 특화 도구인 구조화 면접이 가장 강한 예측력을 유지했습니다.
구조화 면접이 무엇을 묻는지 떠올려 보시면 됩니다. 결과물이 아니라 상황과 행동을 묻습니다. 어떤 제약이 있었고, 무엇을 고려했고, 무엇을 택했고, 그래서 어떻게 됐는지. 코딩 테스트를 통과하고도 떨어지는 이유가 여기 있습니다. 정답 코드는 채점 항목의 일부일 뿐이고, 나머지는 그 코드에 도달한 경로입니다.
사이드 프로젝트는 이 경로를 보여주기에 원래 가장 좋은 재료입니다. 회사 프로젝트와 달리 모든 결정이 지원자 것이기 때문입니다. 그런데 대부분의 이력서는 그 결정을 지우고 결과만 남깁니다.
| 이력서에 자주 적히는 것 | 왜 변별이 안 되는가 | 대신 남길 것 |
|---|---|---|
| 사용 기술 스택 나열 | 튜토리얼 따라간 사람과 구분 불가 | 그 선택으로 무엇을 포기했는가 |
| 완성된 데모 링크 | 만드는 비용이 급락함 | 폐기한 버전과 폐기한 이유 |
| 깃허브 스타·배포 URL | 운영했는지를 증명하지 못함 | 장애 한 건과 대응 과정 |
| ”OO 기능을 구현했습니다” | 모든 지원자가 같은 문장을 씀 | 지표의 전후 변화 |
남겨야 할 세 가지 흔적
정리하면 실행 항목은 셋입니다.
첫째, 코드보다 문제를 먼저 적습니다. 무엇이 불편했고 그것이 왜 기존 도구로 해결되지 않았는지를 한 문단으로 쓰지 못하면, 그 프로젝트는 기술 연습입니다. 예전에 국내 수제 맥주 정보가 블로그와 커뮤니티에 흩어져 있는 게 불편해서 아카이브를 만든 적이 있습니다. 지금 돌아보면 코드는 평범했지만, 면접에서 가장 오래 이야기한 프로젝트는 그것이었습니다. 문제를 설명할 수 있으면 그다음 질문이 자연스럽게 따라옵니다.
둘째, 한 번은 실제 사용자에게 내보냅니다. 로컬에서 도는 코드는 가정 위에서만 정확합니다. 배포하는 순간 시간대, 네트워크 지연, 중복 클릭, 이상한 입력값이 들어옵니다. 이 경험은 흉내 낼 수 없습니다. AI에게 “동시성 이슈를 처리해줘”라고 요청할 수는 있지만, 어느 지점에서 그 요청을 해야 하는지는 겪어본 사람만 압니다.
셋째, 한 번은 일부러 부러뜨려 봅니다. 개인 프로젝트에 결제와 포인트 기능을 붙였을 때, 저는 같은 계정으로 결제를 두 번 빠르게 눌러 봤습니다. 포인트가 두 번 차감되지 않고 잔액이 음수로 내려갔습니다. (테스트 환경이라 다행이었습니다.) 그 뒤에 낙관적 락을 걸고 거래 이력을 스냅샷으로 남기도록 구조를 바꿨습니다. 이력서에는 “결제 기능 구현” 대신 “동시 요청 시 잔액 정합성 문제를 재현하고 낙관적 락으로 해결”이라고 적었고, 면접 질문의 절반이 그 한 줄에서 나왔습니다.
AI 도구를 쓰는 프로젝트라면 검증 장치 자체가 재료가 됩니다. 문서 요약 에이전트를 만들면서 요약 품질을 사람이 매번 눈으로 보는 게 불가능해지자, 평가 기준을 정의하고 모델이 자기 출력을 채점한 뒤 기준 미달이면 다시 생성하는 루프를 붙인 적이 있습니다. 흥미로운 부분은 모델 성능이 아니라 기준을 어떻게 정의했느냐였고, 실제로 그 질문을 받았습니다.
면접에서 사이드 프로젝트를 말하는 세 문장
말하는 형식도 정해두면 편합니다. 프로젝트당 세 문장이면 충분합니다.
- 문제: 무엇이 불편해서 시작했는가 (한 문장, 기술 용어 없이)
- 선택과 대가: 어떤 대안이 있었고 무엇을 포기했는가
- 결과와 다음: 무엇이 얼마나 달라졌고, 다시 만든다면 무엇을 바꿀 것인가
세 번째 문장을 빠뜨리는 분이 많습니다. 이 문장이 없으면 프로젝트는 과거형으로 끝나고, 있으면 지원자가 자기 코드를 평가할 줄 안다는 증거가 됩니다. 장애 대응을 복구가 아니라 학습으로 다루는 팀이 강해지는 것과 같은 이유입니다. 사후에 무엇을 배웠는지 말할 수 있는 사람은 다음 사고에서 다르게 행동합니다.
만든 것이 아니라 겪은 것을 파십시오
사이드 프로젝트를 하나 더 시작하기 전에, 이미 만든 것 중 하나를 골라 배포하고 한 달만 운영해 보시길 권합니다. 새 저장소를 만드는 비용은 거의 0이 됐지만, 운영하며 깨지는 경험의 비용은 그대로입니다. 값이 남아 있는 신호는 그쪽입니다.
주니어 개발자의 포트폴리오를 다룰 때도 같은 이야기를 했지만, 요점은 개수가 아니라 깊이입니다. 저장소 다섯 개보다 장애 한 번을 제대로 복기한 저장소 하나가 면접에서 더 많은 말을 만듭니다. 코드는 이제 누구나 만들 수 있습니다. 그 코드가 틀렸다는 사실을 먼저 알아채는 사람은 여전히 드뭅니다.
참고 자료
- Michael Spence, “Job Market Signaling”, The Quarterly Journal of Economics, 1973
- Stack Overflow, “2025 Developer Survey: AI”, 2025
- GitHub, “Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1”, 2025
- Paul R. Sackett, Charlene Zhang, Christopher M. Berry & Filip Lievens, “Revisiting Meta-Analytic Estimates of Validity in Personnel Selection”, Journal of Applied Psychology, 2022
