INPI에 소프트웨어를 등록한 경험 (솔로 개발자 시점)

1. 배경
   저는 솔로 개발자이자 디지털 전략가입니다. 기술, 자동화 및 인공지능(AI)을 결합한 프로젝트 생태계를 운영하고 있습니다. 이 중 하나의 프로젝트를 개발하는 과정에서, 제가 구축한 소프트웨어의 지적 재산권을 공식화하기 위해 INPI(브라질 국립산업재산권청)에 등록하기로 결정했습니다.

이 결정은 즉각적인 것이 아니었습니다. 시간과 조사, 그리고 몇 가지 시행착오를 거쳤습니다. 본 글은 이 과정을 낭만적으로 포장하거나 지루한 부분을 생략하지 않고 제가 배운 점을 기록합니다.

2. INPI에 소프트웨어를 등록하는 이유
   INPI에서 컴퓨터 프로그램(소프트웨어)을 등록하는 것은 특허가 아닙니다. 이것이 누군가가 비슷한 것을 만드는 것을 막는 것은 아닙니다. 그 기능은 다르지만, 마찬가지로 가치가 있습니다:
   • 법적 효력을 지닌 공식적인 창작일자 확립
   • 계약, 제안서 및 자금 조달 과정에서 추적 가능하고 인용 가능한 지적 자산 생성
   • 특히 솔로 운영자의 경우 기관의 신뢰도를 보여주는 닻 역할을 함
   • 입찰, 공고 및 투자 유치 과정에서 요구될 수 있음

CNPJ(사업자등록번호)가 확립되지 않았거나 뒤에 팀이 없는 상태로 혼자 활동하는 사람에게 있어, 이 등록은 시장이 인정하는 언어로 프로젝트의 진지함을 구현할 수 있는 몇 안 되는 방법 중 하나입니다.

3. 실제 과정
   등록은 e-INPI 플랫폼을 통해 진행됩니다. 이 과정은 디지털이며 변호사가 필요하지 않지만, 주의가 필요합니다. 주요 단계는 다음과 같습니다:
   • 계정 생성 및 위임 대리인 등록 (개인 신분일 경우 본인이 직접)
   • 제목, 기능 설명, 언어 및 실행 환경이 포함된 출원서 작성
   • 부분 또는 전체 소스 코드 제출 (비밀 유지 옵션 있음)
   • GRU(연방세 수납 안내서) 납부
   • 생성된 출원 번호를 통해 과정 추적

인증서 발급 기한은 다릅니다.

제 경우, 프로토콜은 수용되었고 합리적인 시간 내에 등록 번호가 생성되었습니다. 출원(depósito)을 시작하면 보호는 이미 그 날짜로 소급됩니다.

4. 결정에 가장 큰 영향을 미친 요소
   세 가지 요인이 결정적이었습니다:
   • 타이밍: 일찍 등록하는 것은 분쟁이나 파트너십 이전에 프로젝트의 초기 상태를 보호한다는 의미입니다.
   • 비용: 개인을 위한 GRU(납부서) 금액은 예상보다 훨씬 저렴하여 접근성이 좋습니다.
   • 1인 운영: 공동 창업자가 없기 때문에, 등록은 저작권자임을 명확하게 문서화합니다.

5. 거의 실수할 뻔했던 오류들
   재작업을 유발하고 공식 문서에서 명확히 설명하지 않는 몇 가지 사항들이 있습니다:
   • 기능 설명(descrição funcional)은 README가 아닙니다. 소프트웨어가 '무엇을 하는지'를 설명해야 하며, '어떻게 구축되었는지'를 설명하는 것이 아닙니다.
   • 제목은 구체적이고 기술적이어야 합니다. 상표명으로는 기능 설명을 대체할 수 없습니다.
   • 제출된 코드는 부분적일 수 있지만, 대표성을 갖추어야 합니다. 주석이나 의사 코드(pseudocódigo)만 보내면 출원이 훼손됩니다.
   • GRU는 유효 기간이 있습니다. 기한 내에 생성하고 납부하지 않으면 프로세스를 처음부터 다시 시작해야 합니다.

6. 등록을 통해 실질적으로 얻은 것
   단순히 법적 보호를 넘어, 이 등록 번호는 포트폴리오(bios), 발표, 제안서에서 일종의 자격 증명(credential) 역할을 하게 되었습니다. 이는 단순히 개발하는 사람과 자신이 개발한 것을 공식화하는 사람을 구분 짓는 요소입니다.
   기관 고객, 입찰 또는 기술적 가시성을 추구하는 사람에게 이 세부 사항은 생각보다 큰 영향을 미칩니다.

7. 결론 — 할 만할까? 누구에게? 언제?
   소프트웨어가 명확하고 차별화된 기능을 가지고 있으며, 이를 수익화하거나 협상에서 자산으로 사용하려는 경우라면 가치가 있습니다.
   프로젝트가 아이디어 구상 단계에 있거나, 확립된 기능이 없거나, 무엇을 등록하는지에 대해 아직 명확하지 않은 경우에는 가치가 없습니다.
   적절한 시기는 MVP(Minimum Viable Product)가 기능적으로 작동하고, 최소한 하나의 안정적인 버전이 문서화되어 있으며, 소프트웨어가 정확히 어떤 문제를 해결하는지 알고 있을 때입니다.

그 과정은 보이는 것보다 훨씬 간단합니다. 관료주의(bureaucracy)는 존재하지만, 헤쳐나갈 수 있습니다. 그리고 그 결과물은 남는 자산이 됩니다.

© Nauiter Master | AI Strategist, Digital Artist & Automation