Claude Skills에 Karpathy의 autoresearch 적용하면?

AI 에이전트 시대에 새로 생긴 문제는 “모델이 똑똑하냐”가 아닙니다. 같은 스킬이 10번 중 몇 번이나 안정적으로 잘 동작하느냐입니다.

많은 팀이 Claude Skills, 시스템 프롬프트, 내부 에이전트 워크플로를 잘 만들어 놓고도 중요한 사실을 놓칩니다. 한두 번 잘 돌아간다고 해서, 그 스킬이 운영 가능한 수준으로 안정화된 것은 아니라는 점입니다. 실제로 Ole Lehmann은 이 문제를 정면으로 다뤘습니다. 그가 적용한 방식은 Andrej Karpathy가 공개한 autoresearch 아이디어를 Claude Skills 개선 루프로 옮겨온 것이었고, 랜딩 페이지 카피 스킬의 품질 체크 통과율을 56%에서 92%까지 끌어올렸습니다. 사람이 프롬프트를 손으로 뜯어고친 것이 아니라, 에이전트가 스스로 작은 변경을 반복하면서 얻은 결과였습니다. (GitHub)

이 글에서는 이 방법이 왜 흥미로운지, Claude Skills에 붙이면 내부적으로 어떤 구조가 되는지, 그리고 개발자 입장에서 언제 써야 하는지를 차근차근 풀어보겠습니다.

---

프로젝트 소개

autoresearch는 원래 ML 코드 최적화를 위한 방법론으로 등장했습니다. Karpathy가 공개한 저장소의 핵심 아이디어는 놀랄 만큼 단순합니다. 에이전트가 코드나 설정에 작은 변경 하나를 가하고, 짧은 실험을 돌린 뒤, 성능이 좋아졌으면 유지하고 나빠졌으면 버립니다. 그 과정을 반복해서 더 나은 결과를 찾는 방식입니다. Karpathy의 공개 구현에서는 에이전트가 주로 train.py를 수정하고, 제한된 시간 동안 학습을 돌린 뒤 검증 지표를 보고 다음 행동을 정합니다. (GitHub)

Ole Lehmann이 한 일은 이 패턴을 ML 코드에서 Claude Skills로 옮겨온 것입니다. 즉, 바뀌는 대상은 train.py가 아니라 스킬 프롬프트이고, 검증 지표는 손실 함수가 아니라 체크리스트 기반 품질 점수입니다. 그의 설명에 따르면 이 방식은 Claude Code와 Cowork 환경에서 작동하도록 스킬 형태로 구성되며, 사용자는 “내 어떤 스킬을 개선하라”고 지시하고 평가 기준만 제공하면 됩니다. 그러면 에이전트가 스킬을 반복 실행하고, 평가하고, 수정하고, 되돌리는 루프를 자율적으로 수행합니다. (X (formerly Twitter))

이 접근이 흥미로운 이유는 분명합니다. 기존 프롬프트 엔지니어링은 대체로 사람이 감으로 문장을 바꾸고, 몇 번 실행해 보고, 잘 된 것 같으면 저장하는 식이었습니다. 반면 이 방식은 프롬프트 개선을 실험 가능한 엔지니어링 문제로 바꿉니다. 감이 아니라 반복 가능한 측정 루프로 옮기는 것입니다. (GitHub)

---

왜 이런 프로젝트가 등장했을까

Claude Skills나 각종 에이전트 프롬프트가 실무에서 까다로운 이유는 크게 세 가지입니다.

첫째, 침묵하는 실패가 많습니다.
스킬은 10번 중 7번은 훌륭하게 작동할 수 있습니다. 문제는 나머지 3번이 조용히 엉뚱한 출력, 약한 CTA, 밋밋한 헤드라인, 장황한 문장을 만들어낸다는 점입니다. 한두 번 돌려보고 “괜찮네”라고 판단하면 이 실패율을 놓치기 쉽습니다. Ole Lehmann이 강조한 문제의식도 바로 이것입니다. (X (formerly Twitter))

