Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Web—think FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.

If the track is accepted, would you be interested in coming to Taipei (Aug 8–9) to give a talk?

(Boosts appreciated!)

https://hollo.social/@hongminhee/019ca8b2-ecca-7150-a237-37f35de45401

#fedidev #fediverse #SocialWeb #ActivityPub

去年12月受けたJLPTの認定書きたなんか日本語が喋れる韓国のオタクたちがみんなN1って日本語のチュートリアルみたいなものだと言ってて最初は自慢するのかなと思ったけど最近これは割と事実だったなと気付いた

TLにくるりの東京が見えていつ聴いてもすごくいい曲

“자바스크립트 툴체인의 모든 것을 VoidZero에게 맡기기” 자매품으로 파이썬 툴체인의 모든 것을 Astral에게 맡기기가 있다.

https://vite.dev/blog/announcing-vite8

こんど渋谷のGoogle for Startupsでエンジニア向けのミートアップがあるみたいです。因果AIや3D画像処理の会社が主催で、トークセッションもあるそうです。興味あれば覗いてみてください。

https://dxtfl.share-na2.hsforms.com/2-wHVxyeTSVG5KcmhCmUBEg?source=hootfolio

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 #ActivityPub, the #fediverse, 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

#SocialWeb #COSCUP #fedidev

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.

Salvatore Sanfilippo (@antirez) and Armin Ronacher (@mitsuhikoArmin Ronacher) both argue that #AI reimplementation of #copyleft libraries is fine. Their legal reasoning might be correct. That's not the point.

Legal and legitimate are different things—and both pieces quietly assume otherwise.

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

#GPL #LGPL #license #opensource #freesoftware

最近(최근) chardet의 MIT 리라이선싱과 關聯(관련)해서 Redis의 antirez와 Flask의 Armin Ronacher(一名(일명) mitsuhiko)가 이를 擁護(옹호)하는 글을 썼는데, 그에 對(대)한 나름대로의 反論(반론)을 써 봤습니다: 〈合法(합법)이면 公正(공정)한가: AI 再具顯(재구현)과 카피레프트의 侵蝕(침식)〉(한글).

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

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

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

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

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

I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8–9, Taipei)—think FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?

(Boosts appreciated!)

#ActivityPub #SocialWeb #fedidev #COSCUP

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

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

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

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

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

@Yohei_Zuhoもちもちずきん🍆 ちょうどテスト中TLで見えてそのままスクショになりました 😂

明日からHaze Leeさん（@nebuletoHaze）と一緒に一週間東京に旅行に行くんだ。楽しみ！

I've been increasingly concerned about the corporate monopoly over frontier LLMs. While many ethically-minded people choose to boycott these models, I believe passive resistance alone cannot break the structural grip of big tech. To truly “liberate” these technologies and turn them into public goods, we need to look beyond moral high grounds and engage with the material basis of AI—specifically compute, data, and the relations of production.

I've written two posts exploring this through the lens of historical materialism. The first piece analyzes why current “open source” definitions struggle with LLMs, and the second discusses what it means to “act materialistically” in our imperfect world. My goal is to suggest a path forward that moves from mere boycotting to a more proactive, structural socialization of AI infrastructure.

If you've been feeling uneasy about the AI landscape but aren't sure if boycotting is the final answer, I'd love for you to give these a read:

• Histomat of F/OSS: We should reclaim LLMs, not reject them
• Acting materialistically in an imperfect world: LLMs as means of production and social relations

#LLM #AI #opensource #historicalmaterialism #histomat #materialism #digitalcommons

연휴 끝나고 업무 시작하기 전에 Sneak Peak까지 구현했다. 뿌-듯

피카츄 쟁탈전에서 졌다... 전세계에서 피카츄를 기다리고 있는데 그냥 예약받고 생산해주면 안되겠니...??

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

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

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

https://moim.live

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

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

ChatGPT가 한국어로 "너 **핵심을 찔렀어"같이 말하는 것처럼 일본어에선 結論から言うと(결론부터 말하자면)로 시작하는 경우가 많다고 한다. 그리고 지금 내 Codex 세션이 딱 그런 느낌으로 응답하고 있네...

以前から、東アジアにもFediConのようなイベントがあればいいなと言い続けてきました。独自のカンファレンスはまだ難しそうですが、小さな一歩として考えていることがあります。

@COSCUP 2026（台北、8月8日〜9日）がコミュニティトラックの提案を受け付けています。FOSDEMのSocial Web devroomのような感じで、Social Webトラックを開けないかなと思っているところです。

まだ構想段階ですが、ActivityPubやフェディバース、ソーシャルウェブ全般に取り組んでいて、発表や共同オーガナイズに興味があるという方がいれば、ぜひ話しかけてください。

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

