Jaeyeol Lee
@kodingwarrior@hackers.pub · 694 following · 509 followers
Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.
Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.
그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중
Blog- kodingwarrior.github.io
mastodon- @kodingwarrior@silicon.moe
Github- @malkoG
Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.
내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.
-
신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.
-
GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)
-
바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput
물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.
인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.
GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.
Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.
@s3thr1n 안녕하세요!!
살았니!!
https://github.com/Aider-AI/aider/pull/3672
대박. Aider에서도 MCP 지원하려나보다
vim.kr 디스코드에도 물어보긴 했는데, 해커스펍에도 공개적으로 물어봅니다.
Git 관련 유틸리티 중에 이런거 없을까요?
개발된 기능들은 어지간하면 싹 다 Staging 브랜치에 합쳐서 개발망에 배포중인데, 개발망에 배포된 기능/버그픽스 중에 몇개 컨펌된 것만 프로덕션에 배포하고 싶어요. 커밋을 가능하면 잘게 쪼개서 하는 편이긴 한데, 컨펌된 것만 한땀한땀 골라서 체리픽하다보니까 관리하는게 여간 귀찮은게 아니네요. 오죽하면 스프레드시트로 관리할 정도입니다 -_-;;;
커밋 중 몇개는 서로 독립적이긴 한데, 몇개는 비엔나소세지마냥 줄줄이 의존성이 엮여있어요. 줄줄이 의존성이 엮여있긴해도, 가만히 보면 A기능 / B기능 잘개 쪼개져있긴 해서, 그걸 좀 더 보기좋게 시각화하고 싶어요. staging 브랜치에 PR 머지할때도 일부러 Squash and merge로 머지합니다.
한줄 요약
- 의도적으로 커밋 간의 연결관계를 디펜던시 그래프 형태로 가시화할 수 있는 Git 유틸리티 추천받습니다.
State of Vue 2025
https://www.monterail.com/stateofvue
Vue 프레임워크를 사용하는 온갖 회사들의 케이스스터디가 나열되어 있는데, 양이... 어마어마하다... 인터뷰 하나하나 읽어보는 재미가 있다. 저렇게 인터뷰할 수 있으면 좋겠다
https://elixir-lang.org/blog/2025/03/25/cyanview-elixir-case
수퍼볼 같은데서 수백대의 방송장비를 Elixir를 통해서 제어하고, Phoenix LiveView로 시각화하는 사례. Elixir 생태계에 Nerves라는 임베디드 시스템 제어 프레임워크가 있었던걸로 기억하고 있는데, 이게 이렇게 이어지는군아
뉴욕 어딘가에는 컴파일러/DB/웹브라우저 등등 인터널을 까보면서 얘기하는 소셜클럽이 있다. 완전 비슷하게는 아니더라도 해커스펍을 중심으로 밋업을 하는것도 괜찮을지도? 밋업에 참여하는 외부인이 오면 초대장도 그때그때 발급해주는식으로 가고
@allieuslee 안녕하세요! 여기서도 반갑습니다!
https://hackers.pub/@kodingwarrior/0195e565-deaa-7ab0-984f-1e6c065f0118
이거 관련해서 드는 생각.
리액션/북마크 기능이 추가된다면, 리액션/북마크가 많이 된 3~10개의 글을 내림차순으로 정렬해서 장문 아티클을 자동으로 발행하면 어떨까!?
트렌딩 / top 10 (week) / top 10 (month)
이런 봇들을 가입한 시점에 자동으로 팔로하게 한다던가!?
초대장 족보 40명 채움 캬캬
https://hackers.pub/@hn100@social.lansky.name/0195e756-0414-73e6-9234-c9af34cfeb27
Hey, Basecamp의 37Signals에서는 S3를 아예 안쓰고 자체 스토리지를 직접 구축한다는 내용...
팔로워 100명 찍으면 초대는 좀 소극적으로 하고 컨텐츠를 좀 더 적극적으로 채울거야!
@boltlessboltless.me 안녕하세요
Fedify BotKit으로 해커스펍 타임라인 만드는 것도 괜찮을 것 같다. 특정 기간 동안 리액션이 좋은 상위 N개의 아티클을 메뉴로 보는게 아니라, 봇을 구독하는 것으로 해결한다던가!?
살았나!?
내년쯤에 framework 랩톱 풀옵션으로 지를까 고민중... 지금 쓰는건 한정된 예산으로 최대한 쥐어짜내서 산거라 아쉬움이 남긴 하는데, 한 2년은 더 쓰고...
@maxwellEunsoo Eun 어 뭐야 어떻게 오신거에요
.vimrc 파일 공유하던사람들끼리 창업해서 CLI 깎는 회사 만들고 6백만달러를 펀딩받았다는 이야기가 있다. 나는 이 이야기를 아주 좋아한다.
한국의 Clojure 생태계를 책임지는 슈퍼루키 트친도 영입하고 있는 중인데, 이 계정도 추천해야겠다. 아니, 근데.. 클로져리안 모아놓은 인스턴스도 있었네????
코드 리뷰 요정, CodeRabbit이 나타났다 🐰 https://tech.inflab.com/20250303-introduce-coderabbit/
코드래빗에 저렇게 프롬프트를 넣을 수 있는거구나.....
https://choubey.gitbook.io/internals-of-deno
Deno 런타임 내부 까보는거 입문은 이걸로 시작해야겠다
@darkenpengpenguin 안녕하세요 반가워요
2025년도판 대안언어축제 가보자고
이제 파이썬 개발자 분들 물밀듯이 들어옵니다앗!!
Hackers' Pub에 글을 쓸만한게 뭐가 있을까 하고 생각해봤는데, 알고리즘 문제풀이 컨텐츠로 채우는것쯤은 금방금방 가능할 것 같지만 이런식의 양치기보다는 그래도 엑기스를 모아서 정제되어있는 형태의 글을 올리는게 나을 것 같아
Hackers Pub PWA 앱 만드는걸로도 한번 기여해보고 싶다
https://zenn.dev/shun_shobon/articles/173450f5bec890
웹어플리케이션 성능 개선하는 해커톤 같은 것도 있구나 와우
액펍의 특이점은... 왔다...!!
@cetaceanightskyCetacea 안녕하세요 반가워요
이제 타임라인 사람들 50명 정도 되는군아
과연 Lobsters는 호스팅 비용이 얼마나 나갈까?
찾았다. 내 글만 유독 해커스펍 성능이 느린 원인
https://hackers.pub/@hongminhee/2025/bluesky-a-good-alternative-to-x-not-to-the-fediverse 이 글이랑 https://hackers.pub/@kodingwarrior/2025/2025-q1-review 이 글이랑 로딩속도에 차이가 있음 뭐지???
Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다
최근 X(구 Twitter)를 떠나는 사용자들이 늘면서 Bluesky에 대한 관심이 높아지고 있습니다. Bluesky는 깔끔한 인터페이스와 과거 Twitter와 유사한 사용자 경험을 제공하며, '신뢰할 수 있는 이탈'이라는 매력적인 개념을 내세워 X의 유력한 대안으로 떠오르고 있습니다. 하지만 이 글에서는 Bluesky와 그 기반 프로토콜인 AT Protocol이 연합우주(fediverse)의 대안이 될 수 없는 이유를 설명합니다. Bluesky는 메시지 전달 방식 대신 공유 힙 방식을 사용하며, 이는 중앙 릴레이에 의존하게 만들어 탈중앙화의 이상과는 거리가 멀어집니다. 또한, 전역 뷰에 대한 집착은 차단 목록의 전체 공개와 같은 개인 정보 보호 문제를 야기하며, AT Protocol은 아직 특정 사기업에 의해 주도되고 있어 개방형 표준으로서의 한계를 가지고 있습니다. Bluesky는 이동 가능한 아이덴티티를 제공하지만, 여전히 중앙화된 요소에 의존하고 있으며, DM은 완전히 중앙화되어 있습니다. 결론적으로, Bluesky는 X의 훌륭한 대안이 될 수 있지만, 연합우주가 제공하는 탈중앙화된 가치와 경험을 대체하기는 어려울 것입니다. 이 글을 통해 Bluesky와 연합우주의 차이점을 명확히 이해하고, 자신에게 맞는 플랫폼을 선택하는 데 도움이 될 것입니다.
hackers.pub · Hackers' Pub
Link author: 
洪 民憙 (Hong Minhee)@hongminhee@hackers.pub
해커스펍! 계속 흥한다!
https://github.com/dahlia/hackerspub/pull/12
해커스펍의 멘션 기능에 가독성 개선이 필요할 것 같아서 제안하는 느낌으로 PR은 올렸는데, 다른 분들도 어떤 의견을 가지고 계실지 모르겠다
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
외부 인스턴스도 멘션이 되긴 하는군아
슬슬.... 계약도 끝이 보이고 해서 취업준비 모드로 들어가려고 하는데, 이미 꼬여버린 커리어니까 다시 새 출발한답시고 어떤 방향으로 진로를 잡을지 생각중이다. 당장은 웹개발 쪽으로 가는걸 지향하는데? 백/프론트 둘 다 해본 입장에서 백엔드로 갈지 프론트엔드로 갈지 애매한 입장이다. MLOps나 DevOps도 열려있긴 하다. 사실 다 찍먹해볼 수 있는 인공지능 잘 쓰는 회사에서 일하게 된다면 정말 좋을 것 같다.
취준 공부 전략은.... 당장 내가 써먹을 수 있는 방향으로 전이될 수 있는 방향으로 가는 것이 좋을 것 같다. 인공지능에 관심이 생기긴 했으니, 통계나 ML 관련 지식은 어느 정도 감잡을 정도로 곁다리로 공부는 할 것 같다. 메인 분야를 하나 잡고 준비하는게 베스트이긴 한데, 준비할 수 있는 시간은 많으니 메인 분야는 프론트엔드로 잡고 가지 않을까 싶다. 돈이 되는 개발을 하려면 프론트엔드로 가는게 맞더라는게 이리 구르고 저리 구르다가 내린 결론이다.
뭐부터 공부할지 우선순위 정하는 것도 역시 나한테 당장 도움이 되고 바로 써먹을 수 있는 것들 중심으로 가중치를 매겨야 할텐데, 소프트웨어 설계 전략, 추상화, 시스템 디자인, javascript 런타임, 웹 퍼포먼스 등등 주제는 다양하게 있고, roadmap.sh에서도 몇가지 키워드를 주워담고 있다. 지금 밥벌이하는 동안에는 프론트엔드가 중심인 풀스택의 관점에서 접근하게 될 것 같다. 풀스택이 힘든길이 되겠지만... 전반적인 사이클 한바퀴 돌리고 개발하는게 익숙하다.
개인 프로젝트를 만들면서 포폴을 만들어나갈 것 같은데, 밀어붙이고 싶은 스택은 Django/Vue/Flutter 정도? 사실은 어떤 스택이든 상관은 없다. 먹고사니즘을 위해서라면 뭐라도 해야지... 내가 좋아하는 것을 깊게 팔 수 있으면 베스트지만, 상황이 따라주지 않는다면 그냥 하던거나 깊게하면서 내가 좋아하는 기술에 지식이 전이될 수 있는 방향으로 깊게 파볼까 싶다.