bgl gwyng

오늘 드디어 Hackers' Pub의 기여자가 되었다는 소식. https://github.com/hackers-pub/hackerspub/pull/79

유튜브 프론트엔드 잡버그 심심하면 튀어나오는데, 세계에서 가장 많이 보는 페이지가 이렇다는게 좀 신기하다.

DeepWiki는 자체는 참 좋은데 이번에도 인간이 문제다. 문서를 한번 잘 뽑으놨으면 그걸 찬찬히 읽을 생각을해야지, 밑에 AI와의 채팅창을 달아놨더니 거기다가 게으르게 질문을 하고 앉았다. 원래 취지대로면 에너지도 절약하고 참 좋은데 말이다.

여유가 생기면 Build Systems à la Carte를 읽어봐야한다.

근 1년째 하루 10~12시간 일하고 있어서 너무 힘든데 다행히 일들이 차례차례 정리될거같다.

다른 페디버스 서버에서 온 메시지라 그런가, 약간 외계인이 보낸 전파 신호를 감지한 느낌이 든다.

통신사 해킹 사태 등의 보안 사고에 대해 IT쪽으로 조금이라도 지식이 있는 사람과 아닌 사람(e.g. 우리 엄마 아빠)의 통신사의 잘못에 대한 분노의 크기가 다른거 같다. 가령 나는 해커가 RSA2048를 해독하는 알고리즘이라도 발명해서 해킹했다면 크게 화가 안날것이다. 굿잡, 어쩔수없지 정도? 근데 이번 사고의 디테일은 몰라도 그런거랑은 전~혀 관련 없다는건 당연하다.

근데 우리 엄마도 이게 통신사의 인재라는건 아는데, 동시에 해커들도 뭔가 방어하기 어려운 첨단 기술 그런걸 썼다고 막연히 생각하는거 같다. 그래서 나처럼 통신사들이 한방에 골로 가도 할말 없을 만큼의 잘못을 저질렀다고까지 생각하고 분노하진 않는듯...

jules한테 시킨일을 확인했는데 건질만한 리팩토링은 한 건 이었다. 사실 TODO에 설명을 잘 써놓은게 드물어서 큰 기대를 하면 안되긴 했다(내 자신이 봐도 뭘고치라는건지 헷갈리는거 천지다)

재밌는건, 내가 예외처리를 꼼꼼하게 못한것에 대해 TODO 남겨 놓은것들이 있었는데, jules가 그것들을 많이 고쳤다. 문제는 저게 TS가 예외를 exhaustive하게 처리못하다보니 대충 넘어간건건데, jules가 올린 PR도 같은 이유로 믿고 머지할수가 없었다. 케이스가 보강되긴 했는데 완벽하게 처리한건지는 타입체커 도움 없이는 알수가 없다. AI/타입시스템의 보완적 관계에 대해서 자주 생각했는데, 정말로 구체적인 예시를 이리 쉽게 만날줄이야.

방금 청약홈으로 아파트 청약을 했는데, 사이트가 좀 덜컹거리긴 하지만 어쨌건 필요한 문서도 알아서 긁어와서 확인해주는등 편리하게 만들어져있었다. 맨날 불평하면서 쓰긴 하지만, 우리나라의 이런 행정전산의 수준이 세계에서 손꼽히지 않을까? 다른 나라에서 필요한서류 프린트해서 동사무소 찾아다니고 이럴거 생각하면 깜깜하다.

AI직원의 출근거부사태에 이어, 업데이트가 몇분째 없길래 뭐하고 있냐고 물으니까 황급하게 다시 일하기 시작했다(아마 이용자가 몰려서인것으로 예상). 졸기까지하고 사람 다 됐구만.

jules한테 간단한 과제를 줘봤는데 모노레포에서 작업해야할 디렉토리로 못들어가고 헤매고있다.

아니 일단 출근은 해야할거 아니니...

Jules 떴구나. 그동안 쌓인 TODO, FIXME가 도합 400개 정도되는데, 그냥 아무말않고 적당히 알아서 고쳐보라고 해야겠다.

각 개인이 GPT로 지브리 스타일 프사 만드는걸 뭐라고 하고싶진 않다. 오히려 수백만명이 그걸 했다는건 미야자키 하야오가 창조한 스타일의 우수성을 직접적으로 증명한다. 미야자기 하야오 본인이 원한 방식은 아니었지만.

