AI 에이전트로 주식 포트폴리오 앱을 만들면서 겪은 것들
워크트리 파이프라인·멀티에이전트 실험·KIS API 삽질, 그리고 거의 다 만들고 나서 규제에 막힌 이야기
편 1. 워크트리 기반 AI 개발 파이프라인
주식 포트폴리오 앱 trading_mvp를 혼자 만들면서, 처음에는 그냥 브랜치 하나에서 AI 에이전트에게 일을 시켰습니다. 그런데 기능이 여러 개 병렬로 생기기 시작하면서 문제가 생겼습니다. 작업을 구간으로 나누지 않으면 에이전트 하나가 feature 브랜치에서 작업 중인데, 다른 기능도 같이 만들고 싶었거든요.
그래서 도입한 게 git worktree 기반 파이프라인이었습니다. wt-<기능명> 이름으로 기능별 워크트리를 만들고, 각 워크트리에서 에이전트를 독립으로 돌립니다. 완료되면 finalize-worktree.py 스크립트가 dev에 자동 머지하고 워크트리를 정리합니다.
한 번은 이 규칙을 지키지 않고 수동으로 체크아웃한 폴더에서 docker compose up을 돌렸습니다. 컨테이너가 충돌했고, 디버깅에 한참을 썼습니다. 그 이후로는 워크트리 밖에서 컨테이너를 직접 올리는 걸 완전히 금지했습니다.
멀티에이전트 실험도 해봤습니다. 2026년 5월 25일, 매니저·워커·플래너·테스터·리뷰어·리팩터 역할로 나눠 분업을 시도했습니다. 워커가 기능 구현을 마치면 Tester 에이전트가 자동으로 spawn되어 결과를 검증하는 구조였습니다. 작업 inbox/피드 시스템으로 에이전트 간 태스크를 전달했고요.
해보니 알게 된 것이 있었습니다. 에이전트 간 컨텍스트 전달과 피드 관리가 핵심이다는 것. 각 에이전트가 얼마나 정확하게 일하냐보다, 앞 에이전트가 뭘 했는지 다음 에이전트에게 얼마나 잘 넘기느냐가 전체 품질을 좌우했습니다. 지금은 이 구조를 헤르메스-claude-code-분담-운용 방식으로도 이어가고 있습니다.
편 2. KIS API 실전 노트 — rate limit, 테스트 함정
KIS Open API를 직접 써보기 전까지 예상하지 못했던 것들이 꽤 있었습니다.
**rate limit 에러(EGW00201)**는 2026년 5월 22일, 12종목 일괄 매도를 시도할 때 처음 만났습니다. 초당 요청 한도를 넘기면 나는 에러였습니다. _arequest에 1초 간격 × 최대 3회 자동 재시도 로직을 넣었고, 청크 간 sleep도 PAPER 모드에서는 1.0s, LIVE에서는 50ms로 다르게 설정했습니다. 단순해 보이지만 실제 매도 흐름에서 터지기 전까지는 몰랐던 숫자들입니다.
PAPER vs LIVE 모드 차이도 겪어봐야 알았습니다. PAPER 모드에서 40100000 “모의투자 영업일이 아닙니다”라는 에러가 나왔는데, 처음에는 내 코드 문제인 줄 알고 한참 들여다봤습니다. 알고 보니 PAPER 모드에서만 나오는 모드 전용 에러였습니다. LIVE에서는 APBK0919 “장운영일자가 주문일과 상이합니다”로 다르게 나옵니다. 잔고 조회도 마찬가지였습니다. D+0 잔고(dnca_tot_amt)와 D+2 결제잔고(prvs_rcdl_excc_amt)는 용도가 완전히 다른데, 섞어 쓰면 수치가 이상해집니다.
테스트 환경 함정도 하나 있었습니다. 2026년 6월 1일, AUTH_EMAIL_ALLOWLIST 환경변수가 설정된 상태에서 pytest를 돌렸더니 테스트 JWT에 email 클레임이 없어서 전체가 403으로 떨어졌습니다. 테스트 실행 전에 이 환경변수를 unset하는 게 필수였습니다. 당연히 통과되어야 할 테스트가 전부 실패해서 처음에는 코드 문제인 줄 알았습니다. 빌드플랜-스킬로-개발시간-단축 과정에서도 비슷하게, 환경 설정의 사소한 차이가 의외의 곳에서 터지는 걸 많이 겪었습니다.
편 3. 거의 다 만들었는데 런칭을 못 하는 이유
2026년 5월 31일, 세션 말미에 KIS Open API 약관을 직접 읽었습니다. 그 전까지는 기능을 만드는 데 집중했고, 약관을 제대로 살펴볼 생각은 못 했습니다.
약관에는 명확하게 나와 있었습니다. 개인이 본인 계좌를 호출하는 것은 가능하다. 하지만 “다수 사용자에게 주문·계좌 연동 서비스를 제공”하는 것은 제도권 금융회사, 즉 법인 + 금융자문업 인가가 있어야 한다고요. 핀테크사 제휴는 명시적으로 불가했고, 투자일임업 등록이 있어도 한투가 핀테크사 제휴를 막고 있으니 현실적으로 불가능한 구조였습니다.
FastAPI 백엔드, Expo 모바일, CI/CD, 보안 하드닝, 실주문 처리까지 MVP 기능을 모두 구현해놓은 상태에서 나온 결론이었습니다. 솔직히 말하면, 허탈했습니다.
그런데 곰곰이 생각해보니 낭비는 아니었습니다. 만든 것들이 그대로 남았습니다. 본인 전용 자동매매 봇으로 집 서버에서 지금도 운영하고 있고, 코드베이스는 포트폴리오 자산으로 살아있습니다. 앞으로 고려하는 방향도 세 갈래가 있습니다. 직접 주문 대신 리밸런싱 제안만 하는 도구화, B2B 납품, 그리고 포트폴리오 자산화. trading_mvp에 정리해두고 있습니다.
교훈은 하나입니다. 규제나 외부 API 제약은 기능을 만들기 전에 먼저 확인하세요. 70%를 만들고 나서 방향을 바꾸는 것보다 훨씬 낫습니다. 저는 거꾸로 했고, 그 덕에 이 시리즈를 쓸 수 있게 됐습니다.
<- 이전 편: 다 만들고 나서 약관을 읽었다 · 다음 편 ->: 집 서버 배포 삽질기 방법: 에이전트 분담 운용법 · 방법: 빌드플랜으로 개발 시간 단축하기