원격 팀 온보딩 설계: 새 팀원이 첫 30일 안에 성과를 내는 시스템

A사 온보딩 실패 분석 타임라인
============================================

[Day 1]
- HR에서 장비 발송 지연 (노트북 3일 후 도착)
- 계정 생성 미완료: GitHub, AWS, Jira 접근 불가
- "일단 문서 읽어보세요" → 200페이지 Confluence 링크 전달

[Week 1]
- 개발환경 셋업에 3일 소요 (문서 outdated)
- 멘토 미배정, 질문할 사람 불명확
- 팀 미팅에 참여했지만 컨텍스트 부재로 이해 불가

[Week 2-3]
- 첫 태스크 배정: "이 버그 좀 고쳐주세요"
- 코드베이스 이해 없이 버그 수정 시도 → 좌절
- PR 리뷰에서 팀 컨벤션 위반 지적 반복

[Month 2]
- 여전히 "새로운 사람" 취급
- 중요한 의사결정 회의에서 배제
- 자신감 하락, 이직 고려 시작

[Month 4]
- 퇴사 통보: "팀에 소속감을 느끼지 못했습니다"
============================================

근본 원인:
- 구조화된 온보딩 프로세스 부재
- 명시적 기대치 미설정
- 사회적 연결 프로그램 없음
- 온보딩 성과 측정 미비

# 30-60-90일 온보딩 계획

## 팀원 정보

- 이름: \_\_\_
- 직책: \_\_\_
- 입사일: \_\_\_
- 버디: \_\_\_
- 매니저: \_\_\_

---

## Phase 1: 학습 (Day 1-30)

### 목표

- [ ] 팀의 미션, 비전, OKR 이해
- [ ] 제품/서비스의 핵심 사용자 흐름 5가지 직접 체험
- [ ] 주요 시스템 아키텍처 다이어그램 읽고 질문 3개 이상 하기
- [ ] 개발환경 완전 셋업 (로컬 빌드, 테스트 실행)
- [ ] 코드베이스 주요 디렉토리 구조 파악

### 기술 학습

- [ ] 핵심 기술 스택 문서 읽기 (목록 별도 제공)
- [ ] 최근 3개월 주요 PR 5개 리뷰 읽기
- [ ] CI/CD 파이프라인 구조 이해
- [ ] 모니터링/알림 대시보드 접근 및 확인

### 관계 구축

- [ ] 팀 전원과 1:1 커피챗 (30분씩)
- [ ] 유관 팀 핵심 인원 2명 이상과 인사
- [ ] 버디와 주 3회 체크인

### 마일스톤

- [ ] 첫 번째 PR 제출 (Day 5까지)
- [ ] 첫 번째 PR 머지 (Day 10까지)
- [ ] 온콜 쉐도잉 1회 참여

---

## Phase 2: 기여 (Day 31-60)

### 목표

- [ ] 스프린트 태스크 독립적으로 완료 (3건 이상)
- [ ] 코드 리뷰에 참여하여 의미 있는 피드백 제공
- [ ] 기존 문서 1건 이상 개선

### 기술 심화

- [ ] 담당 서비스 도메인 깊이 이해
- [ ] 장애 대응 프로세스 숙지
- [ ] 성능 모니터링 지표 해석 능력

### 마일스톤

- [ ] 중간 규모 기능 구현 1건
- [ ] 팀 미팅에서 기술 공유 1회

---

## Phase 3: 자립 (Day 61-90)

### 목표

- [ ] 프로젝트 또는 이니셔티브 리드 1건
- [ ] 온콜 독립 수행
- [ ] 주니어 팀원 멘토링 또는 문서 작성으로 지식 환원

### 마일스톤

- [ ] 기술 설계 문서(RFC) 작성 1건
- [ ] 팀 회고에서 프로세스 개선 제안 1건
- [ ] 90일 리뷰 미팅 완료

# 버디 1:1 체크인 질문 목록

## Week 1 (매일 15분)

1. 오늘 개발환경 셋업하면서 막히는 부분 있었나요?
2. 읽은 문서 중 이해가 안 되는 부분이 있나요?
3. 팀 미팅에서 모르는 용어나 약어가 있었나요?
4. 점심/커피 시간에 다른 팀원들과 대화할 기회가 있었나요?
5. 가장 궁금한 점 하나만 꼽는다면?

## Week 2-3 (격일 20분)

