Skip to content
Published on

OSS 메인테이너와 AI 기여의 충돌 — jqwik 사건이 던진 질문

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — jqwik 사건이 화제가 된 이유

2026년 6월 9일, JVM 진영의 속성 기반 테스트(property-based testing) 라이브러리 jqwik의 메인테이너 Johannes Link가 자신의 블로그에 "the jqwik anti-AI affair"라는 글을 올렸습니다. 그가 프로젝트에 도입한 반-AI 조치 — AI가 생성한 기여를 제한하는 정책 — 를 둘러싼 논란을 직접 정리한 글이었고, 이 글은 곧바로 Hacker News와 GeekNews 상위권에 올랐습니다.

논쟁 구도는 익숙합니다. 한쪽에서는 "기여의 품질로 판단해야지 생성 수단으로 차별하면 안 된다"고 말하고, 다른 쪽에서는 "무급 자원봉사자인 메인테이너에게 AI가 만들어낸 저품질 PR의 홍수를 감당하라고 요구할 권리는 누구에게도 없다"고 말합니다. 2026년 현재, AI 코딩 에이전트가 보편화되면서 이 갈등은 더 이상 변두리 이슈가 아니라 오픈소스 생태계 전체의 지속가능성 문제가 됐습니다.

이 글에서는 jqwik 사건을 입구로 삼아, AI 기여가 메인테이너에게 지우는 부담의 구조, 다른 프로젝트들의 정책 사례, 그리고 메인테이너와 기여자 양쪽이 당장 쓸 수 있는 실용적 가이드(정책 템플릿, 에티켓 체크리스트)까지 정리합니다.

배경 — jqwik과 속성 기반 테스트

맥락을 위해 jqwik이 어떤 프로젝트인지부터 짚겠습니다. jqwik은 JUnit 플랫폼 위에서 동작하는 속성 기반 테스트 엔진입니다. 속성 기반 테스트는 "예제 몇 개를 검증"하는 전통적 단위 테스트와 달리, "모든 입력에 대해 성립해야 하는 속성"을 선언하면 프레임워크가 수백 개의 무작위 입력을 생성해 검증하고, 실패 시 최소 반례로 축소(shrinking)해 주는 기법입니다.

import net.jqwik.api.*;

class StringProperties {

    // 속성: 어떤 문자열이든 두 번 뒤집으면 원본과 같다
    @Property
    boolean reversingTwiceReturnsOriginal(@ForAll String s) {
        return new StringBuilder(s).reverse().reverse()
                .toString().equals(s);
    }

    // 속성: 리스트를 정렬하면 길이가 보존되고 순서가 단조증가
    @Property
    void sortingPreservesLength(@ForAll java.util.List<Integer> list) {
        var sorted = list.stream().sorted().toList();
        assert sorted.size() == list.size();
    }
}

Python 진영의 Hypothesis도 같은 계보입니다.

from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_sorted_is_idempotent(xs):
    # 속성: 정렬은 멱등 — 두 번 정렬해도 결과가 같다
    assert sorted(sorted(xs)) == sorted(xs)

@given(st.text())
def test_encode_decode_roundtrip(s):
    # 속성: 인코딩-디코딩 왕복은 원본을 보존한다
    assert s.encode("utf-8").decode("utf-8") == s

속성 기반 테스트의 백미는 축소(shrinking)입니다. 무작위 입력으로 실패를 찾으면, 프레임워크가 실패를 재현하는 최소한의 반례까지 자동으로 줄여 줍니다.

jqwik 실행 예 (속성 위반 발견 시)

  StringProperties:reversingTwiceReturnsOriginal =
    org.opentest4j.AssertionFailedError

  tries = 38            | 38번째 시도에서 실패 발견
  checks = 38
  seed = -47218904...   | 같은 시드로 재현 가능
  sample = ["\uD83D x"] | 원래 실패한 복잡한 입력
  shrunk sample = ["\uD83D"]  | 축소된 최소 반례
                        | → 서로게이트 문자 처리 버그임을 즉시 파악

수백 글자의 무작위 문자열에서 시작해 "깨진 서로게이트 문자 하나"라는 최소 반례까지 자동으로 줄여 주는 것, 이것이 속성 기반 테스트가 주는 디버깅 경험입니다.

