루프엔지니어링 썸네일형 리스트형 자동화에 판단을 맡길 때 '긴급도'와 '실행 권한'을 반드시 분리해야 하는 이유 문제: '급하다'와 '자동으로 고쳐라'를 한 덩어리로 묶는 실수AI에게 "알아서 판단하고 조치하라"고 맡기고 싶은 순간이 온다. 개선 아이디어를 수집하고, 우선순위를 매기고, 급한 건 알려주고, 나아가 스스로 고치게 하는 자가발전 루프다. 이때 가장 흔한 설계 실수는 '긴급도 판단'과 '자동 실행 권한'을 하나의 결정으로 묶는 것이다."이 문제는 A등급(가장 급함)이다" → "그러니 바로 자동 수정한다"로 이어지는 흐름이 대표적이다. 언뜻 합리적으로 보인다. 급한 문제니까 빨리 고치는 게 맞지 않나? 하지만 급하다는 것과 AI가 손대도 안전하다는 것은 전혀 다른 질문이다. 급한 결제 로직 오류는 급하면서도 절대 AI가 자동으로 건드려서는 안 되는 코드다.실제 개발 기록(개선 루프 1단계, improvem.. 더보기 EP.22 허브가 스스로 판단하게 만든 첫 단계: 2-모델 긴급도 판정 이번 회차 요약: 판단은 넘기되, 조치는 코드가 쥔다이전까지 개선 루프에는 결정론 방식의 triage인 propose.py까지만 있었습니다. 결정론 triage로 상위 문제까지는 뽑았지만, "이게 얼마나 급한가"라는 긴급도 판단은 여전히 사람 몫이었죠.오너의 아이디어는 "허브가 알아서 판단·조치"였습니다. 이번 1단계는 그 아이디어를 안전 설계로 옮긴 첫 단계로, 이 회차에서는 긴급도 판정과 알림만 구현했고 자동 수정은 넣지 않았습니다. 판단(긴급도)과 조치(자율화)를 분리해, 판정·알림까지만 하는 형태로 착지시킨 셈입니다.왜 두 모델인가: 만드는 놈과 채점하는 놈을 나눈다루프 엔지니어링에는 검증 단계가 필요합니다. 핵심 원칙은 "만드는 쪽과 채점하는 쪽을 분리"하고, 판단에 다양성을 확보하는 것입니다... 더보기 이전 1 다음
