오! 클로드 코드 사용량을 잠자는 동안 사용하지 못하는게 아까워서 이슈 7개 정도를 잠자기전에 일단 돌려두고 커밋까지 하라고 시켜놨다. 아침에 일어나서 워크트리에 커밋되어있는거 하나씩 머지하면서 테스트하고 코드 리뷰하고 있는데 엄청 좋은것 같다?!

container use를 써봐야겠다

근데 이전에 HN에서 codex가 뭔가 복잡하고 길게 해야하는 일을 더 잘 수행한다고 올린 글 때문에 테스트를 진행해본거라... 오히려 codex는 중간중간에 안껴들어도 일을 잘하고 claude code는 중간에 껴들어야 일을 잘하게되는 차이가 생길 수 도 있음.

이렇게 되면 병렬로 여러 일을 시키기에 codex가 더 적합할 수 도 있겠다는 가정을 해봄. 그래도 claude code가 결국 편할것 같은건 요즘 코딩하면서 테스트해본 결과 내 머리로는 최대 3개 이상의 작업을 동시에 병렬로 진행하는게 부하가 있음. 그래서 간단한 작업들 claude code web처럼 샌드박스에서 자동으로 돌려두는걸 codex로 해두고 내가 직접 상호작용하는 제품은 claude code를 사용하게 되지 않을까 싶음…

물론 어려운 작업들에서 작업 퀄리티 차이가 눈에 보일만큼 크다면 또 다르겠지만...

나중에 더 써보고 후기를 남겨보겠습니다.

codex에 비해서 claude code가 엄청 빠르다고 느꼈는데, 녹화해서 동시에 보면서 분석해봤는데 흥미롭다. gpt API 응답 속도나 claude API 응답 속도가 비슷했던 경험 때문에 인지 편향이 생겼을거라고 가정하고 녹화했다.

아주 간단한 테스트를 통해서 알게된 사실은 UX에서 오는 체감이 있는듯함. 동일한 코드베이스, 일, 프롬프트로 진행했는데 모든 일을 끝마치는데 걸린 속도는 비슷했음.

1. 다만 Claude Code는 TODO 리스트를 통해서 일감 관리되고 있는 상호작용을 눈으로 확인할 수 있음
2. 각 TODO 리스트가 끝났을때 중간 결과 같은것을 바로 알려줌
3. 이 중간 결과를 보고 다음 명령어를 큐잉하게 되니 실질적으로 일 진행이 더 빠른 "느낌"을 받게됨.

두 제품 다 중간에 끼어들어서 일 방향을 수정하거나 일감을 큐잉하는등의 액션은 수행할 수 있는 것처럼 보여서 중간 결과를 알 수 있는게 복잡한 일을 하면 할 수록 큰 차이를 만들 수 있을것이라고 생각함.

이런 차이라면 학습하지 못한 자료에서 수행해야하는 일을 할때 조금 더 유의미한 차이가 생길것 같은데 나중에 테스트 해봐야겠다.

Sharing the slides from my talk, Embracing yak shaving, which I presented today at the @fossforall Conference 2025! Thanks to everyone who came to listen!

🚀 FOSS for All Conference 2025

The conference has started!
A joyful start for open source.

오픈소스를 위한 즐거운 시작,
포스포올 컨퍼런스 2025가 드디어 막을 올렸습니다.

#FOSSforAll #포스포올
#OpenSource #Conference

오늘 @fossforall 컨퍼런스 2025에서 發表(발표)한 〈야크 셰이빙: 새로운 오픈 소스의 原動力(원동력)〉의 슬라이드를 共有(공유)합니다! 들어주신 분들 모두 感謝(감사)합니다!

저희팀도 비슷한 문제 때문에 polar, peddle 같은 Merchant of Record 서비스 사용하긴 했습니다 ㅜ

오! 좋은 아이디어 인것 같습니다. 조금 찾아보니 git-branchless나 jj-vcs로 활용해서 AGENTS.md나 스킬에 정의해서시도해봐도 괜찮을듯한 느낌이네요

안그래도 오늘 스킬을 이제 좀 써볼까 싶어서 어떻게 하면 더 잘 agents나 skill을 쓸 수 있지라는 고민을 하고 있었는데 이 글을 발견.

넘모 유용하다. 심지어 이 모든 정수를 담은 리포지토리도 열려있음. 존경스럽네.

@hongminhee洪 民憙 (Hong Minhee) 혹시 protobuf보다 지금 사용하시는 주로 사용하시는 pothos 기반 GraphQL로 결정하신 이유가 있으신가요?!

