비전문가도 개발자를 제대로 채용하는 방법

내 능력 밖이라는 걸 깨닫는 순간

채용 공고를 올리고 이력서가 들어오는데, 하나같이 들어본 적 없는 프레임워크 이름들이 나열되어 있습니다. 누군가는 "확장 가능한 마이크로서비스 아키텍처를 활용한 풀스택 개발" 경력 5년을 주장하는데, 그게 정말 대단한 건지 아니면 면접 한 시간 전에 튜토리얼 사이트에서 읽고 온 내용인지 알 길이 없습니다. 통화 중에는 그저 고개를 끄덕일 뿐, 되받아칠 방법이 없습니다.

이건 지극히 정상입니다. 직원 10~200명 규모 회사를 운영하는 사람들 대부분은 개발자가 아니지만, 그래도 개발자를 채용해야 합니다. 좋은 소식은 코딩을 배우지 않아도 채용을 잘할 수 있다는 것입니다. 핵심은 코드 자체를 판단하려 하지 말고, 그 주변의 증거들을 판단하는 데 집중하는 것입니다.

기술적으로 아는 척하지 마세요 — 역효과만 납니다

지원자들은 여러분이 허풍을 떠는지 금방 알아챕니다. "쿠버네티스 관련 경험을 얘기해주세요"라고 물어놓고 어떤 답이 나와도 "좋네요, 좋아요"라고만 반응한다면, 눈치 빠른 지원자는 이 면접에 실질적인 기준이 없다는 걸 알아차립니다. 말은 유창하지만 실제로 결과물을 내지 못하는 사람들은 그대로 통과할 것이고, 조용하지만 실력 있는 지원자들은 여러분이 정말로 검증하고 있다고 생각해 오히려 자신을 과소평가할 수 있습니다.

차라리 솔직하게 말하세요. "저는 기술 배경이 없어서, 쉬운 말로 설명해주시길 부탁드릴 거고 이 과정 일부는 기술 전문가에게 맡길 예정입니다." 이건 약점이 아닙니다. 유능한 채용 담당자라면 자신이 직접 해본 적 없는 분야에서 채용할 때 누구나 이렇게 합니다.

다른 사람의 기술적 안목을 빌리세요 — 전체 과정이 아닌 딱 한 시간만

채용을 잘하기 위해 풀타임 기술 공동창업자가 필요한 건 아닙니다. 개발자의 시간 한 시간을 두 번 빌리면 됩니다. 한 번은 채용 공고와 스크리닝 질문을 작성할 때, 또 한 번은 최종 면접 대화에 참여하거나 작업 샘플을 검토할 때입니다.

이런 사람에게 부탁할 수 있습니다:

• 상담료를 지불하고 두 시간 정도 도움을 받을 프리랜서 개발자
• 소프트웨어를 만들어본 경험이 있는 지인이나 어드바이저
• 다른 업무로 이미 함께 일하고 있는 계약직 개발자

부탁할 내용은 구체적이어야 합니다: "이 지원자가 이 특정 질문에 답한 내용이 타당한지 봐주세요." "이 사람을 검증해주세요"처럼 애매하고 부담스러운 부탁은 하지 마세요.

가상의 질문이 아니라 자신의 실제 작업을 설명하게 하세요

정말로 뭔가를 만들어본 개발자는 여러분이 원하는 만큼 세부적으로, 쉬운 말로 설명할 수 있습니다. 이력서를 부풀린 사람은 보통 표면적인 수준을 넘어서지 못합니다.

드러나는 정보량 순으로 좋은 질문들:

1. "본인이 만든 것 중 자랑스러운 걸 하나 설명해주세요. 무엇을 했고, 본인 역할은 무엇이었나요?"
2. "그 프로젝트에서 가장 어려웠던 기술적 문제는 무엇이었고, 어떻게 해결했나요?"
3. "같은 팀 다른 엔지니어들에게 당신과 일하는 게 어땠는지 묻는다면 뭐라고 답할 것 같나요? 왜 그렇게 답할까요?"
4. "본인 코드가 실서비스에서 문제를 일으킨 적이 있다면, 무슨 일이 있었고 어떻게 대처했나요?"

네 번째 질문이 가장 많은 것을 드러냅니다. 거의 모든 진짜 개발자는 뭔가를 망가뜨려본 경험이 있습니다. 몇 년 경력을 주장하면서 "그런 적 없다"고 답하는 사람은 거짓말을 하고 있거나, 실제로 중요한 걸 배포해본 적이 없는 것입니다.

