【拡散希望】

Hackers' Pub（ハッカーズ・パブ）は現在開発中の、ソフトウェアエンジニアと技術愛好家の為のActivityPub対応ソーシャルネットワークです。現在は韓国語中心のコミュニティが形成されていますが、日本のエンジニアの方々にも参加していただきたいと考えています。

Hackers' Pubは短文の投稿^[1]と長文の記事^[2]の両方をサポートしています。日常的な会話や簡単な質問は短文投稿で、詳細な技術解説やチュートリアルなどは長文記事で表現できます。QiitaやZennのような技術ブログ機能と、MastodonやMisskeyのようなタイムライン機能を兼ね備えた一つのプラットフォームで、両方の利点を享受できます。何よりもActivityPubプロトコルに対応している為、Mastodon、Misskey、Akkoma等と連携可能です。（このアカウントもHackers' Pubから投稿しています！）

技術的な特徴として、拡張Markdownによるテーブル、脚注、警告ボックス、ダイアグラム、数式などの多様な記法をサポートし、構文ハイライト、行ハイライト、差分表示などの強力なコードブロック機能も備えています。また、様々な言語での投稿が可能で、将来的には自動翻訳機能も予定しています。

Hackers' PubはAGPL-3.0ライセンスの下で開発されているオープンソースプロジェクトです。コードの貢献や機能提案も歓迎しています。

現在はまだ開発段階のため招待制となっています。Hackers' Pubに興味がある方は、DMや返信でメールアドレスをお知らせいただければ、招待状をお送りします。技術コミュニティの一員として、ぜひご参加をお待ちしております。よろしくお願いいたします。

Hackers' Pub에 이제 알림 기능이 생겼습니다. 우상단 프로필 사진 바로 왼쪽에 알림 아이콘이 추가되었고, 이제 읽지 않은 알림이 있을 경우 그 위에 빨간 동그라미가 표시됩니다. 알림의 종류는 현재 다음 다섯 가지입니다:

• 누가 날 팔로했을 때
• 누가 날 언급했을 때
• 누가 내 글에 답글을 달았을 때
• 누가 내 글을 인용했을 때
• 누가 내 글을 공유했을 때

역시 모든 것들은 직접 데여봐야 는다... React의 useContext가 뭐하려고 쓰는지 실감이 잘 안났었는데, prop drilling하지 않고 디펜던시를 주입하고 싶을때 유용한듯.

특히, 어떤 특정한 데이터를 다루는 복잡한 컴포넌트를 다룬다고 가정하면 요렇게 프로바이더에 넘겨주면 되고 하위 컴포넌트에서는 useContext에서 그 값을 가져오면 코드도 굉장히 깔끔해지게 되는 듯

  <PostContext.Provider value={{ currentUser }}>
     <Post.Title post={post} />
     <Post.Comments>
       {comments.map(comment =>
          <Post.Comment  comment={comment} />
        )}
     </Post.Comments>
  <PostContext.Provider>

이런 글도 있다.

https://testdouble.com/insights/react-context-for-dependency-injection-not-state-management

@jjme정진명 @hongminhee洪 民憙 (Hong Minhee) 저는 고스트가 페디파이에 자금 지원을 하게 된 이 이야기를 참 좋아합니다. https://writings.hongminhee.org/2024/07/ghost-funds-fedify/

@hongminhee洪 民憙 (Hong Minhee) @curry박준규 저도 C/C++만 하다가, 취직해서 Python/C# 등등 메모리 관리 알아서 해주는 언어의 편리함을 제대로 느꼈거든요. 그런 다음에 Rust 나왔을때 다시 메모리 관리하려고 하니까 너무 불편하고 이런걸 꼭 해야하나 싶었습니다. 요즘은 하스켈로 space leak 와장창 내면서 살고 있습니다ㅋㅋ

이거 사서 읽긴 했는데, 문서에서 설명하는 내용이랑 거의 비슷해요. 액티비티펍이 왜 생겨났고, 액티비티펍으로 어떤 미래를 기대하는가 같은 내용 위주로 읽으면 좋을 것 같아요. 다만, 여기에 실습 예제는 따로 실습 안하고 슥 하고 보기만 했는데, 실용적인 뭔가를 만들거면 Fedify 문서를 정독하는게 낫지 않나 싶습니다

RE: https://hackers.pub/@curry/0195f6ee-df39-7af7-b388-495fcc0d0789

몇 년 전에 취미로 프로그래밍 책 제본을 했다. 인터넷에서 업체에 PDF 파일을 전달하면 제본해서 택배로 받았다. 그렇게 읽지도 않는 책은 쌓여만 갔다. 결국 몇 달 전에 하스켈 학교 모르는 분에게 한 권만 나눔하고 모두 버렸다.

