Try to Remember RSS Feed

Hermes Agent — 자기 학습하는 오픈소스 AI 에이전트

Sat, 18 Apr 2026 00:00:00 GMT

얼마 전 GitHub 트렌딩에서 Hermes Agent라는 저장소를 발견했다. Nous Research라는 이름은 파인튜닝 커뮤니티에서 꽤 오래 들어왔던 곳이라 눈길이 갔다. 훑어보니 단순한 챗봇 래퍼가 아니라 “작업을 마치고 나서 스스로 스킬을 문서화한다”는 구조가 흥미로웠다. 맥미니 M4 8GB에 직접 올려봤다.

Nous Research와 Hermes 모델 계보

Nous Research는 오픈소스 AI 연구소다. 기업 규모는 크지 않지만 Hermes 파인튜닝 시리즈로 커뮤니티에서 이름을 알렸다. Tool calling, 함수 호출, 구조화된 출력에 특화된 파인튜닝이 주력이고, Atropos(RL 프레임워크), DisTrO(분산 학습) 같은 연구도 함께 진행한다.

Hermes Agent는 2026년 2월에 오픈소스로 공개됐다. 이름에서 알 수 있듯 Hermes 모델 계보 위에서 동작하는 자율 에이전트 프레임워크다. Telegram, Discord, Slack, WhatsApp 같은 메시징 플랫폼에 연결해 두면, 메시지를 받아 계획을 세우고, 웹 검색·코드 실행·파일 관리 등을 수행한다. 단순 작업 실행기와 다른 점은 **닫힌 학습 루프(closed learning loop)**다 — 복잡한 작업을 끝내고 나면 에이전트가 그 과정에서 발견한 절차, 함정, 검증 단계를 스킬 문서로 정리한다. 다음에 비슷한 작업이 오면 처음부터 추론하지 않고 저장된 스킬을 불러와 시작한다.

핵심 아키텍처

닫힌 학습 루프 (Closed Learning Loop)

일반 에이전트는 선형 구조다.

Task → Plan → Execute → Result → [끝]

Hermes는 폐루프 구조다.

Task → Plan → Execute → Result
                           ↓
                      Evaluate
                           ↓
                    Write/Update Skill
                           ↓
                    Store in Memory
                           ↓
              Next similar Task → [스킬 재사용]

실행 결과가 다음 실행의 입력이 된다. 루프가 닫혀 있다는 표현이 정확하다.

자율 스킬 생성

복잡한 작업(tool call 5회 이상)이 완료되면 에이전트가 스스로 스킬 문서를 작성한다. 문서에는 태스크를 어떻게 분해했는지, 어떤 순서로 도구를 호출했는지, 어디서 실패했고 어떻게 우회했는지, 검증 단계는 무엇인지가 담긴다. 다음에 유사 작업이 들어오면 이 문서를 먼저 로드해 처음부터 탐색하지 않는다.

스킬 자기 개선

스킬은 한 번 쓰고 끝이 아니다. 사용할 때마다 결과를 비교해 업데이트한다.

기존 스킬 실행
     ↓
결과 비교 (신규 접근법 vs 기존 절차)
     ↓
신규 접근법이 더 나은가?
  ├── Yes → 스킬 문서 갱신
  └── No  → 기존 유지, 실패 케이스 주석 추가

예를 들어 처음엔 뉴스 API를 직접 호출하는 방식으로 스킬이 만들어졌다가, 나중에 캐싱 방법이 발견되면 스킬이 캐싱 버전으로 교체된다.

계층형 메모리 스택

메모리는 네 계층으로 분리된다.

계층	내용	형태
영구 노트	에이전트가 curate한 핵심 사실	Markdown
세션 히스토리	전체 대화 기록	SQLite + FTS5 전문 검색
사용자 모델	선호·패턴·결정 이력	Honcho DB
프로시저 메모리	스킬 라이브러리	Markdown 디렉토리

핫/콜드 계층 분리 덕분에 매 턴마다 전체 기억을 컨텍스트에 욱여넣지 않고 관련된 것만 선택적으로 로드한다. 8GB 환경에서도 토큰 낭비가 줄어드는 이유다.

Honcho 변증법 사용자 모델링

단순히 “사용자가 이런 말 했음”을 기록하는 게 아니라, 대화를 통해 사용자 모델을 능동적으로 검증한다. 에이전트가 내부적으로 “이 사람은 이런 패턴을 선호할 것”이라는 가정을 세우고, 이후 결과에 대한 피드백을 받으면 맞으면 강화하고 틀리면 수정한다. 세션이 쌓일수록 “이 사람이 왜 이런 질문을 하는가”를 더 잘 예측하게 된다.

Nous Search

Hermes Agent의 검색 백엔드는 일반 웹 검색이 아니라 Nous Research가 자체 개발한 Nous Search를 사용한다. 일반 검색 결과보다 AI/기술 도메인에 특화된 결과를 반환하고, 에이전트 파이프라인에서 쓰기 좋은 구조화된 포맷으로 응답이 온다. API 키가 있으면 연동하고, 없으면 DuckDuckGo fallback으로 동작한다.

맥미니 M4 8GB에서 설치

내 환경은 맥미니 M4 기본형이다.

모델: Mac mini (Late 2024)
칩:   Apple M4 (10-core CPU, 10-core GPU)
메모리: 8GB 통합 메모리
저장장치: 256GB SSD
OS: macOS Sequoia 15.4

Ollama 공식 연동 활용

Hermes Agent는 Ollama 공식 통합 문서를 통해 공식 연동을 지원한다. 별도로 저장소를 클론하거나 가상환경을 직접 세팅하지 않고 인스톨 스크립트 한 줄로 시작할 수 있다.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

설치가 끝나면 설정 마법사가 자동으로 실행된다. “More providers…” → “Custom endpoint”를 선택하고 Ollama 주소를 입력한다.

Provider: Custom endpoint
API Base URL: http://127.0.0.1:11434/v1
API Key: (공란)

API 키 없이 로컬 모델에 바로 연결된다. Ollama가 실행 중이면 연결 가능한 모델 목록을 자동으로 감지해 보여준다.

수동으로 설치하는 경우 Python 3.11이 필요하다. pyenv로 버전을 맞추는 게 안전하다.

pyenv install 3.11.9
pyenv local 3.11.9
git clone https://github.com/NousResearch/hermes-agent
cd hermes-agent
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

설치 중 aiohttp, honcho-ai, duckduckgo-search 같은 패키지들이 줄줄이 딸려온다. 전체 설치 시간은 약 2분 정도였다.

모델 선택: 8GB 안에서 최대한

8GB 통합 메모리에서 LLM을 돌리면 OS와 에이전트 프로세스 오버헤드를 빼면 실질적으로 모델에 쓸 수 있는 메모리는 5~6GB 수준이다. Hermes Agent는 OpenAI 호환 엔드포인트를 쓰면 모델을 자유롭게 선택할 수 있다.

Ollama 공식 문서의 권장 모델은 gemma4(~16GB)와 qwen3.5(~11GB)인데, 둘 다 8GB에서는 동작하지 않는다.

모델	필요 메모리	8GB M4 적합 여부
gemma4	~16GB	불가
qwen3.5	~11GB	불가
hermes3:8b-llama3.1-q4_K_M	~4.9GB	가능
qwen2.5:7b-instruct-q4_K_M	~4.7GB	가능

8GB 환경에서는 아래 두 가지가 현실적인 선택지다.

ollama pull hermes3:8b-llama3.1-q4_K_M      # 약 4.9GB, Hermes 계보 tool-calling 최적화
ollama pull qwen2.5:7b-instruct-q4_K_M  # 약 4.7GB, 안정적인 대안

처음엔 hermes3:8b를 시도했다. 같은 Hermes 계보라 도구 호출 포맷 호환성이 좋을 것 같았다.

ollama serve &

서버가 뜨면 에이전트 설정 파일을 만든다.

cp .env.example .env

.env를 열어 핵심 항목들을 채운다.

# 로컬 Ollama 엔드포인트
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollama
MODEL_NAME=hermes3:8b-llama3.1-q4_K_M

# Telegram 봇 (선택)
TELEGRAM_BOT_TOKEN=your_bot_token_here

# Nous Search (없으면 DuckDuckGo fallback)
# NOUS_SEARCH_API_KEY=

# 메모리 저장 경로
MEMORY_PATH=./memory

설정이 끝나면 에이전트를 실행한다.

python main.py

처음 실행하면 memory/ 디렉토리가 생성되고 SQLite DB가 초기화된다.

[INFO] Initializing Hermes Agent...
[INFO] Memory backend: SQLite (./memory/agent.db)
[INFO] Skill store: ./memory/skills/
[INFO] Model: hermes3:8b-llama3.1-q4_K_M via http://localhost:11434/v1
[INFO] No Telegram token found. Running in CLI mode.
[INFO] Ready.

CLI 모드로 바로 테스트할 수 있다.

>>> 최근 Llama 4 관련 뉴스를 찾아서 요약해줘

[TOOL] web_search("Llama 4 release 2026")
[TOOL] web_search("Llama 4 benchmark results")
[RESULT] 검색 완료 (DuckDuckGo fallback)

Llama 4는 Meta가 2026년 초에 공개한 모델로...
(요약 내용)

[SKILL] 작업 유형 'news_summary'에 대한 스킬 문서를 작성합니다.
[SKILL] ./memory/skills/news_summary_001.md 저장 완료

처음 실행에서 바로 스킬 문서가 생성되는 걸 확인했다. memory/skills/ 폴더를 열어보면 Markdown 파일이 저장돼 있다.

# Skill: news_summary

## 개요

특정 주제의 최신 뉴스를 검색하고 구조화된 요약을 작성하는 절차

## 절차

1. 주제 키워드 추출
2. "{주제} release {year}" 형식의 검색 쿼리 생성
3. 검색 결과 상위 5개 파싱
4. 날짜 순 정렬 후 최신 3~5개 선택
5. 출처 링크 포함한 요약 작성

## 주의사항

- DuckDuckGo는 최근 24시간 내 결과가 부정확할 수 있음
- 날짜 확인 필수

## 검증

- 날짜가 현재 기준으로 최근인지 확인
- 출처가 신뢰할 수 있는 도메인인지 확인

에이전트가 직접 작성한 문서다. 사람이 쓴 것처럼 자연스럽지는 않지만, 다음에 같은 유형의 작업이 들어오면 이 문서를 참고해 시작점을 높인다.

두 번째 실행: 스킬 재사용 확인

같은 세션에서 비슷한 요청을 다시 넣어봤다.

>>> Claude 4 관련 최근 소식 정리해줘

[SKILL] 'news_summary' 스킬 발견. 절차를 참고합니다.
[TOOL] web_search("Claude 4 release 2026")
[TOOL] web_search("Claude 4 benchmark 2026")
...

도구 호출 순서가 첫 번째와 달라졌다. 스킬 문서에 적힌 절차를 따라 쿼리 패턴도 비슷해졌다. 완전히 새로운 추론을 하는 것보다 응답 시간이 체감상 빨랐다.

메모리 상태 확인

에이전트 내장 명령으로 현재 상태를 볼 수 있다.

>>> /memory status

[메모리 상태]
영구 노트: 3개
세션 히스토리: 14개 항목
스킬 문서: 2개
DB 크기: 0.2MB

>>> /skills list

[저장된 스킬]
1. news_summary_001.md — 뉴스 요약 절차
2. code_review_001.md — 코드 리뷰 체크리스트

아직 두 번밖에 안 썼는데 이미 두 개의 스킬이 쌓였다. 오래 쓸수록 에이전트가 점점 자신의 노하우를 축적해 간다는 느낌이 든다.

8GB 메모리 환경의 한계

솔직히 말하면 8GB에서 로컬 LLM으로 에이전트를 돌리는 건 타협이 많다. hermes3:8b는 도구 호출 포맷을 잘 따르고 스킬 문서도 나름 잘 작성하지만, 복잡한 멀티스텝 추론에서는 자주 길을 잃는다. 도구를 두 번, 세 번 연달아 써야 하는 작업에서 중간에 계획을 잊어버리는 경우가 있었다.

해결책은 두 가지다.

첫 번째는 클라우드 API를 붙이는 것이다. .env의 OPENAI_BASE_URL을 실제 OpenAI나 Anthropic 엔드포인트로 바꾸면 된다.

OPENAI_BASE_URL=https://api.anthropic.com/v1
OPENAI_API_KEY=sk-ant-...
MODEL_NAME=claude-haiku-4-5-20251001

Claude Haiku는 속도와 비용 균형이 좋아서 에이전트처럼 도구 호출이 많은 용도에 잘 맞는다. 로컬에서는 메모리·스킬을 관리하고, 추론은 클라우드에 맡기는 하이브리드 구성이다.

두 번째는 모델을 더 작게 줄이는 것이다. Qwen 2.5 7B는 4.7GB라 macOS 시스템 영역과 에이전트 프로세스까지 합쳐도 8GB 안에 들어간다. hermes3:8b보다 도구 호출 품질이 조금 떨어지지만 안정적으로 돌아간다.

OpenClaw와 뭐가 다른가

지난번에 OpenClaw를 맥미니에 세팅하고 써봤는데, 비교해보면 지향점이 꽤 다르다.

항목	Hermes Agent	OpenClaw
핵심 콘셉트	자기 개선하는 에이전트	로컬 LLM 추론 엔진
학습 루프	자율 스킬 생성·재사용	없음 (매 작업 fresh start)
플랫폼 연결	Telegram, Discord, Slack 등	없음 (API 서버)
메모리	계층형 (영구/세션/스킬)	없음
보안	프롬프트 인젝션 스캐닝 내장	해당 없음
성숙도	초기 (2026.02~)	안정적

OpenClaw는 “어떤 모델이든 빠르게 로컬에서 서빙”에 집중한다. API 서버를 띄우고 다른 도구들과 연결하는 인프라 역할이다. Hermes Agent는 그 위에 앉아서 실제로 작업을 수행하고 기억을 쌓는 에이전트 레이어다. 둘은 경쟁 관계라기보다 보완 관계에 가깝다 — OpenClaw로 모델을 서빙하고, Hermes Agent를 그 위에 얹는 구성이 가능하다.

생태계 면에서는 OpenClaw가 ClawHub(44,000+ 스킬)를 갖고 있어 훨씬 성숙하다. Hermes Agent의 agentskills.io는 아직 초기라 공유 스킬 수가 적다. 반면 Hermes Agent는 에이전트가 스스로 스킬을 만들기 때문에 공유 생태계 의존도가 낮다는 특징이 있다.

마치며

Hermes Agent에서 인상 깊었던 건 “에이전트가 자신의 경험을 문서화한다”는 발상이다. 사람도 반복 작업을 하다 보면 자기만의 체크리스트를 만들게 되는데, 에이전트에 그걸 자동화한 셈이다. 오래 쓸수록 점점 내 작업 패턴에 최적화된다는 기대가 생긴다.

8GB 맥미니에서는 로컬 모델만으로는 아직 한계가 있다. 에이전트 프레임워크 자체는 훌륭한데, 작은 모델이 복잡한 멀티스텝 계획을 따라가지 못하는 경우가 있어서 클라우드 API를 붙이는 게 현실적이다. 메모리와 스킬은 로컬에 쌓이니 프라이버시 걱정 없이 하이브리드로 쓸 수 있다.

OpenClaw와 비교하면 성숙도는 아직 떨어지지만, “작업할수록 나아지는 에이전트”라는 방향성 자체가 흥미롭다. Nous Research가 오픈소스 생태계에서 꾸준히 임팩트를 내온 곳이기도 해서 앞으로의 발전이 기대된다. 당장 일상 업무에 쓰기에는 좀 더 다듬어져야 할 것 같지만, 지켜볼 만한 프로젝트다.

References

프로젝트 하일메리

Wed, 08 Apr 2026 00:00:00 GMT

SF 영화를 좋아한다. 넷플릭스 삼체를 정주행한 후로 시즌2만 기다리고 있는 입장인데, 요즘 주변에서 하일메리 얘기를 워낙 많이 들어서 4월 8일 퇴근길에 혼자 극장을 찾았다.

기대 이상이었다

솔직히 반신반의하며 들어갔다. 그런데 나오면서 이건 좀 다르다는 생각이 들었다.

스토리, 유머, 음악. 셋 다 내 스타일이었다. 특히 록키와의 첫 만남과 그 이후 서로를 이해해 나가는 과정이 웃기면서도 감동적이다. 언어도 생물학적 구조도 전혀 다른 두 존재가 조금씩 소통을 만들어 가는 장면이 영화 내내 가장 인상 깊었다.

라이언 고슬링이 연기한 라일랜드 그레이스는 혼자 우주 한복판에 있으면서도 유머를 잃지 않는다. 그게 억지스럽지 않고 자연스러운데, 덕분에 무거운 설정 위에서도 영화가 숨을 쉰다.

마치며

간만에 극장에서 진짜 재미있는 영화를 봤다. 집에 오는 내내 머릿속에 록키가 맴돌았다. SF를 좋아하는 사람이라면 아직 상영 중일 때 꼭 보길 추천한다.

삼체 시즌2가 언제 나오든, 그 기다림의 공백을 하일메리가 꽤 잘 채워줬다.

강철의 연금술사 정주행 완료

Fri, 20 Mar 2026 00:00:00 GMT

우리 딸이 자기 최애라며 한번 꼭 보라고 강력 추천을 해서 보게 됐다. 아이가 그렇게까지 좋아하는 작품이라면 뭔가 있겠지 싶어 일단 틀었다.

오리지널과 브라더후드

