튜사에 왔는데 몰입형 공간이 꽉차서 더블 모니터를 못쓰는 관계로, 어쩔수없이 오늘은 하스켈을 좀 해야겠다...

洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 906 following · 630 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
OSSCA 발대식 옴
.NET으로 서버 만들 때는 이메일 보낼 때 FluentEmail이라는 패키지를 유용하게 썼는데, JavaScript 쪽에도 비슷한 게 있나 찾아봤지만 뭔가 다 조금씩 마음에 안 드네… 내가 원하는 건 다음과 같다:
- Mailgun, SendGrid, SMTP 등 다양한 이메일 전송 트랜스포트를 하나의 일관된 API로 사용할 수 있어야 한다.
- 멋대로 환경 변수에 의존하지 말아야 한다.
- Node.js는 물론 Deno에서도 동작해야 한다.
오히려 파일 첨부 같은 부가 기능은 없어도 되기 때문에 간단하게 필요한 라이브러리를 찾을 수 있을 거라고 생각했는데, 못 찾고 있다. 음… 바이브 코딩으로 하나 만들까?
결국 하나 만들었습니다. “우표”라는 이름으로…
I got suddenly inspired yesterday to build an email sending library for Node.js/Deno/Bun/edge functions. Meet Upyo: a TypeScript-first email library with a unified API that works across all JavaScript runtimes. It features pluggable transports (SMTP and Mailgun so far), built-in connection pooling, and comprehensive type safety. Still early days but already loving how clean the API turned out!
By the way, check out this cute Upyo logo here! Just FYI, 郵票 (upyo) means postage stamp in Korean. You can view the SVG source code on GitHub.
I got suddenly inspired yesterday to build an email sending library for Node.js/Deno/Bun/edge functions. Meet Upyo: a TypeScript-first email library with a unified API that works across all JavaScript runtimes. It features pluggable transports (SMTP and Mailgun so far), built-in connection pooling, and comprehensive type safety. Still early days but already loving how clean the API turned out!
洪 民憙 (Hong Minhee) shared the below article:
객체 프로퍼티 키 평가 과정
Lee Dogeon @moreal@hackers.pub
이 글은 AI도 틀리는 JavaScript 퀴즈를 풀면서 발견한 JavaScript의 흥미로운 동작 방식에 대한 탐구 과정을 담고 있습니다. 퀴즈의 예제 코드를 실행했을 때 예상과 다른 결과가 나타난 이유를 분석하며, JavaScript에서 세미콜론 자동 삽입(Automatic Semicolon Insertion) 규칙과 쉼표 연산자의 동작 방식을 설명합니다. 특히 배열이 객체의 프로퍼티 키로 사용될 수 있는 이유를 파악하기 위해 ECMAScript 명세를 깊이 파고들어 `Symbol.toPrimitive`라는 개념을 소개합니다. 이를 통해 객체가 프로퍼티 키로 사용될 때 JavaScript 엔진이 어떻게 객체를 문자열로 변환하는지, 그리고 `Symbol.toPrimitive`를 사용하여 이 동작을 어떻게 커스터마이징할 수 있는지 보여줍니다. 비록 퀴즈의 정답과는 거리가 멀어졌지만, 이 과정에서 얻게 된 새로운 지식을 공유하며 JavaScript의 숨겨진 동작 원리를 이해하는 데 도움을 줍니다.
Read more →洪 民憙 (Hong Minhee) shared the below article:
AI도 무조건 틀리는 Javascript 퀴즈
중고 자몽차(따뜻함) @dvbeetle@hackers.pub
이 JavaScript 퀴즈는 `age` 객체와 `preferences` 객체를 사용하여 각 이름에 대한 나이를 출력하는 문제입니다. `forEach` 메서드를 통해 배열의 각 요소(이름)를 `printAge` 함수에 전달하고, 이 함수는 템플릿 리터럴을 사용하여 "name is age" 형태의 문자열을 콘솔에 출력합니다. Claude Opus, GPT 4.5, Gemini 2.5 Pro와 같은 고급 AI 모델들도 이 문제에서 오답을 냈다는 점이 흥미롭습니다. 이 코드를 통해 JavaScript의 객체 접근과 배열 메서드 사용법을 다시 한번 상기할 수 있습니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) 요것이 사실 대표 오답입니다...! 다시 보시면 금방 찾으실지도...?
@dvbeetle중고 자몽차(따뜻함) 아,
preferences
가 안 쓰인다고 생각했는데 세미콜론이 없어서 뒤로 이어지는군요… JavaScript는 역시 어렵네요.
洪 民憙 (Hong Minhee) replied to the below article:
AI도 무조건 틀리는 Javascript 퀴즈
중고 자몽차(따뜻함) @dvbeetle@hackers.pub
이 JavaScript 퀴즈는 `age` 객체와 `preferences` 객체를 사용하여 각 이름에 대한 나이를 출력하는 문제입니다. `forEach` 메서드를 통해 배열의 각 요소(이름)를 `printAge` 함수에 전달하고, 이 함수는 템플릿 리터럴을 사용하여 "name is age" 형태의 문자열을 콘솔에 출력합니다. Claude Opus, GPT 4.5, Gemini 2.5 Pro와 같은 고급 AI 모델들도 이 문제에서 오답을 냈다는 점이 흥미롭습니다. 이 코드를 통해 JavaScript의 객체 접근과 배열 메서드 사용법을 다시 한번 상기할 수 있습니다.
Read more →@dvbeetle중고 자몽차(따뜻함) 출력은 대충 아래와 같을 것 같은데…
ruby is 18
ayumu is 19
siki is 20
근데 preferences
는 정의된 채로 전혀 안 쓰이네요?
1만 * 1만 = 1억 이 상식인줄 알았는데 아닌가 봅니다? 오늘만난 제 문과친구 두 명이 저걸 모르길래 뭐라했더니 저보고 별것도 아닌걸로 잘난척하지 말라고합니다. 상식... 아닌가요?
@bglbgl gwyng 부끄럽지만 모르고 있었습니다… 😂
튜링의 사과 매주 주말마다 간다고 계산하면... 한달에 10만원 쯤 나가는구나... 거기 그 민생지원금 사용 되나요????
@akastoot악하 12시간권 사면 좀 낫더라고요.
튜링의 사과 매주 주말마다 간다고 계산하면... 한달에 10만원 쯤 나가는구나... 거기 그 민생지원금 사용 되나요????
洪 民憙 (Hong Minhee) shared the below article:
내가 애정하는 터미널 도구들 - Wezterm 편

