Claude Fable 5.2, 새로운 코딩 벤치마크 선두와 함께 Devin Desktop 및 CLI에 도입

Cognition은 Claude Fable 5.2가 Devin Desktop과 Devin CLI에 도입됐으며, FrontierCode 2.0에서 49.1% 점수를 기록했다고 밝혔다. 이번 발표는 Devin의 Claude Fable 5.2에 대해 분명한 가치를 제시한다. 즉, 반드시 최고 추론 설정을 요구하지 않으면서도 더 강력한 코딩 성능을 제공한다는 것이다. 이 벤치마크 선두 기록은 주목할 만하지만, 해당 모델이 두 Devin 인터페이스 내에서 작업을 얼마나 안정적으로 완료할지는 입증하지 않는다.

Anthropic의 11월 9일 출시 자료는 이 핵심 점수를 뒷받침하며, 그 결과가 Xhigh 추론 설정에서 나온 것이라고 명시한다. 이 구분은 최대 성능과 효율적인 일상 운영이 서로 다른 결과를 설명하기 때문에 중요하다. 에이전트를 선택하는 팀은 어떤 설정이 어떤 결과를 냈는지, 그리고 자체 개발 환경이 그 결과를 바꾸는지 알아야 한다.

핵심 비교는 Fable 5.2 대 Fable 5.1이며, Opus 5.5도 유용한 또 다른 기준점이 된다. 즉각적인 압박은 기존 모델 기본값과 이를 정당화해야 하는 팀에 가해진다. 새 모델은 기존 워크플로를 하루아침에 모두 교체해야 할 이유가 아니라, 그러한 선택을 재평가할 이유를 만든다.

Devin의 Claude Fable 5.2가 실제로 바꾸는 것

이번 제품 변경은 기존 개발 워크플로에 새 모델을 도입하며, 벤치마크 주장은 이를 평가할 근거를 제공한다.

제공된 Devin 모델 발표는 Devin Desktop과 Devin CLI를 모두 지원 환경으로 명시한다. Desktop은 그래픽 애플리케이션을 통해 작업하는 개발자를 위한 환경이다. CLI는 명령줄 인터페이스를 뜻하며, 개발자는 터미널 명령어를 통해 상호작용한다. 이러한 접근 지점은 발표가 서로 다른 작업 습관과 관련 있음을 보여주지만, 사용 가능 여부만으로 비교 성능에 관해 말해주지는 않는다.

원본 X 게시물은 검증 과정에서 직접 불러올 수 없었다. 따라서 사용 가능 여부에 관한 주장은 독립적으로 검증된 제품 출시로 제시하기보다 Cognition의 주장으로 귀속돼야 한다. 모든 사용자, 조직 또는 설치 환경이 이미 동일한 접근 권한을 갖는다는 더 광범위한 주장을 뒷받침하는 실사용 계정 테스트도 없다.

이 경계는 실무적 보도에서 중요하다. 모델 사용 가능 여부에는 계정 권한, 애플리케이션 버전, 관리자 설정 또는 출시 시점이 관여할 수 있다. 이는 여기서 문서로 확인된 제한 사항이 아니라 확인해야 할 가능성들이다. 개발자는 발표의 범위와 자체 환경에서 실제로 확인할 수 있는 접근 권한을 구분해야 한다.

이 통합이 공개된 벤치마크가 Devin Desktop 또는 Devin CLI 내부에서 실행됐음을 입증하는 것도 아니다. 모델은 제품에 탑재될 수 있지만, 인용된 평가는 다른 소프트웨어 환경을 사용할 수 있다. 이러한 맥락 간 점수를 이전하려면 주변 도구, 지침, 실행 조건에 관한 근거가 필요하다.

코딩 에이전트는 모델과 파일 접근, 명령 실행, 피드백 반환을 제공하는 소프트웨어를 결합한다. 이 주변 소프트웨어는 흔히 하니스(harness)라고 불린다. 하니스는 모델이 무엇을 검사할 수 있는지, 그리고 그 행동이 어떻게 변경 사항으로 이어지는지를 결정한다. 인터페이스 발표만으로는 전체 시스템이 어떻게 동작하는지 결론낼 수 없다.

