강의 내용중에 실제로는 api key를 입력하셨지만, 강의 중에 api key를 굳이 입력하지 않고, .mcp.json에서 api key 관련 내용을 제거하셨는데 api key를 제거하고, use context7 를 입력하였더니 아래와 같이 api key가 필요하다고 나옵니다. 혹시 context7의 정책이 변경된거라고 인지하면될까요?? Invalid API key. Please check your API key. API keys should start with 'ctx7sk' prefix.
보시는대로 네이버냐 구글이냐 가르는 스위치 노드 인풋까지는 정상적으로 들어옵니다. 강의대로 똑같이 했는데, 아웃풋이 안 나옵니다. 왜 이런걸까요? 참고로 구글로 테스트해보면 구글은 잘 됩니다. 더 참고로 말씀드리면 네이버 정크 메일 노드는 이전 노드 아웃풋이 없으니 당연히 이렇게 인풋이 없습니다.
안녕하세요! 수강자 쵸잉입니다 강의듣다가 질문사항이 생겨 남깁니다. ArticleViewCountRepository 에서 read 메서드 보면 현재 코드에서 조회수 조회를 할때 레디스에서만 가져오는데 이전 강의에서 레디스는 휘발메모리기 때문에 백업용 rdb 를 주기적으로 업데이트 시켰는데 그럼 레디스에서 값이 없을경우 백업용 rdb 도 한번 조회해봐야되지 않나 싶어서 질문드립니다!
안녕하세요. 강의 잘 들었습니다. 현재 시간이 별로 없어서 typescript react nextjs 코드 구현 부분쪽은 다봤네요. 해서 제가 궁금한 것은 일반적인 nextjs project architecture 입니다. 물론 유연하게 상황에 맞춰서 하는 게 최선이겠지만 입문자이다 보니 일반적인 형태를 알고 경험을 쌓으며 해당 부분 지식을 쌓고 싶은 마음입니다. 해서 입문점으로 일반적인 nextjs project architecture에 대하여 알고싶습니다. 감사합니다.
현재 강의에서 웹 디렉터리를 모르는 상태이지만 웹 쉘을 웹 디렉터리에 업로드 한 상태로 가정하여 실습을 진행해 주셨습니다 웹 디렉터리를 파악하지 못한 상태에서, 게싱공격을 제외하고 웹디렉터리에 웹 쉘을 업로드 하는게 가능한가요? 웹 디렉터리를 파악 했다면 경로조작 문자를 이용해서 웹 디렉터리에 파일 업로드가 가능할것 같은데 파악하지 못하여도 가능한지 여부가 궁금합니다.
chatgpt,google image, seedream의 경우 셋팅이 되어있지 않아 테스트용으로 flux-1.1-pro로 변경 후 실행을 하여봤습니다. 이렇게 사진처럼 변경을 했구요 작동을 해보니 flux-1.1pro로 정확히 인식된것을 확인하였음에도 switch에서 더이상 넘어가지 않습니다..ㅠㅠ 뭐 솔직히 기존에 이미지에서 붙여넣은거라 딱히 바꿀것도 없긴한데 왜 이게 제대로 넘어가지 않을까요? 혹여나해서 image쪽 n8n이 잘못되었나 체크해봤음에도 불구하고 그건 문제 없이 정상작동하는 것을 확인하였습니다 ㅠㅜ
안녕하세요 강사님. 지난번 '어드민 예약 변경 시 쿠폰 회수' 관련 질문을 드렸던 수강생입니다. 답변 주신 내용을 바탕으로 설계를 보완하던 중, 스냅샷 데이터의 범위와 확장성 에 대해 추가적인 고민이 생겨 조언을 구합니다. [현재 아키텍처 상황] 현재 예약 테이블에는 예약 시점의 가격 정보를 JSON 형태의 스냅샷 으로 저장하고 있습니다. 이유: 가격 결정 요소(할인, 이벤트, 기업 지원 등)가 빈번하게 변경/추가되어 RDB 컬럼으로 대응하기 어렵기 때문입니다. 저장 데이터: 현재는 '결과값' 위주로 저장합니다. (예: 적용된 할인 명, 타입(정액/정률), 최종 할인 금액) [직면한 문제: 변경 시점의 기준 모호성] 예약 시점(T1)과 변경 시점(T2) 사이에 정책이 변경되었을 때, 어드민에서 예약을 수정하면 어떤 정책을 따라야 하는가 에 대한 딜레마입니다. 만약 기획 요구사항이 "변경 시점(T2)의 정책이 아니라, 최초 예약 시점(T1)의 정책 조건을 유지한 채 금액만 다시 계산해 주세요" 라고 한다면 문제가 복잡해집니다. 현 구조의 한계: 현재 JSON에는 '결과(할인액)'만 있고 '조건(최소 결제 금액, 당시 허용된 옵션 목록 등)'은 없습니다. 예상되는 부작용: 이를 해결하려면 예약 시점의 모든 검증 조건(Condition) 을 JSON에 다 때려 넣어야 합니다. 이렇게 되면 도메인 로직이 바뀔 때마다 JSON 스키마도 계속 비대해지고, 과거 JSON 데이터와 현재 로직 간의 정합성을 맞추기 매우 까다로워질 것 같습니다. [질문] 이처럼 "빈번하게 변하는 가격 정책"과 "과거 기준 수정"을 동시에 만족해야 할 때, 실무에서는 보통 어떤 접근 방식을 취하나요? JSON 스냅샷 확장: 다소 복잡해지더라도 예약 시점의 검증 조건(Parameter)들까지 모두 JSON에 스냅샷으로 남기는 게 맞나요? (JSON 컬럼 사용이 잘못된 선택이었을까요?) Policy Versioning (정책 버전 관리): 아니면 가격/할인 정책 테이블 자체를 버전 관리(Effective Date 등)하여, 예약 시점의 policy_version_id 를 매핑해두고 로직을 태우는 방식을 써야 할까요? 현실적인 타협: 아니면 보통 어드민 변경 건은 "재계산 불가(단순 금액 입력)"로 처리하거나, "무조건 현재(T2) 정책"을 따르게 하는 등 복잡도를 낮추는 타협점을 찾나요? 확장성 있는 가격 스냅샷 설계에 대한 강사님의 경험과 조언을 부탁드립니다..!