Jaeyeol Lee @kodingwarrior@hackers.pub
이 글은 개발 환경에서 자주 사용하는 도구인 Wezterm을 소개한다. dotfiles에 대한 간략한 설명과 함께, Rust 기반의 GPU 가속 터미널 에뮬레이터인 Wezterm의 특징과 장점을 설명한다. Linux, MacOS, 윈도우즈 등 다양한 환경에서 사용 가능하며, Lua 스크립팅을 통해 확장 가능한 기능을 제공한다. 폰트 설정, 단축키를 이용한 반투명도 조정, 탭 이름 변경, 시각적 알림 등 Wezterm을 커스터마이징하는 다양한 방법을 예시 코드와 함께 제시하여 독자들이 Wezterm을 쉽게 시작하고 자신만의 환경을 구축할 수 있도록 돕는다. Wezterm의 유연성과 사용자 정의 가능성을 강조하며, 독자들에게 생산성을 향상시킬 수 있는 강력한 도구임을 어필한다.
Read more →여성향 커미션 중개 플랫폼 크레페를 운영하는 쿠키플레이스에서 시니어 백엔드 엔지니어 채용을 진행중입니다. 채용공고에 해당 직무 소개, 복지, 연봉, 회사문화의 내용이 포함돼 있습니다. 많은 관심 부탁드립니다. Node.js, TypeScript, GraphQL에 대한 높은 숙련도 및 지식으로 팀에 기여해주실 분을 쿠키플레이스에서 극진히 기대하고 있습니다.
크레페에서는 이런 기술스택을 사용합니다
- Node.js, TypeScript, Vitest, Fastify
- GraphQL - Yoga, Relay, Pothos, Prisma
- ElasticSearch, MongoDB, FCM
- Docker, Github Actions
- AWS - ElasticBeanstalk, CloudWatch, Aurora PostgreSQL, Lambda, SES, S3, ElastiCache (Redis)
- Grafana, Sentry
구성원의 성장과 덕질을 지원해요
- 희망 도서 구매 (만화책 및 TRPG 룰북 포함)
- 워크샵 및 교육 프로그램 지원
- 전시, 공연 및 각종 행사 티켓 지원
- 월 5만 크레페 포인트
- 전동작탁 AMOS JP-EX COLOR
- 6인용 TRPG/보드게임 테이블
지원자님이 예상하실 수 있는 처우는 이래요
- 연봉: 최소 8000만원 ~ 최대 2억원 (주 40시간)
- 스톡옵션 부여에 열려있는 포지션
@hongminhee洪 民憙 (Hong Minhee) 아뉘 잠깐... 클로드가 쓴 결과물을 마우스로 긁으면 '업데이트'라고 피드백 줄수있는 메뉴가 뜨는데요?
@bglbgl gwyng 아, 네 그것도 종종 씁니다. ㅎㅎㅎ
@hongminhee洪 民憙 (Hong Minhee) 중간 수정같은건 어떻게 하시나요?
@bglbgl gwyng 수정을 구체적으로 지시해서 수정하거나, 아니면 제가 실제로 수정한 버전을 첨부해서 그 위에서 작업하게 시켜요.
AI 도움 받아 글쓰기할때 주로 어떤 방식으로 하시나요?
- 클로드 웹. 모델은 좋은데 인터페이스가 글쓰기 최적화는 아닙니다.
- Cursor/Windsurf 등. 모델이 코딩 고문을 당해서 그런가 글을 잘 못씁니다.
@bglbgl gwyng 저는 Claude 웹을 씁니다.
내가 예민한건가. LLM이 "여기서 as any
한 번 정도는 괜찮아요"라며 구슬린다
@mck 하지만 사람들도 많이 그럽니다…
내가 예민한건가. LLM이 "여기서 as any
한 번 정도는 괜찮아요"라며 구슬린다
이슈 적당히 어려워보이면서 할만해보이는걸로 고르니까 코드베이스가 더 잘 익혀진다
내일도 튜링의 사과 출근해야지
@bglbgl gwyng 앗… 저는 일요일에 가려고 했는데!
Diffsitter – A Tree-sitter based AST difftool to get meaningful semantic diffs
Link: https://github.com/afnanenayet/diffsitter
Discussion: https://news.ycombinator.com/item?id=44520438
@hongminhee洪 民憙 (Hong Minhee) 벌써내일이네요!!! 저도 기대가 됩니당 ㅎㅎ
@hjleee93hyeonjeong lee 네, 내일 뵙겠습니다…!
js 커뮤니티는 환경변수 주입 정도는 컴파일타임 의존성 주입처럼 생각하긴 하는듯. 과거에 subpath import, export 없을 때 많이 쓰이던 방식이 고착화된게 아닌가 하는 뇌피셜이 있음..
역시나 UCPC 일정으로 OSSCA 발대식 참여하기 어려운 분들이 많으시군아 흠흠
@kodingwarriorJaeyeol Lee Fedify 프로젝트에서는 두 분 불참하신다고 하셨어요.
내일은 OSSCA 발대식… 처음으로 기여자 분들 만나는 자리다. 어떤 분위기일까 걱정도 되고 기대도 된다.
어제의 나는 제정신이 아니였군 as any를 이렇게 남발하다니
洪 民憙 (Hong Minhee) shared the below article:
펑터Functor

