Chiko IT
AI & Machine Learning

폰에서 떼어내는 스타트업 러시 — together tech 웨이브 뭐길래

Chiko
18min read

목차

java.lang.SecurityException: Permission Denial: getUsageStats from 
  pid=14782, uid=10247 requires android.permission.PACKAGE_USAGE_STATS
  at android.os.Parcel.createExceptionOrNull(Parcel.java:3057)
  at android.os.Parcel.createException(Parcel.java:3037)
  at android.app.usage.UsageStatsManager.queryUsageStats(...)

Google Play Pre-launch report:
  > "PACKAGE_USAGE_STATS는 시스템/사전 설치 앱에만 허용된다"
  > Submission: REJECTED
  > Policy reference: Restricted permissions / device admin

그러나, 본인 폰 사용 시간 추적해서 일정 시간 넘으면 알림 보내는 작은 사이드 프로젝트를 만들려고 했다. 프론트엔드 2년 하고 백엔드로 넘어온 지 2년차, 모처럼 클라이언트 쪽으로 다시 와본 거였다. React Native + Kotlin 모듈로 안드로이드 빌드까지 올렸다. 그런데 Play Console 사전 리뷰가 위 메시지를 던졌다. 권한이 "고위험"으로 분류되어 일반 개발자 계정으로는 못 받는다는 거다. iOS는 더 막혀 있다. Screen Time API는 패밀리 셰어링 컨텍스트의 보호자용으로 제한되어 있고, 일반 앱에서 본인 사용 통계를 가져오는 건 사실상 불가능에 가깝다.

OS가 "앱이 앱을 통제하는 것"을 점점 봉쇄하는 중이다. 보안과 광고 ID 정책이 강화되며 그 흐름은 가속됐다. 그러다 보니 도서관에 보안 책 깔리듯, 하드웨어로 같은 문제를 푸는 스타트업이 줄줄이 등장했다. 외신에선 이걸 묶어 together tech라 부른다. 사람을 화면에서 떼어내고, 결과적으로 옆사람과 다시 같은 자리에 두는 기술이라는 의미다. 작성 시점(2026년 6월) 기준으로 가장 눈에 띄는 흐름을 백엔드 관점으로 풀어본다.

OS가 막아놓은 길 — Screen Time API를 파다 만난 벽

먼저 이 흐름이 왜 하드웨어로 회귀했는지부터 봐야 한다. 사실 "폰 덜 보게 하는 앱"은 새롭지 않다. Forest, Opal, One Sec, AppBlock 같은 앱이 수년 전부터 있었다. 그런데 이 앱들이 점점 무력해지는 중이다.

iOS Screen Time API의 제약

예를 들어, Apple이 2021년 WWDC에서 Screen Time API(FamilyControls, ManagedSettings, DeviceActivity)를 공개했다. 이게 처음 나왔을 때 분위기는 "드디어 본인 사용도 통제할 수 있겠다"였다. 막상 써보면 사용 컨텍스트가 좁다.

FamilyControls.AuthorizationCenter는 두 가지 모드를 가진다. .individual과 .child. 개인 모드는 본인 통제용이지만 가져올 수 있는 데이터가 제한적이다. 정확한 사용 시간을 분 단위로 뽑는 건 아동 보호자 컨텍스트에서만 의미 있게 동작한다. 즉 본인 정신 차리려고 만든 앱이 "패밀리 셰어링에 아이로 등록해라" 같은 요구를 하게 된다. 사용자 입장에선 우스꽝스럽다.

Opal 같은 서비스는 이 제약을 우회하려고 VPN/DNS 차단을 결합해서 푸쉬 알림 자체를 끊거나, Screen Time의 일부 API를 부분적으로 쓴다. 다만 정상적으로 작동시키려면 VPN 프로파일을 설치해야 하고, 실제 사용자 후기를 보면 iOS 메이저 업데이트마다 깨지는 경우가 적지 않다(예: iOS 17.4 → 17.5 사이 일부 차단 우회 동작이 차단됐다는 사용자 보고가 다수).

