자동화 계층 프레임워크 (Automation Layer Framework)
어떤 프로그램이나 서비스를 자동화할 때 접근 방법에 따라 안정성이 달라진다. API(1계층·가장 안정·병렬) → CLI(2계층·중간·텍스트) → GUI(3계층·불안정·단일스레드)의 3계층으로 분류하며, “몇 계층인지 먼저 판단”이 자동화 설계의 출발점이다. exec는 AI 에이전트가 디지털 세계 밖(CLI·GUI)으로 나가는 유일한 통로다.
exec = 에이전트의 “손”
AI 에이전트 도구는 두 종류로 나뉜다:
| 유형 | 예시 | 특성 |
|---|---|---|
| 기능 고정 도구 | read, write, web_search, message | 하나의 기능에 특화, 범위 밖 불가 |
| exec | 셸 명령 실행 | 셸에서 뭐든 가능 |
read가 “눈”, write가 “펜”이라면 exec는 **“손”**이다. API 없는 카카오톡, 레거시 프로그램, 데스크톱 앱에 접근할 수 있는 유일한 통로. (출처: bbojjak-openclaw-automation-layers-lesson11)
자동화의 3계층
1계층: API — 가장 안정적 🏛️
프로그램이 “자동화해도 돼요”라고 공식 창구를 열어둔 방식.
장점:
- 구조화된 데이터(JSON) 반환 → 파싱 용이
- HTTP 상태 코드(200/400/500)로 결과 명확
- 동시에 100개 요청도 서버가 독립 처리 → 병렬 가능
- UI 변경과 무관하게 버전 관리 → 갑자기 깨질 위험 낮음
- ID 기반 접근 → 목록 순서가 바뀌어도 무관
적합한 경우: Slack, Airtable, Zoom 등 공식 API가 있는 서비스.
2계층: CLI — 중간 ⚙️
터미널 명령으로 프로그램을 조작하는 방식.
특성:
- 텍스트 입출력 → 파싱 가능
- 스크립트로 자동화 용이
- exec 도구가 가장 잘 다루는 영역
예시: git commit, ffmpeg, bun run script.ts
3계층: GUI — 가장 불안정 🎰
화면을 직접 조작하는 방식. 사람이 하는 걸 그대로 흉내냄.
구조적 한계:
- 화면 레이아웃 변경 → 좌표 오류
- 앱 업데이트 → 버튼 계층 변경 → 스크립트 파괴
- “클릭했다” ≠ “클릭이 성공했다” (검증 불확실)
- 화면은 하나 → 동시 접근 불가 (단일 스레드)
- 좌표 기반 → 목록 순서 변경 시 레이스 컨디션 발생
예시: AppleScript, Selenium, 좌표 클릭
고수준 추상화 구현체: OpenClaw의 browser 도구는 playwright 헤드리스 브라우저를 내부적으로 사용하며, GUI 3계층을 에이전트 친화적으로 래핑한 사례다. 직접 HTML→PNG 파이프라인으로 대량 이미지 생산에도 활용 가능. (출처: bbojjak-openclaw-playwright-image-pipeline-lesson13) → playwright-html-to-image 참조.
자동화 선택 프레임워크
자동화하고 싶다!
↓
Step 1: API가 있는가?
→ Yes → API 사용. 끝.
→ No ↓
Step 2: CLI가 있는가?
→ Yes → exec + CLI. 대체로 안정.
→ No ↓
Step 3: GUI밖에 없는가?
→ 아래 체크리스트 확인 후 결정
GUI 자동화 체크리스트
- 정말 다른 방법이 없는가? (비공식 API, 웹 버전 포함)
- 한 번인가 반복인가? (한 번이면 수동이 나을 수도)
- 실패 피해가 큰가? (엉뚱한 사람에게 메시지 전송 등)
- 동시 처리가 필요한가? (GUI = 본질적으로 단일 스레드)
- 결과를 독립적으로 검증할 수 있는가?
GUI 자동화 설계 5원칙
원칙 1: 날것으로 쓰지 않는다
GUI 조작 코드를 직접 쓰지 말고 검증 로직+폴백이 포함된 스크립트로 감싼다. 스크립트 안에서 삽질을 흡수하고, 바깥에서는 깔끔한 인터페이스를 제공한다.
exec("bash send_message.sh '방이름' '메시지'") # 외부에서는 이 한 줄
# 내부: 방 열기 → 타이틀 검증 → 입력 → 폴백 → 전송 → 검증원칙 2: 레이스 컨디션을 방지한다
“찾는 타이밍”과 “실행하는 타이밍” 사이에 세상이 변할 수 있다.
- API: ID로 접근 → 순서 무관
- GUI: 좌표/순서로 접근 → 실시간 변경 위험
대응: 윈도우 타이틀 검증, --skip-open 플래그(사람이 미리 창 열어두기) 등.
원칙 3: 단일 스레드 제약을 인식한다
GUI = 화면 하나 = 한 번에 하나만. 동시에 여러 세션이 화면을 건드리면 충돌.
설계 결정: 동시 접근 방지 규칙을 사전에 확정한다. 스케일링이 필요하면 가상 데스크톱을 고려한다.
“이 작업이 늘어나면 어떻게 되지?”를 설계 단계에서 질문한다.
원칙 4: 실패 자동화도 설계한다
성공 경로만 생각하면 안 된다. 실패했을 때:
- 재시도는 몇 번까지?
- 같은 에러를 반복 보고하지 않는 메커니즘 필요 (memory/ 파일에 상태 기록)
- 사람에게 에스컬레이션하는 기준은?
이 패턴은 agent-error-learning-loop의 “실패 자동화 설계” 원칙과 동일하다.
원칙 5: Trust but verify — 이중 검증
내부 검증만으로는 부족하다.
| 검증 종류 | 방식 | 한계 |
|---|---|---|
| 내부 검증 | 입력란 비워짐, exit code 확인 | ”전송 가능성”을 체크, 실제 도달 미확인 |
| 외부 검증 | 다른 경로로 결과 확인 | 더 확실하지만 추가 단계 필요 |
실전 패턴:
- 카톡 전송 →
read_messages.sh로 도달 확인 - 이메일 발송 → 발송 로그 확인
- 배포 → 실제 페이지 접근 확인
실무 보완: Layer 선택보다 먼저 “게시 책임”을 분리하라
네이버 블로그 자동화 사례(출처: yt-shinyeongseon-claudecode-naver-blog-automation-2026)는 기술 계층(API/CLI/GUI) 이전에 운영 책임 계층을 먼저 분리한다:
- AI: 키워드 리서치, 초안 작성, 구조화, 메타/태그/이미지 후보 생성
- 사람: 사실 검증, 브랜드 리스크 확인, 최종 게시/붙여넣기
핵심은 “완전 자동 발행”보다 human-in-the-loop를 남겨 저품질/정책 리스크를 낮추는 것. 즉, 자동화 계층 프레임워크는 기술 경로(API/CLI/GUI)뿐 아니라 최종 승인 경계까지 함께 설계해야 실전 품질이 안정된다.
또한 이 사례는 온보딩 인터뷰(회사/타깃/톤/금칙어/기존 글 샘플)를 먼저 구조화해, 같은 자동화 계층이라도 결과 편차를 줄이는 방법을 보여준다.
exec-approvals — 안전 제어
AI에게 컴퓨터를 맡길 때의 안전장치. 자동이체 한도 설정과 유사한 개념.
| 수준 | 설명 | 적합 상황 |
|---|---|---|
| deny | 터미널 완전 차단 | 읽기/쓰기만 하는 에이전트 |
| allowlist | 허용 목록 + 신규 명령 시 승인 요청 | 대부분의 운영 에이전트 |
| full | 전체 허용 | 완전히 신뢰할 수 있는 환경 |
승인 흐름: 에이전트가 새 명령 실행 시도 → 사람에게 알림 → Allow once / Always allow / Deny.
원격 승인: /approve <id> allow-once (Slack/텔레그램에서 가능).
이는 harness-engineering의 PreToolUse Hook으로 위험 명령을 차단하는 것과 동일한 원리다.
관련 개념
- agent-skill-design — exec를 활용한 스킬 scripts/ 실행 구조
- agent-error-learning-loop — 실패 자동화 설계 원칙; GUI 자동화 에러 반복 보고 사례
- agentic-scheduling-design — 하트비트(폴링·모니터링)가 GUI 자동화와 조합될 때 에러 반복 보고 문제
- harness-engineering — exec-approvals가 PreToolUse Hook과 동일한 원리
exec-approvals와 exec 보안 설정의 차이
Lesson 11의 exec-approvals(실행 전 사람 승인)와 Lesson 17의 exec.security: allowlist는 다른 메커니즘이다:
| 방식 | 동작 | 목적 |
|---|---|---|
| exec-approvals | 새 명령 시 사람에게 승인 요청 | 의도치 않은 명령 방지 |
exec.security: allowlist | 허용 목록 외 명령 자동 차단 | 보안 격리, 인젝션 방어 |
외부 대응 에이전트에는 allowlist 설정이 권장된다 — 인젝션에 성공해도 allowlist 외 명령 실행 불가. (출처: bbojjak-openclaw-agent-security-lesson17) → agent-security-design 참조.
소스
- bbojjak-openclaw-automation-layers-lesson11
- bbojjak-openclaw-playwright-image-pipeline-lesson13 (browser 도구 = GUI 3계층 Playwright 구현체)
- bbojjak-openclaw-agent-security-lesson17 (exec.security allowlist = exec 보안 제약)
- yt-shinyeongseon-claudecode-naver-blog-automation-2026 (AI 초안 + 사람 최종 게시의 human-in-the-loop 실전 패턴)