과거를 기억하지 못하는 자는 과거를 반복하도록 운명지어진다. 저는 이 문장을 그다지 좋아한 적이 없는데, 지금 AI를 둘러싸고 벌어지는 일, 즉 소프트웨어 프로젝트를 재구현하는 문제를 보면 이 생각이 얼마나 한계적인지 분명해집니다. 많은 사람들이 AI를 이용해 기존 프로젝트를 다시 쓰는 것이 공정한지 문제를 제기합니다. 하지만 그런 사람들 중 상당수는 이미 90년대에도 현장에 있었습니다. 80년대에 시작된 리처드 스톨먼(Richard Stallman)과 그의 추종자들이 GNU 프로젝트를 위해 UNIX 유저스페이스를 재구현하던 작업의 마지막 과정을 지켜본 사람들입니다. 지금은 AI를 이용한 재작성에 반대하는 바로 그 사람들이, 당시에는 GNU 프로젝트의 행보를 열렬히 응원했습니다. 제 관점에서는 정당하게 그랬던 것이고, 저 역시 응원했습니다.

스톨먼은 단순한 프로그래밍 천재가 아닙니다. 여러 학문을 넘나드는 넓은 시야를 가진 사람이며, 그중에서도 저작권의 미묘한 차이를 잘 꿰고 있었습니다. 그는 다른 프로그래머들에게 UNIX 유저스페이스를 특정한 방식으로 재구현해 달라고 요청했습니다. 원본과 비교했을 때 각 도구가 고유하고 뚜렷하게 구분되는 방식으로 말입니다. 더 빠르거나, 기능을 더 풍부하게 하거나, 스크립트로 다룰 수 있게 하는 식입니다. 이런 특성들은 두 가지 목표를 동시에 달성했습니다. GNU Hurd를 더 나은 시스템으로 만드는 것과, 소송에 대비한 보호막을 마련하는 것이었습니다. 만약 누군가 GNU 구현물이 아이디어와 동작을 베끼는 것을 넘어 — 이는 합법입니다 — “보호되는 표현”, 즉 소스 코드를 그대로 베낀 것이라고 주장한다면, 추가된 기능과 의도적으로 밀어붙인 설계 방향이 법관이 이해할 수 있는 반론이 되어 줄 것이기 때문입니다.

그는 또한 실제 구현 코드를 들여다보지 말고, 명세와 도구를 직접 실행해 확인한 실제 동작을 바탕으로 그 동작 자체를 재구현하라고 당부했습니다. 그럼에도 GNU 프로젝트에 참여한 많은 사람들이 UNIX 소스 코드를 접했거나 접근할 수 있었을 것이라고 추측하는 것은 타당합니다.

리누스가 UNIX를 재구현해 리눅스 커널을 만들었을 때는 상황이 한층 더 복잡했고, 한 겹의 간접성이 더해졌습니다. 그는 UNIX를 사용자 자격으로 접했을 뿐, UNIX 소스 코드 자체에는 접근하지 못한 것으로 보입니다. 반면 그는 Minix 소스 코드 — 마이크로커널을 사용한 UNIX 구현체 — 와 그 구현을 설명하는 책에 깊이 노출되어 있었습니다. 그런데 다시 거슬러 올라가면, 타넨바움(Tanenbaum)이 Minix를 만들 때 역시 UNIX 소스 코드에 깊이 노출된 상태였습니다. 그래서 SCO가 IBM 소송 과정에서 리눅스에 보호되는 표현이 포함되어 있다고 주장하기는 어려웠습니다. 그럼에도 리누스가 Minix를 영감의 원천으로 삼았을 때, 그는 UNIX 코드를 알고 만들어진 대상(Minix)에 매우 정통했을 뿐 아니라, 더 흥미롭게도 Minix의 라이선스는 제한적이었고 2000년이 되어서야 오픈소스가 되었습니다. 그럼에도 이런 구도에서조차 타넨바움은 유명한 논쟁에서 저작권 침해를 문제 삼지 않고 아키텍처를 비판했습니다. 따라서 타넨바움은 리누스가 Minix에 노출되었더라도 — 그리고 그 자신도 Minix를 만들 때 비슷한 과정을 거쳤음에도 — 재작성을 공정한 것으로 여겼다고 합리적으로 추정할 수 있습니다.

