크리에이터 앱, 그 예시와 기술적 기반

지난 여름 주거 문제로 연남동에 묵는 동안 크리에이터 앱이라는 아이디어를 정립했습니다. 그 지역의 작고 창의적인 브랜드의 가게들, 카페들, 음식점들이 영감이 되었습니다. 많은 브랜드를 가로지르는 플랫폼을 만들기보다는 각 브랜드의 고유한 맥락에 맞는 여러가지 앱을 연재하는 것이 핵심입니다.

그리고 며칠 전 예시로서 Pillars 앱을 런칭했습니다. 그동안 기능우선, utility-first로 개발되었던 앱 개발의 단위를 특정 크리에이터의 고유한 스토리텔링으로 대체하고, 소프트웨어 개발의 비지니스 또한 개발을 위한 기능 조직에서 창의적 협업 creative collaborations로 전환하려는 시도입니다.

그 이전에 저는 여러 해 동안 사회 진보를 이해하기 위해 생명의 역사, 인류사, 근대화의 본질을 탐구해왔습니다. 그 결론 중 하나는 가치생산의 단위가 더 작고 질적인 수준으로 쪼개지고, 그 작은 조직들이 보다 유기적으로 협업해야만 지금의 사회모델이 갖는 한계를 극복할 수 있다는 것입니다. 지금 자주 쓰이는 말로 환언하면 대기업이 융해하여 1인 기업과 소규모 팀들이 나타나는 것, 서로 경쟁이 일어나지 않는 독자적인 가치, 가능하면 물질을 덜 소비하는 가상적, 질적인 경험의 공유를 통해 사회가 연대하는 것이죠.

이런 디지털 르네상스의 이상은 가능할까요? 유럽의 종교개혁과 르네상스는 교회의 권위를 의심하게 만든 흑사병의 맹렬한 파급력에 대한 인간 이성의 응답이었습니다. 그 결과 전통사회에서 천대받던 상업분야가 혁명을 이뤄냈고 근대화를 이끌었습니다. 저는 지금 소셜 미디어와 AI가 흑사병보다 덜 위협적이라고 생각하지 않습니다. 16세기 네덜란드 상인들이 행상에서 탐험가로, 자본가로 일어난 것처럼, "전산직"으로 불리던 소프트웨어 개발자들이 파운더, 메이커로서 이 위협적인 힘을 혁명으로 전환해낼 수 있습니다.

한 층 구체적인 차원에서 제가 지켜보는 각은 크리에이터 경제, the creator economy와 한계비용 제로사회, The Zero Marginal Cost Society의 도래입니다. 에너지, 인공지능, 반도체, 배터리 분야에서 보다 기술적인 혁신이 있겠습니다만 저는 사회, 특히 헤겔의 인정이론에 기초한 사회변화에 조금 더 중점을 두고 있습니다. 이것이 이번의 크리에이터 앱 아이디어의 배경입니다.

이 글은 처음부터 새로 쓰긴 했습니다만, 제 Substack에 작성한 3개 포스트의 요약본/합본 성격도 있습니다.

창의적 협업 Creative collaborations

크리에이터의 역할은 단순히 영향을 미치는 것이 아니라, 사람들 사이에 변화를 만들고 그 변화를 관리하는 것입니다. 처음엔 "컨텐츠 크리에이터"의 줄임말이었습니다. 소셜 미디어 플랫폼들이 관심을 판매하는 광고 플랫폼 대기업이 되어 컨텐츠로 관심을 일으키는 일을 외주한 것이죠. 비지니스 관점에서 이들을 바라보는 표현이 influencer입니다. 다른 건 몰라도 영향력이 있다는 것입니다.

저는 한동안 인플루언서로 덮인 소셜 미디어의 표면만을 보고 업신여겼습니다. 거품같았거든요. 하지만 그 틈바구니에서 크리에이터를 주축으로 한 교육 비지니스가 성장하는 것을 보고 완전히 생각을 바꿨습니다. 이 새로운 교육의 모델은 전통적인 교육 모델과 흡사 달라서, 가르침보다는 실험, 혹은 프로젝트에 오히려 가깝습니다. 맞는 답을 정해놓고 분량을 커버하는 것보다는 스스로 실천적인 목표를 설정하고 코칭을 제공하는 것입니다. John Dewey를 비롯한 진보적인 사상가들의 교육관이 지금 디지털 기술로 인해 물꼬를 트고 있다고 해석할 수도 있습니다.

크리에이터 경제라고 하면 모든 것이 혼재된 시장 규모를 보겠습니다만, 상업에 복무하여 자신이 만들지 않은 어떤 제품과 서비스에 대한 결제를 유도하는 인플루언서와, 인간 정신활동과 그 발전에 직접 참여하는 교육자로서의 크리에이터 사이에는 중요한 경계선이 있습니다.

