들어가며

구독자님, 안녕하세요. 요즘 바이브코딩이나 인공지능을 통해 새로운 시도를 해보고 계신가요?

2007년 9월, 영국 브라이턴 대학교 강연장. 오픈소스 소셜 네트워크 Elgg의 공동 창업자 벤 베르뮬러(Ben Werdmüller)가 무대에 섰어요. 청중은 수만~수십만 명 규모의 소셜 네트워크를 운영하는 사람들이었죠. 다음 버전에 어떤 기능이 들어가는지 기대에 차 있었어요. 그가 빈 슬라이드를 띄우며 말했어요.

객석에서 탄성이 터졌다고 해요. 그의 요지는 이랬어요. 커뮤니티마다 필요한 것이 다른데, 플랫폼 개발자가 어떻게 모든 커뮤니티의 니즈를 알 수 있겠느냐고. 그래서 Elgg는 '기능'을 빼고 '조합할 수 있는 구조'를 넣기로 했어요. 커뮤니티 운영자가 직접 자기 커뮤니티에 맞는 기능을 골라 조립하도록 한 거예요.

18년이 지난 지금, 그의 이 철학이 전혀 다른 기술 환경에서 다시 소환되고 있어요. 에이전틱 코딩^[1]​과 오픈 프로토콜^[2]​이라는 두 흐름이 만나면서요. 오늘은 이 교차점에서 무엇이 가능해지고 있는지 이야기해 볼게요.

🏗️ "한 벌이 모두에게 맞는" 플랫폼의 구조적 한계

지난 18년간 소셜 미디어의 역사는 사실상 '획일화의 역사'였어요. 페이스북, 트위터, 인스타그램, 틱톡 등 모두 하나의 디자인, 하나의 규칙, 하나의 알고리즘을 전 세계 수십억 명에게 동일하게 적용했죠.

문제는 이 획일적 설계 안에 개발팀의 문화적·지적 전제가 그대로 녹아 있다는 점이에요. 멘로파크(Menlo Park)에 본사를 둔 팀이 미얀마 로힝야족의 커뮤니티 역학을 이해할 수 있었을까요?

결과는 참혹했어요. UN 독립 국제 사실 조사단은 2018년 보고서에서 페이스북이 로힝야족에 대한 혐오 표현을 확산시키는 데 "결정적 역할(determining role)"을 했다고 결론 내렸어요. 미얀마에서 페이스북은 단순한 소셜 미디어가 아니라 사실상 인터넷 그 자체였거든요. 당시 미얀마 인터넷 이용자의 대다수가 페이스북만을 통해 정보를 소비하고 있었고, 페이스북의 버마어 콘텐츠 검토 인력은 1,800만 명의 활성 사용자 대비 단 2명이었어요.

이건 단순한 운영 실패가 아니에요. 하나의 플랫폼이 하나의 세계관으로 전 세계를 커버하려 할 때 발생하는 구조적 한계예요. 어떤 커뮤니티는 정체성에 관한 특별한 요구 사항이 있고, 또 어떤 커뮤니티는 고유한 문화적 민감성을 신뢰와 안전 정책에 반영해야 해요. 획일적 플랫폼은 이런 요구를 무시하거나 아예 인지하지 못해요.

🔧 에이전틱 코딩이 바꾸는 '만들기'의 경제학

그런데 최근 몇 년 사이, 코드를 만드는 비용 구조 자체가 바뀌고 있어요.

LLM 기반 에이전틱 코딩이 '흥미로운 도구' 수준을 넘어 실질적인 코드 생산 엔진으로 자리 잡았어요. 벤 베르뮬러의 글에서 인상적인 대목이 있어요. 30년 이상 소프트웨어를 직접 작성해온 시니어 엔지니어들, Perl 프로그래밍 언어를 관리했던 제시 빈센트(Jesse Vincent), Datasette의 창시자이자 Lanyrd의 공동 창업자 사이먼 윌리슨(Simon Willison) 같은 베테랑들이 이제 LLM을 풀타임 코딩 엔진으로 쓰고 있다는 거예요. 만약 LLM이 코딩에 쓸모없었다면, 이 사람들이 가장 먼저 그렇게 말했을 거예요. 하지만 그 반대가 일어났죠.

