커뮤니티 내부 공유를 위한 협업 규칙 만들기

도구보다 먼저 약속을 만든다

여러 강사가 같은 옵시디언 Vault와 깃허브 저장소를 쓰기 시작하면 처음 며칠은 꽤 신납니다. 누군가는 강의 사례를 올리고, 누군가는 프롬프트를 정리하고, 또 누군가는 새 AI 도구 리뷰를 남깁니다. 흩어져 있던 인사이트가 한곳에 쌓이기 시작하니 "드디어 우리 커뮤니티의 지식창고가 생겼다"는 느낌이 듭니다.

그런데 조금 지나면 이상한 일이 생깁니다.

"이 파일은 누가 만든 거죠?"

"이 자료 공개해도 되는 건가요?"

"제가 수정했는데 다른 분 수정 내용이 사라진 것 같아요."

"강의 사례 폴더에 프롬프트가 들어가 있는데요?"

이런 혼란은 옵시디언이나 깃허브를 못 써서 생기는 문제가 아닙니다. 대부분은 약속이 없어서 생깁니다. 도구는 파일을 저장해 줄 뿐, 누가 무엇을 어디에 어떻게 올릴지는 대신 정해주지 않습니다.

이번 장의 핵심은 단순합니다.

협업의 시작은 기능을 더 배우는 것이 아니라, 모두가 같은 방식으로 일하기로 약속하는 것이다.

앞 장에서 우리는 Private 저장소를 커뮤니티의 기본 집으로, Public 저장소를 검토가 끝난 전시장으로 나누었습니다. 이제 그 집 안에서 여러 사람이 부딪히지 않고 움직이는 규칙을 만들 차례입니다.

저장소의 문부터 정한다: Public, Private, 권한

협업 규칙의 첫 번째 질문은 "어떤 플러그인을 쓸까?"가 아닙니다. 먼저 물어야 할 질문은 이것입니다.

"이 저장소는 누구에게 열려 있는가?"

우리 커뮤니티의 기본 원칙은 다음과 같습니다.

내부 자료 저장소 = Private 기본
공개 자료 저장소 = Public 별도 운영
공개 후보 자료 = Private 안의 60_공개후보에서 먼저 검토

Private 저장소에는 회의록, 강의안 초안, 수강생 사례, 내부 프롬프트 실험, 운영 전략이 들어갑니다. Public 저장소에는 공개해도 되는 튜토리얼, 일반 프롬프트 예시, 도구 사용 팁, 공개 세미나 자료만 들어갑니다.

그다음은 권한입니다. 깃허브 조직 저장소에서는 사람이나 팀별로 저장소 접근 역할을 다르게 줄 수 있습니다. GitHub는 저장소 역할을 Read, Triage, Write, Maintain, Admin처럼 나누며, 각 사람에게 필요한 만큼만 권한을 주는 방식을 권장합니다.¹

비전공자 강사 커뮤니티라면 처음에는 너무 많은 역할을 쓰지 말고, 다음 세 가지로 단순하게 시작해도 충분합니다.

여기서 가장 중요한 원칙은 "친하니까 Admin"이 아닙니다. Admin은 저장소 설정을 바꾸거나 저장소를 삭제할 수도 있는 강한 권한입니다. 커뮤니티 대표, 기술 담당자, 백업 담당자처럼 실제 관리 책임이 있는 사람에게만 주는 편이 안전합니다.

신규 멤버에게는 처음부터 Write 권한을 주기보다 Read로 시작하는 것이 좋습니다. 1~2주 동안 폴더 구조, 파일명 규칙, 공개·비공개 기준을 익힌 뒤 Write 권한으로 올립니다. 이것은 불신이 아니라 온보딩입니다. 운전면허를 따기 전에는 조수석에서 길을 먼저 익히는 것과 같습니다.

권한 부여 규칙은 볼트 최상위의 커뮤니티_협업규칙.md 또는 40_회의록/운영규칙/협업규칙.md 같은 문서에 적어둡니다.

## 저장소 권한 원칙

