OpenAI: 저자원 프로그래밍 언어의 코딩 발전에는 동작 보존이 필요하다
OpenAI는 10월 19일 두 가지 코딩 평가를 공개하며, 익숙한 언어를 넘어선 근거를 제시했다. 다만 프로덕션 신뢰성은 여전히 미해결 과제로 남았다. 이제 저자원 프로그래밍 언어의 코딩 발전은 더 까다로운 비교를 수반한다. 작동하는 소프트웨어를 생성하는 것과 기존 시스템의 동작을 보존하는 것의 비교다.
이번 발표는 20개 언어를 아우르는 소프트웨어 평가인 MultiLangBench와 별도의 COBOL 마이그레이션 평가를 다룬다. Common Business-Oriented Language의 약자인 COBOL은 IBM과 AWS의 현대화 도구에서 여전히 핵심 대상이다. 핵심 쟁점은 모델이 그럴듯한 코드를 만든 뒤에 어떤 일이 벌어지는가에 있다.
개발자와 기업 구매자에게 유용한 질문은 이 결과가 다른 현대화 결정을 뒷받침하는지 여부다. 더 나은 모델은 시도할 가치가 있는 작업의 범위를 넓힐 수 있다. 그러나 대체 프로그램이 기존 비즈니스 프로세스를 맡을 자격이 있는지를 판단하려면 추가 근거가 필요하다.
저자원 프로그래밍 언어의 코딩 발전, 서로 다른 두 가지 테스트를 거치다
OpenAI의 저자원 코딩 연구에 따르면, MultiLangBench는 모델이 SQLite 호환 데이터베이스 엔진을 구축하도록 요구한다. SQLite는 애플리케이션이 별도 데이터베이스 서버를 운영하지 않고 사용할 수 있는 임베디드 데이터베이스 엔진이다.
OpenAI는 GPT-6 Astra의 평균 테스트 통과율이 87.4%로, GPT-5.6 Sol의 26.8%와 비교된다고 밝혔다. 별도의 마이그레이션 평가는 COBOL을 다른 언어로 번역할 때 출력 결과가 완전히 일치할 것을 요구한다. GPT-6.1 Sol은 낮은 추론 수준에서 86.6%, 더 높은 설정에서 97.9%의 정확도에 도달한 것으로 전해진다.
이 평가들은 서로 다른 엔지니어링 질문을 다루므로, 그 백분율을 상호 교환 가능한 준비 수준 지표로 취급해서는 안 된다.
데이터베이스 구축 과제는 모델이 명시된 기능을 얼마나 구현할 수 있는지 묻는다. 마이그레이션 과제는 기존 프로그램의 관찰 가능한 동작이 번역 후에도 유지되는지 묻는다. 어느 환경에서의 성공도 중요하지만, 각각이 뒷받침하는 결론은 다르다.
부분적인 데이터베이스 점수가 무엇을 의미하는지 생각해 보자. 구현체는 일부 작업에서 실패하면서도 유용한 작업은 지원할 수 있다. 실질적 의미는 어떤 작업이 계속 지원되지 않는지, 그리고 애플리케이션이 해당 작업을 필요로 하는지에 달려 있다.
마이그레이션 점수는 다른 방식으로 읽어야 한다. 인수 테스트를 충족한 번역 프로그램은 성공 그룹에 포함된다. 하지만 그 분류만으로는 주변 배포가 얼마나 까다로울지는 알 수 없다.
이러한 차이는 구매자가 헤드라인 결과를 해석하는 방식을 바꾼다. 여러 언어에 걸친 높은 평균은 폭넓은 역량을 입증하는 데 도움이 된다. 그러나 모든 언어, 작업 또는 애플리케이션이 동일한 이점을 얻는다는 사실까지 입증하지는 않는다.
마찬가지로 마이그레이션 평가는 포함된 프로그램들에서의 진전을 보여줄 수 있다. 그 결론을 조직의 소프트웨어로 확장하려면 해당 프로그램들이 조직의 자체 시스템과 얼마나 유사한지 이해해야 한다.
따라서 이번 발표는 보편적인 대체 결정보다는 평가를 위한 유용한 출발점을 제공한다. 이전에 익숙하지 않은 언어에서의 성능에 실망했던 팀은 재평가할 이유가 생겼다. 여전히 공개된 과제와 의도한 사용 사례 사이의 명확한 연결고리는 필요하다.
개발자에게 즉각적인 함의는 “AI 코딩이 개선됐다”보다 더 구체적이다. 핵심 질문은 이전에는 비현실적이었던 어떤 작업이 이제 통제된 시험을 받을 가치가 있는가다. 여기에는 모듈 이해, 수정안 제안 또는 후보 번역본 준비가 포함될 수 있다.
각 작업에는 서로 다른 인수 기준이 있다. 설명은 검토자가 수정한 뒤에도 유용할 수 있다. 대체 프로그램은 다른 시스템이 그 출력을 의존하기 전에 더 강한 근거가 필요하다.
이러한 기준을 통해 발표를 읽으면, 결과가 감당할 수 없는 책임을 부여하지 않으면서도 그 중요성을 보존할 수 있다. 개선은 평가된 역량에 관한 것이다. 배포 결정은 특정 시스템에 관한 것이다.
유지보수 팀은 새로운 평가 부담에 직면한다
생성 성능의 향상은 팀이 제안된 변경을 수용하거나 거부하는 데 사용하는 근거로 관심을 옮긴다.
저자원 프로그래밍 언어의 코딩 발전은 엔지니어링 조직이 성공을 더 정확하게 정의하도록 압박한다. 한때는 그럴듯하지 않았던 시연도 내부 테스트의 후보가 된다. 이는 유지보수 담당자, 검토자, 비즈니스 책임자의 업무를 늘린다.
부담은 무엇이 반드시 변하지 않아야 하는지를 결정하는 일에서 시작된다. 프로그램의 소스는 수행하는 작업을 설명하지만, 인수 결정에는 예상 결과도 필요하다. 그 결과가 없으면 검토자는 읽기 좋은 코드를 알아볼 수는 있어도 동등한 동작을 입증할 수는 없다.
이는 실질적인 비대칭을 만든다. 또 하나의 후보 구현을 만드는 일은 논쟁이 되는 비즈니스 규칙을 해결하는 일보다 쉬울 수 있다. 생성된 코드가 모호성을 드러낸다면, 조직이 어떤 해석을 의도하는지 결정할 권한을 가진 사람이 여전히 필요하다.
반복적인 계정 조정이 포함된 가상의 유지보수 프로젝트를 상상해 보자. 대체 프로그램이 이례적인 레코드에서 예상치 못한 결과를 낸다. 엔지니어링 팀은 원래 동작이 정책인지, 우회책인지, 오류인지를 판단해야 한다.
이러한 설명은 서로 다른 결정으로 이어진다. 정책을 보존하면 호환성을 뒷받침한다. 우발적인 결함을 보존하면 마이그레이션 요건은 충족할 수 있지만 별도의 비즈니스 목표에는 걸림돌이 될 수 있다.
따라서 언어 변경에는 명시적인 범위가 있어야 한다. 동작 보존과 비즈니스 재설계는 하나의 프로젝트에서 함께 진행될 수 있지만, 이를 결합하면 이견의 원인을 진단하기가 더 어려워진다. 출력이 다를 때 검토자는 그 차이가 승인된 것인지 알아야 한다.
이번 발표는 조달 팀에도 압박을 준다. 매력적인 모델 결과는 구매 결정의 입력값이지만, 유용한 조달 비교에는 전체 작업 과정이 필요하다.
그 과정에는 자료 준비, 변경 검토, 실패 조사, 그리고 이후 결과물 유지보수가 포함된다. 모델이 수용 가능한 후보를 빠르게 생성하더라도 전문가의 상당한 해석이 필요할 수 있다.
반대로 모델이 전체 마이그레이션을 수행하지 않아도 가치를 제공할 수 있다. 유지보수 담당자가 의존성을 분리하거나 낯선 루틴을 설명하는 데 도움이 된다면, 그 기여는 별도로 평가할 가치가 있다. 더 좁은 활용 사례는 더 명확한 인수 기준을 가질 수 있다.
이는 인력 논의에도 중요하다. 더 나은 생성을 제도적 지식의 즉각적인 대체물로 취급하면, 그 지식이 검증에서 수행하는 역할을 놓치게 된다. 이례적인 예외를 알아보는 사람은 겉보기에 깔끔한 번역이 수용 가능한지 판단할 수 있다.
기술 리더에게 가장 강력한 대응은 수정된 평가 계획이다. 이전에 실패했던 작업을 식별하고, 관찰 가능한 인수 기준을 정의하며, 새 결과를 해당 기준과 비교해야 한다. 공개된 개선은 동기를 제공하고, 내부 근거는 결정을 제공한다.
단기적인 압박은 사용 가능한 테스트나 접근 가능한 기술 기록이 부족한 조직에 집중된다. 더 나은 후보는 이러한 빠진 기반을 더 뚜렷하게 드러낸다. 그러나 이를 자동으로 해결하지는 않는다.
동작 보존은 마이그레이션을 다른 코딩 문제로 만든다
IBM 문서는 COBOL 반올림 규칙에서 구체적인 예를 설명한다. 소수 결과가 사용 가능한 저장 위치를 초과하면, 해당 연산이 반올림을 명시하지 않는 한 절단이 발생한다.
절단은 초과 자릿수를 버린다. 반올림은 보존되는 값을 바꿀 수 있다. 따라서 다른 수치 규칙을 대입한 번역은 문법적으로 유효한 상태에서도 결과를 바꿀 수 있다.
마이그레이션의 정확성은 읽기 쉬운 대체 코드가 감출 수 있는 세부 사항을 포함해, 연산의 의미에 달려 있다.
이 지점에서 코드를 생산하는 것과 동작을 보존하는 것의 차이가 결정적인 의미를 갖는다. 검토자는 경계 사례를 처리하는 방식의 변화를 간과하면서 대체 프로그램의 외형을 선호할 수 있다.
가상의 계정 계산은 특정 고객 사례를 요구하지 않고도 이 문제를 보여준다. 기존 프로그램이 중간 단계에서 소수 정밀도를 버린다고 가정해 보자. 이 조정을 최종 출력 단계로 옮기면 결과가 달라질 수 있다.
대체 프로그램은 수학적으로 타당해 보일 수 있다. 그러나 하위 프로세스가 기대하는 동작에서는 벗어날 수도 있다. 어떤 결과가 바람직한지 결정하려면 언어 지식뿐 아니라 비즈니스 판단도 필요하다.
같은 논리는 산술을 넘어 적용된다. 마이그레이션 평가는 예상 정보가 없거나, 형식이 잘못되었거나, 이례적인 순서로 제공될 때 어떤 일이 벌어지는지 물어야 한다. 적절한 답은 시스템의 계약에 달려 있다.
그 계약은 유효한 비즈니스 응답과 기술적 실패를 구분해야 한다. 빈 결과를 반환하는 것, 거부를 기록하는 것, 작업을 종료하는 것은 서로 다른 동작이다. 대체 프로그램은 명시적 결정 없이 이러한 구분을 하나로 합쳐서는 안 된다.
구매자에게 이는 테스트 설계가 현대화 제안의 일부가 됨을 뜻한다. 번역을 생성하고 그 번역을 위한 테스트를 생성한다고 해서 자동으로 독립적인 근거가 만들어지는 것은 아니다. 두 산출물 모두 같은 잘못된 해석을 반영할 수 있다.
더 강한 평가는 가능한 경우 후보를 외부 참조와 비교한다. 기존 출력, 승인된 비즈니스 사례, 독립적으로 검토된 요구사항이 그러한 참조를 제공할 수 있다. 그러면 이견은 주관적 판단이 아니라 검토 가능한 대상이 된다.
이는 성공적인 언어 번역이 모든 현대화 문제를 해결하지 못하는 이유이기도 하다. 조직은 유지보수성 향상, 다른 배포 옵션 또는 더 명확한 소유권을 원할 수 있다. 동작 일치는 그 의제의 일부만 다룬다.
여기에는 유용한 원칙이 있다. 결과가 인상적인지 논의하기 전에, 그 결과가 무엇을 뜻하는지 확립하라. 통과한 번역은 테스트된 동작에 관한 진술을 뒷받침한다. 성공적인 배포는 더 폭넓은 운영상의 진술을 뒷받침한다.
경제성은 이러한 구분을 유지하는 데 달려 있다. 팀이 의미상 차이를 늦게 발견하면, 이전의 생성 이점은 정보 가치가 떨어진다. 차이를 일찍 식별하고 해결한다면, 더 강력한 모델은 더욱 신뢰할 수 있는 프로젝트를 뒷받침할 수 있다.
따라서 OpenAI COBOL 마이그레이션을 평가하는 개발자에게 핵심 역량은 규율 있는 보존이다. 팀이 대체 프로그램이 유지해야 하는 관찰 가능한 세부 사항을 확립한 뒤에야 관용적인 대체 구현을 만드는 일이 중요해진다.
IBM과 AWS는 주변 워크플로에서 경쟁한다
IBM은 watsonx Code Assistant for Z를 애플리케이션 분석, 코드 설명, 리팩터링, 변환을 중심으로 제시한다. 또한 번역된 Java 서비스와 원래 COBOL 동작을 비교하는 테스트도 설명한다.
AWS는 AWS Transform을 분석, 문서화, 비즈니스 로직 추출, 계획 수립, 코드 변환을 포괄하는 메인프레임 현대화 워크플로로 설명한다. 해당 문서에는 추가 정보나 승인이 필요한 경우 사람이 참여하는 절차가 포함된다.
경쟁 비교의 범위는 모델 역량에서 후보를 수용된 시스템으로 전환하는 데 필요한 작업까지 확장된다.
이러한 접근 방식은 OpenAI 발표를 이해하는 데 유용한 맥락을 제공한다. 범용 모델 평가는 여러 제품을 뒷받침할 수 있는 하나의 역량을 분리해 측정한다. 현대화 플랫폼은 그러한 역량이 조직의 프로세스에 어떻게 들어맞는지를 설명한다.
어느 한 범주만으로는 모든 구매자의 질문에 답할 수 없다. 특화된 워크플로도 구매자의 소프트웨어에서 설득력 있는 결과를 보여줘야 한다. 성능이 뛰어난 범용 모델도 적절한 통합, 검토, 운영 책임 체계가 필요하다.
이 구분은 공정한 비교에 무엇이 포함되어야 하는지를 바꾼다. 모델의 산출물과 플랫폼 전체의 약속을 비교하면 서로 다른 분석 단위를 섞게 된다. 완전한 워크플로를 비교하면 상충 관계가 더 뚜렷해진다.
내부 시험에서는 경쟁하는 접근 방식에 동일한 범위가 정해진 과제와 승인 조건을 부여할 수 있다. 이후 검토자는 결과물, 미해결 질문, 승인된 결과에 도달하는 데 필요한 노력을 살펴볼 수 있다.
그 비교는 원래 과제의 경계를 유지해야 한다. 한 접근 방식이 추가적인 수작업 준비에 의존한다면 그 준비 과정을 기록해야 한다. 다른 방식이 코드와 함께 유용한 문서를 생성한다면, 검토자가 그 문서를 신뢰할 수 있는지도 평가해야 한다.
목표는 각 접근 방식이 어디에서 기여하는지 파악하는 것이다. 어떤 조직은 폭넓은 언어 지원보다 기존 환경과의 통합을 더 중시할 수 있다. 또 다른 조직은 서로 관련 없는 여러 저장소 전반에서 유연한 지원이 필요할 수 있다.
이는 서로 다른 구매 상황이다. 벤치마크가 이를 없애주지는 않는다. 다만 어떤 후보를 더 면밀히 검토할 가치가 있는지 결정할 때 구매자에게 또 하나의 근거를 제공한다.
OpenAI에 전략적 기회는 폭넓은 적용성에 있다. 낯선 언어를 다룰 수 있는 모델은 유지보수와 현대화 프로세스 안의 구성 요소가 될 수 있다. 상업적 의미는 조직이 그 역량을 승인된 작업으로 전환할 수 있는지에 달려 있다.
기존 제공업체가 받는 압박은 부가가치에 대한 증거와 관련된다. 탐색, 검토 지원, 통합, 배포 지원은 관찰 가능한 이점을 만들어야 한다. 구매자에게는 이러한 이점을 중복되는 생성 기능과 구별할 방법이 필요하다.
상호 보완적으로 사용할 여지도 있다. 엔지니어링 조직은 기존 현대화 프로세스 안에서 범용 모델을 평가할 수 있다. 중요한 결과는 결합된 워크플로가 승인된 과제를 개선하는지 여부다.
이러한 틀은 경쟁을 현실에 기반하게 만든다. IBM, AWS, OpenAI는 동일한 조직적 문제, 즉 소프트웨어의 동작에 대한 통제권을 유지하면서 변경하는 문제에 서로 다른 진입점을 제공한다. 구매자는 각 제품이 실제로 맡는 책임을 비교해야 한다.
신뢰할 수 있는 시장의 대응은 더 명확한 과제 경계와 재현 가능한 증거를 제공할 것이다. 자동 현대화에 관한 광범위한 주장은 그러한 비교를 더 어렵게 만든다.
통과한 평가는 프로덕션 관련 질문을 남긴다
SQLite의 자체 데이터베이스 테스트 관행에는 충돌 테스트, 잘못된 입력, 리소스 장애, 회귀 테스트가 포함된다. 회귀 테스트는 변경 사항이 이전에 작동하던 동작을 손상시키는지 확인한다.
이 문서는 데이터베이스 신뢰성에 관한 독립적인 엔지니어링 관점을 제공한다. 일반적인 조건에서의 올바른 답변은 더 큰 테스트 프로그램의 일부다. 비정상적인 운영 조건에도 주의가 필요하다.
정의된 평가를 통과했다는 사실은 그 평가가 명시한 주장을 뒷받침할 뿐이며, 프로덕션 수용에는 평가가 입증하지 못한 조건에 관한 증거가 필요하다.
이는 리소스가 부족한 프로그래밍 언어에서 코딩을 발전시키는 문제를 바라보는 핵심적인 회의적 관점이다. 공개된 결과는 그 자체의 기준으로 검토할 가치가 있다. 그 해석은 이용 가능한 증거가 닿는 지점에서 멈춰야 한다.
데이터베이스는 쿼리에 올바르게 답할 수 있으면서도 중단이나 리소스 압박 상황에서는 추가 조사가 필요할 수 있다. 그러한 조건이 중요한지는 의도된 애플리케이션에 달려 있다. 일회용 프로토타입과 지속적인 운영 기록은 요구 사항이 다르다.
같은 원칙이 번역된 소프트웨어에도 적용된다. 예상 출력과 일치한다고 해서 허용 가능한 성능, 배포 동작, 복구 절차가 독립적으로 입증되는 것은 아니다. 프로젝트가 이러한 특성에 의존한다면 명시적인 평가가 필요하다.
이는 출력 일치가 중요하지 않다는 뜻이 아니다. 일치를 명확히 범위가 정해진 증거 형태로 만든다는 의미다. 유용한 측정치를 대체물 전체에 대한 완전한 진술로 바꾸는 것이 실수다.
평가 설계 역시 점수가 얼마나 많은 것을 보여주는지 좌우한다. 구매자는 과제 선택, 사용 가능한 도구, 종료 조건, 실패한 시도에 대한 처리 방식을 검토해야 한다. 이러한 세부 사항은 공개된 결과가 자신의 제약 조건과 유사한지에 영향을 준다.
반복 실험은 또 다른 질문을 제기한다. 팀이 실제로 마지막에 받는 것은 무엇인가? 최종적으로 통과한 산출물은 유용하다. 그 전에 포기된 후보와 전문가 개입이 얼마나 있었는지를 아는 것도 유용하다.
이런 맥락이 없으면 팀은 결과를 재현하는 데 필요한 작업량을 과소평가할 수 있다. 맥락이 있으면 조직은 검토 역량과 프로젝트 범위에 대해 더 현실적인 판단을 내릴 수 있다.
문서화 문제도 있다. 모델이 비즈니스 규칙을 식별했다면 검토자는 설명과 함께 이를 뒷받침하는 증거를 보존해야 한다. 그렇지 않으면 이후 유지보수 담당자는 근거 없는 또 하나의 설명을 물려받게 된다.
검색 가능한 지식 베이스는 기술 기록에 대한 접근을 지원할 수 있다. 하지만 테스트 실행과 해당 분야 검토는 제안된 해석이 수용 가능한지를 계속 결정한다.
가상의 마이그레이션 프로젝트에서 중요한 기록은 동작을 해당 테스트 및 승인과 연결하는 것이다. 이 연결은 미래의 검토자가 왜 특이한 작업이 재작성 과정에서도 유지되었는지 이해하는 데 도움이 된다.
따라서 남은 불확실성은 전이 가능성과 관련된다. 평가된 역량은 저장소, 비즈니스 규칙, 운영 조건이 바뀌어도 계속 유용한가? 이는 고객 시험을 통해 확인해야 할 실증적 질문이다.
OpenAI의 결과는 그 질문을 다시 제기할 근거가 된다. 그러나 아직 자체 소프트웨어를 테스트하지 않은 조직에 대한 답을 결정하지는 않는다.
재현성, 고객 수용, 워크플로 비교를 주시하라
다음 증거는 더 강해진 평가상 역량이 실제 변경을 수용하는 데 필요한 작업을 줄이는지 보여줘야 한다.
향후 몇 달 동안에는 재현성이 먼저 주목받아야 한다. 독립 팀에는 과제를 이해하고, 자신의 결과가 동일한 결론을 뒷받침하는지 평가할 수 있을 만큼의 정보가 필요하다.
유용한 재현 연구는 모델 설정, 환경, 승인 규칙, 원래 설정에서 벗어난 부분을 식별해야 한다. 그러면 차이를 해석할 수 있다. 이런 세부 정보가 없으면 일치하는 백분율이 서로 다른 실험을 감출 수 있다.
독립적으로 선택한 과제 전반에서 개선이 지속된다면, 재현은 리소스가 부족한 프로그래밍 언어에서 코딩을 발전시켜야 한다는 주장을 강화할 것이다. 결과가 좁거나 일관되지 않다면 구매자가 일반화할 수 있는 범위는 제한된다.
두 번째 신호는 고객 수용에 관한 증거다. 어떤 소프트웨어를 평가했는지, 무엇을 성공으로 간주했는지, 미해결 차이를 어떻게 처리했는지를 설명하는 사례를 찾아야 한다. 세련되게 생성된 예시는 의사결정에 주는 가치가 더 낮다.
강력한 고객 증거는 실험적 후보와 운영상 수용된 변경을 구분해야 한다. 또한 남아 있는 인간의 책임도 설명해야 한다. 이러한 세부 사항은 다른 조직이 경험의 이전 가능성을 판단하는 데 도움이 된다.
범위가 정해진 유지보수 결과가 광범위한 전환 주장보다 더 많은 정보를 제공할 수 있다. 검증된 수정 사례는 구체적인 결과를 입증한다. 현대화가 쉬워졌다는 주장은 추가 설명이 필요하다.
OpenAI COBOL 마이그레이션에서 특히 유용한 증거는 생성된 대체물과 독립적으로 승인된 동작을 연결하는 것이다. 이는 평가와 실무적 수용 사이의 연결을 강화할 것이다.
세 번째 신호는 완전한 워크플로의 비교다. 구매자는 범용 모델과 특화된 현대화 도구가 비교 가능한 제약 조건 아래 동등한 과제를 받는지 지켜봐야 한다. 비교에는 검토와 재작업이 포함되어야 한다.
IBM의 COBOL 현대화 워크플로와 AWS의 메인프레임 전환 워크플로는 이러한 평가가 고려해야 할 더 넓은 범위를 보여준다. 공개된 설명은 독립적인 성능 순위가 아니라 여전히 공급업체의 주장이다.
더 강력한 모델이 수용 과정을 거쳐 지속적으로 노력을 줄인다면 워크플로 비교는 발표의 실질적 의미를 강화할 것이다. 검토와 수정이 대부분을 차지한다면 당장의 이점은 더 제한적일 것이다.
어느 결과도 근본적인 역량을 무의미하게 만들지는 않는다. 다만 그 역량이 어디에 속하는지를 분명히 해줄 것이다. 개발자에게 필요한 것은 또 하나의 차별성 없는 리더보드보다 이런 명확성이다.
엔지니어링 리더에게 유용한 다음 단계는 권위 있는 예상 결과가 있는 범위가 정해진 과제를 선택하는 것이다. 승인 논의에는 대표적인 실패 사례와 비정상적인 입력을 포함하라. 제안된 동작 변경은 언어 번역과 분리하라. 모델이 도움이 되는 지점, 전문가가 개입하는 지점, 승인 근거가 되는 증거를 기록하라. 그런 다음 전체 노력을 기존 프로세스와 비교하라. 리소스가 부족한 프로그래밍 언어에서 코딩을 발전시키는 일은 조직이 개선된 생성 능력을 검증된 결과와 연결할 수 있을 때 의미를 갖는다. 시험을 확대하기 전에 유지보수 담당자와 비즈니스 소유자에게 같은 질문을 던져라. 이 대체물에 의존할 의향이 생기려면 어떤 증거가 필요한가?
