모의 ERP × AI Agent 실습 교재

Aurora Group 모의 ERP로 회계 프로세스를 직접 돌려 보고, 그 위에 AI Agent를 얹어 사람이 하던 판단을 자동화하는 과정을 실습한다.

🧩 쉽게 말하면 이 교재는 IT를 전공하지 않은 회계·재무 담당자를 기준으로 쓰였다. 전문 용어가 나오면 바로 뒤에 이런 회색 상자로 한 번 더 쉽게 풀어 둔다. 어려운 문단이 이해가 안 되면 이 상자만 먼저 읽고 넘어가도 실습에는 지장이 없다.

0. 무엇으로 실습하나 — 준비물

준비물은 둘뿐이다

설치·설정할 프로그램은 그 외에 없다. 파이썬도, 터미널도, 개발 도구도 쓰지 않는다. ERP를 Claude에 붙이는 일은 설정 화면에 주소 한 줄을 붙여넣는 것으로 끝난다(4-1).

🧩 쉽게 말하면 프린터를 새로 쓰는 것과 같다. 프린터 드라이버를 코딩하지 않는다 — “이 프린터를 쓰겠다”고 한 번 등록하면 그다음부터는 어느 문서에서든 인쇄가 된다. ERP를 Claude에 등록하는 것도 딱 그만큼의 일이다.

Claude 데스크톱 앱으로 한다 (기본)

이 교재의 4·5·6·7회차 실습은 전부 Claude 데스크톱 앱에서 진행한다. (claude.ai 웹으로 해도 절차와 화면이 같다.)

실습 중 나오는 실행 프롬프트는 전부 복사해서 대화창에 붙여넣으면 된다. 직접 타이핑하거나 명령어를 외울 일은 없다.

Claude Code(터미널)가 필요한 경우 — 셋뿐

정규 실습에는 필요 없다. 아래 세 경우에만 쓴다.

사내망 차단은 실제로 생길 수 있다 — 새로 등록된 도메인이라 보안 장비가 막는 경우가 있다(1-1). 이때 ERP 화면은 IP 주소로 들어가면 되지만, 커넥터는 그 방법이 통하지 않는다. Claude Code를 쓰면 IP 주소로도 등록된다.

claude mcp add --transport http erp http://133.186.244.191/s/stu07/482913/mcp

먼저 도메인으로 시도해 본다. 커넥터 등록이 “연결됨”으로 뜨면 그대로 진행하면 된다. 실패하는 사람만 강사에게 알리고 위 방법으로 바꾼다 — 교재의 실습 내용은 어느 쪽이든 같다.

1. 강의실 입장

1-1. 접속 주소

두 가지 주소가 있다. 둘 다 같은 서버이고 데이터도 같다.

사내망에서 도메인이 막히는 경우 — 새로 등록된 도메인(newly-registered-domain)으로 분류돼 보안 장비가 차단할 수 있다. 이때는 IP 주소로 들어온다. IP는 평문 HTTP라 브라우저 주소창에 “안전하지 않음”이 뜨는데, 실습 데이터에는 개인정보가 없으므로 그대로 진행한다. Chrome이 막히면 Edge로 접속하면 대개 열린다.

1-2. 좌석 선택 (PIN 로그인)

1. /enter 화면에서 본인 좌석 번호(stu01 ~ stu40)를 고른다.
2. 강사가 나눠 준 6자리 PIN을 입력한다.
3. 좌석마다 독립된 데이터베이스를 쓴다 — 옆 사람이 무엇을 하든 내 데이터는 영향받지 않고, 내가 무엇을 망가뜨려도 나만 다시 시작하면 된다.

좌석 stu07 → data/erp_stu07.db   (나만의 ERP 한 벌)

🧩 쉽게 말하면 .db 는 데이터가 담긴 파일 하나다. 엑셀 파일 하나에 시트가 여러 장 있는 것처럼, 이 파일 하나 안에 전표·거래처·재고 표가 전부 들어 있다. 좌석마다 파일이 따로이므로 각자 자기 엑셀 파일을 한 벌씩 받아 든 셈이다. 옆 사람이 자기 파일을 지워도 내 파일은 멀쩡하다.

막히면 초기화한다. 강사에게 요청하면 좌석을 시드 상태로 되돌려 준다. 실습 중 잘못된 전표를 잔뜩 만들었어도 문제없다 — 되돌리고 다시 하면 된다.

1-3. 좌석 PIN 하나면 된다 — 좌석 토큰은 언제 쓰나

정리부터. 대부분의 수강생은 좌석 PIN 6자리만 있으면 된다.

좌석 토큰은 MCP 도구 이름이 아니다. 32자리 문자열이고, 성격은 비밀번호에 가깝다. 프로그램이 “나는 stu07 좌석 사람이다”를 증명할 때 쓴다.

🧩 쉽게 말하면 건물에 들어가는 방법이 둘이라고 생각하면 된다. 커넥터는 출입증을 미리 등록해 둔 자동문 이다 — 주소 안에 PIN이 들어 있어 그냥 열린다. 내 PC에서 파일을 직접 실행하는 것은 뒷문으로 들어가는 것 이라, 경비원에게 “나 여기 사람이에요” 하고 신분증(좌석 토큰) 을 보여 줘야 한다. 4~7회차 실습은 전부 자동문(커넥터)으로 가므로 신분증은 안 꺼내도 된다.

커넥터로 등록하면 좌석 토큰은 필요 없다. 커넥터 주소에 이미 PIN이 들어 있어서 그것으로 신원이 확인되기 때문이다. 4~7회차 실습은 전부 커넥터만으로 된다.

$env:ERP_API_BASE  = "https://edu-erp.co.kr/api"
$env:ERP_TENANT    = "stu07"
$env:ERP_SEAT_TOKEN = "<좌석 토큰>"
python ai_agent_mcp.py

2. 전체 캔버스 읽기

첫 화면 프로세스맵 → 🗺 전체 캔버스는 이 회사의 업무 전체 지도다. 박스 하나가 Cycle(업무 사이클), 박스를 잇는 선이 데이터 흐름이다.

🧩 쉽게 말하면 지하철 노선도라고 보면 된다. 큰 박스가 호선, 그 안의 작은 박스가 역 이다. 선은 “이 역 다음은 저 역”이라는 순서를 뜻한다. 실제로 이 노선도가 곧 규칙이어서, 선이 없으면 그 길로는 못 간다.

1행   판매 O2C                          구매 P2P
2행   경비 T&E      결산·세무 HUB        급여 HR
3행   출장경비                           지출결의

2-1. Cycle 7개가 각각 무엇인가

왜 지출결의가 따로 있나 — 구매 P2P는 “발주가 있는 매입”만 다룬다. 사무실 임차료·통신비· 회계감사 수수료처럼 발주서를 쓰지 않는 비용은 지출결의서가 원천이 된다. 구매 P2P의 매입전표 화면에서 안 보이는 계산서들이 바로 지출결의의 몫이다.

왜 출장경비가 따로 있나 — 카드 3건(호텔·KTX·식대)이 사실은 하나의 출장일 때, 건별로 경비전표를 3장 끊는 것보다 출장 한 건으로 묶어 전표 한 장을 만드는 게 맞다. 묶인 카드는 개별 경비전표 대상에서 빠지고, 결제는 다시 카드대금 결제로 합류한다.

2-2. Cycle 안으로 들어가기

박스를 클릭하면 그 Cycle의 내부 프로세스맵이 열린다. 여기서 박스 하나가 단위모듈 (= 실제 화면 하나)이다. 박스에 붙은 숫자 배지는 그 단계에서 처리를 기다리는 건수다.

• 단위모듈을 클릭 → 그 단계의 실행 화면으로 이동
• 상단 탭도 Cycle과 1:1이다 — 프로세스맵에서 본 순서 그대로 탭 안에 서브탭으로 있다
• 상단 탭을 누르면 항상 맨 왼쪽 서브탭(🗺 프로세스맵)이 열린다. 그 Cycle의 전체 그림을 먼저 보고 단계로 들어가라는 뜻이다

🧩 쉽게 말하면 단위모듈 = 실제로 일하는 화면 한 개다. “수주 등록 화면”, “출하 처리 화면” 하나하나가 캔버스에서는 박스 하나로 그려져 있을 뿐이다. 박스에 붙은 숫자는 결재판에 쌓인 서류 장수 라고 보면 된다 — 처리하면 줄어든다.

2-3. 관리자 모드 — 캔버스 편집

우측 상단 [🔓 관리자 모드]를 누르고 캔버스 편집 관리자 키를 입력하면 프로세스 설계를 바꿀 수 있다.

캔버스 편집 관리자 키: aurora-canvas-2026

교실 콘솔(좌석 재시드·PIN 명부) 키와는 다른 키다. 이 키로는 내 좌석의 프로세스 설계만 바꿀 수 있고, 다른 좌석이나 교실 전체는 건드릴 수 없다.

관리자 모드에서 할 수 있는 일:

🧩 쉽게 말하면 단계를 새로 만들 때 고르는 내부 / 외부는 이런 뜻이다. 내부 애플리케이션 = 사람이 앉을 자리 — ERP 안에 입력 화면과 표가 새로 생긴다. 외부 애플리케이션 = AI·로봇이 앉을 자리 — 화면 대신 주고받을 데이터 약속이 생긴다. “이 일은 사람이 하나, 기계가 하나”를 정하는 것이지 기술을 고르는 게 아니다.

＋ 를 눌렀을 때의 규칙 (중요)

단계 사이에 새 단계를 넣으면, 앞 단계의 처리 결과는 새로 생긴 단계로 먼저 간다. 종전의 다음 단계로 바로 넘어가지 않는다.

넣기 전:  지출결의서 작성 ──────────────▶ 매입계산서 매칭
넣은 후:  지출결의서 작성 ─▶ [지출결의 승인] ─▶ 매입계산서 매칭
                              ↑ 확정한 건은 여기서 대기. 승인해야 다음으로.

반려하면 앞 단계로 되돌아간다. 반려는 “진행하지 말라”는 뜻이므로 앞 단계 담당자가 다시 손볼 수 있어야 한다. 되돌린 건은 앞 단계의 대기 목록에 다시 나타난다.

🧩 쉽게 말하면 게이트 = 결재선에 사람 하나 끼워 넣기 다. 원래 “작성 → 다음 부서”였던 흐름에 팀장 결재를 넣으면, 작성한 서류는 다음 부서로 바로 가지 않고 팀장 책상에서 멈춘다. 팀장이 반려하면 서류는 작성자 책상으로 되돌아온다 — 시스템도 똑같이 동작한다는 뜻이다.

게이트 설치 시점의 원칙

게이트를 설치해도 이미 그 단계를 지나간 건은 소급 심사하지 않는다(자동승인으로 기록). 설치 후 새로 올라오는 건부터 심사한다. AI Agent도 같다 — 설치 직후 대기 0건에서 시작하고, 앞 단계가 처리해서 넘겨준 건부터 Agent의 일이 된다.

한 가지 예외 — 은행 입출금. 통장 거래는 앞 단계가 만들어 넘겨주는 것이 아니라 밖에서 들어오는 원천이다. 그래서 수금 대사·지급기표 자리는 만들자마자 일감이 있다.

그래서 설치 직후에는 실행 화면에 두 종류가 섞여 보인다. 실행 목록의 심사 열이 이를 구분한다.

“게이트를 달았는데 승인 없이 실행된다” 싶으면 심사 열의 자동승인 을 확인한다. 통제가 안 걸린 게 아니라 설치 전 건이다. 새로 확정한 건으로 시험해야 통제가 보인다.

3. RCM을 보고 통제를 심기

