GitHub AI Scan, 적용 범위 확대에도 병합 결정은 개발자에게 맡긴다

1시간 전

10분 분량

GitHub AI Scan은 10월 15일 정식 출시돼 CodeQL 적용 범위를 넘어 보안 검사를 확장했지만, 발견 사항이 병합을 차단할 수는 없도록 했다. 이 기능은 검토를 위해 제출된 제안 변경 사항인 pull request를 대상으로, 선택된 언어와 프레임워크 전반을 검사한다. 개발자가 이미 릴리스 결정을 내리는 위치에 또 하나의 보안 신호가 추가된 셈이다. 동시에 그 신호에 대응할 책임 역시 개발자에게 남는다.

핵심적인 긴장은 탐지 범위 확대와 강제 가능한 보호 사이에 있다. 코드를 실행하지 않고 분석하는 GitHub의 정적 분석 엔진 CodeQL은 계속 보안 워크플로의 일부로 남는다. 새로운 AI 계층은 이를 대체하는 대신 적용 범위를 보완한다. 추가 발견 사항은 검토자가 조사할 또 하나의 근거가 되지만, 자동으로 릴리스 조건이 되지는 않는다.

이 구분은 기존 검사가 실제로 무엇을 보장하는지 판단해야 하는 애플리케이션 개발자, 보안 관리자, 플랫폼 팀에 중요하다. 저장소는 경고의 출처를 하나 더 얻을 수 있지만, 자동 중단 장치를 하나 더 얻는 것은 아니다. 실질적인 질문은 코드가 프로덕션에 도달하기 전에 검토자가 이러한 경고를 정당한 결정으로 전환할 수 있는지다.

GitHub AI Scan, 기존 검사를 넘어 적용 범위 확장

확인된 변화는 CodeQL을 대체하는 것이 아니라 pull request 검사를 확장하는 것이다.

GitHub의 AI Scan 출시 발표는 PHP, Shell/Bash, Terraform 구성, Dockerfile, JavaServer Pages, Blazor 등을 적용 범위 사례로 제시한다. 이 사례들은 애플리케이션 코드, 배포 지침, 인프라 정의를 아우른다. GitHub는 기존 엔진이 현재 다루지 않는 영역을 보완하는 기능으로 이를 제시한다.

프레임워크의 구분에도 주목할 필요가 있다. C#용 Blazor를 언급한다고 해서 GitHub가 C# 언어 전체를 새롭게 발견했다는 뜻은 아니다. 마찬가지로 JavaServer Pages를 언급한다고 해서 이전에는 모든 Java 분석이 없었다는 의미도 아니다. 적용 범위는 검사 대상인 특정 언어, 프레임워크, 코드에 따라 달라진다.

개발자에게 이는 저장소가 “검사된다”는 포괄적 표현만으로는 충분하지 않다는 뜻이다. 프로젝트에는 여러 기술이 포함될 수 있으며, 각각 다른 수준의 검사를 받을 수 있다. 애플리케이션의 주 언어를 이해하는 검사가 템플릿이나 배포 구성에 대해서도 동등한 가시성을 제공하는 것은 아니다.

서버 코드, 컨테이너 정의, 배포 스크립트를 포함하는 예시 애플리케이션 변경을 생각해 보자. 애플리케이션 로직만 검토하면 소프트웨어가 어떻게 시작되는지, 어떤 권한을 받는지에 관한 별도 질문이 남는다. 더 넓은 검사는 팀이 이러한 주변 위험을 발견할 기회를 한 번 더 제공한다.

이 시나리오는 제품의 의도된 역할을 보여줄 뿐, 엔진이 그러한 모든 문제를 잡아낸다는 증거는 아니다. 지원되는 파일 형식은 검사 대상 자격을 뜻한다. 해당 파일 안의 모든 보안 약점에 대한 완전한 적용 범위를 보장하지는 않는다.

발표에 따르면 발견 사항은 기존 검토 인터페이스 안에 표시된다. 개발자는 CodeQL 결과와 구분되는 AI 표시를 보게 된다. 인터페이스에는 설명과 권장 수정안이 포함될 수 있어, 우려 사항을 발견하는 일과 영향을 받은 변경을 논의하는 일 사이의 간격을 줄인다.

