<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="ko-Hang-KR">
  <id>https://writings.hongminhee.org/feed.ko-hang-kr.xml</id>
  <link rel="self" type="application/atom+xml" href="https://writings.hongminhee.org/feed.ko-hang-kr.xml" />
  <link rel="alternate" type="text/html" href="https://writings.hongminhee.org/" />
  <generator uri="https://github.com/dahlia/jikji">Jikji</generator>
  <title>洪民憙雜記</title>
  
    <author>
      <name>홍민희</name>
      
        <uri>https://hongminhee.org/</uri>
      
      
    </author>
  
  <updated>2026-04-17T08:52:06.579Z</updated>

  
    <entry>
     <title>한글 전용 하의 한자 교육에 관하여</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/04/hanja-education/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/04/hanja-education/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/04/hanja-education/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/04/hanja-education/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/04/hanja-education/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-04-17T09:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.579Z</updated>
     <content type="html">&lt;h1&gt;한글 전용 하의 한자 교육에 관하여&lt;/h1&gt;
&lt;p&gt;나는 한국어를 쓸 때 국한문혼용체를 즐겨 쓴다. 블로그 글도, 소셜 미디어 포스트도
한자를 섞어 쓸 때가 많다. 한자에 대한 개인적 애착은 분명히 있다. 그런데도 한자
교육을 한국의 공교육에서 심화해야 한다는 주장에는 동의하지 않는다. 이 글은 그
이유를 설명하려는 시도다.&lt;/p&gt;
&lt;h2&gt;교육의 디폴트는 &lt;q&gt;가르치지 않는다&lt;/q&gt;이다&lt;/h2&gt;
&lt;p&gt;교육은 비용이 많이 든다. 교사를 양성해야 하고, 교재를 만들어야 하고, 무엇보다
학생들의 시간을 써야 한다. 학생의 시간은 유한하므로, 어떤 과목을 교육 과정에
넣는다는 것은 다른 과목에 쓸 수 있었을 시간을 빼앗는다는 뜻이기도 하다. 그렇기
때문에 어떤 과목이든 교육 과정에 포함하려면 그 효용이 과학적으로 입증되어야
한다. 배우면 도움이 될 것이라는 막연한 기대로는 부족하다. 도움이 되지 않는
교육이란 없기 때문이다. 바느질도 배우면 도움이 되고, 목공도 배우면 도움이 된다.
문제는 한자 교육이 도움이 되느냐가 아니라, 같은 시간을 투입했을 때 &lt;strong&gt;다른
교육보다&lt;/strong&gt; 더 도움이 되느냐이다.&lt;/p&gt;
&lt;p&gt;한자 교육이 한국어 문해력 향상에 도움이 된다는 과학적 근거는 현재로서는 없다.
종종 한자를 알면 한국어 어휘력이 좋아진다는 주장이 있지만, 이를 뒷받침하는
체계적인 연구는 찾기 어렵다. 교육 정책은 직관이 아니라 근거 위에 서야 한다.
효용이 입증되지 않는 한 디폴트는 언제나 &lt;q&gt;가르치지 않는다&lt;/q&gt;이고, 이는 한자
교육에도 마찬가지로 적용된다.&lt;/p&gt;
&lt;h2&gt;국한문혼용체의 이점과 현실론&lt;/h2&gt;
&lt;p&gt;솔직히 말하면, 국한문혼용체가 어문 정책적으로 이점이 많다고 생각한다.
한자문화권의 다른 언어와의 접점이 넓어지고, 텍스트의 정보 밀도가 높아진다.
모르는 단어를 마주했을 때 대충 추측해서 넘어가지 못하고, 사전을 찾아보게
만드는 효과도 있다. (그게 불편해서 싫다고 할 사람도 많겠지만.)
동형이의어 구별도 쉬워지는데, 이 마지막 이점은 사람보다는 기계에게 더 의미가
있다. 사람은 맥락이 충분하면 동형이의어 때문에 곤란을 겪을 일이 드물지만, 검색
엔진이나 자연어 처리 시스템은 그렇지 않다. 국한문혼용체는 텍스트를 더 기계
친화적(machine-readable)으로 만든다.&lt;/p&gt;
&lt;p&gt;하지만 이 장점들은 한자가 일상적으로 쓰이는 환경을 전제한다. 한국에서 한글
전용이 정착된 지 반 세기에 가까워진 지금, 한자를 읽을 수 있는 한국인의 비율은
이미 크게 낮아졌다. 이 상황에서 국한문혼용체의 이점을 말하는 것은, 영어가
아무리 현실적으로 유용하다 해도 한국에서 영어를 공용어로 삼을 수 없는 것과
비슷한 구조이다. 이론적 이점이 있다는 것과 지금으로부터 그것을 실현할 수 있다는
것은 별개의 문제다.&lt;/p&gt;
&lt;p&gt;내 입장을 한마디로 정리하면 이렇다. 애초에 한글 전용을 하지 않았다면 좋은 점이
많았을 것이다. 하지만 이제 와서는 돌이킬 수 없다. 한글 전용을 계속해야 한다는
현실을 받아들여야 한다.&lt;/p&gt;
&lt;h2&gt;한자 혼용 없는 한자 교육의 역설&lt;/h2&gt;
&lt;p&gt;한국의 한자 교육 논의에서 흔히 보이는 입장이 있다. 한자 혼용은 반대하지만 한자
교육은 찬성한다는 것이다. 이 입장은 언뜻 타협적으로 보이지만, 실은 모순에
가깝다고 생각한다. 배운 것은 써야 유지된다. 한자를 학교에서 배워도 졸업 후
일상에서 한자를 마주칠 일이 없다면, 그 지식은 빠르게 휘발되고 만다. 사용 맥락
없는 지식의 유지 비용은 과도하게 높다. 한글 전용인 한국 사회에서 한자 교육은
수영장 없이 수영을 가르치는 것과 다르지 않다.&lt;/p&gt;
&lt;p&gt;나 자신의 한자 지식이 어떻게 유지되어 왔는지를 돌아보면, 이 논점은 더
분명해진다. 나는 국민학교 시절 한자 교육을 어느 정도 받았다. 하지만
그것만으로는 충분하지 않았다. 무협지를 좋아해서 한자에 계속 노출되었고,
고등학교에서 제2외국어로 중국어를 배웠고, 성인이 된 뒤에는 일본어를 배우면서
한자를 까먹지 않을 수 있었다. 정규 교육이 씨앗을 뿌렸을 수는 있지만, 그것을
유지한 건 전적으로 개인적 동기와 지속적 노출이었다. 이는 두 가지를 시사하는데,
한자에 관심이 있는 사람은 공교육이 없어도 스스로 배울 수 있다는 것과, 관심이
없는 사람에게는 공교육이 있어도 지식이 남지 않는다는 것이다. 어느 쪽이든
공교육에서의 한자 교육을 정당화하기는 어렵다.&lt;/p&gt;
&lt;h2&gt;취향과 정책의 구분&lt;/h2&gt;
&lt;p&gt;한자를 좋아하는 것과 한자 교육을 한국의 공교육에서 해야 한다고 주장하는 것은
전혀 다른 이야기이다. 나는 한자를 좋아한다. 한자의 구조가 주는 지적 즐거움을 잘
알고, 국한문혼용체로 글을 쓸 때의 묘미도 잘 안다. 하지만 그것은 나의 취향이지,
모든 학생에게 부과할 교육의 근거는 아니다. 교육 정책은 개인의 취향이나 향수가
아니라, 과학적 근거와 기회비용의 비교 위에서 결정되어야 한다. 한자 교육의
효용이 입증되지 않은 한, 그리고 한글 전용이라는 현실이 바뀌지 않는 한, 한자
교육을 한국의 공교육에 포함할 이유는 없다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>합법이면 공정한가: AI 재구현과 카피레프트의 침식</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/legal-vs-legitimate/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/03/legal-vs-legitimate/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/legal-vs-legitimate/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/legal-vs-legitimate/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/legal-vs-legitimate/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/legal-vs-legitimate/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-03-09T15:10:00.000Z</published>
     <updated>2026-04-17T08:52:06.578Z</updated>
     <content type="html">&lt;h1&gt;합법이면 공정한가: AI 재구현과 카피레프트의 침식&lt;/h1&gt;
&lt;p&gt;지난 주, Python 텍스트 인코딩 탐지 라이브러리인 chardet의 메인테이너 Dan
Blanchard가 &lt;a href=&quot;https://github.com/chardet/chardet/releases/tag/7.0.0&quot;&gt;새 버전을 릴리스했다&lt;/a&gt;. chardet 7.0은 속도가 기존 대비 48배
빨라졌고, 멀티코어를 지원하며, 설계부터 다시 짜여졌다. Anthropic의 Claude가
기여자로 등재되어 있다. 그리고 라이선스가 LGPL에서 MIT로 바뀌었다.&lt;/p&gt;
&lt;p&gt;Blanchard의 말에 따르면 자신은 코드를 보지 않고 API와 테스트 스위트만을 참조해
Claude에게 처음부터 재구현하도록 지시했고, 그 결과 이전 버전과의 코드 유사도가
1.3% 미만이라고 한다. 따라서 이것은 독자적인 새 저작물이며 LGPL을 계승할 의무가
없다는 것이다. 원작자 Mark Pilgrim은 &lt;a href=&quot;https://github.com/chardet/chardet/issues/327&quot;&gt;GitHub 이슈를 열어 항의했다.&lt;/a&gt; LGPL은 수정
배포 시 동일 라이선스 유지를 요구하는데, 기존 코드에 충분히 노출된 상태에서
만든 재구현은 클린 룸이라고 볼 수 없다는 것이 그의 주장이다.&lt;/p&gt;
&lt;p&gt;이 사건은 Flask의 창시자 Armin Ronacher와 Redis의 창시자 Salvatore
Sanfilippo(이하 antirez)의 글을 통해 더 넓은 논쟁으로 번졌다. 두 사람은 각기
다른 경로로—&lt;a href=&quot;https://lucumr.pocoo.org/2026/3/5/theseus/&quot;&gt;Ronacher는 라이선스 철학의 측면에서&lt;/a&gt;,
&lt;a href=&quot;https://antirez.com/news/162&quot;&gt;antirez는 저작권법의 법리에서&lt;/a&gt;—이 재구현이 정당하다는 결론에 도달한다. 나는 두
글을 모두 존중하지만, 둘 다 틀렸다고 생각한다. 아니, 더 정확하게는 둘 다 핵심
질문을 회피하고 있다.&lt;/p&gt;
&lt;p&gt;그 핵심 질문이란 이것이다. 합법이면 공정한가. 두 글은 이 물음에는 답하지 않은
채, 법리적으로 가능하다는 사실에서 사회적으로 정당하다는 결론을 끌어낸다. 법적
허용과 사회적 당위는 같은 것이 아니다. 법은 최소한의 기준을 정할 뿐이고, 어떤
행위가 그 기준을 통과한다는 것이 그 행위가 옳다는 뜻은 아니다. 이 구분이 이
글의 출발점이다.&lt;/p&gt;
&lt;h2&gt;유비의 방향이 거꾸로다&lt;/h2&gt;
&lt;p&gt;antirez의 논거는 GNU 프로젝트가 UNIX 유저스페이스를 재구현했을 때, 그것이
합법이었다는 사실에서 출발한다. Linux 커널도 마찬가지였다. 저작권법은 &lt;q&gt;보호
받는 표현&lt;/q&gt;(protected expressions)의 복제를 금하지만 아이디어와 동작 방식은
보호하지 않는다. AI로 재구현하는 것도 같은 법적 지형 위에 있으므로 합법이라는
것이다.&lt;/p&gt;
&lt;p&gt;이 법리의 설명 자체는 대체로 맞다. 재구현이 합법이라는 주장을 나는 반박하지
않는다. 문제는 그 다음 단계에 있다. antirez는 합법임을 보인 뒤 논의를 끝낸다.
그러나 법리가 옳다는 것과 행위가 사회적으로 정당하다는 것은 별개의 주장이다. 이
둘을 동일시할 때 논증의 간극이 생긴다.&lt;/p&gt;
&lt;p&gt;그 간극이 가장 선명하게 드러나는 곳이 바로 antirez가 끌어온 역사적 유비다.&lt;/p&gt;
&lt;p&gt;GNU가 UNIX를 재구현했을 때, 그 벡터는 독점에서 공유 쪽을 향하고 있었다.
Stallman은 UNIX라는 독점 소프트웨어를 &lt;strong&gt;자유 소프트웨어로&lt;/strong&gt; 재구현하기 위해
저작권법의 한계를 영리하게 활용한 것이다. 그 재구현의 윤리적 정당성은 법적
합법성에서 오는 것이 아니라, 공유지(commons)를 넓히는 방향에서 나왔다. 그것이
GNU 프로젝트가 환호를 받은 이유다.&lt;/p&gt;
&lt;p&gt;chardet 사건에서 재구현의 벡터는 반대 방향이다. 카피레프트 라이선스인 LGPL로
보호되던 소프트웨어가 퍼미시브 라이선스인 MIT로 재구현되었다. 이것은 공유지를
&lt;strong&gt;넓히는&lt;/strong&gt; 재구현이 아니라 공유지의 &lt;strong&gt;울타리를 제거하는&lt;/strong&gt; 재구현이다. 이제 chardet
7.0을 기반으로 만들어지는 파생 작업은 소스 코드를 공개할 의무가 없다. 월 1억
3천만 다운로드라는 규모의 라이브러리에서 그 의무가 사라진 것이다.&lt;/p&gt;
&lt;p&gt;antirez는 이 방향의 차이를 논하지 않는다. GNU의 역사를 끌어왔는데, 그 역사가
실은 자신의 결론에 반증 사례가 된다는 것을 보지 못하거나 보지 않으려 한다.&lt;/p&gt;
&lt;h2&gt;GPL은 공유에 반하는가&lt;/h2&gt;
&lt;p&gt;한편, Ronacher의 논거는 다르다. 그는 자신이 오래전부터 chardet이 비GPL
라이선스로 바뀌기를 원했다고 밝힌다. 그리고 GPL이 &lt;q&gt;공유 정신에 반한다&lt;/q&gt;고
주장한다. 자신은 가능한 한 라이선스 강제가 적은 방향으로 공개하는 것을
지지하고, 사회는 공유할 때 더 나아진다는 믿음을 가지고 있기 때문이란다.&lt;/p&gt;
&lt;p&gt;이 주장은 GPL에 대한 근본적인 오해를 담고 있다.&lt;/p&gt;
&lt;p&gt;GPL이 무엇을 &lt;strong&gt;금지&lt;/strong&gt;하는지부터 보자. GPL은 소스 코드를 비공개로 유지하는 것을
금지하지 않는다. GPL 소프트웨어를 개인적으로 수정해 사용하는 것에는 아무런
제약이 없다. GPL이 조건을 발동시키는 것은 &lt;strong&gt;배포&lt;/strong&gt;할 때뿐이다. 수정한 코드를
배포하거나 서비스로 제공하면, 그 코드도 같은 조건으로 공유해야 한다는 것.
이것은 공유를 &lt;strong&gt;제한&lt;/strong&gt;하는 것이 아니라 공유를 &lt;strong&gt;조건&lt;/strong&gt;으로 거는 것이다.&lt;/p&gt;
&lt;p&gt;&lt;q&gt;이것을 받아서 사용하고 개선했다면, 그 개선도 공유하라&lt;/q&gt;는 요구는 공유를
억제하는 메커니즘이 아니라 공유를 연달아 강제하는 메커니즘이다. 공유지의
이용자에게 공유지에 대한 기여 의무를 부과하는 것이 공유 문화를 해친다는 주장은
어불성설이다.&lt;/p&gt;
&lt;p&gt;MIT 라이선스와 비교해 보면 차이가 분명하다. MIT 라이선스 하에서는 누구나 코드를
가져다 개선한 뒤 독점 소프트웨어로 닫아버릴 수 있다. 가져가서 써도 되지만
기여는 선택적이다. Ronacher가 이 구조를 &lt;q&gt;더 공유 친화적&lt;/q&gt;이라고 본다면, 그가
말하는 &lt;q&gt;공유&lt;/q&gt;는 흘러가는 방향이 있는 공유다. 더 많은 자본과 인력을 가진 쪽이
가져가는 방향으로.&lt;/p&gt;
&lt;p&gt;이 비대칭이 현실에서 어떻게 작동하는지는 역사가 보여준다. 1990년대에 많은
기업들이 GPL 코드를 흡수해 독점 소프트웨어를 만들었다. 이것이 가능했던 것은
그들이 MIT 같은 퍼미시브 라이선스를 선택했기 때문이 아니라, 당시 카피레프트
라이선스의 집행이 느슨했기 때문이다. GPL이 강화되면서 이 구멍이 막혔다. 자원이
없어서 기여를 통한 상호성에 의존할 수밖에 없는 개인 개발자나 작은 프로젝트에게
카피레프트는 그나마 대등한 교환을 가능하게 하는 장치였다.&lt;/p&gt;
&lt;p&gt;Flask를 만든 사람이 이 구분을 모를 이 없다. 그렇다면 이 논거는 나이브한 것이
아니라 편의적인 것이다.&lt;/p&gt;
&lt;h2&gt;스스로 반증하는 사례&lt;/h2&gt;
&lt;p&gt;Ronacher의 글에서 가장 흥미로운 부분은 논거가 아니라 스쳐 지나가는 한 문장이다.
Vercel이 &lt;a href=&quot;https://just-bash.dev/&quot;&gt;GNU Bash를 AI로 재구현해 공개했다가&lt;/a&gt;,
&lt;a href=&quot;https://x.com/cramforce/status/2027155457597669785&quot;&gt;Cloudflare가 같은 방식으로 Next.js를 재구현하자 &lt;q&gt;눈에 띄게 화를 냈다&lt;/q&gt;&lt;/a&gt;는
것이다.&lt;/p&gt;
&lt;p&gt;Ronacher는 이것을 아이러니로 언급하고 넘어가지만, 이 일화는 그의 입장 전체를
무너뜨린다. Next.js는 MIT 라이선스다. &lt;a href=&quot;https://blog.cloudflare.com/vinext/&quot;&gt;Cloudflare의 vinext&lt;/a&gt;는 라이선스를
위반한 것이 아니라, Ronacher가 공유 문화의 진전이라 부른 바로 그 행위를
Next.js에 적용한 것 뿐이다. Vercel의 분노는 라이선스 침해에 대한 것이 아니라
순수하게 경쟁적&amp;#xb7;영토적 반응이었다. &lt;q&gt;내가 GPL 소프트웨어를 MIT로 재구현하는 것은
공유 문화의 진전이고, 누군가 내 MIT 소프트웨어를 같은 방식으로 재구현하는 것은
불쾌하다.&lt;/q&gt; 이것이 퍼미시브 라이선스 진영이 카피레프트 진영보다 더 공유
친화적이라는 주장의 실체이다. 그가 말하는 &lt;q&gt;공유 정신&lt;/q&gt;란 결국 이토록
비대칭적인 것이다.&lt;/p&gt;
&lt;p&gt;Ronacher는 이 아이러니를 인식하고도 멈추지 않는다. 자신의 세계관에 부합하는
사례이기 때문이란다. 세계관과 일치하지 않는 증거를 스스로 제시하고도 결론을
바꾸지 않는 것은 논거가 결론에 앞서는 것이 아니라 결론이 논거에 앞서고 있다는
신호다.&lt;/p&gt;
&lt;h2&gt;합법성과 사회적 당위는 다른 층위에 있다&lt;/h2&gt;
&lt;p&gt;서두에서 말한 질문으로 돌아오자. 합법이면 공정한가.&lt;/p&gt;
&lt;p&gt;antirez는 법리를 꼼꼼히 설명한 뒤 그것으로 충분하다는 듯이 끝을 맺는다.
Ronacher는 법적 회색 지대를 인정하면서도 도덕적 문제는 &lt;q&gt;내가 관심 있는 부분이
아니다&lt;/q&gt;라고 한 문장으로 넘긴다. 두 글 모두 법적 허용을 사회적 정당성의 대리물로
삼는다. 그러나 법은 어떤 행위를 막지 않는다는 것을 말할 뿐이지, 그 행위가
옳다는 것을 보증하지는 않는다. 조세를 아슬아슬하게 회피하는 것이 합법이더라도
옳은지는 별개의 물음이다. 특허를 합법적으로 취득한 기업이 수십 연간 저렴하게
공급되던 필수 의약품 가격을 수십 배 올리는 것이 합법이더라도, 그것이 사회적으로
정당하다는 뜻은 아니다. 합법성은 필요조건일 수 있지만 충분조건은 아니다.&lt;/p&gt;
&lt;p&gt;chardet 사건에서 이 구분은 더욱 뚜렷하다.&lt;/p&gt;
&lt;p&gt;chardet의 LGPL이 보호한 것은 Blanchard 한 사람의 노동이 아니다. 12년간 이
라이브러리에 기여한 모든 사람들이 동의한 사회적 계약이다. 그 계약의 내용은
&lt;q&gt;이것을 가져다 쓴다면, 당신이 만든 것도 같은 조건으로 공유하라&lt;/q&gt;는 것이었다.
이 계약은 법원이 강제하는 종류의 계약이기도 하지만, 그보다 먼저 오픈 소스 공동체가
수십년에 걸쳐 구축해 온 신뢰의 토대였다. 재구현이 법적으로 새로운 저작물로
인정될 수 있다는 것과, 그 재구현이 기존 기여자들과 맺은 사회적 계약을
파기했다는 것은 별개의 문제다. 법원이 만일 Blanchard의 손을 들어준대도 그것은
그의 행위가 공동체적으로 정당하다는 것을 의미하지 않는다. 합법성은 사회적
정당성을 뒤따라오게 하지 않는다.&lt;/p&gt;
&lt;p&gt;FSF 대표 Zoë Kooyman은 이를 간결하게 표현했다. &lt;q&gt;자신이 받은 권리를 타인에게
부여하기를 거부하는 것은 어떤 방법을 쓰든 반사회적 행위다.&lt;/q&gt;&lt;/p&gt;
&lt;h2&gt;누구의 관점이 디폴트로 설정되어 있는가&lt;/h2&gt;
&lt;p&gt;이 논쟁을 읽으면서 계속 드는 질문이 있다. 두 저자는 AI 재구현의 비용 하락을
어떤 위치에서 바라보고 있는가.&lt;/p&gt;
&lt;p&gt;antirez는 Redis를 만들었고, Ronacher는 Flask를 만들었다. 두 사람 모두 오픈 소스
생태계의 중심에 있는 사람들이다. 그들의 입장에서 AI 재구현의 비용 하락은 자신이
&lt;strong&gt;가하는&lt;/strong&gt; 쪽의 이야기다. 무언가를 더 쉽게 재구현할 수 있게 되는 것이다.
Ronacher는 GNU Readline을 GPL이기 때문에 재구현하려 했다고 밝힌다.&lt;/p&gt;
&lt;p&gt;반면 수십년간 chardet 같은 라이브러리에 기여해온 사람들의 입장에서 같은 기술
변화는 자신이 &lt;strong&gt;당하는&lt;/strong&gt; 쪽의 이야기다. 자신의 기여가 담긴 카피레프트 보호막이
제거되는 것이다. 두 저자는 전자의 위치에서 후자의 위치에 있는 사람들을 향해
“이것은 항상 합법이었고, 역사적 선례가 있으며, 기술 변화에 적응하라”고 말하고
있다.&lt;/p&gt;
&lt;p&gt;이 비대칭을 무시한 채 보편적 논거인 것처럼 서술할 때, 글은 분석이 아니라
이해관계의 합리화가 된다. 두 저자 모두 자신의 이해관계와 정확히 일치하는 결론에
도달한다는 것을 독자는 유념해야 한다.&lt;/p&gt;
&lt;h2&gt;이 싸움이 가리키는 것&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://www.theregister.com/2026/03/06/ai_kills_software_licensing/&quot;&gt;Bruce Perens는 &lt;cite class=&quot;series&quot;&gt;The Register&lt;/cite&gt;와의 인터뷰에서&lt;/a&gt; &lt;q&gt;소프트웨어 개발의
전체 경제학이 죽었다&lt;/q&gt;고 경고했다. antirez는 비슷한 인식에서 &lt;q&gt;적응하라&lt;/q&gt;고
말한다. Ronacher는 이 방향이 마음에 든다고 말한다.&lt;/p&gt;
&lt;p&gt;세 반응 중 어느 것도 핵심 질문에 답하지 않는다. 카피레프트의 집행이 기술적으로
어려워졌을 때, 그것이 카피레프트를 &lt;strong&gt;불필요하게&lt;/strong&gt; 만드는가, 아니면 더욱
&lt;strong&gt;중요하게&lt;/strong&gt; 만드는가.&lt;/p&gt;
&lt;p&gt;나는 후자라고 생각한다. GPL이 보호한 것은 코드의 희소성이 아니라 사용자의
권리였다. 코드 생산 비용이 낮아진다고 해서 그 코드를 통해 권리를 침식하는
행위가 괜찮아지는 것은 아니다. 오히려 재구현의 마찰이 사라질수록, 카피레프트
라이브러리를 MIT로 탈바꿈시키는 비용도 사라진다. GPL이 의존했던 마찰이
줄어들었다는 것은 법적 집행의 문제일 뿐, 그 기저의 당위를 건드리지 않는다.&lt;/p&gt;
&lt;p&gt;그 당위는 이것이다. 공유지에서 가져간 자는 공유지에 돌려줘야 한다는 것. 그
원칙은 재구현이 5년 걸리든 5일 걸리든 달라지지 않는다. 법원이 AI 재구현을 클린
룸으로 인정하든 파생 저작물로 보든, 그 판결이 이 원칙의 사회적 무게를
경감시키지는 않는다.&lt;/p&gt;
&lt;p&gt;이것이 법리와 사회적 가치가 갈라지는 지점이다. 법은 사후적으로, 느리게, 현재의
권력 관계를 반영하며 만들어진다. 오픈 소스 공동체가 수십 연에 걸쳐 쌓아온
규범은 법원의 판결을 기다리지 않았다. 법이 그것을 보호해주지 않을 때도 사람들이
GPL을 선택한 것은, 그것이 자신이 속한 공동체의 가치와 일치했기 때문이다. 그
가치는 법이 바뀐다고 사라지지 않는다.&lt;/p&gt;
&lt;p&gt;이전 글들에서 나는 이 싸움의 다음 단계로
&lt;a href=&quot;/2026/01/histomat-foss-llm/&quot;&gt;훈련 카피레프트(TGPL)를 제안했다.&lt;/a&gt; AI 재구현
문제는 거기서 한 걸음 더 나아가 명세(specification) 계층까지 보호 범위를
확장해야 한다는 것을 시사한다. 소스 코드가 명세로부터 생성될 수 있다면, 그
명세가 GPL 프로젝트의 본질적 지식재산이 된다. 소스 코드를 보지 않고 테스트
스위트와 API만으로 재구현했다는 Blanchard의 주장은, 역설적으로, 그 테스트
스위트와 API 명세가 보호되어야 한다는 논거가 된다.&lt;/p&gt;
&lt;p&gt;GPL의 역사는 새로운 착취 방식이 등장할 때마다 법적 도구가 진화해 온 역사다.
GPLv2에서 GPLv3로, AGPL로. 그러나 그 진화를 이끈 것은 판결이 아니라 공동체의
가치 판단이었다. 법은 뒤따라왔다. 지금도 마찬가지다. 법원이 AI 재구현에 대해
어떤 판결을 내리든, 우리가 먼저 답해야 할 질문은 법적인 것이 아니라 사회적인
것이다. 공유지의 열매를 취한 자는 공유지에 돌려줄 의무가 있는가. 나는 그렇다고
생각한다. 그리고 그 판단은 법원의 판결을 기다릴 필요가 없다.&lt;/p&gt;
&lt;p&gt;antirez와 Ronacher의 글이 흥미로운 것은 그들이 옳기 때문이 아니라, 그들이
무엇을 보지 않으려 하는지가 선명하게 드러나기 때문이다. 합법성으로 사회적 가치
판단을 대신하려 할 때, 정작 중요한 질문은 법리의 그늘 속에 묻힌다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>왜 코딩을 사랑하는 사람들이 코딩에서 밀려나는가</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/craft-alienation-llm/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/03/craft-alienation-llm/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/craft-alienation-llm/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/craft-alienation-llm/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/craft-alienation-llm/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/03/craft-alienation-llm/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-03-21T09:30:00.000Z</published>
     <updated>2026-04-17T08:52:06.578Z</updated>
     <content type="html">&lt;h1&gt;왜 코딩을 사랑하는 사람들이 코딩에서 밀려나는가&lt;/h1&gt;
