섞인 문제를 푸는 법: 절차를 먼저 고르고, 따져보고, 모아보는 추론

Route-Verify-Vote: Procedure-Conditioned Self-Consistency for Mixed-Domain Reasoning은 SCoRE 2026 평가에 참여한 연구진이 arXiv 식별자 2610.08814로 공개한 논문입니다. 원문은 제목 아래 연결되어 있습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 파라미터를 고치지 않고도 도메인 표시를 절차 선택에 연결한 뒤 검증과 집합 단위 투표를 거치면 낯선 혼합 문제에서 완전한 정답 집합을 더 안정적으로 찾을 수 있다는 것입니다.

왜 이런 접근이 나왔는지 궁금하실 텐데요. SCoRE 2026은 학습 때 보지 못한 세 가지 혼합 도메인에서 조합 일반화를 평가하고, 문항마다 옳은 보기를 빠짐없이 전부 고르도록 요구합니다. 하나만 맞히면 되는 시험이 아니라 정답 집합 전체가 맞아야 점수를 받는 시험이죠. 그래서 이번 글에서는 라우팅과 검증, 투표가 각각 무엇을 맡는지, 16개 샘플 투표에서 나온 74.6%라는 수치가 어디에서 77.3%와 79.4%까지 이동했는지, 그리고 전체 2위라는 결과가 말해주는 것과 말해주지 않는 것을 차례로 짚어보겠습니다.

익숙한 조각인데 왜 섞어 놓으면 헷갈릴까요

저도 처음에는 이런 의문이 들었습니다. 개별 추론 연산은 학습 때 충분히 봤는데, 그걸 낯선 방식으로 섞었다고 갑자기 성능이 무너지는 이유가 무엇일까 하고요. 그런데 문제를 직접 상상해보니 감이 왔습니다. 따로따로 풀 때는 각 단계의 규칙이 분명한데, 막상 섞이면 어떤 규칙을 언제 적용해야 하는지부터 흐려지기 때문입니다. 수학 시험에서 배운 공식은 아는데, 응용 문제에서 어떤 공식을 꺼내야 할지 몰라 멈칫하는 장면과 비슷합니다.

논문이 진단하는 지점도 여기에 있습니다. 모델이 연산 자체를 몰라서 틀리는 경우보다, 낯선 조합 앞에서 제약 조건을 어떻게 표현하고 어떤 순서로 적용할지 흔들리다가 틀리는 경우가 많다는 것이죠. 이때 무작정 샘플을 많이 뽑아 다수결을 하면 어떻게 될까요. 흔들리는 절차가 매번 다른 답을 내놓으니 표가 갈리고, 그럴수록 운에 기대는 투표가 됩니다. 그래서 연구진은 샘플 수를 늘리기 전에 절차를 먼저 고정하자는 쪽을 택했습니다. 도메인 표시라는 단서를 보고 추론 절차를 고른 뒤, 그 절차에 맞춰 답을 만들고 검증하겠다는 발상입니다.

제가 이 논문에서 가장 눈여겨본 부분은 바로 이 순서입니다. 답을 먼저 뽑는 것이 아니라 문제를 푸는 방식을 먼저 정한다는 것이죠. 등산으로 치면 정상만 바라보고 출발하는 대신, 지도에서 코스를 먼저 고르고 장비를 점검한 뒤에 발걸음을 옮기는 셈입니다. 이런 순서를 바꾸는 것만으로 이후 단계가 훨씬 안정됩니다. 뒤에서 살펴볼 검증과 투표는 모두 이 선택 위에 서 있기 때문입니다.

정답 하나가 아니라 집합 전체를 맞히라는 요구는 뭐가 다를까요

SCoRE 2026의 채점 방식은 평소 벤치마크와 결이 다릅니다. 보기 중 정답 하나를 고르고 끝내는 형태와 달리, 옳은 보기를 빠짐없이 전부 골라낸 집합이 정답과 정확히 일치해야 합니다. 하나를 빼먹어도 틀리고, 하나를 더해도 틀립니다. 부분 점수가 넉넉하지 않은 셈인데요. 이런 조건에서는 모델이 아는 것과 모르는 것의 경계가 훨씬 날카롭게 드러납니다.

왜냐하면 단일 정답 문제에서는 그럴듯한 보기 하나에 표가 몰리면 운 좋게 맞힐 수 있는데, 집합 문제에서는 그런 요행이 통하지 않기 때문입니다. 네 개의 보기 중에서 두 개가 정답인 문항을 떠올려 보시면 됩니다. 모델이 첫 번째 정답에는 확신을 가져도 두 번째 정답 앞에서 머뭇거리면 전체 집합은 어긋납니다. 반대로 확신 없는 보기를 하나 더 얹으면 그것대로 오답이 됩니다. 그래서 집합 정확도는 모델의 판단 일관성을 그대로 비춥니다.

