AI가 문제를 푸는 방식: 데이터가 꼭 답일까? (TSP Solver 사례)

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 AI 기술의 발전 속도는 현기증이 날 정도입니다. 하루가 멀다 하고 쏟아지는 새로운 모델들과 논문들을 보면서, 우리는 종종 '거대함'에 압도되곤 합니다. 더 많은 데이터, 더 큰 파라미터, 더 오랜 학습 시간이 곧 성능이라는 공식이 마치 진리처럼 받아들여지는 시대죠. 하지만 가끔은 이런 거대한 흐름을 거스르는, 작지만 날카로운 시도들이 엔지니어로서의 본질을 일깨워주곤 합니다. 오늘은 최근 Hacker News에서 꽤 흥미롭게 지켜본 TSP(Traveling Salesperson Problem, 외판원 순회 문제) Solver 프로젝트 이야기를 통해, AI가 문제를 해결하는 방식에 대한 근본적인 질문을 던져보려 합니다.

대부분의 딥러닝 기반 TSP 접근법은 공식이 정해져 있습니다. 엄청난 양의 TSP 데이터셋을 모으고, 이를 통해 모델을 사전 학습(Pre-training)시킵니다. "이런 패턴의 도시 배치에서는 저런 경로가 효율적이다"라는 일반적인 지식을 모델에 주입하는 것이죠. 그런데 이번에 소개된 'Per-instance TSP Solver'는 이 전제를 완전히 뒤집었습니다.

"사전 학습 없이, 지금 눈앞에 닥친 이 문제(Instance) 하나만을 위해 즉석에서 학습하면 어떨까?"

이 프로젝트의 개발자는 다른 문제들로부터 얻은 지식(Prior knowledge) 없이, 오직 현재 주어진 도시들의 좌표만을 가지고 PPO(Proximal Policy Optimization) 강화학습을 돌렸습니다. 결과는 놀라웠습니다. 단일 A100 GPU로 약 5.6시간 만에 TSPLIB d1291(1291개의 도시 문제)에서 최적 해와의 격차(Gap)를 1.66%까지 좁혔습니다. 데이터셋 없이, 오직 시행착오만으로 이 정도 수준에 도달했다는 건 시사하는 바가 큽니다.

이 프로젝트의 핵심 가설이 정말 인상적이었습니다. 개발자는 TSP의 최적 해가 대부분 '가장 가까운 이웃(Minimum edges)'들로 연결되지만, 문제를 어렵게 만드는 건 지역적인 범위를 벗어나는 소수의 '예외 엣지(Exception edges)' 때문이라고 보았습니다. 그래서 무작정 데이터를 때려 붓는 대신, 이 예외 엣지의 위상적, 기하학적 구조를 기반으로 한 'Inductive bias(귀납적 편향)'를 설계했습니다.

쉽게 말해, AI에게 "모든 걸 데이터로 배워라"고 하는 대신, "이 문제는 기하학적으로 이런 특성이 있으니, 이걸 힌트 삼아 풀어봐"라고 가이드를 준 셈입니다. 에이전트는 이 구조적 가이드를 바탕으로 유망한 경로를 탐색하고, 나머지는 강화학습의 시행착오를 통해 채워 나갔습니다.

여기서 우리가 주목해야 할 점은 '데이터의 양'이 아니라 '문제에 대한 이해'입니다.

풀링포레스트에서 AI를 활용해 기업의 일하는 방식을 혁신하려 할 때도 비슷한 고민에 부딪힙니다. 우리는 종종 문제 해결의 열쇠가 '더 많은 데이터 확보'에 있다고 착각합니다. "고객 데이터를 더 모아야 해", "로그를 더 쌓아야 해"라며 인프라 비용을 늘리지만, 정작 문제의 본질인 'Why'를 놓치는 경우가 많습니다.

이 TSP Solver 사례는 우리에게 기술적 의사결정의 중요한 힌트를 줍니다.

1. Domain Knowledge의 힘은 여전히 강력합니다.
   AI가 만능은 아닙니다. 문제의 특성(여기서는 TSP의 기하학적 구조)을 깊이 이해하고 이를 모델 설계에 반영(Inductive bias)했을 때, 무식하게 데이터를 학습시키는 것보다 훨씬 효율적인 결과를 낼 수 있습니다. 우리가 현업에서 마주하는 비즈니스 로직들도 마찬가지일 겁니다. 단순히 LLM에게 "알아서 해줘"라고 던지는 것보다, 우리 비즈니스의 구조적 특성을 프롬프트나 아키텍처에 녹여내는 것이 훨씬 중요합니다.

2. 일반화(Generalization)만이 정답은 아닙니다.
   우리는 습관적으로 '모든 상황에 대처 가능한 범용 모델'을 만들고 싶어 합니다. 하지만 때로는 '지금 당장 눈앞의 이 문제 하나'를 극도로 잘 푸는 솔루션이 필요할 때가 있습니다. 사전 학습 없이 인스턴스별로 최적화하는 접근 방식은, 매번 상황이 급변하는 비즈니스 환경에서 오히려 더 유연한 전략이 될 수 있습니다. "모든 고객을 위한 추천 시스템"보다 "지금 들어온 이 고객만을 위한 실시간 최적화"가 더 가치 있을 수 있다는 뜻이죠.

물론 5.6시간이라는 추론 시간은 실시간 서비스에 적용하기엔 깁니다. 하지만 이 시도가 보여준 가능성은 명확합니다. 거대 모델과 빅데이터의 홍수 속에서도, 문제를 집요하게 파고드는 엔지니어의 통찰력과 수학적 사고가 여전히 빛을 발할 수 있다는 사실입니다.

솔직히 말해, 저 역시 CTO로서 기술 트렌드를 쫓다 보면 "이거 그냥 LLM 쓰면 해결되는 거 아니야?"라고 안일하게 생각할 때가 있습니다. 하지만 그럴 때마다 뼈저리게 느낍니다. 도구는 도구일 뿐, 문제를 정의하고 해결의 실마리를 설계하는 건 결국 사람의 몫이라는 것을요.

기술 리더로서 여러분은 지금 어떤 선택을 하고 계신가요? 남들이 다 하는 대로 거대 모델과 데이터셋 뒤에 숨어 계신가요, 아니면 문제의 본질을 꿰뚫는 날카로운 가설을 세우고 계신가요?

데이터가 없어도 문제를 풀 수 있습니다. 우리가 그 문제를 진정으로 이해하고 있다면 말이죠. 오늘도 복잡한 문제 앞에서 씨름하고 계실 모든 개발자분들을 응원합니다.