Spring AI 학습 로드맵과 버전 선택
3줄 요약
- Spring AI는 Spring Boot 애플리케이션에서 LLM, embedding, vector store, tool, MCP, observability를 Spring 방식으로 연결하는 프레임워크다.
- 이 폴더는 Spring AI 2.0.x와 Spring Boot 4.x를 본류로 삼고, Boot 3.x와 Spring AI 1.x는 기존 서비스 호환성 판단으로 다룬다.
- 입문자는 첫 ChatClient 호출에서 시작하고, 고급자는 운영 가능한 RAG, tool, MCP, eval, 장애 대응까지 설명할 수 있어야 한다.
핵심 정리
- 상세 문서: 01. Spring AI 학습 로드맵과 버전 선택.md
- 학습 순서는 버전 선택, 첫 호출, 계층 설계, 설정, prompt/context/advisor, structured output, tool, MCP, RAG, eval, observability, production readiness, capstone으로 간다.
- Spring AI는 모델 품질을 대신 보장하지 않는다. 호출 경계와 Spring 통합을 구조화할 뿐이다.
- 최신 Spring AI 예제는 Boot 4.x 기준일 수 있으므로 기존 Boot 3.x 서비스에 바로 적용하기 전에 호환성을 확인한다.
- OpenAI를 기본 provider로 보고, Ollama는 개인 실습과 로컬 fallback 감각을 익히는 보조 경로로 둔다.
- 졸업 기준은 단순 호출이 아니라 테스트, 비용, 보안, 인프라 협업, 장애 런북까지 초안 작성할 수 있는 수준이다.
헷갈리는 지점
- Spring AI를 배우면 AI 애플리케이션 전체를 다 배운다고 생각하기 쉽다. Spring 이름이 익숙하기 때문이다.
- 핵심은 Spring AI는 Spring 백엔드 안에서 AI 기능을 운영 가능하게 붙이는 도구라는 점이다.
- 모델 선택, 데이터 품질, eval, 보안, 비용 관리는 별도 역량으로 같이 배워야 한다.
- 최신 버전만 보면 된다고 생각하기 쉽다. AI 생태계 변화가 빠르기 때문이다.
- 핵심은 실무 서비스의 Spring Boot 버전과 조직 표준 Java 버전이 더 느리게 움직인다는 점이다.
- 최신 학습과 운영 적용 버전을 분리해 판단해야 한다.
확인 질문
- 이 폴더의 최종 졸업 기준은 무엇인가?
- Spring AI 기능을 설계, 구현, 테스트, 관측, 운영 런북까지 작성할 수 있는 백엔드 개발자 수준이다.
- Boot 3.x 서비스에서 Spring AI 2.0 예제를 볼 때 가장 먼저 확인할 것은 무엇인가?
- Spring Boot, Java, Spring AI BOM, provider starter의 호환성이다.
개발 환경 구축과 첫 ChatClient
3줄 요약
- 첫 실습의 목표는 대단한 챗봇이 아니라 Spring Boot에서 AI 모델 호출 경계가 어떻게 생기는지 보는 것이다.
- OpenAI는 운영 감각을 익히기 좋고, Ollama는 비용 없이 로컬에서 반복 실습하기 좋다.
- 첫 호출부터 API key, timeout, 요청 크기, 실패 메시지를 의식해야 나중에 운영 코드로 자연스럽게 이어진다.
핵심 정리
- 상세 문서: 02. 개발 환경 구축과 첫 ChatClient.md
- Spring AI는 BOM과 starter로 의존성을 맞추고,
application.yml에서 provider property를 구성한다.
ChatClient.Builder를 주입받아 ChatClient를 만들고 prompt().user(...).call().content() 흐름으로 첫 호출을 확인한다.- OpenAI 설정은
spring.ai.openai.api-key, spring.ai.openai.chat.model처럼 provider별 공식 property를 따른다.
- Ollama는 로컬 모델 다운로드, 실행 상태, 모델 이름 불일치가 초보자 오류의 대부분이다.
- 첫 호출이 성공하면 바로 Controller에 붙이기보다 작은 service로 감싸 예외와 로그를 다루기 시작한다.
헷갈리는 지점
- 샘플처럼 Controller에서 바로
ChatClient를 호출해도 된다고 생각하기 쉽다. 첫 실습은 그렇게 보여주기 때문이다.
- 핵심은 샘플의 단순함과 운영 코드의 경계는 다르다는 점이다.
- 첫 호출 이후에는 service/gateway로 분리해야 테스트와 장애 대응이 쉬워진다.
- Ollama가 되면 운영도 로컬 모델로 충분하다고 생각하기 쉽다. 비용이 들지 않기 때문이다.
- 핵심은 로컬 모델은 latency, 품질, GPU, 메모리, 보안 업데이트, serving 운영 책임을 만든다는 점이다.
- 개인 실습과 기업 운영의 기준을 나눠야 한다.
확인 질문
- 첫 ChatClient 실습에서 반드시 확인해야 할 것은 무엇인가?
- 의존성, provider 설정, API key 또는 로컬 모델, 첫 요청 성공, 실패 시 오류 메시지, 호출 경계다.
- OpenAI와 Ollama를 함께 다루는 이유는 무엇인가?
- OpenAI로 managed provider 운영 감각을 익히고, Ollama로 비용 없는 반복 실습과 로컬 실행의 제약을 이해하기 위해서다.
Spring Boot 계층 설계와 AI Gateway
3줄 요약
- Spring AI 호출은 Controller가 아니라 application service와 AI gateway 경계 뒤에 두는 편이 안전하다.
- AI gateway는 provider 호출, prompt version, model profile, 예외 변환, 사용량 기록, fallback의 중심 경계다.
- 이 경계를 만들면 Spring AI를 쓰다가 plain SDK나 다른 provider로 바꿔도 업무 서비스가 덜 흔들린다.
핵심 정리
- 상세 문서: 03. Spring Boot 계층 설계와 AI Gateway.md
- Controller는 HTTP 계약, service는 유스케이스와 정책, gateway는 AI 호출과 관측성을 맡는다.
- AI 호출은 결제 API나 문자 API 같은 외부 시스템 호출로 보고 timeout, retry, rate limit, circuit breaker를 고려한다.
- 내부 DTO는 provider 원본 응답을 그대로 노출하지 않는다.
- prompt version, model profile, tenant/user, trace id를 gateway 경계에서 묶어 기록한다.
- 운영에서는 fallback도 gateway 정책으로 관리한다.
헷갈리는 지점
- Spring bean으로 주입받으면 내부 의존성처럼 안정적이라고 느끼기 쉽다.
- 핵심은 AI provider는 네트워크, quota, 정책 변경, 비용, latency를 가진 외부 시스템이라는 점이다.
- Spring bean은 주입 방식일 뿐 운영 안정성을 보장하지 않는다.
- provider 교체를 인터페이스 하나로 해결할 수 있다고 생각하기 쉽다.
- 핵심은 provider 교체는 코드 컴파일보다 품질, 비용, latency, safety, tool 동작의 regression 문제라는 점이다.
확인 질문
- AI gateway를 두는 이유는 무엇인가?
- provider 호출, 예외 변환, 사용량 기록, prompt/model version, fallback, 테스트 double을 한 경계에서 관리하기 위해서다.
- Controller가 AI 호출 세부사항을 알면 어떤 문제가 생기는가?
- HTTP 계약과 provider 정책이 섞여 테스트, 변경, 장애 대응이 어려워진다.
ChatClient Model Auto Configuration
3줄 요약
ChatClient는 애플리케이션 친화적인 fluent API이고, ChatModel은 provider 호출 추상화다.- auto-configuration은 편하지만 설정 책임과 운영 책임을 대신 정해주지는 않는다.
- model profile을 두면 기능 코드가 물리 모델명과 provider option에 직접 묶이지 않는다.
핵심 정리
- 상세 문서: 04. ChatClient Model Auto Configuration.md
- Spring AI starter는 provider별 model bean과 builder를 구성한다.
- 기능별
ChatClient bean을 만들면 system prompt, advisor, output format, tool 정책을 분리하기 쉽다.
- Spring AI 2.0에서는 OpenAI chat 설정을
spring.ai.openai.chat.model, spring.ai.openai.chat.temperature처럼 다룬다.
- retry는 provider retry와 API 전체 retry가 겹치지 않도록 조심한다.
- 모델 옵션은 코드 하드코딩보다 profile, property, feature flag, admin config로 관리하는 편이 안전하다.
헷갈리는 지점
ChatClient가 같으면 결과도 비슷할 것이라고 생각하기 쉽다.
- 핵심은 builder 기본값, advisor, tool, structured output, model option에 따라 완전히 다른 기능이 된다는 점이다.
- 기능별 client 구성이 필요하다.
temperature=0이면 테스트가 항상 deterministic하다고 생각하기 쉽다.
- 핵심은 provider 정책, 모델 버전, context, tool 결과가 바뀌면 응답이 달라질 수 있다는 점이다.
확인 질문
ChatClient와 ChatModel을 구분해야 하는 이유는 무엇인가?
- 애플리케이션 API와 provider 호출 추상화의 책임이 다르기 때문이다.
- model profile을 두면 어떤 운영 작업이 쉬워지는가?
- 모델 교체, A/B 테스트, rollback, 기능별 비용/품질 비교가 쉬워진다.
Prompt Context Advisor Memory 설계
3줄 요약
- Spring AI의 prompt, advisor, memory는 prompt engineering을 넘어 context engineering과 harness engineering을 구현하는 지점이다.
- Advisor는 모델 호출 전후에 context, memory, RAG, logging, safety 같은 반복 패턴을 삽입한다.
- Memory는 사용자 경험을 좋게 만들지만 개인정보, 권한, 토큰 비용, 대화 오염을 함께 만든다.
핵심 정리
- 상세 문서: 05. Prompt Context Advisor Memory 설계.md
- prompt template은 고정 instruction과 동적 input/context를 분리한다.
- context assembler는 검색, 권한, 최신성, token budget, source format을 다룬다.
- advisor ordering은 결과 품질과 보안에 영향을 준다.
- Spring AI memory advisor는
ChatMemory.CONVERSATION_ID를 명시해야 한다.
- prompt, context policy, advisor chain, model profile, index version을 함께 추적하면 장애 분석이 쉬워진다.
헷갈리는 지점
- prompt template을 잘 쓰면 context engineering이 끝난다고 생각하기 쉽다.
- 핵심은 context engineering은 어떤 정보를 어떤 권한과 비용 안에서 넣을지 결정하는 일이라는 점이다.
- 템플릿은 마지막 표현 방식일 뿐이다.
- memory를 켜면 항상 좋아진다고 생각하기 쉽다.
- 핵심은 잘못된 답변, 오래된 정보, 민감정보, injection 문구도 memory에 남을 수 있다는 점이다.
- TTL, 삭제, 요약, 격리 정책이 필요하다.
확인 질문
- Advisor를 조심해야 하는 이유는 무엇인가?
- 실행 순서와 책임이 섞이면 권한 누락, 비용 증가, 디버깅 난도가 생기기 때문이다.
- Memory에서 conversation id가 중요한 이유는 무엇인가?
- 대화 이력을 사용자/테넌트별로 격리하고 권한이 다른 대화가 섞이지 않게 하기 위해서다.
Structured Output과 Bean Validation
3줄 요약
- Structured output은 모델 응답을 DTO로 받는 기술이지만, JSON 파싱 성공이 업무 안전성을 뜻하지는 않는다.
- Bean Validation과 업무 rule 검증을 함께 써야 모델 출력이 서버 상태 변경으로 이어져도 안전하다.
- 실패 시 재시도, fallback, human review 중 무엇을 택할지 기능별 정책이 필요하다.
핵심 정리
- 상세 문서: 06. Structured Output과 Bean Validation.md
- Spring AI는 모델 응답을 Java class나 record로 매핑하는 structured output 흐름을 제공한다.
- DTO는 작게 시작하고 enum, 길이, 범위, 필수값을 명확히 한다.
- Bean Validation은 형태와 값 범위를 잡고, 업무 rule은 정책 위반을 잡는다.
- invalid output은 같은 prompt로 무한 재시도하지 않는다.
- structured output은 tool calling 전에 안전한 중간 단계로 익히기 좋다.
헷갈리는 지점
- JSON schema를 쓰면 안전하다고 생각하기 쉽다.
- 핵심은 schema는 문법과 형태를 돕지만 권한, 정책, 업무 의미를 보장하지 않는다는 점이다.
- DTO 검증과 업무 검증이 필요하다.
- 모델이 confidence를 주면 그대로 믿어도 된다고 생각하기 쉽다.
- 핵심은 confidence도 모델 출력이며 calibration된 확률이 아닐 수 있다는 점이다.
- human review나 fallback 기준의 보조 신호로만 써야 한다.
확인 질문
- structured output 뒤에 Bean Validation을 붙이는 이유는 무엇인가?
- 모델이 형태를 맞춰도 필수값, 범위, 길이, enum, 업무 정책이 틀릴 수 있기 때문이다.
- invalid output이 발생하면 무엇을 결정해야 하는가?
- 재시도 여부, fallback 응답, human review 전환, 로그 샘플링, 사용자 메시지를 결정해야 한다.
3줄 요약
- Tool calling은 모델이 서버 기능을 호출하게 만드는 경계라서 API 설계보다 더 엄격하게 다뤄야 한다.
- read-only tool과 write tool은 권한, idempotency, 승인, 감사 로그 기준이 다르다.
- 모델 설명에 보안 정책을 맡기지 말고 서버 코드에서 검증해야 한다.
핵심 정리
- 상세 문서: 07. Tool Calling과 Side Effect 방어.md
- Spring AI tool API를 사용하면 Spring bean 메서드를 모델이 호출할 수 있는 tool로 노출할 수 있다.
- tool input에는 인증된 tenant/user context를 서버가 주입하거나 검증해야 한다.
- read-only tool은 조회 결과 DTO를 최소화하고, write tool은 idempotency key와 approval gate가 필요하다.
- provider retry와 application retry가 겹치면 같은 side effect가 두 번 실행될 수 있다.
- tool output은 다시 모델 context가 되므로 secret, 개인정보, 내부 entity를 그대로 반환하지 않는다.
헷갈리는 지점
- Tool은 그냥 함수 호출이라고 생각하기 쉽다.
- 핵심은 tool 호출이 DB 변경, 외부 API 호출, 메일 발송, 결제 같은 side effect로 이어질 수 있다는 점이다.
- 서버 API와 같은 보안/감사 기준이 필요하다.
- tool description에 금지사항을 적으면 안전하다고 생각하기 쉽다.
- 핵심은 description은 모델 힌트이고 보안 경계가 아니라는 점이다.
- 권한과 정책은 코드에서 검증해야 한다.
확인 질문
- read-only tool과 write tool을 분리해야 하는 이유는 무엇인가?
- 부작용, 재시도, 승인, 감사 로그, rollback 책임이 다르기 때문이다.
- tool 중복 실행을 막는 기본 장치는 무엇인가?
- idempotency key, execution id, 상태 저장, retry 정책 분리다.
MCP Client Server 통합
3줄 요약
- MCP는 tool, resource, prompt를 표준 방식으로 연결해 AI client와 외부 시스템의 접점을 만든다.
- Spring AI에서는 MCP client와 server 통합을 통해 외부 MCP server를 쓰거나 Spring 서비스를 MCP server로 노출할 수 있다.
- MCP는 연결 표준이지 보안 표준의 완성본이 아니므로 인증, 인가, 네트워크 경계, 감사 로그를 별도로 설계한다.
핵심 정리
- 상세 문서: 08. MCP Client Server 통합.md
- MCP client는 IDE, agent, 내부 운영 도구, 문서 시스템 같은 외부 tool/resource를 Spring AI 흐름에 연결할 때 유용하다.
- MCP server는 Spring 서비스의 read-only 운영 조회, 사내 문서 검색, ticket 조회 같은 기능을 표준 tool로 노출할 때 유용하다.
- 처음에는 read-only tool/resource 중심으로 시작한다.
- write operation은 승인, idempotency, rate limit, rollback 경로가 준비된 뒤 노출한다.
- 인프라팀과 MCP server 위치, transport, 인증, 로그, egress/ingress를 합의해야 한다.
헷갈리는 지점
- MCP를 쓰면 도구 통합이 자동으로 안전해진다고 생각하기 쉽다.
- 핵심은 MCP는 연결 방식을 정하지만 어떤 tool을 누구에게 허용할지는 애플리케이션 책임이라는 점이다.
- 인증, 인가, 감사, rate limit은 별도 설계가 필요하다.
- MCP server는 내부망이면 안전하다고 생각하기 쉽다.
- 핵심은 내부망에서도 권한 없는 운영 조회, secret 노출, 과도한 tool 권한이 사고가 될 수 있다는 점이다.
- 최소 권한과 감사 로그가 필요하다.
확인 질문
- MCP client와 server의 차이는 무엇인가?
- client는 외부 MCP server의 tool/resource를 사용하고, server는 우리 Spring 서비스를 MCP tool/resource로 노출한다.
- MCP 운영 전에 인프라팀과 합의할 것은 무엇인가?
- 네트워크 위치, transport, 인증, 인가, 감사 로그, rate limit, 장애 대응, 배포/rollback 기준이다.
Embedding VectorStore RAG ETL 설계
3줄 요약
- RAG 품질은 모델보다 ingestion, chunking, metadata, 권한 필터, 재색인, 삭제 반영에서 많이 갈린다.
- Spring AI의
VectorStore, DocumentRetriever, QuestionAnswerAdvisor는 RAG 흐름을 Spring 코드로 구성하게 해준다.
- 기업 운영에서는 vector DB 선택을 개발 편의가 아니라 권한, backup, latency, index rebuild, 인프라 운영성으로 판단한다.
핵심 정리
- 상세 문서: 09. Embedding VectorStore RAG ETL 설계.md
- RAG는 source 수집, document 변환, splitting, embedding, index 저장, retrieval, filtering, context packing, generation, evaluation으로 나뉜다.
- metadata에는 tenant, source id, source type, updated at, ACL, embedding model, index version을 넣는다.
- 권한 필터는 retrieval 전에 적용되어야 한다.
- embedding model이나 chunk policy를 바꾸면 재색인과 regression eval이 필요하다.
- vector DB 장애 시 fallback과 degrade mode를 정해야 한다.
헷갈리는 지점
- Vector DB를 붙이면 RAG가 완성된다고 생각하기 쉽다.
- 핵심은 검색 결과가 권한에 맞고 최신이며 질문에 적합해야 한다는 점이다.
- eval 없이 vector DB만 바꾸면 품질이 좋아졌는지 알 수 없다.
- chunk size는 한 번 정하면 된다고 생각하기 쉽다.
- 핵심은 문서 유형, 질문 유형, 모델 context window, citation 요구에 따라 적정 chunk가 달라진다는 점이다.
확인 질문
- RAG에서 metadata가 중요한 이유는 무엇인가?
- 권한, 최신성, source attribution, 재색인, 운영 디버깅을 결정하기 때문이다.
- embedding model 변경이 위험한 이유는 무엇인가?
- 기존 vector와 새 vector가 같은 의미 공간에 있지 않을 수 있어 검색 품질이 흔들리기 때문이다.
Evaluation Testing Regression
3줄 요약
- AI 기능 테스트는 exact match보다 schema, safety, citation, retrieval hit, latency, forbidden output 같은 속성 검증이 중요하다.
- Spring Boot 테스트는 fake gateway 단위 테스트, adapter 테스트, provider smoke test, eval regression으로 나눠야 한다.
- prompt/model/index/tool 변경은 작은 eval set이라도 통과한 뒤 배포하는 습관이 필요하다.
핵심 정리
- 상세 문서: 10. Evaluation Testing Regression.md
- 유스케이스 service는 fake AI gateway로 빠르게 테스트한다.
- AI adapter는 prompt 조립, 예외 변환, output validation을 테스트한다.
- structured output은 DTO validation과 실패 fallback을 테스트한다.
- RAG는 retrieval hit, source id, forbidden leak, stale document를 테스트한다.
- eval result는 prompt version, model profile, index version과 함께 기록한다.
헷갈리는 지점
- 모델 응답이 매번 달라서 테스트할 수 없다고 생각하기 쉽다.
- 핵심은 exact string 대신 속성 기반으로 테스트할 수 있다는 점이다.
- schema valid, source 포함, 금지 문구 없음, latency budget 같은 기준을 둔다.
- 실제 provider 테스트만 있으면 충분하다고 생각하기 쉽다.
- 핵심은 provider 테스트는 느리고 비용이 들며 비결정적이라는 점이다.
- 대부분의 정책 테스트는 fake gateway로 분리해야 한다.
확인 질문
- AI 기능의 regression gate에 들어갈 최소 항목은 무엇인가?
- 대표 질문, 기대 source, 금지 문구, schema valid, latency budget, validation failure 기준이다.
- fake gateway 테스트가 필요한 이유는 무엇인가?
- 비즈니스 로직 테스트가 provider 비용, latency, 비결정성에 흔들리지 않게 하기 위해서다.
Observability와 장애 대응 런북
3줄 요약
- Spring AI 운영은 latency와 error rate뿐 아니라 token, 비용, prompt version, model profile, retrieval, tool 실행을 함께 봐야 한다.
- 로그에는 원문 prompt와 completion을 무조건 남기지 말고 마스킹, 샘플링, 보존 정책을 둔다.
- 장애는 provider timeout, quota, JSON 깨짐, tool 중복 실행, vector DB 지연, prompt injection처럼 유형별 런북으로 대응한다.
핵심 정리
- 상세 문서: 11. Observability와 장애 대응 런북.md
- Micrometer/Observation과 Spring Boot Actuator를 기반으로 feature, model profile, prompt version, status, latency, token usage를 기록한다.
- metric tag에는 user id, raw prompt, document id 같은 고카디널리티 값을 넣지 않는다.
- trace에는 request id, tenant id, prompt version, model profile, index version, tool execution id를 연결한다.
- provider 장애 fallback은 다른 모델 재시도뿐 아니라 검색 결과만 제공, 비동기 전환, human review도 포함한다.
- 장애 런북에는 사용자에게 보여줄 문구와 내부 운영자 확인 절차가 같이 있어야 한다.
헷갈리는 지점
- observability를 켜면 자동으로 문제가 보일 것이라고 생각하기 쉽다.
- 핵심은 어떤 차원을 tag/event로 남길지 설계해야 한다는 점이다.
- feature, prompt version, model profile, index version이 없으면 원인 분석이 어렵다.
- prompt 원문 로그가 많을수록 디버깅이 쉽다고 생각하기 쉽다.
- 핵심은 원문에는 개인정보와 내부 문서가 섞일 수 있다는 점이다.
- 샘플링, 마스킹, 접근 제어, 보존 기간이 필요하다.
확인 질문
- AI 운영에서 최소로 남겨야 할 차원은 무엇인가?
- feature, tenant, prompt version, model profile, latency, error type, token usage, index version, tool execution count다.
- provider 장애 fallback은 왜 다른 모델 호출만이 아닌가?
- 비용과 품질 위험이 다시 생길 수 있으므로 검색 결과 제공, 비동기 처리, human review가 더 안전할 수 있기 때문이다.
Production Readiness와 인프라 협업
3줄 요약
- Spring AI 기능은 애플리케이션 코드만의 일이 아니라 secret, egress, proxy, vector DB, log volume, tracing, backup을 포함한 운영 계약이다.
- 개인 프로젝트도 timeout, quota, validation, 작은 eval, 로그 마스킹, 재색인 절차는 챙겨야 수준이 올라간다.
- 기업 운영에서는 비용 예산, 개인정보 경계, prompt/model/index rollback, MCP 노출 범위, incident runbook을 문서화해야 한다.
핵심 정리
- 상세 문서: 12. Production Readiness와 인프라 협업.md
- 인프라팀은 provider endpoint, secret rotation, outbound traffic, TLS, DNS, proxy, rate limit을 본다.
- vector DB는 backup, restore, index rebuild, capacity, latency, filter 성능을 운영 대상으로 본다.
- AI log와 trace는 비용과 민감정보 리스크가 크므로 retention과 sampling을 정한다.
- 배포 단위에는 code뿐 아니라 prompt, model profile, index version, tool schema, MCP server version이 포함된다.
- production readiness checklist는 출시 전 리뷰 문서로 남긴다.
헷갈리는 지점
- AI 기능은 애플리케이션팀만 잘 만들면 된다고 생각하기 쉽다.
- 핵심은 외부 provider와 새 저장소, 새 로그 차원, 새 보안 경계가 생긴다는 점이다.
- 인프라팀과 운영 계약을 미리 맞춰야 한다.
- 개인 프로젝트에는 운영 기준이 과하다고 생각하기 쉽다.
- 핵심은 작은 timeout, quota, validation, eval만 있어도 포트폴리오 품질이 달라진다는 점이다.
- 최소 기준과 기업 기준을 구분하면 부담을 줄일 수 있다.
확인 질문
- Spring AI 출시 전 인프라팀과 합의할 항목은 무엇인가?
- egress, secret rotation, provider 장애 대응, vector DB 운영, log/trace volume, MCP 노출 범위, rollback 기준이다.
- prompt/model/index를 배포 자산으로 봐야 하는 이유는 무엇인가?
- 변경 시 품질, 비용, latency, 보안 결과가 달라지기 때문이다.
고객지원 RAG Capstone
3줄 요약
- 졸업 과제는 고객지원 RAG 서비스로 잡고, Spring AI 핵심 기능을 하나의 운영 가능한 설계로 묶는다.
- 최종 결과물은 단순 챗봇이 아니라 문서 검색, structured output, read-only tool, MCP 운영 조회, eval, observability, 장애 대응을 포함한다.
- capstone을 설명할 수 있으면 개인 프로젝트 수준의 AI 백엔드 기능을 프로덕션에 가깝게 설계할 수 있다.
핵심 정리
- 상세 문서: 13. 고객지원 RAG Capstone.md
- 사용자는 질문을 보내고, 서버는 권한 있는 문서를 검색하고, 모델은 근거 기반 답변을 생성한다.
- 답변은 text, source ids, confidence, escalation flag 같은 structured output으로 받는다.
- 주문/계정 상태 조회 같은 read-only tool은 권한 검증 뒤 제한적으로 붙인다.
- MCP는 운영자나 내부 agent가 배포 상태, 문서 index 상태, 장애 상태를 조회하는 read-only tool부터 시작한다.
- eval set, metrics, 장애 런북, production checklist를 capstone의 산출물로 둔다.
헷갈리는 지점
- capstone을 기능 데모로만 생각하기 쉽다.
- 핵심은 졸업 과제는 운영 설계 능력을 확인하는 문서라는 점이다.
- 성공 응답뿐 아니라 실패, 비용, 보안, 인프라 협업을 포함해야 한다.
- RAG 답변이 나오면 과제가 끝났다고 생각하기 쉽다.
- 핵심은 검색 품질, 권한, source, eval, 장애 대응이 없으면 운영 가능한 RAG가 아니라는 점이다.
확인 질문
- 고객지원 RAG capstone의 핵심 산출물은 무엇인가?
- API 흐름, AI gateway, RAG index 설계, structured output, read-only tool, MCP 운영 조회, eval set, observability, 장애 런북이다.
- 이 capstone으로 확인할 수 있는 역량은 무엇인가?
- Spring AI 기능을 실제 백엔드 서비스에 안전하게 붙이고 운영 판단까지 설명하는 역량이다.