안녕하세요 태경님 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "join시 인덱스 방식이 달라지는지 궁금합니다." -> 조인이라서 달라진다기보다는, 그 쿼리에서 어떤 조건이 데이터를 가장 많이 걸러주느냐에 따라 인덱스 걸 위치가 달라진다고 보시면 돼요 ! 조인에서는 MySQL이 한 테이블을 먼저 읽고 그 결과 건수만큼 반대편 테이블을 찾아가기 때문에, 먼저 읽는 테이블의 결과를 최대한 줄이는 게 핵심이에요 ! 유저 이름은 동등 조건(=)이라 범위 조건인 created_at보다 훨씬 적은 행으로 좁혀지다보니 u.name 에 인덱스를 거는 게 효과적이었던 거죠 ! EXPLAIN으로 어떤 테이블이 먼저 읽히는지 직접 확인해보시면 훨씬 이해가 잘 되실 거예요 :) "또, 다른 곳에서 파티셔닝, 클러스터링?? 이라는 용어들도 보이던데 이것도 인덱스에서 파생된 것일까요?" -> 인덱스에서 파생된 건 아니고 별개의 기술이에요 ! 파티셔닝은 큰 테이블을 특정 기준으로 쪼개 저장해서 필요한 조각만 읽게 하는 방식이구요, 클러스터링은 InnoDB에서 PK 기준으로 데이터가 정렬되어 저장되는 걸 뜻하기도 하고 DB 서버를 여러 대 묶는 걸 뜻하기도 해요 ! 다만 지금 단계에서는 굳이 파고들지 않으셔도 괜찮아요ㅎㅎ 인덱스 감부터 확실히 잡으신 뒤에 보셔도 늦지 않아요 :) 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! 우선 첨부해주신 이미지를 보니 CNAME 이름에서 api 부분까지 같이 빼신 게 원인으로 보이네요! ACM에서 알려주는 CNAME 이름은 _a42f376b39c…. api.본인도메인.p-e.kr 형태일 텐데요, 내도메인한국은 입력칸 바로 오른쪽에 . 본인도메인.p-e.kr 이 이미 붙어있어서 그 뒷부분만 빼고 넣어야 해요 ! 즉 a42f376b39c….api 이렇게 api까지 포함해서 입력해주셔야 해요! 지금처럼 api까지 빼버리면 실제로는 a42f376b39c…. 본인도메인.p-e.kr 이라는 엉뚱한 주소로 레코드가 만들어져서, ACM이 확인하러 가는 주소와 달라 계속 검증 대기중에 머물게 돼요 ! 인터넷에서 보신 설명은 도메인 부분만 빼라는 의미였는데 api까지 빼신 것으로 보이네요~ 값 부분은 지금 입력하신 게 정상이니 그대로 두시면 되구요, 이름만 수정하시고 5~10분 정도 기다렸다가 ACM 창을 새로고침해보시면 검증이 완료될 거예요 ! 무료 도메인은 레코드 반영이 조금 느릴 수 있어서 길게는 30분 정도 걸릴 수도 있으니 여유있게 기다려보셔도 좋아요 :) 추가로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 지원님 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "비전공자도 합격하는 개발자 이력서/포트폴리오 작성법' 강의 관련:저는 IT 인프라(시스템엔지니어, 클라우드 엔지니어)를 목표로 하고 있는데, 개발자 대상의 이력서/포트폴리오 강의를 수강해도 괜찮을까요?" -> 네, 수강하셔도 괜찮아요 ! 이력서와 포트폴리오를 작성하는 핵심 원칙(내가 한 일을 어떻게 어필할지, 어떤 구조로 작성해야 서류 통과율이 높아지는지 등)은 개발자든 인프라 엔지니어든 직군에 상관없이 동일하게 적용돼요 ~ 프로젝트 경험을 정리하는 방식이나 기술적인 어필 포인트를 잡는 방법도 인프라 직군에 그대로 활용하실 수 있어요! "지원 시기 관련:아직 프로젝트와 포트폴리오가 완성되지 않은 상태입니다. 지금 당장 자격증과 자기소개서만으로 조금씩 지원을 시작해 보는 것이 괜찮을까요? 아니면 2달 반 뒤 프로젝트와 포트폴리오까지 완전히 갖춘 후 지원하는 것이 좋을까요? " -> 지금부터 조금씩 지원을 시작해보시는 걸 추천드려요 ! 지원 자체가 하나의 연습이 되기도 하고, 서류를 넣어보면서 시장에서 어떤 역량을 요구하는지 파악할 수 있거든요 ! 또 운이 좋으면 면접 경험까지 쌓을 수 있어서 실전 감각을 기르는 데 큰 도움이 돼요 ~ 그리고 2달 반 뒤에 프로젝트와 포트폴리오가 완성되면 그때 이력서를 업데이트해서 본격적으로 지원하시면 돼요 ! 완벽하게 준비된 상태를 기다리기보다는, 준비하면서 동시에 지원하는 게 취업 시기를 앞당기는 데 훨씬 유리해요:) 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "route53이 프리티어에서 안되다 보니 해당 DNS 레코드 생성도 안되는 것 같은데 HTTPS 인증서 발급이 안되면 다른 방법은 없나요?" -> 방법 있어요 ! 지금 상황은 도메인을 내도메인.한국에서 발급받으셔서 생긴 현상이에요 ! 첨부해주신 화면에서 "도메인이 Route 53에 있습니까?"가 "아니요"로 나와 있죠? ACM의 "Route 53에서 레코드 생성" 버튼은 말 그대로 Route 53 호스팅 영역에 도메인이 등록돼 있을 때만 자동으로 레코드를 만들어주는 편의 기능이라서, 다른 곳에서 발급받은 도메인은 이 버튼으로는 검증이 안 돼요 ~ 대신 검증용 CNAME 레코드를 내도메인.한국 쪽 DNS 설정에 직접 등록해주시면 똑같이 발급받으실 수 있어요 ! ACM 인증서 상세 화면에 들어가시면 도메인 항목에 CNAME 이름과 CNAME 값이 나와 있어요 ~ 이 두 값을 복사해서 내도메인.한국의 DNS 설정에 CNAME 레코드로 추가해주시면 돼요 ! 5~10분 정도 기다렸다가 ACM 화면 새로고침해보시면 "발급 완료"로 바뀌어 있을 거예요! (길게는 30분 정도 걸릴 때도 있어요 ~) 진행하시다가 막히시면 화면 캡처해서 댓글로 추가 질문 남겨주세요:) 또한 이 외로 궁금하신 점 있으시면 언제든 편하게 추가 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! 꼼꼼하게 봐주셨네요! 말씀해주신 대로 표준 대기열은 순서를 완벽하게 보장하진 않고, 엄격한 순서 보장이 필요하면 FIFO 큐를 사용해야 하는 게 맞아요 ~ 다만 상단의 문장은 SQS라는 서비스가 어떤 서비스인지 큰 그림을 먼저 잡아드리기 위한 설명이라고 봐주시면 좋을 것 같아요! 큐라는 자료구조 자체가 먼저 들어온 메시지부터 처리하는 구조이다 보니, SQS의 기본 동작 방식을 이렇게 표현해두었어요 ! 그리고 바로 아래 [유형] 부분에서 표준 대기열과 FIFO 큐를 나눠서 순서 보장 여부를 설명드리고 있어서, 자료를 순서대로 쭉 읽으시면 자연스럽게 이해되실 거라 생각해요 :) 시험에서도 "순서를 정확히 보장해야 한다", "정확히 한 번만 처리해야 한다" 같은 키워드가 나오면 FIFO 큐를 고르시면 되니, 이 부분만 확실히 잡아두시면 충분해요 ~ 그래도 헷갈리실 수 있는 부분이라고 말씀해주신 만큼, 표현을 조금 더 명확하게 다듬을 수 있을지 한 번 검토해보겠습니다! 이렇게 자료 꼼꼼히 봐주시고 피드백까지 남겨주셔서 감사드려요😊 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 태수님 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! 우선 태수님께서 생각하신 방향도 충분히 일리가 있어요 ~ 실제로 부분 선결제가 선결제 없음보다 할인율이 조금 더 높은 건 맞구요ㅎㅎ 다만 이 문제에서는 "다년 계약에 묶이는 것은 원치 않는다"라는 조건이 핵심 힌트인데요! 여기서 말하는 "묶인다"는 게 단순히 계약 기간만을 의미하는 게 아니라, 비용이 미리 묶여버리는 상황까지 포함하는 뉘앙스로 보시면 돼요 ! 즉 유연성을 최우선으로 두고 있는 상황이라고 해석하시면 돼요~ 또 현실적으로 봤을 때 No Upfront와 Partial Upfront의 할인율 차이는 몇 %p 정도로 그리 크지 않아요 ! 반면 부분 선결제는 목돈이 초기에 나가야 하다 보니, 유연성을 중요하게 여기는 회사 입장에서는 그 정도 할인율 차이를 위해 현금을 미리 묶어둘 이유가 크지 않은 거죠! 그래서 실제 시험에서도 "유연성", "묶이는 걸 원치 않는다" 같은 키워드가 나오면 No Upfront 쪽을 고르시면 되고, 반대로 "비용 절감을 최대화하고 싶다", "선결제 가능하다" 같은 표현이 나오면 그 때 All Upfront나 Partial Upfront를 고르시면 돼요:) 이렇게 키워드 위주로 정리해두시면 헷갈리는 상황이 많이 줄어드실 거예요 ! 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 쿠카이든님! 질문 잘 해주셨습니다~~ 실무에서는 핵심 용어를 수기로 등록하고 실제 검색 데이터를 보면서 조금씩 보완하는 방식 을 많이 사용합니다. 구체적인 예로, 회사에서 상품을 관리하기 위해 개발자가 아니어도 관리자 화면에서 검색 규칙이나 동의어 등을 수정할 수 있는 서비스를 활용해서 관리를 합니다. 검색 설정을 변경할 때마다 개발팀에 요청하지 않고, 상품과 고객을 잘 아는 운영 담당자가 직접 관리하는 방식입니다. 처음에는 상품명, 업계 용어, 약어, 영문·한글 표현처럼 명확한 동의어를 담당자가 직접 등록합니다. 이후 검색 결과가 없었던 검색어, 검색 후 클릭이 발생하지 않은 검색어, 고객 문의에서 자주 나오는 표현을 주기적으로 확인해 동의어를 추가합니다. 검색 분석 도구에서도 결과가 없거나 클릭되지 않은 검색어를 확인하고, 이를 동의어나 검색 규칙으로 보완할 수 있습니다. 정리하자면, 동의어 전체를 한 번에 수기로 정의하지 않고, 초기 핵심 용어는 사람이 등록하고, 검색 로그와 고객 문의를 통해 지속적으로 보완는 방식이 가장 일반적입니다. 이 외로 또 궁금하신 점 있으시면 편하게 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "왜 해당 문제에서는 "Direct Connect"가 비용 효율적인 방법이 되는건가요??" -> 이 문제에서는 Direct Connect를 쓸지 말지를 고르는 게 아니라, 이미 Direct Connect가 연결되어 있는 상황이라는 점이 핵심이에요 ! 문제 지문을 보시면 "AWS Direct Connect를 통해 연결했습니다"라고 이미 전제가 깔려 있죠. 즉 전용선 구축 비용은 이미 지불하고 있는 상태고, 여기서 물어보는 건 "그 전용선을 통해 오가는 데이터 전송 비용을 어떻게 줄일 것인가?" 이에요 ! Direct Connect도 데이터를 전송한 양(GB)만큼 요금이 붙어요 ~ 그래서 온프레미스에 시각화 도구를 두면 쿼리할 때마다 50MB짜리 결과가 전용선을 타고 넘어오게 되고, 그만큼 전송 비용이 계속 쌓이게 되죠 ! 반면에 시각화 도구를 데이터 웨어하우스와 같은 리전에 두면, 무거운 50MB 쿼리 결과는 AWS 내부에서만 왔다갔다 하고, 사용자한테는 최종 결과물인 500KB만 전용선을 타고 나가게 돼요! 전송량이 100분의 1로 줄어드니 전송 비용도 그만큼 줄어드는 거죠! 정리하면 개념 강의에서 말씀드린 "Direct Connect는 비싸다"는 여전히 맞는 얘기이고, 이 문제는 이미 깔아둔 Direct Connect 위에서 데이터가 오가는 양을 최소화하는 게 핵심이라고 이해하시면 돼요 :) 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! 우선 '오리진'은 CloudFront가 원본 데이터를 가져오는 서버를 뜻해요 ! 멀티 오리진은 CloudFront 배포 하나에 원본 서버를 여러 개 등록해두고, 요청 경로에 따라 각각 다른 서버로 보내주는 걸 말해요 ~ 예를 들면 example.com/index.html 요청 -> S3에서 가져옴 example.com/api/orders 요청 -> 온프레미스 서버에서 가져옴 경로가 다른 게 맞긴 한데, 경로는 어디로 보낼 지 판단하는 기준일 뿐이고 핵심은 그 경로에 따라 요청이 도착하는 서버 자체가 완전히 달라진다는 점이에요 ! 그래서 '여러 개의 오리진을 가진다'라고 표현하는 거예요 ! 덕분에 사용자는 example.com 하나로만 접속하는데 뒤에서는 S3와 온프레미스가 나뉘어 처리되고, WAF도 CloudFront 앞에 한 번만 붙이면 둘 다 보호할 수 있어서 정답이 된 거죠:) 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