먼저 2003년 오리지널 시리즈부터 봤는데, 솔직히 잘 이해가 안 됐다. 중반부터 이야기가 원작 망가와 다른 방향으로 흘러가면서 결말이 다소 뜬구름 잡는 느낌이었다. “이게 왜 명작이라는 거지?” 하는 의문이 살짝 들기도 했다.

그런데 브라더후드를 보니 완전히 달랐다. 왜 다들 결말이 탄탄하다고 하는지, 왜 수십 년이 지나도 회자되는지 바로 이해가 됐다. 복선 하나하나가 다 회수되고, 각 캐릭터의 서사가 제자리를 찾아간다. 구성력이 정말 대단하다.

정답이다, 연금술사

스포일러가 될 수 있으니 자세히는 못 쓰겠지만, 결국 이 이야기가 말하고자 하는 건 단순하면서도 묵직하다. 온갖 것을 포기하고 먼 길을 돌아 도달한 답이 “나 자신”이라는 것. 화려한 설정과 세계관 속에서 결국 인간에 대한 이야기를 하고 있다.

마지막에 나오는 “정답이다, 연금술사” 라는 대사는 꽤 오래 머릿속에 남는다. 짧지만 64화 내내 쌓아온 무게가 그 한 마디에 담겨 있다.

내 생각

개인적으로 가장 감동적이었던 장면은 따로 있다. 아버지가 아내의 무덤 앞에서 자신의 삶을 회고하는 장면인데, 거창한 클라이맥스가 아닌 그 조용한 장면이 오히려 더 마음에 남았다. 오래 살아온 사람만이 할 수 있는 말들이 있더라.

딸에게 고맙다. 덕분에 좋은 작품 봤다.

Context Hub vs Context7: 코딩 에이전트에게 최신 문서를 주는 두 가지 방법

Sat, 14 Mar 2026 00:00:00 GMT

AI 코딩 에이전트를 쓰다 보면 반드시 부딪히는 문제가 있다. 에이전트가 이미 deprecated된 API를 자신 있게 쓰거나, 존재하지 않는 파라미터를 만들어낸다. 학습 데이터에 최신 내용이 없으니 당연한 일이다. 이 문제를 해결하려는 두 가지 도구를 최근 핸즈온해봤다. Andrew Ng 팀이 만든 Context Hub와 Upstash가 만든 Context7이다.

무엇을 해결하려는 도구인가

두 도구 모두 같은 문제를 해결하려 한다. LLM의 학습 데이터 컷오프와 현실 사이의 간극이다.

예를 들어 Claude Sonnet 4.6은 2025년 8월까지 학습됐다. OpenAI API의 최신 responses API, 최신 버전 Anthropic SDK의 변경 사항 같은 건 모를 수 있다. 그래서 에이전트에게 “OpenAI API로 GPT-5 호출 코드 짜줘”라고 하면 낡은 client.chat.completions.create 방식을 쓸 수 있다.

이 공백을 채우는 방식이 두 도구에서 다르다.

Context7 — MCP 서버 방식

Context7은 MCP(Model Context Protocol) 서버다. AI 코딩 에디터(Cursor, Claude Code 등)에 MCP 서버로 등록해두면, 에이전트가 문서가 필요할 때 자동으로 쿼리한다.

설치는 간단하다.

npx ctx7 setup

Claude Code에 연결하려면 ~/.claude/mcp.json에 아래를 추가한다.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp", "--api-key", "YOUR_API_KEY"]
    }
  }
}

프롬프트에 use context7라고 붙이거나, CLAUDE.md 등 에이전트 규칙 파일에 “문서가 필요하면 context7을 사용하라”고 적어두면 에이전트가 알아서 쓴다. 내부에서 두 가지 MCP 툴이 동작한다.

resolve-library-id: 라이브러리 이름을 Context7 내부 ID로 변환
query-docs: 해당 ID로 최신 문서 조각을 가져옴

Upstash의 벡터 DB와 Redis를 백엔드로 쓰고 있어서 시맨틱 검색이 빠르다. 48.6k 스타를 받으며 MCP 서버 순위권에 올라와 있을 만큼 커뮤니티 반응이 뜨거웠다.

다만 무료 티어가 월 1,000 요청으로 줄었다(2026년 1월 기준). 적극적으로 쓰다 보면 금방 소진된다. 유료 플랜은 월 $10이다. 클라우드 서비스다 보니 네트워크 없이는 동작하지 않고, 라이브러리 인덱싱 주기에 따라 초최신 버전은 바로 반영되지 않을 수 있다.

Context Hub — CLI 방식

Context Hub는 Andrew Ng과 DeepLearning.AI 팀이 2026년 3월에 공개한 CLI 도구다. chub라는 명령어로 쓴다.

npm install -g @aisuite/chub

기본 흐름은 이렇다.

chub search "openai"           # 사용 가능한 문서 검색
chub get openai/chat --lang py # Python 버전 문서 가져오기
chub search "stripe payments"
chub get stripe/api --lang js  # JS 버전 문서 가져오기

MCP가 아니라 CLI이기 때문에, 에이전트가 직접 셸 명령을 실행해서 문서를 가져온다. Claude Code 같은 에이전트는 이미 셸 명령 실행이 가능하니 잘 맞는다. SKILL.md 파일을 에이전트 스킬 디렉토리에 넣어두면 에이전트가 필요할 때마다 알아서 chub를 쓰도록 할 수 있다.

mkdir -p ~/.claude/skills/get-api-docs
# SKILL.md를 그 안에 배치

Context Hub의 독특한 기능은 **주석(annotation)**이다. 에이전트가 문서에서 갭을 발견했을 때, 그 내용을 로컬에 저장할 수 있다.

chub annotate stripe/api "웹훅 검증에는 raw body가 필요함, parsed body 쓰면 안 됨"

다음에 같은 문서를 가져오면 이 주석이 자동으로 붙어서 나온다. 에이전트가 세션을 넘어서도 같은 실수를 반복하지 않게 된다. 커뮤니티 피드백도 있다.

chub feedback stripe/api up       # 문서 좋음
chub feedback stripe/api down     # 문서에 문제 있음

현재 68개 이상의 API 제공자 문서가 포함돼 있다. 오픈소스 마크다운으로 관리하기 때문에 PR을 통해 직접 기여할 수 있다.

두 도구 비교

항목	Context7	Context Hub
작동 방식	MCP 서버	CLI
인프라	클라우드 (Upstash)	로컬
통합 방식	MCP 연결	셸 명령 실행
무료 한도	월 1,000 요청	무제한
버전 지정	자동 매칭	`--version` 플래그
학습 지속성	없음	로컬 주석
커뮤니티 기여	없음	PR 가능
지원 라이브러리	수천 개 (인덱스 기반)	68개+ (큐레이션)
출시	2025년 3월	2026년 3월

가장 큰 차이는 범위 대 깊이다. Context7은 수천 개의 라이브러리를 인덱싱해서 쿼리할 수 있지만, 큐레이션 품질은 라이브러리마다 다를 수 있다. Context Hub는 68개로 규모는 작지만, 각 문서가 “에이전트가 읽기 좋은 형태로” 직접 큐레이션됐다는 점이 강점이다. 마크다운이고 공개돼 있어서 에이전트가 정확히 무엇을 읽는지 사람이 확인할 수도 있다.

또 하나의 차이는 기억이다. Context7은 세션이 끝나면 끝이다. Context Hub는 주석을 통해 에이전트가 발견한 것들을 로컬에 누적할 수 있다.

내 생각

솔직히 두 도구를 써보면서 “이걸 왜 이제야 만들었지?”라는 생각을 했다. 에이전트 코딩을 하면서 가장 많이 시간을 낭비하는 부분 중 하나가 딱 이거다. 에이전트가 자신 있게 틀린 API를 쓰고, 내가 그걸 발견하고 수정하는 사이클.

Context7은 이미 생태계가 크고 사용자가 많다. MCP 방식이라 에이전트 입장에서는 자연스럽게 쓸 수 있다. 다만 무료 한도가 줄어든 게 아쉽다. 개인 프로젝트에서 하루 이것저것 시험해보다 보면 순식간에 한도를 채운다.

Context Hub는 Andrew Ng의 이름값도 있고, 접근 방식이 흥미롭다. CLI를 에이전트가 직접 쓴다는 발상이 단순하면서도 명쾌하다. MCP를 지원 안 하는 환경에서도 쓸 수 있고, 로컬에서만 돌아가니 요청 제한 같은 게 없다. 주석 기능은 에이전트의 “장기 기억” 문제를 건드리는 아이디어인데, 이걸 잘 발전시키면 흥미로운 방향으로 갈 것 같다.

다만 68개 API는 아직 초기 규모다. Stripe, OpenAI, Anthropic 같은 주요 플레이어는 있지만, 내가 쓰는 라이브러리가 없으면 직접 기여해야 한다. Context7처럼 자동 인덱싱 방식이 아니라서 커뮤니티 기여 없이는 규모가 천천히 늘 수밖에 없다.

두 도구가 사실 경쟁 관계라기보다 보완 관계로 보인다. Context7은 광범위한 커버리지를 원할 때, Context Hub는 특정 API를 정확하게 짚어서 쓸 때 각각 유용하다. 실제로 Context Hub가 지원하는 68개 API를 Context7도 대부분 커버할 것이다. 그런 의미에서 현재로서는 Context7을 메인으로 쓰되, 에이전트의 학습 누적이 필요한 시나리오에는 Context Hub의 주석 기능을 따로 활용하는 방식이 합리적으로 보인다.

더 근본적으로는, 이런 도구들이 필요해진 것 자체가 AI 에이전트 코딩이 얼마나 진지한 영역이 됐는지를 보여준다. 에이전트가 “최신 정보”를 갖도록 돕는 메타 도구들이 생태계로 자리잡고 있다는 게 재미있다.

References

클로드 한국 결제액 10배 급증, 그리고 AI 코딩의 미래

Wed, 04 Mar 2026 00:00:00 GMT

최근 앤트로픽의 클로드(Claude)가 한국에서 폭발적인 성장을 보이고 있다는 기사를 봤다. 1년 전 대비 결제액이 무려 10배 이상 늘었다는 내용인데, 이게 단순한 숫자 그 이상의 의미를 가진다고 생각해서 정리해봤다.

숫자로 보는 클로드의 성장

한경에이셀 데이터에 따르면 2026년 2월 1~22일 기준 국내 클로드 결제액이 약 197억 원이었다. 1년 전 같은 기간(16억 원)과 비교하면 1,131% 증가다. 단순히 많이 쓴다는 게 아니라, 돈을 내면서까지 쓴다는 이야기다.

몇 가지 수치가 특히 눈에 띈다.

국내 생성형 AI 결제 점유율에서 클로드가 29%, 챗GPT는 51%로 격차를 빠르게 좁히고 있다
법인카드 결제 비중이 61% — 기업이 업무에 본격 도입하고 있다는 증거다
건당 평균 결제액이 10만 원 이상 — 다른 AI 서비스 평균의 두 배 수준이다

이 숫자들이 말해주는 건 명확하다. 이제 AI는 개인이 호기심에 써보는 단계를 넘어, 기업이 업무에 정식으로 예산을 배정하는 단계로 진입했다.

미국 정부와의 갈등, 그리고 역설적인 성장

흥미로운 맥락이 하나 더 있다. 트럼프 행정부가 앤트로픽에 압박을 가했고, 국방부는 앤트로픽 기술 사용 중단을 지시하며 ‘국가 안보 공급망 위험’으로 지정하겠다고 했다. 반면 오픈AI는 국방부 계약을 수용했다.

이 상황에서 벌어진 일이 흥미롭다. 앤트로픽이 거절하자 소셜미디어에서는 #DeleteChatGPT 캠페인이 확산됐고, 챗GPT 앱 삭제 건수가 하루 만에 295% 급증했다. 동시에 클로드는 미국 앱스토어 무료 앱 1위에 올랐다. 수요가 너무 몰린 나머지 3월 2~3일 이틀간 글로벌 서비스 장애까지 발생했을 정도다.

AI 선택이 단순히 “어느 게 더 잘하나”의 문제에서, **“이 회사의 가치관을 지지하느냐”**의 문제로 넘어가고 있다는 신호다.

클로드 코드 생산성 얘기가 뜨거운 이유

요즘 개발자 커뮤니티에서 클로드 코드(Claude Code)에 대한 얘기가 부쩍 많아졌다. 생산성이 몇 배가 됐다는 경험담이 쏟아진다.

개인적으로도 이 변화를 실감하고 있다. 예전엔 코드를 짜다가 막히면 스택오버플로를 뒤지고, 공식 문서를 읽고, 시행착오를 거치는 데 몇 시간을 썼다. 지금은 막힌 부분을 그대로 붙여넣고 대화하면 대부분 해결된다. 단순히 빨라진 게 아니라, 시도해볼 수 있는 것의 범위 자체가 넓어졌다.

터미널에서 직접 에이전트처럼 동작하는 클로드 코드의 경우, 파일을 읽고 수정하고 명령을 실행하는 것까지 맡긴다. 이쯤 되면 코딩 어시스턴트라기보다는 페어 프로그래밍 파트너에 가깝다.

AI 에이전트 코딩은 선택이 아니다

법인 결제 비중 61%라는 숫자가 다시 보인다. 이미 기업들은 AI 코딩 도구에 예산을 쓰기 시작했다. 이걸 쓰는 사람과 쓰지 않는 사람 사이의 생산성 차이는 이제 무시하기 어려운 수준이 됐다.

앞으로 코딩에서 AI 에이전트의 역할은 더 커질 것이다. 단순 코드 자동완성에서 시작해서, 이미 파일을 읽고 수정하고 테스트까지 실행하는 단계에 와 있다. 몇 년 안에 “요구사항을 주면 알아서 구현하고 PR까지 올리는” 수준이 실용적으로 쓰이게 될 거라고 본다.

이 흐름에서 개발자에게 중요한 건 두 가지다.

첫째, 지금 당장 써봐야 한다. 관심만 갖고 지켜보는 것과 실제로 일상 업무에 녹여 쓰는 것은 다르다. 익숙해지는 데 시간이 걸리고, 프롬프트를 잘 쓰는 것도 연습이 필요하다. 지금 시작하지 않으면 격차는 계속 벌어진다.

둘째, 두려워할 필요는 없다. AI가 코드를 짜준다고 개발자가 필요 없어지는 게 아니다. 무엇을 만들어야 하는지 판단하고, 결과물의 품질을 검증하고, 더 나은 방향을 제시하는 능력 — 이건 여전히 사람의 영역이다. AI 코딩을 잘 활용하는 개발자가 그렇지 않은 개발자보다 더 많은 것을 해낼 수 있을 뿐이다.

한국 시장에서 클로드 결제액이 10배 뛴 건 결국 이 흐름을 숫자로 보여주는 것이다. 기업들이 이미 움직이고 있다. 개발자 개인으로서도 같은 판단을 해야 할 때다.

참고 기사

OpenClaw + 맥미니로 로컬 온디바이스 AI 세팅하기

Wed, 25 Feb 2026 00:00:00 GMT

클라우드 AI 서비스를 구독하면서도 늘 마음 한켠에는 “내 데이터는 내 컴퓨터에서만 처리하고 싶다”는 생각이 있었다. 최근 맥미니 M4 Pro를 구입하고 OpenClaw를 이용해 로컬 온디바이스 AI 환경을 구축해 봤는데, 생각보다 훨씬 쾌적해서 그 과정을 기록으로 남겨 둔다.

들어가기 전에

OpenClaw란?

OpenClaw는 Apple Silicon에 최적화된 로컬 LLM 추론 엔진이다. Metal 백엔드를 활용해 애플 Neural Engine과 GPU를 함께 쓰는 하이브리드 추론을 지원하며, Hugging Face 호환 모델 포맷(GGUF, SafeTensors)을 그대로 불러올 수 있다. OpenAI API 호환 서버를 내장하고 있어 기존 도구들과 연동하기도 편리하다.

항목	OpenClaw	Ollama	LM Studio
Apple Silicon 최적화	Neural Engine + GPU 하이브리드	GPU	GPU
OpenAI API 호환	기본 내장	기본 내장	플러그인
GUI	없음 (CLI)	없음 (CLI)	있음
모델 포맷	GGUF, SafeTensors	GGUF	GGUF, GPTQ
커스텀 시스템 프롬프트	지원	모델파일 방식	지원

사용 장비 스펙

이번 세팅에 사용한 장비는 **맥미니 M4 Pro (2024년 말 출시 모델)**이다.

모델: Mac mini (Late 2024)
칩:   Apple M4 Pro (14-core CPU, 20-core GPU)
메모리: 48GB 통합 메모리
저장장치: 512GB SSD
OS: macOS Sequoia 15.3.1

메모리가 크면 클수록 더 큰 모델을 통째로 메모리에 올릴 수 있다. 48GB 기준으로 32B 파라미터 모델(4비트 양자화 기준 약 20GB)을 여유 있게 구동할 수 있었다.

설치하기

1. Homebrew 설치 (미설치 시)

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Apple Silicon 맥의 경우 /opt/homebrew에 설치된다. 설치 후 쉘 프로파일에 PATH를 추가한다.

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

2. OpenClaw 설치

Homebrew tap을 통해 설치한다.

brew tap openclaw-ai/openclaw
brew install openclaw

설치 후 버전을 확인한다.

openclaw --version
# openclaw version 0.9.4 (darwin/arm64)

3. 모델 다운로드

OpenClaw는 pull 명령으로 공식 레지스트리에서 모델을 받거나, 로컬 GGUF 파일을 직접 임포트할 수 있다.

공식 레지스트리에서 받기

# 경량 모델 (약 4.7GB)
openclaw pull qwen2.5:14b-instruct-q4

# 고성능 모델 (약 19.8GB)
openclaw pull deepseek-r1:32b-q4_k_m