- 내부 자료 저장소는 Private으로 운영한다.
- 신규 멤버는 Read 권한으로 시작한다.
- 정기 기여자는 운영진 확인 후 Write 권한을 부여한다.
- Admin 권한은 최소 인원에게만 부여한다.
- Public 저장소 업로드 권한은 게시 담당자 중심으로 운영한다.

이 문서는 법전이 아닙니다. 모두가 같은 방향을 보게 해주는 안내판입니다.

문서마다 신분증을 붙인다: 표준 머리말

옵시디언 문서는 결국 마크다운 파일입니다. 깃허브에 올라가면 회의록.md, 프롬프트.md, 도구리뷰.md 같은 파일로 보입니다. 그런데 파일을 열었을 때 작성자도 없고, 수정일도 없고, 공개 가능 여부도 없다면 어떻게 될까요?

나중에 누군가는 파일을 열고 이렇게 말하게 됩니다.

"이거 좋은데 공개해도 되나요?"

그리고 아무도 대답하지 못합니다.

이 문제를 막는 가장 쉬운 방법은 문서 맨 위에 표준 머리말을 붙이는 것입니다. 옵시디언에서는 이런 정보를 프론트매터라고 부르기도 합니다. 어렵게 생각하지 마세요. 문서의 신분증입니다.

기본 형식은 이렇게 시작합니다.

---
type: 회의록
author: 김강사
created: 2026-05-06
updated: 2026-05-06
visibility: private
review_status: 초안
owner: 운영팀
related_issue: 
---

각 항목의 뜻은 다음과 같습니다.

처음부터 완벽하게 쓰려고 하면 부담스럽습니다. 그래도 author, created, updated, visibility, review_status 다섯 가지는 꼭 남기는 습관을 들이는 편이 좋습니다. 이 다섯 가지만 있어도 "누가 만들었는지, 언제 바뀌었는지, 공개해도 되는지, 검토가 끝났는지"를 알 수 있습니다.

문서 종류별로 조금씩 다른 템플릿을 50_템플릿에 만들어두면 더 편합니다.

회의록 템플릿은 이렇게 쓸 수 있습니다.

---
type: 회의록
author: 
created: 2026-05-06
updated: 2026-05-06
visibility: private
review_status: 기록완료
owner: 운영팀
related_issue: 
---

## 회의 정보

일시:
참석자:
주제:

## 결정한 내용

## 해야 할 일

- [ ] 담당자 / 할 일 / 마감일

## 다음 회의에서 확인할 것

프롬프트 템플릿은 이렇게 만들 수 있습니다.

---
type: 프롬프트
author: 
created: 2026-05-06
updated: 2026-05-06
visibility: private
review_status: 초안
owner: 프롬프트팀
use_case: 강의준비
related_issue: 
---

## 언제 쓰는 프롬프트인가

## 프롬프트 원문

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

## 사용 예시

## 잘 작동한 조건

## 주의할 점

## 공개 전 확인

- [ ] 개인정보가 없는가?
- [ ] 유료 강의 핵심 내용이 그대로 들어가지 않았는가?
- [ ] 외부 자료 출처가 필요한가?

강의 사례 템플릿은 더 조심해야 합니다.

---
type: 강의사례
author: 
created: 2026-05-06
updated: 2026-05-06
visibility: private
review_status: 초안
owner: 사례관리팀
sensitive: yes
related_issue: 
---

## 상황 요약

실제 이름, 학교명, 회사명, 연락처는 적지 않습니다.

## 수강생의 어려움

## 강사가 시도한 방법

## 결과와 배운 점

## 공개 가능성 검토

- [ ] 가상 사례로 바꾸었는가?
- [ ] 특정인을 추측할 단서가 없는가?
- [ ] 공개용 문서로 따로 복사했는가?

템플릿의 힘은 생각보다 큽니다. 사람마다 문서 쓰는 방식이 달라도, 맨 위 신분증과 기본 구조만 같으면 나중에 찾고 검토하기가 훨씬 쉬워집니다.

파일명은 검색을 위해 짓는다

초보 팀에서 가장 빨리 무너지는 규칙이 파일명입니다. 처음에는 누구나 가볍게 만듭니다.

회의.md
프롬프트.md
좋은자료.md
최종.md
진짜최종.md

