새해를 뜨겁게 달군 업스테이지 사건이 헤프닝으로 일단락하긴 했지만, 이 논쟁이 커뮤니티의 토론과 검증, 합의라는 긍정적 작용을 한 이면에는, 내용을 정확히 알지 못하는 분들이 제기하는 “해외 오픈소스를 베꼈다”, “코드 새로 다 안만들고 데이터만 넣은 게 무슨 혁신이냐”, “라이선스를 위반한 대국민 사기극이다”라는 부정적 논란들이 여전히 지속되고 있습니다.
이러한 논란을 지켜보는 제 마음은 좀 무겁습니다. 기업들이 오픈소스 라이선스 고지(Attribution)와 같은 기본적인 컴플라이언스(Compliance)를 소홀히 한 부분이 있다면, 시정이 되어야 하지만, 그러나, 일부 절차적 실수를 잡겠다고 초가삼간을 태우는 형국으로 흘러가서는 안됩니다.
지금의 논란은 단순한 도덕성 시비를 넘어, ① AI 모델의 기술적 본질(Code vs Weights), ② 오픈소스 개발 현장의 현실(Spectrum), ③ 생태계의 관행(License Correction) 에 대한 근본적인 몰이해에서 비롯된 측면이 크다고 봅니다.
그래서, 문과와 이과의 경계인(?). 정책입안자와 현장종사자의 경계인(?), 기술과 제도의 경계인(?)인 제가 좀 풀어서 설명해서, 지금의 이 논란을 좀 정리해보고자 합니다.
- 카피라이트와 라이선스, 그리고 ‘도둑질’의 오해
정확히 내용을 알지 못하는 사람들과 일부 비전문가들은 ‘코드를 가져다 쓰는 행위’ 자체를 마치 논문의 표절이나 물건을 훔치는 도둑질과 동일시하는 경향이 있습니다. 하지만, 소프트웨어, 특히 오픈소스로 구동되는 AI 생태계에서의 문법은 전혀 다릅니다. 이 오해를 풀기 위해서는 가장 기초적인 두 가지 개념의 분리가 선행되어야 합니다
1) 카피라이트(Copyright)
카피라이트, 즉 저작권은 “이 코드를 누가 작성했는가”를 증명하는 창작자의 권리입니다. 아파치 재단(Apache Foundation), 메타(Meta), 혹은 허깅페이스(Hugging Face)에 코드를 기여한 수많은 익명의 개발자들이 바로 저작권자입니다. 우리가 오픈소스를 가져다 쓴다고 해서 이 저작권이 우리에게 넘어오는 것은 아닙니다.
2) 라이선스(License)
반면 라이선스는 저작권자가 사용자에게 부여하는 허락이고 계약입니다. 현재 모든 AI 생태계를 지탱하는 아파치 2.0(Apache 2.0) 라이선스의 핵심 철학은 <제한 없는 자유>입니다.
원작자는 이런 라이선스를 통해 이런 소리를 하는겁니다.
“제발 이 코드를 가져가서 마음대로 뜯어고치고(수정), 더 좋은 것을 만들어 돈도 벌고(상업적 이용), 생태계를 확장해 주세요!!!!!”
이렇게 판을 깔아준 것입니다.
따라서 기업들이 오픈소스를 기반으로 모델을 개발하는 것은 ‘몰래 훔치는 것’이 아니라, 원작자가 깔아놓은 판 위에서 정당하게 부여받은 권리를 행사하는 것입니다. 이를 두고 “남의 것을 썼으니 너희 기술은 가짜아니야!!! “라고 비난하는 것은, 지난 30년간 소프트웨어 혁신을 이끌어온 오픈소스 정신을 전면으로 부정하는 것입니다.
- LLM 기술의 본질 = 코드는 ‘빈 그릇’, 가중치는 ‘채워진 지능’
이제 기술을 얘기해보겠습니다. 일각에서는 “오픈소스 코드를 그대로 가져와서 데이터만 들이부은 게 무슨 기술이냐”고 폄하합니다. 특히, 가중치(Weights)를 백지 상태(Random Initialization)에서부터 새로 학습시킨 경우조차 ‘베끼기’로 매도되고는 합니다. 단언컨대, LLM의 본질을 전혀 모르는 이야기입니다.
1) 코드는 뇌의 해부도일 뿐이다
AI 모델의 소스 코드(Python 파일 등)는 뇌의 해부학적 구조도에 불과합니다.
“뉴런을 몇 층으로 쌓아라”, “신호를 어떻게 전달하라”는 설계도인거죠.
이 설계도 자체는 텅 빈 껍데기입니다. 이 코드만 실행한다고 해서 AI가 말을 하거나 추론을 할 수 있는 것은 당연히 전혀 아닙니다. 굳이 비교해보자면, 갓 태어난 아기의 뇌가 구조적으로는 완성되어 있어도 지식은 전무한 것과 같습니다.
2) 혁신과 진정한 기여는 가중치(Weights)에 있다
진짜 지능은 수조 개의 텍스트 데이터(토큰)를 읽고, 수천 대의 GPU를 동원해 수 개월간 학습하는 과정에서 만들어집니다. 이 과정에서 뉴런 간의 연결 강도, 즉 가중치(Weights)가 계속 조정되면서, 비로서야 AI가 언어를 이해하고 세상을 배우는 겁니다,
AI 모델 개발에서 소스 코드가 차지하는 비중이 5%라면, 좋은 데이터를 선별하고(Data Curation), 학습 파라미터를 튜닝하며, 막대한 컴퓨팅 자원을 투입해 최적의 가중치를 찾아내는 사전 학습(Pre-training) 과정이 95%의 핵심 기술이자 자본입니다.
3) 같은 코드, 완전히 다른 인격체
기본 레시피(코드)가 같아도, 어떤 재료(데이터)를 쓰고 셰프가 어떠한 비법을 추가하고, 조리(학습)를 어떻게 하느냐에 따라 요리의 맛은 천지 차이입니다. 김치찌개가 다 같은 김치찌개인가요? ㅋㅋㅋ
Llama 아키텍처 코드를 그대로 사용했더라도, 한국 기업이 한국의 역사, 법률, 문화 데이터를 큐레이션하여 처음부터(From Scratch) 학습시켰다면, 그 결과물은 미국 모델과는 뇌의 기본 구조(Topology)만 같을 뿐 사고체계와 가치관이 완전히 다른 ‘한국형 인격체’가 탄생한 것입니다,
그게 바로 글로벌 스탠다드로 얘기하고 있는 주권 AI, 소버린AI의 데피니션입니다.
젠슨황은 이렇게 정의합니다.
“Sovereign AI is about a nation owning its own data, on its own infrastructure, to create its own national interlligence”
여기에 하나 제가 추가하자면, 가장 중요한 것은 “통제가능성” 입니다.
이것을 두고 “코드가 같으니 베낀 것”이라고 하는 것은, “한국인과 미국인은 DNA 구조가 99.9% 일치하니 같은 사람이다”라고 주장하는 것과 같은 논리적 비약입니다.
- 현장의 진실: 오픈소스 활용은 일종의 Spectrum
그렇다면 왜 <참조>와 <복제>의 경계가 논란이 될까요? 많은 이들이 소프트웨어 개발을 직접 전부 짰거나(100% 창작), 베꼈거나(100% 복제)라는 이분법으로 바라보지만, 현장의 개발자들이 마주하는 OSS의 현실은 0과 1이 아닌, 넓은 스펙트럼 위에 존재합니다.
1) 명확한 양극단과 그레이존
양극단(White & Black) : 완전히 새로 짠 코드(창조)와, 토씨 하나 안 바꾼 코드(복제)는 구분하기 쉽죠. 문제는 회색지대(The Grey Zone), 그 사이의 광활한 영역입니다.
기존 코드의 전체 구조(Class structure)는 유지하되, 내부 연산 로직(Method logic)을 50% 이상 수정했거나, 아이디어와 구조를 참조하되 나름 새로짠 코드(자기는 새로 다 짰다고 믿는), 성능 최적화를 위해 특정 라이브러리의 핵심 함수 몇 개만 차용하여 코드에 이식한 경우, 변수명과 주석을 다 바꾸고 불필요한 기능을 제거하여, 원본과는 모양새가 완전히 달라졌다고 생각하는 경우….
이 지점에서 엔지니어는 딜레마에 빠집니다.
“이것은 참조인가, 아니면 복제인가?”
(이 비슷한 광고가 있었는데, 생각이 안납니다…..ㅋ)
2) 보수적 의사결정이 필요하긴 하다.
자, 개발자는 법률가가 아닙니다. 사실, 명확한 선이 보이지 않을 때, 실무에서는 보통 “애매하면 라이선스를 표기하자. 괜히 나중에 문제 되는 것보다 낫다”는 보수적인 결정을 내립니다.
최근 논란이 된 업스테이지 사례도 이 맥락에서 이해해야 합니다. 코드를 복제한 것이 아니라, 원형이 일부 남아있는 코드를 두고, OSS 위반 시비를 원천 차단하기 위해 스스로에게 엄격한 기준을 적용해 라이선스를 표기한 것에 가깝다고 봅니다. 갑자기 지적이 되니까, “내가 베꼈소”라는 자백이 아니라, “애매한 경계에서 욕먹기보다는 안전한 컴플라이언스 전략을 택하겠소”라는 실무적 판단입니다.
또는! 기존에는 참조로 생각했지만, 논란이 있으니 깔끔하게 라이선스 표기 추가하자. 는 겁니다,
이를 두고 도덕적 해이로 몰아가는 것은 좀 말도안되는 해석이라고 봅니다.
- 라이선스 정정의 진실
이번 논란의 또 다른 핵심 질문은 또 있죠.
“처음에 라이선스 표기를 안 했다가, 지적받고 나중에 수정한 것은 ‘도둑질하다 들킨 것’ 아닌가?”
답은 뭐 명확합니다. 관리의 미흡함 정도는 될 지언정, 문제가 될만한 법적, 기술적 소지는 없습니다.
1) 오픈소스 생태계의 흔한 일상
오픈소스 세계에서 [코드 공개 → 커뮤니티의 지적(NOTICE 누락 등) → 즉시 수정 커밋]은 너무나 흔한 일상입니다. 구글, 메타, 파이토치(PyTorch) 생태계에서도 수시로 일어나는 일이죠. 아무도 이를 두고 “구글이 도둑질을 했다가 들켰다”고 하지 않습니다. 위반이 아니라 커뮤니티와 함께 완성해가는 정정(Correction) 과정입니다. 앞에서 말씀드린 것처럼, 이 경계가 그레이존이니까요.
2) Apache 2.0의 설계 철학
모두가 사용하는 아파치 2.0 라이선스는 GPL처럼 “한 번 어기면 끝”인 징벌적 라이선스가 아닙니다,
GPL은 리처드 스톨만이 만든 라이선스로, 핵심 철학은 Copyleft입니다. Copyright을 없애자는 게 아니라, 저작권을 이용해 일종의 자유를 강제하는 방식이죠.
GPL이 보장하는 자유는 네 가지입니다.
- 누구나 프로그램을 실행할 자유
- 소스코드를 볼 자유
- 수정할 자유
- 수정한 버전을 배포할 자유
하지만 조건이 하나 붙습니다. GPL 코드를 사용해 만든 결과물도 반드시 GPL로 공개해야 한다는 점입니다.
그래서 중요한 특징이 나옵니다. GPL 코드를 그대로 쓰든, 수정해서 쓰든, 내 코드와 섞어서 하나의 프로그램으로 배포하면, 전체를 GPL로 공개해야 합니다.
이게 흔히 말하는 강한 카피레프트입니다. 기업들이 GPL을 특히 조심하는 이유도 여기 있습니다.
리눅스 커널이 GPL 이죠, GPL은 어기면 혼납니다. ㅋ
이에 비해서, 아파치 2.0은 개발 과정의 실수와 복잡성을 인정하고, 사후 수정과 보완을 허용하는현실적이고 유연한 라이선스입니다! 그러니까, 사후 수정 및 보완이 다 된다는 말입니다. 나중에 고쳤다고 문제가 아니라는 겁니다.
3) 그런데 왜 이번만 과도하게 공격받나?
유독 이번 사안이 비화되고, 여전히 계속 정리가 안되고, 코투리가 잡혀가는건, 기술적 문제가 아니라. 국가 과제 + From Scratch 라는 점, 그리고 반중 정서가 겹치면서 통상적인 문제들이 계속 의혹의 증거로 과잉 해석되는 것입니다.
핵심만 말하자면, 지적 후 라이선스를 수정했다는 사실은 관리에 있어 미흡함을 얘기할 수는 있어도, 이를 근거로 모델 도용이나 기술적 독립성 부재를 얘기하는 건 옳지 않다는 말입니다.
- 전략적 선택: 왜 구조(Topology)를 바꾸지 않는가?
자, 그러면, 또 이런 얘기를 합니다.
“야!! 국민 세금 들어서 독자 기술이라면 아키텍처 구조도 뜯어고쳐야 진짜 기술 아니냐?”
그런데,토폴로지 재설계와 호환성의 딜레마를 이해해야 합니다.
1) 나 홀로 아키텍처의 고립
독자성을 증명하겠답시고 구조를 특이하게 바꾸면 어떻게 될까? 그 모델을 돌리기 위한 전용 구동기(Inference Server), 전용 툴을 기업이 직접 다 만들어야 합니다. 엄청난 리소스 낭비이자, 외부 개발자들이 사용하기 꺼리게 만드는 진입 장벽이 됩니다.
2) 생태계 호환성(Compatibility)도 중요한 경쟁력
Llama나 Qwen과 같은 표준 아키텍처를 유지하는 것은 기술이 없어서라기 보다는 호환성 때문인 경우가 많습니다. 돈이 많고, 자원이 많고, 시간이 많다면 이거저거 시도를 해보면서, 논문도 내고 혁신을 주장할 수 있겠지만, 우리의 현실, GPU도 이제 26만장 확보한 현실에서 맞을까요?
표준 구조를 따르면 전 세계 개발자들이 만든 vLLM, ollama, LangChain 등의 도구를 즉시 사용할 수 있습니다. 그래서, 표준 아키텍처의 장점인 호환성은 흡수하되, 내부 효율이나 데이터 처리 방식에서 차별화를 두는 전략이 어쩌면 가장 필요한 현실적인 소버린 전략입니다. 무조건 다 뜯어버리겠다! 고 하는 것만 혁신이 아니라 잘 쓰는 것이 혁신입니다. -> 제가 주장하는 소버린AI 등급체계에서 명확하게 T4부터 소버린인 이유가 이렇습니다.
물론, 구조도 바꾸는 토폴로지 재설계도 필요합니다. 새로운 시대에 앞서나가기 위한 전략도 같이 가야죠. 기존 아키텍쳐로 해결할 수 없는 문제를 돌파하기 위한 의미있는 재설계는 필요합니다. 하지만, 단순히 보여주기 식의 토폴로지 재설계보다는 표준 구조 활용하는 전략이 효율적일수 있다는 지적입니다. 그러니까. 투트랙으로 가야합니다.
모든 기업이 바퀴를 다시 발명할 필요는 없기에, 글로벌 표준 아키텍처를 영리하게 개량하여 현장에 보급하는 산업의 허리(T4-2) 기업들을 적극 육성하여 AI 네이티브 전환의 속도를 높여야 합니다. 동시에, 글로벌 빅테크와의 레버지리를 확보하고 안보적 타협이 불가능한 핵심 인프라를 수호하기 위해, 설계도부터 독자 구축하는 국가의 방패(T5/T6) 원천 기술에 대한 전폭적인 지원도 병행되어야 하겠죠. 이런 투트랙전략을 가져가야 합니다.
- 그런데, 중국 저작권 코드 참조하면 중국산인가?
“중국 알리바바의 코드를 참조했으니 중국 기술에 종속된 것 아니냐”, “보안이 위험한 것 아니냐”는 우려 역시 오픈소스 생태계의 흐름을 전혀 이해하지 못한 낡은 이념적 프레임입니다,
1) 기술의 흐름과 선순환
중국 모델들 역시 미국의 LLaMA, 구글의 Transformer 등 글로벌 OSS를 참조해 고도화되어 왔습니다. 우리가 중국의 코드를 활용하는 것은, 글로벌 OSS → 중국의 대규모 최적화 → 우리의 재검증·재활용으로 이어지는 기술 축적의 흐름을 활용하는 것입니다. 중국이 수천억원의 막대한 비용을 들여 성능과 안정성을 끌어올린 결과를 우리가 통제·검증 가능한 형태로 활용한다면, 종속이 아니라 효율적인 도구 선택이 될 수 있습니다.
2) 국적보다 라이선스, 그리고 투명성
중요한 것은 저작권자의 국적이 아니라 그들이 허용한 라이선스(License)입니다. 우리는 허용된 권리 안에서 가장 좋은 도구를 선택하면 됩니다. 오픈소스는 코드가 투명하게 공개되어 있어 백도어 심기가 불가능에 가깝습니다. 오히려 내부를 알 수 없는 폐쇄형 모델보다, 우리가 코드를 뜯어보고 검증할 수 있는 오픈소스 기반 모델이 소버린 안보 관점에서 더 안전할 수 있죠
코드에 중국인 저자의 이름이 있거나 저작권자가 중국 기업이라는 이유로 ‘중국산 AI’라는 딱지를 붙이곤 하는데요…현재 글로벌 표준인 허깅페이스(Hugging Face) 라이브러리는 국적을 불문한 전 세계 엔지니어들의 공동 기여로 이루어진 ‘기술 공용어’의 장이며, 이곳에 아파치 2.0(Apache 2.0) 라이선스로 공개된 코드는 그 저작자가 누구든 상관없이 전 인류가 자유롭게 활용할 수 있는 ‘공용 자산’이 됩니다.
즉, 중국이든 미국이든 아파치 라이선스로 코드를 공개한 순간, 그 기술은 전 인류의 공용 자산이 되는겁니다. 우리가 영어를 사용한다고 해서 영국에 종속되었다고 하지 않듯, 허깅스페이스 라이브러리 쓴다고 프랑스꺼 쓰는게 아니듯, 글로벌 표준 라이브러리를 활용하는 것은 합리적 선택입니다.
우리가 윈도우(Windows)를 쓰면서 마이크로소프트에 종속되는 것과 달리, 아파치 라이선스 코드를 가져와 우리만의 모델을 만드는 것은 우리가 기술의 배타적 사용권과 통제권을 갖는 구조라는 말입니다.
자 이제 결론을 내면,
복제(Cloning)와 참조(Reference)를 명확히 구분해야 합니다,
복제는 이해 없이 껍데기만 베끼는 행위로 당연히 비난받아야 합니다.
반면, 참조는 검증된 아키텍처(거인의 어깨) 위에서, 우리만의 데이터와 Alignment로 독자적인 지능을 구축하는 행위로 당연히 장려되어야 하고, 소버린AI의 출발점입니다.
소버린 AI는 무조건 모든 부품을 국산으로 만든 순혈 AI가 아닙니다. 가장 중요한 소버린의 핵심은 통제권(Control)입니다. 미국이든 중국이든, 외부의 우수한 코드를 일부 또는 전부 가져오더라도 그 안에 담기는 데이터, 가중치 와 운영의 통제권을 우리가 쥐고 있다면, 그게 바로 가장 강력하고 효율적인 소버린 AI입니다.
그래서,
부디, 글로벌 생태계의 회색지대에서 고군분투하는 엔지니어들의 의사결정을 ‘양심 고백’이나 ‘사기’로 오독하지 말았으면 좋겠습니다. 진짜, 그러다가 벼룩을 잡으려다 초가삼간을 태웁니다
AI 기업들도, 오픈소스 생태계의 혜택을 누리는 데 그쳐선 안됩니다. 라이선스 고지는 더욱 보수적으로 하고, 더 나아가, 우리가 수정한 것, 그리고 우리가 새롭게 만든 것들도 아파치(Apache) 등으로 과감하게 오픈해서 남들이 더 많이 활용하도록 해야 합니다. 그래야만 비로소 우리가 생태계의 진정한 일원이 되고, 글로벌 기술 주도권(Leadership)을 가져올 수 있습니다. 받는 것(Take)을 넘어 주는 것(Give)이 있어야 리더가 됩니다.
