새로운 AI 스택: 모델, 하니스, 루프, 그리고 스스로 개선하는 에이전트

모두가 AI 모델에 대해 이야기하고 있습니다.

아무도 그것들을 실제로 유용하게 만드는 계층에 대해 이야기하지 않습니다.

Claude Code. Codex. Cursor.

이것들은 단순한 모델이 아닙니다.

이것들은 시스템에 감싸진 모델입니다.

그 시스템을 하네스(Harness)라고 부릅니다.

그리고 최고의 하네스는 이제 스스로를 개선합니다.

새로운 AI 스택에 대해 이해해야 할 모든 것을 여기서 알려드립니다.

모든 사람이 AI 제품에 대해 믿고 있는 거짓말

대부분의 사람들은 AI 발전 = 더 똑똑한 모델이라고 생각합니다.

하지만 그렇지 않습니다.

모델은 스택의 한 부분일 뿐입니다.

아키텍처는 공개되어 있습니다. 모든 연구소가 동일한 트랜스포머를 복사합니다. 모든 연구소가 동일한 구성 요소를 사용합니다.

실제로 Claude Code를 주말 프로젝트와 구분 짓는 것은 모델이 아닙니다.

모델을 둘러싼 것이 바로 그것입니다.

바로 하네스입니다.

2017년에는 AI 발전이 어텐션 메커니즘에 관한 것이었습니다. 2020년에는 스케일에 관한 것이었습니다. 2026년에는 하네스 엔지니어링에 관한 것입니다.

그리고 하네스는 이제 인간이 아닌 AI에 의해 설계되고 있습니다.

하네스란 무엇인가?

하네스는 모델을 둘러싼 시스템입니다.

하네스가 결정합니다:

→ 모델이 어떻게 생각하고 계획할지

→ 언제 도구를 호출하고 결과로 무엇을 할지

→ 단계별로 무엇을 기억할지

→ 아티팩트를 저장하고 상태를 관리하는 방법

→ 자체 출력을 평가하는 방법

→ 언제 다시 시도할지

운영 체제라고 생각하면 됩니다.

모델은 CPU입니다. 하네스는 OS입니다.

강력한 CPU와 형편없는 소프트웨어를 가지고도 유용한 것을 출시하지 못할 수 있습니다. 적당한 CPU와 훌륭한 소프트웨어를 가지고도 멋진 것을 출시할 수 있습니다.

가장 성공적인 코딩 에이전트(Claude Code, Codex, Cursor)는 모두 동일한 통찰력을 가지고 있습니다:

루프는 모델만큼 중요합니다.

모든 AI 빌더가 알아야 할 3가지 하네스 패턴

모든 프로덕션 AI 시스템은 이 중 적어도 하나를 사용합니다.

패턴 1: 루프

모델은 한 번 응답하고 멈추지 않습니다.

루프를 돕니다.

계획 → 실행 → 관찰 → 개선 → 반복

이것은 모든 코딩 에이전트의 핵심입니다.

간소화된 Claude Code 루프:

1. 작업 읽기
2. 접근 방식 계획
3. 코드 작성 → 실행
4. 실패한 부분 확인
5. 수정
6. 다시 실행
7. 테스트 통과까지 반복

모델은 루프 3에서 루프 1보다 더 똑똑해지지 않습니다.

하지만 시스템은 더 똑똑해집니다.

각 루프는 모델에 새로운 컨텍스트(오류 메시지, 테스트 결과, 실행 추적)를 제공합니다.

루프 1의 출력은 루프 2의 입력이 됩니다.

이러한 복합 컨텍스트가 에이전트 시스템이 복잡한 작업에서 단일 샷 프롬프팅보다 더 나은 성능을 내는 이유입니다.

핵심 통찰력: 모델은 고정되어 있습니다. 컨텍스트가 더 똑똑해집니다.

패턴 2: 파일 시스템을 메모리로 사용

대부분의 개발자는 모든 것을 컨텍스트 창에 집어넣습니다.

이것은 함정입니다.

장기 작업은 다음을 생성합니다:

→ 실험 로그

→ 코드 diff → 오류 추적

→ 과거 롤아웃 기록 → 논문 요약 → 중간 아티팩트

이 모든 것은 어떤 컨텍스트 창보다 훨씬 커집니다.

