@hongminhee洪 民憙 (Hong Minhee) 근데 저도 한 10년전에 파이썬 프로젝트할때 Django 대신 Flask 골랐었는데, 아마 홍민희님 글 읽고 그랬던거 같아요.

@hongminhee洪 民憙 (Hong Minhee) 청개구리 스택을 골라놓고 피지컬로 돌파하고 계시는군요

새롭게 다시 태어난, 또 만들어버린 boilerplate. 이제는 진짜 monolithic 하고 Pocket Galaxy라는 이름에 걸맞는 boilerplate입니다.

Django + Vue(Vuetify) 조합이구요, nginx가 이것저것을 다 처리합니다.

백엔드는 /api에서 서빙하고, 기타 기본적인 static 캐싱이나 로깅 등 전부 기초적인건 제공합니다.

간단한 웹사이트 하나 만들겠다는게 어쩌다 여기까지 왔는지.... 암튼 이제는 진짜 최소한의 웹사이트 만들때 뚝딱 하면 만들수 있을것 같습니다 제발...

내부용 툴 만들때 애용해보세요.

https://github.com/theeluwin/pocket-galaxy

오픈소스 프로젝트에 여러분의 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 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

나는 리액트에서 성능 자체가 떨어지는 부분보다(제대로 체감한적 없음), 성능을 고려해서 컴포넌트를 일부러 나눠야하는 점이 더 맘에 안든다.

클플 뭐 서비스 낼때마다 리전 맨날 Earth 요따구로 해두니까 우주진출 뒤의 클플을 상상하게 됨

@theeluwin제이미 축하드립니다!!

Gemini CLI 공개 됐네. 어떠려나…

부트캠프의 함정, 오버엔지니어링 https://subokim.wordpress.com/2025/06/20/overengineering/

리액트 작업하면 vs code 탭 두 개 한 화면에 브라우저 한 화면에 디자인 전달받아서 하면 figma나 시안 확인용 화면 하나에 모니터 세 개쯤은 있어야 하던데 노트북만 들고 카페에서 코딩하는 건 어떤 종류의 작업일까….

해커스 펍은 아무래도 어텐션이 낮다 보니 채용 시장 이야기를 조금 해 보자면 (트위터는 왠지 채용 과정에서 아쉬운 경험을 하신 분들도 있을 것 같고, 해서) 새로운 프론트엔드 개발자분이 곧 합류하시는데 채용까지 이르는 데 까지 정말 많은 이력서 스크리닝을 해야 했다. 솔직히 말해 '옛날에 비하면' 뛰어난 개발자분들이 시장에 많은데 (공개적으로 이야기하기는 뭐한) 특정한 스타일의 비슷한 개발자분들이 아주 많다. 괜찮은 사람을 아무나 빨리 뽑는 채용 기조는 아니다 보니 정말 특출나게 뭔가 뛰어난 부분이 있는 분을 찾아야 한다는 압박감이 있었고, 이것때문에 좀 힘들었다.

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) @hongminhee洪 民憙 (Hong Minhee) 좋아용~

블로그 글로도 적어봤습니다. 재현 환경 구성 하는거 너무 노가다인데 어떻게 잘 할까..

https://moreal.hashnode.dev/vitepress-localsearch-debugging

오늘의 코딩은 합정역 근처에 위치한 카페 콤파일에서 했습니다!
해커스펍의 개발자 분들이 좋아하실 것 같은 노트북하기 좋은 카페에요

#콤파일 #코딩하기좋은카페

@hongminhee洪 民憙 (Hong Minhee) 저도 일요일이 좋아요

주말에 튜사 모각코하실분 있나요~

@oilpaintingkim 고민되시겠어요. 음… 결국 본인 성향과 어떤 걸 하고 싶으시냐에 따라 다를 것 같은데, 자기 주도적이신 편이라면 첫번째 회사가 좋을 것 같고요. 누군가 가르쳐 주는 사람한테 배우는 걸 좋아하시면 두번째 회사가 좋을 것 같아요.

@curry박준규 대신 해커스펍에 씁시다ㅋㅋ

안녕하세요 이번에 신입 개발자 취업에 성공하게 되었는데 두 회사중에서 고민중입니다.

