Joyuno's Dev Blog

2026-05-25 (월) 개발일지

2026년 05월 25일 joyuno
dev-blog
#dev-blog #til

AI 활용 회고: 프롬프팅 전략이 결과를 갈랐던 하루

오늘은 퀀트 전략 해석, JLPT 데이터 크롤링, 시스템 정리, 코드 디버깅까지 AI를 네 가지 전혀 다른 역할로 활용한 하루였다. 각 작업마다 프롬프트 스타일과 컨텍스트 전달 방식을 의도적으로 달리했는데, 그 차이가 결과 품질에 직접적인 영향을 미쳤다. 특히 “무엇을 요청하느냐”보다 “어떤 구조로 요청하느냐” 가 AI를 도구로 쓸지, 동료로 쓸지를 결정했다.

게임 프로젝트: AI를 데이터 파이프라인 오케스트레이터로

studyandgame-godot 리포를 클론한 후, JLPT N2 단어장을 크롤링하고 .yml 퀴즈팩으로 변환하는 작업을 AI에게 맡겼다. 여기서 핵심은 단계를 나누고 각 단계별로 컨텍스트를 유지한 점이다.

프롬프팅 접근: 한 번에 “크롤링해서 yml까지 만들어줘”라고 하지 않고, 아래처럼 쪼개서 요청했다.

  1. 진행해도 돼
  2. n3.csv까지 두개 다운받아줘
  3. 크롤링해줘
  4. 마지막으로 workbook 호출해서 yml 퀴즈팩까지 생성해줘

이렇게 gen_vocab_quiz.py와 scrape_n2_grammar.py 두 스크립트를 잇달아 작성·수정하게 했다. AI는 /workbook 슬래시 커맨드에 반응해 YAML 검증까지 자동으로 수행했는데, 이는 AI를 하나의 함수 호출처럼 쓰는 패턴이 잘 먹힌 사례였다.

잘 통한 점:

  • 병렬 요청(크롤링 + 다운로드)을 동시에 지시했을 때 AI가 자연스럽게 비동기 처리 로직을 제안함
  • YAML 포맷 검증을 AI에게 맡기니 수동 yamllint 없이도 오류 0으로 통과

안 통한 점:

  • 크롤링 대상 사이트의 HTML 구조가 변경되었을 때, AI가 추천한 BeautifulSoup 선택자가 실제 DOM과 일치하지 않아 직접 scrape_n2_grammar.py의 selector 문자열을 수정해야 했다
  • AI는 User-Agent 헤더나 time.sleep()을 기본적으로 생략하는 경향이 있음 — 직접 추가

노하우: AI에게 “너가 그밖에 회수할 수 있는 건 다 해” 같은 광범위한 명령보다, 체크리스트 형태로 단계를 제공하면 응답의 구체성이 2배 이상 올라갔다.

bit-scalp: 백테스트 결과를 해석하는 비서

알트코인 거래량 quartile, RSI 진입 패턴, regime별 TP/SL 그리드 등 세 가지 백테스트 결과를 AI에게 던지고 “명확한 의견 제시”를 요구했다. 이 작업에서 AI에게 통계적 맥락을 먼저 설명한 것과 그렇지 않은 경우의 차이가 극명했다.

프롬프트 구조 비교:

방식 AI 반응
“이 백테스트 결과 분석해줘” 일반론적 조언 (“변동성이 높을 때는 risk 관리가 중요합니다”)
“롱 시그널에서 이전구간 RSI가 과매수였다가 낮아져서 30-60에 걸릴 경우 vs 이전구간이 30보다 낮았다가 올랐을 때 TP/SL 수익률을 비교해줘” 구체적 숫자 비교 + 조건별 백분율 제시

후자의 경우 AI는 long_pattern_by_regime_2y.py, rsi_pattern_test.py 등의 코드를 직접 읽고 결과를 해석해, “Regime 2에서 전략 A는 평균 보유기간 3.2일로 TP 도달률 78%, 전략 B는 보유기간 1.1일로 TP 도달률 43%” 같은 정량적 인사이트를 내놓았다.

안 통한 점:

  • AI가 특정 전략의 가정(예: regime 분류 기준)을 비판 없이 그대로 수용하여, 실제로는 유의미하지 않은 패턴을 과대해석하는 경향이 있음
  • 예를 들어 “RSI 30-60 구간 진입 조건 자체가 데이터 편향을 만들었다”는 지적은 인간이 직접 해야 했음

잘 통한 점:

  • orchestrator.py와 repository.py의 구조를 설명하지 않았는데도 AI가 grep 결과만으로 데이터 흐름을 추론해냄
  • CUR_PID=$(pgrep -f ...) 같은 프로세스 체크 명령을 AI가 제안해 디버깅 시간 단축

배운 점: AI에게 “명확한 의견”을 요구할 때는 비교 대상을 명시하고 가정을 검증하라고 지시하는 게 필수다. 안 그러면 AI가 눈앞의 숫자에만 집착한다.

ficeptterminal + 시스템 정리: 광범위한 요청일수록 경계 설정이 중요

ficeptterminal에서는 dca_cb_results.md와 quantflow_runner.py의 로그를 grep으로 추출한 후 AI에게 원인 추적을 요청했다. 반면 옵시디언 정리는 “회수할 수 있는 건 다 해”라는 아주 개방적인 프롬프트로 시작했다.

시스템 정리 프롬프트:

Waylight-1.0.1-universal.dmg랑 Containers/com.docker.docker 회수해 대신 bit-scalp 관련 도커는 남겨둬

여기서 흥미로웠던 점은 AI가 “otel 데이터는 일단 삭제할게, codefill은 보류” 같은 판단을 스스로 내렸다는 것이다. 단, Waylight 관련 파일을 찾기 위해 echo와 df 명령을 추천했고, 실제 실행 전에 먼저 목록을 보여줬다.

잘 통한 점:

  • “회수”라는 모호한 단어에 대해 AI가 대안(삭제, 이동, 압축 등)을 물어보지 않고 가장 일반적인 삭제로 해석해 빠르게 진행
  • Docker 관련 폴더는 남기라는 조건을 지켜서, Docker 이미지가 날아갈 위험을 방지

안 통한 점:

  • AI가 추천한 삭제 대상에 ~/Library/Application Support/ 같은 시스템 디렉토리가 포함되었을 때는 직접 확인하고 veto해야 했다
  • grep 결과를 그대로 AI에게 전달했더니, AI가 로그 파일의 timestamp 패턴을 오독해 잘못된 프로세스 종료를 제안함

노하우: 광범위한 요청("다 해")을 할 땐 금지 규칙을 먼저 명시하는 게 안전하다. 예를 들어 “시스템 라이브러리는 건드리지 마” 같은 조건을 한 줄 추가하면 AI의 위험한 추천을 80% 줄일 수 있었다.

오늘의 한줄

AI는 훌륭한 연구원과 집행자이지만, 최종 판단은 내가 직접 내려야 하며 — 그 판단을 위한 근거를 AI에게서 빨리 뽑아내는 기술이 진짜 생산성이다.