23) nonos(No No Stress) - 업무자동화 agent 구축방안 검토

nonos의 ai agent 구축방안 검토!!

현실적으로 어떻게 설계해야 할까?
여기서 중요한 게, 시스템 전체를 agent로 만들 필요는 없다는 것이다.
workflow와 agent를 한 시스템 안에서 분리해야 한다.
Anthropic 가이드의 "Building Effective Agents"에서 가장 실용적인 패턴이다.
┌─────────────────────────────────────┐
│ 워크플로우 레이어 (예측 가능)         │
│ - 스케줄링                           │
│ - 메일 폴링                          │
│ - 파일 다운로드                      │
│ - DB 트랜잭션                        │
│ - 알림 발송                          │
└──────────┬──────────────────────────┘
            │ 위임 (정형화된 입력 → 정형화된 출력)
           ↓
┌─────────────────────────────────────┐
│ Agent 노드 (유연성 필요한 지점)       
│ ┌─────────────────────────────────┐ 
│ │ 송장 엑셀 파서 agent              
│ │ - 임의 포맷 → 표준 스키마        
│ │ - tools: read_excel, validate  
│ └─────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ 수취인 매칭 agent                
│ │ - 모호한 데이터 → 매칭 결과      
│ │ - tools: search_orders, check_dup
│ └─────────────────────────────────┘ │
│ ┌─────────────────────────────────┐ │
│ │ 발주 의사결정 agent              
│ │ - 주문들 → 업체 선택 + 합배송    
│ │ - tools: get_inventory, get_addr 
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

핵심 원리는: agent를 넓고 얇게 쓰지 말고, 좁고 깊게 쓰자!!

전체 발주 프로세스를 agent로 만들면 한 번 돌릴 때마다 토큰 폭탄 + 디버깅 지옥.
대신 워크플로우가 메인 흐름을 통제하고, 판단이 필요한 정확한 지점에서만 agent에게 작은 작업을 위임!

각 agent는:

• 명확한 입력 (예: 엑셀 파일)
• 명확한 출력 (예: {recipient: "...", tracking_no: "...", carrier: "..."} JSON)
• 제한된 도구 (3~5개)
• 짧은 루프 (최대 5~10 step)

이렇게 하면:

• 디버깅 가능 (각 agent 호출이 격리됨)
• 부분 실패 처리 가능 (한 agent 실패해도 워크플로우는 다음 단계로)
• 비용 통제 가능 (per-call 토큰 모니터링)
• 사람이 검토 단계 끼우기 쉬움 (agent 출력에 confidence score 두고, 낮으면 human-in-the-loop)

이 패턴에 NanoClaw 같은 agent 프레임워크가 필요한가?

답은 여전히 Nope!
NanoClaw는 메시징 인터페이스 + 컨테이너 격리 + 그룹별 메모리 관리에 최적화되어 있음.
위 그림은 그게 다 필요 없다!
진짜 필요한 건 Claude Agent SDK (또는 더 가볍게는 Anthropic Python SDK + tool use)을 직접 호출하면 된다.

# 송장 파서 agent의 골격 (Python 예시)
from anthropic import Anthropic

client = Anthropic()

tools = [
    {
        "name": "read_excel_sheet",
        "description": "엑셀 시트의 셀 값 읽기. 범위 지정 가능.",
        "input_schema": {...}
    },
    {
        "name": "validate_tracking_number",
        "description": "운송장 번호 형식 검증",
        "input_schema": {...}
    },
]

def parse_invoice_excel(file_path: str) -> list[InvoiceRow]:
    response = client.messages.create(
        model="claude-opus-4-7",
        tools=tools,
        messages=[{
            "role": "user",
            "content": f"이 엑셀에서 송장 데이터를 추출해. 파일: {file_path}"
        }],
        max_tokens=4096,
    )
    # tool_use 루프 돌리고 최종 결과 파싱
    return extract_structured_output(response)

이게 핵심이에요. Spring Boot 워크플로우가 메인 흐름이고, 이런 agent 함수들이 검증된 라이브러리처럼 호출되는 구조.
각 agent는 100~200줄 안에 끝나요.

Kotlin/Java 환경이면 Anthropic Java SDK 쓰면 같은 패턴으로 가능해요.
Spring Boot 코드베이스에 자연스럽게 녹일 수 있어요.

Human-in-the-loop이 진짜 중요해요:

위 케이스들 — 친구 매장 고객한테 잘못된 송장 보내면 큰 문제잖아요.
그래서 agent 출력을 무조건 신뢰하지 말고:

• Confidence threshold: agent가 "확실함"으로 분류한 것만 자동 처리
• Borderline 케이스: 텔레그램/슬랙으로 친구에게 "이거 맞나요?" 보내고 승인 받기
• 롤백 가능 설계: 잘못된 매핑 발견 시 한 번에 되돌리기

이런 게 워크플로우의 "예측 가능성"이 빛나는 지점이에요.
agent가 판단을 하지만, 워크플로우가 그 판단을 언제 신뢰할지 통제해요.

• NONOS의 메인 흐름은 워크플로우 (스케줄링, 메일 폴링, DB 트랜잭션, 알림)
• 판단이 필요한 노드는 좁은 agent (송장 파싱, 수취인 매칭, 합배송 판단)
• 두 레이어를 분리해서 구현, NanoClaw 같은 풀 프레임워크는 여전히 불필요
• Anthropic SDK 직접 호출로 충분 (또는 Claude Agent SDK)

---

맥미니와 나노클로 등은 일단 PASS~!!!!

agent만들어서 셀러들이 리포팅과 판단만 해주면 얼마나 편할까? ㅎㅎ 

6월 11일 이후에 제대로 시작!! ㅋㅋ