이건 개발자 생산성의 이야기가 아니에요. 소프트웨어 생산의 진입 장벽이 근본적으로 낮아진다는 이야기예요. 과거에는 커뮤니티가 자체 플랫폼을 만들려면 개발팀을 꾸려야 했어요. WordPress나 Elgg 같은 오픈소스 프로젝트를 써도 커스터마이징에는 상당한 개발 역량이 필요했죠.

여기서 두 가지 새로운 흐름이 주목할 만해요.

첫째, 시민 개발자(Citizen Developer)의 부상이에요. 시민 개발자란 IT 부서나 전문 엔지니어가 아닌, 현업 담당자가 직접 자기 업무에 필요한 소프트웨어를 만드는 사람을 뜻해요. 원래는 로우코드·노코드^[3]​ 플랫폼의 맥락에서 등장한 개념인데, 에이전틱 코딩과 만나면서 가능성이 폭발적으로 넓어지고 있어요. 가트너는 대기업에서 시민 개발자가 전문 개발자의 4배에 달할 것으로 전망한 바 있어요. 커뮤니티 맥락에서 보면 이건 곧 커뮤니티 리더가 곧 플랫폼 빌더가 될 수 있다는 이야기예요.

둘째, 포워드 개발자(Forward Dev)라는 역할 전환이에요. 전통적 개발자의 역할이 코드 작성에서 아키텍처 설계, AI 에이전트 오케스트레이션, 품질 검증 쪽으로 '전진(forward)'하고 있어요. 2026년까지 개발자의 75%가 직접 코딩보다 설계와 오케스트레이션에 더 많은 시간을 쓸 것이라는 전망도 나와요. 쉽게 말하면, 시민 개발자가 '만드는 사람'의 저변을 넓히고, 기존 개발자는 더 높은 수준의 설계와 품질 관리로 이동하는 이중 확장이 일어나고 있는 거예요.

이 두 흐름이 합쳐지면, 커뮤니티 소셜 플랫폼의 풍경이 근본적으로 달라져요. 커뮤니티 리더(시민 개발자)가 "우리 커뮤니티에는 이런 기능이 필요해"라고 말하면 AI가 코드를 생성하고, 포워드 개발자가 아키텍처와 안전성을 검증하는 구조가 가능해지는 거죠.

하지만 여기서 한 가지 문제가 생겨요. 모든 커뮤니티가 각자의 맞춤형 소프트웨어를 만들면 어떻게 될까요? 수천, 수만 개의 고립된 섬이 만들어지는 거예요.

🌐 오픈 프로토콜: 고립된 섬들을 잇는 다리

바로 여기서 오픈 프로토콜의 역할이 중요해져요.

웹이 HTTP와 HTML이라는 오픈 프로토콜 위에 돌아가는 것처럼, 차세대 소셜 플랫폼들도 오픈 프로토콜 위에 구축되고 있어요. 현재 두 가지 주요 프로토콜이 경쟁하며 생태계를 형성하고 있죠.

ActivityPub은 W3C가 2018년 권고 표준으로 채택한 프로토콜이에요. 서로 다른 커뮤니티 플랫폼이 사용자를 대신해 메시지를 주고받을 수 있게 해줘요. 마스토돈(Mastodon), 고스트(Ghost), 그리고 메타의 스레드(Threads)까지 이 프로토콜로 연결돼 있어요. 쉽게 말하면 '각자 다른 소셜 서비스를 쓰면서도 서로 소통할 수 있게 해주는 공통 언어'인 셈이에요.

