질문&답변
지식공유 (윈도우 설치) [실습] 외부 MCP Server와 연동한 실시간 날씨 조회 - MCP Client 개발
안녕하세요 이준엽님~ JSCODE 시니 입니다. 해당 내역 공유해주셔서 감사합니다! ㅎㅎ 명령어도 잘 보이게 글 써주셔서 너무 좋네요~! ㅎㅎ 수강하시다가 궁금한점 있으시면 언제든 질문 게시판 이용 부탁드립니다 ~~
- 좋아요수
- 0
- 댓글수
- 1
- 조회수
- 14
질문&답변
안녕하세요 이준엽님~ JSCODE 시니 입니다. 해당 내역 공유해주셔서 감사합니다! ㅎㅎ 명령어도 잘 보이게 글 써주셔서 너무 좋네요~! ㅎㅎ 수강하시다가 궁금한점 있으시면 언제든 질문 게시판 이용 부탁드립니다 ~~
질문&답변
안녕하세요 흑후추님~ JSCODE 시니입니다~! 강의자료 섹션 맨 상단에 기재해드린 것 처럼 윈도우 OS를 사용하시는 분들의 경우, 윈도우 기본 압축프로그램을 사용하시면 압축파일이 비어보입니다! 반디집과 같은 압축 프로그램을 사용하셔서 압축 해제해보시길 바라고, 시도 후에도 동일증상 있으시면 1대1 오픈채팅방으로 재문의 부탁드립니다~!ㅎㅎ
질문&답변
안녕하세요! 허언증님~ JSCODE 시니 입니다! ㅎㅎ 먼저 완강 전에 이렇게 멋진 프로젝트를 기획하시고 질문 남겨주셔서 감사합니다. 결론부터 말씀드리면, 수강생님이 기획하신 'RAG 기반 의사소통 피드백 챗봇'은 강의 완강하시면 충분히 구현 가능하며, 아주 훌륭한 프로젝트 주제 입니다! RAG(검색 증강 생성)를 활용하면 일반적인 챗봇을 넘어, 특정 도메인 지식이나 대화 가이드라인을 기반으로 LLM이 보다 정확하고 의미 있는 피드백을 주도록 만들 수 있습니다. 강의 후반부로 가실수록 RAG의 핵심인 외부 데이터 검색과 Tool Calling 등을 결합한 프롬프트 엔지니어링을 스프링 환경에서 어떻게 매끄럽게 연결하는지 감을 잡으실 수 있을 거예요. 우선은 강의를 끝까지 완강하시면서 Spring AI의 전체적인 흐름과 Vector DB 활용법을 익히시는 것을 추천해 드립니다. 이후에 작은 기능(예: 단순 텍스트 입력에 대한 1차 피드백)부터 차근차근 살을 붙여나가시면 원하시는 애플리케이션을 멋지게 완성하실 수 있을 겁니다! ㅎㅎ 학습하시다가 구현과 관련해 막히는 부분이 생기면 언제든 다시 질문 남겨주세요. 완강과 프로젝트 완성까지 응원하겠습니다! 화이팅하세요~!!
질문&답변
안녕하세요! 다연님~ JSOCDE 시니 입니다! 해당 파일이 Mac OS에서 작성된 파일이라 윈도우 기본 압축 해제 프로그램으로 압축 해제시 빈 파일로 보일 수 있습니다! 이런 경우 기본 프로그램이 아닌 반디집으로 압축해제 시도 하시면 정상적으로 파일 확인하실 수 있습니다~! 조치 진행해보시고, 추가적으로 문의사항 생기시면 연락주시길 바랍니다! 완강까지 화이팅입니다~ +1:1 질문방에서 해결 완료 확인하였습니다~!
질문&답변
안녕하세요, agachansong님! JSCODE 시니입니다~ 현재 이 강의에서는 Jenkins의 초점을 맞추어 Node.js 환경을 기반으로 CI/CD의 핵심 원리와 흐름을 다루고 있습니다! 질문해 주신 Spring Boot 의 경우, 기본적인 Docker 및 Jenkins 활용 흐름은 유사하지만 빌드 도구(Gradle/Maven)나 Dockerfile 작성 방식에서 약간의 차이가 있습니다. 추후 시간이 된다면 Spring Boot 프로젝트를 활용한 CI/CD 과정 도 별도 강의로 제작해 볼 계획을 가지고 있습니다! 🥹 다만, 현재 강의를 완강하신 분이라면 이미 CI/CD의 전체적인 메커니즘을 충분히 이해하고 계실 거예요. 따라서 다음 과정을 참고하여 스스로 자료를 찾아보며 직접 환경을 구축해 보시는 것 을 강력히 추천드립니다! • Dockerfile 작성: openjdk 이미지를 기반으로 Gradle/Maven 빌드 결과물(.jar)을 실행하는 Dockerfile을 만들어 보세요! • Jenkins Pipeline 수정: Node.js 빌드 단계 대신 ./gradlew build와 같은 명령어를 사용하도록 Pipeline 스크립트를 변경해 보세요. • 컨테이너 배포: 생성된 JAR 파일을 Docker 이미지로 빌드하고 컨테이너로 띄우는 과정을 실습해 보세요. 직접 부딪히며 해결하는 과정이 강의를 들을때보다 훨씬 실력 향상에 가장 큰 도움이 되실거에요! 실습하시다가 막히는 부분이 생기면 언제든 질문 남겨주세요! agachansong님의 성장을 응원하겠습니다~!
질문&답변
안녕하세요! 쿠카이든님~ JSCODE 시니입니다!ㅎㅎ 질문해 주신 Playwright 리포트 빈 화면 현상은 리포트 구성 파일이 정상적으로 로드되지 않을 때 주로 발생합니다. 정확한 문제 원인을 파악하여 해결책을 드리기 위해, 번거로우시겠지만 아래 세가지 정보 를 추가로 확인 부탁드립니다. 1. 브라우저 콘솔 에러 로그 빈 화면이 뜬 상태에서 키보드의 F12(개발자 도구)를 누른 뒤, 상단의 [Console] 탭을 클릭해 보세요. 그곳에 빨간색으로 표시되는 에러 메시지들이 있다면 캡처하거나 복사해서 공유해 주세요. (문제를 해결할 가장 중요한 단서가 됩니다.🥹) 2. 수강 중인 강의 정보 현재 수강하고 계신 강의의 전체 제목과 몇 강인지 알려주실 수 있을까요~? 젠킨스 설정 단계에 따라 해결 방법이 달라질 수 있어 확인이 필요합니다. 3. 젠킨스 스크립트 콘솔 설정 확인 [젠킨스 관리] > [Script Console]에 아래 코드를 입력하고 Run 을 실행한 뒤, 다시 리포트를 확인해 보시기 바랍니다. System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "sandbox allow-same-origin allow-scripts; default-src 'self' 'unsafe-inline' 'unsafe-eval'; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline'; img-src * data:; font-src *;") (참고: 이 설정은 젠킨스 재시작 시 초기화될 수 있으니, 우선 실행 후 리포트가 정상적으로 나오는지 확인 부탁드립니다.) 위 정보들을 확인해 주시면 정확한 원인을 잡아드리겠습니다!ㅎㅎ
질문&답변
안녕하세요! p4sh4님~ JSCODE 시니 입니다! 강의를 수강하시며 꼼꼼하게 확인해 주신 덕분에 오류를 바로잡을 수 있었습니다. 제보해 주셔서 진심으로 감사드립니다! ㅎㅎ 말씀하신 대로 업로드 과정에서 혼선이 있어 47강과 48강의 순서가 바뀌어 있었습니다. 확인 즉시 [실습] Jenkins와 S3를 활용한 정적 웹사이트 호스팅하기 내용이 정상적으로 이어지도록 수정을 완료했습니다. 참고로, 해당 강의 자료는 'Jenkins와 S3를 활용한 정적 웹사이트 호스팅하기' 라는 하나의 강의자료 페이지 안에 다음과 같이 구성되어 있으니 학습에 참고해 주세요. 47강: [실습] Jenkins와 S3를 활용한 정적 웹사이트 호스팅하기 48강: 버킷에 정책 추가하기 학습에 불편을 드려 죄송합니다. 혹시 수정된 내용 확인 후에도 이상이 있거나 궁금한 점이 생기시면 언제든 말씀해 주세요. 완강까지 화이팅 하시길 바랍니다~!
질문&답변
안녕하세요 p4sh4님! JSCODE 시니 입니다~ 파일이 없어 당황스러우셨을 것 같아요,,! 불편드려 죄송합니다! ㅠㅠ 해당파일이 업로드 중 누락된 것 같아 다시 다운로드 받으실 수 있게 강의자료에 재 업로드 해놓았습니다~! 혹시나 윈도우 사용자분이시라면, 반디집을 이용해 압축 해제 부탁드립니다! 또한 기타 문의 사항 있으시다면 언제든 편하게 연락주시길 바랍니다~! 완강까지도 응원하겠습니다!
질문&답변
안녕하세요! Hyo Kyun Lee님~ JSCODE 시니 입니다! ㅎㅎ 강의 내용을 아주 깊이 있게 소화하고 계시네요! 질문 주신 내용은 실무에서 개발자가 늘 고민하게 되는 가독성(코드)과 가시성(운영) 사이의 균형에 대한 아주 훌륭한 주제인 것 같습니다! ㅎㅎ 말씀하신 것처럼 프로젝트의 성향이나 규모에 따라 천차만별이긴 하겠지만,,, 질문하신 내용에 대해 제 실무적 경험을 바탕으로 정리해드릴게요! 1. 주석과 로그의 본질적인 차이 제가 생각할때 주석과 로그의 본질척인 차이를 두기 위해 가장먼저 구분해야 할 것은 '누가, 언제 읽는가' 인 것 같습니다! 주석 : 개발자가 코드를 수정하거나, 기능을 파악하기 위해 코드 편집툴에서 읽는 것 입니다. 비즈니스 로직의 의도나 복잡한 알고리즘 설명, 오픈소스 사용법등이 여기에 포함됩니다. 로그 : 운영자가 애플리케이션이 실행 중일 때 콘솔이나 파일을 통해 읽는 것 입니다. 프로그램의 상태를 확인하는 용도라고 생각하시면 쉬울 것 같습니다! 2.상세 명세와 설명은 어떤 영역일까? 결론부터 말씀드리면, '상세한 명세와 설명은 100% 주석의 영역 ' 입니다. 오픈 소스나 프레임워크(Spring Batch, Tomcat 등)에서 로그를 상세하게 남기지 않는 이유는 크게 두가지입니다..! 성능 저하 : 상세한 설명을 모두 로그로 세세하게 남기면 디스크 I/O 가 발생하여 전체 시스템 성능이 크게 떨어집니다! 로그 노이즈 : 너무 많은 정보가 로그에 찍히면, 정작 장애가 났을 때 중요한 로그를 찾기가 불가능해질 수 있습니다. 그래서 결론적으로는 저는 클래스나 메서드의 역할을 설명하실때는 주석으로 작성하는걸 추천 드립니다. 특히 이때 작성하시는 주석은 일반 주석 보다는 /** 내용 */ 주석으로 작성하시는걸 추천드립니다! ㅎㅎ 만약 로그로 남겨야 할 특징적인 부분이 뭘까 라고 한다면,, 어떤 데이터가 들어와서 어떤 결과가 나갔는지에 대한 상태의 변화라고 생각합니다..! 3.Log Info와 Warn의 실무적 활용 가이드 우선 강의에서 이해하신 내용이 아주 정확합니다! ㅎㅎ 이를 실무/오픈소스 관점에서 조금 더 구체화 해볼게요..! Log INFO : 실행되는 로직의 핵심단계만 남기시면됩니다. 예를들어, log.info("이제부터 사용자 유효성 검사를 시작하고 디비에 저장 한 뒤~~ 어쩌고 저쩌고") 이런 내용은 로그 보다는 주석으로 가는것이 훨씬 알맞겠죠! 대신 좋은 예시는 log.info("배치 작업 xxx 시작 : [TargetDate : {}]", targetDate); 이런식으로 이 작업이 시작이 됐고 성공적으로 끝났다는 사실 여부 같은걸 쓰면 좋습니다. 참고로 식별자를 남기는 것이 핵심입니다! ㅎㅎ Log WARN : 시스템이 중단되지는 않지만, 나중에 문제가 될 요소를 남깁니다. 예를들어 오픈소스라면 설정값이 권장 사양보다 낮을때나, 곧 사라질 기능을 호출 했을때 남기면 좋을 것 같습니다. 또는, 재시도 로직 중 1차 실패 발생시나, api 응답이 평소보다 늦어지는 임계치 도달시 남기는 것을 추천드립니다..! 이것 저것 말씀드리다 보니 답변이 길어졌네요,,! 제 답변이 도움이 되셨을지 모르겠습니다! 근데 다만 확실한건 제가 강의에서도 말씀드렸지만 전적으로 이런건 정답은 없고 프로젝트의 상황과 규모를 토대로 잘 판단하신다면 그게 정답입니다! ㅎㅎ 여러가지 적용 해보시면서 적절한 트레이드 오프를 하시면 좋을 것 같습니다! ㅎㅎ 강의 열심히 들어주셔서 감사하고, 추후에 질문 사항이 또 생긴다면 언제든 남겨주시길 바랍니다! ㅎㅎ 항상 응원하겠습니다~!!
질문&답변
안녕하세요 gibbs님! ㅎㅎ JSCODE 시니 입니다~! 아직 실습은 못해보고 영상만 보는 중이시군요! 전체적인 흐름을 먼저 파악하시는 것도 아주 좋은 학습 방법입니다. 결론부터 말씀드리면, 의존성을 추가하면 마이크로미터가 자동으로 기본 지표들을 수집하지만, 이 데이터를 프로메테우스가 가져갈 수 있도록(Scraping) 길을 열어주는 설정 파일( application.yml ) 수정이 반드시 필요합니다! 강의에서 다루고 있는 설정을 기준으로 설명해 드릴게요! ㅎㅎ 1. 의존성 추가 implementation 'org.springframework.boot:spring-boot-starter-actuator' implementation 'io.micrometer:micrometer-registry-prometheus' 이 두 가지 의존성을 추가하면 스프링 부트가 중간에서 마이크로미터와 관련된 설정들을 자동으로 처리하고, JVM, CPU, 웹 요청 등 다양한 기본 지표를 수집하기 시작합니다. 2. 엔드포인트 노출 및 추가 설정 (application.yml) 데이터를 수집하고 있더라도 보안상 기본적으로는 외부에서 접근할 수 없습니다. 따라서 프로메테우스가 데이터를 수집할 수 있도록 아래와 같이 설정을 추가해주어야 합니다. spring: application: name: waiting-api management: endpoints: web: exposure: include: prometheus,health,info,metrics,env,loggers metrics: tags: application: waiting-api endpoint: health: show-details: always 이 설정을 통해 /actuator/prometheus 등의 엔드포인트를 외부에 노출하고, 수집되는 모든 지표에 application: waiting-api 라는 공통 태그를 붙여 프로메테우스에서 식별하기 쉽게 만들어 줍니다. 이후 실습을 진행하시면서 설정 파일이 어떻게 동작하는지 직접 확인해 보시면 구조가 훨씬 명확하게 이해되실 거에요!ㅎㅎ 강의 수강하시다가 더 궁금한 점이 생기면 언제든 질문 남겨주세요~!! 화이팅하시고 좋은하루 보내세요~!!