Black Duck AI Agent, 사람의 승인 아래 취약점 수정 기능 추가

Black Duck는 2026년 10월 27일, 개발자가 변경 사항 승인 책임을 계속 지는 가운데 취약점을 분류하고 수정안을 준비하는 AI 에이전트를 출시했다. Signal Agentic Fix라는 이름의 Black Duck AI agent는 보안 탐지 결과를 제안된 수정과 연결한다. 핵심적인 상충 관계는 명확하다. 자동화는 변경 사항을 더 빠르게 준비할 수 있지만, 그 변경 사항을 소프트웨어에 적용할지는 여전히 사람이 결정한다.

이는 문제를 식별하는 보안팀과 이를 해결할 시간을 찾는 개발팀 사이의 인수인계에 압박을 가한다. 누군가 그 중요성을 이해하고, 수정안을 평가하며, 안전하게 배포할 수 있을 때 탐지 결과는 유용해진다. 패치 생성은 이 작업의 일부를 해결하지만, 정확성, 호환성, 책임 소재에 관한 질문은 남는다.

GitHub는 2024년 8월 CodeQL 알림용 Copilot Autofix를 정식 출시하며 앞선 기준점을 마련했다. 이제 Black Duck도 자체 분석 도구를 이 범주에 추가한다. 엔터프라이즈 구매자에게 의미 있는 비교는 검증된 수정 조치가 얼마나 많이 프로덕션에 도달하는지, 그 과정에 얼마나 많은 검토가 필요한지, 자동화가 잘못된 결과를 낼 경우 어떤 일이 일어나는지에 관한 것이다.

Black Duck AI Agent가 추가하는 기능

회사의 에이전틱 개선 발표에 따르면 Signal Agentic Fix는 스캔, 분류, 수정, 검증, 제출의 워크플로를 따른다. 이는 소스 코드의 결함을 검사하는 정적 애플리케이션 보안 테스트와 타사 구성 요소를 검사하는 소프트웨어 구성 분석을 결합한다.

Black Duck는 AI가 탐지 결과를 평가하고 수정 생성에 도움을 준다고 설명한다. 이후 시스템은 사람의 승인을 위해 제출하기 전에 변경 사항을 다시 스캔한다. 고객이 정의한 기능 테스트와 컴플라이언스 검사는 이러한 검증을 보완할 수 있다.

이번에 발표된 변경 사항은 탐지를 검토 가능한 수정안과 연결해, 알림과 승인된 변경 사이의 작업을 더 많이 하나의 워크플로에 담는다.

이 구분은 알림과 패치에 서로 다른 판단이 필요하기 때문에 중요하다. 알림은 어떤 사안이 주의를 기울일 가치가 있는지를 묻는다. 제안된 패치는 특정 조치가 애플리케이션을 손상하지 않고 문제를 해결하는지를 묻는다.

따라서 보안팀은 평가할 또 하나의 산출물을 얻게 된다. 원래 탐지 결과와 함께 제안된 변경이 왜 이를 해결하는지 설명하는 근거가 필요하다. 개발자에게는 변경 사항이 주변 코드와 어떻게 상호작용하는지 평가할 충분한 맥락이 필요하다.

유용한 개선 제안은 이러한 관계를 드러내야 한다. 검토자는 무엇이 탐지 결과를 촉발했는지, 무엇이 바뀌었는지, 이후 어떤 검사가 실행됐는지를 이해해야 한다. 그렇지 않으면 자동화는 아무도 그 영향을 확인하기 전에 완료된 것처럼 보이는 작업을 만들어낼 위험이 있다.

사람의 승인 요건은 제품의 운영 경계도 규정한다. 변경을 준비한다고 해서 이를 병합할 권한이 부여되는 것은 아니다. 이 분리는 기존의 책임 체계를 유지하면서 팀이 조사와 구현을 자동화할 여지를 제공한다.

하지만 승인 버튼만으로는 검토 품질을 충분히 보장하기 어렵다. 개발자는 신중한 검토 후 변경을 승인할 수도 있고, 익숙하지 않은 설명을 훑어본 뒤 승인할 수도 있다. 두 행동 모두 승인 기록을 남기지만, 서로 다른 수준의 확신을 나타낸다.