하지만 세 달 뒤에는 이 파일들이 지뢰밭이 됩니다. 어떤 회의인지, 어떤 프롬프트인지, 무엇의 최종인지 알 수 없습니다.

파일명은 예쁘게 짓는 것이 아니라, 나중에 찾기 쉽게 짓는 것입니다. 우리 커뮤니티에서는 날짜, 주제, 작성자를 포함하는 규칙을 추천합니다.

YYYY-MM-DD_주제_작성자.md

예를 들면 다음과 같습니다.

2026-05-06_정기회의_김강사.md
2026-05-06_강의안초안프롬프트_이강사.md
2026-05-06_챗GPT이미지생성도구리뷰_박강사.md

주제별 폴더 안에서는 날짜를 앞에 붙이면 시간순으로 정렬되어 편합니다. 프롬프트처럼 계속 업데이트되는 자료는 날짜보다 주제를 앞에 두는 방식도 가능합니다.

강의안초안생성_김강사.md
수강생질문분류_이강사.md
도구비교표작성_박강사.md

중요한 것은 한 번 정한 규칙을 모두가 같이 쓰는 것입니다. 한글이냐 영어냐보다 일관성이 더 중요합니다.

폴더도 마찬가지입니다. 4장에서 설계한 구조를 바탕으로 협업용 저장소는 다음 구조를 표준으로 삼습니다.

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

민감한 사례는 30_사례모음/수강생질문이나 30_사례모음/강의실패사례 안에 두되, 문서 상단에 visibility: private, sensitive: yes처럼 표시합니다. 폴더명에만 의존하지 않고 문서 안에도 경고등을 켜 두는 방식입니다.

같은 파일을 동시에 고치지 않는 것이 최고의 충돌 해결법이다

깃허브와 Obsidian Git 플러그인을 쓰면 여러 사람이 같은 저장소를 무료로 백업하고 공유할 수 있습니다. 하지만 협업에서 꼭 알아야 할 위험이 있습니다. 두 사람이 같은 파일의 같은 부분을 동시에 고치면 충돌이 생길 수 있습니다.

충돌, 영어로는 merge conflict라고 합니다. 쉽게 말해 Git이 이렇게 묻는 상황입니다.

"김강사님 버전도 있고, 이강사님 버전도 있는데, 어느 쪽을 살릴까요?"

Git은 똑똑하지만 독심술사는 아닙니다. 같은 문장을 두 사람이 다르게 바꾸면 자동으로 판단하기 어렵습니다. Obsidian Git을 쓰는 팀에서도 여러 사용자가 같은 Vault를 함께 편집할 때 충돌이 생길 수 있다는 점이 자주 문제로 언급됩니다. 그래서 협업 문서에서는 작업 전 자주 pull을 하고, 명확한 커밋 메시지를 남기며, 팀이 같은 구조로 문서를 관리하는 습관을 강조합니다.²

초보 팀에게 가장 좋은 충돌 해결법은 충돌을 멋지게 고치는 기술이 아닙니다. 애초에 같은 파일을 동시에 고치지 않는 운영 방식입니다.

다음 세 가지 약속만으로도 충돌이 크게 줄어듭니다.

예를 들어 20_프롬프트/강의안초안생성.md라는 핵심 문서가 있다고 합시다. 여러 사람이 이 파일을 동시에 고치면 충돌 가능성이 큽니다. 대신 강사별 초안 파일을 둡니다.

20_프롬프트/
├─ 00_공통프롬프트/
│  └─ 강의안초안생성.md
├─ 초안_김강사_강의안초안생성_개선안.md
├─ 초안_이강사_강의안초안생성_사례추가.md
└─ 초안_박강사_강의안초안생성_질문형.md

그다음 담당자가 초안들을 검토해 00_공통프롬프트의 문서에 반영합니다. 조금 느려 보이지만, 초보 팀에서는 이 방식이 훨씬 안전합니다.

수정 전 알림 문구도 정해두면 좋습니다. 단체 채팅방이나 슬랙, 디스코드에서 이렇게 말하면 됩니다.

[수정 시작] 20_프롬프트/00_공통프롬프트/강의안초안생성.md
담당: 김강사
예상 종료: 오늘 16:30

