서론

AI가 생성할 수 있는 정보량은 급격히 증가하고 있지만, 인간이 한 번에 읽을 수 있는 양은 변하지 않습니다.

대량의 사양서나 코드를 AI에게 만들게 하더라도, 인간이 확인할 수 없다면 의미가 없습니다.

AI로 무책임하게 생산되는 결과물에 대해 경종을 울리는 전문가들도 있습니다.

Linux 창시자인 리누스 토발즈(Linus Torvalds) 씨는 Open Source Summit North America 2026의 기조연설에서, AI 이용으로 인한 pull request의 급증과 후속 조치가 없는 버그 보고가 받는 쪽의 부담이 된다고 지적했습니다. 패치가 없는 지적이나, 추가 설명을 요구해도 응하지 않는 보고도 문제시하고 있습니다.

읽는 것을 주안점으로 둔 출력을 지향하기

토발즈 씨가 문제로 삼고 있는 것은 AI 그 자체가 아니라, 판단으로 이어지지 않는 출력의 증가입니다.

책임을 동반하지 않는 지적이 늘어남으로써, 받는 쪽만은 정밀 조사나 대응 비용을 떠안게 됩니다.

본 기사에서 말하는 AI 슬롭 (AI slop) 도 같은 구도의 문제입니다. 인간의 판단에 사용하기 어려운 생성물이 늘어날수록 리뷰, 정밀 조사, 팔로업(Follow-up)의 비용이 쌓입니다. 앞으로의 AI 활용에서는 생성량을 늘리는 것보다, AI 슬롭을 줄이는 것이 중요해질 것이라고 느끼고 있습니다.

AI 슬롭이란 무엇인가

AI 슬롭(AI slop)이란 일반적으로 저품질로 대량 생산된 AI 생성 콘텐츠를 가리키는 말입니다.

이 기사에서는 범위를 조금 넓혀, 내용이 올바르더라도 인간의 판단에 사용하기 어려운 결과물 도 AI 슬롭으로 취급합니다.

• 중간 판단이 혼재되어 최종 판단을 쉽게 찾을 수 없는 사양서
• 우선순위나 의존 관계가 보이지 않는 태스크(Task) 목록
• 변경 이유나 개수 의도가 보이지 않는 코드

AI 슬롭을 줄인다는 것은 글자 수를 깎는 것이 아니라, 인간이 판단하기까지 필요한 독해 비용을 낮추는 것입니다. 줄이는 방법으로서 HTML을 통한 정보 정리와 Linter, 테스트, CI를 통한 자동 검증 두 가지를 다룹니다.

HTML로 AI 슬롭을 줄이기

이것을 시도하게 된 계기는 Anthropic의 엔지니어인 Thariq Shihipar 씨의 포스트였습니다.

AI의 결과물을 Markdown이 아닌 HTML로 만들게 함으로써, 정보를 읽기 쉽고 공유하기 쉽게, 경우에 따라서는 조작할 수 있는 형태로 만든다는 내용입니다. 이를 Codex로 시도해 보았습니다.

실제로 실행해 보니 세세한 스타일링이 아니라, 태그 자체가 시맨틱(Semantic)하다는 것에 큰 이점을 느꼈습니다. section, h2, table 등으로 각 블록의 역할을 명시하면서 AI는 그 구조를 파악하여 기재할 수 있습니다. 당연히 인간은 그것을 일일이 추적할 필요가 없습니다.

그렇다고는 해도, 빨간색을 이용하거나 반전 효과를 통한 강조 등, 색각을 동반한 어필이 가능하다는 장점도 있습니다.

또한 Markdown보다 파일 간의 체계가 파악하기 쉽다는 것도 특징입니다.

열람 시에는 기점이 되는 index.html을 열도록 하고, 개별 HTML 파일은 거기서부터의 링크를 철저히 함으로써 체계화하기 쉽습니다.

실례: 스펙(사양서)을 HTML로 정리하기

실제로 시도한 것이 AWS 인프라 학습용 프로젝트의 HTML형 스펙 주도 개발(Spec-driven development)입니다.

스펙 주도 개발을 Markdown으로 진행할 경우, 대략 다음과 같은 구성이 됩니다.

my-app/
├── .sdd/ # SDD 관리용 디렉토리
│ ├── steering/ # 프로젝트 전체의 「헌법」
...

Markdown은 개별 페이지는 어느 정도 읽기 편하지만, 파일을 넘나들 때의 이동이 불편하다고 느낍니다.

HTML로 문서를 웹사이트처럼 준비하고, index.html을 기점으로 하면 처음 보는 페이지가 하나로 고정되어 가독성이 좋아집니다.

디렉토리 구성은 다음과 같이 해 보았습니다.

spec/
├── index.html # 기점. features / tasks / steering으로의 링크 목록
├── styles.css # 공통 스타일
...

