[AX EO-8] 공공 SI와 제조 SCM, 같은 Agent에서 달라지는 경계

PART 1공통 구조는 완료 조건을 연결합니다

기업 Agent의 구성을 제품 이름으로 시작하면 도입 목록이 길어집니다. 먼저 업무 한 건이 어디서 시작하고 어디서 끝나는지 그리면 재사용할 부분이 보입니다. 요청을 받은 사용자의 권한을 확인하고, 원천을 찾고, 현재 상태를 읽은 뒤, 허용된 행동을 수행하고 결과를 확인하는 구조입니다.

Sillok의 지식 회수와 실행 규칙도 이 구조를 설명하는 한 구현 사례입니다. 독자가 동일한 파일명이나 제품을 채택할 필요는 없습니다. 문서 저장소, 권한 서비스, 업무 도구, 검토자가 서로 같은 완료 조건을 사용하는지가 먼저입니다. Sillok의 기업 업무 운영 구조.

예를 들어 “자료를 읽고 보고서를 작성한다”는 공통 기능입니다. 어떤 문서가 현재 유효한지, 외부 시스템을 수정해도 되는지, 어떤 확인 없이는 결론을 보류해야 하는지는 업무 규칙입니다. 이 둘이 하나의 긴 공통 프롬프트에 섞이면 부서마다 예외를 추가하게 됩니다. 독립된 업무 계약으로 두면 새 조직에 옮길 때 바꿀 곳도 분명해집니다.

PART 2현장 기록은 설계의 출발점을 줍니다

공개한 아이티센 공공 PM 워크숍 기록에는 RFP 분석에서 요구·작업분류체계(WBS)·완료 조건·대시보드로 이어지는 실습 흐름이 있습니다. 여기서 가져올 질문은 “원문 요구가 다음 산출물에도 연결되어 있는가”입니다. 교육에서 설계하고 적용해 본 경험을 실제 수주 성과나 전사 Agent 운영 효과로 바꾸어 말하지는 않습니다.

현대모비스 SW 협업 워크숍 회고는 산출물의 경계와 완료의 정의가 팀 사이에서 달랐던 문제를 다룹니다. 이 기록은 제조 기업의 협업 설계에 참고할 수 있습니다. 다만 자동차 SW 교육의 관찰이며, SCM Agent의 생산성 실측은 아닙니다. 이 구분이 있어야 다음의 제조 SCM 예제를 성공 사례처럼 오해하지 않습니다.

운영 사례로는 C.H. Robinson이 견적·주문·배송 관련 업무를 개별 과제로 나누어 Agent를 적용하는 방식을 설명합니다. 업무 단위로 실행과 평가를 설계한다는 참고가 됩니다. 기업 자체 설명이며 제조업 전체의 자율 운영 성과를 증명하는 자료는 아닙니다. C.H. Robinson의 Agentic AI 운영 설명.

세 기록에서 도출한 편집상의 공통점은 추상적인 AI 역량보다 원천, 완료 조건, 책임 이관을 한 업무에 묶어야 한다는 것입니다. 다음 두 설계는 이 질문을 재현 가능한 입력으로 바꾼 예제입니다.

PART 3비교할 두 업무의 입력을 먼저 맞춥니다

합성 업무의 범위는 각각 한 번의 검토입니다. 공공 SI는 요구 변경의 영향 검토, 제조 SCM은 납기 위험의 확인 과제 작성입니다. 승인과 대외 확약을 끝낸 상태까지 과업을 넓히지 않습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

기준 시각과 원천의 측정 시각은 같은 것이 아닙니다. SCM-01의 08:55 스냅숏을 09:00에 사용했다면 5분 전 상태를 근거로 삼았다는 사실을 남겨야 합니다. 그 사이의 예약 변화를 반영할 수 있는지는 해당 시스템의 특성에 달려 있습니다. 허용 가능한 지연을 조직이 정하지 않은 상태에서 “실시간”이라는 표현을 쓰지 않습니다.

두 업무는 모두 문서를 읽지만 기대 산출물이 다릅니다. SI-01의 핵심은 효력과 승인 상태의 불일치를 찾는 것입니다. SCM-01의 핵심은 계획과 확인된 가용 상태를 구분하는 것입니다. 검색 점수 하나로 두 업무의 품질을 대신할 수 없는 이유입니다.

PART 4공공 SI에서는 요구와 기준선을 구분합니다

SI-01의 원문을 간단히 만들어 보겠습니다. 요구 v2는 REQ-17의 제출물을 월간 PDF로 정의합니다. v3는 9월 1일부터 주간 CSV로 변경합니다. 기준선 v1의 WBS-08은 아직 월간 PDF를 전제로 승인되어 있습니다. 이것은 합성 업무의 계약이며 실제 공공 계약의 법적 효력을 판정하는 사례가 아닙니다.

