관찰전용 썸네일형 리스트형 그 순간에만 존재하는 값을 잃지 않는 법: 진입 시점 데이터 저장 전략 문제: '왜 손해 봤지?'에 답할 수 없는 기록매매든, 실험이든, 사용자 행동 분석이든 결과를 남기는 시스템은 많다. 그런데 결과만 남기면 나중에 특정 질문에 답하기 어려울 수 있다. "이 거래는 왜 손해가 났을까?"라고 물었을 때, 살 때 어떤 상황이었는지에 대한 기록이 아예 없기 때문이다.실제 자동매매 프로그램을 손보면서 이 문제를 정면으로 겪었다. 매수 기록에는 그 종목을 왜 골랐는지 선정 점수 하나만 남아 있었다. 정작 살 때의 시장 상황 — 짧은 흐름과 긴 흐름, 하루 안에서 가격이 어디쯤이었는지, 거래량 비교, 가격이 얼마나 출렁였는지, 대표 코인의 움직임, 시장 심리 지표 — 은 어디에도 저장되지 않았다.그 결과, 이긴 비율은 높은데도 수수료를 빼면 손해가 나는 상황의 원인을 살 때의 상황별.. 더보기 EP.35 매수할 때와 팔 때 정보를 한 줄로 잇기: 자동매매 기록 개선기 P0-C 이번 회차에서 풀려던 문제물건을 살 때의 상황과 팔 때의 결과를 따로따로 적어두면, 나중에 "왜 손해를 봤지?"라고 물어도 답을 찾기 어렵다. 산 순간이 어떤 분위기였는지 기록이 남아 있지 않기 때문이다. 이번 작업은 바로 이 문제를 다뤘다.자동으로 사고파는 프로그램이 있는데, 사는 순간의 여러 정보(그때의 시장 흐름, 하루 안에서 가격이 어디쯤이었는지 등)를 저장했다가, 팔 때 그 기록을 다시 꺼내 하나로 이어 붙이는 기능을 넣었다. 이렇게 하면 "어떤 상황에서 샀을 때 결과가 좋았는지"를 한 줄로 볼 수 있다. 중요한 점은 실제로 사고파는 규칙은 하나도 건드리지 않았다는 것이다. 오직 기록만 늘린, 지켜보기 위한 작업이다.무엇이 부족했나 — 원인을 못 찾던 이유기록을 살펴보니 두 가지가 겹쳐 있었다... 더보기 자동화에 판단을 맡길 때 '긴급도'와 '실행 권한'을 반드시 분리해야 하는 이유 문제: '급하다'와 '자동으로 고쳐라'를 한 덩어리로 묶는 실수AI에게 "알아서 판단하고 조치하라"고 맡기고 싶은 순간이 온다. 개선 아이디어를 수집하고, 우선순위를 매기고, 급한 건 알려주고, 나아가 스스로 고치게 하는 자가발전 루프다. 이때 가장 흔한 설계 실수는 '긴급도 판단'과 '자동 실행 권한'을 하나의 결정으로 묶는 것이다."이 문제는 A등급(가장 급함)이다" → "그러니 바로 자동 수정한다"로 이어지는 흐름이 대표적이다. 언뜻 합리적으로 보인다. 급한 문제니까 빨리 고치는 게 맞지 않나? 하지만 급하다는 것과 AI가 손대도 안전하다는 것은 전혀 다른 질문이다. 급한 결제 로직 오류는 급하면서도 절대 AI가 자동으로 건드려서는 안 되는 코드다.실제 개발 기록(개선 루프 1단계, improvem.. 더보기 EP.22 허브가 스스로 판단하게 만든 첫 단계: 2-모델 긴급도 판정 이번 회차 요약: 판단은 넘기되, 조치는 코드가 쥔다이전까지 개선 루프에는 결정론 방식의 triage인 propose.py까지만 있었습니다. 결정론 triage로 상위 문제까지는 뽑았지만, "이게 얼마나 급한가"라는 긴급도 판단은 여전히 사람 몫이었죠.오너의 아이디어는 "허브가 알아서 판단·조치"였습니다. 이번 1단계는 그 아이디어를 안전 설계로 옮긴 첫 단계로, 이 회차에서는 긴급도 판정과 알림만 구현했고 자동 수정은 넣지 않았습니다. 판단(긴급도)과 조치(자율화)를 분리해, 판정·알림까지만 하는 형태로 착지시킨 셈입니다.왜 두 모델인가: 만드는 놈과 채점하는 놈을 나눈다루프 엔지니어링에는 검증 단계가 필요합니다. 핵심 원칙은 "만드는 쪽과 채점하는 쪽을 분리"하고, 판단에 다양성을 확보하는 것입니다... 더보기 이전 1 다음