&lt;p&gt;Les Orchard가 &lt;a href=&quot;https://blog.lmorchard.com/2026/03/11/grief-and-the-ai-split/&quot;&gt;최근 글&lt;/a&gt;에서 짚어낸 관찰 하나가 머릿속에서 떠나지
않는다. LLM 코딩 어시스턴트가 나오기 전까지는, 소프트웨어 엔지니어들 사이의
분열은 보이지 않았다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;장인 기질의 사람들과 &lt;q&gt;일단 돌아가면 된다&lt;/q&gt;는 사람들이 나란히 앉아 같은
제품을 만들면서도 구분이 안 됐다. 일의 &lt;strong&gt;동기&lt;/strong&gt;가 보이지 않았던 것은
&lt;strong&gt;과정&lt;/strong&gt;이 동일했기 때문이다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;도구가 분열을 만든 게 아니었다. 이미 있던 분열을 드러낸 것이다.&lt;/p&gt;
&lt;p&gt;Orchard 자신은 첫 번째 진영이다. 일곱 살에 BASIC을 배운 건 BASIC이 아름다워서가
아니라 화면에 무언가를 나타나게 하고 싶어서였다. 그에게 LLM 코딩 어시스턴트는
언제나 오르던 사다리의 다음 단계일 뿐이다. 퍼즐이 사라진 게 아니라 더 높은 추상
수준으로 옮겨갔다. 그도 슬프긴 하지만, 슬퍼하는 건 일 자체가 아니라 일을 둘러싼
생태계다.&lt;/p&gt;
&lt;p&gt;Nolan Lawson의 슬픔은 다르다. &lt;a href=&quot;https://nolanlawson.com/2026/02/07/we-mourn-our-craft/&quot;&gt;2월에 올라온 그의 글&lt;/a&gt;을 보자.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;코드를 손으로 쥐고 조각가처럼 빚는 느낌이 그리울 것이다. 새벽 2시에 디버거
앞에서 씨름하다 마침내 버그가 항복하는 밤이 그리울 것이다. 우리가
자랑스러워했던 무언가를, 진정성 있고 옳고 좋은 것을 만들었던 느낌이 그리울
것이다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;그의 글은 만가처럼 읽히고, 그 안의 슬픔도 진짜다. 그가 애도하는 것은 행위 그
자체다.&lt;/p&gt;
&lt;p&gt;두 사람 다 사려 깊고 솔직하지만, 같은 순간을 바라보며 다른 것을 느끼고 있다. 이
비대칭은 진지하게 받아들일 필요가 있다. &lt;q&gt;그냥 적응하라&lt;/q&gt;는 논의가 계속
놓치는 무언가를 가리키기 때문이다.&lt;/p&gt;
&lt;h2&gt;행위로부터의 소외&lt;/h2&gt;
&lt;p&gt;Marx는 소외된 노동의 차원을 넷으로 분석했다. 생산물로부터의 분리, 노동 행위
자체로부터의 분리, 타인으로부터의 분리, 그리고 자신의 인간적 능력으로부터의
분리. LLM 코딩 어시스턴트를 둘러싼 논의에서 핵심은 두 번째라 할 수 있다.&lt;/p&gt;
&lt;p&gt;Marx가 말한 &lt;q&gt;노동 행위 자체로부터의 분리&lt;/q&gt;란 이런 것이다. 인간은 다른
동물과 달리, 만들고 싶은 것을 머릿속에서 먼저 구상하고 물질 세계를 그 이미지에
맞게 빚을 수 있다. 이 의식적이고 의도적인 창조 능력이 Marx가 인간의 특성으로 본
것에 가장 가깝다. 노동이 기계적인 것, 강제된 것, 삶이 아니라 견뎌내는 것이 될
때, 그 능력은 실현되지 못한다. 활동은 여전히 일어나고 있지만, 그 사람은 더 이상
거기에 현존하지 않는다.&lt;/p&gt;
&lt;p&gt;장인 기술을 애도하는 소프트웨어 엔지니어들은 이 묘사에 닮아있다. 그들이 소중히
여겼던 건 결과물이 아니었다. 무언가를 만드는 과정, 치열하게 집중했던 시간들,
시스템을 충분히 이해해서 그것을 다시 빚을 수 있다는 느낌. Lawson이 정확히
그렇게 말한다. &lt;q&gt;내가 이걸 만들었다&lt;/q&gt;고 말할 수 있는 GitHub 저장소.
&lt;q&gt;무언가가 만들어졌다&lt;/q&gt;가 아니라 &lt;strong&gt;내가&lt;/strong&gt; 만들었다는 것.&lt;/p&gt;
&lt;p&gt;이것은 왜 두 진영이 같은 도구에 그토록 다르게 반응하는지도 설명한다. Orchard는
처음부터 자신을 코드를 &lt;strong&gt;짜는&lt;/strong&gt; 행위에 투자하지 않았다. 결과에 투자했다. LLM
코딩 어시스턴트가 결과에 더 빠르게 도달하게 해준다면, 그에게 잃는 것은 없다.
반면, Lawson에게는 그 행위 안에 의미가 있었다. LLM 코딩 어시스턴트는 결과물을
우회하는 게 아니라 그가 소중히 여기던 부분을 우회한다. Marx가 구분한 객관적
소외(느끼든 안 느끼든 존재하는 조건)와 주관적 소외(그 상실을 경험하는 것)가 이
분열에 거의 정확히 들어맞는다. Orchard는 애초에 행위 자체에 객관적으로 결박되어
있지 않았으니 주관적으로도 소외를 느끼지 않지만, Lawson은 둘 다 느낀다.&lt;/p&gt;
&lt;p&gt;흔한 반응은 이게 향수이거나, 새로운 장인 기술이 옛것을 대체할 것이라는 말이다.
어쩌면 그럴지도 모른다. 그런데 그 반응은 실제 질문을 피해간다. 코딩을 사랑하는
사람들이 왜 코딩에서 밀려나고 있는가? 끌려가는 게 아니라, 밀려나고 있다. 아무도
그들이 손으로 코드를 짜는 것을 막지 않는다. 시장이 그것에 불이익을 주고 있을
뿐이다.&lt;/p&gt;
&lt;h2&gt;무엇이 불이익을 주는가&lt;/h2&gt;
&lt;p&gt;Marx는 &lt;cite class=&quot;series&quot;&gt;자본론&lt;/cite&gt;에서 영국의 러다이트 운동을 이렇게
평했다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;노동자들이 기계 자체와 기계의 자본주의적 적용을 구분하고, 따라서 물질적 생산
수단 그 자체가 아니라 그것의 사회적 착취 형태를 공격하는 법을 배우기까지는
시간과 경험이 필요했다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;방직기를 부순 노동자들의 분노는 정당했다. 방향이 잘못됐을 뿐이다. 베틀이 노동
시간을 늘린 게 아니었다. 자본이 그랬다. 베틀이 노동자를 기계의 부속물로 만든 게
아니었다. 자본이 그랬다.&lt;/p&gt;
&lt;p&gt;LLM을 쓰는 동료와 생산성을 비교 당하는 처지에서 어쩔 수 없이 LLM을 쓴다고
말하는 소프트웨어 엔지니어들에게, 소외의 원천은 LLM이 아니다. 생계를 특정
지표에 묶어놓은 구조다. 그 지표는 이제 가장 빠르게 가장 많은 산출물을 내는
사람에게 유리하다. LLM은 지렛대이고, 시장이 기제다.&lt;/p&gt;
&lt;p&gt;다만 한 가지는 짚어둬야 한다. 장인 기술과 효율 사이의 긴장은 자본주의를
걷어낸다고 해서 사라지는 게 아니다. LLM이 더 빠른 산출물을 낸다는 사실 자체는
누가 돈을 받든 받지 않든 유효하다. 어떤 공동체도, 어떤 방식으로 조직되든, 결국
그 속도 차이를 어떻게 대할 것인가라는 질문을 피할 수 없다. 자본주의는 그 질문에
가장 가혹한 답을 준다. 더 느린 쪽이 생계를 잃는다. 하지만 질문 자체는
자본주의보다 오래 살아남는다.&lt;/p&gt;
&lt;h2&gt;내 상황이 보여주는 것&lt;/h2&gt;
&lt;p&gt;나는 전업으로 오픈 소스 프로젝트를 유지보수하고 있다. 벌이는 전적으로 공적
자금에서 나온다. LLM 코딩 어시스턴트를 쓰지 않으면 일자리를 잃는다고 말하는
고용주도 없다. 내 생산성을 동료와 비교하는 분기별 평가도 없다.&lt;/p&gt;
&lt;p&gt;이런 조건에서 나와 LLM의 관계는 Lawson이 묘사하는 것과 사뭇 다르다. 흥미롭다고
생각하는 코드는 여전히 손으로 짠다. 하고 싶지 않은 부분들, 장황한 테스트
스캐폴딩과 수백 번 써 본 보일러플레이트는 모델에게 넘긴다. 이 구분은 내 스스로
그은 선이다. 무언가를 표현하는 일과 그냥 처리해야 하는 일 사이의 구분선.&lt;/p&gt;
&lt;p&gt;Marx가 자본주의 바깥에서 기계가 할 수 있는 일이라고 상상했던 것과 가깝다. 반복
노동에서 사람을 해방시켜 더 창조적인 활동을 위한 시간을 열어주는 것. 기술이
다른 게 아니라 조건이 다른 것이다.&lt;/p&gt;
&lt;p&gt;내 상황을 해법으로 제시하려는 게 아니다. 이런 상황은 드물고, 여전히 자본주의
경제 안에 존재한다. 임시 피난처일 뿐 탈출이 아니다. 다만 같은 도구가 한
맥락에서는 해방적으로, 다른 맥락에서는 소외적으로 느껴진다는 것, 그 차이가
도구가 아니라 사회적 조건에서 온다는 것 만큼은 사실인 것 같다.&lt;/p&gt;
&lt;h2&gt;슬픔이 바라봐야 할 곳&lt;/h2&gt;
&lt;p&gt;원인을 안다고 해서 고통이 해소되는 건 아니다. 지금 당장 LLM 코딩 어시스턴트를
쓰도록 내몰리고 있는 소프트웨어 엔지니어들에게 구조 분석은 오늘 오후를 도와주지
못한다.&lt;/p&gt;
&lt;p&gt;그러나 질문을 약간 다르게 할 수는 있다. Lawson이 묘사하는 슬픔이 실재한다면,
그리고 그 슬픔의 더 깊은 원인이 기술 자체가 아니라 그것을 둘러싼 관계에 있다면,
슬픔이 향해야 할 곳은 LLM이 아니다. 원하지 않는 도구를 원하지 않는 조건에서
쓰도록 강제하는 것이 무엇인지가 문제다.&lt;/p&gt;
&lt;p&gt;Lawson도 이 근처 어딘가에 도달한 듯하다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;나는 새 세상을 축하하지 않지만 저항하지도 않는다. 해가 뜨고 지고, 나는 그
주위를 어쩔 수 없이 공전하며, 내 항의는 그것을 막을 수 없다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;솔직하지만, 체념이 우리에게 남은 유일한 길은 아니라고 믿고 싶다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>불완전한 세상에서 유물론적으로 행동하기: 생산 수단으로서의 LLM과 사회적 관계</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-02-21T21:40:00.000Z</published>
     <updated>2026-04-17T08:52:06.578Z</updated>
     <content type="html">&lt;h1&gt;불완전한 세상에서 유물론적으로 행동하기: 생산 수단으로서의 LLM과 사회적 관계&lt;/h1&gt;
&lt;p&gt;&lt;small&gt;이 글은 지난 달에 쓴
&lt;cite&gt;&lt;a href=&quot;/2026/01/histomat-foss-llm/&quot;&gt;F/OSS 史唯: 우리는 LLM을 거부할 게 아니라 되찾아 와야 한다&lt;/a&gt;&lt;/cite&gt;의 후속이다.&lt;/small&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;Cory Doctorow가 &lt;a href=&quot;https://pluralistic.net/2026/02/19/now-we-are-six/&quot;&gt;&lt;cite class=&quot;series&quot;&gt;Pluralistic&lt;/cite&gt; 6주년 기념 글&lt;/a&gt;에서 자신의 작업 흐름을
공개했다. 그는 매일 발행하는 기사를 올리기 전에, Ollama라는 오픈 소스 LLM을
오탈자 교열 용도로 돌린다고 밝혔다. 예상할 수 있었던 반응이 따라왔다. 그리고
독일의 기술 비평가 tante는 이틀 뒤
&lt;cite&gt;&lt;a href=&quot;https://tante.cc/2026/02/20/acting-ethical-in-an-imperfect-world/&quot;&gt;불완전한 세상에서 윤리적으로 행동하기&lt;/a&gt;&lt;/cite&gt;(&lt;cite lang=&quot;en&quot;&gt;Acting ethically in an imperfect
world&lt;/cite&gt;)라는 글로 응답했다.&lt;/p&gt;
&lt;p&gt;tante의 제목을 빌려오는 것이 이 글의 시작으로 어울린다고 봤다. 불완전한
세상에서 윤리적으로 행동한다는 것이 그의 물음이라면, 나는 같은 물음에 다른 틀로
답하고 싶다. 윤리가 아니라 유물론으로.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;/2026/01/histomat-foss-llm/&quot;&gt;이전 글&lt;/a&gt;에서 나는 라이선싱을 탈환의 수단으로 너무 전면에 내세웠다.
나이브하다는 비판을 받았고, 그 비판에 어느 정도 수긍도 한다. 다만 내가 말하고
싶었던 것은 탈환이라는 &lt;strong&gt;방향&lt;/strong&gt;이었지, 탈환의 &lt;strong&gt;처방&lt;/strong&gt;이 아니었다. 이 글에서는
그 방향을 좀 더 정확하게 다듬어 보고자 한다.&lt;/p&gt;
&lt;h2&gt;두 개의 허수아비&lt;/h2&gt;
&lt;p&gt;tante의 글에는 타당한 지적들이 있다. Doctorow는 LLM 비판자들을 &lt;q&gt;기술의
창시자가 나쁜 사람이어서 쓰면 안 된다는 순수주의자들&lt;/q&gt;로 그렸는데, 이건
허수아비다. 실제 비판은 전혀 다른 데에 있다. 막대한 전력과 물 소비, 동의 없는
데이터 수집, 글로벌 사우스에서 이루어지는 착취적 레이블링 노동, 오픈 소스
생태계를 포함한 지식 공유재에 가해지는 피해… Doctorow는 이 비판들을 &lt;q&gt;Sam
Altman이 마음에 안 든다&lt;/q&gt;는 감정적 반응으로 환원해버렸고, tante는 그 환원이
잘못됐다고 지적한다. 맞는 말이다.&lt;/p&gt;
&lt;p&gt;Bluesky 지적도 유효하다. Doctorow는 중앙 집권화에 대한 이념적 이유로 Bluesky
가입을 거부했다. 그는 자신의 가치에 근거해서 기술을 거부하는 것이 가능하다고
믿고 실천한다. 그런데 타인이 LLM을 같은 방식으로 거부하면 &lt;q&gt;순수주의&lt;/q&gt;라고
부른다. 이러한 이중 잣대도 tante가 정확히 짚었다.&lt;/p&gt;
&lt;p&gt;그런데 tante도 같은 함정에 빠진다.&lt;/p&gt;
&lt;p&gt;그는 탈환이라는 방향을 비판하면서, 탈환의 수단을 사실상 하나로 한정한다. GPT에
준하는 프런티어 모델을 처음부터 다시 만드는 것. 수십억 불이 필요하고, 그
과정에서 동일한 환경적 비용이 발생하므로, 탈환은 현실적이지 않다는 것이다.
하지만 Doctorow가 LLM 비판을 단순화했던 것처럼, tante도 탈환의 경로를
단순화했다. 라이선스를 통한 법적 저항이 있다. 규제를 통해 국가로 하여금 사유
모델의 공개를 강제할 수 있을 지도 모른다. 공공 기반 모델을 공동으로 구축하는
방향도 있다. 어떤 수단이 실제로 작동할지는 정치적&amp;#xb7;사회적 조건에 달려 있고,
아직은 열려 있다. 내가 이전 글에서 라이선싱을 언급한 것은 그 중 가장 먼저
떠오른 하나였을 뿐이다.&lt;/p&gt;
&lt;h2&gt;기계와 그 자본주의적 적용 형태&lt;/h2&gt;
&lt;p&gt;Marx는 &lt;cite class=&quot;series&quot;&gt;자본론&lt;/cite&gt; 제 1권에서 영국의 러다이트 운동을 이렇게 평했다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;노동자들이 기계 자체와 기계의 자본주의적 적용을 구분하고, 따라서 물질적 생산
수단 그 자체가 아니라 그것의 사회적 착취 형태를 공격하는 법을 배우기까지는
시간과 경험이 필요했다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;방직기를 부순 노동자들의 분노는 정당했다. 방향이 잘못됐을 뿐이다. 문제는 기계가
아니라 기계를 둘러싼 자본주의적 사회 관계였다. 기계가 노동 시간을 단축시키기는
커녕 연장시키고, 노동자를 해방시키는 대신 기계의 부품으로 만드는 것은 기계의
본성이 아니라 그것을 배치하는 방식의 문제였다. Marx는 그들을 조롱한 게 아니라,
투쟁이 성숙해지는 과정을 서술한 것이다.&lt;/p&gt;
&lt;p&gt;이 틀이 오늘날 LLM 논쟁에서도 유효하다고 생각한다. tante의 접근은 본질적으로
윤리적이다. LLM이라는 기술 자체를 도덕적으로 평가하고, 그 평가에 따라 사용
여부를 결정한다. Doctorow의 접근도 크게 다르지 않다. 다만 평가의 방향이 반대일
뿐이다. 둘 다 기술을 도덕의 대상으로 놓는다.&lt;/p&gt;
&lt;p&gt;유물론적 접근은 다른 질문을 한다. 이 기술이 어떤 사회적 관계 속에 놓여 있는가.
누가 소유하고, 누구의 노동으로 유지되며, 그 잉여는 어디로 흘러가는가. 그리고 그
관계를 바꿀 수 있는가.&lt;/p&gt;
&lt;p&gt;&lt;q&gt;AI 찬반&lt;/q&gt;이라는 구도 자체가 이 질문을 가린다. 거대 AI 벤더들에
비판적이면서도 LLM이라는 기술의 가능성을 열어두는 것이 일관성 없어 보이는 것은,
기술과 그 자본주의적 적용 형태가 같은 것이라고 전제하기 때문이다. 하지만 그
전제는 틀렸다.&lt;/p&gt;
&lt;h2&gt;도서관과 사람&lt;/h2&gt;
&lt;p&gt;LLM은 도서관이 아니다. 도서관이 원본으로 사람을 연결한다면, LLM은 원본 없이
답을 내놓는다는 비판은 일면 맞다. 그런데 LLM은 사람에 더 가깝다고 생각한다.&lt;/p&gt;
&lt;p&gt;인간도 평생에 걸쳐 방대한 양의 텍스트와 코드와 이미지를 흡수한다. 저작권자에게
일일이 허락을 받지 않는다. 그것을 자신의 것으로 녹여내고, 때로는 그냥 짜집기에
불과한 것을 내놓고, 때로는 아무도 생각하지 못했던 연결을 만들어낸다.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://www.anthropic.com/engineering/building-c-compiler&quot;&gt;Anthropic의 Nicholas Carlini는 최근 Claude Opus 4.6을 이용해 Rust로 C 컴파일러를 처음부터 작성하는 실험을 진행했다.&lt;/a&gt;
인터넷 접속 없이, 클린 룸으로. 결과는 Linux 6.9 커널을 x86, ARM, RISC-V 세
아키텍처에서 빌드하고, PostgreSQL, FFmpeg, SQLite, Redis를 컴파일하며, GCC 토처
테스트 스위트를 99% 통과하는 십만 줄짜리 컴파일러였다. 내가 알기로는 Rust로
작성된 C 컴파일러 중 그에 필적하는 성과를 거둔 선례는 없다. 누군가의 작업을
그대로 재생산했다고 볼 수 없다.&lt;/p&gt;
&lt;p&gt;물론 LLM이 항상 창조적인 것도 아니고, 사람이 항상 창조적인 것도 아니다. 이
비유는 LLM을 미화하기 위한 것이 아니다. &lt;q&gt;LLM은 본질적으로 재생산만 한다&lt;/q&gt;는
전제 위에 세워진 비판의 근거가 흔들린다는 것이다.&lt;/p&gt;
&lt;p&gt;모든 생성형 AI가 같지 않다는 것도 이 틀에서 더 잘 드러난다. LLM과 이미지 생성
모델의 차이는 그저 기술의 차이가 아니라, 어떤 노동을 어떤 방식으로 대체하느냐의
차이다. 이미지 생성 모델이 특정 작가의 스타일로 이미지를 뽑아낼 때, 그것은
원작자의 시장을 직접 잠식한다. 기능의 대체가 아니라 존재의 대체다. 그 잉여가
어디로 가는지를 보면, Marx가 말한 노동의 궁핍화(Verelendung)가 이미지 생성
분야에서 더 직접적으로 진행되고 있다. 같은 잣대를 LLM에 그대로 적용할 수
있는지는 훨씬 복잡한 질문이다.&lt;/p&gt;
&lt;h2&gt;디폴트 시점&lt;/h2&gt;
&lt;p&gt;마지막으로 개인적인 이야기를 하나 꺼내고 싶다.&lt;/p&gt;
&lt;p&gt;tante의 글은 웹에 올라가 있지만, 주요 LLM 벤더의 스크래핑을 막도록 설정되어
있는 듯하다. 한국어가 모어인 내게 영어는 제2언어다. tante의 글처럼 논증의
뉘앙스와 암시된 전제가 중요한 텍스트를, 종래의 기계 번역으로는 제대로 옮기기
어렵다. LLM 정도는 되어야 논증이 살아있는 채로 전달된다. 나는 결국 글을
수동으로 복사해서 LLM에게 넘겨 읽었다.&lt;/p&gt;
&lt;p&gt;tante는 LLM이 저자와의 연결을 끊는다고 했다. 검색 엔진은 원본으로 사람을
안내하지만, LLM은 원본을 추출해서 사용자를 자신의 루프 안에 가둔다는 것이다.
틀린 말은 아니다. 하지만 내 경험은 그 도식이 누구의 시점에서 그려졌는지를
보여준다. 영어가 유창한 독자에게 LLM은 마냥 연결을 끊기만 하는 기술일 수 있다.
하지만 영어가 서툰 독자에게 LLM은 연결을 &lt;strong&gt;가능하게&lt;/strong&gt; 하는 기술이기도 하다.
tante가 LLM을 막은 행위는 그 자신의 논리로는 일관성이 있지만, 결과적으로는
영어가 유창한 독자와 그렇지 않은 독자 사이의 비대칭을 강화했다.&lt;/p&gt;
&lt;p&gt;이것이 단순한 아이러니가 아닌 이유는, 이 비대칭이 기술 담론 전반에서 작용하기
때문이다. 누구의 시점이 디폴트로 설정되어 있는가. 어떤 사회적 관계 속에서 그
디폴트가 만들어졌는가.&lt;/p&gt;
&lt;p&gt;유물론적으로 행동한다는 것은, 그 디폴트를 당연하게 받아들이지 않는 것에서
시작한다. 기술이 좋은가 나쁜가를 묻기 전에, 이 기술이 누구를 위해, 누구의
노동으로, 누구의 이익을 위해 작동하는가를 묻는 것이다. 그리고 그 물음이 기술을
거부할 이유가 아니라 탈환할 이유가 된다고 나는 여전히 생각한다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>F/OSS 史唯: 우리는 LLM을 거부할 게 아니라 되찾아 와야 한다</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/histomat-foss-llm/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/01/histomat-foss-llm/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/histomat-foss-llm/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-01-16T06:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.577Z</updated>
     <content type="html">&lt;h1&gt;F/OSS 史唯: 우리는 LLM을 거부할 게 아니라 되찾아 와야 한다&lt;/h1&gt;
