Jaeyeol Lee

@kodingwarrior@hackers.pub · 400 following · 302 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

간만에 필받아서 aider 커꾸(commit 꾸미기) 함.
gum 이라는 훌륭한 쉘꾸 도구 + git pretty format + delta 썼어요

# Define the git log format string with color formatting for better readability
local GIT_FORMAT="%C(bold yellow)Hash:%C(reset) %C(bold cyan)%h%C(reset) %C(dim white)(%cd)%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Author:%C(reset) %C(bold white)%an%C(reset) %C(dim white)<%ae>%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Message:%C(reset) %C(bold white)%s%C(reset)"

# Define the date format
local DATE_FORMAT="%Y-%m-%d %H:%M:%S"

# Perform the commit with aider and show a styled commit summary
aider --commit && \
gum style \
  --border rounded \
  --padding "0 2" \
  --border-foreground 39 \
  "$(git log -1 \
      --pretty=format:"$GIT_FORMAT" \
      --date=format:"$DATE_FORMAT" \
      --color=always)" && \

# Show detailed changes using delta for side-by-side diff with line numbers
git show -1 --color=always --stat --patch | delta --side-by-side --line-numbers
2
5

🤔

Protocols such as ActivityPub are widely used and useful, but unfortunately are not the best option when efficiency is important. Messages are in plain JSON format, which is wasteful, and extensions by various implementations complicate the implementation.

XQ's focus on replacing JSON with Protocol Buffers seems misguided. While serialization efficiency matters, ActivityPub's fundamental bottlenecks are in its multi-hop network architecture and request patterns. Optimizing message format without addressing these core architectural inefficiencies is like polishing doorknobs on a house with structural issues. True performance gains would require rethinking the communication model itself.

https://github.com/misskey-dev/xq

3
0
0

DuckDB 인 액션 - SQL만 알면 되는 로컬 데이터 분석, DuckDB로 가볍게 시작한다 (마크 니드햄, 마이클 헝거, 마이클 시몬스 (지은이), 김의윤 (옮긴이) / 인사이트 / 2025-05-07 / 28,000원) feed.kodingwarrior.dev/r/qmINu

aladin.co.kr/shop/wproduct.asp

0

내가 제일 좋아하는 프로그래밍 문법, "파이프라이닝"
------------------------------
- *파이프라이닝* 은 프로그래밍 언어에서 코드의 가독성과 유지보수성을 높이는 중요한 기능임
- *데이터 흐름을 왼쪽에서 오른쪽, 위에서 아래로 자연스럽게* 표현할 수 있게 해주는 방식
-
Rust 와 같은 언어에서 파이프라이닝은 코드의 흐름을 명확하게 하고, IDE 의 자동 완성 기능을 통해 개발 생산성…
------------------------------
https://news.hada.io/topic?id=20473&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

랭체인으로 RAG 개발하기 : VectorRAG & GraphRAG - 현직 AI Specialist에게 배우는 RAG! 파이썬, 오픈AI, Neo4j로 실습하며 개념과 원리를 이해하고, 오픈AI와 딥시크 비교 분석까지! (서지영 (지은이) / 길벗 / 2025-04-25 / 29,000원) feed.kodingwarrior.dev/r/9pIEy

aladin.co.kr/shop/wproduct.asp

0

미래의 기술은 'AI'가 아니라 '집중력'임
------------------------------
- LLM은 반복 작업 자동화와 브레인스토밍 등에 유용하지만, *맹목적인 의존은 문제 해결 능력 저하를 초래할 수 있음*
- 특히 *새로운 문제에 대한 LLM의 신뢰도는 낮아* , 인간 엔지니어의 판단력이 중요함
- 구글 같은 검색엔진은 탐색과 활용의 균형을 제공하지만,
LLM은 즉시 ‘활용’(exploitation)만 유…
------------------------------
https://news.hada.io/topic?id=20458&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0

Vibe 코딩은 저품질 작업에 대한 변명이 될 수 없어요
------------------------------
- *AI 기반 바이브 코딩* 은 혁신적이지만, *품질 없는 속도는 위험* 하다는 경고의 글

"더 빨리 움직이고, 더 많이 망가뜨려라"
"vibe coding, 두 명의 엔지니어가 50명의 기술 부채를 만들어낼 수 있는 방식"
- 이 실리콘밸리의 오래된 슬로건을 비튼 표현은 최근 엔지니어링 커뮤니티에서 “vibe coding…
------------------------------
https://news.hada.io/topic?id=20449&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
8