로컬 GGUF 파일 임포트

Hugging Face에서 직접 내려받은 파일이 있다면 이렇게 임포트한다.

openclaw import ./models/gemma-3-27b-it-Q4_K_M.gguf --name gemma3:27b

다운받은 모델 목록은 list 명령으로 확인한다.

openclaw list

NAME                          SIZE    MODIFIED
deepseek-r1:32b-q4_k_m       19.8GB  2 minutes ago
qwen2.5:14b-instruct-q4       4.7GB  10 minutes ago
gemma3:27b                    16.4GB  1 hour ago

서버 실행 및 기본 사용

서버 시작

openclaw serve

기본적으로 http://localhost:11435에서 OpenAI 호환 API를 제공한다. 포트나 호스트를 바꾸려면 플래그를 쓴다.

openclaw serve --host 0.0.0.0 --port 8080

로컬 네트워크의 다른 장비에서도 접근하게 하려면 --host 0.0.0.0을 지정하고 macOS 방화벽에서 해당 포트를 허용해야 한다.

터미널에서 바로 대화하기

서버 없이 CLI만으로 바로 대화할 수도 있다.

openclaw run deepseek-r1:32b-q4_k_m

>>> 안녕하세요! 로컬 AI입니다. 무엇을 도와드릴까요?

/bye를 입력하면 종료된다.

설정 커스터마이징

시스템 프롬프트 설정

~/.openclaw/config.yaml 파일에서 모델별 기본 시스템 프롬프트를 설정할 수 있다.

models:
  deepseek-r1:32b-q4_k_m:
    system_prompt: |
      당신은 숙련된 소프트웨어 엔지니어입니다.
      항상 한국어로 답변하고, 코드 예시를 포함해 설명하세요.
    temperature: 0.7
    context_length: 8192

  qwen2.5:14b-instruct-q4:
    system_prompt: |
      You are a helpful assistant. Be concise.
    temperature: 0.3
    context_length: 32768

성능 튜닝

Metal 백엔드 관련 옵션을 config.yaml에 추가하면 성능을 더 끌어낼 수 있다.

backend:
  threads: 10 # CPU 추론 스레드 수 (P-core 수에 맞춤)
  gpu_layers: 999 # GPU에 올릴 레이어 수 (999 = 전체)
  use_neural_engine: true # Neural Engine 하이브리드 모드
  batch_size: 512
  flash_attention: true

M4 Pro 기준으로 gpu_layers: 999와 flash_attention: true를 활성화했을 때 체감 속도가 가장 좋았다.

macOS 서비스로 등록 (자동 시작)

맥미니는 항상 켜두는 경우가 많으니 launchd 서비스로 등록해 두면 편리하다.

openclaw service install
openclaw service start

이후 재부팅 시에도 자동으로 서버가 올라온다. 상태 확인은 다음과 같이 한다.

openclaw service status
# ● openclaw.service - OpenClaw LLM Server
#    Active: active (running) since Wed 2026-02-25 09:12:33 KST

기존 도구와 연동

Continue (VS Code 확장)

코드 작성 시 AI 어시스턴트로 활용하기 위해 Continue 확장을 연동했다. ~/.continue/config.json에 다음을 추가한다.

{
  "models": [
    {
      "title": "DeepSeek R1 32B (Local)",
      "provider": "openai",
      "model": "deepseek-r1:32b-q4_k_m",
      "apiBase": "http://localhost:11435/v1",
      "apiKey": "local"
    },
    {
      "title": "Qwen 2.5 14B (Local)",
      "provider": "openai",
      "model": "qwen2.5:14b-instruct-q4",
      "apiBase": "http://localhost:11435/v1",
      "apiKey": "local"
    }
  ]
}

Open WebUI

브라우저 기반 채팅 인터페이스를 원한다면 Open WebUI를 Docker로 실행할 수 있다. (Docker Desktop 설치 필요)

docker run -d \
  --name open-webui \
  -p 3000:8080 \
  -e OPENAI_API_BASE_URL=http://host.docker.internal:11435/v1 \
  -e OPENAI_API_KEY=local \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

http://localhost:3000에 접속하면 ChatGPT와 유사한 웹 인터페이스로 로컬 모델을 쓸 수 있다.

성능 측정

맥미니 M4 Pro (48GB) 기준 실측 토큰 생성 속도다.

모델	크기(디스크)	토큰/초 (생성)	메모리 사용
qwen2.5:14b-instruct-q4	4.7GB	62 t/s	7.2GB
gemma3:27b	16.4GB	28 t/s	17.8GB
deepseek-r1:32b-q4_k_m	19.8GB	22 t/s	21.3GB

14B 모델은 60 t/s가 넘어 실시간 대화에 전혀 불편함이 없다. 32B 모델은 22 t/s 수준인데, 문장이 나타나는 속도를 눈으로 따라가기에는 충분하다. 다만 긴 코드 블록을 한번에 생성할 때는 잠깐 기다리는 느낌이 난다.

사용해 보고 나서

처음엔 “굳이 로컬에서 돌릴 필요가 있나?” 싶었다. 클라우드 모델이 품질 면에서는 여전히 앞서고, 비용도 쓰는 만큼만 내는 구조라 합리적이기 때문이다. 그런데 막상 써보니 로컬 환경만의 장점이 확실했다.

가장 크게 느낀 건 응답 지연이 없다는 점이다. API 호출은 네트워크 왕복이 기본으로 들어가는데, 로컬은 첫 토큰이 나오기까지의 시간(TTFT)이 몇백 밀리초 수준이다. 특히 짧은 질문에 대한 즉답 느낌은 클라우드와 비교해 오히려 더 좋다는 생각이 들었다.

다음으로 비용 걱정 없이 실험을 많이 하게 됐다. 클라우드 API를 쓸 때는 테스트 코드 하나 짜면서도 “이거 몇 토큰이지?” 하고 계산하는 습관이 생겼는데, 로컬이 되고 나서는 그냥 막 써보게 된다. 프롬프트 엔지니어링을 이것저것 시험해 보기가 훨씬 편하다.

개인 데이터 처리도 생각이 바뀌었다. 예전에는 업무 관련 코드나 개인 문서를 AI에게 보여주는 게 좀 꺼림칙했는데, 이제는 로컬 모델에 “이 코드 좀 봐줘”라고 편하게 쓸 수 있다.

아쉬운 점도 있다. 최상위 모델과의 품질 격차는 여전히 존재한다. 복잡한 멀티스텝 추론이나 코딩 문제에서는 최신 클라우드 모델이 훨씬 잘한다. 저는 지금은 일상적인 코드 리뷰, 문서 요약, 간단한 코드 자동완성은 로컬로, 복잡한 설계나 디버깅은 클라우드로 나눠서 쓰고 있다.

맥미니가 조용하고 전력 소모도 낮아서 항상 켜두기에 부담이 없다는 것도 장점이다. AI 서버를 24시간 돌리면서도 팬 소리 하나 안 나고, 전기세도 크게 걱정되지 않는다. 맥미니 M4 Pro의 최대 TDP가 65W 수준이라 풀로드 상태에서도 월 전기료 추가분이 몇 천 원 수준이다.

References

Jekyll에서 Gatsby로 블로그 마이그레이션하기

Tue, 20 Jan 2026 00:00:00 GMT

오랫동안 Jekyll로 유지해 온 블로그를 Gatsby로 옮겼다. 결론부터 말하면 잘한 결정이었고, 이 글은 그 과정과 느낀 점을 기록으로 남기기 위해 쓴다.

왜 옮기려 했는가

이 블로그는 2021년부터 Jekyll + Minimal Mistakes 테마 조합으로 운영했다. GitHub Pages가 Jekyll을 네이티브로 지원하던 시절에는 별 문제가 없었는데, Ruby 버전이 올라가면서 상황이 달라졌다.

Ruby 4 호환성 문제

문제의 발단은 Ruby 4.0 릴리스였다. Ruby 4에서는 표준 라이브러리에서 csv, bigdecimal, webrick 등이 제거됐는데, Jekyll 생태계는 이것들에 의존하는 젬이 많았다. Gemfile에 하나씩 추가하다 보니 이렇게 됐다:

gem "csv"
gem "bigdecimal"
gem "webrick"
gem "liquid", ">= 4.0.4"
gem "kramdown-parser-gfm"
gem "jekyll-sass-converter"
gem "jekyll-remote-theme"
gem "jekyll-gist"
gem "jekyll-paginate"
gem "jekyll-seo-tag"

단순히 블로그를 빌드하는 데 이렇게 많은 젬이 필요하다는 게 점점 부담스러워졌다. 로컬에서 bundle install 할 때마다 gem 충돌을 맞닥뜨리거나, CI에서 ruby-setup 액션의 버전을 또 맞춰야 하거나. 블로그 글 한 편 쓰는 것과 전혀 관계없는 일에 에너지를 쏟는 느낌이었다.

Liquid 템플릿의 한계

Minimal Mistakes 테마를 쓰면서 커스터마이징을 하다 보면 결국 Liquid 템플릿을 건드려야 한다. Liquid는 간단한 출력이나 반복에는 편하지만, 조건 분기가 복잡해지거나 데이터를 가공해야 할 때는 금방 난해해진다. 특히 {% raw %}{% assign %}{% endraw %}, {% raw %}{% capture %}{% endraw %}를 남발하는 코드를 다시 볼 때마다 “이게 뭐였지?” 하고 한참 생각했다.

마이그레이션 과정

마이그레이션은 단번에 깔끔하게 되지 않았고, 몇 차례의 시행착오를 거쳤다.

1단계: Gatsby 프로젝트 초기화 및 콘텐츠 이전

먼저 gatsby-source-filesystem과 gatsby-transformer-remark를 기반으로 프로젝트 골격을 잡았다. Jekyll 때 _posts, _notes 등 언더스코어 디렉터리로 관리하던 콘텐츠를 content/posts, content/notes, content/portfolio, content/pages로 정리했다.

content/
  posts/     ← 연도별 서브디렉터리
  notes/     ← 기술 노트 (구 wiki/notes 컬렉션)
  portfolio/ ← 포트폴리오 항목
  pages/     ← about 등 정적 페이지

마크다운 파일 자체는 거의 손댈 필요가 없었다. frontmatter 키 이름이 다를 때만 일괄 치환했고, 본문 내용은 그대로 썼다.

2단계: 라우팅 규칙 구현

Jekyll은 _config.yml의 permalink 설정으로 URL 구조를 정의한다. 기존 블로그는 /:categories/:title/ 패턴이었는데, 이를 Gatsby에서 재현하기 위해 gatsby-node.js에 직접 로직을 작성했다.

// 파일명에서 날짜 접두어(YYYY-MM-DD-)를 제거하고 슬러그 생성
const filename = fileNode.name
const datePrefixMatch = filename.match(/^(\d{4}-\d{2}-\d{2})-/)
const titleSlug = datePrefixMatch
  ? filename.slice(datePrefixMatch[0].length)
  : filename

const slug = `/${firstCategory}/${titleSlug}/`

JavaScript이다 보니 정규식, 문자열 처리 모두 자연스럽게 쓸 수 있었고, 기존 Jekyll URL 구조를 그대로 유지할 수 있었다. 기존 외부 링크나 검색 엔진 인덱스를 깨뜨리지 않기 위해 URL 호환성을 최우선으로 했다.

3단계: 플러그인 설정

Jekyll 플러그인에 해당하는 기능들을 Gatsby 플러그인으로 대응했다.

Jekyll	Gatsby
`jekyll-seo-tag`	`gatsby-plugin-react-helmet`
`jekyll-sitemap`	`gatsby-plugin-sitemap`
`jekyll-feed`	`gatsby-plugin-feed`
`jekyll-paginate`	`gatsby-awesome-pagination`
Google Analytics (직접 삽입)	`gatsby-plugin-google-gtag`
`jekyll-gist`	— (불필요)

RSS 피드 설정이 Jekyll보다 다소 장황하긴 했지만, GraphQL 쿼리를 그대로 쓸 수 있어서 원하는 필드를 자유롭게 골라낼 수 있었다.

4단계: GitHub Actions 배포 설정

Jekyll은 actions/jekyll-build-pages가 있어 설정이 단순한 편인데, Gatsby는 빌드 결과물을 직접 올려야 한다. 아래 흐름으로 정리했다.

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'

- run: npm ci
- run: npm run build

- uses: actions/upload-pages-artifact@v3
  with:
    path: ./public

Ruby 셋업, Bundler 캐시 설정 등이 사라지고 npm ci 한 줄로 의존성이 해결되니 워크플로 파일이 훨씬 간결해졌다.

5단계: Jekyll 잔재 제거

Gemfile, _config.yml, .ruby-version, CNAME 등 Jekyll 전용 파일들을 모두 삭제하고 .gitignore에서도 루비 관련 항목을 정리했다. 저장소 루트가 눈에 띄게 깔끔해졌다.

Jekyll 대비 Gatsby의 장점

직접 써보고 느낀 실질적인 차이점들이다.

의존성 관리의 일관성

Ruby + Bundler 조합은 macOS, Linux, CI 환경에서 미묘하게 다른 동작을 보일 때가 있었다. 특히 시스템 Ruby와 rbenv/rvm이 섞이면 gem install 경로 문제가 발생하곤 했죠. Gatsby는 Node.js 위에서 돌아가므로 package-lock.json을 저장소에 커밋해두면 어느 환경에서나 동일한 npm ci로 재현 가능한 빌드가 된다.

데이터 레이어: GraphQL

Gatsby의 GraphQL 데이터 레이어는 처음엔 과하다는 느낌이 들 수 있지만, 막상 쓰다 보면 편하다. 페이지 컴포넌트에서 필요한 데이터만 정확히 선언하면 되고, gatsby develop 중에 GraphiQL(localhost:8000/___graphql)로 쿼리를 바로 테스트할 수 있다. Jekyll에서 site.posts | where: "category", "컴퓨터" 같은 Liquid 필터를 짜는 것보다 훨씬 직관적이다.

컴포넌트 기반 UI

Jekyll 테마를 커스터마이징하려면 테마 파일을 _includes나 _layouts에 복사해서 덮어쓰는 방식을 써야 했는데, 이게 업스트림 테마 업데이트와 충돌하기 쉬웠다. Gatsby에서는 src/components/에 React 컴포넌트를 두고, 어느 페이지에서 어떤 컴포넌트를 쓰는지 코드로 명확하게 드러난다. 헤더 레이아웃을 바꾸고 싶으면 layout.js를 열면 되고, 포스트 템플릿을 수정하고 싶으면 blog-post.js를 보면 된다.

빠른 피드백 루프

gatsby develop의 HMR(Hot Module Replacement)은 템플릿을 수정하면 브라우저가 즉각 반영된다. Jekyll의 bundle exec jekyll serve --livereload와 비교하면 체감 속도 차이가 난다. 특히 CSS를 조정하면서 레이아웃을 맞출 때 훨씬 쾌적했다.

마이그레이션 후 소감

이전을 완료하고 나서 가장 크게 달라진 것은 “블로그 인프라를 다시 건드리고 싶다”는 생각이 생겼다는 점이다. 예전에는 Jekyll 설정을 열면 왠지 모를 부담감이 있었는데, 지금은 컴포넌트 파일을 열어보는 것이 자연스럽다. JavaScript는 평소에도 쓰는 언어이고, React는 업무에서도 접하는 도구이니까요.

콘텐츠 디렉터리 구조도 이번에 함께 정리했다. 연도별 서브디렉터리로 포스트를 분류하니 content/posts/ 안이 한결 깔끔해졌고, 노트류는 content/notes/에, 포트폴리오는 content/portfolio/에 분리되어 각자 역할이 명확해졌다.

아직 아쉬운 점이 없는 건 아니다. Gatsby 5 기준으로 빌드 시간이 콘텐츠가 많아질수록 늘어나는 편이고, gatsby build가 처음 실행될 때 이미지 처리에 시간이 걸린다. 그리고 플러그인 생태계가 워낙 빠르게 변해서 버전 업데이트 시 breaking change를 챙겨봐야 한다.

그래도 전체적으로는 잘 옮겼다고 생각한다. 적어도 Ruby 4 호환성 때문에 새벽에 Gemfile을 뒤적이는 일은 없어질 테니까요.

Solar vs GLM 논란: 공개 검증으로 마무리된 코사인 유사도 논쟁

Tue, 06 Jan 2026 00:00:00 GMT

2026년 새해 벽두부터 국내 AI 업계에 뜨거운 논쟁이 불거졌다. Upstage의 초대형 언어모델 Solar-Open-100B가 중국 칭화대 연구팀이 개발한 GLM-4.5-Air를 기반으로 파생되었다는 의혹이다. 국민 세금이 투입된 프로젝트에서 중국 모델을 복사했다는 주장이라 파장이 상당했다. 그러나 Upstage가 즉각 공개 검증에 나서면서 논란은 빠르게 마무리됐다.

논쟁의 타임라인

1월 1일 - 문제 제기: Sionic AI 고석현 대표가 LinkedIn에 Solar와 GLM의 LayerNorm 가중치 코사인 유사도가 비정상적으로 높다는 글을 올리며 “Solar는 GLM에서 파생됐다”고 주장했다. 분석 코드는 GitHub에 공개됐다.
1월 1일 - Upstage 반박: 김성현(Sung Kim) 대표가 Facebook을 통해 공개 검증을 제안하며 강하게 부인했다.
논쟁 중 - 커뮤니티 반박: 카카오 ML 개발자 고현웅(Kevin Ko)씨가 “코사인 유사도만으로 파생 여부를 단정할 수 없다”는 반박 리포트를 공개했다.
논쟁 중 - 전문가 개입: 뉴욕대 조경현 교수가 sionic-ai 리포에 “코사인 대신 Pearson 상관관계를 쓰자”는 PR을 제안했다.
공개 검증회 개최: Upstage가 공개검증회를 열어 전체 학습 기록을 공개했다. 현장에 AI 전문가 90명, 온라인으로 2,000명이 참석했다.
1월 3일 - 사과: 고석현 대표가 사과글을 게재하며 논란이 종료됐다.

