사이드 프로젝트를 위한 새로운 모듈을 구축하고 있었는데, 설계 문서(design document)가 매우 철저해 보였습니다. Claude가 작성했고 제가 검토했으며, 모든 것이 합리적으로 보였습니다. 한 섹션에는 두 개의 저장된 필드로부터 파생된 값을 계산하는 방법이 설명되어 있었습니다. 두 필드 모두 소수점 두 자리를 보존하기 위해 100이 곱해진 상태였으며, 다음과 같은 공식이 제시되었습니다.

Result = fieldA × 100 × fieldB × 100 / 10000

표면적으로는 논리가 맞았습니다. 두 필드 모두 100배의 정밀도(precision)를 가지고 있으므로, 나누는 수(divisor)가 이를 상쇄할 것이라고 생각했습니다. DeepSeek이 이를 구현했습니다. 검토 에이전트(review agent)가 이를 검증했습니다. 제가 승인했습니다. 그러고 나서 시뮬레이터를 열었을 때, 1,200이어야 할 값이 120,000으로 표시되는 것을 보았습니다.

공식이 100배 차이로 틀렸습니다

올바른 나누는 수는 10,000이 아니라 1,000,000이었습니다. 각각 100배로 부풀려진 두 필드를 곱하면, 그 곱은 10,000배로 부풀려집니다. 따라서 기본 단위(base units)로 되돌리려면 10,000이 아니라 1,000,000으로 나누어야 합니다. 설계 문서가 이 부분을 틀렸고, 그 이후의 모든 단계(downstream)가 그 실수를 충실히 재현했습니다.

그 부분을 발견했을 때 수정하는 것은 쉬웠습니다. 하지만 그 이후로 제가 계속 생각했던 것은 실패한 프로세스였습니다.

세 시스템이 동일한 틀린 공식을 읽었습니다

그 공식을 읽는 인간 엔지니어라면 아마도 본능적인 행동을 할 것입니다. 바로 실제 숫자를 대입해 보는 것입니다. 각각 '정수 × 100'으로 저장된 두 수치를 가정해 봅시다. fieldA = 10000이고 fieldB = 1200이라고 한다면, 곱하면 12,000,000이 됩니다. 이를 10,000으로 나누면 1,200이 됩니다. 하지만 기대되는 결과값은 12여야 합니다. 계산이 맞지 않습니다. 이 오류는 형식적 검증(formal verification)을 통해서가 아니라, 공식을 믿기 전에 빠르게 건전성 검사(sanity check)를 수행하는 습관을 통해 약 5초 만에 드러납니다.

제 워크플로우에 있는 세 가지 시스템 중 그 어느 것도 이 작업을 수행하지 않았습니다. DeepSeek는 설계 문서(design document)를 읽고 작성된 대로 공식을 정확히 구현했습니다. 리뷰 에이전트(review agent)는 구현 내용이 설계와 일치하는지 확인했고, 일치함을 확인했습니다. 저는 두 가지를 모두 읽고 승인했습니다. 모든 문장은 기술적으로 정확했습니다. 문서는 진실의 근원(source of truth)이었고, 코드는 문서를 충실히 구현했으며, 리뷰는 그 일치 여부를 검증했습니다. 아무도 수치를 직접 계산해 보지 않았습니다.

내가 해왔던 가정

제수(divisor)를 수정한 후, 저는 실제로 무엇이 실패했는지에 대해 생각하기 시작했습니다. 그것은 수학이 아니었습니다. 수학적 오류는 주의 깊게 살펴보니 사소한 것이었습니다. 실패한 것은 AI 보조 개발(AI-assisted development)이 어떻게 작동하는지에 대해 제가 해왔던 더 깊은 가정이었습니다.

저는 설계 문서를 검증된 산출물(verified artifacts)로 취급해 왔습니다. 제 머릿속의 워크플로우는 다음과 같았습니다:

설계 문서 (Design Document) → AI 구현 (AI Implementation) → AI 리뷰 (AI Review) → 인간 승인 (Human Approval)

이 워크플로우에 내재된 암묵적인 가정은 설계 문서 자체가 정확하다는 것이었습니다. 만약 그렇지 않다면, 전체 체인은 오류를 충실히 재현하게 될 것이며, 그것이 바로 실제로 일어난 일이었습니다.

문서는 입력값이 아닙니다. 그것은 주장입니다.

설계 문서는 검증된 사실이 아닙니다. 그것은 작성한 사람이 내놓은 주장(claim)이며, 이 경우에는 Claude가 작성했습니다. Claude는 일관성 있고 그럴듯해 보이는 기술 문서를 생성하는 데 매우 능숙합니다. 하지만 그 문서에 포함된 수학이 실제로 정확한지 검증하는 능력은 상당히 떨어집니다. 저는 Claude에게 아키텍처(architecture)에 대해 추론하는 것과 산술(arithmetic)을 검증하는 것, 이 두 가지를 동시에 수행하도록 요청해 왔습니다. Claude가 이 두 가지 책임을 매우 다르게 처리한다는 점을 인식하지 못한 채 말입니다. Claude는 첫 번째는 잘 해냈지만, 두 번째는 서툴렀습니다. 그리고 저는 이 둘을 분리해야 한다는 생각을 하지 못했습니다.

제가 내린 결론은 간단합니다. 설계 문서(design document)에 있는 모든 공식은 누군가가 구체적인 숫자를 대입하고 수동으로 결과를 확인하기 전까지는 검증되지 않은 것으로 간주하는 것입니다. 이는 AI가 공식을 자주 틀리기 때문이 아니라, AI가 실수를 했을 때 그 오류가 모든 후속 단계(downstream step)를 통해 깨끗하고 보이지 않게 전파되기 때문입니다. 공식이 틀리면 구현도 틀리고, 리뷰는 구현이 공식과 일치함을 확인하며, 모든 것이 일관성을 유지합니다. 모든 것이 틀린 상태로 말입니다.

코드는 원래 의도한 대로 정확히 작동했습니다

AI가 생성한 코드에서 발생하는 대부분의 버그는 구현 버그(implementation bugs)입니다. 조건이 반전되어 있거나, null 체크가 누락되었거나, 예외 케이스(edge case)를 처리하지 못한 경우와 같은 것들입니다. 이는 코드가 의도(intent)를 올바르게 구현하지 못한 실패 사례입니다. 하지만 이번 사례는 달랐습니다. 코드는 의도를 완벽하게 구현했습니다. 다만 그 의도가 틀렸을 뿐입니다. 이러한 범주의 오류는 코드 리뷰(code review)로 잡아내기가 훨씬 더 어렵습니다. 왜냐하면 코드 리뷰는 코드가 '해야 할 일을 제대로 하고 있는지'를 묻기 때문입니다. 이 경우 대답은 '예'였습니다. 아무도 그 '해야 할 일' 자체가 실제로 맞는지에 대해서는 묻지 않았습니다.

구현뿐만 아니라 명세(specification)가 옳은가 하는 이 질문이야말로, AI 보조 워크플로우(AI-assisted workflow)에서 인간의 판단이 가장 중요해지는 지점이라고 저는 생각합니다. AI는 명세를 작동하는 코드로 변환하는 데 상당히 능숙해지고 있습니다. 구현 버그를 잡아내는 데도 제법 능숙해지고 있습니다. 하지만 AI는 명세 자체를 기정사실(ground truth)로 취급하는 경향이 있으며, 이는 애초에 명세가 타당한지 의문을 제기하는 작업은 여전히 전적으로 당신의 몫임을 의미합니다. AI는 당신이 주는 것이 무엇이든 점점 더 높은 신뢰도로 구현해낼 것입니다. 문제는 당신이 준 것이 맞느냐 하는 것입니다.

그리고 현재로서는, 그 부분은 여전히 당신의 책임입니다.