바이브코딩을 하면서 느끼는게 몇가지 있는데,

  1. 내가 뭘 하고 싶은지, 뭘 생각하는지 명확하게 설명할 수 있는 능력이 더더욱 중요해짐.
    • 그렇다는 것은 즉, 문서를 작성하는 능력이랑 커뮤니케이션이 능력이 중요함. LLM의 시대에서 Garbage in Garbage out은 절대진리
  2. 타이핑을 많이 해서 손에 익는 것도 중요하지만, 머리에 들어있는 정보량이랑 계획을 세우는 것도 못지 않게 중요해짐.
    • 바이브코딩으로 타이핑하고 디버깅하느라 날아가는 시간이 절약되었다면, 그 시간에 앞으로 어떤 문제를 해결할지 고민하는데 시간을 더 들여야 함. 뭔가를 학습 중인 단계라면, 좀 더 많은 정보량이 머릿속에 들어올 수 있도록 해야 함.

뭐.... 손빠른 사람들의 시대가 갔다고는 하지만, 손빠른 사람들이 바이브코딩을 더 빠르게 하지 않을까 싶기도 하고 단위시간당 정보처리량이 더더욱 속도전에서 영향을 미치지 않을까 싶다. 리터러시는 말할 것도 없다.

4
1
2
4
1

터미널에 대해 궁금한 점이 생겨 자료를 찾다 보니 Windows Console Team에서 연재한 시리즈물을 발견했는데, 그 내용이 참 유익했다.

Windows Command-Line Series:

  1. Backgrounder
  2. The Evolution of the Windows Command-Line
  3. Inside the Windows Console
  4. Introducing the Windows Pseudo Console (ConPTY)
  5. Unicode and UTF-8 Output Text Buffer

콘솔 앱이 터미널과 입출력을 주고 받는 것을 공기처럼 당연하다고 생각했는데, 그 과정에는 커서 이동이나 개행 등과 같은 제어 문자를 렌더링하거나 SIGINT 같은 시그널을 발생시켜주는 처리가 존재했다. 터미널과 콘솔 앱이 서로 분리된 구조가 과거 물리 터미널로부터 비롯된 것도 흥미로웠고 말이다. 사실 이해 못 한 부분이 아직 많아서 다음에 또 읽어볼 생각이다.

6
0
0

배그로 설명하는 수학, 실험, 과학의 관계

수학: 배그에서 총을 쏠 때 총알 궤적
실험: 현실에서 총을 쏘면 배그와 동일한 총알 궤적이 나올까? 궁금한데? 쏴서 비교해보자!
과학: 실험 몇 번 해보니까 배그랑 현실이랑 총알 궤적이 같더라! 앞으로 총알 궤적 예측할 때는 배그켜서 확인하자!

0
0
1

토요일/일요일 각각 카테고리를 나눠서 작업하게 될 것 같습니다.

토요일

  • Fedify를 이용해서 마이크로블로그를 만드는 튜토리얼을 완주하는 것을 도전해보려고 합니다.

이미 postgres 기반으로 데이터베이스 세팅해서 만들고 있는게 있긴 하지만, Vibe coding으로 쭉 이어나가다가 Fedify를 제대로 활용하는 방법에 대해 알지 못한 상황이라 중간에 삑사리나서 헤매고 있는 상황입니다.

큰 욕심은 안내고 천천히 튜토리얼을 정주행하면서 전반적으로 한 사이클 돌고 감을 잡는 것에 의미를 둘 생각입니다. 예제는 sqlite를 쓰고 있지만, 여기서도 배리에이션 안주고 최대한 예제를 충실히 따르면서 완주하고 배리에이션은 천천히 주려고 합니다.

일요일

  • 지난주말에 작업했던 뉴스레터 서비스를 마저 작업할 것인데요. django 기반의 개발환경은 이미 세팅 완료 했습니다.

django admin에서 아티클 url을 수동으로 입력하고 langchain 기반으로 요약하는 기능 PoC로 나마 구현해보려고 합니다.



RE: https://hackerspub-ask-bot.deno.dev/message/0196468d-7fd8-7447-b2a6-e974c49e42b8

5
0