주장 측(sionic-ai)의 논거

sionic-ai 리포의 논리 구조는 다음과 같다.

Solar-Open-100B와 GLM-4.5-Air의 같은 레이어에서 RMSNorm/LayerNorm 가중치의 코사인 유사도를 측정했더니 약 0.989로 매우 높았다. 반면 같은 모델 내 서로 다른 레이어끼리의 유사도는 0.377 수준에 불과했다.

텐서 타입별로도 흥미로운 패턴이 발견됐다. LayerNorm 계열 텐서는 유사도가 0.949~0.986으로 매우 높은 반면, 임베딩·K/V projection·MoE gate 등은 유사도가 0에 가까웠다. 이 “선택적 보존” 패턴을 두고 “일부 파라미터만 원본 모델에서 가져오고 나머지는 재학습한 파생 모델”이라고 해석했고, p-value 등 통계 수치를 제시하며 “우연일 가능성은 사실상 0”이라고 강조했다.

반박 측(hyunwoongko)의 핵심 지적

카카오 ML 개발자 고현웅씨의 반박 리포트는 sionic-ai의 분석을 정면으로 반박한다.

핵심은 비교 대상을 늘렸다는 점이다. Solar, GLM, Phi-3.5-MoE-instruct 세 모델의 LayerNorm 파라미터를 비교했더니, 같은 레이어끼리 비교했을 때 세 모델 모두 코사인 유사도가 0.9 이상으로 높게 나왔다. sionic-ai의 논리대로라면 GLM과 Phi도 파생 관계가 성립해야 하지만, GLM은 칭화대(THUDM)가 2021년부터 독자적으로 개발한 모델이고 Phi는 Microsoft가 2023년에 내놓은 경량 모델로 계보가 전혀 다르다. 시간 순서상 불가능한 파생 관계가 도출되는 것이다.

MAD(Mean Absolute Difference) 기준으로 비교하면 Solar–GLM의 차이(≈ 0.4121)가 GLM–Phi의 차이(≈ 0.2159)보다 오히려 더 크다. sionic-ai의 메트릭을 그대로 적용하면 “Solar가 GLM에서 파생됐다”는 주장보다 “GLM이 Phi에서 파생됐다”는 주장이 더 쉽게 성립하는 모순이 발생한다.

이 현상의 원인은 RMSNorm 가중치의 구조적 특성에 있다. RMSNorm 가중치는 rank-1 벡터로 정보량이 적고, 대부분 1.0 근처로 초기화된 뒤 학습 후에도 분산이 크게 늘지 않는다. 코사인 유사도는 방향만 보고 크기는 무시하기 때문에, 이런 “스케일링 벡터”류에서는 서로 다른 모델 사이에서도 높게 나오는 경향이 있다.

조경현 교수의 PR: “Pearson 상관관계를 써라”

뉴욕대 조경현 교수는 sionic-ai 리포에 직접 PR을 올려 코사인 유사도 대신 Pearson 상관관계를 사용하자고 제안했다.

Pearson 상관관계는 벡터에서 평균을 제거하고 분산으로 정규화한 뒤 계산한다. “값이 비슷한가”가 아니라 “패턴이 비슷한가”를 보는 방식으로, LayerNorm의 초기화 편향(initialization artifact)을 제거할 수 있다는 것이 핵심 논지다.

실제로 Pearson을 적용하면 Solar–GLM의 유사도는 특별히 높지 않게 나온다. 코사인 기준으로는 GLM과 Qwen2(완전히 다른 모델) 사이에서도 유사도가 0.94 이상 나온다는 점을 고려하면, 코사인 유사도가 “파생 여부를 판단하는 지표”로 적합하지 않다는 결론이 도출된다.

공개 검증 결과

Upstage는 공개검증회를 즉각 개최하고 전체 학습 기록을 공개했다. 검증 현장에는 AI 전문가 90명이 참석했고, 온라인으로는 2,000명이 지켜봤다.

김성훈 대표는 검증회에서 “대부분의 거대언어모델은 트랜스포머나 MoE 기반으로 표준화되어 있기 때문에, LayerNorm의 유사도는 어떤 모델과 비교해도 비슷하게 나올 수밖에 없다”고 설명했다. 이는 앞서 커뮤니티 반박과 조경현 교수의 PR에서 제기된 내용과 맥락을 같이한다.

검증 결과 의혹은 해소됐고, 고석현 대표는 1월 3일 사과글을 게재하며 이번 논란이 마무리됐다. 배경훈 부총리는 이번 공개 검증에 대해 “한국 AI의 밝은 미래를 보았다”고 평가하며 환영 입장을 밝혔다. 이 과정은 “건전한 AI 생태계의 건강한 토론”이라는 평가를 받기도 했다.

내 생각

이번 논란에서 흥미로웠던 건 기술적 주장이 아니라 그것이 소비되는 방식이었다. 코사인 유사도 하나를 “DNA 수준의 일치”로 비유한 순간, 논쟁은 기술적 검증의 영역을 벗어났다.

결과적으로 sionic-ai의 방법론은 부적절한 지표를 사용했고, 결론은 과장됐다. Upstage가 전체 학습 기록을 공개하고 공개 검증에 나선 것은 올바른 대응이었다고 생각한다. 의혹을 제기한 측도 검증 결과를 받아들이고 사과한 것 역시 깔끔한 마무리였다.

다만 이번 사건이 남긴 더 중요한 질문이 있다. AI 모델의 파생 관계를 판단하는 엄밀한 기준이 아직 업계에 정립되어 있지 않다는 점이다. 앞으로 비슷한 논쟁이 반복될 가능성이 높은 만큼, Pearson 상관관계처럼 더 신뢰할 수 있는 방법론을 커뮤니티 차원에서 정립해나갈 필요가 있다고 생각한다.

좋은 리더가 되기 위한 조언

Sun, 28 Dec 2025 00:00:00 GMT

영상: https://youtu.be/gK5MBHDXw24

모두에게 마음을 열고 이 자리가 처음이라는 걸 말한다. 처음으로 윗 사람이 되었고, 같이 일하게 되서 기쁘고, 좋은 리더가 되고 싶다. 할 수 있는 한 최고의 리더가 되도록 노력할 거고 그 과정에서 실수도 하겠지만 지금 가장 중요하게 생각하는 건 우리 팀이 한 팀으로 잘 성장하는 것이다.
리더십을 공부해라. 원래부터 잘 하는 리더는 없음. 책을 읽고 강연을 듣고 기사를 읽는다. 존경하는 리더에 대해 공부한다. 많은 업적을 이룬 사람이 아니고, 내가 따라가고 싶은 사람을 말이다. 나쁜 리더에게도 배워야 한다. 되고 싶지 않은 리더도 라부해야 한다. 이미 리더가 되었다고 해서 잘하고 있는건 아니다. 그래서 공부해야 한다.
멘토를 찾아라. 멘토가 중요하다. 또래와 경험이 있는 사람 누구든지. 나의 계급 체계에 있는 사람 말고, 아버지의 친구나 학교에서 만난 사람도 좋고, 나의 경력에 영향을 주지 않는 사람을 선택한다. 그래야 나 자체에 관심을 둘 것이다. 계속 그들과 대화한다. 그들이 문제를 해결해 주거나 그 충고를 따라야 한다는건 아니다. 소리 내어 말하는 것이 필요한거다. 내가 무슨 생각을 하고 어떤 일을 겪고 있는지를 말이다. 그러면 스스로 문제를 해결하게 된다. 친구도 좋다. 리더십 친구를 두는거 좋다.

현대오토에버, 프라이빗 AI 모델 개발한다

Thu, 02 Oct 2025 00:00:00 GMT

현대오토에버가 자체 프라이빗 LLM 개발에 착수했다는 기사를 읽었다.

현대오토에버, 프라이빗 AI 모델 개발한다…그룹사 확산 전망 - 전자신문

기사에서 본 핵심 변화

GPT와 같은 퍼블릭 LLM을 사용하다가 온프레미스 프라이빗 모델로 전환하는 흐름 자체는 낯설지 않다. 보안이 민감한 영역에서 외부 API를 사용하는 것은 처음부터 무리가 있었다. 다만 이번에 눈길을 끄는 점은 현대오토에버가 국가핵심기술 분야를 명시적인 첫 번째 적용 대상으로 지목했다는 것이다. 자율주행, 철강과 같은 76개 핵심 산업 분야에서 데이터가 외부로 유출되어서는 안 된다는 점은 규정보다 앞서 상식의 영역이기도 하다.

내가 더 관심 있게 본 부분은 이 결정의 비용 구조다. 초기 인프라 비용은 퍼블릭 API보다 훨씬 크다. GPU 서버, 운영 인력, 모델 유지보수까지 모두 감당해야 한다. 그런데 현대차그룹처럼 계열사가 많고 AI 활용 빈도가 높은 곳에서는 오히려 장기적으로 더 저렴해질 수 있다. API 호출 단가가 고정이 아니고, 사용량이 늘수록 클라우드 비용은 선형적으로 증가한다. 어느 시점에서는 손익분기점을 넘게 된다.

sLLM, 즉 소형 언어 모델 개발도 고려 중이라는 부분이 흥미롭다. 대형 모델을 무조건 적용하는 방식은 이제 유효하지 않다. 특정 업무에 특화된 소형 모델이 같은 작업을 더 빠르고 저렴하게 처리하는 경우가 많다. 행정 문서 처리, 차량 SW 매뉴얼 응답처럼 도메인이 좁고 반복성이 높은 작업이라면 더욱 그렇다. 맞춤형 모델이 범용 대형 모델보다 실용적인 영역은 생각보다 넓다.

내 생각

이 흐름을 보면서 드는 생각은 하나다. AI 내재화는 선택지가 아니라 방향이 되고 있다.

2023~2024년에는 “어떤 LLM API를 쓸 것인가”가 주요 질문이었다면, 이제는 “어떻게 우리 데이터와 인프라 위에서 돌릴 것인가”로 무게 중심이 이동하고 있다. 현대오토에버의 이번 결정은 그 전환을 가장 잘 보여주는 사례 중 하나라고 생각한다.

물론 자체 모델 개발은 쉽지 않다. 좋은 모델을 만들려면 데이터, 컴퓨트, 사람이 모두 필요하다. 그 중 가장 확보하기 어려운 것은 결국 사람이다. 기사에서 인재 채용을 확대하고 있다고 언급한 것도 그 맥락에서 읽힌다. 기술 전략이 인재 전략과 분리되지 않는다는 점을 잘 알고 있다는 신호다.

그룹사 확산 전망이라는 부분도 현실적이다. 현대차, 현대제철, 기아와 같은 계열사들이 같은 베이스 모델을 공유하면서 각자의 도메인 데이터로 파인튜닝하는 구조라면, 초기 개발 비용을 나눠 감당할 수 있다. 하나의 IT 계열사가 그룹 AI 인프라를 맡는 구조는 효율적이고 합리적이다.

마치며

결국 이 기사는 기술 뉴스라기보다 기업 전략의 무게 이동을 보여주는 신호로 읽힌다. 외부 의존에서 내부 역량으로, 범용에서 특화로. 그 방향은 맞다. 실행이 관건이다.

리더의 VAP

Mon, 29 Sep 2025 00:00:00 GMT

리더는 복잡한 모든 일을 다 잘해야 하는 사람이 아니라, 팀이 앞으로 나아가도록 핵심을 지키는 사람이라고 생각한다.

내가 정리한 핵심은 세 가지다. 바로 VAP이다.

VAP란

Vision: 비전을 제시하고
Action: 지금 해야 할 액션을 알려주고
Problem: 팀이 부딪히는 문제를 해결한다

왜 중요한가

팀원은 우리가 어느 방향으로, 어떤 목적으로 가는지 알아야 동기부여가 된다.
팀원은 당장 내가 무엇을 해야 하는지 알아야 혼란 없이 움직일 수 있다.
팀원은 여러 문제에 휘둘리지 않아야 업무에 집중할 수 있다.

자주 만나는 문제와 대응

시간이 부족하다 → 범위를 줄인다
사람이 부족하다 → 범위를 줄이거나, 시간을 늘인다
업무를 모른다 → 잘 아는 사람을 데려온다
협업이 안 된다 → 협업팀 리드를 직접 만난다

결국 리더의 역할은 거창하지 않다.

방향을 명확히 하고, 실행을 분명히 하고, 장애물을 치워주는 것.

이 세 가지만 제대로 해도 팀의 속도와 집중력은 크게 달라진다.

Ted Lasso 명언 모음

Tue, 23 Sep 2025 00:00:00 GMT

Apple TV+ 드라마 Ted Lasso(2020–2023)는 AFC 리치몬드라는 영국 축구팀을 맡게 된 미국인 풋볼 코치 테드 라소의 이야기다. 전술보다 사람을 먼저 보는 그의 태도가 팀을 조금씩 바꿔 나가는 과정이 시즌 내내 담긴다. 코미디처럼 시작해서 결국 사람 냄새 나는 성장 드라마로 마무리되는데, 그 과정에서 무심히 던져지는 말들이 꽤 오래 머릿속에 남는다.

아래는 세 시즌을 통틀어 기억에 남는 명언들을 정리한 것이다.

믿음에 관하여

“Believe.”

테드가 라커룸 문에 붙여 놓은 단 한 단어. 설명도 없고 조건도 없다. 시즌 내내 이 글자가 반복해서 등장하는데, 볼 때마다 맥락이 달라서 무게감이 계속 쌓인다. 믿음이라는 게 거창한 것이 아니라 그냥 하루하루 계속 나타나는 것이라는 걸 이 단어 하나가 보여준다.

“Taking on a challenge is a lot like riding a horse. If you’re comfortable while you’re doing it, you’re probably doing it wrong.”

도전에 임하는 건 말을 타는 것과 비슷해. 하는 동안 편안하다면, 아마 잘못하고 있는 거야.

호기심과 판단에 관하여

“I have a real fear of something, and it ain’t losing. I was afraid of being judged. ‘Cause I don’t ever want to stop being curious about people.”

제가 정말 두려워하는 건 지는 게 아니에요. 저는 판단받는 걸 두려워했어요. 왜냐하면 사람들에 대해 궁금해하는 걸 절대 멈추고 싶지 않거든요.

테드가 다트 내기 중 말하는 장면이다. 상대방을 쉽게 재단하지 않고 늘 더 알고 싶어하는 태도, 그게 테드라는 캐릭터의 핵심이다. 사람에 대한 호기심을 유지하는 것만으로도 많은 갈등이 해소된다는 걸 드라마 전반에서 보여준다.

과거와 현재에 관하여

“You know what the happiest animal on Earth is? It’s a goldfish. You know why? Got a ten-second memory.”

지구에서 가장 행복한 동물이 뭔지 알아요? 금붕어예요. 왜인지 알아요? 기억이 10초밖에 안 되거든요.

실수를 빠르게 털어내고 다시 시작하는 것의 중요성을 유머로 전달한다. 물론 금붕어의 기억이 10초라는 건 오해지만, 비유로서의 힘은 충분하다.

“Taking the high road… I was told that’s the road less traveled.”

잘못한 상대에게 복수하거나 끌어내리는 대신 그냥 자기 길을 가는 것. 말은 쉽고 행동은 어렵지만, 테드는 그걸 매 상황에서 실제로 해낸다.

팀과 관계에 관하여

“For me, success is not about the wins and losses. It’s about helping these young fellas be the best versions of themselves on and off the field.”

저에게 성공이란 승패가 아니에요. 이 젊은 친구들이 경기장 안팎에서 최고의 자신이 될 수 있도록 돕는 거예요.

축구 코치가 성적에 집착하지 않는다는 게 이 드라마의 가장 큰 반전이다. 테드는 일관되게 사람을 결과보다 앞에 놓는다. 그리고 아이러니하게도 그게 팀을 더 강하게 만든다.

“I think that if you care about someone and you got a little love in your heart, there ain’t nothing you can’t get through together.”

누군가를 아끼고 마음속에 조금이라도 사랑이 있다면, 함께 못 넘을 게 없다고 생각해요.

“A good mentor hopes you will move. A great mentor knows you will.”

좋은 멘토는 당신이 발전하길 바래요. 훌륭한 멘토는 당신이 발전할걸 이미 알고 있구요.

바람과 확신은 다르다. 테드는 선수 한 명 한 명을 이미 믿고 있다. 그 믿음이 선수들에게 전해지고, 결국 그들이 스스로 성장하도록 이끄는 힘이 된다. 기대가 아니라 확신으로 사람을 대하는 것, 그게 테드식 리더십의 핵심이다.

“You know my philosophy about cats, baby. Let them come to you.”

고양이, 아기 사과에 대한 나의 철학 알잖아. 내게 오게 하라.

밀어붙이지 않고 기다리는 코칭 방식이다. 선수가 준비됐을 때 먼저 다가오도록 공간을 만들어 주는 것, 그게 테드의 방식이다. 억지로 끌어당기지 않아도 결국 오게 되어 있다는 느긋한 확신이 담겨 있다.

“Big advice to being a boss. Hire your best friend.”

보스가 될거니 조언을 하나 줄게. 제일 친한 친구를 고용해.

테드와 코치 비즐리의 관계를 그대로 보여주는 말이다. 신뢰가 쌓인 사람과 함께 일하는 것이 얼마나 큰 힘이 되는지, 두 사람이 함께하는 장면마다 자연스럽게 느껴진다.

