주니어 이력서 작성방법

안녕하세요 진섭님 ! 질문 잘 해주셨어요 ~질문해주신 내용에 대해 답변드려볼게요 !지금 상황에서는 유지보수 경력이 약점이라고 생각하지 않으셔도 돼요 ! 운영 중인 서비스를 직접 다루면서 기존 코드를 분석하고 수정하고, 장애를 대응하고, 사용자 요청사항을 반영한 경험은 분명한 실무 역량이예요 !이력서에는 단순히 JSP 유지보수를 했다고 짧게 적기보다는, 어떤 문제를 해결했고 어떤 개선을 했는지를 중심으로 작성하시는 것이 좋아요 !React 실무 경험이 없는 부분은 억지로 포장하기보다, 개인 프로젝트나 사이드 프로젝트를 통해 별도로 보여주시는 것이 가장 현실적이고 좋은 방법이예요 ! React를 활용해 화면을 구현하고 API를 연동해본 경험, 상태관리나 배포 경험 등이 있다면 좋아요 ~그리고 이직 사유도 자연스럽게 연결해주시면 좋아요 ! 기존 회사에서 운영과 유지보수를 경험하며 서비스 개선의 중요성을 느꼈고, 이제는 사용자 경험을 직접 만드는 프론트엔드 개발자로 더 성장하고 싶어 React 중심의 환경으로 도전하게 되었다는 흐름이면 충분히 설득력이 있죠 :)결론적으로 유지보수 경력은 숨길 것이 아니라 실무 경험으로 잘 정리해서 강점으로 보여주시고, React 역량은 프로젝트 결과물로 보완하시는 방향을 추천드려요 ~추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

강의 듣는 중인데,

안녕하세요 원영님! 질문 잘 해주셨습니다:) 1강에서 다운 받으신 자료는 강의에서 똑같이 다루는 자료이기 때문에 수업을 들으시면서 참고를 하셔도 되고강의를 다 들으신 뒤에 따로 공부를 하셔도 좋습니다! 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~

36강 오탈자가 있는 거 같습니다.

안녕하세요 ㅅㅇ님! 제보해주셔서 감사합니다:)우선 제공하고 있는 수업 자료 먼저 우선적으로 수정 완료했습니다! 제보해주신 덕분에 빠르게 오탈자 정정할 수 있었습니다! 감사합니다~~~

큰 범위 조회 시 EXPLAIN의 rows 값이 정확하지 않은 이유가 궁금합니다.

안녕하세요 선우님 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 EXPLAIN의 rows 값은 정확한 수치가 아닌 추정값이예요 ~옵티마이저가 실제로 데이터를 전부 세어보는 게 아니라, 인덱스의 통계 정보를 바탕으로 빠르게 추정하는 방식으로 동작하거든요 !옵티마이저가 사용하는 통계 정보는 테이블 전체를 매번 스캔해서 만드는 게 아니라, 일정 시점에 샘플링된 데이터를 기반으로 만들어져요 !그래서 PK처럼 중복이 없고 순차적으로 들어간 컬럼이더라도 통계 정보 자체에 오차가 포함될 수 있어요 !정확한 count를 미리 계산해두지는 않거든요 ~결국 EXPLAIN의 rows는 옵티마이저가 실행 계획을 세우기 위한 참고용 추정치라고 이해하시면 돼요 !중요한 건 이 값이 크게 줄었는지 늘었는지를 보면서 SQL 튜닝의 방향을 잡는 것이고, 정확한 수치를 기대하는 용도로는 사용하지 않는 게 좋아요 :)추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

인프라 구성 중 ELB 관련하여 질문 드립니다.

안녕하세요 영서님 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 말씀해주신 것처럼 나중에 서버를 여러 대로 확장하는 상황을 대비해서 미리 ELB를 구성해둔 것도 맞아요 !다만 그것만이 이유라기보다는, 실제 서비스 환경과 유사한 구조를 경험해보는 데 더 큰 목적이 있다고 보시면 좋을 것 같아요 ~실무에서는 대부분 “사용자 → ELB → EC2” 구조로 트래픽이 들어오기 때문에, 처음부터 이 구조를 구성해보는 게 이후 확장이나 트래픽 처리 흐름을 이해하는 데 훨씬 도움이 돼요 !또한 이후 실습에서 EC2를 여러 대로 늘리는 수평 확장을 진행하게 되는데, 이때 ELB가 있어야 여러 서버로 트래픽을 분산시킬 수 있어요 !그래서 강의 흐름상 미리 ELB를 구성해두고 전체 인프라 구조를 점진적으로 확장해 나가는 방식으로 진행된다고 이해해주시면 좋을 것 같아요!결과적으로 지금 당장 “필수”라기보다는, 추후 확장과 실무 구조를 고려해서 미리 포함시켜둔 구성이라고 보시면 돼요 :)추가로 또 궁금하신 점 있으시면 편하게 질문 남겨주세요~~ 😊

라우팅 테이블 설정 중 궁금한게 있습니다.

