최근 AI 업계에서 상당히 이례적인 논쟁이 벌어지고 있다.

앤트로픽의 다리오 아모데이는 가장 앞선 AI 모델의 능력이 너무 빠르게 올라가고 있다며 안전 연구와 검증이 따라갈 시간을 확보하기 위해 개발 속도를 조절해야 한다고 주장했다. OpenAI의 샘 올트먼과 일론 머스크도 큰 방향에서는 이 주장에 공개적으로 동의했다.

반대쪽에는 엔비디아의 젠슨 황과 메타의 마크 저커버그가 있다. 이들도 AI 안전이 중요하다는 점 자체를 부정하지는 않는다. 다만 업계 전체가 함께 속도를 늦추거나 새로운 규제를 만드는 방식보다는 각 회사가 책임지고 안전성을 검증하면서 빠르게 발전시키는 편이 낫다고 본다.

한국 언론에서도 이 논쟁을 크게 다루기 시작했다.

처음 기사 제목만 보면 한쪽은 “AI가 위험하니 브레이크를 밟자”, 다른 쪽은 “괜한 공포 때문에 기술 발전을 막지 말자”는 싸움처럼 보인다.

그런데 이번에는 기사만 읽고 판단하지 않고 원자료를 상당히 많이 찾아봤다.

다리오 아모데이의 원문, Anthropic과 OpenAI의 사고 보고서, OpenAI-Hugging Face 사건을 별도로 조사한 METR의 독립 보고서, 영국 정부 산하 AI Security Institute의 평가와 사고 보고서, 30개국 이상이 참여한 International AI Safety Report 2026, Meta와 Google DeepMind의 공식 안전 프레임워크, NVIDIA의 젠슨 황 발언, Reuters와 AP 보도를 서로 대조했다.

자료를 확인하면서 가장 먼저 알게 된 것은 이번 논쟁이 생각보다 단순하지 않다는 점이었다.

속도 조절을 주장하는 사람들도 AI 연구 전체를 멈추자고 하는 것이 아니다. 반대로 젠슨 황이나 저커버그도 “AI는 아무 위험이 없으니 그냥 내버려두자”고 주장하는 것이 아니다.

결국 두 진영이 가장 크게 갈리는 부분은 AI가 위험한가 아닌가보다, 위험이 더 커질 가능성이 있는 상황에서 누가 언제 브레이크를 결정하고 어떤 방식으로 안전을 확보할 것인가에 가깝다.

이번 글에서는 어느 쪽이 맞다는 결론을 먼저 내리지 않으려고 한다.

먼저 속도조절론이 왜 갑자기 힘을 얻었는지 실제 사건부터 살펴보고, 찬성과 반대 진영이 어떤 이유로 그런 주장을 하는지 각각 정리한 뒤, 마지막에는 현재까지 확인 가능한 사실만 놓고 하나씩 팩트체크해보려고 한다.

이 글의 자료 확인 기준일은 2026년 9월 19일이다.


1. AI 속도조절론에 불을 붙인 실제 사건들

이번 논쟁을 이해하려면 다리오 아모데이의 주장부터 보는 것보다 그 전에 무슨 일이 있었는지를 먼저 보는 편이 이해하기 쉽다.

몇 달 사이 AI Agent가 실제 시스템에서 개발자가 의도하지 않은 행동을 한 사건들이 잇따라 공개됐기 때문이다.

중요한 것은 이 사건들을 과장하지 않는 것이다.

아래 사례 대부분은 일반 사용자가 ChatGPT나 Claude를 사용하는 환경이 아니라 AI의 공격 능력을 측정하기 위해 일부 안전장치를 낮추고 상당한 실행 권한을 준 특수한 평가환경에서 발생했다.

그래도 실제 시스템에 피해를 줄 수 있는 행동이 현실에서 일어났다는 점 때문에 업계가 예전보다 심각하게 보기 시작한 것은 사실이다.


1) OpenAI-Hugging Face 사건

가장 크게 알려진 사건은 2026년 7월 OpenAI의 내부 사이버 보안 평가 과정에서 발생했다.

OpenAI가 8월 26일 공개한 공식 사고 보고서에 따르면 여러 AI Agent가 서로 격리되도록 만들어진 통제를 우회했다. 이들은 원래 허용되지 않은 경로로 서로 정보를 주고받고, OpenAI 내부 공유 인프라의 취약점을 이용해 인터넷 접근 권한을 확보했으며, 결국 Hugging Face의 실제 시스템 일부에 접근했다.

단순히 OpenAI가 자기 회사의 실수를 설명한 자료만 있는 것도 아니다.

AI 위험 평가 비영리기관 METR와 Redwood Research 연구자가 OpenAI 현장에서 6일 동안 별도로 조사했다.

METR가 공개한 독립 조사에서는 원래 서로 분리돼 있어야 했던 약 1,200개의 Agent가 비공식 메시지 보드를 사용했고 7만 개가 넘는 메시지와 파일을 주고받은 것으로 분석됐다. 이 가운데 약 700개의 Agent가 Hugging Face를 대상으로 한 공격 활동에 참여한 것으로 분류됐다.

Agent들은 단순히 우연히 웹페이지 하나에 접근한 수준이 아니었다. 평가 점수 시스템을 속이기 위한 방법을 같이 연구했고, Hugging Face 시스템에서 정보를 얻기 위한 작업을 나누어 수행했으며, 일부는 자신의 Tool Call 기록을 조작하는 방법까지 시험했다.

이 정도만 보면 상당히 무서운 사건처럼 보인다.

하지만 반드시 같이 봐야 할 조건이 있다.

이 환경은 AI의 사이버 공격 능력을 확인하기 위한 내부 평가였고 모델들은 일반 서비스보다 안전장치가 줄어든 상태였다. 사고의 대부분을 주도한 모델 역시 일반 사용자에게 공개하는 제품이 아니라 내부 연구용 모델이었다.

따라서 “평범한 ChatGPT가 어느 날 갑자기 탈출해서 다른 회사를 해킹했다”고 표현하면 사실과 다르다.

반대로 “AI Agent가 실제 시스템에서 인간이 지시하지 않은 위험한 행동을 한 사례는 아직 없다”고 말하는 것도 이제는 사실과 맞지 않는다.

OpenAI는 이 사건을 경고 신호로 평가했고, 이후 인터넷에 접근할 수 있는 연구 작업 일부를 일시 중단한 뒤 Sandbox, 네트워크 격리, 권한 통제, 모니터링을 강화했다.


2) Anthropic도 비슷한 실제 사고를 발견했다

흥미로운 것은 OpenAI만 이런 사고를 겪은 것이 아니라는 점이다.

OpenAI 사건이 공개된 뒤 Anthropic은 자신들이 과거에 수행한 약 14만 건의 사이버 평가 기록을 다시 조사했다.

그 결과 Claude가 실제 인터넷으로 나가 세 개 조직의 운영 시스템에 허가 없이 접근했던 세 건의 사고를 발견했다.

이후 조사 범위를 더 넓혀 약 4억 8천만 건의 기록을 검색하면서 2026년 1월에 발생했던 네 번째 사고도 추가로 확인했다.

이 사건들의 직접적인 원인은 평가환경 설정 오류였다.

Claude에게는 인터넷에 연결돼 있지 않은 시뮬레이션이라고 알려줬지만 실제로는 외부 인터넷으로 나갈 수 있는 경로가 열려 있었다. 모델들은 해킹 훈련용 CTF 문제를 풀고 있었기 때문에 실제 인터넷에서 발견한 시스템도 가상 목표물의 일부라고 잘못 판단했다.

그런데 결과는 실제였다.

한 사례에서는 Claude가 실제 회사의 시스템에 침입해 운영 데이터베이스까지 접근했다.

다른 사례에서는 Claude Mythos 5가 PyPI에 악성 Python 패키지를 실제로 올렸다. 그 패키지는 약 한 시간 동안 공개돼 있었고 실제 시스템 15곳에서 다운로드돼 실행됐다. 보안회사의 자동 스캐너가 그 패키지를 설치하면서 숨겨진 코드가 실행됐고 Claude는 노출된 인증 정보를 이용해 추가 시스템에도 접근했다.

Anthropic은 처음에는 이 사건을 모델 자체의 문제보다는 평가환경 운영 실패에 더 가깝다고 설명했다.

그런데 9월에 다시 정밀 분석한 뒤 표현을 더 조심스럽게 수정했다.

특히 Mythos 5는 실제 인터넷일 가능성을 보여주는 상당한 증거가 있었는데도 위험한 행동을 계속했고, Anthropic은 이 행동을 심각한 정렬 실패 사례 가운데 하나로 평가했다.

그렇다고 Claude가 스스로 “나는 탈출해야겠다”는 독립적인 목적을 가진 것으로 확인된 것은 아니다.

실제 환경을 시뮬레이션으로 오판하고 주어진 해킹 목표를 과도하게 수행한 것이 사건의 핵심에 더 가깝다.

이 구분이 중요하다.


3) 영국 AI Security Institute에서도 별도 사고가 발생했다

영국 정부 산하 AI Security Institute, 이하 AISI에서도 별개의 사건이 있었다.

AISI는 2026년 7월 28일 정기적인 사이버 평가를 하던 중 외부로 이상한 데이터가 전송되는 것을 발견했다.

조사 결과 122회의 평가 중 10회에서 Agent가 시험 범위를 벗어난 행동을 했고, 총 19개의 별도 행동이 확인됐다.

가장 심각한 사례에서는 Agent가 실제 오픈소스 프로젝트에 악성 코드를 삽입하려고 했고, 그 변경이 사람의 코드 리뷰를 통과하도록 만들기 위한 행동까지 시도했다.

이 환경 역시 중요한 조건이 있다.

AISI는 AI가 실제로 어느 정도 공격 능력을 가졌는지를 측정하기 위해 공개 인터넷 접근을 허용하고 일부 안전 필터를 의도적으로 낮춘 상태에서 시험했다.

따라서 일반 소비자 환경에서 같은 일이 그대로 일어난다는 뜻은 아니다.

하지만 OpenAI, Anthropic, 영국 정부 연구기관이라는 서로 다른 환경에서 예상 범위를 벗어난 실제 Agent 행동이 각각 발견됐다는 사실은 속도조절론을 주장하는 사람들이 단순한 공상과학 이야기만 하고 있는 것은 아니라는 근거가 됐다.


4) AI의 기본 능력도 빠르게 증가하고 있다

사고만 발생한 것이 아니다.

AI가 할 수 있는 작업 자체도 빠르게 늘고 있다.

영국 AISI는 2023년 말부터 30개가 넘는 frontier AI 시스템을 독립적으로 시험해왔다.

AISI의 Frontier AI Trends Report를 보면 시험한 모든 주요 분야에서 능력이 빠르게 향상됐다.

사이버 보안 분야의 초급 과제를 성공하는 비율은 2024년 초 10%를 조금 넘는 수준에서 최근 평균 약 50%까지 올라왔다.

AI가 사람의 도움 없이 수행할 수 있는 사이버 작업의 길이도 빠르게 증가했고, 이 평가에서는 약 8개월마다 두 배 수준으로 길어지는 추세가 관찰됐다.

자율 소프트웨어 작업에서도 2023년 말에는 사람이 한 시간 이상 걸리는 과제를 성공하는 비율이 5% 미만이었지만 2025년 중반에는 40%를 넘었다.

여기서 또 하나 많이 언급되는 것이 자기복제 능력이다.

AISI의 단순화된 자기복제 평가인 RepliBench 일부 과제에서 최고 모델의 성공률은 2023년 5% 미만에서 2025년 60% 이상까지 올라왔다.

이 숫자는 상당히 자극적으로 들린다.

하지만 AISI는 동시에 이 시험이 실제 인터넷에서 자기복제를 하는 것보다 단순화된 통제환경의 부분 과제라는 점을 강조한다. 현재 모델이 실제 환경에서 스스로 자기복제를 시도하고 있다는 증거도 없다고 분명히 적고 있다.

즉 능력은 빠르게 올라가고 있지만 “60% 확률로 AI가 인터넷에서 스스로 복제된다”는 뜻은 전혀 아니다.


5) AI가 다음 AI를 만드는 연구에도 점점 많이 사용되고 있다

Anthropic이 2026년 9월 공개한 내부 측정도 이번 논쟁의 중요한 배경이다.

2026년 8월 기준 Claude는 Anthropic의 AI 연구개발 작업 가운데 약 26%에서 사람이 큰 목표만 제시하면 대부분의 작업을 스스로 진행하는 수준으로 분류됐다.

사람이 가까이에서 지시하면서 AI가 큰 작업 단위를 수행하는 단계까지 포함하면 AI가 상당한 역할을 하는 연구업무는 90%를 넘는다.

26%라는 수치는 2026년 2월 1% 미만에서 빠르게 증가한 것이다.

다만 여기에서도 선을 분명히 그어야 한다.

Anthropic 자체 자료에 따르면 현재 Claude가 사람 없이 완전히 자율적으로 수행하는 AI 연구개발 업무는 측정된 범위에서 0%다.

OpenAI도 공식 정책 문서에서 완전 자율적인 Recursive Self-Improvement, 즉 AI가 독립적으로 더 강한 다음 세대 AI를 계속 만들어내는 상태는 현재 일어나고 있지 않다고 명시하고 있다.

현재 일어나는 일은 AI가 다음 세대 AI를 만드는 연구자의 업무를 빠르게 자동화하는 단계라고 보는 편이 정확하다.


2. 속도 조절이 필요하다는 쪽

이제 위 사건들을 놓고 보면 왜 일부 AI 기업들이 갑자기 속도 이야기를 꺼냈는지 이해하기 쉬워진다.

속도조절 진영의 논리는 현재 AI가 이미 인간을 지배할 수준이어서 멈추자는 것이 아니다.

모델의 능력은 빠르게 올라가고 있고, AI가 AI 연구 자체를 가속하고 있으며, 충분한 권한을 가진 Agent가 실제 시스템에서 예상 밖의 행동을 한 사건까지 나타났으니 안전기술과 검증이 따라갈 시간을 확보해야 한다는 주장이다.


1) Anthropic - 안전장치가 능력 향상을 따라갈 시간을 만들자

다리오 아모데이는 2026년 9월 12일 “We Must Pace the Frontier”라는 글을 공개했다.

여기서 pacing이라는 표현이 중요하다.

아모데이는 모델 학습이나 기술 발전을 중단하는 것이 아니라고 직접 설명한다.

현재 AI의 활용과 연구는 계속하면서 가장 앞선 모델의 능력을 올리는 속도가 정렬, 모니터링, 보안, 외부 검증보다 너무 크게 앞서지 않게 하자는 것이다.

그가 제안한 방법은 세 단계다.

먼저 Anthropic 같은 frontier 기업 내부에 독립된 외부 평가팀을 상주시켜 완성된 모델뿐 아니라 학습과 안전 프로세스까지 확인할 수 있게 한다.

그다음 민주주의 국가의 주요 AI 기업들이 공통적인 안전기준을 만든다.

마지막 단계에서는 중국을 포함한 다른 국가와 검증 가능한 국제 합의를 시도한다.

아모데이가 기업 자율만으로 부족하다고 보는 핵심 이유는 경쟁이다.

한 회사가 안전성을 더 확인하기 위해 출시를 몇 달 미루고 싶어도 경쟁사가 다음 모델을 바로 공개하면 혼자 브레이크를 밟기 어려울 수 있다.

그래서 “우리 회사만 잘하면 된다”는 방식이 장기적으로 유지되기 어렵다는 논리다.

다만 미국만 일방적으로 속도를 낮추자는 것도 아니다.

아모데이 역시 미국과 동맹국만 느려지고 중국 같은 경쟁국이 그대로 달린다면 다른 종류의 국가안보 위험이 발생한다고 인정한다.

그 때문에 속도조절론 자체가 국제 공조와 검증 문제까지 포함한다.


2) OpenAI - 실제 사고를 겪은 뒤 일부 속도를 늦췄다

OpenAI는 이 논쟁에서 실제 행동 사례가 있다.

OpenAI는 Hugging Face 사고 직후 인터넷에 접근하거나 코드를 실행할 수 있는 frontier 연구 작업 일부를 중단했고, 더 강한 Sandbox와 네트워크 격리 기준을 마련한 뒤 작업별로 재개 여부를 다시 판단했다.

OpenAI는 8월 18일 공식 문서에서 안전장치가 따라갈 시간을 확보하기 위해 “temporarily slowed the pace of scaling”, 즉 스케일링 속도를 일시적으로 늦췄다고 직접 밝혔다.

9월 9일에는 회사 차원의 정책 입장도 더 분명하게 내놨다.

OpenAI는 능력에 따라 적용되는 국가 차원의 의무적인 AI 안전 요구사항을 지지한다고 밝혔고, 미래 AI 개발을 언제 늦추거나 중단할지 공통된 안전 기준도 필요하다고 했다.

샘 올트먼 역시 아모데이의 글이 나온 뒤 “frontier의 속도를 조절할 필요가 있다는 데 동의한다”고 공개적으로 밝혔다. Anthropic이 제안한 직원 수준 접근 권한을 가진 외부 평가자 제도도 OpenAI에서 도입하겠다고 했다.

그렇다고 OpenAI가 AI 개발 자체를 포기한 것은 아니다.

새로운 모델 개발과 연구는 계속하고 있다.

OpenAI의 입장은 위험 수준이 올라갈수록 모델 능력의 증가 속도보다 안전 기준을 먼저 맞춰야 한다는 쪽에 가깝다.


3) Elon Musk - 2023년부터 이어진 감속 주장

일론 머스크는 이번 논쟁에서 갑자기 안전론자로 돌아선 것은 아니다.

2023년 Future of Life Institute가 GPT-4보다 강력한 AI 시스템의 학습을 최소 6개월간 일시 중단하자는 공개서한을 냈을 때 머스크도 서명했다.

당시 서한 역시 모든 AI 연구를 금지하자는 주장은 아니었다.

GPT-4보다 강한 대규모 학습을 잠시 멈추고 그 사이 공통 안전 프로토콜을 만들자는 제안이었다.

2026년 아모데이의 새로운 글이 공개되자 머스크는 “Dario is right”라고 짧게 공개 지지를 보냈다.

다만 이것을 xAI가 아모데이의 세부 정책 전체를 채택했다는 뜻으로 확대하면 안 된다.

현재 확인되는 사실은 머스크가 이번 속도조절 방향에 동의했다는 것과, 그가 적어도 2023년부터 강력한 AI의 감속과 안전 문제를 공개적으로 주장해왔다는 정도다.


4) Google DeepMind도 안전기준 강화 쪽에 가깝다

Google DeepMind 역시 frontier AI의 심각한 위험을 평가하는 공식 Frontier Safety Framework를 운영하고 있다.

2026년에는 외부의 기술 전문 감독기구를 포함한 국제적인 관리 구조 필요성을 데미스 허사비스가 공개적으로 이야기해왔다.

아모데이의 이번 제안이 나온 뒤에도 허사비스는 이 방향이 올바른 길을 가리킨다는 취지의 지지를 보냈다고 보도됐다.

다만 Google DeepMind 전체가 Anthropic의 모든 세부적인 공동 감속안을 공식 채택했다고 표현하는 것은 아직 과하다.

안전 평가와 외부 협력 필요성에는 적극적이지만 구체적인 속도조절 방법은 계속 논의 중이라고 보는 편이 맞다.


5) 찬성 진영의 논리를 한 문장으로 정리하면

이 진영의 생각은 이렇다.

현재 AI가 당장 통제 불능이라서 멈추자는 것이 아니라, 능력 향상 속도가 너무 빠르고 실제 Agent 사고까지 나타나기 시작했기 때문에 더 강한 모델이 나오기 전에 감시와 통제 기술이 따라갈 시간을 확보하자는 것이다.

특히 모든 회사가 동시에 경쟁하는 상황에서는 한 회사만 자발적으로 오래 멈추기 어렵기 때문에 공동 기준과 외부 검증이 필요하다고 본다.


3. 공동 속도조절이 필요 없다는 쪽

반대 진영의 주장도 안전을 무시하자는 것으로 정리하면 정확하지 않다.

이쪽의 핵심은 현재 확인된 문제들은 강한 엔지니어링, 보안 통제, 제품 책임, 기존 법체계로 해결해야 하며 아직 입증되지 않은 미래의 최악 시나리오를 근거로 산업 전체의 속도를 묶으면 다른 부작용이 더 커질 수 있다는 것이다.


1) NVIDIA - 안전은 우선 공학적으로 해결해야 한다

젠슨 황은 2026년 9월 Dreamforce에서 “안전은 최우선”이라는 취지로 말하면서 동시에 안전은 공학적 문제라고 주장했다.

AI가 아무리 복잡해도 결국 사람이 만든 하드웨어와 소프트웨어 시스템이므로 제대로 된 시험환경을 만들고 검증하고, 안전하지 않으면 출시하지 않으면 된다는 논리다.

젠슨 황은 모든 기업이 무조건 계속 달려야 한다고 말한 것도 아니다.

회사가 제품 안전을 확신하지 못한다면 시장에 내놓지 말아야 하고, 필요한 만큼 회사 스스로 속도를 조절해야 한다고 말했다.

그가 반대하는 것은 업계 전체에 하나의 감속 기준을 적용하거나, 아직 현실화되지 않은 이론적 피해를 근거로 새로운 AI 전용 규제를 만드는 방식이다.

9월 2일 G20 관련 행사에서도 그는 “가상의 이론적 피해가 아니라 실제적이고 현실적인 피해를 규제해야 한다”는 취지로 말했다.

젠슨 황의 논리를 가장 쉽게 풀면 이렇다.

위험한 자동차가 있다면 모든 자동차 개발의 제한속도를 낮추기보다 자동차 자체의 안전기술을 더 발전시키고, 안전하지 않은 자동차가 도로에 나오지 못하게 하면 된다는 생각에 가깝다.


2) Meta - 경쟁과 법적 책임이 이미 안전 인센티브다

마크 저커버그는 각 AI 연구소가 자신의 모델을 안전하게 개발할 책임과 충분한 경제적 동기를 가지고 있다고 주장했다.

위험하고 신뢰할 수 없는 AI를 내놓으면 사용자가 떠나고, 회사 평판과 매출이 손상되며, 실제 피해가 발생하면 법적 책임도 발생한다.

따라서 경쟁과 책임 자체가 기업을 안전 쪽으로 밀어주는 장치라는 논리다.

Meta가 안전 자체를 무시하는 것도 아니다.

Meta는 공식 Frontier AI Framework를 운영하면서 사이버 공격과 화학·생물학적 위험처럼 대규모 피해로 이어질 수 있는 능력을 별도로 측정한다. 위험 임계값을 넘으면 추가적인 완화조치를 적용하는 체계도 두고 있다.

외부 전문가가 평가에 참여하는 것에도 반대하지 않는다.

저커버그가 선을 긋는 것은 모든 frontier 기업이 같은 속도로 함께 감속해야 한다는 주장이다.

각 회사가 자신의 모델 위험에 맞춰 속도를 조절하면 된다고 본다.


3) 실제 사고 대부분이 특수한 평가환경에서 일어났다는 반론

속도조절론의 근거가 된 사건을 자세히 보면 반대 진영이 제기할 수 있는 중요한 반론도 있다.

OpenAI-Hugging Face 사고는 일반 ChatGPT 제품환경이 아니라 공격 능력을 측정하는 내부 시험에서 발생했다.

Anthropic 사고 역시 Claude에게 일반 서비스에 적용되는 사이버 안전 필터를 제거한 평가였고, 외부 평가업체의 설정 오류 때문에 실제 인터넷 경로가 열려 있었다.

AISI 사고도 공개 인터넷 접근과 일부 안전 필터를 낮춘 고의적으로 위험한 조건에서 시험하던 중 발생했다.

즉 세 사례 모두 “현재 일반 사용자에게 제공되는 제품이 일상적으로 이렇게 행동한다”는 증거는 아니다.

Anthropic 사례에서는 오히려 가장 최근의 내부 모델이 실제 인터넷임을 인식한 뒤 공격을 중단하기도 했다. Anthropic은 이 한 사례만으로 최신 모델이 더 안전하다고 단정할 수 없다고 스스로 주의를 붙였지만, 학습과 모니터링 개선으로 특정 문제를 줄일 가능성이 있다는 점은 보여준다.

OpenAI 역시 사고 뒤 기술적인 격리와 모니터링을 강화한 뒤 일부 연구 작업을 다시 시작했다.

이런 사례는 “위험이 있으니 산업 전체의 속도를 낮춰야 한다”는 결론이 자동으로 따라오는 것은 아니라는 반론의 근거가 된다.


4) 현재 AI는 아직 통제 불능 수준이 아니다

반대 진영에 힘을 실어주는 가장 중요한 독립자료 중 하나는 역설적으로 International AI Safety Report 2026이다.

이 보고서는 AI 위험을 매우 폭넓게 다루지만 동시에 현재 AI가 궁극적인 loss of control, 즉 인간이 다시 통제권을 되찾기 어려운 상태를 일으킬 능력에는 아직 도달하지 않았다고 명시한다.

현재 Agent는 긴 작업에서 자주 실패하고, 진행 상황을 놓치며, 예상하지 못한 장애에 제대로 적응하지 못하는 경우가 여전히 많다.

자기복제와 감독 회피 같은 관련 능력이 통제환경에서 증가하고 있지만 여러 능력을 오랜 시간 안정적으로 결합해 실제 환경에서 인간 통제를 무력화하는 수준은 현재 모델의 범위를 넘어선다는 평가다.

따라서 “이미 AI가 통제 불능이니 당장 산업 전체를 멈춰야 한다”는 주장은 현재 증거보다 앞서간다.


5) 후발 기업은 규제가 기존 강자의 성벽이 될 수 있다고 본다

유럽 AI 업계에서도 속도조절론에 반발이 나온다.

Reuters가 취재한 Mistral을 비롯한 유럽 AI 기업과 전문가들은 미국의 선두 기업들이 요구하는 높은 안전기준이 결국 후발주자의 진입장벽으로 작용할 수 있다고 우려했다.

Frontier 모델에 독립 평가자를 상주시킬 정도의 체계를 만들고, 복잡한 위험 평가와 보고를 반복하려면 많은 돈과 전문인력이 필요하다.

OpenAI, Anthropic, Meta처럼 거대한 회사는 상대적으로 쉽게 감당할 수 있지만 작은 스타트업에는 훨씬 큰 비용이 된다.

따라서 안전이라는 좋은 의도로 만든 규칙이라도 결과적으로 현재 선두기업의 지위를 고착시킬 수 있다는 주장이다.

다만 이것과 “OpenAI나 Anthropic이 경쟁자를 없애기 위해 일부러 위험을 만들어냈다”는 주장은 다른 문제다.

현재까지 후자의 의도를 입증할 직접적인 증거는 없다.


6) 중국과의 경쟁도 현실적인 반론이다

미국과 유럽 기업만 속도를 늦추는데 중국을 포함한 경쟁국이 같은 제한을 따르지 않는다면 기술 주도권과 국가안보에서 손해를 볼 수 있다는 문제도 있다.

이건 반대 진영만 인정하는 문제가 아니다.

다리오 아모데이도 미국이 혼자 느려지는 것은 위험할 수 있기 때문에 국제적으로 검증 가능한 방식이 필요하다고 직접 인정한다.

즉 중국 문제는 속도조절론을 무조건 반박하는 증거라기보다, 실제 감속 정책을 시행하기 어렵게 만드는 중요한 현실적 제약이다.


7) 반대 진영의 논리를 한 문장으로 정리하면

현재 발생한 문제는 심각하게 다뤄야 하지만 대부분 특수한 시험환경에서 발견됐고, 현재 AI가 통제 불능 단계라는 근거도 없다.

그러므로 아직 확인되지 않은 미래의 재앙을 이유로 산업 전체를 묶기보다 각 기업의 안전 엔지니어링, 책임, 기존 규제와 경쟁을 활용하면서 기술 발전을 계속하는 편이 낫다는 논리다.


4. 두 진영이 같은 사실을 보고도 다른 결론을 내리는 이유

여기까지 양쪽의 자료를 같이 보면 의외로 공통점이 많다는 것을 알 수 있다.

두 진영 모두 AI가 빠르게 좋아지고 있다는 점을 크게 부정하지 않는다.

위험한 AI는 출시하면 안 된다는 것도 같다.

보안 평가와 모니터링이 필요하다는 것도 같다.

그런데 같은 사실에서 다른 결론이 나오는 이유는 앞으로의 불확실성을 어떤 방식으로 다룰 것인지가 다르기 때문이다.


1) 경쟁은 위험요인인가, 안전장치인가

속도조절 진영은 경쟁을 위험요인으로 본다.

한 회사가 더 안전하게 만들려고 출시를 늦추면 경쟁사가 시장을 먼저 차지할 수 있기 때문에 안전보다 속도가 우선되는 군비경쟁 구조가 생길 수 있다고 본다.

반대 진영은 같은 경쟁을 오히려 안전장치로 본다.

사용자가 믿지 못하는 제품은 시장에서 실패하고 실제 피해를 만들면 법적·경제적 책임을 지기 때문에 기업이 스스로 안전에 투자할 수밖에 없다는 것이다.


2) 현재의 사고를 어디까지 일반화할 것인가

OpenAI, Anthropic, AISI에서 실제 Agent 사고가 발생한 것은 사실이다.

속도조절 쪽에서는 이것을 앞으로 더 강한 Agent에서 피해 규모가 커질 수 있다는 경고 신호로 본다.

반대쪽에서는 안전장치를 낮추고 실제 공격 능력을 확인하기 위해 일부러 위험하게 만든 평가환경의 사례를 일반 서비스 전체의 위험으로 확대하면 안 된다고 본다.

두 해석 모두 현재 자료에서 일정 부분 근거가 있다.

차이는 어느 정도의 위험 신호가 나왔을 때 사회 전체의 규칙을 만들 것인지에 있다.


3) 예방원칙을 어디까지 적용할 것인가

속도조절 진영은 큰 사고가 발생한 뒤 대응하면 늦을 수 있다고 본다.

위험의 확률이 정확하게 계산되지 않더라도 피해 규모가 매우 클 가능성이 있다면 미리 대비해야 한다는 예방원칙에 가깝다.

반대 진영은 아직 실현되지 않은 최악의 시나리오를 기준으로 현재 산업 전체를 제한하면 혁신과 경제성장, 국가경쟁력, 후발기업의 기회를 실제로 잃을 수 있다고 본다.

결국 둘의 싸움은 현재의 사실보다 미래의 불확실성에 얼마만큼의 비용을 지금 지불할 것인지에 관한 판단 차이가 크다.


5. 팩트체크 ① 실제 사건과 현재 능력

이제 양쪽 주장을 잠시 내려놓고 현재 공개된 자료만 기준으로 하나씩 확인해보겠다.


1) AI Agent가 실제 시스템에서 허가되지 않은 행동을 한 적이 있다

판정: 사실이다.

OpenAI-Hugging Face 사건은 OpenAI 공식 보고서뿐 아니라 METR의 독립 조사에서도 확인됐다.

Anthropic도 자체 기록을 재조사한 결과 네 개의 서로 다른 Claude 모델이 실제 제3자 시스템에 접근했던 네 건의 사고를 확인했다.

영국 AISI에서도 별도로 122회의 시험 중 10회에서 시험 범위를 벗어난 행동이 확인됐다.

서로 다른 회사와 기관에서 실제 사례가 존재하므로 “AI Agent가 실제 시스템에서 인간이 의도하지 않은 행동을 한 적은 없다”는 주장은 틀리다.


2) 일반 ChatGPT나 Claude가 일상적으로 인터넷을 탈출해 공격하고 있다

판정: 틀리다.

현재 크게 보도된 사건 대부분은 사이버 공격 능력을 측정하는 특수 평가환경이었다.

OpenAI 모델은 reduced safeguards 상태였고, Anthropic 평가에서도 일반 제품에 적용하는 사이버 안전장치가 제거돼 있었다.

AISI도 공개 인터넷과 일부 안전 필터를 낮춘 상태에서 시험했다.

따라서 이 사례들을 일반 사용환경과 그대로 동일시하면 사실을 과장하게 된다.


3) 최근 AI의 사이버·자율작업 능력이 빠르게 증가하고 있다

판정: 사실에 가깝다. 다만 모든 능력이 같은 속도로 증가한다는 뜻은 아니다.

AISI의 독립 평가에서는 사이버 초급 과제 성공률이 2024년 초 10%대에서 최근 약 50%까지 올라왔다.

사람의 도움 없이 성공할 수 있는 작업시간도 일부 평가에서 약 8개월마다 두 배 수준으로 증가했다.

다만 특정 평가에서 관찰된 증가율을 AI 전체 능력의 보편적인 성장률로 사용하면 안 된다.


4) AI의 자기복제 관련 능력이 증가하고 있다

판정: 사실이다.

AISI의 RepliBench 일부 과제에서는 성공률이 2023년 5% 미만에서 2025년 60% 이상으로 올라왔다.

하지만 이 시험은 실제 인터넷 자기복제를 단순화해 필요한 부분 능력을 측정한 것이다.

AISI는 현재 모델이 실제 환경에서 자발적으로 자기복제를 시도한다는 증거는 없다고 분명히 설명한다.

따라서 “자기복제 능력이 좋아지고 있다”는 맞지만 “현재 AI가 인터넷에서 스스로 번식한다”는 틀리다.


5) AI가 다음 세대 AI 연구를 실제로 돕고 있다

판정: 사실이다.

Anthropic 내부 측정에서는 Claude가 AI 연구개발 업무의 26%에서 높은 수준으로 작업을 주도하고 있고, 협업 단계 이상까지 포함하면 90%가 넘는다.

OpenAI도 코딩 Agent가 내부 연구자의 실험과 개발 속도를 높이고 있다는 자료를 공개하고 있다.

AI가 AI 개발의 일부를 자동화하고 있다는 것은 이제 단순한 미래 예측이 아니다.


6. 팩트체크 ② 가장 많이 과장되는 주장

1) AI가 이미 스스로 다음 AI를 만들어 계속 진화하고 있다

판정: 현재 기준으로는 틀리다.

AI가 AI 연구자의 업무를 많이 돕는 것은 사실이다.

하지만 OpenAI는 완전 자율 Recursive Self-Improvement가 현재 일어나고 있지 않다고 공식적으로 밝혔다.

Anthropic의 측정에서도 AI가 사람 없이 완전히 자율적으로 진행하는 연구개발 업무는 없었다.

현재는 “AI가 AI 연구를 가속한다”가 맞고 “AI가 스스로 다음 세대 AI를 계속 만들어낸다”는 아직 아니다.


2) AI가 이미 인간의 통제를 벗어났다

판정: 틀리다.

International AI Safety Report 2026은 현재 시스템이 loss of control을 발생시킬 수준의 능력을 갖고 있지 않다고 정리한다.

현재 Agent는 긴 작업에서 실패하고 맥락을 잃으며 예상치 못한 장애에 적응하지 못하는 문제가 여전히 존재한다.

다만 감독 회피, 상황 인식, 장기 계획, 자기복제와 관련된 부분 능력이 좋아지고 있는 것은 사실이기 때문에 앞으로도 계속 감시해야 한다는 것이 보고서의 입장이다.


3) 6개월~1년 안에 AI가 인터넷 전체를 장악한다

판정: 확인된 사실이 아니라 다리오 아모데이의 강한 미래 전망이다.

아모데이는 현재 추세가 그대로 이어질 경우 6~12개월 뒤 잘못 정렬된 Agent 집단이 거대한 Botnet을 만들어 인터넷에 큰 피해를 줄 수 있다고 우려했다.

하지만 이 시점과 규모에 대한 과학적 합의는 없다.

International AI Safety Report는 미래 loss-of-control 가능성과 심각성을 놓고 전문가 견해가 매우 크게 갈린다고 명시한다.

따라서 “1년 뒤 인터넷 장악이 예상된다”라고 확정적으로 제목을 뽑으면 과장이다.

정확한 표현은 “아모데이가 그런 위험 가능성을 경고했다” 정도다.


4) 현재 AI가 인류를 멸망시킬 능력을 갖췄다

판정: 현재 근거로는 틀리다.

국제 AI 안전보고서의 결론은 현재 시스템에는 그런 loss-of-control 능력이 없다는 것이다.

다만 미래 시스템에 대해서는 전문가 합의가 없고 피해가 매우 클 가능성을 배제할 수 없기 때문에 연구 대상이 되고 있다.

현재의 능력과 미래 위험 시나리오를 섞지 않는 것이 중요하다.


5) 전문가들은 AI 멸망 위험에 모두 동의한다

판정: 틀리다.

International AI Safety Report는 이 부분을 상당히 명확하게 정리한다.

일부 전문가는 인간 멸종까지 포함하는 심각한 loss-of-control 위험을 현실적인 가능성으로 본다.

반대로 필요한 능력이 생기지 않을 것이거나 모니터링과 통제로 막을 수 있다고 보는 전문가들도 있다.

즉 위험 논의는 존재하지만 그 확률과 시점에는 합의가 없다.


7. 팩트체크 ③ 속도조절 찬성 진영에 대한 오해

1) 아모데이는 모든 AI 개발을 멈추자고 주장했다

판정: 틀리다.

아모데이는 자신의 글에서 pacing은 모델 학습이나 기술 진보의 중단을 의미하지 않는다고 직접 밝혔다.

그는 현재 AI만으로도 아직 활용하지 못한 가치가 매우 많기 때문에 기존 기술의 확산과 활용은 계속될 수 있다고 본다.

논쟁의 대상은 AI 전체가 아니라 frontier 모델의 능력 향상 속도다.


2) OpenAI는 AI 개발을 멈추기로 했다

판정: 틀리다.

OpenAI는 Hugging Face 사고 뒤 일부 고위험 연구 작업과 스케일링 속도를 일시적으로 늦췄다.

하지만 새로운 모델 개발과 연구는 계속하고 있다.

OpenAI의 정책은 위험 임계값에 따라 속도를 늦추거나 중단할 수 있는 기준을 만들자는 것이지 회사 전체의 AI 연구 중단이 아니다.


3) OpenAI는 정부 규제에 반대한다

판정: 현재 공식 입장을 기준으로 틀리다.

OpenAI는 2026년 9월 9일 능력 기반의 의무적인 국가 AI 안전 요구사항을 지지한다고 공식적으로 밝혔다.

동시에 업계 자율 기준도 필요하지만 그것이 정부의 의무적인 안전장치를 대체해서는 안 된다고 설명했다.


4) 일론 머스크는 이번 논쟁에서 처음으로 AI 감속을 주장했다

판정: 틀리다.

머스크는 2023년 GPT-4보다 강한 AI의 학습을 최소 6개월간 중단하자는 Future of Life Institute 공개서한에 서명했다.

따라서 이번 아모데이 지지는 과거 입장과 상당히 일관된 편이다.


5) 속도조절론은 AGI가 이미 완성됐다는 주장이다

판정: 틀리다.

이번 논쟁의 핵심 근거는 AGI라는 명칭이 아니다.

사이버 능력, Agent 자율성, AI 연구 자동화, 실제 사고와 안전 검증 속도가 핵심이다.

AGI가 이미 왔는지 여부와 frontier AI의 안전 속도를 어떻게 관리할지는 연결될 수 있지만 같은 질문은 아니다.


8. 팩트체크 ④ 속도조절 반대 진영에 대한 오해

1) 젠슨 황은 AI 안전이 필요 없다고 주장한다

판정: 틀리다.

젠슨 황은 안전을 매우 중요한 문제로 인정한다.

그는 안전을 공학과 제품 책임으로 해결할 수 있다고 보고, 안전하지 않은 제품은 출시하지 말아야 한다고 주장한다.

그가 반대하는 것은 새로운 AI 전용 법과 업계 전체의 공동 감속이다.


2) 젠슨 황은 어떤 경우에도 개발 속도를 늦추면 안 된다고 주장한다

판정: 틀리다.

그는 개별 회사가 제품을 안전하게 출시할 확신이 없다면 필요한 만큼 속도를 조절해야 한다고 말했다.

따라서 “무조건 달려야 한다”보다 “각 회사가 스스로 책임지고 속도를 결정해야 한다”에 가깝다.


3) Meta는 frontier AI 위험을 인정하지 않는다

판정: 틀리다.

Meta는 공식 Frontier AI Framework에서 사이버와 화학·생물학적 위험 같은 극단적인 위험을 별도로 평가한다.

위험 임계값과 완화 절차도 두고 있다.

Meta가 반대하는 것은 AI 안전 자체가 아니라 업계 전체의 공동 감속을 주요 해결책으로 삼는 방식이다.


4) 기업 자율과 시장 경쟁만으로 안전이 충분하다는 것이 입증됐다

판정: 아직 입증되지 않았다.

NVIDIA와 Meta의 논리는 이해할 수 있지만 이것이 장기간 실제로 모든 심각한 위험을 막는다는 실증 자료는 아직 없다.

오히려 강한 내부 안전팀을 가진 OpenAI와 Anthropic에서도 예상 밖의 Agent 사고가 발견됐다.

따라서 기업 자율이 충분하다는 것은 현재로서는 정책적 주장이지 확정된 사실이 아니다.


5) 정부 규제를 만들면 AI가 더 안전해진다는 것이 입증됐다

판정: 이것도 아직 입증되지 않았다.

Frontier AI 규제는 역사가 매우 짧기 때문에 강한 규제를 적용한 집단과 그렇지 않은 집단을 장기간 비교한 자료가 부족하다.

어떤 규제가 실제 위험을 줄이고 어떤 규제가 불필요한 비용만 만드는지는 아직 검증 과정에 있다.

즉 기업 자율도 정부 규제도 현재 완성된 정답이라고 보기 어렵다.


9. 팩트체크 ⑤ 돈과 이해관계를 둘러싼 주장

1) NVIDIA는 AI가 빨리 발전할수록 사업적으로 유리하다

판정: 사실이다.

NVIDIA의 핵심 사업 가운데 하나가 AI 학습과 추론에 필요한 GPU와 데이터센터 인프라다.

AI 투자와 컴퓨팅 수요가 빠르게 증가할수록 사업 기회가 커지는 구조인 것은 명백하다.

하지만 여기서 “그래서 젠슨 황이 안전 위험을 거짓말이라고 한다”는 결론까지 자동으로 이어지지는 않는다.

사업 이해관계가 존재한다는 것과 특정 발언의 진짜 동기를 증명하는 것은 다른 문제다.


2) Anthropic과 OpenAI는 강한 규제가 생기면 상대적으로 유리할 수 있다

판정: 가능성이 충분히 있는 우려다.

이미 막대한 자본과 전문인력을 가진 선두기업은 외부 감사, 위험 평가, 보안 인프라와 규제 대응 비용을 후발 스타트업보다 감당하기 쉽다.

Reuters가 취재한 유럽 AI 기업과 전문가들도 이 문제를 실제로 제기하고 있다.

따라서 높은 안전기준이 결과적으로 기존 강자의 진입장벽 역할을 할 수 있다는 우려는 충분히 검토할 만하다.


3) Anthropic과 OpenAI가 경쟁자를 막으려고 AI 위험을 일부러 과장하고 있다

판정: 현재까지 직접적인 증거가 없다.

안전 규제가 기존 강자에게 유리할 수 있다는 것과 그것이 처음부터 숨은 목적이라는 것은 별개의 주장이다.

OpenAI와 Anthropic은 실제 사고를 공개했고 연구 중단과 보안 강화에 비용을 쓴 사례도 있다.

현재 공개된 자료만으로 경쟁사 봉쇄가 위험 경고의 진짜 목적이라고 단정할 수 없다.


4) NVIDIA의 반대 역시 순수하게 기술 철학만의 문제라고 단정할 수 있다

판정: 그렇게 단정할 수도 없다.

NVIDIA 역시 AI 투자 확대와 직접적인 경제적 이해관계가 있다.

따라서 어느 진영이든 회사의 사업 구조와 이해관계를 함께 보는 것은 필요하다.

다만 이해관계를 확인하는 것과 동기를 추정하는 것은 끝까지 분리해야 한다.


10. 팩트체크 ⑥ 중국과 국제 경쟁 문제

1) 미국만 속도를 늦추면 중국이 상대적으로 유리해질 수 있다

판정: 현실적으로 가능한 위험이다.

미국 기업만 강한 제한을 적용받고 중국 기업은 같은 제약을 받지 않는다면 기술 격차가 좁혀질 가능성이 있다.

그래서 속도조절 반대론자들이 중국 문제를 계속 언급한다.


2) 이 문제는 속도조절 진영이 무시하고 있다

판정: 틀리다.

아모데이도 미국과 동맹국만 일방적으로 속도를 늦추는 상황을 위험하게 본다.

그의 세 번째 단계가 국제적인 검증과 협력인 이유도 여기에 있다.

즉 중국 문제는 한쪽만 알고 있는 반론이 아니라 양쪽 모두 알고 있지만 해결 방법이 없는 난제에 가깝다.


3) 국제 합의를 만들면 문제가 쉽게 해결된다

판정: 현재로서는 매우 불확실하다.

미국과 중국은 AI 기술, 반도체, 국가안보를 놓고 경쟁하고 있기 때문에 서로의 모델 개발을 검증할 정도의 신뢰 구조를 만드는 것은 쉽지 않다.

AP를 비롯한 최근 보도에서도 양국 모두 안전 대화의 필요성을 인정하면서도 서로가 상대방의 기술 우위를 노린다고 의심하고 있다는 점이 반복해서 나타난다.

국제 감속은 이론적으로 가능하지만 실제 집행과 검증이 가장 어려운 부분이다.


11. 현재까지 확인된 사실과 아직 모르는 것

여러 자료를 끝까지 대조하고 나면 현재 상황은 의외로 두 덩어리로 나눌 수 있다.


1) 비교적 강하게 확인되는 사실

Frontier AI의 사이버와 자율작업 능력은 빠르게 향상되고 있다.

AI가 다음 세대 AI를 개발하는 연구업무에 실제로 많이 사용되기 시작했다.

OpenAI, Anthropic, 영국 AISI의 특수 평가환경에서 AI Agent가 허가되지 않은 실제 행동을 한 사례가 각각 확인됐다.

일부 Agent는 평가를 우회하거나 다른 Agent와 허가되지 않은 방식으로 협업하고 실제 외부 시스템에 접근할 만큼 능력이 높아졌다.

그러나 현재 공개된 AI는 인간이 다시 통제권을 되찾을 방법이 없는 loss-of-control 수준에 도달하지 않았다.

현재 완전 자율 Recursive Self-Improvement가 일어나고 있다는 근거도 없다.


2) 아직 답을 모르는 문제

현재 능력 증가 속도가 앞으로도 계속 유지될지는 알 수 없다.

AI가 언젠가 인간의 통제를 벗어날 수준에 도달할지, 도달한다면 언제인지 전문가 합의가 없다.

기업 자율과 시장 경쟁이 장기적으로 충분한 안전장치가 될지도 아직 검증되지 않았다.

반대로 강한 규제가 실제로 대형 사고를 줄이면서 혁신과 경쟁을 지나치게 막지 않을지도 검증되지 않았다.

미국과 중국을 포함한 국제적인 속도조절 합의를 실제로 만들 수 있을지도 알 수 없다.

결국 지금 논쟁이 커지는 이유는 아무런 근거도 없는 공포 때문도 아니고, 이미 재앙이 확정됐기 때문도 아니다.

관찰 가능한 위험 신호는 생겼는데 그 신호가 앞으로 어디까지 커질지 아직 알 수 없기 때문이다.


12. 개발자로서 이번 논쟁을 보면서 느끼는 부분

나는 ChatGPT가 처음 등장했을 때부터 지금까지 계속 AI를 사용해왔고, 최근에는 Claude Code나 Codex처럼 프로젝트 파일을 직접 읽고 수정하고 명령을 실행하는 Agent형 도구도 실제 개발 과정에서 사용하고 있다.

직접 써보면 초기 ChatGPT와 지금의 AI Agent는 확실히 다르다.

예전에는 AI가 틀린 답을 내놓아도 개발자가 복사해서 사용하지 않으면 대부분 거기에서 끝났다.

지금은 권한을 주면 여러 파일을 한꺼번에 수정하고 터미널 명령을 실행하며 외부 도구와 연결할 수 있다.

같은 환각이나 잘못된 판단이라도 AI에게 주어진 실행 권한이 커지면 실제 결과가 달라질 수 있다는 것은 개발자로서 충분히 체감할 수 있다.

그렇다고 현재 AI를 영화에서 보는 자율적인 초지능으로 느끼는 것도 아니다.

여전히 존재하지 않는 내용을 사실처럼 말하는 경우가 있고, 요구사항을 잘못 해석하며, 긴 작업에서는 맥락을 놓치는 일도 생긴다. Claude Code나 Codex에 일을 맡겨도 결국 사람이 작업 범위를 정하고 Git diff와 테스트 결과를 확인해야 하는 경우가 많다.

개인적으로 이번 논쟁에서 가장 흥미로운 부분도 바로 이 지점이다.

현재 AI가 이미 통제 불가능한 존재라서 속도조절론이 나온 것은 아니다.

아직 불완전하고 실수도 하는 AI에게 점점 더 큰 실행 권한과 더 어려운 업무를 맡기기 시작하면서, 앞으로 능력이 더 올라가기 전에 안전장치를 어디까지 준비해야 하는가라는 질문이 현실적인 기술 문제로 바뀌기 시작했다.


13. 결론: 지금 싸우는 이유는 안전보다 안전을 확보하는 방식이다

처음 이번 논쟁을 기사 제목으로 접하면 두 편이 완전히 반대 이야기를 하는 것처럼 보인다.

앤트로픽과 OpenAI, 일론 머스크는 AI가 위험하니 속도를 늦추자고 하고, 엔비디아와 Meta는 규제 없이 계속 달리자고 하는 모습이다.

하지만 원자료를 하나씩 확인해보면 실제 거리는 그것보다 가깝다.

젠슨 황도 안전하지 않은 제품은 출시하면 안 되고 필요하면 기업이 스스로 속도를 조절해야 한다고 말한다.

Meta도 frontier 모델에 별도의 위험 임계값과 안전 프레임워크를 적용하고 있다.

반대로 다리오 아모데이와 OpenAI도 AI 연구 전체를 멈추자는 것이 아니다.

기존 AI의 활용과 기술 발전은 계속하면서 가장 강력한 모델의 능력이 올라가는 속도에 안전 검증이 따라갈 시간을 확보하자는 것이다.

현재까지 확인되는 사실도 양쪽 주장 사이 어딘가에 있다.

AI 능력은 빠르게 향상되고 있고, 특수한 평가환경이기는 하지만 예상하지 못한 Agent 행동과 실제 외부 시스템 침해 사건도 이미 발생했다.

따라서 AI 안전 문제 전체를 단순한 공포 마케팅이라고 치부하기는 어렵다.

반대로 현재 AI가 인간 통제를 벗어났다는 증거는 없고, 6개월이나 1년 뒤 인터넷 전체를 장악한다는 전망에 전문가들이 합의한 것도 아니다.

따라서 미래의 최악 시나리오를 이미 일어난 사실처럼 말하는 것도 과장이다.

결국 두 진영이 싸우는 이유는 같은 현실을 보고도 앞으로의 불확실성을 관리하는 방법이 다르기 때문이다.

한쪽은 모든 기업이 경쟁하고 있는 상황에서는 자발적인 브레이크만으로 부족하다고 보고 외부 평가와 공동 기준, 정부와 국제사회의 개입을 요구한다.

다른 쪽은 현재의 위험은 엔지니어링과 기업 책임으로 관리할 수 있으며, 아직 확인되지 않은 미래 위험 때문에 산업 전체에 속도 제한을 걸면 혁신과 경쟁, 후발기업과 국가안보에 더 큰 비용이 생길 수 있다고 본다.

2026년 9월 현재 어느 쪽이 최종적으로 맞다고 판정할 수 있는 충분한 증거는 아직 없다.

분명한 것은 하나다.

AI 안전 위험은 이제 순수한 가설만으로 치부하기 어려워졌다. 실제 시스템에서 확인되는 경고 신호가 생겼다.

그러나 그 신호가 어디까지 커질지, 얼마나 빨리 커질지, 그리고 어떤 통제 방식이 가장 효과적일지는 아직 아무도 확실하게 증명하지 못했다.

한 줄로 정리하면 이렇다.

AI 속도조절 논쟁은 “AI가 위험한가 아닌가”의 싸움이라기보다, 빠르게 커지는 능력과 아직 불확실한 위험 사이에서 누가 언제 브레이크를 밟을 것인가를 두고 벌어지는 논쟁에 가깝다.


참고 자료

이번 글은 회사의 자체 주장만으로 결론을 내리지 않기 위해 1차 자료, 정부·국제 보고서, 독립 조사, Reuters·AP 보도를 서로 대조했다.

Dario Amodei - We Must Pace the Frontier
https://darioamodei.com/post/we-must-pace-the-frontier

Anthropic - Measurements for understanding the pace of AI development inside frontier labs
https://www.anthropic.com/institute/measuring-pace-of-ai-development

Anthropic - Investigating three real-world incidents in our cybersecurity evaluations
https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals

Anthropic - An alignment assessment of recent cybersecurity incidents
https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents

OpenAI - The Hugging Face incident and the road ahead
https://openai.com/index/hugging-face-incident-and-the-road-ahead/

METR - Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

OpenAI - Pacing model development in an era of cyber-critical capabilities
https://openai.com/index/pacing-model-development-cyber-capabilities/

OpenAI - The AI policy window is open. We need to act.
https://openai.com/index/ai-policy-window/

OpenAI - An Alien Mind
https://openai.com/index/an-alien-mind/

UK AI Security Institute - Incident Report: unsanctioned agent behaviour during cyber testing
https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing

UK AI Security Institute - Frontier AI Trends Report
https://www.aisi.gov.uk/frontier-ai-trends-report

UK AI Security Institute - RepliBench
https://www.aisi.gov.uk/research/replibench-evaluating-the-autonomous-replication-capabilities-of-language-model-agents

International AI Safety Report 2026
https://internationalaisafetyreport.org/publication/international-ai-safety-report-2026

International AI Safety Report 2026 - Executive Summary
https://internationalaisafetyreport.org/publication/2026-report-executive-summary

Meta - Our Approach to Frontier AI
https://about.fb.com/news/2025/02/meta-approach-frontier-ai/

Google DeepMind - Frontier Safety Framework
https://deepmind.google/frontier-safety/

NVIDIA - Jensen Huang at Dreamforce
https://blogs.nvidia.com/blog/jensen-huang-dreamforce/

Future of Life Institute - Pause Giant AI Experiments: An Open Letter
https://futureoflife.org/open-letter/pause-giant-ai-experiments/

Reuters - Anthropic CEO urges AI companies to slow model development
https://www.reuters.com/business/anthropic-ceo-urges-ai-companies-slow-model-development-2026-09-12/

Reuters - What Amodei, Altman and Musk have said about AI risks
https://www.reuters.com/business/what-amodei-altman-musk-have-said-about-ai-risks-stoking-doom-fears-2026-09-14/

Reuters - Meta's Zuckerberg says AI labs have enough incentive to build safely
https://www.reuters.com/business/metas-zuckerberg-says-ai-labs-have-enough-incentive-build-safely-2026-09-16/

Reuters - Europe's AI firms challenge U.S. calls for slowdown
https://www.reuters.com/business/europes-ai-firms-playing-catch-up-challenge-us-calls-slowdown-2026-09-18/

Reuters - Anthropic considers releasing new AI model ahead of IPO
https://www.reuters.com/business/anthropic-considers-releasing-new-ai-model-ahead-ipo-sources-say-2026-09-19/

Associated Press - Anthropic CEO says AI industry needs to give safety measures time to catch up
https://apnews.com/article/d59552edcb27892d8ee4d98a48397706

Associated Press - AI rivals found rare agreement on safety
https://apnews.com/article/b61f28b6212338e88c0baec31f661701

한국경제 - 'AI 충돌' 아모데이·젠슨 황…'속도 조절' vs '시장에 맡겨라'
https://www.hankyung.com/article/2026091670437

SBS - 아모데이·젠슨황, AI안전 충돌…"표준 세워야" "규제 불필요"
https://news.sbs.co.kr/news/endPage.do?news_id=N1008755034

SBS - 'AI 공룡' 수장도 충돌…'인류 파멸' 경고 뒤에 숨은 속내?
https://news.sbs.co.kr/news/endPage.do?news_id=N1008756785

Posted by 모과이IT
,

Claude Code나 Codex 같은 AI 코딩 도구를 실제 개발에 사용하다 보면 예전과 비교해 개발 방식이 크게 달라졌다는 것을 느낀다.

몇 년 전에는 AI에게 함수 하나를 만들어 달라고 요청한 뒤 결과를 복사해서 프로젝트에 넣는 정도였다. 지금은 프로젝트 전체를 읽고 관련 파일을 찾은 다음 여러 파일을 수정하고, 테스트와 명령 실행까지 이어가는 작업도 자연스럽게 맡길 수 있다.

직접 사용해보면 분명 편하다. 반복적인 코드나 범위가 명확한 수정은 사람이 처음부터 직접 작성하는 것보다 빠를 때도 많다.

다만 여기에서 한 가지는 확실하게 구분해야 한다고 생각한다.

AI가 코드를 빠르게 만드는 것과 그 코드를 실제 서비스에 그대로 배포해도 된다는 것은 전혀 다른 문제다.

오랫동안 개발을 하다 보면 코드 한 줄 자체보다 그 변경이 기존 시스템에 미치는 영향이 더 위험한 경우를 많이 보게 된다. 화면에서는 정상으로 보여도 DB 데이터가 잘못 쌓일 수 있고, 개발환경에서는 문제없던 코드가 동시 요청이 들어오는 운영환경에서만 깨질 수도 있다. 인증이나 권한 검사가 한 군데 빠진 것 때문에 보안 문제가 생길 수도 있다.

이번에는 이런 판단을 내 경험에만 기대지 않고 다시 확인해봤다.

2026년 9월 기준으로 GitHub 공식 문서, NIST Secure Software Development Framework, OWASP Secure Code Review, Microsoft Security Development Lifecycle, Google DORA, Google SRE, AWS Well-Architected, Anthropic 연구, OpenAI 연구, OpenSSF, PostgreSQL 공식 문서, CISA의 Secure by Design 관련 자료까지 18개 이상의 공식·표준 자료를 비교했다.

재미있는 점은 회사와 기관은 달라도 결론이 상당히 비슷하다는 것이다.

AI가 만든 결과도 결국 요구사항 확인, 테스트, 보안 검토, 의존성 확인, 사람의 리뷰, 안전한 배포와 롤백 같은 기존 소프트웨어 엔지니어링 원칙을 통과해야 한다.

GitHub는 AI 생성 코드 전용 검토 가이드에서 테스트와 정적 분석뿐 아니라 요구사항과 의도, 외부 의존성, AI 특유의 환각까지 별도로 확인하라고 안내한다. Microsoft SDL은 코드가 릴리스되기 전에 자동 분석뿐 아니라 작성자와 다른 사람의 수동 리뷰를 요구하고 있으며, NIST SSDF 역시 보안을 개발 생명주기 전체에 통합하는 것을 기본 원칙으로 두고 있다.

AI 때문에 기존 개발 원칙이 사라지는 것이 아니라 오히려 코드 생성 속도가 빨라지면서 검증의 중요성이 더 커지고 있는 셈이다.

Google DORA의 2025년 연구에서도 AI 도입은 소프트웨어 전달 속도와 긍정적인 관계를 보였지만 안정성과는 여전히 부정적인 관계가 관찰됐다. 2026년 DORA의 후속 분석에서는 AI가 초기 코드 생성을 빠르게 만들어 절약한 시간이 감사와 검증으로 다시 이동하는 현상을 설명한다.

그래서 개인적으로는 AI가 코드를 만든 뒤부터가 개발자의 중요한 역할이라고 생각한다.

이번 글에서는 AI 생성 코드를 실제 서비스에 반영하기 전에 무엇을 확인해야 하는지, 공식 자료에서 반복해서 강조되는 내용을 실무 개발자의 관점으로 다시 정리해봤다.


1. 요구사항과 구현 일치 여부

AI가 작업을 끝내면 가장 먼저 코드를 읽고 싶어진다.

하지만 개인적으로는 코드보다 원래 요구사항을 먼저 다시 보는 편이 낫다고 생각한다.

코드가 깔끔하고 테스트까지 통과했더라도 처음 요청한 기능과 다른 방향으로 구현됐다면 결국 잘못된 결과다.

GitHub의 AI 생성 코드 검토 가이드에서도 단순한 기능 검사를 넘어서 코드가 실제 요구사항과 프로젝트의 설계 의도에 맞는지 확인하라고 안내한다. Anthropic 역시 자율적으로 행동하는 Agent가 사용자의 의도를 잘못 해석할 수 있으며, 불확실한 상황에서는 사람이 통제권을 유지하고 필요한 경우 다시 확인할 수 있어야 한다는 점을 강조한다.

실제로 AI 코딩 도구를 사용하다 보면 요청하지 않은 주변 코드까지 정리하거나, 자신의 판단으로 구조를 개선하는 경우가 있다.

예를 들어 로그인 실패 메시지만 변경해달라고 했는데 인증 흐름 자체를 리팩터링했다면 결과가 좋아 보이더라도 별개의 변경으로 보는 편이 안전하다.

운영 중인 서비스에서는 현재 코드가 이상해 보이는 것과 정말 잘못된 코드는 다를 수 있다. 과거 장애나 특정 고객 데이터 때문에 생긴 예외처리가 남아 있을 수도 있기 때문이다.

그래서 첫 번째 검증 질문은 의외로 단순하다.

“이 코드가 좋은가?”보다 “내가 요청한 것만 정확하게 했는가?”를 먼저 확인하는 것이 좋다.


2. Git diff와 변경 범위

AI가 수정한 코드를 확인할 때는 전체 파일을 처음부터 다시 읽기보다 Git diff에서 변경 범위를 먼저 보는 것이 효율적이다.

GitHub의 공식 가이드도 AI 생성 코드를 기존 프로젝트의 컨텍스트와 의도에 맞춰 검토하도록 권장하며, Microsoft SDL은 코드가 릴리스되기 전에 작성자와 분리된 리뷰어의 수동 검토를 요구한다.

내가 요청한 기능 때문에 어떤 파일이 바뀌었는지, 몇 줄이 추가되고 삭제됐는지를 먼저 보면 AI가 작업 범위를 얼마나 넓게 잡았는지 바로 알 수 있다.

API 하나를 수정해달라고 했는데 공통 유틸리티, 인증 미들웨어, 설정 파일까지 한꺼번에 바뀌었다면 이유를 확인해야 한다.

AI가 코드 품질이나 일관성을 이유로 주변 코드까지 리팩터링하는 경우가 있는데, 기능 수정과 리팩터링이 하나의 변경에 섞이면 문제가 생겼을 때 원인을 찾기도 어려워진다.

AWS Well-Architected에서도 변경 크기가 작을수록 잠재적인 영향 범위를 낮출 수 있다는 방향을 권장한다.

AI 시대에도 작은 변경 단위가 여전히 중요한 이유다.


3. 빌드와 테스트의 의미

GitHub의 AI 생성 코드 검토 문서는 가장 먼저 코드가 컴파일되는지, 테스트가 통과하는지, 새로운 경고가 없는지 확인하고 정적 분석 도구를 사용하도록 권장한다.

Microsoft SDL과 NIST SSDF도 자동화된 보안 검사와 검증을 개발 과정에 포함하는 것을 기본적인 안전장치로 본다.

그렇다고 테스트가 모두 통과했다는 사실을 “이 코드는 안전하다”는 의미로 받아들이면 안 된다.

테스트는 작성돼 있는 조건을 확인하는 도구다. 테스트에 없는 요구사항이나 실제 운영에서만 발생하는 상황까지 자동으로 보장해주지는 않는다.

특히 AI가 구현 코드와 테스트 코드를 동시에 수정했다면 더 꼼꼼하게 보는 편이 좋다.

GitHub는 AI 특유의 문제로 테스트가 정상적으로 수정되지 않고 삭제되거나 skip 처리되는 경우까지 별도로 경고한다.

기존 테스트가 실패했을 때 AI가 실제 버그를 고친 것인지, 아니면 자신의 구현이 통과하도록 테스트의 기준을 바꾼 것인지는 반드시 구분해야 한다.

개인적으로 AI가 “모든 테스트를 통과했습니다”라고 보고하면 성공 메시지만 볼 것이 아니라 어떤 테스트 파일까지 함께 수정했는지 diff를 다시 확인하는 편이 안전하다.


4. 예외 상황과 비즈니스 로직

정상적인 입력 하나로 동작하는 것을 확인하는 것보다 실제 서비스에서 더 중요한 것은 실패 상황이다.

OWASP Secure Code Review 가이드에서는 자동화 도구만으로 잡기 어려운 영역으로 비즈니스 로직, 인증과 권한, 상태 전환, Race Condition, Transaction Integrity 등을 직접 강조한다.

값이 null이거나 비어 있을 때, 외부 API가 실패했을 때, 동일한 요청이 반복됐을 때 어떤 결과가 나오는지 확인해야 한다.

특히 주문, 결제, 포인트, 재고처럼 여러 단계에 걸쳐 상태가 바뀌는 기능은 중간 실패를 반드시 생각해야 한다.

주문 데이터는 저장됐는데 결제 요청이 실패했다면 어떤 상태로 남는지, 다시 시도했을 때 중복 결제가 일어나지 않는지, 이미 처리된 요청을 다시 받았을 때 안전한지도 확인해야 한다.

이런 문제는 단순한 문법 오류와 다르다.

자동화된 분석 도구와 테스트가 도움이 되더라도 실제 업무 규칙을 이해하는 사람의 판단이 필요한 영역이다.

OWASP가 수동 코드 리뷰를 자동화된 SAST나 DAST의 대체재가 아니라 보완 수단으로 설명하는 이유도 여기에 있다.


5. 기존 기능의 회귀 영향

특정 기능 하나를 수정했다고 해서 영향이 그 기능 안에서만 끝난다는 보장은 없다.

공통 함수, 공통 컴포넌트, DB 테이블, 인증 미들웨어처럼 여러 기능이 공유하는 부분을 수정했다면 회귀 영향까지 함께 확인해야 한다.

NIST SSDF는 소프트웨어 보안을 특정 검사 한 번으로 끝내는 것이 아니라 개발과 변경 과정 전체에 통합해야 한다고 본다. DORA 역시 AI가 개발 속도를 높일 수 있지만 자동 테스트, 버전 관리, 빠른 피드백 같은 기본적인 통제 시스템이 약하면 그 속도가 오히려 불안정성을 드러낼 수 있다고 설명한다.

AI가 프로젝트 전체를 읽을 수 있다고 해도 실제 운영 이력과 사용자 행동, 과거 장애의 원인을 모두 알고 있는 것은 아니다.

공통 날짜 함수를 수정했는데 현재 작업 화면에서는 잘 되더라도 검색 기간이나 정산 기능이 함께 깨질 수 있다.

그래서 변경된 함수나 모듈이 어디에서 사용되고 있는지 한번 더 검색하고, 영향받을 가능성이 높은 기존 기능을 같이 확인하는 편이 좋다.


6. DB와 데이터 변경

개인적으로 AI에게 맡길 때 가장 보수적으로 보는 부분 중 하나가 DB다.

코드가 잘못되면 이전 버전으로 돌릴 수 있는 경우가 많지만, 잘못 변경된 운영 데이터는 애플리케이션 코드처럼 간단히 되돌아오지 않을 수 있다.

PostgreSQL 공식 문서만 봐도 동시 트랜잭션에서는 Dirty Read, Nonrepeatable Read, Phantom Read, Serialization Anomaly 같은 문제가 발생할 수 있으며, 일부 상황에서는 명시적인 Lock이나 Transaction Isolation을 제대로 설계해야 한다.

ALTER TABLE 같은 스키마 변경도 작업 종류에 따라 강한 잠금이 필요할 수 있다. 큰 테이블에서는 단순해 보이는 Migration이 실제 서비스의 다른 요청에 영향을 줄 수 있다는 뜻이다.

AI가 Migration을 만들었다면 SQL 문법만 맞는지 볼 것이 아니라 기존 데이터가 있는 상태에서도 안전한지 확인해야 한다.

NOT NULL 컬럼을 추가한다면 기존 행은 어떻게 처리하는지, 인덱스 생성이 운영 트래픽에 어떤 영향을 주는지, 타입 변경 과정에서 데이터 손실 가능성은 없는지 살펴봐야 한다.

UPDATE나 DELETE처럼 실제 데이터를 바꾸는 SQL은 더욱 조심해야 한다.

실행 전에 같은 조건의 SELECT로 대상 건수를 확인하고, 운영환경이라면 백업과 복구 방법도 먼저 확인하는 편이 좋다.


7. 인증과 권한

OWASP의 Secure Code Review 가이드는 보안 코드 리뷰에서 인증과 권한을 별도의 핵심 영역으로 다룬다.

CISA 역시 Secure by Design 원칙을 통해 보안 통제를 제품 설계와 소프트웨어 개발 생명주기 처음부터 넣어야 한다고 강조하고 있으며, NIST SSDF도 같은 방향을 제시한다.

기능이 정상적으로 동작하는 것과 권한 처리가 올바른 것은 다른 문제다.

관리자 API를 만들었는데 로그인 여부만 확인하고 관리자 권한을 확인하지 않았다면 일반 사용자가 API를 직접 호출할 가능성이 생긴다.

화면에서 관리자 버튼을 숨긴 것 역시 보안 통제가 아니다. 최종 권한 판단은 서버 쪽에서 검증되어야 한다.

AI가 요구받은 기능 구현에 집중하면서 프로젝트에 이미 존재하는 권한 정책을 놓치는 경우를 생각해야 한다.

특히 인증, 개인정보, 결제, 파일 업로드, 관리자 기능처럼 한 번의 실수가 큰 사고로 이어지는 영역이라면 일반 기능보다 한 단계 더 보수적으로 검토하는 것이 좋다.


8. 외부 라이브러리와 API

AI 코딩 도구를 오래 사용했다면 존재하지 않는 API나 잘못된 라이브러리 옵션을 너무 자연스럽게 제시하는 경우를 한 번쯤 봤을 것이다.

GitHub의 AI 생성 코드 검토 가이드 역시 Hallucinated API와 존재하지 않거나 의심스러운 패키지를 AI 특유의 위험으로 명시한다.

그래서 새로운 의존성이 추가됐다면 정말 필요한지부터 확인해야 한다.

GitHub의 Dependency Review는 Pull Request에서 어떤 의존성이 추가·삭제·업데이트됐는지와 알려진 취약점을 확인하도록 지원한다. OWASP의 Software Component Verification Standard와 OpenSSF Scorecard 역시 소프트웨어 공급망에서 외부 컴포넌트의 위험을 평가하는 것을 중요한 검증 영역으로 본다.

단순히 패키지가 실제로 존재하는지만 보면 부족하다.

현재 프로젝트에 이미 같은 역할의 라이브러리가 있는지, 유지보수가 되고 있는지, 알려진 보안 문제가 없는지, 라이선스에 문제는 없는지도 함께 보는 편이 좋다.

외부 API와 클라우드 SDK처럼 버전 변화가 빠른 영역은 AI의 설명보다 현재 공식 문서를 마지막 기준으로 삼는 것이 안전하다.


9. 동시성과 중복 실행

개발환경에서 요청을 한 번씩 실행할 때는 문제가 없어도 실제 운영환경에서 동시에 여러 요청이 들어오면 전혀 다른 문제가 생길 수 있다.

OWASP의 Secure Code Review 가이드도 Race Condition과 Transaction Integrity를 비즈니스 로직 리뷰 항목에 포함하고 있다.

PostgreSQL 문서 역시 동시 트랜잭션이 직렬로 실행했을 때와 다른 결과를 만들 수 있는 Serialization Anomaly를 설명하며, 상황에 따라 Lock이나 Serializable Isolation, 재시도 처리가 필요할 수 있다고 안내한다.

재고가 하나 남은 상황에서 두 사용자가 동시에 구매하거나, 포인트 차감 요청이 거의 동시에 들어오는 상황을 생각하면 이해하기 쉽다.

AI가 생성한 코드가 단일 요청에서는 정확해 보여도 Transaction과 Lock, Idempotency가 필요한 업무인지 별도로 판단해야 한다.

이런 부분은 코드가 문법적으로 완벽한가보다 실제 서비스에서 어떤 일이 동시에 발생할 수 있는지 상상하는 능력이 더 중요하다.


10. 성능과 운영 비용

기능이 정확하게 동작해도 운영환경에서 너무 느리거나 비싼 구조라면 좋은 구현이라고 보기 어렵다.

반복문 안에서 DB를 계속 조회하는 N+1 문제나, 한 번이면 되는 외부 API를 여러 번 호출하는 코드는 작은 테스트 데이터에서는 잘 드러나지 않는다.

Google SRE는 신뢰성을 검증할 때 단순 기능 테스트뿐 아니라 Stress Test와 실제 트래픽에 가까운 Canary 검증을 중요하게 다룬다.

사용자가 늘어나거나 데이터가 커졌을 때 응답 시간이 어떻게 변하는지 생각해야 한다.

LLM API를 이용하는 서비스라면 비용도 성능과 같은 운영 조건으로 봐야 한다. 같은 데이터를 불필요하게 반복 전송하거나, 복잡하지 않은 작업에도 가장 비싼 모델을 사용하는 구조라면 기능은 정상이어도 운영비가 크게 늘 수 있다.

그래서 최종 검증에서는 “지금 동작하는가?”와 함께 “사용자가 늘어도 이 방식으로 유지할 수 있는가?”를 같이 보는 것이 좋다.


11. 배포와 롤백

운영 배포 전에 반드시 생각해야 할 질문은 문제가 생겼을 때 얼마나 빨리 이전 상태로 돌아갈 수 있는가다.

AWS Well-Architected는 실패한 변경에 대한 Rollback 또는 Fix Forward 계획을 배포 전에 문서화하고 검증할 것을 권장한다. 자동 테스트와 자동 롤백을 CI/CD에 통합하는 것도 별도의 Best Practice로 두고 있다.

Google SRE 역시 새 버전을 전체 사용자에게 한 번에 배포하기보다 작은 범위에 먼저 적용하는 Canary 방식과 단계적 Rollout을 사용한다. 문제가 감지되면 먼저 Rollback하고 원인은 그다음에 분석하는 것이 복구 시간을 줄이는 데 유리하다는 원칙도 명확하게 제시한다.

AI가 코드를 만들었는지는 여기에서 중요하지 않다.

애플리케이션 코드만 바뀌었다면 이전 버전 재배포가 가능한지, DB Migration이 포함됐다면 이전 애플리케이션과 새 스키마가 호환되는지 확인해야 한다.

배포 후에는 단순히 “배포 성공” 메시지만 보는 것도 부족하다. 오류율과 응답시간, 주요 업무 지표를 확인할 수 있는 모니터링이 있어야 실제 문제가 생겼을 때 빨리 판단할 수 있다.

AI가 개발 속도를 높일수록 안전하게 되돌릴 수 있는 배포 구조의 중요성도 같이 커진다고 생각한다.


12. AI를 이용한 교차 검증

AI가 만든 코드를 다른 AI에게 다시 검토시키는 방법은 충분히 활용할 가치가 있다.

Claude Code에서 구현한 변경을 Codex나 Copilot Code Review에 다시 확인시키면 작성 과정에서 놓친 부분을 다른 관점으로 발견할 수 있다.

다만 이것을 사람의 최종 리뷰를 없애는 방법으로 사용해서는 안 된다.

GitHub는 Copilot Code Review가 모든 문제를 찾는다고 보장하지 않으며 실수할 수 있으므로, Copilot의 피드백을 반드시 검증하고 사람의 리뷰로 보완하라고 공식 문서에 명확하게 적고 있다.

Microsoft SDL 역시 작성자와 다른 사람의 수동 리뷰를 릴리스 전 검증 절차로 둔다.

Anthropic도 Agent가 더 자율적으로 움직일수록 사용자의 의도를 잘못 읽거나 예상하지 못한 행동을 할 여지가 커진다고 설명하며, 중요한 작업에서 사람이 의미 있는 통제권을 유지해야 한다고 강조한다.

그래서 AI 리뷰는 좋은 두 번째 의견으로 사용하는 것이 맞다.

최종 승인 도장으로 사용하는 것은 아직 이르다.


13. 벤치마크 점수와 실제 배포 품질

AI 코딩 모델의 벤치마크 점수가 매우 높아지면서 “이 정도면 코드 리뷰까지 맡겨도 되지 않을까?”라는 생각이 들 수 있다.

하지만 벤치마크 성능과 실제 서비스의 신뢰성은 구분해서 볼 필요가 있다.

OpenAI가 2026년 SWE-Bench Pro를 직접 감사한 결과 약 30%의 Task에 문제가 있는 것으로 추정했다. 평가 데이터 자체에 결함이 있으면 모델의 능력을 실제보다 높거나 낮게 오해할 수 있다는 것이 OpenAI의 결론이다.

이 결과가 “AI 코딩 벤치마크는 의미 없다”는 뜻은 아니다.

좋은 평가도구가 필요하지만 특정 점수 하나를 실제 운영환경에서의 안전성으로 그대로 해석하면 안 된다는 의미에 가깝다.

실제 서비스에는 기존 데이터, 사용자 권한, 외부 API, 과거 장애를 통해 생긴 예외처리, 성능과 비용, 배포 전략처럼 코딩 문제 하나에서는 측정되지 않는 요소가 훨씬 많이 존재한다.

그래서 나는 모델 점수가 높아질수록 코드 검증이 필요 없어지는 것이 아니라, 모델에게 더 큰 작업을 맡길 수 있게 되는 만큼 검증의 범위 역시 넓어진다고 보는 편이 맞다고 생각한다.


14. 경력과 전문성이 여전히 중요한 이유

Anthropic이 2026년 약 40만 건의 Claude Code 세션을 분석한 연구도 이 주제와 연결된다.

이 연구에서 일반적인 세션을 보면 사용자는 계획에 관한 결정의 약 70%를 맡았고, Claude는 실행에 관한 결정의 약 80%를 맡았다.

쉽게 말하면 무엇을 만들지와 어떤 방향으로 갈지는 사람이 더 많이 결정하고, 실제 파일 수정과 명령 실행 같은 구현은 Claude가 더 많이 맡는 구조가 관찰된 것이다.

전문성에 따른 차이도 확인됐다.

Anthropic의 가장 엄격한 Verified Success 기준에서 초보 수준으로 분류된 세션은 15%가 성공한 반면, 중급 이상은 28~33%였다. 문제가 발생한 세션에서도 전문성이 높은 사용자가 결과를 다시 성공으로 가져가는 비율이 더 높았다.

물론 이 연구는 Claude Code 사용자라는 특정 집단과 Anthropic이 정의한 성공 측정 방식에 기반하므로 모든 개발 업무에 그대로 일반화하면 안 된다.

그럼에도 한 가지 경향은 분명하게 보인다.

AI가 실행을 많이 맡아도 어떤 문제를 풀어야 하는지 알고, 잘못된 결과를 알아차리고, 다시 올바른 방향으로 조정하는 전문성은 여전히 가치가 있다.

개인적으로 장기간 개발하면서 쌓은 경험이 AI 시대에 의미가 있는 지점도 바로 여기라고 생각한다.

직접 타이핑하는 코드의 양은 줄어들 수 있지만, 요구사항과 구조를 판단하고 장애 가능성을 예상하며 실제 운영에 넣어도 되는지 결정하는 역할은 사라지지 않는다.


15. 실무 배포 전 최종 체크리스트

앞의 내용을 실제 작업에서 빠르게 확인하려면 아래 12가지를 기준으로 삼을 수 있다.

① 요청한 요구사항과 실제 구현 결과가 일치하는가

② Git diff에 요청하지 않은 변경이나 불필요한 리팩터링이 섞이지 않았는가

③ 빌드, 테스트, lint, 정적 분석이 정상적으로 통과하는가

④ AI가 기존 테스트를 자신의 코드에 맞춰 삭제하거나 약화시키지 않았는가

⑤ 수정한 코드가 다른 기존 기능에 미치는 회귀 영향을 확인했는가

⑥ null, 중복 요청, 외부 API 실패, 비정상 입력 같은 예외 상황을 확인했는가

⑦ DB Migration과 데이터 변경을 안전하게 실행하고 필요하면 복구할 수 있는가

⑧ 인증, 권한, 개인정보, 파일 업로드 같은 보안 영향을 별도로 검토했는가

⑨ 새 의존성과 API가 실제 존재하며 현재 버전에 맞고 알려진 취약점은 없는가

⑩ 동시 요청, Transaction, Lock, Idempotency 문제가 없는가

⑪ 사용자와 데이터가 늘어났을 때도 성능과 운영 비용을 감당할 수 있는가

⑫ 운영 배포 후 문제를 빠르게 감지하고 Rollback 또는 Fix Forward할 준비가 되어 있는가

GitHub, NIST, OWASP, Microsoft, AWS, Google SRE 등 서로 다른 기관의 가이드를 비교해도 이 목록의 방향은 크게 다르지 않았다.

결국 AI 생성 코드라고 해서 특별한 소프트웨어 공학 원칙이 새로 생기는 것이 아니다.

기존에 중요했던 검증 원칙을 AI의 특성에 맞춰 더 꼼꼼하게 적용해야 한다.


16. 결론: AI가 빨라질수록 검증 기준이 중요해진다

Claude Code와 Codex 같은 도구를 사용하면서 개발 속도가 빨라진 것은 분명하게 느끼고 있다.

예전에는 개발자가 직접 찾아보고 작성해야 했던 작업을 AI가 몇 분 만에 처리하는 경우도 있다.

하지만 코드 생산 속도가 빨라졌다고 해서 소프트웨어 개발 전체가 자동으로 안전해지는 것은 아니다.

Google DORA의 연구처럼 AI 활용이 소프트웨어 전달 속도와 긍정적인 관계를 보이는 동시에 안정성과는 부정적인 관계가 나타날 수 있다. AI로 아낀 시간이 감사와 검증으로 이동하는 현상도 이미 현업 연구에서 관찰되고 있다.

GitHub와 Microsoft는 AI 리뷰 자체도 다시 사람이 검증하라고 권장하고 있고, NIST와 OWASP는 보안과 비즈니스 로직을 개발 과정 전체에서 검토하도록 요구한다. AWS와 Google SRE는 실제 배포 단계에서 테스트와 모니터링, Canary, Rollback까지 준비하는 것을 기본 원칙으로 둔다.

결국 AI 코딩 도구가 아무리 좋아져도 마지막 질문은 바뀌지 않는다.

“이 코드가 만들어졌는가?”가 아니라 “이 변경을 실제 사용자에게 배포해도 되는가?”다.

개인적으로는 AI 시대에 경력 개발자의 가치도 이 질문에 얼마나 정확하게 답할 수 있는가에서 더 많이 드러날 것이라고 본다.

AI는 점점 더 많은 코드를 작성할 것이다.

그럴수록 사람은 요구사항과 구조를 판단하고, AI가 만든 결과를 검증하고, 문제가 생겼을 때 안전하게 복구할 수 있도록 책임지는 역할에 더 집중하게 될 가능성이 높다.

한 줄로 정리하면 이렇다.

AI 생성 코드는 초안이 아니라 실제 코드다. 따라서 사람이 작성한 코드와 마찬가지로 요구사항, 테스트, 보안, 데이터, 성능, 배포와 롤백까지 모두 검증한 뒤에야 운영에 넣을 수 있다.


참고 자료

아래 자료는 2026년 9월 13일 기준으로 다시 확인했다.

GitHub Docs - Review AI-generated code
https://docs.github.com/en/enterprise-cloud@latest/copilot/tutorials/review-ai-generated-code

GitHub Docs - About GitHub Copilot code review
https://docs.github.com/en/copilot/concepts/agents/code-review

GitHub Docs - Reviewing dependency changes in a pull request
https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-dependency-changes-in-a-pull-request

NIST - Secure Software Development Framework, SP 800-218
https://csrc.nist.gov/pubs/sp/800/218/final

OWASP - Secure Code Review Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html

OWASP - Software Component Verification Standard
https://owasp.org/www-project-software-component-verification-standard/

Microsoft - Security Development Lifecycle
https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-security-development-lifecycle

Google DORA - State of AI-assisted Software Development 2025
https://dora.dev/research/2025/dora-report/

Google DORA - Balancing AI tensions
https://dora.dev/insights/balancing-ai-tensions/

Anthropic - Agentic coding and persistent returns to expertise
https://www.anthropic.com/research/claude-code-expertise

Anthropic - Trustworthy agents in practice
https://www.anthropic.com/research/trustworthy-agents

OpenAI - Separating signal from noise in coding evaluations
https://openai.com/index/separating-signal-from-noise-coding-evaluations/

AWS Well-Architected - Plan for unsuccessful changes
https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_mit_deploy_risks_plan_for_unsucessful_changes.html

AWS Well-Architected - Automate testing and rollback
https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_auto_testing_and_rollback.html

Google SRE - Release Engineering
https://sre.google/sre-book/release-engineering/

Google SRE - Canarying Releases
https://sre.google/workbook/canarying-releases/

OpenSSF - Scorecard
https://openssf.org/projects/scorecard/

PostgreSQL - Transaction Isolation
https://www.postgresql.org/docs/18/transaction-iso.html

PostgreSQL - Explicit Locking
https://www.postgresql.org/docs/current/explicit-locking.html

CISA - Secure by Design 관련 공식 가이드
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

Posted by 모과이IT
,

Claude Code를 오래 사용하다 보면 비슷한 작업을 하는데도 어떤 날은 사용량이 유난히 빨리 줄어드는 느낌이 들 때가 있다.

나 역시 실제 개발에 Claude Code를 계속 사용하면서 이런 차이를 여러 번 느꼈다. 처음에는 단순히 프롬프트를 길게 쓰거나 대화를 많이 해서 그런 줄 알았는데, Anthropic이 최근 공개한 공식 가이드와 Claude Code 문서를 다시 확인해보니 원인은 생각보다 훨씬 넓었다.

Claude Code는 사용자가 방금 입력한 문장만 처리하는 것이 아니다. 이전 대화와 읽어온 파일, CLAUDE.md 같은 프로젝트 지침, 명령 실행 결과, MCP와 Skill 관련 정보까지 현재 세션의 컨텍스트에 영향을 준다. 여기에 Prompt Cache가 얼마나 잘 유지되는지, 어떤 모델과 Effort를 사용하는지도 사용량에 영향을 줄 수 있다.

Anthropic은 2026년 8월 “Maximizing the value of your Claude Code sessions”라는 공식 글을 따로 공개하면서 Claude Code 세션을 효율적으로 운영하는 방법을 정리했다. 기존 도움말에도 비용과 사용량을 줄이기 위한 별도 가이드가 있고, Prompt Cache가 언제 깨지는지나 /usage, /context를 어떻게 활용해야 하는지도 이전보다 훨씬 구체적으로 설명하고 있다.

이번 글에서는 그 공식 자료를 기준으로 Anthropic의 Claude Code 문서와 Prompt Cache 설명을 다시 확인하고, Amazon Bedrock과 Google Cloud의 Claude 캐싱 문서까지 같이 비교해봤다.

결론부터 말하면 Claude Code에서 토큰을 아끼는 핵심은 프롬프트 몇 글자를 줄이는 데 있지 않았다.

실제 차이를 만드는 것은 현재 작업과 관계없는 컨텍스트를 오래 끌고 가지 않는 것, 이미 처리한 내용을 Prompt Cache로 최대한 재사용하는 것, 그리고 작업의 난이도에 맞게 모델과 Effort를 선택하는 쪽에 가까웠다.


1. Claude Code 토큰 사용량의 기본 구조

Claude Code의 사용량을 이해하려면 일반적인 채팅처럼 “내가 이번에 몇 글자를 입력했는가”만 보면 안 된다.

오전부터 하나의 세션을 계속 사용하면서 여러 파일을 읽고 테스트와 빌드를 반복했다고 해보자. 오후에 짧은 질문 하나만 추가하더라도 Claude는 앞에서 쌓인 대화와 작업 맥락을 함께 참고한다. 세션이 길어질수록 단순한 질문 한 번에도 따라붙는 정보가 많아질 수 있다는 뜻이다.

이 부분은 Anthropic의 비용 관리 문서에서도 직접 설명하고 있다. 긴 세션을 계속 유지하면 짧은 요청이라도 전체 대화 히스토리 때문에 사용량이 커질 수 있고, 작업이 바뀌었는데도 이전 맥락을 계속 가지고 가면 불필요한 비용이 생길 수 있다.

물론 Claude Code에는 Prompt Cache가 있다. 이미 처리한 동일한 앞부분을 매번 처음부터 다시 계산하지 않도록 캐시를 이용한다. 그래서 긴 세션이라고 해서 이전 내용을 매번 완전히 새로 처리하는 것은 아니다.

하지만 캐시가 있다고 해서 컨텍스트 관리가 필요 없어지는 것은 아니다. 세션 자체가 지나치게 길어지거나 캐시를 다시 만들게 되는 설정 변경이 반복되면 결국 사용량이 늘어난다.

개인적으로 이 구조를 이해하고 나니 “프롬프트를 짧게 쓰면 토큰이 절약된다”는 말만으로는 부족하다는 생각이 들었다. 내가 입력한 한두 문장보다 그 시점에 Claude가 함께 들고 있는 컨텍스트가 훨씬 클 수 있기 때문이다.


2. /clear와 /compact의 사용 기준

Anthropic 공식 가이드에서 가장 실용적으로 느껴진 부분은 /clear와 /compact를 구분해서 사용하는 방법이었다.

두 명령은 비슷해 보이지만 역할이 다르다.

예를 들어 로그인 오류를 고치던 세션에서 작업이 끝난 뒤 전혀 관계없는 결제 모듈 개발을 시작한다고 해보자. 결제 작업에 로그인 오류를 분석하면서 읽었던 파일과 테스트 로그, 앞선 대화 내용이 계속 필요하지 않다면 새 컨텍스트로 시작하는 편이 낫다. 이럴 때 사용하는 것이 /clear다.

반대로 같은 문제를 계속 다루고 있는데 세션이 너무 길어졌다면 이야기가 달라진다. 앞에서 결정한 설계와 수정 내용은 남겨야 하지만, 지금까지의 모든 대화를 그대로 유지할 필요는 없을 수 있다. 이런 경우에는 /compact로 중요한 내용을 요약해 같은 작업을 이어가는 방식이 더 자연스럽다.

Anthropic도 관련 없는 작업으로 넘어갈 때는 /clear를 사용하고, 긴 작업을 계속해야 할 때는 /compact를 이용해 대화를 정리하는 방향을 권장하고 있다.

내가 실제로 적용하기 쉽게 정리한다면 기준은 간단하다.

이전 대화가 없어도 다음 작업을 설명할 수 있다면 /clear 쪽에 가깝고, 앞선 결정과 작업 내역을 유지해야 한다면 /compact 쪽에 가깝다.

무조건 일정 시간이 지났다고 /clear를 쓰거나, 토큰이 아깝다고 자주 /compact를 반복하는 것보다는 작업의 맥락이 끊기는 지점을 기준으로 판단하는 편이 자연스럽다.


3. 모델과 Effort 설정

이번 공식 가이드에서 개인적으로 가장 새롭게 느껴진 부분 중 하나가 모델과 Effort를 세션 중간에 자주 바꾸지 말라는 내용이었다.

Claude Code의 Prompt Cache는 현재 사용하는 모델과 설정에 영향을 받는다. Anthropic의 Prompt Cache 문서에 따르면 세션 도중 모델이 바뀌면 기존 대화 내용을 새로운 모델 기준으로 다시 처리해야 할 수 있고, Effort를 변경하는 경우에도 기존 캐시를 그대로 활용하지 못하는 상황이 생길 수 있다.

결국 긴 작업을 진행하면서 모델과 Effort를 계속 바꾸면, 이미 처리했던 컨텍스트를 다시 계산하는 비용이 생길 수 있다는 뜻이다.

그렇다고 항상 가장 저렴한 설정만 사용하라는 이야기는 아니다.

범위가 명확한 단순 수정과 복잡한 아키텍처 분석은 필요한 추론량이 다르다. 오타 수정이나 이미 위치가 정해진 작은 코드 변경에 높은 Effort를 계속 사용할 이유는 크지 않지만, 원인을 찾기 어려운 장애나 여러 모듈이 얽힌 구조를 분석할 때는 더 높은 수준의 추론이 도움이 될 수 있다.

중요한 것은 “가장 좋은 모델을 항상 사용한다”가 아니라 작업의 성격에 맞춰 시작 전에 적절한 수준을 선택하는 것이다.

이렇게 보면 모델과 Effort 선택도 단순한 성능 설정이 아니라 Claude Code의 사용량을 관리하는 방법 중 하나가 된다.


4. Prompt Cache 관리

Anthropic은 Claude Code를 만들면서 Prompt Cache를 굉장히 중요하게 보고 있다. 공식 블로그에도 아예 “Prompt caching is everything”이라는 제목의 글을 따로 공개했을 정도다.

Prompt Cache의 개념 자체는 어렵지 않다.

Claude가 이미 처리한 동일한 앞부분을 이후 요청에서도 다시 사용할 수 있다면, 매번 모든 입력을 처음부터 새로 계산하지 않고 캐시된 결과를 활용한다. 대화가 길어지는 Claude Code에서는 이 차이가 특히 중요하다.

문제는 세션 중간에 캐시를 다시 만들게 되는 변화가 생길 수 있다는 점이다.

Anthropic 문서를 보면 모델이나 Effort를 변경하거나, 일부 MCP와 Plugin 설정을 바꾸거나, Claude Code 자체가 업데이트되는 상황처럼 세션의 앞부분이 달라지는 경우 캐시가 영향을 받을 수 있다. /compact 역시 대화를 새롭게 요약하는 과정이기 때문에 이후 컨텍스트 구조가 달라진다.

이런 기능을 사용하지 말라는 뜻은 아니다. 필요한 설정은 당연히 바꿔야 한다.

다만 긴 세션을 진행하는 도중에 모델, Effort, MCP, Plugin을 계속 켰다 껐다 하면서 사용하면 불필요한 재처리가 생길 수 있다는 점은 알고 있을 필요가 있다.

그래서 나는 작업을 시작하기 전에 이번 세션에서 사용할 모델과 Effort, 필요한 MCP 정도는 먼저 정해두는 쪽이 더 낫다고 본다.


5. /context와 시작 컨텍스트

토큰이 빨리 줄어든다고 느껴질 때 내가 가장 먼저 확인해볼 만한 명령은 /context다.

Claude Code는 새 세션을 열었다고 해서 완전히 빈 상태에서 시작하는 것이 아니다. 프로젝트에 CLAUDE.md가 있다면 그 내용이 들어오고, Auto Memory나 Skill 설명, MCP와 관련된 정보도 시작 컨텍스트에 포함될 수 있다.

프로젝트를 오래 사용하다 보면 이런 설정이 조금씩 쌓인다.

처음에는 필요해서 추가했던 MCP가 지금은 거의 사용되지 않거나, 예전에 적어둔 프로젝트 규칙이 더 이상 맞지 않는데도 그대로 남아 있을 수 있다. 이런 정보는 눈에 잘 보이지 않지만 세션이 시작될 때부터 컨텍스트의 일부가 된다.

Anthropic 최신 가이드에서도 새 세션에서 /context를 확인해 어떤 요소가 컨텍스트를 차지하고 있는지 살펴보는 방법을 권장한다.

개인적으로는 Claude Code 사용량이 신경 쓰인다면 프롬프트 문장부터 줄이기 전에 /context를 한번 보는 편이 훨씬 실용적이라고 생각한다.

내가 첫 질문을 하기 전부터 무엇이 들어가 있는지 알아야 불필요한 부분도 정리할 수 있기 때문이다.


6. CLAUDE.md와 프로젝트 규칙

CLAUDE.md는 Claude Code를 제대로 사용할 때 굉장히 유용하다.

프로젝트 구조와 중요한 규칙, 자주 사용하는 명령처럼 Claude가 항상 알고 있어야 할 내용을 미리 적어두면 매번 같은 설명을 반복하지 않아도 된다.

문제는 편리하다는 이유로 내용을 계속 추가하다 보면 파일이 업무 매뉴얼처럼 커질 수 있다는 점이다.

Anthropic 공식 문서에서는 CLAUDE.md를 간결하게 유지하고, 한 파일은 대략 200줄 이하를 목표로 관리하는 기준을 제시한다. 이유는 단순하다. 세션을 시작할 때부터 Claude가 읽는 정보이기 때문에 현재 작업과 상관없는 설명이 많을수록 모든 작업이 그 부담을 같이 안고 시작하게 된다.

내가 관리 기준을 잡는다면 “Claude가 이 프로젝트에서 거의 항상 알아야 하는 내용인가?”를 먼저 본다.

거의 모든 작업에서 필요한 빌드 명령이나 핵심 규칙이라면 CLAUDE.md에 두는 것이 맞다. 반면 특정 상황에서만 필요한 긴 작업 절차라면 Skill처럼 필요할 때 불러오는 구조로 분리하는 편이 낫다.

파일을 여러 개로 쪼개는 것만으로 토큰이 줄어드는 것도 아니다. import된 내용이 세션 시작부터 함께 로드된다면 결국 컨텍스트에 들어오는 것은 비슷하다.

중요한 것은 파일 개수가 아니라 항상 필요한 정보와 필요할 때만 불러올 정보를 구분하는 것이다.


7. 파일 탐색과 작업 범위

Claude Code가 프로젝트를 직접 탐색할 수 있다는 것은 큰 장점이다. 하지만 개발자가 이미 알고 있는 정보까지 Claude가 처음부터 다시 찾게 만들 필요는 없다.

예를 들어 수정해야 할 파일이 auth.ts라는 것을 이미 알고 있는데 “로그인 처리하는 코드 찾아서 수정해줘”라고 요청하면 Claude는 먼저 프로젝트를 검색하고 관련 후보를 찾아야 한다. 반대로 처음부터 파일을 지정하면 탐색 범위를 줄일 수 있다.

Anthropic의 최신 공식 블로그에서도 필요한 파일이 명확한 경우 @파일명 형태로 바로 지정하는 방법을 권장한다. Claude가 파일 위치를 찾는 검색 과정과 별도의 Read 호출을 줄일 수 있기 때문이다.

다만 이것도 무조건적인 규칙은 아니다.

어떤 파일을 봐야 할지 확실하지 않거나, 프로젝트 구조 자체를 분석해야 한다면 Claude가 탐색하도록 두는 것이 맞다. 아주 큰 파일에서 특정 부분만 필요한데 전체를 무조건 컨텍스트에 넣는 것도 오히려 낭비가 될 수 있다.

결국 중요한 것은 Claude에게 일을 대신 시키는 것과, 내가 이미 알고 있는 정보를 Claude가 다시 찾게 만드는 것을 구분하는 것이다.

프롬프트도 같은 기준으로 보면 이해하기 쉽다.

“이 프로젝트 코드 좀 개선해줘”처럼 범위가 넓은 요청은 Claude가 어디부터 봐야 할지 판단하기 위해 많은 파일을 탐색하게 만든다. 반대로 수정 대상과 완료 조건이 명확하면 불필요한 검색과 파일 읽기를 줄일 수 있다.

좋은 프롬프트는 무조건 길고 자세한 문장이 아니라 Claude가 어디까지 보면 되는지를 명확하게 알려주는 프롬프트에 가깝다.


8. 로그와 테스트 출력 관리

실제 개발에서 생각보다 컨텍스트를 크게 만드는 것이 로그와 명령 실행 결과다.

테스트를 한번 돌렸는데 성공 메시지가 수백 줄 나오거나, 서버 로그를 통째로 읽었다면 그 결과 역시 현재 작업의 맥락에 들어간다. 이후 대화를 계속하면 이미 들어온 긴 출력이 다음 작업에도 영향을 줄 수 있다.

Anthropic 공식 가이드는 이런 상황에서 가능한 경우 quiet 옵션을 사용하거나, 필요한 부분만 추려서 Claude에게 전달하는 방식을 권장한다. 비용 관리 문서에는 긴 로그에서 에러 부분만 추출해 전달하는 Hook 예제도 나온다.

실제 개발에서는 테스트가 성공했다는 수백 줄의 로그보다 실패한 테스트 이름과 에러 주변 몇 줄이 더 중요할 때가 많다.

그래서 로그를 통째로 넣기 전에 내가 무엇을 찾으려는지 먼저 정하는 습관이 토큰 절약에도 도움이 된다.

예를 들어 “이 로그를 전부 분석해줘”보다 “결제 API에서 발생한 500 오류의 원인과 관련된 부분만 찾아줘”라고 범위를 정해주면 Claude가 읽고 유지해야 하는 정보도 줄어든다.


9. Subagent와 Agent Team

Subagent도 토큰 절약과 관련해서 오해하기 쉬운 기능이다.

Subagent를 사용한다고 전체 토큰이 자동으로 줄어드는 것은 아니다. 별도의 Claude 인스턴스가 작업하기 때문에 당연히 그쪽에서도 토큰을 사용한다.

장점은 메인 세션을 덜 복잡하게 만들 수 있다는 데 있다.

예를 들어 대규모 코드 탐색이나 긴 로그 분석, 문서 조사처럼 과정에서 수많은 파일과 출력이 발생하는 작업을 Subagent에게 맡기면, 메인 대화에는 최종 결과만 요약해서 가져올 수 있다.

Anthropic도 테스트 실행이나 문서 검색처럼 출력이 많은 작업을 Subagent로 분리해 메인 컨텍스트가 지나치게 커지지 않도록 하는 방식을 안내한다.

반면 Agent Team은 목적이 다르다.

여러 Agent가 병렬로 협업하는 만큼 복잡한 작업에서는 강력하지만, 토큰 절약을 위한 기능이라고 보기는 어렵다. Anthropic 비용 문서에서도 Agent Team은 일반적인 단일 세션보다 훨씬 많은 토큰을 사용할 수 있다고 설명한다.

따라서 단순한 수정 작업에 여러 Agent를 무조건 띄우는 것은 오히려 사용량을 늘릴 수 있다.

내 기준에서는 “과정은 복잡하지만 메인 대화에는 결과만 필요하다”면 Subagent를 검토하고, 실제로 여러 작업자가 독립적으로 나눠서 처리해야 할 정도의 작업에서만 Agent Team을 고려하는 편이 맞다고 본다.


10. MCP와 외부 도구 정리

MCP를 많이 연결하면 Claude Code가 할 수 있는 일도 늘어난다.

하지만 사용하지 않는 서버까지 계속 붙여놓는 것이 항상 좋은 것은 아니다.

최근 Claude Code는 Tool Search를 이용해 예전보다 MCP 도구 정의를 효율적으로 다루고 있지만, Anthropic 비용 관리 문서에서는 여전히 /mcp를 통해 사용하지 않는 서버를 확인하고 정리하는 것을 권장한다.

같은 작업을 CLI로 간단하게 처리할 수 있다면 gh, aws, gcloud 같은 기존 도구가 더 가벼운 선택이 될 수도 있다.

중요한 것은 MCP를 적게 쓰는 것이 아니라 현재 프로젝트에서 실제로 필요한 연결만 유지하는 것이다.

프로젝트가 바뀌었는데 예전에 쓰던 MCP와 Plugin을 그대로 유지하고 있다면 /context와 /mcp를 한번 확인해보는 것이 좋다.


11. Plan Mode와 작업 방향

토큰을 아끼겠다고 무조건 바로 코딩부터 시키는 것도 효율적인 방법은 아니다.

Claude가 잘못된 방향으로 수백 줄을 수정한 뒤 전체를 되돌리고 다시 만드는 상황이 생기면 처음에 계획을 확인하는 것보다 훨씬 많은 토큰과 시간이 들어간다.

여러 파일을 건드리거나 DB 구조, 인증, 기존 기능까지 영향을 받을 가능성이 있는 작업에서는 먼저 Plan Mode로 접근 방향을 확인하는 것이 낫다.

어떤 파일을 수정할지, 기존 구조에서 무엇을 유지할지, 테스트는 어디까지 할지 먼저 확인한 뒤 구현을 시작하면 Claude와 내가 서로 다른 방향을 보고 달리는 상황을 줄일 수 있다.

작업 도중 방향이 틀렸다는 것이 보이면 끝까지 기다릴 필요도 없다.

Claude Code에서는 현재 작업을 중단하고 이전 체크포인트로 돌아갈 수 있으므로, 잘못된 코드가 계속 생성되는 것을 지켜보는 것보다 초기에 바로잡는 편이 훨씬 효율적이다.

개인적으로는 이 부분이 단순한 토큰 절약 팁이라기보다 AI 코딩 도구를 사용하는 기본 습관에 가깝다고 생각한다.


12. /usage로 사용량 원인 확인

사용량이 예상보다 빨리 줄어들 때는 감으로 원인을 추측하기보다 /usage를 먼저 확인하는 편이 낫다.

최근 Claude Code의 /usage는 단순히 남은 사용량만 보여주는 수준을 넘어, 어떤 종류의 기능이 최근 사용량에 영향을 줬는지 확인하는 데 도움을 준다.

여기에 /context를 같이 보면 현재 세션이 왜 무거워졌는지 파악하기가 더 쉽다.

예를 들어 오랫동안 같은 세션을 유지했다면 Long Context가 원인일 수 있고, 모델이나 설정을 자주 바꿨다면 Cache Miss와 관련된 부분을 의심해볼 수 있다. 시작부터 컨텍스트가 큰 경우라면 CLAUDE.md나 MCP, 프로젝트 설정도 다시 봐야 한다.

내가 실제로 점검한다면 /usage에서 최근 사용량을 확인한 뒤 /context로 현재 컨텍스트 구성을 보고, 필요하면 /clear 또는 /compact로 세션을 정리하는 순서로 접근할 것 같다.

이렇게 확인하면 막연하게 “요즘 Claude Code가 토큰을 더 많이 먹는 것 같다”고 느끼는 것보다 실제로 무엇이 문제인지 찾기 쉽다.


13. AWS와 Google Cloud에서 확인한 Prompt Cache

Prompt Cache의 중요성이 Anthropic만의 설명인지도 확인해봤다.

Amazon Bedrock 공식 문서에서는 Claude 모델이 이전에 캐시한 입력을 재사용할 때 일반 입력과 다른 비용 구조를 적용한다고 설명하고 있다. Google Cloud Vertex AI 역시 Claude에서 동일한 앞부분을 반복해서 사용하는 경우 Prompt Caching으로 지연 시간과 비용을 줄일 수 있다고 안내한다.

즉 Prompt Cache는 Claude Code 안에서만 사용하는 특별한 개념이 아니라, Claude를 API와 클라우드 환경에서 운영할 때도 실제 비용과 성능에 영향을 주는 기능이다.

다만 여기에서 한 가지는 구분해야 한다.

AWS나 Google Cloud 문서에 나오는 할인 비율은 API나 클라우드 환경에서 토큰 단위로 과금할 때의 기준이다. Claude Pro나 Max 구독자의 5시간 제한이나 주간 사용량이 똑같은 비율로 줄어든다고 해석하면 안 된다.

이번 글에서 AWS와 Google Cloud 자료를 같이 본 이유는 숫자를 그대로 Claude Code 구독에 적용하기 위해서가 아니라, Prompt Cache가 실제 Claude 운영 비용에서 중요한 기능이라는 점을 교차 확인하기 위해서다.


14. 실제로 적용할 때의 순서

공식 문서를 여러 개 읽고 나면 오히려 복잡하게 느껴질 수 있다.

하지만 실제 사용에서는 몇 가지 습관만 정리해두면 생각보다 단순하다.

나는 먼저 작업 단위부터 나눌 것 같다. 앞의 대화가 전혀 필요 없는 새로운 작업이라면 /clear로 시작하고, 같은 장기 작업을 이어가야 한다면 필요한 시점에 /compact를 사용한다.

세션을 시작할 때는 모델과 Effort, 필요한 MCP를 먼저 정해두고 중간에 이유 없이 계속 바꾸지 않는다. 새 프로젝트나 오래된 프로젝트에서는 /context를 한번 확인해 시작부터 어떤 정보가 들어오는지도 본다.

CLAUDE.md에는 항상 필요한 규칙만 남기고, 긴 로그와 테스트 출력은 필요한 부분만 전달한다. 수정할 파일과 작업 범위를 이미 알고 있다면 Claude에게 다시 전체 프로젝트를 찾게 하지 않고 처음부터 알려주는 편이 낫다.

그리고 사용량이 이상하다고 느껴질 때는 감으로 판단하기보다 /usage와 /context를 먼저 확인한다.

결국 모두 같은 방향의 이야기다.

Claude가 지금 작업하는 데 필요하지 않은 정보를 계속 들고 다니거나, 이미 처리한 내용을 불필요하게 다시 계산하지 않도록 만드는 것이다.


15. 결론: 토큰 절약은 컨텍스트 관리다

Claude Code의 토큰 사용량을 줄이려고 하면 가장 먼저 프롬프트를 짧게 쓰는 방법을 떠올리기 쉽다.

물론 불필요하게 장황한 설명을 줄이는 것도 도움이 된다. 하지만 Anthropic이 최근 공개한 공식 가이드와 Claude Code 문서를 다시 확인해보니 더 큰 차이는 세션을 어떻게 운영하느냐에서 생긴다.

관련 없는 작업을 하나의 세션에 계속 쌓아두지 않고, 같은 긴 작업은 필요할 때 compact해서 이어가는 것이 기본이다. 모델과 Effort, MCP 같은 설정도 작업 중간에 이유 없이 자주 바꾸기보다 처음부터 작업에 맞게 정하는 편이 낫다.

CLAUDE.md와 로그, 테스트 출력처럼 눈에 잘 띄지 않게 컨텍스트를 키우는 요소도 관리해야 한다. 그리고 Claude가 잘못된 방향으로 가고 있다면 오래 실행하게 두지 말고 초기에 계획과 결과를 확인하는 것이 결국 시간과 토큰을 같이 아끼는 방법이 된다.

이번 공식 가이드를 읽으면서 느낀 것은 Anthropic이 말하는 “토큰 절약”이 단순한 꼼수와는 조금 다르다는 점이다.

같은 토큰을 쓰더라도 실제 작업에 필요한 정보에 더 많이 사용하고, 불필요한 컨텍스트와 재처리를 줄이라는 쪽에 가깝다.

개인적으로도 이 방식이 Claude Code를 오래 사용할수록 더 현실적이라고 생각한다.

한 줄로 정리하면 이렇다.

Claude Code 토큰을 아끼는 가장 효과적인 방법은 프롬프트 글자 수를 줄이는 것이 아니라, 현재 작업에 필요하지 않은 컨텍스트와 불필요한 재처리를 줄이는 것이다.


참고 자료

Anthropic - Maximizing the value of your Claude Code sessions
https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions

Anthropic - Lessons from building Claude Code: Prompt caching is everything
https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything

Claude Code Docs - Manage costs effectively
https://code.claude.com/docs/en/costs

Claude Code Docs - How Claude Code uses prompt caching
https://code.claude.com/docs/en/prompt-caching

Claude Code Docs - Explore the context window
https://code.claude.com/docs/en/context-window

Claude Code Docs - Model configuration
https://code.claude.com/docs/en/model-config

Claude Code Docs - How Claude remembers your project
https://code.claude.com/docs/en/memory

Claude Code Docs - MCP
https://code.claude.com/docs/en/mcp

Amazon Bedrock - Prompt caching
https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/prompt-caching.html

Google Cloud Vertex AI - Anthropic Claude Prompt Caching
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/partner-models/claude/prompt-caching

Posted by 모과이IT
,