[태그:] 앱개발

앱 하나 내놓으면 수익 30%가 먼저 나간다. 구글이든 애플이든 마찬가지다. 1만 원짜리 아이템 하나 팔면 개발사 통장엔 7천 원만 들어온다는 얘기다. 수수료율 1%p 차이가 연간 수백만 원 규모로 불어날 수 있는데, 이 구조를 정확히 파악하고 있는 개발자는 생각보다 드물다. 인디 개발자나 스타트업이라면 플랫폼 고르기 전에 한번쯤 짚고 넘어가야 한다.

30% 수수료, 왜 이게 문제인가

구글과 애플 모두 기본 인앱결제 수수료로 30%를 적용해왔다. 2008년 앱스토어 출범 이후 10년 넘게 이어진 관행이다. 이 숫자가 논란인 이유는 단순하다. 협상이 안 된다는 거다. 플랫폼이 유일한 배포 경로인 상황에서 개발사 입장에서는 선택지 자체가 없다.

에픽게임즈가 포트나이트 직접결제를 밀어붙이다 양 플랫폼에서 동시에 퇴출당한 사건, 스포티파이가 유럽 경쟁당국에 제소한 사건 모두 이 구조에서 비롯됐다. 수수료 문제가 아니라 사실상 독점 구조 문제에 가깝다는 시각이 나오는 것도 이해가 된다.

구글 플레이 수수료 구조

구글은 현재 다층적 수수료 체계를 운영한다.

• 기본 수수료: 연간 매출 100만 달러(약 13억 원) 이하 구간 — 15%
• 초과 구간: 100만 달러 초과분 — 30%
• 구독 앱: 가입 첫 해 15%, 2년차부터도 15% (전 구간 동일)
• 전자책·음악 스트리밍 등: 별도 협약으로 10% 적용 가능

에픽게임즈 소송 합의 이후 구글은 일부 시장에서 수수료를 추가 인하하는 조치를 진행 중이다. 중소 개발사 쪽에 상대적으로 유리한 방향이고, 전 세계 확대는 단계적으로 진행된다. 아직 확정된 건 아니지만, 흐름 자체는 인하 쪽이다.

애플 앱스토어 수수료 구조

애플의 체계는 구글과 유사하지만 기준선이 조금 다르다.

• 소규모 개발자 프로그램: 연간 매출 100만 달러 이하 — 15%
• 일반 수수료: 100만 달러 초과 — 30%
• 구독: 1년 이상 유지 구독자에 한해 15%로 인하
• EU 지역: DMA(디지털시장법) 적용으로 대체 결제 허용, 단 Core Technology Fee(설치당 약 0.5유로) 별도 부과

애플은 iOS에서 제3자 앱스토어를 원칙적으로 허용하지 않아왔다. EU에서만 법적 강제로 대안 마켓플레이스 허용이 시작됐고, 이 흐름이 다른 지역으로 번질지는 미지수다. EU 바깥에서 애플의 입장은 여전히 강경하다. Core Technology Fee 같은 별도 요금 구조를 보면, 허용하면서도 수익을 놓지 않겠다는 계산이 보인다.

구글 vs 애플, 실질적인 차이

숫자만 놓고 보면 두 플랫폼 구조는 거의 같다. 실질적 차이는 예외 조항과 적용 방식에 있다.

• 중소 개발자 우대: 둘 다 100만 달러 이하 구간에 15% 적용. 기준은 동일하다
• 제3자 결제: 구글은 일부 국가에서 대안 결제 허용(수수료 4%p 할인). 애플은 EU만 허용, 그 외 불가
• 게임 앱: 구글은 인기 게임사 대상 협상 여지가 있다. 애플은 사실상 단일 요율
• 웹 결제 유도: 구글은 앱 내 외부 링크 허용(미국 한정, 법원 판결). 애플은 최근까지 금지였고 지금은 제한적으로만 허용
• 분쟁 해결: 구글은 에픽과 합의 완료. 애플은 에픽과 소송 진행 중(항소심)

