모든 테스트는 8년 된 MacBook Air에서 실행되었습니다.

코드베이스 파일을 한꺼번에 LLM에 전달하여 모든 버그를 찾아내게 하려고 시도했던 이야기.

결과: 전혀 안 됐다. 어떤 일이 일어났는지, 그리고 어떻게 해결했는지를 작성한다.

검증 환경

Claude Opus 4.7과 Gemini 3.5 Flash를 thinking 모드(추론 모드)를 활성화하여 검증. 태스크는 Rust (Tauri v2)의 멀티 파일 코드베이스 버그 찾기. 언어와 상관없이 동일한 현상이 발생할 것이라 생각한다.

실제로 어떤 일이 일어났는가

모델은 크래시(Crash)되지 않는다. 에러도 발생하지 않는다. 자신만만하게 답변을 돌려준다. 문제는 그 답변이 틀렸다는 것이다. 그리고 코드베이스를 제대로 이해하고 있지 않으면, 그 오류를 알아차릴 수 없다.

이 부분이 가장 중요한 점이라고 생각한다: AI의 출력은 검증하는 측의 지식 수준에 의존한다. 100개의 파일을 전달하고 "버그 없음"이라는 답변을 받았을 때, 그것이 거짓이라는 것을 어떻게 알아차릴 것인가.

Claude Opus 4.7:

• 5개 파일 이내: 정밀도가 높다. 정말 우수하다.
• 10개 파일 초과: 의심스러워지기 시작한다. 놓치는 부분이 늘어난다.
• 15개 파일 (src-tauri에서 실제로 확인): 할루시네이션 (Hallucination) 다발.

Gemini 3.5 Flash:

• 1개 파일·300행 이내: 간신히 사용할 수 있다. 지시서가 정확하다면 간단한 로직은 수행할 수 있다.
• 여러 파일: 금방 붕괴한다. 지시서의 질에 크게 의존하기 때문에, 동일한 태스크라도 결과에 편차가 생기기 쉽다.

둘 다 thinking 모드를 사용했음에도, 명백히 버그가 있는 코드에 대해 "버그 없음"이라고 답변했다.

왜 이렇게 되는가: Lost in the Middle

**"Lost in the Middle"**라고 불리는 현상이 원인이다.

LLM은 인간처럼 컨텍스트 (Context)를 선형적으로 읽는 것이 아니다. 거대한 컨텍스트 윈도우 (Context Window)의 중간 부분에 대한 주의력(Attention)이 현저히 저하된다.

15개의 파일을 전달하면, 모델은 기술적으로는 전부 "보고" 있다. 하지만 실제로는 중간에 있는 파일들을 거의 무시하고 있다.

중요한 구분: thinking 모드는 추론의 깊이를 높이지만, 정보 누락 문제는 해결하지 못한다.

컨텍스트 윈도우가 넓다고 해서 ≠ 전부 제대로 읽을 수 있는 것은 아니다.

해결책: 1개 파일씩 전달하기

경험칙을 통해 도달한 방법: 파일을 하나씩 전달한다.

# NG:
"100개의 파일이 있습니다. 모든 버그를 찾아주세요"
# OK:
...

번거로운가? 그렇다. 하지만 정밀도는 차원이 다르게 올라간다.

Opus는 1회 요청당 5개 파일 이내가 안전선이다. Gemini는 1개 파일 300행 이내가 한계다.

요약

대량 입력에서의 "버그 없음"은 신뢰하지 말 것 — 모델이 단순히 놓치고 있을 가능성이 높다
thinking 모드는 추론을 깊게 하지만, 전부 읽는다는 보장은 아니다
컨텍스트 윈도우의 크기는 마케팅이다. 실용적인 유효 범위는 훨씬 좁다

• 고민된다면 태스크를 작게 분할할 것

거대한 컨텍스트 윈도우는 보기에는 좋다. 하지만 실제로 신뢰할 수 있는 출력을 얻을 수 있는 범위는 광고보다 훨씬 작다.

해결책은 더 좋은 모델이 아니라, 더 좋은 워크플로우 (Workflow)이다.

진행 상황은 X에서 발신 중: @hiyoyok

Discussion