신규 입사자 trial 1주 — 우리의 채점표

왜 결제·정산 팀에서 채용 실패의 무게가 다른가

세 명이 운영하는 팀에서 한 명을 더 뽑는다는 건 팀 규모를 33% 키우는 일이다. 대기업에서 300명 중 1명이 이탈하는 것과는 파급 규모 자체가 다르다. 그런데 HEDVION처럼 결제·정산·자동화를 직접 운영하는 팀이라면 이 압박은 한 단계 더 올라간다. 우리가 다루는 건 코드가 아니라 돈의 흐름이다. 매일 정산 배치가 돌아가고, 파이프라인 하나가 예외 처리 없이 멈추면 가맹점 정산이 하루씩 밀린다. 새 팀원이 코드베이스에 익숙해지는 속도보다, 익숙하지 않은 상태에서 실수가 났을 때 파급 범위가 먼저 결정된다.

채용 실패 비용을 거칠게 계산해본 적이 있다. 채용 프로세스 자체에 기존 팀원이 쓰는 시간이 인당 약 15~~20시간이다. 온보딩과 코드 리뷰 병행에 2~~3주간 기존 팀원의 집중력 일부를 가져간다. 3개월 내 이탈이 발생하면, 그 기간에 밀린 자동화 개선 작업이 부채로 그대로 남는다. 대기업은 다른 팀원이 커버하거나 채용을 다시 열면 되지만, 세 명 팀에서는 공백이 제품과 운영 품질에 직접 나온다. 그래서 우리는 1주 trial을 단순한 적응 기간으로 보지 않는다. 서로를 관찰하는 구조화된 구간으로 운영한다.

채점표를 공개하는 이유

관찰이 일방적이어서는 안 된다. 신규 팀원도 우리를 보고 있다. 이 팀이 어떻게 일하는지, 코드베이스가 어느 수준인지, 여기서 성장할 수 있는지. 채점 기준을 숨기는 건 신규 팀원에게도 손해고 우리에게도 손해다. 긴장 속에서 본래 역량의 70%만 나온 사람을 그 샘플로 판단하면, 우리가 잘못된 결론을 내리게 된다.

"기준을 미리 알면 맞춰 행동하지 않느냐"는 걱정이 있을 수 있다. 그런데 우리가 보는 항목들은 1주 내내 연기하기 어렵다. 막혔을 때의 행동 패턴, 코드에 흔적을 남기는 방식, 회의에서 발언하는 타이밍 — 이것들은 의식적으로 꾸미기보다 평소 습관이 그대로 나온다. 채점표를 공유하는 진짜 목적은 불필요한 긴장을 줄이고, 첫 주를 더 밀도 있게 만드는 것이다. 기준이 없으면 신규 팀원은 무엇을 보여줘야 하는지 모르고, 우리는 일관성 없는 '인상'으로 판단하게 된다.

우리가 실제로 보는 세 가지

막혔을 때 어떻게 움직이는가. 결제·정산 코드베이스는 PG사 연동, 세금계산서 API, 은행 가상계좌 처리 로직이 얽혀 있다. 문서 없이 코드에만 남아 있는 예외 케이스도 적지 않다. 이런 환경에서 막혔을 때 행동 패턴은 세 가지다. ①혼자 오래 붙잡고 있기, ②바로 물어보기, ③"여기까지 파악했고 이렇게 접근하려 한다, 방향이 맞는지 확인해도 되냐"고 묻기. 정답은 세 번째에 가깝다. ①은 정산 배치에서 2시간 삽질 후 틀린 방향으로 PR이 올라오는 패턴이고, ②는 맥락 없는 질문에 답변자가 처음부터 다시 탐색해야 하는 패턴이다. 질문을 잘 하는 것도 실력이다.

코드를 남기는 방식. 첫 주에 큰 기능을 작성할 기회가 없어도 괜찮다. 우리가 보는 건 기존 코드를 어떻게 읽고 어떤 흔적을 남기는가다. 정산 배치 스크립트에 주석이 없을 때, 의문을 내부 메모로만 쌓는지 아니면 짧게라도 주석을 붙이고 PR 설명에 맥락을 남기는지. 변수 이름도 신호다. tmp, result 대신 unsettled_tx_list, pg_fee_rate처럼 도메인 언어를 반영한 이름을 쓰는가. 이 팀 코드베이스는 결제 도메인 용어가 곳곳에 박혀 있어서, 그 언어를 흡수하는 속도 차이가 첫 주 코드에서 바로 드러난다.

회의에서 발언하는 타이밍. 말의 양이 아니라 타이밍이다. 우리 팀 회의는 길지 않다. 주간 정산 현황 리뷰, 자동화 이슈 브리핑, 스프린트 우선순위 조율이 전부다. 이 자리에서 "잘 모르겠다"고 말할 수 있는지가 중요하다. 과도한 자신감("제가 해볼게요"를 리스크 판단 없이 먼저 말하는 것)과 완전한 침묵은 비슷하게 위험하다. 전자는 감당할 수 없는 일을 가져가는 패턴이고, 후자는 회의 후 혼자 헤매다 문제가 커지는 패턴이다. 둘 다 결국 팀의 디버깅 비용이 된다.

