증명의 무게와 운영의 속도: verified polygon intersection을 실무 선택지로 읽는 법

출처: Hacker News — https://github.com/schildep/verified-polygon-intersection

경계 조건 하나가 계약 분쟁으로 번지는 시스템에서는, "대부분 맞는다"는 말이 생각보다 약하다.

이번 Hacker News 글이 실무자에게 던지는 포인트는 AI 모델이 얼마나 영리해졌는지보다 훨씬 더 구체적이다. 저장소 설명과 RSS 본문을 기준으로 보면, 이 사례의 중심에는 "LLM이 맞다고 해서 믿는 것이 아니라 Lean checker와 사람이 읽을 수 있는 작은 specification을 믿는다"는 태도가 있다. 작성자는 이것을 폴리곤 교차 알고리즘의 형식 검증 사례로 소개하고, web demo에는 multipolygon, holes, self intersections, overlapping edges 같은 조건을 지원한다고 적었다. 또 최근 모델 릴리스 이후에는 proof strategy를 사람이 잘게 쪼개서 밀어주지 않아도 한 번에 더 큰 단위의 구현과 증명을 생성할 수 있었다는 경험을 함께 말한다.

여기서 실무 관점의 핵심은 두 갈래다. 하나는 "무엇이 검증되었는가"이고, 다른 하나는 "무엇은 여전히 검증 바깥에 남는가"다. 이 구분이 없으면 이 뉴스를 과대평가하거나, 반대로 너무 빨리 흘려보내기 쉽다. 실제로 저장소는 correctness의 신뢰를 LLM이 아니라 checker와 작은 spec review에 둔다고 선을 긋는다. 동시에 작성자는 이런 방식이 느리거나 practical consideration을 놓치기 쉽다는 한계도 직접 언급한다. 즉, 이 사례는 "형식 검증이 모든 것을 해결한다"는 선언이 아니라, "복잡한 로직의 신뢰 경계를 훨씬 작은 표면으로 줄이는 방식이 가능해지고 있다"는 신호에 가깝다.

이걸 뉴스로만 읽으면 놓치는 것

겉으로 보기에는 "Opus 4.8이 이제 oneshot으로 formal proof를 만든다"는 이야기가 전면에 보인다. 하지만 저장소 설명을 조금만 더 들여다보면 진짜 실무 포인트는 AI capability 자체보다 검토 구조의 이동이다. 예전에는 사람이 proof strategy를 쪼개서 공급해야 했다면, 최근에는 더 큰 전략을 모델이 자율적으로 구성할 수 있었다는 경험담이 나온다. 그런데도 최종 신뢰는 모델이 아니라 Lean checker에 맡긴다. 이 조합은 중요하다. 생성 능력은 가속 수단이고, 신뢰 근거는 별도의 기계적 검증 체계에 둔다는 뜻이기 때문이다.

실무에서 이 구조가 의미 있는 이유는 리뷰 비용 때문이다. 복잡한 geometry 구현은 테스트 케이스를 수백 개, 수천 개 쌓아도 "아직 만나지 못한 이상한 모양"이 남는다. 특히 hole, self intersection, overlapping edge가 섞이면 정상처럼 보이는 알고리즘도 특정 경계에서 깨지기 쉽다. 반면 형식 검증 접근은 사람이 모든 구현 디테일을 따라가지 않아도, 더 작은 명세와 정리된 보장 범위를 중심으로 신뢰를 구성할 수 있다. 저장소가 굳이 "사람이 읽어야 하는 파일은 작다"는 점을 강조하는 것도 이 맥락으로 읽는 편이 맞다.

비교의 출발점을 바꿔야 한다

이 사례를 평가할 때 비교 대상은 "AI를 썼느냐 안 썼느냐"가 아니다. 실무에서 실제로 경쟁하는 선택지는 대체로 세 가지다.

첫째는 formally verified core를 직접 쓰거나 채택하는 선택지다.
둘째는 일반적인 geometry 구현에 테스트, property-based test, fuzzing, 회귀 케이스를 겹치는 선택지다.
셋째는 빠른 일반 구현을 주 경로로 두고, 별도의 reference path나 검산 코어를 곁들이는 하이브리드 선택지다.

