이 기사의 요점

「작동한다」, 「통과한다」, 「요약된다」는 신뢰의 재료는 될 수 있다.

하지만 그것만으로 안전성, 타당성, 사회적 올바름, 제도적 책임까지 증명된 것은 아니다.

이 기사에서는 그러한 치환을 「검증 범위의 팽창 (Verification Scope Inflation)」이라 부르며, 책임 경로 공학 (Responsibility Pathway Engineering)의 관점에서 정리한다.

서론: 신뢰 대신 삼고 있는 것

모르는 리포지토리 (Repository)를 사용할 때, 우리는 의외로 많은 것을 「신뢰의 대용품」으로 삼고 있다.

• README가 잘 정리되어 있다.
• Star가 붙어 있다.
• Fork도 되어 있다.
• GitHub Actions가 Green(성공) 상태이다.
• 샘플을 실행하면 제대로 작동한다.

이 정도 갖춰져 있으면 나도 모르게 생각하게 된다.

'아마 괜찮겠지.'

그렇게 생각하여 소스 코드를 충분히 읽지 않고 fork하고, 의존 관계 (Dependency)를 추가하며, 스크립트를 실행한다.

그리고 나중에 깨닫는 것이 있다.

나는 사실, 무엇을 확인하고 있었던 것일까?

이 기사에서 다루고자 하는 것은 바로 이 작은 치환이다.

이것은 모르는 리포지토리를 사용할 때만의 이야기가 아니다.

CI의 Green, 형식화된 코드, AI에 의한 요약, 검색 결과에서의 표시. 그러한 시그널을 우리는 어느샌가 「신뢰의 증명」으로 읽어버리곤 한다.

나아가 그 시그널이 난해한 전문 용어나 독자적인 조어, 권위적인 어휘와 결합하면, 실제 검증 범위보다 더 큰 신뢰가 생긴 것처럼 보이기도 한다.

이 기사에서는 그 구조를 의심하기 위한 읽기 방식을 정리하고자 한다.

확인한 것과, 신뢰한 것

예를 들어, 다음과 같은 것들은 분명히 보고 있다.

• README를 읽었다.
• Star나 Fork를 보았다.
• CI가 Green임을 확인했다.
• 샘플이 작동하는 것을 보았다.

여기까지는 확실히 확인된 것이다.

하지만 그것만으로는 「소스 전체를 읽었다」는 것이 되지 않는다.

의존 관계, 권한, 외부 통신, secrets의 취급, 워크플로우 (Workflow) 설계, 운영 환경에서의 영향까지 확인한 것은 아니다.

즉, 우리는 종종 확인한 범위보다 조금 더 넓은 범위를 신뢰해 버린다.

이 「조금 넓은」 범위가 쌓이면 보안 문제로도, 주장이나 사상의 권위화 문제로도 이어지게 된다.

이 기사에서 다루는 것

이 기사는 GitHub, CI, Lean4, 형식화 (Formalization), AI 요약, 검색 요약을 부정하는 것이 아니다.

오히려 그것들은 올바르게 사용한다면 투명성, 재현성, 설명 가능성, 검증 가능성을 높여준다.

다만, 모든 시그널에는 범위가 있다.

여기서 보고 싶은 것은 그 범위를 넘어 「안전해 보인다」, 「옳아 보인다」, 「외부에서 인정받고 있는 것 같다」라고 읽어버리는 구조다.

초점은 기술 도입이나 정보 독해의 상황에서 발생하는 신뢰 시그널의 과잉 해석에 있다.

이 기사에서 말하는 「검증 범위의 팽창」이란

검증 범위의 팽창이란, 어떤 체크, 동작, 공개, 요약, 형식화, 인용, 도메인 게재가 본래 뒷받침할 수 있는 범위를 넘어, 더 큰 안전성·신뢰성·타당성·정당성을 뒷받침하는 것처럼 보이는 것을 말한다.

짧게 말하면 다음과 같다.

확인된 범위
≠
신뢰해도 좋은 범위

「작동한다」, 「통과한다」, 「요약된다」는 신뢰의 재료는 될 수 있다.

하지만 그것만으로 신뢰가 증명된 것은 아니다.