여기서 재미있는 질문이 생깁니다. 그렇다면 표를 셀 때도 보기 단위가 아니라 집합 단위로 세어야 하지 않을까요. 각 보기마다 따로 다수결을 하면 보기별로는 그럴듯해 보여도 전체 조합이 어긋나는 경우가 생깁니다. 연구진이 투표 단위를 완전한 답안 집합으로 잡은 이유는 여기에 있습니다. 집합째로 모아야 채점 기준과 판단 기준이 같은 눈높이에 놓이기 때문입니다. 저는 이 선택을 보고 채점 방식을 먼저 읽은 설계라고 느꼈습니다. 평가가 묻는 것을 정확히 세겠다는 태도니까요.

절차를 먼저 고른다는 발상은 어떻게 작동할까요

Route 단계는 이름 그대로 길을 고르는 일입니다. 문제에 딸려 온 도메인 표시를 보고, 어떤 추론 절차를 쓸지 정합니다. 절차라고 해서 거창한 것을 떠올리실 필요는 없습니다. 제약을 어떻게 표현하고 어떤 순서로 적용할지에 대한 약속에 가깝습니다. 예를 들어 어떤 도메인에서는 조건을 표로 정리한 뒤 하나씩 대조하는 편이 낫고, 다른 도메인에서는 전제를 문장으로 풀어쓴 뒤 충돌 여부를 살피는 편이 나을 수 있습니다. 도메인 표시가 바로 그 선택을 이끄는 이정표가 됩니다.

이 방식이 일반적인 자기 일관성 기법과 갈라지는 지점은 여기 있습니다. 보통 자기 일관성은 같은 프롬프트에서 여러 답을 뽑아 가장 잦은 답을 고릅니다. 절차가 매번 조금씩 달라져도 그러려니 하고 표를 셉니다. 반면 이 논문은 절차를 먼저 묶어둡니다. 같은 절차 아래에서 답을 뽑으니 샘플마다 흔들리는 폭이 줄어들고, 표가 같은 집합에 모일 가능성이 커집니다. 요리 비유를 들면 매번 레시피를 바꿔가며 맛을 보는 대신, 레시피를 하나 정해두고 간만 여러 번 보는 셈이죠.

물론 여기서 곧바로 반문이 나옵니다. 도메인 표시가 시험장에서 매번 주어질까요. 실제 서비스에서는 도메인이 분명하지 않거나 여러 도메인이 뒤섞인 입력이 흔합니다. 논문은 평가 형식을 따라 제공된 표시를 쓰는 쪽을 택했는데, 이 선택 덕분에 절차 고정이 깔끔해집니다. 대신 표시가 없거나 틀렸을 때 성능이 어떻게 흔들리는지는 별도로 물어야 합니다. 저는 이 대목을 읽으면서 절차 고정이 주는 안정과 표시 의존이 만드는 위험이 한 쌍으로 움직인다고 느꼈습니다. 뒤에서 모델 조합 이야기가 나오는 것도 이런 맥락과 연결됩니다.

하나씩 따져보는 검증은 무엇을 바꾸나요

Verify 단계는 답을 고르기 전에 보기를 하나씩 따져보는 과정입니다. 모델에게 추론 절차에서 정리된 제약을 건네주고, 각 보기가 그 제약을 만족하는지 평가하게 합니다. 한 번 훑고 정답 번호를 찍는 대신, 보기마다 근거를 묻는 셈입니다. 시험장에서 OMR 카드에 표시하기 전에 각 문항 옆에 작게 참과 거짓을 적어보는 습관과 비슷합니다. 손은 조금 더 가지만 실수가 눈에 띄게 줄어듭니다.

이 검증이 절차와 맞물릴 때 효과가 커집니다. 절차 없이 검증만 하면 모델이 매번 다른 잣대를 들이댈 수 있는데, 절차가 먼저 정해져 있으면 잣대가 고정됩니다. 같은 잣대로 모든 보기를 재니 보기 사이의 비교가 공정해집니다. 게다가 파라미터를 업데이트하지 않고 프롬프트 수준에서 검증을 얹으니 학습 파이프라인을 새로 돌릴 필요가 없습니다. 이미 배포된 모델 위에 얹는 사후 절차로 쓸 수 있다는 뜻이죠. 저희가 새로운 AI 아키텍처를 볼 때도 갱신 비용과 서빙 구조를 함께 보는데, 이런 무갱신 설계는 도입 문턱을 낮추는 편입니다.

