Profile img

Jaeyeol Lee

@kodingwarrior@hackers.pub · 637 following · 464 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

추석 연휴(10월 중순) 지나면 동시에 해야하는거

  • 이력서 돌리기
  • 외주 다시 시작
  • OSSCA 프로젝트 마무리 짓기 (연휴 기간에는 영혼갈아넣어서 완성도 높일거임)
  • MT? 워크샵? 아무튼 기획
  • Hackers Pub 두번째 모임 기획
  • vimrc 모임 기획
  • 밀린 커피챗

전부 11월까지는 끝내야함....

갑갑하구만..

3

Jaeyeol Lee shared the below article:

'블루스카이즘', 정치 폭력, 그리고 권위주의 하의 개방 소셜 네트워크

잇창명 EatChangmyeong💕🐱 @eatch@hackers.pub

이 글은 개방형 소셜 네트워크인 블루스카이가 미국 정치 지형 변화 속에서 겪는 어려움을 분석합니다. 중도 논객들의 비판과 가짜 뉴스 확산으로 '좌편향' 플랫폼이라는 낙인이 찍히고, 정부의 검열 압박까지 받는 상황을 설명합니다. 특히 찰리 커크 피살 사건을 계기로 블루스카이에 대한 정치적 공격이 심화되고 있으며, 이는 앱 스토어 퇴출과 같은 실질적인 위협으로 이어질 수 있음을 지적합니다. 저자는 블루스카이가 빅테크의 엔시티피케이션(enshittification) 문제 해결에 집중하는 동안, 권위주의 정부의 탄압이라는 새로운 위협에 직면했다고 주장합니다. 따라서 단순한 플랫폼 이동의 자유를 넘어, 정치적 탄압에도 살아남을 수 있는 회복탄력성 있는 네트워크 구축이 필요하다고 강조합니다. 이 글은 기술적 자유와 정치적 억압 사이의 복잡한 관계를 조명하며, 미래 소셜 네트워크의 방향성에 대한 중요한 질문을 던집니다.

Read more →
5
8
0
0

“소프트웨어 아키텍처 101” 책은 소프트웨어 아키텍처를 주제로 소프트웨어 엔지니어링 접근 방식을 여러 체계로 분류하고, 각각을 설명한다. 아키텍처를 다루는 데 그치지 않고 아키텍트의 역할과 소프트스킬도 간략하게 다뤄서, 아키텍처라는 활동을 기초부터 차근 차근 두루 살펴본다.

저자는 절충점(트레이드오프)을 근간으로 삼아 내용을 기술한다. 책 초반부에 “아키텍처는 모든 게 다 트레이드오프”라고 선언한다. 그래서 여러 아키텍처를 소개하고 설명할 때에도 무엇이 트레이드오프 요소일지 설명하는 점이 유익하다.

이런 주제를 다루는 책은 주니어에게 자칫 헛바람 또는 손에 망치를 들게 하는데, 자신의 커리어 단계에서 아키텍처를 어떻게 학습하고 소화할지 제안하는 점이 인상적이다.

원제에 fundamentals이라는 표현이 있는데, 기초나 입문이라는 표현이 좀 더 어울리는 책이다.

책 표지책 갈무리 1책 갈무리 2책 갈무리 3책 갈무리 4책 갈무리 5책 갈무리 6책 갈무리 7책 갈무리 8
1
0
0
1

“러닝 랭체인” 책은 랭체인, 랭그래프 등을 개발한 이들이 집필한 책으로, 랭체인을 활용해 AI 제품을 확장하거나 고도화하고, AI 에이전트를 개발하는 실무 내용을 다룬다. 실무에 초점을 맞춘 책이라 주요 개념을 간략히 설명하거나 언급만 하며, 랭체인을 사용해 실제 구현하는 방법을 제시한다. 어느 정도로 구현하는 방법을 다루냐면, Python과 JavaScript 두 언어로 예시 코드를 담고 있다. 랭체인 등이 워낙 추상화를 해놓은 도구여서 굳이 두 언어로 예시 코드를 다룰 필요가 있을까 생각이 들면서도, 소프트웨어 엔지니어링이 주업이 아닌 직군인 사람에겐 편할 것같기도 하다. 세세하고 풍부하게 내용을 다루는 온라인 공식 문서와 책 사이에 모호한 경계에 위치한 책이라는 생각이 든다. 디지털 문서 읽는 걸 선호하지 않는 내겐 유용했다.