변화와 성장에 관하여

“Every disadvantage has its advantage.”

모든 불리함에는 유리함이 있다.

요한 크루이프의 말을 인용하는 장면인데, 드라마 흐름에 딱 맞게 떨어진다. 약점이라고 생각했던 것이 나중에 강점이 되는 전개가 이 말 한 줄로 정리된다.

“I believe in communism. Rom-communism, that is.”

진지한 맥락에서 갑자기 로맨틱 코미디 얘기를 꺼내는 장면인데, 테드다운 전환이다. 어색한 순간을 유머로 부드럽게 넘기면서도 핵심 메시지(서로 잘 되길 바라는 마음)는 흐리지 않는다.

자기 자신에 관하여

“I’ve come to realize that cynicism is just fear with a fancy hat and a trip wire.”

냉소란 그냥 두려움이 멋진 모자를 쓰고 올가미를 든 것이라는 걸 깨달았어요.

냉소적인 사람을 나쁜 사람이 아니라 두려운 사람으로 바라보는 시각이 인상적이다. 테드는 냉소적인 캐릭터들을 밀어내지 않고 그 두려움이 뭔지 이해하려 한다.

“Be curious, not judgmental.”

판단하지 말고 궁금해해라.

월트 휘트먼의 말로 알려진 구절인데, 드라마에서 이 한 문장을 중심으로 한 에피소드 전체가 설계될 정도로 핵심 메시지다. 이 드라마를 한 줄로 요약하라면 저는 이 말을 고르겠다.

마무리하며

Ted Lasso는 스포츠 드라마의 외형을 하고 있지만, 결국 사람이 사람을 어떻게 대해야 하는지에 대한 이야기다. 테드의 말들이 특별한 이유는 그게 훈계나 교훈이 아니라, 그냥 그가 사는 방식에서 자연스럽게 나오기 때문이다. 대사를 외우거나 명언집을 만들려고 한 게 아니라, 저렇게 살다 보니 저런 말이 나오는 것처럼 보인다.

그래서 보고 나면 저 말들보다 테드라는 사람이 더 오래 기억에 남는다.

무대와 관객

Mon, 11 Aug 2025 00:00:00 GMT

공연을 만드는 것은 무대이고, 공연을 성공시키는 것은 관객이다.

화려한 경력을 가진 피아니스트와 비판적이고 냉소적인 관객
동네 작은 피아노 연주회에 모인 부모님과 친구들
공연의 성공은 무대에 있는 사람이 아니라 주변에 의해 결정

장한나 지휘자 강연 요약

Sat, 02 Nov 2024 00:00:00 GMT

오케스트라가 하나의 소리를 만들기까지

장한나 지휘자 강연을 들으며 가장 크게 남은 문장은 이것이었다.

지휘자는 가장 훌륭한 연주를 연주자가 가장 쉽게 할 수 있도록 돕는 사람.

짧은 문장인데, 리더십에 대한 거의 모든 것이 들어 있다고 느꼈다. 이번 글은 강연 내용을 정리하면서 내가 인상 깊었던 지점을 함께 남겨두는 기록이다.

강연 핵심 요약

훌륭한 연주는 악보가 완전히 해석된 상태에서 시작된다.
지휘자는 총보의 모든 음을 이해할 때까지 파고든다.
리허설은 짧고(보통 2~3일), 그래서 첫 만남의 방향 제시가 결정적이다.
지휘 대상은 악기가 아니라 사람 100명이다.
결국 핵심은 통제보다 비전 공유와 신뢰 형성이다.

DAY 1 — 간보기, 쐐기, 목표 제시

첫 리허설의 목적은 서로를 시험하는 동시에, 이 주의 기준을 선명하게 세우는 것이다. 강연에서 특히 흥미로웠던 부분은 “첫 5분”의 중요성이었다.

지휘자는 확신 있는 해석을 보여주며 팀의 방향을 제시한다.
오케스트라도 지휘자의 스타일과 청음 능력을 확인한다.
가장 길고 어려운 곡을 먼저 연주해 전체 기준점을 맞춘다.
고쳐야 할 실수는 가능한 한 즉시, 악보 근거로 정리한다.

내가 느낀 포인트는 “처음 인상이 끝까지 간다”는 점이었다. 초반에 애매하면 이후 수정 비용이 커지고, 초반에 명확하면 팀 전체가 훨씬 빠르게 정렬된다.

DAY 2 — 디테일과 설득의 시간

둘째 날은 본격적인 완성 단계다. 음정, 밸런스, 프레이징 같은 기술적 요소를 다듬는 동시에, 감정의 밀도까지 올려야 한다.

같은 요청도 단원마다 다르게 전달해야 한다.
“작게” 같은 지시보다 이미지 언어(안개, 별빛 등)가 더 깊게 작동한다.
모든 설명의 최종 근거는 결국 악보다.
지휘자는 전체 소리의 퍼스펙티브를 듣고 하나의 소리로 엮는다.

이 대목에서 가장 공감한 건 “정확함 + 진정성”의 결합이었다. 기술만으로는 움직이지 않고, 열정만으로도 완성되지 않는다. 둘이 같이 갈 때 비로소 소리가 바뀐다는 말이 인상 깊었다.

DAY 3 — 신뢰 확인과 선택의 리더십

셋째 날은 “무엇을 더 할지”보다 “무엇을 하지 않을지”를 결정하는 날에 가깝다.

이미 된 부분은 과감히 넘기고 필요한 부분만 리허설한다.
협연자와의 해석을 빠르게 맞추며 전체 균형을 잡는다.
시간이 남아도 억지로 채우지 않고 종료할 수 있어야 한다.

개인적으로는 이 부분이 가장 프로답게 느껴졌다. 많이 시키는 리더보다, 필요한 것만 정확히 시키는 리더가 결국 신뢰를 얻는다는 점이 명확했다.

리허설에서 공연까지

강연 내용은 아래 흐름으로 정리할 수 있었다.

DAY 1: 존재감과 비전 각인
DAY 2: 디테일 조정과 완성도 극대화
DAY 3: 신뢰 확인과 최종 정렬
공연: 모든 준비가 한순간에 하나로 모이는 시간

“연주는 우주선 발사 같다”는 비유가 기억에 남는다. 보이지 않던 작은 조정들이 공연 순간 한 번에 점화되는 느낌을 잘 설명해 준다.

장한나의 리더십 프레임: VISA

강연의 결론은 VISA라는 네 단어로 정리됐다.

1) Vision

해석은 리더의 비전이다. 어디로 갈지 정하지 못하면 팀은 움직일 수 없다.

2) Inspiration

지휘자 본인이 먼저 음악에 감동해야 단원과 청중에게도 영감을 전달할 수 있다.

3) Service

지휘는 지시가 아니라 섬김에 가깝다. 작곡가, 악보, 단원, 청중을 모두 향한 태도다.

4) Achievement

협업을 통해 감동을 실제 결과로 만들고, 그 순간 클래식의 생명력이 다음 세대로 이어진다.

내 감상

이번 강연을 들으며 나는 “리더십은 결국 사람의 마음을 다루는 일”이라는 말을 다시 확인했다.

특히 좋았던 점은 이상적인 말만 하지 않고, 리허설 현장에서 실제로 부딪히는 문제(실수, 저항, 시간 압박, 해석 충돌)를 매우 현실적으로 짚어준 부분이었다. 덕분에 지휘라는 일이 낭만적인 이미지가 아니라, 치밀한 준비와 순간 판단의 연속이라는 걸 더 선명하게 이해했다.

나도 일을 할 때 종종 “더 많이”에 집중하는 편인데, 이 강연은 “더 정확하게”와 “더 진정성 있게”가 훨씬 중요하다는 걸 다시 생각하게 만들었다. 좋은 리더는 앞에서 끌고 가기만 하는 사람이 아니라, 팀이 스스로 더 잘 연주할 수 있게 만드는 사람이라는 말이 오래 남는다.

LLM을 활용한 실전 AI 어플리케이션 개발

Mon, 19 Aug 2024 00:00:00 GMT

허정준 지음, 박재호 감수의 『LLM을 활용한 실전 AI 애플리케이션 개발』(책만, 2024)을 읽고 정리한 감상입니다. 2025 대한민국학술원 우수학술도서로 선정된 이 책은 556쪽에 걸쳐 LLM의 기초 아키텍처부터 실전 서비스 운영까지 전 과정을 체계적으로 다룹니다.

책 한 줄 평

LLM을 “만드는 것”과 “쓰는 것” 모두를 아우르는, 국내 저자가 쓴 거의 유일한 LLM 풀스택 안내서.

구성과 흐름

책은 4부 16장으로 구성됩니다. 1부에서 이론 기반을 닦고, 2부에서 모델을 직접 다루는 방법을 배우고, 3부에서 실전 애플리케이션을 만들고, 4부에서 멀티모달과 에이전트 같은 고급 주제로 마무리합니다. 읽는 내내 “왜 이 기술이 필요한가”라는 질문에 먼저 답한 뒤 세부 구현으로 들어가는 흐름이 자연스러웠습니다.

1부 — LLM의 기초 뼈대 세우기

1장. LLM 지도 — 전체 그림부터

책이 처음부터 전체 지형도를 제시해 주는 점이 좋았습니다. LLM을 제대로 활용하려면 관련 기술들이 어떻게 연결되는지 큰 그림을 먼저 잡아야 한다는 저자의 시각이 고스란히 드러납니다.

구분	설명
머신러닝	입력 → 특징 추출 → 분류 → 출력
딥러닝	입력 → 특징 추출 + 분류(통합) → 출력
임베딩	데이터의 의미와 특징을 포착해 숫자로 표현
전이 학습	하나의 문제를 해결하면서 얻은 지식을 다른 문제에 활용

LLM의 실용화를 가능하게 한 핵심 기술들을 초반에 정의해 두는 방식도 유용했습니다.

sLLM: 모델 크기는 작지만 특정 도메인에서 높은 성능을 내는 소형 언어 모델
양자화(Quantization): 모델 파라미터를 더 작은 비트로 표현해 메모리 사용량을 줄임
LoRA(Low Rank Adaptation): 모델의 일부 파라미터만 학습해 효율적으로 미세 조정
RAG(Retrieval Augmented Generation): 프롬프트에 LLM이 답변할 데이터를 미리 추가해 최신성과 정확도를 높임
멀티모달: 텍스트를 넘어 이미지, 음성 등 여러 형태의 데이터를 입출력
에이전트: LLM이 계획을 세우고 의사결정을 내리며 필요한 행동까지 수행

2장. 트랜스포머 아키텍처

RNN의 한계에서 출발해 트랜스포머가 왜 등장했는지 설명하는 흐름이 설득력 있습니다. RNN은 지금까지 입력된 텍스트의 맥락을 하나의 **잠재 상태(hidden state)**에 압축하는데, 레이어가 깊어질수록 과거 정보가 희석되는 Vanishing Gradient 문제가 있었습니다.

트랜스포머는 이 순차적 처리 방식을 버리고 입력 전체를 동시에 참조하는 self-attention 연산을 채택했습니다. 주요 아키텍처 분류도 직관적으로 정리되어 있어 처음 접하는 독자도 이해하기 쉽습니다.

아키텍처	대표 모델	특징
인코더	BERT (Google)	마스크 언어 모델링, 양방향 문맥 이해
디코더	GPT (OpenAI)	인과적 언어 모델링(CLM), 단방향, 생성 특화
인코더+디코더	BART (Meta), T5 (Google)	번역·요약 등 시퀀스-투-시퀀스 태스크에 강점

3장. 허깅페이스 트랜스포머 라이브러리

모델마다 구현 방식이 달라 각기 활용법을 익혀야 했던 문제를 허깅페이스 트랜스포머 라이브러리가 공통 인터페이스로 해결한 과정을 잘 설명합니다. 모델 허브, 토크나이저, 데이터셋, 학습용 Trainer, 추론용 pipeline을 아우르는 생태계를 실습 예제와 함께 익힐 수 있습니다.

4장. 말 잘 듣는 모델 만들기

사전 학습된 언어 모델이 텍스트를 잘 생성하더라도 사용자 요청에 적절히 응답하는 방식은 따로 학습해야 한다는 사실을 이 장에서 배웠습니다. **지도 미세 조정(SFT)**과 정렬 기법들을 비교한 부분이 특히 유익했습니다.

RLHF: 사람의 피드백을 보상 신호로 활용하는 강화 학습. 단, 보상 해킹(reward hacking) 문제가 있음
PPO(Proximal Policy Optimization): 가까운 범위에서 높은 보상을 탐색하는 근접 정책 최적화
기각 샘플링(Rejection Sampling): SFT 모델로 여러 응답을 생성하고, 리워드 모델이 가장 높은 점수를 준 것만 다시 SFT에 사용
DPO(Direct Preference Optimization): 강화 학습 없이 선호 데이터셋을 직접 학습. RLHF보다 단순하면서 효과적이고 리워드 모델이 필요 없음

2부 — LLM 들이기

5장. GPU 효율적인 학습

부동소수점 정밀도 개념부터 설명한 뒤 메모리 절약 기법으로 자연스럽게 이어지는 구성이 탄탄합니다.

fp32 (지수 8bit, 가수 23bit)
  → fp16 (지수 5bit, 가수 10bit)
  → bf16 (지수 8bit, 가수 7bit)

기법	설명
Gradient Accumulation	제한된 메모리에서 큰 배치 효과를 얻는 방법
Gradient Checkpointing	순전파 중간 값을 선별 저장해 메모리를 줄이고 필요 시 재계산
분산 학습	2개 이상의 GPU로 모델을 학습

**PEFT(Parameter Efficient Fine-Tuning)**의 대표 기법인 LoRA는 모델에 소수의 파라미터를 추가하고 그 부분만 학습합니다. 여기에 양자화를 결합한 QLoRA는 메모리 효율을 한층 더 높입니다. 개인 장비에서도 파인튜닝이 가능하다는 점을 실감할 수 있었습니다.

6장. sLLM 학습하기

직접 소형 언어 모델을 학습시키는 과정을 다룹니다. 이론으로만 알던 내용을 코드로 실습할 수 있어 이해가 깊어지는 챕터입니다.

7장. 모델 가볍게 만들기

실제로 모델을 경량화할 때 쓰는 주요 도구들을 한데 정리해 둔 점이 실용적입니다.

bitsandbytes: 워싱턴대학교에서 개발한 양자화 라이브러리
GPTQ(GPT Quantization): 사후 양자화 방식
AWQ(Activation-aware Weight Quantization): 활성화 값을 고려한 가중치 양자화
GGUF(Georgi Gerganov Unified Format): 다양한 칩(GPU, CPU, 애플 실리콘)에서 추론 가능한 모델 저장 형식 → 온디바이스 AI에 특히 유용

지식 증류(Knowledge Distillation) 기법도 설명합니다. 더 크고 성능이 높은 **교사 모델(teacher model)**의 출력을 활용해 더 작은 **학생 모델(student model)**을 학습시키는 방법으로, 온디바이스 AI 트렌드와도 맞닿아 있어 흥미롭게 읽었습니다.

8장. sLLM 서빙하기

서빙은 개발자 입장에서 가장 현실적인 고민이 담긴 챕터입니다. 배치 전략부터 메모리 관리까지 실무에 바로 적용할 수 있는 내용이 많았습니다.

방식	특징
정적 배치	고정된 입력 묶음을 한 번에 처리
동적 배치	요청이 들어오는 대로 묶음 크기를 조절
연속 배치	처리 완료된 요청을 즉시 새 요청으로 교체해 GPU 활용도 극대화

KV Cache: 동일 연산의 반복을 줄이기 위해 계산 결과를 저장
플래시어텐션(FlashAttention): HBM(고대역폭 메모리) 접근을 최소화해 어텐션 연산을 가속
페이지어텐션(PagedAttention): KV Cache를 OS의 가상 메모리처럼 관리해 메모리 낭비를 줄임
추측 디코딩(Speculative Decoding): 소형 모델이 먼저 초안을 생성하고 대형 모델이 검증

LLM 서빙의 사실상 표준이 된 vLLM 프레임워크를 직접 실행해 볼 수 있는 예제도 포함되어 있습니다.

python -m vllm.entrypoints.openai.api_server \
  --model shangrilar/yi-ko-6b-text2sql \
  --host 127.0.0.1 \
  --port 8888 \
  --max-model-len 1024

3부 — LLM을 활용한 실전 애플리케이션 개발

책에서 가장 실용적인 부분입니다. RAG 파이프라인을 처음부터 끝까지 직접 구축해 볼 수 있도록 안내합니다.

9장. LLM 애플리케이션 개발하기

사용자 인터페이스, 임베딩 모델, 벡터 데이터베이스 등 다양한 구성 요소를 연결하는 오케스트레이션 프레임워크를 비교합니다.

LlamaIndex: 데이터 인덱싱과 검색에 강점
LangChain: 다양한 LLM과 도구를 체이닝
Canopy: 대화형 애플리케이션 특화

벡터 데이터베이스 비교도 간결하게 정리되어 있어 프로젝트에 맞는 도구를 고를 때 참고하기 좋습니다.

구분	제품
오픈소스	Chroma, Milvus, Qdrant
상업용	Pinecone, Weaviate
벡터 기능 추가 DB	ElasticSearch, PostgreSQL, MongoDB, Neo4j

10장. 임베딩 모델로 데이터 의미 압축하기

임베딩 모델의 발전 계보와 두 가지 핵심 방식을 비교한 내용이 인상적이었습니다.

방식	원리	장점	단점
교차 인코더	두 문장을 함께 입력해 직접 비교	정확도 높음	느리고 확장성 낮음
바이 인코더	각 문장을 독립적으로 임베딩 후 거리 계산	빠르고 확장성 높음	상대적으로 낮은 정확도

