Profile img

Lee Dogeon

@moreal@hackers.pub · 102 following · 86 followers

어느 한 개발자입니다.

GitHub
@moreal

I'm writing this in English.

Not because English is my first language—it isn't. I'm writing this in English because if I wrote it in Korean, the people I'm addressing would run it through an outdated translator, misread it, and respond to something I never said. The responsibility for that mistranslation would fall on me. It always does.

This is the thing Eugen Rochko's post misses, despite its good intentions.

@GargronEugen Rochko argues that LLMs are no substitute for human translators, and that people who think otherwise don't actually rely on translation. He's right about some of this. A machine-translated novel is not the same as one rendered by a skilled human translator. But the argument rests on a premise that only makes sense from a certain position: that translation is primarily about quality, about the aesthetic experience of reading literature in another language.

For many of us, translation is first about access.

The professional translation market doesn't scale to cover everything. It never has. What gets translated—and into which languages—follows the logic of cultural hegemony. Works from dominant Western languages flow outward, translated into everything. Works from East Asian languages trickle in, selectively, slowly, on someone else's schedule. The asymmetry isn't incidental; it's structural.

@GargronEugen Rochko notes, fairly, that machine translation existed decades before LLMs. But this is only half the story, and which half matters depends entirely on which languages you're talking about. European language pairs were reasonably serviceable with older tools. Korean–English, Japanese–English, Chinese–English? Genuinely usable translation for these pairs arrived with the LLM era. Treating “machine translation” as a monolithic technology with a uniform history erases the experience of everyone whose language sits far from the Indo-European center.

There's also something uncomfortable in the framing of the button-press thought experiment: “I would erase LLMs even if it took machine translation with it.” For someone whose language has always been peripheral, that button looks very different. It's not an abstract philosophical position; it's a statement about whose access to information is expendable.

I want to be clear: none of this is an argument that LLMs are good, or that the harms @GargronEugen Rochko describes aren't real. They are. But a critique of AI doesn't become more universal by ignoring whose languages have always been on the margins. If anything, a serious critique of AI's political economy should be more attentive to those asymmetries, not less.

The fact that I'm writing this in English, carefully, so it won't be misread—that's not incidental to my argument. That is my argument.

4
9
0

제가 일하는 팀에서 채용중입니다. https://careers.linecorp.com/ko/jobs/2964/

회사 이름이 LINE 으로 시작하지만 메신저는 안만듭니다. 국내외 선물 시장에서 거래하는 자동매매 전략과 그 전략을 서빙하는 플랫폼을 만듭니다. Rust, FPGA, AI 같은 키워드를 나열할 수 있긴 한데, 그냥 코딩 잘하시는분이면 좋겠습니다. 시장은 몰라도 됩니다. 근데 혼자 코딩 잘하는거 말고 AI랑 같이도 잘 코딩해야 합니다.

저는 이런 사람입니다 https://github.com/youknowone/

같이 일할 @perlmint 님은 https://github.com/perlmint/

함께 일하고 싶으신 분을 찾습니다.

7
0
0

Lee Dogeon shared the below article:

성공적인 AI 에이전트 시스템을 만들려면

Seo Sanghyeon @sanxiyn@hackers.pub

AI 에이전트 시스템을 구축하며 얻은 실전 경험을 바탕으로 효율적인 설계와 운영 전략을 심도 있게 다룹니다. 성공적인 에이전트를 위해 목표는 측정 가능하고 유용하며 달성 가능한 범위로 좁혀야 하며, 로그 인프라 구축과 정교한 평가 설계(evaluation design)를 통해 지속적인 개선의 토대를 마련하는 것이 필수적입니다. 특히 도메인 특화 지식을 스킬(skill) 형태로 패키징하여 모델의 추론 능력을 극대화하고, 프롬프트 캐싱과 적절한 모델 선택으로 비용 효율성을 확보하는 방법론을 제시합니다. 구체적인 구현 단계에서는 컨텍스트 윈도(context window) 관리를 위한 멀티 에이전트 구조와 서브 에이전트의 실행 제어 기법을 살펴봅니다. 또한 복잡한 도구 호출 대신 모델이 직접 코드를 생성하고 실행하게 함으로써 토큰 사용량을 혁신적으로 줄이는 코드 생성(code generation) 패턴의 효용성을 강조합니다. 이와 더불어 신뢰할 수 있는 파일 편집 방식과 샌드박스 기반의 강력한 인가 제어(authorization) 시스템 구축은 안전한 자율 시스템을 위한 핵심 요소로 작용합니다. 이 글은 빠르게 진화하는 AI 에이전트 분야에서 기술적 정확성과 실용성을 겸비한 아키텍처를 설계하려는 개발자들에게 구체적이고 실질적인 인사이트를 제공합니다.

