앱 개발자를 위한 특허·상표·저작권 체크리스트

앱 하나를 만들면 특허·상표·저작권·디자인권이 한데 얽혀 있습니다. 어떤 권리를 어떤 순서로 챙겨야 할까요? 개발자들은 기능과 코드에 집중하다 볼수록 브랜드명이나 화면 디자인 보호를 놓치기 쉽고, 출시 후 상표 충돌, 외주 개발자와의 저작권 분쟁, 핵심 기능의 신규성 상실 같은 문제는 앱 사업에 큰 타격을 줍니다. 이 글에서는 앱 개발자와 스타트업이 출시 전후로 반드시 점검해야 할 IP 체크리스트와 실전 전략을 정리했습니다. 출원 시기와 비용, 외주 계약서 작성 팁까지 실무에 바로 쓸 수 있는 내용입니다.

앱을 지키는 네 가지 권리의 지도

앱은 하나의 제품이지만, 보호되는 방식은 네 겹으로 나뉩니다. 이름과 로고는 상표로, 독창적인 기능과 알고리즘은 특허로, 소스코드와 문서는 저작권으로, 화면 구성과 아이콘은 디자인권으로 보호됩니다. 어느 하나만 챙겨서는 나머지 겹이 열린 채로 남습니다. 앱의 보이는 화면에서 코드까지, 각 겹이 무엇을 지키는지는 앱 하나를 지키는 IP 네 겹을 다룬 글에서 구조적으로 정리해 두었으니 함께 참고해 보세요.

권리	보호 대상	발생 방식	일반적 비용·기간
상표권	앱 이름, 로고, 슬로건	특허청 출원·등록	류당 수십만 원대, 10~14개월 내외
특허권	독창적 기능·알고리즘·처리 방법	특허청 출원·심사청구·등록	수백만 원대, 1년 반~3년 내외
저작권	소스코드, 문서, 기획서	창작 시 자동 발생(등록은 입증 장치)	수만 원대, 수 주 내외
디자인권	앱 아이콘, 화면 GUI	특허청 출원·등록	수십만 원대, 수개월~1년 내외

우선순위를 정하자면, 출시 전에는 이름(상표)과 핵심 기술(특허)의 '시기'를 지키는 것이 급합니다. 이 둘은 시기를 놓치면 돈으로 해결되지 않는 권리입니다. 저작권과 디자인권은 출시 전후로 순차적으로 정리핼 수 있으므로, 단계별 로드맵을 세워 접근하는 것이 현실적입니다.

앱 이름과 로고: 상표권

앱 이름은 9류(다운로드 가능한 소프트웨어·앱)가 핵심 상품류입니다. 여기에 서비스 성격에 따라 42류(SaaS·소프트웨어 개발), 35류(광고·중개), 그리고 업종 류를 조합합니다. 로고와 아이콘은 문자 상표와 분리해 도형 상표로 출원하는 것이 리뉴얼에 유연합니다.

앱 유형	핵심 상품류	추가 검토 류
금융·핀테크 앱	9류, 36류	35류, 42류
커머스·중개 앱	9류, 35류	39류(배송), 42류
교육·학습 앱	9류, 41류	35류, 42류
건강·운동 앱	9류, 44류	10류(기기), 42류
게임 앱	9류, 41류	28류(완구), 42류

이름을 확정하기 전에는 KIPRIS 상표 검색과 앱스토어 검색을 모두 해 보세요. 특허청 등록 상표와는 별개로, 앱스토어에 같은 이름의 앱이 이미 있다면 마케팅 채널에서 혼란이 생깁니다. 도메인과 SNS 계정까지 함께 확보해야 브랜드가 온전해집니다.

핵심 기능과 알고리즘: 특허권

