AI를 이용한 개발이 빨라졌습니다. 무언가를 설명하면 페이지, 대시보드, 작은 내부 보고서 또는 고객 대상 마이크로사이트가 만들어집니다. 그런데 까다로운 부분이 다음 단계입니다. 정확히 세 명의 사람만 이 결과물을 봐야 하는데, 우리가 만든 것을 공유하는 기본 방식은 링크를 얻는 모든 사람이 열어볼 수 있는 공개 URL입니다.

랜딩 페이지에는 괜찮습니다. 하지만 고객의 숫자, 미공개 기능, 두 명의 동료가 읽기를 원하는 초안 같은 경우에는 잘못된 기본 방식입니다. 저는 Thryvate를 만들면서 이 문제를 계속 겪었고 (고지: 이것은 제 것이며, 피치가 아닌 빌드 로그입니다), 접근 모델이 가장 어렵고 흥미로운 부분이었습니다. 제가 결론 내린 부분과 그 배경의 트레이드오프(tradeoffs)는 다음과 같습니다.

누구나 열 수 있는 링크의 문제점

파일을 받아 공개 URL을 제공하는 데 탁월한 '붙여넣기-링크 호스팅' 서비스들(Tiiny.host, Static.app, Netlify Drop 등)은 한 가지 일에 좋습니다. 하지만 '공개 URL'이라는 것은 조용히 세 가지를 결정합니다.

1. 링크만 있으면 누구나 접근할 수 있습니다. 한번 전달하면 게스트 리스트가 사라집니다.
2. 누가 실제로 열었는지 알 수 없고, 단지 '누군가' 열었다는 것만 알 수 있습니다.
3. 검색 엔진과 링크 펼치기 서비스(link unfurlers)가 도달할 수 있으므로, '비공개(unlisted)'라는 것은 '개인적(private)'이 아닙니다.

많은 AI 기반 아티팩트들은 그 자체가 모두를 위한 것이 아니라는 점에 핵심이 있습니다. 모든 뷰어를 동일하게 취급하는 URL로는 '이 사람들만, 다른 누구는 안 돼'라는 것을 표현할 수 없습니다. 따라서 모델은 무언가를 보여주기 전에 뷰어의 신원을 알아야 합니다.

제가 정착한 모델: 바이트가 로드되기 전에 검증하기

제가 지키기로 한 규칙은 말하기는 간단하지만 구축하기는 까다롭습니다. 뷰어가 자신의 신분을 증명할 때까지 콘텐츠를 렌더링하지 않는 것입니다. 구체적으로, 비공개 사이트는 다음과 같이 작동합니다:

• 뷰어가 접속하면 콘텐츠가 아니라 이메일 인증 단계가 나타납니다.
• 이메일을 입력하고 링크를 클릭해야만 페이지가 로드됩니다.
• 그들의 이메일은 소유자가 통제하는 허용 목록(allowlist)과 대조하여 확인합니다. 목록에 없으면, 접근할 수 없습니다.

가장 중요한 단어는 '전에(before)'입니다. 렌더링 후에 검증하는 것은 페이지를 로드하고 탭을 닫는 모든 사람에게 콘텐츠를 유출하기 때문입니다. 렌더링 전에 검증한다는 것은 목록에 없는 사람에게 바이트가 서버를 떠나지 않는다는 의미입니다. 이 순서 결정 하나가 가장 큰 보안 가치를 만듭니다.

전달 가능한 링크가 아닌, 허용 목록(Allowlist)

허용 목록은 전달하는 행위를 무해하게 만드는 요소입니다. 해당 사이트는 URL에 대한 지식이 아니라 일련의 이메일 주소에 묶여 있습니다. 뷰어가 링크를 전달하더라도 수신자는 소유자가 추가하지 않은 경우 동일한 검증 장벽에 부딪혀 실패합니다. 사람을 추가하고 제거하는 것은 소유자가 목록을 편집하는 것이며, 접근 권한을 취소하는 것도 즉각적입니다. 주소를 삭제하면 다음 로드 시도부터 실패하게 됩니다.