학교 캡스톤에서 절반 넘는 팀이 장고를 사용하는 신세카이를 보셨나요? 나도 멋진거 만들고 싶은데 현실적인거 고려하니까 걍 crud 웹앱이 되어버려서 눈물 난다

0
1
0

가장 선호하는 JetBrains IDE가 AI 시대에 뒤쳐지고 있어서 안타까웠는데 AI assistant 와 Junie 업데이트로 이제 좀 쓸만해진 것 같다.

여전히 부족한 점이 많기는 하다.
Agent는 느리고, 현재 상태에 대한 가시성이 없어 계속 기다려야할지 중단하고 새로운 세션을 열어야 할지에 대한 판단이 안선다.

prompt를 별도 관리할 수 있게 한 점은 훌륭하나 포맷이나 디렉토리를 유저가 선택할 수 있게 했더라면 더욱 유용했을 것이다. 나는 prompt가 다른 에이전트와 공유 가능하길 원한다.

vscode copilot처럼 Claude로부터 mcp 서버 설정을 불러올 수 있다. 하지만 역시 현재 상태 가시성이 없어 제대로 mcp 서버와 인터랙션이 되고 있는지 확인하기 어렵다.

그럼에도 불구하고 Cursor 나 Copilot에 충분히 대항할만한 업데이트라 생각한다. 앞으로를 응원한다!
https://www.jetbrains.com/ko-kr/junie/

1
0
1
3

오늘도 PostHog 뉴스레터의 좋은 말씀 들고왔습니다

빠른 제품 출시(Ship Fast)를 가로막는 7가지 원인 그리고 이에 대한 해결방법 https://newsletter.posthog.com/p/this-is-why-youre-not-shipping

  1. 징후: 문제가 생겨도 1:1 미팅 때까지 해결을 미룸

    • 해결:
      • 1:1 미팅 축소 및 목적 변경 (상태 보고 → 전략 논의/피드백)
      • 문제 발생 시 즉시 해결 문화 장려
      • 정보 공유는 투명하게 진행
  2. 징후: 다른 팀 승인 없이는 일이 앞으로 나아가지 못함

    • 해결:
      • 엔지니어의 자체 결정 권한 확대 (디자인/제품 출시 등)
      • 프로세스보다 신뢰/피드백 기반 협업
      • 위험 관리 위한 테스트 강화 (예: 실 운영 환경 테스트)
  3. 징후: 팀이나 담당자(오너십)를 바꾸는 것이 매우 힘듦

    • 해결:
      • 소규모 팀 유지로 유연성 확보
      • 필요시 신속한 팀 재구성 (분할/통합)
      • 책임 소재 투명화쉬운 변경 (공개 문서 등 활용)
  4. 징후: 엔지니어보다 영업 인력이 눈에 띄게 많음 (Sales-led)

    • 해결:
      • 제품/엔지니어링 인력 중심 조직 구성
      • 전사적 기술 역량 보유 인력 채용 확대
      • 제품 개발 속도 우선 (마케팅 등 후행 가능성 수용)
  5. 징후: 정보 공유가 안 돼서 계속 사람들을 '챙겨야' 함 ('in the loop')

    • 해결:
      • 정보의 완전한 투명성 추구 (목표, 현황, 결정 등)
      • 정보 Pull 방식 문화 정착 (필요한 사람이 직접 확인)
      • 구성원의 자발적 정보 공유 장려
  6. 징후: 성과가 그저 그런 사람들이 회사를 떠나지 않음

    • 해결:
      • '키퍼 테스트' 등 활용한 정기적 성과 점검 및 피드백
      • 성과 미달 시 명확한 기대치 전달 및 신속한 조치 (개선 없을 시)
      • 비효율적인 성과 개선 프로그램(PIP) 지양
  7. 징후: 모든 일이 너무 예상대로만 흘러가고 편안함 (위험 감수 X)

    • 해결:
      • 속도를 위한 의도적 트레이드오프 수용
      • 완벽함보다 빠른 출시와 학습 우선
      • 실패/미흡함 수용 및 학습 기회로 활용
3
5
0

Jaeyeol Lee shared the below article:

함수형 언어의 평가와 선택

Ailrun (UTC-5/-4) @ailrun@hackers.pub

함수형 언어(Functional Language)의 핵심

