원문 제목: Thin Harness, Fat Skills
원문 작가: Garry Tan
번역: Peggy, BlockBeats

편집자 주: '보다 강력한 모델'이 산업의 기본 답변이 되는 가운데, 이 글은 다른 판단을 제시합니다: 10배, 100배, 심지어 1000배까지의 생산성 격차를 실제로 만드는 것은 모델 자체가 아니라, 모델 주변에 구축된 완전한 시스템 설계입니다.

본문의 저자인 Garry Tan은 현재 Y Combinator의 회장 겸 최고경영자이며 AI 및 초기 창업 생태계에 장기간 종사해왔습니다. 그는 'fat skills + thin harness'라는 프레임워크를 제시하여 AI 응용을 기술, 실행 프레임워크, 컨텍스트 라우팅, 작업 분업 및 지식 압축 등의 주요 구성 요소로 분해합니다.

이 체계에서 모델은 더 이상 능력의 전부가 아니며, 단지 시스템 내의 실행 단위입니다. 결과물 품질을 실제로 결정하는 것은 컨텍스트를 어떻게 조직하고 프로세스를 정립하며 '판단'과 '계산'의 경계를 어떻게 명확히 하는지입니다.

더 중요한 것은, 이 방법론이 개념적 수준에 머무르지 않고 실제 상황에서 검증되었습니다: 수천 명의 창업가에게 데이터 처리 및 매칭 작업을 진행하면서, 시스템은 '읽기 - 집계 - 판단 - 다시 쓰기'의 루프를 통해 코드 재작성 없이도 지속적으로 자체 최적화되어 거의 인간 수준의 분석가 능력을 실현했습니다. 이러한 '학습 가능한 시스템'은 AI를 일회성 도구에서 복리 효과를 갖는 기반 시설로 변화시켰습니다.

따라서, 글에서 제시된 핵심 메시지는 AI 시대에 효율성 격차가 더 이상 최신 모델을 사용하느냐는 데에 달려있지 않고, 계속해서 능력을 축적하고 자동 진화하는 시스템을 구축했는지에 달렸다는 것입니다.

아래는 원문입니다:

Steve Yegge는 AI 프로그래밍 에이전트를 사용하는 사람들이 '커서(cursor)와 채팅 도구만으로 코드를 작성하는 엔지니어들보다 10배에서 100배, 대략 2005년 구글 엔지니어들의 1000배' 더 효율적이라고 말합니다.

참고: Steve Yegge는 실리콘밸리에서 영향력 있는 소프트웨어 엔지니어, 기술 블로거 및 엔지니어링 문화 평론가로, 날카로운 기술 글로, 강렬한 개인 스타일을 가진 긴 문장의 기술 글로 유명합니다. 그는 아마존, 구글 등의 회사에서 고급 엔지니어로 근무한 경험이 있으며, 나중에 Salesforce에 합류하여 스타트업 및 AI 관련 분야에서 활동했으며 초기 Dart 프로젝트를 촉진한 선구자 중 한 명입니다.

과장이 아닌 말씀입니다. 제가 직접 목격하고 직접 체험한 일입니다. 그러나 이러한 격차를 듣는 사람들은 종종 더 강력한 모델이나 더 똑똑한 Claude, 더 많은 매개변수로 이유를 찾으려고 합니다.

실제로, 성능이 2배 향상된 사람과 100배 향상된 사람은 같은 모델을 사용합니다. 차이는 "지능"이 아니라 "구조"에 있으며, 이러한 구조는 명함에 적을 정도로 간단합니다.

Harness(실행 프레임워크)가 제품 자체입니다.

2026년 3월 31일, Anthropic은 Claude Code의 전체 소스 코드를 npm에 실수로 게시한 적이 있었습니다. 총 51.2만 줄입니다. 저는 한 번 훑어보았습니다. 이것은 저가 YC(Y Combinator)에서 항상 말해온 것을 확인했습니다: 진정한 비밀은 모델에 있지 않고, "모델을 감싸는 그 층"에 있습니다.

실시간 코드 저장소 컨텍스트, 프롬프트 캐시, 특정 작업에 대한 도구, 최대한 중복 컨텍스트 압축, 구조화된 세션 메모리, 병렬로 실행되는 서브 에이전트 — 이러한 것들은 모델을 더 똑똑하게 만들지는 않습니다. 그러나 이러한 요소들은 모델에 "올바른 컨텍스트"를 "올바른 시간에" 제공하고, 관련 없는 정보에 잠기지 않도록 해줍니다.

