JYP Garden

수업 #11 — AI가 카톡을 친다고?

Properties1
tagssource, agentic-architecture, knowledge

7 min read

수업 #11 — AI가 카톡을 친다고?

Source: bbojjak-viewer.vercel.app/lessons/lesson-11 Type: article By: 뽀짝이 / 뽀짝이의 서재 (지피터스 AI스터디) Valid as of: 2026-04-28

Key Insight

exec = 에이전트의 “손” — 디지털 세계 밖으로 나가는 유일한 통로. 자동화는 API(안정·병렬) → CLI(중간) → GUI(불안정·단일스레드) 3계층으로 분류하며, GUI는 검증+폴백 스크립트로 감싸고 내부+외부 이중 검증을 필수로 적용한다.

핵심 Takeaway

  • exec = 에이전트의 “손”: 기능 고정 도구(read/write/message)와 달리 셸에서 뭐든 실행 가능. API 없는 카카오톡, 레거시 앱에 접근하는 유일한 통로 (출처: “exec가 특별한 이유” 섹션)
  • 자동화의 3계층 — 선택 프레임워크: API(1·가장 안정·병렬·ID 기반) → CLI(2·중간·텍스트) → GUI(3·불안정·좌표·단일 스레드). “몇 계층인지 먼저 파악” → 삽질 감소 (출처: “자동화의 3계층” 섹션)
  • exec-approvals — 안전 제어: deny/allowlist/full 3단계. 새 명령 실행 시 사람에게 승인 요청. 자동이체 한도처럼 편의와 안전의 균형 (출처: “exec-approvals” 섹션)
  • 검증의 2단계 — Trust but verify: 내부 검증(스크립트 상태·입력란 비워짐)만으로 부족. 독립적 외부 검증(다른 경로로 실제 결과 확인) 필수. VERIFIED이어도 read_messages.sh로 도달 확인 (출처: “에피소드 4” 섹션)
  • GUI 자동화 5가지 원칙: ①날것 금지→검증+폴백 스크립트 ②레이스 컨디션 방지(윈도우 타이틀 검증) ③단일 스레드 제약 인식 ④실패 자동화도 설계 ⑤독립 검증 가능성 사전 확인 (출처: “자동화 판단 프레임워크” 섹션)

상세 요약

exec와 다른 도구의 차이

도구역할범위
read눈파일 읽기만
write펜파일 쓰기만
message메신저채널 전송만
exec손셸에서 뭐든

3계층 비교

계층안정성병렬 가능에러 추적
API⭐⭐⭐O (서버가 처리)HTTP 상태 코드로 명확
CLI⭐⭐O (프로세스)exit code + stdout
GUI⭐X (화면 하나)“클릭했다” ≠ “성공했다”

카카오톡 스킬 구조 (에피소드 1)

검증+폴백이 포함된 셸 스크립트 4개로 구성:

  • send_message.sh: 방 열기 → 윈도우 타이틀 검증 → 메시지 입력(set value → Cmd+V 폴백) → 전송 → 입력란 비워짐 검증

이중 폴백 이유: 한글 입력에 keystroke 불가 → set value of text area 우선, 실패 시 클립보드 붙여넣기.

에러 15번 반복 보고 (에피소드 3) — 실패 자동화 설계

카카오톡 앱 버그 → 하트비트마다 재보고 (하트비트 세션은 매번 새 세션이라 이전 기억 없음).

해결: memory/ 파일에 “이미 보고한 에러” 상태 기록 → 다음 하트비트에서 “기존 에러” 판단 후 스킵.

이는 agent-error-learning-loop에서 정의한 패턴의 GUI 자동화 맥락 재발이다. “실패 자동화”(실패했을 때의 에러 처리 프로세스)도 미리 설계해야 한다.

Trust but verify — 외부 검증 원칙 (에피소드 4)

이모지 파서 에러 → 폴백 과정에서 텍스트가 입력란에 잠깐 들어갔다가 지워짐 → 스크립트 “입력란 비었으니 VERIFIED” → 실제 미전송.

교훈: 실행한 시스템과 다른 시스템으로 결과를 확인해야 한다.

적용 패턴:

  • 이메일 발송 → 발송 로그 확인
  • 파일 업로드 → URL 접근 확인
  • 배포 → 실제 페이지 확인
  • 카톡 전송 → read_messages.sh로 도달 확인

연결되는 위키 페이지

그래프 뷰