30일 온보딩 로드맵과 커뮤니티 운영 매뉴얼

이 장의 목표: 모두가 전문가가 되는 것이 아니라, 같은 리듬을 갖는 것

옵시디언과 깃허브를 함께 쓰는 커뮤니티 시스템은 처음 보면 꽤 거창해 보입니다. 누군가는 "깃허브라니, 개발자들이 쓰는 것 아닌가요?"라고 묻고, 누군가는 "옵시디언은 설치했는데 파일이 어디 저장되는지 모르겠어요"라고 말합니다. 둘 다 자연스러운 반응입니다.

우리가 만들려는 것은 IT 전문가 집단의 개발 환경이 아닙니다. AI 활용 강사들이 매일 얻는 자료와 인사이트를 잃어버리지 않고 함께 키워 가는 지식 운영 습관입니다.

30일 온보딩의 최종 목표는 모든 구성원이 옵시디언과 깃허브를 완벽하게 다루는 것이 아닙니다. 목표는 훨씬 현실적입니다. 매일 기록하고, 정해진 위치에 저장하고, 주기적으로 커밋과 푸시를 하며, 공개 자료와 비공개 자료를 구분하는 최소 공통 습관을 만드는 것입니다.

다행히 비용 장벽은 낮습니다. 옵시디언은 업무나 조직 활동에 사용해도 상업용 라이선스가 필수가 아니며, 계정 없이도 로컬 기기에 평문 마크다운 파일로 데이터를 저장하는 도구입니다.¹ 깃허브 역시 Free 플랜에서 공개 저장소와 비공개 저장소를 만들 수 있으므로, 우리 커뮤니티는 처음부터 유료 도구를 구매하지 않고도 실험을 시작할 수 있습니다.²

이 장은 책의 마지막 장이지만, 실제로는 시작 버튼입니다. 앞 장들에서 배운 내용을 30일짜리 실행 계획으로 묶어, 커뮤니티 전체가 같은 시스템을 쓰도록 만드는 운영 매뉴얼로 사용하면 됩니다.

온보딩을 시작하기 전: 운영진이 먼저 준비할 것

구성원에게 "각자 알아서 설치해 오세요"라고 말하면, 온보딩은 높은 확률로 실패합니다. 초보자는 설치보다 "내가 지금 맞게 하고 있는지"에서 막힙니다. 그래서 운영진은 도구보다 먼저 길을 준비해야 합니다.

온보딩 시작 전 운영진은 공통 안내 문서 하나를 만듭니다. 문서 이름은 시작하기-여기부터.md처럼 누구나 찾을 수 있게 짓습니다. 이 문서는 볼트 최상위나 40_회의록/운영규칙 안에 둘 수 있습니다. 여기에는 설치 링크, 커뮤니티 폴더 구조, 파일명 규칙, 저장소 구분 기준, 문제가 생겼을 때 연락할 채널을 넣습니다. 특히 "혼자 해결하려고 오래 붙잡고 있지 말고, 스크린샷과 함께 공유한다"는 문장을 굵게 적어 둡니다.

운영진이 미리 준비할 기본 세트는 다음과 같습니다.

• 개인 연습용 볼트 예시와 커뮤니티 공통 볼트 예시

• 커뮤니티 표준 폴더 구조

• 강의 노트, AI 프롬프트, 수강생 질문, 도구 리뷰 템플릿

• 내부 공유용 Private 저장소와 공개 발행용 Public 저장소

• 신규 멤버 초대 절차와 권한 부여 기준

• 오류 보고 양식과 월간 정리일 운영표

이 책에서 사용할 커뮤니티 표준 폴더 구조는 다음과 같습니다.

AI강사커뮤니티_볼트/
├─ 00_Inbox
├─ 10_강의자료
├─ 20_프롬프트
├─ 30_사례모음
├─ 40_회의록
├─ 50_템플릿
├─ 60_공개후보
├─ 90_아카이브
└─ 99_Attachments

처음부터 완벽한 체계를 만들 필요는 없습니다. 폴더가 너무 많고 규칙이 복잡하면 초보자는 기록을 시작하기 전에 지칩니다. 처음 30일은 커뮤니티의 지식 창고를 완공하는 기간이 아니라, 모두가 같은 문으로 들어오는 기간입니다.

