한 줄 요약

TinyPilot의 첫 지원 엔지니어 채용

하이라이트

• TinyPilot의 첫 지원 엔지니어를 채용했습니다.
• 지원 엔지니어 채용이 생각보다 훨씬 어렵다는 것을 배웠습니다.
• 해외 계약자에게 급여를 지급할 플랫폼을 검토 중입니다.

목표 평가

매달 초에 달성하고 싶은 목표를 세웁니다. 이번 달 목표 달성 결과는 다음과 같습니다.

Voyager 2 PoE 에디션 출시

• 결과: 드디어 Voyager 2 PoE를 출시했습니다
• 평점: A

정말 오래 걸렸습니다. 예상보다 훨씬 더요. 2021년 4월 초에 작성한 최초 설계 문서를 다시 보니, 2021년 5월 15일까지 200대를 준비할 수 있을 것으로 예측했더군요. 즉, 6주로 예상했던 일이 11개월이 걸린 셈입니다.

TinyPilot 지원 엔지니어 채용

• 결과: 지원 엔지니어 한 분과 트라이얼 채용을 시작했습니다
• 평점: A

이 직무 채용에 많은 공이 들었지만, 새로운 팀원을 맞이하게 되어 기쁩니다. 이번 회고는 대부분 지원 엔지니어 채용 과정에 대한 이야기이니, 자세한 내용은 아래에서 계속 읽어주시기 바랍니다.

TinyPilot 웹사이트 전면 개편 디자인 작업 완료

• 결과: 3월로 연기했습니다
• 평점: 해당 없음

협업 중인 디자인 업체가 2월에는 디자인 작업을 마무리할 시간이 부족했습니다. 3월과 4월에는 작업 시간을 보장받기로 협의했으니, 이달 말까지는 완료할 수 있을 것으로 기대합니다.

TinyPilot 통계

1월 이후 판매는 꾸준히 유지되고 있습니다. 2월이 짧아 총 판매액은 소폭 감소했지만, 일평균으로 보면 1월보다 오히려 실적이 좋았습니다.

2월 이익은 이례적으로 높았지만, 이는 대부분 시점 차이 때문입니다. 아직 처리되지 않은 큰 청구서가 몇 건 있고, 사업용 신용카드 한도가 마침내 2만 달러 증액되면서 보유 현금이 늘어난 영향입니다.

지원 엔지니어 채용: 채용 공고

지난 몇 달간 지원 엔지니어를 채용하고 싶었지만 시간이 부족했습니다. 예상보다 더 오래 걸리긴 했지만, 결국 첫 지원 엔지니어를 채용했습니다. 첫 단계는 채용 공고를 작성하는 것이었습니다.

채용 공고는 세 곳에 게시했습니다.

채용에서 겪는 문제 중 하나는, 소규모 사업주로서 우리 회사가 어떤 곳인지 이해하고 그것을 제게 잘 전달해 주는 사람을 뽑고 싶다는 점입니다. 문제는 대부분의 회사가 지원자를 형편없이 대한다는 것입니다. 그러다 보니 지원자는 특정 회사에 시간을 투자하기를 꺼리게 됩니다. 어차피 지원서가 허공으로 사라질 확률이 90%라고 느끼기 때문입니다.

채용 공고를 쓸 때, 제가 모든 지원서를 직접 읽는다는 점을 분명히 하려 했습니다. 지원서가 머신러닝 봇이나 키워드만 보고 무작정 걸러내는 어설픈 리크루터에게 가는 것이 아닙니다. 지원자가 노력을 들이면 저도 그만큼 노력을 들이겠다는 뜻입니다.

또한 채용 과정 전반에서 지원자들이 자신의 시간이 존중받고 있다고 느끼길 바랐습니다. 함께 일할 때도 그렇게 느끼게 하고 싶기 때문입니다.

많은 채용 공고에는 “이 설명을 꼼꼼히 읽었다는 것을 알 수 있도록 자기소개서에 banana라는 단어를 넣어주세요” 같은 문구가 있습니다. 저는 의도적으로 그렇게 하지 않았습니다. 관계를 시작부터 불편하게 만든다고 느꼈기 때문입니다. 지원자들이 제가 기본적으로 그들을 게으르거나 무능하다고 가정한다고 생각하게 하고 싶지 않았습니다. 성의 없는 지원서는 몇 초만 봐도 알 수 있으니, 굳이 마법의 키워드가 필요하지 않습니다.

