고정 메트릭

I’m sorry, but I can’t retrieve the contents of the linked article directly. Could you please paste the text you’d like translated here? Once you provide the content, I’ll translate it into Korean while preserving the formatting, markdown, and technical terms as requested.

핵심 인사이트

Andrej Karpathy의 autoresearch 저장소에는 중요한 파일이 정확히 세 개 있습니다:

**program.md**는 시스템에서 가장 중요한 아티팩트입니다.
이것은 훈련 코드도, 모델 아키텍처도 아닙니다. 문제에 대해 에이전트가 어떻게 생각해야 하는지를 알려주는 문서입니다.

왜 고정된 5분 예산이 중요한가

• 모든 실행은 정확히 5분을 사용합니다 – “대략 5분”도, “실험이 유망해 보이면 5분”도 아닙니다.
• 모든 실행에 어휘‑크기와 무관한 동일한 지표가 사용됩니다.

이 고정 예산이 대부분의 무거운 작업을 담당합니다:

• 이것이 없으면 의미 있게 비교할 수 없는 100개의 데이터 포인트가 생깁니다.
• 작은 아키텍처에서 8 분 동안 학습한 실행과 큰 아키텍처에서 3 분 동안 학습한 실행 – 어느 것이 더 좋을까요? 알 수 없으며, 비교가 깨집니다.

고정된 지표가 바로 아레나가 작동하게 하는 핵심 요소입니다. 이것은 에이전트가 바꿀 수 없는 한 가지입니다. 에이전트는 아키텍처, 옵티마이저, 하이퍼파라미터 등을 수정할 수 있지만, 평가 기준은 인간이 정의한 그대로 유지됩니다.

각 아레나에 대한 설계 질문: 움직일 수 없는 한 가지는 무엇인가?

앵커 기준이 없으면 아레나는 벽이 없는 공간이 됩니다. 에이전트는 계속 변하는 목표를 향해 최적화하게 되고, 결과적으로 비교할 수 없는 실험들의 바다에 빠지게 됩니다.

도메인별 패턴

이 모든 것은 에이전트가 생각하는 방식을 형성하는 사양이며 – 인간 창작 작업의 주요 산물입니다.

Source: …

구체적인 예시

1. 모드가 있는 팀 워크플로

공유 코드베이스에서 에이전트를 실행하는 팀은 mode separation을 정의합니다:

1. Discover – 문제 영역을 탐색합니다.
2. Plan – 해결책을 개요합니다.
3. Build – 계획을 구현합니다.
4. Review – 결과물을 평가합니다.
5. Bugfix – 문제를 수정합니다.
6. Loop – 반복합니다.

각 모드는 자신만의 규칙을 가진 별개의 arena입니다. 에이전트는 Build 로 바로 이동할 수 없으며, 먼저 Discover 를 거쳐야 합니다. 이러한 모드들은 에이전트가 잘못된 방향으로 무한히 실행되는 것을 방지하는 벽 역할을 합니다.

2. 조직 거버넌스

워크플로 전반에 에이전트를 배포하는 조직은 거버넌스 프레임워크를 구축합니다:

• Authorization scope – 에이전트가 단독으로 수행할 수 있는 작업 범위.
• Escalation paths – 인간의 승인(서명)이 필요한 경우.
• Audit trails – 결정 및 행동에 대한 로그 기록.

이 프레임워크는 기관 차원의 arena이며, program.md와 동일한 기준을 제공하는 역할을 합니다.

3. Arena 없이 발생한 실패

Victor Taelin의 실험
예산: $1,000, 2일.
결과: 잘못된 작업 18라운드.

고정된 메트릭도, 기준이 되는 앵커도, arena도 없었습니다. 에이전트는 잘못된 답을 향해 효율적으로 최적화했는데, 시스템에 그들이 잘못된 질문에 답하고 있다는 것을 알려줄 수 있는 것이 없었기 때문입니다. 이것이 arena가 방지하는 실패 모드입니다.

The Discipline Lies in the Specification

• 규율은 에이전트에 있는 것이 아니라 명세(인간이 작성한 파일) 에 있다.
• Karpathy의 program.md는 이미 ~90 % AI‑작성이지만, 앵커인 검증 메트릭 val_bpb는 변하지 않는다. 에이전트는 다른 모든 것을 다시 쓸 수 있지만, 평가 기준은 인간이 정의한 그대로 유지된다.

Recursive Self‑Improvement Principle

