17. 신규 입사자 온보딩 가이드

0. 먼저 알고 가기 (30초 요약)

• 환경 설정을 끝내고, 본인 코드 소유권/권한을 정리한 뒤 첫 PR로 시작하세요.
• 초반엔 큰 변화보다 팀 규칙을 복제해 적용하는 것이 중요합니다.
• 매일 짧은 피드백으로 질문을 규칙으로 바꾸는 흐름을 유지하세요.

왜 중요한가: 첫 2주의 경험이 입사자의 이후 6개월 기여 속도를 결정합니다. 단순 환영 행사가 아니라 "팀의 품질 기준을 손으로 익히는 시기"입니다.

일상 비유: 새 직장의 사물함, 출입증, 매뉴얼, 첫 거래처 인사를 준비된 매뉴얼로 받느냐, 매번 물어가며 찾느냐가 첫 달의 만족도를 가르는 것과 같습니다.

초심자용 한눈에 보기

입사는 "설정 완료 + 첫 PR + 피드백 루프"의 3단계로 진행하면 실패 확률이 내려갑니다.

flowchart LR
  D0[Day 0<br/>준비] --> D1[Day 1<br/>환경/권한]
  D1 --> W1[Week 1<br/>First PR]
  W1 --> M1[30일<br/>독립 작업]
  M1 --> M2[60일<br/>중간 기능]
  M2 --> M3[90일<br/>영역 owner]

핵심 용어 빠르게 정리

---

온보딩 표준은 특정 협업 도구 초대 절차가 아니라 신규 구성원이 안전하게 개발 환경을 만들고, 첫 기여를 하며, 팀의 품질 기준을 빠르게 이해하도록 돕는 시스템입니다.

---

추천 항목 (실무 우선순위)

• 시작 추천: Day0에 계정·접근권한·필수 도구를 하루 내 완료해 첫 주 활동을 지연 없이 시작하세요.
• 안정 추천: 첫 PR까지 팀의 공통 PR 기준을 그대로 따라가고 피드백은 짧은 주기로 받습니다.
• 운영 추천: 30/60/90 체크리스트는 팀 목표와 연동해 주기적으로 갱신하세요.

추천 항목 고도화 체크

• 첫 적용 — 개발 환경, 권한, 첫 PR, 멘토링 루프 중 하나를 실제 PR이나 운영 이슈에 붙이고, 변경 전 기준을 먼저 적는다.
• 증거 정리 — setup log, first PR, access checklist, 멘토 피드백를 같은 작업 기록에 남긴다.
• 재점검 — setup 소요 시간, 첫 PR lead time, 막힌 항목 수가 나아졌는지 30일 안에 확인하고 기준을 유지, 수정, 폐기 중 하나로 판정한다.

추천 항목 실행 기록 템플릿

• 작업 : 개발 환경, 권한, 첫 PR, 멘토링 루프 적용 범위를 어느 화면, 패키지, 문서에 둘지 적는다.
• 증거 : setup log, first PR, access checklist, 멘토 피드백 중 실제로 남긴 항목만 링크한다.
• 판정 : 유지/수정/폐기 중 하나와 이유를 한 문장으로 남긴다.
• 다음 점검 : setup 소요 시간, 첫 PR lead time, 막힌 항목 수를 다시 볼 날짜와 담당자를 지정한다.

문서 책임 범위

---

0. 모든 프론트엔드 그룹 공통 Baseline

0.0 온보딩 여정 한눈에 보기

flowchart TD
  A[Day 0 준비] --> B[환경/권한 셋업 완료]
  B --> C[Day 1 목표 달성]
  C --> D[Week1 First PR]
  D --> E[30/60/90 체크포인트]
  E --> F{피드백 필요 여부}
  F -->|필요| G[멘토링 확대 + 과제 조정]
  F -->|완료| H[독립 작업 확대]
  G --> C
  H --> I[팀 온보딩 품질 지표 개선 제안]

0.1 교차 검증 매트릭스

0.2 운영 게이트

---

1. Day 0 준비

신규 멤버가 오기 전에 팀이 준비해야 할 항목입니다.

---

2. Day 1 목표

