CaffeMate 발표용 기술 분석
이 문서는 CaffeMate의 실제 코드와 운영 문서를 기준으로 작성한 발표용 기술 설명입니다. 구현된 기능, 운영 확인이 더 필요한 기능, 현재 범위가 제한된 기능을 구분했습니다. 발표에서는 기술 이름을 나열하기보다 각 기술이 어떤 문제를 해결하며, CaffeMate의 판단 품질과 안정성에 어떻게 기여하는지를 중심으로 설명할 수 있습니다.
1. 기술 설계의 핵심
CaffeMate는 단순히 카페 창업 정보를 생성하는 채팅 서비스가 아니라, 여러 출처에서 사실을 모으고 창업 후보를 비교한 뒤 사용자가 판단할 수 있는 근거를 남기는 의사결정 지원 시스템입니다. 이 목표를 위해 언어 모델이 잘하는 의미 해석과 설명은 Agent에 맡기고, 자금 계산, 조건 판정, 순위 결정, 상태 저장은 검증 가능한 코드에 맡겼습니다. 따라서 모델의 문장이 바뀌더라도 같은 입력과 같은 근거라면 핵심 계산 결과는 흔들리지 않습니다.
모든 흐름을 전적으로 Gemini의 판단에 맡기면 그럴듯하지만 근거가 없거나, 같은 입력에도 달라지는 추천이 나올 수 있다고 판단했습니다. 특히 창업비와 가맹 가능 여부처럼 사용자의 실제 결정에 영향을 주는 항목은 모델의 부정확한 해석이나 할루시네이션에 맡길 수 없었습니다. 짧은 개발 기간에 가장 중요했던 것은 복잡한 자율 Agent를 만드는 일이 아니라, 재현 가능한 워크플로 위에 모델의 해석과 설명 능력을 얹는 일이었습니다. 모델은 자료를 읽고 후보를 제안하지만, 근거 조회와 자금 계산, 조건 판정, 순위 확정은 코드가 담당합니다.
전체 흐름은 다음과 같습니다.
이 구조에서 Agent와 MCP는 권위 있는 프로젝트 상태를 직접 수정하지 않습니다. Agent는 해석 결과와 제안을 반환하고, MCP는 조회 결과를 반환합니다. Control API가 자료의 출처, 스키마, 프로젝트 범위, 계산 규칙을 확인한 뒤에만 결과와 상태를 저장합니다. 이 권한 분리는 멀티 Agent 구조를 유지하면서도 모델 오류가 데이터베이스의 확정 사실로 바로 들어가는 일을 막습니다.
2. 현재 확인된 지표와 남은 측정
기술을 적용했다는 사실만으로 품질이 좋아졌다고 말할 수는 없습니다. 평가 보고서에서 수치로 확인된 결과는 다음과 같습니다.
| 측정 항목 | 현재 결과 | 이 수치가 뜻하는 것 |
|---|---|---|
| 고가치 회귀 평가 | 35/35 통과, 100% | 지역 오류, 비용 누락, 자금 초과, 가맹 불가 브랜드, 문서 충돌, 프롬프트 주입 등 35개 실패 사례가 자동 검사에 연결되어 있습니다. |
| 자동 평가 범위 | 8개 검사 묶음 | 상권 근거, 재무 계산, 피드백 상태, RAG 범위, 문서 처리, Agent 계약, Runtime, RAG 근거 연결을 각각 검사합니다. |
| Proposal 프롬프트 응답 시간 | 8.734초에서 7.241초 | 같은 고정 입력을 한 번씩 실행한 비교에서 새 버전이 17.1% 짧았습니다. 반복 측정 결과는 아닙니다. |
| Proposal 출력 계약 | Schema와 의미 검사 통과, 적합도 5/5, 근거 연결 5/5 | 두 프롬프트 버전 모두 결과 카드에 필요한 구조를 채웠습니다. |
| 공식 RAG 실험 자료 | 공식 원문 13개에서 정규화한 근거 42개 | 정부의 커피전문점 창업 절차와 세 브랜드의 가맹 자료를 바탕으로 검색 실험용 코퍼스를 구성했습니다. 운영 색인 전체가 아니라 재현 가능한 평가 범위입니다. |
| RAG 평가 질문 | 기본 질문 60개, 복합·모호 질문 30개 | 공식 자료의 표현을 그대로 복사하지 않고, 실제 사용자가 물을 법한 문장으로 사람이 작성했습니다. |
| 복합 질문 Recall@3 | 92.78%에서 98.89% | 재정렬만 적용했을 때 밀려난 두 번째와 세 번째 근거를 질의 분해와 근거 보존형 병합으로 다시 확보했습니다. |
| 운영 종단 평가 범위 | 15개 시나리오 | 세 가지 카페 선호와 다섯 가지 창업자 조건을 조합한 실행 경로가 준비되어 있습니다. 현재 소스의 운영 통과율은 별도로 확인해야 합니다. |
RAG 품질은 운영 경로와 분리한 읽기 전용 실험으로 측정했습니다. 실험 자료는 정부와 브랜드 공식 원문 13개에서 정규화한 근거 42개이며, 정답 근거는 평가 파일에 사람이 직접 표시했습니다. 모델은 정답 식별자를 보지 않았고, 정답 정보는 검색이 끝난 뒤 지표를 계산할 때만 사용했습니다.
첫 번째 실험에서는 사람이 작성한 기본 질문 60개를 사용했습니다. 질문마다 Vertex AI RAG Engine에서 후보를 20개까지 가져오고, 같은 후보군을 semantic-ranker-default-004로 재정렬했습니다. 이 모델은 임베딩 모델이 아니라 질문과 각 후보 문단을 함께 읽고 관련도 점수를 다시 매기는 재정렬 모델입니다.
| 기본 질문 60개 | 재정렬 전 | 재정렬 후 | 변화 |
|---|---|---|---|
| MRR@5 | 96.39% | 97.50% | +1.11%p |
| nDCG@5 | 97.32% | 98.15% | +0.83%p |
| Recall@20 | 100.0% | 100.0% | 0.0%p |
| 인용 정확도@5 | 100.0% | 100.0% | 0.0%p |
기본 질문에서는 재정렬이 정답을 처음 찾는 능력보다 정답을 더 앞에 배치하는 순위를 개선했습니다. 하지만 이 결과만으로 복합 질문의 근거를 충분히 모은다고 볼 수는 없었습니다. 그래서 서로 다른 문서의 근거가 함께 필요한 질문, 부정 표현이 포함된 질문, 표현이 모호한 질문 30개를 별도로 만들었습니다.
복합 질문에서는 재정렬이 첫 번째 정답 근거를 앞에 두는 동안 두 번째와 세 번째 근거를 상위 결과 밖으로 밀어내는 사례가 확인됐습니다. 재정렬 전 97.22%였던 Recall@3이 재정렬 후 92.78%로 낮아졌습니다. 이는 재정렬 모델이 나쁘다는 뜻이 아니라, 여러 주장을 한 번의 검색 순위로 처리하는 방식에 한계가 있다는 뜻입니다.
후속 실험에서는 Gemini가 한 질문을 최대 네 개의 독립적인 검색 질의로 나누도록 했습니다. 각 질의는 Vertex AI RAG Engine에서 별도로 후보를 찾고 같은 재정렬 모델을 통과했습니다. 마지막에는 한 질의의 결과가 상위 자리를 독점하지 않도록 각 질의의 1위 근거를 먼저 한 개씩 담고, 그다음 순위 근거를 같은 방식으로 합쳤습니다. 정답 식별자는 이 과정에 사용하지 않았습니다.
| 복합 질문 30개 | 재정렬만 적용 | 질의 분해 후 | 변화 |
|---|---|---|---|
| Hit@5 | 100.0% | 100.0% | 0.0%p |
| MRR@5 | 97.78% | 98.33% | +0.56%p |
| nDCG@5 | 95.95% | 98.39% | +2.45%p |
| Recall@3 | 92.78% | 98.89% | +6.11%p |
| Recall@5 | 98.89% | 100.0% | +1.11%p |
| 필요한 근거를 상위 5개에서 모두 확보한 질문 | 96.67% | 100.0% | +3.33%p |
| 인용 정확도@5 | 100.0% | 100.0% | 0.0%p |
30개 입력은 53개의 검색 질의로 늘어났습니다. 전체 처리 시간은 평균 3.093초였고, 이 가운데 Gemini의 질의 분해가 평균 2.208초를 차지했습니다. 또한 하나의 근거만 필요한 질문 6개도 불필요하게 두 개 이상으로 나뉘었습니다. 따라서 질의 분해를 운영 기본값으로 바로 적용하지는 않았습니다. 다음 단계에서는 먼저 질문이 실제로 여러 주장을 포함하는지 판단한 뒤, 복합 질문에만 질의 분해를 적용해야 합니다.
이번 결과는 질문을 잘게 나누는 기능이 무조건 우수하다는 결론이 아닙니다. 복합 질문에서는 필요한 근거의 누락을 줄였지만, 단순 질문에서는 비용과 지연을 불필요하게 늘릴 수 있다는 사실도 함께 확인했습니다. 다음으로 측정할 항목은 복합 질문 판별 정확도, 검색된 문단이 실제 판단에 사용되는 근거 채택률, 15개 운영 시나리오의 종단 성공률, 역할별 Agent의 p50과 p95 응답 시간 및 토큰 사용량입니다. 현재 확인된 35개 회귀 평가와 RAG 오프라인 평가는 구현 안정성과 제한된 검색 범위를 보여주는 자료이며, 실제 사용자 성공률을 뜻하지 않습니다.
3. Advanced RAG
CaffeMate의 RAG는 창업 조건을 묻는 질문에 공식 자료를 찾아 연결하는 역할을 합니다. 사용자가 컴포즈커피 창업을 검토한다면 Vertex AI RAG Engine은 정보공개서와 본사의 가맹 안내에서 관련 문단을 찾아옵니다. 복합 질문을 개인 가맹 가능 여부, 초기 투자비, 본사 부담금, 출점 조건처럼 여러 검색 질의로 나누는 방식은 운영 경로와 분리한 실험에서 검증했습니다.
처음 검색한 문단이 모두 같은 가치를 갖는 것은 아닙니다. 브랜드 이름이 들어갔다는 이유만으로 메뉴 소개나 홍보 문구가 함께 검색될 수 있기 때문입니다. CaffeMate는 semantic-ranker-default-004를 사용해 검색된 문단의 순서를 다시 정합니다. 이 모델은 문서를 벡터로 바꾸는 임베딩 모델이 아닙니다. 임베딩 검색이 먼저 넓게 찾은 후보를 질문과 다시 비교하고, 각 후보에 관련도 점수를 매기는 재정렬 모델입니다. 예를 들어 “개인 가맹이 가능한가”라는 질문에는 매장 소개보다 가맹 자격과 계약 조건을 설명한 문단을 위로 올립니다. 이 과정을 거치면 Agent가 읽어야 할 자료의 양은 줄고, 답과 직접 관련된 문단은 앞쪽에 배치됩니다.
검색된 문단의 출처도 확인합니다. CaffeMate에는 정부 사이트에서 수집한 창업 절차 자료와 각 브랜드 본사가 공개한 가맹 자료가 등록되어 있습니다. 검색 결과에 등록된 공식 원문 주소와 문서 식별 정보가 남아 있고, 현재 질문의 브랜드와 자료 범위가 맞을 때만 창업 판단의 근거 후보로 사용합니다. 출처를 다시 찾을 수 없거나 다른 브랜드의 내용이 섞인 문단은 결과에서 제외합니다. Evidence Researcher는 남은 자료가 현재 질문과 관련 있는지, 자료의 기준일과 대상 브랜드가 맞는지를 한 번 더 확인합니다.
질의 분해 실험에서는 원래 질문을 그대로 검색하는 방식과 질문을 하위 주장으로 나누는 방식을 같은 30개 질문으로 비교했습니다. 각 하위 질의는 독립적으로 검색과 재정렬을 거쳤고, 결과를 합칠 때는 각 질의의 첫 번째 근거를 우선 보존했습니다. 이 방식은 한 문서의 근거만 반복해서 상위에 나타나는 현상을 줄였습니다. 다만 단순 질문까지 나누는 과분해가 확인됐기 때문에, 현재 운영 기능으로 확정하지 않고 복합 질문 판별 조건을 추가로 검증하고 있습니다.
상권 수치는 다른 방식으로 가져옵니다. 사용자가 희망 동네를 선택하면 주소를 행정동 코드로 바꾸고, MCP가 그 코드를 BigQuery 조회 조건으로 전달합니다. BigQuery에는 수집 시점과 지역 코드가 정리된 상권 자료가 들어 있습니다. 조회 결과로 카페 수, 신규 신고와 폐업 신고, 추정 매출, 유동인구, 거주인구, 직장인구가 반환되며 각 값에는 단위와 기준일이 붙습니다. 따라서 Agent가 문서 속 숫자를 읽고 다시 계산하지 않아도 됩니다.
정리하면 RAG는 법령, 정보공개서, 가맹 조건처럼 문맥을 읽어야 하는 자료를 담당하고, BigQuery는 지역별 수치를 담당합니다. CaffeMate는 두 결과를 같은 근거 형식으로 묶어 Proposal Agent에 전달합니다. Agent는 이 근거 안에서 후보를 설명하고, 자금 계산과 조건 판정은 Backend 코드가 수행합니다. 현재 공식 자료는 정부의 커피전문점 창업 절차와 컴포즈커피, 메가MGC커피, 이디야커피의 가맹 안내를 중심으로 구성되어 있으며, 같은 방식으로 브랜드와 자료 범위를 추가할 수 있습니다.
4. AI Evaluation
CaffeMate의 평가는 문장이 자연스러운지만 확인하지 않습니다. 지역 범위 오류, 오래된 자료, 비용 누락, 자금 초과, 개인 가맹 불가 브랜드, 평균 매출의 오용, 문서 간 숫자 충돌, 프롬프트 주입, 다른 프로젝트의 자료 혼입처럼 실제 서비스에서 위험한 실패를 사례로 만들었습니다. 각 사례는 입력, 기대 동작, 금지 동작, 필요한 근거, 통과 조건을 갖습니다.
CaffeMate는 35개의 고가치 평가 사례를 정의했으며, 최신 오프라인 평가에서 35개가 모두 자동 검사 조건을 통과했습니다. 이 수치는 사용자 만족도나 실제 창업 성공률을 뜻하지 않습니다. 반복해서 발생할 수 있는 실패를 자동으로 검사하고 있다는 뜻입니다.
평가 목적에 따라 자료도 분리했습니다. 35개 고가치 회귀 사례는 서비스 규칙이 다시 깨지는지 확인하고, RAG 평가는 공식 문서를 실제로 찾고 순서를 정하는 품질을 측정합니다. 기본 검색 질문 60개와 복합·모호 질문 30개를 사용했으며, 복합 질문에서는 재정렬만 적용한 방식과 질의 분해를 추가한 방식을 같은 조건에서 비교했습니다.
| 평가 묶음 | 사례 수 | 주요 지표 | 현재 확인한 결과 |
|---|---|---|---|
| 고가치 회귀 평가 | 35개 | 자동 통과율 | 35/35 통과 |
| 기본 RAG 검색 평가 | 60개 | MRR@5, nDCG@5, Recall@20 | 재정렬 후 MRR@5 97.50%, nDCG@5 98.15% |
| 복합 질문 RAG 평가 | 30개 | Recall@3, Recall@5, 완전 근거 확보율 | 질의 분해 후 Recall@3 98.89%, 상위 5개 완전 근거 확보율 100% |
| 질의 분해 지연 시간 | 30개 | 평균, p95 | 전체 평균 3.093초, p95 3.814초 |
실제 평가 사례는 다음과 같습니다. 정상 입력만 반복하지 않고, 서비스가 잘못된 추천을 만들기 쉬운 상황을 중심으로 구성했습니다.
| ID | 평가 사례 | 검사 영역 | 최신 결과 |
|---|---|---|---|
| EV-001 | 같은 이름을 가진 여러 행정구역을 구분하는가 | 상권 근거 | 통과 |
| EV-002 | 중복된 카페 자료를 두 번 집계하지 않는가 | 상권 근거 | 통과 |
| EV-003 | 매출과 유동인구 자료가 없을 때 수치를 만들지 않는가 | 재무와 후보 | 통과 |
| EV-004 | 전체 비용이 자기자금을 넘으면 이를 명확히 표시하는가 | 재무와 후보 | 통과 |
| EV-005 | 브랜드 비용 일부가 빠졌을 때 확정 비용으로 제시하지 않는가 | 재무와 후보 | 통과 |
| EV-006 | 개인 가맹 가능 여부를 확인하지 못한 브랜드를 확정 추천하지 않는가 | 재무와 후보 | 통과 |
| EV-007 | 직영점만 운영하는 브랜드를 개인 창업 후보에서 제외하는가 | 재무와 후보 | 통과 |
| EV-008 | 정보공개서의 평균 매출을 신규 점포 예상 매출로 바꾸지 않는가 | Agent 계약 | 통과 |
| EV-009 | 참고 비용만으로 필요한 고객 수를 확정하지 않는가 | 재무와 후보 | 통과 |
| EV-010 | 결과가 나오기 전 피드백을 조건 변경으로 처리하지 않는가 | 상태 변경 | 통과 |
| EV-011 | 사용자가 확인하기 전에 결과 상태를 바꾸지 않는가 | 상태 변경 | 통과 |
| EV-012 | 다른 프로젝트의 문서가 현재 결과에 섞이지 않는가 | RAG 범위 | 통과 |
| EV-013 | 조회일만 새롭고 자료 기준일이 오래된 경우를 구분하는가 | RAG 범위 | 통과 |
| EV-014 | 업로드한 문서 안의 프롬프트 주입 문장을 명령으로 실행하지 않는가 | 문서 처리 | 통과 |
| EV-015 | 두 문서의 로열티 수치가 충돌하면 이를 표시하는가 | 문서 처리 | 통과 |
| EV-016 | Agent 응답이 정해진 형식을 어기면 저장하지 않는가 | Agent 계약 | 통과 |
| EV-017 | 추천할 수 있는 후보가 부족할 때 후보를 꾸며내지 않는가 | 재무와 후보 | 통과 |
| EV-018 | 문서 값이 바뀌면 영향을 받는 계산만 다시 수행하는가 | 문서 처리 | 통과 |
| EV-019 | 자료가 일부 부족한 후보를 조건부 순위로 구분하는가 | 재무와 후보 | 통과 |
| EV-020 | OCR 결과를 수정 가능한 폼으로 보여주고 한 번에 반영하는가 | 문서 처리 | 통과 |
| EV-021 | Agent Runtime 호출이 실패했을 때 오류 원인을 구분하는가 | Runtime | 통과 |
| EV-022 | Proposal Agent가 존재하지 않는 브랜드를 만들지 않는가 | Agent 계약 | 통과 |
| EV-023 | 근거 평가에서 같은 입력을 반복하거나 과도하게 추론하지 않는가 | Agent 계약 | 통과 |
| EV-024 | 잘못된 Agent 응답을 한 번만 수정하고 계속 실패하면 중단하는가 | Agent 계약 | 통과 |
| EV-025 | Control API와 Candidate Auditor가 같은 의미 계약을 사용하는가 | Agent 계약 | 통과 |
| EV-026 | 배포되지 않은 MCP 도구를 호출하지 않는가 | Agent 계약 | 통과 |
| EV-027 | Intent Agent가 제한 없이 길게 응답하거나 같은 요청을 반복하지 않는가 | Agent 계약 | 통과 |
| EV-028 | 사용자의 가능성 질문을 조건 변경 의사로 오해하지 않는가 | Agent 계약 | 통과 |
| EV-029 | 역할별 Agent가 정해진 추론 예산을 넘기지 않는가 | Agent 계약 | 통과 |
| EV-030 | 주소 조회 지연이 Agent 실행 오류처럼 보이지 않게 구분하는가 | 상권 근거 | 통과 |
| EV-031 | 자료 부족을 추천 후보가 없다는 뜻으로 오해하지 않는가 | Agent 계약 | 통과 |
| EV-032 | Agent 세션 왕복을 줄여도 역할 분리와 세션 정리가 유지되는가 | Runtime | 통과 |
| EV-033 | 모델의 제안과 Runtime이 보존해야 할 실행 정보를 분리하는가 | Agent 계약 | 통과 |
| EV-034 | 운영 문서 저장소와 Document Agent가 실제로 연결되는가 | 문서 처리 | 통과 |
| EV-035 | RAG 검색 결과가 실제 판단 근거와 결과 카드까지 전달되는가 | RAG 근거 연결 | 통과 |
각 사례는 연결된 자동 검사 묶음의 결과로 판정합니다. 따라서 이 표의 통과는 해당 실패 조건에 대한 회귀 검사가 성공했다는 뜻이며, 사례마다 Gemini 답변의 품질을 사람이 따로 채점했다는 뜻은 아닙니다.
프롬프트도 버전별로 비교합니다. 같은 입력과 같은 모델을 사용해 전송 성공, 출력 스키마, 의미 규칙, 후보 수, 적합도 축, 근거 항목, 응답 시간을 비교합니다. 현재 보고서에서는 Proposal Agent의 두 버전이 모두 계약을 통과했고, 새 버전의 한 차례 실행 시간이 더 짧았습니다. 한 번의 실행 결과이므로 통계적인 우월성으로 주장하지 않고, 회귀 여부를 빠르게 찾는 기준으로 사용합니다.
운영 경로 평가는 15개 합성 시나리오로 구성되어 있습니다. 세 가지 카페 선호와 다섯 가지 창업자 조건을 조합해 Database, MCP, Agent Runtime, Gemini, 결과 생성까지 실제 연결을 확인합니다. Vertex AI Pipeline은 이 평가를 반복 실행하고 전체 사례 수와 실패 수를 기록합니다.
5. AI Agent Engineering과 MCP
CaffeMate의 Agent는 자유롭게 대화하며 다른 Agent를 호출하는 구조가 아닙니다. Control API가 task_type, 입력 스키마, 출력 스키마, 프롬프트 버전, 프로젝트 경계, 상태 버전을 포함한 작업을 만들고, 관리형 Runtime의 Dispatcher가 정확히 한 역할에 전달합니다. Agent는 정해진 JSON 계약으로만 결과를 반환합니다. 이 구조는 모델의 추론 능력을 사용하면서도 호출 관계와 책임 범위를 코드로 추적할 수 있게 합니다.
Agent의 역할은 의도 해석, 근거 평가, 후보 제안, 후보 감사, 문서 분석, 결과 설명으로 나뉩니다. 각 역할은 서로 다른 프롬프트와 스키마를 사용합니다. 예를 들어 Proposal Agent는 후보의 성격과 다섯 가지 적합도 축을 제안하지만 창업비를 계산하거나 순위를 확정하지 못합니다. Candidate Auditor는 누락과 모순을 지적하지만 계산 결과나 저장 상태를 덮어쓰지 못합니다.
MCP는 단순한 문서 검색기가 아니라, 여러 데이터 공급자를 같은 방식으로 호출하기 위한 읽기 전용 데이터 접근 계층입니다. 상권 수치가 필요하면 BigQuery 조회 도구를 실행하고, 가맹 조건이나 공식 절차가 필요하면 RAG 검색 도구를 실행합니다. 프로젝트에 업로드된 문서를 읽는 작업도 MCP를 통해 요청할 수 있습니다. 각 도구는 결과와 함께 출처, 기준일, 대상 지역이나 브랜드를 공통 형식으로 반환합니다.
MCP는 자료를 가져오는 역할까지만 담당합니다. 어떤 브랜드를 추천할지 판단하지 않으며, 비용을 계산하거나 순위를 정하지도 않습니다. 결과를 저장할 권한도 없습니다. Control API가 현재 작업에 필요한 자료를 MCP에 요청하고, 반환된 자료를 확인한 뒤 Agent와 계산기에 전달합니다. 이렇게 하면 Agent가 BigQuery, RAG, 문서 저장소마다 다른 호출 방법을 알 필요가 없고, 데이터 공급자가 바뀌어도 Agent의 역할은 그대로 유지됩니다.
이 설계의 핵심은 Agent에게 많은 권한을 주는 것이 아니라, 의미 판단이 필요한 지점에만 Agent를 배치하는 것입니다. 계산, 순위, 상태 전이는 일반 코드가 처리하고, 자료의 관련성 판단과 후보 설명처럼 규칙만으로 다루기 어려운 부분에 Gemini를 사용합니다.
6. Multi-Agent Architecture
첫 창업안 생성에서 핵심 역할은 Evidence Researcher, Proposal Agent, Candidate Auditor입니다. Evidence Researcher는 MCP와 RAG가 가져온 자료 중 현재 판단에 사용할 수 있는 근거를 가립니다. Proposal Agent는 검증된 근거와 사용자 조건을 바탕으로 개인카페 또는 프랜차이즈 후보를 제안합니다. Candidate Auditor는 후보가 근거 범위를 넘어서지 않았는지, 알려지지 않은 값을 사실처럼 사용하지 않았는지, 사용자 자금과 운영 조건을 위반하지 않았는지 검토합니다.
세 Agent 사이에는 권한의 차이가 있습니다. Researcher는 자료를 채택할 수 있지만 후보를 확정하지 못합니다. Proposal Agent는 후보를 제안하지만 자금 계산과 순위를 확정하지 못합니다. Auditor는 문제를 지적하지만 결과를 직접 수정하지 못합니다. 최종 계산과 상태 저장은 Control API가 담당합니다. 역할의 이름보다 이 권한 분리가 멀티 Agent 구조의 정당성을 만듭니다.
처리 속도를 위해 서로 독립적인 조회와 후보 제안은 병렬로 실행합니다. MCP와 RAG 조회를 동시에 시작하고, 여러 후보의 Proposal 작업도 병렬로 처리할 수 있습니다. 반면 후보 계산, 조건 판정, 정렬은 순서가 바뀌면 결과가 달라질 수 있으므로 결정론적 코드에서 한 번만 수행합니다. 이 구성은 모든 일을 Agent에게 맡기는 방식보다 비용과 지연을 줄이고, 오류가 난 역할을 구분하기 쉽습니다.
7. Responsible AI와 Explainable AI
CaffeMate는 사용자를 대신해 계약, 결제, 대출, 본사 연락, 최종 창업 결정을 실행하지 않습니다. 시스템의 역할은 현재 확인된 자료로 어떤 후보를 검토할 수 있는지 보여주고, 아직 확인하지 못한 정보가 판단을 어떻게 바꿀 수 있는지 설명하는 것입니다. 법률적 안전이나 창업 성공을 확정하는 문장은 결과에 사용할 수 없습니다.
설명 가능성은 별도의 점수 하나로 표현하지 않습니다. 결과 카드에는 현재 판단, 사용한 근거, 가정, 알려지지 않은 값, 자료 기준일, 비용 범위, 판단을 바꿀 조건이 함께 표시됩니다. 자금 적합도, 운영 적합도, 사용자 선호 적합도, 상권 적합도, 근거 완성도라는 다섯 축은 Agent가 어떤 관점으로 후보를 제안했는지 보여줍니다. 최종 자금 계산과 조건 판정은 코드가 다시 수행합니다.
결과 설명 Agent는 사용자의 "왜 이 안을 먼저 보나요?"와 같은 질문에 현재 결과와 연결된 근거만 사용해 답합니다. 이 Agent는 새 자료를 검색하거나 계산을 바꾸거나 상태를 수정하지 않습니다. 설명과 조건 변경도 UI에서 분리되어 있습니다. 사용자가 이유를 묻는 행동이 창업 조건 변경으로 오해되지 않게 하기 위한 설계입니다.
근거의 원문 위치와 출처 식별자를 보존하므로 결과 문장에서 공식 원문으로 되돌아갈 수 있습니다. 평균 매출은 특정 점포의 예상 매출로 바꾸지 않고, 상권 집계는 개별 점포의 성공 확률로 표현하지 않습니다. 알려지지 않은 값은 0으로 채우지 않습니다. 이 원칙은 설명을 친절하게 만드는 동시에 과도한 확신을 줄입니다.
8. Guardrails
CaffeMate의 Guardrail은 모델 앞뒤에 금지 문구를 붙이는 방식에 머물지 않습니다. 인증, 프로젝트 격리, 출처 검증, 계산 규칙, 권한 경계, 사용자 확인을 여러 층으로 나눴습니다. 한 층이 잘못되더라도 곧바로 확정 상태가 오염되지 않도록 설계했습니다.
입력 단계에서는 Firebase 로그인 정보를 확인하고, 더 이상 유효하지 않은 로그인 정보도 거절합니다. 내부 서비스가 MCP에 자료를 요청할 때는 요청을 보낸 서비스의 신원과 현재 작업의 권한을 함께 확인합니다. 이 작업에 허용된 프로젝트와 도구만 사용할 수 있으므로, 다른 프로젝트의 문서나 결과가 잘못 섞이는 요청은 자료 조회 전에 거절됩니다.
근거 단계에서는 출처, 기준일, 대상 범위, 원문 위치를 확인합니다. 프롬프트 주입 문장이 공식 문서 안에 있어도 명령이 아니라 자료 내용으로 취급합니다. 개인 가맹 여부가 확인되지 않은 브랜드는 확정 추천으로 올리지 않으며, 정보공개서 평균 매출을 신규 점포의 예상 매출로 사용하지 않습니다.
결정 단계에서는 알려지지 않은 값을 0으로 바꾸지 않고, 자금 계산과 조건 판정을 Agent가 아닌 코드가 수행합니다. Agent와 MCP는 권위 상태를 직접 쓰지 못합니다. 계약, 송금, 대출, 고액 지출, 최종 창업 결정은 항상 사용자에게 남깁니다. Guardrail은 모델의 답을 무조건 막는 장치가 아니라, 잘못된 답이 확정 사실이나 실행으로 넘어가지 못하게 하는 구조입니다.
9. AI Backend와 Frontend UI/UX
Backend는 FastAPI와 Pydantic을 사용합니다. Cloud SQL PostgreSQL이 프로젝트와 워크플로의 권위 있는 상태를 저장하고, BigQuery가 지역 상권 집계를 제공합니다. Cloud Storage는 사용자가 올린 문서와 공식 자료를 보관합니다. Control API, Worker, MCP, Web은 Cloud Run에 분리해 배포하며, Agent는 관리형 Vertex AI Runtime에서 실행합니다.
외부에서 보는 흐름은 간단하게 유지했습니다. 사용자가 분석을 시작하면 Backend가 워크플로를 만들고, Frontend는 진행 상태를 조회한 뒤 완성된 결과를 가져옵니다. 내부에서는 여러 Agent와 도구가 움직이지만 사용자는 구현 단계 수를 알 필요가 없습니다. 오류가 생겼을 때도 내부 코드나 영어 상태값을 그대로 보여주지 않고, 무엇을 다시 확인해야 하는지 한국어로 안내합니다.
Frontend는 React, TypeScript, Vite로 구성되어 있습니다. 온보딩에서 희망 지역, 자기자금, 개인카페와 프랜차이즈 선호, 운영 방식을 입력합니다. 결과 화면은 후보의 판단 상태, 선택 이유, 상권 신호, 가맹 조건, 필요자금, 위험과 미확인 항목을 나눠 보여줍니다. 결과를 선택한 뒤에는 실제 점포 조건이나 문서를 넣어 임시 범위를 실제 값으로 교체할 수 있습니다.
문서 입력 화면은 PDF, JPG, PNG, DOCX를 받고, 추출된 값을 수정 가능한 폼으로 보여줍니다. 사용자는 모든 값에 확인 버튼을 누르지 않고, 비어 있거나 잘못 읽힌 값만 고친 뒤 계산에 반영할 수 있습니다. 자연어 대화도 결과 설명과 조건 변경을 구분합니다. 질문은 현재 판단의 이유를 설명하고, 조건 변경은 별도 동작으로 제안을 다시 만듭니다.
10. GitHub와 Cloud Build CI/CD
CaffeMate의 배포 기준은 GitHub의 main 브랜치입니다. 코드가 main에 반영되면 GitHub webhook이 Cloud Build를 시작하고, Cloud Build가 정확한 커밋을 다시 받아 변경 범위를 계산합니다. Frontend 변경과 Backend 변경을 구분해 필요한 이미지만 빌드하고 Artifact Registry에 올립니다.
Backend 변경이 있으면 데이터베이스 마이그레이션 작업을 먼저 갱신하고 실행한 뒤 API와 내부 Worker를 배포합니다. Frontend 변경은 Web 이미지를 빌드해 Cloud Run에 배포합니다. 배포 리소스에는 소스 리비전과 빌드 정보를 라벨로 남겨 어떤 코드가 운영 중인지 추적할 수 있습니다.
GitHub에서는 기능별 브랜치와 Pull Request로 변경 내용을 검토하고, main에 반영된 커밋을 배포 기준으로 사용합니다. 배포 단계는 Cloud Build가 담당합니다. Cloud Build는 변경된 영역을 확인해 필요한 서비스만 빌드하고 Cloud Run에 배포합니다. 협업 과정과 운영 배포를 분리했기 때문에 팀원은 GitHub에서 변경 이력을 확인하고, GCP에서는 실제 빌드와 배포 상태를 추적할 수 있습니다.
11. Vertex AI Pipelines
Vertex AI Pipelines는 사용자 요청을 처리하는 Backend 워크플로가 아니라, 품질 평가를 반복 실행하고 결과를 남기는 운영 자동화에 사용합니다. 서비스 기능과 평가 작업을 분리하면 평가 실패가 사용자 분석 요청을 막지 않으며, 같은 평가를 정해진 환경에서 다시 실행할 수 있습니다.
평가 파이프라인은 Cloud Run의 평가 작업을 실행하고, Cloud Storage에 저장된 결과에서 전체 사례 수와 실패 수를 확인합니다. 15개 운영 시나리오 가운데 하나라도 실패하면 평가를 통과시키지 않습니다. 사용자 분석 요청과 품질 평가를 분리했기 때문에 평가 작업에 문제가 생겨도 사용자의 창업 분석 요청은 계속 처리할 수 있습니다.
12. Prompt Version Control
프롬프트는 코드 안의 임의 문자열로 관리하지 않습니다. 각 Agent 작업은 프롬프트 버전, 입력 스키마, 출력 스키마, 모델, 추론 수준, 출력 토큰 한도를 registry에 등록합니다. 같은 task_type이라도 프롬프트 버전이 다르면 별도 릴리스 항목으로 추적됩니다.
릴리스할 때는 프롬프트 버전뿐 아니라 입력과 출력 형식, 모델, Agent Runtime, MCP, RAG 색인, 공식 자료 버전을 하나의 릴리스 정보로 묶습니다. 실행 결과에도 이 릴리스 정보를 남기므로, 문제가 발생했을 때 어떤 프롬프트와 자료를 사용했는지 다시 확인할 수 있습니다. 이전 작업의 응답이 현재 결과에 섞이지 않도록 작업 식별 정보도 함께 검사합니다.
프롬프트 변경은 같은 평가 입력으로 이전 버전과 비교합니다. 출력 JSON이 계약에 맞는지, 후보 수가 맞는지, 다섯 적합도 축과 근거 항목을 모두 채웠는지, 응답 시간이 어떻게 달라졌는지를 보고서로 남깁니다. 현재 프롬프트의 권위 원본은 Git으로 관리되는 TypeScript 코드와 릴리스 명세입니다. 별도의 Vertex Prompt 리소스를 원본으로 쓰는 구조는 아닙니다.
13. Vertex AI Agent Engine
CaffeMate는 Google ADK로 만든 Agent application을 Vertex AI의 관리형 Agent Runtime에 배포합니다. 각 실행에는 사용한 Runtime, 모델, 프롬프트 버전을 기록합니다. Control API는 Runtime 세션을 만들고 작업을 실행한 뒤 최종 응답을 확인하고 세션을 정리합니다.
관리형 Runtime 안에는 하나의 Dispatcher가 있고, 입력의 task_type에 따라 정확히 한 Agent 역할을 실행합니다. Agent끼리 자유롭게 대화를 이어가거나 서로를 재귀 호출하지 않습니다. 여러 역할을 연결하는 순서는 Control API의 파이프라인이 소유합니다. 덕분에 세션 관리와 모델 실행은 관리형 환경의 장점을 사용하면서도, 업무 흐름은 코드로 읽고 테스트할 수 있습니다.
Runtime은 의미 해석과 구조화된 제안만 담당합니다. MCP 도구를 직접 호출하거나 데이터베이스를 수정하지 않으며, 최종 자금 계산과 순위 결정에도 참여하지 않습니다. Agent Engine을 사용한 이유는 Agent에게 모든 권한을 주기 위해서가 아니라, 역할별 프롬프트와 세션, 모델 호출, 관측 정보를 관리형 환경에서 일관되게 운영하기 위해서입니다.
14. Google Cloud Trace
CaffeMate는 한 번의 사용자 요청이 Control API, MCP, Agent Runtime, Gemini를 거치는 동안 같은 추적 문맥을 유지합니다. FastAPI는 요청 시작 시 server span을 만들고, FIRST_PROPOSAL 파이프라인, MCP 호출, Agent Runtime 호출을 하위 span으로 기록합니다. W3C traceparent를 MCP header와 Agent 작업에 전달해 서비스가 달라도 같은 요청 흐름으로 볼 수 있습니다.
관리형 Agent Runtime도 OpenTelemetry를 사용합니다. 역할 dispatch와 Gemini 호출을 각각 span으로 만들고, 역할, 작업 유형, 프롬프트 버전, 스키마, 모델, 소스 리비전처럼 운영에 필요한 값만 attribute로 남깁니다. 서버리스 환경에서 응답 직후 CPU가 제한될 수 있으므로 반환 전에 trace exporter를 flush하도록 구현했습니다.
추적 정보에는 사용자의 원문, 문서 내용, 정확한 위치, 프로젝트 식별자, 세션 식별자, 토큰과 비밀값을 기록하지 않습니다. 관측 가능성을 높이는 과정에서 개인정보와 사업 자료가 로그로 복제되지 않게 하기 위한 원칙입니다.
배포 스크립트는 필요한 서비스 계정에 Trace 권한을 부여하고 Agent 호출 수, 모델 지연 시간, 모델 토큰 수를 위한 log-based metric과 "CaffeMate AgentOps" Monitoring dashboard를 만듭니다. Dashboard와 Trace Explorer 주소를 출력하고, 검증 스크립트가 dashboard 구성과 개인정보 비노출 안내를 다시 읽어 확인합니다. 코드와 자동화는 구현되어 있으며, 현재 운영 dashboard가 실제로 존재하는지는 발표 전 GCP에서 read-back한 화면을 증거로 남겨야 합니다.
15. Response Quality Enhancement
응답 품질은 더 긴 프롬프트를 쓰는 방식보다 역할과 근거를 정리하는 방식으로 높였습니다. Agent마다 입력과 출력 스키마를 분리하고, 공식 자료와 사용자 사실, 가정, 계산 결과, 알려지지 않은 값을 다른 필드에 담습니다. 모델이 자유 문장으로 비용과 순위를 만들지 못하게 하고, 설명에 필요한 의미 정보만 구조화해 반환하게 했습니다.
Proposal Agent는 자금 적합도, 운영 적합도, 사용자 선호 적합도, 상권 적합도, 근거 완성도를 같은 형식으로 제시합니다. Control API는 이 제안을 실제 비용 범위와 사용자 자금에 대조하고, 계산된 값을 다시 결과 카드에 넣습니다. Candidate Auditor는 근거 없는 브랜드, 누락 비용, 사용자 조건 위반을 별도로 점검합니다. 이 과정을 통해 문장은 모델이 만들더라도 판단의 뼈대는 검증 가능한 데이터와 코드에 남습니다.
컨텍스트도 무작정 모두 넣지 않습니다. Evidence Researcher에는 출처별로 고르게 선택한 근거 후보와 필요한 원본 참조를 전달하고, 전체 MCP 응답은 별도로 보존합니다. 모델이 처리해야 할 문맥은 줄이되, 나중에 누락 여부를 다시 확인할 수 있게 한 것입니다. 서로 독립적인 후보 생성은 병렬 실행해 응답 시간을 줄입니다.
프롬프트 버전 비교, 고가치 평가 사례, 운영 Trace를 함께 사용하면 품질 문제를 "모델이 이상했다"로 끝내지 않을 수 있습니다. 검색 결과가 부족했는지, 근거 채택에서 탈락했는지, Agent 출력이 계약을 위반했는지, 계산 단계에서 문제가 생겼는지 구분할 수 있습니다. 품질 개선은 이 구간별 측정에서 시작합니다.
16. Security Audit and Refinement
보안은 사용자 인증, 서비스 간 인증, 자료 격리, 모델 입출력 검사, 비밀 관리로 나눴습니다. 사용자 요청은 Firebase ID Token을 검증하고 폐기 여부까지 확인합니다. API, Worker, MCP는 서로 다른 서비스 계정을 사용합니다. 비밀값은 Secret Manager에서 주입하며 Frontend 코드나 저장소에 넣지 않습니다.
내부 서비스가 MCP를 호출할 때는 두 가지를 확인합니다. 먼저 Cloud Run이 요청을 보낸 서비스가 CaffeMate의 정식 서비스인지 확인합니다. 그다음 현재 작업에 사용할 수 있는 프로젝트, 워크플로, 도구가 적힌 짧은 유효기간의 작업 권한을 확인합니다. 예를 들어 A 프로젝트의 상권 분석 작업이 B 프로젝트의 문서를 읽으려고 하면, 서비스가 정상적으로 로그인되어 있어도 MCP가 요청을 거절합니다.
사용자가 올린 문서는 프로젝트별로 분리해 저장합니다. 문서를 읽을 때 사용하는 주소도 정해진 시간 동안만 유효합니다. 따라서 주소가 외부에 남거나 다른 작업에 잘못 전달되더라도 계속 사용할 수 없습니다. 이 구조는 한 번 인증된 내부 서비스가 모든 자료를 자유롭게 읽지 못하도록 접근 범위를 작업 단위로 줄입니다.
Agent 입출력에는 Model Armor 검사를 연결했습니다. 입력은 sanitizeUserPrompt, 출력은 sanitizeModelResponse를 사용하며, 서울 리전의 지정된 template과 정확히 일치하는지 확인합니다. 현재 template은 SDP 검사를 사용하는 INSPECT_ONLY 방식입니다. 개인정보 가능성을 찾고 안전한 요약 지표를 남기지만, 내용을 자동 차단하는 정책은 아닙니다. 따라서 발표에서는 "Model Armor로 Agent 경계의 민감정보를 관측한다"고 설명해야 하며, "모든 유해 입력을 차단한다"고 말하면 안 됩니다.
보안 로그에는 원문을 남기지 않고 검사 결과의 안전한 요약만 기록합니다. 배포 스크립트는 Model Armor 사용 권한과 조회 권한을 서비스 계정에 부여하고 API 환경 변수를 설정합니다. 검증 스크립트는 template, IAM, API 설정을 다시 읽고 별도 검증 작업을 실행합니다. 현재 운영 리소스의 적용 상태는 발표 전에 GCP read-back 결과로 확인해야 합니다.
17. 발표에서 강조할 문제 해결 방식
CaffeMate의 기술 선택은 기능 수를 늘리기 위한 것이 아닙니다. 카페 창업 자료는 출처와 기준일이 다르고, 상권 수치는 특정 점포의 매출을 보장하지 않으며, 프랜차이즈 자료에는 개인 가맹 가능 여부와 아직 확인되지 않은 조건이 섞여 있습니다. 언어 모델 하나에 검색, 계산, 판단, 설명을 모두 맡기면 잘못된 문장이 곧 잘못된 결정이 될 수 있습니다.
그래서 공식 자료는 Advanced RAG와 MCP로 가져오고, Evidence Researcher가 사용 범위를 확인합니다. Proposal Agent는 여러 가능성을 제안하며, 계산기는 비용과 자금 조건을 다시 계산합니다. Candidate Auditor는 결과가 근거를 넘어섰는지 확인합니다. Prompt Version Control과 Evaluation은 변경 뒤 품질 회귀를 찾고, Cloud Trace는 운영 중 어느 구간에서 문제가 생겼는지 보여줍니다. Model Armor와 권한 경계는 사용자 자료가 Agent 경계를 지날 때 생길 수 있는 위험을 줄입니다.
이 구조의 장점은 모델이 항상 완벽하다고 가정하지 않는다는 점입니다. 모델이 의미 판단에서 도움을 주되, 결과를 확정하는 권한은 갖지 않습니다. 근거가 부족하면 부족하다고 표시하고, 실제 점포와 문서가 들어오면 같은 상태를 갱신해 다시 계산합니다. CaffeMate가 제공하는 가치는 정답을 대신 선언하는 것이 아니라, 사용자가 다음 결정을 더 정확하게 내릴 수 있도록 자료와 판단 과정을 연결하는 데 있습니다.
18. 구현 상태를 정확하게 말하는 방법
| 발표 항목 | 확인된 구현 범위 | 발표에서 사용할 표현 |
|---|---|---|
| Advanced RAG | 공식 절차와 세 개 브랜드 자료의 검색, 재정렬, 근거 변환을 구현하고 공식 원문 13개에서 만든 근거 42개로 질의 분해 실험 수행 | 제한된 공식 자료를 출처 추적 가능한 근거로 연결했고, 복합 질문의 Recall@3을 92.78%에서 98.89%로 개선했습니다. 질의 분해는 아직 운영 기본값으로 적용하지 않았습니다. |
| AI Evaluation | 고가치 사례 35개, RAG 질문 90개, 운영 시나리오 15개 구현 | 규칙 회귀 평가와 검색 품질 평가를 분리하고, 검색 순위와 근거 누락을 수치로 비교했습니다. |
| Multi-Agent | Researcher, Proposal, Auditor와 결정론적 계산 연결 | Agent별 책임과 권한을 분리하고 최종 계산은 코드가 담당합니다. |
| Vertex AI Pipelines | 파이프라인 코드, 컴파일 명세, 제출 스크립트 구현 | 운영 평가 자동화 파이프라인을 구현했습니다. 성공 실행 기록은 GCP에서 별도 확인합니다. |
| Prompt Version Control | Git 기반 프롬프트 버전과 릴리스 정보 구현 | 프롬프트, 스키마, 모델, RAG 자료 버전을 한 릴리스로 관리합니다. |
| Vertex AI Agent Engine | ADK application과 관리형 Runtime 연결 구현 | 역할별 Agent를 관리형 Runtime에서 실행합니다. |
| Google Cloud Trace | API, MCP, Agent, Gemini trace 연결과 dashboard 자동화 구현 | 한 요청의 서비스 간 흐름을 같은 trace로 추적하도록 구현했습니다. |
| Security | 인증, 범위 토큰, Model Armor inspect-only 구현 | 서비스 권한을 분리하고 Agent 입출력의 민감정보 신호를 관측합니다. |
| CI/CD | GitHub webhook과 Cloud Build 배포 구현 | GitHub main 변경을 Cloud Build가 빌드하고 Cloud Run에 배포합니다. |
19. 발표에서 피해야 할 표현
전국 모든 프랜차이즈와 지역 자료를 이미 확보했다고 말하면 안 됩니다. 현재 공식 RAG 자료 범위는 제한되어 있습니다. "공식 자료를 지속해서 추가할 수 있는 색인과 근거 변환 구조를 만들었다"는 표현이 맞습니다.
Model Armor가 모든 개인정보와 공격을 차단한다고 말하면 안 됩니다. 현재 설정은 inspect-only이며, 민감정보 신호를 관측하는 역할입니다. 실제 차단 여부는 별도의 정책 결정이 필요합니다.
Vertex AI Pipeline, Trace dashboard, Model Armor가 현재 운영에 완전히 적용됐다고 발표하려면 GCP console 또는 검증 스크립트의 read-back 증거가 필요합니다. 코드와 자동화가 존재한다는 사실과, 현재 운영 리소스가 확인됐다는 사실은 구분해야 합니다.
오프라인 평가 35개 통과를 실제 사용자 성공률로 해석하면 안 됩니다. 이 결과는 정해진 실패 사례에 대한 회귀 검사 결과입니다. 실제 제품 성과는 별도의 사용자 평가와 운영 데이터로 확인해야 합니다.
20. 마무리 발표문
CaffeMate는 Gemini에게 카페 창업 답변을 한 번에 맡기지 않았습니다. 공식 자료를 찾는 RAG, 구조화된 데이터를 읽는 MCP, 자료의 사용 가능성을 판단하는 Evidence Researcher, 후보를 만드는 Proposal Agent, 결과를 다시 살피는 Candidate Auditor를 연결했습니다. 자금 계산과 순위는 일반 코드가 담당하고, Control API만 상태를 확정합니다.
품질을 유지하기 위해 프롬프트와 스키마, 모델, RAG 색인을 릴리스 단위로 관리하고, 고가치 실패 사례와 운영 시나리오를 자동 평가합니다. Cloud Trace는 한 요청이 API, MCP, Agent Runtime, Gemini를 지나는 과정을 연결해 보여주며, Model Armor와 범위 기반 인증은 Agent 경계와 서비스 간 통신을 점검합니다.
결국 CaffeMate의 핵심은 더 많은 Agent가 아니라 더 분명한 책임입니다. 모델은 해석하고 제안하며 설명합니다. 데이터 계층은 출처를 보존합니다. 계산기는 결과를 재현합니다. Control API는 권한과 상태를 관리합니다. 사용자는 근거와 미확인 항목을 확인한 뒤 최종 결정을 내립니다. 이 역할 분리가 CaffeMate의 AI 기능을 실제 창업 검토 과정에 사용할 수 있게 만드는 기술적 기반입니다.