[MCP] 4주차 Day 2 — ★ 쓰기는 업무 활동으로 보낸다

주차 주제: 읽기와 쓰기 | 제조 사례: 요청으로 바꾸고 사고가 사라진 자리

오늘의 목표: 쓰기를 요청으로 바꾸는 구조를 설계한다.

소요 시간: 30분


1. 한 문장으로

DB 에 직접 쓰지 말고
업무 흐름에 태우세요.                      ★

2. 무엇이 다른가

  직접 쓰기

   도구 → DB                                ★
   · 업무 규칙을 건너뜁니다                ★
   · 트리거·후처리를 안 탑니다              ★
   · 감사가 다른 자리에 남습니다           ★
   · 어느 시스템에 쓸지 애매합니다         ★
  요청

   도구 → 요청 건 생성 → 사람 → 정규 경로  ★
   · 규칙을 다 탑니다                      ★
   · 기존 화면을 씁니다
   · 감사가 원래 자리에 남습니다           ★

3. ★ 요청 도구의 모양

  품목수정요청(품번, 항목, 값, 사유)          ★
그리고 이게 하는 일
① 요청 건을 하나 만듭니다                 ★
② 담당(주인)에게 알립니다                 ★
③ 요청 번호를 돌려줍니다                  ★
돌려줄 것
  { "요청번호": "REQ-2026-0912-004",         ★
    "상태": "대기",                          ★
    "담당": "설계팀 김○○",                  ★
    "안내": "확인 후 반영됩니다.
            진행은 요청조회로 봅니다." }     ★
「담당」 을 알려 주는 게 좋습니다.             ★
· 사람이 언제 될지 압니다                 ★
· 급하면 직접 연락합니다                   ★

4. 요청에 꼭 넣을 것

□ 무엇을  대상·항목·값                     ★
□ 왜      사유 (필수)                     ★
□ 누가    사람 또는 Agent                 ★
□ 근거    무엇을 보고                     ★
□ 원래 값  바꾸는 것이면                   ★
「원래 값」 이 중요합니다.                    ★
· 확인하는 사람이 차이를 봅니다           ★
· 그리고 되돌릴 때 씁니다                  ★
「근거」 도 중요합니다.                       ★
  "발주서 #1204 3쪽 표 2행"                  ★
· 지어냈는지 바로 보입니다                ★

5. 이미 있는 요청 흐름을 쓰세요

새로 만들지 마세요.                          ★
대개 이미 있습니다.                       ★
· 마스터 등록 요청 (기준정보 11주차)       ★
· 설계 변경 요청
· 특채 신청                                ★
· 구매 요청                                ★
도구는 그 요청을 만들기만 하면 됩니다.    ★
그러면
· 승인 절차가 그대로입니다                ★
· 화면이 그대로입니다
· 사람이 배울 게 없습니다                 ★

6. 없으면 만들어야 합니다

그때는 작게.                              ★
· 요청 목록 화면 하나                      ★
· 승인·반려 버튼
· 알림                                     ★
그리고 사유를 필수로.                     ★
반려할 때도 사유를 받으세요.                 ★
· 그게 도구를 고치는 목록이 됩니다        ★
   (왜 자꾸 틀리는 요청이 오나)           ★

7. 제조 현장의 실제

어느 업체, 마스터 수정 도구를 요청으로 바꿨습니다.
  전  품목수정(품번, 항목, 값)               ★
  후  품목수정요청(품번, 항목, 값, 사유)      ★
그리고 이미 있던 기준정보 요청 화면에     ★
붙였습니다.
여섯 달
  요청     월 210건                        ★
  승인     189건 (90%)                      ★
  반려     21건 (10%)                     ★
반려 사유를 보니
· 근거가 약함        9건                   ★
· 이미 다른 값으로 정해짐   6건            ★
· 대상이 틀림        4건                   ★
· 권한 밖           2건                    ★
그리고 첫 번째를 고쳤습니다
  도구가 근거를 필수로 받게               ★
  그리고 근거가 원문에 있나 확인          ★
  반려  10% → 4%                          ★
데이터 사고는 0건이었습니다.              ★

8. ★ 「반려가 도구를 고칩니다」

직접 쓰면
· 틀려도 모릅니다                        ★
· 고칠 것도 모릅니다
요청이면
· 반려가 남습니다                        ★
· 사유가 남습니다
· 그게 고칠 목록입니다                   ★
그래서 요청은
  안전할 뿐 아니라 배웁니다.              ★

9. 어디까지 요청으로 할까

  쓰기 종류        판정                     ★
  ──────────────────────────────────────
  마스터 수정      요청                    ★
  상태 변경        요청 (되돌리기 어려우면)  ★
  실적 정정        요청                    ★
  판정 기록        직접 (새 값이고 되돌림 가능) ★
  분류·태그        직접                     ★
  초안 저장        직접                     ★
  메일 발송        초안까지만              ★
「되돌릴 수 있나」 와 「따라오는 게 있나」    ★
두 물음이면 정해집니다.                    ★

10. 오늘 해 볼 것 (15분)

① 쓰기를 판정하세요

  쓰기        되돌림  따라옴  판정           ★
  ________    ○/✗    ○/✗    직접/요청
  ________    ○/✗    ○/✗    직접/요청      ★
② 기존 요청 흐름을 찾으세요

  □ 마스터 등록 요청이 있나                  ★
  □ 변경 요청이 있나
  □ 붙일 수 있나  ○/✗                        ★
③ 요청에 넣을 것을 정하세요

  □ 무엇을  □ 왜  □ 누가                  ★
  □ 근거  □ 원래 값                    ★

11. 내일 할 것

확인을 받는 자리.

요청을 만들었습니다. 누가 언제 어떻게 확인하나입니다.


이 글은 MCP 과정의 4주차 2일차입니다. 과정 전체 보기

진도와 검색이 되는 판: AXPulse 기술따라가기

댓글

이 블로그의 인기 게시물

자재관리는 잘 쓰는데 BOM은 엑셀입니다

협력사 AI 로봇 도입, 공급망 스마트 제조 생태계 대응 전략

개발 테스트 자동화, AI 에이전트와 MCP 도입 전략