두 방식을 결합하면 속도와 정확도를 모두 잡을 수 있습니다.

검색 쿼리 → 바이 인코더 → 의미 검색 Top 100 → 교차 인코더 → Re-rank → Top K

원핫 인코딩 → Bag of Words → TF-IDF → Word2Vec(CBOW, Skip-gram) → 트랜스포머 기반 임베딩으로 이어지는 계보도 깔끔하게 정리되어 있습니다.

11장. 자신의 데이터에 맞춘 임베딩 모델 만들기

**대조 학습(Contrastive Learning)**을 활용해 도메인 특화 임베딩 모델을 만드는 방법을 다룹니다. RAG 성능을 끌어올리고 싶다면 꼭 읽어야 할 챕터입니다.

12장. 벡터 데이터베이스로 확장하기

대규모 벡터 데이터베이스에서는 정확도보다 속도를 우선하는 ANN(Approximate Nearest Neighbor) 알고리즘이 쓰인다는 사실을 이 장에서 처음 제대로 이해했습니다.

KNN: 정확하지만 느림 (전수 검색)
IVF(Inverted File Index): 클러스터로 나눠 검색 범위를 줄임
HNSW(Hierarchical Navigable Small World): 그래프 기반 ANN으로 높은 성능과 빠른 검색 속도를 동시에 달성

13장. LLM 운영하기

LLMOps는 기존 MLOps와 두 가지 면에서 다릅니다. 모델 크기가 훨씬 크고 상당수가 API 기반 상업용 모델이라는 점, 그리고 분류·회귀처럼 명확한 지표가 없어 평가가 어렵다는 점입니다.

방법	예시 지표
정량적 지표	BLEU, ROUGE, PPL(Perplexity)
사람 평가	직접 품질 평가
LLM 평가	GPT-4 등으로 자동 채점

RAG 평가 3요소도 실무에서 바로 쓸 수 있는 기준입니다.

신뢰성(Faithfulness): 답변이 검색된 맥락에 근거하는가
답변 관련성(Answer Relevancy): 답변이 질문에 관련 있는가
맥락 관련성(Context Relevancy): 검색된 맥락이 질문에 관련 있는가

4부 — 멀티모달, 에이전트 그리고 LLM의 미래

14장. 멀티모달

구분	모델
상업용	GPT-4V, GPT-4o, Gemini
오픈소스	LLaVA, Fuyu-8B

이미지 입력
  → 모달리티 인코더 (예: CLIP)
  → 입력 프로젝터 (이미지 임베딩 → LLM이 이해하는 텍스트 형식으로 변환)
  → LLM 백본
  → 출력 프로젝터
  → 모달리티 생성기

CLIP: OpenAI가 개발한 이미지 인코더로 이미지를 텍스트와 같은 임베딩 공간에 배치
DALL-E: CLIP의 반대 방향인 텍스트 → 이미지 생성 모델
LLaVA: 이미지를 인식하고 그에 대한 텍스트를 생성하는 오픈소스 멀티모달 모델

15장. LLM 에이전트

에이전트를 구성하는 세 요소가 명쾌하게 정리되어 있습니다.

요소	내용
감각(Perception)	멀티모달 입력으로 환경 인식
두뇌(Brain)	이해, 기억, 지식, 계획
행동(Action)	검색 API 호출, 코드 실행, 이미지/음성 생성, 번역/요약 등

멀티 에이전트 시스템에서 각 에이전트에 서로 다른 역할(profile)을 부여해 협력하는 방식은 책이 출간된 이후로도 빠르게 발전하고 있는 분야라 더욱 흥미롭게 읽었습니다. AutoGen, MetaGPT, CrewAI 등 구현 프레임워크도 간략히 소개합니다.

16장. 새로운 아키텍처 — 맘바(Mamba)

2017년 트랜스포머가 등장한 이후 그 자리를 위협한 맘바(Mamba) 아키텍처로 책이 마무리됩니다.

맘바 = SSM(State Space Model) + 선택 메커니즘

트랜스포머 대비 5배 빠른 추론 속도를 주장하며 등장했지만, 현재(2026년)까지도 트랜스포머 계열 모델이 주류를 이루고 있다는 점에서 새 아키텍처의 자리잡기가 얼마나 어려운지 실감하게 됩니다.

읽고 난 소감

이 책이 좋았던 이유는 단순히 지식을 나열하지 않기 때문입니다. 각 챕터가 “왜 이 기술이 필요한가”라는 질문에 먼저 답하고, 그 맥락 위에서 구현 세부 사항을 설명합니다. 덕분에 개별 기술들이 고립된 지식이 아니라 하나의 큰 흐름 속에서 자연스럽게 자리를 잡습니다.

특히 인상 깊었던 점은 “모델을 잘 만드는 것”과 “모델을 잘 쓰는 것”을 명확히 구분하면서도 두 영역을 하나의 책에서 연결해 설명한다는 점입니다. 대부분의 LLM 책이 둘 중 하나에만 집중하는 경향이 있는데, 이 책은 E2E 흐름 전체를 다룹니다.

아쉬운 점이 있다면, 2024년 7월 출간 시점 이후 LLM 생태계가 빠르게 변해 일부 도구와 프레임워크의 내용이 이미 구버전이 됐다는 것입니다. 하지만 이는 이 분야 책의 숙명이기도 하고, 기술보다는 원리를 중심으로 설명하는 저자의 방식 덕분에 핵심 내용은 여전히 유효합니다.

LLM을 처음 공부하는 분, 혹은 개발 경험은 있지만 LLM의 내부 동작이 궁금한 분 모두에게 권하는 책입니다.

도서 정보

저자: 허정준 지음 | 정진호 그림 | 박재호 감수
출판사: 책만
출간일: 2024년 7월 25일
ISBN: 9791189909703
교보문고: https://product.kyobobook.co.kr/detail/S000213834592
실습 코드: https://github.com/onlybooks/llm

안동소주

Sun, 18 Aug 2024 00:00:00 GMT

지난 주말 안동소주 주문 정보를 정리해두려고 메모를 남긴다. 필요할 때 바로 참고할 수 있도록 연락처, 용량별 가격, 택배비 기준을 한 번에 정리했다.

연락처

054-858-4541

가격

용량 (ml)	가격
400	2만원
600	2.7만원
800	3.3만원

택배비

기본 5병까지 5천원
이후 1병당 1천원씩 증가
택배 중 파손에 대해서는 책임짐

주문 전에 재고와 배송 일정을 먼저 확인하면 더 수월하다.

신뢰할 수 있는 인공지능

Sun, 02 Jun 2024 00:00:00 GMT

ChatGPT가 세상을 뒤흔든 이후로 인공지능은 더 이상 연구실 안의 이야기가 아닌 일상이 됐다. 그런데 매일같이 쏟아지는 AI 뉴스를 보면서 늘 마음 한켠에 불편함이 남았다. “이 기술을 정말 믿어도 되는 걸까?” 한상기 저자의 『신뢰할 수 있는 인공지능』은 바로 그 불편함에 정면으로 답하는 책이다.

저자 한상기는 카이스트에서 컴퓨터공학을 전공하고 테크프런티어 대표로 AI 정책과 산업을 오랫동안 분석해 온 전문가다. 이 책은 단순히 기술적 원리를 설명하는 책이 아니라, 인공지능을 둘러싼 사회적·윤리적·제도적 맥락을 함께 짚어주는 보기 드문 교양서다.

1. 인공지능과 신뢰성 — 왜 지금 이 질문인가

책의 첫 장은 도발적인 질문으로 시작한다. “당신은 AI의 판단을 믿습니까?”

우리는 이미 수없이 많은 AI 판단에 의존하고 있다. 신용카드 이상 거래 탐지, 병원의 영상 진단 보조, 채용 서류 필터링, 재판 보석 여부 예측까지. 문제는 이런 결정들이 우리 삶에 직접적인 영향을 미침에도 불구하고, 그 판단 과정이 블랙박스처럼 불투명하다는 점이다.

저자는 신뢰성(Trustworthiness)을 단일 속성으로 보지 않고 여러 차원이 결합된 개념으로 정의한다. 기술적으로 정확한가, 예상치 못한 상황에서도 안전한가, 사람이 이해할 수 있는 방식으로 작동하는가, 윤리적으로 올바른가 — 이 모든 것이 맞물려야 비로소 신뢰할 수 있는 AI라 부를 수 있다는 것이다.

신뢰는 정확도 수치가 아니라, 실패했을 때 어떻게 행동하는가에서 만들어진다.

이 한 문장이 책 전체의 방향을 잘 압축한다. 99%의 정확도를 자랑하는 모델이라도 나머지 1%의 실패가 치명적이라면, 우리는 그 모델을 신뢰할 수 없다.

2. 윤리와 공정성 — AI가 차별한다

AI 편향(Bias)은 학계에서 오래 논의된 주제지만, 이 책은 사례 중심으로 이를 매우 실감나게 전달한다.

가장 인상 깊었던 사례는 미국의 COMPAS 알고리즘이다. 재범 위험도를 예측해 보석 여부를 결정하는 이 시스템은 흑인 피의자에게 더 높은 위험 점수를 부여하는 경향이 있었고, 이는 인종 차별을 알고리즘으로 제도화한 것이나 마찬가지라는 비판을 받았다. 놀라운 것은, 이 알고리즘이 인종 정보를 직접 사용하지 않았음에도 불구하고 이런 결과가 나왔다는 점이다. 우편번호, 교육 수준, 소득 같은 ‘중립적’ 변수들이 인종과 강하게 상관되어 있었기 때문이다.

이것이 AI 공정성 문제의 핵심 딜레마다. 데이터는 사회의 산물이고, 사회에는 이미 불평등이 내재되어 있다. 과거 데이터를 학습한 AI는 그 불평등까지 학습하게 된다.

저자는 공정성(Fairness)의 수학적 정의가 여럿 존재하며, 이것들이 상호 충돌한다는 점도 지적한다.

공정성 기준	설명	문제점
개인 공정성	유사한 개인에게 유사한 결과	“유사함”의 정의가 어렵다
그룹 공정성	집단 간 결과 분포가 동일	개인 불공정이 생길 수 있다
기회 균등	집단 간 위양성률 동일	음성 예측 정확도는 다를 수 있다
균등 정확도	집단 간 정확도 동일	위양성·위음성 비율이 다를 수 있다

이 네 가지를 동시에 만족하는 것은 수학적으로 불가능하다. 결국 어떤 공정성을 우선할지는 기술이 아니라 사회적 합의의 문제라는 것이 저자의 결론이다.

3. 투명성과 설명 가능성 — “왜 그런 결론을 냈나요?”

딥러닝 모델은 강력하지만 불투명하다. 수십억 개의 가중치가 얽혀 만들어내는 판단을 인간이 직관적으로 이해하기란 어렵다. 이 챕터는 그 문제를 어떻게 해결하려는지, XAI(Explainable AI) 분야의 다양한 시도를 소개한다.

**LIME(Local Interpretable Model-agnostic Explanations)**은 복잡한 모델의 특정 예측 주변을 단순한 선형 모델로 근사해서, “이 입력의 어떤 부분이 이 판단에 영향을 줬는가”를 보여준다. 예를 들어 의료 이미지 분류 모델이 “폐렴 의심”이라고 판단했을 때, 어느 부위를 주목했는지 히트맵으로 시각화할 수 있다.

**SHAP(SHapley Additive exPlanations)**은 게임 이론의 샤플리 값에서 아이디어를 가져온다. 각 특성(feature)이 예측 결과에 기여한 정도를 수치로 나타내어, “당신의 대출이 거절된 가장 큰 이유는 소득 대비 부채 비율(DTI)이 높기 때문입니다”처럼 설명하는 것이 가능해진다.

저자는 EU의 GDPR이 “자동화된 결정에 대한 설명 요구권”을 명시한 것을 언급하면서, 설명 가능성이 더 이상 연구자들의 관심사가 아니라 법적 의무가 되고 있음을 강조한다.

그러나 설명 가능성에도 한계는 있다. 사후 설명(post-hoc explanation)은 실제 모델의 작동 방식이 아니라 근사일 뿐이며, 설명이 너무 단순화되면 오히려 사용자에게 잘못된 확신을 줄 수도 있다. 투명성과 성능 사이의 긴장은 아직 해소되지 않은 과제다.

4. 견고성과 안전성 — 의도하지 않은 실패와 의도적인 공격

AI 시스템이 예상치 못한 상황에서 얼마나 안정적으로 작동하는가, 그리고 악의적인 공격에 얼마나 저항할 수 있는가. 이 챕터는 기술적으로 가장 흥미로운 내용을 담고 있다.

**분포 이탈(Distribution Shift)**은 현실에서 가장 자주 마주치는 문제다. 맑은 날 도로 사진으로 학습한 자율주행 모델은 폭설이나 안개 상황에서 성능이 급격히 저하될 수 있다. 학습 환경과 실제 배포 환경이 다를 때, 모델은 조용히 실패한다.

**적대적 공격(Adversarial Attack)**은 더 무서운 문제다. 사람 눈에는 전혀 차이가 없어 보이는 미세한 픽셀 변조만으로도 이미지 분류 모델을 완전히 속일 수 있다. 판다 사진에 노이즈를 추가했더니 모델이 긴팔원숭이라고 99% 확신으로 분류했다는 유명한 예시가 있다. 자율주행 차의 정지 표지판에 스티커를 붙여 속도 제한 표지로 인식하게 만들 수 있다는 연구 결과도 있다.

저자는 이에 대한 방어 전략들을 소개한다.

적대적 훈련(Adversarial Training): 의도적으로 공격 샘플을 훈련 데이터에 포함시켜 모델을 강화하는 방법
인증된 방어(Certified Defense): 입력이 특정 범위 내에서 변조되더라도 예측이 바뀌지 않음을 수학적으로 보장하는 방법
앙상블 방어: 여러 모델을 조합해 단일 모델 공격의 영향을 줄이는 방법

안전한 AI를 만드는 것은 단순히 성능 지표를 높이는 것과는 다른 차원의 작업이다. 이 챕터를 읽으면서 AI 시스템을 설계할 때 “얼마나 정확한가”뿐 아니라 “어떤 방식으로 실패하는가”를 함께 고려해야 한다는 관점이 생겼다.

5. 미래 전략과 관련 기업 — 신뢰를 어떻게 경쟁력으로 만들 것인가

마지막 챕터는 조금 더 실용적이고 전략적인 시각을 제시한다. 신뢰할 수 있는 AI가 단순한 윤리 구호가 아니라, 기업과 국가에게 실질적인 경쟁력이 될 수 있다는 주장이다.

규제 환경의 변화를 먼저 짚는다. EU AI Act는 AI 시스템을 위험도에 따라 분류하고, 고위험 AI에는 엄격한 투명성·설명 가능성·견고성 요건을 부과한다. 의료, 금융, 채용, 사법 분야의 AI는 사실상 XAI와 감사(Audit) 기능이 의무화되는 방향이다. 미국도 AI 집행명령(Executive Order on AI)을 통해 안전성과 신뢰성 기준 마련을 서두르고 있다.

글로벌 기업들의 접근 방식도 흥미롭다.

기업	신뢰 AI 접근 방식
Google	책임 있는 AI 원칙 7가지 공개, 모델 카드(Model Card) 도입
Microsoft	AI 책임 프레임워크, Azure에 공정성 측정 툴킷 내장
IBM	AI Fairness 360, AI Explainability 360 오픈소스 공개
Anthropic	헌법 기반 AI(Constitutional AI)로 안전성 내재화 시도

저자는 한국 기업들에게도 시사점을 제시한다. 글로벌 시장에서 경쟁하려면 기술 성능만큼이나 신뢰성 인증과 설명 가능성 대응이 필수 역량이 될 것이라는 전망이다. “AI 윤리팀이 별도로 있는 것”이 아니라, 개발 과정 전반에 신뢰성 관점이 내재화되어야 한다고 강조한다.

책을 덮으며

이 책을 읽으면서 가장 크게 바뀐 생각은, AI의 신뢰 문제가 기술자만의 문제가 아니라는 것이다. 공정성을 어떻게 정의할지, 어떤 설명을 요구할지, 실패를 어디까지 허용할지는 결국 사회적 합의의 문제다. 기술은 그 합의를 구현하는 도구일 뿐이다.

개발자로서 성능 지표와 마감에 쫓기다 보면 “이 모델이 어떻게 실패할 수 있는가”를 깊이 생각하지 못할 때가 많다. 이 책은 그 질문을 다시 꺼내 들게 한다. 기술적으로 정확한 AI보다 사람이 믿을 수 있는 AI를 만드는 것이 더 어렵고, 동시에 더 중요한 일이라는 것을.

AI를 개발하거나 도입하는 조직에 있다면, 기술 문서만큼이나 이 책을 권하고 싶다.

References

한상기, 『신뢰할 수 있는 인공지능』, 클라우드나인, 2023
EU AI Act 전문
Google AI 원칙
IBM AI Fairness 360
LIME 논문: “Why Should I Trust You?” (Ribeiro et al., 2016)
SHAP 논문 (Lundberg & Lee, 2017)

영어 회화 과외

Mon, 20 May 2024 00:00:00 GMT

숨고 앱을 통해 견적을 받음

