"저 코딩 없이 말로만 앱 만들었어요."

요즘 이런 말, 낯설지 않으시죠?

바이브 코딩 시대입니다. 자연어로 말하면 AI가 프로그램을 만들어 주는 시대.

그런데 여기서 특허 변리사 입장에서 굉장히 중요한 질문이 생깁니다.

소스코드를 아무도 직접 안 짜는 시대에, 소프트웨어 지식재산권 전략은 어떻게 달라져야 할까요?

오늘 이 주제로 이야기해 보겠습니다.

안녕하세요, AI 읽어주는 변리사입니다.

오늘은 소프트웨어 IP 전략에 관심 있는 분들께 꼭 드리고 싶은 이야기입니다.

오늘 세 가지를 말씀드릴게요.

첫째, 바이브 코딩 시대에 소스코드 저작권이 왜 점점 의미를 잃는가.

둘째, 그렇다면 왜 특허, 특히 청구항이 더 강력한 무기가 되는가.

셋째, 앞으로 특허 청구항은 어떤 관점으로 작성해야 하는가.

PART 1. 바이브 코딩 시대, 소스코드 저작권의 한계

지금 시대를 한마디로 표현하면 이렇습니다.

"아무도 코드를 직접 타이핑하지 않는다."

Cursor, Claude, GPT. 자연어로 "이런 기능을 만들어줘" 하면 AI가 소스코드를 생성해 줍니다.

개발자는 점점 코드 자체보다 무엇을 만들지에 집중하게 되고, 소스코드는 그냥 AI가 뽑아낸 결과물이 됩니다.

그렇다면 소스코드 저작권 침해 주장은 어떻게 될까요?

저작권 침해를 주장하려면 원칙적으로 두 코드가 실질적으로 유사해야 합니다.

그런데 같은 기능을 구현하더라도, AI가 생성한 코드는 매번 다르게 나옵니다. 변수명도 다르고, 함수 구조도 다르고, 라이브러리 선택도 다릅니다.

경쟁사가 비슷한 제품을 만들어도 "소스코드가 다르다"는 반박 하나로 저작권 침해 주장은 무력화되기 쉬운 시대가 된 겁니다.

결론적으로, 바이브 코딩 시대에 소스코드 저작권은 점점 약한 무기가 됩니다.

이 점에 대해, 저작권 전문 미국 변호사인 [Jason Mueller]도 같은 관점을 이야기했습니다.

기존에는 코드의 선택, 배치, 창조적인 정제 등 저작물로 인정될 요소가 있었지만,

바이브 코딩 시대에는 저작권의 보호 대상이 아닌 아이디어를 프롬프트로 입력하고,

저작권의 보호 대상인 소스 코드 즉, expression은 입력하지 않습니다.

즉, 바이브 코딩에서는 저작권의 요건인 인간 저작원칙 human authorship을 충족하지 않고,

따라서 결과물인 코드는 저작권 보호의 요건인 독창성과 인간 저작권 요건을 충족하지 못할 수 있습니다.

PART 2. 그래서 특허가 더 중요해진다

그렇다면 어디로 가야 할까요?

특허입니다.

미국의 한 로펌에서도 특허가 바이브 코딩 시대에 소프트웨어를 강력하게 보호할 수 있는 수단이고, 저작권은 상대적으로 약하다고 분석하였습니다.
(출처-arapackelaw)

또한 이 로펌에서는 “무엇을"이 아닌 "어떻게"에 집중함으로써 소프트웨어 특허는 창의적 프로세스와 솔루션이 무단 복제로부터 보호되도록 하고,

경쟁사가 특허 기술을 우회하려면 상당한 장벽을 넘어야 한다는 점에서, 파트너십 체결·인수 협상 시 적극 활용된다고 설명하였습니다.

특허에서 핵심은 청구항이죠.

여기서 중요한 포인트가 있습니다.

특허 청구항은 소스코드를 적는 게 아닙니다.

청구항은 이 프로그램이 어떤 동작을 통해 어떤 결과를 만들어내는지, 그 기능적 단계를 기술합니다.

예를 들어볼게요.

바이브 코딩으로 프로그램을 만들 때 어떻게 합니까?

"이 앱은 사용자 입력을 받아서, A를 분석하고, B를 추천하고, C를 저장해야 해"라고 자연어로 설명하죠.

