name: make-skills description: Meta-skill for creating new Claude Code skills. Systematic approach to identify repeated workflows, extract patterns from conversation/git history, and create reusable skills. Use when noticing repeated debugging patterns, workflows that could be standardized, or when user asks to "make a skill" or "suggest skills". Works for any language/framework.

Make Skills - Meta-Skill for Creating New Claude Code Skills

Transform repeated workflows into reusable, production-ready skills using a systematic 3-model iterative approach.

🚀 Quick Reference Card

When to Create a Skill:
  ✅ Task repeated 3+ times
  ✅ Multi-step workflow that could be standardized
  ✅ Common bug pattern with known solution
  ✅ User says "we keep doing X"

3-Model Process:
  1. Haiku (30s): Quick 70% draft
  2. Sonnet (2m): Add real examples, 90% complete
  3. Opus (5m): Polish to 100% production-ready

Essential Commands:
  git log --all --grep="pattern" --oneline  # Find patterns
  grep -r "keyword" --include="*.{js,py,go}"  # Search code
  ls .claude/skills/  # Check existing skills

🎯 When to Use This Skill

# User triggers:
- "create a new skill for..."
- "make a skill based on..."
- "we keep doing X, let's make a skill"
- "look through history and suggest skills"

# Proactive triggers (suggest to user):
- Same debugging pattern appears 3+ times in git history
- User repeatedly asks for same type of help
- Complex multi-step workflow happens frequently

🔄 The 3-Model Iterative Approach

Based on successful code-review and state-fixer skill creation:

Model 1: Haiku (Speed Draft)

• Goal: Fast first draft with basic structure
• Time: ~30 seconds
• Output: Core workflow, simple examples
• Quality: 60-70% complete

Model 2: Sonnet (Enhancement)

• Goal: Add depth, real examples, better organization
• Time: ~2 minutes
• Output: Detailed examples from actual code, better formatting
• Quality: 85-90% complete

Model 3: Opus (Refinement)

• Goal: Polish, edge cases, production-ready
• Time: ~5 minutes
• Output: Comprehensive guide with real commit references
• Quality: 95-100% production-ready

📋 The 5-Step Skill Creation Process

Workflow Overview with Model Switches

Step 1: Pattern Mining
  Model: Any (Sonnet recommended)
  ↓
Step 2: Template Creation
  Model: Any (Sonnet recommended)
  ↓
🔄 SWITCH TO HAIKU
  ↓
Step 3: Quick Draft
  Model: Haiku (~30 seconds)
  Output: 70% complete skill
  ↓
🔄 SWITCH TO SONNET
  ↓
Step 4: Enhancement
  Model: Sonnet (~2 minutes)
  Output: 90% complete with real examples
  ↓
🔄 SWITCH TO OPUS
  ↓
Step 5: Production Polish
  Model: Opus (~5 minutes)
  Output: 100% production-ready skill
  ✅ DONE!

Detailed Steps

Step 1: Pattern Mining (Research Phase)

💡 Use current model (any model is fine for research)

Goal: Find repeated workflows in conversation and git history

Universal Pattern Discovery Commands:

# === Git History Mining ===
# Find repeated problem patterns
git log --all --oneline | grep -i "fix\|bug\|error\|issue" | head -30

# Search for specific domains
git log --all --grep="[KEYWORD]" --oneline  # Replace with: auth, api, state, etc

# Analyze recent work patterns
git log --oneline -50 | cut -d' ' -f2- | sort | uniq -c | sort -rn

# Find files changed together (coupling)
git log --all --name-only --format="" | sort | uniq -c | sort -rn | head -20

# === Codebase Pattern Analysis ===
# Language-agnostic searches
find . -type f -name "*.{js,ts,py,java,go,rb}" -exec grep -l "TODO\|FIXME\|HACK" {} \;

# Find error handling patterns
grep -r "catch\|except\|rescue\|error" --include="*.{js,ts,py,java,go,rb}" | head -20

# Find test patterns
find . -type f -name "*test*" -o -name "*spec*" | head -20

# === Conversation Pattern Mining ===
# Check existing skills
ls -la .claude/skills/
find .claude/skills -name "SKILL.md" -exec head -20 {} \;

# Recent conversation topics (if logs exist)
# Look for repeated questions, errors, workflows

Universal Questions to Ask User:

• "What workflows do you repeat most often?"
• "What types of bugs keep appearing?"
• "Which tasks take multiple iterations to get right?"
• "What do you wish was automated?"
• "What patterns do you see in your recent work?"

Pattern Categories to Look For:

1. Debugging Patterns
   - Specific bug types that recur (state, async, memory leaks)
   - Error patterns in logs
   - Common root causes

2. Development Workflows
   - Feature implementation → review → test cycles
   - Refactoring patterns
   - Migration/upgrade patterns

3. Testing Patterns
   - Test creation workflows
   - Validation sequences
   - Performance testing routines

4. Operations Patterns
   - Deployment workflows
   - Monitoring/debugging production issues
   - Configuration management

5. Code Quality Patterns
   - Review checklists
   - Performance optimization workflows
   - Security audit patterns

Step 2: Skill Template Creation

💡 Use current model (any model is fine for planning)

Goal: Decide on skill structure and content outline

Basic Structure:

---
name: skill-name
description: Short description with triggers
---

# Skill Name

Brief overview of what this skill does.

## 🎯 Quick Start
- When to use
- User triggers
- Proactive usage

## Common Patterns / Bug Checklist
- Pattern 1 with example
- Pattern 2 with example

## Step-by-Step Workflow
1. Step 1
2. Step 2
...

## Real Examples from Project
### Example 1: [Commit hash]
- Problem:
- Solution:
- Code:

## Testing / Verification
- How to test
- What to check

## Related Skills
- Other skills that complement this

Step 3: Haiku Draft (Fast Initial Version)

🔄 ACTION: Tell the user:

✋ PAUSE: Switch to Haiku model now

Run: /model haiku

Then ask me:
"Create a skill for [SKILL_NAME] based on these patterns:
[List 3-5 repeated patterns from Step 1]

Structure:
- Quick Start section
- Common patterns (3-5)
- Basic workflow (3-5 steps)
- 1-2 simple examples

Keep it concise, focus on the most common cases."

What Haiku is good at:

• Fast structure (~30 seconds)
• Simple examples
• Basic workflow steps
• Getting 70% done quickly

What to skip in Haiku:

• Detailed commit references
• Edge cases
• Complex examples
• Extensive documentation

When Haiku is done: Save the draft, then proceed to Step 4.

Step 4: Sonnet Enhancement (Add Depth)

🔄 ACTION: Tell the user:

✋ PAUSE: Switch to Sonnet model now

Run: /model sonnet

Then ask me:
"Enhance this skill with:
1. Real commit examples from git history (search: git log --all --grep='...')
2. Actual code snippets from the project
3. 'Before/After' comparisons from real bugs
4. Better organization and formatting
5. More detailed workflow steps

Read relevant files if needed to get accurate examples.
Base it on actual project code, not hypothetical examples.

Here's the Haiku draft to enhance:
[Paste the Haiku draft here]"

What Sonnet is good at:

• Reading codebase for real examples (~2 minutes)
• Finding actual commits with git log
• Detailed explanations
• Better organization
• Accurate code snippets

When Sonnet is done: Review the enhanced skill, then proceed to Step 5.

What Sonnet Adds - Real Examples:

### Before Sonnet (Haiku version):
"Fix array mutation bugs by creating copies before sorting"

