AI/AX Instructor Application

AI 에이전트를 설계하고,
실제 서비스와 일에 적용합니다.

처음에는 AI로 무언가를 만드는 일이 그냥 재미있었습니다. 회사 제품을 만들고, 블로그 대행을 자동화하고, 제 일상까지 Hermes에 맡겨보다 보니 어느새 에이전트와 자동화에 푹 빠졌습니다. 혼자 제 방식대로 해온 시간이 길어서, 이제는 제가 알게 된 것을 나누면서 다른 사람들과 같이 해보고 더 배우고 싶습니다.

프로덕트를 만들고,
에이전트로 수익을 만들고,
일상을 자동화했습니다.

제가 AI로 해본 일은 크게 세 가지입니다.

↓ 각 프로젝트를 펼치면 실제 설계와 화면을 볼 수 있습니다.
01 · PRODUCT

회사 개발 환경 안에서 바이브코딩으로
프로덕션 레벨 제품을 구축했습니다.

실제 배포를 전제로 한 B2B 물류 매칭 서비스입니다.

사용자 서비스와 운영 어드민, API와 DB까지 AI 에이전트 제품팀으로 함께 만들고 있습니다.

펼치면 볼 수 있어요 · 에이전트 제품팀 · 검수 구조 · 실제 화면 6장

  • 회사 서비스의 실제 사용자·운영자 업무를 제품으로 구현
  • 화주 요청–파트너 제안–운영 승인·노출을 한 데이터 흐름으로 연결
  • 9개 전담 Agent와 프로젝트 Skill, 공통 개발 Skill을 작업에 맞게 조합
  • 회사 개발 가이드·권한·보안·물류 정책을 시스템에 반영
사용자 서비스 + 어드민견적·입찰부터 운영 승인·제재까지
API + DB35개 데이터 모델과 실제 업무 규칙 연결
사내 개발 환경권한·개인정보·감사로그까지 반영
Why this architecture

처음에는 저와 Claude Code 한 세션으로 시작했습니다.

그런데 실제 회사 제품은 화면만 그려서는 끝나지 않았습니다. 물류 정책 하나를 바꾸면 견적 화면, 어드민, DB, 권한과 안내 문구가 같이 바뀌었습니다. 놓치는 일이 생길 때마다 담당 역할과 검수 순서를 하나씩 붙였고, 지금의 에이전트 제품팀이 됐습니다.

Agent = 담당자

독립된 맥락에서 맡은 역할만 수행합니다. Planner는 정책을, 물류 전문가는 실무를, QA는 전체 연결을 판단합니다.

Skill = 작업 매뉴얼

담당자가 반드시 따라야 하는 순서와 체크리스트입니다. Agent가 바뀌어도 작업 품질과 산출물 형식이 유지됩니다.

Agent Architecture

기획부터 오픈 전 검수까지 이 순서로 움직입니다.

Page Orchestrator — 전체 흐름을 통제하는 메인 Skill
Phase 1Planner
Spec·영향도
정책·DB·연관 화면
Phase 1.5Logistics
실무 검증
P0이면 구현 차단
Phase 2Frontend
Backend
페이지·API·DB
Phase 3Design·UX
QA·Compliance
병렬 리뷰팀
Phase 4수정리뷰 이슈 전수 반영
Phase 5재검증
결과 보고
Build·잔여 이슈
Agent × Skill

프로젝트 안의 제품팀과, 필요할 때 붙이는 공통 개발 루틴

프로젝트 안에는 기획·물류·프론트엔드·백엔드·디자인·UX 문구·QA·그래픽·컴플라이언스를 맡는 9개 Agent와 10개 전용 Skill이 있습니다. 작업을 끝낼 때는 테스트와 빌드, 독립 PR 리뷰, 변경 내용 랩업처럼 프로젝트 밖의 공통 개발 루틴도 이어 붙입니다. 숫자를 크게 보이게 만드는 것보다, 어떤 변경에 누구를 부를지가 더 중요했습니다.