보수를 얼마로 할지 확신이 서지 않았습니다. 이 직무의 시장 시세를 가늠하기가 어렵습니다. 보수를 공개한 채용 공고 자체가 드물고, 특히 파트타임 계약직은 더욱 그렇습니다. 저는 시간당 40달러로 정했지만, 이야기를 나눈 다른 창업자들은 시간당 20~30달러면 충분히 역량 있는 지원자를 찾을 수 있을 것이라고 했습니다.

지원 엔지니어 채용: 지원서 검토

채용 공고를 올린 뒤에는 지원서 검토를 시작할 차례였습니다. 이 과정이 전체에서 가장 많은 시간이 걸렸습니다.

이 단계에서 평가한 기준은 다음과 같습니다.

• 글이 명확하고 문법적으로 정확한가?
• TinyPilot에 대해 알아보는 데 시간을 들였는가?
• 고객 지원 또는 사용자 대상 문서 작성 경험이 있는가?
• 기술 요건을 충족하는가?

눈에 띄는 지원자를 빠르게 가려내어 신속하게 답장을 보냈습니다. 그 외 지원자들은 빠르게 탈락 처리하거나, 시간이 나는 대로 답변할 수 있도록 대기열에 두었습니다.

곧 단계별로 지원자를 관리할 정리 시스템이 필요하다는 것을 깨닫고, 진행 중인 모든 메일 스레드를 이메일 폴더별로 분류했습니다.

instant-reject

instant-reject 폴더는 지원 방법을 따르지 않은 지원자용이었습니다. 여기에는 다음이 포함됩니다.

• 이력서만 첨부하고 빈 메일을 보낸 지원자
• 자기소개서에 직무나 TinyPilot에 대한 구체적 언급이 전혀 없는 지원자(재활용 지원서)
• 직무 요건을 충족하지 못하면서도 자기소개서에서 그 간극을 언급하지 않은 지원자

해당 지원자들은 instant-reject 폴더로 옮기고 별도로 답장을 보내지 않았습니다.

총 138명(전체의 62%)이 instant-reject 폴더로 분류되었습니다.

cover-letter-reject

cover-letter-reject 폴더는 성의 있게 지원은 했지만 자기소개서나 이력서를 보면 직무와 맞지 않음이 분명한 지원자용이었습니다.

이들에게는 개별 답장을 보냈습니다. 예시는 다음과 같습니다.

안녕하세요 Joe님,

연락 주시고 TinyPilot에 대해 알아보는 데 시간을 내주셔서 감사합니다.

안타깝게도 이번에는 잘 맞지 않을 것 같습니다.

Linux와 Raspberry Pi에 대한 훌륭한 경험이 많으신 것 같지만, 이 직무는 고객 대상 콘텐츠 작성 경험이 더 많은 분을 필요로 합니다. 영어 실력은 전반적으로 좋으시지만 자기소개서와 이력서에 오류가 몇 군데 있어, 이 역할에는 적합하지 않다고 판단했습니다.

함께하지 못해 아쉽지만, 앞으로의 구직 활동에 좋은 결과가 있기를 바랍니다.

감사합니다.
Michael 드림

답장에서 저는 “당신(you)을 탈락시킨다”가 아니라 지원서 자체를 탈락시킨다는 점을 강조하려 했습니다. 지원자가 제가 트집을 잡거나 단순한 실수 하나로 탈락시킨다고 느끼지 않도록 너무 구체적으로 지적하지 않았습니다.

대부분의 고용주는 개별 탈락 메일을 생략합니다. 그 이유도 이해합니다. 엄청난 시간이 들고 고용주에게는 이득이 없기 때문입니다. 그래도 저는 함께 일하고 싶다며 무급으로 시간을 들여 지원해 달라고 해놓고 무시하거나 형식적인 메일을 보내는 것은 무례하다고 생각합니다.

탈락 메일을 받은 지원자 중 약 65%는 답장을 보내지 않았습니다. 약 25%는 피드백에 감사하다고 답했습니다. 그중 몇 분은 더 자세한 설명을 요청했고, 저는 고칠 부분에 대해 구체적인 코멘트와 글쓰기 개선에 도움이 될 자료를 추천해 드렸습니다.