이러한 치환은 보안 문제로서도, AI 시대의 정보 유통 문제로서도, 그리고 주장이나 사상의 권위화 문제로서도 나타난다.

「작동한다」는 안전의 증명이 아니다

먼저 「작동한다」부터 살펴보고 싶다.

코드가 작동하는 것은 중요하다.

샘플이 작동한다. 테스트용 스크립트가 통과한다. 내 환경에서 기대한 출력이 나온다.

그것은 분명 의미 있는 확인이다.

다만, 작동하는 것과 안전한 것은 같지 않다.

스크립트가 정상적으로 실행되더라도 의도하지 않은 통신, 과도한 권한 요구, 위험한 의존 관계, 환경 변수의 취급, 로그에 대한 비밀 정보 출력, 외부 서비스로의 전송, 후속 처리에서의 부작용 등이 없다고 단정할 수 없다.

동작 확인은 확인한 범위 내에서의 동작 확인일 뿐이다.

그것만으로는 코드 전체, 의존 관계, 실행 환경, 운영 조건, 조직 도입 시의 책임 분계까지 보증한 것이 되지 않는다.

여기서 혼동하기 쉬운 것은 다음 두 가지다.

내 환경에서는 작동했다
≠
조직에서 안전하게 실행할 수 있다

작동하는 것을 가볍게 보려는 것이 아니다.

오히려 작동한 것을 올바르게 다루고 싶다.

그것이 무엇을 나타내고, 무엇을 아직 나타내지 못하고 있는지를 구분할 필요가 있다.

「통과한다」는 신뢰의 증명이 아니다

다음으로 「통과한다」를 살펴보자.

CI가 Green인 것 또한 물론 중요하다.

GitHub Actions 등의 CI는 정의된 체크(check)를 통과했음을 보여준다.

예를 들어, 다음과 같은 사항들은 확인할 수 있을지도 모른다.

• 테스트가 통과했다
• 타입 체크 (Type check)가 통과했다
• 린트 (Lint)가 통과했다
• 빌드 (Build)가 통과했다
• 특정 스크립트가 성공했다
• 특정 형식화 파일이 컴파일되었다

이것들은 개발, 유지보수, 재현성을 위해 매우 중요하다.

하지만, CI Green이 의미하는 것은 어디까지나 "정의된 체크를 통과했다"는 지점까지다.

그것만으로는 다음과 같은 사항들을 확인한 것이 되지 않는다.

• 악의적인 코드가 포함되어 있지 않다
• 의존 관계 (Dependency)가 안전하다
• 운영 환경에서 실행해도 좋다
• 조직으로서 도입해도 좋다
• 법적 책임이 정리되었다
• 안전성이 증명되었다
• 사회적 주장이 옳다
• 사상이 타당하다
• 제3자 리뷰 (Peer review)를 받았다

코드 Green은 코드나 체크의 Green이다.

신뢰 그 자체의 Green이 아니다.

GitHub Actions의 Green을 안전성과 혼동하지 말 것

여기서 한 번, 구체적인 예시로 GitHub Actions를 살펴보고자 한다.

GitHub Actions에 대해서는 실제 침해 사례나 초기 접근 기법을 정리한 참고 기사도 있다.

이 기사에서는 GitHub Actions가 침해되었을 경우, runner 상에서 임의의 명령어가 실행되어 워크플로 (Workflow) 중에 존재하는 인증 정보나 secrets가 탈취될 가능성이 있다는 점, 또한 릴리스 처리나 패키지 공개가 악용될 수 있다는 점이 정리되어 있다.

또한 신뢰할 수 없는 Pull Request의 checkout, 외부 컨텍스트의 직접 전개, 검증되지 않은 artifact의 사용, 외부 Action의 태그 지정, AI 에이전트에 대한 과도한 권한 부여 등, GitHub Actions의 "통과하는" 메커니즘 자체가 공격 경로가 될 수 있음도 보여준다.

여기서 중요한 것은 "GitHub Actions는 위험하다"라고 단정 짓는 것이 아니다.

CI가 통과하는 것은 중요하다.

하지만 CI가 통과했다는 것만으로는 워크플로 설계, 권한, 의존 관계, 외부 입력, artifact, Action 참조, AI 에이전트의 권한까지 안전하다고 확인한 것이 아니다.

