참이 감자

[Claude Code] Tool 정리 - 01

참이 감자 — Sat, 22 Aug 2026 13:27:55 +0900

1. Tool이란?

Tool 개념

Claude Code가 코드베이스를 이해하고, 파일 수정, 명령어 실행, 개발 도구 통합 등 AI가 외부 세계와 상호작용하여 직접 작업을 수행할 수 있도록 확장해 주는 기능

'외부 세계와 상호작용하는 함수' 형태로 생각하면 된다.

이는 외부 MCP(Pencil.dev)를 tool로써 추가하는 사진인데, 이렇게 설정하면 Claude가 Pencil에 접근이 가능해진다.

Tool을 알아야 하는 이유

기능 확장

기본 Claude는 'text 생성'이 다이므로, 이 text에 tool+action을 통해 'file-system 접근/조작', 'bash 명령어 실행', '외부 API 연동' 등이 가능해진다.

권한 및 보안 통제

각 Tool이 동작하는 동작과 권한을 설정(Allow / Deny)하여 안전하게 사용할 수 있다.

세밀한 Workflow 설정

서브 에이전트(Sub-agent)나 훅(Hook) 등에서 어떤 Tool을 허용하고 제한할지 결정함으로써 작업 효율과 정확도를 높일 수 있다.

사용자 정의 Tool

MCP (Model Context Protocol)

외부 서버나 커스텀 서비스를 연결하여 Claude가 기본 제공하지 않는 나만의 기능(Tool)을 확장할 수 있다.

Skill

반복되는 워크플로우를 프롬프트 형태로 작성하여 확장하는 방식이며, 실행될 때 Claude 내부의 Skill이라는 전용 Tool을 사용한다.

2. Tool 종류

1) `Agent`

별도의 context window에서 sub-agent를 생성

sub-agent는 자신의 task 처리 후 결과를 '단일 text'만 부모 Conversation에 반환 => 부모는 이 Reply만 봄!

sub-agent의 tool은 tools(Allow), disallowedTools(deny) 필드에서 관리할 수 있으며, 기본적으로 부모 tool + MCP를 상속받는다.
(우선순위: disallowedTools > tool)

이 떄, 아래 tool은 sub-agent에서 사용할 수 없다.

AskUserQuestion
EnterPlanMode
ExitPlanMode (sub-agent의 permissionMode가 plan인 경우 제외)
ScheduleWakeup
WaitForMcpServers

sub-agent는 기본적으로 background에서 실행되며, 메인 세션에서 결과가 필요한 경우 foreground에서 실행시킨다. (Ctrl+B: back으로 sub-agent 이동)

background에서 실행 중인 sub-agent의 도구 호출을 위해 Esc를 누르면 해당 agent 자체가 죽는 것이 아닌, 그 도구 호출만 거부하고 다른 작업을 실행한다.

2) `Artifact`

HTML 또는 Markdown 파일을 artifact로 게시한다.

이는 Claude의 '비공개 대화형 페이지'로써, 사용자가 공유를 하면 다른 사람들도 해당 링크를 통해 들어가 내용을 확인할 수 있다.

개인적으로 나는 아래 방법으로 사용하고 있다.

디자인 하기 전 디자인 후보를 artifact로 보고 확정 짓기
빠르게 보고서 작성
세션 내 기록을 효과적으로 확인할 때

artifact의 지속 시간은 '설정 > 데이터 및 개인정보 보호 제어'에서 관리할 수 있다.

또한 artifact 그리는 것을 Claude에게 요청할 때 /artifact-design 스킬이 발동된다.

3) `AskUserQuestion`

요구사항을 수집하거나 모호함을 명확히 하기 위해 사용자에게 질문을 해주는 Tool이다.

이는 사용자가 답변할 때까지 열려있으며, default에는 timeout 없이 계속 떠있다.

만약 떠있는 시간을 제한하고 싶으면(일정 시간 지나면 대화창 닫히고 진행), askUserQuestionTimeout을 설정할 수 있다. (ex. 60s, 10m )

만약 제한시간을 설정하면 해당 대화창에서 20초부터 카운트다운이 표시된다.

질문 형태는 기본적으로 객관식이며, 그 안에서 '주관식'으로 답변도 가능하다.

[AX] LLM WIKI 개념 및 실제 사용 방법

참이 감자 — Fri, 21 Aug 2026 21:51:09 +0900

1. LLM WIKI 개념

일반 메모장 vs LLM WIKI

일반 메모장은 내가 쓰고, 내가 분류하고, 내가 찾는다. 자료 100개를 넣으면 100개가 그냥 쌓인다. 많아질수록 지저분해지고, 어디 적었는지 기억이 안 나면 끝이다.

누적은 되는데 복리가 안 된다. 이게 핵심 문제였다.

LLM WIKI는 역할이 뒤집힌다. 나는 자료를 던져 넣기만 한다. AI가 똑똑한 조수처럼 읽고, 요약하고, 분류하고, 기존 노트와 연결해서 서랍에 넣는다. 찾을 때는 서랍을 뒤지는 게 아니라 조수에게 물어본다.

	일반 메모장	LLM WIKI
분류	내가 한다	AI가 한다
검색	키워드 검색, 폴더 뒤지기	자연어로 질문
자료가 늘면	지저분해진다	기존 노트까지 같이 갱신돼 더 똑똑해진다
근거 추적	"어디서 봤더라"	모든 노트에 `source` 경로가 박혀 있다

이 구조는 올해 4월 Andrej Karpathy가 공유한 "LLM wiki" 패턴을 따른 것이다. 요지는 세 줄이다.

raw 원본은 내가 고른다. 절대 안 바뀐다.
wiki 페이지는 LLM이 쓴다. 나는 읽기만 한다.
schema는 LLM에게 "어떻게 행동할지" 적어둔 규칙이다.

Karpathy 표현을 빌리면 "다시 유도하는 걸 멈추고, 컴파일하라(stop re-deriving, start compiling)". 질문할 때마다 검색해서 읽고 잊어버리는 RAG와 달리, 위키는 한 번 정리한 지식이 남아서 쌓인다.

LLM WIKI를 쓰는 이유

써보고 느낀 이유는 네 가지다.

1) 복리로 쌓인다.
자료 하나를 넣을 때마다 AI가 기존 노트들과 다시 연결하고 재정리한다. Karpathy 방식에선 원본 하나가 10~15개 위키 페이지를 건드린다고 한다. 그래서 "A랑 B 종합하면 어떻게 돼?" 같은 질문에 시간이 갈수록 더 잘 답한다. 자료 수가 아니라 연결의 밀도가 자산이 된다.

2) 사람은 판단만, 사무노동은 AI가.
무엇을 넣을지 고르는 것과 방향 잡는 것만 내가 한다. 분류·요약·연결·중복 체크·갱신은 전부 AI 몫이다. "정리 귀찮아서 미루다 자료가 증발하는" 일이 없어졌다.

3) 출처가 항상 남는다.
원본은 절대 건드리지 않고, 정리 노트마다 어느 원본에서 왔는지 적는다. AI가 정리한 내용이 틀려도 원본에서 다시 만들 수 있고, "이거 근거가 뭐야?"에 항상 답할 수 있다.

4) 검색 엔진 없이도 잘 찾는다.
뒤에서 자세히 쓰지만, 모든 노트에 "이 노트로 답할 수 있는 질문" 목록과 한/영 동의어가 미리 박혀 있다. 벡터DB 없이 grep만으로 질문과 노트가 바로 매칭된다. 이게 된다는 게 처음엔 좀 의외였다.