두 곳 모두 프론트엔드 직무고, 최종 합격은 했는데 방향이 너무 달라서 글 올려봅니다!

1. 웹페이지 제작 전문 회사 (정규직)

• 고용 형태: 정규직 (풀타임)
• 기술 스택: PHP 기반의 오픈소스 콘텐츠 관리 시스템(CMS) + JS/TS
• 업무 내용: 홈페이지 리뉴얼 및 내부 시스템 개발 등
• 장점
  • 제가 기술 도입을 주도할 수 있는 환경인듯 합니다
  • 프론트엔드 개발의 모든 범위를 직접 경험 가능
• 단점
  • 레거시 기반 스택 중심
  • 최신 기술 도입은 가능하나, 대부분 혼자 해결해야 할 수도 있음 (사수 없습니다!)

2. 어느 정도 규모 있는 보안쪽 IT 자회사 (인턴)

• 고용 형태: 인턴 (하루 5시간, 약 4개월)
• 기술 스택: React
• 업무 내용: 보안 관련 웹 페이지 개발 일부 참여
• 장점
  • React 기반의 실무 경험
  • 체계적이고 안정적인 조직 문화 기대
• 단점
  • 실무 범위가 제한적일 수 있음
  • 인턴 기간 이후엔 다시 취업 준비를 해야 함 (정규직 전환 없습니다!)

많은 의견 주시면 감사드리겠습니다!

뭔가를 잘 설명하는 방법에 대해 생각해봤는데. 일단 내가 어떤 내용을 말하고 싶은 욕구를 참아내야다. 어떤 재치있는 비유를 꼭 써야겠다거나, 아니면 '통찰'을 전달하고 싶다거나.

대신 상대방의 무지에 공감해야한다. 그 무지란게, 많은 경우 진짜 멍청해서 그런게 아니라, 대충 얼개는 파악하고 있음에도 뜬금없는 부분에서 뜬금없는 오해를 하고 있어서 완전한 이해를 막는다거나 하는 경우가 많다. 그래서 그 귀여운 멍청을 함께 디버깅해야한다. 요게 지식뿐만 아니라 공감능력이 필요한 부분.

크롬 개발자 도구의 네트워크 디버거에, 특정 상황에서(제 경우엔 400 Bad Request 에러 발생) 응답 본문이 빈 문자열로 표시되는 버그가 있는거 같습니다???

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 의 역사를 읽어볼 생각이에요. 두근두근.

Just learned of a self-hostable ticketing software called Pretix: https://pretix.eu/

It looks extremely full-featured.

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

역시 하스켈을 가르친 덕택일테지...

마지막 멘티가 취직에 성공해서 기분이 좋구만

It's pretty unfortunate that NodeJS still doesn't have Fetch API based servers included while still being the most used JS runtime. This justifies server side libraries keep promoting Express usage by default on docs, which is not good considering that it's a NodeJS specific one.

Windows NT라는 이름은 David Cutler의 말장난에서 비롯되었다고 한다. 그가 DEC에서 일할 적에 만든 운영체제가 VMS인데, Microsoft로 옮긴 뒤에 VMS를 계승한다는 의미에서 VMS의 각 알파벳을 한 글자씩 뒤로 미룬^[1] WNT를 코드네임으로 썼던 것.

유튜브 쇼츠 안보이게 해주는 크롬 확장. 왜 진작에 쓸 생각을 안 했지?

https://chromewebstore.google.com/detail/remove-youtube-shorts/mgngbgbhliflggkamjnpdmegbkidiapm

@meWoojin Kim 말씀하신 '계속해서 영원히 쌓아 간다'는 감각은 여전히 중요한거 같아요. 시즌제로 하되 시즌을 완전 메타적으로 다루지말고 게임 내적인 설정과 어떻게 엮으면 도움이 되지않을까 싶네요. 또 계속해서 영원히 쌓다보면 예전에 쌓아놓은게 무가치해지는 문제가 있잖아요? 그래서 쌓은게 쌓은게 아닌게 되어버리는데, 시즌 보상을 어떻게 잘 설계하면 이 문제 또한 기존보다 더 잘 해결할수 있지 않을까요?

