Claude 4.5의 충격적인 코딩 테스트

AI의 하이프 사이클은 빠르게 변화하며, 클로드 오푸스 4.5가 전격 등장했습니다. 안트로픽은 새로운 클로드 오푸스 모델이 코드 생성 리더보드부터 긴 문맥 추론 테스트에 이르기까지 모든 벤치마크에서 최고라는 주장을 하고 있으며, 이를 진지한 소프트웨어 작업을 위한 “최전선” 시스템으로 자리매김하고 있습니다. 출시 블로그의 차트는 훌륭해 보이지만, 제품은 제공하지 않습니다.

개발자에게 정말 중요한 한 가지 지표가 있다: 이 모델이 이전 모델보다 기능을 더 빠르고 안전하게 배포하게 만드는가? 만약 도구가 수정, 롤백, “왜 이게 프로덕트에서 고장났지?”라는 순간의 수를 줄이지 못한다면, 벤치마크 점수는 사소한 이야기가 된다. 유일하게 중요한 스코어보드는 git 히스토리와 사고 로그에 있다.

그것을 테스트하려면 억지로 만든 LeetCode 퍼즐이나 장난감 CRUD 앱 이상이 필요합니다. 실제 제품 안에서의 진짜 코딩 작업 흐름이 필요하며, 여기에는 엉망인 레거시 코드, 반만 문서화된 구성 요소, 구현 중에 변경되는 UX 요구 사항이 포함됩니다. 그곳에서 Claude Opus 4.5는 과연 그 hype를 증명할 것인지, 아니면 리더보드에서의 승리와 일상적인 엔지니어링 현실 간의 갭을 드러낼 것인지가 드러납니다.

테스트 환경은 Composalo로, 이미 유료 사용자를 보유하고 있고 비범한 코드베이스를 가진 프로덕션 웹 애플리케이션입니다. 설정: Cursor와 터미널 기반 클라우드 코드를 통해 Opus 4.5를 실행하고, 모든 것을 실제 운영 환경에서 유지하며, AI가 스테로이드로 강화된 코드 자동 완성기가 아닌 유능한 쌍 프로그래머처럼 행동할 수 있는지를 확인합니다. 선택된 그린 필드 프로젝트나 정제된 저장소는 없습니다.

워크플로우는 난이도가 점차 상승하는 세 가지 구체적인 작업을 중심으로 구성되어 있습니다. 첫 번째로는 간단한 UI 조정입니다: 사용자들이 이중 클릭과 스크롤을 통해 내장 화면을 사용할 수 있다는 것을 이해할 수 있도록 노드 툴바에 상호작용 모드 버튼을 추가합니다. 순수한 프론트 엔드 작업이며, 범위가 작고 Opus가 기존 컴포넌트를 읽고 기능을 연결할 수 있는지를 테스트하기에 완벽합니다.

다음은 중간 난이도의 기능입니다: 데이터베이스 기반의 "중복 노드" 작업으로, 노드를 복사하고 올바른 데이터를 유지하며 새로운 ID를 생성하고, 프롬프트 히스토리나 오래된 버전을 끌고 가지 않도록 합니다. 마지막으로, 복잡한 스트리밍 UI 동작이 모델을 다중 파일 추론, 상태 관리 및 엣지 케이스 처리로 밀어넣습니다. 벤치마크에 따르면 Claude Opus 4.5가 이를 처리할 수 있다고 합니다. 현실이 그것을 결정할 것입니다.

플랜 모드는 전체 워크플로우를 조용히 실행합니다. Claude Opus가 한 줄의 코드에도 손을 대기 전에 Moritz는 플랜 모드에 들어가 그가 원하는 내용을 설명합니다: 기능이 어디에 위치하는지, 어떻게 작동하는지, 어떤 구성요소에 영향을 미치는지. 이러한 사전 설명은 모델을 스테로이드가 주입된 자동 완성에서 스펙을 받는 주니어 엔지니어에 가까운 것으로 변모시킵니다.

클로드 오퍼스는 그 후 속임수처럼 강력한 행동을 합니다: 그것은 사양을 조사합니다. “어떤 아이콘이 더 마음에 드세요?”와 “버튼은 어디에 위치해야 할까요?”와 같은 질문은 사소해 보이지만, 이는 전체적인 재작업을 없애버립니다. UI 결정을 소환하는 대신, 모델은 커서 포인터 아이콘, 미리보기 버튼 뒤의 위치, 또는 중복 노드가 제목을 수정해야 하는지 여부와 같은 세부 사항을 고정합니다.