features/, steering/, features/tasks.html 세 가지로 나누고, 모두 index.html에서 링크로 찾아갑니다.

features/: 기능별 Living Documents

features/YYYYMMDD-topic.html

형식으로, 기능 단위의 사양을 날짜별로 남깁니다. 요구사항 정리부터 설계, 구현, 확인까지 진행 상황에 따라 문서가 늘어납니다. 미대응·미결정 사항은 개별 feature 문서에 쓰지 않고, features/tasks.html에 집약합니다.

작업 이력에 해당하므로 양이 늘어나면 검색 효율이 떨어집니다. 상태를 나타내는 내용을 steering/에 반영함으로써 컨텍스트 (Context)를 효율화해 나갑니다.

태스크를 집약하는 것은 개인 개발의 편의를 위한 것이지만, 팀 개발이라면 각 feature의 HTML에 포함시켜도 좋다고 생각합니다.

steering/：프로젝트 횡단 방침과 운용

features/와는 별도로, 결정 사항이나 상태 관리 페이지를 steering/에 둡니다.

종류	역할	예
구성	목표로 하는 시스템 전체의 방침	인프라, 앱, 프론트엔드
운용	반복해서 사용하는 절차·규칙	runbook, 배포, 복구

features/는 "그 기능에서 무엇이 일어났고, 무엇이 확정되었는가"를, steering/는 "지금 프로젝트 전체로서 무엇을 전제로 하는가"를 다룹니다. 이러한 분리가 있으면 과거의 features/ 문서를 다시 읽지 않아도 현재의 판단에 필요한 정보에 도달할 수 있습니다.

AI의 컨텍스트 (Context)에도 효과적

이 구조는 인간만을 위한 것이 아닙니다.

인덱스를 준비하여 전체 구조를 파악하기 쉽게 만듦으로써, AI에게도 컨텍스트 (Context)를 전달하기 쉬워졌습니다.

• 구현 상담 → steering/의 구성 페이지와 최근의 features/ 문서
• 개별 작업 → steering/deploy.html 등의 운용 문서
• 잔여 사항 확인 → features/tasks.html

자동 검증으로 AI 슬롭 (AI Slop)을 줄이기

HTML은 문서를 정리할 수 있습니다. 다음은 코드 등의 실제 결과물의 슬롭 (Slop)을 줄입니다. 이것은 전통적인 검증 결과물을 AI를 사용하여 늘려가는 수법입니다.

• Linter
• Formatter
• 타입 체크 (Type Check)
• 정적 분석 (Static Analysis)
• 단위 테스트 (Unit Test)
• E2E 테스트 (End-to-End Test)
• 빌드 체크 (Build Check)
• CI

AI에게 구현만을 의뢰하는 것이 아니라, 구현과 병행하여 검증 메커니즘도 만들게 합니다. 무엇이 자동 검증되었는지, 무엇이 미검증인지, 인간이 판단해주길 바라는 지점은 어디인지 —— 이 경계까지 결과물에 포함합니다.

테스트 케이스의 망라(Coverage)나 파악은 중요한 과제가 됩니다. 커버리지 (Coverage) 출력이나 테스트 케이스 표의 출력을 의무화함으로써, 인간이 더 체크하기 쉬운 체제를 준비할 수 있을 것이라 생각합니다.

Markdown과 HTML은 구분해서 사용하기

README, 짧은 절차, 규칙, Git으로 차분 관리(Diff)하고 싶은 사양에는 Markdown이 적합합니다.

문장을 직접 편집하기 쉽고, 불필요한 구조를 갖지 않는 것 자체가 강점입니다.

반면, 긴 사양서, 비교 자료, 구현 계획, 리뷰 자료는 HTML 쪽이 읽는 양을 제어하기 쉬운 경우가 있습니다.

용도	적합한 형식
README, 짧은 메모, 규칙	Markdown
...

장단점이 있으므로, 그 결과물을 인간이 어떻게 읽는지, AI가 다음 작업에서 어떻게 재사용하는지에 따라 형식을 선택합니다.

AI의 진화에 맞춰 매일 재검토하기

이번 기사에서는 AI에 의한 생성물을 정돈함으로써, 인간의 역할을 "생성물을 읽는 것"에서 "판단하는 것"으로 옮기는 데 주안점을 두었습니다.

하지만 이 기사에서 소개한 방법도 현시점에서의 사용법에 불과합니다.

AI 모델의 능력은 앞으로도 계속 변해갈 것입니다.

미래에는 인간의 역할을 더욱 AI나 자동 검증에 맡길 수 있을지도 모릅니다.

모델의 능력이 변하면 인간이 읽어야 할 범위도 재검토한다.

무엇을 생성시킬 것인가뿐만 아니라, 무엇이 AI 슬롭 (AI Slop)이 되기 쉬운지를 생각한다.

이 업데이트를 계속하는 것이 AI 활용에서는 중요하다고 생각합니다.

참고

Discussion