비개발 대표의 첫 개발자 채용 가이드 - 이력서에서 뭘 봐야 하나요?

 

"이력서를 봐도 도통 모르겠어요"

비개발 대표님들과 이야기하다 보면 가장 많이 듣는 말입니다.

 

"React 5년 경력이라는데 좋은 건가요?"

"Github 스타 1,000개면 실력이 좋은 건가요?"

"대기업 출신인데 우리 스타트업에 맞을까요?"

 

저도 처음 개발자를 채용할 때 비슷했습니다. 기술 스택 나열만 잔뜩 있는 이력서를 보며 "이게 대체 무슨 뜻이지?" 싶었죠. 7년간 20,000명이 넘는 개발자를 면접하고, 그중 100명 정도와 함께 일하면서 배운 게 있습니다.

 

이력서에서 정말 봐야 할 건 화려한 스펙이 아니라, 그 사람이 우리 회사에서 실제로 일할 수 있는 사람인지 판단할 수 있는 단서들입니다.

첫 번째 개발자, 왜 가장 중요한가

첫 개발자 채용은 그냥 채용이 아닙니다. 회사의 기술 DNA를 결정하는 순간입니다.

 

첫 개발자가 작성한 코드는 회사의 기반이 됩니다. 두 번째, 세 번째 개발자는 첫 개발자가 만든 구조 위에서 일하게 되죠. 첫 개발자가 설정한 개발 문화와 기준이 팀 전체의 기준이 됩니다. 그래서 첫 개발자 선택을 잘못하면, 나중에 갈아엎는 비용이 어마어마합니다.

 

저희도 초기에 "빨리 만들 수 있는 사람"만 보고 채용했다가 큰 코를 다쳤습니다. 6개월 만에 시스템 전체를 다시 만들어야 했고, 그 과정에서 3개월 이상 신규 기능 개발을 멈춰야 했습니다. 첫 단추를 잘 끼우는 게 얼마나 중요한지 뼈저리게 느꼈죠.

이력서에서 정말 봐야 하는 것들

1. 프로젝트 설명의 구체성

기술 스택 나열보다 중요한 건 프로젝트에서 무엇을 했는지입니다.

별로인 이력서: "React, Node.js, MongoDB를 사용한 웹 서비스 개발

• 프론트엔드 개발
• 백엔드 API 개발"

좋은 이력서: "월 10만 사용자의 예약 플랫폼 개발

• 예약 동시성 문제 해결로 오버부킹 90% 감소
• 페이지 로딩 속도 3초 → 0.8초 개선
• 사용 기술: React, Node.js, Redis"

차이가 보이시나요? 좋은 이력서는 어떤 문제를 해결했는지, 어떤 임팩트를 만들었는지 구체적으로 적혀있습니다. 단순히 기술을 사용했다는 것보다, 그 기술로 비즈니스 문제를 해결했다는 게 훨씬 중요합니다.

2. 회사 규모와 본인의 역할

같은 "3년 경력"이라도 환경에 따라 완전히 다른 개발자입니다.

대기업 3년 개발자:

• 명확한 업무 분담과 프로세스
• 안정적인 시스템과 코드 리뷰
• 좁지만 깊은 전문성

스타트업 3년 개발자:

• 처음부터 끝까지 직접 결정
• 빠른 변화와 불확실성 경험
• 넓지만 얕을 수 있는 경험

어느 쪽이 더 좋다는 게 아닙니다. 우리 회사 상황에 맞는 사람을 찾아야 합니다. 초기 스타트업이라면 모호함을 견디고 스스로 결정할 수 있는 사람이 필요합니다. 어느 정도 규모가 있다면 체계적인 개발 경험이 있는 사람이 더 적합할 수 있죠.

 

이력서에서 "팀 규모", "담당 범위", "의사결정 권한" 같은 표현을 찾아보세요. "5명 팀에서 프론트엔드 전체 담당"과 "50명 팀에서 특정 모듈 개발"은 완전히 다른 경험입니다.

3. 프로젝트의 지속성

한 회사나 프로젝트에서 얼마나 오래 일했는지도 중요한 신호입니다.

경고 신호:

• 1년 이하의 짧은 경력이 여러 번 반복
• 프로젝트마다 사용 기술이 완전히 다름
• 회사 이름 없이 프로젝트만 나열

