@hongminhee洪 民憙 (Hong Minhee) 오 감사합니다. 참고하겠습니다.

LLM을 이용한 코딩에 대한 생각이 최근 몇달간 많이 바뀌었는데, 사실 영향의 40% 정도는 아민 로나커의 트윗들에서 받은 것 같다. 오늘 보니 유튜브 비디오들도 올리는 것 같아서 이번 주에 한번 잘 살펴볼 예정. https://www.youtube.com/watch?v=Y4_YYrIKLac

내가 할 수 있는 개발자로서 제일 중요한 조언이라면, '느낌에 의존하는 것들을 최대한 빨리 제거하라' 정도인 것 같다.

특히 이건 지금 시대에는 더더욱 중요하다. 뭐든 prompt를 해야하니깐

프론트엔드 일자리가 너무 없다........ 나도 이직 좀....

Javascript/Typescript 생태계에는 소스코드 간 의존관계를 유향그래프(Direct Graph)로 시각화하는 CLI 도구가 있다는 사실... 알고 계신가요? madge, 적극적으로 추천합니다.

그냥 JS/TS 프로젝트 뿐만이 아니라, jsx 파일이 들어간 경우도 의존관계를 아름답게 시각화해줍니다. fedify 소스코드 통독하면서 이걸 적극적으로 써볼까 합니다. 마치.... 탐정이 사건 추적하면서 지도에 X 표시하는 감성으로...

바이브코딩 자체는 대세가 되어가는데 그에 반해 바이브코딩을 사람들이 어떻게 하는지에 대한 공유는 (한국에선) 잘 이뤄지진 않는 것 같다. 주로 AI 가즈아, 개발자들 니들 이제 큰일났다ㅜ 이런 얘기만 가득

슬프게도 한국의 일정이상 연차 FE 인재들은 두개의 대타트업들이 다 빨아간 것으로 판단이 된다.

이전에 다녔던 회사들에서 채용이 무너지면 회사도 무너지는 것들을 몇번 경험해서 채용에 상당히 신중한 편인데, 신중하게 뽑은 분은 역시 모셔오기 어려웠다. 그야말로 양극화의 시대다.

평소에 하고 다니는 이야기와 비슷한 것 같다. 물론 나는 기대치가 낮아서 디자이너들이 따라줄 것을 기대하지는 않는다.

(트위터에 버릇처럼 글을 썼다가 여기 계정이 있다는 것을 생각하고.. 다음부턴 개발 관련 끄적임은 좀 의식적으로 여기에 써보기로..)

https://gpui.rs 는 zed 의 UI framework 인데, 이거 기반으로 desktop ui 프로젝트 시도도 있는듯. https://github.com/longbridge/gpui-component https://longbridge.com/desktop/ zed 가 지금은 한글 입출력이 좋은 것 처럼, iced, egui 에 비해 한글 입출력도 좋을거라 생각. 그나저나 longbridge 는 홍콩 회사인 것 같은데 gpui 를 굳이 저정도로(?) 썼다. 물론 이런 작업 굳이 한 쪽으로는 iced 개발자가 있는 cryptowatch 도 있긴 하다 (kraken 에 인수인데 desktop app 이 rust + iced)

egui 의 경우 사실 https://github.com/topki0325/egui-chinese-font/blob/ce80cb38b4d12e2542a6be2ddbaf5ca213e88a31/src/lib.rs#L126 폰트 문제에 가까운 것 같긴 함 (저 경로에 대해 걍 산돌고딕 폰트 경로 잡아주면 한글 출력도 되고 입력도 됨)

Gemini CLI가 미쳐 날뛰기 시작했다…

@hongminhee洪 民憙 (Hong Minhee) 굉장히 많은 사람들이 비슷한 이야기를 해 주셔서 아무래도 결제를 해보게 될 것 같네요 😂

회사에서 커서를 쓰고 있는데 물론 tab completion은 무척 만족스럽긴 하다. 근데 agent로 가면 솔직히 뭘 잘하는 게 없다. 나는 진짜 바이브-코딩이 하고 싶은 것인데.

클로드 코드 쓰는 사람들이 다 100달러 이상 플랜을 쓰라고 하니 현혹이 되는구만