이러한 "감싸기" 층은 바로 harness(실행 프레임워크)라고 합니다. 그리고 모든 AI 빌더가 실제로 묻어야 할 질문은 다음과 같습니다: 어떤 것을 harness에 넣어야 하고, 어떤 것을 밖에 둬야 하는가?

이 질문에 실은 매우 구체적인 대답이 있습니다 — 내가 얇은 프레임워크(thin harness), 뚱뚱한 기능(fat skills)이라고 부르는 것입니다.

다섯 가지 정의

병목 현상은 모델의 지능에 있지 않습니다. 모델은 이미 추론, 정보 통합, 코드 작성하는 방법을 알고 있습니다.

그들이 실패하는 이유는 데이터를 이해하지 못하기 때문입니다 — 당신의 schema, 당신의 규칙, 이 문제가 어떤 모양인지에 대한 이해. 아래 다섯 가지 정의는 이 문제를 해결하기 위해 만들어졌습니다.

1. Skill file(스킬 파일)

스킬 파일은 모델에게 "어떻게 하면 되는지"를 가르치는 재사용 가능한 마크다운 문서입니다. 주목할 점은, 이 문서는 모델에게 "무엇을 해야하는지"를 가르치는 것이 아닙니다 — 사용자가 제공합니다. 스킬 파일이 제공하는 것은 프로세스입니다.

대부분 사람들이 무시하는 중요한 점은: 스킬 파일이 사실상 메소드 호출과 같다는 것입니다. 그것은 매개변수를 받을 수 있습니다. 다른 매개변수로 호출할 수 있습니다. 동일한 프로세스가 서로 다른 매개변수로 인해 전혀 다른 능력을 보여줄 수 있습니다.

예를 들어, /investigate 라는 스킬이 있다고 가정해보겠습니다. 이는 일곱 단계로 이루어져 있습니다: 데이터 범위 정의, 타임라인 설정, 각 문서에 대한 diarize 수행, 종합 요약, 양쪽에서의 논증, 출처 인용. 이는 TARGET, QUESTION 및 DATASET 세 가지 매개변수를 받습니다.

이를 보안 전문가와 2.1 백만 개의 증거 수집 이메일에 적용하면, 의료 연구 분석가가 되어 폭로자가 억압당했는지를 판단하게 됩니다.

한편, 이를 쉘 회사와 미국 연방 선거위원회(FEC)의 공표 파일에 적용하면, 법적 증거 수집 조사관이 되어 공동 행동적 정치 기부를 추적하게 됩니다.

여전히 같은 스킬입니다. 여전히 동일한 일곱 단계입니다. 여전히 동일한 markdown 파일입니다. 이 스킬은 판단 프로세스를 설명하는 것이며, 실제로 그것을 현실 세계에 적용하는 것은 호출할 때 전달되는 매개변수입니다.

이것은 prompt engineering이 아니라 소프트웨어 디자인입니다: 여기서는 markdown을 프로그래밍 언어로 사용하고, 인간 판단력을 실행 환경으로 사용합니다. 사실, markdown은 rigid한 소스 코드보다 더 많은 캡슐화 능력에 더 적합합니다. 왜냐하면 그것이 설명하는 것은 프로세스, 판단 및 맥락이며, 이러한 것들이 바로 모델이 가장 잘 "이해"하는 언어이기 때문입니다.

2、Harness(실행 프레임워크)

Harness는 LLM을 실행하기 위한 레이어입니다. 이는 모델을 반복적으로 실행하고, 파일을 읽고 쓰며, 컨텍스트를 관리하고, 보안 제약을 실행하는 네 가지 작업만 수행합니다.

이것뿐입니다. 이것이 "얇은" 것이죠.

특이한 패턴은 다음과 같습니다: 뚱뚱한 harness, 날씬한 skills.

아마 이런 것을 본 적이 있을 것입니다: 40가지 이상의 도구 정의, 설명만으로도 절반의 컨텍스트 창고를 소모; 만능 God-도구, MCP를 왕복하는 데 2에서 5초가 소요; 또는 REST API의 모든 엔드포인트를 개별 도구로 포장하는 것. 결과적으로, 토큰 소비량이 세 배로 늘어나고, 지연 시간도 세 배로 늘어나며, 실패율도 세 배로 증가합니다.

진정으로 이상적인 방법은 목적에 맞는 빠르고 기능이 제한된 도구를 사용하는 것입니다.

예를 들어 Playwright CLI는 각 브라우저 작업에 100밀리초만 소요됩니다. 이는 한 번의 스크린샷 → 찾기 → 클릭 → 대기 → 읽기에 15초가 걸리는 Chrome MCP와는 달리 75배 빠릅니다.