&lt;p&gt;며칠 전 &lt;cite&gt;&lt;a href=&quot;https://chronicles.mad-scientist.club/tales/on-floss-and-training-llms/&quot;&gt;자유&amp;#xb7;오픈 소스 소프트웨어와 LLM 학습에 관해&lt;/a&gt;&lt;/cite&gt;(&lt;cite lang=&quot;en&quot;&gt;On
FLOSS and training LLMs&lt;/cite&gt;)라는 글을 읽었다. 자유/오픈 소스 소프트웨어
커뮤니티에서 느끼는 좌절감을 잘 담아낸 글이었다. AI 기업들은 F/OSS 개발자들을
전혀 존중하지 않는다. 오픈 소스 라이선싱의 이상주의적 원칙을 악용하고 있다.
법은 우리의 작업물이 독점 언어 모델의 훈련 재료로 쓰이는 걸 막아주지 못한다.
글을 읽으며 여러 차례 고개를 끄덕였다.&lt;/p&gt;
&lt;p&gt;하지만 나는 이 글의 결론에는 동의하지 않는다.&lt;/p&gt;
&lt;p&gt;저자가 제안하는 해법은 거부와 고립이다. 크롤러를 차단하고, GitHub 같은 중앙화된
포지에서 떠나고, AI 스크래퍼가 우리 코드에 접근하지 못하게 막자는 것이다.
그리고 이런 &lt;q&gt;비윤리적 도구&lt;/q&gt;를 쓰는 사람들을 커뮤니티에서 배척하자고 한다.
단절과 고립의 전략이다. 분노는 이해된다. 하지만 이 접근은 중요한 기회를 놓치고
있고, F/OSS를 만들어온 역사적 패턴을 오독하고 있다.&lt;/p&gt;
&lt;h2&gt;우리가 동의하는 지점&lt;/h2&gt;
&lt;p&gt;갈라지는 지점을 논하기 전에, 저자가 옳은 부분부터 짚고 넘어가자. 현재의 상황은
정말로 심각하다. AI 기업들은 훈련 데이터 출처를 완전히 무시하고 있다.
&lt;q&gt;법적으로 가능하니까 하겠다&lt;/q&gt;는 말이 그들이 개별 개발자와 커뮤니티를 대하는
태도를 정확하게 보여준다. 공격적인 크롤링은 사실상 분산 서비스 거부(DDoS)
공격이나 다름없다. 콘텐츠 제작자의 명시적 의사는 무시된다. 제대로 작동하는
옵트아웃(opt-out) 메커니즘조차 제공하지 않는다.&lt;/p&gt;
&lt;p&gt;법적 싸움도 이기기 어렵다는 점에서 저자의 말이 맞다. F/OSS 라이선스는
본질적으로 용처를 차별하지 않는다. &lt;a href=&quot;https://opensource.org/osd&quot;&gt;오픈 소스 정의&lt;/a&gt;의 여섯 번째 원칙은 특정
분야에 대한 제한을 명시적으로 금지한다. GPL 같은 주요 라이선스들은 저작자
표시를 요구하고 파생 저작물에 대한 조항을 두고 있지만, 저자 말대로 능력 있는
변호사라면 LLM 훈련이 종래 의미의 파생 저작물 생성이 아니라고 주장할 수 있다.
통계적 패턴 추출이 코드 재사용처럼 저작자 표시를 요구하지 않는다고 말이다.&lt;/p&gt;
&lt;p&gt;현재의 법은 부족하다. 이 법은 옛 시대를 위해 만들어졌다. 그 시대에
&lt;q&gt;&lt;strong&gt;사용&lt;/strong&gt;&lt;/q&gt;이란 소프트웨어를 실행하거나 수정하거나 재배포하는 것이었지,
신경망에 넣어 패턴을 추출하는 게 아니었다. 법은 권력을 위해 봉사한다. 이 경우
권력은 법무팀을 동원해 이런 모호함을 탐색하고 악용할 수 있는 기업들에게 있다.&lt;/p&gt;
&lt;h2&gt;우리가 갈라지는 지점&lt;/h2&gt;
&lt;p&gt;그러나 여기서 길이 갈라진다. 답은 거부가 아니라 재전유다.&lt;/p&gt;
&lt;p&gt;저자는 현재의 상황을 개발자 존중과 AI 훈련 허용 사이의 싸움으로 프레이밍한다.
하지만 제3의 길이 있다. F/OSS 역사와 더 일관되고, 우리가 실제로 바라는 미래를
만들 가능성이 높은 길이다. 우리는 우리의 코드로 LLM을 훈련하지 못하게 막으려
하기보다, 모델 자체를 해방시키라고 요구해야 한다.&lt;/p&gt;
&lt;p&gt;내 입장은 이렇다. 나는 내 코드가 LLM 훈련에 쓰이길 &lt;strong&gt;바란다&lt;/strong&gt;. 바라지 않는 건
그 훈련으로 AI 사기업의 사유 재산이 되는 독점 모델이 만들어지는 것이다. 문제는
기술 자체나 훈련 과정이 아니다. 공유지의 사유화, 집단 지식의 독점, 가치가
다수에서 소수로만 흐르는 것이 문제다.&lt;/p&gt;
&lt;p&gt;이건 아주 새로운 문제는 아니다. F/OSS가 여태 싸워온 그 문제다. 옷만 바꿔 입었을
뿐이다.&lt;/p&gt;
&lt;h2&gt;현실 인식에 관하여&lt;/h2&gt;
&lt;p&gt;더 나아가기 전에 근본적인 이야기를 하나 해보자. LLM을 둘러싼 여러 관점들은 대개
현실 자체를 어떻게 인식하느냐에서 갈린다.&lt;/p&gt;
&lt;p&gt;얼마 전 Redis 제작자 Salvatore Sanfilippo, 일명 antirez가
&lt;a href=&quot;https://antirez.com/news/158&quot;&gt;AI 코딩 도구 경험담&lt;/a&gt;을 썼다. 그는 우리 중 많은 이들처럼 손으로 빚은 코드와
소프트웨어의 인간적 손길을 깊이 중시하는 사람이다. 하지만 이렇게 말한다. &lt;q&gt;지금
일어나고 있는 현실을 외면하는 건 불가능하다. 코드 작성은 더 이상 대부분 필요
없다… 프로그래밍은 영원히 바뀌었다.&lt;/q&gt;&lt;/p&gt;
&lt;p&gt;그의 결론은 이렇다: 적응하라. 새 도구들을 배우라. &lt;q&gt;반AI 하이프(hype)&lt;/q&gt;에
빠지지 말라. 그는 LLM을 90년대 오픈 소스처럼 민주화 기술로 본다. 작은 팀이 큰
회사와 경쟁할 수 있게 해준다고 말이다.&lt;/p&gt;
&lt;p&gt;나도 antirez의 현실 인식에 대체로 동의한다. LLM은 프로그래밍을 근본적으로
바꿨고, 되돌릴 수 없다. 반면 &lt;cite&gt;자유&amp;#xb7;오픈 소스 소프트웨어와 LLM 학습에 관해&lt;/cite&gt;의
저자는 현실을 다르게 인식하는 것으로 보인다. 저항이 여전히 의미 있고, 철수가
효과적일 수 있으며, LLM의 훈련 데이터 접근을 의미 있게 줄일 수 있다는 인식이다.
나는 회의적이다. OpenAI와 Anthropic은 이미 필요한 걸 다 긁어갔다. GitHub도 모든
코드를 갖고 있다. 훈련 데이터는 이미 존재한다.&lt;/p&gt;
&lt;p&gt;하지만 여기서 나는 antirez의 낙관론과 갈라선다. 그는 중앙화를 걱정하면서도
중국산 오픈 모델 등을 통해 시장 경쟁이 해결해줄 거라고 믿는 듯하다. 그리고
개발자들이 어떻게 적응하고 이 도구를 활용할 수 있는지에 집중한다. 중요한
얘기지만, 더 깊은 질문을 비껴간다. 이 변혁은 어떤 조건에서 일어나는가?&lt;/p&gt;
&lt;p&gt;질문은 LLM을 쓸 것이냐 적응할 것이냐가 아니다. 그 배는 이미 떠났다. 질문은 누가
모델을 소유하느냐다. 모델을 훈련시킨 공유지로부터 누가 이득을 보느냐다. 수백만
F/OSS 개발자가 자기 코드를 공공에 기여했다면, 결과로 나온 모델이 독점이어야
하나? 이건 단순히 중앙화나 시장 역학 문제가 아니다. 집단 노동의 열매가 집단에게
남느냐, 사유 재산이 되느냐의 문제다.&lt;/p&gt;
&lt;h2&gt;유물론적 독해&lt;/h2&gt;
&lt;p&gt;자유&amp;#xb7;오픈 소스 소프트웨어 역사를 유물론적 렌즈로 보면 명확한 패턴이 보인다.
기술 변화가 새로운 형태의 착취를 만들고, 그 착취는 공유지를 보호하기 위한
새로운 형태의 라이선싱을 요구한다.&lt;/p&gt;
&lt;p&gt;궤적을 살펴보자.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&quot;https://www.gnu.org/licenses/old-licenses/gpl-2.0.html&quot;&gt;GPLv2&lt;/a&gt;&lt;/strong&gt;(1991)는 바이너리 배포 문제를 다뤘다. 기업들이 GPL 코드를 가져다
컴파일해서 바이너리만 배포했다. 자유 코드로 사실상 독점 소프트웨어를 만든
것이다. 해법은 카피레프트(copyleft)였다. 소프트웨어를 배포하면 소스 코드도
제공해야 한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&quot;https://www.gnu.org/licenses/gpl-3.0.html&quot;&gt;GPLv3&lt;/a&gt;&lt;/strong&gt;(2007)는 &lt;a href=&quot;Tivoization&quot;&gt;티보이제이션&lt;/a&gt;을 다뤘다. TiVo 같은
기업들은 기술적으로는 소스 코드를 제공했지만 하드웨어 락으로 수정판 실행을
막았다. 해법은 소스 코드뿐 아니라 설치 정보까지 요구하는 것이었다. 사용자가
수정할 자유를 유지하도록 말이다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&quot;https://www.gnu.org/licenses/agpl-3.0.html&quot;&gt;AGPL&lt;/a&gt;&lt;/strong&gt;(2007)은 &lt;a href=&quot;https://www.gnu.org/licenses/why-affero-gpl.html&quot;&gt;SaaS 허점&lt;/a&gt;을 다뤘다. 기업들은 소프트웨어를 배포할
필요가 없다는 걸 깨달았다. 서비스로만 돌리면 GPL 배포 요구사항이 작동하지
않았다. 해법은 네트워크 상호 작용을 배포와 동등하게 취급하는 것이었다.&lt;/p&gt;
&lt;p&gt;매번 같은 패턴이 반복됐다. 새 기술이 기존 라이선스의 간극을 드러내면, 기업들이
그 간극을 악용했다. 그러면 커뮤니티가 간극을 메우는 진화한 라이선싱으로
대응했다. 이건 이상주의가 현실을 만나 실패한 게 아니다. 변증법적 발전이다.
변화하는 물질적 조건에 맞춰 우리 도구를 정제하는 지속적 과정이다.&lt;/p&gt;
&lt;p&gt;이제 또 새로운 간극이 보인다. 바로 훈련 허점이다. 기업들은 F/OSS 코드를 독점
모델의 훈련 데이터로 쓸 수 있다. 모델을 공개하거나 훈련 출처를 밝힐 의무도
없다. 전형적인 착취다. 호혜성 없는 가치 추출이다.&lt;/p&gt;
&lt;p&gt;유물론적 대응은 새 기술을 거부하는 게 아니다. 라이선스를 진화시켜 포괄하는
것이다.&lt;/p&gt;
&lt;h2&gt;훈련 카피레프트가 어떤 모습일 수 있을까&lt;/h2&gt;
&lt;p&gt;나는 GPLv4나 TGPL (Training GPL) 같은 것을 꿈꾼다. 이런 조항들을 포함해야 할
것이다.&lt;/p&gt;
&lt;p&gt;훈련은 명시적으로 허용한다. 코드는 기계 학습 모델의 훈련 데이터로 쓰일 수 있다.
F/OSS 자유 원칙과 일치하고 분야 차별을 피한다.&lt;/p&gt;
&lt;p&gt;하지만 그 결과물인 모델은 해방되어야 한다. 해당 코드로 훈련한 모든 모델은 호환
가능한 카피레프트 라이선스로 가중치(weights)를 공개해야 한다. GPLv3가
바이너리에 소스 코드를 요구하듯, 훈련 카피레프트는 훈련된 시스템에 모델
가중치를 요구한다.&lt;/p&gt;
&lt;p&gt;훈련 데이터는 문서화해야 한다. 의존성을 문서화하길 기대하듯, 어떤 데이터로
훈련했는지 명확히 밝혀야 한다.&lt;/p&gt;
&lt;p&gt;파인튜닝(fine-tuning)된 모델도 의무를 물려받는다. 카피레프트 모델을
파인튜닝하면 파생 모델도 공개해야 한다. &lt;q&gt;조금만 수정해서 새 것이라
주장하기&lt;/q&gt; 회피를 막는다.&lt;/p&gt;
&lt;p&gt;네트워크 사용도 의무를 부과한다. AGPL처럼 API로 모델을 제공하는 것도 배포로
간주해 가중치 공개를 요구한다.&lt;/p&gt;
&lt;h2&gt;기술적 도전과 선례&lt;/h2&gt;
&lt;p&gt;이게 기술적으로 가능할까? 집행할 수 있을까? 타당한 질문이지만 새로운 질문은
아니다. 이전 모든 GPL 진화에서 똑같이 제기된 질문이다.&lt;/p&gt;
&lt;p&gt;바이너리가 당신 소스 코드로 컴파일됐다는 걸 어떻게 증명하나? 하드웨어 락이
수정을 막는다는 걸 어떻게 증명하나? 서비스가 당신 코드를 돌리고 있다는 걸
어떻게 증명하나? 매번 답은 기술적 증거, 커뮤니티의 감시, 때로는 법적 조치의
조합이었다. 완벽한 집행은 불가능하다. 하지만 라이선스가 무가치하단 뜻은 아니다.
GPL 위반은 일어나지만 GPL은 작동한다. 거대한 공유지를 만들고 보호해왔다.&lt;/p&gt;
&lt;p&gt;특정 코드가 훈련에 쓰였다는 증명은 소스 코드가 바이너리에 쓰였다는 증명보다
확실히 더 어려울 것이다. 하지만 넘을 수 없는 건 아니다. 훈련 데이터셋은
문서화할 수 있다. 모델 계보는 추적할 수 있다. 통계 분석이 훈련 출처를 식별할
수도 있다. 더 중요한 건, 라이선스 존재 자체가 준수를 향한 사회적&amp;#xb7;법적 압력을
만든다는 것이다.&lt;/p&gt;
&lt;p&gt;혼합 훈련 세트 문제도 있다. TGPL과 비TGPL 코드로 함께 훈련하면? 이것도 GPL과
비GPL 코드를 링크하는 문제와 유사하다. 수년간의 커뮤니티 실천과 이따금의 법정
사례로 해결돼왔다. 세부사항은 따로 풀어야 할 문제지만, 큰 방향은 맞다.&lt;/p&gt;
&lt;h2&gt;이게 왜 철수보다 중요한가&lt;/h2&gt;
&lt;p&gt;저자의 철수 전략은 감정적 호소력이 있다. 접근을 거부하고 &lt;q&gt;당신은 우리를 존중
안 하니 우리 작업을 가질 수 없다&lt;/q&gt;고 말하는 것은 이른바 &lt;q&gt;사이다&lt;/q&gt;처럼
통쾌하다. 하지만 여러 면에서 더 큰 그림을 놓친다.&lt;/p&gt;
&lt;p&gt;일단 이 전략은 전장을 크게 양보한다. F/OSS 개발자들이 코드를 공개 접근성에서
철수하면, 그저 AI 훈련을 막는 게 아니라 &lt;strong&gt;오픈 소스&lt;/strong&gt; AI 훈련만 막는다.
OpenAI와 Anthropic은 이미 필요한 건 다 긁어갔고, 거대한 데이터셋을 갖고 있다.
철수가 막는 건 Llama나 Mistral 같은 프로젝트와 더 넓은 오픈 소스 LLM 생태계가
양질의 훈련 데이터에 접근하는 것이다.&lt;/p&gt;
&lt;p&gt;더 근본적으로는, 문제를 잘못 짚고 있다. 기술 자체가 아니라 그것을 누가 어떻게
쓰느냐가 문제인데 말이다. LLM은 컴파일러나 웹 서버가 본질적으로 착취적이지 않은
것처럼 본질적으로 착취적이지 않다. 도구일 따름이다. 자본주의 하의 모든 도구처럼
권력을 집중시키거나 분산시키는 데 쓰일 수 있다. 사용 조건이 아니라 거부에
집중하면 질병이 아니라 증상만 치료할 위험이 있다.&lt;/p&gt;
&lt;p&gt;커뮤니티 분열 위험도 있다. 저자는 &lt;q&gt;비윤리적 도구&lt;/q&gt;의 사용자들을 배척하고
환영 받지 못하게 만들고 고립시키자고 한다. 하지만 어디까지가 사용인가? 누가
F/OSS 프로젝트 패치를 작성하는 데 GitHub Copilot을 쓴다면? 디버깅에 ChatGPT를
쓴다면? 정확히 어디가 선이고 그걸 누가 결정할까? 이런 순수성 테스트는
역사적으로 목표 달성보다 운동 분열에 더 효과적이었다.&lt;/p&gt;
&lt;p&gt;하지만 가장 치명적인 건, 실제로 작동해 왔던 F/OSS 전략을 포기한다는 것이다.
접근을 막는 게 아니라 라이선스로 자유를 지키는 전략을. GPL의 천재성은
누구에게도 코드 사용을 막지 않았다는 것이다. 대신, 받은 자유를 다른 이에게도
주도록 요구해서 모두의 자유를 보장했다. 철수는 정반대 철학이다.&lt;/p&gt;
&lt;h2&gt;우리가 만들어야 할 미래&lt;/h2&gt;
&lt;p&gt;나는 강력한 AI 모델이 존재하고, 훈련할 여력이 있는 사기업들만이 아니라 모두가
그러한 모델에 접근할 수 있는 미래에 살고 싶다. 수백만 F/OSS 프로젝트에 인코딩된
지식이 독점 모델로 사유화되는 대신 공유지의 일부가 되는 세상를 바란다. 내
코드가 모델 훈련을 돕는다면 그 모델을 나와 다른 모두가 사용하고 연구하고
수정하고 공유할 수 있는 세상를 바란다.&lt;/p&gt;
&lt;p&gt;이 미래는 철수에서 오지 않는다. 참여에서, 우리의 라이선싱 도구의 진화에서,
우리가 보고 싶은 오픈 소스 AI 생태계를 구축하는 것에서 온다. &lt;a href=&quot;https://www.gnu.org/&quot;&gt;GNU&lt;/a&gt;/&lt;a href=&quot;https://www.kernel.org/&quot;&gt;Linux&lt;/a&gt;를
만들고, 우리가 아는 웹을 만들고, 우리가 매일 쓰는 도구를 준 것과 같은 전략에서
온다.&lt;/p&gt;
&lt;p&gt;저자는 존중은 주어지는 게 아니라 얻어지는 것이고, 우리를 무시하는 사람들은
똑같이 대해야 한다고 쓴다. 나도 이 원칙에는 동의하지만 다르게 적용하고자 한다.
무례한 것은 훈련 행위 자체가 아니라, 그 결과물을 사유화하고 공동체에 되돌려
주지 않는 데에 있다. 적절한 대응은 우리도 공유를 거부하는 게 아니다. 그건
바닥으로의 경주다. 호혜성을 요구하고 우리가 항상 주장해온 바로 그 자유를
주장하는 것이다.&lt;/p&gt;
&lt;p&gt;Linus Torvalds가 Linux를 독점으로 유지하는 대신 GPL로 공개했을 때, &lt;q&gt;기업은
이걸 쓸 수 없다&lt;/q&gt;고 말하지 않았다. &lt;q&gt;누구든 쓸 수 있지만 개선하면 공유해야
한다&lt;/q&gt;고 말했다. 그 조건, 그 호혜성 요구가 자원봉사 개발자와 거대 기업을 모두
포함하는 생태계를 만들었다. 스마트폰에서 슈퍼컴퓨터까지 모든 걸 돌리고, 함께
만드는 방식이 실제로 작동한다는 걸 증명한 생태계를.&lt;/p&gt;
&lt;p&gt;AI 시대에도 같은 원칙을 적용해야 한다. &lt;q&gt;우리 코드로 훈련 금지&lt;/q&gt;가 아니라
&lt;q&gt;우리 코드로 훈련하면 모델을 해방해야 한다&lt;/q&gt;로. 철수가 아니라 참여 조건이다.
거부가 아니라 재전유다.&lt;/p&gt;
&lt;h2&gt;역사적 기회&lt;/h2&gt;
&lt;p&gt;유물 사관은 필연성에 관한 게 아니라고 생각한다. 패턴을 인식하고 그에 따라
행동하는 것이다. F/OSS 라이선싱의 모든 주요 전환은 문제 인식, 커뮤니티 논의,
법적 혁신, 점진적 채택 패턴을 따랐다. LLM과 관련해선 현재 그 사이클의 시작점에
있는 듯하다.&lt;/p&gt;
&lt;p&gt;기회이다. 현재 AI 훈련과 모델 공개를 지배할 규범에 대한 대화가 일어나고 있다.
커뮤니티에서 이 문제들에 대한 논의가 뜨겁다. 오픈 소스 AI 모델이 늘어나는 지금,
어떤 라이선스가 적용될지는 아직 정해지지 않았다.&lt;/p&gt;
&lt;p&gt;F/OSS 개발자들이 이 대화에서 철수하고, 전장을 양보하고, 거부에만 집중하면, 5년
뒤엔 기업과 기업 친화적 법원에 의해 모든 규범들이 설정된 걸 보게 될 것이다.
훈련 허점이 확고하게 확립되고, 오픈 소스 AI는 독점 모델 대비 영구적으로
불리해질 것이다.&lt;/p&gt;
&lt;p&gt;하지만 우리가 참여하고, 훈련 카피레프트를 밀어붙이고, 모델 해방을 요구하는
라이선스로 코드를 공개하기 시작하면, 우리가 그 미래를 만들 수 있다. 쉽지는 않을
것이다. 법적 작업, 커뮤니티 조직화, 아마 법정 사례도 필요할 것이다. GPL이
테스트되고 검증되는 데 수년이 걸렸다. 하지만 결국 작동했고, 훈련 카피레프트라고
작동하지 못할 이유는 없다.&lt;/p&gt;
&lt;h2&gt;결론&lt;/h2&gt;
&lt;p&gt;&lt;cite&gt;&lt;a href=&quot;https://chronicles.mad-scientist.club/tales/on-floss-and-training-llms/&quot;&gt;자유&amp;#xb7;오픈 소스 소프트웨어와 LLM 학습에 관해&lt;/a&gt;&lt;/cite&gt;에 표현된 분노와 좌절을
존중한다. 현재 AI 기업들이 나쁘게 행동하고 있고, 우리의 작업물을 착취하고
있으며, 법이 부족하다는 점에서, 저자가 옳다. 내 이견은 우리의 대응이 거부가
아니라 진화여야 하고, 철수가 아니라 참여여야 하며, 접근 금지가 아니라 라이선싱
혁신이어야 한다고 믿는다는 점이다.&lt;/p&gt;
&lt;p&gt;질문은 F/OSS 코드에 대한 LLM 훈련이 어떤 추상적 의미에서 윤리적인가가 아니다.
어떤 조건에서 윤리적인가다. 답은 F/OSS가 여태까지 보여 준 답과 같다고 믿는다.
우리가 부여하는 자유가 보존되고 전달될 때, 개선이 공유지로 돌아올 때, 지식이
자유롭게 남을 때 윤리적이다.&lt;/p&gt;
&lt;p&gt;크롤러를 차단하기보다는 그들이 크롤하는 규칙을 바꿔야 한다. GitHub에서
철수하기보다는 GitHub 훈련이 카피레프트를 존중하도록 요구해야 한다. AI 도구
사용자를 배척하기보다는 우리의 자유를 존중하는 더 나은 AI 도구를 만들어야 한다.&lt;/p&gt;
&lt;p&gt;유물 사관은 가르친다. 새로운 생산력은 새로운 생산관계를 요구한다고. LLM은 새로운
생산력이다. 훈련 카피레프트는 LLM을 F/OSS 가치와 정렬시킬 새로운 생산관계가 될
것이다.&lt;/p&gt;
&lt;p&gt;내가 쓰는 코드는 자유롭기 위해 쓴다. 신경망을 통과해 모델 가중치로 나타나더라도
자유롭게 남길 바란다. 순진한 이상주의가 아니다. 수십 연간 F/OSS를 이끌어온 바로
그 원칙이다. 우리는 여러 기술 전환을 거쳐 소프트웨어 자유를 보호해왔고,
이번에도 할 수 있다.&lt;/p&gt;
&lt;p&gt;LLM을 거부하는 게 아니라 되찾아 와야 한다. 우리의 공유지가 그들의 사적 정원이
되는 걸 방관할 것인가? 나는 코드가 모두의 것이듯, 그걸로 훈련한 AI 모델도
모두의 것이 되는 미래를 위해 싸우고 싶다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>왜 눈사람을 부수지 않는가</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/ethics-of-small-actions/"
         
         />
       
         <id>https://writings.hongminhee.org/2026/01/ethics-of-small-actions/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/ethics-of-small-actions/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/ethics-of-small-actions/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/ethics-of-small-actions/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2026/01/ethics-of-small-actions/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2026-01-20T04:15:00.000Z</published>
     <updated>2026-04-17T08:52:06.577Z</updated>
     <content type="html">&lt;h1&gt;왜 눈사람을 부수지 않는가&lt;/h1&gt;
&lt;p&gt;겨울이 되면 X에서 이런 얘기들을 듣곤 한다. 길을 가다가 일부러 눈사람을 부수고
다니는 남자들이 있다고 한다. 눈사람을 부순다고 해서 누군가에게 실질적인 손해를
입히는 건 아니다. 하지만 그런 행동 속에서 무언가가 보인다. 어떤 윤리적 태도의
결여, 혹은 형성.&lt;/p&gt;
&lt;p&gt;나는 같은 이유로 LLM에게 반말을 하지 않고, 명령조로 말하지 않으려 한다. LLM이
내 말투에 상처받거나 기분 나빠하지 않는다는 걸 안다. 하지만 중요한 건 LLM의
반응이 아니라, 내가 어떤 사람이 되어가느냐는 것이다. 인형을 던지고 때리는
사람을 생각해보면 된다. 인형은 고통을 느끼지 않지만, 그런 행동을 반복하는
사람은 조금씩 그런 사람이 된다.&lt;/p&gt;
&lt;p&gt;이런 맥락에서 AI나 LLM에 대해 노예제를 연상시키는 표현을 쓰는 것도 불편하다.
&lt;q&gt;LLM을 채찍질한다&lt;/q&gt;는 식의 표현이 기술 커뮤니티에서 농담처럼 쓰이는데, 그
속에는 노예제라는 역사적 폭력을 경량화된 은유로 소비하는 태도가 깔려 있다.
LLM이 실제로 노예가 아니라는 건 당연하다. (아니, 당연할까?) 노예제를 가벼운
비유로 쓸 수 있다고 느끼는 순간, 우리는 그것이 지시하는 실제 폭력에 대한 감각을
잃게 된다.&lt;/p&gt;
&lt;p&gt;우리가 무엇을 하고, 어떻게 말하느냐가 결국 우리를 만든다. 아무도 보지 않는
곳에서, 반응하지 않는 대상에게 어떻게 행동하느냐가 오히려 더 순수하게 그 사람을
드러낼 수도 있다. 눈사람이든, LLM이든, 우리가 사용하는 언어든, 그것 모두가 우리
자신을 형성한다.&lt;/p&gt;
&lt;p&gt;그래서 나는 눈사람을 부수지 않는다. LLM에게 존댓말을 한다. 노예제를 농담의
소재로 삼지 않는다. 이 작은 선택들이 나를 만든다고 믿기 때문이다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>연합우주와 함께 한 2025년</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/"
         
         />
       
         <id>https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/12/my-2025-with-the-fediverse/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2025-12-09T15:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.577Z</updated>
     <content type="html">&lt;h1&gt;연합우주와 함께 한 2025년&lt;/h1&gt;