수정이 끝나면 이렇게 남깁니다.

[수정 완료] 강의안초안생성.md 업데이트 후 push 완료
커밋 메시지: Update lecture draft prompt examples
확인 부탁: 이강사님

이런 메시지는 사소해 보이지만, 협업에서는 신호등 역할을 합니다. 신호등이 있으면 차가 많아도 덜 부딪힙니다.

초보 팀의 기본 작업 순서: pull → 수정 → commit → push

여러 사람이 같은 저장소를 쓸 때는 작업 순서가 중요합니다. GitHub Desktop을 쓰든 Obsidian Git 플러그인을 쓰든 기본 흐름은 같습니다.

pull → 수정 → commit → push

우리말로 풀어보면 이렇습니다.

최신 자료 가져오기 → 내 컴퓨터에서 수정하기 → 수정 기록 남기기 → 깃허브에 올리기

작업 전에는 반드시 pull을 합니다. pull은 깃허브에 올라온 최신 변경사항을 내 컴퓨터로 가져오는 행동입니다. 이 단계를 빼먹으면 다른 사람이 이미 고친 낡은 파일 위에 내가 다시 덮어쓸 수 있습니다.

수정을 마친 뒤에는 commit을 합니다. commit은 "여기까지 수정했습니다"라고 기록을 찍는 일입니다. 마지막으로 push를 합니다. push는 내 컴퓨터에 남긴 commit을 깃허브 저장소로 올리는 일입니다.

초보 팀의 하루 작업 루틴은 이렇게 정하면 좋습니다.

## 하루 작업 루틴

1. 작업 시작 전 GitHub Desktop에서 Fetch origin 또는 Pull origin을 누른다.
2. 오늘 수정할 파일이 공동 문서라면 채팅방에 수정 시작을 알린다.
3. 옵시디언에서 문서를 수정한다.
4. 수정이 끝나면 GitHub Desktop에서 변경 파일 목록을 확인한다.
5. 커밋 메시지를 쓰고 Commit을 누른다.
6. Push origin을 눌러 깃허브에 올린다.
7. 공동 문서라면 채팅방에 수정 완료를 알린다.

Obsidian Git 플러그인으로 자동 백업을 켜둔 팀이라도 이 원칙은 같습니다. 자동 백업은 편리하지만, 협업 규칙을 대신하지 않습니다. 특히 여러 사람이 동시에 같은 파일을 만지는 팀에서는 자동 commit·push 간격을 너무 짧게 잡기보다, 작업 전 pull과 작업 후 push 습관을 먼저 익히는 편이 안전합니다.

커밋 메시지는 미래의 우리에게 쓰는 한 줄 메모다

커밋 메시지를 어렵게 생각하는 분들이 많습니다. 개발자처럼 멋진 영어를 써야 할 것 같고, 문법을 틀리면 안 될 것 같습니다. 그렇지 않습니다.

커밋 메시지의 목적은 하나입니다.

"무엇이 바뀌었는지 나중에 알 수 있게 하기."

나쁜 예시는 다음과 같습니다.

수정
업데이트
작업
최종
ㅎㅎ

좋은 예시는 다음과 같습니다.

Add meeting notes for May community session
Update prompt template for lecture planning
Fix typo in Obsidian onboarding guide
Remove private comments from public candidate note

한글로 써도 괜찮습니다.

5월 정기회의 회의록 추가
강의안 작성 프롬프트 예시 보강
공개후보 문서에서 내부 코멘트 삭제
도구리뷰 템플릿 수정

커뮤니티에서는 커밋 메시지 앞에 작업 종류를 붙이는 방식도 좋습니다.

[회의록] 5월 정기회의 내용 추가
[프롬프트] 강의안 초안 생성 예시 보강
[공개검토] 수강생 식별 가능 표현 삭제
[도구리뷰] Claude 활용 사례 업데이트

이렇게 해두면 나중에 깃허브 기록을 볼 때 흐름이 보입니다. 커밋 메시지는 보고서가 아니라 영수증입니다. 언제 무엇을 했는지 확인할 수 있으면 충분합니다.