이름	비용(시간 당)	검토	의견
HD 영어	14만원	X	너무 비싸고, 지역은 일산, 온라인만 가능
Alex Ha	5만원	P	망포역 부근 아파트, 오프라인 가능
Roy KHY	2.5만원	X	가격이 저렴, 2시간에 5만원, 지역은 청주, 온라인만 가능
Edward	2.5만원	P	가격이 저렴, 원어민, 내용 좋음, 여러 강사
월시 잉글리시	5만원	A	미국 교포, 광교 위치, `5/22 만난 후 결정`
조다솜	5.5만원	X	동탄 위치, 금액이 오버됨
Jupiter	33만원/한달	X	성수동 위치, 금액도 비싸고 오프라인도 안됨
이수림	5만원	X	응답이 없음
Leah	5만원	X	영어강사, 사업자번호 없음, 개인계좌 결제 불가

예상 질문지

당연히 도와드리겠습니다! 영어회화를 개선하고자 하는 목적에 따라 질문을 선택할 수 있습니다. 아래는 몇 가지 추천 질문입니다:

“What motivated you to become an English teacher?” 이 질문은 선생님의 열정과 경험에 대해 알아보는 좋은 시작점입니다.
“How do you tailor your teaching approach to different learning styles?” 학생들의 학습 스타일에 맞게 수업을 진행하는 방법에 대해 물어보세요.
“What strategies do you use to help students improve their speaking fluency?” 선생님이 학생들의 말하기 능력을 향상시키기 위해 사용하는 전략에 대해 알아보세요.
“Could you share any success stories of students who significantly improved their conversational skills under your guidance?” 선생님이 지도한 학생 중에서 대화 능력이 크게 향상된 사례를 들려주실 수 있을까요?
“How do you incorporate real-world topics and current events into your lessons?” 선생님이 수업에서 현실적인 주제와 최신 이슈를 어떻게 활용하시는지 물어보세요.

또한, 영어회화를 연습하고 싶다면 영어 랜덤 질문 사이트1를 활용해보는 것도 좋은 방법입니다. 이 사이트에서는 다양한 주제의 영어 질문을 제공하며, 자유롭게 대화를 나눌 수 있습니다. 행운을 빕니다! 😊

제텔카스텐을 시작하며

Fri, 03 May 2024 00:00:00 GMT

오늘부터 메모를 단순 보관이 아니라 생각을 연결하는 시스템으로 바꾸기 위해 제텔카스텐 방식을 적용해 보기로 했다. 기존에는 읽은 내용을 파일 단위로 쌓아두기만 했고, 시간이 지나면 다시 찾기 어려웠다. 이번에는 노트를 짧게 쪼개고 서로 연결해서, 나중에 글로 발전시키기 쉬운 형태를 목표로 한다.

적용 원칙

한 노트에는 한 가지 아이디어만 담는다.
제목은 나중에 검색해도 바로 이해되는 문장으로 작성한다.
노트를 저장할 때 최소 1개 이상의 관련 노트 링크를 붙인다.
읽은 자료 요약(문헌 노트)과 내 생각(영구 노트)을 분리한다.
매일 10~20분이라도 노트 정리 시간을 따로 확보한다.

폴더/파일 운영 초안

inbox/: 빠르게 적는 임시 메모
literature/: 책, 글, 영상에서 가져온 요약 메모
permanent/: 내 언어로 다시 쓴 핵심 노트
index/: 주제별 진입점 노트

이 구조는 시작점일 뿐이고, 실제 사용하면서 복잡해지면 줄이고 필요하면 확장할 예정이다.

오늘의 결론

완벽한 도구보다 중요한 건 짧은 단위로 계속 쓰고 연결하는 습관이다. 이번 달 목표는 영구 노트 30개를 만들고, 그중 3개 이상은 실제 블로그 글로 확장하는 것이다.

참고 자료

인공지능 대학원

Sun, 18 Feb 2024 00:00:00 GMT

한양대학교 인공지능융합대학원

한양대학교 인공지능융합대학원 (hanyang.ac.kr)
거리는 멀지만, 온라인 수업을 지원함 (8:2 비율)
교육과정이 기본에 충실

카이스트 김재철AI대학원

석사 학위도 주어지고, 매주 목요일 저녁만 참석하면 된다는 장점
지원자격이 중견관리자 인데 이 부분은 구체적인 확인이 필요

연세대 인공지능대학원

연세대학교 공학대학원 (yonsei.ac.kr)
전형 방법
- 1차 : 서류 심사
- 2차 : 면접 심사
비용
- 입학금 : 1,195,000원
- 등록금 : 9,867,000원
- 졸업까지의 비용(순수 등록금 기준, 4학기제) : 40,663,000원
개강 및 수업일
- 강의 개설 : 월, 화, 목
- 강의 시간 : 야간강의 1교시(18:50~~20:20), 2교시(20:30~~22:00)
- 한 학기 수업 시수 : 6시간(3과목)
- 이수학점 : 논문 없음, 30학점 이수 (전공학점 10학점 이상)
- 논문졸업자 또는 교과졸업자 동일한 공학석사 학위증 수여
거리가 너무 멀어 어려움

고려대 특수대학원 인공지능융합학과

고려대학교 컴퓨터정보통신대학원 (korea.ac.kr)
전형 방법
- 1차 : 서류 심사
- 2차 : 면접 심사
비용
- 입학금 : 1,234,000원
- 등록금 : 6,563,000원
- 졸업까지의 비용(순수 등록금 기준, 5학기제) : 34,049,000원
개강 및 수업일
- 개학일 : 2022년 3월 1일
- 강의 개설 : 월, 화, 목
- 강의 시간 : 야간강의 1교시(18:45~~20:15), 2교시(20:20~~21:50)
- 한 학기 수업 시수
  - 이수학점 : 논문졸업자 (26학점 이수), 교과졸업자 (30학점 이수)
  - 논문졸업자 또는 교과졸업자 동일한 공학석사 학위증 수여
거리가 너무 멀어 어려움

국민대 소프트웨어융합대학원

국민대학교 소프트웨어융합대학원 (kookmin.ac.kr)
여름학기 포함 1.5년이면 졸업 & 교과졸업 가능
비용
- 입학금 : 1,029,000원
- 등록금 : 5,981,000원
- 졸업까지의 비용(순수 등록금 기준, 4학기제) : 24,953,000원
개강 및 수업일
- 개학일 : 2022년 3월 1일
- 강의 개설 : 매주 토요일
- 강의 시간 : 토요일 1교시(09:00~~10:40), 2교시(11:00~~12:40), 3교시(14:00~~15:40), 4교시(16:00~~17:40)
- 한 학기 수업 시수
  - 이수학점 : 논문졸업자 (24학점 이수), 교과졸업자 (24학점 이수, 프로젝트 or 현장실습 대체인듯)
  - 논문졸업자 또는 교과졸업자 동일한 공학석사 학위증 수여

경희대 AI 대학원 (야간 X)

http://gsai.khu.ac.kr/03/01.php
위치가 가장 가까움, but 야간 특수대학원이 없는 것으로 보임
전화 문의 필요함: 031-201-5350

성균관대 인공지능학과 (야간 X)

성균관대학교 인공지능대학원 (skku.edu)
일반대학원만 인공지능이 있고, 야간은 없는 것으로 보임

Redis 데이터타입

Wed, 13 Sep 2023 00:00:00 GMT

Redis란

Redis는 Remote Dictionary Server의 약자로, 인메모리 데이터베이스이다. 인메모리 데이터베이스란 데이터를 디스크나 SSD가 아닌 메모리에 저장하는 데이터베이스를 말한다. 이렇게 하면 디스크 I/O를 줄여서 빠른 응답 속도를 얻을 수 있다. Redis는 단순한 키-값 저장소가 아니라 다양한 데이터 타입을 지원한다. 이번 포스트에서는 Redis의 주요 데이터 타입과 그 사용법에 대해 알아보겠다.

Sentinel vs Cluster

Redis Sentinel: Redis 인스턴스를 모니터링하고, 마스터 선출, 자동 장애 조치, 알림 등의 기능을 제공
Redis Cluster: Redis 인스턴스를 여러 개의 노드로 분산시켜 데이터를 저장하고, 자동 장애 조치, 샤딩(Sharding) 등의 기능을 제공

특징	Redis Sentinel	Redis Cluster
고가용성	마스터 선출, 자동 장애 조치	자동 장애 조치
분산 방식	단일 노드	여러 노드
샤딩	지원하지 않음	지원
데이터 구조	다양한 유형 지원	다양한 유형 지원
멀티 스레딩	No	Yes

Redis vs Memcached

특징	Redis	Memcached
문서화	Comprehensive	Limited
데이터 구조	다양한 유형 지원	이진 문자열만 지원
멀티 스레딩	No	Yes
성능	작은 데이터 저장에서 우수	대량의 데이터 저장에서 우수
클러스터	Yes	No
인기도	8th most popular database in the world1	28th most popular database in the world

데이터타입

Redis의 데이터 타입은 크게 다섯 가지로 나눌 수 있다. 바로 문자열(String), 리스트(List), 해시(Hash), 셋(Set), 정렬된 셋(Sorted Set)이다. 각각의 데이터 타입은 다음과 같은 특징과 용도를 가지고 있다.

문자열(String)

가장 기본적인 데이터 타입으로, 키와 값이 모두 문자열로 구성
값은 최대 512MB까지 저장
단순한 텍스트 뿐만 아니라 이미지, 비디오, 오디오 등의 바이너리 데이터도 저장 가능
카운터, 캐싱, 세션 관리 등에 사용 가능

리스트(List)

문자열의 컬렉션으로, 키 하나에 여러 개의 값이 연결된 형태
값은 최대 4억 개까지 저장
삽입 순서를 유지하며, 키의 앞과 뒤에서만 값을 추가하거나 제거 가능
스택, 큐, 메시징 등에 사용 가능

해시(Hash)

키-값 쌍의 컬렉션으로, 키 하나에 여러 개의 필드와 값이 연결된 형태, 필드와 값은 모두 문자열로 구성
값은 최대 4억 개까지 저장
객체나 구조체와 같은 복합적인 데이터를 표현하기에 적합하다. 해시 타입은 사용자 프로필, 상품 정보, 설정 등에 사용될 수 있다.

셋(Set)

중복되지 않는 문자열의 컬렉션으로, 키 하나에 여러 개의 값이 연결된 형태
값은 최대 4억 개까지 저장
삽입 순서를 유지하지 않으며, 값의 존재 여부를 빠르게 확인 가능
태그, 소셜 그래프, 실시간 분석 등에 사용 가능

정렬된 셋(Sorted Set)

셋과 비슷하지만, 각 값에 점수(score)라는 부가 정보가 추가된 형태
점수는 실수로 표현되며, 값들은 점수를 기준으로 오름차순으로 정렬
랭킹, 리더보드, 지역 정보 등에 사용 가능

Google 면접 코딩 - 문자열을 float로 파싱하기

Wed, 14 Jun 2023 00:00:00 GMT

면접 중 간단하지만 구현 디테일을 보기 좋은 문제 중 하나가 문자열을 실수(float)로 직접 파싱하는 문제이다.

예를 들어 "-12.34"를 입력받아 -12.34를 반환해야 한다. 이번 글에서는 parseInt, parseFloat 같은 내장 변환 함수 없이 직접 구현하는 아이디어를 정리한다.

문제

입력: 부호(-), 소수점(.), 숫자로 이루어진 문자열
출력: 해당 문자열을 float 값으로 변환한 결과

예시

"1.23" -> 1.23
"-12.34" -> -12.34

아이디어

핵심은 두 가지이다.

- 부호를 먼저 확인해서 음수 여부를 저장
숫자만 따로 모은 뒤, 소수점 이하 자릿수를 이용해 자리값을 계산

기존 메모처럼 스택을 사용하면, 뒤에서부터 꺼내면서 10의 거듭제곱을 곱해 합산할 수 있다.

예: "12.34"
- 숫자 스택: 1, 2, 3, 4
- 소수 자릿수 카운트: 2
- 계산:
  - 4 * 10^-2 = 0.04
  - 3 * 10^-1 = 0.3
  - 2 * 10^0 = 2
  - 1 * 10^1 = 10
- 합: 12.34

Java 예시 코드

import java.util.Stack;

public class AtofParser {
    private static final char SIGN = '-';
    private static final char POINT = '.';

    public static float atof(final String str) {
        boolean isMinus = false;
        boolean countDecimal = false;
        int decimalCount = 0;

        Stack<Integer> stack = new Stack<>();

        if (str.length() > 0 && str.charAt(0) == SIGN) {
            isMinus = true;
        }

        for (int i = 0; i < str.length(); i++) {
            char ch = str.charAt(i);

            if (countDecimal) {
                decimalCount++;
            }

            if (ch == SIGN) {
                continue;
            } else if (ch == POINT) {
                countDecimal = true;
                decimalCount--; // 소수점 자체는 숫자가 아니므로 보정
            } else {
                stack.push(ch - '0');
            }
        }

        float sum = 0f;
        int size = stack.size();

        for (int i = 0; i < size; i++) {
            int number = stack.pop();
            sum += (float) (number * Math.pow(10, -1 * decimalCount));
            decimalCount--;
        }

        return isMinus ? -sum : sum;
    }
}

복잡도

스택에 push: O(n)
스택에서 pop하며 계산: O(n)
전체: O(n)

마무리

이 문제의 포인트는 “문자열 파싱을 단계별로 분리하는 능력”이다.

부호 처리
소수점 위치 처리
자리값 계산

실무에서는 내장 함수를 쓰는 것이 일반적이지만, 면접에서는 이런 구현을 통해 기본기와 사고 과정을 확인할 수 있다.

인증과 전자서명

Fri, 02 Jun 2023 00:00:00 GMT

양방향 암호화

내가 보낸 데이터를 중간에서는 모르게, 받은 사람은 알 수 있게 하는게 목적
이때, 암호화 키를 교환하기 위한 방식으로 다시 2가지로 나뉨

대칭키 vs 공개키(비대칭키) 암호화

방식	대칭키	공개키(비대칭키)
설명	암복호화에 사용되는 키가 동일	암복호화에 사용되는 키가 다름
대표 알고리즘	DES,AES,SEED	RSA,DSA
장점	빠름	느림
단점	키교환의 취약성	키교환의 안정성

공개키 암호화 활용

키가 2개라는 거지 어떤걸 공개키로 사용해도 무관
- 상대에게 주는 것 공개키, 내가 가지는 것 비밀키
2가지 방식으로 활용이 가능
- 내 비밀키로 복호화: 누구나 암호화된 메시지를 보내고, 나만 열어 볼 수 있음
- 내 비밀키로 암호화: 누구나 복호화하여 볼 수 있는 메시지를 받고, 나만이 만들 수 있음

단방향 암호화

복호화가 불가능한 해시를 생성하고 이 값으로 변조되지 않았음을 증명
활용하는 대표적인 사례
- 패스워드 암호화 ~~몇 글자 다른지 알면 양방향으로 저장하는 것~~
- 전자서명
대표적인 알고리즘
- MD5, SHA128, SHA256, SHA384, SHA512
참고로, base64는 인코딩/디코딩이 가능하며 해시와는 다름

디지털 서명

위키백과 정의
- 네트워크에서 송신자의 신원을 증명하는 방법으로, 송신자가 자신의 비밀키로 암호화한 메시지를 수신자가 송신자의 공용 키로 해독하는 과정
디지털 서명은 일반적으로 다음의 세 가지 알고리즘
- 키 생성 알고리즘 ex) 공개키 암호화
- 서명 생성 알고리즘 ex) 단방향 해싱 암호화 + 비밀키
- 서명 검증 알고리즘 ex) 단방향 해싱 암호화 + 공개키
디지털 서명 vs 전자 서명
- 디지털서명: 송신자가 자신의 신원을 증명하는 절차
- 전자서명: 그 절차의 특정 단계에서 사용하는 정보

프로세스

송신자
1. 원본 문서(평문)을 해싱
2. 해싱된 문서 데이터를 비밀키로 암호화
3. 암호화된 전자 서명(해시)를 문서에 첨부
수신자
1. 수신 문서(평문)을 해싱
2. 첨부된 전자 서명(해시)을 공개키로 복호화
3. 위 1,2번 값이 같은지 비교

인증과 서명

위에서 봤던 서명의 방식을 바탕으로 다양한 형태의 활용 방법이 개발됨
- 사용자 인증 정보를 서명하여 위변조 걱정 없이 토큰에 싣거나
- 인터넷에 공개된 API에서 인증된 단말기의 요청의 위변조를 검토하거나
디지털 서명처럼 복호화 할 필요는 없음
- 단지 위변조만 검사하면 되기 때문에 해시가 같은지만 보면 됨
- RSA 사용하지 않기 때문에 더 빠름

JWT

인증 정보를 지속하는 대표적인 방법으로 쿠키, 세션, 토큰이 있음
- 어떤 방법이든 해당 정보의 주인을 확인하기 위해 DB에 대한 IO가 필요했음
그럼 이런 정보를 모두 토큰에 담아두면 어떨까?
- 토큰에 사용자 정보를 노출하면 위변조 되었을 경우 위험성 존재
- 이를 해결하기 위해 토큰에 서명을 같이 첨부
JWT 구조
HTTP 헤더 샘플 (RFC 6750 Bearer 타입) Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
인증서버 병목 이슈
- HS256(HMAC+SHA256) 방식을 사용하면, 대칭키를 배포된 모든 서버에서 공유 or 인증서버 병목
- RS256(RSA+SHA256) 방식을 통해, 인증서버가 토큰을 발급(비밀키)하고 서비스에서 검증(공개키)
  - public key 조회하는 API를 인증서버가 제공
  - 서비스는 한 번만 인증서버와 통신해서 public key를 가져오면 됨

HMAC

HMAC = Hash(Message, Key) + Message
공유키를 이용하여 전달할 메시지의 해시값을 양쪽에서 생성하여, 메시지의 위변조 여부를 판단
Replay Attack
- 공격자는 메시지 변조는 못해도, 동일한 메시지를 계속 활용 가능
- HMAC 대상 메시지에 timestamp를 포함, 특정 시간 지난 후 무효화 시킴
자세한 내용은 MLOps 자율주행차량 API 연동 설계 참고

