bgl gwyng

Vibe coder? 3류다. Agent Orchestrator? 2류다. Permission granter. 그것이 1류다.

예전에 만들었던 lat이 코에 점찍고 돌아왔습니다. zat이란 이름은 훑어보다라는 뜻의 일본어 ざっと (zatto)에서 따왔습니다. CLI code outline viewer이고, zat main.ts 이렇게 하면 export 된 값들의 이름과 타입 시그니쳐 등, 코드의 인터페이스 부분에 해당하는걸 보여줍니다. 디렉토리에다가 zat src/ 해도 entry 파일들을 찾아서 적당히 잘 보여줍니다. 주로 코딩 에이전트가 쓸 것을 기대하고 만들었고, 코드 내비게이션을 할때 토큰 수를 줄이고 불필요한 정보가 컨텍스트에 미리 들어가는걸 줄여줍니다. 또 Nix 유저라면 zat 쉽게 확장해서 자기가 쓰는 언어를 지원하게 할 수 있습니다.

https://github.com/bglgwyng/zat

슬슬 사람들이 토큰 태우기의 무상함을 느끼고 함수형에 귀의할때가 됐는데..

미니PC 생긴김에 브라우저 기반 에디터에 대해 다시 생각해봤는데, 나는 브라우저의 탭을 그대로 쓰고싶단 말이지. 근데 cross tab 메모리 공유가 아직 제약이 많다. SharedWorker들간에 SharedArrayBuffer도 못보내고, 문자열 전송에도 매번 복사가 발생한다. 뭐 이런 문제 있다고 브라우저 기반 에디터를 못만드는건 아니긴 하지만 아쉽다. 관련한 WHATWG에 제안이 있는데 언제 시간날 때 기여해보면 좋겠군.

difftastic처럼 AST를 활용해서 diff를 뜨는 툴은 이미 있는데, 아예 AST끼리 비교해서 힌트를 활용해 더 관대하게 merge하는 방법도 생각해볼수 있겠다. 여기서 힌트는 가령 하스켈에서 record 문법의 경우 property 순서가 무관하고 이런거.

뭐같이 못만든 프로그램을 쓰고있으면 방사능에 피폭되는 기분이다. 은행 앱 얘기다.

요즘 코딩 에이전트도 그렇고 TUI 만드는게 유행인데, 여기에 무슨 장점이 있는걸까? 뭔가 까리하고 간지나는건 인정하는데 말이지. 그냥 로컬 웹서버 띄우는게 낫지않나?

ssh를 쓴다면 이해가 되는데, 그건 브라우저에서 인증을 편리하게 만드는게 나은 방향이라고 본다.

주말에 Pijul을 연습해봤다. Pijul은 패치 이론 기반의 VCS로, Pijul 패치는 Git의 커밋과 달리 순서가 (완전히는 아니지만) 상관없다. 그래서 Git의 merge, rebase, cherry-pick이 Pijul에서는 그냥 apply이다. 커밋은 나열해야하는 반면 패치는 마치 숫자처럼 '더할' 수 있다. 그래서 그런지 튜토리얼은 오히려 훨씬 쉬웠다. 배울게 적어서 너무 빨리 끝났다고 느꼈을 정도.

물론 실무에 투입하려면 여러가지 애로사항이 있을텐데 차차 공유해보겠다.

Software Engineer's Never-Ending Backlog란 레포를 만들었다. 이름은 AI 벤치마크 [Humanity's Last Exam의 패러디이다. 자꾸 입개발만 하고 실제로 문제를 해결하는데 노력을 안하게 되어서 스스로에게 동기부여를 하고자 만들었다.

많이들 GitHub PR 만들고 Jira 티켓도 만들어서 서로 링크하는 등의 일이 좀 뻘스럽다곤 느꼈을 것이다. 왜 Git만으로 안되고 플래닝 툴이 또 필요한가? Git 못 쓰는 팀과의 협업같은 현실적인 문제는 잠깐 제쳐두면, 많은 부분을 Git을 쓰는 방식으로 해소할수 있다.

우리는 Git에 커밋을 할때 어떤 기능을 추가/버그를 픽스해서 소스 코드에 뭘 더 붙이거나 구멍을 메워야 한다고(Positive) 생각한다. 하지만 커밋은 Negative할 수도 있다. 그냥 TODO, FIXME 코멘트만 붙인 커밋도 가능하다. 그럼 이후에 커밋에서 그걸 메우면 되는거다. 이 방법으로 많은 도구의 재발명을 막고, Hole-Driven-Development, Agent Orchestration, etc를 할 수 있다고 본다.

물론 이렇게하면 Git의 한계도 드러나는데, 가장 치명적인 건 저런 구멍들에 대한 인덱싱이 불가능하단 거다. 그래서 VCS 새로 만들고싶단 얘기를 반복하게 된다.

Kroisse님과는 하스켈 서버에서 같은 주제로 이야기를 나누었는데, 나는 패키지 매니저 그냥 만들지 말자는 입장이다. 또는 작게 만들거나.

