그래도 PoC는 쓴다
Cantina가 PoC를 필수로 바꿨을 때 솔직히 불만이었습니다. 1년 동안 경쟁에 참가하고 심사도 하고, AI가 만든 리포트가 쏟아지는 걸 보면서 지금은 이게 오딧 경쟁에서 가장 쓸모 있는 규칙이라고 생각합니다.
Cantina가 모든 취약점 제출에 PoC(Proof of Concept)를 요구하겠다고 발표했을 때 저는 불만이었습니다. 복잡한 프로토콜에서, 그것도 프로젝트 팀의 안내 없이 PoC를 작성하는 데는 시간이 많이 듭니다. PoC에 쓰는 시간은 다음 버그를 찾는 데 쓰지 못하는 시간이니까요.
지금은 생각이 바뀌었습니다. 필수가 아닌 곳에서도 제출하는 버그에는 거의 다 PoC를 씁니다.
PoC가 실제로 주는 것
먼저 제출하기 전에 오탐을 걸러 줍니다. "유효해 보이는" 이슈 중 상당수는 실제로 돌려 보는 순간 무너집니다. Pump.fun 경쟁에서는 이런 흐름이 익숙했습니다.
- 유효해 보이는 이슈를 찾는다 (여섯 자리 보상을 상상한다).
- PoC를 쓰기 시작한다.
- 동작하게 만드는 데 실패한다.
- 체인 설계 자체가 그 공격을 막고 있다는 걸 깨닫는다.
이걸 계속 반복합니다. 괴롭긴 해도 심사자에게 듣는 것보다는 훨씬 낫습니다.
다른 버그가 보이기도 합니다. 동작하는 익스플로잇을 만들려면 평소라면 대충 넘길 코드 경로를 하나하나 따라가야 합니다. 꽤 괜찮았던 발견 중 몇 개는 다른 이슈의 PoC를 쓰다가 이상한 점을 눈치챈 데서 나왔습니다.
리포트에 반박할 여지도 줄어듭니다. 테스트를 직접 돌려 볼 수 있으니 심사자가 제 추론을 믿어 줄 필요가 없습니다.
심사자 자리에서 본 것
2025년 초부터 Cantina에서 경쟁 심사를 맡고 있습니다. 연구할 때와는 전혀 다른 일입니다. 수백 건의 제출물을 놓고 "이 리포트가 주장하는 걸 증명하고 있나?"를 하나하나 따져야 합니다. 연구할 때 던지던 "버그가 있나?"와는 다른 질문입니다.
지난 1년 동안 LLM이 쓴 게 분명한 리포트가 점점 늘었습니다. 자신만만하고 형식도 깔끔한데 내용이 틀렸습니다. 그럴듯한 공격을 설명하지만 실제 코드에서는 그 공격이 성립하지 않습니다.
PoC 필수 규칙은 효과가 있습니다. 이 규칙이 없는 경쟁에서는 LLM이 쓴 것처럼 보이는 리포트의 비율이 훨씬 높습니다.
PoC는 우리가 가진 가장 값싼 필터입니다. 모델은 그럴듯한 문단을 쉽게 만들어 냅니다. 하지만 실제 코드베이스에서 통과하는 익스플로잇 테스트를 만들기는 훨씬 어렵습니다.
AI를 반대하는 게 아니다
AI는 오딧에 정말 유용하고 저도 매일 씁니다. 자동화 도구와 AI를 활용한 워크플로가 이미 경쟁에서 실제 버그를 찾고 있습니다. 업계에 좋은 일입니다.
다만 그만큼 그럴듯해 보이는 리포트도 계속 늘어날 겁니다. 그러니 증거를 요구하는 기준은 낮추면 안 됩니다. AI로 버그를 찾았다면 PoC를 쓰는 데도 AI를 활용하세요.
제출 전 체크리스트
- PoC가 수정한 사본이 아니라 범위 안의 커밋에서 동작하는가.
- 단순히 예상 밖의 상태가 아니라 실제 영향(자금 손실, 불변식 위반)을 보여 주는가.
- 역할과 신뢰에 대한 가정을 명시했는가. "그건 신뢰된 주체다(That is trusted)"는 흔한 기각 사유라서 미리 다룹니다.
- 동작하게 만들 수 없다면 제출하기 전에 이유를 먼저 확인했는가.