여기서도 필요한 것은 "무엇이 통과했는가"와 "무엇은 확인되지 않았는가"를 분리하는 것이다.

이것은 단순히 GitHub Actions의 안전 대책에 관한 이야기만이 아니다.

"통과했다"라는 사실을 어디까지 신뢰의 근거로 읽어도 좋은가, 라는 문제이기도 하다.

형식화나 수리 증명에도 증명 범위가 있다

같은 점이 형식화나 수리 증명에도 적용된다.

Lean4 등의 형식 증명 계열이나 수리 모델, 사양 기술 (Specification), 검증용 스크립트는 매우 강력하다.

정의된 명제, 전제, 타입, 증명 대상에 대해 일반적인 문장보다 엄격하게 다룰 수 있다.

그렇기에 형식화되어 있다는 것에는 큰 가치가 있다.

다만, 여기에도 범위가 있다.

형식화된 명제가 증명되었다 하더라도, 그 명제 설정 자체가 현실을 적절하게 잘라내고 있는지, 사회적 주장으로서 타당한지, 제도 도입을 해도 좋은지, 구현 전체가 안전한지까지는 확인한 것이 아니다.

형식 증명이 강력하기에, 다음의 선은 구분해 두고 싶다.

어떤 명제가 형식적으로 증명되었다
≠
그 명제의 사회적 의미까지 증명되었다

형식 증명은 증명 대상을 명확히 한다.

하지만 그 증명 대상을 어떻게 현실과 연결할지는 인간, 조직, 제도, 전문가, 이용자, 영향을 받는 당사자의 책임 경로 (Responsibility Pathway)로 되돌려야 한다.

보충: 나 자신도 Lean4를 사용하고 있다

나는 나의 RPE (Responsibility Pathway Engineering) 리포지토리에서도 Lean4를 채택하고 있다.

그렇기에 Lean4나 형식화를 부정하고 싶은 것이 아니다.

오히려 형식화가 무엇을 증명하고 무엇을 증명하지 않는지를 상당히 신중하게 바라보게 되었다.

다른 공개 리포지토리에서 Lean4나 형식화가 사용되고 있는 경우에도 "무엇이 형식화되어 있는가", "README의 주장과 Lean 코드의 증명 대상이 일치하는가", "CI Green은 어디까지를 나타내는가"를 확인하게 되었다.

그러한 확인을 거듭하는 과정에서, 이 글에서 언급한 "검증 범위의 팽창"이라는 문제의식은 상당히 명확해졌다.

「요약된다」는 승인의 증명이 아니다

마지막으로 「요약된다」를 살펴보고자 한다.

생성 AI나 검색 엔진의 서머리 (Summary)는 편리하다.

코드 설명, README의 요약, 라이브러리 비교, 설계 사상 설명, 기사 군의 정리 등에도 사용할 수 있다.

하지만 AI가 요약했다는 것이, AI가 그 내용을 검증하고 승인하며 타당성을 보증했다는 뜻은 아니다.

검색 결과에 나오는 것도, AI Overview나 검색 요약(Search Summary)에 정리되는 것도 마찬가지다.

그것은 크롤링(Crawling)되어 관련 텍스트로 처리되고 표시되었다는 정보일 뿐이다.

그러나 그것만으로 외부 피어 리뷰(Peer Review)를 거쳤다거나, 전문가의 확인을 마쳤다거나, 사회적으로 타당하다거나, 도입해도 안전하다고 확인된 것은 아니다.

요약된 것과 검증된 것은 분리해서 생각해야 한다.

AI에 의해 요약됨
≠
AI에 의해 타당성이 검증됨

동일한 구조는 주장이나 사상을 읽을 때도 발생한다

지금까지의 이야기는 보안이나 소프트웨어 도입에 관한 이야기로 읽힐 수 있다.

하지만 동일한 구조는 주장이나 사상을 읽는 방식에서도 나타난다.

예를 들어, 어떤 주장, 조어(造語), 사상, 설계 개념이 있다고 가정하자.

이를 생성형 AI(Generative AI)가 긍정적으로 정리한다. 기사 플랫폼에 올라온다. 검색 결과에 나타난다. AI가 요약한다. GitHub에 문서나 코드가 놓인다. CI(Continuous Integration)를 통과한다. 형식화(Formalization)나 수리 모델과 같은 표현이 곁들여진다. 기업 도메인이나 공적 발언에 대한 인용과 연결된다.