물론 이직이 나쁜 건 아닙니다. 하지만 너무 자주 이동했다면 이유를 물어봐야 합니다. 스타트업은 인내심이 필요한 곳입니다. 어려운 순간을 함께 견뎌낼 수 있는 사람인지 파악하는 게 중요합니다.

 

반대로 좋은 신호는 한 프로젝트를 처음부터 끝까지 완성한 경험입니다. "베타 출시부터 월 사용자 10만 달성까지"처럼 성장 과정을 함께한 경험이 있다면, 그 사람은 장기적인 관점으로 일할 줄 아는 사람입니다.

4. 커뮤니케이션 능력의 힌트

이력서 자체가 커뮤니케이션 능력을 보여줍니다.

좋은 신호:

• 비전공자도 이해할 수 있게 설명
• 숫자와 지표로 성과를 표현
• 명확한 구조와 읽기 쉬운 문장

경고 신호:

• 전문 용어와 약자만 가득
• 두서없는 나열과 중복된 내용
• 오타와 맞춤법 오류

첫 개발자는 나중에 개발자를 채용하고, 비개발 팀원들과 소통하고, 투자자에게 기술을 설명해야 할 수도 있습니다. 이력서를 알아보기 어렵게 쓴 사람은 실제로도 소통이 어려울 가능성이 높습니다.

기술 스택, 어떻게 볼 것인가

이제 피할 수 없는 질문입니다. "React가 좋은가요, Vue가 좋은가요?"

솔직히 말씀드리면, 초기 스타트업에서는 별로 중요하지 않습니다. 정말로요.

기술 스택보다 중요한 것

학습 능력: 새로운 기술을 빠르게 배울 수 있는가? 문제 해결: 막혔을 때 스스로 답을 찾을 수 있는가? 기본기: 프로그래밍의 근본 원리를 이해하는가?

 

좋은 개발자는 React를 모르더라도 2주면 배웁니다. 하지만 문제 해결 능력이나 기본기는 단기간에 키울 수 없습니다.

이력서에서 이런 표현을 찾아보세요:

• "Python으로 개발하다가 프로젝트 필요에 따라 Go 학습"
• "레거시 PHP 코드를 Node.js로 마이그레이션"
• "새로운 프레임워크 도입을 위해 팀 스터디 진행"

기술 변화에 유연하게 대응한 경험이 있다면, 우리 회사에서도 필요한 걸 배워서 해낼 것입니다.

단, 이것만은 확인하세요

우리 서비스와 완전히 동떨어진 기술만 다뤄본 사람은 조심해야 합니다.

 

웹 서비스를 만들어야 하는데 임베디드만 10년 한 분을 채용하면? 아무리 뛰어난 개발자라도 학습 곡선이 너무 가파릅니다. 비슷한 도메인(웹, 모바일, 백엔드 등)에서 일한 경험이 있는지는 확인하세요.

이런 이력서는 조심하세요

1. 화려한 스펙만 가득한 이력서

"Google, Microsoft 출신"

"해커톤 10회 수상"

"오픈소스 컨트리뷰터"

 

물론 인상적입니다. 저 또한 이러한 이력서 유형에서 자유롭지 못합니다. 하지만 스타트업에 필요한 건 화려한 이력이 아니라 굴러갈 수 있는 사람입니다. 큰 회사에서 특정 분야만 깊게 팠던 사람은 스타트업의 모호함과 빠른 변화를 힘들어할 수 있습니다.

 

면접에서 꼭 물어보세요: "불확실한 상황에서 빠르게 결정하고 실행해본 경험이 있나요?"

2. 기술 스택이 너무 많은 이력서

"React, Vue, Angular, Svelte, React Native, Flutter, Swift, Kotlin..."

 

3년 경력에 15개 기술 스택이 있다면? 각각 얼마나 깊이 알까요? 스타트업에서는 넓고 얕은 지식보다, 한두 가지를 깊이 아는 게 더 유용합니다. 문제가 생겼을 때 근본 원인을 찾고 해결할 수 있어야 하니까요.

3. 성과가 전혀 없는 이력서

"담당 업무: 코딩, 테스트, 배포"

 