저는 그래서 크리에이터가 create 하는 것은 미디어 컨텐츠를 넘어 변화, change로 확장된다고 생각합니다. 시장조직이 거래를 통해 서로 활동의 가치를 인정하고 신뢰를 쌓듯이, 모두가 크리에이터인 현대사회에서는 창의적 협업, creative collaborations가 가치 생산의 엔진입니다.

여전히 미디어 활동에 의존적인 크리에이터들은 성장과정에서 파운더로의 변화를 시도하곤 합니다. 그래야 극복할 수 있는 개인적인, 또 비지니스 차원에서의 한계들이 있기 때문이죠. 앱 만들기는 그 중 한가지입니다.

하지만 앱 만들기는 비싸고 어렵습니다. 팀을 경영하거나, 외주를 맡기거나, 워드프레스와 씨름하거나, 똑같이 많은 시간과 노력, 리스크 관리가 필요합니다. 미디어 제작에 맞춰진 크리에이터의 업무 흐름에서는 현실적으로 어려운 일이죠. 아마도 현재로써는 노션을 비롯한 노코드 툴을 사용해 안전한 기능만을 사용하는 것이 낫겠습니다.

반대로 이미 테크 파운더라면, 소규모 팀이나 심지어는 개인도 앱을 만들 수 있도록 도와주는 생태계, 도구, 공급처가 너무 많아졌습니다. 하지만 바로 그 이유 때문에 소프트웨어 개발이 대중화되고 기술적인 차원에서의 버티컬 혹은 niche는 남아나지 않게 되었습니다.

이 둘은 서로의 문제를 해결할 수 있습니다. 크리에이터는 파운더에게 경쟁이 불가능한 버티컬, 즉 크리에이터 자신의 브랜드와 고유한 맥락, 스토리텔링을 제공합니다. 파운더는 기술적인 바탕과 운영을 제공합니다. 크리에이터는 앱 하나 만들고 버릴 스택을 공부하지 않아도 되고, 파운더는 가망 없는 자신의 유튜브 채널을 보며 괴로워하지 않아도 됩니다.

Pillars 필라스 — 오늘의 신탁

크리에이터 앱의 예시를 제공하고 저 스스로 작은 앱을 연재할 수 있는 스택을 테스트하기 위해 필라스라는 사주명리 앱을 만들었습니다. 영미권에 거주하는 젊은 동아시아인들이 새로운 형태로 사주를 접할 수 있도록 그래픽과 좋은 번역을 제공하는 것이 기획의도입니다.

네 양띠입니다.

이렇게 하나의 만세력을 만드는 데에도 수십가지 의사결정이 필요합니다. 기존의 기눙우선적, 합리주의적 관점을 가져온다면 가장 알맞은 답을 찾아나가야겠죠. 고유함보다는 더 많이, 더 빨리, 더 자주, 더 세게, 더 "좋은" 결정을 내려야하는 것이 근대성의 덕목이니까요.

하지만 이 앱은 사용자의 범위가 어떤 크리에이터의 팔로워들이기 때문에, 자신만의 목소리를 가질 수 있습니다.

십천간과 십이지지의 한자는 물상을 형상화한 그래픽으로 대체되었습니다. 한자는 영미권에서는 읽기 어렵고, 원래 한자는 상형문자이기도 하니까요.
십천간, 십이간지, 십성, 십이운성은 모두 새롭게 번역됐습니다. 번역의 적확성을 따질 필요가 없습니다. 크리에이터 마음이고 사용자는 다른 만세력을 써도 되니까요.
십년대운, 육친 등 젠더와 가족구성원에 대한 해묵은 편견을 정당화할 여지가 있는 내용은 완전히 제거하도록 Claude에게 일러두었습니다.

물론 이런 결정을 내리기 전에 만세력에 대한 이해와 영문 12개, 한국어, 일본어, 중국어 각 3개 만세력에 대한 분석이 있었습니다. 그냥 몰라서 틀리는 건 결정이 아니니까요.

아래는 새 번역을 표현한 그래픽들입니다.

갑, 을, 병, 정, 등의 십천간입니다.

생극제화, 비견, 겁재, 식신, 상관, 등의 십신입니다.

태, 양, 장생, 목욕, 등의 십이운성입니다.

흥미로웠던 것은, 아니나 다를까 사주명리와 만세력에 대해 "무엇이 옳은가"에 관한 논의가 있다는 것입니다. 저는 개인적으로 사주를 비롯해 문화의 구성요소에 대해 주술적/종교적 입장을 갖지는 않습니다. 내 사주를 본다는 것은 이야기를 만들어 내 삶을 돌아볼 수 있는 계기로 삼는 것이지, 내 정신과 문화권의 담론을 벗어나 객관성에 도달하는 요소가 있다고 보지 않는 것이죠

하지만 예언적 능력을 바라는 경우에는 적확성을 따지는 경우가 있었습니다. 한국에서는 일본 도쿄를 기준으로 맞춰진 타임존을 30분씩 수정하기도 하고, 시간과 날이 동시에 바뀌는 현대의 시간 개념에 맞춰 야자시/조자시 개념을 도입하기도 합니다.