3-1. RCM 읽기

실습 Lab → 📕 통제기술서(RCM) 에 통제 8건이 있다. 각 행은 이렇게 읽는다.

🧩 쉽게 말하면 RCM(Risk Control Matrix) 은 “이 회사가 어디서 사고가 날 수 있고, 그걸 막으려고 무슨 절차를 두었는가” 를 한 줄씩 적어 둔 표다. 회계감사에서 늘 요구하는 그 문서다. 통제란 거창한 게 아니라 “전표는 만든 사람 말고 다른 사람이 승인한다” 같은 규칙 한 줄이다.

모집단 API — 무엇을 돌려주나

population_api 는 “이 통제가 제대로 돌아갔는지 확인하려면 어느 자료를 다 꺼내 봐야 하는가” 다. 통제 8건이 각각 어느 테이블의 무엇을 주는지 정리하면 이렇다. (건수는 시드 직후 기준)

읽는 법 세 가지

1. 굵은 글씨가 속성 테스트의 근거다. 예를 들어 FR01-P01-R01-01 의 속성 “작성자≠승인자” 는 같은 행의 created_by 와 approved_by 를 비교하면 판정된다.
2. 모집단이 0건이면 “통제가 잘 돌아간다”는 뜻이 아니다. 예외 탐지형 통제(journal-exceptions)는 시드 상태에서 0건이지만, 실습으로 전표를 만들다 보면 늘어난다. 먼저 실습을 돌린 뒤 테스트해야 의미가 있다.
3. 한 API가 여러 통제의 모집단일 수 있다. /api/ic/users 는 퇴사자 통제와 SoD 통제가 함께 쓴다 — 같은 자료를 다른 관점으로 보는 것이다.

🧩 쉽게 말하면 모집단은 “검사 대상 전부” 다. 전표 승인 통제를 확인하려면 승인된 전표 전부가 검사 대상이고, 그중 일부를 뽑아 보는 것이 표본이다. API는 그 목록을 꺼내 주는 창구 번호 라고 생각하면 된다 — 위 표의 /api/... 가 창구 이름이다. /api/journal?status=승인 은 “전표 창구에서 상태가 ‘승인’인 것만 주세요”라는 뜻이다.

이번 실습에서 다룰 통제

FR01-P01-R01-01 (핵심통제)

모든 수동전표는 작성자와 다른 권한보유자가 검토·승인한 후 전기된다.

• 모집단: /api/journal?status=승인 → 승인된 전표 전부
• 속성: 작성자≠승인자 · 승인자 권한보유 · 승인일자 기표일 이후

SL01-P01-R01-01 (핵심통제)

출하 전 거래처 여신한도와 미수잔액을 확인하고 승인한다.

• 모집단: /api/scm/sales-orders → 수주 전부
• 속성: 출하 전 승인 존재 · 한도 내 여부

3-2. 통제를 단위모듈로 심어 보기

RCM에 적힌 통제가 ERP에 실제로 구현돼 있는가를 확인하고, 없으면 심는다.

실습 A — FR01-P01-R01-01: 전표 승인 게이트

지금 상태에서는 전표를 만들면 곧바로 ‘미결’로 남고, 승인 절차가 프로세스에 그려져 있지 않다. 통제를 눈에 보이게 만든다.

1. 관리자 모드를 켠다 (키: aurora-canvas-2026)
2. 판매 O2C → 🗺 프로세스맵 으로 간다
3. 매출전표 발행 박스의 ＋ 를 누른다
4. 제안 목록에서 [매출전표 승인] 게이트를 고른다
5. 승인권자를 지정한다 — 예: 이부장(재무)
6. 설치되면 캔버스에 게이트 박스가 생기고, 상단 서브탭에도 나타난다

확인할 것

• 매출전표를 새로 발행하면 → 게이트의 심사 대기로 간다
• 승인하지 않은 채 다음 단계로 가려 하면 → 409 차단
• 반려하면 → 전표가 삭제되고 계산서가 ‘전표 발행 전’으로 돌아간다
• 지정한 승인권자가 아닌 사람이 심사하려 하면 → 403
• 설치 전에 이미 있던 미결 전표는 → 소급 심사 대상 (전표 승인 게이트만 예외적으로 소급)

실습 B — SL01-P01-R01-01: 여신 확인 게이트

1. 판매 O2C → 🗺 프로세스맵 에서 수주 등록 박스의 ＋
2. [여신 확인] 게이트를 고른다 → 승인권자 지정
3. 게이트 화면을 열면 각 수주에 여신한도 · 기사용액 · 초과여부가 함께 표시된다

⚠️ 먼저 알아 둘 것 — 설치 시 “기존 3건 자동승인” 메시지

시드에는 이미 확정된 수주 3건(SO-26071·26072·26075)이 있다. 게이트는 이미 그 단계를 지나간 건을 소급 심사하지 않으므로, 설치할 때 이 3건을 자동승인한다. 그래서 출하 처리 화면에 가면 4건 중 3건은 승인 없이도 출하된다 — 고장이 아니다.

통제를 확인하려면 반드시 ‘새로 확정한 건’으로 시험한다. 출하 처리 목록의 심사 열을 보면 구분된다 — 승인 / 자동승인 (설치 전 기존 건) 과 심사 대기 가 행마다 표시되고, 심사 대기 건은 [출하] 버튼 대신 “여신 확인 필요” 가 뜬다.

확인할 것 (순서대로)

1. 수주 등록에서 미확정 수주 하나(예: SO-26073)를 확정한다 → 화면이 “다음 단계: 여신 확인 (승인 후 출하)“라고 알려 준다
2. 출하 처리로 간다 → 그 건의 심사 열이 심사 대기, 실행 칸은 “여신 확인 필요” (버튼이 아예 없다 — 눌러서 409를 보기 전에 막힌다)
3. 여신 확인 게이트 화면에서 그 건을 승인한다 → 출하 처리로 돌아오면 심사 = 승인, [출하] 버튼이 살아난다
4. 다른 건을 반려해 본다 → 수주가 ‘수주’(미확정)로 돌아가 영업이 다시 검토
5. 한도를 초과한 거래처는 게이트 화면에서 빨갛게 표시된다

🧩 쉽게 말하면 결재선에 팀장을 새로 넣어도 어제까지 이미 결재가 끝나 넘어간 서류를 다시 불러 결재받게 하지는 않는다. 오늘부터 올라오는 서류에만 적용된다. 자동승인 3건이 바로 그 ‘어제까지의 서류’다.

직접 해보기 — 게이트를 설치했다가 삭제해 보라. 통제가 사라지면 출하가 다시 바로 된다. 프로세스맵의 선이 곧 실행 규칙이라는 걸 몸으로 확인하는 지점이다.

4. MCP로 통제 테스트 Agent 만들기

통제가 설계대로 운영되고 있는지를 확인하는 것이 통제 테스트다. 전 통제를 다 할 수는 없으므로 핵심통제 2건을 골라 모집단 추출 → 표본 선정 → 속성 테스트를 한다.

4-0. 그 전에 — MCP가 뭔가

Claude는 기본적으로 대화만 한다. 우리 회사 ERP에 무엇이 들어 있는지는 모른다. “7월 전표 뽑아줘”라고 해도 볼 수가 없으니 답할 수 없다.

MCP(Model Context Protocol) 는 그 사이를 잇는 규격이다. 쉽게 말해 “AI가 외부 프로그램에 말을 거는 공용 어댑터 규격” 이다.

[Claude]  ←─ MCP ─→  [우리 ERP]
                     [사내 위키]
                     [파일 서버] ...

왜 규격이 필요한가 — ERP마다, 시스템마다 접속 방법이 제각각이면 AI 쪽에서 전부 따로 배워야 한다. 콘센트 규격을 통일해 두면 어떤 가전이든 꽂히듯, MCP 규격만 맞추면 어떤 AI든 붙는다. 우리가 만든 ERP도 이 규격에 맞춰 준비돼 있다.

MCP로 붙으면 Claude가 쓸 수 있는 것이 도구(tool) 형태로 열린다. 우리 ERP는 85개를 연다.

Claude는 대화 내용에 맞는 도구를 알아서 골라 쓴다. 우리가 도구 이름을 외울 필요는 없고, “7월 승인 전표 뽑아서 작성자와 승인자가 같은 게 있는지 봐줘” 처럼 말하면 된다.

🧩 쉽게 말하면 여기서 도구(tool) 는 프로그램이 아니라 “AI가 누를 수 있는 버튼” 이다. ERP 화면의 [조회] [저장] 버튼을 AI도 누를 수 있게 목록으로 만들어 준 것이고, 그 목록이 85개라는 뜻이다. 우리는 버튼 이름을 외울 필요 없이 한국어로 시키면 Claude가 알아서 누른다.

한 줄 요약 — MCP는 “AI에게 우리 ERP를 쓸 손을 달아 주는 규격” 이다.

4-1. 커넥터 등록 — ERP를 Claude에 붙이기

커넥터란

커넥터(Connector) 는 Claude 화면에서 MCP 연결을 등록해 두는 자리다. 한 번 등록하면 새 대화를 열 때마다 그 시스템이 계속 붙어 있다.

• 설치할 프로그램이 없다 — 주소 하나를 등록하면 끝
• 등록은 Claude 설정 화면에서 한다 (파일 편집 없음)
• 등록한 커넥터는 내 계정에 저장되어 PC를 바꿔도 따라온다

내 커넥터 주소 만들기

https://edu-erp.co.kr/s/{좌석}/{좌석 PIN}/mcp

{좌석}에 본인 좌석(stu07), {좌석 PIN}에 로그인할 때 쓰는 6자리 PIN을 넣는다. 좌석 stu07, PIN 482913 이라면 —

https://edu-erp.co.kr/s/stu07/482913/mcp

🧩 쉽게 말하면 이 주소는 내 좌석 전용 출입문 주소다. /s/stu07/ 이 “7번 좌석 데이터로 들어가겠다”, 482913 이 “내가 맞다는 증명”, 끝의 /mcp 가 “사람이 보는 화면이 아니라 AI가 붙는 문” 이라는 표시다. 그래서 이 주소는 비밀번호가 적힌 쪽지 나 마찬가지다 — 남에게 보이면 안 된다.

등록 절차 (Claude 데스크톱 앱 · claude.ai 공통)

1. 좌우측 하단의 설정(Settings) 을 연다
2. 커넥터(Connectors) 메뉴로 간다
3. [사용자 지정 커넥터 추가](Add custom connector) 를 누른다
4. 이름: ERP 실습 처럼 알아볼 이름
5. URL: 위에서 만든 내 주소를 붙여넣는다
6. [추가] → 목록에 뜨면 연결됨인지 확인한다

새 대화를 열고 이렇게 물어 확인한다.

ERP에 연결됐는지 확인해줘. 회사 목록을 보여줘.

오로라홀딩스 / 코레비아코스메틱 / 마실커머스 3개가 나오면 성공이다.

연결이 안 될 때

• HTTPS 주소여야 한다. http://133.186.244.191/... (IP·평문)로는 커넥터가 붙지 않는다. 사내망에서 도메인이 막히면 커넥터 실습은 개인 노트북/휴대폰 테더링으로 한다.
• PIN을 빠뜨렸거나 틀리면 401로 막힌다. 좌석 번호만으로는 연결되지 않는다.
• PIN을 10회 틀리면 그 IP가 10분간 차단된다. 강사에게 PIN을 다시 확인한다.

⚠️ 커넥터 주소에는 내 PIN이 들어 있다. 주소를 남에게 보여 주면 그 사람이 내 좌석에 붙을 수 있고, 웹 로그인도 된다. 화면 공유·채팅에 붙여넣지 않는다. 노출됐다면 강사에게 PIN 재발급을 요청하면 즉시 무효가 된다.

