01시작 전 확인
현재 장을 시작하거나 다시 이어갈 때
먼저 확인 · 현재 장과 실제 프로젝트를 확인. 기존에 확인한 맥락은 재사용.
12장 시작해.자료와 브리핑을 저장·재사용해 호출을 줄이고 품질을 유지합니다.
11장의 운영 서비스와 근거 검증이 있습니다.
필요한 도구 · 기존 서버 · DB·Redis 클라이언트
이미 준비한 계정과 기능은 그대로 이어갑니다.
과거 측정값을 새 실측으로 쓰거나 캐시 때문에 품질 검사·데이터 기준일을 버리지 않습니다.
현재 단계와 입력 위치를 확인한 뒤 하나씩 복사하세요.
현재 장을 시작하거나 다시 이어갈 때
먼저 확인 · 현재 장과 실제 프로젝트를 확인. 기존에 확인한 맥락은 재사용.
12장 시작해.이번 장 Secret 입력창 준비
먼저 확인 · 현재 ai-stock-briefing과 기존 인증값 보관 방식 확인.
ai-stock-briefing 프로젝트에서 이번 장에 쓸 Secret 입력창을 실행해줘.
입력칸은 `Supabase Database URL`, `Upstash Redis REST URL`,
`Upstash Redis REST Token` 세 개로 만들고, 앞 장에서 이미 넣은 인증키도
같은 화면에서 다시 넣을 수 있게 해줘. 빈칸으로 두고 저장하면 그 값은
기존 것을 그대로 남겨줘.
세 입력칸의 값은 순서대로 `SUPABASE_DATABASE_URL`,
`UPSTASH_REDIS_REST_URL`, `UPSTASH_REDIS_REST_TOKEN` 이름으로 저장해줘.
브라우저의 내 컴퓨터 주소에서만 열고, 입력값은 Git에서 제외된
`.env.local`에 저장해줘. 실제 값은 대화와 실행 결과에 출력하지 마.Supabase 연결
먼저 확인 · 독자가 지역·현재 플랜을 확인하고 연결 문자열을 로컬 입력창에 저장했는지 확인.
국내 주식 한눈에 서비스에 Supabase Database를 연결해줘.
실제 연결 정보는 내가 안전한 입력 위치에 직접 넣을게. 대화창에 값을
붙여 넣으라고 하지 말고 `SUPABASE_DATABASE_URL` 환경변수로만 읽어줘.
Secret이 코드, Git, 브라우저, 로그와 오류 메시지에 노출되지 않는지도
검사해줘.주식 저장·갱신 기준 구현
먼저 확인 · Supabase 연결 결과 확인.
금융위원회 데이터를 Supabase에 저장하고 다시 사용할 때 갱신 기준도 함께
적용해줘.
최신 거래 기준일을 찾은 결과는 1시간, 기준일이 확정된 주식 시세,
최근 1년 차트, 시장 지수와 상장종목 정보는 24시간 동안 재사용해줘.
유효시간이 지나면 저장된 값을 최신 데이터처럼 사용하지 말고 금융위원회
API에서 다시 확인해줘.
더 이상 유효하지 않은 저장 데이터가 계속 쌓이지 않도록 만료된 데이터만
안전하게 정리해줘. 아직 유효한 데이터와 다른 테이블은 삭제하지 마.
지금까지 만든 기능과 데이터 기준일 표시는 그대로 유지해줘.Redis 연결
먼저 확인 · 독자가 Upstash 비용·지역을 확인하고 REST URL·쓰기 Token을 로컬 입력창에 저장했는지 확인.
같은 근거로 만든 Gemini 브리핑을 Upstash Redis에 Cache해줘.
접속 정보는 내가 안전한 입력 위치에 직접 넣을게. 실제 값은 대화창이나
코드에 붙여 넣지 말고 `UPSTASH_REDIS_REST_URL`과
`UPSTASH_REDIS_REST_TOKEN` 환경변수로만 읽어줘.
URL과 Token이 Git, 브라우저, 로그, 오류 메시지와 검증 결과에 노출되지
않는지도 검사해줘.브리핑 재사용 조건 구현
먼저 확인 · Redis 연결과 11장의 현재 모델·구조화 브리핑 확인.
11장에서 확인한 모델을 그대로 사용해줘. 모델 ID를 바꿨다면
Cache key 구분과 관련 Test가 새 모델과 맞는지 확인해줘.
같은 근거로 만든 Gemini 브리핑은 Redis에서 1시간 동안 재사용해줘.
Cache에는 검증을 통과한 구조화 브리핑 전체를 저장해줘. 한 문장만 저장하지
말고 제목, 핵심 브리핑, 시장·가격·공시 설명, 알 수 없는 것과 각 항목의
근거 ID를 함께 보존해줘.
사용한 Gemini 모델도 Cache를 구분하는 조건에 포함해줘. 모델이 바뀌면
이전 모델로 만든 Cache 결과를 재사용하지 마.
다만 1시간 안이라도 종목코드, 브리핑에 사용한 근거, Gemini 모델, 결과에
영향을 주는 주요 프롬프트가 바뀌면 이전 결과를 사용하지 말고 새로 만들어줘.
요청마다 달라지는 생성 시각은 Cache를 구분하는 값에서 제외해줘.
같은 조건의 Cache가 있으면 Gemini를 다시 호출하지 말고 저장된 결과를
바로 사용해줘.
일반적인 수정이나 배포 때문에 Redis 전체 Cache를 삭제하지 마.
검증을 통과한 브리핑만 Cache에 저장하고, Secret은 코드·브라우저·로그와
오류 메시지에 노출하지 마.사용량 한도 처리 구현
먼저 확인 · 브리핑 Cache와 현재 한도 오류 처리 확인.
Gemini 호출이 사용량 한도 때문에 실패하는 경우도 처리해줘.
Gemini 응답에서 다시 호출할 수 있는 시간을 확인할 수 있다면 그 시간을
저장하고, 그때까지 Gemini를 다시 호출하지 마.
사용량 한도 상태보다 Cache를 먼저 확인해줘. 재사용할 Cache가 있으면
Gemini를 새로 호출하지 말고 기존 브리핑을 보여줘.
Cache가 없고 대기 중이라면 브리핑 생성 버튼을 막고, 반복해서 눌러도
Gemini 요청이 나가지 않게 해줘.
화면에는 “Gemini 사용 한도에 도달했습니다”라고 알리고, 다시
사용할 수 있는 시간이 확인되면 언제부터 다시 시도할 수 있는지
사용자에게 보여줘.
다시 호출할 수 있는 시간이 지나면 사용자가 다시 누르지 않아도 버튼을
자동으로 활성화해줘.
Gemini가 다시 호출할 수 있는 시간을 알려주지 않으면 내부 기본 대기값으로
반복 호출을 막되, 그 값을 확인된 재시도 시각처럼 화면에 표시하지 마.
한도 오류와 일반적인 서버 오류는 서로 구분해서 처리하고, Gemini의 내부
오류 메시지나 API Key 같은 정보는 사용자 화면에 그대로 보여주지 마.
이 동작도 Test에 추가해줘. 한도에 도달한 동안 Gemini 호출이 추가로
발생하지 않고, 다시 사용할 수 있는 시간이 지난 뒤에만 호출할 수 있는지
확인해줘.로컬 저장·재사용 검증
먼저 확인 · DB·Cache·한도 처리가 구현됐는지 확인.
Database와 Cache 설정을 반영한 현재 버전을 확인해줘.
저장한 주식 데이터를 실제로 다시 사용하는지, TTL이 지나면 원본에서 다시
확인하는지, 같은 조건의 Cache가 있으면 Gemini를 다시 호출하지 않는지
확인해줘.
Gemini 사용 한도에 도달한 동안에는 추가 호출을 보내지 않고 브리핑 생성
버튼을 막는지, 다시 호출할 수 있는 시간이 확인된다면 그 시간이 지난
뒤에만 다시 사용할 수 있게 되는지도 확인해줘.
기존 주가·차트·공시·AI 브리핑 기능과 투자 추천·예측 금지 기준은 바꾸지
마.
Cache에서 구조화 브리핑을 꺼낸 뒤에도 핵심·시장·가격·공시·알 수 없는 것,
대표 공시, 사용 모델과 출처가 그대로 유지되는지 확인해줘. AI 단계가
실패하면 프로그램이 확인한 사실 다음에 오류가 표시되는지도 확인해줘.
Secret이 코드, Git, 브라우저, 로그와 오류 메시지에 노출되지 않는지도
확인해줘.
필요한 Test와 기존 기능 Regression을 확인한 뒤 문제가 없으면 완료했다고
알려줘.Cache 이후 품질 검증
먼저 확인 · 저장·재사용 결과 확인.
Database와 Cache를 적용한 뒤에도 앞에서 정한 AI 브리핑의 품질 기준이
그대로 유지되는지 확인해줘.
프로그램이 계산한 사실과 AI 설명이 구분되는지, 현재 근거만으로 알 수 없는
것이 표시되는지, 근거 없는 인과관계·미래 예측·투자 추천이 들어가지 않는지
Regression으로 확인해줘.
Cache에 저장했다가 다시 꺼낸 뒤에도 구조화된 다섯 목록과 근거 ID, A·B·I
대표 공시, 사용 모델과 출처가 그대로 유지되는지 함께 확인해줘.환경 등록 후 전송·배포 확인
먼저 확인 · 독자가 Vercel Production에 정본 세 변수로 연결값을 등록했는지 확인. 등록했어라는 원문을 사실로 추정하지 않음.
이번 작업을 마무리하고 GitHub 저장소에도 보내줘.
Vercel에도 로컬과 같은 `SUPABASE_DATABASE_URL`, `UPSTASH_REDIS_REST_URL`,
`UPSTASH_REDIS_REST_TOKEN` 이름으로 연결값을 등록했어.
보내기 전에 서버가 이 세 이름을 사용하는지 확인해줘. 실제 값은 출력하지 마.
배포된 주소에서 같은 종목 화면을 두 번 열고, 매번 AI 브리핑 만들기 버튼을
눌러 응답까지 확인해줘. 같은 근거 자료와 Cache 유효시간 안에서 진행해줘.
첫 번째 요청의 생성·재사용 여부를 구분하고, 두 번째 요청에서 저장한 데이터와
브리핑을 다시 썼는지, 금융위원회와 Gemini의 추가 호출이 없었는지
서버의 처리 기록으로 확인해서 알려줘. 비밀값은 출력하지 마.독자가 기본 동네 또는 종목을 바꾸고 싶을 때만
먼저 확인 · 기본 실습을 마친 뒤 독자가 선택한 변경인지 확인. 이 변경 없이도 다음 장으로 진행할 수 있음.
홈 화면 맨 위에 내가 고른 종목을 고정해서 보여줘. 삼성전자, 종목코드
005930이야.이번 장 완료 조건을 확인할 때
먼저 확인 · 현재 장과 실제 프로젝트를 확인. 기존에 확인한 맥락은 재사용.
장 완료 확인해줘.디버깅 → 내 정상 기록으로 복구 → 장별 Source로 재시작Git 명령을 외우거나 직접 입력할 필요는 없습니다. 아래 요청문을 그대로 붙여넣으면 Claude Code가 확인하고 처리합니다.
1. 디버깅 --- 먼저 무엇이 어긋났는지 그대로 말하고 고쳐봅니다. 대부분 여기서 해결됩니다.
지금 작업이 책과 다르게 진행됐어.
현재 상태와 화면에 나온 문제를 확인하고 원인을 찾아서 고쳐줘.Database나 Cache에 연결되지 않을 때는 값이 잘못된 것인지, 아직 읽히지 않는 것인지부터 갈라야 합니다.
Database와 Cache 연결이 안 돼.
접속에 쓰는 환경변수가 실제로 읽히는지, 값이 있는지 없는지만 확인해줘.
실제 값은 출력하지 마.두 번째 요청이 첫 번째와 똑같이 느리면 저장된 값을 쓰지 않고 있는 것입니다.
같은 종목을 두 번 열었는데 두 번째도 느려.
저장된 데이터와 브리핑을 실제로 다시 쓰고 있는지,
매번 원본과 Gemini를 다시 부르고 있는지 확인해서 알려줘.브리핑이 계속 예전 문장으로 나오면 Cache를 구분하는 조건을 확인합니다.
근거가 바뀌었는데 브리핑이 예전 문장 그대로야.
Cache를 구분하는 조건에 근거와 모델이 들어가 있는지 확인하고 고쳐줘.브리핑만 만들어지지 않을 때는 사용량 한도인지 다른 오류인지 갈라야 합니다.
AI 브리핑만 만들어지지 않아.
사용량 한도에 도달한 상태인지, 다른 오류인지 구분해서 알려줘.
실제 키 값은 출력하지 마.2. 내 정상 기록으로 복구 --- 해결되지 않으면 실습하면서 내 프로젝트에 남겨둔 정상 기록으로 돌아갑니다. 지금까지 한 작업은 먼저 따로 보존합니다.
현재 작업은 잃지 않도록 먼저 별도로 보존해줘.
이 프로젝트에서 마지막으로 정상 동작했던 상태를 찾아 안전하게 복구해줘.3. 장별 Source로 재시작 --- 그래도 이어갈 수 없을 때 사용합니다. 12장의 남은 실습은 건너뛰게 되므로 마지막 수단입니다.
내 현재 작업을 먼저 안전하게 보존해줘.
아래 12장 완성 Source에서 다시 시작해줘.
https://github.com/buildyourownai-lab/develop-like-a-pro-with-ai/tree/main/chapters/ch12/source/ai-stock-briefing
내 인증키와 Database, Cache 접속 정보를 입력할 자리를 알려주고
준비가 끝나면 12장을 마친 상태인지 확인해줘.방향부터 확인하고, 더 필요할 때 다음 힌트를 펼치세요.
속도와 실제 재사용은 다른 증거입니다.
브라우저 캐시인지 서버 저장값인지 구분합니다.
두 번째 요청에서 외부 API·Gemini를 다시 불렀는지 기록을 봅니다.
동일 조건 반복·만료·다른 종목을 각각 검사해 재사용과 격리를 확인합니다.
이 설명만으로 원인이 확인됐거나 수정됐다고 말하지 않습니다. 현재 프로젝트의 근거를 먼저 대조합니다.
로컬과 배포 환경의 변수 이름을 비교합니다.
자동 연결이 만든 Name과 코드가 찾는 Name을 나눕니다.
SUPABASE_DATABASE_URL, UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN이 로컬과 Vercel에 같은 이름으로 등록되어 있는지 값 노출 없이 확인합니다.
Vercel에 프로젝트가 사용하는 세 이름으로 연결값을 등록하고 새 배포 후 저장·재조회까지 검증합니다. 무료 플랜을 임의 가정하지 않습니다.
이 설명만으로 원인이 확인됐거나 수정됐다고 말하지 않습니다. 현재 프로젝트의 근거를 먼저 대조합니다.
장 완료 확인해줘.실제 프로젝트에서 튜터와 확인합니다. 사이트를 열어본 기록은 학습 완료가 아닙니다.
저자는 11장을 끝낸 상태에서 12장 요청문만으로 Database와 Cache 적용까지 갔습니다. 프로젝트 전체 Test 113개가 통과했고 그중 13개가 이 장에서 새로 생겼습니다. 실제 서비스 주소에서 같은 종목을 반복 요청해 주식 데이터는 1.339초에서 0.088초로, AI 브리핑은 3.350초에서 0.076초로 줄어드는 것을 측정했습니다. 반복 요청에서 금융위원회 호출과 Gemini 호출이 0회인 것, 유효시간이 지난 값만 원본에서 다시 확인하는 것, 사용량 한도에 도달한 동안 추가 호출이 나가지 않는 것도 확인했습니다. 근거는 verification/chapter-12/에 있습니다.
장별 소스는 해당 장까지의 기준 상태입니다. 정상 실습은 내 프로젝트를 이어가고, 완성 소스는 비교·복구할 때 사용합니다.
자료 판본 1c784213