아이 AI 수업은 도구 말고 누가 가르치는지부터 보자

이미지
아이들 AI 수업은 지금 누가 가르치고 있을까요. 얼마 전에 아이 학교 참관수업을 보고 왔습니다. 요즘은 수업 시간에 AI로 글을 쓰는 것 같은 걸 가르치는 모양입니다. 보고 나오면서 든 생각은 하나였습니다. 개발자 입장에서 보면 이건 아니다 싶었습니다. 처음 드는 생각도 아닙니다. 스크래치가 유행할 때도, 마인크래프트로 코딩을 가르친다고 할 때도 저는 비슷한 생각을 했습니다. 도구 이름은 그때마다 바뀌었는데, 개발자 눈에 비어 보이는 것은 매번 같았습니다. 도구가 문제였다면 도구가 바뀔 때 뭔가 달라졌어야 합니다. 세 번을 바꿔도 같은 것이 비어 있으니 도구보다 앞에 원인이 있다고 봤고, 그걸 따라가다 보니 가르치는 사람이 어디서 배워서 교실에 들어오는지에 닿았습니다. 범위를 먼저 그어 두겠습니다. 참관수업이 몇 학년 무슨 수업이었는지, 누가 가르쳤는지는 적지 않습니다. 이 글은 교실 하나나 강사 한 사람을 두고 하는 이야기가 아닙니다. 제도에 관한 사실은 원문을 열어서 확인한 것만 쓰고, 확인하지 못한 것은 제 판단이라고 밝혀 두겠습니다. 인용한 자료는 전부 2026년 9월 27일에 확인했습니다. 디지털새싹 강사는 이틀짜리 양성과정을 거쳐 교실에 들어갑니다 배경부터 짧게 적겠습니다. 소프트웨어 교육은 중학교가 2018학년도 신입생부터, 초등학교 5·6학년이 2019년부터 필수가 됐습니다( 한국일보, 2017-12-27 ). 그리고 2025년부터 적용되는 2022 개정 교육과정에서 정보 수업 시간이 초등은 17시간에서 34시간 이상으로, 중학교는 34시간에서 68시간 이상으로 늘었습니다( 정책브리핑, 2022-08-29 ). 정규 교과 안의 정보 수업은 학교 선생님이 맡습니다. 교과 밖으로 들어오는 AI 교육은 경로가 다릅니다. 대표적인 게 교육부의 디지털새싹입니다. 올해는 대학과 공공·민간기관을 대상으로 운영기관 공모를 해서 45곳을 골랐고, 이 기관들이 267종의 프로그램을 들고 학교로 직접 찾아가 8~12차시 이상씩 수업을 합니다. AI ...

리눅스 커널은 AI 에게 Signed-off-by 를 금지했다

제가 혼자 만드는 Unity 모바일 게임 저장소는 비공개입니다. 그래서 아래 숫자는 누가 열어서 확인할 수 있는 게 아니고, 제 상태를 보여주는 용도로만 적습니다.

2026년 3월 29일 첫 커밋부터 9월 9일까지 다섯 달 반 동안 커밋이 239개 쌓였습니다. 그중 187개에 Co-Authored-By: Claude 가 붙어 있습니다. Signed-off-by: 가 붙은 커밋은 0개입니다. Assisted-by: 도 0개입니다.

각자 저장소에서 세어 보려면 세 줄이면 됩니다.

git log --oneline | wc -l
git log --format='%b' | grep -ci 'Co-Authored-By'
git log --format='%b' | grep -ci '^Signed-off-by:'

비공개라서 아무도 저에게 서명을 요구한 적이 없습니다. 혼자 쓰고 혼자 머지하니 DCO 를 걸어 둘 이유가 없었고, 그래서 저 두 줄이 서로 다른 일을 한다는 것도 생각해 본 적이 없었습니다. 공동 저자가 한 명 더 있다고 적은 적은 187번 있는데, 내가 만들었고 내가 제출할 권리가 있다고 밝힌 적은 한 번도 없습니다. 남의 저장소에 PR 을 올리는 순간 그 둘이 전혀 다른 줄이라는 게 드러납니다.

이 글에서 인용 부호 안의 영문은 전부 원문 그대로이고, 그 바깥의 판단은 제가 적은 것입니다. 영문을 인용한 자리마다 옮긴 문장을 바로 뒤에 붙였습니다. 리눅스 커널과 QEMU, NetBSD, Gentoo 문서와 DCO 원문은 2026년 9월 13일에 파일을 직접 받아 확인했고, 저작권 쪽은 보고서 요지와 해설을 통해 본 것이라 그 차이가 드러나게 적었습니다.

