@bglbgl gwyng 네, 물론이죠!

bgl gwyng
@bgl@hackers.pub · 87 following · 107 followers
슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.
GitHub
- @bglgwyng
shootee
- www.shootee.io
@hongminhee洪 民憙 (Hong Minhee) 기대됩니다! 사실 저는 자동완성이 잘된다면, 단축형 옵션같은 기능이 덜 중요해진다고 생각합니다. 또 단축형 표형이 사소하지만 어쨋든 학습을 필요로 하는 단점이 있다고 생각합니다. 저 아직도 tar뒤에 xvzf인가 무슨 의미인지 몰라요ㅋㅋ
생각해 보니 option terminator 문법(--
뒤에는 옵션처럼 생긴 게 와도 인자로 인식하게 하는 것)은 또 어떻게 구현해야 하나…
@hongminhee洪 民憙 (Hong Minhee) 혹시 자동완성 스크립트를 생성해주는 기능도 고려하고 계신가요?
프로그램 명세서는 문서 그 자체로도 컴파일 되어야만 한다
프로그램 명세서는 문서 그 자체로도 컴파일 되어야만 한다
@joonnotnotJoon 반대로 컴파일이 안되면 명세가 아니고 이를통해 가짜 명세를 구분할수있겠지요
JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?
@bglbgl gwyng Vite 같은 경우에는 기본적으로
import.meta.env.DEV
이 빌드 시에는 false
로 치환되어서 minifier 돌리면 안쪽 코드가 통째로 날아가게 할 수 있습니다. 다른 번들러들에서도 비슷한 방법을 찾아볼 수 있을 것 같네요
API 기반 에이전트에서 요금제 기반 에이전트로 넘어와, 이제 마음껏 감사인사를 하는 풍부한 인간이 되었습니다.
미리미리 아부 떨어서 기계화 시대를 대비하자
JS 라이브러리를 만들때 개발시엔 invariant check를 위해 assert를 쓰되, 배포할땐 빼고싶거든요. 어떤 좋은 방법이 있을까요?
@bglbgl gwyng 태국에서 디지털 노마드 생활하시는 분들 많더라고요.
@hongminhee洪 民憙 (Hong Minhee) 아 이미 많이들 하는 방식이었군요??
여행 다녀왔는데 또 가고싶다... 예전에 1인 창업을 위해 베트남에서 생활하는 개발자를 만난적이 있다. 사실 휴양지에 가면 플렉스를 해버려서 그렇지 그걸 참으면 돈을 아낄수 있긴하다. 디지털 노마드의 로망을 1년 정도는 실현해보고 싶은데...
이번 Ubucon Korea 2025에서 발표할 주제로, 식탁보의 리눅스 버전에 대한 이야기를 준비하면서 간단한 Demo를 WSL로 준비해보았습니다.
일상적으로 사용하는 리눅스 시스템에 보안 플러그인을 그대로 설치하는 것은 솔직히 많이 위험합니다. 하지만, LXD 덕분에 이런 위험을 최소화하면서도 편의성과 보안의 균형을 맞추고, 더 나아가서는 Windows에 종속된 인터넷 뱅킹과 전자 정부 대고객 서비스의 대체 가능성을 살펴볼 수 있는 좋은 기회가 될 수 있다고 생각합니다.
연말을 목표로 리눅스 버전의 식탁보 프리뷰를 선보이도록 노력해보겠습니다. :-D
https://drive.google.com/file/d/1xapy_k4ofzyaNFPAPTF1QUYvLrz6MN55/view?usp=drive_link
보정한 결과물입니다. 19년도에 아이폰 X로 기내에서 찍었던 것 같습니다.
저는 ActivityPub 인스턴스 운영을 쉽게 해주는 프레임워크 Fedify 의 CLI 툴에 Webfinger 를 손쉽게 조회할 수 있는 fedify webfinger
커멘드를 구현했어요! https://github.com/fedify-dev/fedify/pull/278
bgl gwyng shared the below article:
프론트엔드 애플리케이션 상태를 다루는 법