지금 소프트웨어는 더 이상 "푹신으로 정굽지 않아도 됩니다." 당신이 해야 할 일은: 당신이 정말 필요로 하는 것만 구축하고, 그게 전부입니다.

3、Resolver(해결사)

Resolver는 본질적으로 상황별 라우팅 표입니다. 작업 유형 X가 발생할 때 문서 Y를 우선으로 로드합니다. skills는 모델에게 "어떻게 하라"고 말하며, resolvers는 모델에게 "언제 무엇을 로드해야 하는지"를 알려줍니다.

예를 들어, 개발자가 어떤 프롬프트를 수정했습니다. 해결사가 없으면, 그는 수정을 하고 즉시 릴리스 할 수도 있습니다. 해결사가있는 경우, 모델은 먼저 docs/EVALS.md을 읽습니다. 이 문서에는 처음에 평가 스위트를 실행하고 이전 및 이후 점수를 비교하라고 적혀 있습니다. 정확도가 2% 이상 감소하면 롤백하고 원인을 조사하십시오. 이 개발자는 평가 스위트의 존재조차 몰랐을 수도 있습니다. 해결사는 올바른 문맥을 올바른 시기에로드하여 주었습니다.

Claude Code에는 해결사가 내장되어 있습니다. 각 skill에는 설명 필드가 있으며, 모델은 사용자 의도를 skill 설명과 자동으로 일치시킵니다. 당신이 /ship이라는 기술이 존재하는지 기억할 필요가 전혀 없습니다-description 자체가 해결사입니다.

솔직히 말하면: 내 이전 CLAUDE.md에는 무려 2 만 줄이 있었습니다.모든 기이, 모든 패턴, 내가 경험한 모든 교훈이 모두 박혔습니다. 매우 어처구니없습니다. 모델의 주의력 품질이 뚜렷하게 저하되었습니다. Claude Code는 심지어 그것을 들었어야 했습니다.

최종 수정 해결책은 대략 200 줄에 불과했습니다-일부 문서 포인터 만 남기십시오. 실제로 필요한 문서를 resolver가 중요한 시기에로드하도록하십시오. 이렇게하면 2 만 줄의 지식을 필요할 때마다 가져와 사용할 수도 있지만, 상황 창에 오염시키지 않을 것입니다.

4、Latent and deterministic(잠재 공간과 결정론적)

귀하의 시스템에는 각 단계가이 범주 중 하나에 속합니다. 그리고이 두 가지를 혼동하는 것은 에이전트 설계에서 가장 흔한 실수 중 하나입니다.

·잠재 공간(Latent space)은 지능이 존재하는 곳입니다. 모델은 여기에서 읽기, 이해하기, 판단하기, 의사 결정을합니다.이 곳에서는 판단, 종합, 패턴 인식 등이 처리됩니다.

·결정론적(deterministic)은 신뢰성이 있는 곳입니다. 동일한 입력은 항상 동일한 출력을 생성합니다. SQL 쿼리, 컴파일 된 코드, 산술 연산은 이 쪽에 속합니다.

하나의 LLM은 여러분이 8명의 사람들을 대접하는 자리를 배치하는 데 도움을 줄 수 있습니다. 각 사람의 성격과 사회적 관계를 고려합니다. 그러나 800명의 사람들을 대상으로 자리를 배치하라고 요청하면, 그것은 경솔하고도 틀린 자리 배치표를 만들어 냅니다. 왜냐하면 그것이 처리할 문제는 더는 잠재적 공간의 문제가 아니라 latent space에 강제로 밀어 넣은 결정론적 문제인 조합 최적화 문제이기 때문입니다.

최악의 시스템은 항상 이 경계선 양쪽에 작업을 잘못 위치시킵니다. 최고의 시스템은 그 경계를 명확히 긋게 될 것입니다.

5. Diarization(문서 정리 / 주제 포트레이트)

diarization 단계는 AI가 현실 지식 작업에 가치를 부여하는 데 실질적인 역할을 합니다.

그 의미는 다음과 같습니다: 모델이 한 주제와 관련된 모든 자료를 읽은 후 구조화된 포트레이트를 작성합니다. 몇십 개에서 수백 개의 문서에서 얻은 판단을 한 장의 종이에 요약합니다.

이것은 SQL 쿼리로 얻을 수 있는 것이 아닙니다. 또한 RAG 파이프라인으로 얻을 수 있는 것도 아닙니다. 모델은 실제로 읽고 상충하는 정보를 동시에 이해하고 정보가 어떻게 변하는지, 언제 변하는지를 주시하며 그 내용을 구조화된 인텔리전스로 통합해야 합니다.