developercertificate.org 에 적힌 네 항목

Signed-off-by 는 커밋 메시지 맨 아래 붙는 트레일러 한 줄이고, 그 한 줄이 가리키는 문서가 Developer Certificate of Origin 1.1 입니다. 커널이 만들어 쓰기 시작했고 지금은 여러 프로젝트가 같은 문서를 그대로 가져다 씁니다. 서명을 붙인다는 건 이 문서의 (a)부터 (d)까지 중 하나에 해당한다고 밝히는 행위입니다.

(a) 항은 이렇게 시작합니다.

The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file

옮기면, 이 기여물은 전부 또는 일부가 나에 의해 만들어졌고, 나는 파일에 표시된 오픈소스 라이선스로 이것을 제출할 권리가 있다는 뜻입니다.

문장 하나에 두 가지가 들어 있습니다. 내가 만들었다는 것과, 제출할 권리가 나에게 있다는 것. 저작자성과 제출 권한이 한 줄에 묶여 있고, 서명은 그 둘을 동시에 주장합니다.

(b) 항은 남의 작업 위에 얹은 경우입니다.

The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, ...

옮기면, 이 기여물은 내가 아는 한 적절한 오픈소스 라이선스가 걸린 기존 작업에 기반하고 있고, 나는 그 라이선스에 따라 그 작업을 수정한 형태로 제출할 권리가 있다는 뜻입니다. (c) 항은 더 짧습니다. 다른 사람이 (a)나 (b)나 (c)를 확인해서 나에게 직접 준 것이고 내가 고치지 않았다는 경우입니다.

(d) 항은 성격이 다릅니다. 기여물과 함께 제출한 개인 정보가 서명을 포함해 무기한 보존되고 재배포될 수 있다는 데 동의하는 항목입니다. 이름과 이메일이 트리에 영구히 남습니다.

그러니까 이 한 줄은 출처를 표시하는 줄이 아닙니다. 누가 이 코드를 썼는지 알려 주는 게 목적이었다면 (b)와 (c)가 필요 없었을 겁니다. 이 줄이 하는 일은 문제가 생겼을 때 물어볼 사람을 한 명 확정하는 것입니다.

커널 문서가 AI agents MUST NOT 이라고 적은 자리

리눅스 커널에는 Documentation/process/coding-assistants.rst 가 있습니다. 코딩 어시스턴트를 쓸 때 무엇을 지키라는 문서인데, 첫 부분에 이런 문장이 있습니다.

AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).

옮기면, AI 에이전트는 Signed-off-by 태그를 붙여서는 안 된다, 오직 사람만이 DCO 를 법적으로 증명할 수 있다는 뜻입니다.

금지의 이유를 능력 부족이 아니라 법적 자격으로 적었습니다. 모델이 코드를 못 짜서가 아니라, 증명이라는 행위를 할 수 있는 주체가 아니어서입니다. 앞 절에서 본 (a) 항을 다시 보면 이유가 보입니다. 제출할 권리가 있다고 주장하려면 권리를 가질 수 있는 자리에 있어야 하는데, 도구는 거기 들어가지 못합니다.

같은 문서가 사람 제출자의 몫으로 네 가지를 적어 뒀습니다. "Reviewing all AI-generated code" 는 AI 가 생성한 코드를 전부 검토하는 것, "Ensuring compliance with licensing requirements" 는 라이선스 요건 준수를 확인하는 것, "Adding their own Signed-off-by tag to certify the DCO" 는 DCO 를 증명하기 위해 본인의 Signed-off-by 태그를 붙이는 것, "Taking full responsibility for the contribution" 은 그 기여에 대한 전적인 책임을 지는 것입니다.

그러면 도구를 썼다는 사실은 어디에 적느냐. 커널은 그 자리를 따로 만들었습니다. 형식은 Assisted-by: LLM [TOOL1] [TOOL2] 이고, 대괄호 안은 선택 항목입니다. 거기 적는 건 coccinelle 이나 sparse, smatch, clang-tidy 같은 전문 분석 도구이고, 문서는 이렇게 선을 긋습니다. "Basic development tools (git, gcc, make, editors) should not be listed." 기본 개발 도구인 git 과 gcc, make, 에디터는 적지 말라는 뜻입니다.

