WATCHA - Medium 최신 글

최신 글

• 감으로 맞추던 값을 식을 세워서 kubernetes 최적화하기

  감으로 맞추던 값을 식을 세워서 Kubernetes 최적화하기 배경 왓챠는 다양한 취향을 가진 시청자들을 위해 다채로운 영상 콘텐츠들을 제공하고 있습니다. 이를 위해 왓챠는 고용량 원본 영상을 웹, 모바일, TV에서 원활히 재생할 수 있도록 압축하는 인코딩 작업을 Kubernetes 위에서 수행하고 있습니다. 하지만 복잡한 Kubernetes 환경에서 인코딩 작업을 비용 효율적이고 빠르게 수행하도록 최적화하는 것은 항상 어려운 과제였습니다. 이번 글에서는 이 과제를 해결하기 위해 식을 세워 값을 찾는 모델 기반 접근 방식을 활용하여 인코딩 작업을 최적화할 수 있었던 경험을 소개합니다. 문제 정의 왓챠의 인코딩 플랫폼은 하나의 영상을 여러 개의 Segment로 나누어 작업을 병렬 처리하는 방식(Parallel distributed job)으로 인코딩을 수행하고 있습니다. 기존에는 이러한 병렬 분산 작업을 구현하기 위해 Segment 처리에 필요한 컴퓨팅 자원을 VM instance 단위로 분배하고 있었습니다. 하지만 이러한 방식은 서비스 로직과 인프라 로직이 강결합되어 불필요한 배포를 요구했으며, VM instance 단위의 확장은 리소스를 비효율적으로 사용한다는 문제점을 내포하고 있었습니다. 기존의 EC2 기반 구조와 전환 이후 Kubernetes 기반 구조의 차이 위와 같은 문제를 해결하기 위해 플랫폼 팀은 인코딩 플랫폼의 Kubernetes 전환을 진행했습니다. 인프라 로직을 Kubernetes에 위임하고 컴퓨팅 단위를 Pod로 세밀화함으로써 인프라 강결합을 해소하고 확장 단위를 유연하게 만들기 위함이었습니다. 하지만 Kubernetes 전환 이후 아래와 같은 문제들이 새로 나타났습니다. 고도화된 오케스트레이션 정책으로 인해 인코딩 작업에 영향을 미칠 수 있는 변수들이 많아졌습니다. 기존에는 작업 구성을 위해 어떤 VM Instance 타입으로 인코딩을 수행할까?, 한 VM Instance에 몇 개의 Segment를 할당할까? 와 같은 단순한 결정이 필요했습니다. 하지만 Kubernetes 환경에서는 확장 안정화 윈도우, 확장 단위 임계점 설정, 프로세스 종료에 필요한 버퍼 시간 설정 과 같은 복잡하고 다양한 정책 결정이 필요해졌습니다. 각 변수들의 최적 값을 결정하는 과정이 더 복잡해졌습니다. Kubernetes 환경에서 작업에 영향을 미치는 변수들은 독립적으로 존재하는 것이 아니라 서로 영향을 주고 받는 의존적인 관계를 가지고 있었습니다. 예를 들어 어떤 변수는 단순히 높이거나 낮출수록 효율성에 긍정적인 방향으로 작용했지만, 어떤 변수는 무한정 높이거나 낮추는 것이 효율성에 도움을 주지 못하는 경우가 존재했습니다. 이와 같은 복잡한 환경에서 문제를 해결하기 위해서는 기존보다는 더 엄밀하고 구조적인 방식을 사용해야 할 필요가 있었습니다. 과거에는 이러한 방식을 사용하려면 많은 시간과 노력이 들었기 때문에 ‘일단 값 넣어보고 관찰하기’와 같은 방식을 사용할 수밖에 없었지만, 현재는 AI의 도움을 통해 이러한 허들을 낮출 수 있을 것이라고 판단했습니다. 따라서 Kubernetes 환경에서 영향을 미칠 수 있는 변수들을 반영한 방정식을 세운 후 이를 통해 구조적으로 각 변수의 최적값을 찾는 방법을 사용해보기로 했습니다. 즉 최적해를 찾기 위해 변수들의 값을 바꿔가며 결과를 확인하는 기존의 경험적 방법을 사용하는 대신 발전한 AI를 통해 방정식을 세우고 최적해를 구하는 모델 기반 방법을 통해 인코딩 작업의 효율성을 개선하고자 했습니다. 문제 해결을 위한 과정 모델 기반 접근 방법에 가장 먼저 필요했던 작업은 최적화해야 하는 변수가 무엇인지 정의하는 것이었습니다. 통상적으로 작업의 효율성에 영향을 미치는 변수는 품질, 비용, 시간이 존재한다는 가정에서부터 시작했습니다. 하지만 인코딩 작업은 품질 면에서 개선할 수 있는 상한이 비교적 뚜렷하며, 항상 일정한 수준을 유지한다는 특성이 있기 때문에 비용과 시간 2개 요소만을 주요 변수로 고려하기로 했습니다. 이러한 과정을 통해 모델 기반 접근으로 최적해를 구해야 할 요소는

  2026년 10월 22일

