오

빨리 팀을 만들어서 일정도 짜고 회고도 하고 회식도 하고 했으면 좋겠다. 그러기위해 어서 MVP를 완성하자.

@noxowlSuyeong RHIE @kodingwarriorJaeyeol Lee @gagl3 안 그래도 지난주에 그 바에 대한 얘기가 나오기도 했었습니다!

RE: https://hackers.pub/@diarapin/0195c6a1-c2e0-722d-8b72-136ce75dcf93

"그런 백엔드 기술로 괜찮은가?"

• 대상 : 다양한 기술과 도메인에서의 실무 문제 해결 사례를 통해 실질적인 인사이트를 얻고자 하는 개발자
• 일시 : 2025.04.20(일) 13:00 ~ 17:00 KST
• 장소 : 테크살롱 (서울 강남구 테헤란로 411, 성담빌딩 13층)
• 기타 : 주차 지원이 어려우니 대중 교통 이용을 권장드립니다.

https://www.inflearn.com/course/offline/게으른게발자컨퍼런스-2025

Chrome Built-In AI (EPP)で変更

Canary 136.0.7103.0* 以降、すべての組み込み API に新しいエントリ ポイントがあります。 self.ai.* ではなく、self.* で直接 API を見つけることができるようになりました。静的 create() メソッドを使用して、これらの API をインスタンス化します。

await LanguageModel.create();
await Summarizer.create(); 
await Writer.create();
await Rewriter.create();
await LanguageDetector.create();
await Translator.create();

同様に、静的 availability() メソッドが追加されました。

await LanguageModel.availability();
await Summarizer.availability();
await Writer.availability();
await Rewriter.availability();
await LanguageDetector.availability();
await Translator.availability();

Hackers' Pub 行動規範を拝見し、その根底にあるキーワードは「尊重」と「思いやり」だと強く感じた。だからこそ、僕はHackers' Pubを心から応援している。時間が経っても、その価値観がブレずに、前向きで明るいエネルギーがあふれる場所であってほしい。

それと、もうひとつだけ言うと、開発者のちょっとした日常の話とかも、もっと共有されるといいなって思う。（まずは自分から始めなきゃだけどね）

Hackers' Pub 행동 강령을 관통하는 큰 키워드가, 존중과 배려라고 느꼈고, 그래서 더욱 Hackers' Pub 을 응원하고 있는데, 오랜 시간이 흘러도 추구하는 가치에 흔들림이 없으면 좋겠고, 여기에 더해 긍정적이고 밝은 에너지가 가득한 공간이 되기를 소망한다.

한가지만 더 첨언하자면, 개발자의 소소한 일상 얘기들도 많이 공유되었으면 좋겠다. (우선 나부터도 해야겠지만)

그것 아십니까? 國立國語院(국립국어원)은 漢字(한자) 【茶(다)】에 本音(본음)인 「다」 말고는 慣用音(관용음) 「차」가 있다는 것을 認定(인정)하지 않습니다. 그 代身(대신), 【차】가 이미 固有語化(고유어화)된 낱말이라고 봅니다. 그래서 《標準國語大辭典(표준국어대사전)》에서도 【다례】는 【茶禮(다례)】라고 밝히면서도 【차례】는 【차禮(예)】라고 밝히고 있습니다…

사실 Hackers' Pub은 저희 집 홈 서버인 Mac mini M4 깡통 모델에서 돌아가고 있을 뿐만 아니라, 배포도 compose.yaml 파일의 image: 필드를 매번 손으로 고친 뒤 docker compose up -d를 치는 전근대적인 방식으로 이뤄지고 있습니다… 뭔가 자동화를 하고 싶긴 한데 귀찮은 마음이 커서 아직까지 이대로 살고 있네요.

내년 React Summit Asia는 싱가포르에서 열리는군요! 기회가 된다면 한번 꼭 가 보고 싶네요 🤩

https://x.com/ReactSummit/status/1906718835668906104

@analoggreenMTG @kodingwarriorJaeyeol Lee 님은 인싸 맞죠…

@xtjuxtapose ActivityPub의 한계는 아닌데 Mastodon을 비롯한 주요 구현들이 지원을 안 하는 건 사실입니다. 음… SVG를 업로드하면 Hackers' Pub 내부에서는 SVG로 보여주고 ActivityPub으로는 래스터화해서 보내는 식으로 편법을 쓸 수는 있을 것 같네요.

https://learnbyexample.github.io/learn_perl_oneliners/one-liner-introduction.html https://learnbyexample.github.io/learn_ruby_oneliners/one-liner-introduction.html