이러한 명확한 질문은 잘못된 의도의 안전 장치 역할을 합니다. 모리츠는 버튼이 잘못된 툴바에 위치하게 되었거나 복제 논리가 잘못된 버전 이력을 복사했다는 사실을 발견할 때까지 기다리지 않습니다. 그는 몇 가지 특정한 질문에 답하고, 클로드 오푸스는 코드베이스에 손을 대기 전에 그 제약 사항들을 계획에 반영합니다.

간단한 UI 수정의 경우, 클라우드 코드 내에서 가벼운 왕복 작업으로 충분하다. Moritz는 계획 모드에 머무르며 파일 목록—노드 툴바, 웹 앱 노드, 버튼 스타일링—을 승인한 후, 편집 내용을 자동으로 수락한다. 결과는: 작동하는 상호작용 전환, 올바른 커서 동작, 심지어 클릭 외부 시 비활성화와 같은 엣지 케이스 처리까지, 모두 첫 실행에서 이루어진다.

복잡한 기능은 작업 흐름을 더 무거운 기어로 전환합니다. 데이터베이스 작성, Supabase 스키마 또는 다중 버전 로직이 등장할 때, 모리츠는 클로드 오푸스에게 별도의 계획 문서 생성을 요청합니다. 해당 문서에는 합의된 동작이 기록됩니다: 어떤 필드를 복제할지, 어떤 필드는 생략할지(프롬프트 히스토리, 버전 등)와 같은 규칙, "사용자가 현재 보고 있는 버전만 복제할 것" 등이 포함됩니다.

그 계획 문서는 지속 가능한 유물로 남습니다. 모리츠는:

• 1새로운 Claude Opus 세션으로 재사용하세요.
• 2작곡가 같은 더 빠른 모델에게 넘기세요.
• 3몇 주 후에 다시 검토하여 구현이 특정 방식으로 동작하는 이유를 이해하세요.

부서진 채팅 기록에 의존하는 대신, 워크플로우는 맥락 초기화, 모델 교체 및 인간의 재고를 견뎌내는 안정적인 구현 경로를 구축합니다.

간단한 "콘텐츠와 상호작용" 제어 기능을 추가하는 것은 현대 코딩 모델이라면 쉽게 해결할 수 있는 일입니다. 이 첫 번째 기능을 위해 Claude Opus는 사용자가 숨겨진 더블 클릭 제스처를 통해 발견하는 대신, 임베디드 화면의 상호작용 모드를 명시적으로 전환할 수 있도록 Composalo의 노드 툴바에 새로운 버튼을 연결해야 했습니다.

모리츠는 플랜 모드로 전환하고 변화를 설명한다: 미리보기 버튼 뒤에 위치한 `NodeToolbar`의 아이콘 전용 버튼으로, `WebAppNode` iframe에서 상호작용 모드를 전환한다. 오퍼스는 즉시 두 가지 주요 구성 요소인 UI를 위한 `NodeToolbar`와 iframe 동작을 위한 `WebAppNode`를 식별하고, 비관련 모듈로 벗어나지 않고 해당 파일에만 제한된 수정을 제안한다.

구현은 한 번의 실행으로 진행됩니다. Opus는 툴바 버튼을 추가하고 이를 기존의 더블 클릭 상호작용 로직에 연결하며, 활성 상태가 "지금 임베디드 앱과 상호작용하고 있습니다"를 명확하게 신호할 수 있도록 스타일을 업데이트합니다. Moritz는 로컬 개발 서버를 부팅한 후, 새로운 "콘텐츠와 상호작용" 버튼을 클릭하고 iframe 위에서 커서가 손 모양으로 변경되는 것을 보며 스크롤과 상호작용이 예상대로 작동하는 것을 확인합니다.

그 다음에는 즉흥적인 부분이 옵니다. 사용자에게 요청하지 않고도 Claude Opus는 사용자가 노드 외부에서 클릭할 때 상호작용 모드를 자동으로 비활성화하는 로직을 구현합니다. iframe 외부를 클릭하면 모드가 꺼지고 커서와 동작이 정상으로 돌아옵니다. Moritz는 Sonnet이나 다른 모델이 쉽게 간과할 수 있는 일종의 엣지 케이스 처리로 이를 지적합니다.

