스스로 개선하는 AI 운영을 설계한다면: 실패 기록에서 다음 검증까지

자동화를 만들면 다음 질문이 생긴다. 정해 놓은 일을 반복하는 데서 끝나지 않고, 자주 실패하는 부분을 찾아 다음 실행을 더 낫게 만들 수 있을까. 블로그라면 출처가 빠진 원고, 같은 자료를 찾지 못하는 검색, 공개 상태가 어긋나는 발행을 반복하지 않게 하는 일이다.

YC Root Access의 「How to Build a Self-Improving Company with AI」라는 영상은 이 질문을 회사 운영의 규모로 생각하게 한다. 여기서는 영상의 제목과 원출처를 확인했으며, 세부 발언이나 내부 운영을 검증한 사례 보고로 사용하지 않는다. 아래 내용은 이 질문을 작은 블로그 운영으로 옮긴 설계안이다. 야간에 코드를 만들고 검토와 배포까지 자동으로 끝내는 시스템을 이미 운영한다는 뜻은 아니다. YC Root Access 원영상

개선의 단위를 오류 하나와 재현 가능한 입력으로 잡는다

‘독자가 좋아할 글을 더 써라’는 목표는 넓다. 결과가 달라져도 무엇 때문에 좋아졌는지 알기 어렵다. 시작할 문제는 더 작게 잡겠다. 원문 링크가 저장되지 않아 같은 자료를 다시 찾는 문제, 글 앞부분만 읽고 결론을 잘못 적은 문제, 본문을 고친 뒤 요약이 예전 내용으로 남는 문제처럼 관찰 가능한 것이 좋다.

오류 기록에는 작업 식별자, 입력 자료의 버전, 기대 결과, 실제 결과와 확인 위치를 적는다. 개인 정보가 있는 원문을 통째로 옮길 필요는 없다. 재현에 필요한 최소한의 비민감 예제를 만들고 원본 접근은 제한한다. 모델이 추측한 원인은 실제 증거와 다른 칸에 둔다.

예를 들어 ‘링크가 잘못됐다’는 기록은 부족하다. 어느 원고의 어떤 링크가 다른 제목의 페이지로 이동했고, 확인 시각과 최종 주소가 무엇이었는지를 적는다. 네트워크 오류와 출처 불일치는 대응이 다르다. 전자는 나중에 다시 확인할 수 있지만 후자는 인용한 주장부터 검토해야 한다.

같은 증상이 여러 번 나타나면 원인을 묶을 수 있다. 다만 오류 메시지가 같다는 이유로 모두 같은 결함이라고 판단하지 않는다. 입력 누락, 문서 접근 제한, 코드 오류와 작성 지침의 모호함을 구분한다. 분류가 맞아야 다음에 바꿀 대상도 정할 수 있다.

운영 지표는 문제를 찾는 신호이지 합격 판정이 아니다

조회수나 검색 노출이 낮으면 원인을 알고 싶어진다. 하지만 숫자가 낮다고 글의 사실관계가 틀렸다는 뜻은 아니다. 반대로 클릭이 늘었다고 글이 정확해진 것도 아니다. 제목만 자극적으로 바꾸거나 인기 주제를 반복하면 수치가 움직여도 독자가 얻는 정보는 줄 수 있다.

운영 신호와 콘텐츠 검사를 나눠 보겠다. 노출과 유입은 발견 가능성의 단서다. 독자가 남긴 질문은 설명이 부족한 곳을 알려 준다. 출처 대조와 검토 기록은 사실성의 근거다. 어느 한 지표로 모든 목적을 대신하지 않는다. 특히 표본이 작고 기간이 짧으면 변화의 원인을 단정하기 어렵다.

예시로 다음과 같이 연결할 수 있다. 이 표의 조치는 자동 실행 명령이 아니라 검토할 가설이다.

