문서는 늘어났지만, 신뢰할 수 있는 문서는 늘어나지 않았다

두 가지 사고로부터 시작되었다

최근 AI 에이전트(AI Agent)에게 기존 시스템의 개수를 맡기고 있었는데, 비슷한 사고를 두 번 겪었습니다.

첫 번째는 아직 작성 중인 사양 메모를 AI가 곧이곧대로 받아들인 사고입니다. 고백하자면, 그 메모 자체는 제가 논의 도중에 AI에게 쓰게 한 초안이었습니다. 미확정 상태인 그것을 다른 AI가 확정 사양으로 읽어 들여, 말도 안 되는 방향으로 구현이 진행되었습니다.

두 번째는 훨씬 더 질이 나쁩니다. 몇 년 전에 작성되고 이후 아무도 손대지 않은 설계 문서(Design Document)를 AI가 읽어 들여, 이미 존재하지 않는 전제로 이상한 움직임을 시작했습니다. 작성되었을 당시에는 분명 맞았을 문서입니다.

이 두 가지는 단순히 운이 나빴던 것만은 아니라고 생각합니다. AI 에이전트를 이용한 개발을 몇 달간 지속하자, 리포지토리(Repository)의 문서는 눈에 띄게 늘어나 있었습니다. 설계 메모, 조사 결과, 요약——대부분은 AI 스스로가 생성한 것입니다. 쓰는 비용이 사라진 만큼 문서는 쌓여가고, 모두 비슷한 모습을 하고 있습니다. 문서는 늘어났지만, 신뢰할 수 있는 문서는 늘어나지 않았다. 두 가지 사고는 그 산더미 속에서 일어날 수밖에 없었다는 느낌이 듭니다.

처음에는 기본적인 문서 관리와 하네스(Harness)의 문제라고 생각했습니다. "읽어도 좋은 문서"와 "읽어서는 안 되는 문서"를 나누어 AI에게 전달할 문맥(Context)을 정리하면 된다——그렇게 생각했습니다. 같은 사고를 겪은 분들도 우선은 같은 결론에 도달하지 않을까요?

하지만 이것은 정리의 문제가 아니었습니다.

"주의해서 선택하기"가 지속되지 않는 이유

"AI에게 읽힐 문서를 주의해서 선택한다". 이 대책은 지속되지 않습니다.

이것은 모든 사람이 매번 수동으로 문맥을 선별하고, 작성 중인 것에 표시를 남기고, 오래된 문서를 지우는 것을 기억하고 있다——라는 전제에 기반하고 있습니다. 개인의 역량에 의존하며 강제성이 없고, 문서가 늘어나면 결국 파탄 납니다. 누군가 한 명이 한 번이라도 태만해지면 구멍이 생기는 구조는 시스템이라고 부를 수 없습니다.

그리고 결정적인 것은, AI 스스로는 신뢰할 수 있는 문서와 그렇지 않은 문서를 구별할 수 없다는 점입니다. 작성 중인 메모도, 죽은 설계서도, 살아있는 사양도 AI가 보기에는 똑같은 글자일 뿐입니다. 인간조차 언뜻 보아서는 구분하기 힘든 것을 AI에게 "분위기를 파악해서 골라내라"고 요구하는 것은 무리가 있습니다.

그렇다면, 해결책을 인간의 주의력에 둘 수는 없다고 생각합니다. 신뢰의 판정은 문서 측이나 시스템 측이 가져야만 합니다.

공짜로 작동하던 신뢰의 시그널이 사라졌다

그렇다면 왜 이것이 이제 와서 문제가 된 것일까요. 가장 깊이 생각하게 만든 지점은 여기입니다.

"오래된 Wiki도 작성 중인 메모도 예전부터 지뢰였잖아. 존재 자체가 신뢰의 시그널이었던 적은 없어"라고 말할지도 모릅니다. 확실히 예전부터 유용하지 않은 문서는 있었습니다. 그럼에도 사고로 이어지기 어려웠던 데에는 두 가지 포인트가 있다고 생각합니다.