의미가 있을까요? 원래 만세력은 동지를 기준으로 해가 넘어갑니다. 그레고리력에서는 12월 21일 즈음이죠. 하지만 한국 만세력에서는 희한하게도 설날이 되어야 해가 넘어갑니다. 무려 한 달 정도 되는 정확성의 논란이 생깁니다. 야자시/조자시 또한 마찬가지입니다. 날이 넘어가는 동시에 00시 00분이 되는 우리의 시간과 달리 태양태음력에서는 날의 기운이 자시의 중간에, 해의 기운은 자월의 중기에 넘어갑니다. 이걸 이해하거나 설명하기 어렵다고 해서 야자시/조자시 를 도입한다면 적확성을 논의할 필요는 없지 않을까요?

크리에이터 앱에서는 각 크리에이터의 관점을 존중하기 때문에 이런 논란에서 자유롭습니다. 옳고자 하는 의지를 일찍이 내려놨기 때문이죠. 이것이 크리에이터 앱이 갖는 문화적 함의입니다. 합리성에서 다양성으로 나아가는 것입니다.

Elixir 엘릭서, HTMX, Tailwind

마지막으로 스택을 간략하게 소개하고 줄이겠습니다.

인디 메이커로서, 엘릭서를 알게된 건 천운이었다고 생각합니다. 대개는 시니어나 CTO수준에서 고려할만한 도입률을 갖고있어서, 테크분야에서 정식으로 업무경험이 없는 저는 정말 얻어걸린 기술입니다.

Mix.install([:bandit])

Bandit.start_link(plug: fn conn, _opts ->
  Plug.Conn.send_resp(conn, 200, "hello world")
end)

엘릭서로 쓴 4줄짜리 웹서버

엘릭서 생태계는 Phoenix라는 짱짱한 웹 프레임워크가 널리 쓰입니다만, 크리에이터 앱을 위해서는 짱짱함보다는 가벼움과 유연성을 갖고싶어서 Elixir.Plug라는 보다 기본적인 인터페이스를 활용하기로 했습니다.

Umbrella 프로젝트는 설정과 디펜던시를 공유하는 여러 앱을 한 개 프로젝트에서 관리할 수 있는 엘릭서 믹스의 기능입니다. 모노리포와는 비슷하면서도 차이가 있습니다. 엘릭서 커뮤니티에서 인기가 없는 기능이지만, 크리에이터 앱들이 공유하는 부분을 통합할 수 있다면 좋은 용례가 될 것 같아서 도입했습니다.

이렇게 서버에서 JS를 쓰지 않고 웹 앱을 만들고자 한다면, HTMX가 흥미로운 접근방식이 될 수 있습니다. HTMX는 JS를 안쓰게 해주는 JS 라이브러리입니다. JSON을 주고받아서 JS 로직으로 화면을 보여주는 대신 서버에서 마크업을 다시 보내는 방식으로 앱을 만들고, 코드도 전부 HTML에 작성하게 해줍니다.

<script src="https://unpkg.com/htmx.org@2.0.3"></script>

<button hx-post="/clicked">
  Click Me
</button>

버튼을 누르면 버튼이 /clicked가 보내준 마크업으로 대체되는 식입니다.

React. 🤮. 죄송합니다. React.js가 만연한 지금의 JSON 패러다임과는 다르게 HTMX는 REST 웹 아키텍처의 철학을 이어받아 앱 상태 엔진으로서의 하이퍼텍스트, Hypertext as the Engine of Application State에 충실한 패러다임으로 웹 앱 만들기를 재정의하고 있습니다.

HTMX가 로직을 마크업으로 회수한다면, 잘 알고 계실 Tailwind는 스타일을 마크업으로 회수합니다. 이제 Tailwind는 필수가 되어서 달리 설명할 필요가 없겠습니다. 조만간 v4.0도 나올 예정이죠.

저는 이러한 구성이 웹을 더 웹답게 만든다고 생각합니다. CSS와 JS를 쓰기 시작하면 개발자가 클래스명과 함수명을 지어내기 시작해야합니다. 하지만 웹은 국제사회가 함께 관리하는 공적 인프라로서 그 어휘 또한 국제적으로 공유된 것이어야한다는 것이 REST의 원칙입니다. HTML 스펙만이 이런 원칙에 항상 충실해왔습니다.

HTMX는 JS의 대부분을, Tailwind는 CSS의 대부분을 이미 잘 정의되고, 공유되고, 문서화된 형태로 협업에 이용될수 있게 해줍니다.

이외에 크로스 도메인 passkey 본인인증을 위한 web authentication API와, 왜인지 몰라도 이 API를 제공하지 않는 메타 인앱 브라우저를 위해 약간의 JS 작업도 들어갔습니다.

const credential = await navigator.credentials.create({ publicKey })

location = "googlechrome://" + location.href.replace("https://", "")
location = "x-safari-" + location.href
location = "intent:" + location.href + "Intent;end"