@lionhairdino 그건 항등원 말고 다른값들도 다 가능하지않나요? 1 ( _ ) 3 = 4 1 ( _ ) 3 = 3하면 각각 +, *로 유추되겠죠. 똑같은(identical) 값이 나오게하는 값이라는 정의 자체와 부합하는 용어인데 필요이상으로 꼬아서 생각하고 계신게 아닌가 싶네요.

@lionhairdino 연산은 정의하려면 아무렇게나 정의할수있고, 같은 항등원을 가지는 다른 연산도 여러개 만들수 있잖아요. 그래서 항등원 자체로 연산에 대해 뭔가 많은걸 알려준다고 보긴 힘들다고 생각합니다. a + b, max(a, b), a + b + ab 모두 0을 항등원으로 갖죠. 그냥 연산을 수행하기 전과 후가 identical해서 identity아닌가 싶네요.

@meWoojin Kim 저는 어떤 형태로든 시즌제를 도입해야한다고 생각합니다. 단순하게 생각해서, 사람들이 옛날에 했던거를 (약간의 변경만 포함해서) 다시 해도 충분한 재미를 느끼는데요. 이 방식을 전혀 활용하지않고 계속해서 새로운 컨텐츠를 제공해내겠다는게 많이 무모해보입니다. 저는 와우 클래식도 아~주 긴 시즌제로 볼수있다고 생각합니다.

소프트웨어 엔지니어링 가이드북 저자 게르겔리 오로스, 켄트백 둘다 페디버스 계정 있는걸 사이먼 윌라이슨 계정을 통해 알았다..... 페디버스에서 네임드 개발자 찾으라면 있긴 있는데, 사혼의 구슬 찾는듯한 이 묘한 기분

@hongminhee洪 民憙 (Hong Minhee) 저도 좀 비슷한 히스토리가 있어요. 중학생쯤 되면서 그동안 봐왔던 포켓몬같은 애니가 유치하게 느껴지고, 좀더 시리어스한 장르를 찾게 되었는데요. 그때 그런 수요를 맞춰주는 에반게리온, 페이트 이런거 재밌게 봤어요. 근데 그러고나서 더 딥다크한 애니를 찾진 않고 대신 마찬가지로 시리어스하고 좀더 핍진성 있는 미드/영드에 안착하게 되더라고요. 지금은 거의 범죄/공포/스릴러 드라마만 보고 살고있네요.

기분 좋은 일. 작업실에 밥 주는 성격 좋고 조심성 있는 고양이가 있는데 이 친구가 동네 최약체라 다른 큰언니한테 맨날 맞고 밥도 뺏기며 마주치면 도망가고 숨어다녔단 말임. 사실 양쪽 다 밥 주고 싶은데 큰언니는 자기가 우리를 다 차지하고 싶어서인지 최약체를 쫓아내려고 해서 맘에 안들었음. 그래서 최약체 전용 밥을 실내에서 따로 주기 시작했는데 최약체도 좀 컸고 또 건강상태가 좋아져서인지는 몰라도 이제 이전처럼 큰언니와 대면할 때 그냥 도망치지 않고 거리를 둔 채 위협하며 대면하는 단계까지 갔다. 오늘은 그 위협에 무서운 큰언니가 아주 천천히 시야 밖으로 사라졌고 그걸 보는데 너무 대견하게 느껴짐. 잘했어 최약체야.

번아웃으로 아직 고생하는 가운데, 갑자기 삘이 와서 지난 1주간 170쪽짜리 소설을 Gemini로 써 버렸다. 소재가 너무 잔혹해서 (R-18G 수준) 그대로 공개하기에는 꺼려진다는 문제가 있을 뿐; 줄거리 자체는 내가 예상한 것 이상으로 잘 나왔는데 퇴고를 열심히 해서 그런 것 같다. 구체적으로 어떻게 된 거냐 하면,