• 왓챠 직원 누구나 AI 앱을 만들 수 있게 된 이유

  현재 왓챠에서는 마케터가 스스로 KPI 대시보드를 만들어 레포트를 작성하고, 운영자가 자동화 도구를 만들어 업무를 자동화하고 있습니다. ML 엔지니어는 자체 데이터 분석 플랫폼을 제작해 데이터를 분석하고, 사업팀에서는 자체 CRM을 구축해 SaaS를 대체하고 있습니다. 사내 직원들은 누구나 원하는 도구나 앱이 있다면 이를 직접 만들어 직접 문제를 해결하고 있습니다. 지난 몇 년 동안, 플랫폼이나 자동화 앱을 제작하는 것은 개발자만의 전유물이었습니다. 소프트웨어 제작에는 특정한 지식이나 경험이 필요한 개발 능력이 필요했기 때문입니다. 마케팅 팀이 월별 활성 사용자 대시보드를 볼 수 있으려면 어느 정도 시간이 필요했을까요? 정답은 “대시보드 개발자의 백로그에 따라 다르다” 였습니다. 이처럼 개발 능력의 부재는 비개발자 팀에게 병목으로 작용하곤 했습니다. 이제는 상황이 변했습니다. LLM의 발전으로 비개발자 직군도 쉽고 빠르게 개발할 수 있게 되었기 때문입니다. 이제 소프트웨어를 개발하는 행위는 개발자만의 능력이 아니게 되었습니다. 하지만 사내 직원들은 생각만큼 매끄러운 자동화 앱을 쉽게 제작할 수 없었습니다. 이에는 단순히 개발 지식의 부족이 아닌 다른 문제가 존재했습니다. 이 글에서는 왓챠의 플랫폼 팀에서 조직이 AI 기반으로 앱을 개발하기 어려워하는 문제를 해결하기 위해 ADP, AI Development Platform를 구현한 과정을 서술합니다. 플랫폼 팀에서는 ADP를 왜 만들었는지, ADP를 배포하며 어떤 문제를 마주했는지, ADP로 어떤 문제를 해결할 수 있었는지 알아봅니다. 문제 정의 왓챠 사내 직원들이 생산성 향상에 필요한 앱을 LLM으로 제작하는데 어려움을 겪었던 이유는 다음과 같았습니다. 비단 왓챠뿐 아니라 LLM을 통해 앱을 개발하고자 했던 유저라면 누구나 아래와 같은 문제들을 마주했을 것입니다. 아무도 데이터를 찾지 못한다 : 사내 직원들이 앱을 제작하기 위해서는 사내에서 관리하는 데이터가 필요했습니다. 보통 직원들은 사내 정보를 시각화하거나 메트릭을 추출하는 등 사내 데이터를 기반으로 인사이트를 얻으려 하기 때문입니다. 하지만 이에 필요한 데이터를 소유하고 관리하는 주체는 보통 데이터 팀, 혹은 개발 조직이었습니다. 이러한 조직에 속하지 않은 직원들은 데이터가 어디 있는지, 심지어 데이터가 존재는 하는지 등의 정보를 알 수 없다는 문제가 있었습니다. 너무 많은 권한 요청 : 어느 날 플랫폼팀에 GCP 권한 요청이 평소보다 많이 들어온 적이 있었습니다. 원인은 많은 사내 직원들이 LLM으로 앱을 만드는 과정에서 Google Drive 접근이 필요했기 때문에 관련 권한을 요청해야 한다고 판단(혹은 LLM이 가이드) 했던 것이었습니다. 하지만 플랫폼 팀은 대부분의 권한 요청을 보류할 수밖에 없었습니다. 플랫폼 팀 인원이 모든 직원들의 권한 요청에 대응할 수 없었을뿐더러, 많은 직원에게 API Key나 Token이 발급되는 것은 보안 공격 표면이 커질 수 있었기 때문입니다. 어디에도 배포할 수 없다 : 사내 직원들이 LLM을 통해 만든 앱 대부분은 외부 호스팅 플랫폼(Vercel, Github pages, Netlify ..)에 배포되어 있었습니다. 이는 LLM이 특정 호스팅 플랫폼에 앱을 배포하려는 편향도 있었지만, 사내에 앱을 배포하기 위한 환경이 부재하다는 것이 외부 호스팅 플랫폼을 통해 배포된 결정적인 원인이었습니다. 사내에서 운영하는 배포 환경은 “개발자”가 제작한 앱, 혹은 서비스를 배포하기 위한 것이지 전사 직원들을 위한 것은 아니었기 때문입니다. 하지만 모든 직원들이 각자의 앱을 외부에 배포하면 사내 정보가 유출될 위험이 커지며, 용량이나 스펙 부족으로 인해 원하는 생산성을 얻기 힘들 것이라는 문제가 있었습니다. 데이터 유출 위험 : 무엇보다 가장 큰 문제는 LLM을 통해 생성된 코드가 사내에서 요구하는 보안 수준을 만족하기 어려웠다는 것입니다. 특히 OpenClaw 사내 데이터 유출 문제가 있었던 것처럼, 왓챠에서도 로컬 환경에서 LLM으로 제작한 앱을 구동한 직원들이 사내 정보나 데

  2026년 7월 1일

• 맥락이 형태를 결정할 때

  왓챠와 왓챠피디아 스크린샷을 설계하며 WATCHA Branding Notes ⑤ 앱 스토어와 구글 플레이 스크린샷은 사용자가 앱 서비스를 경험하기 전에 가장 먼저 만나는 접점이다. 그 몇 장에서 “이게 나에게 맞는 서비스인가”를 판단한다. 왓챠와 왓챠피디아는 이름의 연결고리는 명백하지만 사용자에게 전달하는 경험의 본질은 확실히 구분된다. 두 서비스를 다르게 정의해온 시도가 WATCHA Branding Notes 시리즈의 흐름이었고, 스크린샷 작업은 그 정의가 가장 첫 번째 접점에서 실행되는 일이었다. 이 글은 그 과정에서 기준으로 삼은 것들을 기록한다. 시작은 시각이 아니다 스크린샷 디자인을 시작할 때 가장 먼저 해야 할 것은 시각적 접근이 아니다. 서비스가 사용자에게 무엇을 전달해야 하는지, 그 첫 번째 접점에서 무엇이 보여야 하는지가 먼저 정리되어야 한다. 그 선행 없이 화면 구성을 시작하면 시각적 자극을 높이는 방향으로 흐르기 쉽다. 디바이스 목업과 화면 요소를 연출하는 데 집중한다거나, 슬롯마다의 시각적 변주를 기준으로 삼는 것. 이런 선택들이 나쁘다는 것이 아니라, 맥락 없이 먼저 오면 브랜드가 아니라 형태만 남는 결정으로 흐를 수 있다. 비교 대상을 선택하는 것도 이미 브랜드 판단이다. 카테고리 안에서 어떤 서비스들과 나란히 놓일지, 그 안에서 이 브랜드가 어디에 위치해야 하는지를 먼저 파악해야 한다. 시장 안에서의 위치를 이해하지 못하면 비교 자체가 방향을 흔드는 근거가 된다. 더 화려하거나 더 밀도 높은 것이 무조건 더 나은 방향이 아니다. 브랜드가 어디에 서 있는지를 아는 것이 시각적 판단보다 먼저 있어야 한다. 맥락이 충분히 정리되어 있을 때, 시각적 선택도 비로소 브랜드 판단이 된다. 보여지는 화면을 결정하는 것이 개인의 시각적 기준에 머무는 순간, 그 선택은 작업자의 감각일 뿐 브랜드의 맥락에서 벗어난다. 어떤 화면을 담을지, 어떤 순서로 배치할지, 무엇을 덜어낼지 — 결국 브랜드가 무엇인지를 이해한 위에서 내려지는 결정이다. 같은 접점, 다른 설계 App Store — WATCHA & WATCHA PEDIA 왓챠와 왓챠피디아의 설계가 달랐던 것은 두 브랜드가 사용자에게 전달하는 경험의 본질이 다르기 때문이다. 왓챠는 콘텐츠를 발견하고 감상하는 플랫폼이다. 다른 곳에서 접하기 어려운 작품, 장르와 형식의 다양성이 왓챠가 가진 고유한 가치다. 볼륨보다 큐레이션, 양보다 다양성으로 자리를 잡아온 서비스다. 사용자가 왓챠에 오는 이유는 보고 싶은 것을 찾기 위해서이며, 스크린샷은 왓챠가 무엇을 가지고 있는지를 보여주는 방식으로 설계했다. 순서에도 의도가 있었다. 콘텐츠 다양성으로 시작해 — 왓챠에 오는 첫 번째 이유 — 개인화 추천으로 나만을 위한 경험을 보여주고, 함께 보는 경험으로 왓챠만의 방식을 드러내고, 최신작 감상과 웹툰으로 왓챠에서 할 수 있는 것의 폭을 닫는다. 각 슬롯이 독립된 기능 소개가 아니라 왓챠를 경험하는 흐름으로 이어지도록 설계했다. WATCHA Screenshots 2026.05 — 왓챠가 무엇을 가지고 있는지를 순서대로 드러내는 기능 중심 소개 왓챠피디아는 다르다. 피디아의 중심에는 사용자의 기록이 있다. 별점 하나를 남기는 것에서 시작해 코멘트를 쓰고, 그 기록이 취향으로 분석되고, 나만의 예상 별점이 정교해지며, 그 취향들은 피드에서 다른 이의 발견으로 이어진다. 이 흐름이 왓챠피디아를 작동시키는 구조다. 그래서 스크린샷도 그 루트를 그대로 순서로 담았다. 기능을 나열하는 대신 “이렇게 쓰게 된다”를 보여주는 것이 목적이었기 때문이다. 덜어낼수록 선명해진다 스크린샷에 담을 수 있는 것은 너무 많다. 장수도, 내용도 선택의 영역이다. 문제는 담을 수 있는 것을 모두 담으려는 순간, 아무것도 전달되지 않는다는 것. 이번 왓챠피디아 스크린샷에서 기능을 강조해 나열하지 않은 것, 디바이스 목업 없이 플랫하게 처리한 것은 모두 같은 판단에서 나왔다. 무엇을 보여줄지 보다 무엇을 보여주지 않을지를 먼저 결정한다. 그 판단이 가능했던 건 이 서비스가 무엇을 말해야 하는지가 먼저 정

  2026년 6월 29일