#SocialWeb #ActivityPub #fediverse #フェディバース #COSCUP #fedidev

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

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

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

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

#SocialWeb #fediverse #연합우주 #페디버스 #COSCUP #fedidev

🚀 COSCUP 2026 Call for Participation is now open!

🎤 Community Tracks – Run a open-source agenda with talks, panels, or workshops. Apply by Mar 23. Spots are limited.

🛠 Community Booths – Showcase your project, recruit members, and connect. Apply by Jun 9. First come, first served.

👉 Apply here: https://s.coscup.org/26communityen

#COSCUP2026 #OpenSource #Community

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

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

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

🚀 COSCUP 2026 Call for Participation is now open!

🎤 Community Tracks – Run a open-source agenda with talks, panels, or workshops. Apply by Mar 23. Spots are limited.

🛠 Community Booths – Showcase your project, recruit members, and connect. Apply by Jun 9. First come, first served.

👉 Apply here: https://s.coscup.org/26communityen

#COSCUP2026 #OpenSource #Community

모델 선호에 대해 조금 더 말하자면 여전히 문서를 작성히거나 이미지가 필요 없는 모든 작업에선 Claude를 선호한다. 코딩 작업 시 planning과 review 단계에서 Codex를 훨씬 더 선호하고, 코드를 작성하거나 수정하는 일은 토큰 효율이나 시간 효율을 생각하면 Opus나 Sonnet이 더 좋다.

요즘 일할 때 Opus 4.6보다 GPT-5.3 Codex를 애용하고 있지만 그럼에도 나는 Anthropic이 LLM의 alignment나 safety, explainability 분야에서 제일 잘 하고 있는 곳이라고 생각한다.

미국 정부와 관련된 일련의 사건에서 누가 잘잘못을 따지는 것과는 별개로 미국 정부가 저렇게까지 강경하게 나서서 가지지 못하면 부숴버리겠어!!!!!! 같은 스탠스를 취하고 있다는건, 그만큼 Anthropic의 모델이 우수해서가 아닐까.

그러고선 OpenAI가 Anthropic 자리를 대신 들어갔는데 정작 OpenAI도 Anthropic가 제한한걸 그대로 제한하고도 계약을 딴걸 보면 미국 정부가 자기네 정치적 이유로 OpenAI를 밀어줬거나 OpenAI는 미국 정부가 원하는 것을 이루기 위해 뒤에서 제한을 풀어주지 않을까하는 우려가 크다.

3月4日(水)から11日(水)まで東京に滞在します。この機会に日本のフェディバースの皆さんとお会いしたいです。ランチでもディナーでも、お茶やコーヒーでも構いません。私と会ってくださる方はいらっしゃいますか？食事やお茶は私がおごります。私はこの期間中、特に予定がないので、皆さんのご都合に合わせることができます。（ただし、最終日を除きます）

SheetKit은 처음으로 설계나 의사 결정 외에는 모든 구현을 코딩 에이전트에게 위임하면서 만들었습니다. 이 과정에서 코딩 에이전트로 어떻게 큰 작업을 효율적으로 하는지, 또 어떻게 코딩 에이전트와 함께 잘 작업할 수 있을지 등을 많이 배웠습니다.

이 경험에 대해서도 시간 여유가 될 때 정식으로 글로 적어보고자 합니다.

지난 주말부터 열심히 토큰을 팍팍 태워 만든 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

기존 ExcelJS를 쓰던 프로젝트에 SheetKit을 붙이다가 문득 궁금해져서 벤치마크 스크립트를 만들어보게 시켜보았다. 데이터 유효성 검사 설정을 많이 추가해둔 기존 템플릿 파일에서 SheetKit이 최대 10000배 이상 빠른 결과가 나왔다. 바퀴 재발명 야크 셰이빙이 뿌듯해지는 순간이다.

코딩 에이전트를 풀로 활용해서 나보단 코딩 에이전트가 만들고 있는 TypeScript와 Rust를 위한 스프레드시트 라이브러리. 타입스크립트에서 xlsx 파일을 다루는 라이브러리들 쓰다가 너무 괴로워서 만들게 되었다. (GitHub Actions 배포 이슈는 내일 마저 잡는걸로…)

https://github.com/Nebu1eto/sheetkit

TIL: Biome은 자체적으로 만든 AST 쿼리 언어인 GritQL을 통해 Plugin 시스템을 제공한다. [문서]

language js

