[카테고리:] 가이드

몸값을 냈는데도 파일이 돌아오지 않는다. 이건 이미 알려진 얘기다. 근데 최근엔 한 술 더 뜬다. 특정 코딩 오류로 인해 128KB를 초과하는 파일은 애초에 복구 불능 상태로 파괴되어버리는 랜섬웨어까지 나왔다. Tom’s Hardware 보도를 보면, 돈을 내든 안 내든 파일은 그냥 사라진다. 읽으면서 솔직히 좀 아찔했다. 랜섬웨어가 ‘암호화 → 인질’ 공식에서 ‘그냥 다 부숴버리기’로 진화하고 있다는 얘기다.

랜섬웨어, 이제는 암호화도 아니다

원래 랜섬웨어의 공식은 이랬다. 파일을 잠그고, 돈을 받으면 키를 준다. 범죄자 입장에서도 ‘신뢰’가 필요했으니까. 근데 그 공식이 깨지고 있다. 최근 보안 업계 보고서들을 보면 몸값 지불 후에도 복구 키가 아예 안 오는 경우가 늘었고, 기술적 결함으로 인해 파일 자체를 되살릴 수 없는 상태로 만들어버리는 변종도 확인됐다. 128KB 초과 파일을 죄다 망가뜨리는 랜섬웨어가 그 예다. 이 경우엔 몸값을 내도 아무 의미가 없다. 처음부터 복구가 불가능하니까.

결론은 단순하다. 감염되지 않는 게 최선이고, 감염됐을 때 살아남으려면 백업밖에 없다.

감염 전에 해야 할 것들

예방의 핵심은 세 가지다. 백업, 업데이트, 의심.

• 3-2-1 백업 규칙: 가장 확실한 방어선이다. 데이터 복사본 3개, 서로 다른 저장 매체 2개(PC 내장, 외장하드, 클라우드 조합), 그리고 그 중 1개는 반드시 오프라인에. 평소엔 외장하드를 PC에서 분리해놔야 한다. 랜섬웨어는 네트워크로 연결된 장치를 싹 다 감염시키기 때문이다.
  • 3개: 원본 포함 최소 3벌 보관
  • 2개: 다른 매체에 분산 — 내장 드라이브, 외장 SSD, 클라우드 중 2가지 이상
  • 1개: 네트워크 미연결 오프라인 보관. 이게 핵심이다
• OS·소프트웨어 업데이트: 귀찮아도 해야 한다. OS, 웹 브라우저, 오피스, 백신 소프트웨어 — 전부 최신 버전으로 유지해야 랜섬웨어 침투 경로를 막는다. 업데이트 미루는 습관이 보안 구멍을 열어두는 거다.
• 이메일 첨부파일 주의: 랜섬웨어 감염 경로의 상당 부분이 이메일이다. .exe, .zip, .js, .vbs 확장자 파일은 발신자를 먼저 의심해라. 링크도 클릭 전에 URL을 확인하는 습관이 필요하다.
• 강력한 비밀번호 + 2단계 인증: 계정이 털리면 끝이다. 복잡한 비밀번호에 MFA(다단계 인증)를 더하면 계정 탈취 위험이 크게 줄어든다.
• 방화벽 + 불필요한 포트 차단: 외부에서 들어오는 무단 접근을 막는 기본이다. 공유기 비밀번호를 기본값으로 쓰고 있다면 지금 당장 바꿔야 한다.

감염됐다 싶으면 이 순서대로

아무리 조심해도 감염될 여지는 있다. 그때 초기 대응이 피해 규모를 가른다.

• 네트워크 즉시 차단: 의심스러우면 일단 Wi-Fi를 끄거나 랜 케이블을 뽑아라. 랜섬웨어가 다른 기기로 번지는 걸 막고, 추가 암호화도 멈출 수 있다. 속도가 중요하다.
• 전원은 끄지 마라: 당황해서 강제 종료하면 오히려 복구 시도에 필요한 메모리 내 정보가 사라질 수 있다. 네트워크만 끊고 기기는 켜둔 채로 전문가를 기다리는 게 낫다.
• 증상 기록: 어떤 파일이 암호화됐는지, 확장자가 뭐로 바뀌었는지, 랜섬웨어 메시지는 뭐라고 나오는지 — 스크린샷이든 메모든 남겨둬라. 복구 전문가나 수사기관에 도움이 된다.
• KISA 118 상담: 한국인터넷진흥원(KISA) 118 상담센터에 신고하면 랜섬웨어 피해 복구 상담을 받을 수 있다. 혼자 끙끙대다 상황을 악화시키는 것보다 훨씬 낫다.
• 몸값 절대 내지 마라: 돈을 내도 파일을 돌려주지 않는 경우가 상당하다. 관련 연구 보고서들이 반복적으로 지적하는 내용이다. 앞서 말한 128KB 결함 랜섬웨어처럼 기술적으로 복구 자체가 불가능한 경우도 있다. 돈만 날린다.

