@bglbgl gwyng 그러니 개최를 해주시죠
bgl gwyng
@bgl@hackers.pub · 95 following · 121 followers
GitHub- @bglgwyng
@kodingwarriorJaeyeol Lee
지원할만한 회사 정리하는 타래
[리디] 풀스택 엔지니어
- https://ridi.career.greetinghr.com/ko/o/106674
@bglbgl gwyng 컨설팅해드릴테니 열어보실?
@kodingwarriorJaeyeol Lee
역시 마니악한 주제로 라이트닝 토크하는 행사를 추가로 만들어야겠다
최근 며칠간 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이 과연 얼마까지 바이브 코딩으로 할 수 있는지를 테스트하는 목표였다면, 이번에는 정말로 목표를 달성하는 수단으로 기능할지 실험해 볼 작정이다.
사리투하
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 
이거 얼마전에 칭따오가서 먹었는데 존맛탱이더라고요. 요즘 한국에도 프랜차이즈로 들어온다죠?
git bisect란게 있군요? 그동안 이걸 한땀한땀 직접하며 월루를 해왔는데 말이죠..
bgl gwyng 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 →이제 자신이 보여주고 싶지 않은 추천사를 가리는 기능도 추가되었습니다. 메인 페이지에서 링크 타고가시면 사용 가능해요. 많은 이용 부탁드립니다.
https://referral.akaiaoon.dev/ 이 링크에서 사용 가능하고, 내가 받은 추천사는 https://referral.akaiaoon.dev/u/:username 으로 볼 수 있습니다. 아래 말코링님의 추천사 리스트를 참조해 주세요.
@hongminhee洪 民憙 (Hong Minhee) 
@curry박준규 제가 친구 가르쳐본 경험으론요. 그냥 do notation 알려주고 알아서 하라고하니, 시간 좀 지나서 main이 어떻게 평가되는지 내가 잘 모르는거 같다? 하고 알아서 눈치를 채더라고요. 이때 알려주면 됩니다.
부리또 이슈는 본인이 뭘 모르는지도 모른는 사람을 가르치려다가 생기는거 같아요. 최소 자신이 뭔가 모른다는 사실은 스스로 깨닫게 냅둬야합니다.
그러고보니 첫 컨트리뷰터 malkoG 님의 PR이 머지되었습니다.
벌려둔 일이 너무 많아서 뭐부터 해야 할 지 정하질 못한 채 우왕좌왕하는 일이 많다.
@hongminhee洪 民憙 (Hong Minhee) 우왕좌왕의 결과물의 fedify, logtape, upyo, optique인거군요. 앞으로도 쭉 우왕좌왕하시면 될듯 합니다.
이거 아무리 봐도 옛날에 본 심리검사 문항 같다. 이런 느낌으로
제 GitHub 프로젝트 중 별 400개를 받은 프로젝트가 나왔습니다!
여기까지 오는데 정말 많은 격려와 응원해주셔서 감사합니다. ㅠㅠ
IQ 테스트로 인간을 판별하고 구분짓는것에는 불편한 느낌이 들지만(그게 쓸모없단 얘긴 아님), 그와중에 우리집 강아지 견종인 요크셔테리어가 똑똑한 견종으로 분류되는 글을 보면 진심으로 뿌듯하다...
https://github.com/bglgwyng/nix-x-cabal
한달간의 삽질끝에 Nix + Haskell 빌드 프레임워크를 완성했다. 늘 Nix, Haskell에 기여하고 싶었지만, 솔직히 이걸 내가 직접해야하는 상황이 올줄은 몰랐네. Nix 디버깅하느라 정말 개고통이었다..
bgl gwyng shared the below article:
공허한 참
박준규 @curry@hackers.pub
하스켈의 `all` 함수에 빈 리스트를 넣었을 때 왜 `True`가 반환되는지에 대한 의문을 "공허한 참(Vacuous truth)"이라는 개념을 통해 탐구합니다. 흔히 '구현이 그렇게 되어 있으니까'라고 생각할 수 있지만, 저자는 이 현상을 논리적으로 분석합니다. `all` 함수의 구현 방식과, 빈 리스트에 대한 연산 결과가 전체 결과에 미치는 영향을 설명하며, 공집합의 모든 원소가 짝수라는 명제가 참인 이유와 유사한 논리적 근거를 제시합니다. 이를 통해 코드와 수학 간의 연결고리를 발견하고, 마지막으로 ChatGPT가 생성한 유머러스한 이미지를 곁들여 독자에게 즐거움을 선사합니다.
Read more →역시 마니악한 주제로 라이트닝 토크하는 행사를 추가로 만들어야겠다
@z9mb1wwj 
@catamorphicCata 
@d01c2Hyunjoon Kim 
@icecream_mable구슬아이스크림 
@minju2996bbang 
@lionhairdino 
@akastoot악하 
@jihyeokJihyeok Seo 
@linea 
@woaol벨 
@theeluwin제이미 
@rangho우주해커 끄적끄적 랭호 📝 
@nebuletoHaze 
@jcha0713joohoon 
@hyunjoon 
@krepe90남기현 (Krepe) 
@cetaceanightskyCetacea 
@aiooAhn Kiwook 
@ink_punctuation책 읽는 프로그래머 
@yg1ee밀
오늘 Hackers' Public 행사 첫번째 모임에 와주셔서 정말 감사합니다! 정말 즐거웠습니다! 잘 들어가세요!
https://referral.akaiaoon.dev/
github referral 사이드 플젝을 드디어 외부공개했읍니다... 적당히 추천하시고, 본인이 받은 추천사는 https://referral.akaiaoon.dev/api/recommendations/:github_id 로 URL 링크를 거시면 대충 svg가 말려옵니다. 깃허브 프로필에도 마크다운으로 링크 가능합니다.
예:
아직 임시라 수정 요청 혹은 피드백은 환영합니다.
@akastoot악하 프사가 깨져서 안나옵니다
리액트 기본 파비콘 쓰는 페이지 어떤데
https://referral.akaiaoon.dev/
github referral 사이드 플젝을 드디어 외부공개했읍니다... 적당히 추천하시고, 본인이 받은 추천사는 https://referral.akaiaoon.dev/api/recommendations/:github_id 로 URL 링크를 거시면 대충 svg가 말려옵니다. 깃허브 프로필에도 마크다운으로 링크 가능합니다.
예:
아직 임시라 수정 요청 혹은 피드백은 환영합니다.
I wrote a post on my blog after a long time: Recent open source development updates.
오랜만에 블로그에 글을 썼습니다: 〈오픈 소스 開發 近況〉.
몇년전에 모 기업 공채를 지원했는데. 마지막 인적성 면접만 남긴 상태에서 간접적으로 그때까지의 점수를 짐작할 방법이 있었는데, 정말 99% 합격했다고 생각했다. 결국 인적성 면접보고 떨어졌는데 거기서 정말 점수를 엄청나게 까먹었단 얘기다. 근데 지금도 이유가 뭔지 모르겠다. 진짜 모든 질문에 무난~한 대답만 했는데 말이지... 그거 떨어지고 다른 회사 갔는데 거기서 커리어도 꽤 꼬여서, 종종 다시 생각하면 아쉬워진다.
부연설명을 하자면. Git에선 브랜치 자체로는 '변경 사항'이라는 의미가 없습니다. 왜냐면 끝점만 있고 시작점만 있으니까요. 변경 사항을 논하려면 비교 대상인 커밋이 필요합니다.
Rebase를 하는 이유는 연속된 커밋들로(예쁩니다) '변경 사항'을 나타내기 위해서입니다. 그 의도한 '변경 사항'을 만들기 위해, 비교 대상이 될 커밋을 바꾸는게 리베이스입니다. 그러니까 개발자가 의도한 diff를 그대로 표현하지 못해서, diff = head - x니까 이 방정식을 만족시키는 x 커밋을 찾아서 diff를 의도한데로 계산되게 만드는거지요.
참 뻘스럽습니다.
Git 떡밥이 지나갔군요. 리베이스가 왜 필요할까요? Git 브랜치에 시작점의 개념이 없기 때문입니다. 브랜치는 커밋 ref가 아니라 (시작 커밋 ref, 끝 커밋 ref)가 되어야 합니다.
Go로 JSON 패키지 만들고 이름을 고조선(go-joseon)이라고 지으면 어떨까란 생각이 들었음
포항공대 > 카이스트인 이유
포스텍은 '포스'가 있지만,
카이스트는 '텍'도 없기 때문,,,,
친구 회사에서 react-form-mozard의 잠깐 언급되었는데, Generator 기반인게 문제가 되어 도입이 바로 기각되었다. yield*가 async, await, try, catch 등등과 달리 혐오스러운 외양을 갖고 있는게 문제가 되었다. 여러분 제발 키워드 차별을 멈춰주세요ㅠㅠ
bgl gwyng shared the below article:
LogTape 1.1.0: Smarter buffering, seamless integration
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
LogTape 1.1.0 introduces smarter and more flexible logging with two major features. The first is "fingers crossed" logging, which buffers debug and low-level logs in memory and only outputs them when an error occurs, providing a complete sequence of events leading up to the problem. Category isolation prevents one component's errors from flushing unrelated logs, keeping logs focused and relevant. The second feature is direct log emission via the `Logger.emit()` method, which allows feeding logs from external systems like Kafka directly into LogTape while preserving original timestamps and metadata. This release also includes bug fixes and improvements across the ecosystem, such as fixes for potential data loss during high-volume logging and improved cross-runtime compatibility. Upgrading to 1.1.0 is backward-compatible and enhances debugging in production by providing complete context for every error without constant verbose logging.
Read more →@bglbgl gwyng ctags로 어떻게 되지 않을까요?
@curry박준규 ctags는 일종의 구현이고, 제가 찾는건 프로그래밍 언어 자체의 요소에 가까운거 같습니다.
소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...
@bglbgl gwyng 단순히 링크 용도로만 남겨두는 게 아니라 실행 흐름을 점프시키는 용도로도 활용하면 더 좋겠군요!
키워드는 jmp 아니면 goto로 하면 좋을 것 같습니다.
리액티브 주석 시스템이라 이름 붙이며 될 것 같은데, 잠깐 검색으론 아직 그런 시도가 검색이 안되네요. 좋은 아이디어인데요. @bglbgl gwyng
@lionhairdino 자유롭게 전역적으로 unique한 심볼을 만들고(쉬움), 또 그걸 참조할 좋은 방법을 만드는게(잘 모르겠음) 필요하단 생각을 많이 합니다.
소스코드 사이의 안정적인 하이퍼링크를 만들수 있는 기능이 없다. 가령 A.hs에서 주석을 쓰면서 B.hs의 foo란 함수의 구현의 특정 부분을 언급하고자 할때, 그냥 B.hs L:77 이렇게, 소스코드가 수정이라도 되면 바로 유효하지 않게되는 방식으로 언급할수 밖에 없다. 만약 소스 코드 어디에서든 전역적인 심볼을 자유롭게 선언할 수 있다면 이 문제를 해결할 수 있을텐데...
@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) @hongminhee洪 民憙 (Hong Minhee) ㅋㅋ아닙니다. 솔직히 제 취향이라 재밌네요..
@hongminhee洪 民憙 (Hong Minhee) 뮤트 기능 로드맵에 있나요?
Deno 2.5 is out —
⭐ Permission sets in config
⭐ Setup and teardown APIs to Deno.test
⭐ HTML entrypoint support in deno bundle
⭐ Runtime API for deno bundle
bgl gwyng shared the below article:
헬: 하스켈 방언 기반의 셸 스크립팅 언어
박준규 @curry@hackers.pub
Chris Done이 개인적인 셸 스크립팅 용도로 만든 하스켈 방언 기반의 셸 스크립팅 언어인 헬(Hell)을 소개합니다. 저자는 bash의 난해한 문법과 서브 프로세스 의존성 등의 단점을 극복하고자 헬을 개발하게 되었습니다. 헬은 모듈, 패키지 시스템, 추상화 기능 없이 매우 기본적인 기능만을 제공하며, 하스켈의 장점(탄탄한 개념, 동시성, 가비지 컬렉션, 정적 타입 등)을 활용합니다. 헬은 기존 하스켈의 직관을 재사용하고, 안정성과 단순성을 추구하여 자동화 스크립팅에 적합하도록 설계되었습니다. 헬은 냉정하게 완결된 소프트웨어를 지향하며, 스크립팅의 한계를 명확히 정의하여 불필요한 기능 확장을 방지합니다. 릴리스 페이지에서 정적 링크된 리눅스 바이너리를 다운로드할 수 있으며, 구현에 대한 자세한 내용은 소개 슬라이드를 참고할 수 있습니다.
Read more →〈타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).
난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.
누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.
반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.
@hongminhee洪 民憙 (Hong Minhee) 글의 전체적인 논지가 일관되지 않은거 같습니다. '시간을 일급 개념으로 하자'는건 정말 200% 공감하는 얘긴데, 이건 또 그런 타입시스템을 만들잔 얘기란 말이죠. 응? 제 짐작으론, 저자는 타입 시스템 자체를 반대한다기 보다는, 현재 타입 시스템이 고도화 되는 방향인 더 강력한 추상화보다는, 물리 세계에서의 동작을 잘 묘사하는 쪽이 더 중요하다고 하는거 같습니다. 근데 제목에서 어그로를 살짝 끌어보려다가 글 전체가 좀 중구난방이 된 느낌입니다.
지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.
'둠'의 개발자 존 카멕이 '게임의 스토리는 포르노 영화의 스토리와 똑같다. 있어야 하긴 하지만, 딱히 중요하진 않다고'라고 말한적이 있다. 뭐 곧이 곧대로 이해해도 괜찮은데 약간 재밌게 해석하는 방법이 있는데.
종종 스토리가 훌륭하다고 언급되는 게임들이 있다. 나한텐 그런 게임으로 하프라이프2가 처음이었는데, 실제로 해보면 흥미진진하고 몰입감이 상당하긴 하다. 근데 막상 엔딩을 보고 무슨 내용이었지, 하고 돌이켜보면 전체 플레이타임(한 40시간?)에 비해 그렇게 플롯이 밀도있지 않다는걸 깨닫게 된다.
- 죽기 싫으면 A로 가세요
- A로 가려면 무슨 아이템이 필요해서 B를 먼저 가야하네요?
- B로 갔더니, 여기가 아닌가벼~ C로 가야겠군요
- 이러쿵저러쿵하다가 결국 A에 도착
이런게 대부분이라, 의미있는 내용만 추리면 전체 게임의 스토리가 아마 세줄 요약도 가능할 것이다. 사실 하프라이프만 이런게 아니라, 대부분의 스토리가 훌륭하다는 게임이 까보면 이런식이다. 잉, 그럼 스토리가 좋다는 얘긴 다 허상이었나?
자, 근데 포르노 영화의 스토리가 어땠더라? 움베르토 에코가 어떤 영화가 멀쩡한 영화인지 포르노 영화인지 구분하는 방법을 알려주는 가벼운 에세이를 쓴 적이 있다. 여기서 포르노 영화라 함은, 21세기에 인터넷에서 볼수 있는 '야동'보단, 옛날에 영화관에서 상영되던, 꼴에 1시간이 넘는 상영시간을 가지는 포르노 '영화'를 뜻한다.
아무튼 그 방법이 뭐냐면. 가령, 남녀 주인공들이 만나서 택시를 타고 집으로 간다. 이때 집으로 가는 동안의 시간을 아무 편집없이 그대로 보여주면 그게 포르노다. 멀쩡한 영화는 당연히 쓸데없는 장면은 바로 끊고, 집에 도착해서 거사를 치르고, 그리고 다시 다음 내용으로 이어질 것이다. 하지만, 지금 당신이 보고 있는게 포르노 영화라면! 택시 타고 가는 아무 의미없는 장면을 10분간 본다음, 그 다음에야 원래 보려고 했던걸 보게 된다.
도대체 왜 10분 동안 택시 타는걸 보여줄까? 움베르토 에코의 대답은, 만약 그 쓸데없는 장면이 없이 주인공들이 바로 물고빨기 시작해버리면, 관객들이 그걸 못 버틸거란 것이다. 아무리 그걸 보려고 온 관객들이라지만, 너무... 바로 그래버리면 쪼끔 부담스럽고 그렇다. 그래서 완충제 역할을 할, 택시에서의 10분이 필요하다. 21세기의 포르노는 고전 포르노 영화에 비해 완충제 구간이 많이 짧아지긴 했지만, 그래도 여전히 흔적은 남아있다.
다시 게임으로 돌아와서. 눈치챘겠지만, 게임에서의 전투(나 아무튼 핵심 플레이)가 포르노의 섹스씬에 대응된다. 그럼 게임에서의 스토리는, 포르노 영화에서 남녀 주인공이 택시를 타고 가는, 플레이어의 정서적 안정감을 위해서가 아니라면 굳이 필요없는 그런 역할을 한다는 얘기가 된다. 게임의 즐거움은 총칼로 맘에 안드는 놈들을 한 3,000명 쯤 조지는데 있는데, 그게 아무리 즐거운 활동이라지만 브레이크가 전혀 없이 스트레이트로 3,000명을 해치우는것은 정서적으로 만만치않은 일이다. 그래서 100명씩, 30번씩 나눠서 죽일 방법이 필요하고, 그 사이를 매꿔주는것이 것이 하프라이프2에서의 '여기가 아닌가벼~'란 결론이다.
존 카멕 님아, 이런 의도로 말씀하신거 맞죠?
컴파일러 책 얇은 거 하나 읽고 있는데 문맥자유문법(CFG)이 나와서 오랜만이야 친구 하면서 보는 중...언어학 덕질했던 사람으로선 이걸 보니 하나 떠오르는 게 하나 있는데, 1957년 Syntactic Structures에서 촘스키는 이 CFG를 갖고 닝겐의 자연어가 지니는 통사적 성질(의미 아님)을 마르코프 과정을 통해서 설명하기엔 한계가 있음을 지적하며 변형문법(Transformational Grammar)를 제안한 게 생각난다. 즉, 닝겐 자연어의 통사 정보를 설명할 문법을 제안한 것(다시 한 번 말하지만 의미가 아님). 물론 이후엔 훨씬 더 발전하고 추상화됐고, PCFG라 하여 CFG에 확률을 넣은 CFG 확장판도 있다[1]. 참고로 오토마타 이론에서 나오는 촘스키-슈첸버거 위계나 촘스키 정규형할 때 얘기하는 그 촘스키 맞다.
개인적으로 촘스키의 저 시절 연구들이 되게 재밌다고 생각하는데 (물론 훑어만 봤지만...) 이후엔 사실상 오토마타 이론쪽으론 손 뗀 것 같아서 좀 아쉽기도 함...여튼 컴파일러 책 보다가 갑자기 생각나서 씀. 그나저나 도대체 난 언제 쯔음 나만의 프로그래밍 언어를 만들 수 있을까?
정규언어에서 은닉 마르코프 모형으로 확장시키는 거랑 똑같다. ↩︎
이미 지원할 곳들을 조금 선정하긴 했지만, 여전히 프론트엔드 개발자로 일할 수 있는 곳들을 찾고 있습니다. 기존에 고장나있었던 cv를 조금 고쳐놨습니다 (원래 read cv 산이었던 것을 백업받아 홈페이지에 합체...)
비동기 프로그래밍:
async,Promise, ...: X- AI 에이전트 갈구고 딴짓하기: O
안녕하세요, 백엔드 경력직 프로그래머 뽑고 있습니다. 로그를 모니터링하고 저장하는 시스템을 개발하는 포지션입니다. 기존 오픈소스 솔루션을 사용하긴 하지만 단순히 구축하고 운영하는 것은 아닙니다. 운영도 하지만 개발이 주된 업무 입니다. (오픈소스 솔루션 운영 포지션으로 착각하고 지원하시는 분들이 계셔서 사족을 넣었습니다) https://careers.linecorp.com/ko/jobs/2845/
요즘 #cosmoslide (https://github.com/cosmoslide/cosmoslide) 개발하면서 들고 있는 생각....
대부분의 액티비티펍 소프트웨어 인스턴스는 멀쩡하게 365일 24시간 동일한 위치에서 운영이 되고 있다고 가정이 된다. 내가 글을 올리면, 나를 팔로우 중인 모든 사람들의 inbox에 내가 글을 올렸다(Create(Note))는 Activity가 전달이 되는데, 각자가 운영되고 있는 서버 인스턴스가 멀쩡히 살아있다면.... 딱히 문제가 되지는 않는다.
문제는, 게시글을 작성하는 시점에 팔로워 중 누군가의 인스턴스가 죽어있을때도 있다는 점이다. 그런 경우를 대비해서 exponential backoff를 쓰든 아무튼 fallback 알고리즘이 동작하긴 하는데, 서버가 살아나면 당연히 전달이야 잘 되긴 한다. 그런데, Activity 전달이 실패하는 일이 잦으면 어떤 액티비티펍 소프트웨어를 쓰던간에 retry를 하기 위해서 계속해서 Queue에 쌓이고, 최종적으로는 Queue에 쌓인 것 때문에 적지 않은 오버헤드가 있을 것 같은데 모더레이터의 입장에선 어느 정도까지 감안할 수 있는가? 라는 생각이 문득 들었다.
사실 내가 왜 이런 글을 쓰고 있냐면, 위에서도 언급했다시피, 로컬호스트에서 실제로 서비스를 (맥북이 켜져있을때만) 서빙하고 있고 그걸 Tailscale로 연결해서 터널링을 하고 있다. 즉, 맥북을 켜놓고 있으면 Create(Note) Activity가 정상적으로 잘 전달되고, 맥북이 꺼져있으면 Activity 전달이 안되고 있다. 실제로, 이런 맥락에서 지금 테스트 중인 두 개의 인스턴스가 있다. 이런 실험적인 시도를 하면서 이래도 되는게 맞나 싶은 생각도 들고는 있다. 맥북을 켜놓으면, retry되고 있는 것도 다 consume되긴 하겠지만.... 찝찝하긴 찝찝하다.
개발하는 입장이라고 선해를 할 수는 있어도, 비뚤어진 관점에서 해석하면 누군가는 어뷰징의 관점으로 해석할 수 있는 가능성이 적지는 않다고 생각하고 있다. 이런 경우엔 모더레이터되는 분들한테, 내가 이런 tailscale 도메인으로 서빙하고 있다고 통지라도 하는게 나으려나... 아니면, 내가 구매해놓은 도메인을 tailscale 도메인으로 CNAME 걸어놓고 "이런 도메인으로 서비스 걸어놓을 예정이니까 이 도메인만은 제발 차단하지 말아주십쇼 헤헤" 라고 해야하나... 아예 서버를 만드는거다보니까 이런 고려사항이 생기는 것 같다.
근데, 한 편으로는 이런 생각이 든다. 물리적인 서버의 위치를 옮길 가능성이 많은 환경(예를 들면, 전시 상황)이면 어떡하지? ActivityPub이 사실은 분산된 웹 환경을 위해 나온 프로토콜이긴 하지만, 분산된 웹 환경이라는게 물리적으로 각자 다른 위치에 오랫동안 배치가 되어 있는 서버 뿐만이 아니라 위치가 자주 바뀔 수 있는 서버도 연합의 대상으로 포함이 될 수 있다면? 어떤 공상과학 영화(ex. 터미네이터4)들을 보면, 저항군이 독자적인 라디오 기지국 같은거 만들고 위치도 매번 다른 곳으로 옮기고 주파수를 매번 다르게 설정하면서 소식전달하는 모습을 볼 수 있는데, 액티비티펍도 어떻게 보면 그걸 고려한 설계도 포함될 수 있지 않나... 그런 생각도 든다..
주로 사용하는 형상관리도구인 퍼포스 CLI에 이런 기능이 있어 삽질을 크게 줄이고 있어요. p4 set 해보면 각각의 설정이 기본값인지 로컬 설정파일인지 서버측 설정인지 의도적으로 설정하지 않은 건지 표시해줍니다.
https://hackers.pub/@bgl/01992444-6229-7509-b23a-aed615f96d23
난 어떤 CLI 툴들이 자기가 실제로 쓰고있는 설정값(기본값이거나, 환경변수에서 왔거나, 파일에서 왔거나)를 읽는 명령어를 필수적으로 포함했으면 좋겠다. 사실 법제화까지 하고싶다..
커뮤니티에서 정치적 발언을 하는 것을 금지하는 것의 문제는, 정치적인(또는 그렇게 들린다고 다른사람들이 주장하는) 발언으로 문제가 생겼을때(안 생길수가 없다) 발언의 옳고그름을 떠나, 발언이 정치적인지 아닌지를 따지는쪽으로 흘러가기 때문이라고 생각한다.
아 물론, 대놓고 정치적 발언을 많이 해서 커뮤니티 구성원들을 피곤하게 하는건 좀 다른 문제고, 그걸 피하기 위해 정치적 발언을 금지하는 강령이 있는것일 테다. 근데 이건 그냥 각자 눈치껏 잘치기길 기대하는 수준이고, 커뮤니티의 방향성과는 무관한, 각자 지켜야할 운전 매너에 가깝다. 내 말은, 언젠가 커뮤니티내에서 큰 의견 차이가 생겼을때, '정치적 발언 안됨'이 해결책이 되길 기대할순 없단거다.