둘째, 프롬프트 수정은 국소 최적화에 가깝습니다.
“전체를 다시 쓰자”는 접근은 자주 실패합니다. 이미 잘 되는 부분까지 깨뜨릴 수 있기 때문입니다. 그래서 autoresearch는 전체를 갈아엎지 않고, 한 번에 하나의 작은 변경만 시도합니다. 이 방식은 변경의 원인과 결과를 연결하기 쉽고, 되돌리기도 간단합니다. 이 철학은 Karpathy의 원래 구현에도 그대로 반영되어 있습니다. (GitHub)

셋째, 좋은 출력의 기준을 사람이 모호하게 말하는 경우가 많습니다.
“더 날카롭게”, “좀 더 설득력 있게”, “덜 AI스럽게” 같은 피드백은 실행하기 어렵습니다. 반면 autoresearch는 이를 예/아니오로 판정 가능한 체크리스트로 바꾸라고 요구합니다. 이 순간부터 프롬프트 개선은 예술이 아니라 운영 가능한 시스템이 됩니다. (X (formerly Twitter))

---

autoresearch를 Claude Skills에 적용하면 무엇이 달라지나

핵심은 아주 간단합니다.

스킬을 하나 정합니다.
테스트 입력을 정합니다.
좋은 출력의 기준을 3~6개 체크리스트로 만듭니다.
그리고 에이전트가 아래 루프를 반복하게 합니다.

이 구조는 ML 실험 루프와 거의 같습니다. 다만 차이가 있다면, 모델 가중치를 학습하는 대신 프롬프트를 미세하게 진화시키고, loss 대신 체크리스트 점수를 사용한다는 점입니다. (GitHub)

Ole Lehmann의 사례에서 랜딩 페이지 카피 스킬은 다음과 같은 흐름으로 개선되었습니다.

• 초기 기준선 측정
• 가장 자주 실패하는 항목 분석
• 스킬 프롬프트에 작은 규칙 추가
• 다시 실행 후 점수 비교
• 개선되면 유지, 악화되면 롤백
• 목표 통과율에 도달할 때까지 반복

그 결과 4라운드에서 3개의 변경은 유지되었고, 1개는 되돌려졌습니다. 성능을 깎은 변경을 시스템이 알아서 취소했다는 점이 특히 중요합니다. 사람이 프롬프트를 손볼 때 가장 자주 저지르는 실수가 “좋아 보이는 규칙”을 붙였지만 실제론 출력 품질을 해치는 경우인데, autoresearch는 이걸 루프 안에서 바로 잡습니다. (X (formerly Twitter))

---

이 방법의 핵심은 체크리스트다

이 방식의 성패는 모델이 아니라 평가 함수에 달려 있습니다.

Ole의 랜딩 페이지 예시를 보면 기준은 대략 이런 형태입니다.

• 헤드라인에 구체적인 숫자나 결과가 있는가
• 유행어와 공허한 버즈워드를 쓰지 않았는가
• CTA가 구체적인 동사를 포함하는가
• 첫 문장이 구체적인 고충을 짚는가
• 전체 길이가 과도하게 길지 않은가

이 질문들이 좋은 이유는 전부 이진 판정이 가능하기 때문입니다. 점수 7.2점 같은 애매한 평가가 아니라, 통과/실패를 비교적 일관되게 기록할 수 있습니다. Ole의 설명에서도 3~6개 정도가 적당하며, 너무 많아지면 모델이 체크리스트만 통과하려고 “게임”하기 시작한다고 말합니다. 이건 개발자로 치면 테스트 더블을 속이는 코드를 짜는 것과 비슷합니다. 테스트는 통과하지만, 실제 품질은 오히려 떨어질 수 있습니다. (X (formerly Twitter))

개발자 관점에서 이 포인트는 아주 중요합니다.
좋은 autoresearch는 좋은 프롬프트가 아니라 좋은 eval에서 시작합니다.

즉, 질문은 “프롬프트를 어떻게 쓰지?”가 아니라 “이 스킬이 실패하는 패턴을 어떻게 측정하지?”여야 합니다.

