프로젝트 구조 설계와 팀 온보딩

📖 이론10분

🛠️ 실습15분

🎯 미션5분

"잘 설계된 구조는 설명이 필요 없다."

— 리처드 버크민스터 풀러 (R. Buckminster Fuller, 건축가·발명가)

🎯 오늘의 학습 목표

팀 구조에 맞는 프로젝트 설계 3가지 방식을 설명할 수 있다.
부서별·환경별·클라이언트별 분리 방식의 차이를 구분할 수 있다.
팀 공용 n8n 가이드라인 문서를 작성할 수 있다.

방식 1 — 부서별 분리 (일반 기업에 가장 적합)

가장 일반적인 구조입니다. 팀별로 프로젝트를 나눠서 관리합니다.

부서별 분리 구조

text

📁 공용 프로젝트        ← 전사 공통 워크플로우
📁 마케팅팀 프로젝트   ← SNS, 리드 수집, 뉴스레터
📁 영업팀 프로젝트     ← CRM 연동, 계약 알림
📁 HR팀 프로젝트       ← 온보딩, 휴가 관리
📁 개발팀 프로젝트     ← 배포 알림, 버그 트래킹

방식 2 — 환경별 분리 (개발/운영 분리)

워크플로우를 개발/검증/운영 단계로 나눠서 관리합니다. 실수로 라이브 워크플로우를 건드리는 사고를 방지할 수 있어요.

환경별 분리 구조

text

📁 Dev 프로젝트        ← 테스트 중인 워크플로우
📁 Staging 프로젝트   ← 검증 중인 워크플로우
📁 Production 프로젝트 ← 실제 서비스에 쓰이는 워크플로우

방식 3 — 클라이언트별 분리 (에이전시, 프리랜서)

외부 클라이언트마다 프로젝트를 분리해서 크리덴셜과 워크플로우를 완전히 격리합니다.

클라이언트별 분리 구조

text

📁 A 클라이언트 프로젝트
📁 B 클라이언트 프로젝트
📁 공용 유틸리티 프로젝트

팀 공용 n8n 가이드라인 문서 템플릿

markdown

# [회사명] n8n 팀 가이드라인

## 1. 기본 규칙
- 새 워크플로우는 반드시 Dev 프로젝트에서 먼저 테스트
- Production 워크플로우 수정 전 팀장 승인 필수
- 크리덴셜은 개인적으로 생성하지 말고 팀 크리덴셜 사용

## 2. 네이밍 규칙
형식: [팀약자]_[동작]_[대상]_v[버전]
예시: mkt_send_newsletter_v1
      sales_sync_crm_daily_v2

## 3. 노드 이름 규칙
- 기본 이름(HTTP Request, Set 등) 그대로 쓰지 말 것
- 기능을 설명하는 이름 사용: "고객데이터_가져오기", "이메일주소_추출"

## 4. Sticky Note 필수 작성 항목
- 워크플로우 목적
- 주의 사항
- 최종 수정일 + 수정자

## 5. 오류 처리
- 모든 외부 API 호출에 Error 핸들러 추가
- 중요한 워크플로우에는 반드시 Slack 오류 알림 연결

🛠️ DAY 16 실습

Step 1우리 팀에 맞는 프로젝트 구조 결정

3가지 방식 중 팀 상황에 맞는 방식 선택
프로젝트 목록과 각 프로젝트에 들어갈 워크플로우 초안 작성
n8n에서 결정한 구조대로 프로젝트 생성

Step 2팀 가이드라인 문서 작성

위 템플릿을 Notion 또는 Google Docs에 복사
회사/팀 상황에 맞게 내용 수정
팀원들과 공유 및 피드백 반영

Step 3기존 워크플로우 정리

현재 Personal 공간에 있는 워크플로우를 적절한 프로젝트로 이동
워크플로우 이름을 네이밍 규칙에 맞게 수정
각 워크플로우에 Sticky Note 추가

🚀 DAY 16 미션

팀에 맞는 프로젝트 구조를 확정하고 팀 가이드라인 문서를 완성하세요.

☑️ 미션 체크리스트

프로젝트 구조 방식 결정 완료 (부서별/환경별/클라이언트별)
프로젝트 구조대로 n8n에 프로젝트 생성 완료
팀 가이드라인 문서 작성 완료 (네이밍 규칙 포함)
기존 워크플로우 프로젝트 이동 및 이름 정리 완료

💡 힌트: 가이드라인 문서는 처음부터 완벽하게 만들려 하지 마세요. 팀이 쓰면서 계속 업데이트하는 살아있는 문서로 만드는 게 더 중요합니다.

🎯 성공 기준: 프로젝트 구조가 정리되고 팀 가이드라인 문서가 팀원과 공유된 상태