AgentSkill책임
plannerspec-writing화면 정책, 사용자 분기, 관련 DB와 연관 화면 영향도
logistics-expertlogistics-review5개 물류 서비스 유형, 견적 항목, 실무 엣지케이스 검증
frontend-devpage-implementationNext.js 페이지와 컴포넌트 구현, 반응형·인터랙션
backend-devbackend-apiPrisma 스키마, API, mock→DB, 비즈니스 규칙
designerdesign-review디자인 토큰, 간격, 타이포, 시각 일관성
ux-writercopy-review톤, 용어, 버튼·에러·빈 상태 문구
qaquality-check빌드, 반응형, 화면 경계와 전체 흐름 종합 검증
compliance-expertcompliance-review권한·PII·암호화·감사로그, 개인정보 수집·보유·파기와 약관 검토
graphic-designer3d-illustration서비스 디자인 규칙에 맞는 이미지 생성과 파일 관리
Worktree

폴더를 이렇게 나눈 데에도 이유가 있습니다.

project tree · 공개용 축약
new-matching/
├── CLAUDE.md                         # 프로젝트 규칙과 호출 기준
├── .claude/
│   ├── agents/                       # 9개 제품 역할
│   │   ├── planner.md                # 정책·영향도
│   │   ├── logistics-expert.md       # 물류 실무 검증
│   │   ├── frontend-dev.md           # 사용자·어드민 화면
│   │   ├── backend-dev.md            # API·DB
│   │   ├── designer.md / ux-writer.md
│   │   ├── qa.md / graphic-designer.md
│   │   └── compliance-expert.md      # 권한·개인정보·법무
│   └── skills/                       # 10개 프로젝트 전용 절차
│       ├── page-orchestrator/         # 전체 순서와 차단 조건
│       ├── spec-writing/              # 정책·DB·연관 화면 영향도
│       ├── logistics-review/          # 물류 P0 검증
│       ├── page-implementation/       # Next.js 화면 구현
│       ├── backend-api/               # Prisma·API Route
│       ├── design-review/ / copy-review/
│       ├── quality-check/             # typecheck·test·build
│       ├── compliance-review/         # 배포 전 점검
│       └── 3d-illustration/
├── docs/                              # 제품 판단의 원본
│   ├── SPEC.md / POLICY.md
│   ├── DATABASE.md / DESIGN.md / COPYWRITING.md
│   ├── ADMIN-SERVICE-INTEGRATION.md
│   ├── DB-WIRING-CHECKLIST.md
│   └── specs/                         # 화면·권한·상태별 상세 정책
│       ├── quote-request.md / logistics.md
│       ├── account-partner-lifecycle.md
│       ├── admin-membership.md / admin-credits.md
│       └── admin-moderation.md / admin-ops.md
├── app/
│   ├── src/app/                       # 사용자 서비스와 운영 어드민
│   │   ├── quote/ / logistics/ / partner/ / credits/
│   │   ├── qna/ / promotion/ / messages/
│   │   ├── admin/(console)/           # 회원·파트너·거래·콘텐츠·감사
│   │   └── api/                       # 인증·견적·입찰·크레딧 API
│   ├── src/components/ / src/lib/
│   └── prisma/                        # schema·migration·seed
└── _workspace*/                       # 기능 단위 Agent 인수인계 기록
    ├── 01_planner_spec_draft.md
    ├── 01.5_logistics_review.md
    ├── 01.6_compliance_review.md
    ├── 02_frontend-dev_implementation.md
    ├── 03_designer_review.md / 03_ux-writer_review.md
    ├── 03_qa_report.md
    └── 04_fixes.md / 05_qa_recheck.md
Artifact Handoff

다음 Agent에게는 말 대신 파일을 넘깁니다.

각 단계가 결과를 정해진 파일로 남깁니다. 덕분에 실패한 단계만 다시 실행할 수 있고, 무엇을 근거로 결정했는지 추적할 수 있습니다.

01 · PlannerSpec + 영향도01_planner_spec_draft.md
01.5 · Domain물류 검증01.5_logistics_review.md
02 · Build구현 내역02_frontend-dev_implementation.md
03 · Review종합 QA03_qa_report.md
04–05 · Fix수정·재검증05_qa_recheck.md
Quality Gates

