17개 스마트 컨트랙트, 각각 2번의 변환, 수십 개의 검증 항목. 결과는 전부 초록불이었습니다. 그런데 코드는 틀려 있었습니다.
비주얼 플로우를 Solidity 스마트 컨트랙트로 변환하는 툴 Doodledapp 팀이 AI 기반 자동 테스팅 루프를 구축한 경험을 공유했습니다. 실제 프로덕션에서 쓰이는 OpenZeppelin ERC-20, Uniswap V2/V3 등 17개 컨트랙트를 대상으로 AI에게 테스트를 작성하게 했고, 첫 실행에서 모든 테스트가 통과했습니다. 하지만 바로 그 순간, 뭔가 크게 잘못됐다는 걸 깨달았습니다.
출처: AI made every test pass. The code was still wrong. – Doodledapp
AI는 “있는 코드”를 테스트한다, “원하는 코드”가 아니라
AI는 컨버터 코드를 읽고, 그것이 실제로 하는 동작을 확인하는 테스트를 작성했습니다. 함수가 변환되는지, 상태 변수가 출력에 나타나는지, 제어 흐름 구조가 있는지. 모든 검증이 기술적으로는 옳았습니다. 컨버터는 실제로 그런 일을 하니까요.
문제는 테스트가 단 한 번도 “변환 결과가 원본과 같은 일을 하는가?”를 묻지 않았다는 겁니다. 버그가 modifier를 조용히 누락시키는 코드라면, AI는 modifier가 누락되는 코드를 읽고 “modifier가 누락되는 게 맞다”는 테스트를 작성합니다. 테스트는 통과하고, 버그는 보이지 않습니다.
연구자들은 이를 Ground Truth 문제라고 부릅니다. 올바른 동작이 무엇인지 알고 있는 무언가가 있어야 한다는 것입니다. 사람이 테스트를 작성할 때는 코드가 무엇을 해야 하는지에 대한 이해를 갖고 씁니다. 하지만 AI가 코드만 보고 테스트를 작성할 때는 독립적인 기준점이 없습니다. 코드 자체가 대상이자 명세(specification)가 되어버립니다.
앨버타 대학교의 2024년 연구도 같은 결론을 냈습니다. LLM이 생성한 테스트 검증문은 명세된 동작이 아닌 구현된 동작을 기준으로 작성된다는 것입니다. 테스트는 문법적으로 유효하고, 실행되고, 통과합니다. 그리고 버그를 보호합니다.
“일관성”을 증명했을 뿐, “정확성”은 아니었다
첫 번째 접근 방식의 또 다른 함정은 비교 구조에 있었습니다. 팀은 각 컨트랙트를 컨버터로 1회 변환해 정규화한 뒤, 그 출력을 다시 한번 변환해 두 결과가 일치하는지 확인했습니다.
그런데 컨버터가 1차 변환에서 modifier를 누락시키면, 이미 망가진 출력이 “정규화된 기준”이 됩니다. 2차 변환도 같은 망가진 결과를 냅니다. 1차 = 2차, 테스트 통과. 이건 일관성(idempotency)만 증명한 것이지, 정확성(correctness)을 증명한 게 아닙니다.
팀은 방식을 완전히 바꿨습니다. 원본 컨트랙트를 기준점으로 삼고, 문자열 비교 대신 AST(추상 구문 트리) 수준에서 비교하는 방식으로 전환했습니다. 코드의 생김새가 아니라 논리적 구조가 살아남았는지를 보는 것입니다.
흐름은 이렇습니다. 원본 컨트랙트를 AST로 파싱 → 비주얼 플로우로 변환 → 다시 Solidity로 역변환 → 결과를 AST로 파싱 → 두 AST를 비교. 구조가 다르면 AI에게 “뭐가 틀렸는지 분석해줘”라고 묻고, 컨버터를 수정한 뒤 다시 돌립니다.
이 루프는 실제로 작동했습니다. AI는 더 이상 코드로부터 테스트를 쓰는 게 아니라, 알고 있는 정답(원본)과 컨버터 출력 사이의 구체적인 구조 차이를 분석하는 역할을 맡게 됐습니다. 기준점이 생기자 AI는 누락된 modifier, 잘못된 연산자 우선순위, 손상된 상속 체인 같은 실제 버그를 찾아냈습니다.
AI 코딩 도구의 진짜 한계
이 경험이 드러낸 건 특정 AI 도구의 결함이 아닙니다. AI가 코드를 대하는 방식의 구조적 특성입니다. AI는 코드가 무엇을 하는지 이해하는 데 뛰어납니다. 하지만 코드가 무엇을 해야 하는지는, 외부 기준점을 주지 않으면 알 수 없습니다.
“테스트가 통과했는가?”보다 더 중요한 질문은 “테스트가 무엇과 비교하고 있는가?”입니다. 만약 답이 “코드 자체”라면, 그 테스트 스위트는 거울입니다. 당신이 만든 것을 그대로 비춰주면서 잘 됐다고 말해줄 뿐입니다.
답글 남기기