Day 1의 성공 기준은 "많은 정보를 전달했다"가 아니라 "스스로 검증 가능한 개발 루프를 만들었다"입니다.

---

3. Week 1 목표

왜 중요한가: 첫 PR을 너무 늦게 시작하면 환경 셋업 단계의 사소한 막힘을 발견하지 못하고, 너무 일찍 큰 일을 맡기면 리뷰 부담만 늘어납니다.

첫 PR은 생산성 평가가 아니라 팀의 개발 루프를 체험하는 과제입니다.

3.1 첫 PR까지의 흐름

flowchart TD
  S[Day 1 환경 setup 완료] --> ISSUE[멘토가 first issue 배정<br/>난이도 XS/S]
  ISSUE --> BRANCH[branch 생성<br/>네이밍 규칙 학습]
  BRANCH --> CODE[코드 변경<br/>2일 내]
  CODE --> LOCAL[lint/type/test<br/>로컬 실행]
  LOCAL -->|실패| FIX[수정 또는 멘토 페어링]
  FIX --> LOCAL
  LOCAL -->|통과| PUSH[push + PR 생성<br/>템플릿 채움]
  PUSH --> AI[AI 1차 리뷰]
  AI --> REVIEW[멘토 + reviewer 피드백]
  REVIEW -->|수정 요청| CODE
  REVIEW -->|승인| MERGE[Merge]
  MERGE --> NOTE[배운 점 학습 노트 기록]
  NOTE --> NEXT[Week 1 후속 과제 진행]

비유: 자전거 보조바퀴와 같습니다. 첫 PR은 멘토가 옆에서 손잡이를 잡아주는 시간이지, 시속 30km로 달리는 시험이 아닙니다.

---

4. 30/60/90 기대치

왜 중요한가: 기대치가 입사자 머릿속에만 있으면 매니저와의 평가 기준이 어긋나고, 첫 평가 시점에 동상이몽이 됩니다.

기대치는 직무 레벨에 따라 조정하되, 기준과 피드백 주기는 사전에 공유합니다.

4.1 30/60/90 타임라인 (gantt)

gantt
  title 신규 입사자 30/60/90 일정
  dateFormat  YYYY-MM-DD
  axisFormat  Day %j
  section Day 0-1
  계정/권한/장비 준비    :done, d0, 2030-01-05, 1d
  환경 setup verify     :a1, after d0, 1d
  section Week 1
  핵심 flow 학습        :a2, after a1, 2d
  First PR 작성/머지    :a3, after a2, 3d
  section 30일
  작은 기능 독립 처리   :b1, after a3, 21d
  리뷰 기준 내재화      :b2, after a3, 21d
  section 60일
  중간 규모 기능 설계   :c1, after b1, 30d
  RFC/ADR 읽기 반영     :c2, after b1, 30d
  section 90일
  영역 owner 역할       :d1, after c1, 30d
  품질 개선 제안        :d2, after c1, 30d
  section 회고
  90일 회고/온보딩 개선 :e1, after d1, 3d

4.2 권한 부여 단계별 흐름

flowchart LR
  subgraph D0["Day 0 입사 전"]
    P0[계정 생성<br/>SSO]
    R0[read 권한<br/>저장소/문서]
  end
  subgraph D1["Day 1-7"]
    P1[write 권한<br/>feature branch]
    R1[staging deploy<br/>preview]
  end
  subgraph W4["30일 이후"]
    P2[main 머지 권한<br/>code owner 후보]
    R2[production read<br/>로그/모니터링]
  end
  subgraph W12["90일 이후"]
    P3[production deploy<br/>승인자 동반]
    R3[secret/IAM<br/>한정 범위]
  end
  D0 --> D1
  D1 --> W4
  W4 --> W12

비유: 운전면허 단계와 같습니다. 학원(read), 임시 면허(write+staging), 정식 면허(main 머지), 영업용 면허(production)로 점진적으로 확장합니다.

---

5. 개발 환경 표준

install
typecheck
test
dev

위 명령은 실제 팀의 스크립트명으로 바꾸되, 온보딩 문서에는 "무엇을 검증하는 명령인지"를 함께 적습니다.

---

6. 권한 관리

