AI가 미해결 수학 문제를 풀기 시작했다.

얼마 전 수학자들이 발표한 선언문 A Severe Misalignment of AI in Mathematics를 읽었다. 테렌스 타오, 피터 숄체, 허준이 등 여러 저명한 수학자가 참여한 이 선언은 얼핏 보면 AI가 수학자를 대체할지 모른다는 불안처럼 보인다. 하지만 내용을 따라가다 보면 훨씬 낯설고 중요한 질문을 만난다.

문제를 더 빨리 푸는 것이 정말 수학을 더 빠르게 발전시키는 일일까?

처음에는 이상하게 들린다. 풀리지 않던 문제를 풀었다면 당연히 발전 아닌가. 그러나 선언문이 지적하는 것은 정답과 이해가 서로 다른 것이라는 사실이다.

난제는 제거해야 할 장애물이 아니다

AI 기업의 관점에서 수학의 난제는 매력적인 벤치마크다.

“우리 모델이 아직 아무도 풀지 못한 문제를 해결했다.”

이보다 모델의 성능을 인상적으로 보여주는 문장은 찾기 어렵다. 답이 분명하고, 성공 여부를 비교하기도 좋다. 더 어려운 문제를 더 많이 풀수록 더 뛰어난 모델이라는 이야기도 만들기 쉽다.

하지만 수학자에게 난제는 단순한 시험 문제가 아니다. 그것은 연구자들을 새로운 영역으로 이끄는 등대에 가깝다. 한 문제를 해결하려고 수년간 씨름하는 동안 새로운 개념이 등장하고, 전혀 관계없어 보이던 이론들이 연결되며, 다른 문제에도 사용할 수 있는 방법이 만들어진다. 증명이 나온 뒤에도 그것을 더 단순하게 만들고, 일반화하고, 학생들이 이해할 수 있는 형태로 정리하는 긴 작업이 이어진다.

난제의 가치는 마지막 정답에만 있지 않다. 그 문제를 향해 가는 과정에서 새로운 수학이 자라는 것이 더 중요할 수 있다.

그런데 AI가 인간보다 압도적으로 빠른 속도로 난제를 해결한다면 어떻게 될까? 표면적으로는 수학이 엄청나게 발전한 것처럼 보일 것이다. 동시에 인간 수학자들이 오랜 시간 탐험했을 수많은 연구 경로가 한꺼번에 닫힐 수도 있다.

AI가 문제 100개를 풀었다는 말은 100개의 연구 성과가 생겼다는 뜻일 수 있다. 그러나 다른 각도에서 보면 인간이 탐구했을 100개의 연구 프로그램이 사라졌다는 뜻일 수도 있다.

결과는 쌓이는데 이해는 늘지 않는다

AI가 새로운 증명을 만들었다고 해서 곧바로 인간의 수학이 되는 것은 아니다.

누군가는 증명이 정말 옳은지 검증해야 한다. 기존 연구와 어떤 관계인지 확인하고, 핵심 아이디어를 추출하고, 더 간단한 설명을 찾아야 한다. 다른 분야에 적용할 수 있는지 살펴보고, 논문과 강의와 교과서의 언어로 바꾸어야 한다.

AI가 하루에 수천 개의 결과를 생산해도 인간이 그것을 이해하고 체계화하는 속도는 갑자기 수천 배 빨라지지 않는다. 결국 엄청난 양의 ‘AI 생성 수학 백로그’가 쌓일 수 있다.

문제 해결 속도는 100배 빨라졌는데 인간의 이해가 증가하는 속도는 그대로인 이상한 상황이다.

이 선언문을 읽으며 가장 오래 남은 문장은 이것이었다.

Output ≠ Understanding

산출물이 늘어나는 것과 이해가 늘어나는 것은 같은 일이 아니다.

그리고 이 문제는 수학만의 이야기가 아니다.

코드는 만들어졌지만 누가 시스템을 이해하는가

코딩 에이전트를 사용하면 예전에는 며칠 걸리던 기능을 몇 시간 안에 만들 수 있다.

“결제 실패 시 자동 재시도 기능을 추가해줘.”

에이전트는 여러 파일을 수정하고 테스트를 추가한다. CI도 통과한다. 다른 에이전트가 코드를 리뷰하고, 발견한 문제를 원래 에이전트가 다시 수정한다. 사람은 마지막 요약을 읽고 병합 버튼을 누른다.

완벽한 자동화처럼 보인다.

그런데 담당 개발자에게 질문해본다.

  • 왜 별도의 retry queue가 필요한가?
  • 중복 결제는 어떻게 방지하는가?
  • 재시도를 포기하는 조건은 무엇인가?
  • 외부 결제사가 부분 장애일 때 어떤 일이 벌어지는가?
  • 장애가 나면 어느 로그와 지표부터 확인해야 하는가?