낯선 리포지토리 전반에서 회귀 문제를 조사하는 개발자를 생각해 보자. 모델은 관련 파일을 식별하고, 기존 규칙을 이해하며, 동작을 수정하고, 결과를 확인해야 한다. 기반 추론 능력은 이 전 과정에서 중요하다. 제품이 제공하는 지침, 사용 가능한 명령어, 테스트 환경, 컨텍스트도 마찬가지다.

이는 설명을 위한 시나리오이지, 보고된 Fable 5.2 고객 결과가 아니다. 이는 접근 권한과 결과를 별개의 문장으로 다뤄야 하는 이유를 보여준다. 이번 발표는 검토할 가치가 있는 새 선택지를 제시한다. 특정 회귀 문제가 더 빠르게 진단되거나 검토자의 개입 없이 해결된다는 점까지 입증하지는 않는다.

기존 Devin 사용자에게 즉각적인 결과는 평가 후보군의 변화다. 팀은 익숙한 작업과 수용 기준을 유지한 채 새 모델을 현재 모델과 비교할 수 있다. 이 접근법은 출시의 목적을 분명하게 한다. 즉, 업그레이드가 이미 잘 이해하고 있는 작업을 개선하는지 판단하는 것이다.

코딩 벤치마크 선두 기록은 올바른 패치 이상을 측정한다

FrontierCode가 수용 가능한 기여를 중시한다는 점은 결과의 관련성을 높이지만, 채점 규칙은 핵심 백분율이 의미하는 바를 제한한다.

Cognition은 FrontierCode 방법론을 병합 가능성, 즉 리포지토리 관리자가 제안된 기여를 수용할지 여부를 중심으로 설명한다. 그 기준은 정확성뿐 아니라 테스트, 범위, 스타일, 리포지토리 표준까지 포괄한다. FrontierCode 2.0은 132개 작업을 사용하며, 그 외에는 유망해 보이는 해결책이라도 점수를 잃게 할 수 있는 차단 기준을 포함한다.

이 설계는 소프트웨어 작업에서 익숙한 구분을 다룬다. 코드는 보고된 증상을 해결할 수 있지만, 관리자가 전혀 요청하지 않은 동작을 도입할 수도 있다. 새 동작을 충분히 검증하지 않은 채 기존 테스트만 통과할 수도 있다. 병합 여부를 결정하는 검토자는 이러한 부족함을 함께 고려해야 한다.

이런 문제를 중심으로 구성된 벤치마크는 고립된 코드 생성 시연보다 더 많은 정보를 제공한다. 제안된 기여가 해당 리포지토리에 들어갈 수 있는지를 묻는다. 모든 조직의 기대나 운영 제약을 재현할 수 있는 벤치마크는 없지만, 이는 인간 검토자가 내리는 결정에 더 가깝다.

가장 좁지만 유용한 형태로 Fable 5.2 벤치마크를 설명하면 다음과 같다. 보고된 점수는 정의된 평가 절차하의 성능을 요약한다. 이는 모델이 기업의 백로그에서 동일한 비율의 작업을 완료할 것이라는 예측이 아니다. 생성된 모든 코드 중 같은 비율이 정확하다는 뜻도 아니다.

리더보드는 점수와 통과율을 구분한다. 독자는 발표를 반복할 때 이 구분을 유지해야 한다. 가중 집계와 수용 가능한 결과의 개수는 서로 다른 질문에 답한다. 이를 같은 의미로 취급하면 공개된 용어가 뒷받침하는 수준보다 강한 주장이 된다.

한 가지 예시는 차이를 보여준다. 구문 분석 오류를 수정하지만 이전에는 유효했던 입력의 동작을 바꾸는 패치를 상상해 보자. 일부 요구 사항은 점수를 얻을 수 있지만, 필수 호환성 요구 사항은 실패한다. 평가 규칙에 따라 이 실패는 패치가 겉보기에는 유용하더라도 전체 결과를 결정할 수 있다.

이 예시는 가정이지만, 편집상 시사점은 구체적이다. 점수는 무엇이 점수를 얻고 무엇이 수용을 막는지 독자가 이해할 때에만 유익한 정보가 된다. 숫자가 헤드라인이나 구매 검토 슬라이드가 될 때 벤치마크의 명칭은 사라지지 않고 결과와 함께 따라가야 한다.