Android UsageStats — Play 정책이 갈수록 빡빡해진다

안드로이드는 한때 더 자유로웠다. PACKAGE_USAGE_STATS만 받으면 앱별 사용 시간을 정확히 가져올 수 있었다. 그런데 Google Play가 2022년부터 "민감 권한 + 접근성 권한 오남용 금지" 정책을 단계적으로 강화했다(Google Play Developer Program Policies, 2023-05 업데이트 기준).

핵심은 두 가지다. 접근성 서비스를 사용 통제 목적으로 쓰는 건 정책 위반이다. 그리고 PACKAGE_USAGE_STATS는 정당한 사유를 증명해야 한다. 부모 통제 앱이라면 통과되지만, "본인 사용 줄이기"는 사유로 약하다는 게 리뷰의 일관된 반응이다. 본인이 받은 거절 사유도 그거였다.

또한, 여기서 흥미로운 비대칭이 생긴다. 폰을 통제하는 책임은 OS에 있고, OS는 그 책임을 외부 앱에 거의 위임하지 않는다. 그렇다고 OS 자체가 강력한 디지털 디톡스 기능을 내놓는 것도 아니다. iOS Focus 모드와 안드로이드 Digital Wellbeing은 둘 다 "다시 켜기 버튼"이 두 번 클릭이면 끝난다. 의지에 의존하는 설계다.

소프트웨어로는 갈 길이 막혔다. 그러면 답은 하나로 줄어든다. 의지가 약한 순간에 물리적으로 차단되는 무언가가 옆에 있어야 한다.

Brick — NFC 태그 한 장이 만든 흐름

Brick은 가장 단순한 형태로 이 문제를 푼다. 네모난 NFC 태그 한 장과 앱의 조합이다. 작동 흐름은 이렇다.

  1. 앱에서 "차단할 앱 묶음"을 정한다(인스타, 틱톡, 메일 등).
  2. NFC 태그를 폰에 대면 잠금이 활성화된다.
  3. 풀려면 다시 NFC 태그에 폰을 대야 한다.

핵심은 태그를 집에 두고 나가는 거다. 밖에 있는 동안엔 풀 수가 없다. 의지의 문제를 거리의 문제로 바꿔놓는 트릭이다.

기술적으로 보면 별 게 없다. 안드로이드는 NFC 읽기 권한과 Brick 자체가 들고 있는 사용자 매개 차단 기능을 결합한다(앱 자체가 접근성 권한 우회를 안 쓰고, OS가 허용한 범위 안에서 차단 UX를 만든다). iOS는 더 까다롭다. Brick은 iOS에서 Screen Time API와 NFC 트리거를 묶는 방식으로 풀었다. 정확히는 NFC가 일종의 "다시 푸는 잠금장치" 역할을 하고, 차단 자체는 Screen Time이 한다. 둘을 인위적으로 묶어 "물리적 잠금장치 비유"를 완성한 거다.

비즈니스 모델도 단순하다. 하드웨어 단가 + 앱 구독 일부의 조합이다. 작성 시점 기준 Brick은 $59 전후의 일회성 구매와 추가 기능에 대한 소액 구독을 섞고 있다(공식 사이트 getbrick.app, 2026-06 확인). 회사 입장에서는 NFC 태그 하나가 진입 장벽이자 락인이 된다. 사용자가 한 번 구매하면 그 태그가 일상 의식의 일부가 된다. 이게 의외로 강력한 리텐션 장치다.

왜 이 단순한 게 먹혔나

이전 세대의 "폰 사용 줄이기 앱"들은 한 가지를 못 풀었다. 풀고 싶을 때 5초 만에 풀린다는 문제다. Brick은 그걸 "집에 두고 온 NFC 태그"로 풀었다. 의지의 문제를 거리의 문제로 변환하는 것이 본질이다.