GitHub Issues를 작업 카드로 쓴다

파일 안에서만 일을 관리하면 곧 한계가 옵니다. 누가 무엇을 해야 하는지, 어떤 문서가 검토 중인지, 어떤 자료가 공개 후보인지 한눈에 보기 어렵습니다. 이때 GitHub Issues를 작업 카드처럼 쓰면 좋습니다.

GitHub Issues는 원래 버그, 작업, 아이디어, 토론 등을 추적하기 위한 기능입니다. GitHub 공식 문서에서도 Issues를 팀이나 프로젝트의 일을 계획하고 추적하는 도구로 설명합니다.³

비전공자에게 Issue라는 말은 낯설 수 있습니다. 그냥 "작업 카드"라고 이해하면 됩니다. 포스트잇 한 장에 할 일을 적어 칠판에 붙이는 것과 비슷합니다. 다만 그 포스트잇이 깃허브 안에 있고, 담당자와 마감일, 관련 문서 링크를 붙일 수 있습니다.

우리 커뮤니티에서는 다음 네 가지 라벨부터 시작하면 충분합니다.

Issue 제목은 짧고 행동이 보이게 씁니다.

[정리 필요] 5월 세미나 질의응답 회의록으로 정리
[검증 필요] Gemini 이미지 기능 무료 사용 범위 확인
[공개 후보] 강의안 초안 프롬프트 공개용으로 다듬기
[수정 요청] GitHub Desktop 백업 장 설명 보완

Issue 본문에는 세 가지를 꼭 적습니다.

## 작업 내용
무엇을 해야 하나요?

## 관련 문서
- 20_프롬프트/강의안초안생성.md

## 완료 기준
- [ ] 개인정보 제거
- [ ] 예시 2개 이상 추가
- [ ] 검토자 확인

담당자: @username
마감일: 2026-05-10

이렇게 하면 일이 파일 밖으로 나옵니다. 머릿속이나 단체 채팅방에 흘러가는 것이 아니라, 저장소 안에서 보이는 작업 카드가 됩니다.

처음에는 모든 일을 Issue로 만들 필요는 없습니다. 오타 하나 고치는 일까지 카드로 만들면 오히려 피곤합니다. 대신 다음 경우에는 Issue를 만드는 것을 추천합니다.

• 여러 사람이 함께 봐야 하는 문서 수정

• 공개 여부 검토가 필요한 자료

• 마감일과 담당자가 필요한 작업

• 나중에 왜 수정했는지 기록이 필요한 결정

• 회의에서 나온 후속 작업

Issue를 닫는 기준도 정해야 합니다. "대충 한 것 같음"이 아니라 완료 기준 체크박스가 모두 끝났을 때 닫습니다. 닫힌 Issue는 사라지는 것이 아니라 기록으로 남습니다. 나중에 "이 문서를 왜 이렇게 바꿨지?" 하고 궁금할 때 좋은 단서가 됩니다.

Pull Request는 나중에, 중요한 공개 자료부터

깃허브 협업을 검색하면 Pull Request, 줄여서 PR이라는 말이 자주 나옵니다. PR은 "제가 이렇게 바꾸려고 하는데, 합쳐도 될까요?"라고 요청하는 절차입니다. GitHub의 Pull Request 리뷰에서는 변경 내용에 의견을 남기고, 승인하거나, 수정 요청을 할 수 있습니다.⁴

개발팀에서는 PR 중심 협업이 매우 흔합니다. 하지만 IT 비전공자 강사 커뮤니티가 첫날부터 PR, 브랜치, 리뷰 승인 규칙을 모두 쓰려고 하면 부담이 큽니다. 도구를 배우다가 정작 자료 정리를 못 하게 될 수 있습니다.

그래서 우리 커뮤니티는 단계적으로 갑니다.

1단계: main에 직접 작업하되 pull → 수정 → commit → push 습관 만들기
2단계: 중요한 공동 문서는 Issue로 담당자와 검토자 지정하기
3단계: Public 저장소에 올라갈 자료만 PR로 검토하기
4단계: 익숙해지면 핵심 문서도 PR 리뷰 적용하기