하나는 양입니다. 문서를 쓰는 데 비용이 들었기에 수가 적었고, 인간이 수동으로 선별할 수 있는 범위 안에 있었습니다.

다른 하나는 **시그널(Signal)**입니다. 굳이 써 놓았다는 사실 자체가 미약하게나마 "누군가가 의도했다"는 것을 의미했습니다. 수고를 들인 것에는 의도가 깃들어 있다는 추정입니다.

AI가 문서를 한없이 저렴하고 대량으로 생성할 수 있게 된 순간, 이 두 가지가 동시에 사라졌습니다. 양은 인간의 선별 능력을 넘어섰고, 존재는 더 이상 아무런 시그널도 발하지 않게 되었다. 초안도, 죽은 문서도, 살아있는 사양도 겉모습이 완전히 같아집니다. "적혀 있다"는 사실은 이제 아무것도 보장하지 않습니다.

그래서 진짜 문제는 "문서가 너무 많다"는 것만이 아닙니다. 풍부함이 선별할 수 있는 양과, 존재라는 미약한 시그널 두 가지를 한꺼번에 망가뜨렸다. 앞으로의 신뢰는 명시적으로 만들고 계속 유지해 나갈 수밖에 없습니다. 이제는 공짜로 얻을 수 없기 때문입니다.

같은 증상 뒤에 숨은 다른 두 가지 병

여기서 처음의 두 가지 사고를 다시 보겠습니다. 증상은 둘 다 "AI가 잘못된 문서를 읽었다"로 동일합니다. 하지만, 한 단계 더 깊게 나누어 볼 수 있습니다.

첫 번째, 작성 중인 문서의 사고는 "아직 승인되지 않은 것"을 진실로 취급했다는, 이른바 출생 시의 문제입니다. 필요한 것은 "이것은 초안이다"라고 생성되는 순간부터 붙어 있는, 기계가 읽을 수 있는 구분입니다. 작성한 본인이 기억하고 있다는 전제로는 부족하며, 문서가 태어나는 시점에 속성(Attribute)으로서 가지고 있어야 합니다.

둘째로, 오래된 문서의 사고는 **"과거에 승인되었으나, 아무도 유지하고 있지 않은 것을 진실(Truth)로 취급했다"**는 시간 경과의 문제입니다. 이후 이를 부패(腐敗)라고 부르겠습니다. 여기서 중요한 것은, 승인은 단 한 번의 도장이 아니라, 계속해서 유지되어야 하는 약속이라는 관점입니다. 승인한 순간에는 올바르더라도, 참조 대상인 코드가 바뀌어 전제가 변하면 문서는 서서히 부패합니다. 그렇다면 유지가 끊기면 신뢰도가 감쇠하는 장치가 필요합니다.

이 두 가지 문제는 별개로 생각할 필요가 있습니다.

덧붙이자면, 이것이 모든 것을 망라한다는 뜻은 아닙니다. 승인된 문서끼리 서로 충돌하는 '재정(Arbitration)'과 같은 구분 방식도 있을 것이며, 제가 실제로 겪은 것이 이 두 가지였다는 것뿐입니다.

결국 이것은, SSOT와 파생의 문제였다

이 두 가지 사고에는 또 하나의 공통점이 있습니다. 둘 다 출처(AI인지 인간인지)와는 상관이 없다는 것입니다. AI가 작성한 사양이라도 승인되고 유지되고 있다면 진실로 취급해도 좋습니다. 인간이 작성한 메모라도 승인되지 않았다면 진실이 아닙니다. 작성자가 아니라, "승인되었으며, 또한 유지되고 있는가"만이 유효합니다. AI 시대의 문서 불신은 "AI가 쓴 것이라 신용할 수 없다"라고 말해지기 쉽지만, 진짜 경계는 그곳이 아닙니다.

