서론

AI Slop 문제는 "AI가 만든 것이니까 나쁘다"라는 이야기가 아닙니다. 문제의 본질은, 검증되지 않았고, 책임 소재가 모호하며, 수신자에게 인지 부하를 떠넘기는 결과물이 대량으로 유통되는 것입니다.

인터넷상의 저품질 콘텐츠뿐만 아니라, 사내 문서, 티켓, 리뷰 요청, 취약점 보고에도 동일한 구조가 들어오고 있습니다.

특히 소프트웨어 개발에서는 생성 속도가 올라가는 반면, 리뷰, 검증, 이해, 유지보수의 속도는 그만큼 올라가지 않고 있습니다. 이 차이가 "코드의 Slop화"나 "이해의 부채"로서 축적됩니다.

따라서 여기서 전달하고자 하는 메시지는 다음과 같습니다.

• AI 생성 그 자체를 금지하는 것이 아니라,
  검증 가능성, 설명 책임, 리뷰 가능성을 기준으로 다룬다.
• 에이전트(Agent)나 루프(Loop)는 구현 내부의 반복을 가속화한다. 반면,
  방침 결정, 승인, 리스크 판단, 최종 책임은 인간이 외부 루프로서 갖는다.
• 엔지니어의 가치는 AI에게 쓰게 하는 능력이 아니라, AI의 출력을 제어하고 품질을 유지하는 능력으로 옮겨가고 있다.

AI Slop에 의한 문제점

AI Slop

AI Slop란, AI에 의해 생성된 결과물 중 겉모습은 정돈되어 있으나 정확성, 문맥 적합성, 독자적인 가치, 설명 책임 중 어느 하나가 부족하여 수신자에게 재확인이나 수정의 부담을 떠넘기는 것을 가리킵니다.

중요한 점은, AI 생성 콘텐츠 전부가 Slop는 아니라는 점입니다. 인간이 목적을 정의하고, 근거를 확인하며, 편집하고, 책임감을 가지고 전달하는 AI 지원 결과물은 Slop가 아닙니다.

Work Slop

Work Slop는 사내 업무에서의 AI Slop입니다. 예로, 그럴듯하지만 의사결정에 사용할 수 없는 보고서, 논점이 얕은 슬라이드, 티켓의 문맥을 읽지 않은 코멘트, 재현성 없는 조사 메모 등이 있습니다.

작성자는 짧은 시간에 만들 수 있지만, 수신자는 이를 읽어내고, 사실을 확인하며, 다시 작업하는 시간을 빼앗깁니다.

Code Slop

Code Slop는 표면적으로는 동작하거나 테스트를 통과하지만, 설계 의도, 경계 조건, 유지보수성, 감사 가능성이 약한 코드를 가리킵니다.

AI가 작성한 코드라는 사실 자체가 아니라, 인간이 이해·설명·유지보수할 수 없는 상태로 도입되는 것이 문제입니다.

AI 개발 기법의 평가

Context Engineering

Context Engineering은 AI에게 충분한 문맥을 제공하는 기술입니다. 리포지토리(Repository) 전체를 대충 넘기는 것이 아니라, 관련 파일, 설계 배경, 제약 사항, 용어, 과거의 의사결정, 테스트 결과 등을 필요한 입도(Granularity)로 전달합니다.

효과는 크지만 만능은 아닙니다. 잘못된 컨텍스트나 오래된 사양을 전달하면, AI는 그것을 자신만만하게 확장합니다. 따라서, 컨텍스트에는 신선도, 출처, 우선순위가 필요합니다.

Harness Engineering

Harness Engineering은 AI를 둘러싼 실행 환경, 권한, 도구, 테스트, 가드레일(Guardrail)을 설계하는 것입니다. 파일 조작 권한, 네트워크 권한, CI, lint, 타입 체크, 유닛 테스트(Unit Test), E2E, 보안 스캔, 차이점(Diff) 리뷰 등이 포함됩니다.

초보적인 Slop, 예를 들어 구문 오류, 명백한 테스트 실패, 파괴적인 조작 등은 상당히 줄일 수 있습니다. 반면, 테스트가 약한 영역, 사양이 모호한 영역, 설계 판단을 동반하는 영역에서는 Harness만으로는 품질을 보증할 수 없습니다.