파일 되찾기, 현실적으로 가능한가

랜섬웨어에 걸리면 복구 옵션이 몇 가지 있다. 솔직히 기대치는 낮게 잡는 게 맞다.

• 백업 복원: 제대로 된 백업이 있다면 이게 답이다. 감염된 시스템을 초기화하고 백업 데이터를 올리면 끝. 백업이 없는 경우엔 이 항목 자체가 의미 없다는 게 문제지만.
• 무료 복구 툴: 일부 랜섬웨어는 보안 업체들이 복구 툴을 만들어 무료 배포한다. ‘노모어랜섬(No More Ransom)’ 사이트에서 자신이 걸린 랜섬웨어 유형을 입력하면 복구 툴이 있는지 확인 가능하다. 단, 모든 랜섬웨어에 툴이 있는 건 아니다.
• 전문 복구 업체: 백업도 없고 무료 툴도 없다면 전문 업체에 맡기는 선택지가 남는다. 비용이 상당하고 성공을 100% 보장하지도 않는다. 그냥 현실이 그렇다.
• 손실 인정: 안타깝지만, 어떤 방법으로도 복구가 안 되는 경우가 있다. 128KB 결함 랜섬웨어처럼 처음부터 파일을 파괴해버린 경우라면 더더욱. 이게 오프라인 백업을 미리 해야 하는 이유다.

기업이라면 이것도 챙겨야 한다

기업 환경에서 랜섬웨어 피해는 규모가 다르다. 영업 자료, 고객 데이터, 내부 시스템이 한꺼번에 날아가면 회사 존립이 흔들린다. 개인용 백신 하나 설치해놓고 끝낼 수준이 아니다.

• EDR/XDR 솔루션: 엔드포인트에서 이상 징후를 실시간으로 탐지하고 대응하는 도구다. 공격이 퍼지기 전에 차단하는 데 효과적이다.
• 직원 보안 교육: 결국 사람이 뚫린다. 피싱 이메일 식별, 수상한 USB 차단, 의심스러운 사이트 접속 자제 — 정기적이고 실전적인 교육이 필요하다. 1년에 한 번 클릭만 하는 e러닝으로는 부족하다.
• 취약점 점검 + 모의 해킹: 실제로 뚫릴 수 있는 구멍이 어디 있는지 주기적으로 확인해야 한다. 모의 공격으로 방어 체계를 직접 시험해보는 것도 방법이다.
• 제로 트러스트 아키텍처: ‘아무것도 신뢰하지 않는다’는 원칙 아래, 모든 접근을 엄격히 인증하고 권한을 최소화하는 구조다. 내부자 위협과 외부 침입 양쪽 모두를 막는다.
• 보안 정책 수립: 데이터 접근 권한, 백업 주기, 사고 대응 절차 — 문서로 만들고 전 직원이 지키게 해야 한다. 정책이 없으면 사고 났을 때 우왕좌왕한다.

결국 살아남는 데이터는 오프라인 백업에서 시작된다

랜섬웨어는 계속 진화한다. 암호화에서 파괴로, 이제는 기술적 결함으로 복구 자체를 막아버리는 형태까지. 첨단 보안 솔루션도 중요하지만, 결정적으로 데이터를 지키는 건 오프라인 백업이다. 3-2-1 규칙을 생활화하고, 외장하드는 평소에 분리해놓고, 주기적으로 백업 상태를 점검해라. 완벽한 방어는 없다. 하지만 백업만 제대로 돼 있으면 랜섬웨어는 그냥 ‘불편한 사건’으로 끝난다.

출처: Reddit r/technology

