“사무장님, 혹시 개발자 출신이세요?”

특허 명세서를 작성하다 보면 가끔 발명자(개발자)분들에게 이런 질문을 받곤 합니다. 반대로 요즘 AI를 통해 코딩을 배우면서 저는 모니터 속 소스 코드를 보며 혼자 중얼거립니다.

“이거… 특허 청구항(Claim) 쓰는 거랑 똑같잖아?”

20년 동안 특허 밥을 먹어온 저에게, 코딩은 전혀 낯선 외국어가 아니었습니다. 오히려 ‘사용하는 언어만 다를 뿐, 본질은 완벽하게 같은 쌍둥이’처럼 느껴졌죠.

오늘 그 흥미로운 평행이론에 대해 이야기해 보려 합니다.

1. 정의(Definition)의 미학: 변수 선언 vs 구성요소 정의

• 코딩: const userAge = 30;
  • 변수의 이름을 정하고, 그 안에 담길 데이터의 타입과 값을 정의합니다.
• 특허: 【청구항 1】 ... 디스플레이부; 및 상기 디스플레이부를 제어하는 제어부;를 포함하고...
  • 발명을 구성하는 핵심 요소(변수)를 명확하게 정의합니다.

둘 다 ‘모호함’을 가장 싫어합니다. 컴퓨터가 이해하지 못하는 변수는 에러를 뿜어내듯, 심사관이 이해하지 못하는 구성요소는 거절 이유가 됩니다.

2. 예외 처리(Exception Handling) vs 방어적 청구항

개발자는 코드를 짤 때 항상 ‘최악의 상황’을 가정합니다.

• “만약 사용자가 숫자가 아니라 문자를 입력하면?” (try-catch 문)

특허 전문가도 마찬가지입니다. 경쟁사가 우리 특허를 요리조리 피해서 베끼려고 할 때를 대비합니다.

• “경쟁사가 A 부품 대신 B 부품을 쓰면?” (종속항으로 다양한 실시예 방어)

버그를 잡는 것과 특허 침해 회피를 막는 것. 둘 다 빈틈없는 논리적 방어막을 구축하는 치열한 두뇌 싸움입니다.

3. 리팩토링(Refactoring) vs 보정(Amendment)

• 코드 리팩토링: 기능은 그대로 두면서, 코드를 더 깔끔하고 효율적으로 다듬는 작업.
• 특허 보정: 발명의 핵심은 유지하면서, 명세서의 문장을 더 명확하고 권리 범위를 적절하게 다듬는 작업.

처음부터 완벽한 코드는 없고, 처음부터 완벽한 명세서도 없습니다. 끊임없이 수정하고 다듬어서 최적의 결과물을 만들어내는 과정. 이것이 우리가 밤을 새우는 이유 아닐까요?

에필로그: 융합의 시대, 두 언어를 말하다

특허라는 ‘법적 논리의 언어’와 코딩이라는 ‘기계적 논리의 언어’. 이 두 가지를 모두 구사할 수 있다는 건, 디지털 아키텍처 시대에 꽤 강력한 무기가 되는 것 같습니다.

저는 이제 특허를 설계하듯 코드를 짜고, 코드를 짜듯 특허를 씁니다. 이 블로그는 그 두 세계가 만나는 접점이자, 저의 새로운 실험실입니다.

혹시 여러분의 업무에서도 코딩과의 의외의 공통점을 발견한 적이 있으신가요?