research
Neuromorphic Computing — 개요 및 기초 로드맵
한 줄 정의: 뇌의 spike 기반 동작 원리를 하드웨어와 알고리즘으로 그대로 구현하는 분야 에너지 효율 연결: 뇌는 20W로 동작 — 이벤트 기반 연산이 핵심 이유 현재 상태: 장기 잠재력 최상, 성숙도…
ZeroClaw — 학습 지도
목적: 일정 관리 프로그램 구축 + 장기 Rust 전환의 레퍼런스. 방향: 전체 그림 → 레이어 순서대로 하나씩. 상태: Layer 1~4 전체 완료 (2026-03-22) --- --- …
Architectural Constraints — 구조적 강제
Skill이 "이렇게 해야 한다"고 말해주는 것이라면, Architectural Constraints는 "이렇게 하지 않으면 빌드가 깨진다"는 것이다. 권고가 아니라 강제. …
Context Engineering
"agent 입장에서 context window에 없는 건 존재하지 않는 것과 같다" AC test, ADR, Skill이 있어도 agent가 읽지 않으면 없는 것과 같다. Context…
맥락/히스토리 기록 방법론
Mermaid는 인간이 큰 흐름을 파악하기엔 좋지만, LLM이 "왜 이 결정을 했지?"를 추론하는 데는 텍스트가 더 효율적이다. 용도가 다르다: | 형식 | 답하는 질문 | 적합한 내용 | …
Garbage Collection Agents — 시스템이 스스로를 유지하는 방법
AC test가 새로운 위반을 막는다면, GC agent는 이미 쌓인 문제를 주기적으로 찾아낸다. 코드와 문서, 코드와 설계 의도가 서서히 벌어지는 현상. AC test는 새 commit을…
Harness 레이어 구조
| 레이어 | 파일 | 질문 | 누가 쓰나 | 언제 | |---|---|---|---|---| | Goal | feature_list.json | 무엇을? | initializer agent | 프로젝트 시작…
Harness Engineering — 전문가 로드맵
최신 연구(OpenAI, Stripe, LangChain, HumanLayer) 기반으로 구성. mugyeon v1 완주 기준으로 업데이트 (2026-03-21) --- ---…
Human as Bottleneck — 병목의 성격을 바꾼다
"내가 설계하고 agent가 구현"하는 모델에서, 규모가 커지면 설계 자체가 병목이 된다. Harness Engineering이 이걸 어떻게 다루는가? | 종류 | 정의 | 현재 상태 | …
업계 Harness Engineering 트렌드 — 2026
Stripe Minions, Ramp Inspect, Coinbase Cloudbot이 독립적으로 만들었으나 같은 구조로 수렴. LangChain이 이를 Open SWE로 오픈소스화 (2026.03.17). …
Anthropic Initializer + Coding Agent 패턴
출처: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents (2025.11) 1. One-shot 시도:…
Multi-Agent 구조 — 언제, 왜, 어떻게
지금 일반적인 Claude Code 사용 방식: 두 가지 벽: 컨텍스트 한계: 작업이 길어지면 앞 결정을 잊거나 일관성이 깨진다 직렬 처리: 한 번에 한 가지 일만. A가 끝나야 B를 시작한다 …
프로젝트 Bootstrap — Blank Repo에서 시작하는 방법
상태를 chat memory가 아니라 파일과 git history에 저장한다. harness 최적화보다 shipping 우선. agent가 실패할 때만 harness를 개선한다. 기존…
2023 03 11 (해야 할 프로젝트)
Taa 프로젝트의 도구와 나를 위한 시스템 개발 1. Taa (Tool calls 기능 체험) 2. MugYeon(marker + server + client) v1.0.0 제작 중 …
AI가 내 프로세스들을 어떻게 관리 할 것인가
현재 문제점은 VRAM에 제약이 있어서 각 작업마다 모델을 스위치를 해야 한다. 위 문제만 봤을 때는 AI 모델을 바꾸면 되는 게 아닌가라고 생각이 가능한데, 가장 큰 문제점은, 각 작업마다, SQLite…
Description Dropout으로 local model fine-tuning
현재 연구들은 광범위한 foundation model을 만드는 데 집중하지만, 특정 domain에서만 작동하는 작은 모델을 만들 때는 다른 접근이 유효하다. 도구(tool)를 명시적으로 정의한 뒤,…
Tool Calls + RPC + Platform 전략
MCP 방식보다 CLI 형태로 확장하는 platform이 새롭게 등장 중 (pi 등). 채팅 인터페이스는 앞으로 모든 플랫폼의 필수 요소가 될 것이다. OpenAI function calling /…
개인용 LLM 시스템 상업화 전략
개인용 LLM 인프라 (local model + RAG + RPC 서버 + 지식 관리) 를 시스템화해서 판매하는 방향. 앞으로 개인용 LLM 수요는 두 가지로 나뉜다: 일반 소비자 → Claude, ChatGPT…
Elaboration Iteration에서 만드는 다이어그램과 그 흐름
Larman의 Applying UML and Patterns가 답하려는 질문은 하나다: 요구사항에서 코드까지, 객체지향으로 어떻게 체계적으로 도달하는가? 그 답은 Unified Process의…
Use Case 작성법 (Ch 6)
유스케이스는 "시스템이 사용자에게 어떤 가치를 제공하는가"를 시나리오로 기술한 것이다. 기능 목록(feature list)이 아니라 목표 지향적 스토리다. 기능 목록은 수십~수백 페이지의 분절된 항목이…
Fully Dressed Use Case 작성 가이드
의 Fully Dressed 형식을 실제로 작성할 때 참고하는 가이드. --- --- 이 Use Case를 시작하는 사람. "시스템아, 이거 해줘"라고 요청하는 주체. …
System Sequence Diagram (Ch 9)
SSD는 시스템을 블랙박스로 놓고, 외부 액터가 시스템에 보내는 이벤트를 시간순으로 나열한 다이어그램이다. 만드는 데 30분이면 충분하다. 유스케이스가 텍스트로 기술한 상호작용을, SSD는 시각적으로…
Domain Model (Ch 10-12)
도메인 모델은 문제 도메인의 현실 세계 개념을 시각화한 것이다. 소프트웨어 클래스가 아니다. 메서드가 없다. "이 세계에 어떤 것들이 존재하고, 서로 어떻게 연결되어 있는가"를 보여준다. 객체지향…
Domain Model 작성 가이드
의 내용을 실제로 작성할 때 참고하는 가이드. --- --- Use Case 텍스트를 읽으면서 명사와 명사구를 전부 뽑는다. 판단하지 말고 일단 다 모은다. 예를 들어 수강 추천 UC에서: "학생이 수강 과목…
Operation Contract (Ch 13)
Operation Contract는 에서 도출된 시스템 이벤트 각각에 대해, 실행 후 도메인 객체들의 상태가 어떻게 변했는지를 명세한 것이다. 유스케이스 텍스트만으로 충분하면 안 써도 된다. 하지만…
GRASP 패턴 (Ch 16, 22)
GRASP(General Responsibility Assignment Software Patterns)은 "이 책임을 어떤 객체에 줄 것인가"라는 질문에 답하는 9개의 원칙이다. 디자인 패턴이라기보다는 객체…
Interaction Diagram과 Use-Case Realization (Ch 15, 17)
Interaction Diagram은 소프트웨어 객체 간의 메시지 흐름을 그린 것이다. Larman이 이 책에서 "설계의 심장"이라고 부르는 산출물이 바로 이것이다. 도메인 모델이나 SSD보다 만들기 어렵고, 더…
Design Class Diagram (Ch 19)
DCD는 에서 발견된 소프트웨어 클래스, 메서드, 속성, 관계를 정적으로 정리한 다이어그램이다. 은 현실 세계 개념이고, DCD는 소프트웨어 클래스다. | | Domain Model | DCD |…
GoF 디자인 패턴 in Larman (Ch 23)
Iteration 2에서 외부 서비스 연동, 다양한 결제 방식, 복잡한 가격 정책 같은 문제가 등장한다. 이때 의 기본 원칙만으로는 설계를 표현하기 부족해지면서 GoF 패턴이 필요해진다. 하지만 GoF 패턴을…
바이브 코딩에서 LLM에게 설계 방향 전달하기
Larman의 OOA/D 프로세스에서 만드는 산출물은 LLM에게 설계 의도를 전달하는 데 최적화된 형태다. 각 산출물이 프롬프트에서 어떤 역할을 하는지, 그리고 프로젝트의 어떤 시점에 어떤 걸 전달해야 하는지를…
Iteration을 돌 때 "뭘 깊게 파야 하는지" 모르겠을 때
초보자가 Elaboration iteration을 돌 때 부딪히는 진짜 문제는 이거다: "다음 iteration에서 뭘 더 해야 하는지 모르겠다." 경험 많은 개발자는 코드를 보고 "여기가 깨지겠다"를 직감하지만,…
Mermaid 다이어그램 치트시트 (OOA/D용)
Larman 프로세스에서 필요한 Mermaid 문법은 딱 두 가지다: 과 . 이 노트는 OOA/D 산출물을 그리는 데 필요한 문법만 모았다. --- SSD와 Interaction Diagram 둘…
Larman — Applying UML and Patterns
요구사항에서 코드까지 객체지향으로 도달하는 체계적 프로세스. Craig Larman의 Applying UML and Patterns 핵심을 정리한 폴더다. | # | 노트 | 핵심 | …
LWW와 CRDT — 충돌 해결 전략
두 기기가 같은 데이터를 오프라인에서 각각 수정했을 때 어떻게 합치느냐의 전략. 탐구에서 파생. 기기 A와 B가 같은 데이터를 가지고 있고, 둘 다 오프라인에서 수정한 뒤 sync하면 — 어느 버전이…
16GB VRAM 추론 모델 비교 (2026년 3월 기준)
Naran 프로젝트 핵심 추론 엔진 선택을 위한 HuggingFace 모델 비교. 중국 모델 포함, 양자화 포함. --- | 모델 | 출처 | HF ID | VRAM (Q4_K_M) | Tool…
Task, Sequence
Google Calendar Event Schema
API v3 기준. 출처: Google Calendar API v3 reference. --- --- 만 있으면 all-day (시간 없음) 이 있으면 timed (timeZone 필수)…
Google Tasks API — Task & TaskList 구조
API: Google Tasks API v1. Calendar API와 별개 API. 출처: Google Tasks API v1 reference 조사 기반. --- --- …
gpt-oss-20b — Naran 적용 리서치
Naran 프로젝트의 핵심 추론 엔진으로 검토한 모델. 2025년 8월 OpenAI가 공개한 오픈웨이트 reasoning 모델. --- | 항목 | 값 | |------|-----| | 총…
Naran 데이터 모델 (v4)
상태: 확정 (설계하자에서 검토 완료) zeroclaw 위에 얹는 도메인 레이어. zeroclaw DB는 건드리지 않음. --- --- --- Task…
Naran 핵심 엔진 모델 비교 — Unsloth 기준 (2026-03-25)
출처: https://unsloth.ai/docs 전체 모델 조사 --- | 모델 | 출처 | 16GB 적합성 | tool call | 비고 | …
Naran 미결 사항 (Big Picture)
세부 미결사항은 각 관련 md에 저장. 여기는 전체 아키텍처에 영향을 주는 큰 결정만 모은다. --- --- --- --- | 주제 | 파일 | |------|------| | DB 스키마 세부 미결 | | |…
Naran 설계 세션 인계 문서
작성: 2026-03-31 목적: 설계하자 세션 → 새 대화창 인계용 compact 맥락 --- Naran = zeroclaw 위에 도메인 레이어를 얹는 개인 생산성 시스템. zeroclaw가 실행을 담당하고,…
zeroclaw cron 내부 구조
소스: zeroclaw-labs/zeroclaw 직접 조사. 관련 파일: types.rs, store.rs, scheduler.rs --- zeroclaw는 경로에 SQLite를 열고 최초…
Harness for End Users — 일반인을 위한 Harness
개발자 Harness에서 인간이 하는 일 = 파일 직접 편집 일반인은 이게 불가능 → "파일 편집"을 UI로 추상화 자연어 입력 → LLM이 feature_list.json으로 변환…
Local LLM 요구사항 산정
| 구성 요소 | 추정 토큰 | |---|---| | 역할 정의 | ~200 | | Tool 명세 × 10개 | ~4,000 | | Skill 정의 × 5개 | ~1,500 | | 사용자 설정 | ~300…
Skill Composition Model
앞 Tool의 출력이 다음 Tool의 입력으로 연결. 서로 의존성 없는 Tool을 동시 실행. 결과에 따라 다음 행동이 달라짐. Tool 조합(구조)은 공유,…
Skill 선택 메커니즘 — LLM이 어떤 Skill을 써야 하는지 아는 방법
LLM이 description을 보고 요청과 매칭해서 선택. 가장 단순하고 현재 가장 많이 쓰는 방식. 캘린더 자동 트리거처럼 조건이 명확할 때 강력. confidence가…
Tool 분석 방법론 — 추상적 사고 과정
판단이 필요하면 LLM, 실행이 명확하면 Tool. 사람이 실제로 하는 행동을 동사로 나열한다. 각 동사가 Tool 후보. "이게 다른 상황에서도 쓰일 수 있나?" 를…
Tool 설계와 LLM CoT 실행 구조
"이 작업을 다른 Skill에서 다시 쓸 수 있는가?" Yes → Tool / No → Skill 내부 로직 각 Tool: 단일 입출력, 독립적으로 재사용 가능. …
Tool 구현 — 근본적인 구조
모든 Tool이 이 클래스를 상속해서 만 구현. 에러를 exception으로 터뜨리면 LLM이 뭘 해야 할지 모른다. 에러를 LLM이 읽을 수 있는 구조화된 응답으로 반환해야 한다. — Tool…
Tool Registry — 포괄적 Agent 구현 구조
사용 가능한 Tool들의 카탈로그. 새 Tool 추가 → 등록 → 자동 반영. Tool을 손으로 쓰지 않고 Registry에서 자동 생성: …
Tool 명세 작성법 — LLM이 잘 쓰는 System Prompt
Tool 명세는 "주니어 개발자에게 API 문서 쓰듯" 쓴다. LLM은 그 문서를 읽고 판단하는 주니어 개발자다. LLM이 가장 많이 실수하는 부분 — 이 tool을 써야 하는 상황 판단. …
Tool vs Skill 설계 원칙
Tool = agent가 실행할 수 있는 원자적 능력 Skill = tool들의 조합 + 실행 순서 + 조건 Tool은 개발자가 만들고, Skill은 사용자가 구성한다. 하나의…
이벤트 트리거 시스템
같은 이벤트에 트리거가 여러 번 발생하면 안 됨 → 실행 기록 저장 필요. 사용자별로 다른 것: 트리거 조건, 필터, 연결된 Skill — Skill 조합 구조 — LLM이 Skill…
User Customization UX
이 간극을 메우는 게 UX 설계의 전부. 내부적으로 YAML 생성, 사용자는 몰라도 됨. 장점: 진입 장벽 낮음 단점: 미리 만들어진 옵션 밖으로 못 나감 LLM이 자연어 파싱 →…
pi SDK — Extension API 상세
pi-mono의 Extension 시스템 완전 분석. 목적: 일정 관리 프로그램에서 Python으로 동일 패턴 구현 시 레퍼런스. --- Extensions는 lifecycle 이벤트를 구독하고,…
Local LLM VRAM 모델 스왑 방식
질문: llama.cpp/ollama로 LLM을 돌릴 때, 모델 전환 시 VRAM에 올린 채 swap하는가, 내리고 다시 올리는가? (API 호출 자체는 논외 — 인프라 레벨 질문) --- 둘 다…
pi-agent-core — Agent Loop 핵심 구조
max_steps 없음: 루프 횟수를 제한하는 knob이 없다. 모델이 tool call을 내지 않을 때까지 계속 돌린다. "왜 추가하지 않았냐"는 질문에 Mario의 답변: "쓸 일이 없었다." 이벤트…
LLM Agent 전체 파이프라인
llama.cpp 기반 로컬 LLM 에이전트의 전체 구조를 4개 레벨로 나눠서 시각화. --- --- 현재 가 구현하는 영역. 루프가 없으면 두 번째 tool_call부터 처리…
pi SDK — RPC 모드 상세
pi RPC 모드의 전체 프로토콜 분석. 목적: Python orchestrator에서 pi를 subprocess로 호출할 때 구현 레퍼런스. --- 다른 언어나 프로세스 격리가 필요한 환경에서…
ZeroClaw — Rust 기반 자율 AI 에이전트 프레임워크
pi SDK 없이 처음부터 Rust로 구현한 OpenClaw 대안. 분석 목적: 일정 관리 프로그램 + 장기 Rust 전환 시 레퍼런스. --- ZeroClaw는 100% Rust로 작성된…
PoEAA 읽기 가이드 — Larman 이후의 다음 단계
Craig Larman의 Applying UML and Patterns는 요구사항에서 설계 클래스 다이어그램(DCD)까지의 여정을 안내한다. Use Case → SSD → Domain Model →…
Layering — 실전 예시와 템플릿
이론: "CLI를 추가한다고 상상하라. 뭘 중복 구현해야 하는가?" | 기능 | 올바른 위치 | 잘못된 위치 | |------|-----------|-----------| | 추천 점수 계산 |…
The Three Principal Layers
엔터프라이즈 애플리케이션 아키텍처의 가장 기본적인 구조적 결정은 시스템을 어떤 계층으로 나눌 것인가다. Layering은 복잡한 시스템을 분리하는 가장 보편적인 기법이다. TCP/IP 네트워크 스택이…
Organizing Domain Logic — 실전 예시와 템플릿
이론: 같은 기능이 패턴에 따라 어떻게 달라지는지 비교한다. 장점: 읽기 쉽고, 흐름이 한눈에 보인다. 단점: "졸업요건 확인" 기능에도 비슷한 조회+필터링 로직이…
Organizing Domain Logic
시스템 설계에서 가장 중요한 첫 번째 결정: 도메인 로직을 어떻게 구조화할 것인가. 이 선택이 나머지 모든 아키텍처 결정의 출발점이 된다. 각 비즈니스 트랜잭션(사용자 액션)마다 하나의…
Mapping to Relational Databases — 실전 예시와 템플릿
이론: Step 1: DCD (Larman에서 온 것) Step 2: 매핑 결정 테이블 | DCD 클래스 | DB 테이블 | 매핑 방식 | 비고 | …
Mapping to Relational Databases
DCD까지 만들었는데 "이걸 DB에 어떻게 저장하지?"라는 질문이 남았다면, 이 챕터가 그 답이다. 데이터 소스 계층의 아키텍처 패턴, 행동 패턴, 구조적 매핑 패턴을 전체적으로 조감한다. 도메인…
Domain Logic Patterns — 실전 예시와 템플릿
이론: Fowler가 책 전체에서 반복 사용하는 예제. "소프트웨어 제품을 팔면, 매출 인식을 언제 어떻게 하는가?" Word Processor: 계약 체결일에 전액 인식 Spreadsheet:…
Domain Logic Patterns
에서 큰 그림을 봤다면, 여기서는 각 패턴의 구체적인 동작 방식과 코드 수준의 차이를 다룬다. 각 비즈니스 트랜잭션을 하나의 프로시저로 구성한다. 호텔 예약이면 , 장바구니 추가면 . 각 프로시저가 입력 받기…
Data Source Patterns — 실전 예시와 템플릿
이론: 같은 Student를 각 데이터 소스 패턴으로 구현하면 어떤 차이가 생기는지 비교한다. …
Data Source Architectural Patterns
도메인 로직을 어떻게 구조화할지 결정했으면, 다음 질문은 "그 객체들을 DB에 어떻게 연결할 것인가"다. 이 선택은 의 선택에 종속된다. DB 테이블에 대한 Gateway. 인스턴스 하나가 테이블 전체를 담당한다.…
O-R Behavioral Patterns — 실전 예시와 템플릿
이론: 한 요청 안에서 Student 로드 → Enrollment 추가 → 추천 계산 → 저장이 일어난다. 사용 예시: 왜 필요한가 — 없으면…
Object-Relational Behavioral Patterns
구조적 매핑(테이블↔클래스, 컬럼↔필드)보다 더 어려운 것이 행동 문제다. 객체를 읽고 수정하는 과정에서 발생하는 동시성, 중복, 성능 문제를 다루는 세 가지 핵심 패턴. 비즈니스 트랜잭션 동안 DB에 영향을 줄…
Putting It All Together — 실전 예시와 템플릿
이론: 1단계: 도메인 복잡도 평가 | 기능 | 복잡도 | 근거 | | ---------- | ----- |…
Putting It All Together
지금까지의 패턴들을 실제 프로젝트에서 어떻게 조합할 것인가. Fowler가 준 의사결정 트리를 정리한다. 모든 것은 도메인 계층 선택에서 시작한다. 이 결정이 데이터 소스, 프레젠테이션까지 연쇄적으로…
Web Presentation Patterns — 실전 예시와 템플릿
이론: 각 Controller가 특정 URL 그룹을 담당하고, 해당 도메인 객체와 대화한다: Page Controller로 시작했는데 이런 상황이…
Web Presentation Patterns
웹 프레젠테이션의 핵심은 Model View Controller(MVC)와 그 변형들이다. MVC는 아마 소프트웨어에서 가장 많이 언급되면서도 가장 많이 오해받는 패턴이다. Fowler는 웹 맥락에서…
Distribution & Base Patterns — 실전 예시와 템플릿
이론: Academic Life System에서 외부 LLM API와의 통신이 가장 분산 패턴에 가까운 부분이다. 만약 프론트엔드가 SPA(React 등)라서…
Distribution & Base Patterns
PoEAA의 나머지 중요 패턴들을 간결하게 정리한다. 프로젝트에서 당장 쓰지 않더라도, 개념을 알아두면 아키텍처 논의에서 도움이 된다. "Don't distribute your objects." (객체를 분산하지…
DCD에서 DB까지 — 실전 예시와 템플릿
이론: | DCD 클래스 | DB 테이블 | 1:1? | 매핑 패턴 | 비고 | |-----------|----------|------|----------|------| |…
DCD에서 DB까지 — 빠진 연결고리
Larman은 요구사항에서 DCD까지, Fowler는 패턴 이름과 선택 기준을 준다. 하지만 DCD 클래스를 실제로 DB에 어떻게 연결하고, 이걸 어떤 다이어그램으로 표현하는지는 어디에도 명시적으로 정리되어 있지…
Concurrency & Transactions — 실전 예시와 템플릿
이론: 수강 인원이 30명 제한인 과목에 29명이 등록된 상태. 두 학생이 동시에 신청한다. 해법 — Pessimistic Lock (SELECT FOR UPDATE): …
Concurrency & Transactions
엔터프라이즈 애플리케이션에서 동시성 문제를 다루는 핵심 개념과 패턴. Lost Update: Martin이 파일을 편집하는 동안 David도 같은 파일을 편집. David이 먼저 저장하고 Martin이…
Larman + Fowler 통합 학습 전략
Larman은 바로 실행 가능하고, Fowler는 전체를 알아야 한다는 느낌이 들 수 있다. 하지만 Fowler도 처음부터 다 알 필요 없다. 첫 두 결정만 해도 시작할 수 있다. 핵심: Fowler의…
Larman vs Fowler — 두 방법론의 관계
둘 다 프로세스 방법론이 아니다. 관점의 초점이 다를 뿐이다. Larman — 객체 책임 할당 방법론 : "이 유스케이스를 실현하려면 어떤 객체가 어떤 메시지를 주고받아야 하는가?" Fowler —…
DI의 트레이드오프 — mock 교체와 보일러플레이트
에서 DI의 단점으로 언급된 두 가지를 상세히 풀어본다. --- 테스트할 때 실제 DB 대신 가짜(mock)를 쓰고 싶은 상황을 생각해보자. 모듈 레벨 변수 방식: …
런타임에 한 번만 생성할 것을 굳이 클래스로 만들어야 할까?
"프로그램 runtime 중에 한 번만 생성할 클래스를 굳이 클래스로 만들 필요가 있을까? 만약 클래스로 관리해야 한다면 효과적인 방법은 무엇인가?" 클래스는 원래 세 가지를 묶어준다: 1. 상태…
Singleton 패턴의 3가지 단점
에서 나온 단점들을 상세히 풀어본다. 세 단점의 공통 뿌리는 하나다: "하나만 만들겠다"는 결정을 클래스 안에 숨긴 것. --- 이 코드만 보면 가 DB를 쓴다는 게 안 보인다. 함수…
SQLite In-Memory DB (`:memory:`)
SQLite의 는 파일 대신 RAM에만 존재하는 DB다. 동작 방식은 일반 SQLite랑 완전히 동일하다. 테이블 만들고, INSERT하고, SELECT하고 — 전부 똑같이 작동한다. 차이는 딱 하나,…
Tool Call 판단 주체 — 모델이 결정한다
llama.cpp 서버에서 채팅 요청이 들어왔을 때, "이게 tool을 쓰는 요청인가?"를 판단하는 건 서버 로직이 아니라 모델 자체다. 모델의 tokenizer config에는…
Tool Call 루프가 필요한 이유
모델이 tool을 더 쓰고 싶어도, 클라이언트가 루프를 돌려주지 않으면 두 번째 tool_call부터는 그냥 무시된다. 현재 1회성 코드의 흐름: 모델이 첫 번째 결과를 보고 "이걸론…
웹사이트 종류 분석 방법
크롤링을 시작하기 전에 반드시 해야 할 일: 타겟 사이트가 어떤 방식으로 동작하는지 분석하기. 이 단계를 건너뛰면 삽질한다. 모든 분석은 브라우저 개발자도구(DevTools)에서 이뤄진다. …
크롤링 관점에서 본 웹사이트 종류
웹사이트를 크롤링하려면, 그 사이트가 어떤 방식으로 콘텐츠를 제공하는지 알아야 한다. 같은 데이터라도 제공 방식에 따라 크롤링 전략이 완전히 달라진다. 웹사이트가 HTML을 "언제, 어디서" 만드는지에…
ZeroClaw — Agent Loop
Layer 2 학습. 실제 소스 코드 기반. 파일: , --- 이 agent loop의 핵심 진입점이야. 한 번의 사용자 입력을 처리하는 전체 흐름: --- …
ZeroClaw — 자동 컴팩션
Layer 2 학습. 실제 소스 코드 기반. 파일: , , --- 컴팩션이 두 개의 독립적인 레이어에서 동작해. --- 안에서 tool call 결과를 history에…
ZeroClaw — Channel 시스템
Layer 3 학습. 실제 소스 코드 기반. 파일: , , --- --- 필수 구현은 세 개뿐: , , 나머지는 플랫폼이 지원하면 override, 아니면…
ZeroClaw — Config 스키마
Layer 1 학습. 실제 config.toml 구조 기반. 파일: (501KB), --- Config 시스템은 4단계 우선순위 모델을 구현한다. config.toml 한 파일이…
ZeroClaw — Cron → Agent 실행 흐름
Cron이 Agent Job을 어떻게 트리거하고, Agent 내부에서 어떻게 작업이 처리되는지 전체 시퀀스. --- --- Cron은 트리거/기록 전담, Agent는 추론/실행…
ZeroClaw — Cron 스케줄러
Layer 3 학습. 실제 소스 코드 기반. 파일: , , , --- Cron = 시간 기반으로 Shell 명령이나 LLM 에이전트 작업을 자동 실행하는 스케줄러. 일반 cron과 다른 점…
ZeroClaw — Daemon 스케줄링 구조
Daemon이 관리하는 컴포넌트 전체와 각각이 어떻게 작업을 트리거하는지. 소스: --- --- | 컴포넌트 | 트리거 | 실행 조건 | Agent 위임 | …
ZeroClaw — Daemon
Layer 3 학습. 실제 소스 코드 기반. 파일: --- Daemon = 여러 컴포넌트를 하나의 프로세스 안에서 동시에 실행하고 감시하는 슈퍼바이저. --- …
ZeroClaw — Gateway 시스템
Layer 3 학습. 실제 소스 코드 기반. 파일: , , , --- Gateway = ZeroClaw를 HTTP로 노출하는 Axum 웹 서버. Channel 시스템(Telegram,…
ZeroClaw — Hands (Multi-Agent)
Layer 3 학습. 실제 소스 코드 기반. 파일: , , --- ZeroClaw의 multi-agent 시스템은 세 레이어로 구성돼: --- Hand는…
ZeroClaw — Lifecycle Hooks
Layer 3 학습. 실제 소스 코드 기반. 파일: , , --- Hooks = 에이전트 파이프라인의 특정 지점에서 코드를 끼워 넣는 확장 포인트. 메시지 수신 → LLM 호출 → 도구…
ZeroClaw — Memory 시스템
Layer 2 학습. 실제 소스 코드 기반. 파일: , , --- --- --- --- 내 프로젝트에서: --- …
ZeroClaw — Message 흐름 상세
Channel 시스템 내부. 실제 소스 코드 기반. 파일: — --- --- shell …
ZeroClaw — System Prompt 구성
Layer 2 학습. 실제 소스 코드 기반. 파일: --- System prompt는 가 여러 을 순서대로 조립해서 만든다. 첫 호출 시 딱 한 번 생성되고, history 맨 앞에 push된다. --- 커스텀…
ZeroClaw — Provider 구현체
Layer 1 학습. 실제 소스 코드 기반. 파일: , --- Provider trait 위에 두 개의 핵심 구현체가 있다. agent loop는 항상 를 통해 LLM을 호출한다. …
ZeroClaw — Sandboxing 시스템
Layer 3 학습. 실제 소스 코드 기반. 파일: , , , , , --- Sandboxing = shell 명령 실행 시 OS 레벨에서 프로세스를 격리하는 것. …
ZeroClaw — Security Policy
Layer 3 학습. 실제 소스 코드 기반. 파일: , --- --- 실제 동작 차이: | | ReadOnly | Supervised | Full | …
ZeroClaw — SOP 엔진
Layer 3 학습. 실제 소스 코드 기반. 파일: , , , --- SOP(Standard Operating Procedure) 엔진 = 이벤트가 도착하면 정의된 절차(단계 목록)를 자동으로…
ZeroClaw — SQLite + 벡터 검색 내부
실제 소스 코드 기반. 파일: , --- 핵심: 이 테이블 안에 BLOB으로 저장돼. 외부 벡터 DB 없이 SQLite 하나로 전부 처리. --- --- f32 벡터 ↔ BLOB 변환이 단순해: --- 전용…
ZeroClaw — Tool Dispatcher
Layer 2 학습. 실제 소스 코드 기반. 파일: --- LLM마다 tool call 방식이 달라. ToolDispatcher trait이 이 차이를 추상화한다. agent…
ZeroClaw — Tool 시스템
Layer 2 학습. 실제 소스 코드 기반. 파일: , , --- --- --- 이것만 구현하면 ZeroClaw agent가 자동으로 LLM에 노출하고 호출한다. --- config에 따라 활성화된 tool들을…
ZeroClaw — Trait 시스템
Layer 1 학습. 실제 소스 코드 기반. 파일: , --- ZeroClaw의 핵심 설계 원칙은 하나야. "컴포넌트 교체는 설정 파일만 바꾸면 된다. 코드는 건드리지 않는다." 이걸 가능하게 하는 게 Rust…