# [Claude Code] 테스트 1,700개 통과하고도 진짜 계좌 앞에서 다섯 번 막혔습니다

📝 한줄 요약

증권사 계좌를 직접 연결해 "얼마나 갖고 있고 얼마나 벌었나"만 보는 대시보드를 만들었습니다. 가짜 데이터로 만든 테스트 1,700개가 전부 통과한 상태에서 실제 계좌를 처음 연결했더니 다섯 번 막혔고, 원인이 매번 달랐습니다.

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

Investing Pro, TradingView, Seeking Alpha를 오가며 보던 걸 한 화면에 모으고 싶어서 시작했습니다.
코드를 쓰기 전에 "무엇을 안 만들 것인가"부터 문서로 정했습니다. 주문 기능은 처음부터 제외했습니다.
AI가 스스로 검수자 3명을 불러 4라운드를 돌게 했습니다. 대화를 공유하지 않는 검수자여야 잡아냅니다.
그렇게 해도 실제 계좌 앞에서 다섯 번 막혔습니다. 그중 둘은 코드 문제가 아니라 "무엇을 만들 것인가"를 다시 정해야 하는 문제였습니다.
마지막엔 직접 만든 기능의 절반을 지웠습니다. 안 쓰는 기능이었습니다.
배운 것: AI에게 실제 데이터를 보여주기 전까지는 끝난 게 아니었습니다.

🎯 이런 분들께 도움돼요

AI로 뭔가 만들어보려는데 "어디까지 믿어도 되나" 궁금한 비개발자
테스트는 다 통과했는데 실제로 쓰면 자꾸 깨지는 경험을 해본 분
여러 앱을 오가며 같은 정보를 확인하는 게 번거로운 분

😫 문제 상황 (Before)

주식을 보려면 앱을 여러 개 켜야 했습니다.

증권사 앱 — 내가 뭘 얼마나 갖고 있는지
Investing Pro — 지수, 원자재, 금리
TradingView — 차트
Seeking Alpha — 종목 분석

각각은 잘 만들어진 도구인데, 제가 매일 확인하는 건 그중 아주 일부였습니다. 그 일부를 보려고 매번 네 개를 오갔습니다.

게다가 증권사 앱은 주문 중심으로 만들어져 있습니다. 사고파는 버튼이 크고 정보가 빽빽합니다. 저는 "지금 얼마고 얼마 벌었나"만 보고 싶었는데, 그 답을 찾으려면 화면을 여러 번 넘겨야 했습니다.

그래서 내가 실제로 보는 것만 모은 화면을 만들기로 했습니다.

🛠️ 사용한 도구

도구: Claude Code
모델: Claude Opus 5
화면: Streamlit (파이썬으로 웹 화면을 만드는 도구)
저장: DuckDB (파일 하나로 끝나는 데이터베이스)
연결: 증권사의 조회 전용 API

🔧 작업 과정

코드보다 문서를 먼저 — "무엇을 안 만들 것인가"

바로 만들자고 하지 않았습니다. 먼저 문서를 쓰게 했습니다.

Toss 포트폴리오 1단계를 문서로 먼저 정의해줘

무엇을 만들지보다 무엇을 안 만들지를 적는 데 시간을 더 썼습니다. 제외 목록에 이렇게 적었습니다.

주문 생성·수정·취소
자동매매
공시 분석, 뉴스·심리 분석

특히 주문 기능은 처음부터 뺐습니다. 돈이 실제로 움직이는 기능은 만들지 않으면 사고도 없습니다. 나중에 검사할 때 "주문 관련 코드가 0건인가"를 매번 확인하는 항목으로 넣었습니다.

이 문서가 나중에 "약속과 실제 동작이 다르다"를 판정하는 기준이 됩니다. 이게 없으면 AI가 뭘 잘못했는지 따질 근거가 없습니다.

사람이 결함 목록을 주고 고치기를 여섯 번

구현이 끝난 뒤, 다른 AI에게 코드를 검사시켜 결함 목록을 받았습니다. 그 목록을 다시 구현 AI에게 주고 고치게 했습니다.