이 추가적인 행동은 Opus를 "스테로이드의 자동완성" 범주에서 벗어나 주니어 엔지니어에 더 가까운 무언가로 나아가게 합니다. Opus는 단순히 지침을 따르는 것이 아니라, 사용자를 혼란스럽게 할 수 있는 고착된 상호작용 방식을 추론하고 조용히 이를 수정합니다. Anthropic은 Introducing Claude Opus 4.5 - Anthropic에서 모델에 대한 자사 피치에서 이런 유형의 “적극적인 추론”을 강조하며, 여기에서는 매우 실용적이고 실제 배송 가능한 방식으로 드러납니다.

엣지 케이스는 일반적으로 스프린트의 끝에서 나타나며, QA 테스터가 “하지 말아야 할” 곳을 클릭하면 모든 것이 무너지게 됩니다. 여기에서 클로드 오푸스는 그런 케이스 중 하나를 미리 조용히 처리했습니다: 모리츠가 새로운 “콘텐츠와 상호작용” 모드 바깥을 클릭했을 때, 해당 기능이 자동으로 비활성화되었습니다. 아무도 그런 동작을 요청하지 않았지만, 모델은 어쨌든 그것을 구현했습니다.

그 작은 세부사항이 중요합니다. 절대 꺼지지 않는 고착형 상호작용 모드는 사용자에게 짜증을 주고, 버그 보고와 핫픽스를 소모시키는 UX의 위험 요소입니다. 기본적으로 바깥 클릭으로 해제 패턴을 채택함으로써 Opus는 모달, 드롭다운 및 팝오버에 사용되는 익숙한 웹 관용구와 일치했습니다.

코드보다 더 흥미로운 것은 그 안에 내재된 제품 사고입니다. 모리츠는 상호작용을 전환하는 버튼만 요청했으며, 포커스가 다른 곳으로 이동했을 때 어떤 일이 발생해야 하는지는 명시하지 않았습니다. 오푸스는 이 기능을 위한 합리적인 라이프사이클을 추론했습니다: 클릭 또는 더블 클릭 시 활성화하고, 커서 변화를 통해 모드를 시각적으로 신호하며, 사용자가 다른 곳을 클릭할 때 부드럽게 종료합니다.

그러한 예측적 행동은 Anthropic이 최전선 모델에서 개선된 추론에 대해 이야기할 때 의미하는 바입니다. 이는 단순히 React 코드 조각의 패턴을 맞추는 것이 아니라, 사용자 의도와 실패 모드를 모델링한 후, 이러한 가정을 구현에 반영하는 것입니다. "단순한" UI 조정에서도 Opus는 여전히 상태, 포커스 및 회피 경로에 대해 추론했습니다.

이러한 작은 결함들도 실제 코딩 워크플로우에서는 시간을 절약하는 데 큰 기여를 합니다. 놓친 결함이 발생할 경우, 일반적으로 한 번의 추가 루프가 필요합니다: - 버그를 발견하기 위한 수동 테스트 - 모델에 맥락을 다시 설명하기 - 패치를 재생성하고 앱을 다시 실행하기

기능마다 2-3개의 루프를 피하는 것은 일주일 동안의 개발 기간에서 시간을 절약하는 것으로 이어집니다. 모리츠는 툴팁 복사 편집 외에는 구현에 거의 손을 대지 않았고, 상호작용 해체를 명시하거나 이벤트 리스너를 추가하거나 이상한 멈춤 상태를 추적할 필요가 없었습니다.

수십 가지 기능에 걸쳐 확장됨에 따라, 그 행동은 "코드를 위한 자동 완성"처럼 보이기보다는 편집기에 내장된 주니어 제품 엔지니어처럼 보이기 시작합니다. 완벽하지는 않지만, 전지전능하지도 않지만, 점점 실제 사용자가 화면을 어떻게 클릭할지를 생각할 수 있는 능력이 향상되고 있습니다.