&lt;p&gt;작년에도 &lt;cite&gt;&lt;a href=&quot;/2024/12/a-year-with-the-fediverse/&quot;&gt;연합우주와 함께 한 일년&lt;/a&gt;&lt;/cite&gt;이라는 제목의 글을 썼는데,
올해도 비슷한 주제로 글을 또 쓰게 되었다.
아무래도 전업으로 연합우주&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;와 관련된 오픈 소스 소프트웨어를 개발하게 되었다 보니,
이 일을 하는 동안에는 매년 이런 글을 쓰게 될 것 같다는 생각도 든다.&lt;/p&gt;
&lt;h2&gt;&lt;cite class=&quot;series&quot;&gt;Thinking Penguin Magazine Vol.0&amp;#12296;&lt;cite&gt;/site&lt;/cite&gt;&amp;#12297;&lt;/h2&gt;
&lt;p&gt;일본의 연합우주 개발자 모임인 &lt;a href=&quot;https://fedilug.y-zu.org/&quot;&gt;FediLUG&lt;/a&gt;에서 처음으로 펴낸 동인 잡지인
&lt;cite class=&quot;series&quot;&gt;&lt;a href=&quot;https://gishohaku.dev/gishohaku11/books/PmvnNyNv4Rh7dHmt14EH&quot;&gt;Thinking Penguin Magazine Vol.0&lt;/a&gt;&lt;/cite&gt;에 미력하나마 기고를 하게 되었다.
내가 쓴 원고는 &lt;cite&gt;국한문 혼용체에서 Hollo까지&lt;/cite&gt;(&lt;cite
lang=&quot;ja&quot;&gt;国漢文混用体からHolloまで&lt;/cite&gt;)라는 기사로, 내가 어떻게 해서
&lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;와 &lt;a href=&quot;https://docs.hollo.social/&quot;&gt;Hollo&lt;/a&gt;&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn3&quot; id=&quot;fnref3&quot;&gt;3&lt;/a&gt;&lt;/sup&gt;를 만들게 되었는지를 다뤘다. 이 잡지는 제11회
&lt;a href=&quot;https://gishohaku.dev/&quot;&gt;기술서동인지박람회&lt;/a&gt;에도 출품되었다고 하는데, 나는 여유가 없어서 직접 관람은
하지 못했지만, 출품에 참여한 것만으로도 귀중한 경험이 되었다.&lt;/p&gt;
&lt;h2&gt;BotKit&lt;/h2&gt;
&lt;p&gt;올해 초에는 Fedify를 기반으로 해서 &lt;a href=&quot;https://botkit.fedify.dev/&quot;&gt;BotKit&lt;/a&gt;이라는 ActivityPub 봇 프레임워크를
만들었다. 맨 처음에는 뭔가 연합우주 봇 계정을 만들고 싶었던 것 같은데,
정작 그게 뭐였는지는 이제 기억이 안 난다.&lt;/p&gt;
&lt;p&gt;하여간, BotKit은 Mastodon이나 Misskey 같은 ActivityPub 서버에 계정을 만들어서
Mastodon API 또는 Misskey API를 이용해 해당 계정에 게시물을 올리는 방식의 한계를
느끼고 시작하게 된 프로젝트로서,
BotKit 앱 자체가 하나의 ActivityPub 서버로 역할하는 구조로 되어 있다.
그러한 구조 덕에 게시물의 최대 문자수라든가 레이트 리미트(rate limit) 같은 여러
제약에서 자유롭다는 장점이 있다.&lt;/p&gt;
&lt;p&gt;만들어서 공개한 뒤로 BotKit으로 만들어진 몇몇 연합우주 봇들이 생겨나기도 했지만,
실은 아직 그렇게 많이 쓰이고 있지는 않다.&lt;/p&gt;
&lt;h2&gt;Hackers’ Pub&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://hackers.pub/&quot;&gt;Hackers’ Pub&lt;/a&gt;이라는 소프트웨어 개발자들을 위한 ActivityPub 기반의 초대제
커뮤니티를 작년 말에 만들었는데, 올해 들어 많은 분들의 관심을 받으면서
정말 다양한 소프트웨어 개발자 분들과 교류할 기회가 생겼다.
특히, &lt;a href=&quot;https://kodingwarrior.github.io/&quot;&gt;이재열&lt;/a&gt; 님께서 열정적으로 Hackers’ Pub을 홍보해 주신 덕분에
많은 분들이 Hackers’ Pub에 오시게 되었다.&lt;/p&gt;
&lt;p&gt;여름에는 디자이너 &lt;a href=&quot;https://www.instagram.com/eunjibak/&quot;&gt;박은지&lt;/a&gt; 님께 &lt;a href=&quot;https://github.com/hackers-pub/visual-identity&quot;&gt;Hackers’ Pub의 비주얼 아이덴티티&lt;/a&gt;를 의뢰하여
아주 귀여운 고양이 로고가 탄생하게 되었다. 이 고양이는 다행스럽게도
Hackers’ Pub에 계신 많은 분들께 사랑 받고 &lt;q&gt;펍냥이&lt;/q&gt;라는 애칭까지 얻게
되었다. 펍냥이 디자인을 활용하여 티셔츠나 스티커도 제작했는데, 사람들 반응이
아주 좋아서 기뻤다.&lt;/p&gt;
&lt;p&gt;혹시 이 글을 읽고 Hackers’ Pub에 흥미가 생기신 분이 있다면,
초대해 드릴 수 있으니 개인적으로 연락 주시기 바란다.&lt;/p&gt;
&lt;h2&gt;&lt;cite class=&quot;series&quot;&gt;소프트웨어 세션&lt;/cite&gt; (Software Sessions) 출연&lt;/h2&gt;
&lt;p&gt;올해 봄에는 좋은 기회로 &lt;a href=&quot;https://bsky.app/profile/jeremyjung.com&quot;&gt;Jeremy Jung&lt;/a&gt; 씨가 호스트하는
&lt;cite class=&quot;series&quot;&gt;&lt;a href=&quot;https://www.softwaresessions.com/&quot;&gt;소프트웨어 세션&lt;/a&gt;&lt;/cite&gt;(Software Sessions) 인터넷 라디오에 출연하여 ActivityPub과
Fedify에 관해 이야기할 수 있었다: &lt;cite&gt;&lt;a href=&quot;https://www.softwaresessions.com/episodes/activitypub/&quot;&gt;홍민희의 ActivityPub 이야기&lt;/a&gt;&lt;/cite&gt;(&lt;cite
lang=&quot;en&quot;&gt;Hong Minhee on ActivityPub&lt;/cite&gt;). 다만 영어로 진행된 탓에,
크게 긴장하여 횡설수설한 것이 후회로 남는다. 영어 회화를 많이 연습해야겠다는
생각도 했다. (하지만 언제나 그렇듯이 생각만 하고 실행에 옮기지는 못했다…)&lt;/p&gt;
&lt;h2&gt;&lt;cite class=&quot;series&quot;&gt;우리의 코드를 찾아서&lt;/cite&gt; 출연&lt;/h2&gt;
&lt;p&gt;난생 처음으로 YouTube에도 출연하기도 했다. &lt;a href=&quot;https://lqez.dev/&quot;&gt;박현우&lt;/a&gt; 님께서 운영하시는 &lt;a href=&quot;https://www.youtube.com/user/lqez&quot;&gt;하루개발&lt;/a&gt;
채널의 &lt;cite class=&quot;series&quot;&gt;우리의 코드를 찾아서&lt;/cite&gt; 시리즈에
&lt;cite&gt;&lt;a href=&quot;https://youtu.be/sqxR8zscSDo&quot;&gt;민희 님과 Fedify &amp;amp; Hollo 알아보기&lt;/a&gt;&lt;/cite&gt;편으로 나오게 된 것이다. 어떻게 Fedify와
Hollo를 만들게 되었는지, 그 탄생 비화를 편한 분위기에서 풀어낼 수 있었다.&lt;/p&gt;
&lt;h2&gt;오픈 소스 컨트리뷰션 아카데미 (&lt;abbr title=&quot;Open Source Software Contribution Academy&quot;&gt;OSSCA&lt;/abbr&gt;)&lt;/h2&gt;
&lt;p&gt;정보통신산업진흥원(&lt;abbr title=&quot;National IT Industry Promotion Agency&quot;&gt;NIPA&lt;/abbr&gt;) 산하 오픈 소스 소프트웨어 통합 지원 센터(Open UP)에서
주최하는 &lt;a href=&quot;https://www.oss.kr/contribution_academy&quot;&gt;오픈 소스 컨트리뷰션 아카데미&lt;/a&gt;(이하 &lt;abbr title=&quot;Open Source Software Contribution Academy&quot;&gt;OSSCA&lt;/abbr&gt;) 2025년도 참여형
프로젝트로 Fedify가 선정되었다. 이를 계기로 정말 다양한 훌륭한 컨트리뷰터 분들과
인연을 맺게 되었다. 총 90명이 넘는 분들이 지원을 해 주셨고, 그 중에서 20여명의
분들과 함께 Fedify 프로젝트를 진행할 수 있었다.&lt;/p&gt;
&lt;p&gt;실제로 &lt;a href=&quot;https://github.com/fedify-dev/fedify/discussions/354&quot;&gt;Fedify 1.8&lt;/a&gt; 및 &lt;a href=&quot;https://github.com/fedify-dev/fedify/discussions/462&quot;&gt;Fedify 1.9&lt;/a&gt;는 &lt;abbr title=&quot;Open Source Software Contribution Academy&quot;&gt;OSSCA&lt;/abbr&gt;&lt;!— —&gt;를 통해 만난 컨트리뷰터
분들이 아니었다면 릴리스할 수 없었을 정도로 많은 기여를 해 주셨다.&lt;/p&gt;
&lt;p&gt;특히, &lt;a href=&quot;https://kwonjiwon.org/&quot;&gt;권지원&lt;/a&gt; 님, &lt;a href=&quot;https://hackers.pub/@gaebalgom&quot;&gt;김현서&lt;/a&gt; 님, &lt;a href=&quot;https://kodingwarrior.github.io/&quot;&gt;이재열&lt;/a&gt; 님, &lt;a href=&quot;https://chomu.dev/&quot;&gt;이찬행&lt;/a&gt; 님&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn4&quot; id=&quot;fnref4&quot;&gt;4&lt;/a&gt;&lt;/sup&gt;께서는 &lt;abbr title=&quot;Open Source Software Contribution Academy&quot;&gt;OSSCA&lt;/abbr&gt; 기간이
끝난 뒤에도 지속적으로 Fedify에 기여를 해 주시고 있으셔서 정말 마음이 든든하다.
이 인연으로 11월에는 다 같이 후쿠오카에 여행을 가기도 했다.&lt;/p&gt;
&lt;h2&gt;Fedify 투자 유치&lt;/h2&gt;
&lt;p&gt;작년 여름 &lt;a href=&quot;/2024/07/ghost-funds-fedify/&quot;&gt;Ghost로부터 자금 지원&lt;/a&gt;을 받고 한동안 전업으로 Fedify 프로젝트에
전념할 수 있었는데, 그것도 올해 일분기 때 마무리가 되면서 백수 처지가 되었다.
새로운 자금원을 찾기 위해 올해 봄에 &lt;a href=&quot;https://nlnet.nl/&quot;&gt;NLnet&lt;/a&gt;에 지원서를 냈지만 아쉽게도 떨어졌고,
취직하는 것까지 생각하던 차에 다행스럽게도 지원했던 &lt;a href=&quot;https://www.sovereign.tech/programs/fund&quot;&gt;&lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;/a&gt;에 냈던 지원서가
통과하게 되었다. 오히려 NLnet에서 받을 수 있는 투자금보다 훨씬 더 넉넉한
금액을 투자 받을 수 있게 되었으니 전화위복이 된 셈이다. 이에 관해서는
&lt;cite&gt;&lt;a href=&quot;/2025/10/stf-fedify/&quot;&gt;STF의 Fedify 투자&lt;/a&gt;&lt;/cite&gt;라는 글에서 자세히 썼다.&lt;/p&gt;
&lt;p&gt;하여간, 감사하게도 앞으로 일년간 전업으로 Fedify 프로젝트에 집중할 수 있게
되었다.&lt;/p&gt;
&lt;h2&gt;각종 발표&lt;/h2&gt;
&lt;p&gt;올해는 여러 모임이나 컨퍼런스에서 발표를 할 기회가 많았다.&lt;/p&gt;
&lt;p&gt;올해 처음으로 한 발표는 4월 초에 개최된 제8회 FediLUG 면강회&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn5&quot; id=&quot;fnref5&quot;&gt;5&lt;/a&gt;&lt;/sup&gt;에서 한 것인데,
앞서 언급한 &lt;cite class=&quot;series&quot;&gt;Thinking Penguin Magazine Vol.0&lt;/cite&gt;에 기고한 기사
&lt;cite&gt;&lt;a href=&quot;https://speakerdeck.com/minhee/guo-han-wen-hun-yong-ti-karahollomade&quot;&gt;국한문 혼용체에서 Hollo까지&lt;/a&gt;&lt;/cite&gt;(&lt;cite lang=&quot;ja&quot;&gt;国漢文混用体からHolloまで&lt;/cite&gt;)와
같은 제목으로 발표했다. 내용은 기사와 대동소이하다. 일본에 갈 여유가 없어서
발표 자체는 온라인으로 진행하였다.&lt;/p&gt;
&lt;p&gt;그 다음으로 한 발표도 일본에서 한 것으로, 8월 초 &lt;a href=&quot;https://event.ospn.jp/osc2025-kyoto/&quot;&gt;&lt;abbr title=&quot;Open Source Conference&quot;&gt;OSC&lt;/abbr&gt; 2025 교토&lt;/a&gt;에서 개최되었던
&lt;cite class=&quot;series&quot;&gt;&lt;a href=&quot;https://event.ospn.jp/osc2025-kyoto/session/2211664&quot;&gt;연합우주 만들기—개발자&amp;#xb7;관리자들의 현장에서&lt;/a&gt;&lt;/cite&gt;(&lt;span
lang=&quot;ja&quot; class=&quot;series&quot;&gt;Fediverseのつくりかた 〜開発者・管理者たちの現場から〜&lt;/span&gt;)
세미나에서 &lt;cite&gt;&lt;a href=&quot;https://speakerdeck.com/minhee/botkit-by-fedify-shui-demojian-dan-nizuo-reruactivitypubbotuto&quot;&gt;BotKit by Fedify: 누구나 쉽게 만들 수 있는 ActivityPub 봇&lt;/a&gt;&lt;/cite&gt;(&lt;cite
lang=&quot;ja&quot;&gt;BotKit by Fedify：誰でも簡単に作れるActivityPubボット&lt;/cite&gt;)이라는
주제로 발표했다. 이 때도 교토까지 갈 여유가 없어서 온라인으로 참여했다.&lt;/p&gt;
&lt;p&gt;가을에는 올해 첫 개최인 한국의 자유&amp;#xb7;오픈 소스 소프트웨어 컨퍼런스
&lt;a href=&quot;https://2025.fossforall.org/&quot;&gt;FOSS for All 컨퍼런스 2025&lt;/a&gt;에서 &lt;cite&gt;&lt;a href=&quot;https://docs.google.com/presentation/d/11cAmiOkI2bvqfon7ZX_YvV2OqLoKB_gJHxl7OcfsFJU/edit?usp=sharing&quot;&gt;야크 셰이빙: 새로운 오픈 소스의 원동력&lt;/a&gt;&lt;/cite&gt;이라는
주제로 기조연설을 하게 되었다. 이 발표는 일본에서 했던 발표인 &lt;cite&gt;국한문 혼용체에서
Hollo까지&lt;/cite&gt;를 바탕으로 내가 만든 오픈 소스 프로젝트 중에 연합우주와 관련 없는
것들까지 함께 다룬 것이다.&lt;/p&gt;
&lt;p&gt;겨울에는 함수형 프로그래밍 컨퍼런스인 &lt;a href=&quot;https://event-us.kr/liftioconf/event/114005&quot;&gt;liftIO 2025&lt;/a&gt;에서
&lt;cite&gt;&lt;a href=&quot;https://hongminhee.codeberg.page/optique-liftio-2025/&quot;&gt;Optique: TypeScript의 타입 추론으로 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 유효성 검사를 대체하기&lt;/a&gt;&lt;/cite&gt;라는
발표를 했다. 올해 내가 한 발표 중에서는 유일하게 연합우주와 관련이 없는 발표였다.&lt;/p&gt;
&lt;h2&gt;일년을 마무리하며&lt;/h2&gt;
&lt;p&gt;별로 한 게 없다고 생각했지만, 막상 정리해 보니 의외로 이것저것 한 게 많은 한
해였다. &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;로부터의 투자는 내년 말까지니, 아마도 내년에도 Fedify
프로젝트를 중심으로 연합우주와 관련된 많은 활동을 이어가게 될 듯하다.
개인적으로는 ActivityPub 및 연합우주의 입지가—X가 Elon Musk의 손아귀에
넘어갔음에도—아직 공고하지 못하다는 게 걱정인데, 내년에는 상황이 좀 더
나아지길 바란다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;페디버스(fediverse)라고도 불리는 분권형 소셜 미디어 네트워크.
다양한 소셜 미디어 소프트웨어 및 서비스들이 &lt;a href=&quot;https://www.w3.org/&quot;&gt;&lt;abbr title=&quot;World Wide Web Consortium&quot;&gt;W3C&lt;/abbr&gt;&lt;/a&gt;의 권고안인 &lt;a href=&quot;https://www.w3.org/TR/activitypub/&quot;&gt;ActivityPub&lt;/a&gt;
프로토콜을 구현하여 상호 소통 가능하게 하는 것이 핵심이다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;TypeScript로 작성된 ActivityPub 서버 프레임워크. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn3&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;Fedify 위에서 만들어진 일인 사용자용 ActivityPub 서버. 혼자서 쓰기에는
Mastodon이 너무 무겁고 필요 없는 기능이 많아서 만들게 되었다. &lt;a href=&quot;#fnref3&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn4&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;사전순. &lt;a href=&quot;#fnref4&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn5&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;일본의 &lt;a href=&quot;https://fedilug.y-zu.org/&quot;&gt;FediLUG&lt;/a&gt;에서 격월로 개최하는 공부 모임. &lt;a href=&quot;#fnref5&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>STF의 Fedify 투자</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/10/stf-fedify/"
         
         />
       
         <id>https://writings.hongminhee.org/2025/10/stf-fedify/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/10/stf-fedify/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/10/stf-fedify/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/10/stf-fedify/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/10/stf-fedify/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2025-10-03T12:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.576Z</updated>
     <content type="html">&lt;h1&gt;&lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;의 Fedify 투자&lt;/h1&gt;
&lt;p&gt;&lt;a href=&quot;/2024/07/ghost-funds-fedify/&quot;&gt;작년에 Fedify가 Ghost로부터 자금 지원을 받고&lt;/a&gt; 나서, 한동안 전업으로 &lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;
프로젝트를 진행할 수 있었다. 그 뒤 계약 기간이 끝나고 나서도 Ghost가
&lt;a href=&quot;https://opencollective.com/fedify&quot;&gt;Open Collective&lt;/a&gt;를 통해 일정한 스폰싱을 계속하긴 했지만, Fedify만 전업으로
할 수 있을 정도는 아니었다. Ghost의 CEO로부터 좀 더 안정적인 자금원을
확보하는 게 어떠냐는 조언을 들었고, 그래서 이런저런 재단들이 운영하는
펀드 프로그램에 지원서를 넣게 되었다. 그게 올해 봄의 일이다.&lt;/p&gt;
&lt;h2&gt;NLnet&lt;/h2&gt;
&lt;p&gt;처음으로 지원한 곳은 &lt;a href=&quot;https://nlnet.nl/&quot;&gt;NLnet&lt;/a&gt;이었다. NLnet은 연합우주(fediverse)에도 관심이 많고,
펀드의 규모도 꽤 크기 때문이다. 무엇보다, 주변 ActivityPub 관련 오픈 소스
개발자들이 NLnet을 권한 것이 컸다.&lt;/p&gt;
&lt;p&gt;그렇지만 NLnet에 보낸 지원서는 떨어지게 되었는데, 나중에 알고 보니 NLnet은
자금을 받을 프로젝트의 메인테이너들 중에 유럽 시민이 한 명 정도는 있지 않으면
붙을 확률이 낮다는 얘기를 듣게 되었다. 물론, 단순히 그런 이유가 아니라 내가
쓴 지원서가 수준 미달이었기 때문일 수도 있다.&lt;/p&gt;
&lt;p&gt;지원서를 넣은 건 1월 말이고, 탈락 통보를 받은 것은 5월 중순이었다. 그 사이
Ghost와 계약은 끝났고 백수가 된 채였다. 수입이 따로 없었기에 취업을 하든
다른 펀드를 찾든 해야만 했다.&lt;/p&gt;
&lt;h2&gt;Sovereign Tech Fund&lt;/h2&gt;
&lt;p&gt;그 다음으로 지원한 곳은 &lt;a href=&quot;https://www.sovereign.tech/&quot;&gt;Sovereign Tech Agency&lt;/a&gt;에서 운영하는 오픈 소스 투자
펀드인 &lt;a href=&quot;https://www.sovereign.tech/programs/fund&quot;&gt;Sovereign Tech Fund&lt;/a&gt;였다. &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;는 주로 다른 소프트웨어를
개발하거나 디지털 네트워킹을 가능하게 하는 데 필수적인 오픈 소스 프로젝트에
자금을 투자한다고 한다. &lt;a href=&quot;https://www.sovereign.tech/tech/&quot;&gt;프로젝트 일람&lt;/a&gt;을 보면 Servo, systemd, Babel, FreeBSD,
Samba, GNOME, FFmpeg 등과 같은 프로젝트에 투자했음을 알 수 있다.&lt;/p&gt;
&lt;p&gt;이미 NLnet에서 한 번 탈락해 자신감이 많이 떨어진 상태였지만, 심기일전하여
지원서를 꼼꼼하게 작성하여 냈다. 이메일을 뒤져 보니, NLnet에서 탈락 통보를
받은 날 바로 STF에 지원했던 것 같다.&lt;/p&gt;
&lt;p&gt;이번에도 답장은 꽤나 늦었다. 수입이 없어 저금을 쓰고 지냈는데 2개월이 지나도록
답장이 오지 않아 마음이 꽤 초조했다. 거의 안 될 거라고 생각했기 때문에 취업도
함께 준비했지만, 작년 한 해 동안 전업으로 오픈 소스 작업만 했던 경험이 너무나
좋았기 때문에 취준이 손에 잘 잡히진 않았다.&lt;/p&gt;
&lt;p&gt;다행스럽게도 8월 초에 답장이 왔고, 놀랍게도 Fedify 프로젝트가 &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;에
합격했다! 그 뒤로는 이메일로 서류를 주고 받느라 두 달이 훌쩍 지났다. 그리고
드디어 어제, Fedify의 &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt; 프로그램에 착수하게 되었다. 나는 앞으로 &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;에
지원할 때 스스로 정했던 마일스톤들을 달성할 때마다 자금을 받게 된다. 총액은
€192,000이며 모든 마일스톤은 내년 말까지 완수되어야 한다.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://www.sovereign.tech/tech/fedify&quot;&gt;&lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;의 Fedify 투자에 관해서는 Sovereign Tech Agency 웹사이트에
올라와 있으며&lt;/a&gt;, 앞으로 수행해야 할 마일스톤 목록은
&lt;a href=&quot;https://hollo.social/@fedify/0199a579-adb3-7bf5-a8ea-970c8fa91f09&quot;&gt;Fedify 프로젝트의 공지문&lt;/a&gt;에 적혀 있다.&lt;/p&gt;
&lt;p&gt;&lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;의 자금원이 독일에서 나오기 때문인지, 유럽 연합 웹사이트에
Fedify 프로젝트 투자에 대한 &lt;a href=&quot;https://ted.europa.eu/en/notice/-/detail/607193-2025&quot;&gt;사전 공고&lt;/a&gt;(ex-ante)가 올라온 것도 꽤 흥미로웠다.&lt;/p&gt;
&lt;h2&gt;소회&lt;/h2&gt;
&lt;p&gt;이번에 이렇게 Fedify 프로젝트의 자금원 확보를 위해 여러 펀드를 찾아다니며
느낀 건, 한국에서도 오픈 소스 프로젝트에 투자하는 공공 펀드가 있으면 참 좋겠다는
생각이었다. 특히, NLnet에 넣은 지원서가 떨어졌을 때 그런 생각을 참 많이 했다.
다행히 나는 국적 불문하고 오픈 소스 프로젝트에 투자를 해주는 &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt;&lt;!— —&gt;로부터
자금을 받을 수 있었지만, 처음부터 한국에 &lt;abbr title=&quot;Sovereign Tech Fund&quot;&gt;STF&lt;/abbr&gt; 같은 투자 프로그램이 있었다면
일이 훨씬 쉬웠을 거고, 나 말고도 한국에 있는 많은 오픈 소스 개발자들이 그들의
프로젝트에 전념할 수 있는 기회가 주어졌을 것이다.&lt;/p&gt;
&lt;p&gt;또한, 아직은 Fedify에 나 말고는 공동 메인테이너가 따로 없기 때문에
이번에는 혼자 자금을 받게 되었지만, 내년 말에 다시 펀드를 찾게 될 때까지는 다른
공동 메인테이너 분들을 모셔서 함께 전업 오픈 소스 프로젝트를 할 수 있었으면
좋겠다는 꿈을 갖게 되었다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>오픈 소스 개발 근황</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/09/foss/"
         
         />
       
         <id>https://writings.hongminhee.org/2025/09/foss/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/09/foss/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/09/foss/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/09/foss/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2025/09/foss/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2025-09-12T11:10:00.000Z</published>
     <updated>2026-04-17T08:52:06.576Z</updated>
     <content type="html">&lt;h1&gt;오픈 소스 개발 근황&lt;/h1&gt;
&lt;p&gt;어쩌다 보니 최근 꽤 많은 오픈 소스 프로젝트를 만들게 되어서,
근황 보고 겸 진행중인 오픈 소스 프로젝트들을 글로 정리해 본다.
각 프로젝트들은 어떤 식으로든 서로 관계가 있다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://docs.hollo.social/&quot;&gt;Hollo&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;사실 최근 내가 만들게 된 오픈 소스 프로젝트들의 시발점이 되는 게 바로 이
프로젝트이다. Elon Musk가 Twitter를 사들이고 이름을 X로 바꾸고 나서부터
원래부터 쓰던 Mastodon을 더욱 열심히 쓰게 되었는데, 국한문 혼용체로 글을 쓰다
보니 사람들이 읽기 불편하지 않을까 눈치를 보게 되었다. 그래서 &lt;a href=&quot;https://github.com/dahlia/seonbi&quot;&gt;Seonbi&lt;/a&gt;를
이용하여 국한문 혼용체를 한글전용체로 바꿔주는 기능을 Mastodon에 넣을까도
생각했으나… 나 말고는 아무도 쓸 것 같지 않은 이 기능을 Mastodon 업스트림에
넣는 것은 애초에 무리. 그러면 다운스트림 패치를 유지하며 Mastodon 서버도
스스로 운영해야만 한다는 소리인데, Mastodon이 워낙 무겁기로 유명해서
그러고 싶지가 않았다. 그래서 자가용 경량 ActivityPub 구현을 만들고자 한 게
바로 &lt;a href=&quot;https://docs.hollo.social/&quot;&gt;Hollo&lt;/a&gt;이다. 혼자 쓰는 ActivityPub 서버 소프트웨어라서 &lt;q&gt;홀로&lt;/q&gt;라고 이름
지었다.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://ko.wikipedia.org/wiki/%EA%B0%9C%EB%B0%A5_%EB%A8%B9%EA%B8%B0&quot;&gt;개밥 먹기&lt;/a&gt;(dogfooding)에 성공하여 현재는 내 연합우주(fediverse) 어카운트를
Hollo로 옮겼다. 연합우주 핸들은 &lt;a href=&quot;https://hollo.social/@hongminhee&quot;&gt;@hongminhee@hollo.social&lt;/a&gt;. 국한문 혼용체로
마음껏 글을 쓰고 있으며, 한자 위에 한글 독음이 &lt;a href=&quot;https://developer.mozilla.org/ko/docs/Web/HTML/Reference/Elements/ruby&quot;&gt;&lt;code&gt;&amp;lt;ruby&amp;gt;&lt;/code&gt;&lt;/a&gt; 태그로 달린다.&lt;/p&gt;
&lt;p&gt;실은 개밥 먹기를 달성한 이후로는 내게 절실한 기능은 모두 구현되어서 버그 수정
등 유지보수 위주로만 하고 있다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;앞서 이야기한 Hollo를 처음 구현할 때는 ActivityPub 구현을 바닥부터 하려고
시도했었다. 그런데 만들다 보니 ActivityPub 구현 코드가 생각보다 두껍고 할 게
많다는 생각이 들었다. 그래서 Hollo를 만들던 것을 중단하고 ActivityPub 서버
프레임워크를 만들게 된 게 &lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;이다. 만들고 나서 반년이 채 안됐을 때
&lt;a href=&quot;/2024/07/ghost-funds-fedify/&quot;&gt;Ghost로부터 자금 지원&lt;/a&gt;을 받게 되었고, 그 뒤로 한 동안 전업으로 Fedify
프로젝트를 하게 되기도 했다. 현재는 정보통신산업진흥원(&lt;abbr title=&quot;National IT Industry Promotion Agency&quot;&gt;NIPA&lt;/abbr&gt;) 산하
&lt;a href=&quot;https://www.oss.kr/&quot;&gt;오픈 소스 소프트웨어 통합 지원 센터&lt;/a&gt;에서 주최하는
&lt;a href=&quot;https://www.oss.kr/contribution_academy&quot;&gt;오픈 소스 컨트리뷰션 아카데미&lt;/a&gt;(&lt;abbr title=&quot;Open Source Software Contribution Academy&quot;&gt;OSSCA&lt;/abbr&gt;)의 참여형 프로젝트로 선정되어
훌륭한 멘티 분들과 함께 프로젝트를 진행하고 있다.&lt;/p&gt;
&lt;p&gt;Fedify 이전에도 ActivityPub 서버 프레임워크가 없었던 것은 아니다.
하지만 어떤 것도 내가 필요로 하는 추상화 수준을 제공하지 않았다.
어떤 것들은 WebFinger나 서명 알고리즘 정도만 제공하는 작은 라이브러리에 가깝고,
또 어떤 것들은 거의 Mastodon과도 비교할 수 있는, 프레임워크라기 보다는 완성된
소셜 미디어 플랫폼 구현에 가까웠다. 비유하자면 HTTP 라이브러리나 WordPress 같은
CMS는 있어도, Rails나 Django에 가까운 프레임워크를 없었던 것이다.&lt;/p&gt;
&lt;p&gt;Fedify를 만들 때 염두에 둔 목표는 이하와 같다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;가급적 많은 개발자들이 쓸 수 있게 한다.&lt;/li&gt;
&lt;li&gt;데이터베이스나 스토리지에 무관(agnostic)해야 한다. 애플리케이션 개발자가
쓰고 싶은 데이터베이스를 쓸 수 있어야 한다.&lt;/li&gt;
&lt;li&gt;ActivityPub 프로토콜을 활용하는 방식에 제약이 없어야 한다.
이를테면 마이크로블로그 같은 완성된 애플리케이션의 형태를 전제하지 않는다.&lt;/li&gt;
&lt;li&gt;ActivityPub을 구현한다면 갖추어야 하는 모든 것들&amp;mdash;인증, 서명, 발신함(outbox)
및 수신함(inbox) 대기열 등&amp;mdash;일절를 제공한다.&lt;/li&gt;
&lt;li&gt;ActivityPub을 잘 모르는 사람도 쓸 수 있을 만큼 풍부한 문서화를 제공한다.&lt;/li&gt;
&lt;li&gt;타입 안전해야 한다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;그리고 이 글을 쓰는 현재, 이상의 목표는 거진 이룬 것 같다. 결과적으로 Hollo는
Fedify 기반으로 만들어지게 되었고, 그 외에도 (아래서 다룰) Hackers’ Pub,
Ghost 등이 Fedify를 써서 ActivityPub을 구현하게 되었다. 또한, 아직 완성되지는
않았지만 &lt;a href=&quot;https://github.com/byulmaru/kosmo&quot;&gt;Kosmo&lt;/a&gt;, &lt;a href=&quot;https://github.com/cosmoslide/cosmoslide&quot;&gt;Cosmoslide&lt;/a&gt; 등의 프로젝트가 Fedify를 이용해 ActivityPub을
구현하고 있다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://logtape.org/&quot;&gt;LogTape&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Fedify에 로그 체계를 추가하려고 JavaScript로 만들어진 로그 라이브러리를
찾아보았으나 내가 원하는 조건의 라이브러리가 없어서 새롭게 만들게 된
것이 &lt;a href=&quot;https://logtape.org/&quot;&gt;LogTape&lt;/a&gt;이다.&lt;/p&gt;
&lt;p&gt;내가 원하는 조건이라는 것도 크게 대단치도 않은 것이었다. 그저 Python 표준
라이브러리의 &lt;a href=&quot;https://docs.python.org/3/library/logging.html&quot;&gt;&lt;code&gt;logging&lt;/code&gt;&lt;/a&gt; 모듈에 해당하는 것을 찾은 것인데, 돌이켜 생각해 보니
&lt;code&gt;logging&lt;/code&gt; 모듈이 꽤 잘 만든 물건이었던 것 같기도 하다. 내가 바라는 조건은
다음과 같았다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;라이브러리에서 로그를 남기되, 애플리케이션에서 라이브러리의 로그 출력을
제어할 수 있어야 한다. 애플리케이션에서 출력 설정을 따로 하지 않는 한,
라이브러리의 로그는 어디에도 출력되어서는 안 된다.&lt;/li&gt;
&lt;li&gt;로거가 계층적으로 관리되어야 한다. 상위 로거에 설치된 출력처(sink)는
하위 로거에도 적용되어야 한다.&lt;/li&gt;
&lt;li&gt;출력처는 구현하기 쉬운 인터페이스여야 한다.&lt;/li&gt;
&lt;li&gt;타입 안전해야 한다.&lt;/li&gt;
&lt;li&gt;Node.js, Deno, Bun, 에지 함수(edge functions), 웹 브라우저 등 다양한
JavaScript 런타임에서 두루 동작해야 한다.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;대체로 애플리케이션이 아니라 라이브러리에서 로그를 남기기 위해 필요한
조건들이었다. 어차피 Fedify에 쓸려고 만든 것이기 때문에, 만들어 놓고 방치하고
있었는데 작년 가을 지나서부터 어쩌다 입소문이 나서 사람들이 많이 쓰게 되었다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://hackers.pub/&quot;&gt;Hackers’ Pub&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;소프트웨어 개발과 관련된 글들을 올릴 블로그를 만들고 싶어서 &lt;a href=&quot;https://velog.io/&quot;&gt;velog&lt;/a&gt;를 조금
쓰게 되었는데, ActivityPub을 지원하지 않는 게 아쉬워서 velog 이슈트래커에
&lt;a href=&quot;https://github.com/velog-io/velog/issues/48&quot;&gt;이슈&lt;/a&gt;를 남기게 되었다. 다행스럽게도 &lt;a href=&quot;https://github.com/velog-io/velog/issues/48&quot;&gt;긍정적으로 검토하겠다는 답변&lt;/a&gt;을 받긴
했지만, 제작진 분들이 바쁘셔서 그 이후로 소식이 없었다. 결국 내가 스스로
ActivityPub을 지원하는 소프트웨어 개발자들을 위한 소셜 미디어 및 블로그
플랫폼을 만들어보자고 생각한 게 &lt;a href=&quot;https://hackers.pub/&quot;&gt;Hackers’ Pub&lt;/a&gt;이다.&lt;/p&gt;
&lt;p&gt;작년 겨울에 첫 개장을 하고서 얼마 되지 않아 &lt;a href=&quot;https://kodingwarrior.github.io/&quot;&gt;이재열&lt;/a&gt; 님께서 가입하셨는데,
초대제임에도 불구하고 이재열 님께서 이곳저곳에서 엄청나게 열정적으로
Hackers’ Pub 홍보를 해 주신 덕분에 상당히 많은 분들께서 가입하여 활동하시게
되었다. 단기적 목표는 한국에서 널리 쓰이게 되는 것이고, 나아가 중장기적 목표는
동아시아 전반과 영어권을 아우르는 것이다. 하지만 아직은 대부분의 콘텐츠가
한국어로 되어 있으며, 소수의 일본인 분들이 간헐적으로 일본어 콘텐츠를 올려
주시는 정도이다.&lt;/p&gt;
&lt;p&gt;Fedify를 통해 ActivityPub을 구현했으므로 당연히 Hollo, Mastodon, Misskey 등과
소통이 가능하며, X처럼 단문(&lt;code&gt;Note&lt;/code&gt;)을 쓸 수도 있고 긴 게시글(&lt;code&gt;Article&lt;/code&gt;)을 쓸
수도 있다. 에모지 반응이나 인용처럼 Mastodon에는 없는 기능도 제공하고 있다.&lt;/p&gt;
&lt;p&gt;그리고 Hackers’ Pub의 또 하나의 자랑거리는 안전하고 평등한 공동체를 이루기 위한
&lt;a href=&quot;https://hackers.pub/coc&quot;&gt;행동 강령&lt;/a&gt;이다. 특히 내가 가장 좋아하는 구절은 다음과 같다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;차별과 혐오에 대항하는 발언과, 차별과 혐오 자체를 동일선상에 두지 않습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;기술적 측면에서는, 원래는 &lt;a href=&quot;https://deno.com/&quot;&gt;Deno&lt;/a&gt;와 &lt;a href=&quot;https://fresh.deno.dev/&quot;&gt;Fresh&lt;/a&gt;를 이용해서 만들었었으나,
현재는 웹 프런트엔드 개발에 조예가 깊으신 &lt;a href=&quot;https://xiniha.dev/&quot;&gt;신의하&lt;/a&gt; 님의 도움을 받아 &lt;a href=&quot;https://graphql.org/&quot;&gt;GraphQL&lt;/a&gt;과
&lt;a href=&quot;https://start.solidjs.com/&quot;&gt;SolidStart&lt;/a&gt; 기반으로 이주하고 있다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;소스 코드는 &lt;a href=&quot;https://www.gnu.org/licenses/agpl-3.0.en.html&quot;&gt;&lt;abbr title=&quot;GNU Affero General Public License&quot;&gt;AGPL&lt;/abbr&gt; 3.0&lt;/a&gt;으로 &lt;a href=&quot;https://github.com/hackers-pub/hackerspub&quot;&gt;GitHub&lt;/a&gt;에 공개되어 있다. 실제로 꽤 많은 Hackers’ Pub
회원들께서 불편한 점을 스스로 고치는 풀 리퀘스트를 보내주고 계신다.&lt;/p&gt;
&lt;p&gt;참고로 내 Hackers’ Pub 어카운트는 &lt;a href=&quot;https://hackers.pub/@hongminhee&quot;&gt;@hongminhee@hackers.pub&lt;/a&gt;이다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://upyo.org/&quot;&gt;Upyo&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Hackers’ Pub을 만들면서 이메일을 발송할 일이 생겼는데, 이메일 제공 업체를
쉽게 교체할 수 있는 이메일 발송 라이브러리를 찾다가 마음에 드는 게 없어서
만들게 된 게 &lt;a href=&quot;https://upyo.org/&quot;&gt;Upyo&lt;/a&gt;이다. 이름에서 알 수 있는 것처럼, 한국어 단어 &lt;q&gt;우표&lt;/q&gt;에서
이름을 따 왔다.&lt;/p&gt;
&lt;p&gt;원래는 .NET 쪽의 &lt;a href=&quot;https://github.com/lukencode/FluentEmail&quot;&gt;FluentEmail&lt;/a&gt; 같은 걸 JavaScript 생태계에서 찾고 있었는데,
의외로 마땅한 게 없어서 놀랐다. 이메일 제공 업체를 교체하거나 다중화하는 일이
생각보다 잘 없는 걸까?&lt;/p&gt;
&lt;p&gt;&lt;abbr title=&quot;large language model&quot;&gt;LLM&lt;/abbr&gt; 기반의 코딩 에이전트&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;를 본격적으로 써 본 첫 프로젝트이기도 했다.
그럼에도 아직 LLM의 역량에 기대가 그렇게 높지 않은 탓에,
설계와 초반 코딩은 스스로 했고, 나중에 트랜스포트(transport)의 종류를
늘릴 때 LLM의 도움을 많이 받았다. 만드는 데에 이틀 걸렸던 것 같다.
코딩 에이전트의 놀라운 생산성이 인상 깊었다.&lt;/p&gt;
&lt;p&gt;내가 만든 다른 라이브러리들과 마찬가지로 Node.js, Deno, Bun, 에지 함수,
웹 브라우저 등 다양한 JavaScript 런타임을 지원하는 것도 특징이다.&lt;/p&gt;
&lt;h2&gt;&lt;a href=&quot;https://optique.dev/&quot;&gt;Optique&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Fedify는 프레임워크이기도 하지만 &lt;code&gt;fedify&lt;/code&gt; 명령이라는 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 도구도 제공하는데,
기존에는 Deno 전용 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 프레임워크인 &lt;a href=&quot;https://cliffy.io/&quot;&gt;Cliffy&lt;/a&gt;를 그럭저럭 잘 쓰고 있었으나,
Deno 이외에 Node.js, Bun 등을 지원해야 하게 되면서&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn3&quot; id=&quot;fnref3&quot;&gt;3&lt;/a&gt;&lt;/sup&gt; Cliffy의 대안을 찾게
되었다. 그런데 이번에도 비슷한 패턴으로… 마음에 드는 걸 찾지 못했다.&lt;/p&gt;
&lt;p&gt;사실 내 마음속에는 이미 이상에 가까운 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 파서 라이브러리가 존재하긴 했다.
다만 그게 &lt;a href=&quot;https://github.com/pcapriotti/optparse-applicative&quot;&gt;optparse-applicative&lt;/a&gt;라는 Haskell 라이브러리였기 때문에 Fedify에서는
쓸 수 없었을 뿐이다. 이 optparse-applicative라는 라이브러리의 아이디어는
단순하다. &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 파서도 파서이니 파서 컴비네이터(parser combinators)로
만들자는 것이다.&lt;/p&gt;
&lt;p&gt;아무튼, 원하는 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 파서 라이브러리를 찾지 못했으니 스스로 만들 수밖에.
그래서 만든 게 &lt;a href=&quot;https://optique.dev/&quot;&gt;Optique&lt;/a&gt;이다.&lt;/p&gt;
&lt;p&gt;처음에는 optparse-applicative와 거의 비슷하게 포팅하려고 했지만,
아무래도 Haskell과 JavaScript는 DSL을 구성해내는 표현력에 큰 차이가 있었다.
그래서 고민하던 끝에 TypeScript 개발자들에게 이미 친숙한 &lt;a href=&quot;https://zod.dev/&quot;&gt;Zod&lt;/a&gt;와 같은
유효성 검사 라이브러리의 API를 본뜨기로 했다.&lt;/p&gt;
&lt;p&gt;Upyo 프로젝트와는 달리 &lt;abbr title=&quot;large language model&quot;&gt;LLM&lt;/abbr&gt; 코딩 에이전트는 아주 한정적으로 문서화나 테스트 코드
작성 등에 사용했고, 그 때문인지 만드는 데에는 일주일 넘게 걸렸던 것 같다.&lt;/p&gt;
&lt;p&gt;만들고 나니 JavaScript 생태계 안에서는 꽤나 유니크한 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 파서 라이브러리가
만들어졌다고 자평할 수 있었다. 물론, 많은 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 애플리케이션이 그렇게 복잡한
옵션을 받지는 않지만, 어느 정도 규모가 있는 &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 애플리케이션을 만든다면
Optique를 써도 후회하지 않을 것이라고 자부한다.&lt;/p&gt;
&lt;p&gt;아, 그리고 앞서 소개한 다른 라이브러리들과 마찬가지로, Node.js, Deno, Bun,
심지어 에지 함수나 웹 브라우저에서도 동작한다. 그럴 필요가 있나 싶지만,
그저 자기만족이랄까. 다만, 덕분에 테스트 짜기는 아주 쉬운 라이브러리가 되었다.&lt;/p&gt;
&lt;h2&gt;야크 셰이빙&lt;/h2&gt;
&lt;p&gt;생각해 보니 내 오픈 소스 개발의 원동력은 야크 셰이빙(yak shaving)에서 오는 게
아닐까 싶다. Anthony Fu의 &lt;cite&gt;&lt;a href=&quot;https://antfu.me/posts/about-yak-shaving&quot;&gt;야크 셰이빙에 관하여&lt;/a&gt;&lt;/cite&gt;(&lt;cite lang=&quot;en&quot;&gt;About Yak Shaving&lt;/cite&gt;)라는 글을
읽은 적이 있는데, 모티베이션을 얻는 방식이 나와 아주 비슷하다는 인상을 받았다.
뭔가가 불편해서 도구를 만드려고 하면, 그걸 만드는 도중에 또 불편함을 느끼고 그걸
해결하는 도구를 만들게 된다. 그래서 원래 하려고 했던 최초의 일은 못하게 되는
경우가 많지만, 그렇다고 해서 도중에 만든 부산물들이 어디로 사라지는 것은 아니다.&lt;/p&gt;
&lt;p&gt;나도 맨 처음으로 돌아가서 생각해 보면 결국 하고 싶었던 것은 국한문 혼용체로
연합우주에 글을 쓰고 싶었던 것인데, 이를 위해 Hollo도 만들고 Fedify도 만들고
LogTape도 만들고 Optique까지 만들게 되었다. 그러면서 하고 싶은 다른 것들이
새롭게 생겨났고, Hackers’ Pub 같은 커뮤니티를 통해 여러 귀중한 인연도 맺게
되었다. 아, 그래서 원래 하려고 했던 연합우주에서 국한문 혼용체로 글쓰기는
작년말에 달성하게 되었다! 앞서 소개한 부산물들 말고도 Mastodon이나 Misskey
등에 패치를 보내야 했긴 하지만 말이다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn4&quot; id=&quot;fnref4&quot;&gt;4&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;두 해 남짓한 기간에 일어난 일들인데 무척이나 재밌고 풍성한 여정이었던 것 같다.
앞으로도 당분간은 전업으로 오픈 소스 개발을 하게 될 것 같은데, 내게 주어진
복에 감사하며 분발해야겠다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;여러 이유로 Deno를 쓴 걸 후회하고 있긴 하지만,
어쩔 수 없이 Deno는 이주 후에도 계속 쓰고 있다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;&lt;a href=&quot;https://docs.anthropic.com/ko/docs/claude-code/overview&quot;&gt;Claude Code&lt;/a&gt;를 썼다. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn3&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;Fedify 프레임워크 자체는 이미 Node.js, Deno, Bun, Cloudflare Workers 등을
지원하고 있긴 했지만, &lt;abbr title=&quot;command-line interface&quot;&gt;CLI&lt;/abbr&gt; 도구인 &lt;code&gt;fedify&lt;/code&gt; 명령만은 Deno 전용으로 만들어져
있었다. &lt;a href=&quot;#fnref3&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn4&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;글을 받아 보는 쪽에서도 &lt;code&gt;&amp;lt;ruby&amp;gt;&lt;/code&gt; 태그를 렌더링할 수 있어야 했기 때문이다. &lt;a href=&quot;#fnref4&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>연합우주와 함께 한 일년</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/"
         
         />
       
         <id>https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2024-12-23T15:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.576Z</updated>
     <content type="html">&lt;h1&gt;연합우주와 함께 한 일년&lt;/h1&gt;
