요즘 프론티어 모델 비교는 대부분 벤치마크 점수표로 이뤄지잖아요. 그런데 한 개발자가 조금 다른 방식의 실험을 공유했어요. Anthropic의 Fable 5와 OpenAI의 GPT-5.6 Sol에게 NP-하드 문제를 던져놓고, 목표 지향 기능인 /goal을 켰을 때와 껐을 때 결과가 어떻게 달라지는지 관찰한 건데요. 정답이 정해진 시험문제가 아니라 '끝없이 더 좋은 답이 존재하는' 문제로 모델을 굴려봤다는 점이 흥미로워요.
NP-하드 문제가 뭐냐면
NP-하드가 뭐냐면, '답을 확인하는 건 쉬운데 최적의 답을 찾는 건 끔찍하게 어려운' 문제 부류예요. 대표적인 게 외판원 문제(TSP)인데요. 여러 도시를 최단 경로로 도는 순서를 찾는다고 해보세요. 경로 하나의 길이를 재는 건 초등 산수지만, 가능한 순서의 수는 도시가 늘수록 폭발적으로 증가해서, 도시 수십 개만 돼도 모든 경우를 다 확인하는 건 우주가 끝날 때까지 계산해도 못 끝내요. 그래서 실무에서는 '최적해'를 포기하고 '충분히 좋은 해'를 빠르게 찾는 휴리스틱을 쓰죠.
이게 LLM 평가에 왜 좋냐면요. 첫째, 문제 인스턴스를 무작위로 새로 만들 수 있어서 모델이 학습 데이터에서 답을 외웠을 가능성이 없어요. 둘째, 점수가 이분법이 아니라 연속적이에요. '맞았다/틀렸다'가 아니라 '얼마나 좋은 해를 찾았나'로 미세하게 비교할 수 있거든요. 셋째, 채점이 기계적으로 확실해서 벤치마크 오염 논란에서 자유로워요.
실험의 핵심: /goal은 뭘 바꾸나
/goal 기능이 뭐냐면, 모델에게 '이 세션의 목표는 이것'이라고 명시적으로 선언해서, 모델이 한 번 답하고 끝내는 게 아니라 그 목표를 향해 스스로 작업을 이어가게 만드는 장치예요. 일반 프롬프트에서는 모델이 그럴듯한 해를 하나 내놓고 완료를 선언하는 경향이 있는데, 목표가 걸려 있으면 '아직 더 개선할 수 있지 않나?'를 스스로 묻게 되는 거죠.
실제로 이런 문제를 받은 모델들이 일하는 방식을 보면 재미있는데요. 답을 직접 '말하는' 게 아니라, 알고리즘 엔지니어처럼 행동해요. 먼저 탐욕(greedy) 알고리즘으로 초기 해를 만들고, 2-opt 같은 국소 탐색으로 다듬고, 시간이 남으면 담금질 기법(simulated annealing) 같은 고전 휴리스틱까지 꺼내 쓰죠. 결국 승부는 '어느 모델이 더 똑똑한가'보다 '어느 모델이 개선 루프를 더 끈질기게, 더 영리하게 도는가'에서 갈리는 경우가 많아요. 목표를 명시하면 조기에 만족하고 멈추는 현상이 줄어드는 대신, 같은 자리를 맴돌며 예산만 태우는 위험도 생기고요. 그래서 이런 실험에서는 동일한 시간과 토큰 예산을 걸어두고 최종 해의 품질을 비교하는 게 공정한 설계예요.
업계 맥락에서 보면
이건 요즘 업계 흐름과 정확히 맞닿아 있어요. ARC-AGI나 FrontierMath 같은 벤치마크가 '모델이 얼마나 똑똑한가'를 재려 한다면, 이런 최적화 실험은 '모델에게 도구와 시간을 주면 얼마나 일을 잘하는가', 즉 에이전트로서의 역량을 재는 쪽이거든요. DeepMind의 AlphaEvolve가 LLM으로 코드를 진화시켜 행렬 곱셈 알고리즘을 개선한 것도 같은 계열이고요. 모델 자체의 성능 못지않게, 목표 관리·반복·검증 같은 하네스 설계가 결과를 좌우한다는 게 점점 분명해지고 있어요.
실무에 가져갈 것
배차, 스케줄링, 재고 배분처럼 조합 최적화 성격의 문제를 다루는 분이라면 시사점이 커요. LLM에게 답을 직접 물어보지 마세요. 대신 평가 함수를 먼저 만들고, LLM에게는 '이 점수를 올리는 솔버 코드를 작성하고, 실행 결과를 보고 개선하라'는 루프를 시키는 거예요. OR-Tools 같은 검증된 솔버와 조합하면 더 좋고요. 목표를 명시적으로 걸어주는 것만으로 결과물이 달라진다는 것도 프롬프트 설계에 바로 써먹을 수 있는 팁이에요.
한 줄로 정리하면, '모델 지능보다 일하게 만드는 구조가 결과를 좌우한다'는 실험이에요. 여러분은 에이전트에게 열린 문제를 맡길 때 어떤 장치로 조기 만족을 막고 계신가요?
🔗 출처: Hacker News