1. 코드베이스에서 가장 이해하기 어려운 부분은 어디인가요?
2. 현재 진행 중인 태스크에서 도움이 필요한 부분은?
3. 팀 프로세스(PR 리뷰, 스프린트 등) 중 개선했으면 하는 점은?
4. 지금까지의 온보딩 경험에서 가장 좋았던 점은?
5. 비동기 소통에서 불편한 점이 있나요?

## Week 4 (주 2회 30분)

1. 팀에서 자신의 역할이 명확하게 느껴지나요?
2. 기술적으로 더 깊이 배우고 싶은 영역은?
3. 다른 팀원들과의 협업은 어떻게 진행되고 있나요?
4. 만약 다시 첫 날로 돌아간다면, 뭘 먼저 알았으면 했나요?
5. 팀 문화 중 가장 좋은 점과 아쉬운 점은?

## Month 2-3 (주 1회 30분)

1. 독립적으로 태스크를 완료할 수 있다고 느끼나요?
2. 기술적인 의사결정에 자신감이 생겼나요?
3. 온콜이나 장애 대응에 대한 준비가 되었다고 느끼나요?
4. 팀에 기여하고 있다는 느낌이 드나요?
5. 이 팀에서 6개월 후 어떤 모습이길 원하나요?

#!/bin/bash
# onboarding-setup.sh
# 새 팀원 개발환경 자동 셋업 스크립트
# 사용법: curl -fsSL https://internal.company.com/setup.sh | bash

set -euo pipefail

echo "=========================================="
echo "  Welcome! 개발환경 자동 셋업을 시작합니다"
echo "=========================================="

# 1. 필수 도구 설치
echo "[1/6] 필수 도구 설치 중..."
if [[ "$(uname)" == "Darwin" ]]; then
    # macOS
    if ! command -v brew &> /dev/null; then
        /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    fi
    brew bundle --file=- <<BREWFILE
brew "git"
brew "node"
brew "python@3.11"
brew "docker"
brew "kubectl"
brew "awscli"
brew "jq"
brew "gh"
BREWFILE
else
    # Linux
    sudo apt-get update && sudo apt-get install -y \
        git nodejs npm python3 python3-pip docker.io kubectl awscli jq
fi

# 2. 레포지토리 클론
echo "[2/6] 레포지토리 클론 중..."
WORKSPACE="$HOME/workspace"
mkdir -p "$WORKSPACE"
cd "$WORKSPACE"

repos=(
    "company/main-api"
    "company/web-frontend"
    "company/infrastructure"
    "company/shared-libs"
)

for repo in "${repos[@]}"; do
    if [ ! -d "$(basename "$repo")" ]; then
        gh repo clone "$repo"
    fi
done

# 3. 환경 변수 설정
echo "[3/6] 환경 변수 설정 중..."
cp "$WORKSPACE/main-api/.env.example" "$WORKSPACE/main-api/.env.local"
echo ">> .env.local 파일을 확인하고 필요한 값을 채워주세요"

# 4. Docker 컨테이너 실행
echo "[4/6] 로컬 개발용 Docker 컨테이너 시작..."
cd "$WORKSPACE/main-api"
docker compose -f docker-compose.dev.yml up -d

# 5. 의존성 설치 및 빌드
echo "[5/6] 의존성 설치 중..."
cd "$WORKSPACE/web-frontend"
npm ci
cd "$WORKSPACE/main-api"
pip install -r requirements.txt

# 6. 검증
echo "[6/6] 셋업 검증 중..."
cd "$WORKSPACE/main-api"
if python -m pytest tests/smoke/ -q; then
    echo ">> 스모크 테스트 통과!"
else
    echo ">> 스모크 테스트 실패. 버디에게 문의하세요."
    exit 1
fi

echo ""
echo "=========================================="
echo "  셋업 완료! 다음 단계:"
echo "  1. .env.local 파일에 API 키 입력"
echo "  2. 'make run' 으로 로컬 서버 시작"
echo "  3. http://localhost:3000 접속 확인"
echo "=========================================="

Slack 웰컴 메시지 템플릿
============================================

안녕하세요 [이름]님, [팀명]에 오신 것을 환영합니다!

우리 팀에 합류해 주셔서 정말 기쁩니다.
원활한 온보딩을 위해 아래 정보를 참고해 주세요.

------------------------------------------
핵심 채널 안내
------------------------------------------
#team-engineering     : 팀 공지 및 일반 대화
#team-eng-pr-review   : PR 리뷰 요청
#team-eng-incidents   : 장애 알림 및 대응
#random               : 잡담, 밈, 일상 공유
#til                  : Today I Learned 공유