이 세 가지는 모두 "틀리지 않게 만들자"를 목표로 하지만, 비용이 드는 위치와 실패하는 방식이 다르다. 그래서 비교 기준도 기능 목록이 아니라 실패 비용, 검토 가능성, 성능 요구, 팀의 유지보수 역량을 중심으로 잡는 것이 더 정확하다.

선택지 1: formally verified core를 앞세우는 경우

이번 사례가 가장 강하게 보여주는 선택지는 이쪽이다. 저장소 설명 기준으로 보면, 구현과 proof는 Lean으로 검증되고 correctness 신뢰는 checker에 둔다. 또한 verified core를 바탕으로 web demo까지 연결했다는 점은 "연구 artifact"에 머물지 않고 실제 동작하는 데모까지 잇는 방향성을 보여준다.

이 선택지의 가장 큰 장점은 희귀한 edge case에 대한 신뢰 방식이 다르다는 점이다. 테스트 중심 접근은 결국 관찰된 입력과 상상 가능한 입력에 크게 의존한다. 반면 형식 검증은 명세가 허용하는 모든 입력에 대해 특정 성질을 보장하려 한다. 폴리곤 교차처럼 조합 폭이 사실상 무한한 문제에서는 이 차이가 아주 크다. 저장소도 바로 그 점을 강조한다. 입력 구성은 무한하고, 내부 집합의 의미도 단순한 예제 테스트만으로는 다루기 어렵기 때문에, 형식적으로 interior set과 intersection의 관계를 잡는 것이 가치 있다는 논리다.

또 하나의 장점은 검토 표면을 줄일 수 있다는 데 있다. 사람이 복잡한 최적화 구현 전체를 끝까지 읽는 대신, 더 작은 specification과 theorem interface를 점검하는 구조는 조직 차원에서 재현성이 좋다. 고위험 로직에서 이건 꽤 강력한 이점이다. "누가 이 거대한 구현을 다 이해했나" 대신 "우리가 믿는 속성이 무엇인지, 그리고 checker가 그것을 어디까지 보장하는지"를 중심으로 대화할 수 있기 때문이다.

하지만 이 선택지는 강점만 있는 것이 아니다. 저장소 작성자 스스로도 formal verification을 강하게 밀면 느린 코드나 practical consideration을 덜 반영한 코드가 나오기 쉽다고 적었다. 이 지점은 과소평가하면 안 된다. correctness를 강하게 확보하는 대신, 성능 최적화, 메모리 사용량, 구현 단순성, 외부 환경 통합성은 별도 문제로 남을 수 있다. 다시 말해 "증명된 정답"과 "운영 가능한 정답"은 같은 문장이 아니다.

또한 팀 역량 문제도 크다. Lean이나 proof assistant 체계를 이해하고 유지할 사람이 없으면, 초기 도입의 기술적 성취와 별개로 장기 운영 비용이 급격히 커질 수 있다. 이번 프로젝트는 데모와 코어를 잇는 흐름을 보여주지만, 일반 조직에서 이 모델을 그대로 받아들이려면 proof tooling, build chain, reviewer skillset까지 같이 따라와야 한다.

이 선택지는 이런 상황에 더 어울린다.

• 결과 오류의 비용이 매우 큰 경우
• rare edge case가 실제 장애나 법적 리스크로 번질 수 있는 경우
• 성능보다 설명 가능한 correctness가 우선인 경우
• 팀이 명세를 작게 고정하고 검토하는 문화를 받아들일 수 있는 경우

반대로 이런 상황에는 곧바로 주력 선택지가 되기 어렵다.

• 요구사항 자체가 자주 바뀌는 초기 제품 단계
• hot path의 latency budget이 매우 빡빡한 경우
• 조직 내에서 proof 기반 유지보수 역량을 확보하기 어려운 경우

선택지 2: 전통적인 구현 + 테스트를 더 강하게 가져가는 경우

대부분의 팀이 실제로 선택하는 길은 이쪽이다. 성숙한 geometry library를 붙이거나 자체 구현을 만들고, 예제 테스트, 회귀 테스트, fuzzing, property-based testing으로 품질을 올린다. 이 접근의 장점은 명확하다. 생태계가 넓고, 통합이 쉽고, 성능 최적화 경험도 풍부하다. 운영팀과 제품팀이 이미 익숙한 도구로 일할 수 있고, 팀원이 바뀌어도 지식 이전이 비교적 수월하다.