앱의 독창적인 기능, 추천 알고리즘, 데이터 처리 방법은 특허로 보호할 수 있습니다. 다만 단순한 사업 아이디어 자체는 특허 대상이 아니고, 컴퓨터·스마트폰 같은 정보처리장치와 결합한 구체적인 기술적 방법으로 풀어내야 합니다. '무엇을 하는가'가 아니라 '어떻게 구현하는가'가 특허 명세서의 핵심입니다. 사업 아이디어와 특허의 경계는 비즈니스 모델 특허와 진보성의 벽을 다룬 글에서 더 자세히 확인할 수 있습니다.

특허 대상이 될 수 있는 기능의 예

• •특정 조건에서 UI를 자동으로 전환하는 화면 제어 방법
• •오프라인 상태에서의 충돌 방지 데이터 동기화 방법
• •사용자 행동 로그를 분석해 개인화 결과를 도출하는 방법
• •위치·시간·센서 값을 결합한 추천 시스템
• •생체 인증과 결합한 보안 인증 프로세스

사례 — 클라우드 메모 앱을 만든 H사는 여러 기기에서 동시에 편집해도 내용이 꼬이지 않는 충돌 방지 동기화 기술을 특허로 등록했습니다. 이후 대형 플랫폼이 유사 기능을 도입하려 하자 H사는 등록 특허를 근거로 라이선스 협상을 벌여 수익화에 성공했습니다. 핵심 기술이 곧 사업 모델인 앱일수록, 출시 전 특허 검토는 선택이 아니라 생존 전략입니다.

소스코드: 저작권 등록의 실익

소스코드는 프로그램 저작물로서 작성과 동시에 저작권이 발생합니다. 등록은 필수가 아니지만, 분쟁에서 창작 시기와 내용을 입증하는 공식 자료가 됩니다. 한국저작권위원회의 프로그램 저작권 등록은 수수료가 수만 원 수준이고 처리 기간도 수 주 내외라 부담이 적습니다. 정확한 수수료와 절차는 위원회 안내를 확인하세요.

등록이 특히 빛을 내는 장면은 세 가지입니다. 첫째, 외주 개발자가 산출물의 권리를 주장할 때 등록증이 기준이 됩니다. 둘째, 투자 유치 실사에서 기술 자산의 존재를 문서로 보여 줄 수 있습니다. 셋째, 코드 유출이나 무단 복제가 의심될 때 등록 시점 이후의 유사 코드에 대해 강하게 대응할 근거가 됩니다. 버전 관리 시스템의 커밋 기록과 함께 보관하면 입증력이 더 높아집니다.

화면과 아이콘: 디자인권(화상디자인)

앱의 화면 구성, 아이콘 배열, 인터랙션 비주얼은 화상디자인(GUI 디자인)으로 디자인권 등록이 가능합니다. 경쟁 앱이 화면 레이아웃을 통째로 모방할 때, 저작권만으로는 '표현의 실질적 유사성'을 입증하기 까다로운 경우가 있는데, 등록된 디자인권이 있으면 권리 범위가 도면으로 명확해 대응이 수월합니다.

모든 화면을 등록할 필요는 없습니다. 사용자가 앱을 떠올리는 대표 화면(온볼딩, 메인 대시보드, 차별화된 조작 화면)과 앱 아이콘을 우선순위로 정하세요. 출시 직후 UI가 자주 바뀌는 초기 앱이라면, 대표 화면이 안정화된 시점에 출원하는 것이 낭비를 줄이는 방법입니다.

출시 전 상표 검색과 앱스토어 충돌

앱스토어는 상표 분쟁이 자주 터지는 공간입니다. 애플과 구글은 상표권자의 신고를 받으면 해당 앱의 이름 변경을 요구하거나 앱을 내릴 수 있습니다. 반대로 말하면, 상표권을 확보한 쪽이 플랫폼 신고 절차를 통해 유사 앱 이름에 대응할 수 있다는 뜻이기도 합니다.

