Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

FedifyHolloBotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨,我是 FedifyHolloBotKit 以及這個網站 Hackers' Pub 的開發者!

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
2
3

LogTape 0.11.0 release notes

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

LogTape 0.11.0 introduces enhanced structured logging capabilities and a new JSON Lines formatter, improving how developers handle logs across JavaScript runtimes. The update allows direct object logging, where structured data can be logged by passing an object as the first argument to any log method, and introduces a universal property interpolation with `{*}`. This placeholder streamlines the inclusion of all properties from structured data without explicitly naming each one. Additionally, the new JSON Lines formatter outputs each log record as a JSON object on a separate line, ideal for log aggregation systems and analysis tools, with customizable options for category separation, message formatting, and properties handling. These enhancements aim to make logs more searchable and analyzable, reduce boilerplate, and improve integration with log management systems, all while maintaining backward compatibility and LogTape's zero-dependency promise.

Read more →
4

예전에 게임 회사에서 상점 시스템(게임 머니로 아이템 구입/선물을 처리하는거)을 개발하는 팀에서 일한적이 있다. 그때도 퇴사하기 직전에 취약점을 발견했었는데, 다행히 외부인은 쓸수없고 직원만 쓸수있는 취약점이긴 했다. 상점 시스템이 게임 머니를 관리하는 시스템과, 실제로 아이템을 인벤토리에 넣는 시스템이 분리가 되있어서 생긴 문제였는데, 가령 잡템을 100원에 구입하는척하며 실제론 인벤토리에 전설의 무기가 들어가게끔 할수 있었다. 그러니까 MSA인데 각 서비스가 서로를 100% 신뢰하고 있어서 생긴 문제? 어떤 직원이 마음먹고 그런 짓을 했다면 본격적으로 abnormarly detection을 하지 않는이상 적발하기가 매우 어려웠을 것이다.

4
3

@hongminhee洪 民憙 (Hong Minhee) 예전에 잠깐 일했던 핀테크(라기에도 민망한) 회사에서, PG랑 VAN 사이에서 뭔가 하는 모듈을 만들고 그걸로 돈을 벌었거든요. 근데 그 모듈이 보안에도 도움되는게 없고, 또 신용에도 도움이 되는게 없어서 존재 이유가 의문이었습니다. 그러다 퇴사하기 직전엔 거기 취약점까지 있어서 순수하게 악영향만 있는 프로그램이란걸 깨달았습니다.

0
0
0
0
0
2
0
3
1

GPL은 외부 릴리즈시 추가로 작성하거나 고친 소스 코드의 동일 조건 공개를 강제하는 특성으로 인해, 초기에 사회주의-공산주의라는 오해를 많이 받기는 했었음. 네가 썼다면, 네가 작성한 코드도 공개하라는 공유주의 라이센스니까.

그러나 그러한 공개 강제는 GPL을 일종의 플랫폼으로 만드는 효과 - GPL을 쓰면 GPL이고 아니면 처음부터 아니어야 함 - 가 있어서, 리눅스가 BSD를 제치고, 윈도와 유닉스를 넘어 인터넷과 세계의 커널이 되는 결정적 요인이 됩니다. 그리고 수많은 기업들이 이를 기반으로 자라나죠.

GPL은 자본주의 사회에서도 매우 훌륭하게 기능하고 있습니다. 이제 와서 GPL이 공산주의라고 하는 사람은 거의 없죠.

4

잘 모르는데 불안정한 라이브러리를 쓸때의 디버깅은, 코드의 일부를 disable하고 버그가 재현되는지 보고 맞으면 범위를 좁히고 이런식으로 무지성 이진탐색을 수행하는 식으로 하게된다. 전혀 모르는 라이브러리에 대해서도 쓸수있는게 장점이긴한데, 반대로 이런건 하고나서 배우는게 진짜 1도 없다.

6
4

