우리는 20년 동안 'slop'을 배포해 왔습니다. 우리는 그것을 MVP라고 부르곤 했죠.

발행: 1주 전 (2026년 1월 10일 오전 12:04 GMT+9)

12 min read

Source: Dev.to

“우리는 20년 동안 ‘슬롭’을 배포해 왔습니다. 우리는 그냥 MVP라고 부르곤 했죠.” 커버 이미지

소개

많은 사람들이 **“slop”**이라는 단어를 AI‑생성 코드의 약어로 사용하기 시작했습니다. 그들의 입장은 AI가 저품질 소프트웨어를 산업에 넘쳐나게 하고 있으며, 우리는 나중에 장애, 회귀, 그리고 기술 부채 형태로 그 대가를 치르게 될 것이라는 것입니다.

그 주장은 설득력 있게 들리지만, 지난 20 년간 실제로 소프트웨어가 어떻게 구축되어 왔는지를 솔직히 살펴보면 그렇지 않다는 것이 드러납니다.

불편한 진실은 “slop”이 AI와 함께 시작된 것이 아니라는 점입니다. 사실 AI는 더 이상 부정할 수 없게 만들었습니다.

첫 번째 LLM이 훈련되기 훨씬 이전에 산업이 따랐던 무언의 계약을 이제 밝혀봅시다.

소프트웨어는 항상 실행을 최적화해 왔습니다

Google의 유명하게 엄격한 리뷰 문화 외에도, 대부분의 대형 기술 기업들(Meta, Amazon, Microsoft 등)은 역사적으로 속도를 우선시해 왔습니다.

실제 현장에서는 PR이 종종 대충 훑어봅니다.
버그는 사용자가 보고한 뒤에 수정됩니다.
아키텍처는 제품이 입증된 후에 진화합니다.

당시 우리는 이를 “형편없는 코드”라고 부르지 않았습니다; MVP(Minimum Viable Product)라고 불렀습니다.

비교해 보면, 오늘날 코딩 에이전트가 제공하는 일부 코드는 이미 많은 기업의 일반적인 초기 단계 PR보다 뛰어납니다. AI가 새로운 “충분히 좋은” 코드 시대를 도입한 것이 아니라, 수십 년 동안 사용해 온 전략을 위한 최신 도구일 뿐입니다. 돌이켜 보면, 우리는 언제나 내부 코드 순수성을 외부 시장 속도와 교환할 준비가 되어 있었습니다.

Source: …

오픈‑소스 해법

주된 예외는 다르게 운영되는 오픈‑소스 프로젝트입니다. 오픈 소스는 수십 명 혹은 수백 명의 개발자가 기여하더라도 일관되게 신뢰할 수 있고 유지 보수가 쉬운 코드를 생산해 왔습니다.

왜일까요?

모듈화가 강제됩니다.
기여자는 격리된 환경에서 작업하며, 시스템을 깨뜨리지 않고도 내부 맥락을 전혀 모르는 사람이 기여할 수 있도록 엄격한 API 경계와 깔끔한 추상화를 반드시 준수해야 합니다.
공격적인 반복 루프.
모든 기여는 자동화된 테스트와 다양한 사람들의 피어 리뷰를 거칩니다. 피드백은 여러 출처에서 나오며, 이는 일반적으로 하나 또는 두 개의 특정 사용 사례를 위해 작성된 코드보다 전체적인 품질이 더 높게 수렴합니다.

이러한 환경은 실행을 완벽함보다 우선시하는 것이 가능함을 보여줍니다—만약 기여자에게 명확한 경계와 자동화된 피드백을 제공한다면 말이죠. AI 에이전트를 외부 오픈‑소스 기여자처럼 다루면 “느슨함”이 사라집니다.

에이전트에 품질을 엔지니어링하기

Pochi에서는 AI 에이전트의 출력이 주변에 구축한 컨텍스트 가드레일만큼만 좋다고 믿습니다. “슬롭”을 피하려면 단순한 채팅 프롬프트를 넘어선 노력이 필요합니다. 우리에게 효과적이었던 팁을 소개합니다:

1. 환각(Hallucination) 문제 해결

AI가 생성한 코드에서 가장 큰 문제는 존재하지 않는 라이브러리나 폐기된 구문을 환각하는 경향입니다. 이는 개발자가 Prompt Engineering이 아니라 Environment Engineering 관점으로 생각할 때 발생합니다.