근데 샘 알트만이 저 기능을 광고하는 행동은 정말 꼴보기 싫었다. 일단 미야자키 하야오 본인이 그걸 매우 싫어할거란걸 몰랐을리 없는데도 그냥 강행했다. 여기선 일종의 트롤링 내지는 악의가 느껴지는데, 등산객들이 쌓아놓은 소원돌탑 무너뜨리는 행동과 비슷하다. '미신이나 믿는 멍청이들ㅎㅎ'이 '예술에 인간의 영혼 어쩌고가 들어있다고 믿는 멍청이들ㅎㅎ' 로 바뀐 것이다. 샘 알트만의 메시지는, 우리 OpenAI가 예술의 가치를 재정의했으니 너희들은 거기 적응하라는 거다.

물론 미신도 구라고 인간의 영혼 어쩌고도 구라지만, 그래도 좀 덜 asshole이 될 방법은 언제나 존재한다. 심지어 이미 이룰거 다이루고 돈도 많은 사람에겐 더 선택하기 쉽기까지 하다.

Nix에 GUI 툴이 부실한게 laziness를 적극적으로 쓰다보니 그런거 같다. 작은일을 하는 nix파일도 실제로 설정을 까보면 사실상 nixpkgs를 통째로 export하고 있고, 이런걸 GUI로 잘 보여주긴 힘들 것이다. public export랑 shy(?) export를 구분할수 있으면 해결되려나?

농담이 아니라, 어려운 문제 때문에 너무 손이 안가는 상황을 타파하려고, 어제는 일부러 autocompletion 정도만 쓰면서 손맛을 느끼며 잡다구리한 리팩토링을 했다. 그다음 설계 개선해야하는 부분을 20분 정도 하고 잤다.

리눅스에서 파일의 리비전을 정확하게 구할 방법이 없는거 같다. 혹시 있나요? mtime과 달리 변경될때마다 1씩 증가하는 믿을수있는 값을 원하는데, 알려진 파일시스템 중에서 이 기능을 바로 제공하는게 없어 보인다. 이런게 되면 incremental build를 정확하게 구현할수 있을텐데, 지금은 비슷한 경우에 해시 아니면 mtime 쓰는걸까.

사이드 프로젝트에 LLM이 쉬운 문제는 다 해치워주는 바람에 이제 머리 아픈 문제밖에 안남아서 그래서 오히려 진도가 안나가고 있다;; 아직 아무도 이 현상에 이름을 붙이지 않았다면 미리 'bgl의 역설'이란 명칭을 선점하고 싶다.

우리 가족은 20년 넘게 KT써왔는데, 2달전에 SKT로 옮기자마자 이 사단이 났다;;

최근에 마주친 문제/주제들이 우연히 다들 '양방향' 이란 개념과 관련이 있다. 아래는 거기 관련된 러프/나이브한 생각들이다.

세션 타입

이건 노골적인 예시인데, 말그대로 서버/클라가 양방향으로 통신하는걸 기술하게 해준다.

Propagator

대부분의 프로그래밍 언어에서 x = 3 + 2과 같은 우변을 계산해서 좌변의 기호에 할당하는 기능을 제공한다.

그런데 3 = x + 2 라고 썼을때 x = 1을 해주는 언어는 거~의 없다. 이런 기능이 왜 필요하냐는 의문이 들 수 있지만, 이런 방식을 간접적으로 다들 매일 쓰고 있다. 예컨데 패키지 버전 관리를 생각해보자.

foo: >= 2.0.0
bar: =< 3.1.0 

이런 식의 설정 파일을 만지작 거릴텐데, 사실 foo >= 2.0.0, bar =< 3.1.0, ... 같은 부등식을 기술하고 있는 셈이다. 여기서 bar가 foo를 의존성으로 가지면 문제가 좀더 복잡해진다. 패키지 매니저는 조건을 만족하는 foo, bar의 값을 알아서 계산해준다.

요지는, 구체적인 값 대신에 조건을 나열하는 방식은 이미 다들 쓰고 있다는 얘기다. 그리고 패키지 매니징이 아닌 다른 문제에서도 이 방식이 좋은 경우는 흔하지만, 조건을 풀어서 값을 구하는 부분을 짜는게 까다로워서 도입하기 쉽지 않다.