이걸 여섯 번 반복했습니다. 한 번에 안 끝난 이유는, 고칠 때마다 더 깊은 문제가 드러났기 때문입니다.

여섯 번 내내 붙들고 있던 질문은 하나였습니다.

데이터베이스 파일을 만들다가 실패하면, 무엇을 지우고 무엇을 남겨야 하나?

지우면 깔끔합니다. 그런데 이미 제자리에 놓인 파일을 지우면 그 안의 기록이 사라집니다. 여섯 번째에 결론이 났습니다.

파일을 제자리에 놓은 뒤에는 무슨 일이 있어도 지우지 않는다. 지우는 것보다 "상태를 모르겠다"고 말하는 편이 안전하다.

"모르겠다"고 말하는 게 왜 중요하냐면, 사람은 "실패했습니다"를 보면 지우고 다시 하거든요. 실제로는 멀쩡한데 말입니다.

AI가 스스로 검수자를 부르게 하기

여섯 번을 사람이 중개하다 보니 지쳤습니다. 그래서 방식을 바꿨습니다.

결함을 수정한 뒤 보고하고 멈추지 말고, 독립 읽기 전용 리뷰 → 재현 → 수정 →
전체 검증을 새 리뷰에서 심각한 문제가 0건이 될 때까지 자체 반복하라

핵심 장치는 이겁니다.

검수자는 구현한 AI와 대화를 공유하지 않는다.

같은 AI에게 "네가 고친 거 다시 봐"라고 하면 자기 논리에 갇혀 통과시킵니다. 그래서 매 라운드마다 아무것도 모르는 새 검수자 3명을 만들고 서로 다른 각도를 맡겼습니다. 한 명은 이상 상황(강제 종료, 파일 충돌), 한 명은 문서와 실제 동작의 일치, 한 명은 진짜 브라우저 확인.

4라운드를 돌렸고, 결과는 이렇습니다.

라운드

가장 심각

심각

보통

사소

"가장 심각"은 1라운드에 사라졌는데, "보통"이 잘 안 줄었습니다.

원인을 뜯어보니 2·3라운드 지적의 상당수가 직전 라운드에서 새로 생긴 것이었습니다. 패턴이 똑같았습니다.

규칙을 세운다 → 적용할 자리가 다섯 군데인데 → 세 군데만 고친다 → 남은 두 군데에서 같은 문제가 다시 난다

AI는 "규칙을 세우는 것"은 잘하는데 "빠짐없이 적용하는 것"에서 계속 실패했습니다.

3라운드에서 접근을 바꿨습니다. 빠진 자리를 더 채우는 대신 세는 방식 자체를 버렸습니다. 이름을 목록으로 적어두던 판정을, 목록이 필요 없는 규칙으로 바꿨습니다. 그러자 "또 한 군데 빠뜨렸다" 계열이 줄었습니다.

그리고 실제 계좌를 연결했습니다

여기까지 테스트 1,700개가 통과한 상태였습니다. 실제 키를 넣고 조회 버튼을 눌렀습니다.

다섯 번 막혔고, 원인이 매번 달랐습니다.

1번 — 필드가 없다더니, 있었습니다

보유자산 응답이 계약과 다릅니다 — 총 매입금액: 필수 항목이 없다

없는 줄 알았는데 있었습니다. 다만 그 안에 제가 가정한 이름이 아닌 다른 이름이 들어 있었습니다. 바깥이 아니라 안쪽 이야기였는데, 문구만 보고 넘겨짚었습니다.

여기서 설계 실수도 하나 드러났습니다. 그 값은 화면에 표시되지도 저장되지도 않는 검산용 숫자였습니다. 쓰지도 않을 숫자를 못 읽는다고 보유 종목 전체를 거부하고 있었습니다.

2번 — 아예 없는 필드

휴장 여부: boolean이 아니다

이번엔 진짜로 없었습니다. 휴장인지 아닌지 알려주는 항목이 응답에 아예 없었습니다.

