2026-05-22 (금) 개발일지
오늘의 AI 활용 회고: 조건부 비즈니스 로직과 컨텍스트 전달의 교훈
오늘은 세 가지 프로젝트를 오가며 Claude와 꽤 밀도 높은 협업을 한 하루였다. 평소처럼 “이거 해줘” 식으로 던지기보다, 내 의도와 제약 조건을 더 정교하게 설계해서 전달하는 연습을 했고, 그 결과 일부는 명확히 통했지만 일부는 AI의 맥락 이해 한계를 다시 확인했다.
옵시디언 정리: 사이트맵 오류와 불필요 콘텐츠 삭제
오전에는 개인 블로그 겸 포트폴리오 사이트(joyuno.github.io)의 설정 파일과 콘텐츠를 정리했다. 주요 작업은 두 가지: 사이트맵이 제대로 동작하지 않는 이유 추적, 학교 프로젝트와 불필요한 게임 관련 콘텐츠 삭제.
프롬프팅 접근 방식
“메일은
해주고 https://joyuno.github.io/[] 사이트맵 들어가서 []안에 sitemap.xml을 넣으라는거지?"
처음에는 이렇게 단순 확인성 질문부터 던졌다. 그러자 AI는 _config.yml과 default.html의 설정 구조를 추측해서 답변했지만, 실제로는 Gitee Pages나 GitHub Pages의 동작 특성을 반영하지 못했다. 내 저장소가 정적 페이지 호스팅 중인데, AI는 사이트맵이 URL에서 바로 접근 가능하다고 가정하고 있었다.
잘 통한 점: grep과 cat으로 현재 _config.yml의 일부를 발췌해서 던지니 AI가 “plugins 목록에 jekyll-sitemap이 없네요”라고 정확히 짚었다. 단편적인 파일 스니펫보다는 전체 설정 구조의 일부를 보여주는 게 효과적이었다.
안 통한 점: 사이트맵 URL에 [] 대괄호가 들어간 질문은 AI가 “아마도 마크다운 링크 표기법을 물어보는 것”으로 오해했다. 질문에 메타포나 불명확한 기호가 섞이면 AI가 문맥을 잘못 잡는다는 걸 다시 알았다.
직접 손봐야 했던 부분: 학교 프로젝트 삭제 요청에서 AI는 “학교 프로젝트”라는 모호한 분류로 콘텐츠를 찾으려 했지만, 실제 폴더명이 univ나 capstone 같은 구체적 이름이 아니면 추측만 반복했다. 결국 ls로 폴더 구조를 직접 확인한 후 rm -rf로 처리해야 했다. 파일 시스템 수정은 AI가 아닌 내 손으로 해야 안전하다는 원칙을 다시 확인.
노하우: 1) 설정 파일처럼 구조가 중요한 경우
_config.yml의 전체 섹션을 발췌한다. 2) 질문에는 URL 예시를 실제 형태(https://joyuno.github.io/sitemap.xml)로 던져야 AI가 테스트 가능한 답을 준다. 3) 삭제는 AI의 추천 리스트를 받고 직접rm하라.
bit-scalp: 숏 전략 조건 조율과 Rate Limit 디버깅
오후는 트레이딩 봇 bit-scalp의 핵심 로직을 손봤다. 특히 숏 포지션에서만 적용되는 손절 조건과 진입 구간 확장에 대한 논의가 길어졌다.
“숏일 때만 손절” 조건 분리
첫 요청은 명확했다.
“B-4: 30분 내 -1% 빠른 손절 (risk_manager.should_close_position) 이건 숏일때만 부탁해”
AI는 risk_manager.py의 should_close_position 함수에 position_type 파라미터를 추가하고, 롱일 때는 해당 조건을 건너뛰는 방식으로 구현했다. 조건이 단일하고 의도가 명확하면 AI의 코드 생성이 매우 빠르고 정확했다. 단, 기존에 should_close_position이 여러 위치에서 호출되고 있었기 때문에 호출부까지 전부 수정하라고 프롬프트를 추가해야 했다 – 처음에는 함수만 바꿔주고 호출부는 안 알려줬다.
잘 통한 점: orchestrator.py 에서 risk_manager.should_close_position(...)이 호출되는 두 군데의 라인 번호를 미리 grep -n으로 알려줬더니 AI가 완벽하게 일관성 있게 수정했다. 컨텍스트의 일부(호출 위치)를 직접 제공하면 AI의 추론 부담이 확 줄어든다.
Rate Limit 에러와의 싸움
갑자기 API Error: Server is temporarily limiting requests가 발생했다. 원래는 rate limit이 아니라 서버 과부하 에러인데, AI는 “API 키 확인하라”는 일반론만 반복했다.
안 통한 점: 에러 메시지를 그대로 던졌지만, AI는
거래소 API 문서의 최신 업데이트를 반영하지 못했다. 실제 원인은 웹소켓 연결이 끊긴 후 재연결 시도가 너무 빨라 발생하는 429 Too Many Requests였다. 결국ps로 실행 중인 프로세스를 확인하고, 자체적으로time.sleep(5)를 삽입하여 해결. AI는 네트워크 상태나 실시간 외부 요인을 알 수 없으므로, 에러 메시지 외에 “내 시스템 상태 요약(몇 개의 봇이 동시 실행 중인지, 재연결 시도 횟수)”을 함께 제공해야 한다는 교훈을 얻었다.
숏 전용 변동폭 조율
가장 논의가 길었던 부분이다. 여태까지의 매매 데이터를 바탕으로 진입 시 변동폭을 분석해 달라고 한 다음, -0.15 ~ -0.3 구간에서도 숏 진입이 가능하되, 하락 추세(trendingdown)보다 덜 잡히도록 조건을 조율해 달라고 했다.
내 접근 방식:
- 먼저 데이터 요청: “여태까지의 매매 종목 진입 시 변동폭을 위아래로 비교해 달라”
- AI가 제시한 통계(예: 숏 진입 시 평균 상승 폭보다 하락 폭이 1.2배 컸다)를 보고
- “이 조건을 추가할 때
trendingdown신호보다 가중치를 0.7배로 낮춰서 적용해라” 라고 구체적 수치를 제시
잘 통한 점: 수치 기반의 조건(가중치 0.7, 구간 -0.15 ~ -0.3)을 명시하니 AI가 rsi_trend.py의 스코어링 로직을 정확히 수정했다. 모호한 “적절히 조율해줘”는 AI가 자의적으로 해석해서 이상한 결과를 내는 반면, 구체적인 조율 방안을 내가 제안하고 AI는 구현만 담당하는 분업이 효과적이었다.
안 통한 점: 처음에 “너의 생각은 어때”라고 물었을 때는 AI가 데이터 없이 추측만 늘어놨다. 의견을 묻는 프롬프트보다는 “데이터 분석 후 옵션 3개를 제시해라” 같은 명령형이 훨씬 생산적이다.
Godot 게임 프로젝트: 기존 기능 리서치와 미구현 리스트업
저녁에는 study_game_godot 프로젝트를 다시 열었다. 이전 세션에서 작업하던 게임 로직을 이어받아, “골드로 검상점에서 검사 강화”라는 기능이 기존에 유사 게임에 있던 기능인지 조사하고, 미구현 기능을 리스트업해 달라고 했다.
프롬프팅 스타일: “Continue from where you left off.”로 이전 컨텍스트를 그대로 활용. 이후 “그 골드로 검상점에서 검사는 기능도 기존 검강화하기 게임에 있던 기능 아니었어? 알아와봐 미구현 기능있으면 리스트업해” 라고 던졌다.
잘 통한 점: 이전 세션에서 이미 게임 구조와 기능 목록을 주고받은 상태였기 때문에 AI가 “이미 구현된 기능(A), 게임 디자인 문서에 있지만 미구현 기능(B), 유사 장르 게임에서 차용 가능한 기능(C)”을 명확히 구분해서 리스트업했다. 컨텍스트가 연속적인 세션에서는 중간에 파일을 다시 설명할 필요가 없어 효율이 급상승한다.
안 통한 점: “기존 검강화하기 게임”이 정확히 어떤 게임인지 AI가 모른다. 내가 전에 언급했던 게임명(예: “검강화하기”라는 모바일 게임)이 컨텍스트에 없으면 일반론만 말한다. 결국 내가 직접 “검강화하기 게임의 메커니즘 (강화 확률, 무기 등급, 골드 소모량 등)”을 한두 문장으로 요약해서 넣어줬더니 그제서야 “강화 실패 시 무기 파괴 기능이 빠져있다”는 유의미한 발견을 했다.
노하우: AI에게 기존 게임 리서치를 시킬 때는 비교 대상 게임의 핵심 메커니즘 3~5개를 먼저 알려줘야 한다. AI는 인터넷 검색을 못 하므로 내가 알고 있는 지식을 컨텍스트로 제공해야 한다.
오늘의 한줄
AI가 스스로 모르는 것은 알려주고, 애매한 조건은 숫자로 바꾸고, 파일 구조는 직접 확인하라 — AI는 내 인지 부하를 줄여주는 도구이지, 대신 생각해주는 존재가 아니다.