디자이너가 피그마에서 컴포넌트 하나를 옮겼더니, 리액트 코드가 자동으로 따라왔다. 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

구글 플레이 스토어에 앱을 올리려면 25달러를 먼저 내야 한다. 딱 한 번만. 애플 앱스토어가 매년 99달러를 청구하는 것과 비교하면 꽤 합리적이다. 이 일회성 수수료만 내면 별도 연회비 없이 계정이 유지된다. 처음 개발자 등록을 앞두고 절차가 복잡할 것 같아 미루는 경우가 많은데, 막상 해보면 생각보다 단순하다. 다만 몇 군데 걸리는 포인트가 있어서 미리 알고 들어가는 게 낫다.

등록이 왜 이렇게 까다로워졌나

예전엔 지금보다 훨씬 느슨했다. 앱 하나 만들어 올리면 그만이었다. 그런데 앱 생태계가 커지면서 악성 코드, 사기성 앱, 개인정보 탈취 앱 등이 우후죽순 올라오기 시작했다. 구글 입장에서도 방치할 수 없었던 거다.

그래서 지금은 세 가지가 핵심이다.

• 신원 확인 강화: 등록 개발자만 앱을 배포하도록 제한함으로써 악성 앱 유포를 원천 차단한다. 신분증 기반 본인 확인까지 요구하는 경우도 있다.
• 책임 부여: 정책 위반 시 계정 제재가 따른다. 개발자가 스스로 정책을 지킬 유인이 생기는 구조다.
• 정책 일관성: 등록 개발자에게는 정책 변경 사항이 공식 채널로 전달된다. 모르고 위반하는 일을 줄이는 역할도 한다.

사용자 입장에서는 나쁘지 않은 변화다. 앱 품질이 전반적으로 올라갔고, 노골적인 사기 앱은 예전보다 확실히 걸러진다.

준비물 체크리스트

등록 전에 이것만 챙겨두면 된다. 네 가지다.

• 구글 계정: 기존 Gmail 계정도 되고, 개발 전용으로 새로 만들어도 상관없다. 개인 계정과 섞이는 게 불편하다면 새로 파는 걸 추천한다.
• 결제 수단: 비자, 마스터카드 등 국제 결제 가능한 카드가 필요하다. 25달러 한 번이니 체크카드도 된다.
• 신원 정보:
  • 개인 개발자: 실명, 거주 국가, 연락처, 이메일. 신분증 정보와 일치해야 한다.
  • 기업 개발자: 사업자 등록증, 법인명, 사업장 주소, 대표자 정보, 법인 연락처가 필요하다.
• 개발자 프로필 정보: 스토어에 공개될 개발자 이름과 연락처 이메일은 미리 정해두자. 웹사이트는 선택 사항이다.

본인 확인에서 막히는 경우가 제법 있다. 처음부터 신분증 정보와 완벽히 일치하는 정보를 입력해야 나중에 번거롭지 않다.

단계별 등록 절차

준비물이 다 갖춰졌다면 이 순서대로 진행하면 된다. 총 7단계다.

1. 구글 플레이 콘솔 접속: developer.android.com/ko/console로 접속하거나 ‘구글 플레이 콘솔’로 검색한다. 준비한 구글 계정으로 로그인.
2. 계정 유형 선택: 개인 개발자냐 조직(기업) 개발자냐를 먼저 고른다. 나중에 바꾸기 번거로우니 처음부터 제대로 선택하자.
3. 개발자 계약 동의: 구글 플레이 개발자 배포 계약이다. 그냥 체크하고 넘기는 경우가 많은데, 앱 운영에 직접 영향을 주는 내용이 담겨 있으니 최소한 훑어봐야 한다.
4. 25달러 등록 수수료 결제: 카드 정보 입력 후 결제. 환불은 안 된다. 한 번 내면 끝이다.
5. 계정 정보 입력: 개발자 이름, 연락처 이메일, 전화번호, 주소 등을 입력한다. 기업은 법인명, 사업자 등록 번호까지 필요하다. 스토어에 공개되니 정확하게 입력해야 한다.
6. 본인 확인: 최근 들어 이 단계가 더 엄격해졌다. 운전면허증이나 여권으로 신원 확인을 요구하거나, 추가 서류를 요청하기도 한다. 구글 안내에 따라 순서대로 진행하면 된다.
7. 등록 완료 후 대기: 구글 검토가 필요한 경우가 있다. 이메일로 계정 활성화 안내가 온다. 보통 며칠 내로 처리되는데, 상황에 따라 더 걸리기도 한다.