여기서 추측하면 위험했습니다. 휴장과 개장을 뒤집으면 화면이 "오늘 장 열림"이라고 조용히 거짓말합니다. 그래서 확실히 쉬는 날(신정)과 평일을 나란히 조회해서 비교했습니다.

평일 → 네 개 거래 시간이 전부 들어 있음
신정 → 네 개 전부 비어 있음

즉 정규장 시간이 없으면 휴장입니다. 추측이 아니라 확인이었습니다.

3번 — 만드는 방식 자체가 틀렸습니다

호출 제한 상태입니다

월간 달력을 채우려고 하루에 한 번씩, 한 달이면 31번을 부르고 있었습니다. 증권사가 그 연타를 막았습니다.

그런데 응답을 자세히 보니 하루만 불러도 오늘 상태와 다음 개장 시각이 다 들어 있었습니다. 화면이 실제로 쓰는 건 그것뿐이었습니다. 31번을 1번으로 줄이고 월간 표를 없앴습니다.

이건 코드를 고쳐서 될 문제가 아니라 "무엇을 만들 것인가"를 다시 정해야 하는 문제였습니다.

4번 — 데이터베이스가 거부했습니다

달력을 저장하지 못했습니다

"완료된 한 달만 저장한다"는 규칙을 데이터베이스에 박아뒀는데, 이제 하루만 저장하니 걸렸습니다. 표를 없애면서 그 테이블의 역할이 바뀐 것이었습니다.

5번 — 제 실수

구조를 바꾸는 작업을 하면서 조건 하나를 빠뜨렸습니다. 앱이 열리지 않았습니다. 백업에서 되돌리고 고쳐서 다시 적용했습니다. 이래서 백업을 먼저 뜹니다.

마지막에 기능의 절반을 지웠습니다

실제로 쓰기 시작하니 안 쓰는 절반이 보였습니다.

과감하게 거래원장을 빼버리자.
얼마나 가지고 있고 어느정도 수익을 냈냐만 보는거라

거래 기록을 직접 입력하는 기능, 증권사 수량과 대조하는 기능, 추천 순위를 매기는 기능을 전부 지웠습니다. 코드로 약 3,000줄, 테스트 350여 개 분량입니다.

AI가 먼저 물었습니다. "추천 순위는 대조된 종목만 후보로 쓰는데, 대조 기능이 사라지면 후보가 영원히 0이 됩니다. 순위도 같이 뺄까요?" — 지웠습니다.

만드는 것보다 안 만들 것을 정하는 게 더 어려웠습니다.

✅ 결과 (After)

Before vs After

항목

Before

After

확인 경로

증권사 앱 + Investing Pro + TradingView + Seeking Alpha

화면 하나

화면 구성

주문 중심, 정보 빽빽

총액·손익 먼저, 종목은 한 줄씩

주문 기능

있음 (실수 위험)

없음 — 처음부터 만들지 않음

시장 지표

앱을 따로 열어 확인

같은 화면에 9종 (지수·원자재·금리)

완성 화면

위 화면은 시뮬레이션 데이터입니다. 종목명이 Alpha Sample Corp 같은 예시값이고, 화면 맨 위에 실제 계좌가 아니라는 표시가 붙습니다. 실제 보유 종목과 금액은 공개하지 않습니다.

지금 화면이 답하는 것

총 평가금액과 평가손익 (원화 환산 포함)
종목별 평가금액·손익률·비중 — 한 줄에 하나씩
보유 비중 도넛
많이 벌어준 3종목 / 많이 까먹은 3종목
지수·원자재·금리 9종의 최근 3개월 흐름
지금 미국장이 열렸는지, 다음 개장·마감은 언제인지

확인된 검증 결과

테스트 522개 통과 (기능을 지운 뒤 기준)
주문·매매 관련 코드 0건
비밀번호·키가 코드에 박힌 곳 0건
외부에 요청하는 주소 6개, 전부 조회 전용
실제 계좌 연동 성공

아직 못 하는 것

자산이 늘고 있는지 보여주는 추이 차트 — 지금은 최신 상태 하나만 저장하고 덮어쓰는 구조라 과거가 없습니다. 이력을 쌓기 시작하면 몇 주 뒤부터 가능합니다.
전일 대비 등락률은 시장 지표에만 있고, 내 종목에는 없습니다. 증권사 통로가 어제 값을 주지 않습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

