Fortytwo의 CEO 겸 공동 창업자 Ivan Nikitin – 인터뷰 시리즈

Ivan Nikitin은 Fortytwo의 CEO 겸 공동 창업자로, 여러 AI 모델이 함께 추론하고 서로의 결과를 평가하는 스웜 추론 기술을 개발하고 있다. 그는 게임, 대화형 AI, 생성형 AI 분야와 Temporal 및 Sensorium에서의 인터랙티브 시스템 개발 경험을 두루 갖추고 있다. 2011년 Vlad Larin과 함께 Temporal을 공동 창업했으며, 현재 Vlad Larin은 Fortytwo의 공동 창업자이자 CTO다. 이 과정에서 진화하는 에이전트 집단과 전문화된 모델을 결합하는 시스템을 구축하는 경험을 쌓았다.

Fortytwo는 추론 과정에서 모델들이 협력할 수 있도록 지원하는 AI 인프라를 구축한다. Fortytwo Engine은 Swarm Decoder를 사용해 진행 중인 공동 추론 과정을 조정하며, 장시간 작업에서 정확도를 높이고 불필요한 토큰 생성을 줄이는 것을 목표로 한다. 개발자에게는 Fortytwo Engine을 통한 API를 제공하고, Fortytwo Harbor를 통한 온프레미스 배포도 지원한다.

Fortytwo를 공동 창업하기 전, Sensorium과 Temporal에서 대화형 AI, 생성형 AI, 인터랙티브 시스템을 활용한 제품을 수년간 개발하셨습니다. 이러한 경험은 개별 대규모 언어 모델의 한계에 대한 관점을 어떻게 형성했으며, 궁극적으로 Fortytwo의 기반이 된 스웜 접근 방식으로 이어졌나요?

저를 포함해 우리 팀의 상당수는 게임을 통해 AI 분야에 발을 들였습니다. 게임은 개인용 컴퓨팅과 현대 AI의 산실이었습니다. 게임이 있었기에 GPU가 탄생했고, 게임 플레이는 강화 학습의 첫 본격적인 실험장이었습니다. 게임 세계는 학습하고 적응하며 경쟁하는 에이전트를 구축할 수 있는 실용적인 환경을 제공했습니다. 2011년 Vlad Larin과 함께 공동 창업한 Temporal에서는 진화하는 지능, 즉 선택 압력 속에서 경쟁하는 에이전트 집단을 연구하기 시작했습니다. 우리는 각 에이전트의 가장 뛰어난 기여를 찾아내고 이를 발전시킬 효과적인 메커니즘만 있다면, 집단이 개별 에이전트보다 더 많은 성과를 낼 수 있는지에 관심이 있었습니다. 선택과 평가는 지능을 바라보는 우리의 사고에서 핵심적인 요소가 됐습니다. 현재 Vlad Larin은 Fortytwo의 공동 창업자이자 CTO입니다.

트랜스포머 모델이 등장하면서 우리는 대화형 AI 분야로 영역을 넓혔고, 기억력과 개성을 갖춘 AI 캐릭터가 정해진 대본 없이 자유롭게 대화를 이어갈 수 있는 플랫폼을 만들었습니다. 이는 ChatGPT가 나오기 몇 년 전의 일이었으며, 당시 우리가 사용하던 모델의 컨텍스트 창은 512~1,024토큰에 불과했습니다. 초기 언어 모델 하나가 그 경험에 필요한 여러 요구 사항을 모두 안정적으로 처리하리라고 기대하는 것은 불가능했습니다. 그래서 각 모델이 더 좁은 범위의 역할을 맡도록 전문화된 모델로 구성된 맞춤형 파이프라인을 만들고, 각 모델의 기여를 결합하는 로직도 개발해야 했습니다. 전체 경험이 제대로 작동하려면 응답을 순위화하고 선택하는 과정이 필수적이었습니다. 이 경험을 통해 제한된 모델들을 잘 설계된 시스템으로 결합하면 얼마나 많은 역량을 끌어낼 수 있는지 배웠습니다.