이 방식은 특히 오류가 치명적이지 않고 복구 가능할 때 강하다. 예를 들어 결과가 조금 이상해도 사용자가 수동 보정할 수 있거나, UI 상에서 재편집이 가능하거나, 내부 백오피스 검토가 한 번 더 들어가는 구조라면 형식 검증보다 테스트 축적이 더 현실적인 선택일 수 있다. 또 성능이 사업성의 핵심인 경우, 검증보다 최적화된 구현과 운영 안정성이 우선 순위를 가져간다.

하지만 약점도 분명하다. geometry는 버그가 잘 숨어드는 분야다. 이번 저장소 설명에서도 드러나듯, overlapping segments나 hole이 얽힌 케이스에서는 "어떤 경계 조각을 어떤 폐곡선으로 묶을 것인가" 같은 문제가 생각보다 복잡하다. 테스트를 많이 한다고 해서 이 복잡성이 선형으로 줄어들지는 않는다. 오히려 테스트 세트는 점점 커지는데, 조직의 심리적 자신감만 커지고 진짜 보장 수준은 애매하게 남는 경우가 있다.

이 선택지는 이런 상황에 적합하다.

• 성능과 생태계 통합성이 correctness의 절대치보다 중요할 때
• 이미 검증된 외부 라이브러리와 운영 경험이 충분할 때
• 오류 복구 비용이 낮고 사용자 보정 경로가 있을 때
• 팀이 빠르게 반복 출시해야 할 때

반례도 있다. "테스트를 잘하면 충분하다"는 태도는 금융 계산, 정책 엔진, geometry kernel처럼 edge case가 제품 신뢰를 깨는 영역에서는 지나치게 낙관적일 수 있다. 테스트가 많다는 사실이 보장의 강도를 자동으로 설명해주지는 않기 때문이다.

선택지 3: 검산용 reference path를 두는 하이브리드 구조

실무적으로는 이 세 번째가 가장 넓은 조직에 맞을 가능성이 높다. 주 처리 경로는 일반 구현이나 고성능 라이브러리로 유지하되, 중요한 순간에는 별도의 더 엄격한 코어로 검산하거나 결과를 샘플링해서 대조하는 방식이다. 꼭 완전한 formally verified implementation일 필요는 없다. 하지만 이번 사례를 응용하면, 사람이 신뢰할 수 있는 작은 spec과 checker 기반 코어를 "truth anchor"처럼 둘 수는 있다.

이 구조의 장점은 정확도와 속도를 분리해서 최적화할 수 있다는 점이다. 운영 hot path는 빠르게 유지하고, release validation, dispute handling, suspicious input triage, 고위험 고객군 처리 같은 구간에서만 더 비싼 correctness path를 태울 수 있다. 실무에서는 이런 절충이 자주 더 잘 작동한다. 모두를 증명하려 하기보다, 틀리면 안 되는 핵심만 더 강하게 묶는 방식이다.

또한 하이브리드 구조는 조직 설득에도 유리하다. 제품팀은 빠른 사용자 경험을 유지하고, 플랫폼팀이나 신뢰성 팀은 결과 검산 장치를 통해 리스크를 줄일 수 있다. 특히 이번 사례처럼 복잡한 로직의 verified core가 작은 spec review를 기반으로 신뢰를 주장할 수 있다면, "모든 코드를 바꾸자" 대신 "핵심 검산 경로를 하나 두자"는 제안이 훨씬 수용되기 쉽다.

물론 주의점이 있다. 하이브리드는 구조적으로 두 구현을 관리해야 하므로 운영 복잡도가 올라간다. 차이가 발생했을 때 어느 쪽을 정답으로 볼지, 언제 fallback할지, mismatch를 어떤 수준에서 알릴지 미리 정해야 한다. 검산 장치가 있다는 이유로 메인 경로 품질이 느슨해지는 것도 흔한 함정이다.

이 선택지는 이런 상황에 특히 유용하다.

• 기존 시스템을 완전히 갈아엎기 어렵지만 리스크를 낮추고 싶을 때
• 성능과 correctness 둘 다 포기하기 어려울 때
• 분쟁 가능성이 있는 결과만 더 엄격하게 다루면 될 때
• 조직 내 formal methods 역량을 점진적으로 쌓고 싶을 때

이번 사례에서 바로 뽑아낼 수 있는 체크포인트

체크포인트 1. 무엇이 증명되었는지보다, 무엇이 아직 증명 밖인지 먼저 적을 수 있는가