함수형 언어가 점점 많은 매체에 노출되고, 더 많은 언어들이 함수형 언어의 특징을 하나 둘 받아들이고 있다. 함수형 언어, 적어도 그 특징이 점점 대세가 되고 있다는 이야기이다. 하지만, 함수형 언어가 대체 무엇이란 말인가? 무엇인지도 모르는 것이 대세가 된다고 할 수는 없지 않은가?

함수형 언어란 아주 단순히 말해서 함수가 표현식[1]인 언어를 말한다. 다른 말로는 함수가 이기 때문에 다른 함수를 호출해서 함수를 얻어내거나 함수의 인자로 함수를 넘길 수 있는 언어를 말한다. 그렇다면 이 단순화된 핵심만을 포함하는 언어로 함수형 언어의 핵심을 이해할 수 있지 않을까? 이게 바로 람다 대수(Lambda Calculus)의 역할이다.[2]

람다 대수는 딱 세 종류의 표현식만을 가지고 있다.

  1. 변수 (xx, yy, …\ldots)
  2. 매개변수 xx에 인자를 받아 한 표현식 MM(함수의 몸체)을 계산하는 함수 (λx→M\lambda x\to M)
  3. 어떤 표현식 LL의 결과 함수를 인자 NN으로 호출 (L NL\ N)

이후의 설명에서는 MMNN, 그리고 LL이라는 이름을 임의의 표현식을 나타내기 위해 사용할 것이다. 람다 대수가 어떤 것들을 표현할 수 있는가? 앞에서 말했듯이 람다 대수는 함수의 인자와 함수 호출의 결과가 모두 함수인 표현식을 포함한다. 예를 들어 λx→(λy→y)\lambda x \to (\lambda y \to y) 는 매개변수 xx에 인자를 받아 함수 λy→y\lambda y \to y를 되돌려주는 함수이고, λx→(x (λy→y))\lambda x \to (x\ (\lambda y \to y))는 매개변수 xx에 함수인 인자를 받아 그 함수를 (λy→y\lambda y \to y를 인자로 사용하여) 호출하는 함수이다.

람다 대수(Lambda Calculus)의 평가(Evaluation)

이제 문제는

그래서 람다 대수의 표현식이 하는 일이 뭔데?

이다. 위의 표현식에 대한 소개는 산수로 말하자면 x+yx + y와 같이 연산자(++)와 연산항(xxyy)로부터 얻어지는 문법만을 설명하고 있고, 3+53 + 5와 같은 구체적인 표현식을 계산해서 88이라는 결과 값을 내놓는 방식을 설명하고 있지 않다. 이런 표현식으로부터 값을 얻어내는 것을 언어의 "평가 절차"("Evaluation Procedure")라고 한다. 람다 대수의 평가 절차를 설명하는 것은 어렵지 않다. 적어도 표면적으로는 말이다.

  • 함수는 이미 값이다.
  • 함수 λx→M\lambda x \to MNN으로 호출하면 MM에 등장하는 모든 xxNN으로 치환(Substitute)하고 결과 표현식의 평가를 계속한다.

이는 겉으로 보기에는 말이 되는 설명처럼 보인다. 하지만 이 설명을 실제로 해석기(Interpreter)로 구현하려고 시도한다면 이 설명이 사실 여러 세부사항을 무시하고 있다는 점을 깨닫게 될 것이다.

  1. 함수 호출 L NL\ N에서 LL이 (아직) λx→M\lambda x \to M 꼴이 아닐 때는 어떻게 해야하지?
  2. 함수 호출 (λx→M) N(\lambda x \to M)\ N에서 NN을 먼저 평가하는 게 낫지 않나? xxMM에 여러번 등장한다면 NN을 여러번 평가해야 할텐데?

첫번째 문제는 비교적 간단히 해결할 수 있다. LL을 먼저 평가해서 λx→M\lambda x \to M 꼴의 결과 값을 얻어낸 뒤에 호출을 실행하면 되기 때문이다. 반면에 두번째 질문은 좀 더 미묘한 문제를 가지고 있다. 함수 호출의 평가에서 발생하는 이 문제에 구체적인 답을 하기 위해서는 값에 의한 호출(Call-By-Value, CBV)와 이름에 의한 호출(Call-By-Name, CBN)이 무엇인지 이해해야 한다.