처음부터 모든 내부 메모에 PR을 요구하지 마세요. 회의록 하나 올리는데 PR을 만들고 리뷰를 기다려야 한다면 아무도 기록하지 않게 됩니다. 대신 Public 저장소에 올라갈 자료에는 PR을 적용하는 것이 좋습니다. 공개 자료는 외부에 보이기 때문입니다.

PR 리뷰에서 선택지는 보통 세 가지입니다.

Public 저장소의 공개 자료 검토 규칙은 이렇게 단순하게 정할 수 있습니다.

## Public 자료 PR 규칙

- 공개 자료는 바로 main에 올리지 않고 PR로 올린다.
- 최소 1명의 검토자가 Approve해야 병합한다.
- 수강생 사례, 외부 자료 인용, 유료 강의 내용이 포함된 경우 Request changes를 적극 사용한다.
- 검토자는 내용의 좋고 나쁨보다 공개 안전성을 먼저 확인한다.

여기서 "병합"은 PR의 변경 내용을 실제 저장소에 합치는 일입니다. 초보자에게는 "검토가 끝난 초안을 정식 자료실에 넣는 것"이라고 설명하면 됩니다.

공개 자료 검토표를 만든다

Public 저장소로 옮기는 자료는 내용 검토와 공개 안전성 검토를 분리해서 보면 좋습니다. 글이 훌륭해도 공개하면 안 되는 정보가 들어 있을 수 있고, 반대로 안전하지만 너무 어려워서 초보자에게 맞지 않을 수도 있습니다.

공개 자료 검토표는 50_템플릿/공개자료_검토표_템플릿.md로 만들어 두고, 실제 검토할 때는 60_공개후보의 문서 옆에 복사해 사용합니다.

## 공개 자료 검토표

문서명:
작성자:
검토자:
검토일:
관련 Issue/PR:

## 1. 공개 안전성

- [ ] 개인정보가 없다.
- [ ] 수강생을 추측할 수 있는 단서가 없다.
- [ ] 내부 회의 내용이나 운영 전략이 없다.
- [ ] 유료 강의 핵심 자료가 그대로 들어 있지 않다.
- [ ] Private 문서로 연결되는 링크가 없다.

## 2. 저작권과 출처

- [ ] 외부 자료 문장을 그대로 복사하지 않았다.
- [ ] 참고한 자료의 출처를 남겼다.
- [ ] 이미지와 첨부파일의 사용 가능 여부를 확인했다.

## 3. 독자 친절도

- [ ] 초보자가 이해할 수 있는 말로 설명했다.
- [ ] 필요한 단계가 빠지지 않았다.
- [ ] 예시가 있다.
- [ ] 제목과 파일명이 내용을 잘 보여준다.

## 최종 판단

- [ ] 공개 가능
- [ ] 수정 후 공개 가능
- [ ] 공개 보류

검토 의견:

민감한 내용은 좋은 자료여도 Private에 남긴다

강사 커뮤니티의 가장 귀한 자료는 현장 사례입니다. 수강생이 어디에서 막혔는지, 어떤 설명을 들었을 때 이해했는지, 어떤 프롬프트가 실제 수업에서 효과가 있었는지는 책이나 공식 문서에서 얻기 어려운 자산입니다.

하지만 바로 그 이유 때문에 조심해야 합니다. 생생한 자료일수록 누군가의 실제 상황과 연결되어 있을 가능성이 높습니다.

민감한 내용은 다음 원칙으로 다룹니다.

원본 사례 = Private
익명화한 요약 = 60_공개후보
일반화한 교훈 = Public 가능

예를 들어 원본 사례가 이렇다고 합시다.

서울 강서구에서 학원을 운영하는 50대 여성 수강생 A님은 2026년 봄 과정에서 ChatGPT로 학부모 안내문을 쓰는 데 어려움을 겪었다.

공개 후보에서는 이렇게 바꿉니다.

소규모 교육기관 운영자는 AI로 안내문을 작성할 때 문체와 대상 독자를 구체적으로 지정하지 못해 결과물이 어색해지는 경우가 있다.

Public 자료에서는 더 일반화합니다.

안내문 작성 프롬프트에는 대상 독자, 전달 상황, 원하는 문체를 함께 넣으면 결과가 좋아집니다.