이 질문에 답할 수 없다면 코드 저장소에는 기능이 추가됐지만 팀에는 그만큼의 이해가 추가되지 않은 것이다.

더 위험한 것은 AI가 만든 코드가 나쁠 때만 이런 일이 생기는 것이 아니라는 점이다. 코드는 정확할 수 있다. 테스트도 모두 통과할 수 있다. 서비스도 당장은 잘 동작할 수 있다. 그러면서도 그것을 이해하고 통제할 수 있는 사람은 줄어들 수 있다.

과거에는 개발자가 기능을 구현하고 버그를 잡는 과정에서 시스템에 대한 정신적 모델을 만들었다. 로그를 뒤지고, 네트워크를 추적하고, 데이터베이스를 확인하고, 잘못된 가설을 버리는 과정이 곧 학습이었다.

AI에게 “원인을 찾아서 고쳐줘”라고 말한 뒤 10분 만에 수정된 코드를 받으면 장애 대응 시간은 줄어든다. 그러나 장애를 통해 개발자가 시스템을 배울 기회도 함께 사라진다.

해결 속도는 빨라졌지만 팀은 장기적으로 시스템에 약해질 수 있다. 숫자로 측정되는 KPI는 좋아졌는데 실제 통제력은 낮아지는 역설이다.

문서는 존재하지만 조직의 이해는 존재하지 않는다

조직 업무에서는 이 문제가 더 쉽게 감춰진다.

리서치 에이전트가 시장을 조사하고, 경쟁사 분석 에이전트가 비교표를 만들고, 재무 에이전트가 사업성을 계산하고, 마지막 에이전트가 모든 결과를 묶어 70페이지짜리 전략 보고서를 작성한다고 해보자.

2주 걸리던 보고서가 30분 만에 완성된다.

회의에서 임원이 묻는다.

“왜 중국 시장보다 일본 시장에 먼저 진출해야 하죠?”

담당자가 AI 보고서의 결론을 다시 읽어주는 것밖에 할 수 없다면, 조직에는 70페이지의 문서가 있지만 70페이지 분량의 이해는 없다.

AI가 원자료를 읽고, 다른 AI가 그것을 분석하며, 또 다른 AI가 분석을 요약하는 동안 사람은 마지막 슬라이드만 볼 수 있다. 그러다 보면 조직 안에서 원자료를 직접 읽고 핵심 가정을 검토한 사람이 아무도 없는 상태가 된다.

문서의 수는 늘어난다. 분석의 수도 늘어난다. 회의 자료는 더 화려해진다. 하지만 질문에 답하고, 반론을 검토하고, 잘못된 결정을 중단시킬 사람은 오히려 줄어들 수 있다.

병목은 생산에서 흡수로 이동한다

지금까지 지적 노동의 병목은 주로 생산 능력이었다.

개발자가 하루에 작성할 수 있는 코드에는 한계가 있었다. 기획자가 일주일에 만들 수 있는 보고서도 제한되어 있었다. 수학자가 평생 풀 수 있는 문제 역시 많지 않았다.

AI는 이 병목을 빠르게 없애고 있다.

그러면 새로운 병목이 나타난다.

검증하고, 이해하고, 선택하고, 공유하고, 책임지는 능력.

코딩 에이전트 10개를 동시에 돌려 PR 30개를 만드는 일은 점점 쉬워질 것이다. 그러나 사람이 30개 변경의 의미와 시스템에 미치는 영향을 이해하는 일은 여전히 어렵다.

멀티에이전트 시스템으로 보고서 100개를 만드는 것도 가능해질 것이다. 하지만 사람이 실제로 판단할 수 있는 것은 그중 몇 개뿐이다.

그래서 AI 시대에는 이상한 역전이 일어난다.

생성하는 능력보다 무엇을 생성하지 않을지 결정하는 능력이 더 중요해진다.

에이전트가 쉬지 않고 일하는 상태를 목표로 삼아서는 안 된다. 에이전트 활용률이 높다는 것은 비용과 산출량이 많다는 뜻일 뿐, 조직이 더 현명해졌다는 뜻은 아니다.

좋은 시스템은 보고서 100개를 만드는 시스템이 아니라 사람이 실제로 판단하고 실행할 핵심 결과 3개를 만드는 시스템일 수 있다.

그렇다면 코딩 에이전트를 어떻게 사용해야 할까

AI가 코드를 작성하더라도 시스템에 대한 판단과 책임까지 AI에게 넘겨서는 안 된다. 몇 가지 운영 원칙이 필요하다.

첫째, 모든 AI 작업에는 인간 Owner가 있어야 한다. 에이전트가 구현과 테스트와 리뷰를 모두 수행했더라도 변경 이유를 설명하고 장애가 발생했을 때 대응할 사람은 명확해야 한다. “AI가 만들었다”는 책임 주체가 될 수 없다.

