bgl gwyng

조만간 revive coding 이란 제목으로 글을 써봐야겠다

LLM 인권(?) 떡밥 보다가 든 생각인데, 대부분의 사람들이 요즘 LLM에 마음이 있는지 없는지에 이렇게까지 무관시 하다는게 신기하다. 생각해봤자 피곤하고 답도 안나오니까 그냥 생각을 일찌감치 관둔건가? 나는 옛날부터 심리철학에 관심이 많았어서 이와 관련해 생각을 많이 해왔고, 나름대로 마음이 없다는 결론을 내려서 그렇게까지 존중은 안하고 있다. 동시에 마음이 있다면 잘 대해주는게 맞다고 생각하고 그렇게 할 것이다.

위클리 미팅은 왜 매주하는걸까요? 너무 잦습니다.

오늘 가족과 함께 성당에서 하는 반려동물 축복식을 다녀왔다. 요즘 유행이라더라. 우리 강아지도 축복을 받았다. 나는 신앙이 딱히 없는데도 기분이 좋았다.

기도문 중에 우리 인간은 하느님의 창조물들을 잘 돌볼 의무가 있다 어쩌고 하는 부분이 있었다. 실제로 창세기에 하느님이 동물들을 만듬 담에 인간한테 얘들한테 이름을 짓고 돌보라는 내용이 나온다. 실제론 지구에서 유일하게 일반지능을 가진 종인 인간이 스스로에게 쓸데없이(?) 부여한 책무이다. 어찌보면 오만하다고도 볼수 있겠지만, 이 경우엔 그래도 좀 귀여운 형태인거 같다.

빨리 저런 라이센스가 제대로 잘 만들어져서 내 레포에 적용하고 싶다.

근데 그런 라이센스가 있다한들 AI 기업들이 그걸 존중할까 하는 걱정이 있는데. 한가지 긍정적인건 LLM들이 원본 데이터를 하도 잘 외워서(이게 꼭 긍정적이지만은 않다), 가령 유명한 소설 '위대한 개츠비'를 한번 읊어보라 하면 80% 정확도로 뱉더라 라던 연구가 있다. 그래서 라이센스를 어기고 학습에 사용한 코드가 있다면 검출은 쉬울지도?

모델 프로바이더 입장에서는 시스템 프롬프트에 '코드를 외웠다는 사실이 드러나지 않게하라' 같은걸 넣을수도 있겠다. 근데 또 모델이 나쁜짓을 하게 하면 딱 그지시만 따르는게 아니라 전반적으로 부작용이 생긴다는 연구가 있다(해당 연구에선 프롬프팅이 아니고 파인튜닝이었지만). 그래서 라이센스를 어기고 학습한다음 잡아떼기가 생각보다 어려운 일일수 있겠다.

그래프를 다루는 코드는 안전하게 짜기가 참 어려운데, 그렇다고 또 라이브러리화해서 재사용하기도 어려운거 같다. 둘중 하나라도 잡을 방법이 없을까? 후자에 대한 부분적인 아이디어는 있긴한데..

어떻게하면 mise 유저들을 Nix로 꼬실수있을까..

LLM한테 하나하나 뭘만들지 알려주기보다, SPEC.md 같은 파일을 만들고 거기를 수정하면 git diff를 떠서 그 변경분을 LLM이 반영하는 워크 플로우를 고민하고 있다. continuous한 AI 번역 솔루션을 생각하다보니 여기까지 왔네.

나는 CLI툴이 MCP보다 LLM에게 나은 도구라고 생각하는데, CLI 툴은 bash로 조합이 되기 때문이다. 즉 코딩이 가능하다. 디렉토리의 파일들의 각 첫 50줄을 읽는 작업은 ls, head, xargs를 조합해 한반의 호출로 가능하다. 그에 반해 MCP의 Read 툴 같은건호출을 파일 갯수만큼 해야한다.

이는 bash가 충분히 좋은 프로그래밍 언어라던가 MCP에 조합성을 추가할수가 없다는 얘기는 물론 아니다.

주말동안 Nix Flake의 워크스페이스 flakespace를 만들었는데, 구현이 너무 Hacky해서 솔직히 내가 만들어놓고도 쓸 맘이 안든다. 잡버그 고치느라 시간을 많이 버릴 걱정이든다. 일단 트라이는 해보겠다만.. Nix Flake가 자체적으로 워크스페이스 기능을 제공했으면 좋겠다.

모노레포를 쓸때 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 순으로 해야지.

LLM을 위한 cat, lat을 만들어볼까 생각이 들었다. 어떤 파일을 열던지 간에, 토큰 아끼고 LLM이 쉽게 읽도록 적당히 알아서 바꿔서 보여주는 것이다. 그리고 CLAUDE.md 같은거에 cat 대신에 쓰라고 하는거지.

