구현 금지 킥오프와 12문항 인터뷰
자동매매 봇 설계를 시작하며 구현 코드 작성을 금지하고 인터뷰부터 시킨 킥오프 프롬프트 사용기.
일요일 밤, 자동매매 봇 프로젝트의 첫 프롬프트를 썼다. 이번에는 코드를 한 줄도 안 받는 게 목표였다.
하려던 것
증권사 Open API 기반 자동매매 봇이다. 모의투자에서 완성한 뒤 실전으로 전환하고, 맥미니 한 대에서 launchd 상주 데몬으로 무인 운전하는 게 최종 그림. 구조는 하이브리드로 잡았다. 매매 시그널은 룰 엔진만 생성하고, LLM은 그 시그널을 APPROVE/REJECT/REDUCE로 심사만 한다. 돈이 직접 걸리는 시스템이라, “만들어줘” 한마디에 코드부터 쏟아지는 평소의 흐름은 피하고 싶었다.
어떻게 시켰나
킥오프 프롬프트의 첫 줄을 금지 조항으로 시작했다.
지금은 설계 단계다. 구현 코드를 한 줄도 작성하지 마라. 산출물은 docs/ 아래의 설계 문서뿐이다.
요구사항을 몇 개 더 박았다. 첫째, “LLM은 주문을 생성할 수 없다”는 원칙이 프롬프트 수준이 아니라 코드 경로 수준에서 강제되는지 설계로 증명할 것. 둘째, 실패 모드 문서가 이 설계의 핵심이다 — 돈이 걸린 시스템이므로 행복 경로보다 실패 경로 설계에 더 많은 지면을 쓸 것. 셋째, 나는 9년차 백엔드 개발자니 설명은 간결하게, 코드는 나중에 쓰게 되면 프로덕션 수준으로. 진행 방식도 3단계로 못 박았다. 1단계 인터뷰, 2단계 증권사 API 사전 조사, 3단계 설계 문서 7종과 ADR을 하나씩 리뷰.
어디서 막혔나
1단계 인터뷰에서 Claude가 12문항을 한꺼번에 던졌다. 항목마다 A/B/C 선택지에 트레이드오프 설명, 별표 추천까지 붙은 성실한 질문지였다. 문제는 나였다. 백엔드는 9년을 했어도 투자는 전문 분야가 아니라서, 절반쯤은 질문 자체를 이해하지 못했다. 15분을 붙들고 있다가 답장을 보냈다.
- 이건 추천. 4. 이것도 내가 전문가가 아니라 추천, 네가 추천하는 방향이 맞는 거지? … 한번에 너무 많은 질문이었어.
답장의 뒷부분은 “무슨 말인지 모르겠어, 추천”, “다시 설명 좀, 추천”의 반복이었다. 12개 중 8개를 “추천”으로 답했고, 질문 개수에 대한 불평도 그대로 적어 보냈다. 설계 결정을 직접 내리겠다고 인터뷰를 시켜놓고, 정작 결정의 3분의 2를 되돌려준 셈이다.
어떻게 풀었나
결과적으로는 인터뷰 형식이 나를 살렸다. 항목마다 선택지·트레이드오프·추천이 붙어 있으니, 모르는 분야는 “추천” 한 단어로 답해도 의사결정이 굴러간다. 아는 항목만 직접 정했다 — 모의투자 자본 3천만원, 국내 시장만. 나머지는 위임하는 구도가 자연스럽게 만들어졌다. 이해가 안 되는 개념은 다시 설명을 받았다. 히스테리시스 밴드가 뭔지 몰라 되묻자 “문 열림/닫힘에 딸깍 걸리는 자석” 비유로 재설명해줬고, 그제서야 내가 뭘 결정하는 건지 알았다. 인터뷰를 마치고 2단계 증권사 API 사전 조사로 넘어갔다. 이날 밤 산출물에 코드는 한 줄도 없다.
배운 점
- 첫 줄에 “구현 코드를 한 줄도 작성하지 마라”를 박으니 이날 산출물은 설계 문서 방향으로 고정됐다. 금지는 두루뭉술한 부탁보다 명시적 조항이 나았다.
- 선택지·트레이드오프·추천이 붙은 인터뷰 형식 덕에, 비전문 분야는 “추천”으로 위임하고 아는 항목만 직접 결정할 수 있었다.
- 다만 12문항 일괄 투척은 과했다. 다음 인터뷰부터는 질문 개수도 프롬프트에서 조절해야겠다.
- 돈이 걸린 시스템이라면 실패 경로에 지면을 더 쓰라고 처음부터 못 박는 편이 낫다.
- 핵심 원칙은 “지키겠다”는 다짐이 아니라 구조로 강제되는지 설계로 증명하라고 요구할 것.