물론, 프론트엔드 만들다 백엔드로 넘어와서 가장 자주 들은 말이 있다. "상태를 옮길 수 있으면 옮겨라. 클라이언트에서 처리하지 말고, 서버로." Brick은 그 발상을 사람에게 적용한 셈이다. 의지를 디바이스 안에 두지 말고, 다른 물리적 공간으로 옮겨라. 백엔드 패턴 같은 게 행동 디자인에서도 통한다는 점이 묘하게 인상적이다.

Light Phone III — e-ink 폰의 두 번째 시도

실제로, Light Phone은 이 분야의 고전이다. 2015년 첫 모델, 2018년 Light Phone II, 그리고 2024년 말 공개된 Light Phone III(thelightphone.com, 2024-12 announcement)가 최신이다. III에서 가장 큰 변화는 디스플레이다. 이전까지는 e-ink 흑백이었는데, III는 그레이스케일 OLED를 채택했다. 가독성을 위해 OLED를 e-ink처럼 보이게 튜닝한 거다.

따라서, 가격은 사전 주문 기준 $799선이다(2024-12 공지, 작성 시점 기준 일부 지역 한정 판매). 비싸다. 그런데 이 비싼 가격이 의외로 이 회사의 전략이다.

의도된 불편함은 가격으로 정당화된다

특히, Light Phone은 인스타그램, 트위터, 브라우저, 앱스토어가 없다. 카메라, 전화, 문자, 음악, 지도, 알람, 계산기, 메모. 그게 전부다. 이메일도 모델 II에서 추가됐다가 III에선 일부 기능이 빠졌다. 이걸 $800에 판다.

물론, 비싸야 자기 강제력이 생긴다는 논리다. 보조금 받아서 무료로 받는 폰이라면 1주일 쓰고 책상 서랍으로 들어간다. $800짜리 폰은 다르다. 본인이 결정해서 큰돈을 썼기 때문에 라이프스타일 변화의 일부로 굳어진다.

특히, 기술적으로는 Android Open Source Project(AOSP) 위에 자체 OS LightOS를 올렸다. 구글 서비스(GMS)가 빠져 있다. 푸쉬 알림은 자체 서버를 통해 전달되고, 앱 생태계는 의도적으로 닫혀 있다. 백엔드 개발자 입장에서 보면 이건 사실 자체 인프라 비용이 꽤 드는 선택이다. FCM 안 쓰고 자체 푸쉬를 굴리려면 글로벌 메시지 큐와 데드 레티어 다 직접 운영해야 한다.

한계는 명확하다

또한, Light Phone III를 쓰면 카카오톡이 안 된다. 한국 사용자에겐 치명적이다. 회사 단톡, 가족 단톡 다 끊긴다. 이걸 받아들일 수 있는 사람은 라이프스타일을 통째로 재구성할 의지가 있는 사람뿐이다. 그래서 시장 규모 자체가 작다.

반면, 다만 흥미로운 건, 회사가 이 작은 시장을 의도적으로 노린다는 점이다. 보편적 기술이 아니라 "선택한 사람들의 도구"라는 포지셔닝을 유지한다. 비즈니스 모델은 하드웨어 마진 + 일부 통신/푸쉬 서비스 운영비를 사용자에게 전가하는 형태다. 작성 시점에 공개된 정보만 보면 통신 요금은 별도이고, 디바이스는 일회성 결제다.

Daylight DC-1 — 같은 흐름이 노트북까지 확장됐다

반면, Daylight Computer는 폰이 아니라 태블릿/노트북 영역에서 비슷한 베팅을 한다. DC-1이라는 e-paper 비슷한 LCD 패널을 채택한 안드로이드 태블릿이다. 60Hz로 흑백 표시가 가능하고, 백라이트가 별도(주황색 호박 톤)다. 가격은 약 $729선이다(daylightcomputer.com, 2026-06 확인 기준, 재고 변동 있음).