1주차: 옵시디언과 친해지기

1주차의 주제는 백업도, 협업도 아닙니다. 오직 "옵시디언은 내 컴퓨터 안의 폴더를 읽고 쓰는 마크다운 노트 도구"라는 감각을 몸에 익히는 것입니다. 옵시디언을 켰을 때 보이는 멋진 그래프 뷰나 플러그인은 잠시 잊어도 됩니다. 첫 주에는 파일 하나를 만들고, 저장 위치를 확인하고, 다시 열어 보는 것만으로도 충분합니다.

첫날에는 옵시디언을 설치하고 개인 볼트를 만듭니다. 볼트는 특별한 데이터베이스가 아니라 하나의 폴더입니다. 그 안에 .md 파일이 쌓입니다. 그래서 옵시디언을 지워도 폴더와 파일이 남아 있다면 노트는 사라지지 않습니다. 이 감각을 이해하면 도구에 끌려가는 느낌이 줄어듭니다.

둘째 날부터는 매일 노트 하나를 작성합니다. 주제는 거창하지 않아도 됩니다. "오늘 강의에서 받은 질문", "새로 발견한 AI 도구", "수강생이 헷갈려 한 개념", "다음 강의에 써 보고 싶은 프롬프트" 정도면 좋습니다. 목적은 훌륭한 글을 쓰는 것이 아니라 손이 옵시디언에 익숙해지는 것입니다.

1주차에 익힐 마크다운 문법은 최소한으로 제한합니다.

• ## 소제목으로 문단을 나누기

• - 항목으로 간단한 목록 만들기

• - [ ] 할 일로 체크박스 만들기

• [[노트 제목]]으로 다른 노트 연결하기

• #태그로 주제 표시하기

예를 들어 어느 강사가 수업 중 "챗GPT에게 역할을 주면 왜 답변이 달라지나요?"라는 질문을 받았다면, 다음처럼 남기면 됩니다.

## 상황
입문반 수업 중 수강생이 역할 부여 프롬프트의 효과를 질문했다.

## 내가 답한 내용
AI에게 역할을 주는 것은 답변의 관점을 정해 주는 일이라고 설명했다.

## 다음에 보완할 점
예시를 2개 준비하면 더 이해가 쉬울 것 같다.

#수강생질문 #프롬프트

이 정도면 충분합니다. 1주차의 성공 기준은 "잘 정리했는가"가 아니라 "매일 하나라도 남겼는가"입니다.

2주차: 무엇을 어디에 저장할지 정하기

2주차부터는 개인 기록을 커뮤니티 기록 방식에 맞춥니다. 많은 지식 창고가 실패하는 이유는 사람들이 기록을 안 해서가 아닙니다. 기록은 하는데 각자 다른 곳에, 다른 이름으로, 다른 형식으로 저장하기 때문에 나중에 찾지 못해서 실패합니다.

이 주의 핵심 문장은 하나입니다.

저장 위치를 고민하느라 기록을 멈추지 않게 한다.

운영진은 공통 폴더 구조를 배포합니다. 이 책의 표준 구조를 그대로 쓰면 됩니다.

00_Inbox          임시 메모와 아직 분류하지 않은 자료
10_강의자료       강의안, 실습 안내문, 체크리스트
20_프롬프트       프롬프트 예시와 실험 기록
30_사례모음       수강생 질문, 강의 성공·실패 사례, FAQ 후보
40_회의록         회의록, 운영 결정, 역할분담
50_템플릿         반복해서 쓸 문서 양식
60_공개후보       공개 가능성을 검토할 자료
90_아카이브       지금은 쓰지 않지만 보관할 자료
99_Attachments    이미지, PDF, 음성, 슬라이드 등 첨부파일

구성원에게는 복잡한 분류 철학보다 구체적인 예시가 필요합니다. "수강생이 수업 중 한 질문은 30_사례모음/수강생질문에 저장합니다." "내가 만든 프롬프트는 20_프롬프트에 저장합니다." "외부에 공개해도 될 것 같은 자료는 바로 공개 저장소에 올리지 말고 먼저 60_공개후보에 넣습니다." 이렇게 안내해야 합니다.