본인 확인에서 막히는 게 가장 흔한 문제다. 입력 정보와 신분증이 조금이라도 다르면 반려되니 꼼꼼히 확인하자.

25달러로 뭘 얻나

등록비 25달러는 일회성이다. 이후 연회비는 없다. 애플 앱스토어 개발자 프로그램은 매년 99달러를 내야 하니, 구글 플레이 초기 진입 비용은 확연히 낮다.

물론 앱 내 구매(인앱 결제)나 유료 앱 판매 시에는 구글이 수수료를 가져간다. 이건 등록비와 별개다. 25달러는 말 그대로 계정 개설 비용이고, 그 이후 계정 유지에 추가 비용은 없다.

등록 후 앱 출시까지 남은 것들

개발자 계정이 생겼다고 바로 앱이 올라가는 게 아니다. 몇 단계가 더 남아 있다.

• 앱 서명(App Signing): Google Play에서 앱 서명을 관리하도록 설정하는 과정이다. 앱 무결성과 보안에 직결되는 필수 단계다.
• 앱 정책 준수 확인: 개인정보 보호, 콘텐츠 가이드라인, 광고 정책 등을 꼼꼼히 읽어야 한다. 정책 위반으로 앱이 반려되거나 계정이 정지되는 일이 생각보다 자주 있다.
• 테스트 트랙 활용: 내부 테스트, 비공개 테스트, 공개 테스트. 세 단계를 순서대로 활용하면 좋다. 실제 출시 전에 버그를 잡고 피드백을 반영하는 게 평점 관리에 유리하다.
• 스토어 등록 정보 준비: 앱 제목, 짧은 설명, 긴 설명, 스크린샷(폰·태블릿 각각), 기능 그래픽, 아이콘. 이것만 해도 꽤 손이 간다. 잘 써야 다운로드로 이어진다.
• 앱 번들/APK 업로드: 완성된 앱 파일을 플레이 콘솔에 업로드하면 된다.

실수하기 쉬운 포인트들

해보지 않으면 놓치기 쉬운 것들이 있다.

• 정책 변경 알림 확인: 구글은 정책을 수시로 바꾼다. 플레이 콘솔 알림이나 개발자 이메일을 주기적으로 확인하지 않으면 모르는 사이에 위반 상태가 되기도 한다.
• 계정 평판 관리: 사용자 불만이 쌓이거나 정책 위반이 반복되면 계정 자체에 제재가 가해진다. 문제 신고가 들어오면 빠르게 대응하는 게 낫다.
• 보안 업데이트: 안드로이드 OS는 계속 업데이트된다. 구형 API만 지원하는 앱은 보안 문제로 마켓에서 내려갈 여지가 있다. 최소 연 1회는 앱을 점검하자.
• 구글 지원팀 활용: 등록이나 출시 과정에서 막히는 게 생기면 공식 지원팀에 바로 문의하는 게 빠르다. 커뮤니티 포럼보다 공식 채널이 정확하다.

개발자 등록은 관문이지 목적지가 아니다. 이걸 마쳤다고 끝난 게 아니라 이제 시작인 거다. 정책을 지키고, 업데이트를 놓치지 않고, 사용자 피드백에 반응하는 것. 그게 플레이 스토어에서 오래 살아남는 방법이다.

출처: Reddit r/technology

앱을 하나 팔면 30%는 애플이나 구글 몫이다. 개발자가 1,000원짜리 앱을 팔면 손에 쥐는 건 700원. 인앱 결제가 붙은 게임이라면 유저가 쓰는 돈의 30%가 개발사가 아닌 플랫폼으로 간다. 이 구조가 10년 넘게 거의 그대로다. 왜 바뀌지 않는지, 그리고 정말 바뀔 수 있는지 따져보자.

두 회사가 모든 걸 통제하는 구조

모바일 앱 시장은 사실상 애플 iOS와 구글 안드로이드 둘이 나눠 먹는다. 전 세계 스마트폰의 대부분을 이 두 운영체제가 차지하고 있다. 새 앱이 사용자한테 닿으려면 이 두 플랫폼의 앱스토어를 반드시 통과해야 한다. 달리 갈 길이 없다.