작지만 실제적인 작업 샘플을 활용하세요

지원자에게 무급으로 전체 기능을 만들어달라고 할 필요는 없습니다. 짧고 범위가 명확한 작업 — 60~90분 정도 걸리고, 실제 업무와 유사한 것 — 하나가 한 시간의 대화보다 더 많은 것을 알려줍니다.

공정하게 진행하는 방법:

• 보수를 지급하거나, 무급으로도 합당할 만큼 정말 작은 작업으로 만드세요 (대부분의 지원자는 어느 쪽이 적절한지 알려줄 것입니다)
• 같은 단계의 모든 지원자에게 동일한 과제를 주세요
• 과제 완료 후 본인이 만든 결과물을 직접 설명하게 하세요 — 여기서 누군가 도움을 받고도 언급하지 않았는지 드러납니다

결과물을 직접 검토할 기술적 판단력이 없다면, 바로 이 순간이 앞서 빌린 한 시간의 기술 자문을 쓸 때입니다.

과제를 처음부터 직접 만들고 싶지 않다면, 검증된 기술 스크리닝 테스트로 이 단계 이전에 1차 필터링을 할 수 있습니다 — AssessFit은 다양한 기술 분야에 걸쳐 적응형 테스트를 제공하므로, 모든 지원자를 곧바로 유일한 기술 검토자에게 보내지 않아도 됩니다.

주장이 아니라 실제로 만든 것을 확인하세요

기술 용어로 가득한 이력서는 그 사람이 무엇을 다뤄봤는지는 말해주지만, 무엇을 잘하는지는 말해주지 않습니다. 대신 증거를 요구하세요:

• GitHub 프로필, 포트폴리오, 또는 실제로 만든 서비스 링크
• 회사명과 제품명 — 직접 확인해볼 수 있도록
• 프로젝트에서 본인이 실제로 담당한 비중이 팀 전체 대비 얼마나 되는지

긴 도구 목록에 감명받지 마세요. 한두 가지를 깊이 파고들 수 있는지에 관심을 두세요. 깊이가 진짜 신호이고, 유행어의 폭넓음은 종종 그 반대를 의미합니다.

레퍼런스 체크: 실력이 아니라 실행력을 물어보세요

레퍼런스에게 "그 사람 코드 실력이 좋았나요?"라고 물어봤자, 레퍼런스 본인이 기술적 배경이 없는 한 유용한 답을 기대할 수 없습니다. 설령 기술 배경이 있다 해도, 사람들이 잘 반박하지 않는 부드럽고 관대한 질문일 뿐입니다.

대신 이렇게 물어보세요:

• "약속한 기한 안에, 약속한 걸 끝냈나요?"
• "문제가 생겼을 때, 미리 알려줬나요, 아니면 나중에야 알게 됐나요?"
• "애매한 일을 맡겨도 알아서 해결할 거라고 믿을 수 있었나요, 아니면 하나하나 다 설명해줘야 했나요?"

이 질문들도 레퍼런스가 코드를 알아야 답할 수 있는 게 아닙니다. 그저 이 사람과 함께 일해본 경험만 있으면 됩니다. 솔직한 답을 얻기에 훨씬 문턱이 낮은 질문들입니다.

솔직한 한계

이 모든 방법도 결국엔 여러분이 신뢰할 수 있는 기술 전문가를 두는 것을 대체하지는 못합니다. 이번이 첫 엔지니어 채용이고 주변에 실력을 검증해줄 사람이 정말 아무도 없다면, 이는 위험 요소로 스스로에게, 그리고 어쩌면 아는 사람이 있을 법한 초기 투자자나 어드바이저에게 솔직히 밝힐 가치가 있습니다. 90일 수습 기간 동안 (배포됐는지, 작동했는지, 사용자 불만이 있었는지 같은) 비기술적이고 명확한 성과 지표를 정해두면, 채용한 사람이 면접에서 보였던 것보다 실력이 부족한 것으로 드러났을 때 대비책이 되어줍니다.

여러분이 개발자가 되려는 게 아닙니다. 실제로 뭔가를 만들어본 사람과 그저 관련 용어를 외운 사람을 구분해낼 수 있는 프로세스를 만들려는 것입니다.