버그 수정 절차를 아홉 단계로 적어 둔 부분이 있는데, 그중 6번이 이겁니다. "Do not add a Signed-off-by tag, and add an Assisted-by tag, as described above." 서명 태그는 붙이지 말고 위에서 설명한 대로 Assisted-by 태그를 붙이라는 뜻입니다.

한 줄은 금지하고 다른 한 줄은 요구합니다.

Co-developed-by 규칙은 저자마다 서명을 하나씩 요구합니다

여기까지는 커널 문서가 직접 적은 내용입니다. 다음은 제 판단입니다.

Documentation/process/submitting-patches.rst 에는 공동 저자를 표시하는 트레일러 규칙이 따로 있습니다.

Since Co-developed-by: denotes authorship, every Co-developed-by: must be immediately followed by a Signed-off-by: of the associated co-author.

옮기면, Co-developed-by 는 저작자성을 나타내므로 모든 Co-developed-by 뒤에는 해당 공동 저자의 Signed-off-by 가 곧바로 따라와야 한다는 뜻입니다.

이 규칙과 앞 절의 금지를 나란히 놓으면 결론이 하나로 모입니다. 저자 자리에 이름을 적으면 그 저자의 서명이 따라와야 하는데, AI 는 서명을 할 수 없습니다. 그러니 AI 는 저자 자리에 들어갈 수 없습니다. 커널이 이 연결을 한 문장으로 적어 둔 건 아니고, 두 문서를 맞대 놓고 제가 얻은 판단입니다. 다만 Assisted-by 라는 새 트레일러가 왜 필요했는지는 이렇게 봐야 설명이 됩니다. 저자가 아닌 자리가 필요했던 겁니다.

제가 187번 적은 Co-Authored-By 는 GitHub 관습의 트레일러라서 커널 규칙과 직접 관계가 없습니다. 하지만 하는 일은 같습니다. 저자를 한 명 늘립니다. 커널 문법으로 옮기면 그 줄은 서명을 데리고 와야 하는 줄이 되고, 데려올 서명이 없습니다.

제 저장소에서는 이게 문제가 되지 않았습니다. 저 줄을 읽는 사람이 저 하나니까요. 문제가 되는 건 같은 습관을 들고 남의 트리에 갔을 때입니다.

torvalds/linux 트리에서 Assisted-by 를 세어 봤습니다

규칙이 생겼다고 트리에 바로 나타나는 건 아니라서 GitHub 커밋 검색으로 torvalds/linux 에서 Assisted-by: LLM 을 찾아봤습니다. 2026년 9월 13일 기준입니다.

99건이 나왔고 99건 전부 실제로 그 줄이 있었습니다. 그리고 99건 전부에 Signed-off-by: 가 함께 붙어 있습니다. 문서가 시킨 구조가 트리에서 그대로 확인됩니다. 표시는 도구가 받고 서명은 사람이 합니다.

날짜를 보면 최초가 2026년 6월 30일이고 최근이 9월 8일입니다. 6월 31건, 7월 16건, 8월 26건, 9월 26건으로, 세 달 남짓 사이에 몰려 있습니다.

한계를 밝혀 둡니다. 이건 GitHub 커밋 검색 색인 기준이라 전수가 아닙니다. 2026년 6월 이후에만 있다고 말할 근거는 못 되고, 검색으로 잡히는 범위에서 전부 6월 이후였다는 정도까지입니다.

저자 쏠림도 큽니다. Jori Koolstra 가 31건, Linus Walleij 가 20건으로 두 사람이 51건입니다. 그 뒤로 Jeff Layton 7건, Dmitry Torokhov 6건이 이어집니다. 커널 전체 커밋 수를 생각하면 99건은 관행이라기보다 소수가 먼저 써 보는 단계에 가깝습니다.

태그 본문은 대부분 Assisted-by: LLM 한 줄입니다. 89건이 그렇고, Assisted-by: LLM sparse 가 2건, Assisted-by: LLM (debugging, commit message) 가 3건입니다. 그리고 이렇게 적힌 게 한 건 있었습니다.

Assisted-by: LLM (initial analysis, but incorrect conclusion with too many burnt tokens)

초기 분석은 도와줬는데 결론이 틀렸고 토큰만 많이 태웠다는 뜻입니다. 도구를 썼다는 표시와 그 도구가 틀렸다는 기록이 같은 줄에 들어가 있습니다. 이 줄을 적은 사람은 바로 아래에 자기 서명을 붙였습니다.

