커뮤니티 에서 협업 하 기 툴킷 | 툴킷 
 툴킷 소개 
 협력 적 커뮤니티 툴킷 
 커뮤니티 101 
 커뮤니티 오 거나 이 저 되 기 
 커뮤니티 가이드 만들 기 
 커뮤니티 행동 강령 세우 기 
 커뮤니티 활동 시작 하 기 
 커뮤니티 모임 가이드 
 커뮤니티 에서 협업 하 기 
 왜 협업 방법 을 이야기 해야 할까요 ? 
 커뮤니케이션 방식 이해 하 기 
 비 동기식 협업 의 원칙 
 도움 이 되 는 방법 들 
 함께 읽 으면 좋 은 글 
 협력 적 의사 결정 
 항해 하 는 조직 101 
 DIY 정당 101 
 프로젝트 팀 으로 커뮤니티 만들 기 
 커뮤니티 준비 하 기 
 커뮤니티 소통 하 기 
 프로젝트 공동 작업 하 기 
 프로그램 함께 만들 기 
 캠페인 가이드 
 캠페인 101 
 캠 페이 너 인생 게임 
 시민 참여 플랫 폼 운영 가이드 
 데 모스 X 운영 가이드 
 0 . 운영 가이드 1 . 1 
 2 . 운영 계획 세우 기 
 3 . 시민 제안 단계 
 4 . 시민 토론 단계 
 5 . 실행 
 6 . 기관 제안 
 7 . 홍보 운영 
 8 . 데 모스 X 의 로드맵 
 공론 장 가이드 
 시민 제안 워크숍 
 의제 선정 및 기획 
 시민 참여 공론 장 
 실험장 
 찾아가 는 시민 제안 
 플랫 폼 가이드 
 빠 띠 그룹스 
 빠 띠 타운 홀 
 기타 유용 한 팁 
 빠 띠 의 실험 들 
 # 커뮤니티 에서 협업 하 기 툴킷 
 수다 를 떨 다 자연스레 하 고 싶 은 프로젝트 가 생겼 나요 ? 그런데 커뮤니티 에서 어떻게 해야 할지 막막 하 다구요 ? < 커뮤니티 에서 협업 하 기 가이드 > 는 ' 즐겁 고 효과 적 으로 커뮤니티 에서 함께 일 하 는 방법 ' 을 소개 합니다 . 
 # 왜 협업 방법 을 이야기 해야 할까요 ? 
 서로 의 소중 한 시간 과 스타일 을 존중 하 며 공동 의 목표 를 달성 할 수 있 어요 . 
 불 필요 한 오해 와 갈등 을 줄이 고 즐겁 게 일 할 수 있 어요 . 
 무리 는 NO ! 지치 지 않 고 지속 가능 한 커뮤니티 를 만들 어 보 아요 . 
 # 커뮤니케이션 방식 이해 하 기 
 협업 의 기본 은 커뮤니케이션 , 커뮤니케이션 방식 ( 문화 , 규칙 , 도구 ) 을 이해 하 고 적절히 활용 하 면 협업 을 보다 매끄럽 게 할 수 있 어요 . 커뮤니티 에서 만난 사람 들 은 각자 본업 이 있 는 경우 가 많 지요 . 같 은 시간 에 소통 하 기 쉽 지 않 고 각자 가능 한 시간 에 협업 에 참여 합니다 . 이렇게 동시 간 에 얼굴 을 대면 하 지 않 고 , 서로 다른 시간 에 메시지 를 남겨 소통 하 는 방식 을 비 동기식 ( asynchronous ) 소통 이 라고 합니다 . 
 비 동기식 소통 의 특징 은 이렇 습니다 . 
 빨리 소통 할 필요 가 없 어요 . ( 상대방 의 시간 을 존중 해요 . ) 생각 할 시간 여유 가 있 습니다 . 
 주제 를 중심 으로 맥락 을 고려 하 여 차근히 대화 해요 . 
 다양 한 장소 와 시간 대 에 있 는 사람 과 소통 할 수 있 어요 . 
 예 : 게시판 , 이메일 , 할 일 관리 도구 등 
 반대 개념 인 동기식 소통 의 특징 은 다음 과 같 아요 . 
 실시간 대화 에 가까워요 . 
 대체 적 으로 비 형식 적 이 고 빠르 죠 . 
 같 은 시간 에 접속 되 어 있 다면 바로 바로 소통 할 수 있 어요 . 
 예 : 전화 , 회의 , 메신저 등 
 이 가이드 에서 는 같 은 시간 에 협업 하 기 어려운 커뮤니티 에서 쓸 수 있 는 비 동기식 협업 방법 을 제안 합니다 . 
 [ 사례 ] 빠 띠 팀 의 ' 돌탑 쌓 기 ' 
 빠 띠 팀 의 기본 적 인 커뮤니케이션 모델 은 돌탑 쌓 기 입니다 . 돌탑 은 누군가 먼저 얹 은 돌 위 에 사람 들 이 각자 그 길 을 지나 는 대로 돌 을 하나 씩 얹 으면서 만들 어 집니다 . 
 빠 띠 팀 은 각자 의 자리 에서 각자 의 시간 에 맞 게 커뮤니케이션 하 기 를 권장 합니다 . 모든 일 에 피드백 을 즉각 적 으로 하 지 않 아도 된다는 사실 에 공감 하 면서 실시간 커뮤니케이션 이 주 는 단점 들 을 극복 하 고자 합니다 . 
 각자 의 자리 에서 각자 의 시간 에 맞 게 메세지 를 확인 하 는 것 은 그 자체 로 효율 성 의 문화 입니다 . 진행 중 인 업무 의 흐름 을 끊 지 않 을 수 있 고 , 메세지 를 확인 하 고 응답 함 으로써 끊긴 업무 에 복귀 하 기 위해 다시 업무 를 리 마인드 하 는 시간 을 줄일 수 있 습니다 . 뿐 만 아니 라 의견 이 기록 되 는 것 들 을 지켜보 면서 토론 의 흐름 을 누구 나 더 쉽 게 이해 할 수 있 습니다 . 
 물론 급한 일 의 경우 반드시 바로 피드백 을 받 아야 할 수 있 습니다 . 빠 띠 팀원 들 은 커뮤니케이션 하 기 전 에 피드백 이 바로 필요 한 일 인지 고민 해 보 고 , 약속 한 방식 에 맞 게 행동 하 도록 노력 합니다 . 
 # 비 동기식 협업 의 원칙 
 위 와 같 은 특징 으로 인해 다음 과 같 은 커뮤니케이션 원칙 을 정하 고 소통 하 면 좀 더 협력 적 인 소통 을 할 수 있 습니다 . 
 # 명확 하 게 
 비 언어 적 소통 ( 표정 , 몸짓 ) 이 제한 되 기 때문 에 명확 한 커뮤니케이션 이 중요 해요 . 글 을 기반 으로 나 의 의사 를 명확 하 게 정리 하 여 소통 하 고 상호 예절 을 지킵니다 . 
 # 천천히 
 실시간 대화 를 하 는 것 이 아니 므로 숙의 를 기반 으로 소통 합니다 . 나 도 차근히 생각 하 며 기록 을 남기 고 상대방 도 함께 고민 할 수 있 도록 놓쳐 지 는 정보 없이 충분히 제공 합니다 . 
 # 투명 하 게 
 대화 는 가능 하 면 공개 적 으로 하 고 , 내용 은 기록 하 여 투명 하 게 관리 합니다 . 또 누구 나 쉽 게 접근 하 고 볼 수 있 도록 합니다 . 
 # 주기 적 으로 
 소통 할 주기 를 정하 지 않 으면 필요 이상 으로 소통 이 길 어 질 수 있 고 , 이슈 를 해소 할 적절 한 시기 를 놓칠 수 있 어요 . 가능 한 주기 를 가지 고 소통 합니다 . 공동 의 일감 이나 이슈 를 나누 는 요일 , 시간 을 정해 두 거나 필요 에 따라서 는 동시 에 논의 할 수 있 는 시간 을 정해 두 는 것 도 좋 은 방법 입니다 . 
 # 도움 이 되 는 방법 들 
 위 의 원칙 에 맞 게 협업 할 때 활용 할 수 있 는 방법 들 이 있 습니다 . 모든 것 을 완벽 하 게 갖추 기 보 다는 부족 한 부분 을 채울 수 있 는 방법 으로 활용 하 는 게 좋 아요 . 아래 체크 리스트 를 통해 회고 하 고 개선 할 방법 을 찾 을 때 참고 해 보 세요 . 
 # 체크 리스트 
 [ ] 프로젝트 가이드 만들 기 
 [ ] 체크 리스트 만들 고 관리 하 기 
 [ ] 진행 상황 업데이트 하 기 
 [ ] 이슈 발굴 하 고 토론 하 기 
 [ ] 일지 쓰 기 
 [ ] 주기 적 으로 회의 하 기 
 [ ] 공동 작업 세션 하 기 
 [ ] 커뮤니티 핸드북 만들 기 
 # 1 . 프로젝트 가이드 만들 기 
 # 명확 하 게 # 투명 하 게 
 프로젝트 의 목적 , 행동 강령 , 활동 , 참여 와 기여 방법 등 프로젝트 의 개요 를 정리 한 문서 입니다 . 프로젝트 가이드 를 문서 로 작성 해 커뮤니티 에 게시 해 두 면 구성원 모두 가 프로젝트 에 대해 좀 더 명확 하 게 이해 하 고 소통 할 수 있 습니다 . 프로젝트 문서 는 구성원 모두 가 동의 할 수 있 도록 충분히 논의 하 고 합의 한 상태 로 작성 하 는 것 이 중요 합니다 . 
 프로젝트 가이드 목차 ( 예시 ) 
 참여 , 기여 하 는 방법 
 # 2 . 체크 리스트 만들 고 관리 하 기 
 # 투명 하 게 # 주기 적 으로 
 혼자 보 는 체크 리스트 가 아니 라 , 커뮤니티 가 공동 으로 보 고 관리 하 는 체크 리스트 를 만듭니다 . 모든 커뮤니티 구성원 이 볼 수 있 도록 공개 하 며 프로젝트 가 완료 되 기 위해 필요 한 구체 적 인 일감 ( task ) 으로 구성 합니다 . 함께 만들 고 , 하나 씩 완료 해 보 세요 . 우리 가 지금 어디 까지 왔 는지 , 앞 으로 어떤 일 을 어떤 순서 로 해야 할지 볼 수 있 습니다 . 새로운 사람 이 참여 할 때 어떤 일 에 기여 할 수 있 는지 고를 수 있 구요 . 
 프로젝트 의 체크 리스트 게시물 을 만듭니다 . 
 현재 진행 중 인 일 에 는 📌 을 표시 하 고 , 완료 된 일 에 는 ✅ 를 표시 합니다 . 
 자신 이 참여 하 고 있 는 일 에 는 '@ 이름 ' 을 표시 해 누가 진행 하 고 있 는지 를 표시 합니다 . 
 정기 적 으로 회의 때 함께 보 고 체크 리스트 를 다듬 습니다 . 
 # 3 . 진행 상황 업데이트 하 기 
 결과물 을 100 % 완성 해서 공유 하 는 게 아닌 , 중간 과정 을 주기 적 으로 다른 사람 들 에게 공유 합니다 . 초안 을 공유 하 여 피드백 을 받 고 그 에 대한 일감 을 나눌 수 도 있 고 결과물 을 공동 으로 작성 할 수 도 있 습니다 . 
 프로젝트 가이드 에 댓글 로 진행 상황 을 업데이트 하 기 
 중간 결과물 을 게시물 로 공유 하 고 의견 주고받 기 
 # 4 . 이슈 발굴 하 고 토론 하 기 
 # 천천히 
 프로젝트 를 가로 막 는 문제 를 찾 는 것 은 매우 환영 할 만 한 일 입니다 . 질문 에 답 하 고 , 문제 를 해결 하 는 과정 에서 함께 배우 고 성장 할 수 있 습니다 . 비동기 작업 의 경우 질문 이나 문제 가 생겼 을 때 , 긴급 한 사항 이 아니 라면 바로 메세지 로 보내 지 않 고 협업 공간 에 게시물 로 남 깁니다 . 토론 이 필요 한 내용 이 라면 관련 내용 을 정리 하 여 토론 게시 글 로 올릴 수 있 고 , 공동 작업 중 생기 는 크 고 작 은 이슈 들 은 하나 의 위키 에 모아 함께 토론 하 며 해결 해 가 는 것 도 가능 합니다 . 
 이렇게 하 면 , 남겨진 기록 을 바탕 으로 천천히 생각 하 며 의견 을 주 고 받 을 수 있 고 , 비동기 작업 에서 생기 는 질문 에 대한 대처 방안 이 될 수 있 습니다 . 또한 그 자체 가 기록 으로 남 기 때문 에 자동 으로 흐름 이 정리 되 어 나중 에 비슷 한 문제 에 처한 사람 도 참고 할 수 있 답니다 . 
 방법 1 : 토론 게시물 만들 기 
 이슈 / 질문 채널 을 만듭니다 . 
 이슈 나 질문 이 생겼 을 때 충분 한 정보 를 포함 하 여 글 을 올립니다 . 
 댓글 로 답변 을 받 거나 , 토론 을 합니다 . 
 답변 을 달 아 준 구성원 에겐 감사 를 표현 합니다 . 
 이슈 가 해결 되 면 글 을 수정 하 여 ✅ 표시 를 합니다 . 
 반복 적 으로 발생 할 문제 로 예상 되 거나 구성원 에게 공유 할 만 한 내용 이 라면 커뮤니티 핸드북 에 정리 합니다 . 
 방법 2 : 위 키로 이슈 모으 기 
 한 가지 작업 에 대한 이슈 / 질문 위키 를 만듭니다 . 
 이슈 나 질문 이 생겼 을 때 해당 내용 을 정리 해 위키 에 기록 해 둡니다 . 
 정기 적 인 토론 시간 을 정 합니다 . 
 토론 시간 에 모여진 이슈 를 바탕 으로 토론 을 진행 합니다 . 
 토론 이후 , 정리 된 결과 를 위키 에 기록 하 고 항목 에 ✅ 표시 를 합니다 . 
 빠르 고 정확 하 게 답변 을 받 을 수 있 는 질문 하 는 법 
 # 5 . 일지 쓰 기 
 # 천천히 # 명확 하 게 
 일지 는 프로젝트 를 진행 하 며 있 던 일 과 느낀 점 , 배운 점 을 자유 롭 게 기록 하 는 글 입니다 . 일 을 하 면서 했 던 고민 과 결정 , 결과 를 남기 면 프로젝트 가 어떤 과정 으로 진행 됐 는지 나중 에 다시 볼 수 있 습니다 . 또 협업 하 는 구성원 들 의 경험 , 감정 , 배움 을 공유 하 여 서로 를 더 잘 이해 하 게 될 수 있 지요 . 
 좋 은 점 
 다양 한 목소리 로 커뮤니티 이야기 를 들 을 수 있 어요 . 
 커뮤니티 의 기록 을 자연 스럽 게 남길 수 있 어요 . 
 함께 관심 갖 고 고민 해 볼 이슈 를 발견 할 수 도 있 어요 . 
 일지 채널 을 만듭니다 . 
 기록 할 만 한 일 이 있 을 때 일지 를 씁니다 . ( 각자 자유 롭 게 ) 
 다른 사람 의 일지 를 보 며 개선 할 점 이나 아이디어 를 얻 습니다 . 공감 과 이야기 를 나누 기 도 합니다 . 
 프로젝트 결과 를 공개 할 때 일지 를 함께 공개 할 수 도 있 습니다 . 
 빠 띠 의 항해 일지 문화 - 항해 일지 , 조직 의 감정 을 기록 하 다 
 # 6 . 주기 적 으로 회의 하 기 
 # 주기 적 으로 
 비 동기식 협업 인데 무슨 회의 냐구요 ? 적절 한 시기 에 열리 는 주기 적 인 회의 는 헙업의 효율 성 을 높이 고 문제 를 제때 제때 에 해결 해줍니다 . 리듬감 을 가지 고 일감 을 나누 는 규칙 을 함께 만들 어 보 고 진행 하 며 우리 커뮤니티 에 맞 는 리듬감 을 찾 아 나 가 봅니다 . 
 매일 ~ 이틀 에 한 번 
 정기 점검 회의 
 주 1 - 2 회 ~ 격주 1 회 
 회고 미팅 
 주간 ~ 월간 
 월간 ~ 계절 마다 한번 
 # 7 . 공동 작업 세션 하 기 
 # 투명 하 게 
 공동 작업 세션 은 동시 에 하나 의 결과물 을 만드 는 시간 을 뜻 합니다 . 하나 의 모니터 를 놓 고 같이 글 을 쓰 거나 , 코딩 을 하 는 것 이 대표 적 인 공동 작업 이 에요 . 실시간 공동 편집 이 가능 한 문서도구 ( 구글 문서 등 ) 를 활용 하 면 쉽 게 진행 할 수 있 어요 . 
 좋 은 점 
 실시간 으로 피드백 을 주 고 받 고 의사 결정 이 일어납니다 . 
 각자 가진 기술 과 지식 을 서로 배울 수 기회 . 
 초보 자 가 기초 적 인 방법 을 익히 는 것 을 도와 줄 수 있 어요 . 
 프로젝트 에 대한 관점 을 맞출 수 있 어요 . 
 화 상회 의 공간 에 모 입니다 . ( 줌 , 행 아웃 , 카카오 통화 등 ) 
 하나 의 구글 문서 에 함께 들어갑니다 . 
 대화 를 나누 며 문서 를 함께 편집 합니다 . 
 한 사람 이 작성 을 하 면서 화면 공유 를 하 고 , 한 사람 은 의견 을 주 는 식 으로 도 할 수 있 습니다 . ( " 여기 를 다르 게 고쳐 보 면 어때요 ? ") 
 팁 / 사례 
 내 가 쓴 글 의 수정 을 허용 하 기 . 개인 창작물 이 아닌 , 공동 의 결과물 을 만드 는 것 이 니 타인 의 수정 과 기여 에 열린 마음 을 가져 보 세요 . 
 [ 참고 ] 페어 프로그래밍 동료 프로그래밍 또는 쌍 프로그래밍 은 애자일 소프트웨어 개발 중 하나 로 하나 의 컴퓨터 에서 두 사람 의 프로그래머 가 작업 하 는 방법 이 다 . 코드 를 작성 하 는 사람 이 진행자 ( dirver ) 가 되 고 다른 한 사람 이 관찰자 ( observer , navigator ) 가 되 어 코드 검토 ( code review ) 를 하 며 프로그래밍 을 작성 한다 . 두 프로그래머 는 수시로 역할 을 바꾼다 . 코드 검토 를 하 는 동안 에 관찰자 는 전략 적 방향 을 제시 하 거나 고려 하 여 개선 하 기 위한 아이디어 와 해결 가능 성 이 있 는 문제 를 제시 한다 . 진행자 는 작업 을 완료 하 는 전술 적 측면 에 모든 관심 을 집중 시키 고 관찰자 는 안전망 과 가이드 의 역할 을 담당 하 게 된다 . ( 출처 : 위키백과 - 페어 프로그래밍 ) 
 # 8 . 커뮤니티 핸드북 만들 기 
 마지막 입니다 ! 커뮤니티 가 소통 하 고 협업 하 는 방법 을 담 은 ' 핸드북 ' 을 만듭니다 . 핸드북 은 프로젝트 에 참여 할 때 필요 한 정보 를 모두 담 은 문서 입니다 . 구성원 들 이 함께 합의 한 방법 들 을 정리 해 나가 면 좋 습니다 . 
 가능 하 면 처음 에 핸드북 초안 을 씁니다 . ( 프로젝트 가이드 의 부분 으로 넣 는 것 도 가능 ) 
 커뮤니티 에 자리 잡 은 협업 방법 을 핸드북 에 추가 합니다 . 
 누구 나 편집 할 수 있 는 문서 로 만들 면 지속 적 으로 개선 해 나갈 수 있 습니다 . 
 새로운 핸드북 이 필요 할 때 파트 나 페이지 를 추가 할 수 있 게 만들 어 보 세요 . 
 코로나 19 코드 포 코리아 핸드북 
 커뮤니티 가이드 만들 기 툴킷 
 # 함께 읽 으면 좋 은 글 
 빠 띠 의 조직 항해술 이야기 
 툴킷 을 함께 만드 는 커뮤니티 시작 하 기 
 ← 커뮤니티 모임 가이드 협력 적 의사 결정 →