어플특허 완벽 가이드 — 앱 기능·아이디어 보호 방법 총정리

앱을 만들었거나 만들 계획이라면 한 번쯤 “이거 누가 따라 하면 어떡하지”라는 고민을 하게 됩니다. 그때 가장 먼저 떠오르는 단어가 ‘어플특허’입니다.

그런데 막상 상담을 받아 보면, 생각했던 것과 특허로 보호되는 대상이 다른 경우가 많습니다. 이 글에서 그 차이부터 비용·절차까지 실무 기준으로 정리합니다.

어플도 특허가 될까? 결론부터

결론부터 말하면, 앱(프로그램) 그 자체는 특허 대상이 아닙니다. 다만 앱이 수행하는 기능과 처리 방법을 ‘컴퓨터로 구현되는 발명(시스템·방법)’ 형태로 구성하면 특허로 보호받을 수 있습니다.

이유는 특허법이 정한 ‘발명’의 정의에 있습니다. 특허법은 발명을 ‘자연법칙을 이용한 기술적 사상의 창작으로서 고도한 것’으로 규정합니다(특허법 제2조제1호).

프로그램 코드 자체나 추상적인 아이디어, 데이터의 단순한 배열은 자연법칙을 이용한 것으로 보지 않아 발명에 해당하지 않습니다.

상담에서 가장 자주 보이는 오해도 여기에 있습니다. “내 앱을 특허 내고 싶다”고 오시지만, 실제로 보호받는 건 앱이 아니라 그 앱이 동작하는 구조와 처리 방법입니다.

예를 들어 “사용자 위치와 주변 데이터를 받아 특정 알고리즘으로 매칭해 결과를 제공하는 방법”처럼, 기능을 기술적 단계로 풀어내야 비로소 특허의 대상이 됩니다.

특허 vs 저작권 vs 디자인권 vs 상표권 — 내 앱은 무엇으로 보호할까

결론부터 말하면, 하나만 고르는 게 아니라 네 가지를 조합하는 것이 정석입니다. 앱은 기능, 코드, 화면, 이름이 각각 다른 권리로 보호되기 때문입니다.

핵심만 정리하면, 차별화된 기능은 특허, 작성한 코드는 저작권 등록, 독창적인 화면은 화상디자인, 이름과 아이콘은 상표로 나눠서 봐야 합니다.

조합이 필요한 이유는 권리마다 막아 주는 지점이 다르기 때문입니다. 기능만 특허로 지켜 두고 이름을 비워 두면, 그 틈으로 권리가 샙니다.

실제로 상표권은 사용 여부와 무관하게 먼저 출원한 사람이 권리를 갖는 구조라, 기능 특허는 잘 받아 두고 앱 이름은 출원하지 않아 제3자에게 명칭을 선점당하는 사례가 반복됩니다. 기능을 지키는 것만큼 이름을 선점하는 것도 중요합니다.

내 앱은 어디에 강점이 있는지에 따라 우선순위가 달라집니다. 간단한 기준은 이렇습니다.

• 남들이 따라 하기 어려운 기능·로직이 강점이면 → 특허를 우선
• 화면 구성·UI가 독창적이면 → 화상디자인을 우선
• 이름·브랜드가 핵심 자산이면 → 상표를 우선
• 출시가 임박했다면 → 공개 전에 특허, 출시와 함께 상표를 함께 준비

어떤 어플이 특허로 등록될까 — 등록 요건 3가지

결론부터 말하면, 신규성, 진보성, 산업상 이용 가능성 세 가지를 모두 충족해야 합니다. 그리고 이 셋을 가르는 실무적 핵심은 ‘서비스 설명’이 아니라 ‘기술적 효과’를 보여 줬는지에 있습니다.

심사관은 앱이 무슨 서비스를 하는지가 아니라, 어떤 기술적 구조로 문제를 해결하는지를 봅니다.

같은 기능이라도 “이런 화면을 제공한다”가 아니라 “서버와 단말이 어떤 데이터를 주고받아 어떤 처리를 거쳐 결과를 낸다”로 풀어내야 등록 가능성이 올라갑니다.

아이디어만으로 특허가 될까? (BM 특허)

가능합니다. 실제 구동하는 앱이 없어도, 기획 단계의 아이디어만으로 출원할 수 있습니다. 이를 비즈니스모델(BM) 특허라고 부르며, 소프트웨어 특허의 한 갈래입니다.

다만 조건이 있습니다. 특허청 심사기준에 따르면, 영업방법을 컴퓨터상에서 구현하면서 출원 당시의 통상적인 기술수준을 넘어선 기술을 이용했다고 인정될 때 특허가 가능합니다. 즉 ‘영업방법’ 자체가 아니라 그것을 구현하는 ‘기술’이 있어야 합니다.

그래서 “아이디어만 있는데 되겠냐”며 반신반의하시던 분도, 그 아이디어를 데이터 흐름과 처리 단계로 함께 설계하면 출원으로 이어지는 경우가 많습니다. 반대로 이 설계가 비어 있으면 좋은 아이디어라도 거절되기 쉽습니다.

어플특허가 거절되는 대표 사유

거절되는 출원에는 공통점이 있습니다. 바로 ‘추상적인 아이디어 수준에 머물러 있다’는 점입니다.

대표적인 거절 유형은 세 가지입니다.

• 자연법칙을 이용하지 않은 순수한 영업방법이나 인위적 약속에 그치는 경우
• 수학적 알고리즘이나 추상적 아이디어만 청구한 경우
• 기능은 설명했지만 이를 구현하는 구체적 기술 구성이 빠진 경우