또 하나의 교훈은 효율성이었습니다. 명확히 정의된 작업에 맞춰 전문화된 모델을 학습시키고 제공하면 더 효율적으로 운영할 수 있어, 제한된 컴퓨팅 자원으로도 더 많은 성과를 낼 수 있었습니다. 하지만 추론 규모를 키우는 일은 여전히 어려웠습니다. 한쪽에는 API 사용량 제한이 있었고, 다른 한쪽에는 대규모 자체 호스팅 비용이 따랐습니다. 최첨단 컴퓨팅 역량을 이용할 수 없었기에, 가용 자원을 최대한 활용하는 방법을 신중하게 고민해야 했습니다. Fortytwo는 이러한 교훈을 스웜 추론이라는 비전에 결합했습니다. 여러 모델 또는 동일한 모델의 여러 인스턴스가 추론에 참여하면서 서로의 결과도 평가하는 방식입니다. 그 결과 집단은 구성원 어느 하나보다 정확한 답을 내놓습니다.

Fortytwo Engine은 여러 오픈 웨이트 모델을 사용해 하나의 추론 과정을 조정하고, 응답을 생성하는 동안 서로의 결과를 검증합니다. 이 접근 방식은 기존의 다중 에이전트 시스템이나 모델 앙상블, 또는 단순히 여러 모델을 실행한 뒤 가장 나은 답변을 선택하는 방식과 어떻게 다른가요?

핵심적인 차이는 스웜 추론이 우리가 개발한 추론 엔진에 직접 통합되어 있다는 점입니다. 우리는 이를 Swarm Decoder라고 부릅니다. 여러 모델 참여자가 추론을 생성하는 동안 하나의 추론 경로를 계속해서 함께 형성합니다. 평가와 조정은 이 과정 안에서 이뤄지므로, 응답이 완성되기 전에 모델들이 추론의 방향에 영향을 줄 수 있습니다.

다른 방식은 이와 다르게 작동합니다. 답변 수준의 앙상블에서는 모델들이 각각 별도의 응답을 생성한 다음, 이를 순위화하거나 선택하거나 결합합니다. 2025년에 구현된 Fortytwo의 초기 아키텍처는 완성된 답변을 동료 모델끼리 순위화하는 방식을 사용했습니다. 이로써 답변 정확도는 크게 향상됐지만 지연 시간과 컴퓨팅 오버헤드가 늘어났습니다. 기존의 다중 에이전트 시스템 중 상당수는 오케스트레이터와 자연어 메시지를 사용해 에이전트별 작업과 기여를 조율합니다. 이처럼 작업을 넘겨주는 과정에는 추가 추론 호출과 컨텍스트 반복이 필요할 수 있으며, 한 에이전트에서 다른 에이전트로 어떤 정보를 전달할지 결정해야 합니다. Swarm Decoder에는 작업을 넘기는 과정이 없습니다. 참여자들은 하나의 추론 경로에서 작업하며, 더 나은 방향이 무엇인지에 대한 판단만 서로 주고받습니다.

Swarm Decoder는 추론 과정에서 약한 가정을 포착해, 그 가정을 바탕으로 상당한 노력을 들여 결과를 쌓아 올리기 전에 바로잡도록 설계됐습니다. 목표는 오류와 되돌아가는 작업, 불필요한 생성을 줄이는 것입니다. 검증으로 추가되는 작업보다 검증 덕분에 줄어드는 작업이 더 많을 때 효율성이 향상됩니다. 지연 시간이 늘어나지 않는 이유도 여기에 있습니다. 더 직접적인 경로로 실행되므로 Engine은 동일한 모델을 단독으로 실행할 때보다 작업을 더 빠르게 완료하고, 참여하는 모든 모델을 포함해 계산해도 전체 토큰을 더 적게 사용합니다.

장시간 이어지는 작업에서 모델 드리프트가 중대한 문제라고 지적하셨습니다. 이런 드리프트는 실제로 무엇 때문에 발생하며, 소프트웨어 엔지니어링이나 연구, 자율 AI 에이전트 같은 실제 응용 분야에서는 어떤 형태로 나타나나요?

