EP 빌드로그 썸네일형 리스트형 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 단계로 격리했나이번 시스템은 실주문이나 기존 추천에 연결하지 않고, 별도의 관찰 경로로 격리해 구축했습니다. 관찰만 하는 경로로 분리해 두면 새 신호 조합이 실전 로직과 뒤섞이지 않고 데이터를 쌓아볼 수 있습니다.종목별 점수와 상태 전이를 저장하는 저장 구조주도주 진입·유지·이탈을 관찰하는 실행기관찰 결.. 더보기 EP.16 장초반 방향예측 적중률 집계와 Shadow Open 연결기 이번 회차에서 다루는 문제신호를 만드는 것과 그 신호가 실제로 맞는지 확인하는 것은 별개의 문제입니다. 이번 작업의 핵심 질문은 두 가지였습니다.예측이 실제 결과와 얼마나 맞았는지를 어떻게 지속적으로 확인할 것인가검증되지 않은 신호를 실주문과 기존 추천 흐름에 영향을 주지 않고 어떻게 매매에 연결해 볼 것인가누적 적중률 집계: 정확도 리포트 추가먼저 예측과 실제 결과를 날짜별로 대사(reconcile)하는 정확도 리포트를 추가했습니다. 신호를 계속 뽑아내는 것보다, 그 신호가 시간이 지나면서 실제로 맞았는지를 꾸준히 대사하는 작업이 먼저라고 판단했기 때문입니다.리포트는 예측과 실제 결과를 날짜별로 대사해 누적 적중률을 집계하는 구조입니다. 이렇게 하면 특정 하루의 결과에 흔들리지 않고, 신호 품질을 시간.. 더보기 EP.15 shadow-only 모드에서 텔레그램 알림 분리하기 들어가며: 관찰만 하는데 왜 알림이 문제였나이번 글은 shadow-only 모드에서 겪은 알림 정책 문제와 그 해결 과정을 정리한 기록입니다. shadow-only 모드는 실제 주문을 내지 않고 전략의 동작만 관찰하는 실험 상태를 말합니다.문제는 단순했습니다. 가상 관찰을 돌리는 중에도 추천·스캔·수동매매 메시지가 진입·청산 알림과 함께 수신되었습니다. 그러다 보니 실제 행동을 요청하는 메시지와 실험 관찰 결과 알림을 눈으로 구분하기 어려웠습니다.무엇이 문제였는지shadow-only 모드의 취지는 '주문을 내지 않고 지켜보기'입니다. 그런데 가상 관찰 중에도 여러 유형의 메시지가 함께 수신되어 구분이 어려웠습니다.추천·스캔 메시지: 원래는 사람이 판단·행동하도록 유도하는 알림수동매매 메시지: 실제 주문 .. 더보기 이전 1 2 3 4 5 다음