### After Sonnet Enhancement:
#### 🔴 Array Mutation Bug (Found in 3 projects)
```javascript
// BEFORE (BUG - Mutates original array):
const key = generateKey(items.sort());  // ❌ Mutates 'items'
const filtered = items.filter(x => x > 0).sort();  // ❌ OK filter, bad sort

// AFTER (FIXED - Safe immutable operations):
const key = generateKey([...items].sort());  // ✅ Sorts copy
const filtered = [...items].filter(x => x > 0).sort();  // ✅ Full copy chain

// PATTERN: Always spread [...array] before mutating operations

Real Commit Examples Added:

• Links to actual commits showing the fix
• Performance metrics (before: 3 bugs/week, after: 0)
• Test cases that catch this pattern

Step 5: Opus Polish (Production Ready)

🔄 ACTION: Tell the user:

✋ PAUSE: Switch to Opus model now

Run: /model opus

Then ask me:
"Polish this skill to production quality:
1. Add edge cases and gotchas
2. Add troubleshooting section
3. Verify all commit hashes are correct
4. Add 'Related Skills' section
5. Add 'Anti-Patterns' (what NOT to do)
6. Ensure examples are complete and accurate
7. Add metrics/success criteria
8. Review for consistency and completeness

Make this the definitive guide for this workflow.

Here's the Sonnet-enhanced version to polish:
[Paste the Sonnet version here]"

What Opus is good at:

• Comprehensive edge cases (~5 minutes)
• Troubleshooting guides
• Quality assurance
• Completeness check
• Professional documentation

When Opus is done: ✅ Your skill is production-ready! 💾 Save to .claude/skills/[skill-name]/SKILL.md 🧪 Test it on a real problem 📊 Track usage metrics

Example - What Opus added to code-review:

## 🚫 Anti-Patterns
| ❌ Don't | ✅ Do Instead |
|----------|---------------|
| "It should work now" | "Here's the test proving it works" |
| "Try it and see" | "Follow these numbered steps" |
| Fix all bugs at once | Fix, test, repeat for each bug |

## 📈 Success Metrics
- Bugs found in self-review: N
- Bugs fixed before user testing: N
- User-reported issues: N
- Iteration cycles: N

🎨 Skill Naming Conventions

Good Names

• state-fixer ✅ (verb-noun, action-focused)
• code-review ✅ (clear purpose)
• iterative-testing ✅ (describes workflow)

Bad Names

• debug ❌ (too vague)
• helper ❌ (not descriptive)
• fix-stuff ❌ (unprofessional)

Pattern

[action]-[target]
   ↓        ↓
  verb     noun

Examples:
- make-skills (make = action, skills = target)
- state-fixer (fix = action, state = target)
- code-review (review = action, code = target)

📊 Common Skill Creation Examples

Example 1: State Management Debugger Skill

Pattern Discovery:

git log --all --grep="state\|redux\|context" --oneline

# Found patterns:
abc123 Fix: State not updating after API call
def456 Fix: Race condition in state updates
ghi789 Fix: localStorage sync issues with React state

Common Theme: State synchronization bugs across different storage layers

User Signals:

• "The state isn't persisting"
• "Data disappears on refresh"
• "Updates aren't reflecting in UI"

Resulting Skill Structure:

1. Quick diagnostic checklist
2. State flow diagram (Component → Store → Storage)
3. Common bug patterns with fixes
4. Testing strategies for state issues

Example 2: API Integration Skill

Pattern Discovery:

# Conversation analysis revealed:
- 5 instances of "add API endpoint"
- 3 instances of "fix CORS issues"
- 4 instances of "handle API errors"

# Code pattern:
grep -r "fetch\|axios\|api" --include="*.{js,ts}" | wc -l
# Result: 150+ API calls across codebase

Resulting Skill Structure:

1. API endpoint creation checklist
2. Error handling patterns
3. Testing strategies (unit, integration, e2e)
4. Common pitfalls (CORS, auth, rate limits)

Example 3: Performance Optimization Skill

Pattern Discovery:

git log --all --grep="slow\|performance\|optimize" --oneline

# Found:
- Multiple commits about React re-renders
- Database query optimizations
- Bundle size reductions

User Signals:

• "The app feels sluggish"
• "This query takes too long"
• "Bundle size is too large"

Resulting Skill Structure:

1. Performance audit workflow
2. Measurement tools by platform
3. Common optimization patterns
4. Before/after comparison templates

✅ Skill Quality Checklist

Before finalizing a skill:

Content

• Has clear "When to use" section
• Includes 3+ real examples from project
• All commit hashes verified (use git show <hash>)
• Code snippets are accurate (Read from actual files)
• Has step-by-step workflow
• Includes "What NOT to do" section

Organization

• Uses emojis for visual scanning (🎯 🔴 ✅ ❌)
• Has tables for comparisons
• Code blocks are properly formatted
• Headers are hierarchical (##, ###)

Usability

• Can be used by Claude without user present
• Has proactive triggers (when to suggest it)
• Includes testing/verification steps
• Links to related skills

Accuracy

• All file paths are correct
• All line numbers are current
• All examples compile/work
• No hypothetical code - all real

🔧 Commands for Skill Creation

Research Phase

# === Version Control Analysis ===
# Find related commits
git log --all --grep="keyword" --oneline

# See commit details
git show <commit-hash>

# Analyze commit frequency by author
git shortlog -sn --all

# Find most changed files (hotspots)
git log --all --name-only --format="" | sort | uniq -c | sort -rn | head

# === Code Pattern Search (Language Agnostic) ===
# JavaScript/TypeScript
grep -r "pattern" --include="*.{js,jsx,ts,tsx}"

# Python
grep -r "pattern" --include="*.py"

# Java/Kotlin
grep -r "pattern" --include="*.{java,kt}"

# Go
grep -r "pattern" --include="*.go"

# Ruby
grep -r "pattern" --include="*.{rb,erb}"

# General pattern search
find . -type f -exec grep -l "pattern" {} \; 2>/dev/null

# === Skill Discovery ===
# List existing skills
ls .claude/skills/

# Read all skill descriptions
find .claude/skills -name "SKILL.md" -exec head -5 {} \;

# Search for similar skills
grep -r "keyword" .claude/skills/

Creation Phase

# Create skill directory
mkdir -p .claude/skills/new-skill-name

# Create SKILL.md
# (Use Write tool with template above)

Verification Phase

# Check skill loads
cat .claude/skills/new-skill-name/SKILL.md

# Verify commit hashes exist
git show <hash>

# Test file paths
ls -la <path-from-skill>

📈 Skill Evolution Pattern

Our successful pattern:

Iteration 1 (Haiku):
├─ Basic structure
├─ Simple examples
└─ Core workflow
   ↓ (2 hours of use)

Iteration 2 (Sonnet):
├─ Real commit examples
├─ Actual code from project
├─ Better organization
└─ More detailed steps
   ↓ (1 day of use)

Iteration 3 (Opus):
├─ Edge cases
├─ Troubleshooting
├─ Anti-patterns
├─ Complete documentation
└─ Production ready

🎯 Skill Success Metrics

Track these to know if a skill is useful:

Quantitative

• Usage frequency: How often is skill invoked?
• Time saved: Workflow time before vs after skill
• Error reduction: Bugs missed before vs after skill

Qualitative

• User feedback: "this skill is helpful" or requests for changes
• Iteration count: Does skill reduce back-and-forth?
• Coverage: Does it handle most cases or need extensions?

Example from our skills:

state-fixer:
- Used: 3 times in 1 week
- Time saved: ~30 min per debug session
- Bugs caught: 4/4 state bugs in recent work

code-review:
- Used: Every major feature (5 times)
- Time saved: ~15 min per review
- Bugs caught: 3-5 bugs per review before user testing

🚫 Anti-Patterns (What NOT to Do)

❌ Don't: Create skills for one-time tasks

Bad: "import-csv-file" skill for a one-time data import
Good: "data-migration" skill if you do migrations regularly

❌ Don't: Make skills too specific

Bad: "fix-ybc-table-row-3-bug"
Good: "state-fixer" (covers all state bugs)

❌ Don't: Use hypothetical examples

Bad: "Imagine you have a function foo()..."
Good: "In YBCTableDialog.tsx:1321, we had this bug..."

❌ Don't: Skip the research phase

Bad: Create skill based on 1 occurrence
Good: Find 3+ repeated patterns in git/conversation

❌ Don't: Make skills without testing

Bad: Write skill and never use it
Good: Use skill 2-3 times, then refine based on actual usage

🔗 Related Skills

• code-review: Use after creating skill to review quality
• state-fixer: Example of well-structured skill
• iterative-testing: Pattern for skill improvement

📚 Skill Template Library

Quick Copy-Paste Templates

Minimal Skill Template

---
name: skill-name
description: What it does and when to use it
---

# Skill Name

## 🎯 Quick Start
When to use this skill

## Common Patterns
1. Pattern 1
2. Pattern 2

## Workflow
1. Step 1
2. Step 2
3. Step 3

## Example
Real example from project

Full Skill Template

---
name: skill-name
description: Detailed description with trigger keywords
---

# Skill Name

One-line overview.

## 🎯 Quick Start
- User triggers
- Proactive usage
- When NOT to use

## Common Patterns / Checklist
### Pattern 1
- Example
- Code snippet

### Pattern 2
- Example
- Code snippet

## Step-by-Step Workflow

### Step 1: Name
What to do
```bash
command

Step 2: Name

What to do

Real Examples from Project

Example 1: [Commit hash]

Problem: Solution: Code:

before → after

Testing / Verification

How to verify skill worked

🚫 Anti-Patterns

What NOT to do

🔗 Related Skills

• Skill 1
• Skill 2

📈 Success Metrics

How to measure effectiveness

## 💡 Pro Tips