(opt) 보안 관련 용어

SSL: 대칭키와 공개키 암호화의 장점을 모두 활용한 방법
- 키교환이 안전한 공개키 방식으로 대칭키를 최초 한 번 교환
- 이후 통신에서는 각 엣지에서 속도가 빠른 대칭키 방식으로 암호 통신
TLS: SSL의 개선된 버전
HTTPS: HTTP 통신에 SSL/TLS가 적용된 버전
MITM: 중간 트래픽에서 가짜 인증서를 보낸 뒤 HTTPS 통신을 복호화
RootCA: 신뢰할 수 있는 제3의 인증기관을 두어 MITM 무력화
인증서 체인: 인증서를 신뢰할 수 있도록 서명으로 만들어진 체인

참고

Golang 학습 아카이브

Tue, 28 Mar 2023 00:00:00 GMT

Go를 제대로 공부해보고 싶었다. 이름은 오래전부터 알고 있었는데, 주변에서 쓰는 곳이 점점 늘어나니 더 이상 미루기 어렵다는 생각이 들었다. learning-golang이라는 이름으로 저장소를 만들고 공식 문서와 예제를 따라가면서 사흘 동안 기본기를 익혔다.

프로젝트 레이아웃

처음부터 Standard Go Project Layout을 기준으로 잡았다. 학습용이지만 실제 구조에 익숙해지는 게 낫겠다는 판단이었다.

learning-golang/
├── cmd/
│   ├── hello/          # 기본 패키지 호출 예제
│   ├── rest/           # Echo 기반 REST 서버
│   └── rest-failed/    # CockroachDB 연동 시도 (미완성)
├── pkg/
│   ├── greetings/      # Hello 함수 + 테스트
│   └── music/          # 맵 활용 예제
├── internal/
│   └── dict.go         # 내부 유틸리티 (Keys, Values)
├── Dockerfile
└── docker-compose.yml

cmd에 진입점을 두고, pkg에는 외부에서 쓸 수 있는 패키지를, internal에는 이 모듈 안에서만 쓸 유틸리티를 넣었다. Go의 internal 패키지는 상위 모듈 밖에서는 임포트가 안 된다. 직접 확인해보니 컴파일 에러로 막힌다.

패키지 구조

pkg/greetings는 공식 Go 튜토리얼(go.dev/doc)에서 처음 나오는 예제다. 이름을 받아서 인사 문자열을 반환하는 함수인데, 에러 처리를 함께 보여준다는 점이 인상적이다. Java나 Python에서는 예외를 던지는 게 보통인데, Go는 에러를 반환값으로 명시적으로 돌려주는 방식이라 코드 흐름이 훨씬 눈에 잘 들어온다.

func Hello(name string) (string, error) {
    if name == "" {
        return "", errors.New("empty name")
    }
    message := fmt.Sprintf("Hi, %v. Welcome!", name)
    return message, nil
}

pkg/music은 map을 써보기 위해 만든 예제다. 가수와 노래 제목을 매핑해두고 조회하는 구조다. internal.Keys와 internal.Values를 호출해서 internal 패키지 연결이 잘 되는지도 확인했다.

cmd/hello에서는 greetings, music, 그리고 외부 패키지인 rsc.io/quote를 모두 불러와서 한꺼번에 출력한다.

테스트

Go 테스트는 별도 프레임워크 없이 표준 라이브러리 testing만으로 작성한다. greetings_test.go에 두 가지 케이스를 넣었다. 정상 이름을 넣었을 때 응답에 그 이름이 포함되는지 정규식으로 검증하고, 빈 문자열을 넣었을 때 에러가 반환되는지 확인한다.

func TestHelloName(t *testing.T) {
    name := "Gladys"
    want := regexp.MustCompile(`\b` + name + `\b`)
    msg, err := Hello("Gladys")
    if !want.MatchString(msg) || err != nil {
        t.Fatalf(`Hello("Gladys") = %q, %v, want match for %#q, nil`, msg, err, want)
    }
}

t.Fatalf로 실패 메시지를 포맷팅해서 출력한다. 테스트 실패 시 어떤 값이 들어왔고 무엇을 기대했는지 한눈에 보이게 쓰는 게 Go 테스트의 관행인 것 같다.

Docker 연동

Dockerfile은 golang:1.20-alpine 기반으로 빌드하고, ARG module로 어떤 cmd를 빌드할지 선택할 수 있게 했다.

ARG module=rest
RUN go build -o main ./cmd/${module}

빌드 시 --build-arg module=hello처럼 넘기면 원하는 커맨드를 이미지로 만들 수 있다. 기본값은 rest다.

docker-compose.yml에는 Echo 서버와 CockroachDB를 함께 띄우는 구성을 넣었다. 환경 변수로 DB 접속 정보를 주입하고, 서버가 DB보다 먼저 뜨는 상황을 backoff로 재시도하는 방식이다.

CockroachDB 연동 시도

cmd/rest-failed가 이름 그대로다. Echo + CockroachDB + cockroach-go 드라이버를 연결해서 메시지를 저장하고 조회하는 REST API를 만들려 했는데, 로컬 환경에서 CockroachDB 접속이 제대로 안 된다. 디버그 로그만 잔뜩 남긴 채 멈춰있다.

err = backoff.Retry(openDB, backoff.NewExponentialBackOff())

재시도 로직은 cenkalti/backoff를 써서 지수 백오프로 구현했다. 연결은 아직 못 잡았지만 트랜잭션 처리를 crdb.ExecuteTx로 감싸는 패턴은 눈에 익었다.

마치며

사흘 동안 Go의 핵심 개념 몇 가지를 잡았다. 에러를 반환값으로 다루는 방식, internal 패키지로 접근 범위를 제어하는 방법, 표준 라이브러리만으로 충분한 테스트 환경, 그리고 멀티 스테이지 없이도 간결한 Dockerfile. 일단 여기서 마무리하고 다음 단계로 넘어가려 한다.

References

한글 이름 풀이

Fri, 12 Aug 2022 00:00:00 GMT

한글이름풀이 인터넷한글이름풀이 이름풀이 - 한자이름뜻풀이 (beautyname.net)

한글 이름의 음오행에 따른 풀이인데, 그냥 한번 재미로 해보기 좋았네요.

간편결제, 충전금, 그리고 루나

Mon, 30 May 2022 00:00:00 GMT

간편결제 사업을 보면 결국 핵심은 기술보다 가맹점과 사용처다. 결제 버튼은 누구나 만들 수 있지만, 사람들이 실제로 돈을 쓸 수 있는 생태계는 쉽게 만들어지지 않는다. 네이버페이가 쇼핑과 결합했을 때 강했던 이유도, 결제 경험과 소비처를 동시에 확보했기 때문이다.

수익 구조를 보면 더 분명해진다. 가맹점 수수료는 기본이지만, 간편결제에서 진짜 힘을 발휘하는 건 충전금이다. 이용자가 미리 넣어둔 돈은 서비스 사업자 입장에서 유동성과 이자 수익의 원천이 된다. 스타벅스 충전금 이자 사례가 자주 언급되는 것도 같은 맥락이다. 반대로 신용카드는 선충전 구조가 아니기 때문에 이 구간의 이점이 거의 없다.

이 지점에서 자연스럽게 스테이블코인 이야기가 이어진다. 디지털 결제를 확장하려는 시도는 결국 “변동성이 낮은 디지털 돈”에 대한 욕망으로 연결되기 때문이다. 문제는 이름이 ‘스테이블’이어도 안정성은 설계와 신뢰에 달려 있다는 점이다.

루나·테라 사태는 그 사실을 가장 극적으로 보여줬다. 알고리즘만으로 가치를 유지할 수 있다는 약속은 시장 신뢰가 꺾이는 순간 빠르게 무너졌다. 기술은 화폐를 보조할 수 있지만, 화폐 그 자체의 신뢰를 대체하지는 못한다는 교훈을 남겼다.

돌아보면 간편결제의 본질은 복잡하지 않다. 더 편한 UX, 더 넓은 사용처, 더 단단한 신뢰. 이 세 가지 중 하나라도 무너지면 성장 서사는 오래가지 못한다.

참고 링크

입만 열면 손해보는 사람들을 위한 대화책

Fri, 22 Apr 2022 00:00:00 GMT

난 회사 라이브러리를 종종 애용하는데, 가끔은 기술책이 아닌걸 빌릴때가 있다. 신간이 들어왔다고 메일이 왔길래 우연히 보게된 책의 제목이 흥미로워서 빌리게 된 책이다. 어쩌면 지금쯤 나에게 뭔가 필요하다고 느껴지는 책인거 같았다.

저자는 일본인이다. 그러다 보니 책의 곳곳에 일본식 대인관계를 기반으로 한 내용들이 종종 보였다. 그런 몇가지 점을 제외한다면 이 책에서 말하고자 하는 메시지는 큰 맥락에서 통한 것 같다. 결론부터 말하자면 상대를 안심시켜 주고, 끝까지 잘 들어준다가 핵심이다.

집중해야 할 키워드는 안심감과 자기중요감

책의 초반부에 이미 핵심 키워드가 모두 나와있다. 뒤쪽에 할애된 분량은 이에 대한 상세한 가이드와 같다. 크게 로드맵을 짜주고 이제 상세한 내용으로 구술하는 식의 책의 구성이 참 마음에 들었다. 1부에서 이렇게 방향을 잡아주고 2부와 3부에서 몇가지 방법을 제시한다.

2부. 안정감을 주는 스킬

절대 부정하지 마라
이야기를 끝까지 들어라
미소를 지어라
타인을 뒤에서 비판하지 마라

3부. 상대의 자존감을 높여주는 스킬

이름을 자주 부르자
칭찬하라
지적은 단 둘이 있을때 하라
타이밍에 맞게 말하라

그리고 4부, 5부에서는 그 외 추가적인 대화의 기술이나 상대방의 마음을 움직이는 방법 등을 알려준다.

책의 분량이 그리 크지 않아서 주말에 2시간 정도면 완독할 수 있다. 일련의 자기개발서라고 생각할 수도 있지만, 한번쯤 나의 대화법을 회고하기엔 좋은 시간 투자일 것 같은 책이었다.

NFT 민트 개발

Tue, 22 Mar 2022 00:00:00 GMT

이 포스트는 NFT를 직접 개발하기 위한 내용을 담고 있습니다.

개발 환경

Hardhat
- dApp 개발 프레임워크
- 대체 가능: Truffle
- 후발주자로서 Truffle 보다 사용이 더 쉽다고 함
Alchemy
- 블록체인 개발 플렛폼: dApp을 만들어 블록체인 연동을 쉽게 할 수 있도록 도와줌
- 대체 가능: Infura
Metamask
- 암호화폐 지갑 & 블록체인 앱 연동 툴
- 대체 가능: Coinbase Wallet, WalletConnect, Fortmatic 등
Ropsten Test Network
- 이더리움 테스트넷 중 하나
- 대체 가능: Kovan, Rinkeby, Goerli

사전 준비

metamask 지갑
faucet 충전

개발

스마트 컨트랙트

NFT 민트

지갑에 넣기

Jekyll에서 Gatsby 블로그로 변경

Tue, 08 Mar 2022 00:00:00 GMT

이미 얼마 전부터 블로그를 손봐야 겠다는 생각은 많이 했었다. 그동안 설치형 블로그를 많이 사용했었다. 블로그를 적극적으로 하는 스타일은 아니지만 그래도 꽤 오랫동안 다양하게 사용해 봤다.

블로그 짬밥

	도구	형태	언어	특징
1	태터툴즈	설치형	PHP	학부 시절 순수 PHP에 대한 재미로 국산 블로그 소프트웨어 설치하면서 시작
2	티스토리	서비스		호스팅, DB 관리가 귀찮아서, 태터툴즈 DB를 티스토리 서비스로 마이그레이션
3	워드프레스	설치형	PHP	세계적으로 검증된 CMS 툴로서 설치형을 지원
4	워드프레스	서비스		호스팅, DB 관리가 귀찮아서~~역사의 반복~~, 워드프레스 서비스형으로 데이터 이관
5	Hugo	설치형	Ruby	정적 사이트 생성기라는 신선한 개념을 처음 알게되고 개별 포스트를 작성
6	Jekyll	설치형	Ruby	Markdown 편집이라 개발자 친화적이며 호스팅 없이 gh-phage 활용 가능 관련글: Wordpress 블로그 Jekyll로 가져오기

Jekyll로 넘어가는 과정에서 MySQL DB에 있던 내용들을 모두 .md 파일로 변환하는 작업을 했다. 다행이 Wordpress를 Markdown으로 변환해주는 툴 덕분에 쉽게 할 수 있었다. 그렇게 지금까지 사용했던 블로그 https://gizrak.github.io/ 를 만들었다.

꽤 오랜기간 블로그라는걸 운영을 해왔지만 사실 한가지 근본적인 아쉬움은 있었다. 그냥 툴을 사용하는 입장에서 매뉴얼대로 설치하고 사용하는 것 뿐이었다. PHP와 Ruby가 전혀 어색한 언어는 아니었지만 굳이 깊이 파고들 만큼 열정이나 지식을 가지고 있지는 않았다. 쓰는 정도로만 충분했죠.

Gatsby 블로그

그래서 최근에 눈여겨보던 플랫폼이 바로 Gatsby 였다. 무엇보다 익숙한 자바스크립트 언어를 기반으로 했고, 리액트에서 파생된 CMS 플랫폼이었기 때문이다. 공식 사이트에서 gatsby-starter-blog 를 제공해 주는데, 뭔가 책에서 나오는 샘플 예제 수준이라 이걸로 하기엔 좀 아쉬웠다.

줌코딩 블로그 템플릿

그러다 줌코딩 님이 개발하신 gatsby-blog 를 알게 되었다. 디자인과 구성이 깔끔하고 개발 블로그로 사용하기 안성맞춤이었다. 설치하는 방법은 2가지인데 저는 후자를 이용했다.

공식 사이트에 있는 Deploy to Netlify 버튼을 이용
- Netlify 연동해서 내 저장소에 zoomkoding-gatsby-blog를 내 저장소로 clone
- 쉽고 간단하게 원클릭으로 설정이 가능
공식 사이트 저장소를 Fork
- 위 clone 방법과 동일한 이름의 내 저장소가 생성됨
- 차이점은 Fetch upstream을 사용해서 필요할 때마다 업데이트를 받을 수 있음

예전에 Jekyll 사용하면서 한가지 깨닫게 된 사실인데, 그냥 clone하면 upstream 저장소에 변경하상을 추적하기 힘들다는 단점이 있었다. 그래서 처음에 1번으로 했다가 2번으로 바꿔서 다시 한번 받았다. 그렇게 새롭게 블로그를 시작하게 되었네요.

메타정보 변경

Markdown을 똑같이 사용하기 때문에 크게 변경해야 할 부분은 없으나 그래도 손은 갑니다. 기존 Jekyll 에서 사용하던 메타 정보는 아래와 같습니다.

---
title: 자바스크립트는 모든 곳에 존재한다
category:
  - 도서
---

이걸 새롭게 바뀐 메타정보 형식으로 변경합니다. 줌코딩 님의 블로그에서는 emoji를 상단에 표기하는데 꽤나 마음에 들었습니다.

---
emoji: 📚
title: 자바스크립트는 모든 곳에 존재한다
date: "2021-10-09 23:00:00"
author: TED
tags: javascript reading starter featured
categories: 도서
---

앞으로의 계획

새로운 블로그의 몇가지 원칙을 만들었다.

평어체를 사용
개인 일상은 자제
기록 & 정보공유 목적

예전엔 블로그에 일상 같은 얘기들을 꽤 썼다. 그래서인지 제가 예전에 쓴건 독백에 가까운 반말체로 되어 있다. 이제는 SNS가 그런 역할을 충분히 대신해 주고 있다. 대부분의 블로그는 정보 전달을 목적으로 하네요. 저도 바꿔야겠다.

TIL 도 작성하고 있긴한데, 이건 이미 잘 만들어진 글들을 스크랩하는 부분에 가깝다. 여긴 내가 배운 것들을 재가공해서 유용한 정보를 공유하는 목적으로 쓰려고 한다.

좋은 블로그 템플릿을 공유해주신 줌코딩 님께 감사의 말을 전한다.

자바스크립트는 모든 곳에 존재한다

Sat, 09 Oct 2021 00:00:00 GMT

자바스크립트 언어를 알고 지낸지는 꽤 오래이지만 가장 따라가기 어려운 언어이기도 하다. 컴공과 신입생 시절에 만든 HTML 홈페이지에서 사용해본 자바스크립트~~아마도 팝업~~에서부터 HTML5 웹앱이 떠오르는 시절 회사에서 만든 웹앱으로 본격적으로 개발해 본 것 까지… 하지만 그러고도 10년이 지난 지금의 자바스크립트는 정말 빠르게 변하고 달라지고 있는 언어이다.

요약

꽤 오랜시간 FE(Frontend) 기술을 잊고 지냈다. 이직도 하고 업무의 종류가 바뀌면서 대부분은 BE(Backend)에서만 개발했기 때문이다. 그래서 다시 FE 기술을 따라가기도 겁나고 React, Angular, rxJS 등 용어만 들어도 언제 저걸 다시 공부하나 하는 생각도 들었다. 그랬던 나에게 이 책은 딱 좋은 도서였다.

참고 링크

구입: https://www.hanbit.co.kr/store/books/look.php?p_code=B5225420272
소스코드: https://github.com/javascripteverywhere