에픽게임즈 소송이 실제로 바꾼 것

에픽이 2020년 포트나이트 직접결제를 밀어붙인 건 단순 규정 위반이 아니었다. 의도된 도발이었다. 양 플랫폼에서 동시에 퇴출당하면서 바로 소송을 제기했고, 구글과의 소송에서는 배심원단이 에픽의 손을 들어줬다.

합의 과정에서 구글은 수수료 인하, 제3자 앱스토어 접근성 개선, 일부 시장에서의 대안 결제 허용 등을 수용했다. 직접적인 수혜자는 에픽 같은 대형 퍼블리셔보다 오히려 협상력 자체가 없는 중소 개발사 쪽이 될 가능성이 크다. 싸운 건 에픽인데 혜택은 인디 개발자에게 돌아가는 아이러니한 구도다.

애플과의 소송은 결과가 달랐다. 법원은 반독점법 위반을 인정하지 않았지만 외부 결제 링크 허용 명령은 유지됐다. 그런데 애플이 이를 제한적으로만 이행하고 있다는 비판이 계속 나온다. 명령은 이겼는데 이행은 반쪽짜리라는 얘기다.

수수료 줄이는 현실적인 방법

플랫폼 수수료를 완전히 피하기는 어렵다. 그래도 방법이 아예 없진 않다.

• 웹 결제 유도: 구글 플레이는 미국에서 앱 내 외부 결제 링크를 허용한다. 사용자를 웹으로 보내서 결제하게 하면 수수료를 크게 아낀다. 다만 UX 마찰이 생기는 트레이드오프가 있다
• 구독 모델 전환: 연간 구독을 1년 이상 유지한 사용자에겐 15%가 적용된다. 일회성 결제보다 장기 구독 전환이 장기적으로 유리하다
• 소규모 개발자 프로그램 유지: 연 매출 100만 달러 이하를 유지하면 15% 구간이 계속 적용된다. 성장 속도를 의도적으로 조절하는 팀도 실제로 있다
• B2B 앱 활용: 기업 대상 앱은 Apple Business Manager나 Google Play for Work를 통해 배포하면 인앱결제 수수료 구조를 우회하는 경우가 있다
• 디지털 재화 예외 확인: NFT, 특정 물리적 상품 연동 서비스 같은 일부 콘텐츠는 인앱결제 의무에서 제외된다. 자사 서비스가 해당하는지 가이드라인을 꼼꼼히 봐야 한다

결국 어느 쪽이 덜 아픈가

수수료 숫자만 놓고 보면 지금 시점에서 구글이 약간 유연하다. 대안 결제 허용 범위가 더 넓고, 합의 이후 추가 인하 조치도 진행 중이다. Ars Technica가 전한 바에 따르면 구글은 에픽과의 합의를 이행하는 방향으로 수수료 인하를 단계적으로 확대하고 있다.

단, 수수료가 전부가 아니다. 애플 사용자의 평균 소비력이 안드로이드 대비 높다는 건 업계에서 공공연한 얘기다. 게임·유틸리티·구독 앱 기준으로 iOS 쪽 ARPU(사용자당 평균 수익)가 구글 플레이보다 높게 나오는 경우가 많다. 수수료 2~3%p 차이보다 이 격차가 더 클 수 있다.

수익 최적화를 고민하는 개발자라면 수수료율 비교보다 플랫폼별 사용자 LTV(생애 가치)를 먼저 측정하는 게 맞다. 수수료는 내는 것이고, 매출은 버는 것이다. 비율보다 절대액이 중요하다.

출처: Ars Technica

디자이너가 피그마에서 컴포넌트 하나를 옮겼더니, 리액트 코드가 자동으로 따라왔다. SF 얘기가 아니다. Vibe 코딩이 추구하는 방향이 딱 이거다. 해외 IT 커뮤니티에선 이미 이 개념을 두고 토론이 한창이고, TechCrunch가 전한 바에 따르면 Lovable은 iOS와 Android 앱까지 출시했다. 단순한 유행어가 아닐 수 있다는 신호다.