그러면 본질적인 제3자 검증이나 피어 리뷰(Peer Review)가 들어오지 않았음에도, 외부에서 보기에는 "검증된 것처럼 보이는" 경우가 있다.

발신자 자신도 그것을 외부로부터의 승인으로 받아들이기 쉽다.

• AI가 긍정했다
• 검색에 나왔다
• 요약되었다
• GitHub에 있다
• CI가 통과되었다
• 형식화되어 있다
• 회사 사이트에 있다
• 공적 발언과 연결되어 있다

이러한 시그널(Signal)이 겹치면, "그러니까 옳은 것이 아닐까"라는 해석이 생기기 쉽다.

하지만 공개, 요약, 크롤링, 형식화, CI 통과, 기업 도메인 게재, 인용 연결은 각각 서로 다른 의미를 가진다.

이것들을 동일한 종류의 증명으로 취급할 수는 없다.

여기서 특히 경계해야 할 것은, 이러한 시그널을 쌓아 올림으로써 외부에서 검증된 것과 같은 인상을 만드는 비즈니스 모델적인 구조다.

GitHub에 있다. CI가 통과되었다. 형식화되어 있다. AI가 긍정적으로 요약한다. 기업 도메인에 놓여 있다. 공적 발언과 연결되어 있다.

이것들은 하나하나 떼어놓고 보면 반드시 문제가 되는 것은 아니다.

하지만 그것들이 조합되면 독자에게는 "어딘가에서 검증되었겠지"라는 인상을 주기 쉽다.

난해한 수리 용어, 독자적인 조어, 형식화 파일, GitHub Actions 등의 Green 표시를 조합하여, 폭넓은 대상에게 효과가 있는 것처럼 만능성을 내세우는 소구(Appeal)에도 주의가 필요하다.

정말로 보아야 할 것은 분위기의 강함이 아니다.

무엇이 증명되었는가. 어떤 명제가 통과되었는가. 누가 읽었는가. 검증 범위는 어디까지인가.

그 부분이 공개되지 않은 채 "증명됨" 혹은 "검증됨"처럼 읽히게 만드는 구조는 상당히 신중하게 다루어야 한다.

특히 기존의 개념이나 인접한 용어가 있는 경우, 차이점(Diff)을 명시하지 않은 채 비슷한 용어를 계속 사용하면 검색 결과나 AI 요약 속에서 뒤섞이게 된다.

그 결과 독자는 어디까지가 기존 개념이고 어디서부터가 새로운 주장인지, 누가 그 타당성을 책임지고 있는지 추적하기 어려워진다.

이는 단순한 표현상의 문제가 아니다.

신뢰 시그널을 재료로 삼은, 책임 경로(Responsibility Path)의 불투명화로 보아야 한다.

더욱 경계해야 할 것은, 세계적인 권위나 제도에 관련된 어휘를 사용하면서 기술 검증의 내용은 모호하고, 제3자 기관이나 전문가에 의한 피어 리뷰(Peer Review) 경로도 보이지 않는 경우다.

기존의 학문, 제도, 전문가, 권위를 폭넓게 부정하는 듯한 발신을 반복하는 한편, 구체적인 증명 결과, 전제, 정의, 검증 대상, 한계 조건을 전문가가 추적할 수 있는 형태로 공개하지 않는다.

그럼에도 불구하고 이미 증명된 것처럼 말한다.

이러한 구조를 마주했을 때는 일단 멈춰 서는 것이 좋다.

무엇이 증명되었는가.

누가 검증했는가.

어느 범위까지 유효한가.

그리고 부자연스러운 면책 조항이 강력한 소구 근처에 놓여 있지는 않은가.

그 부분을 살펴볼 필요가 있다.

검증 범위의 팽창을 방지하기 위한 읽기 방식

검증 범위의 팽창을 방지하기 위해 시그널을 부정할 필요는 없다.

오히려 시그널을 정확하게 읽을 필요가 있다.

관측된 시그널	본래 나타낼 수 있는 것	오독하기 쉬운 것
코드가 작동함	특정 조건에서 실행됨	안전하게 사용할 수 있음
...

