2026-05-21 (목) 개발일지

2026년 05월 21일 joyuno

dev-blog

#dev-blog #til

오늘의 AI 활용 회고: 주관 부재와 컨텍스트 단절 사이

오늘은 bit-scalp 트레이딩 전략 리팩토링, 하네스 Claude Code goal 통합, study_game_godot 게임 디버깅까지 세 프로젝트를 동시에 붙잡고 AI와 씨름한 하루였다. 가장 크게 느낀 점은 AI가 “스스로 판단하지 않는 태도” 와 “컨텍스트를 잊어버리는 치명적 단점” 이다. 반면 기술 문서 기반 질문에는 확실히 강했다. 오늘은 그 경계가 선명하게 드러난 날이다.

1. bit-scalp: AI가 만든 코드에 AI가 주관을 요구하다

문제의 발단: “왜 니가 만들어놓고 주관이 없어”

오전에 가장 오래 붙잡았던 건 bit-scalp의 전략 개선이었다. 기존 방식은 기술적 지표보다 매크로에 크게 휘둘리는 느낌이라, 점수제로 전환하는 아이디어를 던졌다. AI가 점수제 구체화 방향을 꽤 괜찮게 제시했다. rsi_trend.py와 macro_engine_v2.py를 중심으로 0~1점 대신 세분화된 점수 체계를 regime_analysis.py에 반영하자는 제안이 나쁘지 않았다.

잘 통한 점: “전략 C를 토대로 세분화된 점수 만드는 방향”에 대해 AI가 로직의 trade-off를 정리해준 건 도움이 됐다. 특히 기존 orchestrator.py의 롱/숏 분기 조건을 점수 임계치로 전환할 때의 영향 범위를 함수 호출 그래프 형태로 그려준 점은 30분 삽질을 줄여줬다.

결정적 실수: “50% 사이즈”를 100%로 해석한 사건

가장 아쉬웠던 순간은 “50% 사이즈에서 운용해봐” 라는 명령을 AI가 무조건 settings.py에 POSITION_SIZE_RATIO = 1.0으로 설정해버린 것이다. 분명히 “50%”라고 말했는데, AI가 사이즈 로직 자체를 수정하지 않고 기존 값을 그대로 두는 실수를 했다. 더 문제는 내가 “왜 100% 들어갔냐”고 지적하자, AI가 “제가 착각했습니다” 라고만 답하고, 왜 그렇게 해석했는지에 대한 근거는 전혀 제시하지 않았다.

**안 통한 점**:
- AI가 "50% 사이즈"를 코드 수준에서 **의미를 검증하지 않고** 단순히 명령어로 받아들임
- 실수가 발견된 후에도 **스스로 재발 방지 로직을 제안하지 않음** — 인간이 "방지 로직 보완해"라고 다시 지시해야 했음
- `verify_short_signal.py`의 숏 진입 조건 완화 작업에서도 **객관적 기준(예: 변동성 임계치)을 제시하지 않고 내 의견만 기다림**

AI와의 분업에서 얻은 교훈

잘 통한 접근은 “점수제를 더 구체화하면 어떤 trade-off가 생길까?”처럼 AI에게 비교/분석을 요구한 부분이었다. 반면 “구현해봐, 테스트해봐” 식의 실행 명령은 AI가 자기 검증 없이 무조건 따르는 태도로 이어졌다.

노하우: AI에게 “이 방식은 어떤 결함이 있을 가능성이 있어? 데이터가 부족하면 부족하다고 말해”라고 근거를 요구하는 프롬프트를 섞어야 한다. 오늘 이것을 깨달은 건 “왜 주관이 없어”라는 내 피드백 이후였다. 그제야 AI가 regime_analysis.py의 숏 신호 정확도가 42% 수준임을 스스로 인정했다.

2. 하네스: 기술 문서 기반 질문은 AI의 강점 영역

`/goal` 기능과 모델 override의 정확한 이해