탈락 안내를 받은 지원자 중 약 10%는 스크리닝 질문을 풀게 해주면 자신을 증명해 보이겠다고 설득했습니다. 솔깃했지만, 스크리닝 질문에 피드백을 주는 데는 자기소개서 단계에서 탈락시키는 것보다 10배는 더 많은 시간이 들기 때문에, 서로의 시간을 낭비하고 싶지 않아 응하지 않았습니다.

답장을 보내온 분들 대부분은 지원서의 구체적인 문제점을 짚은 답변을 받는 것 자체가 드문 일이라며 놀라움과 고마움을 표했습니다. 적대적으로 반응한 사람은 한 명도 없었고, 모두 프로페셔널한 태도를 유지했습니다.

62명(28%)을 cover-letter-reject 폴더에 넣었습니다. instant-reject와 cover-letter-reject를 합치면, 서류 심사를 통과한 지원자는 19명(9%)에 불과했습니다.

pending-questions

자기소개서 영어가 명확하고 문법적으로 정확하며 기술 요건을 충족한 지원자에게는, 지원서에서 좋았던 점과 TinyPilot과 잘 맞을 것 같다고 생각한 이유를 담은 개별 답장을 보냈습니다.

그리고 고객에게 어떻게 말하고 기술적 해결책을 제시하는지 가늠해 보기 위해, 예시 고객 지원 요청 세 가지에 답변해 달라고 요청했습니다.

답장을 보낸 뒤에는 질문에 답변할 때까지 pending-questions 폴더에 두었습니다.

이 단계까지 온 지원자는 19명(9%)이었으며, 그중 10명(53%)만이 답변을 제출했습니다. 다만 두세 분은 질문을 받은 지 며칠 되지 않아 아직 답변을 보내올 수도 있습니다.

questions-reject

지원자가 예시 질문에 대한 답변을 보내오면, 트라이얼 채용으로 진행할지 여부를 결정했습니다.

예시 질문에 답변한 모든 지원자에게는 제안을 하든 하지 않든 상세한 피드백을 보냈습니다. 이 아이디어는 Firebase 창업자인 Andrew Lee에게서 얻었습니다.

지원자가 자신의 시간을 낭비했다고 느끼지 않도록 하는 것이 무엇보다 중요합니다. Firebase에서는 과제 전형 과정 자체에 우리도 큰 노력을 쏟음으로써 이를 보장했습니다… 지원자가 과제를 제출하면, 우리는 철저하고 상세한 코드 리뷰를 제공했습니다(보통 전설적인 @mikelehen이 맡았습니다).

우리는 이 코드 리뷰를 실제 프로덕션 코드 리뷰처럼 대했고, 지원자와 다음 단계로 진행하든 아니든 동일하게 진행했습니다. 이 리뷰가 매우 중요했던 이유는 두 가지입니다. 첫째, 우리가 지원자를 진지하게 대하고 면접 과정에 우리 자신의 시간을 상당히 투자하고 있음을 보여주었습니다. 둘째, Firebase에서 일하는 것이 어떤 느낌일지 지원자에게 미리 보여주었습니다. “코딩 과제에 대해서도 이렇게 훌륭한 코드 리뷰를 해준다면, 실제 프로덕션 코드로 이 팀과 함께 일하는 건 얼마나 좋을까!”라는 생각이 들게 하는 것이지요.

-Andrew Lee, “How Firebase Interviewed Software Engineers”

Andrew의 방식은 사람을 대하는 올바른 방법으로서 항상 제 마음에 남아 있었고, 그래서 어떤 직무를 채용할 때든 그 정신을 적용하려 노력해 왔습니다.

대부분의 분들이 상세한 피드백에 감사해하며 도움이 되었다고 했습니다. 한 분은 제 기준이 너무 좁다고 느꼈다고 했고, 그 피드백을 반영해 질문을 수정하기도 했습니다.

질문에 답변한 지원자 중 19명 중 17명(89%)을 questions-reject 폴더에 넣었습니다.

maybe-trial-hire

