jscode
@jscode
受講生
29,363
受講レビュー
2,049
講義評価
4.9
[Sites]
Youtube 바로가기
LinkedIn 바로가기
[Career]
現) JSCODE - 대표 멘토, CEO
前) (주)트라이포드랩 - CTO
前) (주)온리원유니버스 - CTO
前) 달리(DALY) - CTO
前) 팀메이트(Teammate) - CEO
[Books]
『Do it! JSCODE의 AWS 입문』, 이지스퍼블리싱 (2025.05)
[ETC]
- 기업 대상 개발 컨설팅 및 코딩 교육 활동
講義
受講レビュー
- 非専攻者でも理解できるMSA入門/実戦 (feat. Spring Boot)
- 大規模トラフィック処理のための負荷テスト入門・実践
投稿
Q&A
스프링 부트에 Redis 적용하기 질문
안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! "강의 진행 시에는 Service 계층에서 Redis 설정을 적용시켰는데, Redis 설정은 Service 계층에서 적용하는 것이 일반적일까요 ?"->네 ! Redis 캐싱 설정은 Service 계층에 적용하는 것이 일반적이고 권장돼요 !Service 계층에서 비즈니스 로직이 처리된 후의 최종 결과를 캐싱하기 때문에 가장 효율적이기 때문이에요 !또한 여러 Controller에서 같은 Service를 호출할 때 캐시를 재사용할 수 있어서 효율성이 높고, 캐시 키 관리도 깔끔하게 비즈니스 로직 단위로 할 수 있어요 !Controller 계층에 적용하면 HTTP 요청 파라미터나 헤더 등까지 고려해야 해서 캐시 키가 복잡해질 수 있고, Controller는 HTTP 계층의 역할에 집중하는 게 좋기 때문에 캐싱 로직이 섞이면 관심사 분리 측면에서도 좋지 않아요 ! Repository 계층에 적용하는 경우에는 DB 쿼리 결과를 바로 캐싱하게 되는데, 이렇게 되면 비즈니스 로직 처리 전의 원본 데이터만 캐싱되고 페이징이나 정렬 등 다양한 조건마다 별도의 캐시가 생성되어 비효율적일 수 있어요 !결론적으로 Service 계층에서 비즈니스 로직이 완료된 최종 결과물을 캐싱하는 것이 가장 효율적이고 관리하기도 좋죠 :) 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~
- 0
- 2
- 28
Q&A
블로그 작성에 너무 힘 쓸 필요는 없다는 말씀이신가요?
안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 ! 결론부터 말씀드리면, 학생분의 생각처럼 본인을 위해 편하게 작성하시는 것을 권장드려요 !블로그에 너무 많은 시간을 투자하면 정작 중요한 실력 향상에 쓸 시간이 줄어들기 때문이죠 !면접관 입장에서도 블로그를 꼼꼼히 읽어보는 경우는 생각보다 드물고,오히려 포트폴리오 프로젝트나 기술 면접에서의 답변을 더 중요하게 봐요 ! 화려하게 꾸미거나 남에게 잘 보이려고 문장을 다듬는 데 시간을 쓰기보다는,핵심 내용을 간결하게 정리하고 그 시간에 한 줄이라도 더 코딩하시는 게 실력 향상에 훨씬 도움이 돼요 !다만 한 가지 팁을 드리자면, 트러블슈팅 경험이나 기술적 의사결정 과정을 담은 글은면접에서 실제로 도움이 될 수 있으니, 그런 내용은 조금 더 신경 써서 정리해두시면 좋아요 !하지만 이것도 완벽하게 작성하려고 하기보다는 일단 빠르게 기록해두고,나중에 필요하면 다듬는 방식으로 접근하시면 돼요 :) 추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~
- 0
- 2
- 39
Q&A
안녕하세요 질문 있습니다.
안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !결론부터 말씀드리면, 스프링 부트에서 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 사용을 권장드려요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~
- 0
- 2
- 31
Q&A
로드밸런싱 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가 반환되는 거예요! 이게 바로 로드 밸런싱이 제대로 작동하고 있다는 증거에요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~
- 0
- 2
- 26
Q&A
도커 허브에서 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로 뜬 거예요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요 ~
- 0
- 2
- 37
Q&A
보충 자료와도 관련된 추가 내용
안녕하세요 11 1님!! 수업 들으시면서 시행착오 겪으신 내용 공유해주셔서 감사합니다ㅎㅎ다른 수강생분들한테도 도움이 될 것 같네요!감사합니다~~~
- 1
- 1
- 31
Q&A
mysql_data 폴더 내부에 다른 파일이 있는데도 잘 되는 경우
안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해 주신 내용에 대해 답변드려볼게요 !우선 "mysql_data 폴더 내부에 파일이 있으면 안 된다"는 것은 MySQL을 처음 실행할 때의 이야기예요 ! 그래야 MySQL 컨테이너 내부의 /var/lib/mysql 파일들이 호스트의 mysql_data 폴더로 복사되거든요 !하지만 이미 볼륨에 MySQL 데이터가 정상적으로 저장된 이후에는 컨테이너를 삭제하고 다시 생성해도 오류가 나지 않아요 ! MySQL 컨테이너는 새로 초기화하지 않고 기존 데이터를 그대로 사용하며 오히려 이게 볼륨의 목적이에요 ! 그래서 pwd1234로 바꿔서 컨테이너를 다시 생성했을 때 오류가 안 난 거예요! 이때 -e MYSQL_ROOT_PASSWORD=pwd1234로 새로운 비밀번호를 설정하더라도, 이미 초기화된 데이터베이스가 있기 때문에 이 환경변수는 무시돼요 ! 결과적으로 새로운 비밀번호 설정이 적용되지 않고 기존 비밀번호(password123)가 그대로 유지되는 거죠 🙂 즉, "폴더가 비어있어야 한다"라는 건 최초 1회 실행 시에만 해당되는 내용이고, 이후에는 기존 데이터를 재사용하는 게 정상이에요 !추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~
- 0
- 2
- 29
Q&A
현업에서 MySQL은 RDS와 도커 볼륨 중 어떤 걸 사용하나요?
안녕하세요 11 1님! 질문 잘 해주셨어요~~~어느 정도 서비스의 안정성이 중요해진 기업에서는 AWS에서 제공하는 고가용성과 다양한 편리한 기능들 때문에Docker로 MySQL을 띄워서 사용하는 것보다RDS를 사용하는 경우가 많습니다:D이 외로 또 궁금한 점 있으시면 질문 남겨주세요~~
- 0
- 2
- 43
Q&A
노션 자료에 안 보이는 이미지가 있습니다
안녕하세요 11 1님! 제보해주셔서 감사합니다ㅎㅎ말씀해주신 덕분에 안 보이는 이미지를 다른 이미지로 교체했습니다! 감사합니다:D
- 0
- 1
- 32
Q&A
default.conf
안녕하세요 ! 질문 잘해주셨어요 !질문해 주신 내용에 대해 답변드려볼게요 ~이전에 해당 파일을 실수로 삭제했거나, 설치 방법 및 운영체제와 같은 서버 환경에 따라 기본 설정 파일 경로가 다른 경우 /etc/nginx/conf.d/default.conf 파일이 보이지 않을 수 있어요 !HTTPS 인증서가 정상적으로 발급된 상태라면, Nginx 설정 파일 어딘가에 # managed by Certbot이라는 주석이 반드시 들어 있어요!아래 명령으로 실제로 사용 중인 설정 파일을 확인해 보시는 걸 추천드려요 !sudo nginx -tsudo find /etc/nginx -name "*.conf"sudo grep -R "managed by Certbot" /etc/nginx이 명령을 통해 Certbot이 수정한 설정 파일의 정확한 위치를 찾으실 수 있고, 강의에서 설명드린 HTTPS 관련 코드는 경로만 다를 뿐 내용과 의미는 동일하니 그대로 이해하시면 돼요:)혹시 위 방법으로도 찾기 어려우시면 현재 어떤 경로에 어떤 파일들이 있는지에 대한 내용과 함께 언제든 편하게 추가 질문 주세요 ~~늘 파이팅입니다 😄
- 0
- 2
- 38




