# ANDRWJ.COM Programming & Structural Humanities - Site: https://andrwj.com/ ## 컴파일러 개발자가 들려주는 C 이야기 - Link: https://andrwj.com/c-book-from-compiler-designer/ - Published: 2026-10-14T08:59:48+09:00 - Author: A.J ![](https://andrwj.com/wp-content/uploads/2026/10/c-book-from-compiler-designer. png?amp;st=ji_Xc2esP9cU73yaXNIfDg&e=1794704031&st=64z7A-G868UT7fJmsWplRw) AI 시대 이전에는 컴퓨터 관련 매대마다 사람들이 서거나 앉아서 책을 찾아보던 모습이 일상과도 같았다. 그냥, 별다른 이유없이 가는 곳이 서점이었고 혹시라도 내가 모르던 재미난 주제를 담은 책이 나왔을까해서 기웃거렸던 때가 있었다. 이제는, 책도 없고 사람도 없다. 책장에, 매대에 놓여있는 것들은 어쩌면 다 철지난 내용을 담은 것들 뿐인 것 같은건 기분탓이다. 그냥 나오려다 눈이 마주쳤다. “어허,, 컴파일러 개발자가 얘기 해준다고?” 라는 주제를 출판하는 회사는? 역시나 [인사이트 출판사](https://blog.insightbook.co.kr/2022/01/07/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EB%93%A4%EB%A0%A4%EC%A3%BC%EB%8A%94-c-%EC%9D%B4%EC%95%BC%EA%B8%B0/). 2016년 이후로 10년만에 다시 Pebble Smartwatch 앱을 만들면서, C에 대한 향수 때문인지 아니면 저물어가는 사람이 코딩하던 시대에 대한 미련 때문인지, 덥썩 주워들고 결재를 해버렸다. 무려 컴파일러 개발자가 얘기해준다는데, 그냥 갈 수는 없지않은가;; 가능한 종이 책을 사지 않겠다고 그렇게 다짐을 했건만 난 어쩔 수 없이 온갖 낙서를 해대면서 봐야한다는 변명으로 날 속이고 말았네. 대신, 이번에는 겉포장을 하지 않을 것이다. 팔지도 않을 것이고, 잃어버리면 잃어버리는대로 더러워지면 더러워지는대로 그냥 둘 예정이다. 2026년 9월 15일, 포인터와 배열의 다름에 대해 쓴 9장 부터 본다. 제목에는 충격적이라고 하지만 뭐 잊어버렸던 내용일 뿐 완전 새로운 건 아니었다. 번역 문체도 나쁘지 않고 내용도 맘에든다. 군더더기가 없어 좋다. 내 Mercury는 정보 그자체를 설명하는 것 보다 뭔가와 비교를 할 때, 그리고 순서와 상관없이 궁금한 내용에 대한 것을 직접 해보면서 생각과 결과의 차이를 통해 이해하는 Venus Driven 구조이다. 어릴 때 이 특성을 미리 알았다면, 나는 그렇게 나를 학대하진 않았을 것이다. 비선형적이면서 엄청난 질문을 쏟아내지만 누구도 답을 해주지도 않았고 답해줄 수도 없었기 때문에 나는 나를 이해가 딸리는, 모자란 놈으로 여겼다. 그러나 남들이 도저히 생각해내지 못하는 것들을 만들어내거나 생각해내는 것이 우연이라고 하기엔 너무 잦았기 때문에 스스로도 이해하기 힘들었다. 아니, 그것보단 도대체 어떻게 해야 항상 그렇게 괜찮을 결과물을 만들어내거나 생각해 낼 수 있을까 그 방법을 찾기 위해 서점을 그렇게 들락거렸는지도 모르겠다. 그런 특성을 가진 내가 C 언어에 대해 벽이 사라짐을 느꼈던 계기는 정확히 기억난다. FreeBSD 기반의 커널 방화벽을 제작하는 회사에서 메모리 누수로 인해 Kernel Panic 버그를 잡는 문제를 해결하면서라고 얘기할 수 있다. 당시 커널 코드는 뭐 암호문이나 다를 바 없게 느껴졌었고 도대체 어떻게 해야 커널 개발자가 되는지 내 주변의 사람들은 내게 제대로 대답을 해주지 못했다. 아뭏튼 기억나는 건 도대체 왜`Cast`를 그렇게 해대는 걸까 하는 의문이었는데, 정확한 code는 기억나지 않지만 대충 기억나는 건 struct base 구조의 크기가 24 bytes 정도이고 멤버 필드중 하나가 4 바이트 짜리 unsigned int 인데 그걸 전혀 다른 사이즈 타입으로 캐스트를 하는 코드였다. 전혀 사이즈가 맞지 않아서 컴파일도 안될 것 같지만 원래 C 컴파일러 라는 놈은 _“네가 뭐 알아서 잘 하겠지, 난 그냥 컴파일만 해줄께”_ 라는 바이브라서 그런지 왜 그게 컴파일 되는지도 왜 하는지도 도무지 알수가 없었던 기억이 있다. 어쨌든 마침내 그 이유를 알게됐을 때 머리속에 번개 같이 모든 퍼즐이 맞춰졌다고나 할까… struct 타입을 어떻게 정렬했느냐에 따라 다르겠지만 그때 그 Cast 이유는 특정 위치에서 지정된 크기 만큼의 데이터를 원하는 타입으로 읽어와서 변수를 초기화 하기 위해서였다. 당시 그 코드가 남아있다면 더 생생하게 기록할 텐데, 아쉽다. C언어에서 타입은 크기를 의미하고 모든 것은 그 크기를 맞추는 놀음과 같다 라는 깨달음이라고나 할까… 그때 갑자기 C언어에 대한 막연함과 커널 프로그래밍에 대한 막막함이 한순간에 걷히는 느낌이었다. 그리고 그 Kernel Panic을 일으키던 메모리 조작 오류를 밝혀냈는데 그게 내 첫번째 실전 커널 프로그래밍의 결과였다. 그게 왜 기억에 남느냐면, 글로는 설명할 수 없는 개 무식한 과정을 거치면서 그 오류를 잡아내던 시절이기 때문이다. 그때당시 Kernel 쪽에 문제가 생기면 OS가 그냥 뻗어버린다. 퍽~ 하고 아무것도 남지 않는 그런 현상이 발생하면 그 이유를 명확히 알기위해 한 줄씩, 좁혀 들어가면 죽는지 안 죽는지를 봐야하고, 그 때마다 커널 빌드를 해야한다;;;;ㅎㅎ… 씨발.. 그러니까 단어 하나 고치고 퍽~ 하고 죽고, 다시 어찌어찌 부팅해서 몇 줄 고치고 빌드하는데 지금처럼 쓕~ 하고 지나가는게 아니란 말씀. 하염없이 컴파일 로그가 올라가는 걸 보다가 내 청춘이 다 가버린 것은 느낌이랄까… 그때 만약 지금처럼 QEMU 에뮬레이터가 있고 소스레벨로 디버깅이 가능했다면 정말 재밌었을 것이다. 그러나, 그때는 중노동에 가까웠다. 여기서 하고 싶은 얘기는 그것이다: “Threshold to understanding”, 즉 어느정도 차올라야 이해라는 것을 하는가.. 라는 건데, 결론을 먼저 말하자면, 그딴 건 없다. 각 사람이 이해해 도달하는 과정과 방법은 그 사람의 구조에 달려있다. 내 경우는, 이론을 듣고 말하고 보는 것 만으로는 완전한 이해에 도달하기 힘들다. 그런데! 만약 “그냥 궁금한 것을 해보고, 생각과 결과의 차이를 비교하면서 떠오르는 궁금함이 무엇이든 그걸 해결하려고 하면” 어느 순간 한꺼번에 전체를 완벽하게 이해하게 된다. 이게 내가 나를 쓰는 방법이다. 그래서 난 뭔가를 학습할 때는 무조건 소스코드를 따라서 분석하거나 디버거로 코드 흐름을 쫒아가거나 내가 궁금한 것을 해보다가 개구멍을 발견해서 그 영역에 들어가지만 곧 전체를 파악하는 경우가 많았었다. 내가 백엔드 개발자에서 프론트엔드 개발자로 전향했던건 ExtJS 가 버전 1일때, 그 소스를 분석해본 후에 JavaScript의 객게지향 상속 테크닉에 충격받았기 때문이었다. 이제는 내가 학습으로 나를 이해시키는 방법을 알기 때문에 이 책, 컴파일러 제작자가 알려주는 내용을 볼 때 읽고 싶은대로, 흥미가 당기는 대로 이리저리 뛰면서 아무런 계획없이 흥미를 쫒는다. 내가 이 책에서 기대하는 건, 이전에는 몰랐던 C 컴퍼일러의 설계레벨에서의 지식이다. 말 처럼 그렇게 딱딱한게 아니라, 오히려 숨은 비화같은 걸 기대한다고나 할까… 다행히도 그런 얘기가 많다. 함수의 인자로 사용되거나 호출 될 때에만 배열이 포인터로 치환된다는 컴파일러 설계 지침이, C언어 매뉴얼에서 페이지가 나눠지게 됨에 따라 어이없이 모든 배열이 포인터와 같이 취급된다는 내용을 가르치는 엉터리 책이 무수히 쏟아졌다는 얘기 같은 것 말이다. 갑자기 C언어의 창시작인 브라이언 커니핸이 떠오른다. C언어로 만드는 전통적인 예제 “Hello World!”를 만든 분. Mr. 커니핸을 추모할 때 사람들이 남긴“ Good bye, world” 라는 헌사가 떠오른다. 난 이 문구를 생각할 때 마다 그렇게 참,,, 찡하다… C는 내게 그런 감정을 가지게 하는 언어라고나 할까.. 언젠간, 아무도 Z80 어셈블리를 코딩하지 않듯이 C를 찾지 않게 되는 시대가 오겠지. 이미 `char c[10];`으로 선언하고 `c[3]` 을 쓰던 `3[c]`를 쓰던 상관없다라는게 아무런 재미나 흥미를 끌지 못하는 것과 같다. 설령 그렇다고 해도 내겐 C언어를 공부하는 건 여전히 흥미롭다. 어린애가 태어나서 철이들자마자“_ 언젠간 죽을 텐데 , 모든게 쓸모없다_“고 우울해 하면, 뒤통수가 마려운 것과 같다. 목적과 쓸모가 모든 것의 잣대는 아니잖는가. ## 리센느 - Link: https://andrwj.com/RESCENE/ - Published: 2026-10-12T03:04:40+09:00 - Author: A.J 원래 내가 가졌던 궁금증은 **_제나의 춤선은 왜 다른가?_** 였다. 여러 쇼츠에서도 제나는 춤꾼의 얼굴은 아닌데 춤선이 다르다 라는 댓글들이 많고, 나도 그렇게 생각한다. 그래서 인문구조학 관점에서 왜 그런지에 대해 탐색해본 짧은 기록을 남긴다. 미리 얘기를 하지만, 아마 거의 대부분 읽는 도중에 도무지 무슨 소리인지 의아해 할 것이다. 아무것도 친절하게 처음부터 하나 하나 얘기하려는게 아니라 그저 내 호기심과 그 호기심에 대한 이유를 기록한 것이기 때문이다. 그러나 언젠가 당신이 인문구조학이 뭔지를 알게되면 달리 보이게 될 것이 틀림없다. 우선, 시작은 나무위키에 올려진 리센느 멤버 페이지에 기록된 기록을 바탕으로 생시를 분석하였다. 리센느에 대한 정보가 잘 기록되어 있어 aspectscope-mcp로 각각의 멤버의 생시를 추적하는 ratification 절차는 한 사람당 대부분 5분 정도가 걸렸고 결과는 05: 56^(메이), 08:53^(리브), 12:00^(원이), 07:11^(미나미), 11:39^(제나) 으로 **추정한다**. 다시 한번 말하지만, 각각의 시간은 태어난 날짜와 알려진 정보를 바탕으로 생시를 확인하는 기법으로 계산된 추정시간이다. 그러나, 오직 Mercury-Mars 구조만을 참조하기 때문에 오차 범위는 끽해봐야 5% 정도 이내 일 것이다. 24시간 동안 Mercury든 Mars든 움직이는 거리는 거의 무시할 정도로 작다. 따라서 충분히 의미가 있는 분석이라고 생각한다. 내 생각엔 분명히 제나의 Mercury-Mars가 Conjunction 일 것이라고 확신했는데, 예상대로 였다. (그리고 이게 결론이기 때문에 사실상 나머지는 과정을 기록한 것에 불과하지만, 인문구조학적 지식이 조금이라도 쌓이면 Mercury-Mars Conjunction 구조라는 것이 얼마나 많은 의미를 내포하는지 감이 오게될 것이다) 아래 [AspectScope](https://andrwj.com/aspectscope/)로 출력한 이미지에서 보듯, 11 월 17일 ~ 12월 11일까지 제나의 출생지와 대략 50Km 이내 태어난 사람들은 강약의 차이는 있을지라도 대부분 춤을 잘 출 수 있는 능력을 타고 났다. (사실 그 기간안에서 크게 이틀 정도의 차이가 날뿐, 한국에서 태어난 대부분의 사람들에게 해당한다) `z` 로 마킹되어 있는 시간대가 제나가 태어난 날과 시간이다. 그리고 이미지 중앙의 굵은 검은 선은 Mercury- Mars 구조가 Conjunction 을 맺는 구간을 의미한다. 제나가 태어난 2008년에는 Conjunction 구간이 두번 있었고 그 중 첫번째 구간이 8월 24일 17시 46분 ~ 10월 2일 20시 20분, 두번째 구간이 아래 이미지에서 보이는 11월 17일 22시 22분 ~ 12월 11일 12시 20분까지였다. 생각과 행동이 하나가 되는 마치 공명하듯 강하게 흐름을 이어가는 시점이 11월 19일 이었는데, 제나는 그 시점에서 이틀먼저 태어났기 때문에 그 위상의 차이가 1.73° 였다는 것이다. Orb 값이 3° 이내는 상당히 강한 위상밀착도이므로 Conjunction 1.73°는 소위 말하는 타고난 재능에 속한다. ![](https://andrwj.com/wp-content/uploads/2026/10/mercury-mars-zena.png?amp;st=Dar13ruFrYa7jeO8yC- xLg&e=1794704031&st=85BDhWQ-rVAsNb6yDNSWuw) 그러나 나는 이 수치만 보면 솔직히 많이 의하스럽다. 이 정도의 Orb로 그렇게 춤을 춘다는면 1° 미만인 사람들(대략 12월 초순에 태어난 사람들)은 얼마나 더 잘 출지 놀라워서라고나 할까…라고, 솔직히 강하게 의문이 들었고 단지 Mercury-Mars Conjunction 만으로는 분명히 설명되지 않기 때문에 제나의 Mars와 Venus Network을 살펴보았다. 아래 그래프에서 파란색 선은 흐름유도위상이는 그룹이고, 빨간색은 그 반대이다. 앞서 강조했듯 추정한 시간대를 마치 진짜인 것 처럼 들릴 수 있기 때문에, 나는 대단히 조심스럽다. 특히 1~2분 단위로 달라지는 ASC/DSC/MC/IC/Vertex 그룹은 절대 추정으로 얘기해서는 안되므로 말을 아낄 수 밖에 없다. Moon 역시 정확한 시간을 알지 못하면 얘기해서는 안되므로 아래 데이터들은 참조용이라고 분명히 못박아두는 바이다. 그러나 Sun-Mars, Mercury-Mars는 24시간의 변화에도 크게 달라지지 않는다. 따라서 내가 알고자 했던 “ 제나의 춤은 왜 다른가?” 라는 의문에는 충분한 근거로 보인다는 것이 내 생각이다. 제나 한 손가락으로 이동 / 두 손가락으로 확대·축소 / 두 번 탭하여 최대화·복귀 그래프 탭을 사용하려면 JavaScript를 활성화하세요. 제나의 Venus-Uranus 구조가 상당히 타이트한 Orb를 이루지만 Moon-Mars는 Conjunction 이라도 범위밖이다. Descendant-Mars가 훨씬 타이트하면서 좋은 흐름을 유도하고 있다. Network만 볼 때는 Mercury-Mars, ASC-Mars 두 구조가 핵심으로 보인다. (물론 ASC는 정확한 생시를 알아야 한다) 그러나 궁금증을 참지 못하고 제나의 Celestigram을 계산해보니, 제나의 춤이 왜 다른지에 대한 결정적인 단서를 발견하였다. 제나의 Mercury와 Mars는 Orb 값 외에도 하나처럼 동작할 수 밖에 없는 구조였다는 걸 알게되었고 이 글의 원초적인 질문에 대한 답을 발견하였다. (2008년 Mercury-Mars Conjunction 구간에 태어난 모든 사람들은 대단한 능력을 가졌다) Mercury-Mars가 Conjunction 이므로, 분명히 제나는 악기 연주에 재능이 있을 것이라 생각하고 유튭을 뒤져봤더니, [역시나 피아노를 연줄할 수 있는 것으로 확인됐다](https://youtu.be/_zTSCOy5iFc?t=358). 어떤 사람이 프로답게 악기 연주를 할 수 있으려면 3가지 핵심 구조가 반드시 있어야 하는데, 제나는 그 중 두가지가 확실하므로 악기 연주 뿐만 아니라 학교를 제대로 다녔다면 상당한 성적을 보이는 학생이었을 것임을 알수 있었다. 제나는 행동파다^(doer). --- 제나와 다른 멤버들의 춤실력이 어떻게 차이나는지 단순하게 비교하기 위해 리더 원이 차트를 보았다. 내가 보고자 한 것은 기본적으로 타고난 재능의 유무와 강도^(STRENGTH) 이다. 그러나 당신은 곧 의문이 들기를 “재능의 유무와 강도를 어떻게 알수있는가?” 라고 생각할 것이다. 그것에 대한 얘기는 이 게시물에서 하지 않는다. 그저 나는 리센느 멤버의 충실력에 대한 가벼운? 의문이 있었고 그것을 분석한 것을 기록하는 것만 이 게시물에서 진행할 것이다. 원이 오른쪽 버튼을 누른 채 위아래로: 확대·축소 / 왼쪽 버튼을 누른 채 이동: 그래프 이동/ Enter: 크게 보기·복귀한 손가락으로 이동 / 두 손가락으로 확대·축소 / 두 번 탭하여 최대화·복귀 그래프 탭을 사용하려면 JavaScript를 활성화하세요. 원이 역시 춤실력은 타고났다. 제나와 다른 점은 실시간으로 자기가 원하는대로, 생각이 가는대로 맘대로 몸을 움직일 수 있는 무의식레벨의 춤은 출 수 있는 타입은 아닐 가능성이 있다고 말할 수 있다. 가능성을 붙이는 건 제나와 달리 Mercury-Mars가 Sextile 연결을 보이고 있기 때문이고, 다른 숨겨진 구조(Celestigram)를 보니 원이의 Mars는 완전 춤꾼의 특징을 보일 수 없는 구조였다. 그러나 추정한 시간대가 맞다면 원이는 다방면에 한다면 하는 능력을 타고 난 것이 확실하다. 눈에 띄는 건 Mars-Saturn Conjunction이 무려 0.06 이라는 점인데, 이 구조는 정말 많은 것을 얘기해준다. 다만 이 게시물에서는 진행하지 않고 따로 분석을 올릴 것이다. --- 이제 항상 본인의 흐름을 가지는 리브를 보자. 리브 그래프 탭을 사용하려면 JavaScript를 활성화하세요. 리브는 Mercury-Mars 구조가 명시적으로 없지만 Venus-Mars 구조가 Conjunction이다;; 그러나, 어우… 리브는 정말… 장난 아닌 구조를 가졌다. 리브의 입담은 Mercury-Uranus Trine 0.04 구조가 증명한다. 엄청난 순발력, 엉뚱하다고 불리는 리브의 표현은 그냥 자동으로 머리속을 엄청난 속도로 지나가는 생각중의 하나이다. 하지만 거의 모든 구조가 흐름을 유도하는 구조들이라 더 알아보고 싶다. --- 아래 그래프에서 보이는 위상구조는 안원잘부를 통해 본 미나미의 모습을 정말 잘 설명해준다. 미나미 그래프 탭을 사용하려면 JavaScript를 활성화하세요. 확실히 미나미의 춤선은 Mercury-Mars Conjunction, IC-Mars Trine 에서 비롯된 것이다. 미나미의 Mercury와 Mars는 하나다. 다만 본인의 느낌에 집중하는 제나와 달리 조화와 균형쪽으로 치우쳐 있으므로 춤선이 약간 정석에 가까운 경향을 띌 수 있다. 미나미는 자신의 정체성과 감정이 깊다. 그 깊음을 조화와 균형을 염두하면서도 추구하는 미적표현는 확실한 방향성을 가지고 있으며 그 기준에 대단히 민감하다. --- 뭘 해도 귀여운 메이의 경우를 보자. 메이 그래프 탭을 사용하려면 JavaScript를 활성화하세요. 메이는 Mercury-Mars 구조는 없다. 그외 춤과 연관된 눈에 띄는 구조가 없지만, Mercury- Venus 구조가 강한 아름다운 여자인 걸 한눈에 알 수 있다. 성격 뿐만 아니라 보는 시각과 생각도 상당해서 아름다움이 어떻게 발현되는지 좋은 참고가 될 것 같다. 메이의 쉬지않는 대사는 Mercury-Jupiter Trine, Mercury-Venus Conjunction 영향이다. 쉬지않는 입에서 말이 나온다고 해서 아무 말이나 내뱉는 구조는 아니다. 오히려 세상을 구조적 시각으로 보고, 감정은 타인에게 기대지 않는다. 구조적으로 본다는 의미는 세상이 움직이는 원리, 사람사이의 역학, 감정의 흐름등을 피상적으로 보지 않고, 각각을 구성하는 근본적인 것들로 구분하면서 각각이 어떤 관계를 가지고 어떤 요건에 의해 반응하며 달라지는지 인식하고 느낀다는 것이다. 그래서 말이 많은 것일수도. 나이가 들면서 성숙하게되면 존재감을 더 발산하면서 타인과 세상에 대해 표현을 아끼지 않을 것 같다. --- 지금까지의 내용은 아주 단순한 호기심에 의해 살펴본 내용 일부를 공유했을 뿐이다. 리센느 멤버에 대한 모든 내용이 아니며 그저 춤추는 것과 관련한 한가지 사소한 관점만 공유했을 뿐임을 분명히 밝혀둔다. 재차 언급하지만 이 게시물에서 언급된 모든 데이터는 추정 시간을 기반으로 했기 때문에 멤버 각각의 실제 태어난 시간과 다를 수 있다. 다만, 24시간 범위내에서 크게 변동이 없을 것 같은 것 중에서 하나를 얘기한 것일 뿐이다. ## Claude Startups 지원 프로그램에 얽힌 이야기 - Link: https://andrwj.com/0,xwq,1/ - Published: 2026-10-09T07:52:23+09:00 - Author: A.J #### 한가닥 가능성을 발견했을 때 > Claude를 기반으로 제품을 만드는 창업자들과 함께하세요. Claude Team 1년 무료 이용권, > API 크레딧, AI-native 기업 운영에 도움이 되는 툴 특별 혜택, Anthropic Applied > AI 팀과의 오피스 아워 등 다양한 혜택을 누리세요. > [https://claude.com/ko/programs/startups](https://claude.com/ko/programs/startups) Claude의 Startups 지원 소식을 듣기 전까지는 공허한 마음에 삐끗한 허리로 인해 움직이기도 힘들고 기분도 더럽고 멍하게 있었다. 1년동안 무료지원이라니… 그것도 도메인과 메일주소만 있으면 된다는 내용에 급속충전을 시작한듯 머리속에서 여러 생각이 스치고 지나간다. 외부에는 아직 보일 수 없지만 뭐 그래도 `.app` 도메일이 있으니 메일만 어떻게 처리하면 될 것 같았다. 그 도메인은 OCI VPS에서 동작중이라 ChatGPT에 메일서버 셋업방법을 조사해서 보고하라고 날리고, 20% 의 기대가 섞인 맘으로 아무것도 하지 않았다. 지난 20년동안 메일서버 셋업을 수도 없이 했었지만 더 이상은… 거부감이 든다. 그래도 Codex 또는 Opencode CLI를 불러서 시키면 되니까 일단 조사하라고 시킨 것이다. 조사 보고서를 보니 곧 바로 기분이 더러워 졌는데, 이는 Mercury-Neptune Opposition 구조때문 일 것이다. 내용은 많으나 불확실하고 정리가 덜 되어 있는 경우에 대한 반감일까? 그래서 그 M-N 구조의 방해를 물리치기 위해 조건을 더 타이트하게 걸고 2개만 제안하라고 했더니 **Mailu** 로 낙점됐다. AI 시대 이전에 메일서버를 셋업하는 것은 손가락 부러트리는 짓을 일부러 하는 것 같았다. 많은 것을 알아야 하고, 시간을 엄청나게 소비했으며, 당연하게 보이는 스팸메일 필터링 기능을 추가하는 건 쉬운 일이 아니었다. 게다가 DNS 설정과 메일 서비스 콤포넌트 구성을 하는 것은 다른 곳에서는 정말 아무짝에도 쓸모없는 지식이 너무 많이 필요했으며, 설령 성공적으로 셋업한다고해도 Google Mail에서 차단 당했던 기분 나쁜 기억들 때문에 Claude Startups 지원을 위해 메일 서버를 셋업하는 것 조차 거부감이 들었던 것일수도 있다. 그럼에도 불구하고 AI 시대 이전에는 “내가 직접 처리해야 했기 때문에”, 어떤 식으로든 지식으로 남았다는게 다르다. #### 단계적 접근 Mailu와 관련된 10가지의 콤포넌트를 셋업하는 ChatGPT의 기본 설계를 가지고 OCI VPS 에서 Opencode + kontexus-mcp를 사용해서 순차적으로 처리하기로 했다. AI 이전 시대에서 이 과정을 진행해야 한다고 들었다면, 절대로 하지 않았을 것이다. 그러나 지금은 서버에는 Coding Agent가 대기하고 있고 웹에서는 ChatGPT Desktop이나 Alike가 대기하고 있다. 어떤 패키지를 써야 하는지 몇일 동안 찾고 분석하며 검증하는 과정이 내 실력을 키운 것임에 틀림없지만 그짓을 다시 하고 싶지는 않다. 메뉴가 어디 처박혔는지 찾아내는 것 조차 짜증나는 OCI 서버와 Google Gmail과의 소통을 위해 추가적으로 셋업해야하는 DNS 설정, 이를 테면 OCI 쪽에서 해줘야 하는 PTR 설정과 SPF, DKIM, TLS 설정을 쳐다보는 것 자체가 스트레스다. 다행히도 Coding Agent 와 ChatGPT chrome extension 덕분에 속에서 부대끼는 강한 거부감을 거튼 걷듯이 하나씩 걷어나갈 수 있었다. 이제는 그냥 알기도 싫고 알게된다고해도 가치를 느끼지 못하는 건 빌어먹을 세상이 결과만을 더더욱 강조하게 되었기 때문일 것이다. 이제 그 누가 메일서버 셋팅하면서 날밤까며 문제를 잡으려고 할까;; 이제 그런 날들은 역사 만화에나 나오지도 않을 그런 시대이다. 64Kbytes RAM안에 코드를 집어넣기 위해 한 바이트도 덜덜 떨며 코딩하던 것이 실력을 키워주는 것으로 보이기 보단 궁상맞을 짓이며 누구도 그딴 짓을 하려고 하지도 않고, 해야할 이유도 느끼지 못하는 시대. 답답하고 무기력한 느낌이 드는 이유는 그것 때문인가? Mercury-Neptune Opposition 구조의 한가닥 희망에 급격한 에너지 방출 현상을 보이기도 하지만 기대와 다를 때 그 들뜬 마음이 식어버리는 속도 또한 액체질소로 얼리는 속도에 버금가는 특징 때문일 수도 있다. 아뭏든 kontexus-mcp를 통해 단계를 나눠서 하나씩 해치울 수 있어서 몇 시간만에 겁나 복잡했던 설정을 마무리 할 수 있었다. ![](https://andrwj.com/wp-content/uploads/2026/10/mailu-setup-1024x564.png?e=1794704031& st=OXhziCqLn9jqBmxw5XnZcA) #### ChatGPT extension이 서버와 통신하게 하면, 난 할게 없겠다는 생각이 들었다 DNS 설정을 조정하고 OCI Mail 인증을 위해 복잡한 과정을 겪고 있을 때, OCI VPS에서의 Codex가 내놓는 보고를 ChatGPT extension으로 복사하는것도 귀찮았다. ChatGPT의 Computer Use 를 사용하면 로컬 macOS까지는 문제없을테지만 OCI VPS 쪽은 kontexus-mcp로 제어되고 있으므로 하나의 프롬프트로는 처리하기 난감한 상황이다. OCI VPS는 TailScale, OpenVPN 두개의 VPN 환경이 맞물려고있고 OCI쪽 포트보안과 내부 GeoIP 제한 및 복잡한 iptables 설정이 얽혀있다. 게다가 NGINX가 셋업하는 사이트 접근은 3개의 환경에 따라 다르게 반응하도록 되어 있어서 “사용설명서” 즉, AGETNS.md 파일이 제법 길다. Chrome Browser 의 ChatGPT extension은 Gabia쪽 DNS 셋업에는 더할 나위없이 간편하게 해주지만 OCI 쪽의 그 instruction을 문맥에 넣고 OCI 환경을 연결하는 MCP 서버를 적용할수가 없다. 그래서, 결국 두개의 OpenAI 모델에 메세지 중계하는 게 내 역활이 되는 것이다. 셋업은 어찌 어찌 처리되지만, 내겐 어떤 지식도 깊게 자리잡질 못한다. “내가 하는게 아니기 때문이다”. 그냥, 귀찮다. 원래 시작은 Claude API를 1년간 무료로 지원받을수도 있다는 가능성 때문이었고, 신청한다고해도 당선된다는 보장은 없기 때문에 모델 사이에 메세지 중계를 하는 것 조차 기술적인 의미도 느끼지 못하고 내 지식화 되지도 않는다고 직감이 알고 있어서 인지, 셋업 하는 것 조차 스트레스인 것 같다는 생각이 든다. #### 빚이 없고 먹고 살길이 있으면 재미날 것이다 난 벼룩시장으로 직장을 구하던 시대를 지나 C,Perl 언어로 CGI 방식으로 웹 서비스를 만들었고 Python기반의 Zope와 PHP를 지나 mod_perl + apache, mod_php+nginx 등으로 백엔드를 만들던 시대를 지나왔다. FreeBSD 커널 기반 방화벽을 만들었었고 Python/Perl 로 국가연구자망을 3년동안 유지보수 했으며 JavaScript로 웹브라우저에서 의료영상뷰어( DICOM)를 만들면서 엄청난 재미를 경험하고 ExtJS 소스를 분석해서 백엔드에서 프론트로 전향했으며 Dart를 남들보다 4년전에 접했고 WASM으로 게임을 돌려보려는 수작의 재미남을 경험해왔다. 하나같이 다 마이너한 것들이지만 “재미”를 부정하진 않는다. 한 때는 JavaScript 로 모든 것을 하려했고 먹고살기위해 Flutter로 농X의 모바일 앱을 만들고 유지보수했었다. 수입을 위해 코딩한 것들도 거의 다 재미있었다. 의미도 있었고… 적어도 이렇게까지 스트레스 받으며 코딩하지는 않았다. #### 그때의 가치는 시대가 없애버리는 듯 메일 서버는 셋업되었고, 덕분에 Claude Startups 지원 프로그램에도 무사히 신청서를 낼 수 있었다. 작업 시작한 지 대략 4~5시간 정도 걸린듯하다. 옛날 방식대로라면 못해도 꼬박 하루 정도 걸리면 엄청 빨리 한 것이고, 걍 될대로 되라 하면서 셋업했다면 5일은 걸릴것이다. 이럴 바에야 차라리 Google Workgroup 서비스에 1~2달만 가입하는 것도 방법일 것이다. 계정당 $7 정도밖에 비용이 들지 않으니 도메인 메일 하나 쓰자고 5시간 스트레스 받으면서 뻉이치느니 그냥 그 비용내고 맘편히 신청서 내는 것도 방법임에 틀림없다. 다만, 옛날 처럼 스스로 서비스를 셋업하면서 배우는 즐거움이 남아있을 것이라 착각한 것일 뿐이다. “결론만 본다면” 4~5시간 걸려서 메일서버를 셋업하는 건 정말 ㅂㅅ짓거리다. OCI VPS 에서 동작하는 OpenAI 모델 사용료와 ChatGPT extension으로 사용하는 모델 사용료는 땅에서 솟아나지 않는다. 그 비용이면 Google Workgroup 서비스에 도메인 등록해서 메일서비스를 못해도 1년은 유지할 수 있을 것이다. 즉, 내가 스트레스 받는 것은, 이제는 배움을 위해 시간과 비용을 들이는 것이 병신 짓거리로 전락하는 시대인것과 배운 것이 도둑질이라 나이들어 딱히 이 상황을 벗어날 뾰족한 방법이 보이질 않는다는 답답함 때문일 것이다. #### 결국 몸으로 하는 일을 찾게될 듯 나는 Mercury-Pluto Trine 구조의 Orb가 0.78 인, 아주 타이트한 분석력이 자동으로 동작하는 타입이다. 거의 모든 요소와 어떤 식으로든 위상 연결되어 있는 Pluto Network와 Venus Network 덕분에 원리의 발견이 내겐 가장 큰 즐거움이었고 원동력이었다. 종이를 긁는 만년필 펜촉의 거친 진동을 사랑하고, 굳이 사진이 아닌 손으로 그려내는 것을 앙망한다. 다음에 태어나면, 그때는 눈 뜨자마자 꼭 바이올린을 먼저 배우겠다. 그리고 다음 생애에선 그림 그리는 게 먹고살 방법이 아니라고 주변에서 아무리 지랄대더라도, 절대 고수하고 싶다. 목공과 대장장이의 기술을 결합해서 집을 짓는 직업을 가져도 괜찮겠다. 어떻게 언제 이 세상을 뜰지 모르지만, 그때까지 언어를 배우는 즐거움은 고수하고 싶네. ## Audio 사용이 가능한 pebble-qemu-wasm - Link: https://andrwj.com/pebble-qemu-wasm/ - Published: 2026-10-07T05:23:44+09:00 - Author: A.J [uConsole에서 삽질하며 수정](https://andrwj.com/pebble-qemu-development-on-uconsole-with-physical-controls/) 한 [QEMU Audio 코드를 **PR**](https://github.com/ericmigi/pebble-qemu-wasm/pull/3) 했다. Eric이 바뻐서 테스트해보기나 할지 몰라, 내 브랜치를 만들어서 몇가지 수정하여 연결한다: ## structura.lisp - Link: https://andrwj.com/structura/ - Published: 2026-10-05T15:10:32+09:00 - Author: A.J #### Abstract `structura.lisp`는 위상기반 구조판독을 프로그램으로 표현하기 위해 만들기 시작한 Common Lisp 패키지이다. Rust로 작성한 [Aspectscope-MCP](https://andrwj.com/aspectscope/)는 Swiss Ephemeris 를 기반으로 Natal, Transit, Progress Chart를 계산하고, Aspect와 Aspect Pattern 및 CSF, Celestigram을 탐색하며, 특정 조건이 성립하는 시점을 찾아내등 LLM을 끼고 기본적인 역할을 해왔다. HTTP 방식의 MCP 서버이기 때문에 LLM Agent 역시 필요한 계산을 직접 요청할 수 있다. 그런데 계산할 수 있다는 것과 판독할 수 있다는 것은 다른 문제이므로 AspectScope가 알려주는 것은 특정 시점에 어떤 천체가 어디에 있고, 어떤 Aspect가 형성되며, 어떤 Pattern이 존재하는가와 같은 비교적 결정론적인 사실에 국한된다. 실제 구조판독에서는 여기에서 다시 여러 요소의 관계를 연결하고, 직접 관계와 간접 관계를 구분하고, Pattern 이나 CSF를 통과하는 Pathway를 찾으며, 시간에 따라 어떤 구조가 생성되고 약화되고 사라지는지 등, 간단히 주어진 몇개의 데이터로 판단하는게 아니라 그래프 데이터에 기반해서 판단해야 한다. 지금까지는 이런 부분의 상당량은 문서화된 구조판독지침을 LLM이 읽고 적용하는 방식으로 처리했다. 이 방법은 유연하지만, 반복해서 계산할 수 있고 명확한 규칙으로 표현할 수 있는 부분까지 매번 LLM의 추론에 맡겨야 한다는 문제가 있다. structura. lisp은 바로 그 사이의 계층, 즉 가능한 계산할 수 있는 한계까지 미리 계산하거나 프로그램으로 처리하기 위한 프로젝트이다. AspectScope가 천문학적 사실을 제공한다면, Structura는 그 사실들 사이의 관계와 구조를 계산한다. 그리고 LLM은 이미 계산된 구조를 바탕으로 최종적인 의미를 판독하고 인간의 언어로 표현할 것이다. #### Why Common Lisp? 구조판독 규칙은 완성된 알고리즘이지만 계속 발견되고 수정되는 지식에 가깝다. 어떤 관계를 직접 연결로 인정할 것인지, 위상구조 내부의 관계를 어떻게 전파할 것인지, 여러 구조가 중첩될 때 어떤 관계를 우선할 것인지와 같은 규칙은 계속 변하고 조정되야 한다. 이런 작업에는 프로그램을 수정하고 다시 컴파일하는 방식보다, 실행 중인 시스템 안에서 규칙을 정의하고 즉시 적용해 보는 Common Lisp의 REPL 중심 개발방식을 생각하지 않을 수 없다. 또한 Lisp에서는 코드 자체가 데이터이므로 구조판독 규칙을 단순한 함수의 집합으로 만드는 대신, Lisp 표현식으로 정의된 하나의 Domain Specific Language로 발전시킬 수 있다. 규칙 자체를 검색하고 검사하고 교체할 수 있으며, 같은 규칙으로 실행 코드와 설명, 검증 로직을 만들어내는 것도 가능하다. #### structrua vs. structualis Structura 내부에서 규칙을 처리하는 컴포넌트에는 `structuralis`라는 이름을 사용한다. **structura** 가 여러 요소와 관계가 만들어낸 **구조 그 자체**를 의미한다면, **structuralis** 는 그 구조를 **구조적으로 판별하는 방법**을 의미한다. #### 1st implementation plan * AspectScope-MCP와 통신하여 계산 결과를 Common Lisp의 내부 객체로 변환하고, * 그 위에서 판독 규칙을 등록하고 실행하는 기능부터 구현 예정. * 규칙이 어떤 조건에서 성립했는지 근거를 추적할 수 있게 하고, * 같은 입력과 같은 규칙에는 동일한 구조적 결과가 나오도록 하는 것이 첫 번째 목표입니다. * 이후에는 Aspect, Pattern, CSF 등의 관계를 하나의 그래프로 표현하고, 두 요소 사이의 Pathway를 탐색하거나 서로 다른 시점의 구조를 비교하여 새로 발생한 관계와 소멸한 관계를 찾아내는 기능을 추가한다. * Transit과 Progress Chart 역시 단순히 두 개의 Chart를 비교하는 것이 아니라, 시간에 따라 구조가 어떻게 변화하는지를 추적하는 방향으로 확장한다. * 장기적으로는 structura 자체도 MCP 서버가 될 수 있다. 그렇게 되면 Agent가 AspectScope 의 저수준 계산 결과를 일일이 조합할 필요 없이 `find-pathway`, `compare-structure`,` evaluate-rule` 같은 구조판독 명령을 직접 사용할 수 있을 것이다. (CLisp은 C로 포팅 & 컴파일 된다) AspectScope가 **무엇이 존재하는가**를 계산한다면, structura는 **그것들이 어떻게 연결되어 있는가**를 계산한다. 그리고 최종적으로 LLM은 **그 구조가 무엇을 의미하는가** 를 판독한다.^(2610051510) structura.lisp 패키지는 이미 구현되었고 어쩌면 제법 길수도 있는 검증 과정을 거칠 것이다. ## speak-mcp on Zeno.app - Link: https://andrwj.com/speak-mcp/ - Published: 2026-09-26T12:56:29+09:00 - Author: A.J #### Zeno.app – 16GB Mac에서 35B 로컬 AI를 돌리는 흥미로운 실험, 그러나 아직은 실험에 가깝다 최근 [Icosa Computing이 공개한 Zeno](https://icosa.co/)라는 macOS용 로컬 AI를 설치해 보았다. 회사 설명에 따르면 전체 MoE expert를 메모리에 올리지 않고, 사용되지 않는 expert weight는 SSD에 두었다가 필요한 expert만 RAM으로 읽어들이는 방식을 적용하여 inactive expert를 SSD에 보관하고 필요한 expert만 RAM으로 불러온다고 설명하고 있다. 뭐… 설명이 어떻든, 결국 내가 하고자 하는 일^(인문구조학)에는 쓸수가 없다. 대략 2 페이지 정도는 출력하는 것 같지만 내용에는 군데 군데 엉터리가 보이다가 몇 페이지 더 지나면 정신을 잃고 혼절하듯 헛소리만 계속 내놓는다. 비싼 M4 장비에서도 이런 정도도 할 수 없다는 게 정말 빡치는 일이다. **더 흥미로운 것은 LMShop이다** [LMShop](https://www.lmshop.com/)은 현재 IBM Granite 4B, Google Gemma 12B, Qwen 3.6 35B 등을 기반으로 사용자가 올린 문서에서 training set을 만들고 LoRA tuning을 한 뒤 결과 모델을 GGUF로 다운로드하게 한다. 그리고 이 모델을 다시 Zeno에서 로컬로 사용하는 그림을 그리고 있다. Zeno/LMShop 이 오픈소스가 된다면 로컬 AI를 구동하는 방법에 획기적인 방향전환이 일어날 수 있겠다. --- #### 매 턴마다 영어/한국어를 macOS TTS로 출력하게 했다 앞서와는 다른 목적으로, 로컬에서 음성으로 말하고 음성으로 듣기 위해 [speak-mcp](https://github.com/andrwj/speak-mcp) 를 조금 뜯어고쳐 각 언어마다 다른 Voice를 쓰게 했는데, AGENTS.md 규정을 따를 때가 있는가 하면, 개무시하고 기본적으로 박혀있는 system prompt를 따라가곤 했다. Qwen 35B 모델의 멍청함이란;;; 휴… 인수가 2개인 MCP 도구에서 locale을 판단해서 호출해야 하는 것 조차 매번 명시적으로 지정해야만 제대로 읽는다. 출력해야할 내용의 로케일을 선택하도록 Tool Description 에 박아뒀어도 그러네;; 설령 읽는다해도 한국어 Voice로는 영어 단어나 문장 표현을 병맛스럽게 읽기 때문에 이걸 써먹기는 정말… 애매…하다. Voice가 영어인 경우, 화자 선택지는 좀 있으나 다른 언어가 섞이면 영락없이 해당 부분은 무음이 된다. Zeno.app 소개글에는 앱을 사용할수록 Qwen 모델의 Weight를 변화시킨다는데… 글쎄; 그걸 확인할 방법도 UI도 없다. 가지고 노는 정도 외에, 제품으로서는 아직 추천할 정도는 아닌 것 같다. 그러나 32B 모델이 이렇게 돌아간다는 건 고무적인 일임에는 틀림없다. 누군가에겐 쓸만할지도. [Whispree.app](https://github.com/Arsture/whispree) 또는 [Handy.app](https://github.com/cjpais/handy) 앱을 사용해서 음성을 Text로 (STT) 입력하고, Text와 함께 speak-mcp로 출력하게 하면 대충 소리로 대화하는 느낌은 알수있다. 내 목소리를 그대로 분석하는게 아니기 때문에 본격적인 외국어 학습용도로 사용하긴 아쉽다. 그래도 웹 문서를 검색해서 읽어달라고 하는 것 같은 간단한 일은 그럭저럭 가능하다. 음성 출력은 굳이 Qwen 35B를 사용할 것도 없이 LMStudio + gemma-4-e4b 에서도 가능하다. 다만, [gemma-4-e4b jinja template](https://andrwj.com/wp-content/uploads/2026/09/gemma-4-e4b.jinja) 을 수정해야 한다. ## Saffron Ink – VSCode Theme - Link: https://andrwj.com/saffron-ink-vscode-theme/ - Published: 2026-09-24T13:58:09+09:00 - Author: A.J [Gray background: Github Light Theme – Gray](https://marketplace.visualstudio.com/items?itemName=Hyzeta.vscode-theme-github-light) 테마를 기반으로 내 취향에 맞게 수정하였다. * 원래 테마보다 좀 더 어두운 배경, 강한 텍스트 대비를 주었다. * 선택영역 색상 및 커서 색상을 쪼매 튀게. * 각 영역의 border-radius 제거. * scrollbar 색상을 배경색 대비 3% 어둡게. [https://marketplace.visualstudio.com/items?itemName=andrwj.saffron-ink](https://marketplace.visualstudio.com/items?itemName=andrwj.saffron-ink) ![](https://raw.githubusercontent.com/andrwj/saffron-ink-vscode-theme/main/screenshot1. png) ![](https://raw.githubusercontent.com/andrwj/saffron-ink-vscode-theme/main/screenshot2. png) ## Pebble QEMU Development on uConsole with Physical Controls - Link: https://andrwj.com/pebble-qemu-development-on-uconsole-with-physical-controls/ - Published: 2026-09-21T09:17:57+09:00 - Author: A.J ![](https://andrwj.com/wp-content/uploads/2026/09/pebble-qemu-on-uconsole-768x1024- 1.jpg?e=1794704031&st=vgUemR3_-D48CCPhkC4Ncw) #### 의도 기본 생각은 단순하다: **uConsole의 Joystick Keys 와 물리키보드를 이용해 Pebble QEMU Emulator에 직접 버튼/ 터치/가속도데이터 등을 전송하여 개발/디버깅 하겠다**는 것이다. 왼쪽 이미지에 보이는 Pebble앱은 한국어(한글) 모르스부호 연습기 앱인데, 단순히 한글 자모를 출력하는게 아니라 한글 오토마타를 내장해서 모르스부호를 입력하면 한국어 문장이 조립된다. 죽도록 버튼을 누르지 않고 화면 터치만 사용하게 했기 때문에, 제대로 동작하는지 확인하려면 Pebble Time 2 실물기기에서 테스트하는 것이 가장 정확하겠지만, 심각한 배터리 사용이 걱정스러웠다. 실제 기기를 오래쓰려면 이런 개발 과정을 Emulator에서 실행해야하지만, macOS 상태에서 테스트하는 것보다, 벽에 달려 놀고있는 uConsole을 활용하자는 생각이 떠올랐다. #### 구현 아이디어 GamePad 키를 QEMU로 전송하는 방식은 오래전에 이미 사용했던 방법이 있다. [RetroPie Joy2Key 방식](https://github.com/RetroPie/RetroPie-Setup/tree/master/scriptmodules/admin/joy2key) 이다. 그때는 AI가 없어서 직접 코드를 내가 원하는 방향으로 쓰기위해 시간을 제법 쏟아 부었던 적이 있으나, 지금은 뭐 AI 도움을 받아 거의 막힘이 없다. 구현 제한 사항은, 반드시 페블 앱에서 발생하는 Audio를 QEMU를 통해 들을 수 있어야 한다는 점이다. 그게 아니면, 이딴 건 의미 없다. #### 삽질로 드러난 아이디어 구현의 걸림돌 ① 실제 Touch 처럼 자유롭게 입력을 넣는 건 좀 더 시간이 걸리듯. * Touch 인식은 QEMU 앱 소관이라서 외부에서는 Virtual Touch Event Signal 정도만 날릴 수 있다. * QEMU 화면이 resize 되면 touch 위치 인식 불능. Pebble Firmware를 수정하거나 페블 앱을 작성할 때 상대크기로 작성해야 한다. * Ctrl+마우스 움직임 또는 Ctrl+Drag 등의 키 조합을 가상 이벤트로 날릴 수 밖에 없다. ② 입력 종류마다 다른 방식으로 처리해야 함. * QEMU와 통신 방식이 4가지: pypkjs, WebSocket, QMP(unix socket), raw_tcp * 포트는 두가지: 포트마다 적절한 시그널을 보내는게 제한된다. 올바르지 않은 채널에 시그널 부어버리면 페블앱을 전환할 때 마다 WebSocket이 죽어버릴 수 있음. ③ pypkjs는 Settings 때문 필수. * 따라서 실질적으로 QEMU와 통신수단으로써 남은 선택지는 WebSocket 또는 raw_tcp 채널을 써야 한다. * pypkjs process의 생존 여부 + QEMU process 생존여부 + WebSocket server process 생존여부가 조합된 상태에 따라 강제 재 기동 혹은 멈춤을 결정해야 함. 이게 뭥미;; * raw_tcp를 사용할 경우 포트 충돌. ④ Audio 품질이 개 구림. * PebbleSDK에 포함된 emulator.py 스크립트에 audio 드라이버가 아예 누락됨. 수정해서 써야하는데, 현재로써는 SDK 업데이트마다 배포된 emulator.py 파일을 수정해서 사용해야 한다. * 찌그러짐, 늦게 반응, 버퍼 밀림 등의 이상 증상을 보임. * Gemini-3.8-Flash High + gpt-5.5 High 조합으로 12시간 넘게 추적 결과 어이없게도 QEMU RTC 모듈의 말도 안되는 시간처리 코드 때문인 것으로 드러남. * 같은 맥락으로 Firmware speaker_service.c 에서도 time_ms() 가 개판이라 buffer underrun 및 지터링 발생할 수 밖에 없는 코드로 확인됨. * PebbleOS speaker stream과 QEMU pebble-audio 장치의 시작 시퀀스가 맞지 않고, SDL audio driver 대신 PipeWire PulseAudio(pa)로 전환해야 했음. #### Audio 문제 원인 파악을 위해 사용한 접근법 아래와 같이 문제를 발생시키는 원인을 특정하거나 좁혀가는 방법을 적용했다. ① 추측 금지 * Local macOS에 PebbleOS 소스를 clone 받아두고 Pebble Firmware 및 QEMU 동작관련 코드를 확인케 했다. * 실제 동작은 Remote uConsole 에서 확인해야 하므로 ssh로 접근하는 데서 많은 토큰 소모가 발생했다. ② 고치라고 요구하는 내용에 더해, 완료시 접하게될 상태를 더 했다 * “이 요청이 계획에 따라 수행되면 사용자는 다음과 같은 상태를 기대한다” 라는 식으로, 어떤 상태를 기대하는지, 해야하는지를 기술했다. LLM모델이 학습한 방식을 적용한 것이다. * 그치만, Gemini 병신은 단정적이고, GPT 고자놈은 뭘 어떻게 해도 멋대로 확장해서 해석한다. 오지게 패고싶다… ③ 문맥 유지를 위해 [kontexus-mcp](https://andrwj.com/kontexus-mcp/)를 사용했다 * 엄청난 양의 출력을 굳이 문서로 만들 필요없이, LLM이 Chatting 내용을 언제든 검색할 수 있으므로, 토큰을 아끼고 문맥 포화를 최대한 막기위해 세션을 여러번 재시작 하며 이어갔다. * LLM 스스로 가설을 나열하고 하나씩 실행하면서 범위를 좁혀갈 때, 문맥포화로 인해 멍청해 지지 않도록 kontexus-mcp가 지속적으로 상태를 유지하고 결과를 기록하여 끊임없이 LLM에게 주입하였다. 그럼에도 불구하고 실제 원인 파악은 인간인 내가 감으로 때려잡았다. LLM ㅅㄲ들은 자꾸만 문제를 확장시키거나 돌아가는데, 어떤 특정 오류 패턴에서 시간 문제인 것 같다는 느낌이 들어 RTC(realtime clock) 코드를 팠던 것이 핵심. #### 최종 삽질 결과 * Dynamic Audio Generator 류의 페블 앱을 제외한다면 거의 모든 영역의 페블앱을 uConsole 에서 생성/테스트/디버깅을 할 수 있다. * 이 삽질을 하게 만들었던 모르스부호연습기 앱은 안타깝게도 소리가 시작되는 시점에서 음이 갈라져서, 지금은, 실제로 활용을 할 수가 없다. * 언젠가 다시 QEMU와 Firmware를 건드릴지 모르겠지만, 어디 격리되서 할 짓이 마땅이 없을 때 해결해볼 꺼리로 남겨둔다. * 페블 실제 기기에서는 아무런 문제가 없지만 QEMU에서만 발생하는 문제다. * 덕분에 `pebble-mcp` 도구를 어떻게 만들지에 대해 아이디어가 정리됐다. #### pebble-mcp 도구 설계 스케치 * PYPKJS는 CLI에서 직접 처리하고, QMP 채널로 signal을 날리게, 그리고 도구의 리턴값은 전이된 상태명을 돌리게 하는 방식이 적절할 것 같다. * MCP는 앱의 특정 동작을 유도하기 위해 상태전이를 시키는 시그널을 날리는 것으로 족하다. * 그리고 `--logs` 명령 등으로 로그를 파싱하게 하는 것보다 도구 호출의 리턴 값을 전이된 상태명을 전달하면, 상태전이 테이블은 코드에 있으므로 스스로 알아서 테스트를 할 것 이다. ## HERDR multiplexer - Link: https://andrwj.com/herdr/ - Published: 2026-09-19T11:57:25+09:00 - Author: A.J #### Why & What * [https://herdr.dev/](https://herdr.dev/) * (’26-SEP-18) HERDR 사용하기로 결정한 이유는 **① Rust로 제작되었다는 것**, **② Plugin 생태계가 꽤 성장세로 보여서**, **③ TMUX가 채우지 못하는 부분이 있어서** 이다. * **깔끔하게 hook을 설치/제거할 수 있다**는 점은 좋다. 그러나 integration hook은 설치하지 않는다. 불필요하게 모든 턴마다 hook을 걸어 하는 일은 겨우 모니터링이라서 제외. * CSI-u 표준을 지원하므로 **[TMUX에서 설정한 키맵](https://andrwj.com/lumi/)을 거의 모두 그대로 이전할 수 있다**. 마우스로 copy&paste 하는 여러 기능은 동작하되 복사관련 Look & Feel은 TMUX 쪽이 더 낫다. #### WHAT I DISAPPOINTED * `terminal-browser`, `terminal-code` 등이 유명한데 왜 이런거야?? code-server → 브라우저/Electron → terminal-browser → Herdr/iTerm 단계를 거치니 도저히 사용할 수 있는 상태가 아닌 것 같은데? * PANE 렌더링에 문제가 많다. TMUX와 병행해야 것다. * plugin 설치와 유지를 위해 clone 된 저장소를 계속 그대로 둬야한다는게 너무 거슬린다. 도대체 왜 그렇게 결정한 건지, 꼰대ㅅㄲ인가; * plugin이 겁나게 많은데, 정작 “와~” 스러운 건 별로 없다. 그나마 Mobile 중계 앱과 agent quota를 표시하는 건 TMUX 사용에서 건너올 가장 큰 명분 중 하나가 될 듯. ##### PLUGIN: 󠀁[https://github.com/levi-qiao/herdr-agent-quota](https://github.com/levi-qiao/herdr-agent-quota)󠁿 ![](https://andrwj.com/wp-content/uploads/2026/09/agent-usage.png?amp;st=YeAmxyt5hl5Y9WnepwqHgQ& e=1794704031&st=WE9HZIwdfuLnb1nH-wb_EQ) * 남은 토큰 상태를 사이드바에서 알려준다. * AGENT가 실행되고 있어야 한다. * [VibeProxy](https://github.com/automazeio/vibeproxy/) 를 통해 Antigravity IDE, Codex를 사용하는건 기본적으로 표시되지 않는다. * 이 플러그인의 AGY collector는 Antigravity IDE의 내부 사용량을 읽지 않고, agy CLI가 실행하는 statusLine JSON만 읽는다. ## Obsidian Web Clipper Setting for ChatGPT - Link: https://andrwj.com/0,nyj,2/ - Published: 2026-09-06T06:37:55+09:00 - Author: A.J [ChatGPT 채팅의 내용을 깨끗하게 Obsidian 앱으로 import](https://obsidian.md/clipper) 하는 설정. 현재로썬 이게 최선… 구분선 위의 빈줄을 한 칸으로 줄일 방법을 찾다 찾다… 그냥 쓰기로 .. ```language-twig {{selectorHtml:[data-testid*="conversation-turn"] |join:"" |remove_html:("img,svg,picture,source,canvas,object,embed,iframe") |remove_attr:("style,alt,aria-label,aria-description,title,srcset") |markdown |replace:"#### 나의 말:":"---\n\n# 질문:" |replace:"/\\n+#### ChatGPT의 말:/g":"---\n\n## 답변:" |trim}} ```