빌드와 재검증까지 끝나야 작업이 완료됩니다.

실무 차단 게이트

물류 전문가가 P0 이슈를 발견하면 Planner가 Spec을 고치고 재검증하기 전까지 구현할 수 없습니다.

보안·컴플라이언스 게이트

로그인, 권한, 개인정보, 파일, 외부 API, 어드민을 건드리면 Compliance Agent가 검토에 들어갑니다.

독립 리뷰 게이트

커밋 전 맥락 없는 리뷰어가 diff를 검토하고, 원래 세션이 제품 맥락에 따라 반영 여부와 이유를 기록합니다.

이해 게이트

비개발 오너가 변경을 이해할 수 있도록 직관적인 설명과 이해 확인을 거친 뒤 커밋합니다.

Schema Sync

DB가 바뀌면 Migration, Prisma Client, ERD, 데이터 사전, 검토 문서를 한 순서로 갱신합니다.

최종 재검증

리뷰 이슈를 수정한 뒤 Build와 해당 항목을 다시 확인하고, 남은 이슈까지 보고합니다.

Product Output

사용자가 남긴 요청은 운영 어드민까지 같은 흐름으로 이어집니다.

메인 화면만 만든 것이 아니라 요청 작성, 견적 탐색, 운영자의 매칭 관리와 알림 이력까지 한 제품 안에서 연결했습니다.

01 · Request

사용자는 필요한 물류 서비스를 찾고, 조건을 입력합니다.

처음 온 사용자도 서비스 선택부터 물류 조건 입력까지 순서대로 진행할 수 있게 만들었습니다.

물류 서비스 사용자 메인 화면
사용자 메인 · 필요한 물류 서비스를 바로 찾고 요청을 시작하는 화면
물류 견적 요청 조건 입력 화면
견적 요청 · 취급 상품과 출고 유형 등 실제 매칭 조건을 단계별로 입력
02 · Matching

사용자의 견적 요청과 운영자의 매칭 현황이 같은 데이터로 움직입니다.

사용자에게 보이는 견적 카드와 운영자가 관리하는 상태·입찰·마감 정보를 따로 만들지 않고 연결했습니다.

사용자 견적 탐색 화면
사용자 서비스 · 진행 상태와 조건을 비교하는 견적 탐색 화면
운영 어드민 견적 현황 화면
운영 어드민 · 서비스 유형별 견적, 입찰, 마감 상태를 한곳에서 관리
03 · Operations

어드민은 매칭뿐 아니라 서비스 운영 전체를 다룹니다.

운영자는 대시보드에서 병목과 처리 대상을 확인하고, 시스템이 보낸 알림과 이력을 다시 추적할 수 있습니다.

운영 어드민 대시보드
운영 대시보드 · 승인 대기와 매칭 퍼널을 기준으로 우선 처리할 업무를 확인
운영 어드민 알림 발송 이력 화면
운영 이력 · 견적과 매칭 단계에서 발송된 알림의 대상과 결과를 추적
02 · REVENUE-GENERATING AGENT

블로그 자동 발행 에이전트로
대행 업무를 자동화하고 수익을 만들었습니다.

실제 유료 블로그 대행에 사용하는 콘텐츠 에이전트입니다.

고객별 자료는 분리하고, 조사부터 기획·작성·검수·납품까지 같은 흐름으로 반복합니다.

펼치면 볼 수 있어요 · 고객별 지식 · 제작 파이프라인 · 검수 구조

  • 실제 유료 블로그 대행 업무와 납품에 사용
  • 클라이언트별 자료·문체·규제·피드백을 완전히 격리
  • 조사→기획→사람 승인→작성→편집→납품본 생성
  • 반복 피드백을 다음 실행의 규칙과 Skill로 축적
3개 고객 팩금융·B2B 기술·외국인 생활정보
16개 최종 원고실제 납품본이 쌓인 운영 시스템
리서치 → 납품중간 산출물로 부분 재실행 가능
Design Principle

고객이 늘어도 자료가 섞이지 않게 두 층으로 나눴습니다.