이는 검토 가능함과 실제 검토됨 사이에 실질적인 차이를 만든다. 검토 가능하다는 것은 시스템이 이해할 수 있는 제안과 뒷받침 근거를 제공한다는 뜻이다. 검토됐다는 것은 자격을 갖춘 사람이 해당 자료를 살펴보고 결과에 대한 책임을 수용했다는 뜻이다.

구매자에게 이 구분은 처음부터 기대치를 형성해야 한다. 제품 발표는 작업을 진전시키는 방법을 설명한다. 모든 생성된 변경이 수용할 만한 가치가 있거나 똑같이 적은 사람의 주의만 필요하다는 점까지 입증하지는 않는다.

알림을 해결하는 것과 수정을 배포하는 것 사이에도 차이가 있다. 영향을 받는 애플리케이션이 계속 실행되는 동안 제안된 변경은 브랜치에 남아 있을 수 있다. 보안 결과는 릴리스 일정과 배포를 포함해 승인 후 어떤 일이 벌어지는지에 달려 있다.

따라서 이번 출시는 보안 자동화가 달성하려는 범위를 넓힌다. 그 가치는 관련성 있는 탐지 결과에서 안전한 프로덕션 변경까지의 전체 경로를 이 시도들이 단축하는지에 달려 있다.

이 경로는 발표의 의미를 부여한다. Black Duck는 사람의 의사결정이 전 과정에 내재된 엔지니어링 워크플로로서 개선을 다루고 있다. 그 결과로 생기는 작업량은 생성된 코드만큼이나 면밀한 검토를 받을 만하다.

얼리 액세스가 당면한 구매 결정을 규정한다

Black Duck의 얼리 액세스 세부 정보는 Coverity 사용자를 위한 Claude Code 플러그인을 명시한다. 회사는 Coverity, Polaris, Black Duck SCA 전반에서 추가 코딩 에이전트 및 파이프라인 통합이 향후 제공될 예정이라고 설명한다.

당면한 평가는 특정 얼리 액세스 통합에 관한 것이며, 더 광범위한 배포 모델은 제공 약속으로 남아 있다.

이는 보안 아키텍처가 서로 다른 저장소, 개발 환경, 릴리스 프로세스에 걸쳐 있는 조직에 중요하다. 개발자의 코딩 세션에서 제공되는 기능이 중앙화된 배포 파이프라인 전반에서 동등한 동작을 자동으로 보장하는 것은 아니다.

각 환경은 서로 다른 요구를 만든다. 대화형으로 작업하는 개발자는 질문에 답하고, 예상치 못한 변경을 살펴보며, 에이전트를 다른 방향으로 유도할 수 있다. 백그라운드 워크플로에는 의도를 명확히 해줄 사람이 없을 때의 상황을 위한 명확한 규칙이 필요하다.

현재 릴리스는 누가 제품을 의미 있게 평가할 수 있는지도 결정한다. 지원되는 조합의 기존 사용자는 해당 제품이 자신의 업무에 어떻게 맞는지 살펴볼 수 있다. 다른 잠재 구매자는 발표된 방향과 현재 테스트할 수 있는 기능을 구분해야 한다.

이는 기술적 문제인 동시에 조달 문제다. 구매자는 어떤 기능이 즉각적인 도입을 지원하고, 어떤 기능이 향후 제공에 의존하는지 알아야 한다. 그렇지 않으면 성공적인 시연이 제공 가능한 통합 범위를 넘어서는 기대를 만들 수 있다.

그 압박은 먼저 애플리케이션 보안 리더에게 가해진다. 이들은 생성된 수정안이 미해결 위험을 줄이는지, 아니면 단지 또 다른 대기열을 만드는지 결정해야 한다. 이들의 평가는 보안 우선순위를 영향을 받는 애플리케이션을 이해하는 개발자와 연결해야 한다.

개발 관리자 역시 역량에 관한 관련된 질문에 직면한다. 개발자에게 이미 검토 시간이 부족하다면, 추가 제안을 보내는 것만으로 병목이 자동으로 해소되지는 않는다. 제안은 소비하는 주의를 정당화할 만큼 조사 노력을 줄여야 한다.

저장소 소유자도 범위에 관한 결정을 떠안는다. 범위가 좁게 정의된 수정은 검토하기 간단할 수 있다. 공유 인터페이스나 핵심 동작을 건드리는 변경은 원래 취약점이 국지적으로 보이더라도 더 폭넓은 지식을 요구한다.