이 배치는 검토자가 이미 결정을 내려야 하는 상황에 있기 때문에 중요하다. 별도 보고서는 누군가가 그 내용을 제안된 변경과 연결해야 한다. 관련 코드 옆의 발견 사항은 그 연결을 직접 제공하지만, 여전히 누군가는 정확성을 평가해야 한다.

Visual Studio Magazine은 10월 23일 보도에서 확대된 pull request 검사를 조명했다. 기초가 된 정식 출시 발표는 그보다 이른 10월 15일에 나왔다. 이 날짜들을 구분하면 이후의 보도를 새로운 제품 출시로 제시하는 일을 피할 수 있다.

따라서 즉각적인 변화는 구체적이다. 검사 대상 자격을 갖춘 제안 변경은 또 다른 형태의 보안 검사를 받게 된다. 이는 유용한 추가 가시성을 제공한다. 동시에 누가 새 발견 사항을 검토하고, 검토자들 사이에 이견이 생기면 어떻게 할지라는 별도의 운영 질문을 제기한다.

더 넓어진 탐지가 검토 역량에 부담을 준다

더 많은 발견 사항을 받는 팀에는 어떤 발견 사항에 대응해야 하는지 결정하는 명확한 방법도 필요하다.

애플리케이션 개발자에게 추가 작업은 해석에서 시작된다. 보안 설명은 애플리케이션의 실제 동작과 연결돼야 한다. 검토자는 의심스러운 작업이 신뢰할 수 없는 입력을 처리하는지, 민감한 리소스에 접근하는지, 또는 제한적인 조건에서 실행되는지를 이해해야 한다.

보안 관리자에게 과제는 저장소 전반의 일관성이다. 서로 다른 팀은 유사한 경고에 다르게 대응할 수 있다. 합의된 검토 기준이 없다면, 같은 근본 우려가 한 프로젝트에서는 수정으로 이어지고 다른 프로젝트에서는 기록된 대응 없이 넘어갈 수 있다.

플랫폼 팀에는 적용 범위를 정확하게 설명해야 할 또 다른 책임이 있다. 기능 활성화는 관리 상태다. 적절한 변경이 유용한 검사를 받도록 하는 것은 운영 결과다. 내부 보고서와 보안 평가에서는 이 두 진술을 구분해야 한다.

GitHub는 9월 16일 CodeQL 기본 설정에 대한 기존 의존성을 제거했다. 설정 의존성 변경으로 해당 구성 없이도 AI 검사를 실행할 수 있게 됐다. 다만 코드 스캐닝과 관련 AI 설정은 여전히 활성화해야 했다.

이 변화는 배포 마찰이 보안 기능의 활용 범위에 영향을 미치기 때문에 중요하다. 팀은 다른 방식으로 검사 대상이 되는 변경을 검사하기 위해 무관한 분석 구성을 별도로 설정할 필요가 없어야 한다. 이러한 요구 사항을 분리하면 기능 자체의 조건으로 평가하기가 쉬워진다.

그러나 활성화를 쉽게 했다고 해서 누가 결과를 책임지는지가 정해지는 것은 아니다. 조직은 보안 전문성보다 설정을 더 쉽게 배포할 수 있다. 검토자는 여전히 유용한 경고와 존재하지 않는 문제를 그럴듯하게 설명한 내용을 구별할 충분한 맥락이 필요하다.

공개 저장소에는 특히 중요한 제한 사항이 있다. GitHub의 출시 발표는 변경을 제안하기 위해 쓰이는 별도 저장소 사본인 fork에서 온 pull request를 제외한다. 또한 GitHub의 의존성 업데이트 서비스인 Dependabot이 만든 pull request도 제외한다. 유지 관리자는 검토 범위를 설명할 때 이러한 제외 사항을 고려해야 한다.

여기서의 함의는 오픈 소스 프로젝트가 아무런 이점을 얻지 못한다는 주장보다 좁다. 검사 대상인 변경은 여전히 검사를 받을 수 있다. 하지만 유지 관리자는 저장소 자체가 공개라는 이유만으로 기능을 활성화하면 모든 기여 경로가 포괄된다고 가정해서는 안 된다.

엔터프라이즈 구매자 역시 접근 권한과 사용량을 구분해야 한다. GitHub는 비공개 및 내부 조직 저장소에 GitHub Code Security 또는 GitHub Advanced Security가 필요하다고 설명한다. Copilot 라이선스는 필요하지 않다. 사용 시 Code Security AI Credits가 소모되므로, 접근 권한이 무제한 검사로 이어지는 것은 아니다.