generated-content.rst 가 밝히라고 한 범위와 빼 준 범위

커널에는 Documentation/process/generated-content.rst 가 하나 더 있습니다. 적용 범위를 이렇게 잡습니다.

These guidelines apply when a meaningful amount of content in a kernel contribution was not written by a person in the Signed-off-by chain, but was instead created by a tool.

옮기면, 이 지침은 커널 기여물에서 의미 있는 분량의 내용이 Signed-off-by 사슬에 있는 사람이 쓴 것이 아니라 도구가 만들어 낸 경우에 적용된다는 뜻입니다.

기준이 서명 사슬입니다. 서명한 사람이 쓰지 않았으면 대상입니다.

빼 주는 것도 적어 뒀습니다. 맞춤법과 문법 수정, 식별자 자동완성 같은 타이핑 보조, 변수명 변경처럼 순수하게 기계적인 변환, Lindent 나 clang-format, rust-fmt 같은 재정렬은 이 지침의 대상이 아닙니다.

대상이 되는 예로 든 것 중 하나가 눈에 걸렸습니다.

The changelog was generated by handing the patch to a generative AI tool and asking it to write the changelog.

옮기면, 패치를 생성형 AI 도구에 넘겨 changelog 를 써 달라고 해서 만든 경우입니다. 코드가 아니라 커밋 메시지만 맡긴 것도 밝힐 대상이라는 뜻입니다. 제 커밋 187개 중에 메시지를 제가 처음부터 타이핑한 건 거의 없습니다. 이 기준을 그대로 들고 오면 코드를 한 줄도 받지 않은 커밋까지 대상에 들어갑니다.

밝히는 방법도 구체적입니다.

If code was largely generated from a single or short set of prompts, include those prompts. For longer sessions, include a summary of the prompts and the nature of resulting assistance.

옮기면, 코드가 하나 또는 짧은 프롬프트 묶음에서 대부분 생성됐다면 그 프롬프트를 포함시키고, 더 긴 세션이라면 프롬프트 요약과 받은 도움의 성격을 포함시키라는 뜻입니다. 세션이 길어지면 요약을 붙이라는 건데, 요약을 쓰려면 세션에서 무슨 일이 있었는지 자기가 알고 있어야 합니다.

메인테이너 쪽 재량도 적혀 있습니다. 즉시 거부하는 것과 사람이 쓴 기여보다 낮은 우선순위로 검토하는 것이 둘 다 선택지로 들어 있습니다. 그리고 문서 안에 이 문장이 있습니다.

You are expected to understand and to be able to defend everything you submit. If you are unable to do so, then do not submit the resulting changes.

옮기면, 당신은 제출하는 모든 것을 이해하고 방어할 수 있어야 하며, 그럴 수 없다면 그 변경을 제출하지 말라는 뜻입니다. 이어서 그렇지 못하면 메인테이너가 상세한 검토 없이 시리즈를 거절할 자격이 있다고 적혀 있습니다.

방어할 수 있느냐가 제 쪽에서 제일 걸리는 항목입니다. 이 분기가 왜 여기 있는지, 입력이 비어서 들어오면 어디로 가는지, 이 함수를 걷어내면 무엇이 같이 깨지는지에 대답할 수 있어야 합니다. 혼자 쓰는 저장소에서는 대답을 요구하는 사람이 없어서 대답할 수 있는지 확인할 기회도 없었습니다.

QEMU 는 DCO 의 b 항과 c 항을 지킬 방법이 없다고 적었습니다

커널이 태그를 만들어 받는 쪽이라면, 반대쪽 끝에 QEMU 가 있습니다. docs/devel/code-provenance.rst 를 받아 보면 이렇게 적혀 있습니다.

Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

옮기면, 현재 QEMU 프로젝트 정책은 AI 생성 콘텐츠를 포함하거나 거기서 파생된 것으로 보이는 기여를 모두 거절하는 것이고, 여기에는 ChatGPT 와 Claude, Copilot, Llama 및 유사 도구가 포함된다는 뜻입니다.

거절의 근거를 품질이 아니라 DCO 에 뒀습니다.

To satisfy the DCO, the patch contributor has to fully understand the copyright and license status of content they are contributing to QEMU. With AI content generators, the copyright and license status of the output is ill-defined with no generally accepted, settled legal foundation.