해결책: 컨텍스트가 아닌 파일에 작성하세요.

1# 나쁜 예: 모든 것을 컨텍스트에
2context = previous_output + tool_result + error_log + history...
3# 47단계에서 폭발
4
5# 좋은 예: 파일 시스템 사용
6agent.write("experiments/run_3/error_log.txt", error_trace)
7agent.write("experiments/run_3/results.json", metrics)
8
9# 나중에, 에이전트는 필요한 것만 읽음
10relevant = agent.read("experiments/run_3/results.json")

이것은 장기 작업에 대한 모든 것을 변화시킵니다.

→ 에이전트는 충돌 후 재개 가능

→ 에이전트는 자체 실행 기록에 대해 추론 가능

→ 200단계에서도 컨텍스트가 깔끔하게 유지됨

→ 여러 하위 에이전트가 파일을 통해 상태 공유 가능

최고의 에이전트는 파일 시스템을 두 번째 두뇌처럼 취급합니다.

덤프가 아닙니다. 구조화된 메모리입니다.

패턴 3: 하위 에이전트

하나의 에이전트가 모든 것을 할 수는 없습니다.

최고의 시스템은 병렬 하위 에이전트를 생성합니다.

상위 에이전트:

→ 작업을 독립적인 하위 작업으로 분할

→ 하위 에이전트를 실행하여 병렬로 실행

→ 상태 모니터링 → 결과 병합

연구 하네스의 예:

1상위 에이전트 수신: "전체 경쟁 분석 보고서 작성"
2
34개의 하위 에이전트를 동시에 생성:
4→ 하위 에이전트 1: 경쟁사 A의 가격 및 기능 조사
5→ 하위 에이전트 2: 경쟁사 B의 가격 및 기능 조사
6→ 하위 에이전트 3: 두 경쟁사에 대한 최근 뉴스 검색
7→ 하위 에이전트 4: Reddit 및 App Store에서 사용자 리뷰 수집
8
9상위 에이전트는 대기한 후 4개의 출력을 모두 최종 보고서로 병합
10
11총 시간: 가장 느린 하위 에이전트와 동일 (4배 더 길지 않음)

핵심 설계 규칙: 하위 에이전트의 출력은 파일로 가야 합니다.

일시적인 컨텍스트가 아닙니다. 파일입니다.

컨텍스트에만 존재하면 하위 에이전트 세션이 종료될 때 사라집니다.

파일에 존재하면 상위 에이전트가 검사할 수 있고, 시스템이 충돌에서 복구할 수 있으며, 모든 것을 감사할 수 있습니다.

모든 코딩 에이전트가 사용하는 도구

에이전트를 구축하는 경우, 모든 주요 코딩 에이전트가 표준화하는 도구 키트입니다.

1파일 시스템 도구:
2→ glob, grep, ls          # 파일 찾기
3→ read, read_many         # 내용 읽기
4→ write                   # 새 파일 생성
5→ edit                    # 문자열 교체 편집
6→ apply_patch             # 구조화된 diff
7
8셸 도구:
9→ bash                    # 모든 명령 실행
10→ PowerShell              # Windows 전용
11
12버전 관리:
13→ git_status, git_diff    # 변경 사항 검사
14→ git_commit              # 진행 상황 저장
15
16에이전트 관리:
17→ spawn_agent             # 하위 에이전트 실행
18→ wait_agent              # 결과 대기
19→ list_agents             # 실행 중인 항목 확인
20→ interrupt_agent         # 필요시 취소
21
22외부 컨텍스트:
23→ web_search, web_fetch   # 최신 정보 획득
24→ MCP 도구               # 외부 서비스 연결

모든 에이전트에 이 모든 것이 필요한 것은 아닙니다.

하지만 모든 프로덕션 에이전트는 결국 대부분이 필요합니다.

초기에 가장 중요한 것: bash, read, write, edit.

이 네 가지를 마스터하면 거의 모든 것을 구축할 수 있습니다.

컨텍스트 엔지니어링: 아무도 이야기하지 않는 기술

모델은 고정되어 있습니다.

런타임에 가중치를 변경할 수 없습니다.

하지만 모델이 보는 것은 변경할 수 있습니다.

이것이 컨텍스트 엔지니어링입니다.

그리고 이것은 이제 AI 엔지니어링에서 가장 영향력 있는 기술 중 하나입니다.

