[AI 에이전트 2대 + Claude Code] 주식 대시보드, 코드보다 먼저 만든 건 '질문 목록'이었습니다 — 무료 API 6곳을 직접 호출해 본 이틀

[AI 에이전트 2대 + Claude Code] 주식 대시보드, 코드보다 먼저 만든 건 '질문 목록'이었습니다 — 무료 API 6곳을 직접 호출해 본 이틀

📝 한줄 요약

미국 주식·ETF 포트폴리오 대시보드를 만들기로 하고, AI 에이전트 두 대(빅맥·와퍼)와 이틀 동안 요구사항 확정 → 신호 설계 → 무료 데이터 소스 실측 → 구현 계획까지 끝냈습니다.
앱 코드는 아직 한 줄도 없습니다. 못 만든 게 아니라, 무엇을 만들지와 어떤 데이터가 실제로 오는지를 먼저 고정하려고 일부러 여기서 끊었습니다.

바쁘시면 이것만 읽어도 돼요:

• AI에게 "내가 지시할 테니 만들어"가 아니라 "네가 나한테 하나씩 질문해서 같이 정하자" 라고 시작했더니, 제가 몰랐던 결정거리 서른 개 가까이가 튀어나왔습니다.

• 첫 질문에서 "위험 관리"를 골랐다가 다음 날 "매수·매도 판단 신호가 먼저" 로 1순위를 바꿨습니다. 이미 배정하려던 작업이 있어서, 총괄 에이전트가 실행 상태부터 확인하고 중복 배정을 막았습니다.

• 에이전트를 총괄(빅맥) / 조사 전담(와퍼) 로 나눴습니다. 와퍼가 조사해 오면 빅맥이 그대로 믿지 않고 직접 호출해서 다시 확인했습니다. 이 통합검증에서 실제로 두 개가 탈락했습니다.

• 무료 데이터 소스는 조사만으로 정하지 않고 엔드포인트를 실제로 두드렸습니다. SEC·FRED·Nasdaq 프로필은 응답이 왔고, Nasdaq 과거 가격은 0행, GDELT는 429였습니다.

• Alpha Vantage는 무료 하루 25회·짧은 이력, Finnhub는 일별 가격 이력이 유료라 둘 다 탈락. 최종 운영안은 FMP Basic 주력 + Yahoo는 수동 비상복구·교차검증 + SEC EDGAR + FRED입니다.

• 이번 회차 결과물은 설계 문서 3종과 개발 로그입니다. 앱·DB·수집기·신호 엔진·테스트는 다음 편입니다.

• 배운 점: "데이터가 없으면 0점"이 아니라 "데이터가 없으면 신뢰도를 깎는다" 로 규칙을 바꾼 게 이번 설계에서 제일 큰 수확이었습니다.

🎯 이런 분들께 도움돼요

• GPTers에서 데이터 대시보드를 만들어보려는데 어디서부터 정해야 할지 모르겠는 분

• AI 에이전트를 여러 대 쓰고 싶은데 역할을 어떻게 나눠야 하나 고민 중인 분

• 무료 API로 뭔가 만들어보려다 "무료라고 써 있는데 막상 안 되는" 경험을 한 분

• AI가 만들어준 결과물을 어디까지 믿어야 하는지 기준이 필요한 분

😫 문제와 시작 배경

미국 주식과 ETF를 열 종목 넘게 들고 있습니다. 그런데 판단할 때마다 하는 일이 매번 같았습니다. 증권사 앱에서 잔고를 보고, 차트를 따로 열고, 실적 발표는 검색으로 확인하고, 금리나 달러는 또 다른 데서 봅니다. 보는 곳이 흩어져 있으니 "지금 이 종목을 어떻게 봐야 하는가" 에 대한 답이 매번 그날 기분에 따라 달라졌습니다.