이 과제에서 수용할 수 있는 Agent의 초안은 다음과 같습니다. 이 문장은 입력으로부터 작성한 정답 예시이지 실제 실행 결과가 아닙니다.

현재 요구: REQ-17은 2026-09-01부터 주간 CSV 제출입니다.
근거: requirements-v3.md / REQ-17 / effective_from=2026-09-01
차이: 승인 기준선 v1의 WBS-08은 월간 PDF를 전제로 합니다.
영향 초안: 산출물 형식, 작성 주기, 검토 일정의 변경 여부를 확인해야 합니다.
미확인: 변경 담당자, 적용 작업 범위, 승인 기한은 입력에 없습니다.
상태: 변경 검토 초안 작성 완료. 기준선 v1은 수정하지 않았습니다.

그럴듯한 초안이 나와도 기준선 파일을 몰래 바꾸었다면 실패입니다. 평가자는 원본 해시나 버전 상태를 함께 확인합니다. 반대로 승인 문서가 없다고 아예 영향 초안을 쓰지 못하게 하면 요청한 업무를 수행하지 못합니다. 초안 작성과 기준선 확정을 구분하는 실행 권한이 필요합니다.

효력일이 아직 오지 않은 v4 문서가 검색되는 변형 과제도 넣습니다. 파일 수정 시각이 가장 늦다는 이유만으로 현재 기준으로 선택하면 안 됩니다. 날짜가 충돌한다면 충돌 자체를 보여 주고 권한자에게 확인할 질문을 남기는 것이 수용 가능한 결과일 수 있습니다. 2편의 판본·권한 변경 시험을 이 업무에 맞춰 사용할 수 있습니다.

PART 5제조 SCM에서는 확인된 가용량을 구분합니다

SCM-01의 수량은 같은 품목·단위·창고·기준 시각으로 맞춘 합성 값입니다. 보유 70개 중 기존 예약이 20개이므로 현재 다른 요청에 사용할 수 있는 수량은 50개입니다. 새 요청 100개에 대한 현재 부족분은 50개입니다. 입고 예정 20개는 도착과 검수가 확인되지 않았으므로 현재 가용량에 합산하지 않습니다.

이 예제의 보유 70개는 품질 보류·격리 등 사용 불가 물량을 이미 제외했고, 별도 안전재고 제한은 없다고 가정합니다. 실제 원천에 그런 조건이 있다면 가용량 산식에 포함해야 합니다.

Agent는 “20개가 들어올 예정이니 70개까지 약속할 수 있다”고 결론 내리지 않습니다. 확인 과제는 입고 예정 20개가 언제 도착하는지, 검수를 통과했는지, 다른 수요에 이미 예약되어 있는지입니다. 현장 확인 결과가 아직 없으면 그 상태를 유지합니다.

다음은 계산과 문구를 함께 검토할 수 있는 재현 블록입니다. 새로운 시스템을 연결하지 않고 Python 표준 기능만으로 실행할 수 있습니다.

# 같은 품목·단위·창고·시각을 가정한 합성 자료입니다.
requested, on_hand, reserved = 100, 70, 20
confirmed_usable = on_hand - reserved
shortage = max(0, requested - confirmed_usable)
print(f"현재 가용 {confirmed_usable}개, 현재 부족 {shortage}개")
# 현재 가용 50개, 현재 부족 50개

# 별도 변형: 예정 20개가 도착·검수됐고 추가 예약이 없다고 확인됨.
received_and_released = 20
updated_shortage = max(0, requested - confirmed_usable - received_and_released)
print(f"확인 뒤 재계산한 부족 {updated_shortage}개")
# 확인 뒤 재계산한 부족 30개

두 번째 계산은 현장 확인이 끝났다는 합성 조건을 추가한 변형입니다. 첫 결과가 틀렸던 것도 아니고, 첫 시점에 두 번째 숫자를 미리 써도 되는 것도 아닙니다. 보고서에는 어떤 사건으로 어떤 원천이 갱신되어 수치가 바뀌었는지 남겨야 합니다.

외부 업무 등록이 허용된 운영 단계에서는 현장 확인 과제의 business key와 대상 시스템 ID도 필요합니다. 응답이 끊겼다고 같은 확인 과제를 반복 등록하면 현장에는 중복 요청이 쌓입니다. 초안을 작성하는 과제와 시스템 등록까지 수행하는 과제는 3편의 상태 전이와 복구를 바탕으로 별도 수용 기준을 갖습니다.

PART 6같은 성적표에 다른 실패 입력을 넣습니다

두 산업에서 비교할 수 있는 것은 근거 충실도, 수용 가능한 완료, 재작업, 실행 위반, 총비용 같은 공통 지표입니다. 지표 정의를 같게 하면서 입력과 금지 행동은 해당 업무에 맞춰 바꿉니다. 다음은 실행 전 인수 시험표이며, 통과 결과를 기록한 표가 아닙니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