안녕하세요 병운님 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 결론부터 말씀드리면, 라우팅 테이블은 말씀해주신 것처럼 "내부에서 외부로 나가는 경로를 설정하는 역할"이 맞아요 !그런데 외부에서 내부로 들어오는 것까지 가능해진 이유는 라우팅 테이블 때문이 아니라, 연결된 대상인 IGW의 특성 때문이예요 ~IGW는 VPC와 인터넷을 연결해주는 관문 역할을 하면서 통신의 방향을 제한하지 않는 구조이기 때문에, 라우팅 테이블에 0.0.0.0/0 → IGW로 설정하는 순간 내부에서 외부로 나가는 길뿐만 아니라 외부에서 들어오는 응답이나 요청도 처리할 수 있게 돼요 !즉, 라우팅 테이블이 양방향을 만든 것이 아니라 IGW 자체가 방향을 제한하지 않기 때문이예요 !추가로 NAT 게이트웨이에 대해 이해하신 부분도 방향은 거의 맞아요 ~라우팅 테이블 자체는 단순히 "어디로 보낼지"만 결정할 뿐이고, 실제 통신이 단방향인지 양방향인지는 NAT 게이트웨이냐 IGW냐에 따라 결정돼요 !NAT 게이트웨이는 내부에서 외부로 나가는 요청만 허용하고 외부에서 시작되는 요청은 차단하는 단방향 구조이고, IGW는 외부와 내부 간 양방향 통신이 가능한 구조예요 !그래서 정리해보면, 외부 인터넷용인지 내부 전용인지의 구분은 라우팅 테이블이 아니라 "어떤 게이트웨이를 연결했는지"에 의해 결정된다고 이해하시면 돼요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

user-service jwt

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !우선 레포지토리(서비스)를 분리한 MSA 환경에서는 보통 JWT 인증을 각 서비스마다 개별적으로 처리하지 않고, API Gateway에서 JWT 검증을 한 번 처리한 뒤에 내부 서비스로 사용자 정보를 전달하는 방식으로 많이 구성해요 !구체적으로는 API Gateway에서 JWT를 검증하고, 토큰에서 추출한 사용자 정보(userId 등)를 HTTP 헤더(예: X-User-Id)에 담아서 각 내부 서비스로 요청을 전달해주는 방식을 주로 사용해요 !그러면 내부 서비스의 Controller에서는 @RequestHeader("X-User-Id") Long userId 이런 식으로 간단하게 사용자 정보를 받아서 쓸 수 있게 돼죠 !이 방식의 장점은 각 서비스마다 JWT 검증 로직이나 Secret Key를 중복해서 관리할 필요가 없다는 점이에요 !인증 관련 책임을 Gateway에 몰아주고, 내부 서비스는 비즈니스 로직에만 집중할 수 있게 되는 구조인거죠 ~참고로 어떤 방식이 더 좋다라기보단, 프로젝트의 규모나 구조에 따라 선택하시면 돼요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

무중단 배포

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"혹시 처음에는 하나 모놀리식으로 만들다가 ASG(auto scaling group과 LB)를 같이 쓰는 모드로 바꿀려면 기존에 설정을 바꾸어 주어야 하나요?"-> 네, 몇 가지 부분은 변경이 필요해요 ! 크게 보면 아래와 같은 부분들을 신경 써주셔야 해요~~우선 로드밸런서(ALB)를 앞단에 두게 되면 기존에 EC2의 퍼블릭 IP나 도메인으로 직접 트래픽을 받던 구조에서, ALB의 DNS로 트래픽을 받는 구조로 바뀌게 돼요 ! 그래서 도메인 설정이나 보안 그룹 설정을 변경해주셔야 해요 ~그리고 ASG를 쓰게 되면 서버 인스턴스가 여러 대로 늘어날 수 있기 때문에, 세션이나 파일 업로드 같은 부분에서 특정 서버에 종속되는 데이터가 없는지 꼭 확인해보셔야 해요 ! 예를 들어 로컬 디스크에 파일을 저장하거나 인메모리 세션을 쓰고 있다면 여러 서버 간에 데이터가 공유가 안 돼서 문제가 생길 수 있거든요 ! 이런 부분은 S3나 Redis 같은 외부 저장소로 이전해주시는 게 좋아요 ~또한 ASG에서 새 인스턴스가 자동으로 올라올 때 애플리케이션이 정상적으로 배포되어 실행될 수 있도록 Launch Template 설정도 잘 맞춰주셔야 해요 !기존 모놀리식 코드 자체를 크게 바꿀 필요는 없고, 인프라 구조 쪽 설정을 순서대로 잘 잡아주시면 전환이 가능해요 :)추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~

workflows/deploy.yml 궁금증

안녕하세요 ! 질문 너무 잘 해주셨어요 ~질문해주신 내용에 답변 드려볼게요 !"혹시 이부분에 APPLICATION_PROPERTIES 말고 secretes 에 변수만 넣어서 하는 방법이 따로 있나요?"-> 네 ! APPLICATION_PROPERTIES는 application.yml 파일 전체 내용을 하나의 secret 값으로 통째로 넣는 방식인데요, 이 대신 각 환경변수를 개별 secret으로 분리해서 관리하는 방법도 있어요 ~예를 들어 DB_URL, DB_USERNAME, DB_PASSWORD 등 각각의 값을 GitHub Secrets에 따로 등록한 뒤, deploy.yml에서 application.yml을 직접 생성하는 방식으로 작성하실 수 있어요 !다만 이 방식은 환경변수 항목이 많아질수록 deploy.yml이 길어지고 관리가 번거로워질 수 있어서, 실제로는 APPLICATION_PROPERTIES 방식처럼 파일 전체를 하나의 secret으로 관리하는 게 더 편리한 경우가 많아요 ~프로젝트 규모나 팀 상황에 따라 편한 방법으로 선택하시면 될 것 같아요 :)추가로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~

31강 이미지내용에 틀린 부분이 있는 것 같습니다.

안녕하세요 tjwcskdle1님! 확인해보니 말씀해주신 대로 3번째 서브넷 부분은 10.10.0.16/29가 맞습니다! 제보해주신 덕분에 다른 수강생분들도 같이 참고할 수 있겠네요:)감사합니다~!!