---

실제로 어떤 변경이 살아남았나

Ole 사례에서 유지된 변경은 꽤 상징적입니다.

첫째, 모호한 헤드라인을 금지하는 구체 규칙이 들어갔습니다.
예를 들면 “헤드라인은 반드시 구체적인 숫자나 결과를 포함하라” 같은 식입니다. 이 규칙은 “Transform Your Business”처럼 공허한 문장을 줄이는 데 직접적입니다. (X (formerly Twitter))

둘째, 금지 버즈워드 목록이 추가됐습니다.
이건 흥미로운데, LLM은 평균적인 마케팅 문체를 쉽게 흉내 내기 때문에 “revolutionary”, “cutting-edge”, “next-level” 같은 표현으로 자주 미끄러집니다. 금지어 목록은 스타일 가드를 아주 낮은 비용으로 강제하는 방식입니다. (X (formerly Twitter))

셋째, 좋은 예시를 프롬프트 내부에 직접 삽입했습니다.
규칙만 주는 것보다 worked example이 더 강력한 이유는, 모델이 추상적인 목표를 텍스트 패턴으로 구체화할 수 있기 때문입니다. “무엇을 쓰지 말라”보다 “좋은 출력이 어떻게 생겼는가”를 보여주는 편이 효과적이라는, 프롬프트 설계의 고전적인 교훈이 그대로 드러납니다. (X (formerly Twitter))

반대로, 너무 빡빡한 길이 제한은 되돌려졌습니다.
짧으면 좋을 것 같았지만, 실제로는 카피가 지나치게 얇아지고 CTA 힘이 약해졌습니다. 이 사례는 로컬 규칙 하나가 전체 품질을 해칠 수 있음을 보여줍니다. 그리고 바로 이 지점에서 autoresearch의 강점이 드러납니다. 인간은 자기 가설에 애착을 가지지만, 루프는 점수가 떨어지면 미련 없이 되돌립니다. (X (formerly Twitter))

---

Claude Skills용 autoresearch 아키텍처를 개발자 시점에서 보면

실제로 구현한다면 구조는 대개 이렇게 나뉩니다.

1) Orchestrator

루프 전체를 관리합니다.
몇 라운드를 돌릴지, 어떤 입력 세트를 쓸지, 점수 개선이 없으면 멈출지, 95% 이상이 3회 연속 나오면 종료할지 같은 정책을 담당합니다. Karpathy의 원본 autoresearch도 사실상 이런 오케스트레이션 개념 위에 서 있습니다. (GitHub)

2) Mutation Engine

스킬 프롬프트를 미세 조정하는 컴포넌트입니다.
중요한 점은 한 번에 하나만 바꾼다는 것입니다. 규칙 추가, 예시 삽입, 금지 표현 목록 보강, 출력 형식의 명시 강화 같은 변화가 여기에 속합니다.

3) Skill Execution

실제 스킬을 테스트 입력에 대해 실행합니다.
여기서 중요한 것은 테스트 세트의 다양성입니다. 특정 예시 하나만 잘 통과하면 그건 개선이 아니라 과적합일 수 있습니다.

4) Judge / Checklist Evaluator

출력을 읽고 체크리스트를 기준으로 점수를 매깁니다.
여기서는 “헤드라인에 숫자가 있는가”처럼 비교적 명확한 질문을 써야 합니다. 모호한 판정이 많아질수록 루프 전체가 흔들립니다.

5) Score Store / Changelog

각 라운드의 점수, 시도한 변경, 유지/롤백 여부를 기록합니다.
실무에서는 이 부분이 생각보다 훨씬 중요합니다. 결과가 아니라 탐색 과정 전체가 자산이 되기 때문입니다. Ole도 최종 스킬만큼 changelog가 가치 있다고 강조합니다. 미래의 더 좋은 모델이 나오면, 그 로그를 넘겨 이어서 개선할 수 있기 때문입니다. (X (formerly Twitter))

---

코드로 보면 이런 식이다