설계의 언어로 말하자면, 이것은 SSOT(Single Source of Truth)와 파생 데이터의 혼동입니다. 작성 중인 것이 파생품이면서 SSOT인 척했던 케이스, 부패는 과거의 SSOT가 파생품의 품질 수준까지 떨어져 버린 케이스입니다. DB에 비유하자면, SSOT가 원본 테이블(Base Table)이고 파생이 구체화된 뷰(Materialized View)입니다. 구체화된 뷰(Materialized View)를 시스템 오브 레코드(System of Record)로 취급해서는 안 됩니다 — AI에게 전달하는 문서에도 완전히 동일한 규율이 필요하다고 생각합니다. 진짜 질문은 처음부터 "어느 폴더에 둘 것인가"가 아니라, AI 스스로가 무엇을 진실로 취급해도 되는가였습니다.

승인 그 자체는 가볍다. 무거운 것은 상류와 하류다

승인이라는 행위 자체는 자세히 보면 가벼운 것입니다. "이것으로 가겠다"라고 결정하는, 그 한 점뿐입니다. 무거운 것은 그 양 끝에 있습니다.

상류는 "승인할 수 있는 형태로 정돈하는 것"입니다. 판정 가능한 단위가 되어 있고, 독립적으로 분리할 수 있으며, 구현 상세가 섞여 있지 않은 — 그러한 높이로 문서를 끌어올리는 작업입니다. 이곳이 정돈되어야 비로소 "승인됨인지 초안인지"가 문서 단위별로 기계적 판정이 가능한 속성(Attribute)이 됩니다.

이 상류의 어려움과 고안점은 타베로그(Tabelog)의 사례[1]가 이해하기 쉽다고 생각합니다. 해당 기업은 AI에게 요구사항 정의의 "정답"을 내놓게 하는 것을 그만두고, 데이터 엔티티(Entity) 상태에서 유스케이스(Use Case)를 분해하여, 그 유스케이스의 집합으로부터 업무 규칙을 귀납적으로 도출하는 형태로 바꾸었습니다. 나아가 도출된 업무 규칙에는 구현 상세를 섞지 않는다는 원칙을 철저히 하고 있습니다.

여기까지가 원문의 사실입니다. 여기서부터는 저의 재해석입니다만, 이것은 요구사항 정의의 효율화인 동시에, 승인할 수 있는 단위를 만드는 기술이기도 하다고 느꼈습니다. 혼재된 대량의 리스트는 승인할 수 없습니다. 하나하나 판정할 수 있고, 독립적으로 끊어지며, 구현에 의존하지 않는 선언으로서 나열되기 때문에 사람은 "이것으로 괜찮다"라고 말할 수 있습니다. "구체에서 추상으로"라는 순서는 승인할 수 있는 높이로 끌어올리는 절차 그 자체입니다.

그리고 상류의 핵심은 **입도(Granularity,粒度)**에 있습니다. 승인할 수 있는 단위를 어느 정도의 크기로 자를 것인가, 이에 대한 공식은 없습니다. 너무 거칠면 덩어리가 너무 커서 내용을 다 읽지 못해 승인은 그저 도장 찍기가 됩니다. 게다가 단위가 큰 만큼 되돌리는 비용(Rollback)도 커집니다. 너무 세밀하면 이번에는 승인할 개수가 폭발하여 사람이 승인 피로(Approval Fatigue)로 익사합니다. 둘 다 상류가 무너지는 실패이며, 적절한 높이는 프로젝트마다 다릅니다. 이곳은 자동화할 수 없으며, 논점을 어떻게 자를 것인가라는 인간의 판단이 남습니다. 상류의 가치는 바로 이 선 긋기 그 자체에 있다고 생각합니다.

하류는 "승인에 구속력을 갖게 하는 것"입니다. 승인됨인지 초안인지의 구분을 검증 메커니즘에 결선합니다. 체감상으로는 예를 들어 문서의 서두에 다음과 같은 속성을 갖게 하는 이미지입니다.

status: approved # draft / approved / 要再承認 (재승인 필요)
owner: team-a
source_of_truth: true # 진실로서 참조해도 좋은가
...