그런데 프로그래밍 책은 펼쳐 놓고 노트북을 켜서 실습할 때가 많기 때문에 잘 펴져야 한다. 떡제본은 펼침성이 나빠서 불만이었고 여러 제본 방식을 알아보다가 바인더 형식을 써보기로 했다. 적당한 업체를 찾아서 첫 주문을 했는데 오늘 도착했다. 원래 표지 디자인을 직접 해서 업체에 PDF를 전달해야 하는데 하는 법도 모르고 시간도 없어서

“그냥 대충 알아서 해주세요.”

했는데⋯

너무 이쁘게 잘 뽑아 주셨다. 책등 문구 디자인도 알아서 센스 있게 해주셨는데 너무 마음에 든다. 과연 이 책은 끝까지 읽을 수 있을까!

@kodingwarriorJaeyeol Lee 하스켈로 HTTP 서버를 바닥부터 구현하는 책입니다. https://leanpub.com/sockets-and-pipes

오늘은 Rust를 현업에서 쓰고 있고 또 좋아하는 고교 동창에게 Haskell을 영업했다.

회사에서 거의 10년 동안 운영한 서버를 교체 중이다. 고생 많으셨습니다. 서버님⋯ 새로 오신 서버님에게는 돼지 머리랑 막걸리 준비는 못했지만 절이라도 올려야겠다.

오

빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.

@noxowlSuyeong RHIE @kodingwarriorJaeyeol Lee @gagl3 안 그래도 지난주에 그 바에 대한 얘기가 나오기도 했었습니다!

RE: https://hackers.pub/@diarapin/0195c6a1-c2e0-722d-8b72-136ce75dcf93

"그런 백엔드 기술로 괜찮은가?"

• 대상 : 다양한 기술과 도메인에서의 실무 문제 해결 사례를 통해 실질적인 인사이트를 얻고자 하는 개발자
• 일시 : 2025.04.20(일) 13:00 ~ 17:00 KST
• 장소 : 테크살롱 (서울 강남구 테헤란로 411, 성담빌딩 13층)
• 기타 : 주차 지원이 어려우니 대중 교통 이용을 권장드립니다.

https://www.inflearn.com/course/offline/게으른게발자컨퍼런스-2025

Chrome Built-In AI (EPP)で変更

Canary 136.0.7103.0* 以降、すべての組み込み API に新しいエントリ ポイントがあります。 self.ai.* ではなく、self.* で直接 API を見つけることができるようになりました。静的 create() メソッドを使用して、これらの API をインスタンス化します。

await LanguageModel.create();
await Summarizer.create(); 
await Writer.create();
await Rewriter.create();
await LanguageDetector.create();
await Translator.create();

同様に、静的 availability() メソッドが追加されました。

await LanguageModel.availability();
await Summarizer.availability();
await Writer.availability();
await Rewriter.availability();
await LanguageDetector.availability();
await Translator.availability();

그것 아십니까? 國立國語院(국립국어원)은 漢字(한자) 【茶(다)】에 本音(본음)인 「다」 말고는 慣用音(관용음) 「차」가 있다는 것을 認定(인정)하지 않습니다. 그 代身(대신), 【차】가 이미 固有語化(고유어화)된 낱말이라고 봅니다. 그래서 《標準國語大辭典(표준국어대사전)》에서도 【다례】는 【茶禮(다례)】라고 밝히면서도 【차례】는 【차禮(예)】라고 밝히고 있습니다…

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

내년 React Summit Asia는 싱가포르에서 열리는군요! 기회가 된다면 한번 꼭 가 보고 싶네요 🤩

https://x.com/ReactSummit/status/1906718835668906104

@analoggreenMTG @kodingwarriorJaeyeol Lee 님은 인싸 맞죠…

@xtjuxtapose ActivityPub의 한계는 아닌데 Mastodon을 비롯한 주요 구현들이 지원을 안 하는 건 사실입니다. 음… SVG를 업로드하면 Hackers' Pub 내부에서는 SVG로 보여주고 ActivityPub으로는 래스터화해서 보내는 식으로 편법을 쓸 수는 있을 것 같네요.

https://learnbyexample.github.io/learn_perl_oneliners/one-liner-introduction.html https://learnbyexample.github.io/learn_ruby_oneliners/one-liner-introduction.html

대화형 쉘 환경에서 Perl / Ruby 한줄짜리 스크립트를 짜는 방법을 소개. awk/sed 같은 스크립트를 쓰지 않고도, stdin으로 넘어온 입력을 가독성 있는 코드로 처리하기 좋음.

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…