Obsidian + Claude Code로 사용하는 이유

왜 노션이 아니라 Obsidian인가? 파일이 내 PC에 .md로 그대로 있기 때문이다.

노션은 API를 거쳐야 해서 AI가 훑기에 느리고, 데이터가 남의 서버에 있다. Obsidian은 그냥 폴더와 마크다운 파일이다. 사람도 읽기 쉽고 AI도 읽기 쉽고, [[위키링크]]로 노트 간 연결을 그래프로 볼 수 있다. 나중에 도구를 바꿔도 파일은 남는다.

왜 채팅창이 아니라 Claude Code인가? 내 폴더의 파일을 직접 읽고 쓰는 AI이기 때문이다.

복붙하는 게 아니라, 터미널에서 vault 폴더를 열어두면 Claude가 raw를 읽고, 노트를 만들고, index를 갱신하고, lint를 돌린다. 여기에 두 가지 장치가 결정적이었다.

Hooks — 특정 시점(파일 수정 전, 질문 제출 시, 세션 종료 시)에 자동 실행되는 스크립트. "raw 수정하지 마"를 말로 하는 게 아니라 코드로 물리적으로 막는다.
Skills — SKILL.md에 절차를 적어두면 "이거 정리해줘" 한마디에 그 절차를 그대로 따른다.

정리하면 Obsidian은 저장소, Claude Code는 엔진, 규칙 파일(SCHEMA.md, CLAUDE.md)은 엔진에게 어떻게 움직일지 알려주는 설명서다.

2. 개인 위키 (PARA 구조)

먼저 혼자 쓰는 버전부터. 강의 녹취, 멘토링 회의록, 읽은 아티클이 주로 들어간다.

3 레이어 구조 (raw / compiled / SCHEMA)

뼈대는 세 층이다.

[1] raw/        ← 원본 금고. 강의 녹취·PDF·회의록. 절대 수정 X
      │  AI가 ingest(정리)
      ▼
[2] PARA 폴더   ← AI가 정리한 노트(.md). 내가 읽고 질문하는 곳
      │
[3] SCHEMA.md   ← 규칙. "어떻게 정리할지" 적어둔 설명서

레이어	역할	왜 분리하나
1. raw	손대지 않는 금고. 파일명 `YYYY-MM-DD 제목.확장자`	정리가 틀려도 원본에서 다시 만들 수 있다
2. compiled	AI가 유지하는 PARA 노트. 질문이 향하는 곳	원본은 지저분해서 AI가 바로 못 읽는다
3. 규칙	`SCHEMA.md`(권위) · `CLAUDE.md`(진입점) · `index.md`(지도) · `hot.md`(최근) · `log.md`(이력)	규칙이 파일마다 제각각이면 AI가 매번 다르게 정리한다

raw에는 txt, pdf, xlsx, docx, pptx 뭐든 들어간다. 웹 링크는 본문을 긁어 raw/reference/에 .md 스냅샷으로 박아둔 뒤 ingest한다. 링크가 죽어도 출처가 남는다.

PARA 구조 개념

Layer 2 폴더는 PARA로 나눴다. Tiago Forte가 제안한 정리법으로, Projects / Areas / Resources / Archives의 앞글자다.

폴더	무엇	내 예시
`01-projects/`	기한·목표가 있는 진행 중 작업	졸업작품, 심심이 프로젝트
`02-areas/`	기한 없이 계속 책임지는 영역	학업, 건강, 소마 멘토링
`03-resources/`	주제별 참고 지식	AI, 코드리뷰, SEO 노트
`04-archives/`	끝났거나 안 쓰는 것	지난 해커톤, 완료 과제

PARA의 핵심 질문은 "이 자료가 무슨 주제냐"가 아니다. "이 자료가 지금 내 삶에서 얼마나 실행 가능(actionable)하냐"다.

주제별로 나누면 폴더가 끝없이 늘어난다. 실행 가능성으로 나누면 4개면 끝난다. 학업·프로젝트·멘토링·사이드 프로젝트를 동시에 굴리는 사람한테 이게 딱 맞았다.

Skill, Hook 설명

이 시스템이 "말로만 하는 규칙"이 아니라 실제로 굴러가는 이유는 .claude/ 폴더 안의 hook 3개와 skill 3개 덕분이다.

.claude/
├─ settings.json         ← hook 등록
├─ hooks/
│  ├─ raw-guard.js        raw/ 불변 강제
│  ├─ wiki-context.js     질문할 때 관련 노트 자동 주입
│  └─ stop-lint.js        세션 종료 시 무결성 점검
└─ skills/
   ├─ wiki-ingest/        raw → 정리노트
   ├─ wiki-lint/          무결성 검사
   └─ wiki-archive/       완료 항목 보관

Hook — 규칙을 코드로 강제한다.

Claude Code의 hook은 도구 호출 전(PreToolUse), 질문 제출 시(UserPromptSubmit), 세션 종료 시(Stop) 같은 시점에 실행되는 스크립트다. PreToolUse에서 exit code 2로 종료하면 그 도구 호출이 차단되고, stderr 내용이 Claude에게 "왜 막혔는지"로 전달된다.

훅	언제	하는 일
`raw-guard`	Edit/Write/Bash 실행 전	`raw/` 기존 파일의 수정·덮어쓰기·`rm`·`>` 리다이렉트를 차단. 새 파일 추가와 `mv` 리네임은 허용
`wiki-context`	내가 질문할 때마다	PARA 노트의 `keywords`·`aliases`·`title`·질문 섹션을 grep해서 점수를 매기고, 상위 6개 노트 경로와 raw 출처를 컨텍스트에 자동 주입
`stop-lint`	세션 종료 시	`wiki-lint`를 1회 실행. 문제 있을 때만 보여주고 없으면 조용히 통과

솔직히 처음엔 hook까지는 과하다고 생각했다. 그런데 "raw 수정 금지"를 CLAUDE.md에만 적어둔 동안 Claude가 정리하다 원본을 덮어쓴 게 두 번 있었다. raw-guard를 넣은 뒤로는 0건이다.

README에 적어봤자 사람은 안 읽고, AI는 가끔 무시한다. hook은 --dangerously-skip-permissions 모드에서도 돌기 때문에 사실상 유일한 안전장치다.

Skill — 반복 절차를 표준화한다.

skill은 SKILL.md라는 마크다운 파일에 절차를 적어둔 폴더다. 이름과 설명만 항상 컨텍스트에 올라가 있고, 관련 요청이 오면 그때 전문을 읽어 따른다.

스킬	트리거	하는 일
`wiki-ingest`	"이 강의 정리해줘", `/wiki-ingest`	raw 텍스트 추출 → PARA 분류 → 허브 1 + atomic n 노트 생성 → index/hot/log 갱신 → lint
`wiki-lint`	"점검해줘", `/wiki-lint`	깨진 `[[링크]]`, frontmatter 누락, TL;DR·질문섹션 누락, 고아 노트, 미-ingest raw, raw 네이밍 위반 검사
`wiki-archive`	"이 프로젝트 끝났어", `/wiki-archive`	노트를 `04-archives/`로 이동, `status: archived` 부여, index 정리. raw는 안 옮긴다

노트 형식 — 검색이 잘 되는 진짜 이유.

ingest된 모든 노트는 같은 골격을 갖는다.

---
title: ...
aliases: [한/영 동의어]
keywords: [검색할 법한 단어들]
source: raw/lectures/2026-05-29 Obsidian + Claude Code.txt
related: ["[[다른 노트]]"]
---
> [!tldr] 첫 3줄 안에 핵심 답

