労働が非人間的になるのは「疎外」と呼ばれるけど、先日洪民憙さんの記事を読んだばかりだった。

Marxは『資本論』第一巻で、イギリスのラッダイト運動をこう評した。

労働者が機械そのものと機械の資本主義的利用とを区別し、したがって物質的生産手段そのものではなく、その社会的搾取形態を攻撃することを学ぶまでには、時間と経験が必要だった。

機織り機を打ち壊した労働者たちの怒りは正当だった。方向が間違っていただけだ。問題は機械ではなく、機械をめぐる資本主義的社会関係だった——機械が労働時間を短縮するどころか延長し、労働者を解放するどころか機械の付属物にしてしまうのは、機械の本性ではなく、機械を配置する方式の問題だった。Marxは彼らを嘲笑したのではなく、闘争が成熟していく過程を叙述したのだ。

https://writings.hongminhee.org/2026/02/acting-materialistically-in-an-imperfect-world/

@gaeulbyul가을별 저도 오늘 가격인상 공지 메일을 받았네요. 월급만 빼고 다오르는 느낌 무엇. 😂

Current vs New Pricing:
Current price: $35.88 USD / year
New price: $47.88 USD / year
The new price will take effect at your next renewal, provided it’s on or after March 27, 2026. Those occurring prior to March 27, 2026, will continue at the current pricing until your next renewal.
Action needed: Please go to my.1password.com/billing to register your approval. If you do not provide consent by your next renewal date on or after March 27, 2026, your subscription will automatically be cancelled at time of your next renewal.

Fedify 2.0.0을 릴리스했습니다!

Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:

• 모듈형 아키텍처 — 기존의 단일 @fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.
• 실시간 디버그 대시보드 — 새로운 @fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.
• ActivityPub 릴레이 지원 — @fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).
• 순서 보장 메시지 전달 — 새로운 orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.
• 영구 전달 실패 처리 — setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.

이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.

이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!

브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.

전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

TypeScript 6.0 beta is now published!

This release brings

- inference improvements for functions
- updates to package.json 'imports'
- Temporal APIs
- alignments for the upcoming TypeScript 7.0
- & more!

Try it today!

https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/

지난 주말부터 열심히 토큰을 팍팍 태워 만든 TypeScript/Rust용 엑셀 라이브러리 SheetKit, 방금 0.4.0를 배포했습니다.

문서 퀄리티가 아직 좋다고는 말을 못해도 API 레퍼런스와 문서 웹도 생겼고, 단순한 값 읽기/쓰기를 넘어 복잡한 기능들도 많이 추가되었습니다. 이제 폭발적인 구현보다는 적당한 스피드로 문서의 완성도를 높이고 WebAssembly나 Bun/Deno/Python 등에 대한 바인딩 등을 고민해볼 계획입니다. 문서의 완성도도 좀 어느 정도 올라간다면 이리저리 SheetKit을 소개하는 정식 글도 한번 여기저기에 올려보려고 합니다.

이미 Node.js쪽 binding은 열심히 개밥먹기하고 있는 중인데, Rust나 Node.js 환경에서 엑셀 파일을 다룰 일이 있는 분들은 한번 써보시고 이슈나 피드백을 남겨주시면 너무 좋을 것 같습니다.

Node.js에서 SheetKit은 다른 라이브러리에 비해 거의 모든 벤치마크 테스트에서 성능 우위를 보였습니다. 웹 문서에는 SheetKit이 어떻게 메모리를 덜 사용하고 Node.js 바인딩에서 영역 전환 시의 오버헤드를 줄였는지도 정리되어 있습니다.

https://github.com/Nebu1eto/sheetkit

• zellij 를 MacOS + Ghostty 조합에서 사용할 때 한글 폴더명의 깨짐현상이 있다.

• (초성만 노출되는 문제) https://github.com/zellij-org/zellij/issues/3148

• Claude Code (Opus 4.6 Model) 의 도움을 받아 수정했고 로컬에서 빌드해서 쓰고 있다.

• PR 도 보냈는데, 근본적인 해결책은 되지 못해, 커밋이 병합되지는 못했다.

• 그래서 결론 - 이 커밋은 나만 쓰게 되었다. 😂

아래 내용도 참고하면 좋을 것 같습니다.

기존 도메인(t1.daumcdn.net)도 당분간 계속 사용 가능하지만, 가능한 경우 신규 도메인(t1.kakaocdn.net) 사용을 권장드립니다.
...
daum.Postcode는 강제 변경되지 않으며, 가능한 한 오랜 기간 동안 호환성 유지를 목표로 지원할 예정입니다.
다만, 신규 개발 및 유지보수 관점에서 점진적으로 kakao.Postcode 사용을 권장드립니다.

Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)