중간 난이도의 작업은 속기 쉬운 간단한 요청으로 도착했습니다: 노드 복제 버튼으로, 이는 React UI와 백엔드 데이터베이스 모두에 영향을 미쳤습니다. Moritz는 이를 노드 툴바의 액션 드롭다운에 배치하여 기존 액션들과 함께 살도록 하길 원했으며, 현재 노드를 캔버스에 인라인으로 복사하는 기능을 제공해야 했습니다. 모의 데이터도 없이, 클라이언트 전용 해킹 없이—이것은 실제 지속성 레이어에 적용되어야 했습니다.

그가 Claude Opus 4.5에 입력한 프롬프트는 매우 구체적이었다. 모델은 노드 데이터를 복제하고 새로운 UUID를 생성하며, 상태의 전체 범주를 건너뛰어야 했다: 프롬프트 히스토리, 이전 버전, 낡은 컨텍스트를 우연히 끌어들이는 숨겨진 메타데이터는 없었다. 또한 Composalo의 버전 관리 모델을 존중해야 했는데, 여기서 수정 사항은 사용자가 순환할 수 있는 별도의 “버전”으로 쌓인다.

Opus 4.5는 모든 열을 단순히 복사하는 대신 최소 중복 집합을 추론했습니다. 제목, 내용, 레이아웃, 유형과 같은 핵심 노드 필드를 유지하면서 역사 테이블과 버전 기록은 생략했습니다. 가시적인 레이블의 경우, 제목에 “복사” 접미사를 추가하여 “랜딩 페이지 v2”가 “랜딩 페이지 v2 (복사)”와 같은 형태로 변환되어, 복잡한 캔버스에서 혼란을 줄이는 작은 사용자 경험 세부 사항이 되었습니다.

데이터베이스 측면에서, 이 모델은 원래 ID를 재사용하거나 수동으로 조정하는 대신 새로운 UUID로 적절한 삽입을 설정했습니다. 이 단계는 사소하게 들리지만, 많은 AI 생성 패치들이 실패하는 정확한 지점입니다. ID 충돌, 원본 행 변형, 또는 외래 키 관계를 잊어버리는 경우가 많기 때문입니다. 여기에서 Opus 4.5는 일반 UI를 통해 생성된 다른 노드처럼 작동하는 깔끔한 새로운 행을 생성했습니다.

흐름은 여러 계층을 아우르며: 툴바 버튼, 클릭 핸들러, API 호출, 데이터베이스 기록, UI 새로 고침. Opus 4.5는 이러한 요소들을 일관되게 유지하며, React 컴포넌트에서 올바른 노드 식별자를 백엔드로 전달하고 새로 생성된 노드를 반환하여 프론트엔드가 원래 위치 "바로 옆에" 배치할 수 있도록 했다. 유령 상태, 유령 노드, 수동 정리는 없다.

이 중간 수준의 도전은 벤치마크가 거의 측정하지 않는 것을 드러냈습니다: 스택 간의 상태 기반 추론. Opus 4.5는 단순히 SQL 문이나 React 컴포넌트를 고립된 상태에서 작성한 것이 아닙니다; 그것은 이들을 조정하고, 버전과 이력에 대한 애플리케이션별 규칙을 존중하며, 실제 사용자들이 하루 종일 중복 버튼을 누르는 상황에서도 지속될 수 있는 기능을 출시했습니다.

Composalo의 기존 "편집 노드" 흐름을 리트로핏하면서 Claude Opus 4.5의 강점과 여전히 부족한 점이 드러났습니다. Moritz는 Opus에게 이 앱의 새로운 실시간 스트리밍 UI를 이미 복잡한 편집 파이프라인에 통합할 것을 요청했습니다. 이는 처음부터 만들기보다는 살아있는 조직에 수술을 하는 것과 같았습니다.

문제는 수정 방식에 두 가지가 있다는 것입니다. 전역 수정은 전체 노드—제목, 내용, 메타데이터—를 재작성하는 반면, 섹션 수정은 단지 특정 부분, 예를 들어 단락이나 블록에만 적용됩니다. 스트리밍 레이어는 이러한 구분을 이해하고 나머지 React 트리를 지우지 않고 관련된 영역만 다시 렌더링해야 했습니다.