전부터 했던 생각인데, 저장소를 fork해서 계속 track하면서 특정 override만 계속 적용시켜주는 (커밋과 별개로) 그런 시스템을 만드는 건 어려울까 git 기반이라 하면 조금 난해할 것 같은데 (어느 시점에선 컨플릭트가 날테니) LLM 기반이라면 가능할 것 같다

아무래도 프론트엔드 개발자들은 어느정도 괜찮은 후보자군에서는 '회사원' 스타일의 분과 '해커' 스타일의 분들로 스펙트럼이 나뉘어지는데, 계속 면접과 스크리닝을 진행하다 보니 채용기조가 둘 다 적당히 잘 하는 수준으론 안되고, '정말 뛰어난 뭔가'가 있어야 한다는 분위기로 점점 바뀌었다. (그 criteria가 무엇인지는 여기에도 쓰기가 조금 곤란해서 쓰지는 않겠지만) 나중에 가서는 스크리닝할 이력서가 거의 떨어지는 상황이 됐는데 운이 좋게 지원해주신 분 덕에 성공적으로 채용 여정을 마칠 수 있었다.

하지만 한편으로는 이게 대다수의 회사들이 현재 경험하고 있는 채용 이슈와 다르지 않을 것 같아 크게 씁쓸함을 느꼈다. 나도 경력이 적지 않은 개발자고 나름대로 회사일로 이룬 것도 많은 편인데, 채용 시장에 나를 뚝 떨어뜨려 놓으면 쏙 집어갈만큼 매력이 있을까? 하는 생각이 드는 것이다. 스크리닝을 하면서 보면 이미 6개월 이상 구직을 하시는 분들이 많이 보였다. 어짜피 갈 곳도 별로 없는 한국에서 회사가 조금 맘에 안 든다고 이직을 하기는 그다지 어려운 시대가 왔다.

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

@oilpaintingkim 저라면 인턴 경험보다는 첫번째 회사에서 경험을 쌓은 것을 기반으로 이직을 고려해 볼 것 같아요.

회사에서 AI 도입 드라이브가 강한데 솔직히 하나만 했으면 좋겠다는 생각이 든다. 기존의 방식으로 일하는 것을 그만두든지 AI를 신경쓰지 말든지. 두개를 애매하게 다 하려니까 가랑이가 찢어진다.

오늘 발견한 흥미로운 링크들: 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 을 제공하는 언어가 많은 소프트웨어 엔지니어들에게 높은 선호도를 가지는 이유가 있다고 본다.

Existential Lens란걸 알게되었는데 정의는 다음과 같다

data Lens s a = forall c. Lens (s -> (c, a)) ((c, a) -> s)

돌무식 렌즈(get, set 레코드)보다는 좀더 어렵지만 Van Laarhoven Lens보다는 훨씬 더 직관적이라서 렌즈의 이해에 도움이 많이 되었다.

전체 설명은 요깄다.

나같이 LLM에 skeptic하지만 활용은 해보려고 하는 개발자 모임 같은 거 없나

"For comparison, Python — my initial choice — often poses significant challenges.[...]" 십년 전엔 누가 '머신 리더블 언어'를 찾게 될 줄 알았겠는가, (누군가는 예상했겠지만...)

모두가 AI 얘기를 하는 거 보면 AI가 거대한 흐름이긴 한가보다. https://lucumr.pocoo.org/2025/6/12/agentic-coding/ 개인적으로는 (가치를 가져다줄지 모를 일에) 돈을 쓰고 싶지는 않은 구두쇠라서 조금 망설여지긴 하는데 Claude MAX든 Pro든 곧 결제를 할 것 같다.

오늘 @xiniha 님 소환해서 배운 것:

• SolidStart 기본적인 사용법
• SolidStart 위에서 GraphQL 질의해서 결과 갖다 쓰는 법
• GraphQL + Relay에서 커넥션에 추가 필드 끼워넣는 법
• SolidStart에서 shadcn/ui…가 아니라 solid-ui 쓰는 법

그리고 배운 건 아니고 그냥 @xiniha 님이 다 해주신 것:

• Lingui를 이용한 국제화 세팅
• Deno를 쓰기 때문에 생기는 온갖 트러블들 해결

이제 이 새로운 스택으로 Hackers' Pub을 재구현하기만 하면 된다…! 다행히 도메인 모델은 분리되어 있어서, UI 위주로 재작성하면 될 것 같다.

The abbreviation #a11y itself is not very accessible. #accessibility

왔습니다(?)