한 줄 요약

TinyPilot의 첫 서포트 엔지니어 채용

하이라이트

• TinyPilot의 첫 서포트 엔지니어를 채용했다.
• 서포트 엔지니어 채용이 생각보다 훨씬 어렵다는 것을 알게 됐다.
• 해외 계약자에게 급여를 지급할 플랫폼을 평가 중이다.

목표 달성도

매달 초에 달성하고 싶은 목표를 정한다. 이번 달 목표 달성 결과는 다음과 같다:

Voyager 2 PoE 에디션 출시

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

휴, 정말 예상보다 훨씬 오래 걸렸다. 2021년 4월 초에 작성한 원래 설계 문서를 다시 찾아봤다. 그때는 2021년 5월 15일까지 200대를 준비할 수 있을 것으로 예상했었다. 즉, 6주 걸릴 거라 예상했는데 실제로는 11개월이 걸린 셈이다.

TinyPilot 서포트 엔지니어 채용

• 결과: 서포트 엔지니어와 수습 채용을 시작했다
• 평가: A

이 직무 채용에 정말 많은 공이 들었지만, 팀에 새로운 멤버가 합류하게 되어 기대가 크다. 이번 회고는 대부분 서포트 엔지니어 채용 과정에 대한 이야기이니 자세한 내용은 아래에서 이어서 보자.

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

• 결과: 3월로 연기함
• 평가: N/A

함께 작업 중인 디자인 업체가 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 드림

답장에서 나는 “당신이라는 사람을 거절한다”가 아니라 “당신의 지원서를 거절한다”는 점을 강조하려 했다. 너무 구체적으로 짚지 않은 것도, 지원자가 내가 사소한 실수 하나를 트집 잡아 거절한다고 느끼지 않게 하기 위해서였다.

대부분의 고용주는 개별 거절 메일을 생략한다. 그 이유도 이해한다. 엄청난 시간이 들고 고용주 입장에서는 얻을 게 없기 때문이다. 하지만 나는 나와 함께 일하기 위해 무급으로 시간을 들여 지원한 사람들을 무시하거나 형식적인 메일로 때우는 건 예의가 아니라고 생각한다.

거절 메일을 받은 지원자 중 약 65%는 답장을 하지 않았다. 약 25%는 피드백에 감사하다고 답했다. 그중 몇 명은 추가 설명을 요청했고, 나는 고칠 수 있는 부분에 대해 구체적으로 짚어주고 글쓰기 개선에 도움이 될 자료도 추천해 주었다.

거절 메일을 받은 지원자 중 약 10%는 심사 질문을 풀게 해주면 자신을 증명해 보이겠다고 설득하려 했다. 솔깃하긴 했지만, 심사 질문에 대해 피드백을 주는 데는 커버레터 단계에서 거절하는 것보다 열 배는 더 많은 시간이 들기 때문에, 서로의 시간을 낭비하고 싶지 않아 응하지 않았다.

답장을 보내온 대부분의 사람들은 지원서의 구체적인 문제점을 짚어주는 답장을 받은 것에 놀라며 고마워했다. 그런 경우가 드물기 때문인 것 같다. 답장 중 적대적으로 나온 사람은 한 명도 없었다. 모두 프로페셔널한 태도를 유지했다.

62명(28%)을 cover-letter-reject 폴더에 넣었다. instant-reject와 cover-letter-reject를 합치면, 서류 심사를 통과한 사람은 19명(9%)뿐이었다.

pending-questions

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

그리고 고객 지원 요청 예시 세 가지에 답변해 달라고 요청했다. 고객에게 어떻게 말하고 기술적인 해결책을 어떻게 제시하는지 보고 싶었기 때문이다.

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

이 단계까지 온 지원자는 19명(9%)이었다. 그중 답변을 제출한 사람은 10명(53%)뿐이었는데, 2~3명은 질문을 받은 지 며칠 되지 않아 아직 답장이 올 수도 있다.

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”로 분류했던 지원자에게는 다른 분과 함께하기로 했다고 전했다.

첫 서포트 엔지니어를 채용한 뒤에는 여러 명을 동시에 수습으로 운영하는 것이 너무 어렵겠다는 걸 깨달았다. 개발자라면 각자 다른 과제를 주면 되니 동시에 여러 명을 수습으로 돌릴 수 있다. 하지만 서포트 엔지니어 여러 명이 도움말 포럼에서 서로의 답변을 보면서 같은 자리를 두고 경쟁한다는 걸 알게 하는 건 너무 각박하게 느껴졌다.

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

trial-hire

한 번에 한 명만 수습 채용했기 때문에 이 단계에서는 관리가 쉬웠다. 하지만 완전성을 위해 채용 퍼널의 마지막 단계를 위한 폴더도 만들어 두었다.

요약

내 폴더 시스템을 “채용 퍼널”로 옮겨 보면 단계별 수치는 다음과 같다:

서포트 엔지니어 채용: 급여 지급

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

원격 근무자를 위한 급여 지급 플랫폼을 찾으면서 다음 조건을 충족하는 곳을 알아봤다:

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

Deel (최종 선택)

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

Deel은 계약자의 은행 계좌에 현지 통화로 정확히 얼마가 입금될지를 보여주는 점에서 다른 업체보다 투명해 보였다. 다른 업체들은 좋은 환율을 찾기 위해 최선을 다하겠다고만 할 뿐, 계약자는 실제로 돈이 입금되어야 최종 환율을 알 수 있다.

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

Pilot

Pilot은 Deel과 꽤 비슷하다. 둘 다 Y Combinator의 투자를 받았고 UI도 마찬가지로 세련됐다. 다른 점은 Pilot은 시간 추적을 지원하지 않는 반면 Deel은 지원한다는 것이다.

나는 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 신규 서포트 엔지니어 온보딩 완료