이것이 데이터베이스 쿼리와 분석가 브리핑 간의 차이점입니다.

이 아키텍처

이 다섯 가지 개념은 매우 간단한 세계로 결합될 수 있습니다.

· 맨 위에는 두꺼운 기술(fat skills)이 있습니다: markdown으로 작성된 절차, 판단 및 방법론, 그리고 도메인 지식을 담고 있습니다. 가치의 90%는 이 층에 있습니다.
· 중간에는 얇은 CLI harness 층이 있습니다: 약 200줄의 코드로, JSON을 입력으로 받아 텍스트를 출력하며 기본적으로 읽기 전용입니다.
· 가장 아래에는 귀하의 응용 프로그램 시스템이 있습니다: QueryDB, ReadDoc, Search, Timeline 등이 있습니다. 이들은 결정론적 기반 시설입니다.

핵심 원칙은 방향을 가지고 있습니다: "지능"을 기술로 최대한 후방 이동시키고, "실행"을 결정론적 도구로 최대한 전진시키며, harness를 가볍게 유지하는 것입니다.

이렇게 하면 결과적으로, 모델 능력이 향상될 때마다 모든 스킬이 자동으로 강화되고, 하단의 결정론적 시스템은 항상 안정적이고 신뢰할 수 있습니다.

학습 가능한 시스템

아래는 YC에서 구축 중인 실제 시스템을 사용하여 이 다섯 가지 정의가 어떻게 함께 작동하는지 보여 드리겠습니다.

2026 년 7 월, Chase Center. Startup School에는 6000 명의 창업자가 참석했습니다. 각자는 구조화된 신청 자료, 설문 응답, 멘토와의 1:1 대화 트랜스크립트, 그리고 공개 신호를 가지고 있었습니다: X에서의 게시물, GitHub 제출 기록, Claude Code 사용 기록(그들의 개발 속도를 나타냅니다).

전통적인 방식은 다음과 같습니다: 15 명의 팀이 각자 신청서를 읽고 직관적으로 판단한 후 스프레드시트를 업데이트합니다.

이 방법은 200 명 규모에서는 작동할 수 있지만, 6000 명에서는 완전히 실패합니다. 아무도 한 번에 이렇게 많은 프로필을 머릿속에 담을 수 없으며, AI 에이전트는 라그로스의 개발 도구 창시자, 싱가폴의 규정 준수 기업가, 그리고 브루클린의 CLI 도구 개발자가 각각 세 가지 다른 1:1 대화에서 동일한 고민을 완전히 다른 용어로 설명했다는 것에 대해 인식하고 참여자를 선정했습니다.

모델은 할 수 있습니다. 방법은 다음과 같습니다:

Enrichment(정보 강화)

/enrich-founder 라는 기술이 있습니다. 이 기술은 모든 데이터 원본을 가져와 정보를 풍부하게 하고, diarization을 수행하며 "창업자의 말"과 "실제로 하는 일" 사이의 차이를 표시합니다.

기저 확률론적 시스템은 SQL 쿼리, GitHub 데이터, 데모 URL의 브라우저 테스트, 소셜 신호 캡처, CrustData 쿼리 등을 처리합니다. 정기적인 작업이 매일 실행됩니다. 6000 명의 창업자 프로필은 항상 최신 상태를 유지합니다.

diarization의 출력은 키워드 검색으로는 발견할 수 없는 정보를 포착할 수 있습니다:

창업자: Maria Santos 회사: Contrail(contrail.dev) 자기 소개: "AI 에이전트의 Datadog" 실제로 하는 일: 코드 제출의 80%가 요금 모듈에 집중 → 본질적으로는 FinOps 도구를 입은 것

이러한 "말과 행동의 차이"는 GitHub 제출 기록, 신청 자료 및 대화 기록을 동시에 읽고 머릿속에서 통합해야 합니다. 어떤 임베딩 유사성 검색도 이를 수행할 수 없으며, 키워드 필터도 작동하지 않습니다. 모델은 완전히 읽은 후 판단해야 합니다. (이것은 latent space에 놓아야 할 작업입니다!)

매칭

이것은 「기술 = 메소드 호출」이 힘을 발휘하는 곳입니다.

동일한 매칭 기술을 세 번 호출하면 완전히 다른 전략을 만들어낼 수 있습니다:

/match-breakout: 1200 명을 처리하며 도메인에 따라 클러스터링되어 각 그룹은 30 명 (임베딩 + 결정론적 할당)

