녹음 소리

안녕하세요, 이도원입니다. 강의에 관심을 가져 주셔서 감사드립니다.말씀하신 6~8강의 내용 외에 9~16강 까지의 파일이 모노로 녹음된 것을 확인했습니다. 그 이후 파일은 모두 스테레오로 녹음되었습니다. 모노 파일을 스테레오 타입으로 변환 가능한지 확인해 보고 다시 답변 드리도록 하겠습니다.감사합니다.

spring으로 RAG 구축인 이유?

안녕하세요, 이도원입니다. 기본적으로 AI 관련 된 작업에서는 파이썬언어가 많이 사용됩니다. 그러나, 실제로 국내의 백엔드 개발자들은 대부분 자바와 스프링을 사용합니다. 이번 강의의 주요 타겟은 자바 개발자들(특히 스프링 개발자들)을 위해 Spring AI를 활용하여 LLM 서비스를 구축하는데 필요한 내용을 알아보고, RAG 파이프라인 구축에 있어서도, 직접 Spring AI로 구축해 보고자 하는데 있습니다. 1. 레거시가 있는 시스템(금융권 등)을 타겟으로 기획했는지네, 맞습니다. 실제로 금융권 AI/LLM 프로젝트를 진행하면서 느낀 게, 이미 Spring 기반으로 수년간 운영해온 서비스에 "이제 AI 기능을 붙여야 한다"는 요구가 들어왔을 때, 이 서비스를 Python/FastAPI로 새로 작성할 수도 있지만, 기존에 구축된 환경에 바로 연계될 수 있도록 스프링으로 구축하는 것으로 구성했습니다.- 기존 인증/인가, 트랜잭션 처리, 배치, 모니터링이 전부 Spring 생태계에 맞춰져 있고- 사내 표준, 배포 파이프라인, 코드 리뷰 체계도 Java/Spring 기준으로 잡혀 있어서- "AI 기능만 별도 Python 서버로 분리"하는 것도 가능은 하지만, 그러면 인증 연계·트랜잭션 정합성·운영 부담이 늘어나는 문제가 생깁니다.즉 이 강의는 신규 스타트업처럼 스택을 자유롭게 고를 수 있는 분보다는, 이미 Spring으로 서비스를 운영 중이고 그 위에 LLM 기능을 자연스럽게 얹어야 하는 실무자를 우선 타겟으로 기획했습니다. 금융권이 대표적이지만, 대기업 사내 시스템이나 오래된 커머스/ERP 백엔드도 비슷한 상황이라 함께 고려했습니다.2. 기존 Python/FastAPI 강의 대비 추가로 필요한 기술 스택오히려 반대에 가깝습니다. 이미 Spring Boot로 개발해오신 분이라면 추가로 배워야 할 "새로운 언어나 런타임"은 없습니다. 새로 학습이 필요한 부분은 이것 하나입니다.- Spring AI 라이브러리 자체 — ChatClient, Advisor 패턴, VectorStore 추상화, MCP 연동 API 등은 Spring AI가 나온 지 얼마 안 돼서 이 라이브러리의 사용법 자체는 Python 개발자든 Spring 개발자든 처음 보시는 게 맞습니다.반대로 Python/FastAPI 진영에서 넘어오시는 경우라면 Spring Boot의 DI, 설정 방식, Maven/Gradle 빌드 체계까지 같이 익히셔야 해서 진입장벽이 있을 수 있는데, 이 강의는 "Spring Boot로 REST API를 만들어본 경험"을 전제로 하고 있어서 그 부분은 스킵하고 바로 Spring AI 자체에 집중할 수 있게 구성했습니다. 만약 자바 개발이 처음이시라면, 강의에서 제공하는 실습 예제를 직접 실행해 보면서, 강의를 수강하실 수도 있습니다. 이번 강의의 포지션은 "AI 서비스를 Python으로 새로 짤지 고민하는 분"이 아니라 "이미 Spring 위에서 돌아가는 서비스에 LLM을 자연스럽게 통합해야 하는 분"을 위한 강의입니다. 도움이 되셨길 바랍니다!추가 문의사항 있으시면 다시 글 남겨 주세요.감사합니다.

강의 자료는 어디서 다운 받을 수 있나요?

안녕하세요, 이도원입니다.먼저, 답변이 늦어 죄송합니다.강의 교안은 아래 링크에서 확인해 보실 수 있습니다. 강의 업데이트를 아직 마무리하지 못해서, 우선 기조 자료로 확인 해 주시길 부탁드립니다.https://github.com/joneconsulting/msa_with_spring_cloud/tree/main/pdf감사합니다.

강의자료는 어디에서?

안녕하세요, 이도원입니다. 먼저, 답변이 늦어 죄송합니다. 강의 교안은 아래 링크에서 확인해 보실 수 있습니다. 강의 업데이트를 아직 마무리하지 못해서, 우선 기조 자료로 확인 해 주시길 부탁드립니다. https://github.com/joneconsulting/msa_with_spring_cloud/tree/main/pdf감사합니다.

강의 자료 업데이트

안녕하세요, 이도원입니.먼저, 답변이 늦어 죄송합니다. section 11 까지 업데이트 이후, 프로젝트에 투입되어 마무리를 하지 못했습니다. 이후 강의에 대한 업데이트를 다시 진행하고 있으시면, 빠른 시일 내에 완료하도록 하겠습니다. 감사합니다.

섹션 19 질문드립니다