조사→기획→작성→검수 순서는 같지만 고객마다 산업 지식, 표현 규제, 말투가 다릅니다. 일하는 순서는 재사용하고, 고객 자료는 따로 보관했습니다.

공통 실행 순서

리서치, 기획, 작성, 편집 역할이 blog-pipeline을 따라 움직입니다. brand-voiceaeo-geo-writing은 고객의 말투와 검색·AI 인용 기준을 확인합니다.

Client Layer

BRIEF, 통합 지침, 가이드, 피드백, 승인본, 출력 스키마를 클라이언트별로 격리해 다른 고객의 사실과 말투가 섞이지 않게 합니다.

Pipeline

글의 방향은 제가 먼저 확인합니다.

STEP 0Client Pack
정독 게이트
읽은 흔적 파일 생성
STEP 1Researcher검색어·통계·1차 출처
STEP 1.5Planner독자 여정·H2/H3
STEP 1.75Human Gate구조 보고·명시적 승인
STEP 2Writer승인 구조로 초안 작성
STEP 3–4Editor
최종 승인
규제·팩트·보이스 검수
Worktree

새 고객이 생기면 고객 폴더만 하나 추가합니다.

project tree · 고객명 익명화
leadgen-lab/
├── CLAUDE.md                         # 공통 운영 원칙·라우팅
├── .claude/
│   ├── agents/
│   │   ├── blog-researcher.md        # 키워드·데이터·출처 수집
│   │   ├── blog-planner.md           # 검색의도·독자여정·글 구조
│   │   ├── blog-writer.md            # 승인된 설계로 본문 작성
│   │   └── blog-editor.md            # 규제·팩트·브랜드 검수
│   └── skills/
│       ├── blog-pipeline/             # 전체 단계·재실행·보고
│       ├── brand-voice/               # Client Pack 정독 게이트
│       └── aeo-geo-writing/           # 검색·AI 인용 구조
├── clients/
│   ├── _TEMPLATE.md                  # 신규 고객 온보딩 양식
│   ├── client-a/
│   ├── client-b/
│   └── client-c/
│       ├── BRIEF.md                   # 목표·독자·최우선 규칙
│       ├── CLAUDE.md                  # 작성·검수 통합 지침
│       ├── agents/                    # 고객별 역할 보정
│       ├── skills/                    # 브랜드·도메인 규칙
│       ├── guide/                     # 공식자료·피드백·승인본
│       ├── templates/                 # 단계별 JSON 스키마
│       └── output/
│           └── YYYY-MM-DD-topic/
│               ├── brief.json
│               ├── pre_write_check.md
│               ├── research_summary.md
│               ├── seo_keywords.json
│               ├── content_plan.json
│               ├── v1.md
│               ├── review_report.json
│               ├── final.md
│               └── feedback_learnings.md
├── frameworks/                       # SEO·GEO·AEO 공통 프레임
└── memory/                           # 작업 이력·진화 후보
File-based Handoff

리서치와 기획안이 다음 작업의 재료가 됩니다.

Context정독·브리프brief.json
pre_write_check.md
Research근거·키워드research_summary.md
seo_keywords.json
Plan글 설계도content_plan.json
Write버전 원고v1.md → v2.md
Review검수·학습review_report.json
final.md
  • 중간 파일을 보존해 리서치만, 구조만, 본문만 부분 재실행할 수 있습니다.
  • 파일이 없거나 0바이트면 “가짜 완료”로 판정하고 다음 단계로 넘기지 않습니다.
  • 출처가 없는 사실은 작성 Agent가 사용할 수 없고, Editor가 원문과 1:1로 다시 확인합니다.
Guardrails

가장 공들인 건 잘못된 글이 나가지 않게 하는 장치였습니다.

정독 흔적 게이트

BRIEF·통합 지침·가이드·피드백·직전 승인본을 읽고 pre_write_check.md를 만들기 전에는 리서치나 작성으로 넘어갈 수 없습니다.

사람 구조 승인

Planner가 H1/H2/H3와 타깃 키워드, 예상 분량을 보고하고 사람이 승인한 뒤 Writer가 시작합니다.

점수 기반 재작성

