▲

AI가 이 코드의 작동 방식을 깊이 이해하고 있다

 (github.com/ocaml)
3P by GN⁺ 21시간전 | ★ favorite | 댓글 2개
  • 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 보조 개발이 오픈소스 프로젝트에 통합될 때 필요한 절차와 기준을 둘러싼 논의를 촉발함
▲
iolothebard 8시간전  [-]

그런데… PR을 제출한 사람은 전혀 이해하지 못하고 있다.
그러므로… 본 PR을 각하한다. (땅땅땅)

답변달기
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • OCaml 메인테이너들이 어려운 사람을 다루는 특별한 훈련이라도 받은 건지 궁금함
    그들의 인내심과 성숙함이 놀라울 정도임. 나였다면 Torvalds식으로 바로 차단했을 것 같음

    • 내가 다니는 대기업에서는 AI에 회의적이면 왕따 취급받는 분위기임
      리더십이 AI에 거의 종교적인 믿음을 가지고 있어서, 모든 엔지니어가 AI를 최대한 쓰길 원함
      코드 리뷰도 점점 AI가 맡고 있음. 다만 이 경우는 그런 이유로 친절했던 건 아닌 듯함
    • 대형 오픈소스 프로젝트의 메인테이너라면 자연스럽게 그런 훈련을 받게 되는 것 같음
    • 기여자가 악의적인 의도는 없어 보였음. 그 에너지를 건설적으로 전환할 방법이 있었을지도 모름
      예를 들어 PR을 나누거나 설계 제안을 하게 유도하는 식으로
    • 어떤 사람들은 AI의 존재로 인해 사고가 망가진 듯함
      메인테이너들이 너무 착해서, 그런 사람들에게 시간을 낭비하는 걸 보면 답답함
    • 스레드를 다시 읽으며 감탄했음
      메인테이너들이 감정 없이 논리와 공감으로 대응하는 모습이 정말 교과서적인 커뮤니케이션이었음
      다만 이런 친절함이 오히려 환상을 강화시키는 건 아닌지 고민됨

  • 어떤 사람은 LLM보다도 자기 인식이 부족해 보였음
    AI가 만든 커밋의 정당성을 AI에게 물어보는 건 정말 어처구니없음
    그래도 최소한 솔직하긴 했음. “이 쓰레기 산을 유지보수하겠지만 돈은 줘야 함”이라는 말이 압권이었음

    • 커뮤니티가 침착하게 건설적 피드백을 준 게 인상적이었음
      그 덕분에 나도 OCaml 생태계에 기여하고 싶다는 생각이 들었음
    • 그는 단순히 멍청한 게 아니라 고수준의 트롤일 수도 있다고 생각함
    • 그 부분이야말로 케이크 위의 장식 같은 장면이었음

  • “왜 제출한 파일의 저자가 Mark Shinwell로 되어 있나요?”라는 질문에
    “AI가 그렇게 정했어요, 저는 묻지 않았어요”라고 답한 게 모든 걸 요약함

    • 그 전에 “AI가 이 코드를 깊이 이해하고 있으니 도전해보라”고 말했었다는 게 더 웃김
    • 좋은 개발자는 여러 추상화 레벨에서 동시에 사고해야 한다는 말을 떠올리게 됨
      이런 AI 세대들은 최소한의 다각적 사고조차 하지 않음
      저작권이 왜 들어갔는지 물을 게 뻔한데, 답변 준비도 안 되어 있었음
    • 오픈소스이긴 하지만 이런 식의 기여는 정신적 오픈소스 정신과는 거리가 멀다고 느낌
      결국 리뷰 부담은 메인테이너에게 전가되고, 유지보수 책임은 기여자가 지지 않음
    • 처음엔 농담인 줄 알았는데 진짜였다니 충격이었음
    • 혹시 진짜 Mark Shinwell이 여기 있나 싶어 그의 GitHub 프로필을 찾아봤음

  • 이 사람의 이력서가 전설적임
    월가 은행들을 거쳐 Deutsche Bank 기술 이사, EA에 라이선스 판매,
    “Hardcore Erlang” 책 집필 시도, 2일 만에 200만 달러 크립토 펀딩 등
    천재이거나 세기의 허풍쟁이 둘 중 하나일 듯함
    관련 링크: http://wagerlabs.com/articles/category/uptick">이전 블로그, http://wagerlabs.com/resume.pdf">이력서 PDF, 인터뷰, 공식 사이트, Erlang 책 취소 소식

  • 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이었음
    해당 커밋 링크

    • 적어도 그 변경분만큼은 AI가 쓴 게 아닐 수도 있겠다는 농담이 나왔음 /s
답변달기