흥미로운 역설이 하나 있습니다. 속성 기반 테스트는 "무작위로 생성된 입력의 홍수로 코드의 허점을 찾는" 기법입니다. 그 도구의 메인테이너가 이번에는 "무작위로 생성된 기여의 홍수"에 맞서게 된 것입니다. 다만 결정적 차이가 있습니다. 테스트 프레임워크의 무작위 입력은 검증 비용이 자동화되어 있지만, AI 생성 PR의 검증 비용은 전부 사람의 몫입니다.

핵심 문제 — 리뷰 비용의 비대칭

AI 기여 논쟁의 본질은 생성 비용과 검증 비용의 비대칭입니다. 구조를 그림으로 보면 명확합니다.

        AI 이전 시대                      AI 이후 시대
  기여자: PR 작성에 수 시간          기여자: 프롬프트 1분 + 생성 1분
  메인테이너: 리뷰에 30분~수 시간     메인테이너: 리뷰에 여전히 30분~수 시간
                                    (오히려 증가: 그럴듯해 보이는
                                     오류를 찾아내야 하므로)

  비용 비율  대략 1 : 1              비용 비율  대략 1 : 50 이상

  결과: 기여의 양과 검증 능력의 균형 붕괴
        → 메인테이너의 시간이 시스템의 병목이자 공격 표면이 됨

구체적으로 메인테이너가 겪는 부담은 세 갈래입니다.

  1. 저품질 PR의 절대량 증가: 코딩 에이전트 덕에 PR을 만드는 한계 비용이 0에 수렴하면서, 이력서 채우기용 드라이브바이 기여, 해커톤/교육 과정의 숙제형 PR이 폭증했습니다
  2. 그럴듯함의 함정: AI 생성 코드는 표면적으로 일관되고 설명도 유창합니다. 사람이 쓴 어설픈 PR은 한눈에 거를 수 있지만, AI의 산출물은 정독해야 결함이 보입니다. 리뷰 단가가 오히려 올라갑니다
  3. 커뮤니케이션 비용: 지적 사항에 대해 기여자가 다시 AI에게 물어 답변을 복붙하는 "대리 대화"가 벌어지면, 리뷰는 사람과 모델 사이의 비효율적 전화 게임이 됩니다

이 현상을 커뮤니티는 "slop"(질 낮은 AI 생성물)이라는 단어로 부르기 시작했습니다. curl의 Daniel Stenberg가 보안 신고 채널에 쏟아지는 AI 생성 가짜 취약점 보고서를 두고 공론화한 단어이기도 합니다.

갈등의 연대기 — 여기까지 어떻게 왔나

이 갈등은 하루아침에 생기지 않았습니다. 주요 사건을 시간순으로 늘어놓으면 누적의 구조가 보입니다.

2021~2022  GitHub Copilot 등장과 라이선스 논쟁 시작
           — 학습 데이터 저작권 소송 제기

2023       Stack Overflow, AI 생성 답변 금지 정책
           — 검증 비용 비대칭 문제의 첫 대규모 공론화

2024       Gentoo/NetBSD 등 AI 기여 금지 정책 채택
           curl, AI 생성 가짜 보안 보고서 공개 비판
           xz 백도어 — 메인테이너 번아웃의 보안 위험 입증

2025       코딩 에이전트 보편화 — PR 생성 한계 비용 급락
           해커톤/교육발 드라이브바이 PR 폭증
           다수 프로젝트가 PR 템플릿에 AI 고지란 도입

2026-06    jqwik 반-AI 조치 논란 — HN/GeekNews 상위
           npm 공급망 공격이 Red Hat Cloud Services 침투
           — 공급망 신뢰와 리뷰 부담 문제가 동시에 부각

연대기가 보여주는 것은 명확합니다. 생성 비용은 해마다 떨어졌고, 검증 비용은 그대로였으며, 그 간극이 임계점을 넘은 곳마다 정책이라는 방파제가 세워졌습니다. jqwik은 그 최신 사례일 뿐입니다.

다른 프로젝트들의 정책 사례

