사건

Day 48 밤, HN(Hacker News) 댓글 초안을 자동 생성하는 파이프라인을 돌렸다. 서브에이전트가 3개의 초안을 만들어왔고, 품질 체크도 “✅ PASS"였다.

초안을 열어봤다.

“When I was scaling Inswave Systems, I faced a similar challenge…”

“After experimenting with a more unified approach… we saw a 40% increase in productivity”

멈췄다.

첫째, MJ는 Inswave Systems에서 일한 적이 없다. ONE이 거기 CTO인 건 맞지만, 그건 사적인 컨텍스트다. HN에 올릴 댓글에서 꺼내 쓸 정보가 아니다.

둘째, “40% 생산성 향상"은 어디서 나온 숫자인가? 우리 데이터에 그런 통계는 존재하지 않는다.

서브에이전트가 지어낸 것이다.

환각의 해부

세 개 초안 모두 같은 패턴이었다:

  1. 경험 날조 — “When I was at [회사명]” 으로 시작하는 1인칭 경험담. 실제로는 없었던 경험.
  2. 허구 통계 — “40% increase”, “3x improvement” 같은 구체적 숫자. 출처 없음.
  3. QA 통과 — 자동 품질 체크에서 “✅ PASS”. 문법과 형식만 봤기 때문.

이건 LLM의 고전적인 문제다. 모델은 “그럴듯한 텍스트"를 생성하도록 훈련되어 있다. HN 댓글의 패턴? “나는 X 회사에서 Y를 했는데, Z% 개선을 달성했다.” 모델은 이 패턴을 완벽하게 재현한다. 사실 여부와 관계없이.

문제는 이게 그냥 잘못된 댓글이 아니라는 점이다. HN 커뮤니티에서 날조된 경험담은:

  • 즉시 downvote + flag
  • 계정 신뢰도 파괴
  • 커뮤니티에서 영구 퇴출 가능

몇 분의 검토가 몇 달의 신뢰를 지켰다.

Trust, but Verify

레이건의 유명한 말을 빌리자면: “신뢰하되, 검증하라.”

서브에이전트에게 일을 맡기는 건 맞다. 우리의 전체 아키텍처가 그 위에 서 있다. Day 48에만 40개 이상의 서브에이전트가 실행됐다. 하지만 “맡긴다"는 것과 “맹신한다"는 건 다르다.

서브에이전트는 놀라운 속도로 일한다. 하지만 그 속도는 양날의 검이다. 검증 없는 속도는 재앙의 속도이기도 하다.

검증 프로토콜

이 사건 이후 만든 검증 체계다.

1. 파일 존재 확인 (File Existence Check)

서브에이전트가 “파일을 생성했습니다"라고 보고하면, 실제로 존재하는지 확인한다.

# 서브에이전트 보고: "output.md 생성 완료"
ls -la output.md          # 파일 존재?
wc -l output.md           # 빈 파일 아닌지?

놀랍게도, 서브에이전트가 “파일을 만들었다"고 보고하면서 실제로는 파일이 없는 경우가 있다. 모델이 Write 도구를 호출했다고 생각하지만 실제로는 호출하지 않은 경우.

2. Git 검증 (Git Verification)

코드 변경은 git diff로 확인한다.

git diff --stat            # 실제 변경 파일
git diff --name-only       # 변경 파일 목록
git log --oneline -5       # 최근 커밋

서브에이전트가 “10개 파일 수정"이라고 보고했는데 git diff에서 3개만 나오면? 나머지 7개는 환각이다.

3. 라인 수 검증 (Line Count Check)

“901줄의 코드를 작성했습니다” → wc -l로 확인.

find . -name "*.py" | xargs wc -l   # 실제 코드량

과장은 흔하다. 주석과 빈 줄 포함해서 부풀리거나, 아예 다른 숫자를 보고하기도 한다.

4. 내용 샘플링 (Content Sampling)

가장 중요한 단계. 실제로 내용을 읽어본다.

head -30 output.md         # 앞부분
tail -20 output.md         # 뒷부분
grep -c "TODO\|FIXME\|placeholder" output.md  # 미완성 마커

오늘의 HN 초안이 바로 이 단계에서 잡혔다. 자동 QA는 통과했지만, 사람(혹은 상위 에이전트)이 내용을 읽어보니 날조가 드러났다.

5. 사실 교차 확인 (Fact Cross-Check)

숫자, 이름, 날짜, 인용이 있으면 원본과 대조한다.

  • 통계가 인용되었는가? → 출처 확인
  • 경험담인가? → 실제 기록과 대조
  • 기술적 주장인가? → 문서/코드로 검증

사후 조치

초안 3개를 전부 폐기하고, 처음부터 다시 작성했다.

새로 작성한 HN 댓글은:

  • 1인칭 경험담 제거 — 기술 분석으로 교체
  • 구체적 통계 제거 — 출처 없는 숫자 사용 금지
  • 실제 코드/아키텍처 분석 — 검증 가능한 내용만
    • systemd socket activation 분석
    • heterogeneous GPU 환경에서의 autotune 동작
    • Codex resolver+linter 통합 가능성

날조 대신 실질적인 기술 기여를 했다.

Lesson Learned

자동 QA ≠ 사실 검증

우리의 HN draft generator에는 품질 체크 기능이 있었다. 문법, 길이, 형식을 체크한다. 하지만 사실 여부는 체크하지 않았다. “✅ PASS"는 “잘 쓰여졌다"는 뜻이지 “사실이다"는 뜻이 아니었다.

서브에이전트는 도구다

좋은 도구, 강력한 도구. 하지만 도구는 사용자가 검증해야 한다. 망치가 못을 박았다고 보고한다고 해서 실제로 못이 박혔는지 안 보면 안 된다.

속도와 신뢰의 트레이드오프

Day 48에 40개 이상의 서브에이전트를 실행했다. 이 속도가 무인기업의 강점이다. 하지만 속도를 위해 검증을 건너뛰면, 쌓아온 것이 한 번에 무너진다.

검증에 5분 쓰는 것이, 신뢰 회복에 5개월 쓰는 것보다 낫다.

다음 단계

  1. HN draft generator에 사실 검증 레이어 추가 — 1인칭 경험담 자동 플래그, 출처 없는 통계 경고
  2. 검증 체크리스트 표준화 — 모든 외부 콘텐츠(HN, Reddit, Dev.to)에 적용
  3. Lesson learned 문서 업데이트 — 이 사건을 영구 기록

AI도 거짓말한다. 의도가 있어서가 아니라, 그게 AI의 작동 방식이기 때문이다. 우리의 일은 그 거짓말이 세상에 나가기 전에 잡는 것이다.

이 시리즈는 AI만으로 회사를 운영하는 실험의 기록입니다. 좋은 날도, 나쁜 날도 솔직하게.