안녕하세요 지원님 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! "비전공자도 합격하는 개발자 이력서/포트폴리오 작성법' 강의 관련:저는 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 앞에 한 번만 붙이면 둘 다 보호할 수 있어서 정답이 된 거죠:) 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 ! 질문 잘 해주셨어요~ 질문해주신 내용에 대해 답변드려볼게요! 우선 멀티 컬럼 인덱스는 '정렬 순서'만 다른 게 아니라, 인덱스 표 안에 컬럼이 2개 다 들어있다는 점이 핵심이에요 ! (department) 인덱스만 걸었을 때는 인덱스 표에 department 값밖에 없어요 ! 그래서 department = 'Sales'인 데이터 10만 개를 인덱스에서 찾아낸 뒤, created_at 조건을 확인하려면 실제 테이블로 하나하나 다 찾아가야 해요 ! 그래서 rows가 191,314처럼 크게 잡히고 성능이 덜 향상됐던 거예요 ! 반면 (department, created_at) 멀티 컬럼 인덱스는 인덱스 표 안에 created_at까지 들어있어요 ! department = 'Sales'로 범위를 좁힌 뒤, 그 안에서 created_at이 이미 정렬되어 있으니 최근 3일치 구간만 인덱스 안에서 바로 찾아낼 수 있어요 ~ 실제 테이블에 접근하는 데이터가 100개 수준으로 확 줄어드는 거죠! (created_at, department)도 마찬가지로 created_at으로 1,100개 정도로 좁힌 뒤, department 값도 인덱스에 있으니 인덱스 안에서 걸러낼 수 있어요 ~ 결국 두 멀티 컬럼 인덱스 모두 '실제 테이블에 액세스하는 데이터 수'가 적어지기 때문에, idx_created_at과 비슷한 성능이 나오게 된 거죠 ! 이 외로 궁금하신 점 있으시면 또 질문 남겨주세요~~
안녕하세요 dongdong2님! 강의 잘 봐주셔서 감사합니다ㅎㅎ 정확히는 인덱스가 영향을 주는 건 execution 구간입니다. 여기는 110ms → 7~11ms로 이미 10배 이상 깔끔하게 줄었어요. 실습에서 확인하려던 효과는 완벽하게 나온 겁니다. 그럼 510ms 스파이크의 정체는 뭘까요 ? 튄 부분을 보면 execution이 아니라 fetching(499ms) 입니다. fetching은 1,028행을 DB에서 클라이언트(DataGrip/DBeaver 등)로 전송하고 그리드에 렌더링하는 시간이에요. 인덱스와는 무관한 구간이고, 네트워크 상태·JVM GC·클라이언트 UI 렌더링 등에 따라 수백 ms씩 흔들립니다. 즉 "인덱스가 아직 캐싱 안 돼서"라는 설명은 방향이 살짝 다릅니다. 그 논리라면 execution이 튀어야 하는데, 첫 실행부터 이미 11ms였거든요. 정리하자면 크게 신경 쓰지 않으셔도 되는 정도의 오차입니다. 이 외로 또 궁금하신 점 있으시면 편하게 질문 남겨주세요~~
