ConicFlow, 흐름을 다스리는 법

Flow matching 모델에서 추론 시점에 제약과 보상을 함께 다루기 위해 샘플링을 최적 제어 문제로 다시 쓴 ConicFlow를 해설합니다.

원문 논문 보기
'ConicFlow, 흐름을 다스리는 법' 기사 커버 이미지

arXiv에 공개된 ConicFlow: constrained Inference-time optimal control for flow matching models (arXiv 2610.14307)는 flow matching 모델의 추론 시점 샘플링 문제를 다룹니다. 원문 링크는 제목 아래에 걸어 두었습니다.

이 연구가 내세우는 말은 한 문장으로 정리되는데, 미리 학습된 흐름에서 너무 멀어지지 않으면서 보상을 높이고 종착점의 hard 제약을 지키는 샘플링을 추론 시점 최적 제어 문제로 풀자는 것입니다. 이 글에서는 그 발상이 왜 나왔고 어떤 장치로 구현됐으며 이론과 실험이 어디까지 뒷받침하는지를 차례로 따라가 보겠습니다.

처음 이 논문이 눈에 들어온 이유

저는 이 논문을 처음 봤을 때 제목의 마지막 두 단어에 먼저 멈췄습니다. flow matching 모델에 inference-time control을 얹는다는 말은 이제 낯설지 않기 때문입니다. 그런데 constrained라는 말이 붙으면 이야기가 달라지죠. 보상을 높이는 일과 제약을 지키는 일은 겉보기에는 비슷한 유도처럼 보이지만, 실제로는 서로 다른 종류의 약속이기 때문입니다.

생성 모델을 쓰다 보면 이런 장면을 자주 만납니다. 분자 구조를 만들 때는 결합이 물리적으로 말이 되어야 하고, 로봇 궤적을 만들 때는 관절 각도가 한계를 넘으면 안 되며, 이미지를 만들 때는 특정 영역을 비워 두어야 할 때가 있기 때문입니다. 그렇다면 학습이 끝난 뒤에 이런 조건을 붙일 수 있을까요? 다시 학습하지 않고 샘플링 과정에서만 조건을 만족시킬 수 있다면, 운영 입장에서는 부담이 크게 줄어들죠.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 지점입니다. 학습된 흐름을 최대한 존중하면서도 마지막 샘플이 원하는 조건 안에 들어가도록 추론 과정을 조율하겠다는 태도가 읽혔기 때문입니다. 흔히 보상 유도라고 하면 흐름을 조금 비틀면 되는 것처럼 말하지만, hard 제약을 걸면 흐름 전체를 다시 설계해야 하는 순간이 옵니다. 이 논문은 그 순간을 피하지 않고 제어 문제로 정면으로 받아들입니다.

생성 도중에 조건을 붙이면 왜 힘들어질까

Flow matching을 잠깐 떠올려 보겠습니다. 노이즈에서 시작해 데이터 쪽으로 흘러가는 벡터 필드를 미리 학습해 두고, 추론 시점에는 그 필드를 따라 미분방정식을 풀면서 샘플을 만들기 때문입니다. 그래서 중간 궤적은 매끈하고, 종착점의 분포는 학습 데이터의 모양을 닮죠. 그런데 여기에 추론 시점에 새로운 소망이 끼어듭니다. 특정 성질은 더 높았으면 좋겠고, 특정 조건은 꼭 지키고 싶다는 소망입니다.

문제는 그다음에 생깁니다. 보상을 높이는 방향으로 흐름을 비틀면 분포가 서서히 어긋나고, 제약을 세게 걸면 궤적이 갑자기 꺾이면서 학습된 흐름이 상상하지 못한 영역으로 들어가기 때문입니다. 생각해보면 사람도 비슷하게 길을 잃습니다. 내비게이션이 알려준 길을 따라가다가 갑자기 유턴하라는 말을 들으면 잠깐은 버틸 수 있지만, 계속 꺾다 보면 결국 어디에 있는지 모르게 되니까요.