// 4개 이상의 서로 다른 useState를 사용하는 경우
or {
  `function $name($args) { $body }`,
  `$name = ($args) => { $body }`,
  `$name = forwardRef(($args) => { $body })`,
  `$name = React.forwardRef(($args) => { $body })`,
  `$name = forwardRef(function($args) { $body })`,
  `$name = React.forwardRef(function($args) { $body })`,
  `$name = memo(($args) => { $body })`,
  `$name = React.memo(($args) => { $body })`,
  `$name = memo(function $name($args) { $body })`,
  `$name = React.memo(function $name($args) { $body })`
} where {
  $body <: contains `$t1 = useState($a1)` as $b1 where {
    $body <: contains `$t2 = useState($a2)` as $b2 where {
      or { not $a2 <: $a1, not $t2 <: $t1 },
      $body <: contains `$t3 = useState($a3)` as $b3 where {
        or { not $a3 <: $a1, not $t3 <: $t1 },
        or { not $a3 <: $a2, not $t3 <: $t2 },
        $body <: contains `$t4 = useState($a4)` as $b4 where {
          or { not $a4 <: $a1, not $t4 <: $t1 },
          or { not $a4 <: $a2, not $t4 <: $t2 },
          or { not $a4 <: $a3, not $t4 <: $t3 },
          register_diagnostic(
            span = $name,
            message = "컴포넌트 안에서 너무 많은 useState를 쓰고 있습니다."
          )
        }
      }
    }
  }
}

@hongminhee洪 民憙 (Hong Minhee) 처음에 그걸 해봤다가... 도저히 이건 가능하지 않구나라고 깨달았습니다 ㅋㅋㅋㅋ 줄바꿈이나 이런 것들도 기계가 읽기 좋은 포맷이 아니라서 라이브러리들의 힘으로 열심히 후처리를 하고 있습니다

@hongminhee洪 民憙 (Hong Minhee) 사실 이건 PDF -> Markdown으로 변환 후 -> context window에 맞게 쪼개서 병렬로 번역 -> 결과물을 Markdown으로 병합한 다음 -> PDF로 변환하는 것입니다 ㅋㅋㅋ 그래서 실질적으로는 Markdown이에요

최근 그냥 코딩 에이전트에게 코딩을 넘어서 삶의 귀찮은 자동화나 일들을 대신 해주는 느낌으로도 쓸 수 있지 않을까 싶어서, 자는 동안 남은 토큰 한도로 epub 파일로 된 소설을 번역시켰더니 꽤 그럴싸한 수준의 번역이 나와서 놀랐다. 그래서 이건 좀 잘 만들어두면 굉장히 편하겠다 싶어서 pdf 파일과 epub 파일을 번역하는걸 Agent Skills로 만들어보았다.

• PDF or epub 파일 지원
• 번역 효율과 context window 문제를 피하기 위해 큰 파일은 잘라서 병렬로 하위 Task를 실행하는 형태로 동작
• PDF의 경우, 텍스트를 추출 과정에서 줄바꿈 등에 대한 후처리
• epub의 경우, 우종서(중국어나 일본어)나 RTL 방식 언어의 레이아웃에도 대응

Repository

"AD8K, with Dolby Vision"

These days, my friends with ADHD and I have started calling our condition AD4K, or even AD8K, because our symptoms feel so severe. 😂

식탁보 1.15.0 버전을 출시했습니다. 1년여만의 대규모 업데이트로, .NET 10 적용과 함께 커뮤니티에서 불편 사항으로 여겨졌던 Windows Sandbox의 vGPU 기본 사용 문제, 언어 표시 문제, 그리고 인스톨러 간소화 등 성능과 기능 간소화는 물론, 코드의 분량을 대폭 간소화했습니다.

추후 TableCloth3 프로젝트에서 개발 중인 Avalonia 기반 프론트엔드로 쉽게 전환할 수 있도록 땅 다지기 작업도 같이 진행해두었고 계속 업데이트해나갈 예정입니다. 그리고 이번 업데이트부터 ARM64 빌드도 정식으로 제공됩니다.

꾸준한 관심과 성원에 늘 감사드립니다.

#식탁보 #오픈소스 #인터넷뱅킹 #전자정부 #공동인증서 #NPKI

https://forum.dotnetdev.kr/t/1-15-0/14191

한 10년 정도만에 무라카미 하루키의 언더그라운드 시리즈를 다시 읽었다. 종교가 사회 문제를 일으키는 요즘 한국에서도 읽어볼만한 책이라고 생각한다. 느낀 점을 다 쓰려면 글을 쓰는데만 한 세월일 것 같으니 기록만.