이러한 속성이 있다면 AI가 읽을 대상을 기계적으로 좁힐 수 있습니다. 미승인 문서는 참조에서 자동으로 제외하고, 초안이 머지(Merge)에 섞이면 CI에서 차단하며, depends_on의 코드가 바뀌면 要再承認(재승인 필요) 상태로 떨어뜨리는 — 구분을 효력 있게 만드는 장소가 여기서 생겨납니다. 반대로 구분이 있어도 효력을 발휘할 장소가 없다면, 그것은 그저 라벨로 끝납니다.

그리고 부패(腐敗) 사고가 하류(downstream)에 한 단계를 더 추가합니다. 하류는 머지(merge) 시점에 한 번 적용하고 끝나는 것이 아닙니다. 유지가 끊기면 등급을 낮춘다 — '승인됨'에서 '재승인 필요'로 떨어뜨리는 것까지가 하류입니다. 승인은 유지를 약속하는 것이므로, 유지가 끊긴 문서는 더 이상 '승인됨'으로 취급하지 않습니다. 예를 들어, 최종 승인으로부터 경과된 시간이나 참조 대상인 코드가 변경되었다는 사실을 트리거로 하여, 해당 문서를 '재승인 필요'로 떨어뜨리고 AI의 참조 대상에서 제외하는 — 그러한 장치를 생각할 수 있습니다.

정리하자면, 작성 중인 사고(書きかけの事故)가 상류(upstream)의 필요성을, 부패 사고가 하류에서의 유지 필요성을 각각 증명하고 있는 구조가 됩니다.

하네스(Harness)에서 거버넌스(Governance)로

"개인의 주의가 아니라 조직의 시스템으로"라고 말씀드렸지만, 이는 하네스에서 거버넌스로의 비약이라고 파악하고 있습니다.

하네스는 AI 에이전트의 발판입니다. 실행 환경, 문맥(context), 가드레일(guardrail), 검증 루프(verification loop)와 같이 에이전트가 안전하게 동작하기 위한 메커니즘을 모은 것을 가리킵니다. OpenAI의 Lopopolo는 에이전트가 실패했을 때 사람이 손으로 고치는 것이 아니라, 결여된 능력을 에이전트가 읽을 수 있고 강제할 수 있는 형태로 만들어 두어야 한다고 설파합니다. "사람이 키를 잡고, 에이전트가 실행한다"는 원칙입니다 [2].

다만, 폴더 규약이나 운영 규칙에 머무는 것은 결국 사람이 따른다는 전제가 되기 쉽습니다. 놓여는 있지만, 어겨도 멈추지 않습니다. 하네스 자체는 CI나 허가 도구로 강제력을 가질 수 있지만, 그것은 '어떻게 움직일 것인가'를 묶는 데까지입니다. 무엇을 옳다고 할지를 결정하고 유지하는 데까지는 닿지 않습니다. 이 지점이 거버넌스와의 갈림길이라고 생각합니다.

거버넌스는 인간이 "무엇을 옳다고 할 것인가"를 결정한 뒤, 그 상태를 기계가 판정하고 유지할 수 있는 것을 가리킵니다. 어떤 문서를 신뢰해도 되는지가 판정되고, 유지되며, 어기면 멈춘다. 거기까지 와야 비로소 거버넌스라고 부를 수 있다고 생각합니다.

토야마(外山) 씨는 이를 국가의 삼권분립에 비유하고 있습니다 [3]. 규칙을 정하는 것이 입법, 그것을 따르고 있는지를 심판하는 것이 사법, 실제로 움직이는 것이 행정이라는 구분입니다. 그의 지적 중 핵심은 "적혀 있는 것"과 "효력이 발생하는 것"은 다르다는 점입니다. ADR도 Wiki도 설계서도, 잘 갖춰져 있어도 그저 "적혀 있을" 뿐입니다. 위반해도 아무도, 아무것도 멈추지 않는다면 거버넌스가 되지 않는다는 뜻입니다.

이 삼권을 앞서 말한 상류와 하류에 겹쳐보면, 역할이 깔끔하게 나뉩니다.

