요약: Anthropic은 2026년 6월 11일 Claude code execution tool이 code_execution_20260521을 지원한다고 공지했습니다. 이 버전은 도구 설명에 셀당 90초 실행 제한을 명시해 Claude가 긴 실행을 더 잘 예산화할 수 있게 합니다. 데이터 분석, 리포트 생성, 코드 검증 에이전트를 만드는 팀은 긴 작업을 “한 번에 실행”이 아니라 “90초 안에 끝나는 셀 단위 파이프라인”으로 설계해야 합니다.
코드 실행 도구를 붙인 AI 에이전트는 강력합니다. CSV를 읽고, 통계를 내고, 차트를 만들고, 테스트 코드를 실행하고, 결과를 설명할 수 있습니다. 하지만 실행 환경에는 항상 제한이 있습니다. 시간 제한, 메모리 제한, 파일 크기 제한, 네트워크 제한이 대표적입니다. 이 제한이 프롬프트나 도구 설명에 드러나지 않으면 모델은 현실보다 큰 계획을 세우기 쉽습니다.
Anthropic release notes에 따르면 code_execution_20260521은 셀당 90초 실행 제한을 도구 설명에 공개합니다. 별도 beta header는 필요 없다고 안내합니다. 이 변화는 작아 보이지만, 에이전트 설계에는 중요합니다. 모델이 제한을 알면 대용량 작업을 쪼개거나, 먼저 샘플링하거나, 중간 산출물을 저장하는 전략을 선택할 가능성이 높아집니다.
운영 관점에서 핵심은 제한을 모델에게만 맡기지 않는 것입니다. 애플리케이션도 작업을 작은 단계로 나누고, 각 단계의 입력·출력·시간을 관리해야 합니다. 그래야 실패했을 때 전체를 처음부터 다시 실행하지 않고 특정 단계만 재시도할 수 있습니다.
데이터 분석 에이전트라면 셀을 역할별로 분리합니다. 첫 셀은 파일 로딩과 스키마 확인만 합니다. 둘째 셀은 결측치, 타입, 행 수, 기본 통계를 계산합니다. 셋째 셀은 분석 질문에 필요한 집계만 수행합니다. 넷째 셀은 시각화나 표 생성을 맡깁니다. 이렇게 나누면 한 셀이 실패해도 원인을 찾기 쉽습니다.
나쁜 예시는 “이 2GB CSV를 읽고 전체 EDA를 수행하고 그래프 10개를 만들어줘”입니다. 좋은 예시는 “먼저 파일 크기와 컬럼 목록을 확인하고, 10,000행 샘플로 타입과 결측치를 추정한 뒤, 필요한 컬럼만 골라 다음 단계 계획을 세워줘”입니다. 같은 목표라도 실행 제한을 반영하면 안정성이 달라집니다.
코드 검증 에이전트도 마찬가지입니다. 전체 테스트를 한 번에 돌리기보다 실패 가능성이 높은 테스트 파일, 변경된 패키지, 빠른 unit test, 느린 integration test 순서로 나눕니다. 각 단계가 90초를 넘을 것 같으면 더 작은 명령으로 쪼개거나 타임아웃이 긴 외부 CI에 넘깁니다.
긴 분석 작업에서 가장 중요한 셀은 본 분석이 아니라 사전 진단입니다. 파일 크기, 컬럼 수, 행 수, 압축 여부, 결측치 비율, 고유값 수를 먼저 확인해야 합니다. 이 정보를 모르면 모델은 비싼 연산을 바로 실행할 수 있습니다.
예를 들어 사용자 로그 데이터에서 전환율을 분석한다고 가정해보겠습니다. 전체 데이터를 groupby하기 전에 timestamp 범위, user_id cardinality, event_name 종류, 필요한 컬럼만 확인합니다. 그 다음 “전체 로드 가능”, “청크 처리 필요”, “샘플로 충분”, “외부 데이터 웨어하우스 필요” 중 하나를 선택합니다.
프로파일링도 짧게 해야 합니다. Python이라면 일부 샘플로 연산 시간을 추정하고, 예상 시간이 90초를 넘으면 청크 처리나 벡터화로 바꿉니다. 모델에게 “실행 시간이 길어질 것 같으면 전체 실행하지 말고 추정 결과와 대안을 보고하라”고 지시하면 불필요한 타임아웃을 줄일 수 있습니다.
에이전트 실행이 중간에 실패했을 때 가장 나쁜 상황은 무엇을 했는지 모르는 것입니다. 셀마다 산출물을 저장하면 복구가 쉬워집니다. 예를 들어 schema.json, profile_summary.json, cleaned_sample.parquet, aggregation_result.csv처럼 중간 결과를 명확한 파일로 남깁니다.
중간 산출물에는 버전과 입력 해시도 포함하는 편이 좋습니다. 같은 파일인지, 같은 필터 조건인지 확인할 수 있어야 합니다. 사용자가 새 파일을 올렸는데 이전 profile_summary를 재사용하면 잘못된 분석이 됩니다. 캐시는 좋지만 검증 없는 캐시는 위험합니다.
실패 메시지도 사용자 친화적으로 바꿔야 합니다. “Cell timed out”만 보여주면 사용자는 다음 행동을 모릅니다. 대신 “전체 데이터 집계가 90초 제한을 초과했습니다. 필요한 컬럼 4개만 선택해 청크 집계로 재시도하거나, 기간을 최근 30일로 줄일 수 있습니다”처럼 대안을 제시해야 합니다.
코드 실행 에이전트는 실수로 민감한 파일을 읽거나 외부 네트워크를 호출하거나 큰 비용을 유발할 수 있습니다. 90초 제한은 시간에 관한 제어일 뿐입니다. 운영 환경에서는 파일 접근 범위, 네트워크 허용 목록, 패키지 설치 정책, 출력 크기 제한을 별도로 둬야 합니다.
특히 사용자가 업로드한 파일을 다루는 서비스에서는 경로 traversal, 압축 폭탄, 과도한 메모리 사용을 막아야 합니다. 에이전트에게 “업로드 디렉터리 밖 파일은 읽지 말라”고 말하는 것만으로는 부족합니다. 샌드박스 권한과 애플리케이션 레벨 검사를 함께 적용해야 합니다.
비용 측면에서는 재시도 정책이 중요합니다. 타임아웃 난 셀을 같은 방식으로 3번 반복하면 비용만 늘고 결과는 같습니다. 재시도는 원인을 바꿀 때만 의미가 있습니다. 예를 들어 샘플 크기를 줄이거나, 컬럼을 제한하거나, 알고리즘을 바꿀 때 재시도합니다.
출처: Anthropic Claude Platform release notes, 2026년 6월 11일 code_execution_20260521 공지.