• ✔App Store·Google Play에서 동일·유사 이름 검색 — 발음이 비슷한 앱까지 확인합니다.
• ✔KIPRIS에서 선등록 상표 검색 — 9류와 업종 류를 중심으로 확인합니다.
• ✔도메인·SNS 계정 확보 — 이름 통일성을 확보합니다.
• ✔출시 전 상표 출원 — 최소한 출원 번호를 확보한 뒤 공개 일정을 잡습니다.

⚠️ 앱스토어 선점과 상표권은 다릅니다

앱스토어에 이름을 먼저 등록해도 상표권이 생기지는 않습니다. 상표권은 특허청 출원·등록으로만 확보됩니다. 스토어 이름 선점에 안심하다가 제삼자에게 상표를 먼저 등록당하면, 스토어에서 이름을 내려야 하는 상황이 올 수 있습니다.

특허 출원 시기: 공개의 함정

특허는 신규성이 생명입니다. 발명을 공개한 뒤에 출원하면 원칙적으로 등록이 불가능합니다. 앱 개발에서 '공개'는 생각보다 넓습니다. 오픈 베타 테스트, 테스터 모집 공고의 기능 설명, 데모데이 발표, 투자 유치 자료의 공개 배포, 기술 블로그 포스팅까지 모두 공개가 될 수 있습니다.

사례 — J사는 차별화된 추천 알고리즘을 개발했지만, 클로즈 베타라고 생각했던 테스트에서 초대장 없이도 가입이 가능한 상태로 몇 주간 운영했습니다. 이후 특허 출원을 검토했을 때는 이미 신규성 논란을 피하기 어려운 상태였고, J사는 핵심 기술 보호의 기회를 놓쳤습니다. 비밀유지계약(NDA) 없이 외부에 공개되는 모든 순간이 신규성을 갉아먹는다는 점을 기억하세요. 실무적으로는 '핵심 기술은 베타 전에 출원'을 원칙으로 삼는 것이 안전합니다.

외주 개발 계약서 가이드

개발 외주에서 분쟁의 8할은 '권리가 누구 것인가'에서 시작됩니다. 돈을 냈으니 결과물도 내 것이라고 생각하기 쉽지만, 계약으로 정하지 않으면 저작권은 만든 사람에게 남습니다. 다음 조항은 반드시 서면으로 확인하세요.

• •저작재산권의 양도 — 소스코드와 산출물의 저작재산권이 의뢰인에게 귀속된다는 문구
• •발명의 승계(직무발명 유사 조항) — 개발 과정에서 나온 발명의 특허를 받을 권리가 의뢰인에게 귀속된다는 문구
• •저작인격권 행사 범위 — 수정·업데이트에 대한 동의와 성명 표시 방식
• •오픈소스·제3자 소재 사용 목록과 라이선스 책임 — 어떤 외부 코드를 썼는지 명세를 받고 라이선스 위반 시 책임을 정합니다
• •비밀유지와 유지보수 범위 — 기술 자료의 취급, 출시 후 수정 권한과 비용
• •인도물 목록 — 소스코드 전체, 빌드 환경, 문서, 계정 정보까지 인도 범위를 명시

특히 프리랜서 개발자와의 구두 계약, 지인 소개 개발에서 사고가 잦습니다. 금액이 작아도 전자계약이라도 남기세요. 나중에 투자 유치 실사에서 '코드의 권리가 회사에 있다는 증빙'을 요구받을 때, 계약서가 없으면 기업 가치 평가가 직접 깎입니다.

오픈소스 라이선스 관리

오픈소스는 무료로 가져다 쓰는 코드가 아니라 '조건부 사용 허락'입니다. MIT·Apache처럼 고지 표시만 요구하는 관대한 라이선스가 있는가 하면, GPL 계열은 파생 저작물의 소스 공개 의무를 요구할 수 있습니다. GPL 코드를 상용 앱에 섞어 쓰면 앱 전체 소스를 공개해야 하는 최악의 시나리오도 가능합니다.

