Part 3. AI Agent — 스스로 도구를 쓰고 배우는 일꾼

Part 2에서 AI가 ‘비정형을 다루고 회사 맥락을 누적하는 신입사원’임을 봤다. 그런데 신입사원도 손과 도구가 있어야 일한다. 에이전트는 LLM이라는 두뇌에 ‘도구를 쓰는 손’과 ‘배우는 습관’을 붙인 것이다. 이 부가 끝나면 Part 4의 ‘AI를 ERP에 결합한다’가 구체적 그림으로 보인다.

8장. 실행형 vs 학습형 에이전트 — 락인 공포를 차단하는 법

핵심 질문: “비슷해 보이는 오픈소스 에이전트가 너무 많은데 뭘 골라야 하나? 잘못 고르면 갇히는 것 아닌가?”

표면은 비슷하지만 설계 철학이 정반대인 두 부류가 있다. 실행형은 ‘지금 시키는 일을 잘하는 만능 비서’다. 한 줄로 설치하고 외부 LLM API를 연결해 메신저로 명령을 받아 PC·브라우저를 조작한다. 즉시성·범용성이 강점이나 세션 간 학습이 없다. 학습형은 ‘쓸수록 회사 맥락이 누적되는 비서’다. 작업하며 스스로 SKILL.md를 쓰고 MEMORY·세션DB를 누적하는 닫힌 학습 루프를 내장한다.

경쟁이 아니라 보완이다. 작업 성격으로 도구가 갈린다.

작업 성격	적합	이유
1회성 PC 자동화(파일 정리·메일 일괄)	실행형	학습 오버헤드 불필요
반복 표준 작업(BMS 회로 검토·CAN 로그 분석)	학습형	학습 루프로 회차마다 ROI 상승
보안 민감(도면·계약·인사)	학습형	컨테이너 격리 옵션 다양

락인 차단 전략

진짜 자산은 도구가 아니라 노하우다. SKILL.md·MEMORY.md를 특정 도구의 내부 포맷이 아니라 우리가 소유하는 표준 텍스트 파일로 보관하면, 도구를 바꿔도 자산은 남는다. 핵심은 “도구를 고르는 것”이 아니라 “자산을 우리 것으로 만드는 것”이다. (단, 오픈소스 에이전트는 메인 PC 직접 설치 금지 — VM/Docker에서, 기밀 접근 권한을 분리해 운영한다.)

한 장 요약 — 에이전트의 분기점은 학습 루프의 유무다. 1회성은 실행형, 반복·보안은 학습형. 노하우를 표준 텍스트로 소유하면 락인이 사라진다.

9장. Tool Use·Agentic Loop — LLM이 행동하는 법

핵심 질문: 말만 하는 LLM이 어떻게 DB를 바꾸고 메일을 보내는 ‘행동’을 하게 되는가?

LLM 단독은 텍스트만 만든다. 그래서 함수를 ‘도구(Tool)‘로 등록한다. ‘LLM → 도구 선택 → 실행 결과 → 재추론’의 반복 — 이것이 Agentic Loop, 에이전트의 심장이다.

기존 RPA와 결정적으로 다르다. RPA는 결정론이다: IF 메시지에 '연차 신청' AND 다음이 이름…. 100가지 표현을 if-else로 다 커버해야 하고, “박철수 다음주 좀 쉬게 해줘”라고 쓰면 못 알아듣는다. 에이전트는 사용자가 무슨 말을 하든 의도를 파악하고, 필요한 도구를 스스로 선택·조합하며, 막히면 우회한다. 미리 안 짠 시나리오에도 대응한다. 이것이 if-else 자동화와의 본질적 차이다.

무한 호출·실패를 막는 안전장치가 필요하다 — 동일 도구 최대 호출 횟수 제한, 실패 시 보상 트랜잭션(롤백) 후 재시도 또는 사람에게 에스컬레이션. 이는 14장의 가드 체인으로 구현된다.

우리의 현 위치 — 주방은 완공, 요리사는 부재

솔직한 자기 평가다. 우리 시스템은 데이터·도구·승인 구조 같은 인프라는 상당 부분 완성됐다. 그러나 ‘요리사’에 해당하는 핵심 — LLM 연동 루프(API 실제 호출 + Tool Use + 재추론) — 는 아직 뼈대 상태다.

구성 요소	상태
🍳 가스레인지(도구 등록소)	✅ 설치됨
🥕 식재료(업무 도구들)	✅ 준비됨
🔧 조리도구(승인 서비스)	✅ 정리됨
👨‍🍳 요리사(LLM 에이전트 루프)	❌ 아직 없음

다음 핵심 한 가지는 명확하다 — agent.service에 Tool Use 루프를 구현하는 것. 그 한 단계로 등록된 도구들이 자연어 인터페이스로 살아난다.

한 장 요약 — 도구가 없으면 LLM은 말만 한다. Agentic Loop(선택→실행→재추론)가 행동의 심장이며, 의도 기반이라 미리 안 짠 시나리오에도 대응한다. 안전장치(호출 상한·보상)는 필수다.

10장. MCP — AI 시대의 RPC, 도구를 빌려주는 표준

핵심 질문: “AI를 내 소스코드 어디에 박아 넣지?”

이 그림이 틀렸다. 맞는 그림은 ERP는 어제 만든 모습 그대로 존재하고, AI는 별도 프로세스로 바깥에 있으며, 둘은 API로 대화하는 것이다. 신입사원이 ERP 코드를 모른 채 화면만 쓰듯, AI는 사용법(API 명세)만 알면 된다. 인간은 GUI로, AI는 도구(MCP)로 같은 ERP를 쓴다.

