서론
지난번에는 오버레이 탐색의 시행착오에 대해 글을 썼습니다.
1회차에서 'Claude Code를 파트너 삼아 개발하고 있다'고만 언급했을 뿐, 그 내용 자체는 다루지 못했습니다. 9회차가 된 이번 글에서는 이 프로젝트에서 Claude Code를 어떻게 사용하고 있는지, 성공적인 활용 방법과 주의해야 할 점을 포함하여 작성합니다.
어떤 상황에서 사용하는가
이 프로젝트에서는 개발의 거의 모든 과정에 걸쳐 Claude Code의 도움을 받고 있습니다.
- 스크래핑 및 파싱 처리 유지보수
- 특징량(Feature) 아이디어 도출 및 구현
- 정확도 저하 또는 버그 원인 조사
- Notebook 정리 및 스크립트화
- 운영 트러블 분리 (Troubleshooting)
- 문서화 (README나 설계 메모) 정비
단순히 구현을 맡기기보다는, '함께 조사하고, 함께 고치는' 파트너로서의 활용 방식이 가장 적합하다고 느낍니다.
성공적이었던 사용 사례
원인 조사의 파트너로 활용하기
가장 효과를 크게 느낀 부분은 2회차에서 작성했던 NAR의 AUC(Area Under the Curve) 악화 원인 조사였습니다. '최근 AUC가 떨어진 것 같다'는 막연한 상담에서 시작하여, 저장된 모델 메타데이터를 시계열로 추적하고, 악화가 시작된 시기를 특정하며, 그 시기에 발생한 변경 사항을 파악하는 조사를 함께 진행했습니다.
처음에는 '학습 창(Learning Window) 단축이 원인일 수 있다', '일별 데이터 처리로 바꾼 것이 원인일 수 있다'라며 모델 측의 가설들을 연이어 의심했지만, 학습 데이터 행 수가 거의 변하지 않았다는 사실을 깨달으면서 데이터 품질 문제로 방향이 전환되었습니다. 가설을 세우고, 데이터를 통해 확인하고, 틀리면 다음으로 넘어가는 사이클을 빠르게 돌릴 수 있다는 점이 큰 도움이 되었습니다.
기계적이고 양이 많은 작업을 맡기기
Notebook에 작성했던 실제 운영 처리 코드를 스크립트화하는 이식 작업도 Claude Code에게 맡겼습니다. 대상은 12개의 파일이었는데, 각 파일 자체는 단순하지만 의존 관계 확인이나 import 정리 등 그 양이 많아 사람이 할 경우 실수가 발생하기 쉬운 작업입니다.
이때도 원본 Notebook을 삭제하지 않고 '내용만 비우고 이식 메모만 남긴다'라는 규칙을 처음에 정하고, 그것에 따라 진행하도록 했습니다. 나중에 '저 Notebook은 어디로 옮겼지?' 하고 헤매지 않기 위함입니다.
운영 트러블 분리 (Troubleshooting)
개발과 직접적인 관련이 없는 환경 문제도 상담했습니다. 예를 들어, Mac이 절전 모드(Sleep)에 들어가서 cron Job이 실패하는 문제의 경우, 절전 모드의 원인이 여러 가지가 있음을 하나씩 분리하여 대책을 마련했습니다. 또한, 의존 패키지가 갑자기 사라지는 등 원인 불명의 트러블도 있었는데, 복구 절차를 바로 확인할 수 있어서 도움이 되었습니다.
정한 운영 규칙
편의성이 높은 만큼, 너무 많이 맡기면 사고로 이어질 수 있기 때문에 몇 가지 규칙을 정했습니다.
- 커밋(Commit)은 내가 진행하기: 변경 내용 확인과 커밋은 반드시 사람이 직접 해야 합니다. 커밋 메시지 문구는 그때그때 작성하게 하지만, 실행은 제가 합니다.
- 파일 삭제 전에는 반드시 확인하기: 함부로 지우지 않는다는 간단한 약속입니다.
- 작업 범위를 프로젝트 디렉토리 내로 한정하기: 홈 디렉토리 등 의도하지 않은 장소에 쓰기(Write)가 발생하지 않도록 합니다.
- 임시 파일은 프로젝트의 tmp 폴더에 두기: 시스템 공용 임시 영역을 사용하지 않고, 나중에 정리하기 쉬운 곳에 모아둡니다.
- 큰 변경 사항은 단계적으로 제안받기: 한 번에 대량의 변경을 넣지 않고, 검토 가능한 단위로 나누어 받습니다.
- 불명확한 점은 작업 전에 확인받기: 임의로 추측하여 진행하지 않도록 하고, 헷갈리면 질문하도록 합니다.
특히 마지막 두 가지는 'AI가 알아서 멋지게 해줄 것'이라는 기대를 지나치게 하지 않기 위한 안전장치입니다.
기억과 인계 (Handover)
Claude Code는 대화(Conversation)마다 기억이 초기화되기 때문에, 지속적인 개발에서는 '지난 내용 이어가기'를 어떻게 할지가 과제입니다. 이 프로젝트에서는 다음 두 가지 방법을 사용하고 있습니다.
- 메모리 기능: 운영상의 결정 사항이나, 과거에 발생했던 트러블의 원인과 대처법, 그리고 '다음으로 해야 할 일' 같은 정보를 종류별로 파일에 축적해 놓는 시스템입니다. 예를 들어 'crontab 재생성은 반영 전에 Job 개수를 확인해야 한다'와 같이, 한 번 쓰라린 경험을 교훈으로 남겨둡니다.
- handover(인계 문서): 작업이 끝날 때마다 현재 상황, 미완료된 태스크, 주의사항 등을 정리한 문서를 작성하게 하고, 다음 세션에서 이 문서를 읽히는 방식으로 진행합니다.
둘 다 새로운 세션을 시작할 때 '지금 어떤 상황이고, 무엇이 결정되었으며, 무엇이 해결되지 않았는지'를 즉시 공유하기 위한 노력입니다. 사실 이 연재의 구성이나 집필 방침 역시 메모리에 기록하면서 진행하고 있습니다.
주의해야 할 점들
편리하기 때문에 오히려 조심하고 있는 부분이 있습니다.
AI 출력은 반드시 직접 검증한다: 문서를 요약하게 했을 때, 원문 기술의 일부를 과대 해석하여 실제와는 조금 다른 표현이 되는 경우가 있었습니다. 예를 들어 "자동 투표에는 Playwright를 사용하고 있다"라는 설명이, 실제로는 지방 경마 측에만 해당되는 이야기인데도 중앙 경마 측에도 똑같이 쓰여 있는 경우 같은 것입니다. 이 연재의 초안 역시 Claude Code에게 작성하게 하고 있지만, 사실 관계는 공개 전에 제가 직접 확인합니다.
검증 없이 본 서비스에 적용할 수 없다: 제4회에서 썼듯이, 백테스트(backtest)의 좋은 성적은 과적합(overfitting)일 가능성이 있습니다. AI가 제시해 준 "좋아 보이는 결과"를 그대로 실제 운영 환경에 반영하지 않도록, 미관찰 기간에서의 검증을 거치는 습관을 들였습니다.
어디까지 공개할지는 스스로 판단한다: 제1회 전후로, 스크레이핑(scraping)이나 자동 투표에 대한 기술을 공개해도 되는지에 대한 문제가 있었습니다. 이러한 종류의 판단은 AI에게 맡기지 않고, 사이트명을 가리는 등 제가 직접 선을 긋고 있습니다.
요약
Claude Code는 구현을 대신해 주는 도구라기보다는, "조사하고 정리하며 시도하는" 속도를 높여주는 동반자라고 느낍니다. 그만큼 무엇을 맡기고 무엇은 스스로 판단할지 경계가 이전보다 훨씬 중요해졌습니다.
다음 회차 예고
다음 회차에서는 예측 모델을 여러 개 나열하여 사용 전환하는 메커니즘에 대해 작성할 예정입니다.
- Model A/B를 활용한 듀얼 모델 운영 및 승격 메커니즘
- 단승(Win), 복승(Place), 삼쌍승식(Tricast) 각각을 위한 메타 모델
- 경주의 "난이도"를 예측하는 센서
등을 예정하고 있습니다.
※본 기사는 접근 분석을 위해 Google Analytics를 사용하고 있습니다.
토론
