신규 입사자 첫 7일 체크리스트 v3

왜 결제·정산 팀의 온보딩은 더 위험한가

결제·정산 자동화 시스템을 운영하는 팀에서 온보딩을 즉흥으로 한다는 건, 단순히 불편한 게 아니라 실제 금전적 리스크를 만든다. 일반 웹서비스라면 신규 팀원이 잘못된 코드를 올렸을 때 에러 로그가 쌓이고 팀이 롤백하면 끝이다. 그런데 우리 도메인은 다르다. 정산 배치가 중간에 깨지면 수백 건의 거래 금액이 틀어지고, 자동화 파이프라인 하나가 멈추면 가맹점 정산이 하루 지연된다. 그 지연은 계약 위반으로 이어질 수 있고, 가맹점 측에서 수기 대사를 돌려야 하는 추가 공수도 우리 팀이 감당해야 한다.

HEDVION은 지금까지 세 번 새 팀원을 맞았다. 세 번 모두 "다음엔 잘 준비하자"고 했고, 세 번 모두 그 준비가 충분하지 않았다. v3은 그냥 반복 학습의 산물이 아니다. 실시간 결제 흐름과 야간 정산 배치가 맞물리는 시스템 구조를 이해하는 사람을 어떻게 빠르고 안전하게 키울 것인가, 라는 질문에 대한 실용적 답이다.

v1의 실패: 정보 과부하는 도메인이 복잡할수록 치명적이다

v1 체크리스트의 문제는 단순히 "항목이 많았다"가 아니다. 결제 도메인 특유의 복잡성이 없는 상태에서 너무 많은 것을 동시에 요구했다는 게 핵심이다. 당시 첫날 목록에는 계정 생성, 개발 환경 구성, 주요 API 문서 정독, 내부 용어 사전 확인, 팀 점심까지 들어 있었다. 결제 시스템에서 "환경 구성"은 일반 서비스와 다르다. 개발 환경에서도 PG사 연동 테스트 계정, 샌드박스 인증키, 정산 DB 접근 권한이 각각 따로 발급되어야 하고, 각 단계마다 담당자 승인이 필요하다. 첫날 그 과정만으로 3~4시간이 사라진다. 나머지 항목들은 형식적으로 체크만 됐고, 팀 점심은 기술적인 것들에 밀려 생략됐다.

실제 수치를 보면 명확하다. v1으로 온보딩한 팀원이 코드베이스에 의미 있는 첫 기여를 한 시점을 기록해보니, 평균 16일이 걸렸다. 첫날 과부하가 이후 일주일의 혼란으로 이어지고, 그게 실질적인 생산성 공백으로 굳어진 결과다. 작은 팀에서 신규 팀원의 첫 2주 공백은 팀 전체 속도에 직접 영향을 미친다.

v2의 실패: 문서는 경험의 대체재가 아니다

v2는 v1의 반성으로 항목 수를 줄이고 문서 중심으로 재설계했다. "이 위키 페이지를 읽으세요"가 하루 일정의 절반을 차지했다. 결제 도메인에서 이 접근법이 특히 문제가 되는 이유가 있다. 우리 내부 문서에는 실제 운영 흐름이 담겨 있다. 가맹점 정산 주기, 수수료 계산 로직, 환불 처리 예외 케이스들. 이 내용은 코드나 데이터를 직접 만져보기 전까지는 읽어도 체계가 안 잡힌다. PG 연동 흐름을 한 번도 디버깅해보지 않은 상태에서 "승인-취소-환불-부분취소" 시나리오를 설명하는 문서를 읽는 건, 수영 방법 책만 읽고 물에 들어가는 것과 같다.

v2로 온보딩한 팀원에게 3주 후 "내부 정산 흐름을 설명해보라"고 했을 때, 문서에 적힌 내용을 거의 그대로 반복했다. 자신의 언어로 재해석한 부분이 없었다. 이건 이해가 아니라 암기다. 결제 시스템에서 암기 기반의 이해는 곧 버그의 씨앗이다. 실제로 상황이 문서와 조금만 달라지면 판단을 못 한다.

v3의 설계: 결제·정산 도메인에 맞춘 7일

1~2일차: 손이 먼저, 눈이 나중. 로컬 환경 구성과 첫 서비스 실행에만 집중한다. 목표는 하나다. 결제 요청이 들어와서 승인 응답이 나오는 흐름을 로컬에서 직접 찍어보는 것. 문서는 막혔을 때만 연다. 환경 세팅 자체가 우리 시스템 구조를 경험하는 첫 번째 학습이다. 어떤 서비스가 어떤 포트로 뜨고, 어떤 환경변수가 없으면 어디서 터지는지를 몸으로 배운다. v3부터는 샌드박스 계정 발급을 입사 하루 전에 미리 완료해둔다. 이 변화 하나로 첫날 환경 구성 소요 시간이 기존 4시간에서 1.5시간으로 줄었다.