둘째, 코드의 양보다 의사결정을 리뷰해야 한다. AI가 만든 수천 줄을 사람이 모두 똑같은 깊이로 읽는 것은 불가능하다. 대신 무엇을 바꿨는지, 왜 이 설계를 선택했는지, 어떤 대안을 버렸는지, 실패할 때 어떻게 동작하는지, 어떤 위험이 남았는지를 먼저 확인해야 한다.

셋째, 위험에 따라 인간의 개입 수준을 달리해야 한다. 문서 수정, 테스트 추가, 단순한 리팩터링에는 높은 자율성을 줄 수 있다. 그러나 인증, 권한, 결제, 개인정보, 데이터베이스 마이그레이션, 동시성, 외부 API, 인프라 변경에는 사람이 설계 단계부터 참여해야 한다.

넷째, AI가 작성하고 다른 AI가 리뷰했다고 해서 검증된 것으로 간주하면 안 된다. 여러 에이전트가 같은 잘못된 전제를 공유할 수 있다. AI 리뷰는 인간 리뷰를 없애는 장치가 아니라 인간이 읽어야 할 부분을 압축하는 장치여야 한다.

다섯째, PR 수나 코드 줄 수를 생산성 지표로 삼지 말아야 한다. 배포 후 장애, 롤백, 재작업, 중요한 결함의 발견 시점, 담당자의 설명 가능성, 장애 복구 시간 같은 결과를 함께 보아야 한다.

여섯째, 인간의 흡수 대역폭에 맞춰 동시에 진행하는 작업의 수를 제한해야 한다. 에이전트가 만들 수 있는 양이 아니라 사람이 제대로 판단할 수 있는 양이 기준이 되어야 한다.

마지막으로 중요한 변경에는 코드뿐 아니라 이해를 전달하는 최소한의 기록이 필요하다. 설계 결정, 데이터 흐름, 운영 지표, 장애 시 확인 순서, 롤백 조건, 알려진 한계가 다음 사람에게 전달되어야 한다. 여기서도 문서를 많이 만드는 것이 목적은 아니다. 실제로 사용할 최소한의 정보만 남기는 것이 중요하다.

3분 안에 설명할 수 없다면

이 모든 원칙을 하나의 간단한 규칙으로 압축한다면 이렇게 말할 수 있다.

담당자가 변경의 목적, 핵심 설계, 주요 실패 시나리오를 3분 안에 설명할 수 없다면 병합하지 않는다.

사람이 모든 코드를 직접 작성할 필요는 없다. AI가 반복 작업을 처리하고, 테스트를 만들고, 잠재적인 문제를 먼저 찾아주는 것은 분명 큰 도움이 된다.

하지만 최종적으로 무엇이 바뀌었고 왜 안전하다고 판단했는지 설명할 수 있는 사람은 남아 있어야 한다. 배포 이후 문제가 발생했을 때 결정을 내리고 결과를 책임질 사람도 필요하다.

AI가 인간을 돕는 가장 좋은 방식은 인간을 과정에서 완전히 제거하는 것이 아니라, 인간이 읽고 판단해야 할 영역을 줄여주는 것이다.

진짜 생산성은 무엇인가

수학 선언문은 AI의 목표를 “얼마나 많은 난제를 풀었는가”에서 “인간의 수학적 이해와 발견을 얼마나 증진했는가”로 바꾸자고 요구한다.

개발 조직에도 같은 질문을 던질 수 있다.

  • 얼마나 많은 코드를 만들었는가가 아니라, 얼마나 많은 시스템을 이해하고 통제할 수 있게 되었는가.
  • 얼마나 많은 보고서를 만들었는가가 아니라, 얼마나 좋은 판단을 내릴 수 있게 되었는가.
  • 얼마나 많은 에이전트를 실행했는가가 아니라, 인간의 능력과 책임 범위가 얼마나 확장되었는가.

AI 시대의 생산성은 인간이 이해하고 책임질 수 있는 유용한 결과를 얼마나 더 많이 만들었는가로 측정해야 한다.

산출물을 만드는 비용이 거의 0에 가까워질수록 산출물의 양은 성과를 측정하는 지표로서 의미를 잃는다. 앞으로 가장 희소한 것은 코드나 문서가 아니라, 무엇을 만들지 선택하고 결과를 검증하며 그것을 자신의 이해로 흡수하고 책임지는 능력일 것이다.

AI가 인간보다 더 빨리 답을 만들 수 있는 시대가 오고 있다.

그래서 이제 더 중요한 질문은 “AI가 무엇을 만들 수 있는가”가 아니다.

그 결과로 인간에게 무엇이 남는가.