Read more →
12
0
0

Lee Dogeon shared the below article:

Nix Store에서 언어의 특권적 지위 제거: Sandbox 기반 아키텍처 제안

bgl gwyng @bgl@hackers.pub

Nix 아키텍처에서 Nix 언어가 스토어(store)에 대해 가지는 특권적 지위와 그로 인한 생태계 종속성 문제를 짚어보고, 이를 해결하기 위한 샌드박스(sandbox) 기반의 구조적 개선안을 제안합니다. 핵심은 언어의 순수성에 의존하던 기존의 신뢰 모델을 OS 레벨의 격리와 데몬(daemon) 프로토콜로 전환하는 것입니다. 이러한 변화를 통해 Nix 언어뿐만 아니라 파이썬(Python)이나 러스트(Rust) 등 다양한 언어가 동등한 지위에서 스토어와 상호작용할 수 있게 되며, 빌드와 평가의 경계를 허물어 더욱 유연하고 견고한 시스템을 구축할 수 있는 통찰을 제공합니다.

Read more →
3
5

그 뭐시냐.... 제가 모임 개최 플랫폼 (대충 event-us.kr 혹은 connpass.com 같은거) + 지역 기반 리뷰 서비스 (대충 포스퀘어 같은거) 를 만들었는데요.

**당연히, 연합우주 거주민 대상으로 만들어진 서비스이고, 연합우주에 계정이 있다면 누구나 OTP 로그인으로 인증이 가능합니다**

어떻게 만들어나갈지 나름 고민은 많이 해봤고, 내가 생각하는 고민이랑 다른 사람들이 생각하는 수요가 일치하는지 확인도 하고 싶어서 이렇게 공개적인 글을 올립니다.

moim.live

많은 관심과 사랑 부탁드리고, 문의사항이나 피드백 있으면 GitHub Issue로 부탁드리겠습니다. GitHub 링크 : github.com/moim-social/moim

물론, 다른 창구도 열어둘 여지는 있습니다. 디스코드 채널은.. 당장은 fedidev.kr 채널을 이용하지 않을까 싶구요.

4
2
1

오랜만입니다. 근황 겸...

2월 말 퇴사했습니다. 역시 Web3는 제가 "잘" 하는거지 "좋아" 하진 않는 것 같습니다. 평가도 좋고 계속 할 수도 있었지만 뭔가 이젠 시들해지기도 했고, 원래부터 Web3로 커리어를 잡으려고 했던 것도 아니라서 다음 직장을 알아봤습니다.

그래서 4월 1일부터 크레페(쿠키플레이스)로 옮깁니다. 김민상(bis_cir_kit) 님 추천으로 지원하게 되었는데, 타입으로 그래프 나타내는 건 원래 좋아하던 일이라서 스택도 잘 맞고, 회사 감성도 완전 찰떡이라 일주일 만에 합류 결정이 되었습니다.

그 사이엔 결혼 일정때문에 바빴습니다. 3월 7일에 대구에서 결혼합니다. 너무 멀어서 미안한 나머지 청첩장은 많이 못 돌렸지만 이렇게나마 소식은 전합니다.

wedding.suho.io 에서 저희 사진과 정보를 더 확인하실 수 있습니다.

또한 2월 중순쯤 퇴사가 확정되고 나서 만들고 있는 프로젝트가 있습니다. whaleback.suho.io 입니다. 한국 주식을 각 종목별로 퀀트 분석해 주고, AI 리포트로 일간 트렌드를 알려주는 등, 각종 정보를 보기 편하게 정리했습니다.

사용해 보시고 궁금한 점 있거나, 아니면 저 개인이 궁금하시더라도 연락주세요. 감사합니다.

9

I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:

@COSCUP 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.

Nothing is decided yet, but if you're working on , the , or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.

https://floss.social/@COSCUP/116152356550445285

()아시아에도 FediCon 같은 行事(행사)가 있으면 좋겠다는 말을 여러 () 해왔는데요. 獨立的(독립적)인 컨퍼런스는 아직 어렵더라도, 작은 첫걸음으로 생각해보고 있는 게 있습니다.

@COSCUP 2026(臺北(타이베이), 8() 8()–9())이 커뮤니티 트랙 提案(제안)을 받고 있어요. FOSDEM의 Social Web devroom 같은 느낌으로, 거기서 Social Web 트랙을 열 수 있지 않을까 하고 構想(구상) 중입니다.

