洪 民憙 (Hong Minhee)

@hongminhee@hackers.pub · 415 following · 277 followers

Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!

Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.

Fedify、Hollo、BotKit、そしてこのサイト、Hackers' Pubを作っています。

嗨，我是 Fedify、Hollo、BotKit 以及這個網站 Hackers' Pub 的開發者！

Website
hongminhee.org
GitHub
@dahlia
Hollo
@hongminhee@hollo.social
DEV
@hongminhee
velog
@hongminhee
Qiita
@hongminhee
Zenn
@hongminhee
Matrix
@hongminhee:matrix.org
X
@hongminhee
0
0
0
0
1
0
0
0
0
0
0
0
Woojin Kim @me@hollo.woojinkim.org
Public
Shared by 洪 民憙 (Hong Minhee)

어제 타임라인에서 맥미니 서버로 어느정도 규모까지 버틸 수 있을지에 대한 고민이 지나가는걸 봤는데 1월부터 신형 맥미니로 이것저것 운영해본 경험 안에서는 오히려 문제는 서버 기계가 아니라 가정용 전원과 가정용 인터넷에서 터질 것 같다.

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

소프트웨어 개발자들이 자주 틀리는 외래어 표기법.

영어 틀린 표기 올바른 표기
app 어플 앱
application 어플리케이션 애플리케이션
directory 디렉토리 디렉터리
front-end 프론트엔드 프런트엔드
message 메세지 메시지
method 메소드 메서드
release 릴리즈 릴리스
repository 레포지토리 리포지터리

또 있을까요?

0
0
0
0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

<Tracing the thoughts of a large language model>

LLM이 어떻게 생각하는지 추적하는 연구인데 아주 흥미롭다. LLM이 단순히 바로 다음에 올 높은 확률의 단어를 선택할 것이라고 생각했지만, 실제로는 미리 단어를 계획한 다음에 문장을 완성했다고. 다국어 구사와 암산 부분도 재미있다. 인간이 생각하는 방식과 크게 다르지 않은 것 같은데 기계가 정말 생각을 못한다고 할 수 있을까...

anthropic.com/research/tracing

A hand-drawn image where a black square overlaps with a white circle, revealing nodes and connections inside the circle, some of which are highlighted

Tracing the thoughts of a large language model

Anthropic's latest interpretability research: a new microscope to understand Claude's internal mechanisms

www.anthropic.com

1
0
0
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public
Shared by 洪 民憙 (Hong Minhee)

GN⁺: 대형 언어 모델의 사고 과정을 추적하기
------------------------------
- Claude 같은 언어 모델은 사람이 직접 프로그램한 것이 아니라 방대한 데이터로 학습됨
- 학습 과정에서 문제 해결 전략을 스스로 학습하며, 이 전략은 수십억 개의 연산에 암호화되어 있음
- 결과적으로 모델 개발자조차도 Claude가 대부분의 작업을 어떻게 수행하는지 완전히 이해하지 못함
- Claude 같은 모…
------------------------------
https://news.hada.io/topic?id=20002&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

대형 언어 모델의 사고 과정을 추적하기 | GeekNews

Claude 같은 언어 모델은 사람이 직접 프로그램한 것이 아니라 방대한 데이터로 학습됨학습 과정에서 문제 해결 전략을 스스로 학습하며, 이 전략은 수십억 개의 연산에 암호화되어 있음결과적으로 모델 개발자조차도 Claude가 대부분의 작업을 어떻게 수행하는지 완전히 이해하지 못함Claude 같은 모델이 "무엇을 생각하는가"를 이해하면 모델의 능력을 더 잘

news.hada.io · GeekNews

0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

better CSS에 대한 접근들(CSS-in-JS, Atomic CSS, Preprocessor)의 공통된 한계는 constraint solving 방식이 아니란 것이다.

다들 어떤 기존의 스타일을 '덮어쓰는' 방법, 근데 개중에 좀 잘 덮어쓰는 방법을 찾고 있다. 그런데 많은 경우, 뭔가를 덮어쓰려고 하고 있다면, 그건 사실 값을 덮어쓰는게 아니고 만족해야할 조건을 추가하고 싶은거다. 값을 덮어쓰는 것은 조건을 추가하는 방법 중 가장 강제적인 하나의 방법일 뿐이고. 즉, 디자인 시스템은 어떤 조건들의 합들로부터 실제 스타일을 구하는 방법이어야 하고, 개발자는 조건만 명시할 수 있어야 한다.

constraint solving을 잘 설계하고 구현하는게 어렵다 왜 이렇게 안 하냐고 하긴 좀 거시기하다. 그래서 나도 요즘 propagator를 공부중이다.

0
2
0
Cojette @cojette@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