파일명 규칙도 단순하게 갑니다. 추천 규칙은 날짜_주제_작성자입니다.

2026-05-06_챗GPT역할부여질문_민지.md
2026-05-07_이미지생성프롬프트비교_도윤.md
2026-05-08_노션과옵시디언비교설명_서연.md

이름이 조금 길어도 괜찮습니다. 초보자에게 가장 위험한 파일명은 정리.md, 회의.md, 프롬프트.md입니다. 오늘은 알아볼 수 있지만 한 달 뒤에는 찾기 어렵습니다.

2주차에는 템플릿을 나누어 줍니다. 템플릿은 글쓰기의 빈칸 공포를 줄여 줍니다. 강의 사례 템플릿은 다음처럼 시작할 수 있습니다.

## 한 줄 요약

## 강의 상황

## 수강생 반응

## 사용한 설명 또는 프롬프트

## 다음에 개선할 점

## 공개 가능 여부
- [ ] Public 가능
- [ ] Private 유지
- [ ] 운영진 검토 필요

#강의사례

AI 프롬프트 템플릿은 조금 다르게 구성합니다.

## 목적

## 프롬프트 원문

```text
여기에 프롬프트를 붙여 넣습니다.

사용한 AI 도구

결과 요약

잘된 점

아쉬운 점

재사용 팁

#프롬프트

2주차 마지막 날에는 "저장 전 체크리스트"를 함께 읽습니다. 민감한 수강생 이름이 들어갔는지, 유료 강의 자료를 공개 후보에 넣지는 않았는지, 파일명이 너무 모호하지 않은지 확인합니다. 이 체크리스트가 있어야 초보자도 안심하고 기록을 시작할 수 있습니다.

## 3주차: 깃허브에 백업하는 손동작 익히기

3주차부터 깃허브가 등장합니다. 여기서 운영진이 꼭 기억해야 할 점이 있습니다. 초보자에게 Git 명령어를 외우게 하면 안 됩니다. 우리가 익혀야 하는 것은 명령어가 아니라 흐름입니다.

흐름은 네 단계입니다.

```text
변경 사항 확인 → 커밋 메시지 작성 → Push로 백업 → Pull로 최신본 받기

GitHub Desktop을 사용하면 이 흐름을 버튼 중심으로 연습할 수 있습니다. 첫날에는 GitHub 계정을 만들고 개인 연습용 Private 저장소를 만듭니다. 저장소를 Private으로 만드는 이유는 단순합니다. 아직 연습 중인 노트에는 실수로 개인정보나 내부 자료가 섞일 수 있기 때문입니다. 비공개 저장소도 접근 권한을 받은 사람은 볼 수 있으므로, Private은 "아무렇게나 적어도 안전하다"가 아니라 "외부에 공개되지는 않는다" 정도로 이해해야 합니다.

3주차 훈련은 반복이 핵심입니다. 하루에 한 번 다음 순서를 그대로 따라 합니다.

• 옵시디언에서 노트 하나를 수정한다.

• GitHub Desktop에서 변경된 파일을 확인한다.

• 커밋 메시지에 docs: 오늘 강의 질문 정리처럼 짧게 적는다.

• Commit 버튼을 누른다.

• Push 버튼을 눌러 깃허브에 올린다.

• 다음 시작 때 Pull 버튼을 눌러 최신 상태를 받는다.

커밋 메시지는 대단한 문장이 아니어도 됩니다. 다만 나중에 봤을 때 무엇을 했는지 짐작할 수 있어야 합니다. 우리 커뮤니티의 초보자용 규칙은 다음 네 가지 정도면 충분합니다.

note: 개인 노트 추가
prompt: 프롬프트 추가 또는 수정
fix: 오타나 잘못된 내용 수정
docs: 강의 자료나 설명 문서 정리

예를 들어 prompt: 블로그 글쓰기 프롬프트 개선, fix: 수강생 질문 파일명 수정, docs: 공개 후보 체크리스트 추가처럼 쓰면 됩니다.