승인할 단위를 기초하는 것이 입법 (상류) / 승인 그 자체가 채결
구분을 검증하고 연결하는 것이 사법 (하류)

가치와 난관은 입법과 사법 — 즉 상류와 하류에 있습니다. 승인의 의식이나 폴더 규약은 머지않아 범용화되어 차이가 없어질 중간 단계입니다.

또한, 하네스는 외부에서 빌려올 수 있어도 거버넌스는 자사에서 직접 만들어야 한다 [3:1]라고 토야마 씨는 말합니다. 자사에 남는 것은 무엇을 옳다고 할 것인가(규칙의 내용)와 어느 입도(granularity)로 승인할 것인가(경계 긋기)의 판단이라고 생각합니다.

남아있는 과제

유지 비용과 속도는 트레이드오프(trade-off) 관계입니다. 출처와 유지를 책임지게 하는 것은 AI가 제공하는 속도와 충돌합니다. 무료로 얼마든지 양산할 수 있지만, 신뢰하게 만들기 위해서는 공수가 들어갑니다. 이 트레이드오프가 난관이라고 생각합니다.

상류는 구체적인 내용을 보기 전까지는 쓸 수 없는 경우가 있습니다. 승인할 단위는 추상 단계에서는 분리해낼 수 없으며, 구체적인 모습이 나타나고 나서야 비로소 제대로 된 관점이 보일 때가 있습니다. 타베로그(食べログ)의 사례에서도 요건은 구체적인 모습으로 나타나고 나서야 새로운 관점이 솟아난다고 언급되었습니다 [1:1]. 구체적인 사례로부터 추상화로 떨어뜨리기 위한 시행착오가 필요할지도 모릅니다.

그리고 구분(切り分け) 자체를 자동화하고 싶어집니다. "그렇다면 신뢰할 수 있는 문서와 그렇지 않은 문서를 구분하는 것 자체도 AI에게 맡기면 된다"라고 생각할지도 모릅니다. 하지만 그것은 처음의 사고로 돌아가는 길입니다. 무엇을 진실(truth)로 할지를 AI가 판정하게 하는 순간, 그 판정의 근거가 SSOT(Single Source of Truth)가 아닌 파생물이 될 가능성이 있습니다. 구분을 돕게 할 수는 있어도, 마지막에 "이것을 진실로 한다"라고 책임지는 부분은 놓아줄 수 없습니다. AI는 실행의 영역에서 밖으로 확장될 수는 있어도, 무엇을 진실로 할지를 책임지는 입법의 책임까지는 담당할 수 없습니다. 그 원(circle)에는 인간이 남습니다.

이러한 과제들에 대한 대처는 다음에 다시 생각해보고자 합니다.

마치며

AI가 문서 작성 비용을 무료로 만든 바로 그 사실이 문서의 신뢰를 무너뜨렸습니다. 과거에는 의식하지 않아도 발신되었을 '의도의 시그널 (signal of intention)'을 문서의 방대함이 지워버린 것입니다. 그렇기에 우리는 앞으로 명시적으로 신뢰를 다시 구축해 나갈 수밖에 없습니다.

大橋「AI로 요구사항 정의의 토대를 즉시 생성하여, 요구사항 변경에 따른 재작업 (rework) 비용을 제로에 가깝게 만든 이야기」 Tabelog Tech Blog, 2026년 6월 11일. https://tech-blog.tabelog.com/entry/ai-driven-requirements-definition-process_52 ↩︎ ↩︎

Ryan Lopopolo, "Harness engineering: leveraging Codex in an agent-first world," OpenAI, 2026년 2월 11일. https://openai.com/index/harness-engineering/ ↩︎

外山英幸「AI 주도 개발이 바꾸는 대규모 개발의 전제 ―Human in the Loop에서 Human on the Loop로」 AI Engineering Summit Tokyo 2026 (2026년 6월 8~9일), Speaker Deck. https://speakerdeck.com/visional_engineering_and_design/aie2026 ↩︎ ↩︎