커넥터 vs .mcp.json — 무엇이 다른가

MCP를 붙이는 방법은 크게 둘이다. 둘 다 같은 MCP 규격이고, 붙고 나면 Claude가 쓰는 도구도 똑같다. 다른 것은 “어디에 등록하고, 서버를 누가 돌리느냐” 다.

핵심 차이 하나만 기억한다면 — 커넥터는 url 만 적고 남이 돌리는 서버에 접속하는 것, .mcp.json 은 command 를 적어 내 PC에서 프로그램을 띄우는 것이다.

// 커넥터와 같은 원격 접속 (url)
{ "mcpServers": { "erp": {
    "type": "http",
    "url": "https://edu-erp.co.kr/s/stu07/482913/mcp" } } }
 
// 내 PC에서 프로그램을 실행 (command) — 5회차에서 만든 Agent 파일을 돌릴 때
{ "mcpServers": { "ai_agent": {
    "command": "python",
    "args": ["C:/실습/ai_agent_mcp.py"],
    "env": { "ERP_API_BASE": "https://edu-erp.co.kr/api",
             "ERP_TENANT": "stu07",
             "ERP_SEAT_TOKEN": "<좌석 토큰>" } } } }

아래쪽에만 좌석 토큰이 나오는 이유가 여기 있다 — 내 PC에서 뜬 프로그램은 주소에 PIN이 없으니, 따로 신원을 증명해야 하기 때문이다(1-3 참고).

🧩 쉽게 말하면 커넥터는 넷플릭스 계정에 로그인해 두는 것 과 같다. 한 번 등록하면 어느 기기에서 새 대화를 열어도 붙어 있다. .mcp.json 은 내 컴퓨터에 프로그램을 설치해 두고 그때그때 실행하는 것 이다. 파일 안에 url 이 있으면 “남의 서버에 접속”, command 가 있으면 “내 PC에서 프로그램 실행”이다. JSON은 그냥 컴퓨터가 읽는 메모 형식이고, 중괄호와 따옴표를 지키면 된다. 이 수업은 전부 커넥터로 하므로 이 파일은 안 만들어도 된다.

Claude Code(CLI)를 쓴다면

터미널에서 한 줄로 등록한다. 위 .mcp.json 의 url 방식을 명령어로 하는 것과 같다.

claude mcp add --transport http erp https://edu-erp.co.kr/s/stu07/482913/mcp

연결되면 도구 85개를 쓸 수 있다. 통제 테스트에 쓰는 것들만 추리면 —

4-2. 실행 프롬프트 — 통제 테스트 Agent

Claude에 그대로 붙여넣는다.

너는 내부회계관리제도 통제 테스트를 수행하는 감사인이다. ERP MCP 도구를 사용해라.

대상 통제: FR01-P01-R01-01 (수동전표 작성자·승인자 분리)

1. erp_get_control 로 통제 내용과 test_attr(속성)을 확인해라.
2. erp_get_control_population 으로 모집단을 가져와 **모집단 규모**를 보고해라.
3. 모집단에서 표본 25건을 뽑아라. 금액이 큰 건이 통제 실패 시 영향이 크므로
   amount 방식과 random 방식을 각각 확인하고, 어떤 방식을 왜 골랐는지 밝혀라.
4. 표본마다 속성을 테스트해라:
   - 작성자(created_by)와 승인자(approved_by)가 다른가
   - 승인자가 '전표승인' 권한을 실제로 보유했는가 (erp_list_erp_users 로 대조)
   - 승인일자가 기표일 이후인가
5. 결과를 표로 보여라 — 표본번호 / 전표번호 / 금액 / 속성별 O·X / 예외 사유
6. **예외(deviation)** 건수와 예외율을 계산하고, 통제 결론(효과적/비효과적)을 내려라.
7. erp_create_control_workpaper 로 통제조서를 작성해라.
   조서에는 모집단 규모, 표본 추출 방법과 근거, 속성별 결과, 결론이 들어가야 한다.

주의: 근거 없이 '적정'이라고 하지 마라. 확인하지 못한 속성은 '확인 불가'로 남기고 이유를 써라.

🧩 쉽게 말하면 이 긴 문장이 곧 업무 지시서다. 신입에게 일 시킬 때 적어 주는 메모와 다르지 않다 — 무엇을 대상으로(모집단), 몇 건을 어떻게 뽑아(표본), 무엇을 확인하고(속성), 결과를 어떤 표로 보고할지(산출물) 를 순서대로 적었을 뿐이다. AI는 시킨 만큼만 한다. 위 지시에서 한 줄을 빼고 돌려 보면 결과가 그만큼 부실해진다. “프롬프트를 잘 쓴다”는 건 결국 일을 명확히 지시한다는 뜻이다.

4-3. 두 번째 통제 — SoD

대상 통제: SD01-P01-R01-01 (전표입력·전표승인·지급실행 겸직 금지)

1. erp_list_erp_users 로 전 사용자의 보유 역할을 가져와라.
2. 세 역할 중 2개 이상을 동시에 가진 사람을 찾아라 — 겸직 조합을 명시해라.
3. 겸직자가 실제로 **자기가 만든 전표를 자기가 승인**한 사례가 있는지
   erp_list_journal_entries 로 확인해라 (created_by == approved_by).
4. erp_get_role_grants 로 그 권한이 **승인을 거쳐 부여됐는지** 확인해라.
   approver 가 NONE 인 건은 승인 없는 부여 — 별도 예외로 보고해라.
5. 예외 목록과 재무제표 영향(어떤 계정이 얼마나 노출되는가)을 정리해라.

점검 — Agent가 내놓은 결과를 실습 Lab → 🚨 예외전표 탐지와 대조해 본다. 그 화면이 참고 답안이다. Agent가 놓친 게 있으면 프롬프트의 어느 부분이 부족했는지 되짚는다.

4-4. 도구는 어떻게 정해지는가 — 절차 → 데이터 → 도구

4-2·4-3에서는 도구가 이미 준비돼 있었다. erp_get_control_population 을 부르면 모집단이 나오고, erp_run_control_test 를 부르면 예외까지 나왔다.

현업에는 그런 도구가 없다. 우리 회사 ERP에 붙일 때는 내가 도구를 정해야 한다. 그 순서가 이 절의 주제다.

순서는 언제나 이 방향이다

① 무슨 일을 하려는가        (업무 절차)
        ↓
② 그러려면 무엇을 알아야 하나   (필요한 정보)
        ↓
③ 그 정보는 어디에 있나       (Data — 테이블·컬럼)
        ↓
④ 그걸 꺼내 주는 도구를 만든다  (MCP 서버)

🧩 쉽게 말하면 거꾸로 가면 반드시 실패한다. “우리 ERP에 뭐가 있더라 → 그걸로 뭘 해볼까”로 시작하면, 만들어 놓고 나서 정작 필요한 게 빠져 있는 도구가 나온다. 신입에게 일을 시킬 때와 같다 — “이 일을 하려면 무슨 자료가 필요하지?” 를 먼저 묻고, 그 자료를 찾아 주는 것이다. 자료 창고를 먼저 뒤지는 게 아니다.

해보기 — 4-2의 통제를 이 순서로 다시 짜 본다

① 업무 절차 — FR01-P01-R01-01: “수동전표는 작성자와 다른 권한보유자가 승인했는가”

② 그러려면 무엇을 알아야 하나 — 통제기술서의 test_attr 이 그대로 답이다.

③ 그 정보는 어디에 있나 — 여기서 Data를 정의한다.

여기서 이 실습의 가장 중요한 발견이 나온다 — 승인일시를 담을 칸이 아예 없다. 통제기술서는 증적으로 “승인자·승인일시”를 요구하는데 시스템이 그걸 남기지 않는다.

이건 실패가 아니라 결론이다. 감사에서는 “확인 불가 — 시스템에 승인일시가 보존되지 않음” 이라고 쓰고, 통제 설계의 미비로 지적한다. 없는 데이터를 있는 척 채우는 것이 최악이다.

④ 도구를 만든다 — ②·③에서 정한 것을 그대로 도구로 바꾼다.

🧩 쉽게 말하면 ②에서 적은 표의 한 줄이 도구 하나가 된다. 특별한 기술이 필요한 게 아니라, “무엇을 알아야 하는지” 를 제대로 적었으면 도구 목록은 거의 저절로 나온다.

그래서 도구는 뭘로, 어떻게 만드나

여기서 대부분 멈춘다. “도구를 만든다”가 곧 개발이라고 들리기 때문이다. 세 가지 길이 있고, 대부분은 1번이면 끝난다.

길 1 — 코드를 한 줄도 안 쓴다 (기본)

이 랩에서는 캔버스에서 자리를 만드는 것이 곧 도구를 만드는 것이다. 폼에 처리 대상과 참고 자료를 고르면, ERP가 그 계약대로 fetch_pending(자료 꺼내기)·submit_results(결과 받기)를 알아서 만들어 준다. 커넥터가 그 자리를 그대로 호출한다(4-5).

🧩 쉽게 말하면 엑셀 피벗테이블을 만드는 것과 같은 난이도다. 어떤 표를 쓸지, 어떤 열을 보여줄지 고르는 것이 전부다. “도구를 만들었다”는 말이 거창하게 들릴 뿐, 실제로 하는 일은 양식 채우기다.

길 2 — 파일을 받아서 실행만

Agent 화면 [B. 전용 MCP 서버] → [파일 저장] 을 누르면 ..._mcp.py 가 완성된 상태로 내려온다. 내가 폼에서 정한 표·컬럼이 이미 들어 있다. .mcp.json 에 등록하고 실행하면 끝이다(부록 D).

길 3 — 직접 작성한다 (우리 회사 ERP에 붙일 때)

현업에서 우리 회사 시스템에 붙일 때가 여기다. 필요한 것은 셋뿐이다.

함수 하나 = 도구 하나다. 아래가 실제로 도는 전체 코드다 — 이게 전부다.

import json, os, urllib.parse, urllib.request
from mcp.server.fastmcp import FastMCP
 
BASE   = os.getenv("ERP_API_BASE", "https://edu-erp.co.kr/api")
TENANT = os.getenv("ERP_TENANT", "stu07")
mcp = FastMCP("my-erp")
 
def _get(path, params=None):
    if params:                     # 한글 조건(status=승인)은 반드시 인코딩한다
        path += "?" + urllib.parse.urlencode(params)
    req = urllib.request.Request(BASE + path, headers={"X-ERP-Tenant": TENANT})
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.loads(r.read().decode() or "{}")
 
@mcp.tool()
def get_approved_journals() -> str:
    """승인된 전표 전부. 작성자(created_by)와 승인자(approved_by)가 들어 있다.
    통제테스트의 모집단으로 쓴다."""
    return json.dumps(_get("/journal", {"status": "승인"}), ensure_ascii=False, indent=1)
 
@mcp.tool()
def get_users() -> str:
    """ERP 사용자와 보유 권한(roles). 승인자가 '전표승인' 권한자인지 대조할 때 쓴다."""
    return json.dumps(_get("/ic/users"), ensure_ascii=False, indent=1)
 
if __name__ == "__main__":
    mcp.run()

이 파일을 my_erp_mcp.py 로 저장하고 .mcp.json 에 등록하면 Claude가 도구 2개를 쓸 수 있게 된다. 4-2의 통제테스트는 이 둘만으로도 절반이 된다. (실제로 이 코드를 돌리면 승인 전표 19건, 사용자 11건이 나온다.)