기준이 없다는 게 진짜 문제였습니다. 어제는 차트가 좋아 보여서 괜찮다고 하고, 오늘은 뉴스 하나 보고 불안해합니다. 같은 종목인데 판단이 흔들리는 건 종목 탓이 아니라 제가 매번 다른 정보를 보고 있어서였습니다.

그래서 "내가 보는 항목을 고정해서 한 화면에 놓자"가 목표가 됐습니다. 종목을 추천받으려는 게 아닙니다. 제가 판단할 때 봐야 할 것들을 매번 같은 순서로 보여주는 화면이 필요했습니다.

GPTers 23기에서 아파트 실거래·KB 지수 대시보드를 한 번 만들어본 게 계기였습니다. 그때 배운 게 하나 있었는데, 데이터 소스를 대충 정하고 시작하면 나중에 전부 다시 만든다는 것이었습니다. 이번엔 순서를 바꿔보기로 했습니다.

🛠️ 사용한 도구

• AI 에이전트: Hermes — 빅맥(총괄 PM), 와퍼(조사 전담)

• 개발 로그·사례글 작성: Claude Code (write-post 스킬)

• 작업 기간: 2026-07-30 저녁 ~ 2026-07-31

• 특이사항: 이번 회차에는 코드를 작성하지 않았습니다. 요구사항·설계·데이터 검증·구현 계획까지만 진행했습니다.

🔧 작업 과정

1. 시작하자마자 "네가 나한테 질문해" 라고 못 박았습니다

보통은 AI한테 "주식 대시보드 만들어줘"라고 시작하죠. 그러면 AI가 알아서 그럴듯한 걸 만들어 오는데, 막상 보면 제가 원한 게 아닙니다. 제가 뭘 원하는지 스스로도 정리가 안 된 상태로 던졌으니 당연합니다.

그래서 첫 지시를 이렇게 줬습니다.

난 지금부터 내 주식 포트폴리오 대시보드를 만들 예정이야.

- 내가 바로 지시하는것보다 너가 하나하나씩 질문해가면서 같이 만든다.

-너가 다른 에이전트 '와퍼'의 역할과 업무를 정해준다.

-그 업무와 역할에 맞춰 '와퍼'에게 일을 맡긴다.

-일정량의 일이 끝나면 총괄인 '빅맥'이 점검 그리고 나한테 보고한다.

빅맥이 제일 먼저 한 건 코딩이 아니라 작업 흐름을 5단계로 고정하는 일이었습니다. 기존 맥락 확인 → 요구사항 인터뷰 → 와퍼 역할 정의와 배정 → 산출물 통합 검증 → 저에게 통합 보고. 이 순서를 먼저 박아두니까 이후에 제가 딴 얘기를 꺼내도 원래 자리로 돌아왔습니다.

그리고 질문이 시작됐습니다. 한 번에 하나씩, 매번 선택지 네 개를 붙여서요. 이게 생각보다 훨씬 편했습니다. 백지에서 "어떤 기능이 필요하세요?"라고 물으면 대답을 못 하는데, "1번 손익 확인 / 2번 자산배분과 위험관리 / 3번 매수·매도 신호 / 4번 성과 복기" 중에 고르라고 하면 고를 수 있습니다.

첫날 다섯 문항으로 자산 범위(미국 주식·ETF만), 종목 수(11~30개), 위험 관리에서 먼저 보고 싶은 것(집중·섹터 쏠림·변동성을 종합 점수로)까지 정해졌습니다.

2. 다음 날 1순위를 바꿨습니다 — 위험 관리에서 매매 신호로

자고 일어나니 생각이 달라졌습니다. 위험 관리도 필요하지만, 제가 매일 답답해하는 건 "지금 사야 하나 팔아야 하나" 였거든요.