3년을 일했는데 달성한 게 아무것도 없다면, 그냥 시킨 일만 한 사람일 수 있습니다. 첫 개발자는 스스로 문제를 찾고 해결하는 사람이어야 합니다. 최소한 "이런 걸 개선했다", "이런 문제를 해결했다"는 이야기가 하나라도 있어야 합니다.

실전 팁: 이력서 보는 5분 체크리스트

이력서를 받았을 때 5분 안에 이것만 확인하세요.

 

1분: 전체 훑어보기

• 이력서가 깔끔하고 읽기 쉬운가?
• 경력 기간이 합리적인가?
• 우리 서비스와 관련된 경험이 있는가?

2분: 최근 프로젝트 자세히 보기

• 무엇을 만들었는지 구체적으로 설명하는가?
• 숫자나 지표로 성과를 표현하는가?
• 비즈니스 임팩트를 이해하고 있는가?

2분: 위험 신호 찾기

• 너무 짧은 경력이 반복되는가?
• 성과 없이 업무만 나열하는가?
• 커뮤니케이션이 어려울 것 같은가?

5분 후 "면접 볼 만하다"는 생각이 들면 다음 단계로 넘어가세요. 확신이 안 서면 과감히 패스하는 것도 용기입니다.

이력서로 알 수 없는 것들

하지만 이력서만으로는 절대 알 수 없는 것들이 있습니다.

 

실제 코딩 실력: 이력서는 얼마든지 포장할 수 있습니다.

문제 해결 과정: 어떻게 생각하고 접근하는지는 봐야 압니다.

팀워크와 태도: 함께 일하기 편한 사람인지는 대화해봐야 알 수 있습니다.

우리 회사와의 핏: 가치관과 일하는 방식이 맞는지 확인이 필요합니다.

 

그래서 이력서는 시작일 뿐입니다. 이력서로 명백히 안 맞는 사람을 걸러내고, 면접에서 진짜 중요한 것들을 확인해야 합니다.

면접으로 이어지는 이력서의 조건

이력서 평가의 목표는 완벽한 사람을 찾는 게 아닙니다. 만나서 대화해볼 가치가 있는 사람을 찾는 것입니다.

이런 이력서라면 면접 기회를 주세요:

• 우리 서비스와 유사한 도메인 경험이 있고
• 프로젝트에서 명확한 성과를 만들어봤으며
• 비즈니스 관점으로 기술 문제를 설명할 수 있고
• 학습하고 성장하려는 의지가 보이는

완벽하지 않아도 괜찮습니다. 우리 회사에서 성장할 수 있는 잠재력이 보이면 됩니다.

마지막 조언: 혼자 결정하지 마세요

첫 개발자 채용은 너무 중요한 결정이라 혼자 하기 어렵습니다.

 

주변에 개발자 지인이 있다면 이력서를 보여주고 조언을 구하세요. 기술 자문이나 멘토가 있다면 면접에 참여해달라고 요청하세요. 아니면 외부 CTO나 시니어 개발자를 단기로 고용해서 채용 과정을 도와달라고 하는 것도 좋은 방법입니다.

 

저도 초기에 선배 CTO님께 계속 물어봤습니다. "이 이력서 어때 보이세요?" "이런 경력이면 괜찮을까요?" 부끄러운 줄 알면서도 물어봤고, 그 덕분에 좋은 분들을 모실 수 있었습니다.

정리하며

비개발 대표가 개발자 이력서를 보는 건 외국어 문서를 읽는 것처럼 느껴질 수 있습니다. 하지만 기술 하나하나를 이해할 필요는 없습니다.

 

정말 봐야 하는 건:

• 구체적인 문제 해결 경험
• 비즈니스 임팩트에 대한 이해
• 지속적인 학습과 성장 의지
• 우리 회사 상황에 맞는 경험

그리고 기억하세요. 이력서는 시작일 뿐입니다. 좋은 이력서가 좋은 개발자를 보장하지 않고, 평범한 이력서 뒤에 훌륭한 개발자가 숨어있을 수도 있습니다.

---

이 글은 '모두의 CTO' 시리즈의 다섯 번째 글입니다. 스타트업 기술 조직과 리더십에 대한 솔직한 이야기를 이어가겠습니다.