다만 검증 자체가 완벽하지는 않습니다. 모델이 스스로 만든 제약을 스스로 평가하니, 제약 표현이 어긋나면 검증도 같은 방향으로 어긋날 수 있습니다. 자기 채점은 관대해지기 쉬운 법이죠. 그래서 검증 단독의 힘보다는 절차 고정과 집합 투표가 함께 만드는 구조로 읽어야 합니다. 검증은 그 구조 안에서 표를 모으기 전에 노이즈를 걷어내는 체에 가깝습니다. 체가 촘촘하면 뒤에서 셀 표가 깨끗해지니까요.

다수결인데 왜 집합째로 묶어서 셀까요

Vote 단계는 여러 개의 완전한 답안 집합을 뽑아 가장 잦은 집합을 고르는 일입니다. 보기별 득표와 달리 집합별 득표라는 점이 다릅니다. 16개 샘플을 뽑아 집합 단위로 세었을 때 공식 테스트에서 74.6%의 집합 정확도가 나왔다는 보고가 바로 이 단계의 결과입니다. 숫자를 풀어보면, 한 번 찍어 맞힌 비율을 뜻하지 않습니다. 열여섯 번 두드려 가장 자주 나온 묶음을 낸 정확도가 74.6%라는 뜻입니다.

왜 집합째로 세는지 다시 짚어보겠습니다. 보기별로 세면 각 보기는 과반을 얻어도 그 과반을 만든 표가 서로 다른 샘플에서 왔을 수 있습니다. 보기 A는 샘플 1번 무리에서, 보기 B는 샘플 2번 무리에서 지지받은 식이죠. 그렇게 합친 집합은 실제로는 아무도 온전히 지지하지 않은 조합일 수 있습니다. 반면 집합째로 세면 그런 꿰맞춤이 사라집니다. 온전한 답안으로 16표가 나뉘니 가장 많은 표를 받은 묶음은 적어도 여러 샘플이 같은 형태로 동의했다는 뜻이 됩니다.

그렇다면 왜 하필 16개일까요. 샘플을 늘리면 표본이 안정되지만 비용도 함께 늘어납니다. 16개는 완전한 무작위보다는 안정적이면서도, 뒤에서 설명할 적응형 추가 샘플을 얹을 여지를 남기는 크기입니다. 저는 이 숫자보다 그 뒤의 집계 단위가 더 중요하다고 봅니다. 무엇을 세는지를 바꾸면 같은 16표라도 전혀 다른 판단이 되기 때문입니다. 채점이 집합을 묻는데 집계가 보기를 묻는다면 처음부터 눈높이가 어긋나니까요.

박빙인 문제에만 예산을 더 쓰는 판단은 합리적일까요

적응형 투표는 모든 문항에 같은 샘플을 쓰지 말자는 제안입니다. 1등 집합과 2등 집합의 표 차이가 작아서 승부가 박빙인 문항에만 샘플을 더 투입합니다. 보고된 수치를 보면 기본 투표 74.6%에서 적응형 적용 뒤 77.3%로 정확도가 올라갑니다. 2.7%포인트 상승인데요. 전체 문항에 일괄 증량하는 대신 어려운 문항에만 얹어서 얻은 개선이라는 점에서 계산이 깔끔합니다.

개표소 풍경을 떠올리시면 이해가 빠릅니다. 격차가 크게 벌어진 투표함까지 굳이 몇 번씩 다시 셀 필요는 없습니다. 표 차이가 한두 표인 곳에 인력을 몰아넣는 편이 전체 정확도를 끌어올리는 데 유리합니다. 모델 추론도 마찬가지입니다. 쉬운 문항은 적은 표로도 결론이 흔들리지 않는데, 어려운 문항은 표 몇 개에 1등이 뒤집힙니다. 그래서 표 차이인 마진을 난이도 신호로 쓰는 것입니다. 마진이 작으면 불확실하다는 뜻이니 예산을 더 주고, 마진이 크면 그대로 확정합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 적응형 예산은 평균 비용을 아끼지만 최악 지연을 늘릴 수 있습니다. 쉬운 문항은 빨리 끝나도 어려운 문항에서 추가 호출이 길어지니, 배치 전체가 끝나는 시간은 박빙 문항에 끌려갑니다. 실시간 서비스에서 꼬리 지연은 체감 품질과 직결됩니다. 그럼에도 연구 관점에서는 의미 있는 선택입니다. 같은 총량이라도 어디에 쓰는지에 따라 결과가 달라진다는 점을 보여주기 때문입니다. 저는 그래서 이 2.7%포인트를 단순 상승보다 예산 사용법의 교훈으로 읽었습니다. 어려운 곳에 더 쓰는 원칙은 다른 샘플링 기법에도 그대로 옮길 수 있으니까요.