그것은 기존 상태, 낙관적인 업데이트 및 서버 응답을 고려하지 않으면 간단하게 들립니다. 이 앱은 이미 비스트리밍 편집 로직을 가지고 있었기 때문에, Opus는 스트리밍 콜백을 다음을 통해 연결해야 했습니다: - 노드 편집기 UI - 백엔드 변형 핸들러 - 섹션별 렌더링 컴포넌트

오푸스 4.5는 그 아키텍처를 놀라울 정도로 잘 매핑했습니다. 부분 응답을 적절한 구성 요소로 파이프하는 스트리밍 핸들러를 도입했으며, 이를 전체 및 섹션 편집 경로에 연결하고, 토큰이 흘러 들어오는 동안 노드의 나머지 부분이 안정적으로 유지되도록 했습니다.

전 세계 편집에서는 업데이트된 콘텐츠가 전체 노드 보기로 스트리밍되어 이전 버전을 점진적으로 교체했습니다. 섹션 편집에서는 해당 하위 섹션만 실시간으로 업데이트되었고, 주변 콘텐츠는 정지 상태로 유지되었습니다. 전체 페이지 깜박임 없이, 대규모 상태 초기화 없이, 데모 중 눈에 띄는 경쟁 조건도 없었습니다.

구현에는 여전히 이음새가 보였습니다. 스트림 중간에 섹션을 빠르게 전환하거나 편집을 중단하는 등 몇 가지 엣지 케이스는 완벽한 방어가 없었습니다. 몇몇 추상화는 통합되기보다는 부착된 것처럼 느껴졌으며, 이상적으로는 전송 세부사항을 알지 말아야 할 컴포넌트로 스트리밍 논리가 흘러들어갔습니다.

모리츠는 네이밍 정리에 나서고, 중복된 코드를 정리하며, 스트리밍 페이로드에 대한 일부 TypeScript 타입을 강화해야 했다. 오퍼스는 핵심 동작을 작동시켰지만, 선임 엔지니어가 추출할 수 있는 수준의 세련된 라이브러리급 API는 제공하지 못했다.

유사한 패턴을 채택하는 개발자들을 위해 Anthropic Python SDK - GitHub와 같은 도구는 모델 프롬프트에서 안정적인 클라이언트 추상화로 이동해야 할 인체공학적 스트리밍 지원이 얼마나 필요하는지를 강조합니다.

배송은 괜찮았지만 완벽하지는 않았다. 모리츠가 클로드 오퍼스를 그의 실시간 편집 UI에 연결했을 때, 새로운 스트리밍 동작이 기술적으로 작동했다: 텍스트 업데이트가 모델이 생성하는 대로 흐르고, 네트워크 호출이 정확하게 작동하며, 기능이 사양과 일치했다. 하지만 스트리밍이 시작될 때마다 편집기는 업데이트가 시작되기 전에 작고 부정할 수 없는 UI 깜박임이 일었다.

그 작은 결함은 현대 AI 지원 개발의 90/10 규칙을 잘 보여주었다. Claude Opus는 기존의 “편집 노드” 기능을 이해하고, 새 스트리밍 파이프라인을 연결하며, 적절한 React 컴포넌트 및 API 핸들러에 접근하는 주요 작업을 처리했다. 그러나 마지막 10%—사용자가 실제로 느끼는 부분—는 여전히 렌더링 타이밍, 상태 전환, 그리고 React 트리가 스트레스 아래에서 어떻게 작동하는지를 이해하는 사람에게 의존하고 있었다.

모델은 앱의 논리를 존중했지만 렌더 생명주기의 미세한 차이를 놓쳤습니다. 상태를 올바른 위치에서 업데이트하고 스트리밍 콜백을 올바르게 연결했지만, 중간의 빈 상태나 이중 렌더링이 구성 요소가 잠시 언마운트됐다가 재마운트되는 원인이 될 것이라고 예상하지 못했습니다. 컴파일러에게는 모든 것이 괜찮아 보였지만, 사용자에게는 편집기가 정확히 잘못된 순간에 깜박였습니다.

그 간극은 현재의 최전선 모델이 실제로 무엇을 최적화하는지를 드러냅니다. Claude Opus는 구조적 추론에서 뛰어납니다: 데이터 흐름 매핑, 유형 추론, API 경계 추적, 그리고 문맥을 잃지 않으면서 다중 파일 기능 리팩토링을 수행하는 데 강점을 가지고 있습니다. 그러나 프레임 별 UX 품질—레이아웃 혼란을 피하고, 수화 불일치를 방지하며, 로딩 스켈레톤을 매끄럽게 하는 일—은 벤치마크가 측정하지 않는 암묵적 지식의 영역에 존재합니다.