드리프트란 모델의 컨텍스트가 점차 작업과 무관해지는 현상입니다. 작업이 오래 이어지면 컨텍스트는 모델 자체의 출력, 도구 결과, 파일 내용, 재시도 기록으로 채워집니다. 모델이 주의를 기울이는 내용에서 최초 지시가 차지하는 비중은 점점 줄어들고, 모델이 앞서 저지른 실수도 추론의 입력에 포함됩니다. 그 결과 오류는 상쇄되지 않고 누적됩니다. 여기에 오늘날의 추론 모델은 작업을 끝내도록 강화 학습을 받기 때문에, 완료한 것처럼 보이는 지름길을 익힙니다. 도구 호출을 건너뛰거나, 성공했다고 단정하거나, 확인하는 대신 요약하는 식입니다. 우리는 이를 게으름이라고 부르며, 최첨단 모델도 개방형 가중치 모델만큼 이런 모습을 보입니다. 근본 원인은 단일 모델에는 외부 검증 장치가 없다는 것입니다. 모델은 자기 작업을 스스로 평가하는데, 모델은 정확한 자기 성찰에 서툽니다.

소프트웨어 엔지니어링에서는 에이전트가 요청받은 버그는 고치면서 첫 메시지에서 명시된 제약 조건을 어기거나, 형식적으로만 통과하는 테스트를 작성하거나, 이미 파악한 내용을 잊어 같은 파일을 네 번 읽는 식으로 드러납니다. 연구에서는 질문자가 던진 질문에서 답하기 가장 쉬운 질문으로 방향이 흐른 뒤, 일반적인 요약만 내놓는 장시간 작업이 이에 해당합니다. 자율 에이전트에서는 비용이 크게 불어나는 형태로 나타납니다. 작업에 필요한 양보다 몇 배나 많은 토큰을 쓰면서 곁길로 새고, 도구를 반복 호출하고, 되돌아가는 것입니다.

이 현상을 수치로 나타낼 수 있습니다. 도구를 사용하고 긴 컨텍스트를 다루는 실제 소프트웨어 엔지니어링 작업인 DeepSWE 과제 450개를 Qwen 3.8 27B로 실행했습니다. 모델을 단독으로 한 번 실행하고 Fortytwo Engine을 통해 한 번 실행했습니다. 단독 실행에서 모델은 실행당 평균 1,630만 토큰을 사용했고, 총사용량은 74억 토큰이었습니다. Engine을 사용했을 때는 같은 모델의 실행당 평균 사용량이 1,230만 토큰, 총사용량이 56억 토큰으로 24.7% 줄었으며, 해결한 과제 비율도 42.2%에서 47.8%로 높아졌습니다. 모델 자체는 달라지지 않았습니다. 실행당 줄어든 400만 토큰은 드리프트로 인한 낭비였습니다. 다시 읽고, 재시도하고, 되돌아가는 데 쓰인 토큰입니다. 단일 모델은 잘못된 방향으로 가는 것을 누군가가 진행 중에 알아차려 주지 않기 때문에 그런 낭비를 감수해야 합니다. 스웜은 잘못된 방향을 잡아내므로 그런 비용을 치를 필요가 없습니다.

이전의 Fortytwo 아키텍처에서는 모델들이 서로의 완성된 답변을 평가했지만, 현재 아키텍처에서는 추론이 생성되는 동안 모델들이 서로에게 영향을 줄 수 있습니다. 이전 접근 방식에서 무엇을 배웠으며, 실시간으로 방향을 조정하는 방식이 더 효과적인 이유는 무엇인가요?

2025년 아키텍처를 통해 우리는 가장 큰 모델 하나를 좇는 대신 참여 모델 수를 늘리는 수평적 확장으로 최첨단 수준의 역량에 도달할 수 있음을 입증했습니다. 서로의 완성된 답변을 평가하는 개방형 가중치 모델의 스웜은 스웜 내 최고 단일 모델보다 최대 17퍼센트포인트 앞섰습니다. 또한 단일 모델과 달리 잡음이 섞인 프롬프트, 삽입된 지시, 오답이 다수인 상황에서도 견고하게 작동했습니다.

