Jaeyeol Lee

@kodingwarrior@hackers.pub · 238 following · 158 followers

Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.

Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.

그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중

Github
@malkoG
Blog
kodingwarrior.github.io
mastodon
@kodingwarrior@silicon.moe
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
0

Jaeyeol Lee shared the below article:

셸 언어는 때로 추하길 요구 받는다

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

명령줄 인터페이스(CLI)는 컴퓨터와 상호작용하는 가장 오래된 방식 중 하나다. 그리고 이 인터페이스를 지배하는 것은 셸 언어다. 그런데 흥미로운 점은 셸 언어가 일반적인 프로그래밍 언어들과는 상당히 다른 설계 철학을 따른다는 것이다. 한 마디로 요약하자면, 셸 언어는 때로 “추함”을 받아들여야 한다.

간결함의 미학

Bash나 zsh와 같은 전통적인 셸을 보자. grep -r "error" /var/log | wc -l와 같은 명령은 암호처럼 보일 수 있지만, 타이핑하는 데 몇 초밖에 걸리지 않는다. 이러한 간결함은 우연히 생긴 것이 아니다. 셸 환경에서는 사용자가 빠르게 입력하고, 결과를 확인하고, 다시 명령을 수정하는 반복적인 워크플로우가 일반적이다. 여기서 핵심은 “대화형” 경험이다.

PowerShell의 딜레마

PowerShell은 마이크로소프트가 셸의 개념을 재정의하려 한 야심찬 시도였다. 객체 지향적 파이프라인, 일관된 동사–명사 구문, 그리고 자세한 매개변수 이름 등은 모두 코드의 가독성과 유지보수성을 높이기 위한 설계였다.

그러나 다음 명령을 비교해보자:

Bash:

find . -name "*.log" -mtime -7 \
  | xargs grep "error" \
  | sort \
  | uniq -c

PowerShell:

Get-ChildItem -Path . -Filter *.log `
  | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-7)} `
  | ForEach-Object {Select-String -Path $_.FullName -Pattern "error"} `
  | Sort-Object `
  | Group-Object `
  | Select-Object Name,Count

PowerShell의 명령은 더 명확하고 자기 설명적이지만, 대화형 셸에서 빠르게 실험하고 반복하기에는 너무 장황하다. PowerShell 설계자들은 “추함”을 견디지 못하고 너무 많은 “다림질”을 해버린 것이다.

균형점 찾기

흥미롭게도 최근의 Nushell 같은 현대적인 셸은 이 교훈을 받아들이고 있다. 구조화된 데이터 처리와 같은 PowerShell의 장점을 가져오면서도, 대화형 사용에 필요한 간결함을 유지하려 노력한다.

셸 언어의 진정한 성공은 “아름다운 코드”와 “효율적인 상호작용” 사이의 균형에 달려 있다. 이는 때로 완벽한 문법이나 일관성보다는 실용적인 “추함”을 수용해야 함을 의미한다.

결론

프로그래밍 언어의 세계에서는 우아함과 일관성이 미덕이다. 그러나 셸의 세계에서는 타이핑 효율성, 속도, 그리고 대화형 적합성이 우선시된다. 이것이 바로 셸 언어가 때로 “추함”을 요구받는 이유다. PowerShell의 제한적인 성공은 이 기본적인 진실을 간과한 데서 비롯된 것일지도 모른다.

그리고 어쩌면 이것은 소프트웨어 설계 전반에 걸친 더 깊은 교훈을 담고 있다: 모든 도구는 그 사용 맥락에 맞게 설계되어야 한다는 것이다. 셸 언어에서는 그 맥락이 바로 키보드와 사용자 사이의 빠른 대화다.

Read more →
0
0
0
0
0
0
0
0
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by Jaeyeol Lee

지금 Hackers' Pub에는 Fresh 2.0 알파를 쓰고 있는데, 여러 가지 아쉬운 점이 많지만 그 중 하나가 아일랜드 컴포넌트로 콘텍스트가 전달이 안 된다는 것. 현재 아일랜드 컴포넌트에는 로캘 같은 정보를 일일히 프랍(prop)으로 넘겨줘야 한다…



RE: https://hackers.pub/@kodingwarrior/0195f94d-61f3-7cab-8a34-f2a8ab0f9a4a

0
0
0
0
0
0
정진명 @jjme@hackers.pub
Public
Shared by Jaeyeol Lee

개인적으로 웬만한 경우에는 prop drilling하는 걸(깊더라도) 선호하는데, 마우스를 따라다니고(=도큐먼트 기준 마우스 좌표를 알아야 하고) 해당 컴포넌트에 대한 설명을 담은(=해당 컴포넌트가 받은 prop을 쓰는) 마우스오버 툴팁을 여기저기에 붙여야 할 경우(=여러 번 구현해야 함) createContext/useContext를 쓰는 게 말이 되는 것 같았다.

접근성 문제 때문에 마우스오버로 정보를 보여주는 것 자체를 어디서나 쓸 수는 없겠지만… 다른 데 써 먹을 수도 있으리라 생각함.

0
0
0
Simon Park @parksb@silicon.moe
Public
Shared by Jaeyeol Lee

알렉사나 시리와 같은 음성 인터페이스가 성공하지 못한 이유에 대해 AI가 충분히 똑똑하지 않았기 때문이라고 말하곤 하지만, 핵심 문제는 출력의 퀄리티가 아니라 입력의 불편함이었다. "헤이 구글, 오늘 샌프란시스코 날씨는 어때?"와 같은 자연어 프롬프트는 홈 화면에서 날씨 앱을 터치하는 것보다 10배 더 걸린다. (매우 공감...)

대화형 인터페이스는 기존 워크플로우를 대체하는게 아니라 보완해야 한다. 키보드 워크플로우와 대화 워크플로우가 분리되어 스위칭을 반복해야 하는 방식이 아니라, 기존 작업을 멈추지 않고 AI와 대화하며 작업을 계속 할 수 있어야 한다는 것. julian.digital/2025/03/27/the-

The case against conversational interfaces

Conversational interfaces are a bit of a meme. Every couple of years a shiny new AI development emerges and people in tech go "This is it! The next computing paradigm is here! We'll only use natural language going forward!". But then nothing actually changes and we continue using computers the way w

julian.digital · julian.digital

0
0
0
0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

역시 모든 것들은 직접 데여봐야 는다... React의 useContext가 뭐하려고 쓰는지 실감이 잘 안났었는데, prop drilling하지 않고 디펜던시를 주입하고 싶을때 유용한듯.

특히, 어떤 특정한 데이터를 다루는 복잡한 컴포넌트를 다룬다고 가정하면 요렇게 프로바이더에 넘겨주면 되고 하위 컴포넌트에서는 useContext에서 그 값을 가져오면 코드도 굉장히 깔끔해지게 되는 듯

  <PostContext.Provider value={{ currentUser }}>
     <Post.Title post={post} />
     <Post.Comments>
       {comments.map(comment =>
          <Post.Comment  comment={comment} />
        )}
     </Post.Comments>
  <PostContext.Provider>

이런 글도 있다.

https://testdouble.com/insights/react-context-for-dependency-injection-not-state-management

Using React Context for dependency injection, not state management

Learn how to use React Context for dependency injection instead of state management, with insights from Redux maintainer Mark Erikson.

www.testdouble.com

0
0
2
0
0
0
0
0
0
0
0
0
0
0
0

Jaeyeol Lee shared the below article:

킹켄 혼도리점(キング軒 本通店)의 즙 없는 탄탄멘

정진명의 굳이 써서 남기는 생각 @index@guji.jjme.me

가게정보

상호: キング軒 本通店
주소: 広島県広島市中区本通8-7 しげとみビル 1F
방문한 날짜: 2025년 3월 20일
먹은 메뉴: 즙 없는 탄탄멘(汁なし担担麺)

검은 면기에 가는 면이 담겨 있고 후추, 다진 고기, 채썬 대파가 올라가 있다.

생각

즙 없는 탄탄멘이라는 것이 유행하다고 해서, 숙소 근처에 있는 가게에 가서 먹게 되었습니다.

가게에 들어가면 가게 전체에 나는 마라향(산초? 잘은 모르겠습니다.)에 압도됩니다. 조금 기다려서 서빙된 용기에서 면과 아주 적은 양의 국물을 잘 비벼 먹으면, 향에서 기대하게 되는 매운 맛은 강하지 않고, 강한 감칠맛이 올라옵니다. 매우리라는 기대를 배신당하는 점이 재미있고, 감칠맛이 좋습니다.

이 글을 쓰는 동안 맛과 향을 떠올리니 더 먹고 싶네요.

Read more →
0
0
1
0
1
0
박준규 @curry@hackers.pub
Public

몇 년 전에 취미로 프로그래밍 책 제본을 했다. 인터넷에서 업체에 PDF 파일을 전달하면 제본해서 택배로 받았다. 그렇게 읽지도 않는 책은 쌓여만 갔다. 결국 몇 달 전에 하스켈 학교 모르는 분에게 한 권만 나눔하고 모두 버렸다.

그런데 프로그래밍 책은 펼쳐 놓고 노트북을 켜서 실습할 때가 많기 때문에 잘 펴져야 한다. 떡제본은 펼침성이 나빠서 불만이었고 여러 제본 방식을 알아보다가 바인더 형식을 써보기로 했다. 적당한 업체를 찾아서 첫 주문을 했는데 오늘 도착했다. 원래 표지 디자인을 직접 해서 업체에 PDF를 전달해야 하는데 하는 법도 모르고 시간도 없어서

“그냥 대충 알아서 해주세요.”

했는데⋯

너무 이쁘게 잘 뽑아 주셨다. 책등 문구 디자인도 알아서 센스 있게 해주셨는데 너무 마음에 든다. 과연 이 책은 끝까지 읽을 수 있을까!

책등 이미지책의 목차 일부주문 제작한 B5 크기의 3공 바인더
0
1
0
0
12
0
0
1
0
0
0
0
0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

이거 사서 읽긴 했는데, 문서에서 설명하는 내용이랑 거의 비슷해요. 액티비티펍이 왜 생겨났고, 액티비티펍으로 어떤 미래를 기대하는가 같은 내용 위주로 읽으면 좋을 것 같아요. 다만, 여기에 실습 예제는 따로 실습 안하고 슥 하고 보기만 했는데, 실용적인 뭔가를 만들거면 Fedify 문서를 정독하는게 낫지 않나 싶습니다



RE: https://hackers.pub/@curry/0195f6ee-df39-7af7-b388-495fcc0d0789

0
0
0
Jaeyeol Lee @kodingwarrior@hackers.pub
Public

이거 사서 읽긴 했는데, 문서에서 설명하는 내용이랑 거의 비슷해요. 액티비티펍이 왜 생겨났고, 액티비티펍으로 어떤 미래를 기대하는가 같은 내용 위주로 읽으면 좋을 것 같아요. 다만, 여기에 실습 예제는 따로 실습 안하고 슥 하고 보기만 했는데, 실용적인 뭔가를 만들거면 Fedify 문서를 정독하는게 낫지 않나 싶습니다



RE: https://hackers.pub/@curry/0195f6ee-df39-7af7-b388-495fcc0d0789

0
0
0
bgl gwyng @bgl@hackers.pub
Public
Shared by Jaeyeol Lee

@hongminhee洪 民憙 (Hong Minhee) @curry박준규 제가 Rust 유저한테 하스켈을 영업해본적은 없지만, Rust 유저들은 하스켈을 고를수 있는 선택지에서 이미 결정을 내리고 지나온 사람들이라고 생각했거든요. HKT, 모나드? 그런거보다 포인터 직접 만지고 최적화하는게 좋아.

근데 생각해보니 Rust가 언어덕후들이 파던 언어였던것도 이미 오래전 얘기고, 이제는 하스켈 등의 옵션을 고려하지 않은채로 Rust를 써야할 환경에 놓인 사람들도 많겠다 싶네요.

0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0