RE: https://hackers.pub/@xt/2025/stackage-why

여러분 저 이거 추천사 썼어요

https://social.silicon.moe/@aladin_itbook_notifier/114260705422505137

@lionhairdino 저의 영업력 + 물 들어올때 빠른 속도로 노젓는 홍민희님의 피지컬! (아님)

"pub"의 외래어 표기법에 따른 표기는 "펍"이 아니라 "퍼브"입니다. 유성음으로 끝나는 단어라서 "ㅡ"를 붙입니다. 이것은

• log: "록"이 아니라 "로그"
  • blog: "블록"이 아니라 "블로그"
• tag: "택"이 아니라 "태그"
• egg: "엑"이 아니라 "에그"
• dog: "독"이 아니라 "도그"
• mug: "먹"이 아니라 "머그"
• hub: "헙"이 아니라 "허브"
• pad: "팻"이 아니라 "패드"
• lid: "릿"이 아니라 "리드"
• mud: "멋"이 아니라 "머드"

등등, 유성음으로 끝나는 영어 단어에 일관적으로 적용되는 규칙입니다.

보통 외래어 표기법의 규칙이 무시되는 사례를 보면, 규칙이 모호성을 낳는다는 이유로 기피되는 경향이 있는데요. 예를 들어 "seat"와 "sheet"를 구분하려는 욕망으로 인해 /ʃiː/를 "시"로 표기하는 원칙을 깨고 후자를 "쉬트"로 적는 것이 있죠.

그런데 유성음으로 끝나면 "ㅡ"를 붙인다는 규칙은 원어의 유성 음가를 반영하는 동시에, 대체로 모호성을 해소하는 방향으로 표기를 만들어 주는 좋은 규칙입니다. 이 규칙이 없었으면 꼼짝없이

• "dog"와 "dock"이 "독"이라는 동음이의어가 되고
• "pig"와 "pick"도 "픽"이라는 동음이의어가 되고
• "rug"와 "luck"도 "럭"이라는 동음이의어가 되고
• "tag"와 "tack"도 "택"이라는 동음이의어가 되고

영 좋지 않았겠죠.

이 공간에서 그럴 분이 안계실 거라 생각하지만...

만우절이라고 정치나 재난을 주제로 과도한 농담이 등장하지 않았으면 하는 바람이 있습니다.

많은 부분 Hackers' Pub에서 이미 사용하고 있는 패턴들. 그리고 기본 키를 uuid로 했을 때 지역성(locality)가 떨어져서 성능상 손해를 보는 문제는 UUIDv7을 쓰면 해결된다.

RE: https://sns.lemondouble.com/notes/a61hofry16

vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.

Git 관련 유틸리티 중에 이런거 없을까요?

개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;

커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.

한줄 요약

• 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.

프로그래밍 언어 하스켈은 1990년 4월 1일에 처음 나와 올해 35주년이 되었습니다. 오늘이 하스켈 생일이에요. 이거 만우절 농담 아니고 진짜예요.

ADHD의 글쓰기 - 내용이 순서대로 정리되지 않고 여기저기 분산되어있음....... 결론이랑 뱀발이랑 도입부랑 순서가 뒤죽박죽임...

Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.

내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.

1. 신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.

2. GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)

3. 바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput

물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.

인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.

GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.

Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.

참고로 Hackers' Pub은 딱 한 번 뿐이긴 하지만 핸들을 바꿀 수 있답니다.

사실 ActivityPub이나 WebFinger 명세에서는 핸들을 바꿀 수 없다는 제약이 있지는 않아요. 다만 대부분의 ActivityPub 구현들이 액터 ID에 핸들의 일부를 포함시키기 때문에 바꿀 수 없게 되었을 뿐…^[1]

자세한 설명은 Fedify 문서의 Actor identifier and WebFinger username 항목을 읽어보시면 됩니다.

RE: https://serafuku.moe/notes/a6199pgz4v

そういえば今週の金曜日に第8回FediLUG勉強会が有る。すっかり忘れていた。早く発表資料を準備しないと。😱

We're incredibly honored to announce that #Ghost (@indexBuilding ActivityPub) has become a formal sponsor of Fedify through Open Collective!

This is a significant milestone for our project, and we're deeply grateful to @johnonolanJohn O'Nolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.

Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.

If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:

https://opencollective.com/fedify

Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️

@kodingwarriorJaeyeol Lee 성수동 코딩클럽??

언젠가 해커스펍 오프라인 밋업 같은 거 하면 사진기사 겸 봉사자로 놀러가고 싶음