3주차 후반에는 일부러 실수하는 연습을 합니다. 테스트 노트를 하나 만들고, 커밋하고, 푸시한 뒤, 파일을 삭제합니다. 그리고 이전 커밋에서 복구하는 과정을 함께 실습합니다. 이 연습은 매우 중요합니다. 백업 시스템의 진짜 가치는 저장할 때가 아니라 되돌릴 때 드러납니다. 한 번 복구를 경험한 사람은 삭제나 수정 실수를 덜 두려워합니다.

Obsidian Git 플러그인을 사용하는 구성원은 자동 백업 설정을 켤 수 있습니다. 다만 초보자에게 처음부터 완전 자동화를 권하지는 않습니다. 플러그인에는 일정 간격 자동 백업, 시작 시 Pull, 백업 시 Push 같은 설정이 있지만,³ 처음 일주일은 수동으로 흐름을 익힌 뒤 자동화를 켜는 편이 좋습니다. 손동작을 모른 채 자동화만 켜면, 문제가 생겼을 때 무엇이 어디서 꼬였는지 알기 어렵습니다.

4주차: 개인 백업에서 공동 운영으로 확장하기

4주차는 커뮤니티 운영 단계입니다. 이제 질문이 바뀝니다. "내 노트를 어떻게 백업하지?"에서 "우리 자료를 어떻게 안전하게 나누고, 일부는 어떻게 공개하지?"로 넘어갑니다.

저장소는 최소 두 개로 나눕니다. 하나는 내부 공유용 Private 저장소이고, 다른 하나는 공개 발행용 Public 저장소입니다. 두 저장소를 분리하는 이유는 실수를 줄이기 위해서입니다. 한 공간 안에서 "이건 공개, 이건 비공개"를 태그만으로 관리하면 언젠가 사고가 납니다. 공개와 비공개는 물리적으로 다른 저장소에 두는 편이 안전합니다.

내부 공유용 Private 저장소에는 커뮤니티 운영에 필요한 실제 자료를 둡니다. 유료 강의 커리큘럼, 수강생 질문 원문, 내부 회의 기록, 강사별 노하우, 아직 검증되지 않은 프롬프트는 이곳에 둡니다. 반대로 Public 저장소에는 공개해도 커뮤니티와 수강생 모두에게 문제가 없는 자료만 올립니다. 예를 들어 샘플 템플릿, 일반적인 도구 사용 팁, 홍보용 안내 자료, 개인정보가 제거된 예시 노트가 여기에 해당합니다.

공개 후보를 판단할 때는 다음 기준을 사용합니다.

• 특정 수강생, 기관, 기업, 강사의 신원이 드러나지 않는가?

• 유료 강의의 핵심 자료를 그대로 공개하지 않는가?

• 외부 자료의 저작권을 침해하지 않는가?

• 커뮤니티 내부 의사결정이나 민감한 피드백이 포함되어 있지 않은가?

• 공개했을 때 우리 커뮤니티의 전문성과 신뢰를 높이는가?

이 기준을 통과하지 못하면 Public으로 보내지 않습니다. 애매하면 공개하지 않는 것이 원칙입니다. 공개는 나중에 해도 되지만, 한 번 공개된 자료를 완전히 회수하기는 어렵습니다.

4주차 마지막에는 공동 운영 리허설을 합니다. 운영진이 예시 자료 하나를 Private 저장소에 올리고, 구성원은 Pull로 최신본을 받습니다. 이후 각자 템플릿에 맞춰 노트 하나를 추가하고, 커밋한 뒤 Push합니다. 충돌이 생기면 당황하지 않고 운영진에게 스크린샷을 보냅니다. 충돌 해결 실습까지 마치면, 커뮤니티는 드디어 "같은 시스템을 쓰는 팀"이 됩니다.

30일 실행표

아래 실행표는 그대로 복사해 커뮤니티 온보딩 문서에 넣어도 좋습니다. 하루에 20~40분이면 충분하도록 설계했습니다. 중요한 것은 속도가 아니라 중도 이탈을 줄이는 것입니다.

30일을 모두 끝냈는데도 누군가는 여전히 Push와 Pull을 헷갈릴 수 있습니다. 괜찮습니다. 헷갈리면 다시 표를 보고 따라 하면 됩니다. 시스템은 천재를 위한 것이 아니라, 평범한 사람이 반복할 수 있도록 만드는 장치입니다.