안녕하세요, 이도원입니다. 섹션 19. [Updated] Spring Boot 3.2 + Spring Cloud 2023 는 기존 초기 스프링 부트 버전을 3.x으로 업데이트 하면서 변경되는 실습 코드에 대한 설명입니다. 말씀하신 것추럼 관련 부분만 수강하셔도 괜찮을 것 같습니다. 작년부터 Spring Boot 4.x + Spring Cloud 2025 버전으로 강의교안도 업데이트를 하고 있는데, 다른 업무 밀려 Kafka 이후 마무리를 못하고 있습니다. ㅡ.ㅡ; 나머지 강의도 업데이트 하겠습니다. 추가 문의 사항 있으시면 다시 글 남겨 주세요.감사합니다.

마이크로서비스간 통신 시, 인증 처리

안녕하세요, 이도원입니다. 먼저 답변이 늦어 죄송합니다.주문 서비스에서 주문 목록에 대한 api 는 유저서비스 의 IP만 접근하도록 방어 처리도 따로 필요 한가요 ??주문 서비스에서 유저 서비스로의 접근만 허용되도록 하는 것도 필요하지만, 더 중요한 것은 접근 권한이 있는 사용자에게 적절한 서비스를 제공하는 지에 대한 확인 입니다. 인증과 권한을 확인 후 해당 기능이 제공되도록 구현해야 합니다. API Gateway에서 인증처리는 하고 있기 때문에, 주문 서비스는 외부에 공개되지 않도록 서비스를 구성하면 1차적인 보안은 해결될 것 같습니다. 추가로 해당 인증 정보에 다른 사람의 주문 목록을 확인할 수 없도록 주문 서비스에서 추가 제어하는 것도 방어 로직에 포함해 볼 수 있을 것 같습니다. 추가 문의사항 있으시면 다시 글 남겨주세요.감사합니다.

강의 교안

안녕하세요, 이도원입니다. 답변이 늦어 죄송합니다. 강의 교안은 우선 아래 링크에서 확인해 보실 수 있습니다. https://github.com/joneconsulting/msa_with_spring_cloud/tree/main/pdf감사합니다.

kafka 업데이트 강의 듣고 시포요

안녕하세요, 이도원입니다. 글 남겨주신지가 시간이 꽤 흘렀네요. 다시 한번 죄송한 말씀 드립니다. Kafka는 MSA에서 비동기 처리 간 이벤트 전달에 사용되는 주요한 기술입니다. 서비스들이 서로 직접 REST API로만 호출하면 결합도가 높아지고, 한 서비스 장애가 다른 서비스 장애로 번지기 쉽습니다. Kafka는 이 문제를 줄이기 위해 중간에서 이벤트 브로커 역할을 합니다. Kafka 전용 강의 계획은 아직 없지만, MSA 패턴에서 EDA에 대한 강의는 설명드리고 있으니 참고부탁드립니다. https://inf.run/iFcqS추가로, EDA, Event Soucing, CQRS에 대한 실습 강의는 준비 중입니다. 업데이트 되는대로 공지 드리겠습니다. 감사합니다.

내장형 톰캣일경우

안녕하세요, 이도원입니다. 답변이 늦어 죄송합니다. 아래 AI 답변에 몇가지 추가해 봅니다. 1. application-*.yml 파일이 프로파일로 구분된 경우에는 환경별 설정을 분리하기 위해서인데, local, dev, stage, qa, prod 등 애플리케이션 환경에 따라 적합한 이름을 붙이게 됩니다. 환경별로 데이터베이스 접속 정보나 Redis 주소, 로그 레벨, 외부 API, 키 등의 값들을 완전히 분리할 수 있습니다. 이러한 application-*.yml 파일은 각 애플리케이션에서 직접 패키징해서 가지고 있는 경우도 있고, 중앙에서 관리해서 사용하도록 spring cloud config나 kubernetes config/secret 등을 사용할 수도 있습니다. 다만, 운영 DB 비밀번호 같은 민감정보를 application-prod.yml에 그대로 넣고 Git에 올리는 것은 좋지 않습니다. 운영 설정은 보통 환경변수, Jenkins Credential, Kubernetes Secret, Vault, AWS Parameter Store 같은 방식으로 분리하는 것이 좋습니다. Jenkins에서 적용할 때, 빌드 시 어떤 환경정보(프로파일)을 사용할 것인지 선택하게 하여 배포하거나, 환경별 Jenkins 프로젝트를 구분하는 것이 좋습니다. 만약 MSA 환경이라면, 앞서 말씀드린, Spring Cloud Config, K8s Secret 등을 적극 활용하는 것이 좋습니다. https://inf.run/1hrfv2. 멀티모듈의 경우에는 라이브러리 모듈들은 직접 실행되는 애플리케이션이 아니기 때문에, 실행 모듈만 배포하시면 됩니다. (즉, BootJar가 만들어지는 실행 모듈만 배포하시면 됩니다.) 3. Jenkins에서도 빌드 후 jar 파일을 서버로 복사하고, 기존 프로세스를 종료한 다음 새로운 jar를 실행하는 것이 일반적인 방법이지만, 이는 프로세스 관리가 어렵과, 재시작 실패 시 자동 보구 또한 어렵습니다. CI/CD에서 추구하고자 하는 무중단 배포또한 어럽습니다. 프로제긑 초기나 내부 서비스에서는 가능하지만, 운영 서비스에서는 권장하지 않습니다. 린구스 환경이라면, systemd 로 관리하는 것이 좋으며, 가능하면 도커와 같은 컨테이너 이미지 형태로 배포하는 것이 좋습니다. 추가 문의사항 있으시면 다시 글 남겨주세요.감사합니다.