19건인데 왜 모집단은 16건인가 — 도구는 조건에 맞는 것을 그대로 준다. 19건에는 기초잔액 전표 3건이 섞여 있고, 그건 사람이 만든 전표가 아니라 이월 데이터라 이 통제의 대상이 아니다. 무엇을 빼야 하는지는 도구가 모른다 — 감사인이 판단한다. 그래서 조서에 모집단 정의를 반드시 적는 것이다.

읽는 법 — 딱 세 군데만 보면 된다.

🧩 쉽게 말하면 도구를 만든다는 건 “우리 회사 자료를 꺼내 오는 함수에 이름표를 붙이는 일” 이다. 새 시스템을 개발하는 게 아니라, 이미 있는 조회 기능에 AI가 부를 수 있는 손잡이를 다는 것이다. 그래서 30줄이면 되고, 어려운 부분은 코드가 아니라 ②·③(무엇을 꺼낼지 정하는 일) 이다.

한글 때문에 자주 나는 오류 — 위 코드의 urlencode 를 빼고 주소에 한글을 그대로 붙이면 UnicodeEncodeError: 'ascii' codec can't encode... 가 난다. 조건에 한글이 들어가면(status=승인) 반드시 인코딩한다.

설명문(docstring)이 코드보다 중요하다

함수 아래 설명문을 대충 쓰면 AI가 그 도구를 안 쓰거나 엉뚱할 때 쓴다. 사람에게 인수인계하듯 쓴다 — 무엇을 돌려주는지 · 언제 쓰는지 · 주의할 점.

직접 안 짜도 된다 — Claude에게 시킨다

②·③의 표를 그대로 붙여넣고 이렇게 부탁하면 된다.

아래 표의 정보를 꺼내 주는 MCP 서버를 파이썬으로 만들어 줘.
- 접속: https://our-erp.company.com/api  (헤더 X-API-KEY 필요)
- 도구 1: 승인 전표 목록 (created_by, approved_by, je_date, total 포함)
- 도구 2: 사용자·권한 목록 (roles, active)
읽기 전용으로만 만들고, 각 도구 설명문에 언제 쓰는지 적어 줘.

실제로 이 랩의 MCP 서버(도구 85개)도 이렇게 만들어졌다. 어려운 것은 코딩이 아니라 “무엇을 꺼내야 하는지”를 아는 것이고, 그건 현업만 안다.

회사에 붙이기 전 확인할 것

중요 — 판단까지 대신하는 도구는 만들지 않는다

erp_run_control_test 처럼 예외 판정까지 해 주는 도구는 편하지만 위험하다. 판정 규칙이 도구 안에 숨어 있어서, 그 도구가 놓친 것을 사람이 알아챌 수 없다.

실제로 4-2 실습에서 이 도구는 예외를 1건(자기승인)만 잡았다. 그런데 자료를 직접 보면 —

🧩 쉽게 말하면 계산기와 자동채점기의 차이다. 계산기(자료를 꺼내 주는 도구)는 내가 검산할 수 있지만, 자동채점기(판정까지 하는 도구)는 틀려도 틀린 줄 모른다. 그래서 도구는 자료까지, 판단은 사람과 AI가 — 이게 원칙이다.

이 원칙은 5·6·7회차에도 그대로 이어진다

Agent 자리를 만들 때 고르는 처리 대상과 참고 자료가 정확히 ②·③이다.

같은 사고방식이다. 통제 테스트에서 “승인일시가 없어 확인 불가”였던 것처럼, Agent도 주지 않은 정보로는 판단하지 못한다. “AI가 못 한다”가 아니라 “내가 필요한 자료를 정의하지 못했다” 인 경우가 대부분이다.

4-5. 커넥터와 단위모듈이 만나는 지점

5회차부터는 프로세스맵에 AI Agent의 자리(단위모듈) 를 만든다. 그 자리는 업무 지시서다 — 무엇을 처리할지, 무엇을 참고할지, 어떤 형식으로 돌려줄지가 적혀 있다.

지시서를 만들었으면 누군가 읽어 와야 한다. 그 통로가 커넥터다. 커넥터에는 자리(모듈)를 다루는 도구 3개가 들어 있다.

즉 이렇게 이어진다.

[ERP 캔버스]  Agent 자리를 만든다 (지시서)
      │  module_id
      ▼
[커넥터]  erp_agent_fetch_pending(module_id)  →  일감 + 참고 자료
      ▼
[Claude]  판단한다
      ▼
[커넥터]  erp_agent_submit_results(module_id, 결과)
      ▼
[ERP 캔버스]  전표 생성 · 대기 배지 감소 · 작성자 ext:<슬러그> 로 이력

전용 MCP 서버를 따로 만들지 않아도 된다. 4회차에 등록한 커넥터 하나로 5·6·7회차의 모든 Agent 자리를 돌릴 수 있다. (전용 서버는 “이 Agent에게 도구를 3개만 준다”는 최소권한 설계를 보여 주기 위한 선택지로 남겨 둔다 — 부록 D.)

🧩 쉽게 말하면 단위모듈(Agent 자리) = 조직도에 자리를 하나 만드는 일 이다. “수금 대사 담당” 자리를 만들고 책상 위에 업무 분장표를 올려 둔 셈이다 — 무슨 서류를 처리하고, 무슨 자료를 참고하고, 어떤 양식으로 보고하라 가 적혀 있다. 커넥터는 그 책상까지 가는 복도다. AI는 복도를 지나 자리에 앉아 분장표를 읽고 일한다. module_id 는 그 자리 번호(좌석 번호) 다 — “3번 자리 일감 주세요”라고 부를 때 쓴다.

자리에는 표가 여러 개 붙는다 — 처리 대상과 참고 자료

Agent 자리를 만들 때 데이터를 두 종류로 나눠 지정한다. 이게 계약의 핵심이다.

왜 나누는가 — 대사·매칭·검토는 한 표만 봐서는 답이 안 나오기 때문이다.

입금 5건만 던져 주면 Agent는 “이 돈이 어느 매출의 회수인지” 알 길이 없다. 참고 자료로 미수 매출계산서를 같이 주면 그때부터 판단이 가능해진다.

🧩 쉽게 말하면 직원에게 일을 시킬 때 처리할 서류철과 옆에 놓고 볼 장부는 다르다. 처리할 서류철(처리 대상)은 다 하면 “처리 완료” 도장 이 찍히지만, 옆에 놓고 본 장부(참고 자료)에는 아무 표시도 남지 않는다. 통장 입금 내역만 주고 “정리해”라고 하면 아무도 못 한다 — 미수금 명세서를 같이 줘야 “아, 이 돈은 A사 3월 매출 회수구나”가 나온다. 그게 참고 자료다.

4-6. Agent 자리 만들기 — 폼 채우는 법

5·6·7회차는 여기서 만든 자리를 쓴다. 자리가 없으면 커넥터가 부를 module_id 자체가 없다. 그러니 실습 순서는 늘 이렇다 — ① 프로세스맵에서 자리를 만든다 → ② 커넥터로 그 자리를 시킨다.

1단계. 어디서 시작하나

1. 우측 상단 [🔓 관리자 모드] → 키 aurora-canvas-2026
2. 해당 Cycle 탭 → 🗺 프로세스맵 으로 간다 (예: 판매 O2C)
3. Agent에게 일을 넘겨줄 앞 단계 박스 위에 마우스를 올리면 사방에 ＋ 가 나타난다
4. ＋ 를 누르고 [To (다음 단계)] 를 고른다
5. 목록의 준비된 조합에서 [AI ○○ Agent] 를 고른다 → 정의 폼이 열린다

왜 앞 단계의 ＋ 인가 — Agent는 앞 단계가 처리해서 넘겨준 건을 받는다. 카드내역을 수집하는 단계 뒤에 붙여야 “수집된 카드”가 Agent에게 흘러간다. 엉뚱한 박스에 붙이면 연결선이 그쪽으로 그려져 일감이 오지 않는다.

2단계. 폼의 칸을 채운다

준비된 조합에서 열면 모듈명 · 원천 · 회신 형식 · 참고 자료가 이미 채워져 있다. 아래 표는 무엇을 왜 그렇게 두는지 이해하기 위한 것이다. 대부분 그대로 두고 [생성]을 누르면 된다.

[생성] 을 누르면 캔버스에 박스가 생기고 연결선이 자동으로 그려진다.

회신 형식 4가지 — 무엇을 고르나

🧩 쉽게 말하면 “일을 끝내고 무엇을 제출하느냐” 를 고르는 칸이다. 분개를 제출하면 장부에 전표가 꽂히고, 의견을 제출하면 검토 결과가 목록에 쌓이고, 짝을 제출하면 서류 두 장이 클립으로 묶인다. 검토 Agent를 ‘전표’로 만들면 지적사항을 넣을 데가 없어 회신이 거부된다.

⚠️ 수금 대사를 ‘전표’로 만들면 안 된다 — 가장 많이 하는 실수

전표를 만들면 통장 입금만 처리완료가 되고 매출채권은 그대로 남는다. 화면에서 보면 수금전표는 생겼는데 수금 대기 목록이 그대로인 이상한 상태가 된다.

채권을 없애는 일(= 대사)은 어느 입금이 어느 계산서의 회수인지 짝짓는 것이고, 부분 반제·선수금까지 한 묶음이다. 그래서 회신 형식이 따로 있다. 전표는 대사 결과로 ERP가 만든다 — Agent가 분개를 짤 일이 아니다.

데이터 항목 채우는 법 (회신 형식이 ‘데이터 적재’일 때만)

전표 · 계산서 매칭 · 수금 대사를 고르면 이 칸은 아예 안 보인다. 데이터 적재를 골랐을 때만 나타난다 — Agent가 돌려줄 결과를 담을 표를 직접 만드는 것이다.

기본으로 빈 줄 한 개가 있다. [+ 항목 추가] 로 줄을 늘리고, 오른쪽 ✕ 로 지운다. 한 줄이 열 하나다.

칸별로 무엇을 넣나

🧩 쉽게 말하면 엑셀 시트를 새로 만들면서 1행 머리글을 정하는 일이다. 다만 머리글이 두 벌 필요하다 — 사람이 읽을 한글(표시명)과, AI가 값을 넣을 때 쓸 영문 열쇠(컬럼명). 이름표는 한글로 붙이고, 서랍 손잡이는 영문으로 다는 셈이다.

유형 4가지

je_no(전표번호)를 숫자가 아니라 문자로 두는 이유 — JE-10 처럼 문자가 섞이고, 번호는 더하거나 평균 낼 값이 아니기 때문이다. 계산할 값만 숫자·금액으로 둔다.

필수는 어디에 체크하나 — 판단의 결론에만

필수를 체크해 두면, Agent가 그 값을 빠뜨렸을 때 ERP가 그 줄만 보류하고 이유를 알려 준다.

AI 경비전표 검토 Agent: 0건 반영, 1건 보류
  보류 사유: 필수 항목 누락: 판정

이것이 ‘계약’이다. 사람이 화면에서 입력할 때든 Agent가 회신할 때든 같은 규칙으로 검증된다. 전표는 차대 일치를, 계산서 매칭은 공급처·금액 일치를 ERP가 확인하듯, 데이터 적재는 필수 항목을 확인한다.

Agent는 이렇게 회신하게 된다

컬럼명을 je_no·verdict·reason 으로 정했으니, 회신 JSON도 그 이름을 쓴다.

[{"values": {"je_no": "JE-21", "verdict": "지적",
             "reason": "롯데호텔 거래처 동반 식사 — 811 복리후생비가 아니라 813 접대비"}},
 {"values": {"je_no": "JE-22", "verdict": "적정"}}]