관리 방법은 단순합니다. 사용하는 라이브러리 목록을 SBOM(소프트웨어 자재 명세) 형태로 유지하고, 각 라이선스 종류를 표시해 두는 것입니다. 출시 전과 대규모 업데이트 전에 점검하는 절차를 배포 체크리스트에 넣어 두세요. 외주 개발이라면 계약서에 '사용한 오픈소스 목록과 라이선스 고지 의무'를 명시해 두는 것이 안전합니다.

출시 전 IP 체크리스트

• ✔앱 이름 상표 검색 및 출원(9류 중심)
• ✔로고·아이콘 도형 상표 및 디자인권 검토
• ✔핵심 기능의 특허 출원 검토(베타 공개 전)
• ✔소스코드 저작권 등록 및 커밋 기록 보관
• ✔외주 개발 계약서의 권리 귀속 조항 확인
• ✔오픈소스·에셋 라이선스 목록(SBOM) 정리
• ✔도메인·SNS 계정 확보 및 이름 통일
• ✔이용약관·개인정보처리방침 작성

업데이트와 IP 재검토

앱은 한 번 출시로 끝나지 않습니다. 새 기능, 새 화면, 새 캐릭터가 계속 추가되고, 그때마다 IP 보호 범위도 함께 커져야 합니다. 분기에 한 번은 다음 항목을 점검하는 IP 리뷰를 운영하세요.

• •이번 분기에 추가된 핵심 기능 중 특허 출원 후보가 있는가
• •UI 개편으로 등록 디자인과 실제 화면이 달라졌는가
• •신규 브랜드·서비스명이 생기지 않았는가(추가 상표 검토)
• •새로 들어온 오픈소스·폰트·에셋의 라이선스가 확인됐는가

특히 특허는 개량 발명이 쌓이는 영역입니다. 초기 출원 하나로 끝내지 말고, 버전이 올라가며 개선된 핵심 로직은 추가 출원으로 포트폴리오를 두텁게 만드는 전략이 경쟁사의 우회 설계를 막는 데 효과적입니다.

비용과 기간 가이드

네 가지 권리의 비용 구조는 성격이 다릅니다. 저작권 등록은 수만 원대로 가장 저렴하고, 상표는 류당 수십만 원대, 디자인은 수십만 원대, 특허는 명세서 작성 난이도에 따라 수백만 원대까지 갑니다. 기간도 저작권 수 주, 디자인 수개월~1년, 상표 10~14개월 내외, 특허 1년 반~3년 내외로 다양합니다. 정확한 관납료와 심사 현황은 특허청 안내에서 확인하시고, 특허 비용의 세부 구조는 특허출원 비용 총정리 글을 참고해 예산을 잡아 보세요.

초기 스타트업의 현실적인 예산 배분은 이렇습니다. 첫해에는 상표(이름 보호)와 저작권 등록(코드 입증)에 우선 배정하고, 핵심 기술이 검증되는 시점에 특허 1건을 목표로 잡는 식입니다. 모든 것을 한꺼번에 하려 하면 비용에 짓눌리고, 아무것도 하지 않으면 모방에 멀어집니다. 단계별 우선순위가 답입니다.

흔한 실수와 예방법

실수 1 — 앱스토어 등록 먼저, 상표 출원은 나중에

예방법: 이름을 공개하기 전에 상표 출원부터 마칩니다. 스토어 선점은 상표권을 대신하지 못합니다.

실수 2 — 베타 테스트 후 특허 검토

예방법: 오픈 베타·데모데이·기술 블로그 공개 전에 핵심 기술의 출원을 끝냅니다. NDA 없는 공개는 모두 신규성 리스크입니다.

실수 3 — 계약서 없는 외주 개발

예방법: 저작재산권 양도와 발명 승계 조항이 담긴 서면 계약이 최소한의 방어선입니다. 코드 인도 범위까지 명시하세요.

