브랜드의 화면을 설계해 왔습니다.
이제는 그 브랜드가 굴러가는
조직을, AI로 설계합니다.
패션·커머스·미디어 브랜드의 웹 경험을 설계해 매출과 전환을 만들어 온 5년, 그리고 최근 — CS·주문·콘텐츠·마케팅·보안을 나눠 맡는 8개 역할의 AI 에이전트 조직을 설계하고 실제로 가동시킨 시간. 두 경력은 같은 질문에서 출발합니다. 이 구조가 왜 필요한가.
Profile
Profile
보기 좋은 화면보다, 설명 가능한 구조를 만듭니다 — 그 구조가 사람이 아니라 AI로 운영될 때도 같은 기준을 적용합니다.
5년간 패션·커머스·미디어 분야에서 브랜드 웹 경험을 설계해 왔습니다. 상세페이지와 GNB 구조를 데이터 기반으로 최적화하는 일부터, 브랜드의 철학을 화면 순서와 정보 밀도로 번역하는 일까지 — 매출과 브랜드 인상이 충돌하지 않도록 조율하는 역할을 맡아왔습니다.
최근에는 같은 사고방식을 화면 바깥으로 확장했습니다. 1인 체제로 운영되는 브랜드의 CS·주문·콘텐츠·마케팅·보안 업무를 8개 역할의 AI 에이전트 조직으로 설계하고, 실행 결과를 매일 PASS/PARTIAL/FAIL로 판정·재시도·학습시키는 관제 루프를 직접 구축해 가동 중입니다. 화면을 설계하던 기준 — 왜 이 구조가 필요한가 — 을 그대로 AI 조직 설계에 적용하고 있습니다.
가장 앞세우는 무기는 AI 조직·운영 설계이고, 브랜드 UX/UI 설계와 데이터 기반 진단이 그 판단을 뒷받침합니다. 화면 하나를 만드는 것과 8개 역할이 맞물려 돌아가는 조직을 만드는 것은, 저에게는 같은 종류의 일입니다.
Judgment / Working Method
Working Method
아래는 화면을 설계할 때와 AI 조직을 설계할 때 각각 지키는 판단 기준입니다. 이어지는 4개 사례(AI Ops · Diagnostics · Brand Design · Toolkit)는 이 기준이 실제로 적용된 기록입니다.
화면을 설계할 때
- 브랜드의 톤은 비주얼 스타일뿐 아니라 정보의 우선순위와 읽히는 리듬에도 반영되어야 한다고 생각합니다.
- 화면의 완성도는 시각적 정리에서 끝나지 않고, 사용자가 다음 행동으로 이동하는 흐름까지 포함합니다.
- 반응형 설계는 레이아웃의 축소가 아니라, 디바이스별 맥락에 맞춘 정보 재배치의 문제입니다.
AI 조직을 설계할 때
- 모호한 상황에서 AI가 임의로 진행하지 않도록, "멈추고 보고하는" 경로를 먼저 설계합니다.
- 같은 실패가 반복되면 그건 AI의 실수가 아니라 지시문의 결함으로 보고, 규칙을 고칩니다.
- 되돌리기 어려운 조작(연동 해제, 예산 집행, 고객 응대)은 언제나 사람의 승인을 거칩니다.
Flagship — AI Organization Design
SLDS 에이전트 조직 설계 & 관제
Org Structure — 실제 설계 문서 기준
Safety Rails — 지시문에 고정한 규칙
- 사람 개입이 필요한 상황(로그인 만료, 규칙 모호, 권한 없음)은 임의로 진행하지 않고 FAIL/PARTIAL로 기록한 뒤 중단한다.
- 돈이 걸린 실행(광고 예산 집행, 채널 송장·배송중 처리)은 보고 → 승인 → 실행 순서를 반드시 지킨다.
- 카카오 상담 등 고객 대면 채널은 자동 응답하지 않는다. 요약·분류까지만 하고 사람이 답한다.
- 작업 산출물과 로그는 GitHub 등 외부 저장소에 임의로 공유하지 않는다. 비밀번호·카드번호는 로그에 남기지 않는다.
Control Ledger — 관제 원장 (실제 판정 로그)
| 날짜 | ① CS | ② 오더 | ③ 콘텐츠 | ④ IT블로거 | 재시도 | 조치 필요 |
|---|---|---|---|---|---|---|
| 2026-06-18 | PASS | — | PASS | PASS | 0 | 카카오 로그인 만료 (누적 2회) |
| 2026-06-19 ~ | 가동 지속 중 · 판정은 매일 13:00 관제 루프에서 기록 | |||||
누적 실패 추적 예시 — [카카오 로그인 만료] 임계 3회 도달 시 제안: 자동화 전 세션 유지 방안부터 해결. 같은 실패를 세 번째 겪기 전에, 원인을 지시문에 되먹임하는 구조입니다.
이 프로젝트의 핵심은 "AI에게 일을 시켰다"가 아니라, 실패를 판정하고 재시도하고 학습하는 관제 계층을 별도로 설계했다는 데 있습니다. 8개 역할 중 하나라도 규칙이 모호하면 임의로 진행하는 대신 멈추고 보고하도록 설계했고, 같은 실패가 반복되면 그 패턴을 지시문 개선안으로 되돌리는 루프를 넣었습니다. 제품을 만드는 감각과 조직을 설계하는 감각이 같은 문제라고 생각합니다.
Case — Diagnostic Rigor
구글 애즈 · 머천트센터 진단
전환 이벤트 규모 — 최근 30일
* 결제 시작이 장바구니보다 많은 것도 원본 데이터 그대로입니다 — '결제시작'이 기본 전환 목표에 섞여 중복 집계됐을 가능성 자체가 진단 대상이었습니다.
예산 배분의 역설
진단 초기에는 "네이버페이 결제 자체가 안 잡힌다"고 판단했으나, 실제로는 카페24가 선불금으로 표시하는 방식의 문제였고 — 사용자의 재확인으로 다시 "주문 데이터가 아니라 구글↔카페24 서버 연동 문제"라는 결론으로 두 차례 정정했습니다. 원인이 확실해진 지금도, 라이브 연동을 끊는 재연결 작업은 사용자 승인 없이 진행하지 않고 있습니다. 결론을 서두르지 않는 것, 되돌리기 어려운 조작은 승인 없이 하지 않는 것 — 이 두 가지를 판단 기준으로 삼습니다.
Case — Full-Scope Brand Renewal
slds.kr 브랜드 사이트 전체 리뉴얼
BEFORE — 상품 나열 위주의 균일한 리스트 구조 / AFTER — 풀스크린 라이딩 영상 히어로 + SLDS IS·FEATURE(브랜드 스토리)·CONTACT 페이지 신설 + 화이트 솔리드 반응형 GNB 개편. 모든 캡처는 현재 운영 중인 slds.kr 실제 화면입니다.
브랜드 철학은 이미 확고했는데, 문제는 그게 상품 나열 구조 어디에도 번역되어 있지 않다는 점이었습니다. 컬러나 로고를 바꾸는 대신 정보 구조부터 다시 짠 이유입니다 — 브랜드 리뉴얼에서 가장 먼저 손대야 할 것은 톤이 아니라 순서라는 걸 이 프로젝트에서 확인했습니다.
Case — Publishing Craft
이 사이트 자체가 마크업 증명입니다
<!-- 이 페이지 실제 코드: 접근성 뼈대 -->
<a class="skip-link" href="#main">본문으로 건너뛰기</a>
<main id="main"> … </main>
/* 모션 민감 사용자: 애니메이션 전체 해제 */
@media (prefers-reduced-motion: reduce) {
.reveal { opacity: 1; transform: none; transition: none; }
}퍼블리싱 기준: 웹 표준(HTML Living Standard) · KWCAG 접근성 지침 · 크로스 브라우징(Chrome/Safari/Firefox/삼성 인터넷).
Case — Custom Tooling
API 없는 관리자 화면을 위한 자동화 툴킷
주문 목록의 결제수단 컬럼만으로는 네이버페이·토스 사용 여부를 정확히 판별할 수 없다는 걸 뒤늦게 발견했습니다 (카페24가 선불금으로 표시). 그 뒤로는 집계 스크립트를 만들 때마다 "이 데이터가 실제로 뭘 의미하는지"부터 문서화하고 시작합니다. 도구는 빨리 만드는 것보다, 무엇을 못 하는지 아는 것이 더 중요했습니다.
Earlier Work — 브랜드 · 커머스 · 미디어
Earlier Work
Contact
화면을 만드는 사람이 아니라, 그 화면 뒤 구조까지 책임지는 사람이 필요하다면.
채용 제안, 프로젝트 협업 모두 열려 있습니다. 브랜드 웹 디자인부터 AI 운영 조직 설계까지, 기획 초기 단계부터 구조를 함께 정리합니다.
Available for in-house & project-based collaboration