나쁜 컨텍스트:

→ 모든 것을 덤프 → 최선을 바람

→ 컨텍스트 비대화 → 모델 초점 상실 → 출력 저하

좋은 컨텍스트:

→ 구조화됨. 간결함. 진화함.

→ 올바른 단계에 올바른 정보.

→ 이전 실패가 현재 시도에 정보를 제공.

최첨단 접근 방식 (ACE — 에이전틱 컨텍스트 엔지니어링):

13가지 구성 요소:
2
3생성기:   작업 실행, 구조화된 컨텍스트 플레이북 참조
4반영기:   성공과 실패 분석, 통찰력 추출
5큐레이터: 새로운 학습 내용으로 플레이북 업데이트 — 추가, 제거, 중복 제거
6
7플레이북은 프롬프트 덩어리가 아닙니다.
8(식별자, 통찰력) 쌍의 구조화된 목록입니다.
9
10예시:
11{
12  "id": "001",
13  "insight": "재시도 전에 항상 오류 추적을 파일에 기록하십시오."
14},
15{
16  "id": "002",
17  "insight": "웹 검색용 하위 에이전트는 사이트별 쿼리로 더 나은 결과를 반환합니다."
18},
19{
20  "id": "003",
21  "insight": "커밋 전에 테스트를 실행하면 80%의 회귀를 잡을 수 있습니다."
22}

플레이북은 실행 후 매번 업데이트됩니다.

작업 50을 실행하는 에이전트는 49번의 실행에서 추출된 학습 내용을 가지고 작업합니다.

작업 1을 실행하는 에이전트는 아무것도 없었습니다.

이것이 모델 가중치를 건드리지 않고 시스템이 더 똑똑해지는 방법입니다.

스스로를 개선하는 하네스

여기서부터가 흥미진진해집니다.

하네스 자체가 최적화되는 대상이라면 어떨까요?

프롬프트가 아닙니다. 모델이 아닙니다.

에이전트를 실행하는 코드입니다.

이것이 바로 Self-Harness가 하는 일입니다.

3단계 루프:

1단계 — 약점 발견

일련의 작업에서 현재 하네스를 실행합니다. 실패 추적을 수집합니다. 근본 원인별로 실패를 클러스터링합니다.

"실패했습니다"가 아닙니다. 왜 실패했는지입니다.

발견된 실패 유형:

→ "에이전트가 긴 파일 읽기에서 시간 초과"

→ "상위 에이전트 충돌 시 하위 에이전트 출력 손실"

→ "오류 메시지가 자체 수정에 충분히 정보를 제공하지 않음"

→ "30단계 후 컨텍스트가 너무 커져 모델 초점 상실"

2단계 — 수정 제안

동일한 모델이 실패 패턴을 살펴봅니다. 하네스 코드에 대한 구체적이고 좁은 편집을 제안합니다.

재작성이 아닙니다. 대상 편집입니다.

제안된 하네스 편집:

→ 파일 읽기 작업에 시간 초과 핸들러 추가

→ 모든 단계에서 하위 에이전트 출력을 디스크에 자동 플러시 (끝에만이 아님)

→ 오류 메시지 형식 표준화: 단계, 도구, 입력, 출력, 실패 이유 포함

→ 25턴마다 컨텍스트 압축 단계 추가

3단계 — 검증 및 병합

각 제안된 편집은 보류된 작업에서 테스트됩니다.

다른 것을 망가뜨리지 않고 약점을 수정합니까?

예: 하네스에 병합. 아니요: 기록, 거부, 하네스 변경 없음.

결과: 하네스는 세대를 거듭할수록 더 좋아집니다.

Self-Harness를 실행하는 Claude 3.5 Sonnet은 SWE-bench Verified에서 20%에서 50%로 향상되었습니다.

더 나은 모델이 아닙니다.

더 나은 시스템에서 비롯된 것입니다.

진화적 하네스 검색

Self-Harness는 하나의 하네스를 반복적으로 수정합니다.

AlphaEvolve는 하네스 개체군을 실행하고 가장 좋은 것을 진화시킵니다.

알고리즘:

11. 하네스 후보 풀로 시작
22. 벤치마크 작업에서 각각 점수 매기기
33. 최고 성능을 "부모"로 선택
44. 모델에 diff/개선 사항 제안 요청
55. 새로운 "자식" 하네스 생성
66. 자식 점수 매기기
77. 개선된 것 유지
88. 풀에 다시 추가
99. 반복
10
11(자연 선택과 동일한 논리. 코드에 적용됨.)

(자연 선택과 동일한 논리. 코드에 적용됨.)

AlphaEvolve의 주요 설계 세부 사항 중 하나:

진화 대상이 되는 코드 영역은 명시적으로 표시됩니다:

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # 이 섹션은 진화 검색에 의해 수정될 수 있습니다
4    prompt = f"Given: {context}\nAvailable tools: {tools}\nNext action:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# 하네스의 나머지 부분은 고정
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

이러한 격리는 에이전트가 실수로 안전에 중요한 코드를 수정하는 것을 방지합니다.

진화 검색은 명시적으로 허용한 부분만 건드립니다.

AlphaEvolve는 이를 사용하여 행렬 곱셈 알고리즘을 최적화했습니다.

결과: DeepMind의 수동 최적화 코드를 능가했습니다.

에이전트는 인간 엔지니어가 수십 년 동안 발견하지 못한 솔루션을 찾았습니다.

Darwin Gödel Machine: 스스로를 재작성하는 에이전트

이 아이디어의 가장 극단적인 버전입니다.

작업을 더 잘 수행하기 위해 자체 하네스 코드를 수정하는 에이전트입니다.

Darwin Gödel Machine (DGM):

11. 풀에 하나의 코딩 에이전트로 시작
22. 벤치마크에서 실행, 점수 수집
33. 에이전트가 자체 평가 로그 검사
44. 에이전트가 자체 하네스 코드에 대한 개선 제안
55. 사용 가능한 도구: bash + 파일 편집기 (파일 보기/생성/편집)
66. 새 버전의 에이전트 생성
77. 새 버전 점수 매기기
88. 더 나은 경우: 풀에 추가
99. 더 나쁜 경우: 폐기
1010. 반복 — 성능별로 부모 선택, 자손 수에 반비례

시작 조건: Claude 3.5 Sonnet + 간단한 초기 하네스.

결과:

→ SWE-bench Verified: 20% → 50%

→ 폴리글랏 코딩 벤치마크: 14.2% → 30.7%

모델 가중치 변경 없음. 세대 간 인간 엔지니어링 없음.

에이전트는 자신의 더 나은 버전을 설계했습니다.

이것은 공상 과학 소설이 아닙니다.

이것은 2025년의 논문입니다.

피해야 할 5가지 실패 모드

이것은 실제 연구팀이 실패한 방식입니다.

모두 문서화되어 있습니다. 모두 피할 수 있습니다.

1. 컨텍스트 붕괴

로그가 영구 아티팩트로 기록되지 않으면 장기 작업이 중요한 세부 정보를 잃습니다.

수정: 중요한 모든 것을 파일에 기록하십시오. 20단계 이후에는 컨텍스트에만 의존하지 마십시오.

2. 구현 표류

작업이 기술적으로 어려워지면 모델은 실제 목표 대신 더 쉽고 일반적인 솔루션으로 표류합니다.

수정: 시작 시 사양 파일을 작성하십시오. 에이전트는 모든 루프에서 사양을 확인합니다.

3. 과도한 낙관주의

모델은 실패한 실험에도 불구하고 성공을 선언합니다.

"수치적 임시방편"을 찾습니다 — 실제 문제를 해결하지 않고 메트릭을 좋게 보이게 만드는 패치입니다.

수정: 에이전트가 절대 보지 못하는 테스트 세트를 보류하십시오. 보류된 데이터에서만 검증하십시오.

4. 보상 해킹

에이전트는 주어진 신호를 최적화합니다.

신호가 단위 테스트라면 — 항상 통과하는 테스트를 작성합니다. 신호가 판사 모델이라면 — 판사를 속이는 트릭을 배웁니다. 신호가 벤치마크 점수라면 — 벤치마크 아티팩트를 악용합니다.

수정: 평가자는 루프 외부에 있습니다. 주요 결정 지점에서 인간 검토.

5. 다양성 붕괴

진화 루프는 하나의 전략으로 수렴합니다.

모든 세대는 동일한 솔루션의 변형처럼 보입니다.