따라서 부담은 여러 책임자에게 동시에 돌아간다. 개발자는 개별 경고를 평가한다. 보안 팀은 검토 기대치를 수립한다. 플랫폼 및 청구 관리자는 배포와 사용량을 이해하기 쉽게 유지한다. 더 넓은 검사는 이러한 책임이 연결될 때에만 의도한 이점을 제공한다.

이는 도입에 관한 측정된 주장이 아니라 출시의 조직적 결과다. 발표는 제품 동작을 확립한다. 특정 팀이 추가 업무를 효과적으로 처리하는지는 그 팀이 입증해야 할 문제로 남는다.

AI Scan vs CodeQL은 상호 보완적 증거에 관한 문제다

유용한 비교는 어떤 엔진이 일반적인 경쟁에서 이기는지가 아니라, 각 발견 사항이 검토자에게 무엇을 알려주는지에 초점을 맞춘다.

AI Scan vs CodeQL은 경쟁하는 대체재 중 하나를 선택하는 문제처럼 들릴 수 있다. GitHub가 제시한 포지셔닝은 다른 해석을 뒷받침한다. 두 엔진은 서로 다른 적용 영역을 다루면서 하나의 공유 워크플로를 통해 발견 사항을 제공한다.

이 구분은 팀이 출시를 평가하는 방식을 바꾼다. 공통 테스트 사례에만 한정한 비교는 추가 계층의 목적을 간과할 위험이 있다. 관련 질문에는 다른 방식으로는 기본 검사를 덜 받는 변경에서 실행 가능한 문제를 식별하는지도 포함된다.

동시에 추가 적용 범위는 기존 증거를 버릴 이유가 아니다. AI 발견 사항을 조사하는 검토자는 여전히 테스트, 확립된 보안 검사, 애플리케이션 설계를 고려해야 한다. 각각은 결정의 서로 다른 부분에 관한 정보를 제공한다.

실무적으로 설명하면 GitHub AI Scan은 검토 증거의 또 다른 출처다. 의심되는 약점으로 개발자의 주의를 이끌고 대응 방안을 제안할 수 있다. 이후 검토자는 그 우려가 실제로 적용되는지, 제안된 대응이 의도한 동작을 보존하는지 판단해야 한다.

분석과 AI 지원의 이러한 결합에는 이미 업계 선례가 있다. Semgrep은 공개한 분류 및 수정 엔지니어링 논의에서 AI 워크플로 안에서 프로젝트 맥락과 정적 분석 결과를 활용하는 방식을 설명한다. 또한 분석 엔진을 통해 생성된 수정안을 검사하는 방식도 설명한다.

이 설명은 성능 순위를 확정하지 않으면서 유용한 비교를 제공한다. Semgrep은 자체 아키텍처와 검증 접근 방식을 설명한다. GitHub는 pull request에 통합된 적용 범위 확장을 설명한다. 어느 설명도 그 자체만으로 고객 코드베이스에서의 우수성을 입증하지는 않는다.

공통된 업계 문제는 의심되는 약점을 신뢰할 수 있는 조치와 연결하는 방법이다. 의심스러운 코드를 찾는 것은 하나의 과제다. 왜 그것이 중요한지 설명하는 것은 또 다른 과제다. 기능을 망가뜨리지 않고 위험을 제거하는 변경을 만드는 일에는 추가 조건이 따른다.

따라서 구매자는 AI 라벨을 완전한 기술 사양으로 취급하지 않아야 한다. 제품은 AI를 탐지, 설명, 우선순위 결정, 또는 수정안 제시에 적용할 수 있다. 비슷한 인터페이스 표현 뒤에는 서로 다른 책임과 검증 방식이 숨겨질 수 있다.

의미 있는 평가는 관련 변경에서 실제 결과를 비교해야 한다. 검토자는 발견 사항이 실제 문제를 식별하는지, 설명이 이해하기 쉬운지, 제안된 대응이 작동하는지를 알아야 한다. 하나의 댓글에 함께 나타나더라도 이들은 별개의 판단이다.