처음엔 JSON 파일을 minify해서 토큰 아끼는 정도를 생각했는데, 막상 클로드한테 물어보니 자기도 들여쓰기가 있어야 읽기 편하다고 한다. 응? 그래서 쓸모있는 접근을 물어봤더니, 코드를 읽을때 앞에 함수 시그니쳐/클래스 정의 등의 요약을 달아주면 좋겠다고 한다.

쓸모있게 만드려면 좀더 고민해야할듯..

Zod가 lazy validation을 지원안하길래 대안을 찾아봤는데, 잘 알려진것중엔 Valibot의 v.lazy 뿐인것 같다

프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.

인터페이스가 구린 라이브러리를 쓸때는 반!드!시! 심호흡을 하고 멀쩡한 인터페이스의 wrapper를 만든후에! 기능 개발을 합시다. 절대 대충 꾸역꾸역 만들어보자고 덤비면 안됩니다. 결국 후회합니다.

• V모사의 AI 라이브러리를 쓰다가

갠적으로 커밋 메시지나 PR 제목 앞에, feat:, fix:, chore: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.

흑백요리사 보는데 재미는 있지만 룰이 엉성하고 개판이라 찜찜하다. PD들을 모아서 코딩 교육을 시키고 싶다.

VCS와 패키지 매니저가 통합되어야 한단 얘기를 했었는데, shadcn의 인기가 그런 방향에 대한 지지를 간접적으로 보여주고 있다. shadcn은 UI 라이브러리를 만들어봤자 어차피 고쳐쓰는 경우가 많아서 나왔다. 문제는 기존의 npm 패키지 같은 것들은 받는건 쉬운데 그다음에 고치는게 열불터지는 것이다.

1. 조건에 맞는 소스 코드를 받는 것 2. 그걸 고치는 것, 에서 패키지 매니저는 1은 잘하는데 2를 불편하게 만든다. VCS는 1을 할수있는데, 약간 번거롭게 되어있고(git submodule을 생각해보라), 2는 당연히 쉽다. VCS에서 1을 개선해야한다.

Zed는 망치가 좀 부족한가.. 심지어 성능도 좋은게 잘 체감 되지 않는데, 렌더링이 아닌 다른 곳에서(아마도 LSP와의 통신?) 구현이 구린지 랙이 빈번하다.

AI 물 사용량 떡밥의 문제는, 그 이야기를 하는 사람의 상당수가 AI의 결과물은 모조리 무가치하다는 생각을 하고있다는 것이다. 결과물의 가치가 0이라면, 뭐 물을 500ml만 써도 낭비는 낭비겠지요? AI와 관련해 해결해야할 문제가 한두개가 아닌데, 논의에 질을 높이고 고품격의 토큰이 오갔으면 좋겠다.

(아무도 관심없겠지만) 요거의 예시로는 tree-sitter의 파싱 테이블 + AST node 메타데이터 export가 있다. 지금은 파싱 테이블 대신 parser.c만 뱉고 중요한 메타데이터를 몇개 빼먹는다. 하는 김에 rewrite in haskell도 하면 더 좋고..

좀 웃긴 생각이 났는데, '해결해주면 나랑 친해질수 잇는 문제들'이란 목록을 만들어서 공유하고 싶다. 네임드가 되면 실제로 잘 동작하려나.

https://news.hada.io/topic?id=25285

추상화가 강력한 더 좋은 언어를 쓰는 것 이상의 확실한 방법이 없고, 그 외에는 그냥 임시방편이라고 생각함.

NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.

NextJS + Vercel AI SDK로 챗봇 UI 만들다가 수명이 줄겠네..

그동안 Nix 쓰면서 고통도 많이 받았는데 그래도 주변에 꾸준히 Nix를 권한다. Nix가 '빌드'라는 소프트웨어 개발의 아주 일반적인 문제를 한방에 푸는 방법론이기 때문이다. 물론 아직 몇가지 문제가 좀 있지만(잘 안된다, 불편하다 식의 단순한 문제는 아니다), 나 자신도 그 해결책을 위한 몇가지 아이디어를 가지고 있고, 머지않은 미래에 풀릴거라 생각한다.

UNIX 철학이 작은 기능을 확실하게 수행하는 프로그램들을 만들어 조합하자인데, ls, cat, grep 등이 그 예시다. 내가 볼땐 Nix도 생각도 거기에 해당된다. Nix도 좋은 의미로 의외로 꽤 작다.

Vercel AI SDK는 LLM이라는 훌륭한 기술을 주옥같은 인터페이스로 감싸놓았다. 정말 이해가 안가는 추상화 투성이다.

https://medium.com/daangn/당근의-genai-플랫폼-ee2ac8953046

으악 송년회 오늘인줄알고 헛걸음했네

요즘 개발자들 만나면 죄다 AI 얘기밖에 안하는데, 대부분 ‘동물원 가서 코끼리 봤어’ 수준의 이야기라 다 들어주기가 피곤하다. 여기서 들은 얘기 저기서 또 들어야하고.