참고로 미국의 Alice 판결(2014년) 이후 한국에서도 소프트웨어 발명의 추상성 판단이 한층 엄격해졌다는 점도 염두에 둘 필요가 있습니다.

한 가지 덧붙이면, 1차 거절이유를 받았다고 끝이 아닙니다. 청구항을 기술적 효과 중심으로 다시 다듬는 보정 과정을 거쳐 등록까지 가는 경우가 드물지 않습니다. 거절이유 통지는 협의의 출발점에 가깝습니다.

어플특허 출원 절차 — 5단계 한눈에

절차 자체는 일반 특허와 같습니다. 다음 다섯 단계로 진행됩니다.

1. 선행기술 조사 및 등록 가능성 검토 — 비슷한 기술이 이미 있는지 확인하고 출원 방향을 잡습니다.
2. 명세서·청구범위·도면·요약서 작성 — 발명의 내용과 권리범위를 문서로 구체화합니다. 앱은 데이터 흐름을 도면(플로우차트)으로 표현하는 것이 중요합니다.
3. 특허청 출원 — 작성한 서류를 지식재산처에 제출합니다.
4. 심사청구 및 거절이유 대응 — 심사관이 요건을 검토하고, 거절이유가 있으면 의견서·보정서로 대응합니다.
5. 등록결정 및 설정등록 — 거절이유가 없으면 등록결정이 내려지고, 등록료를 납부해 권리가 설정됩니다.

빠른 권리화가 필요하면 4번 단계에서 우선심사를 활용할 수 있습니다. 우선심사 대상에 해당하면 심사 착수가 크게 앞당겨집니다.

등록되면 특허권은 출원일로부터 20년간 존속합니다(특허법 제88조). 다만 권리를 유지하려면 매년 연차등록료를 납부해야 합니다.

어플특허 비용과 기간

비용은 크게 특허청에 내는 관납료와 대리인 수임료로 나뉩니다. 관납료는 「특허료 등의 징수규칙」에 정해져 있어 누구나 동일하게 적용됩니다.

관납료의 기본 구조는 출원료 → 심사청구료 → 설정등록료 → 연차등록료 순서이며, 2025년 기준으로 정리하면 다음과 같습니다.

대략적인 감을 위해 예를 들면, 청구항 5개 정도로 개인이 출원할 경우 출원부터 설정등록까지의 관납료 합계가 대체로 50만 원 안팎이 됩니다. 여기에 우선심사를 신청하면 특허 기준 약 20만 원의 신청료가 더해집니다.

다만 이 금액은 청구항 수와 규칙 개정 시점에 따라 달라지므로, 출원 직전에 특허청 수수료 안내와 「특허료 등의 징수규칙」 최신 기준을 확인하는 것이 안전합니다. 개인·중소기업·벤처기업은 일정 요건을 충족하면 관납료 감면을 받을 수 있습니다.

대리인 수임료는 발명의 난이도와 청구항 구성에 따라 출원 시·등록 시로 나뉘어 책정되며, 관납료와는 별도입니다.

그래서 앱 특허는 출원료보다 명세서 작성 단계에서 승부가 납니다. 데이터 흐름과 기술 구성을 얼마나 촘촘하게 설계했는지가 등록 여부와 권리 강도를 좌우하기 때문입니다.

기간은 일반 심사의 경우 출원에서 등록까지 통상 1~2년 이상 걸리는 편이지만, 우선심사를 활용하면 6개월 안팎까지 단축되기도 합니다.

등록 가능성을 높이는 명세서·청구항 작성 포인트

가장 중요한 원칙은 하나입니다. 서비스 설명이 아니라 기술적 효과로 쓰는 것입니다.

실무에서 등록률이 갈리는 지점은 거의 명세서에 있습니다. “이런 편리한 기능을 제공한다”는 마케팅 문장이 아니라, 서버와 클라이언트가 어떤 데이터를 주고받고, 어떤 모듈이 어떤 순서로 처리하며, 그 결과 어떤 기술적 효과가 생기는지를 단계별로 적어야 합니다.

특히 소프트웨어가 수행하는 처리 수순을 시간 순서대로 명확히 기재하고, 분석 모듈이나 서버–단말 간 데이터 처리 구조 같은 구성 요소를 도면으로 뒷받침하면 좋습니다.

청구항은 너무 좁게 쓰면 회피가 쉽고, 너무 넓게 쓰면 거절되기 쉬우므로 균형을 잡는 설계가 핵심입니다.

이 부분은 발명자 혼자 작성하기 가장 까다로운 영역입니다. 같은 아이디어라도 청구항 설계에 따라 등록 여부와 권리 강도가 완전히 달라집니다. 출원 전에 청구항 설계를 한 번 점검하면, 거절 후 보정으로 시간과 비용을 다시 쓰는 일을 줄일 수 있습니다.

자주 묻는 질문 (FAQ)

정리 — 내 앱에 맞는 IP 전략 한 장 요약

세 줄로 정리하면 이렇습니다. 첫째, 앱 자체가 아니라 앱의 기능·처리 방법이 특허 대상입니다. 둘째, 기능은 특허, 코드는 저작권, 화면은 디자인권, 이름은 상표로 나눠 조합해야 빈틈이 없습니다. 셋째, 등록의 성패는 아이디어가 아니라 그것을 기술적 효과로 풀어낸 명세서에 달려 있습니다.

타이밍도 전략의 일부입니다. 아이디어 단계에서는 BM 특허 출원을 검토하고, 개발 중에는 화면 디자인을, 출시 직전에는 상표를 함께 준비하면 단계마다 생기는 빈틈을 줄일 수 있습니다.