저작권법이 실제로 말하는 것

이 모든 것을 올바른 맥락에 두기 위해 저작권의 실제 경계를 조금 더 확대해 보겠습니다. 법은 “보호되는 표현”을 복제해서는 안 된다고 말합니다. 소프트웨어의 경우 보호되는 표현이란 코드 그 자체, 즉 동일한 구조와 변수, 함수, 특정 작업을 수행하는 정확한 메커니즘을 의미하며, 알려진 알고리즘은 예외입니다(표준 퀵소트나 이진 탐색은 매우 유사하게 구현해도 위반이 되지 않습니다). 문제는 프로그램의 비즈니스 로직이 원본 구현과 거의 한 줄 한 줄 일치할 때 발생합니다. 그 외의 경우, 코드가 붙여넣기나 다른 언어로의 기계적 번역, 혹은 조금 다르게 보이도록 꾸민 미관상의 수정 — 바로 법원이 가려내려 하는 악의적인 꼼수입니다 — 없이 유사한 일을 수행하지만 명확히 다른 코드로 작성되었다면 그 복제는 합법이며 원본 라이선스를 따를 필요가 없습니다. 이 글을 읽는 유능한 프로그래머라면 누구나 *재구현*이 무엇이며 어떤 모습인지 정확히 알고 있을 것이라 생각합니다. 불가피한 유사성은 있겠지만 코드가 복제되지 않았다는 점은 분명히 드러납니다. 법적 구조가 그렇다면 왜 사람들은 클린룸 구현을 신경 쓸까요? 현실은 이것이 소송에 대비한 최적화에 불과하다는 것입니다. 법원에서 이기기를 더 쉽게 만들 뿐이며, 원본 소스 코드에 노출되었다 하더라도 그 노출이 아이디어와 동작에 대한 지식을 얻는 데만 쓰였다면 괜찮습니다. 게다가 우리는 오늘날 리눅스와 GNU 유저스페이스, 그리고 비슷한 경로를 밟은 수많은 다른 오픈소스 프로젝트가 존재한다는 사실을 기쁘게 생각합니다. 규칙은 그 결과가 마음에 들 때나 들지 않을 때나 동일하게 적용되어야 한다고 믿습니다.

AI의 등장

어쨌든 재구현은 언제나 가능했습니다. 지금 달라진 점은 그것이 엄청나게 더 빠르고 저렴해졌다는 사실입니다. 과거에는 개발자를 고용하거나, 사업적 포부 때문이든 세상과 공유하고 싶은 열정 때문이든 스스로 재구현을 만들 만큼 열정적이어야 했습니다.

이제 코딩 에이전트를 실행해 두 가지 방식으로 진행할 수 있습니다. 구현물을 명세로 변환한 뒤, 새로운 세션에서 에이전트에게 재구현을 요청하는 것입니다. 이때 특정한 품질을 강제할 수도 있습니다. 예를 들어 더 빠르게 만들라거나, 구현을 믿을 수 없을 만큼 따라가기 쉽고 이해하기 쉽게 만들라거나 — 이는 다른 구현과 크게 달라진 결과물을 얻는 좋은 요령입니다. 많은 코드가 정반대의 목표를 위해 설계된 것처럼 보이기 때문입니다 — 혹은 더 모듈화하라거나, 원본 구현의 근본적인 한계를 해결하라는 식입니다. 이런 힌트들은 모두 원본 설계와 크게 달라지도록 만들기를 훨씬 쉽게 해줍니다. 이런 방식으로 사용된 LLM은 과거에 본 것을 그대로 복사해 내지 않습니다. 그럼에도 마지막에는 에이전트를 이용해 위반 사항이 있는지 꼼꼼히 확인하고, 만약 있다면 해당 부분을 새로운 코드로 교체할 수 있습니다.

겉으로는 덜 엄밀해 보이지만 현실에서는 매우 효과적일 수 있는 또 다른 접근법은, 소스 코드 자체를 제공하고 에이전트에게 완전히 새로운 방식으로 재구현하라고 요청하면서, 소스 코드를 명세이자 구현을 코드 자체로부터 최대한 멀어지도록 이끄는 자료로 활용하는 것입니다. 프런티어 LLM은 매우 능력이 뛰어나서, 무언가를 명시적으로 복제하지 않기 위해서라도 그것을 활용할 수 있으며, 서로 다른 구현 방식을 신중하게 시도합니다.