아래는 개념을 설명하기 위한 아주 단순화된 의사 코드입니다.

from dataclasses import dataclass
from typing import Callable, List

@dataclass
class EvalResult:
    passed: int
    total: int
    details: list[str]

    @property
    def score(self) -> float:
        return self.passed / self.total

def run_skill(skill_prompt: str, test_input: str) -> str:
    # 실제로는 Claude Skill 실행
    return call_agent(skill_prompt, test_input)

def judge_output(output: str) -> EvalResult:
    checklist = [
        lambda x: contains_specific_number_or_result(x),
        lambda x: not_contains_buzzwords(x),
        lambda x: has_specific_verb_in_cta(x),
        lambda x: mentions_specific_pain_point_early(x),
        lambda x: word_count(x) <= 150,
    ]
    passed = 0
    details = []
    for i, rule in enumerate(checklist, start=1):
        ok = rule(output)
        passed += int(ok)
        details.append(f"Q{i}: {'PASS' if ok else 'FAIL'}")
    return EvalResult(passed=passed, total=len(checklist), details=details)

def mutate_prompt(skill_prompt: str) -> str:
    # 한 번에 하나의 변경만 적용
    # 예: 금지어 추가, 예시 삽입, 규칙 강화
    return propose_single_change(skill_prompt)

def autoresearch(skill_prompt: str, test_inputs: List[str], rounds: int = 20) -> str:
    current_prompt = skill_prompt
    current_score = evaluate_prompt(current_prompt, test_inputs)

    for _ in range(rounds):
        candidate_prompt = mutate_prompt(current_prompt)
        candidate_score = evaluate_prompt(candidate_prompt, test_inputs)

        if candidate_score > current_score:
            current_prompt = candidate_prompt
            current_score = candidate_score
            log_change("kept", current_score)
        else:
            log_change("reverted", candidate_score)

    return current_prompt

def evaluate_prompt(prompt: str, test_inputs: List[str]) -> float:
    scores = []
    for test_input in test_inputs:
        output = run_skill(prompt, test_input)
        result = judge_output(output)
        scores.append(result.score)
    return sum(scores) / len(scores)

이 코드는 단순하지만 본질을 잘 보여줍니다.
프롬프트 엔지니어링이 아니라, 프롬프트 실험 자동화입니다.

---

개발자가 이걸 바로 써먹을 수 있는 영역

이 방식은 “무엇이 좋은 결과인지 사전에 비교적 명확히 정의할 수 있는 작업”에서 특히 강합니다.

랜딩 페이지 카피

가장 대표적인 예입니다.
헤드라인, CTA, 길이, 고충 제시, 금지 표현 등은 체크리스트화하기 쉽습니다. Ole의 사례도 바로 이 영역에서 효과를 증명했습니다. (X (formerly Twitter))

콜드 아웃리치

“상대 회사 언급 여부”, “75단어 이하”, “구체적 질문으로 종료”처럼 규칙을 정하기 쉽습니다. 사용자 반응이 오기 전에도 1차 품질 필터링이 가능합니다.

뉴스레터 인트로

“첫 문장에 개인적 디테일이 있는가”, “클리셰 표현이 없는가”, “주제가 너무 늦게 나오지 않는가” 같은 기준을 둘 수 있습니다.

반복 사용하는 프롬프트 전반

요약, 회의록, 보고서 초안, 세일즈 카피, 제품 소개문, 채용 공고 등도 가능성이 큽니다. 핵심은 도메인이 아니라 점수화 가능성입니다.

---

반대로, 지금 당장 한계가 뚜렷한 영역

여기서 과장하면 안 됩니다. autoresearch는 만능이 아닙니다.

마케팅 성과처럼 실제 사용자 반응이 필요한 영역은 피드백 루프가 느립니다. 이메일 오픈, 광고 클릭, 전환율은 몇 분 안에 안정적으로 확인되는 지표가 아닙니다. 따라서 autoresearch는 A/B 테스트를 대체하기보다, 트래픽과 예산을 태우기 전에 품질을 미리 걸러내는 사전 필터에 더 가깝습니다. 이 해석은 실무적으로도 매우 설득력 있습니다.

