특허 스토리

소프트웨어특허 VS 저작권, 개발자가 헷갈리는 이유{feat. 권리 보호 전략}

윤변리사 2026. 6. 15. 17:04

솔직히 말씀드리면, 소프트웨어특허출원은 변리사 중에서도 제대로 하는 사람이 많지 않습니다.


19년 동안 이 일을 해오면서 느낀 건데, 특허라는 게 기계 구조물이나 화학 성분처럼 눈에 보이는 것일수록 쓰기가 쉽습니다. 그런데 소프트웨어는 달라요. 코드가 있고, 알고리즘이 있고, 시스템이 있는데 정작 그걸 특허 명세서로 옮기는 순간 어디서부터 어디까지가 '발명'인지 경계가 흐릿해집니다.


최근 상담한 고객 중에 이런 분이 있었습니다. 스타트업 대표님인데, 이미 다른 사무소에서 소프트웨어특허를 한 건 진행했다고 하시더군요. 그런데 막상 등록이 됐는데도 뭔가 찜찜하다고 하셨어요. 청구항을 보니 이유가 바로 보였습니다. 권리 범위가 너무 좁게 잡혀 있었거든요. 경쟁사가 조금만 우회하면 그냥 통과할 수 있는 수준이었습니다. 등록은 됐지만, 사실상 아무것도 보호받지 못하는 특허였던 거죠.


소프트웨어특허, 왜 어려운가


특허청은 소프트웨어 발명에 대해 꽤 까다롭게 심사합니다.


단순한 아이디어나 추상적인 개념은 특허가 되지 않습니다. "사용자가 버튼을 누르면 화면이 바뀐다" 수준의 기술은 특허 대상이 아니에요. 특허청에서 요구하는 건 구체적인 기술적 수단입니다. 하드웨어와의 연계, 데이터 처리 방식의 구체성, 시스템 구성의 명확성, 이런 것들이 명세서 안에 녹아 있어야 합니다.


여기서 변리사의 역량 차이가 극명하게 갈립니다. 발명자가 설명해 준 내용을 그냥 받아 적는 수준의 명세서와, 발명의 핵심을 파악하고 거절 가능성을 미리 차단하면서 권리 범위를 최대한 넓게 설계한 명세서는 완전히 다른 결과물입니다.


저는 하루 평균 20건의 상담을 직접 진행하고, 월 100건 이상의 출원을 관리합니다. 그중 소프트웨어·IT 계열 비중이 상당한데요. 경험이 쌓이다 보니 이제는 상담 초반에 어느 부분에서 거절이 나올지가 거의 보입니다.


특허청이 거절하는 패턴, 딱 두 가지입니다


소프트웨어특허출원이 거절되는 이유는 대부분 두 가지 중 하나입니다.


첫째, 기술적 특징이 없다는 거절. 이건 발명의 구체성이 부족할 때 나옵니다. "AI를 이용해서 추천한다"는 식의 기재는 특허청에서 기술적 수단이 특정되지 않았다고 봅니다. 어떤 방식으로 데이터를 수집하고, 어떤 알고리즘으로 처리하고, 그 결과를 어떻게 출력하는지까지 구체적으로 적어야 합니다.


둘째, 선행기술과 유사하다는 거절. 2000년대 초 IT 버블 이후 소프트웨어 관련 특허 출원이 폭발적으로 늘었습니다. 선행기술 데이터베이스가 엄청나게 두꺼워져 있어요. 비슷해 보이는 기술이 이미 등록돼 있을 가능성이 높습니다. 그래서 출원 전에 선행기술 조사를 제대로 하고, 차별점을 명확하게 잡아내는 작업이 반드시 선행돼야 합니다.


이 두 가지 거절을 미리 막는 것. 그게 소프트웨어 분야 경험이 많은 변리사를 써야 하는 이유입니다.


단순한 대리를 찾는 분이 아닌, 장기적인 윈윈 관계를 원하는 분들을 전 좋아합니다.





셀프 출원, 한 번만 생각해 보십시오


요즘 특허청 홈페이지에서 직접 출원하는 분들이 늘었습니다. 비용을 아끼고 싶은 마음, 충분히 이해합니다.


그런데 소프트웨어특허만큼은 셀프 출원이 정말 위험합니다. 이유가 있습니다. 소프트웨어 발명은 명세서를 어떻게 쓰느냐에 따라 권리 범위가 하늘과 땅 차이로 벌어집니다. 기계 특허는 구조가 눈에 보이니까 어느 정도 쓸 수 있어요. 소프트웨어는 그렇지 않습니다. 잘못 쓰면 등록은 됐는데 아무 쓸모없는 특허가 되는 거예요.


저에게 오시는 분들 중에 이런 케이스가 꽤 있습니다. 셀프로 출원했다가 거절이유 통지를 받고, 그제서야 저를 찾아오시는 거죠. 눈물을 흘리며, 그때서야 변리사를 찾아갈 뿐이죠. 이미 출원일이 확정돼 있고, 잘못 설계된 청구항은 수정에 한계가 있습니다. 처음부터 다시 시작해야 하는 경우도 많아요. 아낀 돈보다 훨씬 큰 피해가 생기는 겁니다.


소프트웨어특허, 이런 경우에 꼭 받으십시오


"우리 서비스가 특허가 될 수 있나요?"라는 질문을 정말 자주 받습니다.


제 답은 항상 같습니다. 일단 검토해 보자고요. 소프트웨어특허는 아이디어의 독창성보다 기술적 구현 방식의 구체성이 더 중요합니다. 아이디어가 평범해 보여도, 구현 방식을 잘 파고들면 특허가 나오는 경우가 많습니다. 반대로, 아이디어가 아무리 기발해도 명세서에 구체성이 없으면 등록이 안 됩니다.


특히 아래 상황에 해당하신다면 소프트웨어특허를 진지하게 고민해 보셔야 합니다.


  • 경쟁사가 유사한 서비스를 준비 중이거나 이미 출시했을 때
  • 투자 유치나 정부 지원사업을 앞두고 있을 때
  • 플랫폼이나 앱의 핵심 알고리즘이 서비스 경쟁력의 근간일 때

특허는 출원일 기준으로 권리가 발생합니다. 오늘 출원한 것과 6개월 뒤 출원한 것은 완전히 다른 결과를 낳을 수 있습니다. 미루지 마십시오.


변리사를 고를 때 꼭 확인하십시오


소프트웨어특허는 담당 변리사의 전공과 경험이 결과를 좌우합니다.


전기전자공학이나 컴퓨터공학 출신 변리사가 이 분야를 주력으로 하는 경우가 많습니다. 상담할 때 담당 변리사의 전공을 물어보는 것, 전혀 이상한 게 아닙니다. 당연히 확인하셔야 합니다. 기계공학 전공 변리사가 소프트웨어 명세서를 쓰는 것과, 컴퓨터공학 전공 변리사가 쓰는 것은 차원이 다릅니다.


저는 관련 분야에서 수백 건의 소프트웨어·BM특허를 직접 처리했고, 등록률은 90% 이상을 유지하고 있습니다. 숫자가 전부는 아니지만, 숫자는 거짓말을 하지 않습니다.


참, 한 가지 더. 상담할 때 변리사가 직접 상담하는지 확인하세요. 사무장이나 일반 직원이 상담하는 곳이 생각보다 많습니다. 소프트웨어특허처럼 기술 이해도가 필요한 분야는 첫 상담부터 변리사가 직접 들어야 합니다. 그래야 발명의 핵심이 제대로 파악됩니다.




인생 길다, 짧게 생각하지 말자는 게 제 철학인데요. 특허도 마찬가지입니다. 지금 당장 비용이 아깝다고 미루다가, 나중에 경쟁사에 치이거나 투자 유치 타이밍을 놓치는 경우를 너무 많이 봤습니다. 그때 가서 후회해도 이미 늦어요.


당장 상담이 필요하신 분들은 아래 알려 드리는 링크를 통해 연락 주셔도 좋습니다. 최선의 방법을 찾아 드리겠습니다.





감사합니다.