### Tip 1: Start Small, Iterate
Don't try to make perfect skill on first try. Use Haiku for quick draft, use it a few times, then enhance with Sonnet/Opus.

### Tip 2: Use Real Commit Hashes
Always reference actual commits. Makes skill credible and verifiable.
```bash
# Good
### Example: Commit 3499b6e
git show 3499b6e

# Bad
### Example: Some bug we fixed

Tip 3: Include Console Log Patterns

Real debugging often uses console.log. Include actual log messages used.

// From state-fixer skill:
console.log(`💾 Saved YBC edits with angle-specific key: ${storageKey}`, editData);

Tip 4: Add Visual Markers

Use emojis for quick scanning:

• 🎯 Goals/Objectives
• 🔴 Critical issues/bugs
• ✅ Solutions/Correct way
• ❌ Wrong way/Anti-patterns
• 📊 Data/Metrics
• 🔧 Commands/Tools
• 💡 Tips/Insights

Tip 5: Link Between Skills

Skills work better together. Reference related skills.

## 🔗 Related Skills
- Use `code-review` after implementing solution
- Use `state-fixer` if dealing with state bugs
- Use `iterative-testing` for geometric algorithms

🌍 Cross-Language Skill Patterns

Skills often translate across languages and frameworks. Here's how to adapt:

Universal Skill Categories

Language-Specific Adaptations

JavaScript/TypeScript:
  - Focus: Async/Promise patterns, React hooks, Node.js specifics
  - Tools: npm, webpack, ESLint
  - Patterns: Component lifecycle, state management

Python:
  - Focus: Type hints, async/await, decorators
  - Tools: pip, pytest, mypy
  - Patterns: Context managers, generators

Java/Kotlin:
  - Focus: Concurrency, streams, annotations
  - Tools: Maven/Gradle, JUnit
  - Patterns: Dependency injection, builders

Go:
  - Focus: Goroutines, channels, interfaces
  - Tools: go mod, go test
  - Patterns: Error handling, context usage

Ruby:
  - Focus: Metaprogramming, blocks, modules
  - Tools: bundler, RSpec
  - Patterns: DSLs, mixins

🎓 Skill Evolution Patterns

The 3-Stage Lifecycle

Stage 1: Discovery (0-3 occurrences)
├─ Pattern emerges from repeated work
├─ User mentions "we keep doing X"
└─ Initial documentation in conversation
   ↓
Stage 2: Formalization (3-5 uses)
├─ Create initial skill with Haiku
├─ Test on real problems
├─ Gather feedback and edge cases
└─ Enhance with Sonnet
   ↓
Stage 3: Production (5+ uses)
├─ Polish with Opus
├─ Add metrics and success criteria
├─ Create related skills
└─ Skill becomes standard workflow

Success Indicators

Quantitative Metrics:

High Value Skill:
  - Used: >5 times per week
  - Time saved: >30 min per use
  - Error reduction: >50%
  - User mentions: "use the X skill"

Medium Value Skill:
  - Used: 2-5 times per week
  - Time saved: 10-30 min per use
  - Error reduction: 20-50%
  - User aware of skill

Low Value (Needs Refinement):
  - Used: <2 times per week
  - Time saved: <10 min
  - May need broader scope or merger with another skill

🚀 Advanced Skill Patterns

Composite Skills

Skills that combine multiple smaller skills:

deployment-pipeline:
  ├─ Uses: code-review
  ├─ Uses: test-runner
  ├─ Uses: performance-checker
  └─ Orchestrates full deployment workflow

Domain-Specific Skills

Highly specialized for particular domains:

ml-model-debugger:
  - Dataset validation
  - Training monitoring
  - Hyperparameter tuning
  - Model versioning

database-migration:
  - Schema evolution
  - Data transformation
  - Rollback strategies
  - Zero-downtime techniques

Meta-Skills

Skills about skills (like this one):

skill-optimizer:
  - Analyzes skill usage patterns
  - Suggests improvements
  - Merges redundant skills
  - Creates skill hierarchies

Remember: The best skills come from real repeated patterns, not anticipated needs. Let the work guide you to the skills you actually need!

Universal Truth: If you've done something manually 3+ times, it's time to make it a skill.

골치 아픈 버그가 하나 터졌다. 대형 모델 서빙할 때, JAX 쓰고 TPU로 돌리니까 XLA 컴파일러에서 이상한 정밀도(16비트-32비트) 엇갈림 때문에, 가장 확률 높은 토큰이 아예 누락되는 등, 한참 동안 아무도 알아채지 못했던 이상 버그가 간헐적으로 등장한 거다.

솔직히 말하면, NVIDIA 서버에 PyTorch만 썼으면 이런 일 진짜 거의 없었을 거다. 오히려 JAX+TPU+XLA라는 최신(?) 조합이 아니었으면, 누구나 원인 짚고 패치하기 쉬웠다. PyTorch는 개발자 수, 디버깅 편의성, 정밀도 자동 관리를 이미 수년간 검증받았다.

앞으로도 AMD든, 뭐든 새로운 하드웨어&프레임워크 쓰면 비슷한 꼬인 버그 만날 확률 정말 높다. 결국 진짜 중요한 건, 코드를 누구보다 멋지게 짜는 것도 아니고, 가장 적합한 '도구'와 아키텍처, 그리고 제대로 동작하는지 일찍 알아낼 수 있는 환경과 습관이다.

아직까지는 NVIDIA+PyTorch. 이 조합이 실패 없는 안전빵이고, 새로운 플레잉필드에선 막연한 혁신보다, 검증된 프레임워크와 개발 생태계가 훨씬 더 중요하다. 앞으로 변화 더 빨라진다면, 괜히 최신 기술 따라가다 내 일자리까지 털릴 수 있으니, 자기가 쓰는 도구와 플랫폼의 한계, 버그까지 미리 파악해두는 사람이 진짜로 살아남는다.

클로드코드 및 다른 AI 코딩툴 다 써도 해결 안된 문제를 3트만에 해결 대신 비쌈...

서로 250 크레딧 리퍼럴 링크(최대 5명)

유튜브 관련 링크 https://www.youtube.com/watch?v=y4JvgfsO8PU https://www.youtube.com/watch?v=gcWy_mQiEFc

안트로픽 버그 fix

위 버그 때문에 클로드 오프스 보다 좋아 보인걸 수도 있습니다.

DRS Updating 읽고 따라하기

2번정도는 program failed 나오는데, 여러번 하면 결국 된다.

메인보드사 RGB Controller 다운받고

윈도우 설정까지 맞추면 끝.

문제는 대부분의 설명이 시작부터 아래와 같은 알 수 없는 수학 공식을 들이민다는 겁니다.

q(x_t | x_(t-1)) = N(x_t; sqrt(1 - beta_t) * x_(t-1), beta_t * I)

이런 식만 보고 "아, 노이즈를 추가하는 정규분포군!" 하고 바로 이해하는 사람이 몇이나 될까요? 공식을 이해하려면 직관이 먼저입니다. 제가 이제부터 이 공식이 왜 나왔는지, 그리고 이 모델이 실제로 어떻게 작동하는지 차근차근 설명해 드리겠습니다. 설명을 다 듣고 나면, 이 공식이 사실은 매우 간단한 아이디어를 표현한 것뿐이라는 걸 깨닫게 되실 겁니다.

확산 모델의 큰 그림: 예술가가 되는 비법

확산 모델의 핵심 아이디어는 아주 역설적이고 재미있습니다. AI에게 '창조'하는 법을 가르치기 위해, 먼저 '파괴'하는 법을 완벽하게 마스터하게 하는 것입니다.

가장 쉬운 비유로 시작해 보죠.

• 선명한 원본 사진이 한 장 있습니다. 우리의 최종 목표는 AI가 이런 사진을 스스로 그리게 하는 것입니다.
• 그런데 처음부터 흰 캔버스에 그림을 그리게 하는 건 너무 어렵습니다.
• 대신, AI에게 망가진 사진을 복원하는 방법을 가르치기로 합니다.
• 그러려면? AI에게 줄 '망가진 사진' 문제집이 필요하겠죠. 그래서 우리는 먼저 사진을 망가뜨리는 전문가가 되어야 합니다.

이것이 바로 확산 모델의 순방향 과정(Forward Process)과 역방향 과정(Reverse Process)의 핵심입니다.

1. 순방향 과정 (Forward Process): 일부러 사진을 망가뜨리기

이 단계는 AI를 훈련시키기 위한 '문제집'을 만드는 과정입니다. 깨끗한 사진(x_0)에서 시작해서, 그 위에 모래알 같은 노이즈(noise)를 아주 조금씩, 여러 번(T번)에 걸쳐 뿌립니다.

한 번 뿌릴 때마다 사진은 아주 살짝 손상됩니다. 이 과정을 수백, 수천 번 반복하면, 마지막(x_T)에는 원래 사진이 무엇이었는지 전혀 알아볼 수 없는 순수한 노이즈(TV 채널이 끊겼을 때 나오는 '지지직' 화면)만 남게 됩니다.

이제 수학 공식을 파헤쳐 봅시다

q(x_t | x_(t-1)) = N(x_t; sqrt(1 - beta_t) * x_(t-1), beta_t * I)

겁먹지 마세요. 하나씩 뜯어보면 별거 아닙니다.

• q(x_t | x_(t-1)): "이전 단계 이미지(x_(t-1))가 있을 때, 다음 단계 이미지(x_t)는 어떤 모습일까?"를 나타내는 기호입니다. 즉, '노이즈를 한 번 뿌렸을 때의 결과'를 설명하는 식이죠.
• N(...): '정규 분포' 또는 '가우시안 분포'를 의미합니다. 갑자기 웬 통계일까요? 우리가 추가하는 노이즈는 완전히 무작위적이지만, 대부분의 노이즈는 미세한 변화를 주고 아주 가끔 큰 변화를 주는 패턴을 보입니다. 이런 자연스러운 무작위성을 표현하기에 가장 적합한 도구가 바로 정규 분포입니다.
• 평균 (sqrt(1 - beta_t) * x_(t-1)): 이 부분이 핵심입니다. beta_t(베타)는 t번째 단계에서 우리가 뿌릴 노이즈의 양을 나타내는 아주 작은 숫자입니다(예: 0.001). 그러면 sqrt(1 - beta_t)는 1보다 아주 살짝 작은 값이 되겠죠? 즉, 이 부분의 의미는 "이전 이미지를 가져와서 아주 살짝 희미하게(값을 작게) 만들어라"는 뜻입니다. 원본의 형태는 유지하되, 약간 흐리게 만드는 거죠.
• 분산 (beta_t * I): 바로 이 부분이 실제 노이즈를 뿌리는 역할을 합니다. 분산은 데이터가 흩어진 정도를 의미하는데요, 여기서는 beta_t의 강도로 픽셀 값들을 무작위로 흩어놓으라는 의미입니다.

순방향 과정 한 줄 요약: "이전 이미지를 살짝 흐리게 만들고, 그 위에 beta_t만큼의 노이즈를 뿌린다." 이 과정을 T번 반복하면 완벽한 노이즈 이미지가 만들어집니다. (역자: 결국 순방향 과정은 AI를 위한 '오답 노트'를 만드는 과정이라고 보시면 됩니다. 정답(깨끗한 이미지)과 다양한 수준의 오답(노이즈 낀 이미지)을 미리 다 만들어두는 거죠.)

2. 역방향 과정 (Reverse Process): AI가 사진을 복원하는 법 배우기

이제 본격적으로 AI를 훈련시킬 시간입니다. AI는 '망가진 사진'을 보고 '어떻게 망가졌는지'를 알아맞히는 전문가가 되어야 합니다.

어려움: x_t(노이즈가 조금 낀 이미지)를 보고 x_(t-1)(노이즈가 끼기 바로 전 이미지)을 예측하는 것은 거의 불가능합니다. 경우의 수가 너무 많기 때문이죠.

천재적인 발상의 전환: 여기서 확산 모델의 가장 중요한 아이디어가 나옵니다. "이전 이미지를 통째로 예측하지 말고, 방금 추가된 '노이즈'만 예측하자!"

AI 모델(epsilon_theta)의 역할은 이렇습니다.

• 입력: 노이즈 낀 이미지 x_t와 현재 단계 t를 AI에게 보여줍니다. (역자: 단계 t를 알려주는 것이 매우 중요합니다. AI는 지금이 초기 단계인지, 거의 다 복원된 단계인지 알아야 예측할 노이즈의 양을 조절할 수 있습니다.)
• 출력: AI는 x_t에 섞여있을 것이라고 예측되는 노이즈 epsilon을 뱉어냅니다.

훈련 과정:

1. 순방향 과정에서 우리는 t 단계의 노이즈 낀 이미지(x_t)와, 그때 사용한 실제 정답 노이즈(epsilon)를 모두 알고 있습니다.
2. AI에게 x_t를 보여주고 "여기에 섞인 노이즈가 뭘까?"라고 묻습니다.
3. AI는 예측 노이즈를 내놓습니다.
4. AI의 예측과 실제 정답을 비교해서, 둘 사이의 차이(오차)를 계산합니다.
5. 이 오차를 줄이는 방향으로 AI의 내부 파라미터(theta)를 계속 업데이트합니다. 마치 오답 노트를 보며 공부하는 학생처럼요.

역방향 과정 한 줄 요약: "AI는 노이즈 낀 이미지를 보고 '어떤 노이즈가 추가됐을까?'를 맞추는 훈련을 반복하며, 점차 노이즈 예측의 달인이 되어갑니다."

최종 정리: 창조는 어떻게 일어나는가?

훈련이 끝난 확산 모델은 이제 '노이즈 예측의 대가'가 되었습니다. 이제 이 모델로 완전히 새로운 이미지를 만들 수 있습니다.

1. 완전히 무작위적인 노이즈(순수한 '지지직' 화면 x_T)에서 시작합니다.
2. AI에게 이 노이즈 덩어리를 보여주며 "여기서 제거해야 할 노이즈는 뭐야?"라고 묻습니다.
3. AI는 예측한 노이즈를 알려주고, 우리는 그 노이즈를 x_T에서 살짝 뺍니다. 그러면 아주 희미하게 무언가의 형체가 나타납니다 (x_(T-1)).
4. 이 과정을 x_0에 도달할 때까지 계속 반복합니다.
5. 그러면 최종적으로, 훈련 데이터에서 봤던 그림들과 비슷하지만 세상에 없던 새로운, 깨끗한 이미지가 마법처럼 생성됩니다.

이것이 바로 생성 확산 모델의 작동 원리입니다. 복잡한 수식은 결국 '사진을 체계적으로 망가뜨렸다가, 그 과정을 거꾸로 되짚어 복원하는' 매우 직관적인 아이디어를 표현한 것뿐입니다.

추가설명 1

sqrt(1 - beta_t)에서 sqrt를 사용하는 이유는 '분산(variance)'의 성질 때문입니다. 양수로 만들려는 목적이 아니라, 전체 분산을 1로 유지하기 위한 수학적 장치입니다.

이것을 이해하려면 '분산'과 '표준편차'의 관계를 먼저 알아야 합니다.

1. 분산(Variance)과 표준편차(Standard Deviation)

• 분산 (σ²): 데이터가 평균으로부터 얼마나 퍼져 있는지를 나타내는 값입니다. 숫자가 클수록 많이 흩어져 있다는 뜻입니다.
• 표준편차 (σ): 분산에 제곱근(sqrt)을 씌운 값입니다. 분산은 단위를 제곱한 형태라 직관적이지 않아서, 다시 원래 단위로 돌려놓은 것이 표준편차입니다.

핵심 관계: 표준편차 = sqrt(분산)

우리가 사용하는 가우시안 노이즈는 '표준' 정규 분포를 따릅니다.

• 표준 정규 분포 (N(0, I)): 평균이 0이고, 분산이 1인 특별한 정규 분포입니다.

2. 왜 분산을 1로 유지해야 할까요?

확산 모델의 아이디어는, 깨끗한 이미지(x_0)에 노이즈를 계속 추가해서 최종적으로는 완전히 무작위적인 노이즈(x_T), 즉 표준 정규 분포 N(0, I) 와 거의 똑같은 상태로 만드는 것입니다.

여기서 중요한 가정이 있습니다. "과정 중간에 있는 모든 이미지(x_1, x_2, ... x_t)들도 대략적으로 표준 정규 분포(N(0, I))를 따르게 만들자!" 는 것입니다. 즉, 각 단계의 이미지들의 분산도 항상 1로 유지되도록 만들고 싶은 거죠.

왜냐하면, 이렇게 하면 모델이 훨씬 안정적으로 학습되고, 수학적으로 다루기도 쉬워지기 때문입니다.

3. Sqrt가 마법을 부리는 방법: 분산을 1로 만드는 과정

이제 수식을 다시 봅시다.

x_t = sqrt(1 - β_t) * x_{t-1} + sqrt(β_t) * ϵ

이 식은 "다음 이미지(x_t)"는 "이전 이미지(x_{t-1})의 성분"과 "새로운 노이즈(ϵ)의 성분"을 더해서 만들어진다는 뜻입니다.

통계학에는 아주 중요한 공식이 있습니다. 서로 독립적인 두 확률 변수 X, Y가 있을 때,

Var(a*X + b*Y) = a² * Var(X) + b² * Var(Y)

(여기서 Var는 분산(Variance)을 의미합니다.)

이 공식을 우리 식에 적용해 봅시다.

• a = sqrt(1 - β_t)
• X = x_{t-1}
• b = sqrt(β_t)
• Y = ϵ

그러면 x_t의 분산은 다음과 같이 계산됩니다.

Var(x_t) = (sqrt(1 - β_t))² * Var(x_{t-1}) + (sqrt(β_t))² * Var(ϵ)

여기서 제곱근(sqrt)과 제곱(²)이 서로 만나 사라지는 마법이 일어납니다!

Var(x_t) = (1 - β_t) * Var(x_{t-1}) + β_t * Var(ϵ)

이제 각 항의 분산을 대입해 봅시다.

• Var(x_{t-1}): 우리는 이전 단계의 이미지도 분산이 1이라고 가정했습니다. 그래서 Var(x_{t-1}) = 1 입니다.
• Var(ϵ): ϵ는 우리가 추가하는 순수 노이즈이고, 표준 정규 분포를 따르므로 분산이 1입니다. Var(ϵ) = 1 입니다.

이 값들을 대입하면,

Var(x_t) = (1 - β_t) * 1 + β_t * 1 Var(x_t) = 1 - β_t + β_t Var(x_t) = 1

결론적으로, x_t의 분산도 정확히 1이 됩니다!

요약

• Sqrt를 왜 쓰나요?
  • 분산을 조절하기 위해서입니다.
• 어떻게 조절하나요?
  • 이전 이미지에서 가져올 성분(x_{t-1})과 새로운 노이즈에서 가져올 성분(ϵ)의 분산의 합이 항상 1이 되도록 계수를 설정하는 것입니다.
  • 계수들을 각각 sqrt(1 - β_t) 와 sqrt(β_t) 로 설정하면, 이들을 제곱해서 더했을 때 (1 - β_t) + β_t = 1 이 되기 때문에, 다음 단계 이미지의 분산도 깔끔하게 1로 유지됩니다.

즉, sqrt는 각 단계에서 이미지의 '흩어짐 정도(분산)'를 일정하게 유지시켜주는, 매우 정교하고 중요한 수학적 장치인 것입니다. 양수/음수와는 직접적인 관련이 없습니다.

추가설명 2

네, 아주 좋은 지적입니다. 그 부분을 명확하게 짚고 넘어가는 것이 중요합니다.

q(x_t | x_{t-1}) = N(x_t; sqrt(1 - β_t) * x_{t-1}, β_t * I)

여기서 왜 β_t * I 가 분산을 나타내는지 단계별로 설명해 드릴게요.

1. 정규 분포의 기본 형태 복습

먼저, 정규 분포를 나타내는 기호 N(μ, σ²)를 다시 봅시다.

• μ (뮤): 평균 (데이터가 어디에 몰려있는가)
• σ² (시그마 제곱): 분산 (데이터가 얼마나 널리 퍼져있는가)

우리 수식에서 이 형태에 맞춰보면 다음과 같습니다.

• 평균 μ = sqrt(1 - β_t) * x_{t-1}
• 분산 σ² = β_t * I

즉, 이 수식은 β_t * I를 분산으로 갖는 정규 분포를 따르도록 정의된 것입니다. 이제 왜 이것이 '분산'의 역할을 하는지 그 의미를 파헤쳐 보겠습니다.

2. I (단위 행렬, Identity Matrix)의 역할: 픽셀별 독립성

이미지는 수많은 픽셀들의 집합입니다. 예를 들어 64x64 이미지는 4096개의 픽셀 값을 가집니다.

• 만약 분산이 그냥 숫자 하나(β_t)라면, 모든 픽셀이 똑같은 정도로만 퍼져나간다는 의미가 됩니다.
• 하지만 우리는 각 픽셀에 서로 독립적인(상관없는) 노이즈를 추가하고 싶습니다. 1번 픽셀에 추가된 노이즈가 2번 픽셀에 영향을 주면 안 됩니다.

이 '독립성'을 수학적으로 표현하는 것이 바로 단위 행렬 I 입니다.

• 단위 행렬 I란? 대각선 성분만 1이고 나머지는 모두 0인 행렬입니다. $$ I = \begin{pmatrix} 1 & 0 & 0 \ 0 & 1 & 0 \ 0 & 0 & 1 \end{pmatrix} $$ (이건 3x3 예시이고, 4096개 픽셀이라면 4096x4096 행렬이 됩니다.)

• 통계학에서의 의미: 분산을 나타내는 행렬(공분산 행렬)에서, 대각선 이외의 성분이 0이라는 것은 각 변수(픽셀)들이 서로 상관관계가 없다(독립적이다)는 뜻입니다.

따라서 분산 자리에 I가 있다는 것은 "각 픽셀에 추가되는 노이즈는 다른 픽셀의 노이즈와 완전히 독립적이다" 라는 가정을 나타냅니다.

3. β_t (베타)의 역할: 노이즈의 강도 조절

이제 β_t가 무엇을 하는지 봅시다.

• β_t는 아주 작은 양수입니다 (예: 0.001, 0.002, ...).

• 이 숫자가 단위 행렬 I에 곱해집니다. $$ \beta_t * I = \beta_t * \begin{pmatrix} 1 & 0 \ 0 & 1 \end{pmatrix} = \begin{pmatrix} \beta_t & 0 \ 0 & \beta_t \end{pmatrix} $$

• 의미: 이제 분산 행렬의 대각선 성분이 1이 아니라 β_t가 되었습니다. 이는 각 픽셀의 노이즈가 평균 0, 분산 β_t인 정규 분포를 따른다는 의미입니다.

• 결론적으로 β_t는 노이즈의 '강도' 또는 '크기'를 조절하는 역할을 합니다.

  • β_t가 크면: 노이즈가 강하게 추가되어 이미지가 많이 망가집니다.
  • β_t가 작으면: 노이즈가 약하게 추가되어 이미지가 조금만 망가집니다.

확산 모델에서는 보통 t가 0에 가까울 때는 β_t를 작게 설정하고, t가 커질수록 β_t를 점차 크게 만들어 노이즈의 강도를 점진적으로 높입니다.

정리

분산 (β_t * I) 이라는 표현을 다시 한번 해석해 봅시다.

"각 픽셀에 노이즈를 추가할 건데,"

• I: "각 픽셀에 추가되는 노이즈는 서로 완전히 독립적이야."
• β_t: "그리고 그 노이즈의 강도(분산)는 β_t 만큼이야."

이것이 바로 β_t * I 가 분산의 자리에 있는 이유입니다. 이것은 단순한 숫자가 아니라, 수많은 픽셀들에게 독립적으로, 특정 강도의 노이즈를 어떻게 부여할 것인지를 정의하는 약속이자 설계도인 셈입니다.

Text 생성의 제약 컨텍스트 사이즈의 제한으로 인해 텍스트 생성 AI는 아직 완벽한 성능을 보여주지 못하고 있다. 진정한 의미의 고성능 구현을 위해서는 현재보다 100-1000배 이상의 GPU 연산력이 필요한 상황이다.

비디오 생성의 현실 구글이 개발한 비디오 생성 AI도 아직은 제한적인 성능을 보여준다. 짧은 길이의 영상만 가능하고, 성공적인 결과물과 실패한 결과물이 혼재되어 있는 상황이다.

전략적 접근의 필요성

대중의 이해도 격차 현재 문제점 중 하나는 대중들이 AI 기술의 실제 규모와 현재 한계를 정확히 이해하지 못한다는 점이다. 아직 갈길이 멀다 그래서 더 많은 하드웨어가 필요하다 100배,1000배가 필요하고 그래서 최대 규모의 gpu 클러스터를 가지고 있는 xAI의 LLM 모델 Grok3이 기대되는 점이다.

결론: 패닉셀은 기회니 주어 담으면 된다. 단, 점진적으로 사야 한다. 왜냐면 대중의 무지의 크기가 얼마난지 난 모른다.

2050년 없어질 0순위 업종: 일반 프로그래머

4년 하고 5개월 전, 대충 미래가 어떻게 변화할지는 짐작했다. 하지만 이렇게 빠르게 변화할 줄은 몰랐다. 그때 potcast에서 잠깐 나온 OpenAI의 Sam Altman이라는 사람이 대단한 사람인 줄은 알았지만, 이렇게 빠른 시간에 이렇게 많은 영향력을 미칠 사람이 될 줄은 몰랐다. 당시만 해도 그냥 파이썬 프로그램을 만들어주는 인공지능이라고 문득 스쳐 지나갔는데... 당장 세상을 변화시킬 ChatGPT의 초기 모습이라는 걸 그 당시에는 제대로 깨닫지 못했다.

하지만 한 가지는 확실하다. 이제는 더 이상 코드를 잘 짜는 사람이 중요한 것이 아니라, 앱/웹 등 각종 프로그램을 만들 때 가장 적절한 '공구'가 무엇인지 아는 사람이 더 중요한 시대이다. 그런데 각 IT 회사의 중간 관리자들의 저항이 거세다. 왜냐하면 이미 그들은 자신이 일자리를 잃을 것을 알고 최대한 시간을 벌려고 하기 때문이다. 책임감 있게 자신이 직접 빠르게 이 기술을 접목하면 앞서갈 것을 알면서도, 총대는 다른 사람이 들기를 원한다. 오히려 임원들이 훨씬 더 진취적이고, 회사를 위해 생각하며 지원해준다.

일주일 단위로 바뀌는 인공지능 세상인데, 한국 노동법은 너무나도 노동자에게 유리하다. 사실 IT 종사자 중 대부분은 재교육을 받아야 할 대상인데, 해고가 자유롭지 않으니 임원이나 고용자 입장에서는 답답할 것이다. 심각한 것은 아무도 이런 이야기를 공개적으로 하지 않는다는 점이다.

이미 중국은 사기업 High-Flyer에서 Deepseek V3 오픈소스 LLM을 공개했다. 삼성, LG 자체 LLM보다 훨씬 뛰어나고, Anthropic의 Claude Sonnet 3.5보다 성능이 떨어지지만 가격 면에서는 최소 1/10로 싸다.

앞으로 프로그래머를 LLM이 대체하지 않을 거라고? 그리고 현재 FANG에서 그렇게 하지 않는다고? 라고 한다면 이런 이야기를 해주고 싶다. 유명한 미국 IT 유튜버가 있다. 당시 이런 발언을 했다. 자신은 구글 데이터 사이언티스트로 일하는데, 인공지능 관련 교육을 받지 않는다며 "사람이 구글에서 데이터 사이언티스트로 일할 때 그런 거 다 필요 없다. 현재 내 팀에서는 쓰지 않는다."라고 해서 많은 사람들이 안심했다. 그러나 현재는 어떻게 되었나? 그 사람은 지금 일반 엔지니어가 되었다. 그런 것처럼 현재 자신의 팀에서 쓰지 않는다고 해서 기술의 발전이 멈추는 것은 아니다. 그 그러니 빠르게 이런 LLM 코딩툴 유튜브 채널가서 배워라.

내년 LLM에 넣을 데이터 현저히 작아진다.

현재 청산시 무위험으로 30% 수익 시장에 배팅 했다면 35% 수익 하지만, 아무래도 10% 무수익으로 먹고 끝날을 듯.

얻은 데이터: 나의 관점과 시장과 괴리 lag는 1년 정도 걸림.

현재 나의 관점: text data는 용량이 작고 처리하는 비용이 상대적으로 매주 적음 또한 강화학습을 접목한 추론 LLM의 등장으로 양질의 데이터를 생산 할 수 있게 됨. 생각보다 한계가 없을 수도 있음.

하지만, 용량이 큰, 사진, 비디오, 오디오 데이터로는 현재 text bassed LLM 수준을 따라오기에는 매우 힘들 것으로 보임. 다른 말로는 아직은 큰 가치가 없음.

단, 생각보다 인공지능 로봇이 빠르게 발달 할 수 있겠음. Genesis라는 오픈소스 시뮬레이터가 배포됨. 그렇다고 해서 1~2년 후에 바로 뜬다는 것이 아님. 왜냐하면 아직 시뮬레이션쪽을 제대로 조사를 못함.

투자 포지션: 중립. 딱히 떠오르는 무위험 거래 아직 없음.

OVER ()란 뭘까요?

OVER () 절은 SQL에서 윈도우 함수를 사용할 때 쓰이는 마법의 주문이에요. 이걸 사용하면 데이터를 그룹화하지 않고도 집계 함수를 적용할 수 있어요. 마치 떡볶이 먹을 때 떡과 오뎅을 따로 먹지 않고 한 번에 먹는 것처럼요!

OVER ()의 매력 포인트

1. 행 유지력 최강: GROUP BY와 달리 모든 행을 유지하면서 계산해요.
2. 파티션 파티!: PARTITION BY를 사용하면 데이터를 그룹으로 나눌 수 있어요.
3. 순서는 내 맘대로: ORDER BY로 원하는 대로 정렬할 수 있어요.

실전에서 써보자!

자, 이제 우리 '맛있는 코딩 주식회사'의 직원 정보로 OVER ()를 사용해볼게요:

SELECT 
    사원명,
    부서명,
    급여,
    AVG(급여) OVER (PARTITION BY 부서명) AS 부서평균급여
FROM 직원테이블

이 쿼리의 결과를 볼까요?

와! 각 직원의 정보와 함께 부서별 평균 급여를 한눈에 볼 수 있네요. 👀

GROUP BY와 비교해보기

이제 GROUP BY와 OVER ()를 비교해볼까요? 마치 김치찌개와 된장찌개를 비교하는 것처럼 둘 다 맛있지만 다른 매력이 있어요!

GROUP BY 사용하기

SELECT 
    부서명,
    AVG(급여) AS 부서평균급여
FROM 직원테이블
GROUP BY 부서명

결과:

GROUP BY는 비빔밥 재료를 모두 섞어버린 것 같아요. 맛은 좋지만, 각 재료의 개성은 좀 사라졌죠?

비교 포인트

1. 세부 정보:

   • GROUP BY: 부서별 평균만 보여줘요. 개인 정보는 사라져요. 😢
   • OVER (): 개인 정보와 부서 평균을 동시에 볼 수 있어요. 완전 대박! 🎉

2. 유연성:

   • GROUP BY: 집계 결과만 볼 수 있어요. 딱딱하네요.
   • OVER (): 원래 데이터에 집계 결과를 추가할 수 있어요. 부드럽고 유연해요!

3. 사용 목적:

   • GROUP BY: 데이터를 요약하고 싶을 때 좋아요. 마치 식당 메뉴판처럼!
   • OVER (): 세부 데이터와 요약 정보를 동시에 보고 싶을 때 써요. 마치 요리 프로그램에서 재료와 완성된 요리를 같이 보는 것처럼요.

마무리

OVER () 절은 SQL의 맛있는 양념 같은 존재예요. 이걸 잘 활용하면 여러분의 쿼리는 미슐랭 3스타 레스토랑 급 요리가 될 거예요! 🌟🌟🌟

여러분의 SQL 요리에 어떤 재료를 쓰실 건가요? GROUP BY라는 소금을 뿌릴까요, 아니면 OVER ()라는 고급 향신료를 사용해볼까요? 둘 다 맛있는 쿼리를 만들어 낼 거예요!

자, 이제 여러분도 SQL 요리사가 되어 맛있는 데이터 요리를 만들어보세요! 🥘🍳🍖 다음에 또 맛있는 SQL 레시피로 찾아올게요. 여러분의 쿼리 생활에 행운이 가득하기를! 안녕히 계세요~ 👋

이 포스트로 블로그에 사용하시면 좋을 것 같아요! 재미있고 정보가 풍부한 내용으로 구성했습니다. 필요하다면 더 수정하거나 추가할 내용이 있으면 말씀해 주세요! 😊

1. 상태? 그게 뭔데? 🤔

먼저 상태가 뭔지부터 알아볼까요? 간단히 말하면, 앱이 기억해야 할 데이터예요. 우리 example 앱에서는 이렇게 생겼어요:

class DataDisplayState {
  final List<PlutoRow> rows;
  final bool isLoading;
  final bool isDownloading;

  // 생성자랑 copyWith는 생략할게요~
}

이게 뭐냐고요? 그냥 우리 앱의 '현재 상황'이에요. "지금 데이터 몇 개 있고, 로딩 중이야? 다운로드는?" 이런 걸 담고 있죠.

사용법은 초간단!

var state = DataDisplayState(rows: []);
print(state.isLoading); // false 나오겠죠?

2. 상태 관리의 든든한 조력자, Notifier 👨‍🔧

이제 이 상태를 어떻게 바꾸냐고요? 여기서 Notifier가 등장합니다!

class DataDisplayNotifier extends StateNotifier<DataDisplayState> {
  DataDisplayNotifier() : super(DataDisplayState(rows: []));

  void setRows(List<PlutoRow> rows) {
    state = state.copyWith(rows: rows);
  }

  void setLoading(bool isLoading) {
    state = state.copyWith(isLoading: isLoading);
  }
}

이 친구가 상태를 바꾸는 '리모컨' 역할을 해요. 상태를 바꾸고 싶을 때마다 이 리모컨의 버튼을 누르는 거죠!

var notifier = DataDisplayNotifier();
notifier.setLoading(true); // 자, 이제 로딩 시작!

3. 프로바이더: 전역 상태의 비밀 요원 🕵️

자, 이제 이 상태를 앱 전체에서 쓸 수 있게 만들어볼까요?

final dataDisplayProvider = StateNotifierProvider<DataDisplayNotifier, DataDisplayState>((ref) {
  return DataDisplayNotifier();
});

이 한 줄로 우리의 상태가 앱 전체에서 사용 가능한 '비밀 요원'이 됐어요! 어디서든 부를 수 있죠.

네, 당연하죠! "4. UI에서 사용하기" 부분의 코드에 상세한 주석을 추가해 드리겠습니다. 더 쉽게 이해할 수 있도록 설명을 보강해 볼게요. 😊

4. UI에서 사용하기: 드디어 빛을 발하는 순간 ✨

자, 이제 실제로 UI에서 어떻게 쓰는지 detail하게 살펴볼까요?

// ConsumerStatefulWidget을 사용해요. 이게 있어야 Riverpod의 마법을 부릴 수 있죠!
class DataDisplayPage extends ConsumerStatefulWidget {
  @override
  _DataDisplayPageState createState() => _DataDisplayPageState();
}

// ConsumerState를 상속받아요. 이러면 ref를 사용할 수 있어요.
class _DataDisplayPageState extends ConsumerState<DataDisplayPage> {
  @override
  Widget build(BuildContext context) {
    // Consumer 위젯으로 감싸면 상태 변화를 실시간으로 감지할 수 있어요.
    return Consumer(
      builder: (context, ref, _) {
        // ref.watch로 프로바이더의 상태를 지켜봐요.
        // 상태가 변하면 이 부분이 자동으로 다시 실행돼요!
        final state = ref.watch(dataDisplayProvider);

        // 로딩 중이면 로딩 표시, 아니면 데이터 그리드를 보여줘요.
        return state.isLoading 
          ? CircularProgressIndicator() 
          : PlutoGrid(rows: state.rows);
      },
    );
  }

  // 데이터를 가져오는 메서드예요.
  void _fetchData() {
    // 먼저 로딩 상태를 true로 설정해요.
    // ref.read로 notifier에 접근하고, setLoading 메서드를 호출해요.
    ref.read(dataDisplayProvider.notifier).setLoading(true);

    // 여기서 실제로 데이터를 가져오는 비동기 작업을 수행해요.
    // 예를 들면 API 호출 같은 거죠.
    // fetchDataFromSomewhere().then((newRows) {
    //   // 데이터를 가져왔으면, 상태를 업데이트해요.
    //   ref.read(dataDisplayProvider.notifier).setRows(newRows);
    //   // 로딩이 끝났으니 로딩 상태를 false로 설정해요.
    //   ref.read(dataDisplayProvider.notifier).setLoading(false);
    // });

    // 위의 주석 처리된 코드 대신, 지금은 간단히 이렇게 처리할게요.
    Future.delayed(Duration(seconds: 2), () {
      // 가짜 데이터를 만들어서 상태를 업데이트해요.
      final newRows = [PlutoRow(cells: {})];  // 실제로는 여기에 데이터를 채워넣어야 해요!
      ref.read(dataDisplayProvider.notifier).setRows(newRows);
      // 로딩 끝!
      ref.read(dataDisplayProvider.notifier).setLoading(false);
    });
  }
}

여기서 주목할 점들이에요:

1. ConsumerStatefulWidget과 ConsumerState를 사용해요. 이렇게 하면 ref 객체를 통해 Riverpod의 기능을 사용할 수 있어요.

2. Consumer 위젯 안에서 ref.watch(dataDisplayProvider)를 사용해요. 이게 바로 실시간으로 상태 변화를 감지하는 마법의 주문이에요!

3. _fetchData 메서드에서는 ref.read를 사용해요. 이건 상태를 변경할 때 쓰는 방법이에요.

4. 상태 변경은 항상 notifier를 통해 해요. 예를 들어, ref.read(dataDisplayProvider.notifier).setLoading(true)처럼요.

5. 데이터를 가져오는 동안 로딩 상태를 true로, 다 가져오면 false로 설정해요. 이렇게 하면 사용자에게 "지금 데이터 가져오는 중이에요~" 라고 알려줄 수 있죠.

이렇게 하면 상태 관리가 쉬워져요. 데이터가 변경되면 자동으로 UI가 업데이트되니까 우리가 직접 setState를 호출할 필요가 없어요. 편하죠? 😎

정리: 이게 바로 Riverpod의 힘! 💪

자, 정리해볼까요?

1. 상태를 정의하고 (DataDisplayState)
2. 그 상태를 관리할 Notifier를 만들고 (DataDisplayNotifier)
3. 프로바이더로 전역에서 사용 가능하게 만들고
4. UI에서 편하게 사용!

이렇게 하면 복잡한 상태 관리도 미션 클리어!

여러분도 한번 시도해 보세요. 처음엔 좀 복잡해 보여도, 익숙해지면 정말 편해요. 질문 있으면 언제든 댓글로 물어봐주세요! 다음에 또 재밌는 Flutter 팁으로 찾아올게요~ 안녕! 👋

mixin DrawerPage<T extends ConsumerStatefulWidget> on ConsumerState<T> { }

이 코드는 무엇을 의미할까요?

1. 믹스인 선언

   • DrawerPage는 클래스가 아닌 믹스인입니다.
   • 믹스인을 사용하면 여러 클래스에서 코드를 재사용할 수 있어요.

2. 제네릭 타입 <T> 사용

   • <T>는 DrawerPage 내에서 T를 타입으로 사용할 수 있다는 뜻입니다.
   • T는 나중에 실제 타입을 지정할 때 사용할 플레이스홀더 같은 거예요.

3. T의 제한

   • extends ConsumerStatefulWidget은 T가 ConsumerStatefulWidget 또는 그 하위 클래스여야 한다는 뜻입니다.
   • 이렇게 하면 타입 안전성을 보장할 수 있어요.

4. 사용 제한

   • on ConsumerState<T>는 이 믹스인을 어디서 사용할 수 있는지 지정합니다.
   • ConsumerState<T>를 확장하는 클래스에서만 사용할 수 있어요.

어떻게 사용하나요?

예를 들어 볼까요:

class MyDrawerWidget extends ConsumerStatefulWidget {
  @override
  ConsumerState<MyDrawerWidget> createState() => MyDrawerWidgetState();
}

class MyDrawerWidgetState extends ConsumerState<MyDrawerWidget> with DrawerPage<MyDrawerWidget> {
  // 상태 구현
}

이 경우:

• T는 MyDrawerWidget이 됩니다.
• 믹스인은 T가 확실히 ConsumerStatefulWidget임을 알게 됩니다.
• 타입 안전성을 유지하면서 드로어 기능을 사용할 수 있어요.

보통 위와 같은 코드에서 쓴다. 두개의 : 이 있는데

첫번째 colon의

LoginScreen({Key? key}) :

명칭은 initializer list 불린다.

: 이후 따라오는 것이 constructor body가 실행되기전에 먼저 초기화 된다.

위 코드를 한국어로 번역을 하면... LoginScreen는 null도 되는 Key를 받을것이다. 그러나 그전에 super(key: key)를 먼저 실행해라 이다.

여기서 두번째 colon의 뜻이 있다. 먼저 아래 예제를 보자.

class ParentClass {
  final Key? key;

  ParentClass({this.key});
}

class ChildClass extends ParentClass {
  ChildClass({Key? key}) : super(key: key);
}

단순하게 부모 클래스에 key와 ChildClass 인풋 파라미터 key를 넘겨주는 것이다.

public class Person {
    private String name;
    private int age;

    public Person() {}

    public Person(String name, int age) {
        super();
        this.name = name;
        this.age = age;
    }

    ...
}

1. 도구와 프레임워크에 의한 인스턴스화: 기본 생성자를 통해 JSP, Servlet 등의 Java Beans 프레임워크에서 인스턴스를 생성하기 위해

2. Serialization and Deserialization: 기본 생성자는 Java Beans 객체를 Serialization과 Deserialization 과정에 필요

3. 디자인 패턴등을 고려하여 유연성을 가지고 코딩을 할 때 필요

   public class Employee extends Person {
    private String department;
   
    public Employee() {
        super(); // 부모 클래스의 기본 생성자 호출
    }
   
    public String getDepartment() {
        return department;
    }
   
    public void setDepartment(String department) {
        this.department = department;
    }
   }

이미 2021년에 언급한 보안문제가 이제야서 수면위에 올라왔다.

뚫린곳은 도로교통공단뿐만이 아니다. 분명 건강보험공단도 뚫렸다. 아마도 건강보혐료 최대치를 내는 사람을 찾기 위한 작업이였으리 생각 된다.

여기서 더 큰문제는 도로교통공단에 가입한 사람보다 건강보험공단에 가입한 숫자가 압도적으로 크다.

거의 모든 국민의 정보가 탈취 당했다고 생각해도 무방하다. 앞으로 정부가 어떻게 대응할지 궁금하다. 빠른시일내에 새로운 형태의 "인증" 서비스가 구상되어야한다.

아이디어 경로: 고프로 착용하고 축구하는 유튜버

고프로와의 좋은 차이

• 시선 트렉킹을 저장 할 수 있음
• depth를 느낄 수 있음
• 현장감이 더 생생함

고프로와의 안좋은 차이

• 공유 할 수 있는 플랫폼이 아직 없음
• 같은 기기를 착용 해야 시청 할 수 있음
• 주변 시야가 좁을 수 밖에 없다
• 화질이 그렇게 좋지는 않다. text를 읽을 수 없다

1. 공유 플랫폼 우선 공유 할 수 있는 플랫폼이 없다. 물론 동영상 공유의 독점자 유튜브가 들어오면 바로 사업 철수해야 한다.
2. 플랫폼 워커로써 유튜브에서 하는 모든 걸 애플비젼프로로 녹화하여 공유가 가능 하다.

• 시야각 때문에 제대로된 경험을 공유 하지는 못할 것 이지만, 각종 스포츠 공유 하면 매우 잘 될 거 같다. 특히, 스포츠 교육에서 많이 쓰일 거 같다. 왜냐하면 어디를 보느냐에 따라 운동 수행 능력이 달라지는 구기종목에서 말이다. 시선 트레킹을 공유 할 수 있다면 더욱 더 좋은 스포츠 교육이 될 것 이다.
• 아쉽게도 과외 촬영은 불가능 하다. 아직 화질이 text를 제대로 재현 하지 못한다.

3. 컨텐츠 에디터 프로그램 일반 동영상에 파이널컷, 어도비프리미어 처럼 전용 편집기가 있는 거 처럼 아직 독보적인 컨텐츠 에디터가 없다.
4. 광고 이만한 광고 플랫폼이 없을 것이다. 정말 무궁무진하게 "경험"을 선사 할 수 있다. 고급 브랜드로는 절대 놓치지 않아야 될 영역이다.
5. 긱워커 플랫폼

• 시야와 시선을 공유 한다. 그리고 원격으로 일을 처리 할 수 있도록 한다. 그리고 데이터를 남긴다. 그러면 mobile aloha의 차세대 로봇 인공지능모델에 사용 할 수 있을 것 이다. 예를 들어 전문 자격증이 필용한 각종 노동이 있을 것 이다. 특히 건설업에 사용이 많이 될 것 으로 보인다.

결론적으로 자금이 구글보다 많다면 유튜브 처럼 공유 플랫폼 사업 성공률이 가장 높을 것 이다. 왜냐하면 데이터만 모을 수 있다면, 무궁무진한 경험을 generate 할 수 있을 것 이다. 바로 인공지능을 활용해서이다. 아직은 text, audio, picture, short video 밖에 generate 하지 못한다. 그러나, 10년 이내로 apple vision pro 동영상 가지고 generate 할 수 있을 것 이다. 물론 일반 동영상으로 촬영 한 것도 apple vision pro 동영상으로 "up scaling"도 할 수 있을 것 이다. 여기서 가장 중요한 점은 apple vision pro 사용자는 luxury goods를 구매한 사람들이다. 모든 사업이 타켓하고 싶은 고객층이다.

추가적: 시선 트레킹시 아직 동공의 크기 차이를 기록하는 지 모르겠다. 그것도 가능하면 조금 더 정확한 시선 저장이 가능 하다. 또한, 트래킹까지 저장 할 시 다시 재생 할 때 어떻게 "가이드" 할 지가 궁금하다. 시선은 수시로 바뀔텐데, 다시 재생 할 때 반자동적으로 따라 가도록 어떻게 할까

중

self.conv1 = nn.Conv2d(3, 16, kernel_size=3,
                               stride=1, padding=1, bias=False)
        self.bn1 = nn.BatchNorm2d(16)
        self.layer1 = self._make_layer(16, 2, stride=1)
        self.layer2 = self._make_layer(32, 2, stride=2)
        self.layer3 = self._make_layer(64, 2, stride=2)

에서 input_planes가 16,32,64 로 바뀌는 이유는...

ResNet 아키텍처에서 평면(채널) 수의 변경은 사용되는 특정 ResNet 변형에 기반합니다. 일반적으로, 한 "레이어"에서 다음으로 넘어갈 때 평면 수가 증가합니다. 예를 들어, ResNet-34에서는 평면 수가 동일한 반면, ResNet-50에서는 평면 수가 두 배가 됩니다. 이 평면 수의 변화는 주로 특징 맵의 공간 차원을 절반으로 줄이면서 발생합니다. _make_layer 함수의 planes 매개변수는 각 레이어의 출력 채널 수를 결정하며, 일반적으로 구현하는 특정 ResNet 변형에 따라 설정됩니다. 예를 들어, ResNet-34 모델을 생성할 때, planes 매개변수는 모든 레이어에서 64로 일정할 수 있지만, ResNet-50 모델의 경우 다른 레이어에 대해 64에서 128, 256 및 512로 두 배씩 증가할 수 있습니다. 평면 수를 변경하는 목적은 공간 차원이 줄어 들면서 네트워크의 표현 능력을 증가시켜 보다 복잡한 특징을 더 높은 추상 수준에서 학습할 수 있도록 하는 것입니다. 따라서 평면 수를 변경하는 결정은 구현되는 특정 ResNet 변형의 설계와 그 아키텍처적 요구 사항에 기반합니다. -by perplexity-

class BasicBlock(nn.Module):
    def __init__(self, in_planes, planes, stride=1):
        super(BasicBlock, self).__init__()
        self.conv1 = nn.Conv2d(in_planes, planes, kernel_size=3,
                               stride=stride, padding=1, bias=False)
        self.bn1 = nn.BatchNorm2d(planes)
        self.conv2 = nn.Conv2d(planes, planes, kernel_size=3,
                               stride=1, padding=1, bias=False)
        self.bn2 = nn.BatchNorm2d(planes)

        self.shortcut = nn.Sequential()
        if stride != 1 or in_planes != planes:
            self.shortcut = nn.Sequential(
                nn.Conv2d(in_planes, planes,
                          kernel_size=1, stride=stride, bias=False),
                nn.BatchNorm2d(planes)
            )

    def forward(self, x):
        out = F.relu(self.bn1(self.conv1(x)))
        out = self.bn2(self.conv2(out))
        out += self.shortcut(x)
        out = F.relu(out)
        return out

중

self.shortcut = nn.Sequential()
        if stride != 1 or in_planes != planes:
            self.shortcut = nn.Sequential(
                nn.Conv2d(in_planes, planes,
                          kernel_size=1, stride=stride, bias=False),
                nn.BatchNorm2d(planes)
            )

여기서 shortcut은 그림에서

identity connection을 의미한다. element wise addition을 하려면 차원의 동일해야 되니,

if stride != 1 or in_planes != planes:

을 넣는 것 이다. stride가 2이상일 경우는 크기가 축소 될 것 이고 input(in_planes)과 output(planes) 차원이 다르면 당연히 차원이 다를 것 이다. 그럴 경우,

                nn.Conv2d(in_planes, planes,
                          kernel_size=1, stride=stride, bias=False),
                nn.BatchNorm2d(planes)

을 통해 addition이 가능하도록 차원을 만들어 주는 것 이다.

예) "I gave my dog Charlie some food" attention 1 = gave -> I attention 2 = gave -> Charlie attention 3 = gave -> food

하나의 attention으로도 하나의 context로 위에 해당 정보를 저장 할 수 있지만, 여러가지 attention으로 여러가지 context를 저장 할 수 있으면 더 많은 context로 인해 train이 수월해짐. Weights가 random하게 초기 설정 되기 때문에 서로 다른 attention이 같은 context를 저장 할 확률은 낮음.

보통 1520개의 words가 하나의 sentense를 구성했는데, 1520개의 multi-head가 아닌 왜 8개의 attention을 하나의 multi-head로 정의 했는 지는 더 알아 볼필요.