Cognition은 코딩 제품도 판매하므로, 이 벤치마크는 이해관계가 있는 평가자의 방법론을 나타낸다. 그렇다고 이 작업의 유효성이 사라지는 것은 아니다. 오히려 투명성, 공개된 기준, 재현 가능한 비교의 가치를 더 높인다. 구매자는 벤치마크 소유자를 이해관계 없는 관찰자로 간주하지 않으면서도 그 관련성을 인정할 수 있다.

검증 과정에서 접근 가능한 리더보드 스냅샷은 새로 발표된 Fable 결과를 명확히 확인하지 못했다. Anthropic의 출시는 핵심 수치의 공개를 뒷받침하지만, 이 글은 독립적 재현을 주장하지 않는다. 따라서 구성 및 배포 근거에 따라 실무적 의미가 달라지는 유용한 신호가 남는다.

Fable 5.2 대 Fable 5.1은 기본 모델의 문제를 바꾼다

이번 업그레이드는 어려운 코딩 작업에는 항상 가장 강도 높은 추론 설정이 필요하다는 가정에 도전한다.

코딩 평가 결과에서 Anthropic은 Xhigh 노력 수준의 Fable 5.2가 49.1%를 기록했다고 보고한다. 비교 목록에는 Fable 5.1의 32.4%와 Opus 5.5의 45.5%가 포함된다. 또한 Fable 5.2가 High 노력 수준에서 45.3%를 기록했으며, 이는 인용된 Opus 결과에 가깝다고 회사는 보고한다.

이 수치는 하나의 보편적 성능 수준이 아니라 서로 다른 운영 지점을 설명한다. 추론 노력은 모델이 작업을 얼마나 집중적으로 처리할지를 제어하는 설정이다. 모델 이름만으로는 테스트된 구성을 알 수 없으므로, 팀은 결과를 기록할 때 설정을 보존해야 한다.

Cognition이 제공한 발표는 전작보다 낮은 노력 수준에서 효율성이 더 좋다고도 주장한다. 현재 이용 가능한 보도는 이를 고객의 개발 비용이 측정 가능한 수준으로 감소했다는 사실이 아니라 회사의 주장으로 다루는 것을 뒷받침한다. 통제된 벤치마크 비교에는 소프트웨어를 출시하는 과정에서 발생하는 모든 비용이 포함되지 않는다.

실무적 질문은 설정이 수용되는 작업을 어떻게 바꾸는가다. 검토자가 추론 과정을 재구성하거나 패치를 고쳐야 한다면 짧은 실행 시간의 가치는 제한적이다. 반면 어려운 문제를 깔끔하게 해결한다면 더 긴 실행 시간은 정당화될 수 있다. 어느 결론도 모델의 평판만으로는 도출되지 않는다.

따라서 Fable 5.2 대 Fable 5.1은 운영 선택의 비교가 된다. 기존 사용자는 어떤 작업이 개선되는지, 어떤 작업은 변하지 않는지, 어떤 작업은 퇴보하는지를 파악해야 한다. 광범위한 집계 수치는 이러한 차이를 감출 수 있다. 리포지토리별 근거는 업그레이드가 가장 중요한 작업을 바꾸는지 설명하는 데 도움이 된다.

이번 발표는 현재 기본값의 책임자에게 압박을 가한다. 더 높은 관찰 신뢰성이나 호환성 같은 정당한 이유 없이 이전 구성을 그대로 두는 일은 이제 설명이 필요하다. 이를 변경하는 데에도 근거가 필요하다. 두 결정 모두 출시 기대감이나 전작에 대한 친숙함이 아니라 동일한 수용 기준을 따라야 한다.

Opus 5.5는 단순한 업그레이드 서사를 복잡하게 만든다. Anthropic은 여전히 대부분의 코딩 및 지식 작업에는 Opus로 시작하고, 더 까다로운 작업에는 Fable을 남겨둘 것을 권한다. 이 가이드는 벤치마크 선두 기록을 모든 요청을 최신 모델로 라우팅하라는 지시로 읽어서는 안 된다는 근거가 된다.

이 구분에서는 작업 라우팅 방식이 자연스럽게 따른다. 일상적인 변경과 어려운 조사는 동일한 모델 정책을 공유할 필요가 없다. 중요한 질문은 팀이 언제 상향 전환이 도움이 되는지 알아볼 수 있는가다. 사용자가 언제, 왜 선택해야 하는지 이해할 때에만 추가 모델은 가치를 만든다.