Vibe 코딩, 뭔지부터 짚고 가자

Vibe 코딩은 디자인의 시각적·감성적 ‘vibe(분위기)’를 코드로 직관적으로 변환하는 개발 접근법이다. 기능이 돌아가는 것만으론 부족하다는 전제에서 출발한다. 사용자가 앱을 열었을 때 느끼는 ‘이 서비스 뭔가 다르다’는 감각, 그걸 코드 레벨에서 구현하겠다는 거다.

• 디자인 주도 개발: 코딩의 시작점이 스펙 문서가 아니라 디자인의 분위기와 사용자 경험에 있다.
• 직관적 인터페이스: 비주얼 툴로 디자인 요소를 조작하면 코드가 자동 생성된다. 손으로 CSS를 한 줄씩 치는 방식이 아니라.
• 실시간 피드백: 색상 하나 바꾸면 즉시 결과물에 반영된다. 빌드 기다릴 필요 없다.

‘어떻게 작동하나’보다 ‘어떻게 느껴지나’를 먼저 묻는 방식. 그게 핵심이다.

기존 개발 방식이랑 뭐가 다른가

전통 웹/앱 개발 흐름을 떠올려 보면, 기획 → 디자인 시안 → 프론트 구현 → 백엔드 → 테스트 순서가 꽤 고정돼 있다. 디자이너가 피그마로 만든 시안을 개발자가 받아서 코드로 ‘번역’하는 구조다. 이 번역 과정에서 디자인 의도가 어딘가 날아가버리는 건 다들 한 번씩 겪었을 거다. 마진 10px이 왜 8px이 됐는지 묻다가 회의가 30분 늘어나는 그런 상황.

Vibe 코딩은 이 번역 단계 자체를 줄이거나 없애는 쪽을 겨냥한다. 디자인 툴이 개발 툴을 겸하거나, 디자인 단계에서 코드가 자동 생성되는 형태다. 결과적으로 디자이너와 개발자 간 경계가 흐려지고, 협업 구조 자체가 달라진다. 디자이너가 직접 동작하는 화면을 만들어 내는 상황이 생기는 거다. 솔직히 여기서 개발자 입장에선 살짝 긴장되기도 한다.

이게 가능한 이유: 기술 3가지

기술 기반을 빼놓고 얘기하면 그냥 구호에 불과하다. Vibe 코딩이 현실로 들어오는 데 결정적 역할을 한 건 크게 셋이다.

• AI / 머신러닝: 레이아웃과 색상 조합을 학습해서 반응형 코드를 자동 제안한다. 특정 UI 패턴이 어떤 감성을 주는지 모델이 이미 알고 있다는 뜻이다.
• 고도화된 비주얼 프로그래밍 툴: 드래그 앤 드롭 수준을 한참 넘어섰다. 디자이너의 의도를 ‘읽어내는’ 수준까지 왔고, 노코드·로우코드 플랫폼의 발전과 궤를 같이 한다.
• 컴포넌트 기반 개발: 버튼, 카드, 내비게이션 같은 미리 정의된 UI 컴포넌트를 vibe에 맞게 조합하고 커스터마이징하는 방식이 효율을 크게 올린다.

세 기술이 맞물리면서 개발 진입 장벽이 낮아지고 있다. 아직 모든 게 매끄럽진 않지만, 방향은 분명하다.

개발 생태계에 미칠 실질적 변화

Vibe 코딩이 확산되면 개발 현장에서 뭐가 달라지는지 구체적으로 보자.

• 개발 속도 향상: 아이디어가 프로토타입이 되는 시간이 짧아진다. 스타트업이나 MVP를 빠르게 검증해야 하는 팀에게 이건 꽤 실질적인 이점이다.
• 디자이너의 역할 확장: 코드를 몰라도 실제 동작하는 화면을 만들 수 있게 된다. 디자인 비전을 중간 단계 없이 구현하는 셈이다.
• 개발자의 역할 변화: 단순 코딩 비중은 줄어든다. 대신 아키텍처 설계, 복잡한 비즈니스 로직, 성능 최적화, 보안 같은 영역에 더 집중하게 된다. 이게 나쁜 방향은 아니다.
• 새로운 협업 모델: 디자이너·개발자·기획자가 같은 툴에서 실시간으로 작업한다. 피드백 루프가 훨씬 빨라진다.

