스프링 종료 명령어

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요 ~"sudo fuser -k -n tcp 8080 이 명령어로 스프링 죽이시던데 실제 실무에서도 저 명령어로 스크립트를 구성하나요?"-> 네 ! sudo fuser -k -n tcp 8080 명령어는 실무에서 자주 사용되는 방식이에요 !특정 포트를 점유하고 있는 프로세스를 빠르게 종료해야 할 때 간편하게 쓸 수 있어서 자주 사용돼요 !참고로 프로젝트 규모가 커지거나 더 안정적인 배포가 필요한 경우에는 systemd 같은 프로세스 관리 도구를 사용하거나, Blue-Green 배포나 Kubernetes 같은 오케스트레이션 도구를 도입하는 경우도 있어요 !하지만 강의에서 사용하는 방법으로도 실무에서 충분하니 걱정하지 않으셔도 되고, 이런 방법들도 있다는 것 정도만 알아두시면 좋을 것 같아요~지금 강의에서 배우시는 CI/CD의 기본 개념과 흐름을 잘 이해해두시면, 나중에 프로젝트 규모가 커지거나 팀 상황에 맞춰 이런 도구들을 배우고 적용하실 때 훨씬 수월하실 거예요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

영상이 안 나옵니다 ㅠㅠ

안녕하세요! 위의 '인프런 AI 인턴'이 잘 답변해준 것 같네요:)혹시나 캡쳐 프로그램이나 영상 녹화 프로그램을 실행시키고 있는 게 있는 지확인해보시기 바랍니다~!!만약 확인을 했는데도 재생이 안 된다면 인프런 사이트의 우측 하단에 있는 '문의하기'를활용해서 도움 받아보시기 바랍니다ㅎㅎ

이번 실습은 무료 플랜에서도 가능한가요?

안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요 ~ "이번 실습은 무료 플랜에서도 가능한가요?"-> 네! Route53에서 도메인을 구매하는 건 유료이지만, 내도메인.한국 같은 무료 도메인 서비스를 활용하시면 무료로 실습하실 수 있어요 ! ACM(AWS Certificate Manager) 인증서 발급 자체도 무료예요 :) "인증서 발급 시, 저 빨간 박스에는 "내가 미리 만든 도메인" 이름을 적어야 하는 것 맞나요?"-> 네 맞아요 ! CloudFront에 연결하려는 도메인 이름을 입력하시면 돼요 ! "분명 인증서는 미국 동부(버지니아 북부)에서 발급 받아야 하는데, 저는 그런 설정 없이 성공했는데 그 이유가 무엇인가요? 그리고 제가 잘못 알고 있는 부분이 있을까요?"-> 사실 설정 없이 성공하신 게 아니라, 이미 버지니아 북부(us-east-1) 리전에서 인증서를 발급받으셨을 거예요!5번째 첨부해 주신 이미지를 보시면 CloudFront의 Custom SSL certificate 드롭다운에서 발급받으신 인증서가 정상적으로 보여요 ~CloudFront에서 ACM 인증서가 보인다는 것 자체가 버지니아 북부 리전에서 발급받았다는 증거에요 !ACM 콘솔에 접속하셨을 때 이미 리전이 버지니아 북부로 되어 있었거나, 무의식적으로 버지니아 북부에서 작업하셨을 가능성이 높아 보여요 :)추가로 궁금하신 점 있으시면 편하게 질문 남겨주세요 ~

