AI가 코드를 토해내는 시대, '수학적으로 증명된 코드'가 답일까

요즘 개발 현장의 풍경이 확 바뀌었습니다. 사람이 한 줄씩 타이핑하던 코드를, 이제 AI가 화면 가득 쏟아냅니다. 빠르긴 한데 한 가지 찜찜한 질문이 남습니다. 이 코드, 정말 맞는 걸까요. 바로 이 지점에서 수십 년 묵은 개념 하나가 다시 무대 위로 올라왔습니다. ‘정형 기법(formal methods)’, 즉 코드가 옳다는 걸 수학적으로 증명하는 방법입니다.

정형 기법이 대체 뭔가요

정형 기법을 한 문장으로 풀면 이렇습니다. 코드가 명세대로 동작한다는 것을 수학적으로 증명하는 기술입니다.

보통 우리는 코드가 맞는지 어떻게 확인하나요. 테스트를 돌립니다. 입력 몇 개를 넣어보고 결과가 기대대로 나오면 통과입니다. 하지만 테스트는 본질적으로 ‘예시 몇 개’를 확인하는 일입니다. 넣어보지 않은 입력에서 무슨 일이 벌어질지는 모릅니다.

정형 기법은 접근이 다릅니다. “모든 입력에 대해 이 함수는 절대 음수를 반환하지 않는다” 같은 명제를 수학적으로 증명합니다. 예시가 아니라 전체를 다룹니다. 유명한 사례가 seL4 마이크로커널입니다. 운영체제 핵심부의 동작이 명세와 일치한다는 것을 형식 증명으로 못 박았습니다. 항공, 우주, 금융처럼 한 번의 버그가 치명적인 분야에서 오래전부터 쓰여온 무거운 무기입니다.

문제는 비용입니다. 증명을 작성하는 데 드는 시간과 전문성이 어마어마합니다. 그래서 대부분의 일반 소프트웨어에서는 “좋은 건 알지만 우리 쓸 일은 없는 기술"로 여겨졌습니다.

왜 하필 지금 다시 뜨는가

답은 AI입니다. 정확히는 AI가 만들어내는 코드의 양과 신뢰성 문제입니다.

AI 코딩 도구는 코드를 놀랍도록 빠르게 생산합니다. 그런데 그만큼 빠르게 검토할 수 있는 사람은 없습니다. 리뷰 부담이 폭발적으로 늘어났다는 뜻입니다. 더 곤란한 건 AI 코드 특유의 ‘그럴듯함’입니다. 문법도 맞고 읽기에도 자연스러운데, 미묘한 곳에서 틀립니다. 사람 눈으로는 잘 안 걸립니다.

여기서 발상의 전환이 나옵니다. 코드를 누가 썼든, 옳다는 것을 기계가 증명할 수 있다면 누가 썼는지는 중요하지 않다는 겁니다. AI가 코드를 쏟아내도 그 코드가 명세를 만족한다는 증명이 함께 따라온다면, 우리는 코드 한 줄 한 줄을 읽지 않고도 신뢰할 수 있습니다. 검증의 짐을 사람에서 기계로 넘기는 그림입니다.

흥미로운 역설도 있습니다. 정형 기법의 가장 큰 장벽이 ‘증명 작성이 너무 어렵다’였는데, 바로 그 어려운 증명을 이제 AI가 거들 수 있습니다. AI가 코드도 만들고 그 코드의 증명도 함께 만드는 구조. AI가 만든 문제를 AI가 풀게 하는 셈입니다.

Jane Street이 보여준 현실적 모델

이 흐름에서 자주 언급되는 곳이 금융 트레이딩 회사 Jane Street입니다. 이들은 함수형 언어 OCaml을 거의 회사 전체의 공용어로 쓰는 것으로 유명합니다.

왜 하필 함수형 언어일까요. 핵심은 타입 시스템입니다. 강력한 타입 시스템은 일종의 ‘가벼운 정형 기법’입니다. 전체를 수학적으로 증명하는 무거운 방식까지 가지 않더라도, 타입이 맞지 않는 코드는 애초에 컴파일조차 되지 않게 막습니다. “이 변수에는 절대 잘못된 종류의 값이 들어올 수 없다"를 컴파일러가 보장해주는 겁니다.

밀리초 단위로 수백억이 오가는 트레이딩 세계에서 버그는 곧 손실입니다. 그래서 이들은 ‘실행하기 전에 틀린 걸 잡는’ 쪽에 일찌감치 투자했습니다. 그리고 AI 코딩 시대에 이 선택이 다시 빛을 봅니다. AI가 만든 코드라도 강한 타입 시스템이라는 그물망을 통과해야만 살아남기 때문입니다. 사람이 일일이 안 봐도 컴파일러가 1차 검문소 역할을 합니다.

여기서 중요한 시사점이 나옵니다. 검증 가능한 프로그래밍은 꼭 seL4 같은 극단적 형식 증명만을 뜻하지 않습니다. 타입 시스템, 계약(contract) 기반 설계, 속성 기반 테스트(property-based testing)처럼 ‘현실적으로 적용 가능한’ 스펙트럼이 존재합니다.

그래서 검증 가능한 프로그래밍이 정답인가

여기서 냉정해질 필요가 있습니다. 정형 기법은 만능이 아닙니다.

가장 근본적인 한계는 이겁니다. 정형 기법은 “코드가 명세를 만족한다"를 증명할 뿐, “명세 자체가 옳은지"는 증명하지 못합니다. 명세를 사람이 잘못 적으면, 잘못된 명세를 완벽하게 만족하는 잘못된 코드가 나옵니다. 증명서가 멀쩡한 가짜인 셈입니다.

비용 문제도 여전합니다. 모든 코드에 형식 증명을 붙이는 건 비현실적입니다. 빠르게 만들고 빠르게 버리는 대부분의 일반 소프트웨어에는 과한 무장입니다. 게다가 명세를 정확한 형식 언어로 적어내는 일 자체가 또 하나의 어려운 전문 작업입니다.

그래서 현실적인 그림은 ‘전부 아니면 전무’가 아닙니다. 위험도에 따라 검증 강도를 나누는 쪽입니다. 결제, 인증, 금융 거래처럼 틀리면 큰일 나는 핵심부에는 강한 검증을. 화면 색깔 바꾸는 코드에는 가벼운 테스트를. AI가 코드를 양산할수록, 어디에 검증의 힘을 집중할지 판단하는 안목이 오히려 더 중요해집니다.

마무리

AI가 코드를 쏟아내는 시대에 정형 기법이 다시 떠오르는 건 우연이 아닙니다. 생산 속도가 빨라질수록 신뢰의 병목이 드러나고, 그 병목을 사람의 눈이 아닌 기계의 증명으로 뚫으려는 시도이기 때문입니다. Jane Street의 타입 중심 문화는 그 현실적 출발점을 보여줍니다.

다만 명심할 게 있습니다. 검증 가능한 프로그래밍은 ‘읽지 않아도 되는 코드’를 향한 길이지, ‘생각하지 않아도 되는 개발’을 뜻하진 않습니다. 무엇을 검증할지, 명세를 어떻게 옳게 적을지는 결국 사람의 몫으로 남습니다. AI가 코드를 다 써주는 세상에서, 여러분이라면 어느 코드에 ‘증명’이라는 도장을 찍고 싶으신가요.