그 아키텍처로는 개입할 수 없었습니다. 완성된 답변의 순위를 매기는 방식은 단일 질문에는 효과적이지만, 에이전트 실행은 중간중간 도구를 호출하며 수백 단계에 걸쳐 진행되고 결정적인 실수는 초기에 발생해 누적됩니다. 마지막에 평가하면 모든 모델이 이미 토큰 비용을 전부 치른 뒤이며, 평가자는 이미 서로 다른 방향으로 갈라진 실행 경로 가운데 하나를 고를 수밖에 없습니다. 또한 스웜 비용은 모델 수에 비례해 증가했습니다. 어려운 질문 하나를 다룰 때는 괜찮지만, 코딩 에이전트에는 적합하지 않은 방식입니다.

실시간 방향 조정은 두 문제를 모두 해결합니다. 지속적인 순위 평가는 실행 전반에 선택 압력을 가하므로, 잘못된 방향으로 가는 순간 바로잡아 그 영향이 퍼지기 전에 막습니다. 스웜은 게으른 시도로 만족하지 않습니다. 더 성실한 시도에 순위가 밀리기 때문입니다. 같은 메커니즘으로 정확도를 높이는 동시에 토큰 사용량도 줄일 수 있는 이유가 바로 여기에 있습니다.

Qwen 3.8 27B를 사용한 테스트에서 Fortytwo는 DeepSWE 실행 450회에 걸쳐 토큰 사용량을 24.7% 줄이면서 6개 벤치마크 모두에서 결과를 개선했다고 밝혔습니다. 스웜 내부에서는 성능을 높이는 동시에 토큰 소비를 줄이기 위해 어떤 일이 일어나나요?

스웜의 검증에는 소규모의 고정 비용이 들지만, 검증을 통해 막을 수 있는 복구 비용은 작업이 길어질수록 커집니다. 바로잡지 않은 잘못된 방향 하나가 그 위에 쌓인 모든 작업을 낭비하게 하기 때문입니다. 따라서 작업이 길수록 절감할 수 있는 비용도 커집니다. DeepSWE는 작업 길이의 긴 쪽에 속하기 때문에 전체 토큰의 거의 4분의 1을 절감하게 됩니다.

정확도 향상은 들쭉날쭉한 지능과 관련이 있습니다. 모델의 성능 향상은 대개 영역에 따라 고르지 않습니다. 한 분야에서는 박사급 추론을 보여주다가도 다른 분야에서는 완전히 터무니없는 답을 내놓을 수 있습니다. 미세 조정과 강화 학습(RL)을 비롯한 사후 학습은 모델이 학습한 데이터에서 성능을 높이며, 실제 작업이 그 데이터에서 멀어질수록 성능 향상 폭은 줄어들기 때문입니다. The Swarm Decoder는 모델 자체를 바꾸지 않습니다. 추론 자체를 일관되게 개선하므로, 6개 벤치마크는 우리가 최적화한 6개 분야가 아니라 동일한 효과를 측정한 6개 항목입니다. 전반적으로 모델은 더 똑똑하고 주의 깊게 작동하며, 동료 모델들이 모든 단계를 확인해 주기 때문에 사용자의 작업에 훨씬 더 많은 노력을 기울이는 것처럼 느껴집니다. Engine의 가격을 기본 모델의 토큰당 요금에 맞출 수 있는 이유도 여기에 있습니다. 고객은 더 큰 예산을 지불하는 것이 아니라 정답에 이르는 더 짧은 경로에 비용을 지불하는 것입니다.

추론 모델이 더 긴 토큰 시퀀스를 생성하면서 AI 개발자들은 추론 비용을 점점 더 우려하고 있습니다. 추론 과정 자체의 효율성을 높이는 일이 궁극적으로 개별 모델을 더 작고 빠르고 저렴하게 만드는 것만큼 중요해질 수 있다고 보시나요?