실수 4 — 오픈소스 라이선스 무시

예방법: GPL 계열 여부를 출시 전에 확인하고, SBOM으로 사용 라이브러리를 관리합니다.

투자 유치와 IP 포트폴리오

투자 심사에서 IP는 '있으면 가점, 없으면 감점'의 영역으로 자리 잡았습니다. 심사역이 확인하는 것은 세 가지입니다. 첫째, 핵심 기술이 특허나 영업비밀로 보호되고 있는가. 둘째, 코드와 콘텐츠의 권리가 회사에 온전히 귀속되어 있는가(외주 계약서·직무발명 규정). 셋째, 브랜드가 상표로 확보되어 있는가. 이 세 가지 중 하나라도 빠지면 기술력 평가는 그대로여도 기업 가치는 깎입니다.

실사를 앞두고 급하게 만드는 서류보다, 평소에 정리된 IP 대장이 훨씬 설득력이 있습니다. 출원·등록 현황, 계약서 목록, 오픈소스 관리 대장을 한 폴더에 유지해 두면, 실사 요청이 와도 하루 안에 제출할 수 있습니다.

앱 출시 전후로 챙겨야 할 IP 점검 타임라인

지식재산 점검은 한 번에 몰아서 하는 것보다 개발 단계에 맞춰 나눠 하는 편이 훨씬 효율적입니다. 기획 단계에서는 이름과 핵심 기능의 검색이 전부라 핵심 기능의 선행기술 조사와 앱 이름·서비스명의 상표 검색을 끝내 두는 것이 좋습니다. 이 시점의 검색 비용은 사실상 시간뿐인데, 이 단계에서 갈린 이름이 나중에 리브랜딩으로 이어지면 비용은 수십 배로 불어납니다.

개발 중반에는 외주·협업 계약서의 권리 귀속 조항을 다시 확인하고, 새로 추가된 핵심 알고리즘이나 UI 흐름이 있다면 특허 출원 후보로 메모해 두세요. 코드 저장소에 누가 어떤 코드를 기여했는지 기록이 남는 상태를 유지하는 것도 중요합니다. 분쟁이 생겼을 때 "누가 만들었는가"를 입증하는 가장 강력한 자료가 바로 커밋 기록과 계약서이기 때문입니다.

출시 직전에는 상표 출원을 마치고, 앱스토어 등록 정보에 회사명과 저작권 표기를 정확히 넣습니다. 출시 후에는 분기마다 한 번씩 유사 앱 이름과 앱스토어 모니터링을 하고, 기능 업데이트 때마다 새 특허 후보를 검토하는 루틴을 만드세요. IP 관리는 특별한 프로젝트가 아니라 제품 개발 주기에 스며든 습관일 때 가장 저렴하게 유지됩니다.

개발 계약서에 반드시 넣어야 할 권리 조항 3가지

저작권·특허권의 귀속 주체를 명확히

외주 개발 계약에서 가장 많이 싸우는 지점이 "만든 결과물이 누구 것인가"입니다. 계약서에 아무 말이 없으면 저작권은 실제로 만든 개발사에 남고, 발주자는 사용 허락만 받은 상태가 될 수 있습니다. "본 계약에 따라 개발되는 프로그램·디자인·문서의 저작권 및 이에 관한 특허권·실용신안권을 받을 권리는 발주자에게 귀속된다"는 식의 귀속 조항을 반드시 넣으세요.

기존 자산(BK)과 신규 결과물의 구분

개발사가 자사 라이브러리나 기존 코드를 재사용하는 경우, 그 부분까지 발주자에게 넘어가면 개발사가 난색을 보입니다. 그래서 실무에서는 "계약 전에 보유한 자산(Background IP)은 개발사에 남기고, 발주자에게는 영구적·무상의 사용권을 부여한다"는 조항으로 절충합니다. 다만 사용권 범위에 "수정·2차 저작물 작성권"이 빠지면 나중에 다른 업체가 유지보수를 못 하니, 권리 범위를 꼭 확인하세요.

