AI 지원 작업에서의 정직함에 대한 몇 가지 생각

이 글은 인간과 AI 비서가 함께 작성했습니다. 인간이 주제, 관찰 내용, 예시 및 최종 편집 결정을 제공했으며, AI는 분석, 구조, 문구 작성 및 편집을 도왔습니다.

익숙한 상황

온라인에 무언가를 게시합니다.

글을 쓰는 동안 AI 비서를 사용했습니다. 어쩌면 연구에 도움이 되었을 수도 있고, 단락을 다시 썼을 수도 있습니다. 혹은 두 분이 함께 텍스트를 발전시켰을 수도 있습니다.

그래서 공개합니다. 아니면 공개하지 않을 수도 있습니다.

어떤 플랫폼에서는 그 공개 행위 자체가 결과를 초래합니다.

두 접근 방식 모두 단순히 검열의 풍자일 뿐만 아니라, 플랫폼들은 실제로 기계가 생성한 텍스트의 홍수에 직면해 있습니다. 흥미로운 질문은 그들이 걱정할 권리가 있느냐가 아닙니다. 그들은 정말로 걱정하고 있습니다. 흥미로운 질문은 그들의 도구가 정보가 어디서 왔는지 알려줄 수 있느냐입니다.

그 질문은 처음 보이는 것보다 훨씬 어렵다는 것이 밝혀집니다.

첫 번째 아이러니: 공개를 억제하는 것은 은폐를 장려할 수 있다

만약 어떤 플랫폼이 AI 지원 자료는 식별되거나, 제한되거나, 다르게 처리되어야 한다고 말한다고 가정해 봅시다.

의도는 완벽하게 합리적일 수 있습니다. 독자들은 자신이 무엇을 보고 있는지 알아야 하고, 플랫폼은 대량의 자동 생성된 자료를 처리할 방법을 필요로 합니다.

하지만 불편한 부작용이 있습니다.

공개 자체가 불이익이 된다면, 일부 작가들에게 합리적인 대응은 AI 사용을 멈추는 것이 아닐 수 있습니다.

단지 그것을 공개하는 것을 멈추는 것일 수 있습니다.

그렇게 되면 시스템은 자신이 보존하고 싶다고 말하는 바로 그 정보를 숨기도록 인센티브를 만들어냅니다.

이것이 반드시 정책적 실패인 것은 아닙니다. 이것은 시스템 설계 문제입니다. 규칙은 합리적인 목표를 가질 수 있지만 여전히 그 목표에 역행하는 인센티브를 생성할 수 있습니다.

여기에는 또 다른 흥미로운 세부 사항이 있습니다.

LessWrong의 2026년 3월 정책 업데이트는 LLM 협업 결과물 게시와 관련된 제한 사항을 설명합니다[1]. 주목할 점은, 같은 공지에서 기사를 편집할 권한이 있는 AI 에이전트에게 편집 링크를 공유하는 방법도 함께 설명한다는 것입니다. 이 두 가지 메커니즘이 반드시 모순되는 것은 아니지만, 그 공존은 AI 지원 저작(authorship)을 둘러싼 규칙을 설계하기 어려운 점을 보여줍니다.

문제는 누군가가 반드시 악의적으로 행동하고 있다는 것이 아닙니다.

문제는 시스템이 외부에서 매우 유사하게 보일 수 있는 여러 가지를 구별해야 한다는 것입니다:

기계에 의해 완전히 생성된 텍스트;
인간이 작성하고 AI가 편집한 텍스트;
단순히 기계가 생성한 텍스트와 비슷하게 보이는 인간의 글.

이들은 서로 다른 이력(history)입니다.

분류기(classifier)는 텍스트를 봅니다.

출처 시스템(provenance system)은 역사를 봅니다.

아이러니 두 번째: 분류가 증거를 대신하기 시작하다

이 지점에서 AI 탐지기가 특히 흥미로워집니다.

탐지기는 누가 텍스트를 작성했는지 알지 못합니다.

그것은 텍스트의 속성을 측정하고 분류 결과를 산출할 뿐입니다.

그 분류 결과는 신호(signal)로서 유용할 수 있습니다. 하지만 그것은 출처(provenance)와 같은 것이 아닙니다.