Devin에서 Claude Fable 5.2를 고려하는 개발자에게 가장 강력한 초기 가설은 구체적이다. 일부 까다로운 작업은 새롭게 비교할 가치가 있다. 이는 새로운 보편적 승자를 선언하는 것보다 좁은 결론이다. 실제 패치와 검토 결과를 기준으로 팀이 시험할 수 있으므로 더 유용하기도 하다.

주변 워크플로가 결과를 바꿀 수 있다

모델 역량은 중요하지만, 그 역량이 리포지토리에 도달하는 방식은 개발 시스템이 결정한다.

벤치마크 결과는 특정 구성 내에서 작동하는 모델을 요약한다. 같은 모델을 다른 애플리케이션으로 옮기면 그 조건을 의도적으로 일치시키지 않는 한 주변 조건도 바뀐다. 컨텍스트, 도구 동작, 지침, 실행 제한의 차이는 요청에서 제안된 기여로 이어지는 경로를 바꿀 수 있다.

이는 Devin 통합에서 중요한 구분을 만든다. Fable 5.2와 연관된 결과가 Devin Desktop의 측정 결과가 되는 것은 아니다. Devin CLI에도 같은 주의가 적용된다. 두 제품 내 성능을 입증하려면 문서화된 구성과 비교 가능한 작업을 사용해 해당 제품에서 관찰한 결과가 필요하다.

리포지토리 맥락은 구체적인 사례를 제공합니다. 실패한 함수만 보는 에이전트는 프로젝트의 호환성 요구 사항까지 전달받는 에이전트보다 정보가 적습니다. 추가 맥락은 도움이 될 수 있지만, 관련 없는 자료는 작업을 방해할 수도 있습니다. 제공된 근거의 질은 양만큼이나 중요합니다.

Anthropic의 모델 마이그레이션 요구 사항은 Fable 5.1에서의 호환성 변경 사항을 문서화합니다. 여기에는 이전 추론 콘텐츠와 관련된 제한 및 특정 도구에 영향을 미치는 변경 사항이 포함됩니다. 이러한 요구 사항은 통합과 직접 관련이 있으며, 모든 Devin 사용자가 구현해야 하는 지침으로 설명해서는 안 됩니다.

그럼에도 이 문서는 운영상 중요한 점을 강조합니다. 더 큰 시스템 안에서 모델 식별자를 교체하는 일은 단순히 라벨을 바꾸는 것 이상을 수반할 수 있습니다. 제품 관리자는 지원되는 상호작용을 고려해야 합니다. 특히 다른 모델로 시작한 작업을 이어갈 때, 최종 사용자는 애플리케이션이 이러한 세부 사항을 처리한다는 확신이 필요합니다.

중요한 결과는 전체 기여물입니다. 에이전트가 올바른 파일을 점검했는가? 기대되는 동작을 보존했는가? 해결되지 않은 불확실성을 설명했는가? 적절한 검사를 실행했는가? 이러한 질문은 인상적인 완료 메시지보다 시스템의 동작을 검토자의 결정과 더 직접적으로 연결합니다.

복잡한 조사 과정에서는 맥락의 연속성이 특히 중요해집니다. 이전에 내린 결정은 겉보기에는 단순한 수정이 왜 받아들일 수 없는지 설명할 수 있습니다. 실패한 접근법의 기록은 에이전트가 무엇을 배제했는지 검토자가 이해하는 데 도움이 됩니다. 이 기록이 없다면 개발자와 모델 모두 이미 거부된 경로를 다시 검토할 수 있습니다.

검색 가능한 지식 베이스를 유지하는 팀은 이러한 제약 조건을 기술 문서와 함께 보존할 수 있습니다. 이는 문서의 품질이 모델의 지능을 결정한다는 뜻을 내포하지 않으면서도 이후 조사를 지원합니다. 연결점은 실용적입니다. 신뢰할 수 있는 근거는 사람과 에이전트 모두에게 더 명확한 출발점을 제공합니다.

여기서 제품 경쟁의 여지는 여전히 열려 있습니다. 모델 제공업체는 기반 역량을 개선할 수 있는 반면, 코딩 애플리케이션은 그것을 얼마나 효과적으로 드러내는지를 두고 경쟁합니다. Devin 발표는 사용할 수 있는 조합을 확장합니다. 그 조합이 일상 업무를 개선하는지는 모델만을 내세운 헤드라인에서 추론하기보다 관찰된 기여물을 통해 판단해야 할 문제로 남습니다.

