들어가며
AI 코딩 도구(Claude Code, Devin 등)를 실무에서 적극 활용하면서 한 가지 예상치 못한 문제를 발견했다. AI가 코드베이스의 로그 메시지를 "사실"로 받아들여, 잘못된 방향으로 문제를 진단하는 현상이다.
로그가 말하는 것 vs 실제로 일어나는 것
로그는 작성자의 가설이다
로그 메시지는 코드를 작성한 사람이 "이 시점에 이런 일이 일어날 것"이라고 가정한 내용이다. 하지만 시스템이 복잡해지면 그 가설이 틀릴 수 있다.
예를 들어, 분산 스트리밍 환경에서 이런 로그가 있다고 가정하자:
이 로그는 "A가 누락된 것"이라고 단정하고 있다. 하지만 실제로는 A가 생성되었으나, 병렬 처리 과정에서 B보다 늦게 도착한 것일 수 있다. 즉, 누락이 아니라 순서 역전이다.
사람도 속고, AI도 속는다
사람은 이런 로그를 보면 "아, A가 누락되는구나"라고 생각하고 누락 방지 로직을 추가하려 한다. AI도 마찬가지다. 코드베이스에서 이 로그를 발견하면 "A 누락" 전제 하에 해결책을 제안한다.
문제는, AI는 로그 메시지를 의심할 동기가 없다는 것이다. 코드에 적혀 있으면 그것이 사실이라고 판단한다. 이것이 AI 에이전트의 확증 편향이다.
왜 위험한가
1. AI가 잘못된 전제 위에 해결책을 쌓는다
"A 누락"이라는 전제가 틀렸는데, AI는 이 전제 위에 복잡한 해결책을 제안한다. State 저장, TTL 설정, 재시도 로직 등 — 근본 원인과 무관한 코드가 추가된다.
2. 디버깅 시간이 늘어난다
AI의 제안을 따라 구현한 뒤에도 문제가 해결되지 않으면, "AI가 제안한 방향이 맞는데 구현이 잘못된 건가?"라고 생각하게 된다. 잘못된 전제를 의심하기까지 시간이 더 걸린다.
3. 로그가 또 다른 잘못된 로그를 낳는다
AI가 추가한 코드에 또 잘못된 가설의 로그가 포함되면, 이후에 같은 문제를 디버깅할 때 또 같은 함정에 빠진다.
어떻게 대응할 것인가
1. 로그 메시지를 "가설"이 아니라 "사실"로 작성하라
로그에 원인을 단정하지 말고, 관찰된 사실만 기록하라.
"lost"(잃어버렸다)와 "not yet observed"(아직 관찰되지 않았다)는 큰 차이다. 후자는 순서 역전 가능성을 열어둔다.
2. AI에게 맡기기 전에 로그 정합성을 확인하라
AI 에이전트에게 트러블슈팅을 맡기기 전에, 관련 로그가 기술적으로 정확한지 먼저 검증하라. 부정확한 로그가 있으면 AI가 잘못된 방향으로 갈 확률이 높다.
3. AI의 진단을 의심하라 — 특히 "로그에 의하면"이라고 할 때
AI가 "로그에 의하면 A가 누락되고 있으므로..."라고 말하면, 그 로그 자체가 맞는지 먼저 확인하라. AI는 로그를 의심하지 않으므로, 사람이 그 역할을 해야 한다.
결론
AI 코딩 도구는 코드베이스에 있는 정보를 기반으로 판단한다. 로그 메시지도 그 정보의 일부다. 로그가 부정확하면 AI도 부정확한 방향으로 간다.
로그 정합성은 AI 활용의 전제 조건이다. AI를 잘 쓰려면, AI가 참고할 데이터를 먼저 정리해야 한다.
이것은 비단 로그에만 해당하는 이야기가 아니다. 주석, README, 문서 — AI가 참고하는 모든 텍스트가 정확해야 AI의 아웃풋도 정확해진다.