개발 프로세스 전체의 생산성을 끌어올리는 쪽으로 작용할 여지가 크다.

준비하려면 뭘 해야 하나

Vibe 코딩이 모든 걸 대체하진 않는다. 그렇다고 무시하기엔 흐름이 너무 뚜렷하다. 지금 당장 준비할 수 있는 것들을 정리하면 이렇다.

• 기초 역량은 오히려 더 단단히: 자료구조, 알고리즘, 시스템 설계 같은 바탕이 없으면 자동 생성된 코드의 문제를 잡아낼 수 없다. Vibe 코딩 툴이 만든 코드가 왜 느린지, 어디서 터지는지 읽어낼 줄 알아야 한다. 기초는 오히려 더 빛난다.
• UI/UX 감각을 키워라: ‘vibe’를 이해하는 게 핵심인 만큼, 디자인 원칙과 사용자 경험에 대한 감각은 개발자에게도 이제 선택이 아니다. 디자이너와 같은 언어로 대화하는 능력이 차이를 만든다.
• 새 툴에 거부감 없애기: 로우코드·노코드 툴을 직접 써보고, AI 기반 개발 도구를 workflow에 녹이는 연습이 필요하다. 새 기술 흡수 속도가 곧 경쟁력이다.
• 협업 커뮤니케이션: 경계가 허물어질수록 적극적인 소통이 더 중요해진다. 디자이너, PM과 같은 툴에서 일하게 되면 기술 너머의 대화 능력이 결과를 가른다.

한계도 솔직하게 보자

장밋빛 얘기만 하면 반쪽짜리 정보다. 현재 Vibe 코딩의 한계는 꽤 명확하다.

• 복잡한 로직엔 여전히 역부족: 대규모 트랜잭션 처리, 정교한 알고리즘, 고성능이 생명인 앱엔 여전히 수작업 코딩이 필수다. Vibe 코딩은 빠른 구현에 강하지, 모든 상황에 맞지는 않는다. 이건 좀 과한 기대다.
• 커스터마이징의 벽: 자동 생성된 코드나 템플릿 기반 구현은 세밀한 커스터마이징에 제약이 따른다. 독창적인 기능을 만들려 할 때 오히려 발목을 잡을 수도 있다.
• 보안과 유지보수: 자동 생성된 코드가 보안 취약점을 안고 있을 가능성, 그리고 6개월 뒤 그 코드를 누가 어떻게 관리할 건지는 여전히 검증이 필요한 부분이다.
• 새로운 학습 곡선: 기존 개발자 입장에선 새로운 툴과 개념에 익숙해지는 시간이 든다. 공짜로 얻는 건 없다.

한계를 알고 쓰는 것과 모르고 쓰는 건 다르다. 도구는 맥락이 맞아야 빛난다.

결국 뭐가 달라지나

Vibe 코딩은 웹/앱 개발의 속도를 올리고, 디자인과 코드 사이의 골을 메운다. 아이디어가 서비스가 되는 시간을 줄이는 데 꽤 실질적인 도구다.

만능열쇠는 아니다. 복잡한 시스템, 보안, 성능 최적화엔 아직 인간 개발자의 손이 필요하다. 하지만 ‘어떻게 활용하느냐’에 따라 이 도구의 가치는 크게 갈린다. Vibe 코딩의 흐름을 이해하고 자기 workflow에 녹여낸 개발자와, 그냥 관망한 개발자의 생산성 격차는 시간이 갈수록 벌어질 거다. TechCrunch가 Lovable의 iOS·Android 출시를 다룬 건 그냥 기사 하나가 아니라, 이 흐름이 모바일까지 닿았다는 신호다.

출처: TechCrunch