패키지 매니저가 하는일이

1. 조건에 맞는 패키지를 찾아줌
2. 패키지를 다운받게 해줌

여기서 2를 위해 별도의 프로그램이 필요하진 않다. 그냥 http나 git 클라이언트 쓰면 된다. 애초에 패키지 매니저들도 레지스트리로부터 패키지를 다운받는것외에, http, git 등을 레지스트리에 올리기 이전 개발단계의 편의를 위해 별도로 지원한다.

그럼 1번이 문제인데, 이게 쉬운 문제였으면 정말로 패키지 매니저가 필요없긴 했겠지. 저 조건이란게 단순히 strict한 버전이었다면 git tag등으로 명시하면 그만이다. 현실은 ^3.1.0 같은 여러 버전을 허용하는 방식이고, 같이 설치하는 패키지들의 버전들의 제약 조건을 풀어서 만족하는 버전을 찾아내야한다. 이걸 하려면 여러 패키지들을 모아놓아야하다보니 패키지 레지스트리라고 하는 서버가 생긴다. 그리고 패키지 매니저는 그 서버에 대한 클라이언트가 된다.

... 이렇게 써놓고보니 마치 서버에서 버전 제약 조건을 푸는 solver 역할도 할것 같은데, 대부분의 경우 그렇지 않다. 보통 클라이언트한테 패키지의 메타데이터(어떤 버전이 있는지, 각 버전마다 의존성은 뭔지) 내려주고 클라이언트에서 푼다. 패키지 수가 별로 많지않은 하스켈의 Hackage의 경우엔 그냥 메타데이터들 모아놓은 tar 파일을 하나 내려주는게 끝이다.

패키지 매니저란게 뭔가 거창한거 같은데, 의외로 별거 아닌 동작들을 한군데 모아놓은거란 걸 알수 있다. 확실히 까다로운 부분이라면 버전 solver 정도? 그리고 여기다가 꼭 패키지 매니저가 할 필요는 없는 기능들을 하나둘 넣어서(빌드나 npm run 같은 잡 기능이나) 또 별 이유없이 큰 프로그램을 만든다. 그렇다면 UNIX 철학에 따라 최대한 작은 패키지 매니저를 만들면 어떻게 될까?

그냥 버전 솔버만 만들면 된다는게 내 의견이다. 나머지는 그냥 파일 다운로드 받는거고 git한테 맡기면 된다. 더 나아가 버전 VCS가 버전 솔버까지 해야한다는게 내 입장이지만 이 얘기는 일단 pass. 또 Hackage와 달리 npm의 경우에 그 규모 때문에 패키지 메타데이터를 통째로 받기가 어렵긴 하다. 하지만 많은 언어들이 Hackage같은 접근을 할 수 있고(Rust의 crate.io도 그랬던걸로 안다), 그게 불가능할 경우에도 문제를 해결할만큼만 프로그램을 키우는게 낫다고 본다.

그리고 자꾸 Nix 얘기만 해서 짜증날까봐 걱정이긴한데, 여기서 버전 솔버 빼고 나머지를 모조리 Nix한테 맡길수 있다. 패키지 다운로드, locking, 빌드 등. 이때 패키지 매니저를 최대한 작게, 솔버 역할로만 만들어야지 Nix와 쉽게 연동될 수 있다. Nix가 다른 건 다 포용해줘도, 쓸데없는 IO 많이 발생시키는건 쉽게 안 봐준다. 다른 옵션으로, 만약 Nix를 안 쓰겠다면(합리적인 이유들이 있음), 차라리 Bazel/Buck과 같은 범용 빌드시스템을 위한 해당 언어의 플러그인/rule 같은걸 만드는 것도(이것도 거의 버전 solver에 가까울 거다), 큼지막한 패키지 매니저를 개발하는걸 피함과 동시에, 결과적으로 더 나은 결과를 얻을수 있다.

devenv라고 mise 비슷한 물건이 있는데, Nix를 잘 모르고도 Nix의 혜택을 누릴수 있게 해준다. 처음부터 NixOS 설치하기는 무서운 개발자들은 저거부터 시도해보는것도 좋겠따.

@eatch.dev잇창명 EatChangmyeong💕🦋 해마 이모지 같은 Glitch Token이나 Attractor State란 개념이 있어요.

Zed 에디터 공짜로 쓰긴좀 미안한데, 그렇다고 10$ 내고 AI 기능을 쓰자니 옆에 붙은 클로드 세션밖에 안 볼거 같아서 참 애매하네.

