## 6월 6일 안녕하세요. 저는 한국에 사는 취미 프로그래머이고, Haskell로 코딩하는 것을 즐깁니다. 우연히 Matrix Haskell에 올리신 글(https://storytotell.org/smalltalk-haskell-and-lisp)을 읽게 되었는데, NRAO라는 곳에서 일하고 계시다는 것을 알게 되었습니다. 이름만 들어도 NRAO는 정말 흥미로운 곳처럼 들립니다! 혹시 그곳에서 Haskell 기반 프로그램을 사용하고 계신가요? 감사합니다! 좋은 하루 되세요. 박준규 드림. ## 6월 7일 준규님께. 편지를 받게 되어 정말 기쁩니다! Haskell을 사용하는 취미 프로그래머라는 말씀을 듣고 무척 반가웠습니다. 혹시 현재 진행 중인 프로젝트나 공유해주실 수 있는 코드가 있으신가요? Haskell 공부는 어느 정도까지 하셨나요? H-99 문제는 풀어보셨는지요? 또는 Advent of Code, Project Euler 같은 문제 풀이도 해보셨나요? 공부하시는 데 필요한 자료나 지원은 충분하신지도 궁금합니다. 제 블로그를 읽어주셔서 진심으로 감사드립니다. 요즘은 Haskell을 많이 다루고 있진 않지만, Haskell은 제 프로그래밍 이해에 깊은 영향을 주었습니다. 저는 지금도 Haskell에서 얻은 아이디어를 자주 활용하고 있고, 업무에서 프로젝트 프로토타입을 만들 때 사용하기도 했습니다. 다만, 아쉽게도 현재 제가 맡은 업무 프로젝트 중에는 Haskell로 작성된 것은 없습니다. 하지만 NRAO에는 Haskell을 사용한 이력이 조금 있습니다. 지금도 Green Bank Observatory에서 사용되고 있는 프로젝트가 하나 있는데, 망원경 스케줄링 프로그램인 “antioch”입니다. 소스 코드는 다음에서 보실 수 있습니다. https://github.com/nrao/antioch 보시다시피 한동안 유지 관리가 되지 않고 있습니다. 코드를 읽어보시면 두 가지를 금방 눈치채실 겁니다. 1) 전체가 “Bird 스타일”로 작성되어 있어서 코드가 설명 사이에 주석처럼 들어가 있다는 점, 2) 작성자들이 Haskell에 대해 그렇게 깊은 이해를 갖고 있진 않았다는 점입니다. :) 제가 이 프로그램을 좀 더 현대적으로 바꿔보려고 시도한 브랜치가 어딘가에 있긴 한데, 내부에만 있는 것인지 저도 잘 모르겠습니다. 물론, 우리가 Haskell 기반 프로그램을 사용하면서도 크게 의식하지 않는 경우도 있습니다. 예를 들어 Pandoc은 아마 이미 알고 계실 텐데, 그런 도구 중 하나입니다. 개인적으로는 “reldiagram”이라는 프로그램을 가끔 사용하는데요. https://github.com/fusiongyro/reldiagram 이 프로그램은 PostgreSQL 데이터베이스를 읽어서 테이블 간의 관계를 도식화해줍니다. 제가 만든 Haskell 저장소는 이 외에도 몇 개 더 있지만, 가족과 함께하는 삶의 시기라 취미에 많은 시간을 쓰지 못해 대부분 좀 오래된 것들입니다. 언젠가는 여유가 생기면 더 많은 결과물을 만들 수 있으리라 생각합니다. 가끔은 Haskell이 아닌 다른 기이한(?) 것들도 시도하곤 했습니다. 예를 들어 Subversion에서 Git으로 대규모 마이그레이션을 할 때는 Prolog로 변환을 돕는 프로그램을 작성하기도 했습니다! 아마 지금 다 기억나지 않는 것도 있을 거예요. NRAO는 정말 훌륭한 직장입니다. 제가 처음 입사했을 때는 모든 것이 C++와 Java로 되어 있었어요. 지금은 대부분 Python으로 작업하지만, Go도 있고 Julia나 Rust를 쓰기 시작한 동료들도 있습니다. 점점 더 새로운 기술을 시도하려는 분위기로 바뀌고 있지요.(아마 J 언어는 당분간 안 쓰겠지만요! 😊) 제 블로그를 보시면 아시겠지만 저는 그냥 프로그래머일 뿐입니다. 하지만 NRAO에는 과학자, 실제 천문학자들도 많이 있습니다. 그중 한 명인 Emmanuel Momjian 박사는 최근 한국에 다녀왔는데, 한국의 아름다움과 음식에 대해 끊임없이 이야기하더군요. 저도 언젠가는 꼭 한국을 방문하고 싶습니다! 혹시 미국 뉴멕시코에 오실 일이 있다면 꼭 연락 주세요. 만나서 VLA(초거대 전파 망원경) 현장 투어도 안내해드릴 수 있습니다! 늘 좋은 일 가득하시길 바랍니다. 진심을 담아. ## 6월 8일 다니엘 님께. 정성스럽고 친절한 답변 진심으로 감사드립니다. 제가 공유드릴 수 있는 프로젝트들을 몇 가지 소개해드리겠습니다. 먼저, 제가 유지 관리자로 등록된 Hackage 패키지입니다. * https://hackage.haskell.org/package/align-equal * https://hackage.haskell.org/package/webfinger-client `align-equal`은 Gabriela 님의 블로그 글에 소개된 프로그램을 바탕으로 연습 삼아 만든 프로젝트입니다. `webfinger-client`는 원래 다른 분이 시작했다가 중단한 프로젝트를 최근에 제가 이어받은 것입니다. 두 프로젝트 모두 처음부터 제가 시작한 것은 아니라 조금 부끄럽기도 합니다. 저는 몇 년째 꾸준히 Haskell을 공부해왔지만, 아직 monad transformer를 능숙하게 다루지는 못합니다. H-99나 Project Euler 같은 문제들을 훑어보긴 했지만 실제로 풀지는 못했습니다. Advent of Code는 매년 1~2일 차 문제 정도는 시도해보지만 완주한 적은 없습니다. 또한 Exercism에 올라온 Haskell 문제도 몇 가지 풀어보았습니다. https://exercism.org/profiles/nattybear 그리고 다음은 제가 Protohackers에서 푼 0~2번 문제입니다. https://protohackers.com/ 대체로 저는 Haskell로 출판된 책들을 읽는 것을 즐깁니다. 소개해주신 antioch 프로젝트도 흥미로웠습니다. 꽤 오래된 프로젝트이긴 하지만요. 저도 Pandoc을 자주 사용합니다. 별건 아니지만 Hakyll을 이용해 정적 블로그도 운영하고 있습니다. https://nattybear.github.io/ reldiagram 프로젝트도 흥미롭네요. 저도 Graphviz를 좋아해서 반갑게 느껴집니다. 개인적인 프로젝트에 Prolog를 사용해본 적은 없지만, 《Logic Programming with Prolog》라는 책을 재미있게 읽고 예제도 따라 해 본 기억이 있습니다. 사실 저는 한 번도 미국 본토에 가본 적이 없습니다.(괌은 여행으로 간 적이 있습니다.) 앞으로 방문할 기회가 생길지는 모르겠지만, 언젠가 기회가 된다면 영화에서만 보던 그 거대한 전파망원경을 꼭 보고 싶습니다. 저도 요즘은 가족과 함께 보내는 시간이 많아 취미에 많은 시간을 쓰지는 못하고 있습니다. 언젠가 조금 더 여유로워지면, Haskell 생태계에 좀 더 활발히 기여할 수 있으면 좋겠습니다. 제 간단한 질문에 정성껏 길게 답변해주셔서 다시 한 번 감사드립니다. 혹시 이 대화를 트위터나 한국 디스코드 서버 ‘하스켈 학교’ 같은 소셜 미디어에 공유해도 괜찮을까요? 다시 한 번 감사드리며, 언제나 건강하시기를 바랍니다. 진심을 담아. 박준규 드림. ## 6월 10일 준규 님께. 유지 관리하고 계신 프로젝트들을 공유해주셔서 감사합니다. 저는 WebFinger라는 것을 이번에 처음 들었는데요, 아마도 Fediverse에 대해 잘 몰라서 그럴 것 같습니다. 반면에 준규 님께서는 이쪽에 대해 어느 정도 알고 계신 것 같네요. 절대 부끄러워하지 마시고, Haskell 세계에 무언가를 돌려주고 계시다는 점에 자부심을 느끼셔야 합니다! 제 아내가 자주 하는 말이 있는데요, “비교는 기쁨의 도둑”이라는 말이 있어요. :) 저도 Exercism을 한 번 확인해봐야겠네요. 아직 사용해본 적이 없고, Protohackers는 아예 처음 듣습니다. Advent of Code는 저도 보통 이틀쯤 하면 포기하게 됩니다. 문제 난이도가 금방 아주 높아지죠. 연말 휴일에 하루에 몇 시간씩 쓰고 싶진 않으니까요. 그래도 가끔은 연중에 돌아가서 한두 문제씩 풀어보곤 합니다. 어떤 분께서 언어를 배우기에 좋은 방법이라고 추천해주셔서, 저도 요즘 J를 공부하면서 따라 해보려고 하고 있습니다. 블로그도 공유해주셔서 감사합니다. Google Translate의 도움을 받아서 즐겁게 읽었습니다! 준규 님께서 스스로 시간을 내어 Haskell과 Lisp, 그리고 수학적 증명에 대해 공부해오신 점은 정말 자랑스러우신 일이라고 생각합니다. 저도 꾸준히 블로그를 구독할 수 있도록 좋은 RSS 리더를 찾아봐야겠네요. Lisp에 대해서도 흥미를 느끼고 계신 걸 보았는데, 저도 약간은 다뤄보았지만 Haskell만큼 깊이 있게 하지는 못했고, 공개 저장소에 올린 코드도 없는 것 같습니다. 개인적으로는 Lisp과 Haskell 사이에 깊고 아름다운 대칭성이 있다고 생각합니다. Haskell의 게으름(laziness)을 잘 활용하면, Lisp의 매크로와 비슷한 효과를 얻을 수 있다고도 생각하고요. 혹시 아직 안 읽어보셨다면, Typeclassopedia를 꼭 읽어보시길 추천드립니다. https://wiki.haskell.org/Typeclassopedia 이 문서는 제가 Haskell을 이해하는 데 정말 많은 도움을 주었습니다. 물론 아직도 comonad는 잘 이해하지 못했지만요! 한국어 번역본이 있다면, Haskell을 공부하는 다른 친구분들께도 아주 유용할 것 같습니다. 또한 아직 접해보지 않으셨다면 “free monad”에 대해서도 알아보시는 걸 추천드립니다. 제가 이해한 바로는, free monad는 절차적인(action-based) 방식으로 작성된 동작들을 구조화된 데이터로 만들기 쉽게 해주고, 그 구조를 함수형으로 다룰 수 있게 해주는 개념입니다. 즉, 절차적으로 보이는 문제를 함수형으로 전환할 수 있는 다리 역할을 해준다고 할 수 있습니다. 저 자신이 직접 써본 적은 없지만, 매우 강력한 아이디어라고 생각합니다. 그리고, 제가 드린 편지는 어떤 방식으로든 자유롭게 공유하셔도 괜찮습니다! 혹시 Haskell 관련해서 흥미로운 문제를 만나게 된다면 언제든지 제게 질문해 주세요. 저도 그걸 핑계로 다시 Haskell을 손에 잡을 수 있을지도 모르니까요. :) 다시 한 번 감사드리며.