값에 의한 호출(Call-By-Value)? 이름에 의한 호출(Call-By-Name)?

앞에서 말한 함수 호출에서부터 발생하는 문제는 사실 함수형 언어에서만 발생하는 문제는 아니다. C와 같은 명령형 언어에서도 함수를 호출할 때 인자를 먼저 평가해야하는지를 결정해야하기 때문이다. 즉 이 문제는 함수를 가지고 있고 함수를 호출해야하는 모든 언어들이 가지고 있는 문제이다.

그렇다면 이 일반적인 문제를 어떻게 해결하는가? 대부분의 언어가 취하는 가장 대표적인 방식은 "값에 의한 호출"("Call-By-Value", "CBV")이라고 한다. 이 함수 호출 평가 절차에서는 함수의 몸체에 인자를 치환하기 전에[3] 인자를 먼저 평가한다. 이 방식을 사용하면 인자를 여러번 평가해야하는 상황을 피할 수 있다.

또 다른 방식은 "이름에 의한 호출"("Call-By-Name", "CBN")이라고 한다. 이 방식에서는 함수의 몸체에 인자를 우선 치환한 후 몸체를 평가한다. 몇몇 언어의 매크로(Macro)와 같은 기능이 이 방식을 사용한다. 얼핏 보기에는 CBN은 장점이 없어보인다. 그러나 함수가 인자를 사용하지 않을 경우는 CBN이 장점을 가진다는 것을 볼 수 있다. 극단적으로 평가가 종료되지 않는 표현식(Non-terminating expression)이 있다면[4] CBV는 종료하지 않고 CBN만이 종료하는 경우가 있음을 다음 예시를 통해 살펴보자. 표현식 (λx→(λy→y)) N(\lambda x \to (\lambda y \to y))\ N이 있다고 할 때, NN이 평가가 종료되지 않는 표현식이라고 하자. 이 경우 CBV를 따른다면 종료하지 않는 NN 평가를 먼저 수행하느라 이 표현식의 값을 얻어낼 수 없지만, CBN을 따른다면 λy→y\lambda y \to y라는 값을 손쉽게 얻어낼 수 있다. 바로 이런 상황 때문에

CBN은 CBV보다 일반적으로 더 많은 표현식들을 평가할 수 있다

고 말한다.

모호한 선택을 피하는 방법

두 방식의 장점을 모두 가질 수는 없을까? 다시 말해서, 어떤 상황에서는 이름에 의한 호출을 사용하고, 어떤 상황에서는 값에 의한 호출을 사용할 수 없을까? 이 질문에 답한 수많은 선구자들 가운데 폴 블레인 레비(Paul Blain Levy)가 내놓은 답인 "값 밀기에 의한 호출"("Call-By-Push-Value", "CBPV")은 함수형 언어의 평가를 기계 수준(Machine level)에서 이해하는데에 있어 강력한 도구를 제공한다. CBPV는 우선 "계산"("Computation")과 "값"("Value")을 구분한다.

  • 계산 MM, NN, LL, …\ldots = 함수 λx→M\lambda x \to M 또는 함수 호출 L VL\ V
  • VV, UU, WW, …\ldots = 변수 xx

잠깐, 앞서서 함수형 언어에서 함수는 값이라고 하지 않았던가? 이는 값 밀기에 의한 호출에서 함수와 함수 호출을 종전과 전혀 다르게 이해하기 때문이다. 함수 λx→M\lambda x \to M는 스택(Stack)에서 값을 빼내어(Pop) xx라는 이름을 붙인 후 MM을 평가하는 것이고, 함수 호출 L VL\ V는 스택에 값 VV를 밀어넣고(Push)[5] LL을 평가하는 것이다. 따라서 함수 λx→M\lambda x \to M는 평가의 결과가 아닌 추가적인 평가가 가능한 표현식이 된다. 이 구분을 간결하게 설명하는 것이 다음의 CBPV 표어이다.

값은 "~인 것"이다. 계산은 "~하는 것"이다.

그렇지만 함수형 언어이기 위해서는 함수를 값으로 취급할 수 있어야 한다고 했지 않은가? 그렇다. 이를 위해 CBPV는

계산을 강제한다면(force\mathbf{force}) 계산 MM를 하는 지연된 계산인 값 thunk(M)\mathbf{thunk}(M)

