2026.09.30 RFP Multi-Agent 설계 및 Jev 학습 정리(4주차-2)

Об этом предложении

한 일 요약 개인 프로젝트인 RFP / 고객 요구사항 대응 검토 Multi-Agent 의 UX Scenario 이후 단계인 Task 도출과 Agent 구조 설계를 진행함. :chatgpt-content-reference{index="0"} Persona 수에 맞춰 Agent를 나누지 않고 실제 업무에서 필요한 Task를 기준으로 Agent 역할을 분리 함. :chatgpt-content-reference{index="1"} 최종적으로 Main Agent 1개 + Sub-Agent 2개 구조로 정리함. Main Agent는 전체 흐름 관리와 결과 취합만 담당하고, 실제 요구사항 분석 및 검토는 Sub-Agent가 담당하도록 역할을 구분함. 각 Agent의 Prompt를 역할 → 입력 → 처리 → 제약 → 출력 구조로 통일함. :chatgpt-content-reference{index="2"} Web Search는 내부 공식 자료를 대체하지 않고 공개 정보 보완용 으로만 사용하도록 기준을 정의함. 다음 단계로 테스트용 RFP와 내부 더미 데이터를 만들고 Expected Output 및 Pass/Fail 기준을 정의할 예정임. :chatgpt-content-reference{index="3"} AI 리터러시 발표 주제로 Jev 를 조사하고 기존 LLM과의 차이를 정리함. Jev의 Choice / Noul / Score / Confidence 개념과 적합한 활용 영역을 학습함. 최종적으로 Jev를 Code, LLM, Agent와 비교하여 각각 어떤 문제에 적합한지 정리하고 7분 발표 구성을 완성함. 1. RFP / 고객 요구사항 대응 프로젝트 재확인 현재 개인 프로젝트의 주제는 RFP / 고객 요구사항 대응 검토 이며, Domain은 B2B 영업 / 기술영업 으로 설정했다. :chatgpt-content-reference{index="4"} 프로젝트의 목적은 고객이 전달한 RFP를 단순히 요약하는 것이 아니라, 고객 요구사항을 내부 제품 및 정책 자료와 비교하여 다음과 같이 정리하는 것이다. 대응 가능 불일치 근거 부족 추가 확인 필요 즉 사용자가 직접 여러 내부 문서를 검색하고 비교하던 작업을 Agent가 지원하여 반복적인 검토 업무를 줄이는 방향이다. 2. UX Scenario 작성 완료 앞선 기획 단계에서는 다음 세 가지 Persona를 기준으로 AS-IS / TO-BE UX Scenario를 작성했다. :chatgpt-content-reference{index="5"} B2B 영업 담당자 기존에는 RFP를 직접 읽고 제품 및 정책 문서를 찾아 대응 가능한 요구사항과 추가 검토가 필요한 요구사항을 구분했다. Agent 도입 후에는 요구사항 구조화와 내부 근거 조회를 지원하여 1차 검토 부담을 줄이는 방향으로 설계했다. 기술영업 담당자 제품 기능, API, 보안 등 기술 자료를 직접 검색하고 고객 요구사항과 비교하던 업무를 Agent가 지원하도록 구성했다. 제안기획 담당자 영업 및 기술 담당자의 검토 결과를 다시 취합하고 미확인 항목을 점검하던 업무를 요구사항별 근거와 함께 정리하도록 설계했다. 3. Persona가 아닌 Task 기준으로 Agent 분리 오늘 설계에서 가장 중요하게 본 부분은 Persona 수와 Agent 수를 동일하게 맞추지 않는 것 이었다. 기존 피드백처럼 다음 구조로 접근하지 않았다. B2B 영업 담당자 → 영업 Agent 기술영업 담당자 → 기술 Agent 제안기획 담당자 → 제안 Agent 대신 UX Scenario에서 실제 필요한 업무를 다시 분석했다. 필요한 주요 Task 전체 RFP 검토 흐름 관리 고객 요구사항 추출 및 구조화 내부 근거 검색 및 대응 상태 검토 처음에는 내부 근거 검색 과 대응 검토 를 서로 다른 Agent로 분리하는 방법도 고려했다. 하지만 내부 근거를 검색한 직후 해당 근거를 기준으로 고객 요구사항을 검토하는 연속적인 작업이기 때문에 별도로 나누면 역할 중복과 Token 사용량 증가 가능성이 있다고 판단했다. :chatgpt-content-reference{index="6"} 최종 구조 Main Agent 1개 + Sub-Agent 2개 로 정리했다. 4. RFP 처리 총괄 Agent Main Agent는 RFP 처리 총괄 Agent 로 정의했다. 주요 역할 사용자 요청 확인 필요한 Sub-Agent 호출 작업 순서 관리 Sub-Agent 결과 취합 최종 사용자 응답 생성 중요한 점은 Main Agent가 직접 고객 요구사항을 분석하거나 대응 가능 여부를 판단하지 않는다는 것이다. Main Agent는 오케스트레이션과 최종 결과 취합 에 집중하도록 역할을 제한했다. :chatgpt-content-reference{index="7"} 5. 요구사항 구조화 Agent 첫 번째 Sub-Agent는 요구사항 구조화 Agent 다. RFP 문서에서 실제 검토해야 하는 고객 요구사항을 찾아 구조화하는 역할을 담당한다. 주요 역할 고객 요구사항 추출 요구사항 항목별 분리 중복 및 유사 요구사항 확인 요구사항 유형 분류 요구사항 유형 예시 기능 기술 보안 서비스 및 지원 정책 또한 문서에 존재하지 않는 요구사항을 임의로 생성하지 않고, 유사하다는 이유만으로 서로 다른 요구사항을 임의로 합치지 않도록 제약을 설정했다. :chatgpt-content-reference{index="8"} 6. 근거 기반 대응 검토 Agent 두 번째 Sub-Agent는 근거 기반 대응 검토 Agent 다. 구조화된 고객 요구사항을 내부 공식 자료와 비교하여 실제 대응 상태를 검토한다. 주요 참조 자료 제품 기능 문서 기술 문서 보안 문서 서비스 및 지원 정책 검토 결과 각 요구사항을 다음 중 하나로 구분한다. 대응 가능 불일치 근거 부족 추가 확인 필요 내부 근거가 없는 상태에서 Agent가 임의로 대응 가능 이라고 판단하지 못하도록 하는 것도 중요한 제약으로 설정했다. :chatgpt-content-reference{index="9"} 7. Web Search 사용 기준 근거 기반 대응 검토 Agent에는 Web Search를 사용할 수 있도록 설정했다. 하지만 Web Search 결과를 회사 내부 공식 자료와 동일한 근거로 사용하면 문제가 발생할 수 있다. 따라서 다음 원칙을 적용했다. 기본 원칙 내부 공식 자료 우선 ↓ 내부 자료만으로 확인하기 어려운 공개 정보만 Web Search로 보완 ↓ 외부 정보와 내부 근거를 구분하여 표시 특히 Web Search 결과만으로 회사가 고객 요구사항에 대응 가능하다고 판단하지 않도록 했다. 즉 Web Search는 회사 정책이나 제품 문서를 대신하는 Source가 아니라 부족한 공개 정보를 보완하는 수단 으로 정의했다. :chatgpt-content-reference{index="10"} 8. Agent 간 실행 흐름 현재 Multi-Agent 구조는 Sub-Agent들이 서로 직접 연결되는 구조가 아니다. 전체 흐름은 다음과 같다. 사용자 요청 ↓ RFP 처리 총괄 Agent ↓ 요구사항 구조화 Agent ↓ Main Agent로 결과 반환 ↓ 근거 기반 대응 검토 Agent ↓ Main Agent로 결과 반환 ↓ 최종 응답 즉 Main Agent가 각 Sub-Agent를 순서대로 호출하고, Sub-Agent의 결과는 다시 Main Agent로 반환하는 구조다. :chatgpt-content-reference{index="11"} 9. Agent Prompt 작성 기준 각 Agent의 Prompt도 동일한 기준으로 작성하기로 했다. Prompt 구조 역할 ↓ 입력 ↓ 처리 ↓ 제약 ↓ 출력 예를 들어 요구사항 구조화 Agent라면 다음과 같이 정의한다. 역할 고객 RFP를 검토 가능한 요구사항 형태로 구조화함. 입력 고객 RFP 및 요구사항 문서 처리 요구사항을 추출하고 유형별로 분류함. 제약 문서에 없는 내용 생성 금지 서로 다른 요구사항 임의 병합 금지 출력 요구사항 번호 요구사항 내용 요구사항 유형 이렇게 구성하면 Agent가 무엇을 해야 하는지만 아니라 무엇을 하지 말아야 하는지도 명확하게 정의할 수 있고 테스트하기도 쉬워진다. :chatgpt-content-reference{index="12"} 10. Agent별 출력 형식 구분 모든 Agent가 동일한 형태로 결과를 반환할 필요는 없다고 판단했다. Main Agent 최종 사용자가 보는 결과이므로 다음 형태를 고려했다. 요약 최종 검토 결과 표 추가 확인사항 요구사항 구조화 Agent 다음 Agent가 처리할 데이터이므로 사람에게 보여주기 위한 문장보다 구조화된 요구사항 데이터 가 적합하다. 근거 기반 대응 검토 Agent 다음 정보를 구조화하여 Main Agent에 전달하도록 설계했다. 요구사항 번호 검토 결과 내부 근거 근거 문서 외부 참고 정보 추가 확인사항 Sub-Agent 사이의 정보 전달에서는 표보다 JSON과 같은 구조화된 형태가 더 적절할 가능성도 함께 검토했다. :chatgpt-content-reference{index="13"} 11. Multi-Agent 설계에서 다시 확인한 점 오늘 설계를 진행하면서 다시 확인한 핵심은 Agent를 많이 만드는 것이 Multi-Agent의 목적은 아니라는 것 이다. 처음에는 Agent를 더 잘게 분리하면 역할이 명확해질 수 있다고 생각할 수 있다. 하지만 Agent가 증가하면 다음 문제도 함께 증가할 수 있다. Agent 호출 횟수 Token 사용량 Context 전달 역할 중복 Prompt 관리 비용 테스트해야 하는 범위 따라서 내부 근거 검색과 대응 검토처럼 서로 강하게 연결된 업무는 하나의 Agent가 함께 처리하도록 구성했다. Main Agent 역시 실제 분석에는 참여하지 않고 흐름 관리에 집중시켜 역할 중복을 줄였다. :chatgpt-content-reference{index="14"} 12. 개인 프로젝트 현재 진행 상태 현재 개인 프로젝트는 다음 단계까지 진행되었다. 주제 선정 완료 ↓ Persona / Pain Point 정의 완료 ↓ UX Scenario 작성 완료 ↓ Task 도출 완료 ↓ Agent 구조 설계 완료 ↓ Agent별 Prompt 설계 기준 정리 완료 다음 단계에서는 테스트용 RFP와 내부 제품 및 정책 더미 데이터를 만들고 다음 내용을 준비할 예정이다. Expected Output Pass / Fail 기준 Agent별 테스트 Scenario Gemini Enterprise 실제 구현 결과 비교 및 개선 :chatgpt-content-reference{index="15"} 13. AI 리터러시 — Jev 조사 개인 프로젝트와 함께 AI 리터러시 발표를 위해 Jev 라는 모델을 조사했다. Jev는 TypeSafe AI가 공개한 System One Model 계열의 모델로, GPT나 Claude처럼 긴 문장을 생성하는 것보다 구조화된 판단 결과를 반환하는 것에 초점을 둔 모델 이다. :chatgpt-content-reference{index="16"} 쉽게 구분하면 다음과 같다. GPT / Claude / Gemini → 생성하는 AI Jev → 판단하는 AI 14. 기존 LLM과 Jev의 차이 일반적인 LLM은 Token을 생성하여 최종 Text를 만드는 것이 기본이다. Input ↓ LLM ↓ Token 생성 ↓ Text 반면 Jev는 입력 상태를 보고 구조화된 확률적 판단 결과 를 반환하는 방향을 지향한다. 상황 입력 ↓ Jev ↓ Typed Probabilistic Decision 따라서 Jev를 단순히 GPT의 작은 버전으로 이해하는 것보다는 목적 자체가 다른 Decision Model 로 이해하는 것이 적절하다고 정리했다. :chatgpt-content-reference{index="17"} 15. Jev가 필요한 이유 일반적인 프로그램에서는 명확한 규칙을 if 문으로 처리할 수 있다. 하지만 실제 자연어는 같은 의미도 매우 다양하게 표현될 수 있다. 반대로 이런 작은 판단마다 대형 LLM을 호출하면 비용과 응답 시간 측면에서 과할 수도 있다. 따라서 Jev는 다음 영역을 목표로 한다. Hard-coded Rule ↓ Jev ↓ Full LLM / Agent 즉, 규칙만으로 처리하기에는 애매하지만, 깊은 추론이나 긴 생성까지는 필요하지 않은 판단 에 사용하는 모델로 이해했다. 쉽게 표현하면 확률적으로 판단하는 똑똑한 if문 에 가까운 개념이다. :chatgpt-content-reference{index="18"} 16. Jev의 세 가지 판단 방식 Jev에서는 크게 Choice, Noul, Score 세 가지 판단 형태를 학습했다. :chatgpt-content-reference{index="19"} Choice 여러 선택지 중 하나를 선택함. 이 문의는 어떤 유형인가? 결제 / 기술 / 계정 → 결제 Choice = 무엇인가? Noul 각 조건이 맞는지 독립적으로 판단함. 환불 요청인가? → Yes / No 중복 결제인가? → Yes / No 사람 확인이 필요한가? → Yes / No 여러 조건이 동시에 참일 수 있다는 점이 Choice와 다르다. Noul = 맞는가? Score 대상의 강도나 수준을 평가함. 고객 불만 수준은? 0 = 낮음 1 = 보통 2 = 높음 → 1.4 Score = 어느 정도인가? 17. Confidence Jev는 판단 결과만 제공하는 것이 아니라 Confidence도 함께 반환한다. 예를 들어 단순히 다음과 같이 반환하지 않고, billing 다음과 같이 반환할 수 있다. billing = 0.96 이를 서비스의 다음 동작과 연결할 수 있다. Confidence 높음 → 자동 처리 Confidence 중간 → 더 강한 모델로 재검토 Confidence 낮음 → Human Review 중요한 점은 Threshold가 Jev에 고정된 공식 숫자가 아니라 서비스의 위험도와 비용에 따라 개발자가 정해야 하는 운영 기준 이라는 점이다. :chatgpt-content-reference{index="20"} 18. Jev가 잘 맞는 업무 Jev는 모든 AI 작업을 대신하기 위한 모델이 아니다. 다음과 같이 빠른 판단이 필요한 업무에 적합하다. Classification Routing Scoring Verification Moderation / Guardrail Fraud Detection Search Ranking 공통점은 긴 문서를 생성하거나 깊은 Reasoning을 수행하기보다 짧고 반복적인 판단이 필요하다는 점 이다. :chatgpt-content-reference{index="21"} 반대로 다음 업무는 기존 LLM이나 Agent가 더 적합하다. 코드 작성 문서 작성 Research 긴 대화 Architecture 설계 복잡한 Reasoning :chatgpt-content-reference{index="22"} 19. Code / Jev / LLM / Agent 구분 오늘 Jev를 공부하면서 가장 이해하기 쉬웠던 구분은 다음과 같다. Code → 확실한 규칙 Jev → 애매하지만 빠른 판단 LLM → 복잡한 추론과 생성 Agent → Tool을 이용한 여러 단계의 작업 예를 들어: HTTP Status 확인 → Code 고객 문의 분류 → Jev 문서 작성 및 복잡한 설명 → LLM 검색 + Tool 호출 + 판단 + 반복 작업 → Agent 즉 모든 문제를 가장 강력한 하나의 모델에게 맡기는 것이 아니라 문제의 성격에 맞는 방법을 선택하는 것이 중요하다 는 방향으로 이해했다. :chatgpt-content-reference{index="23"} 20. Jev의 한계 Jev는 아직 초기 단계이기 때문에 현재 공개된 결과를 그대로 실제 환경에 일반화해서는 안 된다고 정리했다. 추가 확인이 필요한 부분은 다음과 같다. 실제 Traffic 환경의 Latency Domain별 Accuracy Confidence Calibration 장기간 Reliability Pricing API Stability 또한 정해진 형식의 결과만 반환한다고 해서 항상 정답을 선택한다는 의미는 아니다. 예를 들어 실제 정답이 billing 인데 technical 이라고 판단하는 것처럼 Decision Error는 여전히 발생할 수 있다. :chatgpt-content-reference{index="24"} 21. Jev 7분 발표 구성 발표에서는 Jev 내부 구조를 깊게 설명하기보다 이런 새로운 종류의 AI 모델이 등장했고 기존 생성형 LLM과 어떤 차이가 있는지 소개하는 것 을 목표로 했다. 최종 발표는 다음 6개 흐름으로 구성했다. Jev란 무엇인가 기존 LLM과 Jev의 차이 왜 Jev가 필요한가 Jev는 어떻게 판단하는가 Choice Noul Score Confidence 왜 주목받고 있고 어디에 사용할 수 있는가 정리 및 개인 인사이트 :chatgpt-content-reference{index="25"} 22. 오늘의 핵심 정리 RFP / 고객 요구사항 대응 Multi-Agent 프로젝트에서 UX Scenario 이후 Task 도출과 실제 Agent 구조 설계 단계까지 진행함. Persona별 Agent를 만들지 않고 실제 업무에 필요한 Task를 기준으로 Agent 역할을 나눔. 최종적으로 RFP 처리 총괄 Main Agent + 요구사항 구조화 Agent + 근거 기반 대응 검토 Agent 구조로 정리함. Main Agent는 분석하지 않고 전체 업무 흐름과 결과 취합만 담당하도록 역할을 제한함. 근거 검색과 대응 검토는 연속된 작업이기 때문에 하나의 Agent로 구성하여 역할 중복과 Token 사용을 줄이는 방향을 선택함. Agent Prompt는 역할 → 입력 → 처리 → 제약 → 출력 구조로 통일함. Web Search는 내부 공식 자료를 대체하지 않고 공개 정보를 보완하는 용도로 제한함. 다음 단계는 테스트용 RFP 및 내부 더미 데이터, Expected Output, Pass / Fail 기준을 만들고 실제 Gemini Enterprise Agent를 구현하는 것임. AI 리터러시에서는 생성보다 판단에 집중하는 Jev Decision Model 을 조사함. Jev의 Choice, Noul, Score, Confidence 개념을 학습하고 기존 LLM과의 차이를 정리함. 모든 문제에 대형 LLM을 사용하는 대신 Code → Jev → LLM → Agent 처럼 문제 복잡도와 특성에 따라 적절한 도구를 선택할 수 있다는 점이 가장 흥미로웠음. 오늘 학습을 통해 개인 프로젝트와 AI 리터러시 모두에서 공통적으로 “가장 강력하거나 복잡한 구조를 사용하는 것보다 문제에 필요한 만큼의 구조를 선택하는 것이 중요하다” 는 점을 다시 확인함.