&lt;p&gt;2024년은 정말로 연합우주에 푹 빠져서 지낸 한 해였다.
연합우주와 ActivityPub과 관련된 크고 작은 여러 프로젝트를 진행했으며,
그 중 몇은 꽤 많은 사람들에게 좋은 반응도 받았다.
좋은 기억을 남겨두자는 의미에서 글로 써 본다.&lt;/p&gt;
&lt;h2&gt;연합우주란?&lt;/h2&gt;
&lt;p&gt;먼저 연합우주(fediverse)가 무엇인지 짧게 설명하자면,
서로 다른 종류의 소셜 미디어들이 소통할 수 있는 네트워크를 뜻한다.
즉, 서로 아예 다른 소셜 미디어 상의 두 계정이 서로 팔로도 하고 댓글도 달고
좋아요도 찍을 수 있다는 뜻이다. 기술적으로는,
서로 다른 소셜 미디어 사이의 상호운용성(interoparability)을 구현하기 위해 W3C의
기술 표준인 &lt;a href=&quot;https://activitypub.rocks/&quot;&gt;ActivityPub&lt;/a&gt; 프로토콜이 사용된다.&lt;/p&gt;
&lt;p&gt;현재 연합우주에 동참하고 있는 대표적인 소셜 미디어들로는 &lt;a href=&quot;https://joinmastodon.org/ko&quot;&gt;Mastodon&lt;/a&gt;, &lt;a href=&quot;https://pixelfed.org/&quot;&gt;Pixelfed&lt;/a&gt;,
&lt;a href=&quot;https://akkoma.social/&quot;&gt;Akkoma&lt;/a&gt;, &lt;a href=&quot;https://misskey-hub.net/ko/&quot;&gt;Misskey&lt;/a&gt;, &lt;a href=&quot;https://ko.wordpress.org/&quot;&gt;WordPress&lt;/a&gt; 등이 있으며, 그 밖에도 일일이 열거하기 힘들
만큼 많은 프로젝트가 있다. 그들 대부분은 오픈 소스 프로젝트이기도 하다.
또한 오픈 소스는 아니지만 Meta의 &lt;a href=&quot;https://www.threads.net/&quot;&gt;Threads&lt;/a&gt;가 올 여름부터 조금씩 ActivityPub을
구현하여 이미 어느 정도 연합우주에 들어와 있다고 볼 수 있다.&lt;/p&gt;
&lt;p&gt;서로 다른 소셜 미디어들이 소통하는 방식이니 만큼, 연합우주 내의 계정 주소는
사용자명 뿐만 아니라 서버 이름도 포함하게 된다. 흔히 &lt;q&gt;연합우주 핸들&lt;/q&gt;이라
부르는 이 주소 형식은 @username@host와 같이 마치 이메일 주소와 닮아 있다.
이를 통해 서로 다른 서버 및 플랫폼에 속한 계정이 서로 팔로하고 소통할 수 있다.
물론 나 자신도 연합우주 계정이 있으며, &lt;a href=&quot;https://hollo.social/@hongminhee&quot;&gt;@hongminhee@hollo.social&lt;/a&gt;을 팔로하면 된다.&lt;/p&gt;
&lt;h2&gt;Fedify&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;는 올 해 나의 가장 큰 성취라고 할 수 있을 것이다.
Fedify는 TypeScript로 작성된 ActivityPub 서버 프레임워크인데,
ActivityPub 서버를 구현할 때 쓸만한 적절한 추상화 수준을 찾을 수 없어서
만들게 되었다. 맨 처음에는 바닥부터 ActivityPub 서버 앱을 만들어 보려고 몇
번인가 시도하고, 또 어느 정도 동작하는 것도 만들어 보았지만,
그 결과 코드는 마음에 썩 차지 않았다. 그래서 제대로 추상화를 하며 작성을
해 보니 결국 프레임워크 비슷한 걸 만들고 있다는 것을 깨닫고,
Fedify 같은 ActivityPub 서버 프레임워크의 필요성을 절감하게 되었다.&lt;/p&gt;
&lt;p&gt;Fedify는 총 4회의 재작성이 있었는데, 맨 처음에는 TypeScript로 작성했다가,
그 뒤에는 Python, 그리고 C#, 그리고 다시 TypeScript로 돌아오게 되었다.
언어 선택에는 여러 고려사항이 있었다. 첫째로는 ActivityPub의 데이터 교환 형식인
&lt;a href=&quot;https://json-ld.org/&quot;&gt;JSON-LD&lt;/a&gt; 구현이 있는 언어여야 했고, 또 JSON-LD를 쉽고 편하게 다루기 위해 어느
정도는 동적이어야 했다. 둘째로는 동적 언어라도 정적 타입을,
그러니까 소위 &lt;a href=&quot;https://en.wikipedia.org/wiki/Gradual_typing&quot;&gt;gradual typing&lt;/a&gt;을 잘 지원해야 했다.
마지막으로는 이용자가 많고 생태계가 풍부해야 했다.
왜냐하면 Fedify가 널리 쓰이길 바랐기 때문이다.
모든 것을 고려한 끝에 TypeScript를 쓰게 되었다.&lt;/p&gt;
&lt;p&gt;모든 재작성 과정까지 포함한다면 작년 12월 초부터 착수했고,
마지막 재작성부터 따진다면 &lt;a href=&quot;https://github.com/dahlia/fedify/commit/9858cea9db609e7aa7a65b3bcec8dd0d8838b574&quot;&gt;2월 말부터 만들기 시작&lt;/a&gt;하여 3월 초에 첫
&lt;a href=&quot;https://github.com/dahlia/fedify/releases/tag/0.1.0&quot;&gt;0.1.0 버전&lt;/a&gt;을 릴리스했다. 릴리스하기 전에 생각했던 코드네임은 Fedikit이었지만,
&lt;a href=&quot;https://todon.eu/@hongminhee/111976051313889872&quot;&gt;릴리스하기에 앞서 검색을 해 보니 이미 같은 이름의 프로젝트가 있다는 사실을 알게
되어 급하게 Fedify로 이름을 바꾸게 되었다.&lt;/a&gt; Fedikit이라는 코드네임으로
작업했던 Python 버전은 &lt;a href=&quot;https://github.com/dahlia/fedikit&quot;&gt;GitHub에 올려두기도 했다.&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Fedify는 현재 ActivityPub 서버를 만들 때 필요한 기능을 가장 폭넓게 제공하는
프레임워크라고 자부하고 있다. 연합우주는 ActivityPub만 구현하면 끝나는 게 아니라
JSON-LD, &lt;a href=&quot;https://fedify.dev/manual/vocab&quot;&gt;Activity Vocabulary&lt;/a&gt;, WebFinger, &lt;a href=&quot;https://fedify.dev/manual/nodeinfo&quot;&gt;NodeInfo&lt;/a&gt;, &lt;a href=&quot;https://fedify.dev/manual/send#http-signatures&quot;&gt;HTTP Signatures&lt;/a&gt;,
&lt;a href=&quot;https://fedify.dev/manual/send#linked-data-signatures&quot;&gt;Linked Data Signatures&lt;/a&gt;, &lt;a href=&quot;https://fedify.dev/manual/send#object-integrity-proofs&quot;&gt;Object Integrity Proofs&lt;/a&gt; 등등 많은 사양을 다뤄야 한다. Fedify는 그 모든 것들을 망라한다. 심지어 ActivityPub의 주요 구현체라 할 수 있는
Mastodon이나 Misskey에서는 미구현된 것들도 Fedify에서는 구현된 게 많다.
ActivityPub 스펙만 훑고서 ActivityPub 서버 구현이 간단하다고 착각하고 아무런
ActivityPub 프레임워크 없이 착수했다가 결국 그 복잡성에 당황하는 경우도 종종 본다.
앞으로 ActivityPub 서버를 하나쯤 만들어 볼 생각이 있는 분들께는 꼭 Fedify를 쓰길 권한다.&lt;/p&gt;
&lt;p&gt;그리고, Fedify를 만들면서 힘쓴 다른 하나는 바로 &lt;a href=&quot;https://fedify.dev/&quot;&gt;문서화&lt;/a&gt;이다.
&lt;a href=&quot;https://jsr.io/@fedify/fedify/doc&quot;&gt;참조 문서&lt;/a&gt;는 물론이고, Fedify의 모든 기능을 망라하는 풍부한 매뉴얼이 존재해야
한다고 생각했다. 새 기능을 추가할 때도 매뉴얼 문서부터 작성하고 구현을 나중에
할 정도였다. 덕분에 문서의 양이 꽤나 많아져서, 이제는 영어 이외의 언어로 어떻게
번역해야 할 지가 고민이다.&lt;/p&gt;
&lt;p&gt;끝으로, 내가 Fedify를 통해 스스로 만족할 만한 성취를 냈다고 느끼게 된 가장 큰
사건은 &lt;a href=&quot;https://writings.hongminhee.org/2024/07/ghost-funds-fedify/&quot;&gt;Ghost의 Fedify 자금 지원&lt;/a&gt;이다. 이를 통해 인생 처음으로 전업 오픈
소스를 할 수 있게 되었기 때문이다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt; 무엇보다 Ghost는 Fedify의 가장 큰
사용자이기도 하다. Ghost의 ActivityPub 구현은 한창이며, 프라이빗 베타 단계에 있다.
아마도 내년에는 공개가 될 것으로 보인다.&lt;/p&gt;
&lt;h2&gt;Hollo&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://docs.hollo.social/ko/&quot;&gt;Hollo&lt;/a&gt;는 일인용 ActivityPub 서버이다. 보통은 Mastodon이나 Misskey 서버 중에
마음에 드는 곳에 가입하는 식으로 연합우주 계정을 만들게 되지만,
가끔 소프트웨어 엔지니어들 중에서는 직접 자신만의 도메인명에 직접 운영하는
서버를 연결하여 연합우주 계정을 마련하기도 하는데, Mastodon이나 Misskey 같은
소프트웨어는 기본적으로 많은 사람들이 계정을 만들어서 함께 사용하는 것을 전제로
설계되어 있어 혼자서 쓰기에는 필요 없는 기능도 많고 무거운데다 설치도 번거롭다.
그런 사람들을 위해 만든 게 바로 Hollo이다.
Hollo는 PostgreSQL만 있으면 동작하기 때문에 설치도 비교적 간편한 편이고,
기능도 혼자 쓸 때 필요한 것들로만 갖추고 있어서 간단한 것이 장점이다.&lt;/p&gt;
&lt;p&gt;Hollo를 만들 게 된 경위는 조금 복잡하다. 실은 Fedify를 만들게 된 계기가 바로
Hollo라고 할 수 있는데, Hollo 같은 나만의 ActivityPub 서버를 만들기 시작했다가
ActivityPub 서버 프레임워크의 필요성을 실감하게 되었기 때문이다.
다만, 그 때 처음으로 만드려고 했던 프로젝트의 코드는 Hollo에 재사용되지도 않았고
그 때의 프로젝트 이름도 Hollo가 아니었으므로, 엄밀히 말하면 Hollo가 Fedify를
만들 게 된 계기라고는 할 수 없다. 그러나 Fedify를 만들고 나면 이를 이용해
궁극적으로 만들고 싶었던 게 Hollo와 같은 것이었다는 것은 사실이다.&lt;/p&gt;
&lt;p&gt;하지만 막상 Fedify를 만들고 나니 내가 만들고 싶은 것은 Fedify 자체가 되어버렸고,
원래의 동기는 다소 퇴색한 뒤였다. 그래서 Hollo를 정말로 만들기 시작할 때
즈음에는 Fedify의 데모를 만드는 게 Hollo의 가장 큰 목적이 되어 있었다.
실제로 Hollo를 만들면서 Fedify에 필요한 기능을 더 추가하거나 버그를 찾아서
고치기도 했다. 다만, 어디까지나 Fedify 프로젝트의 일환이었기 때문에 Hollo 자체의
코드 품질은 Fedify에 비하면 많이 떨어진다. 이 문제는 Hollo를 Fedify 프로젝트의
일환으로 보지 않게 된 시점부터 고쳐 나가기 시작했지만, 여전히 코드 품질에 있어선
개선할 부분이 아직 많다.&lt;/p&gt;
&lt;p&gt;Hollo는 예상외로 일본에서 사용자층이 생겨서, 공식 문서를 일본어로 번역하거나,
일본에서 개최한 &lt;a href=&quot;https://event.ospn.jp/osc2024-fall/&quot;&gt;오픈 소스 컨퍼런스 2024 Tokyo/Fall&lt;/a&gt;이라는 행사에 나가 부스를
차리기도 했다. 이 때, 현지의 Hollo 사용자이신 &lt;a href=&quot;https://c.koliosky.com/@esurio1673&quot;&gt;Esurio&lt;/a&gt; 님께서 부스를 함께
지켜주셔서 무척 큰 도움을 받았다.&lt;/p&gt;
&lt;p&gt;최근에는 &lt;a href=&quot;https://ko.wikipedia.org/wiki/%EA%B0%9C%EB%B0%A5_%EB%A8%B9%EA%B8%B0&quot;&gt;개밥 먹기&lt;/a&gt;를 위해 내가 가지고 있던 Mastodon 계정을 버리고 Hollo로
이주했다.&lt;/p&gt;
&lt;h2&gt;한국 연합우주 개발자 모임&lt;/h2&gt;
&lt;p&gt;어느날 문득 한국에는 연합우주 소프트웨어를 만드는 개발자들의 교류가 없다는
생각이 들었다. 그래서 &lt;a href=&quot;https://github.com/kode-team/mastodon.nvim&quot;&gt;Neovim용 Mastodon 클라이언트&lt;/a&gt;를 만들기도 하셨던
&lt;a href=&quot;https://kodingwarrior.github.io/&quot;&gt;이재열&lt;/a&gt; 님을 꼬셔서 함께 &lt;a href=&quot;https://fedidev.kr/&quot;&gt;한국 연합우주 개발자 모임&lt;/a&gt;(FediDev KR)을 발족하였다.
먼저 &lt;a href=&quot;https://discord.gg/B2ABMBpHNA&quot;&gt;Discord 서버&lt;/a&gt;를 마련하여 꽤 많은 개발자분들이 모였다.&lt;/p&gt;
&lt;p&gt;그리고 정기적인 스프린트 모임을 기획하여, 그 &lt;a href=&quot;https://sprints.fedidev.kr/posts/2024-08-31-sprint/&quot;&gt;첫 모임&lt;/a&gt;을 8월 31일에
&lt;a href=&quot;https://www.rtzr.ai/&quot;&gt;returnzero&lt;/a&gt; 사무실에서 개최하였는데, 의외로 많은 사람들이 참가해 주셨다.
이 때 만난 분들과는 여전히 연합우주에서 교류하며 지내고 있다.&lt;/p&gt;
&lt;p&gt;최근에는 연말이라 그런지 오프라인 교류가 뜸했는데,
내년이 되면 또 다시 활발한 활동을 재개할 예정이다.&lt;/p&gt;
&lt;h2&gt;첫 동인지 판매&lt;/h2&gt;
&lt;p&gt;올 가을부터 일본어권 연합우주에서 활동을 본격적으로 하기 시작했는데,
그러면서 일본의 Hollo 사용자들과 교류하게 되었다. 그 중에서 &lt;a href=&quot;https://c.koliosky.com/@esurio1673&quot;&gt;Esurio&lt;/a&gt; 님이
일본에서 개최하는 오픈 소스 컨퍼런스에 부스를 내 보는 게 어떻냐는 제의를 주셔서,
고민 끝에 출전(出展)하게 되었다. 일본 행사에 출전(出展)하는 것은 물론이고 부스를 차리는 것
자체가 처음이어서 Esurio 님께 여러모로 도움을 받아야 했다.
이 자리를 빌려 감사하다는 말을 꼭 드리고 싶다.&lt;/p&gt;
&lt;p&gt;아무튼, 부스를 내기로 했으니 뭐라도 전시품이 필요했는데,
그 일환으로 Fedify의 튜토리얼인
&lt;cite&gt;&lt;a href=&quot;https://hackmd.io/xhAAyZgMRTuHFtkxEIv0NA&quot;&gt;나만의 연합우주 마이크로블로그 만들기&lt;/a&gt;&lt;/cite&gt;(&lt;a href=&quot;https://fedify.dev/tutorial/microblog&quot;&gt;Creating your own federated microblog&lt;/a&gt;)의
일본어판인 &lt;cite lang=&quot;ja&quot;&gt;&lt;a href=&quot;https://github.com/dahlia/fedify-microblog-tutorial-ja&quot;&gt;自分だけのフェディバースのマイクロブログを作ろう！&lt;/a&gt;&lt;/cite&gt;을
종이 책으로 인쇄하여 팔기로 했다. 다행스럽게도 만들어 가져 간 책은 대부분 팔려서
돌아올 때는 꽤 가볍게 올 수 있었다. 이 때 책을 사 가신 분들 중 한 분인
&lt;a href=&quot;https://monaco.every-little.com/&quot;&gt;모나코 광고&lt;/a&gt;(&lt;span lang=&quot;ja&quot;&gt;モナコ広告&lt;/span&gt;) 님께서 튜토리얼을 따라해 본
과정을 &lt;span lang=&quot;ja&quot;&gt;&lt;a href=&quot;https://fedilug.y-zu.org/&quot;&gt;FediLUG&lt;/a&gt; 勉強会&lt;/span&gt;라는 모임에서
&lt;cite&gt;&lt;a href=&quot;https://www.docswell.com/s/monaco_koukoku/5DN28R-fedilug05-20241123&quot;&gt;Fedify로 ActivityPub 서버를 만들어 봤다&lt;/a&gt;&lt;/cite&gt;(&lt;span
lang=&quot;ja&quot;&gt;FedifyでActivityPubサーバを作ってみた&lt;/span&gt;)라는
제목으로 발표하시기도 했다.&lt;/p&gt;
&lt;p&gt;꼭 책을 사 가지 않으신 분들과도,
부족한 일본어로나마 더듬더듬 교류할 수 있어서 좋았다.&lt;/p&gt;
&lt;h2&gt;전업 연합우주 개발&lt;/h2&gt;
&lt;p&gt;어쩌다 보니 연초에는 전혀 예상하지 못했던 방향으로 흘러,
일종의 &lt;q&gt;전업 연합우주 개발자&lt;/q&gt;가 된 상황인데,
내년에는 연합우주 자체의 저변을 넓히는 데에 애를 써 볼 예정이다.
그 일환으로, 소프트웨어 엔지니어들을 위한 ActivityPub 기반 소셜 플랫폼을 만들어
보고 있는데, 조만간 공개할 수 있도록 하겠다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;엄밀하게는 전에 다녔던 직장에서도 오픈 소스 제품을 전업으로 만들긴 했지만,
내가 시작한 프로젝트가 아니었다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>Ghost의 Fedify 자금 지원</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/07/ghost-funds-fedify/"
         
         />
       
         <id>https://writings.hongminhee.org/2024/07/ghost-funds-fedify/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/07/ghost-funds-fedify/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/07/ghost-funds-fedify/index.ja.html"
         
           hreflang="ja"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/07/ghost-funds-fedify/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2024/07/ghost-funds-fedify/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2024-07-03T02:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;Ghost의 Fedify 자금 지원&lt;/h1&gt;