오픈소스 사용에 대한 진술과 보증

"개발사는 결과물에 GPL 계열 등 의무 공개를 유발하는 오픈소스를 발주자 동의 없이 포함하지 않으며, 사용된 오픈소스 목록과 라이선스를 납품 시 함께 제공한다"는 조항을 넣으세요. 투자 실사나 인수 심사에서 오픈소스 목록을 요구하는 경우가 많은데, 계약서에 근거가 있어야 개발사에 자료를 요구할 수 있습니다.

오픈소스 라이선스, 이 세 가지만 기억하세요

오픈소스 라이선스는 수십 가지지만, 앱 개발 실무에서는 세 부류로 나눠 생각하면 거의 충분합니다. 첫째, MIT·BSD·Apache처럼 고지문만 포함하면 자유롭게 상용 서비스에 쓸 수 있는 허용적 라이선스입니다. 둘째, MPL·LGPL처럼 수정한 해당 파일이나 라이브러리 부분만 공개하면 되는 중간형입니다. 셋째, GPL·AGPL처럼 결합된 프로그램 전체의 소스 공개를 요구할 수 있는 강한 카피레프트형으로, 상용 앱에서는 사실상 사용을 피하거나 별도 격리 설계가 필요합니다.

특히 주의할 것은 "라이브러리를 바꾸지 않고 링크만 했는데도 의무가 생기는가"의 문제입니다. 정적 링크냐 동적 링크냐, 별도 프로세스 통신이냐에 따라 달라지는 라이선스가 있어서, 강한 카피레프트 라이브러리는 아키텍처 단계에서 배제하는 것이 안전합니다. 팀에 오픈소스 담당자가 없다면, 최소한 사용 라이브러리 목록과 라이선스 종류를 표로 정리해 두는 것만으로도 리스크의 절반은 줄어듭니다.

앱스토어 심사나 광고주 검토 과정에서도 오픈소스 고지를 요구하는 경우가 늘고 있습니다. 앱 내 설정 화면에 "오픈소스 라이선스" 메뉴를 만들어 목록과 고지문을 상시 노출해 두면, 별도 대응 없이도 대부분의 요구를 충족할 수 있습니다.

투자 실사에서 앱 개발사가 실제로 받는 IP 질문들

시드 투자 단계부터 투자자는 지식재산을 확인하기 시작합니다. "핵심 기술에 특허가 있는가", "서비스 이름의 상표권을 회사가 보유하고 있는가" 같은 기본 질문에서 시작해, 시리즈 A 이후로는 권리 서류를 일일이 뜯어봅니다. 이때 답변의 완성도가 기업가치 평가에 직접 반영되기 때문에, 평소에 정리해 두는 것과 급하게 만드는 것의 차이가 그대로 드러납니다.

실무에서 가장 자주 지적되는 것은 창업자 개인 명의로 되어 있는 권리입니다. 창업 전에 대표 개인이 출원한 특허나 상표가 회사 명의로 이전되어 있지 않으면, 투자 조건으로 "회사로의 양도"가 붙습니다. 양도는 등록료와 절차가 필요하고, 세금 문제까지 얽힐 수 있으니 처음부터 법인 명의로 출원하는 습관이 중요합니다.

두 번째로 자주 나오는 지적은 직무발명 규정의 부재입니다. 직원이 회사 업무로 발명한 것도, 보상 규정과 귀속 규정이 없으면 퇴사 후에 권리를 주장할 여지가 남습니다. 회사 규모가 작아도 근로계약서에 "업무상 발명은 회사에 귀속되며, 회사는 정당한 보상을 한다"는 취지의 조항과 별도 직무발명 보상 규정을 갖춰 두세요. 특허청이 배포하는 표준 규정을 참고하면 비용 없이 만들 수 있습니다.