컬럼명을 바꾸면 회신 형식도 따라 바뀐다. verdict 대신 result 로 지었다면 Agent도 result 로 보내야 한다 — [A. 커넥터로 시키기] 탭의 프롬프트에 그 이름이 들어 있으니 복사해서 쓰면 어긋날 일이 없다.

정의하지 않은 이름은 버려진다. Agent가 comment 를 보내도 그런 열이 없으면 조용히 사라진다. 결과에 있어야 할 값이 안 보이면 컬럼을 안 만든 것은 아닌지 먼저 본다.

3단계. 만든 뒤 반드시 확인할 것 세 가지

캔버스에서 새로 생긴 박스를 클릭하면 Agent 화면이 열린다.

시드 직후 참고 자료 건수 — 이 숫자가 나오면 제대로 만든 것이다.

evidence_posted(증빙이 첨부된 전표)가 0건인 것은 정상이다 — 아직 증빙을 붙인 전표가 없기 때문이고, 7장에서 전표를 만들면 늘어난다. 같이 붙은 card_tx 로 대조가 된다.

대개 대기 0건이 정상이다. 자리를 만들기 전부터 쌓여 있던 건은 Agent 몫이 아니다. 앞 단계를 몇 건 처리해 넘겨주면 그때 숫자가 올라간다.

예외 — 은행 입출금은 처음부터 일감이 있다. 통장 입금은 앞 단계가 만들어 넘겨주는 것이 아니라 밖(은행)에서 들어오는 원천이다. 그래서 수금 대사 자리는 만들자마자 13건이 대기로 잡힌다. 이건 정상이다.

흔한 실수

지우고 다시 만들어도 된다. 관리자 모드에서 박스를 클릭해 삭제하면 연결선이 자동으로 다시 이어진다. 자리를 만들고 지우는 일은 되돌릴 수 있는 작업이니 겁내지 않아도 된다.

4-7. 이 수업에서 만들 Agent 자리

5·6·7회차에서 쓸 자리다. 각 장에서 그때그때 만들어도 되고, 여기서 한 번에 만들어 둬도 된다.

규칙성이 보인다 — 만드는 Agent(경비 분류·증빙 전표작성)는 참고 자료가 없고, 대사·검토·매칭 Agent는 반드시 있다. 혼자 판단할 수 있는 일인지, 상대를 봐야 하는 일인지가 갈리는 지점이다. ERP도 이 규칙을 알고 있어서 원천을 고르면 참고 자료가 알아서 붙거나 비어 있다 — 추천된 그대로 두면 된다.

🧩 쉽게 말하면 표의 6줄이 곧 채용 공고 6건이다. 어느 부서(Cycle) 어느 자리 옆에 앉히고, 무슨 서류를 맡기고, 무슨 자료를 참고하게 하고, 무엇을 제출받을지 를 정한 것이다. 사람을 뽑을 때와 다르지 않다 — 다만 5분이면 자리를 만들고 없앨 수 있다는 점만 다르다.

주의 — 참고 자료는 바뀌지 않는다. Agent가 참고 자료를 처리했다고 회신해도 ERP는 처리 대상(rows)에 대해서만 상태를 바꾼다. “무엇이 내 일인가”가 계약으로 못 박혀 있는 것이다.

5. 판매 O2C 전 구간 + AI 수금 대사 Agent

5-1. 수주 등록부터 수금전표까지

판매 O2C 탭에서 서브탭 순서대로 진행한다. 각 단계는 앞 단계가 끝나야 실행된다.

시작 상태 — 수주 등록 대기 3건(미확정), 출하 처리 대기 3건(확정), 매출전표 발행 대기 6건(외부 고객 계산서). 프로세스맵 박스의 숫자 배지로 확인한다.

담당자가 다르다. 우측 상단에서 사용자를 바꿔 가며 해 본다. 수주·계산서는 박영업, 출하는 노물류, 전표·수금은 이재무다. 담당이 아닌 사람으로 실행하면 403이 나고, 누가 담당인지 알려 준다. 이게 직무분리다.

🧩 쉽게 말하면 403 은 “권한 없음”이라는 뜻의 웹 오류번호다(404는 “그런 페이지 없음”). 화면이 고장 난 게 아니라 일부러 막은 것이다. 주문받는 사람과 돈 받는 사람을 갈라 두는 게 직무분리 — 한 사람이 다 하면 가짜 매출을 만들고 돈을 빼도 아무도 모르기 때문이다.

5-2. 수금 처리 — n:n 대사

[💰 수금 처리] 를 누르면 창이 뜬다.

왼쪽: 수금 안 된 매출전표 전부        오른쪽: 미처리 입금 + 선수금 잔액

ERP는 짝을 미리 골라 주지 않는다. 어느 입금이 어느 채권인지는 사람이 판단한다. 양쪽에서 골라 [수금 처리]를 누르면 아래 세 가지 중 하나가 된다.

🧩 쉽게 말하면 대사(對査) 는 “이 돈이 어느 청구서에 대한 입금인지 짝을 맞추는 일” 이다. n:n 은 짝이 1:1이 아닐 수 있다는 뜻 — 청구서 3장을 한 번에 입금하기도 하고, 한 청구서를 두 번에 나눠 보내기도 한다. 부분 반제는 “일부만 갚음”(잔액이 남아 다시 청구 대상), 선수금은 “미리 더 받음”(다음 청구에 쓸 돈)이다.

꼭 해볼 것 세 가지