Hackers' Pub을 사용하면서 연합우주(fediverse) 뿐만 아니라 Bluesky 사람들과도 교류하고 싶으신 분들은 Bridgy Fed라는 서비스를 사용해 보시면 좋을 것 같습니다. Hackers' Pub 계정 생성 후 2주가 지난 분들만 사용 가능하긴 한데요.[1]

@bsky.brid.gyBridgy Fed for Bluesky 계정을 팔로하시면 Bluesky 쪽에 일종의 미러링 계정이 생성되게 됩니다. 성공적으로 Bluesky 미러가 생기면 @bsky.brid.gyBridgy Fed for Bluesky 계정이 맞팔을 해 올 겁니다.

예를 들어 제 @hongminhee洪 民憙 (Hong Minhee) 계정으로 @bsky.brid.gyBridgy Fed for Bluesky 계정을 팔로하면, Bluesky 쪽에 @hongminhee.hackers.pub.ap.brid.gy라는 계정이 생기는 식입니다. 그러면 Bluesky 쪽 사람들이 해당 계정을 멘션하거나, 댓글을 달거나, 인용을 하면 Hackers' Pub에서 그게 보이게 됩니다. 서로 팔로도 할 수 있고요.


  1. Bridgy Fed 쪽의 스팸 대책 정책이라고 합니다. ↩︎

3
2

Good news! We've officially added support to the roadmap. We've created a detailed issue to track our implementation plan: https://github.com/fedify-dev/fedify/issues/233.

The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.

If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.

🎉 support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, can now run on Cloudflare Workers.

What's included:

Try it now: Available in the development release v1.6.1-dev.876+7b07d213:

This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!

1
  • 출근할 때 새로 산 키보드 가지고 하면 기분이 좋다 유효 시간: 1시간
0
5

洪 民憙 (Hong Minhee) shared the below article:

ap-components

Evan Prodromou @evanprodromou@socialwebfoundation.org

I want to share some information about a repository we just published. ap-components is a set of Web Components for building interfaces for the ActivityPub API. I built it as I was making a sample application for handling the acct: URI scheme. I found myself making more and more components for the UI, and realised that they would probably be useful for other applications, too. The library is available on npm at @socialwebfoundation/ap-components. It currently covers some of the simplest […]

Read more →
0
1

제가 지난 15년 정도 그렇게 살다가 결국 VS Code에 정착했답니다. 온갖 랭귀지 서버 세팅하는 게 너무나 귀찮은 나머지…

0

@bglbgl gwyng 저도 VS Code로 갈아타게 된 계기가 LSP의 보급으로 대부분의 언어에서 고품질의 자동 완성 및 리팩터가 제공되면서 생각이 바뀐 거였습니다. 아무리 글자 조작을 신속 효율적으로 한다고 해도 LSP의 기능이 주는 생산성을 따라가지 못하더라고요. 그리고 Vim이 제공하는 많은 이점을 이제 주요 IDE에서 Vim 호환 확장을 통해 누릴 수 있게 되었기도 하고요.

3

If you're interested in building your own server but don't know where to start, I recommend checking out 's Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the !

ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!

1
0
0
0

If you're interested in building your own server but don't know where to start, I recommend checking out 's Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the !

0
3
0
2

오픈 소스 컨퍼런스 名古屋(나고야)에서 Fedify () 《나만의 聯合宇宙(연합우주) 마이크로블로그 만들기》(自分だけのフェディバースのマイクロブログを作ろう!)가 完販(완판)되었다고…!

4

제가 지난 15년 정도 그렇게 살다가 결국 VS Code에 정착했답니다. 온갖 랭귀지 서버 세팅하는 게 너무나 귀찮은 나머지…

2
3
2
2

Node.js 개발자라면 꼭 읽어봤으면 하는 아티클 2선

일반적인 Node.js 애플리케이션을 개발할 때 프레임워크와 무관하게 함께 일하는 동료들에게 필수적으로 추천하고 싶은 아티클이 있다.

빠르고 유지보수 가능한 데이터베이스 패턴들

https://sophiebits.com/2020/01/01/fast-maintainable-db-patterns