------------------------------------------
첫 주 체크리스트
------------------------------------------
1. 프로필 사진과 자기소개 업데이트
2. #team-engineering 채널에 자기소개 남기기
3. 온보딩 가이드 읽기: [링크]
4. 개발환경 셋업 스크립트 실행
5. 버디([버디 이름])와 첫 미팅 잡기

------------------------------------------
유용한 링크
------------------------------------------
- 온보딩 체크리스트: [Notion 링크]
- 시스템 아키텍처 문서: [링크]
- 팀 위키: [링크]
- 휴가/재택 신청: [링크]

궁금한 점이 있으면 언제든 이 채널에 질문해 주세요.
"바보 같은 질문"은 없습니다!

# ADR-0015: 결제 서비스를 마이크로서비스로 분리

## 상태

승인됨 (2025-08-15)

## 배경

결제 모듈이 모놀리스의 배포 속도를 저하시키고 있다.
결제 관련 변경이 전체 시스템 테스트를 트리거하여
배포 주기가 주 1회로 제한되었다.

## 결정

결제 서비스를 독립 마이크로서비스로 분리한다.
통신은 gRPC, 이벤트는 Kafka를 사용한다.

## 결과

- 결제 서비스 독립 배포 가능 (일 2-3회)
- 모놀리스 배포 시간 40% 단축
- 운영 복잡도 증가 (서비스 간 통신 관리)

## 대안 검토

1. 모놀리스 내 모듈 분리 → 배포 문제 해결 안 됨
2. 서버리스(Lambda) → 콜드 스타트 문제로 SLO 미달

# 우리 팀의 문화 가이드

## 소통 원칙

- 비동기 우선: 즉각적인 응답을 기대하지 않는다. 긴급한 것만 DM으로.
- 투명성: 의사결정 과정을 공개 채널에서 진행한다.
- 글쓰기 문화: 중요한 제안은 문서로 정리한 후 논의한다.

## 코드 리뷰

- PR은 24시간 이내에 첫 리뷰를 단다.
- "LGTM"만 다는 것은 지양하고, 구체적인 피드백을 제공한다.
- 리뷰어가 2명 이상 승인해야 머지할 수 있다.
- 코드 스타일 관련 피드백은 린터에 맡기고, 로직에 집중한다.

## 미팅 규칙

- 미팅은 25분 또는 50분 단위로 잡는다 (전환 시간 확보).
- 아젠다 없는 미팅은 거절해도 된다.
- 카메라는 선택 사항이다. 강제하지 않는다.
- 미팅 노트를 반드시 남기고 공유한다.

## 장애 대응

- 장애 발생 시 비난하지 않는다 (Blameless Culture).
- 장애 후 48시간 이내에 포스트모템을 작성한다.
- 포스트모템의 목적은 시스템 개선이지, 책임 추궁이 아니다.

## 업무 시간

- 코어 타임: 오전 10시 - 오후 4시 (KST 기준)
- 코어 타임 외에는 각자의 일정에 맞게 유연하게 근무한다.
- 야근과 주말 근무를 기대하지 않는다.

추천 하이브리드 온보딩 모델 구조
============================================

[자율 학습 (Self-Service)]
  - 문서화된 온보딩 가이드
  - 녹화된 아키텍처 설명 영상
  - 자동화된 개발환경 셋업
  - FAQ 데이터베이스
      |
      v
[버디 지원 (Buddy-Based)]
  - 매일/격일 체크인
  - 질문 응답 및 컨텍스트 제공
  - 문화적 가이드
  - 비공식적 관계 구축
      |
      v
[매니저 관리 (Structured)]
  - 주간 1:1 미팅
  - 30-60-90일 목표 설정 및 리뷰
  - 성과 피드백
  - 경력 개발 논의
      |
      v
[팀 참여 (Social)]
  - 버추얼 커피챗
  - 팀 빌딩 활동
  - 페어 프로그래밍 세션
  - 점심 시간 수다 채널

============================================

# 온보딩 30일 피드백 설문

## 전반적 만족도

1. 온보딩 경험에 대한 전반적인 만족도는? (1-10)
2. 이 팀을 친구에게 추천하겠는가? (1-10, NPS)

## 정보 접근성