1. 1:n 매칭 — 마실커머스 계산서 3건(#24·#26·#28)을 골라 놓고, 오른쪽에서 “마실커머스(주) 7월 1~3차 통합 결제” 입금 한 건을 고른다. 합계가 딱 맞는다(1,633,632,000원). 거래처가 여러 건을 한 번에 결제한 경우다.
2. 부분 반제 — 큰 계산서 하나에 작은 입금 하나를 붙인다. 잔액이 새 전표번호로 생기는 것을 확인한다.
3. 선수금 — 채권보다 큰 입금을 붙인다. 남은 돈이 선수금으로 잡히고, 다음 수금에서 그 선수금을 골라 쓸 수 있다.

거래처가 달라도 대사할 수 있다. 은행 적요에 적힌 이름은 참고일 뿐 실제 거래처를 확정하지 않는다(모회사 대납·계열사 통합결제·예금주 상이). ERP가 막지 않는 이유이고, 그래서 사람의 판단이 필요한 자리다 — 즉 Agent를 붙일 자리다.

5-3. AI 수금 대사 Agent 만들기

실습 순서 — ① 프로세스맵에서 자리를 만든다(4-6) → ② 커넥터로 그 자리를 시킨다. 자리를 먼저 만들어야 커넥터가 부를 module_id 가 생긴다. 아래 방식 ①은 자리 없이 바로 시켜 보는 비교용이다 — 감을 잡는 데 먼저 해 보고, 방식 ②에서 자리를 만들어 같은 일을 시켜 본다.

Agent를 붙이는 길은 두 가지다. 둘 다 커넥터로 실행하지만 배우는 것이 다르다. 5~7회차는 두 방식을 모두 해 보고 차이를 몸으로 느끼는 것이 목표다.

①이 쉽고 ②가 어렵다는 뜻이 아니다. ①은 “사람이 하던 판단을 AI에게 시킨다”, ②는 “AI를 조직의 한 자리에 앉힌다” — 목적이 다르다. ①로 감을 잡고 ②로 옮겨 보면 차이가 분명해진다. 커넥터는 둘 다에 쓴다. ②에서 달라지는 것은 커넥터로 무엇을 호출하느냐뿐이다.

🧩 쉽게 말하면 ①은 아르바이트에게 그때그때 시키는 것이다 — “오늘 이 입금 좀 정리해 줘”. 시킬 때마다 무엇을 보고 무엇을 하라고 매번 설명해야 하고, 끝나면 기록도 흩어진다. ②는 정규직 자리를 하나 만드는 것이다 — 업무 분장표를 써 붙여 두면, 다음에는 “3번 자리 일 해줘” 한마디로 끝나고 처리 이력이 회사 장부에 남는다. 어느 쪽이든 드나드는 문(커넥터)은 같다.

방식 ① 커넥터로 하기

커넥터에는 수금 대사에 필요한 도구가 이미 들어 있다.

erp_create_journal_entry 로 대신하면 안 된다. 전표를 만들면 통장 입금은 처리완료가 되지만 매출채권이 남아 수금 대기 목록이 줄지 않는다. 대사는 erp_collect_match 여야 한다.

erp_collect_sales_order 도 쓰면 안 된다 — 이 도구는 수주 기준으로 입금 거래를 새로 만든다. 이미 통장에 들어온 돈과 별개로 가짜 입금이 하나 더 생긴다.

Claude가 “그 도구가 없다” 고 하면 도구가 없는 게 아니라 커넥터의 도구 목록이 낡은 것이다 — 부록 A를 본다.

Claude에 그대로 붙여넣는다.

너는 ERP의 수금 담당자다. 커넥터로 연결된 ERP 도구를 사용해라.

1. erp_get_collect_workspace 로 회사 2000 의 미수 매출전표와 미처리 입금을 가져와라.
2. 어느 입금이 어느 채권의 회수인지 **적요와 금액**을 근거로 짝지어라.
   - 거래처명이 적요에 있으면 참고하되, 적요의 이름이 실제 거래처를 확정하지는 않는다
     (모회사 대납·계열사 통합결제·예금주 상이가 있다)
   - 한 입금이 여러 계산서를 한 번에 결제한 경우(합계가 맞는 조합)를 반드시 찾아라
3. 짝지은 근거를 표로 보여줘라 — 계산서번호 / 거래처 / 미수액 / 입금번호 / 입금액 / 판단 근거
4. 내가 승인하면 erp_collect_match 로 대사해라. 여러 건이면 쉼표로 넘긴다.
5. 결과를 보고해라. 부분 반제로 **새 전표번호**가 생겼거나 **선수금**이 남았으면 그 금액을 알려라.

주의: 확신이 없는 건은 대사하지 말고 "판단 보류"로 남겨 이유를 설명해라.

꼭 확인할 것 — 마실커머스 계산서 3건(#24·#26·#28)의 합계가 통합 입금 1건과 정확히 맞는다. Agent가 이 1:n 조합을 찾아내는지가 이 실습의 핵심이다.

🧩 쉽게 말하면 AI가 잘하는 일이 바로 이런 조합 찾기다. 입금 1건에 맞는 계산서 조합을 사람이 손으로 찾으면 한참 걸리지만, AI는 금액을 더해 보며 금방 짚어 낸다. 반대로 “이 이름이 정말 그 거래처인가” 같은 건 AI가 자신 있게 틀린다 — 그래서 프롬프트에 “확신이 없으면 보류하고 이유를 말해라” 를 넣어 둔 것이다.

방식 ② 단위모듈로 Agent 자리 만들기

프로세스맵에 Agent의 자리를 만들어 두는 방식이다. 캔버스에 박스가 생기고, 대기 건수가 배지로 뜨며, Agent가 만든 전표가 별도 이력으로 쌓인다.

방식 ①과 달리 무엇을 처리할지·무엇을 참고할지를 ERP에 못 박아 둔다. Agent는 매번 “어느 표를 봐야 하지”를 고민하지 않는다 — 자리가 알려 준다.

자리 만들기 (폼 채우는 법은 4-6)

1. 관리자 모드 ON (키: aurora-canvas-2026)
2. 판매 O2C → 🗺 프로세스맵 에서 수금 처리 박스의 ＋ → [To (다음 단계)]
3. 준비된 조합에서 [AI 수금 대사 Agent] 선택 → 폼이 열린다

[생성] 후 새 박스를 클릭해 확인한다 — ① 처리 대상 13건, ② 참고 자료 11건, [A. 커넥터로 시키기] 탭에 module_id.

왜 ‘전표’가 아니라 ‘수금 대사’인가 — 전표로 만들면 통장 입금만 처리완료가 되고 매출채권은 그대로 남는다. 수금 대기 목록이 줄지 않는 것이다. 대사로 만들면 사람이 [수금 처리] 를 누른 것과 똑같이 채권이 소멸되고, 모자라면 부분 반제(잔액이 새 전표번호), 남으면 선수금까지 ERP가 처리한다.

참고 자료를 빼고도 한 번 만들어 보라. [삭제] 를 눌러 지운 뒤, 참고 자료 줄의 [삭제]를 누르고 만들면 Agent가 입금만 받고 “어느 채권의 회수인지 알 수 없다” 고 답한다. 붙였다 뗐다 해 보는 것이 이 실습의 핵심이다.

여기는 대기 0건이 아니다. 통장 입금은 앞 단계의 산출물이 아니라 밖에서 들어오는 원천이라, 만들자마자 13건이 잡힌다(4-6의 예외). 바로 실습할 수 있다.

커넥터로 그 자리를 실행하기 (기본)

Agent 화면의 [A. 커넥터로 시키기] 탭에서 module_id 와 실행 프롬프트를 복사한다. 새로 설치할 것은 없다 — 4회차 커넥터가 그대로 이 자리를 집어 든다.

ERP 수금 대사 Agent 실습을 시작한다.

1. erp_list_agent_modules 로 내 좌석의 Agent 자리를 확인해라. 이번 대상은 module_id "<복사한 ID>"다.
2. erp_agent_fetch_pending("<복사한 ID>") 로 처리 대상(rows)과 참고 자료(refs)를 가져와라.
   - rows = 미처리 은행 입금 (이번에 처리할 일감)
   - refs["ar_open"] = 미수 매출계산서 (판단 근거, 조회 전용)
3. 어느 입금이 어느 채권의 회수인지 **적요와 금액**을 근거로 짝지어라.
   - 한 입금이 여러 계산서를 한 번에 결제한 경우(합계가 맞는 조합)를 반드시 찾아라
   - 적요의 이름이 실제 거래처를 확정하지는 않는다 (대납·통합결제·예금주 상이)
4. 근거를 표로 보여주고, 내가 승인하면
   erp_agent_submit_results("<복사한 ID>", "<결과 JSON 배열>") 로 회신해라.
5. accepted / rejected 를 보고해라. rejected 가 있으면 원인을 분석해라.

주의: 확신이 없는 건은 회신하지 말고 "판단 보류"로 남겨 이유를 설명해라.

확인할 것 — 회신에 성공하면 프로세스맵의 그 박스 대기 배지가 줄고, 전표 조회에 작성자 ext:ai_agent 로 뜬다.

🧩 쉽게 말하면 이 프롬프트는 세 문장으로 줄일 수 있다 — ① 3번 자리 일감 가져와 → ② 짝 맞춰서 나한테 먼저 보여줘 → ③ 내가 OK 하면 ERP에 올려. 중간에 내 승인을 끼워 넣은 것이 중요하다. AI가 판단은 하되 장부에 올리는 것은 사람이 확인한 뒤가 되게 한 것으로, 실무에서 AI를 쓸 때의 기본 안전장치다.

다른 실행 수단 (선택)

같은 자리를 다른 방법으로도 돌릴 수 있다. 계약(무엇을 주고 무엇을 받는지)은 똑같다.

부록 D에 전용 서버 실행 방법(좌석 토큰 포함)을 정리해 두었다.

검증

[▶ 시뮬레이션 실행] 버튼으로 Agent 없이도 동작을 미리 볼 수 있다. Agent가 회신한 전표는 Agent 실행 이력 패널에 쌓인다. 차대가 안 맞거나 이미 기표된 건은 서버가 거부한다 — rejected 사유를 읽고 프롬프트를 고친다.

두 방식을 다 해 본 뒤 — 무엇이 달랐나

직접 비교해 보라 — 같은 입금 건을 두 방식으로 처리한 뒤 결산·세무 → 전표 조회·승인을 열어 보면, 작성자가 mcp-agent 인 것과 ext:ai_agent 인 것이 나란히 보인다. 누가(무엇이) 만든 전표인지 장부에서 구분된다는 것이 감사 관점의 핵심이다.

🧩 쉽게 말하면 작성자 칸이 사람 이름이 아니라 ext:ai_agent 로 찍힌다는 것은, “이 전표는 AI가 만들었다”가 장부에 그대로 남는다는 뜻이다. 감사에서 “AI가 처리한 건은 몇 건이고 누가 승인했나”를 물으면 바로 답할 수 있어야 하는데, 그 근거가 이 한 칸이다.

정리하면 — ①은 판단을 시키는 실습, ②는 자리를 만드는 실습이다. 현업에 얹을 때도 순서가 같다: 먼저 자유 지시로 “AI가 이 일을 할 수 있나”를 확인하고, 되겠다 싶으면 단위모듈로 프로세스에 자리를 만들어 대기 건·참고 자료·권한·이력을 붙인다.

6. 경비 T&E · 출장경비 — 작성 Agent와 검토 Agent

6-1. 카드내역 일괄 수집

1. 경비 T&E → 1. 카드내역 수집
2. 실습에 쓸 ID 1·3·5·6 이 미처리(수집 대기)로 있는지 확인한다
3. [미처리 일괄수집] 을 누른다 → 미처리 카드가 전부 수집완료가 된다
4. 수집된 건만 경비전표 발행·출장 품의 대상이 된다

담당은 이재무·김경영 두 명이다. 한 단계에 담당자가 여럿일 수 있다.

6-2. 출장전표 만들기 — 카드 3건을 하나로

출장경비 → 1. 출장 품의 → [+ 출장 품의 작성]

1. 출장 목적·출장지·기간·출장자를 채운다
2. 아래 카드 목록에서 ID 3, 5, 6 을 체크한다 — 선택할 때마다 선택 건수와 합계가 뜬다
3. [출장 품의 등록]

출장경비 → 2. 출장전표 발행 → [출장전표 발행]

• 카드 목록 아래 소계(공급가액 / 부가세 / 합계)가 표시된다
• 계정은 직접 입력한다: 812 여비교통비 / 135 부가세대급금 / 대변 253 미지급금(CARD-01)
• [카드 내역대로 채우기] 를 쓰면 건별 라인이 깔린다. 단, 전부 812로 깔리므로 거래처 접대성 지출은 813 접대비로 직접 바꿔야 한다
• 차변합계가 출장 합계와 같아야 저장된다 — 하단에 차대 일치 / 금액 일치 배지로 확인

🧩 쉽게 말하면 차변·대변은 회계의 양쪽 칸이다. “무엇이 늘었나(차변) / 그 돈은 어디서 났나(대변)“를 같은 금액으로 양쪽에 적는 규칙이라, 합계가 다르면 저장이 안 된다. 화면 아래 배지는 “양쪽 합이 맞습니다” 를 알려 주는 신호등이라고 보면 된다.

발행하면 묶인 카드 3건이 모두 전표완료가 되고, 카드대금 결제로 이어진다.

승인 절차 얹기

관리자 모드에서 출장 품의 박스의 ＋ → [출장전표 승인] 게이트를 설치한다. 설치 후에는 품의를 올려도 승인 전에는 전표를 발행할 수 없고, 반려하면 품의가 취소되어 묶였던 카드가 다시 풀린다.

6-3. 개별 경비전표 — ID 1

출장에 묶이지 않은 카드는 개별로 기표한다.

1. 경비 T&E → 2. 경비전표 발행
2. 카드 ID 1 의 [전표발행]
3. 계정·금액이 비어 있다 — 원천 내용(가맹점·업종·용도·금액·부가세)을 보고 직접 입력한다
   • 부가세가 있으면 공급가액과 135 부가세대급금을 분리
   • 대변은 253 미지급금 (CARD-01)
   • 거래처 동반 식사·골프·선물은 811 복리후생비가 아니라 813 접대비

🧩 쉽게 말하면 계정을 자동으로 제안하지 않는 것은 일부러 그렇게 만든 것이다. 같은 “식당 결제”라도 직원끼리 먹었으면 복리후생비, 거래처와 먹었으면 접대비다. 영수증만 봐서는 모르고 용도를 읽어야 갈린다 — 바로 이 판단이 뒤에서 AI에게 시킬 일이다. 사람이 먼저 해 봐야 AI가 뭘 틀리는지 보인다.

6-4. AI 경비 분류 Agent (작성)

5-3과 같이 두 방식 모두 해 본다. 방식 ②로 갈 것이므로 프로세스맵에서 자리부터 만들어 두면 편하다(아래 6-5 뒤의 ‘방식 ② 단위모듈로 만들기’ 참조).

방식 ① 커넥터로 하기

카드내역을 읽고 계정을 판단해 경비전표를 만드는 일이다.

너는 ERP의 경비 담당자다. 커넥터로 연결된 ERP 도구를 사용해라.

1. erp_list_source_transactions 로 회사 2000 의 **수집완료** 법인카드 내역을 가져와라.
2. erp_get_chart_of_accounts 의 계정과목과 keywords 를 근거로 각 건의 분개를 만들어라.
   - 접대성 지출(거래처 식사·골프·선물)은 811 복리후생비가 아니라 **813 접대비**로
   - 복리후생(회식·간식·야근식대)은 811, 출장·교통은 812, 소모품은 830
   - 부가세(vat)가 있는 건은 공급가액과 135 부가세대급금을 분리
   - 대변은 253 미지급금 (거래처 CARD-01)
3. 가맹점·업종·용도 중 **무엇을 근거로 그 계정을 골랐는지** 표에 함께 적어라.
4. 내가 승인하면 erp_create_journal_entry 로 건별로 만들어라.
   반드시 source_type="card" 와 source_id 를 넘겨라 — 중복 기표를 ERP가 막아 준다.
5. 결과를 보고해라. 거부된 건이 있으면 사유를 분석해라.

확인할 것 — 롯데호텔(거래처 접대 식사)을 813으로 골랐는가, 아니면 숙박이라고 812로 갔는가. 근거를 물어보면 Agent가 무엇을 보고 판단했는지 드러난다.

6-5. AI 경비전표 검토 Agent (승인 검토)

작성 Agent가 만든 전표를 승인 전에 검토하는 Agent다. 작성과 검토를 다른 대화(다른 Agent) 가 맡는 것이 요점이다 — 사람의 세계에서 작성자와 승인자를 나누는 것과 같은 이유다.

새 대화를 열고 (작성 Agent와 섞이지 않게) 커넥터로 그대로 한다.

너는 경비전표를 승인 전에 검토하는 감사인이다. 커넥터로 연결된 ERP 도구를 사용해라.
작성은 다른 사람이 했다 — 너는 **틀린 곳을 찾는 역할**이다.

1. erp_list_journal_entries 로 회사 2000 의 미결 전표를 가져오고,
   source_type 이 card 인 것만 골라라.
2. 각 전표를 erp_get_journal_entry 로 열고, erp_list_source_transactions 로 원천
   카드내역을 가져와 대조해라.
3. 다음을 지적해라:
   - 가맹점·용도가 접대성(거래처 동반)인데 811 복리후생비로 잡힌 건 → 813 접대비
   - 부가세가 있는데 135 부가세대급금을 분리하지 않은 건, 없는데 잡은 건
   - 대변이 253 미지급금(CARD-01)이 아닌 건
   - 금액이 원천과 다른 건
4. 전표번호 / 판정(적정·지적) / 사유 / **근거가 된 원천 문구** 를 표로 보여라.
5. 지적이 없으면 "지적 없음"이라고 분명히 말해라. 억지로 만들지 마라.

실습의 포인트 — 작성 Agent에 일부러 “전부 811로 분류해라” 같은 잘못된 프롬프트를 주고, 검토 Agent가 그걸 잡아내는지 확인해 본다. Agent를 Agent가 검증하는 구조를 체험하는 것이다.

🧩 쉽게 말하면 AI 하나에게 “만들고 네가 검토도 해”라고 하면 자기가 쓴 답을 자기가 채점하는 셈이라 잘 못 잡는다. 그래서 새 대화를 열어 다른 AI에게 검토를 시킨다 — 사람 조직에서 작성자와 결재자를 나누는 것과 정확히 같은 이유다. 여기서 ‘대화를 새로 연다’는 것이 곧 ‘다른 담당자를 앉힌다’는 뜻이다.

승인 게이트([경비전표 승인])를 함께 설치하면 작성 Agent → 검토 Agent → 사람 승인 3단 구조가 된다.

방식 ② 단위모듈로 만들기

자리를 두 개 만든다. 폼 채우는 법은 4-6에 있다.

자리 ① 작성 — 경비 T&E → 🗺 프로세스맵 → 카드내역 수집 박스의 ＋ → [To] → [AI 경비 분류 Agent]

자리 ② 검토 — 경비전표 발행 박스의 ＋ → [To] → [AI 경비전표 검토 Agent]

usage_memo 를 빼면 안 되는 이유 — 카드 원본에서 접대성 여부를 알려 주는 유일한 칸이다. 이 칸이 없으면 Agent는 가맹점 이름만 보고 찍는다. 6-4에서 롯데호텔을 813으로 골랐던 그 판단이 바로 이 컬럼에서 나온다.

작성 Agent와 검토 Agent의 차이가 여기서 드러난다.

검토는 전표와 원본을 나란히 놓아야 성립한다. 참고 자료를 붙이지 않고 만들면 Agent가 전표 헤더만 받고 “분개 내용을 알 수 없다”고 답한다 — 한 번 그렇게 만들어 보면 이유가 분명해진다.

대기 0건에서 시작하므로, 만든 뒤에 카드내역을 수집해야 Agent 몫이 생긴다.

실행 프롬프트 — 자리 ① 경비 분류 (작성)

Agent 화면 [A. 커넥터로 시키기] 탭에서 module_id 를 복사해 아래 <자리①ID> 자리에 넣는다. 새 대화를 열고 붙여넣는다.

ERP 경비 분류 Agent 실습을 시작한다.

1. erp_list_agent_modules 로 내 좌석의 Agent 자리를 확인해라. 이번 대상은 module_id "<자리①ID>"다.
2. erp_agent_fetch_pending("<자리①ID>") 로 처리 대상을 가져와라.
   rows = 수집완료된 법인카드 사용내역 (이번에 기표할 일감)
   이 자리는 참고 자료가 없다 — 카드내역만 보고 판단한다.
3. erp_get_chart_of_accounts 의 계정과목과 keywords 를 근거로 각 건의 분개를 만들어라.
   - 접대성 지출(거래처 식사·골프·선물)은 811 복리후생비가 아니라 813 접대비로
   - 복리후생(회식·간식·야근식대)은 811, 출장·교통은 812, 소모품은 830
   - 부가세(vat)가 있는 건은 공급가액과 135 부가세대급금을 분리
   - 대변은 253 미지급금 (거래처 CARD-01)
4. 가맹점·업종·용도(usage_memo) 중 **무엇을 근거로 그 계정을 골랐는지** 표에 함께 적어라.
5. 내가 승인하면 erp_agent_submit_results("<자리①ID>", "<결과 JSON 배열>") 로 회신해라.
6. accepted / rejected 를 보고해라. rejected 가 있으면 원인을 분석해라.

회신 형식:
[{"source_id":ID,"description":"적요","lines":[
  {"account_code":"813","debit":300000,"credit":0},
  {"account_code":"135","debit":30000,"credit":0},
  {"account_code":"253","debit":0,"credit":330000}]}]

주의: 차변합계 = 대변합계여야 한다. 확신이 없는 건은 회신하지 말고 이유를 설명해라.

확인할 것 — 회신에 성공하면 프로세스맵의 그 박스 대기 배지가 줄고, 전표 조회에 작성자 ext:ai_agent 로 뜬다. 롯데호텔 건을 813으로 골랐는지 본다.

실행 프롬프트 — 자리 ② 경비전표 검토

반드시 새 대화에서 실행한다. 작성 Agent와 같은 대화에서 하면 자기가 만든 것을 자기가 검토하게 되어 검토의 의미가 없다.

ERP 경비전표 검토 Agent 실습을 시작한다. 작성은 다른 Agent가 했다 —
너는 승인 전에 **틀린 곳을 찾는 역할**이다.

1. erp_agent_fetch_pending("<자리②ID>") 로 처리 대상과 참고 자료를 가져와라.
   rows = 미결 경비전표 (검토 대상)
   refs["evidence_posted"] = 증빙이 첨부된 전표 (금액·공급자 대조용)
   refs["card_tx"]         = 법인카드 사용내역 원본 (가맹점·용도 대조용)
2. 각 전표를 원천 카드내역과 대조해 다음을 지적해라.
   - 금액·부가세가 전표와 원본이 다른 건
   - 가맹점·용도가 접대성(거래처 동반)인데 811 복리후생비로 잡힌 건 → 813 접대비
   - 부가세가 있는데 135 부가세대급금을 분리하지 않은 건, 없는데 잡은 건
   - 대변이 253 미지급금(CARD-01)이 아닌 건
   - 작성자와 승인자가 같아질 수 있는 건(자기승인 위험)
3. 전표번호 / 판정(적정·지적) / 사유 / **근거가 된 원천 문구** 를 표로 보여라.
4. 내가 승인하면 erp_agent_submit_results("<자리②ID>", "<결과 JSON 배열>") 로 회신해라.
5. accepted / rejected 를 보고해라.

회신 형식 (데이터 적재 — 폼에서 정한 컬럼명 그대로):
[{"values":{"je_no":"JE-21","verdict":"지적","reason":"롯데호텔 거래처 동반 식사 — 813 접대비"}},
 {"values":{"je_no":"JE-22","verdict":"적정"}}]

주의: je_no 와 verdict 는 **필수**다 — 빠뜨리면 그 줄이 보류된다.
지적이 없으면 "적정"이라고 분명히 적어라. 억지로 지적을 만들지 마라.

확인할 것 — 회신 결과는 전표가 아니라 이 자리의 표에 쌓인다. 캔버스에서 그 박스를 클릭하면 판정 목록이 보인다. 이게 커넥터 자유 지시와 가장 다른 점이다.

일부러 틀리게 해 보기 — 작성 Agent에 “전부 811로 분류해라” 라고 잘못된 프롬프트를 주고, 검토 Agent가 그걸 잡아내는지 확인한다. Agent를 Agent가 검증하는 구조를 체험하는 것이 목적이다.

꼭 해볼 것 — 작성은 방식 ①(자유 지시)로, 검토는 방식 ②(자리 만들기)로 해 본다. 검토 결과가 dyn 테이블에 쌓여 화면으로 조회되는 것이 방식 ①과 가장 다른 점이다.

🧩 쉽게 말하면 dyn 테이블은 어려운 말이 아니라, 그 자리를 만들 때 ERP가 자동으로 만들어 준 전용 장부(엑셀 시트 한 장) 다. 검토 Agent가 남긴 “전표번호 / 판정 / 사유”가 대화창에만 떠 있다 사라지지 않고 그 시트에 줄줄이 쌓여 나중에 조회된다. 방식 ①(자유 지시)은 대화가 끝나면 결과도 같이 사라진다 — 이 차이가 실무에서는 크다.

7. 일반전표 + AI 증빙 전표작성 Agent

7-1. 증빙함

결산·세무 → ✍️ 일반전표 생성 에 증빙함이 있다. 영수증 스캔이 6건 들어와 있다.

일반전표는 증빙을 붙여서 만든다. 증빙 번호를 클릭하면 별도 창으로 열리고, 전표 창과 동시에 띄워 놓고 금액을 보며 입력할 수 있다. 창은 제목 표시줄을 끌어 이동하고 우하단 모서리로 크기를 조절한다.

🧩 쉽게 말하면 증빙은 영수증·계산서처럼 “이 돈을 왜 썼는지 보여 주는 종이” 다. 전표만 있고 증빙이 없으면 감사에서 “근거를 대라”는 말이 나온다. 화면이 두 개의 창으로 뜨는 이유도 실무와 같다 — 왼쪽에 영수증 펼쳐 놓고 오른쪽에 분개를 치는 그 모습을 그대로 옮긴 것이다.

7-2. 손으로 한 번 만들어 보기

1. [📎 증빙 올리기] 로 새 증빙을 넣거나, 기존 증빙의 [전표 작성] 을 누른다
2. 증빙 창을 열어 두고 금액을 보며 분개를 입력한다 (금액칸은 천단위 콤마가 자동으로 붙는다)
3. 저장하면 그 증빙이 전표완료로 넘어간다

판단이 갈리는 건들이 일부러 섞여 있다.

7-3. AI 증빙 전표작성 Agent

증빙함을 읽고 계정을 판단해 일반전표를 만드는 일이다. 여기서도 두 방식 모두 해 본다. 방식 ②로 갈 자리는 7-4 뒤의 ‘방식 ② 단위모듈로 만들기’에서 만든다.

방식 ① 커넥터로 하기

너는 ERP의 회계 담당자다. 커넥터로 연결된 ERP 도구를 사용해라.

1. erp_list_evidence 로 회사 2000 의 미처리 증빙을 가져와라.
2. 각 건을 erp_get_evidence 로 열어 **ocr_text(판독 텍스트) 전문**을 읽어라.
   목록의 요약만 보지 말고 반드시 본문을 확인해라.
3. 거래 성격을 파악하고 계정을 정해라.
   - 접대성(거래처 동반 식사·골프·선물)은 813 접대비, 임직원 회식·야근식대는 811 복리후생비
   - 광고·캠페인 대행료는 833 광고선전비, 사무용품·소모품은 830 소모품비
   - 취득가 100만원 이상 비품(노트북·기기)은 비용이 아니라 212 비품(자산)으로
   - vat>0 이면 135 부가세대급금을 분리하고, 면세 증빙(vat=0)은 분리하지 않는다
   - 대변은 결제수단에 따라 — 카드결제는 253 미지급금, 현금·계좌이체는 103 보통예금
4. 판단이 갈리는 건은 **증빙의 어느 문구를 근거로 삼았는지** 반드시 함께 보고해라.
5. 표로 보여주고, 내가 승인하면 erp_create_journal_entry 로 만들어라.
   **evidence_ids 에 그 증빙 번호를 반드시 넣어라** — 넣지 않으면 증빙이 전표에 붙지 않는다.

확인할 것 — 일부러 갈리게 만들어 둔 증빙 5건

틀렸다면 근거를 물어보라. “노트북을 왜 소모품으로 봤나” 하고 물으면 금액을 안 봤는지, 자산화 기준을 몰랐는지가 드러난다. 그 지점이 프롬프트를 고칠 자리다.

🧩 쉽게 말하면 OCR(판독 텍스트) 은 영수증 사진에서 글자만 뽑아 놓은 것 이다. 목록에는 “청담한우 / 340,000원”처럼 요약만 보이지만, 본문에는 “거래처 임원 3인 동반” 같은 결정적인 한 줄이 들어 있다. AI가 계정을 틀리는 대부분의 이유는 본문을 안 읽었기 때문이라, 프롬프트에 “목록만 보지 말고 본문을 읽어라” 를 넣은 것이다.

7-4. AI 증빙 검토 Agent

이미 기표된 전표와 증빙을 대조해 지적사항을 남긴다. 7-3과 다른 대화에서 한다.

너는 기표된 전표를 증빙과 대조해 검토하는 감사인이다. 커넥터로 연결된 ERP 도구를 사용해라.

1. erp_list_evidence 로 status="전표완료" 인 증빙을 가져와라 (전표에 붙은 것들).
2. 각 증빙의 je_id 로 erp_get_journal_entry 를 열어 분개를 확인해라.
3. 증빙(erp_get_evidence 의 ocr_text)과 전표를 대조해 다음을 본다:
   - 금액이 증빙 합계와 같은가
   - 공급자와 전표 거래처가 같은가
   - 일자가 같은 기간인가
   - 계정 분류가 증빙 내용에 맞는가 (접대성인데 811, 면세인데 135 등)
4. 전표번호 / 증빙번호 / 판정(적정·지적) / 사유 를 표로 보여라.
5. 지적이 없으면 "지적 없음"이라고 분명히 말해라.

방식 ② 단위모듈로 만들기

여기도 자리를 두 개 만든다. 둘 다 결산·세무 → 🗺 프로세스맵 에서 만든다.

자리 ① 작성 — 일반전표 생성 박스의 ＋ → [To] → [AI 증빙 전표작성 Agent]

자리 ② 검토 — 전표 승인 박스의 ＋ → [To] → [AI 증빙 검토 Agent]

실행 프롬프트 — 자리 ① 증빙 전표작성

ERP 증빙 전표작성 Agent 실습을 시작한다.

1. erp_list_agent_modules 로 내 좌석의 Agent 자리를 확인해라. 이번 대상은 module_id "<자리①ID>"다.
2. erp_agent_fetch_pending("<자리①ID>") 로 처리 대상을 가져와라.
   rows = 증빙함의 미처리 영수증·세금계산서·입금증
   **ocr_text(판독 텍스트)가 판단의 핵심 근거다.**
3. erp_get_chart_of_accounts 의 계정과목과 keywords 를 근거로 각 건의 분개를 만들어라.
   - ocr_text(판독 텍스트)를 읽어 거래 성격을 파악하고 계정을 정한다
   - 접대성(거래처 동반 식사·골프·선물)은 813 접대비, 임직원 회식·야근식대는 811 복리후생비
   - 광고·캠페인 대행료는 833 광고선전비, 사무용품·소모품은 830 소모품비
   - 취득가 100만원 이상 비품(노트북·기기)은 비용이 아니라 212 비품(자산)으로
   - vat>0 이면 135 부가세대급금을 분리하고, 면세 증빙(vat=0)은 분리하지 않는다
   - 대변은 결제수단에 따라 — 카드결제는 253 미지급금, 현금·계좌이체는 103 보통예금
   - 입금증은 차변 103 보통예금 / 대변 108 외상매출금 으로 회수 처리
   - 판단이 갈리는 건은 근거(증빙의 어느 문구를 봤는지)를 반드시 같이 보고한다
4. 건마다 **증빙의 어느 문구를 보고 그 계정을 골랐는지** 표에 함께 적어라.
5. 내가 승인하면 erp_agent_submit_results("<자리①ID>", "<결과 JSON 배열>") 로 회신해라.
6. accepted / rejected 를 보고해라.

회신 형식:
[{"source_id":ID,"description":"적요","lines":[
  {"account_code":"813","debit":300000,"credit":0},
  {"account_code":"253","debit":0,"credit":300000}]}]

주의: 차변합계 = 대변합계여야 한다. 판단이 갈리는 건은 근거를 반드시 밝혀라.

확인할 것 — 청담한우 건이 811인지 813인지. 근거를 물어보면 Agent가 ocr_text 의 어느 문장을 봤는지 답한다. 그 답이 이 실습의 핵심이다.

실행 프롬프트 — 자리 ② 증빙 검토

새 대화에서 실행한다.

ERP 증빙 검토 Agent 실습을 시작한다. 전표는 다른 Agent가 만들었다 —
너는 증빙과 전표가 맞는지 대조하는 역할이다.

1. erp_agent_fetch_pending("<자리②ID>") 로 처리 대상과 참고 자료를 가져와라.
   rows = 증빙이 첨부된 전표 (검토 대상)
   refs["card_tx"] = 법인카드 사용내역 원본 (필요하면 대조용)
2. 다음을 대조해 지적해라.
   - 증빙의 금액(amount)과 전표 차변합계가 같은가
   - 증빙의 공급자(vendor)와 전표 거래처가 같은가
   - 증빙 일자(doc_date)와 전표 일자가 같은 기간인가
   - 계정 분류가 증빙 내용과 맞는가 — 특히 접대비(813)를 복리후생비(811)로 처리한 건
   - 면세 증빙인데 135 부가세대급금을 잡았거나, 과세인데 누락한 건
3. 전표번호 / 증빙번호 / 판정(적정·지적) / 사유 를 표로 보여라.
4. 내가 승인하면 erp_agent_submit_results("<자리②ID>", "<결과 JSON 배열>") 로 회신해라.
5. accepted / rejected 를 보고해라.

회신 형식 (데이터 적재 — 폼에서 정한 컬럼명 그대로):
[{"values":{"je_no":"JE-31","verdict":"지적","reason":"면세 증빙인데 135 부가세대급금 계상"}},
 {"values":{"je_no":"JE-32","verdict":"적정"}}]

주의: je_no 와 verdict 는 **필수**다. 지적이 없으면 "적정"이라고 분명히 적어라.

evidence_posted 가 처음에는 0건일 수 있다 — 증빙을 붙인 전표가 아직 없기 때문이다. 자리 ①로 전표를 몇 건 만들고 나면 검토 대상이 생긴다. 작성 → 검토 순서로 해야 한다.

단위모듈 방식으로 만든 전표는 작성자가 ext:<슬러그> 로 남아 Agent 실행 이력에 쌓이고, 설치 후 새로 올린 증빙만 대상이 된다(대기 0건에서 시작).

이 장에서 꼭 해볼 실험 — 컬럼을 빼 보기

증빙 Agent를 만들 때 전달할 컬럼에서 ocr_text 체크를 빼고 만들어 본다. 그러면 fetch_pending 이 판독 텍스트를 주지 않는다. 같은 프롬프트로 돌려 보면 —

• Agent는 vendor(상호)와 amount(금액)만 보고 계정을 찍는다
• 청담한우를 811인지 813인지 구분하지 못한다 — 동반자가 적힌 문장을 못 봤으니까

Agent가 못 하는 게 아니라 계약이 정보를 안 준 것이다. 다시 체크하고 만들면 바로 맞춘다. 이 실험이 “계약 설계”가 무엇인지 가장 빠르게 알려 준다 — 자유 지시 방식에서는 겪을 수 없는 경험이다.

같은 실험을 참고 자료 쪽으로도 해 본다. 검토 Agent에서 참고 자료를 떼면 전표 헤더만 보고 “적정”이라고 답해 버린다 — 대조할 상대를 안 줬기 때문이다. 컬럼 하나, 표 하나가 판단 품질을 어떻게 바꾸는지가 이 장의 결론이다.

🧩 쉽게 말하면 계약(契約) 이라는 말이 어렵게 들리지만, 여기서는 “이 자리에 앉는 사람에게 무슨 서류를 주고 무슨 양식으로 받을지 정해 둔 것” 일 뿐이다. 신입에게 자료를 반만 주고 “왜 못 하냐”고 하면 안 되듯이, AI가 틀리면 먼저 내가 무엇을 안 줬는지 본다. 이 장의 실험이 그것을 보여 준다.

부록 A. 자주 막히는 곳

🧩 쉽게 말하면 숫자 오류코드 읽는 법 — 403 은 “당신 권한 아님”, 404 는 “그런 것 없음”, 409 는 “지금 순서가 아님”(앞 단계가 안 끝났다), 401 은 “누군지 확인 안 됨”(PIN 오류)이다. 대부분 고장이 아니라 규칙대로 막힌 것이니, 메시지를 읽고 앞 단계로 돌아가면 된다.

부록 B. 권한 신청·승인

관리자나 Super User가 아니면 권한을 직접 바꿀 수 없다. 대신 신청한다.

1. 실습 Lab → 🔐 사용자·권한 → [＋ 권한 신청]
2. 대상자·구분(역할 / 단계 담당)·요청(부여 / 회수)·사유를 적어 올린다
3. ‘권한관리’ 역할을 가진 사람이 승인하면 그때 실제 권한이 반영된다
4. 본인 신청을 본인이 승인할 수 없다 — 직무분리

승인되면 권한 부여·회수 이력에 구분(부여/회수)·승인자·신청 근거가 함께 남는다. 승인자가 없음인 행은 승인 절차 없이 부여된 건으로, ITGC 접근권한 통제의 예외다.

🧩 쉽게 말하면 ITGC 는 IT 일반통제 — “시스템 권한을 아무나 못 갖게 관리하고 있는가”를 보는 영역이다. 감사에서 늘 묻는 것이 “이 사람은 누가 승인해서 이 권한을 갖게 됐나” 인데, 승인자 칸이 비어 있으면 그게 바로 지적사항이다. 그래서 이 화면은 권한을 신청 → 승인 → 이력의 3단으로 남긴다.

부록 C. 관리자 키 두 가지

캔버스 편집 키로는 다른 좌석을 건드릴 수 없다. 마음껏 설계를 바꿔 보고, 망가지면 강사에게 재시드를 요청하면 된다.

🧩 쉽게 말하면 재시드(reseed) 는 “연습용 데이터를 처음 상태로 되돌린다” 는 뜻이다. 게임의 새로 시작하기와 같다. 내 좌석만 되돌아가고 남의 좌석은 그대로다. 그러니 망가뜨릴까 봐 조심하지 말고 마음껏 눌러 보는 것이 이 실습의 취지다.

부록 D. 전용 MCP 서버로 Agent 자리 돌리기 (선택)

커넥터 하나면 모든 Agent 자리를 돌릴 수 있다(4-5). 그럼에도 전용 서버를 만들어 보는 이유는 최소권한 설계를 눈으로 보기 위해서다 — 그 Agent에게 필요한 도구만 3~5개 열린다.

Agent 화면 [B. 전용 MCP 서버] 탭 → [파일 저장] 으로 파이썬 파일을 받는다. Builder가 그 자리의 입출력 정의로 코드를 자동 생성한다.

.mcp.json 에 등록하고 실행한다. 이때만 좌석 토큰이 필요하다(1-3 참고) — 내 PC에서 뜬 프로그램은 주소에 PIN이 없으니 따로 신원을 증명해야 한다.

{ "mcpServers": { "ai_collect": {
    "command": "python", "args": ["<경로>/ai_agent_mcp.py"],
    "env": { "ERP_API_BASE": "https://edu-erp.co.kr/api",
             "ERP_TENANT": "stu07",
             "ERP_SEAT_TOKEN": "<좌석 토큰>" } } } }

실행 프롬프트도 같은 화면에서 복사한다 — 그 Agent 종류에 맞는 회계 규칙이 들어 있다.

커넥터 방식과 비교 — 같은 자리를 두 방법으로 돌려 보면 결과는 똑같다. 다른 것은 Agent에게 열린 도구의 범위뿐이다. 실무에서 “이 Agent에게 ERP 전체를 열어 줄 것인가, 자기 일만 열어 줄 것인가”를 정하는 판단이 바로 이것이다.