책 표지책 갈무리 1책 갈무리 2책 갈무리 3책 갈무리 4
2
1

최근 며칠간 WAH라는 이름의 WebAssembly 인터프리터를 만들고 있다. ~와! 샌즈!~

WAH의 특징이라면 C로 작성되어 있는데 헤더 하나로 구성되어 있다는 점과, 거의 대부분의 코드를 Gemini가 짰다는 것 정도일까? (Claude Code도 좀 사용했지만 코드 생성은 Gemini가 다 했다.) Gemini가 디버깅을 시키면 답답한 게 사실이라서 최대한 프롬프트에 정보를 많이 넣고 few-shot으로 생성하게 하는 걸 목표로 했는데 생각보다 잘 되었다. 예를 들어서 한 프롬프트는 다음과 같았다. 저 문장 하나 하나가 시행착오의 결과이다.

@wah.h 에 if~else~end 명령을 구현하고, 대응되는 test_*.c 파일들이 모두 성공하도록 (또는, 해당 테스트에서 잘못된 점이 있을 경우 그 원인을) 고쳐줘. 아직 loop 관련된 코드는 처리할 필요 없고 테스트 중에 그걸 테스트하는 게 있다면 주석 처리해(지우지는 마). 컴파일과 실행은 &&로 한 번에 하도록 해. 정확한 구현 방법은 이래야 해: if~else~end에서 마지막 end는 사라지고, if는 else 직후 명령으로 이동하는 conditional jump로 재활용하며, else는 unconditional jump로 바뀌어(즉 실행기 입장에서 br과 else의 동작은 똑같아야 해! else를 아예 없애고 br로 대체할지 말지는 알아서 정해). 그러니까, if A B C else D E F end G 같은 명령이 있다면 preparsing 이후에는 if <offset to D> A B B C else <offset to G> D E F G 형태가 되어야 한다는 뜻이야. WebAssembly 명세에 따르면 if 문에는 block type이 따르는데, 이 타입을 사용해서 validation을 진행하는 것도 정확히 구현해야 해(block type이 function type (T1..Tn)->(U1..Um)이면 현재 스택에 T1..Tn 타입이 들어 있고 end 이후에는 U1..Um 타입이 들어 있어야 하고, 일반 타입 T가 들어 있다면 ()->(T)와 동일하게 취급함). block type은 validation 이후 preparsing 과정에서 사라져서 런타임에는 반영되지 않도록 해.

솔직히 너무 많이 요구하는 거 아닌가, 안되면 validation 부분을 어떻게 뺄지 고민하고 있었는데 시도 세 번만에 800줄짜리 diff가 떡하니 나오고 일단 보기에는 틀린 부분이 없어서 놀랐다. 물론 삽질도 많이 했는데 가장 많이 한 삽질은 테스트를 작성할 때 수동으로 WebAssembly 바이너리를 짜면서 바이트 숫자를 잘못 세어서 오류가 나는 거랑, 분명 WebAssembly opcode를 사용해야 하는데 자기 마음대로 코드를 정해 버린다거나 하는... 그런 우스운 상황이었다.

우습기도 하고 놀랍기도 하지만 이 코드를 내가 직접 짜지 않는 이유는 귀찮아서...라기보다는 내가 이걸로 하고 싶은 일이 따로 있고 WebAssembly 인터프리터를 만드는 게 주 목표는 아니기 때문이다. (원래 하고 싶은 일은 나중에 언급할 듯.) WebAssembly 구현이라고 하면 기술적으로 복잡해 보이지만, 내 용도에서 유래하는 몇 가지 조건(대표적으로 결정론적인 동작)을 제약으로 걸면 기술적으로 복잡하다기보다는 그냥 노가다에 가까워지기 때문에 끌리지 않는 것도 있긴 하다. 이전의 Angel이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.

