기술 사업이 딸린 로펌인 Oracle은 자사 코드를 AI로 세탁한 이들을 고소할 선택지를 남겨두려는 듯함
출처가 불분명한 AI 생성 코드를 공개적으로 받아들이면 그런 소송 논리가 성립하기 어려움. 기술 부문은 양립하기 어렵다고 하겠지만 운전대는 법무 부문이 잡고 있음

음모론도 아니고 가장 그럴듯한 설명임

이유가 무엇이든 반AI 입장을 취한 건 긍정적으로 봄

법무 부서는 역설적으로 거대 언어 모델(LLM) 과 매우 비슷함. 좁은 데이터로 훈련되어 현실을 제대로 이해하지 못하고, 감독 없이 풀어두면 회사를 엉망으로 만듦
누군가는 “고객을 전부 고소해 화나게 하는 게 정말 최선인가?”라고 제동을 걸어야 함. 보통 CEO가 맡아야 하지만, 대기업 CEO들은 브라질 주짓수나 자기 소셜 미디어에서의 막말, 국제정치 개입, 가족 비영리단체 운영으로 너무 바쁨
법무를 CEO 직속에서 내려놓고, 홍보와 법무를 함께 감독하는 새 직책 아래 둬야 함. 모든 보도자료가 법무 검토를 받듯 모든 법적 조치도 홍보 검토를 거치는 게 논리적임. 다만 대기업 홍보 조직이 기업집단 중심 세계에서 쇠퇴한 문제는 별개임

속보: 관리자와 기업의 무능한 이들이 천재 행세하는 시대를 맞아 Oracle도 기술 기업인 척함

해당 글은 https://openjdk.org/legal/ai이며, OpenJDK 생성형 AI 임시 정책임. 이 페이지에 따르면 법무팀이 최종안을 작성 중임
Java와 저작권을 둘러싼 과거의 상처, 오래된 대기업이라는 특성을 고려하면 합리적인 조치로 들리지만 최종안이 더 나아질 거라고 기대하지는 않음

Java와 저작권을 둘러싼 상처 중 얼마나 많은 부분이 자초한 결과였을까?

Oracle이 AI에 전력투구한다는 점은 아이러니하지만 취지는 어느 정도 이해함. 신중하게 작성되지 않은 기여가 쏟아지면 이미 부족한 사람 검토자의 시간을 더 잡아먹음
수많은 주요 기업이 의존하는 프로젝트에서는 엄청난 위험이 될 수 있음

누군가 AI로 만든 쓰레기 더미를 건네며 “네가 알아서 검토해”라고 하면 정말 무례하고 짜증 남. 이제 누구나 프롬프트를 입력할 수 있고, 어려운 부분은 결과가 타당한지 판별하는 것임
AI 생성 코드를 전면 금지하는 것보다 나은 방법이 있겠지만, Oracle은 남의 불편보다 자기 검토 부담을 훨씬 더 걱정하는 듯함

약간 비꼬자면 Oracle은 원래부터 변호사에 전력투구했고, 소프트웨어가 최우선이었던 적은 없지 않나?

“AI에 전력투구하지만 결과가 눈에 보이는 곳에서는 제외한다”는 아이러니를 잠시 음미해 볼 만함
여기서 AI가 작성한 홍보문을 괴롭히는 문제가 내 직장의 AI 작성 홍보문에도 똑같이 나타남. 언젠가는 나아질지 모르지만 파레토 법칙이 떠오름

Oracle은 본질적으로 변호사가 고객에게서 돈을 뜯어낼 수 있도록 소프트웨어 라이선스를 판매하는 법무 부서임
Google에서 Oracle org chart meme을 이미지 검색해 보면 밈으로만 치부하기 어려움

George Lucas가 Jedi, Dark Side, 심지어 Jar Jar까지 모두 소유한 것과 비슷함

