Role-based AI operations architecture
Reasoning, workflow automation, browser execution, and human decisions separated by explicit boundaries.
기술 스택 · 구성도 · Turnstile 대응 · AI 직원 조직 · 공개 범위
Smartstore 운영을 위한 AI 직원 조직과 Hermes·Claw3D 연동 구성을 공개 기술 문서로 정리한 저장소다. 이 저장소의 핵심은 특정 쇼핑몰의 영업자료가 아니라, 역할 기반 AI 직원, 상태 중심 업무 코어, 브라우저 자동화 경계, 이벤트 연결, 운영 문서화를 하나의 구조로 설계한 기술적 접근이다.
| 17 역할 기반 AI 직원 |
5 표준 직원 문서 |
1 DB 정본 |
3 브라우저 실행 단계 |
4 agy Gemini 계정 수 |
0 공개 운영 비밀 |
이 시스템은 17명의 역할별 AI 직원이 상품·주문·구매·배송·회계·인프라 업무를 분리해서 판단하도록 구성한다. AI 대화나 Kanban 카드가 거래의 기준 기록이 되지 않도록 PostgreSQL을 정본으로 두고, n8n은 연결·예약·알림, Hermes는 역할별 판단, 브라우저 실행기는 화면 조작, Slack은 진행상황과 사용자 결정을 전달하는 계층으로 제한한다.
|
Smartstore 상품·주문·배송이 연결 상거래 표면 |
Tistory Blog 프로젝트 운영 기록·콘텐츠 채널 |
|
공개 아키텍처 직원 역할·권한·인계·상태 연동 구성도 |
비공개 실행 경계 토큰·세션·거래 데이터·구매 스킬 런타임 |
이 저장소는 다음을 공개한다.
- AI 직원 17명의 역할·권한·인계·중단 조건 문서
- Hermes 프로필의 비민감 표시 메타데이터
- Claw3D 직원 레지스트리와 작업공간의 논리적 구조
- 직원별 Slack App Manifest와 Socket Mode 연동 계약
- 시스템 구성도, 데이터 흐름, 보안·민감정보 제외 원칙
비즈니스 거래 데이터, 인증정보, 계정 식별자, 고객정보, 외부 판매 채널별 자료, 구매팀 스킬 본문은 공개하지 않는다.
| 기술 스택 |
 Django |
 DRF |
 React |
 TypeScript |
 Vite |
| 데이터· 워크플로 |
 PostgreSQL |
 n8n |
 YAML |
 Markdown |
 Mermaid |
| AI·실행· 연동 |
 Hermes Agent |
 Claw3D |
 Docker |
 Slack |
 WebSocket |
| 브라우저· 운영 |
 Chromium |
 Chrome/CDP |
 Ubuntu |
 Python |
 Git |
| 보안확인 대응 |
 1차 Byparr |
 2차 Gemini Computer Use |
 3차 Hermes Browser |
 인계 감시기 |
 단계별 Slack 알림 |
| 업무 연동 |
 HTTP API |
 Webhook |
 외부 채널 커넥터 |
 SMTP |
 승인 게이트 |
| 검증· 복구 |
 회귀 시험 게이트 |
 Terraform |
 Node.js |
 TOTP 2단계 인증 |
 공공데이터 API |