여기서 핵심은 "주의력 보존"이다. 푸른빛 LED 백라이트가 멜라토닌 분비를 억제한다는 연구가 있는데, 이건 학계에서도 이견이 있는 영역이다. 물론 Daylight는 그 논쟁과 별개로 "글 쓰고 책 읽기에 최적화된 디바이스"라는 포지션을 잡았다. 안드로이드 위에 올라가서 Kindle 앱, 일반 노트 앱, 글쓰기 앱이 다 돈다. e-ink만큼 리프레시가 느리지도 않다.

:::stats

  • Brick: $59 전후 (NFC 태그 + 앱, 2024년 출시)
  • Light Phone III: $799 사전 주문가 (2024-12 공지)
  • Daylight DC-1: $729 (2026-06 기준, 일부 지역 한정)
  • Boox Palma 2: $299 (e-ink 안드로이드 폰형 디바이스, 비교 참고용) :::

DC-1을 폰 대체재로 보면 안 된다. SIM 슬롯이 있긴 하지만, 주 용도는 "노트북 옆에 두고 깊은 작업할 때 쓰는 두 번째 화면"에 가깝다. 그래서 이 카테고리 자체가 "폰 사용 줄이기"보다 더 넓은 "디지털 환경 재구성"으로 확장된다. together tech가 단순히 폰 끊기가 아니라는 첫 번째 단서다.

AI 펜던트와 미니멀 디바이스의 미묘한 위치

따라서, 여기서 분기점이 갈린다. AI 펜던트류(Humane Ai Pin, Rabbit R1, Friend, Plaud NotePin)는 "폰을 떼게 한다"는 약속으로 시작했다가 대부분 실패했거나 방향을 틀었다.

그런데, Humane Ai Pin은 사실상 단종 경로로 갔다(2025년 초 HP가 일부 자산 인수, 서비스 종료 발표). Rabbit R1은 출시 직후 "R1이 하는 일은 안드로이드 앱 하나로 가능하다"는 분석이 돌면서 평판에 큰 타격을 입었다. 둘 다 폰을 대체하겠다는 야심에 실패했다. 이유는 단순하다. AI가 폰 안에 들어와 있는 한, 외부 디바이스가 폰을 대체할 이유가 없다.

살아남은 부류는 다르다. 대체가 아니라 보완을 노린다. Plaud NotePin은 회의 녹음과 요약에 특화된 클립형 디바이스다. 폰을 안 보게 하지만, 폰 없이 살게 하지는 않는다. Friend는 SNS 친구 흉내 내는 AI 펜던트인데, 이건 사회적 결핍을 "AI 친구"로 메우는 방향이라 together tech 흐름과는 정확히 반대다. 모두 다 같은 카테고리로 묶기 어렵다.

백엔드 관점에서 본 차이

AI 펜던트는 대부분 API 의존도가 높다. OpenAI나 Anthropic의 LLM API를 호출하고, STT/TTS를 클라우드로 돌린다. 한 사용자당 월 추론 비용이 무시할 수 없는 규모로 쌓인다. 그래서 비즈니스 모델이 디바이스 일회성 결제 + 월 구독 구조가 된다.

반면 Brick, Light Phone, Daylight는 추론 비용이 거의 없다. 푸쉬 인프라, 약간의 펌웨어 업데이트 서버, 결제 게이트웨이 정도다. 같은 "폰에서 떼어내는" 명목 아래에서도 백엔드 부담이 완전히 다르다. AI 펜던트는 클라우드 비용이 무거워서 구독 의존도가 높고, 그래서 회사가 망하면 디바이스가 벽돌이 된다(Humane이 정확히 그 케이스다). 미니멀 디바이스는 회사가 망해도 폰처럼 기본 기능은 작동한다.

이 차이는 사용자에게 "산 디바이스가 얼마나 오래 살아남느냐"의 차이로 직결된다. together tech가 의외로 안정적인 카테고리로 굳어지는 이유 중 하나다.

Together Tech가 진짜 노리는 것

