CHAPTER 16

커뮤니티에 기여하기

PR 보내기, 피드백 받기, 그리고 여러분의 오픈소스 이야기가 시작됩니다

일러스트 16-1: 졸업식과 첫 PR 성공

기억하시나요, 챕터 3?

이 책의 맨 앞에서, 우리는 리누스 토르발스라는 핀란드 대학생 이야기를 했어요.

"취미로 운영체제를 만들고 있는데, 관심 있으면 피드백 주세요."

그 한마디가 리눅스를 만들었고, 오픈소스 문화를 탄생시켰다고요.

그때 저는 이렇게 말했어요:

"이 책을 다 읽고 나면, 여러분도 '별거 아닌데, 유용하면 가져다 쓰세요'라고 말하게 될 거예요."

자, 그 순간이 왔습니다.

여러분은 지금까지 생성형 AI가 뭔지 배웠고, 스킬 패키지를 이해했고, 직접 만들었고, 테스트했고, 모노레포로 정리했고, GitHub에 공유하는 방법도 배웠어요.

이제 마지막 퍼즐 한 조각이 남았어요. 커뮤니티의 일원이 되는 것.

단순히 "내 스킬을 올리고 끝"이 아니라, 다른 사람의 스킬을 개선하고, 피드백을 주고받고, 함께 더 좋은 도구를 만들어가는 것. 이것이 오픈소스의 진짜 매력이에요.

기여의 순환: Use → Find → Fix → Share

오픈소스 기여는 거창한 게 아니에요. 일상적인 과정이에요.

기여의 4단계

1. Use (사용하기)
다른 사람의 스킬을 써본다. "오, 이거 유용한데?"

2. Find (발견하기)
쓰다 보니 뭔가 발견한다. "이 부분 설명이 좀 부족하네" 또는 "이런 기능도 있으면 좋겠다"

3. Fix (고치기)
직접 수정하거나 개선한다. description을 더 명확하게, 예시를 추가하거나, 오타를 고치거나.

4. Share (공유하기)
수정한 걸 원래 만든 사람에게 보낸다. 이게 Pull Request(PR)!

이 4단계가 계속 반복돼요. 여러분이 다른 사람의 스킬에 기여하면, 또 다른 누군가가 여러분의 스킬에 기여하고. 이렇게 모두의 스킬이 점점 좋아지는 거예요.

"근데 저는 초보인데, 뭘 기여할 수 있을까요?"

의외로 초보의 기여가 가장 가치 있는 경우가 많아요. 왜냐하면 초보의 눈으로 봐야 보이는 것들이 있거든요.

  • "이 설명, 전문가는 이해하겠지만 저는 모르겠어요" → 설명 개선 제안
  • "설치 과정에서 이 부분이 빠져있었어요" → 문서 보충
  • "이 오타 발견했어요" → 오류 수정
  • "이런 사용 사례도 추가하면 좋겠어요" → 예시 추가

이런 기여 하나하나가 엄청나게 소중해요. 만든 사람은 이미 내용을 다 알기 때문에 "초보가 어디서 막히는지" 모르거든요.

Pull Request 보내기 — 생각보다 쉬워요

Pull Request(줄여서 PR)은 이름이 좀 무서운데, 실제로는 아주 자연스러운 과정이에요.

PR을 일상으로 비유하면

친구가 만든 레시피를 써봤는데, "여기에 참기름 한 방울 넣으면 더 맛있을 것 같아"라는 생각이 들었어요.

그래서 친구에게 이렇게 말하는 거예요:
"나 이 레시피 살짝 바꿔봤는데, 한번 맛봐봐. 괜찮으면 네 레시피에 반영해!"

이게 Pull Request예요. "내가 이렇게 바꿔봤는데, 당겨가(Pull) 보실래요?"

PR 보내는 단계 (GitHub 기준)

1단계: Fork (포크) — 내 사본 만들기

다른 사람의 저장소를 바로 수정할 수는 없어요. 그래서 먼저 "내 사본"을 만들어요. GitHub에서 "Fork" 버튼을 누르면 돼요.

# GitHub 웹에서 Fork 버튼 클릭 후
# 내 사본을 로컬에 다운로드
git clone https://github.com/내아이디/원래저장소이름.git
cd 원래저장소이름

2단계: 수정하기

파일을 수정해요. SKILL.md의 설명을 더 명확하게 하든, 오타를 고치든, 새 기능을 추가하든.

# 새 브랜치 만들기 (좋은 습관!)
git checkout -b fix/improve-description