대화형 쉘 환경에서 Perl / Ruby 한줄짜리 스크립트를 짜는 방법을 소개. awk/sed 같은 스크립트를 쓰지 않고도, stdin으로 넘어온 입력을 가독성 있는 코드로 처리하기 좋음.

昨年までは、DB設計において uuid を使わないキー値には int よりも bigint を優先していた。しかし今では、ログのような頻繁に書き込まれるデータでない限り intを使うようになった。

bigint を採用していたのは将来の拡張を見据えた判断だったが、自分が開発するサービスでは int の上限（約20億）を超えることはまずないと気づいた。そして、いつか bigint に移行しなければならない規模のサービスに成長してほしいとも思っている。

불과 작년까지도, DB설계시에 uuid 를 쓰지 않는 키값은 int 보다 bigint 를 선호했으나, 이제는 로그성 데이터같은 빈번하게 등록되는 데이터가 아닌 이상 int 를 사용한다. bigint 의 사용은 당연히 미래를 위한 결정이었지만, 내가 만드는 서비스들이 웬만해서는 int 를 뛰어넘지 않는다는 것을 깨달았고 (약 20억이면 충분), 언젠가 bigint 로 마이그레이션해야 하는 서비스가 되었으면 좋겠다.

인용한 글의 내용과는 상관 없는 이야기인데, 현재는 단문에서는 단문이든 게시글이든 인용할 수 있는 반면, 게시글에서는 단문도 게시글도 인용을 못 하게 되어 있다. 별 생각을 안 하고 그렇게 만든 거긴 한데, 잘 생각해 보니 오히려 인용 기능은 게시글에서 더 유용할 것 같다.

하루 빨리 게시글에서도 인용이 가능하게 개선을 하도록 하겠습니다…

RE: https://hackers.pub/@xt/2025/stackage-why

여러분 저 이거 추천사 썼어요

https://social.silicon.moe/@aladin_itbook_notifier/114260705422505137

@lionhairdino 저의 영업력 + 물 들어올때 빠른 속도로 노젓는 홍민희님의 피지컬! (아님)

"pub"의 외래어 표기법에 따른 표기는 "펍"이 아니라 "퍼브"입니다. 유성음으로 끝나는 단어라서 "ㅡ"를 붙입니다. 이것은

• log: "록"이 아니라 "로그"
  • blog: "블록"이 아니라 "블로그"
• tag: "택"이 아니라 "태그"
• egg: "엑"이 아니라 "에그"
• dog: "독"이 아니라 "도그"
• mug: "먹"이 아니라 "머그"
• hub: "헙"이 아니라 "허브"
• pad: "팻"이 아니라 "패드"
• lid: "릿"이 아니라 "리드"
• mud: "멋"이 아니라 "머드"

등등, 유성음으로 끝나는 영어 단어에 일관적으로 적용되는 규칙입니다.

보통 외래어 표기법의 규칙이 무시되는 사례를 보면, 규칙이 모호성을 낳는다는 이유로 기피되는 경향이 있는데요. 예를 들어 "seat"와 "sheet"를 구분하려는 욕망으로 인해 /ʃiː/를 "시"로 표기하는 원칙을 깨고 후자를 "쉬트"로 적는 것이 있죠.

그런데 유성음으로 끝나면 "ㅡ"를 붙인다는 규칙은 원어의 유성 음가를 반영하는 동시에, 대체로 모호성을 해소하는 방향으로 표기를 만들어 주는 좋은 규칙입니다. 이 규칙이 없었으면 꼼짝없이

• "dog"와 "dock"이 "독"이라는 동음이의어가 되고
• "pig"와 "pick"도 "픽"이라는 동음이의어가 되고
• "rug"와 "luck"도 "럭"이라는 동음이의어가 되고
• "tag"와 "tack"도 "택"이라는 동음이의어가 되고

영 좋지 않았겠죠.

이 공간에서 그럴 분이 안계실 거라 생각하지만...

만우절이라고 정치나 재난을 주제로 과도한 농담이 등장하지 않았으면 하는 바람이 있습니다.

많은 부분 Hackers' Pub에서 이미 사용하고 있는 패턴들. 그리고 기본 키를 uuid로 했을 때 지역성(locality)가 떨어져서 성능상 손해를 보는 문제는 UUIDv7을 쓰면 해결된다.

RE: https://sns.lemondouble.com/notes/a61hofry16

(비슷한 상황의 프로젝트가 있음) 남일같지 않아서 조금 눈물이 납니다. 😂

vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.

Git 관련 유틸리티 중에 이런거 없을까요?

개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;

커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.

한줄 요약

• 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.