아직 確定(확정)된 건 아무것도 없지만, , , ()은 소셜 웹 全般(전반)을 다루고 있고 發表(발표)共同(공동) 오거나이징에 關心(관심)이 있으신 분이 있다면 이야기 걸어주세요.

https://floss.social/@COSCUP/116152356550445285

1
0
0

오늘 하루 Hackers Pub iOS 앱에 작업한 것들

  1. 긴 글을 잘라서 보여줄 때 HTML truncate할 때 HTML 태그 구조에 이상이 없게끔 안전하게 처리
  2. 글 리스트 보여줄 때 렌더링 최적화
  3. 글 리스트 / 상세 페이지에서 인용된 글도 제대로 보이도록 수정하고 인용 기능 추가
  4. 글에 반응하기 기능 추가
  5. 누가 글을 공유하거나 인용했는지 화면 추가

조금만 더 하면... 앱스토어 올려도 되겠다...

3월 1일 하루에 hackers-pub/ios에 16개 커밋을 올렸다.
5
0
3
0
2

앗! 나도 해커스펍 기여자? Hackers Pub 기여자 모임 스프린트

Hackers' Pub 리뉴얼, 손꼽아 기다리고 계시지 않으신가요? Hackers' Pub, 한 번쯤 직접 기여해 보고 싶다는 생각, 해보신 적 없으신가요? Hackers' Pub, 이용하면서 어딘가 아쉽다 느꼈던 부분, 혹시 있지 않으셨나요? 이번 스프린트 모임은 리뉴얼 진도도 팍팍 빼면서, 기여자들끼리 서로 얼굴도 익히고 친분도 쌓는 자리입니다. 부담 없이 참여해 주세요. 모임은 서울특별시 성동구 상원길 26, 뚝섬역 5번 출구 근처 어딘가에 있는 튜링의 사과에서 진행합니다. 일정은 3월 1일 ~ 3월 2일. 모여서 각자 편하게 해커스펍 기여하다가 가시면 됩니다. 몸만 오시면 됩니다. 비용은 튜링의 사과 이용료만 챙겨 주시면 돼요. 감사합니다. 이 글은 연합우주를 위한 모임 개최 서비스 moim.live의 첫 게시글로 영광스럽게 공유합니다

📅 2026-03-01T02:00:00.000Z — 2026-03-02T10:00:00.000Z

Organized by: @hongminhee@hollo.social

View event details

1
0
1

오래 기다리셨습니다!!!

BlueBase: Python으로 밑바닥부터 직접 만들어보는 DBMS

https://theeluwin.github.io/BlueBase/

결국 완성은 못했지만, 일단 공개할 수 있는 부분이라도 공개합니다.

RedBase DBMS을 구성하는 PF, RM, IX, SM, QL 중 PF와 RM을 여러분들이 직접 구현 할 수 있게, 과제의 형태로 제공합니다.

PF는 paged file의 약자로, file을 page 단위로 관리하는 컴포넌트입니다. 대충 4096 바이트 단위로 관리하는데요, file에 바로바로 read하거나 write하지 않고, 자주 사용되는 page는 가능한 memory에 있도록 중간에 buffer manager를 둡니다. 그렇다면 buffer에 공간이 모자라면? buffer에 있는 page 중 누군가를 evict 할 수밖에 없습니다. 그럼 뭘 기준으로 하면 좋을까요? 이 부분을 잘 생각해서 구현해보고, 성능을 비교해보기 바랍니다. 제가 cache hit/miss 시뮬레이션 구현해둔게 있으니, 제 custom 보다 높은 성능을 달성해주세요!

이후 RM은 record management의 약자인데, PF를 사용해서 record들을 가져오거나, 새로 넣거나 등을 하게 해줍니다. 그렇다면 전체 record를 순회하는 scan 연산이 중요하겠죠. 이 부분을 구현하는 것이 핵심입니다. record는 page 앞 부분에 bitmap을 둬서 slot이 비어있는지 아닌지를 확인하는데, 만약 record 삭제 명령이 마지막 slot을 비우게 된다면 해당 page는 더이상 필요 없겠죠. 그렇지만 이를 바로 free로 만드는건 조금 비싼 연산이 필요합니다. free page list를 다시 계산해야하거든요. 그래서 보통 DBMS에서는 이러한 작업들을 vacuum 연산으로 해결합니다. 추가로, 지금은 고정 길이 record만 다룰 수 있습니다만, 가변 길이를 허용하려면 어떻게 해야할까요? 이 부분들은 자유롭게 구현해보시면 좋겠습니다.