AI 코딩 이후로 코드 리뷰/품질 관리에 더 철저한 노력을 기울이자고들 얘기하는데, 정말로 그렇게 하려면 훨씬 더 의식적으로 해야겠다는 생각이 든다. 동료가 클로드랑 뚝딱 만들어서 가져온 코드 중에, 방향이 너무 근시안적이고 불필요하게 복잡한 코드가 종종 보인다. 근데 그럴때 단호하게 수정 요청을 날리지 못하고 그냥 머지하는 경우가 많았다. 내가 아직 '일단 문제를 해결하는 하는 코드'를 짠 것에 여전히 가치를 인정하고 있어서 그런거 같다. AI 코딩 이전에는 '일단 돌아는 간다'는게 (안타깝게도) 큰 가치를 가지고 있었기 때문에, (그리고 그걸 짠 사람의 노력도 고려에 넣고) 머지해놓고 나중에 생각하는게 나쁜 판단이 아니었다고 본다. 근데 지금은 그게 전혀 아닌데도,관성 때문에 그렇게 못하고 있다 . '저 코드의 가치는 (5분 + 100원)이다'라고 셀프 프롬프팅해야 할듯..

ssh 서버가 아닌 클라에서 tmux쓰면 새 탭 열때마다 연결을 새로하는게 맘에 안 들었는데, SSH connection multiplexing 란 기능을 쓰면 하나의 TCP 연결을 유지하면서 여러 탭을 쓸수 있다고 하는걸 배움.

RFC를 만들었다.

개발자로서 느끼는 Nix의 최대장점은 패키지가 가능한한 최대로 configurable하다는 것이다. 가령 nixpkgs와 homebrew에 똑같이 10만개의 패키지가 있다고 하자. 하지만 nixpkgs에는 실제로 그보다 훨씬 많은 수의 패키지가 있는 셈이다. 저 10만개 외에도, 쉽게 설정을 바꿔서 안전하게 새로 빌드할수 있는 잠재적인 패키지들이 무수히 많기 때문이다.

beelink 미니PC를 주문했다. NixOS, Tvix, LLM 에이전트를 가지고 놀아보려고 한다.

오늘 동료랑 모노레포 설계에 대해 이야기하다가, 아래의 내용을 근거로 모노레포 설계에 너무 많은 시간을 쓰지말고 그냥 죄다 몰빵하자고 설득했다. 내가 생각하는 올바른 워크플로우를 어차피 도입하지 못할 거고, 그 상황에서 차선책들을 늘어놓고 고민을 하느니 시간이라도 아끼자는 입장이다.

내가 가진 개발에서의 지식/경험/의견은 negative한 형태가 많은것 같다. 어떤 문제에 대한 명쾌한 해결책(positive)보다는, 어떤 문제가 어렵거나 별로 중요하지 않으니 그쪽으로 시간을 쏟지 말아야한다는 사실을 활용하게 되는 경우가 더 잦다.

클로드가 2주 동안 gcc 호환되는 컴파일러를 만들어서 다들 놀라고 있다.

한가지 고려해야할 부분은, 애초에 소프트웨어 공학 자체가 큰틀에서 설계를 잘하면(클로드는 이미 현존하는 가장 훌륭한 설계도 알고 있을 것이다) 나머지는 꾸역꾸역 코드를 짜서 제품을 완성할수 있게하는게 목표란거다. 그러니까 클로드가 C 파서를 짰다고 하면 2026년 지금은 아무도 안놀라겠지. 근데 소프트웨어 공학 지식은 C 파서를 짤수 있는 인간이 더 많은 시간을 투자하면 C 컴파일러도 짤수 있게 해준다.

그래서 모델의 성능이 좋아질수록 마치 RPG에서 레벨이 오르면 새로운 장비를 착용할수 있게 되어 급격히 강해지는것과 같은 일을 보게될거 같다. 하지만 이때 장비를 착용할수 있는 능력과 장비를 만들 수 있는 능력을 구분할 필요는 있다. 이제 후자가 AI 회사의 다음 목표인셈인데..

vercel에서 skills 패키지 매니저도 내놓았다는데, homebrew도 그렇고 사람들이 foo add bar 로 뭔가 되는걸 너무 좋아하는듯..

Nix 유저들은 왜 자꾸 주변 사람들도 Nix를 쓰게 만드려고 하는지 아십니까? 그게 다 본인의 정신 건강을 위해서입니다.

GPT한테 질문하면 끝에 이어지는 후속 질문을 제안하는데, 사실 그건 GPT 본인이 하고싶은 이야기란걸 알수 있다

https://x.com/math_rachel/status/2016232354608800254?s=46&t=I3_HxFRtjlCXCspThn61wA

바이브 코딩하면 긍정적인 몰입이 아니라 어두운 몰입(dark flow)에 빠진다는 이야기. 얼마전에 아르민 로나커도 비슷한 얘길했지. 결과물과는 별개로 바이브 코딩하고나면 머리가 바싹 마르는거 같아서 요즘 힘들다.

클로드 코드나 코덱스 등을 쓰면 작업한 데이터가 다시 각 모델의 학습에 쓰일거고 이러면 성능이 떨어지는 오픈웨이트 모델들이 격차를 따라잡는게 더 힘들어진다. 작업 내용을 export해서 오픈데이터셋 등에 쉽게 기여할 방법이 없을까?

조만간 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: 붙이는 컨벤션은 뭘붙일지 애매한 경우가 너무 많아서 별로라고 본다.