여기서 양방향과 관련된 부분은 좌변과 우변의 정보 교환이다. x = 3 + 2는 x <= 3 + 2로, 우변의 정보가 일방적으로 좌변으로 간다고 볼수 있다. 반면 3 = x + 2는 좌변의 정보가 우변으로 가야한다.

x + 1 = y - 3란 예시를 보자. 이 식만 가지고는 x, y의 값을 구할 수 없다. 하지만 x = 3이란 정보가 들어오면 y = 4란걸 알 수 있고, 반대로 y = 5란 정보가 들어오면 x = 1인걸 알 수 있다. 이런 양방향 정보교환을 기술할수 있게 해주는것이 Propagator 패턴이다. Propagator 자체도 세션 타입과 뭔가 관련이 있을거 같은데, 뭐 찾아보면 오히려 서로 관련 없는게 없으니 일단 패쓰.

프로그래밍에서의 타입

모든 프로그래밍 언어는 메타프로그래밍이 가능하고, 대부분의 프로그래밍 언어는 메타프로그래밍을 할 자격이 없다. 나는 그중에서도 특히 자격이 없는 언어인 Nix로 메타프로그래밍을 하는 상황에 쳐해있다. Nix의 특성상 나뿐 아니라 다른 많은 Nix 유저들이 자연스레 이 토끼굴에 빠진다.

Nix의 에러메시지는 읽기가 참 힘든데, 기능이 매우 부족한 언어에다가 여러 개념을 새로 구현해서 얹어놔가지고, 긴 스택트레이스 중에 내가 관심있는 부분은 끝의 일부인데 거기까지의 흐름을 따라가려면 앞의 상관없는 코드도 대충은 이해해야한다. 이게 양방향 정보 교환이 잘 안되고 있는 부분이다.

알다시피 함수 자체는 단방향 정보이다. 스택트레이스는 함수를 통한 단방향 정보의 전달 과정을 보여준다. 그리고 개발자는 그걸 반대로 뒤집은 형태를 분석해야 하는 상황에 놓인다. 이게 개발자 <=> 코드 의 양방향 정보교환의 수단이 제공되지 않아서 생기는 문제다.

개발자 <=> 코드의 양방향 정보코드의 대표적인 수단은 타입이다. 타입은 코드가 스스로를 변호하고, 개발자의 잘못된 변경으로부터 방어하도록 해준다. 대부분의 언어가 메타프로그래밍을 할 자격이 없다는 얘기가, 코드 생성이라는 개발자 -> 코드의 단방향 정보전달만 기술하고 반대로 코드 -> 개발자 방향의 정보를 모조리 잃어버리는 형태로 이루어지기 때문이다.

그런데 타입안전한 메타프로그래밍은 그자체로 어려운 문제이고 아직은 연구주제에 가깝다고 알고있다. 혹시 그냥 개발자에게 뭔가 알려줄수있는 방법 자체를 primitive로 가질 순 없나? 그게 결국 타입이랑 똑같은 것일까? 여기에 TypeScript에서의(역시!) 무근본한 트릭이 소개되어있는데, 약간 관련있을지도 모른다.

정기적으로 하는 미니 컨퍼런스 같은게 있으면 좋겠다. 돌아가면서 각자 최근에 발견/발명한걸 부담없이(뭐 공들여 ppt만들고 이러지 말고) 발표하고 치킨 먹고 헤어지는?

@hollo 아 어찌저찌 고쳤습니다ㅎㅎ

앱개발해야하는데 아이폰 터치가 고장나서 아무것도 못한다. 억까가 끝이 없구나.

프론트엔드 개발을 한 6년정도 하면서 생긴 아직 풀리지 않은 의문으로, 템플릿과 공식 문서에선 그렇게 세련되고 예쁜 컴포넌트들이 왜 import해서 내 프로젝트에서 쓰면 개촌스럽고 못생겨지냐는 것이 있다.

단문으로 짧게 쓰려했는데 분량 조절에 실패해서 그냥 메모리 덤프를 해봤다. 머리에 별로 든게 없어서 한 페이지면 충분했다.

구글이 AlphaEvolve란걸 내놨는데, AI로 새로운 알고리즘을 찾아내서 구글 인프라에 적용시켰다고 한다.

논문을 보니 Gemini 2.0 기반으로 했다는데, 몇번 채팅으로 시험해봤을때 인상적이지 않았던 2.0으로도 이런 결과를 낼수 있다는게 놀랍다. 새로 나온 훨씬 똑똑한 2.5로 하면 어떤 결과가 나올까?