이 표에서 보고 싶은 것은 시그널을 의심하는 것이 아니다.

그 시그널이 어디까지를 뒷받침하고 있는지를 보는 것이다.

문제는 이러한 시그널 그 자체가 아니다.

문제는 시그널이 나타내는 범위를 넘어 독자, 이용자, 조직, AI, 검색 엔진, 그리고 발신자 자신이 의미를 과도하게 읽어버리는 데 있다.

책임 경로 공학(Responsibility Path Engineering) 관점에서의 체크 항목

이때부터는 내가 진행하고 있는 책임 경로 공학 (Responsibility Pathway Engineering)의 관점에서 정리한다.

어려운 이론을 끌어들이고 싶은 것이 아니다.

'신뢰해도 되는가'를 생각하기 전에, 책임 있는 판단으로 돌아오는 경로를 가시화하고 싶다.

신뢰하기 전에, 다음의 점들을 구분해 둔다.

Claim: 무엇을 주장하고 있는가 -
Evidence: 무엇을 근거로 하고 있는가 -
Evidence Type: 그 근거는 어떤 종류의 근거인가 -
Source Scope: 그 근거는 어디까지 뒷받침되는가 -
Validity Owner: 그 타당성을 누가 판단하는가 -
Stop Condition: 어디에서 해석이나 도입을 멈춰야 하는가 -
Human Return Point: 어디에서 인간이나 조직으로 판단을 돌려보내는가

이것은 추상론이 아니다.

예를 들어, GitHub상의 리포지토리 (Repository)를 이용한다면 다음과 같이 물을 수 있다.

• 무엇을 도입하려고 하는가
• 무엇을 확인했는가
• README만 읽었는가, 소스 코드 (Source Code)도 읽었는가
• 의존 관계 (Dependency)는 확인했는가
• CI는 무엇을 체크하고 있는가
• 무엇은 미확인 상태인가
• 누가 도입 판단 권한을 갖는가
• 어떤 조건이라면 실행을 멈출 것인가
• 문제가 발생했을 때, 누가 복귀하여 수정하는가

주장이나 사상을 읽을 때도 마찬가지로 생각할 수 있다.

• 무엇이 주장되고 있는가
• 무엇이 근거인가
• AI 요약인가, 1차 자료인가, 제3자 검토 (Peer Review)인가
• GitHub상의 코드나 형식화 (Formalization)는 어디까지를 뒷받침하는가
• 어디서부터는 별도의 검증이 필요한가
• 타당성을 누가 판단하는가
• 독자는 어디에서 판단을 보류해야 하는가

이 7가지 점이 모호해지면, 책임은 존재하는 것처럼 보여도 실제로는 AI, 검색, GitHub, CI, 수리 (Mathematics), 형식 증명 (Formal Proof), 기사군, 기업 도메인, 인용처 사이에 분산되어 버린다.

책임 경로는 AI나 수리에 책임을 넘기기 위한 것이 아니다.

오히려 인간, 조직, 제도, 독자, 영향을 받는 사람에게 책임을 돌려주기 위한 설계다.

비주장 (Non-claim)은 회피가 아니라, 독자를 위한 난간이다

공개 문서에서는 비주장을 적는 경우가 있다.

예를 들어 다음과 같은 것들이다.

• 이것은 인증이 아니다
• 이것은 법적 판단이 아니다
• 이것은 안전성 증명이 아니다
• 이것은 운영 환경 도입 승인이 아니다
• 이것은 제3자 검토를 거친 것이 아니다
• 이것은 AI로의 최종 책임 이전이 아니다

이것들은 단순한 면책 조항으로 놓일 경우 회피하는 것처럼 보일 수 있다.

하지만 본래의 비주장은 독자가 검증 범위를 오독하지 않도록 돕는 난간 (Handrail) 역할을 한다.

중요한 것은 비주장을 문장 끝에 모아서 두는 것이 아니라, 강한 주장 근처에 두는 것이다.

어떤 주장이 어느 범위까지 뒷받침되는가.

어디서부터는 별도의 검증, 별도의 책임자, 별도의 제도적 판단이 필요한가.

독자가 그것을 따라갈 수 있도록 해두고 싶다.

FAQ

