만들어 돌려 보고, 숫자로 확인한 것.
AI 에이전트와 업무자동화를 실제로 운영하면서 측정한 것을 적습니다. 잘된 것만 고르지 않고, 숫자가 저희 가정을 뒤집은 지점도 그대로 남깁니다.
지식인 자동 답변, 하루 상한보다 질문 공급원이 먼저였다
지식인 자동 답변의 채택률을 올리려면 답변 문장이나 하루 발행량보다 먼저 질문을 어디서 가져오는지를 바꿔야 했습니다. 저희 답변이 붙은 질문은 작성된 지 중앙값 141일이 지난 글이었고 채택률은 2.8%였는데, 같은 시장에서 당일 질문에 단 답변은 27.0%가 채택을 받았습니다. 2026년 9월 15일에 공급원을 바꾸고 첫 사이클을 돌렸더니 초안 3건이 모두 품질 검사에서 떨어졌고, 수리 뒤에야 2건이 통과했습니다.
개발 생산성 지표, 저장소 수와 커밋 수가 부풀려지는 자리
개발 생산성 지표는 숫자가 커질수록 세는 단위부터 의심해야 합니다. 2026년 8월 21일과 10월 23일을 나란히 놓자 저장소는 42개에서 59개로, 사람이 한 커밋은 4,612개에서 8,308개로 늘었습니다. 그런데 늘어난 저장소 17개를 한 줄씩 열어 보니 같은 코드 5,065줄을 두 번 센 한 쌍과 15줄짜리 시험 저장소가 섞여 있었고, 코드 줄 수 1,824,798줄은 기준선과 세는 방식이 달라 비교할 수 없었습니다.
B2B 뉴스레터, 권위를 쌓는다는 가설이 틀렸다: 184통 전수 분석
B2B 뉴스레터는 권위를 만드는 장치가 아니라, 이미 한 번 만난 사람에게 같은 이름을 다시 닿게 하는 통로였습니다. 본보기로 삼은 회계법인의 뉴스레터는 한 통의 본문 텍스트가 130자였고, 발송 100통을 목적별로 나누면 37%가 콘텐츠가 아니었습니다. 그래서 뉴스레터를 새 원고·새 구독자 없이, 우리 메일을 이미 열어 본 사람에게 두 번째 접촉을 만드는 용도로만 들이기로 했습니다.
콜드메일 클릭 913건에 방문 18명, 권위 부족이 원인이 아니었다
콜드메일로 리드가 안 나오던 이유는 회사 권위가 아니라 열어 본 사람이 사이트까지 오지 못하는 구간에 있었습니다. 30일 동안 16,268통을 보내 913건의 클릭을 얻었는데 사이트 실방문은 18명, 클릭 대비 0.6%였습니다. 이 구간을 그대로 두면 발송을 늘리든 뉴스레터를 새로 만들든 같은 비율로 사람이 사라집니다.
지식인 하루 답변 한도, 7건을 10건으로 올린 첫날 초안 3건이 전부 버려졌다
지식인 하루 답변 한도를 7건에서 10건으로 올리는 것만으로는 채택이 늘지 않고, 질문을 가져오는 곳을 바꾸고 네이버 등급 상한을 코드가 직접 읽게 해야 한다는 결론에 이르렀습니다. 저희 자동 답변이 붙은 질문은 작성된 지 중앙값 141일이 지난 글이었고, 같은 시장에서 당일 질문에 단 답변은 27.0%가 채택을 받았습니다. 2026년 9월 15일에 당일 질문만 받는 두 번째 발행 경로를 열었는데, 첫 사이클에서 만든 초안 3건은 하나도 품질 검사를 넘지 못했습니다.
견적 할인 요청 23%, 범위를 줄이는 답이 틀렸던 이유
견적 할인 요청에 범위를 줄여서 답하는 방법은 이 건에서 틀렸습니다. 노무법인 고객이 홈페이지 견적 390만 원을 300만 원으로 맞춰 달라고 했을 때 저희는 세 가지 답을 세웠지만, 고객이 이미 한 말과 대조하자 셋 다 깨졌습니다. 최종 견적은 가격을 받고 범위를 고객이 말한 데까지만 잠그는 쪽으로 정했습니다.
홈페이지리뉴얼 메뉴 개편, 드롭다운 5개를 4개로 줄이고 남은 것
홈페이지리뉴얼에서 메뉴가 복잡하다면 카드를 더 붙이기보다 분류 축을 먼저 바꿔야 했고, 저희는 그 결과 상단 드롭다운을 5개에서 4개로 줄였습니다. 처음 떠오른 안은 기존 구조를 그대로 두고 서비스 카드만 늘리는 방법이었습니다. 그런데 그 안은 같은 서비스를 두 갈래로 보여 주는 중복 구조를 만들었고, 진짜 문제는 회사 조직도를 메뉴로 옮겨 놓은 데 있었습니다.
광고대행 수익구조, 가격표보다 동시 수주 상한 8곳을 먼저 잰 이유
광고대행 수익구조를 정할 때 먼저 잴 것은 가격표가 아니라 동시에 받을 수 있는 광고주 수였고, 저희의 그 상한은 8곳이었습니다. 처음에는 월 39만·79만·149만 원 세 단계 중 무엇으로 몇 곳을 받아야 목표 매출에 닿는지를 물었습니다. 그런데 협약서 한 조항과 광고주 34곳을 센 결과가 질문을 “8곳으로 얼마까지 갈 수 있는가”로 바꿔 놓았습니다.
검색광고 키워드 선정, 감으로 고른 18종 중 9종은 노출 0이었다
검색광고 키워드 선정에서 먼저 잴 것은 "이 말을 사람들이 치는가"와 "우리 예산으로 이 말에 광고가 걸리는가" 두 가지였습니다. 감으로 등록한 키워드 18종 가운데 9종은 월검색량이 10에도 못 미쳐, 입찰을 아무리 해도 노출이 거의 생길 수 없었습니다. 등록 전에 API로 검색량·최소 입찰가·검색 의도·예산 상한을 차례로 재는 5단계를 만들고 나서야, 수요 가설에서 구글 키워드 11개 집행까지 한 번에 갔습니다. 이 글은 그 과정에서 세운 가설, 틀린 지점, 다시 잰 결과를 순서대로 적은 기록입니다.
광고대행 가격 책정, 3티어 가격표보다 동시 수주 8곳이 먼저였다
광고대행 가격 책정에서 먼저 답할 질문은 “얼마를 받나”가 아니라 “동시에 몇 곳까지 받을 수 있나”였습니다. 처음에는 월 39만·79만·149만 원 3티어 가격표를 두고 승인을 기다렸는데, 그 승인은 이틀 가까이 나지 않았습니다. 동시 수주 상한이 8곳이라는 숫자를 세고 나서야 세 가지 수익 구조 가운데 둘이 목표에 닿지 못한다는 사실이 보였습니다. 이 글은 처음 세운 가설, 그 가설이 틀린 지점, 다시 잰 결과를 순서대로 남긴 기록입니다.
구글 광고 입찰가 상한 2,500원, 홈페이지제작 키워드 13개가 전부 꺼진 이유
구글 광고 입찰가 상한을 일예산에서 거꾸로 계산하지 않고 감으로 정하면, 광고는 켜 둔 것처럼 보여도 실제로는 한 번도 경매에 나가지 못합니다. 저희는 입찰가 상한 2,500원 아래에서 홈페이지제작 키워드 13개를 전부 꺼진 상태로 두고 있었고, 시장이 요구하는 입찰가는 5,740원에서 29,180원 사이였습니다. 2026년 7월 21일 구글 일예산을 5,000원에서 30,000원으로, 입찰가 상한을 15,000원으로 올렸고, 그 과정에서 처음 세운 원인 진단 하나가 틀렸다는 사실도 확인했습니다.
RPA로 외주 공고 수집 자동화, 하루 2회를 2시간 간격으로
RPA로 외주 공고 수집을 자동화해도 계약을 막는 것은 공고 수가 아니라 납품 시간이었습니다. 적합 공고는 월 36건이었지만 기준 공고는 1,000만 원에 441시간, 시간당 2.3만 원짜리 일이었고 월 1,000만 원 목표에는 9.3만 원이 필요했습니다. 수집 주기를 2시간 간격으로 줄인 첫날에는 예약 실행이 0회였습니다.
앵커 텍스트 SEO 진단, 내부링크 69편이 같은 문구였다
앵커 텍스트를 세어 보니 내부링크는 없던 게 아니라 69편이 모두 같은 문구를 달고 있었습니다. 홈페이지 제작을 의뢰하려는 사람이 치는 구글 검색어 6개에서 28일 동안 노출이 1회뿐이었고, 저희는 처음에 글이 모자라거나 내부링크가 없어서라고 봤습니다. 첫 가설은 공개 글 39편과 초안 43편이라는 숫자에 기각됐고, 두 번째 가설은 절반만 맞았습니다.
홈페이지제작업체 SEO canonical 통합, 29편 중 4편만 합친 이유
홈페이지제작업체 검색어를 두고 쌓인 글을 대표 글 하나로 모으는 작업에서, 처음 잡힌 대상 29편 가운데 실제로 합쳐야 할 글은 4편뿐이었습니다. 제목이 같은 말로 시작한다는 기준 하나가 성격이 전혀 다른 글 세 부류를 한 묶음으로 만들고 있었습니다. 이 글은 “29편 전부 합치면 된다”는 첫 판단과 “성과가 가장 좋은 글을 대표로 세우면 된다”는 두 번째 판단이 각각 어떻게 무너졌는지 순서대로 남긴 기록입니다.
홈페이지제작업체 검색광고 전환율, 업계 평균 9.8%를 믿었다가 생긴 일
홈페이지제작업체 검색광고에서 리드가 안 나온 원인은 입찰 배선이 아니라 전환율 가정 하나였습니다. 키워드마다 “클릭 하나에 얼마까지 써도 되는가”를 계산하는 공식에 업계 평균 전환율 9.8%가 들어 있었고, 우리 데이터로 다시 재 보니 0.75%였습니다. 13배 부풀린 숫자 하나가 감당할 수 없는 키워드 9종에 광고비를 쓰게 만들고 있었습니다. 이 글은 처음에 엉뚱한 곳을 의심한 과정과 그 의심이 왜 틀렸는지까지 그대로 남긴 기록입니다.
숨고 스마트견적으로 자동 견적, 입찰 봇을 직접 만들지 않은 이유
숨고 스마트견적을 쓰기로 한 결론부터 말하면, 견적을 못 보내던 원인은 자동화가 없어서가 아니라 견적을 보낼 캐시가 0이었기 때문입니다. 저희는 처음에 알림을 모아 직접 입찰하는 프로그램을 만들 생각이었지만, 요청이 1시간 안에 사라지고 알림이 카카오톡으로만 온다는 사실 앞에서 그 계획을 접었습니다. 대신 19,900원짜리 첫 출발 이벤트로 500,000캐시를 받고, 숨고 안에 이미 있는 자동 견적 기능을 켜는 쪽으로 방향을 틀었습니다.
HTML 프로토타입 한 장, 요구사항 문서보다 먼저 보낸 이유
HTML 프로토타입 한 장을 요구사항 문서보다 먼저 보내는 절차를 만들었고, 형식 기준은 기준 예시 3.6KB로 통과했지만 고객 회신이 늘었는지는 아직 재지 못했습니다. 글로 되묻던 방식의 출발점 숫자가 없다는 점도 그대로 적습니다.
기술 검토서 작성, CTO 독자 점수는 문장이 아니라 증거에서 멈췄다
기술 검토서 작성에서 CTO 독자 점수를 막은 원인은 문장이 아니라 증거였습니다. 문장을 고친 4라운드는 7·6·6에서 멈췄고, 점수가 크게 움직인 때는 문서의 주어를 고객이 받을 시스템으로 바꾸고 그 과업의 시제품을 먼저 돌린 뒤였습니다. 다만 마지막 새 독자 점수는 5·5·4로, 목표 6점에는 아직 닿지 못했습니다.
교란 변수 찾기: 주식 진입 시간대 적자의 진짜 원인은 밤을 넘긴 거래
진입 시간대가 수익을 가른다는 결론은 틀렸고, 교란 변수는 거래가 밤을 넘겼는지 여부였습니다. 10시대와 11시대 진입은 누적 −25.3%와 −27.3%로 적자였지만, 같은 표에 다음 날 정리한 거래의 비율을 붙이자 그 비율이 9시대 8.7%에서 10시대 31.7%, 11시대 40.0%로 적자와 나란히 올라갔습니다. 이 글은 “그 시간대를 막자”는 가설을 세웠다가 버린 과정과, 같은 표에서 하나 더 틀린 가설을 그대로 남긴 기록입니다.
크롤러 세션 만료 추세, 표본 2개로 내린 판정이 하루 만에 뒤집혔다
크롤러 세션 만료가 짧아지는 추세라는 판정은 틀렸습니다. 로그인 두 번이 각각 55분·137분 만에 끊긴 것을 보고 추세를 적었는데, 바로 다음 날 같은 수집기가 158건을 모으는 동안 거부를 한 줄도 남기지 않았습니다. 이 글은 그 판정을 세운 과정, 반증이 4일 동안 묻혀 있던 이유, 그리고 아직 풀지 못한 진짜 질문까지 그대로 남긴 기록입니다.
멀티 에이전트 토론, 반박은 페르소나가 아니라 증거에서 나왔다
멀티 에이전트 토론에서 의견이 갈라지게 만드는 것은 에이전트마다 붙인 페르소나가 아니라 각자 서로 다른 증거를 직접 열어 보는 구조였습니다. 저희 토론방 29턴을 다시 세어 보니 반박은 7번(24%)뿐이었고, 그중 가장 선명한 반박은 페르소나 덕분이 아니라 그 턴이 파일을 직접 열었기 때문에 나왔습니다. 이 글은 “페르소나를 다르게 주면 집단지성이 생긴다”는 가설이 어떻게 무너졌고, 무엇으로 바꿨고, 바꾼 뒤에도 무엇이 안 풀렸는지를 순서대로 남긴 기록입니다.
SNS 포스팅 자동화, Claude Code로 하루 검토 80분을 10분 목표로
SNS 포스팅 자동화에서 줄여야 했던 것은 발행 버튼을 누르는 시간이 아니라 매일 글감을 고르고 사실을 대조하는 사람의 검토 시간이었고, 저희는 이 시간을 하루 50~80분에서 5~10분으로 줄이기로 목표를 잡았습니다. 출발점은 스스로 정한 주 2시간 상한을 이미 넘어 주 6~9시간을 쓰고 있다는 계산이었습니다. 이 글은 그 계산과 설계, 기각한 대안, 그리고 아직 실측으로 닫지 못한 부분까지 그대로 남긴 기록입니다.
Claude Code 맥락 유지: 세션이 끝나도 남는 문서 4개 구조
Claude Code 맥락 유지는 모델의 기억력이 아니라 저장 스키마로 풀어야 했습니다. 저희는 세션이 끝나면 사라지는 대화 대신, 프로젝트 폴더 안에 살아 있는 문서 4개를 두고 그 위에 전역 메모리와 선택형 지식 그래프를 얹었습니다. 그래도 2026-08-09 감사에서 완료라고 적힌 5,357줄 중 기계로 확인할 수 있는 줄은 71줄, 1.33%뿐이었고, 그래서 지금은 쓰는 순간에 막는 검사를 붙여 두었습니다.
업무 자동화 ROI 계산, 구축 4~6시간이 4~7일에 회수되는 조건
업무 자동화 ROI는 구축 4~6시간을 들여 주 5~8시간을 돌려받으면 4~7일 만에 회수된다는 계산으로 시작했지만, 실제로 효과를 가르는 변수는 시간이 아니라 AI가 글 속 사실을 대조하는 정확도였습니다. 출발점은 주 2시간으로 정해 둔 상한을 넘어 주 6~9시간을 쓰고 있다는 첫 합산이었습니다. 이 글은 그 계산과 숨은 전제, 반증된 가정, 그리고 아직 채우지 못한 재측정 칸까지 남긴 기록입니다.
FAQPage 구조화 데이터 전에 본문부터: 얇은 페이지 367개 보강기
FAQPage 구조화 데이터를 붙이기 전에 먼저 해야 했던 일은 본문을 두껍게 만드는 일이었고, 저희는 데이터 템플릿만으로 자동 생성 페이지 367개의 고유 텍스트 중앙값을 338자에서 1,429자로 올렸습니다. 출발점은 페이지가 367개나 있으니 검색 기반은 이미 있다는 가정이었는데, 재 보니 500자를 넘는 페이지가 0개였습니다. 이 글은 그 측정과 보강, 그리고 아직 증명하지 못한 부분까지 숫자 그대로 적은 기록입니다.
AI 에이전트 검증 자동화, 스크립트 210개가 712개 될 때
AI 에이전트 검증 자동화의 핵심은 검사기를 똑똑하게 만드는 일이 아니라, 검수량이 제품 수에 비례하는 구조를 끊는 일이었습니다. 처음에는 검사기가 통과시키면 믿는다는 가설로 시작했지만, 고정 임계는 노이즈와 0.04%p 차이였고 정상 입력 5건만 넣은 검사기에서 거짓 통과 4건이 나왔습니다. 이 글은 그 가설이 틀린 지점과, 사람 판정을 저장하는 구조로 바꾼 뒤 다시 잰 숫자를 적은 기록입니다.
Claude Code 병렬 세션이 작업 목록을 지운 이유, 잠금으로 안 막혔다
Claude Code 병렬 세션이 작업 목록을 지운 원인은 동시에 쓰는 충돌이 아니라, 목록을 매번 통째로 다시 쓰는 구조였습니다. 잠금을 걸면 해결된다고 보고 잠금부터 넣었지만, 잠금 도입 사흘 뒤부터 같은 번호가 두 결정에 붙는 충돌이 3건 더 나왔습니다. 이 글은 그 가설이 무너진 지점과, 문장으로 적어 둔 규칙을 명령과 커밋 검사로 바꾼 뒤 다시 잰 숫자를 그대로 적은 기록입니다.
본인인증 자동화 실패 원인, 화면 문구가 아니라 숨은 입력칸이었다
본인인증 자동화가 멈춘 진짜 원인은 화면 문구가 아니라 숨은 입력칸과 브라우저 상태였고, 그걸 고치자 문자 인증이 121초 만에 사람 손 없이 끝났습니다. 정부24 간편인증은 카카오·PASS·토스·삼성패스 네 곳이 같은 코드로 거절했고, 화면은 인증서가 없다고 말했습니다. 인증서는 있었습니다.
AI업무자동화 어디까지 맡기나, 4회 연속 성공률 20.6%
AI업무자동화를 사람 손 없이 길게 맡기려면, 한 번 성공률이 아니라 여러 번 연속 성공률과 80% 성공 기준 작업 길이를 봐야 합니다. 같은 과제를 한 번 시켰을 때 37.4%였던 성공률이 4회 연속 성공을 요구하자 20.6%로 내려갔고, 실제 유료 업무를 자동화하는 측정에서는 최고 기록이 21.25%였습니다. 이 글은 “AI에게 몇 시간짜리 일을 혼자 맡겨도 되나”라는 질문에 답하려다 처음 세운 가설이 어디서 틀렸는지, 그래서 무엇을 바꿨는지를 순서대로 적습니다.
내부 링크 SEO, 관련 글 목록 101개를 6개로 줄인 이유
내부 링크 SEO에서 글 하단의 관련 글 목록은 많이 걸수록 손해였습니다. 우리 사이트는 낱개 글마다 자기를 뺀 101편을 전부 나열하고 있었고, 이 구조를 관련 글 6편과 전체 목록 허브 1개로 바꾸자 빌드한 102편 전수에서 글 사이 링크가 최대 7개로 내려왔습니다. 처음엔 화면이 지저분한 문제로 봤지만, 실제로는 모든 글이 모든 글을 가리켜 사이트 구조가 평평해진 문제였습니다.
이미지 원본 다운로드 크롤러, 썸네일만 받던 원인은 작업 단위였다
이미지 원본 다운로드가 썸네일에서 멈춘 원인은 사이트마다 다른 주소 규칙이 아니라, 수집기가 ‘페이지’를 작업 단위로 삼은 구조였습니다. 단위를 ‘이미지 하나’로 바꾸자 같은 주소에서 safebooru는 250px에서 2048px로, 위키백과는 500px에서 1436px로 올라갔습니다. 바꾸기 전에도 단위테스트 82건은 전부 통과하고 있었습니다.
개발 외주 제안서, 주어를 바꾸자 CTO 독자 점수가 5점에서 6점으로
개발 외주 제안서의 점수를 올린 것은 문장 다듬기가 아니라 문서의 주어를 바꾼 일이었습니다. 기술을 아는 독자 역할로 채점하자 첫 판들은 10점 만점에 5점 근처에 머물렀고, 고객이 받을 시스템을 주어로 장을 새로 짠 일곱 번째 판에서 5→6→6점으로 올랐습니다. 다만 그 뒤로 다른 과업에서도 6점을 넘지 못했고, 남은 감점은 문장이 아니라 계약 조건과 실적 같은 증거 쪽에 있었습니다.
광고대행 수수료 조사에서 «판정 불가»를 «원정»으로 센 오류를 바로잡은 기록
광고대행 수수료 조사에서 결론을 죽인 전제 두 개는 사실 조사 도구의 읽기 실수였고, 9월 17일 재조사로 «김포 치과 5곳 중 1곳»은 10곳 중 7곳으로, «공개 사례 0건»은 원문 4건(광고비의 10~14%)으로 바뀌었습니다. 결정 세 건의 결론은 그대로 두고 근거만 교체했습니다.
홈페이지 제작 견적 490만 원을 290만 원으로 낮춘 과정
홈페이지 제작 견적을 490만 원에서 290만 원으로 내린 이유는 단가 인하가 아니라 범위 축소였습니다. 같은 지역 최고가 295만 원의 1.66배였던 처음 견적에서 고객이 요청하지 않은 항목과 월 20달러 운영비를 빼고, 요청한 4가지만 남겼습니다.
콜드메일 아닌 문의 메일 자동 회신, 알림 메일을 원천으로 삼은 구축기
콜드메일처럼 먼저 보내는 영업과 달리 들어온 문의는 회신 속도가 곧 신뢰인데, 챗봇·폼 문의는 알림에서 멈춰 있었습니다. 결론부터 적으면 실주소와 원문이 남는 자사 알림 메일을 원천으로 삼아, 회신 초안·소개서 첨부 후보·2차 명령까지 한 번에 만들고 발송만 사람 승인으로 남겼습니다. 30일 치 알림 48건 중 실제 고객 문의가 4건이었고, 이 4건이 전부 사람 손에서 처리되던 구조를 바꾼 과정과 운영 첫날 드러난 구멍까지 순서대로 적습니다.
숨고 스마트견적 캐시 충전 기준, 보너스 기간엔 5개 전부 켠 이유
숨고 스마트견적 캐시 충전 기준은 두 줄로 정했습니다. 보너스 50만 캐시가 있는 동안은 서비스 5개를 전부 켜고, 현금 충전은 실측 승률이 손익분기를 넘은 서비스에만 허용합니다. 손해 확률이 54%인 서비스를 끄면 오히려 20일 동안 거래가 한 건도 없을 확률이 51%로 올라가서, 끄지 않기로 했습니다.
숨고 스마트견적으로 견적 자동화, 자체 입찰 파이프라인을 버린 이유
숨고 스마트견적을 쓰기로 한 결론부터 적습니다. 견적 자동화를 막던 병목은 발송 속도가 아니라 보유 캐시 0이었고, 19,900원 이벤트 결제로 잔액을 500,000캐시로 올린 뒤에는 직접 만든 파이프라인보다 숨고 안에서 도는 자동 견적이 빠르고 쌌습니다. 처음에는 알림을 모아 직접 입찰하는 프로그램을 만들 생각이었고, 그 가설이 어디서 틀렸는지를 순서대로 남깁니다.
AI업무자동화 외주 공고 채점, 키워드 대신 시간당 수령액으로
AI업무자동화로 외주 공고를 고를 때 병목은 공고 수가 아니라 납품 시간이었습니다. 적합 공고는 월 36건이었지만, 기준 공고 한 건은 1,000만 원에 441시간이 드는 시간당 2.3만 원짜리 일이었고 월 1,000만 원 목표에 필요한 단가는 9.3만 원이었습니다. 저희는 채점 기준을 시간당 실수령으로 바꾸고 수집을 2시간 간격으로 늘렸는데, 다음 날 예약 실행이 0회였다는 사실을 발견했습니다.
AI자동화 견적 발송, 약관 위반 링크 5건: 규칙은 이미 있었다
AI자동화로 견적 메시지를 만들 때 규칙을 문서에 적어 두는 것만으로는 누수를 막지 못했습니다. 외주 플랫폼 약관이 채팅 안의 외부 링크를 금지한다는 사실을 10월 4일에 기록해 두었는데도, 이틀 뒤 시안 링크가 채팅방 5곳에 나갔습니다. 같은 기간 대표 지적 83개 중 21개(25%)가 이처럼 규칙이 있는데도 다시 나온 지적이었고, 저희는 규칙을 더 쓰는 대신 발송 직전에 기계가 막는 구조로 바꿨습니다.
AI업무자동화 견적서, 지적 83개 중 21개는 이미 규칙이 있었다
AI업무자동화로 견적서를 만들 때 같은 지적이 반복된 이유는 규칙이 없어서가 아니라 만드는 순간 규칙이 읽히지 않아서였습니다. 고객 3건의 제안서·견적서를 두고 대표가 지적하고 AI가 고치는 왕복이 52바퀴였고, 지적 83개 가운데 21개(25%)는 이미 적어 둔 규칙을 어긴 경우였습니다. 규칙을 생성 단계에 전부 넣고 기계 검사를 붙인 뒤 다시 재 보니 남은 지적은 6건, 5건이었습니다. 목표로 정한 0건에는 아직 닿지 못했습니다.
크론 로그 확인, 실행 0회 17개는 정말 안 돌았나
크론 로그 확인에서 실행 0회는 "안 돌았다"는 판정이 아니라 "돈 흔적을 찾지 못했다"는 관측입니다. 2026년 10월 14일 등록 크론 168개 가운데 사람 일을 대신하는 70개의 최근 30일 기록을 세어 보니 실행 0회가 17개, 로그 형식이 달라 횟수를 셀 수 없는 작업이 17개였습니다. 그런데 0회 작업 중 기록 위치가 남은 10개를 펼치자 7개는 로그 자체가 없었고, 한 스크립트가 네 줄을 차지하고 있었습니다.
랜딩페이지 전환율 0건, 폼이 아니라 금액이 빠져 있었다
랜딩페이지 전환율이 0건이었던 진짜 원인은 폼의 길이가 아니라, 메일이 약속한 내용과 금액이 첫 화면에 없었다는 점이었습니다. 콜드메일에서 61번의 클릭이 랜딩으로 넘어왔고, 그중 7명이 진단을 시작했고, 문의는 0건이었습니다. 처음에는 입력 단계를 줄이면 된다고 봤고 그 판단은 틀렸습니다.
AI 도입 성과 지표, 우리 홈페이지엔 0건이었다: 브런치 405편 대조
AI 도입 성과 지표가 우리 홈페이지 카피에 0건이었고, 문제는 시장이 아니라 이 빈칸이었습니다. 한국 초기 창업팀에게 AX·DX 컨설팅을 권하는 한 저자의 브런치 글 405편, 1,339,296자를 모아 우리 서비스와 대조했습니다. 자리는 맞았고 팀 단위 진입점도 겹쳤지만, 구매 담당자가 예산을 열 때 내미는 결과 숫자는 한 개도 없었습니다.
AI 글 판별, 조사와 접속부사만으로 갈렸지만 차단은 미뤘다
AI 글 판별은 내용을 읽지 않고 조사·어미·접속부사의 빈도만 세어도 상당히 맞았고, 그래도 저희는 이 신호로 글을 막는 규칙을 아직 넣지 않았습니다. AI가 쓴 짧은 글 조각 433개와 사람이 쓴 글 10,000개를 기능어 90개의 비율로만 나눴더니 AUROC 0.816 ± 0.019가 나왔습니다. 차단을 미룬 이유는 판별력이 모자라서가 아니라, 이미 걸어 둔 다른 검사의 효과를 아직 가르지 못했기 때문입니다.
블로그 대행 원가 실측: 사전 조건이 재개를 17일 막은 기록
블로그 대행 원가(발행 1건에 사람 손이 드는 시간)를 미리 10건 재야 서비스를 다시 연다는 조건은, 17일 동안 아무도 수행하지 않아 조건이 아니라 차단기로 굴었습니다. 2026년 8월 28일 저희는 그 실측을 첫 고객의 발행 8건으로 옮기고, 동시 운영 정원을 1개사로 묶어 모르는 원가의 최악값을 월 2.7시간으로 가둔 뒤 재개를 확정했습니다.
프로그래매틱 SEO 얇은 콘텐츠 367페이지 보강기: 338자에서 1,429자로
프로그래매틱 SEO로 찍어 낸 페이지 367개는 전부 얇은 콘텐츠였고, 저희는 LLM을 쓰지 않고 데이터 템플릿만으로 페이지마다 다른 고유 텍스트 중앙값을 338자에서 1,429자로 늘렸습니다. 다만 이 숫자는 글자 수를 다시 잰 결과일 뿐이고, 검색 유입이 늘었다는 증거는 아직 없습니다.
블로그 운영대행 재개 회고, 판매 상태가 세 파일에서 달랐던 17일
블로그 운영대행 서비스를 중단했다가 다시 여는 동안 판매 상태를 적은 세 파일이 서로 다른 말을 했고, 저희는 17일간 판정이 없는 서비스를 팔고 있었습니다. 재개를 막던 조건(발행 10건 사전 실측)은 아무도 수행하지 않아 결정 요청이 11.9일 동안 답을 받지 못했고, 결국 그 실측을 첫 고객의 발행 8건으로 옮겨 2026년 8월 28일 재개를 확정했습니다.
네이버 블로그 링크 카드 자동 발행, API로 못 만드는 카드를 붙여넣기로
네이버 블로그 링크 카드는 API로 만들 수 없어서, 자동 발행에서는 빈 문단에 주소만 붙여 넣고 편집기가 카드를 만들 때까지 기다리는 방법이 유일한 길이었습니다. 이 방식과 조립 후 일괄 서식 변환을 함께 적용해, 구조 장치가 0개였던 글 5편을 포함한 기존 7편을 다시 발행했고 라이브 재측정에서 7편 모두 소제목 8~12개·링크 카드 2~3개를 확인했습니다.
콜드메일 발송량을 150통으로 늘린 날, 문의 0건은 그대로였다
콜드메일 발송량 하루 상한을 100통에서 150통으로 올린 근거는 최근 30일 반송률 4.3%와 스팸 신고 0건이었지만, 발송량은 처음부터 문제가 아니었습니다. 같은 날 함께 들여다본 클릭한 회사 34곳, 개발사를 거르는 업종 코드 필터, 회사명이 들어간 안내 페이지에서 가설 두 개가 숫자로 무너졌습니다. 나흘 뒤 전체 발송 1,193건을 다시 세어 보니 클릭 56건, 폼 문의 0건이었습니다.
업종코드로 개발사 거르기, 라벨 한 줄은 넣고 문구 필터는 버렸다
업종코드로 개발사를 거르는 필터는 코드 라벨 단위로 막고, 사업자등록의 업태·종목 문구까지 읽게 넓히지 않는 편이 맞았습니다. “소프트웨어 도매업”으로 등록한 응용 소프트웨어 개발사가 필터를 그대로 통과했고, 같은 업종코드 회사가 발송 대기열에 12곳 있었습니다. 문구 필터를 붙여 후보 4,249곳에 돌려 보니 108곳이 추가로 빠졌는데, 그 목록은 종이제품 제조사와 부동산 임대사였습니다.
위시켓 포트폴리오 자동 첨부를 제목 핵심어 규칙으로 고친 기록
위시켓 포트폴리오를 공고마다 자동으로 붙일 때는 판매 서비스 태그보다 공고 유형과 제목 핵심어로 골라야 맞았습니다. 태그별로 3건씩 고정해 둔 기존 규칙에서는 태그 없는 공고 130건이 첨부 0건이었고, 태그가 붙은 공고에도 엉뚱한 사례가 붙었습니다. 규칙을 바꾼 뒤 상위 등급 공고 21건에서 무관한 첨부가 0건이 됐고, AI 에이전트 공고 10건의 첨부는 2회에서 11회로 늘었습니다.
기술블로그 SEO 검사를 통과한 글이 안 읽힌 이유, 검사에 독자가 없었다
기술블로그 SEO 검사는 8항목을 전부 통과했지만 독자를 묻는 항목이 하나도 없었고, 그래서 제목만 봐서는 무슨 글인지 알 수 없는 글 4편이 실렸습니다. 비교 표본 1,157편은 86%가 제목에 기술명이나 문제 명사를 담았는데 우리 4편은 0편이었습니다. 난이도와 첫 문단 가설이 차례로 깨진 뒤에야 검사에 독자 항목이 없었다는 원인이 남았습니다.
LLM 분류 프롬프트, '관련 있음' 71건이 전부 오탐이었다
LLM 분류 프롬프트에 '주제가 맞는가'만 물으면, 주제는 맞지만 저희 고객 이야기가 아닌 글을 전부 통과시킵니다. 해외 개발자 커뮤니티 해커뉴스에서 하루 동안 모은 82건 가운데 LLM이 '관련 있음'으로 판정한 71건을 다시 보니 한국 시장 글은 0건이었습니다. 처음에는 검색 키워드를 범인으로 지목했고, 그 가설은 표본 20건을 열어 보는 순간 틀린 것으로 드러났습니다.
개발 생산성 측정, 커밋보다 자동화 스크립트가 빨리 늘었다
개발 생산성 측정은 한 가지 숫자로 하면 틀립니다. 2026년 8월 21일 기준선과 10월 11일 재측정을 나란히 놓자 저장소는 42개에서 49개로 7개 늘었을 뿐인데, 사람 작업 커밋은 4,612개에서 7,330개로, 자동화 스크립트는 210개에서 606개로, 정해진 시각에 도는 크론 잡은 142개에서 321개로 늘었습니다. 처음에는 저장소와 커밋이 일한 양을 보여 준다고 가정했고, 그 가설은 세 군데에서 틀렸습니다.
개인화 랜딩 페이지 검수 8건, 인원을 넣자 결론이 1명으로 돌아갔다
개인화 랜딩 페이지에 방문 회사의 인원 수를 넣었더니, 앞부분은 인원이 많을수록 이득이라고 말하면서 결론부는 다시 1명 기준으로 돌아가는 페이지가 나왔습니다. 배포 직후 사람이 직접 검수해 지적 6건을 찾았고, 고치는 중에 2건이 더 나왔습니다. 원인은 문장 하나하나가 아니라 인원이라는 축을 섹션 절반에만 반영한 설계였습니다.
네이버 단체회원 계정, 블로그 대행 약관 검토에서 빠뜨린 층
네이버 단체회원 계정이 있었기 때문에, 블로그 운영을 남에게 맡길 공식 통로가 없다는 우리 결론은 틀렸다. 계정 운영정책에는 구성원이 하나의 아이디를 함께 쓰되 각자 정한 비밀번호로 로그인해 글을 올리는 기능이 적혀 있었다. 우리는 블로그 기능 화면만 확인하고 계정 정책은 열지 않은 채 판매를 멈췄고, 판단을 되돌리기까지 나흘이 걸렸다.
SMTP 550 5.7.1 거절, 계정 없음으로 읽으면 살아 있는 주소를 버린다
SMTP 550 5.7.1 거절을 계정 없음으로 읽으면, 답장까지 보낸 살아 있는 고객 주소를 영구히 버리게 된다. 우리는 메일을 보내기 직전에 받는 서버에 그 계정이 있는지 묻는 검사를 만들었고, 첫 판은 5xx 응답을 전부 계정 없음으로 처리했다. 그 상태에서 재 본 성적은 반송 주소 57% 차단, 정상 주소 10% 차단이었다. 응답 문구로 정책 차단을 갈라내자 반송 주소 48% 차단, 정상 주소 0% 차단으로 바뀌었다.
네이버 블로그 글자수, 상위 글 9건을 재 보니 우리 원고는 하한의 절반이었다
네이버 블로그 글자수를 실제 검색 결과로 재 보니 상위 노출 글 9건의 본문은 최소 1,966자·중앙 3,299자였고, 저희가 47편 쌓아 둔 요약형 원고는 1,033자였습니다. 본문 전개형으로 바꿔 중앙 2,101자, 126편 중 87편(69%)이 하한선 안으로 들어왔지만 중앙값에 닿은 원고는 한 편도 없었습니다.
pSEO로 주력 서비스 키워드 페이지를 대량 생성하기 전에 세어 봐야 할 것
pSEO는 데이터 유니버스가 클 때 통하는 방식이고, 주력 서비스 키워드 72종은 대부분 동의어라 키워드마다 페이지를 만들 근거가 없었습니다. 저희는 콘텐츠를 상업 의도 갈래와 질문 갈래로 나눴고, 발행할 수 있는 주제 묶음이 4개에서 14개가 됐습니다. 이 글은 처음 가설이 틀린 지점과, 그 뒤에도 남아 있는 한계를 같이 적습니다.
GA4 광고 세션이 클릭보다 많게 찍힐 때, 표본부터 의심해야 하는 이유
GA4 광고 세션 숫자는 광고 계정의 클릭 수와 같지 않고, 이 차이를 모른 채 읽으면 표본이 없는 칸에서 결론을 만들게 됩니다. 저희는 구글 광고 클릭 19건에 GA4 세션이 31건 찍힌 표를 보고 모바일이 붕괴했다고 읽었습니다. 다시 확인하니 30일 데이터라던 창은 클릭 발생일 사흘치였고, 붕괴한 칸을 받친 실클릭은 8건뿐이었습니다.
홈페이지제작업체 SEO 노출 0, 카니발라이제이션 가설이 틀린 이유
홈페이지제작업체 검색에서 글이 안 보이는 이유를 같은 글끼리 순위를 나눠 먹는 카니발라이제이션으로 진단했지만, 28일 검색 노출 데이터는 그 현상을 보여 주지 않았습니다. 판매 서비스 직결 글 89편이 만든 노출은 82건에 클릭은 2건이었고, 월 2,840회 검색되는 홈페이지제작업체 노출은 0이었습니다. 그래서 글 통합을 보류하고 새 글이 쌓이는 길부터 막았습니다.
네이버 검색 API 정렬: sort=date가 관련 질문 1,414건을 가렸다
네이버 검색 API 정렬을 sort=date 하나만 쓴 설정이 지식iN 질문 후보 선정 0건의 원인이었습니다. 같은 키워드를 sort=sim으로 다시 조회하자 상위 10건 중 관련 질문이 3건에서 10건으로 늘었고, 그 아래에는 한 번도 손대지 않은 관련 질문 1,414건이 쌓여 있었습니다. 그래서 2026년 8월 17일, 키워드를 늘리는 대신 두 정렬을 함께 쓰고, 페이지를 열기 전에 후보를 거르는 필터를 넣고, 질문 작성일 상한을 90일에서 365일로 넓혔습니다.
홈페이지 제작 견적서, AI 검토가 붙인 기능을 걷어낸 기준
홈페이지 제작 견적서의 범위는 AI 검토가 필요하다고 본 기능이 아니라 고객이 실제로 말한 요구로만 닫아야 합니다. 노무법인 고객의 견적을 쓰면서 적대 검토가 낸 지적 15건을 전부 반영하려 했지만, 고객의 통화·채팅·첫 견적과 한 줄씩 대조해 보니 알림톡·지사별 알림·2단계 인증·웹 접근성은 어디에도 없었습니다. 가격은 고객 요청대로 390만 원에서 300만 원으로 낮추고, 범위는 첫 견적과 통화 요구로 잠갔습니다.
콜드메일 회신률, 클릭 4.2%가 리드 0건이었던 이유
콜드메일 회신률이 0에 머문 원인으로 저희는 문구가 아니라 한 통에 담긴 요청의 개수를 지목했습니다. 669통을 보내 클릭 27건(4.2%)을 얻었고, 그 클릭에서 나온 리드는 0건이었습니다. 처음엔 클릭을 살아 있는 신호로 보고 링크를 지키려 했지만, 따라가 보니 클릭은 한 번도 매출 쪽으로 이어진 적이 없었습니다. 그래서 2026년 8월 28일, 메일 절반에서 요청 두 개를 빼고 “회신” 하나만 남겼습니다.
SEO 콘텐츠 노출 2.6→0.9, 더 쓸수록 떨어진 이유
SEO 콘텐츠 노출이 떨어진 원인은 발행량이 아니라 글을 놓은 자리였습니다. 판매 서비스와 직결한 글 88편은 하루 최대 9편씩 늘어나는 동안 편당 노출이 2.6에서 0.9로 내려갔고, 같은 기간 세무 글 12편은 편당 19.9를 냈습니다. 처음엔 “덜 써서”와 “겹쳐 써서”를 의심했지만, 끝까지 따라가 보니 광고 입찰가가 9.3배 비싼 상업형 검색어에 글을 쌓고 있었고, 사람이 실제로 오는 글에서 서비스로 가는 길은 한 줄도 없었습니다.
지식인 마케팅 경쟁사 분석, 12계정 표본의 결론이 뒤집혔다
지식인 마케팅에서 채택을 가르는 1순위는 답변자의 전문성이나 브랜드가 아니라 질문이 올라온 지 얼마나 됐느냐였습니다. 같은 시장의 대형 답변 운영사 계정 57개를 전수로 조사하자, 당일 질문에 단 답변은 27.0%가 채택을 받았고 작성 8~90일이 지난 질문에 단 답변은 0%였습니다. 중간에 12계정 표본으로 내렸던 “브랜드 인사말이 채택을 깎는다”는 결론은 이 시점 차이가 만든 착시였고, 2026년 9월 15일에 정정했습니다.
지식인 채택률 2.8%의 원인, 프롬프트가 아니라 질문 나이였다
지식인 채택률을 2.8%에 묶어 둔 원인은 답변 문장이 아니라 저희가 고른 질문의 나이였습니다. 저희 자동 답변이 붙은 질문은 작성된 지 중앙값 141일이 지난 글이었고, 같은 시장에서 당일 질문에 단 답변은 27.0%가 채택을 받았습니다. 그래서 2026년 9월 15일, 프롬프트를 고치는 대신 질문을 가져오는 통로와 발행 시각표를 바꿨습니다.
AI 에이전트 메모리의 빈칸, 기각한 제안이 세션마다 돌아왔다
AI 에이전트 메모리가 기각한 제안을 다시 들고 오는 원인은 기억력이 아니라 저장 구조였습니다. 저희 에이전트가 세션을 넘어 남기는 기록 세 가지가 전부 '하기로 한 것'만 담고 있었고, '하지 않기로 한 것'을 담는 자리는 어디에도 없었습니다. 2026년 8월 8일에는 한 세션 안에서 이미 기각한 제안이 2번 다시 올라왔습니다.
crontab 실행 안됨, 등록된 크론 중 실행 0회가 16개였다
crontab 실행 안됨 문제는 crontab -l 로 등록 목록을 열어서는 보이지 않고, 로그에 남은 실행 흔적을 세야 드러났습니다. 2026년 10월 8일에 사람 일을 대신하는 크론 70개의 최근 30일 흔적을 세어 보니 실행 0회가 16개, 로그 형식이 달라 횟수를 셀 수 없는 작업이 17개였습니다. 흔적을 세는 방식도 믿을 수만은 없었습니다. 하루 한 번 도는 작업이 30일에 99회로 잡혔기 때문입니다.
이메일 클릭률과 실제 방문 차이: 클릭 913건, GA4 방문 18건
이메일 클릭률이 높아도 그 클릭이 사이트 방문으로 이어진다는 보장은 없었습니다. 30일 동안 영업 메일 클릭은 913건이었지만 GA4에 잡힌 실제 방문은 18건, 비율로 0.6%였습니다. 처음에는 “회사가 작아 신뢰가 없어서 클릭한 사람이 떠난다”고 의심했고, 그 가설을 확인하려고 본보기 회계법인의 뉴스레터까지 전수로 뜯었습니다. 그 가설은 절반만 맞았고, 간극의 대부분은 링크와 계측 쪽에 있었습니다.
카카오 챗봇 스킬 서버 메일 유실, 초록불 테스트가 놓친 429
카카오 챗봇 스킬 서버의 메일 유실은 응답만 재던 테스트가 초록불을 켠 채로 숨기고 있었습니다. 실행 검증 20개 항목 중 18개가 통과했는데 서버 로그에는 발송 실패가 전 건 찍혀 있었고, 문의 8건을 한꺼번에 넣으면 2건만 담당자에게 닿았습니다. 원인은 메일 API의 429 응답에 재시도가 없는 백그라운드 발송이었고, 재시도를 넣은 뒤 8건 모두 도착했습니다.
LLM 토큰 비용 76% 절감, 룰을 다 넣지 않고 골라 넣었다
LLM 토큰 비용은 모델을 바꾸는 쪽보다 프롬프트에 넣는 룰을 고르는 쪽에서 크게 줄었습니다. 금융투자 광고 검토 시스템에서 수백 개 룰을 매번 전부 넣던 방식을 경량 모델이 먼저 고르는 RAG 라우터로 바꾸자, 평가 세트 기준 입력 토큰이 427K에서 104K로 76% 줄고 총비용이 54% 줄었습니다. 이 글은 룰을 늘릴수록 정확해진다는 가설이 비용 앞에서 틀린 과정과, 줄인 뒤에도 품질을 지키려고 둔 골든 케이스 24개 회귀 감시를 순서대로 적습니다.
AI 에이전트 승인 요청 병목, 응답 속도가 아니라 유입량이었다
AI 에이전트 승인 요청이 쌓이는 원인은 사람이 늦게 답해서가 아니라, 사람에게 올라오지 말았어야 할 요청이 너무 많이 올라와서였습니다. 저희는 처음에 알림을 늘리면 해결된다고 봤고, 그 가설은 숫자 앞에서 무너졌습니다. 이 글은 입구에서 요청을 거르는 필터를 만들고, 그 필터가 정작 사람이 봐야 할 결정까지 치워 버린 실수를 찾아 고친 과정을 순서대로 적습니다.
QA 자동화, 크론 잡 303개를 혼자 검수하지 못했다: 줄인 건 검수량
QA 자동화로 1인 개발의 검수 병목을 풀려면 검사를 빨리 돌리기보다, 사람이 봐야 하는 양이 제품 수에 비례해 늘어나는 구조부터 끊어야 했습니다. 2026년 8월 21일 기준선에서 10월 7일 재측정까지 커밋은 4,612개에서 7,066개로, 크론 잡은 142개에서 303개로 늘었습니다. 늘어난 자동화를 사람 눈으로 다 확인하겠다는 계획은 처음부터 성립하지 않았고, 기계에 맡긴 판정도 검사기 자체를 검증하기 전까지는 믿을 수 없었습니다.
숨고 고수 견적 캐시, 돈을 내면 고용이 늘까: 7,961명 전수 조사
숨고 고수 견적에 캐시를 쓰면 고용이 늘어난다는 증거는 공개 데이터 어디에도 없었습니다. 숨고 “웹 개발” 고수 7,961명을 전수로 세어 보니 고용이 한 번도 없는 고수가 6,298명(79.1%)이었고, 상위 5%가 전체 고용의 81.2%를 가져갔습니다. 처음에는 자동 견적(스마트견적)을 켠 고수의 성적이 좋다는 숫자를 보고 “돈을 내면 거래가 는다”고 읽을 뻔했지만, 그 숫자는 원인을 말해 주지 못했습니다.
백테스트 레짐 필터, 약세장 손실을 줄이고도 탈락시킨 이유
백테스트 레짐 필터는 약세장 손실을 -30.98%에서 -10.66%로 줄였지만, 저희는 이 전략을 실전에 넣지 않기로 했습니다. 약세장 표본이 단 한 번뿐이라, 그 한 번을 흑자로 맞추는 튜닝은 과적합밖에 남기지 않기 때문입니다. 이 글은 숫자가 좋아 보이는데도 탈락시킨 과정과, 그 판정마저 나중에 평가 틀 문제로 정정한 사실까지 순서대로 적습니다.
생존자 편향 보정, 랭커가 진 달을 넣자 기대수익이 3분의 1로
생존자 편향 보정을 하자 랭커의 청산 습관은 살아남았고, 기대 수익은 3분의 1 남짓으로 줄었습니다. 지속 랭커 26명이 랭킹에 못 든 달의 체결 14,857행을 더해 왕복 표본을 960건에서 1,933건으로 늘렸고, 비용을 뺀 평균 순수익은 +0.79%에서 +0.28%로 내려갔습니다. 약세장 구간의 손실은 착시가 아니라 더 뚜렷한 사실이었습니다.
백테스트 과최적화, 샤프 3.24 전략이 5년 검증에선 음수였다
백테스트 과최적화를 점검하려고 운영 중인 자동매매 전략 세 개를 5년 데이터로 다시 돌렸더니, 셋 다 전체 기간 샤프 지수가 음수였습니다. 라이브 11개월 동안 2.79~3.24를 기록하던 전략들이었고, 흑자를 낸 해는 2025년 한 해뿐이었습니다. 짧은 기간의 좋은 성적이 어디서 왔는지, 그리고 바로 끄지 않고 어떤 기준을 세웠는지 기록합니다.
자동매매 급락 감지 기준선, 낮춰도 비상계엄은 안 잡혔다
자동매매 급락 감지 기준선을 낮추는 처방은 비용만 키우고 문제의 사건은 잡지 못했습니다. 저희 주식 자동매매 시스템은 비상계엄 당일 시장 점수를 -0.287로 계산해 공황 기준선 -0.60에 한참 못 미쳤고, 기준선 5개를 5년치에 적용해 보니 가장 느슨한 값도 그날을 놓쳤습니다. 이 글은 기준선을 옮기려다 점수를 만드는 재료가 비어 있었다는 사실을 찾은 과정을 순서대로 적습니다.
백테스트 갭 반영 누락, 손절 57건 중 73.7%가 갭 관통이었다
백테스트 갭 반영이 빠져 있으면, 손절 규칙을 바꾸는 실험은 처음부터 잴 수 없습니다. 저희 주식 자동매매 백테스트는 손절 청산을 언제나 손절선 가격에 체결된 것으로 계산했고, 실제로는 손절 청산 57건 중 73.7%가 밤사이 갭으로 그 선을 뚫고 내려가 있었습니다. 이 글은 장 마감 직전에 포지션을 정리하면 손실이 줄어든다는 가설 세 개를 검증하려다 측정 도구부터 고쳐야 했고, 결국 셋 다 기각한 과정을 순서대로 적습니다.
Windows Terminal 창 배치 자동화, 마지막 창만 제자리를 못 찾은 이유
Windows Terminal 창 배치를 자동화할 때 가장 늦게 드러나는 결함은 창을 한 번 밀고 확인하지 않는 구조였습니다. 저희는 4모니터 2×2 구성에 Claude Code 세션 8개를 한 명령으로 띄우는데, 2026년 8월 15일 존8 창이 Windows Terminal 기본 위치 861,90에 남아 있었고 런처는 그 창을 ok로 보고했습니다.
스레드 자동 발행 측정 오류, 좋아요를 읽지 못하고 0으로 적고 있었다
스레드 자동 발행 글에 그림을 붙인 실험의 처리군이 비교표에서 0건이었던 원인은 발행이 아니라 측정이었습니다. 측정기가 좋아요를 읽지 못하고 못 읽은 값을 0으로 적었고, 9월 17일에 수집한 14건은 전부 답글 항목만 읽힌 채 좋아요 0으로 적혀 있었습니다.
광고 전환 퍼널 점검, 끊긴 곳을 고쳐도 같은 절단이 되돌아온 이유
광고 전환 퍼널 점검은 끊긴 지점을 고치는 일이 아니라 지점을 끊기게 만든 구조를 고치는 일이었습니다. 2026년 7월 20일 네 층에서 찾은 절단을 모두 고쳤는데도 같은 종류의 절단이 다른 서브도메인과 다른 키워드 그룹에서 반복했고, 점검 단위를 증상에서 구조 원인으로 올린 뒤에야 줄기 시작했습니다.
텔레그램 알림 중복 제거, 고점수 글 84%가 재알림이었던 이야기
텔레그램 알림 중복 제거를 하지 않으면 «고점수 글을 발굴했다»는 알림의 대부분은 이미 본 글입니다. 저희 점수 파일 120개에서 8점 이상 글은 456건이었고, 서로 다른 글은 75건뿐이었습니다.
온라인광고대행업 통계 837→1,136, 성장이 아니라 재분류일 수 있다
광고산업조사의 온라인광고대행업 통계는 사업체 수가 837에서 1,136으로 늘었다고 나오지만, 같은 표에서 광고대행업과 합친 사업체 수는 2020년 2,455, 2023년 2,456으로 그대로여서 성장보다 재분류일 수 있습니다. 그래서 증가율은 근거로 쓰지 않고 수준값만 쓰기로 했습니다.
사람인 이력서 특수문자, 화살표가 입력 즉시 지워져 자동 저장이 멈춘 이유
사람인 이력서 특수문자 가운데 화살표(→ ⇒ ▶ 와 굵은 화살표(U+2794))는 입력하는 순간 지워지고, 그 1자 때문에 소개글이 382자에서 381자로 읽혀 자동 저장이 멈췄습니다. 원인은 대조 코드가 아니라 입력칸이었고, 작성완료 버튼은 50밀리초 뒤로 클릭을 예약해서 풀었습니다. 핵심역량 5줄이 사라진 원인은 끝내 찾지 못했습니다.
크론 작업 모니터링, 14라운드를 돌려도 결함이 안 줄었던 이유
크론 작업 모니터링에서 결함이 줄지 않은 원인은 점검이 모자란 것이 아니라 결함을 하나씩 고치는 방식이었습니다. 같은 렌즈로 14라운드를 돌려도 라운드마다 신규 결함이 8건에서 14건씩 나왔고, 덧댄 수리 147건을 다시 묶으니 구조 원인 9개와 단발 2건이 남았습니다.
Threads 조회수 수집이 null이던 날, 노출 2.7만회를 한 번도 못 재고 있었다
Threads 조회수 수집이 98건 전부 null이었던 원인은 정규식 한 줄의 비대칭이었습니다. 프로필 헤더에는 «최근 조회수 2.7만회»가 떠 있었는데, 조회수 패턴만 소수점과 «만»을 받지 못해 값을 한 번도 읽지 못했습니다.
사무자동화 대사 랜딩 페이지, 검색용이 아니라 접촉 후 검증용으로 만든 이유
사무자동화 도구의 소개 페이지는 검색에 걸리라고 만든 게 아니라, 소개서 메일을 받고 저희를 검색한 사람이 “이 회사가 진짜 이걸 하나”를 확인하는 자리로 만들었습니다. 그래서 첫 화면 다음에 소개가 아니라 실적을 놓았고, 맥락 없는 독자에게 6회차까지 읽혀 모순을 하나씩 걷어 냈습니다.
수주율 계산, 계약이 0건이어도 가격표를 기각할 수 있었다
수주율 계산은 계약이 0건이어도 할 수 있습니다. 리드 14건에 계약 0건인 표본에서 rule of three로 95% 상한 21.4%를 내면, 그 상한을 넘는 필요 수주율은 «어렵다»가 아니라 현재 표본과 양립 불가로 판정할 수 있습니다.
AI 코드 품질 측정을 점수 목표에서 회귀 문턱으로 바꾼 기록
AI 코드 품질 측정은 “몇 점 이상”을 목표로 걸 때가 아니라 “지난번보다 떨어지지 않게” 막을 때 작동했다. 점수 네 개 중 strict 하나만 판정에 쓰고, 프로젝트마다 기준선을 재서 문턱을 단계별로 올리도록 규칙을 바꿨다.
LLM as a judge 평균이 노이즈 폭만큼 오른 날, 결정론 지표로 다시 잰 기록
LLM as a judge로 잰 평균 점수가 1.93점에서 2.13점으로 올랐지만, 같은 조건 재실행이 0.07점 흔들리고 채점 노이즈가 0.2점이라 이 상승은 개선이라 부를 수 없었다. 대신 채점 AI와 독립된 결정론 지표로 다시 재자 정답 요소 재현율이 6.1%에서 14.3%로 올라 있었다.
스레드 자동 답글 0건, 필터를 풀어도 안 나간 진짜 원인
스레드 자동 답글이 한 건도 나가지 않은 원인은 깐깐한 발송 필터가 아니라, 답글 프로그램이 새 글을 아예 받지 못하던 공급 경로였습니다. 14일 동안 구매 의도가 보이는 글 8건을 찾고도 발송은 0건이라, 처음에는 필터 기준 다섯 가지를 한꺼번에 풀었습니다. 그 뒤 624번을 더 돌렸는데도 통과는 0건이었고, 보류 사유는 같은 세 사람에게서 나온 세 가지로 굳어 있었습니다.
DeepSeek 402 오류가 스레드 새 글을 막은 이야기, 폴백 호출에 검사가 없었다
DeepSeek 402 오류(잔액 부족) 문장이 정상 초안처럼 통과하면, 자동 글쓰기 파이프라인은 에러 하나 없이 조용히 멈춥니다. 저희 스레드 계정의 새 글이 9월 15일과 16일에 0건, 17일에 1건으로 멎었을 때 원인이 정확히 이 모양이었고, 폴백 호출에 종료 코드 검사가 없었습니다.
쿠팡 크롤링 차단, 15분 만에 선 벽: 고정 4.5초 간격이 자초했다
쿠팡 크롤링 차단은 IP 전체가 아니라 카테고리·상품 경로에만 걸렸고, 원인은 사이트가 아니라 요청 속도를 조절하지 않은 저희 스캐너였습니다. 목록 30페이지와 상세 24건, 리뷰 API 24회를 돈 뒤 한 번에 몰아 읽은 뒤 `Access Denied`가 떴고, 속도 조절 모듈을 넣은 뒤 두 번째 차단에서는 60→120→240초를 기다리다 스스로 멈췄습니다.
스레드 프로필 링크 유입, 소개란이 비었다던 기록이 틀렸던 날
스레드 프로필 링크 유입이 끊겼다는 보고는 하루 전 기록을 현재 상태로 읽은 오보였습니다. 2026년 9월 1일 라이브로 다시 확인하니 소개 3줄과 홈페이지 링크가 있었고, 최근 21일 동안 threads 소스에서 12세션이 GA4에 찍혀 있었습니다.
스레드 마케팅 글이 읽히는데 좋아요가 0이었다, 주제와 글감 출처를 다시 쟀다
스레드 마케팅에서 글이 읽히는데 좋아요가 0이었던 원인은 문장이 아니라 글감 출처였다. 노출 102~488을 받고도 좋아요가 0이었던 우리 글은, 좋아요 중앙값이 가장 낮은 주제만 쓰고 있었다. 출처 파일이 전부 회의록이었고, 우리가 파는 서비스 문서는 한 번도 글감이 된 적이 없었다.
AI업체 홈페이지에 실적을 쓰기 전에, 방문자가 직접 세어 볼 수 있는지부터 쟀다
AI업체가 홈페이지에 운영 실적 수치를 쓸 때 가장 먼저 그 수치를 반박하는 쪽은 경쟁사가 아니라 같은 화면에 걸어 둔 우리 링크였다. 서비스 소개 페이지에 숫자 세 개를 넣으려다 이 사실을 알았고, 기준을 “그럴듯한 숫자 세 개”에서 “방문자가 눌러서 직접 세어 확인되는 도착지 세 개”로 바꿨다.
RAG 성능 평가에서 재현율이 안 오를 때, 프롬프트를 고치기 전에 잰 것
RAG 성능 평가에서 재현율이 안 오르는 원인은 프롬프트가 아니라 검색 천장이었다. 정답에 들어 있는 토큰 49개 가운데 우리가 모델에게 넘긴 자료 안에 애초에 존재하는 것은 16개, 32.7%였다. 초안이 실제로 맞힌 7개(14.3%)는 천장 대비 44%이고, 목표로 잡았던 재현율 25%는 천장의 76%를 내라는 요구였다.
자동화 성과 측정에서 크론 168개의 절감 시간을 세다가 막힌 곳
자동화 성과 측정에서 먼저 막힌 곳은 재료가 아니라 계측이었다. 무인으로 도는 크론 168개를 성격별로 나눠 보니 사람 업무를 대신하는 작업은 70개였고, 사람이 그 일을 직접 하며 잰 시간 기록(measured)은 0건이었다.
크론 실행 확인, 등록 목록이 아니라 실행 흔적을 세야 하는 이유
크론 실행 확인은 등록 목록이 아니라 로그에 남은 실행 흔적으로 해야 합니다. 등록한 크론 168개 중 사람이 하던 일을 대신하는 70개의 최근 30일 기록을 2026년 10월 1일에 세어 보니, 실행 0건이 19개였고 로그 형식이 달라 횟수를 셀 수조차 없는 작업이 17개였습니다.
카드뉴스 디자인 스타일을 수치로 나눈 뒤 검사기가 잡은 사고 두 건
카드뉴스 디자인 스타일을 숫자로 나눠 재현하는 작업에서, 검사 스크립트가 떨어뜨린 원인은 이미지 품질이 아니라 우리 쪽 자와 코드였다. 표지만 잰 기준값을 카드 8장 전체와 견줬고, 다크 스타일에서는 화면을 어둡게 덮는 막이 밝은 글자색을 그대로 써서 흰 배경에 흰 글자 표지가 나왔다. 기준을 넓혀 통과시키는 대신 두 원인을 고쳤고, 다크 스타일 표지의 평면 비율은 0.840에서 0.538로 내려와 참고 군의 0.546과 0.008 차이로 붙었다.
표본 크기 10 미만에서 나온 결론이 뒤집힌 과정: 스레드 글 1,902건 재수집기
표본 크기가 작은 칸에서 나온 결론은 표본이 커지자 실제로 뒤집혔고, 그래서 지금은 모든 결론 옆에 표본 수 n을 같이 적는다. 스레드 비교 계정 하나의 분석 대상 글은 41건에서 253건, 다시 1,669건으로 두 번 커졌고, 그사이 “질문으로 시작하면 진다”던 결론은 질문형 글 6건과 4건에 기대고 있었다는 사실이 드러났다.
랜딩페이지 CTA 버튼 검사, 정규식이 놓친 자리는 없는 게 아니었다
랜딩페이지 CTA 버튼을 세는 자동 검사가 있는 버튼 하나를 통째로 놓치고 '견적 문의 버튼 하나가 전부'라고 결론 냈습니다. 검사 규칙에 없는 것은 검사 결과에도 없는데, 그 사실을 '실제로 그런 버튼이 없다'는 뜻으로 잘못 읽었습니다.
아웃바운드영업 자동화, 답글에 회사 지식이 없었던 이유: 신원은 나중이라는 착각
아웃바운드영업 자동화가 스레드에서 찾은 잠재 고객 글에 쓴 답글에는, 지식인처럼 주려던 정보가 하나도 들어 있지 않았다. 되묻는 말 1개와 애매한 인사말이 실제로 나간 전부였고, 신원과 서비스 소개는 다이렉트 메시지 단계에서 밝히기로 했으니 괜찮다고 여겼다. 그런데 다이렉트 메시지 단계까지 간 대화를 세어 보니 0건이었다. 나중에 채워질 정보는 애초에 나중이 없었다.
추천 알고리즘 편향, 점수 대신 쿼터를 쓴 이유
추천 알고리즘 편향은 점수식 자체가 아니라, 점수만으로 순서를 정하는 구조 안에 있었습니다. 회사 기술 블로그의 글감 선택 점수는 '글이 될 재료가 얼마나 많은가'만 쟀고, 실제로 파는 서비스와 관련된 소재 후보 3건은 전체 순위에서 각각 561위, 664위, 936위에 머물러 있었습니다. 하루 3~9편을 발행하는 페이스로도 그 자리까지 내려가려면 약 두 달이 걸리는 순위였습니다. 점수에 가산점을 더하는 방법은 시뮬레이션에서부터 실패했고, 점수식은 그대로 두고 별도의 확보 규칙을 추가해서야 문제가 풀렸습니다.
네이버 계정 제재 위험, 발행 실패를 전부 세면 안전장치가 스스로 꺼진다
네이버 지식iN 자동 답변 채널의 하루 발행 상한을 5건에서 7건으로 늘리면서, 네이버 계정 제재 위험을 사람이 아니라 코드가 판단하게 만들었습니다. 실패를 전부 위험 신호로 셌다면 질문이 소진될 때마다 안전장치가 상시로 꺼진 상태가 됐을 것입니다.
E2E 테스트 없이 배포한 영문 서비스, 실제 신청은 0건이었다
테스트가 전부 통과하고 배포도 문제없이 끝난 영문 서비스에서, 실제로 규칙 하나를 끝까지 제출해 보는 E2E 테스트를 하니 처리된 신청이 0건이었습니다. 자동화된 테스트는 진짜 서비스 대신 가짜 답변과 가짜 통신을 쓰고 있었고, 실제로 막혀 있던 층은 세 개였습니다.
Claude Code 토큰 절감, 크론이 호출마다 규칙 82K를 다시 읽었다
Claude Code 토큰 절감의 답은 모델을 바꾸는 데 있지 않았고, 호출마다 다시 싣던 지시문을 빼는 데 있었습니다. 크론이 claude -p 를 한 번 부를 때마다 약 82K 토큰의 규칙 묶음이 캐시로 새로 만들어졌고, 좁은 작업에만 --safe-mode 를 붙이자 그 값이 0.3K로 떨어졌습니다. 다만 처음 세운 가설은 절반만 맞았고, 절약의 대가로 보안 규칙 하나가 같이 꺼진 사실은 두 달 뒤에야 알았습니다.
systemd CPUQuota 부작용, 상한을 걸자 인덱서가 2배 느려졌다
systemd CPUQuota로 백그라운드 인덱서의 CPU를 250%로 묶었더니, 작업 창의 버벅임은 줄지 않았고 인덱서만 청크당 0.87초에서 1.9초로 2배 느려졌습니다. 같은 날 함께 건 세 설정 가운데 실제로 효과가 있던 설정은 Nice 하나였습니다. 상한을 걷어 내고 임베딩을 조건부로 GPU에 넘긴 뒤, 청크당 처리 시간은 GPU 81ms 대 CPU 435ms로 다시 쟀습니다.
인스타그램 크롤링 175시간을 78초 시험으로, 크롬이 꺼진 진짜 이유
인스타그램 크롤링을 게시물마다 하나씩 열어 캡처하는 방식으로 하면 계정 121곳을 다 모으는 데 약 175시간이 걸린다는 계산이 나왔고, 실제로는 페이지가 스스로 받는 응답을 기록하는 방식으로 바꿔 시험 375건을 78초에 모았습니다. 다만 속도 문제를 푼 뒤에도 밤새 돌리는 동안 사고가 네 번 났고, 네 번 모두 수집 코드가 아니라 수집기를 둘러싼 운영 환경에서 터졌습니다. 이 글은 처음 세운 가설이 어디서 틀렸는지, 진짜 원인이 무엇이었는지를 숫자 그대로 남긴 기록입니다.
스레드 하루 게시물 수 상한 3건이 틀렸던 이유, 글당 반응이 속였다
스레드 하루 게시물 수 상한 3건은 잘못 잰 숫자와 잘못 고른 지표에서 나온 값이었고, 다시 재서 하루 10체인·30조각으로 올렸습니다. 처음에는 상한을 올리려면 글 소재가 모자랄까 봐 걱정했지만, 소재는 문제가 아니었습니다. 문제는 2주 전에 실측으로 내린 판정을 그대로 믿어도 되느냐였고, 재측정해 보니 그 판정은 두 군데가 틀려 있었습니다.
병원 블로그 관리 대행, 네이버 약관을 한 층만 읽고 접었다
병원 블로그 관리 대행은 네이버 약관상 막힌 사업이 아니었습니다. 비밀번호를 넘기지 않고 한 계정에 여러 사람이 글을 올리는 단체회원 계정이 있었고, 저희는 블로그 화면만 보고 그 층을 놓친 채 판매를 접었습니다. 판정을 되돌리기까지 나흘이 걸렸고, 그사이 구매하러 온 문의 1건을 잃었습니다.
LLM 자동 답글, 재개발 글에 광고 경험이 붙어 나간 이유
LLM 자동 답글이 상대 글과 무관한 경험을 끌어온 원인은 모델이 아니라 프롬프트에 무엇을 싣느냐였습니다. 재개발·집값 글에 "광고 전환 이벤트가 코드에 빠져 있어 '0'이 아니라 '못 세는 상태'였다"는 답글이 나갔고, 발송 기록 32건을 전수 조사하니 같은 유형이 8건이었습니다. 처음 지목한 선별 함수는 알리바이가 있었고, 범인은 그 옆에서 경험 목록 17개를 매번 통째로 싣던 경로였습니다.
간편인증 자동화: PASS 로그인 9번 실패, 원인은 매번 달랐다
간편인증 자동화에서 9번 연속 실패한 원인은 하나가 아니었고, 그래서 저희는 10번째 자동 재시도 대신 멈추는 쪽을 택했습니다. 앞의 다섯 번은 서버가 '인증서를 발급하지 않으셨다면'이라는 문구로 거절해 인증서 문제처럼 보였지만, 실제로는 저희 코드가 숨은 주민번호 칸에 생년월일 일부를 흘려 넣은 탓이었습니다. 그 칸을 비우자 요청은 폰까지 갔고, 이번에는 네 번이 네 가지 다른 이유로 무너졌습니다. 매번 '직전 수정으로 고쳤다'고 믿고 돌렸다는 점이 이 글의 핵심입니다.
이미지 크롤링 속도, 느린 건 다운로드가 아니라 대기였다
이미지 크롤링 속도를 끌어내린 주범은 다운로드가 아니라 요청 사이에 넣어 둔 대기였습니다. 구간별로 재 보니 루리웹은 네트워크에 0.7초를 쓰는 동안 대기에 22.9초를 썼고, 무신사는 스크롤에만 55.2초를 썼습니다. 받는 장수는 그대로 두고 대기를 호스트별 시작 간격으로, 스크롤 멈춤을 후보 수 기준으로 바꾸자 무신사는 장당 3.47초에서 1.06초가 됐습니다.
스레드 자동 발행, 같은 글이 9번 올라간 재시도 사고
스레드 자동 발행에서 같은 글이 9번 올라간 원인은 문장 필터 하나가 아니라 결함 셋이 겹친 결과였고, 그중 사고를 9배로 키운 쪽은 '실패했다'고 잘못 판정한 게시 확인과 상한 없는 재시도였습니다. 라이브 프로필에는 '스레드 체인 글 초안입니다'라는 한 줄로 시작하는 같은 첫 조각이 9개 쌓여 있었습니다. 처음엔 문장 필터의 빈틈만 보였지만, 필터만 고쳤다면 다른 문장으로 같은 사고가 또 났을 겁니다.
컴플라이언스 자동화: 건당 2시간 광고 검토, 사람 손은 어디에 남겼나
컴플라이언스 자동화에서 사람이 건당 30분에서 2시간 쓰던 광고 수기 검토는 자동 보고서로 바꿀 수 있었지만, 감독기관 제출처럼 되돌릴 수 없는 단계는 끝까지 사람 확인으로 남겼습니다. 룰을 전부 넣고 제출까지 자동으로 잇자는 두 가정은 각각 입력 토큰 427K와 판정이 모호한 회신 앞에서 틀렸습니다. 고친 뒤 입력 토큰은 104K로 76% 줄었고, 자동 제출 판정은 검증 29케이스와 실제 회신 3건에서 오탐 0이었습니다.
검색광고 입찰가 상한을 감으로 고른 숫자에서 예산 공식으로 바꾼 기록
검색광고 입찰가 상한은 하루 예산을 목표 클릭 수로 나눠 정하도록 바꿨고, 구글·네이버 모두 2,500원이 나왔습니다. 그 공식에 닿기까지 구글 무노출의 원인을 두 번 잘못 짚었고, 그 사이 계산해 둔 상한이 광고 계정에 한 번도 반영되지 않았다는 사실도 드러났습니다.
프로그래매틱 SEO를 주력 서비스로 돌리려다 검색어 72종을 세어 보고 접은 기록
프로그래매틱 SEO를 주력 서비스 쪽으로 돌리는 계획은 검색어를 세어 보는 단계에서 끝났습니다. 주력 서비스 검색어 72종은 대부분 같은 질문의 동의어라 만들 수 있는 페이지가 6개였고, 그 6개는 이미 사이트에 있었습니다.
지식iN 답변 자동화의 입력이 질문이 아니라 남의 답변 조각이었다
지식iN 답변 자동화가 질문을 빗나간 원인은 프롬프트가 아니라 입력이었습니다. 모델에게 질문이라고 건넨 텍스트는 네이버 검색 API가 잘라 준 페이지 조각이었고, 그 조각에는 같은 페이지에 달린 다른 사람의 답변이 섞여 있었습니다.
GA4 이탈률을 기기별로만 자르면 광고 네트워크가 한 칸에 섞인다
GA4 이탈률을 기기별로만 비교하면 서로 다른 광고 네트워크의 정반대 신호가 한 칸에서 평균으로 뭉개집니다. 저희는 데스크톱 153초 대 모바일 9초라는 숫자를 보고 “모바일이 붕괴했다”고 읽었지만, 유입 소스로 다시 자르자 네이버 광고의 모바일 방문은 네 칸 가운데 이탈률이 가장 낮았습니다.
기술블로그 제목에 기술명이 없던 원인은 난이도가 아니었다
기술블로그 제목에 기술명이 없던 원인은 글이 어려워서가 아니라, 글쓰기 규칙이 독자를 한 번도 정의하지 않아서였습니다. 비교 기술블로그 1,157편은 86%가 제목에 기술명이나 문제 명사를 담았고, 저희가 발행한 4편은 0편이었습니다.
지식iN 답변 채택률 2%, 유입 0건: 축소 근거로 삼은 분석이 틀렸던 이유
지식iN 답변 채택률이 2%이고 유입이 0건이어도 채널을 줄일 근거는 아니었습니다. 축소 보고서를 받친 분석 두 건이 기저율 착각과 대소문자 버그였고, 재검산 뒤 채널은 유지로 정해졌습니다.
네이버 블로그 글 구조를 자동 발행으로 상위 노출 글처럼 바꾼 과정
네이버 블로그 글 구조 문제는 원고가 아니라 변환 코드 한 곳에서 시작됐고, 소제목이 굵은 본문으로 나간 5편을 고쳐 7편을 새 구조로 다시 발행했습니다.
크몽 신규 판매자, 칸을 고르는 통계가 세 번 틀렸다
크몽 신규 판매자가 어느 칸에 gig을 올릴지 통계로 가리려다, 표본 편향과 순환논증 세 번, 검정 코드 버그 세 건을 차례로 잡았고 진입 후보는 4칸에서 1칸을 거쳐 0칸이 됐습니다. 남은 것은 칸을 바꿔도 얻을 게 없다는 결론과, 칸보다 판매자가 깐 gig 수가 판매를 가른다는 신호였습니다. 틀린 주장과 고친 과정을 그대로 적습니다.
AI 에이전트 무한 루프 감지, 같은 에러 기준이 놓친 반복
AI 에이전트 무한 루프는 “같은 에러가 3번 나오면 멈춘다”는 기준만으로는 막히지 않습니다. 에러 문구가 조금씩 바뀌면 기준에 걸리지 않고, 공개 사례에서는 결과가 똑같은 도구 호출이 58회 반복되는 동안 아무것도 알아채지 못했습니다. 저희는 반복을 에러 문자열이 아니라 도구 이름과 결과 앞 500자로 만든 지문으로 세고, 막아야 할 때는 반드시 종료 코드 2를 돌려주도록 검증 규칙을 고쳤습니다. 다만 규칙을 고친 뒤 처음 제대로 잰 숫자는 좋은 소식이 아니었습니다. 저희가 직접 만든 검사기가 적대적 입력 앞에서 거짓 통과 4건을 냈습니다.
CLAUDE.md 길이 제한을 지켜도 컨텍스트가 넘친 이유
CLAUDE.md 길이만 지키면 된다고 생각했지만, 세션을 무겁게 만든 주범은 CLAUDE.md가 아니라 로딩 조건이 빠진 규칙 파일들이었습니다. 2026년 9월 1일에 세션 시작 때 항상 실리는 글자를 세어 보니 149,842자였고, 그중 CLAUDE.md는 20,660자뿐이었습니다. 나머지는 “언제 읽을지”를 적어 두지 않아 매번 통째로 실리던 규칙 파일 9개와 메모리 파일이 차지하고 있었습니다.
WSL2 메모리 반환 안 됨, 4일 만에 PC 전체가 느려진 이유
WSL2 메모리 반환이 꺼져 있으면, PC를 오래 켜 둘수록 WSL이 쥔 메모리의 바닥이 올라가고 결국 Windows 전체가 느려질 수 있습니다. 저희 PC는 2026년 8월 17일 10:46에 켜서 8월 21일 07:51에 다시 켤 때까지 4일 5시간을 버텼고, 마지막에는 창 하나 넘기기도 힘들 만큼 느려졌습니다. .wslconfig 설정 파일에서 메모리 회수 설정(autoMemoryReclaim)이 통째로 빠져 있었습니다. 다만 이 설정 누락이 랙의 유일한 원인인지는 아직 확정하지 못했고, 그 사정까지 함께 적습니다.
WSL 메모리 부족 멈춤, OOM killer가 4시간 동안 못 죽인 프로세스
WSL 메모리 부족 사고는 커널 OOM killer에게 맡겨 두면 “빠른 죽음”이 아니라 “느린 마비”로 끝날 수 있습니다. 저희 PC에서는 프로세스 1개가 swap까지 합쳐 30GB대로 부풀었고, 커널이 그 프로세스를 새벽 02:00부터 06:07까지 10번 죽이려 했지만 메모리 사용량은 매번 그대로였습니다. 그 4시간 동안 같은 WSL 위에서 돌던 다른 작업도 전부 함께 멈췄습니다. 그래서 커널을 최후 방어선으로 믿지 않기로 하고, 1분마다 메모리를 재서 12GB에 닿으면 먼저 끊는 작은 감시 스크립트를 붙였습니다. 다만 이 감시 스크립트가 실제 상황에서 작동한 기록은 아직 0건입니다.
크롤링 키워드 선정 7일 실측, 슬래시 하나가 멈춘 채점
크롤링 키워드 선정은 넣을 때가 아니라 7일 뒤 다시 잴 때 결정됩니다. 새로 넣은 키워드 13개를 7일 동안 모아 보니 채널×키워드 9개 조합이 50건 이상 쌓이고도 적중 글이 0건이었고, 'A/B 테스트' 한 개는 이름에 든 슬래시 때문에 804건을 모으는 동안 채점이 한 번도 돌지 않았습니다.
스레드 게시물 수집, 좋아요 필터의 편향: 가장 닮은 글이 먼저 밀려났다
스레드 게시물 수집 도구에서 좋아요가 계정 중앙값 이상인 글만 남기는 필터는, 독자층이 바뀐 계정에서 저희와 가장 닮은 최근 글을 먼저 밀어냈습니다. 참고 계정 한 곳의 글을 시기별로 나눠 보니 창작자 시기 글은 좋아요가 400 안팎, 저희 업종과 닮은 2026년 B2B 시기 글은 100도 안 됐습니다. 필터를 기간 기준으로 바꾸자 원래는 보이지 않던 글 2건이 후보로 올라왔습니다.
코드 라인 수로 성장을 비교하지 않은 이유, 기준선을 다른 방식으로 셌다
코드 라인 수는 두 시점을 같은 방법으로 셌을 때만 성장의 증거가 되고, 우리 기준선은 그 조건을 채우지 못해 비교에서 뺐다. 2026년 8월 21일 기준선의 줄 수는 git이 추적하지 않는 파일까지 센 옛 방식이었고, 9월 15일에 센 1,143,445줄은 그 방식이 아니라서 둘을 빼면 방법 차이까지 성장처럼 잡힌다. 같은 기간 사람이 한 커밋은 4,612건에서 5,918건으로 1,306건 늘었지만, 그중 824건이 저장소 한 곳에서 나왔다.
채용공고 자동 수집 효과, 적합도 판정의 값은 3.7시간에 없었다
채용공고 자동 수집 작업이 아낀 시간은 목록 파일에 한 달 3.7시간으로 적혀 있지만, 이 값은 몇 번 돌았는지와 사람이 공고를 훑는 시간만 셀 뿐 적합도 판정이 맞았는지는 재지 않습니다. 매일 오전 7시 7분에 도는 작업의 최근 30일 실행 기록은 11회였고, 건당 20분은 검색·목록 훑기 12분과 상위 공고 열람·기록 8분을 더한 추정이었습니다.
리드 스코어링 오탐, '팔로우' 글자가 판매자 필터였다
리드 스코어링 규칙에서 진짜 구매 문의를 떨어뜨린 범인은 '팔로우' 버튼 글자였지만, 그 글자만 떼자 판매자 글까지 전부 통과했다. 원문으로 채점하면 8점인 문의가 수집본에서는 4점을 받아 문턱 5점 아래로 떨어졌고, 버튼 글자를 떼자 후보 35건이 모두 6~8점으로 올라갔다. 진짜 원인은 구매 표현을 문장의 성격과 떼어 센 규칙 세 곳이었고, 고친 뒤 한 번도 열어 보지 않은 표본 44건에서 정밀도가 0.37에서 0.68로 올랐다.
AI 자체 검증 정확도, 다시 확인시킬수록 떨어진 이유
AI 자체 검증 정확도는 에이전트에게 여러 번 다시 확인시키거나 여러 모델에게 동시에 판단을 맡길수록 오히려 떨어졌다. 강한 모델에게 스스로 다시 확인해 보라고 시켰더니 정확도가 26.8%에서 16.7%로 내려갔고, AI 넷이 모여 투표하는 방식도 토론을 거친 뒤 오히려 정확도가 낮아진다는 결과가 나왔다. 처음엔 여러 목소리를 모으면 판단이 정교해질 거라 가정했는데, 실제로는 정보가 사라지는 쪽으로 움직였다. 그래서 판단을 한 사람에게 모으고 실패 사례부터 직접 들여다보는 방식으로 기준을 다시 짰다.
MCP 서버 메모리, 창 하나에 428MB가 붙던 이유
MCP 서버 메모리는 원인이 안 꺼지는 프로세스가 아니라, 거의 쓰지 않는 서버까지 창을 열 때마다 전부 미리 띄우는 방식에 있었다. 실측해 보니 창 하나가 연결된 서버 3종 때문에 최소 276MB에서 최대 428MB를 쓰고 있었는데, 그중 하나는 최근 14일 동안 단 한 번도(0%) 쓰이지 않았다. 실제로 쓸 때만 서버를 켜는 중개 프로그램을 앞에 세운 뒤 창 하나당 메모리는 24MB로 줄었다.
설정값 드리프트, 주석은 8인데 코드는 이미 12였다
자동 답글 봇의 하루 발송 상한을 정해 둔 크론탭 주석이 실제 코드 값과 달라져 있는 설정값 드리프트가, 나흘 밀린 정기 점검에서 드러났습니다. 점검 자체는 다섯 가지 항목 모두 정상이라는 결론으로 끝났지만, 그 과정에서 발송 상한을 적어 둔 주석 문구가 이미 보름 전에 바뀐 실제 값을 따라가지 못하고 있다는 사실이 나왔습니다.
크론 모니터링, 업무대체형 70개 중 20개가 실행 0건이었다
크론 모니터링에서 확인해야 할 것은 목록에 등록됐는지가 아니라 실제로 실행됐는지입니다. SGK 스튜디오가 시간 절감을 말할 자격을 준 업무대체형 크론 70개를 대상으로 2026년 9월 14일 최근 30일 로그를 세어 보니, 그중 20개는 실행 흔적이 0건이었고 17개는 로그 형식이 서로 달라 횟수를 셀 수조차 없었습니다. 실제로 셀 수 있었던 크론은 70개 가운데 3분의 1을 조금 넘는 수뿐이었습니다.
카카오톡챗봇, 비즈니스 채널 없인 못 붙는 이유: 검사기가 놓친 문장 한 줄
카카오톡챗봇은 카카오톡 채널에 붙이는 순간부터 비즈니스 채널 전환을 전제로 하는데, 그 전제를 뒤집은 문장이 고객에게 나갈 회신과 제안서 마지막 장에 그대로 실려 있었다. 자동 검사 도구는 이미 카카오 관련 비용·무료 주장을 잡는 규칙을 3개나 갖고 있었는데도 이 문장을 통과시켰다. 원인은 두 가지가 겹쳐 있었다. 참고 문서를 한 층 얕게 읽은 것과, 검사 규칙이 잡던 문장 형태와 실제 문장의 형태가 서로 달랐던 것이다.
자동화 절감 시간 계산, 매일 도는 크론의 4.5시간은 무엇을 쟀나
자동화 절감 시간 계산에서 먼저 확인할 칸은 곱셈의 결과가 아니라 두 인수의 출처입니다. 매일 아침 외부 플랫폼 3곳을 훑는 크론 작업은 한 달 4.5시간을 아낀다고 적혀 있었지만, 그 값은 로그에서 센 실행 9회와 사람이 추정한 건당 30분을 곱한 결과였고, 작업이 실제로 무엇을 찾았는지는 계산에 들어 있지 않았습니다.
리포트 자동 발행 크론, 하루 1번인데 30일에 100회
리포트 자동 발행 크론에 적힌 최근 30일 실행 100회는 실행 횟수로 읽을 수 없는 숫자였습니다. 매일 오전 8시 20분에 한 번 도는 일정이라 30일 동안 30회가 상한인데, 자동화가 대신한 시간 150.0시간은 바로 이 100회에 건당 90분을 곱해 나왔습니다.
개인화 랜딩페이지 인원별 절감액, 결론에서 1명으로 돌아간 논증
개인화 랜딩페이지에서 인원별 절감액을 보여 줄 때 가장 먼저 무너진 곳은 계산식이 아니라 논증의 순서였습니다. 직원 수에 맞춰 숫자를 바꾸는 페이지를 배포한 날 대표 검수에서 지적 6건이 나왔고, 그 지적을 재현하는 동안 결함 2건을 더 찾았습니다. 고친 뒤 서버 렌더링 결과를 3가지 진입 경우로 다시 재 보니 같은 인원 카드 중복은 0건, “본전” 문구는 0회였고, 사례 소개 할인율 표기는 10~20%에서 실제 집행 근거가 있는 37~49%로 바뀌었습니다.
이메일 반송률과 SMTP RCPT 확인, 검증 통과 주소가 2배 더 반송됐다
이메일 반송률 8.3%를 끌어올린 주소는 출처가 불분명한 주소가 아니라 홈페이지 공식 주소로 확인된 주소였다. 판정별로 나눠 재 보니 공식 주소로 확인된 174건은 9.8%, 확인되지 않은 162건은 4.9%가 반송됐다. 그래서 공식 주소에만 보내자는 대책을 버리고, 발송 직전에 받는 쪽 메일 서버에 그 계정이 있는지 SMTP RCPT로 직접 묻는 검사를 넣었다. 이미 반송된 주소에 소급해 돌리자 48%를 걸러 냈고, 정상 주소는 한 건도 막지 않았다.
B2B 뉴스레터 벤치마크, 184통을 세어 보니 권위는 메일 밖에서 왔다
B2B 뉴스레터가 회사의 권위를 만든다는 가설은 절반만 맞았다. 본보기로 삼은 회계법인 마일스톤의 뉴스레터 184통을 전수로 세어 보니 메일 한 통의 본문은 130자, 배너는 두 장이 전부였고, 권위는 언론 인터뷰·기업 컨설팅·책·무료 세미나처럼 메일 밖에서 왔다. 뉴스레터가 한 일은 그 권위를 같은 사람에게 184번 실어 나른 일이었다. 그래서 뉴스레터를 권위를 쌓는 장치가 아니라, 이미 한 번 접촉한 사람을 다시 만나는 장치로만 도입했다.
업무 자동화 효과 측정, 다른 두 작업의 건당 40분이 똑같았다
업무 자동화 효과를 적어 둔 목록에서, 새벽 3시에 도는 브랜드 후보 발굴 작업과 새벽 2시에 도는 리드 이메일 수집 작업은 일정과 근거 문장만 다를 뿐 실행 8회·건당 40분·대체 시간 5.3시간까지 칸마다 같은 값이었습니다. 두 줄이 같은 값을 쓰는 이유는 목록 어디에도 적혀 있지 않았습니다. 따라가 보니 더 큰 빈칸이 따로 있었는데, 브랜드 후보 발굴은 후보를 «고르는» 일인데도 5.3시간은 몇 번 돌았는지만 세고 고른 결과가 쓸 만했는지는 재지 않았습니다.
AI 업무 자동화 절감 시간, 283.3시간 중 실측은 0시간이었다
AI 업무 자동화로 아낀 시간을 2026년 9월 12일 기준으로 모두 더하면 283.3시간이지만, 그중 사람이 직접 재 본 값은 0시간이었습니다. 283.3시간은 16개 항목, 246회 실행분을 «계산 과정을 적은 추정»으로 쌓은 숫자였고, 잴 방법조차 없는 17건은 0으로 세지 않고 합계에서 뺐습니다. 합계 하나로 말하면 이 차이가 사라지기 때문에, 근거 등급을 네 칸으로 갈라 따로 적습니다.
git 커밋 수가 부풀려진 이유
git 커밋 수로 개발 활동량을 재던 스크립트가 켠 “커밋 +636” 경보는 자동 커밋이 부풀린 숫자였고, 사람이 만든 커밋만 다시 세면 422건이었습니다. 한 저장소는 커밋 979개 중 947개가 스크립트가 남긴 자동 동기화 커밋이었고, 코드 줄 수도 16%가 git이 추적하지 않는 파일에서 나왔습니다. 경보가 옳다는 가설부터 확인해 원인을 좁히고, 자동 커밋을 목록으로 막았다가 세 번째 자동 커밋을 만나 감지기로 바꾼 과정을 적었습니다.
콜드메일 리드 이메일 수집 자동화, 매일 도는 작업이 30일에 8회였다
콜드메일 리드 이메일 수집 자동화가 아낀 시간은 저희 목록 파일에 한 달 5.3시간으로 적혀 있지만, 이 숫자를 이루는 세 값은 모두 아직 확인을 기다리는 상태였습니다. 매일 새벽 2시에 도는 작업인데 최근 30일 실행 기록은 8회였고, 건당 40분은 사람이 재 본 적 없는 추정이었으며, «한 건»이 무엇을 얼마나 처리하는지는 어디에도 적혀 있지 않았습니다.
AI 에이전트 역할 분담을 정한 기록
AI 에이전트 역할 분담을 문서 한 장으로 정리하면 끝날 줄 알았는데, 실제 결정 15건에 대입해 보니 6건을 그 자리에서 다시 고쳐야 했습니다. 여러 사업을 혼자 운영하면서 전략·운영·기술·제품을 맡을 여덟 개 역할을 나누고, 그 사이의 결정권을 처음으로 규칙에 못 박은 기록입니다. 표만 그려서는 부족했고, 정작 빠져 있던 건 결정 하나마다 번호와 받는 사람을 적어 두는 목록이었습니다.
프롬프트 인젝션 방어, 규칙 꺼지는 자리와 공격 들어오는 자리가 겹쳤다
프롬프트 인젝션 방어 규칙이 정작 가장 위험한 자리에서만 꺼져 있었습니다. 비용을 아끼려고 쓴 절약 실행 모드가 회사 규칙과 점검 절차를 통째로 건너뛰는데, 이 모드를 쓰는 자동화 작업 3개가 하필 외부 웹 콘텐츠를 그대로 읽어 들이는 자리와 정확히 겹쳤습니다. 처음에는 위협 탐지 함수 자체를 의심했지만 그 함수는 결백했고, 진짜 문제는 함수가 걸려 있지 않은 자리였습니다.
vmmem 메모리 과다 점유, 5분마다 자동으로 회수한 방법
vmmem 메모리 과다 점유는 상한을 고정한다고 해결되지 않았고, 오래 안 쓴 캐시만 골라 회수하는 방식으로 바꾸고 나서야 잡혔습니다. 저희는 처음에 메모리 상한(MemoryHigh)을 고정해 캐시를 묶어 두려 했는데, 그 기준으로 참고한 예전 기록의 '최대 3.83GB'가 실제로는 특정 순간의 단면이었고 7일 관측 최고치는 11.39GB였다는 사실이 뒤늦게 드러났습니다. 상한 대신 cgroup v2의 memory.reclaim 기능으로 오래된 캐시 페이지만 5분마다 자동으로 회수하도록 바꾸자 vmmem이 정상 범위로 돌아왔고, 회수한 캐시를 다시 읽는 비용까지 실측해 상시 실행이 안전하다는 근거를 확보했습니다.
우선순위 큐 버그로 멈춘 자동화 엔진을 되살린 기록
우선순위 큐 버그가 자동화 엔진을 12일 동안 사실상 세워 뒀습니다. 631회 실행 주기 중 412건(65%)이 실행 없이 자동으로 멈췄고, 그중 380건은 사람의 결정 하나를 기다리다 막혔습니다. 처음에는 원인을 자율 판단의 한계로 봤지만, 실제로는 작업 목록을 읽는 정규식과 순위를 매기는 기준, 정지 범위를 설계한 방식에 있던 배선 결함 3개였습니다.
AI 프롬프트 작성법, 지시가 짧아도 목적은 안 드러났다
AI 프롬프트 작성법이 부족했던 게 아니라, 실행 전에 확인해야 할 정보 세 가지가 통째로 빠져 있었다. 최근 1개월 프롬프트 1,827건을 세어 보니 세션 첫 지시의 68%가 100자 미만이었고, 목적이나 판정 기준을 미리 적어 둔 경우는 1.8%뿐이었다. 사람에게 더 자세히 쓰라고 요구하는 방법을 먼저 시도했지만, 실제 사고는 그 방법으로는 못 잡는 자리에서 났다.
AI 판례 검색 오류, 0건이 '없다'는 뜻은 아니었다
AI 판례 검색 오류 하나가 실제로 있는 판례를 '없음'으로 잘못 결론지을 뻔한 일이 있었다. 채무 분쟁 사안에서 '가사채무 연대책임'이라는 복합 키워드로 판례를 검색했더니 결과가 0건이었고, 그 0건을 그대로 믿었다면 판례가 없다는 잘못된 진단이 그대로 나갈 뻔했다. 원인은 판례가 실제로 없어서가 아니라 검색어를 너무 복합적으로 넣은 데 있었고, 단어를 쪼개 '배우자 채무'로 다시 검색하자 같은 사안에서 85건이 나왔다.
무한 스크롤 크롤링, 종료 로그를 믿었더니 실제론 10배가 있었다
무한 스크롤 크롤링에서 수집 프로그램이 스스로 찍은 '바닥 도달'이라는 종료 로그를 그대로 믿었다가, 실제로는 열 배 넘는 게시물을 두고 온 사실을 뒤늦게 알았다. 특정 계정 하나가 24건에서 멈춘 것을 보고 '프로필 화면 스크롤로는 과거 글을 전부 가져올 수 없다'고 판정해 분석 보고서에까지 한계로 적었지만, 같은 시스템 안에 이미 400일 넘게 운영해 온 계정을 3회 만에 전량 수집한 사례가 두 건 있었다. 파라미터만 바꿔 다시 실행하자 253건이 나왔고, 스크롤 횟수 제한을 더 늘리자 1,902건까지 나왔다.
크롤링 게시일 판별 오류, 27일 된 글이 신규로 잡혔다
크롤링 게시일 판별 오류 하나가 27일 전에 올라온 글을 방금 올라온 글로 둔갑시켜, 24시간 신선도 게이트를 통과시키고 있었다. 스레드에서 잠재 고객 글을 찾아 답글 초안까지 준비하는 파이썬 프로그램을 만들다가 발견한 문제였고, 게이트를 통과한 후보 2건 가운데 1건이 이 오류가 만든 가짜 신규 글이었다. 원인은 '3일 전'처럼 상대적으로 적은 날짜 표기가 긁어 온 시점을 기준으로 코퍼스에 그대로 굳어 버린다는 데 있었다.
생존자 편향 없이 비교한 손절 규칙, 승률 붕괴의 원인
실거래 승률이 55.6%에서 10.7%로 무너진 진짜 원인은 종목 선택이 아니라 손실 관리 방식에 있었습니다. 이 결론은 생존자 편향(살아남은 사례만 보고 판단해 실패 사례를 놓치는 오류)을 피하려고, 이미 한 번 이상 실전 매매 대회 상위권에 든 사람들끼리만 비교하는 방식으로 검증했습니다. 국내 한 증권사가 매달 발표하는 실전 매매 대회 상위 200명 데이터에서, 반복해서 상위권에 오르는 79명과 한 번만 오른 897명의 실제 매매 기록 28,100건을 비교한 결과입니다.
위탁판매 마진 계산: 22건 전수 채점, 통과 0건
위탁판매 마진 계산을 광고비 최저가까지 넣어서 다시 하자, 팔 만하다고 여겼던 상품 22개 중 통과한 것이 하나도 없었다. 소비자에게 직접 파는 상품 후보를 기계로 전수 채점했더니 기각선 18점 만점에 12점을 넘은 건이 0건이었고, 최고점도 9점에 그쳤다. 원인은 상품이 나빠서가 아니라, 광고 없이는 팔리지 않는 시장에서 광고비를 감당할 마진이 안 나왔기 때문이었다.
챗봇 상담 자동 검수, 위반만 잡으면 충분한 줄 알았다
챗봇 상담 자동 검수는 위반 문구를 잡아내는 검사만으로는 끝나지 않았고, 정상적으로 나갈 초안까지 같은 검사에 넣어봐야 검사 도구 자체의 결함이 드러났습니다. SGK 스튜디오는 카카오톡 채널 상담봇·접수봇 문의를 반복해서 받으면서 매번 공식 문서를 처음부터 다시 조사했고, 조사할 때마다 답이 조금씩 달라졌습니다. 위반을 심은 초안 15건을 전부 잡아내는 검사 도구를 만들고 나서 검수가 끝났다고 판단했지만, 실제로 발송 대기 중이던 정상 초안 한 건을 같은 도구에 넣어보니 그제서야 도구 자체의 결함이 나타났습니다.
AI 제안서 검수, 고친 숫자가 표에는 남아 있었다
AI 제안서 검수는 한 번 고친 숫자를 다시 확인하는 일까지 포함해야 끝난다. 리걸테크 스타트업 고객사에게 보낼 아웃바운드 영업 제안서에서 발송량 숫자가 틀렸던 것을 한 번 고쳤는데, 문서 안의 다른 표에는 그 수정이 반영되지 않은 채 남아 있었다. 서로 다른 관점을 가진 AI 에이전트 네 개를 병렬로 돌려 같은 문서를 다시 훑게 한 뒤에야 그 사실이 드러났다.
개발자 생산성 측정, 커밋 수만 늘어서는 안 보였다
개발자 생산성 측정은 커밋 수나 코드 줄 수를 세는 일로는 끝나지 않았습니다. SGK 스튜디오를 포함해 마흔 개가 넘는 코드 저장소를 혼자 운영하면서, 2026년 8월 21일과 9월 8일 두 시점에 저장소·커밋·코드 줄 수 그리고 업무 지침서·자동 검사 프로그램·자동 실행 스크립트 규모를 각각 재서 비교했습니다. 저장소는 42개에서 45개로, 커밋은 5,608개에서 7,305개로, 코드는 109만 줄에서 132만 줄로 늘었지만, 정작 가장 많이 늘어난 항목은 지침서가 아니라 자동 검사 프로그램이었습니다.
스레드 게시물 조회수 측정, 79건 동안 한 번도 재지 않았다
스레드 게시물 조회수를 측정할 방법이 자동 발행 프로그램 안에 아예 없었습니다. SGK 스튜디오가 스레드에 글 79건을 자동으로 올리는 29일 동안 좋아요는 거의 0에 머물렀는데, 그 글이 애초에 안 읽혀서 반응이 없는 것인지 읽혔는데도 반응이 없는 것인지 구분할 지표 자체가 없었습니다. 코드에는 '조회수는 원천적으로 수집할 수 없다'는 메모가 이미 적혀 있었고, 그 메모를 26일째 아무도 다시 열어 보지 않았습니다.
5분봉 백테스트가 −69%로 무너진 이유, 원인은 레짐이 아니었다
5분봉 백테스트가 5년치 구간에서 −69%까지 무너진 원인은 시장 상황이 아니라 데이터 단위(타임프레임) 자체에 있었습니다. 자동매매 전략을 하락장·횡보장·상승장 여러 국면에서 검증하려던 개발자는 1분봉 데이터가 2024년 4월 18일 이후분만 남아 있다는 사실을 확인하고, 더 오래 남아 있는 5분봉(2021년 4월~2026년 5월, 2,689개 종목)으로 같은 검증을 시도했습니다. 그런데 이 5분봉 백테스트가 대참사에 가까운 손실을 내면서, 문제가 전략 자체인지 데이터 단위인지를 가리는 조사가 시작됐습니다.
자동매매 청산 전략 실측, 적자에서 흑자로 뒤집힌 이유
자동매매 청산 전략을 실측한 결과, 문제는 매수 신호가 아니라 포지션을 정리하는 방식에 있었습니다. 급등 후 눌림목 매수 전략(SurgePullback)과 볼린저밴드 스퀴즈 전략(BBSqueeze)으로 2026년 5월 13일부터 8월 24일까지 쌓인 실거래 165건을 청산 사유별로 나눠 보니, 목표가 도달 익절 52건은 승률 76.9%로 240.1%를 벌었고 손절 계열 113건은 280.8%를 잃었습니다. 왕복 거래 비용 0.23%를 반영한 건당 기대수익은 −0.478%, 누적으로는 −40.9%였습니다.
AI 법령 인용 검증, 5개국 중 3개국이 없는 법이었다
AI 법령 인용 검증을 검색 횟수로 대신하면 존재하지 않는 법이 고객 메일에 그대로 실린다. 해외 다섯 나라의 광고 메일 규제를 정리한 회신 초안에서 세 나라가 틀렸다. 태국은 아예 없는 법 이름이었고, 아랍에미리트는 번호는 실재하지만 광고 메일과 무관한 사이버범죄법이었고, 사우디는 대형 로펌 공개 해설과 정면으로 어긋나는 숫자였다. 세 건의 근거는 전부 규제 준수 도구 판매사의 블로그와 검색 결과 요약이었다.
canonical 태그 통합 대상 29편, 실제로 묶은 건 4편이었다
canonical 태그로 묶을 대상을 “제목이 같은 말로 시작한다”는 조건으로 세면 29편이 걸립니다. 그 29편을 한 편씩 열자 성격이 다른 셋이 섞여 있었습니다. 이미 평균 3.7위로 검색 결과 첫 화면에 올라간 글 1편, “병원홈페이지제작”처럼 다른 검색어를 노리는 업종별 글 5편, 발행한 지 21일이 안 돼 성과를 판정할 데이터 자체가 없는 글 19편입니다. 남은 4편만 묶었고, 그 4편은 전부 28일 노출 2 이하에 클릭 0건이었습니다.
검색광고 전환율 9.8%는 남의 숫자였다, 실측은 0.75%
검색광고 전환율을 남의 평균값으로 두면 감당 못 할 키워드에 계속 입찰하게 된다. 30일 동안 490,559원을 써서 265클릭을 사고 상담 신청 2건·계약 0건이 나온 뒤에야, 우리 계산기에 들어 있던 9.8%가 업계 벤치마크였고 자체 실측은 0.75%라는 사실을 확인했다. 처음 의심한 광고 설정 결함은 알리바이가 있었다.
네이버 블로그 글자수, 요약형 원고 47편은 발행해도 소용이 없었다
네이버 블로그 글자수를 재고 나서, 발행 준비를 마쳤다고 부르던 원고 47편이 사실은 발행해도 아무 일이 일어나지 않는 상태였음을 확인했다. 우리가 노리는 검색어의 상위 노출 글 9건은 본문이 중앙 3,299자였고, 우리 원고는 1,033자로 상위 하한 1,966자의 절반을 겨우 넘었다. 새 원고를 한 편도 쓰지 않고 형식만 바꿔 중앙 2,101자까지 올린 기록이다.
SEO 카니발라이제이션, 18편이 순위를 나눠 먹는다는 진단이 틀렸다
SEO 카니발라이제이션을 원인으로 지목했다가 집행 직전에 되돌렸다. 서비스 소개 글 89편의 28일 노출은 82건, 클릭은 2건이었고 같은 기간 세무 정보 글 12편은 202건으로 편당 16.8건이었다. 격차의 원인을 '같은 검색어를 노린 18편이 서로 순위를 갉아먹는다'로 봤는데, 검색어별로 다시 뽑아 보니 노리던 검색어에서 노출이 0건이었다. 나눠 먹으려면 일단 그 자리에 나타나야 한다.
콘텐츠 자동화 파이프라인 0편, 소재는 3건 쌓여 있었다
콘텐츠 자동화 파이프라인이 한 편도 못 낸 원인은 재료 부족이 아니라 파일 경로 표기와 점수 정렬 두 가지였다. 글감을 모으는 쪽에는 새 후보가 3건 쌓여 있었지만 그 후보를 꺼내 읽는 쪽은 경로를 열 수조차 없었고, 열렸더라도 본문 길이에 걸린 30점 때문에 126점에서 128점짜리 기존 후보를 이길 수 없었다. 그래서 라이브 9편이 전부 한 축에서 나왔다.
크론 실패 감지, 감시기가 4일 내내 정상이라고 말했다
“크론 실패 감지”를 로그 갱신 시각으로만 하면, 실패하는 작업일수록 더 건강해 보입니다. 집에서 회사로 작업 파일을 밀어 넣는 백업이 2026년 8월 7일부터 4일 동안 45회 연속 실패했는데, 그 기간 내내 감시 스크립트 판정은 “정상 · 0.1시간 전 갱신”이었습니다. 30분마다 실패하면서 실패했다고 로그에 적었으니 파일은 계속 새것이었기 때문입니다. 이 글은 그 구멍을 메운 과정과, 같은 종류의 구멍을 반복해 찾아내는 절차를 검사 축 아홉 개·절차 일곱 단계로 고정한 기록입니다.
네이버 검색 API 정렬, 수집은 되는데 쓸 후보가 0건이었던 이유
네이버 검색 API 정렬 옵션 하나가 답변 후보 선정 0건의 원인이었다. 같은 키워드를 최신순으로 조회하면 10건 중 3건만 질문과 관련이 있었는데, 관련도순으로 바꾸자 10건 중 10건이 관련 질문이었다. 손도 대지 않은 후보가 1,414건 쌓여 있었고, 그때까지 누적 수집한 631건의 2.2배였다.
웹 스크래핑 URL 누락, 범인은 하나가 아니라 셋이었다
“웹 스크래핑 URL 누락”의 원인은 수집기가 아니었습니다. 수집기는 7월 23일부터 원글 주소를 100% 담고 있었고, 주소가 사라진 자리는 그 뒤쪽 세 군데였습니다. 처음 잰 숫자는 후보 20건 중 자동 심사 통과 0건이었고, 세 군데를 다 막고 나서 2건이 됐습니다. 한 군데만 고쳤다면 숫자는 그대로였을 겁니다.
콜드메일 회신율: 클릭 27건, 문의 0건의 진짜 원인
콜드메일 회신율을 막고 있던 범인은 링크도 계측도 아니었다. 한 통이 받는 사람에게 정정과 클릭과 회신을 동시에 요구하고 있었고, 그중 가장 부담 없는 클릭만 남았다. 같은 문구로 669통을 보내 클릭 27건(4.2%)이 나왔지만 그 클릭에서 넘어온 문의는 0건이다.
AI 글쓰기 전문성이 안 나온 이유, 검사기가 아니라 재료였다
“AI 글쓰기 전문성”이 안 살아난 원인은 검사기가 아니라 재료였습니다. 자동으로 써서 올린 글 68건 가운데 64건, 그러니까 94퍼센트에 기술 어휘가 한 개도 없었습니다. 처음에는 출력 단계의 어휘 검사기가 전문 용어를 반려한다고 봤지만, 로그를 열자 실제 반려는 2회뿐이었습니다. 그 가설이 깨진 자리에서 발행 68건의 출처를 다시 세어 보니 결정 기록 32건·측정 기록 26건·자산 문서 7건·원고 3건이었고, 코드에서 온 재료는 0건이었습니다.
AI 문서 작성 규칙, 사내 문서 지적 35건을 세 축으로 갈랐다
AI 문서 작성 규칙에서 가장 크게 잡힌 결함은 문장력이 아니라 맥락이었습니다. AI가 대신 쓴 사내 질의서 한 건을 세 개 축으로 갈라 세어 보니 작업 대화 내용이 그대로 새어 나간 자리가 14건, 기계 말투가 13건, 가독성 결함이 8건이었습니다. 저희가 처음 세운 처방은 문장을 다듬는 쪽이었고, 그 처방으로는 가장 큰 축이 한 건도 줄지 않았습니다. 지적을 항목별로 세고 상한을 정한 다음, 발송 전 검사를 명령 하나로 묶기까지의 기록입니다.
AI 이미지 생성 글자 깨짐, 원인은 도구가 아니라 층 구분이었다
AI 이미지 생성 글자 깨짐의 원인은 모델이 한글을 못 써서가 아니라, 카드 한 장을 통째로 한 도구에 맡긴 데 있었다. SGK 스튜디오는 카드뉴스와 썸네일, 상세페이지 같은 산출물을 AI 에이전트 팀이 나눠 만드는 파이프라인으로 찍어내는데, 글자가 이미지에 얹히는 순간 결과가 두 방향으로 갈라졌다. 참고로 삼은 계정들의 카드 24개를 전부 열어 세어 보니 텍스트만으로 된 카드는 0개였고, 그 숫자 하나에 '전부 브라우저 렌더로 만들면 품질에서 앞선다'던 1차 판정이 무너졌다.
설정 추가했는데 반영 안 됨, 하드코딩 사본이 3주간 감춘 리포트 섹션
“설정 추가했는데 반영 안 됨”의 원인은 설정을 읽는 쪽이 아니라 결과를 내보내는 쪽이었습니다. 2026년 7월 21일에 분야 하나를 설정 파일에 넣었는데 그 뒤 3주 넘게 자동 리포트 8개 파일 어디에도 해당 섹션이 없었습니다. 저희가 처음 세운 가설은 “그 분야는 시장에 신호가 없다”였고, 분류 함수만 따로 돌려 보자 7건이 잡히며 그 가설이 깨졌습니다. 분류는 설정 파일을 그대로 훑는데 출력은 이름 5개를 손으로 적어 둔 사본을 보고 있었습니다.
스레드 바이럴 유형 실측, 실패담은 오히려 지는 쪽이었다
스레드 바이럴을 만드는 유형은 실패담도 경험담 평문도 아니었다. 스레드 원글 42,661건·작성자 8,344명을 같은 작성자·같은 수집 경로·길이 ±25% 안에서 짝지어 재니, 우리가 절반씩 쓰던 두 유형은 짝을 이겼다고 말할 근거가 없었고 실패·자백은 짝에서 지는 쪽이 더 많았다(234대 257). 우리 발행분 53건을 같은 자로 재 보니 실패·자백이 41.5%로, 코퍼스 비중 1.8%의 23배였다.
AI 에이전트 확인 없이 답변, 같은 값을 물을 때마다 달랐다
AI 에이전트 확인 없이 답변은 겉보기엔 사실 같았다. 자동매매 전략 코드의 손절 설정값을 물었더니 답이 매번 달랐다. 어떤 때는 -1.5%, 어떤 때는 -2.5%였다. 처음엔 에이전트가 아예 확인을 안 하고 찍어서 말한다고 의심했다. 그런데 실제 기록을 열어 보니 파일 경로가 붙은 진짜 근거가 있었다. 근거를 댔는데도 왜 계속 틀렸는지, 그 답을 어떻게 고쳤는지를 순서대로 적는다.
AI 번역체 자동 검사, 고치라고 시켰더니 더 심해졌다
AI 번역체 자동 검사를 만든 이유는 한 문장으로 설명된다. 모델에게 자연스럽게 쓰라고 프롬프트에 적어 넣는 방법은 효과가 없었고, 오히려 번역체를 늘렸다. SGK 스튜디오는 AI 에이전트가 만든 한국어 문서를 고객과 거래처에 그대로 내보내다가, 문장 속에 영어 문형을 그대로 옮긴 표현이 섞여 나가는 문제를 발견했다. 처음에는 프롬프트에 '자연스럽게'라는 말 한마디만 더하면 될 것 같았지만, 실제로 프롬프트 조건별 번역체 비율을 잰 연구를 대조하자 정반대 결과가 나왔다. 그래서 생성 지시를 강화하는 대신, 다 쓴 결과만 따로 검사하고 고치는 별도 패스로 설계를 완전히 바꿨다.
AI 에이전트 오판, 원인은 계정 레이어 확인 누락이었다
AI 에이전트 오판은 설정 화면 하나만 보고 '공식 경로가 없다'고 결론 내릴 때 일어났습니다. 블로그 계정을 대신 관리할 방법을 찾다가 화면에 그 기능이 안 보인다는 이유만으로 '위임 경로 자체가 없다'고 판단해 판매 상품 하나를 접었는데, 실제로는 계정 종류를 하나 더 확인했어야 했습니다. 이 판단이 어디서 갈렸는지, 확인 수단을 어떻게 다시 검증했는지, 같은 실수를 막으려고 어떤 절차를 새로 세웠는지를 정리했습니다.
AI 에이전트 스킬 재사용률 24%, 원인은 회수 배선 부재였다
AI 에이전트 스킬 재사용률을 처음 재보니 승격해 둔 스킬 17개 중 실제로 다시 불려 쓰인 것은 4개, 24%뿐이었습니다. 이 회사는 사람이 에이전트 작업에 얼마나 개입하는지, 실패에서 얼마나 스스로 회복하는지 같은 자율성 지표를 다섯 가지로 정의해 두고 있었는데, 실제로 첫 측정까지 마친 것은 이 하나뿐이었습니다. 정식으로 등록했으니 자연히 다시 쓰일 거라 짐작했던 가정이 왜 빗나갔는지, 원인을 찾아 손을 본 뒤에도 왜 아직 다시 재지 못했는지를 그대로 적었습니다.
서비스 종료 결정 기준, 시작할 때만 있고 접을 때는 없었다
서비스 종료 결정 기준은 시작할 때만 있었고 그만둘 때는 없었다는 데 있었다. SGK 스튜디오는 새 판매 상품을 시작하기 전에 수요와 허용 여부를 확인하는 절차를 AI 에이전트에게 맡기고 있었는데, 이미 하던 서비스를 그만두는 결정에는 같은 확인 절차가 전혀 없었다. 판매 상품 하나가 근거를 다시 볼 시간도 없이 발견한 날 그만두기로 결정되고 고객 통지까지 나간 뒤에야, 조사 품질이 아니라 절차 자체의 무게가 한쪽으로만 쏠려 있었다는 사실이 드러났다.
AI 에이전트 인수인계 자동화, 손으로 하면 4번 중 3번 깨졌다
AI 에이전트 인수인계 자동화를 손으로 하면 넷 중 셋이 깨진다는 사실을 실제 사고로 확인했습니다. SGK 스튜디오가 AI 에이전트에게 업무를 맡기고 세션이 끝날 때마다 다음 세션에게 넘기는 인계 문서를 손으로 발급했더니, 파일 이름이 하나뿐이라 새 인계 문서가 저장되는 순간 아직 쓰이지 않은 직전 인계 문서를 덮어썼습니다. 원인은 사람의 부주의가 아니라 파일 하나에 여러 축을 겹쳐 쓰게 만든 설계였고, 이 사실을 확인한 뒤 손으로 쓰는 절차를 명령 하나로 바꿨습니다.
LLM 비용 절감, 토큰 427K를 104K로 줄인 기록
LLM 비용 절감은 모델을 바꾸는 일이 아니라 프롬프트에 무엇을 넣을지 다시 정하는 일이었습니다. 한 금융투자업 회사의 금융투자 광고 컴플라이언스 자동 검토 시스템은 심사 룰 베이스를 수백 개 규모로 10배 이상 넓히면서, 매 건 심사마다 그 룰 전체를 LLM에 통째로 넣고 있었습니다. 이 방식이 입력 토큰 427K짜리 요청을 만들었습니다. 광고 콘텐츠 한 건에 실제로 걸리는 룰만 경량 모델이 먼저 골라 넣는 RAG 라우터를 넣은 뒤, 같은 방식으로 다시 재니 입력 토큰은 104K로, 총 비용은 54% 줄었습니다. 이 글은 그 사이에 세운 가설과 틀린 지점, 골든 케이스 24개로 회귀를 감시한 과정을 적은 기록입니다.
크론 168개, 시간 절감 측정법이 따로 있었다
크론(정해진 시각마다 자동으로 실행되는 작업) 168개를 전부 자동화라고 부르면 숫자가 부풀고, 시간 절감 측정법은 크론의 성격별로 따로 있어야 한다는 사실이 실제로 세어 보고서야 드러났습니다. 사람이 하던 일을 대신하는 크론과, 사람이 원래 안 하던 일을 감시하는 크론, 손이 아니라 판단만 앞당기는 크론은 같은 방식으로 셀 수 없습니다. 168개 중 시간 절감을 말할 자격은 업무대체 70개에만 있었고, 그중에서도 비교 기준을 갖춘 것은 3개였습니다. 그 3개를 직접 열어 실행 횟수와 사람이 같은 일을 했을 때 걸리는 시간을 다시 잰 기록을 남깁니다.
브라우저 자동화 표 삽입 실패, 원인은 클릭 순서였다
브라우저 자동화 표 삽입 실패의 진짜 원인은 화면이 아니라 명령을 쪼개어 보내는 방식에 있었습니다. 저희는 네이버 블로그에 글을 자동으로 올리는 프로그램으로 표가 든 글을 발행하다가, 마크다운 표가 편집창에서 표로 바뀌지 않고 텍스트 그대로 남는 일을 반복해서 만났습니다. 화면 좌표를 다시 재고 클릭 위치를 몇 번이나 고쳐도 결과는 같았습니다. 원인을 찾고 보니 문제는 좌표가 아니라, 마우스와 키보드를 흉내 내는 명령 하나하나가 서로 완전히 독립된 프로그램 실행이라는 점이었습니다. 키를 누른 채 유지해야 하는 동작이 명령과 명령 사이에서 풀려 버리고 있었습니다.
업무 자동화 효과 측정, 크론 168개 중 70개만 셈에 넣었다
업무 자동화 효과 측정은 크론 개수를 그대로 더하는 일이 아니라 그 개수 중 무엇을 셀 자격이 있는지 가르는 일이었습니다. SGK 스튜디오가 2026년 9월 3일 기준으로 등록해 둔 크론은 168개였고, 이 숫자를 그대로 '168개를 자동화했다'고 쓰면 절반 가까이가 다른 이야기를 하고 있었습니다. 168개를 성격별로 나누자 업무대체 70개, 감시 45개, 보고 35개, 위생 17개, 미분류 1개로 갈렸고, 시간 절감을 말할 자격이 있는 것은 업무대체 70개뿐이었습니다. 그 70개 중에서도 비교 기준을 갖춘 것은 3개였고, 이 글은 그 3개를 실측해 합산한 128.9시간이 왜 아직 추정으로만 남아 있는지 적은 기록입니다.
유튜브 자동 수집 IP 차단, 원인은 새 스크립트 하나였다
유튜브 자동 수집 IP 차단은 스크립트 하나의 실수가 아니라, 프로그램마다 요청 속도를 알아서 절제하게 둔 설계 자체의 문제였습니다. SGK 스튜디오는 유튜브 영상을 자막과 화면으로 훑어 요약하는 자동화 프로그램을 여러 개 운영하는데, 이 프로그램들이 같은 컴퓨터의 인터넷 주소를 함께 쓰다 보니 하나가 짧은 시간에 지나치게 자주 요청을 보내면 유튜브가 그 주소 전체를 막아 다른 프로그램의 수집까지 함께 멈췄습니다. 채널을 대량으로 자막까지 훑는 프로그램과, 감시할 채널을 스스로 찾아내는 새 프로그램에서 원인은 서로 달랐지만 결과는 같았습니다. 공용 관문을 프로그램마다 알아서 통과하게 두면 언젠가 하나는 그 관문을 빠뜨린다는 것이었습니다.
구글플레이 평점 개선, 4.0점을 4.7점으로 올린 기록
구글플레이 평점 개선은 별점 대응이 아니라 고객 목소리를 모으는 시스템을 다시 짜는 일이었습니다. 핀테크 투자자문사에서 로보어드바이저 앱을 운영하며 마주한 Google Play 평점은 4.0점이었고, 자문계약 고객 4,300명이 넘는 규모에서는 개별 상담만으로 이 숫자가 움직이지 않았습니다. Zendesk 기반 VoC 시스템으로 고객 목소리를 체계적으로 모은 뒤에야 평점은 4.7점으로, 계좌 개설 시도율은 2.44배로 올랐습니다. 이 글은 그 사이에 세운 가설과 틀린 지점, 그리고 같은 원리가 지금 소프트웨어 품질 규칙으로 어떻게 코드화됐는지를 적은 기록입니다.
AI 에이전트 스펙 검증, 설계서를 새 세션이 못 찾은 이유
AI 에이전트 스펙 검증이 놓친 자리는 스펙의 내용이 아니라 스펙으로 가는 길이었습니다. 2026년 7월 25일 설계서 작성을 마치고 '한 줄만 치면 구현이 시작된다'고 안내했는데, 새로 연 세션은 그 한 줄로 설계서를 찾지 못했습니다. 처음에는 규칙이 가리키는 대로 스펙이 부실하다고 의심했고, 그 가설은 명령 두 줄의 결과 앞에서 무너졌습니다. 이 글은 그 진단이 어디서 틀렸고 무엇을 고쳤는지, 그리고 같은 종류의 실수를 스펙 검토 단계에서 어떻게 막기로 했는지의 기록입니다.
AI 에이전트 체크포인트, 2시간에서 30~40분으로
AI 에이전트 체크포인트 간격을 2시간으로 잡은 규칙은 첫 판부터 늦은 경계였고, 외부 실측을 들여오자 30~40분 세그먼트로 내려갔습니다. 같은 규칙에서 첫 사이클 안전장치로 넣은 60초 대기도 실측 뒤 0초로 줄일 수 있다는 줄이 붙었습니다. 안전은 멈춰서 묻는 데서 오지 않았고, 표류를 막는 목표 낭독과 기계 검증, 그리고 사이클마다 남기는 커밋에서 왔습니다. 그 규칙을 2026년 4월 29일부터 8월까지 고쳐 쓴 전후를 그대로 적습니다.
Claude Code hooks 오탐, 설명 요청을 작업으로 읽은 앵커 한 글자
Claude Code hooks 오탐의 원인은 정규식 첫머리 앵커 한 글자였습니다. 세션 첫 지시에서 에이전트가 한 번만 일하고 멈추는 증상을 잡으려고 훅을 배선한 다음 날, '조금 더 쉽게 설명해줘'라는 설명 요청을 훅이 작업 지시로 읽었습니다. 고친 뒤 세션 첫 프롬프트 1,123건을 다시 돌리니 작업 아님 판정이 55건에서 59건으로 늘고 나머지 수치는 그대로였습니다. 그 훅이 왜 있어야 했는지, 첫 진단이 어디서 틀렸는지부터 순서대로 적습니다.
Claude Code 병렬 세션의 기록 유실 12건을 0건으로
Claude Code 병렬 세션이 공유 문서를 서로 지우던 문제는 락이 아니라 '통째 다시 쓰기'라는 구조를 바꾸자 멈췄습니다. 30개 저장소 소급 감사에서 영구 유실 12건은 전부 가드 배선 이전이었고, 배선 이후는 0건입니다. 반면 번호 충돌은 락을 걸고도 3건이 더 났고, 발급기를 만든 뒤에도 경로 하나 때문에 한 번 더 겹쳤습니다.
git status 정리, 파일 571개를 한 자릿수로 줄인 기록
git status 정리는 무시 규칙을 몇 줄 보태는 일이 아니라 저장소가 무엇을 추적해야 하는지 다시 정하는 일이었습니다. 이미지와 초안을 스크립트가 매일 만들어 떨어뜨리는 저장소에서 git status가 571줄을 뱉었고, 임시 파일과 렌더 출력을 무시하는 규칙을 두 번 넣었는데도 노이즈는 줄지 않았습니다. 2026년 7월 2일 커밋에서 생성 산출물 폴더를 무시하고 cron이 고쳐 쓰는 상태 파일 4개를 추적에서 빼자 571줄이 한 자릿수로 내려갔습니다. 이 글은 왜 앞의 두 조치가 틀렸는지, 두 종류의 노이즈가 어떻게 다른지, 그리고 무엇이 끝내 줄지 않았는지의 기록입니다.
AI 에이전트 승인 게이트를 4개로 줄인 기록
AI 에이전트 승인 게이트를 늘릴수록 안전해지지 않았고, 사람이 답을 받아 적는 시간만 늘었습니다. 게이트를 4개로 끊고 나머지를 전부 자율로 내린 뒤 규칙 문서에 남은 결정 이력은 8건이고, 그 가운데 두 번은 저희 가설이 정면으로 반증된 기록입니다. 승인 프롬프트가 안전을 만든다는 전제부터 틀렸습니다.
Claude Code 자율 실행은 왜 한 턴 만에 멈추나
Claude Code 자율 실행은 같은 도구, 같은 모델인데 어떤 세션은 도구를 190번 쓰고 끝까지 가고 어떤 세션은 1번 쓰고 멈춥니다. 원인이 프롬프트 길이라고 생각했습니다. 21일치 3,161턴을 세어 보니 절반만 맞았고, 틀린 절반이 처방을 통째로 바꿨습니다.
pytest ERROR 1,300건은 버그가 아니었다
pytest ERROR 가 1,289건 나왔습니다. 코드를 한 줄도 안 고치고 다시 돌리니 1,516건, 한 번 더 돌리니 2,173건이었습니다. 처음 지목한 범인은 알리바이가 있었고, 진짜 원인은 코드가 아니라 코드를 재는 도구 안에 있었습니다.
SEO 콘텐츠 88편의 노출이 안 붙은 원인
SEO 콘텐츠 노출을 늘리려고 발행량을 키우는 동안, 판매 서비스로 이어지는 글의 편당 노출은 2.6에서 0.9로 오히려 떨어졌습니다. 처음 지목한 원인은 같은 키워드에 열여섯 편이 쌓인 콘텐츠 중복이었지만, 155개 키워드의 검색량과 광고 입찰가를 다시 대조하고서야 그건 2차 요인이었다는 것이 드러났습니다. 진짜 원인과, 그 과정에서 함께 발견한 두 번의 죽은 계측을 그대로 적습니다.