인터뷰를 줄이고 trial 을 늘린 1년 회고

결제·정산 코드베이스에서 채용 실수가 더 비싼 이유

채용은 모든 팀에게 비대칭 리스크다. 그러나 결제·정산·자동화를 직접 운영하는 팀에서 그 비대칭은 훨씬 가파르다. 우리가 다루는 코드 대부분은 돈이 직접 오가는 경로 위에 있다. 정산 파이프라인 하나의 버그는 단순한 기능 오류가 아니라 거래처에 과지급하거나 미지급하는 사태가 된다. 자동화 스크립트의 엣지케이스 누락은 반복 청구, 중복 정산, 감사 로그 불일치로 이어진다. 일반적인 서비스라면 "배포 후 핫픽스"로 마무리되는 수준의 실수가, 이 도메인에서는 외부 거래처에 공문을 보내고 수작업 보정을 며칠 돌리는 사태로 커진다.

세 명짜리 팀에서 넷째를 추가하는 것은 팀 구성을 25% 바꾸는 일이다. 그 넷째가 결제 로직의 경계 조건을 이해하는 방식, 정산 불일치를 마주쳤을 때 즉흥적으로 수정하는 습관, 자동화 작업의 멱등성(idempotency)에 대한 감각 — 이 모든 것이 팀 전체 코드 품질에 즉시 영향을 미친다. 사람 한 명이 추가되는 게 아니라, 그 사람의 작업 방식이 코드베이스에 스며드는 것이기 때문이다. 이 무게를 인터뷰 몇 번으로 가늠하기에는 정보가 너무 적었다.

인터뷰가 측정하는 것과 우리가 알고 싶은 것의 간극

인터뷰에서 잘 통한다고 느꼈던 사람이 실제 작업에서 어려웠던 경우, 반대로 말이 적었는데 코드와 커뮤니케이션이 군더더기 없었던 경우 — 이건 우리만의 경험이 아니다. 인터뷰는 그 사람의 인터뷰 능력을 측정하도록 설계된 환경이다. 결제 API 연동 중 예상치 못한 응답 코드를 만났을 때 어떻게 반응하는가, 정산 로직의 엣지케이스를 발견했을 때 바로 PR을 올리는가 슬랙으로 먼저 공유하는가, 자동화 작업이 절반쯤 진행됐을 때 막히면 혼자 끙끙대는가 일찍 질문하는가 — 이런 것은 1시간짜리 화상 통화에서 절대 나오지 않는다.

우리가 정말 알고 싶었던 건 세 가지였다. 첫째, 이 사람이 도메인 지식 없이 결제·정산 코드를 처음 마주쳤을 때 어떻게 탐색하는가. 둘째, 작업 중간에 막혔을 때 팀에 어떻게 신호를 주는가. 셋째, 코드 리뷰 사이클에서 피드백을 어떻게 주고받는가. 이 세 가지는 인터뷰 질문으로 물어봐도 답을 알 수 없다. "막히면 어떻게 하세요?"라는 질문에 나쁜 대답을 하는 사람은 없다.

유료 Trial로의 전환: 설계 원칙과 실제 운영

약 1년 전부터 최종 결정 전에 유료 trial 기간을 두기 시작했다. 우리가 정한 원칙은 간단하다. 과제는 실제 프로젝트에서 추출한 것이거나, 우리가 실제로 해결했던 문제의 단순화 버전이어야 한다. 인위적인 알고리즘 문제나 "이상적인 상황"을 가정한 과제는 배제했다. 구체적으로는 실제 정산 파이프라인의 일부 로직을 sandbox 환경에서 다루게 하거나, 과거에 발생했던 중복 정산 버그와 유사한 케이스를 재현해서 원인을 찾고 수정하게 하는 식이다.

유료는 협상 대상이 아니었다. 상대방의 시간과 집중력에는 비용을 지불하는 게 맞다. 시간 단위로 환산했을 때 시장 평균 이상의 금액을 제시했고, 결과물의 완성도와 무관하게 지급했다. 이 원칙을 지키지 않으면 trial은 무료 노동 착취가 된다. 실제로 trial 과정에서 나온 아이디어나 코드 조각이 이후 프로덕션에 영향을 미친 경우도 있었기 때문에, 도의적으로도 맞는 방향이라고 생각한다.

1년간 달라진 것: 수치와 구체적 경험

시도해본 케이스 중 인터뷰 인상과 trial 결과가 실질적으로 달랐던 경우는 절반 가까이 됐다. 인터뷰보다 trial에서 더 좋게 보인 경우도 있었고, 반대인 경우도 있었다. 한 케이스에서는 인터뷰 내내 말이 적고 자신감이 낮아 보였는데, trial 과제에서 정산 로직의 반올림 처리 오류를 우리 팀원 중 누구도 미리 지정하지 않은 방식으로 잡아냈다. 이후 합류했고 지금도 팀에 있다. 반대로, 인터뷰에서 결제 도메인 경험을 풍부하게 이야기했는데 trial 과제에서 멱등키(idempotency key) 처리를 아예 빠뜨렸고 지적했을 때의 반응도 방어적이었던 케이스는 그 자리에서 결정하기 훨씬 쉬워졌다.