문서와 테스트는 모두 공개되어있습니다. 기여해주시면 감사하겠습니다! 다만, 정답 코드와 핵심 로직은 마지막까지 저 혼자 해보고 싶습니다 (도전).

https://github.com/theeluwin/BlueBase

밑바닥부터 직접 만들어보는 DBMS에서 page cache policy에 따른 성능 비교.
5

We're gradually moving our community from Discord to Matrix. The maintainers and contributors are already there, so you'll get faster responses on Matrix going forward. Discord will stay up for a while, but Matrix is now our primary home.

For the full details and the list of Matrix rooms, see: https://github.com/fedify-dev/fedify/discussions/573.

저희 커뮤니티를 Discord에서 Matrix로 조금씩 이전하고 있습니다. 메인테이너와 기여자들은 이미 Matrix로 옮긴 상태라, 앞으로는 Matrix 쪽이 응답이 더 빠를 거예요. Discord는 당분간 유지되지만, Matrix가 이제 메인 거점입니다.

자세한 내용과 Matrix 룸 목록은 여기서 확인하세요: https://github.com/fedify-dev/fedify/discussions/573.

0

🕐 2026-02-15 12:02 UTC

📰 技術発信を後回しにした私が、転職で詰んだ話。 (👍 223)

🇬🇧 How neglecting tech blogging destroyed job prospects. Skills without documentation = skills without proof. Share imperfect work early and often.
🇰🇷 기술 블로깅을 미루다 이직에 실패한 이야기. 증명되지 않은 실력은 없는 것과 같다. 불완전해도 일찍 자주 공유하라.

🔗 zenn.dev/igz0/articles/skill-w

0

Optique 0.10.0 released—the biggest update yet for this TypeScript CLI parser library.

What's new:

  • Runtime context system for composing config files, env vars, and other data sources
  • New @optique/config package with Standard Schema validation
  • Man page generation from parser metadata (@optique/man)
  • Inter-option dependencies with context-aware shell completions
  • 11 network value parsers (IP address, port, hostname, email, CIDR, etc.)
  • Program interface: define metadata once, reuse everywhere

This is the last pre-release before 1.0.0.

https://github.com/dahlia/optique/discussions/108

0

Dear FOSS maintainers,

here’s a list of funding programs currently accepting proposals for maintenance work:

Codeberg: codeberg.org/mechko/awesome-ma

GitHub: github.com/mechko/awesome-main

Thanks to everyone who helped crowdsource it! I’ll keep it updated, issues and PRs are very welcome :)

0
0
1

AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다.

  1. 가장 비싼 Plan으로 마음껏 써보기 클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요.

프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다.

AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다.

제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다.

리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다.

사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다.

  1. 가능성과 한계 인식하기 1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요.
  • 내가 하는 일, 내 환경에 대해 재정의하기
  • 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기

그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다.

소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다.

AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요.

대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다.


2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요.

이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다.


보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요.

고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.

7

I have deeply mixed feelings about 's adoption of JSON-LD, as someone who's spent way too long dealing with it while building .

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

2
28
1

Recently, @morealLee Dogeon built ap-thread-reader, a tool that displays threaded posts on a single page. Works with any ActivityPub platform, not just Mastodon.

Try it at https://ap-thread-reader.fly.dev/.

Built with Fedify and released as open source: https://github.com/moreal/ap-thread-reader.

More details at https://blog.moreal.dev/2026/02/ap-thread-reader-introduction/index.en.html.

0
0

Spring 2026 @CMUDBCMU Database Group Seminar Series: PostgreSQL vs. The World → db.cs.cmu.edu/seminars/spring2

Starting Mon Feb 2nd @ 4:30pm EST over Zoom. We will alternate between a speaker from either a Postgres DBMS or a non-Postgres DBMS. Open to the public. Videos available on YouTube afterwards.

SCHEDULE
‣ Feb 2: Redpanda Oxla
‣ Feb 9: Amazon Aurora DSQL
‣ Feb 16: TopK
‣ Feb 23: Microsoft Azure HorizonDB
‣ Mar 9: turbopuffer
‣ Mar 16: YugabyteDB
‣ Mar 23: TonicDB
‣ Mar 30: PixelTable
‣ Apr 6: SpacetimeDB
‣ Apr 13: Supabase Multigres
‣ Apr 20: VillageSQL

PostgreSQL vs. The World Seminar Series — Spring 2026
https://db.cs.cmu.edu/seminars/spring2026/PostgreSQL vs. The World Seminar Series Schedule
https://db.cs.cmu.edu/seminars/spring2026/
0
8

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

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

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

* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]
14
1
0

프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.

4

Lee Dogeon shared the below article:

Designing type-safe sync/async mode support in TypeScript

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

Optique, a type-safe CLI parser for TypeScript inspired by functional programming principles, recently introduced support for both synchronous and asynchronous execution modes to handle complex requirements like dynamic shell completions. Implementing this feature required sophisticated type-level logic to ensure that combining an asynchronous parser with synchronous ones correctly results in an asynchronous aggregate. After evaluating several design patterns, the developer settled on an explicit mode parameter with a default value to maintain backward compatibility while allowing for runtime inspection. This approach leverages conditional types and advanced inference to compute combined modes automatically, even though it necessitated significantly increasing internal implementation complexity to support dual execution paths. The updated API now includes specialized runners that provide compile-time enforcement of the expected execution mode, preventing common pitfalls associated with asynchronous code. By prioritizing a clean user-facing interface, the library successfully integrates asynchronous capabilities without compromising its original simplicity or type safety. This architectural evolution demonstrates how TypeScript’s powerful type system can manage complex state propagation while keeping the development experience intuitive and robust.

Read more →
4

Lee Dogeon shared the below article:

`X-Frame-Options` 의 악몽에서 깨어나세요, 프록시 서버 개발기

소피아 @async3619@hackers.pub

`X-Frame-Options` 헤더로 인해 발생하는 웹 사이트 임베딩 제한을 프록시 서버 개발을 통해 해결하는 과정을 다룹니다. 저자는 실시간 영상 스트리밍 방식의 지연 시간 문제를 극복하기 위해 `iframe`을 활용한 직접 임베딩 방식을 선택했으며, 이 과정에서 마주한 다양한 기술적 난제를 해결해 나갑니다. 단순히 응답 헤더를 제거하는 수준을 넘어, 상대 경로 문제를 해결하기 위한 URL 구조 재설계와 React 및 Vue와 같은 단일 페이지 애플리케이션(SPA)의 라우팅 시스템을 속이기 위한 고난도의 JavaScript 후킹 기법을 소개합니다. 특히 Babel을 이용해 소스코드를 추상 구문 트리(AST)로 분석하고 실행 시점에 `window.location` 접근을 가로채는 방식은 브라우저 보안 제약을 창의적으로 우회하는 통찰을 제공합니다. 이 글은 외부 웹 서비스를 자사 서비스에 매끄럽게 통합하려는 개발자들에게 프록시 서버 설계와 JavaScript 내부 동작 원리에 대한 깊이 있는 경험을 공유하며 기술적 돌파구를 제시합니다.

Read more →
4
0

크리스마스를 맞아 크리스마스 트리... 가 아닌 Hackers' Pub 초대 트리를 꾸몄습니다.

기존 초대 트리는 작은 규모에서는 충분히 제 역할을 했으나 회원이 점차 늘어나면서 구조를 파악하기 어렵고, 페이지가 너무 길어져 변화가 필요하다고 생각했습니다. 다음 개편되는 Hackers' Pub의 초대 트리 페이지에서는 초대 관계를 잘 드러내면서, 많은 회원이 한 눈에 들어올 수 있도록 만들었습니다. Hackers' Pub의 회원은 앞으로도 많이 늘어날 예정이니까요. 그렇겠죠? 내년에도 Hackers' Pub에서 많은 분들을 만날 수 있기를, 더 풍성한 초대 트리를 볼 수 있기를 기대해봅니다.

개편된 Hacker's Pub의 초대 트리. 노드를 드래그하면 움직인다.실제 데이터를 렌더링한 Hacker's Pub의 초대 트리.
4
2

https://github.com/sonohoshi/sonomemo 최근에는 바이브코딩을 좀 해봤고, 제가 쓸 메모용 앱을 만들어봤습니다. 만들었다고 하는게 맞나? 바이브코딩이라는거 재밌더라고요. 사실 당연한 것 같습니다. 코딩에서 오는 아이디어 구현과 결과물이 나오는 재미는 취하고, 디버그하고 버그 잡는 힘든 일은 LLM이 해주는데 당연히 재미있겠죠. 어쨌거나 이 행위에 맛들려서 Rust 코드는 어떻게 쓰는지 볼 겸, 터미널 기반의 메모용 앱을 만들었습니다. 제가 쓰려고 만들었는데 생각보다 쓰는 트친들이 많이 생겨서 여기에도 올려봐요. 감사합니다.

2