데이터에서 인과 관계를 아예 찾을 수 없냐면, 그렇지는 않습니다. 그 과정이 생각보다 조금 더 단계가 많을 뿐입니다. 인과 분석에 있어서, 인과 구조가 단순히 ‘뭐가 바뀌면 뭐가 바뀐다‘ 이상으로 다양하고, 어떤 식으로 다양할 수 있는지를 이해해야 인과 관계를 가정하고 조건적 사고를 진행할 수 있을 것입니다. 이를 고려하지 않고 너무 인과관계를 단순하게 보다보니 잘못된 내용을 호도하거나 아예 배제하는 경우가 종종 눈에 띄어 아쉽습니다. 관련하여 인과 관계 구조를 구분하고 각각의 분석법을 훑어볼 수 있게 정리해 보았습니다. https://cojette.github.io/posts/structureofcausation/

인과 관계의 다양한 구조와 분석 방안

현실에서 나타나는 현상은 시간에 따라 변화한 무언가를 말한다. 그리고 그런 시간에 따른 변화는 독립적으로 이루어지는 건 많지 않아, 그 변화 속에서 다양한 인과 관계가 형성된다. 그리고 사람들은 그 관계를 특정하고 싶어하고, 이를 수치적으로 풀고자 한다. 하지만 이를 풀어내는 것은 쉽지 않고 오용되는 경우가 너무나도 많아, ‘상관관계는 인과관계를 의미하지 않는다’는 말을 다들 입에 달고 살게 되었다. 하지만 여전히 이 말만 유명하고, 이 이상으로 나아가지 않는다. 심지어 이를 이상하게 해석한 후 마치 진실인 양 호도하는 이야기마저도 눈에 띈다. 물론 데이터에서 인과 관계를 아예 찾을 수 없냐면, 그렇지는 않다. 그 과정이 생각보다 조금 더 단계가 많을 뿐이다.

cojette.github.io · Cojette의 Data Wonderland

0
0
0
박진우 @parkjinwoo@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

베이즈 확률론에서 사후 확률을 다룰 때 베타 분포를 가정한다. 베타 분포의 확률 밀도 함수는 다음과 같다.

f(x;α,β)=1B(α,β)⋅xα−1(1−x)β−1 f(x; \alpha, \beta) = \frac{1}{B(\alpha, \beta)} \cdot x^{\alpha-1}(1-x)^{\beta-1}

여기서 B(α,β)는 베타 함수이며 다음과 같이 정의된다.

B(α,β)=Γ(α)Γ(β)Γ(α+β) \mathrm{B}(\alpha,\beta) = \frac{\Gamma(\alpha)\Gamma(\beta)}{\Gamma(\alpha+\beta)}
0
1
0
0
1
0
0
0
0
정진명 @jjme@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

해커스펍 계정을 만들었습니다. 권유와 초청 주신 분들 감사합니다.

저는 게임 기획자로 일하고 있습니다만, 요즘 몇년은 js/react로 제품에 들어갈 코드를 짜는 일이 많습니다. 최근에는 https://guji.jjme.me/ 에서 블로그를 쓰는 데 많은 에너지를 쓰고 있습니다.

정진명의 굳이 써서 남기는 생각

정진명의 굳이 써서 남기는 생각은 잊지 않기 위해 쓰고, 읽기 위해 쓰는 개인 블로그입니다. 책, 게임, 티셔츠, 그 외 이것저것에 대한 생각이 올라옵니다.

guji.jjme.me · 정진명의 굳이 써서 남기는 생각

0
2
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
OpenTelemetry @opentelemetry@fosstodon.org
Public
Shared by 洪 民憙 (Hong Minhee)

The JavaScript SDK 2.0 is here!

opentelemetry.io/blog/2025/ote

Announcing the OpenTelemetry JavaScript SDK 2.0

Exciting news: OpenTelemetry JavaScript has released SDK 2.0! Migration guide For a detailed description of breaking changes, see the migration guide: Upgrade to OpenTelemetry JS SDK 2.x. What is JS SDK 2.x? JS SDK 2.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=2.0.0 for the stable and >=0.200.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.

opentelemetry.io · OpenTelemetry

0
0
0
0
0
0

洪 民憙 (Hong Minhee) shared the below article:

거꾸로 상태 모나드로 강화 학습 하기 (1/2)

bgl gwyng @bgl@hackers.pub