GitHub Actions가 Green이라면 안심해도 되나요?

안심할 수 있는 요소는 된다.

하지만 안전성이나 도입 타당성의 증명은 아니다.

CI Green은 정의된 체크를 통과했음을 나타낸다. 워크플로우 (Workflow) 설계, 권한, 의존 관계, 외부 입력, 아티팩트 (Artifact), 외부 Action, secrets, AI 에이전트의 권한까지 안전한지는 별도로 확인해야 한다.

Lean4나 형식 증명이 있다면 주장은 증명된 것인가요?

증명되었다고 말할 수 있는 것은 정의된 전제와 명제의 범위까지다.

그 명제 설정이 현실을 적절하게 포착하고 있는지, 사회적 주장으로서 타당한지, 제도를 도입해도 되는지는 형식 증명만으로는 결정되지 않는다.

AI나 검색 엔진에 의해 요약되었다면 외부에서 인정받은 것이 되나요?

그렇지 않다.

요약은 기존 텍스트를 처리하여 표시한 결과일 뿐, 타당성에 대한 검토나 승인이 아니다.

그렇다면 GitHub, CI, Lean4, AI 요약을 신용해서는 안 되나요?

신용해서는 안 된다는 이야기가 아니다.

각각이 무엇을 나타내고, 무엇을 나타내지 않는지를 구분해서 읽어야 한다.

검증 범위의 팽창을 막으려면 무엇을 봐야 하나요?

그 시그널이 무엇을 나타내고, 무엇을 나타내지 않는지를 본다.

코드, CI, 형식화, AI 요약, 검색 결과, 기업 도메인, 공적 발언의 인용은 각각 근거의 종류가 다르다.

이를 동일한 종류의 증명으로 취급하지 않는 것이 중요하다.

검증된 것처럼 보이는 비즈니스 모델을 어떻게 읽어야 하나요?

시그널을 쌓아 올리고 있을 뿐인지, 실제로 검증 책임의 소재가 명시되어 있는지를 본다.

GitHub, CI, 형식화 (Formalization), AI 요약, 기업 도메인, 공적 발언과의 연결이 있더라도, 각각의 근거 범위와 책임자가 명시되어 있지 않다면 검증되었다고 읽어서는 안 된다.

특히 세계적인 권위나 제도와 관련된 어휘를 사용하면서도, 심사 경로 (Peer review path), 증명 대상, 전제, 한계 조건, 구체적인 검증 결과를 추적할 수 없는 경우에는 강력한 소구점(Appeal) 근처에 어떤 면책 조항이 배치되어 있는지도 확인할 필요가 있다.

마치며

「작동하는」 것은 중요하다.

「통과하는」 것도 중요하다.

「요약되는」 것 또한 현대의 정보 환경에서는 큰 의미를 갖는다.

하지만 그것들은 신뢰의 증명이 아니다.

GitHub에 있다는 것, CI가 Green(통과) 상태라는 것, 형식화되어 있다는 것, AI 요약에 등장한다는 것, 검색에서 강하게 표시된다는 것, 기업 도메인에 놓여 있다는 것.

이것들에는 각각의 의미가 있다.

그러나 그것만으로 안전성, 타당성, 사회적 올바름, 제도적 책임까지 증명된 것은 아니다.

필요한 것은 기술적 시그널이나 검색 시그널을 부정하는 것이 아니다.

각각의 시그널이 무엇을 나타내고, 무엇을 나타내지 않는지를 구분하는 것이다.

책임 경로 공학 (Responsibility Path Engineering)은 이를 위한 난간(Handrail)이 된다.

작동했다.

통과했다.

요약되었다.

그렇다면 무엇이 확인되었고, 무엇이 미확인 상태인가.

그 질문을 인간과 조직의 측면으로 되돌리는 것부터 시작하고 싶다.

오노 아키히사 (Akihisa Ono)

• note : https://note.com/dantarg
• LinkedIn : https://www.linkedin.com/in/akihisaono

【주기】

저 개인은 기업에 소속되어 있으나, AI 연구에 대해서는 완전히 개인 활동이므로, 또한 발언 내용으로 인해 소속처에 폐를 끼치지 않도록 실제 소속처는 미공개로 하고 있습니다.

Discussion