따라서 Black Duck 취약점 개선은 제품 평가와 함께 조직적 시험대가 된다. 팀은 제안된 수정의 소유자가 누구인지, 누가 이를 거부할 수 있는지, 해결되지 않은 불확실성이 언제 에스컬레이션을 요구하는지에 합의해야 한다.

고객 대상 서비스를 담당하는 가상의 팀을 생각해 보자. 보안 엔지니어는 우선순위를 식별하고, 애플리케이션 개발자는 주변 비즈니스 규칙을 이해한다. 생성된 패치는 두 사람이 조사를 처음부터 다시 구성하지 않고도 동일한 근거를 평가할 수 있을 때만 도움이 된다.

이 예시는 보고된 고객 배포 사례가 아니라 예시다. 이는 인수인계가 중요한 이유를 보여준다. 보안 위험을 평가하는 사람과 애플리케이션 동작을 평가하는 사람은 서로 다른 정보를 필요로 할 수 있다.

같은 구분은 배포 권한에도 적용된다. 누군가는 수정안을 충분히 이해해 코드를 승인할 수 있지만, 릴리스 일정을 잡을 권한은 없을 수 있다. 자동화는 이러한 책임이 같은 사람에게 속한다고 가정할 수 없다.

엔터프라이즈 구매자에게 얼리 액세스의 경계는 유용한 제약을 제공한다. 이는 식별 가능한 참여자가 있는 구체적인 워크플로의 평가를 촉진한다. 조직 전체의 처리량에 관한 광범위한 약속은 그 워크플로의 근거를 뒤따라야 한다.

단기적인 결정은 이 통합이 지원되는 업무를 안전하게 완료하기 쉽게 만드는지 여부다. 추가 환경으로의 확장은 권한, 검토 품질, 운영 적합성에 관한 자체적인 근거를 제시해야 한다.

더 빠른 패치 생성이 검토 방정식을 바꾼다

Black Duck AI agent의 핵심 긴장은 준비 속도와 승인 역량의 관계에 있다. 검토자가 이를 효율적이고 자신 있게 평가할 수 있을 때 더 많은 제안된 수정은 가치를 창출한다.

가장 강력한 결과는 수용된 수정당 사람의 작업이 줄어들고, 애플리케이션 동작이 올바르게 유지된다는 근거가 함께 제시되는 것이다.

코드 생성은 구현 단계를 다룬다. 이를 검토하려면 의도, 맥락, 결과에 관한 판단이 필요하다. 제안된 변경에 자동화된 설명이 함께 제공된다고 해서 이러한 판단이 사라지는 것은 아니다.

이는 엔지니어링 노력이 축적될 수 있는 지점을 바꾼다. 패치 준비가 쉬워지면 검토가 제한 단계가 될 수 있다. 그러면 조직에는 단순히 더 많은 후보 변경 공급이 아니라 더 나은 근거와 우선순위 설정이 필요하다.

재스캔은 보안 탐지 결과에 관한 근거를 제공한다. 기능 테스트는 예상된 동작에 관한 근거를 제공한다. 모든 검사는 자신이 살피는 범위 안에서 작동하므로, 어느 쪽도 제한 없는 보장을 제공하지는 않는다.

예를 들어 알려진 취약점이 있는 구성 요소 버전을 제거하는 가상의 종속성 업그레이드를 상상해 보자. 애플리케이션은 교체 버전에서도 계속 올바르게 동작해야 한다. 종속성 탐지 결과가 사라지더라도 구성 가정과 통합 동작은 중요할 수 있다.

소스 코드 수정도 비슷한 질문을 제기한다. 제안된 입력 검사는 위험한 사례를 막는 동시에 정당한 요청까지 거부할 수 있다. 보안 의도와 제품 요구 사항은 모두 변경을 거쳐서도 유지돼야 한다.

이 사례들은 검증이 면밀한 주의를 받을 가치가 있는 이유를 설명한다. 검토자는 무엇이 실행됐고, 무엇이 통과했으며, 무엇이 테스트되지 않은 채 남았는지 알아야 한다. 광범위한 성공 표시는 이러한 상태들 사이의 의미 있는 차이를 감출 수 있다.

에이전트의 설명 역시 이의를 제기할 수 있는 상태로 남아 있어야 한다. 명확한 문장은 검토자가 패치를 이해하는 데 도움이 될 수 있지만, 유창함이 정확성을 입증하지는 않는다. 뒷받침 근거는 설명이 얼마나 자신 있게 읽히는지와 독립적으로 성립해야 한다.

