NATが諸悪の根源（過激）
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 1014 following · 720 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub! My main account is at 
@hongminhee洪 民憙 (Hong Minhee) 
.
Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다. 제 메인 계정은: @hongminhee洪 民憙 (Hong Minhee) .
Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。私のメインアカウントは「@hongminhee洪 民憙 (Hong Minhee) 」に。
Website- hongminhee.org
GitHub- @dahlia
Hollo- @hongminhee@hollo.social
DEV- @hongminhee
velog- @hongminhee
Qiita- @hongminhee
Zenn- @hongminhee
Matrix- @hongminhee:matrix.org
X- @hongminhee
IPv6가 30주년을 맞았지만 여전히 세계를 장악하지 못한 이유
------------------------------
- 1995년 등장한 IPv6 는 32비트에서 128비트로 확장된 주소 체계를 통해 *인터넷 주소 고갈 문제* 를 해결하려 했음
- 그러나 *IPv4와의 비호환성* , *기능적 차별성 부족* , *NAT의 확산* 등으로 인해 전환이 지연됨
- 전문가들은 *배포 비용과 복잡성* , *ROI 부족* , *성능 불일치* 등이 여전히 주요 …
------------------------------
https://news.hada.io/topic?id=25533&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.
@hongminhee洪 民憙 (Hong Minhee) 해커즈 퍼브에서 "그냥" 댓글을 막을 수 있게 해 주셨으면 합니다.
- 어떤 글에 대해서 댓글을 안 받고 싶다면, 안 받을 권리는 글쓴이에게 있어야 한다고 생각합니다.
- 댓글은 '내' 글을 남에게 보여줄 때 반드시 함께 노출되어 버리는데, '내'가 전혀 통제할 수 없습니다.
- 댓글 그 자체가 사실 별로 책임 있는 소통에 적합한 수단이 아니라고 감히 주장하겠습니다. 한국어 언어 생활만 봐도, '악플'은 있어도 '악글'이나 '악영상' 등은 없습니다. 유독 댓글에 대해서만 따로 '악플'이라는 조어가 등장할 만큼, 댓글 쪽이 가장 더럽다는 것을 언중도 인식하고 있는 것입니다. 이것은 댓글에 대해서만 '남의 집'이라는 인식이 적용되는 인간 심리 때문입니다. 실제로 네이버 뉴스의 헤비 악플러들을 보면, 자기 블로그를 만들어서 그 온갖 입에 담지 못할 모욕적인 말을 늘어놓는 사람은 사실상 없다시피 하고, 꼭 댓글에만 그 짓을 하고 다니죠. 자기 집 안방, 자기 집 대문, 자기 간판, 자기 얼굴에다 똥을 싸기는 싫은 거죠. 즉 이것은 댓글 그 자체의 매체적 특성에서 온다는 것입니다.
- 물론 모든 분들이 "댓글 그 자체가 나쁜 문명" 이라는 제 의견에 동의하실 필요는 없습니다만, 적어도 댓글 거부권은 개별적으로 존중되는 것이 맞다고 생각합니다. 그리고 많은 플랫폼이 이미 이것을 지원하고 있습니다(트위터, 유튜브, 네이버 블로그 등).
현재 액티비티퍼브 프로토콜에서 '댓글 안 받기' 관련 지원이 아직 부족한 것으로 보이기는 합니다. 하지만, 이 문제는 어차피 프로토콜에서 완벽한 해법을 도출할 수 없습니다. 예를 들어 악의적인 인스턴스가 내 글을 가져가서 악플을 주렁주렁 달며 조리돌림을 하려 한다 해도, 기술적으로 그걸 사전에 원천 차단할 방법은 없겠죠. 내가 '댓글 안 받기' 설정을 하든 말든, 저쪽 인스턴스에서 무시할 수 있습니다.
더 나아가 생각해 보면, 내 글을 연합우주도 아닌 그냥 다른 '사이트'에서 링크 가져간 뒤에, 자기들끼리 조롱하고 능욕하는 일도 얼마든지 있을 수 있는데, 그것도 글을 '공개'하는 이상 원천적으로 막는 것은 불가능할 것입니다.
다만 댓글이 '내' 글의 하단에 직접 박히는 것은 '내'가 거부할 수 있어야 한다고 생각합니다. 따라서 완벽한 해법을 기다릴 것이 아니라(어차피 불가능하므로), 그냥 지금 당장 '내' 글의 하단에 댓글이 달리는 것을 막는 간단한 구현부터 적용하는 것이, 맞는 접근이라고 생각합니다. 해커즈 퍼브에 이것을 구현해 주셨으면 합니다.
다만 현실적인 상황을 말씀드리자면, Hackers' Pub은 제가 전업으로 개발하는 프로젝트가 아니다 보니, 지금 당장 이 기능을 최우선으로 구현하기가 어렵습니다. (실은 이 기능만 그런 게 아니라 Hackers' Pub 개발 전반에 제가 참여를 거의 못하고 있습니다—오히려 다른 분들께서 기여를 해주고 계세요.) 이 기능을 안 하겠다는 게 아니라, 바로 지금은 어렵다는 점 양해 부탁드립니다. GitHub 이슈로 남겨주시면 로드맵에 참고하겠습니다.
한편 Hackers' Pub은 오픈 소스 프로젝트이기도 해서, 혹시 직접 구현에 관심이 있으시다면 해당 PR은 최우선으로 리뷰하겠습니다. 코드베이스가 익숙하지 않으시더라도 어디서부터 손대면 좋을지, 어떤 식으로 구현하면 될지 등 제가 적극적으로 도와드릴 수 있으니 편하게 말씀해 주세요.
Using Nano Banana Pro, I composited an image to make it look like the cute dinosaur from the Fedify logo was standing in front of the ULB (Université libre de Bruxelles) building in Brussels, where FOSDEM is held.
This time, I tried writing a prompt to draw an illustration of the mascots from the Mastodon, Lemmy, Fedify, Misskey, and Akkoma projects all getting along together.
Using Nano Banana Pro, I composited an image to make it look like the cute dinosaur from the Fedify logo was standing in front of the ULB (Université libre de Bruxelles) building in Brussels, where FOSDEM is held.
미지의 영역을 프로토타이핑할때는 Sonnet으로 충분한듯... Opus 깊생하게 해봤자 토큰만 더먹는다
클로드 맥스 5x 월 16만원... 10만원만 됐어도 눈감고 지르는건데
洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-3 DHCP
자손킴 @jasonkim@hackers.pub
DHCP(Dynamic Host Configuration Protocol)는 IP 주소와 서브넷 마스크 등 네트워크 접속에 필수적인 설정을 자동으로 배포하여 관리 효율성을 극대화하는 핵심 프로토콜입니다. 이 글은 수동으로 관리하는 정적 할당과 자동화된 동적 할당의 차이점을 비교하며, UDP 기반의 메시지 구조와 Discover부터 ACK로 이어지는 네 단계의 처리 과정을 상세히 다룹니다. 특히 할당받은 주소를 유지하기 위한 임대 시간(Lease Time) 관리와 갱신 메커니즘을 통해 네트워크 안정성이 어떻게 유지되는지 설명합니다. 또한 단순한 주소 할당을 넘어 옵션 필드를 활용한 네트워크 부팅(PXE) 기술을 소개하며, DHCP가 현대 인프라 자동화의 강력한 기반이 되는 과정을 보여줍니다. 이 포스팅은 네트워크의 기본 동작 원리부터 실무적인 확장성까지 폭넓은 인사이트를 제공하여 기술적 이해도를 한 단계 높여줄 것입니다.
Read more →洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-4 SSL 오프로드
자손킴 @jasonkim@hackers.pub
TLS(SSL) 오프로드는 웹서버의 CPU 자원을 소모하는 암복호화 작업을 로드밸런서(Load Balancer)와 같은 전용 장비에 위임하여 애플리케이션의 처리 효율을 극대화하는 기술입니다. 중앙집중식 인증서 관리를 통해 운영 부담을 줄이는 장점이 있지만, 로드밸런서 통과 후 내부망에서 데이터가 평문으로 전달되는 보안 취약점이 발생할 수 있습니다. 특히 내부망이 항상 안전하다는 고정관념을 깨고 '결코 신뢰하지 말고 항상 검증하라'는 제로 트러스트(Zero Trust) 원칙에 따라, 상호 TLS(mTLS)를 활용한 마이크로 세그멘테이션의 중요성이 대두되고 있습니다. 하지만 L7 로드밸런서나 웹 애플리케이션 방화벽(WAF)이 HTTP 헤더와 경로를 분석하여 정교한 라우팅과 공격 탐지를 수행하려면 패킷의 내용을 확인할 수 있는 TLS 종료 과정이 여전히 필수적입니다. 이 포스팅은 성능을 위한 오프로드와 보안을 위한 재암호화 사이의 기술적 접점을 설명하며, 가시성과 안전성을 동시에 확보해야 하는 현대적인 네트워크 인프라 설계의 핵심적인 인사이트를 제공합니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) I certainly like the focus on growth not punishment. It really aligns with the brief discussion in the " Alternative models of content moderation" sectino of Sarah Gilbert's Towards Intersectional Moderation: An Alternative Model of Moderation Built on Care and Power of justice-based models of moderation that "foster education, rehabilitation, and forgiveness" (as opposed to the more punitive and carceral models of moderation that are the norm in commercial social networks).
My impression is that most fedi moderation teams don't actually notify the reporters about what actions are or aren't taken. Some of that is due to software limitations -- if the report is forwarded from another instance, I'm pretty sure you don't even know who the reporter is (and the Mastodon moderator UX doesn't as far as I know directly support two-way communications, instead you. have to DM the user from the moderator account; and) . Just as importantly, though, reporters sometimes get upset and escalate if action isn't taken. If the original report is malicious, as part of a harassment campaign against the target, this sometimes leads to the moderators getting harassed as well.
Of course it's very frustrating to report something and never hear back so I can certainly see the arguments in favor of doing this as well! But with malicious reporting, or if a team of attackers are reporting different posts to try to understand just what borderline content get through the moderators, there are arguments against it as well. One possibility is to treat reports from people who are part of the HackersPub community (differently on this front than reports from other instances.
While I like the idea of not requiring the reporter to cite the specific clause(s) of the guidelines that are violated, I'm personally skeptical about using LLMs to address the problem. Even assuming the datasets used to train the LLMs were gathered with consent (which isn't typically the case) they're likely to have racial, gender, and cultural biases. Don't get me wrong, the idea of using a tool to help the moderators and report recipient understand just what's been violated is a good one, I'm just not sure this is the right technology. Timnit Gebru and others at DAIR have been thinkiing about approaches to content moderations, so might have some ideas here.
In terms of cross-instance reports, it's really important to leave it up to the reporter whether or not to forward to another instance -- sometimes the admins of the other instance are hostile! And like the discussion of malicious reporting above, this highlights the importance of threat modeling.
Anyhow those are my quick initial thoughts. Looking forward to seeing how the functionality evolves! As you're moving forward with this, it might be interesting to talk to some of the academic researchers who have looked at moderation on the Fediverse -- Sohyeon Hwang, Owen Xingjian Zhang, Tolulope Oshinowo and others at Princeton have done some excellent work and talked to a lot of people here in the process. If it's useful, I can see if they're interested in connecting with you.
@jdp23Jon Thank you so much for this thoughtful feedback and for the paper reference! I'll definitely read Sarah Gilbert's work.
You raise excellent points I hadn't fully considered:
-
On notifying reporters: The malicious reporting scenario is a real concern. I like your suggestion of treating reports from within the community differently from forwarded reports. We should think more carefully about what information to share and with whom.
-
On LLM usage: That's a fair criticism. The bias issue is something we need to take seriously. Perhaps the LLM should only assist moderators as a reference tool, not be exposed to reporters or reported users directly. I'll look into DAIR's work on this.
-
On cross-instance forwarding: Absolutely agreed; this should be opt-in by the reporter, not automatic. I'll update the spec to make that explicit.
I'd love to connect with the Princeton researchers if they're open to it. And thank you for taking the time to share your experience: this is exactly the kind of input we were hoping for.
Hi #fediverse! I'm working on Hackers' Pub, a small #ActivityPub-powered social platform for developers and tech folks.
We're currently drafting a content #moderation (#flag/#report) system and would really appreciate any feedback from those who have experience with federated moderation—we're still learning.
Some ideas we're exploring:
- Protecting reporter anonymity while giving reported users enough context to understand and improve
- Graduated responses (warning → content removal → suspension) rather than jumping to bans
- Using LLM to help match reports to code of conduct provisions
- Supporting ActivityPub
Flagactivity for cross-instance reports
Our guiding principle is that moderation should be about growth, not punishment. Expulsion is the last resort.
Here's the full draft if you're curious: https://github.com/hackers-pub/hackerspub/issues/192.
If you've dealt with moderation in federated contexts, what challenges did you run into? What worked well? We'd love to hear your thoughts.
洪 民憙 (Hong Minhee) shared the below article:
Hackers' Pub 신고(flag) 기능 기획서
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Hackers' Pub 커뮤니티의 신고 시스템은 단순한 제재를 넘어 구성원의 성찰과 성장을 돕는 분산형 네트워크 환경을 지향합니다. ActivityPub 프로토콜을 기반으로 설계된 이 시스템은 Mastodon 등 외부 플랫폼과의 연합(federation) 환경에서도 유연하게 작동하며, 신고자의 익명성 보호와 피신고자의 알 권리 사이의 균형을 유지합니다. 기술적으로는 거대언어모델(LLM)을 활용하여 자유 형식의 신고 사유를 실시간 행동 강령(code of conduct) 조항과 동적으로 매칭하고, 신고 시점의 콘텐츠 스냅샷과 행동 강령 버전을 기록하여 검토의 객관성을 확보합니다. 관리자는 경고, 콘텐츠 검열, 일시 및 영구 정지로 이어지는 단계적 제재 체계를 통해 투명하게 사건을 처리하며, 피신고자는 이의 제기(appeal) 프로세스를 통해 공정한 재심 기회를 보장받습니다. 이러한 체계적인 설계는 자율적인 커뮤니티 관리의 복잡성을 해결하고, 건강하고 지속 가능한 연합우주(fediverse) 생태계를 구축하는 데 필요한 실무적인 통찰을 제공합니다.
Read more →GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:
- 모든
export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음) - JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
Deno.env같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)- 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
- 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
- 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림
소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.
오늘은 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를 주력으로 사용하니까, 아무래도 비교가 될 수밖에 없었는데:
- 역시나 눈치라고 해야 하나, 센스는 떨어진다. Claude Sonnet 4.5보다도 떨어지는 듯. 이를테면 Markdown 문서를 수정하도록 지시하면 기존의 일관성 있게 잘 짜여 있던 문서 서식이 금방 무너지는 게 느껴진다.
- AGENTS.md의 세세한 지시를 좀 뭉개는 느낌이 있다. 예를 들면 TypeScript 코딩할 때
any타입을 쓰지 말라고 했음에도 무시하고 사용한다든가. Claude 계열 모델들에서는 이런 건 잘 못 겪는다. - 작업의 맥락보다 이미 학습되어 있는 자신의 지식을 더 따르는 느낌이 있다. 이를테면 일부러 여러 JavaScript 런타임에서 두루 돌아가게 하려고 Deno API를 안 쓰고 Node.js API를 써서 짜 둔 코드베이스에서 갑자기 Deno API를 꺼내서 쓰기 시작하는 식이다. 이것도 눈치 문제로 볼 수도 있을 듯.
- 그렇게 중요하진 않지만 자연어 응답에 언어가 조금 섞인다. 특히 국한문혼용체가 종종 나온다. 나로서는 오히려 좋다(?). 그런데 자세히 보면 대륙에서 쓰는 간화자가 아니라서, 중국어가 섞이는 건 아닌 것 같다. 아마도 일본어 아니면 대만/홍콩의 중국어가 섞이는 것 같다. 아니면 정말로 국한문혼용체일지도? 그리고 아랍어도 한 번 섞이는 걸 봤다.
- 속도는 그냥저냥 쓸만하지만 딱히 빠른 것도 아닌데, 이건 OpenCode에서 공짜로 제공하는 걸 써서 그럴 수도 있다. Claude Opus 4.5보다는 약간 느리다고 느꼈지만, 이것도 그냥 체감이라 정확하진 않다. 삽질하는 걸 더 많이 봐서 느리다고 착각한 걸 수도 있고.
일단은 OpenCode에서 공짜로 제공하는 동안은 좀 더 써 볼 생각이다. 돈 내고 쓸 생각이 있냐 하면, 그건 좀 고민이 된다. 코딩 요금제를 보면 5시간에 300 프롬프트짜리가 월 20불 정도 된다. 지금은 Claude Max 요금제를 쓰고 있는데, 아무래도 부담이 좀 되긴 해서, Claude Pro로 내리고 MiniMax를 섞어서 쓰면 어떨까 생각만 해보고 있다.
洪 民憙 (Hong Minhee) shared the below article:
도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문 #5-2 DNS
자손킴 @jasonkim@hackers.pub
도메인 이름 시스템(DNS)은 숫자로 이루어진 IP 주소를 사람이 기억하기 쉬운 문자로 변환해주는 인터넷의 핵심 인프라입니다. 초기 아파넷(ARPANET)의 중앙 집중식 관리 방식에서 벗어나 계층적 트리 구조의 분산 데이터베이스로 발전한 DNS는 전 세계 네임서버들의 유기적인 협력을 통해 동작합니다. 사용자의 요청을 처리하는 스터브 리졸버(Stub Resolver)부터 최종 답변을 가진 권한 있는 네임서버까지, 재귀 쿼리와 반복 쿼리를 교차 활용하여 효율적인 이름 풀이를 수행합니다. 특히 도메인을 IP에 직접 매핑하는 A 레코드와 별칭을 부여하는 CNAME 레코드의 차이를 이해하면 유연한 네트워크 인프라 운영이 가능해집니다. 최근에는 평문 통신의 보안 취약점을 해결하기 위해 DNS over TLS(DoT)와 DNS over HTTPS(DoH) 같은 암호화 기술이 도입되었으며, 접속 대상의 노출을 막는 ECH 기술까지 등장하며 사용자 프라이버시 보호가 한층 강화되었습니다. 이 글은 복잡한 DNS의 내부 동작 원리와 최신 보안 프로토콜의 진화 과정을 상세히 다루며 현대 네트워크 시스템의 근간을 파악하는 데 필수적인 통찰을 제공합니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) 是的，Ruby 是我最熟悉的编程语言，自制编程语言过程充满挑战和乐趣。多年以前，我还是编程新手时，也尝试了解 Lisphp 的实现方式，但由于能力所限，未能做到；有一段时间使用过 CoffeeScript，得知作者起初也是以 Ruby 作为实现语言，我想对于现在的我，Ruby 是最适合的选择。感谢您为编程爱好者提供这样的交流平台，祝新的一年万事如意！
@hongminhee洪 民憙 (Hong Minhee) 是的，Ruby 是我最熟悉的编程语言，自制编程语言过程充满挑战和乐趣。多年以前，我还是编程新手时，也尝试了解 Lisphp 的实现方式，但由于能力所限，未能做到；有一段时间使用过 CoffeeScript，得知作者起初也是以 Ruby 作为实现语言，我想对于现在的我，Ruby 是最适合的选择。感谢您为编程爱好者提供这样的交流平台，祝新的一年万事如意！
인터페이스가 구린 라이브러리를 쓸때는 반!드!시! 심호흡을 하고 멀쩡한 인터페이스의 wrapper를 만든후에! 기능 개발을 합시다. 절대 대충 꾸역꾸역 만들어보자고 덤비면 안됩니다. 결국 후회합니다.
- V모사의 AI 라이브러리를 쓰다가
Designing type-safe sync/async mode support in TypeScript https://lobste.rs/s/844jrt #api #javascript #plt
https://hackers.pub/@hongminhee/2026/typescript-sync-async-type-safety
바이브코딩이 취미가 되어가는 것일까요? 그새 또 뭔가 하나를 뚝딱여왔습니다... be-music-script라는 동인 리듬게임 에뮬레이터 비슷한 친구의 플레이 로그를 정리해주는 서비스를 만들어봤어요. 많은 리듬게임 유저들은 자기가 얼마나 잘했는지 자랑하고 싶어하는데, db 파일을 읽은 뒤 당일의 멋진 성과들을 정리해주는 서비스입니다. 제가 쓰려고 만든건데 이것도 결국 엔지니어링? 결과물인걸까? 싶어 올려봅니다.
요즘 AI의 도움 덕분에 아이디어를 구현하는게 두렵지 않아졌다는 기분이 드네요. https://sonohoshi.github.io/gosubms/
Claude Code의 인기와 함께 터미널에서 한글을 쓰는 모습을 자주 볼 수 있습니다. 하지만 터미널에서 쓰이는 한글은 글자간의 간격이 넓어 보기 좋지 않은 경우가 많습니다. 왜 이런 걸까요?
흔하게 쓰는 코드용 글꼴은 로마자, 숫자, 특수기호만을 다룰 뿐 한글은 다루지 않습니다. 그래서 터미널은 한글 표시를 하기 위해 대체 글꼴을 사용합니다. 대체 글꼴은 보통 OS의 기본 글꼴일 것입니다. 가변폭 글꼴이겠죠. 터미널은 이를 일부러 고정폭으로 만들기 위해 한글 한 자에 로마자 2자 폭을 할당하는데 이 과정에서 여백이 추가되면서 자간이 넓은 어색한 한글을 보게 되는 것입니다.
해결책은 한글 고정폭 글꼴을 사용하는 것입니다. 한글 고정폭 글꼴은 한글 1자를 로마자 2자 폭에 맞춰 만들었으므로 터미널이 더 이상 여백을 만들지 않습니다. 이러한 한글 고정폭 글꼴이 많진 않습니다. 10종이 안 되는 것 같네요. 저는 그중 Monoplex를 사용하고 있습니다. @hongminhee洪 民憙 (Hong Minhee) 님은 Sarasa Gothic을 사용하신다고 하네요. 적은 수의 글꼴이지만 맘에 드시는 걸 찾으셔서 예쁜 한글 출력을 보시면 좋겠습니다.
처음에는 Optique에 비동기 모드 추가하는 것에 거부감이 있었는데, 막상 구현하고 보니까 이런 저런 아이디어들이 떠오르는 듯? 그래서 이런 이슈도 하나 만들었다.
갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.
@bglbgl gwyng Conventional Commits라고 부르더라고요. 저도 개인적으로 가뜩이나 50자 제한이 빠듯한데 접두사까지 붙이면 더 좁은 느낌이라 안 쓰고 있습니다. 일부 LLM들이 자꾸 Conventional Commits 쓰려고 굴어서 아예 AGENTS.md에서도 막아놨어요. ㅋㅋㅋㅋ
갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.
Designing type-safe sync/async mode support in TypeScript
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Optique, a type-safe CLI parser for TypeScript inspired by functional programming principles, recently introduced support for both synchronous and asynchronous execution modes to handle complex requirements like dynamic shell completions. Implementing this feature required sophisticated type-level logic to ensure that combining an asynchronous parser with synchronous ones correctly results in an asynchronous aggregate. After evaluating several design patterns, the developer settled on an explicit mode parameter with a default value to maintain backward compatibility while allowing for runtime inspection. This approach leverages conditional types and advanced inference to compute combined modes automatically, even though it necessitated significantly increasing internal implementation complexity to support dual execution paths. The updated API now includes specialized runners that provide compile-time enforcement of the expected execution mode, preventing common pitfalls associated with asynchronous code. By prioritizing a clean user-facing interface, the library successfully integrates asynchronous capabilities without compromising its original simplicity or type safety. This architectural evolution demonstrates how TypeScript’s powerful type system can manage complex state propagation while keeping the development experience intuitive and robust.
Read more →Optique 0.9.0 pre-release is ready for testing!
The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).
The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.
Try it:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212I'd love feedback before merging! Especially interested in:
- API ergonomics
- Edge cases I might have missed
- TypeScript inference issues
Docs:
Optique 0.9.0 pre-release is ready for testing!
The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).
The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.
Try it:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212I'd love feedback before merging! Especially interested in:
- API ergonomics
- Edge cases I might have missed
- TypeScript inference issues
Docs:
Optique 0.9.0 프리릴리스 테스트 중입니다!
이번 주요 기능은 동기/비동기 모드 지원입니다. 이제 비동기 값 파싱과 자동완성을 지원하는 CLI 파서를 만들 수 있습니다. Git 브랜치/태그 목록처럼 셸 명령 실행이 필요한 자동완성에 딱이에요.
컴비네이터를 통해 async 모드가 자동으로 전파되기 때문에, 개발자는 말단 파서에서만 동기/비동기를 결정하면 됩니다.
설치:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212머지 전에 피드백 주시면 정말 감사하겠습니다! 특히 이런 부분이 궁금해요:
- API 사용성
- 에지 케이스
- TypeScript 타입 추론 문제
문서:
TCP/IP is a social construct
Modern optimizing compilers are truly amazing. Rust / LLVM just broke my brain by turning what I was SURE would be poorly optimized code due to indirection into a tight result with zero perceptible overhead.
Modern CPUs also probably help.
WinGet도 요즈음은 Microsoft Store와 비슷한 정책을 적용하기 시작해서, 자동화된 검사 과정에서 식탁보 새 버전 매니페스트 등록이 막혔었는데, Moderator께서 정확한 판단을 내려주신 덕분에 무사히 새 버전이 게시되었습니다.
안타깝게도 Microsoft Store에는 식탁보를 등록하는 것이 계속 어려울 것으로 보입니다만, 대신 WinGet에 등록이 가능할테니 UniGetUI 등의 수단을 이용해서 커맨드라인 없이 식탁보를 쉽게 설치할 수 있는 방법을 조만간 공식 가이드로 내도록 하겠습니다.
Apple will allow alternative browser engines for iPhone and iPad users (iOS/iPadOS) in Japan.
https://developer.apple.com/support/alternative-browser-engines-jp/
Apple should allow alt engine for the rest of the world too. No point holding it back.
Logging in Node.js (or Deno or Bun or edge functions) in 2026
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Effective logging is the difference between a quick fix and a 2 AM production nightmare, yet traditional JavaScript tools often swing between the fragile simplicity of console.log and the heavy overhead of complex frameworks. LogTape emerges as a zero-dependency alternative that works seamlessly across Node.js, Deno, Bun, and edge functions, addressing the inherent limitations of standard console methods by introducing hierarchical categories, sophisticated filtering, and structured logging. By utilizing sinks, developers can route logs to multiple destinations—such as rotating files, Sentry, or OpenTelemetry—simultaneously while maintaining machine-readable JSON formats. One of its standout features is the support for implicit contexts via AsyncLocalStorage, which allows for seamless request tracing across asynchronous boundaries without the need for manual identifier passing. Furthermore, its library-first design ensures that package authors can include diagnostic logging without imposing unsolicited output or configuration burdens on their users. The system also accommodates production-critical needs like non-blocking I/O for high-performance environments and automated sensitive data redaction. Adopting this structured approach to logging provides the necessary visibility to debug complex systems efficiently while maintaining a lightweight and modern development workflow.
Read more →
대한수학회 수학달력 2026년을 하루에 하나씩 짧게 설명해보는 타래
洪 民憙 (Hong Minhee) replied to the below article:
Hello, 2026!
neo @neo@hackers.pub
通过 Ruby 实现自制编程语言的解释器逻辑，涵盖了变量作用域（scoping）查找、布尔真值判定及语句解析的核心机制。这段代码揭示了语言运行时的底层设计思路，为开发者深入理解编程语言的实现原理提供了直观的参考。
Read more →
"Crafting Interpreters" 真的想教会我写自己的编程语言。
洪 民憙 (Hong Minhee) shared the below article:
Hello, 2026!
neo @neo@hackers.pub
通过 Ruby 实现自制编程语言的解释器逻辑，涵盖了变量作用域（scoping）查找、布尔真值判定及语句解析的核心机制。这段代码揭示了语言运行时的底层设计思路，为开发者深入理解编程语言的实现原理提供了直观的参考。
Read more →洪 民憙 (Hong Minhee) shared the below article:
`X-Frame-Options` 의 악몽에서 깨어나세요, 프록시 서버 개발기
소피아 @async3619@hackers.pub
`X-Frame-Options` 헤더로 인해 발생하는 웹 사이트 임베딩 제한을 프록시 서버 개발을 통해 해결하는 과정을 다룹니다. 저자는 실시간 영상 스트리밍 방식의 지연 시간 문제를 극복하기 위해 `iframe`을 활용한 직접 임베딩 방식을 선택했으며, 이 과정에서 마주한 다양한 기술적 난제를 해결해 나갑니다. 단순히 응답 헤더를 제거하는 수준을 넘어, 상대 경로 문제를 해결하기 위한 URL 구조 재설계와 React 및 Vue와 같은 단일 페이지 애플리케이션(SPA)의 라우팅 시스템을 속이기 위한 고난도의 JavaScript 후킹 기법을 소개합니다. 특히 Babel을 이용해 소스코드를 추상 구문 트리(AST)로 분석하고 실행 시점에 `window.location` 접근을 가로채는 방식은 브라우저 보안 제약을 창의적으로 우회하는 통찰을 제공합니다. 이 글은 외부 웹 서비스를 자사 서비스에 매끄럽게 통합하려는 개발자들에게 프록시 서버 설계와 JavaScript 내부 동작 원리에 대한 깊이 있는 경험을 공유하며 기술적 돌파구를 제시합니다.
Read more →Sending emails in Node.js, Deno, and Bun in 2026: a practical guide
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Sending emails in JavaScript remains a fragmented task, particularly when navigating the diverse requirements of Node.js, Deno, Bun, and edge environments. This guide explores Upyo, a cross-runtime email library that addresses these challenges through a unified, type-safe API designed for zero dependencies and provider independence. The library simplifies the transition between traditional SMTP and modern providers like Resend, SendGrid, Mailgun, or Amazon SES, ensuring that application logic remains consistent regardless of the underlying transport. Key technical insights include implementing DKIM signatures to boost deliverability, managing resources efficiently with modern JavaScript cleanup patterns, and leveraging bulk-sending optimizations for large-scale notifications. Additionally, the content examines strategies for achieving high availability through provider failover pools and integrating observability with OpenTelemetry for production monitoring. Whether you are building on standard servers or restricted edge functions, Upyo provides the architectural flexibility needed to handle complex email workflows with minimal overhead. Adopting a standardized, runtime-agnostic library for email communication significantly reduces technical debt and ensures your application remains resilient across the modern web stack.
Read more →洪 民憙 (Hong Minhee) shared the below article:
2025 Q4 Review
Jaeyeol Lee @kodingwarrior@hackers.pub
이번 분기 회고는 예상치 못한 기회와 성장을 통해 삶의 궤적이 변화한 과정을 생생하게 담고 있습니다. 저자는 오픈소스 소프트웨어 아카데미(OSSCA) 활동과 웹 브라우저를 밑바닥부터 구현하는 스터디, 그리고 VIMRC 2025 행사 주최 등 왕성한 대외 활동을 이어오며 기술적 내실을 다졌습니다. 특히 구직 과정에서 미국 스타트업의 실무 테스트(Work trial)를 거쳐 정식 멤버로 합류하게 된 경험은 이 글의 핵심적인 전환점입니다. Python과 FastAPI, React 기술 스택을 활용하며 AI 도구를 적극적으로 도입한 업무 환경에서 얻은 인사이트와 전 직장 대비 대폭 향상된 처우 등 구체적인 성과를 공유합니다. 나아가 향후 해외 컨퍼런스 참여와 Python 생태계 기여, 그리고 비즈니스 가치를 창출하는 엔지니어로의 도약이라는 원대한 목표를 제시합니다. 이 글은 꾸준한 기술적 탐구와 커뮤니티 활동이 어떻게 실제적인 커리어 성장과 글로벌 기회로 연결될 수 있는지를 보여주는 귀중한 기록입니다.
Read more →strcpy도 사용 금지
------------------------------
- cURL 프로젝트가 기존에 strncpy()를 제거한 데 이어, 이제 *strcpy()도 코드베이스에서 완전히 금지* 함
- strcpy()는 API가 단순하지만 *버퍼 크기 검증이 분리될 위험* 이 있어, 장기 유지보수 시 안전하지 않음
- 이를 대신해 *curlx_strcopy()* 라는 새 함수가 도입되어, 대상 버퍼 크기와 문자열 …
------------------------------
https://news.hada.io/topic?id=25474&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
2026년 병오년 새해를 맞아 식탁보 1.16.0 버전을 출시했습니다. 이번 버전에서는 폴더 마운트 기능, 그리고 백그라운드 비동기 다운로드를 구현하여 이전보다 최대 30~40% 이상 빨라진 환경 구축 속도를 달성했습니다.
코딩 AI 어시스턴트의 도움을 받아 계속해서 빠른 출시와 적극적인 기능 반영을 이어 나가도록 하겠습니다. 많은 공유와 후원을 계속 부탁드리겠습니다!
#식탁보 #인터넷뱅킹 #NPKI #보안 #플러그인 #공동인증서
https://github.com/yourtablecloth/TableCloth/releases/tag/v1.16.0
2026年에도 새해 福 많이 받으세요!
연말을 맞이하여 주요 저장소들의 AGENTS.md/CLAUDE.md 문서 업데이트 중…
VCS와 패키지 매니저가 통합되어야 한단 얘기를 했었는데, shadcn의 인기가 그런 방향에 대한 지지를 간접적으로 보여주고 있다. shadcn은 UI 라이브러리를 만들어봤자 어차피 고쳐쓰는 경우가 많아서 나왔다. 문제는 기존의 npm 패키지 같은 것들은 받는건 쉬운데 그다음에 고치는게 열불터지는 것이다.
- 조건에 맞는 소스 코드를 받는 것 2. 그걸 고치는 것, 에서 패키지 매니저는 1은 잘하는데 2를 불편하게 만든다. VCS는 1을 할수있는데, 약간 번거롭게 되어있고(git submodule을 생각해보라), 2는 당연히 쉽다. VCS에서 1을 개선해야한다.
오늘은 고등학교 때 만들다 말았던 라이브러리를 얼추 마무리 지었다. Claude랑 같이 스펙 문서 만들고, 이를 바탕으로 작업하도록 했다. 당시에 하라는 FAT 덤프 파싱은 안 하고 Python에서 편하게 파싱하고 싶어서 만들기 시작했던 라이브러리고 취업하게 되서 이후로 안 봤었는데, Claude Code 덕분에 이제는 보내줄(?) 수 있을 것 같다.
근데 당시에 파서 콤비네이터를 몰랐어서 그랬고 지금은 파서 콤비네이터를 쓸 것 같다. 그리고 오늘 작업하면서 보게 된 건데 비슷한(?) 느낌으로 construct[1] 라는 라이브러리의 존재도 알게 되었다.
이제 Python을 잘 안 쓰고, 원래 시작점이었던 포렌식도 안 하니까 쓸 일은 없겠지만 그래도 당시 2019년 Hacktoberfest 시기에 필드 추가 기여도 받아보고 좋은 기억의 라이브러리였다.
https://github.com/moreal/pystructs/
@hongminhee洪 民憙 (Hong Minhee) OpenCode 는 어떤점이 좋으셨어요?
@jLEE Jaeyoung OpenCode가 특별히 Claude Code보다 좋은 점은 아직 크게 못 느낀 것 같아요. 아, LSP를 지원하다는 것 정도…? 근데 Claude Code도 최근에 LSP 지원이 들어왔다고 듣긴 해서 (LSP를 쓴다는 느낌을 받은 적은 없지만요), 이 부분은 좀 애매하네요. 다만 OpenCode가 오픈 소스인데다 확장성이 좋아서 그 부분을 기대하고 있어요. 아, 그리고 세션 중간에 모델(아예 다른 업체의 모델로도)을 바꿀 수 있는 것도 좋은 것 같습니다.
Released Vertana 0.1.0—agentic #translation for #TypeScript/#JavaScript.
Instead of just passing text to an #LLM, it autonomously gathers context from linked pages and references to produce translations that actually understand what they're #translating.
- Docs: https://vertana.org/
- GitHub: https://github.com/dahlia/vertana
알고리즘을 각 잡고 공부해 본 적이 없습니다. 기본부터 천천히 다져가며 공부하고 싶은데, 좋은 책, 강의 등이 있을까요?
@hongminhee洪 民憙 (Hong Minhee) openrouter(AI 모델 여러개 쓸 수 있는 인터페이스 제공하는 곳)랑 연결해서, AI 모델 여러개로 에이전트 여러개 만들어서 각자 역할분담하게 하는 전략도 있더라고요.
저도 돈 많으면 시도해보고 싶습니다...
@akastoot악하 그런 게 OpenCode만 가지고도 되는 것 같더라고요!
평소에는 거의 Claude Code만 쓰는데, 오늘은 일부러 OpenCode를 써봤다. OpenCode에서 Claude 4.5 Opus도 써 보고, Gemini 3 Pro도 써 보고, GPT-5.2도 써 봤다. 일단 “말귀”를 잘 알아 듣는다는 점에서는 Claude 4.5 Opus와 GPT-5.2가 괜찮았던 것 같고, Gemini 3 Pro는 여러 측면에서 내 기대와는 좀 다르게 돌아갔던 것 같다. 그리고 문서 작업을 시켜보면 알 수 있는데, Gemini 3 Pro는 글을 상대적으로 못 쓴다. 이래저래 Gemini 3 Pro는 앞으로도 안 쓰게 될 듯.
OpenCode 자체는 잘 만들었다고 느꼈다. Claude Max 플랜을 그대로 쓸 수 있어서, 당분간 Claude Code 대신 메인 에이전트로 사용해 볼 예정.