S3 호스팅? Amplify 호스팅?

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! "S3 호스팅을 하려고 했더니, Amplify가 더 좋다고 뜨더라고요. 이게 최신 기술인가요?"-> Amplify는 2017년에 출시된 서비스라 "최신"이라기보다는, AWS에서 프론트엔드 개발자들이 더 편하게 배포할 수 있도록 만든 통합 서비스라고 보시면 돼요 !제미나이가 설명해준 것처럼 내부적으로는 S3 + CloudFront를 사용하지만, 이를 자동으로 설정해 주는 거죠 :) "현업에서는 S3에서 Amplify로 옮겨가는 추세인가요?"-> 현업에서 Amplify로 옮겨간다기보다는 프로젝트 특성과 상황에 따라 선택을 해요 !CI/CD 자동화가 필요하거나 Next.js SSR을 사용하거나 빠르게 배포하고 싶을 때는 Amplify를 선택하고, 세밀한 설정이 필요하거나 비용을 더 최적화하고 싶을 때는 S3 + CloudFront를 직접 구성하는 방식을 선택해요 !S3 호스팅을 배우는 거라면 우선 S3로 진행하시는 걸 추천드려요!S3 + CloudFront의 원리를 이해하는 게 AWS 인프라 학습에 훨씬 도움이 돼요 !Amplify는 내부적으로 S3를 쓰기 때문에, S3를 이해하고 나면 Amplify도 쉽게 이해할 수 있어요 !나중에 실제 프로젝트에서 CI/CD가 필요하거나 Next.js를 쓰게 되면 그 때 Amplify로 전환하셔도 전혀 늦지 않아요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

스프링 부트에 Redis 적용하기 질문

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! "강의 진행 시에는 Service 계층에서 Redis 설정을 적용시켰는데, Redis 설정은 Service 계층에서 적용하는 것이 일반적일까요 ?"->네 ! Redis 캐싱 설정은 Service 계층에 적용하는 것이 일반적이고 권장돼요 !Service 계층에서 비즈니스 로직이 처리된 후의 최종 결과를 캐싱하기 때문에 가장 효율적이기 때문이에요 !또한 여러 Controller에서 같은 Service를 호출할 때 캐시를 재사용할 수 있어서 효율성이 높고, 캐시 키 관리도 깔끔하게 비즈니스 로직 단위로 할 수 있어요 !Controller 계층에 적용하면 HTTP 요청 파라미터나 헤더 등까지 고려해야 해서 캐시 키가 복잡해질 수 있고, Controller는 HTTP 계층의 역할에 집중하는 게 좋기 때문에 캐싱 로직이 섞이면 관심사 분리 측면에서도 좋지 않아요 ! Repository 계층에 적용하는 경우에는 DB 쿼리 결과를 바로 캐싱하게 되는데, 이렇게 되면 비즈니스 로직 처리 전의 원본 데이터만 캐싱되고 페이징이나 정렬 등 다양한 조건마다 별도의 캐시가 생성되어 비효율적일 수 있어요 !결론적으로 Service 계층에서 비즈니스 로직이 완료된 최종 결과물을 캐싱하는 것이 가장 효율적이고 관리하기도 좋죠 :) 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

블로그 작성에 너무 힘 쓸 필요는 없다는 말씀이신가요?

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! 결론부터 말씀드리면, 학생분의 생각처럼 본인을 위해 편하게 작성하시는 것을 권장드려요 !블로그에 너무 많은 시간을 투자하면 정작 중요한 실력 향상에 쓸 시간이 줄어들기 때문이죠 !면접관 입장에서도 블로그를 꼼꼼히 읽어보는 경우는 생각보다 드물고,오히려 포트폴리오 프로젝트나 기술 면접에서의 답변을 더 중요하게 봐요 ! 화려하게 꾸미거나 남에게 잘 보이려고 문장을 다듬는 데 시간을 쓰기보다는,핵심 내용을 간결하게 정리하고 그 시간에 한 줄이라도 더 코딩하시는 게 실력 향상에 훨씬 도움이 돼요 !다만 한 가지 팁을 드리자면, 트러블슈팅 경험이나 기술적 의사결정 과정을 담은 글은면접에서 실제로 도움이 될 수 있으니, 그런 내용은 조금 더 신경 써서 정리해두시면 좋아요 !하지만 이것도 완벽하게 작성하려고 하기보다는 일단 빠르게 기록해두고,나중에 필요하면 다듬는 방식으로 접근하시면 돼요 :) 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