옮기면, DCO 를 충족하려면 패치 기여자가 QEMU 에 기여하는 내용의 저작권과 라이선스 상태를 완전히 이해하고 있어야 하는데, AI 콘텐츠 생성기의 경우 산출물의 저작권과 라이선스 상태가 불명확하고 일반적으로 인정되는 확립된 법적 기반이 없다는 뜻입니다. 이어서 오늘날 흔한 AI 생성기의 산출물에 대해 기여자가 DCO 의 (b) 항이나 (c) 항을 어떻게 준수할지 불분명하며, 프로젝트는 준수하지 못하는 법적 위험을 감수할 의사도 능력도 없다고 적었습니다.

앞에서 본 (b)와 (c)가 여기서 걸립니다. 기존 작업에 기반한 경우 그 라이선스로 제출할 권리가 있는지 알아야 하는데, 모델 출력이 무엇에 기반했는지를 기여자가 확인할 방법이 없습니다.

QEMU 도 AI 사용을 전부 막지는 않습니다. API 나 알고리즘을 조사하는 것, 정적 분석, 디버깅은 그 산출물이 기여물에 포함되지 않는 한 이 정책의 대상이 아니라고 적어 뒀습니다. 도구를 쓰는 것과 도구의 출력을 트리에 넣는 것을 나눈 셈입니다. 그리고 예외 절 끝에 이 문장이 있습니다.

the "Signed-off-by" label in a patch submission is a statement that the author takes responsibility for the entire contents of the patch, including any parts that were generated or assisted by AI tools or other tools.

옮기면, 패치 제출에서 Signed-off-by 라벨은 저자가 그 패치 내용 전체에 대해, AI 도구나 다른 도구가 생성하거나 보조한 부분까지 포함해 책임을 진다는 선언이라는 뜻입니다. 커널이 태그를 나눠서 도달한 자리에 QEMU 는 한 문장으로 도달했습니다.

이 정책은 고정된 게 아닙니다. 문서 끝에 AI 도구가 성숙하고 법적 상황이 명확해지면 정책이 바뀔 수 있다고 적혀 있고, 실제로 2026년 5월에 기계적 변경과 20줄 이하 버그 수정, 테스트에 한해 허용하면서 AI-used-for: 트레일러를 새로 두자는 패치가 메일링 리스트에 올라왔습니다. 리뷰 의견을 받은 채로 병합되지는 않았습니다. 커널은 Assisted-by 를 쓰고 QEMU 쪽 논의는 AI-used-for 로 가고 있어서, 어느 줄을 적어야 하는지는 올릴 프로젝트를 열어 봐야 압니다.

NetBSD 의 commit guidelines 2항은 LLM 이 생성한 코드를 "presumed to be tainted code" 로, 즉 오염된 코드로 추정한다고 적고, core 의 사전 서면 승인 없이는 커밋해서는 안 된다고 합니다. 전면 금지가 아니라 승인을 받아 오라는 조건입니다. 반대로 Gentoo 평의회가 2024년 4월에 채택한 정책은 자연어 처리 AI 도구의 "assistance" 를 받아 만들어진 콘텐츠를 Gentoo 에 기여하는 것을 명시적으로 금지한다고 적습니다. 문자 그대로 읽으면 커밋 메시지를 모델에게 다듬어 달라고 한 것도 걸립니다. 커널이 빼 준 맞춤법 교정과 자동완성이 여기서는 빠지지 않습니다.

데비안은 2026년 8월 결의문에서 "Debian continues to rely on the judgment and responsibility of its individual contributors" 라고 적었습니다. 개인 기여자의 판단과 책임에 계속 의존한다는 뜻입니다. 커널 문서에는 상세한 검토 없이 거절할 자격이 적혀 있는데 데비안 결의문에는 그런 조항이 없습니다. 같은 DCO 축 위에서 받는 쪽의 장치를 얼마나 두느냐가 갈립니다.

미국 저작권청은 프롬프트만으로는 저작권이 생기지 않는다고 봅니다

여기서부터는 확인 수준이 다릅니다. 앞 절들의 인용은 파일을 직접 받아 읽은 것이고, 아래는 보고서 요지와 해설을 통해 본 것입니다. 원문 전체를 대조하지는 않았습니다.