업무 데이터는 DB 정본으로 관리하고, AI 판단·워크플로·브라우저 실행·사람의 승인을 명시적으로 분리한다.
| Reasoning Hermes Agent · 역할별 판단과 인계 |
Orchestration n8n · 예약·polling·외부 연결 |
State PostgreSQL · 상태·감사·정합성 |
| Execution Chromium · Chrome/CDP · 브라우저 경계 |
Decision Gate Slack Socket Mode · 승인·예외 |
Operations Claw3D · Kanban · WebSocket |
| 계층 | 기술 | 담당 영역 | 설계 포인트 |
|---|---|---|---|
| 업무 백엔드 | Django 5.2 LTS | 업무 API, 권한 경계, 상태 전이, 작업표 | 모듈형 단일 백엔드로 시작해 운영 복잡도를 낮춘다 |
| API | Django REST framework | 외부 연동·웹 UI·AI 도구용 업무 단위 API | 범용 SQL 대신 역할별 업무 도구만 노출한다 |
| 웹 프론트엔드 | React + TypeScript + Vite | 모니터링, 상품, 회계, 작업 상태 화면 | 타입 안전한 화면 계약과 빠른 개발 루프를 사용한다 |
| 정본 데이터베이스 | PostgreSQL | 주문·구매·배송·정산·감사 이력·작업 임대 | 유니크 제약, CHECK, 상태 전이, 중복 방지를 DB에서 강제한다 |
| 워크플로 오케스트레이션 | n8n | API polling, 예약, 연결, Slack·메일 알림 | 거래 상태의 정본이 아니라 트리거·연결 계층으로 제한한다 |
| AI 직원 런타임 | Hermes Agent | 역할 문서, 세션, 도구 호출, 인계, 승인 흐름 | 17개 프로필을 독립 실행 단위로 분리한다 |
| 직원 운영 화면 | Claw3D + Kanban | 직원 레지스트리, 세션, 작업 카드, 인계 상태 | WebSocket 기반 레지스트리와 작업공간을 연결한다 |
| 기본 브라우저 관측 | Chrome/CDP + ss-* 도구 |
역할별 세션과 정형화된 화면 조회 | 보안확인 화면을 감지하면 코드 작업을 중단하고 기존 탭과 작업 상태를 인계한다 |
| 보안확인 1차 | Byparr | 격리 브라우저로 같은 공개 페이지의 구조화 데이터 확인 | 성공하면 현재 회차의 남은 페이지도 같은 백엔드로 읽는다 |
| 보안확인 2차 | Gemini Computer Use | 기존 탭의 시각 대응 | 1차 실패 뒤 화면에 보이는 단순 확인 요소만 처리하고 코드가 실제 페이지를 재검증한다 |
| 보안확인 3차 | Hermes Browser | 기존 탭의 두 번째 시각 대응 | 2차 실패 뒤 같은 검증 계약으로 마지막 복구를 시도한다 |
| 보안확인 전환·감시 | Python watcher + systemd + 상태 기록 | 단계 전환, 읽기 전용 기존 탭 감시, 정확한 커서 재개 | 진행은 집계 알림에 갱신하고 실패·안전 중단처럼 사람이 볼 사건만 별도로 알린다 |
| 브라우저 기반 | Chromium | 직원별 로그인 세션과 로컬 headless 실행 | 브라우저별 세션·권한·작업 범위를 분리한다 |
| 메시징·결정 게이트 | Slack Socket Mode | 정상 진행, 예외, 중단, 사용자 결정 | 키·이메일 원문·결제정보를 메시지에 넣지 않는다 |
| 메일 계층 | SMTP/자체 메일 연동 | 업무 결과 전달과 반송 수집 | 발송 결과를 외부 식별자와 함께 기록한다 |
| 운영 환경 | Ubuntu, Docker, systemd, WebSocket | 서비스 기동, 프로세스 관리, 실시간 연결 | 서비스별 책임과 재기동 경계를 분리한다 |
| 문서·구성 | Markdown, YAML, Mermaid | 역할 계약, 앱 매니페스트, 구성도 | 실행 가능한 설정과 설명 문서를 같은 구조로 관리한다 |
| 회귀 시험 게이트 | Django test runner + ss-selftest |
가격 계산·알림 분류·인계 상태·지난 사고 재현 시험(220여 개), 매일 실행 | 실패하면 업무 웹 배포가 막히고, 알림 문구 원본과 운영 워크플로가 다르면 실패한다 |
| 운영 감시·알림 | systemd timer + JSON Lines outbox + Node.js 알림 렌더러 | 장기 대기·관측 중단·작업 정체 경고, 팀별·사건별 Slack 전달 | 같은 사건 알림은 담당 팀 채널의 한 스레드로 묶고, 인프라 채널에는 최종 실패만 올린다 |
| 웹 인증 | TOTP 2단계 인증(PyOTP) | 운영 웹 로그인 | 비밀번호 외 일회용 코드가 있어야 업무 웹에 들어간다 |
| 재해 복구 | Terraform | 서버 재구성 정의를 주기적으로 생성 | 복구 절차를 코드로 남겨 수동 재구성 의존을 줄인다 |
| 공공 데이터 연동 | 공공데이터포털·정책 공고 API(k-skill) | 정부지원·정책자금 공고, 사업자 상태, 기준금리 조회 | 전략 담당 AI는 읽기만 하고, 신청·계약은 사람이 한다 |
AI 직원은 판단·해석·인계·예외 설명을 담당한다. 주문 상태, 금액, 외부 식별자, 작업 임대, 정산 결과는 PostgreSQL에 저장한다. 대화 이력이나 Kanban 카드만으로 완료·결제·발송을 확정하지 않는다.
AI 직원에게 범용 SQL이나 무제한 셸 권한을 주지 않고, 다음과 같은 업무 단위 경계를 사용한다.
- 주문 조회와 상태 확인
- 상품·가격 관측 기록
- 작업 큐 생성과 인계
- 구매 실행 준비·확정·결과 대조
- 배송·회계·감사 기록 연결
- Slack 보고와 사용자 결정 요청
브라우저 worker는 화면을 읽고 정해진 행동을 수행한다. Hermes 직원은 실행 결과를 해석해 계속 진행할지, 중단할지, 예외로 전환할지 판단한다. 두 계층을 분리해 화면 자동화 변경이 업무 정책 전체를 바꾸지 않도록 한다.
정상 관측 중 Cloudflare Turnstile 보안확인이 감지되면 현재 요청을 중단하고 기존 브라우저 세션, 열린 탭, 정확한 작업 위치를 보존한다. 접근 계층은 같은 페이지의 필수 데이터를 아래 순서로 복구한다.
flowchart TD
RUN[일반 브라우저 관측] --> DETECT{Turnstile 감지?}
DETECT -->|아니요| DATA[공통 결과 계약으로 기록]
DETECT -->|예| PAUSE[현재 요청 중단<br/>열린 탭과 정확한 작업 위치 보존]
PAUSE --> B[1차 Byparr<br/>격리 브라우저에서 같은 공개 URL 읽기]
B -->|필수 데이터 확인| ROUND[현재 회차의 남은 페이지도 같은 백엔드로 처리]
B -->|확인 실패| G[2차 Gemini Computer Use<br/>기존 화면 시각 복구]
G -->|확인 실패| H[3차 Hermes Browser<br/>기존 화면 시각 복구]
G -->|통과 후 재검증| DATA
H -->|통과 후 재검증| DATA
H -->|실패| STOP[안전 중단<br/>커서 저장·다음 회차 재개]
PAUSE -. 읽기 전용 감시 .-> RECOVER{기존 탭이 스스로 회복?}
RECOVER -->|예| RETURN[현재 항목을 중복 요청하지 않고<br/>다음 페이지 경계에서 복귀]
RETURN --> DATA
ROUND --> DATA
| 단계 | 실행 경계 | 성공·전환 기준 |
|---|---|---|
| 1차 Byparr | 기존 탭과 분리된 격리 브라우저 | 같은 URL에서 필수 데이터를 검증한다. 성공하면 남은 회차도 이 경로로 읽는다 |
| 2차 Gemini | 기존 브라우저 탭 | 1차 실패 뒤 보이는 단순 확인 요소만 처리한다. 성공 문구 뒤 코드가 페이지 데이터를 다시 검증한다 |
| 3차 Hermes | 기존 브라우저 탭 | 2차 실패 뒤 같은 제약과 결과 계약으로 마지막 복구를 시도한다 |
세 단계는 같은 결과 계약을 사용한다. 상품 페이지는 제목·가격·재고·지역 조건·에디션을, 목록 페이지는 정확한 쿼리와 상품 링크를 검증한다. 기존 탭 감시기는 화면을 읽기만 하며 이동·새로고침· 클릭·새 탭 생성을 하지 않는다. 반복 보안확인, 1차 백엔드 연속 차단, 계정 상태 이상은 안전 중단 조건으로 취급하고, 이미 모은 결과와 정확한 목록·상품 위치를 저장한다. 진행 단계는 집계 알림에 갱신하며 전체 실패· 안전 중단·계정 이상처럼 사람이 확인할 사건만 별도로 알린다.
공개 문서에는 외부 매입처·판매처 이름, 상품·계정 식별자, 접속 주소·포트, 세션 값, 상태 파일 경로, 인증정보와 실제 운영 기록을 포함하지 않는다.
외부 결제나 웹 화면 조작은 DB 트랜잭션과 동시에 확정할 수 없다. 따라서 다음을 기본 설계로 둔다.
- 외부 주문·결제·메일 식별자를 저장하고 재개 시 대조
- 작업 임대와 세대 번호로 동시 실행 차단
prepare / commit / reconcile단계 분리- 확정 상태와 결과 불명 상태 분리
- DB 유니크 제약과 허용 상태 전이로 두 번째 확정 실행 차단
- outbox 사건으로 외부 알림을 재전달
- 마지막 성공 시각을 기록하고 서버 밖 감시로 중단을 탐지
사용자
|
v
+-------------------+
| Claw3D 3D Office |
+---------+---------+
|
| WebSocket
v
+-------------------+
| Hermes Adapter |
| 직원 레지스트리 |
+---------+---------+
|
+----------------+----------------+
| |
v v
+---------------------+ +---------------------+
| Hermes 프로필 | | 직원 작업공간 |
| profiles/ss-* | | workspace-ss-* |
| 표시 메타데이터 | | 역할 문서와 규칙 |
+---------------------+ +---------------------+
| |
+----------------+----------------+
|
v
+-------------------+
| 업무 스킬 연결 |
| 민감 스킬은 비공개 |
+-------------------+
- Claw3D는 Hermes Adapter의 직원 레지스트리에서 직원 ID·표시명·역할을 조회한다.
- Hermes 프로필은 직원별 런타임 식별자와 모델·세션 설정을 관리한다.
workspace-ss-*는IDENTITY.md,SOUL.md,AGENTS.md,TOOLS.md,USER.md를 제공한다.- 직원 문서는 역할·허용 범위·중단 조건·인계선을 선언한다.
- 실제 민감 스킬은 서버 로컬에서만 연결하며 이 저장소에는 본문을 포함하지 않는다.
project.md의 0.7.2 기준 실제 가동 구조를 공개 범위에 맞게 요약하면 다음과 같다.
n8n은 정기 실행과 연결을 만들고, 업무 웹이 정본 DB와 직원 작업함을 연결한다.
브라우저 작업은 직원 전용 Chrome 세션과 ss-* 업무 도구로 분리한다. Skyvern은
철수·제거되어 현재 운영 경로에 없으며, 원본 웹훅 주소·인증정보·운영 경로는 공개하지 않는다.
flowchart TD
NAPI[네이버 커머스 API] <--> WEB
N8N[n8n 예약·연결·알림] -->|정기 업무 키| WEB[업무 웹 Django 창구]
WEB <--> DB[(PostgreSQL 업무 DB)]
WEB -->|작업함| EMP[Hermes AI 직원 17인]
EMP -->|업무 단위 도구| TOOLS[ss-* 업무 도구]
TOOLS --> CHROME[직원 전용 Chrome·CDP]
CHROME --> EXT[승인된 외부 업무 화면]
TOOLS --> OBS[비민감 관측 outbox]
OBS -->|주기 수집| WEB
WEB --> UI[업무 웹 화면·사용자]
EMP <--> SLACK[Slack 팀 채널·DM]
SLACK <--> USER[사용자 결정·인증 대기]
WATCH[서비스·업무 감시] --> ALERT[n8n 알림 흐름] --> SLACK
DB --> PACK[지휘본부 점검 자료]
PACK --> HQ[COO·CTO·CFO·CSO]
HQ --> AUDIT[오탐 판단·감사 기록]
AUDIT --> WEB
매입처 관측과 네이버 경쟁가 비교는 관측 outbox로 모은 뒤 공통 장부 판정과 자동 검증을 거친다. 플랫폼팀은 판정 결과를 확인해 상품 상태를 반영하고, 지휘본부는 검색 근거와 의심 사건을 별도 감사 자료로 대조한다. 공개 레이어에는 상품번호·판매자·가격 원문·검색 원본·내부 파일 경로를 포함하지 않는다.
flowchart LR
SOURCING[매입처 관측 주기] --> OBS[(관측 outbox)]
MARKET[네이버 경쟁가·신규 후보 비교] --> OBS
OBS --> LEDGER[공통 장부 판정·마진 규칙]
VERIFY[자동 검증·재검색 조건] --> OBS
LEDGER --> PLATFORM[플랫폼팀 상품 상태 반영] --> STORE[스마트스토어]
OBS --> EVIDENCE[지휘본부 감사 자료]
EVIDENCE --> COO[COO 근거 대조]
COO --> REVIEW[오탐·미탐 판단 기록]
REVIEW --> AUDITS[업무 웹 품질 화면]
USERREPORT[사용자 제보] --> OBS
아래는 구현체와 교체 가능한 계층 계약을 설명하는 공개 논리 흐름이다. 현재 서버의 가동 경로와 실행기 구성은 위의 0.7.2 현재 가동 구성도가 우선한다.
| 01 Ingest 외부 API·n8n 조회·중복 제거 |
→ | 02 Decide Django·PostgreSQL 상태 전이·승인 |
→ | 03 Execute Hermes·Browser worker prepare / commit |
→ | 04 Reconcile outbox·감사 이력 결과 대조 |
flowchart TD
N[네이버 커머스 API]
N8[n8n: 예약 트리거·Slack·메일·외부 연결] -->|주기 호출| API[Django 업무 API: 조회 위치·중복 제거·상태 전이]
API <--> N
API <--> DB[(PostgreSQL: 정본·작업표·정책·전이표·제약·하트비트)]
API -->|사건| H[Hermes AI 사원 17역할: 판단·대응]
H -->|업무 단위 도구만| API
H -->|run 단위 판단| BR[브라우저 실행: 전역 임대 1개·주문 P0]
BR --> SK[실행 workflow: prepare / commit / reconcile]
SK --> BR --> API
API -->|outbox 사건| N8
N8 --> SL[Slack: 주문 채널·예외 채널·일일 요약]
SL -->|사용자 결정| N8 --> API
DB --> KB[Claw3D Kanban]
DB --> UI[웹 화면]
HC[서버 밖 감시] -.->|마지막 조회 성공 시각| API
| 계층 | 책임 | 하지 않는 일 |
|---|---|---|
| 외부 커머스 API | 주문·상품·정산 정보 제공 | 내부 상태의 유일한 정본 역할 |
| n8n | 예약, polling, 연결, 알림, 사건 생성 | 결제 판단과 거래 상태 보관 |
| Django API | 업무 규칙, 상태 전이, 권한, 작업 임대, outbox | 브라우저 화면을 직접 해석 |
| PostgreSQL | 상태·금액·식별자·감사 이력의 정본 | AI 판단을 대신 수행 |
| Hermes | 역할별 판단, 결과 해석, 인계, 예외 보고 | 범용 DB 직접 조작 |
| Browser worker | 화면 관측과 브라우저 행동 | 전체 업무 정책 결정 |
| Slack | 진행상황, 예외, 사용자 결정 | 비밀값·원문 고객정보 저장 |
| Claw3D/Kanban | 운영 시각화와 작업 관리 | 거래 정본 저장 |
운영 런타임·프록시·heartbeat·배치는 공통 기록기(ss_alert.py)를 호출해 사건을
JSON Lines outbox에 append한다. 별도 전송기(ss_alert_watch.py)는 cursor와 quiet
상태를 관리하면서 새 사건만 묶어 자동화 웹훅으로 보내고, 후속 워크플로가 팀 알림으로
전달한다. 웹훅 자격증명, workflow·credential DB, 실제 로그와 상태 파일은 공개 범위에서
제외한다. 공개 구현은 infra/alerts에 정리했다.
외부 사이트에서 확인 화면이 나타나면 코드 관측을 멈추고 열린 탭을 자동 감시기에 넘긴다. 감시기가 처리하면 중단된 관측을 같은 지점부터 재개하고, 처리하지 못하면 인프라 담당에게 알린다. 이 사건의 진행 알림은 담당 팀 채널에서 사건별 한 스레드로 묶는다.
운영 중인 n8n 워크플로 16개(모두 활성)의 구성도다. ss-n8n-snapshot이 운영 n8n에서 워크플로를
내보내 노드 이름·종류·연결과 HTTP 대상 종류(업무 API·Slack API)만 남긴 뒤, 같은 서버의 n8n
미리보기 화면에서 다크 테마로 자동 캡처한다. 코드·URL 경로·헤더·채널 ID·자격증명·실행 데이터는
그림에 들어가지 않으며, 워크플로가 바뀌면 바뀐 것만 다시 그린다.
대부분의 예약 흐름은 같은 모양이다: 예약 트리거 → 업무 API에 작업 키 전달 → 결과 확인 → 실패 시 #ss-인프라팀 알림 → 알림 전달 확인. 업무 판단은 업무 API 뒤의 AI 직원이 하고, n8n은 시각과 연결만 맡는다.
| 주문·구매 | |
| 주문 조회 2분마다 → 주문 관제(Emma)  |
구매 모니터링 점검 08:00·16:00 → Lucas  |
| 영업 | |
| 매입처 관측 매시간 → Noah  |
네이버 가격 비교 2시간마다 → Ava  |
| 새 상품 발굴 연쇄 5분마다 확인 → Noah  |
신규 후보 비교 발굴 라운드 직후 → Ava  |
| 플랫폼 | |
| 플랫폼 장부 갱신 3시간마다 → Mia  |
등록 후보 바로 등록 5분마다 확인·순차 → Mia  |
| 회계·지휘본부 | |
| 회계팀 정기 업무 월초·월 마감·연간 신고 → Henry·Nora  |
COO 일일 점검 매일 17:00 → Olivia  |
| CTO 일일 점검 매일 17:00 → Ethan  |
CFO 주간 조언 월 17:00 → Sophia  |
| CSO 주간 보고 월 17:00 → Daniel  |
|
| 인프라·알림 | |
| 일일 백업·복원 점검 매일 05:00 → Liam  |
재해 복구 Terraform 3일마다 04:00 → Liam  |
| 통합 알림 라우팅 알림 수신 → 팀별 분기 → 응답 확인 |
|
장부형 업무 웹의 공개용 React·TypeScript·Vite 소스를 frontend/에 정리했다.
상품 장부, 회계 장부, 가격 계산기·정책, 보낸 메일 화면과 상대 경로 API 계약을 포함하며,
운영 API·인증정보·원본 상품/주문/고객/금융 데이터·외부 판매 채널 식별자는 포함하지 않는다.
화면 예시는 실제 값과 날짜를 비식별화해 UI 구조만 보여준다.
| 상품 장부 상태·재고·가격·마진 관측  |
회계 장부 월별 대조·판매·정산·세금·입금  |
최근 서버 변경에서 추가된 주문 관제, 구매 상태, 고객 전달, 메일 전달 상태의
공개 가능한 계약을 docs/operations/order-purchase-mail.md에
정리했다. 유일 제약과 실행 임대, 중복 결제 방지, 암호화 키 보관·폐기, 가림 값,
관리자 권한 게이트, 메일 전달·수신확인 상태를 설명하되 외부 판매 채널 식별자와
계정·주문·고객 원문은 공개하지 않는다.
공개 프런트엔드의 보낸 메일 탭은 수신자·키를 가림 값으로만 표시하고, 전달 상태와
수신확인 시각을 운영자가 확인하는 화면 계약만 제공한다. 실제 메일 원문과 전달
자격증명은 서버 런타임에만 존재한다.
회계 장부의 기간별 요약, 자료 상태, 구매 인계·카드 대조, 예상 수익과 문서함 경계는
docs/operations/accounting-reconciliation.md에
정리했다. 실제 금융자료와 외부 채널 식별자는 운영 서버에만 남긴다.
2026-10-06 서버 업데이트에서 추가된 상품 변동·오탐 내역 화면은 읽기 전용 공개 계약으로
반영했다. 사원별 모델 라벨과 연결 스킬 이름은
docs/operations/employee-skill-catalog.md에,
백업·복원 시험 확인 규칙은
docs/skills/infrastructure/ss-backup-restore-check.md에
정리했다. 상품 제외·사용자 대기·오탐/미탐·증거 품질 규칙은
docs/operations/ledger-quality.md에 정리했다.
스킬 원문과 운영 자료는 공개하지 않는다.
2026-10-07~10-10 서버 변경은
docs/operations/current-server-updates-2026-10-10.md에
공개 가능한 운영 계약으로 요약했다. Chrome 기반 실행·인프라 복구·사용량/토큰 기록·
예외 중심 상품 관측·발굴 연쇄·상품별 비교 주기·가격/포트폴리오·주문별 회계 대조·
외부 반영 재확인 원칙을 다루며, 실행 원본과 민감정보는 포함하지 않는다.
현재 가동 구성을 모델 제공자와 역할별로 나누면 다음과 같다. 계정 이름·이메일·잔여량· 인증 상태는 공개하지 않고, 계정 수와 역할 배정 구조만 공개한다.
flowchart LR
HQ[지휘본부 4명<br/>COO · CTO · CFO · CSO] --> CP[GitHub Copilot<br/>GPT-6 Luna]
OPS[실무·지원 13명<br/>플랫폼 · 영업 · 구매 · 회계 · 경리 · 인프라] --> G[agy<br/>Gemini 3.8 Flash High]
G --> PRIMARY[주 계정 2개<br/>Hermes · Accounting]
G --> BACKUP[백업 계정 2개<br/>소진·한도 부족 시 순차 전환]
PRIMARY --> USAGE[10분 주기 사용량 확인]
BACKUP --> USAGE
USAGE --> ALERT[한도 부족·소진·회복 알림]
CP --> TOKENS[실행 사용량 기록<br/>제공된 값만 기록]
G --> TOKENS
- 전체 AI 논리 직원은 17명이며, 모델 배정은 Copilot 4명 + Gemini 13명이다.
- Gemini 계열 agy 계정은 **총 4개(주 2개·백업 2개)**로 운영한다. 주 계정 소진이나 실행 중 한도 오류가 확인되면 백업 풀에서 남은 사용량이 많은 계정을 우선 사용한다.
ss-agy-usage가 계정별 Gemini·GPT 묶음의 사용량을 읽지만, 이 저장소에는 계정 식별자·이메일·토큰·실제 잔여량을 저장하지 않는다.- Skyvern은 과거 보조 실행기였으나 철수·제거되었고, 현재 화면 실행은 Chrome/CDP와
ss-*도구만 사용한다.
직원은 프로필 ID, 표시명, 작업공간, 역할 문서로 구성된다. 표시명은 운영 화면에서 식별하기 쉽도록
이름 (ss-역할) 형식을 사용하며, 프로필 ID와 폴더명은 안정적인 내부 식별자로 유지한다.
| 지휘본부 검증·전략·품질 |
플랫폼·영업 상품·시장·매입 관측 |
인프라 서비스·데이터·복구 |
구매·배송 주문·실행·전달 |
회계·경리 원장·정산·분류 |
| 팀 | 직원 | 프로필 | 작업공간 | 기술적 책임 |
|---|---|---|---|---|
| 지휘본부 | Olivia | ss-coo |
workspace-ss-coo |
원본 증거와 장부의 교차 검증 |
| 지휘본부 | Ethan | ss-cto |
workspace-ss-cto |
직원 상태·문서·연결 품질 점검 |
| 지휘본부 | Sophia | ss-cfo |
workspace-ss-cfo |
가격·이벤트·성과 지표 조언 |
| 지휘본부 | Daniel | ss-cso |
workspace-ss-cso |
자금·정책·중장기 전략 조언 |
| 플랫폼팀 | Mia | ss-platform |
workspace-ss-platform |
상품·재고·상세·플랫폼 작업 |
| 영업팀 | Noah | ss-sales-sourcing |
workspace-ss-sales-sourcing |
매입정보 관측과 1차 검증 |
| 영업팀 | Ava | ss-sales-market |
workspace-ss-sales-market |
경쟁가·예상 이익 2차 검증 |
| 인프라팀 | Mason | ss-infra-ops |
workspace-ss-infra-ops |
승인된 배포·연동·서비스 상태 |
| 인프라팀 | Liam | ss-infra-data |
workspace-ss-infra-data |
백업·복원·보존 상태 |
| 구매팀 | Emma | ss-order-watch |
workspace-ss-order-watch |
주문 사건 관제와 작업 큐 |
| 구매팀 | Lucas | ss-purchase-monitor |
workspace-ss-purchase-monitor |
계정 상태와 경고 모니터링 |
| 구매팀 | James | ss-purchase-main |
workspace-ss-purchase-main |
구매 실행 주담당 |
| 구매팀 | Grace | ss-purchase-backup |
workspace-ss-purchase-backup |
인계·복구와 활성 백업 |
| 구매팀 | Leo | ss-delivery |
workspace-ss-delivery |
배송·직접전달 처리 |
| 회계팀 | Nora | ss-accounting-web |
workspace-ss-accounting-web |
원장·원가·카드·조정 전표 |
| 회계팀 | Henry | ss-accounting-naver |
workspace-ss-accounting-naver |
정산·세금계산서·입금 대조 |
| 경리팀 | Ella | ss-bookkeeping |
workspace-ss-bookkeeping |
원본 분류와 승인 CSV 준비 |
IDENTITY.md: 표시명과 역할 식별SOUL.md: 판단 원칙과 금지 범위AGENTS.md: 실행 주기, 인계선, 승인, 중단 조건TOOLS.md: 허용 도구와 데이터 범위USER.md: 사용자 응답 형식과 보고 기준
지휘본부는 직접 실무를 실행하지 않고 검증·조언·인계를 담당한다. 구매·결제·고객정보·민감한 업무 데이터는 역할 문서만으로 권한이 생기지 않으며, 연결된 업무 도구와 별도 승인 경계를 거쳐야 한다.
17명은 하나의 공용 앱이 아니라 직원별 Slack App Manifest를 사용한다. 각 매니페스트는 다음 계약을 가진다.
- Slack Socket Mode 기반 연결
- 직원별 앱 표시명·봇 표시명·프로필 ID
- 역할별 담당 채널과 DM 흐름
- Hermes gateway 명령 endpoint
- 토큰·사용자 ID는 저장소에 기록하지 않음
| 17 Apps 직원별 표시명·봇·권한 |
→ | Socket Mode 실시간 이벤트 전달 |
→ | Hermes Gateway 프로필·작업공간 연결 |
→ | Approval Gate 예외·확정·중단 |
Slack App Olivia (ss-최고운영)
|
v
Hermes profile ss-coo
|
v
workspace-ss-coo
매니페스트는 slack_apps/ss-*/app-manifest.yaml에, 17개 앱의 비밀값 없는 매핑은
slack_apps/employee-integrations.yaml에 저장한다. 실제 토큰 발급과 환경변수 등록은 운영 서버의
비공개 설정에서 수행한다.
공개 저장소 구조 펼쳐보기
workspace-agent/
├── README.md
├── LICENSE
├── .gitignore
├── docs/
│ ├── assets/
│ │ ├── accounting-ledger-ui.png
│ │ ├── employee-network.svg
│ │ ├── n8n/ # 워크플로 16개 구성도(ss-n8n-snapshot 자동 생성, 다크 테마)
│ │ ├── product-ledger-ui.png
│ │ └── workspace-agent-hero.svg
│ ├── skills/
│ │ ├── accounting/ # 민감정보를 제거한 회계팀 공개 스킬 계약
│ │ └── infrastructure/
│ │ └── ss-backup-restore-check.md # 백업·복원 확인 계약
│ └── operations/
│ ├── employee-skill-catalog.md # 사원별 모델·스킬 이름 카탈로그
│ ├── accounting-reconciliation.md # 회계 요약·자료 상태·원가 대조 계약
│ ├── ledger-quality.md # 상품 변동·오탐 품질 계약
│ ├── order-purchase-mail.md # 주문·구매·메일 공개 운영 계약
│ └── current-server-updates-2026-10-10.md # 최신 서버 변경 공개 요약
├── frontend/
│ ├── src/ # React 화면·상대 경로 API 계약·스타일
│ │ ├── Dashboard.tsx # 비민감 통합 관제 화면
│ │ ├── Orders.tsx # 가림 값 기반 주문 현황 화면
│ │ ├── Changes.tsx # 상품 변동 읽기 전용 화면
│ │ ├── Audits.tsx # 오탐 내역 읽기 전용 화면
│ │ ├── AcctSummary.tsx # 기간별 회계 요약 화면
│ │ └── Mail.tsx # 가림 값 기반 메일 전달 상태 화면
│ ├── dist/ # 정적 빌드 결과
│ ├── package.json
│ └── README.md
├── infra/
│ └── alerts/
│ ├── bin/ # 사건 기록기와 자동화 웹훅 전송기
│ ├── producers/ # 런타임·프록시·heartbeat·배치 알림 지점
│ ├── systemd/ # 1분 주기 전송 서비스·타이머
│ └── README.md # 공개 알림 계약과 운영 비공개 경계
├── slack_apps/
│ ├── employee-integrations.yaml
│ ├── ss-accounting-naver/app-manifest.yaml
│ ├── ss-accounting-web/app-manifest.yaml
│ ├── ss-bookkeeping/app-manifest.yaml
│ ├── ss-cfo/app-manifest.yaml
│ ├── ss-coo/app-manifest.yaml
│ ├── ss-cso/app-manifest.yaml
│ ├── ss-cto/app-manifest.yaml
│ ├── ss-delivery/app-manifest.yaml
│ ├── ss-infra-data/app-manifest.yaml
│ ├── ss-infra-ops/app-manifest.yaml
│ ├── ss-order-watch/app-manifest.yaml
│ ├── ss-platform/app-manifest.yaml
│ ├── ss-purchase-backup/app-manifest.yaml
│ ├── ss-purchase-main/app-manifest.yaml
│ ├── ss-purchase-monitor/app-manifest.yaml
│ ├── ss-sales-market/app-manifest.yaml
│ └── ss-sales-sourcing/app-manifest.yaml
├── profiles/
│ ├── ss-accounting-naver/profile.yaml
│ ├── ss-accounting-web/profile.yaml
│ ├── ss-bookkeeping/profile.yaml
│ ├── ss-cfo/profile.yaml
│ ├── ss-coo/profile.yaml
│ ├── ss-cso/profile.yaml
│ ├── ss-cto/profile.yaml
│ ├── ss-delivery/profile.yaml
│ ├── ss-infra-data/profile.yaml
│ ├── ss-infra-ops/profile.yaml
│ ├── ss-order-watch/profile.yaml
│ ├── ss-platform/profile.yaml
│ ├── ss-purchase-backup/profile.yaml
│ ├── ss-purchase-main/profile.yaml
│ ├── ss-purchase-monitor/profile.yaml
│ ├── ss-sales-market/profile.yaml
│ └── ss-sales-sourcing/profile.yaml
├── workspace-blog/
│ ├── AGENTS.md
│ ├── IDENTITY.md
│ ├── SOUL.md
│ ├── TOOLS.md
│ └── USER.md
├── workspace-infra/
│ ├── AGENTS.md
│ ├── IDENTITY.md
│ ├── SOUL.md
│ ├── TOOLS.md
│ └── USER.md
├── workspace-ss-accounting-naver/
│ ├── AGENTS.md
│ ├── IDENTITY.md
│ ├── SOUL.md
│ ├── TOOLS.md
│ └── USER.md
├── workspace-ss-accounting-web/
├── workspace-ss-bookkeeping/
├── workspace-ss-cfo/
├── workspace-ss-coo/
├── workspace-ss-cso/
├── workspace-ss-cto/
├── workspace-ss-delivery/
├── workspace-ss-infra-data/
├── workspace-ss-infra-ops/
├── workspace-ss-order-watch/
├── workspace-ss-platform/
├── workspace-ss-purchase-backup/
│ └── skills/.gitkeep
├── workspace-ss-purchase-main/
│ └── skills/.gitkeep
├── workspace-ss-purchase-monitor/
│ └── skills/.gitkeep
├── workspace-ss-sales-market/
└── workspace-ss-sales-sourcing/
각 Smartstore workspace의 표준 문서는 동일한 계약을 따르며, 구매팀 skills/는 영업비밀 보호를 위해
빈 폴더 표식만 저장한다. Git은 빈 폴더를 추적할 수 없으므로 .gitkeep을 사용한다.
| Stateful 재시작·중복·부분 실패 복구 |
Role-based 17개 역할과 명시적 권한 경계 |
Replaceable 브라우저 실행기 교체 가능 |
Auditable 상태 전이·outbox·감사 이력 |
스케줄러나 AI 대화가 중단되어도 마지막 성공 조회 지점, 외부 식별자, 작업 임대, 상태 전이를 DB에서 복구할 수 있다. 이는 단순 자동화 스크립트와 달리 재시작·중복·부분 실패를 설계 대상으로 삼은 부분이다.
17명의 AI 직원을 하나의 범용 에이전트로 만들지 않고 역할별 프로필·작업공간·문서·도구 범위로 분리했다. 문서 계약은 사람 조직의 직무기술서와 비슷한 역할을 하며, 실행 권한은 DB와 업무 API가 추가로 제한한다.
주 브라우저 worker와 보조 엔진을 업무 코어에서 분리해 화면 변경이나 자동화 엔진 교체가 상태 모델·감사 이력·직원 역할을 다시 설계하는 일로 번지지 않도록 했다.
공개 저장소에는 재현 가능한 구조와 비민감 계약만 두고, 운영 서버에는 비공개 환경변수, 브라우저 세션, 인증 설정, 업무 스킬 본문을 둔다. 공개 가능한 설계와 운영 비밀을 분리하는 저장소 경계를 명확히 한 것이 이 프로젝트의 중요한 운영 설계다.
| 공개 역할 문서 · 구조 · 계약 · 구성도 재현 가능한 공개 레이어 |
비공개 인증정보 · 거래 데이터 · 세션 운영 런타임 · 구매 실행 자료 |
저장소에 포함하지 않는 항목:
| API key, access token, OAuth token, 비밀번호, private key | Slack Bot/App Token과 사용자 ID |
| 브라우저 쿠키·세션·인증 파일 | PostgreSQL·SQLite·n8n 실행 데이터 |
| 고객 이메일, 결제정보, 게임 키, 원본 장부 | 외부 판매 채널별 계정·가격·주문 자료와 구매 실행 playbook |
구매팀의 SKILL.md 및 실제 스킬 구현 |
로그, 캐시, 런타임 상태, 내부 비밀 설정 |
.gitignore는 구매팀 스킬과 외부 판매 채널별 자료가 실수로 추가되지 않도록 경로명 기반 차단 규칙도 포함한다.
공개 저장소에 올리는 파일은 문서 allowlist와 staged diff 검사를 거친다.
공개 저장소 검증 명령 펼쳐보기
git diff --check
git ls-files '*SKILL.md'
git ls-files '*skills/*'
git ls-files | grep -Ei 'credentials|secrets|token|private' || true
find . -type f \( -name '.env' -o -name '*.sqlite3' -o -name '*.lock' \) -print정상 공개 상태에서는 실제 SKILL.md, 인증파일, 데이터베이스, 외부 판매 채널별 파일이 출력되지 않아야 한다.
- Smartstore AI 직원 17명 프로필·작업공간 문서화 완료
- Claw3D 직원 레지스트리와 Hermes 작업공간 연결 구조 반영
- 직원별 Slack App Manifest와 Socket Mode 연동 계약 정리
- Django·React·PostgreSQL·n8n·Hermes·Claw3D·브라우저 worker를 포함한 목표 아키텍처 문서화
- 상품 장부·회계 장부·계산기·정책·보낸 메일 공개 프런트엔드와 빌드 결과 반영
- 주문 관제·구매 상태·고객 전달·메일 전달 상태의 공개 운영 계약 반영
- 통합 관제·주문 현황·기간별 회계 요약·AI 사원·작업 로직의 공개 UI 계약 반영
- 상품 변동·오탐 내역의 읽기 전용 공개 UI 계약 반영
- 사원별 연결 스킬 카탈로그와 백업·복원 확인 스킬의 비민감 계약 반영
- 구매 인계·카드 대조·문서함·예상 수익의 회계 운영 계약 반영
- 최신 서버의 Chrome 실행·복구·사용량·관측·발굴·가격·포트폴리오 운영 변경 요약 반영
- 회귀 시험 게이트(220여 개)·알림 문구 원본과 운영 워크플로 일치 검사 반영(2026-10-17)
- 장기 대기·관측 중단 경고와 사건별 Slack 스레드 알림 반영(2026-10-17)
- 전략 담당 AI의 정부지원·정책자금 공고·공공데이터 주간 수집 반영(2026-10-17)
- 외부 사이트 확인 화면의 자동 감시·재개·실패 알림 흐름 반영(2026-10-17)
- 매입처 식별 정보와 Slack 채널 ID·워크스페이스 주소를 공개 범위에서 제외(2026-10-17)
- 구매팀 스킬과 외부 판매 채널별 영업비밀은 저장소에서 제외
- 저장소는 공개 구조와 비민감 운영 문서에 한정
이 저장소의 원본 문서, 구성 파일, SVG 시각화 자산은 Apache License 2.0으로 공개한다. 외부 서비스·상표·라이브러리·의존성은 각 권리자의 라이선스와 이용약관을 따르며, 이 저장소의 라이선스가 그 권리를 대신 부여하지 않는다. 비공개 운영 데이터와 서버 로컬 스킬은 이 저장소의 배포 대상이 아니다.