ㄹ @disjukr@hackers.pub
이 글은 리액티브 프로그래밍에서 시간의 흐름에 따른 의존 그래프 관리를 설명하며, 특히 프론트엔드 상태 관리에 있어 옵저버블보다 시그널이 더 적합한 이유를 제시합니다. 저자는 프론트엔드 상태가 시간에 따라 결정적으로 변하지 않고, 노드의 의존 관계가 렌더 트리에 따라 변화무쌍하게 바뀌기 때문이라고 주장합니다. Rx, Redux, XState와 같은 기존 상태 관리 방식의 한계를 지적하며, 시그널(+ DI와 수명관리)을 중심으로 옵저버블, 리듀서, 스테이트머신을 함께 사용하는 것이 각 기술의 장점을 극대화할 수 있다고 설명합니다. 애니메이션, 폼 관리, NPC 인공지능과 같이 특정 상황에 적합한 기술을 시그널로 묶어 전체 애플리케이션 상태를 선언적으로 관리하는 방법을 제안하며, 이를 통해 애플리케이션의 구조를 더욱 명확하고 효율적으로 만들 수 있다고 강조합니다.
Read more →안녕하세요! 현재 컴퓨터공학과 학부 2학년 재학중인 새내기입니다.
PLT, Lexer 등에 관심이 많습니다. Emulation, VM 기술 등도 관심이 많습니다. 아직 주 전공 분야를 정하진 못했지만 넓게 두루두루 좋아합니다.
올드 레트로 기술들 또한 좋아합니다.
Go와 .NET 언어 일부를 주력으로 삼고 있으며 F# 을 학습하려고 공부 중입니다.
현재는 취미와 흥미 위주의 프로젝트를 주로 진행 중입니다. 감사합니다!
내일 튜사 나오시는분 있나요?
아직 저만 팔로하신 분들을 위한 끌올!!!!
한창 개발중인 다음 버전의 Hackers' Pub입니다. 프런트엔드를 전면 개편하고 있습니다. 프레임워크도 Fresh에서 SolidStart로 아예 바꿨습니다.
@lionhairdino
@bglbgl gwyng 칭따오인거죠...?? 경북 청도 출신 어리둥절..
@kodingwarriorJaeyeol Lee
@lionhairdino ㅋㅋ칭따오 맞습니다
청도 놀러 가신 분 사진으로 염장 지를 때가 지났는데, 소식이 없네요. @bglbgl gwyng
@lionhairdino 칭따오 5.4 광장 야경입니다. 낼 귀국하는데 아쉽네용.
Hackers' Pub 400명 돌파!
오늘부터 사흘간 중국 칭따오여행합니다
거의 느낌이 더 좋다는 이유만으로 rootless컨테이너를 시도했고, 이후에는 갈아엎기 귀찮다는 이유로 계속 써왔다. uid를 외부랑 일치 시키면 이미지가 권한 관련 문제를 일으키기도 하고, 자동으로 이미지내 파일 소유를 바꿔주는 기능은 첫 실행 시 너무 느리기나 하고... 자동 재시작은 systemd랑 엮어서 쓸 수 있다고 알고 있기는 한데 어쨌든 별도의 시스템이라 아직도 안쓰고 있다. 아마 별 일 없으면 계속 이렇게 쓰겠지...?
@bglbgl gwyng 농담 아니고 그렇게까지 느끼는 수준이면 애드빌같은 NSAID류의 소염진통제를 복용하는 방법이 있습니다. 위장 나빠지니까 습관성이 되는 것은 조심하시구요.
@jhhuhJi-Haeng Huh 오... 혹시모르니 구비해놓는게 좋겠네요
Nix 디버깅은 육체적으로 힘들다. 퇴근할따되면 등이 찌뿌둥함.
SteamOS 의 일종인 Bazzite 설치.
- 내가 하는 대부분의 게임이 잘 된다.
- 리눅스 데스크탑이 윈도보다 반응성 빠르고 편의성도 좋다.
- 안 되는 게임 https://www.protondb.com/app/2507950 안 되는 것들은 멀티 게임들. 안티 치트 등, 드라이버를 통해 치팅 검사하는 프로그램이 들어가는 것들이 안되는 모양.
애초에 윈도 아닌 게임이 의외로 많이 나오고 있고(Crusader Kings 3, Factorio) 직장이 아니면 집에서 윈도 안 쓴지도 몇 년 되었고, Debian, Arch Linux, OS X 만 쓰고 있다.
bazzite 는 Fedora CoreOS 기반인 모양인데 알게 된지 며칠 안 되어서 패키지 관리가 어떻게 되는 것인지 잘 모르겠다. neovim 설치는 일단 brew 로 하면 되는 모양인데, 다른 소프트웨어들은 flatpak 으로 설치하고 있고...
1년 반 만에 글을 썼다. 웹이 복잡해진 과정을 간략히 되돌아보고, 웹을 지탱해온 하이퍼미디어라는 개념이 얼마나 강력한 힘을 가졌는지 짚어보았다. https://parksb.github.io/article/43.html
- 파도처럼 출렁이는 연합우주의 분산 네트워크를 통해
- 이제는 파이콘 한국 2025 행사에서 다 같이 처음 만나
- 콘서트보다 더 뜨거운 분위기를 기대하겠습니다!
@iamuhun김무훈
@hongminhee洪 民憙 (Hong Minhee) 개인적으로 이게 장원급제네요
bgl gwyng shared the below article:
Upyo 0.2.0 Release Notes

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Upyo 0.2.0 has been released, introducing new features to this cross-runtime email library that supports Node.js, Deno, Bun, and edge functions. The latest version expands its capabilities with Amazon SES transport support, enabling AWS Signature v4 authentication and session-based authentication. Additionally, comprehensive OpenTelemetry integration has been added, offering distributed tracing, metrics collection, and error classification without altering existing code. The OpenTelemetry transport automatically instruments email operations, tracking delivery rates and latency, and integrates with existing OpenTelemetry infrastructure. Community feedback is encouraged to further improve Upyo, whether through testing the new Amazon SES transport, implementing OpenTelemetry, or contributing to the GitHub repository. This release enhances Upyo's utility by providing more transport options and robust observability features, making it a valuable tool for developers needing reliable email sending across various environments.
Read more →(CLI 툴을 쓰다 느낀건데), UX 이슈 중에 no-op과 관련된 것이 특히 까다로운것 같다. 예를들어 유저가 뭔가를 했는데 에러나서 안되면 에러 메시지로 다른 사람에게 물어볼수 있다. 근데 예상한 동작이나 변경이 안 일어났을 경우엔 그게 불가능하다. 어떤 설정을 하는걸 빼먹어서 그렇게 된 경우엔, 운좋게 다른 사람들도 자주 겪는 문제라서 쉽게 답을 찾는 경우가 아니라면, 결국엔 문서를 읽으며 내가 하려는 동작엔 어떤 설정이 요구된다는 사실을 알아내야하는데, 이러면 문서를 사실상 통독하게 된다.
내가 개발자로써 딱히 내세울 커리어는 없지만, 그래도 일평생 XCode 개발에 전혀 기여하지 않았다는 점에서는 자긍심을 느낀다.
그동안 짬짬히 테스트 기능을 만들고 있었는데 얼추 돌아간다
bgl gwyng shared the below article:
퍼즐: 1번 칸에 말 올려! 2번 칸에서 말 내려!