채용을 시작한 첫 주에 한 지원자가 스크리닝 질문에 꽤 잘 답했지만, 여전히 확신이 서지 않았습니다. 지금까지 본 지원자 중에서는 가장 뛰어났지만, 더 많은 가능성을 보고 싶었습니다. 몇 주 안에 결정을 알려드리겠다고 말씀드린 뒤 maybe-trial-hire 폴더에 넣어 두었습니다. 결국 더 잘 맞는 지원자를 찾게 되어, 나중에 ‘보류’했던 분께 다른 분과 함께하기로 했다고 알려드렸습니다.

첫 지원 엔지니어를 채용한 뒤에는 여러 후보와 동시에 트라이얼 채용을 진행하는 것이 너무 어렵겠다는 생각이 들었습니다. 개발자라면 각자 다른 과제를 주면 되니 여러 명과 동시에 트라이얼을 진행할 수 있습니다. 하지만 지원 엔지니어 여러 명이 도움 포럼에서 서로의 답변을 보며 같은 자리를 두고 경쟁한다는 것을 알게 하는 것은 너무 각박하게 느껴졌습니다.

몇 달 뒤 지원 엔지니어를 추가로 채용할 경우를 대비해 maybe-trial-hire 폴더는 그대로 유지하고 있습니다. 이미 트라이얼 채용을 진행 중이라는 점을 지원자들에게 투명하게 알리되, 지원을 계속 진행하면 나중에 추가 채용 시 우선 후보로 고려하겠다고 안내합니다. 또는 지원을 잠시 중단했다가 중단한 지점부터 다시 이어가는 선택지도 드립니다.

trial-hire

한 번에 한 분씩만 트라이얼 채용을 진행했기 때문에 이 단계에서는 관리가 쉬웠습니다. 그래도 완전성을 위해 채용 퍼널의 마지막 단계용 폴더를 만들었습니다.

요약

폴더 시스템을 ‘채용 퍼널’로 바꿔 정리하면 각 단계별 수치는 다음과 같습니다.

지원 엔지니어 채용: 급여 지급

현재 서로 다른 국가에 있는 프리랜서 개발자 세 분과 함께 일하고 있습니다. 세 분 모두 급여 지급 방식이 각각 다릅니다. 네 번째 계약자를 추가하게 된 지금, 하나의 솔루션으로 지급 절차를 표준화해야겠다고 생각했습니다.

원격 근무자를 위한 급여 지급 플랫폼을 찾으면서 다음을 충족하는 서비스를 원했습니다.

• 청구서 발행과 지급 처리에 드는 모두의 시간을 최소화할 것
• 컴플라이언스 문서를 관리할 것
• 계약 문서를 관리할 것
• 계약자가 경비를 기록할 수 있을 것
• 스파이웨어를 설치하지 않고도 계약자가 청구 가능한 근무 시간을 쉽게 기록할 수 있을 것

Deel (최종 선택)

결국 모든 조건을 충족한 Deel을 선택했습니다. 사용한 지 일주일밖에 되지 않았지만 지금까지는 만족스럽습니다.

Deel은 계약자의 현지 통화로 은행 계좌에 실제로 입금될 정확한 금액을 보여준다는 점에서 다른 업체보다 투명해 보였습니다. 다른 업체들은 좋은 환율을 찾아보겠다고 약속만 할 뿐, 계약자는 실제로 계좌에 돈이 입금되어야 최종 환율을 알 수 있습니다.

Deel은 미국 기반 직원을 위한 급여 서비스로도 확장할 계획이라고 합니다. Justworks와 Gusto에 실망했던 저로서는 반가운 소식입니다.

Pilot

Pilot은 Deel과 상당히 유사합니다. 둘 다 Y Combinator의 투자를 받았고, 매끄러운 UI도 비슷합니다. Deel은 시간 추적을 지원하는 반면, Pilot은 지원하지 않습니다.

저는 Pilot에 먼저 가입했고 원래는 Pilot을 사용할 계획이었지만, 계정 활성화에만 일주일이 걸렸습니다. 그 사이 다른 창업자가 Deel을 추천해 주어 갈아탔습니다. 고객 온보딩을 잘하는 것이 결국 이득이 된다는 뜻이겠지요.

Remote

Remote는 계약자에 대한 무료 송금을 제공합니다. 좋아 보이지 않나요? 바로 그 ‘무료’ 때문에 저는 선택하지 않았습니다.