lionhairdino @lionhairdino@hackers.pub
하스켈 펑터 입문자를 위한 이 글은 `Maybe Int` 타입의 값에서 `Int`를 직접 "꺼내올 수 없다"는 개념을 설명합니다. `Maybe`의 `fmap`이나 `fromJust`가 마치 값을 꺼내는 것처럼 보이지만, 이는 실제로는 값을 꺼내는 것이 아니라, 원본 타입(`Int`)의 구조를 보존하며 새로운 `Maybe Int` 타입의 값을 "생성"하는 과정이라는 것입니다. 미끄럼틀 비유를 통해, `Maybe Int`의 `Just 1`은 `Int` 값 `1`과 연관되어 있지만, `Just 1` 자체가 `1`을 의미하는 것은 아닙니다. 펑터는 원본 타입의 관계(구조)를 그대로 유지하며 다른 타입으로 변환하는 역할을 합니다. `fmap`은 `Maybe Int` 안의 `Int`를 직접 조작하는 것이 아니라, 원본 `Int` 값의 관계를 바탕으로 새로운 `Maybe Int` 값을 만들어내는 것입니다. 상자 메타포가 유용할 때도 있지만, 펑터의 본질을 오해하게 만들 수 있습니다. 상자 안의 값을 꺼내는 것이 아니라, 값의 "성격"은 값을 다루는 함수들의 동작에 따라 결정된다는 점을 강조합니다. 이 글은 "없을 수도 있는 수를 꺼낸다"는 표현의 모순을 지적하며, 펑터의 개념을 더 깊이 이해하도록 돕습니다.
Read more →예전에 카페에서 코딩하는데 처음 보는 사람이 보더니 혹시 프로그래머냐고 자기 좀 도와달라길래 무슨 문제냐고 하니까 자바 환경설정 좀 도와달라길래 바로 GG치고 튐
- 아직 OSSCA 튜토리얼 돌려보진 않았어서 빠르게 훑어보기
- @fedify/nestjs 계속 만드는 중인데, 한바퀴 돌려볼 수준으로는 만들어놓기 (만들다보니 이렇게 하는게 맞나 싶음....)
- 파이콘 발표 준비.....
- 파이콘에서 데모할 영상 녹화하기
- 파이콘 발표 슬라이드 대본 채우기
- Ubucon BoF 슬라이드 자료 완성하기
🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify!
👏 @gaebalgom개발곰 tackled a tricky terminal compatibility issue in PR #282, fixing the
fedify node
command's favicon display on terminal emulators without truecolor support (#168). His solution elegantly detects terminal capabilities and falls back to 256-color mode when needed—ensuring a great experience across different environments.
🌟 @joonnotnotJoon enhanced Fedify's #WebFinger functionality in PR #281 by adding a configurable
maxRedirection
option to the lookupWebFinger()
function (#248). He transformed a hardcoded limitation into a flexible, user-customizable parameter while maintaining perfect backward compatibility.
Both delivered thoughtful, well-implemented solutions that showcase the quality of contributions coming from the OSSCA program. Welcome to the Fedify community!
이와 비슷하게 청개구리 스택 경로라는 것도 생각해 볼 수 있겠다. 예를 들어 Deno를 선택했으면 Fresh는 청개구리 스택 경로가 아니다. 그런데 Deno를 선택한 다음 Next.js를 선택하면 오히려 청개구리 스택 경로가 된다.
마지막 남은 현금을 털어 DGX Spark 주문서를 넣었습니다. 128GB 메모리로 어디까지 할 수 있을지 궁금하네요. (그 돈으로 클라우드 GPU를 빌리는 게 훨씬 나았겠다는 생각도 한 켠에 들지만.)
언제쯤 한국에 올지, 그리고 온다면 언제쯤 잘 쓸 수 있을지는 모르겠으나. 모쪼록 사고 없이 무사히 왔으면 좋겠습니다.
//
그런데 저 정도 금액이 왜 카드결제가 안 되는 걸까요? 할부가 안 된다거나 하는 건 이해할 만한 일이지만, 오직 현금기반 결제(혹은 세금계산서 기반 결제)만 가능하다는 건 다소 의아하네요.
뭔가 any를 떡칠한거 같지만 미래의 내가 알아서 잘 없애주겠지?
얼마전에 해커스펍에 devcontainer 환경에서 Claude Code 쓰는걸로 엄청 삽질하던분이 계신걸로 기억하고 있는데, 공식 문서가 나온 듯
@kodingwarriorJaeyeol Lee 오…
@kroisse크로이세 님 이거 한 번 살펴보시면…
洪 民憙 (Hong Minhee) shared the below article:
힙스택 보존 법칙
RanolP @ranolp@hackers.pub
이 글에서는 프로젝트 진행 시 기술 스택 선정에 대한 경험적 법칙인 "힙스택 보존 법칙"을 소개하며, 힙한 기술 스택을 과도하게 선택할 경우 프로젝트가 산으로 갈 수 있음을 경고합니다. 저자는 신기술 도입 시 발생하는 호환성 문제와 그로 인한 추가 작업의 부담을 설명하며, 커뮤니티가 크고 성숙한 기술의 중요성을 강조합니다. 힙한 기술을 사용하더라도 프로젝트를 성공적으로 이끌 수 있는 두 가지 조건, 즉 기술의 안정성과 개발자의 숙련도를 제시하며, 힙스택을 사용하기 전에 충분한 학습과 경험을 통해 기술적 내성을 길러야 함을 역설합니다. 이 글은 기술 스택 선택의 중요성과 개발자의 역량 강화 필요성을 동시에 강조하며, 균형 잡힌 기술 스택 선택이 프로젝트 성공에 미치는 영향을 시사합니다.
Read more →일본은 Neovim 못지 않게 Vim을 쓰는 사람이 많은데...
Vim을 그대로 쓸 수 이유가 나름대로 있는데.. 첫번째로는, coc.nvim 이라는 걸로 nodejs 런타임으로 랭귀지서버/포매터 등등을 가져쓸 수 있어서 그냥 쓰는 것이다.... 두번째로는, 일본 생태계는 deno 런타임으로 vim 플러그인을 개발할 수 있는 vim-denops 위주로 생태계가 잘 발전이 되어있다. vim 스크립트에 대한 이해없이도, deno 스크립트로 vim 플러그인을 누구나 작성할 수 있는 생태계가 마련되어 있다.
터미널 환경에서 작업하는 만큼, 일본의 Vim 사용자 커뮤니티 사람들이 한창 Claude Code 삼매경에 빠져 있는데, 그 중에 누군가가 간단하게 Claude Code hook을 deno 스크립트로 작성해서 올렸는데 참고해볼만하다.
드디어 야크 털을 다 깎았습니다. 이번엔 진짜 진짜 pocket-galaxy
라는 이름에 걸맞는 boilerplate입니다. 온갖 기능을 다 집어 넣어봤습니다. 실제 서비스에서 쓰는 용도라기보단, 내부 툴이나 간단한 1회용 서비스 개발용에 가깝습니다.
Fedify 진행되는 속도보면 11월까지 메이저 릴리즈 두번할것만 같아
@kodingwarriorJaeyeol Lee
@2chanhaeng이찬행 저 티켓 다 가져갑니다?
@joonnotnotJoon
@kodingwarriorJaeyeol Lee
@2chanhaeng이찬행 어려운 이슈들 가져가시는 건 좋은데, 쉬운 이슈들은 남겨 주세요… ㅋㅋㅋ
한쪽은 신기능 백엔드 구현 및 프론트엔드 붙이기 작업. 한쪽은 149개 파일을 하나하나 다 건드리는 국제화 노가다 작업..
쿼드코어 바이브코딩은 여기서도 빛을 발휘한다..
간다, 쿼드코어 바이브코딩...!! (클로드 코드 4개 동시에 띄워놓고 각자 각개전투 시키고 있다는 뜻ㅎ)
이슈들 확인해보면서 어떤 것들이 있는지 파악하니까 꽤 해볼만한거 같군
.NET으로 서버 만들 때는 이메일 보낼 때 FluentEmail이라는 패키지를 유용하게 썼는데, JavaScript 쪽에도 비슷한 게 있나 찾아봤지만 뭔가 다 조금씩 마음에 안 드네… 내가 원하는 건 다음과 같다:
- Mailgun, SendGrid, SMTP 등 다양한 이메일 전송 트랜스포트를 하나의 일관된 API로 사용할 수 있어야 한다.
- 멋대로 환경 변수에 의존하지 말아야 한다.
- Node.js는 물론 Deno에서도 동작해야 한다.
오히려 파일 첨부 같은 부가 기능은 없어도 되기 때문에 간단하게 필요한 라이브러리를 찾을 수 있을 거라고 생각했는데, 못 찾고 있다. 음… 바이브 코딩으로 하나 만들까?
Node.js 커뮤니티는 환경 변수를 너무 좋아하는 것 같다. 거의 라이브러리 API의 일부로 생각하는 듯?
Deno만 해도 환경 변수는 --allow-env
플래그를 통해 명시적으로 허용하지 않으면 접근 못하고, Haskell에서도 getEnv
는 String
이 아니라 IO String
을 반환하게 되어 있다.
반면 Node.js에서는 process.env
로 너무 쉽게 접근 가능해서 그런가, 환경 변수 접근이 입출력이라는 생각을 아예 안 하는 모양이다.
오늘 오전에 저와 같은 하늘을 보신 분이 계실지.. 더위 조심하시고, 맛점하시길 바랍니다 ☺️
Claude code가 trait설명 안 읽고는 구현 해달라는 곳에 TODO만 남기길래 문서 좀 읽어! 라고 했더니 열심히 크롤링하고는 틀린 코드를 작성해줬다...
아침에 코드 읽다가 TODO를 봐서 고쳐봤다. 다듬는건 회사가서 해야지
이 딜레마 때문에, 이메일을 로그인 아이디로 사용하는 Hackers' Pub에서도 RFC 5321 스펙대로 로컬 파트에서 대소문자를 구분할지, 현실의 이메일 제공자들이 로컬 파트에서 대소문자를 구분하지 않는다는 것을 받아들이고 함께 대소문자를 구분하지 않을지 고민을 했는데… 결국에는 로컬 파트에서 대소문자를 구분하되, 로그인할 때 대소문자가 일치하는 이메일 주소가 없으면 대소문자 구별 없이 이메일 주소를 한 번 더 찾는 로직을 구현했다.