이 글은 하스켈로 강화 학습을 구현하며 겪는 기술적인 고민과 해결 과정을 다룹니다. 저자는 Hasktorch 라이브러리를 사용하여 스네이크 게임을 강화 학습으로 훈련시키는 과정을 소개하며, 데이터 없이 에이전트를 학습시키는 강화 학습의 장점을 강조합니다. 특히, 에이전트와 환경을 정의하고, 보상 함수를 설계하여 뱀이 먹이를 먹도록 유도하는 방법을 설명합니다. 글에서는 즉각적인 보상과 누적 보상의 차이를 지적하며, 감쇠율을 적용하여 미래의 보상을 현재의 선택에 반영하는 방법을 제시합니다. 또한, 순수 함수로 환경을 정의하는 것의 한계를 언급하며, 환경이 에이전트를 실행할 수 있는 모나드여야 함을 강조합니다. 저자는 이 경험을 통해 얻은 인사이트를 공유하며, 강화 학습 코드를 더 효율적으로 작성하는 방법에 대한 고민을 제시합니다. 다음 글에서는 상태 모나드를 사용하여 이러한 문제점을 해결하는 방법을 소개할 예정이며, 독자들에게 모나드에 대한 사전 학습을 권장합니다.

Read more →
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
박준규 @curry@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

해키지(Hackage)[1]에 업로드한 패키지에 하독(Haddock)[2] 문서가 보이지 않을 때 다음과 같이 하면 된다.

먼저 다음 명령어로 하독 문서를 빌드한다.

cabal haddock --haddock-for-hackage

빌드된 압축 파일을 다음 명령어에 인자로 넣어 해키지에 업로드한다.

cabal upload --documentation --publish

이렇게 하면 이미 업로드된 패키지를 버전 변경(bump up)할 필요 없이 패키지에 누락된 하독 문서만 따로 업로드할 수 있다.

  1. 하스켈 패키지 저장소 ↩︎

  2. 하스켈 코드에 적은 주석 기반으로 HTML 문서를 만들어 주는 도구 ↩︎

0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
1
0
0
0
0
0
0

洪 民憙 (Hong Minhee) shared the below article:

복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다

ㄹ @disjukr@hackers.pub

이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.

Read more →
0
0
0
0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

옛날에 만들어놓고 저 혼자는 잘쓰고 있는 React 폼 라이브러리 react-form-mozard를 소개합니다.

폼 중에서 Stepper 또는 Wizard라고 하는, 여러 개의 폼을 순차적으로 합친 형태를 다룰때 씁니다. 그래서 하나의 폼에 대해서는 react-hook-form 등 을 쓰고, 그걸 여러개 조합할땐 react-form-mozard를 활용하면 됩니다.

순차적으로 합친 에서 느낌이 오지요? 모나드가... 그대를 부릅니다...

폼 말고 CLI를 만들때를 잠깐 생각해보죠.

const name = prompt("이름이?")
const age = prompt(`{name} 님, 나이가?`)
if (Number(age) < 20) {
  console.info("미성년자는 이용할 수 없습니다")
  return
}
const gender = prompt(`{name} 님, 성별이?`)

뭐 이런 흐름을 생각해볼 수 있는데요. 보시면 먼저 받은 입력값에 따라 이후의 메시지나, 제어 흐름이 달라질 수 있습니다. 즉, 모나딕하죠. 근데 이런 평범한 로직을 Stepper/Wizard 에서 짜게되면 코드게 쉽게 더러워 지는걸 알수 있습니다.

react-form-mozard의 step은 위 예제의 prompt와 같은 역할을 합니다. 그리고 그걸 Generator 위에 얹으면 모나딕한 폼 합성이 가능해집니다.

단점이라면... 지금은 React랑 강결합 되어 있어, XState 등 다른 상태관리 라이브러리를 같이 쓴다면 연동이 깔끔하지 않을수 있습니다. 근데 평소에 쉽게 겪을 문제는 아니라고 보고, 또 추후에 설계를 수정해서 개선이 가능한 부분입니다.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

GitHub - gwyng-dev/react-form-mozard: Compose multiple forms into a single form wizard using a monadic approach.

Compose multiple forms into a single form wizard using a monadic approach. - gwyng-dev/react-form-mozard

github.com · GitHub

0
0
0
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
Simon Park @parksb@silicon.moe
Public

코틀린+스프링 백엔드 개발하다가 지금은 프론트엔드 개발하고 있다는게 다른 사람들에게 꽤 재밌는 이야기로 다가오는 것 같다. 당연히 선택의 이유에 대한 질문을 가장 많이 받는데, 가장 특이한 질문은 OOP가 그립지 않은지(?)라는 질문. (OOP도, AOP도 전혀 그립지 않다.)

Simon Park @parksb@silicon.moe
Public
Shared by 洪 民憙 (Hong Minhee)

그리고 이런 입장에서 BE vs FE 같은 대결 구도가 조금... 그렇다. 사실 업무상 관점이 좀 다를 수는 있어도, 다른 직군으로 분류할 정도로 기술적 관심사나 고민의 주제가 그렇게 까지 다른가 싶기도. 나중에 이 생각의 해상도를 좀 더 높여봐야겠다.

0
0
0