만들어 돌려 보고, 숫자로 확인한 것.
AI 에이전트와 업무자동화를 실제로 운영하면서 측정한 것을 적습니다. 잘된 것만 고르지 않고, 숫자가 저희 가정을 뒤집은 지점도 그대로 남깁니다.
- 2026-09-16자동화 대체 시간 목록의 채용 사이트 1곳 공고 수집·적합도 판정 항목 — 실행 일정 7 7 * * * · 최근 30일 실행 11회(공용 로그 검색) · 사람이 하면 건당 20분(검색·목록 훑기 12분 + 상위 공고 열람·기록 8분) · 근거 등급 estimate · 대체 시간 3.7시간같은 목록의 이웃 항목 5개와 실행 일정·최근 30일 실행 횟수·셈법·건당 시간 대조 — 11회 네 줄(공용 로그 검색 2 · 전용 로그 2), 60회·96회 두 줄(산출 마커)
채용공고 자동 수집 효과 — 적합도 판정의 값은 3.7시간에 없었다
채용공고 자동 수집 작업이 아낀 시간은 목록 파일에 한 달 3.7시간으로 적혀 있지만, 이 값은 몇 번 돌았는지와 사람이 공고를 훑는 시간만 셀 뿐 적합도 판정이 맞았는지는 재지 않습니다. 매일 오전 7시 7분에 도는 작업의 최근 30일 실행 기록은 11회였고, 건당 20분은 검색·목록 훑기 12분과 상위 공고 열람·기록 8분을 더한 추정이었습니다.
채용공고 자동 수집업무 자동화 효과크론측정 설계 - 2026-09-16개인 저장소 42개 → 45개 · 사람이 한 커밋 4,612건 → 5,918건(+1,306) · 코드 1,143,445줄은 기준선 방식이 달라 비교 제외성장한 저장소 10곳 커밋 증가분 +824 ~ +7 · 새 저장소 3곳 커밋 4~18건, 577~1,534줄
코드 라인 수로 성장을 비교하지 않은 이유 — 기준선을 다른 방식으로 셌다
코드 라인 수는 두 시점을 같은 방법으로 셌을 때만 성장의 증거가 되고, 우리 기준선은 그 조건을 채우지 못해 비교에서 뺐다. 2026년 8월 21일 기준선의 줄 수는 git이 추적하지 않는 파일까지 센 옛 방식이었고, 9월 15일에 센 1,143,445줄은 그 방식이 아니라서 둘을 빼면 방법 차이까지 성장처럼 잡힌다. 같은 기간 사람이 한 커밋은 4,612건에서 5,918건으로 1,306건 늘었지만, 그중 824건이 저장소 한 곳에서 나왔다.
코드 라인 수git 커밋개발 생산성측정 설계 - 2026-09-16'팔로우' 글자만 뗀 재채점 — 후보 35건 전부 6~8점, 기존 판매자·칼럼 감점 적중 0건, 정밀도 0.19로 기각손대지 않은 표본 44건 — 정밀도 0.37(14/38) → 0.68(13/19), 재현율 1.00 → 0.93(13/14), 14일 실데이터 리드 2건 → 10건
리드 스코어링 오탐, '팔로우' 글자가 판매자 필터였다
리드 스코어링 규칙에서 진짜 구매 문의를 떨어뜨린 범인은 '팔로우' 버튼 글자였지만, 그 글자만 떼자 판매자 글까지 전부 통과했다. 원문으로 채점하면 8점인 문의가 수집본에서는 4점을 받아 문턱 5점 아래로 떨어졌고, 버튼 글자를 떼자 후보 35건이 모두 6~8점으로 올라갔다. 진짜 원인은 구매 표현을 문장의 성격과 떼어 센 규칙 세 곳이었고, 고친 뒤 한 번도 열어 보지 않은 표본 44건에서 정밀도가 0.37에서 0.68로 올랐다.
리드 스코어링규칙 기반 분류웹 스크래핑데이터 품질 모니터링 - 2026-09-15운영 점검 기록 1건(2026년 8월 31일) — 다섯 가지 안전장치 재확인 결과발송 기록 전수 — 최근 13일 치 발송 건수, 8월 27일~30일 일별 추이
설정값 드리프트 — 주석은 8인데 코드는 이미 12였다
자동 답글 봇의 하루 발송 상한을 정해 둔 크론탭 주석이 실제 코드 값과 달라져 있는 설정값 드리프트가, 나흘 밀린 정기 점검에서 드러났습니다. 점검 자체는 다섯 가지 항목 모두 정상이라는 결론으로 끝났지만, 그 과정에서 발송 상한을 적어 둔 주석 문구가 이미 보름 전에 바뀐 실제 값을 따라가지 못하고 있다는 사실이 나왔습니다.
설정값 드리프트크론 자동화코드와 문서 불일치운영 점검 - 2026-09-15관련 연구 확인 — LLM 심사자와 사람 전문가의 동의율 64~68%(2025년 다수 연구)2026년 8월 13일 발표된 멀티에이전트 연구 — 4인 투표 그룹의 정확도 하락 확인
AI 자체 검증 정확도, 다시 확인시킬수록 떨어진 이유
AI 자체 검증 정확도는 에이전트에게 여러 번 다시 확인시키거나 여러 모델에게 동시에 판단을 맡길수록 오히려 떨어졌다. 강한 모델에게 스스로 다시 확인해 보라고 시켰더니 정확도가 26.8%에서 16.7%로 내려갔고, AI 넷이 모여 투표하는 방식도 토론을 거친 뒤 오히려 정확도가 낮아진다는 결과가 나왔다. 처음엔 여러 목소리를 모으면 판단이 정교해질 거라 가정했는데, 실제로는 정보가 사라지는 쪽으로 움직였다. 그래서 판단을 한 사람에게 모으고 실패 사례부터 직접 들여다보는 방식으로 기준을 다시 짰다.
AI 에이전트LLM 심사자자기 재확인골든 데이터셋 - 2026-09-15미확인 상태였던 사실 8건을 정리하는 과정에서 발견 — 회신과 제안서 마지막 장(7쪽)에 동시 게재검사 스크립트의 금지 문장 목록 직접 확인 — 카카오 비용·무료 관련 규칙 이미 3개 존재
카카오톡챗봇, 비즈니스 채널 없인 못 붙는 이유 — 검사기가 놓친 문장 한 줄
카카오톡챗봇은 카카오톡 채널에 붙이는 순간부터 비즈니스 채널 전환을 전제로 하는데, 그 전제를 뒤집은 문장이 고객에게 나갈 회신과 제안서 마지막 장에 그대로 실려 있었다. 자동 검사 도구는 이미 카카오 관련 비용·무료 주장을 잡는 규칙을 3개나 갖고 있었는데도 이 문장을 통과시켰다. 원인은 두 가지가 겹쳐 있었다 — 참고 문서를 한 층 얕게 읽은 것과, 검사 규칙이 잡던 문장 형태와 실제 문장의 형태가 서로 달랐던 것이다.
카카오톡챗봇비즈니스 채널발송 전 자동 검사정규식 검증 - 2026-09-15메모리 관측 기록 1,001건(2026년 8월 21일부터 9월 11일까지) + 프로세스 전체 스캔(`ps`) — MCP 고아 프로세스 0건 확인최근 14일 대화형 세션 208개 대상 서버별 실사용률 실측 — playwright 6.2%(13개)·google-workspace 8.7%(18개)·veilbrowser 0%
MCP 서버 메모리, 창 하나에 428MB가 붙던 이유
MCP 서버 메모리는 원인이 안 꺼지는 프로세스가 아니라, 거의 쓰지 않는 서버까지 창을 열 때마다 전부 미리 띄우는 방식에 있었다. 실측해 보니 창 하나가 연결된 서버 3종 때문에 최소 276MB에서 최대 428MB를 쓰고 있었는데, 그중 하나는 최근 14일 동안 단 한 번도(0%) 쓰이지 않았다. 실제로 쓸 때만 서버를 켜는 중개 프로그램을 앞에 세운 뒤 창 하나당 메모리는 24MB로 줄었다.
MCP 서버Claude Code메모리 최적화지연 시작 - 2026-09-15업무대체형으로 분류된 크론 70개 대상 2026년 9월 14일 최근 30일 로그 실측 — 실행 0회 20개 · 로그 형식이 달라 셀 수 없는 것 17개이름이 남은 크론 10개 — 전용 로그가 있는데도 실행 0회인 것 4개 · 로그 자체가 없는 것 6개
크론 모니터링, 업무대체형 70개 중 20개가 실행 0건이었다
크론 모니터링에서 확인해야 할 것은 목록에 등록됐는지가 아니라 실제로 실행됐는지입니다. SGK 스튜디오가 시간 절감을 말할 자격을 준 업무대체형 크론 70개를 대상으로 2026년 9월 14일 최근 30일 로그를 세어 보니, 그중 20개는 실행 흔적이 0건이었고 17개는 로그 형식이 서로 달라 횟수를 셀 수조차 없었습니다. 실제로 셀 수 있었던 크론은 70개 가운데 3분의 1을 조금 넘는 수뿐이었습니다.
크론 모니터링업무 자동화로그 감사실행 기록 - 2026-09-142026년 8월 13일 배포본 대표 검수 지적 6건 + 재현 중 추가 결함 2건수정 후 서버 렌더링 3가지 진입 경우 실측 (카드 중복·문구·할인율·폼 선택지)
개인화 랜딩페이지 인원별 절감액 — 결론에서 1명으로 돌아간 논증
개인화 랜딩페이지에서 인원별 절감액을 보여 줄 때 가장 먼저 무너진 곳은 계산식이 아니라 논증의 순서였습니다. 직원 수에 맞춰 숫자를 바꾸는 페이지를 배포한 날 대표 검수에서 지적 6건이 나왔고, 그 지적을 재현하는 동안 결함 2건을 더 찾았습니다. 고친 뒤 서버 렌더링 결과를 3가지 진입 경우로 다시 재 보니 같은 인원 카드 중복은 0건, 「본전」 문구는 0회였고, 사례 소개 할인율 표기는 10~20%에서 실제 집행 근거가 있는 37~49%로 바뀌었습니다.
개인화 랜딩페이지ReactNext.js전환 카피콜드메일 - 2026-09-14발송 전 게이트 판정별 반송률 — 공식 주소 대조 검증 통과 174건 9.8% · 판단불가 128건 11.7% · 미등재 162건 4.9% (관측 비교)반송 40건 중 32건이 공식 주소 대조 등재 + 신뢰도 high — 반송률 8.3%로 하루 발송 상한 100통 → 50통
이메일 반송률과 SMTP RCPT 확인 — 검증 통과 주소가 2배 더 반송됐다
이메일 반송률 8.3%를 끌어올린 주소는 출처가 불분명한 주소가 아니라 홈페이지 공식 주소로 확인된 주소였다. 판정별로 나눠 재 보니 공식 주소로 확인된 174건은 9.8%, 확인되지 않은 162건은 4.9%가 반송됐다. 그래서 공식 주소에만 보내자는 대책을 버리고, 발송 직전에 받는 쪽 메일 서버에 그 계정이 있는지 SMTP RCPT로 직접 묻는 검사를 넣었다. 이미 반송된 주소에 소급해 돌리자 48%를 걸러 냈고, 정상 주소는 한 건도 막지 않았다.
이메일 반송률콜드메일SMTP이메일 주소 검증 - 2026-09-1430일 콜드메일 깔때기 원천 계측 — 발송 16,268 → 열람 2,808 → 클릭 913 → 사이트 실방문 18(0.6%) → 폼 제출 4벤치마크 뉴스레터 184통 전수 — 본문 130자·배너 2장, 발송 100통 중 37%가 콘텐츠 외 목적(세미나 모객 10·칼럼 재포장 8·제3자 검증 7·서비스 판매 6·채널 소식 3·책 배포 3)
B2B 뉴스레터 벤치마크 — 184통을 세어 보니 권위는 메일 밖에서 왔다
B2B 뉴스레터가 회사의 권위를 만든다는 가설은 절반만 맞았다. 본보기로 삼은 회계법인 마일스톤의 뉴스레터 184통을 전수로 세어 보니 메일 한 통의 본문은 130자, 배너는 두 장이 전부였고, 권위는 언론 인터뷰·기업 컨설팅·책·무료 세미나처럼 메일 밖에서 왔다. 뉴스레터가 한 일은 그 권위를 같은 사람에게 184번 실어 나른 일이었다. 그래서 뉴스레터를 권위를 쌓는 장치가 아니라, 이미 한 번 접촉한 사람을 다시 만나는 장치로만 도입했다.
B2B 뉴스레터콜드메일 전환율B2B 마케팅랜딩 페이지 전환 - 2026-09-14자동화 목록 파일의 서비스 후보 스캔 항목 1줄 — 최근 30일 9회 × 건당 30분 = 4.5시간같은 목록의 이웃 작업 6줄 — 실행 주기·실행 횟수·셈법·건당 시간 분해 대조
자동화 절감 시간 계산 — 매일 도는 크론의 4.5시간은 무엇을 쟀나
자동화 절감 시간 계산에서 먼저 확인할 칸은 곱셈의 결과가 아니라 두 인수의 출처입니다. 매일 아침 외부 플랫폼 3곳을 훑는 크론 작업은 한 달 4.5시간을 아낀다고 적혀 있었지만, 그 값은 로그에서 센 실행 9회와 사람이 추정한 건당 30분을 곱한 결과였고, 작업이 실제로 무엇을 찾았는지는 계산에 들어 있지 않았습니다.
업무 자동화크론 잡절감 시간 계산자동화 효과 측정 - 2026-09-14자동화 효과 목록의 「리포트형 콘텐츠 1편 작성·발행」 항목 — 실행 일정 `20 8 * * *`, 최근 30일 실행 100회(셈법: 산출 마커), 사람 기준 건당 90분(근거 등급: 추정), 대체 시간 150.0시간같은 목록의 이웃 항목 6건 — 기술블로그 1편, 채용 사이트 공고 수집 3건, 리드 이메일 수집, 판매 서비스 후보 스캔의 실행 일정·실행 횟수·셈법·건당 시간 근거
리포트 자동 발행 크론 — 하루 1번인데 30일에 100회
리포트 자동 발행 크론에 적힌 최근 30일 실행 100회는 실행 횟수로 읽을 수 없는 숫자였습니다. 매일 오전 8시 20분에 한 번 도는 일정이라 30일 동안 30회가 상한인데, 자동화가 대신한 시간 150.0시간은 바로 이 100회에 건당 90분을 곱해 나왔습니다.
리포트 자동 발행크론 잡자동화 효과 측정실행 로그 - 2026-09-13자동화 대체 시간 목록의 브랜드 후보 발굴 항목 — 실행 일정 매일 새벽 3시(0 3 * * *) · 최근 30일 실행 8회(전용 로그) · 사람이 하면 건당 40분(검색·선별 30분 + 기록 10분) · 근거 등급 estimate · 대체 시간 5.3시간같은 목록의 리드 이메일 수집 항목과 칸별 대조 — 실행 일정 매일 새벽 2시 · 8회(전용 로그) · 건당 40분(대상 사이트 순회 30분 + 정리 10분) · estimate · 5.3시간
업무 자동화 효과 측정, 다른 두 작업의 건당 40분이 똑같았다
업무 자동화 효과를 적어 둔 목록에서, 새벽 3시에 도는 브랜드 후보 발굴 작업과 새벽 2시에 도는 리드 이메일 수집 작업은 일정과 근거 문장만 다를 뿐 실행 8회·건당 40분·대체 시간 5.3시간까지 칸마다 같은 값이었습니다. 두 줄이 같은 값을 쓰는 이유는 목록 어디에도 적혀 있지 않았습니다. 따라가 보니 더 큰 빈칸이 따로 있었는데, 브랜드 후보 발굴은 후보를 «고르는» 일인데도 5.3시간은 몇 번 돌았는지만 세고 고른 결과가 쓸 만했는지는 재지 않았습니다.
업무 자동화 효과업무 자동화크론데이터 검증품질 평가 - 2026-09-13자동화 대체 시간 목록의 리드 이메일 수집 항목 — 실행 일정 매일 새벽 2시(0 2 * * *) · 최근 30일 실행 8회(전용 로그) · 사람이 하면 건당 40분(대상 사이트 순회 30분 + 정리 10분) · 근거 등급 estimate · 대체 시간 5.3시간같은 목록의 이웃 항목 6개와 실행 일정·최근 30일 실행 횟수·셈법 대조 — 8회 다섯 줄(전용 로그 1 · 공용 로그 grep 4), 46회·101회 두 줄(산출 마커)
콜드메일 리드 이메일 수집 자동화, 매일 도는 작업이 30일에 8회였다
콜드메일 리드 이메일 수집 자동화가 아낀 시간은 저희 목록 파일에 한 달 5.3시간으로 적혀 있지만, 이 숫자를 이루는 세 값은 모두 아직 확인을 기다리는 상태였습니다. 매일 새벽 2시에 도는 작업인데 최근 30일 실행 기록은 8회였고, 건당 40분은 사람이 재 본 적 없는 추정이었으며, «한 건»이 무엇을 얼마나 처리하는지는 어디에도 적혀 있지 않았습니다.
콜드메일리드 수집업무 자동화크론데이터 검증 - 2026-09-13자동화 대체 시간 목록 2026년 9월 12일 집계 — 사람이 잰 값 0개 · 같은 형태 업무 실측치 0개 · 추정 16개(실행 246회, 283.3시간) · 미계측 17건 제외추정 등급 항목 6개의 계산 근거와 최근 30일 실행 횟수 대조 — 셈법 3종(산출 마커·공용 로그·전용 로그)
AI 업무 자동화 절감 시간, 283.3시간 중 실측은 0시간이었다
AI 업무 자동화로 아낀 시간을 2026년 9월 12일 기준으로 모두 더하면 283.3시간이지만, 그중 사람이 직접 재 본 값은 0시간이었습니다. 283.3시간은 16개 항목, 246회 실행분을 «계산 과정을 적은 추정»으로 쌓은 숫자였고, 잴 방법조차 없는 17건은 0으로 세지 않고 합계에서 뺐습니다. 합계 하나로 말하면 이 차이가 사라지기 때문에, 근거 등급을 네 칸으로 갈라 따로 적습니다.
AI 업무 자동화업무 자동화 효과근거 등급데이터 검증 - 2026-09-13활동량 경보 실측(2026년 9월 11일) — 경보 증가분 636건 vs 사람 커밋 증가분 422건저장소별 커밋 분해 — claude-os 979개 중 자동 동기화 커밋 947개 · threads-loop 523개 중 예약 수집 커밋 165개
git 커밋 수가 부풀려진 이유
git 커밋 수로 개발 활동량을 재던 스크립트가 켠 「커밋 +636」 경보는 자동 커밋이 부풀린 숫자였고, 사람이 만든 커밋만 다시 세면 422건이었습니다. 한 저장소는 커밋 979개 중 947개가 스크립트가 남긴 자동 동기화 커밋이었고, 코드 줄 수도 16%가 git이 추적하지 않는 파일에서 나왔습니다. 경보가 옳다는 가설부터 확인해 원인을 좁히고, 자동 커밋을 목록으로 막았다가 세 번째 자동 커밋을 만나 감지기로 바꾼 과정을 적었습니다.
git 커밋 수개발 활동량 계측자동 커밋git ls-files감시 스크립트 오탐 - 2026-09-12역할·결정 규칙 문서 1건(632줄) · 결정 이력 15건(2026년 5월 15일 합의)정정 표시가 붙은 결정 6건 vs 정정 없이 확정된 결정 9건 — 15건 전수 확인
AI 에이전트 역할 분담을 정한 기록
AI 에이전트 역할 분담을 문서 한 장으로 정리하면 끝날 줄 알았는데, 실제 결정 15건에 대입해 보니 6건을 그 자리에서 다시 고쳐야 했습니다. 여러 사업을 혼자 운영하면서 전략·운영·기술·제품을 맡을 여덟 개 역할을 나누고, 그 사이의 결정권을 처음으로 규칙에 못 박은 기록입니다. 표만 그려서는 부족했고, 정작 빠져 있던 건 결정 하나마다 번호와 받는 사람을 적어 두는 목록이었습니다.
AI 에이전트 역할 분담의사결정 큐다중 에이전트 조직권한 분류가설 반증 - 2026-09-12메모리 회수 정책 결정 기록(2026년 9월 2일) — 크론 164줄 중 유휴 5분 창을 만족한 관측은 48건 중 13건, 그마저 순간값이었다는 확인7일 관측 기록 재확인 — 실제 사용 메모리(anon) 최고치 11.39GB, 이전 내부 기록의 '최대 3.83GB'는 단면값으로 정정
vmmem 메모리 과다 점유 — 5분마다 자동으로 회수한 방법
vmmem 메모리 과다 점유는 상한을 고정한다고 해결되지 않았고, 오래 안 쓴 캐시만 골라 회수하는 방식으로 바꾸고 나서야 잡혔습니다. 저희는 처음에 메모리 상한(MemoryHigh)을 고정해 캐시를 묶어 두려 했는데, 그 기준으로 참고한 예전 기록의 '최대 3.83GB'가 실제로는 특정 순간의 단면이었고 7일 관측 최고치는 11.39GB였다는 사실이 뒤늦게 드러났습니다. 상한 대신 cgroup v2의 memory.reclaim 기능으로 오래된 캐시 페이지만 5분마다 자동으로 회수하도록 바꾸자 vmmem이 정상 범위로 돌아왔고, 회수한 캐시를 다시 읽는 비용까지 실측해 상시 실행이 안전하다는 근거를 확보했습니다.
vmmem 메모리WSL2cgroup리눅스 메모리 관리가설 반증 - 2026-09-12보안 규칙 문서 결정 이력 — 절약 실행 모드 호출부 3개와 외부 텍스트 처리 지점이 겹친 것을 확인, 방어 함수 4개 경계에 부착 (2026년 8월 9일)탐지 함수 호출부 전수 조사 — 위협 탐지 함수가 걸려 있던 자리는 읽기 경계 1곳뿐
프롬프트 인젝션 방어 — 규칙 꺼지는 자리와 공격 들어오는 자리가 겹쳤다
프롬프트 인젝션 방어 규칙이 정작 가장 위험한 자리에서만 꺼져 있었습니다. 비용을 아끼려고 쓴 절약 실행 모드가 회사 규칙과 점검 절차를 통째로 건너뛰는데, 이 모드를 쓰는 자동화 작업 3개가 하필 외부 웹 콘텐츠를 그대로 읽어 들이는 자리와 정확히 겹쳤습니다. 처음에는 위협 탐지 함수 자체를 의심했지만 그 함수는 결백했고, 진짜 문제는 함수가 걸려 있지 않은 자리였습니다.
프롬프트 인젝션AI 에이전트 보안자동화 크론가설 반증 - 2026-09-12결정 기록 1건(2026년 8월 11일) · 실행 로그 12일치 631회 주기사람 입력 로그 14일치 1,666건 — 수작업 구성 교차 확인
우선순위 큐 버그로 멈춘 자동화 엔진을 되살린 기록
우선순위 큐 버그가 자동화 엔진을 12일 동안 사실상 세워 뒀습니다. 631회 실행 주기 중 412건(65%)이 실행 없이 자동으로 멈췄고, 그중 380건은 사람의 결정 하나를 기다리다 막혔습니다. 처음에는 원인을 자율 판단의 한계로 봤지만, 실제로는 작업 목록을 읽는 정규식과 순위를 매기는 기준, 정지 범위를 설계한 방식에 있던 배선 결함 3개였습니다.
자동화 엔진우선순위 큐작업 스케줄러운영 지표 - 2026-09-11실측 — 최근 1개월 프롬프트 1,827건 중 세션 첫 지시의 68%가 100자 미만, 목적·판정 기준을 미리 적은 경우는 1.8%뿐반증된 가설 3건 — 사람 훈련, 값 하나씩 불러 주기, 제약을 말로 전달하기. 셋 다 그것만으로는 안 됐다
AI 프롬프트 작성법 — 지시가 짧아도 목적은 안 드러났다
AI 프롬프트 작성법이 부족했던 게 아니라, 실행 전에 확인해야 할 정보 세 가지가 통째로 빠져 있었다. 최근 1개월 프롬프트 1,827건을 세어 보니 세션 첫 지시의 68%가 100자 미만이었고, 목적이나 판정 기준을 미리 적어 둔 경우는 1.8%뿐이었다. 사람에게 더 자세히 쓰라고 요구하는 방법을 먼저 시도했지만, 실제 사고는 그 방법으로는 못 잡는 자리에서 났다.
AI 에이전트프롬프트 엔지니어링업무 자동화품질 관리AI 협업 - 2026-09-11종료 로그 신뢰 → 24건에서 수집 중단, 재실행 시 69스크롤·253건(10배)이웃 계정 대조 — 계정 B 1,832건/427일·계정 C 2,884건/425일, 각 3회 실행으로 전량 수집
무한 스크롤 크롤링, 종료 로그를 믿었더니 실제론 10배가 있었다
무한 스크롤 크롤링에서 수집 프로그램이 스스로 찍은 '바닥 도달'이라는 종료 로그를 그대로 믿었다가, 실제로는 열 배 넘는 게시물을 두고 온 사실을 뒤늦게 알았다. 특정 계정 하나가 24건에서 멈춘 것을 보고 '프로필 화면 스크롤로는 과거 글을 전부 가져올 수 없다'고 판정해 분석 보고서에까지 한계로 적었지만, 같은 시스템 안에 이미 400일 넘게 운영해 온 계정을 3회 만에 전량 수집한 사례가 두 건 있었다. 파라미터만 바꿔 다시 실행하자 253건이 나왔고, 스크롤 횟수 제한을 더 늘리자 1,902건까지 나왔다.
무한 스크롤 크롤링웹 스크래핑종료 조건 설계데이터 수집 검증 - 2026-09-11상품 후보 22건 전수 채점 · 기각선 12/18점 · 통과 0건채점 근거 3종 실측(도소매 순소득률·광고 최저 입찰가·소매 단가 관측률)
위탁판매 마진 계산 — 22건 전수 채점, 통과 0건
위탁판매 마진 계산을 광고비 최저가까지 넣어서 다시 하자, 팔 만하다고 여겼던 상품 22개 중 통과한 것이 하나도 없었다. 소비자에게 직접 파는 상품 후보를 기계로 전수 채점했더니 기각선 18점 만점에 12점을 넘은 건이 0건이었고, 최고점도 9점에 그쳤다. 원인은 상품이 나빠서가 아니라, 광고 없이는 팔리지 않는 시장에서 광고비를 감당할 마진이 안 나왔기 때문이었다.
위탁판매 마진 계산판매 상품 채점광고비 단가 검증수요 신호 파이프라인 - 2026-09-11증상 — 채무 분쟁 사안에서 복합 키워드 '가사채무 연대책임'으로 판례를 검색하자 결과가 0건, 비슷한 시기 법령 이름을 짧게 줄여 조회한 다른 경로에서는 '상법 제1조'가 전혀 다른 법의 조문(1980년해직공무원의보상등에관한특별조치법 제1조)으로 돌아왔다반증된 가설 — '이 사안엔 판례가 없다'와 '조회 도구 자체가 오류를 냈다'. 검색어를 '배우자 채무'로 쪼개 재조회하자 85건이 나왔고, 법령명을 정확히 일치시키는 별도 명령으로 재조회하자 조문이 정상적으로 반환됐다
AI 판례 검색 오류 — 0건이 '없다'는 뜻은 아니었다
AI 판례 검색 오류 하나가 실제로 있는 판례를 '없음'으로 잘못 결론지을 뻔한 일이 있었다. 채무 분쟁 사안에서 '가사채무 연대책임'이라는 복합 키워드로 판례를 검색했더니 결과가 0건이었고, 그 0건을 그대로 믿었다면 판례가 없다는 잘못된 진단이 그대로 나갈 뻔했다. 원인은 판례가 실제로 없어서가 아니라 검색어를 너무 복합적으로 넣은 데 있었고, 단어를 쪼개 '배우자 채무'로 다시 검색하자 같은 사안에서 85건이 나왔다.
법률 AI 진단판례 검색 정확도법령 인용 검증발송 전 전수 감사 - 2026-09-11자동 발송 후보 재측정 — 24시간 신선도 게이트 통과 20건 중 2건 → 실제 유효 20건 중 1건 (나머지 1건은 27일 된 글)원인 진단 — 상대 날짜 표기가 긁어 온 시점 기준으로 코퍼스에 고정되는 문제, 헤더 구간 한정으로 교정
크롤링 게시일 판별 오류 — 27일 된 글이 신규로 잡혔다
크롤링 게시일 판별 오류 하나가 27일 전에 올라온 글을 방금 올라온 글로 둔갑시켜, 24시간 신선도 게이트를 통과시키고 있었다. 스레드에서 잠재 고객 글을 찾아 답글 초안까지 준비하는 파이썬 프로그램을 만들다가 발견한 문제였고, 게이트를 통과한 후보 2건 가운데 1건이 이 오류가 만든 가짜 신규 글이었다. 원인은 '3일 전'처럼 상대적으로 적은 날짜 표기가 긁어 온 시점을 기준으로 코퍼스에 그대로 굳어 버린다는 데 있었다.
웹 크롤링날짜 파싱리드 자동화회귀 테스트스레드 자동화 - 2026-09-11실전 매매 대회 상위 랭커 1,015명 · 왕복매매 28,100건 분석가설 검정 3회 (순위-재랭크 상관 · 손익구조 대조 · 보유구간별 기여도)
생존자 편향 없이 비교한 손절 규칙, 승률 붕괴의 원인
실거래 승률이 55.6%에서 10.7%로 무너진 진짜 원인은 종목 선택이 아니라 손실 관리 방식에 있었습니다. 이 결론은 생존자 편향(살아남은 사례만 보고 판단해 실패 사례를 놓치는 오류)을 피하려고, 이미 한 번 이상 실전 매매 대회 상위권에 든 사람들끼리만 비교하는 방식으로 검증했습니다. 국내 한 증권사가 매달 발표하는 실전 매매 대회 상위 200명 데이터에서, 반복해서 상위권에 오르는 79명과 한 번만 오른 897명의 실제 매매 기록 28,100건을 비교한 결과입니다.
자동매매 전략생존자 편향손절 규칙퀀트 트레이딩 - 2026-09-09발행 79건 · 29일 감사반증 2회(수집 불가 메모 · 새벽 시간대 가설)
스레드 게시물 조회수 측정, 79건 동안 한 번도 재지 않았다
스레드 게시물 조회수를 측정할 방법이 자동 발행 프로그램 안에 아예 없었습니다. SGK 스튜디오가 스레드에 글 79건을 자동으로 올리는 29일 동안 좋아요는 거의 0에 머물렀는데, 그 글이 애초에 안 읽혀서 반응이 없는 것인지 읽혔는데도 반응이 없는 것인지 구분할 지표 자체가 없었습니다. 코드에는 '조회수는 원천적으로 수집할 수 없다'는 메모가 이미 적혀 있었고, 그 메모를 26일째 아무도 다시 열어 보지 않았습니다.
스레드 자동 발행조회수 측정SNS 지표 계측디버깅 - 2026-09-09데이터 보유 기간 — 1분봉은 2024년 4월 18일 이후분만, 5분봉은 2021년 4월~2026년 5월(2,689개 종목) 보유처음 잰 숫자 — 5분봉 5년(2021년 6월~2026년 5월) 백테스트, 필터 끈 기준선 −88%·강한 필터 −69%, 최대낙폭 −75%~−92%
5분봉 백테스트가 −69%로 무너진 이유, 원인은 레짐이 아니었다
5분봉 백테스트가 5년치 구간에서 −69%까지 무너진 원인은 시장 상황이 아니라 데이터 단위(타임프레임) 자체에 있었습니다. 자동매매 전략을 하락장·횡보장·상승장 여러 국면에서 검증하려던 개발자는 1분봉 데이터가 2024년 4월 18일 이후분만 남아 있다는 사실을 확인하고, 더 오래 남아 있는 5분봉(2021년 4월~2026년 5월, 2,689개 종목)으로 같은 검증을 시도했습니다. 그런데 이 5분봉 백테스트가 대참사에 가까운 손실을 내면서, 문제가 전략 자체인지 데이터 단위인지를 가리는 조사가 시작됐습니다.
5분봉 백테스트타임프레임 아티팩트퀀트 트레이딩자동매매 전략 검증 - 2026-09-09실측 표본 — 2026년 5월 13일~8월 24일 실거래 165건(급등 후 눌림목 매수 전략 97건 + 볼린저밴드 스퀴즈 전략 68건)처음 잰 숫자 — 청산 사유로 나누면 목표가 도달 익절 52건(승률 76.9%, +240.1%) 대 손절 계열 113건(−280.8%), 건당 순손실 −0.478%(왕복 비용 0.23% 반영), 누적 −40.9%
자동매매 청산 전략 실측, 적자에서 흑자로 뒤집힌 이유
자동매매 청산 전략을 실측한 결과, 문제는 매수 신호가 아니라 포지션을 정리하는 방식에 있었습니다. 급등 후 눌림목 매수 전략(SurgePullback)과 볼린저밴드 스퀴즈 전략(BBSqueeze)으로 2026년 5월 13일부터 8월 24일까지 쌓인 실거래 165건을 청산 사유별로 나눠 보니, 목표가 도달 익절 52건은 승률 76.9%로 240.1%를 벌었고 손절 계열 113건은 280.8%를 잃었습니다. 왕복 거래 비용 0.23%를 반영한 건당 기대수익은 −0.478%, 누적으로는 −40.9%였습니다.
자동매매 청산 전략퀀트 트레이딩백테스트손절 전략 - 2026-09-09기준선 스냅샷 — 2026년 8월 21일 개인 코드 저장소 42개 · 누적 커밋 5,608개 · 전체 코드 1,092,296줄재측정 — 18일 뒤인 9월 8일 저장소 45개(+3) · 커밋 7,305개(+1,697) · 코드 1,320,551줄(+228,255)
개발자 생산성 측정, 커밋 수만 늘어서는 안 보였다
개발자 생산성 측정은 커밋 수나 코드 줄 수를 세는 일로는 끝나지 않았습니다. SGK 스튜디오를 포함해 마흔 개가 넘는 코드 저장소를 혼자 운영하면서, 2026년 8월 21일과 9월 8일 두 시점에 저장소·커밋·코드 줄 수 그리고 업무 지침서·자동 검사 프로그램·자동 실행 스크립트 규모를 각각 재서 비교했습니다. 저장소는 42개에서 45개로, 커밋은 5,608개에서 7,305개로, 코드는 109만 줄에서 132만 줄로 늘었지만, 정작 가장 많이 늘어난 항목은 지침서가 아니라 자동 검사 프로그램이었습니다.
개발자 생산성 측정자동화 도구코드 자산 관리1인 개발 운영 - 2026-09-09첫 자체 시험 — 위반 문구를 심은 초안에서 15건 중 15건 전부 검출(2026년 9월 7일)반증된 가설 — '위반본만 통과시키면 검사 도구가 완성됐다'. 실제 발송 대기 초안·서식 3종을 같은 도구에 넣자 검출기 결함 3건(사실 식별번호 오인·부정 어미 누락·줄바꿈 부정 미검출)과 서식 실제 결함 2건이 나왔다
챗봇 상담 자동 검수, 위반만 잡으면 충분한 줄 알았다
챗봇 상담 자동 검수는 위반 문구를 잡아내는 검사만으로는 끝나지 않았고, 정상적으로 나갈 초안까지 같은 검사에 넣어봐야 검사 도구 자체의 결함이 드러났습니다. SGK 스튜디오는 카카오톡 채널 상담봇·접수봇 문의를 반복해서 받으면서 매번 공식 문서를 처음부터 다시 조사했고, 조사할 때마다 답이 조금씩 달라졌습니다. 위반을 심은 초안 15건을 전부 잡아내는 검사 도구를 만들고 나서 검수가 끝났다고 판단했지만, 실제로 발송 대기 중이던 정상 초안 한 건을 같은 도구에 넣어보니 그제서야 도구 자체의 결함이 나타났습니다.
카카오 챗봇 사실 검증발송 전 게이트자체 시험 이중 검증고객 서식 표준화 - 2026-09-09증상 — 발송량 정정(월 200건에서 500건 사이 → 400건에서 1,000건 사이)을 한 번 반영한 제안서에서, 3개월 램프업 표의 2개월차 칸만 예전 값(주 100건에서 150건)으로 남아 월 최대 645건에 그쳤다. 같은 문서의 목표(월 800건에서 1,000건)에는 못 미쳤다반증된 가설 — '요약 문단 숫자를 고치면 문서 전체가 맞아떨어진다'. 실제로는 같은 목표 값이 요약 문단과 램프업 표 두 곳에 따로 적혀 있었고, 처음 정정 때도 이번 재검토 전까지 표 쪽은 손대지 않은 채 남아 있었다
AI 제안서 검수 — 고친 숫자가 표에는 남아 있었다
AI 제안서 검수는 한 번 고친 숫자를 다시 확인하는 일까지 포함해야 끝난다. 리걸테크 스타트업 고객사에게 보낼 아웃바운드 영업 제안서에서 발송량 숫자가 틀렸던 것을 한 번 고쳤는데, 문서 안의 다른 표에는 그 수정이 반영되지 않은 채 남아 있었다. 서로 다른 관점을 가진 AI 에이전트 네 개를 병렬로 돌려 같은 문서를 다시 훑게 한 뒤에야 그 사실이 드러났다.
제안서 수치 검증AI 에이전트 교차검증문서 정합성발송 계획 재계산 - 2026-09-08증상 — 해외 5개국 광고 메일 규제를 정리한 회신 초안에서 3개국이 틀렸다. 태국 「UEMA(스팸메일법)」는 존재하지 않는 법, 아랍에미리트 「연방법 5/2012」는 번호는 실재하나 사이버범죄법, 사우디 「위반 결정 48건」은 대형 로펌 공개 해설과 정면 충돌반증된 가설 — 「검색을 덜 해서 났다」. 회신을 고쳐 쓰는 라운드마다 나라별 검색은 이미 돌고 있었고, 오히려 자료가 귀한 나라일수록 더 많이 돌린 상태에서 5개국 중 3개국이 틀렸다
AI 법령 인용 검증 — 5개국 중 3개국이 없는 법이었다
AI 법령 인용 검증을 검색 횟수로 대신하면 존재하지 않는 법이 고객 메일에 그대로 실린다. 해외 다섯 나라의 광고 메일 규제를 정리한 회신 초안에서 세 나라가 틀렸다. 태국은 아예 없는 법 이름이었고, 아랍에미리트는 번호는 실재하지만 광고 메일과 무관한 사이버범죄법이었고, 사우디는 대형 로펌 공개 해설과 정면으로 어긋나는 숫자였다. 세 건의 근거는 전부 규제 준수 도구 판매사의 블로그와 검색 결과 요약이었다.
법령 인용 검증AI 사실 확인회신 문서 파이프라인해외 규제 - 2026-09-08대상 전수 확인 — 제목 앞부분이 같은 29편을 한 편씩 열어 각 편이 노리는 검색어를 대조관측 수단 — 28일 치 검색 성과 리포트(편별 노출·클릭·평균 순위), 편별 발행일과 21일 잠복 기준 대조
canonical 태그 통합 대상 29편 — 실제로 묶은 건 4편이었다
canonical 태그로 묶을 대상을 「제목이 같은 말로 시작한다」는 조건으로 세면 29편이 걸립니다. 그 29편을 한 편씩 열자 성격이 다른 셋이 섞여 있었습니다. 이미 평균 3.7위로 검색 결과 첫 화면에 올라간 글 1편, 「병원홈페이지제작」처럼 다른 검색어를 노리는 업종별 글 5편, 발행한 지 21일이 안 돼 성과를 판정할 데이터 자체가 없는 글 19편입니다. 남은 4편만 묶었고, 그 4편은 전부 28일 노출 2 이하에 클릭 0건이었습니다.
SEO콘텐츠 운영검색 색인 - 2026-09-08처음 잰 숫자 — 30일 네이버 354,265원(246클릭)·구글 136,294원(19클릭), 합계 490,559원에 상담 신청 2건(7월 13일·7월 22일)·계약 0건. 최근 7일은 357,060원에 상담 0건관측 수단 — 채널 리포트 소진·클릭 원자료, 방문자 행동 계측의 상담 신청 이벤트(유입 채널·날짜 포함), 설정 파일과 라이브 상태 대조 명령, 구글 노출 손실 지표 교차조회
검색광고 전환율 9.8%는 남의 숫자였다 — 실측은 0.75%
검색광고 전환율을 남의 평균값으로 두면 감당 못 할 키워드에 계속 입찰하게 된다. 30일 동안 490,559원을 써서 265클릭을 사고 상담 신청 2건·계약 0건이 나온 뒤에야, 우리 계산기에 들어 있던 9.8%가 업계 벤치마크였고 자체 실측은 0.75%라는 사실을 확인했다. 처음 의심한 광고 설정 결함은 알리바이가 있었다.
검색광고전환율 측정업계 벤치마크가설 반증광고 자동화 - 2026-09-08처음 잰 숫자 — 검색어 3개(홈페이지제작업체·AI 업무자동화·AI 챗봇 제작)의 상위 3건씩 9건 본문이 1,966~4,296자·중앙 3,299자. 우리 원고는 1,033자측정 방법 — 공개 검색 API가 아니라 실제 검색 결과 화면 직접 수집(HTTP 200). 본문은 스마트에디터 본문 영역의 문단만 세고, 표 행·링크 줄·머리기호는 양쪽 모두 제외
네이버 블로그 글자수 — 요약형 원고 47편은 발행해도 소용이 없었다
네이버 블로그 글자수를 재고 나서, 발행 준비를 마쳤다고 부르던 원고 47편이 사실은 발행해도 아무 일이 일어나지 않는 상태였음을 확인했다. 우리가 노리는 검색어의 상위 노출 글 9건은 본문이 중앙 3,299자였고, 우리 원고는 1,033자로 상위 하한 1,966자의 절반을 겨우 넘었다. 새 원고를 한 편도 쓰지 않고 형식만 바꿔 중앙 2,101자까지 올린 기록이다.
네이버 블로그검색 노출콘텐츠 파이프라인가설 반증측정 방법 - 2026-09-08처음 잰 숫자 — 서비스 소개 글 89편 전체가 구글 서치 콘솔 28일 노출 82건·클릭 2건. 같은 기간 세무 정보 글 12편은 202건으로 편당 16.8건반증된 가설 — 같은 대표 검색어를 노린 18편의 SEO 카니발라이제이션. 페이지×검색어로 다시 뽑으니 월 2,840회짜리 목표 검색어에서 노출 0건, 보이는 유일한 홈페이지 검색어는 52위 하나였다
SEO 카니발라이제이션 — 18편이 순위를 나눠 먹는다는 진단이 틀렸다
SEO 카니발라이제이션을 원인으로 지목했다가 집행 직전에 되돌렸다. 서비스 소개 글 89편의 28일 노출은 82건, 클릭은 2건이었고 같은 기간 세무 정보 글 12편은 202건으로 편당 16.8건이었다. 격차의 원인을 '같은 검색어를 노린 18편이 서로 순위를 갉아먹는다'로 봤는데, 검색어별로 다시 뽑아 보니 노리던 검색어에서 노출이 0건이었다. 나눠 먹으려면 일단 그 자리에 나타나야 한다.
SEO 카니발라이제이션구글 서치 콘솔콘텐츠 파이프라인가설 반증 - 2026-09-07처음 잰 숫자 — 하루치 후보 14건 중 13건이 질문 내용과 무관, 답변 초안까지 간 선정 0건, 대기 큐 3건, 그때까지 누적 수집 631건반증된 가설 — 후보 공급량이 부족하다는 가설. 앞서 키워드를 13개에서 21개로 늘리고 씨앗 검색어를 13개에서 34개로 늘려 원자료 수확을 5,978건에서 7,935건까지 올렸지만 실제 후보 순증은 +1이었다. 정렬만 관련도순으로 바꿔 조회하니 관련도가 3/10에서 10/10으로 뒤집혔고 미사용 후보가 1,414건 쌓여 있었다
네이버 검색 API 정렬 — 수집은 되는데 쓸 후보가 0건이었던 이유
네이버 검색 API 정렬 옵션 하나가 답변 후보 선정 0건의 원인이었다. 같은 키워드를 최신순으로 조회하면 10건 중 3건만 질문과 관련이 있었는데, 관련도순으로 바꾸자 10건 중 10건이 관련 질문이었다. 손도 대지 않은 후보가 1,414건 쌓여 있었고, 그때까지 누적 수집한 631건의 2.2배였다.
네이버 검색 API정렬 옵션콘텐츠 파이프라인병목 인수분해 - 2026-09-07같은 문구로 나간 669통 실측 — 클릭 27건(4.2%), 그 클릭에서 넘어온 문의 0건. 30일 창으로 다시 잘라도 열람 410건·클릭 128건·문의 0건반증된 가설 — 링크와 클릭 계측이 고장 났다는 가설. 링크 주소를 전부 교체하고 클릭 계측 세 경로를 정정하고 조회 신호를 새로 붙인 뒤에도 뒷단 숫자는 그대로였고, 8월 13일 퍼널에서는 클릭 24건 중 7건이 진단 화면까지 실제로 들어갔다
콜드메일 회신율 — 클릭 27건, 문의 0건의 진짜 원인
콜드메일 회신율을 막고 있던 범인은 링크도 계측도 아니었다. 한 통이 받는 사람에게 정정과 클릭과 회신을 동시에 요구하고 있었고, 그중 가장 부담 없는 클릭만 남았다. 같은 문구로 669통을 보내 클릭 27건(4.2%)이 나왔지만 그 클릭에서 넘어온 문의는 0건이다.
콜드메일회신율퍼널 계측A/B 대조군 - 2026-09-07새 재료 창구 실측 — 후보 3건 적립, 해당 축 산출물 0편, 라이브 9편은 AI 에이전트 운영 6·검색 노출 진단 1·코드 이력 위생 1·테스트 도구 디버깅 1반증된 가설 — 재료 부족으로 품질 관문 탈락. 실제 탈락 사유는 연도 표기(괄호 형태 대 년 표기)였고 생성기가 기간 한 줄을 같이 내자 20건 중 6건에서 20건 전부 통과
콘텐츠 자동화 파이프라인 0편 — 소재는 3건 쌓여 있었다
콘텐츠 자동화 파이프라인이 한 편도 못 낸 원인은 재료 부족이 아니라 파일 경로 표기와 점수 정렬 두 가지였다. 글감을 모으는 쪽에는 새 후보가 3건 쌓여 있었지만 그 후보를 꺼내 읽는 쪽은 경로를 열 수조차 없었고, 열렸더라도 본문 길이에 걸린 30점 때문에 126점에서 128점짜리 기존 후보를 이길 수 없었다. 그래서 라이브 9편이 전부 한 축에서 나왔다.
콘텐츠 파이프라인자동화 디버깅점수 정렬 편향무음 실패 감지 - 2026-09-07사고 당시 로그 파일 직접 확인 — 집에서 회사로 보내는 백업이 2026년 8월 7일부터 4일·45회 연속 실패, 30분마다 중단 문구 기록같은 기간 감시 스크립트 출력 — 판정 「정상 · 0.1시간 전 갱신」
크론 실패 감지 — 감시기가 4일 내내 정상이라고 말했다
「크론 실패 감지」를 로그 갱신 시각으로만 하면, 실패하는 작업일수록 더 건강해 보입니다. 집에서 회사로 작업 파일을 밀어 넣는 백업이 2026년 8월 7일부터 4일 동안 45회 연속 실패했는데, 그 기간 내내 감시 스크립트 판정은 「정상 · 0.1시간 전 갱신」이었습니다. 30분마다 실패하면서 실패했다고 로그에 적었으니 파일은 계속 새것이었기 때문입니다. 이 글은 그 구멍을 메운 과정과, 같은 종류의 구멍을 반복해 찾아내는 절차를 검사 축 아홉 개·절차 일곱 단계로 고정한 기록입니다.
크론모니터링운영 자동화장애 감지 - 2026-09-07원본 저장소 전수 대조 — 수집기는 7월 23일부터 원글 주소를 100% 담고 있었다주제별 원글 주소 보유율 — 감시용 경로만 훑는 주제 4개 0%, 전체 주제 경로만 훑는 주제 100%, 두 경로가 겹치는 주제 3개 96~97%
웹 스크래핑 URL 누락 — 범인은 하나가 아니라 셋이었다
「웹 스크래핑 URL 누락」의 원인은 수집기가 아니었습니다. 수집기는 7월 23일부터 원글 주소를 100% 담고 있었고, 주소가 사라진 자리는 그 뒤쪽 세 군데였습니다. 처음 잰 숫자는 후보 20건 중 자동 심사 통과 0건이었고, 세 군데를 다 막고 나서 2건이 됐습니다. 한 군데만 고쳤다면 숫자는 그대로였을 겁니다.
웹 스크래핑데이터 파이프라인파이썬 - 2026-09-06발행 글 전수 대조 — 68건 중 64건(94퍼센트)에 기술 어휘 0개, 어휘 검사기 실제 반려 2회짝짓기 부호검정 라이브 재실행 43,049건 — 기술 어휘 축 1,078개 짝에서 516건 대 522건, 개발 계정 18곳 14,563건 표본에서 729개 짝 355건 대 355건
AI 글쓰기 전문성이 안 나온 이유 — 검사기가 아니라 재료였다
「AI 글쓰기 전문성」이 안 살아난 원인은 검사기가 아니라 재료였습니다. 자동으로 써서 올린 글 68건 가운데 64건, 그러니까 94퍼센트에 기술 어휘가 한 개도 없었습니다. 처음에는 출력 단계의 어휘 검사기가 전문 용어를 반려한다고 봤지만, 로그를 열자 실제 반려는 2회뿐이었습니다. 그 가설이 깨진 자리에서 발행 68건의 출처를 다시 세어 보니 결정 기록 32건·측정 기록 26건·자산 문서 7건·원고 3건이었고, 코드에서 온 재료는 0건이었습니다.
AI 콘텐츠 자동화프롬프트 설계파이썬 - 2026-09-06자동 요약 리포트 8개 파일 전수 검색 — 해당 섹션 출력 0건 (2026년 7월 21일 추가 이후 3주간)분류 함수 단독 실행 실측 — 7건 매칭, 최고 점수 14.1, 5개 분야 중 볼륨 3위
설정 추가했는데 반영 안 됨 — 하드코딩 사본이 3주간 감춘 리포트 섹션
「설정 추가했는데 반영 안 됨」의 원인은 설정을 읽는 쪽이 아니라 결과를 내보내는 쪽이었습니다. 2026년 7월 21일에 분야 하나를 설정 파일에 넣었는데 그 뒤 3주 넘게 자동 리포트 8개 파일 어디에도 해당 섹션이 없었습니다. 우리가 처음 세운 가설은 「그 분야는 시장에 신호가 없다」였고, 분류 함수만 따로 돌려 보자 7건이 잡히며 그 가설이 깨졌습니다. 분류는 설정 파일을 그대로 훑는데 출력은 이름 5개를 손으로 적어 둔 사본을 보고 있었습니다.
설정 관리파이썬자동화 파이프라인 - 2026-09-06반려된 사내 질의서 1건 실측 — 세션 맥락 누출 14건 · 기계 말투 13건 · 가독성 결함 8건작성 규칙 문서 1건(6개 절) · 발송 전 검사 명령 1개 · 개정 이력 2건 (2026년 8월 19일 신설, 8월 21일 게이트 통합)
AI 문서 작성 규칙 — 사내 문서 지적 35건을 세 축으로 갈랐다
AI 문서 작성 규칙에서 가장 크게 잡힌 결함은 문장력이 아니라 맥락이었습니다. AI가 대신 쓴 사내 질의서 한 건을 세 개 축으로 갈라 세어 보니 작업 대화 내용이 그대로 새어 나간 자리가 14건, 기계 말투가 13건, 가독성 결함이 8건이었습니다. 우리가 처음 세운 처방은 문장을 다듬는 쪽이었고, 그 처방으로는 가장 큰 축이 한 건도 줄지 않았습니다. 지적을 항목별로 세고 상한을 정한 다음, 발송 전 검사를 명령 하나로 묶기까지의 기록입니다.
문서 작성AI 에이전트한국어 문체 - 2026-09-06스레드 원글 42,661건 · 작성자 8,344명 — 같은 작성자·같은 수집 경로·길이 ±25% 매칭쌍 검정 (우리 계정 제외)일곱 유형 판정 — 핫이슈 짝 1,745개 · 번호·불릿 리스트 921개 · 정보 전수형 1,198개 · 수익 인증 823개 · 주장 단정 1,468개 · 경험담 평문 4,773개 · 실패·자백 529개
스레드 바이럴 유형 실측 — 실패담은 오히려 지는 쪽이었다
스레드 바이럴을 만드는 유형은 실패담도 경험담 평문도 아니었다. 스레드 원글 42,661건·작성자 8,344명을 같은 작성자·같은 수집 경로·길이 ±25% 안에서 짝지어 재니, 우리가 절반씩 쓰던 두 유형은 짝을 이겼다고 말할 근거가 없었고 실패·자백은 짝에서 지는 쪽이 더 많았다(234대 257). 우리 발행분 53건을 같은 자로 재 보니 실패·자백이 41.5%로, 코퍼스 비중 1.8%의 23배였다.
스레드콘텐츠 자동화코퍼스 분석매칭쌍 검정SNS 마케팅 - 2026-09-06참고 계정 카드 24개 전수 열람 (팔로워 상위 두 계정 · 2026년 8월 29일) — 텍스트만으로 된 카드 0개, 이미지 영역 60~70% · 텍스트 밴드 30~40%한국어 공개 게시글 코퍼스 22,648건 전문 스캔 (그 안의 프롬프트 블록 24,959개) — 도구 언급 글 수 실측: 미드저니 842건 · Canva 763건 · Figma 385건 · Nano Banana 273건 · Photoshop 106건
AI 이미지 생성 글자 깨짐 — 원인은 도구가 아니라 층 구분이었다
AI 이미지 생성 글자 깨짐의 원인은 모델이 한글을 못 써서가 아니라, 카드 한 장을 통째로 한 도구에 맡긴 데 있었다. SGK 스튜디오는 카드뉴스와 썸네일, 상세페이지 같은 산출물을 AI 에이전트 팀이 나눠 만드는 파이프라인으로 찍어내는데, 글자가 이미지에 얹히는 순간 결과가 두 방향으로 갈라졌다. 참고로 삼은 계정들의 카드 24개를 전부 열어 세어 보니 텍스트만으로 된 카드는 0개였고, 그 숫자 하나에 '전부 브라우저 렌더로 만들면 품질에서 앞선다'던 1차 판정이 무너졌다.
AI 이미지 생성카드뉴스 자동화콘텐츠 파이프라인AI 에이전트한글 조판 - 2026-09-05손절 값 재확인 사례 — 같은 질문에 -1.5%와 -2.5%로 답이 갈렸고(961번째 질문에서는 R=7%와 R≈2.5%로도 갈림), 인용된 파일 경로·줄 번호는 실재했으나 확인한 층이 하나뿐이었다값 결정 구조 실측 — 전략 기본값·초기화 재정의·검증 실행기 재정의·상한 고정까지 4개 층이 순서대로 값을 덮어쓰고 있었다
AI 에이전트 확인 없이 답변, 같은 값을 물을 때마다 달랐다
AI 에이전트 확인 없이 답변은 겉보기엔 사실 같았다. 자동매매 전략 코드의 손절 설정값을 물었더니 답이 매번 달랐다 — 어떤 때는 -1.5%, 어떤 때는 -2.5%였다. 처음엔 에이전트가 아예 확인을 안 하고 찍어서 말한다고 의심했다. 그런데 실제 기록을 열어 보니 파일 경로가 붙은 진짜 근거가 있었다. 근거를 댔는데도 왜 계속 틀렸는지, 그 답을 어떻게 고쳤는지를 순서대로 적는다.
AI 에이전트 검증할루시네이션 방지자동매매 코드 확인근거 기반 답변 - 2026-09-05시작 쪽 확인 절차 실측 — 제품 무게별 압축 비율 5%·15%·30%, 표준 산출물 10개, 위협 점검 최소 5분, 시간 예산 3일·2주·4주, 설계 문서 1장으로 재작업 80% 감소그만두는 쪽 확인 절차 부재로 발생한 사고 1건 — 계정 위임 경로가 없다는 판단이 나온 날 안에 상품 폐기와 고객 통지가 함께 나감
서비스 종료 결정 기준, 시작할 때만 있고 접을 때는 없었다
서비스 종료 결정 기준은 시작할 때만 있었고 그만둘 때는 없었다는 데 있었다. SGK 스튜디오는 새 판매 상품을 시작하기 전에 수요와 허용 여부를 확인하는 절차를 AI 에이전트에게 맡기고 있었는데, 이미 하던 서비스를 그만두는 결정에는 같은 확인 절차가 전혀 없었다. 판매 상품 하나가 근거를 다시 볼 시간도 없이 발견한 날 그만두기로 결정되고 고객 통지까지 나간 뒤에야, 조사 품질이 아니라 절차 자체의 무게가 한쪽으로만 쏠려 있었다는 사실이 드러났다.
AI 에이전트 의사결정서비스 종료 절차프로젝트 라이프사이클허용성 판단 - 2026-09-052025년 번역체 연구 대조 — naturalness를 명시한 프롬프트 조건에서 오류가 줄지 않고 늘었고, 생성 후 다듬기 패스를 추가하자 번역체 비율이 43%에서 25%로 떨어졌다이력서 재판정 실측(2026년 8월 22일) — 정본 docx와 렌더링한 중간 결과가 단어 수 기준으로 정확히 일치했고, 강한 위반 15건짜리 검증 문서는 훅이 그 자리에서 막았다
AI 번역체 자동 검사, 고치라고 시켰더니 더 심해졌다
AI 번역체 자동 검사를 만든 이유는 한 문장으로 설명된다 — 모델에게 자연스럽게 쓰라고 프롬프트에 적어 넣는 방법은 효과가 없었고, 오히려 번역체를 늘렸다. SGK 스튜디오는 AI 에이전트가 만든 한국어 문서를 고객과 거래처에 그대로 내보내다가, 문장 속에 영어 문형을 그대로 옮긴 표현이 섞여 나가는 문제를 발견했다. 처음에는 프롬프트에 '자연스럽게'라는 말 한마디만 더하면 될 것 같았지만, 실제로 프롬프트 조건별 번역체 비율을 잰 연구를 대조하자 정반대 결과가 나왔다. 그래서 생성 지시를 강화하는 대신, 다 쓴 결과만 따로 검사하고 고치는 별도 패스로 설계를 완전히 바꿨다.
번역체 검사AI 문서 자동화Claude Code 훅한국어 자연성 검사 - 2026-09-05다섯 단계 확인 절차의 앞 네 단계 실측 — 업종별 부가가치율(자동차 소매 7.5%~법무회계상담 67.3%), 재능마켓 유효 상품 2,000개 중 1,957건 수집해 가격대별 매출 88배 차이 확인, 넓은 키워드 25,250원 대 구체적 키워드 4,270원(20배 검색량 차이), 병원 블로그 1,582개 중 97.9% 활성·방치 0.6%다섯 번째 단계(허용성 확인)에서 발생한 오판 1건 — 설정 화면에 위임 기능이 안 보인다는 이유로 '공식 경로 없음' 판정, 실제로는 단체용 계정 종류에 위임 기능이 있었음
AI 에이전트 오판, 원인은 계정 레이어 확인 누락이었다
AI 에이전트 오판은 설정 화면 하나만 보고 '공식 경로가 없다'고 결론 내릴 때 일어났습니다. 블로그 계정을 대신 관리할 방법을 찾다가 화면에 그 기능이 안 보인다는 이유만으로 '위임 경로 자체가 없다'고 판단해 판매 상품 하나를 접었는데, 실제로는 계정 종류를 하나 더 확인했어야 했습니다. 이 판단이 어디서 갈렸는지, 확인 수단을 어떻게 다시 검증했는지, 같은 실수를 막으려고 어떤 절차를 새로 세웠는지를 정리했습니다.
AI 에이전트시장 조사 자동화허용성 판단확증 편향 - 2026-09-05스킬 재사용률 첫 측정(2026년 6월 14일) — 승격 17개 / 후보 47개(승격률 27%), 재사용률 24%(4/17), 스크립트 백엔드 4개, 진짜 미사용 9개다른 회사(2026년 4월 자체 발표) 자율성 지표 — 자동 승인율 약 40%, 개입율 약 9%, 세션당 개입 5.4회→3.3회(3개월), 처리 시간 25분→45분(3개월)
AI 에이전트 스킬 재사용률 24%, 원인은 회수 배선 부재였다
AI 에이전트 스킬 재사용률을 처음 재보니 승격해 둔 스킬 17개 중 실제로 다시 불려 쓰인 것은 4개, 24%뿐이었습니다. 이 회사는 사람이 에이전트 작업에 얼마나 개입하는지, 실패에서 얼마나 스스로 회복하는지 같은 자율성 지표를 다섯 가지로 정의해 두고 있었는데, 실제로 첫 측정까지 마친 것은 이 하나뿐이었습니다. 정식으로 등록했으니 자연히 다시 쓰일 거라 짐작했던 가정이 왜 빗나갔는지, 원인을 찾아 손을 본 뒤에도 왜 아직 다시 재지 못했는지를 그대로 적었습니다.
AI 에이전트 자동화스킬 재사용률자율성 측정Claude Code - 2026-09-04두물머리투자자문 Associate, Operations & Growth 재직 2020년 2월~2022년 5월 (2년 4개월) · 로보어드바이저 앱 '불릴레오' + 증권사 자문 서비스 '불리오' 운영·그로스 담당자문계약 고객 4,300명+ 규모 · Zendesk 기반 VoC 시스템 팀 내 도입
구글플레이 평점 개선, 4.0점을 4.7점으로 올린 기록
구글플레이 평점 개선은 별점 대응이 아니라 고객 목소리를 모으는 시스템을 다시 짜는 일이었습니다. 두물머리투자자문에서 로보어드바이저 앱 '불릴레오'를 운영하며 마주한 Google Play 평점은 4.0점이었고, 자문계약 고객 4,300명이 넘는 규모에서는 개별 상담만으로 이 숫자가 움직이지 않았습니다. Zendesk 기반 VoC 시스템으로 고객 목소리를 체계적으로 모은 뒤에야 평점은 4.7점으로, 계좌 개설 시도율은 2.44배로 올랐습니다. 이 글은 그 사이에 세운 가설과 틀린 지점, 그리고 같은 원리가 지금 소프트웨어 품질 규칙으로 어떻게 코드화됐는지를 적은 기록입니다.
그로스VoC고객 피드백앱 평점품질 측정 - 2026-09-042026-09-03 기준 등록 크론 168개 전수 분류 — 업무대체 70·감시 45·보고 35·위생 17·미분류 1업무대체 70개 중 최근 30일 실행 기록 대조 — 실행 0회 27개, 로그 형식 상이로 집계 불가 34개
크론 168개, 시간 절감 측정법이 따로 있었다
크론(정해진 시각마다 자동으로 실행되는 작업) 168개를 전부 자동화라고 부르면 숫자가 부풀고, 시간 절감 측정법은 크론의 성격별로 따로 있어야 한다는 사실이 실제로 세어 보고서야 드러났습니다. 사람이 하던 일을 대신하는 크론과, 사람이 원래 안 하던 일을 감시하는 크론, 손이 아니라 판단만 앞당기는 크론은 같은 방식으로 셀 수 없습니다. 168개 중 시간 절감을 말할 자격은 업무대체 70개에만 있었고, 그중에서도 비교 기준을 갖춘 것은 3개였습니다. 그 3개를 직접 열어 실행 횟수와 사람이 같은 일을 했을 때 걸리는 시간을 다시 잰 기록을 남깁니다.
업무 자동화크론 관리시간 절감 측정데이터 검증 - 2026-09-04손으로 발급한 인수인계 문서 실측 — 한 저장소에서 발급 4회 중 보관(아카이브) 성공 1회, 2026년 8월 31일 확인아홉 칸 골격으로 쓴 인수인계 문서 실증 — 다른 프로젝트에서 이 골격으로 쓴 문서가 판정 축 5개 중 5개(만점)를 받고, 실제 세션이 재질문 0회로 완주
AI 에이전트 인수인계 자동화, 손으로 하면 4번 중 3번 깨졌다
AI 에이전트 인수인계 자동화를 손으로 하면 넷 중 셋이 깨진다는 사실을 실제 사고로 확인했습니다. SGK 스튜디오가 AI 에이전트에게 업무를 맡기고 세션이 끝날 때마다 다음 세션에게 넘기는 인계 문서를 손으로 발급했더니, 파일 이름이 하나뿐이라 새 인계 문서가 저장되는 순간 아직 쓰이지 않은 직전 인계 문서를 덮어썼습니다. 원인은 사람의 부주의가 아니라 파일 하나에 여러 축을 겹쳐 쓰게 만든 설계였고, 이 사실을 확인한 뒤 손으로 쓰는 절차를 명령 하나로 바꿨습니다.
AI 에이전트 자동화세션 인계 문서업무 자동화 설계Claude Code - 2026-09-04두 수집 프로그램(메타 수집·자막 수집) 동시 실행 재현 — 2026년 8월 31일, 병행 시작부터 차단까지 걸린 시간 측정채널 전수 자막 수집 2단계 전략 실측 — 2026년 8월 31일 519편 채널 기준, 좁혀서 빠르게 도는 1차와 넓혀서 회수하는 2차의 처리 방식·성공률 대조
유튜브 자동 수집 IP 차단, 원인은 새 스크립트 하나였다
유튜브 자동 수집 IP 차단은 스크립트 하나의 실수가 아니라, 프로그램마다 요청 속도를 알아서 절제하게 둔 설계 자체의 문제였습니다. SGK 스튜디오는 유튜브 영상을 자막과 화면으로 훑어 요약하는 자동화 프로그램을 여러 개 운영하는데, 이 프로그램들이 같은 컴퓨터의 인터넷 주소를 함께 쓰다 보니 하나가 짧은 시간에 지나치게 자주 요청을 보내면 유튜브가 그 주소 전체를 막아 다른 프로그램의 수집까지 함께 멈췄습니다. 채널을 대량으로 자막까지 훑는 프로그램과, 감시할 채널을 스스로 찾아내는 새 프로그램에서 원인은 서로 달랐지만 결과는 같았습니다 — 공용 관문을 프로그램마다 알아서 통과하게 두면 언젠가 하나는 그 관문을 빠뜨린다는 것이었습니다.
유튜브 데이터 수집요청 한도 제어자동화 스크립트 설계yt-dlp - 2026-09-04네이버 블로그 자동 발행 표 변환 결함 조사 — 2026년 6월 15일 발견, 그날 함께 나온 결함 3건 중 세 번째가 표 변환 실패여러 줄 선택 실패 원인 확인 — 명령을 한 줄씩 나눠 반복 실행할 때와 한 번에 묶어 실행할 때의 결과 대조
브라우저 자동화 표 삽입 실패, 원인은 클릭 순서였다
브라우저 자동화 표 삽입 실패의 진짜 원인은 화면이 아니라 명령을 쪼개어 보내는 방식에 있었습니다. 저희는 네이버 블로그에 글을 자동으로 올리는 프로그램으로 표가 든 글을 발행하다가, 마크다운 표가 편집창에서 표로 바뀌지 않고 텍스트 그대로 남는 일을 반복해서 만났습니다. 화면 좌표를 다시 재고 클릭 위치를 몇 번이나 고쳐도 결과는 같았습니다. 원인을 찾고 보니 문제는 좌표가 아니라, 마우스와 키보드를 흉내 내는 명령 하나하나가 서로 완전히 독립된 프로그램 실행이라는 점이었습니다 — 키를 누른 채 유지해야 하는 동작이 명령과 명령 사이에서 풀려 버리고 있었습니다.
브라우저 자동화UI 자동화 디버깅네이버 블로그 자동 발행자동화 도구 설계 - 2026-09-04SGK 스튜디오 자동화 크론 168개 전수 분류(2026-09-03 기준) — 업무대체 70개·감시 45개·보고 35개·위생 17개·미분류 1개업무대체 70개 중 최근 30일 실행 기록 대조 — 실행 0회 27개, 로그 형식 상이로 집계 불가 34개, 비교 기준을 갖춘 것 3개
업무 자동화 효과 측정, 크론 168개 중 70개만 셈에 넣었다
업무 자동화 효과 측정은 크론 개수를 그대로 더하는 일이 아니라 그 개수 중 무엇을 셀 자격이 있는지 가르는 일이었습니다. SGK 스튜디오가 2026년 9월 3일 기준으로 등록해 둔 크론은 168개였고, 이 숫자를 그대로 '168개를 자동화했다'고 쓰면 절반 가까이가 다른 이야기를 하고 있었습니다. 168개를 성격별로 나누자 업무대체 70개, 감시 45개, 보고 35개, 위생 17개, 미분류 1개로 갈렸고, 시간 절감을 말할 자격이 있는 것은 업무대체 70개뿐이었습니다. 그 70개 중에서도 비교 기준을 갖춘 것은 3개였고, 이 글은 그 3개를 실측해 합산한 128.9시간이 왜 아직 추정으로만 남아 있는지 적은 기록입니다.
업무 자동화크론 관리성과 측정근거 등급 - 2026-09-04퀀팃 / 퀀팃투자자문 Manager, Business Operation / Compliance 재직 2022년 5월~2024년 8월, 2025년 1월~현재(합산 약 4년) · 금융투자 광고 컴플라이언스 자동 검토 시스템 운영검토 룰 베이스 10배 이상(수백 개 규모) 확장 · PDF·PPTX·이미지(Vision) 페이지 단위 전수 대조 · 계측 구간 2026년 5월 5일~7월 24일, 작업일 18일·파일 112건
LLM 비용 절감, 토큰 427K를 104K로 줄인 기록
LLM 비용 절감은 모델을 바꾸는 일이 아니라 프롬프트에 무엇을 넣을지 다시 정하는 일이었습니다. 퀀팃투자자문의 금융투자 광고 컴플라이언스 자동 검토 시스템은 심사 룰 베이스를 수백 개 규모로 10배 이상 넓히면서, 매 건 심사마다 그 룰 전체를 LLM에 통째로 넣고 있었습니다. 이 방식이 입력 토큰 427K짜리 요청을 만들었습니다. 광고 콘텐츠 한 건에 실제로 걸리는 룰만 경량 모델이 먼저 골라 넣는 RAG 라우터를 넣은 뒤, 같은 방식으로 다시 재니 입력 토큰은 104K로, 총 비용은 54% 줄었습니다. 이 글은 그 사이에 세운 가설과 틀린 지점, 골든 케이스 24개로 회귀를 감시한 과정을 적은 기록입니다.
LLM 비용RAG컴플라이언스 자동화토큰 최적화회귀 테스트 - 2026-09-03저장소 1개 (전자책 원고 5권 + 마케팅 자산) · 정리 커밋 1건 (2026-07-02)정리 전 git status 571줄 · 정리 후 한 자릿수 · 무시 대상 PNG 450장 · 추적 해제 상태 파일 4개
git status 정리, 파일 571개를 한 자릿수로 줄인 기록
git status 정리는 무시 규칙을 몇 줄 보태는 일이 아니라 저장소가 무엇을 추적해야 하는지 다시 정하는 일이었습니다. 이미지와 초안을 스크립트가 매일 만들어 떨어뜨리는 저장소에서 git status가 571줄을 뱉었고, 임시 파일과 렌더 출력을 무시하는 규칙을 두 번 넣었는데도 노이즈는 줄지 않았습니다. 2026년 7월 2일 커밋에서 생성 산출물 폴더를 무시하고 cron이 고쳐 쓰는 상태 파일 4개를 추적에서 빼자 571줄이 한 자릿수로 내려갔습니다. 이 글은 왜 앞의 두 조치가 틀렸는지, 두 종류의 노이즈가 어떻게 다른지, 그리고 무엇이 끝내 줄지 않았는지의 기록입니다.
git.gitignore콘텐츠 자동화cron - 2026-09-03협업 규칙 문서 1건 (2026-07-19 추출 · 2026-07-30 개정) · 실제 사고 1건 (2026-07-25)규칙이 정한 상수 — 사람 접점 2번 · 단계 6개 · 표준 섹션 10개 · 검토자 5명 · 확신도 앵커 5단 · 라운드 상한 3
AI 에이전트 스펙 검증, 설계서를 새 세션이 못 찾은 이유
AI 에이전트 스펙 검증이 놓친 자리는 스펙의 내용이 아니라 스펙으로 가는 길이었습니다. 2026년 7월 25일 설계서 작성을 마치고 '한 줄만 치면 구현이 시작된다'고 안내했는데, 새로 연 세션은 그 한 줄로 설계서를 찾지 못했습니다. 처음에는 규칙이 가리키는 대로 스펙이 부실하다고 의심했고, 그 가설은 명령 두 줄의 결과 앞에서 무너졌습니다. 이 글은 그 진단이 어디서 틀렸고 무엇을 고쳤는지, 그리고 같은 종류의 실수를 스펙 검토 단계에서 어떻게 막기로 했는지의 기록입니다.
Claude Code스펙 기반 개발에이전트 자율 실행교차검증 - 2026-09-03장시간 자율 실행 규칙 문서 1건 · 결정 이력 4건 (2026-04-29 ~ 2026-06-04) · 개정 커밋 1건 (2026년 33~34주차 신호 반영)체크포인트 트리거 3개 · Effort 등급 3개 · 컨텍스트 등급 3개의 상수값
AI 에이전트 체크포인트, 2시간에서 30~40분으로
AI 에이전트 체크포인트 간격을 2시간으로 잡은 규칙은 첫 판부터 늦은 경계였고, 외부 실측을 들여오자 30~40분 세그먼트로 내려갔습니다. 같은 규칙에서 첫 사이클 안전장치로 넣은 60초 대기도 실측 뒤 0초로 줄일 수 있다는 줄이 붙었습니다. 안전은 멈춰서 묻는 데서 오지 않았고, 표류를 막는 목표 낭독과 기계 검증, 그리고 사이클마다 남기는 커밋에서 왔습니다. 그 규칙을 2026년 4월 29일부터 8월까지 고쳐 쓴 전후를 그대로 적습니다.
에이전트 하네스자율 실행체크포인트 - 2026-09-03계측 기간 21일 · 사람 발화 3,161턴 · 세션 기록 10,855파일훅 배선 규칙 문서 1건 · 결정 이력 4건 (2026-08-23 ~ 2026-08-27)
Claude Code hooks 오탐 — 설명 요청을 작업으로 읽은 앵커 한 글자
Claude Code hooks 오탐의 원인은 정규식 첫머리 앵커 한 글자였습니다. 세션 첫 지시에서 에이전트가 한 번만 일하고 멈추는 증상을 잡으려고 훅을 배선한 다음 날, '조금 더 쉽게 설명해줘'라는 설명 요청을 훅이 작업 지시로 읽었습니다. 고친 뒤 세션 첫 프롬프트 1,123건을 다시 돌리니 작업 아님 판정이 55건에서 59건으로 늘고 나머지 수치는 그대로였습니다. 그 훅이 왜 있어야 했는지, 첫 진단이 어디서 틀렸는지부터 순서대로 적습니다.
Claude Codehooks에이전트 자율 실행정규식 오탐 - 2026-09-03세션 종료 절차 문서 1건 (2026-07-24 ~ 2026-09-02 수정 이력)30개 저장소 소급 유실 감사 1회 (2026-08-09) · 번호 재정리 기록 1건 (2026-08-14)
Claude Code 병렬 세션의 기록 유실 12건을 0건으로
Claude Code 병렬 세션이 공유 문서를 서로 지우던 문제는 락이 아니라 '통째 다시 쓰기'라는 구조를 바꾸자 멈췄습니다. 30개 저장소 소급 감사에서 영구 유실 12건은 전부 가드 배선 이전이었고, 배선 이후는 0건입니다. 반면 번호 충돌은 락을 걸고도 3건이 더 났고, 발급기를 만든 뒤에도 경로 하나 때문에 한 번 더 겹쳤습니다.
에이전트 하네스병렬 세션기록 유실 - 2026-09-02규칙 문서 1건 · 결정 이력 8건 (2026-04-23 ~ 2026-08-13)1번 게이트 판정표 18행 · 훅 3종의 상수값
AI 에이전트 승인 게이트를 4개로 줄인 기록
AI 에이전트 승인 게이트를 늘릴수록 안전해지지 않았고, 사람이 답을 받아 적는 시간만 늘었습니다. 게이트를 4개로 끊고 나머지를 전부 자율로 내린 뒤 규칙 문서에 남은 결정 이력은 8건이고, 그 가운데 두 번은 우리 가설이 정면으로 반증된 기록입니다. 승인 프롬프트가 안전을 만든다는 전제부터 틀렸습니다.
에이전트 하네스자율 실행승인 게이트 - 2026-09-01서비스 직결 글 88편·검색량 155키워드 대조가설 재판정 1회·죽은 계측 2건 복구
SEO 콘텐츠 88편의 노출이 안 붙은 원인
SEO 콘텐츠 노출을 늘리려고 발행량을 키우는 동안, 판매 서비스로 이어지는 글의 편당 노출은 2.6에서 0.9로 오히려 떨어졌습니다. 처음 지목한 원인은 같은 키워드에 열여섯 편이 쌓인 콘텐츠 중복이었지만, 155개 키워드의 검색량과 광고 입찰가를 다시 대조하고서야 그건 2차 요인이었다는 것이 드러났습니다. 진짜 원인과, 그 과정에서 함께 발견한 두 번의 죽은 계측을 그대로 적습니다.
SEO 콘텐츠데이터 검증계측 - 2026-09-01테스트 5,638건오진 2회·반증 2회
pytest ERROR 1,300건은 버그가 아니었다
pytest ERROR 가 1,289건 나왔습니다. 코드를 한 줄도 안 고치고 다시 돌리니 1,516건, 한 번 더 돌리니 2,173건이었습니다. 처음 지목한 범인은 알리바이가 있었고, 진짜 원인은 코드가 아니라 코드를 재는 도구 안에 있었습니다.
디버깅테스트 자동화품질 검증 - 2026-09-01계측 기간 21일사람 발화 3,161턴
Claude Code 자율 실행은 왜 한 턴 만에 멈추나
Claude Code 자율 실행은 같은 도구, 같은 모델인데 어떤 세션은 도구를 190번 쓰고 끝까지 가고 어떤 세션은 1번 쓰고 멈춥니다. 원인이 프롬프트 길이라고 생각했습니다. 21일치 3,161턴을 세어 보니 절반만 맞았고, 틀린 절반이 처방을 통째로 바꿨습니다.
AI 에이전트업무자동화계측