https://github.com/daumPostcode/QnA/issues/1498

GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.

1. 공식 가이드 페이지

• 현재: https://postcode.map.daum.net/guide
• 2026-03-10 이후: postcode.map.kakao.com 으로 이전 예정

2. CDN 도메인 변경 (적용 완료)

• 기존: t1.daumcdn.net
• 변경: t1.kakaocdn.net

3. 서비스 도메인 변경 일정 (예정)

• 공식 가이드 / 서비스 팝업
  • 기존 dmaps.daum.net
  • 변경 postcode.map.kakao.com

4. JavaScript API 네임스페이스 변경 안내

• 기존 new daum.Postcode({...
• 변경 new kakao.Postcode({...

5. 서비스 종료 예정 도메인 안내 (중요)

• 2026년 4~5월 도메인 최종 전환 시점에 서비스가 종료될 예정
  • dmaps.daum.net
  • ssl.daumcdn.net

6. 도메인 변경 사전 안내 및 네임스페이스 변경에 대한 안내

• 기존 도메인 종료에 대한 상세 일정은 3월 10일 전후 공지에서 다시 안내
• 서비스 중단 방지를 위해 사전 점검 및 점진적 전환을 권장

백만년만에(?) 터미널 프로그램을 iTerm2 에서 Ghostty 로 바꿨다.

• 찍먹만 해보자는 생각으로 깔았는데,
• 설정 잡는 방법도 마음에 들고
• 빠르고 가벼운 느낌이 제법 체감되어 아예 넘어가기로 했다.

日本(일본)의 TypeScript 컨퍼런스인 TSKaigi 2026이 5月(월) 22日(일)(金(금))–23日(일)(土(토))에 東京(도쿄)에서 開催(개최)된다고 합니다. 함께 가실 韓國(한국) 분 계실까요?

一旦(일단) 저랑 @2chanhaeng초무 님하고 @kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 님이 같이 가실 것 같습니다.

LLM으로 문서 뽑아낼 때 "위키피디아 하드 유저(Highly Active User) 겸 테크니컬 라이터"라고 페르소나 주입하니까 문서 질이 다르다

skill 문서를 한 곳에서 관리하는 것이 좋아보여서 레포를 만들었음 https://github.com/notJoon/SKILLS

AI/LLM에 對(대)해 奴隸制(노례제)를 聯想(연상)시키는 表現(표현)을 쓰는 것에 拒否感(거부감)이 있다. 아니, AI/LLM이 아니라 어떤 對象(대상)에 對(대)해서든.

@curry박준규 Dojang 새 버전을 릴리스했습니다. ㅎㅎㅎ

오랫동안 Grafana 와 Prometheus 의 조합으로 서버 모니터링을 해왔는데, (거기에 Uptime Kuma 까지)

뭔가 바꿔볼 마음이 들어서, 올해 하게 되는 프로젝트에는 SigNoz 와 xyOps 를 적용해볼까 싶어서 살펴보고 있다. (바쁘거나 우선순위에서 밀리면 못하겠지만)

AI 企業(기업)이 F/OSS 코드로 LLM 訓練(훈련)하는 걸 막을 게 아니라, 訓練(훈련)한 모델을 公開(공개)하도록 要求(요구)해야 한다고 생각합니다.

撤收(철수)가 아니라 再專有(재전유)! GPL이 그랬던 것처럼요.

訓練(훈련) 카피레프트에 對(대)한 글을 썼습니다: 〈F/OSS 史唯(사유): 우리는 LLM을 拒否(거부)할 게 아니라 되찾아 와야 한다〉(한글).

@hongminhee洪 民憙 (Hong Minhee) 앗. 피드백 감사드립니다. 오류 수정했습니다! (Google 로그인을 넣으면서 버그가 있었네요.)

내 구독 목록을 보는 SubList Me 를 소개합니다.

• 대 AI 시대라, 저도 AI 에이전트와 함께 개인적으로 장난감을 만들어 보았습니다.

• Cloudflare에서 도메인을 샀고, 서버리스로 Pages와 Workers를 사용합니다.

• Nextjs, Hono를 사용하고 있습니다.

• 선택UI 는 Installkit에서 영감을 받았습니다.

• Hackers.pub 에 제일 먼저 공개하고 싶었고, 그러므로, 최초 공개입니다. 😅

• 많이 부족하고 아직 버그나 개선의 여지도 많지만 개밥먹기하면서 수정해 나가려고 합니다.

• 소개 페이지: https://www.sublistme.com/

• 서비스 링크: https://app.sublistme.com/

소스는 요기

（わかる人にはわかると思うけど）最近は、機能追加や修正において、コードを直接いじるよりも、修正計画をしっかり書いてからコードエージェントに任せることが増えている。

手戻りを減らすためにも、修正計画はできるだけ具体的に書くことを意識している。テスト対応まで含めて指示することも多い。

もちろん、最終的なコードの検証とテストは自分で行う。

공익글: VS Code에서 작업하던 파일이 유실됐다면 가장 먼저 Timeline부터 확인합시다. 바로 오늘도 이 방법으로 삭제된 코드를 복구한 지인분이 계시며...

LLM을 위한 cat, lat의 프로토타입을 완성했습니다. 당장은 Nix 유저만 쉽게 설치할수 있습니다. 다른 패키지 매니저 지원을 비롯해 빠르게 개선하겠습니다.

LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

프로젝트에 Deno와 pnpm을 함께 쓰고 있었는데, mise의 태스크 기능을 사용해서 개발에 필요한 커맨드들을 일원화했더니 속이 편하다.

複数のパーサーを合成するとき、一つでも非同期なら結果も非同期になる——これをTypeScriptの型レベルで表現するのが意外と難しかった。Optiqueでの設計過程を書きました。

https://zenn.dev/hongminhee/articles/d27ca1e6effa11

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를 섞어서 쓰면 어떨까 생각만 해보고 있다.

明けましておめでとうございます！2026年もよろしくお願いいたします。

새해 복 많이 받으세요. 2026년에도 늘 좋은 일만 가득하시기를 바랍니다.

あけましておめでとうございます。 2026年も素敵な一年になりますように。

新年快乐！愿2026年带给您满满的好运与美好。

Happy New Year. May 2026 bring you happiness, success, and many wonderful moments.

2026年(년)에도 새해 福(복) 많이 받으세요!

한 해를 마무리하는 글을 블로그에 썼습니다: 〈聯合宇宙(연합우주)와 함께 한 2025年(년)〉(한글 專用文(전용문)은 이쪽). 題目(제목) 그대로 聯合宇宙(연합우주)와 함께 했던 저의 한 해를 되돌아 보는 글입니다. 聯合宇宙(연합우주) 德分(덕분)에 많은 因緣(인연)과 이어지게 되어서 感謝(감사)하게 생각합니다.

Just had someone leave feedback on my F/OSS project saying “maybe that's fine if a product is focused on your Chinese community.”

I'm Korean. Every single piece of documentation is in English. There's nothing in Chinese anywhere in the project.

This kind of microaggression is exhausting. As a non-white maintainer, you deal with these assumptions constantly—people who feel entitled to your labor while casually othering you based on your name.

It chips away at your motivation. It makes you wonder why you bother.

https://github.com/dahlia/optique/issues/59#issuecomment-3678606022

가족들이 밋업 굿즈를 탐내는 건 처음이다. 다음번엔 앵그리 버전 한 표!

내 로컬에서는 됐는데. 라는 말을 20년 넘게 사용할 줄, 20년전의 나는 (당연히) 몰랐겠지. #중년의개발자

最近、社内の（自社）メッセンジャーの利用をやめ、Discord を主な協業ツールとして活用している。 Webhook 用のチャンネルが一つずつ増えるにつれて活用度と満足度も高まり、全体としてかなりうまく使えていると感じている。

Slack も優れたツールではあるが、無料プランでは90日を過ぎたメッセージを確認できない点がやや残念だ。そのため、現時点の会社の状況で、Discord よりも Slack を有料で使うだけの明確なメリットがあるかというと、正直なところ判断が難しい。

一方で悩ましいのは、社外、とくに大企業の顧客との協業において、Discord を公式な協業ツールとして提案しづらい点である。ゲーミング向けメッセンジャーというイメージが依然として強く、積極的に推し出すには少し躊躇してしまう。

とはいえ、オープンソースや開発者向けのコミュニティでは、以前から Discord がかなり活発に使われている印象もある。(これは、ひとまず韓国に限った話かもしれない。)

@hongminhee洪 民憙 (Hong Minhee) Slackの無料プランでは90日を過ぎたメッセージは閲覧できなくなりますが、日本語圏のオープンソースコミュニティでは、スポンサー支援を受けている、もしくは有料プランを利用しているケースが多いのでしょうか。

오늘 모집 마감.................

@lionhairdino 도움이 되었다니 제가 더 기쁩니다^^

https://nextjs.org/blog/security-update-2025-12-11

Next.js의 추가 보안 업데이트가 있습니다.

지난주에 CVE-2025-66478 보안취약점때문에 부랴부랴 패키지 업데이트한 기억이 있는데, 이번에도 몇개 패치되었네요.

Next.js를 App Router 방식으로 쓰는 개발자분들은 잊지 말고 업데이트하셔요.

fix-react2shell-next 패키지로 검사 및 업데이트 가능합니다.

❯ npx fix-react2shell-next

fix-react2shell-next - Next.js vulnerability scanner

Checking for 4 known vulnerabilities:

  - CVE-2025-66478 (critical): Remote code execution via crafted RSC payload
  - CVE-2025-55184 (high): DoS via malicious HTTP request causing server to hang and consume CPU
  - CVE-2025-55183 (medium): Compiled Server Action source code can be exposed via malicious request
  - CVE-2025-67779 (high): Incomplete fix for CVE-2025-55184 DoS via malicious RSC payload causing infinite loop

...

지난주 금요일에 Next.js의 보안취약점 cvss 10 (필수패치해야하는) 소식이 나와서 바로 패치대응했다. (App router 방식을 쓰면 무적권 패치해야 한다) 그리고 이번주에는 Cloudflare DNS를 쓰는 곳에 모두 Zero Trust를 도입했고 이제야(?) 마음이 편해졌다.

덧) 허용된 IP 만 By Pass 하거나, 사내 도메인 메일 인증 정책을 추가했다.

CLIパーサーの新しい記事を書きました。--reporterの値によって--output-fileが必須になったり禁止になったり…そういう関係、型で表現できたら楽じゃないですか？

https://zenn.dev/hongminhee/articles/201ca6d2e57764

#TypeScript #CLI #Optique

여기에 뒤늦게 올리지만 2차 모집도 진행중입니다! 이번엔 12월 15일(월)까지....!!

이 소식을 오늘 아침에야 알게되어, 부랴부랴(?) React / Next.js 의 버전 업데이트 패치를 했습니다.

• RSC보안취약점이라서, Next.js기반으로 App router 방식을 쓰는 프로젝트 하시는 분들중에 아직 소식을 못들었다면 패치 업데이트하시면 좋을 것 같네요!

(예시)

• Next.js 의 현재 사용중인 버전이 15.3.0 이다. 15.3.6 으로 업데이트하셔야 합니다.
• Next.js 의 현재 사용중인 버전이 15.5.0 이다. 15.5.7 로 업데이트 하셔야 해요.

관련링크: https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp

React: 19.0.1, 19.1.2, 19.2.1 Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

요약 보안취약점 (CVE-2025-66478, cve-2025-55182) 대응을 위한 React / Next.js 업데이트가 필요함.

사실 정확히는 Next.js 보다도 RSC기반이면 무조건 패치 업데이트해야 하는...

추가 관련 링크

• https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp
• https://news.hada.io/topic?id=24826
• https://www.dailysecu.com/news/articleView.html?idxno=203063

회사에서 디스코드로 하는 일 모음

1. 이슈트래커에 내 일감 등록되었는지 멘션 알림
2. 서비스 중 업타임 (업다운) 알림
3. 젠킨스 배포 시작,종료 (성공실패) 알림
4. Gitlab CI Docker 빌드, 컨테이너 레지스트리 정상 업로드 알림
5. ArgoCD 상태알림 (정상 싱크, 배포)
6. 봇으로 사내 음악 공유 (봇 대기열에 노래 추가해서 같이듣기)

6번이 제일 유용합니..

(다른 거 더 추천 받습니다..)

Hackers Public @ Seoul 송년회 ---- 2025년의 마지막을 해커들과 함께해요.

Hackers' Public @ Seoul 송년 네트워킹 밋업은 발표보다 대화, 형식보다 연결을 중심으로 진행됩니다. 라이트닝 토크도 지원받습니다. 만들었던 것·배운 것·고민했던 이야기를 자유롭게 얘기해보도록 해요.

많은 관심 부탁드립니다~

• 🗓 12/21(일) 14:30~18:30
• 🎤 라이트닝 토크 5분 자유 참여
• 📌 1차 모집: 11.26~12.5 (회원 대상)
• 신청하기 👉 https://event-us.kr/hackerspubseoul/event/117468

大量の応募者の中から悩みに悩んで選んだエンジニアが、出社予定日の当日になっても来ない。しかも連絡も取れず、電話も切られる始末…。人への信頼がまたしても粉々になった一日だった。

「一緒に働いてから問題になるよりは、まだマシだった」とポジティブ変換しようとしてるけど、それでも「人って基本的には善良だよね」って信じようとしていた自分は……（いや無理だろこれ）。

하. 클라우드플레어.. 잠시 눈물 좀 닦고 올게요. 😢 (hackers.pub 은 이제 접속되네요. 아까 안되었던..)