참고자료 · Progress

AI 발전 속도와 실제 도입 사례

agentic coding harness를 설계할 때는 “지금 모델이 좋다” 수준의 인상 비평보다, 실제로 얼마나 빨리 발전하고 있는지, 어떤 인프라가 그 속도를 떠받치고 있는지, self-improving 흐름은 어디까지 왔는지, 그리고 어떤 회사들이 어떻게 도입해 성과를 냈는지를 같이 봐야 합니다. 이 페이지는 그 질문에 대한 1차 자료 기반 요약입니다.

1. 발전 속도는 ‘긴 작업을 얼마나 해내는가’로 측정되는 흐름이 강해졌습니다

METR는 최근 frontier AI를 “긴 작업을 얼마나 성공적으로 해내는가”로 측정하는 time horizon 프레임을 계속 업데이트하고 있습니다. 2025년 블로그는 50% 신뢰도 기준 task length가 약 7개월마다 두 배씩 늘었다고 설명했고, 2026년 3월 3일 업데이트된 time horizons 페이지는 이 측정을 최신 모델들로 계속 추적하고 있습니다.

여기서 중요한 건 “AI가 더 똑똑해졌다”보다 “AI가 더 긴 multi-step task를 다룰 수 있게 됐다”는 관점입니다. 이건 곧 하네스 엔지니어링에서 context management, task decomposition, stop condition이 더 중요해진다는 뜻과 연결됩니다.

2. 올해와 그 이후를 말할 때는 시나리오 기반으로 읽어야 합니다

OECD의 2026년 보고서는 METR 데이터를 바탕으로 2030까지 여러 시나리오를 제시합니다. 여기에는 progress continues, slows, halts, accelerates 같은 서로 다른 가정이 같이 놓여 있습니다. 즉, 공식 기관 수준의 정리도 “무조건 이만큼 간다”가 아니라, 어떤 가정을 두느냐에 따라 결과가 달라진다고 봅니다.

그래서 이 사이트도 같은 원칙을 따르는 편이 안전합니다. “올해 안에 몇 시간짜리 작업을 완전히 자동화한다” 같은 표현은 과장되기 쉽고, 대신 “현재 관측 가능한 추세는 긴 작업 처리 능력과 자율 작업 길이가 꾸준히 늘고 있다” 정도가 더 정확합니다.

3. self-improving 기술은 실제로 존재하지만, 범위를 구분해야 합니다

OpenAI의 2026년 GPT-5.3-Codex 발표는 초기 버전의 Codex가 자체 개발, 배포, 테스트 진단에 도움을 줬다고 설명합니다. 이건 “에이전트가 자기 자신을 만드는 데 기여했다”는 매우 흥미로운 방향성을 보여 줍니다.

Sakana AI는 2025년 Darwin Gödel Machine을 통해 “자기 코드를 다시 써서 더 나아지는” self-improving 흐름을 공개했고, 2026년에는 AI Scientist 관련 Nature 논문 발표를 통해 자동화된 연구 루프를 더 강하게 밀고 있습니다. 다만 이걸 곧바로 “완전 자율적 자기개선 시스템이 실무에서 일반화됐다”로 읽으면 과장입니다. 현재는 연구와 실험 축이 강하다고 보는 편이 정확합니다.

4. 인프라 쪽에서는 TPU와 inference 최적화가 분명한 추세입니다

Google 은 2024년 Trillium(v6e), 2025년 Ironwood 를 발표하며 TPU 의 training + serving, 그리고 thinking · inference 모델 최적화를 강하게 밀고 있습니다. Trillium 공식 문서는 v6e 가 transformer, text-to-image, CNN 학습 · 서빙을 겨냥한다고 설명합니다. Google 은 Ironwood 를 “age of inference” 를 위한 TPU 라고 직접 표현합니다.

즉, 모델 자체만 발전하는 것이 아니라, 그 모델을 더 길고 더 자주 더 안정적으로 돌릴 수 있게 해 주는 하드웨어와 서빙 스택이 같이 발전하고 있습니다. 하네스 엔지니어링 관점에서 이 변화는 매우 중요합니다. reasoning-heavy 모델과 long-running agent 가 늘수록 latency, cost, availability 문제가 함께 커지기 때문입니다.

5. 회사 도입 사례는 이미 ‘실험’을 넘어서고 있습니다

6. 실제로 잘되는 회사들의 공통점

• 모델만 도입하지 않고 workflow와 guardrails를 같이 설계합니다.
• incident response, code review, documentation, build/test처럼 측정 가능한 업무부터 붙입니다.
• 사람 검토를 없애기보다, 사람이 봐야 할 범위를 더 전략적인 층으로 올립니다.
• 도입 효과를 추상적 만족도가 아니라 시간 단축, 품질 향상, adoption rate 같은 지표로 봅니다.

7. 이 사이트 관점으로 번역하면

이 모든 흐름은 결국 한 방향으로 모입니다. 모델의 지능은 계속 오르고 있고, 자율 작업 길이는 늘고 있으며, self-improving 연구와 inference 인프라도 빠르게 발전하고 있습니다. 하지만 회사가 실제로 성과를 내는 지점은 모델 이름이 아니라, 하네스와 운영 설계 를 같이 붙이는 곳입니다.

그래서 사내 도입 문서에서는 항상 세 가지를 같이 봐야 합니다. 첫째, 모델과 인프라의 발전 속도. 둘째, 그 모델을 감싸는 guardrails와 workflow. 셋째, 도입 이후의 metrics와 실제 사례. 이 셋이 같이 있을 때만 “요즘 트렌드”가 아니라 “우리 조직에서 쓸 수 있는 기술”이 됩니다.

8. 같이 읽으면 좋은 페이지