운영진 매뉴얼: 신규 멤버가 들어왔을 때

신규 멤버 온보딩은 매번 즉흥적으로 하면 운영진이 지칩니다. 아래 순서를 고정해 두면, 새 사람이 들어와도 커뮤니티 시스템이 흔들리지 않습니다.

첫째, 신규 멤버에게 시작하기-여기부터.md 문서를 보냅니다. 이 문서에는 설치부터 첫 커밋까지의 순서가 들어 있어야 합니다.

둘째, GitHub 사용자명을 받아 내부 Private 저장소에 초대합니다. 권한은 처음부터 관리자 권한으로 주지 않습니다. 일반 구성원은 Write 권한이면 충분합니다. 저장소 설정을 바꾸거나 멤버를 삭제할 수 있는 권한은 운영진에게만 둡니다.

셋째, 저장소별 사용 목적을 설명합니다. 개인 연습 저장소는 실수해도 되는 공간입니다. 내부 Private 저장소는 커뮤니티 자산을 모으는 공간입니다. Public 저장소는 외부에 보여 주기 위한 전시 공간입니다. 이 세 공간을 구분하지 못하면, 언젠가 내부 자료가 공개 저장소에 올라갈 수 있습니다.

넷째, 첫 주에는 반드시 짝을 붙입니다. IT 이해도가 높은 구성원 한 명이 초보 구성원 한 명의 설치와 첫 Push를 도와줍니다. 단, 대신 해 주는 것이 아니라 화면을 보며 안내만 합니다. 온보딩의 목표는 빠른 해결이 아니라 스스로 한 번 해 보는 경험입니다.

커밋 메시지와 충돌 보고 규칙

커밋 메시지는 커뮤니티의 일기장입니다. 나중에 문제가 생겼을 때 "언제 무엇이 바뀌었는지"를 찾게 해 줍니다. 그래서 너무 짧게 수정, 업데이트, aaa처럼 적지 않습니다. 우리 커뮤니티에서는 다음 형식을 권장합니다.

종류: 무엇을 했는지

예시는 다음과 같습니다.

note: 수강생 질문 3건 정리
prompt: 카드뉴스 생성 프롬프트 추가
fix: 강의 사례 파일명 오타 수정
docs: 공개 후보 체크리스트 보완
archive: 지난달 회의 노트 아카이브 이동

충돌이 발생했을 때의 규칙은 더 단순해야 합니다. 초보자는 충돌 화면을 보는 순간 겁을 먹습니다. 이때 "알아서 해결해 보세요"라고 하면 다음부터 기록을 하지 않습니다. 따라서 공식 규칙은 이렇게 정합니다.

문제가 생기면 혼자 해결하지 않습니다. 먼저 현재 화면을 캡처합니다. 그다음 어떤 작업을 하던 중이었는지 한 문장으로 씁니다. 마지막으로 운영진 지원 채널에 올립니다.

보고 양식은 다음처럼 고정합니다.

## 문제 상황
예: Push를 눌렀더니 빨간 오류 메시지가 나왔습니다.

## 직전에 한 행동
예: 수강생 질문 노트를 수정하고 커밋했습니다.

## 사용 중인 기기
예: Windows 노트북 / MacBook / Android

## 관련 파일
예: 30_사례모음/수강생질문/2026-05-06_질문정리_민지.md

## 스크린샷
이미지 첨부

이 양식은 초보자를 보호할 뿐 아니라 운영진의 시간을 아껴 줍니다. "안 돼요"라는 말만으로는 도와줄 수 없지만, 스크린샷과 직전 행동이 있으면 대부분의 문제는 빠르게 좁혀집니다.

월간 정리일: 지식 창고를 숨 쉬게 하는 날

지식베이스는 만들 때보다 유지할 때 차이가 납니다. 한 달 동안 열심히 기록하면 반드시 중복 노트, 애매한 파일명, 잘못된 위치의 자료가 생깁니다. 이것은 실패가 아니라 자연스러운 현상입니다. 그래서 우리에게는 월간 정리일이 필요합니다.

월간 정리일은 한 달에 한 번, 60~90분이면 충분합니다. 운영진은 회의처럼 무겁게 만들지 말고 "창고 환기하는 날"처럼 운영합니다. 각자 자기 노트를 점검하고, 공개 후보를 검토하고, 오래된 임시 노트를 아카이브로 옮깁니다.

