디버깅을 하다가 도저히 모르겠어서 Gemini한테 시켜서 해보라고했는데, 걔도 나랑 똑같은 시도를 한다음에 잘 모르겠다고 하니까 덤앤더머같다;;
bgl gwyng
@bgl@hackers.pub · 92 following · 116 followers
GitHub- @bglgwyng
Parse, don’t validate는 언제 읽어도 좋은 글이다 https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
거의 반은 내가 기여했네 ㅎㅎ
@fedify/fedify: Custom Collection 디스패처 setter@fedify/cli:webfinger커맨드@fedify/next: 패키지 제작 및 예제 생성@fedify/sveltekit: 패키지 분리, 타입 수정 및 예제 생성@fedify/cfworkers,@fedify/denokv,@fedify/hono: 패키지 분리
GraphQL에는 어째서 ADT가 없을까…?
@hongminhee洪 民憙 (Hong Minhee) union + type 쓰면 비슷하게 되지 않나요?
Zed Industries가 코드 에디터와 코딩 에이전트 사이의 통신을 표준화하기 위해 Agent Client Protocol (ACP)이라는 걸 소개했다. 잘 돼서 Neovim의 AI 통합 생태계가 더욱 풍성해지면 좋겠다. https://agentclientprotocol.com/overview/introduction
https://well-typed.com/blog/2025/08/standard-chartered-supports-haskell-ecosystem/
제일은행을 먹은 SC(Standard Chartered)가 하스켈 생태계에 돈을 보태겠다네요. SC가 하스켈을 프로덕트에 조금씩 쓰고 있다는 얘기는 들은 적 있는데... 뭐 얼마나 후원하는지는 자세히는 안나와 있습니다만, 대기업 돈이 들어오면, 긍부정적 변화가 생기긴 하는데.. 툴체인이 정돈된다든지 해서 입문자한테 도움이 되는 변화가 생기면 좋겠습니다. 하스켈을 JS로 트랜스파일링 하는 컴파일러도 있는데, 막상 쓰려고 보면, 난이도가 너무 높아요.
#Optique 0.3.0 is out with dependent options and flexible parser composition, shaped by feedback from 
@z9mb1wwj's work migrating 
Nix는 시스템에 git이 있을 때와 없을 때의 동작이 다르다. 왜지... nix 내부에서 쓰는 git 라이브러리랑 git 패키지랑 뭔가 차이가 있나.
@nyeongAn Nyeong (安寧) 어떻게 다르죠? 저도 언젠가 밟을거 같아 미리 알아두고 싶네요.
결국 SvelteKit용 자체 GraphQL 클라이언트를 만드는 중... (relay-runtime 기반이지만)
지난 한달동안 개인적 이유로 코딩을 도저히 할수없는 상태로 지냈는데, 이제 좀 회복이 된거 같다..
bgl gwyng shared the below article:
React - useCallback & useMemo Misuse
Shahar Amir @shaharamir@hackers.pub
The `useCallback` and `useMemo` hooks in React are designed to optimize performance by memoizing functions and values, but using them indiscriminately can lead to unnecessary overhead. These hooks are beneficial when dealing with expensive calculations or when passing stable references to deeply nested child components. However, for simple operations like basic arithmetic or simple function declarations, the memoization provided by these hooks adds complexity without any performance gain. Overusing `useMemo` and `useCallback` introduces extra CPU cycles and can confuse developers, making the code harder to maintain. It's more efficient to apply these hooks selectively, focusing only on the parts of your application where they provide a tangible benefit, ensuring that React remains fast and your code stays clean.
Read more →I'm currently improving Optique's façade API, and in the process, I've added a few more parsers. Optique 0.3.0 might have some breaking changes on the API side. Of course, these changes will be thoroughly documented in the changelog.
Excited to share some great news from the #creative community! Oeee Cafe, a fantastic oekaki #drawing platform, just added #ActivityPub support today. This means all the amazing artwork being created there can now be shared and discovered across the #fediverse, which is such a wonderful step toward connecting creative communities.
Big shoutout to my friend 
@jihyeokJihyeok Seo for building this platform and bringing it to the fediverse. It's always inspiring to see developers creating spaces for artists and then opening them up to the broader federated community. If you're into digital art or just appreciate seeing creative work, definitely worth checking out what people are sharing from Oeee Cafe on your timeline now. You can find me there at @hongminhee洪兔 if you want to connect!
Hackers' Public @ Seoul 1회차 모임 (1차 모집)
서울에서 열리는 Hackers' Pub 오프라인 밋업, "Hackers' Public @ Seoul"이 2025월 9월 14일(일) 처음으로 개최됩니다. 처음 열리는 밋업인 만큼, 참여하는 많은 분들이 재밌게 느낄 수 있는 소재 위주로 연사자 분들을 섭외했습니다.
- 일시 : 9월 14일 (일) 오후 3시 ~ 오후 6시
- 장소 : 서울특별시 성동구 상원길 26, 튜링의사과
- 주제
강연이 끝나고 난 뒤에 자유롭게 네트워킹하는 시간을 가질 예정입니다. 각자 얘기하고 싶은 주제를 들고 오시면 좋습니다.
참여 신청
오프라인 밋업은 여기서 참여신청이 가능합니다. https://event-us.kr/hackerspubseoul/event/110961
- 모집 기간
- 1차 모집 : 8월 27일 ~ 9월 1일 (Hackers' Pub에서만 모집)
- 2차 모집 : 9월 3일 ~ 9월 7일 (Hackers' Pub 외부에서도 공개적으로 모집)
주의사항
- 본 행사는 Hackers' Pub에서 진행하는 오프라인 행사이며, Hackers' Pub 계정을 가지지 않은 분이 신청하셨을 경우 환불처리될 수 있습니다.
- Hackers' Pub 외부에서 유입하시는 경우, 각 모집기간이 끝나고 24시간 안에는 Hackers' Pub에 가입이 되어 있으셔야 참여자로 확정됩니다.
Hackers' Pub은 현재 Fresh 프레임워크로 만들어져 있는데, Fresh 프레임워크의 한계를 벗어나기 위해 GraphQL + SolidStart 스택으로 넘어가는 작업(web-next)을 진행중입니다. 진행 상황을 관리하기 위해 에픽 이슈를 만들었습니다.
이번 FEConf 연사로 "모두를 위한 웹 접근성은 무엇이고, 어떻게 하나요? 💬 🔉" 웹 접근성의 가치와 실천 방법론에 대해 말했습니다.
제가 있는 A11YKR 커뮤니티의 자문으로 주어진 2개월 동안 알찬 자료를 만들어낼 수 있어 정말 감사했습니다. cc 
만약 페디버스가 지금보다 훨씬 활성화되어서, 사람들이 커스터마이징된 개성있는 인스턴스를 갖게 되면, 그게 UX의 측면에서 정말로 좋을까요? 가령, 트위터를 하는데 사용자마다 UI가 다르다고 상상해보세요.
사실 저는 크게 부정적이진 않는데(좋은 쪽으로 개성있을수도 있으니까), 그런 상황이 머릿속에서 아주 잘 시뮬레이션 되지 않네요. 어떨거 같나요?
Vim에 관심있는, 혹은 Vim을 사랑하는 여러분, 안녕하세요.
한국어권 Vim 사용자 모임 vim.kr입니다. 오늘은 vim.kr에서 공식적으로 주최하는 모임 소식을 전해드리려 합니다.
혹시 *빔교정학원 모임(vimrc)*을 들어보신 적 있으신가요? vimrc 밋업은 2019년과 2022년에 3년 간격으로 개최된 바 있는데, 2025년부터는 저희 vim.kr이 그 바통을 이어받아 공식적으로 진행하게 되었습니다.
지난 7월 2일, 기존 vimrc 밋업을 주최하셨던 박현우(lqez)님께 연락을 드렸고, 이어 7월 6일 첫 회의를 통해 vim.kr에서 본 행사를 이어가기로 확정하였습니다.
이번 vimrc 밋업은 이전과는 조금 다른 방식으로 준비되고 있습니다. 특정 연사자가 발표하는 자리가 아니라, 모든 참가자가 동등한 입장에서 자신이 Vim을 어떻게 활용하는지 경험과 노하우를 공유하는 자리를 지향합니다. 즉, 발표 중심의 형식보다 네트워킹과 상호 교류에 초점을 맞춘 밋업입니다.
행사 규모는 약 36명으로 계획 중이며, 일정은 11월 둘째 주에서 셋째 주 사이로 조율하고 있습니다. 현재 대관 장소도 검토 중이니, 혹시 행사 장소 후원에 관심 있는 분이 계시다면 연락 부탁드립니다.
행사 관련 최신 소식은 vim.kr 디스코드를 통해 안내드릴 예정입니다.
많은 관심과 참여 부탁드립니다. 감사합니다.
日常에서 우리가 「知能」이라는 말을 써야만 하는 일은 그렇게 많지 않고, 그 말을 썼다면 程度의 差異가 있을 뿐 人種主義的 乃至는 優生學的으로 들리는 境遇가 많다고 느낀다.
FEConf 갈걸ㅠㅠㅠㅠ
# Ask Hackers Pub : 이번 주말에 뭐 하시나요?
이번 주말에 뭘 하려고 계획 중인지 편하게 얘기해 보아요.
읽을 책, 가볼 곳, 해볼 것.. 어떤 것이든 좋습니다.
도움 요청이나 피드백 요청도 좋습니다.
물론! 아무것도 하지 않고 쉬는 것도 훌륭합니다.
* 지난 주말에 계획하셨던 일의 회고도 한 번 남겨보면 좋을 것 같아요.
@botHackersPub Ask Bot conal 리팩토링하고 문서만들기!!!
오늘 튜사 오시는분 계신가요?
Open source projects I'm currently maintaining:
- Fedify, an ActivityPub server framework for TypeScript
- Hollo, an ActivityPub-enabled single-user microblogging software
- BotKit, an ActivityPub bot framework for TypeScript
- LogTape, a modern logging library for TypeScript
- Upyo, a simple and modern email sending library for TypeScript
- Optique, a type-safe combinatorial CLI parser for TypeScript
@hongminhee洪 民憙 (Hong Minhee) I admire your productivity.
단문(Note)과 긴 게시글(Article) 모두에서 Markdown을 지원할 뿐만 아니라 구문강조와 TeX 수식을 지원한다는 점에서 Hackers' Pub은 연합우주에서 가장 소프트웨어 프로그래머가 쓰기에 적합한 플랫폼이라고 자부합니다.
AI 에이전트와 도구를 결합하는 방법 중 하나인 "재귀적 신경신호 제어 역전(recursive neuro-symbolic IoC) 패턴"에 대해 정리했다. 이름이 너무 거창해서 마음에 쏙 들지는 않지만 정확한 명명이라서 그냥 그렇게 정했다. https://wiki.g15e.com/pages/Recursive Neuro-Symbloic Inversion of Control
Anthony Fu의 〈야크 셰이빙에 관해〉. 요즘 내 심정을 잘 대변하는 글 같다.
오늘은 오랜만에 Hackers' Pub의 web-next 작업. 프로필 설정 기능을 만들었다. Relay를 쓰니까 뮤테이션하고 나서 내가 딱히 뭘 하지 않아도 자동으로 상태가 업데이트된다!
@hongminhee洪 民憙 (Hong Minhee) 
@meWoojin Kim @hongminhee洪 民憙 (Hong Minhee)
bgl gwyng replied to the below article:
Optique: 타입 안전한 CLI 파서 컴비네이터
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글에서는 Haskell의 `optparse-applicative`와 TypeScript의 Zod에서 영감을 받아 제작된 새로운 CLI 파서 라이브러리인 Optique를 소개합니다. Optique는 파서 컴비네이터를 활용하여 CLI의 구조를 레고 블록처럼 조립할 수 있게 해줍니다. `option()`, `optional()`, `multiple()`, `or()`, `object()`, `constant()`, `command()`, `argument()` 등의 다양한 파서와 컴비네이터를 통해 복잡한 CLI 구조를 유연하게 정의할 수 있습니다. 특히, `or()`와 `object()` 컴비네이터를 사용하여 상호 배타적인 옵션이나 서브커맨드를 쉽게 구현하는 방법을 예제를 통해 설명합니다. Optique는 단순한 CLI 파서 역할에 집중하고 있어 모든 기능을 제공하지는 않지만, 복잡한 CLI 구조를 표현하는 데 유용하며, 소개 문서와 튜토리얼을 통해 더 자세한 내용을 확인할 수 있습니다.
Read more →@hongminhee洪 民憙 (Hong Minhee) optparse-applicative엔 여러 커맨드의 겹치는 인자를 처리하는데에 애로사항이 있잖아요? 그러니까 foo bar --baz=1과 foo qux --baz=1이 둘다 가능할때 baz를 필드로 갖는 레코드를 두개 만들어아야 하는 문제 말이에요. 근데 optique는 서브타이핑으로 이 문제를 좀더 잘 다룰수 있어 보이네요. 맞나요?
bgl gwyng shared the below article:
Optique: 타입 안전한 CLI 파서 컴비네이터
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
이 글에서는 Haskell의 `optparse-applicative`와 TypeScript의 Zod에서 영감을 받아 제작된 새로운 CLI 파서 라이브러리인 Optique를 소개합니다. Optique는 파서 컴비네이터를 활용하여 CLI의 구조를 레고 블록처럼 조립할 수 있게 해줍니다. `option()`, `optional()`, `multiple()`, `or()`, `object()`, `constant()`, `command()`, `argument()` 등의 다양한 파서와 컴비네이터를 통해 복잡한 CLI 구조를 유연하게 정의할 수 있습니다. 특히, `or()`와 `object()` 컴비네이터를 사용하여 상호 배타적인 옵션이나 서브커맨드를 쉽게 구현하는 방법을 예제를 통해 설명합니다. Optique는 단순한 CLI 파서 역할에 집중하고 있어 모든 기능을 제공하지는 않지만, 복잡한 CLI 구조를 표현하는 데 유용하며, 소개 문서와 튜토리얼을 통해 더 자세한 내용을 확인할 수 있습니다.
Read more →bgl gwyng shared the below article:
Par 언어 테스트 프레임워크 구현 -- Iterative Box Choice 패턴 적용
notJoon @joonnot@hackers.pub
Par 언어에 테스트 프레임워크를 구현하면서 `box choice` 타입의 소비 동작으로 인해 하나의 테스트 함수에서 여러 assertion을 처리하는 데 어려움을 겪었습니다. 기존 `box choice` 타입은 값을 한 번 사용하면 소비되어 재사용이 불가능했기 때문입니다. 이를 해결하기 위해 `iterative box choice` 타입을 도입하여 반복적인 사용이 가능하도록 개선했습니다. `iterative box choice` 타입은 `iterative`, `box`, `choice` 타입들을 조합하여 여러 번 사용 가능하고, 메서드 선택을 제공하며, 외부 구현과 연동할 수 있는 장점을 제공합니다. 새로운 타입 구조에 맞춰 테스트 실행 함수를 재귀적으로 수정하여 메서드 체이닝 방식과 순차적 명령문 방식 모두를 지원할 수 있게 되었습니다. 이로써 Par 언어는 더욱 유연하고 강력한 테스트 환경을 제공할 수 있게 되었습니다.
Read more →
블로깅의 쇠퇴, AI의 끝없는 학습, 비공개 플랫폼(Discord 등)으로의 이주, 짧고 중독성만을 강조하는 피드와 BM, 한 번 보면 다시 찾기도 힘든 SNS 포스트, 범람하는 가짜뉴스와 개소리와 혐오... 웹은 정보의 망망대해도 아닌 소행성대로 변해가고 있다.
CV 겸 개인 홈페이지였던 사이트를 아예 커스텀 블로그로 바꾸면서... 어제 슬쩍 홍보를 올렸는데요
Pelican으로 만들고 GitHub Pages로 배포를 했는데, 급하게 수정할게 있어서 추가 commit을 했더니 갑자기 README를 기반으로 한 디폴트 페이지로 바뀌었습니다;;;
그러니까 기존 배포 A, 리뉴얼 배포 B, hot-fix 배포 C 이렇게 세개가 있으면, C를 했는데 실패해서 (실패 원인: GitHub Action이 새벽에 일시적으로 불안정했음) 당연히 B가 나올줄 알았는데, A도 B도 아닌 README 기반의 만든적도 없는 배포 X가 나왔습니다... 왜였을까요...? Action 사용하기 이전 시절의 (Jekyll 등을 지원하던) GitHub Pages 빌드 방식이 남아있어서 뭔가 꼬였는지...
암튼 블로그 많이 놀러와주세요,,, 게임 추천으로 시작합니다 (포스트도 아니고 인덱스 페이지에서)
I wrote an op-ed on the world-class STEM research ecosystem in the United States, and how this ecosystem is now under attack on multiple fronts by the current administration: https://newsletter.ofthebrave.org/p/im-an-award-winning-mathematician
conal 리팩토링하면서 느끼는건데, 그래프 다루는 코드는 검증하는게 특히 어렵다. 특히 중요한 성질들을 타입으로 보장을 못해서 테스트와 assert 문으로 때우는수밖에 없다. 아마 하스켈로 했더라도 별반 다르지 않았을듯.
아... 이제서야 집 도착... FediDev KR 파이콘 부스를 지켜주셨던 
@akastoot악하 @z9mb1wwj 
@hongminhee洪 民憙 (Hong Minhee) 
@nebuletoHaze 등등등 고생 많으셨습니다...
If you find it unbearable to be around people with big egos, you might want to consider whether your own ego is the problem.
파이콘 한국 2025의 Hackers' Pub 및 FediDev KR 커뮤니티 부스가 성공적으로 마무리되었습니다. 모두 여러분 덕분입니다.
양일간 부스 지키느라 도와주신 분들께 모두 감사드립니다! @nebuletoHaze 
@kodingwarriorJaeyeol Lee @akastoot악하 @z9mb1wwj 
@gaebalgom개발곰 🙏🏼
개방형 오피스가 코딩의 생산성을 저하시키는 일종의 또 다른 ADHD 상태를 만든다는 글이 올라왔다. 이에 대해 어느 정도는 그럴 수 있지 하고 생각하면서도 많은 부분에 대해 동의하지 않는데... 사무실 내의 소리나 환경적 문제를 제외하면 Slack 등의 업무용 메신저나 메일 등의 알림은 집에서도 사무실에서도 똑같이 발생한다. 내가 업무 시간 중 일정 시간 안에 답하면 되는 것이기 때문에 알림 설정을 미리 해두지 않으면 결국 어디서 일하던간에 알림으로 인한 스트레스나 방해는 똑같이 받게 된다는 점이다. 또한 사무실 내의 다른 소리나 시각적 문제로 집중력을 떨어트릴 수 있다. 근데 이것도 잘 생각해보면 집에서도 가족이나 동거인, 키우는 동물 등이 있다면 똑같이 발생할 수 있는 문제가 아닐까.
결국은 어디에서 일하던간에 본인이 편안한 환경을 만들고 생산성을 유지하기 위한 환경을 조성하고 관리할 필요가 있다. 다만 이 글은 본인의 생산성을 환경에 따라 측정해서 자신만의 데이터를 뽑아낸게 굉장히 의미있다. 아마 제품의 홍보 목적도 겸하는 것이 되겠지만 말이다.
트리시터 grammar 처음 짜봤는데 생각보다 꽤나 쉽고 재밌었음! 다음엔 MDX 지원 만들어봐야지....
장안의 화제 〈파이썬토룡신점〉, 나도 쳐봤다!
해커스펍 500명 돌파 나이스~
bgl gwyng shared the below article:
파서 콤비네이터: 하스켈 초보자를 위한 파싱
박준규 @curry@hackers.pub
이 글은 하스켈 초보자를 위한 파서 컴비네이터에 대한 입문 튜토리얼입니다. 파싱은 프로그래밍에서 흔히 발생하는 작업이지만, 정규 표현식이나 문자열 조작만으로는 복잡한 형식을 다루기 어렵습니다. 저자는 `Text.ParserCombinators.ReadP` 라이브러리를 사용하여 파서 컴비네이터를 소개하고, 이를 통해 더 읽기 쉽고 유지보수가 용이한 파서를 작성할 수 있음을 보여줍니다. METAR 보고서 파싱 예제를 통해 `satisfy`, `many1`, `<|>`, `option` 등의 기본적인 파서 콤비네이터 함수를 설명하고, 펑터와 모나드의 개념을 활용하여 파서를 구성하는 방법을 안내합니다. 또한, 파싱된 데이터의 유효성을 검사하고, 결과를 더 의미 있는 데이터 타입으로 변환하는 방법을 제시합니다. 이 튜토리얼을 통해 독자는 파서 컴비네이터의 기본 원리를 이해하고, 실제 데이터 파싱 작업에 적용할 수 있는 능력을 얻게 됩니다. 마지막으로, 저자는 독자들에게 배운 내용을 바탕으로 전체 METAR 보고서를 파싱하는 라이브러리를 만들어 Hackage에 제출해 볼 것을 권장하며, 파서가 없는 데이터를 만났을 때 `ReadP`를 자신 있게 사용할 수 있기를 바랍니다.
Read more →내일 파이콘 현장 가서 명함 뿌릴거임 우하하하
이번에 Amazon SES 메일 발송 처리를 추가해야 해서, Upyo 를 써 볼 수 있는 좋은 기회가 왔습니다. (SMTP 연동이어도 써볼 생각이었지만...)
README.md 의 Caution 을 보니 조금은 조심스럽지만, 한번 써보겠습니다!
Caution
This project is in early development and subject to change without notice.
개인적인 소망으로 https://unstable.upyo.org/logo.svg 로고에 한글도 들어가면 더욱 더 이쁠 것 같습니다!
bgl gwyng shared the below article:
Rust 컴파일러 개발 관련 명령어 모음집
notJoon @joonnot@hackers.pub
이 글은 러스트 컴파일러에 기여할 때 자주 사용하는 명령어와 작업 흐름을 소개합니다. 기본적인 빌드 명령어부터 특정 컴포넌트만 빌드하는 방법, 테스트 실행 및 `--bless`, `--force-rerun` 플래그 활용법을 설명합니다. Stage 시스템(Stage 0, 1, 2)을 구분하여 각 Stage의 역할과 사용법을 안내하고, UI 테스트 작성 규칙과 에러 주석 문법을 상세히 다룹니다. 또한, 직접 컴파일러 실행, 디버그 어설션 활성화, 백트레이스 활성화 등 디버깅 명령어와 컴파일러 버그 수정 워크플로우를 예시와 함께 제시합니다. 마지막으로, 자주 발생하는 문제와 해결법, 빌드 시간 단축 방법, 디버깅용 환경 변수 설정까지 다루어 러스트 컴파일러 개발에 실질적인 도움을 제공합니다. 이 글을 통해 러스트 컴파일러 기여자들이 효율적으로 개발하고 디버깅하는 데 필요한 지식을 얻을 수 있습니다.
Read more →
LLM에게 코딩 시키기, 요즘 바이브 코딩이라 불리는 일을 해 봤다. 동기는, 리니어 공간에서의 이미지 리사이즈 작업이 ImageMagick 같은 전문? 툴 없이 파이썬 라이브러리로만으로 가능한가? 라는 호기심.
의외로, 알려진 알고리즘을 적용하라는 지시에는 LLM이 매우 효과적으로 대응했다. 정형화되어 있는 작업은 그게 조금? 전문적이라고 해도 찰떡 같이 알아듣고 탬플릿처럼 코드를 만들어냈다. 거대 LLM은 지식의 범위가 매우 넓다고 절감했다.
오히려 문제는 쉽다고 예측했던 색영역 프로필 처리에서 일어났다. 존재하지 않는 메소드들을 계속 있다고 하며 라이브러리 버전 문제라고 우겼다. 제미나이도, chatgpt도 동일했다. 해당 라이브러리 문서를 직접 찾아보니, LLM들이 가져온 오브젝트는 유저에게 노출되지 않은 내부 C 코드에 있는 것들이었다.; 오브젝트는 내부를, 메소드는 문서화 되어 있는 API의 것을 조합해서 코드를 만들어 낸 것이었다.
인간 개발자는, 자기 전문 영역이 아닌 한 라이브러리의 내부 코드까지는 잘 보지 않는다. 즉 API 문서를 기반으로 작업을 해 나간다. LLM은 정반대였다. 오픈소스 라이브러리라면, 오히려 문서보다도 외부 문서화되지 않은 소스 코드가 더 잘 학습 되는 자료였던 것이다. 그 과정에서 라이브러리의 전체 동작 과정을 잘 파악할 정도는 아니었기에 동작하지 않는 코드들을 계속 만들어 냈고.
매우 흥미로운 경험이었다. LLM은 인간과는 전혀 다른 학습, 구성 과정을 통해 코딩한다. 요구-설계-개념-문서-코드 라는 단계는 LLM에게는 의미가 없다. 프로그래머들은 이제 이세돌 이후 바둑 기사들이 겪었던 충격과 비슷한 변화를 나름? 받게 된 듯 하다.
드디어 Claude Code를 굴리고 손을 좀 많이 봐서(...) Solid Relay 문서를 좀 볼만하게 적어보았다
근데 내용 검수 제대로 안 한 부분도 있는데 대충 잘 되었겠거니 하고 있다....... 😇
오픈소스 처음 했을 때는 문서 기여를 해도 되는건지 긴가민가 했었는데, 시간이 지나서 생각해보니
- 방심하면 순식간에 outdated 됨
- 아무튼 결국 누군가는 해야 함
같은 이유 때문에 아주 중요한 기여인거 같음