Figma의 ‘Dev Mode’ 분쟁

최근 디자인 협업 소프트웨어 기업 Figma가 스웨덴 AI 스타트업 Lovable에 ‘Dev Mode’라는 표현을 쓰지 말라는 내용의 경고장을 보낸 사실이 알려지면서, 기능명과 상표권의 관계가 업계의 화제가 됐습니다.

이 사안은 단순한 네이밍 충돌처럼 보일 수 있지만, 실제로는 소프트웨어 스타트업이 어떤 이름을 언제부터 권리 관점에서 관리해야 하는지를 보여주는 사례로 읽을 수 있습니다.

https://www.theverge.com/news/649851/figma-dev-mode-trademark-loveable-dispute

관심이 커진 이유는 몇 가지가 분명합니다.

우선 Figma는 2023년 6월 자사 행사와 블로그를 통해 ‘Dev Mode’를 개발자용 워크스페이스로 공개했고, 이후 2024년 1월에는 이를 정식 출시 단계로 끌어올리며 관련 기능을 지속적으로 확장해왔습니다.

즉, Figma 입장에서는 ‘Dev Mode’가 일회성 표현이 아니라 제품 포지셔닝과 직접 연결된 기능명으로 축적돼 온 셈입니다.

https://www.figma.com/blog/introducing-dev-mode/

분쟁의 흐름을 간단히 보면 이렇습니다.

• Figma는 2023년 6월 16일 미국에서 ‘DEV MODE’ 상표를 출원했습니다.

• 해당 표장은 2024년 11월 미국에서 등록 상태가 되었습니다. 일부 보도에 따르면 EU에서도 같은 시기 등록이 이뤄졌고, 반면 영국에서는 등록 시도가 받아들여지지 않았다는 설명이 나왔습니다.

• 2025년 4월 Figma는 Lovable에 ‘Dev Mode’ 사용 중단을 요구하는 경고장을 보냈고, Lovable 공동창업자가 이를 공개하면서 논란이 크게 확산됐습니다.

이 사건이 특히 눈길을 끈 것은, ‘dev mode’ 또는 ‘developer mode’라는 표현이 업계에서 매우 널리 쓰이는 용어라는 점 때문입니다. 보도에서도 이 표현이 특정 한 회사만의 조어라기보다 일반적인 개발자 문맥에서 자주 사용돼 왔다는 반응이 적지 않았습니다. 반면 Figma는 해당 명칭이 자사 제품과 광범위하게 연결되어 왔기 때문에 지식재산을 보호할 필요가 있다는 입장을 보였습니다.

https://www.figma.com/ko-kr/dev-mode/

이 사례가 보여주는 핵심은 제품명보다 기능명이 먼저 브랜드가 된다는 점입니다.

스타트업 실무에서는 보통 회사명이나 제품명만 상표 검토 대상으로 생각하는 경우가 많습니다.

그런데 SaaS와 AI 제품에서는 실제로 사용자가 제품 전체보다 특정 기능을 먼저 기억하는 경우가 많아지고 있습니다. 특히 개발툴, 협업툴, 노코드 툴에서는 기능명 자체가 검색 키워드가 되고, 커뮤니티에서 통용되는 이름이 되며, 세일즈 자료와 고객 제안서에 반복적으로 등장하게 됩니다. 이 과정에서 기능명은 설명 문구를 넘어 사실상 브랜드처럼 작동하게 됩니다.

Figma의 ‘Dev Mode’도 바로 그런 유형에 가깝습니다.

Figma는 해당 명칭을 단순 메뉴명이 아니라 디자인과 개발의 간극을 줄여주는 별도 워크스페이스로 계속 설명해 왔고, VS Code 연동, Code Connect, MCP 관련 흐름까지 이어가며 개발자 접점을 강화해 왔습니다.

즉, 이 명칭은 기능 설명이면서 동시에 제품 포지셔닝의 일부로 축적되고 있었습니다.

상표 실무에서는 ‘너무 설명적이면 약하고, 너무 알려지면 지켜야 하는’ 문제가 생기고 있습니다