• 왓챠 웹 PiP 적용기 — Document PiP는 어떻게 동작하고, 무엇이 어려웠나

  1부에서 “왓챠 웹이 PiP를 지원한다”고 알려드렸습니다. 이번 편은 실제 적용기 입니다. 특히 DRM 영상·자막·왓챠파티가 얽힌 실서비스에 붙이는 건 전혀 다른 일이었습니다. 📑 목차 1. 들어가기 전에 — 웹 PiP에는 두 종류가 있습니다 (#b1c2) 2. 동작 원리 — Document PiP는 어떻게 가능한가 (#f285) 3. 적용기 ① “옮기는 한 줄”이 React에선 안 통한다 (#8117) 4. 적용기 ② “안 끊긴다”던 영상이, 가끔 굳는다 (#5cfd) 5. 적용기 ③ ‘X’를 누르면 끝내는 걸까, 크게 보는 걸까 (#d231) 6. 요약 — 적용 순서 한 눈에 보기 (#261d) 7. Q&A — 한 발 더 들어가기 (#d392) 8. 못다 한 것 (#27f5) 들어가기 전에 — 웹 PiP에는 두 종류가 있습니다 바로 Standard PiP와 Document PiP 입니다. 이 둘은 할 수 있는 일이 다릅니다. 📌 용어 안내. 사실 “Standard PiP”는 공식 명칭이 아닙니다. 영상 하나만 띄우는 원래 API의 정식 이름은 그냥 Picture-in-Picture API이고, 나중에 나온 Document Picture-in-Picture API가 이를 확장한 것입니다. 그런데 둘 다 “PiP”라 부르면 구별이 안 돼서, 이 글에선 앞엣것을 편의상 Standard PiP로 부르겠습니다. 핵심 차이는 “무엇을 떼어내느냐” 입니다. Standard PiP는 브라우저가 <video> 하나만 floating 창으로 띄웁니다. 간단한 대신 우리가 DOM으로 그리는 자막, 커스텀 컨트롤, 다음 화 버튼은 따라가지 못합니다. Document PiP는 진짜 별도의 window를 열어줍니다. 그 안에 우리 DOM을 통째로 옮기면 자막도 컨트롤도 그대로 살아 있습니다. 대신 Standard PiP보다 관리가 복잡합니다. 왓챠는 왓챠만의 브랜딩된 UI와 자막을 그려야 하기 때문에, 되도록 Document PiP를 지원하기로 했습니다. 그리고 Document PiP를 지원하지 않는 Safari 등에서는 Standard PiP로 fallback시켰습니다. 동작 원리 — 영상을 옮기는데 왜 안 끊길까 앞서 “Document PiP는 우리 DOM을 통째로 새 창으로 옮긴다”고 했습니다. 크롬 공식 가이드의 예시를 보면 꽤 간단하게 적용할 수 있습니다. pipButton.addEventListener('click', async () => { const player = document.querySelector("#player"); // PiP 창을 연다 const pipWindow = await documentPictureInPicture.requestWindow(); // 플레이어를 PiP 창으로 옮긴다 ← 이 한 줄이 핵심 pipWindow.document.body.append(player); }); 📄 출처: 크롬 공식 가이드 — Document Picture-in-Picture 💡 직접 확인해보기 크롬이나 엣지를 쓰신다면, 지금 개발자도구(F12) 콘솔에 이렇게 쳐보세요. documentPictureInPicture 진짜로 브라우저에 내장된 기능이라는 걸 바로 볼 수 있습니다. 반대로 Safari나 Firefox에서 쳐보면 undefined가 나옵니다 — 아직 이 API를 지원하지 않기 때문이죠. 다시 코드로 돌아와보면 requestWindow()로 창을 열고, append(player)로 플레이어를 그 창에 옮긴다. 끝입니다. 말은 간단하지만, 생각해보면 이상한 일입니다. 재생 중인 영상을 다른 창으로 뜯어 옮기는데, 어떻게 끊기지 않을까요? 스펙과 브라우저 코드를 열어보면, 두 가지 장치가 맞물려 이걸 가능하게 합니다. ① 어떻게 우리 코드가 새 창(pipWindow)을 직접 채울 수 있나? 본인인증을 붙여본 개발자라면 이런 흐름이 익숙할 겁니다. 인증 창을 하나 띄우고 → 사용자가 그 안에서 인증을 끝내면 → 결과만 콜백으로 돌려받습니다. 정작 그 창 안에서 무슨 일이 벌어지는지 우리가 들여다보거나 손댈

  2026년 6월 18일

• “왓챠 PiP 안 됨?” — 됩니다, 이제부터.

  🎬 이런 경험, 있으시죠? 저는 장송의 프리렌을 정말 좋아합니다. 그래서 애니를 한켠에 틀어놓고 게임이나 일을 할 때가 많습니다. 들려오는 대사와 잠깐씩 보는 장면만으로도 충분히 좋거든요. 그런데 한켠에 틀어놓으면 새 창을 띄울 때마다 영상이 그 뒤로 덮여 버리는 문제가 있습니다. 화려한 전투씬이 시작될 땐 바로 봐야 하는데 말이죠! 저만 그런 게 아닐 거라 생각했고, 그래서 만들었습니다. 왓챠가 PiP(Picture-in-Picture) 모드를 지원합니다. 영상을 작은 창으로 화면 위에 띄워두고, 그 아래·뒤에서 자유롭게 다른 일을 하세요. 영상은 멈추지 않습니다. 이제는 외부 확장 프로그램까지 동원하지 않아도 됨. 📺 PiP가 뭔가요? 이름은 낯설어도, 한 번쯤 써보셨을 겁니다. 📱 휴대폰으로 유튜브를 보다 홈으로 나오면 → 영상이 작게 떠서 따라다니죠 💻 구글 밋 회의 중 다른 창으로 넘어가면 → 회의 화면이 작아져 어디든 따라오고요 PiP(Picture-in-Picture, 화면 속 화면) — 재생 중인 영상을 페이지에서 떼어내, 항상 화면 맨 위에 떠 있는 작은 창으로 보여주는 기능입니다. 다른 창을 띄우든 탭을 옮기든, PiP 창은 그 뒤로 숨지 않습니다. 💡 왓챠 앱에선 이미 일부 지원하던 기능입니다. 웹에서도 쓸 수 있게 됐어요. 🔄 무엇이 달라졌나요 — Before & After Before: 미니플레이어 지금까지 왓챠는 자체 제작한 미니플레이어로 이 문제를 풀어왔습니다. 페이지 한 구석에 작은 플레이어를 띄워, 스크롤을 내리거나 다른 작품을 둘러보는 동안에도 영상을 볼 수 있었죠. 기존 미니플레이어 하지만 미니플레이어에는 한계가 있었습니다. 어디까지나 웹페이지 안의 한 요소라, 탭을 바꾸거나 브라우저 창을 최소화하면 함께 사라졌습니다. After: PiP 모드 PiP 모드 PiP 창은 브라우저 탭과 독립적입니다. 탭을 옮겨도, 다른 작업 창을 띄워도, 영상은 화면 맨 위에 그대로 떠 있습니다. 이제 프리렌을 마음껏 볼 수 있게 되었습니다. (야호) 동시에 다른 작품을 둘러볼 수 있음 ✨ 왓챠 PiP, 이런 게 좋아요 재생이 끊기지 않습니다. 탭을 넘나들어도, 다른 앱을 띄워도 영상은 계속됩니다. 자막과 컨트롤이 그대로 따라옵니다. PiP 창 안에서도 자막을 보고, 재생/일시정지·시킹을 직접 조작할 수 있습니다. (지원 브라우저 기준 — 아래 참고) 다음 화도 PiP 안에서. 한 편이 끝나면 PiP 창에서 바로 다음 화로 이어집니다. 왓챠파티도 함께. 왓챠파티 중에도 PiP로 띄워두고 다른 걸 둘러볼 수 있습니다. 다음 에피소드를 재생하거나 자막도 보여짐. (DRM 때문에 검정 화면으로 보여요) 🖱️ 어떻게 쓰나요? 플레이어 하단 컨트롤의 PiP 버튼을 누르면 바로 작은 창으로 떨어집니다. 다시 원래 화면으로 돌아오려면 PiP 창의 버튼을 누르면 됩니다. 💡 참고: 브라우저에 따라 경험이 조금 달라요 PiP는 브라우저가 제공하는 기능이라, 지원 범위가 브라우저마다 다릅니다. Chrome·Edge 등 (Chromium 계열): 자막·컨트롤·다음 화까지 포함된 완전한 PiP 경험을 제공합니다. Safari·Firefox 등: 영상 자체는 PiP로 띄울 수 있지만, 자막과 커스텀 컨트롤은 표시되지 않습니다. (브라우저 기본 PiP의 제약입니다.) 가장 풍부한 경험을 원하시면 Chrome 계열 브라우저를 권해드립니다. 🔧 그리고, 그 뒤에는… “영상을 작은 창에 띄운다”는 한 문장 뒤에는, 기술을 실제 서비스에 녹여내기 위해 많은 고민이 있었습니다. 화면이 멈추고, 에피소드가 안 넘어가던 문제들을 어떻게 풀었는지 — 그 이야기는 2부 (기술편)에서 풀어보겠습니다. [2부 링크] “왓챠 PiP 안 됨?” — 됩니다, 이제부터. was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.

  2026년 6월 18일

• 다를 수도 있지: 왓챠 영화 주간

  화면 밖에서 브랜드를 경험시키는 일 WATCHA Branding Notes ④ 디지털에 뿌리를 둔 브랜드를 오프라인에서 경험시키는 일은 생각보다 어렵다. 왓챠는 데이터와 기록 위에서 작동하는 브랜드다. 수억 개의 별점과 코멘트가 쌓이며 만들어진 취향의 흔적들. 그 경험을 직접 발 딛고 서는 공간에서는 어떻게 체감하게 할 수 있을까. 왓챠가 오랫동안 이야기해온 것이 있다. 다양한 취향이 함께 존재할 때 더 풍부한 감상이 만들어진다는 것. 2026년 1월, 서울영화센터에서 열린 ‘왓챠 영화 주간’은 그 태도를 오프라인에서 직접 경험하게 하는 프로젝트였다. 발견하게 두기 이 공간을 설계할 때 가장 먼저 고민한 것은 무엇을 보여줄지가 아니라, 어떻게 발견되게 할 것인가였다. 왓챠는 취향을 정의하는 대신, 사용자가 스스로 자신의 취향을 발견하게 만드는 구조 위에서 작동한다. 수억 개의 별점과 코멘트 역시 정답처럼 제시되기보다, 각자가 자기 언어로 이해하고 이어가게 된다. 그래서 이 공간 역시 그 방식에 가깝게 설계하고자 했다. 이 공간에서 브랜드의 메시지는 직접 설명되지 않는다. 대신 관객이 이동하는 동선 위에 자연스럽게 놓였다. 서로 다를 수도 있다는 선언에서 시작해, 입구에서는 쌓여온 별점의 규모로 증명하고, 층마다 질문을 거쳐 각자의 감상으로 정리되는 흐름. 입장에서 퇴장까지 공간 어디에서나 같은 태도가 이어지도록 했다. 메시지를 주입하기보다, 관객이 스스로 마주치고 의미를 완성하게 하는 것. 이것이 이 공간의 기준이었다. 디지털에서 기록과 데이터로 작동하던 브랜드의 방식은, 오프라인에서는 이동과 체류의 경험으로 번역된다. 걸으며 보게 되고, 멈추며 읽게 되며, 어느 순간 이미 체감하고 있는 상태. ‘다를 수도 있지: 왓챠 영화 주간’은 그렇게 시작되는 경험이었다. 취향을 아는 왓챠가 할 수 있는 것 왓챠의 사용자들은 조금 다르다. 같은 시기에 같은 콘텐츠를 보는 경험보다, 자신만의 취향을 깊이 파고드는 사람들이 모여 있다. 사용자는 좋아하는 장르도 취향도 제각각이지만 한 가지는 같다. 자기 기준으로 보고, 자기 언어로 기록한다. 이 공간의 언어는 그 사람들에게서 왔다. “애매필”, “갑자기 벅차오름”. 설명하지 않아도 고개를 끄덕이는 사람이 있다면, 그건 그 언어가 살아있는 커뮤니티가 있다는 뜻이다. 왓챠는 사용자와 함께 그 언어를 직접 쓸 수 있는 브랜드다. 그래서 준비한 섹션도 각각 확연하게 달랐다. ‘스파게티 웨스턴 코어’, ‘한따한따 아저씨 정모’, ‘영화보다 현실이 더 해’ — 어떤 취향도 중심이나 변방으로 나뉘지 않았다. 매일 다른 취향이 그날의 주인공이 되었고, 영화가 끝난 뒤에도 그 흐름은 자연스럽게 이어졌다. 각각의 섹션은 그 취향을 실제로 경험할 수 있도록 구성되었다. 한 장르를 깊이 있게 해석하는 흐름이 이어졌고, 같은 작품을 좋아하는 사람들이 모여 자연스럽게 대화를 나누는 장면이 만들어졌다. 또 다른 문화의 맥락과 연결되며, 전혀 다른 이야기로 확장되기도 했다. 서로 다른 취향이 한 공간에 모여 각자의 감상을 나누는 것. 왓챠가 오랫동안 만들어온 경험이, 오프라인에서 그대로 펼쳐졌다. 기획된 것 이상의 장면 〈킴스 비디오〉를 오프닝으로 선택한 이유는 명확하다. 장르를 가리지 않는 방대한 컬렉션, 어떤 취향이든 ‘영화’라는 하나의 연결고리로 공존할 수 있었던 공간. 지금의 왓챠가 누군가에게 나만 알고 싶은 비디오 가게 같은 곳인 것처럼, 이 프로젝트의 기획 의도와 가장 잘 맞는 출발점이었다. 오프닝의 관객들은 ‘영화를 사랑하는 유령들의 파티’에 초대받았다. 각자 좋아하는 영화감독이나 배우의 가면을 만들어 입장하는 방식으로. 가면은 참여의 장치였다. 어떤 취향이든, 영화를 좋아한다는 것 하나만으로 누구나 이 공간에 들어올 수 있었다. 그리고 그 참여는 이후 이어질 가지각색의 섹션으로 자연스럽게 확장되었다. 빨간 카펫이 깔린 1관의 모든 좌석에는 영화인들의 이름표가 붙어 있었다. 가면을 준비하지 않은 관객도, 그 자리에 앉는 순간 영화를 진심으로 사랑하는 사람이 됐다. 실제로 가면을 만들어올 관객이

  2026년 4월 1일

• 왓챠피디아, 취향을 기록하는 아카이브

  기록에서 시작되는 서비스 구조 WATCHA Branding Notes ③ WATCHA / WATCHA PEDIA 로고 왓챠와 왓챠피디아는 같은 회사 안에서 운영되는 서비스지만 서로 다른 역할을 가진다. 이 글은 두 서비스의 관계를 브랜드 관점에서 바라보며, 왓챠피디아의 서비스 구조를 기록이라는 관점에서 정리해본 글이다. 왓챠는 콘텐츠를 발견하고 감상하는 플랫폼이고, 왓챠피디아는 그 경험을 기록하는 서비스다. 왓챠에서 브랜드 디자인을 담당하며 두 서비스를 함께 다루고 있다. 브랜드를 운영하는 과정에서 자연스럽게 두 서비스의 관계와 구조를 다시 바라보게 되었고, 그 과정에서 왓챠피디아를 다른 관점에서 이해하게 되었다. 브랜드 관점에서 두 서비스를 바라보다 보니 한 가지 질문이 떠올랐다. 같은 이름을 공유하는 두 서비스는 브랜드 구조 안에서 어떤 관계에 있어야 할까. 왓챠에 합류했을 때 두 서비스의 이름 구조는 이미 정리되어 있었다. 같은 이름을 공유하고 있었지만 두 서비스는 서로 다른 방향으로 운영되고 있었다. OTT 서비스인 왓챠는 추천과 큐레이션을 통해 다양한 작품을 발견하는 경험을 중심에 둔 플랫폼이다. 대형 스트리밍 서비스에서 쉽게 접하기 어려운 작품들을 꾸준히 소개해 왔고, 특정 취향을 가진 관객층에게 오랫동안 사랑받아 온 서비스이기도 하다. 이런 환경 속에서 왓챠피디아는 자연스럽게 콘텐츠 경험을 기록하고 공유하는 공간으로 함께 존재해 왔다. 기록에서 시작되는 추천 왓챠피디아는 추천 서비스로 소개되기도 한다. 하지만 서비스 구조를 조금 더 들여다보면 추천 기능 이전에 존재하는 중요한 기반이 보인다. 왓챠가 제공하는 핵심 기능 중 하나는 예상 별점이다. 사용자의 평가 데이터를 기반으로 아직 보지 않은 작품의 예상 별점을 계산해주는 기능이다. 이 기능은 왓챠피디아에서도 동일하게 사용되고 있다. 다만 서비스 안에서의 맥락은 조금 다르다. 예상 별점이 작동하기 위해서는 사용자 데이터가 필요하다. 그리고 그 데이터는 결국 사용자가 남긴 별점, 코멘트, 감상 기록에서 만들어진다. 즉 추천 기능은 기록을 기반으로 작동한다. 이 관점에서 보면 왓챠피디아의 출발점은 추천이 아니라 기록에 있다. 기록에서 시작되는 취향 왓챠피디아의 서비스 구조를 보면 다음과 같은 흐름이 만들어진다. 기록 → 데이터 → 예상 별점 → 취향 발견 사용자가 남긴 기록이 데이터가 되고, 그 데이터가 다시 추천과 취향 발견의 경험으로 이어진다. 이 과정에서 중요한 것은 추천 기능 자체보다 기록이 만들어내는 데이터의 축적이다. 왓챠피디아의 중심에는 다음과 같은 관점이 있다. 전문가의 평이 아닌 나의 기록 평균 별점이 아닌 나의 예상 별점 왓챠피디아는 전문가의 평가를 중심에 두는 서비스가 아니라, 사용자가 남긴 기록을 통해 취향을 발견해가는 구조를 가지고 있다. 이러한 구조를 기준으로 보면 왓챠피디아는 단순한 추천 서비스라기보다 개인이 기록을 통해 자신의 취향을 발견해가는 공간에 가깝다. 취향의 발견 왓챠피디아에는 오랫동안 서비스 구조를 직접적으로 설명하는 슬로건이 존재하지 않았다. 앱스토어에는 ‘세상의 모든 취향, 왓챠피디아’라는 문구가 사용되고 있었지만, 서비스의 핵심 경험을 설명하기에는 다소 범용적인 표현에 가까웠다. 브랜드 가이드를 정리하는 과정에서 왓챠피디아의 서비스 구조를 다시 분석하게 되었고, 그 중심에는 기록을 통해 취향을 발견하는 경험이 있다는 점이 분명해졌다. 이 관점을 기준으로 왓챠피디아의 브랜드 메시지는 다음과 같이 제안되고 적용되었다. (2025년 기준) 왓챠 영화 주간(2026.1.29–2.1) 당시 서울영화센터 복도에 설치된 ‘취향의 발견! 왓챠피디아’ 슬로건 취향의 발견! 왓챠피디아 이 표현은 단순한 추천 서비스가 아니라, 사용자가 기록을 통해 자신의 취향을 발견하는 경험을 설명하는 슬로건이다. 취향 아카이브 기록은 단순히 감상을 남기는 행위에 그치지 않는다. 사용자의 별점과 코멘트, 감상 기록이 쌓이며 콘텐츠 경험에 대한 데이터가 축적된다. 이렇게 쌓인 기록은 개인의 감상을 넘어 하나의 취향 아카이브를 만든다. 왓챠피디아는 바

  2026년 3월 18일

• 클라우드 비용 최적화를 위한 Automatic Labeling System 구축기

  1. FinOps는 왜 어려운가 1. 측정 가능한 비용, 불가능한 비용 클라우드 인프라를 운영하는 사람이라면 누구나 비용 최적화를 원합니다. 하지만 이를 달성하는 것은 누구에게나 쉽지 않습니다. 그래서 이 문제를 해결하기 위해 많은 이들이 FinOps와 같은 프레임워크를 도입해 이 같은 문제를 해결하고자 해왔습니다. FinOps는 클라우드와 같은 기술 분야에서 비즈니스 가치를 극대화하고자 하는 운영 프레임워크이자 문화를 뜻합니다. 하지만 FinOps를 적용하는 과정에서 기술 비용과 재정 비용 사이의 최적해를 찾아야 하는 문제를 마주하게 됩니다. 이는 재정 비용을 절감하고자 하면 기술적인 운영, 관리에 소요되는 비용인 기술 비용이 상승하고, 기술 비용을 절감하고자 하면 재정 비용이 상승해 조직 전체의 Budget이 줄어든다는 Tradeoff를 말합니다. 이 같은 Tradeoff는 대부분의 조직에서 해결하기 어려운 문제입니다. 왜냐하면 문제를 해결하기 위해 비용을 측정하는 것부터 쉽지 않기 때문입니다. 다행히 재정적 비용($)은 청구서에 적힌 숫자를 통해 쉽게 확인할 수 있지만, 기술적 비용은 Engineer의 운영, 개발, 유지 보수에 들어가는 Man power 및 소모되는 시간, 기술적인 부채 등 다양한 정성적 요소들을 포함한 까다로운 측정이 필요하다는 어려움이 있습니다. 2. 비용과 배분 그렇다면 비용 최적화는 달성할 수 없는 목표일까요? 왓챠의 플랫폼 팀은 Tradeoff 문제를 풀기 위해 완벽한 최적해를 구하는 대신, 개선 가능한 영역을 식별하고 이를 통제하는 것으로 비용 최적화를 달성하고자 했습니다. 즉 산출하기 까다로운 기술 비용을 측정하려고 하는 대신, 상대적으로 확정적인 재정적인 비용을 분석해 효율화를 달성하고자 했습니다. 하지만 재정적인 비용을 분석하는 작업은 이 비용이 언제, 누가, 어떤 서비스 때문에 생성되었는가? 등의 다양한 비용의 메타 정보(Metadata)를 필요로 합니다. 이러한 메타 정보는 재정적 비용을 더 세밀하게 식별할 수 있게 해주며, 특히 비용을 대상에 대응시키는 비용의 배분(Cost allocation)을 가능케 하기 때문에 중요합니다. 3. Resource Labeling을 통한 해결 비용의 메타 정보 정의는 기술적인 영역에서 봤을 때 리소스 라벨링(Resource Labeling)으로 구현할 수 있습니다. 리소스 라벨링이란 서비스가 제공하는 Labeling, Tagging 등의 방법을 활용해 리소스에 적절한 의미를 담은 메타 정보를 정의하는 작업을 의미합니다. 리소스 라벨링을 통해 운영자는 Cloud 리소스와 같은 기술적인 재고(Inventory)에 높은 cardinality를 부여함으로써 비용의 맥락을 더 정밀하게 파악할 수 있습니다. 또한 잘 구성된 리소스 라벨링은 다음과 같은 질문에 답을 할 수 있게 합니다. Who : 이 비용은 어느 팀의, 혹은 누구의 책임인가? What : 어떤 서비스, 혹은 프로젝트에서 발생했나? Where : 어떤 환경(Dev,Test,Prod..)인가? When : 언제 생성되었나? Why : 이 리소스의 목적은 무엇인가? 따라서 왓챠의 플랫폼 팀은 기술 비용을 측정하는 대신, 리소스 라벨링을 통해 비용의 메타 정보를 세밀하게 정의함으로써 재정적 비용에 맥락을 부여하고 이를 분석해 비용 최적화를 이루고자 했습니다. 2. Labeling을 향한 여정 1. Resource Labeling의 어려움 하지만 많은 조직에서 리소스 라벨링을 통한 FinOps를 제대로 정착시키는 것은 어려운 과제였습니다. 기존의 왓챠 또한 그 많은 조직 중 하나였습니다. 기존 왓챠에서는 리소스 라벨링을 위해 라벨에 대한 컨벤션, 규약을 담은 Labeling Policy를 문서 형태로 배포하고 이를 반영한 라벨링을 수동으로 작업하도록 했습니다. 하지만 해당 정책은 문서로만 정의되어 있는 권고 사항에 불과했기 때문에 정책을 지키도록 강제하지는 못했습니다. 따라서 초기에는 조직 구성원들이 Labeling Policy를 준수해 리소스를 생성했었으나, 아래의 이유로 정책이 유명무실

  2026년 3월 10일

• 왓챠파티@무비랜드: 발견의 기쁨

  1년의 원테이크, 왓챠파티를 멈추면 안 돼! Part 3 왓챠파티@무비랜드 회고의 마지막 편입니다. 지난 1년간, 왓챠가 직접 만난 유저 한 사람, 한 사람에게 왓챠라는 브랜드가 조금 더 자연스럽게, 일상 속에 은근히 스며들기를 바랐습니다. 우리는 늘 100명의 관심보다, 꾸준히 함께할 1명과의 연결을 더 소중하게 여겨왔었어요. 왓챠파티@무비랜드는 그 ‘1명’을 만나기 위한 실험이자, 여정이었습니다. 콘텐츠 데이터를 기반으로 취향을 연결해 온 왓챠가, 온라인을 넘어 오프라인에서 유저와 마주한다면 어떤 경험이 가능할까?라는 질문에서 출발한 이 프로젝트는, 아무런 보장 없이 1년을 약속한 꽤 무모한 도전이었을지도 모릅니다. 하지만 시간이 흐른 지금, ‘왓챠파티’를 비롯해 ‘영화 선물하기’ 등 왓챠의 서비스가 오프라인 경험 속에서 자연스럽게 유저에게 연결되고, 체험된 것만큼은 분명해 보입니다. 콘텐츠를 전하는 우리만의 방식 왓챠파티@무비랜드에서 기획한 모든 테마는 ‘왓챠이기에 가능한 것’에서 출발했습니다. 왓챠만의 방식으로 구현할 수 있는지, 왓챠만의 보이스 톤이 담겨 있는지를 고민하며 시도했어요. 예를 들어 9월 ‘왓챠상차림’ 테마에서는 추석 특선 편성표를 용돈 봉투에 담아 티켓과 함께 증정했고, 실제 왓챠 서비스 상에서도 해당 편성을 따라 콘텐츠를 감상할 수 있도록 연결했습니다. 11월에는 누구나 공감할 ‘반차’와 ‘테라피’라는 키워드를 영화 감상과 연결하고, 가운을 입은 팀원들이 ‘왓챠파티 처방전’을 내려주는 등 누구나 상영할 수 있는 영화일지라도 소개 방식에 위트가 담기고 가볍게 웃을 수 있는 여유를 선물하는 방식으로 풀어냈어요. #왓챠상차림 추석 느낌 물씬 공간 영상 & 왓챠의 추석 차림표#반차테라피 왓챠팀의 처방은 왓챠파티와 사탕이었다. 마지막 회차를 준비하며 가장 어려웠던 점은, ‘어떻게 마무리다운 마지막을 만들 것인가’였습니다. 극장에서 실시간으로 왓챠파티 기능을 테스트해 보기도 하고, 연말과 연초를 지나며 다른 때보다 조금 더 오랜 시간을 들여 다양한 가능성을 놓고 고민을 이어갔습니다. 그 과정을 거치며 문득, ‘마지막’이라는 단어에 매달릴수록 오히려 본질에서 멀어지고 있다는 사실을 깨달았어요. 그리고 자연스럽게 중심으로 되돌아가게 되었습니다. 바로 왓챠와 무비랜드, 그리고 그 무엇보다도 ‘관객=유저’가 이 프로젝트의 핵심이라는 사실 말입니다. - 하나. 파티를 멈춰선 안 돼! 좌충우돌, 불같은 애드립, 진심 어린 광기. 앞선 표현들은 이 영화를 요약하는 말인 동시에 왓챠파티@무비랜드 그 자체이기도 하다. 어디로 튀어도 이상하지 않은 이 영화가 그동안 우리가 바란 모습이라면 믿을 수 있을까? 마지막 순간까지 이 광란의 목격자가 되어주길 바란다. 둘. 발견, 기쁨 그리고 영화 속 아이들은 괴짜 선생 듀이 덕(?)에 락에 심취하고, 그 과정에서 삶의 새로운 이면을 경험한다. 몇 마디뿐인 코드 진행은 누군가의 운명의 지침을 돌려놓기에 충분하다. 무비랜드와 왓챠는 영화가 그런 존재였고, 그 발견의 기쁨 덕에 여기까지 왔다. 당신 앞에 놓인 발견의 여정을 왓챠파티@무비랜드는 항상 응원한다. — 〈카메라를 멈추면 안 돼!〉 & 〈스쿨 오브 락〉 테마 소개 중 발견의 기쁨 〈카메라를 멈추면 안 돼!〉 & 〈스쿨 오브 락〉 왓챠의 슬로건이기도 한 ‘발견의 기쁨’을 테마로, 마지막 상영작은 왓챠팀과 무비랜드팀이 서로에게 영화를 추천하는 방식으로 선정되었습니다. 그렇게 선택된 두 작품 — 왓챠의 추천작 〈카메라를 멈추면 안 돼!〉와 무비랜드의 추천작 〈스쿨 오브 락〉 — 은 그 자체로 왓챠파티@무비랜드를 상징하는 메타포와도 같았습니다. 집요한 열정이 결국 원테이크 영화와 마지막 무대를 완성하는 이야기, 이 두 작품은 그간 우리가 하고 싶었던 이야기를 대신 말해주는 작품이었죠. 취향 나누기의 절정이었던 이 파티에서는, 현장에 오시는 관객분들도 본인의 취향을 나눠주길 바랐습니다. 마지막 회차의 지원 방법은 바로 ‘영화 추천’이었어요. 내가 추천한 영화가 다른 관객의 인생 영화가 되고, 추천된 작품들이 서로에게 새로운 영감을

  2025년 5월 28일

• 왓챠파티@무비랜드: 팀 크리에이티브

  낯설지만 의미 있는 선택, 〈퀸 크랩〉과 〈후 아 유〉로 본 왓챠의 감각 Part 2 왓챠파티@무비랜드 회고 두 번째 편입니다. 이번 편에서는 낯설지만 그래서 더 특별했던 기획 아이디어와 왓챠팀의 비주얼 역량이 유난히 빛났던 두 개의 테마를 소개합니다. 왓챠와의 만남이 ‘운명’처럼 느껴졌던 〈퀸 크랩〉은 제인이, 가장 오랜 시간 준비해 다각적인 기획이 빛을 발한 〈후 아 유〉는 세로가 글을 맡았습니다. 이 두 테마를 통해 왓챠팀의 감각과 실행력이 어떻게 오프라인 파티로 구현되었는지 이야기해 볼게요. 왓챠파티@무비랜드 프로젝트를 진행하면서 돌을 주문해 ‘눈알 스티커’를 붙이는가 하면, 폐조명과 연출할 ‘설탕 유리’를 만들기도 했는데요. 도움이 되는 일이라면, 모두가 자진해서 작은 것 하나라도 도전해 보곤 했습니다. 결과물을 만들기 위해 다양한 방법을 동원했고, 팀의 시너지를 가장 큰 원동력 삼아 때로는 우리가 판 무덤이다 탄식하면서도, 그 고통스러운 방식으로도 창작을 멈추지 않았습니다. 그중에서도 팀원들의 활발한 상상력과 실행력으로 완성된 6월의 테마, 〈퀸 크랩〉을 먼저 소개해 볼게요. 1회차 〈에브리씽 에브리웨어 올 앳 원스〉 돌과 2회차 〈트루먼 쇼〉 무대조명은 무비랜드에 기증되었다. - 영화를 보는 취향은 다양하다. 세상이 몰라줘도, 때로는 용기 내어 용감하게 추천하고 싶은 영화가 있다. 가끔은 이야기가 허무맹랑하고 무모할수록 만족스럽다. 조금이라도 그런 마이너 한 취향을 가지고 있다면, 당신의 DNA 깊숙한 곳에는 B의 의지가 흐르고 있다! B 필름은 용기(BRAVE) 있게 도전하고, 상식을 깨는(BREAK) 사람의 향유물. 〈퀸 크랩〉이 당신에게 B의 의지를 이어받을 수 있는 등용문이자 시험대가 되기를! — 〈퀸 크랩〉 테마 소개 중 6월, B필름 좋아하세요? 〈퀸 크랩〉 2022년 연말, 온라인을 뜨겁게 달군 ‘게’가 있었습니다. 왓챠 유저들의 입소문을 타고 바이럴이 된 영화 〈퀸 크랩〉. 왓챠도 조금 늦게 발견한 것이 아쉬울 만큼, 화제가 되었던 작품입니다. 해당 콘텐츠는 서비스 종료 직전, 왓챠 스트리밍 실시간 순위 1위를 기록하며 큰 주목을 받았고, 유저들의 요청에 힘입어 다시 왓챠에서 감상할 수 있게 되었어요. 유저들이 기억하는 이 대단한 ‘게’는 에너지 넘치는 6월의 테마로 더없이 어울리는 콘텐츠였습니다. 왓챠와의 인연도 특별했지만, 영화 자체가 가진 매력 역시 강렬합니다. 〈퀸 크랩〉은 모두가 아는 유명한 작품은 아니었지만, 한 번 보면 절대적인 재미를 선사하는 B 필름의 전형이자, 왓챠 유저들이 특히 애정하는 장르이기도 했습니다. 이런 남다른 콘텐츠로 오프라인 파티를 구현해 보고 싶다는 바람은 팀 내에서 오래전부터 있었고, 〈퀸 크랩〉은 그 바람을 실현해 줄 완벽한 선택이었죠. 다양한 취향과 장르를 아우르는 사람들이 모여 있는 곳, 왓챠이기에 가능했던 기획이기도 했습니다. 왓챠 비디오 가게 운영합니다! 우리는 〈퀸 크랩〉을 둘러싼 상상력을 하나의 설정으로 구체화했습니다. “이 영화를 빌릴 수 있는 가상의 비디오 가게가 있다면 어떨까?” 바로 느낌이 왔어요. 이 질문에서 출발해 바로 실제 비디오 플레이어와 비디오 테이프를 중고 마켓에서 구매하고, 그에 맞는 공간 연출을 기획하기로 합니다. 바로 〈퀸 크랩〉이 스탠더드인 비디오 가게 말이에요! 모든 과정은 B 필름 특유의 기이하고도 유쾌한 에너지처럼 빠르게 흘러갔습니다. 이 가상의 비디오 가게에서 열린 취향을 가진 사람들을 모으고, 왓챠엔 이런 취향을 가진 다양한 유저들이 있다는 걸 보여주기로 계획했어요. 사무실에 쌓인 중고 비디오 테이프 & ‘비디오 가게’ 티저 발행물(이런 멋진 3D 결과물은 쏘니의 골드핸드를 거친다.) 스스로 판, 창작 고통의 무덤 〈퀸 크랩〉 테마를 준비하던 2024년 5월 중순은 생성형 AI, 특히 ‘미드저니(Midjourney)’가 큰 화두였던 시기였습니다. 이를 직접 체험해 보고 싶었던 마일즈, 이스턴, 제인은 이 기회를 놓치지 않았죠. 단순히 왓챠에서 서비스 중인 콘텐츠를 소개하는 데 그치지 않고, 아직 세상에 발견

  2025년 5월 21일

이 블로그의 주제