출시 근거가 여전히 입증하지 못하는 것

공개된 결과는 목표가 뚜렷한 평가를 뒷받침하지만, 프로덕션 신뢰성이나 조직 전반의 성과 향상을 입증하지는 않습니다.

이 글은 Devin에서 Claude Fable 5.2를 대상으로 한 독립적인 실사용 테스트에 기반하지 않습니다. 출시 발표, 제공업체의 평가, 관찰된 배포는 서로 다른 질문에 답하기 때문에 이 구분은 중요합니다. 단서 없이 이를 결합하면 그럴듯한 이점을 뒷받침되지 않은 주장으로 바꾸게 됩니다.

현재 이용 가능한 근거는 인간 검토가 줄어든다는 점도 입증하지 않습니다. 더 유능한 모델은 더 나은 패치를 만들 수 있지만, 검토자는 여전히 그 동작을 점검해야 합니다. 검토 노력은 변경의 복잡성, 문서화, 테스트 커버리지, 실패의 결과에 따라 달라집니다. 이러한 요인은 리포지토리마다 다릅니다.

보안에 민감한 작업은 일반화에 또 다른 한계를 만듭니다. 일반적인 유지보수를 잘 처리하는 모델이 모든 민감한 작업에 적합하다는 점까지 입증한 것은 아닙니다. 제품 권한, 데이터 처리, 조직 정책, 요청된 작업의 성격은 여전히 별개의 고려 사항입니다. 코딩 점수만으로 그러한 결정을 대신할 수는 없습니다.

Anthropic의 광범위한 출시에는 11월 9일 발표된 AWS 모델 제공도 포함됩니다. 이는 더 넓은 출시 일정을 뒷받침하고 접근성이 Devin을 넘어 확장된다는 점을 보여 줍니다. 그러나 모델을 제공하는 여러 제품에서 동일한 조건, 제어 방식 또는 동작이 적용된다는 점까지 입증하지는 않습니다.

이 구분은 배포 옵션을 비교하는 엔터프라이즈 구매자에게도 관련이 있습니다. 하나의 모델이 여러 서비스에 등장한다고 해서 그 서비스들이 서로 대체 가능한 것은 아닙니다. 각 애플리케이션은 서로 다른 워크플로와 계약 조건으로 모델을 둘러쌉니다. 구매자는 다른 채널의 결론을 옮겨오기보다 실제로 사용할 서비스를 평가해야 합니다.

공개 반응도 비슷한 주의가 필요합니다. 초기의 호평은 유망한 작업을 식별할 수 있고, 불만은 유용한 실패 사례를 드러낼 수 있습니다. 어느 쪽도 관심을 끈다는 이유만으로 대표성을 갖게 되지는 않습니다. 이 글은 검증되지 않은 소셜 반응을 합의, 광범위한 도입 또는 확정된 신뢰성 기록의 근거로 제시하지 않습니다.

벤치마크 순위가 제품 결정에 얼마나 영향을 미쳐야 하는지도 불확실합니다. 특수한 코드베이스를 유지하는 팀은 좁은 유형의 실패를 가장 중요하게 여길 수 있습니다. 종합 순위 선두 모델도 그 유형에서는 부진할 수 있습니다. 반대로 전체 순위가 더 낮은 모델도 제한된 워크플로에는 충분할 수 있습니다.

따라서 평가 중에는 작업 범주를 보존할 필요가 있습니다. 광범위한 평균은 방향성을 보여 줄 수 있지만, 중요한 회귀를 가릴 수 있습니다. 검토자는 실패가 호환성, 불완전한 테스트, 과도한 범위, 지시 사항 오해 중 어디에 집중되는지 알아야 합니다. 이러한 패턴은 팀이 무엇을 감독해야 하는지 설명합니다.

신중한 해석은 근거가 이점을 시사하는 영역에서 모델을 시험해 보는 데 여전히 긍정적입니다. 신중함은 보고된 개선을 무시하라는 뜻이 아닙니다. 각 결론을 그 근거에 맞춰야 한다는 뜻입니다. 즉, 공개된 벤치마크 성능, 출처가 명시된 제공 여부, 그리고 사용자의 개발 환경 안에서의 동작에 관한 미해결 질문입니다.