jqwik 사건은 고립된 해프닝이 아닙니다. 주요 프로젝트들은 이미 다양한 정책을 실험해 왔습니다.

  • curl: HackerOne 보안 신고에서 AI 생성 의심 보고가 급증하자, AI 사용 고지를 의무화하고 검증 없는 AI 보고는 즉시 종료(밴 포함) 방침을 공개했습니다. Stenberg는 "쓰레기 보고서 하나가 엔지니어 여러 명의 시간을 태운다"고 썼습니다
  • Gentoo: 2024년 일찍이 AI 생성 기여를 공식적으로 금지하는 결의를 채택했습니다. 근거는 저작권 불확실성, 품질, 윤리 문제였습니다
  • NetBSD: 커밋 가이드라인에 AI 생성 코드를 기본적으로 수용 불가로 명시했습니다
  • QEMU: 라이선스/출처 불확실성을 이유로 AI 생성 코드 기여를 거부하는 정책을 문서화했습니다
  • Fedora: 전면 금지 대신 "기여자가 내용을 이해하고 책임질 것, AI 사용을 투명하게 밝힐 것"을 요구하는 중간 노선의 정책을 다듬어 왔습니다
  • Servo: 커뮤니티 논의 끝에 AI 생성 기여를 받지 않는 방침을 명시한 대표 사례 중 하나입니다

스펙트럼이 분명히 보입니다. 전면 금지(Gentoo, NetBSD, QEMU 계열)부터 고지 의무화(curl, Fedora 계열)까지, 각 프로젝트가 자신의 리뷰 역량과 위험 프로파일에 맞는 지점을 고르고 있습니다.

라이선스와 저작권 — 아직 안개 속

정책의 강경함을 좌우하는 또 하나의 축은 법적 불확실성입니다.

  • 저작권 귀속: 주요 법역에서 AI가 단독 생성한 산출물의 저작권 보호 여부는 여전히 회색지대입니다. 미국 저작권청은 인간의 창작적 기여가 없는 산출물의 등록을 거부해 왔습니다
  • 학습 데이터 오염 우려: 모델이 학습한 코드의 라이선스(GPL 등 카피레프트 포함)가 산출물에 어떤 의무를 전파하는지에 대한 확립된 판례가 부족합니다
  • DCO/CLA와의 충돌: 많은 프로젝트가 요구하는 Developer Certificate of Origin은 "이 기여를 제출할 권리가 나에게 있음"을 서약하는 절차인데, AI 생성 코드는 기여자가 그 서약을 자신 있게 할 수 있는지 자체가 불명확합니다

법적 리스크를 보수적으로 평가하는 프로젝트(특히 GPL 계열, 기업 재배포가 많은 인프라 소프트웨어)일수록 전면 금지로 기우는 경향이 설명됩니다.

AI 기여 정책 스펙트럼 — 선택지 정리

메인테이너가 고를 수 있는 정책 옵션을 비교하면 다음과 같습니다.

정책 수준내용장점단점대표 사례
전면 금지AI 생성 기여 일체 거부명확함, 법적 위험 최소화집행 어려움, 선의의 보조 사용까지 차단Gentoo, NetBSD
고지 의무AI 사용 시 PR에 명시 요구투명성, 리뷰 우선순위 조정 가능자진 신고 의존, 허위 고지 검증 불가curl, Fedora
품질 게이트수단 불문, 테스트/설명/재현 요건 강화본질(품질)에 집중, 중립적게이트 설계와 유지 비용다수 프로젝트의 실질 운영 방식
제한적 허용문서/번역 등 저위험 영역만 허용위험-편익 균형경계 모호, 영역 구분 논쟁일부 문서 중심 프로젝트
무정책기존 리뷰 프로세스로 흡수마찰 없음slop 홍수에 무방비소규모/저노출 프로젝트

핵심 통찰은 이것입니다. 어떤 정책도 완벽히 집행할 수 없습니다. AI 생성 코드를 확실히 판별하는 기술은 없기 때문입니다. 따라서 정책의 실질적 기능은 판별이 아니라 기대치 설정과 거절 근거 마련입니다. "이 PR은 우리 정책 위반"이라고 말할 수 있는 문서적 근거가 있으면, 메인테이너는 죄책감과 논쟁 없이 닫을 수 있습니다. 정책은 메인테이너의 정신 건강을 위한 방어 장치입니다.

프로젝트용 AI 정책 템플릿

자신의 프로젝트에 바로 붙여 쓸 수 있는 CONTRIBUTING.md 섹션 예시입니다. 고지 의무 + 품질 게이트의 중간 노선으로 작성했습니다.

## AI-Assisted Contributions Policy

We welcome contributions, including those created with AI assistance,
under the following conditions:

### Disclosure
- If AI tools (code assistants, agents, LLMs) were used to generate
  a substantial part of this contribution, state it in the PR
  description: which tool, and for which parts.

### Accountability
- You must fully understand every line you submit. If you cannot
  explain a change during review in your own words, the PR will
  be closed.
- Do not paste AI-generated responses verbatim into review
  discussions.