AI Scan vs CodeQL 비교는 탐지와 강제의 구분도 보존해야 한다. 유용한 발견 사항은 자동 병합 조건으로 작동하지 않으면서도 검토자에게 도움이 될 수 있다. 팀이 워크플로에 필요한 사항을 이해한다면 이러한 방식은 유용할 수 있다.

GitHub 통합의 이점은 신호가 나타나는 위치다. 개발자는 제안된 코드를 검토하면서 이를 마주한다. 남는 부담은 증거 판단에 있다. 팀은 발견 사항이 어느 정도의 신뢰를 받을 만한지 결정하고 그에 따른 조치를 문서화해야 한다.

권고성 발견 사항은 릴리스 결정을 사람에게 맡긴다

병합을 차단할 수 없는 경고가 릴리스 결정에 영향을 주려면, 팀은 명시적인 사람의 대응을 마련해야 한다.

GitHub는 적용 범위를 분명히 구분한다. AI 발견 사항은 코드 스캔 검사를 실패시키지 않으며, 리포지토리 ruleset 요구사항을 통해 병합을 차단할 수도 없다. Ruleset은 변경 사항을 수용하기 위한 조건을 정의하는 리포지토리 정책이다.

이 구분은 팀이 발견 사항이 표시되는 것과 릴리스를 자동으로 중단하는 것을 동일시하지 않도록 한다. 경고는 계속 표시될 수 있지만 제안된 변경 사항은 여전히 병합 가능하다. 인간 검토자는 수정을 요청할지, 추가 분석을 요구할지, 남은 위험을 수용할지 결정해야 한다.

권고형 운영은 실질적인 이점을 제공한다. 팀은 의심스러운 결과마다 자동으로 작업이 중단되도록 만들지 않고도 새로운 발견 소스를 살펴볼 수 있다. 이를 통해 신호에 내부 의사결정에서 더 강한 역할을 부여하기 전에 그 유용성을 평가할 여지가 생긴다.

이에 상응하는 위험은 책임 주체가 불분명해지는 것이다. 개발자는 보안 담당자가 대응할 것이라 가정하고, 보안 담당자는 개발자가 검토를 맡는다고 가정하면, 눈에 보이는 경고가 실질적인 평가를 전혀 받지 못할 수 있다. 인터페이스만으로는 이러한 책임 공백을 해결할 수 없다.

GitHub의 AI Scan limitations도 제안된 변경 사항과 과거 코드 범위를 구분한다. 이 기능은 전체 리포지토리 스캔을 지원하지 않는다. 발견 사항은 리포지토리 보안 보기에서 백로그 경고로 표시되지 않고 pull request에 남는다.

백로그 경고는 나중에 수정하기 위해 추적되는 지속적인 이슈다. 작업이 원래 검토 기간보다 길어질 때 이 차이는 중요하다. 즉각적인 논의가 끝난 뒤에도 우려 사항을 조사해야 한다면, 팀에는 의도적인 인계 절차가 필요하다.

문서는 실제로는 문제가 없는 상황을 문제로 식별하는 오탐도 인정한다. 이는 자동 수용이 아니라 조사를 요구해야 하는 이유다. 특정 발견 사항이 틀렸다는 증거나, 기능 전체에 가치가 없다는 증거는 아니다.

수정 제안은 이와 관련된 판단을 요구한다. 수정은 의심스러운 패턴을 제거하면서도 예상된 동작을 바꿀 수 있다. 제안된 패치가 간결해 보이더라도, 검토자는 근본적인 보안 논리와 기능적 결과를 별도로 평가해야 한다.

외부 입력을 허용하는 배포 스크립트에 대한 예시 경고를 생각해 보자. 핵심 질문은 해당 입력이 위험한 형태로 작업에 도달하는지 여부다. 설득력 있는 설명은 단순히 작업을 의심스럽다고 표시하는 데 그치지 않고, 검토자가 그 관계를 추적하도록 도와야 한다.

그다음 제안된 수정도 자체적인 평가가 필요하다. 입력을 적절히 제한하는가? 정상적인 배포 동작은 보존하는가? 주변 프로세스는 계속 작동하는가? 어느 도구가 제안을 생성했는지와 관계없이 이러한 질문은 여전히 중요하다.

릴리스 자료는 나열된 기술 전반에서 제품의 탐지 정확도를 입증하는 독립적인 정면 비교 벤치마크를 제공하지 않는다. 독자는 확인된 제공 여부와 문서화된 동작을, 효과성에 관한 아직 입증되지 않은 주장과 구분해야 한다.