아무래도 대 LLM 시대에 스키마 지향적인 삶을 살아야한다고 생각이 듦과 동시에 원래 사용하던 protobuf 외에도 trpc와 graphql 모두 검토를 진행중. 백엔드, 프론트엔드간 필드 마이그레이션 문제는 결국 다 필연적으로 마주치게되는 것 같고 어떤식으로 해결하거나 감내할것인지 결정하는게 중요할것 같다.

git worktree로 작업하고 변경 사항 가지고 오려고하면 같은 로컬 머신에 디렉토리에 있는 변경사항인데 remote 리포지토리까지 거쳐야하는게 참 멀리 돌아온다! 라는 생각을 하다가 worktree 작동 특성상 걍 git 명령어로 cherry pick 혹은 switch가 되어야하지 않을까 싶어서 써보니 잘된다.

역시 설명서를 잘 읽어야…

이거 프로젝트 여러개 셋업하니까 귀찮아서 리포 하나 만들었습니다.

@iamuhun김무훈 연휴 때문에 이제서야 봤네요 ㅋㅋㅋ 반갑습니다! 잘지내시죠?

이 문제로 다시 zed를 켰습니다 ^오^!

@kanghyojun강효준 하지만 --dangerously-skip-permissions이 되지 않았다고 한다...

오 한국어 버그 있음. (끝글자 한번 더 입력됨)

zed를 잠깐 테스트 중이엇는데 소넷 4.5 나오면서 코드 네이티브 확장이 나왔네… 다시 돌아가야겠다

sc2ts 구현 과정에서 결국 claude 구독을 pro에서 max로 변경도 해봤고, max 5시간 usage도 다 채워봤는데요. 그만큼 많이 익숙해져서 좋습니다.

SC2TS: TypeScript로 포팅한 스타크래프트 2 리플레이 파서

SC2TS를 공개했습니다. 처음에는 Claude Code를 공부하기 위한 연습 프로젝트로 시작했던 작업이었습니다.

왜 TypeScript로 포팅했을까요?

여러 이유가 있었지만, 크게 다섯 가지 이유로 정리할 수 있습니다.

첫째, 충분히 흥미로운 프로젝트여야 했습니다. 끝까지 완성할 수 있는 동기부여가 필요했는데, 이 프로젝트는 그럴 만한 가치가 있다고 판단했습니다.

둘째, 이미 관련 경험이 있었습니다. 예전에 Blizzard의 공식 라이브러리인 s2protocol에 Pull Request를 보내본 적이 있어서, 프로젝트의 구조와 동작 방식에 어느 정도 익숙했습니다.

셋째, 선례가 있었습니다. 이미 Go 언어로 포팅된 버전이 존재했기 때문에, TypeScript로도 충분히 구현 가능하다는 확신이 있었습니다.

넷째, 적절한 난이도였습니다. 내부 구현을 세세하게 다 알고 있지는 않았지만, 충분히 복잡하면서도 AI의 도움을 받아 해결할 수 있는 수준이라고 판단했습니다.

다섯째, 그리고 가장 중요한 이유는 스타크래프트 2 관련 분석 사이트를 AI 기능과 함께 만들어보고 싶었는데, 기존 s2protocol이 더 이상 공식 지원을 받지 못하게 되었기 때문입니다. 이 문제를 해결하기 위해서는 직접 TypeScript 버전을 만드는 것이 최선의 선택이었습니다.

사실 이러나 저러나.. 중간에 잠깐 휴가도 있었어서 생각보다는 오래걸렸네요.

요즘 리모트 서버에서 코딩을 하고 있는데, 클로드 코드 돌려두고 자꾸 멍때리게 되어서 디스코드 알람을 만들었다

@hongminhee洪 民憙 (Hong Minhee) @TuringAppleDev튜링의 사과 오 이제 스위치도 교체하시면서 쓰시나요 ㅋㅋㅋㅋ

클로드 코드는 에이전트를 에디터나 IDE 독립적으로 쓸 수 있어서 편하긴했지만, 제드 같은 에디터에 클로드 코드 에디터 통합 같은 기능을 써보니 또 그건 그거대로 예뻐서 편했다. 제드가 ssh를 통한 리모트 개발이 좀 더 수월했으면 코드가 아니라 제드를 메인 에디터로 썼을 것 같다.

@hongminhee洪 民憙 (Hong Minhee) 님의 추천으로 클로드 코드를 쓰고나서 결국 커서 구독을 해지했다. 깃헙 코파일럿의 에이전트보다도 커서의 에이전트가 플래닝을 못한다는건 알고 있었는데, 클로드 코드는 그것보다 몇단계는 더 잘한다는 느낌이다. 그렇다보니 점점 탭 컴플리션을 안쓰게 되어서, 코드로 충분하다는 생각.