## 이 노트로 답할 수 있는 질문
- (예상 질문 4~6개)

## 본문 ...

## 출처

## 이 노트로 답할 수 있는 질문이 핵심이다. 일종의 역방향 인덱스다. "이 문서는 이런 질문에 답한다"를 미리 써두면, 내가 던지는 질문 텍스트와 직접 매칭된다. 여기에 aliases·keywords의 한/영 동의어가 검색 정확도의 대부분을 결정한다.

사용하는 방법

핵심은 간단하다. 딱 3단계.

1) 넣기(ingest)
강의 녹취, 회의록, PDF, 웹 링크를 raw/ 하위폴더에 던진다. 분류 고민은 안 한다. Claude Code에서 /wiki-ingest 또는 "이거 정리해줘".

2) 물어보기(query)
폴더를 뒤지지 않는다. "지난주 멘토링에서 배차 얘기 뭐였지?"라고 그냥 묻는다. wiki-context 훅이 관련 노트를 찾아 주입하고, Claude가 종합해서 raw 출처를 인용해 답한다. 위키에 근거가 없으면 "위키에 근거 없음"이라고 명시하게 해뒀다. 이게 없으면 그럴듯하게 지어낸다.

3) 점검(lint)
가끔 /wiki-lint. 세션 끝날 때 자동으로 한 번 돌아가니 사실 신경 안 써도 된다.

프로젝트가 끝나면 /wiki-archive. 이게 전부다.

사용 시 이점

Before: 녹취 파일 20개가 다운로드 폴더에 있고, 뭐가 어느 강의인지 파일명만 보고는 모른다. 필요할 때 찾다가 포기한다.

After: 파일명만 YYYY-MM-DD 제목으로 맞춰 넣으면 끝. 한 달 뒤 "그 강의에서 코드리뷰 관련해서 뭐라고 했지?" 하면 해당 문단과 날짜가 같이 나온다.

구체적으로는:

정리 부담이 0에 가깝다. 미루다 잊어버리는 자료가 없어졌다.
질문에 출처가 붙는다. "어디서 봤더라"가 아니라 "2026-05-29 강의 녹취"로 답이 온다. 블로그나 발표 자료 만들 때 근거를 바로 끌어온다.
연결이 쌓인다. 새 강의를 넣으면 예전 노트의 related에 역링크가 붙는다. 몇 달 전 메모가 오늘 질문에 딸려 나온다.
안전하다. raw가 물리적으로 보호되니 AI한테 마음 놓고 맡긴다. 정리가 맘에 안 들면 지우고 다시 ingest하면 된다.
이식 가능하다. 전부 로컬 .md라 Obsidian 없이도, Claude 없이도 읽힌다.

활용 방법

실제로 이렇게 쓰고 있다.

강의 복습 — 특강 녹취를 넣고 "이 강의에서 실무에 바로 쓸 수 있는 팁만 뽑아줘". 허브 노트 + 개념별 atomic 노트로 쪼개져 있어서 나중에 개념 하나만 다시 꺼내기 쉽다.
멘토링 맥락 복원 — "소마 멘토링에서 DRT 관련해서 멘토님이 지적한 거 전부 모아줘". 여러 회차 회의록에서 관련 대목만 날짜순으로 모아준다. 이 글 맨 앞에 쓴 그 문제가 이걸로 해결됐다.
글쓰기 재료 수집 — 블로그 주제를 정하면 "이 주제 관련 내 노트 전부 보여주고 빠진 관점 알려줘". 이 글도 그렇게 시작했다.
"이거 어디에 넣어야 돼?" — 분류가 애매한 자료는 그냥 Claude한테 묻는다. Projects인지 Resources인지 판단하고 이유까지 말해준다.

3. 팀 위키

개인 위키가 잘 굴러가니 팀 프로젝트에도 옮기고 싶어졌다.

그런데 팀은 조건이 다르다. 여러 명(+AI)이 동시에 노트를 고치고, 비개발 팀원도 있고, 회의록·기획서·리서치가 쏟아진다. 개인용을 그대로 복사했다가 일주일 만에 구조를 갈아엎었다.

내 구조 설명

설계 철학은 세 가지로 정했다.

1) 실행 우선(Action-First) — 완벽한 문서를 쓰려고 개발·고객 인터뷰를 미루지 않는다. 뼈대만 갖추고 인사이트를 계속 커밋하며 살을 붙인다. 문서는 결과물이 아니라 도구다.

2) AI가 읽기 쉽게(AI-Readability) — 모든 노트를 같은 봉투(envelope) 형식으로 감싼다. frontmatter → # 제목 → > [!tldr] → ## 이 노트로 답할 수 있는 질문 → 본문 → ## 출처. 이 일관성이 검색 정확도를 결정한다.

3) 중복 없이 상속(DRY) — 같은 내용을 여러 곳에 복붙하지 않는다. 한 곳에서만 정의(canon)하고 나머지는 [[링크]]로 참조한다. "우리 타깃 고객이 누구야?"의 답은 ICP.md 하나뿐이어야 한다.

폴더는 PARA 대신 종류별 flat 구조다.

00-meta/       ← SCHEMA, glossary, 템플릿, 스크립트
01-product/    ← 제품의 뿌리 (GOAL·ICP·VALUE) — canon
02-planning/   ← 기획
03-specs/      ← 스펙/PRD
04-decisions/  ← 결정 기록 (ADR)
05-meetings/   ← 회의록
06-research/   ← 리서치
07-individual/ ← 개인 노트 (낮은 우선순위)
90-archive/
raw/           ← Google Drive 심볼릭 링크 (git 제외)

개인용과 달라진 점을 짚어보면 이렇다.

PARA를 버린 이유. 팀 프로젝트는 제품 하나를 중심으로 돈다. "지금 실행 가능하냐"보다 "이게 회의록이냐 결정이냐 스펙이냐"가 더 중요한 질문이었다. 종류별 flat은 제품 1개일 때 가장 단순하고, AI가 탐색하기도 쉽다.

가변성 class 추가. 문서마다 "어떻게 변하는가"가 다르다. 이걸 frontmatter class:로 구분했다.

class	예시	변경 규칙
canon	GOAL·ICP·VALUE·SCHEMA	단일 진실. 사람 승인 없이 못 바꿈
log	회의록·리서치	추가만. 과거 기록 수정은 역사 왜곡
decision	ADR	스냅샷. 뒤집으면 `superseded` + 새 ADR
raw	원본	불변

canon-guard 훅 추가. canon 문서를 AI가 수정하려 하면 멈추고 before→after diff를 보여준 뒤, 사용자가 APPROVE CANON: <파일>을 직접 입력해야 통과한다. 타깃 고객 정의가 AI 손에 몰래 바뀌면 팀 전체 의사결정이 흔들린다.

07-individual 분리. 개인 의견은 팀 합의와 권위가 다르다. wiki-context 훅이 이 폴더 노트는 별도 블록("~님의 개인 의견, 참고용")으로 주입해서 canon/log와 섞이지 않게 했다.

<br.

type별 본문 템플릿. 봉투는 공통이지만 회의록엔 참석자·안건·Action Items, ADR엔 맥락·선택지·결정·근거가 필요하다. 00-meta/templates/에 type별 템플릿을 두고 ingest 시 따르게 했다. 노트 품질이 눈에 띄게 고르게 나온다.

Google Drive + Git을 사용하는 이유

팀 위키에서 가장 고민 많이 한 결정이다. 결론은 raw와 compiled를 다른 곳에 둔다.

raw → Google Drive