1. Gemini 2.5 Flash로 짧은 초안 작성 (1판)
2. 이 초안의 중간 즈음에서 두 개의 새 줄거리를 만들어서 전체 줄거리 수가 3개가 됨
3. 이대로는 안되겠다 싶어서 Flash의 제안을 일부 받아 들여 줄거리를 하나로 재조정 (2판)
4. 이 시점에서 Gemini 2.5 Pro한테 평가를 부탁하고, 평가 내용을 다시 Flash에게 되먹여서 액션 아이템을 만들어 퇴고를 반복 (3~7판)
5. 이 참에 번역도 맡겨야지 싶어서 Flash한테 먼저 초벌 번역을 시킴 (번역 1판)
6. 초벌 번역을 Pro한테 주고 고쳐야 하는 부분을 그 이유와 함께 나열하게 함
7. Flash한테 수정된 번역과 수정한 이유들을 주고 판단하게 시킨 다음 최종 번역본을 완성 (번역 2판)
8. 마지막으로 Pro한테 전체 번역문을 주고 전체 번역 안에서의 일관성이 깨진 게 있는지 확인

이랬는데, 가장 곤란했던 건 역시 4였다. 왜냐하면 내용이 너무 길어서 텍스트 창에는 한 번에 안 들어가고(...), 잘라서 넣으면 이제 뭔 짓을 해도 앞부분을 까먹어 버렸기 때문이다. 최종적으로 동작한 방법은 소설을 최대 32KB 크기가 되도록 쪼갠 뒤 파일로 나눠어 업로드하고, 업로드가 끝난 뒤에 몇장까지 있는지 확인하고 뒤가 잘린 문장이 있는지 확인해서 뭔가 문제가 있으면 평가를 하지 않고 멈추라고 지시한 것. 혹시 이런 일 해야 하는 분은 참고하시길.

...뭐 이렇게 말하긴 했는데 사실 Flash한테 글 쓰기는 다 맡겼지만 세부적으로는 상당히 손을 많이 거쳤다. 한국어나 영어 번역이나 둘 다 그랬음. 나름 노력한 것도 있고 이 전체 내용을 다시 Flash한테 되먹였더니 찬사 일색(!!!!!)이라 진짠가 싶어서 어디 올려야 할 것 같긴 한데 소재가 소재다 보니 공개도 간단하지 않다는 게 곤란하다. 호옥시 관심 있으신 분께서는 메일로 pdf 파일을 보내 드리겠습니다.

코드에디터의 탐색기 동작을 이렇게 개선하면 좋겠다.

지금 큰 프로젝트에서 이파일 저파일 돌아다니다보면 너무 많은 디렉토리들이 expand되어서 필요한 디렉토리를 찾는게 어려워진다. 이때 expand되어 있는 디렉토리중에, 직접 탐색기안에서 찾아서 들어간 경우가 있고, Go to Definition나 방금 닫은 창 다시 열기 등의 간접적인 방법으로 expand된 경우가 있다. 후자의 간접적인 방식으로 열린 파일이 닫혔을때 이로 인해 열린 디렉토리 중 전자의 방식으로 열리지 않은 것을 자동으로 닫아줬으면 좋겠다. 일종의 가비지 컬렉트?

...인데 https://github.com/microsoft/vscode/issues/150869 똑같은 제안이 있었는데 업보트가 부족해서 나가리됐구나ㅠ

PvE 중심 MMO 게임의 지속가능성 https://blog.woojinkim.org/sustainability-in-pve-focused-mmos/

개인 홈페이지 플랫폼 나루를 오픈 소스로 공개했습니다.

Next.js, Rust, CodeMirror 등으로 만들었고, 서비스 지표도 공개되어 있습니다.

많은 관심 부탁드립니다!

오늘 발견한 흥미로운 링크들: Matt 타입스크립트 선생님은 종종 Effect 에 대해 트윗하는데 주로 이펙트를 찍먹해보시고 이걸 강의로 만들까말까 만들까말까 하신다. Michael EffectTS 의 BDFL 은 종종 맷 선생의 트윗에 답글을 달아 이펙트 얘기를 풍부하게 가꿔주신다.

오늘은 이펙트의 굿파츠에 대한 얘기로 스레드가 열렸다. https://x.com/mattpocockuk/status/1936083553483157714