세 번째는 오픈소스 감사 결과입니다. 실사에서 소스코드 스캔 도구를 돌려 GPL 계열 코드가 발견되면, 투자 조건으로 소스 공개 의무 해소 또는 해당 부분 재작성을 요구받는 경우가 실제로 있습니다. 앞서 설명한 오픈소스 목록 관리가 바로 이 순간을 위한 준비입니다. 정리가 되어 있다면 하루면 끝날 확인이, 없다면 몇 주씩 걸리며 딜이 지연됩니다.

마지막으로 상표 분쟁 이력과 진행 중인 분쟁의 유무를 반드시 묻습니다. 경고장을 받은 적이 있다면 숨기지 말고 대응 결과와 함께 공개하는 편이 낫습니다. 실사 단계에서 뒤늦게 발견된 분쟁은 신뢰를 깎지만, 미리 공개되고 관리된 분쟁은 오히려 "이 팀은 리스크를 관리할 줄 안다"는 인상을 줍니다.

투자 실사에서 앱 개발사가 실제로 받는 IP 질문들

시드 투자 단계부터 투자자는 지식재산을 확인하기 시작합니다. "핵심 기술에 특허가 있는가", "서비스 이름의 상표권을 회사가 보유하고 있는가" 같은 기본 질문에서 시작해, 시리즈 A 이후로는 권리 서류를 일일이 뜯어봅니다. 이때 답변의 완성도가 기업가치 평가에 직접 반영되기 때문에, 평소에 정리해 두는 것과 급하게 만드는 것의 차이가 그대로 드러납니다.

실무에서 가장 자주 지적되는 것은 창업자 개인 명의로 되어 있는 권리입니다. 창업 전에 대표 개인이 출원한 특허나 상표가 회사 명의로 이전되어 있지 않으면, 투자 조건으로 "회사로의 양도"가 붙습니다. 양도는 등록료와 절차가 필요하고, 세금 문제까지 얽힐 수 있으니 처음부터 법인 명의로 출원하는 습관이 중요합니다.

두 번째로 자주 나오는 지적은 직무발명 규정의 부재입니다. 직원이 회사 업무로 발명한 것도, 보상 규정과 귀속 규정이 없으면 퇴사 후에 권리를 주장할 여지가 남습니다. 회사 규모가 작아도 근로계약서에 "업무상 발명은 회사에 귀속되며, 회사는 정당한 보상을 한다"는 취지의 조항과 별도 직무발명 보상 규정을 갖춰 두세요. 특허청이 배포하는 표준 규정을 참고하면 비용 없이 만들 수 있습니다.

세 번째는 오픈소스 감사 결과입니다. 실사에서 소스코드 스캔 도구를 돌려 GPL 계열 코드가 발견되면, 투자 조건으로 소스 공개 의무 해소 또는 해당 부분 재작성을 요구받는 경우가 실제로 있습니다. 앞서 설명한 오픈소스 목록 관리가 바로 이 순간을 위한 준비입니다. 정리가 되어 있다면 하루면 끝날 확인이, 없다면 몇 주씩 걸리며 딜이 지연됩니다.

마지막으로 상표 분쟁 이력과 진행 중인 분쟁의 유무를 반드시 묻습니다. 경고장을 받은 적이 있다면 숨기지 말고 대응 결과와 함께 공개하는 편이 낫습니다. 실사 단계에서 뒤늦게 발견된 분쟁은 신뢰를 깎지만, 미리 공개되고 관리된 분쟁은 오히려 "이 팀은 리스크를 관리할 줄 안다"는 인상을 줍니다.

자주 묻는 질문

Q.앱의 아이디어만으로 특허가 가능한가요?