9
1
0
1

탈모가 심한 개발자는 함수형 패러다임을 써야 하는 이유는?

함수형 써보니까 모나드라

엌ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

8
2

연구자로서, 또한 한 명의 개발자로서 현 세대에 항상 궁금한 것은 AI가 얼마나 도움이 되느냐이다.

Haskell, OCaml은 말할 것도 없고, JavaScript, Python도 AI와 써 본 경험으로는 그들이 큰 도움이 되느냐는 질문에 자신있게 "그렇다"고 하기 힘든 경험만 해봤기 때문이다.

내가 코드의 형식에 대한 집착이 너무 심한 것이 원인일 수는 있겠으나... AI가 준 결과를 여기 바꾸고 저기 바꾸다보면 결국 내가 쓴 처음부터 코드가 된다.

얼핏 드는 생각으로는 거의 "타입도 없고 문서화도 잘 안되어 있는 환경에서는 사람들이 기능을 이해하기 어려우니 AI를 쓰겠다..."싶다가도, "그러면 내가 잘 아는 분야에 대해서 왜 AI를 써야하지?"하는 생각도 떨치기 힘든 상황이 자주 찾아온다.

결과적으로 나는 AI를 사용하려는 시도를 (적어도 일시적으로는) 멈추었다.

7
1

웹 접근성을 고려한 콘텐츠 제작기법 2.2 개정판 W3C 저작 웹 콘텐츠 접근성 지침(WCAG)에 대한 국내 사례집이라 생각하시면 됩니다.

디지털 접근성의 4가지 원칙인 인지 · 조작 · 이해 · 견고 마다 실용적인 예제가 실려져 있습니다. FE 하시는 분이라면 꼭 읽어보세요.

1

Jaeyeol Lee shared the below article:

생각을 더 잘하기 위한 생각

규영 @0xq0h3@hackers.pub