그래서 추론 시점 유도는 늘 긴장과 함께 갑니다. 유도를 약하게 하면 제약이 안 지켜지고, 세게 하면 샘플이 이상해지기 때문입니다. 게다가 제약은 대개 종착점에서만 판단됩니다. 중간 궤적이 아무리 예뻐도 마지막 샘플이 제약 밖에 있으면 실패니까요. 그렇다면 중간에서는 무엇을 기준으로 움직여야 할까요? 이 질문이 ConicFlow의 출발점이라고 저는 봅니다.

미리 학습된 흐름과 제어된 궤적이 나란히 나아가는 개념도
미리 학습된 흐름과 제어된 궤적이 나란히 나아가는 개념도

보상을 쫓다 보면 흐름이 망가지는 이유

여기서 잠깐 보상에 대해 짚고 넘어가야 합니다. 보상이라는 말은 달콤하지만, 생성 모델 앞에서는 꽤 위험한 유혹이기도 하기 때문입니다. 보상이 높은 샘플을 찾아 흐름을 비틀수록, 모델이 원래 알던 분포에서 멀어집니다. 처음에는 그 이동이 작아 보여도, 여러 스텝에 걸쳐 쌓이면 전혀 다른 동네에 도착해 있죠.

연구진이 이 문제를 deviation이라는 말로 다룬 점이 저는 마음에 들었습니다. 미리 학습된 궤적에서 얼마나 벗어났는지를 명시적인 비용으로 두고 보상과 저울질하겠다는 선언이기 때문입니다. 이렇게 쓰면 유도의 세기를 감으로 정하는 대신, 벗어난 정도와 얻는 보상을 같은 식 안에서 비교할 수 있습니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보기 때문입니다.

그런데 제약이 하나 더 들어오면 저울이 복잡해집니다. 보상은 높을수록 좋다는 부드러운 wish지만, hard 제약은 지키거나 깨거나 둘 중 하나니까요. 보상을 10점 더 받는 대신 제약을 어기는 샘플은 현장에서는 0점짜리입니다. 로봇 팔이 목표에 1cm 더 가까워졌는데 관절이 부러졌다면, 그 궤적은 쓸 수 없죠. 그래서 보상과 제약을 같은 가중합으로 뭉뚱그리면 운영에서 사고가 납니다. 이 논문이 제약을 목적함수 속 항이 아니라 종착점의 조건으로 따로 세운 이유도 여기에 있습니다.

샘플링을 제어 문제로 다시 쓰는 발상이 던지는 질문

이제 논문의 중심 발상으로 들어가 보겠습니다. ConicFlow는 샘플링을 최적 제어 문제로 다시 씁니다. 매 스텝에서 흐름을 따라가는 것에 더해 작은 제어 입력을 더할 수 있고, 그 제어는 궤적을 미리 학습된 흐름 근처에 묶어 두는 비용을 치르면서 보상 쪽으로 궤적을 밀어냅니다. 다만 종착점에서는 hard 제약이 기다리고 있죠. 수식으로 쓰면 상태는 생성 과정의 중간 샘플, 제어는 흐름에 더하는 보정, 목적함수는 deviation 비용에서 보상을 뺀 형태가 됩니다.

여기서 재미있는 질문이 생깁니다. 왜 하필 제어(control)라는 말을 쓸까요? 그냥 유도(guidance)라고 해도 되지 않을까요? 저는 이 단어 선택이 논문의 태도를 보여준다고 봅니다. 유도는 대개 기울기를 더하는 기법처럼 들리지만, 제어는 제약과 비용과 지평(horizon)을 함께 고려하는 Decisions의 연속이라는 뜻을 품고 있기 때문입니다. 매 순간 무엇을 할지가 아니라, 앞으로의 궤적 전체를 생각하면서 지금의 입력을 고르겠다는 선언입니다.

물론 이렇게 쓰면 문제가 커집니다. 전체 궤적에 대한 최적화를 추론 시점에 매번 풀 수는 없으니까요. 그래서 논문은 곧바로 이산화(discretization)와 짧은 지평이라는 현실적인 선택으로 넘어갑니다. 이상과 계산 사이의 거리를 메우는 과정이 이 논문의 진짜 볼거리라고 할 수 있습니다.