프로그래밍 언어 하스켈은 1990년 4월 1일에 처음 나와 올해 35주년이 되었습니다. 오늘이 하스켈 생일이에요. 이거 만우절 농담 아니고 진짜예요.

ADHD의 글쓰기 - 내용이 순서대로 정리되지 않고 여기저기 분산되어있음....... 결론이랑 뱀발이랑 도입부랑 순서가 뒤죽박죽임...

@hongminhee洪 民憙 (Hong Minhee) @thx땡스바 오웃! 응원하겠습니다! がんばれ！洪さん!

@hongminhee洪 民憙 (Hong Minhee) 아앗. 기능추가를 재촉하는 글은 아니었습니다! (맞음 😂)

@bglbgl gwyng @kodingwarriorJaeyeol Lee 요금제도 매력적이지만, 저는 말씀주신 부분이 가장 강력한 매력으로 다가오네요

저는 VS Code를 오래 써서, Cursor든 Windsurf든 VS Code 포크들은 아무 비용없이 갈아탈수 있었는데요.

저 역시 Cursor 로 반나절만에 갈아탈 수 있었고 (사실상 사용법의 차이가 없으므로) 과거 Sublime Text 부터 이어져 오는 비슷한 느낌들 때문에 이질감 없이 접근할 수 있어서 좋네요.

Hackers' Pub 에서 좋아요 느낌을 표현하고 싶을 때

• 공유 혹은 댓글을 다는 방법이 있겠고
• 그냥 지나치기는 아쉬워서
• (우선은) 공유를 하고 있기는 한데,

잘하고 있는건가 싶은 생각이 들 때도 있다.

개인적으로 공유는 팔로워들에게 공유하고 싶을 때 쓰고 싶은 기능인데… 최근에 다소 남발하게 된다.^[1]

서로 멘션 주고 받다가, 답글 마지막에 좋아요 하트 느낌으로 마무리 짓고 싶은 마음 뿜뿜할 때에도, 그냥 아무말 안하고 마무리 하기도 하고. (이모티콘 댓글 정도를 남긴다거나 하는 방법은 있음)

@hongminhee洪 民憙 (Hong Minhee) 님이 이모티콘 좋아요 기능을 고민중이라 하시니, 그때까지는 좀 더 공유 기능을 남발해 보는 걸로. 😂

결론 : 이 글은 무차별 공유에 대한 자기 합리화를 위한 글이었던 것입니다. 😅

Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.

내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.

1. 신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.

2. GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)

3. 바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput

물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.

인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.

GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.

Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.

참고로 Hackers' Pub은 딱 한 번 뿐이긴 하지만 핸들을 바꿀 수 있답니다.

사실 ActivityPub이나 WebFinger 명세에서는 핸들을 바꿀 수 없다는 제약이 있지는 않아요. 다만 대부분의 ActivityPub 구현들이 액터 ID에 핸들의 일부를 포함시키기 때문에 바꿀 수 없게 되었을 뿐…^[1]

자세한 설명은 Fedify 문서의 Actor identifier and WebFinger username 항목을 읽어보시면 됩니다.

RE: https://serafuku.moe/notes/a6199pgz4v

そういえば今週の金曜日に第8回FediLUG勉強会が有る。すっかり忘れていた。早く発表資料を準備しないと。😱

We're incredibly honored to announce that #Ghost (@indexBuilding ActivityPub) has become a formal sponsor of Fedify through Open Collective!

This is a significant milestone for our project, and we're deeply grateful to @johnonolanJohn O'Nolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.

Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.

If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:

https://opencollective.com/fedify

Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️

@kodingwarriorJaeyeol Lee 성수동 코딩클럽??

언젠가 해커스펍 오프라인 밋업 같은 거 하면 사진기사 겸 봉사자로 놀러가고 싶음

이제 지브리나 교애니 풍의 그림은… “지피티풍”이라고 해야하나… 지브리나 교애니는 이제 어떤 그림을 그려야 하나?

나는 코파일럿(클로드)와 클로드 데스크탑과 클로드 코드와 함께 주로 작업을 하니… 내 코드는 “클로드풍”인가? 나는 이제 어떤 코드를 만들어야하나?

Gitlab은 특히 내가 가장 눈여겨보던 오픈소스 프로젝트 중 하나였는데, 실제로는 Vue가 어떻게 하이브리드로 섞여서 쓰고 있는지 생각하면서 읽는 재미가 쏠쏠함

@ysh염산하 Vue도 Vue 나름대로의 장점이 있습니다. 개인적인 개발경험을 생각해봤을때 Rails/Django/Laravel 같은 전통적인 MVC 프레임워크랑 궁합이 좋거든요.