이제 지브리나 교애니 풍의 그림은… “지피티풍”이라고 해야하나… 지브리나 교애니는 이제 어떤 그림을 그려야 하나?

나는 코파일럿(클로드)와 클로드 데스크탑과 클로드 코드와 함께 주로 작업을 하니… 내 코드는 “클로드풍”인가? 나는 이제 어떤 코드를 만들어야하나?

Gitlab은 특히 내가 가장 눈여겨보던 오픈소스 프로젝트 중 하나였는데, 실제로는 Vue가 어떻게 하이브리드로 섞여서 쓰고 있는지 생각하면서 읽는 재미가 쏠쏠함

@ysh염산하 Vue도 Vue 나름대로의 장점이 있습니다. 개인적인 개발경험을 생각해봤을때 Rails/Django/Laravel 같은 전통적인 MVC 프레임워크랑 궁합이 좋거든요.

레트로 웹 마니아 @limeburstJihyeok Seo 가 만든 호스팅 플랫폼 나루(https://naru.pub/)에 나도 2005년 감성의 홈페이지를 하나 깎아서 띄워볼까 함…(2005년인 이유: 내 html, css, js 지식이 20년 전에 멈춰있음)

뉴욕 어딘가에는 컴파일러/DB/웹브라우저 등등 인터널을 까보면서 얘기하는 소셜클럽이 있다. 완전 비슷하게는 아니더라도 해커스펍을 중심으로 밋업을 하는것도 괜찮을지도? 밋업에 참여하는 외부인이 오면 초대장도 그때그때 발급해주는식으로 가고

https://eatonphil.com/nyc-systems-coffee-club.html

해커스펍 DAU 50 가보자고

Polymarket 등의 예측 시장에는 오라클 문제가 있다. 블록체인으로 만들어봤자, 어차피 베팅의 승패를 결정하려면 외부에서 딸깍 해줘야한다. 가령 4월 내에 탄핵이 이뤄질거냐 마냐 같은 게임을 상상하면 된다. 그 딸각하는 사람을 어떻게 믿을수 있냐는 문제가 오라클 문제다.

오라클 문제가 없는 예측 시장이 하나 생각났는데, 바로 수학 문제가 언제 풀릴 것이냐에 대한 것이다. 가령 리만 가설이 앞으로 1,000,000 블록 내에 풀릴지, 또는 P=NP랑 둘 중에 뭐가 먼저 풀릴지 등에 대한 것이다. 여기서 풀리는건 Lean 등으로 작성된 Formal Proof을 통해서 온체인으로 판단한다.

수학자들은 자신이 베팅을 걸어놓고 연구를 열심히해서 돈을 벌 수도 있다. 또 직접 연구를 하지 않더라도 GPU를 사서 자신의 베팅에 유리하도록 연구에 도움을 줄 수 있다. 앞서 그냥 유명하단 이유로 너무 거창한 문제를 예시로 들었는데, 그보다는 더 작고 쉬운 많은 문제들에 대해 이런 식의 경제가 돌아가는걸 상상해보자. 연구에 들어가는 자원 배분이 최적화되지 않을까?

좋은 글 잘 읽었습니다. 글도 잘 쓰시고 코딩도 잘 하시고 부럽습니다. 본문 내용 중 ‘두부와 강철 영수증’이란 표현이 재밌네요. ‘오라클’이라는 전문 용어도 처음 알게 되었습니다. 과거에 하시던 블록체인과 현재 하시는 액티비티펍이 뭔가 탈중앙화라는 공통 분모가 있는 것 같네요.

북적북적 해커스펍

저도 최근 VSC에서 Zed로 넘어오게 됐습니다. 특히 블로그 글을 mdx로 작성하는 입장에서, 플러그인 없이도 mdx 문법과 미리보기를 지원하는 Zed가 정말 마음에 들었어요. 하지만 내장 터미널에서 한글 사용 시 글자가 제대로 표시되지 않고, 일부 작업 시 Zed가 강제 종료되는 문제가 생겨서 최근 이슈를 제보했습니다.

https://github.com/zed-industries/zed/issues/26036

https://github.com/zed-industries/zed/issues/27599

https://hackers.pub/@hongminhee/0195e9c3-2bc8-712a-a38e-aa355335ab0b/shares

@hongminhee洪 民憙 (Hong Minhee) <joke>조용히 눈에 안 띄고 싶었지만 최고관리자의 우렁찬 호명으로 존재가 드러나 버렸습니다. 왜 계정을 만들자마자 글도 쓰기 전에 팔로어가 일곱 명이나 붙었나 했더만 이거였군요. 조용히 눈에 안 띄고 살 권리를 관리자가 빼앗아갔습니다.</joke>