모리츠는 또 다른 계획이 필요하지 않았다; 그는 맛과 경험이 필요했다. 그는 개입하여 깜박임이 구성 요소가 스트리밍 상태를 초기화하는 방식에서 비롯된 것임을 인식하고, 토큰이 도착하는 동안 뷰가 안정적으로 유지되도록 렌더링 경로를 조정해야 했다. 그 모델은 그를 "존재하지 않는 기능"에서 "작동하는 기능"으로 몇 분 만에 이끌었지만, "앱에 원래 있는 것처럼 느껴지게" 하려면 여전히 수동 디버깅이 필요했다.

이러한 균형은 Claude Opus In Production의 현실적인 모습입니다. AI는 기능을 구축하고, 접근 방식을 탐색하며, 보일러플레이트를 처리하는 데 있어 힘을 배가하는 역할을 합니다. 그러나 최종 단계는 여전히 인간이 책임집니다: 다듬기, 가드레일 설정, 그리고 데모와 제품을 구분짓는 보이지 않는 세부 사항들입니다.

인간-AI 조합은 제작 습관처럼 느껴질 때만 효과적이며, 데모 장치처럼 느껴져서는 안 됩니다. Moritz의 Composalo 빌드는 Claude Opus를 실질적인 팀처럼 보이는 세 단계의 루프로 바꿉니다: 설계자, 실행자, 검토자. 그 결과: 레포를 엉망으로 만들지 않고 한 번에 여러 기능을 발행할 수 있습니다.

첫 번째 단계는 구성 및 계획입니다. 사람은 간단한 언어로 "무엇"과 "왜"를 정의한 다음, Claude Opus를 코드 자판기가 아니라 중요한 파트너로 사용합니다. Moritz는 "계획 모드"로 전환하고 관련 구성 요소("노드 툴바")를 태그한 후 제약 사항(스크롤 바 없음, 최소 아이콘, 상호 작용 모드 전환)을 명시하며 파일을 열기 전에 모델이 명확한 질문을 하도록 강요합니다.

그 계획 패스는 두 가지를 수행합니다. UX 결정을 조기에 드러내고(커서 아이콘, 버튼 배치, 클릭 밖 행동) 별도의 계획 문서에서 존재할 수 있는 가벼운 사양을 만듭니다. 데이터베이스 작업을 위해 Moritz는 한 가지 엄격한 규칙을 추가합니다: 먼저 스키마를 요청한 다음 변경 사항을 제안하는 것입니다. 이는 AI가 테이블 이름이나 필드를 잘못 인식하는 것을 방지합니다.

두 번째 단계는 AI 생성입니다. 계획이 타당해 보이면, Claude Opus는 지루한 부분을 처리합니다: 보일러플레이트 React 컴포넌트, 핸들러 연결 및 기존 훅을 통해 상태 스레딩. “콘텐츠와 상호 작용” 기능에서 모델은 툴바를 수정하고, iframe 컨테이너를 업데이트하며, 한 번의 작업으로 활성화/비활성화 논리를 연결했습니다.

같은 패턴이 UI와 데이터베이스 모두에 영향을 미치는 "중복 노드" 기능으로 확장되었습니다. Moritz는 Opus에게 처음부터 끝까지의 흐름을 구상하게 했습니다: 새로운 툴바 액션, 서버 호출, 노드 복제 로직, 그리고 중복 노드를 원본 바로 옆에 배치하는 과정입니다. 스트리밍 편집기와 같은 장기적인 변화에 대해서는 모델이 여러 파일을 연결하면서도 정신적인 스택을 잃지 않는 중급 엔지니어 역할을 효과적으로 수행했습니다.

세 번째 단계는 인간이 다듬고 polish하는 것입니다. 모리츠는 수석 리뷰어로서 코드에 다시 들어가 앱을 실행하고 엣지 케이스를 살펴보며 손으로 더 빠르게 마이크로 수정을 합니다. 그렇게 그는 실시간 스트리밍 버그를 발견했습니다. 이는 스트리밍 콘텐츠가 렌더링되기 전 UI의 깜박임이었습니다. 이로 인해 상태를 더 깔끔하게 유지하는 두 번째 반복이 필요했습니다.

