# AI가 이 코드의 작동 방식을 깊이 이해하고 있다 > Clean Markdown view of GeekNews topic #24637. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24637](https://news.hada.io/topic?id=24637) - GeekNews Markdown: [https://news.hada.io/topic/24637.md](https://news.hada.io/topic/24637.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-27T04:38:24+09:00 - Updated: 2025-11-27T04:38:24+09:00 - Original source: [github.com/ocaml](https://github.com/ocaml/ocaml/pull/14369) - Points: 4 - Comments: 2 ## Topic Body - OCaml 네이티브 컴파일러에 **DWARF v5 디버깅 정보**를 추가해 macOS와 Linux에서 **GDB·LLDB 소스 수준 디버깅**을 지원하는 1만3천라인짜리 대규모 PR이 제출됨 - 구현 내용에는 **함수·라인 단위 브레이크포인트**, **매개변수 및 지역 변수 추적**, **기본 타입 정보 표시**, **AMD64·ARM64 지원** 등이 포함됨 - 작성자는 이 코드가 **Claude Sonnet 4.5와 ChatGPT 5(Codex)** 등 AI 모델이 협업해 생성한 결과이며, 자신은 코드 작성 대신 **AI를 지휘·검토**했다고 밝힘 - OCaml 유지관리자들은 **저작권 문제, 설계 논의 부재, 유지보수 부담, AI 코드 검토 난이도** 등을 이유로 병합을 거부하고 PR을 종료함 - 이번 논의는 **AI 생성 코드의 품질·저작권·협업 절차**에 대한 오픈소스 커뮤니티의 새로운 과제를 드러낸 사례 --- ### DWARF v5 디버깅 지원 PR 개요 - PR은 OCaml 네이티브 컴파일러에 **DWARF v5 디버깅 정보**를 추가해 GDB와 LLDB에서 **소스 수준 디버깅**을 가능하게 함 - 함수명·파일·라인별 브레이크포인트 설정, 변수 이름 표시, 타입 정보 제공 - **AMD64·ARM64** 아키텍처 지원, 32비트 플랫폼은 미지원 - macOS(Mach-O)와 Linux(ELF) 모두에서 **섹션 상대 재배치**를 이용한 완전한 DWARF 지원 구현 - **LLDB 플러그인(ocaml_lldb.py)** 추가로 OCaml 값 출력 명령(`ocaml print`) 제공 - 테스트는 9개 항목으로 구성되어 **기능·타입·라인 디버깅**을 검증함 ### 구현 세부 사항 - DWARF v4에서 v5로 업그레이드하며 **DW_FORM_string**을 사용해 링크 오류를 방지 - **다중 컴파일 유닛(CU)** 지원 및 문자열 테이블 중복 제거 - **지역 변수·매개변수 추적**, **렉시컬 블록**, **기본 타입 정보**를 DWARF 구조에 반영 - **Var_lifetime** 모듈로 변수 생명주기 추적, **fun_var_info** 필드로 컴파일 파이프라인 전반에 변수 정보 전달 - **DW_TAG_lexical_block**을 통해 중첩 스코프 표현 - **테스트 스크립트**는 GDB·LLDB에서 브레이크포인트와 타입 표시를 검증 ### AI 생성 코드 논란 - 작성자는 “Claude Sonnet 4.5가 대부분 작성하고 ChatGPT 5(Codex)가 검토했다”고 밝힘 - 자신은 “AI를 지도하고 검토했을 뿐, 한 줄도 직접 작성하지 않았다”고 설명 - 일부 파일에 **Mark Shinwell**의 이름이 저자로 포함되어 있어 **저작권 출처 논란** 발생 - 작성자는 별도의 분석 보고서를 통해 “OxCaml 구현과는 구조·명명·타입 시스템이 다르며 복제 아님”이라 주장 ### 유지관리자들의 반응 - **gasche**: 설계 논의 없이 1만3천여 줄의 코드가 제출되어 **리뷰·유지보수 부담**이 크다고 지적 - AI 작성 코드는 “검토가 더 어렵고 법적 위험이 있다”며 병합 불가 결정 - **dra27**: “AI가 코드를 이해한다”는 표현을 비판하며, LLM은 이해가 아닌 **패턴 생성 도구**임을 강조 - **bluddy**와 **tmcgilchrist**: DWARF 코드는 별도 라이브러리로 분리해야 하며, 컴파일러 내부에 포함되면 **유지보수 부담**이 커진다고 언급 - 논의가 격화되자 PR은 **‘too heated’ 상태로 잠금 처리**됨 ### AI와 오픈소스 협업의 쟁점 - 작성자는 “AI가 고품질 코드를 완성할 수 있음을 증명하려 했다”며 **AI 기반 개발 실험**임을 강조 - 유지관리자들은 “AI 생성 코드의 품질·저작권·검토 절차”에 대한 명확한 정책 부재를 지적 - 이번 사례는 **AI 보조 개발이 오픈소스 프로젝트에 통합될 때 필요한 절차와 기준**을 둘러싼 논의를 촉발함 ## Comments ### Comment 46877 - Author: iolothebard - Created: 2025-11-27T17:13:50+09:00 - Points: 1 그런데… PR을 제출한 사람은 전혀 이해하지 못하고 있다. 그러므로… 본 PR을 각하한다. (땅땅땅) ### Comment 46843 - Author: neo - Created: 2025-11-27T04:38:24+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46039274) - OCaml 메인테이너들이 **어려운 사람을 다루는 특별한 훈련**이라도 받은 건지 궁금함 그들의 인내심과 성숙함이 놀라울 정도임. 나였다면 Torvalds식으로 바로 차단했을 것 같음 - 내가 다니는 대기업에서는 AI에 회의적이면 **왕따 취급**받는 분위기임 리더십이 AI에 거의 종교적인 믿음을 가지고 있어서, 모든 엔지니어가 AI를 최대한 쓰길 원함 코드 리뷰도 점점 AI가 맡고 있음. 다만 이 경우는 그런 이유로 친절했던 건 아닌 듯함 - 대형 오픈소스 프로젝트의 메인테이너라면 자연스럽게 그런 훈련을 받게 되는 것 같음 - 기여자가 악의적인 의도는 없어 보였음. 그 에너지를 **건설적으로 전환**할 방법이 있었을지도 모름 예를 들어 PR을 나누거나 설계 제안을 하게 유도하는 식으로 - 어떤 사람들은 AI의 존재로 인해 **사고가 망가진** 듯함 메인테이너들이 너무 착해서, 그런 사람들에게 시간을 낭비하는 걸 보면 답답함 - 스레드를 다시 읽으며 감탄했음 메인테이너들이 감정 없이 논리와 공감으로 대응하는 모습이 정말 **교과서적인 커뮤니케이션**이었음 다만 이런 친절함이 오히려 환상을 강화시키는 건 아닌지 고민됨 - 어떤 사람은 LLM보다도 **자기 인식이 부족**해 보였음 AI가 만든 커밋의 정당성을 AI에게 물어보는 건 정말 어처구니없음 그래도 최소한 솔직하긴 했음. “이 쓰레기 산을 유지보수하겠지만 돈은 줘야 함”이라는 말이 압권이었음 - 커뮤니티가 침착하게 **건설적 피드백**을 준 게 인상적이었음 그 덕분에 나도 OCaml 생태계에 기여하고 싶다는 생각이 들었음 - 그는 단순히 멍청한 게 아니라 **고수준의 트롤**일 수도 있다고 생각함 - 그 부분이야말로 케이크 위의 장식 같은 장면이었음 - “왜 제출한 파일의 저자가 Mark Shinwell로 되어 있나요?”라는 질문에 “AI가 그렇게 정했어요, 저는 묻지 않았어요”라고 답한 게 모든 걸 요약함 - 그 전에 “AI가 이 코드를 깊이 이해하고 있으니 도전해보라”고 말했었다는 게 더 웃김 - 좋은 개발자는 여러 **추상화 레벨에서 동시에 사고**해야 한다는 말을 떠올리게 됨 이런 AI 세대들은 최소한의 다각적 사고조차 하지 않음 저작권이 왜 들어갔는지 물을 게 뻔한데, 답변 준비도 안 되어 있었음 - 오픈소스이긴 하지만 이런 식의 기여는 **정신적 오픈소스 정신**과는 거리가 멀다고 느낌 결국 리뷰 부담은 메인테이너에게 전가되고, 유지보수 책임은 기여자가 지지 않음 - 처음엔 농담인 줄 알았는데 진짜였다니 충격이었음 - 혹시 진짜 Mark Shinwell이 여기 있나 싶어 [그의 GitHub 프로필](https://github.com/mshinwell)을 찾아봤음 - 이 사람의 **이력서가 전설적**임 월가 은행들을 거쳐 Deutsche Bank 기술 이사, EA에 라이선스 판매, “Hardcore Erlang” 책 집필 시도, 2일 만에 200만 달러 크립토 펀딩 등 천재이거나 세기의 허풍쟁이 둘 중 하나일 듯함 관련 링크: [이전 블로그](https://web.archive.org/web/20060624122838/http://wagerlabs.com/articles/category/uptick), [이력서 PDF](https://web.archive.org/web/20070101044653/http://wagerlabs.com/resume.pdf), [인터뷰](https://hackernoon.com/leaders-speak-joel-reymont-lead-developer-stegos-interview-2rhp3a3m), [공식 사이트](https://joel.id/resume/), [Erlang 책 취소 소식](https://www.reddit.com/r/programming/comments/674d1/joel_reymont_cancels_his_hardcore_erlang_book/) - AI가 만든 코드라도, 커뮤니티가 시간을 들여 대화하고 피드백을 주는데 작성자가 **AI가 쓴 긴 텍스트를 그대로 복붙**하는 건 즉시 차단 사유라고 생각함 스팸봇처럼 행동하면 스팸봇 취급받는 게 당연함 - 예전에 동료가 Jira 티켓을 ChatGPT에 붙여넣고 답변을 복사해 PR을 제출했음 내가 질문하면 그 답변이 전형적인 GPT 어투였음 결국 직접 실험해보니 거의 **단어 단위로 동일한 답변**이 나왔고, 그 이후로는 그의 코드를 리뷰하지 않겠다고 선언했음 - “AI가 작성한 저작권 분석입니다”라는 말이 나왔을 때 이미 한계였음 나 같으면 그 시점에서 바로 **리포 차단**했을 것임 - 메인테이너들의 **감정적 성숙도**가 놀라울 정도로 높았음 - 그냥 광대짓이었고, 웃고 넘기면 될 일이라고 생각함 - 나도 여러 오픈소스 프로젝트에서 **AI 생성 PR을 닫은 경험**이 있음 이런 기여자들은 한 프로젝트에서 거절당하면 다른 곳으로 옮겨 다님 리뷰 부담은 커지고, 진짜 기여자는 줄어듦 그래도 이런 토론을 HN에서 실시간으로 보는 게 흥미로움 - 이번 PR은 결국 닫히고 잠겼음. 메인테이너들이 **인내심 있게 대응**했지만 작성자는 논리에 전혀 설득되지 않았음. 다른 프로젝트들도 이렇게 버틸 수 있을 듯함 - 오픈소스 메인테이너들은 HN이나 Reddit에서 **조롱받기 싫어서라도** 이 물결에 저항할 것임 오히려 걱정해야 할 건 기업용 소프트웨어 쪽임 - AI 옹호자들에게 묻고 싶음 AI로 작성한 발표문을 발표한 뒤 질문을 받으면 뭐라고 답할 건가? 이 상황이 바로 그거임 - AI 옹호자 입장에서 말하자면, 문제는 AI 자체가 아니라 **이해하지 못한 채 제출하는 태도**임 13k 라인의 PR을 이해 없이 던지는 건 AI 유무와 상관없이 잘못된 일임 AI는 도구일 뿐, **CNC 머신을 쓰든 톱을 쓰든** 결과를 이해하는 게 중요함 - “AI가 그렇게 정했어요, 저는 묻지 않았어요”라는 답변이 모든 걸 말해줌 - “자금이 없어서 답변 못 합니다. 돈 주면 AI에게 물어보죠”라는 식의 태도는 황당함 - 사실 정치인들이 예전부터 그렇게 해왔다는 농담도 나왔음 - “AI가 당신의 질문을 완벽히 이해하고 있습니다. 틀렸다는 걸 증명해보세요”라는 말도 있었음 - 지금까지 본 AI 생성 PR 중 이건 **가장 독특한 사례**였음 대부분은 초보가 쓴 작동 안 되는 코드인데, 이번엔 복잡하고 실제로 동작했음 작성자 Joel Reymont는 30년 경력의 개발자였고, 2008년부터 HN 계정을 가진 베테랑이었음 OCaml 메인테이너들의 인내심이 대단했고, 결국 그는 인간적인 코멘트로 자신의 입장을 정리하며 AI로 OSS에 기여하는 건 그만두겠다고 했음 그래도 이런 PR은 여전히 **모두에게 시간 낭비**이며, 지금까지 생산적으로 활용된 사례는 본 적이 없음 - 정말 놀라운 PR이었음 [해당 커밋 링크](https://github.com/ocaml/ocaml/pull/14369/commits/ce372a60bd97e0a19b336c3042c4036cfda3c01e) - 적어도 그 변경분만큼은 AI가 쓴 게 아닐 수도 있겠다는 농담이 나왔음 /s