블루스카이는 왜 스크린샷에만 로고를 그릴까

스마트폰으로 마음에 드는 게시물을 캡처해 본 사람이라면 한 번쯤 겪었을 법한 장면이 있다. 앱 화면에서는 분명 '팔로우' 버튼이 있던 자리에, 스크린샷을 찍고 나면 그 앱의 로고가 찍혀 있는 것이다. 한 개발자가 블루스카이(Bluesky)에서 바로 이 현상을 발견하고 그 원리를 추적한 글이 화제가 됐다. 앱을 사용할 때는 게시물 우측에 '팔로우' 버튼만 보이는데, 캡처된 이미지에서는 그 자리에 블루스카이의 나비 로고가 나타나 있었다. 눈으로 볼 때는 없던 것이 스크린샷에만 등장하는 셈이다.

아이폰 캡처가 로고를 불러내는 원리

글쓴이는 처음에 아이폰의 노치 영역에 로고를 숨겨 두는 흔한 기법을 떠올렸지만, 여기서는 로고가 화면에 훤히 드러나는 자리에 있었기에 설명이 되지 않았다. 앱을 전환하는 도중에 캡처를 시도해 봐도 결과가 달랐다. 결국 블루스카이가 오픈소스라는 점을 이용해 코드를 직접 열어보면서 답을 찾았다. 문제의 로직은 2026년 1월 mozzius라는 개발자가 추가한 GrowthHack.tsx 파일에 있었고, 실제 동작은 같은 사람이 만든 expo-privacy-sensitive라는 패키지에 담겨 있었다.

이 패키지는 iOS의 UITextField를 활용한다. isSecureTextEntry 속성을 켠 텍스트 입력 필드를 만든 뒤, 실제로 보여줄 콘텐츠, 즉 '팔로우' 버튼을 그 필드의 레이어에 그려 넣는다. isSecureTextEntry는 원래 비밀번호처럼 민감한 입력을 가리기 위한 속성이다. 사용자가 스크린샷을 찍는 순간 iOS는 이 보안 텍스트 필드의 레이어를 비워 버리는데, 이때 위에 얹혀 있던 버튼이 사라지고 그 밑에 계속 자리 잡고 있던 블루스카이 로고가 드러난다. 로고는 처음부터 그 자리에 있었지만 버튼에 가려져 보이지 않았을 뿐이다. iOS가 아닌 다른 플랫폼에서는 이런 가리기 없이 콘텐츠를 그대로 렌더링한다.

앱 전환 중에는 이 마술이 통하지 않았던 이유도 같은 맥락에서 설명된다. 글쓴이의 추정에 따르면, iOS는 앱 전환 제스처가 시작될 때 자체적으로 화면 스냅샷을 뜨는데 이 과정에서는 레이어 비우기가 발동하지 않는다. 그 뒤에 캡처를 해도 반응할 살아 있는 UITextField 인스턴스가 없고, 이미 굳어 버린 스냅샷만 남아 있어서 버튼이 그대로 찍힌다는 것이다. 다만 글쓴이 본인이 iOS 개발자가 아니라는 점은 여러 차례 스스로 밝히고 있어, 이 부분은 확정된 설명이라기보다 합리적 추론에 가깝다.

프라이버시 API의 용도를 벗어난 활용

실무 관점에서 흥미로운 지점은 이 기법이 새로 발명된 것이 아니라는 데 있다. 보안 텍스트 필드가 스크린샷에서 가려진다는 특성은 이미 잘 알려진 동작으로, 텔레그램은 '비밀 대화'에, 시그널도 비슷한 방식으로 이를 사용해 왔다. 프라이버시를 지키려는 앱들이 화면 캡처로부터 내용을 감추기 위해 쓰던 메커니즘을, 블루스카이는 정반대로 캡처 시점에만 로고를 노출시키는 마케팅 용도로 뒤집어 쓴 셈이다. 이렇게 널리 활용되는 동작이다 보니 애플이 조만간 이를 막을 가능성은 낮다고 글쓴이는 봤다.

한국의 앱 개발자나 서비스 기획자 입장에서 이 사례는 두 가지를 시사한다. 하나는 캡처 이미지가 외부로 공유될 때 브랜드 로고나 출처 워터마크를 자연스럽게 붙이는 실용적 방법이 존재한다는 점이다. 평소 UI는 깔끔하게 유지하면서 스크린샷에만 로고를 심으면, 사용성을 해치지 않고도 콘텐츠가 퍼질 때 출처를 남길 수 있다. 다른 하나는 이것이 특정 OS의 내부 동작에 의존하는 기법이라는 한계다. iOS 전용이라 다른 플랫폼에서는 재현되지 않고, 애플이 언젠가 동작 방식을 바꾸면 무력화될 수 있으며 표준적으로 보장된 인터페이스가 아니다.

또한 이 방식이 원래 프라이버시 보호를 위해 설계된 API를 홍보 목적으로 전용한다는 점에서 평가가 엇갈린다. 실제로 이 기능을 추가한 개발 스레드에서도 참여자 다수가 부정적 반응을 보였고, 논의는 잠긴 채로 마무리됐다. 글쓴이 자신은 '귀엽다'는 정도로 가볍게 받아들였지만, 민감 정보 보호용 메커니즘을 성장 해킹 수단으로 쓰는 것이 적절한지에 대한 판단은 결국 각 팀의 몫으로 남는다. 기술적으로 영리하다는 사실과 API의 취지에 부합하는가라는 물음은 별개이기 때문이다.