오퍼레이터를 위한 Lolly
심층 방어형 보안·인텔리전스 전략 — 알고 보니 크리에이티브 제작 플랫폼이에요
이미 하고 계신 일을 감싸는, 제로 트러스트 조직 면역 체계예요 — 팀이 매일 필요로 하는 정형화된 크리에이티브 작업이 경계 밖으로 새어 나가는 대신 경계 안에서 이루어지게 해요.
이 문서가 여러분에게 주는 것. 안전하면서도 인기 있는 무언가에 "예"라고 말한 사람이 될 수 있어요. 정보 유출 구멍을 막고, 역량을 얻고, 요청 대기열까지 없애는 일을 한 번에 해내는 거예요 — 더 미움받는 게 아니라 더 인정받게 되는, 흔치 않은 보안상의 승리예요. 기밀 파일이나 고객 데이터가 낯선 웹 도구로 흘러 들어가서 법무팀에게서 새벽 3시에 전화가 오는 일도 없어지고, 신경 써야 할 SaaS 벤더, 계약, 감사도 줄어들며, 누군가 물어볼 때 보여 줄 수 있는 완전히 재현 가능한 감사 기록도 남아요. 발 뻗고 주무실 수 있고, 그 과정에서 누군가의 하루를 몇 번은 밝혀 주게 될 거예요.
Lolly는 이류 크리에이티브 도구가 아니에요: 프로덕션 품질의 결과물을 모두의 손에 쥐여 주고, 브랜드에 맞춘 제작 경험은 어디에도 뒤지지 않아요. 이렇게 널리 배포해도 안전한 이유는 아키텍처 자체에 있어요: 여러분이 직접 넣지 않은 것은 아무것도 업로드되지 않고, 모든 결과물은 재현 가능하며, 모든 내보내기는 업계를 선도하는 여러 겹의 암호학적 기록을 지닐 수 있어요. 문서가 어떤 경로로 여러분의 책상에 도착했든, 그 전체 출처와 변조 여부, 그리고 픽셀 단위로 똑같이 재현할 수 있는지를 확인할 수 있어요.
지금 상태. Lolly의 보안 속성은 설계상 견고하고, 암호화 및 파일 파싱 엔진은 현재 SUSE의 엔터프라이즈급 인프라 강화 과정을 거치고 있어요. 아래에서 설명하는 서명 봉인, 온디바이스 서명, 암호화는 지금도 실질적이고 근거가 있으며, 독립적인 인증을 향해 성숙해 가는 중이에요——그러니 계약상 인증된 보증이 필요한 경우에는, 그 과정이 완료될 때까지 이를 심층 방어의 한 축으로 배치하세요.
전략적 이점
정형화된 크리에이티브 작업이 처리되는 일반적인 방식은 그 자체로 취약점 표면이에요: 외부 디자인 계약업체에 파일을 이메일로 보내고, 브랜드 에셋을 십여 개의 SaaS 에디터에 업로드하고, "그냥 그래픽 하나 빨리 만들려고" 고객 데이터를 낯선 사람의 웹 도구에 붙여넣는 일까지요. 이 모든 순간이 데이터가 여러분의 통제를 벗어나는 순간이에요.
Lolly는 이를 뒤집어요. 그런 유출을 일으켰던 작업——명언 카드, 현지화된 배너, 이벤트 배지, 마스킹된 스크린샷——이 이제는 직원 자신의 기기에서, 여러분의 브랜드에 맞춰, 서버를 거치지 않고 이루어져요. 위험한 워크플로 위에 통제를 하나 더 얹은 게 아니라, 애초에 유출 경로가 없는 워크플로로 그 위험한 워크플로 자체를 대체한 거예요.
- 구성은 여러분의 것이에요. 엔진과 셸은 오픈소스예요(MPL-2.0). 여러분만의 인증, 텔레메트리, CA를 얹을 수 있어요. 직접 호스팅해도 되고 하지 않아도 돼요. 기능과 비용을 완전히 통제할 수 있고, git으로 추적되며, SaaS 데이터베이스에 갇히지 않아요.
- 거버넌스는 대시보드가 아니라 데이터로 다룰 수 있어요. 그런 통제가 필요할 때는 도구 카탈로그를 Git 리포지토리로 관리하세요 — 풀 리퀘스트 리뷰가 곧 브랜드 승인이 되고, 조직 구성원이 손댈 수 있는 모든 템플릿에 대해 완전한 감사 추적과 즉시 롤백이 가능해요. 이는 선택 사항이지 의무가 아니에요: 그저 무언가를 만들고 싶은 팀은 Layout Studio에서 직접 자신의 도구를 만들고, 자신의 파일을 카탈로그로 가져올 수 있어요 — 모두 앱 안에서 이루어지고, git은 전혀 건드릴 필요가 없어요. 도입과 거버넌스를 참고하세요.
- 가드레일은 구조적이에요. 브랜드 제약은 무시할 수 있는 가이드라인으로 게시되는 게 아니라 템플릿에 하드코딩되어 있어요. 잘못된 출력은 권장되지 않는 정도가 아니라——아예 표현될 수 없어요.
콘텐츠는 늘리면서 요청 대기열은 없애기
Lolly의 목표 중 하나는 디자인 요청 해소(디플렉션)예요: 에셋이 필요한 사람이 직접, 정확하게, 몇 분 만에 만들어 내기 때문에 디자이너에게까지 갈 필요가 없는 일상적인 요청들이 여기 해당돼요. 해소된 티켓 하나하나가 생산성의 승리이자, 손을 거치는 파일이 하나 줄어드는 일이에요.
Lolly는 여러분의 조직이 실제로 운영되는 방식에 맞도록 만들어졌어요——배포하는 유일한 정답은 없어요:
- 서비스가 아니라 배포로. 기존 MDM(Intune, Jamf, Munki 등)을 통해 Lolly를 기기에 배포하세요. 데스크톱/모바일 앱이나 오프라인 PWA로 로컬에서 동작하기 때문에 어떤 방화벽 뒤에서도, 어떤 에어갭 환경에서도 작동하고, 유지해야 할 서버도 없으며, 업데이트 주기는 IT가 통제해요.
- 서비스로만 제공. 네트워크 안(또는 VPN 뒤)에서 인스턴스 하나를 운영하고, 사용자는 브라우저로 접속해요——아무것도 설치할 필요가 없어요. 도구를 한 번 게시하면 모두가 즉시 사용할 수 있고, 여러분의 IdP와 결합해 접근을 제어하세요.
- 하이브리드. 오프라인 현장 업무에는 로컬 앱을, 대여 기기에는 항상 최신 상태인 브라우저 버전을——둘 다 동일한 도구 라이브러리를 가리켜요.
유출 방지 유틸리티
Text Helper는 파일이 아니라 텍스트에 대해 같은 거래를 제공해요. 직원이 원래라면 낯선 사이트에서 찾아 헤맬 탭 형태의 작업대이고, 다루는 내용이 페이지를 떠나는 일이 전혀 없기 때문에 입력을 하나도 선언하지 않아요.
Compress PDF가 이 묶음을 완성해요: 너무 큰 첨부 파일이 여러분이 고른 품질 설정에 따라, 이미 그 파일을 갖고 있는 기기 위에서 작아져요.
Lolly 도구 중 한 범주는 특별히 파일을 경계 안에 머무르게 하려고 존재해요. 프라이버시 유틸리티예요.
- Strip hidden data
문서와 미디어 파일에서 위치 정보와 모든 숨겨진 식별 정보를 제거해요.
- Text Helper
구조화된 텍스트와 비구조화된 텍스트를 익명화, 인코딩, 포맷, 가공해요.
- Compress PDF
용량이 큰 PDF를 온디바이스에서 압축해서, 파일이 이메일로 보내기엔 너무 커진 순간 누구도 "PDF 압축" 같은 서드파티 웹사이트를 찾지 않게 해요 — 데이터가 창밖으로 새어 나가는 지점이 바로 거기예요.
이 모두는 온디바이스 변환이에요: 여러분의 파일이나 데이터가 들어가면 깨끗한 바이트가 나오고, 업로드할 서버 자체가 없어요. 선의를 가진 직원이 자칫 손을 대기 쉬운, "파일을 정리하려고 낯선 웹사이트에 업로드하는" 전형적인 도구와는 의도적으로 정반대예요.
결정성과 재현성
Prompt to Image는 결정성을 가장 소박하게 보여줘요: 텍스트가 입력의 전부이고, 조판된 이미지가 출력의 전부이며, 같은 텍스트는 언제나 같은 모습으로 조판돼요.
모든 도구 입력은 URL 파라미터로 표현할 수 있고, 같은 입력은 언제나 같은 파일을 만들어요. 이는 오퍼레이터에게 두 가지 의미가 있어요:
- URL이 곧 결과물이에요. 링크를 커밋하고, 필요할 때 에셋을 다시 생성하세요——바이너리를 Git에 체크인할 필요도, 채팅에서 "최신 버전"을 뒤쫓을 필요도 없어요. 에셋 ID와 도구 ID는 영구적인 계약이라서, 오늘 만든 링크는 나중에도 그대로 해석돼요.
- CLI는 GUI와 동일한 렌더링 경로예요, 그래서 빌드 파이프라인과 앱이 어긋나는 일이 없어요. OG 이미지, 소셜 카드, 데이터 시각화를 빌드 시점에 재현 가능하게 생성하세요.
출처와 Content Credentials
내보낸 파일은 Content Credentials를 지닐 수 있어요——파일 바이트의 해시에 묶인, 서명된 C2PA 매니페스트예요. 이후 파일이 조금이라도 바뀌면 봉인이 깨지기 때문에, C2PA를 인식하는 검증기는 변조를 암호학적으로, 오프라인에서 탐지해요. 이 크리덴셜은 변조-탐지형이에요: 변조를 막기보다 알려 주는 쪽이며, 바로 그 특성 덕분에 완전한 오프라인 검증이 가능해져요.
- 기본으로 켜져 있고, 온디바이스에서 이루어져요. 서명 키는 기기에서 생성되고, 추출할 수 없으며(Lolly조차 읽을 수 없어요), 서명은 로컬에서 이루어져요——네트워크에 닿는 것은 오직 선택적인 신원 등록 과정뿐이에요.
- 신뢰 등급(Trust tiers). 등록하지 않은 상태의 내보내기는 구조적으로는 유효하지만 익명으로 서명돼요(
untrusted). 검증된 신원(이메일에 연결된, Lolly CA가 발급하는 단기 인증서)을 등록하면 Lolly 루트를 신뢰하는 검증기가trusted와 서명자의 이메일을 표시해요. 신뢰할 수 있는 타임스탬프 기관과 서드파티 검증기의 그린 표시(C2PA 적합성)는 로드맵에 있어요. 모든 등급은 명시적이고, 파일은 자신이 증명할 수 있는 신뢰만을 주장해요. - 크리덴셜 유효 기간은 서명 시점에 오퍼레이터/사용자가 정해요: 7일 / 30일 / 90일 / 365일, 기본값은 30일이에요.
- Lolly Imprint. 기본으로 켜져 있는 두 번째 보완 신호예요: 래스터 내보내기(그리고 PDF/PPTX 안에 Lolly가 직접 렌더링한 래스터——사용자가 직접 삽입한 이미지는 제외예요)에 보이지 않는 픽셀 워터마크가 새겨져요. 크리덴셜은 컨테이너가 조금만 바뀌어도 깨지지만, Imprint는 다시 저장하거나 스크린샷을 찍어도 살아남아요——"이 픽셀은 Lolly를 거쳤다"는 사실만 알리는, 지속력 있는 힌트예요. 존재 여부만 알릴 뿐 개인정보는 담지 않아요. 이는 보안을 은닉성에 의존하는 방식이지 강력한 방어 수단은 아니며, 크리덴셜을 대체하는 게 아니라 보완해요.
imprint=0으로 끌 수 있어요. - Durable Content Credentials (옵트인). 래스터 내보내기에는 소프트 바인딩 식별자를 인코딩하는, 보이지 않는 durable 마크를 추가로 새길 수 있어요. 그러면 소셜 미디어 업로드나 재저장으로 파일의 메타데이터가 지워진 뒤에도——일반 크리덴셜이라면 유실됐을 상황에서도——C2PA 크리덴셜을 복구할 수 있어요. 래스터에만 적용되고 신경망 인코딩 과정을 거치므로 기본값은 꺼짐이에요(켜려면
durable=1). Lolly는 오늘/verify에서 자신의 durable 마크를 오프라인으로 인식할 수 있어요. 서드파티 도구(예: Adobe)에 의한 복구는 업계의 소프트 바인딩 표준이 자리 잡는 대로 뒤따를 예정이에요. - 검증도 온디바이스예요.
/verify(또는lolly validate <file>)에 아무 파일이나 올려 보세요. 그 파일이 실제로 Lolly로 만들어졌고 이후 변경되지 않았는지에 대한 오프라인 리포트를 받을 수 있어요. 웹 Verify 화면은 AI 생성 콘텐츠 여부도 표시하고, Lolly Imprint를 감지하고, SEAL 서명(DNS에 키를 저장하는 바이트 단위 서명——네트워크에 닿는 것은 오직 DNS 키 조회뿐이고 파일 자체는 절대 전송되지 않아요)을 검증하며, 선택적으로 서드파티 픽셀 워터마크를 딥스캔하고(온디바이스 모델을 한 번만 내려받아요), 숨겨진 데이터도 찾아내요——이 모든 게 파일을 업로드하지 않고 이루어져요. Content Credentials Identity를 참고하세요.
상호운용성에 관한 참고 사항. Lolly는 오늘 이미 자체 크리덴셜과 서드파티의 여러 크리덴셜을 오프라인으로 검증하며, 여기에는 다른 제작 도구가 만든 C2PA 클레임 v2 매니페스트를 읽어 들이는 것도 포함돼요. 아직 진행 중인 상호운용 항목은 하나예요: WebM이에요——WebM에는 아직 표준화된 C2PA 매핑이 없어서, Lolly는 매니페스트를 Matroska 파트로 붙여 넣어요(서드파티 도구는 Lolly의 MP4는 바로 검증하지만, WebM은 표준이 정해지는 대로 뒤따를 예정이에요).
암호화와 비밀번호 설정
잠긴 채로 이동해야 하는 파일을 위해, 모든 처리는 온디바이스에서 이루어져요:
- PDF 열람 비밀번호 — Standard는 40비트 RC4 억지력이에요(어디서나 열리고, 링크에 담겨 이동할 수 있어요). Strong은 AES-256(PDF 2.0)이고, 내보낼 때 입력하며 링크에는 절대 담기지 않아요.
- 잠긴 다운로드 — ZIP, Projects 폴더, 배치 실행 결과를 통째로 잠글 수 있어요: Standard는 ZipCrypto(약하지만 범용적)이고, Strong은 AES-256(WinZip AE-2)이에요. 심층 방어로, Strong zip 안의 모든 PDF는 개별적으로도 AES-256으로 잠기기 때문에 압축을 풀어도 잠금이 유지돼요.
- 비밀번호로 보호된 공유 링크 — 링크 상태 전체가 PBKDF2로 유도한 키로 AES-256 암호화돼요. 암호문만 이동하고, 비밀번호는 절대 링크에 담기지 않으며, 복호화는 수신자의 브라우저에서 이루어져요.
에어갭 대응
에어갭은 특수 모드가 아니라 일급 배포 방식이에요——Lolly는 기본적으로 렌더링 시점에 네트워크가 없어도 동작해요. 웹 셸은 오프라인 우선 PWA(서비스 워커)예요. 폰트와 WASM은 기기에 저장돼요. 도구 상태는 호스트 브리지를 통해 로컬에 유지되고, localStorage는 절대 쓰지 않아요. 네트워크에 닿는 도구가 있다면 그건 오직 매니페스트에서 선언해야 하는 허용 목록 기반의 host.net 기능을 통해서만 가능하고, 이를 충족할 수 없는(또는 하지 않는) 셸은 스텁으로 대체해요. 셸을 MDM으로 기기에 배포하거나 네트워크 안에서 인스턴스 하나를 서비스로 제공하면, 완전히 에어갭된 설치본이 아무것도 외부로 연결하지 않은 채 렌더링하고, 내보내고, 암호화하고, 크리덴셜을 검증해요.
알아 두면 좋은 것
도입하기 전에 짚고 넘어갈 만한 사항이 몇 가지 있어요:
- 강화 진행 중. 암호화와 파서는 SUSE의 엔터프라이즈 규모 강화를 거치고 있어요(위 참고)——설계상으로는 지금도 견고하지만, 계약상 인증된 보증이 필요한 곳에서는 심층 방어로 배치하세요.
- *도구 훅은 보안 샌드박스가 아니에요. 도구의 선택적인
hooks.js는 호스트 브리지가 주입된 채로 실행되지만, 브라우저 셸에서는 페이지의 실행 영역 안에서 동작하기 때문에window/document/fetch에 접근할 수 있어요*. 실행하는 다른 모든 코드를 대하듯 도구 코드도 다루세요——리뷰하세요. 공유 카탈로그를 운영하는 조직이라면 Git 리뷰로 이를 통제할 수 있는 이유가 바로 여기에 있어요. 어느 쪽이든, Worker 격리가 도입되기 전까지는 리뷰를 마친 도구만 실행하세요. - Content Credentials는 변조를 탐지할 뿐이에요. 방지하는 게 아니라 탐지해요——위의 상호운용성 참고 사항을 확인하세요.
- 암호화 등급은 두 가지예요. Standard 잠금은 빠르고 범용적인 억지력이고, Strong(AES-256)은 완전한 보호예요——민감한 것에는 Strong을 선택하되, 최신 리더가 필요하다는 점을 기억하세요.