Editor의 종합 점수가 70점 미만이면 기존 리서치는 재사용하고 Writer만 한 번 다시 실행합니다.

규제·팩트 우선

법적·규제 위반, 브랜드 오표기, 사실 오류는 Critical로 분류해 Editor가 즉시 수정합니다.

클라이언트 격리

A사의 사실, 말투, 금지 표현이 B사 작업에 섞이지 않도록 경로와 참조 우선순위를 분리합니다.

Feedback → Skill

반복되는 피드백은 글별 메모에만 두지 않고 Client Pack이나 Skill의 새 규칙으로 승격합니다.

03 · PERSONAL OS

Hermes로
제 일과 생활을 자동 운영합니다.

Slack에서 말을 걸면 Hermes가 필요한 정보와 도구를 찾아 일을 시작합니다.

투자·가계부·CS·콘텐츠·일정과 회고가 연결되고, 결과는 다시 Wiki와 Skill에 남습니다.

펼치면 볼 수 있어요 · 자동화 6개 · 개인 OS · 지식 루프

  • Slack을 입구로 Notion·Calendar·Wiki와 두 대의 Mac을 연결
  • 투자 브리핑·조건부 주문·가계부·스마트스토어 CS를 정기 실행
  • Claude Code와 Codex를 필요한 작업에만 불러 쓰고 결과를 회수
  • 완료 신호를 믿지 않고 실제 주문·시트·문의·URL을 다시 확인
Hermes HubSlack에서 요청·승인·최종 보고
일과 생활 자동화재정·CS·콘텐츠·계획·회고
Knowledge Loop경험을 Wiki와 Skill로 다시 사용
How my OS works

Hermes는 본부이고, 실행 도구는 따로 있습니다.

Hermes는 제가 말을 거는 입구이자 전체 일을 기억하는 허브입니다. 짧은 확인은 직접 처리하고, 오래 걸리는 개발과 문서 작업은 Claude Code나 Codex에 맡깁니다. 정기 업무는 스크립트와 예약 작업이 실행합니다. Hermes는 필요한 맥락을 붙여 일을 보내고, 결과를 회수해 실제 대상이 바뀌었는지 확인합니다.

제가 보는 화면

Slack에서 요청하고 승인합니다. Notion은 할 일, Calendar는 시간, Wiki는 오래 쓸 결정과 경험을 맡습니다.

뒤에서 움직이는 것

Hermes가 Memory·Skill·Wiki를 읽고, 스크립트·API·브라우저·Claude Code·Codex를 작업에 맞게 호출합니다.

Automation Portfolio

귀찮아서 미루던 일부터 하나씩 붙였습니다.

업무마다 위험도가 달라 자동화 범위도 다르게 잡았습니다. 투자는 주문 전 조건을 확인하고, CS는 익숙한 문의만 처리하며, 가계부는 애매한 분류만 제게 묻습니다.

01 · 투자 자동화

리서치 브리핑과 조건부 주문 실행

증권사 자료와 최신 뉴스를 아침·오후 흐름으로 수집해 비전문가도 읽을 수 있는 언어로 요약합니다. 매매 요청은 계좌, 수량, 현재가와 평단 등 사전에 정한 조건을 확인하고, 조건이 맞지 않으면 주문을 차단합니다.

자료 수집 → 중복·휴장 판별 → 요약 → 조건 검증 → 주문 → 체결 확인
02 · 가계부 자동화

카드 결제 알림을 월별 시트로

Mac의 메시지 데이터에서 카드 결제 알림을 읽고 날짜·금액·가맹점·결제수단을 구조화합니다. 확실한 내역은 기록하고 분류가 애매한 항목만 질문하며, 카드별 표기와 가족 결제 같은 예외 규칙도 기억합니다.

SMS 수집 → 결제정보 추출 → 자동 분류/질문 → 중복 확인 → Google Sheets 기록
03 · CS 자동화

스마트스토어 문의를 놓치지 않는 운영

네이버 커머스 API로 고객 문의와 상품 Q&A를 주기적으로 조회합니다. 상품 매뉴얼과 기존 답변 톤을 바탕으로 답변 가능 여부를 가르고, 새로운 판단이 필요한 문의는 내용과 초안을 함께 보고합니다.