이 흐름을 "디지털 디톡스"로만 보면 본질을 놓친다. 흥미로운 건 이 디바이스들의 마케팅 워딩이다. 거의 공통적으로 "함께 있을 때 함께 있어라(be where you are)" 류의 메시지를 쓴다.

반면, 미국 일부 도시에서 식당이 "폰 없는 자리"를 운영하기 시작했다. 입구에서 Yondr 같은 파우치에 폰을 넣어두고 자리에 앉는 방식이다. 학교 단위로 폰 금지 정책을 도입한 국가들도 있다(영국, 프랑스 일부 지역, 호주의 청소년 SNS 규제 등). 이런 사회적 분위기가 하드웨어 스타트업에 마중물이 되고 있다.

핵심은 단순히 화면을 덜 보는 게 아니다. 같은 공간의 사람과 다시 시선을 맞추는 행위다. 그래서 "together"라는 단어가 붙는다. 이게 단순 디톡스 흐름과 갈라지는 지점이다.

백엔드 입장에서 보이는 비즈니스 기회

물론, 이 흐름이 굳어지면, 백엔드 개발자에게도 일감이 생긴다. 단순한 푸쉬 인프라가 아니라, "사용자 상태를 모임 컨텍스트와 결합하는" 백엔드가 필요해진다.

예를 들어 이런 거다. 친구 셋이 식당에 모인다. 모두 Brick류 디바이스를 들고 있다. 셋이 같은 자리에 있는 동안 자동으로 서로의 폰 잠금이 활성화되고, 한 명이 자리를 뜨면 풀린다. 이런 "그룹 잠금" 기능은 작성 시점 기준 아직 보편적이지 않다. 물론 흐름상 등장할 가능성이 높다.

이런 기능의 백엔드는 단순하지 않다. 위치 동의, 그룹 멤버십, 잠금 상태 동기화, 오프라인 상태 처리, 누가 누구에게 권한을 부여했는지 감사 로그까지 다 필요하다. 일종의 작은 분산 락 매니저를 사용자 사이에 둔다고 보면 된다. 백엔드 관점에서 이 카테고리가 흥미로운 이유다. 단순한 d2c 하드웨어가 아니라, 사회적 상태를 다루는 백엔드를 요구하는 영역으로 진화 중이다.

비즈니스 모델 — 구독이 아니라 하드웨어가 돌아왔다

지난 10년의 소비자 IT는 거의 다 구독으로 갔다. 음악, 영상, 생산성, 폰트, 클라우드 스토리지. 그런데 together tech 영역은 정확히 반대 방향으로 간다. 하드웨어를 한 번 비싸게 팔고, 부속 서비스에서 소액을 받는다.

카테고리 진입 가격 구독 (월) 의존성 회사 망하면
Brick류 NFC $50~$80 없음 또는 $3~5 낮음 거의 그대로 작동
Light Phone III $799 통신요금 별도 자체 푸쉬 서버 일부 기능 제약
AI 펜던트 $100~$700 $10~30 클라우드 LLM 필수 벽돌화

반면, 이 표를 보면 베팅의 방향이 보인다. together tech의 진짜 베팅은 "사용자 신뢰는 한 번 결제로 끝나는 디바이스에 더 많이 쌓인다"는 가설이다. 매달 결제 거는 구독 디바이스는 회사 사정에 사용자 가치가 묶인다. 하드웨어 일회성 결제는 그 의존을 끊는다.

특히 Humane이 망한 이후로 시장 인식이 변했다. "이 회사가 1년 뒤에도 있을까?"라는 질문이 모든 디바이스 구매에 따라붙는다. 그래서 클라우드 의존이 낮은 디바이스가 상대적으로 안전 자산으로 보이게 됐다. Brick과 Light Phone이 보수적으로 보이는 게 오히려 강점인 시점이다.

백엔드의 역할이 줄어드는 게 아니라 바뀐다