코드보다 문서를 먼저 쓰게 하기. 나중에 "약속과 다르다"를 따질 기준이 됩니다. 이게 없으면 AI가 뭘 잘못했는지 말할 근거가 없습니다.
검수는 반드시 다른 대화에서. 같은 AI에게 재확인시키면 통과시킵니다. 대화를 공유하지 않는 검수자여야 잡아냅니다.
검수자를 여러 명, 서로 다른 각도로. 한 각도로는 못 보는 게 있습니다.
위험한 기능은 처음부터 만들지 않기. 주문 기능이 없으면 주문 사고도 없습니다.
AI가 고친 뒤에 새 문제가 생겼는지 확인하기. 이게 이번 사례의 핵심입니다.
"목록을 빠짐없이 확인해"보다 "목록이 필요 없게 만들어"를 요구하기.

이렇게 하면 안 돼요

테스트 통과를 완료로 착각하기. 1,700개가 통과해도 실제 데이터 앞에서 다섯 번 막혔습니다.
오류 문구만 보고 원인을 넘겨짚기. "필드가 없다"는 문구를 보고 없는 줄 알았는데 있었습니다. 두 번 헛짚었습니다.
모르는 걸 추측으로 채우기. 휴장 여부를 짐작으로 매핑했다면 화면이 조용히 거짓말했을 겁니다.
되돌릴 수 없는 작업을 백업 없이 하기. 구조 변경 중 한 번 실패했고, 백업 덕분에 5분 만에 복구했습니다.

🌍 다른 업무에 적용한다면?

여러 시스템을 오가며 확인하는 일 — 자주 보는 항목만 모은 화면을 만들면 됩니다. 전부 옮길 필요 없습니다.
AI에게 반복 작업을 맡길 때 — 결과를 검사할 기준을 먼저 문서로 만들고, 검사는 다른 대화에서 하세요.
외부 데이터를 쓰는 모든 일 — 문서만 보고 만든 것과 실제 응답은 다릅니다. 실제 데이터로 한 번 돌려보기 전까지는 완성이 아닙니다.

🚀 앞으로의 계획

자산 추이 기록 — 하루 한 번 상태를 쌓아두면 몇 주 뒤부터 "늘고 있나"를 볼 수 있습니다.
시장 지표 확장 — 지금 9종인데, 자주 보는 것 위주로 더 붙일 생각입니다.
며칠 써보면서 실제로 안 보는 항목이 또 나오면 그때도 지울 겁니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 만들기 전에 범위부터 정하기

[만들려는 것]의 1단계를 문서로 먼저 정의해줘.
만들 것보다 안 만들 것을 더 자세히 적어줘.
특히 되돌릴 수 없거나 위험한 기능은 제외 목록에 넣고 그 이유를 써줘.
나중에 "약속과 실제 동작이 다르다"를 판정할 수 있는 합격 기준도 같이 만들어줘.

프롬프트 2: AI가 자기 작업을 검수하게 하기

수정한 뒤 멈추지 말고, 이전 대화를 공유하지 않는 새 검수자 3명을 만들어
서로 다른 각도로 검사시켜줘.
1번: 이상한 상황에서 어떻게 망가지는지
2번: 문서에 적힌 약속과 실제 동작이 같은지
3번: 실제 화면에서 제대로 보이는지
심각한 문제가 없어질 때까지 반복하고, 매 라운드마다 새 검수자를 만들어줘.
이전 라운드 수정 때문에 새로 생긴 문제도 찾아줘.

프롬프트 3: 실제 데이터와 안 맞을 때

오류 문구만 보고 원인을 추측하지 마.
그 필드를 처리하는 코드를 먼저 열어서 확인해줘.
값을 알아야 한다면, 값은 출력하지 않고 구조(항목 이름과 형태)만 찍는
확인용 스크립트를 만들어줘. 실행 전에 나에게 물어봐.

📣 24기 대기자 모집이 시작되었습니다!