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%를 만들고 나서 방향을 바꾸는 것보다 훨씬 낫습니다. 저는 거꾸로 했고, 그 덕에 이 시리즈를 쓸 수 있게 됐습니다.
편 4. 내 투두와 에이전트 투두는 분리해야 한다
에이전트와 같이 일하면 투두가 두 층으로 나뉩니다. 내 투두는 무엇을 만들지, 어떤 방향을 택할지 — 내가 결정해야 하는 것. 에이전트 투두는 이번 세션에서 어떻게 구현할지 — 에이전트가 스스로 쪼개는 서브태스크.
이게 한 파일에 섞이면 두 가지 문제가 생깁니다. 첫째, 에이전트가 내 투두를 구현 지시로 읽고 맥락 없이 실행합니다. 내가 “다음에 포트폴리오 화면 개선해야지”라고 메모해둔 것을 에이전트가 지금 당장 코드로 짜버리는 식이죠. 둘째, 세션이 바뀌면 어느 게 내 결정 사안이고 어느 게 에이전트가 처리 중인 건지 구분이 안 됩니다. 결국 에이전트에게 “이거 했어?”를 물어보거나, 이미 결정한 것을 다시 결정하게 됩니다.
분리하면 단순해집니다. 에이전트는 자기 스코프 안에서만 놀고, 내 투두는 내가 직접 관리합니다. 에이전트 분담 운용 을 하면서도 이 원칙이 결국 핵심이었습니다 — 누가 무엇을 소유하는지가 명확해야 충돌이 없습니다.
편 5. 테스트는 한 세션 안에 끝낼 것
테스트 사이클의 핵심은 컨텍스트입니다. “왜 이 테스트가 실패하는지”, “어디까지 수정했는지”가 세션 메모리에 살아 있어야 다음 단계로 넘어갈 수 있습니다.
세션을 끊으면 이 컨텍스트가 날아갑니다. 다음 세션에서 에이전트는 왜 실패했는지 처음부터 다시 파악하고, 이미 수정한 것인지 아닌지 불분명한 채로 작업합니다. 위에서 얘기한 AUTH_EMAIL_ALLOWLIST 함정처럼, 한 번 발견해서 고치면 끝인 문제도 세션 중간에 흐름이 끊기면 다음 세션에서 같은 원인을 다시 발견하는 데 비슷한 시간을 씁니다.
테스트는 “통과 or 실패 결론”을 내리고 세션을 마쳐야 합니다. 절반만 돌린 채 끊으면, 다음 세션은 테스트 상태를 재구성하는 데 처음 셋업 비용을 또 씁니다. 길어질 것 같으면 테스트 범위를 줄이더라도 한 사이클은 완결 짓는 게 낫습니다.