이 흐름이 백엔드 일자리 줄인다는 의미는 아니다. 오히려 백엔드의 역할이 바뀐다. "사용자 행동을 추적하고 광고로 환산하는 백엔드"에서 "사용자 의도를 보존하고 결제 흐름을 안정시키는 백엔드"로. 추론 호출이 줄어드는 대신, 결제 게이트웨이 안정성, 펌웨어 OTA 신뢰성, 디바이스 분실/해지 흐름의 견고함이 중요해진다.

프론트엔드에서 넘어와서 처음엔 백엔드의 매력을 못 느꼈다. UI 만들 때처럼 시각적 결과물이 안 나오니 지루했다. 그런데 이런 카테고리 들여다보면 백엔드가 비즈니스 모델 그 자체로 보인다. 어떤 백엔드를 짜느냐가 회사가 1년 뒤에 살아 있느냐를 결정하는 영역에 가까워졌다. 전환한 게 늦지 않았다는 안도감이 든다.

직접 만들어보려면 어떤 스택이 현실적인가

물론, 본인 사용 통제 앱이 Play Store에서 막혔다고 했는데, 이걸 우회하는 방법이 아예 없는 건 아니다. 합법적인 경로로 정리하면 이렇다.

// 1) 디지털 웰빙 API 사용 (사전 등록된 권한 범주 안에서)
val usageStatsManager = getSystemService(Context.USAGE_STATS_SERVICE) 
    as UsageStatsManager

// 사용자가 설정에서 직접 권한 허용한 경우에만 동작
val stats = usageStatsManager.queryUsageStats(
    UsageStatsManager.INTERVAL_DAILY,
    startTime,
    endTime
)

// 2) 사용자가 직접 권한을 켜도록 설정 화면으로 보낸다
if (!hasUsageStatsPermission()) {
    startActivity(Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS))
}

물론, 이렇게 가면 Play Store 리뷰 통과는 가능하다. 단 사용자가 매번 설정 → 사용 정보 접근 → 본인 앱 토글을 직접 켜야 한다. UX가 무너진다. Brick이 NFC 태그라는 우회로를 만든 이유가 정확히 여기에 있다. 권한을 우회하지 말고, 권한이 닿지 않는 물리적 트리거를 만들어버린 거다.

반면, 사이드 프로젝트로 비슷한 걸 만들어볼 생각이라면 두 가지 경로가 현실적이다.

  1. AOSP 기반 커스텀 ROM: 본인이 직접 OS 빌드해서 폰에 올린다. 학습용으로는 좋지만 일반 사용자에게 배포는 불가능에 가깝다.
  2. 하드웨어 사이드킥: NFC 태그, 블루투스 비콘, ESP32 같은 작은 디바이스를 트리거로 쓴다. 앱은 OS가 허용하는 범위 안에서만 차단하고, 트리거를 외부 디바이스로 분리한다. Brick이 정확히 이 패턴이다.

ESP32 + BLE 비콘으로 단순한 "거리 기반 잠금" 프로토타입을 만들면 한 주말 안에 동작 데모는 나온다. 의지 문제를 거리 문제로 옮기는 그 트릭을 직접 검증해볼 수 있다. 현재 본인은 이 두 번째 경로로 ESP32 보드 한 장을 받아둔 상태로 진행 중이다. 다음 주말에 BLE 비콘 신호 강도(RSSI)로 잠금 트리거 거는 데모를 일단 굴려볼 작정이다.

게다가, 참고 자료로 Google Play의 권한 정책 문서(Restricted Permissions, 2024-Q4 업데이트)와 Apple의 Screen Time API 문서(WWDC21 Session 10123, 이후 iOS 17/18에서 일부 갱신)는 한 번씩 훑어두면 이 카테고리의 한계가 왜 OS에서 비롯되는지 더 명확히 보인다. 백엔드 개발자라도 클라이언트 측 제약을 알고 있으면 서버 설계 방향이 달라진다. 사용자가 어떤 데이터를 줄 수 있고 줄 수 없는지가 결국 어떤 인증/동의 흐름을 짤지를 결정하기 때문이다.

관련 글

More posts