이 검증 공백이 발표의 가치를 없애지는 않는다. 다만 적절한 결론을 규정한다. 팀에는 문서화된 한계를 지닌 더 폭넓은 검사 옵션이 생겼다. 이를 활성화했다고 해서 코드가 안전하다고 선언할 근거는 없다.

더 많은 발견에는 더 나은 결과 측정이 필요하다

발견 건수는 활동을 설명할 뿐, 팀이 얼마나 많은 보안 위험을 제거했는지는 입증하지 않는다.

GitHub는 10월 13일 보안 개요에 AI Scan metrics를 도입했다. 공개 프리뷰에는 생성 및 해결된 발견 사항, 수정률, 리포지토리 추세, autofix 제안 사용 현황이 포함된다. AI Scan과 CodeQL 보고는 서로 다른 탭으로 구분된다.

이러한 측정 항목은 관리자가 배포를 평가하는 출발점을 제공한다. 발견 사항이 어디에서 나타나는지, 개발자가 이에 대응하는지를 파악하는 데 도움이 된다. 또한 모든 논의를 개별적으로 읽지 않고도 프로젝트 간 검토 행동을 비교할 기반을 만든다.

그렇더라도 이 수치를 해석할 때는 주의가 필요하다. 발견 사항 증가는 검사 범위 확대, 적격 변경 사항 증가 또는 다른 코드 구성의 결과일 수 있다. 더 큰 합계만으로는 더 나은 탐지나 악화된 애플리케이션 보안을 독립적으로 입증할 수 없다.

해결 역시 맥락이 필요한 결과다. 효과성을 검토하는 팀은 기록된 상태가 운영상 무엇을 의미하는지 이해해야 한다. 중요한 질문은 대시보드 숫자가 줄었는지가 아니라, 확인된 우려 사항이 적절한 대응을 받았는지다.

Autofix 수용은 개발자 상호작용에 관한 유용한 증거다. 그러나 수용된 변경 사항이 위험을 완전히 해결했다는 충분한 증거는 아니다. 책임 있는 평가는 수용된 제안을 검토자의 판단과 관련 검증에 연결해야 한다.

마찬가지로 낮은 대응률도 판단 전에 조사가 필요하다. 검토자는 부정확한 발견 사항을 거부하고 있을 수 있고, 까다로운 수정을 미루고 있을 수 있으며, 의견을 놓치고 있을 수도 있다. 같은 가시적 지표가 서로 다른 근본 상황을 나타낼 수 있다.

이 지점에서 배포는 즉각적인 발견 사항을 넘어선 지식을 만들어 낼 수 있다. 검토 논의는 애플리케이션 경계, 배포 가정, 책임 소유에 관한 반복적인 오해를 드러낸다. 이러한 결정을 보존하면 이후 검토자가 같은 조사를 반복하지 않도록 도울 수 있다.

그 맥락을 문서화하는 팀에게 searchable knowledge base는 기술 문서와 이전 판단에 대한 접근을 지원할 수 있다. 유용한 자료는 가정과 검증을 포함한 결정의 근거다. 설명 없는 경고 제목만 모아 둔 자료는 도움이 덜 된다.

재무 평가는 이러한 운영 평가와 함께 이루어져야 한다. 관련 비교에는 스캔 사용량과 결론에 도달하기 위해 필요한 인적 작업이 포함된다. 유용한 발견 사항을 생성하는 도구도 검토 역량이 필요하며, 잡음이 많은 배포는 결정을 개선하지 못한 채 주의를 소모할 수 있다.

따라서 유익한 내부 보고서는 제품 활동을 소수의 검토된 사례와 연결해야 한다. 기능이 무엇을 드러냈는지, 검토자가 왜 우려를 수용하거나 거부했는지, 이후 어떤 일이 일어났는지를 보여야 한다. 그래야 결론을 평가할 수 있다.

이 접근 방식은 성공을 과장하는 일도 막는다. 팀은 유용한 탐지를 인정하면서도 범위나 워크플로의 해결되지 않은 약점을 기록할 수 있다. 일반 제공은 제품이 출시되었음을 의미하며, 입증된 가치는 실제 검토에서 일어나는 일에서 나온다.