모델을 바꿔 타는 선택은 언제 득이 될까요

보고서에서 눈에 띄는 대목은 도메인 경로별로 모델을 달리 써서 79.4%까지 올렸다는 부분입니다. 적응형 77.3%에서 다시 2.1%포인트를 얹은 셈입니다. 최종 순위는 참가 시스템 중 2위였습니다. 해석은 이렇습니다. 모든 도메인에 가장 강한 단일 모델이 있는 것이 아니라, 도메인마다 상대적으로 잘 맞는 모델이 따로 있다는 것이죠. 그래서 경로별로 모델을 고르면 전체 평균이 올라갑니다.

이 발상은 실무 감각과 잘 맞습니다. 하나의 거대 모델로 모든 입력을 처리하는 대신, 입력 성격에 따라 특화된 모델에 나눠 맡기면 효율이 좋아질 때가 많습니다. 번역은 번역에 강한 모델에, 코드는 코드에 강한 모델에 맡기는 것과 비슷합니다. (물론 실제 운영에서는 라우터 자체의 오류와 모델별 지연 편차가 함께 따라오는데요. 그 비용을 감안해도 남는지를 따져야 합니다.) 논문이 보여준 것은 도메인 표시라는 신호가 모델 선택에도 쓸모 있다는 점입니다. 절차를 고르는 신호와 모델을 고르는 신호를 같은 단서에서 뽑으니 구조가 단순해집니다.

그런데 이 결과를 일반화할 때는 조건을 봐야 합니다. 어떤 모델들을 후보에 올렸는지, 선택 기준이 테스트에 과하게 맞지는 않았는지에 따라 해석이 달라집니다. 후보군이 바뀌면 79.4%라는 수치도 함께 움직일 수 있습니다. 저는 이 숫자에서 단일 모델의 우위보다 조합 설계의 여지를 읽는 편이 안전하다고 봅니다. 경로가 갈리는 문제에서는 단일 강자보다 상황에 맞는 조합이 유리할 수 있다는 교훈이니까요. 2위라는 순위도 같은 맥락입니다. 1등과의 격차보다 어떤 구조로 거기까지 올라갔는지가 다음 설계에 더 많은 힌트를 줍니다.

이 숫자를 그대로 믿기 전에 어떤 조건을 봐야 할까요

74.6%와 77.3%, 79.4%라는 수치는 나란히 놓으면 매끈한 상승 곡선처럼 보입니다. 그런데 실험을 읽을 때는 상승폭보다 각 단계에서 무엇이 달라졌는지를 먼저 봐야 합니다. 기본 투표에서 적응형으로 넘어갈 때는 집계 방식과 샘플 배분이 바뀌었고, 모델 조합으로 넘어갈 때는 추론 주체 자체가 바뀌었습니다. 바뀐 것이 하나가 아니니 세 수치를 같은 막대 위에 올려놓고 단순 비교하면 안 됩니다. 각 수치는 각 조건 아래의 성적표로 읽어야 합니다.

또 하나 짚을 점은 집합 정확도의 엄격함입니다. 전부 맞아야 맞은 것으로 치니 수치가 낮게 보이는 대신, 맞았을 때의 신뢰는 두둑합니다. 거꾸로 말하면 74.6%라는 숫자는 보기 단위 정답률로 환산하면 훨씬 높게 보일 수 있습니다. 평가가 무엇을 재는지를 모르면 숫자의 결이 달라 보입니다. 저는 보고서를 볼 때 분모와 채점 규칙을 먼저 확인하는 편인데, 이번에도 그 습관이 도움이 됐습니다. 완전 일치 기준에서 70%대 중반이면 흔들리는 절차를 꽤 잘 붙잡았다는 뜻이기 때문입니다.

여기서 한 걸음 더 들어가 보겠습니다. 절차 고정과 검증, 집합 투표 중에서 어느 부품이 가장 큰 몫을 했을까요. 보고서가 주는 인상은 세 장치가 맞물려 돌아간다는 쪽입니다. 절차가 흔들리면 검증 잣대가 흔들리고, 검증이 부실하면 투표함에 노이즈가 쌓입니다. 반대로 절차가 고정되면 검증이 쉬워지고, 검증이 깨끗하면 표가 모입니다. 이런 맞물림은 제거 실험을 해석할 때 주의가 필요합니다. 하나를 뺐을 때 떨어진 폭이 그 부품만의 순수 기여라고 단정하기 어렵기 때문입니다. 빠진 부품의 빈자리를 다른 부품이 메우거나, 반대로 연쇄적으로 무너지기도 하니까요. 그래서 저는 각 제거 수치를 부품별 점수표가 아니라 구조의 결속도로 읽었습니다.

