Skillpunk 아키텍처: 분산된 기술 자율성 vs. LLM 오케스트레이터

LLM은 함수를 호출합니다. 하지만 그들과 나란히 공존하지는 않습니다. LLM은 날씨 API를 호출하거나, 게임 가격을 가져오거나, 웹을 검색할 수 있습니다. 인상적이지만, 이러한 모든 도구 호출(tool calls)이 단 한 번의 실행 후 끝나는 'fire-and-forget(실행 후 망각)' 방식이라는 점을 깨닫기 전까지만 그렇습니다. 모델은 깨어나서 함수를 호출하고, 응답을 반환한 뒤, 유휴(idle) 상태가 됩니다. 지속적인 프로세스도, 백그라운드 틱(background tick)도, 응답 이후에 지속되는 행동도 없습니다.

LLM에게 다음과 같은 요청을 해보세요:
🎵 노래를 재생하고, 끝날 때까지 기다린 다음, 다른 노래를 원하는지 물어봐 줘
🍕 피자를 주문하고, 30분 후에 도착했는지 확인해 줘
🏔️ 일주일 동안 하루에 한 번씩 리조트 가격을 모니터링하다가 가격이 떨어지면 알려줘

LLM은 할 수 없습니다. 지능이 부족해서가 아니라, 구조적인 제약 때문입니다. LLM은 중앙 집중식 오케스트레이터(centralized orchestrator)이며, 그 대리인으로서의 주체성(agency)은 각 대화 턴(conversation turn)이 끝날 때 소멸합니다.

중앙 집중식 오케스트레이터 모델 (The Centralized Orchestrator Model)

모든 LLM 도구 통합은 다음과 같은 형태를 띱니다:
사용자 프롬프트(User prompt) → [LLM] → 도구 호출(tool call) → 결과(result) → [LLM] → 응답(response) → 유휴(idle)

도구는 수동적입니다. 모델만이 유일한 능동적 에이전트(active agent)입니다. 응답이 전송되면 루프는 닫힙니다. 당신을 대신해 세상을 관찰하는 지속적인 휴리스틱(persistent heuristic)은 존재하지 않습니다. 이는 단순 조회 작업에는 괜찮습니다. 하지만 대기, 스케줄링, 또는 자율적인 후속 조치가 필요한 모든 작업에서는 완전히 무너집니다.

Skillpunk: 지능을 분산시키다 (Skillpunk: Distribute the Intelligence)

LivinGrimoire는 정반대의 접근 방식을 취합니다. 수동적인 도구들을 관리하는 하나의 중앙 두뇌 대신, 각 기술(skill)이 자체적인 트리거 로직(trigger logic), 자체적인 상태(state), 그리고 내장된 자체적인 다단계 행동(multi-step behavior)을 가진 독립적인 자율 단위(autonomous unit)가 됩니다. 기술은 오케스트레이터에 의해 호출되는 것이 아닙니다. 기술은 매 사이클마다 실행되며, 언제 행동할지를 스스로 결정합니다.

class ResortWatcherSkill( Skill ):
    def input ( self , ear , skin , eye ):
        if self . days_checked < 7 and self . is_new_day ():
            price = fetch_resort_price ()
            self . days_checked += 1
            if price < 80 :
                self . setVerbatimAlg ( 2 , f " Resort dropped to € { price } . Book it? " )

재질문(re-prompting)은 필요 없습니다.

외부 스케줄러도, 오케스트레이션 접착제(orchestration glue)도 없습니다. 기술(skill)은 스스로의 상태를 추적하고, 자체적인 일정에 따라 실행되며, 조건이 충족되면 사용자에게 알림을 보냅니다. 7일이 지나면 중단됩니다. 휴리스틱(heuristic) 동작은 기술의 소유입니다. 위에서 이를 관리하려고 시도하는 모델의 소유가 아닙니다.

아키텍처 분리	LLM + 도구 (Tools)	LivinGrimoire 기술 (Skills)
동작 소유권	중앙 모델	각 기술 (Each skill)
대기 및 후속 조치	✗	✓
백그라운드 / 예약된 작업	외부 스캐폴딩(scaffolding) 필요	지속적인 기술 유형 (Continuous skill type)
시간에 따른 상태 유지	컨텍스트 윈도우 (Context window)만 가능	기술 내부 유지 (Skill-internal)
새로운 동작 추가	새로운 도구 + 프롬프트 튜닝 (prompt tuning)	하나의 독립된 기술 작성

LLM은 강력한 추론 엔진(reasoning engines)입니다. 하지만 무엇을 할지 추론하는 것과, 시간이 지남에 따라 이를 자율적으로 수행하는 것은 서로 다른 두 가지 문제이며, 오늘날의 LLM 아키텍처는 오직 첫 번째 문제만을 해결합니다.

기술(Skills)이 곧 뇌(Brain)입니다

Skillpunk 아키텍처에는 마스터 컨트롤러가 없습니다. 엔진은 그저 루프(loop)를 실행할 뿐입니다. 각 기술은 주권적(sovereign)입니다. 자신의 트리거(trigger), 타이밍, 후속 조치를 스스로 소유합니다. 기술을 투입하면 그 동작이 실행됩니다. 기술을 빼내면 중단됩니다. 프롬프트를 다시 작성할 필요도, 오케스트레이션(orchestration)을 업데이트할 필요도 없습니다. 그리고 기술을 추가하는 방법은요? 말 그대로 폴더에 Python 파일을 넣기만 하면 됩니다.

# DLC_personality.py — /DLC 폴더에 넣으면 자동으로 로드됩니다
def add_DLC_skills ( brain : Brain ):
    brain . add_skill ( DaRainAlerts ( " pripyat " )) # 비를 모니터링하고 알림을 보냄
    brain . add_skill ( DiAttentionSeeker ()) # 자율적이고 선제적임
    brain . add_skill ( DiAlarmer (). set_default_alarm ( " siren " ))
    brain . add_skill ( DiMicroReminder ()) # ... 원하는 만큼 추가 가능

메인 루프는 DLC_로 시작하는 모든 파일을 찾아 add_DLC_skills를 호출합니다. 이것이 통합 계약(integration contract)의 전부입니다. 설정 파일도, 레지스트리(registry)도, 배선(wiring)도 필요 없습니다. 기술을 작성하고, 파일을 넣으면, 실행됩니다.

이를 LLM 시스템에 새로운 동작을 추가하는 과정과 비교해 보십시오. 새로운 도구 정의, 업데이트된 시스템 프롬프트(system prompt), 모델이 실제로 이를 올바르게 호출하는지 테스트, 그리고 호출하지 못하는 예외 상황(edge cases) 처리까지. 매번 이 과정을 반복해야 합니다.

그것이 바로 Skillpunk의 정신입니다: 지능을 분산시키고, 병목 현상 (bottleneck)을 제거하십시오. Repo: LivinGrimoire on GitHub