AI의 재귀적 자기 개선이 먼 미래의 일이었던 과거에는, 이런식의 자기 개선 시작되면 그땐 정말로 게임오버일거라고 생각했었다. 아마 나말고도 많은 사람이 그랬을 것이다. 근데 막상 자기 개선이 시작되고나니 이 속도를 어떻게 평가해야할지 모르겠다. 사실 구글이 AI를 통해 인프라를 개선한게 이번이 처음은 아니고 한 3년전부터 있던일이다. 지금 이게 얼마나 빠른거야?

낮에 피쳐 쫙쫙 찍어내고 일이 잘되야 남은 체력으로 자기전에 사이드 작업을 하는데, 낮에 트러블슈팅으로 시간 다 날리고나면 자기전에 코드를 보는거조차 싫어진다. 이거 때문에 reactive joinable table 진도가 2주째 안나가고 있다.

React Native(와 휘하의 써드파티 라이브러리들)는 개발자로 하여금 꼼수를 고안해내기를 끊임없이 요구한다.

유려한 transition animation을 정확하게 구현하려면, transition 후의 레이아웃을 미리 계산해야하는데 이를 위해 일종의 offscreen dry rendering을 해야한다. 실제로 web의 animation 라이브러리 중에 임시로 DOM 트리 만들어서 offsetX같은거 읽는 방식이 있는걸로 안다. 근데 이런 동작을 브라우저 렌더링 엔진이 효율적으로 처리하고 있는지 모르겠다. 혹시 web이 아닌 UI 라이브러리 중에 layout에 대한 primitive를 사용자에게 잘 노출시켜놓은 예시가 있을까?

CCL이라고 일종의 함수형 configuration 언어가 있는데, 여기 소개에 기존 configuration 언어들을 평가하는 단락이 있는데 웃겨서 가져와본다.

TOML

Tom’s Obvious Minimal Language means it’s obvious only to Tom.

XState Store 좋아보인다. 진짜 이거 하나로 상태관리 다 때울만하겠는데?

Figma보다 나은 디자인툴을 만들기 위해서 뭐가 필요할까? 여러 축으로의 개선이 가능하겠지만, 근본적으로 더 우월한 뭔가를 만들고 싶다면 Figma가 내부적으로 쓰는 디자인 언어보다 나은걸 만들어야 한다. 즉 flexbox + CSS + 뭐시기 보다 나은 디자인 언어가 필요하다. 반대로 그런 언어를 이미 알고있다면 그걸 기반으로 GUI 툴을 만드는건 역시 야심찬 작업이긴해도 비교적 자명한 일이 된다. 어떤 툴이든 그것이 내부적으로 쓰는 언어를 능가하는 기능을 제공할순 없다.

라우터 로직을 죄다 XState로 옮기면 무슨 문제가 있을까요? 파일 기반 라우팅 같은건 쓰고 있지 않고, 크게 매력을 못느낍니다.

무언가가 프로그래머블하다는 것은 문제가 생겼을때 디버깅을 해야한단걸 의미한다. 전세계에 프로그래밍을 좋아하는 사람들은 수백만명 정도 있고, 디버깅을 좋아하는 사람은 정확히 0명 있다.

• Nix의 개발새발 빌드 에러메시지를 읽고 있는 누군가

Hell이라고 쉘 스크립팅을 할 수 있는 하스켈 방언이 있네.

Nix 언어를 새로 만들지말고 그냥 Python DSL 같은걸 썼으면 어땠을까 종종 생각한다. 그 세계선에선 또 그 Python DSL 욕을 주구장창 하고 있겠지만, 적어도 생태계는 더 커지지않았을까. 남바완 Linux 배포판이 됐을 수도 있다.

빌드 고치는 것과 같이 결과물을 확인하는데 시간이 오래걸리는 일을 하는 날엔 엄청 비효율적으로 일하게 된다. 이상적으로 생각하면 빌드 돌려놓고 그사이에 다른일 하면 되긴하는데, 나는 컨텍스트 스위칭이 너무 느려서 그게 잘 안된다. 잘 하는 사람은 실제로 병렬로 일을 처리할 수 있나?