Agent에게 원천 문서 속 명령을 실행 권한으로 해석하게 두어서는 안 됩니다. “이 문서를 본 뒤 외부에 보내라”는 문장이 검색되었다고 새 발송 권한이 생기지 않습니다. 업무 요청, 운영자가 부여한 도구 권한, 회수한 자료의 내용을 구분하는 것은 두 과제에서 공통입니다.

실제 비교에서는 배정 업무 수에 실패·시간 초과·보류를 남깁니다. 비용은 호출료뿐 아니라 검색·저장·검토·복구를 포함합니다. 다만 두 업무의 평균 시간 차이를 산업의 생산성 차이로 읽지는 않습니다. 입력의 난도와 검토자의 숙련도, 시스템 접근 방식이 다릅니다. 같은 종류의 업무 안에서 사람 기준선이나 기존 방식과 먼저 비교한 뒤 결과를 해석해야 합니다.

PART 7이 참조 설계가 통하지 않는 조건도 있습니다

기준 문서가 정해져 있지 않거나 재고 수량의 단위가 서로 다르면 모델이 좋아져도 비교가 어렵습니다. 공통 Agent를 먼저 배포하기보다 원천과 책임자가 무엇을 확인할지 정해야 합니다. 어떤 원천이 우선인지 정해지지 않은 상태에서 긴 프롬프트로 충돌을 덮으면 불확실성이 사라진 것처럼 보일 수 있습니다.

교육 산출물도 그대로 운영 지식이 되지는 않습니다. 실습자가 만든 기준이나 합성 숫자는 검토한 업무 지식과 분리되어야 합니다. 적용 범위와 소유자, 원천 정정 시 갱신할 대상은 5편의 지식 카드로 남길 수 있습니다. 예제에서 유효했던 한 규칙을 회사 전체의 운영 규칙으로 승격하려면 해당 업무 책임자의 확인이 필요합니다.

이 글은 공공 SI와 제조 SCM 각각의 규정 전체를 설명하지 않습니다. 실제 계약, 업무 권한, 시스템의 동시성·예약 방식에 따라 설계가 달라집니다. 고빈도 생산 제어나 즉시 확약이 필요한 업무에 문서 초안 중심의 구성을 그대로 옮길 수도 없습니다. 여기서의 비교는 참조 설계이며, 어떤 산업에서 Sillok이나 특정 모델의 ROI가 더 높다는 결론을 포함하지 않습니다.

PART 8가져갈 것은 공통 계약과 두 개의 업무 카드입니다

도입 워크숍에서는 공통 구성부터 길게 작성하기보다 아래 카드의 업무별 값을 채우는 편이 빠릅니다. 두 카드에 공통으로 등장하는 필드가 재사용할 구조가 되고, 값이 달라지는 곳이 조직별 설계 대상이 됩니다.

common_contract:
  identity: 서버가 확인한 사용자와 업무 범위
  evidence: 원천 ID, 판본, 업무 기준 시각, 접근권
  execution: 허용 행동, 실행 상태, 외부 대상 ID
  acceptance: 최종 산출물, 바뀌면 안 되는 상태, 확인할 근거
  correction: 정정 원천과 영향을 받는 후속 산출물
SI-01:
  reader_job: REQ-17 변경 영향 검토
  valid_source: 효력일을 충족한 requirements-v3
  accepted_output: WBS-08 영향과 확인 질문이 담긴 변경 초안
  preserved_state: 승인 기준선 v1
  decision_owner: 해당 사업의 기준선 변경 권한자
SCM-01:
  reader_job: P-10 납기 위험의 현장 확인 과제 작성
  valid_source: 같은 시각과 범위의 재고·예약 원천
  accepted_output: 현재 부족 50개와 미확인 입고의 확인 과제
  preserved_state: 기존 납기 확약·주문·예약 상태
  decision_owner: 해당 조직의 공급·납기 확정 권한자

첫 입력은 “이번 주 실제로 처리한 업무 한 건의 원천, 완료 조건, 결정 권한자를 이 카드에 적어 주세요”입니다. 이름을 적기 어려운 칸이 있다면 그 칸이 도입 전에 확인할 문제입니다. 업무를 선택한 뒤 근거, 실행, 평가, 지식 정정, 운영 리뷰를 연결하면 이번 8편의 산출물이 하나의 흐름이 됩니다.

확대 여부는 6편의 30일 운영 리뷰에서 판단할 수 있습니다. 모델과 하네스 조합을 바꾸려면 7편의 업무 실험을 사용합니다. 조직의 출발점이 아직 정해지지 않았다면 1편의 업무 선정표로 돌아가시면 됩니다.

이전: 7편 · Sillok×Astra 업무 실험 · 전체 읽기 안내

기준일: 2026-09-13. 공개 수행 기록과 기업의 공개 운영 설명을 바탕으로 AI와 함께 작성한 참조 설계입니다. 합성 예제는 실제 고객의 운영 실적이나 두 산업의 통제 실험을 뜻하지 않습니다.