멀티레포 썸네일형 리스트형 인프라를 계약으로 만들면 기능 추가가 10파일로 끝난다 — 재사용 가능한 코어 설계법 문제: 비슷한 기능을 세 번 만들 때마다 처음부터 다시 짠다같은 성격의 기능을 여러 번 추가해 본 사람은 안다. 두 번째, 세 번째를 만들 때도 매번 저장 로직·리포트·초기화 코드를 다시 짜게 된다. 겉보기엔 '조금 다른' 기능처럼 보이지만, 실제로 다른 부분은 극히 일부이고 나머지는 매번 복사·수정하는 반복 작업이다.실제 개발 기록에서 이 문제를 정면으로 마주친 사례가 있다. 스캘핑 가상매매(섀도우) 기능을 세 시장 — KR(분봉 돌파), US(시세샘플 돌파), Coin(눌림목 반등) — 에 동시에 추가해야 했다. 각각 2,000만원 가상 장부와 장마감 리뷰가 필요했다.결과적으로 설계(SCALPING_SHADOW_DESIGN.md)부터 3레포 병렬 구현, 리뷰·테스트(총 151건 신규, KR 전체 95.. 더보기 여러 시스템에 흩어진 같은 문제를 빠짐없이 닫는 법 문제 제기: '고쳤다'는 완료가 아니다여러 시스템이 같은 뼈대를 공유하면, 하나에서 발견한 문제는 대개 다른 곳에도 있다. 실제 개발 기록에서는 KR·US·코인 세 시장의 자동매매 시스템에서 같은 종류의 운영 위험이 여러 레포에 공통으로 흩어져 있었다. 원장 불일치, 시세 조회 실패 처리, 계정 동기화, 승인 인가 같은 문제들이 시장별로 다른 레포에 나뉘어 있었다.이때 흔한 착각은 "코드를 고쳤으니 끝났다"는 것이다. 하지만 멀티레포 환경에서 안전 수정은 발견 → 수정 → 배포 → 관찰이라는 사슬 전체가 이어져야 실제로 닫힌다. 커밋 하나가 머지됐다는 사실은 그 사슬의 두 번째 고리일 뿐이다. 세 번째, 네 번째 고리가 빠지면 문제는 조용히 남아 있다.왜 위험한가: 빠지는 시장이 생길 수 있다레포가 하나.. 더보기 AI에게 규칙을 지시서로 맡길 때와 훅으로 강제해야 할 때 문제: AI가 규칙을 '읽었다'고 지킨 게 아니다AI 코딩 에이전트에게 "push 전에는 반드시 검토해"라고 문서로 적어두면, 대부분의 경우 잘 지킨다. 그런데 '대부분'이 문제다. 컨텍스트가 길어지거나, 급한 작업이 끼거나, 프롬프트가 살짝 달라지면 같은 규칙도 건너뛴다. 문서는 부탁이지 강제가 아니기 때문이다.필자는 여러 레포를 한 AI 에이전트로 관리하면서 이 경계를 마주했다. 전 시스템 공통 규칙 체계를 만들고, 그 첫 규칙 RULE-001(push 전 필수 검토)을 '문서로 부탁할지, 훅으로 막을지' 판단해야 했다. 결론부터 말하면 두 방식은 서로 다른 층위이며, 섞어 쓰되 역할을 나눠야 한다.왜 문서만으로는 위험한가문서 기반 규칙의 약점은 두 가지다. 첫째, 확률적이다. LLM은 지시를 따를 .. 더보기 EP.24 스캘핑 섀도우 3종 하루 완성기: KR·US·Coin 동시 구현 들어가며: 왜 3종을 하루에 붙일 수 있었나이번 작업의 핵심은 새 전략을 짠 게 아니라, 이미 계약(contract)으로 분리해둔 장부 인프라 위에 전략만 얹은 것입니다. 기존 4장부 도구(book_report·equity_graph·reset·review_delivery)를 슬러그만 shadow_scalp로 바꿔 전면 재사용했고, 그 덕에 신규 코드가 전략(rules)·비용(engine)·데이터 어댑터에 집중될 수 있었습니다.결과적으로 설계 문서(SCALPING_SHADOW_DESIGN.md) 작성 → 3개 레포 병렬 구현 → 리뷰·테스트 → push까지를 하루에 마쳤습니다. 이 글은 그 과정을 시장별로 정리한 개발 기록입니다.설계: 각 시장 2,000만원 가상 장부 + 장마감 리뷰세 시장 모두 공통 .. 더보기 EP.18 AI 규칙, 문서로만 두면 안 지켜진다: 훅으로 강제하기 들어가며: 왜 문서만으로는 부족했나여러 레포에서 AI 에이전트와 협업하다 보면 "이렇게 하자"는 규칙이 쌓인다. 문제는 이 규칙이 문서에만 존재할 때다. 에이전트가 규칙을 읽고 따르길 기대하는 것과, 어겨도 실행 자체가 되지 않게 막는 것은 완전히 다른 층위의 문제였다.이번 작업의 목표는 두 가지였다. 첫째, 전 시스템 공통 규칙을 하나의 정본으로 관리해 드리프트(사본 간 불일치)를 막는 것. 둘째, 진짜 무조건 지켜야 하는 규칙 하나(RULE-001, push 전 필수 검토)를 결정적(deterministic) 훅으로 강제하는 것이다.규칙 정본은 한 곳에서만: 임포트 한 줄 전략규칙 정본은 ai-automation-control 레포의 rules/GLOBAL-RULES.md에서만 관리하기로 했다. 관리.. 더보기 이전 1 다음