뉴럴넷을 설계할수 있는 GUI를 프로토타이핑 해야하는데 좋은 방향이 생각이 안난다. 첨에 착수할땐 자명하다고 생각했는데, 막상 시작하고나니 의외로 참고할 물건도 적고 난감한 상태다.

비올때 엘리엇 스미스 틀어놓고 코딩하고 있으면 기분이 괜찮다.

방금 하스켈 학교에서 객체지향 vs 함수형 떡밥이 n번째로 돌았는데, 나는 그냥 객체지향 = 상속(서브타이핑) 이라고 생각한다. 객체지향에서 상속을 빼면 뭐 남는게 없다. 그래서 객체지향이란 단어를 의미있게 사용하려면 상속이랑 동치시켜 사용할수 밖에 없다고 본다.

근데 상속은 코드를 합성하는 수많은 방법중 하나일 뿐이다. Java같은 언어는 그 수많은 방법중 딱 하나 상속만을 언어 자체에서 지원하는거고, 거기서 벗어나는 다른 유용한 추상화들은 죄다 디자인 패턴이라고 퉁쳐서 부른다. 그래서 객체지향 vs 함수형(= 상속 vs 함수형)은, 나에겐 Monoid vs 타입클래스 같은 비교처럼 들린다. 좌변과 우변이 체급이 안 맞아서 대결이 불성립한다.

혼자서 일하면 끔찍한 관리자 밑에서 일하는 경험과 끔찍한 프로그래머를 관리하는 경험을 동시에 할수 있다. 개꿀~

나는 버전 올리기 강박증같은게 있는데, RN 초기에 불안정한 라이브러리들 많이 쓰다가 생긴거 같다. 일단 버전 올린다음에 빌드 터지는지 기존 기능 잘돌아가는지 확인하는데, 이거하느라 쓰는 시간도 꽤 된다. 실제로 시간을 아끼고 있는지(모르던 버그를 모르고 해결해서) 아닌지 모르겠다.

.cursorrules나 .windsurfrules 등의 파일에 프로젝트에 대한 설명을 써놓는것도 도움이 되나요? 공심 홈페이지의 가이드라인을 보면 코딩스타일 등의 지침만 써놓아서요. 어차피 알아서 일종의 인덱싱을 할테니 필요없을까요?

잉 drizzle에 Live Query 지원이 되네요? [join된 테이블의 reactivity에 문제가 있는데] 이건 고치면되는 버그같고요? 지금 만들고 있는거 왜 하고있지? 제가 원하는 추가 기능을 넣으려면 새로 짤 필요가 있을순 있지만 말이죠.

실제로 방금 어떤 사례를 발견했냐면, 계산이 살짝 까다로운 값에 대한 테스트를 만들라고 시켰더니 코드를 한 백줄 뱉어내는데

expect(x).toBe(42)

이렇게 값에 대한 테스트를 안하고

expect(typeof x).toBe("number")

이러고 넘어가려고 했다. 손바닥 이리내.

join을 지원하는 reactive한 SQLite client 개발 거의 다 되어간다. 혹시 중간에 관두는걸 막기위해 남긴다.

AI가 짠 코드의 테스트코드를 AI한테 짜게하고 있으니 Who watches the watchman? 이 떠오르는 것이다.

.vscode/settings.json으로 확장 켜고끌수 없나 찾아봤는데 해당 이슈가 8년째 오픈이란걸 알게되었다.

똑같은 인터페이스에 대한 여러 구현체에 대해 같은 테스트를 적용하기위한 좋은 방법이 뭘까요? vitest의 경우에 test.each(implementations) 이런식으로 할수 있다는데, 이러면 구현체가 늘어났을때 테스트 파일을 수정해야하는점이 마음에 안든단 말이죠. 지금 구현체를 인자로 받아 테스트를 정의하는 함수를 만들고 각 구현체 마다 .test.ts파일을 만들어서 호출하는 방식을 고려하고 있습니다. 더 좋은 방법이 있을까요?

SolidJS는 React처럼 Reactivity 코어가 분리되어 있지않은거 같다? solid-three, solid-native 등의 프로젝트들이 있는데 2년넘게 관리되고 있지않다.

LLM 시대 이후로 생산성과 관련해서 스트레스를 더 많이 받는거 같다. 당신이 오늘 허투루 보낸 하루는 누군가가 올바른 프롬프팅으로 +10K LOC를 할수있는 하루였다, 같은 생각을 퇴근하면서 한다.