원본은 PDF·녹취·엑셀 등 바이너리·대용량이 많다. Git에 넣으면 레포가 비대해지고 LFS는 귀찮다.
원본은 안 바뀌니까 버전 관리가 필요 없다. 파일 공유면 충분하다.
비개발 팀원도 Drive에 드래그만 하면 된다. Git을 몰라도 된다. 이게 제일 컸다.

compiled → Git

정리 노트는 여러 명(+AI)이 동시에 고친다. Git이 3-way merge로 충돌을 해결해 준다. Drive에 .md를 두면 동시 편집 시 "파일 (1)" 충돌 사본이 생긴다. 실제로 겪었다.
이력·되돌리기·PR 리뷰가 된다.
git pull 한 줄로 팀 전체가 최신 상태를 받는다.

둘은 심볼릭 링크로 잇는다. 프로젝트 폴더 안에 raw/가 있지만 실제로는 Drive 경로를 가리키는 링크다. AI는 raw/meetings/2026-07-01 킥오프.txt처럼 로컬 경로로 접근하고, .gitignore가 raw/를 제외한다. 팀원마다 Drive 마운트 경로가 다르니(macOS/Windows/WSL) .env에 자기 경로를 넣고 setup-raw-link.sh를 한 번 실행하면 된다.

<br.

절대 하면 안 되는 것: 레포를 통째로 Drive 폴더 안에 두기. .git 디렉토리가 Drive 동기화와 충돌해서 저장소가 깨진다. 레포는 Drive 밖, raw만 Drive 링크.

`wiki-ingest-and-push` 스킬 추가

개인 위키는 ingest하면 끝이지만, 팀 위키는 정리한 노트를 공유해야 끝난다. 그래서 스킬을 둘 더 만들었다.

스킬	하는 일
`push`	`git pull --rebase` → lint 사전점검(실패 시 멈춤) → `git add -A` → 한글 커밋(`docs(05-meetings): 킥오프 회의록 ingest`) → `git push` → Slack 알림
`wiki-ingest-and-push`	`wiki-ingest` + `push`를 한 번에. lint 통과 못 하면 push 안 함

lint → commit → push → Slack 알림을 매번 손으로 하면 반드시 하나는 빼먹는다. "ingest하고 푸시해줘" 한마디로 끝나야 팀원이 실제로 쓴다.

팀에서 사용하는 방법

① 사람: Drive에 raw 넣기 (파일 드래그, Git 몰라도 됨)
   ↓  Drive가 각 PC로 동기화 (보통 몇 초~1분)
② AI에게: "ingest하고 푸시해줘"
   ↓  sync 확인 → raw 읽기 → 봉투 노트 생성 → index/hot/log 갱신 → lint → 커밋 → push → Slack 알림
③ 팀원: Slack 알림 보고 git pull → 최신 노트로 질문·열람

비개발 팀원에게 설명하는 규칙은 딱 3개다.

raw는 안 고친다. 새 원본은 새 파일로.
canon(GOAL·ICP·VALUE) 변경은 승인을 거친다.
compiled 노트는 자유롭게 고쳐도 된다. Git이 이력을 남긴다.

읽을 때는 Obsidian으로 열고 index.md에서 시작하거나, 그냥 Claude한테 묻는다. hot.md는 "어제 뭐 바뀌었어?"용(최신이 위), log.md는 전체 이력용(시간순)이다.

사용 시 이점

Before: 회의록은 노션에 쌓이는데 아무도 다시 안 본다. "그때 가격 정책 왜 그렇게 정했지?" 하면 기억에 의존한다. 타깃 고객 정의가 기획서·스펙·슬라이드에 제각각 복붙돼 있어서 셋이 다 다르다.

After:

회의록이 실제로 검색된다. "지난달 가격 정책 어떻게 결정했지?" 하면 ADR과 관련 회의록을 모아 출처와 함께 답한다.
단일 진실이 지켜진다. ICP.md 하나를 [[링크]]로 참조한다. 어긋날 수가 없다.
결정의 이유가 남는다. ADR 덕분에 새 팀원도 "그때 왜 그랬는지"를 추적한다.
진입 장벽이 낮다. 비개발 팀원은 Drive 드래그 + AI한테 한마디. 개발자는 익숙한 Git.
AI가 실수해도 복구된다. raw 불변 + Git 이력 + lint 게이트, 세 겹이다.

활용 방법

킥오프 직후 — GOAL·ICP·VALUE를 canon으로 먼저 박는다. 이후 모든 기획·스펙이 여기를 참조한다.
회의 끝나면 — 녹취/메모를 Drive에 넣고 "ingest하고 푸시해줘". Action Items는 - [ ] @담당 ~납기 형식으로 자동 추출된다.
고객 인터뷰·리서치 — 웹 소스는 Exa MCP로 검색해 raw/reference/ 스냅샷으로 저장 후 ingest. 링크가 죽어도 근거가 남는다.
의사결정 회의 전 — "이 주제 관련 기존 결정과 리서치 요약해줘". 맥락을 갖고 들어간다.
온보딩 — 새 팀원에게 00-meta/WIKI 사용법.md 하나 주고 "궁금한 건 Claude한테 물어봐".

피보팅이 될 때

스타트업은 제품이 바뀌거나 늘어난다. flat 구조는 제품 1개일 때 최적인데, 2개 이상이 되면 products/<제품>/ 하위로 unfold한다.