레트로 웹 마니아 @limeburstJihyeok Seo 가 만든 호스팅 플랫폼 나루(https://naru.pub/)에 나도 2005년 감성의 홈페이지를 하나 깎아서 띄워볼까 함…(2005년인 이유: 내 html, css, js 지식이 20년 전에 멈춰있음)

뉴욕 어딘가에는 컴파일러/DB/웹브라우저 등등 인터널을 까보면서 얘기하는 소셜클럽이 있다. 완전 비슷하게는 아니더라도 해커스펍을 중심으로 밋업을 하는것도 괜찮을지도? 밋업에 참여하는 외부인이 오면 초대장도 그때그때 발급해주는식으로 가고

https://eatonphil.com/nyc-systems-coffee-club.html

해커스펍 DAU 50 가보자고

Polymarket 등의 예측 시장에는 오라클 문제가 있다. 블록체인으로 만들어봤자, 어차피 베팅의 승패를 결정하려면 외부에서 딸깍 해줘야한다. 가령 4월 내에 탄핵이 이뤄질거냐 마냐 같은 게임을 상상하면 된다. 그 딸각하는 사람을 어떻게 믿을수 있냐는 문제가 오라클 문제다.

오라클 문제가 없는 예측 시장이 하나 생각났는데, 바로 수학 문제가 언제 풀릴 것이냐에 대한 것이다. 가령 리만 가설이 앞으로 1,000,000 블록 내에 풀릴지, 또는 P=NP랑 둘 중에 뭐가 먼저 풀릴지 등에 대한 것이다. 여기서 풀리는건 Lean 등으로 작성된 Formal Proof을 통해서 온체인으로 판단한다.

수학자들은 자신이 베팅을 걸어놓고 연구를 열심히해서 돈을 벌 수도 있다. 또 직접 연구를 하지 않더라도 GPU를 사서 자신의 베팅에 유리하도록 연구에 도움을 줄 수 있다. 앞서 그냥 유명하단 이유로 너무 거창한 문제를 예시로 들었는데, 그보다는 더 작고 쉬운 많은 문제들에 대해 이런 식의 경제가 돌아가는걸 상상해보자. 연구에 들어가는 자원 배분이 최적화되지 않을까?

좋은 글 잘 읽었습니다. 글도 잘 쓰시고 코딩도 잘 하시고 부럽습니다. 본문 내용 중 ‘두부와 강철 영수증’이란 표현이 재밌네요. ‘오라클’이라는 전문 용어도 처음 알게 되었습니다. 과거에 하시던 블록체인과 현재 하시는 액티비티펍이 뭔가 탈중앙화라는 공통 분모가 있는 것 같네요.

북적북적 해커스펍

저도 최근 VSC에서 Zed로 넘어오게 됐습니다. 특히 블로그 글을 mdx로 작성하는 입장에서, 플러그인 없이도 mdx 문법과 미리보기를 지원하는 Zed가 정말 마음에 들었어요. 하지만 내장 터미널에서 한글 사용 시 글자가 제대로 표시되지 않고, 일부 작업 시 Zed가 강제 종료되는 문제가 생겨서 최근 이슈를 제보했습니다.

https://github.com/zed-industries/zed/issues/26036

https://github.com/zed-industries/zed/issues/27599

https://hackers.pub/@hongminhee/0195e9c3-2bc8-712a-a38e-aa355335ab0b/shares

@hongminhee洪 民憙 (Hong Minhee) <joke>조용히 눈에 안 띄고 싶었지만 최고관리자의 우렁찬 호명으로 존재가 드러나 버렸습니다. 왜 계정을 만들자마자 글도 쓰기 전에 팔로어가 일곱 명이나 붙었나 했더만 이거였군요. 조용히 눈에 안 띄고 살 권리를 관리자가 빼앗아갔습니다.</joke>

해커스펍을 어떻게 사용해볼까 하다가, 우선 한동안은 블로그에 작성하는 글을 공유해보기로 했습니다.

오늘 공유할 글은 React의 디자인 패턴 중 하나인 Container/Presentational 패턴에 관한 글입니다. 예전에 교육 프로그램을 들을 때 팀 프로젝트로 Next.js 기반의 서비스를 구현한 적이 있는데, 해당 프로젝트의 회고를 진행하면서 컨테이너 패턴을 사용했다고 착각했습니다. 최근 이력서 피드백을 받다가 이를 깨달아서, 그렇다면 컨테이너 패턴은 뭔지, 그렇다면 제가 프로젝트에 사용했던 패턴은 과연 무엇이었는지를 글로 옮겨 봤습니다.

https://hoonieblog.xyz/blog/study-react-container-presentational-pattern