아닙니다. 단순한 사업 아이디어·비즈니스 모델 자체는 특허 대상이 아닙니다. 정보처리장치를 활용한 구체적인 기술적 방법, 즉 '어떻게 구현하는가'가 있어야 합니다. 아이디어 단계라도 기술적 구성을 구체화하면 출원 가능성을 검토할 수 있습니다.

Q. 앱 로고는 디자인권과 상표권 중 무엇을 먼저 해야 하나요?

일반적으로 상표권(도형 상표)을 먼저 검토합니다. 상표권은 브랜드의 상업적 사용을 막는 데 강하고, 디자인권은 형상 자체의 모방을 막는 데 강합니다. 예산이 허락하면 병행하는 것이 가장 튼튼합니다.

Q.MVP 단계에서도 특허 출원이 되나요?

기술적 구성이 명세서로 구체화할 수 있는 수준이면 가능합니다. 다만 구현이 불충분하면 등록 가능성이 낮아지므로, 핵심 로직이 확인된 시점에 출원하는 것이 일반적입니다. 출원 후 개량 기술은 추가 출원으로 보강합니다.

Q. 소스코드도 등록 없이 보호되나요?

네, 저작권은 작성과 동시에 자동 발생합니다. 등록은 창작자·창작 시기를 공식 입증하는 장치입니다. 분쟁 가능성이 있거나 투자 유치를 앞둔 코드라면 등록해 두는 편이 유리합니다.

Q. 오픈소스를 쓴 앱을 상용화할 수 있나요?

라이선스 종류에 따라 다릅니다. MIT·Apache 계열은 고지 표시 조건으로 상용 이용이 가능하고, GPL 계열은 소스 공개 의무가 따라붙을 수 있습니다. 사용 전에 각 라이브러리의 라이선스를 확인하는 절차가 필요합니다.

Q. 외주 개발자가 코드를 돌려주지 않으면 어떻게 하나요?

계약서의 인도 의무 조항을 근거로 이행을 요구할 수 있습니다. 계약서가 없다면 저작권 귀속부터 다퉈야 하므로 분쟁이 길어집니다. 개발 착수 전에 계약서와 인도물 목록을 정해 두는 것이 최선의 예방입니다.

Q. 해외 출시도 계획 중인데 상표는 어떻게 해야 하나요?

상표는 나라별 권리라 출시 국가에서 별도 확보가 필요합니다. 마드리드 의정서 국제출원으로 여러 나라를 한 번에 지정할 수 있고, 국내 출원일로부터 6개월 내 우선권 주장이 가능합니다. 미국 시장이 크다면 미국 출원을 우선 검토하세요.

마무리

앱 개발에서 IP는 부차적인 문서 작업이 아니라, 코드와 함께 쌓아 올리는 또 하나의 개발 작업입니다. 이름은 상표로, 핵심 기술은 특허로, 코드는 저작권으로, 화면은 디자인권으로. 이 네 겹을 출시 일정에 맞춰 순서대로 챙기면, 모방과 분쟁에 흔들리지 않는 서비스를 만들 수 있습니다.

⚠️ 본 글은 일반적인 정보 제공을 위한 것으로, 개별 사안에 대한 법률 자문이 아닙니다. 비용과 기간은 사안에 따라 달라질 수 있으며, 구체적인 출원 가능성과 계약 검토는 반드시 변리사와 상담하시기 바랍니다. 앱 개발자의 IP 보호에 대해 더 궁금한 점이 있으시면 자하특허 소개 및 문의 페이지를 통해 문의해 주세요. 자하특허는 특허·상표·디자인·저작권 등 지식재산 전반의 실무 정보를 다루는 전문 블로그입니다.

📎 관련 글

• •앱 하나를 지키는 IP 네 겹 — 보이는 화면, 이름과 로고, 기능과 코드까지
• •사업 아이디어도 특허가 될까 — 비즈니스 모델 특허와 진보성의 벽
• •특허출원 비용은 얼마일까 — 2026년 기준 변리사 비용과 특허청 수수료 총정리