원본의 생생함은 Private에 남기고, 공개 자료에는 교훈만 가져갑니다. 이것이 내부 지식과 외부 신뢰를 동시에 지키는 방법입니다.

API 키, 비밀번호, 결제 정보, 개인 연락처는 어떤 경우에도 저장소에 넣지 않는 것이 좋습니다. Private 저장소라고 해서 완전히 안심하면 안 됩니다. Private은 초대받은 사람만 볼 수 있다는 뜻이지, 비밀 금고라는 뜻은 아닙니다.

역할을 정하면 갈등이 줄어든다

협업에서 갈등은 "누가 잘못했는가"보다 "누가 결정하는지 모르는 상황"에서 자주 생깁니다. 문서마다 책임자가 없으면 모두가 조금씩 손대고, 결국 아무도 책임지지 않는 파일이 됩니다.

우리 커뮤니티에서는 최소한 다음 역할을 정합니다.

인원이 적다면 한 사람이 여러 역할을 맡아도 됩니다. 하지만 "작성자"와 "검토자"는 가능하면 분리하세요. 내가 쓴 문서의 위험은 내가 가장 잘 못 봅니다. 글쓴이는 내용에 빠져 있고, 검토자는 독자와 운영자의 눈으로 봅니다.

역할분담 문서는 볼트 최상위나 40_회의록/운영규칙 안에 둡니다.

## 커뮤니티 저장소 역할분담

| 영역 | 담당자 | 백업 담당자 | 비고 |
|---|---|---|---|
| 40_회의록 | 김강사 | 이강사 | 회의록, 규칙 |
| 20_프롬프트 | 이강사 | 박강사 | 공통 프롬프트 관리 |
| 30_사례모음 | 박강사 | 김강사 | 수강생 질문과 사례 |
| 60_공개후보 | 운영팀 | 게시 담당자 | 공개 검토 |
| Public 저장소 | 게시 담당자 | 운영진 | PR 후 반영 |

이 표 하나만 있어도 "이 폴더는 누구에게 물어봐야 하지?"라는 시간이 줄어듭니다.

우리 커뮤니티의 협업 규칙 초안

이제 지금까지의 내용을 하나의 운영 문서로 묶어보겠습니다. 아래 내용을 그대로 복사해 커뮤니티_협업규칙.md 또는 40_회의록/운영규칙/협업규칙.md로 만들어도 됩니다.

# 커뮤니티 협업 규칙

## 1. 저장소 원칙

- 내부 자료 저장소는 Private으로 운영한다.
- 공개 자료는 별도 Public 저장소에만 올린다.
- 공개 후보 자료는 먼저 Private 저장소의 60_공개후보 폴더에서 검토한다.

## 2. 권한 원칙

- 신규 멤버는 Read 권한으로 시작한다.
- 정기 기여자는 운영진 확인 후 Write 권한을 받는다.
- Admin 권한은 최소 인원에게만 부여한다.
- Public 저장소 게시 권한은 게시 담당자 중심으로 운영한다.

## 3. 문서 작성 원칙

- 모든 문서에는 표준 머리말을 붙인다.
- author, created, updated, visibility, review_status는 반드시 작성한다.
- 파일명은 날짜_주제_작성자 형식을 기본으로 한다.
- 개인정보와 수강생 식별 정보는 공개후보나 Public 저장소로 옮기지 않는다.

## 4. 수정 원칙

- 작업 전에는 반드시 pull 한다.
- 공동 문서를 수정할 때는 채팅방에 수정 시작을 알린다.
- 같은 파일을 여러 사람이 동시에 수정하지 않는다.
- 수정 후에는 의미 있는 커밋 메시지를 남기고 push 한다.

## 5. Issue 사용 원칙

- 정리 필요, 검증 필요, 공개 후보, 수정 요청은 Issue로 관리한다.
- Issue에는 담당자, 마감일, 관련 문서 링크를 적는다.
- 완료 기준 체크박스가 끝나면 Issue를 닫는다.

## 6. Public 공개 원칙