Big change coming to BotKit: multi-bot support! :botkit: :botkit: :botkit:

Currently, each BotKit instance can only run a single bot. We're redesigning the architecture to let you host multiple bots—both static and dynamically created—on a single instance.

The new API will look like this:

const instance = createInstance({ kv });
const greetBot = instance.createBot("greet", { ... });
const weatherBots = instance.createBot(async (ctx, id) => { ... });

Check out the full design:

https://github.com/fedify-dev/botkit/issues/16

1

12() 6() 서울에서 開催(개최)되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題(가제))라는 主題(주제)發表(발표)를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型(함수형) 프로그래밍에 關心(관심) 있으신 분들의 많은 參與(참여) 바랍니다!

9
0
0
2
30
2
6

Lee Dogeon shared the below article:

자연어에서의 재귀와 카탈랑 수

구슬아이스크림 @icecream_mable@hackers.pub

이 글은 자료구조와 알고리즘에서 중요한 개념인 재귀가 자연어에서 어떻게 나타나는지, 특히 통사론적 관점에서 인간 언어 능력의 창조성을 보여주는지를 탐구합니다. 'X의 Y의 Z의...'와 같은 소유격 조사를 사용한 문장 확장을 통해 재귀의 개념을 설명하고, 이러한 재귀가 카탈랑 수와 연관되어 있음을 지적합니다. 영어 예시를 통해 전치사구의 추가가 문장의 중의성을 증가시키고, 구문 분석의 가능한 경우의 수가 카탈랑 수열을 따른다는 것을 보여줍니다. 생성 규칙을 통해 명사구를 재귀적으로 확장하면서 중의성 계수가 카탈랑 수와 동일하게 나타남을 설명합니다. 마지막으로, 자연어의 중의성 해소는 산술 표현식과 달리 확률에 의존하며, 이는 전산/심리언어학에서 중요한 연구 주제임을 강조합니다. 이 글은 재귀의 개념이 자연어에서 어떻게 복잡하게 작용하는지, 그리고 그 중의성을 이해하는 것이 왜 중요한지를 흥미롭게 제시합니다.

Read more →
7

Lee Dogeon shared the below article:

"expression"은 "표현식"이 아니라 그냥 "식"

蛇崩 (じゃくずれ) @ja@hackers.pub

이 글은 프로그래밍 용어 "expression"을 "표현식"이 아닌 간결한 "식"으로 번역해야 한다고 주장합니다. 필자는 "expression"이 수학에서 유래되었으며, 수학에서는 이미 "식"으로 번역되어 사용되고 있음을 지적합니다. 또한, 프로그래머들이 "표현식"을 선호하는 이유로 사전적 정의와 초·중등 교육에서 비롯된 선입견을 들지만, 실제로는 "식"으로 번역해도 의미 전달에 전혀 문제가 없다고 강조합니다. 오히려 "표현식"은 "representation"의 번역어인 "표현"과 혼동될 수 있으며, "정규표현식"과 같이 불필요하게 긴 용어를 만들어낼 수 있다고 비판합니다. 결론적으로, 필자는 "expression"을 "식"으로 번역하는 것이 더 정확하고 간결하며, 전산학 용어의 일관성을 유지하는 데 도움이 된다고 주장하며, "정규식"이라는 간결한 용어 사용을 옹호합니다.

Read more →
10
0
0

얼마 전 웹서핑을 하다가 우연찮게 현재 앤트로픽에서 엔지니어이자 연구원으로 근무하고 있는 Nelson Elhage가 쓴 Computers can be understood(=컴퓨터는 이해가능하다)라는 글을 봤습니다. 다 읽고나니 이 분 마인드가 제가 평소에 CS 공부할 때랑 너무 비슷해서 공감이 가고 아직 CS 뉴비인 저한텐 굉장히 도움이 되는 한편, 이 마인드가 어떠한 단점을 또한 가져다주는지 잘 얘기하는 것 같아 (사실 읽으면서 뜬끔하는 게 많았음) 저만 알기엔 아까워서 이렇게 번역해서 올려봅니다.

번역된 글을 보려면 여기로 이동해주세용.

혹시나 오역 및 CS 용어에 문제가 있다면 언제든 알려주시면 감사하겠습니다.

8

대만의 COSCUP, 벨기에의 FOSDEM에 이어, 국내에서도 개인 및 소규모 오픈 소스 프로젝트를 위한 FOSS for All 컨퍼런스가 드디어 열립니다! 🇰🇷

오는 11월 8일(토), 광운대학교에서 개최되며 저도 이번 행사에서 발표자로 참여하게 되었습니다.