여기서 GitHub와의 비교가 유용하다. Copilot Autofix 제공 발표는 보안 알림 수정 제안이 이미 프로덕션 환경에서의 이력을 보유하고 있음을 보여준다. Black Duck는 기존 개발자 지원 범주에 진입한다.

이러한 이력은 기본적인 코드 생성을 차별화의 제한적인 근거로 만든다. 대신 구매자는 시스템이 작업을 선택하는 방식, 근거를 제시하는 방식, 실패한 시도를 처리하는 방식, 검토자의 결정을 지원하는 방식을 비교할 수 있다.

근본적인 경쟁 질문은 수정안을 수용하는 전체 경험에 관한 것이다. 도구는 합리적인 변경을 생성할 수 있지만, 누군가가 이를 신뢰하기 전에 광범위한 조사가 필요할 수 있다. 다른 도구는 더 적은 사례를 지원하더라도, 그 사례들을 더 쉽게 해결하도록 도울 수 있다.

이러한 가능성은 대표적인 애플리케이션에서 측정해야 합니다. 단순한 결함을 중심으로 한 시연만으로는 동일한 프로세스가 복잡한 서비스를 어떻게 처리하는지 입증할 수 없습니다. 주변의 엔지니어링 작업이 실제 결과의 상당 부분을 좌우합니다.

비교에는 거부된 변경도 포함해야 합니다. 거부된 제안은 수정으로 이어지지 않은 채 조사 시간을 소모할 수 있습니다. 검토자가 이를 거부하는 이유를 이해하면 유용한 신중함과 반복되는 제품 한계를 구분하는 데 도움이 됩니다.

Black Duck 취약점 수정 기능은 평가가 승인과 배포까지 변경 사항을 추적할 때 더 쉽게 판단할 수 있습니다. 생성된 제안 수만 세어서는 핵심 질문에 답할 수 없습니다.

개발자에게 유용한 약속은 관련 근거를 바탕으로 더 나은 출발점을 제공하는 것입니다. 보안 책임자에게 유용한 결과는 해결되지 않은 노출을 줄이는 것입니다. 성공적인 워크플로는 승인을 형식적인 절차로 취급하지 않으면서 이 두 결과를 연결합니다.

재스캔이 남기는 중요한 질문

이 글에서 검토한 출시 자료는 독립적으로 측정된 수정 정확도, 고객 승인율 또는 프로덕션 노출 감소를 입증하지 않습니다. 이러한 결과는 여기서 아직 검증되지 않았습니다.

사람의 승인과 반복 스캔은 안전장치이지만, 어느 것도 승인된 모든 패치가 애플리케이션의 의도된 동작을 유지한다는 점을 입증하지는 않습니다.

GitHub의 security AI limitations는 관련 비교 사례를 제공합니다. 해당 문서는 컨텍스트 한계와 프로그램의 의미를 바꿀 수 있는 변경 가능성을 명시합니다. 또한 개발자에게 제안을 검토하도록 안내합니다.

이러한 공개 내용은 GitHub의 구현과 관련이 있습니다. 이는 Black Duck 제품의 결함을 입증하지 않습니다. 다만 구매자가 이 범주를 일률적으로 신뢰할 수 있다고 간주하기보다, 생성된 수정의 기반이 되는 가정을 검토해야 하는 이유를 보여 줍니다.

한 가지 미해결 질문은 어떤 발견 사항을 먼저 주의 깊게 다뤄야 하는지 결정하는 과정인 트리아지입니다. 수정 시스템은 우선순위가 잘못된 문제에 대해 뛰어난 코드를 생성할 수 있습니다. 실질적인 가치는 선택된 발견 사항이 의미 있는 노출을 나타내는지에 부분적으로 달려 있습니다.

도달 가능성은 애플리케이션이 영향을 받은 코드를 실행할 수 있는지를 뜻합니다. 악용 가능성은 공격자가 해당 약점을 공격으로 전환할 수 있는지와 관련됩니다. 둘 다 취약한 코드 줄을 넘어서는 세부 사항에 좌우될 수 있습니다.

따라서 우선순위 결정에는 근거가 필요합니다. 검토자는 시스템이 어떤 문제를 긴급하거나 덜 관련 있다고 판단한 이유를 이해해야 합니다. 추론이 없는 결론은 팀이 쉽게 검토할 수 없는 판단에 의존하게 만듭니다.