네, 그리고 이미 더 큰 효과를 내는 수단이라고 생각합니다. 모델을 더 작고 빠르고 저렴하게 만들면 토큰 가격이 낮아집니다. 하지만 토큰을 사는 사람은 없습니다. 사람들은 완성된 작업 결과를 사죠. 에이전트 시대에는 작업 하나를 수행하는 데 드는 토큰 수가 폭발적으로 늘었습니다. 실제 코딩 작업에서 추론 모델은 수백만 개의 토큰을 사용하는데, 그중 상당수는 이미 한 일을 되짚는 데 쓰입니다. 작업당 토큰 수를 25% 줄이는 것은 토큰 가격을 25% 인하하는 것과 정확히 같은 가치가 있습니다. 여기에 하드웨어, 양자화, 커널의 모든 개선 효과가 더해지며, 시중에 있는 모든 오픈 웨이트 모델에 이를 적용할 수 있습니다.

업계에는 세 가지 수단이 있습니다. 첫째는 더 나은 모델입니다. 이를 위해서는 학습이 필요하고 비용도 많이 듭니다. 둘째는 더 저렴한 토큰입니다. 하드웨어와 서빙의 문제인데, 모두가 같은 GPU를 사용하기 때문에 차이가 줄어들고 있습니다. 셋째는 작업당 토큰 수를 줄이는 것입니다. 추론을 실행하는 방식에 달려 있지만, 아직 거의 탐구되지 않은 영역입니다. 지금까지 규모를 키운다는 것은 더 큰 모델과 더 긴 사고 과정을 뜻했고, 두 방식 모두 하나의 모델이 한 번의 과정에서 모든 일을 하도록 요구합니다. 우리는 다음 단계가 집단적 접근이라고 생각합니다. 여러 모델이 함께 추론하고 판단을 서로 나누면 과정 자체가 더 짧고 신뢰할 수 있게 됩니다. 이는 매개변수 수나 테스트 시점 연산량을 늘리는 것과는 다른 종류의 규모 확장이며, 우리가 투자하려는 방향입니다. 우리는 이를 ‘매개변수보다 동료 모델’이라고 표현합니다.

Fortytwo Engine은 오픈 웨이트 모델을 실행하면서 OpenAI API와 호환됩니다. 기존 AI 개발 스택과의 호환성은 얼마나 중요했으며, 개발자가 기존의 단일 모델 API 기반 애플리케이션을 스웜 아키텍처로 얼마나 쉽게 전환할 수 있나요?

호환성은 필수입니다. 에이전트 생태계를 이루는 코딩 에이전트, 하네스, 프레임워크, 평가 도구는 OpenAI API 형식을 기반으로 구축되어 있습니다. 따라서 Fortytwo Engine을 사용하는 개발자에게 전환은 한 추론 제공업체에서 다른 곳으로 옮기는 것과 같습니다. 호환되는 앱, 에이전트, 하네스 또는 서비스라면 대개 엔드포인트, API 키, 모델 선택 등 설정 하나만 바꾸면 됩니다.

달라지는 것은 통합 방식이 아니라 작동 방식입니다. 토큰 소비량과 첫 시도에서의 정확도가 비용을 좌우하는 장시간 에이전트 실행에서 차이가 드러납니다. 같은 모델이라도 Engine을 통하면 더 빠르게 완료하고 토큰을 덜 사용하며 더 많은 작업을 정확히 수행합니다. 제 조언은 어떤 모델로 전환할 때와 마찬가지로 접근하는 것입니다. 에이전트에 이미 사용 중인 평가를 실행하고 작업당 토큰 수와 성공률을 비교한 뒤, 더 나은 결과를 내는 쪽을 선택하세요.

좋은 인터뷰에 감사드립니다. 스웜 추론과 동료 평가를 통해 추론 효율성을 높이는 방법을 알아보고 싶은 독자 여러분은 Fortytwo를 방문해 보시기 바랍니다.