ATProto(Authenticated Transfer Protocol)는 블루스카이(Bluesky)가 개발한 프로토콜이에요. 사용자의 정체성과 데이터 이동성에 더 초점을 맞추고 있어요. 자신의 도메인을 아이디로 쓸 수 있고, 서비스를 옮겨도 데이터와 팔로워를 그대로 가져갈 수 있죠. ActivityPub이 '서버 간 소통'에 초점을 맞춘다면, ATProto는 '사용자 중심의 데이터 주권'에 무게를 두고 있어요.

핵심은 이거예요. 두 프로토콜 모두 누구나 호환 가능한 새로운 플랫폼을 만들 수 있다는 것이에요. HTTP와 HTML 명세만 따르면 누구나 웹 브라우저를 만들 수 있는 것처럼, ActivityPub이나 ATProto 명세를 따르면 누구나 소셜 플랫폼을 만들 수 있고, 그 플랫폼은 기존 생태계와 즉시 호환돼요.

그동안 오픈 프로토콜은 '소수의 애플리케이션이 여러 인스턴스로 운영되는 것'을 조율하는 역할이었어요. 마스토돈 서버 수천 개가 서로 소통하는 식이죠. 하지만 에이전틱 코딩으로 소프트웨어 생산이 폭발적으로 늘어나면, 오픈 프로토콜의 역할이 근본적으로 달라져요. 폭발하는 맞춤형 애플리케이션 생태계를 연결하는 조율 레이어가 되는 거예요.

🧩 빠진 퍼즐 조각들: 신뢰·안전, 그리고 가치 정렬

물론 커뮤니티 플랫폼을 만드는 것과 커뮤니티를 '안전하게' 운영하는 것은 다른 문제예요.

콘텐츠 관리, 신고 시스템, 악용 방지 같은 신뢰와 안전(Trust & Safety) 기능은 커뮤니티 운영의 핵심이에요. 그리고 바로 이 부분이 '맞춤형 커뮤니티 플랫폼'이 필요한 가장 큰 이유이기도 해요. 학대의 신호는 커뮤니티마다 다르고, 안전의 기준도 문화마다 달라요. 페이스북이 미얀마에서 실패한 것이 정확히 이 이유예요.

벤 베르뮬러는 이 문제에 대한 해법도 오픈 프로토콜에서 찾아요. 신뢰와 안전을 위한 전용 오픈 프로토콜이 있다면, 커뮤니티 운영자가 서드파티 안전 도구와 연결할 수 있어요. 비슷한 가치관을 가진 여러 커뮤니티가 자원을 모아 공동의 콘텐츠 관리 시스템을 운영할 수도 있고요.

그리고 한 가지 더 근본적인 질문이 있어요. 코드를 생성하는 AI 자체의 가치 정렬 문제예요.

현재 대부분의 LLM은 실리콘밸리의 문화와 전제를 반영하고 있어요. 학습 데이터의 편향은 이미 여러 연구에서 문서화되어 있죠. 진정으로 커뮤니티 중심의 소프트웨어를 만들려면, 그 소프트웨어를 생성하는 AI 자체가 커뮤니티의 가치와 정렬되어야 해요.

이 방향에서 주목할 만한 움직임이 있어요. 소형 언어 모델(SLM)^[4]​은 소수 언어와 문화권에 특화된 AI를 만드는 데 쓰이고 있어요. 브루킹스 연구소의 2025년 보고서에 따르면, SLM은 소규모 데이터셋으로도 특정 언어에 맞춘 도구를 개발할 수 있어서 원주민 언어 보존과 활성화에 활용되고 있어요. 캐나다 밀라(Mila) 연구소의 FLAIR 프로젝트는 북미 원주민 언어를 위한 음성 인식 AI를 커뮤니티와 함께 개발하고 있고요. 2025년 11월에는 모질라 데이터 컬렉티브(Mozilla Data Collective)가 공식 출범해서, 286개 언어로 된 300개 이상의 데이터셋을 커뮤니티 주도로 관리하고 있어요. 데이터 제공자가 자신의 데이터 사용 조건을 직접 설정할 수 있는 구조예요.

오스왈드의 시선