가이던스라고 부르면 놓치는 것들

이 대목에서는 오해를 하나 풀어야 합니다. ConicFlow를 reward guidance의 변형 정도로 보면 이야기가 납작해지기 때문입니다. 일반적인 가이던스는 학습된 score나 벡터 필드에 보상 기울기를 더해 샘플을 밀어내는 방식인데, 제약이 있으면 보통 그 기울기에 제약 페널티를 슬쩍 섞습니다. 간단하고 빠르지만, 페널티 가중치를 아무리 조절해도 종착점의 hard 보장은 나오지 않죠.

반면 ConicFlow는 제약을 페널티가 아니라 조건으로 둡니다. 이 차이는 생각보다 중요합니다. 페널티 방식에서는 제약 위반과 보상 상승이 같은 저울 위에서 맞바꿔지지만, 조건 방식에서는 위반 자체가 허용되지 않는 해를 찾는 것이 목표가 되기 때문입니다. 그래서 논문은 쌍대 변수(dual multiplier)를 도입하는데, 이에 대해서는 뒤에서 자세히 다루겠습니다.

또 하나 짚을 점은 재학습이 없다는 사실입니다. 모델 가중치는 그대로 두고 샘플링 과정의 궤적만 다루기 때문입니다. 운영 관점에서 보면 이 선택은 상당히 큽니다. 밤사이 새로운 제약이 추가됐다고 모델을 다시 학습할 수는 없으니까요. 저는 그래서 이 설정을 연구실 점수 이상으로 평가했습니다. 배포된 큰 flow matching 모델을 그대로 두고 추론 과정에서만 조건을 붙일 수 있다면, 실험실이 아니라 현장에서 바로 쓸 수 있는 이야기니까요. 참고로 논문은 저차원 환경과 함께 최근 큰 규모의 flow matching 모델에서도 실험했다고 밝히는데, 규모가 커져도 같은 틀이 돌아간다는 점을 보여주려는 시도로 읽혔습니다.

짧은 구간만 내다보며 궤적을 고치는 receding-horizon 제어 그림
짧은 구간만 내다보며 궤적을 고치는 receding-horizon 제어 그림

짧게 내다보고 자주 고치는 쪽을 택한 이유

전체 궤적을 한 번에 최적화하는 것은 추론 시점에는 너무 무겁습니다. 그래서 논문이 꺼낸 것이 receding-horizon control인데, 매 스텝마다 전체 남은 구간이 아니라 짧은 윈도우만 내다보며 최적화를 풀고 첫 번째 입력만 실행한 뒤 다음 스텝에서 다시 계획하는 방식입니다. 운전으로 치면 목적지까지의 전체 경로를 한 번에 외우는 대신, 앞의 몇 백 미터만 보고 핸들을 돌리되 매 순간 다시 앞을 보는 셈입니다.

이 방식이 좋은 점은 계산이 감당 가능해진다는 데 있습니다. 윈도우가 짧으니 매번 풀어야 할 문제도 작아지고, 흐름이 예상과 다르게 흘러도 다음 스텝에서 바로잡을 기회가 생기니까요. 그런데 대가가 있습니다. 짧게 보면 종착점의 제약이 눈에 안 들어오기 때문입니다. 지금 눈앞의 몇 스텝만 보면 멀쩡해 보이는 선택이, 나중에 보면 제약을 어기는 길의 입구일 수 있죠.

여기서는 조금 조심해서 읽을 필요가 있습니다. Receding-horizon이 만능이라는 뜻이 아니라, 긴 지평을 짧게 자르는 대신 다른 장치로 종착점을 계속 의식해야 한다는 뜻이니까요. 논문은 그 장치로 쌍대 변수와 종착점 예측을 함께 씁니다. 짧게 보는 효율은 가져가되, 멀리 보는 책임은 다른 형태로 유지하겠다는 설계입니다.

제약의 어려움을 기억하는 쌍대 변수 이야기