# 파일 수정 후
git add .
git commit -m "description을 더 구체적으로 수정"

3단계: Push & PR 만들기

# 내 Fork에 올리기
git push origin fix/improve-description

그 다음 GitHub 웹에서 "Compare & pull request" 버튼이 뜨면 클릭하고, PR 제목과 설명을 쓰면 끝이에요.

좋은 PR 설명 쓰기

PR을 보낼 때 설명을 잘 쓰면, 받는 사람이 이해하기 쉬워요.

## 변경 내용
- description을 "코드 리뷰 스킬"에서 "보안, 성능, 스타일을
  종합적으로 검토하는 코드 리뷰 스킬"로 수정했습니다.

## 이유
- 기존 description이 너무 일반적이어서, Claude가 다른
  리뷰 스킬과 구분하지 못하는 경우가 있었습니다.

## 테스트
- 수정 후 "코드 리뷰해줘"라고 말했을 때, 이 스킬이
  정확하게 활성화되는 것을 확인했습니다.

핵심은 "뭘 바꿨고, 왜 바꿨고, 확인은 어떻게 했는지"를 적는 거예요.

일러스트 16-2: PR 프로세스 단계별 안내

좋은 피드백과 이슈 작성법

직접 코드를 수정하지 않더라도 기여할 수 있는 방법이 있어요. Issue(이슈)를 작성하는 거예요.

이슈는 "이 스킬에 대한 의견이나 문제를 알려주는 글"이에요. GitHub 저장소의 "Issues" 탭에서 작성할 수 있어요.

좋은 이슈의 특징

나쁜 이슈: "이거 안 돼요" (뭐가 안 되는데...?)

좋은 이슈:

제목: description 매칭이 부정확한 경우가 있습니다

환경: macOS, Claude Code v1.2.3

재현 방법:
1. "간단한 리뷰 해줘"라고 입력
2. 다른 스킬이 활성화됨

기대 결과: 이 스킬이 활성화되어야 함
실제 결과: 다른 스킬이 활성화됨

제안: description에 "보안, 성능" 키워드를 추가하면 좋을 것 같습니다

차이가 보이시죠? 좋은 이슈는 재현 가능하고, 구체적이고, 해결 방향까지 제안해요.

이슈 작성도 훌륭한 기여예요

"코드를 수정하는 것만 기여"라고 생각하기 쉬운데, 실은 문제를 발견하고 알려주는 것도 엄청 큰 기여예요. 만든 사람이 모르고 있던 문제를 알려주는 거니까요. 이슈 하나가 스킬의 품질을 크게 높일 수 있어요.

피드백 받기: 개인적으로 받아들이지 마세요

이건 정말 중요한 이야기예요.

여러분이 정성들여 만든 스킬에 누군가 이런 피드백을 준다고 해봐요:

"이 description이 너무 모호해서 다른 스킬과 구분이 안 돼요. 더 구체적으로 바꾸면 좋겠어요."

처음에는 이렇게 느낄 수 있어요. "내가 열심히 만든 건데... 부족하다고?" 약간 상처받을 수 있어요.

근데 여기서 관점을 바꿔보면:

피드백의 진짜 의미

누군가가 여러분의 스킬에 피드백을 준다는 건...

1. 여러분의 스킬을 실제로 써봤다는 뜻이에요
2. 더 좋아지길 바란다는 뜻이에요
3. 시간을 들여 생각하고 글을 썼다는 뜻이에요

무관심이 아니라, 관심이에요.
비판이 아니라, 응원이에요.

피드백을 받았을 때 좋은 반응:

  • "감사합니다! 좋은 지적이에요. 수정해볼게요." — 가장 좋은 반응
  • "그 부분은 의도적인 건데, 이유가 있어요: ..." — 설명하는 것도 좋아요
  • "아직 그 부분까지 생각 못했네요. 시간 날 때 개선해볼게요." — 솔직한 것도 좋아요

좋지 않은 반응:

  • "그냥 쓰면 안 돼요?" — 방어적이에요
  • 무시하기 — 기여한 사람이 실망해요
  • 화내기 — 커뮤니티가 멀어져요

기억하세요: 피드백은 여러분이 아니라 여러분의 "작업"에 대한 거예요. 여러분의 인격이 부정당하는 게 아니에요.

첫 기여의 감정 여행

첫 PR을 보내는 건 감정의 롤러코스터예요. 미리 알려드릴게요.

단계 1: 두근두근
"와, 진짜 PR을 보내는 거야? 내가? 이 프로젝트에?"

단계 2: 불안
"혹시 내가 뭘 잘못한 건 아닐까? 민폐 아닐까?"