솔직히 말하면, 저는 이 글을 읽으면서 GTM 전략 컨설턴트로서 느낀 것이 있어요. 벤 베르뮬러가 제시하는 그림은 이상론이 아니라 시장 구조의 변화에 가까워요. 소프트웨어 생산 비용이 급락하면, '규모의 경제'로 유지되던 플랫폼 독점 구조가 흔들리거든요.

제가 주목하는 건 채널 전략이에요. 지금까지 커뮤니티는 '기존 플랫폼에 입주하는 세입자'였어요. 오픈 프로토콜 기반의 맞춤형 플랫폼은 커뮤니티에게 '자가 소유 채널'을 가능하게 해요. 이건 커뮤니티의 채널 주권 이야기예요.

시민 개발자와 포워드 개발자의 등장은 이 구도를 가속시켜요. 다양한 규모의 기업전략을 수립하면서 반복적으로 봐온 패턴인데, 새로운 도구가 등장할 때마다 '누가 만드는가'의 경계가 재설정돼요. 엑셀이 재무 분석을, 캔바가 디자인을 민주화했듯이요. 시민 개발자가 '초안'을 만들고 포워드 개발자가 프로덕션 수준으로 끌어올리는 협업 모델 등 이건 제가 실무에서 자주 설계했던 빌드-검증 분리 구조와 같은 논리예요.

다만 한 가지. 기술이 민주화되면 결국 생태계는 다시 몇 개의 허브를 중심으로 재편돼요. '누가 프로토콜 명세를 관리하는가'에 새로운 형태의 권력이 집중될 가능성이 높아요. 커뮤니티가 기술적 자율성을 실제로 행사할 거버넌스를 갖추고 있는가? 이게 남는 질문이에요.

마치며

정리하면 이렇게 볼 수 있어요.

첫째, 획일적 플랫폼의 한계는 미얀마 사례가 보여주듯 기술적 결함이 아니라 구조적 문제예요. 하나의 세계관으로 전 세계 커뮤니티를 서비스하는 모델은 근본적으로 한계가 있어요.

둘째, 에이전틱 코딩과 오픈 프로토콜의 결합은 커뮤니티가 자기 자신에게 맞는 공간을 직접 만들면서도 서로 연결될 수 있는 가능성을 열고 있어요. 시민 개발자가 '만드는 사람'의 저변을 넓히고, 포워드 개발자가 품질과 안전을 담보하는 이중 구조가 이 가능성을 현실로 만들고 있어요.

셋째, 진짜 어려운 문제는 코드가 아니라 사람이에요. 신뢰와 안전, AI의 가치 정렬, 커뮤니티 거버넌스 등 기술이 쉬워질수록 이런 인간적 질문이 전면에 떠올라요.

벤 베르뮬러가 쓴 문장이 계속 머릿속에 남아요. "코드가 해결된 문제가 되면, 결국 인간적인 것들이 가장 중요한 자리로 올라온다." 무엇이 필요한지, 왜 필요한지, 누구를 위한 것인지. 멘로파크의 누군가가 아니라, 커뮨니티 자신이 그 답을 정의하는 시대가 오고 있어요.

참고자료 & 더 읽기

핵심 출처

배경 지식

필자 안광섭은 세종대학교 경영학과 교수이자 OBF(Oswarld Boutique Consulting Firm) 리드 컨설턴트이다. 대학에서 경영데이터 관리, 비즈니스 애널리틱스 등 데이터 분석을 가르치는 한편, 현장에서는 GTM 전략과 인공지능 전략 컨설팅을 이끌며 기술과 비즈니스의 접점을 설계하고 있다. AI 대화 시스템의 기억 아키텍처(HEMA) 연구로 학술 논문을 발표했으며, 매일 글로벌 AI 논문을 큐레이션하는 Daily Arxiv 프로젝트를 운영하고 있다. 고려대학교 KBMA와 기술경영전문대 석사과정을 졸업했다. 지은 책으로 《생각을 맡기는 사람들: 호모 브레인리스》가 있다.