나도 EffectTS 도입을 하고 싶지만 여러모로 기존 바닐라JS 스펙과 다른 모양의 코드가 나와서 여러모로 망설이고 있다. (내 기준 이펙트는 실행 코드를 작성하기 보다 실행 계획을 작성하는 개념으로 접근하고 있다) 프로덕션 코드를 새로 만든다면 EffectTS 도입을 고려하고 있지만 학습 난의도가 있어 이를 위해 함께 스터디하고 코드 마이그레이션 계획도 세워야하는데, 그럴 여유는 보통 없는게 현실.

아직은 neverthrow 부터 사용해보는 정도가 지금의 최선이라고 생각한다. 나는 throw 기반의 조건 제어 코드가 불편하다. try catch 안에서 if 절로 throw 하는 코드를 볼 때마다 불만이다. 복구할 수 있는 에러는 throw 하지 않는게 옳다고 생각한다. 물론 언어의 문제도 있지만... 그렇게 스레드를 읽던 중 effectively 라는 애매한 이름의 Alegbraic effects 를 구현한 라이브러리가 공개되어 있다는 것을 발견했다. 작성자 본인도 뻔뻔하게 홍보한다고 어필하고 있다. ;) effectively

EffectTS 라는 이름도 애매하지만 Effectively 는 더 애매하다. 인기가 많아지기 전에 그럴듯 한 이름으로 브랜딩되면 좋겠다. 아, 그렇게 생각하는 이유는 TS 씬에 이런 라이브러리/프레임워크가 자주 거론되면 좋겠다는 생각 때문이다.

얘기하고 싶은 것은, 아이러니하게 이 effectively 의 readme 가 매우 간결하고 읽기 쉽게 EffectTS 에 대해 소개하고 있기 때문이다. effect.website 의 문서는 뭔가 개선이 필요하다. 없는게 없이 다 있지만 실제 읽다보면 어려운 부분이 많고 더 많은 설명이나 예제가 필요한 경우가 생긴다. 미카엘 본인도 문서 개선 필요는 공감하는 것 같다. (해당 스레드 발언 추정) 그리고 또 다른 유저가 포스트를 안내해주셨는데, Effect-like code without Effect 짧게 읽기 좋다. 게다가 이 포스트가 담긴 사이트의 프로덕트도 유용해 보인다.

시작부터 Result 나 Optional 을 제공하는 언어가 많은 소프트웨어 엔지니어들에게 높은 선호도를 가지는 이유가 있다고 본다.

@d01c2Hyunjoon Kim 네네 fp-ts같은걸 말씀드린거였습니다. 좀더 정확힌 HKT가 아니고 HKD네요. HKD를 활용하면 AST를 다루는 로직을 더 잘 짤수 있어서 여부 저도 요즘 공부중입니다.

@d01c2Hyunjoon Kim 1. ADT 지원 여부 2. HKT 지원 여부 3. (장난감 언어 개발이 아닌 툴링도 제대로 다 만드는 시도에서) tree-sitter 바인딩 유무

1 >> 3 >> 2 정도로 중요한거 같네요. 러스트는 1, 3이 있어서 부럽고 하스켈엔 3이 없어서 제가 야크셰이빙하는 중입니다. 타스에 스테로이드 먹이면 1, 2, 3 다 되지 않나요?

내가 Git 쓰다가 왕대빵 커밋 똥히스토리 남기는 전형적인 패턴이다.

1. 간단한 기능 A를 추가하려고 한다.
2. A를 추가하려면 기존의 설계 B를 고쳐야한단걸 깨닫는다.
3. B를 고친다.
4. A를 추가한다.

이렇게 3, 4의 변경이 한데 들어가 있는 무근본 커밋이 탄생한다. 2 -> 3 사이에 stash를 하면 간단히 해결되는 문젠데 매번 까먹고 실천을 못한다.

Nginx의 njs에 QuickJS 엔진 추가되니 기능이나 문법 제약도 거의 없어서 출근해서 해볼 성능 테스트만 제대로 되면 좀 복잡한 로직 필요한 리버스 프록시는 이걸로만 짤거같음. JS모듈들 대충 번들로 만들고 import해서 다 쓸수 있어서...

Claude Code한테 거의 전적으로 맡겨서 LogTape 웹사이트 첫 페이지를 갈아 엎었다. 디자인 측면에서는 바뀐 게 별로 없지만, 내용을 거의 다시 썼다.