@arkjun@hackers.pub · 68 following · 95 followers
中年의 中小企業 開發者, 90年代 Console Gamer. 좋은 하루를 繼續해 나아간다. 좋은 하루가 모이면 좋은 人生이 된다.
韓国人のプログラマー、40代、小学生の息子とゲームするのが幸せ😃💕龍が如く 、ゼルダの伝説、マリオ、ピクミン好き
「いい1日を続ける」
いい1日を続けていけば、いい人生になる！
threads
x
uri.life
GitHub#자기소개 #해커스펍_자기소개 트위터에선 뭔가 무시무시해보여서 개발자 트친소도 못하는 1인이었지만,, 여기서 살며시 해봅니다
앞으로 개발이나 정보기술 관련 쓸 거리가 생기면 여기다 우선 끄적이는 걸로.
Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.
I work full-time on 
@sovtechfundSovereign Tech Agency. I'm also the creator of 
, a single-user ActivityPub microblog; 
@botkitBotKit by Fedify 
, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.
I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!
安寧하세요! 저는 서울에 살고 있는 30代 後半의 오픈 소스 소프트웨어 엔지니어 洪民憙입니다. 兩性愛者(bisexual)이자 논바이너리(non-binary)이며, 自由·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(fediverse)의 熱烈한 支持者이기도 합니다.
STF(@sovtechfundSovereign Tech Agency)의 支援을 받아 TypeScript用 ActivityPub 서버 프레임워크 , ActivityPub 봇 프레임워크 @botkitBotKit by Fedify , 소프트웨어 開發者를 위한 聯合宇宙 플랫폼 Hackers' Pub, JavaScript·TypeScript用 로깅 라이브러리 LogTape 等의 製作者이기도 합니다.
東아시아 言語(이른바 CJK)와 Unicode에도 關心이 많습니다. 이 計定에서는 主로 英語로 포스팅하지만, 때때로 日本語나 國漢文混用體 韓國語로도 씁니다. 聯合宇宙에 오게 된 動機 中 하나가 바로 國漢文混用體로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語, 英語, 日本語, 아니면 漢文으로도 말을 걸어주세요!
[Hackers Pub Android 비공개 테스트] 연합우주 여러분 안녕하세요. 구글 Playstore에 앱을 공식적으로 출시하기에 앞서, 비공개 테스터를 모집하고자 합니다. 여러분의 관심이 Hackers Pub 안드로이드 앱 출시에 큰 도움이 됩니다.
자세한 건 구글 폼을 참고해주세요. 감사합니다.
https://docs.google.com/forms/d/e/1FAIpQLSeu9lB1KFGRsKLrjwwOJqQo68DFoBqRPG2q2poKjjXEBBWuNg/viewform
Juntai Park shared the below article:
Dalinaum @dalinaum@hackers.pub
피처 폰부터 Android까지 모바일 개발의 변천사를 거쳐 현재 Kotlin을 주력으로 사용하는 숙련된 개발자의 진솔한 기록입니다. 기술적 커리어에 대한 깊은 고민과 더불어 영화, 게임, 자동차 드리프트 등 다채로운 취미를 즐기는 저자의 입체적인 일상을 담고 있습니다. 오랜 실무 경험을 가진 개발자의 인간적인 면모와 삶의 궤적을 통해 독특한 인사이트를 얻을 수 있습니다.
Read more →국세청, 세무대리인: 회계 프로그램 뭐 쓰시나요?
나: 우리 단체는 hledger 로 Plain Text Accounting 합니다.
국세청, 세무대리인: (예상 반응) ??? 뭘로 뭘 하신다구요?
Another day, another supply chain attack, this time Axios: https://github.com/axios/axios/issues/10604
Makes me glad I'm lazy and intentional about dependency updates. But it's a worrying trend. Soon we'll be tracking these things by the hour.
《標準國語大辭典》 MCP 서버를 만들었습니다.
旣存에도 《標國大》 MCP들이 있긴 한데, 그냥 標題語랑 뜻풀이만 덜렁 주는 데다가, 每番 stdict.korean.go.kr 서버에 要請하는 式으로 作動해서 레이트 리미트에 걸리더라고요. 제가 만든 건 아예 全體 辭典 데이터를 맨 처음에 받은 다음에 그걸 SQLite에 넣고 照會합니다.
제가 일하는 팀에서 채용중입니다. https://careers.linecorp.com/ko/jobs/2964/
회사 이름이 LINE 으로 시작하지만 메신저는 안만듭니다. 국내외 선물 시장에서 거래하는 자동매매 전략과 그 전략을 서빙하는 플랫폼을 만듭니다. Rust, FPGA, AI 같은 키워드를 나열할 수 있긴 한데, 그냥 코딩 잘하시는분이면 좋겠습니다. 시장은 몰라도 됩니다. 근데 혼자 코딩 잘하는거 말고 AI랑 같이도 잘 코딩해야 합니다.
저는 이런 사람입니다 https://github.com/youknowone/
같이 일할 
함께 일하고 싶으신 분을 찾습니다.
Juntai Park shared the below article:
Haze @nebuleto@hackers.pub
외부에서 SSH를 통해 원격 작업을 수행할 때 연결 끊김에 대비한 세션 유지 도구로 Zellij를 도입한 경험을 소개합니다. Rust로 작성된 터미널 멀티플렉서(terminal multiplexer)인 Zellij는 tmux에 비해 진입 장벽이 낮고, 화면 하단에 실시간 단축키 가이드를 제공하여 매우 직관적인 사용이 가능합니다. 특히 기존에 사용하던 Ghostty 터미널 에뮬레이터의 단축키 설정을 Zellij로 이식함으로써, 익숙한 머슬 메모리를 그대로 유지하면서도 세션 공유와 화면 분할 기능을 극대화하는 방법을 상세히 다룹니다. KDL 포맷을 이용한 간편한 설정 방식과 zjstatus 플러그인을 활용한 상태 바 커스터마이징 과정은 물론, 비활성 탭의 알림 문제와 같은 기술적 한계와 그에 대한 실질적인 우회책도 함께 제시합니다. 이 글은 터미널 에뮬레이터에 종속되지 않는 독립적인 작업 환경을 구축하고, 강력한 세션 관리 기능을 통해 터미널 사용 경험을 한 단계 높이려는 개발자에게 유용한 인사이트를 제공합니다.
Read more →Juntai Park @arkjun@hackers.pub
Warpの試用を機にGhostty、Helix、Zellij、fishへと開発環境を刷新し、モダンなスタックへの移行による作業効率の改善が進んでいます。これに合わせて、これまで複数のツールに分散していたドキュメント管理をObsidianへ集約し、AIとの対話ログや計画ファイルをMarkdownベースで一括管理する「第二の脳」を再構築しました。豊富なプラグインエコシステムや今後のCLIサポートへの期待に加え、特にモバイル環境まで含めた自由なフォントカスタマイズが、日々の執筆や情報整理のモチベーションを大きく高めています。ツール間の細かな不具合を許容してでも得られる、パーソナライズされた快適なワークフローは、個人の生産性を最大化するための重要な基盤となります。
Read more →
tmux → zellij , zsh → fish, vi → hx, iTerm2 → Ghostty 로 바꿨다.
찍먹만 해보려고 했는데 만족도가 높아 업무용 맥은 완전히 전환했고, 개인용 맥은 짬날 때 천천히 바꿀 예정.労働が非人間的になるのは「疎外」と呼ばれるけど、先日洪民憙さんの記事を読んだばかりだった。
Marxは『資本論』第一巻で、イギリスのラッダイト運動をこう評した。
労働者が機械そのものと機械の資本主義的利用とを区別し、したがって物質的生産手段そのものではなく、その社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。
機織り機を打ち壊した労働者たちの怒りは正当だった。方向が間違っていただけだ。問題は機械ではなく、機械をめぐる資本主義的社会関係だった——機械が労働時間を短縮するどころか延長し、労働者を解放するどころか機械の付属物にしてしまうのは、機械の本性ではなく、機械を配置する方式の問題だった。Marxは彼らを嘲笑したのではなく、闘争が成熟していく過程を叙述したのだ。
https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/
Acting materialistically in an imperfect world: LLMs as means of production and social relations
This is a follow-up to last month's Histomat of F/OSS: We should reclaim LLMs, not reject them . Cory Doctorow celebrated the sixth anniversary of Pluralistic…
writings.hongminhee.org · Hong Minhee on Things
Link author: 
洪 民憙 (Hong Minhee) 
@hongminhee@hollo.social
1Password 가격이 올라간다는 소식이...
https://9to5mac.com/2026/02/24/1password-announces-big-price-increases-coming-next-month/
@gaeulbyul가을별
저도 오늘 가격인상 공지 메일을 받았네요. 월급만 빼고 다오르는 느낌 무엇. 😂
Current vs New Pricing:
Current price: $35.88 USD / year
New price: $47.88 USD / year
The new price will take effect at your next renewal, provided it’s on or after March 27, 2026. Those occurring prior to March 27, 2026, will continue at the current pricing until your next renewal.
Action needed: Please go to my.1password.com/billing to register your approval. If you do not provide consent by your next renewal date on or after March 27, 2026, your subscription will automatically be cancelled at time of your next renewal.
Fedify 2.0.0 is here!
This is the biggest release in Fedify's history. Here are the highlights:
@fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.@fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.@fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).orderingKey option solves the “zombie post” problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changes—please check the migration guide before upgrading.
Full release notes: https://github.com/fedify-dev/fedify/discussions/580
Fedify 2.0.0을 릴리스했습니다!
Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:
@fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.@fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.@fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.
이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!
브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.
전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580
Juntai Park shared the below article:
Haze @nebuleto@hackers.pub
SheetKit은 기존 Node.js 엑셀 라이브러리들의 성능 한계와 기능 제약을 해결하기 위해 Rust로 개발된 고성능 스프레드시트 라이브러리입니다. 저자는 대량의 데이터 처리와 동적 템플릿 생성을 위해 Rust 코어 기반에 napi-rs를 활용한 Node.js 바인딩 구조를 설계했으며, 코딩 에이전트와의 긴밀한 협업을 통해 단 일주일 만에 초기 배포부터 v0.5.0 릴리스까지 달성했습니다. 특히 자바스크립트 객체 생성에 따른 가비지 컬렉션(garbage collection) 압박을 줄이기 위해 이진 버퍼(binary buffer)를 통한 데이터 전송 방식을 도입하고, 지연 로딩(lazy loading)과 스트리밍 리더 기능을 통해 대용량 파일 처리 효율을 극대화했습니다. 벤치마크 결과 기존 라이브러리 대비 압도적인 메모리 절감과 속도 향상을 보여주었으며, 특정 쓰기 시나리오에서는 V8 엔진의 최적화 덕분에 Rust 네이티브보다 빠른 성능을 기록하기도 했습니다. 현재 164개의 수식 함수와 43개의 차트 타입을 지원하며 실제 업무 현장에 성공적으로 적용 중인 SheetKit은 Node.js 환경에서 대규모 엑셀 데이터를 다루는 개발자들에게 강력하고 효율적인 솔루션을 제공합니다.
Read more →TypeScript 6.0 beta is now published!
This release brings
- inference improvements for functions
- updates to package.json 'imports'
- Temporal APIs
- alignments for the upcoming TypeScript 7.0
- & more!
Try it today!
https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/
지난 주말부터 열심히 토큰을 팍팍 태워 만든 TypeScript/Rust용 엑셀 라이브러리 SheetKit, 방금 0.4.0를 배포했습니다.
문서 퀄리티가 아직 좋다고는 말을 못해도 API 레퍼런스와 문서 웹도 생겼고, 단순한 값 읽기/쓰기를 넘어 복잡한 기능들도 많이 추가되었습니다. 이제 폭발적인 구현보다는 적당한 스피드로 문서의 완성도를 높이고 WebAssembly나 Bun/Deno/Python 등에 대한 바인딩 등을 고민해볼 계획입니다. 문서의 완성도도 좀 어느 정도 올라간다면 이리저리 SheetKit을 소개하는 정식 글도 한번 여기저기에 올려보려고 합니다.
이미 Node.js쪽 binding은 열심히 개밥먹기하고 있는 중인데, Rust나 Node.js 환경에서 엑셀 파일을 다룰 일이 있는 분들은 한번 써보시고 이슈나 피드백을 남겨주시면 너무 좋을 것 같습니다.
Node.js에서 SheetKit은 다른 라이브러리에 비해 거의 모든 벤치마크 테스트에서 성능 우위를 보였습니다. 웹 문서에는 SheetKit이 어떻게 메모리를 덜 사용하고 Node.js 바인딩에서 영역 전환 시의 오버헤드를 줄였는지도 정리되어 있습니다.
zellij 를 MacOS + Ghostty 조합에서 사용할 때 한글 폴더명의 깨짐현상이 있다.
(초성만 노출되는 문제) https://github.com/zellij-org/zellij/issues/3148
Claude Code (Opus 4.6 Model) 의 도움을 받아 수정했고 로컬에서 빌드해서 쓰고 있다.
PR 도 보냈는데, 근본적인 해결책은 되지 못해, 커밋이 병합되지는 못했다.
그래서 결론 - 이 커밋은 나만 쓰게 되었다. 😂
Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)
https://github.com/daumPostcode/QnA/issues/1498
GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.
아래 내용도 참고하면 좋을 것 같습니다.
기존 도메인(t1.daumcdn.net)도 당분간 계속 사용 가능하지만, 가능한 경우 신규 도메인(t1.kakaocdn.net) 사용을 권장드립니다.
...
daum.Postcode는 강제 변경되지 않으며, 가능한 한 오랜 기간 동안 호환성 유지를 목표로 지원할 예정입니다.
다만, 신규 개발 및 유지보수 관점에서 점진적으로 kakao.Postcode 사용을 권장드립니다.
Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)
https://github.com/daumPostcode/QnA/issues/1498
GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.
백만년만에(?) 터미널 프로그램을 iTerm2 에서 Ghostty 로 바꿨다.
日本의 TypeScript 컨퍼런스인 TSKaigi 2026이 5月 22日(金)–23日(土)에 東京에서 開催된다고 합니다. 함께 가실 韓國 분 계실까요?
一旦 저랑 
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
님이 같이 가실 것 같습니다.
LLM으로 문서 뽑아낼 때 "위키피디아 하드 유저(Highly Active User) 겸 테크니컬 라이터"라고 페르소나 주입하니까 문서 질이 다르다
AI/LLM에 對해 奴隸制를 聯想시키는 表現을 쓰는 것에 拒否感이 있다. 아니, AI/LLM이 아니라 어떤 對象에 對해서든.
@hongminhee洪 民憙 (Hong Minhee) 앗! 기존 라이브러리 업데이트 하시나요, 새로운 프로젝트인가요?ㅎ
오랫동안 Grafana 와 Prometheus 의 조합으로 서버 모니터링을 해왔는데, (거기에 Uptime Kuma 까지)
뭔가 바꿔볼 마음이 들어서, 올해 하게 되는 프로젝트에는 SigNoz 와 xyOps 를 적용해볼까 싶어서 살펴보고 있다. (바쁘거나 우선순위에서 밀리면 못하겠지만)
Been thinking a lot about 
@algernonalgernon, deployer of builds, builder of jank, fan of junk, and only junk (allegedly)'s recent post on FLOSS and LLM training. The frustration with AI companies is spot on, but I wonder if there's a different strategic path. Instead of withdrawal, what if this is our GPL moment for AI—a chance to evolve copyleft to cover training? Tried to work through the idea here: Histomat of F/OSS: We should reclaim LLMs, not reject them.
Histomat of F/OSS: We should reclaim LLMs, not reject them
A few days ago I read a blog post titled On FLOSS and training LLMs . It captures well the frustration spreading through the free and open source software…
writings.hongminhee.org · Hong Minhee on Things
Link author: 洪 民憙 (Hong Minhee) @hongminhee@hollo.social
AI 企業이 F/OSS 코드로 LLM 訓練하는 걸 막을 게 아니라, 訓練한 모델을 公開하도록 要求해야 한다고 생각합니다.
撤收가 아니라 再專有! GPL이 그랬던 것처럼요.
訓練 카피레프트에 對한 글을 썼습니다: 〈F/OSS 史唯: 우리는 LLM을 拒否할 게 아니라 되찾아 와야 한다〉(한글).
Histomat of F/OSS: We should reclaim LLMs, not reject them
A few days ago I read a blog post titled On FLOSS and training LLMs . It captures well the frustration spreading through the free and open source software…
writings.hongminhee.org · Hong Minhee on Things
Link author: 洪 民憙 (Hong Minhee) @hongminhee@hollo.social
@arkjunJuntai Park 가입하려고 하는데, “Email already exists or invalid”라는 오류가 납니다. 이메일 주소를 다른 걸로 바꿔봐도 그렇네요.
@hongminhee洪 民憙 (Hong Minhee) 앗. 피드백 감사드립니다. 오류 수정했습니다! (Google 로그인을 넣으면서 버그가 있었네요.)
내 구독 목록을 보는 SubList Me 를 소개합니다.
대 AI 시대라, 저도 AI 에이전트와 함께 개인적으로 장난감을 만들어 보았습니다.
Cloudflare에서 도메인을 샀고, 서버리스로 Pages와 Workers를 사용합니다.
Nextjs, Hono를 사용하고 있습니다.
선택UI 는 Installkit에서 영감을 받았습니다.
Hackers.pub 에 제일 먼저 공개하고 싶었고, 그러므로, 최초 공개입니다. 😅
많이 부족하고 아직 버그나 개선의 여지도 많지만 개밥먹기하면서 수정해 나가려고 합니다.
소개 페이지: https://www.sublistme.com/
서비스 링크: https://app.sublistme.com/
소스는 요기
（わかる人にはわかると思うけど）最近は、機能追加や修正において、コードを直接いじるよりも、修正計画をしっかり書いてからコードエージェントに任せることが増えている。
手戻りを減らすためにも、修正計画はできるだけ具体的に書くことを意識している。テスト対応まで含めて指示することも多い。
もちろん、最終的なコードの検証とテストは自分で行う。
공익글: VS Code에서 작업하던 파일이 유실됐다면 가장 먼저 Timeline부터 확인합시다. 바로 오늘도 이 방법으로 삭제된 코드를 복구한 지인분이 계시며...
LLM을 위한 cat, lat의 프로토타입을 완성했습니다. 당장은 Nix 유저만 쉽게 설치할수 있습니다. 다른 패키지 매니저 지원을 비롯해 빠르게 개선하겠습니다.
Juntai Park shared the below article:
고남현 @gnh1201@hackers.pub
실리콘밸리를 포함해 수십 개의 회사에서 동시에 근무하며 최고의 평가를 받은 한 개발자의 사례는 현대 소프트웨어 개발 조직이 직면한 본질적인 문제를 시사합니다. 그는 실제로 코드를 거의 작성하지 않았음에도 불구하고 팀의 방향성을 설정하고 기술적 의사결정을 지원하며 복잡한 구조를 정리하는 컨설턴트적 접근으로 생산성을 극대화했습니다. 이는 많은 기업이 채용 공고를 통해 단순히 코드를 작성할 기술자를 찾지만, 실제 현장에서는 무엇을 만들어야 할지 정의하고 불필요한 작업을 제거해 줄 판단력을 갖춘 인재를 더 절실히 필요로 한다는 사실을 보여줍니다. 결국 가장 가치 있는 코드는 작성하지 않아도 되는 코드이며, 개발자의 진정한 역량은 단순한 구현 능력을 넘어 복잡한 문제를 정의하고 책임감 있게 결정을 내리는 용기에서 나옵니다. 이 사례는 기술 중심의 사고방식에서 벗어나 조직 내의 구조적 모순을 해결하고 실질적인 비즈니스 가치를 창출하는 것이 현대 소프트웨어 산업에서 얼마나 중요한지를 일깨워줍니다.
Read more →LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]](/float-https-media.hackers.pub/note-media/17646c5d-3f9d-472b-9d56-dd34006ad291.webp)
프로젝트에 Deno와 pnpm을 함께 쓰고 있었는데, mise의 태스크 기능을 사용해서 개발에 필요한 커맨드들을 일원화했더니 속이 편하다.
Wrote about designing type-safe sync/async mode support in TypeScript. Making object({ sync: syncParser, async: asyncParser }) automatically infer as async turned out to be trickier than expected.
https://hackers.pub/@hongminhee/2026/typescript-sync-async-type-safety
複数のパーサーを合成するとき、一つでも非同期なら結果も非同期になる——これをTypeScriptの型レベルで表現するのが意外と難しかった。Optiqueでの設計過程を書きました。
GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:
export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.
GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:
export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.
오늘은 OpenCode에서 공짜로 제공하길래 MiniMax M2.1로 코딩을 좀 해봤다. 몇 시간 정도 해본 느낌으로는 GLM-4.7보다는 훨씬 나았고, 체감상으로는 대충 Claude Sonnet 4와 비슷한 정도로 말귀를 잘 알아듣는 느낌이었다. 컨텍스트 윈도가 긴 것도 장점이었다. 다만, 컨텍스트가 좀 길어지니까 끝도 없이 삽질을 반복하게 되어서, 그 쯤에서 모델을 GPT-5.1 Codex Max로 바꿔서 진행했다. GPT-5.1 Codex Max로 삽질 구간 벗어난 뒤에 금방 다시 MiniMax M2.1로 돌아와서 계속 코딩을 했고, 전반적으로 싼 값을 감안하면 굉장히 좋다고 느꼈다.
요즘에는 평소에 Claude Opus 4.5를 주력으로 사용하니까, 아무래도 비교가 될 수밖에 없었는데:
any 타입을 쓰지 말라고 했음에도 무시하고 사용한다든가. Claude 계열 모델들에서는 이런 건 잘 못 겪는다.일단은 OpenCode에서 공짜로 제공하는 동안은 좀 더 써 볼 생각이다. 돈 내고 쓸 생각이 있냐 하면, 그건 좀 고민이 된다. 코딩 요금제를 보면 5시간에 300 프롬프트짜리가 월 20불 정도 된다. 지금은 Claude Max 요금제를 쓰고 있는데, 아무래도 부담이 좀 되긴 해서, Claude Pro로 내리고 MiniMax를 섞어서 쓰면 어떨까 생각만 해보고 있다.
2026年에도 새해 福 많이 받으세요!
明けましておめでとうございます！2026年もよろしくお願いいたします。
새해 복 많이 받으세요. 2026년에도 늘 좋은 일만 가득하시기를 바랍니다.
あけましておめでとうございます。 2026年も素敵な一年になりますように。
新年快乐！愿2026年带给您满满的好运与美好。
Happy New Year. May 2026 bring you happiness, success, and many wonderful moments.
2026年에도 새해 福 많이 받으세요!
한 해를 마무리하는 글을 블로그에 썼습니다: 〈聯合宇宙와 함께 한 2025年〉(한글 專用文은 이쪽). 題目 그대로 聯合宇宙와 함께 했던 저의 한 해를 되돌아 보는 글입니다. 聯合宇宙 德分에 많은 因緣과 이어지게 되어서 感謝하게 생각합니다.
Juntai Park @arkjun@hackers.pub
최근 인프라 구축에 Terraform과 Kubernetes를 도입하며 얻은 실질적인 운영 경험과 통찰을 다룹니다. Terraform을 통한 코드 기반의 인프라 관리(Infrastructure as Code)는 변경 이력 추적과 재사용성을 높여 휴먼 에러를 대폭 줄여주었으며, Kubernetes는 자동화된 배포와 셀프 힐링 기능을 통해 운영 부담을 체감될 정도로 낮추어 주었습니다. 특히 AI를 설계와 디버깅의 보조 도구로 활용해 복잡한 기술적 러닝 커브를 효과적으로 극복한 과정이 인상적입니다. 서비스 규모에 따른 적절한 도구 선택과 도입 시점에 대한 현실적인 조언은 인프라 현대화를 고민하는 이들에게 실무적인 가이드라인을 제공합니다.
Read more →Just had someone leave feedback on my F/OSS project saying “maybe that's fine if a product is focused on your Chinese community.”
I'm Korean. Every single piece of documentation is in English. There's nothing in Chinese anywhere in the project.
This kind of microaggression is exhausting. As a non-white maintainer, you deal with these assumptions constantly—people who feel entitled to your labor while casually othering you based on your name.
It chips away at your motivation. It makes you wonder why you bother.
https://github.com/dahlia/optique/issues/59#issuecomment-3678606022
가족들이 밋업 굿즈를 탐내는 건 처음이다. 다음번엔 앵그리 버전 한 표!
Juntai Park shared the below article:
고남현 @gnh1201@hackers.pub
React2Shell(CVE-2025-55182) 취약점은 React와 Next.js 환경에서 발생하는 심각한 역직렬화(Deserialization) 보안 약점을 다룹니다. 이 취약점은 JSON과 자체 규격인 Flight 포맷을 처리하는 과정에서 발생하며, 공격자가 JavaScript의 프로토타입 오염(Prototype Pollution)을 통해 객체의 성격을 임의로 변경하고 원격 코드 실행(RCE)까지 가능하게 합니다. 역직렬화 과정은 본래 자료형에 엄격하지 않고 특정 기호가 실행 신호로 작동할 수 있어 보안상 취약할 수 있는데, React2Shell은 특히 Promise 객체의 속성을 악용하여 악성 코드를 트리거하는 방식을 취합니다. 실제로 취약한 서버에 Mirai 봇넷 계열의 악성코드가 주입되어 서버가 디도스(DDoS) 공격 도구로 악용되는 사례가 발견되기도 했습니다. 이를 방어하기 위해서는 Next.js를 보안 패치가 적용된 최신 버전으로 업데이트하거나 Vercel에서 제공하는 전용 패치 도구를 활용해야 하며, 필요시 웹 방화벽(WAF) 규칙을 강화하는 조치가 필요합니다. 이 글은 현대 웹 생태계에서 역직렬화 공격의 위험성과 구체적인 대응 방안을 제시하여 안전한 애플리케이션 운영을 위한 핵심적인 가이드 역할을 합니다.
Read more →내 로컬에서는 됐는데. 라는 말을 20년 넘게 사용할 줄, 20년전의 나는 (당연히) 몰랐겠지. #중년의개발자
最近、社内の（自社）メッセンジャーの利用をやめ、Discord を主な協業ツールとして活用している。 Webhook 用のチャンネルが一つずつ増えるにつれて活用度と満足度も高まり、全体としてかなりうまく使えていると感じている。
Slack も優れたツールではあるが、無料プランでは90日を過ぎたメッセージを確認できない点がやや残念だ。そのため、現時点の会社の状況で、Discord よりも Slack を有料で使うだけの明確なメリットがあるかというと、正直なところ判断が難しい。
一方で悩ましいのは、社外、とくに大企業の顧客との協業において、Discord を公式な協業ツールとして提案しづらい点である。ゲーミング向けメッセンジャーというイメージが依然として強く、積極的に推し出すには少し躊躇してしまう。
とはいえ、オープンソースや開発者向けのコミュニティでは、以前から Discord がかなり活発に使われている印象もある。(これは、ひとまず韓国に限った話かもしれない。)