문의 조회 → 미답변 판별 → 매뉴얼·과거 답변 참조 → 답변/승인 요청 → 처리 확인
04 · 콘텐츠 운영 자동화

기획부터 발행·검수까지 이어지는 파이프라인

주제 선정, 자료 조사, 글쓰기, 이미지 제작, SEO 항목 검수와 발행을 단계별 산출물로 연결합니다. 결과가 비어 있거나 발행 상태를 확인하지 못하면 완료로 처리하지 않습니다.

소재 수집 → 조사·작성 → 이미지 → SEO 검수 → 발행 → URL 확인
05 · 일정·회고 자동화

하루의 작업 흔적을 다음 계획으로

Calendar와 Notion에서 아침 계획을 만들고, 퇴근 시 여러 에이전트와 기기의 작업 흔적을 회고 후보로 모읍니다. 대화로 확인된 결정과 교훈만 Wiki에 남겨 다음 업무에서 다시 꺼냅니다.

일정·할 일 조회 → 계획 → 작업 흔적 수집 → 회고 대화 → 지식 승격
06 · 운영 원칙

자동 실행 뒤에는 반드시 검증

외부 시스템의 성공 응답만 믿지 않고 주문 체결, 시트 행, 문의 상태, 발행 URL처럼 실제 대상의 변경 결과를 다시 읽습니다. 오류가 나면 자동 복구 범위를 제한하고 필요한 경우 사람에게 되돌립니다.

실행 → 원본 재조회 → 성공/실패 판정 → 재시도 또는 사람에게 에스컬레이션
Knowledge Layer

한 번 고친 것을 다음번에 또 설명하지 않기 위해 만들었습니다.

Hermes는 대화와 실행 결과를 전부 기억으로 저장하지 않습니다. 다시 쓸 만한 사실은 Memory에, 반복 절차는 Skill에, 프로젝트의 결정과 근거는 Wiki에 나눠 둡니다. 하루 기록은 Notion과 Calendar에서 로컬 ledger와 Daily Note로 동기화되고, 확인된 결과만 프로젝트 지식으로 연결됩니다.

매일 쓰는 기록

Notion 태스크와 Calendar 일정은 로컬 일일 노트에 모입니다. 완료만 체크된 일은 결과가 연결될 때까지 회고 질문으로 남습니다.

오래 쓰는 지식

회사 원문은 가져오지 않고, 제가 한 판단과 공개 가능한 교훈만 비식별화해 Wiki에 남깁니다.

Four Circuit Knowledge Loop

기록을 다음 일에서 다시 쓰는 네 단계입니다.

knowledge loop
[조이님 인풋과 Agent 작업 흔적]
           ↓
A. WRITE    자동 분류·출처 포인터와 함께 저장
           ↓
[Wiki / Memory / Project Sources]
           ↓
B. READ     새 작업 전에 관련 기억과 근거를 소환
           ↓
C. COMPOSE  내부 경험 + 외부 자료를 결합해 결과 생성
           ↓
D. EVOLVE   반복 패턴과 피드백을 규칙·Skill로 승격
           ↓
[다음 계획·의사결정·강의·콘텐츠에서 다시 사용]
Daily Pipeline

아침 계획과 퇴근 회고에서 기록이 시작됩니다.

08:40Calendar
Notion 조회
시간 제약·미완료 업무
Morning추천 계획대화로 우선순위 합의
DaytimeClaude·Codex
Aside 작업
여러 기기·프로젝트
17:00회고 후보
3–5개
변경·세션·결정 수집
Dialogue맥락 보완역할·결정·교훈·성과
PromoteWiki 승격다음 작업에서 재사용
Source of Truth

Notion, Calendar, Wiki가 맡는 정보는 서로 다릅니다.

정보정식 원본이유
할 일·상태·날짜Notion Daily Tasks계획 합의 후에만 실제 변경하고 재조회로 확인
약속·시간 제약Google Calendar개인·회사 일정을 함께 읽되 일정 원본은 유지
결정·교훈·성과/wiki출처와 연결을 가진 장기 지식으로 관리
대화·새 입력Slack계획과 회고를 혼자 판단하지 않는 인터페이스
회사 원문·코드회사 시스템원문은 복사하지 않고 비식별화한 교훈만 승격
Wiki Architecture