Loop Engineering

Loop Engineering은 AI가 조사, 구현, 검증, 수정을 반복하는 메커니즘입니다. 인간이 매번 프롬프트(Prompt)를 쓰는 것이 아니라, 목적, 상태, 검증 조건, 정지 조건을 가진 루프를 설계하여 에이전트가 내부 작업을 진행하게 합니다.

이는 개발 효율을 크게 높입니다. 다만, AI Slop의 관점에서는 가장 주의가 필요합니다. 루프는 저품질 출력을 수정하는 메커니즘이 되기도 하지만, 정지 조건이나 리뷰 조건이 약하면 저품질의 차이점을 빠르게 쌓아 올리는 메커니즘이 되기도 합니다.

Loop Engineering의 적절한 위치 설정

적절한 인식은 "루프는 위험하니까 피하자"도 아니고 "루프에 맡기면 된다"도 아닙니다.

적절한 인식은, 에이전트는 내부의 실행 루프를 돌리고, 엔지니어는 외부의 책임 루프를 소유한다입니다.

Loop가 Slop을 생성하는 전형적인 패턴

• 테스트 최적화 (Test Optimization): 본질적인 설계를 수정하지 않고, 테스트를 통과하기 위한 패치만을 덧댄다.
• 의도의 소실: 최종 차분(diff)만 남게 되어, 왜 그런 설계를 했는지 설명할 수 없게 된다.
• 리뷰 불가능한 차분: 생성 속도가 너무 빨라서 인간이 배경과 영향 범위를 추적할 수 없다.
• 자기 채점의 관대함: 작성자와 검증자가 실질적으로 동일한 전제를 가지고 있어, 동일한 결함을 놓친다.
• 정지 조건의 결여: 불확실성이 높은데도 루프가 "완료"라고 말할 때까지 계속 실행된다.

Loop를 실용적으로 운용하기 위한 조건

• 명시적인 정지 조건: 몇 번 실패하면 멈출 것인지, 어떤 종류의 변경사항을 인간에게 넘길 것인지를 결정한다.
• 에비던스 (Evidence): 차분 요약, 실행한 테스트, 실패한 시도, 잔존 리스크, 대안 등을 PR(Pull Request)에 남긴다.
• 독립된 검증: 구현 에이전트와는 다른 관점에서 리뷰한다. 중요한 변경사항에 대해서는 인간의 설계 리뷰를 필수화한다.
• 변경 사이즈의 제한: 루프 1회당 차분을 인간이 15~30분 내에 리뷰할 수 있는 크기로 억제한다.
• 고위험 영역의 승인: 인증, 결제, 개인정보, 권한, 데이터 이관, 공개 API, 장애 대응 플로우는 자동 머지(merge)시키지 않는다.

요약

AI Slop 문제는 AI를 사용할 것인가의 논의가 아니라, 생성 속도에 맞춰 검증·이해·책임의 메커니즘을 어떻게 따라잡게 할 것인가의 논의입니다.

엔지니어가 담당해야 할 역할은 AI의 출력을 맹신하는 것도, AI 이용을 중단하는 것도 아닙니다.

컨텍스트(Context), 하네스(Harness), 루프(Loop), 리뷰(Review), 감사 로그(Audit Log)를 조합하여, AI가 만드는 것을 "빠르기만 한 결과물"에서 "책임 있게 내놓을 수 있는 결과물"로 바꾸는 것입니다.

참고 문헌

• 【AI Slop】社内でも AI ゴミ PR やめよう - Zenn
• Graphite: AI Now Writes as Many Online Articles as Humans Do
• Google Search Central: Spam policies for Google web search
• Google Search Central: Guidance on using generative AI content
• YouTube Community: Response to creator questions about YPP policies
• Daniel Stenberg: The end of the curl bug-bounty
• Daniel Stenberg: curl security moves again
• BetterUp Labs / Stanford Social Media Lab: Workslop
• Nature: AI models collapse when trained on recursively generated data
• Addy Osmani: Loop Engineering
• Addy Osmani: Own the Outer Loop

Discussion