연휴 시작을 맞아 TUI 웹 브라우저 만들기를 해 보았다. 에이전트를 쓸 수 있는 상황에 전적으로 의지해서. 프로젝트 이름은 glance로 했다. 일단은 간단히 읽기 정도만 돌아가도록. 주로 테스트한 곳이 이 곳 Hackers' Pub인데 ActivityPub이 어떻게 돌아가는지 잘 몰라서 처리를 못했다. JSON 보고 링크를 따라가면 되는 것 아닌가 싶기도 하고. 이제 공부해야지.

오늘 대화에서 AI 코딩 에이전트 유행과 관련해서 동료가 했던 가장 좋았던 말은 요즘 개발 너무 재밌고 개발만 하고 싶다

Es bedarf Zeit und Erfahrung, bevor der Arbeiter die Maschinerie von ihrer kapitalistischen Anwendung unterscheiden und daher seine Angriffe vom materiellen Produktionsmittel selbst auf dessen gesellschaftliche Exploitationsform übertragen lernt.

—Karl Marx, Das Kapital, Bd. I, Kap. 13, Abschn. 5

Hi, new followers! Seems like a good time for a re-introduction.

I'm Hong Minhee (洪 民憙), a software engineer based in Seoul. My pronouns are they/them.

I build tools for the fediverse. Fedify is an ActivityPub server framework in TypeScript, Hollo is a single-user microblogging server (what you're reading this on), and BotKit is a framework for making ActivityPub bots. I care a lot about making federation more accessible to developers, which, as my recent JSON-LD rant probably made clear, sometimes means wrestling with parts of the spec I have complicated feelings about.

I'm a free/open source software person through and through, and a socialist, which informs how I think about tech. Lately I've been thinking a lot about LLMs. My position is probably not what you'd expect from either camp: I think the problem isn't the technology itself but the enclosure of the commons. I wrote about this at length here if you're curious: Histomat of F/OSS: We should reclaim LLMs, not reject them.

Outside of software, I have a long-running interest in CJK languages and writing systems. I'm always happy to talk about Chinese characters, Korean orthography, or the weird corners of Unicode where these things intersect.

Nice to meet you all, and thanks for following.

AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다.

1. 가장 비싼 Plan으로 마음껏 써보기 클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요.

프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다.

AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다.

제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다.

리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다.

사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다.

2. 가능성과 한계 인식하기 1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요.

• 내가 하는 일, 내 환경에 대해 재정의하기
• 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기

그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다.

소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다.

AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요.

대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다.

2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요.

이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다.

보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요.

고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

(10달 전에도 지원하는 기능이었다)

지금까지 Hackers' Pub은 반드시 이메일을 통해 로그인 링크를 수신하는 식으로만 로그인이 가능했는데, 사실은 많이 번거로웠죠?

이를 해결하기 위해 Hackers' Pub에 패스키 기능을 추가했습니다. 패스키 추가는 설정 → 패스키 페이지에서 할 수 있으며, 패스키가 등록된 기기 및 브라우저에서는 로그인 페이지에서 자동적으로 패스키를 사용할 것인지 묻는 창이 뜨게 됩니다.

참고로 Hackers' Pub은 패스키 인증을 지원하고 있습니다. ✌️

Hackers' Pub에서 패스키를 지원하길래 등록하고 하는 김에 폰에서 로그인하고 웹앱 아이콘을 설정해 두었다.

얼마 전 Oh My OpenCode이 한창 바이럴 될 때 에이전트 사용법이 재밌다고 느끼면서도 저렇게 누군가 만들어 놓은 걸 그대로 가져다 쓰는 건 별 의미가 없고 스스로가 쓸 도구 모음을 구축하고 (그걸 운영할 수 있는 기술을 가지고) 싶다는 생각을 했는데 Pi가 어느 정도 그것에 대한 실마리를 제공해 주었다고 생각함. (Armin Ronacher가 쓴 Pi: The Minimal Agent Within OpenClaw를 보고 알게 됨.)

컨텍스트 창 크기가 20만 토큰이라는 건 (1대 1로 비교할 수 있는 건 아니고 경우와 사람마다 다르겠지만) 인간 기준으로 어느 정도 느낌을 가지는 크기인지 궁금하다. 한 사람이 가지는 컨텍스트 창은 당연히 무한할 수는 없고 생각보다 그렇게 크지 않을 수도 있다는 얘기도 있다. 예를 들면 개발자도 일할 때 이런 저런 문의와 과제가 쌓이면 “컨텍스트 스위칭” 비용에 대한 불만을 토하기도 하니까.

에이전트가 도구를 다루는 방식에 대한 인식을 동료들과 맞추기 위해 자손킴님의 Tool Use 글을 팀에 공유했고 (👍 을 받음)

비거니즘은
동물이니까, 동물을 죽여서 먹지 않는다가 아니라
농축산업계의 기계적, 착취적 행태에 대한 보이콧에 가깝습니다.

단순히 동물이라서 죽이면 안된다가 아니라 우리는 인간이라는 이유로 인간이 아닌 동물을 비인도적으로 대하는 시스템에 대한 의문을 제기하고 비판하고, 이러한 시스템에서 할 수 있는 보이콧인 그 과정을 거친 동물성 식품을 소비하지 않는 것에 가깝습니다.

오랜만에 블로그에 글을 썼습니다: 〈오픈 소스 開發(개발) 近況(근황)〉.

오래 전

현대 컴퓨터는 계산기라기보다는 복사 기계에 더 가깝다

는 문장을 읽었고 그것에 대해 종종 생각함. 생각해 보면 정말 하는 일이 대개 그런 것에 속한다고 느낌. 어딘가에 있다는 데이터를 모으고 가공하고 정제해서 또 어딘가에 두고 그걸 누군가 가져갈 수 있게 하는 일 끊임 없이 반복함. 데이터의 형식이나 크기나 여러 속성이 다양하고 그래서 다루는 방법과 기술에도 많은 차이가 있지만 어쨌든. 요즘 종종 인용되는 타입 검사는 해결책이 아니라 증상이다(Type Checking is a Symptom, Not a Solution)에 대한 반응들을 보고 직렬화 글과 거기 인용된 인터넷은 디버깅 모드로 돌아가고 있다는 글까지 떠올랐음.

(이 글은 Hackers' Pub에서 제공하는 Markdown 문법 가이드에 익숙해지기 위한 시도로 작성함.)

의외로 잘 안 알려진 도구인데, mise가 정말 좋습니다. 다들 mise 쓰고 행복한 개발 하세요.

https://proofby.ac/mise-for-all/

Perl을 만든 언어학자 Larry Wall이 쓴 글 중에 종종 다시 읽어 보는 글

Human languages therefore differ not so much in what you can say but in what you must say. In English, you are forced to differentiate singular from plural. In Japanese, you don’t have to distinguish singular from plural, but you do have to pick a specific level of politeness, taking into account not only your degree of respect for the person you’re talking to, but also your degree of respect for the person or thing you’re talking about.

Programming is Hard, Let's Go Scripting...

그렇기 때문에 사람의 언어는 당신이 그렇다고 생각하고 있던 것과는 많이 다르다. 영어로 얘기할때는 단수와 복수를 확실히 구분해야만 한다. 일본어에서는, 단수와 복수를 구분할 필요는 없지만, 정중함의 정도를 조절할 줄 알아야 한다. 즉, 상대방에 대한 존경을 표현할 수 있는 정도를 선택해야 하고, 상대방의 입장에서 내가 존중 받아야 하는 정도를 생각해서 말해야 한다.

프로그래밍은 어렵다, 스크립팅의 세계로 가보자...

@hongminhee洪 民憙 (Hong Minhee) @tokolovesme금강토 뵙게 되어 영광이었습니다!

@hongminhee洪 民憙 (Hong Minhee) 감사합니다!

eqn은 markdown-it-texmath에서 생성한 것이고 xss filter에 걸린 것으로 보인다.

베이즈 확률론에서 사후 확률을 다룰 때 베타 분포를 가정한다. 베타 분포의 확률 밀도 함수는 다음과 같다.

여기서 B(α,β)는 베타 함수이며 다음과 같이 정의된다.

해커스펍의 정체… (거대토끼의 맥미니 위에서 돌아가고 있습니다.)

@diarapin금강토 강토님 감사합니다! 반갑습니다!

소프트웨어 개발자들이 자주 틀리는 외래어 표기법.

또 있을까요?

@hongminhee洪 民憙 (Hong Minhee) 민희 님 반갑습니다! 멋진 공간 만들어 주셔서 감사합니다!

고마운 분 덕분에 Hackers' Pub에 가입했다.