아이투맥스는 고객사의 비즈니스 문제를 기술적으로 해석하고 Agentforce 와 LLM 으로 상담·업무 자동화를 구현하며 ERP·그룹웨어 같은 레거시와 연동한다. 그래서 이 도구는 아이투맥스가 다루는 '요청을 에이전트 흐름과 연동 지점으로 옮기는' 작업이 있어야 의미가 있고, 단순 챗봇이 아니라 연동 지점까지 짚는 형태가 된다.
공고가 고객의 문제를 구조화하고 AI 와 시스템 연동으로 푸는 엔지니어를 찾는다. 요청을 흐름·연동 초안으로 옮기는 도구가 그 진입점이다.
Salesforce Agentforce 로 상담 자동화·지식 검색을 구현하는 일이라, 의도·액션으로 나눈 에이전트 흐름 초안이 그대로 쓰인다.
ERP·그룹웨어 등 외부 시스템과 AI 기능을 잇는 일이라, 연동 지점(엔드포인트·인증)을 초안에서 같이 짚어야 한다.
Salesforce Agentforce FDE 의 요청 설계 도구. 고객사 업무 자동화 요청을 받아 에이전트 흐름(의도·액션)과 외부 연동 지점을 근거 배열과 함께 낸다.
아이투맥스 AI Solutions Engineer 와 고객사 현업·IT 담당자.
고객 요청 텍스트와 보유 시스템 목록만으로도 에이전트 흐름과 연동 지점의 1차 초안을 만들 수 있고, 엔지니어는 그 초안을 Agentforce 에 맞춰 다듬으면 된다.
고객 자동화 요청과 보유 시스템 목록을 넣으면 에이전트 흐름(의도·액션 단계)과 연동 지점(시스템·방식)을 근거 배열과 함께 내는 웹 도구. 실제 Agentforce·레거시 연동은 빼고 요청 텍스트와 시스템 메타 가정으로만 시작한다(실 OAuth·Webhook 연동은 빠진 20% 통합이라 W3로 분리).
1주차 초안을 사람 검토자 정답 흐름과 비교해 액션 누락·과잉을 재고, 연동 지점이 보유 시스템 목록에 실재하는지 검사한 v2.
각 연동 지점을 실제 엔드포인트·인증(OAuth)·입출력 스펙으로 채워 Agentforce 구현 직전 골격까지 만드는 확장판.
고객 자동화 요청 한 건을 넣으면 에이전트 흐름과 연동 지점, 그 근거 배열이 한 화면에 나오는 걸 시연한다.
제안한 연동 지점이 모두 보유 시스템 목록에 실재하고 근거가 요청을 인용했는지 judge 로 검사해 연동 실재율 100%를 보여준다. 단, 정답·데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작이다.
결측·미등록 시스템 요청·표기 흔들림을 일부러 섞은 요청 30종을 넣어도 출력 JSON 형식이 안 깨지고 '미연동·확인필요'로 알리는 걸 시연한다.
초안 흐름과 합성 정답 흐름의 액션 일치도를 Cohen's κ(두 채점자가 우연 이상으로 얼마나 일치하는지 -1~1 점수, 높을수록 일치)로 2주차에 보고한다. 합성 기준 추정이라 실제와 다를 수 있다.
위 수치는 더미데이터 자가채점이며, 실제 흐름 정확도와 연동 정합성은 아이투맥스 실 고객 요청과 실 Agentforce 환경이 있어야 측정 가능하다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만든다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니다. 면접에서 데모 동작과 실검증 준비 상태로 솔직히 설명한다.
정답을 내가 만들었으니 잘 맞는 게 당연하다. 결측·미등록 시스템·표기 흔들림을 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피한다.
요청 표현이 시스템명과 달라 표면 유사도가 곧 의미 일치는 아니다. 실데이터 도입 단계에서 시스템 용어 사전을 맞추는 과제로 분리한다.
실제 도입 시 합성 정답이 실 엔지니어 판단으로 바뀌고 Agentforce 액션 카탈로그·고객 시스템도 달라진다. 액션 enum 과 연동 가드를 실 환경으로 다시 맞추는 일을 도입 과제로 둔다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 업무 자동화 요청과 보유 시스템 메타. 흐름·연동 추론의 입력.
| req_id | request_text | systems_raw | system_ids | channel | priority |
|---|---|---|---|---|---|
| R001 | 상담 문의가 오면 FAQ를 검색해 자동 답하고 못 풀면 상담원에게 넘… | Service Cloud, 사내 KB | ["service_cloud","kb"] | service | high |
| R002 | 신규 리드가 들어오면 등급을 매기고 영업 담당자에게 배정 | Sales Cloud | ["sales_cloud"] | sales | mid |
| R003 | 주문 상태를 ERP에서 조회해 슬랙으로 알림 | 그룹웨어ERP, Slack | ["erp","slack"] | slack | mid |
| R004 | 그거 자동화 좀 | [] | — | low | |
| R005 | 계약 데이터를 Data Cloud에 적재하고 이상치를 표시 | Data Cloud | ["data_cloud"] | data | high |
다음 Zod 스키마를 따르는 요청을 더 생성하라: z.object({ req_id: z.string(), request_text: z.string(), systems_raw: z.string(), system_ids: z.array(z.string()), channel: z.enum(['service','sales','data','slack','etc']).nullable(), priority: z.enum(['low','mid','high']) }). 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: systems_raw 가 빈 문자열이고 system_ids 가 빈 배열인 미등록 시스템 요청(orphan), channel 이 null 인 미상, request_text 가 '그거 자동화 좀' 처럼 모호한 건, 같은 시스템의 표기 흔들림(systems_raw 다름·system_ids 동일). 추가로 형식 깨뜨리기 시도 3건(타입이 어긋난 행)을 별도 표시해 파서 가드 테스트에 쓴다.z.object({ req_id: z.string(), request_text: z.string(), systems_raw: z.string(), system_ids: z.array(z.string()), channel: z.enum(['service','sales','data','slack','etc']).nullable(), priority: z.enum(['low','mid','high']) })| Python | 설계 엔진 런타임. 요청 파싱·LLM 호출·스키마 검증·연동 지점 정합 검사를 묶는다. |
| TypeScript | 에이전트 흐름·연동 지점을 보여주는 검토 화면의 타입 안전한 프런트 로직. |
| JavaScript | 흐름 카드·연동 다이어그램 같은 화면 컴포넌트 동작. |
| Java | 고객 레거시(ERP·그룹웨어)가 Java 스택인 경우의 연동 어댑터 예시 작성. |
| Node.js | Webhook 수신·OAuth 콜백을 흉내 내는 연동 목업 서버. |
| AWS | 도구를 컨테이너로 올리고 연동 목업·검토 화면을 배포하는 환경. |
| LLM | 요청을 의도·액션 단계로 분해하고 연동 지점을 추론해 근거와 함께 생성한다. |
✓ pass → 여기서 멈춰도 엔지니어 초안 도구로 완결. 더 키우려면 2주차에서 정답 흐름과 비교해 액션 누락을 보정한다.
✓ pass → 신뢰가 붙으면 3주차에서 연동 지점을 실제 API 스펙으로 채운다.
자동화 요청 한 건에 대한 에이전트 흐름과 연동 지점 초안.
z.object({ req_id: z.string(), flow: z.array(z.object({ intent: z.string(), action: z.enum(['create_record','search_kb','call_api','route','notify','compute']) })).min(0), integrations: z.array(z.object({ system_id: z.string(), method: z.enum(['api','webhook','oauth','none']) })), evidence: z.array(z.object({ field: z.enum(['request_text','systems_raw','channel']), note: z.string() })).min(1), hedge: z.string() })[
{
"req_id": "R001",
"flow": [
{
"intent": "문의 접수",
"action": "search_kb"
},
{
"intent": "미해결 시 상담원 연결",
"action": "route"
}
],
"integrations": [
{
"system_id": "service_cloud",
"method": "api"
},
{
"system_id": "kb",
"method": "api"
}
],
"evidence": [
{
"field": "request_text",
"note": "'FAQ를 검색해 자동 답' 에서 search_kb 도출"
},
{
"field": "systems_raw",
"note": "Service Cloud·KB 가 보유 시스템에 있음"
}
],
"hedge": "액션 매핑은 합성 기준 추정이라 실 Agentforce 에서 달라질 수 있다."
},
{
"req_id": "R004",
"flow": [],
"integrations": [],
"evidence": [
{
"field": "request_text",
"note": "'그거 자동화 좀' 뿐이라 흐름을 못 잡아 확인필요로 표시"
}
],
"hedge": "모호 요청이라 구조화 불가. 합성 기준."
},
{
"req_id": "R007",
"flow": [
{
"intent": "재고 임계 감시",
"action": "compute"
},
{
"intent": "발주 초안 생성",
"action": "create_record"
}
],
"integrations": [
{
"system_id": "사내재고시스템",
"method": "none"
}
],
"evidence": [
{
"field": "systems_raw",
"note": "사내재고시스템이 system_ids 에 미등록이라 method none·확인필요"
}
],
"hedge": "미등록 시스템이라 연동 방식 미정. 합성 기준 추정."
}
]flow.action·integrations.method enum, integrations.system_id 가 입력 system_ids 에 있는지, evidence min(1)은 Zod 와 조인으로 자동 검증한다. evidence note 의 의미 정합과 hedge 의 합성 기준 표기는 judge 와 수동 spot-check 로 검증한다.