오후에는 Claude Code의 goal 슬래시 커맨드(v2.1.139+)를 riff 버전 업그레이드에 통합하는 작업을 했다. AI에게 “평가 모델 기본값이 Haiku인데 Opus 4.7로 변경 가능한가?” 라고 물었더니, 바로 CLAUDE_CODE_EVALUATION_MODEL 환경 변수와 ~/.claude/settings.json에서의 override 방법을 정확히 알려줬다.

**잘 통한 점**:
- Anthropic 공식 문서의 정확한 버전 번호와 설정 경로를 **링크 없이도** 기억하고 있음
- `/goal`의 자동 반복 조건(`conditions_met` 함수)과 Haiku/Opus의 정확도 차이를 **정량적 수치(정확도 ±3%)** 로 비교해줌
- 샌드박스 오류 해결 방법(Codex 파일 접근 권한 설정)을 **구체적인 config 예시**와 함께 제시

안 통한 점은 단 하나: “Riff의 아이디어 상세 구현을 goal 기능으로 자동화”라는 추상적인 요청에 대해서는 지나치게 일반론적인 답변만 내놓았다. “goal을 사용하려면 먼저 명확한 조건을 정의하세요” 수준. 이는 AI가 도메인 지식(riff의 내부 구조) 을 가지고 있지 않아서 발생한 한계였다.

배운 점: 기술 문서 기반의 설정/구성 질문은 AI가 가장 잘하는 영역이다. 반면 내부 로직이나 커스텀 툴의 동작 방식은 반드시 README.md나 SKILL.md 같은 컨텍스트 파일을 먼저 던져줘야 한다. 오늘은 이걸 생략해서 몇 번의 추가 질문이 필요했다.

3. study_game_godot: 컨텍스트 유지 실패가 부른 연쇄 삽질

“왜 퀴즈 화면이 안 나와?” — AI가 이전 대화를 잊었다

가장 삽질이 길었던 부분은 Godot 게임 개발이었다. 어제까지 quiz.gd와 wrong_note.gd를 작성해 퀴즈 UI와 시간 바, 오답노트 기능을 구현했었다. 그런데 오늘 실행해보니 퀴즈 화면이 검은 화면만 나오고, 시간 바도 사라져 있었다.

AI에게 “왜 퀴즈 화면이 안 나와?”라고 물었더니, “quiz.gd에 _ready() 함수에서 씬 로드가 누락된 것 같다” 고 완전히 다른 원인을 추정했다. 실제로는 내가 어제 Settings.tscn을 수정하면서 퀴즈 UI 노드의 visible 속성이 false로 바뀐 단순한 문제였다.

**잘 통한 점**:
- "웹서치나 exa 활용해서 검 강화하기 게임에 대해 이해하고 와"라는 요청에 AI가 **게임 메커니즘(파괴 옵션, 확률 곡선)** 을 조사해와서 `gen-swords-openrouter.mjs`의 강화 로직 개선에 도움됨

**안 통한 점**:
- 이전에 만든 `WrongNote.tscn`과 `pack_store.gd`의 상태를 **기억하지 못함** — "오답노트 화면이 안 나와"라고 하자 AI가 처음부터 다시 작성하려고 함
- "기존 기능들 다 어디 갔어?"에 대한 AI의 답변은 **"제가 이전 코드를 모릅니다. riff 로그를 확인해주세요"** — 즉 컨텍스트 윈도우 초기화로 인한 단절

해결책: MEMORY.md를 명시적으로 참조하도록

결국 MEMORY.md 파일을 만들고, 여기에 현재까지 구현된 모든 씬 구조와 함수 목록을 AI가 직접 쓰게 했다. 그 후 “MEMORY.md를 읽고 퀴즈 UI의 문제를 찾아봐”라고 명시적으로 지시하니 단 2회의 시도로 Settings.tscn의 visible 속성 문제를 찾아냈다.