월간 정리일의 기본 순서는 다음과 같습니다.

• 00_Inbox에 쌓인 임시 노트 정리하기

• 파일명이 모호한 노트 수정하기

• 잘못된 폴더에 들어간 노트 이동하기

• 중복된 프롬프트나 강의 사례 합치기

• 60_공개후보 노트에서 개인정보와 유료 자료 포함 여부 확인하기

• Private 저장소와 Public 저장소의 최신 백업 상태 점검하기

• 오래된 자료를 90_아카이브로 옮기기

• 다음 달에 개선할 운영 규칙 1개만 정하기

여기서 욕심을 내면 안 됩니다. 한 번에 모든 태그를 정리하고, 모든 노트를 연결하고, 모든 템플릿을 고치려 하면 다음 달 정리일은 열리지 않습니다. 매달 하나씩만 개선해도 6개월 뒤에는 놀라울 만큼 안정된 지식 창고가 됩니다.

백업 상태 점검표

운영진은 한 달에 한 번 백업 상태를 확인합니다. 백업은 "아마 되고 있겠지"라고 믿는 순간 약해집니다. 확인해야 안전합니다.

점검은 간단합니다. GitHub 웹사이트에 들어가 최근 커밋 시간이 있는지 확인합니다. 누가 마지막으로 Push했는지 봅니다. Private 저장소에 공개 후보 자료가 섞여 있는 것은 괜찮지만, Public 저장소에 비공개 자료가 섞여 있으면 즉시 조치합니다. 이미지나 PDF처럼 큰 파일이 계속 쌓이는지도 봅니다. 깃허브 저장소는 마크다운처럼 가벼운 텍스트를 관리하기에 좋지만, 대용량 첨부파일 창고로 쓰기 시작하면 점점 무거워집니다.

구성원 개인에게는 다음 네 문장만 기억하게 해도 충분합니다.

시작할 때 Pull.
기록한 뒤 Commit.
마무리할 때 Push.
문제 생기면 스크린샷.

이 네 문장이 습관이 되면, 커뮤니티 지식 운영의 절반은 성공한 것입니다.

30일 이후: 우리 커뮤니티의 운영 리듬

30일이 끝나면 도구 도입 프로젝트가 끝나는 것이 아닙니다. 이제 운영 리듬이 시작됩니다. 매일 기록하고, 매주 공유하고, 매월 정리합니다. 이 리듬이 쌓이면 옵시디언은 개인 메모장이 아니라 커뮤니티의 기억이 됩니다. 깃허브는 개발자 전용 서비스가 아니라 우리 지식의 타임머신이 됩니다.

처음에는 누군가 파일명을 틀릴 것입니다. 누군가는 Pull을 잊고 Push할 것입니다. 누군가는 60_공개후보와 Public 저장소를 헷갈릴 것입니다. 괜찮습니다. 운영 규칙은 사람을 혼내기 위해 있는 것이 아니라, 실수를 작게 만들기 위해 있는 것입니다.

우리의 목표는 완벽한 시스템이 아닙니다. 강의 현장에서 얻은 작은 깨달음이 사라지지 않는 커뮤니티, 좋은 프롬프트가 한 사람의 노트북에만 갇히지 않는 커뮤니티, 공개할 수 있는 지식은 세상과 나누고 보호해야 할 자료는 안전하게 지키는 커뮤니티입니다.

30일 동안 할 일은 많아 보이지만, 사실 한 가지 연습을 반복하는 것입니다. 오늘 배운 것을 적고, 정해진 곳에 넣고, 안전하게 백업하고, 나눌 수 있는 것과 지켜야 할 것을 구분하는 일. 그 습관이 쌓이면 우리 커뮤니티의 지식은 더 이상 흩어지지 않습니다. 각자의 노트가 연결되고, 연결된 노트가 강의력이 되고, 강의력이 다시 커뮤니티의 영향력이 됩니다.

이제 첫 노트를 만들 차례입니다.

참고

¹Obsidian is now free for work

²Pricing · Plans for every developer · GitHub

³Obsidian Git 플러그인 사용하기