이는 '추측 불가능한 링크(unguessable link)'와는 다른 사고방식입니다. 추측 불가능한 링크란 슬랙에 실수로 붙여넣은 비밀번호 같은 것입니다. 허용 목록은 문 앞에서 매번 확인하는 손님 명단과 같습니다.

비밀번호 및 만료일, 추가적인 계층화

실제 공유는 단 하나의 스위치만으로는 복잡하기 때문에, 두 가지 작은 제어 기능이 허용 목록 위에 덧씌워집니다:

• 사이트별 비밀번호: 이메일을 선별하지 않고도 가벼운 게이트를 만들고 싶을 때 사용합니다.
• 링크 만료일: '이번 주에는 괜찮지만, 다음 달은 안 되는' 경우에 사용합니다.

이들은 결합됩니다. 허용된 이메일과 비밀번호 둘 다를 요구할 수도 있고, 비공개로 설정된 허용 목록 사이트를 금요일에 만료되도록 설정할 수도 있습니다. 디자인 목표는 일반적인 사례(나와 두 사람; 이 회사 누구든; 공개적이지만 일주일만)가 설정을 아는 박사 학위 없이도 표현 가능하도록 하는 것이었습니다.

근원지 결정: 샌드박싱 및 쿠키리스(cookieless)

당신에게 피해를 주기 전까지 눈에 보이지 않는 또 다른 점이 있습니다. AI로 구축된 페이지에는 임의의 HTML과 JS가 포함될 수 있다는 것입니다. 모든 사이트가 동일한 근원지(origin)에서 렌더링되면, 한 사이트의 스크립트가 다른 사이트의 저장소와 쿠키에 접근할 수 있게 됩니다. 따라서 각 사이트는 자체적으로 격리된, 쿠키리스 근원지에서 렌더링됩니다. 이는 약간의 편의성(사이트 간 공유 로그인 상태 없음)을 희생하는 대가로 여러 사람이 게시한 것들 사이에 실제적인 격리를 확보합니다.

이것이 아닌 것

솔직히 말하자면, '기본적으로 비공개(private by default)'라는 개념은 과장되기 쉽습니다:

• 이것은 디지털 저작권 관리(DRM)가 아닙니다. 인증된 뷰어는 자신이 볼 수 있는 것을 스크린샷을 찍거나 다시 타이핑할 수 있습니다. 모델은 누가 들어올지(who gets in)를 통제할 뿐, 권한을 가진 사람이 그 후에 무엇을 하는지는 통제하지 못합니다.
• 이것은 뷰어의 익명성이 아닙니다. 핵심은 정반대입니다. 즉, 소유자는 누가 보고 있는지에 대한 인증된 이메일 주소를 알고 있다는 것입니다.
• 복잡한 앱 내부의 실제 접근 제어(access control)를 대체하는 것도 아닙니다. 이것은 아티팩트(artifact)를 공유하기 위한 것이지, 멀티테넌트 제품의 권한 시스템을 구축하기 위한 것이 아닙니다.

기본값이 바뀌어야 하는 이유

공개 링크 호스팅 서비스는 사람들이 발견되기를 원하는 것을 게시하는 웹 환경을 위해 설계되었습니다. 우리가 지금 AI로 만드는 것들의 상당 부분은 정반대의 성격을 띱니다. 즉, 특정하고 개인적이며, 이름이 지정된 소수의 사람들을 위한 것입니다. 제작 비용이 저렴해지면서, 만들어지는 대부분의 것은 전체 인터넷을 위한 것이 아닙니다. 따라서 공유에 대한 합리적인 기본값(sane default)은 비공개이며, 소유자가 누가 들어올지 이름을 지정하고, 공개는 의도적인 예외로 두는 것입니다.

만약 AI를 이용해 무언가를 만들었는데 '지금 이 사람들에게만 공유'하는 단계가 어색하게 느껴졌다면, 어떻게 처리했는지 정말 듣고 싶습니다. 그리고 위에서 설명한 접근 모델을 실제로 보고 싶다면, 제가 구축한 Thryvate를 방문해 보세요.