다시 말해:

• 클릭률을 직접 최적화하는 시스템이라기보다
• 클릭률을 해칠 가능성이 높은 저품질 문안을 미리 제거하는 시스템

에 가깝습니다.

이 차이를 이해하지 못하면 기대치가 어긋납니다.
체크리스트 통과율 92%가 시장 성과 92%를 뜻하는 것은 아닙니다. 다만 인간 검토 전에 버릴 후보를 대폭 줄여준다는 점에서 충분히 강력합니다.

---

이 방식이 특히 강력한 이유

제가 보기에 이 접근의 진짜 가치는 세 가지입니다.

1) 프롬프트를 자산이 아니라 공정으로 본다

많은 팀이 좋은 프롬프트를 “완성된 문서”로 취급합니다.
하지만 autoresearch는 프롬프트를 지속적으로 실험·측정·개선되는 생산 라인으로 봅니다.

2) 실패 패턴이 로그로 남는다

어떤 변경이 왜 먹혔는지, 왜 실패했는지 누적 기록이 남습니다.
이건 단순한 버전 히스토리가 아닙니다. 미래 모델에게 넘길 수 있는 도메인별 개선 이력입니다. Ole가 changelog를 가장 가치 있는 산출물로 본 이유도 여기에 있습니다. (X (formerly Twitter))

3) “좋은 결과”를 팀 차원에서 합의하게 만든다

체크리스트를 만드는 과정 자체가 중요합니다.
팀이 “좋은 랜딩 페이지란 무엇인가”를 말로만 합의하는 것이 아니라, 머신이 반복 실행 가능한 기준으로 박제하게 되기 때문입니다.

---

실무에서 적용할 때의 팁

테스트 입력은 반드시 여러 개로

입력 하나만 쓰면 그 예시에만 과적합됩니다.
최소한 쉬운 케이스, 애매한 케이스, 까다로운 케이스를 섞어야 합니다.

체크리스트는 3~6개 선에서 멈추기

너무 많으면 모델이 본질보다 시험 통과에 최적화됩니다. Ole도 이 점을 명확히 지적합니다. (X (formerly Twitter))

규칙보다 예시가 강할 때가 많다

“하지 마라”만 늘리면 프롬프트가 딱딱해집니다.
worked example을 함께 넣는 쪽이 더 안정적일 때가 많습니다. 실제 사례에서도 그 변경이 유지됐습니다. (X (formerly Twitter))

롤백을 설계에 포함하라

되돌리기는 실패가 아니라 시스템의 핵심 기능입니다.
좋은 자동 개선 루프는 공격적으로 시도하되, 쉽게 취소할 수 있어야 합니다.

---

이 아이디어를 한 문장으로 정리하면

Claude Skills를 잘 쓰는 시대에서, Claude Skills를 스스로 개선하게 만드는 시대로 넘어가는 패턴입니다.

Karpathy의 autoresearch는 원래 작은 LLM 학습 코드에 대한 자율 실험 루프였지만, Ole Lehmann의 사례는 이 패턴이 프롬프트와 스킬에도 그대로 이식될 수 있음을 보여줍니다. 작은 변경, 빠른 평가, 유지 또는 롤백, 그리고 반복. 이 구조가 성립하는 순간 프롬프트 엔지니어링은 감각의 영역에서 시스템의 영역으로 이동합니다. (GitHub)

그리고 이 메시지는 생각보다 더 크습니다.

내 스킬이 10번 중 3번 실패하는 사실을 모르고 있다면, 그건 아직 문제로 인식되지 않습니다.
하지만 일단 알게 되면 이야기가 달라집니다.
그때부터 필요한 것은 더 좋은 문장력이 아니라, 실패를 측정하고 자동으로 줄여 나가는 루프입니다.

그게 바로 Claude Skills에 적용된 autoresearch의 본질입니다.

원본 : 

X의 Ole Lehmann님(@itsolelehmann)