위와 같은 시도를 한 번이라도 해본 사람이라면 “무압축 복사”가 실제로는 환상임을 압니다. 에이전트는 매우 “유기적인” 방식으로 소프트웨어를 작성합니다. 실수를 저지르고, 나중에야 분명해지는 한계 때문에 설계를 여러 번 바꾸며, 작게 시작해 점진적으로 기능을 추가합니다. 그리고 이미 혼란스러운 이 과정에서 우리는 프롬프트와 힌트, 바람으로 에이전트의 작업을 끊임없이 이끌어 갑니다. 위안이 되지만 사실이 아닌 아이디어가 많습니다. “무압축 복사”도 그중 하나입니다. 그럼에도 이제 재작성 과정이 너무나 간단해졌고, 많은 사람들이 이 사실에 불편함을 느낍니다. 여기에는 더 근본적인 진실이 있습니다. 소프트웨어의 본질이 바뀌었다는 것입니다. 다른 라이선스 아래에서의 재구현은 그 본질이 영원히 변모한 한 사례에 불과합니다. 자동화된 프로그래밍의 개별적인 발현 하나하나와 싸우기보다는, 새로운 멘탈 모델을 만들고 적응하는 것이 더 낫다고 믿습니다.

법을 넘어서

조직된 사회는 법이 지켜질 때 번영한다고 믿습니다. 그러나 저는 규칙이 존재한다는 이유만으로 맹목적으로 따르지 않으며, 제 윤리에 비추어 문제를 제기합니다. 그것이 개인과 사회, 그리고 법 자체가 진화할 수 있게 하는 길이기 때문입니다. 우리는 스스로에게 물어야 합니다. 저작권법은 윤리적으로 올바른가? AI가 기존 과정에 제공하는 속도 향상이 그 과정 자체를 근본적으로 바꾸는가?

소프트웨어가 다른 대부분의 인간 분야보다 훨씬 빠르게 진화할 수 있었던 한 가지 이유는, 이 분야가 특허와 보호 장치에 덜 얽매여 있다는 점입니다(그리고 이는 다시 소프트웨어를 둘러싼 공유 문화 덕분일 가능성이 큽니다). 저작권법이 더 엄격했다면 오늘날 우리가 가진 것들을 갖지 못했을 가능성이 큽니다. 개인이나 기업의 이익 보호가 인류 문화 전반의 발전보다 더 중요한가요? 저는 그렇지 않다고 생각합니다. 게다가 저작권법은 모두에게 동일한 공통의 운동장입니다. 규칙은 누구에게나 같습니다. 더 나아가, 비교적 느슨한 접근에도 불구하고 소프트웨어는 여전히 돈을 벌기 가장 쉬운 분야 중 하나로 남아 있다는 점은 과장이 아닙니다. 재구현이 가능하다는 사실이 비즈니스 측면에 타격을 준 것처럼 보이지 않습니다. 아마 그 반대가 사실일 것입니다. 오픈소스 소프트웨어 스택 덕분에 가능해진 수많은 비즈니스를 생각해 보십시오(OSS가 대부분 복제물이라는 뜻은 아니지만, 분명 과거 시스템들의 많은 아이디어를 계승했습니다). AI 시대에도 이러한 근본적인 긴장은 여전히 유효하다고 믿습니다. 재구현은 저렴하게 만들 수 있지만, 이는 우리 모두를 위한 새로운 운동장이며, 아이디어나 엔지니어링, 기능 측면에서 새로운 무언가를 더하지 않고 단순히 자동화된 방식으로 무언가를 재구현하는 것만으로는 장기적으로 큰 가치를 갖기 어렵습니다. 중요한 것은 정확히 어떻게 무언가를 만드느냐입니다. 잘 설계되었는가, 쓰기에 흥미로운가, 지원이 되는가, 어느 정도 참신한가, 빠른가, 문서화가 잘 되어 있고 유용한가? 더욱이 이번에는 힘의 불균형이 올바른 방향으로 기울어져 있습니다. 대기업은 언제나 엄청난 돈을 쏟아 시스템을 복제하고, 사용자들에게 거부할 수 없는 방식 — 예를 들어 수년간 무료로 제공하다가 나중에 모델을 바꾸는 식 — 으로 제공하며, 자신들이 실제로 발명하지 않은 아이디어의 선두주자로 자리매김할 수 있었습니다. 이제 소규모 개인 그룹도 대기업의 소프트웨어 시스템을 상대로 같은 일을 할 수 있습니다. 합성 노동력이 많은 이들에게 더 저렴해진 지금, 아이디어로 경쟁할 수 있게 된 것입니다.