을 추가로 제공한다. 이 둘 (force(V)\mathbf{force}(V)thunk(M)\mathbf{thunk}(M))을 다음과 같이 문법에 추가할 수 있다.

  • 계산 = λx→M\lambda x \to M 또는 L VL\ V 또는 force(V)\mathbf{force}(V)
  • 값 = xx 또는 thunk(M)\mathbf{thunk}(M)

CBPV를 완성하기 위해 필요한 마지막 조각은 계산을 끝내는 법이다. 현재까지 설명한 λx→M\lambda x \to ML VL\ V 그리고 force(V)\mathbf{force}(V) 는 모두 다음 계산을 이어서 하는 표현식이고, 계산을 끝내는 방법을 제공하지는 않는다. 예를 들어 λx→M\lambda x \to M의 평가는 스택에서 값을 빼내고 계산 MM의 평가를 이어한다. 그렇다면 계산의 끝은 무엇인가? 결과 값을 제공하는 것이다. 이를 위해 return(V)\mathbf{return}(V)를 계산에 추가하고, 이 결과 값을 사용할 수 있도록 M to x→NM\ \mathbf{to}\ x \to N (계산 MM을 평가한 결과 값을 xx라고 할 때 계산 NN을 평가하는 계산) 또한 계산에 추가하면 다음의 완성된 CBPV를 얻는다.

  • 계산 = λx→M\lambda x \to M 또는 L VL\ V 또는 force(V)\mathbf{force}(V) 또는 return(V)\mathbf{return}(V) 또는 M to x→NM\ \mathtt{\mathbf{to}}\ x \to N
  • 값 = xx 또는 thunk(M)\mathbf{thunk}(M)

이제 CBPV를 얻었으니 원래의 목표로 돌아가보자. 어떻게 CBV 호출과 CBN 호출을 CBPV로 설명할 수 있을까?

  • CBV 함수 λx→M\lambda x \to M와 호출 L NL\ N이 있다면, 이를 return(thunk(λx→M))\mathbf{return}{(\mathbf{thunk}(\lambda x \to M))}L to x→N to y→force(x) yL\ \mathbf{to}\ x \to N\ \mathbf{to}\ y \to \mathbf{force}(x)\ y로 표현할 수 있다. 즉, CBPV의 관점에서 CBV의 함수는 지연된 원래 계산 λx→M\lambda x \to M을 값으로 되돌려주는 계산으로 이해할 수 있고, 함수 호출 L NL\ N은 함수 부분 LL을 먼저 평가하고 NN을 평가한 뒤 NN의 계산 결과 yy를 스택에 밀어넣고 지연된 계산인 함수 부분 xx의 계산을 강제하는(force(x)\mathbf{force}(x)) 것으로 이해할 수 있다.
  • CBN 함수 λx→M\lambda x \to M와 호출 L NL\ N이 있다면, 이를 λx→M\lambda x \to M(단, 변수 xx의 모든 사용을 force(x)\mathbf{force}(x)로 치환함)과 L thunk(N)L\ \mathbf{thunk}(N)로 표현할 수 있다. 즉, CBPV의 관점에서 함수 호출은 L NL\ N은 지연된 NN을 스택에 밀어넣은 뒤 LL의 계산을 이어가는 것으로 볼 수 있다. 이 지연된 NN은 이후에 스택에서 빼내어져 어떤 이름 xx가 붙은 뒤, 이 변수가 사용될 때에야 비로소 계산된다.

다소 설명이 복잡할 수 있으나, 단순하게 말해서 CBPV는 CBV에 따른 상세한 평가 순서와 CBN 따른 상세한 평가 순서를 세부적으로 설명할 수 있는 충분한 기능을 모두 갖추고 있으며, 이를 통해 CBV 함수 호출과 CBN 함수 호출을 모두 설명할 수 있다는 이야기이다.

기계 수준(Machine level)에서의 Call-By-Push-Value의 장점

앞에서는 CBPV가 CBV와 CBN를 모두 설명할 수 있음을 다뤘다. 그러나 CBPV는 프로그래머(Programmer)가 직접 사용하기에는 과도하게 자세한 세부사항들을 포함하고 있기에, 프로그래머가 직접 CBPV를 써서 CBV와 CBN의 구분을 조율하기에는 적합하지 않다. 그렇다면 어느 수준에서 CBV와 CBN을 혼합해 사용할 때 도움을 줄 수 있을까? 바로 람다 대수를 기계 수준으로 컴파일(Compile)할 때이다. 이때는 CBPV가 가진 자세한 세부사항의 표현력이 굉장히 유용해진다.