## 기술 포스팅 자동 요약 다음은 제공된 Markdown 형식의 기술 포스팅을 요약한 결과입니다. - "Something is always better than nothing": 완벽하지 않더라도 작은 시작이 중요하다는 점을 강조합니다. - "생각은 깨지고 정리되는 동적평형 상태": 새로운 정보가 없는 생각은 정체되므로 지속적인 학습이 필요함을 역설합니다. - "남의 의도를 해석하고 평가할 때 드러나는 것은 자신의 인식과 세계이다": 타인에 대한 평가는 결국 자신을 반영한다는 통찰을 제시합니다. - "Do not fool yourself, the easiest one whom to deceive": 자기기만은 가장 쉬운 함정이므로 경계해야 함을 강조합니다. - "Do plan, Do take action, Do repeat": 계획, 실행, 반복의 중요성을 간결하게 요약합니다. - "Nothing but feedback. Feedback is everything": 피드백의 중요성을 강조하며, 모든 것의 핵심임을 설명합니다. - "Make it work, Make it faster, Make it better": 점진적인 개선의 중요성을 강조합니다. - "Cargo cult science -Richard Feynman": 리처드 파인만의 말을 인용하여 맹목적인 모방을 경계합니다. - "What I cannot create, I do not understand -Richard Feynman": 직접 만들 수 없으면 이해한 것이 아니라는 파인만의 명언을 소개합니다. - "사전부검": 실패를 미리 가정하고 원인을 분석하여 실패를 예방하는 방법론을 제시합니다. - "A: 내가 하는 작업, B: 내가 하는 작업을 개선하는 작업, C: B를 개선하는 작업": 작업 개선의 중요성을 강조하며, 지속적인 개선의 필요성을 설명합니다. - "의지를 이겨내는 극기훈련을 하는 것보다 주변 환경을 통제하는게 더 쉽다": 의지력보다 환경 통제가 더 효과적임을 강조합니다. - "파랑새는 없다": 파랑새 신드롬을 언급하며, 현재에 집중해야 함을 강조합니다. - "망치를 손에 들고 있으면 모든 것이 못으로 보인다": 도구에 갇힌 사고방식의 위험성을 경고합니다. - "세상에서 가장 흐린 먹물도 가장 좋은 기억력보다 낫다": 기록의 중요성을 강조합니다. - "지금 내가 할 수 있는 일들 중에서 가장 도움이 되는 일을 하자": 현재에 집중하여 가장 가치 있는 일에 집중하자는 메시지를 전달합니다. - "You can change your organization or change your organization -Martin Fowler": 조직 변화의 필요성을 강조합니다. - "더닝크루거 롤러코스터": 더닝-크루거 효과를 롤러코스터에 비유하여 설명합니다. - "은총알은 없다": 만능 해결책은 없다는 점을 강조합니다. - "도망쳐서 도착한 곳에 낙원은 없다": 현실 도피는 해결책이 될 수 없음을 강조합니다. - "bias variance trade-off": 통계학의 중요한 개념인 편향-분산 트레이드오프를 언급합니다. - "Don't invent the wheel again": 이미 존재하는 것을 재발명하지 말라는 조언을 제시합니다. - "Amateurs copy, professionals steal": 창의적인 모방의 중요성을 강조합니다. - "과거에 어떤 일을 하지 못했음을 아쉬워하는 것보다 지금 내가 어떤 일을 할 수 있을지 적극적으로 탐색하는 것이 언제나 더 낫다": 과거에 얽매이지 말고 현재에 집중하라는 메시지를 전달합니다. - "조잡한 도구로 일하면 시간과 노력이 배로 필요하다": 도구 개선의 중요성을 강조하며, 악순환을 끊어야 함을 설명합니다. - "견지망월": 본질을 보지 못하고 겉모습에만 집착하는 어리석음을 비판합니다. - "능숙함은 수련이 끝난 바로 그 순간부터 퇴화된다": 꾸준한 수련의 중요성을 강조합니다. - "위대한 일을 하려면 재능, 연습, 노력 세가지가 모두 필요하다": 성공의 필수 요소를 간결하게 요약합니다. - "이제 적어도 무엇을 하고 싶어야만 할 수 있는 시기는 지났다": 변화된 시대에 대한 적응을 강조합니다. - "4인치 반사경을 만든 다음에 6인치 반사경을 만드는 것이, 6인치 반사경 하나 만드는 것보다 더 빠르다": 작은 성공부터 시작하는 것이 효율적임을 설명합니다. 이 요약은 각 포스팅의 핵심 아이디어를 간결하게 전달하며, 독자가 더 자세한 내용을 알고 싶도록 유도합니다.

Read more →
1

유튜브 transcript는 꽤 잘 지원돼서 어쩌면 영상요약을 기다려서 읽는 것보다 transcript를 읽는게 더 빠를지도.
요약과정에서 소실된 의미를 놓쳤을거라는 불안이 있어서 transcript를 선호한다.
이것도 낡은 사고방식일지도 몰라 당분간은 요약서비스 좀 써봐야지

0

유튜브 transcript는 꽤 잘 지원돼서 어쩌면 영상요약을 기다려서 읽는 것보다 transcript를 읽는게 더 빠를지도.
요약과정에서 소실된 의미를 놓쳤을거라는 불안이 있어서 transcript를 선호한다.
이것도 낡은 사고방식일지도 몰라 당분간은 요약서비스 좀 써봐야지

0
2
0

미첼 레스닉의 “평생 유치원”은 창의적 사고와 학습을 하는 방법을 다룬다. 창의적 학습의 틀로 4P, 즉, 프로젝트(Project), 열정(Passion), 동료(Pears), 놀이(Play)를 제시하고, 이들에 대해 연구와 실 사례를 들어 설명한다.

MIT미디어랩에서 만든 두 가지 프로그램을 주요하게 다루는데, 컴퓨터 클럽하우스와 스크레치이다. 이 두 프로그램이 거둔 성과와 이룩한 생태계를 사례로 들어 설명하고, 참여자를 인터뷰하는 내용을 담고 있다.