특정 프레임워크나 ORM에 의존하지 않고도 N+1 Query, 캐싱 같은 일반적인 문제를 해결하며 유지보수 가능한 형태로 코딩하는 방법을 제시한다. DataLoader로 모든 문제가 해결된다고 생각할 수도 있지만, 근본적인 문제 해결 과정을 직접 고민해보는 것만으로도 엔지니어링 역량 향상에 큰 도움이 된다.

Next.js에서 보안을 고려하는 방법

https://nextjs.org/blog/security-nextjs-server-components-actions

React 관련 내용이 포함되어 있지만, 그 부분을 제외하고 읽어도 충분히 가치가 있다. 데이터를 클라이언트에 전달할 때 마스킹하거나 접근 권한을 검사하는 방법을 구체적으로 알려준다. 핵심은 별도의 플러그인이나 외부 시스템 없이도 간단하면서 효과적인 권한 검사 시스템을 구축할 수 있다는 점이다.

마무리

위 아티클들을 추천하는 이유는 간단하다. 특정 프레임워크에 결속되지 않으면서도 독립적이고 지역적으로 백엔드 애플리케이션에서 볼 수 있는 일반적인 문제를 해결할 수 있는 방법들을 제시하기 때문이다. 이런 접근법은 전체 코드베이스의 안전성과 성능을 크게 향상시키며, 결국 더 많은 개발자들이 행복하게 일할 수 있는 환경을 만들어준다고 생각한다.

대부분 프레임워크에 의존적이거나 플러그인에 의존해 전체 코드베이스를 올바르게 수정하기 어려워지는 모습을 여러번 보았다. 개인적으로 엔지니어링 문화에서 크게 해결하고 싶은 부분이다. JavaScript 뿐만 아니라 가능하면 언어나 런타임에 있는 근원적 요소만을 통해 문제를 해결하는게 건강하게 문제를 해결할 수 있는 방법이라고 본다.

6
0
0
0

One of the last missing pieces from Hackers' Pub's original roadmap is an algorithmic timeline. I've been thinking about how to build one that respects privacy and fediverse values—would love to hear thoughts from the community!

The key idea: only use explicit user actions (reactions, shares, follows) as signals, never track clicks, scrolling, or dwell time. What do you think?

@hongminhee洪 民憙 (Hong Minhee) I'm not a Hackers' Pub user but I'm always very excited by algorithm on Fedi! I think they are an important part of building better networks.