이번 저장소는 correctness의 근거를 비교적 명확히 설명한다. 하지만 그 설명이 시스템 전체 무결성을 의미하는 것은 아니다. web demo로 묶인다고 해도, 입출력 파싱, 데이터 변환, 빌드 과정, wrapper, UI 상호작용까지 모두 형식 검증되었다고 읽어서는 안 된다. 실무에서는 "verified core"와 "verified product"를 구분해서 문서화해야 한다.

체크포인트 2. 팀이 믿을 대상이 LLM인지 checker인지 분명한가

이번 사례에서 가장 건강한 부분은 바로 이 선 긋기다. 모델이 구현과 proof를 만들어냈다는 서사는 흥미롭지만, correctness를 믿는 근거는 Lean checker와 작은 spec review라고 반복해서 못 박는다. 실무에서도 AI-assisted development를 도입할 때 이 원칙이 중요하다. 생성 품질이 좋아졌다는 이유로 신뢰 근거까지 생성 모델 쪽으로 넘기면 안 된다.

체크포인트 3. 성능 요구와 정밀도 모델이 충돌하지 않는가

저장소의 DataStructures.lean을 보면 verified core는 rational coordinates를 사용한다. 정확성 측면에서는 설득력 있는 선택이다. 다만 운영 시스템이 주로 floating-point 기반이면, 변환 규칙과 상호운용성 비용이 생긴다. 어디서 round하고 어디서 exact arithmetic를 유지할지 설계가 없으면, 검증된 코어 앞뒤에서 의미가 흔들릴 수 있다. 즉, 검증된 중심부만 보는 것으로는 부족하고 데이터 모델 경계를 함께 봐야 한다.

체크포인트 4. 명세가 실제 제품 요구와 같은 방향을 가리키는가

형식 검증은 명세된 속성에 대해 강하다. 문제는 제품이 원하는 것이 항상 수학적으로 가장 자연스러운 정의와 일치하지는 않는다는 데 있다. 예를 들어 사용자가 기대하는 것은 "내가 그린 도형이 편집기에서 자연스럽게 보이는 결과"일 수 있고, 그것은 어떤 위상적 정의와 정확히 같은 말이 아닐 수도 있다. 이번 프로젝트는 interior set 관점의 올바름에 무게를 두지만, 실무에서는 시각적 직관, 호환 포맷, 후처리 규칙도 중요한 요구사항일 수 있다.

체크포인트 5. proof가 잡아주지 않는 운영 요구를 별도로 관리하는가

작성자가 성능 개선을 다음 단계로 언급한 점은 중요하다. 이것은 단점이라기보다 경계 선언에 가깝다. 즉, correctness를 확보하는 것과 성능을 최적화하는 것은 다른 작업이다. 실무에서는 timeout, 메모리 사용량, 배치 처리량, 추적 가능성, 장애 복구, observability를 별도 지표로 운영해야 한다.

반대로 생각해야 보이는 반례들

이번 사례가 인상적이라고 해서 모든 고난도 알고리즘 팀이 바로 formal verification을 향해 달려갈 필요는 없다. 반례는 꽤 많다.

첫 번째 반례는 문제 정의가 아직 흔들리는 제품 초기 단계다. 아직 고객이 어떤 결과 표현을 선호하는지, 어떤 edge case를 중요한 버그로 인식하는지조차 불명확하다면 명세를 너무 빨리 고정하는 것이 오히려 탐색 속도를 떨어뜨릴 수 있다. 이 단계에서는 먼저 테스트 가능한 프로토타입과 사용성 피드백이 더 중요할 수 있다.

두 번째 반례는 절대 성능이 경쟁력의 핵심인 경우다. 만약 geometry 처리가 대규모 렌더링 파이프라인이나 대량 GIS 배치의 핵심 경로라면, verified core는 reference implementation이나 회귀 검산 장치로는 훌륭해도 운영의 주엔진으로 바로 쓰기에는 부담이 있을 수 있다. 저장소 설명도 현재 구현이 unoptimized라는 점을 숨기지 않는다.

세 번째 반례는 조직 역량의 불균형이다. 기술적으로 올바른 선택이더라도, 팀이 그것을 고칠 수 없으면 다른 종류의 리스크가 생긴다. 특정 소수만 proof를 읽고 수정할 수 있는 구조는 버스 팩터를 높인다. 특히 플랫폼 수명이 길고 유지보수 인력이 자주 바뀌는 조직일수록 이 부분은 냉정하게 봐야 한다.