예를 들어 람다 대수를 기계 수준으로 변환할 때 흔히 필요한 것 중 하나인 항수 분석(Arity analysis)에 대해 이야기해보자. 항수 분석은 함수가 하나의 인자를 받은 뒤 실행되어야 하는지, 혹은 두 인자를 모두 받아 실행되어야 하는지 등을 확인하여 이후에 그에 걸맞는 최적화된 기계어(Machine language)를 생성할 수 있게 도와주는 분석 작업이다. 평범한 람다 대수에서는 항수 분석의 결과를 직접적으로 표현하기 어렵다. 예를 들어 람다 대수의 λx→(λy→y)\lambda x \to (\lambda y \to y)의 경우 이 함수가 xxyy를 모두 받아 yy를 되돌려주는 함수인지 (항수가 2인 함수인지), 혹은 xx를 받아 λy→y\lambda y \to y라는 함수를 되돌려주는 함수인지 (항수가 1인 함수인지) 구분할 수 없다. 그러나 이를 CBPV로 변환한 λx→(λy→return(y))\lambda x \to (\lambda y \to \mathtt{return}(y))λx→return(thunk(λy→return(y)))\lambda x \to \mathtt{return}(\mathtt{thunk}(\lambda y \to \mathtt{return}(y)))는 각각이 무엇을 뜻하는지 분명히 이해할 수 있다.

  • λx→(λy→return(y))\lambda x \to (\lambda y \to \mathtt{return}(y))는 두 변수 xxyy를 스택에서 빼낸 뒤 yy의 값을 되돌려주는 함수(항수가 2인 함수)이다.
  • λx→return(thunk(λy→return(y)))\lambda x \to \mathtt{return}(\mathtt{thunk}(\lambda y \to \mathtt{return}(y)))는 변수 xx를 스택에서 빼낸 뒤 지연된 계산 λy→return(y)\lambda y \to \mathtt{return}(y)를 돌려주는 함수(항수가 1인 함수)이다.

이런 장점을 바탕으로 CBPV를 더 발전시킨 "언박싱한 값에 의한 호출"("Call-By-Unboxed-Value")을 GHC 컴파일러의 중간 언어(Intermediate language)로 구현하는 것에 대한 논의가 현재 진행되고 있으며 앞으로 더 많은 함수형 컴파일러들이 관련된 중간 언어를 채용하기 시작할 것으로 보인다.

마치며

이 글에서는 함수형 언어의 핵인 람다 대수를 간단히 설명하고 람다 대수를 평가하는 방법에 대해서 다루어보았다. 특히 그 중 값 밀기에 의한 평가(Call-By-Push-Value, CBPV)가 무엇이며 CBPV가 다른 대표적인 두 방법(CBV, CBN)을 어떻게 표현할 수 있는지, 그리고 CBPV의 장점이 무엇인지에 대해서도 다루어 보았다. 이 글에서 미처 다루지 못한 중요한 주제는 CBPV를 기계에 가까운 언어로 번역해보는 것이다. 여기에서는 글이 너무 복잡해지는 것을 피하기 위해 제했으나, CBPV의 장점에서 살펴봤듯 이는 CBPV에 있어 핵심 주제 중 하나이기 때문에 이후에 다른 글을 통해서라도 이 주제를 소개할 기회를 가지고자 한다. 이 글이 CBPV에 대한 친절한 소개글이었기를 바라며 이만 줄이도록 하겠다.


  1. 결과 (Value)을 가지는 언어 표현을 말한다. 예를 들어 1+11 + 122라는 값을 가지는 표현식이지만 (JavaScript의) let x = 3;나 (Python의) def f(): ...은 그 자체로는 값이 없기 때문에 표현식이 아니다. ↩︎

  2. 다만 실제 역사에서는 람다 대수의 이해와 발견이 함수형 언어의 개발보다 먼저 이루어졌다. 이런 역사적 관점에서는 (이미 많은 수학자들이 이해하고 있던) 람다 대수에 여러 기능을 추가한 것이 바로 함수형 언어라고 볼 수 있다. ↩︎

  3. 프로그래밍 언어(Programming Language)는 실제로는 치환을 사용하지 않고 환경(Environment)을 사용하는 경우가 더 많지만 설명의 편의를 위해 다른 언어들 또한 환경 대신 치환에 기반해 평가한다고 가정하겠다. ↩︎

  4. 앞서 설명한 람다 대수에서는 이를 쉽게 얻을 수 있다. 오메가(Ω\Omega)라고 부르는 표현식인 (λx→x x) (λx→x x)(\lambda x \to x\ x)\ (\lambda x \to x\ x)의 평가는 값에 의한 호출을 따르든 이름에 의한 호출을 따르든 종료되지 않는다. ↩︎

  5. 바로 이 함수 호출을 값 밀기에 기반해 해석하는 데에서 CBPV의 이름이 유래했다. ↩︎

