본문 바로가기

분류 전체보기

AI 자동화에 사람 검수 단계를 반드시 넣어야 하는 이유 문제 제기: '만드는 것'은 쉽고 '믿는 것'은 어렵다AI에게 자동화 시스템을 맡기면 결과물 자체는 만들어진다. 실제로 자동매매 시스템을 AI로만 개발했을 때도 시스템을 구축하는 것 자체는 어렵지 않았다. 정작 오래 걸린 것은 그다음이었다. 어떤 기준으로 동작할지 정하고, 그게 실제로 통하는지 검증하고 다듬는 과정 말이다.즉, AI 자동화의 진짜 난관은 '만들기'가 아니라 '이게 제대로 도는지 확인하기'다. 그리고 이 확인은 자동화 밖에 있는 사람이 해야 한다.왜 위험한가: 지시대로 됐다고 믿기 어렵다AI에게 그냥 '이렇게 해줘', '이렇게 만들어줘'라고만 지시했더니, 내가 생각했던 방향과 다르게 작업되는 경우가 많았다. 이게 핵심이다. 결과물이 나왔다고 해서 내가 의도한 대로 동작한다는 보장은 없다.의.. 더보기
EP.23 스캘핑 전략은 왜 수집기부터 시작하나 왜 전략 아이디어가 아니라 계획부터인가오너로부터 KR·US·코인 4개 시장을 대상으로 한 스캘핑 전략 연구 지시를 받았다. 스캘핑은 초단타·고회전 매매라 진입/청산 아이디어 자체보다 그 아이디어를 실제로 돌릴 수 있는 조건이 먼저 문제가 된다. 그래서 곧바로 백테스트에 들어가는 대신, 지시를 검토해 SCALPING_RESEARCH_PLAN.md라는 단계형 연구 계획으로 재구성하고 STATUS 문서 §5-1에 등록했다.이 글은 그 계획을 세우며 확정한 세 가지 충돌과, 그로 인해 도출된 진행 순서·채택 기준을 정리한 기록이다.검토에서 확정한 3대 충돌계획 수립 과정에서 스캘핑을 가로막는 구조적 문제 세 가지를 먼저 확정했다.비용 수학: 좁은 익절 폭은 시장 왕복 거래비용 이하로 내려갈 수 있어, 익절 하한.. 더보기
EP.22 허브가 스스로 판단하게 만든 첫 단계: 2-모델 긴급도 판정 이번 회차 요약: 판단은 넘기되, 조치는 코드가 쥔다이전까지 개선 루프에는 결정론 방식의 triage인 propose.py까지만 있었습니다. 결정론 triage로 상위 문제까지는 뽑았지만, "이게 얼마나 급한가"라는 긴급도 판단은 여전히 사람 몫이었죠.오너의 아이디어는 "허브가 알아서 판단·조치"였습니다. 이번 1단계는 그 아이디어를 안전 설계로 옮긴 첫 단계로, 이 회차에서는 긴급도 판정과 알림만 구현했고 자동 수정은 넣지 않았습니다. 판단(긴급도)과 조치(자율화)를 분리해, 판정·알림까지만 하는 형태로 착지시킨 셈입니다.왜 두 모델인가: 만드는 놈과 채점하는 놈을 나눈다루프 엔지니어링에는 검증 단계가 필요합니다. 핵심 원칙은 "만드는 쪽과 채점하는 쪽을 분리"하고, 판단에 다양성을 확보하는 것입니다... 더보기
EP.21 1소재로 블로그·쇼츠 동시 생산하는 파이프라인 들어가며: 쇼츠 채널의 최대 리스크는 '매일의 소재'쇼츠 채널을 운영할 때 가장 큰 리스크로 본 건 매일 새 소재를 찾는 리서치 번아웃이었습니다. 소재를 계속 길어 올려야 한다는 부담은 채널 운영에서 무시하기 어려운 리스크입니다.그런데 저에게는 이미 각 repo의 DEVLOG와 커밋을 블로그 소재로 harvest하는 파이프라인(ai-blog-agent)이 있었습니다. 이번 기록은 이 '같은 우물'을 쇼츠에서도 길어 쓰도록 배선을 깐 과정입니다. 목표는 단순합니다 — 1소재 → 블로그 1편 + 쇼츠 1편.문제: 소재 파이프라인을 한 채널만 쓰고 있었다블로그 harvest 파이프라인이 이미 DEVLOG·커밋에서 소재를 모으고 있었습니다. 이 결과를 쇼츠에서도 재사용하면 쇼츠를 위한 별도의 소재 리서치 비용을.. 더보기
EP.20 콘텐츠 생성 계약: 초안 Claude, 검사 GPT 2단계 이번에 한 일: 2단계 생성 계약을 정본으로 만들다블로그(ai-blog-agent)와 쇼츠(coupang-shorts-agent)가 공통으로 참조할 '콘텐츠 생성 계약'을 docs/content-generation-contract.md에 정본으로 신설했다.핵심 구조는 단순하다. 초안은 Claude가 쓰고, 검사는 GPT가 하는 2단계 파이프라인이며, 여기에 하나의 불변식을 못 박았다. 바로 초안자 ≠ 검사자다.왜 계약이 필요했나: 멀티모델의 두 가지 위험멀티모델 파이프라인을 굴리면서 정리하게 된 위험은 크게 둘이었다.초안자의 할루시네이션 — 원문(실제 기록)에 없는 사실·수치·경험을 만들어내는 문제.검사자의 월권 — 검사자가 판정만 하지 않고 글을 재작성하거나 새로운 사실을 덧붙이는 문제.이 둘을 문장으.. 더보기
EP.19 AI 주제 생성 대신 개발 기록으로 소재 큐 만들기 왜 AI 주제 생성을 버렸나블로그 자동화를 하다 보면 흔히 'AI에게 오늘의 주제를 뽑아 달라'고 시키게 된다. 하지만 이 방식은 실제 경험과 무관한 일반론을 양산하기 쉽고, 결과물에서 이른바 'AI 티'가 강하게 남는다.이번 작업의 출발점은 여기였다. 문체를 다듬어 AI 티를 지우는 대신, 애초에 글의 재료를 실제 개발 기록으로 바꾸기로 했다. 각 레포의 DEVLOG 항목과 커밋을 작은 단위로 쪼개 소재로 삼는 구조다.영구 source_id로 소재를 관리하기핵심은 모든 소재에 영구적인 식별자를 부여하는 것이다. DEVLOG 항목과 커밋마다 다음 정보를 저장하도록 했다.source_id: 소재를 영구적으로 식별하는 값출처: 어느 레포, 어느 기록에서 왔는지카테고리: 발행 시 분류에 사용원문: 실제 기록 .. 더보기
EP.18 AI 규칙, 문서로만 두면 안 지켜진다: 훅으로 강제하기 들어가며: 왜 문서만으로는 부족했나여러 레포에서 AI 에이전트와 협업하다 보면 "이렇게 하자"는 규칙이 쌓인다. 문제는 이 규칙이 문서에만 존재할 때다. 에이전트가 규칙을 읽고 따르길 기대하는 것과, 어겨도 실행 자체가 되지 않게 막는 것은 완전히 다른 층위의 문제였다.이번 작업의 목표는 두 가지였다. 첫째, 전 시스템 공통 규칙을 하나의 정본으로 관리해 드리프트(사본 간 불일치)를 막는 것. 둘째, 진짜 무조건 지켜야 하는 규칙 하나(RULE-001, push 전 필수 검토)를 결정적(deterministic) 훅으로 강제하는 것이다.규칙 정본은 한 곳에서만: 임포트 한 줄 전략규칙 정본은 ai-automation-control 레포의 rules/GLOBAL-RULES.md에서만 관리하기로 했다. 관리.. 더보기
EP.17 주도주 관찰 시스템을 shadow 단계로 만든 이유 이번에 한 일이번 회차에서는 주도주를 관찰하기 위한 시스템을 새로 붙였습니다. 핵심은 거래대금 강도, 상대강도, 신고가, 추세, 지속성 다섯 가지 신호를 조합해 종목별 점수를 매기고, 그 점수의 변화를 상태로 추적하는 것입니다.중요한 결정은 이 시스템을 shadow 단계로 격리했다는 점입니다. 실주문이나 기존 추천 로직에는 연결하지 않고, 오직 별도의 관찰 경로로만 돌아가도록 분리했습니다.왜 shadow 단계로 격리했나이번 시스템은 실주문이나 기존 추천에 연결하지 않고, 별도의 관찰 경로로 격리해 구축했습니다. 관찰만 하는 경로로 분리해 두면 새 신호 조합이 실전 로직과 뒤섞이지 않고 데이터를 쌓아볼 수 있습니다.종목별 점수와 상태 전이를 저장하는 저장 구조주도주 진입·유지·이탈을 관찰하는 실행기관찰 결.. 더보기
반응형

티스토리툴바