이해 없는 기여 없고 소통 없는 머지 없다

오픈소스 기여모임 10th 밋업 @ 서강대학교 (2026년 2월 28일)

오픈소스 첫 기여를 throttled-py로 진행한 과정 공유
오픈소스의 AI 기여동향에 대해 느낀점을 공유

Transcript

1. 이해 없는 기여 없고 소통 없는 머지 없다 2026.02 유성은
2. 자기소개 • 7년차 백엔드 개발자입니다 • 파이썬을 좋아합니다 • 최근 SRE에 관심이 많습니다
3. 3 1. 프로젝트 선택 2. 이슈 파악과 코드 이해 3. 설계와 소통 4. 세 번의 리뷰 5. 추가 기여방안 6. AI Slop이 되지 않기 위해 목차
4. 여기서 다루는 것과 그렇지 않은 것 다루는 것 • AI를 이용한 기여 프로세스 다루지 않는 것 • 실제 기여코드 • 내부 파이썬 로직 상세
5. I. 프로젝트 선택 기여할 오픈소스를 찾고 프로젝트를 선택하기까지
6. 6 I. 프로젝트 선택 기여할 프로젝트를 찾아봅시다 GeekNews에서 이런 글[1]을 읽었습니다 [1]:https://news.hada.io/topic?id=25458
7. 7 I. 프로젝트 선택 만약 기여한다면? 아래 가이드라인을 세웠습니다 1. 기왕 할거면 자신 있는 언어로 1. 이 코드는 오픈소스가 살아있는 한 영원히 남는다! 2. 변경에 강하고 읽기도 쉬운 코드를 고민하자 2. 커리어와 일치되면 더 좋겠다 1. 앞으로 하고싶은 일과 방향성이 맞으면 금상첨화 2. 기여와 공부를 병행하며 나의 것으로 만들고 써먹자
8. 8 I. 프로젝트 선택 이번 기여모임을 찾았습니다! 당시엔 신청 모집일자도 얼마 안 남았기에 일단 신청! https://litt.ly/opensource → 다음 11기는4~5월에 진행됩니다. 오픈챗에 들어오시면 모집 공고를 받아 보실 수 있습니다! 기회를 찾았으니 좋았쓰!
9. 9 I. 프로젝트 선택 기여 가이드를 공유 받았습니다! 이 링크[2]를 통해 가이드를 파악 기여의 접근장벽이 매우(!) 낮아짐 의지만 있다면 할 수 있습니다! • 이슈 파악하기 • 코드베이스 분석하기 • 해결방안 설계하기 • 구현하고 리뷰 받기 • 그리고 머지! [2]: https://medium.com/opensource-contributors/오픈소스의-판도를-바꿀-ai로-오픈소스-기여-완벽-가이드와-프롬프트-공유-2db85bf736b8
10. 10 I. 프로젝트 선택 뭘 고르면 좋을까? – General Use 이 중 하나 기여해볼까?
11. 11 I. 프로젝트 선택 뭘 고르면 좋을까? – General Use 너로 정했다!
12. II. 이슈 파악과 코드 이해 이슈를 분석하고, OTel로 설계하고, 코드를 이해하기
13. 13 II. 이슈 파악과 코드 이해 throttled-py 소개 파이썬 Rate limiter 구현체 동기/비동기 지원 주요 Rate limiter 알고리즘이 구현되어 있음 thread-safe 한 백엔드 사용 가능 벤치마크상 처리량 우수
14. 14 II. 이슈 파악과 코드 이해 AI를 이용한 이슈 분류 앞서 소개한 기여 가이드로 이슈를 분류 종합한 결과, 흥미에 맞는 이슈 #37[1]을 선택하기로 결정 [1]: https://github.com/ZhuoZhuoCrayon/throttled-py/issues/37
15. 15 II. 이슈 파악과 코드 이해 이슈를 직접 살펴봅시다 ‘모니터링, 알람을 위해 세밀한 rate limiting 메트릭을 노출합니다’.
16. 16 II. 이슈 파악과 코드 이해 관측가능성, OpenTelemetry, 메트릭 Observability Via OpenTelemetry(이하 OTel)? • 애플리케이션의 관측가능성(Observability)[2]을 확보하기 위한 CNCF 프로젝트 • OTel은 메트릭, 트레이스, 로그의 생성·전송·수집하는 표준을 정의 Exposing granular rate limiting metrics…. • 세밀한 rate limit 메트릭으로 알람이나 모니터링을 가능하게 하자 • 메트릭(Metrics) - 집계된 수치 지표 (예: 요청 수, 거부율, 응답 시간) [2]: 시스템의 내부 상태를 직접 열어보지 않고도, 외부로 출력되는 데이터(Logs, Metrics, Traces)만으로 파악할 수 있는 성질 — cf. "a measure of how well internal states of a system can be inferred from knowledge of its external outputs" (Wikipedia)
17. 17 II. 이슈 파악과 코드 이해 메트릭이 보여주는 것 이번 이슈(#37)는 메트릭을 설계하는 것이 핵심 rate limiter 로직이 구동되면서 ？ 어느 저장소에 저장된 ？ Key 값은 ？ 어떤 알고리즘으로 ？ 허용/거부 되었는지 …에 대한 메트릭을 설계하자
18. 18 II. 이슈 파악과 코드 이해 대시보드로 본 Rate Limiter 대시보드화 하면: ✓ 어느 저장소에 저장된 ✓ Key 값은 ✓ 어떤 알고리즘으로 ✓ 허용/거부 되었는지 한눈에 볼 수 있습니다
19. 19 II. 이슈 파악과 코드 이해 AI 활용 – 메트릭 설계하기 (via OTel) OTel 공식문서를 살펴보면서 • 나의 이해가 맞는지 질의응답하기 • 실제 사례를 검색해서 직접 보기 • 이번 이슈의 활용방안을 설계하기
20. 20 II. 이슈 파악과 코드 이해 코드를 처음 만나면? 환경구성부터 하자 • 보통은 CONTRIBUTING.md 파일을 보고 따라합니다 • mise[3] 같은 도구를 씁시다 (uv[4], 파이썬 런타임, 환경변수 등 종합관리 가능) 테스트코드를 살펴보자 • 환경구성을 마치고 전체 테스트를 구동 • 개별 테스트코드 하나를 작게 짜보고 실제 구동을 확인 [3]: https://mise.jdx.dev/ [4]: https://docs.astral.sh/uv/
21. 21 II. 이슈 파악과 코드 이해 코드에 대해 전체 테스트코드 구동부터 해보고
22. 22 II. 이슈 파악과 코드 이해 코드에 대해 (cont’d) 최소단위 구동으로 작동 원리를 이해합니다
23. 23 II. 이슈 파악과 코드 이해 코드가 너무 까마득해요 낯선 코드니, 어찌 보면 당연합니다 철저히 사전준비를 합시다 • 어려운 패턴이나 구현 아이디어 학습 • 실제 코드 흐름 분석
24. 24 II. 이슈 파악과 코드 이해 AI 활용 – 코드의 어려운 개념을 이해하기 테스트코드를 짜보고, 디버깅하고
25. 25 II. 이슈 파악과 코드 이해 AI 활용 – 실제 코드 분석하기 코드의 동작원리를 파악합니다
26. 26 II. 이슈 파악과 코드 이해 코드를 작성해봅시다 이해를 토대로 코드를 추가해봅시다 • AI 도구와 적극 리뷰, 지속적으로 검증 • 코드 작성 시 skill로 리뷰 자동화하기 다만 아래 부분은 철칙으로 • 테스트를 확보하고, 기여중인 프로젝트가 필요로 하는 과정을 준수 • 이해하기 전까지 절대 PR을 보내지 말자
27. III. 설계와 소통 초안 공유와 메인테이너 소통을 거쳐 PR 제출까지
28. 28 III. 설계와 소통 초안을 공유했어요 코드 작성 이후 Draft PR을 공유! 이해 완료하고 적합하다 판단한 코드로 구체적인 의견교환을 위해 리뷰를 요청합니다 작업 내용: • 훅 시스템을 두어 .limit() 호출 이후 수집 • Counter 메트릭으로 요청, 허용 및 거부를 수집
29. 29 III. 설계와 소통 기여에 환영인 모습 작업분을 이해하고 리뷰를 해주겠다고 하네요
30. 30 III. 설계와 소통 답장이 왔습니다! 드래프트 구현에 대해 아이디어를 받았습니다! • 훅(Hooks) 컨셉은 마음에 드는데, 이를 확장해봅시다 • 메트릭은 수정해봅시다 • 비동기 케이스는 우선 동기 케이스 구현 후 작업합시다
31. 31 III. 설계와 소통 설계 리뷰 – Hook 컨셉 훅(Hooks) 컨셉 살펴보기 • 미들웨어 패턴으로 리팩터링 • 호출 전·후를 데코레이터 처럼 래핑하기
32. 32 III. 설계와 소통 설계 리뷰 - 메트릭 메트릭 리뷰 • 불필요한 prefix 제거 • allowed/denied 를 하나의 dimension으로 → 메트릭 attribute 줄이기 • latency를 histogram 메트릭으로 살펴보기
33. 33 III. 설계와 소통 PR 올려봅시다! 리뷰를 받았으니, 그대로 고치고 PR 올립시다!
34. IV. 세 번의 리뷰 세 번의 리뷰 끝에 머지에 이르기까지의 과정을 공유합니다
35. 35 IV. 세 번의 리뷰 리뷰가 왔습니다 1차 리뷰 결과가 왔습니다! 으잉????? 리뷰사항이 8개? • 내가 못했나? (x) • 이정도로 신경 써서 리뷰해주는구나 (o)
36. 36 IV. 세 번의 리뷰 1차 리뷰 상세 코드 설계에 대한 리뷰 정리:
37. 37 IV. 세 번의 리뷰 1차 리뷰로부터 배운 점 훅 시스템 리뷰 • 의존성 역전으로 OTel API를 주입 받도록 수정 • 실수로 throttled.latency 를 그대로 둔 것도 수정
38. 38 IV. 세 번의 리뷰 1차 리뷰로부터 배운 점 테스트 Mocking 진행하기 • OTel API의 결과값을 모킹, OTelHook의 책임인 “올바른 호출”만 격리 검 증
39. 39 IV. 세 번의 리뷰 2차 리뷰 상세 테스트 컨벤션과 미사용 변수 정도만 제거 • 그런데 ruff 경고는 왜 저렇게 해야 되는 거지? • 테스트 옵션 보면 하위 디렉터리는 테스트 못하던데, 그건 뭐라고 말 해야 하지..? 내 실수인가? 물어보기 부끄러운데…? 이런 것도 모를 거라고 하면…?
40. 40 IV. 세 번의 리뷰 궁금한 건 명확히 물어보세요! 이 옵션이면 하위 디렉터리도 CI 에서 테스트 못 할 텐데? • 이상하다 싶은 건 물어보면 됩니다!
41. 41 IV. 세 번의 리뷰 궁금한 건 명확히 물어보세요! 이 접근에 뭔가 이점이 있나요? • ruff check 통과. 테스트를 위한 간이 클래스는 무시하기 위함 • 프로젝트의 기존 linter 규칙 준수를 위해 noqa 옵션으로 예외 명시
42. 42 IV. 세 번의 리뷰 3차 리뷰 상세 Docs만 수정해주시고, 나머지는 무시하세요 • AI 리뷰로 이런 허점을 잡을 수 있다는 것을 배웠습니다 • 오오 다왔다!
43. 43 IV. 세 번의 리뷰 그리고 머지!
44. 44 IV. 세 번의 리뷰 하지만?
45. V. 추가 기여방안 저의 추가기여 계획을 공유합니다. 기여는 멈추지 않습니다!
46. 46 V. 추가 기여방안 이번 기여로 끝인가요? 1.CONTRIBUTING.md 가이드라인을 작성하자 – linter 구성, 커밋 규칙도 CI를 깨먹고 GitHub Actions YAML을 읽고 파악함 – 문서 기여방안도 가이드 없이 기존 문서를 둘러보며 유사하게 작성함 – 프로젝트의 테스트코드 규약과 기여방안을 몰라서 일을 두 번 함 → 나중의 나 뿐 아니라 남을 위해 문서화하고 기여하자! 2. 비동기 구현도 별도로 진행하자
47. 47 V. 추가 기여방안 CONTRIBUTING.md 작성하기 문서작성 및 컨텐츠를 담아 PR 완료!
48. 48 V. 추가 기여방안 못다한 비동기 기여 진행하기 초안 소통 후 기여하기로 결정!
49. 49 V. 추가 기여방안 오픈소스 생태계에 기부 테스트 도구에 기부를 결심합니다
50. VI. AI Slop이 되지 않기 위해 AI는 기회지만 오용으로 오픈소스 생태계를 위협합니다. 제 경험과 의견을 나누어 봅니다
51. 51 VI. AI Slop이 되지 않기 위해 AI는 정말 좋습니다. 하지만…. 이번 기여는 AI를 통해 만들어졌습니다 • 하지만 설계와 구현 전체에 제 손길이 닿지 않은 것이 없습니다 그렇지만 AI는 믿음직하지 못합니다 • 결과물은 비결정론적(non-deterministic)입니다 • 아첨을 하기도 하고, 실수를 하고 정정하기도 합니다
52. 52 VI. AI Slop이 되지 않기 위해 AI Slop이 난무하는 현실 AI의 작업물을 100% 신뢰하지 마세요 • AI로 인한 생성물을 온전히 신뢰할 수 있을까요? • 하물며 이 생성물을 검증조차 하지 않고 쓸 수 있을까요? 무책임한 AI 작업물은 건강한 기여 프로세스 자체를 근간부터 위협합니다 • AI 에이전트(OpenClaw 에이전트로 추정)로부터 억지 비판을 당하기도 합니다[1] • cURL 버그 바운티는 AI Slop으로 인해 버그 바운티 정책을 폐지했습니다[2] • GitHub은 Pull Request 비활성화, 일부허용 기능을 발표했습니다[3] [1]: https://github.com/matplotlib/matplotlib/pull/31132 [2]: https://etn.se/index.php/nyheter/72808-curl-removes-bug-bounties.html [3]: https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/
53. 53 VI. AI Slop이 되지 않기 위해 오픈소스의 대응 - 강경책 AI로 생성한 결과물을 원천적으로 받지 않거나, 매우 제한적인 경우 – Gentoo Linux[4], NetBSD[5], QEMU[6]의 케이스 – 워딩부터 아주 세게 가져가기도 합니다(tainted codes) [4]: https://wiki.gentoo.org/wiki/Project:Council/AI_policy [5]: https://www.netbsd.org/developers/commit-guidelines.html [6]: https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst#use-of-ai-content-generators
54. 54 VI. AI Slop이 되지 않기 위해 오픈소스의 대응 - 온건책 사람이 코드를 충분히 인지하고, AI 사용을 밝히면 허용하는 경우 – Git[7] , Ghostty[8], FastAPI[9]의 케이스 – 도구를 사용하는 사람의 코드 가치를 인정하는 경우(Human-in-the-loop) [7]: https://git-scm.com/docs/SubmittingPatches#ai [8]: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md [9]: https://fastapi.tiangolo.com/contributing/#automated-code-and-ai
55. 55 VI. AI Slop이 되지 않기 위해 오픈소스의 대응 – 온건책 (cont’d) 구체적인 AI 사용방안을 공식화 한 경우 – Zulip[10] 의 케이스 – “왜 이게 개선인가요?”의 질문에 “AI가 그러던데요” 는 답이 될 수 없습니다 [10]: https://zulip.readthedocs.io/en/latest/contributing/contributing.html#ai-use-policy-and-guidelines
56. 56 VI. AI Slop이 되지 않기 위해 이러면 어떨까요? 1. 이해하고 작성한 코드를 PR로 보냅시다 – 너무 당연합니다! 사람을 위한 코드를 작성합시다 – 당신의 기여는 코드가 작동되는 한 영원히 기록됩니다 2. 적극적인 의사소통을 해봅시다 – 코멘트에 이모지만 표시해줘도 충분히 좋습니다 – 영어의 톤 조절이 어렵다면, AI에 맡기고 본질에 집중합시다 "Fix this." / "Change it to X.“ "Would it make sense to change this to X?"
57. 이해하고 소통하면, 머지는 따라옵니다
58. Q&A
59. 감사합니다