신규 멤버가 작업을 못 할 정도로 권한을 늦게 주는 것도 문제지만, production 권한을 초기에 넓게 주는 것은 더 큰 위험입니다.

---

7. AI 사용 정책

AI가 답한 내용은 공식 문서, 로컬 실행, 테스트 중 하나로 검증해야 합니다.

---

8. 멘토링 운영

왜 중요한가: 멘토가 한 명에게 모든 부담이 쏠리면 멘토도 입사자도 지칩니다. 역할을 분리해 한 사람당 시간 부담을 작게 만들어야 지속됩니다.

멘토링은 질문을 대신 해결해 주는 것이 아니라, 다음에 스스로 해결할 수 있는 경로를 알려주는 것입니다.

8.1 온보딩 상태 다이어그램

stateDiagram-v2
  [*] --> Preboard: 입사 확정
  Preboard --> Day0: 계정/권한 준비
  Day0 --> Day1: 장비 수령
  Day1 --> Week1: 환경 setup 완료
  Week1 --> RampUp: First PR merged
  RampUp --> Independent: 30일 체크포인트 통과
  Independent --> Owner: 90일 영역 owner
  Owner --> [*]: 정식 구성원

  RampUp --> Stuck: 반복 막힘 감지
  Stuck --> RampUp: 멘토링 강화 + 과제 재조정

  Independent --> Stuck: 피드백 부족
  Stuck --> Independent: 1:1 cadence 강화

8.2 질문 → 규칙 변환 루프

flowchart LR
  Q[입사자 질문] --> ANS[멘토 답변]
  ANS --> RECORD[학습 노트에 기록]
  RECORD --> REPEAT{같은 질문 3회+?}
  REPEAT -->|예| DOC[온보딩 문서/FAQ에 PR로 반영]
  REPEAT -->|아니오| KEEP[개인 노트로 유지]
  DOC --> FUTURE[다음 입사자가 셀프서비스로 해결]

비유: 도서관 사서가 자주 받는 질문은 안내판으로 만들어 두는 것과 같습니다. 같은 답을 100번 하지 않도록 시스템화합니다.

---

9. 온보딩 체크리스트

• [ ] 개발 환경 setup 문서가 최신인가
• [ ] 신규 멤버가 첫날 품질 게이트를 직접 실행했는가
• [ ] first issue와 reviewer가 사전에 지정되어 있는가
• [ ] 권한 목록과 만료/회수 절차가 있는가
• [ ] AI 사용 정책과 민감정보 기준을 설명했는가
• [ ] 30/60/90 기대치와 피드백 일정이 공유되었는가
• [ ] 신규 멤버가 개선해야 할 온보딩 문서를 PR로 제안할 수 있는가

---

10. 제외한 벤더 종속 항목

공통 개발 가이드에는 특정 원격 IDE, 특정 메신저, 특정 문서 도구, 특정 AI 코딩 도구, 특정 계정 자동화 workflow를 표준으로 포함하지 않습니다. 이 문서에는 어떤 회사와 도구에서도 적용 가능한 환경 준비, 권한, 첫 PR, 멘토링, 성장 체크포인트, AI 사용 정책만 남깁니다.

---

11. 로컬 품질 도구 온보딩

신규 구성원은 첫 PR 전에 품질 게이트를 "왜 실패하는지"까지 이해해야 합니다.

11.1 첫날 확인 명령

pnpm install --frozen-lockfile
pnpm exec husky init
pnpm exec commitlint --from=HEAD~1 --to=HEAD --verbose
pnpm exec secretlint "**/*"
pnpm test

• husky init으로 .husky/pre-commit과 prepare script가 만들어지는지 확인합니다.
• commitlint 실패 예시를 한 번 실행해 conventional commit type/scope/subject 규칙을 익힙니다.
• secretlint는 fixture나 문서 예시에서 false positive가 생길 수 있으므로 .secretlintignore와 허용 절차를 함께 설명합니다.
• MSW handler가 어디에 있고 local dev, unit/integration test, Storybook에서 어떻게 공유되는지 첫 PR에서 확인합니다.

11.2 첫 PR 리뷰 훈련