저자는 AI시대에 돌입한 현대 사회에서 우리가 행복한 삶, 성공하는 삶을 사는 준비하는 방법 중 하나로 창의적 사고를 말한다. 창의적인 활동은 인생에 기쁨과 의미, 목적을 부여하기 때문이다.

개발자 입장에서 이 책에서 말하는 창의적 학습과 활동에 대해, 그리고 AI시대를 맞이하고 바라보는 마음으로 여러 생각을 하며 읽었다.

평생 유치원 표지갈무리 1갈무리 2갈무리 3갈무리 4갈무리 5갈무리 6갈무리 7갈무리 8갈무리 9갈무리 10갈무리 11갈무리 12갈무리 13
0
1

We’re taking another step in building a sustainable financial base as a non-profit. Today, we’re announcing new hosting and support offerings, tailored for larger organisations and public institutions. These enable organisations to own their social identities, on their own infrastructure.

blog.joinmastodon.org/2025/09/

0
0
3
0
1

머라구요?프로그래머랑 엔지니어가 다르다구요? 엔지니어는 수학도 해야된다구요?!?

삐비.수포자.무논리.끝판왕…. 아니 진짜 너무… 이과적이야…….. 논리적인뇌 삽니다 제시요😭😭😭😭

저자처럼 심도있게 고민해보지 않아서 그런지.. 아니면 게임 구현 시켜본 적이 없어서 그런지… 저자의 턴제 시스템에 대한 고민이 어떤 건지 잘 이해가 가지 않네…..

그러고보니 비슷한 게 하나 있다… 삡투두의…. 가위바위보….

0
0
0
1

흑백 사진으로 랜더링 해주는 옵션을 추가하면 더 있어보일 것 같을지도

0

Jaeyeol Lee shared the below article:

내가 LLM과 함께 코딩하는 방식

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

이 글은 저자가 LLM(Large Language Model)을 활용하여 코딩하는 방법에 대한 개인적인 경험과 팁을 공유합니다. LLM 코딩 에이전트 사용 시 맥락 제공의 중요성을 강조하며, Claude Code 모델을 선호하는 이유와 그 장단점을 설명합니다. 세부적인 지시를 위해 GitHub 이슈를 활용하고, 설계는 사람이, 구현은 LLM이 담당하는 역할 분담을 제안합니다. 또한, 프로젝트 지침을 담은 *AGENTS\.md* 파일의 중요성과 Context7을 활용한 문서 제공 방법을 소개합니다. 계획 모드를 통해 LLM이 스스로 피드백 루프를 돌도록 유도하고, 필요한 경우 손 코딩을 병행하여 코딩의 재미를 유지하는 전략을 제시합니다. 이 글은 LLM을 단순한 도구가 아닌 협력적인 동료로 활용하여 개발 효율성을 높이는 방법을 모색하는 개발자들에게 유용한 인사이트를 제공합니다.

Read more →
34
0
1
1
0

자기소개: 바이브코딩 116일차... 여전히 아는 건 없고 어떻게 동작하는지 모르겠지만 어쨌든 굴러가니 된 게 아닐까??의 마인드를 갖고 있는 삐비에요. 이번에 @kodingwarriorJaeyeol Lee 님이 추천해주신 (오츠카 아미 저)를 읽고 감명을 많이 받았어요. 삐비도 해보고 싶다는 마음으로 해커스펍에 가입하게 되었습니당! 여태 바이브 코딩을 가챠 돌리는 느낌으로 해왔더니 한계가 많이 보이더라구영... 진심 어디서부터 시작해야할지 막막하지만, 100일동안 어떻게든 열심히 해보겠습니다...!!!!!!!!!!!

매일 최소 한 시간씩~! 바이브코딩 위주(할 줄 아는 게 이것뿐이라!)에 공부를 곁들이는 식으로~! 100일 챌린지 시작해보겠습니다!

3
1
0
0
1
0
1
1
0
1