이제 알고리즘이 실제로 도는 방식을 따라가 보겠습니다. 논문은 receding-horizon primal-dual 알고리즘을 제안하는데, 여기서 primal은 궤적과 제어에 대한 선택이고 dual은 각 제약을 얼마나 세게 다뤄야 하는지를 나타내는 multiplier입니다. 제약을 어길 것 같으면 해당 multiplier가 올라가서 제약을 더 세게 밀어붙이고, 여유가 생기면 내려가는 구조입니다.

이 대목이 저는 꽤 직관적으로 다가왔습니다. 각 제약마다 어려움을 기억하는 계수가 붙어 있다고 상상하면 되기 때문입니다. 어떤 제약은 매번 쉽게 지켜지니 계수가 낮게 머물고, 어떤 제약은 자꾸 어기려고 하니 계수가 올라가서 핸들을 더 세게 꺾습니다. 그리고 이 계수는 샘플링이 진행되는 내내 조금씩 다듬어집니다. 처음부터 완벽한 가중치를 아는 대신, 흘러가면서 배우는 셈입니다.

기술적으로 보면 이 과정은 짧은 윈도우 문제를 푸는 것과 쌍대 변수를 업데이트하는 것을 번갈아 수행합니다. 윈도우 안에서는 제약을 어기지 않는 방향으로 궤적을 찾고, 윈도우 밖의 남은 구간에 대해서는 쌍대 변수가 그 부담을 대신 짊어지는 형태에 가깝습니다. 그래서 논문의 표현을 빌리면, 쌍대 변수는 각 제약을 만족시키는 어려움을 포착합니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 단일 가중치가 아니라 제약마다 따로 움직이는 기억 장치를 두었다는 점이 이 방법의 성격을 규정하니까요.

제약 위반에 따라 올라갔다 내려갔다 하는 쌍대 변수의 흐름도
제약 위반에 따라 올라갔다 내려갔다 하는 쌍대 변수의 흐름도

끝점을 미리 당겨서 보면 무엇이 달라질까

짧은 윈도우의 약점을 메우는 또 하나의 장치가 terminal-estimate 변형입니다. 보통 receding-horizon에서는 윈도우 끝에서의 보상과 제약을 평가하는데, 이 논문의 변형은 윈도우 끝이 아니라 예측된 종착점에서의 보상과 제약을 봅니다. 지금 서 있는 곳에서 몇 발짝 앞이 아니라, 이대로 가면 도착할 곳을 미리 당겨서 판단하겠다는 발상입니다.

왜 이런 선택이 필요할까요? 윈도우 끝에서의 평가는 매 스텝마다 조금씩 어긋나는 local truncation error를 쌓이게 만들기 때문입니다. 매번 근사한 값으로 결정을 내리면 오차가 복리로 쌓이죠. 반면 종착점 예측을 기준으로 삼으면 매번 같은 목적지를 바라보게 되니 오차가 한 방향으로 누적되는 것을 피할 수 있습니다. 내비게이션으로 치면 다음 교차로만 보고 핸들을 꺾는 대신, 목적지까지의 예상 도착 지점을 항상 화면에 띄워 두는 셈입니다.

여기서 논문이 덧붙이는 조건이 흥미롭습니다. 흐름의 dynamics가 천천히 바뀌는 구간에서는 이 terminal-estimate 변형이 provably 더 tight하다고 말하기 때문입니다. 흐름이 급격하게 꺾이지 않는다면 종착점 예측이 꽤 믿을 만하고, 그래서 윈도우 끝 평가보다 낫습니다. 반대로 흐름이 요동치는 구간에서는 예측 자체가 흔들릴 수 있으니, 그 조건을 함께 읽어야 합니다. 저는 이런 단서가 있는 주장을 좋아합니다. 언제 좋아지고 언제 깨질지를 함께 말해주기 때문입니다.

예측된 종착점에서 보상과 제약을 평가하는 terminal-estimate 개념도
예측된 종착점에서 보상과 제약을 평가하는 terminal-estimate 개념도

이론적 보장이 실제로 말해주는 것