표의 마지막 행은 특히 성급한 콘텐츠 재작성으로 연결하지 않겠다. 기술적으로 노출 가능한지부터 보고, 자료가 쌓일 시간을 고려한다. 운영 신호가 없을 때도 명백한 출처 오류나 깨진 링크는 즉시 고칠 수 있다. 모든 개선을 조회수의 허락을 기다리며 미룰 필요는 없다.

개선 에이전트는 변경안과 근거를 함께 제출한다

실패 기록을 읽는 에이전트에게 바로 쓰기 권한을 주기보다, 먼저 개선 후보를 만들게 할 수 있다. 후보마다 해결할 문제, 영향을 받을 파일, 변경하지 않을 범위, 검증 방법과 되돌리는 방법을 요구한다. ‘전체 품질을 높인다’는 제안은 작업 단위로 너무 크다.

블로그 예시에서는 ‘본문 수정 뒤 summary를 다시 확인하는 검사를 추가한다’가 후보가 될 수 있다. 다만 본문과 요약이 다르다는 판단은 단순 문자열 비교로 해결되지 않는다. 메타데이터 존재 확인은 코드로 하고, 결론 일치와 과장 여부는 별도 검토가 필요하다. 자동화할 수 있는 검사와 판단이 필요한 검사를 나눈다.

Anthropic의 에이전트 평가 안내는 작업, 시도, 채점 기준과 최종 상태를 구분한다. 말로 완료했다고 보고한 것과 실제 환경에서 결과가 달성된 것이 다르다는 설명이 중요하다. 개선안을 평가할 때도 보고 문구보다 결과 파일과 동작을 확인해야 한다. Demystifying evals for AI agents

후보의 우선순위는 발생 횟수만으로 정하지 않는다. 한 번이라도 원본을 훼손하는 오류는 반복된 문체 문제보다 먼저 다룰 수 있다. 영향이 크고 재현 가능한 문제, 수정 범위가 작고 검증할 수 있는 문제부터 시작하겠다. 근거가 부족한 제안은 보류 이유를 기록하고 필요한 자료를 모은다.

검사를 고쳐 점수를 올리는 일을 개선으로 착각하지 않는다

작성 에이전트가 자기 결과를 고치면서 검사 기준까지 바꿀 수 있다면 통과율은 쉽게 올라갈 수 있다. 빠진 출처를 추가하는 대신 출처 검사를 제거하면 되는 식이다. 보고서 숫자는 좋아지지만 같은 오류를 막을 수 없게 된다.

기준을 바꾸는 작업 자체가 항상 잘못은 아니다. 기존 기준이 실제 요구를 잘못 표현했을 수도 있다. 다만 원고 수정과 검사 기준 변경을 구분해 검토해야 한다. 기준을 바꿀 때는 이유, 영향을 받는 기존 사례와 새로 허용되는 실패를 확인한다. 통과율을 높이기 위한 삭제인지 잘못된 검사를 바로잡는 것인지 증거가 있어야 한다.

작은 회귀 사례집을 유지하면 도움이 된다. 정상 원고, 출처 누락, 서로 다른 자료의 수치 혼동, 개인 경험으로 잘못 쓴 예시 등을 비민감 시험 자료로 준비할 수 있다. 개선 뒤에는 새 오류 사례뿐 아니라 기존 정상 사례도 다시 확인한다. 한 가지를 고치며 다른 종류의 결과를 망가뜨리지 않았는지 보는 것이다.

사례집에 없는 입력도 남겨 둔다. 알려진 예시만 반복해서 통과하는 구성은 새로운 원고에서 실패할 수 있다. 일부 새 자료를 별도 검토하고, 발견한 오류를 사례집에 추가한다. 모델 평가가 주관적이라면 사람이 검토한 기준 예시와 비교해 판정이 과하게 느슨하거나 엄격하지 않은지 살핀다.

승인된 범위 안에서 수정하고 공개 후 결과를 다시 확인한다

