뭔가 any를 떡칠한거 같지만 미래의 내가 알아서 잘 없애주겠지?

@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee @2chanhaeng이찬행 쉬운 이슈 처리는 오늘 머지된거 이후로 없을거에요 걱정하지 마세요 ㅋㅋㅋ

@kodingwarriorJaeyeol Lee @2chanhaeng이찬행 저 티켓 다 가져갑니다?

오늘따라 키보드 키압이 너무 높은걸?

이슈들 확인해보면서 어떤 것들이 있는지 파악하니까 꽤 해볼만한거 같군

아침에 코드 읽다가 TODO를 봐서 고쳐봤다. 다듬는건 회사가서 해야지

역시 프로젝트를 빨리 이해하려면 직접 써보는게 가장 확실한거 같다

@kodingwarriorJaeyeol Lee 끝장내고 왔습니다

오늘 커피챗은 끝내줬다

이전에도 여러번 추천한 책이지만 저 같은 경우엔 "밑바닥부터 만드는 인터프리터 in Go"로 Go에 입문했습니다. 책의 목적은 인터프리터의 동작, 구현에 대한 것이지만 따라하면서 Go의 코드 스타일이나 테스트 작성 방법도 자연스럽게 익히게 되었습니다. 아니면 "Must Have Tucker의 Go 언어 프로그래밍"도 좋습니다.

내 블로그 글이 기상청 API 피해자 모임이래 ㅋ

CLI 테스트 하고 QA는 클로드 코드를 사용했는데 아주 좋은 개발 경험이였음

얼마전에 구현한 debugger adapter protocol이 실제로 사용 가능한 레벨까지 구현되었다. 한참 걸리겠지만 머지 이후에 외부 IDE에 익스텐션을 만들기만 하면 될듯

@bglbgl gwyng AGI가 멀지 않았습니다

기존에 구현된 코드가 아무리봐도 어떻게 수정해야 할지 감이 안잡혀서 뭐가 더 좋을지 분석해달라고 함.

오늘의 Zed 싱글벙글: Inlay Hint에 non-ASCII 텍스트가 있을 경우 Go to Definition하려고 커맨드 누른 채로 커서 올리면 에디터 전체 패닉 남

역시 코드는 추가할 때보다 삭제할 때가 더 타격감이 좋다

@hongminhee洪 民憙 (Hong Minhee)

그런 거 쓸 거면 Python 안 쓰죠

프로그래밍 언어의 언권?투사가 되게 만드는 발언이군요. 어떤 프로그래밍 언어든 저런 취급을 받아선 안됩니다. 설령 PHP, 아니 Brainfuck이라고 하더라도 린터와 포매터는 갖추고 살아야합니다.

코드 수정 없이 이슈를 닫았다. 만족스럽군

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 앞으로 쭉쭉쭉

이제 진짜 코드베이스를 파악해야 한다

자유의 몸이 됨

퇴근이 뭐지?

ossca 결과 보니까 fedify 합격한듯?

A Higgs-Bugson in the Linux Kernel

Link: https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/
Discussion: https://news.ycombinator.com/item?id=44447259

Vibe Coding

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

Arstechnica 에서 이런 글을 보았습니다.

A history of the Internet, part 2: The high-tech gold rush begins

제가 이것저것의 역사에 대하여 흥미가 많다는 말을 여기에 쓴 적이 있던가요? 게임이라거나 컴퓨팅이라거나 ...

사실 대강의 사연을 알고있던 저 2편보다는, 제가 모르던 사연이 더 많은 1편 An Ars Technica history of the Internet, part 1이 더욱 흥미로웠습니다.

그 와중에 글을 쓰는 방식과 디테일들이 마음에 들어서 글쓴사람을 클릭해보니 와우' -' 보물창고가 쨘 하고 나타나는 것이었습니다.

일단 처음에 눈에 띄여서 이 시리즈를 읽었습니다. 재미있었어요.

• A history of ARM, part 1: Building the first chip
• A history of ARM, part 2: Everything starts to come together
• A history of ARM, part 3: Coming full circle

그래서 ARM의 원래 이름은 Acorn RISC Machine. 도토리 RISC 머신이었던 것입니다 ' -' ...

다음에는 Amiga 의 역사를 읽어볼 생각이에요. 두근두근.

생각해보니까 외부 레포로 빼는게 나았으려나

받아들여질지는 모르겠지만 debug adapter protocol을 구현해서 밀어넣었다. 디버거가 CLI만 지원하기 때문에 사용하기 너무 불편했음. https://github.com/gnolang/gno/pull/4406

claude code를 몇 주간 써본 결과 TODO 리스트가 없으면 오버엔지니어링을 하기 때문에 간단한 작업은 따로 프롬프트를 넣거나 아예 처음부터 작업 목록만 따르도록 하는게 맞는 것 같다.

미국의 이란 폭격 작전 Midnight Hammer를 "자정의 망치"로 번역했지만 정황을 고려했을 때 "아닌 밤중의 홍두깨"가 더 어울린다.

Another blog post on homotopy almost ready.

제미니와 즐거운 나날

제텔카스텐이니 세컨드브레인이니 하지만, 정작 우리나라에서 만든 창의적 방법론에는 무관심한 듯.

우리나라에서 제텔카스텐 기법을 극대화하신 분은 다산 정약용 선생 아닐까? 여유당 전서, 흠흠신서, 목민심서, 경세유표 등등 엄청난 저술 활동을 해낸 분. 여유당 전서는 500권이 넘는다. 제텔카스텐을 창안(?)한 루만도 고작(?!!!) 300편의 논문만 썼다.

예전 다산 선생을 다룬 책에서 제텔카스텐 기법을 본 적이 있는데...

와 이 도메인을 진짜 왜 아직 아무도 안 샀지??

아마 향후 10년간의 성장에 큰 족쇄가 되지 않을까 싶음

해당 breaking change에 대한 워크샵 같은걸 했는데 아는 사람은 그 이상으로는 여전히 모르고, 모르는 사람은 여전히 모르는 상태로 남음.

2025 오픈소스 컨트리뷰션 아카데미 참여형 멘티 모집이 이번주 일요일까지입니다! Fedify 프로젝트에도 많이 지원해 주세요!

한달 전에 breaking change들을 여러번 맞은 덕분에 서비스가 터졌었는데 드디어 주요 기능들을 돌아가게 만듦

사실 시간이 모자라서 땜빵했던게 90%지만 일단 넘어가는걸로

과거의 나는 코드를 왜 이렇게 짰을까 싶으면서도 그때는 몰랐던 것을 지금은 볼 수 있게 된거니 선해하자면 발전의 흔적이라고 해도 되겠다

오버엔지니어링을 자제해야 하지만 이게 또 일하면서 보람을 느낄 수 있는 방법 중 하나라 타협점을 찾아야겠음

파이콘 등록 완료

회사 내부 툴로 돌아가는 파이썬 스크립트들의 디펜던시 관리를 uv로 하도록 수정했다

Rust에서는 파인애플 피자에 대해 컴파일 에러를 띄우려고 시도한 적이 있습니다.[1]

[1] https://github.com/rust-lang/rust/pull/70645