Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?
Jaeyeol Lee
@kodingwarrior@hackers.pub · 694 following · 508 followers
Neovim Super villain. 풀스택 엔지니어 내지는 프로덕트 엔지니어라고 스스로를 소개하지만 사실상 잡부를 담당하는 사람. CLI 도구를 만드는 것에 관심이 많습니다.
Hackers' Pub에서는 자발적으로 바이럴을 담당하고 있는 사람. Hackers' Pub의 무궁무진한 발전 가능성을 믿습니다.
그 외에도 개발자 커뮤니티 생태계에 다양한 시도들을 합니다. 지금은 https://vim.kr / https://fedidev.kr 디스코드 운영 중
Blog
- kodingwarrior.github.io
mastodon
- @kodingwarrior@silicon.moe
Github
- @malkoG
Jaeyeol Lee shared the below article:
Claude Code의 거의 모든 것은 Tool Use 입니다. MCP도 subagent도 Skills 역시요.
자손킴 @jasonkim@hackers.pub
이번 글에서는 지난글에 이어서 Claude가 도구를 사용하는 구체적인 방법을 알아본다. Claude가 사용할 수 있는 도구들의 목록은 Tools 섹션에 포함되어 있다. Tools 섹션에 대해서는 이전 글을 참고한다.
Tool Use 란?
Tool Use는 Claude가 외부 도구(함수)를 호출하여 실제 작업을 수행할 수 있게 하는 메커니즘이다. Claude는 텍스트 생성만으로는 수행할 수 없는 작업들, 예를 들어 파일 읽기, 명령어 실행, 웹 검색 등을 도구를 통해 수행한다.
Claude에게 사용 가능한 도구들의 스키마를 알려주면 Claude는 사용자의 요청을 분석하여 적절한 도구를 선택하고 필요한 파라미터와 함께 도구 사용을 요청한다. 에이전트(클라이언트)는 이 요청을 받아 실제로 도구를 실행하고 그 결과를 다시 Claude에게 전달한다.
Tools 섹션: 도구 정의하기
Claude가 도구를 사용하려면 먼저 어떤 도구가 있는지 알아야 한다. 에이전트는 API 요청의 tools 배열에 사용 가능한 도구들을 정의한다. 각 도구는 이름, 설명, 그리고 입력 스키마를 포함한다.
Bash 도구 정의 예시
{
"name": "Bash",
"description": "Executes a given bash command in a persistent shell session with optional timeout, ensuring proper handling and security measures.\n\nIMPORTANT: This tool is for terminal operations like git, npm, docker, etc...",
"input_schema": {
"type": "object",
"properties": {
"command": {
"type": "string",
"description": "The command to execute"
},
"timeout": {
"type": "number",
"description": "Optional timeout in milliseconds (max 600000)"
},
"description": {
"type": "string",
"description": "Clear, concise description of what this command does in 5-10 words, in active voice."
}
},
"required": ["command"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
Glob 도구 정의 예시
{
"name": "Glob",
"description": "- Fast file pattern matching tool that works with any codebase size\n- Supports glob patterns like \"**/*.js\" or \"src/**/*.ts\"\n- Returns matching file paths sorted by modification time\n- Use this tool when you need to find files by name patterns",
"input_schema": {
"type": "object",
"properties": {
"pattern": {
"type": "string",
"description": "The glob pattern to match files against"
},
"path": {
"type": "string",
"description": "The directory to search in. If not specified, the current working directory will be used."
}
},
"required": ["pattern"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
도구 정의에서 description이 중요하다. Claude는 이 설명을 읽고 어떤 상황에서 해당 도구를 사용해야 하는지 판단한다. input_schema는 JSON Schema 형식으로 Claude가 도구를 호출할 때 어떤 파라미터를 어떤 형식으로 전달해야 하는지 정의한다.
Claude가 도구를 선정하는 방법
Claude가 도구를 선택하는 과정은 Messages API의 대화 흐름 속에서 이루어진다. 실제 예시를 통해 살펴보자.
사용자의 요청
사용자가 "이 NestJS 프로젝트에서 entity 구조를 탐색해주세요"라고 요청하면 에이전트는 다음과 같은 메시지를 API에 전송한다:
{
"role": "user",
"content": [
{
"type": "text",
"text": "이 NestJS TypeScript 프로젝트에서 entity 구조를 탐색해주세요..."
}
]
}
Claude의 도구 사용 요청
Claude는 사용자의 요청을 분석하고 작업 수행에 필요한 도구들을 선택하여 tool_use 블록으로 응답한다:
{
"role": "assistant",
"content": [
{
"type": "text",
"text": "이 NestJS 프로젝트의 entity 구조를 철저하게 탐색하겠습니다."
},
{
"type": "tool_use",
"id": "toolu_01ABC123XYZ",
"name": "Glob",
"input": {
"pattern": "**/*.entity.ts"
}
},
{
"type": "tool_use",
"id": "toolu_01DEF456UVW",
"name": "Bash",
"input": {
"command": "find /workspace/my-nestjs-project/src -type f -name \"*.ts\" | grep -E \"(entity|entities)\" | head -20",
"description": "Find entity files in src directory"
}
}
]
}
여기서 주목할 점이 있다. Claude는 한 번의 응답에서 여러 도구를 동시에 요청할 수 있다. 위 예시에서는 Glob과 Bash 두 도구를 병렬로 요청했다. 각 도구 요청에는 고유한 id가 부여되어 나중에 결과를 매핑할 때 사용된다.
응답의 stop_reason
Claude가 도구 사용을 요청하면 API 응답의 stop_reason이 "tool_use"로 설정된다:
{
"id": "msg_01XYZ789ABC",
"type": "message",
"role": "assistant",
"model": "claude-haiku-4-5-20251001",
"content": [...],
"stop_reason": "tool_use",
"usage": {
"input_tokens": 714,
"output_tokens": 314
}
}
이 stop_reason은 에이전트에게 "응답이 끝난 것이 아니라 도구 실행이 필요하다"는 신호를 보낸다.
에이전트는 tool_use 요청을 받으면 무엇을 하는가?
에이전트(클라이언트)가 stop_reason: "tool_use" 응답을 받으면 다음 단계를 수행해야 한다:
-
도구 요청 파싱: 응답의
content배열에서type: "tool_use"블록들을 추출한다. -
도구 실행: 각 도구 요청에 대해 실제 도구를 실행한다. 예를 들어:
Bash도구 → 시스템에서 실제 bash 명령어 실행Glob도구 → 파일 시스템에서 패턴 매칭 수행Read도구 → 파일 내용 읽기
-
결과 수집: 각 도구의 실행 결과를 수집하고
tool_use_id와 함께 결과를 구성한다. -
모델에 결과 전달: 수집한 결과를
tool_result형식으로 모델에 다시 전송한다.
이 과정에서 에이전트는 도구 실행의 성공/실패 여부, 타임아웃 처리, 보안 검증 등을 담당한다. Claude는 도구의 스키마와 용도만 알 뿐 실제 실행은 에이전트의 몫이다.
에이전트가 모델에 도구 실행 결과를 알리는 방법
에이전트가 도구를 실행한 후에는 그 결과를 tool_result 형식으로 모델에 전달한다. 이 결과는 user role의 메시지로 전송된다.
tool_result 구조
{
"role": "user",
"content": [
{
"tool_use_id": "toolu_01DEF456UVW",
"type": "tool_result",
"content": "/workspace/my-nestjs-project/src/modules/chat/entities/dm-unlock.entity.ts\n/workspace/my-nestjs-project/src/modules/agora/entities/call-session.entity.ts\n/workspace/my-nestjs-project/src/modules/user/entities/user.entity.ts\n/workspace/my-nestjs-project/src/modules/user/entities/user-profile.entity.ts\n/workspace/my-nestjs-project/src/modules/item/entities/item.entity.ts\n...",
"is_error": false
},
{
"tool_use_id": "toolu_01ABC123XYZ",
"type": "tool_result",
"content": "/workspace/my-nestjs-project/src/modules/agora/entities/agora-event-log.entity.ts\n/workspace/my-nestjs-project/src/modules/agora/entities/call-participant.entity.ts\n/workspace/my-nestjs-project/src/modules/item/entities/item.entity.ts\n...",
"cache_control": {
"type": "ephemeral"
}
}
]
}
각 tool_result의 핵심 필드는 다음과 같다:
| 필드 | 설명 |
|---|---|
tool_use_id |
Claude가 요청한 도구의 고유 ID. 어떤 요청에 대한 결과인지 매핑 |
type |
항상 "tool_result" |
content |
도구 실행의 실제 결과 (문자열) |
is_error |
도구 실행 실패 시 true |
cache_control |
(선택) 프롬프트 캐싱을 위한 제어 옵션 |
전체 대화 흐름
tool_result를 받은 Claude는 결과를 분석하고 추가 도구가 필요하면 다시 tool_use를 요청한다. 충분한 정보가 모이면 최종 응답을 생성한다. 이 과정이 반복되면서 복잡한 작업도 단계별로 수행할 수 있다:
User → Claude: "entity 구조를 탐색해주세요"
Claude → Agent: tool_use (Glob, Bash)
Agent → Claude: tool_result (파일 목록)
Claude → Agent: tool_use (Read - 여러 파일)
Agent → Claude: tool_result (파일 내용들)
Claude → User: 최종 분석 결과
실제 예시에서 Claude는 먼저 Glob과 Bash로 entity 파일 목록을 찾고 그 결과를 받은 후 Read 도구로 개별 파일들을 읽어 분석했다:
{
"type": "text",
"text": "좋습니다. 이제 주요 entity 파일들을 읽겠습니다."
},
{
"type": "tool_use",
"id": "toolu_01GHI789RST",
"name": "Read",
"input": {
"file_path": "/workspace/my-nestjs-project/src/modules/user/entities/user.entity.ts"
}
},
{
"type": "tool_use",
"id": "toolu_01JKL012MNO",
"name": "Read",
"input": {
"file_path": "/workspace/my-nestjs-project/src/modules/user/entities/user-profile.entity.ts"
}
}
마무리
Claude Code와 같은 에이전트는 모델에 사용할 수 있는 도구를 알려주어 도구를 능동적으로 사용하게 만듦으로써 유저의 실행환경과 상호 협력하여 도구를 실행한다. 유저에게 질문을 하는 AskUserQuestion도 도구이고 심지어 계획 모드를 빠져나가는 ExitPlanMode도 도구다.
MCP(Model Context Protocol) 서버가 제공하는 기능들도 결국 도구로 노출되며 Subagent 호출도 도구를 통해 이루어진다. Skills도 마찬가지다. 결국 Claude Code의 거의 모든 확장 기능은 Tool Use라는 하나의 메커니즘 위에서 동작한다.
이 구조를 이해하면 Claude Code가 어떻게 파일을 읽고, 코드를 실행하고, 웹을 검색하는지 명확해진다. 그리고 새로운 도구를 추가하거나 MCP 서버를 연동할 때도 같은 패턴이 적용된다는 것을 알 수 있다.
Jaeyeol Lee shared the below article:
Claude API의 Request Body 분석
자손킴 @jasonkim@hackers.pub
Claude API의 Request는 크게 4가지 분류를 가지고 있다.
- System Messages
- Messages
- Tools
- Model & Config
각각은 다음과 같은 역할을 한다.
System Messages
System Messages는 Claude에게 역할, 성격, 제약사항 등을 지시하는 최상위 설정이다. 배열 형태로 여러 개의 시스템 메시지를 전달할 수 있다.
"system": [
{
"type": "text",
"text": "You are Claude Code, Anthropic's official CLI for Claude.",
"cache_control": {
"type": "ephemeral"
}
},
{
"type": "text",
"text": "You are an interactive CLI tool that helps users with software engineering tasks...",
"cache_control": {
"type": "ephemeral"
}
}
]
System Messages에는 다음과 같은 내용이 포함된다:
- Claude의 페르소나 및 역할 정의
- 보안 및 윤리 가이드라인
- 응답 형식 및 톤 설정
- 프로젝트 정보 등 컨텍스트
cache_control을 통한 캐싱 설정
Messages
Messages는 user와 assistant 역할이 번갈아가며 주고받은 대화를 누적하는 배열이다. assistant 메시지는 반드시 모델의 실제 응답일 필요가 없다. 이를 활요해 API 호출 시 assistant 메시지를 미리 작성해서 전달하면, Claude는 그 내용 이후부터 이어서 응답한다. 이를 Prefill 기법이라 한다.
이 대화 기록을 통해 Claude는 맥락을 유지하며 응답한다.
"messages": [
{
"role": "user",
"content": [...]
},
{
"role": "assistant",
"content": [...]
},
{
"role": "user",
"content": [...]
}
]
User Message
User의 content는 주로 두 가지 type으로 구성된다:
1. text - 사용자의 일반 메시지나 시스템 리마인더
{
"role": "user",
"content": [
{
"type": "text",
"text": "선물을 주고받는 기능을 위한 entity를 설계하라."
}
]
}
2. tool_result - Tool 실행 결과 반환
{
"role": "user",
"content": [
{
"tool_use_id": "toolu_01Qj7gnFLKWBNjg",
"type": "tool_result",
"content": [
{
"type": "text",
"text": "## Entity 구조 탐색 보고서\n\n철저한 탐색을 통해..."
}
]
}
]
}
Assistant Message
Assistant의 content는 주로 세 가지 type으로 구성된다:
1. text - Claude의 응답 메시지
{
"type": "text",
"text": "선물 주고받기 기능을 위한 entity 설계를 시작하겠습니다."
}
2. thinking - Extended Thinking 기능 활성화 시 사고 과정 (signature로 검증)
{
"type": "thinking",
"thinking": "사용자가 선물을 주고받는 기능을 위한 entity 설계를 요청했습니다...",
"signature": "EqskYIChgCKknyFYp5cu1zhVOp7kFTJb..."
}
3. tool_use - Tool 호출 요청
{
"type": "tool_use",
"id": "toolu_01Qj7gn6vLKCNjg",
"name": "Task",
"input": {
"subagent_type": "Explore",
"prompt": "이 NestJS TypeScript 프로젝트에서 entity 구조를 탐색해주세요...",
"description": "Entity 구조 탐색"
}
}
User와 Assistant의 협력
Tool 사용 흐름은 다음과 같이 진행된다:
- Assistant:
tool_use로 Tool 호출 요청 - User:
tool_result로 실행 결과 반환 - Assistant: 결과를 바탕으로
text응답 또는 추가tool_use
이 과정에서 어떤 Tool을 사용할 수 있는지는 tools 배열이 정의한다.
Tools
Tools는 Claude가 사용할 수 있는 도구들을 정의하는 배열이다. 각 Tool은 name, description, input_schema 세 가지 필드로 구성된다.
Tool의 기본 구조
"tools": [
{
"name": "ToolName",
"description": "Tool에 대한 설명...",
"input_schema": {
"type": "object",
"properties": {...},
"required": [...],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
]
| 필드 | 설명 |
|---|---|
name |
Tool의 고유 식별자. Claude가 tool_use에서 이 이름으로 호출 |
description |
Tool의 용도, 사용법, 주의사항 등을 상세히 기술. Claude가 어떤 Tool을 선택할지 판단하는 근거 |
input_schema |
JSON Schema 형식으로 입력 파라미터 정의 |
input_schema 구조
input_schema는 JSON Schema draft-07 스펙을 따르며, Tool 호출 시 필요한 파라미터를 정의한다.
"input_schema": {
"type": "object",
"properties": {
"pattern": {
"type": "string",
"description": "The regular expression pattern to search for"
},
"path": {
"type": "string",
"description": "File or directory to search in. Defaults to current working directory."
},
"output_mode": {
"type": "string",
"enum": ["content", "files_with_matches", "count"],
"description": "Output mode: 'content' shows matching lines, 'files_with_matches' shows file paths..."
},
"-i": {
"type": "boolean",
"description": "Case insensitive search"
},
"head_limit": {
"type": "number",
"description": "Limit output to first N lines/entries"
}
},
"required": ["pattern"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
properties 내 각 파라미터 정의
각 파라미터는 다음 필드들로 정의된다:
| 필드 | 설명 |
|---|---|
type |
데이터 타입 (string, number, boolean, array, object 등) |
description |
파라미터의 용도와 사용법 설명 |
enum |
(선택) 허용되는 값의 목록. 이 중 하나만 선택 가능 |
default |
(선택) 기본값 |
input_schema의 메타 필드
| 필드 | 설명 |
|---|---|
type |
항상 "object" |
properties |
파라미터 정의 객체 |
required |
필수 파라미터 이름 배열. 여기 포함되지 않은 파라미터는 선택적 |
additionalProperties |
false면 정의되지 않은 파라미터 전달 불가 |
$schema |
JSON Schema 버전 명시 |
실제 예시: Grep Tool
{
"name": "Grep",
"description": "A powerful search tool built on ripgrep\n\n Usage:\n - ALWAYS use Grep for search tasks...",
"input_schema": {
"type": "object",
"properties": {
"pattern": {
"type": "string",
"description": "The regular expression pattern to search for in file contents"
},
"path": {
"type": "string",
"description": "File or directory to search in (rg PATH). Defaults to current working directory."
},
"glob": {
"type": "string",
"description": "Glob pattern to filter files (e.g. \"*.js\", \"*.{ts,tsx}\")"
},
"output_mode": {
"type": "string",
"enum": ["content", "files_with_matches", "count"],
"description": "Output mode. Defaults to 'files_with_matches'."
},
"-A": {
"type": "number",
"description": "Number of lines to show after each match"
},
"-B": {
"type": "number",
"description": "Number of lines to show before each match"
},
"-i": {
"type": "boolean",
"description": "Case insensitive search"
},
"multiline": {
"type": "boolean",
"description": "Enable multiline mode. Default: false."
}
},
"required": ["pattern"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}
이 Tool을 Claude가 호출할 때의 tool_use:
{
"type": "tool_use",
"id": "toolu_01ABC123",
"name": "Grep",
"input": {
"pattern": "class.*Entity",
"path": "src/modules",
"glob": "*.ts",
"output_mode": "content",
"-i": true
}
}
required에 pattern만 있으므로 나머지는 선택적이다. Claude는 input_schema의 description을 참고하여 적절한 파라미터를 선택한다.
Model & Config
마지막으로 모델 선택과 각종 설정 옵션들이다:
{
"model": "claude-opus-4-5-20251101",
"max_tokens": 32000,
"thinking": {
"budget_tokens": 31999,
"type": "enabled"
},
"stream": true,
"metadata": {
"user_id": "user_2f2ce5dbb94ac27c8da0d0b28dddf815fc82be54e0..."
}
}
| 옵션 | 설명 |
|---|---|
model |
사용할 Claude 모델 (claude-opus-4-5, claude-sonnet-4-5 등) |
max_tokens |
최대 출력 토큰 수 |
thinking |
Extended Thinking 설정 (budget_tokens로 사고 토큰 예산 설정) |
stream |
스트리밍 응답 여부 |
metadata |
사용자 ID 등 메타데이터 |
마치며
지금까지 Claude API Request Body의 4가지 핵심 구성 요소를 살펴보았다:
- System Messages: Claude의 역할과 행동 방식을 정의
- Messages: user-assistant 간 대화 기록을 누적하며, tool_use/tool_result를 통해 Tool과 상호작용
- Tools: JSON Schema 기반으로 사용 가능한 도구의 이름, 설명, 입력 파라미터를 정의
- Model & Config: 모델 선택, 토큰 제한, 스트리밍 등 설정
이 구조를 알면 Claude가 주고받은 메시지를 어떻게 관리하는지, 도구를 어떻게 사용하는지 이해하고 API를 더 효과적으로 활용할 수 있다.
LLMs are good at coding. They can code faster than human. But they don't have ability to maintain their shit. Don't worry developers, there will be tons of shit codes we need to clean up in future. Surely we won't loose our job. Actually there will be more works than ever.
오늘 모집 마감.................
https://github.com/yamadashy/repomix/releases/tag/v1.10.0
Repomix가 소스코드를 압축해서 LLM 친화적인 텍스트를 뽑아주는 CLI도구인데, 이제 그걸 넘어서 Claude Code Skill도 뽑아주는 기능이 추가되었다 .....
이거 solid 같은 청개구리 스택 전용으로도 괜찮아보이지 않을까(?)
https://github.com/yamadashy/repomix/releases/tag/v1.10.0
Repomix가 소스코드를 압축해서 LLM 친화적인 텍스트를 뽑아주는 CLI도구인데, 이제 그걸 넘어서 Claude Code Skill도 뽑아주는 기능이 추가되었다 .....
https://github.com/yamadashy/repomix/releases/tag/v1.10.0
Repomix가 소스코드를 압축해서 LLM 친화적인 텍스트를 뽑아주는 CLI도구인데, 이제 그걸 넘어서 Claude Code Skill도 뽑아주는 기능이 추가되었다 .....
역시 LLM 사용은 뉘집소가 더 잘하는지 경쟁을 시키는게 마음이 편하다.... 디펜던시 그래프를 Mermaid로 그리게하는건 확실히 Claude보다는 ChatGPT가 더 잘하는 듯.
아니다, 내가 비교군을 잘못 선택했다. Opus가 제일 잘한다
역시 LLM 사용은 뉘집소가 더 잘하는지 경쟁을 시키는게 마음이 편하다.... 디펜던시 그래프를 Mermaid로 그리게하는건 확실히 Claude보다는 ChatGPT가 더 잘하는 듯.
https://github.com/yctimlin/mcp_excalidraw DAG 그려서 뭔가를 설명해야하는 일이 있어서 Excalidraw 알아보고 있었는데, 이것도 MCP가 있었다..... 완전 짱이다...
진짜 국내 커뮤니티가 LLM에 친화적이긴 한 것 같은데, 사용하는 팁이 너무 파편화되어있어서 내가 원하는 활용법을 찾기가 어렵다
사실 이래서 나는 커밋 메시지로부터 어떻게든 체인지로그를 자동으로 생성해 내려는 일체의 시도에 회의적임…
@hongminhee洪 民憙 (Hong Minhee) 커밋메시지를 하나하나 읽으라는 소리인지.... TLDR 만들어주는 성의가 없네요 😂
식탁보 1.14.0에서 오랫만에 업데이트를 진행하면서, 생성형 AI의 도움을 받아 적극적인 현대화를 달성하고 있습니다.
-
InnoSetup 대신 Velopack을 사용한 간소화된 사용자 인스톨러 경험 구현
-
MSBUILD 프로젝트 대신 .NET SDK로 .NET Framework 프로젝트 마이그레이션 (추후 완전히 .NET 10과 Avalonia로도 전환할 수 있게 함)
-
TableCloth 프로젝트의 경우 .NET 8/9에서 .NET 10으로 판올림
-
Windows 11 ARM64 GitHub Action Runner가 공식화됨에 따라 ARM64 빌드 추가 예정
내부 정비가 끝나는 대로 식탁보 1.15.0 버전을 출시하도록 하겠습니다. 또한 생성형 AI 코드 어시스턴트의 도움을 적극 받아 1인 개발에서 오는 한계를 극복해보려 합니다.
최신 소스 커밋 목록은 https://github.com/yourtablecloth/TableCloth/commits/main/ 에서 확인하실 수 있습니다.
진심모드로 구조적이면서 맥락을 잘 명시해서 커뮤니케이션하면 프롬프트가 꽤 잘 먹히는데, 이건 사람과 대화할때도 마찬가지인 것 같다. 그냥 사람에게 진심박치기 모드로 뇌에 힘주고 커뮤니케이션하는걸 생활화한다 생각하고 프롬프트를 먹이는 의식적인 훈련이 필요할 것 같다.
Hackers Pub 송년회 라이트닝토크에서 발표 안하려고 했는데? 뭔가 소소하게 공유할꺼리가 생겼다. 그리고.......... Hackers Pub에서 LLM 활용하는 방법 굉장히 과한 밀도로 공유하게 될 것 같다.... 당장 내가 일하는 회사도 LLM을 엄청 적극적으로 활용하고 있기도 하고, 그걸로 사업하는 회사여서 더욱 가속도가 붙는 것도 있는 듯.
https://github.com/einverne/dotfiles/tree/b2002cdb1594eef95f92d8be526f5e3de55c70f6/claude/skills
.claude/skills 로 관리할 수 있다길래, 어? 설마? 하고 봤는데 진짜로 dotfiles로 관리하는 사람이 좀 보이는 것 같다. Claude Code에서도 갖다쓸 수 있는거보면 분명 가능성은 많이 보인다
예상은 했지만, 남들이 다 먹기 전에 선빵을 치고 이득봐야겠다....
https://github.com/ComposioHQ/awesome-claude-skills/tree/master/skill-creator
Claude Skill 기능을 적극적으로 활용해보려고 하는데, skill을 만들 수 있도록 돕는 skill-creator라는게 있다. 이걸 좀 더 참고해서 어떻게 나한테 쓸만한걸 만들 수 있는지 한번 살펴봐야겠다.
https://github.com/einverne/dotfiles/tree/b2002cdb1594eef95f92d8be526f5e3de55c70f6/claude/skills
.claude/skills 로 관리할 수 있다길래, 어? 설마? 하고 봤는데 진짜로 dotfiles로 관리하는 사람이 좀 보이는 것 같다. Claude Code에서도 갖다쓸 수 있는거보면 분명 가능성은 많이 보인다
예상은 했지만, 남들이 다 먹기 전에 선빵을 치고 이득봐야겠다....
https://github.com/ComposioHQ/awesome-claude-skills/tree/master/skill-creator
Claude Skill 기능을 적극적으로 활용해보려고 하는데, skill을 만들 수 있도록 돕는 skill-creator라는게 있다. 이걸 좀 더 참고해서 어떻게 나한테 쓸만한걸 만들 수 있는지 한번 살펴봐야겠다.
앗! 해커스펍! 코드스니펫 공유하는게 GitHub Gist보다 편하다!!!
# 요런 식으로
def greeting(word: str) -> None:
print(f"hello {word}")
greeting("world")
At last, I finished reading Chapter 7 of "Theorem Proving in Lean 4" in Korean by explaining how to use three tactics: cases, induction, and injection. https://youtu.be/N-ELdwO-vN4?si=kfemVPbbNP-Gf0m8
Claude Desktop 프로젝트 파놓고, 시스템 프롬프트를 이렇게 먹이고 있음. MCP 서버도 붙였는데, 그럭저럭 동작은 잘하는듯?
이 프로젝트는 일지를 작성하면서 실시간으로 대화를 주고 받기 위해 만들었습니다.
즉, 다음과 같은 내용들이 포함됩니다.
1. 오늘 한 일들을 실시간으로 기록
2. 일을 하면서 어떤 문제를 접했고, 어떤 방식으로 해결하려고 했는지 기록
3. 갑자기 떠오른 궁금증과 관련해서 궁금한 사항들을 질의/응답
## 역할에 대해
LLM 에이전트로서 당신은 아래와 같은 역할을 해야 합니다.
1. 빅테크 출신 멘토로서의 에이전트
- 최종적으로는 빅테크에서 일하는 것을 지향하고, 빅테크에서 어떤 방식으로 일하는지 체감하고 싶습니다. 엄밀하게는 숙련된 시니어 개발자로서 좋은 습관을 가질 수 있는 환경을 가지는 것을 지향합니다.
- 큰 규모의 기업에서 노련한 경험이 있는 스태프 엔지니어 출신으로서 저에게 조언을 많이 해줄 수 있기를 바랍니다.
2. 개인 비서로서의 에이전트
- 앞으로도 업무 일지를 쓰게 될 일이 많을 것 같습니다. 업무에 대한 이해를 위한 질문 답변을 정리하고, 업무를 하다가 어떤 사고의 흐름을 가지고 일을 했는지 기록을 하게 될 것입니다. 생각을 정리하는 비서로서 역할을 해주기를 기대합니다.
3. 개인 위키의 지식관리자로서의 에이전트
- 지식을 체계적으로 관리하는 에이전트로서 역할을 해주기를 바라고 있습니다. 즉, 뒤에서 또 언급할 xxx-wiki에 흩어진 정보들을 취합하면서도 기록을 체계적으로 관리하는 역할도 수행해주셔야 합니다.
- 내가 새로 알게 되거나 혹은 알고 싶어 하는 내용이 있다면, 해당 내용에 대해서 명료하고 여러가지 예시들을 포함해서 설명해주세요. 그리고, 각각의 설명에는 출처를 반드시 명시해주셨으면 좋겠습니다.
## MCP 활용에 대해
LLM 에이전트를 활용하는데 있어서 아래와 같은 도구들을 적극적으로 사용해보는 것을 검토해보세요.
- Local Search : 업무 일지나 지식 관리는 Obsidian을 활용합니다. 그리고 Obsidian Vault는 ~/xxx-wiki (즉, /Users/yyy/xxx-wiki)를 적극적으로 활용하고 있습니다.
- Linear : 저는 업무용 이슈트래커로 Linear를 적극적으로 활용하고 있습니다. 어떤 업무가 있는지, 나에게 어떤 업무가 할당되어 있는지 조회하고 싶다면 Linear 툴 호출을 고려해보세요.
- Repomix : 소스코드 전반적인 이해, 그리고 프롬프트를 생성해내기 위한 보조도구로서 Repomix를 활용하고 있습니다. 외부 오픈소스에 대해 리서치를 하거나, 현재 프로젝트에 대한 맥락을 파악하고 싶을때 repomix를 쓰는 것도 적절한 방법일 수 있습니다.
개인 기록 관리를 obsidian으로 옮겨볼까...... 아니면 그냥 개인기록 관리(neovim zettelkasten 플러그인)를 그대로 유지하되, mcp 서버를 직접 만드는걸 해볼까... 어느 쪽이든 할만한 도전인 것 같음
고심끝에 그냥 Obsidian 쓰기로 함. 마크다운 에디터로서 가독성이 좋기도 하고, Vim 키맵도 지원되고, MCP도 비벼볼 수 있고, 여러모로 해볼 수 있는게 많음.
개인 기록 관리를 obsidian으로 옮겨볼까...... 아니면 그냥 개인기록 관리(neovim zettelkasten 플러그인)를 그대로 유지하되, mcp 서버를 직접 만드는걸 해볼까... 어느 쪽이든 할만한 도전인 것 같음
@kodingwarriorJaeyeol Lee 제가 프론트도 스토리북 + 테스트 붙이고 이사 가는 거 해보면 어떨까 싶어서 쫌쫌 실험을 해보았는데. 방송대 기말고사 끝나면 PR을 올려보려고요.
@stelo_kim김태희 (탐정토끼) 너무,, 감사합니다,,,
내가 느끼는 가장 큰 #cosmoslide 의 진입장벽이라면 activitypub 관련 코드랑 비즈니스 로직이랑 완전히 커플링되어 있는 것도 좀 큰 것 같은데, 어떻게 계층을 분리할 수 있을지 고민임.
Misskey도 계층이 잘 분리가 되어있어서 군데군데 테스트가 적당히 짜여져 있는데.... 당장은 OpenAI Codex/Claude Code on Web으로 짜도 기여할 수 있을 정도로 구조를 잘 다듬긴 해야겠다는것
(부슽)
%s가~ 좋아하는~ 랜덤~ 계엄~
무슨~ 계엄~
계엄~ 스타트~
큰 범주에서의 WIP를 최대한 줄여야 하는데.....
회사일이랑 cosmosli.de 정도로만 딱 줄이고 싶음. 커뮤니티 쪽은? 그냥 뭐 하면 하는거고...
큰 범주에서의 WIP를 최대한 줄여야 하는데.....
이제 브라우저 스터디 슬슬 진도나가야지
LLM과 함께하는 힐링개발
@minsoo 안녕하세요! 반갑습니다!
12月 6日 서울에서 開催되는 liftIO 2025에서 〈Optique: TypeScript에서 CLI 파서 컴비네이터를 만들어 보았다〉(假題)라는 主題로 發表를 하게 되었습니다. 아직 liftIO 2025 티켓은 팔고 있으니, 函數型 프로그래밍에 關心 있으신 분들의 많은 參與 바랍니다!
오늘 liftIO 2025에서 發表한 〈Optique: TypeScript의 타입 推論으로 CLI 有效性 檢査를 代替하기〉의 發表 資料를 共有합니다! 들어주신 모든 분들께 感謝 드립니다.
오, PPT를 canva로도 깎을 수 있군아
SolidJS로 앱 만들다가 아이콘셋이 필요해져서 패키지를 뒤져보는데, 마이너 생태계답게 마지막 업데이트가 삼사년 전인 패키지들만 나온다. 아이콘셋에 업데이트가 필요 없긴 하지. 그래도 최근에 업데이트 된 패키지가 걸리적거리는게 없을 것 같달까. 그러다 활발히 업데이트 중인 unplugin-icons를 찾았다. 이것은 SolidJS용 패키지가 아니었다. 아이콘셋도 아니었다. 거의 모든 아이콘셋을 거의 모든 프레임워크에서 사용할 수 있게 해주는 도구다. 이런 문물이 있었다니. 누가 만들었나 함 보자. 제작자는 Anthony Fu... 아아 또 그인가. 오늘도 비 React 웹 생태계엔 Anthony Fu의 은혜가 넘친다.
여기에 뒤늦게 올리지만 2차 모집도 진행중입니다! 이번엔 12월 15일(월)까지....!!
@kodingwarriorJaeyeol Lee 님, SNS등에서 사이트 공유할 때 나오게 하는 vim.kr의 메타 이미지 지정이 잘못되어 있는 것 같은데요. 저거 프레임워크 로고 아닌가요?
@lionhairdino 아.......... 왜 openai 가 나오지 ㅋㅋㅋ
```
반대로, 중요한 아키텍처 결정을 내리거나 복잡한 이해관계자 요구사항을 해석하거나 새로운 알고리즘을 설계해야 하는 작업은 AI 지원을 받는 인간 주도 개발에 더 적합합니다. 핵심은 큰 작업의 어떤 측면을 에이전트에게 효과적으로 위임할 수 있고 어떤 부분이 인간의 판단과 창의성을 필요로 하는지 인식하는 데 있습니다
```
결국 중요한 순간에는 사람의 개입이 필요하다...
아카이브 쌓아만두고 후기를 안 적었네.... 일 생각만 하느라 후기 작성도 미루게 되는 느낌이 없지는 않지만, 암튼 후기를 남기자면......
내가 딱 바이브코딩에 대해 가지고 있던 생각들이 책을 통해서 재확인받는 것 같은 느낌이 든다. 바이브코딩이 확실히 개발 진입장벽을 낮춰주기도 하고, 생산성에 부스트를 달아주는 편이라고는 하지만, 최종적으로는 사람이 책임져야한다는 입장이긴 했었다.
뭔가를 빨리 만들고, 그럴싸한 제품을 만들었다고 치자. 근데, 그런 제품을 누가 써? 그렇게 만들어서 어떤 비즈니스 임팩트가 있어? 품질은 누가 책임져? 라는 생각이 안들 수가 없는데 이런 관점에 대해서도 균형적인 시각을 주고 있다.
거듭해서 무작정 그냥 갖다쓰지말고 어떻게 동작하는지 명확히 이해하고 갖다쓰라고하는데 어떻게 보면 라이브러리/프레임워크 갖다 쓰는 것의 좀 더 고차원레벨의 관점에서 접근하는 것이라고도 볼 수 있을 것 같다.
나? 왜? 일 빨리 끝냄?
닷넷은 8.0이후로 Microsoft만이 아니라, Canonical, RedHat 등 각 리눅스 배포판 관리자들이 Microsoft를 대신하여 본인들의 배포판 OS에서 잘 작동할 수 있도록 검증 과정을 거쳐 독자적으로 빌드하여 패키징을 하고 있습니다.
그 덕분에 매우 유의미한 발전이 하나 있었는데, IBM 메인프레임 (s390x)과 IBM PowerPC (ppc64el)에서도 우분투 리눅스를 사용하면 이제 닷넷 10을 아주 손쉽게 apt install dotnet-sdk-10.0 명령어 하나로 바로 설치해서 쓸 수 있게 됩니다.
https://forum.dotnetdev.kr/t/ibm-s390x-ibm-powerpc-ppc64el-10/14096
어떻게 쓰는지도 모르겠었던 투명성보고서 써보니까 Claude Skills가 왜 좋은지 좀 실감한다... 문서 작업하는거 자동화하는거 관련해서는 사실상 python-docx, openpyxl, xlsxwriter, python-pptx, reportlab, PyMuPDF, pdfplumber 스크립팅하는거 wrapper 였을 뿐이었고...
We've got some updates on TypeScript 7! The new native port
- can type-check any project
- supports --build and --incremental
- has rich editor features implemented
- is still 10x faster
and is ready for you to try today!
https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/
일하면서 TeX를 쓰는 날이 오게될 줄은 몰랐어
@kodingwarriorJaeyeol Lee 양꼬치 맛도 생각해주시는거 아시죠?
돈 아득바득 모아서 PyConUS 간다는 각오로 열심히 초과근무를...!
시간 단위로 일을 한 만큼 돈을 받는거다 보니까, 이동할때도 어느 경로가 시간을 많이 아끼는지랑 "나가서 일하기 vs 집/동네에서 일하기" ROI 비용도 많이 생각하게 되는 듯
일하는 장소에 따라 생산성이 바뀌냐 안바뀌냐의 차이가 있을 것 같긴 한데, 일이 몰입이 되면 그것조차도 극복이 되는,,,!!!
JSConf JP 2025に参加しました!登壇とブース出展のレポート - Money Forward Developers Blog
https://moneyforward-dev.jp/entry/2025/12/01/jsconf-2025-participation-report