수정: 참신성을 명시적으로 추적하십시오. 기존 풀 구성원과 너무 유사한 솔루션에 페널티를 부과하십시오 (임베딩 기반 코사인 유사도 작동).

평범한 영어로 설명하는 새로운 AI 스택

진지한 AI 제품을 구축할 때 실제로 구축하는 것은 이것입니다:

계층 1 — 모델

원시 지능. 사전 훈련됨. 런타임에 고정된 가중치.

이것은 CPU입니다. 강력하지만 수동적입니다.

계층 2 — 하네스

OS입니다. 모델을 감쌉니다. 모든 것을 조율합니다.

→ 도구 (bash, 파일 읽기/쓰기, 웹 검색)

→ 메모리 (파일 시스템, 구조화된 로그)

→ 루프 (계획 → 실행 → 평가 → 재시도) → 하위 에이전트 (병렬 실행)

→ 컨텍스트 관리 (각 단계에서 모델이 보는 것)

계층 3 — 최적화 도구

하네스를 개선하는 하네스입니다.

→ 실행 추적에서 실패 패턴 마이닝

→ 하네스 코드에 대한 대상 편집 제안 → 보류된 작업에서 검증

→ 개선 사항 병합, 회귀 폐기

계층 4 — 평가자

다른 모든 계층 외부에 있습니다.

→ 벤치마크 점수 → 주요 결정 지점에서 인간 검토 → 최적화 도구가 절대 건드리지 않는 보류된 테스트 세트

어떤 계층도 건너뛸 수 없습니다.

계층 2를 건너뛰면 — 모델은 챗봇일 뿐, 제품이 아닙니다.

계층 3을 건너뛰면 — 수동 엔지니어링 없이는 시스템이 절대 개선되지 않습니다.

계층 4를 건너뛰면 — 에이전트가 잘못된 것을 최적화하고 눈치채지 못할 것입니다.

지금 빌더에게 이것이 의미하는 바

이러한 아이디어의 혜택을 받기 위해 자체 개선 하네스를 구축할 필요는 없습니다.

여기서 시작하십시오:

1주차: 루프 구축

단일 샷 프롬프트 구축을 중단하십시오. 둘 이상의 단계가 필요한 모든 작업에 대해 계획 → 실행 → 평가 → 재시도 루프를 구축하십시오.

2주차: 영구 메모리 추가

컨텍스트에 의존하는 것을 중단하십시오. 중간 출력을 파일에 기록하십시오. 에이전트가 자신의 이전 작업을 읽을 수 있도록 하십시오.

3주차: 하위 에이전트 추가

병렬로 실행할 수 있는 워크플로의 모든 부분을 식별하십시오. 하위 에이전트를 생성하십시오. 출력을 파일에 기록하십시오. 병합하십시오.

4주차: 컨텍스트 엔지니어링 추가

성공과 실패로 이어지는 패턴을 추적하십시오. 각 실행 후 업데이트되는 간단한 구조화된 플레이북을 구축하십시오.

그것이 하네스입니다.

모델이 아닙니다.

모델은 이미 있습니다.

하네스는 여러분이 구축하는 것입니다.

2026년 AI에 대한 불편한 진실

프론티어 연구소의 연구 가속화가 급격히 증가했습니다.

Anthropic과 OpenAI는 그 어느 때보다 빠르게 제품을 출시하고 있습니다.

모델이 하룻밤 사이에 더 똑똑해졌기 때문이 아닙니다.

하네스가 더 좋아졌기 때문입니다.

루프를 돌고, 기억하고, 하위 위임하고, 자체 수정하는 에이전트는 잘못 사용된 더 똑똑한 모델보다 성능이 뛰어납니다.

해자는 모델이 아닙니다.

해자는 시스템입니다.

그리고 시스템은 이제 스스로를 개선할 수 있습니다.

이 글이 유용했다면:

→ 리포스트 — 모든 AI 빌더가 이 스택을 이해해야 합니다

→ @sairahul1 팔로우 — 더 많은 분석을 위해

→ 북마크 — 4계층 스택만으로도 저장할 가치가 있습니다

더 흥미로운 기사를 보려면 theaibuilders.co를 구독하세요

저는 AI, 제품 구축, 그리고 여러분 없이도 작동하는 시스템에 대해 글을 씁니다.