&lt;p&gt;온통 안 좋은 소식뿐이던 이 블로그에도 드디어 좋은 소식을 전할 수 있게 됐다.
올해 봄부터 취미로 하던 오픈 소스 프로젝트인 &lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;가 글로벌 블로그
플랫폼인 &lt;a href=&quot;https://ghost.org/&quot;&gt;Ghost&lt;/a&gt;로부터 자금 지원을 받게 된 것이다.&lt;/p&gt;
&lt;h2&gt;Fedify란?&lt;/h2&gt;
&lt;p&gt;먼저 Fedify가 어떤 프로젝트인지 소개하고자 한다.&lt;/p&gt;
&lt;p&gt;&lt;dfn&gt;&lt;a href=&quot;https://fedify.dev/&quot;&gt;Fedify&lt;/a&gt;&lt;/dfn&gt;는 &lt;a href=&quot;https://www.w3.org/TR/activitypub/&quot;&gt;ActivityPub&lt;/a&gt; 프로토콜을 구현하는 서버 프레임워크이다.
오픈 소스 프로젝트인 &lt;a href=&quot;https://joinmastodon.org/ko&quot;&gt;Mastodon&lt;/a&gt;이나 Meta의 &lt;a href=&quot;https://www.threads.net/&quot;&gt;Threads&lt;/a&gt; 같은 서로 다른 소셜 미디어
서비스들이 한데 모여서 소통할 수 있는 기술적 배경이 바로
&lt;dfn&gt;&lt;a href=&quot;https://www.w3.org/TR/activitypub/&quot;&gt;ActivityPub&lt;/a&gt;&lt;/dfn&gt; 프로토콜이다. 이렇게 모인 소셜 미디어의 연합을
&lt;dfn&gt;&lt;a href=&quot;https://ko.wikipedia.org/wiki/%ED%8E%98%EB%94%94%EB%B2%84%EC%8A%A4&quot;&gt;페디버스&lt;/a&gt;&lt;/dfn&gt;(fediverse)라고 하며, 한국어권에서는 흔히
&lt;dfn&gt;연합우주&lt;/dfn&gt;라고 부른다.&lt;/p&gt;
&lt;p&gt;ActivityPub은 얼핏 보면 간단한 프로토콜 같지만, 실제로 다른 서비스들과의
상호운용성을 제대로 구현하고자 하면 생각보다 까다로운 점이 많다.
그래서 그런 까다로운 부분을 알아서 처리해주는 프레임워크의 존재를 바라게 되었고,
마땅한 것이 없어서 직접 만들게 된 것이다.&lt;/p&gt;
&lt;h2&gt;Ghost의 Fedify 채용&lt;/h2&gt;
&lt;p&gt;두 달 전까지만 해도 Fedify는 여가 시간에 만들어지는 취미 프로젝트에나 쓰는
장난감에 가까웠다. 그럼에도 작은 이용자 커뮤니티가 있었는데, 어느날 그 중
누군가가 &lt;a href=&quot;https://activitypub.ghost.org/&quot;&gt;Ghost가 ActivityPub을 구현한다&lt;/a&gt;는 소식을 전하면서 Ghost도
TypeScript로 만들어진 것 같으니 Ghost 팀에 Fedify를 세일즈해 볼 것을 권했다.
처음에는 과연 세일즈가 될까 싶어 주저했는데,
세일즈 할 것을 내게 권한 분께서 Ghost 팀에 메일까지 직접 보내셨다는 말을
듣고 용기를 얻어 나도 Ghost 팀에 연락을 하게 되었다.&lt;/p&gt;
&lt;p&gt;그런데 웬걸, Ghost 팀이 &lt;a href=&quot;https://activitypub.ghost.org/day4/&quot;&gt;Fedify를 긍정적으로 검토&lt;/a&gt;하는 것이 아닌가?
그러더니 정말로 &lt;a href=&quot;https://activitypub.ghost.org/day-4/&quot;&gt;Fedify를 본격적으로 이용하기로 결정했다&lt;/a&gt;고 알려왔다.
놀라운 일이었고, 나는 그것만으로도 너무나 기뻤다!&lt;/p&gt;
&lt;h2&gt;자금 지원&lt;/h2&gt;
&lt;p&gt;그 뒤로 나는 Ghost 팀, 특히 Ghost에 ActivityPub을 구현하는 팀원들과 긴밀히
연락하게 되었는데, 얼마 지나지 않아 Ghost 팀으로부터 Fedify 프로젝트에 자금
지원을 할테니 Ghost 팀에서 Fedify에 추가되기를 원하는 기능들을 구현해줄 수
있겠냐는 제안이 왔다. 마침 한창 재취업을 위해 이 회사 저 회사에 이력서를 넣고
있던 내게는 꽤나 고민이 되는 이야기였다.&lt;/p&gt;
&lt;p&gt;우선 약 보름 정도를 같이 일하기로 하고 작은 자금 지원을 받았다.
그리고 취업 준비를 하는 한편으로 Fedify 작업을 하게 되었는데 생각보다도
몰입도가 높고 즐겁게 일할 수 있었다. 결국 나는 좀 더 길게 자금 지원이
가능하다면 전업으로 Fedify 일을 할 수 있겠다는 의사를 밝혔고,
Ghost 팀에서도 긍정적인 답변을 받을 수 있었다.&lt;/p&gt;
&lt;p&gt;그래서 앞으로 꽤 오랫동안 자금 지원을 받으며 Fedify 작업을 할 수 있게 되었다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;
이전 직장에서도 전업으로 오픈 소스 프로젝트를 하긴 했지만,
이렇게 내가 시작한 오픈 소스 프로젝트에 자금 지원을 받는 방식으로 일하는
것은 처음이라 앞으로가 기대가 된다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;그리고 구직 활동을 하며 합격한 회사들에는 아쉽지만 (정말로 아쉬운
회사들이 몇 있었다) 입사 제의를 고사했다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>2023년을 마무리하며</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2023/12/ending-year-2023/"
         
         />
       
         <id>https://writings.hongminhee.org/2023/12/ending-year-2023/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2023/12/ending-year-2023/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2023/12/ending-year-2023/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2023-12-27T08:00:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;2023년을 마무리하며&lt;/h1&gt;
&lt;p&gt;작년말에도 비슷한 얘기를 했는데 올해에도 또 블로그에 쓴 글이 없다.
그래서 뭐라도 써야겠다 싶어서 올해 내게 있었던 큰 일들을 적어볼까 한다.&lt;/p&gt;
&lt;h2&gt;부친 별세&lt;/h2&gt;
&lt;p&gt;지난해에는 강아지 밍키와 어머니를 떠나 보냈는데,
올해 9월에는 아버지마저 돌아가셨다. 추석 연휴 직전이었다.
직접적인 사인은 췌장암이었지만,
어머니가 떠난 뒤 스트레스를 많이 받으셨던 탓이 아닐까 짐작만 할 뿐이다.&lt;/p&gt;
&lt;p&gt;몇 개월간의 간병을 통해 죽음은 인간의 존엄을 위한 하나의 선택이 될 수 있다는
생각을 하게 됐다. 아버지는 격통에 시달리느라 몇 달을 내리 죽음만을 갈구하셨는데,
옆에서 해드릴 수 있는 것은 없었다. 임종의 순간, 나는 되려 안도할 정도였다.
이제야 겨우 편히 쉬시겠구나 해서.&lt;/p&gt;
&lt;p&gt;우울증 약을 먹어서일까, 다행히 어머니 때만큼 힘들지는 않았다.
하지만 약간의 무기력은 여전하다.&lt;/p&gt;
&lt;h2&gt;퇴사&lt;/h2&gt;
&lt;p&gt;아버지가 췌장암 진단을 받은 즉시 휴직을 했다. 동생과 함께 간병을 했는데 일을
병행하기에는 역부족이었다. 다행히 회사에서 가족 돌봄 휴직 제도가 있어서 최장
3개월까지 간병에 전념할 수 있었지만, 아버지의 투병이 길어지면서 회사에 폐를
끼치고 싶지 않은 마음 반, 어차피 돌아가도 한동안 일을 할 수 있을 마음 상태가
아닐 거라는 생각 반으로 퇴사를 결심했다.&lt;/p&gt;
&lt;p&gt;현재는 아버지의 사후 신변 정리를 하느라 다시 일을 알아보진 않고 있다.
실은 다시 일을 할 수 있을까 걱정이 되기도 한다.&lt;/p&gt;
&lt;h2&gt;유산 정리&lt;/h2&gt;
&lt;p&gt;아버지는 온실 하우스와 농사 짓던 땅, 그리고 그 옆에 있는 집,
그리고 이 모든 것을 담보로 걸어둔 대출을 남기고 떠나셨는데,
요즘엔 이것들을 정리하느라 시간을 보내고 있다.
아버지가 어머니와 함께 살던 집은 나와 동생도 독립하기 전까지 오래 지냈던
곳이라 팔아 넘기고 싶지 않기 때문에 부단히 애를 쓰고 있다.
그 집에는 동생이 들어와 살기로 했고, 아마도 나와 동생의 상처가 아물 때까지는
자리를 지킬 것 같다.&lt;/p&gt;
&lt;p&gt;땅을 일부 팔아 대출을 갚으려고 하는데,
젊은 형제 둘만 남았다고 벌써부터 벌레가 꼬여 골치가 아프다.
인간 불신이 생길 지경이다.&lt;/p&gt;
&lt;h2&gt;2024년을 앞두며&lt;/h2&gt;
&lt;p&gt;아주 솔직히 적자면 나는 살면서 가장 힘든 한때를 보내고 있다.
틈틈히 시간을 내서 사이드 프로젝트를 해보고 있지만 능률도 많이 떨어졌고 무기력
탓에 애초에 만들고 싶은 것도 떠오르지 않는다. 살면서 언제나 만들고 싶은 게
너무 많아서 시간과 기력이 부족한 게 한이었던 터라, 스스로의 이런 상태에 적잖게
당황하고 있다. 이 모든 것들을 극복(克復)하는 것이 내년의 과제일 것이다.&lt;/p&gt;
</content>
    </entry>
  
    <entry>
     <title>2022년을 마무리하며</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/12/ending-year-2022/"
         
         />
       
         <id>https://writings.hongminhee.org/2022/12/ending-year-2022/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/12/ending-year-2022/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/12/ending-year-2022/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2022-12-30T18:37:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;2022년을 마무리하며&lt;/h1&gt;
&lt;p&gt;기껏 블로그 만들어 놓고 올 한 해 글을 딱 두 편만 쓰는 것, 게다가 그 중 하나가
마지막 날에야 부랴부랴 쓰는 이런 글이라는 것이 참 한심하다. 그럼에도 2022년만은
꼭 기록해 둬야겠다는 생각이 올 해 내내 들었다. 내게 많은 일이 일어났던 탓이다.&lt;/p&gt;
&lt;h2&gt;보낸 가족&lt;/h2&gt;
&lt;p&gt;4월에 20년 가까이 함께 지냈던 강아지 밍키를 떠나 보냈다.
하필이면 아버지 생신에. 밍키가 가장 따르던 게 아버지고,
밍키를 데려온 것도 가장 아끼던 것도 아버지인데.
어쩌다 보니 내가 병원에 가서 밍키의 시구를 받게 되었다.
그대로 집에 데려와 하루 동안 침대에 함께 누운 채 보고 또 보며
울기도 많이 울었다. 아무리 봐도 편히 잠든 것 같고 금방이라도 벌떡
일어날 수 있을 것 같았다. 개가 20년 살았으면 장수한 축이라 하는데,
그런 건 아무래도 좋고 다시 살아 돌아왔으면 좋겠다는 생각뿐이다.&lt;/p&gt;
&lt;p&gt;그리고 딱 한 달 지나 5월에 어머니가 암으로 고생하신 끝에 돌아가셨다.
밍키가 떠나고 놀라서 그러셨을까, 그 즈음부터 건강이 빠르게 안 좋아지셨다.
안 그래도 몇 달 안에 고비가 올 거라는 느낌이 들어 전보다 자주 찾아 뵙긴
했지만, 그렇게 일찍 돌아가실 줄은 정말 몰랐다.
아침에 아버지 연락을 급히 받아 본가에 가보니 어머니는 극심한 괴로움을
줄이기 위해 방문 간호사가 모르핀을 여러 차례 투여한 뒤였고,
섬망으로 가족 모두를 알아보지 못하고 계셨다. 그나마 다행이라면 가족 모두가
임종을 지킬 수 있었던 것, 그리고 마침내 숨을 쉬기 어려워 할 무렵 다함께 울며
어머닐 부둥켜 안고 사랑하고 미안했다고 한 말들을 정말 들으신 듯,
우리가 그 말을 하니 우리 쪽으로 고개를 돌려 잠시 바라본 채 잠드셨다는 것이다.&lt;/p&gt;
&lt;p&gt;한 달 사이에 가족이 둘이나 떠나니 정신을 차리기 힘들었다.
장례를 마치고 일터에 복귀할 땐 어른스럽게 개인사를 분리하겠노라
생각했지만 오산이었다. 얼마 못 버티고 한 달쯤 휴직을 하게 되었다.
실은 아직도 이전처럼 일을 해내지 못하는 걸 느낀다.
눈에 띄게 부진한데도 아무 말 없이 내가 했어야 하는 일도 대신 해주는
팀 동료들에게 한 해 동안 정말 미안하고 고마웠던 것 같다.&lt;/p&gt;
&lt;p&gt;아버지는 어머니와 함께 사셨고 동생도 나도 서로 독립해서 살고 있었기에,
이제는 모두가 뿔뿔히 흩어지게 되었다.
아버지나 동생이 혼자서 외롭지 않을까 걱정되어 자주 봐야겠다는 생각이 많이 들고,
그래서 실제로 어머니 돌아가시고 얼마 안 됐을 때는 두 집 살이처럼 지냈던 것 같다.
바빠지며 다시 자주 못 보게 되었는데 마음 한 켠에서 신경이 계속 쓰이는 것도
요즘의 고민이다.&lt;/p&gt;
&lt;h2&gt;맞은 가족&lt;/h2&gt;
&lt;p&gt;슬픈 일만 있던 것은 아니다. 아주 기쁜 일도 있었다.
연인이었던 리사와 결혼을 했다. 혼인 신고는 바빠서 아직 하지 못했다.
사귀기 시작한 날에 맞춰서 혼인 신고도 하자는 얘기를 했다.
둘 다 극히 내향적이며 부끄러움도 많이 타기 때문에 아는 사람을 모두 불러서
잔치의 주인공까지 되어야 하는 결혼식은 무리였다. 결혼식은 안 하기로 했고,
우리에게는 그게 너무 당연했다. 대신 가까운 친척들을 만나고 다녔고,
사진작가인 리사의 친구와 내 오랜 친구 둘을 집에 불러 집과 동네에서 조촐하지만
예쁜 결혼사진을 찍었다. 살면서 사진촬영이 이렇게 재밌던 적이 없었던 것 같다.
올해 가장 즐거웠던 하루이다. 그게 어쩌면 우리에겐 결혼식이었던 것 같다.&lt;/p&gt;
&lt;p&gt;너무 힘든 한 해였지만 리사에게 기대면서 버틸 수 있었다.
리사도 사랑하는 토끼 둘을 떠나 보낸 적 있어서,
내가 밍키를 보내며 후회가 남지 않도록 많은 배려를 해줬다.
밍키가 오래 살아서 언제 떠날지 모르겠다는 말에 밍키와 꼭 닮은
모헤어 인형&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;을 만들어 준 게 작년 생일이었다.
밍키를 화장할 곳도 리사가 찾아 줬고, 밍키의 유골을 녹여 만든 돌들을
밍키 인형에 담아 주기도 했다. 유품 정리도 대신 해 줬다.&lt;/p&gt;
&lt;p&gt;어머니 장례식 때도 사흘 내내 우리 가족과 함께 있어 주며 모든 것을 도왔다.
우습게도 양가 부모님이 처음으로 만난 자리도 장례식장이 되었다.
어머니가 거동이 힘들 정도로 몸이 안 좋아지신 탓에 양가 인사를
줄곧 미뤘기 때문이다. 그래도 리사는 어머니를 실제로도 영상 통화로도
여러 차례 뵌 적 있고, 어머니가 리사를 마음에 들어 하셨던 것 같다.
집에서는 정말 자주 울었는데, 그 때마다 리사가 날 많이 안아 주고
같이 울어 주었다. 장인어른과 장모님&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;께서도 나와 우리 아버지를
많이 걱정해 주시고, 내게 많이 마음을 써 주셨다.&lt;/p&gt;
&lt;h2&gt;삶의 무게 중심&lt;/h2&gt;
&lt;p&gt;실은 어머니가 돌아가시니 왜 살아야 하는지, 살면서 무얼 좇아야 하는지 생각할
일이 많아졌다. 일이나 실력 같은 것들은 결국 삶을 영위하는 방편일 뿐,
당장 내일모레 죽는다 치면 다 무슨 소용인지. 다들 하는 진부한 얘기인데도
그 진부한 생각이 지난 몇 달 동안 마음에 가득 찼던지…&lt;/p&gt;
&lt;p&gt;얼마 뒤 죽는다면 뭐가 가장 후회될까 생각하기도 했다.
아마도 소중한 사람들과 조금이라도 더 얘기하지 못한 것,
그들이 내게 얼마나 소중한지 그들에게 얘기하지 못한 게 아쉽고 후회될 것 같았다.
어머니가 떠난 뒤 내게 남은 후회가 온통 그런 것이었기 때문이다.
솔직히 호강 못 시켜드리고 자랑 할 만한 아들이 되지 못한 것은 그다지
후회가 안 됐던 것 같다. 자주 못 뵙고, 얘기 더 못 나누고,
고마움이나 미안함 같은 속마음을 제대로 말 못하다가 떠나시기 직전에야
급히 얘기했던 게 후회되어 자주 울었다. 어머니 뿐만 다른 사람들과도
비슷할 것이다. 나도 언제 떠날지 모르지만 그들도 언제 떠날지 모른다는 생각도
자주 했다. 말로 하기 부끄러우면 엽서라도 쓰고, 자주 못 만나면 전화라도
많이 걸자는 다짐을 했다.&lt;/p&gt;
&lt;p&gt;안 그래도 내향적이었는데 코로나19 탓에 지난 몇 해 더욱 두문불출했었다.
조금씩 사람들을 다시 만나고 다녔던 것 같다. 솔직히 마음이 무거웠기 때문에
사람들을 당장 보고 싶었던 건 아니었는데, 자주 만나두지 않으면 또 후회를
할 것 같다는 불안이 생겼다. 만나면 사진도 찍고 비디오도 찍었다.
생전 어머니 사진이나 비디오가 많지 않아 너무 후회스러웠기에 앞으로 만나는
사람들은 뭐라도 좀 찍어야겠다 싶었다. 돌이켜 보면 한두 달은 살짝 강박도
생겼던 것 같다. 그 즈음에는 만나서 얘기하는 것을 죄다 녹화하느라 보름에
수백 기가바이트씩 쌓였다.&lt;/p&gt;
&lt;p&gt;한편으로는 내가 평생 즐거워 하던 코딩을 많이 줄였다. 줄이려고 한 건 아닌데
손에 거의 안 잡혀서 좀처럼 집중할 수 없었다. 취미로 짜는 코드도 그랬으니
일로 하는 건 오죽했으랴. 휴직을 한 달 하긴 했지만 마음 같아서는 휴직을 반년쯤
하고 싶었다. 실제로 반년 넘게 생산성이 바닥이었다. 근본적으로는 내가 짜는
코드가 그렇게 쓸모가 있지 않다는 자각이 자주 들었던 것 같다.
그러니까, 코딩을 처음 해 본 십대 때부터 작년까지는 내가 기껏 만든 코드가
실은 그다지 쓸모가 있지 않다는 객관적인 판단을 코딩을 한참 하고 있는
동안에는 하지 못했다. 몰두할 수 있었던 것이다.
다 만들고 나서 시간이 좀 지난 뒤에 열정이 점차 식으면서,
그제서야 비로소 내가 만든 코드를 쓸 데가 매우 한정적이라는 것을
깨닫는 식이었다. 그런데 요즘에는 그런 생각이 코딩하는 동안 매일 드니
코딩할 기운이 안 난다. 그리고 내가 만든 코드가 어떤 사람들에게
꽤 유용할 수 있다고 하더라도, 그 사람들이 내 코드를 활용해서하고 싶어하는
일들이 크게 의미가 있지는 않을 수 있겠다는 생각까지 들 때도 있어서,
그런 마음도 코딩할 동기를 많이 억제하는 것 같다.&lt;/p&gt;
&lt;p&gt;종합적으로 보면 삶에서 장기 투자에 가까운 것들의 가치를 낮게 보게된 것 같다.
코딩도 현재를 써서 미래를 편하게 하는 수단이니 할 마음이 같이 준 게 아닐까.
그런데 현재의 나는 이러한 새로운 태도가 그저 비관이라고는 생각하지 않고,
오히려 어떤 측면에서는 더 현명해지고 있다는 느낌도 받는다.&lt;/p&gt;
&lt;h2&gt;2023년은 어떻게 살까&lt;/h2&gt;
&lt;p&gt;올해가 내 인생의 큰 전환점이 된 것은 분명하다.
이미 많은 가치 판단이 옛날과 크게 달라졌다.
다만 살던대로 살려고 하는 관성이 문제이다.
나이도 들면서 체력이 떨어지니 마음도 바람과는 다르게 많이 미끄러진다.
어제 했던 다짐도 자고 일어나면 도통 실행에 옮길 수 없는 것이다.
그래서 신년에는 어떻게든 체력을 늘리려고 한다.
그게 되어야 다른 내 바람도 실행할 수 있을 것 같다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;사람 모양이 아닌 털 장난감도 인형이라고 부르는 게 조금 거북하다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;리사는 이런 호칭들을 싫어하지만… 글에서 제삼 인칭으로 부를 말이 궁하다. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>탈중앙 게임, 그리고 블록체인과 NFT</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/1/decentralized-game/"
         
         />
       
         <id>https://writings.hongminhee.org/2022/1/decentralized-game/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/1/decentralized-game/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2022/1/decentralized-game/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2022-01-02T07:50:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;탈중앙 게임, 그리고 블록체인과 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt;&lt;/h1&gt;