미국 저작권청이 2025년 1월에 낸 Copyright and Artificial Intelligence 두 번째 보고서는 인간의 저작자성을 저작권 성립의 기반으로 놓습니다. 전적으로 AI 가 생성한 산출물은 저작권의 대상이 되지 않는다고 보고, 프롬프트를 고르는 것만으로는 그 프롬프트가 아무리 상세하고 사람의 노력이 들어갔더라도 그 자체로 저작권이 성립하는 저작물이 나오지 않는다고 봅니다. 사람이 만든 부분과 AI 가 생성한 부분이 섞여 있으면 사람이 기여한 부분만 보호 대상이 될 수 있고, 그 판단은 사안별로 한다는 쪽입니다.

한국도 방향이 비슷합니다. 문화체육관광부의 생성형 AI 저작권 안내서와 저작권 등록 안내서를 보면 등록 요건은 인간의 창작적 기여이고, 사람의 개입 없이 AI 가 생성한 산출물은 원칙적으로 등록 대상이 아닙니다. AI 를 도구로 써서 사람이 창작성을 더한 경우를 생성형 AI 활용 저작물로 따로 구분해 등록할 수 있게 하면서, 판단 기준으로 통제가능성과 예측가능성을 제시합니다. 프롬프트 자체에 창작성이 있으면 저작물이 될 수 있다고 하면서도, 같은 프롬프트가 항상 같은 산출물을 내지는 않으므로 창작적 기여로 인정될 가능성은 낮게 봅니다.

제가 법률가가 아니라서 이게 제 코드에 어떻게 적용되는지 단정할 수는 없습니다. 다만 서명 쪽과 권리 쪽의 성격이 다르다는 건 눈에 들어옵니다.

서명은 확실합니다. AI 가 못 하니까 제가 합니다. 187개 커밋을 커널에 올린다면 제 이름이 187번 들어가고, 그중 하나에서 문제가 생기면 물어볼 사람은 저입니다. 그 부분을 모델이 썼다는 사실은 태그로 남을 수는 있어도 책임을 나누지는 않습니다.

권리 쪽은 그렇게 정리되지 않습니다. 저작권 당국이 지금 서 있는 자리에서 보면, 제가 대부분 프롬프트로 얻어낸 코드에 제 저작권이 얼마나 붙는지는 사안별로 따져야 하고, 프롬프트를 상세하게 썼다는 것만으로는 그 자리가 채워지지 않습니다. DCO (a) 항이 요구하는 두 가지 중 제출할 권리 쪽이 여기서 흔들립니다. 만든 사람 자리에 제가 있다고 확실히 말할 수 있는 범위가 어디까지인지가 명확하지 않으니까요.

책임은 전부 오고 권리는 일부만 옵니다. 이게 지금 제가 보고 있는 그림입니다.

Unity 프로젝트에 Signed-off-by 를 적을 자리는 아직 없습니다

제 게임 저장소는 앞으로도 한동안 비공개일 것 같습니다. Signed-off-by 를 붙이기 시작해도 읽는 사람이 저 하나라 증명할 상대가 없습니다.

달라진 건 Co-Authored-By: Claude 를 읽는 방식입니다. 지금까지는 그 줄을 어디서 도움을 받았는지 남기는 기록으로 읽었습니다. 커널 문법에서는 저자를 한 명 늘리는 줄이고, 늘린 저자는 서명을 데리고 와야 하는데 데려오지 못합니다. 표시를 남기려던 자리에 저작자성을 적고 있었던 셈입니다.

커널이라면 Assisted-by: LLM 을 쓰고 제 서명을 아래 붙일 겁니다. QEMU 라면 그 커밋은 애초에 올릴 수 없습니다. Gentoo 라면 커밋 메시지를 모델에게 맡긴 것도 걸립니다. 프로젝트마다 답이 다른 이유는 전부 같은 곳에서 나옵니다. 서명 한 줄이 무엇을 증명하기로 돼 있느냐입니다.

당분간은 커밋 메시지를 쓸 때 한 가지만 더 봅니다. 이 변경에 대해 누가 물어보면 제가 대답할 수 있는 상태인지. generated-content.rst 가 defend 라고 적은 그 상태 말입니다. 지금은 대답 못 할 커밋이 꽤 있을 것 같고, 그 비율을 줄이는 게 서명을 붙일 수 있는 저장소로 가는 조건이라고 보고 있습니다.

댓글

이 블로그의 인기 게시물

아이들은 우리 게임에 들어오지 못한다

AI 부업 강의 여섯 편이 "리스크가 제로죠"라고 말했다

AI가 썼다는 브라우저 300만 줄에서 112만 줄은 남의 코드였다