structura.lisp

Abstract

structura.lisp는 위상기반 구조판독을 프로그램으로 표현하기 위해 만들기 시작한 Common Lisp 패키지이다.

Rust로 작성한 Aspectscope-MCP는 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

Zeno.app – 16GB Mac에서 35B 로컬 AI를 돌리는 흥미로운 실험, 그러나 아직은 실험에 가깝다

최근 Icosa Computing이 공개한 Zeno라는 macOS용 로컬 AI를 설치해 보았다. 회사 설명에 따르면 전체 MoE expert를 메모리에 올리지 않고, 사용되지 않는 expert weight는 SSD에 두었다가 필요한 expert만 RAM으로 읽어들이는 방식을 적용하여 inactive expert를 SSD에 보관하고 필요한 expert만 RAM으로 불러온다고 설명하고 있다. 뭐… 설명이 어떻든, 결국 내가 하고자 하는 일인문구조학에는 쓸수가 없다. 대략 2페이지 정도는 출력하는 것 같지만 내용에는 군데 군데 엉터리가 보이다가 몇 페이지 더 지나면 정신을 잃고 혼절하듯 헛소리만 계속 내놓는다. 비싼 M4 장비에서도 이런 정도도 할 수 없다는 게 정말 빡치는 일이다.

더 흥미로운 것은 LMShop이다

LMShop은 현재 IBM Granite 4B, Google Gemma 12B, Qwen 3.6 35B 등을 기반으로 사용자가 올린 문서에서 training set을 만들고 LoRA tuning을 한 뒤 결과 모델을 GGUF로 다운로드하게 한다. 그리고 이 모델을 다시 Zeno에서 로컬로 사용하는 그림을 그리고 있다. Zeno/LMShop 이 오픈소스가 된다면 로컬 AI를 구동하는 방법에 획기적인 방향전환이 일어날 수 있겠다.


매 턴마다 영어/한국어를 macOS TTS로 출력하게 했다

앞서와는 다른 목적으로, 로컬에서 음성으로 말하고 음성으로 듣기 위해 speak-mcp를 조금 뜯어고쳐 각 언어마다 다른 Voice를 쓰게 했는데, AGENTS.md 규정을 따를 때가 있는가 하면, 개무시하고 기본적으로 박혀있는 system prompt를 따라가곤 했다. Qwen 35B 모델의 멍청함이란;;; 휴…

인수가 2개인 MCP 도구에서 locale을 판단해서 호출해야 하는 것 조차 매번 명시적으로 지정해야만 제대로 읽는다. 출력해야할 내용의 로케일을 선택하도록 Tool Description에 박아뒀어도 그러네;; 설령 읽는다해도 한국어 Voice로는 영어 단어나 문장 표현을 병맛스럽게 읽기 때문에 이걸 써먹기는 정말… 애매…하다.

Voice가 영어인 경우, 화자 선택지는 좀 있으나 다른 언어가 섞이면 영락없이 해당 부분은 무음이 된다. Zeno.app 소개글에는 앱을 사용할수록 Qwen 모델의 Weight를 변화시킨다는데… 글쎄; 그걸 확인할 방법도 UI도 없다. 가지고 노는 정도 외에, 제품으로서는 아직 추천할 정도는 아닌 것 같다. 그러나 32B 모델이 이렇게 돌아간다는 건 고무적인 일임에는 틀림없다. 누군가에겐 쓸만할지도.

Whispree.app 또는 Handy.app 앱을 사용해서 음성을 Text로 (STT) 입력하고, Text와 함께 speak-mcp로 출력하게 하면 대충 소리로 대화하는 느낌은 알수있다. 내 목소리를 그대로 분석하는게 아니기 때문에 본격적인 외국어 학습용도로 사용하긴 아쉽다. 그래도 웹 문서를 검색해서 읽어달라고 하는 것 같은 간단한 일은 그럭저럭 가능하다. 음성 출력은 굳이 Qwen 35B를 사용할 것도 없이 LMStudio + gemma-4-e4b 에서도 가능하다. 다만, gemma-4-e4b jinja template을 수정해야 한다.

Saffron Ink – VSCode Theme

Gray background: Github Light Theme – Gray 테마를 기반으로 내 취향에 맞게 수정하였다.

  • 원래 테마보다 좀 더 어두운 배경, 강한 텍스트 대비를 주었다.
  • 선택영역 색상 및 커서 색상을 쪼매 튀게.
  • 각 영역의 border-radius 제거.
  • scrollbar 색상을 배경색 대비 3% 어둡게.

https://marketplace.visualstudio.com/items?itemName=andrwj.saffron-ink