개발자에게 영업이란: 프로덕트 만들어봤자 결국 영업 안 되면 무쓸모구나
- "아무리 프로덕트 만들어봤자 결국은 영업 안 되면 무쓸모구나"는 거의 모든 개발자 창업자가 6개월 안에 도달하는 결론입니다
- 영업은 양복 입고 전화 돌리는 것이 아닙니다. 문제를 겪는 사람을 찾고, 내 해결책을 연결하는 행위 전부가 영업입니다
- 코드를 짜는 시간과 사람에게 말을 거는 시간의 비율을 바꾸는 것만으로도 결과가 달라집니다
Threads에서 본 글이 있습니다.
댓글이 아니라, 거의 모든 개발자 창업자의 회고록입니다.
3개월 동안 기능을 만들고, 배포하고, 랜딩페이지도 올렸습니다. 그런데 유저가 0명입니다.
코드가 문제가 아니었습니다. 아무도 이걸 몰랐던 것이 문제였습니다.
개발자가 영업을 싫어하는 진짜 이유
"영업"이라는 단어를 들으면 떠오르는 이미지가 있습니다.
- 저녁 먹는데 걸려오는 인터넷/TV 가입 권유 전화
- 아는 친구한테 종신보험 가입하라는 연락
- 길거리에서 "도를 아십니까"
- 새벽 3시까지 소주방에서 진탕 마시고 서류에 사인 받고 대리운전 잡는 영업사원
개발자들이 영업을 거부하는 이유는 영업 자체가 싫어서가 아닙니다. 저 이미지가 싫은 겁니다.
그래서 대안으로 선택하는 것이 있습니다.
- 일단 제품을 지금보다 더 좋게 만들자
- SEO를 잘 하면 검색으로 들어오겠지
- GitHub, GeekNews, Threads, LinkedIn에 올리면 알아서 유저가 오겠지
전부 영업을 안 해도 되는 방법을 찾는 것입니다.
인생은 원래 영업이다
같은 Threads 포스트에 달린 답글이 있었습니다.
"인생은 원래 영업인거야 이놈아. 인생사 단계 단계마다 영업에 성공해야하는거란다."
변호사가 쓴 글입니다. 댓글에 "변호사가 뭔데 영업직 주제에 날뛰냐"라는 반응이 달렸다고 합니다.
하지만 맞는 말입니다.
- 취업 면접은 나를 영업하는 자리입니다
- 사내 제안은 아이디어를 영업하는 자리입니다
- 오픈소스 프로젝트의 README는 프로젝트를 영업하는 문서입니다
- 스타트업 투자 유치는 비전을 영업하는 과정입니다
코드를 잘 짜는 것은 기술이고, 그 코드가 쓰이게 만드는 것은 영업입니다.
개발자가 만든 사이드프로젝트가 실패하는 1등 원인은 기술 부족이 아닙니다. 아무도 그게 있는지 모른다는 것입니다.
영업의 본질은 설득이 아니다
영업을 싫어하는 개발자들이 오해하는 것이 하나 있습니다.
영업 = 설득이라는 공식입니다.
실제로 잘 작동하는 영업은 이렇습니다.
1. 문제를 겪는 사람을 찾는다
2. 그 사람이 진짜 그 문제를 겪고 있는지 확인한다
3. 내 해결책이 맞는지 보여준다
4. 결정은 상대에게 맡긴다
설득이 아니라 연결입니다.
문제가 있는 사람과 해결책을 가진 사람을 연결하는 것. 이것이 영업의 전부입니다.
"사세요"가 아니라 "이 문제 겪고 계세요?"로 시작하면, 영업이 아니라 대화가 됩니다. 대화에서 시작된 매출이 가장 오래 갑니다.
개발자가 영업을 못 하는 구조적 이유
개인의 성격 문제가 아닙니다. 구조의 문제입니다.
| 개발 | 영업 |
|---|---|
| 결과가 즉시 보인다 (코드 → 실행) | 결과가 느리다 (메시지 → 무응답 → 언젠가 답장) |
| 혼자 할 수 있다 | 상대가 있어야 한다 |
| 정답이 있다 (컴파일 되거나 안 되거나) | 정답이 없다 (같은 메시지도 사람마다 반응이 다르다) |
| 실패가 비공개다 (로컬에서 에러) | 실패가 공개다 (거절 메시지가 온다) |
| 상대가 거절하지 않는다 (컴퓨터는 시키는 대로 한다) | 상대가 거절한다 (사람은 "됐어요"라고 말한다) |
개발은 통제 가능한 영역입니다. 영업은 통제 불가능한 영역입니다.
그리고 결정적인 차이가 하나 더 있습니다. 컴퓨터는 거절을 안 합니다.
코드를 잘못 짜면 에러가 나지만, 그건 거절이 아니라 피드백입니다. 고치면 됩니다. 컴퓨터는 감정 없이 시키는 대로 합니다. 개발자는 그 환경에서 수년간 일해 온 사람들입니다.
그런데 영업은 사람을 상대합니다. 사람은 "됐어요", "관심 없어요", 또는 아예 읽씹을 합니다. 이건 에러 메시지가 아니라 거절입니다. 고칠 수 있는 게 아니라 받아들여야 하는 겁니다.
거절에 익숙하지 않은 사람이 거절을 당하면 자연스럽게 피하게 됩니다. 그리고 다시 코드로 돌아갑니다. 익숙하고, 통제 가능하고, 나를 거절하지 않는 곳으로.
하지만 유저를 만드는 일은 그 불편한 영역에서 벌어집니다.
개발자에게 맞는 영업은 따로 있다
전통적 영업을 할 필요 없습니다. 개발자의 강점을 쓰는 영업 방식이 있습니다.
1) 글로 영업하기
코드를 잘 쓰는 사람은 글도 잘 씁니다. 로직을 구조화하는 능력이 동일합니다.
- Threads/X에 만드는 과정을 공개합니다 (Build In Public)
- 기술 블로그에 문제 해결 과정을 씁니다
- 커뮤니티에서 타겟 고객의 질문에 답합니다
글 하나가 24시간 내내 일하는 영업사원입니다.
2) 제품으로 영업하기
랜딩페이지가 영업 도구입니다.
- 헤드라인이 피치입니다
- 소셜 프루프가 신뢰입니다
- CTA 버튼이 클로징입니다
전환율을 1% 올리는 것이 DM 10통 보내는 것보다 효율적일 수 있습니다.
3) 데이터로 영업하기
개발자는 계측에 강합니다.
- 어디서 유입되는지 추적합니다 (UTM)
- 어디서 이탈하는지 봅니다 (세션 리플레이)
- 어떤 메시지가 전환되는지 A/B 테스트합니다
감으로 하는 영업이 아니라, 숫자로 하는 영업입니다.
4) 1:1로 영업하기
가장 어렵지만 가장 효과적인 방법입니다.
- 타겟 고객이 있는 곳에서 DM을 보냅니다
- "팔려고"가 아니라 "배우려고" 보냅니다
- 10명에게 보내서 3명이 답하면, 그 3명이 첫 유저 후보입니다
코드:영업 비율을 바꿔라
대부분의 개발자 사이드프로젝트는 이렇습니다.
코드 90% : 영업 10%
매출이 나는 1인 사업의 비율은 이렇습니다.
코드 30% : 영업 70%
이건 코드를 대충 짜라는 뜻이 아닙니다.
MVP가 나왔으면, 그 다음부터는 코드보다 사람에게 시간을 쓰라는 뜻입니다.
기능을 하나 더 만드는 것보다 잠재 고객 한 명과 대화하는 것이 사업에 더 큰 영향을 줍니다.
| 주차 | 잘못된 배분 | 올바른 배분 |
|---|---|---|
| 1-2주 (MVP 전) | 코드 80% / 고객 20% | 코드 60% / 고객 40% |
| 3-4주 (MVP 후) | 코드 70% / 고객 30% | 코드 30% / 고객 70% |
| 5주+ (런칭 후) | 코드 60% / 고객 40% | 코드 20% / 고객 80% |
"나는 영업 체질이 아닌데"
맞습니다. 대부분의 개발자가 그렇습니다.
하지만 영업에 "체질"은 없습니다.
- 처음 코딩했을 때 자연스러웠나요?
- 처음 Git을 썼을 때 편했나요?
- 처음 GitHub에 코드 올릴 때, 내 부족한 코드로 세상을 오염시키는 것 같지 않았나요?
전부 어색했지만, 반복하니까 됐습니다.
영업도 똑같습니다.
첫 DM은 5분 고민하고 보냅니다. 10번째 DM은 30초 만에 보냅니다. 50번째 DM은 템플릿이 생깁니다.
Pieter Levels는 "마케팅은 스킬이다. 코딩을 배운 것처럼 배울 수 있다"고 말합니다. 영업도 마찬가지입니다. 타고나는 것이 아니라 연습하는 것입니다.
오늘 할 수 있는 가장 작은 영업
- 타겟 고객이 있는 커뮤니티 하나를 찾습니다 (Threads, X, 네이버 카페, 오픈톡방, 디스코드)
- 내 제품이 해결하는 문제를 겪고 있는 사람의 글을 찾습니다
- 그 글에 진심으로 공감하는 댓글을 답니다 (링크 없이, 팔지 않고)
- 자연스럽게 대화가 되면, "저도 이 문제를 풀고 있는데"라고 말합니다
이것이 영업의 시작입니다.
코드를 한 줄도 안 짜는 날이 있어도 괜찮습니다. 사람과 대화한 날이라면, 그날이 사업이 가장 많이 전진한 날입니다.