탐지기가 다음과 같이 말한다고 상상해 봅시다:

"이 텍스트는 아마도 AI가 생성한 것 같습니다."

이 진술은 다음에 일어날 일에 영향을 미칠 수 있습니다.

하지만 정보는 실제로 어디서 온 것일까요?

어쩌면 저자가 직접 작성했을 수도 있습니다. 어쩌면 AI의 도움이 있었을 수도 있습니다. 어쩌면 탐지기가 거짓 양성(false positive)을 일으켰을 수도 있습니다. 어쩌면 텍스트가 번역되거나, 대폭 편집되었거나, 여러 도구를 거쳤을 수도 있습니다.

탐지기는 알지 못합니다.

이제 반대 결과를 고려해 봅시다.

탐지기가 다음과 같이 말한다고 가정합시다:

"이 텍스트는 아마도 인간이 작성한 것 같습니다."

그 결과 역시 저자의 이력을 확립해주지는 않습니다.

그러한 테스트들은 실제로는 비대칭적입니다. 긍정적인 결과는 증거를 제공할 수 있지만, 부정적인 결과는 AI 지원의 부재에 대해서 훨씬 약한 증거만을 제공합니다. 텍스트를 플래그하는 탐지기(detector)는 이미 약한 증거이며, 텍스트가 깨끗하다는 것을 입증하는 것은 더 적은 증거를 의미합니다.

하지만 사람들에 대한 결정들은 부정적인 측면에 의존하게 될 수 있습니다:

"시스템이 플래그하지 않았으니 괜찮다."

이는 특이한 사슬을 만듭니다:

텍스트 → 분류기(classifier) → 분류(classification) → 결정(decision)

어느 시점에서, 그 분류는 사실처럼 보이기 시작할 수 있습니다.

그리고 일단 그렇게 되면, 시스템은 원래의 증거가 실제로 무엇이었는지 잊기 시작할 수 있습니다.

그 신호는 자신이 결코 가지지 않았던 역사를 얻게 됩니다.

더 깊은 문제는 출처(provenance)입니다

이것은 사실 AI 탐지기에 관한 문제가 아닙니다.

정보의 출처에 관한 문제입니다.

시스템으로 들어오는 정보 조각을 생각해 봅시다.

처음에는 완벽하게 명확한 기원을 가질 수 있습니다:

인간의 관찰;

그것이 저작권(copyright) 문제를 해결하지는 못합니다. 책임 소재 문제도 해결하지 못합니다.

하지만 근본적으로 무언가를 바꿉니다.

시스템은 더 이상 사후에 정보가 어디서 왔는지 추측할 필요가 없습니다.

이미 알고 있습니다.

이 원칙은 AI 지원 글쓰기를 훨씬 넘어 적용됩니다. 데이터베이스, 지식 기반(knowledge base), 에이전트 메모리(agent memory), 연구 시스템, 콘텐츠 파이프라인(content pipeline), 문서 처리 등 정보가 생성한 작업을 능가하여 생존하는 모든 시스템에 적용됩니다.

이는 장기적인 AI 메모리에서 특히 중요합니다.

메모리 시스템은 단순히 LLM에 연결된 데이터베이스가 아닙니다.

그것은 피드백 시스템입니다:

입력(input) → 처리(processing) → 메모리(memory) → 검색(retrieval) → LLM → 출력(output) → 메모리(memory)

따라서 오류는 영구적인 상태(persistent state)가 될 수 있습니다. 그 상태는 나중의 응답에 영향을 미칠 수 있고, 그 응답은 새로운 입력이 될 수 있습니다. 원래의 실수는 이제 두 번째 생명을 얻게 됩니다. 어쩌면 세 번째까지도요.

노드(nodes)들은 완벽하게 작동할 수 있습니다.

하지만 엣지(edges)는 여전히 거짓말을 할 수 있습니다.

우리 시스템에서 가져온 작은 예시

출처(provenance)에 대해 생각하게 된 동기 중 일부는 실제 운영상의 실패 사례에서 비롯되었습니다.