3~4일차: 실제 코드베이스에 첫 발자국. 오타 수정, 린트 경고 제거, 주석 업데이트 수준의 PR을 만든다. 중요한 건 내용이 아니라 과정이다. 결제 관련 코드는 리뷰 기준이 일반 기능보다 까다롭다. 금액 계산, 상태 전이, 트랜잭션 경계를 건드리는 코드는 최소 2인 리뷰가 원칙이다. 아주 작은 PR이라도 이 프로세스를 직접 경험하는 게 목표다. "왜 이렇게 꼼꼼하게 보나요?"라는 질문이 나오면, 그 자리에서 실제 사고 사례를 공유한다. 우리 팀은 환불 금액 계산에서 정수형 처리 오류로 특정 케이스의 금액이 틀어진 적이 있다. 숫자가 붙은 실수 이야기가 리뷰 문화의 맥락을 가장 빠르게 전달한다.

5일차: 아키텍처 투어 — 타이밍이 전부다. 기존 팀원 한 명이 30분, 최대 45분 안에 전체 시스템 흐름을 그림으로 설명한다. 결제 요청이 들어와서 가맹점 정산이 완료되기까지의 전체 경로다. 이걸 첫날 하지 않는 이유가 있다. 나흘 동안 로컬에서 서비스를 직접 띄우고 코드를 건드려본 사람과, 아무것도 모르는 상태의 사람이 같은 설명을 들을 때 흡수하는 양이 완전히 다르다. 전자는 "아, 그게 그 서비스였구나"가 되고, 후자는 "그게 뭔지 모르겠다"가 된다. 순서가 내용만큼 중요하다.

6~7일차: 관심의 방향을 확인한다. 관심 있는 이슈를 직접 골라서 작업한다. 이 이틀은 팀이 새 팀원을 관찰하는 시간이기도 하다. 결제 로직 쪽으로 손이 가는지, 자동화·인프라 쪽으로 끌리는지, 데이터 정합성 문제에 민감하게 반응하는지. 작은 팀에서는 각자의 강점을 빨리 파악해서 역할을 유연하게 맞추는 것이 팀 전체 생산성에 직결된다. v3에서는 이 이틀을 "평가"가 아니라 "자기 탐색"으로 프레이밍한다. 팀원도 편하고, 결과로 나오는 정보도 더 진짜에 가깝다.

여전히 불완전한 것, 그리고 그 이유

v3도 완벽하지 않다. 가장 큰 한계는 개인 속도 차이를 체크리스트가 완전히 수용하지 못한다는 점이다. 결제 도메인 경험이 있는 팀원에게 1~~2일차 환경 구성은 반나절이면 끝난다. 반면 백엔드 경험은 있지만 금융 도메인이 처음인 팀원에게는 3~~4일차 PR 과정에서 "왜 이렇게 방어적으로 코딩해야 하나"라는 인식 전환이 필요하고, 이게 일주일 안에 완성되지 않을 수 있다. 체크리스트는 기준선이다. 기준선이 있어야 조정도 가능하고, v1·v2가 없었다면 v3도 없었다.

그래서 v3에서 실제로 가장 중요한 온보딩 항목은 체크리스트가 아니라, 첫날 30분 대화다. "결제나 금융 시스템 경험이 있나요?"부터 시작해서 어디서 속도를 낼 수 있고 어디서 시간이 더 필요한지를 파악한다. 이 대화의 결과에 따라 3~4일차 이슈의 난이도를 조정하고, 5일차 아키텍처 투어의 깊이를 바꾼다. 체크리스트는 이 대화의 결과를 담아내는 그릇이지, 대화를 대체하는 도구가 아니다.

지금 바로 쓸 수 있는 시사점

결제·정산·자동화 시스템을 운영하는 소규모 팀이라면 온보딩에서 다음 세 가지를 먼저 확인하라.

첫째, 환경 세팅은 입사 전날 완료하라. 샌드박스 계정, 접근 권한, 인증키를 미리 발급해두는 것만으로 첫날 공백 시간이 절반으로 줄었다. 소규모 팀에서 신규 팀원의 첫날 3~4시간 낭비는 팀 전체 일정에 파급된다. 담당자 승인 프로세스가 있다면 승인 요청도 미리 넣어두어야 한다.

둘째, 첫 PR은 의도적으로 작게 설계하라. "의미 있는 기여"의 압박을 1주 차에 주지 마라. 결제 코드베이스에서 작은 PR 하나는 리뷰 문화, 코드 컨벤션, 트랜잭션 경계에 대한 팀의 민감도를 동시에 보여준다. 이 정보가 이후 실제 기능 개발의 출발점이 된다.

셋째, 아키텍처 설명은 4일차 이후로 미뤄라. 첫날 전체 시스템을 설명하고 싶은 충동을 참아라. 직접 코드와 데이터를 만져본 다음에 듣는 설명과 아닌 설명은 흡수율이 다르다. 우리 경험상 그 차이는 단순한 느낌이 아니라, 3주 후 팀원이 시스템을 자신의 언어로 설명할 수 있는지 여부로 측정된다.

체크리스트 자체는 공유할 수 있다. 하지만 위 세 가지 없이 체크리스트만 넘기면, 그건 그냥 할 일 목록이다.