또 하나 예상하지 못했던 변화가 있었다. trial은 상대방이 우리 팀을 실제로 경험하는 기회이기도 했다. 인터뷰는 구조적으로 우리가 상대방을 평가하는 방향이 강하지만, trial에서는 상대방도 우리 코드베이스, 커뮤니케이션 방식, 피드백 스타일을 직접 본다. 실제로 trial 과정에서 스스로 "이 팀과 방향이 맞지 않겠다"고 판단해 빠진 케이스가 있었다. 합류 후 3개월 만에 맞지 않아서 헤어지는 것보다 훨씬 낫다. 그 비용은 단순히 재채용 과정의 시간만이 아니다. 결제 코드베이스에 익숙해지는 온보딩 비용, 이미 올라간 PR 리뷰 비용, 그 사람이 건드린 자동화 스크립트의 사후 정리 비용까지 포함된다.

Trial의 한계와 우리가 직면한 트레이드오프

trial이 인터뷰보다 낫다고 해서 한계가 없는 건 아니다. 가장 명확한 한계는 시니어일수록 짧은 trial에서 실력이 드러나지 않는다는 점이다. 경험이 많은 사람일수록 단기 과제를 처리하는 능력과 장기 협업 능력 사이의 간극이 더 크다. 아키텍처 결정에 대한 감각, 기술 부채를 어떤 기준으로 쌓고 갚는지, 팀 전체의 속도와 개인 속도를 어떻게 조율하는지 — 이런 것은 2주짜리 trial에서는 보이지 않는다.

과제 설계 자체의 공수도 생각보다 크다. 나쁜 과제는 나쁜 신호를 준다. 한번은 정산 불일치를 재현하는 과제를 설계했는데, sandbox 환경에 실제 데이터 형태와 다른 fixture를 심어놓은 탓에 후보자가 엉뚱한 방향으로 시간을 썼다. 그 trial의 결과는 후보자가 아니라 과제 설계의 문제였다. 이후로는 과제를 사전에 팀 내부에서 한 번 돌려보고, 예상 소요 시간을 실제로 측정한 다음 제시한다. 과제 설계에 드는 시간을 채용 비용의 일부로 명시적으로 계산해야 한다.

지금 바로 쓸 수 있는 시사점

인터뷰와 trial 중 하나를 선택하는 게 아니다. 인터뷰를 줄이되 없애지는 않고, 최종 결정 전 유료 trial을 반드시 거치는 구조로 재설계하는 것이다. 아래는 우리 팀이 실제로 운영하는 방식을 정리한 체크리스트다.

과제 설계 체크리스트:

과제는 실제 코드베이스에서 추출하거나, 실제 발생했던 버그를 단순화한 것이어야 한다. 알고리즘 퍼즐 금지.
내부에서 먼저 돌려보고 예상 소요 시간을 측정한다. 제시 시간의 1.5배를 여유로 준다.
결제·정산 도메인이라면 멱등성, 경계 조건, 에러 처리가 과제 안에 자연스럽게 포함되도록 설계한다. "이 케이스 어떻게 처리할래요?"를 별도로 묻지 않아도 되도록.

운영 원칙:

유료는 협상하지 않는다. 결과 품질과 무관하게 시간 기준으로 지급한다.
trial 기간 중 슬랙(또는 팀이 쓰는 도구)에 접근 권한을 준다. 커뮤니케이션 방식을 보려면 실제 환경이 있어야 한다.
trial 종료 후 48시간 안에 피드백을 준다. 우리가 상대방을 평가하는 것처럼, 상대방도 우리가 어떻게 피드백을 주는지 보고 있다.

결정 기준:

인터뷰 인상과 trial 결과가 다르다면 trial 결과를 우선한다. 단, 그 불일치의 이유를 팀이 함께 분석해본다.
trial에서 스스로 빠지는 경우는 성공으로 분류한다. 그 정보를 얻기 위해 비용을 쓴 것이다.
시니어 채용일수록 trial 이후 레퍼런스 체크를 반드시 병행한다. trial이 커버하지 못하는 장기 협업 신호를 레퍼런스에서 보완한다.

완벽한 채용 방법은 없다. 그러나 인터뷰만 할 때보다 더 많은, 더 실질적인 정보를 갖고 결정하게 됐다는 점만으로도 이 방식은 우리 팀에게 맞다. 채용 한 건의 비용을 단순히 면접관 시간으로만 계산하는 팀이라면, 잘못된 채용 이후 결제 코드베이스를 정리하는 데 드는 보이지 않는 비용도 함께 넣어서 다시 계산해볼 것을 권한다.

— by slecs