애플리케이션 하나를 만든다는 건 생각보다 많은 가치를 한곳에 쌓아 올리는 일입니다. 사용자가 마주하는 화면, 사람들이 부르는 이름과 로고, 화면 뒤에서 돌아가는 작동 방식, 그리고 개발자가 한 줄씩 써내려간 코드까지. 재미있는 건 이 네 가지가 서로 다른 권리로 지켜진다는 점이에요. 이 글에서는 앱을 지키는 네 겹의 방패를 '보이는 화면', '이름과 로고', '기능과 코드'라는 세 갈래로 나눠, 각각 어떤 지식재산권이 어떻게 작동하는지 차근차근 풀어보겠습니다.
보이는 화면
앱을 처음 켰을 때 사용자가 마주하는 건 결국 화면입니다. 버튼이 어디 놓여 있는지, 아이콘이 어떤 모양인지, 메뉴가 어떤 방식으로 펼쳐지는지 — 이 '보이는 부분'이 앱의 첫인상을 거의 다 결정하죠. 그리고 이 화면 디자인은 디자인권으로 지킬 수 있습니다. 사실 화면 디자인 보호 자체는 예전부터 가능했어요. 다만 '스마트폰 화면에 표시된 아이콘'처럼, 디자인이 반드시 어떤 물품에 부착된 형태(부분디자인)로 묶여 있어야 했죠. 화면 속 그래픽이 늘 특정 기기를 전제로만 권리를 인정받았던 셈입니다. 그런데 2021년 10월에 시행된 개정 디자인보호법이 여기서 한 걸음 더 나아갔어요. 이제는 GUI나 아이콘, 화면 그래픽 같은 '화상디자인' 그 자체를 특정 하드웨어와 분리해서 등록받을 수 있습니다. 자동차 내비게이션 화면이든 스마트워치 시계 화면이든, 모바일 앱의 메뉴 아이콘이든, 물품이라는 굴레를 벗어나 화면 그 자체로 보호받는 길이 새로 열린 겁니다.
비유하자면 가게의 진열창 같은 거예요. 손님이 안으로 들어오기 전에 가장 먼저 보는 건 유리창 너머 진열의 모양과 배치죠. 누군가 우리 가게의 진열을 그대로 베껴 옆 가게를 꾸민다면 손님이 헷갈릴 수밖에 없습니다. 화상디자인 등록은 바로 그 진열창을 우리 것으로 못 박아두는 일이에요. 게다가 개정법은 화상디자인을 온라인으로 전송하는 행위까지 '실시'로 보기 때문에, 누군가 우리 등록 화면을 무단으로 복제해 앱에 띄우거나 파일로 퍼뜨리면 그것도 침해가 됩니다. 화면 하나하나에 공들인 팀이라면 한 번쯤 챙겨볼 만한 권리죠.
이름과 로고
아무리 화면을 잘 만들어도, 사람들이 그 앱을 '무엇'이라고 부를지가 정해지지 않으면 곤란합니다. 앱의 이름과 로고는 사용자가 우리를 알아보고 다시 찾아오게 만드는 가장 직접적인 신호거든요. 이걸 지키는 권리가 상표권입니다. 상표는 쉽게 말해 시장에서 '이건 내 것'이라고 말할 수 있는 이름표예요. 앱 이름, 서비스명, 로고, 때로는 특징적인 색 조합까지 상표로 출원해둘 수 있습니다.
여기서 흔히 놓치는 지점이 하나 있어요. 상표는 '먼저 쓴 사람'이 아니라 원칙적으로 '먼저 출원한 사람'이 권리를 갖는다는 점입니다. 몇 달을 고민해 지은 멋진 이름으로 앱을 출시했는데, 알고 보니 비슷한 이름을 누군가 먼저 등록해두었다면 출시 직전에 이름을 통째로 바꿔야 하는 상황이 생길 수 있어요. 도메인을 사고 마케팅 비용까지 들인 뒤에 이런 일이 터지면 타격이 꽤 큽니다. 그래서 이름을 확정하기 전에 같은 분야에 비슷한 상표가 이미 있는지 먼저 살펴보고, 괜찮다 싶으면 빠르게 출원해두는 순서가 안전합니다. 또 한 가지, 상표는 '어떤 상품·서비스에 쓸 것인가'를 지정해서 등록해요. 같은 이름이라도 우리가 지정하지 않은 분야에서는 보호가 닿지 않을 수 있으니, 앱이 실제로 제공하는 서비스 범위를 잘 짚어 지정하는 게 중요합니다. 건물에 비유하면 상표는 우리가 입주할 '방'을 지정해 등록하는 것과 비슷해요. 같은 이름이라도 다른 층, 다른 방에서는 또 다른 사람이 쓸 수 있는 거죠.
기능과 코드
이제 눈에 잘 보이지 않는 영역으로 들어갈 차례예요. 앱의 진짜 경쟁력은 종종 화면 뒤에 숨어 있습니다. 사용자의 행동을 예측해 다음 화면을 미리 띄우는 방식이라든가, 결제 흐름을 몇 단계로 줄여낸 독특한 프로세스, 데이터를 처리해 결과를 돌려주는 구체적인 방법 — 이런 '작동하는 방식'은 특허로 보호할 수 있습니다. 흔히 BM(영업방법) 특허, 또는 컴퓨터 관련 발명이라고 부르는 영역이죠. 단순한 아이디어나 추상적인 사업 모델 그 자체는 특허가 되지 않지만, 그것을 컴퓨터와 결합해 '기술적으로 구현하는 구체적인 방법'으로 풀어내면 발명으로 인정받을 수 있어요. 특허의 강점은 권리범위가 넓다는 데 있습니다. 경쟁사가 코드를 한 줄도 베끼지 않고 처음부터 새로 짰더라도, 보호받는 그 '방법'을 똑같이 구현하면 침해가 되니까요.
또한, 코드 그 자체, 즉 개발자가 한 줄 한 줄 작성한 소스코드는 저작권으로 보호됩니다. 저작권의 가장 큰 매력은 별도 등록 없이 코드를 만든 순간 자동으로 발생한다는 점, 그리고 보호 기간이 저작자 사후 70년으로 특허(출원일로부터 20년)보다 훨씬 길다는 점이에요. 다만 한계도 분명합니다. 저작권은 '표현된 코드'를 보호할 뿐, 그 안에 담긴 아이디어나 작동 원리까지 보호하지는 않아요. 그래서 경쟁사가 같은 기능을 완전히 다른 코드로 새로 구현해버리면 저작권만으로는 막기 어렵습니다. 결국 같은 앱이라도 '눈에 보이는 멋진 기능'은 특허로, '직접 짠 코드 자체'는 저작권으로 지키는 이중 전략이 자연스럽게 나오게 됩니다. 권리화에 앞서 더 중요한 건, 우리 앱에서 진짜 핵심이 어느 부분인지를 먼저 가려내는 일이에요.
앱 하나를 만들면 그 안에는 화면, 이름, 작동 방식, 코드라는 서로 다른 가치가 함께 들어 있습니다. 그리고 이들은 각각 디자인권, 상표권, 특허, 저작권이라는 다른 도구로 지켜집니다. 그렇다고 모든 걸 다 출원해야 하는 건 아니에요. 우리 앱의 진짜 경쟁력이 화면의 감각인지, 브랜드인지, 기능의 독창성인지에 따라 무엇을 먼저 지킬지가 달라지니까요. 중요한 건 출시 전에 한 번, 우리 앱의 어느 부분에 무게중심이 있는지를 지도처럼 그려보는 일입니다. 이 부분을 정리하다 막히는 지점이 있으면 편하게 문의해주세요.