3. 필요한 정보를 쉽게 찾을 수 있었나요? (매우 어려움 ~ 매우 쉬움)
4. 문서화가 부족하다고 느낀 영역이 있나요? (주관식)

## 관계 구축

5. 팀원들과 충분히 교류할 기회가 있었나요? (1-5)
6. 버디와의 관계는 도움이 되었나요? (1-5)
7. 매니저와의 1:1은 유용했나요? (1-5)

## 기술 온보딩

8. 개발환경 셋업은 순조로웠나요? (1-5)
9. 코드베이스를 이해하는 데 얼마나 걸렸나요?
10. 첫 번째 의미 있는 기여까지 몇 일이 걸렸나요?

## 개선 제안

11. 온보딩에서 가장 좋았던 점은? (주관식)
12. 온보딩에서 가장 아쉬웠던 점은? (주관식)
13. 다음 신규 입사자를 위해 바꾸고 싶은 것은? (주관식)

매니저용 온보딩 체크리스트
============================================

[입사 2주 전]
  [ ] 장비 주문 및 배송 (노트북, 모니터, 키보드)
  [ ] 계정 생성 요청 (이메일, Slack, GitHub, Jira, AWS)
  [ ] 버디 선정 및 요청
  [ ] 30-60-90일 계획 초안 작성
  [ ] 팀원들에게 신규 입사자 소개 메시지 발송
  [ ] 첫 주 미팅 캘린더 세팅

[입사 전날]
  [ ] 웰컴 메시지 준비
  [ ] 첫날 아젠다 확정
  [ ] 모든 계정 접근 권한 확인
  [ ] 온보딩 문서 최신 상태 검증

[Day 1]
  [ ] 팀 채널에 공식 소개
  [ ] 1:1 미팅: 기대치 공유, 30일 목표 합의
  [ ] 개발환경 셋업 지원
  [ ] 필수 채널 초대

[Week 1]
  [ ] 매일 15분 체크인
  [ ] good-first-issue 배정
  [ ] 주요 미팅 초대 (스탠드업, 스프린트 등)
  [ ] 아키텍처 오버뷰 세션

[Week 2-4]
  [ ] 주 2회 체크인
  [ ] 코드 리뷰 참여 독려
  [ ] 온콜 쉐도잉 기회 제공
  [ ] 30일 리뷰 미팅 스케줄링

[Month 2]
  [ ] 독립 태스크 배정 확대
  [ ] 60일 중간 리뷰
  [ ] 성장 영역 논의

[Month 3]
  [ ] 프로젝트 리드 기회 제공
  [ ] 90일 종합 리뷰
  [ ] 온보딩 피드백 설문 실시
  [ ] 다음 분기 목표 설정

============================================

신규 팀원용 셀프 체크리스트
============================================

[환경 셋업]
  [ ] 노트북 수령 및 기본 설정 완료
  [ ] 이메일, Slack, GitHub 로그인 확인
  [ ] VPN 연결 테스트
  [ ] 개발환경 셋업 스크립트 실행 완료
  [ ] 로컬에서 프로젝트 빌드 및 테스트 통과

[학습]
  [ ] 팀 위키의 온보딩 가이드 읽기
  [ ] 시스템 아키텍처 다이어그램 확인
  [ ] 주요 서비스 3개의 README 읽기
  [ ] 최근 포스트모템 2건 읽기
  [ ] 팀 ADR 문서 훑어보기

[관계]
  [ ] Slack 프로필 업데이트 (사진, 소개)
  [ ] 팀 채널에 자기소개 남기기
  [ ] 버디와 첫 미팅 완료
  [ ] 팀원 전원과 1:1 커피챗 예약
  [ ] 유관 팀 담당자 1명 이상 인사

[기여]
  [ ] good-first-issue PR 제출
  [ ] 첫 PR 머지 완료
  [ ] 코드 리뷰 코멘트 1건 이상 작성
  [ ] 발견한 문서 오류 1건 이상 수정

============================================

온보딩 지속 개선 사이클
============================================

   [1. 측정]
   Time to First Commit, 만족도 설문,
   90일 이직률 데이터 수집
        |
        v
   [2. 분석]
   병목 지점 식별, 피드백 패턴 분석,
   이전 사이클 대비 변화 확인
        |
        v
   [3. 개선]
   문서 업데이트, 프로세스 조정,
   새로운 자동화 도입
        |
        v
   [4. 실행]
   다음 신규 입사자에게 적용
        |
        v
   [1. 측정] (반복)

============================================