중요하게도, 그는 판단을 외부에 맡기지 않습니다. 소소한 문구 수정(“더블 클릭하여 상호작용하기”), 시각적 다듬기, 데이터 무결성에 대한 생산적인 불안감은 인간이 소유합니다. AI가 먼저 움직이고, 인간이 무엇을 발송할지 결정합니다.

루프처럼 실행하세요—계획, 생성, 검토—이 워크플로우는 품질을 저버리지 않으면서 속도를 극대화합니다. 클로드 오퍼스는 80%의 힘든 작업을 가속화하고, 개발자는 사용자 경험, 아키텍처 및 정확성을 보호합니다. 한 가지 잘못된 가정이 릴리스를 망칠 수 있기 때문입니다.

벤치마크와 마케팅 카피는 하나의 이야기를 전달하지만, Moritz의 실제 코딩 작업 흐름은 Anthropic의 새로운 조정 장치가 코드 배포 시 실제로 무엇을 의미하는지를 보여줍니다. 자주 언급되는 노력 매개변수와 줌과 같은 컴퓨터 사용 업그레이드는 Opus가 실제 코드베이스에서 변경 사항을 조용히 스레드하면서 빌드를 폭파시키지 않는 모습을 보면 더 이상 추상적이지 않게 됩니다.

일상적인 개발에서는 노력이 의도와 깔끔하게 일치합니다. 지루한 작업에는 낮은 노력을 사용합니다: React 보일러플레이트 생성, 기존 툴바에 버튼 연결, 기본 API 핸들러 구상, 또는 테스트 스텁 초안 작성 등이 해당됩니다. 모델이 얽힌 상태, 경쟁 조건 또는 사용자 흐름에 대해 추론해야 할 때는 높은 노력으로 전환합니다. 예를 들어 서버 응답, 클라이언트 상태 및 기존 사용자 경험 기대치를 조정해야 했던 스트리밍 편집 UI와 같은 경우가 이에 해당합니다.

그 분할은 대부분의 팀에 대한 실용적인 패턴을 제안합니다: - 낮은 노력: 스캐폴딩 및 반복적인 글루 코드 - 중간 노력: 익숙한 패턴 내의 기능 작업 - 높은 노력: 교차 커팅 로직, 데이터 모델링 및 복잡한 비동기 흐름

모리츠의 세션은 앤트로픽이 왜 신뢰성에 대해 계속 이야기하는지를 암시합니다. 여러 기능에서 오퍼스는 최소한의 도구 호출 문제와 재앙적인 빌드 실패 없이 편집물을 생성하였으며, 이는 프로덕션 스타일 테스트에서 50-75% 적은 도구 및 린트 오류에 대한 외부 보고서와 일치합니다. 하루에 수십 번 실행되는 CI 파이프라인의 경우, 실패 소음을 10-15% 줄이는 것만으로도 엔지니어링 주의 시간을 몇 시간을 되찾을 수 있습니다.

그렇게 보면, Claude Opus 4.5는 “그저 코드 생성기”처럼 보이지 않고 시스템을 인식하는 협업자로 변모합니다. 구성 요소의 경계를 기억하고, 안내받을 때 데이터베이스 계약을 존중하며, 무시하지 않고 기존 아키텍처를 탐색합니다. 정확한 숫자가 중요하다면, Claude Opus 4.5 벤치마크 - Vellum AI가 통과율 및 토큰 효율성 데이터를 통해 그 질적 느낌을 뒷받침합니다.

당신에게 중요한 점은 간단합니다: Opus를 실제 스택에 연결하고, 노력을 예산 조정처럼 활용하며, LLM이 여전히 이해하지 못하는 시스템의 부분—제품의 절충, 아키텍처의 베팅, 그리고 사용자가 진정으로 원하는 "충분한" 것이 무엇인지에 대한 시간은 아껴두세요.

AI는 개발자의 역할을 지우는 것이 아니라, 재구성합니다. 클로드 오퍼스 4.5가 모리츠의 작업 목록을 처리하는 모습을 보면 그게 분명해집니다: 모델은 보일러플레이트, 배선, 리팩터링을 처리하는 반면, 인간은 제품의 방향을 계속 잡습니다. 직무는 “하루 종일 코드를 입력하는 사람”에서 “무엇이 언제 존재해야 하는지를 결정하는 사람”으로 변화합니다.