우리가 보지 않는 것, 그리고 그 이유

이력서에 적힌 기술 스택 숙련도를 첫 주에 다시 검증하지 않는다. 채용 과정에서 이미 확인했다. 팀마다 코드베이스가 다르고, 결제 도메인 특유의 패턴은 경험 없이는 알기 어렵다. 오히려 첫 주에 "이미 다 안다"는 태도가 걱정된다. 이 팀 코드는 겉보기엔 단순해 보여도 정산 규칙, 수수료 계산 로직, 예외 처리 히스토리가 층층이 쌓인 코드다. 빠르게 파악했다는 착각과 실제로 파악한 것은 다르고, 그 착각이 실제 결제 버그로 이어진 사례가 있었다.

실수 자체도 보지 않는다. 첫 주에 실수하는 건 당연하고, 우리도 그 공간을 의도적으로 만들어두려 한다. 우리가 보는 건 실수를 발견했을 때 어떻게 반응하는가다. 숨기는지, 바로 알리는지, 원인을 짧게라도 분석해서 팀에 전달하는지. 이상적인 건 세 번째이지만 두 번째도 충분히 좋다. 절대 안 되는 건 첫 번째다. 특히 정산 영역에서 실수를 숨기면 금액 불일치가 누적되고, 나중에 추적하는 데 처음 발견했을 때보다 몇 배 오래 걸린다.

시나리오: 정산 불일치를 처음 만났을 때

구체적인 상황으로 설명하겠다. 입사 4일차 신규 팀원이 정산 배치 스크립트를 훑다가, 특정 가맹점 유형에서 정산 금액과 실제 거래 합계가 맞지 않는 케이스를 발견했다. 차이는 건당 수백 원이지만 배치가 매일 돌아가면 월 단위 누적 오차가 된다. 이 상황에서 "나중에 제대로 파악하고 말해야지"라며 이틀 더 혼자 잡고 있으면, 그사이 배치가 두 번 더 돌고 오차가 쌓인다. 반대로 아무 맥락 없이 "이상한 것 같아요"로만 슬랙을 보내면, 답변자가 처음부터 다시 탐색해야 한다.

우리가 보고 싶은 흐름은 이렇다. 해당 케이스를 재현할 최소 조건을 정리한다(트랜잭션 타입, 가맹점 유형, 적용 수수료율). 그다음 팀에 "이런 케이스를 발견했는데 의도된 로직인지 버그인지 판단이 안 선다. 여기까지 정리했다"고 알린다. 이 흐름에서 보이는 것이 우리가 채용하고 싶은 패턴 전체다. 스스로 맥락을 수집하고, 판단을 유보할 줄 알고, 팀에 넘기는 타이밍을 안다. 이것이 첫 주에 나오는 사람과 나오지 않는 사람의 차이는 생각보다 크다.

바로 써먹을 실행 시사점

1주가 끝나면 30분 대화를 한다. 형식은 없지만 준비는 한다. 첫 주 동안 날짜·상황·행동·결과를 구체적인 장면으로 메모해둔다. "수요일 정산 리뷰에서 이렇게 발언했다", "이 PR에 이런 주석을 남겼다" 수준으로. 느낌이나 인상이 아니라 장면이어야 피드백이 구체적이 된다. "전반적으로 적극적이었어요"는 피드백이 아니다. "화요일에 API 연동에서 막혔을 때 30분 안에 이슈를 정리해서 물어봤는데, 그 방식이 좋았다"가 피드백이다. 이 30분은 우리만 말하는 자리가 아니다. 신규 팀원도 "이 부분이 예상과 달랐다", "온보딩 문서가 이 부분에서 부족했다"고 말할 수 있어야 한다. 그 피드백을 받아서 다음 채용 때 개선하는 것도 이 구조의 목적이다.

지금 당장 쓸 수 있는 것들은 이렇다. 팀 리더라면, trial 시작 전에 채점 기준 세 가지를 종이 한 장에 적어두라. 기준 없이 관찰하면 마지막에 '느낌'으로 판단하게 된다. 첫 주 동안 구체적인 장면을 최소 세 개 이상, 날짜와 상황까지 메모해라. 이 메모가 피드백 대화의 질을 결정한다. 신규 입사자라면, 막혔을 때 30분 이상 혼자 붙잡지 마라. 결제·정산처럼 도메인 지식이 코드에 암묵적으로 박혀 있는 곳에서는 혼자 해석한 것이 틀릴 확률이 높다. "여기까지 파악했고 이렇게 접근하려 한다"는 형태로 묻는 연습을 하라. 실수를 발견하면 그날 안에 알려라. 정산 불일치는 시간이 지날수록 추적하기 어려워진다. 온보딩 구조를 설계하는 팀이라면, 채점표 공개가 기준을 낮추는 게 아니다. 신규 팀원이 의미 있는 방식으로 첫 주를 보내도록 안내하는 것이다. 기준을 숨기면 양쪽 다 손해다.