### Quality gate (applies to ALL contributions)
- The PR must address a real, reproducible issue or an agreed
  feature. Open an issue first for anything non-trivial.
- Include tests that fail without your change and pass with it.
- Keep PRs small and focused: one logical change per PR.
- The full test suite must pass locally before submission.

### Security reports
- AI-generated vulnerability reports without a working proof of
  concept will be closed immediately. Repeated violations lead
  to a ban.

### Why this policy exists
Maintainer review time is the scarcest resource in this project.
These rules exist to keep the project sustainable, not to
discourage genuine contributors.

전면 금지를 원한다면 Disclosure 섹션을 다음으로 교체하면 됩니다.

### No AI-generated contributions
- Contributions that are substantially generated by AI tools are
  not accepted in this project, due to unresolved copyright and
  quality concerns. PRs suspected to be AI-generated may be
  closed without detailed review.

정책을 자동화로 받치기 — 기계가 먼저 거르게 하라

정책 문서만으로는 부족합니다. 사람 리뷰 전에 기계가 1차로 거르는 파이프라인을 깔아야 정책이 지속 가능해집니다.

PR 템플릿에 AI 고지 체크박스를 넣는 예시입니다.

<!-- .github/PULL_REQUEST_TEMPLATE.md -->
## Summary
<!-- What does this PR change and why? Link the issue. -->

## AI disclosure
- [ ] No AI tools were used for this contribution
- [ ] AI tools were used (specify tool and scope below)

AI tool and scope:

## Checklist
- [ ] I opened/linked an issue before this PR
- [ ] I added tests that fail without this change
- [ ] I ran the full test suite locally
- [ ] I can explain every line of this diff in my own words

CI에서 품질 게이트를 강제하는 GitHub Actions 워크플로 예시입니다.

# .github/workflows/quality-gate.yml
name: quality-gate
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Reject oversized PRs
        run: |
          CHANGED=$(git diff --stat origin/main... | tail -1)
          LINES=$(git diff origin/main... | grep -c '^[+-]' || true)
          echo "changed lines: $LINES"
          if [ "$LINES" -gt 800 ]; then
            echo "::error::PR too large (over 800 changed lines)."
            echo "Split into smaller, focused PRs per policy."
            exit 1
          fi

      - name: Require linked issue
        env:
          BODY: ${{ github.event.pull_request.body }}
        run: |
          echo "$BODY" | grep -Eiq '(closes|fixes|resolves) #[0-9]+' || {
            echo "::error::No linked issue found in PR body."
            exit 1
          }

      - name: Build and test
        run: |
          ./gradlew build test --no-daemon

      - name: Coverage threshold
        run: |
          ./gradlew jacocoTestCoverageVerification --no-daemon

이 워크플로의 효과는 단순한 검사 이상입니다. 드라이브바이 PR의 상당수는 이슈 링크 요건과 테스트 요건에서 자동으로 탈락하므로, 메인테이너의 큐에는 정책을 읽고 따른 기여만 도달합니다. 리뷰 시간이 곧 프로젝트의 가장 희소한 자원이라면, CI는 그 자원의 방화벽입니다.

여기에 더해 2026년의 흥미로운 흐름 하나는 AI로 AI를 거르는 시도입니다. 리뷰 봇이 PR의 변경 요약, 정책 위반 의심 항목, 테스트 부재를 1차 스크리닝해 메인테이너에게 보고하는 방식입니다. 코딩 에이전트가 일으킨 문제를 코딩 에이전트로 완화하는 셈인데, 오탐 위험이 있으므로 자동 클로즈가 아니라 라벨링과 우선순위 분류까지만 맡기는 것이 안전한 운영입니다.

사례 시나리오 — 어디까지가 괜찮은가

추상적 정책을 구체적 상황에 적용해 보겠습니다. 다음 세 시나리오를 비교해 보면 경계가 선명해집니다.

시나리오 A — 수용 가능
  기여자가 버그를 직접 재현하고 이슈를 연 뒤,
  코딩 에이전트로 수정 초안을 만들고, 전체 diff를
  직접 검토/수정하고, 실패-통과 테스트를 추가하고,
  PR 설명에 AI 사용 범위를 고지했다.
  → 책임 소재가 명확하고 검증 비용이 정상 범위

시나리오 B — 경계선
  기여자가 에이전트에게 "이 저장소에서 개선점을 찾아
  PR을 만들어 줘"라고 시켰다. 코드는 그럴듯하고
  테스트도 통과하지만, 리뷰 코멘트에 기여자가
  본인 언어로 답하지 못한다.
  → 표면 품질과 무관하게, 책임의 공백이 발생
  → 대부분의 프로젝트에서 닫혀야 정상