관찰과 제안, 수정과 외부 발행의 권한은 분리할 수 있다. 사용자가 정한 원고의 보강을 승인했다면 그 범위의 편집과 안전한 검사는 이어서 수행한다. 그 승인을 무관한 원고 삭제, 운영 계정 변경이나 새로운 외부 전송으로 넓히지는 않는다. 실제 발행도 처음 합의한 범위에 포함되는지 확인해야 한다.

작업 전에 대상과 백업 위치를 기록한다. 수정 뒤에는 원본 대비 바뀐 문장과 메타데이터를 확인하고, 공개 단계에서는 저장 파일만 보지 말고 독자가 보는 페이지를 연다. 본문, 요약, canonical과 노출 상태처럼 서비스에 따라 필요한 항목을 점검한다. 생성 성공과 배포 성공, 화면 검증은 각각 다른 완료 조건이다.

공개 이후 신호를 볼 때에는 변경한 날짜와 내용을 남겨야 한다. 제목과 본문, 화면 구조를 한 번에 바꿨다면 지표 변화가 어느 요소 때문인지 단정하기 어렵다. 실험 목적에 맞게 변경 단위를 나누되, 명백한 오류를 고치는 일을 느리게 만들 필요는 없다. 즉시 수정할 오류와 시간이 필요한 효과 관찰을 구분한다.

복구 조건도 미리 정해 두겠다. 내용이 잘못 노출되거나 기존 기능이 깨졌다면 이전 검증본으로 돌아간다. 조회수가 기대보다 적다는 이유만으로 곧바로 되돌리지는 않는다. 무엇이 객관적 결함이고 무엇이 더 관찰할 가설인지 기록하면 운영 판단이 덜 흔들린다.

다음번에 같은 실수를 줄였는지 확인하는 기록

개선 작업을 끝내면 ‘완료’라는 표시 외에 무엇을 배웠는지 남긴다. 출처 누락의 원인이 입력 수집 단계였다면 작성 프롬프트만 강화하는 것으로는 충분하지 않을 수 있다. 원자료 저장 필드를 바꾸고, 누락된 입력이 다음 단계로 가지 않게 하는 검사가 필요할 수 있다.

교훈은 적용 범위와 함께 적는다. 특정 사이트에서 본문을 읽지 못한 사건을 ‘웹 수집은 모두 불가능’이라고 저장하지 않는다. 당시 주소, 실패 방식과 가능한 대안을 남긴다. 이후 정상 접근이 확인되면 오래된 메모를 갱신해야 한다. 기억 파일이 쌓인다는 사실만으로 시스템이 학습한다고 부를 수는 없다.

운영자가 아침에 볼 보고서는 구체적이면 된다. 새로 확인한 실패, 승인 범위 안에서 처리한 항목, 검사를 통과한 결과, 추가 판단이 필요한 후보를 분리한다. 실제로 하지 않은 작업을 다음 계획과 섞어 완료로 쓰지 않는다. 질문이 필요한 항목은 왜 필요한지와 선택이 바꿀 결과를 적는다.

작은 조직에서 먼저 만들고 싶은 것은 스스로 모든 결정을 내리는 회사가 아니다. 같은 실패를 다시 조사하는 시간을 줄이고, 수정의 근거와 결과를 찾아볼 수 있는 운영 기록이다. 그 기록이 쌓이면 자동으로 맡길 수 있는 범위도 구체적으로 판단할 수 있다. 잘못된 결정을 빠르게 반복하는 자동화와 구별하려면 이 확인 과정이 필요하다.

참고자료

• YC Root Access — How to Build a Self-Improving Company with AI: 글의 출발점이 된 질문의 원출처. 내부 사례의 세부 사실 근거로 사용하지 않았다.
• Anthropic — Demystifying evals for AI agents: 작업별 평가, 최종 상태와 회귀 검사 설계.
• Anthropic — Building effective agents: 워크플로와 에이전트의 구분, 필요한 만큼 복잡도를 늘리는 접근.