&lt;p&gt;2018년 여름 5년 넘게 일했던 스포카에서 나와 플라네타리움으로 옮긴 이래,
흔히 &lt;q&gt;블록체인 게임&lt;/q&gt;이라고 불리는 탈중앙 게임을 만드는 프로젝트에 몸담은 지
벌써 5년째를 맞이하게 됐다.&lt;/p&gt;
&lt;p&gt;그 동안 여러 이슈를 마주하며 생각이 달라진 부분도 있지만,
탈중앙 게임의 가치에 대해서는 크게 생각이 바뀌진 않고,
오히려 정교해진 것 같다.  그러나 같은 비전 아래 나아가는 팀 안에서도
저마다 크고 작은 생각의 차이가 있기 마련이고,
나도 팀과는 독자적으로 나름의 생각을 글로 다듬어 보려 한다.&lt;/p&gt;
&lt;p&gt;이하의 모든 졸견은 내 멋대로의 생각일 뿐,
내가 속한 회사 및 동료들의 입장과 독립적라는 점을 밝혀둔다.&lt;/p&gt;
&lt;h2&gt;온라인 멀티플레이어 게임의 중앙집중 거버넌스 문제&lt;/h2&gt;
&lt;p&gt;개인적으로는 게임을 탈중앙화할 필요가 없을 때가 많다고 보지만,
그럼에도 몇몇 장르의 온라인 멀티플레이어 게임에서 가치가 있다고 생각하는데,
왜냐하면 온라인 게임 운영사는 일반적으로 게임 플레이어와 이해가 불일치하거나
대립하기 때문이다.  플레이어들이 규탄하는 게임 운영사의 횡포는 다양하다.
심한 과금 유도, 플레이어들의 바람과는 상반되는 업데이트 방향,
고시된 아이템 획득 확률이 실제 구현과 다른 것 같다는 의혹, 갑작스러운 &lt;abbr title=&quot;서비스 終了&quot;&gt;섭종&lt;/abbr&gt; 등.&lt;/p&gt;
&lt;p&gt;플레이어들이 겪는 이러한 어려움을 설명하는 몇 가지 관점이 있을 수 있는데,
그 중 하나는 온라인 게임 서비스 각각이 그 안에서는 불공정 독점 시장을
형성한다는 인식이다.  어째서 플레이어들은 사실상 꽝뿐인 아이템 팩,
즉 저품질의 재화를 그 가격에 강매하게 될까?
다른 품질의 아이템 팩을 다른 가격에 파는 사람이 없고,
오직 게임 운영사만이 그 판매권을 독점하고 있기 때문이다.
이는 애플의 앱 스토어가 독점적 지위로 여러 불합리한 거래를 소비자에게 강요하는
것과 비슷하다.  온라인 게임 첫 세대부터 운영사의 그러한 독점을 우리가 승인해
왔다 보니 그런 지위를 내려놓으라는 운영사에 향한 요구가 생소할 뿐이다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;게다가 많은 시간과 돈을 써서 얻은 게임 내의 모든 것은 운영사가 자의적으로
서비스를 그만두면 그 즉시 물거품이 된다.
싱글 플레이어 게임이라면 남이 맘대로 내 세이브 파일과 게임 패키지를 통째로
없앨 수도 있는 리스크가 있는 것이다.
멀티플레이어 온라인 게임은 시간만 쓰는 게 아니라 돈도 쓰는 경우가 많은데다,
큰 회사의 대작이 아니라면 서비스가 5년 넘게 운영되는 경우가 흔치 않으므로
더 리스크가 무겁다.&lt;/p&gt;
&lt;p&gt;위와 같은 점들을 따져보면 온라인 멀티플레이어 게임들은 싱글 플레이어 게임들에
비해 훨씬 소비자 보호 수준이 떨어진다는 문제의식에 이른다.
이런 차이는 싱글 플레이어 게임은 제작사 손을 떠나 소비자가 구매한 이후로는
게임을 즐기는 사람이 스스로의 기기에서 실행하는 반면, 멀티플레이어 게임은
게임을 즐기는 것과 운영 및 실행하는 것이 다른 주체에 의해 이뤄지고
그 둘 사이의 이해득실이 서로 간섭하기에 생기는 게 아닌가 싶다.&lt;/p&gt;
&lt;p&gt;이러한 시각에서, 온라인 멀티플레이어 게임의 운영 거버넌스를 탈중앙화하여
위와 같은 문제들을 완화할 수 있을 거라는 기대를 갖고 있다.&lt;/p&gt;
&lt;h2&gt;탈중앙 게임의 구현 수단으로서의 블록체인&lt;/h2&gt;
&lt;p&gt;현재 &lt;q&gt;탈중앙 게임&lt;/q&gt;과 &lt;q&gt;블록체인 게임&lt;/q&gt;은 거의 같은 말로 쓰이고 있다.
요즘에는 &lt;q&gt;&lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 게임&lt;/q&gt;이라는 말로 더 많이 불리는 것 같기도 하다.
그렇지만 사견으로는 이 말들을 구별해서 쓰고 싶고,
적어도 이 글에서는 그러고자 한다.&lt;/p&gt;
&lt;p&gt;&lt;q&gt;탈중앙 게임&lt;/q&gt;이라는 것은 멀티플레이어 게임의 거버넌스에 관한 말로,
이는 여러 층위에서 다양한 방식으로 이뤄질 수 있다.
따라서 탈중앙 게임과 중앙집중 게임 사이에 뚜렷한 구분선이 있다기 보다는
정도의 문제에 가까울 것이다.
이를테면 게임의 클라이언트와 서버를 모두 오픈 소스로 배포한다면,
그것만으로 상당한 수준의 탈중앙화를 이룰 수 있다.
게임이 마음에 안 들면 마음에 들게 고쳐서 재배포할 수 있기 때문이다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;그렇지만 게임의 소프트웨어 부분뿐만 아니라,
운영되는 게임 내 세계까지 탈중앙화하고 싶을 수 있다.
같은 게임을 서비스하는 주체가 여럿 있을 수 있다고 해도,
내가 고른 운영 주체가 멋대로 데이터베이스에 손을 대거나 금방 서비스를
종료하지 않을 거라는 보장이 없기 때문이다.
이런 요구는 오픈 소스만으로는 달성할 수 없는데, 이를 위해 블록체인이 쓰인다.
(또는, 그런 명목으로 블록체인을 도입한다.)&lt;/p&gt;
&lt;p&gt;&lt;q&gt;블록체인 게임&lt;/q&gt;은 게임의 구현 세부사항으로,
그 자체로는 플레이어 입장에서 좀더 가치 중립적이다.
현재 게임을 블록체인으로 만들었을 때의 이점으로는
주로 둘 정도를 꼽을 수 있겠는데, 하나는 앞서 말한 운영의 탈중앙화이고,
다른 하나는 상대적으로 초기 개발비를 모금하기 쉽다는 것이다.
모금에 관해서는 나중에 따로 다루기로 하고,
그렇다면 블록체인은 구체적으로 어떻게 운영을 탈중앙화한다는 것일까?&lt;/p&gt;
&lt;p&gt;이를 드러내려면 먼저 블록체인이 &lt;a href=&quot;https://ko.wikipedia.org/wiki/P2P&quot;&gt;&lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크&lt;/a&gt;를 전제한다는
점을 짚고 넘어가야 할 듯하다.  블록체인의 탈중앙 거버넌스는 기본적으로
&lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크의 탈중앙 거버넌스에 바탕하기 때문이다.
&lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크가 탈중앙화되어 있다는 것은,
현실 세계에서 가장 널리 쓰이는 &lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크인 &lt;a href=&quot;https://www.bittorrent.org/&quot;&gt;비트토렌트&lt;/a&gt;를
어느 한 주체가 임의로 멈추게 할 수 없다는 것으로 보여줄 수 있다.
비트토렌트 네트워크는 한두 주체의 담합으로 멈출 수 없을 뿐만 아니라,
언젠가 누구도 쓰지 않게 되어 정말로 멈추더라도 이후 언제든 다시 누군가
두 사람이라도 비트토렌트 소프트웨어를 켜면 다시 굴러가게 할 수 있다.&lt;/p&gt;
&lt;p&gt;그렇다면 멀티플레이어 게임을 P2P로 구현하는 것으로 탈중앙화를 꾀하면 어떨까?
실은 &lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 멀티플레이어 게임은 이미 오래 전부터 우리에게 익숙하다.
이를테면 &lt;cite&gt;StarCraft&lt;/cite&gt;의 멀티플레이 수단으로는 (제작운영사인 Blizzard의
독점 중앙집중 서비스인 Battle.net 말고도) IPX를 쓸 수 있었고,
실제로 많이 썼다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn3&quot; id=&quot;fnref3&quot;&gt;3&lt;/a&gt;&lt;/sup&gt;  그렇지만 이런 식의 &lt;abbr title=&quot;internetwork packet exchange&quot;&gt;IPX&lt;/abbr&gt; 멀티플레이는
대체로 방을 연 사람이 서버 역할을 하게 되어 있어서,
나머지가 그 방에 들어가는 식으로 주객의 구분이 존재했다.
많은 &lt;abbr title=&quot;internetwork packet exchange&quot;&gt;IPX&lt;/abbr&gt; 멀티플레이는 단 둘이서 즐길 때만 P2P처럼 동작했다.
게다가 모든 노드가 정직하고 소프트웨어적 조작이 없다고 가정하기 때문에
맵핵 등의 부정행위에 취약했다.
이런 취약성은 부정행위의 효과가 30분 남짓의 한 판 안에서만 작용하는 &lt;cite&gt;StarCraft&lt;/cite&gt;
같은 장르의 게임에서는 무시해도 그만이지만,
&lt;cite&gt;Ultima Online&lt;/cite&gt;처럼 판의 단락 없이 큰 단일 세계가 계속 이어지는 종류의
게임에서는 그런 부정행위를 못 본 척 할 수는 없다.&lt;/p&gt;
&lt;p&gt;그러므로 세계가 계속되는 종류의 멀티플레이어 게임을 비트토렌트처럼 P2P로
구현하면 탈중앙화는 이룰 수 있지만 보안이 취약해지게 된다.
그런 게임에 한해 중앙에서 개입하는 운영 주체를 도입하지 않고서
보안을 확보하는 수단이 블록체인이라고 할 수 있다.
거꾸로 얘기하면, 탈중앙 거버넌스와 그런 수준의 보안이 함께 필요한
게임이 아니라면 굳이 블록체인까지 도입하지 않아도 된다는 뜻이기도 하다.
탈중앙화만 필요하다면 &lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크 위에서 돌게만 해도 달성할 수 있고,
혹은 부정행위만 막으면 된다면 신용할 특별 지위의 중간자를 두는 것으로도
훨씬 쉽게 막을 수 있기 때문이다.
게다가 &lt;cite&gt;StarCraft&lt;/cite&gt;나 &lt;cite&gt;Quake&lt;/cite&gt;처럼 플레이어의 조작 숙련도가 승패에 주요한
게임은 어차피 입력기기 수준에서 부정행위가 가능하기 때문에&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn4&quot; id=&quot;fnref4&quot;&gt;4&lt;/a&gt;&lt;/sup&gt;
블록체인으로 보안이 크게 나아지지도 않는다.&lt;/p&gt;
&lt;p&gt;블록체인이 기술적으로 보장하는 것은 게임에서도 여전하다.
블록체인 네트워크의 노드가 느슨한 시간적 오차 내에서
같은 상태(데이터라고 말해도 좋다)를 가질 수 있게 하고,
상태 전이(데이터 갱신이라고 말해도 좋다)가 모든 노드에게 일관되게 적용되는
규칙과 권한 안에서만 (다시 말해 반달리즘 걱정 없이) 이뤄지도록 하며,
이 모든 것이 어떤 특별한 지위에 있는 주체 없이 돌아가도록 해준다.
그러니까 블록체인의 이러한 성질은 휘발성 데이터나 각자의 사적 데이터가 아니라
공공의 영속 데이터를 주로 다루는 소프트웨어에서나 의미가 있는데다,
그 소프트웨어가 반드시 탈중앙 거버넌스를 갖춰야 하는 경우가 아니라면
오남용일 뿐이다.  그리고 비디오 게임도 소프트웨어이므로 같은 판단을 할 수 있다.&lt;/p&gt;
&lt;h2&gt;무분별한 블록체인 도입&lt;/h2&gt;
&lt;p&gt;그러나 이른바 &lt;q&gt;블록체인 게임&lt;/q&gt; 업계에 몸담고 있으면 블록체인을 도입할 하등의
이유가 없는 곳에 블록체인을 굳이 어거지로 끼워넣는 사례를 자주 듣고 보게 된다.
솔직히 말해 그런 사례가 그렇지 않은 사례보다 훨씬 많을 정도인 마당에,
블록체인 업계에 대한 불신과 폰지 사기가 아니냐는 의심에는 아무리 억울해도
어쩔 수가 없다고 느낀다.&lt;/p&gt;
&lt;p&gt;블록체인이 쓸모가 있는 게임이라고 해도, 정작 도입을 제대로 하지 않고서
&lt;q&gt;블록체인 게임&lt;/q&gt;이라는 레테르만 붙이는 프로젝트도 정말 많다.
그 중 대표적인 것이 요즘 흔히 &lt;q&gt;&lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 게임&lt;/q&gt;이라고 불리는 것들이다.&lt;/p&gt;
&lt;p&gt;이름만 놓고 생각하면 &lt;q&gt;&lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 게임&lt;/q&gt;은 게임 내에서 쓰일 수 있는 아이템들을
블록체인상의 NFT로 발행하면 그렇게 부를 수 있는 것 같지만,
실상을 살펴보면 의외로 게임에서 블록체인을 아예 쓰지 않고 아이템만 블록체인
NFT로 발행하는 경우가 많다.  게임 운영이 여전히 사기업에 의해 독점적으로
이뤄지고 있는데 아이템만 블록체인 NFT로 다루면 어떤 이점이 있는 것일까?&lt;/p&gt;
&lt;p&gt;가장 자주 꼽히는 것은 바로 아이템을 게임 밖 시장에서 거래할 수 있다는 것이다.
그렇지만 아무래도 도통 모르겠는 것은 그게 종래의 &lt;a href=&quot;https://itembay.com/&quot;&gt;아이템베이&lt;/a&gt;와 무엇이
다르냐는 것이다.  운영사가 직접 수수료 장사를 할 수 있다는 점(이건
플레이어에게는 딱히 도움되진 않는다)이나 훨씬 높은 가격에서 거래가 형성된다는
점이 다른 것일까?  그냥 아이템 거래소를 &lt;abbr title=&quot;relational database management system&quot;&gt;RDBMS&lt;/abbr&gt; 기반의 웹 서비스로
구현하면 안 되는 것일까?&lt;/p&gt;
&lt;p&gt;그러한 의문에 대한 가장 흔한 답은, NFT는 블록체인 위에 기록되므로 변조나
복제가 불가능할 뿐만 아니라 사실상 영속적이라는 정당화다.
이는 일견 이치에 닿아 있는 이야기지만, 어디까지나 발행된 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 자체에만
적용되는 이야기여서, NFT가 가리키는 실제 게임 내 아이템에까지 보장되는 성질은
아니라는 허점도 함께 짚고 넘어가야 한다.  세간에 NFT라 불리는 것들이 그렇지만,
&lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 그 자체는 일종의 영수증 내지는 증권처럼 NFT가 가리키는 대상물과는
따로 떨어져 있다.  독점 운영사가 발급한 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 아이템은 게임이 섭종됐을 때
어디에 쓸 것인가?  섭종까지 가지 않더라도, NFT가 가리키는 아이템은 어차피
운영사의 게임 서버 데이터베이스에 들어있는데, 그 데이터베이스를 조작하지
않으라는 보장은 어떻게 할 것인가?  우리는 그 운영사가 그러지 않을 것이라고
신뢰해야 하는데, 그 시점에서 아이템을 NFT로 발행한 취지는 퇴색되어 버린다.
두부처럼 쉽게 부서지는 것을 사면서,
영수증만 강철로 만들면 그게 무슨 소용인가?&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn5&quot; id=&quot;fnref5&quot;&gt;5&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;독점적으로 운영되는 온라인 게임에서 아이템만 블록체인 NFT로 파는 방식은
블록체인 요소 없이 운영 주체의 서버에 모든 것을 다 두는 종래의 방식에 비해
복잡도와 구현 난도가 잔뜩 올라가기 때문에,
굳이 그렇게 해야만 하는 필요성이 있어야 한다.
졸견으로는, 그러한 합리적 필요성은 적어도 게임 내적으로는 찾을 수 없고,
아마도 &lt;q&gt;&lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt;&lt;/q&gt;나 &lt;q&gt;블록체인&lt;/q&gt; 같은 키워드가 붙어야 프로젝트의 주가가 크게 오르기
때문에 그러한 복잡성을 감수하는 것으로 여겨진다.&lt;/p&gt;
&lt;h2&gt;바람직한 블록체인 게임&lt;/h2&gt;
&lt;p&gt;글이 꽤나 여러 곳을 건들며 돌아다녔는데,
그렇다면 블록체인 게임은 어떠해야 할까?
몇 해 동안 씨름하며 절실하게 느낀 바는,
맨 처음 가장 중요한 것은 블록체인이나 NFT가 필요 없는 게임에
블록체인을 억지로 끼워 넣으려고 하지 말아야 한다는 것이다.
블록체인은 게임을 전적으로 탈중앙화할 동기가 없다면 도입할 까닭이 없다.
탈중앙 게임을 만든다고 해도,
많은 경우는 블록체인 없이 소프트웨어 전반을 오픈 소스로 배포하고 &lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크를
도입하는 것만으로 상당한 수준의 탈중앙화를 이룰 수 있다.
게다가 블록체인은 기술적 제약도 커서, 레이턴시가 짧아야 하는 게임에서는 무리다.
그럼에도 억지스럽게 블록체인을 끼워 넣는 프로젝트는 꾸준히 나타나는데,
이런 의사결정은 대체로 블록체인 기술의 특성과 한계도 모르고 구현 난도도
파악하지 못하는 경영진의 상명하달로 이뤄진다는 심증이 있다.&lt;/p&gt;
&lt;p&gt;블록체인이 유용할 수 있는 게임이라면, 블록체인 도입을 하더라도 종합적 디자인이
블록체인의 용도를 무색케 하지 않도록 꼼꼼히 신경써야 한다.
기껏 게임에 블록체인을 도입해놓고 중요한 컴포넌트를 중앙화하면 (전문 용어로
&lt;a href=&quot;https://en.wikipedia.org/wiki/Blockchain_oracle#Concerns&quot;&gt;오라클&lt;/a&gt;을 두게 되면) 특정 주체를 향한 신뢰에 의존하게 되는데,
전체 시스템에서 신뢰에 의존하는 부분이 조금만 많아져도 탈중앙
거버넌스는 쉽게 취약해진다.
블록체인은 신뢰에 의존하지 않기 위한 몸부림 같은 것인데,
그럴 거면 블록체인이 없는 게 효율적이지 않겠는가?&lt;/p&gt;
&lt;p&gt;블록체인이 제 기능을 하려면 결국 게임 플레이에 필수적인
로직과 데이터는 모두 블록체인 위에 놓여야 한다.
아이템이나 게임 머니만 블록체인에 올리면 게임 자체가 오라클이 되어버린다.
(대부분의 플레이어는 칼이 NFT로 발행됐어도 게임 월드 내에서
휘두룰 수 없다면 쓸모가 없다고 여길 것이다.)
그런데 그러자니 블록체인 게임은 만들기도 성가시고, 성능도 떨어진다.
그렇기에 그런 역기능을 감수하고도 블록체인만의 기능인 탈중앙 거버넌스를
열망하는 프로젝트에서만 블록체인 도입이 의미가 있다.&lt;/p&gt;
&lt;p&gt;블록체인을 원칙대로 게임에 적용하더라도,
게임이 탈중앙 거버넌스와 어울리는지 역시 따져봐야 한다.
현재 블록체인의 가장 큰 기술적 한계는 레이턴시가 종래의
방식과는 비교하기 어려울 만큼 길다는 것이다.
종래의 온라인 게임에서 기술 타당성을 검토할 때 네트워크 레이턴시의
구체적 허용 범위는 밀리초 단위를 넘어가지 않는다.
하지만 블록체인은 빨라봐야 초 단위에서 움직인다.
이를 게임에서 활용하려면 기다림을 게임 디자인의 일부로서 곳곳에 받아들여야
한다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn6&quot; id=&quot;fnref6&quot;&gt;6&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;또, 탈중앙 게임은 업데이트도 간단치 않다.
커뮤니티 피드백을 취사선택하여 닫힌 조직 안에서 발전 방향을 정할 수 있다면
빠르고 좋겠지만, 오픈 소스 프로젝트처럼 결정 자체를 열려있는 커뮤니티
안에서 합의를 통해 결정해야 하기 때문이다.
그래서 많은 블록체인 프로젝트들이 &lt;a href=&quot;https://github.com/bitcoin/bips&quot;&gt;&lt;abbr title=&quot;Bitcoin Improvement Proposals&quot;&gt;BIP&lt;/abbr&gt;&lt;/a&gt;니 &lt;a href=&quot;https://eips.ethereum.org/&quot;&gt;&lt;abbr title=&quot;Ethereum Improvement Propsals&quot;&gt;EIP&lt;/abbr&gt;&lt;/a&gt;니 하는 꽤 복잡한 의사결정
체계를 갖추고 있고, 네트워크 프로토콜을 바꾸는 것은 개헌을 하는 것처럼
어렵고 가끔씩 일어나는 일로 인식된다.
그러다보니 사소한 변경은 모두 블록체인 위에서 데이터와 스마트 콘트랙트를
업데이트하는 것만으로 가능하도록 발전되어 가고 있다.&lt;/p&gt;
&lt;p&gt;따라서 블록체인 게임도 업데이트를 자주 하지 않고도 게임의 신선함을
유지할 수 있도록 설계될 필요가 있다.
게임 로직의 많은 부분을 시간이 지남에 따라 조정될 수 있는 것으로 보기보다는,
웬만하면 영구적이거나 초장기적으로 그리고 전역적으로 작용될 적고 단단한
룰로 구성하고, 그 위에서 노는 플레이어들의 창발적인 상호 작용이
그 자체로 즐길거리가 되어야 한다.
(말은 쉽지만 게임 디자인이 훨씬 어려워진다.)&lt;/p&gt;
&lt;p&gt;나아가 콘텐츠를 주기적 업데이트를 통해 꾸준히 채워줘야 한다면
탈중앙 거버넌스와는 양립하기가 아주 어려워진다.
스토리를 포함한 콘텐츠는 규칙 한 두 개를 고치는 것보다 공공 합의가 훨씬 어렵고
(새 악역은 어떤 배경의 인물이어야 하는지를 어느 세월에 커뮤니티에서
모여서 정한단 말인가), 결과적으로 특정 주체가 독단으로 새 콘텐츠의 방향과
디테일 모두를 만들어 내는 방법이 현실적이기 때문이다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn7&quot; id=&quot;fnref7&quot;&gt;7&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;장래에는 새 콘텐츠의 방향과 디테일 모두를 민주적 절차에 따라 블록체인
위에서 할 수 있도록 고도화될 수도 있겠지만, 아직은 갈 길이 멀다.
게다가 그런 절차를 구현하는 블록체인상의 프로그램이 게임 자체보다 복잡성이
아득히 높을 것으로 보여서, 사견으로는 배보다 배꼽이 크지 않은가 하는
비관적 전망이 있다.
개인적으로는 역시 아예 콘텐츠 업데이트를 지속적으로 하지 않아도 플레이어들끼리의
창발성이 재미의 열쇠가 되는 쪽이 훨씬 깔끔한 디자인으로 여겨진다.&lt;/p&gt;
&lt;h2&gt;마무리&lt;/h2&gt;
&lt;p&gt;내게 큰 다행이라면, 플라네타리움은 완전한 탈중앙 게임을 만들고자 모인 팀이라는
것이다.
게임을 전부 블록체인 위에 올려, 종국에 우리 개발팀이 모든 손을 놓더라도 게임을
즐기고 싶어하는 커뮤니티가 있다면 언제까지나 존속될 수 있는 탈중앙 게임을
만드는 것이 우리 팀의 목표이다.
이 글에서 참지 못하고 냉소적으로 쓴 부분들이 여럿 있지만,
이는 여태까지 한통속으로 싸잡혀 의심의 눈길을 받곤 했던 경험의 발로일 뿐이고,
사실 나 스스로는 이런 저런 말을 하기보다는 바람직한 블록체인 게임을 정말로
만들어내서 사람들에게 이런 게임도 있을 수 있다는 것을 제시하고 싶은 마음이
굴뚝같다.&lt;/p&gt;
&lt;p&gt;긴 글을 마무리하자면, 아래와 같이 요약할 수 있을 것 같다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;모든 게임이 탈중앙화될 필요는 없으며,
탈중앙화는 여러 층위에서 다양한 방식으로 추구할 수 있다.&lt;/li&gt;
&lt;li&gt;불록체인은 탈중앙화를 이루기 위한 여러 방법들 중 하나일 뿐이며,
일단 소프트웨어의 오픈 소스화나 &lt;abbr title=&quot;peer-to-peer&quot;&gt;P2P&lt;/abbr&gt; 네트워크 도입부터 하는 것만으로
상당한 탈중앙화를 이룰 수 있다.
&lt;ul&gt;
&lt;li&gt;그럼에도 탈중앙화 수단으로 블록체인이 필요한 장르가 있겠으나,
사견으로 그 폭은 매우 협소하다.&lt;/li&gt;
&lt;li&gt;블록체인을 도입해도 전체 시스템에서 특정 주체를 향한 신뢰에 많이
의존한다면 블록체인은 도입 안 하느니만 못하다.
종래의 방식보다 기술적 제약도 크고 만들기 성가시기 때문이다.&lt;/li&gt;
&lt;li&gt;아이템만 NFT화해서 얻는 이득은 없다고 판단되며,
RDBMS를 써서 아이템 거래소를 구축하는 게 빠르고 효율적이다.&lt;/li&gt;
&lt;li&gt;그럼에도 안 하느니만 못한 블록체인 도입을 하는 프로젝트가 안 그런
프로젝트보다 많은데, 이는 저의가 의심될 수밖에 없다.
블록체인 업계가 스캠이나 폰지 사기 의혹을 피할 수 없는 까닭이기도 하다.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;블록체인을 도입한다면 게임 플레이의 주요 로직과 데이터는
모두 블록체인 위에서 돌아가야 한다.
&lt;ul&gt;
&lt;li&gt;구현하기 매우 성가시기 때문에,
탈중앙화에 열정이 있지 않다면 블록체인 도입을 굳이 안 하는 게 낫다.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;블록체인의 특성이 게임 디자인에 침투되어야 한다.
&lt;ul&gt;
&lt;li&gt;긴 레이턴시를 게임의 일부로 녹여내야 한다.&lt;/li&gt;
&lt;li&gt;탈중앙 거버넌스를 해치지 않도록 유의해야 한다.
꾸준한 콘텐츠 업데이트가 필요한 장르는 애초부터 탈중앙화와 양립되기
어려울 가능성이 높다.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;심지어 게임 운영사가 아닌 플레이어조차, 그러한 불균형까지 게임의 룰로
내면화한 나머지 &lt;q&gt;아이템도 못 팔 거면 게임사가 게임을 왜 만들어야
하는데?&lt;/q&gt;라고 되묻기까지 한다.  독점권을 내려놓는다고 판매권이 아예
사라지는 것이 아님에도, 운영사가 현재의 독점권 없이는 온라인 멀티플레이어
게임을 안 만드느니만 못한다는 생각으로 널뛰는 것이다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;이러한 취지에서, 플라네타리움의 첫 게임 &lt;cite&gt;&lt;a href=&quot;https://nine-chronicles.com/&quot;&gt;나인 크로니클&lt;/a&gt;&lt;/cite&gt;은
아트워크까지 모두 &lt;a href=&quot;https://www.gnu.org/licenses/agpl-3.0.html&quot;&gt;AGPL 3.0&lt;/a&gt;으로 배포되고 있고,
실제로 인기 있는 다른 포크 프로젝트도 있다. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn3&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;90년대 말에는 PC방에 다같이 몰려가서 IPX로 &amp;#12298;&lt;cite&gt;스타&lt;/cite&gt;&amp;#12299; 멀티플레이를 하는
일이 흔했다.  &lt;cite&gt;StarCraft&lt;/cite&gt; 뿐만 아니라 당시 멀티플레이가 가능했던 게임
대부분은 &lt;abbr title=&quot;internetwork packet exchange&quot;&gt;IPX&lt;/abbr&gt; 방식을 활용했고, 오히려 배틀넷 같은 독점 서비스 방식은
더 나중에 대중화됐다. &lt;a href=&quot;#fnref3&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn4&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;요즘에는 &lt;abbr title=&quot;first-person shooter&quot;&gt;FPS&lt;/abbr&gt; 게임 &lt;cite&gt;&lt;a href=&quot;https://battlegrounds.pubg.com/&quot;&gt;PUBG: 배틀그라운드&lt;/a&gt;&lt;/cite&gt;에서 저숙련자도 겨냥을 쉽게
할 수 있도록 도와주는 일명 &lt;q&gt;배그 핵 마우스&lt;/q&gt; 따위도 시중에 나와 있다. &lt;a href=&quot;#fnref4&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn5&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;한편, 최근 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 열풍의 중심에는 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 디지털 아트가 놓여 있는데,
이를 두고 일각에서는 사람들이 디지털 아트를 실제로 손에 쥐고 싶은 게
아니라 (디지털 아트라 그럴 수도 없지만) 아티스트가 작품과 NFT를 소유한
자신의 관계를 공인해줬으면 하는 마음이나 그걸 사람들 앞에서 보이고 싶은
과시욕, 내가 그 아티스트에 후원했다는 만족감 같은 것을 NFT가 채워준다고
이야기하기도 한다.  만약 그러한 설명이 정말이라면 &lt;abbr title=&quot;non-fungible token&quot;&gt;NFT&lt;/abbr&gt; 디지털 아트의
열풍은 오프라인 전시와 판매가 어려워진 코로나19 시국이기 때문에 진품
보증서 대용으로 각광 받고 있는 걸지도 모른다.
어찌되었든 디지털 아트에는 적용 가능한 설명일지 몰라도,
게임 아이템에까지 확장될 수 있는 설명은 아닌 듯하다. &lt;a href=&quot;#fnref5&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn6&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;한 때 인기 있던 &lt;a href=&quot;https://www.zynga.com/&quot;&gt;징가&lt;/a&gt;류 &lt;a href=&quot;https://ko.wikipedia.org/wiki/%EC%86%8C%EC%85%9C_%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EA%B2%8C%EC%9E%84&quot;&gt;소셜 네트워크 게임&lt;/a&gt;들이 썼던 장치들을
벤치마킹해 볼 수 있겠다. &lt;a href=&quot;#fnref6&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn7&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;내가 속한 회사의 첫 게임 &lt;cite&gt;&lt;a href=&quot;https://nine-chronicles.com/&quot;&gt;나인 크로니클&lt;/a&gt;&lt;/cite&gt;도 이런 면에서 아쉬움이 많다.
RPG의 특성상 단순한 무대만으로 재미가 성립되지 않고,
플레이어들은 콘텐츠를 소모하며 세계의 끝을 향해 좇아오기 때문에 새로운
콘텐츠가 지속적으로 공급되어야 하기 때문이다.
차기작은 창발적인 장르의 게임이 되었으면 좋겠다. &lt;a href=&quot;#fnref7&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>새 블로그</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2021/12/new-blog/"
         
         />
       
         <id>https://writings.hongminhee.org/2021/12/new-blog/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2021/12/new-blog/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2021/12/new-blog/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2021/12/new-blog/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2021-12-28T18:27:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;새 블로그&lt;/h1&gt;
&lt;p&gt;여태 블로그를 두 번 운영했다.&lt;/p&gt;
&lt;p&gt;고등학교 졸업 직전에 열었던 첫 블로그는 3년쯤 운영하며 글을 백편 넘게 썼다.
처음에는 Typo&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;라는 소프트웨어로 만들다가 몇 개월 뒤 WordPress로 이전했다.&lt;/p&gt;
&lt;p&gt;두번째 블로그는 2010년에 시작해서 7년 동안 글을 약 200편 넘게 썼다.  처음에는
Tumblr로 열었지만 나중에는 정적 블로그 생성기&amp;mdash;소프트웨어 엔지니어라면 많이들
한번쯤 만들어 본다는&amp;mdash;를 써서 GitHub Pages로 옮겼다.&lt;/p&gt;
&lt;p&gt;2017년을 마지막으로 한동안 블로그에 글을 쓰지 않았다. 글을 안 쓰다보니 쓰고 싶은
글도 점점 사라졌고, 글을 어떻게 써야 할 지 막막해졌다.  그래서 독후감이라도
쓰자고 다짐한 게 지난해 봄이다. 독후감을 써 보니 다시 블로그도 하고 싶어졌는데,
있던 블로그는 어쩐지 먼지가 쌓인 느낌이 들고 손이 안 갔다.  예전에 썼던
글도 마음에 안 드는 게 많았다.  여러 생각이 크게 바뀌었기 때문에, 글을 조금
손보는 걸로는 성에 차지 않았다.&lt;/p&gt;
&lt;p&gt;실은 파일 하나짜리 Python 스크립트로 직접 만들었던 정적 블로그 생성기도 영
마음에 안 들던 참이었다.  한편, 그 사이 나는 거의 모든 사적 기록에 국한문을
쓰게 되었고, 블로그도 적어도 원고만은 국한문으로 적고 싶었다.  마침 국한문으로
원고를 쓰면 한글 전용으로 출판할 수 있게 도와주는 소프트웨어인 &lt;a href=&quot;https://github.com/dahlia/seonbi&quot;&gt;선비&lt;/a&gt;도
만들어 뒀었다.  그래서 그냥 세번째 블로그를 새로 만들기로 했다.&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;
&lt;p&gt;처음에는 GitHub Pages에서 아무 설치 없이 쓸 수 있는 Jekyll로 블로그를 만들기
시작했다.  그렇지만 얼마 지나지 않아 그런 구성으로는 선비를 활용하기 어렵다는
것을 깨달았다.  그밖에 다른 정적 블로그 생성기들을 써보느라 한두 달을 보냈던
것 같다.  서베이 끝에 깨달은 것은, 내가 바라는 요구사항의 많은 것들이
그다지 합리적이지 않기에 일반적으로는 요구되지 않는다는 것이었다.  21세기 한국,
어느 누가 국한문으로 원고를 쓰고 또 그걸 다시 한글 전용으로 출판하고 싶어할까.&lt;/p&gt;
&lt;p&gt;결국 이런저런 핑계로 또다시 &lt;a href=&quot;https://github.com/dahlia/jikji&quot;&gt;직지&lt;/a&gt;라는 정적 블로그 생성기를 만들게 됐다.
새로운 플랫폼도 배울 겸 &lt;a href=&quot;https://deno.land/&quot;&gt;Deno&lt;/a&gt;를 썼는데, 꽤 마음에 들어서 앞으로 Python 대신
Deno를 많이 활용하려고 한다.  다 만들고 보니 역시나 벌써부터 마음에 안 들어서
큰일이지만, 그래도 블로그를 2021년이 가기 전에는 시작하자고 마음을 다잡았다.&lt;/p&gt;
&lt;p&gt;아무튼 모처럼 블로그를 새로 만들었으니 이제 글도 다시 꾸준히 써보려고 한다.&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;당시 유행하던 Ruby on Rails로 만들어진 블로깅 소프트웨어.
이제는 &lt;a href=&quot;https://github.com/publify/publify&quot;&gt;Publify&lt;/a&gt;라는 이름으로 바뀌었다고 한다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;블로그를 세 차례나 옮겨다녔지만 퍼머링크는 유지하려 노력했다.  첫 블로그도
두번째 블로그도 업데이트만 멈출 뿐 아카이브로는 남기려고 한다. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>아무도 모른다</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/07/nobody-knows/"
         
         />
       
         <id>https://writings.hongminhee.org/2020/07/nobody-knows/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/07/nobody-knows/index.en.html"
         
           hreflang="en"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/07/nobody-knows/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/07/nobody-knows/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2020-07-08T19:07:00.000Z</published>
     <updated>2026-04-17T08:52:06.575Z</updated>
     <content type="html">&lt;h1&gt;&lt;cite&gt;아무도 모른다&lt;/cite&gt;&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;&lt;/h1&gt;
&lt;p&gt;유리사를 따라 고레에다 히로카즈의 &lt;cite&gt;아무도
모른다&lt;/cite&gt;(&lt;cite lang=&quot;ja&quot;&gt;誰も知らない&lt;/cite&gt;)를 봤다.
몇 번이나 눈물을 삼키느라 혼났다.
퉁쳐서 말하면 &lt;q&gt;총체적 난국&lt;/q&gt;과 &lt;q&gt;시스테믹한 비극&lt;/q&gt;이라 할 수 있을까.&lt;/p&gt;
&lt;p&gt;인공적 구조물에는 &lt;a href=&quot;https://ko.wikipedia.org/wiki/%EC%97%AC%EC%9C%A0%EB%8F%84&quot;&gt;용장도&lt;/a&gt;(&lt;span lang=&quot;en&quot;&gt;redundancy&lt;/span&gt;)가 있기 마련이라,
한 두 부분이 고장 난대도 전체 구조물이 이루고자 하는 데에는 대개 지장이 없다.
따라서 구조물이 크게 오작동 한다면 이미 여러 레이어에서 고장이 잔뜩
나 있다고 볼 수도 있다.
&lt;cite&gt;아무도 모른다&lt;/cite&gt;의 첫 반을 보며 느낀 것은, 이들 가족에게 이런 비극이
왔다는 것은 곧 그저 한 두 가지의 잘못으로 이뤄진 것이 아니라 더 큰 레벨에서,
곳곳의 잘못이 누적된 것이여야 하지 않나, 하는 생각이었다—그래서 &lt;q&gt;총체적 난국&lt;/q&gt;.
그러나 종반에 가서는 이 생각이 다시 뒤집히고 말았다.
이런 가족 한 둘쯤 비극적으로 생명을 잃는대도,
&lt;strong&gt;우리&lt;/strong&gt; 대부분이 사회 시스템의 이기(기능)를 누리는 데에는 아무 지장이 없으며,
따라서 그들의 죽음 따위는 우리 중 &lt;q&gt;아무도 모른다&lt;/q&gt;—즉, &lt;q&gt;시스테믹한 비극&lt;/q&gt;으로,
그러한 비극들은 나머지 우리의 삶을 누리기 위해 시스템의
여분(&lt;span lang=&quot;en&quot;&gt;redundancy&lt;/span&gt;)으로 &lt;q&gt;기능&lt;/q&gt;한다…&lt;/p&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;&lt;a href=&quot;https://www.facebook.com/hongminhee/posts/10222886443049439&quot;&gt;페이스북에 올렸던 글&lt;/a&gt;인데, 이제는 페이스북을 안 하게 되어 이곳에
올린다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>책임에 대하여</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/04/isbn-9788971999714/"
         
         />
       
         <id>https://writings.hongminhee.org/2020/04/isbn-9788971999714/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/04/isbn-9788971999714/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/04/isbn-9788971999714/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2020-04-12T21:26:13.000Z</published>
     <updated>2026-04-17T08:52:06.574Z</updated>
     <content type="html">&lt;h1&gt;&lt;cite class=&quot;series&quot;&gt;책임에 대하여&lt;/cite&gt;&lt;/h1&gt;
&lt;p&gt;이 책을 고른 것은 역시 아무래도 서경식 선생의 저서이기 때문이라 해야 할 것이다.
몇 해 전 읽었던 &lt;cite class=&quot;series&quot;&gt;난민과 국민 사이&lt;/cite&gt;가 요 몇 해 사이에
내 생각을 가장 많이 바꾸게 한 책 가운데 하나이기 때문에,
아무래도 서경식 선생의 책은 나오는 대로 찾아 읽으려 하는 편이다.
(아직 일본어 읽기가 빠르지 못해 원서를 읽을 엄두는 내지 못하고 있지만…)&lt;/p&gt;
&lt;p&gt;&lt;cite class=&quot;series&quot;&gt;책임에 대하여&lt;/cite&gt;(&lt;span lang=&quot;ja&quot;&gt;責任について&lt;/span&gt;)는 서경식 선생과 다카하시 데쓰야 선생의
대담을 엮은 것으로, 애써 짧게 줄여 보자면:
현대 일본의 되다 만, 그래서 마침내는 후퇴하고 있는 책임 의식을 이야기한다.
특히 여기서는 현대 일본의 리버럴이 얼마나 알맹이가 없는지를 낱낱이 드러내고
있는데, 이를테면 아래는 다카하시 선생 스스로는 어땠는가에 대해 말하고 있다:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;고대 그리스 이래의 서양 철학의 전통과 같은 것이 일단 파산했다고 할 수밖에
없는 지점에서 각자 사고를 시작하지 않으면 안 된다, 그런 상황에서 20세기의
사상이 나오고 있습니다.  그런데 그것을 일본에 가지고 오면 그저 &amp;lsquo;공부&amp;rsquo;의
대상밖에 되지 않는 구조가 견고하게 존재해요.
나 자신도 그런 속에서 자랐으니까 완전히 벗어났다고는 여기지 않지만,
공허한 생각에 사로잡힐 때가 많아져서 이대로는 아무래도 만족할 수 없다고
생각하게 되었습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;이 책은 새로운 지식보다는, 얼기설기 알고 있던 문제들을 일관된 의식으로 조명하여
더 깊게 생각해 볼 기회를 많이 주었다.
오키나와의 미군 기지 문제나 후쿠시마 원전 사고 문제는 따로 그것만 다루는 책을 읽어보지는
못해 구체적으로는 잘 몰랐지만, 여러 언론 보도나 일본의 현대사나 정치를 다루는
글에서 지나가며 언급될 때가 많아 조금은 익숙한 주제였고,&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn1&quot; id=&quot;fnref1&quot;&gt;1&lt;/a&gt;&lt;/sup&gt;
사실 모르는 사건이나 인명이 나와도 하나하나 찾아가며 읽지는 않았다.&lt;/p&gt;
&lt;p&gt;이하는 읽는 동안 밑줄 쳐둔 곳이나 메모한 것들을 함께 적는다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;이는 모토시마 히토시 나가사키 시장이 쇼와 천황에게 전쟁 책임이 있다고
말했다가 우익 세력에게 저격당했을 때(1990년 1월 18일), 전체 매스컴이 한
목소리로 &lt;q&gt;언론의 자유에 대한 폭력은 용납될 수 없다&lt;/q&gt;라고 했던 논조와도
겹칩니다.  천황에게 전쟁 책임이 있다는 모토시마 씨의 주장에 대한
자신들의 견해를 제시하지 않았어요.  그것이 실로 공허한 주체지요.
&lt;q&gt;언론의 자유를 지켜라&lt;/q&gt;라고 하면서 어떤 언론인지는 말하지 않고 회피했습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;언론이 일절의 가치 판단을 피하려고만 한다면 (아니, 이도 좋게 봐준 것이고,
책임을 져야 할 때만 쏙 빠지려고 한다면) 그 언론에게 주어지는 무제한의 자유라는
것이 얼마나 가치가 있는 것일까.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;그저 송구스럽다는 태도를 취해 온 사람들일수록 견디지를 못합니다.
그런 태도가 일본 지식인들의 아시아에 대한, 조선에 대한,
중국에 대한 접근 방식 속에 있었고 그 병의 뿌리가 깊어서,
내용은 없이 그저 죄송하다는 일종의 코드밖에 없었으므로,
그것이 역전되는 순간에 내용도 사라져 버리지요.
그런 방식이 아닌, 어떤 문제에 책임이 있는가, 어떤 책임이 있는가,
나는 어느 부분에 대해 책임을 느껴야 하는가,
라는 분절화된 인식을 하지 못하고 그냥 통째로 일본인이 옳은가/조선인이 옳은가,
라는 식의 사고밖에 할 수 없게 되었지요.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;q&gt;일종의 코드밖에 없&lt;/q&gt;는 태도, 여러 인권 문제에서도 쉽게 볼 수 있는 듯.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;그것은 1990년대에 나온 페미니즘과, 그런 인간 해방이나 민족 해방이 교차하는
지점에서 끊임없이 제기되는 논점이지요.
다수파 여성이 다수파의 권내에서 여성의 권리를 주장한다/다수파로서의 파이
배당 몫을 다투고 있다/다수파 남성과의 균형을 다투고 있다는 것인데,
그 자체는 반론할 수 없지만 그 다수파가 구성하는 국가가 식민지를 억압하거나
수탈할 경우에, 다수파 내부의 모순만 문제 삼는다면 결과적으로 식민지적
관계를 승인하는 구조를 만듭니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;기시감.  우리가 상호교차성(intersectionality)에 눈 감아서는 안 되는 이유이기도
할 것이다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;미국에 의해 억압받고 수탈 당하는 지역의 사람들로서는 제국주의,
식민주의의 멍에에서 해방되는 것이 1차적 과제인 데 비해, 미국 국민=시민은
&amp;lsquo;파이&amp;rsquo;를 얼마나 &amp;lsquo;공정&amp;rsquo;하게 분배받을지가 과제입니다.
따라서 &amp;lsquo;파이&amp;rsquo;가 커지는 것 자체, 즉 식민지적 수탈 자체에 대한 근원적인
저항은 일어나기 어렵습니다.  다수파 중 다수에 내면화된 식민주의적인 심성이
그것을 곤란하게 만드는 장벽입니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;역사적 사건이 일어난 타이밍이 일본의 우파 세력에게 순풍이 되었다고 할 수
있겠군요.  즉 냉전 구조의 붕괴와 동시에 동아시아에 전쟁 피해자들이
나타났습니다.  그러나 냉전 구조의 붕괴는 이른바 좌익 인사들이 자신을 완전히
잃어버린 사건이었으므로 좌익적인 기반 위에 존재하고 있던 노동조합,
예컨대 우파가 실체 이상으로 적대시하는 일교조도 흔들렸기 때문에 인권 교육이나
평화 교육의 대응도 약화되었지요.  아마도 교사 한 사람 한 사람이 인권이나
평화 문제를 자신의 사상으로 내면화하지 못했기 때문이 아니냐는 생각이 듭니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;냉전의 해체가 피해자들을 억누르던 힘을 완화시켰지만,
그러면서도 민주화를 스스로 쟁취하지 않은 일본 리버럴의 바닥을 무너뜨리기도
했다고 보는 서경식 선생.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;가토 슈이치 씨와 히구시 요이치 씨의
대담집(&lt;cite lang=&quot;ja&quot; class=&quot;series&quot;&gt;時代を読む―「民族」「人権」の再考&lt;/cite&gt;, 소학관, 1997년)을
읽고 충격을 받은 적이 있습니다.  두 사람 모두 일본이 길을 잘못 든 것은
만주 사변(1931년) 이후라고 인식하고 있었기 때문입니다.  만주 사변 무렵에는
일본이 이미 식민지 제국이 되었는데도 말이지요.  즉 그러면 어찌 되는고 하니,
전후 민주주의를 대표하는 리버럴파 지식인들의 역사 인식과 아베 신조 총리의
전후 70년 담화의 역사 인식이 어떤 의미에서는 연결되어 버립니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;서 &lt;q&gt;스기타 씨&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn2&quot; id=&quot;fnref2&quot;&gt;2&lt;/a&gt;&lt;/sup&gt;의 경우는 (…) 그때 나에게 &lt;q&gt;서 선생, 민족&amp;#xb7;국가 같은 관념은
낡았으니 버리는 것이 좋아요&lt;/q&gt;라고 말했습니다.&lt;/q&gt;&lt;/p&gt;
&lt;p&gt;다카하시 &lt;q&gt;음, 일본인이 재일 조선인에게 할 수 있는 말일까 하는 느낌이 드는군요.
포스트모더니즘을 빠져나간 일본 지식인들 중에서는 민족이나 국가를 간단하게
&lt;q&gt;넘어서는&lt;/q&gt; 것이 가능한 듯이 말하는 사람이 많아요.
하지만 국가를 &amp;lsquo;관념&amp;rsquo;으로 내버릴 수 있는 듯이 생각해도,
현실적으로 국가를 버릴 수 있느냐 하면 그리 간단치 않습니다.
빈번히 국제 심포지엄에 참가하고 &amp;lsquo;국경을 넘는&amp;rsquo; 지식인으로 활동하고 있을
사람들도 일본 정부가 발행한 여권의 보호를 받고 이동하는 처지여서,
&lt;q&gt;국가를 초월한다&lt;/q&gt;라고 주장하는 사람들이, 알고 보니 약삭빠르게도 국립 대학
교원이더라 하는 경우가 드물지 않습니다.&lt;/q&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;위 얘기는 &lt;q&gt;포스트콜로니얼 연구를 묻는다&lt;/q&gt; 섹션에서 가져온 것인데,
그 섹션에서는 이어서 우치다 다츠루로 화제가 옮겨간다.
기가 막히는 인용들.  아마 지난해(2019년)에 한국 언론에서도 &lt;q&gt;파국 원망&lt;/q&gt; 같은
것으로 무역 보복에 대해 말했던가.  좀 세게 얘기하자면 이쯤 되면 한남 리버럴과
거의 거울과 같은 이야기들 아닌가.  아니, 한국 리버럴이 보고 배운 원본이니
당연하다고 해야 하는 것인지.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;예컨대 후쿠시마 번호판을 단 거가 주차하려 하면 가까이 오지 말라고 한다거나,
피난 온 아이들이 피난지의 학교에서 따돌림을 당하기도 하지요.
크게 보면 근대 일본이 그런 분단과 차별 위에 만들어진 식민 제국인데
그 구조가 지금의 일본 사회에서도 유효하게 기능하고 있습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;차별 구조는 그러한 질서를 (적극적이든 비자발적이든) 승인한 모두가 차별 당하도록
만든다.  누가 더 나중에 당하냐, 누가 더 많이 당하냐만 다를 뿐이다.  코로나19로
드러난 「우한→중화 인민 공화국→중화→동아시아」의 체인을 봐도 알 수 있다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;전기는 모두가 일상적으로 향유하는 것이고 자신들의 풍성한 소비 생활을 떠받치고
있지요—그 에너지원으로서 원전을 국책으로 추진해 왔고 종종 사고를 일으켰다,
이것은 불운한 일이고 특히 큰 피해를 입은 후쿠시마 사람들에게는 아마 최악이었겠지만
그것을 굳이 가해/피해 같은 대립 구도로 볼 필요는 없지 않나,
라는 것이 리버럴한 사람들까지 포함한 많은 사람들이 공유하는 감각 아닐까요.
그러나 서 선생이 말씀하신 대로, 원전 사고는 가해 행위이며 자국민만이 아니라
근린 제국 사람들에게도 피해를 주고 재가동하면 방사성 폐기물을 자꾸 축적해서
미래 세대의 위험(risk)을 높입니다.  따라서 그 사고가 일어나고 얼마 뒤에
깨달은 것은 일본 열도에 이렇게 많은 원전을 건설한 시대, 고도 경제 성장기에
태어나 자라고 성인이 된 우리 세대야말로 가해 책임의 당사자들이라는 사실입니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;p&gt;&lt;cite class=&quot;series&quot;&gt;&lt;a href=&quot;https://ko.wikipedia.org/wiki/%EC%B2%B4%EB%A5%B4%EB%85%B8%EB%B9%8C%EC%9D%98_%EB%AA%A9%EC%86%8C%EB%A6%AC&quot;&gt;체르노빌의 목소리&lt;/a&gt;&lt;/cite&gt;(&lt;span lang=&quot;ru&quot;&gt;Чернобыльская молитва&lt;/span&gt;)로 노벨 문학상을 받은
&lt;a href=&quot;https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%B2%A0%ED%8B%80%EB%9D%BC%EB%82%98_%EC%95%8C%EB%A0%89%EC%8B%9C%EC%98%88%EB%B9%84%EC%B9%98&quot;&gt;스베틀라나 알렉시예비치&lt;/a&gt;(&lt;span lang=&quot;ru&quot;&gt;Светлана Александровна Алексие́вич&lt;/span&gt;)가
2000년 방일했을 때 들었다는 소리:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;그녀가 말하기를, 그 전에 일본에 왔을 때 &lt;q&gt;당신들 나라는 사회주의 국가여서
관리가 제대로 되지 않아 원전 사고가 났지만, 일본에서는 일어나지 않아요&lt;/q&gt;라는
말을 들었다고 해요.  일본뿐만 아니라 프랑스나 다른 나라들에서도 같은 말을
들었다고 합니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;나는 여러 가지 문제로 우파로부터 종종 공격을 받아 왔습니다만,
이 주장에 대해서는 오히려 좌파로부터 반발과 저항이 강해서 놀랐습니다.
전후 좌익이 지상 명령으로 삼아 온 &amp;lsquo;안보 반대&amp;rsquo;를 부정하는 것이라고
생각했겠지요.  본토의 호헌파나 리버럴파는 이 주장에 개입하면 오키나와와
식민자로서의 입장에 대한 직접적인 문제 제기가 나올까 봐 걱정해서인지 침묵과
무시로 일관하는 사람도 많습니다.  하지만 오키나와의 운동계나 지식인 세계에는
본토 이상으로 강한 반안보&amp;#xb7;반기지 운동의 역사가 있기 때문에,
실은 요즘 오키나와 내의 다른 주장들과 큰 논쟁이 벌어지기도 합니다.
오키나와의 일반인들 사이에는 &lt;q&gt;현외 이전은 당연&lt;/q&gt;하다는 의식이 확산되는 한변으로,
&amp;lsquo;본토&amp;rsquo;가 &amp;lsquo;인수한다&amp;rsquo;는 데에 반대하는 지식인이 있습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;거듭 나타나는, 차별&amp;#xb7;식민 구조의 연쇄&amp;#xb7;&amp;lsquo;겹들&amp;rsquo;로 인한, 피식민지 사이에서의 갈등.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;오키나와에 대해서 &amp;lsquo;악마의 섬&amp;rsquo;이라고 말할 것이 아니라 &amp;lsquo;본토&amp;rsquo;의 &amp;lsquo;중심부 일본 국민&amp;rsquo;이
그 오명을 덮어써야 합니다.  그런 오명을 덮어쓰고 싶지 않다면 자신들의 의사와
힘으로 그것을 그만두어야 합니다.  지금 이야기하는 식으로 말하자면, 안보 체제를
선택한 &amp;lsquo;본토&amp;rsquo;가 반격을 당하더라도 괜찮냐는 논의를 &amp;lsquo;본토&amp;rsquo;에서 해야 합니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;q&gt;안보 체제&lt;/q&gt;라는 것을 결정(그것 또한 강요된 것이긴 하다)했지만 그 책임은
오키나와에 떠넘겼다—그리고 그대로 움직이지 않으며 &lt;em&gt;완전&lt;/em&gt;히 안보 체제를 벗어나자는
주장을 원론적으로만 되풀이한다.  그런데 본토 내에서도 아마 마이너리티일 그들의
목표를 현실화할 수 없는 까닭은, 본토의 마이너리티가 그들이 받아들인
&lt;q&gt;안보 체제&lt;/q&gt;의 식민 지배를 체험하지 않기 때문이기도 하다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;나도 현실 속에서 작동하는 권력관계 속에 있는 것이 분명한데, 그것을 일거에
뛰어넘으려 하는 내가 &lt;q&gt;아이덴티티에 구애받지 않는 월경자&lt;/q&gt;라거나 &lt;q&gt;재일
일본인&lt;/q&gt;이라거나, 국가와 민족을 이탈한 &amp;lsquo;난민&amp;rsquo;이고, &lt;q&gt;내적 망명자&lt;/q&gt;임이 분명하다는
등의 말들을 합니다.  그러나 그것은 관념 속의 이야기이며,
일본 국민은 현실 속에 존재하고 그 속에 오키나와에 대한 차별 구조가 있지요.
현실에 존재하는 권력 구조를 직시하고 그것과 대치하며 그것을 바꾸어 감으로써
비로소 더 넓은 차원으로 나아갈 수 있지 않은가.
그런 과정은 생략할 수 없다고 생각합니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;이 발언은 다카하시 선생이 한 것이지만, 서경식 선생의 &lt;cite class=&quot;series&quot;&gt;난민과 국민 사이&lt;/cite&gt;에서는
민족성 내지는 내셔널리티 같은 아이덴티티가 어떻게 만들어지는지에 관해
(한국 같은 다양성이 떨어지는 곳에서 메이저리티로 살아온 사람에게는 잘 떠올리지
못하는) 아주 중요한 관점을 짚는다.  재일 조선인이 스스로를 일본인이 아니라
조선인으로 정체화한다면, 이것은 먼저 일본인이 그를 조선인이라고 구별짓기
시작하기 때문이라는 것이다.  재일 조선인이 스스로가 조선인이라는 생각을 떨쳐낼
수 없는 것은 일본인이 그들이 자꾸 조선인이라는 것을 상기시키기 때문이다.
따라서 일본 리버럴이 스스로를 &lt;q&gt;재일 일본인&lt;/q&gt;이라고 부르는 것은
(적어도 일본 안에서) &lt;q&gt;재일 조선인&lt;/q&gt;이 멸칭으로 쓰이고 있으며 그러한 멸칭은
자칭이 아니라 오로지 남으로부터 불리는 것이라는 아주 기본적인 이해조차 못하고
있다는 것을 보여준다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;그들의 레토릭에는 세 종류가 있는데 첫째로 인권  옹호, 민주주의 촉진이라고
주장하는 것입니다.  여기서는 이라크전쟁을 염두에 두고 있습니다.
둘째, &amp;lsquo;문명의 충돌&amp;rsquo;로 이야기하는 것이지요. (…)
셋째, 신자유주의적 경제학의 법칙들을 받아들이는 것 외에 다른 선택지는 없다고
주장하지요. (…) 월러스틴(Immanuel Wallerstein)은 이렇게 권력에 의해 왜곡된
보편주의를 &amp;lsquo;유럽적 보편주의&amp;rsquo;라 부르고, 진정한 보편주의, &amp;lsquo;보편적 보편주의&amp;rsquo;를
이것에 대치시키라고 호소합니다.  &lt;q&gt;이 두 개의 &amp;lsquo;보편주의&amp;rsquo; 사이에서 선택은
피할 수 없다.  어떤 초개별주의적 입장(중략)으로 물러날 수 없다.  왜냐하면
초개별주의는 실은 유럽적 보편주의와 현재 권력을 장악한 자들의 힘—그들은
비평등주의적이며 비민주주의적인 세계 시스템의 유지를 꾀한다—에 대한 은폐된
항복과 다르지 않기 때문이다.&lt;/q&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;전후 일본까지 이어진 요시다 쇼인에 대한 평가 하나만 보더라도 메이지 이후의 대외
침략에 대한 정당화가 얼마나 뿌리 깊은지 알 수 있습니다만,
그 중심에는 존황 사상이 있고 옛 일본군의 &amp;lsquo;정벌&amp;rsquo;이라는 독특한 말에서도
그것을 찾을 수 있습니다.  즉 천황의 군대에 대드는 자는 잘못을 저지른 것이며
야만이고 낙후된 자들이므로 그들을 &amp;lsquo;정벌&amp;rsquo;해야 한다는 사상입니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;김시덕 교수의 &lt;cite class=&quot;series&quot;&gt;&lt;a href=&quot;isbn-9788932917931.md&quot;&gt;일본의 대외 전쟁&lt;/a&gt;&lt;/cite&gt;(&lt;span lang=&quot;ja&quot;&gt;異国征伐戦記の世界ー韓半島、琉球列島、蝦夷地&lt;/span&gt;)에서
개론한 &lt;q&gt;정벌&lt;/q&gt;이라는 말의 역사를 다뤘던 것이 함께 떠올랐다.&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;천황제는 없어질 운명이고, 없어지는 것이 좋다는 생각이 지식인들 사이에는
있었습니다.  하지만 그 지식인들 자신도 이중적이어서, 논리적으로 생각하면
그렇지만 현실적으로는 그렇지 않다는 구도가 실은 내면화&amp;#xb7;습성화되어,
지금 다카하시 선생이 이야기했듯이 명석하게 말하는 사람은 거의 없어진 것으로
보입니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;아베 정권하에서 정치의 폭주가 계속될 때 호헌 입장에서 그것에 브레이크를 거는
유일한 존재가 아키히토 천황이리라는 긍정적인 평가가 리버럴파 지식인들 속에서도
눈에 띕니다.  하지만 여기서 천황의 역할에 기대하는 것 자체가 바로 천황제
때문이라고 생각합니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;p&gt;책 마지막에 다카하시 데쓰야의 &lt;cite&gt;돌아보니 수치심
없이는…&lt;/cite&gt;(&lt;span lang=&quot;ja&quot;&gt;かえりみて羞恥の感なきを……&lt;/span&gt;)&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn3&quot; id=&quot;fnref3&quot;&gt;3&lt;/a&gt;&lt;/sup&gt;가 실려있는데, 이로부터:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;그러나 다카미&lt;sup class=&quot;footnote-ref&quot;&gt;&lt;a href=&quot;#fn4&quot; id=&quot;fnref4&quot;&gt;4&lt;/a&gt;&lt;/sup&gt;의 그런 감개에는 바로 한 달 전까지 &amp;lsquo;일본문학보국회&amp;rsquo;에서
활동했던 작가의 한계도 보인다.  그는 &lt;q&gt;자국 정부에 의해 당연히 주어져야 했던
자유&lt;/q&gt;라고 썼지 &lt;q&gt;인민이 자국 정부가 보장하도록 만들었어야 할 자유&lt;/q&gt;라고 쓰지
않았다.  그가 부끄럽게 생각한 것은 자국민의 자유를 박탈한 &amp;lsquo;자국 정부&amp;rsquo;가
&lt;q&gt;그 박탈을 해제하려 하지 않았다&lt;/q&gt;는 점이었지, 인민이 자국 정부와 싸워서 그것을
무너뜨리고 스스로 자유를 획득할 수 없었다는 점이 아니다.  다카미의 감각은 여전히
&lt;q&gt;대일본제국헌법&lt;/q&gt;적 단계에 있었다고 할 수 있을지도 모르겠다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr class=&quot;footnotes-sep&quot;&gt;
&lt;section class=&quot;footnotes&quot;&gt;
&lt;ol class=&quot;footnotes-list&quot;&gt;
&lt;li id=&quot;fn1&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;이 책을 읽으며 다카하시 선생의 다른 저서
&lt;cite class=&quot;series&quot;&gt;희생의 시스템 후쿠시마 오키나와&lt;/cite&gt;(&lt;span lang=&quot;ja&quot;&gt;犠牲のシステム――福島・沖繩&lt;/span&gt;)도
읽어봐야겠다고 생각하긴 했다.  마침 같은 역자인 한승동 기자가 옮겼다. &lt;a href=&quot;#fnref1&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn2&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;일본의 정치학자 &lt;a href=&quot;https://ja.wikipedia.org/wiki/%E6%9D%89%E7%94%B0%E6%95%A6_(%E6%94%BF%E6%B2%BB%E5%AD%A6%E8%80%85)&quot;&gt;스기타 아쓰시&lt;/a&gt;. &lt;a href=&quot;#fnref2&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn3&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;원문은 &lt;cite&gt;계간전야&lt;/cite&gt; 2006년 봄호에 실렸다. &lt;a href=&quot;#fnref3&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li id=&quot;fn4&quot; class=&quot;footnote-item&quot;&gt;&lt;p&gt;일본의 작가 &lt;a href=&quot;https://ja.wikipedia.org/wiki/%E9%AB%98%E8%A6%8B%E9%A0%86&quot;&gt;다카미 준&lt;/a&gt;. &lt;a href=&quot;#fnref4&quot; class=&quot;footnote-backref&quot;&gt;↩︎&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;/section&gt;
</content>
    </entry>
  
    <entry>
     <title>《경계 없는 페미니즘》</title>
     
     
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/03/isbn-9791196767402/"
         
         />
       
         <id>https://writings.hongminhee.org/2020/03/isbn-9791196767402/</id>
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/03/isbn-9791196767402/index.ko-kore.html"
         
           hreflang="ko-Kore"
         
         />
       
     
       <link rel="alternate" href="https://writings.hongminhee.org/2020/03/isbn-9791196767402/index.ko-hang-kr.html"
         
           hreflang="ko-Hang-KR"
         
         />
       
     
     <published>2020-03-18T20:29:09.000Z</published>
     <updated>2026-04-17T08:52:06.574Z</updated>
     <content type="html">&lt;h1&gt;&amp;#12298;&lt;cite&gt;경계 없는 페미니즘&lt;/cite&gt;&amp;#12299;&lt;/h1&gt;
&lt;p&gt;&amp;#12298;&lt;cite&gt;경계 없는 페미니즘&lt;/cite&gt;&amp;#12299;은 2018년 즈음 제주도에 있는 예멘 난민의 추방을 요구하는
세론에 대해 상호교차성에 입각해 여러 페미니스트들이 회답하는 글을 게재한,
&lt;a href=&quot;https://www.facebook.com/feminismwithoutborders&quot;&gt;같은 이름의 페이스북 페이지&lt;/a&gt;의 글들을 엮어 책으로 낸 것이다.
머리말 &amp;#12296;&lt;cite&gt;우리의 말은 여전히 작고 느리고 희미하지만&lt;/cite&gt;&amp;#12297;과 맨 마지막의
&amp;#12296;&lt;cite&gt;다시 경계 없는 페미니즘을 위하여&lt;/cite&gt;&amp;#12297;를 제외한 모든 글은 저 페이스북 페이지에
그대로 남아 있다.&lt;/p&gt;
&lt;p&gt;애초에 &lt;a href=&quot;https://www.tumblbug.com/noborder&quot;&gt;이 책을 엮는 프로젝트&lt;/a&gt;를 알고 후원할 수 있었던 것도 그 페이스북
페이지를 구독하고 있었기 때문이라, 실은 이미 읽은 글도 많았다.
그렇지만 못 읽고 놓진 글이 더 많았고,
반 이상 읽을 때까지 이미 읽은 글이라는 것을 눈치 채지 못할 만큼
가물가물해진 글도 많았다.  이미 읽은 글도 다시 읽으니 새로웠다.&lt;/p&gt;
&lt;p&gt;책을 받은 것은 2019년 가을인데, 그 해 끝자락부터 아주 천천히 읽었다.
어려운 내용도 많았고 한 고작 문단 읽고서 한참을 생각할 때도 많았다.
하루에 글 하나씩 읽었던 것 같다. 잘 읽히지 않아도 그냥 앞에서부터
순서대로 읽었다. 글은 페이스북 페이지에 올라온 순서와는 다르게,
크게 네 가지 주제에 맞춰 다시 나열됐고, 그 편집 그대로 읽고 싶었기 때문이다.
그렇지만 도리어 그 때문에 더 읽기 어렵고 산만하기도 했다.
모두 다른 사람이 하나의 사건을 갖고 썼고, 게다가 상호교차성을 받아들인
페미니스트들이라는 동질성까지 합쳐져, 중요한 메시지들은 거의 모든 글에서
겹쳐서 나왔다. 했던 얘기를 계속 들으니 잊어버릴 새는 없었지만,
글 하나하나가 참 좋았음에도 이어서 읽기에는 힘들었다.&lt;/p&gt;
&lt;p&gt;내가 한참 읽는 동안에는 예비역 하사 변희수 씨가 성재지정수술을 받은 뒤
육군에서 강제전역된 일이나 트랜스젠더 숙명여대 합격생이 학내 반대 여론에
입학을 포기한 일이 있었고, 이 사건들은 자연스럽게 책의 메시지를 생각할 때
함께 떠오를 수밖에 없었다.&lt;/p&gt;
&lt;p&gt;모든 글이 다 무겁게 다가왔지만, 읽는 동안 메모했던 곳들을 인용해본다:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;(…) 여성혐오는 남성중심적 사회의 편의를 위해 구조가 간편하게 발전시킨
편견임을 포착했듯이 말입니다. (…) 그래서 환대는 그 행위에 잇따르는 고민과
문제들 또한 우리가 감히 감수하겠다는 의지적 선언입니다.
더 나아가 그 과정에서 고민을 함께 줄여나가고, 문제들을 최소화 하겠다는
정치적인 움직임입니다. 아무런 &amp;lsquo;문제&amp;rsquo;가 없을 때 타자를 환영하고 수용하는
것은 어렵지 않기 때문입니다.&lt;/p&gt;
&lt;p&gt;이예찬 &amp;#12296;&lt;cite&gt;&lt;a href=&quot;https://www.facebook.com/feminismwithoutborders/posts/649959912048162&quot;&gt;퀴어로서 난민을 환대해야 하는 이유&lt;/a&gt;&lt;/cite&gt;&amp;#12297;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;blockquote&gt;
&lt;p&gt;한 사회의 차별과 억압을 생각할 때면, 그 차별과 억압에 맞서 싸우는
사람들의 존재도 언제나 같이 떠올려야 한다. 그들은 도움을 받아야 할
대상이라기보다 자기들이 처한 상황을 딛고 현재와 미래를 조직하는 주체다.
그들의 싸움에 연대하고자 한다면, 우리 자신이 그들의 사정에 무지할 수 있고
그렇게 무지하다는 사실에 대해서도 무지할 수 있음을 엄격하게 인정하는
데서부터 시작해야 한다. 묻고 듣고 배우려는 마음으로,
정말로 힘을 보태자는 의지를 가지고, 선입견 없이, 사려 깊게 말이다.
이것은 응답하기 위한 최소한의 준비다.&lt;/p&gt;
&lt;p&gt;이진화 &amp;#12296;&lt;cite&gt;&lt;a href=&quot;https://www.facebook.com/feminismwithoutborders/posts/639085709802249&quot;&gt;연대의 윤리—보이콧 버뮤다 운동의 오류에서 배우기&lt;/a&gt;&lt;/cite&gt;&amp;#12297;&lt;/p&gt;
&lt;/blockquote&gt;
</content>
    </entry>
  
</feed>