업그레이드가 지속될지 보여 줄 세 가지 신호

다음 근거는 공개된 구성, 관찰된 Devin 동작, 지속적인 기여 품질을 연결해야 합니다.

첫 번째 신호는 추론 설정 전반의 결과를 담은, 명확히 업데이트되고 검토 가능한 FrontierCode 항목입니다. 그러면 헤드라인 점수와 낮은 노력 설정에서의 운영 간 관계를 더 쉽게 평가할 수 있습니다. 또한 독자가 최고 결과와 일상적 사용에 적합한 구성을 구분하는 데도 도움이 됩니다.

구성 세부 사항은 순위만큼 중요합니다. 유용한 비교는 모델, 노력 설정, 하니스, 평가 버전을 식별합니다. 이러한 세부 사항이 모호하게 남는다면 정밀한 모델 간 결론에 대한 신뢰는 약해집니다. 반대로 일관되게 제공된다면 효율성 주장은 추가 테스트를 위한 더 탄탄한 기반을 갖게 됩니다.

두 번째 신호는 Devin Desktop 및 Devin CLI 자체에서 나온 재현 가능한 근거입니다. 리포지토리 작업, 기록된 설정, 검토 가능한 패치는 통합 발표를 관찰 가능한 결과와 연결할 수 있습니다. 성공과 실패한 시도를 모두 보여 주는 사례는 눈에 보이는 분모 없이 선별된 시연보다 더 많은 정보를 제공합니다.

개발자들이 비교 가능한 조건에서 더 나은 기여물을 반복적으로 관찰한다면 독립적인 재현은 그 주장을 강화할 것입니다. 결과가 엇갈린다면 실제로 개선되는 작업으로 주장이 좁혀질 것입니다. 보도가 지나치게 광범위한 출시 서사를 유지하는 대신 그 경계를 설명한다면, 그것 역시 유용한 진전입니다.

세 번째 신호는 초기 평가 이후 수용된 작업의 지속적인 개선입니다. 팀은 기여물이 검토와 후속 사용을 거치는 동안에도 계속 유용한지 살펴봐야 합니다. 단순히 생성 속도가 빨라졌다고 해서 그 결과가 입증되지는 않습니다. 반복적인 수정이 필요한 변경은 작업을 줄이지 않고 참여자 간에 이동시킬 수 있습니다.

검토자가 비슷한 작업을 더 적은 실질적 수정으로 수용하고 동작의 저하가 없다면, 이 신호는 업그레이드의 근거를 강화합니다. 반대로 매력적인 초안이 반복해서 후속 수정을 유발한다면 그 근거는 약해집니다. 어느 결과든 모델이 더 똑똑하게 느껴졌다는 고립된 일화보다 더 실행 가능한 정보입니다.

이 세 가지 신호는 이야기를 원래 주장에 고정합니다. Cognition은 또 하나의 모델 선택지를 도입했으며, 공개된 근거는 개발자가 기존 선택을 재평가할 이유를 제공합니다. 아직 해결되지 않은 문제는 그 개선 중 얼마나 많은 부분이 주변 워크플로와 특정 리포지토리의 요구를 통과해 유지되는가입니다.

Devin에서 Claude Fable 5.2를 검토하는 개발자라면, 이미 신뢰하는 구성과 비교하는 범위가 제한된 평가부터 시작하세요. 명확한 수용 기준이 있는 대표 작업을 선택하고, 프롬프트와 결과 패치를 보존하며, 검토자에게 실질적인 수정 사항을 기록하도록 요청하세요. 기존 모델이 어려움을 겪는 작업과 불필요한 복잡성을 드러내는 일반 작업을 함께 포함하세요. 모든 결과에서 모델과 추론 설정을 명확히 표시하세요. 인상적인 시연 하나하나가 끝날 때마다가 아니라, 문서화된 실패가 패턴을 드러낼 때 결정을 다시 검토하세요. 이번 출시는 업그레이드를 조사할 만한 신뢰할 수 있는 이유를 제공하지만, 선택에 필요한 근거는 여러분의 리포지토리가 제공합니다. 이 차이가 팀에 가장 큰 가치를 줄 수 있는 반복 작업은 무엇인가요?