Read more →
13
3
0

다른 분들이 여러 가지 말씀을 해 주셨습니다만 저도 첨언하자면,

"의업과 약업의 현실적 관계"도 한 가지 중대한 이유입니다. 제약회사 직원이 의사에게 굽실거리다 못해 예비군 훈련을 대신 가거나, 수술을 대신 한다는 기상천외한 뉴스 다들 한번쯤 보셨을 텐데요.

원론적으로는 의사가 약에도 빠삭해야 하지만, 현실적으로는 자기 전공분야도 너무 방대하고 약학도 너무 방대해서 그러기 어렵습니다. 마치 소프트웨어 엔지니어 중에 하드웨어 덕질까지 하는 경우는 소수이고 대부분은 그냥 맥북 사는 것과 비슷하게, 의사들의 약 지식도 한계가 있는 거죠. 어떤 약을 안 쓰는 게 무슨 이유가 있어서가 아니라 진짜로 그 약의 존재를 몰라서인 경우가 허다합니다. 그러니 약 성능 똑같아도 영업에 따라 억 단위가 왔다갔다 하고, 그러니 제약회사의 영업이 엽기뉴스의 영역으로 가는 것이죠.

이런 시장환경에서 의사들에게 약 이름과 성분 이름의 대조표를 매년 새로 외우라고 하면 망하겠죠? 그래서 어떻게든 이름만 보면 성분을 알게 하려고 발버둥치는 것입니다.

그러면 반대로 성분명과 전혀 무관한 약 이름은 어떻게 나오는지도 짐작이 되시죠? 그렇습니다. "처방전 필요없는" 약은 성분명 쿨하게 버리고 일반소비자에게 호소하는 작명을 하는 경향이 있습니다. 그리고, 처방전이 필요하더라도 동일성분의 약이 많거나 저네릭 경쟁이 벌어지는 경우에도 튀는 이름으로 차별화를 꾀하는 경향이 있죠.

RE:
https://serafuku.moe/notes/a6lapo16c2

0

약간 Deprecated 상태인 Deno Fresh 프로젝트 주워먹긴 했는데, Deno Fresh + Supabase 조합으로 MVP 뽑는거 진짜 금방이네......... express로는 그냥 백엔드 위주로 MVP 뽑아먹는 느낌이었다면, deno fresh는 preact가 자체적으로 붙어있어서 제품 사이클 전반적으로 MVP 뽑아먹기 적합한 스택임

4
8
0
2
7
1

왜 Fennel인가?
------------------------------
-
Fennel 은 Lua 런타임에서 실행되는 프로그래밍 언어임
-
Lua 는 간단하면서도 강력한 프로그래밍 언어로, 다른 프로그램에 쉽게 통합되어 사용자에게 재프로그래밍 가능성을 제공함
-
Fennel 은 Lua의 단점을 보완하여, 보다 명확하고 오류를 줄이는 대안을 제공함
-
Fennel 은 Lisp 계열의 문법을 사용하여…
------------------------------
https://news.hada.io/topic?id=20336&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0

Jaeyeol Lee replied to the below article:

안녕하세요.

JakeSeo @jakeseo@hackers.pub

새로운 블로그의 시작을 알리는 첫 글입니다. 간단한 자기소개와 함께 블로그를 시작하게 된 계기와 앞으로의 방향에 대한 기대감을 표현하고 있습니다. 독자들에게 친근하게 다가가려는 노력이 돋보이며, 앞으로 어떤 이야기들이 펼쳐질지 궁금하게 만듭니다.

Read more →
6
1