• 애플 앱스토어: iOS 기기에서 앱을 설치할 수 있는 유일한 공식 창구다. 보안 검수가 까다롭고 사용자 경험이 일관된다는 건 분명 장점이지만, 개발사 입장에선 통제가 너무 강하다는 불만이 오래됐다. 어떤 기능이 안 된다고 리젝 먹으면 그냥 끝이다.
• 구글 플레이스토어: 안드로이드 주력 배포 채널이다. 애플보다 검수 기준이 유연하긴 한데, 시장 점유율에서 나오는 영향력은 절대 만만하지 않다. 대부분의 안드로이드 사용자가 여기서 앱을 내려받는다.

이 구조에서 개발사는 협상 카드가 별로 없다. 플랫폼이 제시하는 조건을 받아들이거나, 아니면 시장 자체를 포기하거나. 사실상 둘 중 하나다. 대기업도, 스타트업도 이 앞에선 비슷한 처지다.

30%라는 숫자는 어디서 왔나

수수료 30%는 애플이 2008년 앱스토어를 처음 열면서 정한 기준이다. 결제 인프라 구축 비용, 보안 검수, 앱스토어 내 노출 등을 명분으로 시작됐다. 당시엔 그나마 납득이 됐다. 앱 생태계 자체를 새로 만드는 시절이었으니까. 구글도 비슷한 시기에 같은 기준을 따랐다.

문제는 지금이다. 시장 규모가 수십조 원대로 커진 지 한참인데 수수료율은 그대로다. 인프라 비용은 규모의 경제로 단가가 낮아졌는데 수수료 비율은 그대로라는 게 비판의 핵심이다. 2021년 에픽게임즈와 애플 사이에 벌어진 소송이 이 논쟁을 수면 위로 끌어올린 계기였다.

• 개발사 입장: 매출 30%를 고정 비용으로 떼어주다 보니 R&D나 마케팅에 쓸 여력이 줄어든다. 스타트업이나 1인 개발자라면 이게 생존과 직결된다. 손익분기점 계산이 완전히 달라지는 수준이다.
• 소비자 입장: 개발사가 30%를 내면 그 비용이 앱 가격이나 인앱 결제 금액에 녹아든다. 결국 지불하는 건 사용자다. 가격을 직접 올리지 않더라도 기능 축소나 광고 추가로 돌아오는 경우도 있다.

모바일 게임처럼 인앱 결제 비중이 높은 장르가 이 수수료의 최대 피해자다. 애플과 구글 입장에선 최대 수익원이기도 하고. 이해관계가 정반대다.

EU가 판을 흔들기 시작했다: 사이드로딩과 대안 스토어

유럽연합이 2024년부터 디지털 시장법(DMA)을 본격 시행하면서 상황이 달라지기 시작했다. 핵심은 ‘사이드로딩(Sideloading)’ 허용이다. 공식 앱스토어 말고 다른 경로로도 앱을 설치할 수 있도록 대형 플랫폼에 강제하는 것. 애플이 줄곧 막아온 부분이다.

• 사이드로딩의 의미: 앱스토어 검수 없이 웹사이트나 외부 파일로 앱을 직접 설치하는 방식이다. 안드로이드는 예전부터 설정에서 허용 가능했다. iOS는 EU 지역 한정으로 문이 조금씩 열리는 중이다.
• 대안 앱스토어의 등장: 사이드로딩이 열리면 제3의 앱스토어가 치고 들어올 여지가 생긴다. 에픽게임즈 스토어가 iOS 진출을 시도한 게 대표적인 사례다. 낮은 수수료나 독점 콘텐츠를 내세워 경쟁하는 구도가 실제로 가능해진다.
• 보안 문제: 반론도 있다. 공식 검수 없이 설치되는 앱은 악성코드 위험이 커진다. 애플이 사이드로딩에 강하게 반발하는 명분이 바로 이거다. 완전히 틀린 말은 아니다. 안드로이드에서 APK 직접 설치로 인한 피해 사례가 적지 않다는 건 실제 데이터가 뒷받침하는 우려다.