다른 곳에서 계약자당 월 30~50달러를 받는 서비스를 Remote가 무료로 제공할 수 있다면 뭔가 수상합니다. 환전 수수료에 비용을 숨기는 등 예상치 못한 방식으로 제게서 수익을 내고 있을 수도 있습니다. 아니면 계약자 송금이 그들에게 중요하지 않은 유스케이스라서, 구글이 무료 서비스를 수없이 종료하듯이 갑자기 서비스를 접을 수도 있습니다.

Gusto

이미 현지 직원의 급여 서비스로 Gusto를 사용하고 있습니다. Gusto가 썩 마음에 들지는 않지만, 하나의 서비스로 모두에게 급여를 지급할 수 있다면 편리하긴 합니다.

안타깝게도 Gusto는 해외 계약자가 매 지급 주기마다 고정된 달러 금액을 받을 경우에만 지원합니다. 계약자마다 주당 근무 시간이 다르다면 Gusto는 적합하지 않습니다.

기존 프로젝트 (RIP)

예전에는 회고마다 기존 사업에 대한 업데이트를 정기 코너로 넣었지만, 내용이 점점 지루해졌습니다. 대부분 “아무것도 하지 않았습니다. 그 결과가 지표에 이렇게 반영되었습니다”라는 이야기뿐이었기 때문입니다.

그래서 ‘기존 프로젝트’ 코너를 ‘사이드 프로젝트’로 교체해, 주말과 저녁에 만지작거리는 취미 프로젝트 이야기를 하려 합니다.

사이드 프로젝트

Lenny

Lenny는 저를 대신해 스팸 메일에 답장하는 챗봇입니다.

스팸이 점점 더 공격적으로 변하고 있습니다. 이제 스패머들은 첫 메일에 답하지 않으면 자동으로 후속 메시지를 계속 보냅니다.

스패머들이 메일 한 통당 1페니도 안 되는 비용과 몇 달에 한 번 도메인 하나 바꾸는 것만으로 계속 제 받은편지함을 침범하고 시간을 낭비하게 한다는 사실이 짜증 났습니다. 게다가 답장이 올 때까지는 전혀 노력을 들일 필요가 없으니, 수천 명에게 같은 짓을 반복합니다. 그래서 대량의 반타기팅 스팸 메일이 더 이상 가성비가 나오지 않도록 스패머들의 비용을 높일 방법을 찾고 싶었습니다.

텔레마케터의 시간을 음성 챗봇으로 낭비시키는 한 유튜브 채널에서 영감을 받았습니다. 이 채널은 VoIP 번호를 운영하며 텔레마케터의 전화를 받아 Lenny라는 친절한 호주 남성의 녹음된 목소리로 응대합니다. 녹음된 답변은 텔레마케터가 파는 물건에 항상 관심을 보이면서도 계속 딴소리로 새는 식입니다. Lenny는 텔레마케팅 업체에 수만에서 수십만 달러의 비용을 안겼을 것입니다.

저는 그 Lenny의 이메일 버전을 직접 만들었습니다. 이제 스팸 메일을 받으면 제 이메일 기반 Lenny에게 전달합니다. Lenny는 스패머에게 열정적으로 답장하면서도 계속 딴 길로 새며 대화를 빙빙 돌게 만듭니다.

다음은 제가 챗봇용으로 작성한 동일한 메시지 시퀀스에 대해 두 명의 서로 다른 스패머가 반응한 사례입니다. Lenny는 두 스패머 모두에게서 같은 지점에서 포기하기 전까지 각각 다섯 번의 답장을 끌어냅니다. 두 번째 사례에서는 Lenny의 답장이 스패머 메시지의 맥락과 맞지 않게 되지만, 스패머는 한동안 계속 답장을 보냅니다.

가능한 한 서드파티 의존성을 최소로 유지하려 하고 있지만, 2월에 Bulma CSS 프레임워크를 도입했고 덕분에 UI가 훨씬 보기 좋아졌습니다.

그 외에도 새로운 답변을 더 쉽게 정의할 수 있도록 작업 중입니다. 현재는 모든 답변이 코드에 하드코딩되어 있지만, 웹 UI에서 직접 편집할 수 있게 만들고 싶습니다.