이론 부분을 어떻게 읽어야 할까요? 논문은 표준적인 regularity 가정 아래에서 receding-horizon 근사의 suboptimality에 대한 finite-horizon 보장을 세우는데, 풀지 않은 긴 지평을 짧게 잘라서 생기는 손해가 어느 정도로 묶이는지를 보여준다는 뜻입니다. 추론 시점에 쓰는 방법에게는 이런 종류의 말이 꽤 소중합니다. 매번 근사를 쓰면서도 그 대가가 발산하지 않는다는 확신이 있어야 운영에 올릴 수 있으니까요.

한 걸음 더 들어가면 볼록-affine 구조 아래에서는 더 sharp한 bound가 나옵니다. 생략된 지평 길이에 대해 선형으로 커지는 형태인데, 지평을 얼마나 잘랐는지가 손해의 크기를 직접 정한다는 뜻이라 읽는 맛이 있습니다. 자른 만큼의 대가를 치른다는 것이니, 계산 예산과 품질 사이의 교환 관계를 숫자로 이야기할 수 있게 됩니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 윈도우를 두 배로 늘리면 wall-clock latency는 얼마나 늘고, 품질은 얼마나 좋아질까요? 논문의 bound는 그 질문에 대한 방향 감각을 줍니다.

물론 여기서 과장하지 말아야 합니다. Regularity 가정이나 볼록-affine 구조는 현실의 큰 생성 모델을 그대로 옮긴 것이 아니라 분석을 위한 무대이기 때문입니다. 저는 이 간극을 논문의 약점이라기보다 이론의 용도로 봅니다. 현실을 증명했다는 뜻이 아니라, 어떤 조건에서 이 근사가 망가지지 않는지를 보여주는 지도에 가깝다는 말입니다. 그래서 보장이 있다는 말을 곧바로 현장 보증처럼 읽으면 안 됩니다. 다만 짧게 보고 자주 고치는 전략이 완전히 감이 아니라 묶인 손해 안에서 움직인다는 점은 분명히 남습니다.

실험 숫자를 어떻게 읽어야 할까

실험은 저차원 환경과 고차원 환경, 그리고 최근 큰 규모의 flow matching 모델에서 이뤄졌다고 보고됩니다. 결과의 결은 일관되는데, 보상은 높게, 제약 만족은 강하게, 그러면서 미리 학습된 흐름에서의 이탈은 최근 baseline보다 적었다는 것입니다. 숫자가 아니라 구조를 봐야 하는 이유가 여기에 있습니다. 단순히 보상을 더 올렸다는 말이 아니라, 덜 벗어나면서 더 잘 지켰다는 말이니까요.

이 대목을 읽을 때는 비교의 축을 함께 봐야 합니다. 덜 벗어났다는 것은 deviation 비용을 기준으로 잰 것이고, 더 잘 지켰다는 것은 종착점 제약의 만족도로 잰 것이기 때문입니다. 두 축이 함께 좋아졌다는 점이 이 논문의 주장을 이룹니다. 만약 보상만 올랐는데 흐름에서 한참 멀어졌다면, 그 샘플이 원래 분포의 대표성을 잃었다는 의심을 받아야 하니까요. 반대로 제약을 지켰는데 보상이 무너졌다면 현장에서는 쓰기 어렵죠.

여기서는 조금 의심하는 태도가 필요합니다. Baseline이 정확히 무엇이었고, 보상의 스케일과 제약의 빡빡함이 어느 정도였는지는 원문의 세부 조건을 함께 봐야 하기 때문입니다. 논문의 요약만으로는 그 디테일까지 단정할 수 없습니다. 그럼에도 방향 자체는 분명합니다. 쌍대 변수를 Degrees of freedom 삼아 제약마다 세기를 조절하고, 종착점 예측으로 근사 오차를 줄인 설계가 보상과 제약과 이탈이라는 세 마리 토끼를 한 번에 노렸기 때문입니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 세 목표를 한 식에 넣되 제약을 조건으로 따로 세운 선택이 결과를 만든 셈이니까요.

볼록 구조에서 생략된 구간 길이에 따라 선형으로 커지는 오차 bound 설명 그림
볼록 구조에서 생략된 구간 길이에 따라 선형으로 커지는 오차 bound 설명 그림