실제 서비스에 올린다면 무엇이 먼저 걸릴까요

논문 속 설계는 파라미터를 고치지 않으니 도입이 가벼워 보입니다. 학습 파이프라인을 다시 돌릴 필요가 없고, 프롬프트와 집계 로직으로 구현되니까요. 그런데 막상 운영을 떠올리면 계산이 달라집니다. 문항마다 16개 집합을 뽑고, 박빙이면 추가 샘플을 뽑고, 보기마다 검증을 돌리면 호출량이 빠르게 불어납니다. 정확도는 올라가도 토큰 비용과 지연이 함께 올라가는 구조입니다. 배치 평가에서는 감당할 만해도 실시간 대화에서는 부담이 될 수 있습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 호출량을 어디에서 줄일 수 있을까 하고요. 검증 호출을 가볍게 만들거나, 쉬운 문항은 일찍 멈추거나, 캐시를 두텁게 쓰는 방법이 떠오릅니다. 적응형 예산이 이미 그런 방향의 한 걸음입니다. 박빙이 아닌 문항은 일찍 확정하니 평균 비용이 내려갑니다. 다만 앞서 짚었듯 꼬리 지연은 남습니다. 몇 개 문항이 길어지면 전체 배치가 그 문항을 기다립니다. 스트리밍 응답이 필요한 서비스라면 확정 전 중간 상태를 어떻게 보여줄지도 설계해야 합니다.

메모리와 대역폭 측면에서는 상대적으로 홀가분합니다. 가중치를 바꾸지 않으니 모델 바이너리는 그대로 두고, 라우팅 표와 집계 로직만 곁에 두면 됩니다. 도메인 표시를 읽어 절차와 모델을 고르는 라우터는 작게 만들 수 있습니다. 문제는 라우터가 틀렸을 때입니다. 엉뚱한 절차를 골라주면 이후 검증과 투표가 모두 엉뚱한 길 위에서 정교해집니다. 그래서 운영에서는 라우터의 오류율을 별도로 재고, 확신이 낮을 때는 기본 절차로 돌려보내는 안전장치가 필요합니다. 저는 이런 장치를 포함한 전체 지연 분포를 봐야 도입 판단이 선다고 봅니다. 평균 정확도 하나만으로는 서빙 결정을 내리기 어렵기 때문입니다.

그래서 저는 앞으로 무엇을 보고 싶어졌을까요

정리하기 전에 처음으로 돌아가 보겠습니다. 이 연구는 낯선 조합 앞에서 절차를 먼저 고정하자는 제안을 내놓았고, 검증과 집합 투표로 그 고정을 점수까지 연결했습니다. 74.6%에서 77.3%, 다시 79.4%로 이어지는 수치는 각 장치가 제 몫을 했다는 신호로 읽힙니다. 참가 시스템 중 2위라는 자리도 뒤따랐습니다. 여기까지는 보고서가 말해주는 사실입니다.

제가 앞으로 보고 싶은 것은 그다음 장면입니다. 첫째, 도메인 표시 없이 절차를 고를 수 있을까요. 표시가 없는 입력에서도 스스로 절차를 고르고, 그 선택의 확신까지 함께 내놓는다면 실용성이 크게 넓어집니다. 둘째, 검증이 스스로 만든 잣대를 스스로 바로잡을 수 있을까요. 외부의 작은 검증기라도 곁에 두면 자기 채점의 관대함을 줄일 수 있을지 궁금합니다. 셋째, 적응형 예산을 지연 예산과 함께 쓸 수 있을까요. 정확도 목표와 지연 상한을 함께 걸고 샘플을 배분하는 규칙까지 가면 운영 이야기로 바로 이어집니다.

이런 질문을 품고 나면 처음의 등산 비유가 다시 떠오릅니다. 코스를 고르고, 발걸음마다 표식을 확인하고, 갈림길에서 다수의 발자국을 따르는 방식은 산에서도 낯설지 않습니다. 모델 추론에서도 같은 태도가 통했다는 점이 이번 연구가 남긴 감각에 가깝습니다. 그렇다면 사람의 역할은 무엇일까요. 절차를 고르는 기준을 더 잘 쓰고, 검증의 잣대를 더 믿을 만하게 다듬는 일은 여전히 사람의 몫으로 남습니다. 저는 그 경계가 어디까지 밀려나는지를 다음 보고서에서 확인하고 싶습니다.