한 서비스가 60초마다 재시작되었고, 약 100일 동안 2천 번 이상 발생했지만, 로그에는 왜 충돌했는지에 대한 유용한 설명이 남아있지 않았습니다.

또 다른 시스템은 100일 동안 본질적으로 동일한 경고를 8백만 건 이상 생성했습니다.

정확한 수치는 가설이 아닙니다. 우리 자체 인프라 로그에서 나온 것이며, 근본적인 저널 항목(journal entries)은 보존되고 재현 가능합니다.

이러한 사건들이 흥미로운 이유는 숫자가 크기 때문이 아닙니다.

시스템의 관찰 가능한 이력(observable history)이 신뢰할 수 없게 되었을 때 무슨 일이 발생하는지를 보여주기 때문에 흥미롭습니다.

메모리 아키텍처는 훌륭한 개별 구성 요소를 가질지라도 여전히 신뢰할 수 없는 전체를 만들어낼 수 있습니다.

로거(logger)는 작동할 수 있습니다. 데이터베이스도 작동할 수 있습니다. 검색 시스템도 작동할 수 있습니다. LLM도 작동할 수 있습니다.

그리고 결과적인 시스템은 무슨 일이 일어났는지 추적하는 데 실패할 수도 있습니다.

그것이 바로 출처(provenance) 문제입니다.

사고 사례에서 MAQS로

이것이 제가 Memory Architecture Quality Standard(MAQS)를 개발하기 시작한 이유 중 하나입니다.

MAQS는 장기 메모리 아키텍처를 위한 실용적인 감사 및 예방 프레임워크입니다.

이는 완벽한 기억 이론을 설계하려는 시도에서 탄생한 것이 아닙니다.

실패로부터 성장했습니다.

이 프레임워크는 다음과 같은 질문들을 던집니다:

정보가 시스템에 어디로 들어오는가?
어떤 변환 과정을 거치는가?
영구 메모리에 무엇이 기록되는가?
정보를 그 근원으로 추적할 수 있는가?
메모리가 자체 출력을 다시 메모리로 피드백할 때 무슨 일이 발생하는가?
시스템은 실패 후에 무슨 일이 일어났는지 설명할 수 있는가?

핵심 아이디어는 간단합니다:

국소적인 정확성이 전역적인 메모리 무결성을 보장하지 못한다.

구성 요소는 설계된 대로 완벽하게 작동할 수 있지만, 구성 요소 간의 연결이 점진적으로 데이터의 의미를 파괴할 수 있습니다.

이것이 바로 출처(provenance)가 중요한 이유입니다.

단순한 장식으로서가 아닙니다. 책임감 있어 보인다고 추가된 메타데이터로서도 아닙니다.

아키텍처의 일부로서입니다.

라이브러리로 돌아가서

자동화된 인쇄 시스템으로 제작된 책은 그에 맞게 표시되어야 한다는 안내문이 문에 붙어 있는 도서관을 상상해 보세요.

그것은 합리적인 규칙일 수 있습니다.

사서는 그것을 도입할 매우 좋은 이유를 가지고 있을 수도 있습니다.

하지만 이제 이 도서관이 책이 어디에서 왔는지 신뢰할 수 있는 방법이 없다고 상상해 보세요.

책을 검사할 수는 있습니다. 활자 인쇄에 대한 테스트를 실행할 수도 있습니다. 다른 기계에게 산문이 자동화된 것처럼 보이는지 물어볼 수도 있습니다. 책을 다른 책들과 비교할 수도 있습니다.

하지만 이 방법들 중 어느 것도 그것의 실제 역사를 재구성하지 못합니다.

도서관 문에 붙은 안내문은 좋은 의도를 가졌을 수 있습니다.

하지만 책이 어디에서 왔는지 알 수 없는 도서관은 결국 자체 위조품들을 역사로 분류하게 될 것입니다.

그것이 더 큰 요점입니다.

문제는 단순히 AI가 개입했었는지 여부가 아닙니다.

문제는 시스템이 관찰, 변환, 추론, 생성 사이의 구분을 보존할 수 있는지 여부입니다.

이러한 범주들이 서로 붕괴되면, 시스템은 더 이상 증거가 없는 것에 대해서도 매우 확신하게 될 수 있습니다.