Design Principle: 재귀적 자기 개선은 최소 하나의 스스로 개선할 수 없는 계층을 필요로 한다.
하위 계층의 평가 기준은 상위, 불변 계층으로부터 와야 한다.

Foundation의 답은 provenance이다: 평가자는 어떤 지식이 semantic memory로 승격되는지를 결정하지만, 그 기준 자체는 고정된 상태로 남는다.

핵심 요점

1. 불변 메트릭(아레나의 벽)을 식별한 후에 에이전트가 반복하도록 합니다.
2. 이 메트릭과 고수준 전략을 인코딩한 단일하고 명확한 사양 파일(program.md, CLAUDE.md, TASK_CONTRACT.md 등)을 작성합니다.
3. 에이전트가 고정된 평가 기준을 존중하면서 코드, 하이퍼‑파라미터, 아키텍처 등 나머지 모든 것을 자유롭게 수정하도록 허용합니다.
4. 모드 분리 또는 거버넌스 프레임워크를 사용하여 더 큰 규모에서 추가적인 벽을 만듭니다.

아레나가 잘 정의될 때, 에이전트는 강력한 연구 파트너가 됩니다; 그렇지 않으면 빠르지만 방향성 없는 자동 장치에 불과합니다.

병목 현상의 진화

평가는 인간이 정의하고 인간이 유지합니다.
에이전트는 지식 후보를 생성하지만 인간이 유지할 가치가 있는 지식이 무엇인지 결정합니다. 그 단계는 자동화되지 않습니다.

루프는 무한히 실행될 수 있지만, 기준이 되는 기준은 유지되어야 합니다.

코드에서 프롬프트로, 그리고 program.md 로

• 1년 전 병목 현상은 코드 작성이었습니다.
• 그 다음은 프롬프트 작성이 되었습니다.
• 현재 병목 현상은 program.md 작성입니다 – 에이전트에게 전체 문제 영역을 어떻게 생각해야 하는지를 알려주는 문서입니다.

“최고의 연구소는 가장 많은 엔지니어를 보유하고 있지 않을 것입니다. 그들은 최고의 program.md를 가지고 있을 것입니다.”

왜 이것이 중요한가

• 잘 설계된 환경을 가진 한 사람에게 제공되는 레버리지는 실로 엄청납니다.
• Karpathy는 하나의 GPU로 밤새 100 ML 실험을 실행합니다.
• 좋은 CLAUDE.md를 가진 개발자는 예전에는 전체 팀이 필요했던 것을 배포합니다.
• 정확한 사양을 가진 연구자는 자신이 직접 실행하지 않은 83개의 실험 중 15개의 유지된 개선 사항을 아침에 발견합니다.

하지만 병목 현상은 이동했을 뿐—사라지지는 않았습니다.

program.md 작성이 실제로 요구하는 것

1. 문제 영역에 대한 깊은 이해 – 실험을 시작하기 전에 성공이 어떤 모습인지 정의해야 합니다.
2. 올바른 지표 선택 및 그것이 왜 중요한지 아는 것.
3. 벽을 구축하는 것:
   • 드리프트를 방지할 만큼 충분히 단단하게,
   • 진정한 발견을 허용할 만큼 충분히 느슨하게.

그것은 코드를 쓰는 것보다 더 어렵습니다.

• 코드는 컴파일되든 안되든입니다.
• 실험 환경은 유용한 실험을 생성하든 아니든, 혹은 잘못된 답을 향한 수백 번의 유사 실행을 생성할 수 있습니다 – 그리고 그 차이를 알게 되는 순간은 에이전트 활동을 며칠 밤새며 지켜본 뒤일 수도 있습니다.

실제 변화

변화는 열심히 일하는 것에서 쉬운 일로 옮겨가는 것이 아닙니다.
실행의 고된 작업에서 명세의 더 고된 작업으로 옮겨가는 것입니다.

• 에이전트는 실험을 수행합니다.
• 인간은 실험이 무엇을 측정해야 하는지에 대한 판단을 담당합니다.

그 판단은 자동화되지 않습니다. 루프는 돌아가지만, 무대는 여전히 당신의 것입니다.

Series Context

이 게시물은 AI가 실제로 소프트웨어 개발에 어떤 변화를 가져오는가에 대한 시리즈의 일부입니다.
Previous pieces:

• 게이트키핑 패닉
• 계량기는 항상 작동하고 있었다
• 누가 누구에게 무엇을 말했는가
• 토큰 경제
• 나는 깨진 코드를 배포하고 그에 대한 글을 썼다