우리는 거인의 어깨 위에 서 있다

우리가 모두 내면화해야 할 또 다른 근본적인 생각이 있습니다. 소프트웨어는 점진적이고 연속적인 과정 속에서 만들어지고 진화하며, 각각의 새로운 혁신은 우리 이전에 누군가가 발명한 것 위에 세워집니다. 우리는 무언가를 만들고는 그것을 “소유”한다고 매우 빨리 믿어 버립니다. 우리가 정확히 작성한 코드에만 한정한다면 맞는 말입니다. 하지만 우리는 이미 이루어진 작업과 아이디어 위에 무언가를 쌓아 올립니다. 그리고 IT의 현재 발전이 아이디어와 동작은 저작권의 보호를 받지 않는다는 근본적인 패러다임 덕분이라는 점을 고려하면, 재구현이 공정한 과정임을 받아들여야 합니다. 참신함이 전혀 담겨 있지 않다면 어쩌면 게으른 노력일 수도 있습니다. 그럴 수도 있습니다. 하지만 그것은 공정하며 누구도 위반을 저지르지 않은 것입니다. 그럼에도 우리가 생태계의 좋은 시민이 되고 싶다면, 어떤 작업을 복제할 때 그것을 함께 발전시키고 새로운 무언가를 발명하려 노력해야 합니다. 더 작은 메모리 공간에 특화하거나, 특정 맥락에서 더 유용하게 만들거나, 버그를 줄이는 식으로 말입니다. 스톨먼 방식처럼 말입니다.

AI의 경우, 우리는 거의 집단적으로 기술이 소프트웨어와 인류에 대해 고립된 채로 좋거나 나쁘다고 생각하는 오류를 범하고 있습니다. AI는 오픈소스 소프트웨어 분야에서 많은 좋은 것들을 가능하게 할 수 있습니다. 많은 열정적인 개인들이 낮의 일이 싫어서 자신이 사랑하는 무언가를 만들고 싶어 오픈소스를 작성하거나, 경제적 이익을 넘어선 더 큰 무언가의 일부가 되고 싶어 오픈소스를 작성합니다. 많은 오픈소스 소프트웨어는 여가 시간에 작성되거나, 프로젝트에 할당된 인원에 심각한 제약을 받은 채 작성되거나, 더 나아가서는 개발 비용을 대는 회사가 부과하는 제한적인 조건 속에서 작성됩니다. 이제 코드가 날마다 아이디어보다 덜 중요해지고 있는 만큼, 오픈소스는 AI로 크게 가속될 수 있습니다. 주말에 할애된 네 시간은 올바른 손에서는 10배의 결실을 가져올 것입니다(AI 코딩이 모두를 위한 것이 아닌 것처럼, 훌륭한 코딩과 설계 역시 모두를 위한 것이 아닙니다). 예컨대 독점 바이너리 블롭을 자동으로 디스어셈블해 리눅스 장치 드라이버를 구현할 수도 있습니다. 혹은 간신히 유지되던 라이브러리가 보다 합리적인 시간 안에 충분히 다룰 수 있는 프로젝트로 탈바꿈할 수도 있습니다.

AI 이전에 우리는 소프트웨어의 상품화를 목격했습니다. 품질은 낮아지고 오직 돈에만 초점을 맞추며, 미니멀리즘과 자원에 대한 존중에는 전혀 신경 쓰지 않았습니다. 대부분 제대로 작동하지도 않는 부풀려진 덩어리뿐이었습니다. 하드웨어 성능은 높아질수록 부풀림은 더 심해지고 관심은 더 줄어들었습니다. 이미 상황은 매우 나쁘게 흘러가고 있었습니다. AI가 그것을 더 악화시킬 것이라는 보장은 전혀 없으며, 다른 소프트웨어 시스템을 재구현할 수 있는 능력은 우리 분야에 관심과 상식을 되돌려 줄지도 모르는 더 큰 그림의 일부입니다.