상표 관점에서 기능명은 늘 애매한 위치에 놓여 있습니다. 특정 용어가 기능이나 성질을 직접 설명하는 표현에 가까우면 원칙적으로는 식별력이 약해 보호 범위가 좁아질 수 있습니다.

반대로 특정 회사의 상품이나 서비스와 강하게 연결되기 시작하면, 그 시점부터는 권리자가 오히려 사용을 관리하지 않을 수 없게 됩니다. 사용을 방치할 경우 표지가 일반 명칭처럼 흘러갈 위험이 있기 때문입니다.

이는 스타트업이 기능명을 다룰 때 자주 놓치는 지점입니다. 상표의 핵심 기능은 출처 식별이며, 설명적 표장은 본질적으로 권리화와 집행 모두에서 더 민감하다는 점을 이해할 필요가 있습니다.

바로 그래서 이번 사안은 누가 옳고 그르냐만의 문제가 아닙니다. 오히려 더 중요한 것은, 널리 쓰이는 기능명처럼 보이는 표현도 어떤 회사에게는 장기간 투자해온 브랜드 자산이 될 수 있고, 반대로 다른 회사에게는 너무 익숙한 업계 용어라 별문제 없다고 느껴질 수 있다는 점입니다. 분쟁은 바로 이 인식 차이에서 발생하고 있습니다.

스타트업에게 더 현실적인 질문은 ‘언제부터 점검해야 하는가’에 있습니다

기능명은 외부 공개 직전에 급히 검색해 보는 수준으로는 부족할 수 있습니다. 반복적으로 사용할 가능성이 있는 핵심 기능명이라면, 제품 기획 단계에서부터 최소한의 선행 상표 검색과 사용 실태 점검을 해둘 필요가 있습니다.

특히 미국이나 유럽처럼 상표 집행이 활발한 시장을 함께 보는 경우에는, 단순히 도메인 확보 여부가 아니라 동일·유사 명칭이 어떤 상품·서비스 범위에서 쓰이고 있는지까지 살펴보는 편이 안전합니다. 이번 Figma 사례처럼 미국에서는 등록이 되었지만 다른 관할에서는 결과가 다를 수 있다는 점도 함께 봐야 합니다.

투자자 입장에서도 이 문제는 더 이상 사소하지 않습니다. 기능명이 이미 세일즈 자료, 웹사이트, 고객 계약서, 데모 영상에 깊게 들어가 있으면, 나중에 이름을 바꾸는 비용은 단순 리브랜딩 비용을 넘어섭니다. 제품 문서, 검색 유입, 고객 혼선, 영업 자산, 파트너 커뮤니케이션이 함께 흔들릴 수 있기 때문입니다.

특히 초기 SaaS나 AI 스타트업은 회사명보다 기능명이 더 빠르게 시장에 퍼지는 경우가 많아서, 기능명 리스크가 곧 사업 리스크가 되는 경우가 늘고 있습니다. 이 점에서 상표 전략은 더 이상 런칭 이후의 관리 문제가 아니라, 제품 설계와 함께 움직여야 하는 문제라고 보는 편이 맞습니다.

결국 지금 필요한 것은 ‘제품명 중심 사고’에서 벗어나는 일입니다

‘Dev Mode’ 분쟁은 한 회사가 공격적이냐 아니냐의 문제를 넘어, 소프트웨어 시장에서 IP의 출발점이 이미 기능 단위로 내려와 있다는 사실을 보여주고 있습니다. 제품명만 챙기면 된다는 생각으로는 부족합니다.

사용자가 기억하는 이름, 검색되는 이름, 제안서와 매뉴얼에 반복적으로 등장하는 이름이 무엇인지부터 다시 봐야 합니다.

스타트업에게는 작은 기능명 하나가 훗날 브랜드 자산이 될 수도 있고, 반대로 분쟁의 출발점이 될 수도 있습니다. 지금 시점에서 필요한 것은 이름을 나중에 보호하는 전략이 아니라, 이름을 처음 붙일 때부터 사업과 권리를 함께 설계하는 접근이라고 할 수 있습니다.