Zed 에디터 써보는 중인데 Git 연동이 좀 부실하다. 보통은 GitKraken이나 lazygit 등의 도구를 병행해서 쓰니까, 꼭 에디터에서 Git을 빵빵하게 지원해야하냐는 의문은 든다. 다만 Git의 특정 기능들은 에디터 연동이 불가피한데(diff 보기, conflict 해결하기 등), 이런거보면 에디터가 Git의 인터페이스가 되어야하는거 같기도하고 그렇다.

Nushell 반나절동안 썼는데, 지금까지 문제는... 그 리치한 기능을 전혀 안 썼다는것이다. 그래서 단지 zsh와 비교해 익숙하지않음+플러그인부족에서 기인한 불편함만 체험하고 말았다.

primes :: (Integral a) => [a]
primes = 2 : ([3, 5 ..] & filter (not . has_divisor))
 where
  has_divisor n =
    any ((0 ==) . (n `mod`) . fst) $ takeWhile ((n >=) . snd) primes_with_square
  primes_with_square :: (Integral a) => [(a, a)]
  primes_with_square = [(p, p * p) | p <- primes]

euler project 문제 풀다가..

리액트의 dumb component는 이름과달리 약간은 더 똑똑할 필요가 있는데. dumb component는 업데이트를 반드시 부모를 통해서만 해야한다. 이때 fine-grained reactivity로 성능을 높이려면 (딱히 별 하는 일도 없는) wrapper가 필요하다. 그리고 데이터 페칭과 관련될 경우 또 wrapper를 반드시 만들어 줘야한다.

이걸 어떻게 해결할수 있나? dumb component가 Props로 raw value가 아닌 signal을 받게하는 것이다. 아쉽게도 현재 JS에 표준 Signal 인터페이스가 없기에 jotai atom 등을 써야하는데, 그러면 컴포넌트가 프레임워크에 의존하게 되어 덜 dumb해지는 문제가 있다.

어쩌다 커서, 윈드서프 대신에 오리지널 VS Code + 코파일럿을 쓰고 있는데, AI의 UX 통합이랑 측면에선 이쪽이 더 낫네? 윈드서프는 채팅 UI 벗어나면 잡버그때문에 못쓸 수준이다.

Vercel 제품들은 딱 봐도 설계가 너무 구리게 느껴지는데, 그렇다고 깊게 생각해보진 않고 또 쨋든 사람들이 젤 많이 쓰긴하니까, 내 느낌이 잘못된건지 헷갈린다.

https://djot.net/ djot이라고 Markdown 개발자가 Markdown의 문제점을 고쳐서 내놓은 마크업 언어이다. 이러고보니 Deno같군.

(최근에 직장을 옮겨 풀타임 근무를 시작함)

새 동료들과 이야기하다 함수형 언어 이야기가 나왔는데, 밈에 불과한 이야기만 나와서(함수형 언어 사용자들의 컬트스러움 등) 좀 아쉬웠다. 답답하거나 짜증난다기 보단, 빨리 그부분을 스킵하고 진짜 재밌는 이야기로 넘어갔으면 하는 생각이 들었다. 다행히 동료들이니 앞으로 이야기할 기회가 아주 많을 것이다.

불변성, 사이드이펙트 없음, 아름다움(?) 추구 등의 이야기가 나왔는데, 물론 다 함수형 언어와 관계있지만 본질적인건 아니다. 내게 함수형 언어는 코드를 조합하는 방법을 연구하고, 조합이 잘되는 코드를 짜는걸 실천하는 것이다. 이를 통해 많은 것을 공짜로 안전하게 얻는 것이 목표이다. 그래서 '함수형'의 칭호를 부여받지 못한 방법론들은(ex: 상속), 그냥 해보니까 조합성에 한계가 있어서, 설계를 구성하는 근본적인 요소로 포함시키기에 부적절하다고 결론이 내려졌을 뿐이다. 그럼... 그냥 좋은 방법들을 엄선해놓은게 함수형인가? 그럴지도? 다함께 좋은거 합시다.

LLM들한테 JSON 출력을 시킬때마다 이스케이핑하느라 얼마나 머리아플까 걱정되고 안쓰럽다.

나는 옷에 별관심 없어가지고 롱패딩 시즌이 은근히 기다려진다

코드에디터 만들고싶다..

요즘 AI 수학자/과학자를 만들겠다는 스타트업들이 생기고있는데, 멤버들도 빅테크 출신에 쟁쟁하고 투자도 크게 받는 등 절대 장난같은건 아니다. 그치만 의문이 드는건 피할수가 없는데... 만약에 AI 사업가를 만드는 스타트업을 세워서 VC를 찾아가면, '...그냥 직접 비즈니스를 하시죠?'라고 할게 당연하지 않나. AI 수학자/과학자를 만드는 스타트업도 비슷한 느낌이다. 그냥 연구 결과 낸다음 빅테크 인수될 계획이라고 하면 할말은 없다만.