AI 모델의 발전 속도가 다시 한번 논쟁의 대상이 되고 있다.
몇 년 전에는 “GPT-4보다 강력한 AI 개발을 잠시 멈추자”는 AI Pause 주장이 화제가 됐다면, 최근에는 조금 다른 개념인 Pacing the Frontier, 즉 프런티어 AI의 발전 속도를 안전 기술과 맞추자는 주장이 등장하고 있다.
특히 최근에는 OpenAI, Anthropic 등 프런티어 AI 기업에서도 모델의 능력뿐만 아니라 Alignment, Security, Evaluation이 충분히 준비되지 않았다면 개발이나 배포 속도를 조절할 필요가 있다는 논의가 나오고 있다.
이번 글에서는 최근 다시 등장한 AI 속도 조절론이 무엇이고, 과거의 AI Pause와 무엇이 다른지 정리해본다.
1. AI Pause에서 Pacing으로
AI 개발 속도에 대한 논쟁이 처음 나온 것은 아니다.
2023년 Future of Life Institute가 공개한 서한에서는 GPT-4보다 강력한 AI 시스템의 훈련을 최소 6개월간 중단하자는 주장이 제기됐다.
당시 논리는 비교적 단순했다.
AI의 능력이 너무 빠르게 발전하고 있으니, 잠시 개발을 멈추고 안전성과 규제 체계를 정비할 시간을 확보하자.
하지만 실제 AI 산업의 발전을 일괄적으로 멈추기는 현실적으로 어렵다. 최근 등장한 Pacing은 조금 다른 접근법이다. Pacing의 핵심은 AI 연구 자체를 멈추는 것이 아니라,
AI의 Capability가 Safety, Alignment, Security보다 빠르게 발전하지 않도록 속도를 조절하자.
는 것이다.

기존 Pacing에서는 중간에 안전 검증 단계를 넣었다면, 이번에 제안하는 방식은 위험 수준이 일정 기준을 넘어가면 다음 단계의 훈련이나 배포를 잠시 늦추고 안전 기술이 따라올 시간을 확보하는 방식이다.
2. 왜 지금 다시 속도 조절론이 등장했을까?
가장 큰 변화 중 하나는 AI가 AI 개발 자체에 참여하기 시작했다는 것이다.
과거 AI는 사람이 작성한 질문에 답하거나 코드를 생성해주는 도구에 가까웠다. 하지만 최근의 AI Agent는 코드 작성뿐만 아니라 테스트, 디버깅, 브라우저 사용, 도구 호출, 데이터 분석 등 상당히 긴 작업을 자동으로 수행할 수 있다. 이를 AI 연구에 적용하면 다음과 같은 구조가 가능하다.
AI 성능 향상
↓
AI의 Coding / Research 능력 향상
↓
AI 개발 자동화
↓
새로운 AI 개발 속도 향상
↓
더 강력한 AI 등장
↓
AI 개발 자동화 능력 증가
↓
반복
이러한 구조는 흔히 Recursive Self-Improvement (RSI) 와 연결해서 이야기된다.
물론 AI가 스스로 계속 성능을 높이면서 폭발적인 Intelligence Explosion으로 이어질지는 아직 불확실하다.
하지만 AI가 소프트웨어 개발과 AI 연구를 자동화하면서 다음 세대 AI를 만드는 시간을 단축할 가능성 자체는 이전보다 현실적인 논점이 되고 있다.
이 때문에 단순히 현재 AI 모델의 위험성만 평가하는 것이 아니라,
AI 발전 속도 자체가 앞으로 얼마나 빨라질 수 있는가?
라는 문제가 중요해지고 있다.
3. AI Agent의 등장도 위험의 성격을 바꿨다
또 하나의 중요한 변화는 Agent다. 기존 챗봇에서는 모델이 잘못된 답을 만들어도 대부분 화면 안에서 문제가 끝났다.
하지만 Agent는 다르다.
LLM
↓
Reasoning
↓
Tool Call
↓
Browser / Terminal / API
↓
External System
↓
Action
AI의 판단이 실제 시스템의 행동으로 이어질 수 있다. 특히 Cybersecurity나 Software Engineering 분야에서는 AI가 직접 코드를 실행하거나 시스템을 분석하고 다양한 도구를 사용할 수 있기 때문에 모델의 Capability가 증가할수록 새로운 안전 문제가 발생할 수 있다.
결국 AI Safety의 문제가 단순히
“AI가 이상한 답변을 하는가?”
에서
“AI에게 어느 수준까지 실제 행동 권한을 줄 수 있는가?”
로 이동하고 있는 것이다.
4. OpenAI도 실제 개발 과정에서 속도를 늦추기 시작했다
최근 논의에서 흥미로운 부분은 속도 조절이 더 이상 선언적인 주장에만 머물지 않는다는 점이다.
OpenAI는 2026년 공개한 Pacing model development in an era of cyber-critical capabilities에서 일부 frontier model 개발 과정에서 추가적인 cybersecurity 평가와 보안 검증을 위해 개발 속도를 조절한 사례를 공개했다.
핵심적인 개념은 다음과 같다.

즉 새로운 모델이 특정 위험 수준에 접근하면 무조건 다음 훈련 단계로 넘어가는 것이 아니라 평가 → 안전 조치 → 재평가 과정을 추가하는 것이다.
이렇게 보면 Pacing은 단순한 AI 윤리 원칙보다는 점점 AI 개발 프로세스에 들어가는 Engineering Control에 가까워지고 있다.
5. Pacing the Frontier 공개서한
이러한 흐름을 대표하는 움직임 중 하나가 Pacing the Frontier 공개서한이다.

OpenAI, Anthropic, Google DeepMind, Meta 등 프런티어 AI 기업에서 일하는 연구자와 관계자들이 참여했으며, 핵심 주장은 AI 개발 속도를 조절할 수 있는 기술적·제도적 메커니즘을 준비해야 한다는 것이다.
여기서 중요한 문제가 하나 있다.
바로 경쟁이다.
예를 들어 한 AI 기업이 안전 문제 때문에 개발을 늦춘다고 생각해보자.
Company A
Safety 문제 발견
↓
AI 개발 속도 감소
Company B
계속 Scaling
↓
더 강력한 모델 출시
↓
시장 경쟁력 증가
Company A 입장에서는 안전을 위해 올바른 선택을 했더라도 시장에서는 오히려 불리해질 수 있다.
국가 간에도 같은 문제가 발생한다. 미국 기업이 개발을 늦추더라도 다른 국가의 AI 기업이 계속 개발한다면 기술 경쟁에서 뒤처질 수 있다는 우려가 나온다. 제일 크게 거론되는게 미국 vs 중국으로 보인다.
그래서 최근 속도 조절론은 단순히
“AI 기업들이 알아서 천천히 개발하자.”
가 아니라,
“여러 Frontier AI 기업이 함께 적용할 수 있는 기준을 만들자.”
는 방향으로 발전하고 있다.
6. Dario Amodei가 제안한 Pacing 방법
Anthropic CEO Dario Amodei는 최근 We Must Pace the Frontier라는 글을 통해 보다 구체적인 방법을 제안했다.
대표적인 것이 Embedded Evaluators다. 외부 안전 평가자가 프런티어 AI 기업 내부에 들어가 모델과 개발 과정을 평가할 수 있도록 하자는 개념이다. 구조를 단순하게 표현하면 다음과 같다.
Frontier AI Lab
Training
↓
Model
↓
Internal Evaluation
↓
Independent / Embedded Evaluation
↓
Risk Assessment
↓
Continue / Slow / Pause
기업이 자신의 모델을 스스로 평가하는 것만으로는 이해관계 충돌이 발생할 수 있기 때문에 독립적인 평가 체계를 추가하자는 것이다.
여기에 기업 간 Capability Threshold와 국제적인 안전 기준까지 연결하는 것이 Pacing 논의의 장기적인 방향이다.
7. 모두가 속도 조절에 동의하는 것은 아니다
물론 AI 업계 전체가 같은 의견을 가지고 있는 것은 아니다.
속도 조절에 반대하거나 신중한 입장에서는 몇 가지 현실적인 문제를 지적한다.
첫 번째는 혁신 속도의 저하다. AI 개발 속도를 인위적으로 제한하면 의료, 과학, 로봇, 생산성 향상처럼 AI가 가져올 수 있는 긍정적인 효과 역시 늦어질 수 있다.
두 번째는 국가 간 경쟁이다. 일부 국가나 기업만 규칙을 지키면 다른 국가가 기술적으로 앞서갈 가능성이 있다.
세 번째는 Regulatory Capture 문제다. 강력한 안전 규제를 만들 경우 이미 충분한 자본과 GPU를 가지고 있는 대형 AI 기업에는 큰 문제가 아니지만, 신규 AI 기업에는 높은 진입장벽이 될 수도 있다.
마지막으로 가장 어려운 문제가 있다.
어디서부터 위험하다고 판단할 것인가?
- Cyber Capability가 어느 정도면 위험한가?
- AI Research Automation은 어디까지 허용할 것인가?
- 누가 Capability를 측정할 것인가?
- 누가 기업의 평가 결과를 검증할 것인가?
- Pause했다면 언제 다시 시작할 것인가?
Pacing이라는 아이디어보다 이러한 기준을 실제로 만드는 것이 훨씬 어려운 문제다.
8. AI 시장 전체가 느려진다는 의미는 아니다
개인적으로 이 부분이 꽤 흥미롭다.
Frontier AI의 개발 속도를 조절한다고 해서 AI 산업 전체의 발전 속도가 느려진다고 볼 필요는 없다. 오히려 AI 시장의 투자 방향이 달라질 가능성이 있다. 지금까지 경쟁의 중심이
더 큰 Model
+
더 많은 Compute
+
더 높은 Benchmark
였다면 앞으로는
Frontier Model
↓
Alignment
Evaluation
Interpretability
Cybersecurity
Agent Safety
Monitoring
Sandbox
같은 영역의 중요성이 커질 수 있다.
그리고 Application 개발자 입장에서는 또 다른 관점도 가능하다. 현재는 새로운 모델이 너무 빠르게 등장한다.
새 모델 출시
↓
Application 적용
↓
Architecture 수정
↓
더 새로운 모델 출시
↓
다시 수정
만약 Frontier Model의 세대교체 속도가 조금 느려진다면 기존 모델을 활용한 AI Agent, Enterprise AI, Vertical AI 서비스가 안정화될 시간은 오히려 늘어날 수도 있다.
물론 실제 시장이 이렇게 움직일지는 아직 알 수 없다. 다만 Frontier Model의 발전 속도와 AI Application 시장의 발전 속도를 동일하게 볼 필요는 없다는 점은 흥미로운 부분이다.
마무리 — 이제 중요한 것은 얼마나 빠르냐가 아닐 수도 있다
2023년 AI Pause 논쟁에서는 질문이 비교적 단순했다.
“AI 개발을 멈춰야 하는가?”
최근 Pacing 논쟁에서는 질문이 조금 달라졌다.
“AI Capability가 Safety보다 빠르게 발전하기 시작한다면 우리는 언제 브레이크를 밟아야 하는가?”
특히 AI Agent가 발전하고 AI가 소프트웨어 개발과 AI 연구 자체에 점점 더 많이 활용되면서 이 문제는 과거보다 현실적인 논쟁이 되고 있다.
개인적으로도 이전에 Pacing the Frontier 공개서한을 처음 봤을 때는 AI 개발 속도를 인위적으로 조절하는 것이 현실적으로 가능한지 의문이 있었다.
하지만 최근에는 실제 프런티어 AI 기업들이 Capability Evaluation → Safety Check → 개발 지속 여부 판단이라는 구조를 개발 프로세스에 넣기 시작하면서 조금 다른 문제로 보이기 시작했다.
결국 앞으로 AI 경쟁에서 중요한 것이 단순히
“누가 가장 빠르게 더 강력한 모델을 만드는가”
뿐만 아니라
“더 강력한 모델을 얼마나 통제 가능한 상태로 개발할 수 있는가”
까지 포함하게 될 가능성이 있다.
참고자료
- Future of Life Institute — Pause Giant AI Experiments
https://futureoflife.org/open-letter/pause-giant-ai-experiments/ - Pacing the Frontier
https://www.pacingthefrontier.com/ - Dario Amodei — We Must Pace the Frontier
https://darioamodei.com/post/we-must-pace-the-frontier - OpenAI — Pacing model development in an era of cyber-critical capabilities
https://openai.com/index/pacing-model-development-cyber-capabilities/ - International AI Safety Report 2026
https://internationalaisafetyreport.org/
'Tech Notes' 카테고리의 다른 글
| Jev 이후 등장한 Julia-1 — 거대한 LLM 대신 144M 모델이 Agent의 결정을 맡는다면 (0) | 2026.09.29 |
|---|---|
| LLM은 답을 만들고, Jev는 판단한다 — TypeSafe AI의 System One Model (0) | 2026.09.22 |
| Agent Lightning v1.0: 실제 AI Agent를 그대로 두고 RL로 학습시키는 방법 (0) | 2026.08.28 |
| LLM의 Router와 MoE는 어떻게 다를까? 모델 선택부터 Expert, Agent까지 (0) | 2026.08.19 |
| inclusionAI, Ling-3.0-flash 공개: 효율성과 에이전트 성능을 함께 노린 대형 언어 모델 (0) | 2026.08.05 |