Oracle이 Sun을 인수하기 전에는 Sun의 프로젝트였음. Sun은 당시 Netscape와 긴밀히 협력해 오픈소스 소프트웨어의 기반을 만드는 데 기여함
1998년부터 2004년 무렵까지 Netscape와 Sun은 오픈소스 라이선스와 개발 모델의 가장 강력한 지지자였고, Oracle은 인수를 통해 그 호의까지 흡수함

Java는 이미 성숙한 제품이며 “빠르게 움직이고 깨뜨리는” 개발 시대를 지났다는 사실을 놓치는 듯함
코드는 부채이므로 AI 기여를 허용해서 얻을 것보다 잃을 것이 많을 가능성이 큼

Java에는 애초에 “빠르게 움직이고 깨뜨리는” 시기가 없었음. 소스 수준을 넘어 완전한 바이너리 클래스 호환성을 유지해 일반적으로 1998년 애플리케이션도 지금 실행할 수 있음
그 일부를 포기하게 만든 건 비교적 최근의 변화, 주로 Java 9의 Jigsaw였음

이는 AI 생성·보조 코드가 불충분하다는 명백한 인정임. 지난 몇 년간 Oracle이 AI에 막대한 돈을 쓴 점을 고려하면 충격적임

Java는 한 번도 “빠르게 움직이고 깨뜨리는” 방식이 아니었음

Oracle Java는 사실상 현상 유지(KTLO) 단계임
현재 Java의 최대 사용처는 Android지만 Google은 장기적으로 Fuchsia로 이전하려 하고, 두 번째는 Apache Spark와 Kafka임. 이제 LLM으로 그 기능을 순수 C로 다시 구현할 수 있으니 Oracle은 주 수익원인 법적 논리만 원하는 듯함

Oracle이 데이터센터와 감원 양쪽에서 AI에 크게 베팅한 점을 고려하면 이상함

JVM 개발자들은 매우 뛰어남

아이러니하지만 적어도 어떤 부서는 현실을 깨달은 듯함

OpenJDK 기여는 사람이 직접 작성해야 하지만 Oracle 내부에서는 AI 생성 코드를 사용한다는 얘기임. 직원이 AI 코드를 더 잘 검토한다고 가정하는 것인지 모르겠고, 여전히 이상해 보임

이런 정책은 합리적이라고 봄. 6개월 동안 직접 코드를 한 줄도 작성하지 않았지만 핵심은 AI 사용 사실이 드러나면 안 된다는 것임
AI는 원래 못 했을 일을 가능하게 해주지만 사고를 대신하는 목발이 되어서는 안 됨. 직접 구현했을 때보다 품질이 높아져서 알아채는 경우가 아니라면 AI 사용 흔적이 보여서는 안 됨
깊은 조사를 바탕으로 잘 작성한 문서나, 수작업으로는 너무 오래 걸렸을 광범위한 테스트가 좋은 예임. 단순히 “이걸 하고 PR을 올려”라고 시키는 건 나쁨
나는 AI로 코드를 만든 뒤 첫 번째 검토자처럼 살펴보고 수정안을 제시하며 계속 다듬음. 때로는 직접 다시 쓰는 편이 빨라도 이미 도구 안에서 작업 중이라 기다리는 비용은 거의 없음
AI가 작성했더라도 내가 이해하고 충분히 다듬은 코드로 JVM에 기여하는 걸 무엇이 막을 수 있을까? 사람이 정말 AI 작성 여부를 판별할 수 있을까?

내부 PR도 똑같은 문제를 안고 있지만 경영진이 AI 서사를 밀고 있고 비공개 코드베이스의 현실은 숨길 수 있음
AI 투자의 제한적인 수익률을 다룬 기사들이 LinkedIn 집단사고에 서서히 스며들다 임계점에 도달하면, 쓸 만한 개발 도구를 화이트칼라 노동을 대체할 특이점의 시작처럼 떠받드는 일을 멈추고 실제 사업 가치를 만드는 데 돌아갈 것임

단지 라이선스 권리 문제를 극도로 경계하는 것이라고 봄

스스로를 속이지 않으면 이상하지 않음. AI 사용은 코드 품질 향상과 무관하며 이제는 과시용 지위 표시에 가까움