단계 3: 기다림
"왜 아직 답이 없지... 무시당하는 건가..." (보통 사람들은 바쁘기 때문에 답이 좀 늦을 수 있어요. 정상이에요!)

단계 4: 피드백
"수정 요청이 왔다! 내가 틀린 건가..." (아니에요. 더 좋게 만들자는 거예요.)

단계 5: 머지(Merge)!
"Merged! 내 코드가 반영됐다!" — 이 순간의 기쁨은 말로 표현하기 어려워요.

GitHub 프로필에 초록색 사각형이 하나 생기는 그 순간. "나도 오픈소스에 기여했다"는 작은 증거. 별거 아닌 것 같지만, 처음 경험하면 정말 뿌듯해요.

그리고 그 한 번이 시작이에요. 한 번 해보면, 두 번째는 훨씬 쉬워요. 세 번째부터는 자연스러워요. 어느새 여러분은 "오픈소스 기여자"가 되어 있을 거예요.

일러스트 16-3: 첫 기여의 감정 여정 지도

한국 개발자 커뮤니티에 참여하기

기여할 곳을 찾고 있다면, 한국 개발자 커뮤니티부터 시작하는 게 좋아요.

  • GitHub Discussions — 스킬 관련 프로젝트의 Discussion 탭에서 질문하고 답하기
  • 한국 AI 커뮤니티 — AI 관련 카카오 오픈채팅, 디스코드 서버
  • 개발자 모임 — 오프라인/온라인 밋업에서 스킬 제작 경험 공유하기
  • 블로그 글 쓰기 — "내가 만든 스킬 이야기"를 블로그에 써보세요. 이것도 훌륭한 기여!

커뮤니티 참여의 가장 좋은 시작은 "질문하기"예요. "이런 스킬 만들고 싶은데, 어떻게 하면 좋을까요?" 같은 질문을 올리면, 생각보다 많은 사람이 친절하게 답해줘요.

기여의 형태는 다양합니다

코드를 수정하는 것만 기여가 아니에요.

- 스킬 사용 후기 써주기
- 오타나 오류 알려주기
- 번역 도와주기
- 블로그에 소개 글 쓰기
- 질문에 답해주기
- 밋업에서 발표하기

이 모든 것이 커뮤니티에 기여하는 거예요.

여러분의 이야기는 이제 시작입니다

이 책의 마지막 챕터까지 오신 여러분에게 진심으로 축하를 드려요.

돌아보면, 여러분이 걸어온 길이 보여요.

1부에서는 생성형 AI가 뭔지, 스킬이 뭔지, 오픈소스가 뭔지 배웠어요. "왜?"에 대한 답을 찾았죠.

2부에서는 스킬의 구조를 뜯어보고, 프론트매터, allowed-tools, references를 이해했어요. "뭘?"에 대한 답을 찾았죠.

3부에서는 직접 스킬을 만들고, 다듬고, 테스트했어요. "어떻게?"를 직접 해봤죠.

4부에서는 모노레포로 정리하고, 공유하고, 커뮤니티에 기여하는 법을 배웠어요. "그다음?"에 대한 답을 찾았죠.

챕터 1에서 여러분은 "AI가 뭔지도 잘 모르는 사람"이었어요.

지금 여러분은:

  • 생성형 AI를 이해하고
  • 프롬프팅을 할 줄 알고
  • 스킬 패키지를 직접 만들 줄 알고
  • 다른 사람과 공유할 줄 알고
  • 오픈소스에 기여할 줄 아는 사람

이 변화가 얼마나 대단한지, 한번 느껴보세요.

여러분은 이 책을 시작할 때 GenAI에 대해 아무것도 몰랐어요.

지금 여러분은 스킬 제작자이자 오픈소스 기여자예요.

리누스가 "별거 아닌 취미 프로젝트"로 시작해서 세상을 바꿨듯,
여러분의 작은 스킬 하나가 누군가의 하루를 바꿀 수 있어요.

수백 명의 월요일 아침을 편하게 만들 수 있어요.

이제 가서 뭔가 멋진 걸 만들어보세요.

그리고 만들었으면, 공유해주세요. 여러분의 이야기를 듣고 싶어요.

감사합니다. 여기까지 함께해주셔서.

아직 끝이 아니에요!

본문은 여기까지지만, 부록이 남아있어요!
용어 사전, 일러스트 프롬프트 모음, 체크리스트, 참고 자료 링크까지.
스킬 만들기를 계속할 때 필요할 때마다 펼쳐보세요.