DMA가 가져올 변화가 EU에만 그칠지, 아니면 미국과 아시아 시장에도 도미노처럼 번질지. 지금 업계가 주시하는 지점이 바로 여기다. 캘리포니아에서도 비슷한 법안이 논의됐다가 애플·구글의 강한 로비로 무산된 사례가 있다.

경쟁이 생기면 뭐가 달라지나

수수료 경쟁이 실제로 붙으면 어떻게 될까. 몇 가지 방향으로 정리된다.

• 수수료 인하: 대안 스토어가 15~20% 수수료를 내걸면 애플·구글도 어느 시점엔 반응해야 한다. 이미 연 매출 100만 달러 이하 소규모 개발사 대상으로 15%까지 낮춘 선례가 있다. 경쟁이 심해지면 이 범위가 더 넓어질 여지가 있다.
• 유통 채널 다변화: 소비자 입장에선 앱을 얻는 루트가 늘어난다. 특정 게임을 에픽 스토어에서만 더 싸게 살 수 있다거나, 개발사 직결제로 할인받는 방식이 자리 잡을 수 있다.
• 개발 자유도 증가: 플랫폼의 심사 기준에 맞추느라 기능을 빼거나 수정해야 했던 경우가 적지 않다. 대안 채널이 생기면 그 제약에서 벗어난 실험적인 시도가 나올 여지가 생긴다.

다만 장밋빛 전망만 있는 건 아니다. 앱 생태계가 여러 스토어로 쪼개지면 사용자 입장에선 어디서 뭘 설치해야 할지 오히려 복잡해진다. 보안 검증 기준도 스토어마다 달라지면 신뢰도를 판단하기가 어려워진다. 편의성과 자유도는 트레이드오프 관계다. 이 부분은 솔직히 아직 답이 없다.

결국 어느 방향으로 가나

30%라는 숫자가 어느 날 갑자기 사라지진 않을 거다. 하지만 규제 압박과 경쟁이 맞물리면서 조금씩 균열이 생기고 있다는 건 분명하다. 애플과 구글도 무한정 버티기는 어렵다.

개발자라면 대안 스토어 정책 변화를 주시할 이유가 충분하다. 수수료 몇 퍼센트 차이가 장기적으론 제품 로드맵과 수익 구조 전체를 바꾸는 변수다. 앱을 쓰는 입장에서도 이 구조를 알면 왜 특정 앱이 웹 결제를 유도하는지, 왜 어떤 기능이 iOS에서만 막혀 있는지가 이해된다. 단순히 플랫폼이 못된 게 아니라, 구조가 그렇게 만든 거다.

플랫폼과 개발사, 소비자 사이의 이해관계가 복잡하게 얽힌 문제다. 누구 한 명의 완전한 승리로 끝날 게임이 아니다. 균형점은 규제와 시장이 함께 만들어가는 과정에서 나올 것이다.

출처: Reddit r/technology

팬데믹 이후 직접 목소리로 나누는 대화량이 현저히 줄었다는 연구 결과가 있다. The Verge 보도를 보면, 실제로 사람들이 목소리로 교환하는 단어 수 자체가 줄었다고 한다. 말은 줄었는데 업무는 여전히 돌아간다. 그 공백을 채우는 게 동기(Synchronous)와 비동기(Asynchronous) 커뮤니케이션이다. 두 방식을 상황에 맞게 쓰는 팀과 그렇지 않은 팀의 생산성 격차는 생각보다 크다.

소통 방식의 구조적 변화

전화와 대면 회의 중심이던 시절은 지났다. 이메일, 슬랙, 노션, 지라 같은 도구들이 그 자리를 나눠 갖고 있다. 재택근무와 유연근무가 확산되면서 달라진 건 단순히 장소만이 아니다. 소통의 타이밍 자체가 바뀌었다. 서울과 뉴욕이 한 팀인 환경에서 ‘지금 바로 대화’는 물리적으로 불가능한 경우도 많다.

즉흥적인 복도 대화가 사라진 대신, 메시지 하나에 더 많은 정보를 담아야 하는 부담이 생겼다. 텍스트 한 줄에 뉘앙스를 실어야 하니 쓰는 사람도 읽는 사람도 더 신경 써야 한다. 이 변화가 불편하다면 아직 비동기 문화에 덜 적응된 것일 수 있다. 각자의 역할과 업무 스타일에 맞는 소통 방식을 선택하는 이유가 여기 있다.

