안녕하세요? Hackers' Pub에 첫 게시글을 올립니다. 간략한 소개를 위한 사이트를 만들었습니다. 잘 부탁드립니다!
Ji-Haeng Huh
@jhhuh@hackers.pub · 23 following · 17 followers
i am the one who knocks
github- @jhhuh
@leetekwooteklee 포트폴리오 페이지가 인상적이네요. 환영합니다.
Ji-Haeng Huh replied to the below article:
데이터 효율성으로 본 AI와 인간의 비교
bgl gwyng @bgl@hackers.pub
이 글은 AI와 인간의 능력 비교에서 데이터 효율성의 중요성을 강조하며 시작합니다. 현재 AI는 인간에 비해 데이터 효율성이 떨어지지만, 일단 학습된 능력은 복제 가능하다는 점을 지적하며 콜센터 직원과 같은 직업군에 대한 위협은 여전하다고 설명합니다. 데이터 효율성이 중요한 경영인과 연구자는 AI를 유용한 도구로 활용할 수 있지만, 인간의 데이터 효율성이 정말 높은지에 대한 의문을 제기합니다. Yann Lecun의 주장을 인용하여 인간이 받아들이는 데이터 양이 AI 학습에 쓰이는 양보다 적지 않음을 언급하며, 인간은 데이터를 있는 그대로 학습하지 않고 편향에 기반하여 학습한다는 흥미로운 주장을 제시합니다. 마지막으로, AI에게 인간처럼 무모한 결론을 내리도록 가르치는 것이 옳은지에 대한 질문을 던지며, 압도적인 양의 데이터를 통해 더 많은 진실을 알아낼 수 있는지에 대한 고민으로 마무리합니다. 이 글은 AI 개발 방향에 대한 새로운 시각을 제시하며 독자에게 깊은 생각거리를 제공합니다.
Read more →@bglbgl gwyng 인류 지성사에 무언가 큰 브레이크스루를 내는 사람들의 공통점 중에 그런 기질적인 편향 집착이 있는 거 같아요. 뛰어난 사고 능력 자체도 역할을 했겠지만 그건 어쩌면 저런 기질적 위험성을 안고도 일정 나이 이상까지 (직업적으로나 생물학적으로) 생존할 수 있게 해서 그 결과를 세상에 내놓게 하는 보조적인 수단 아닌가 하는 생각도 듭니다. 아직 설득할 근거는 부족한데 본인은 밑도 끝도 없이 확신을 갖고 적어도 10년 이상을 밀어 부쳐야만 그 결과가 나오는 것들이 있잖아요.
그럼 이게 개체 단위에서 경쟁력있는 학습 모델인가 하면 당연히 그렇지 않다고 생각합니다. 하지만 인류 전체를 하나의 앙상블 학습 기계로 생각한다면 꽤나 괜찮게 작동하는 방식이라고 생각합니다. 이름을 붙여보자면 불나방떼 학습법 ?!
@jhhuhJi-Haeng Huh 흠 그런 문제를 생각 못했네요. lazyness를 구현하기 위해서 어차피 __getattr__ 이런거 남용해가며 마개조할 필욘 있다곤 생각했습니다.
@bglbgl gwyng 저는 자다말고 생각나서 callPackage 패턴을 쓰려면 메타클래스를 작성해야겠다고 결론내리고 잠들었습니다.
이름은 생각해보셨어요?pyx? 이건 무슨 확장자같네요. ㅎ
Nix 언어를 새로 만들지말고 그냥 Python DSL 같은걸 썼으면 어땠을까 종종 생각한다. 그 세계선에선 또 그 Python DSL 욕을 주구장창 하고 있겠지만, 적어도 생태계는 더 커지지않았을까. 남바완 Linux 배포판이 됐을 수도 있다.
@bglbgl gwyng 갑자기 궁금해졌는데.. 파이썬 런타임은 매우 많은 attribute를 갖는 오브젝트를 핸들하는데 제한이 없을까요? 예를 들면 수천-수만개?
꼿꼿한 자세에 모니터(32인치, 모니터암 사용중)를 눈높이까지 올려 보는게 대부분 추천 자세로 알고 있는데요. 이렇게 맞춰 놓으면, 항상 몸이 의자에서 흘러내려, 높은 모니터를 보려면 눈을 치켜 뜨면서 보게 되는 안 좋은 습관이 생겨 버렸습니다. 남들한테 다 좋아도, 저한테는 안좋은 건가 봅니다. 그래서, 권장되는 모니터 셋팅을 과감히 무시하고, 가장 낮춰서 썼습니다. 그랬더니, 이 번엔 아래 쪽을 볼 때 불편함이 생겼습니다. 까다롭지요.
그런데, 우연히 노트북 모니터마냥 비스듬히 눕혀 놓고 2~3주째 사용 중인데, 이 거 편합니다. 32인치에 기계식 키보드 달린 노트북 느낌 납니다.
@lionhairdino 아무리 안정적인 자세라도 오래 유지하는게 안좋다고 합니다. 스탠딩 데스크나 짐볼, 안장의자 같은 게 추천되는 이유가 한가지 자세로 지속적으로 사용하기 힘들기 때문이라네요. (근본적으로 일하는 시간 자체를 줄여야...)
예전에 공덕동 창업지원센터에서, 여행용 캐리어에 데스크탑과 일반 모니터를 모두 "캐리"해서 다니시는 분을 봤습니다. 은근, 32인치 노트북이 수요가 있을지도 모릅니다.
@lionhairdino 32인치면 무릎에 올리기엔 무거울 거라서 아마 랩탑이 아니라 "포터블 데스크탑"으로 분류될 거예요 ㅎ 예전에 잠시 오피스를 공유하던 친구가 시력이 많이 안좋았는데 (거의 실명에 가까운 수준) 그런 물건을 들고 다니더군요.
LLM이 자꾸 환각을 일으킨다? 혹시 우리 인류가 마땅히 있어야할 함수를 미리 구현해 놓지 않은 잘못은 없는지, 우리가 만든 언어들의 문법이 그 분의 큰 뜻을 담기에는 너무 편협하게 설계된 건 아니었는지 지금이라도 한번 돌이켜 보자.
Ji-Haeng Huh shared the below article:
논리와 메모리 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 2 편)
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 "논리적"이 되는 두 번째 방법인 논건 대수를 재조명하며, 특히 컴퓨터 공학적 해석에 초점을 맞춥니다. 기존 논건 대수의 한계를 극복하기 위해, 컷 규칙을 적극 활용하는 반(半)공리적 논건 대수(SAX)를 소개합니다. SAX는 추론 규칙의 절반을 공리로 대체하여, 메모리 주소와 접근자를 활용한 저수준 자료 표현과의 커리-하워드 대응을 가능하게 합니다. 글에서는 랜드(∧)와 로어(∨)를 "양의 방법", 임플리케이션(→)을 "음의 방법"으로 구분하고, 각 논리 연산에 대한 메모리 구조와 연산 방식을 상세히 설명합니다. 특히, init 규칙은 메모리 복사, cut 규칙은 메모리 할당과 초기화에 대응됨을 보여줍니다. 이러한 SAX의 컴퓨터 공학적 해석은 함수형 언어의 저수준 컴파일에 응용될 수 있으며, 논리와 컴퓨터 공학의 연결고리를 더욱 강화합니다. 프랭크 페닝 교수의 연구를 바탕으로 한 SAX는 현재도 활발히 연구 중인 체계로, ML 계열 언어 컴파일러 개발에도 기여할 수 있을 것으로 기대됩니다.
Read more →자연 연역의 E/I 룰에서는 항상 가정의 목록이 유지되거나 줄어들어 "가정의 소비(?)"된 정도를 기준으로 증명을 순차적으로 구성하거나 파악하는게 유리한 대신 전건과 후건을 다루는데 있어서 그 대칭성이 보이지 않는다. 대신 이와 동등한 논건대수에서는 추론 규칙에 전건과 후건 사이의 대칭성을 명백히 드러냄으로써 추론 시스템 자체의 특정 구조적인 성질을 이해하는데 유리할 수 있다.
- 증명을 위에서 아래로 읽으면 자연 연역의 경우 가정이 줄어들기만 하는 것이 맞습니다. 다만 프로그램적인 측면에서는 아래에서 위로 (가정이 늘어나는 방향으로) 읽는 것이 더 자연스러운데요, 이는 가정이 늘어나는 것이 프로그램에서 깊은 스코프(scope)로 들어갈 수록 더 많은 변수를 소개하는 것과 같은 개념이기 때문입니다.
- "증명을 순차적으로 구성하기 쉽다"는 사실 약간 애매하기는 합니다. 둘 다에 익숙해지면 논건 대수의 증명이 (기계적으로 찾기에) 더 쉽기 때문에요. 실제로 증명 검색 알고리즘(proof search algorithm, 어떤 판단을 증명하는 증명을 찾는 알고리즘)도 논건 대수에 기반하는 경우가 더 많습니다. 다만 이미 만들어진 증명을 "파악"(혹은 이해)하는 데에 있어서는 (프로그래머로서는) 자연 연역의 함수형 프로그램스러운 증명이 훨씬 쉽지요.
- "대칭성"과 관련한 관찰은 논건 대수의 발전에 있어서 핵심이라고 볼 수 있습니다. 뛰어난 직관을 가지고 계시네요.
@ailrunAilrun (UTC-5/-4) "뛰어난 직관"이라고 말씀해주셔서 감사합니다. (칭찬만 걸러듣는 성향 ㅎ) 근데 직관이라기 보단 원글에서 보여주신 "가정없이는 거짓을 증명하지 못한다"의 네줄짜리 증명의 배경 아이디어를 보고 떠오른 습관적인 "논리적 비약"이었던 거 같아요.
자연연역이 (인간에게 있어서) 프로그램으로 표현하기 좋은 어떤 구조적인 이유가 있지않을까 생각해보다가 제가 뭔가를 억지로 끼워 맞춘거 같네요. 논리적 사고를 더 훈련해야겠습니다. :)
@bglbgl gwyng "온 세상이 nix다"
Ji-Haeng Huh replied to the below article:
논리적이 되는 두 가지 방법 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 1 편)
Ailrun (UTC-5/-4) @ailrun@hackers.pub
이 글은 어떤 문장이 "논리적"이라고 할 수 있는지에 대한 심도 있는 탐구를 시작합니다. 일상적인 오용을 지적하며, 진정으로 논리적인 주장은 증명 가능성과 체계의 무모순성이라는 두 가지 핵심 조건을 충족해야 한다고 주장합니다. 특히, "좋은 가정 아래" 논리성을 증명하는 두 가지 방법, 즉 함수형 언어와 유사한 구조를 가진 자연 연역과, 약간의 "부정행위"를 통해 무모순성을 쉽게 보일 수 있는 논건 대수를 소개합니다. 글에서는 명제와 판단의 개념을 명확히 정의하고, 자연 연역을 통해 논리적 증명을 구축하는 방법을 상세히 설명합니다. 특히, 자연 연역과 함수형 언어 간의 놀라운 유사성, 즉 커리-하워드 대응을 통해 논리적 사고와 프로그래밍 언어 이해 사이의 연결고리를 제시합니다. 또한, 자연 연역의 한계를 극복하고 무모순성을 보다 쉽게 증명할 수 있는 논건 대수를 소개하며, 자연 연역과의 구조적 차이점을 강조합니다. 이 글은 논리적 사고의 깊이를 더하고, 프로그래밍 언어와 논리 간의 관계에 대한 흥미로운 통찰을 제공합니다. 특히, 커리-하워드 대응을 통해 논리와 프로그래밍이 어떻게 연결되는지 이해하고 싶은 독자에게 유익할 것입니다.
Read more →@ailrunAilrun (UTC-5/-4) 정말 좋은 글 정말 감사합니다. 아직도 CS관련 글을 보다가 가로로 긴 직선만 나오면 "이거 내가 읽어도 되나?" 싶은 생각이 들면서 읽기를 포기하곤 하는데 기초적인 부분부터 너무 잘 설명해주셔서 끝까지 읽을 수 있었습니다. (사실 두번 읽었습니다.)
자연 연역의 E/I 룰에서는 항상 가정의 목록이 유지되거나 줄어들어 "가정의 소비(?)"된 정도를 기준으로 증명을 순차적으로 구성하거나 파악하는게 유리한 대신 전건과 후건을 다루는데 있어서 그 대칭성이 보이지 않는다. 대신 이와 동등한 논건대수에서는 추론 규칙에 전건과 후건 사이의 대칭성을 명백히 드러냄으로써 추론 시스템 자체의 특정 구조적인 성질을 이해하는데 유리할 수 있다.
라는 생각이 들었는데 이게 올바른 관찰일까요?
"이 내용들이 2 편에서 다룰 본격적인 논리와 자료 표현의 관계에 대해 흥미를 불러일으켰기를 바라며" -> 2편 정말 기대됩니다. ㅎ
에디터의 플러그인도 Nix로 관리하고 싶다. 에디터 쪽에서 지원을 해야하는데, 누군가 총대매고 해줄법도 한데...
@bglbgl gwyng vscode 쓰시죠? 예전 기억을 더듬어보면nix-ld만 잘 설정해서 필요하면 extension들을 ad-hoc하게 깔아서 쓰는덴 큰 문제가 없었습니다. (제 경험상 vscode-fhs는 비추합니다) 저는 그러다 한번씩 pkgs/applications/editors/vscode/extensions/update_installed_exts.sh 스크립트를 이용해서 깔려있는 extension들을 nix-expression으로 뽑아서 vscode-with-extensions로 다시 빌드하곤 했습니다.
@bglbgl gwyng 제가 항상 스토리지로 고생해서 이번에는 그냥 통 크게 2TB로 질렀습니다. Haskell, Rust 프로젝트 같은 것들은 의존성 조금만 생겨도 빌드 디렉터리가 스토리지 많이 차지하더라고요.
@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng "Storage is cheap!!!"
논리와 low-level data representation을 다뤄볼지, 아니면 함수형 추상 기계들(Turing Machine같은 것이지만 함수형을 위한 것들)을 다뤄볼지
@ailrunAilrun (UTC-5/-4) 앗! 저는 논리와 low-level representation에 한표입니다.
친구가 외국 반도체회사에 다니는데 이름만 들으면 다 아는 세계에서 손꼽히는 회사다. 1년 전쯤에, 친구가 자기 팀에서 예전부터 쓰고있는 시뮬레이션 코드가 너무 복잡해서 리팩토링 하고 싶다고 나를 찾아왔다. 한 2, 3000줄 되는 Numpy 코드였다.
나는 시뮬레이션의 의미 자체는 전혀 이해를 못하니(이래서 보안문제도 익스큐즈 할수 있었을 것이다), 그냥 코드의 모양만 보고 이상한 부분을 조금씩 고쳐나갔다. 그... 전형적인 물리학자들의 실험실 코드였다(코드를 못짜는건 이해를 하는데, 거기에 대해 한치의 부끄러움도 느끼지 않는다는 점이 뒷목을 잡게 만든다). Numpy 함수도 제대로 활용을 못해놨길래, 나도 Numpy 잘 못쓰지만 대충 이런 함수가 아마 있겠지... 하고 검색해서 찾아내서 교체하고 이런걸 반복했다.
이것저것 고친 다음에 잘돌아가나 한번 실행을 해봤는데, 이럴수가. 시뮬레이션이 1000배 빨라졌다. 아니 뭐, 한 2배 3배 빨라졌으면 내 솜씨라고 자부할텐데, 1000배 빨라진거는 그냥 원래 코드가 똥통이었다고 해석할수 밖에 없다. 구라안치고 정말 1000배다. 1000배의 성능향상의 보답으로 나는 교촌치킨웨지콤보세트를 현장에서 받아먹었다.
그 이후에 어떤 일이 있었냐. 기존 시뮬레이션 코드로는 하루에 시뮬레이션을 2, 3번정도밖에 돌리지 못했는데, 1000배 빨라지고 나니까 결과가 수십초만에 나오니 하루에 수백번 돌릴수 있게 된것이다(내가 고친 코드가 전부는 아니어서 1000배 향상은 아닌데, 가장 큰 병목이긴 해서 결국 100배 이상이라는 듯). 그때부터 100배 많아진 데이터를 처리하기 위한 인프라가 필요해졌다. 그래서 거기 개발팀이 데이터베이스와 데이터 파이프라인 구축을 시작하게 되었다고 한다. 그 팀에서는 일종의 특이점이 시작된것이다;;
결론: 교촌치킨웨지콤보 세트는 개맛있었다.
@bglbgl gwyng 1000x programmer !!!
https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6#superclass-expansion-is-more-conservative
내가 9.4 -> 9.6 마이그레이션에서 겪고 있는 문제가 이거랑 관련이 있는거 같은데(확실치 않음)... 9.4에서는 c :: Type -> Constraint 일때 forall c. c Int 뭐 이런 조건이 있으면, 모든 c에 대해 c Int가 존재하는게 말이 안되는데도 실제로 c Int 꼴로 쓰이는 c만 고려해서 타입체크를 통과시켜줬던거 같다(이것도 확실하지 않음). 근데 9.6에선 당연히 거부당한다.
위의 내 이해가 맞다면 9.4의 constraint solving 완전 무근본이었단건데, 이건 또 믿기 어렵다(하스켈의 설계 결정에 대한 신뢰 유지한다고 하면). 어디서 내가 잘못 파악한거지.
@bglbgl gwyng 말씀하신 forall c. c Int 꼴이 instance head에 등장하는 건 아닐 거고 instance context나 superclass로 들어 오는 걸 텐데 그것도 instance (forall c. c Int) => ... 꼴이 아니라 instance forall c. c Int => ...이런 꼴이면 해당 변화랑 관계가 있을 여지가 있는 것 같네요. 물론 정확한 건 코드를 봐야 알거 같지만요.
uv2nix는 uv보다 구리고, cabal2nix는 cabal보다 구린데, Nix는 uv + cabal + ... 보다 낫다. Nix 커뮤니티를 키우려면, 후자를 이해시키고(쉬움) 전자에 대해 익스큐즈하도록 설득해야한다(어려움) .
그동안 동료들한테 Cursor 쓰자고했는데 그들이 오소독스 Emacs 매니아들이란 문제가 있었다.
작년에 Nix로 nvidia gpu 지원까지 포함해서 구축해놓은 k3s 클러스터에다가, 오늘 아침에 1시간만에 aider로 쓸수있게 DeepSeek R1을 띄웠고 한번 써보자고 했다. 최근에 한 것 중 가장 가성비 좋은 작업인듯 하다.
@arkjunJuntai Park @hongminhee洪 民憙 (Hong Minhee) 시차적응 때문에 가입만 급하게 하고 이제야 들어와 보네요. 환영해 주셔서 감사합니다. 모두들 반갑습니다.