노션을 처음 사용해봅니다. DB 연결에서 노션이 나오는데 영상과 실제 노션 앱과 화면이 다르게 나오고 화면대로 하려니 다른거 같습니다. 예) invoice-web 페이지를 생성하고 invoice DB 전체 item DB 이렇게 두개를 생성 하는데 연결에 가니 invoice-web이 화면과 달리 보이지 않습니다. 다른 LLM 툴에 물어보니 웹페이지를 만들어서 연결하는게 아니라 DB를 만들고 그 아래에 invoice DB와 item DB를 만들어야 한다는데 현재 이부분에서 더이상 진도가 나가지 못하고 있습니다.
분명히 노션 세팅 잘 했고 연결까지 했는데 데이터베이스 조회 안 되는 분들은 참고해주세요. 강의 영상 촬영 날짜가 아마도 2025년 09월 이전으로 생각 됩니다. 그 이후에 노션 API 버전이 바뀌면서 데이터베이스 조회가 안 되는게 원인입니다. [ 노션 API 업그레이드 가이드 ] https://developers.notion.com/guides/get-started/upgrade-guide-2025-09-03 해결 방법은 2가지인데 API를 구버전을 쓰도록 프롬프트를 유도하거나, 신규 API 버전에 맞춰서 해야 하는데 신규 버전은 "데이터베이스 ID"가 아닌 "데이터베이스 소스 ID"를 필요로 합니다. [ 구버전 프롬프트 ] 노션 api를 "2022-06-28" 버전으로 사용하고 관련 코드 전부 수정해줘. [ 최신 버전 해결 방법 ] 데이터베이스를 열면 위 사진처럼 보일텐데 새로 만들기 왼쪽에 설정 누르면 밑에서 3번째에 데이터 소스 관리 있습니다. 소스 관리에서 위 사진처럼 데이터 소스 ID 복사하시고 그 값을 env에 넣으시면 됩니다.
프로필 수정후 프로필 디테일 화면의 포스트 아이템들에서는 수정된 프로필 내용이 반영이 안되는 것이 확인됩니다. 시나리오대로라면 프로필 수정 후 포스트아이템의 프로필 ui 도 업데이트 해주는게 자연스러운듯 하여 위와 같이 아래 코드를 추가해 주었습니다. 맞을까요? queryClient.resetQueries({ queryKey: QUERY_KEYS.post.userList(updatedProfile.id), });
38강의 4:40초 쯤에, clear 또는 compact, 아님 이미 생성된 파일들을 간략하고 명확하게 정리할 수 있다고 하셨는데, 이 영상에서 알려주신 clear나 compact는 파일을 간략하게 정리하는 명령어는 아니지 않나요? 그냥 클로드 코드와 대화한 내용을 간략하게 정리하는 거 아닌가요? 파일은 어떻게 간략하게 할 수 있다는건지 알려주세요!
(AI 퀀트) 코드 한 줄 안 쓰고 주식 자동 분석 시스템 만들기 feat. Claude CLI
💡 수강생 안내 사항 (커뮤니티 가이드) 학습 관련 질문 : 구체적으로 적을수록 정확한 답변을 받을 수 있습니다. 작성 팁 : 마크다운과 단축키를 활용하면 글을 더 편리하게 작성할 수 있습니다. 사전 검색 : 질문을 남기기 전, 커뮤니티 질문 & 답변에 비슷한 내용이 있었는지 먼저 검색해 보세요. 커뮤니티 매너 : 서로 예의를 지키며 존중하는 분위기를 함께 만들어가요. 서비스 문의 : 인프런 서비스 관련 문의는 1:1 문의하기 를 이용해 주세요. 어떻게 해결해야할까요
WSL 환경에서 수강하시는 분들, tasks.json 파일에 내용이 기록이 안 되면 아래 문제로 보여집니다 https://github.com/cjo4m06/mcp-shrimp-task-manager/issues/61#issuecomment-3240079086 해결법은 딱히 없고 그냥 클로드한테 수동으로 내용 채워달라고 하는게 현재로서는 쓸만해보입니다.
강의를 보다가 궁금한 부분들이 생겨 질문드립니다!! 1. RateLimit Boundary Burst 관련 RateLimit을 설명해주시는 부분을 보면서 한 가지 의문이 들었습니다. 예를 들어 1초에 100개로 제한을 두었을 때, 0.9초 시점에 100개 요청이 들어오고 1초가 되자마자 다시 100개가 들어온다면 실제로는 매우 짧은 시간 안에 200개의 요청이 처리될 수 있지 않을까 하는 생각이 들었습니다. 찾아보니 이러한 문제를 Boundary Burst 라고 부른다는 것을 알게 되었습니다. 이를 해결하기 위해: Sliding Window Sliding Window Counter Token Bucket Leaky Bucket 등의 방식이 있다는 것을 확인했습니다. 실무 관점에서는 이런 경계 구간 Burst 문제를 어떤 방식으로 해결하는지 궁금합니다. 2. Request Collapsing 관련 Request Collapsing을 설명해주신 부분을 보면서, 여러 요청을 하나로 모아서 처리하는 방식으로 Golang의 SingleFlight 패턴을 응용하는 방법도 가능하지 않을까 생각해보았습니다. 이와 관련해서 아래와 같은 예제 코드도 작성해 보았습니다. private final StringRedisTemplate redisTemplate; private final Map<String, CompletableFuture<?>> singleFlightMap = new ConcurrentHashMap<>(); @Override public <T> T fetch(String key, Duration ttl, Supplier<T> supplier, Class<T> clazz) { String cached = redisTemplate.opsForValue().get(key); if (cached != null) { return DataSerializer.deserializeOrNull(cached, clazz); } CompletableFuture<T> newFuture = new CompletableFuture<>(); CompletableFuture<T> existing = (CompletableFuture<T>) singleFlightMap.putIfAbsent(key, newFuture); if (existing != null) { // 다른 스레드가 실행 중 → 기다림 return existing.join(); } // 내가 실행자 (락 없이 실행) try { T result = refresh(key, ttl, supplier); newFuture.complete(result); return result; } catch (Throwable t) { newFuture.completeExceptionally(t); throw t; } finally { singleFlightMap.remove(key, newFuture); } } private <T> T refresh(String key, Duration ttl, Supplier<T> dataSourceSupplier) { T result = dataSourceSupplier.get(); put(key, ttl, result); return result; } 이 방식은 분산 락이나 폴링 방식 없이도 동일 인스턴스 내 요청을 모을 수 있다는 장점이 있다고 생각했습니다.물론 이 방법은 모든 분산 서버 간 요청을 하나로 모으는 것은 아니기 때문에 , 서버 인스턴스 수만큼은 요청이 발생할 수 있다는 한계가 있다고 생각합니다. 하지만 인스턴스 수가 많지 않다면, 분산 락으로 인한 오버헤드나 복잡성을 줄이면서도 어느 정도 트래픽을 제어할 수 있는 현실적인 선택지가 될 수 있지 않을까 하는 생각이 들었습니다. 실무 관점에서는 이런 방식에 대해 어떻게 평가하시는지 궁금합니다. 3. Write Through 방식에서의 장애 처리 Write Through 방식에서는 일반적으로: DB에 먼저 저장 동일 데이터를 Redis에도 저장 하는 구조로 이해하고 있습니다. 그런데 만약: DB에는 쓰기 성공 Redis에는 쓰기 실패 하는 상황이 발생한다면, 이 경우를 트랜잭션 실패로 간주해야 하는지 궁금합니다. Redis 장애로 인해 캐시 반영이 실패했을 때, 핵심 트랜잭션(DB 쓰기)까지 롤백해야 하는지 아니면 캐시는 보조 저장소로 보고 DB 성공을 기준으로 처리해야 하는지 두 저장소 간 원자성을 반드시 보장해야 하는 설계인지 실무에서는 어떤 기준으로 판단하는지 궁금합니다.