예전에 LLM이 얼마나 복잡한 코드를 이해할 수 있는지 파악하기 위해 Gemini 2.5 모델들로 내 IOCCC 2012 수상작을 던지고 무슨 일을 하는지 실행 없이 알아 맞춰 보라고 했더니 하나도 제대로 파악하지 못했던 적이 있다. 문득 생각이 나서 Gemini 3 Pro는 개선되었을려나 생각했는데, 힌트 하나만 받고 10분동안 생각하더니 완벽하게 응답에 성공했다! 심지어 설명도 실행 없이 분석했다는 걸 감안할 때 매우 정확했다. IOCCC 수상작을 모두 기억하고 있을 가능성을 감안해 이전에 본 적이 있냐고 물어 보니 환각(...)을 내뱉는 것도 그렇고(그보다 외웠다면 처음에 바로 정답을 얘기했겠지), 실제로 생각 과정을 보면 사람이 할 법한 분석을 전부 하고 있는 걸 보니 진짜로 LLM들의 reasoning 능력이 이 정도 수준에 도달했음을 알 수 있다. 세상 참 많이 발전했네.

@bglbgl gwyng 그러면 계속해서 여러 개의 메세지가 나올 때, 한번 스트리밍이 끝나면 어느 인덱스의 메세지에서 최종 output을 확인할 수 있는지 별로인 것부터가 크다고 생각합니다. 그 뿐만이 아니라 요즘 LLM들은 Text랑 Tool Calling 말고도 multimodal 모델들이 많아서 Image나 File도 첨부할 수 있는데 이런 part들은 어떻게 한 메세지에 확장해서 담을 수 있을지 고민한 결과이기도 하구요.

@bglbgl gwyng

전 LangChain / LangGraph에 비하면 Vercel AI SDK가 훨씬 sane하다고 생각합니다 ^_ㅜ… 원래 에이전트를 LangChain으로 만들다 이제 Vercel AI SDK에 정착했습니다.

Tool calling은 무엇을 써서 만들어도 안에선 결국 LLM이 호출할 함수와 실행 인자 토큰을 보내면 그걸 provider의 SDK나 그걸 감싼 라이브러리(e.g. LangChain or AI SDK)에서 schema validation을 하고 실패하면 retry를 시키고 하면서 사실상 자기 혼자서 멀티 턴처럼 수행합니다.(그러다가 루프가 나거나 하지 않도록 안에서 상태 머신을 만들고 depth라던가 제한하는거구요.) 그리고 각 파트가 업데이트되고 토큰을 계속 업데이트하다가 동작이 모두 끝나면 그 Part 속 전체 메세지와는 별개의 Message 전체 출력이 나온다는 점에서 이 방식이 맞다고 생각합니다.

저흰 클라이언트와 서버가 굉장히 구분된 편이긴 한데, 서버에서 SSE로 스트림 돌면서 text-delta이면 토큰 이벤트로 추가된 토큰을 내려주고, 스트림이 다 끝나면 전체 텍스트를 가져와서 완료 이벤트로 전체 텍스트를 한번 더 내려주고 대화 제목 업데이트가 필요하면 대화 제목 만들어서 대화 제목 이벤트 보내주고 완료 시점에 데이터베이스에 저장하고 완료 이벤트를 내리고 있습니다. + 클라이언트의 SSE 연결이 끊어져도 해당 작업은 계속 백그라운드에서 돌게만 해두었습니다.

아마 저희가 AI SDK의 프론트엔드 컴포넌트를 쓰지 않고 별도로 자체적으로 이벤트 목록과 스키마를 정해서 그걸로 컴포넌트를 만들어서 크게 스트레스를 못 받는 것일지도 모르겠네요.

@lavieenbleu블루 이게 서버에서 렌더링되는지, 클라이언트에서 렌더링되는지 구분하는 멘탈 모델과 Vercel이 아닌 인프라에서 Next.js를 배포하는게 별로여서 바꾸었어요. 아직 베타 단계지만 TanStack Start나 아니면 React Router v7의 방식이 훨씬 낫다고 생각합니다.

@bglbgl gwyng 일단 렌더링이 어디서 일어나는지를 개발자가 신경 써야하고 거기에 클라이언트에서의 상태 처리까지 생각해야하는게 좀 많이 접근이 아쉬운 것 같습니다. React Router v7이나 TanStack Start 등을 더 선호하게 되는 것 같아요.

@lavieenbleu블루 가벼운 개인 홈페이지를 만들 때 스프링부트같은 도구는 좀 과할 수도 있을 것 같아서, static site generator같은게 있어도 괜찮지 않나 생각합니다.

전 예전엔 이런걸 Next.js + Contentlayer로 만들었었는데 요즘은 TanStack Start + Content Collections로 옮긴 상황이에요. 제 개인 블로그 등의 홈페이지도 이걸로 만들까 생각하고 있습니다.

@bglbgl gwyng 전 그래도 LangChain으로 민드는 것보다 압도적으로 편한 경험이라 생각하고 있는데(Next.js는 아니고 SSE로 내려주는 형태의 백엔드입니다.) 어떤 점이 아쉽거나 힘들다고 느껴지나요??