@morealLee Dogeon 전 그때그때 다른 것 같습니다. 보통 그 당시에 가장 관심 있고 만들고 싶어하는 걸 그냥 바로 도전하는 것 같아요.
Lee Dogeon
@moreal@hackers.pub · 82 following · 75 followers
어느 한 개발자입니다.
GitHub
- @moreal
@hongminhee洪 民憙 (Hong Minhee) 의견 감사합니다!
Q. 새로운 프로그래밍 언어를 공부할 때, 연습용으로 사용하시는 프로젝트(카타?)가 있으신가요?
게시글에 목차가 추가되었습니다. 게시글 안에 소제목이 있을 경우에는 목차가 보이게 됩니다. 가로로 넓은 화면에서는 오른쪽에 보이고, 모바일 환경처럼 가로로 좁은 화면에서는 제목 아래 본문 위에 보이게 됩니다.
.vimrc 파일 공유하던사람들끼리 창업해서 CLI 깎는 회사 만들고 6백만달러를 펀딩받았다는 이야기가 있다. 나는 이 이야기를 아주 좋아한다.
https://choubey.gitbook.io/internals-of-deno
Deno 런타임 내부 까보는거 입문은 이걸로 시작해야겠다
저… 제가 아마도 해커스펍 개발자분보다도해커스펍 서버와 가장 가까이서(2미터 거리) 쓰고 있는 유저인데…
느려요.
RE: https://hackers.pub/@hongminhee/0195d567-06d6-7437-a4eb-cf567adf9714
Lee Dogeon shared the below article:
Browser-Native Translation and Language Detection APIs Coming Soon
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Just reviewed the W3C draft for the Translator and Language Detector APIs. This is genuinely exciting development for web developers.
The proposal would add native browser support for:
- Text translation between languages
- Language detection of arbitrary text
- Both with streaming capabilities
No more relying on third-party translation services or embedding external APIs for basic language operations. All processing happens locally in the browser.
The API design is clean and straightforward:
// Translation example
const translator = await Translator.create({
sourceLanguage: "en",
targetLanguage: "fr"
});
const translatedText = await translator.translate("Hello world");
// Language detection example
const detector = await LanguageDetector.create();
const results = await detector.detect("Hello world");
// Returns array of detected languages with confidence scores
This will be a game-changer for multilingual sites and applications. The browser handles downloading appropriate language models and manages usage quotas.
The spec is still in draft form but shows promising progress toward standardizing these capabilities across browsers. Looking forward to seeing this implemented.
@xiniha 님께서 Hackers' Pub에 눈에 보이진 않지만 큰 기여를 해 주셨습니다. Drizzle ORM 베타 버전에서 쓸 수 있는 릴레이셔널 API v2를 Hackers' Pub 코드 전체에 적용하는 큰 패치가 바로 그것입니다.
기능적으로 눈에 바뀌는 것은 없겠지만, 아마 성능상으로는 약간의 개선이 있을 수 있습니다. 기존에는 복잡한 관계 필터를 서브쿼리 방식으로 해 왔는데, 릴레이셔널 API v2를 쓰면 JOIN으로 바뀌는 것 같아요. 물론 PostgreSQL의 쿼리 최적화기가 뛰어나다면 두 방식 중 어떤 방식을 쓰든 같은 실행 계획을 수립할 것이므로 성능 차이가 없을 수도 있지만요. 아니면 더 느려질 수도 있겠죠. 거기까지 세세하게 비교 테스트해보진 않았습니다. 😅
참고로 해당 변경은 이미 배포된 상태입니다. 아무튼 고생해주신 @xiniha 님께 박수 부탁드립니다. 👏
Hackers' Pub의 타임라인 탭 중 “언급” 탭이 “언급 및 인용” 탭으로 바뀌었습니다. 날 언급한 글 뿐만 아니라, 내가 쓴 글을 인용한 글도 함께 보이게 됩니다. 본격적인 알림 기능이 생기기 전까지는 이 탭을 잘 활용하시면 좋을 것 같습니다.
https://news.hada.io/topic?id=19948
나는 프로그래밍을 Solaris에서 시작했고, FreeBSD의 오랜 팬이자 사용자였지만, 이제 와서는 BSD를 권하지 않음. 내 개인적으로도 이젠 더이상 쓰지 않고 있고. 물론 BSD가 특정 시나리오에서는 매우 뛰어난, 그리고 일반적으로 좋은 서버 OS라는 점은 지금도 유효하지만, 더이상 개인이 사용할 우위점은 거의 없다고 생각함.
- 리눅스가 충분히 안정화되었고, 가장 안정적인 OS를 찾는다면 RHEL(+클론들)을 쓰면 됨. 대형 유저들이 많으며, 전문가 집단이 구성하고 충분히 테스트한 OS임.
- 리눅스가 de facto standard여서, 더 효율적인 솔루션들이 있더라도 작은 차이라도 큰 특수 분야가 아니라면 굳이 다른 방법을 찾는 비용을 정당화하기 어려움. 무엇보다 유지보수, 확장, 인프라 이전 등 모든 면에서 리눅스가 제일은 아닐지 몰라도 충분히 쌈.
- 보안에 있어서도 OpenBSD의 품질은 대단하지만, 대형 리눅스 배포판들 또한 취약점 패치 속도에서 매우 빠른 편이고 보안 툴들도 잘 갖추고 있음. 이제 양자간 개발자, 사용자 숫자의 차이는 인원과 설계의 질로 메꿀 수 있는 수준이 아니라고 봄.
Lee Dogeon shared the below article:
Hacker's Pub에 입문한 한국어권 여러분을 위한 안내서
Jaeyeol Lee @kodingwarrior@hackers.pub
Hacker's Pub은 소프트웨어 업계 종사자들이 자유롭게 생각을 공유하고 소통할 수 있는 소셜 네트워크 서비스이자 블로깅 플랫폼입니다. ActivityPub 프로토콜을 지원하여 Mastodon, Misskey 등 다른 SNS 서비스 사용자들과도 연결되어 플랫폼 경계를 초월한 소통이 가능합니다. 이 글에서는 Hacker's Pub의 의미와 ActivityPub 프로토콜에 대한 간략한 소개, 그리고 커뮤니티에 기여할 수 있는 다양한 방법을 제시합니다. 오픈 소스로 개발되는 Hacker's Pub 생태계에 참여하여 함께 서비스를 발전시키고, 우리만의 클라이언트를 만들어 Hashnode와 같은 블로그 템플릿을 구축하는 미래를 기대해 볼 수 있습니다. Hacker's Pub은 상호 존중과 신뢰를 바탕으로 모든 이들이 자유롭게 의견을 나누고 함께 만들어가는 공간입니다.
Read more →@morealLee Dogeon
배려 감사합니다!
Tiny Tiny RSS에서 잘 되는 걸 보니, RSS-Parrot 문제 같기도 해요. 그러면 어쩔 수 없죠. 
@FoW RSS-Parrot이 오픈소스인 덕분에 소스를 확인할 수 있어서 원인을 찾았습니다! 원인만 찾고 의도는 이해하려고 하지 않아서 불완전한 설명이지만, RSS-Parrot이 주어진 링크의 쿼리 파라미터를 모두 제거해서 발생하는 문제였어요:
// at https://github.com/gugray/rss-parrot/blob/238e98b2736a047064f4b696a9aff28ccf7b8a1c/src/server/logic/feed_follower.go#L139
ff.trimQueryParams(feedUrl)
// at https://github.com/gugray/rss-parrot/blob/238e98b2736a047064f4b696a9aff28ccf7b8a1c/src/server/logic/feed_follower.go#L147-L170
func (ff *feedFollower) trimQueryParams(feedUrl *url.URL) {
// ... 생략 ...
feedUrl.RawQuery = ""
}
때문에 임시로 menuNo 쿼리 파라미터를 선택적으로 넣을수 있게끔 하였고, 첨부한 스크린샷처럼 등록에 성공하는 것을 확인했어요.
하지만 한국은행에 RSS를 요청할 때 menuNo를 쿼리 파라미터로 넘겨주지 않으면 한국은행 원본 페이지로 가는 링크가 제대로 생성되지 않는 문제가 있습니다. 때문에 사실상 필수적으로 입력해야하는 요소이므로 menuNo 쿼리 파라미터를 필수로 받게끔 다시 롤배갛고, RSS-Parrot 측에서 쿼리 파라미터를 보존하는 패치를 하기 전까지는 등록이 되지 않을 예정이에요. 참고 부탁드립니다!
Hackers' Pub에서는 Markdown 내용 안에 HTML을 어느 정도 (XSS을 허용하지 않을 정도) 허용하고 있습니다. 그래서 <abbr>, <kbd>, <ruby> 같은 태그를 써서 좀 더 풍성한 서식화가 가능합니다.
블루스카이를 연합우주보다 먼저 썼고, 해커뉴스에서 관련 주장에 대해서 꽤 싸우기도 한 입장에서 민희님의 글 〈Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다〉에 대한 반대 의견을 제시하고자 한다. 이 의견이 연합우주에 대한 전면적인 비판이 아니라는 것을 의견을 제시하기에 앞서 확실히 해 둔다(그랬다면 Hackers' Pub에 들어 올 일이 없었겠지).
탈중앙화는 매력적인 개념임이 틀림 없다. 인터넷의 많은 중요한 요소들이 어느 정도 탈중앙화되어 있으므로 탈중앙화가 인터넷의 장점들에 큰 몫을 했다는 생각을 쉬이 할 수 있고, 어느 정도는 그게 사실이기도 하니까. 하지만 엄밀히 말하자면 탈중앙화는 기술적인 특징이지 그 자체로 장점이 아니며, 탈중앙화가 장점으로 작용하려면 연결고리가 필요하다. 이를테면 비트코인을 위시한 암호화폐는 본디 비잔틴 실패까지 대비할 수 있는 강력한 탈중앙화를 장점으로 내세웠으나, 결국 화폐로서 제대로 사용되기 시작하자 현실 경제와의 커플링 때문에 그 "장점"이 크게 희석되고 말았다. 현 시점에서 암호화폐는 무에서 유의 신뢰를 창조하여 신용화폐의 요건을 충족하는 데까지는 성공했고 그것만으로도 역사적인 일이기는 하지만, 그게 탈중앙화랑 무슨 상관이 있느냐 하면 글쎄올시다.
블루스카이가 연합우주보다 덜 탈중앙화되어 있음은 분명하다. 민희님의 글에서 지적되었듯, 블루스카이가 이런 선택을 한 가장 큰 이유는 온전한 소셜 네트워크 기능을 위해 전역 뷰가 필수적으로 필요하다고 보았기 때문이다. 반대로 말하면 연합우주는 더 탈중앙화를 하기 위하여 전역 뷰를 포기했는데, 이 때문에 연합우주에서의 "소셜 네트워크"는 트위터/X와는 구조가 크게 다르다. 노드 규모가 문턱값에 다다르지 못하면 다른 노드에 있는 사용자를 찾아서 팔로해야만 온전한 소셜 네트워크 구성이 가능한데, 연합우주 안에서는 이런 외부 사용자를 찾는 구체적인 방법을 제공하지 않는다. 물론 인터넷과 똑같이 검색 엔진이 존재할 수야 있겠지만, 크롤링으로 인한 부하와 프라이버시에 대한 의견 차이 때문에 현실적으로 작동하는 연합우주 내 검색 엔진은 없다고 알고 있다. 따라서 연합우주에서 소셜 네트워크의 구성은 연합우주 바깥의, 보통은 중앙화되어 있는, 다른 소셜 네트워크(이를테면 현실 인간 관계)를 빌어야만 하는데, 이러면 탈중앙화가 큰 가치가 있을까?
한편으로는 전역 뷰가 소셜 네트워크의 단점이라고 주장할 수 있는 여지도 있다. 트위터/X를 오래 써 본 사람이라면 다 알겠지만 한 무리의 사람들이 다른 의견을 가진 무리와 충돌하는 주된 통로는 검색이나 해시태그를 통한 노출, 즉 전역 뷰이기 때문이다. 그러나 현실의 규모 있는 연합우주 노드들을 살펴 보면 각 노드가 곧 한 무리에 대응하는 식으로 충돌을 미리 회피하는 형태로 구성되지, 딱히 이런 충돌을 막기 위한 접근을 가지고 있는 것은 아니다. 노드 운영자를 위해 차단하는 걸 추천하는 서버 목록 같은 게 돌아다니는 건 연합우주 바깥의 일이지 않는가. 결국 전역 뷰의 역할을 대체하는 소셜 네트워크 바깥의 또 다른 소셜 네트워크가 존재할 것이기에, 우리가 소셜 네트워크를 어떤 이유로든 유용하다고 여긴다면 전역 뷰가 없는 게 장점이 될 수는 없다.
모든 이들이 이런 사고 과정을 가지고 블루스카이나 연합우주를 선택했다고 생각하진 않지만, 적어도 현 시점에서 사용자들은 블루스카이(이 글을 쓰는 시점에서 약 3360만명)를 연합우주(FediDB와 Fediverse.party로부터 추정할 때 최대 1530만명)보다 선호하는 것은 틀림이 없다. 게다가 블루스카이의 규모는 최근 1년 사이에 10배 불어난 것이고, 조금 장애가 있었지만 현재는 잘 동작하는 것으로 보인다. 위의 논의와 결합해 보면, 블루스카이는 정석적인 스케일링에 성공하고 있는 반면 연합우주는 스케일링 문제를 회피하기 위해 온전한 소셜 네트워크의 구성을 포기했다고 볼 수도 있는 대목이다. 블루스카이가 못미더운 부분은 분명히 존재하지만, 연합우주가 더 좋은 소셜 네트워크 경험을 제공한다고 가정하고 블루스카이의 단점을 제시할 수는 없다. 마치 암호화폐를 논할 때 장점만 말할 수 없는 것과 마찬가지로 말이다.
RE: https://hackers.pub/@hongminhee/2025/bluesky-a-good-alternative-to-x-not-to-the-fediverse
@morealLee Dogeon
RSS 리더가 인식을 못했어요. 😿
@FoW 엇.. 사용하신게 https://rss-parrot.net/ 로 보이는데 디버깅 해보고 남길게요, 제보 감사합니다!
얼굴인식 사진공유 카메라앱 슈티를 함께 만들 분을 찾습니다. 앱은 출시되어 있어 써보실수 있습니다. 이번달 내로 페디버스 연동을 끝내면 제가 생각한 MVP는 완성입니다. 앞으로도 개발해야할 부분들이 많고, 개중에 기술적으로 흥미로운 문제들도 다수 있습니다.
지금 2025년 상반기 투자유치를 목표로 팀 빌딩을 하고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
한국은행은 여러 지표 및 보고서 등을 구독할 수 있도록 토픽 별 RSS 피드를 제공합니다. 하지만 <