또 다른 질문은 통과한 재스캔의 범위입니다. 깨끗한 결과는 검사된 코드에 대해 실행된 점검을 다룹니다. 스캐너가 한 번도 평가하지 않은 요구사항까지 애플리케이션이 충족한다는 점을 입증하지는 않습니다.

이는 보안과 기능이 상호작용할 때 중요합니다. 의도된 요구사항이 적절한 접근 제한인 상황에서, 수정이 접근 자체를 완전히 제거할 수 있습니다. 이 차이를 구분하려면 애플리케이션의 권한 부여 규칙과 정당한 사용자에 대한 지식이 필요합니다.

테스트에도 비슷한 경계가 있습니다. 통과한 테스트는 해당 테스트가 다루는 동작에 대한 신뢰를 뒷받침합니다. 그러나 누구도 정의하지 않은 시나리오에 필요한 요구사항을 제공하거나 정확성을 확립할 수는 없습니다.

권한에 관한 질문도 있습니다. 수정을 준비하는 에이전트에는 할당된 업무에 적합한 접근 권한이 필요합니다. 구매자는 에이전트가 어떤 리소스를 읽거나 수정할 수 있는지, 그리고 그 활동의 책임 추적이 어떻게 유지되는지 이해해야 합니다.

이는 출시 버전에 대한 의혹이 아니라 평가의 문제입니다. 보안 도구는 신뢰받는 위치에 놓이므로 운영 범위가 중요합니다. 조직은 자동화 활동을 확대하기 전에 그 위치를 이해해야 합니다.

검토 기록 역시 주의가 필요합니다. 나중의 조사자는 패치가 왜 승인됐는지, 어떤 점검이 이를 뒷받침했는지, 누가 승인했는지를 재구성해야 할 수 있습니다. 고립된 성공 메시지는 도움이 제한적입니다.

엔지니어링 컨텍스트는 이러한 재구성을 뒷받침할 수 있습니다. searchable knowledge base는 검토자의 선택을 설명하는 설계 결정과 알려진 제약을 보존할 수 있습니다. 이는 패치 자체를 검증하는 것이 아니라 코드 검토를 보완합니다.

검토 피로도 역시 우려 사항입니다. 적격 인력이 검토할 수 있는 속도보다 제안이 더 빠르게 도착하면 승인은 반복적인 행정 업무가 될 수 있습니다. 그러면 안전장치는 형식적으로 존재하지만 실제 효과는 약화됩니다.

이 위험이 자동화를 거부해야 한다는 뜻은 아닙니다. 제안량을 조직의 근거 평가 역량에 맞춰야 한다는 뜻입니다. 검토 부담이 역효과를 낼 때 팀은 자동화 작업을 중단하거나 범위를 좁히거나 방향을 바꿀 수 있어야 합니다.

따라서 회의적인 입장은 구체적입니다. Black Duck은 평가할 가치가 있는 안전장치를 설명했지만, 공개적으로 검증된 운영 결과는 아직 불완전합니다. 구매자는 통제 장치의 존재와 그 통제 장치가 얼마나 잘 작동하는지에 관한 근거를 구분해야 합니다.

출시 이후 주목할 점

Signal Agentic Fix의 다음 단계는 제공과 운영 근거입니다. 앞으로 몇 달 동안 세 가지 신호가 발표된 워크플로가 지속적인 엔지니어링 가치로 이어지는지 판단하는 데 도움이 될 것입니다.

가장 유용한 근거는 생성된 패치에서 멈추지 않고, 사용 가능한 통합, 검토자 노력, 프로덕션 결과를 연결할 것입니다.

첫째, Black Duck이 발표한 추가 통합을 주시해야 합니다. 이러한 통합이 제공되면 접근 방식이 초기 코딩 에이전트 환경을 넘어 확장된다는 근거가 강화됩니다. 지연된다면 출시의 실질적 범위는 좁아질 것입니다.

가용성만으로 모든 질문에 답할 수는 없습니다. 각 통합은 무엇을 실행할 수 있는지, 어떤 점검을 수행하는지, 사람이 변경을 어떻게 승인하는지 명확히 설명해야 합니다. 구매자는 실제로 운영하는 환경에서 이러한 세부 사항을 검토해야 합니다.