해결책: 에이전트를 CI/CD 파이프라인에 직접 통합합니다. 모든 코드 라인은 컴파일러, 린터, 정적 분석 도구를 통해 즉시 검증됩니다. 환경이 오류를 즉시 포착하므로 AI가 스스로 정확해지기를 기다릴 필요가 없습니다.

2. “클라우드 마크다운” 사용

“클라우드 마크다운” 접근 방식은 대규모 설계 실무에 유용합니다. 장황한 아키텍처 표준이 담긴 정적 PDF 대신, 에이전트의 진실 원천이 되는 README.pochi.md 파일을 작성합니다.

예시 가드레일 파일 (README.pochi.md):

# Project Design Patterns

아키텍처 개요

헥사고날 아키텍처를 따르세요.
모든 외부 종속성은 인터페이스를 통해 주입되어야 합니다.
핵심 비즈니스 로직에서 제3자 서비스에 직접 호출하지 마세요.

코딩 표준

TypeScript strict 모드를 사용하세요.
ESLint @typescript-eslint/recommended를 적용하세요.
any 타입을 사용하지 말고 명시적 제네릭을 선호하세요.

CI/CD 체크

모든 PR에 대해 npm run lint를 실행합니다.
npm test -- --coverage를 실행하고 80 % 이상의 커버리지를 요구합니다.
tsc --noEmit으로 생성된 코드가 컴파일되는지 확인합니다.

의존성 관리

모든 의존성은 특정 버전으로 고정해야 합니다.
잠금 파일 항목 없이 전이 의존성을 허용하지 않습니다.
npm audit를 사용하고 고위험 결과가 있으면 빌드를 실패하도록 합니다.

검토 프로세스

모든 AI‑생성 PR은 최소 한 명의 인간 검토자를 가져야 합니다.
검토자는 코드가 위의 가드레일을 준수하는지 확인해야 합니다.


By feeding this markdown to the agent, you give it a concrete, machine‑readable contract that mirrors the rigor of an open‑source project.

Bottom Line

“Slop”은 새로운 AI 문제가 아니라, 속도와 완벽함 사이의 오래된 트레이드오프이다.
오픈소스 프로젝트는 엄격한 모듈 경계와 자동 피드백이 그 트레이드오프를 관리할 수 있음을 보여준다.
AI 에이전트를 외부 기여자로 대하고, 명확한 가드레일(CI/CD 검증, “cloud markdown” 사양)을 제공하면 “slop”이 사라진다.

에이전트에 엔지니어링 품질을 내재화하는 것이 AI‑생성 코드를 위험 요소에서 자산으로 전환하는 핵심이다.

Data Fetching

Rule: 컴포넌트에서 직접 fetch 호출을 하지 않음.
Pattern: @/lib/api의 useQuery 래퍼를 사용.
Reasoning: 전역 오류 처리와 캐싱이 적용됨을 보장합니다.

상태 관리

제약: 모든 공유 상태는 LiveStore에 있어야 합니다.
패턴:
```
const [data, set] = useLiveStore(key);
```

전체‑screen 제어 (예시)

Enter fullscreen mode
Exit fullscreen mode

핵심 워크플로우

문서를 컨텍스트로 활용
깊은 아키텍처 규칙과 디자인 패턴을 포함한 Markdown 파일을 리포지토리에 직접 저장합니다.
프롬프트 인젝션
에이전트가 작업을 시작하기 전에, 이 Markdown 파일들을 “읽어” 전역 제한 사항을 이해합니다 (예: “LiveStore를 통해 로컬‑우선 저장 패턴을 항상 사용”).
컨텍스트 스캐폴딩
이를 통해 에이전트가 진공 상태에서 코드 조각을 작성하지 않으며, 기존 코드베이스의 특정 스캐폴딩을 따르게 됩니다.

이러한 방식으로 아키텍처 지식을 삽입하면 에이전트가 주요 마이그레이션 전에 가능한 한 많은 파일 수준 컨텍스트를 수집할 수 있어 보다 정확한 결과를 도출합니다.

결론

결국 사용자는 절대 “슬롭”을 보지 못합니다. 대신 깨진 인터페이스, 느린 로딩 시간, 충돌, 그리고 신뢰할 수 없는 기능을 보게 됩니다.

AI가 생성한 코드를 “슬롭”이라고 일축한다면, 컴퓨팅 역사상 가장 큰 속도 변화를 놓치게 되는 것입니다. 오픈소스 규율(엄격한 검토와 모듈화)과 AI 지원 실행을 결합함으로써, 우리는 드디어 빠르게 배포할 수 있으면서도 변화에 탄력적인 소프트웨어를 만들 수 있습니다.