Bubbler @bubbler@hackers.pub
이 글은 1부터 20까지 번호가 매겨진 게임판에서 특정 규칙에 따라 말을 움직여 모든 칸에 말을 채우는 퍼즐 문제를 소개합니다. 핵심은 $k$번 칸에 말을 올리기 위해 필요한 최소 동작 횟수가 $2^{k-1}$임을 밝히는 것입니다. 이를 통해 20번 칸까지 말을 채우는 데 필요한 총 동작 횟수를 계산하는 방법을 설명합니다. 이 퍼즐은 BOJ 29225 문제에서 아이디어를 얻었으며, 문제 해결 과정에서 발견되는 패턴과 논리적 추론이 흥미로운 인사이트를 제공합니다.
Read more →Ji-Haeng Huh replied to the below article:
하스켈 편지

박준규 @curry@hackers.pub
이메일 교환을 요약하면, 한국의 취미 프로그래머 박준규 님이 Haskell에 대한 관심을 표현하며 NRAO의 다니엘 님에게 연락을 시작합니다. 다니엘 님은 Haskell 경험과 NRAO에서의 Haskell 프로젝트(antioch)를 공유하며, 박준규 님의 Haskell 학습 경험과 프로젝트에 대한 질문을 던집니다. 박준규 님은 자신이 관리하는 Hackage 패키지와 Protohackers 문제 풀이 경험을 공유하고, 다니엘 님은 이에 대한 격려와 함께 Typeclassopedia와 free monad를 추천합니다. 이 대화는 Haskell에 대한 열정과 지식을 공유하며, 서로에게 영감을 주는 긍정적인 교류를 보여줍니다. 다니엘 님은 박준규 님에게 Haskell 관련 질문을 언제든지 환영하며, 이 대화를 자유롭게 공유해도 좋다고 허락합니다.
Read more →@curry박준규 정말 귀한 글 올려주셔서 감사합니다.
저 역시 사람들에게 마지막 답장에 언급된 typeclassopedia를 가장 많이 추천합니다. 많은 분들이 하스켈 입문 후 당장의 코딩 경험을 쌓기보다 "모나드는 부리또다"로 대표되는 하스켈 튜토리얼류에 집착적으로 빠져들며 학습의 발란스를 깨는 경향이 보입니다. 무엇에 기인하는 현상인지 아직 확실히 파악은 못했지만 분명 안타까운 상황인 거 같아요.
물론 typeclassopedia도 튜토리얼 문서의 일종이지만 저자만의 특수한 깨달음 포인트가 아닌 정공법으로 설명해주다 보니, "저자의 창의적인 비유와 설명" -> "이제야 알 것 같은 독자" -> "그렇게 생긴 깨달음이 실제 코딩에 도움이 안됨" -> "새로운 문서를 찾아 헤맴" 의 끝없는 반복을 부숴줄 힘이 있는 것 같습니다.
평소에 이펙트 시스템의 필요성을 때가 비동기 코드 테스트할때 인듯. 특히 setTimeout
등 실제로 현실 시간만큼 기다리는 코드가 섞여있을때 이펙트 시스템이 없으면 테스트에서도 실제로 그만큼의 시간을 기다려야한다. 그러다보니 안 짜게 되고...
@xiniha Bunja에 비슷한 로직이 포함되어 있을거 같아요. 다른걸 만드는데 좀더 작은 라이브러리가 필요해서 따로 만들었어요. 근데 Bunja에서 deferred cleanup이 가능한가요?
@xiniha 근데 공개하고나니 바로 좀더 나은 디자인이 생각나는군요ㅋㅋㅋㅋ 패키지 이름이 구린 이유도 디자인이 구려서였고..
@bglbgl gwyng 뭔가 Bunja 생각이....
@xiniha Bunja에 비슷한 로직이 포함되어 있을거 같아요. 다른걸 만드는데 좀더 작은 라이브러리가 필요해서 따로 만들었어요. 근데 Bunja에서 deferred cleanup이 가능한가요?
https://github.com/bglgwyng/deferred-cleanup-resource-map 이런 라이브러리를 만들었다. ref counting 해서 GC 해주는 map인데, 해제를 임의로 늦출수 있다. LRU 캐시같은걸 일반화한 형태라고 보면 된다.
이름이 참 저질인데, 나도 upyo같은 센스있는 이름을 붙이고 싶었지만, 이게 클로드랑 머리맞대서 나온 최선이다;;
@bglbgl gwyng 그런 부분도 있고, 코드의 수명도 더 짧다는 인식이 있어서 그런 것도 있는 것 같아요.
@hongminhee洪 民憙 (Hong Minhee) 위에 제가 한 얘기를 약간 다르게 말하는 방법이 생각났는데, 우리가 쓰고있는 언어가 라이브러리 만드는 작업까진 좋은 언어지만 앱개발 작업에는 아직 구린 언어일수 있어요
@bglbgl gwyng
@kodingwarriorJaeyeol Lee React Native라는 이름의 게임…
@hongminhee洪 民憙 (Hong Minhee)
@kodingwarriorJaeyeol Lee 그렇게라도 생각하면서 견디겠습니다ㅋㅋ
와.... Windows 환경 지원을 위해서 피시방에서 개발한다는 발상은 생각도 못해봤는데...
피시방도 Windows 지원되는 PaaS 점포다 <<<<<
@kodingwarriorJaeyeol Lee 사실 저한텐 요즘 튜링의 사과가 게임 못하는 피시방 정도로 인식되어가고 있습니다. 혹시 해도 되나?
쌀집 앞에 참새가 많아 공유합니다. 좋은 하루 되세요!
사실 애플리케이션 만드는 것보다 라이브러리 만드는 게 훨씬 재밌다. 왜 그런지는 잘 모르겠음… 아마도 UI 개발에 약해서?
@hongminhee洪 民憙 (Hong Minhee) 애플리케이션 코드에는 아직 충분히 형식화하지 못한 문제들을 어영부영 해결하는 코드가 들어가서 그런거 아닐까요. 가령 최근데 Relay가 알아서 reactivity를 부여하지 못하는 부분에 대해서(Relay만의 문젠 아니지만) 땜빵으로 refresh 코드를 몇군데 넣어줘야 하더라고요.
사실 애플리케이션 만드는 것보다 라이브러리 만드는 게 훨씬 재밌다. 왜 그런지는 잘 모르겠음… 아마도 UI 개발에 약해서?