운영 관점에서 보면 다음 질문이 바로 생깁니다

연구실 결과를 현장으로 가져오면 질문이 바뀝니다. 윈도우 길이를 얼마로 잡아야 할까요? 쌍대 변수를 업데이트하는 빈도와 스텝 크기는 latency에 얼마나 영향을 미칠까요? 종착점 예측을 매 스텝마다 돌리면 추가 forward 평가가 얼마나 들까요? 논문이 추론 시점의 계산 tractability를 이유로 짧은 윈도우를 택했다고 말할 때, 저는 그 뒤에 숨은 serving 비용이 궁금해집니다.

좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요? 큰 flow matching 모델에서는 벡터 필드 평가 한 번이 이미 비싸기 때문입니다. 여기에 짧은 윈도우 최적화와 종착점 예측이 얹히면 스텝당 비용이 늘어납니다. 그럼에도 전체 샘플 수나 재시도 횟수가 줄어서 총비용이 낮아질 수도 있습니다. 제약을 못 지켜서 버리는 샘플이 줄면 그 자체가 throughput이니까요. 저희 팀 관점에서도 이런 종류의 교환은 익숙합니다. 단위 스텝의 latency가 아니라 버려지는 샘플까지 포함한 유효 throughput으로 봐야 하기 때문입니다.

메모리와 병렬성도 함께 봐야 합니다. 쌍대 변수는 샘플마다 따로 굴러가는 작은 상태라 부담이 작지만, 윈도우 최적화를 위한 중간 궤적과 기울기는 메모리를 쓰기 때문입니다. 배치로 여러 샘플을 만들 때 그 오버헤드가 어떻게 커지는지가 관건이 됩니다. 논문이 다루는 범위를 넘어서는 이야기지만, 실제 도입을 고민한다면 이 지점을 먼저 재보는 것이 순서라고 생각합니다.

앞으로 제가 지켜보고 싶은 장면

그렇다면 이 흐름은 어디까지 이어질 수 있을까요? 제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째는 제약의 종류가 늘어날 때의 모습인데, 지금은 종착점의 hard 제약을 말하지만 현장의 제약은 종종 중간 궤적에도 걸리기 때문입니다. 관절 한계처럼 매 순간 지켜야 하는 running constraint까지 같은 틀로 품을 수 있을지가 궁금합니다.

둘째는 dynamics가 빠르게 바뀌는 구간에서의 움직임입니다. Terminal-estimate가 흐름이 천천히 바뀔 때 더 tight하다는 조건은 뒤집으면 질문이 되기 때문입니다. 흐름이 요동치는 초기 노이즈 근처에서는 예측이 얼마나 믿을 만할까요? 윈도우 길이를 구간에 따라 바꾸는 adaptive horizon 같은 장치가 붙으면 이야기가 더 재밌어질 것 같습니다.

셋째는 사람 손으로 정하는 제약과 학습된 보상 모델 사이의 충돌입니다. 보상은 대개 학습된 proxy이고, 제약은 물리나 규칙에서 오는데요. proxy 보상이 제약을 우회하는 방향으로 궤적을 밀 때 쌍대 변수가 그 줄다리기를 어디까지 버티는지가 실제 안전과 직결됩니다. 이 지점이야말로 제어라는 말이 시험받는 자리입니다.

이 논문이 남기는 감각을 한 문장으로 정리하면 이렇게 됩니다. 흐름을 존중하면서 조건을 지키는 일은 기울기를 더하는 기술이 아니라, 남은 구간을 내다보며 지금의 핸들을 고르는 판단의 연속이라는 말입니다. 그래서 다음에 추론 시점 유도를 만질 때는 묻고 싶어집니다. 지금 내가 더한 이 기울기는 종착점의 약속을 기억하고 있을까, 하고 말입니다.

저차원과 고차원 실험에서 보상과 제약 만족을 함께 보여주는 결과 개념도
저차원과 고차원 실험에서 보상과 제약 만족을 함께 보여주는 결과 개념도

참고 자료

  1. ConicFlow: constrained Inference-time optimal control for flow matching models · arxiv.org

    리뷰 원문