[Replying to: "이 대시보드를 열었을 때 가장 먼저 해결하고 싶은 핵심 목적은 무엇인가요?
1. 현재 보유 종목·손익을 한눈에 확인 / 2. 자산배분과 종목별 비중·위험 관리 /
3. 매수·매도 판단을 위한 지표와 신호 확인 / 4. 성과 분석과 투자 기록·복기"]

나 3번을 먼저 하고 싶어,

여기서 빅맥이 한 행동이 인상적이었습니다. 바로 "네 알겠습니다"하고 방향을 튼 게 아니라, 어제 와퍼에게 넘기려던 위험지표 작업이 이미 돌고 있는지부터 확인했습니다. 이미 실행 중이면 결과를 버리게 되고, 안 돌았으면 배정 자체를 바꿔야 하니까요. 확인하고 나서 우선순위를 이렇게 다시 썼습니다.

• 1차 목적: 매수·매도 판단 지표와 신호

• 2차 목적: 자산배분과 비중·위험 관리

사람 팀에서도 이런 일 흔하죠. 팀장이 방향을 바꿀 때 이미 나간 업무를 회수하지 않으면 누군가 헛일을 합니다. 에이전트를 여러 대 쓸 때 "방향 바꾸기 전에 진행 중인 작업 확인" 은 사람 팀보다 더 중요합니다. AI는 헛일을 하고도 불평을 안 하거든요.

3. 질문 열여덟 개가 더 왔습니다

방향이 잡히니 질문이 쏟아졌습니다. 한 번에 하나씩, 계속요.

가장 기억에 남는 건 갱신 주기 질문이었습니다. 처음엔 "대시보드 열 때마다 최신으로"를 골랐습니다. 당연히 그게 좋아 보였으니까요. 그런데 빅맥이 곧바로 다시 물었습니다. "그럼 가격 데이터의 최소 자동 갱신 간격은 어떻게 할까요?"

이 질문을 받고서야 계산이 됐습니다. 무료 API는 하루 호출 횟수가 정해져 있습니다. 종목 60개를 열 때마다 갱신하면 하루치 할당량이 오전에 끝납니다. 게다가 저는 데이트레이딩을 하는 게 아니라 며칠~몇 달 단위로 봅니다. 결국 "미국장 마감 후 하루 한 번" 으로 확정했습니다.

이게 이번 작업에서 제일 중요한 순간 중 하나였습니다. 제가 처음 고른 답이 틀린 게 아니라, 비용 제약과 실제 사용 패턴을 같이 놓고 보니 답이 달라진 것입니다. AI가 "그건 안 됩니다"라고 반박한 게 아니라 한 겹 더 구체적인 질문을 던져서, 제가 스스로 답을 바꿨습니다.

같은 방식으로 시각 스타일(밝고 깔끔한 금융 앱), 등락 색상(한국식 — 상승·수익 빨강, 하락·손실 파랑), 경고 정렬 순서, 외부 알림 여부까지 정리됐습니다.

4. 빅맥과 와퍼 — 시키는 쪽과 하는 쪽을 나눴습니다

역할은 이렇게 갈랐습니다.

빅맥 (총괄 PM)

• 요구사항·범위·작업 순서 관리

• 와퍼의 역할과 실행 범위를 좁게 지정, 중복 배정 방지

• 와퍼 산출물을 직접 데이터로 다시 확인하는 통합 검증

• 완료·보류·차단 항목을 저에게 보고

와퍼 (조사 전담)

• 빅맥이 지정한 범위만 수행

• 임의로 범위를 넓히거나 다른 작업을 겹쳐 하지 않음

• 결과에 공식 출처, 한계, "미확인" 표시를 반드시 붙임

와퍼에게 던지는 지시에는 제약을 항상 명시했습니다. 가입·로그인·API 키 발급·결제·파일 수정 금지. 확인 못 한 건 '미확인'으로 표기. 조사만 시켰는데 계정을 만들어버리면 곤란하니까요.

첫 위임은 실패했습니다. 와퍼가 자기 밑으로 또 하위 에이전트를 부르다가 중간에 끊겨서 결과가 아예 없었습니다. 빅맥이 이걸 보고 지시를 다시 썼습니다. "재위임하지 말고 네가 직접 웹 조사해서 한 번에 최종 보고서를 완성하라." 범위를 좁혀서 다시 보내니 그제야 결과가 왔습니다.

에이전트를 나눌 때 배운 점이 이겁니다. 하위 에이전트에게는 "알아서 잘"이 아니라 "이것만, 이 방법으로, 이 형식으로"를 줘야 합니다. 자율성을 주면 알아서 잘할 것 같지만, 실제로는 재위임 사슬이 길어지다가 조용히 끊깁니다.

5. 0~100점 구조 — 점수와 신뢰도를 분리했습니다

와퍼가 만들어 온 다중 기간 투자신호 설계안의 뼈대는 이랬습니다.

• 50점이 중립 기준. 여기서 긍정 요소는 더하고 부정 요소는 뺍니다.

• 단기·중기·장기를 각각 따로 계산합니다. 한 종목이 단기 30점, 장기 70점일 수 있고, 그 불일치 자체가 정보입니다.

• 주식과 ETF는 같은 뼈대를 쓰되, ETF는 기업 재무 대신 구성 종목·비용·추적 품질을 봅니다.

• 가중치는 확정값이 아니라 시작점입니다. 검증 후 조정합니다.

여기서 빅맥이 통합 검증을 돌렸습니다. 읽고 "좋네요"가 아니라 가중치 합계를 실제로 더해봤습니다. 결과는 단기 100 / 중기 100 / 장기 100 / 단기 기술 세부 45 / 신뢰도 100. 합이 맞는지 계산으로 확인한 겁니다.

그리고 세 가지를 고쳤습니다.

① 같은 걸 재는 지표는 한 번만 반영
RSI, MACD, 이동평균은 결국 비슷한 현상을 다르게 재는 도구입니다. 셋을 각각 점수에 넣으면 같은 신호가 세 번 들어가서 과대평가됩니다. 묶음 점수로 한 번만 반영하도록 바꿨습니다.

② 데이터가 없으면 0점이 아니라 신뢰도를 깎는다
이게 제일 크게 와닿았습니다. 어떤 종목의 재무 데이터를 못 가져왔다고 그 항목을 0점 처리하면, 그 종목은 실제로 나쁜 종목처럼 보입니다. 나쁜 게 아니라 모르는 것인데요. 그래서 점수(방향)와 신뢰도(확실성)를 완전히 분리했습니다. 화면에는 "단기 62점 / 신뢰도 낮음(재무 데이터 미수집)" 이렇게 같이 뜹니다.

③ 공시·재무는 실제 공개 시점 이후에만
분기 실적은 분기가 끝난 날이 아니라 공시된 날(filed) 이후부터 신호에 넣기로 했습니다. 이걸 안 지키면 "그때는 알 수 없었던 정보"로 과거를 판단하게 되고, 나중에 백테스트를 돌리면 실제보다 좋은 성적이 나옵니다. 2차 범위인 백테스트를 위해 지금부터 규칙으로 박아뒀습니다.

6. 무료 데이터 소스 — 조사만으로 안 정하고 직접 두드려봤습니다

와퍼에게 조사 범위를 네 갈래로 나눠 배정했습니다. ① 일별 가격·거래량과 티커·섹터 ② SEC 공시·재무 ③ 금리·달러·시장환경 ④ 무료 뉴스.

와퍼가 후보를 정리해 왔습니다. 그런데 빅맥이 여기서 멈추지 않고 엔드포인트를 실제로 호출했습니다. 결과가 이겁니다.

조사한 것과 실제로 되는 것은 다릅니다. Nasdaq은 조사 단계에서 "키 없이 응답한다"고 올라온 후보였는데, 회사 프로필은 잘 되고 과거 가격은 파라미터를 바꿔가며 재시도해도 행이 하나도 안 왔습니다. 그래서 Nasdaq은 가격 소스에서 빼고 섹터·산업 정보 보조로만 쓰기로 했습니다.

GDELT는 조사 중에 이미 429가 떴습니다. 본격적으로 쓰기 전 단계에서 요청 제한에 걸렸다는 건, 매일 60종목 뉴스를 돌리면 훨씬 심할 거란 뜻입니다. 뉴스·심리는 1차 핵심 점수에서 제외하고, 화면 자리와 한계 설명만 남기기로 했습니다.

7. 가격 API 3종 비교 — 두 개가 탈락했습니다

가격 데이터가 이 프로젝트의 핵심이라 후보 세 개를 나눠서 동시에 조사시켰습니다. 기준은 명확했습니다. 약 60개 티커를 하루 한 번 갱신 / 최소 5년 일별 가격 / 프로필·섹터 / 비용 0원.

Alpha Vantage는 하루 25회가 결정타였습니다. 종목 60개를 하루 한 번 갱신하려면 최소 60회가 필요한데 25회면 시작도 못 합니다. 게다가 무료로 받을 수 있는 이력이 최근 100개뿐이라 중기·장기 신호를 계산할 수가 없습니다.

Finnhub는 호출 한도만 보면 셋 중 제일 넉넉했습니다. 분당 60회면 충분하죠. 그런데 정작 필요한 일별 가격 이력이 유료였습니다. 회사 프로필만 무료로 주는 건 이 프로젝트에서 의미가 없습니다.

"무료 플랜 있음"과 "내가 필요한 기능이 무료 플랜에 있음"은 전혀 다른 얘기입니다. 한도 숫자만 보고 골랐으면 Finnhub를 택했다가 구현 중반에 막혔을 겁니다.

8. FMP vs Yahoo — Yahoo를 자동으로 쓰지 않기로 한 이유

FMP가 남고, 비교 대상으로 Yahoo가 있었습니다. Yahoo 공개 차트는 실측에서 인증 없이 HTTP 200으로 AAPL 5년치 일봉 1,254개와 배당 이벤트 20건을 반환했습니다. 숫자만 보면 훌륭합니다. 키도 필요 없고 이력도 길고 배당까지 옵니다. 다만 이건 공식 문서화된 계약형 API가 아닙니다. 서비스 약관상 보장되는 창구가 아니고, 사용 조건과 안정성에 대한 SLA가 없으며, 어느 날 응답 형식이 바뀌거나 막혀도 공지받을 곳이 없습니다. 즉 비공식·무SLA·수동 보조 소스입니다. 개인이 직접 확인용으로 한 번 눌러보는 것과, 매일 자동으로 60종목을 긁는 것은 무게가 다릅니다.

빅맥이 두 소스를 항목별로 비교해서(공식 API 여부, 비용, 가입·키, 호출 제한, 이력 길이, 프로필·섹터, 안정성, 이용 조건, 장애 대응, 사례 게시글에서 설명 가능한지) 추천안을 냈고, 제가 이걸로 확정했습니다.

최종 데이터 소스 운영안

여기서 "Yahoo 자동 fallback"을 일부러 만들지 않았습니다. 보통은 "FMP 실패하면 Yahoo로 자동 전환" 이렇게 짜고 싶어집니다. 편하니까요. 그런데 그러면 내가 지금 보는 숫자가 어느 소스에서 왔는지 모르게 됩니다. 조용히 대체된 데이터로 판단하고 있으면, 나중에 숫자가 이상할 때 원인을 못 찾습니다.

그래서 Yahoo는 제가 "지금 FMP가 안 되니 이걸로 한번 확인해보자"고 직접 누를 때만 부르고, 저장할 때도 출처를 따로 표시해서 FMP 원본과 섞이지 않게 했습니다. 교차검증용으로도 씁니다. 두 소스의 종가가 다르면 경고를 띄웁니다.

📦 지금 완성된 것과 아직 없는 것

여기가 이 글에서 제일 정직해야 할 부분입니다.

만든 것 (설계 자산)

설계 문서 안에서 확정된 것들:

• 화면 5종 — 보유 요약(첫 화면), 관심 종목, 종목 상세, 거래원장, 데이터 상태

• 데이터 모델 6종 — 거래내역, 관심목록, 일별 가격, 재무, 시장환경, 일별 신호

• 안전 규칙 — 가짜 데이터 금지, API 실패를 0이나 빈 값으로 위장 금지, 원본 데이터와 계산 결과 분리, DB 삭제·재생성은 별도 승인, API 키 노출 금지, 투자 추천·수익 보장·자동 주문 만들지 않기

아직 없는 것

• 앱 코드 (한 줄도 없습니다)

• 프로젝트 전용 DuckDB와 스키마

• 거래원장 계산 로직 (평균단가, 실현·미실현손익)

• FMP·Yahoo·SEC·FRED 수집 모듈

• 단기·중기·장기 신호 계산 엔진

• 경고 우선순위 로직

• 테스트 코드와 실행 결과

• 실제 화면, 스크린샷, 배포

• FMP 무료 계정 가입과 API 키 발급

그래서 이 글에는 대시보드 화면 이미지도, 수익률도, 성과 숫자도 없습니다. 아직 존재하지 않으니까요.

멈춘 자리는 오류가 나서가 아니라 되돌리기 어려운 변경(코드 생성, DB 생성) 직전의 승인 대기 지점이었습니다. 빅맥이 이 지점을 체크포인트로 잡고 저에게 보고한 뒤 기다렸습니다. 이 구조가 마음에 들었습니다. 코드가 쌓이고 나서 "아 이게 아니었는데"를 하는 것보다, 아직 아무것도 안 만들었을 때 요구사항을 뒤집는 게 훨씬 쌉니다. 실제로 저는 이틀 사이에 1순위 목적을 한 번, 갱신 주기를 한 번 바꿨습니다. 코드가 있었으면 둘 다 재작업이었을 겁니다.

🚀 앞으로의 구현 순서

02-구현-계획.md에 Task 12개로 정리해뒀습니다. 각 단계는 테스트를 먼저 쓰고 통과시키는 순서(TDD)입니다.

이후 2차 범위로 점수 구간별 백테스트, 거래일 실제 환율 기준 손익, 가중치 사용자 조절, 알림을 두었습니다.

💬 시행착오에서 배운 점

잘 먹혔던 것

1. "질문해줘"로 시작하기
"만들어줘"가 아니라 "나한테 하나씩 물어봐"로 시작하면, 내가 결정해야 할 게 뭔지 AI가 대신 목록으로 만들어줍니다. 선택지를 붙여서 물어보게 하면 백지 앞에서 얼어붙지 않습니다.

2. 조사 결과를 그대로 믿지 않고 직접 확인시키기
와퍼가 "이 API 됩니다"라고 보고한 것 중 하나(Nasdaq 과거 가격)는 실제로 호출하니 0행이었습니다. 조사 담당과 검증 담당을 나눈 게 여기서 값을 했습니다. AI가 웹에서 읽어온 정보와 실제 응답은 다를 수 있습니다.

3. 하위 에이전트에게는 범위를 좁게
"알아서 조사해"는 재위임 사슬로 이어지다 끊겼습니다. "재위임하지 말고 직접, 한 번에, 최종 보고서 형식으로"라고 좁히니 결과가 왔습니다.

4. 데이터 없음을 점수가 아니라 신뢰도로 처리
이건 주식 대시보드만의 얘기가 아닙니다. 어떤 지표든 "나쁨"과 "모름"은 다르게 표시해야 합니다. 둘을 같은 칸에 넣으면 결과를 잘못 읽습니다.

5. 되돌리기 어려운 단계 앞에서 멈추게 하기
코드·DB 생성 직전에 승인 대기를 걸어두니, 요구사항을 두 번 뒤집는 동안 재작업이 0이었습니다.

이렇게 하면 안 되겠더라

1. "무료 플랜 있음"만 보고 고르기
Finnhub는 호출 한도가 셋 중 제일 넉넉했지만 정작 필요한 일별 가격 이력이 유료였습니다. 한도가 아니라 "내가 쓸 그 기능"이 무료인지를 봐야 합니다.

2. 실패 시 자동 대체 소스로 넘기기
편하지만, 지금 보는 숫자의 출처를 모르게 됩니다. 자동 전환 대신 수동 전환 + 출처 분리 저장으로 갔습니다.

3. 조사 문서만 보고 채택 결정하기
문서에 "무료 제공"이라 써 있어도 실제 호출에서 0행이 오는 경우가 있습니다. 채택 전에 엔드포인트를 최소 한 번은 직접 두드려봐야 합니다.

4. 비슷한 지표를 각각 점수에 넣기
RSI·MACD·이동평균을 다 넣으면 같은 신호를 세 번 세는 셈입니다. 묶어서 한 번만 반영해야 합니다.

이 교훈들은 주식이 아니어도 그대로 쓸 수 있습니다. 외부 데이터를 끌어와 지표를 만드는 일이라면 — 광고 성과 대시보드든, 재고 현황판이든 — 소스 실측·결측 처리·중복 지표 문제는 똑같이 나옵니다.

📋 재사용할 수 있는 프롬프트와 체크리스트

프롬프트 1: 요구사항을 AI에게 뽑아내게 하기

나는 지금부터 [만들 것]을 만들 예정이야.

• 내가 바로 지시하는 것보다, 네가 나한테 하나씩 질문해가면서 같이 만든다.

• 질문은 반드시 한 번에 하나씩 하고, 매번 선택지를 3~4개 붙여줘.

• 내가 답하면 그걸 확정 요구사항 표에 기록하고 다음 질문으로 넘어가.

• 요구사항이 다 모이면 표로 정리해서 나한테 한 번에 보여줘.

• 내 답이 나중에 비용이나 기술 제약과 충돌하면, 반박하지 말고 한 겹 더 구체적인 질문을 다시 던져서 내가 스스로 판단하게 해줘.

[만들 것]만 바꾸면 대시보드가 아니어도 됩니다.

프롬프트 2: 조사 담당 에이전트에게 주는 지시

아래 범위만 조사해줘.

• 조사 대상: [소스 후보 목록]

• 확인할 항목: 무료 여부, 호출 한도, 제공 기간, 필요한 인증, 공식 문서 링크, 이용 조건

• 금지: 가입, 로그인, API 키 발급, 결제, 파일 수정, 다른 에이전트에게 재위임

• 네가 직접 조사해서 한 번에 최종 보고서로 완성해. 중간 보고는 필요 없어.

• 확인하지 못한 항목은 추측하지 말고 "미확인" 이라고 그대로 적어.

• 각 항목에 공식 출처와 한계를 반드시 붙여.

프롬프트 3: 조사 결과 통합 검증

방금 받은 조사 보고서를 그대로 믿지 말고 검증해줘.

1. 보고서에 "된다"고 적힌 엔드포인트를 실제로 호출해서 HTTP 상태와 실제 반환된 행 수를 확인해줘.

2. 응답이 200이어도 본문이 비어 있거나 에러 상태를 담고 있는 경우를 따로 구분해줘.

3. 안 되는 건 왜 안 되는지(파라미터 문제인지, 유료인지, 요청 제한인지) 원인까지 적어줘.

4. 결과를 통과 / 확인 필요 / 부적합 세 가지로 나눠 표로 보여줘.

5. 실패한 걸 임의로 대체하거나 가짜 응답을 만들지 마.

무료 데이터 소스 채택 체크리스트

새 API를 후보에 올릴 때 이 순서로 확인하면 헛수고를 줄일 수 있습니다.

• ☐ 내가 쓸 그 기능이 무료 플랜에 포함돼 있나? (플랜 존재 여부 말고)

• ☐ 하루/분당 호출 한도가 내 실제 사용량을 감당하나? (대상 개수 × 갱신 횟수로 계산)

• ☐ 무료로 받을 수 있는 과거 데이터 기간이 내 계산에 충분한가?

• ☐ 인증이 필요한가? 가입·키 발급에 결제 수단을 요구하나?

• ☐ 공식 문서화된 API인가, 아니면 열려 있길래 쓰는 창구인가?

• ☐ 엔드포인트를 실제로 한 번 호출해봤나? 상태 코드뿐 아니라 행 수까지 봤나?

• ☐ 이용 조건상 내 용도(개인 로컬 사용)가 허용되나?

• ☐ 이 소스가 막히면 무엇으로 대체하나? 그 대체를 자동으로 할 건가, 수동으로 할 건가?

AI 에이전트 여러 대 쓸 때 체크리스트

• ☐ 총괄과 실무의 역할이 문장으로 적혀 있나?

• ☐ 실무 에이전트의 범위가 "이것만" 수준으로 좁은가?

• ☐ 재위임을 허용했나, 금지했나? (길어지면 조용히 끊깁니다)

• ☐ 방향을 바꾸기 전에 진행 중인 작업 상태를 먼저 확인하나?

• ☐ 총괄이 실무 결과를 다시 검증하나, 그냥 취합만 하나?

• ☐ 되돌리기 어려운 변경(파일 생성, DB 변경, 계정 가입) 직전에 승인 대기가 걸려 있나?

• ☐ 확인 못 한 것을 "미확인" 으로 남기게 했나?

✅ 마무리

대시보드 하나 만들자고 시작했는데, 이틀 동안 나온 결과물이 코드가 아니라 문서 네 개입니다. 처음엔 좀 답답했습니다. "언제 만드나" 싶었죠.

그런데 돌아보면 이틀 사이에 저는 1순위 목적을 한 번 바꿨고, 갱신 주기를 한 번 바꿨고, 가격 API 후보 두 개를 버렸고, 뉴스 소스 하나를 포기했습니다. 코드가 있었으면 전부 재작업이었을 변경들입니다. 아무것도 안 만들었기 때문에 마음 편히 바꿀 수 있었습니다.

그리고 이 과정에서 제일 크게 배운 건 기술이 아니라 태도 쪽이었습니다. AI가 조사해 온 걸 그대로 믿지 않고 한 번 더 두드려보는 것, "무료"라는 단어와 "내가 쓸 수 있는 무료"를 구분하는 것, "나쁨"과 "모름"을 다른 칸에 넣는 것.

다음 편에서는 실제로 만듭니다. Task 1부터 12까지, 테스트를 먼저 쓰고 통과시키는 순서로 갑니다. 빈 화면에서 앱이 뜨는 것부터 시작해서, 거래 한 건 입력 → 평균단가 계산 → FMP로 종목 하나 수집 → 신호 점수 표시까지가 목표입니다. 그때는 실제 화면과 테스트 결과를 가지고 오겠습니다.

설계가 이만큼 촘촘하니 구현이 순탄할 거라고는 생각하지 않습니다. 계획대로 안 되는 부분이 반드시 나올 텐데, 그건 그것대로 다음 글에 적겠습니다.

이 글은 개인이 자신의 판단을 돕기 위한 대시보드를 만드는 과정을 기록한 것입니다. 특정 종목이나 매매 시점에 대한 추천이 아니며, 어떤 수익도 보장하지 않습니다. 대시보드가 산출할 점수는 검증 전 초기 설계값이고, 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.