안녕하세요 질문 있습니다.

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !결론부터 말씀드리면, 스프링 부트에서 Elasticsearch 라이브러리를 사용하면서 실제 서버는 OpenSearch를 띄워서 사용하는 것은 가능하지만 주의가 필요해요 !OpenSearch는 Elasticsearch를 개발한 회사가 2021년 1월 이후로 새로운 라이선스를 부과하면서 자유로운 활용이 금지되자, AWS가 이에 반발해 오픈 소스로 활용할 수 있었던 Elasticsearch 7.10.2 버전을 포크해서 만든 검색 엔진이에요 !대부분의 기능은 비슷하지만 OpenSearch와 Elasticsearch는 엄연히 다른 소프트웨어이고, 시간이 흐르면서 버전이 업데이트됨에 따라 기능이나 사용법의 차이가 조금씩 생기게 됐어요 !따라서 Spring Data Elasticsearch와 OpenSearch 조합으로 사용하실 경우, 기본적인 CRUD나 간단한 검색은 동작할 수 있지만 고급 기능에서 문제가 생길 수 있고, AWS OpenSearch에서는 nori 플러그인을 제공하지 않는 등의 차이도 있어요 !그래서 OpenSearch를 사용하실 거라면 spring-data-opensearch 라이브러리를 사용하시는 것을 권장 드리고, Spring Data Elasticsearch를 사용하실 거라면 Elasticsearch 서버나 Elastic Cloud 사용을 권장드려요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

로드밸런싱 Server ID 출력에 관한 질문

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !"위 코드에서는 사실 서버는 1대이고, 포트번호만 8080과 8081로 로드밸런싱한 것 아닌가요?"-> 네 맞아요! 물리적으로는 1대의 EC2 서버에서 Spring Boot 애플리케이션 2개를 서로 다른 포트(8080, 8081)로 실행시킨거예요 !"실제로 서버 2대로 로드밸런싱을 하려면 localhost:8080과 localhost:8081 자리에 서버 도메인 주소가 들어가면 되는 건가요?"-> 네 맞아요 ! localhost 대신 각 서버의 IP 주소나 도메인을 넣어주시면 돼요 !"제가 말한 것이 맞다면 /health에 요청할 때마다 나타나는 Server ID는 같아야 하는 것인데, 왜 다르게 나오는 건가요?"-> Server ID는 물리적 서버를 구분하는 게 아니라, 각 Spring Boot 애플리케이션(프로세스)을 구분하는 값이에요 !8080 포트와 8081 포트에서 실행되는 Spring Boot 애플리케이션은 각각 독립적인 프로세스에요 !각 애플리케이션은 별도의 JVM에서 실행되고, 별도의 메모리 공간을 가지며, 별도의 Server ID를 생성해요 !그래서 /health 엔드포인트를 호출할 때마다 Nginx가 8080과 8081로 번갈아가며 요청을 보내기 때문에, 서로 다른 Server ID가 반환되는 거예요! 이게 바로 로드 밸런싱이 제대로 작동하고 있다는 증거에요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~

도커 허브에서 postgres 버전 확인하는 법

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !"도커 허브에 있는 postgres:latest인데https://hub.docker.com/layers/library/postgres/latest/images/sha256-c84595a367a3fe5a4d9dce011490da38c462190e6ac7afb7d2a4c49436c80656이건 postgres 몇 버전인가요?"-> 현재 postgres:latest는 PostgreSQL 18.1 버전이에요!해당 링크의 Layers 섹션에서 확인할 수 있어요 ~Ctrl + F로 'PG_MAJOR' 와 'PG_VERSION'를 검색해 보시면 아래의 버전 정보를 확인할 수 있어요 !ENV PG_MAJOR=18ENV PG_VERSION=18.1-1.pgdg13+2여기서 PG_MAJOR=18이 PostgreSQL 메이저 버전이고, PG_VERSION=18.1-1.pgdg13+2가 정확한 버전 정보에요 :)"newest는 postgres:14.20-alpine3.23인데, 이건 14 버전인가요? "-> 네 맞아요 ! 14.20이 PostgreSQL 버전이에요 !newest는 "가장 최근에 push된 이미지"를 의미해서, 꼭 최신 버전이 아닐 수 있어요! 그래서 14 버전 이미지가 newest로 뜬 거예요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~

보충 자료와도 관련된 추가 내용

안녕하세요 11 1님!! 수업 들으시면서 시행착오 겪으신 내용 공유해주셔서 감사합니다ㅎㅎ다른 수강생분들한테도 도움이 될 것 같네요!감사합니다~~~