- Public 자료는 공개 검토표를 통과해야 한다.
- 개인정보, 내부 의견, 유료 강의 핵심 내용은 제거한다.
- 공개 자료는 가능하면 PR로 검토 후 반영한다.
- Public 저장소에 올린 뒤 README를 업데이트한다.

이 규칙은 처음부터 완벽할 필요가 없습니다. 한 달 운영해 보고 불편한 부분을 고치면 됩니다. 좋은 규칙은 처음부터 완성된 문서가 아니라, 실제 운영을 견디며 다듬어진 문서입니다.

첫 주 온보딩 실습

협업 규칙은 읽기만 하면 잘 익혀지지 않습니다. 손으로 한 번 해봐야 합니다. 신규 멤버 온보딩 첫 주에는 다음 실습을 추천합니다.

첫째 날에는 Private 저장소를 열람하고 폴더 구조를 익힙니다. 이때 아무 파일도 수정하지 않습니다. 커뮤니티_협업규칙.md, 역할분담.md, README.md를 읽고, 궁금한 점을 Issue나 채팅방에 남깁니다.

둘째 날에는 자기소개 테스트 문서를 만듭니다. 위치는 00_Inbox/온보딩연습/ 폴더로 제한합니다.

00_Inbox/온보딩연습/2026-05-06_온보딩연습_홍길동.md

문서에는 표준 머리말을 붙입니다.

---
type: 온보딩연습
author: 홍길동
created: 2026-05-06
updated: 2026-05-06
visibility: private
review_status: 연습
owner: 운영팀
related_issue: 
---

## 내가 주로 하는 강의

## 내가 정리하고 싶은 자료

## 옵시디언·깃허브에서 아직 헷갈리는 점

셋째 날에는 GitHub Desktop 또는 Obsidian Git으로 pull → 수정 → commit → push를 연습합니다. 커밋 메시지는 이렇게 씁니다.

[온보딩] 홍길동 연습 문서 추가

넷째 날에는 Issue를 하나 만들어봅니다.

[정리 필요] 홍길동 온보딩 중 헷갈린 용어 정리

다섯째 날에는 다른 사람의 온보딩 문서를 읽고 오타나 개선 의견을 남깁니다. 단, 직접 고치기 전에 작성자에게 물어보는 연습을 합니다.

이 실습의 목표는 대단한 자료를 만드는 것이 아닙니다. 저장소 안에서 안전하게 걷는 법을 배우는 것입니다.

협업 규칙은 커뮤니티의 안전벨트다

옵시디언과 깃허브를 함께 쓰면 우리 커뮤니티는 강력한 지식베이스를 가질 수 있습니다. 하지만 여러 사람이 함께 쓰는 순간부터 기술보다 운영이 중요해집니다.

누가 볼 수 있는지 정해야 합니다. 누가 고칠 수 있는지 정해야 합니다. 파일은 어디에 넣을지, 문서 맨 위에는 무엇을 남길지, 공개 전에는 누가 확인할지 정해야 합니다.

이 규칙들은 처음에는 조금 번거롭게 느껴질 수 있습니다. 하지만 규칙이 없어서 생기는 혼란에 비하면 훨씬 가볍습니다. 파일 하나를 잘못 공개해 수습하는 시간, 충돌 때문에 사라진 내용을 복구하는 시간, 누가 최신본을 갖고 있는지 찾는 시간을 생각하면, 협업 규칙은 귀찮은 절차가 아니라 시간을 아껴주는 장치입니다.

우리의 목표는 개발자처럼 보이는 것이 아닙니다. AI 활용 강사들이 각자의 현장 지식을 안전하게 모으고, 검토된 자료를 함께 키우고, 공개 가능한 인사이트를 세상과 나누는 것입니다.

도구는 날개입니다. 하지만 날개가 있어도 비행 규칙이 없으면 서로 부딪힙니다. 이제 우리 커뮤니티는 각자 날아오르되, 같은 하늘의 약속을 가지고 움직일 준비가 되었습니다.

참고

¹Repository roles for an organization - GitHub Docs

²Leveraging Obsidian with GitHub for Collaborative Documentation

³GitHub Issues documentation - GitHub Docs

⁴About pull request reviews - GitHub Docs