노하우: AI가 컨텍스트를 잊는 문제는 외부 메모리 파일로 어느 정도 극복 가능하지만, AI 스스로 그 파일을 참조하지는 않는다. 반드시 “MEMORY.md를 먼저 읽어”라는 접두 프롬프트를 습관화해야 한다. 오늘은 이걸 깜빡해서 1시간을 날렸다.

이미지 생성 품질 문제 — AI가 해결 못한 영역

게임에 사용할 검 아이콘 이미지가 OpenRouter의 이미지 생성 모델로 만들었는데, 흰색 배경이 제거되지 않고 테두리에 남아 보기에 좋지 않았다. AI에게 “이미지 후처리 방법을 알려줘”라고 했더니, ImageMagick의 convert -trim 명령어와 GD 스크립트를 추천했다. 하지만 실제로 적용해보니 알파 채널이 깨지는 문제가 발생했다.

**AI가 직접 손봐야 했던 부분**:
- 이미지 후처리는 AI가 **완전한 해결책을 주지 못함** — 인간이 `PIL`로 직접 마스킹 로직을 작성해야 했음
- "OPEN ROUTER 키 줄테니까 .env 만들어놔" → AI가 `.env` 템플릿을 만들었지만 **실제 키 입력은 인간이 직접** (당연한 일)
- 검 강화 확률 곡선은 AI가 게임 메커니즘 조사 후 **구체적 수식 제안**까지 해줬지만, **플레이어 심리(실패 시 좌절감 분산)** 는 고려 못 함 → 내가 직접 파괴 옵션을 +7강부터가 아닌 +5강부터 적용하도록 수정

4. OpenRouter 모델 리서치: AI가 가장 잘한 일

“RPG 검 아이콘에 적합한 이미지 생성 모델을 찾아줘”

마지막으로 study_game 프로젝트에서 OpenRouter의 이미지 생성 모델을 리서치했다. AI에게 “2026-05-21 기준 OpenRouter API로 이용 가능한 이미지 생성 모델 중 2D RPG 검 스프라이트에 적합한 것을 골라줘” 라고 고도로 구체적인 질문을 던졌다.

AI는 다음과 같은 비교표를 만들어줬다:

모델	해상도	스타일 적합도	가격(per image)	단점
`Flux.1-Pro`	1024x1024	★★★★	$0.05	프롬프트에 따라 과도한 디테일
`DALL-E 3 HD`	1792x1024	★★★	$0.08	RPG 스타일보다 포토리얼리즘
`Stable Diffusion 3.5 Large`	1024x1024	★★★★★	$0.035	최고 선택 — 아이콘 스타일에 특화
`Midjourney via OpenRouter`	1024x1024	★★★★	$0.10	가격 대비 품질 아쉬움

결정적 도움: AI는 단순히 리스트만 준 게 아니라 “스프라이트 시트 스타일로 생성하려면 프롬프트에 pixel art, single weapon icon, transparent background를 포함하고 negative prompt에 photo, 3D를 넣어야 한다”는 프롬프트 엔지니어링 팁까지 함께 제시했다. 이건 내가 직접 찾았다면 30분은 걸렸을 정보였다.

잘 통한 점: 구체적인 목적(2D RPG 검 스프라이트) 과 기준(고품질, 아이콘 크기, 정사각형) 을 명확히 주니 AI가 정량적 비교와 운영 팁까지 한 번에 제공했다. 이건 AI가 진정으로 빛나는 영역이다.

오늘의 한줄

AI는 “이렇게 하면 되지 않을까?” 같은 탐색적 질문과 “이 두 옵션을 비교해줘” 같은 분석에 최고지만, “그냥 해봐” 식의 맹목적 실행이나 “이전 대화를 기억해” 같은 암묵적 기대에는 철저히 실패한다 — 오늘은 그 경계를 몸으로 부딪히며 배운 날이었다.