mkdir -p products/<제품명>
git mv 01-product/*  products/<제품명>/
git mv 02-planning   products/<제품명>/planning
git mv 05-meetings   products/<제품명>/meetings
# ...

이게 비용 거의 0으로 되는 이유는 두 가지다.

[[wikilink]]는 경로가 아니라 파일명 기준이라 폴더를 옮겨도 안 깨진다. [링크](../01-product/GOAL.md) 같은 상대경로를 썼으면 전부 깨졌을 거다.
source: raw/...는 Drive에 전역 고정이라 compiled가 어디로 가든 출처가 유지된다.

기존 제품 문서는 지우지 않는다. 피보팅 전 결정은 superseded ADR로 남기고, 끝난 문서는 90-archive/<연도>/로 git mv한다. 삭제하면 "왜 그 방향을 접었는지"라는 제일 값진 기록이 사라진다.

4. 사용하고 느낀 점 및 앞으로의 계획

느낀 점

정리의 병목은 분류가 아니라 귀찮음이었다.

분류 체계를 아무리 잘 만들어도 내가 안 하면 소용없다. 분류를 AI한테 넘기고 나서야 자료가 실제로 쌓이기 시작했다.

보고서 작성 시간이 엄청 줄어들었다.

리서치, 나의 의견, 개발 등 다양하게 해왔던 기록들이 모두 저장돼있고, 이것을 AI가 잘 찾아준다. 따라서, '딸깍' 하나에 내가 이전에 했던 것들이 다 기록으로써 바로바로 나올 수 있으므로, 남들에게 내 의견과 작업을 보고서로써 전달하는 것이 매우 빨라졌다.

검색 품질은 ingest 시점에 결정된다.

keywords·aliases·"이 노트로 답할 수 있는 질문"을 얼마나 풍부하게 넣었느냐가 몇 달 뒤 적중률을 좌우한다. 벡터DB 없이 grep만으로 충분히 쓸 만하다는 게 의외였다.

hook 없는 규칙은 규칙이 아니다.

위에 썼지만 다시 쓴다. 문서에 적어둔 동안엔 사고가 났고, hook을 넣고 나선 0건이다.

개인과 팀은 다른 구조가 맞다.

개인은 "지금 실행 가능하냐"(PARA), 팀은 "어떤 종류의 문서냐 + 얼마나 바뀌어도 되냐"(type + class). 하나로 통일하려다 둘 다 어정쩡해지는 걸 겪었다.

복리는 진짜다.

석 달 치 강의·회의가 쌓이니 "A 강의에서 배운 걸 B 프로젝트에 적용하면?" 같은 질문에 내가 생각 못 한 연결을 가져온다. 이 순간에 "만들길 잘했다" 싶었다.

앞으로의 계획

콘텐츠 생성

WIKI에 있는 knowledge base를 기반으로 PPT, 영상, 게시글 등 콘텐츠를 만들어 수익을 창출해볼 계획이다.

실제 기업용 WIKI 만들기

이렇게 local 기반으로 작업을 하기엔, 문서가 많아질수록 부담이 커질 수 있다. 따라서 'openwiki', 'GraphRAG' 등 공부를 하며 실제 기업적으로 사용할 수 있는 WIKI를 만들어보고 싶다.

5. Tl;DR

자료는 던져 넣기만, 원본은 건드리지 않고, AI가 정리하고, 찾을 땐 묻는다. 쌓일수록 똑똑해진다.

혹시 비슷한 걸 만들어 쓰고 계신 분이 있다면 어떤 구조로 굴리시는지 궁금하다. 특히 팀 위키 쪽은 아직 개선할 게 많아서, 댓글로 의견 남겨주시면 감사하겠습니다!!

6. 참고 자료

[Claude Code] Claude Code 프롬프트 캐싱 정리

참이 감자 — Thu, 20 Aug 2026 14:53:12 +0900

1. 캐시 구성 요소

Prefix (text 기반)

레이어	내용
System Prompt Layer	기본 도구(core tools) + 기본 system 지침
Project Context Layer	`CLAUDE.md` 등 세션 고정 설정 파일
Conversation Layer	지금까지 누적된 대화 내역 (Message, Reply)

Header (Request metadata)

Model
Effort level
Fast mode

Appended requests

Skills · Commands · Agents · Hooks · LSP server · Monitors · Themes · Deferred tools · advisor tool

Cache-Hit 조건

캐시가 Hit되면 모델에 전체 텍스트를 Compute해서 넣을 필요가 없음
Cache Key(Prefix + Header) 가 바뀌면 → 다시 Compute해서 넣어야 함

**Tip

세션 시작 시 Model과 Effort를 먼저 선택하고, 작업 중간에는 가급적 변경을 피할 것.
자연스러운 휴식 타이밍에 /compact로 관리하면 캐시 히트 확률이 올라감!

캐시가 있는 위치

캐싱은 서버 측에서 발생하며, Model을 제공하는 인프라에 위치함.

사용 환경	캐시 위치
API, OAuth, Claude Platform on AWS	Anthropic Infra (Claude API를 통해 액세스)
Amazon Bedrock, GCP Agent Platform	클라우드 제공자의 Infra
Microsoft Foundry	Anthropic 인프라로 요청이 라우팅됨
사용자 정의 `ANTHROPIC_BASE_URL` / LLM gateway	요청이 전달되는 위치. 작동 여부는 gateway에 따라 다름

2. 캐시를 무효화하는 작업 — "Cache Key가 바뀔 때"

① 모델 전환

각 모델은 자체 캐시를 가지므로, 세션 도중 model을 전환하면 다음 요청에서 전체 context를 다시 읽어야 함.

opusplan, Fable 자동 모델 fallback 도 모델 전환에 해당 → 캐시 없이 re-run하고 동일 세션 내에서 작업 진행

② Effort level 변경

동일한 모델이어도 각 effort마다 자체 캐시를 가지므로, effort 수준이 바뀌면 re-run됨.

단, 각 모델마다 default effort가 있어서 default와 똑같은 effort로 변경하면 무효화 없이 캐시 유지

③ Fast Mode 켜기

Request Header가 추가되므로, 다음 요청이 Cache-hit 없이 전체 context를 읽음.

캐싱 안 된 input token은 fast mode rates로 청구 → 세션 시작 시 켜는 것이 중간에 켜는 것보다 저렴
Fast mode는 Opus model에서만 지원
다른 모델에서 활성화하려 하면 Claude Code가 자동으로 Opus로 전환 → 새 캐시가 시작됨

④ disconnect된 MCP Server 연결

MCP도 tool이므로 System Prompt Layer에 속함. 중간에 tool 정의 집합이 변경되면 캐시가 무효화될 수 있음.

1) 일반적인 경우 (Deferred tools, 기본값)

Tool Search 활성화 상태
Tool이 백그라운드 영역에 있어 search해서 꺼내 쓰는 방식
서버 연결/해제, 도구 목록 변경 → 새 내용만 추가되고 기존 캐시는 유지됨

2) Prefix-loaded tools

Tool Search 비활성화 상태
- GC Agent Platform
- Custom Gateway (Custom ANTHROPIC_BASE_URL)
- alwaysLoad로 표시된 서버/도구
Prefix에 tool이 다 적혀 있으므로 tool이 바뀌면 Prefix가 깨짐 → 캐시 무효화

3) advisor 도구

Cache breakpoint 이후에 있으므로, (비)활성화해도 캐시 유지

⑤ Plugin (비)활성화

플러그인 변경은 /reload-plugins 실행 또는 새 세션 시작 시점에 적용됨.
→ 따라서 중간에 /plugin install, /plugin enable, /plugin disable을 해도 캐시는 바뀌지 않음.

/reload-plugins로 전체 context를 다시 읽어야 하는 경우의 동작:

경고 메시지 발생 (비용이 많이 들 거라는 경고)
자동으로 reload 적용 X (실수로 비용 낭비하지 않도록)
--force flag를 붙이면 경고를 무시하고 reload 진행

=> Plugin Skill Prompt 영향으로 인한 캐시 무효화 위험 → 그래서 경고가 필요함

한편 Skills, commands, agents, hooks, LSP 서버, monitors, themes는 캐시를 무효화하지 않음.
(이 Request들은 기존 대화 뒤에 추가되므로, 그 이전의 모든 것은 캐시에서 읽음)

⑥ 기본 Tool을 '거부 규칙'에 추가

기본 Tool(예: Bash, WebFetch 등)은 System Prompt Layer에 있으므로, 거부 규칙에 추가하면 Context에서 완전히 제거됨 → 세션 중 캐시 무효화

단, Deferred tools를 deny하면 캐시 유지 (예: mcp__*, Bash(rm *) 같은 범위 지정 거부 규칙)

⑦ Compact

메시지 기록을 요약으로 바꾸므로, 설계상 Conversation Layer를 무효화시킴
→ System Prompt Layer는 재사용하고, Project Context는 disk에서 다시 load함

CLAUDE.md와 Memory가 변경되지 않은 경우에만 Cache-Hit
평소에 CLAUDE.md를 편집하는 건 기존 캐시 영역에 즉각 영향을 주지 않아 캐시가 유지됨
하지만 /compact를 실행하는 순간 디스크의 최신 상태를 강제로 다시 긁어오기 때문에, 그 사이 CLAUDE.md나 Memory가 수정됐다면 캐시 무효화!

compaction 생성을 위해 System Prompt, Tools, History를 일회성 요청하고 요약 지침을 conversation으로 추가함
→ Prefix를 공유하므로 기존 캐시를 유지하여 읽음

compaction 생성 요청 자체는 요약 생성 때문에 리소스가 들지만, 그 이후부터는 짧아진 대화 기록을 바탕으로 Cache-Hit를 유지하며 효율적으로 작업 가능

Compact Tip

더 이상 필요하지 않은 Context를 버릴 때 유리함
auto-compaction을 기다리지 말고, 휴식 시간에 한 번씩 /compact 실행 권장
Compaction이 과도했거나 Context가 유실됐다면 /rewind로 되돌릴 수 있음

⑧ Claude 업데이트

새로운 Claude Code 버전은 일반적으로 시스템 프롬프트 또는 도구 정의를 업데이트하므로 업그레이드 후 첫 번째 요청은 캐시를 처음부터 다시 구축

자동 업데이트는 백그라운드에서 새 버전을 다운로드하지만 다음 시작 시에만 적용하므로 세션 중에 놀라운 일이 아닌 재시작 후 적용됨

3. 캐시를 유지하는 작업

① repo의 file 편집

File Contents는 Read할 때만 Context에 들어가며, 이는 Conversation에 추가됨

파일이 변경됐으면, Claude Code가 자동으로 <system-reminder> 태그를 붙여 메시지를 추가하는 방식

② 세션 중 `CLAUDE.md` 편집

CLAUDE.md는 세션 시작 시 한 번 읽혀지고 Memory에 보관됨

세션 중에 편집해도 편집본이 적용되지 않음

/clear, /compact or 세션 재시작을 해야 변경되어 로드됨

③ 출력 스타일 변경

출력 스타일은 세션 시작 시 한 번만 읽은 System Prompt의 일부

/config 또는 outputStyle로 설정하며, CLAUDE.md와 마찬가지로 중간에 편집해도 적용되지 않음

④ 권한 모드 변경

권한 모드는 System Prompt or tool 정의를 변경하지 않으므로 캐시가 유지됨

단, opusplan 모델 설정한 Plan mode에서는 모델이 바뀌므로 캐시가 무효화됨

⑤ Skill / Command 호출

호출 지점에서 Conversation layer에 들어가므로 캐시가 유지됨

⑥ `/recap` 실행

/recap : 터미널에 표시할 요약을 생성

메시지 기록을 바꾸는 대신 요약을 명령 출력으로 추가하기 때문에 Prefix가 유지됨

⑦ `/rewind` 실행

/rewind: 대화를 이전 턴으로 되돌림

남은 기록들은 이미 Cache로 구축되어 있으므로, 캐시가 유지됨

3. 캐시 수명 (Cache Lifetime)

Cached Prefix는 비활성 기간 후 만료됨

각 요청은 Cache-Hit 타이머를 재설정하므로, 계속 작업하는 한 캐시는 유지됨

TTL(Time To Live, 캐시가 견디는 간격 길이)가 초과되면 캐시가 무효화됨

OAuth Subscription

자동으로 1시간 TTL 요청

한도 초과 후 Credit 사용할 시에는 자동으로 TTL이 5분으로 감소됨

API key or third-party provider

기본 5분 유지

ENABLE_PROMPT_CACHING_1H=1 옵션을 설정하여 1시간 TTL 설정 가능

Override the TTL

FORCE_PROMPT_CACHING_5M=1를 적용하면 인증 방식, 환경 설정에 관계없이 5분 TTL 강제

4. 캐시 범위

머신과 디렉토리 단위 격리

System Prompt에는 작업 디렉토리, 플랫폼, 셸, OS 버전, 자동 메모리 경로 등이 포함

따라서, 디렉토리가 다르면 서로 캐시를 공유하지 못하고 각각 따로 구축함

동일 repo의 git worktree에서 디렉토리가 달라도 캐시를 공유하지 않음

동일 디렉토리에서의 다른 섹션

병렬 세션 - Prefix가 일치하므로 서로 캐시를 읽고 공유

순차 세션 - 시작 지점의 git 상태 스냅샷이 일치할 떄만 캐시를 공유하며, 커밋 상태가 달라지면 System Prompt가 바뀌어 캐시를 공유할 수 없음

기본적으로 Organization 단위로 격리되며, 제공자에 따라 조직 내 workspace 단위로 격리될 수도 있음

이 경계 안에서 동일한 Model & Prefix를 가진 요청이라면 캐시를 공유

Agent SDK

다른 디렉토리 or 머신에서 에이전트를 실행하면 Prefix가 달라지는 문제점 발생

=> excludeDynamicSections: true 옵션을 활성화하면 세션 별 동적 프롬프트가 System Prompt에서 빠져 첫 번째 사용자로 이동하므로, 정적 프리셋과 append 텍스트만 남아 여러 머신이나 디렉토리 간에도 프롬프트 캐시를 공유할 수 있음

5. 캐시 성능 확인

캐시 성능은 API가 모든 응답에 보고하는 두 개의 토큰 수로 표시됨

필드	요약	의미
`cache_creation_input_tokens`	캐시 쓰기/생성	이번 턴에서 캐시가 기록된 토큰, 캐시 쓰기 속도로 청구됨
`cache_read_input_tokens`	캐시 읽기/재사용	이번 턴에서 캐시에서 제공한 토큰, 표준 입력 속도의 약 10%로 청구됨

current_usage: 라이브로 위 두 필드를 감시

=> 비용 관리할 떄 '캐시' 파트에서는 캐시 무효화를 중점으로 모니터링 및 관리하면 됨!

OpenTelemetry(OTel)

표준화된 로그, 메트릭, 추적 데이터를 수집하고 전송하기 위한 오픈소스 관찰성(Observability) 표준

=> Claude Code가 이를 지원하므로, 캐시 비용 모니터링 결과를 모니터링 서버로 보낼 수 있음

6. 서브에이전트 및 캐시

서브에이전트는 자체 캐시를 구축함

자동 한 시간 TTL이 메인 세션에 적용되더라도, 여기에서는 5분 TTL을 사용

부모의 캐시는 영향을 받지 않음

=> 부모의 프리픽스는 그대로 유지되며, 포크(Fork)의 경우 부모의 시스템 프롬프트, 도구, 대화 기록을 정확히 상속하므로 첫 요청에서 부모의 캐시를 그대로 읽음

Fork

부모 대화의 완벽한 복사본으로써, 부모의 Cache Key, Conversation을 그대로 물려받아 세션을 시작하는 행위

7. 프롬프트 캐싱 비활성화

DISABLE_PROMPT_CACHING : 모든 모델에 대해 비활성화
DISABLE_PROMPT_CACHING_HAIKU/SONNET/OPUS/FABLE : 특정 모델에 대해 비활성화

만약 조직 전체에 Caching 정책을 설정하려면, 위 변수 or TTL 변수를 설정 파일의 env 블록에 넣으면 됨

출처

Claude Code Docs - Prompt Caching

[AX] AI Agent 기초

참이 감자 — Wed, 19 Aug 2026 22:05:56 +0900

2026-07-25 AI-AX_1편.pdf

0.78MB

1. LLM 이해

LLM은 결국 Text를 Text로 답변해주는 모델에 불과하며, 모든 답변은 확률론적으로 답변된다.

2. RAG

LLM이 주어진 문서들에 기반하여 답변할 때, 관련된 문서(Chunks)를 검색(Retrieval)하여 LLM에 주입 후 답변을 text로 낸다.

3. LLM vs Agent

Agent = LLM + tool + action

tool: grep, ls, MCP 등 외부를 조작하고 조회할 수 있는 도구
action: tool을 실행하고 어떤 tool을 쓸 지 결정

=> 이를 통해 Agent는 우리의 file-system에 있는 코드도 고치고 다양한 tool과 그에 맞는 action을 통해 많은 작업을 AI로 할 수 있다.

4. Desktop App vs CLI

Desktop은 tool이 제한돼있다. 물론 MCP, file-system 등 연결해서 사용할 수 있지만 CLI를 사용하면 자연스럽게 많은 tool과 action을 사용하고 연결할 수 있다.

5. Skills

많은 요구사항 및 프롬프트 등을 하나의 명령어로 수행할 수 있는 기술이다. 이는 '자동화'의 핵심이자 전부이다.

6. Hooks

아무리 문서에 위험사항을 적어놔도 AI가 제대로 읽지 않으면 사고가 나기 마련이다. 따라서, 위험사항을md가 아닌 '코드'로 적어놓고 특정 시점에 발생시켜 위험 요소를 사전 차단할 수 있다. 이 또한 자동화에서 핵심으로 가져가야 할 기술이다.

7. Workflow = Skills x Hooks

위 Skill과 Hook을 적절히 만들고 섞어놓으면 그것이 바로 Workflow다. 이 워크플로우를 어떻게 세팅하느냐에 따라 자동화가 무한으로 될 수 있고, 하네스, SDD 등 요즘 나오는 방법론들을 맘대로 만들고 설정할 수 있다.

8. Context 관리

Agent의 Context Window는 아래로 구성돼있다.
System Prompt + Context + Input

이게 LLM의 input으로 들어가 output으로써 tool+action+response text가 나오는 것이다.

LLM의 한계로써 context window가 길어지면 '환각(Hallucination) 및 속도/성능 저하'가 발생하므로, Context + Input을 적게 해야한다.

이 때, 한 세션에서 input들은 계속해서 context에 들어가므로, 각 agent(session)을 분리하여 해당 context를 적게 함으로써 각 agent의 성능 향상 및 페르소나 부여를 해줘야 한다.

9. Multi(Sub) Agents

위에서 말한 agents를 분리하여 작동시키고 workflow를 실행시키는 것이 곧 Multi(Sub) agents 사용이다. 이렇게 하면 특정 큰 작업에서 task를 각 agent가 나눠가짐으로써, Context를 오염시키지 않게 할 수 있다.

10. "하네스는 방법론이다"

하네스 = "인공지능(AI) 에이전트가 안전하고 안정적으로 업무를 수행할 수 있도록 모델 바깥의 전체 작업 환경과 통제 구조를 설계·구축하는 일"

= Hook을 설정해두고 Skill을 통해 agent로 개발하는 일

최근에 나오는 SDD, Goal, Ralph-loop, Compound-engineering, Loop-engineering 모두 결국 Skills x Hooks 조합으로 만들어진다.

이 점만 기억해두면 앞으로의 AI-Native Setting에서 개념적으로 이해가 안되는 일은 없다!

+ 알아야 하는 개념

- GPT (Generative Pretrained Transformers)

https://wikidocs.net/184363

19-01 지피티(Generative Pre-trained Transformer, GPT)

- 16챕터와 17챕터의 사전 학습을 권장드립니다. 2022년 OpenAI에서 `ChatGPT`란 인공지능 모델을 공개하였고, 이어 `GPT-4`, `GPT-4o` 등을 연속으…

wikidocs.net

- RAG (Retreival-Augmented Generation)

https://kimjy99.github.io/%EB%85%BC%EB%AC%B8%EB%A6%AC%EB%B7%B0/rag/

[논문리뷰] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

RAG 논문 리뷰 (NeurIPS 2020)

kimjy99.github.io

- Claude Code Docs

https://code.claude.com/docs/en/overview

Overview - Claude Code Docs

Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. Available in your terminal, IDE, desktop app, and browser.

code.claude.com

- Harness

https://yozm.wishket.com/magazine/detail/3718/

에이전트 하네스 완전 해부 | 요즘IT

이 글은 AI 에이전트 시스템에서 모델을 감싸는 인프라, 즉 '하네스(Harness)'의 개념을 정의하고, 파일시스템·샌드박스·메모리·컨텍스트 관리 등 핵심 구성 요소를 모델의 한계에서 역추적하여

yozm.wishket.com

이전 Velog 링크입니다!

참이 감자 — Wed, 19 Aug 2026 21:41:16 +0900

https://velog.io/@gaiogo2/posts

[소마] 부산 소마 17기 중간 후기

참이 감자 — Sun, 16 Aug 2026 17:18:20 +0900

부산 소마 17기 합격하고 예비과정 2개월 + 본과정 1개월이 흘렀다.
생각보다 정신없고 시간이 훌쩍 지나서 늦게나마 후기를 남겨보기로 했다!

워크숍

워크숍은 OT를 가장한 팀매칭 장소였다. 미리 3인 팀을 구성하기 위해 150명이 서로 대화하고 다니며 각자의 방향성, 목표, 핏 등을 아침부터 새벽까지 맞추는 시간이였다.

창업, 취업, 수익화, 사용자 모으기 등 사람들마다 목표가 너무나 달라 여러 명을 만나느라 너무 힘들었지만, 다행히도 좋은 팀분들이 팀 요청을 주어서 감사히 편하게 팀을 구성헀다. 너무 좋은 팀원들을 만나 지금까지 즐겁게 생활하고 있다!

예비 과정

아이디어 기획

팀장님께서 DRT라는 획기적이고 사회공헌적인 아이디어를 들고왔고, 사업성도 좋았으며 모두가 관심이 생겨 2달 간 열심히 기획 및 개발을 하였다. 이 과정에서 전담 멘토님들께 칭찬도 받고 혼도 나며 열심히 아이디어를 구체화하였다. 이 아이디어는 '정부과제형 B2G' 프로젝트 였는데, 법, 영업 방식 등 생소한 개념이 너무 많아 평소에는 알 수 없었던 내용을 많이 공부할 수 있었다.

전담 멘토님 & 엑스퍼트

팀 당 3명의 기술멘토님들, 개인 당 1명의 엑스퍼트를 구성하여 많이 배우고 다양한 경험을 할 수 있었다. 타 부트캠프와 다르게 멘토님들이 '팀원'만큼 시간을 쏟아주시고 가르침도 많이 주어 너무 좋은 경험이였다.

또한, 엑스퍼트님은 토스 FE 현직자분과 매칭되었다.

덕분에 FE에 대한 많은 지식과 꿀팁(?)을 배울 수 있었으며, 토스도 실제 견학해볼 수 있었다...!!

디자인 씽킹

소마는 일반 개발이 아닌 아이디어 기획, 창업 등 다양한 부분을 배울 수 있다. 예비 과정에서 '디자인 씽킹'을 하면서 아이디어 기획 및 MVP 스코프 잡는 과정을 배울 수 있었다.

또한, 디자인 씽킹 팀원들과 친해져서 현재도 재밌게 같이 지내고 있다!

AI 기술 교육

이번 소마에서는 'AI 기술 교육' 프로그램이 추가되었다. 이는 랜덤 5명의 팀원과 함께 2~3주 간 AI 기반 서비스를 만들고 발표하는 프로그램이다.

'Upstage AI'와 함께 진행되었으며, 멘토님이 1분 붙어 프로젝트를 진행하였다.

우리는 '마인크래프트 초보를 위한 코칭 가이드'를 만들었으며, 인게임 내 GUI를 통해 LLM 기반으로 미션을 받고 이를 수행할 수 있는 프로젝트다.

운좋게 1등을 하여 발표도 진행하였고, 상품도 받아가는 좋은 경험이였다!

(+ 발표하면서 앞에서 마인크래프트 게임도 했다,,,)

개인 공부

소마에서는 다양한 주제로 특강이 열린다(ex. BE, FE, 소프트 스킬, AI 시대 대비, AX 등)

엄청난 실력을 가진 멘토님들이 온라인/오프라인으로 강의를 해주신다.

나는 평소에 귀찮고 어려워서 하기 힘들었던 'AI Coding 및 AX'를 집중적으로 공부하였다.

처음에는 "이게 뭔소리지... 그냥 평소처럼 클로드 쓰면 안되나" 생각이 들었지만, 강의를 듣고 공부를 해보면서 점점 매력을 느끼게 되었다. 원리를 알고 실습을 해보니까 신세계(?)를 보는 기분이였다.

이제는 와이어프레임, 디자인, 코딩, 문서 작성 및 관리, 자동화 작업 등을 AI를 통해 직접 커스텀하고 제작할 수 있는 능력이 생겼다. 소마 사람들과도 공유하고 배우면서 관련 지식이 점점 쌓아지고 있는 느낌이다! 관련 내용도 틈틈히 기록할 계획이다.

본 과정

이 때부터는 본격적으로 프로젝트가 진행된다.

본 센터 열림!

센터가 엄청 으리으리하다. 서면 한가운데 19층에 있고 시설도 좋아서 매우 만족 중이다! 하지만 모니터 자리가 한정되어있어 자리 경쟁이 좀 있다..
(아침 9시 10분 넘어서 오면 자리가 없다,,,,,,,,,)

(+ 7월 28일부터는 '자리 예약제'로 운영된다고 한다.)

피봇팅..

우리 아이디어가 '사업성 + 차별화'가 없다는 이유로 피봇팅 검토를 받게 되었다..

워크숍 때부터 2달간 열심히 진행해온 프로젝트인만큼 애정도 깊고 시간도 많이 썼는데, 처음에는 이해가 전혀 안됐지만 알아보다보니 사업성이 없다는 것을 느꼈다.

이걸 고집하고 갈 지, 새로운 아이디어로 진행할 지 결정하는 과정 속에서 모두가 힘들어했다. 특히 팀장님은 옛날부터 아이디어를 생각해온 만큼 더 애정이 깊어서 힘들어했다.

고민을 하다가 팀원에게 피보팅을 해보자고 제안하였다.

소마 과정 자체를 즐기기에 힘들진 않았지만, 2달간 다같이 열심히 한 만큼 아쉬움이 매우 컸다. 현재는 새로운 아이디어로 진행이 잘 되고 있으며, 오히려 사업성 및 즐거움이 더 커져 다행히 다같이 즐겁게 진행하고 있다.

창업집중형 트랙

우리 팀은 '함부로 해볼 수 없는 경험'을 위해 창업을 해보기로 하였고, 소마에서 신규 개설된 '창업집중형 트랙'을 선택했다.

여기서는 무한 피봇팅이 가능하며, 돈만 벌면 된다...!
일반 개발과 다르게 '돈 보는 눈'을 기르는 것이 매우 어렵다...

아직 기간이 많이 남았기 때문에 포기하지 않고 열심히 진행해보려고 한다!

첫 자취

부산에서 진행해야하기 때문에 어쩌다보니 첫 자취가 시작됐다.
센터 5분 거리에 있는 빌라에서 현재 2달 째 자취중이다.

대학교 다닐 때 편도 1시간 30분 통학을 하다가 걸어다니다 보니 매우 편하다. 또한, 자취를 해보니까 엄청나게 자유롭다! 돈을 많이 써야하긴 하지만, 아직은 매우 재밌다.

(친한 형들이 집에 놀러왔는데 집 상태를 보고 욕을 엄청 해서 매우 반성 중이다..)

첫 맥북

소마에서는 기기 지원금으로 300만원을 지원해준다. 지금까지 60만원짜리 가성비 윈도우 아이디어패드를 사용했으나, 처음으로 맥북 프로를 구매해 사용하게 됐다.

뭔가 진정한 개발자가 된 느낌이다(?)

멘토님들과의 만남

전담 멘토님들께서 온라인, 오프라인 가리지 않고 계속해서 피드백도 주시고 응원도 해주신다. 멘토님들 덕분에 사업도 배우고 개발도 배우고 소프트 스킬, 멘탈 관리, 성장 등 다양한 부분에서 계속해서 도움을 주시고 있다.

만약 18기를 지원하는 연수생분께서 이 글을 본다면 '정문창 멘토님'과 '유호균 멘토님'을 강추한다!!

부산에도 자주 와주시고 맛있고 비싼 것도 엄청 많이 사주신다!

프로젝트 진행

현재는 새로운 아이디어로 열심히 즐겁게 진행중이다!

앞으로의 계획

열심히 프로젝트도 진행하지만, 내가 소마를 왔을 때 목표가 있었다.

창업을 해보기로 했으므로 취준은 좀 약해지지만, 공부는 계속할 계획이다.
AI 사용에 대해서도 계속해서 공부할 계획이다.
'네트워킹'은 운좋게 사람들이 너무 좋아서 잘 진행되고 있다!

참이 감자

[Claude Code] Tool 정리 - 01

1. Tool이란?

Tool 개념

Tool을 알아야 하는 이유

사용자 정의 Tool

2. Tool 종류

1) Agent

2) Artifact

3) AskUserQuestion

[AX] LLM WIKI 개념 및 실제 사용 방법

1. LLM WIKI 개념

일반 메모장 vs LLM WIKI

LLM WIKI를 쓰는 이유

Obsidian + Claude Code로 사용하는 이유

2. 개인 위키 (PARA 구조)

3 레이어 구조 (raw / compiled / SCHEMA)

PARA 구조 개념

Skill, Hook 설명

사용하는 방법

사용 시 이점

활용 방법

3. 팀 위키

내 구조 설명

Google Drive + Git을 사용하는 이유

wiki-ingest-and-push 스킬 추가

팀에서 사용하는 방법

사용 시 이점

활용 방법

피보팅이 될 때

4. 사용하고 느낀 점 및 앞으로의 계획

느낀 점

앞으로의 계획

5. Tl;DR

6. 참고 자료

[Claude Code] Claude Code 프롬프트 캐싱 정리

1. 캐시 구성 요소

Prefix (text 기반)

Header (Request metadata)

Appended requests

Cache-Hit 조건

**Tip

캐시가 있는 위치

2. 캐시를 무효화하는 작업 — "Cache Key가 바뀔 때"

① 모델 전환

② Effort level 변경

③ Fast Mode 켜기

④ disconnect된 MCP Server 연결

⑤ Plugin (비)활성화

⑥ 기본 Tool을 '거부 규칙'에 추가

⑦ Compact

Compact Tip

⑧ Claude 업데이트

3. 캐시를 유지하는 작업

① repo의 file 편집

② 세션 중 CLAUDE.md 편집

③ 출력 스타일 변경

④ 권한 모드 변경

⑤ Skill / Command 호출

⑥ /recap 실행

⑦ /rewind 실행

3. 캐시 수명 (Cache Lifetime)

OAuth Subscription

API key or third-party provider

Override the TTL

4. 캐시 범위

5. 캐시 성능 확인

OpenTelemetry(OTel)

6. 서브에이전트 및 캐시

Fork

7. 프롬프트 캐싱 비활성화

출처

[AX] AI Agent 기초

1. LLM 이해

2. RAG

3. LLM vs Agent

4. Desktop App vs CLI

5. Skills

6. Hooks

7. Workflow = Skills x Hooks

1) `Agent`

2) `Artifact`

3) `AskUserQuestion`

`wiki-ingest-and-push` 스킬 추가

② 세션 중 `CLAUDE.md` 편집

⑥ `/recap` 실행

⑦ `/rewind` 실행