Ah, C. The best lingua franca we have… because we have no other lingua francas. Linguae franca. Surgeons general? C is fairly old — 44 years, now! — and comes from a time when t

예전부터 기술 스택을 정할 때는 꼭 청개구리 같은 기술을 고르곤 했다. 2000년대 말에 Ruby로 웹 개발을 할 때에는 Rails 대신 Sinatra를 DataMapper와 함께 썼다. JavaScript 프레임워크를 쓸 때도 Prototype 대신 MooTools를 썼다. 2010년대 초반에 Python으로 웹 개발을 할 때는 Django를 안 쓰고 Werkzeug을 SQLAlchemy와 함께 썼다. 요즘에는 React와 Next.js를 안 쓰고 Solid와 SolidStart를 쓴다. 나는 요즘 이렇게 남들 쓰는 기술을 안 쓰고 꼭 삐딱하게 대안 기술만 골라서 쓰는 것을 두고 **청개구리 스택** 이라고 부르고 있다. 아마도 반댓말은 **정석 스택** 정도가 될 것이다. 청개구리 스택의 가장 큰 특징은 역시 쓰는 사람이 상대적으로 적다는 것이다. 그렇기 때문에 문제를 만날 일이 좀 더 많고, 트러블슈팅을 할 때도 다른 사람이 이미 찾은 해결책을 쓰지 못하고 직접 해결해야 할 때도 많다. 하지만 이것이 곧 그 기술, 그리고 그 기술을 너머서 그 분야에 대한 좀 더 깊은 이해를 갖추게 하는 기회가 되기도 한다. 이를테면,. Werkzeug의 추상화 수준이 높지 않아서 그 위에서 사실상 인하우스 웹 프레임워크를 만들어서 써야 했다. 물론, 이를 누군가는 삽질이라고 생각할 수 있겠지만, 그런 “삽질”이 나를 성장시킨 것도 사실이다. Stack Overflow에 답이 없을 때, 소스 코드를 직접 읽어야 했고, 그 과정에서 HTTP 프로토콜의 세세한 부분까지 이해하게 되었다. 그리고 그 기술이 오픈 소스라면, 실제로 그 기술에 기여할 기회도 많이 얻는다. 내가 제출한 풀 리퀘스트가 머지되는 순간의 희열은 정석 스택에서는 느끼기 힘든 것이다. 청개구리 스택의 또 다른 특징은 대체로 후발주자라는 것이다. 즉, 정석 스택에서 불만스러운 부분을 인식한 사람들이 참지 못하고 만든 경우가 많다. 그렇다 보니 대안적인 설계를 하게 된다. Solid가 React의 가상 DOM 오버헤드를 피하기 위해 정밀한 반응성(fine-grained reactivity)을 구현한 것처럼 말이다. 그리고 항상 그런 건 아니지만, 그러한 대안적인 설계가 정석 스택의 설계보다 더 나을 때도 많다. 정석 스택의 잘못된 선택들을 보고 배운 다음 그것들을 피해서 만드는 경우가 많기 때문이다. 이로 인해 청개구리 스택을 선택한 사람은 정석 스택을 선택한 사람보다 그 분야에 대해 조금 더 나은 이해, 좀 더 정돈된 이해를 갖출 기회가 더 많다. 한편, 정석 스택은 많은 경우 종합 선물 세트의 형태를 갖는 경우가 많다. Rails의 “설정보다 관행”(convention over configuration), Django의 “배터리 포함”(batteries included), Next.js의 풀 스택 솔루션을 생각해 보면 내부적으로는 여러 기술들을 품고 있더라도 사용자 입장에서는 그 경계를 느끼지 못할 만큼 잘 통합되어 있는 편이다. 반면 청개구리 스택은 많은 경우 여러 부품을 사용자가 직접 고른 다음 조립까지 해야 하는 경우가 많은데, 이 과정에서 시간이 많이 들긴 하지만 각 부품에 대해 최선을 고를 수 있다는 장점과 함께, 조립하는 과정에서도 각 기술에 대해 좀 더 깊게 이해할 기회가 된다. 이 조립 과정은 때로는 지난하다. Sinatra + DataMapper + Haml + Sass를 조합하면서 각각의 설정을 맞추고, 미들웨어를 연결하고, 오류를 디버깅하는 시간. 하지만 이 과정에서 나는 웹 프레임워크가 실제로 어떻게 작동하는지, 각 계층이 어떻게 연결되는지를 더 깊게 이해하게 되었다. 그리고 그 이해는 나중에 어떤 스택을 쓰든 큰 자산이 되었다. 그러나 한 가지 명심해야 할 것은, 오늘의 정석 스택도 과거에는 청개구리 스택으로 시작했을 수 있으며, 오늘의 청개구리 스택도 미래에는 정석 스택이 될 수 있다는 점이다. Ruby on Rails도 처음에는 Java 웹 개발의 대안으로 부상했고, React도 Backbone.js 같은 과거의 MVC 웹 프런트엔드 프레임워크의 대안으로 주목 받지 않았던가? 즉, 각 기술이 중요하다기 보다는 언제나 새로운 대안에 눈길을 주는 호기심과 기술적인 의사 결정을 할 때 기술 선택의 근거를 그저 대중의 선택에 위임하는 것이 아니라 직접 주체적으로 판단한다는 것이 중요하다고 생각한다. 학습과 추론이 분리되어 있는 LLM의 한계 탓에 앞으로 정석 스택은 더욱 더 정석이 되고, 청개구리 스택의 불리함은 커질 것이다. Claude Code는 Next.js 코드는 술술 짜주지만 SolidStart 코드는 헤맨다. 그럼에도 불구하고 청개구리 스택만이 줄 수 있는 배움의 기회는 여전할 것이라고 생각한다. LLM 시대에도 나는 계속 청개구리의 길을 걸을 것이다. 왜냐하면 청개구리 스택이 주는 배움의 기회는 단순한 지식 습득을 넘어서, 기술에 대한 좀 더 깊은 이해를 함양하기 때문이다. 그러니 이 글을 읽는 여러분도, 가끔은 Stack Overflow에 답이 없는 길을 걸어보길 권한다. 그 끝에서 만나는 깨달음은 온전히 자신의 것이 될 것이다. *[LLM]: large language model

What every web developer must know about mobile networks, protocols, and APIs provided by browser to deliver the best user experience.

Hide mentions from follower targeting non-follower

913 Posts, 33 Following, 49 Followers · 인형 만든다