```
"이 앱은 사용자 입력을 받아서,
A를 분석하고,
B를 추천하고,
C를 저장해야 해"
```
라고 자연어로 설명하죠.

AI는 그 동작 명세를 보고 코드를 만들어 냅니다.

청구항도 똑같습니다.

*"사용자 입력을 수신하는 단계,
A를 분석하는 단계,
B를 추천하는 단계,
C를 저장하는 단계를 포함하는 방법."*

바이브 코딩으로 프로그램을 만드는 방식 자체가, 이미 청구항 작성 방식과 거의 같은 구조입니다.

이게 무슨 의미냐면— 바이브 코딩 시대일수록 특허 청구항이 오히려 침해 입증에 더 유리한 도구가 된다는 겁니다. 침해자들도 프로그램을 만들 때 소스코드를 직접 작성하는 것이 아니라, 바이브 코딩으로 전제 동작 과정을 만들 가능성이 크고, 바이브 코딩 과정이나 결과를 문서화하였을 가능성이 높기 때문입니다.

소스코드가 달라도, 프로그램 동작이 청구항의 각 단계를 그대로 수행하고 있다면 침해가 성립할 수 있습니다.

PART 3. 앞으로 청구항, 어떤 관점으로 써야 하나

자, 그렇다면 이제 실전 이야기입니다.

청구항을 작성할 때 앞으로는 이 질문을 해야 합니다.

"경쟁사가 이 제품을 베끼려 할 때, 바이브 코딩으로 어떻게 만들까?"

기존에는 이렇게 생각했습니다. "경쟁사가 소스코드를 어떻게 짤까?" 이제는 이렇게 생각해야 합니다.

"경쟁사 개발자가 AI한테 어떤 자연어로 프롬프트를 넣을까? 그 프롬프트 속에 어떤 동작들이 들어갈까?"

그 동작들을 청구항에 미리 포섭해 두는 것, 이게 앞으로 청구항 전략의 핵심입니다.

구체적으로 말씀드리면:

첫째, 기능 단계를 최대한 상위 개념으로 기술해야 합니다. 구현 방법이 달라져도 포섭될 수 있도록.

둘째, 바이브 코딩으로 유사 제품을 직접 만들어보세요. 어떤 프롬프트를 쓰게 되는지, 어떤 기능 단계들이 자연스럽게 나오는지를 파악해야 청구항에서 그 단계를 빠뜨리지 않습니다.

셋째, 경쟁사의 실시 형태를 예상해서 종속항이나 상세한 설명에 담아두세요. 핵심 청구항 하나로만 승부하는 시대는 지났습니다.

PART 4. 그렇다면 어떤 변리사를 선택해야 할까

클라이언트 입장에서 변리사를 고를 때, 이제는 이런 기준을 추가하셔도 좋을 것 같습니다.

코딩 경험, 그리고 나아가 바이브 코딩 경험이 있는 변리사.

왜냐면 청구항에서 경쟁사의 실시를 포섭하려면, 경쟁사가 실제로 어떻게 제품을 만들지를 알아야 하기 때문입니다.

그리고 지금 시대에 소프트웨어 제품을 만드는 방식은 바이브 코딩이거든요.

직접 AI에게 프롬프트를 넣어보고, 어떤 기능 단계들이 자연스럽게 도출되는지 경험해본 변리사와 그렇지 않은 변리사, 청구항의 포섭 범위가 달라질 수밖에 없습니다.

🔑 CONCLUSION

정리하면 이렇습니다.

바이브 코딩 시대에 소스코드 저작권은 점점 약해집니다.

반면 기능적 동작을 기술하는 특허 청구항은 오히려 강력해집니다.

그리고 청구항을 잘 쓰려면 이제 이 질문을 해야 합니다.

"내 경쟁사는 내 프로그램을 베껴서 바이브 코딩할 때 AI한테 뭐라고 프롬프트를 넣을까?"

"내 프로그램을 베낄 때 어떤 핵심 동작을 구현해 달라고 프롬프트를 작성할까?"

그 상상력이 청구항의 포섭 범위를 결정하는 시대가 됐습니다.

소프트웨어 특허나 바이브 코딩 관련해서 더 궁금한 점 있으시면 메일로 문의 남겨주세요.

감사합니다. AI 읽어주는 변리사였습니다.

velopatent@gmail.com