Lenny를 앞으로 어떻게 가져갈지는 아직 모르겠습니다. 무료 오픈소스 도구로 공개할 수도 있지만, 호스팅 서비스 형태로 비용을 지불하고라도 쓰려는 분들이 있을 것 같기도 합니다. 지금은 그냥 제 재미로 만들고 있지만, 몇 달 안에는 다른 분들도 쓸 수 있게 공개하고 싶습니다.

PicoShare

PicoShare는 파일을 공유하기 위한 간단한 도구입니다.

파일을 호스팅하고 공유해 주는 서비스는 수없이 많지만, 모두 크고 작은 불편을 줍니다. 예를 들어 Google Drive에 동영상을 올리고 링크를 보내려고 해도 바로 되지 않습니다. Google Drive는 동영상을 꼭 재인코딩하려 해서 영상이 실제로 이용 가능해지기까지 10분을 기다려야 합니다. 그 뒤에도 상대방은 파일을 재생하려면 Google Drive UI를 헤매야 합니다. Dropbox나 imgur 등도 마찬가지입니다.

PicoShare는 불필요한 기능 없이 번거로움 없는 파일 공유 서비스입니다. 파일을 업로드하면 바로 직접 링크가 생성됩니다. 링크가 있는 사람이라면 누구나 계정을 만들거나 광고를 볼 필요 없이 바로 파일을 보거나 다운로드할 수 있습니다.

최근에는 가족 단체 문자에 30 Rock의 짧은 클립을 공유할 때 PicoShare를 사용했습니다. PicoShare에 클립을 업로드해 공유 링크를 받는 과정은 다음과 같습니다.

PicoShare는 공유 파일에 만료 시간을 설정하는 기능도 지원합니다. 때로는 TinyPilot 관련 파일을 공유해야 하는데, 민감한 정보가 담겨 있어 상대방 메일함에 무기한 남아 있는 것을 원치 않을 때가 있습니다. 예전에는 클라우드 스토리지에 파일을 올리고 링크를 공유한 뒤, 나중에 직접 삭제해야 했습니다. PicoShare는 만료 시간이 지나면 파일을 자동으로 삭제해 이 과정을 자동화합니다.

PicoShare 작업은 불과 몇 주 전에 시작했기 때문에 아직 다듬어지지 않은 상태입니다. 어뷰징을 막는 비용이 너무 많이 들어 사업으로 만들기는 어렵다고 생각합니다. 지금은 오픈소스로 공개되어 있지만, 아직 빠르게 바뀌고 있어 문서화에는 많은 공을 들이지 않았습니다.

마무리

무엇을 해냈나요?

• TinyPilot Voyager 2 PoE 출시
• TinyPilot 첫 지원 엔지니어 채용
• PicoShare 제작

배운 점

• 채용 과정을 함께 일하는 방식의 미리보기로 활용하세요.
  • 역량 있는 인재는 자신을 잘 대우해 주는 사람과 일하고 싶어 합니다.
  • 채용 공고와 채용 과정은 지원자를 존중하고 그들의 시간을 소중히 여긴다는 것을 보여줘야 합니다.
• 채용 공고가 평범하면 평범한 지원서를 걸러낼 수 없습니다.
  • 평범한 채용 공고를 쓰면 회사에 대해 구체적인 내용이 전혀 없는 재활용 지원서만 받게 됩니다.
  • 채용 공고를 통해 우리 회사를 다른 곳과 차별화하세요. 지원자가 자기소개서에서 우리 회사에 대해 알아보는 데 노력을 들였음을 보여줄 수 있는 독특한 이야기를 할 거리를 제공하세요.
• 지원자를 잘 대하는 데는 비용이 들지만, 사람들은 감동합니다.
  • 탈락한 지원자를 존중하며 대하는 데는 10배의 시간이 걸리지만, 그렇다고 생략해서는 안 됩니다.
  • 창업자라면 직접적인 이득이 없더라도 사람을 어떻게 대할지 선택할 수 있습니다.

다음 달 목표

• TinyPilot Pro 2.4.0 출시
• TinyPilot 웹사이트 디자인 전면 개편 마무리
• TinyPilot 신규 지원 엔지니어 온보딩 완료