MCP는 그 ‘도구 빌려주기’를 표준화한 규격이다. 차이는 단 하나 — **docstring(사용설명서)**이다. AI는 코드를 못 읽고 docstring을 읽는다.

MCP는 새 개념이 아니다 — RPC 30년사

수십 년 IT 경력이 여기서 황금 자산이 된다. MCP는 AI 시대를 위한 새 RPC 표준일 뿐이다.

경험	본질
VB ActiveX	같은 머신 함수 호출
DCOM / CORBA	다른 머신·이기종 함수 호출
SOAP/WSDL	XML 기반 RPC
REST API	HTTP 기반 호출
MCP	AI ↔ 도구 표준

DCOM 시절 IDL을, SOAP 시절 WSDL을 작성하던 노하우가 그대로 docstring 작성 노하우가 된다. 실패의 80%는 도구 명세 부정확에서 온다.

워크드 예시 — 좋은 명세와 4단계 결합

나쁜 명세 def get_data(id): """데이터 가져오기""" → AI: ‘id가 뭐지?’ → 에러 → 무한 재시도. 좋은 명세는 형식·예시·오류를 명시한다.

@mcp.tool()
def 직원조회(employee_id: str) -> dict:
    """직원 ID로 직원 정보를 조회한다.
    Args:
        employee_id: 직원 고유 ID. 형식 'EMP'+3자리(예: EMP001).
                     잘못된 예: 'emp001','EMP-001','E001'
    Returns:
        존재 시 {"name": str, "department": str, ...}
        없으면 {"error": "EMPLOYEE_NOT_FOUND"}
    """
    return get_employee(employee_id)

이 docstring은 30년간 작성하던 함수 명세서 그 자체다. ERP 함수를 AI에 결합하는 4단계: (1) 함수를 REST API로 노출 → (2) API를 MCP 도구로 래핑(@mcp.tool()+docstring) → (3) 에이전트에 MCP 서버 등록(config 한 줄) → (4) 자연어로 부린다. 기존 코드는 한 줄도 안 바뀌고, 새 파일 1개가 추가된다(둘 다 사실). 첫 1개월은 무조건 ERP와 같은 머신(STDIO)에 두라 — 처음부터 분산 시스템을 만들면 디버깅 지옥이다.

한 장 요약 — AI를 코드에 넣는 게 아니라 ERP가 AI에게 도구를 빌려준다. MCP는 RPC의 새 버전이며 핵심은 docstring. 기존 코드는 불변, 새 파일 1개만 추가된다.

11장. Multi-Agent와 Orchestration — 수십 개를 조직처럼 묶는 법

핵심 질문: “기술연구소장·HW·SW·인증 에이전트… 30~50개도 모자랄 수 있다. 한 시스템이 이걸 감당하나?”

단일 인스턴스에 모든 업무를 맡기면 네 가지가 무너진다. (1) 컨텍스트 폭발 — 컨텍스트 윈도우는 프로세스당이라 50명 대화·기억이 한 곳에 들어가면 터진다. (2) 스킬 폭발 — 부서당 30개만 잡아도 50×30=1,500개라 검색 정확도가 무너진다. (3) 권한 격리 불가 — 영업 에이전트가 BMS 도면에 접근하면 안 된다. (4) 장애 전파 — 한 에이전트의 무한 루프가 회사 전체를 멈춘다.

정답은 하나의 거대 두뇌가 아니라 분산형 정부 조직처럼 가는 3계층 하이브리드다.

계층	명칭	역할
Tier 0	CEO 에이전트(SELA)	사용자와 직접 대화, 전사 라우팅의 단일 진입점
Tier 1	부문 임원 에이전트 5~7명	R&D·생산·품질·영업·구매·경영·인증
Tier 2	실무 전문가 에이전트 30~50명	HW·SW·BMS·CAN·인증·EMC·구매·영업 단위 업무

제조+인증+고객+영업이 섞인 환경은 인증이 제멋대로 굴면 안 되므로 Conductor 우위 하이브리드(중앙집중·감사 + 부분 분산)가 정답이다.

워크드 예시 — “한 로봇 고객사 납품 일정이 위험하다”

Tier 0가 이 신호를 감지하면 라우팅한다 → 생산 에이전트(일정·재고 종합)와 구매 에이전트(셀 조달)에게 위임 → 두 에이전트의 결론이 충돌하면(생산은 ‘납기 지킴’, 구매는 ‘셀 부족’) Tier 0가 중재 → 조달 실패 시 보상 후 사람에게 에스컬레이션 → 영업 에이전트는 BMS 도면에 접근 불가(격리). 이 네 가지가 오케스트레이션 4대 메커니즘 — 라우팅·중재·실패복구·격리다.

주의 — 두 ‘에이전트 숫자’는 다른 층위: 운영 조직의 ‘30~50 에이전트’(회사를 운영하는 직원들)와 15장의 설계 파이프라인 ‘5-에이전트’(시스템을 설계하는 컨설턴트 팀)는 전혀 다른 것이다.

한 장 요약 — 한 대에 다 넣으면 컨텍스트·스킬·권한·장애로 실패한다. 3계층 Conductor 우위 하이브리드가 정답이며, 오케스트레이션은 라우팅·중재·실패복구·격리로 작동한다.

---

다음 → 〈Part 4. Agent ERP〉: 이제 에이전트(Part 3)와 ERP(Part 1)를 실제로 결합한다.