/match-lunch: 600 명을 처리하며 도메인을 넘어서는 '우발적 매칭'으로, 각 탁자에는 8 명이 앉으며 중복되지 않음 — LLM이 주제를 먼저 생성하고 결정론적 알고리즘에 의해 좌석이 배치됨

/match-live: 현장에서 실시간 참여자를 처리하며 최근 이웃 임베딩을 기반으로 하여 200ms 내에 1:1 매칭을 완료하고 이전에 만난 사람을 제외함

그리고 모델은 전통적인 클러스터링 알고리즘에서 수행할 수 없는 판단을 내릴 수 있습니다:

「Santos와 Oram은 둘 다 AI 인프라에 속하지만 경쟁 관계는 아닙니다 — Santos는 비용 속성을 수행하고 Oram은 배치를 수행합니다. 동일 그룹에 속해야 합니다.」
「Kim이 신청 시 개발자 도구라고 기재했지만 1:1 대화에서는 SOC2 규정 준수 자동화를 수행하고 있다는 것을 보여줍니다. FinTech / RegTech로 다시 분류해야 합니다.」

이러한 재분류는 임베딩으로 완전히 포착할 수 없습니다. 모델은 전체 프로필을 읽어야만 합니다.

학습 루프

행사 종료 후, /improve 기술은 NPS 조사 결과를 읽어서 '나쁘지 않음' 피드백에 대해 다이어라이제이션을 수행합니다 — 부정적인 평가가 아니라 '조금만 더 나아졌으면 하는' 피드백들을 추출하고 패턴을 식별합니다.

그런 다음 새로운 규칙을 제안하고 매칭 기술에 다시 작성합니다:

참여자가 'AI 인프라'라고 말했지만 코드의 80% 이상이 요금 모듈인 경우:
→ AI 인프라 대신 FinTech으로 분류

같은 그룹의 두 명이 이미 알고 있는 경우:
→ 매칭 가중치 낮춤
새로운 관계 우선 도입

이러한 규칙은 skill 파일에 기록됩니다. 다음 실행 때 자동으로 적용됩니다. 기술이 '자가 수정'합니다. 7월 행사에서 '나쁘지 않음' 평가가 12%를 차지했는데, 다음 행사에서는 4%로 줄었습니다.

skill 파일은 '그럭저럭'이 의미하는 것을 배우고, 시스템이 코드를 다시 작성하지 않은 상태로 더 나아졌을 때를 가리킵니다.

이러한 패턴은 모든 영역으로 이전될 수 있습니다:

검색 → 읽기 → 다이어라이즈 → 계산 → 통합

그 후: 조사 → 설문 → 다이어라이즈 → skill 다시 작성

2026년에 가장 가치 있는 루프가 무엇인지 묻는다면, 이 패턴입니다. 이는 거의 모든 지식 작업 상황에 적용할 수 있습니다.

기술은 영구적인 업그레이드입니다

최근 X에서 OpenClaw에 지시를 보냈는데, 예상보다 큰 반향을 얻었습니다:

지시: 단발적인 작업을 허용하지 않습니다. 미래에 반복될 일을 하게 한다면, 당신은 다음을 해야 합니다: 처음에는 3에서 10개의 샘플을 수동으로 처리하여 결과를 보여주세요. 내가 승인하면, 그것을 하나의 skill 파일로 작성하세요. 자동으로 실행되어야 하는 경우, 예약 작업에 추가하세요. 평가 기준은: 두 번째로 물어봐야 한다면, 실패한 것입니다.

이 콘텐츠는 수천 개의 좋아요와 2,000개 이상의 즐겨찾기를 받았습니다. 많은 사람들이 이것이 prompt 공학의 기술이라고 생각했습니다.

사실은 아닙니다. 이것은 방금 말한 그 패턴입니다. 당신이 쓴 각각의 skill은 시스템의 영구적인 업그레이드입니다. 그것은 퇴화하지 않으며 잊혀지지 않습니다. 새벽 3시에 자동으로 실행될 것입니다. 다음 세대 모델이 출시되면, 모든 skill이 즉시 강화될 것입니다 — latent 부분의 평가 능력이 향상되는 반면, 결정론적 부분은 여전히 안정적입니다.

이것이 Yegge가 언급한 100배 효율성의 근원입니다.

더 똑똑한 모델이 아니라: 풍부한 기술, 얇은 프레임워크(Thin Harness, Fat Skills), 모든 것을 능력으로 고정시키는 규율입니다.

시스템은 복리적으로 성장합니다. 한 번 구축하면 장기간 실행됩니다.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia