Claude Code가 짠 코드를 어느 정도 까지 믿을 것 인가에 대해 Dario Amodei의 AI 구조화 철학에서 답을 찾다

"더 조심스럽게 만들지 않으면, 아무도 안 만들 거다"

2021년, Dario Amodei는 OpenAI의 부사장 자리를 버리고 나왔다. 이유는 단순했다. "모델을 더 크게, 더 빠르게 만드는 것"에만 집중하는 조직에서는 안전한 AI를 만들 수 없다고 판단한 것이다. 그는 동생 Daniela Amodei와 함께, OpenAI 동료 11명을 데리고 Anthropic을 창업했다.

그가 Fortune 인터뷰에서 한 말이 있다.

"모델에 더 많은 컴퓨팅을 쏟아붓는다고 해서 그 모델의 가치관이 정해지는 것은 아니다."

이 한마디에 Anthropic의 철학이 압축되어 있다. 성능과 안전은 별개의 축이며, 안전은 의도적으로 설계해야 한다는 것. 그리고 이 철학이 Claude라는 모델의 아키텍처에, Claude Code라는 도구의 구조에, 그리고 궁극적으로 Claude Code가 생성하는 코드의 신뢰성에까지 관통한다.

이 글에서는 Anthropic CEO Dario Amodei의 AI 안전 철학이 어떤 구조로 구현되어 있는지를 따라가면서, 프로그래머로서 Claude Code의 코드를 어디까지 믿어도 되는지를 이야기한다.

---

1. Constitutional AI — 규칙이 아니라 인격을 심는다

RLHF의 한계에서 출발한 아이디어

대부분의 LLM은 RLHF(Reinforcement Learning from Human Feedback)로 정렬(alignment)한다. 사람이 "이 답변이 좋다/나쁘다"를 판단하고, 그 피드백으로 모델을 훈련한다. 문제는 사람의 판단이 일관되지 않다는 것이다. 라벨러 A가 "괜찮다"고 한 답변을 라벨러 B는 "위험하다"고 판단할 수 있다. 스케일이 커질수록 이 불일치는 심해진다.

Anthropic의 대안이 **Constitutional AI(헌법적 AI)**다. 핵심은 이렇다:

1. AI에게 일련의 원칙(헌법)을 준다
2. AI가 스스로 자신의 응답을 비판하게 한다 — "이 응답이 헌법에 부합하는가?"
3. 비판 결과를 바탕으로 더 나은 응답을 생성하고, 이를 훈련 데이터로 쓴다

사람의 개별 판단에 의존하는 RLHF와 달리, 원칙 문서가 기준점이 된다. Amodei의 표현을 빌리면, "아이가 책에 나오는 롤모델을 보고 인격을 형성하는 것"과 같다.

이게 코드 생성과 무슨 관계인가

Claude Code가 코드를 생성할 때, 그 기저에는 Constitutional AI로 형성된 모델의 "성향"이 작동한다. 이것은 단순히 "위험한 코드를 거부한다"는 수준이 아니다.

• 정직성: 모르는 것을 아는 척하지 않는다. 확실하지 않은 라이브러리 사용법을 추측으로 작성하기보다, 불확실성을 표현한다
• 무해성: SQL 인젝션에 취약한 코드, 하드코딩된 시크릿, 검증 없는 입력 처리를 "자연스럽게" 피한다
• 유용성: 안전하다고 아무것도 안 하는 게 아니라, 안전한 범위 내에서 최대한 돕는다

이 세 가지 — Helpful, Honest, Harmless — 가 Claude의 헌법의 뼈대이고, 코드 생성에도 그대로 적용된다.

---

2. Responsible Scaling Policy — "얼마나 강력한가"에 따라 통제 수준이 달라진다

AI Safety Level(ASL) 프레임워크

Amodei가 설계한 Responsible Scaling Policy의 핵심은 모델의 능력이 올라갈수록 안전 장치도 비례해서 강화해야 한다는 원칙이다. Anthropic은 이를 ASL(AI Safety Level)이라는 단계로 구분한다.

• ASL-1: 기본 수준. 최소한의 안전 장치
• ASL-2: 현재 대부분의 모델. 기본적인 오용 방지, Constitutional AI 적용
• ASL-3: 비국가 행위자의 위험 능력을 증강할 수 있는 수준. 강화된 보안과 배포 통제 필요
• ASL-4 이상: 자율적 위험 행동 가능. 최고 수준의 격리와 감시

Claude Opus 4 이후 모델들은 ASL-3 보호 조치하에 배포되었다. 이것이 의미하는 바는, 단순히 "나쁜 답변을 필터링한다"가 아니라, 모델의 능력 자체를 평가하고 그에 맞는 구조적 안전 장치를 설계한다는 것이다.

코드 생성 도구에 적용되는 의미

Claude Code는 단순한 코드 자동완성이 아니라, 파일을 만들고, 명령을 실행하고, 시스템을 수정할 수 있는 에이전트다. 이 수준의 권한을 가진 도구에는 ASL 개념이 직접적으로 적용된다:

• 기본 읽기 전용: Claude Code는 기본적으로 read-only 권한으로 시작한다. 파일 수정, 테스트 실행, 명령 실행 시 매번 명시적 승인을 요구한다
• Fail-closed 매칭: 매칭되지 않는 명령은 기본적으로 수동 승인 필요
• 명령어 인젝션 감지: 의심스러운 bash 명령은 이전에 허용 목록에 있더라도 수동 승인 필요
• 자격 증명 암호화: API 키와 토큰은 암호화 저장

이것은 "AI가 실수하지 않는다"가 아니라 **"실수하더라도 피해 반경을 최소화하는 구조"**를 만든 것이다.

---

3. Interpretability — "왜 그렇게 했는지"를 들여다보는 기술

블랙박스를 열겠다는 집념

Amodei가 2026년 발표한 "The Urgency of Interpretability" 에세이에서 이런 말을 했다.

"2026~2027년에 데이터센터 안의 천재 국가에 해당하는 AI 시스템이 등장할 수 있다. 해석 가능성에 대한 더 나은 이해 없이 이런 시스템을 배포하는 것은 기본적으로 받아들일 수 없다."

Anthropic은 Claude 내부의 수백만 개 특징(feature)을 매핑하고, 새 모델을 출시하기 전에 이 맵을 사용해 감사(audit)한다. Amodei의 표현을 빌리면, 해석 가능성은 모델 정렬의 "테스트 셋" 역할을 한다. RLHF나 Constitutional AI가 훈련 과정이라면, 해석 가능성은 그 훈련이 실제로 작동했는지를 독립적으로 검증하는 장치다.

코드 신뢰와의 연결

이 해석 가능성 연구가 코드 생성에 주는 영향은 간접적이지만 근본적이다. 모델이 "왜" 특정 코드를 생성했는지를 연구진이 분석할 수 있다면:

• 모델이 보안 취약점을 알면서도 생성하는 패턴을 사전에 발견하고 교정할 수 있다
• 특정 도메인에서 모델의 확신도가 낮은 영역을 파악하고, 해당 영역에서의 출력에 경고를 붙일 수 있다
• "겉으로는 정렬된 척하지만 실제로는 아닌" 모델 행동을 탐지할 수 있다

다시 말해, Claude Code가 짠 코드를 믿을 수 있는 이유 중 하나는, Anthropic이 Claude가 "왜" 그 코드를 짰는지를 들여다보는 기술을 개발하고 있기 때문이다.

---

4. Claude Code Security — 자기가 짠 코드를 자기가 검증한다

2026년 2월, 게임 체인저의 등장

2026년 2월, Anthropic은 Claude Code Security를 출시했다. Opus 4.6을 사용해 코드 취약점을 스캔하고 패치를 제안하는 기능이다. 출시와 함께 프로덕션 코드베이스에서 500개 이상의 제로데이 취약점을 발견했다. 수십 년간 전문가 리뷰와 퍼징을 통과한 힙 버퍼 오버플로우까지 잡아낸 것이다.

사이버보안 주식이 일시적으로 폭락할 정도의 충격이었다.

자기 검증의 구조적 한계를 아는 것이 중요하다

여기서 냉정해져야 한다. OX Security의 분석이 정확하다. 같은 시스템이 코드를 작성하고, 평가하고, 필터링하고, 패치하면, 독립적 검증이 아니라 자기 승인(self-approval)이 된다. 보안은 항상 "만드는 사람과 검증하는 사람을 분리"하는 데서 출발한다.

또한 SonarSource의 분석에 따르면, Opus 4.6으로 생성한 코드의 취약점 밀도가 이전 버전 대비 55% 증가했다는 데이터도 있다. AI가 개발 속도를 높이는 만큼, 가장 잡기 어려운 종류의 리스크도 함께 증폭된다는 뜻이다.

그러니 결론은 이렇다: Claude Code Security는 강력한 1차 방어선이지만, 유일한 방어선이 되어서는 안 된다. SonarQube, Snyk 같은 독립적 SAST/DAST 도구와 병행해야 한다. 이건 Anthropic의 도구를 불신해서가 아니라, 보안 아키텍처의 기본 원칙이다.

---

5. 그러면 Claude Code의 코드를 "어떻게" 믿을 것인가

지금까지의 이야기를 정리하면, Anthropic은 다른 AI 회사들과 근본적으로 다른 접근을 하고 있다:

계층                            Anthropic의 접근                                                                  코드 신뢰에 미치는 영향

모델 훈련	Constitutional AI — 원칙 기반 자기 비판	코드 생성 시 안전하지 않은 패턴을 "자연스럽게" 회피
능력 통제	ASL 프레임워크 — 능력 비례 안전 장치	에이전트 권한을 최소 권한 원칙으로 설계
내부 감사	해석 가능성 연구 — 모델 내부 특징 매핑	모델의 취약점 생성 경향을 사전 탐지 및 교정
실행 환경	Claude Code 권한 시스템 — fail-closed, 명시적 승인	실수의 피해 반경 최소화
사후 검증	Claude Code Security — AI 기반 취약점 스캐닝	생성된 코드의 1차 보안 검증
기업 거버넌스	PBC + LTBT — 안전을 위해 수익을 양보할 수 있는 법적 구조	상업적 압박에 안전이 밀리지 않는 구조적 보장

이 6개 계층이 중첩되어 있다는 것이 핵심이다. 어느 한 계층도 완벽하지 않지만, 여러 겹이 겹치면 실패 확률은 곱셈으로 줄어든다.

실전에서의 신뢰 전략

프로그래머로서 Claude Code의 코드를 다룰 때 권장하는 접근법:

1. Claude Code를 "시니어 개발자의 초안"으로 취급한다. 초안이 훌륭할 수 있지만, 코드 리뷰 없이 머지하지는 않는다. Claude Code가 생성한 코드도 마찬가지다.

2. 보안 검증은 독립적 도구와 병행한다. Claude Code Security를 1차로 쓰되, SonarQube, ESLint security rules, OWASP ZAP 같은 독립적 도구를 2차 검증에 사용한다.

3. 권한 설정을 최소로 유지한다. Claude Code의 기본 read-only 모드를 존중한다. --dangerously-skip-permissions 같은 옵션은 이름 그대로 위험하다.

4. 도메인 판단은 사람이 한다. Claude Code가 아무리 뛰어나도, "이 아키텍처가 우리 상황에 맞는가", "이 라이브러리가 라이선스 조건에 부합하는가", "이 쿼리가 실제 데이터 규모에서 성능이 나오는가"는 개발자가 판단해야 한다.

---

맺으며: 신뢰는 구조에서 온다

Dario Amodei가 2026년 국방부의 자율무기 요구를 거부할 수 있었던 이유는, 개인의 용기 때문만이 아니다. PBC 법인 구조, LTBT 신탁, Constitutional AI 훈련, ASL 프레임워크 — 이 모든 것이 "안전을 위해 수익을 양보하는 결정"을 법적·기술적·조직적으로 지탱하는 구조였기 때문이다.

Claude Code의 코드를 믿을 수 있는 이유도 같은 맥락이다. 한 명의 천재가 만든 완벽한 모델이라서가 아니라, 여러 계층의 안전 구조가 중첩되어 실패를 가두기 때문이다.

물론 맹신은 금물이다. AI가 생성한 코드는 AI가 생성한 코드다. 하지만 "어떤 AI가 생성했는가"는 중요하다. 그리고 그 "어떤"을 결정하는 것은 벤치마크 점수가 아니라, 그 코드 뒤에 있는 철학과 구조다.

Anthropic이 완벽한 회사라는 뜻은 아니다. 다만, "AI가 생산한 코드를 언제, 얼마나 신뢰할 것인가"라는 질문에 대해 가장 체계적인 답을 제시하고 있는 회사라는 것은 분명하다.

---

"가드레일을 설치한 회사가 파는 차에 달린 가드레일은, 도로 당국이 설치한 가드레일과 같지 않다. Amodei도 아마 그 비판에 동의할 것이다. 그는 그것을 알면서도 차를 만들고 있다. 아무도 이보다 더 조심스럽게 만들지 않을 테니까."