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 — 충돌 해결 전략
두 기기가 같은 데이터를 오프라인에서 각각 수정했을 때 어떻게 합치느냐의 전략. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~…
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…
Action Prediction과 Trust — Harness 단에서 예측 가능성 박기
agent의 치명적 단점은 어떤 action을 할지 예측 불가능하다는 것. 이게 비개발자 segment에 결정적 — 코딩은 돌이킬 수 있지만 컴퓨터 조작은 비가역 action 가득. 예측 가능성은 LLM의…
Disorder Tolerance — 일반 사용자 messy input의 input 측 translation
이 output 측 translation을 박았다. 이 노트는 input 측 — 사용자의 messy input을 어떻게 받아들이는가. agent가 비개발자 segment를 채택하려면 완벽한 input을 기대할 수…
Easy → Simple Translation — Harness의 진짜 정의
Harness의 정의는 complex한 LLM 자유를 simple한 예측 가능 행동으로 번역하는 layer다. 이게 harness의 존재 이유. 다른 모든 harness 기능 (prediction · ACL ·…
진화의 흐름 — function calling에서 MCP까지. Layer 분리의 점진성
2023-06 OpenAI function calling에서 2024-11 MCP까지 18개월. 각 단계는 이전 단계의 결정이 만든 문제에 대한 응답이다. ① fundamentals 4축으로 보면 — 각 단계가…
진화의 흐름 — MCP에서 Skills까지. Layer 위의 layer
2024-11에 MCP가 자리잡은 직후 새로운 압력 4개가 동시에 등장했다 — token 부담, skill management 부재, 비개발자 진입성, client/agent 분리 부재. 이 압력이 layer 위의…
Frontier — ACP와 Agent-as-MCP-Server. Agent 경계의 분해
ACP와 agent-as-MCP-server는 다른 frontier지만 같은 thesis를 가진다 — agent의 경계가 흐려지고 있다. agent가 client인지 server인지, tool인지…
Frontier — Computer Use와 Browser Agent. 일반 agent의 실험실
에서 본 L6 (Computer Use / Browser Use)는 30% maturity. 코딩 IDE harness와 완전히 다른 영역. Computer Use / Browser Use는 일반 agent…
Frontier — RL 기반 Skill 자동 생성. Skill 생성의 layer
Skill을 사람이 작성하는 것에서 자동 생성으로 진화하는 frontier. AutoSkill, WebRL, SkillRL — 학술 진행 빠르나 production maturity 낮음. agent…
Frontier — Tool Gateway와 Description 압축. Cross-cutting concern의 자리
Token 부담이 예상치 못한 lever가 됐다. MCP는 transport만 다룬다 — tool 묶음, 압축, 보안, observability 같은 cross-cutting concern은 어느 layer에서…
Harness = Complex → Simple 변환 — 메타 인사이트
"harness는 complex를 어떻게 simple로 변환할 거냐" — 사용자의 종합 명제. 모든 조사 자료(이 프로젝트 14 노트 + stateless-llm-sdk 14 노트)를 한 명제로 압축하면 이 한…
도달도 Frontier 분석 — 15 layer로 본 v1.0의 gap-filling 자리
다른 노트들이 thesis를 박는 반면, 이 노트는 현재 ecosystem이 어디까지 도달했는가를 측정한다. 현재 ecosystem이 어디까지 도달했는가를 명시하는 게 v1.0의 gap-filling 자리를 박는…
Ouroboros 집중 탐구 — Meta-Layer Agent OS 카테고리 깊이
의 1차 분석 위에서 meta-layer 카테고리의 깊이로 진입. Ouroboros가 카테고리의 가장 완성된 사례인 mechanism을 분석하고, Anthropic·OpenAI·Stanford의 동시 다발적 같은…
Postel's Law — 보낼 때 엄격, 받을 때 관대. Protocol 수명의 원리
"Be conservative in what you do, be liberal in what you accept from others." — Jon Postel, RFC 793 (1981). 1년의…
Protocol 이론 — Lamport · Tanenbaum이 알려주는 layer 분리의 원리
Protocol은 합의된 약속이지 구현이 아니다. Layer 분리가 ecosystem의 진화를 가능하게 한다. 왜 tool ≠ protocol이 layer 분리의 직접적 적용인지, 그리고 layer 누설이라는…
비개발자 다수 Segment의 추상 구조 — 왜 protocol을 요구하는가
이전 ①②③④ 분석은 모두 비개발자 다수 segment에 적용된다. 그러나 왜 이 segment가 결정적인가에 답을 박지 않았다. 이 노트가 그 답. 비개발자 다수 segment는 protocol을 요구한다 —…
표준화의 정치경제학 — de facto vs de jure, Cathedral vs Bazaar
표준은 합의가 아니라 권력이다. 누가 표준을 만드느냐가 ecosystem의 모양을 정한다. de jure와 de facto는 다른 mechanism이고, 다른 운명을 가진다. MCP가 de facto 패턴이고,…
종합 (일반 agent 관점) — Q1~Q12 결정 path. 미개척이 v1.0 자산
이 연구의 마지막 노트. 가 코딩 ecosystem 관점이었다면, 이 노트는 일반 agent 관점에서 18 노트 모두 호출. 사용자의 진짜 thesis는 prediction layer + bidirectional…
종합 — v1.0 결정의 근거 정리. 결정 path Q1~Q7
이 연구의 마지막 노트. 이전 11개 노트의 모든 분석을 v1.0 결정으로 변환. 연구는 결정을 대신하지 않는다. 결정의 근거가 fundamentals에 닿게 만든다. 이게 strategic decision의 본질…
5 옵션의 깊은 trade-off — 모든 lens가 모이는 자리
에서 잡은 5 옵션 (Hybrid · MCP 단일화 · Tool only · Tool as API · MCP+Skills lazy)을 9 차원으로 깊이 분석. ①②③의 모든 lens가 모이는 자리. 5 옵션은 동일…
Worse is Better — 단순한 표준이 완벽한 표준을 이기는 mechanism
1989년 Richard Gabriel의 thesis. 완벽한 design이 단순한 design에 패배하는 이유. SOAP/CORBA가 사라지고 REST/JSON이 살아남은 이유. MCP가 6개월 만에…
ADR as Strategic Mechanism — 학생의 진짜 자산
AI가 코드·design·결정을 다 도와주는 시대에 "내가 무엇을 아는가?"의 답. ADR (Architecture Decision Record)이 strategic 사고를 글로 남기는 가장 명확한…
Anti-Corruption Layer — 외부 변화로부터 내 도메인을 지키는 격리벽
Eric Evans Context Map 7가지 패턴 중 가장 강력한 boundary mechanism. 외부 시스템과 내 시스템 사이에 변환 layer를 두어, 외부의 변화·오염이 내 도메인 모델에 영향을 미치지…
Bounded Context — UL의 통치 범위 + AI session의 자연 경계
Eric Evans DDD의 또 하나 핵심 명제. Ubiquitous Language가 어디까지 통하는가의 답. 모델의 경계를 명시적으로 그어 vocabulary 충돌과 모델 일관성 붕괴를 차단. 의 🌐…
Deep Modules — AI 시대에 가장 직접적으로 부활하는 원칙
Ousterhout — A Philosophy of Software Design의 가장 핵심 원칙. Matt 강연이 AI agent의 shallow 양극화 약점을 deep module로 보완한다고 호출한 자리. 의…
Information Hiding — 14 원칙 산소의 마지막 한 조각
Parnas 1972 논문 On the Criteria to Be Used in Decomposing Systems into Modules. 54년 후에도 모든 SE 원칙의 root.…
Information Leak vs Abstraction — Module 축의 자기 점검 도구
이 목표라면, leak은 그 목표가 깨지는 순간. Joel Spolsky의 Law of Leaky Abstractions (2002) + Ousterhout의 information leakage가 핵심…
Interface as Strategic Surface — 14 원칙 통합 운영 답
사용자가 14 원칙을 다 흡수한 후 도달한 통찰: simplex 구조를 strategic하게 설계 = interface 정의 + reversible 방향 — 정확하고 14 원칙의 통합 운영 답. (theory) ·…
Named Ownership — AI 시대 책임의 단위
12% production cohort의 또 한 가지 공통 패턴. 모든 agent·skill·tool에 책임자(owner)와 성공 기준(success criteria)이 명시적으로 박힌다. 익명 swarm은…
Orthogonality — 변경의 전파 차단, AI agent에게 reasoning 공간 주기
Hunt & Thomas The Pragmatic Programmer (1999) 핵심 원칙. 서로 무관한 변경이 서로 무관해야 한다. 한 곳 수정이 다른 곳에 cascading 안 되게 design. 의 🔄…
Reading Guide — 우리 노트 + 원 소스 reading order
의 14 원칙을 어떤 순서로 읽을지 + 어떤 원 소스 (책·강연·글)와 함께 읽을지. 무료 자료 우선, 책은 심화 시점에. 자세한 책 구매 가이드는 . --- | 시간 예산 | 추천 path |…
Reversibility — There Are No Final Decisions
Hunt & Thomas The Pragmatic Programmer (1999) Tip 14. 모든 결정은 가설. 미래는 예측 불가능하고, 그 가설이 틀릴 때를 위해 되돌릴 수 있는 형태로 design한다. 의…
Ship-and-Rollback as Normal — 12% production cohort의 분수령
88% AI pilot이 production 못 가는 이유 중 큰 것이 rollback을 실패로 해석하는 조직 문화. 12% 성공 cohort의 공통: ship과 rollback을 둘 다 normal…
Simple ≠ Easy — 14 원칙의 산소
Rich Hickey의 2011 강연 Simple Made Easy에서 출발. 14 원칙 모두가 complex를 simple로 바꾸는 도구인데, 그 simple이 무엇인가가 정의되지 않으면 모든 원칙이 표류한다.…
Strategic vs Tactical Programming — Matt thesis의 직접 root
Ousterhout 책 3장의 핵심 명제. 매 코드 작업이 task 완료가 목표인가, 시스템 design 개선이 목표인가. Matt thesis가 이 명제를 사람-AI 분할로 확장한 자리. 의 철학적 root 3개…
학생 적용 가이드 — 14 원칙을 어디서·언제 적용하는가
도메인 모르는 학생이 14 원칙을 다 배운 후 마비되는 함정의 답. · 다음에 오는 적용 단계 가이드. 의 통합 명제를 학생 단위로 운영하는 timeline. --- 도메인 모름이 정상이고, 14 원칙은 처음부터…
14 원칙의 통합 명제 — Complex를 Simple로 관리
14 원칙을 한 줄로 압축하면 complex(얽힘)를 simple로 관리하는 strategic 도구의 모음. AI 시대에 더 강해진 이유는 AI가 complex를 더 빠르게 누적시키기 때문. 의 대화 후 발견된…
TDD as Small Deliberate Steps — AI 시대 garbage 누적의 차단막
Kent Beck Test-Driven Development By Example (2002) + Matt 강연의 "rate of feedback is your speed limit". 한 step에 한 행동, 매…
Tracer Bullets — 작은 end-to-end로 architecture 조준
Hunt & Thomas The Pragmatic Programmer (1999) Tip 20. 군사 예광탄에서 어원 — 발사하면 궤적이 보임 → 조준 보정 가능. 작은 end-to-end로 먼저 통과시키고 점진…
Ubiquitous Language — 한국어 도메인의 숨은 자산
Eric Evans Domain-Driven Design (2003)의 핵심 명제. 도메인 expert·개발자·코드·문서가 같은 vocabulary를 쓴다. 번역 비용이 bug의 source. 의 🌐 Domain…
Distribution Shift 대응 방법
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 모델은 과거 패턴이 미래에도 유지된다는 가정 위에서 동작한다. 비즈니스 환경이…
EDA 1단계 — 기본 현황 파악
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ EDA의 첫 번째 단계. 분석을 시작하기 전에 데이터가 "믿을 만한 상태인지"…
EDA 2단계 — 시간 패턴 시각화
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ EDA 1단계에서 데이터 상태를 확인했다면, 2단계는 실제로 어떤 패턴이 있는지…
회귀 모델 평가 지표 — MAE, RMSE, R²
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "정확도(Accuracy) 0.8"은 분류(Classification) 문제의…
Feature Engineering — 주별 모델
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | feature | 내용 | 근거 |…
Feature Engineering — 시계열 데이터에서 feature 만들기
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Regression은 X를 알면 Y를 예측할 수 있는가를 묻는다. 판매량 예측에서…
Forecast Horizon — 예측 단위에 따른 전처리 차이
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 모델은 "지금 보이는 X 패턴으로 Y를 예측할 수 있는가?"를 학습한다. 예측…
ML 문제 정의 프레임워크 — 목적 → 손실함수 → 모델
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 모델 선택은 모델에서 시작하는 게 아니다. 항상 이 순서로 생각해야 한다. 목적이…
ML vs 딥러닝 — 무엇이 줄어들고 무엇이 남는가
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Feature Engineering — 가장 크게 줄어드는 부분이다.…
모델 비교 결과 — 주별 (val 기준)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 모델 | MAE | RMSE | |------|-----|------| |…
Spike 대응 재고 준비 전략
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 일반 regression은 평균적인 판매량을 예측한다. 재고 준비에는 평균이 아니라…
통계적 사고와 ML 모델 지형도 — 학습 로드맵
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 수식을 외우는 것이 아니다. 두 가지 질문을 습관적으로 던지는 것이다. "이 숫자가…
Time Series Cross Validation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 일반 k-fold CV는 데이터를 무작위로 k개 구간으로 나눠 돌아가며…
Train/Validation/Test Split — 시계열에서의 데이터 분할
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 구간 | 비율 | 역할 | |------|------|------| |…
핵심 명제 — 표현력 확보 후 그 안에서 단순함 찾기
ML 모델 설계를 가만히 들여다보면 두 단계가 거의 항상 분리되어 있다. 먼저 모델이 표현할 수 있는 hypothesis 전체를 넉넉히 잡고, 그 다음 그 안에서 "이 중 어느 것?"을 단순함 기준으로 좁힌다. 이…
왜 단순한 게 맞는가 — Ockham에서 Solomonoff까지
"단순한 가설을 골라라"는 격언은 14세기 William of Ockham부터 21세기 ML까지 살아남았다. 살아남은 이유는 후대가 이 격언을 점점 깊게 형식화했기 때문 — 처음엔 직관이었지만, 정보이론을 거쳐…
Regularization은 한 원리의 여러 모습이다
L1, L2, dropout, early stopping, decision tree pruning, Bayesian prior, data augmentation, weight tying, batch…
Simple is not easy — 단순함을 찾는 어려움과 사고 도구
가 두 단계 분리를 제시했다. 가 단순함의 철학적 정당화를, 이 수학적 정당화를, 이 도구의 통합 시각을 다뤘다. 이 노트는 그 위에서 한 가지 사실을 직시한다 — 그렇다면 단순한 답은 어떻게 찾는가? 그리고 그게…
VC dimension과 일반화 — 표현력과 단순함의 수학적 다리
가 단순함의 정당화를 다뤘다면, 이 노트는 단순함이 generalization에 도움이 된다는 사실의 수학적 형식화를 다룬다. Vapnik-Chervonenkis 이론은 한 줄로 요약된다 — 표현력이…
v1.0 Design 원칙 7가지 — 모든 결정의 기반
Architecture를 그리기 전에 원칙을 정한다. 모든 후속 design 결정은 이 7가지를 어기지 않아야 함. Matt가 호출한 3권 + 12% production pattern + 5 기둥에서 압축.…
Fundamentals 회귀 흐름의 지적 계보
Matt Pocock의 thesis는 한 사람의 의견이 아니라 수렴하는 산업 흐름의 한 표현이다. 그 흐름의 root와 contemporary thinker들을 추적해서, v1.0이 이 흐름의 어디에 위치하는지…
2026 산업 Hot Issues — v1.0 시장 위치 검증
2026 봄 (4-5월) 기준 agent harness 산업의 hot topic 7가지를 정리하고, v1.0의 5 기둥 + Matt thesis와 매핑한다. 결론: v1.0이 산업 컨센서스의 정중앙에 있다. 우연이…
5 패러다임 비교 + 사용자 결정 가이드
Goose · Claude Code · Codex · pi-mono · Gemini CLI 다섯 reference의 가정 매트릭스 + 각 가정에 대한 자세한 결정 가이드. v1.0이 어떤 가정을 채택할지는 사용자의…
Claude Code — 패러다임과 약점
Anthropic이 만든 closed-source agent CLI. 산업이 "harness가 무엇인가"를 다시 정의하게 만든 표준점. "98.4%가 infrastructure, 1.6%만 AI logic"이라는…
Codex — 패러다임과 약점
OpenAI의 Rust 기반 코딩 agent CLI. "agent loop는 unroll 가능한 trivial 30줄"이라는 명제와 Submit/Event 비동기 protocol로 agent 통신의 표준을 제시.…
Gemini CLI — 패러다임과 약점
Google이 만든 open-source agent CLI. 진입 장벽을 product 결정의 핵심에 두고, Google ecosystem(Search grounding, Vertex AI, GitHub…
Goose — 패러다임과 약점
Rust 진영의 가장 큰 오픈소스 agent. 그들이 무슨 가정 위에 서 있는가, 어디서 균열이 보이는가, 그 균열을 깨려는 흐름들은 무엇인가. 코드 디테일이 아니라 패러다임과 인사이트. --- Goose의 모든…
Ouroboros — Meta-Layer Agent OS (한국 개발자 사례)
Q00이 만든 한국 개발자 사례. 5 reference와 결정적으로 다른 위치 — meta-layer (Claude Code/Codex/OpenCode/Hermes 위에 얹는 Agent OS). "Stop…
pi-mono — 패러다임과 약점
badlogic(Mario Zechner)이 만든 TypeScript monorepo. 패키지 분리·SDK 모드·OSS 세션 공유라는 세 가지 차별점을 가진 개인 maintainer 주도의 reference.…
연구→실무 gap — 어디까지 production에 도달했나
산업이 문제 인식에는 컨센서스에 도달했지만, 실제 production에 살아 도착한 해결책은 매우 좁다. 이 gap이 정확히 v1.0이 점유할 자리. 결론: 단순한 패턴이 production에 도달했고, 복잡한…
Software Fundamentals Thesis — 사람과 LLM의 leveling
Matt Pocock의 강연 "It Ain't Broke: Why Software Fundamentals Matter More Than Ever" (AI Engineer Europe)에서 출발한 명제. v1.0…
Stateless의 정의 — v0.1 경계
v0.1은 호출 1회의 순수성을 지킨다. 같은 입력 → 같은 출력. 모든 "기억"은 호출자가 관리. 이 노트의 목적: agent CLI(=v1.0의 최종 형태)의 가장 안쪽 코어를 어디에 그을지 결정한다. ---…
Fundamentals 학습 자료 — Matt 기법 + "code is cheap" 비판
Matt이 제안한 구체적 기법들과 그가 비판한 "code is cheap" 명제의 root를 학습 자료로 큐레이션. 학내 사용자가 어디서부터 시작하면 좋은지 단계별 학습 path로 정리. --- "code is…
Tool vs MCP — fundamental 차이와 공유 메커니즘
"Tool vs MCP"는 잘못된 대립. 둘은 경쟁 관계가 아니라 layer 다름. MCP가 function calling을 사용하는 형태. 이 노트는 가정 4 결정의 fundamental reference.…
통계 기초 → ML 연결 도서 로드맵
전체 지도를 한눈에 보면 이렇게 생겼다. --- Naked Statistics (Charles Wheelan) 수식 없이 통계적 사고의 감각만 잡는 책. 읽기 편한 입문서. 추천 이유: 공부 시작 전 or 지치면…