🗣️ 발표 주제: “식탁보 프로젝트 다섯돌, 바뀐 것과 바뀌지 않은 것”

식탁보 프로젝트가 세상에 나온 지 벌써 5년이 되었네요. 처음엔 AI가 없던 시대에 시작했지만, 이제는 AI가 세상을 바꾸고 있고, 식탁보도 그 여정 위에 있습니다.

다섯 해 동안의 변화와, 여전히 지켜온 가치들에 대해 진솔하게 이야기 나누려 합니다.

오픈 소스, 기술, 그리고 커뮤니티를 사랑하는 분들이라면 꼭 한 번 참석해보세요!

👉 참가 신청: https://event-us.kr/fossforall/event/110400

현장에서 함께 이야기 나눌 수 있기를 바랍니다. 🙌

식탁보 프로젝트 다섯돌: 바뀐 것과 바뀌지 않은 것 포스터 이미지 (FOSS for All 2025 행사 홍보 카드)
3

최근 (오픈소스) 프로젝트 관련해서 종종 연락을 받고 있습니다. 대체로, 검토해보겠다던 기능이 추가되는데 왜이렇게 늦어지냐는 내용으로 추정됩니다.

추정인 이유는 건너서 들은 것도 있기 때문입니다.

제가 이 글을 올리는 이유는 상당히 험한 말도 나왔다는걸 전해 들었기 때문입니다.

저는 외부의 어떠한 보수도 받지 않고 혼자서 정규업무 외 시간에 제 프로젝트의 개선과 이슈사항을 해결하고 있습니다.

최근에 개인적 사유로 커밋 빈도가 줄었던 것은 맞지만 그럼에도 우선순위가 높은 작업은 너무 늦어지지 않도록 노력했습니다.

제 프로젝트로 구축 및 운영을 하시는 분들이 있다고 하니 늘 감사하게 생각합니다만, 저는 이 일을 보수를 받고 하지 않습니다.

혹여 답답하신 분이라면 깃허브에 올라와있는 제 프로젝트 내용물을 통채로 복사해서 전문 개발 업체에 커스터마이징을 맡기시길 바랍니다.

그렇게 나온 결과물에 대해선 독점권 행사도 무리없이 행사하실 수 있도록 적극적으로 돕겠습니다. 감사합니다.

9

마인크래프트 내에 레드스톤으로 물리적으로 언어모델을 만든 사람이 나타남... 그러니까 간단한 디지털 회로도 아니거 언어모델을 만듬 ㅋㅋㅋ 외부 언어모델을 연결한것이 아닙니다;; 말그대로 트랜스포머를 구축해놨던데 세상은 넓고 천재는 많다... www.youtube.com/watch?v=VaeI...

I built ChatGPT with Minecraft...

1

그렇습니다. 우울하지 않은 사람도 "우울할 때에는 상담하기"를 평소에 열심히 외워 둘 필요가 있습니다. 왜냐?

심리학에는 결핍의 덫(scarcity trap)이라는 개념이 있는데요. 사람은 시간이나 금전 등 어떤 자원이 결핍(scarce)되면, 심리적 압박을 받아 시야가 좁아집니다(tunnel vision). 이로 인해 올바른 결정과 실행을 못하게 됩니다. 그러면 자원의 결핍(scarcity)이 더 심해집니다.

이렇게 얘기하면 떠오르는 전형적인 예시가 있습니다. 열악한 노동 조건과 저임금에 시달리는 노동자가, 스트레스 때문에 퇴근 후 술이나 도박 등의 즉각적 쾌락에 돈과 시간과 건강을 다 탕진해 버리는 것이죠. 하지만, 높은 소득과 지위를 누리던 대기업 간부도 투신자살을 해서 충격을 주곤 합니다.

사람이 이 덫에 빠지게 되는 계기가 한두 가지가 아닙니다. 환경적 요인으로 인해 우울감이 발생하기도 하고, 반대로 우울감이 사회생활에 지장을 초래해 환경적 요인을 조성하기도 합니다. 그리고 어떤 식으로든 이 덫에 빠지면,

- 심리적 압박으로 시야가 좁아지고
- 그로 인해 어리석은 판단을 하게 되고
- 그 어리석은 판단으로 인해 더욱 궁지에 몰리고
- 심리적 압박이 더 커키고
- 더 어리석은 짓을 저지를 수가 있습니다.

이 악순환이 누적되면, 돈 많다는 사람들에게도, 똑똑하고 가방끈 길다는 사람들에게도, 얼마든지 비극이 일어나는 것입니다.