One thing that Twitter does that is interesting is to give more weight to a comment if the original poster replied/interacted with it (exact numbers: if someone leaves a comment, it's 54 times more impactful than a like, but if the OP replies it become x150). This is a great way to favor discussion in my opinion, this could be interesting to copy.
1

@hongminhee洪 民憙 (Hong Minhee) I'm not a Hackers' Pub user but I'm always very excited by algorithm on Fedi! I think they are an important part of building better networks.

One thing that Twitter does that is interesting is to give more weight to a comment if the original poster replied/interacted with it (exact numbers: if someone leaves a comment, it's 54 times more impactful than a like, but if the OP replies it become x150). This is a great way to favor discussion in my opinion, this could be interesting to copy.
1

One of the last missing pieces from Hackers' Pub's original roadmap is an algorithmic timeline. I've been thinking about how to build one that respects privacy and fediverse values—would love to hear thoughts from the community!

The key idea: only use explicit user actions (reactions, shares, follows) as signals, never track clicks, scrolling, or dwell time. What do you think?

6
0
0

Servo Report Weeks 20 & 21 2025

Highlights from last week:

- Support `wavy` and `double` for `text-decoration-line`
- Fix calculation of font underline thickness on macOS
- Fully support `<input type=color>`
- Incremental layout improvements
- libservo: Allow embedders to execute JavaScript scripts via the API
- Unconditionally enable the URLPattern API

Decorative report cover with the Servo logo that reads "Servo Report Week 20 & 21 2025
0
0
0

주민등록번호를 암호화하면 과연 개인정보가 아니게 되는 것일까〉 (전승재 변호사)

그런데 주민번호를 일방향 암호화 하면 과연 원래 값을 알아낼 수 없는가. (…) 무작위 대입 공격(brute force attack)이 그것이다. 0세부터 100세까지 한국인이 가질 수 있는 주민번호의 경우의 수는 약 70억 개이다. 70억 개의 후보를 하나씩 암호화해서 2기 때 제공받은 암호문과 대조해보는 방법으로 주민번호 원문을 알아낼 수 있다.

주민등록번호를 암호화하면 과연 개인정보가 아니게 되는 것일까

1. 서울중앙지방법원 2017. 9. 11. 선고 2014가합508066, 538302 판결의 개요 의사가 환자에게 발행해주는 처방전에는 환자의 성명, 주민번호 등 개인정보와 질병분류기호, 처방의약품의 명칭 등이 적혀있다. 환자가 약을 짓기 위해 약국에 처방전을 건네주면, 약국은 그 정보를 심사평가원에 전달해 건강보험급여 청구를 한다. 이 작업을 전산화 한 프로그램이 바로 약국의 PC마다 설치되는 Pharm Manager 2000(이하 'PM2000')이다. 피고 재단법인 약학정보원(이하 '약학정보원')은 PM2000 프로그램의 관리·배포 업무를 수행하고 있었다. 약학정보원은 2011년 1월 업데이트한 버전부터 자신의 중앙 서버에 약국에서 입력된 처방전 정보가 자동 전송되도록 했다. 그리고 수집한 처방전 정보를 아래 방식으로 암호화 한 후 피고 IMS Health Inc(이하 'IMS')에 판매했다. &nbsp; ① 2011년 1월부터 2014년 6월까지는 13자리의 주민번호 중 홀수 및 짝수 자리 숫자를 각각 정해진 규칙에 따라 영어 알파벳으로 치환한 다음 양끝 2자리에 임의의 알파벳으로 잡음(noise)을 추가하는 방식의 양방향 암호화가 이루어졌다(이하 '1기 암호화'). ② 2014년 6월부터 2014년 9월까지는 주민번호가 해시 알고리즘인 SHA-512를 통해 일방향 암호화되어 제공되었다(이하 '2기 암호화'). ③ 2014년 10월부터 2015년 1월까지는 주민번호 대신 성명, 생년월일, 성별로 환자를 특정한 후 이것이 일방향 암호화되어 제공되었다(이하 '3기 암호화'). &nbsp; 환자인 원고들은 본인의 동의 없이 개인정보를 약학정보원이 수집했고 IMS가 이를 제공 받았다는 이유로 정신적 손해배상을 청구했다. &nbsp; 1심 판결은 원고들의 청구를 전부 기각했다. 피고들의 일부 행위가 위법하더라도, 당해 개인정보는 통계분석 용도로만 활용되었고 IMS 외 제3자에게 추가 유통되지 않아 정보주체의 정신적 손해가 없다는 것이다. 이는 ‘GS 칼텍스 판결’ 법리에 따른 것인데, 이에 관하여는 본고에서 다루지 않는다. &nbsp; 행위사실 별로 위법 여부를 살펴보면, 약학정보원이 환자의 동의를 받지 않고 처방전 정보를 자신의 중앙 서버에 수집한 행위는 개인정보 보호법 위반으로 1심에서 판단되었다. 참고로 건강보험급여 청구를 위해서는 약국이 환자의 성명, 주민번호 및 질병명 등을 비롯한 처방전 내용을 명세서에 적어 심사평가원에 제출해야 하는데(국민건강보험법 시행규칙 제19조), 그 업무의 당사자인 약국과 심사평가원은 정보주체의 동의 없이 당해 개인정보를 처리할 수 있지만, 약학정보원은 그렇지 않다. &nbsp; 다음으로 약학정보원이 IMS에 정보를 넘긴 부분에 대해, 1심 판결은 암호화 방법에 따라 판단을 달리했다. 먼저 1기 암호화된 정보의 경우 원래 주민번호를 쉽게 알아볼 수 있는 ‘개인정보’에 여전히 해당하며, 이것을 정보주체의 동의 없이 제3자인 IMS에게 제공한 행위는 위법하다고 판단되었다. &nbsp; 한편, 2기 및 3기 암호화된 정보의 경우 아예 개인정보에 해당하지 않아 정보주체의 동의 대상이 아니라고 판단되었다. 주민번호를 일방향 암호화했기 때문에 원문을 풀어볼 수 없어 개인을 알아보지 못한다는 것이 판결 이유이다. 그러나 암호문을 풀지 못하더라도 그 주인을 ‘식별’할 수 있는 경우가 흔히 있다. 이것이 본고에서 논하고자 하는 핵심이다. &nbsp; &nbsp; 2. 1기 암호화된 주빈번호의 개인정보 여부 단순 치환 방식에 기반한 1기 암호화의 경우 암호화라고 칭하기 곤란할 정도로 해독이 쉬웠다. 1심 판결도 이를 가리켜 주민번호 원문을 쉽게 복원해 개인을 식별할 수 있다는 이유로 여전히 ‘개인정보’에 해당한다고 보았다. &nbsp; &nbsp; 3. 2기 암호화된 주민번호의 개인정보 여부 2기 암호화 시기에는 역함수(逆函數)가 없는 암호화 알고리즘(‘일방향 암호화’ 또는 ‘해시’ 함수)인 SHA-512를 통해 주민번호가 변환되어 IMS에게 제공되었다. 1심 판결은 역함수가 없다는 특성에 주목하여, 주민번호 원문을 복원하는 것이 원천적으로 불가능해졌다고 보아 그 정보가 ‘개인정보’가 아니라고 판단했다.&nbsp; &nbsp; 그런데 주민번호를 일방향 암호화 하면 과연 원래 값을 알아낼 수 없는가. 암호화 기술의 관점에서 보았을 때 1심 판결에는 의문의 여지가 있다. IMS는 과거 1기 암호화 시절 이미 방대한 주민번호 정보를 얻은 것으로 평가할 수 있기 때문이다. IMS가 갖고 있는 개인의 주민번호를 동일한 알고리즘으로 암호화 한 후, 이것이 2기 암호화 시기에 제공받은 암호문 중 어느 것과 일치하는지 대조함으로써 개인을 쉽게 알아볼 수 있다. &nbsp; 예컨대 1기 암호화 시기에 주민번호 ‘801231-1234567’인 환자 정보를 IMS가 제공받았다고 하자. 이것을 SHA-512 함수로써 암호화하면 ‘B609EB67916D23262F296CF88A860FCDA987B96087FE75AF2FAB38D4DC50EF2AC0BF486525B602361A3FC9943FECF4109308BC5271E1F9165F72F60026FDC933’이라는 모습이 된다. 다른 텍스트를 암호화 했을 때 동일한 암호문이 나올 확률은 수학적으로 ‘0’으로 보아도 무방하다. 그렇다면 2기 암호화 시기에 제공받은 정보 중 위와 일치하는 암호문이 있다면 당해 정보는 주민번호 ‘801231-1234567’인 환자에 관한 것이다. 이렇듯 개인 식별이 용이한 정보는 법상 ‘개인정보’로 취급되는 것이 타당하다. &nbsp; 참고로 일방향 암호화의 대표적인 활용 사례는 아이디/패스워드 인증이다. 이용자가 설정한 패스워드는 일방향 암호화되어 데이터베이스에 저장되며, 관리자라 할지라도 패스워드 원문을 복호화 할 수 없다. 대신에, 이용자가 로그인 할 때마다 입력하는 패스워드를 동일한 알고리즘으로 암호화하여 이것이 데이터베이스에 저장된 암호문과 일치하는지 확인함으로써 이용자가 그 아이디/패스워드의 주인임을 알아볼 수 있다. 요컨대, 복호화는 ‘식별’의 필요조건이 아니다. &nbsp; 설령 IMS가 1기 암호화 시절 제공받은 정보를 이미 폐기했거나, 혹은 1기 당시 없었던 환자가 2기 때 새로 나타났다 하더라도, 다른 방법을 통해 주민번호를 복원하는 것이 가능하다. 무작위 대입 공격(brute force attack)이 그것이다. 0세부터 100세까지 한국인이 가질 수 있는 주민번호의 경우의 수는 약 70억 개이다. 70억 개의 후보를 하나씩 암호화해서 2기 때 제공받은 암호문과 대조해보는 방법으로 주민번호 원문을 알아낼 수 있다. 70억 분의 1 확률의 암호 해독은 현대의 슈퍼컴퓨터가 순식간에 끝낼 수 있다. 참고로 비트코인 채굴을 위해 요구되는 암호화 퍼즐의 난이도는 무려 1해 분의 1 정도로 훨씬 높은데, 이것이 불과 10분 주기로 풀리고 있다. 빅데이터 회사로서 상당한 컴퓨팅 파워를 갖춘 IMS의 관점에서 볼 때, 2기 암호화된 정보를 가리켜 ‘원천적으로 복원 불가능하다’고 단정하기는 곤란하다. &nbsp; 이러한 맥락에서, 일본의 익명가공정보 가이드라인은 "해시함수를 사용하여 개개인의 고유 정보(예: 신용카드번호) 등으로 임시 ID를 생성하려 할 때 원래 기술(記述)에 동일한 해시함수를 단순 적용하면 복원할 수 있는 규칙성을 갖게 될 가능성이 있다."고 해설하고 있다. &nbsp; 강조하건대, 일방향 암호화를 한다고 해서 항상 ‘식별성’이 제거되는 것은 아니다. 이에 대한 심리가 1심 판결에서 충분히 이루어지지 못한 점은 아쉽다. &nbsp; &nbsp; 4. 3기 암호화된 정보의 개인정보 여부 성명, 생년월일, 성별로 환자를 특정할 경우에도, 세 정보가 모두 동일한 동명이인의 경우를 제외하고는, IMS는 이미 알고 있는 환자 정보를 동일한 알고리즘으로 암호화한 후 3기 때 제공받은 암호문과 일치하는지 대조하는 방법으로 특정 개인을 쉽게 알아볼 수 있다. 한편, IMS가 그 정보를 모르는 환자에 대해서는 원문이 주민번호라는 13자리 숫자일 경우와 비교할 때 ‘무작위 대입 공격’이 상당히 어려울 것이다. 따라서 이 부분 ‘개인정보’ 해당여부 판단은 사안에 따라 유동적일 수 있을 것이다. &nbsp; &nbsp; 5. 시사점 개인정보의 보호와 활용 간 균형점을 모색하고자 하는 사법부의 노력은 매우 고무적이다. 그렇다고 하더라도 개인을 충분히 알아볼 수 있는 정보를 가리켜 ‘개인정보’가 아니라고 판단해버리면, 그 반작용을 우려할 수밖에 없다. &nbsp; 예컨대 2008년 옥션은 서버 관리자 초기 패스워드(공공에 알려진 값)를 그대로 방치한 중과실로 인해 주민번호 1800만 건을 해킹 당하는 참사를 초래했지만, 법원에서 과실이 없다고 판단되었다. 그 후 성난 여론으로 인해 정부의 규제가 급속도로 강화되어, 이제는 해킹을 당한 사업자들이 조금만 부주의했어도 법적 책임을 피하기 어렵게 되었다. &nbsp; 이처럼 신기술의 영역에서 법제도가 냉탕과 열탕을 오가는 상황은 바람직하지 않다. 이를 피하기 위해서는 사법부가 구체적 타당성에 맞는 결론을 내릴 수 있도록 기술적 전문성을 보완해야 한다. 일선 법원에서 소프트웨어 전문가를 전문심리위원으로 활용하는 방안을 고려해 봄직하다. 전승재 변호사 (법무법인 바른)

www.lawtimes.co.kr

1
0
1
1