하지만 conventional approach 쪽에도 반례가 있다. 테스트, fuzzing, 회귀 케이스만으로 충분하다고 믿는 태도는 geometry 같은 분야에서 종종 과신이 된다. 케이스를 더 넣을수록 안심은 커질 수 있지만, 보장의 성질은 여전히 경험적이다. 드문 경계 입력이 사업 손실을 크게 만들 수 있다면, 이 방식만으로는 불안정하다.

"언제 무엇을 고를지"를 한 문장으로 줄이면

세 선택지의 차이를 가장 간단히 말하면 이렇다.

• 틀릴 확률보다 틀렸을 때의 비용이 훨씬 더 중요하다면 formally verified core 쪽으로 기울어야 한다.
• 속도, 통합, 운영 익숙함이 더 중요하고 오류 복구가 쉽다면 일반 구현 + 강한 테스트 체계가 더 현실적이다.
• 둘 다 쉽게 포기할 수 없고 기존 시스템도 유지해야 한다면 하이브리드 구조가 가장 실무적이다.

여기서 중요한 것은 "검증을 도입할까 말까"가 아니라 "어디에 검증을 배치할까"다. 이번 사례는 그 질문을 새롭게 던지게 만든다. 모든 시스템을 증명할 필요는 없지만, 모든 핵심 로직을 테스트만으로 버텨야 하는 것도 아니다.

AI가 도구가 되는 지점, 그리고 아직 사람이 해야 하는 일

이번 HN 포스트의 제목은 AI 모델 버전 차이를 전면에 세우지만, 실무적으로 더 큰 변화는 아마 다른 곳에 있다. 이전에는 proof strategy를 사람이 세밀하게 안내해야 했고, 최근에는 더 큰 전략을 모델이 스스로 조직할 수 있었다는 경험은, formal methods 같은 고난도 작업에서도 AI가 생산성 레이어가 될 수 있음을 시사한다. 하지만 그 자체가 곧 신뢰의 자동화는 아니다. 오히려 이 사례는 AI 시대일수록 신뢰 경계를 더 엄격히 적어야 한다는 교훈을 준다. 누가 코드를 썼는지보다, 무엇이 어떤 checker를 통해 어떤 명세에 대해 보장되는지가 더 중요해진다.

실무 팀이 여기서 바로 가져갈 만한 태도는 분명하다. 생성 모델을 더 많이 쓰되, correctness를 믿는 근거는 더 적게, 더 명확하게 남겨야 한다. 작은 spec, 재실행 가능한 checker, 사람 검토가 가능한 인터페이스, 검증된 코어와 비검증 주변부의 경계 문서화 같은 요소들이 앞으로 더 중요해질 가능성이 크다. 이 프로젝트는 바로 그 설계 감각을 보여준다.

그러니 이번 사례를 "AI가 증명을 해냈다"로만 소비하면 아깝다. 더 생산적인 읽기는 "복잡한 로직에서 사람의 검토 부담을 어디까지 줄일 수 있는가", "그 줄어든 검토 표면이 조직적으로 신뢰 가능한가", "그 대가로 무엇을 포기하거나 별도 관리해야 하는가"를 묻는 쪽이다. 실제 도입 판단은 그 질문들 위에서 내려야 한다. 폴리곤 교차는 시작점일 뿐이고, 진짜 파장은 앞으로 correctness가 중요한 여러 도메인에서 같은 방식의 논의가 늘어나는 데 있을 가능성이 높다.

의견

댓글/토론에서 나온 의견을 참고용으로 정리했습니다. (사실로 단정하지 말고 맥락 확인 권장)

• Hacker News · @threatripper: It uses exact rational coordinates, not floating-point coordinates in the verified core. See: https://github.com/schildep/verified-polygon-intersection/bl...
  • 링크: https://news.ycombinator.com/item?id=48405584
• Hacker News · @CyLith: Does this use integer coordinates or floating point coordinates?
  • 링크: https://news.ycombinator.com/item?id=48405392
• Hacker News · @olaird25: Is the web demo compiled from the lean?
  • 링크: https://news.ycombinator.com/item?id=48405814

댓글

댓글을 읽어오는 중입니다.