• CodeRabbit 같은 AI 리뷰 도구가 있다면 .coderabbit.yaml의 path instruction과 실제 comment를 함께 읽습니다.
• AI finding은 그대로 반영하지 않고 accept/reject/follow-up으로 분류합니다.
• TODO, FIXME, eslint-disable 주석이 필요한 경우 owner, issue, 제거 조건을 남기는 연습을 합니다.

---

실무 적용 가이드

언제 이 문서를 펼칠까

• 새 구성원이 환경 설정과 첫 PR에서 오래 막힐 때
• 권한, 보안, 배포 책임이 구두로만 전달될 때
• 도메인 학습 순서가 없어 질문이 반복될 때

적용 순서

1. Day 0에 계정, 권한, devcontainer/local setup을 준비한다.
2. Day 1에는 앱 실행, 테스트 실행, 문서 위치 찾기를 완료한다.
3. Week 1에는 작은 버그 수정 또는 문서 PR을 merge한다.
4. 30/60/90 목표를 코드, 운영, 도메인 이해로 나눈다.
5. 멘토링 질문과 막힌 지점을 문서 개선 backlog로 연결한다.

함께 두는 파일

• 온보딩 체크리스트와 setup script는 repository 루트에 둔다.
• 도메인별 학습 문서는 해당 feature/package README에 둔다.
• 첫 PR 예제는 실제 기능 폴더와 연결한다.

흔한 실수

• 권한을 너무 넓게 먼저 준다.
• 설정 실패를 개인 문제로 보고 자동화하지 않는다.
• AI 사용 정책과 데이터 반출 기준을 나중에 알려준다.
• 첫 PR 범위가 너무 커서 리뷰 학습이 어렵다.

PR 완료 기준

• [ ] 환경 설정이 재현 가능하다.
• [ ] 권한과 보안 교육 증거가 있다.
• [ ] 첫 PR이 작은 범위로 완료되었다.
• [ ] 30/60/90 피드백이 문서 개선으로 이어졌다.

추천 항목 실행 우선순위 매핑

• P1(7일 내) — 개발 환경, 권한, 첫 PR, 멘토링 루프 중 하나를 작은 변경 1건에 적용하고 증거(setup log)를 남긴다.
• P2(30일 내) — 온보딩 기준을 팀 템플릿, 체크리스트, CI 중 한 곳에 고정한다.
• P3(90일 내) — setup 소요 시간, 첫 PR lead time, 막힌 항목 수 추이를 보고 기준을 유지할지 조정할지 결정한다.
• 완료 기준 — 온보딩 오너가 증거와 철회 조건을 확인했다는 기록을 남긴다.

추천 항목 실행 체크리스트

• [ ] 1단계(7일) : 개발 환경, 권한, 첫 PR, 멘토링 루프 적용 대상을 1개로 좁힌다.
• [ ] 2단계(30일) : 증거(setup log, first PR, access checklist, 멘토 피드백)를 PR, ADR, 회고 중 한 곳에 연결한다.
• [ ] 3단계(60일) : setup 소요 시간, 첫 PR lead time, 막힌 항목 수가 기준 안에 들어왔는지 확인한다.
• [ ] 문제 대응 : 미달성 사유와 다음 조치, 중단 여부를 같은 기록에 남긴다.

추천 항목 실행 운영 규칙

• 실행 게이트 : 권한과 로컬 품질 도구가 같은 날에 확인됐는지 본다.
• 승인 체계 : 온보딩 오너가 영향 범위와 rollback 담당자를 적용 전에 확인한다.
• 재개 조건 : 첫 PR이 검증 게이트를 통과하면 다음 업무 범위를 넓힌다.
• 정지 조건 : 권한 누락이나 로컬 검증 실패가 반복되면 문서와 템플릿을 고친다.
• 리스크 점수 : 권한 범위, 미완료 setup, 멘토 부재로 산정한다.
• 리더 승인자 : 팀 리드/멘토가 최종 승인 책임을 맡는다.
• 승인 역할 : 온보딩 작성자, 검토자, 운영 확인자를 분리해 기록한다.
• 재평가 주기 : 30/60/90일 회고 때 체크리스트를 갱신한다.