인프라 구성이나 워크플로 자동화 설계를 AI에게 맡겨봤다가 결과물이 영 미덥지 않았던 경험이 있다면, 원인이 모델 성능에만 있지 않을 가능성이 높다. 문제는 대부분 검증 구조가 없다는 데 있다. AI가 제안을 내놓았을 때 그것이 좋은지 나쁜지를 판단하는 기준이 인간의 머릿속에만 있고, 자동으로 확인하는 장치가 없으면 에이전트는 피드백 없이 제자리를 맴돈다.
최근 양자 회로 설계 분야에서 나온 연구 결과는 이 문제를 다른 각도에서 보게 만든다.
무엇이 실제로 달라졌는가
양자 컴퓨터는 정보를 처리하는 방식이 고전적 컴퓨터와 근본적으로 다르다. 연산 단위인 큐비트(qubit)는 환경 잡음에 극도로 민감하고, 현재 기술로 구현 가능한 큐비트 수는 수백에서 수천 개 수준에 불과하다. 이 제약 안에서 실용적인 알고리즘을 돌리려면 회로 설계 자체가 최대한 효율적이어야 한다. 게이트(gate, 양자 연산의 기본 단위)를 하나라도 덜 쓸수록 오류가 쌓일 확률이 낮아지고 계산이 더 빨리 끝난다.
Anthropic이 Claude를 활용해 진행한 실험에서, AI 에이전트는 여덟 가지 양자 회로 설계 과제에 대해 기존 최고 수준의 공개 알고리즘을 모두 개선했다. 일부 과제에서는 개선 폭이 10배를 넘었다. 핵심은 에이전트가 스스로 회로를 설계하고, 외부 평가 프로그램이 정확성을 검증한 뒤 점수를 돌려주면, 그 피드백을 받아 다음 설계를 개선하는 닫힌 루프(closed loop) 구조였다. 사람이 중간에 개입하지 않았다.
에이전트가 발견한 개선 사항은 기존 설계를 미세 조정한 결과가 아니었다. 분자의 대칭성과 반복 구조를 이용해 중복 연산을 줄이거나, 극히 드문 입력 케이스를 처리하는 비싼 구성 요소가 실제로는 불필요하다는 사실을 새롭게 발견하는 방식이었다.
이것이 중요한 이유는 명확하다. 성능 개선이 '더 좋은 모델'이 아니라 '더 좋은 검증 구조'에서 나왔다는 점이다.
이 패턴이 기업 시스템 설계에 의미하는 것
양자 회로 최적화와 기업의 인프라 설계는 도메인이 전혀 다르지만, 구조적으로 공통점이 있다.
첫째, 두 문제 모두 탐색 공간이 넓다. 클라우드 리소스 구성 방식, 데이터 파이프라인 순서, 마이크로서비스 간 의존성 배치는 정답이 하나로 수렴하지 않는다. 수십 가지 조합 중 어느 것이 더 낫고 덜 나쁜지를 반복해서 평가해야 한다.
둘째, 두 문제 모두 '점수'로 표현할 수 있는 목표가 있다. 양자 회로에서는 큐비트 수 곱하기 게이트 수가 그 점수였다. 기업 시스템 설계에서도 비슷한 기준을 만들 수 있다. 예를 들어 워크플로 자동화라면 처리 시간, 오류율, 재시도 횟수의 조합이 될 수 있고, 인프라 구성이라면 비용 대비 가용성 수치가 될 수 있다.
셋째, 두 문제 모두 제안과 검증을 분리할 수 있다. 설계 제안은 AI가 하고, 제안이 기준을 충족하는지 확인하는 역할은 자동화된 별도 프로그램이 맡는 구조가 가능하다는 뜻이다.
이 세 조건이 모두 성립하면, 에이전트는 단순히 초안을 제공하는 도구를 넘어서 반복 최적화를 수행하는 시스템으로 작동할 수 있다.
어디서부터 시작하고, 무엇이 아직 불확실한가
실제 도입을 고려한다면, 먼저 두 가지를 구분해야 한다.
평가 기준을 자동화할 수 있는 영역이 있고, 그럴 수 없는 영역이 있다.
자동화 가능한 기준은 숫자로 측정되거나 통과·실패로 판단되는 것들이다. 응답 시간이 500밀리초 이하인지, 특정 입력에 대해 올바른 출력이 나오는지, 비용이 예산 범위를 넘지 않는지 같은 조건은 코드로 검증기를 만들 수 있다. 이런 영역에서는 에이전트와 자동 평가기의 루프가 효과적으로 작동한다.
반면 '이 아키텍처가 3년 후 확장성을 충분히 고려했는가', '팀의 운영 부담이 수용 가능한 수준인가' 같은 판단은 숫자로 환원하기 어렵다. 이 부분은 여전히 사람이 기준을 정하고 결과를 해석해야 한다. AI가 루프를 돌아도, 루프 바깥에서 어떤 목표 함수를 최적화할지 결정하는 것은 인간의 역할이다.
한 가지 더 주의할 점은, 평가 기준이 부정확하게 설정되면 에이전트가 그 기준을 '잘' 충족하면서 실제로는 원하지 않는 방향으로 최적화할 수 있다는 것이다. 양자 회로 실험에서는 '정확성 확인'과 '점수'가 명확하게 분리되어 있었다. 기업 환경에서도 이 두 가지, 즉 결과가 올바른지 확인하는 기준과 얼마나 좋은지 측정하는 기준을 따로 설계하는 것이 중요하다.
실제로 시험해볼 수 있는 진입점
이 구조를 팀에서 처음 적용해보려 한다면, 다음 조건을 동시에 갖춘 문제를 골라 시작하는 것이 현실적이다.
설계 제안이 코드나 구성 파일로 표현되어야 한다. 자연어 설명만으로는 자동 검증이 불가능하다. 테라폼(Terraform) 구성, CI/CD 파이프라인 정의, API 라우팅 규칙처럼 기계가 읽을 수 있는 형태여야 검증기를 붙일 수 있다.
정확성 확인과 품질 측정을 분리해야 한다. 에이전트가 제안한 구성이 배포 가능한 상태인지 먼저 확인하고, 그다음 성능 목표에 얼마나 근접했는지 점수를 돌려주는 구조를 순서대로 만든다. 이 순서가 뒤집히면 잘못된 구성이 높은 점수를 받는 사고가 생긴다.
첫 번째 루프는 가능한 한 범위를 좁게 설정한다. '전체 인프라 최적화'가 아니라 '특정 마이크로서비스의 타임아웃과 재시도 정책'처럼, 평가 기준을 완전히 자동화할 수 있는 작은 단위에서 루프가 실제로 돌아가는지 확인하는 것이 먼저다.
이렇게 시작하는 이유는 성과를 보장하기 위해서가 아니다. 평가 기준을 명확히 표현하는 과정 자체가 팀의 설계 의사결정 기준을 정리하는 작업이 되기 때문이다. 에이전트가 루프를 얼마나 잘 도느냐보다, 팀이 '좋은 설계'를 어떻게 정의하는지를 코드로 표현할 수 있느냐가 이 방식의 실질적인 선결 조건이다.