Wiki 폴더는 자료의 상태에 따라 나뉩니다.

wiki tree
wiki/
├── inbox/       # 아직 판단하지 않은 승격 후보
├── raw/         # 기사·커뮤니티·기존 시스템의 출처 원본
├── concepts/    # 반복해서 쓰는 개념과 판단 프레임
├── entities/    # 사람·조직·제품·도구·시스템
├── cases/       # 실제 적용 사례와 결과
├── projects/    # 진행 중 목표·상태·결정·증거
├── playbooks/   # 다시 수행할 수 있는 절차와 체크 기준
├── queries/     # 아직 답을 키우는 질문과 종합 분석
├── briefings/   # 여러 자료를 읽어 만든 시점성 결과
├── academy/     # 강의·워크숍으로 승격된 지식
└── _meta/       # 분류·승격·품질 운영 규칙
Agent Roles & Safety

Hermes가 기억을 정리하고, Claude Code와 Codex는 필요한 일을 처리합니다.

Hermes

Slack 인터페이스, 아침 계획, 회고 질문, 중복 제거, 지식 정리와 자동화 결과 검증을 담당합니다.

Claude Code · Codex · Aside

개발, 문서, 브라우저 현장 작업과 독립 리뷰 흔적을 제공하되 장기 지식을 직접 확정하지 않습니다.

승인 후 변경

Notion 일정 변경과 Wiki 승격은 조이님과 대화로 합의한 뒤에만 실행합니다.

민감정보 제외

자격증명, 토큰, 쿠키, 캐시, 비밀번호 저장소는 작업 흔적 수집 대상에서 제외합니다.

회사 원문 비복사

승인된 경로만 읽고 공개 가능한 교훈과 구조만 비식별화해 남깁니다.

제가 먼저 해본 것을
비개발자도 따라올 수 있게 풉니다.

기능을 외우는 수업보다, 실제 업무 하나를 가져와 같이 만들어보는 수업을 좋아합니다. 제가 틀리고 다시 만든 과정도 숨기지 않고 보여드립니다.

Aladin Academy

AI 에이전트·업무자동화 시즌 1·2

에이전트 개념과 실제 업무 적용을 연결한 교육을 진행했습니다. 시즌 3 Codex 교육을 준비하고 있습니다.

In-house Training

사내 AI 생산성 교육 5회 이상

비개발자 직군이 자신의 업무에서 바로 활용할 수 있는 실습형 교육을 진행했습니다.

Teaching Method

개념 → 실제 구조 → 함께 실행

기능을 나열하기보다 실제 폴더와 Agent·Skill·산출물 구조를 보여주고, 참가자가 자기 업무로 바꾸어 설계하도록 돕습니다.

제품을 기획해온 10년 위에
AI로 직접 만드는 경험이 더해졌습니다.

물류 플랫폼과 AI·AR 서비스, O2O, 브랜드와 마케팅을 오가며 일했습니다. 요즘은 기획서를 넘기는 데서 멈추지 않고 제품과 자동화까지 직접 만들어보고 있습니다.

회사 경력

Product ManagerKakao Enterprise · 물류 플랫폼/서비스 기획
Product Manager · Brand Experience LeadESTSoft · 브랜드 경험 / O2O 서비스 기획
Brand Managerthe.Watermelon · 브랜드 전략 및 마케팅
Product ManagerESTSoft · AI/AR 서비스 기획
AE · MarketerAdqua Interactive · Samsung C&T Fashion Group

학력

Master of Information ManagementKAIST College of Business · 정보경영프로그램(IMMS) · 재학
Advertising & Public Relations · Communication DesignHanyang University ERICA · 복수전공
Art, Communication and DesignFontys University of Applied Sciences · Exchange
전체 경력과 활동 보기 ↗
Contact

제가 해본 것을 나누고,
같이 해보면서 더 배우고 싶습니다.