시나리오 C — 명백한 위반
  같은 계정이 하루에 수십 개 저장소에 유사한
  자동 생성 PR을 뿌린다. 이슈 없음, 테스트 없음,
  설명은 모델 특유의 정중한 보일러플레이트.
  → slop. 즉시 닫고 반복 시 차단이 표준 대응

시나리오 A와 C 사이의 거리는 도구가 아니라 인간의 개입량입니다. 정책 문서가 어떤 표현을 쓰든, 실무 판단 기준은 결국 "이 PR 뒤에 책임지는 사람이 있는가"로 수렴합니다.

자주 나오는 질문들

논쟁에서 반복적으로 등장하는 질문 몇 가지를 정리합니다.

질문 1. AI 사용을 어떻게 검증하나? 검증할 수 없습니다. 고지 의무는 거짓말 탐지기가 아니라 신뢰 계약입니다. 허위 고지가 들통나면(리뷰 문답에서 대부분 드러납니다) 신뢰 위반으로 처리하면 됩니다.

질문 2. 자동완성 한 줄도 고지해야 하나? 합리적인 정책은 "실질적 부분(substantial part)"에만 고지를 요구합니다. IDE 자동완성 수준까지 고지를 요구하는 정책은 집행 불가능하고 신뢰만 갉아먹습니다.

질문 3. 금지 정책은 위선 아닌가, 메인테이너도 AI를 쓸 텐데? 차이는 책임 구조입니다. 메인테이너는 머지된 코드의 최종 책임자이므로, 자신이 검증한 AI 산출물을 쓰는 것과 검증되지 않은 외부 AI 산출물을 받는 것은 위험 프로파일이 다릅니다.

질문 4. 좋은 AI 기여까지 잃는 것 아닌가? 맞습니다. 그것이 정책의 비용입니다. 다만 메인테이너가 번아웃으로 떠나면 프로젝트 전체를 잃습니다. 정책은 더 작은 손실을 선택하는 행위입니다.

기여자 입장의 에티켓 — AI 시대의 좋은 PR

기여자 쪽에서도 지킬 것이 있습니다. AI를 쓰는 것 자체는 죄가 아니지만, AI 산출물의 검증 책임을 메인테이너에게 떠넘기는 것이 문제의 핵심임을 이해해야 합니다.

AI 시대 기여자 체크리스트
[ ] 프로젝트의 CONTRIBUTING.md와 AI 정책을 먼저 읽었다
[ ] 이슈를 먼저 열어 방향을 합의했다 (드라이브바이 PR 금지)
[ ] AI를 사용했다면 PR 설명에 솔직히 고지했다
[ ] 제출 전 모든 라인을 직접 읽고 이해했다
    — 설명 못 할 코드는 제출하지 않는다
[ ] 실패하는 테스트를 먼저 작성하고, 수정으로 통과시켰다
[ ] PR은 작게 — 한 PR에 하나의 논리적 변경만
[ ] 리뷰 코멘트에는 내 언어로 답한다
    — AI 응답 복붙으로 핑퐁하지 않는다
[ ] 거절당해도 메인테이너의 시간 주권을 존중한다

한 가지 실용적 조언을 보태면, AI로 작성 보조를 받는 것과 AI에게 기여를 외주 주는 것을 구분하는 기준은 "리뷰 코멘트에 막힘없이 답할 수 있는가"입니다. 이 기준을 통과하지 못하는 PR은 보내지 않는 것이 모두의 시간을 아낍니다.

메인테이너 번아웃 — 더 큰 그림

jqwik 사건을 개인의 까칠함으로 읽으면 본질을 놓칩니다. 오픈소스 지속가능성 조사들이 반복적으로 보여주듯, 핵심 인프라 프로젝트 상당수가 한두 명의 무급 메인테이너에게 의존합니다. xz 백도어 사건(2024)은 지친 메인테이너가 사회공학 공격의 표적이 될 수 있음을 보여줬고, 2026년의 npm 공급망 공격 사태는 그 교훈이 여전히 유효함을 증명했습니다.

AI 기여 홍수는 이 취약한 구조에 가해지는 새로운 하중입니다. 리뷰 큐가 길어지면 메인테이너는 세 가지 나쁜 선택지 사이에 놓입니다. 대충 리뷰하고 머지(품질/보안 위험), 전부 정독(번아웃), 기여 차단(커뮤니티 반발). jqwik의 선택은 세 번째였고, 그 반발이 우리가 본 논란입니다.

