마스토돈 스타일의 새로운 커뮤 플랫폼, 커뮹! 모바일 앱이 출시되었어요! 베타 테스트에 참여해주신 여러분, 커뮹!에서 활동해 주시는 여러분 모두 응원해주셔서 감사합니다 🐓📲🥰
iOS: https://apps.apple.com/us/app/commung/id6755352136
Android: https://play.google.com/store/apps/details?id=ng.commu
bgl gwyng
@bgl@hackers.pub · 98 following · 123 followers
GitHub- @bglgwyng
주말동안 Nix Flake의 워크스페이스 flakespace를 만들었는데, 구현이 너무 Hacky해서 솔직히 내가 만들어놓고도 쓸 맘이 안든다. 잡버그 고치느라 시간을 많이 버릴 걱정이든다. 일단 트라이는 해보겠다만.. Nix Flake가 자체적으로 워크스페이스 기능을 제공했으면 좋겠다.
합주실 창업과 시스템 구축 과정에 대한 후기를 남겨보았습니다.
- 1부: 계획과 준비 과정
- 2부: 예약, 운영 시스템 구현 상세
- 3부: 운영하며 느낀 점들
@bglbgl gwyng 저는 주로 모듈에서 모듈로 코드를 이동시키는 리팩터링을 할 때 그 이력이 버전 관리 시스템에 남지 않는 게 불편하다고 느꼈어요. 저장소를 나누면 한 쪽에서는 코드가 삭제된 걸로 되고, 다른 한 쪽에서는 코드가 추가된 걸로 되는데, 이러면 나중에 이 코드가 예전에 어떻게 작성되었는지 이력을 추적할 때 (커밋 메시지에 잘 적어두지 않는 한) 실마리가 사라지더라고요.
@hongminhee洪 民憙 (Hong Minhee) 오 그렇네요. 그 경우에, 그 두 모듈의 히스토리에 서로의 커밋 해시를 남기면 일단 정보는 다 보존할 수 있는것 같아요. git은 커밋 메시지가 커밋해시를 바꿔서 이렇게 못하지만 그렇지 않은 VCS의 경우엔, 실천은 둘째치고, 정보 보존은 가능해 보입니다.
모노레포를 쓸때 pnpm, cargo 등에 있는 워크스페이스를 많이들 쓴다. 근데 모노레포는 잠깐 제쳐두고, 워크스페이스가 뭐하는 기능일까? 워크스페이스는 여러개의 모듈을 동시에 작업할 때 쓰는 기능이다. 근데 어떤 모듈을 수정할 때 다른 모듈을 같이 수정해야 한다면, 걔들이 잘 정의된 모듈이 맞을까? 커플링이 있다면 그걸 제거하는게 정공법 아닌가?
여러 모듈을 동시에 고쳐야 하는 상황의 존재를 부정할 순 없다. 내 생각에 워크스페이스는 일시적으로 존재해야 하는 것이다. 사실 전혀 관계 없어 보이는 두 모듈을 어떤 뜬금없는 이유로 같이 고쳐야하는 경우도 종종 있다. 그럴때 잠깐 만났다 헤어지면 되는 것이다. 그러니까 워크스페이스는 서로 관계있는(관계 없어야 한다니깐) 모듈들이 천년만년 함께 모여있는 집이 아니라, 몇몇 모듈들이 잠깐 서로 용건이 생겼을 때 모이는 광장이어야 한다. 그런데 대부분의 경우 전자의 용례를 따르고 있다.
lat을 만들면서 클로드를 레포 4개에서 동시에 돌렸는데 예상치 못한 문제가 있었다. 내가 원래 모노레포를 별로 안 좋아해서(+ 레포를 나눴을때 빌드의 문제를 Nix가 해소해줌) 관련있는 레포 4개를 그냥 따로 따로 팠는데, 클로드가 일할때의 맥락을 전파해주는게 매우 번거로웠다. 클로드한테 줄 맥락을 기준으로 레포를 나누는게 맞는건가? 아니면 레포를 나누더라도 맥락을 다시 합칠 좋은 방법이 있을까?
이제 lat을 brew로 설치가능합니다.
brew install bglgwyng/tap/lat아 그리고, 진짜로 토큰 소비를 줄이고 LLM이 일하는데 도움이 되는지는 아직 모릅니다. 실험을 해봐야아는것이니 피드백 환영합니다.
LLM을 위한 cat, lat의 프로토타입을 완성했습니다. 당장은 Nix 유저만 쉽게 설치할수 있습니다. 다른 패키지 매니저 지원을 비롯해 빠르게 개선하겠습니다.
나는 AI한테 인권없다는 주의인데, 클로드는 어쩌다 실수하면 아예 도게자를 박아버려서 나도 모르게 괜찮다고 토닥이게 된다..
레포 파놨더니 모르는 사람들이 스타를 찍기 시작해서. 급하게 WIP라고 써놨다. 빨리 완성하자...
LLM 코딩의 부정적인 영향으로 우려하는 부분이 있는데, 점점 현실이 되어가는거 같다. 사람들이 코드를 안 읽고 너무 많이 짠다.
사실 오랫동안 많은곳에서 쓰이는 좋은 프로그램들은, 그 많은 코드를 짜서 어떻게든 동작시키게 만들었다는 것 이전에, 그냥 '뭘 만들지'에 대한 접근부터 훌륭한 경우가 많다(많은 UNIX 기본 프로그램들을 생각해보라). 옛날에는, 내가 어떤 기능 A가 필요할때, 내가 그 기능 A를 짜는게 힘든 일이니까 그 기능 A를 제공하는 프로그램을 먼저 찾게되고, 그러면 그 프로그램은 나의 근시안적인 접근보다 나은 더 좋은 개념을 갖고 있는 경우가 많았다. 그러면 나는 이제 그 개념을 익히며 내 자신을 업데이트하면 되는 것이다.
근데 자기 자신을 업데이트하는건 피곤한 일이라서, 사람들은 그걸 피할수 있는 기회를 놓치지 않는다. 그래서 현재 자기 수준에 맞는 평범한 프로그램을 만드는 길을(단돈 0.1$) 기꺼이 선택해버린다.
프로토타입은 만들었고, 이제 각 언어별로 resolver?를 만들면 된다. JSON, JS 순으로 해야지.
소프트웨어 엔지니어 채용중입니다. https://careers.linecorp.com/ko/jobs/2961/ Rust(도) 하는 팀입니다.
훌륭한 프로그래머인 
저는 유별난 Markdown 스타일을 고집하는데요, 그래서 어떠한 린트나 포매터도 제 요구 사항을 충족시키지 못해서 Markdown 문서에 한해서는 린트/포매터 없이 손으로 고치며 살고 있었습니다만… 오늘 갑자기 삘 받아서 바이브 코딩으로 markdownlint 커스텀 룰들을 구현했습니다. 아마도 이걸 필요로 하는 분들은 없겠지만…
@bglbgl gwyng 오… 좋은 아이디어 같아요! MCP 서버로도 동작하면 좋을 것 같네요. 당장 저장소 파주세요.
@hongminhee洪 民憙 (Hong Minhee) https://github.com/bglgwyng/lat 일단 아이디어 기록 용으로 팠습니다. vertana로 영문 README를 만들어 봐야겠네요.
LLM을 위한 cat, lat을 만들어볼까 생각이 들었다. 어떤 파일을 열던지 간에, 토큰 아끼고 LLM이 쉽게 읽도록 적당히 알아서 바꿔서 보여주는 것이다. 그리고 CLAUDE.md 같은거에 cat 대신에 쓰라고 하는거지.
처음엔 JSON 파일을 minify해서 토큰 아끼는 정도를 생각했는데, 막상 클로드한테 물어보니 자기도 들여쓰기가 있어야 읽기 편하다고 한다. 응? 그래서 쓸모있는 접근을 물어봤더니, 코드를 읽을때 앞에 함수 시그니쳐/클래스 정의 등의 요약을 달아주면 좋겠다고 한다.
쓸모있게 만드려면 좀더 고민해야할듯..
Zod가 lazy validation을 지원안하길래 대안을 찾아봤는데, 잘 알려진것중엔 Valibot의 v.lazy 뿐인것 같다
클로드 코드 쓰고있으니 더 나은 VCS에 대한 욕심이 커진다. 나는 클로드가 브랜치를 더 자주 쪼개서, 원하는 시점으로의 롤백이 더 편해졌으면 좋겠다.
하나 생각나는 아이디어는 브랜치 명을 hierachial하게 만들어서 가령 fix-bug-1/refactor-class-foo/fix-function-bar 이런식으로, 무슨 일하는지의 맥락을 브랜치명에 나타내는 것이다. 그리고 a/b 브랜치는 a 브랜치의 자식이어야 한다는 제약도 강제한다.
...는 git은 a란 브랜치가 이미 있으면 a/b, a/c 같은 브랜치를 못만든다. 이유는 바로... git 브랜치가 이름 디렉토리로 관리되기 때문이다. 뭐 이런;;
근데 솔직히 마크다운이 "너 진짜 **핵심**을 찔렀어"의 형태로 대중화가 될 줄은 몰랐지...
"지코"는 래퍼고 얘는 "지토"입니다 헬로 지토 헬로
@bglbgl gwyng 
@hongminhee洪 民憙 (Hong Minhee)
@hongminhee洪 民憙 (Hong Minhee) 저도 비슷한 이유로 Emacs로 회귀했다가 지금은 Zed를 쓰게 되었습니다 😂
@hongminhee洪 民憙 (Hong Minhee) 저도 한달째 Zed 쓰고 있는데 Git 연동 개선이 시급합니다. 말씀대로 요즘은 에이전트가 작업한거 리뷰하는 시간이 상당한데, 이때 Zed가 많이 불편합니다. 그냥 Zed 터미널에서 lazygit쓰고 마네요.
@bglbgl gwyng @hongminhee洪 民憙 (Hong Minhee) 개인적으로 느끼기에는 말씀하신대로 하는게 프롬프트로 일일히 설명하는것보단 유의미하게 더 낫기는 했습니다.
@khrisHong Segi (aka khris) @hongminhee洪 民憙 (Hong Minhee) 아항 실제로 잘 동작하는군요. 저게 정공법인거 같은데 저걸 덜 번거롭게 하는 방향을 기대해봅니다.
심지어 import 한 줄 추가하는 것도 프롬프트로 해결하게 된다. 그래야 LLM한테 맥락이 주어져서 혼선이 없기 때문이다.
이 부분 완전 공감합니다. 일일히 설명하는 방법도 써봤는데 완벽하지가 않더라구요...
@khrisHong Segi (aka khris) @hongminhee洪 民憙 (Hong Minhee) (그대로 실천하려면 애로사항이 있겠지만) 커밋을 작은 작업단위로 하고, 모델이 작업을 시작할때 그 사이 추가된 커밋을 프롬프트로 넣어주는 방법은 잘 동작할까요?
프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.
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를 섞어서 쓰면 어떨까 생각만 해보고 있다.
bgl gwyng shared the below article:
Hackers' Pub 신고(flag) 기능 기획서
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Hackers' Pub 커뮤니티의 신고 시스템은 단순한 제재를 넘어 구성원의 성찰과 성장을 돕는 분산형 네트워크 환경을 지향합니다. ActivityPub 프로토콜을 기반으로 설계된 이 시스템은 Mastodon 등 외부 플랫폼과의 연합(federation) 환경에서도 유연하게 작동하며, 신고자의 익명성 보호와 피신고자의 알 권리 사이의 균형을 유지합니다. 기술적으로는 거대언어모델(LLM)을 활용하여 자유 형식의 신고 사유를 실시간 행동 강령(code of conduct) 조항과 동적으로 매칭하고, 신고 시점의 콘텐츠 스냅샷과 행동 강령 버전을 기록하여 검토의 객관성을 확보합니다. 관리자는 경고, 콘텐츠 검열, 일시 및 영구 정지로 이어지는 단계적 제재 체계를 통해 투명하게 사건을 처리하며, 피신고자는 이의 제기(appeal) 프로세스를 통해 공정한 재심 기회를 보장받습니다. 이러한 체계적인 설계는 자율적인 커뮤니티 관리의 복잡성을 해결하고, 건강하고 지속 가능한 연합우주(fediverse) 생태계를 구축하는 데 필요한 실무적인 통찰을 제공합니다.
Read more →인터페이스가 구린 라이브러리를 쓸때는 반!드!시! 심호흡을 하고 멀쩡한 인터페이스의 wrapper를 만든후에! 기능 개발을 합시다. 절대 대충 꾸역꾸역 만들어보자고 덤비면 안됩니다. 결국 후회합니다.
- V모사의 AI 라이브러리를 쓰다가
Claude Code의 인기와 함께 터미널에서 한글을 쓰는 모습을 자주 볼 수 있습니다. 하지만 터미널에서 쓰이는 한글은 글자간의 간격이 넓어 보기 좋지 않은 경우가 많습니다. 왜 이런 걸까요?
흔하게 쓰는 코드용 글꼴은 로마자, 숫자, 특수기호만을 다룰 뿐 한글은 다루지 않습니다. 그래서 터미널은 한글 표시를 하기 위해 대체 글꼴을 사용합니다. 대체 글꼴은 보통 OS의 기본 글꼴일 것입니다. 가변폭 글꼴이겠죠. 터미널은 이를 일부러 고정폭으로 만들기 위해 한글 한 자에 로마자 2자 폭을 할당하는데 이 과정에서 여백이 추가되면서 자간이 넓은 어색한 한글을 보게 되는 것입니다.
해결책은 한글 고정폭 글꼴을 사용하는 것입니다. 한글 고정폭 글꼴은 한글 1자를 로마자 2자 폭에 맞춰 만들었으므로 터미널이 더 이상 여백을 만들지 않습니다. 이러한 한글 고정폭 글꼴이 많진 않습니다. 10종이 안 되는 것 같네요. 저는 그중 Monoplex를 사용하고 있습니다. @hongminhee洪 民憙 (Hong Minhee) 님은 Sarasa Gothic을 사용하신다고 하네요. 적은 수의 글꼴이지만 맘에 드시는 걸 찾으셔서 예쁜 한글 출력을 보시면 좋겠습니다.
갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.
Optique 0.9.0 pre-release is ready for testing!
The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).
The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.
Try it:
npm add @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212I'd love feedback before merging! Especially interested in:
- API ergonomics
- Edge cases I might have missed
- TypeScript inference issues
Docs:
흑백요리사 보는데 재미는 있지만 룰이 엉성하고 개판이라 찜찜하다. PD들을 모아서 코딩 교육을 시키고 싶다.
@bglbgl gwyng 흠, 생각해 보니 그렇네요. 근데 그렇게 가다 보면 LangGraph나 Mastra 같은 것에 가까워 지는 것 같기도 하고요…? 🤔
@hongminhee洪 民憙 (Hong Minhee) 
맞습니다ㅋㅋ LangGraph 같은거 중에 인터페이스 좋은걸 찾아서 그위에 구현하면 좋겠네요.
@bglbgl gwyng 오… 아직 생각해 본 적 없는데, 그런 툴과 함께 쓰는 것도 다음 버전에서 생각해 보도록 하겠습니다!
@hongminhee洪 民憙 (Hong Minhee) 사실 저도 비슷한 툴을 고민하고 있었는데 참고할만한 예시가 나와서 도움이 될서같네요. 저는 번역작업을 task planning 라이브러리로 일반화 하고 싶습니다. Chunking, refinement, best-of-N 모두 task planning과 관련된 동작들이죠.
Released Vertana 0.1.0—agentic #translation for #TypeScript/#JavaScript.
Instead of just passing text to an #LLM, it autonomously gathers context from linked pages and references to produce translations that actually understand what they're #translating.
- Docs: https://vertana.org/
- GitHub: https://github.com/dahlia/vertana
@hongminhee洪 民憙 (Hong Minhee) 새로운 멋진 작업이군요! 혹시 docusaurus랑 연동하는 best practice가 어떤식일지 생각해두신게 있을까요?
VCS와 패키지 매니저가 통합되어야 한단 얘기를 했었는데, shadcn의 인기가 그런 방향에 대한 지지를 간접적으로 보여주고 있다. shadcn은 UI 라이브러리를 만들어봤자 어차피 고쳐쓰는 경우가 많아서 나왔다. 문제는 기존의 npm 패키지 같은 것들은 받는건 쉬운데 그다음에 고치는게 열불터지는 것이다.
- 조건에 맞는 소스 코드를 받는 것 2. 그걸 고치는 것, 에서 패키지 매니저는 1은 잘하는데 2를 불편하게 만든다. VCS는 1을 할수있는데, 약간 번거롭게 되어있고(git submodule을 생각해보라), 2는 당연히 쉽다. VCS에서 1을 개선해야한다.
Released Vertana 0.1.0—agentic #translation for #TypeScript/#JavaScript.
Instead of just passing text to an #LLM, it autonomously gathers context from linked pages and references to produce translations that actually understand what they're #translating.
- Docs: https://vertana.org/
- GitHub: https://github.com/dahlia/vertana
Zed는 망치가 좀 부족한가.. 심지어 성능도 좋은게 잘 체감 되지 않는데, 렌더링이 아닌 다른 곳에서(아마도 LSP와의 통신?) 구현이 구린지 랙이 빈번하다.
(개인 계정, 이어잇 계정 나눠서 올리다 자주 섞입니다. 당분간 서비스 소식을 주로 올릴 예정이라, 함수형으로 팔로우 해주신분들께 스팸일 것 같아 미리 양해를 구합니다.)
여행가는 느낌 나나요?
yearit.com
AI 물 사용량 떡밥의 문제는, 그 이야기를 하는 사람의 상당수가 AI의 결과물은 모조리 무가치하다는 생각을 하고있다는 것이다. 결과물의 가치가 0이라면, 뭐 물을 500ml만 써도 낭비는 낭비겠지요? AI와 관련해 해결해야할 문제가 한두개가 아닌데, 논의에 질을 높이고 고품격의 토큰이 오갔으면 좋겠다.
(아무도 관심없겠지만) 요거의 예시로는 tree-sitter의 파싱 테이블 + AST node 메타데이터 export가 있다. 지금은 파싱 테이블 대신 parser.c만 뱉고 중요한 메타데이터를 몇개 빼먹는다. 하는 김에 rewrite in haskell도 하면 더 좋고..
NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.
@bglbgl gwyng 조금 박한 평가일지는 모르겠지만 NextJS는 SEO가 중요한 거 아니면 굳이라는 생각입니다. SSR을 써야 하는 경우가 요즘에는 상당히 제한적이라는 게 제 생각입니다. 굳이 따지자면 프론트엔드랑 백엔드랑 같이 작업할 수 있다 정도인데, 이건 풀스택이 아닌가 싶기도 하고요.
좀 웃긴 생각이 났는데, '해결해주면 나랑 친해질수 잇는 문제들'이란 목록을 만들어서 공유하고 싶다. 네임드가 되면 실제로 잘 동작하려나.
오늘의 권장 행동
랜덤채팅, x톡 이런데에 아래 전화번호 뿌리기
010-3987-0378
010-7955-5680
뿌릴수록 보이스피싱 피해자가 줄어듦
오랜만에 카메라를 들고 산책을 다녀왔습니다. 메리 크리스마스 이브입니다!
https://news.hada.io/topic?id=25285
추상화가 강력한 더 좋은 언어를 쓰는 것 이상의 확실한 방법이 없고, 그 외에는 그냥 임시방편이라고 생각함.
Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.
If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.
@bglbgl gwyng 그러면 계속해서 여러 개의 메세지가 나올 때, 한번 스트리밍이 끝나면 어느 인덱스의 메세지에서 최종 output을 확인할 수 있는지 별로인 것부터가 크다고 생각합니다. 그 뿐만이 아니라 요즘 LLM들은 Text랑 Tool Calling 말고도 multimodal 모델들이 많아서 Image나 File도 첨부할 수 있는데 이런 part들은 어떻게 한 메세지에 확장해서 담을 수 있을지 고민한 결과이기도 하구요.
@nebuletoHaze 저는 Message에 isFinal같은 프로퍼티가 있으면 된다고 생각하고, 말씀하신 이미지나 파일 첨부도 그냥 메시지를 쪼개는게 낫다고 생각합니다. 그냥 챗봇(AI 챗 UI가 아니라 디스코드 등에 붙는)이 가질만한 인터페이스를 그대로 가지는게 낫다고 생각해요.