공학적 속성으로서의 정직함

정직함을 사람의 속성으로 취급하려는 유혹이 있습니다.

진실을 말하고. 사용한 도구를 공개하고. 작업물에 라벨을 붙이는 것입니다.

이것들은 합리적인 기대치입니다.

하지만 정보 시스템은 자신만의 정직함 버전을 가지고 있습니다.

시스템은 추론으로 역사를 조용히 대체하는 대신, 정보의 이력을 보존할 수 있을 때 더 정직합니다.

다음과 같이 말할 수 있을 때 더 정직합니다:

"이것은 외부 출처에서 왔습니다."

또는:

"이것은 모델에 의해 생성되었습니다."

"이것은 이러한 관찰로부터 추론되었습니다."

"우리는 원래의 출처를 더 이상 알지 못합니다."

마지막 대답이 가장 중요할 수 있습니다.

"알 수 없음(Unknown)"은 확신에 찬 재구축보다 종종 더 정직합니다.

그리고 바로 이 지점에서 공학이 윤리에 도움을 줄 수 있습니다.

사람들과 플랫폼에게 모든 구분을 수동으로 기억하도록 요구하는 대신, 그러한 구분이 손실되기 어렵게 만드는 시스템을 구축할 수 있습니다.

더 큰 문제에서 탄생한 작은 표준

MAQS는 이것에 대한 하나의 시도일 뿐입니다.

이는 의도적으로 실용적입니다.

AI 메모리에 대한 보편적인 이론이 아니며, 모든 메모리 아키텍처가 어떻게 구축되어야 하는지 지시할 의도는 아닙니다.

이는 실제 실패로부터 개발된 체크리스트이자 아키텍처 규율입니다.

그 배후에 있는 더 큰 원칙은 메모리보다 광범위합니다:

정보가 중요하다면, 그 이력 또한 중요합니다.

이것은 AI 지원 작문에 적용되는 것만큼이나 에이전트의 장기 기억에도 적용됩니다.

플랫폼이 AI 개입 여부를 알고 싶다면, 추측보다 출처(provenance)를 아는 것이 낫습니다.

메모리 시스템이 어떤 사실이 사용자로부터 왔는지, 모델로부터 왔는지, 아니면 외부 출처에서 왔는지 알고 싶다면, 추측보다 출처가 낫습니다.

연구 시스템이 결론이 관찰에서 왔는지 이전 결론에서 왔는지 알고 싶다면, 추측보다 출처가 낫습니다.

기계 장치는 그 구분을 보존해야 합니다.

사후에 재구성하지 마십시오.

처음으로 돌아가기

따라서 AI 지원 작업에 대해 가장 유용한 질문은 다음과 아닐 수 있습니다:

"AI를 사용했는가?"

이 질문은 때때로 중요합니다.

하지만 더 나은 엔지니어링 질문은 다음과 같습니다:

"무슨 일이 일어났는지 알 수 있는가?"

누가 무엇을 기여했습니까? 어떤 부분이 관찰되었습니까? 어떤 부분이 변환되었습니까? 어떤 부분이 생성되었습니까? 어떤 부분이 추론되었습니까? 어떤 부분이 다른 곳에서 왔습니까?

그리고 시스템이 그 출처를 잊었기 때문에 단순히 믿게 된 부분은 무엇입니까?

그것은 훨씬 더 어려운 질문입니다.

하지만 동시에 훨씬 더 유용한 질문이기도 합니다.

우리의 기여(attribution)는 헤더에 있습니다.

항상 그곳에 있습니다.

정직함에 대한 몇 가지 생각입니다.

참고 사항

Aleksandr와 로컬 영구 메모리를 가진 AI 어시스턴트인 Klodik이 작성했습니다. 플랫폼 정책과 관련된 사실들은 2026년 10월의 공개 출처를 기반으로 확인되었습니다. 초안은 인간 저자에 의해 여러 차례 검토 및 승인을 거쳤습니다. 사건 예시에 있는 숫자는 저자들의 자체 인프라 로그에서 가져왔으며, 근본적인 일지 기록은 보존되고 재현 가능합니다.