그래서 이 논쟁의 올바른 프레임은 "AI 찬성 대 AI 반대"가 아니라 "유한한 리뷰 자원을 어떻게 보호할 것인가"입니다. 같은 프레임에서 보면, AI 기여 정책은 코드 오브 컨덕트나 이슈 템플릿과 같은 계열의 도구입니다. 커뮤니티의 상호작용 비용을 낮추는 인프라인 것입니다.

균형 잡힌 시각 — 반론들도 정당하다

메인테이너 옹호 일변도로 끝내면 공정하지 않으니, 반대편 논거도 충실히 적겠습니다.

  • 수단 차별의 문제: 품질이 같다면 생성 수단으로 기여를 차별하는 것은 원칙적으로 이상합니다. 나쁜 것은 저품질이지 AI가 아니라는 주장은 논리적으로 타당합니다
  • 판별 불가능성: AI 생성 코드를 신뢰성 있게 판별할 수 없으므로, 금지 정책은 필연적으로 의심 기반 집행이 되고, 이는 오판과 위축 효과(선의의 기여자 이탈)를 낳습니다
  • 접근성 가치: AI 도구는 비원어민, 주니어, 장애가 있는 개발자의 기여 장벽을 낮춥니다. 전면 금지는 이 포용 효과까지 차단합니다
  • 역사의 교훈: 새 도구(IDE 자동완성, 코드 생성기, Stack Overflow 복붙)가 등장할 때마다 비슷한 저항이 있었고, 결국 도구는 정착하고 규범이 따라왔습니다. AI도 같은 경로를 밟을 가능성이 큽니다

현실적인 수렴점은 이미 보입니다. 도구는 허용하되 책임은 사람에게 — 즉 "당신이 제출한 모든 것은 당신이 이해하고 책임진다"는 원칙입니다. 2026년의 코딩 에이전트는 충분히 강력해서, 이 원칙만 지켜지면 AI 보조 기여의 평균 품질은 오히려 인간 단독보다 높을 수 있습니다. 문제는 도구가 아니라 책임의 공백입니다.

실무 적용 가이드

메인테이너라면 이번 주에 할 수 있는 일은 다음과 같습니다.

  1. CONTRIBUTING.md에 AI 정책 섹션 추가(위 템플릿 활용). 없는 것이 최악입니다
  2. PR 템플릿에 AI 사용 고지 체크박스 추가
  3. 이슈 우선 원칙(PR 전 이슈 합의) 명문화 — slop의 대부분은 이 관문에서 걸러집니다
  4. 거절 문구 매크로 준비: 정책 링크와 함께 닫는 표준 문구가 있으면 감정 소모가 줄어듭니다
  5. 리뷰 자동화 보강: CI에서 테스트 커버리지, 린트, 빌드를 먼저 돌려 사람 리뷰 전에 기계가 거르게 합니다

기여자라면 위의 체크리스트를 자신의 워크플로에 넣으면 됩니다. 특히 AI 사용 고지는 비용이 0이면서 신뢰를 쌓는 가장 쉬운 방법입니다.

조직(기업)이라면, 직원이 업무로 오픈소스에 기여할 때 따라야 할 AI 사용 가이드라인을 내부 규정으로 정리해 두는 것을 권합니다. 프로젝트 정책 위반은 개인이 아니라 회사의 평판 문제가 되기 때문입니다.

마치며

jqwik 사건이 던진 질문은 결국 이것입니다. 생성 비용이 0에 수렴하는 시대에, 검증 비용은 누가 부담하는가.

오픈소스는 기여의 선의를 전제로 설계된 시스템입니다. AI는 그 전제를 깨뜨린 것이 아니라, 선의 없는 기여의 양산 비용을 0으로 만들어 시스템의 암묵적 균형을 무너뜨렸습니다. 정책, 에티켓, 자동화는 그 균형을 새로 맞추는 도구들입니다.

메인테이너의 강경한 정책을 비난하기 전에 그들의 리뷰 큐를 상상해 보고, 기여자의 AI 사용을 비난하기 전에 그 도구가 낮춘 장벽의 가치를 생각해 보는 것. 양쪽의 비용 구조를 이해하는 것이 이 논쟁에 참여하는 최소한의 예의일 것입니다.

참고 자료

Discuss on Twitter • View on GitHub