우울장애의 가장 큰 무서움이 이것입니다. 현대 사회가 개인에게 도움을 제공하는 모든 체계에는 전제가 있습니다. "개인이 적어도 이기적 동기는 잘 가지고 있을 것." 우울감이 지속되면 이 전제가 깨집니다. 스스로에게 이로운, 이기적인 판단조차 제대로 할 수 없게 됩니다.

그러니 "우울할 때에는 상담하기"를 기억합시다. 평소에 외워 두지 않으면, 우울할 때에 떠오르지 않습니다.

물론 한국은 우울장애에 대한 인지적 관점이 많이 부족한 사회입니다. 그러나 연락처 목록을 뒤져 보면 한두 명 정도는 믿고 이야기할 사람이 있을 것입니다.

주변 사람들을 못 믿겠다면, 일면식도 없는 전문가를 찾읍시다. 한국의 정신과 전문의나 상담심리사 등, 우울한 사람에게 도움을 줄 분들의 숙련도나 전문성은 뜻밖에도 전반적으로 뛰어난 편입니다. 믿고 도움을 청해 봅시다.


RE: https://gameguard.moe/notes/acyejg21pqcx00xl

1
13
6

In June, we announced HarfRust, a fully safe port of to Rust. At that time, HarfRust was 2x to 4x slower than HarfBuzz for a variety of benchmarks, so we have been working on addressing that.

Today, Chad Brokaw and I are pleased to present HarfRust 0.2.0, which is less than 25% slower than HarfBuzz, on both OpenType and AAT shaping benchmarks. We have also addressed all known correctness issues.

Charts:
docs.google.com/spreadsheets/d

0
0
0

Today is the new semester for @CMUDBCMU Database Group's Intro to Database Systems! We're going harder into material than ever before. Projects are more challenging but you can use LLMs to help. We also have 10min talks each Wed from leading DB companies. Follow from home/prison on YouTube: 15445.courses.cs.cmu.edu/fall2

Everything is available for free to non-CMU students:
• Lectures on YouTube: youtube.com/playlist?list=PLSE
• Slides + Notes + Homeworks on course website.
• Project source code on GitHub: github.com/cmu-db/bustub
• Grading with Gradescope (see FAQ ➡️ 15445.courses.cs.cmu.edu/fall2)

Special thank you to our Affiliate companies for their support this academic year:
• ClickHouse
• DataStax
• dbt Labs
• Firebolt
• MotherDuck
• RelationalAI
• SingleStore
• SpiralDB
• PingCAP / TiDB
• Yellowbrick
• Yugabyte

How can people not enrolled in the class test their projects?
All of the source code for the projects are available on Github. There is a Gradescope submission site available to non-CMU students.CMU-DB 2025 Industry Affiliate Program Members
https://db.cs.cmu.edu/affiliates/
1
0
0

Vim에 관심있는, 혹은 Vim을 사랑하는 여러분, 안녕하세요.

한국어권 Vim 사용자 모임 vim.kr입니다. 오늘은 vim.kr에서 공식적으로 주최하는 모임 소식을 전해드리려 합니다.

혹시 *빔교정학원 모임(vimrc)*을 들어보신 적 있으신가요? vimrc 밋업은 2019년과 2022년에 3년 간격으로 개최된 바 있는데, 2025년부터는 저희 vim.kr이 그 바통을 이어받아 공식적으로 진행하게 되었습니다.

지난 7월 2일, 기존 vimrc 밋업을 주최하셨던 박현우(lqez)님께 연락을 드렸고, 이어 7월 6일 첫 회의를 통해 vim.kr에서 본 행사를 이어가기로 확정하였습니다.

이번 vimrc 밋업은 이전과는 조금 다른 방식으로 준비되고 있습니다. 특정 연사자가 발표하는 자리가 아니라, 모든 참가자가 동등한 입장에서 자신이 Vim을 어떻게 활용하는지 경험과 노하우를 공유하는 자리를 지향합니다. 즉, 발표 중심의 형식보다 네트워킹과 상호 교류에 초점을 맞춘 밋업입니다.

행사 규모는 약 36명으로 계획 중이며, 일정은 11월 둘째 주에서 셋째 주 사이로 조율하고 있습니다. 현재 대관 장소도 검토 중이니, 혹시 행사 장소 후원에 관심 있는 분이 계시다면 연락 부탁드립니다.

행사 관련 최신 소식은 vim.kr 디스코드를 통해 안내드릴 예정입니다.

많은 관심과 참여 부탁드립니다. 감사합니다.

13
0
0