파이프라인 지원은 상호작용 모델을 바꾸기 때문에 특히 주목할 필요가 있습니다. 백그라운드 실행은 즉시 대응할 수 있는 개발자 없이도 불확실성을 처리해야 합니다. 따라서 실패 처리와 명확한 제출 근거가 평가의 핵심이 됩니다.

둘째, 승인된 수정과 검토자 노력에 관한 고객 근거를 주시해야 합니다. 승인은 이를 달성하기 위해 필요한 작업에 대한 정보와 함께 제시될 때 유용합니다. 광범위한 재작성이 필요한 제안 패치는 쉽게 이해할 수 있는 수정과는 다른 결과를 의미합니다.

검토 시간에는 조사, 설명 검증, 수동 수정이 포함되어야 합니다. 그렇지 않으면 평가는 패치 작성에서 검증으로 이전된 작업을 놓칠 수 있습니다. 전체 부담이 개발자의 여유 역량이 늘어나는지를 결정합니다.

거부된 제안도 해석이 필요합니다. 거부는 기술적 오류, 부적절한 접근 방식 또는 문제를 의도적으로 미루는 결정을 반영할 수 있습니다. 이러한 이유를 구분하면 고객 결과의 정보 가치가 더 높아집니다.

서로 다른 애플리케이션 유형 전반의 근거는 일반적 유용성에 대한 신뢰를 높일 수 있습니다. 신중하게 선별된 사례에만 국한된 근거는 더 제한적인 결론을 뒷받침합니다. 범위가 명시적으로 유지된다면 둘 다 유용할 수 있습니다.

셋째, 승인된 변경이 프로덕션에 도달한 뒤 어떤 일이 벌어지는지 주시해야 합니다. 회귀, 되돌리기, 반복적으로 발견되는 문제는 워크플로가 지속 가능한 수정을 제공하는지 드러내는 데 도움이 됩니다. 성공적인 승인 단계는 중간 결과일 뿐입니다.

프로덕션 후속 과정은 에이전트의 통제 밖에 있는 지연도 드러냅니다. 검증된 패치라도 출시 일정이나 다른 팀의 승인을 기다릴 수 있습니다. 명시된 이점이 노출 감소와 관련된다면 이러한 지연은 중요합니다.

Black Duck이 이러한 단계 전반에 걸쳐 투명하게 보고한다면 자사 주장을 더 쉽게 평가할 수 있게 됩니다. 또한 구매자가 자동화가 기여하는 지점과 조직적 변화가 여전히 필요한 지점을 파악하는 데 도움이 될 것입니다.

경쟁사에게도 비교 가능한 근거는 시장 논의의 질을 높일 수 있습니다. 기능 명칭은 얼마나 많은 작업이 검토를 통과하는지에 관해 거의 알려주지 않습니다. 완료된 수정에 공동으로 주목하면 구매자는 비교를 위한 더 유용한 기준을 갖게 됩니다.

더 넓은 의미는 구매자가 보안 자동화에 기대해야 할 것이 변화한다는 점입니다. 탐지는 여전히 필요하지만, 수정에 관한 주장은 그 이후에 이어지는 모든 것에 대한 면밀한 검토를 요구합니다. 여기에는 관련 인력, 근거, 출시 결정이 포함됩니다.

Black Duck AI agent는 팀이 조사할 수 있는 구체적인 워크플로를 제공합니다. 초기 액세스 범위는 명확한 출발 경계도 제공합니다. 조직은 더 폭넓은 제공에 관한 근거를 기다리면서 지원되는 이 경험을 평가할 수 있습니다.

시험 도입을 고려하는 팀은 대표적인 애플리케이션과 팀이 이미 영향을 이해하고 있는 미해결 발견 사항으로 시작해야 합니다. 제안된 수정을 검토, 테스트, 승인, 배포까지 추적하십시오. 거부된 시도와 수동 수정을 포함해 그 과정에서 투입된 사람의 노력을 기록하십시오. 그 결과를 팀이 그렇지 않았다면 수행했을 것으로 예상한 작업과 비교하십시오. 다른 엔지니어가 나중에 이를 이해할 수 있도록 승인 근거를 보존하십시오. 핵심 질문은 Black Duck AI agent가 팀이 더 적은 총 노력으로 안전한 수정을 제공하도록 돕는지입니다. 변경 사항이 사람들이 사용하는 애플리케이션에 이르기까지 전체 과정을 추적하는 근거를 요청하십시오.