비동기 커뮤니케이션: 장점과 한계

비동기는 즉각 반응을 요구하지 않는 방식이다. 편지와 구조가 비슷하다 — 보내고, 상대가 읽고, 답한다. 이메일, 슬랙·팀즈의 비실시간 메시지, 노션·지라 댓글, 구글 독스·컨플루언스 피드백, 사전 녹화 영상이 여기 해당한다.

• 주요 예시: 이메일, 슬랙·팀즈 비실시간 메시지, 노션·지라 댓글, 구글 독스·컨플루언스 피드백, 사전 녹화 영상

비동기 커뮤니케이션의 장점:

• 생각할 시간: 답장 전에 충분히 정리할 여유가 생긴다. 즉흥 대답보다 내용 밀도가 높아지는 건 당연하다. 더 정제되고 정확한 정보가 오간다.
• 기록이 남는다: 모든 대화가 텍스트로 쌓인다. 신규 입사자 온보딩에도 실질적으로 쓸모 있다. ‘그때 뭐라고 했더라’ 할 일이 없어진다.
• 시차 무관: 서울-런던 팀도 아무 문제없이 협업된다. 각자 업무 흐름을 끊지 않고 정보를 주고받는 게 핵심이다.
• 집중력 보호: 즉각 답변 압박이 없다. 알림을 쌓아두고 집중 업무가 끝난 뒤 한꺼번에 처리해도 된다. 흐름이 끊기지 않는다는 게 의외로 크다.

비동기 커뮤니케이션의 단점:

• 급할 때 느리다: 빠른 의사결정이 필요한 순간엔 답답하다. 답변 기다리다 업무가 막히는 상황이 생긴다.
• 오해 발생 가능성: 텍스트엔 표정도 없고 목소리 톤도 없다. 같은 문장이 전혀 다른 의미로 읽힐 여지가 있다.
• 메시지 폭탄: 슬랙 채널에 수백 개 메시지가 쌓이면 중요한 내용을 놓치기 쉽다. 관리 안 하면 정보 사일로로 전락한다.
• 관계 형성엔 약하다: 텍스트만으로는 사람 사이 온도가 잘 안 전해진다.

동기 커뮤니케이션: 장점과 한계

동기는 실시간 상호작용이다. 참여자 모두가 같은 시간에 접속해야 한다. 대면 회의, 전화, 줌·구글 미트 화상회의, 실시간 메신저, 워크숍이 여기 속한다.

• 주요 예시: 대면 회의, 전화, 줌·구글 미트 화상회의, 실시간 메신저, 워크숍

동기 커뮤니케이션의 장점:

• 정보 밀도가 높다: 표정, 목소리 톤, 제스처까지 같이 전달된다. 텍스트로는 못 잡는 뉘앙스를 실시간으로 보정할 수 있다는 게 결정적이다.
• 결정이 빠르다: 복잡한 논의도 30분 화상회의면 정리된다. 이메일 핑퐁으로 열흘 걸릴 것을 한 번에 끝낼 수도 있다.
• 팀 결속: 같이 웃고 같이 고민하는 과정에서 관계가 쌓인다. 원격팀일수록 이 시간이 중요하다.
• 브레인스토밍엔 압도적: 아이디어가 아이디어를 부르는 흐름은 실시간 대화에서 나온다. 텍스트 채팅으로는 그 속도가 안 나온다.

동기 커뮤니케이션의 단점:

• 시간이 고정된다: 모두가 같은 시간에 맞춰야 한다. 글로벌 팀이면 누군가는 새벽에 접속해야 하는 구조다.
• 집중력 소모: 관련 없는 논의가 길어지면 참석자들은 조용히 다른 창을 열기 시작한다. 이미 다들 경험해봤을 거다.
• 회의 피로: 하루 5개 회의면 정작 실무할 시간이 없다. 잦은 회의는 생산성을 갉아먹는다.
• 기록이 없다: 녹화나 회의록이 없으면 말한 내용이 전부 사라진다. ‘아까 뭐라고 했죠?’ 상황이 반복된다.

상황별 선택 기준

둘 중 하나가 무조건 낫다는 건 없다. 상황마다 다르다. 판단 기준은 단순하다 — 즉각성이 필요한가, 기록이 중요한가, 감정적 뉘앙스가 전달돼야 하는가.