검증, 범위 변화, 개발자의 후속 조치를 지켜보라

다음으로 유용한 증거는 탐지 품질, 적용 범위의 경계, 그리고 검토자가 발견 사항을 정당한 조치로 전환하는지에 관한 것이다.

가장 먼저 살펴볼 신호는 명확히 설명된 테스트 사례를 활용한 독립적인 검증이다. 평가는 조사한 기술, 포함된 취약점, 검토자가 올바른 결과를 어떻게 확립했는지를 식별해야 한다. 또한 현실적인 애플리케이션 맥락과 고립된 예시를 구분해야 한다.

유용한 탐지와 관리 가능한 검토 노력을 보여 준다면, 그러한 증거는 더 폭넓은 도입의 근거를 강화할 것이다. 지속적인 부정확성이나 중요한 누락 사례의 증거는 영향을 받는 용도에 대한 신뢰를 약화할 것이다. 어느 결론도 지원되는 모든 기술에 자동으로 확대 적용되어서는 안 된다.

유용한 평가는 설득력 있는 시연만 제시하지 말고 실패 사례도 포함해야 한다. 독자는 엔진이 도움이 되는 지점과 불확실성이 남는 지점을 이해할 필요가 있다. 투명한 한계는 어떤 리포지토리에 우선순위를 부여해야 할지 결정하는 데 결과를 더 유용하게 만든다.

두 번째 신호는 적용 범위 또는 강제 적용 경계의 문서화된 변화다. fork 기여, 의존성 업데이트 요청, 전체 리포지토리 분석, 병합 강제 적용은 서로 별개의 기능이다. 한 영역에서의 향후 확장을 모든 영역에 걸친 확장으로 해석해서는 안 된다.

예를 들어 더 폭넓은 기여 범위는 외부 복사본을 통해 검토 트래픽이 유입되는 유지 관리자에게 중요할 것이다. 지속적인 이슈 추적은 또 다른 문제, 즉 원래 검토 후에도 우려 사항을 계속 보이게 하는 문제를 해결한다. 각각의 변화는 워크플로의 서로 다른 부분을 바꾼다.

향후 강제 적용 기능은 특히 면밀한 검토가 필요하다. 발견 사항이 병합을 차단할 수 있게 되면 운영상 결과가 달라진다. 팀에는 명확한 구성 제어와, 그 결정에 부여하는 신뢰도를 뒷받침하는 증거가 필요하다.

세 번째 신호는 초기 배포 이후에도 이어지는 개발자의 후속 조치다. 관리자는 초기 호기심을 넘어 발견 사항이 계속 실질적인 응답을 받는지 이해해야 한다. 가장 강력한 증거는 경고를 확인된 우려 사항, 검토된 변경, 적절한 검증과 연결한다.

팀이 유용한 발견과 완료된 수정을 일관되게 문서화한다면, 추가 검사를 유지해야 한다는 주장은 더 강해질 것이다. 발견 사항이 명확한 책임 주체 없이 쌓인다면, 제품의 가시성은 운영상 영향력을 넘어설 것이다. 대시보드만으로는 이 차이를 판단할 수 없다.

향후 몇 달 동안 이러한 신호는 AI 브랜딩을 중심으로 한 기능 비교보다 더 유용한 그림을 제공할 것이다. GitHub AI Scan은 검사를 확장하는 데 정의된 역할을 맡는다. 실질적인 기여는 그 증거가 검토를 얼마나 잘 견디는지에 달려 있다.

도입을 확대하기 전에 적격 리포지토리의 대표 집합을 선택하고 그에 따른 결정을 검토하라. 어떤 발견 사항이 실제 우려를 식별했는지, 어떤 설명이 도움이 되었는지, 어떤 제안 변경이 테스트를 통과했는지 물어보라. 성공적인 수정과 함께 제외 사항 및 연기된 작업도 기록하라. 증가하는 경고 총계를 축하하기보다 검토자의 노력과 확인된 이슈의 가치를 비교하라. 추가 증거를 평가하는 동안 기존 보안 통제를 유지하라. 그런 다음 검증과 적용 범위가 변화할 때 배포를 다시 검토하라. 여러분의 팀에서는 추가 검사가 더 명확한 보안 결정을 만들어 내는가, 아니면 누군가 책임질 때까지 더 많은 경고만 남기는가?