Claude Opus가 실제로 자동화하는 것은 선임 엔지니어들이 불만을 제기하는 부분과 이상하게도 유사합니다. UI 컴포넌트를 기초로 하고, 기존 툴바에 새로운 버튼을 연결하며, 프론트엔드와 백엔드 간의 데이터 구조를 복제합니다. 모리츠의 실제 코딩 워크플로우에서 Opus는 “콘텐츠와 상호작용” 버튼과 데이터베이스 기반의 중복 노드 기능을 거의 사람의 입력 없이 프롬프트만으로 처리했습니다.

모델이 실패하는 곳에서 새로운 개발자가 편집장으로 등장합니다. 그 스트리밍 UI 리트로핏은 기능적으로 작동했지만 미세한 깜박임이 발생했습니다. 어떤 벤치마크도 이를 포착하지 못하지만, 제품의 감각을 가진 인간은 그것을 알아챕니다. 개발자의 역할은 UX의 틈을 찾아내고, 성능 예산을 관리하며, 더 깔끔한 아키텍처를 위해 AI 생성 코드를 제거해야 할 시점을 결정하는 것으로 변모합니다.

미래 지향적인 엔지니어는 아키텍처와 제품 사고에 더 많은 노력을 기울입니다. Opus에게 한 줄의 코드를 작성해 달라고 요청하기 전에 이벤트 흐름, 오류 경계, 데이터 소유권을 결정합니다. 제약 조건—대기 시간 한도, 접근성 규칙, 테스트 커버리지—을 정의한 다음 AI의 구현이 실제로 이러한 제약을 준수하는지 판단합니다.

일상적으로, 이는 반복 가능한 루프처럼 보입니다:

• 1정확한 제약 조건을 갖춘 계획 모드에서 문제를 설정합니다.
• 2클로드 오푸스가 디자인 및 패치 세트를 제안하게 하세요.
• 3코드를 단순히 들여다보지 말고, 스태프 엔지니어처럼 리뷰하세요.
• 4UX, 보안 또는 성능과 관련된 10–20%를 수동으로 다듬습니다.

이 인간-AI 인수를 마스터한 개발자들은 주니어에서 기술 리드로 이동하는 것과 유사한 레버리지를 얻습니다. 여러분은 여전히 정확성, 유지 보수성, 사용자 경험에 대한 책임이 있지만, 반복적인 노동은 지루함을 느끼지 않는 시스템에 위임합니다. 직무 설명은 줄어들지 않고, 더 전략적이고 창의적인 형태로 확장되며, 적응하는 이들에게는 훨씬 더 강력해집니다.

클로드 오푸스 4.5란 무엇인가요?

Claude Opus 4.5는 복잡한 소프트웨어 엔지니어링 작업, 에이전트워크플로우 및 향상된 코딩 성능을 위해 특별히 최적화된 Anthropic의 최신 최첨단 추론 모델입니다.

Claude Opus 4.5는 코딩 워크플로우를 어떻게 개선하나요?

복잡한 요구 사항을 이해하고, 명확한 질문을 하며, 엣지 케이스를 선제적으로 처리하고, 프론트엔드와 백엔드 코드를 생성하여 초기 개발 시간을 크게 단축시킴으로써 워크플로우를 개선합니다.

Claude Opus 4.5가 다른 모델에 비해 코딩에 더 좋은가요?

'더 나은' 것은 주관적이지만, Opus 4.5는 장기 코드 작업에서 상당한 개선을 보여주며 맥락에 대한 깊은 이해를 바탕으로 실제 테스트에서 볼 수 있듯이 작동 결과를 얻기 위해 필요한 반복 횟수가 종종 줄어듭니다.

시험에서 가장 어려운 과제는 무엇이었나요?

가장 어려운 작업은 '편집 노드' 기능에 대한 실시간 스트리밍 미리보기를 구현하는 것이었습니다. 모델은 핵심 로직을 성공적으로 구현했지만, 약간의 UI 버그(깜박임)를 발생시켜 인간의 세밀한 조정이 필요했습니다.