• 비동기가 맞는 상황:
  • 공지·보고·업데이트: 팀 전체 공지, 주간 진행 보고, 프로젝트 현황 공유.
  • 아이디어 제안·피드백 요청: 초안에 대한 상세 코멘트가 필요할 때. 즉흥 반응보다 숙고된 의견이 필요한 경우.
  • 복잡한 논의: 각자 충분히 생각하고 논리적으로 답변해야 하는 주제.
  • 기록이 필수인 경우: 의사결정, 정책 변경, 업무 절차. 나중에 ‘그렇게 정했어?’ 소리 안 나오려면 텍스트로 남겨야 한다.
• 동기가 맞는 상황:
  • 긴급 대응: 예상 밖의 문제가 터졌을 때. 이메일 핑퐁하다 타이밍 놓치면 안 된다.
  • 브레인스토밍: 아이디어를 자유롭게 쏟아내야 할 때. 텍스트 채팅으로는 흐름이 안 산다.
  • 민감한 논의·갈등 중재: 오해의 소지가 크거나 감정 개입이 필요한 상황. 텍스트로 해결하려다 더 꼬이는 경우가 많다.
  • 교육·트레이닝: 실시간 질의응답이 필요한 복잡한 내용 전달.
  • 팀 빌딩: 신규 멤버 합류, 원격팀이 오프라인 감각을 유지해야 할 때.

실용적인 조합 방법이 있다. 동기 회의 전에 비동기로 아젠다와 자료를 먼저 공유한다. 그러면 회의 당일 ‘이게 뭐예요?’ 질문이 확 준다. 회의 후에는 논의 내용을 비동기로 요약·공유. 동기의 속도와 비동기의 기록 보존을 동시에 잡는 방법이다.

비동기, 잘 쓰는 방법

• 두괄식으로 써라: 결론을 첫 줄에. 바쁜 사람이 끝까지 읽을 거라 기대하면 안 된다.
• 데드라인을 구체적으로: ‘언제까지 회신 주시면 감사하겠습니다’가 아니라 ‘6월 10일 오전까지 확인 부탁드립니다’처럼. 모호하면 아무도 안 지킨다.
• 툴을 목적에 맞게: 긴급하지 않은 공유는 이메일, 팀 내 간단한 소통은 메신저, 프로젝트 추적은 지라·노션. 슬랙에 모든 걸 때려넣으면 노이즈만 늘어난다.
• 중요 결정은 문서화: 구두로 정한 건 사실상 없는 거다. 공유 문서에 링크로 박아두는 습관이 필요하다.
• 알림 관리: 모든 알림을 실시간 처리하려 하지 마라. 중요도에 따라 슬랙 알림을 끄거나 방해 금지 시간을 설정하면 집중 시간이 생긴다.

회의를 살리는 방법

• 목표를 먼저 정해라: ‘이 회의 끝나면 뭐가 결정돼 있어야 하나?’ 이 질문에 답 못하면 회의 잡지 않는 게 낫다.
• 사전 자료 공유: 아젠다와 관련 문서는 최소 24시간 전에. 회의 직전에 올리면 읽어오는 사람이 없다.
• 시간 엄수: 정시 시작, 정시 종료. 오버하면 다음 회의에 아무도 집중 못한다.
• 액션 아이템 정리: ‘누가, 무엇을, 언제까지’가 회의의 결과물이다. 이게 없으면 회의한 게 아니다.
• 회의를 줄여라: 이 논의가 정말 동기 방식이어야 하는지 다시 물어봐라. 슬랙 스레드나 공유 문서로 해결되는 거라면 회의를 없애는 게 맞다.

두 방식을 섞어야 이긴다

동기와 비동기는 경쟁 관계가 아니다. 보완 관계다. 두 방식의 특성을 이해하고 맥락에 맞게 선택하는 것이 생산성을 가른다. 툴이 문제가 아니다. 슬랙이 있든 이메일만 있든, 결국 어떻게 쓰느냐의 문제다.

빠른 판단이 필요하면 동기, 깊은 사고와 기록이 필요하면 비동기. 이 둘을 상황에 맞게 조합하는 팀이 더 빠르게, 더 적은 마찰로 일을 끝낸다. 소통은 많이 하는 게 아니라 잘 하는 거다.

출처: The Verge