단순히 더 좋은 모델이 나왔다는 느낌이 아니었어요. 저희가 사업을 하면서 전제했던 것들을 처음부터 다시 생각해야 할 수도 있겠다는 생각이 들었습니다. 주말 동안 계속 그 생각을 하느라 잠을 제대로 못 잤어요.

사실상 무제한의 R&D가 가능한 회사와 어떻게 경쟁할 것인가였어요. 모델이 연구와 개발의 많은 부분을 할 수 있게 되면, 돈을 더 내는 회사가 더 많은 실험을 하고 더 빠르게 결과를 얻을 수 있잖아요. 그런 상대와 우리는 무엇으로 경쟁할 것인가를 이야기했습니다.

맞아요. AI가 너무 잘하게 되면 지금 우리가 어렵게 만드는 소프트웨어를 다른 사람도 쉽게 만들 수 있잖아요. 그게 걱정인 겁니다. 제품이 나빠서가 아니라, 그 제품을 만드는 진입 장벽이 낮아져서 사업이 어려워질 수 있다는 거예요.

크게 세 층으로 볼 수 있습니다. 맨 아래에는 컴퓨팅 자원과 기본 연산을 최적화하는 영역이 있어요. 그 위에는 모델을 실행해서 토큰을 만들어내는 토큰 팩토리가 있고, 맨 위에는 그 토큰을 사용해 일을 하는 에이전틱 AI 플랫폼이 있습니다.

둘 다 중요해요. 모델을 돌리려면 GPU와 메모리, 서버, 장비들을 연결하는 네트워크가 필요하죠. 그런데 장비를 갖추는 것만으로는 부족합니다. 여러 작업이 그 자원을 효율적으로 나눠 쓰게 해야 해요.

토큰은 모델이 처리하는 텍스트 등의 조각입니다. 항상 한 단어와 일치하는 건 아니에요. 단어 하나가 여러 토큰으로 나뉠 수도 있습니다.

바로 그 구분을 다시 해야 한다고 느꼈습니다. 지금은 플랫폼이 자료를 찾고 파일을 읽는 도구를 연결하고, 모델의 판단을 실제 실행으로 옮긴 뒤 결과를 다시 전달합니다. 보고서를 만드는 일만 해도 자료 수집부터 작성과 확인까지 이어져야 하니까요.

저희는 인프라와 플랫폼을 함께 다루니까, 아래의 계산 방식이 바뀌면 위의 제품까지 다시 봐야 해요. 다른 회사들도 한 층에만 속하는 건 아니고요. 여러 층을 함께 만드는 곳들이 있습니다.

여러 기능이 겹쳐 있는 뇌의 회로를 나누어 이해하는 연구를 했어요. 반대로 하나의 네트워크에 여러 역할을 겹쳐 넣고 반복해서 쓰게 만드는 문제를 보니, 예전에 어렵다고 여겼던 일이 떠오른 겁니다. 앞부분이 특징을 추출하고 뒤쪽이 맥락을 정리한다는 설명도 역할을 이해하기 위한 단순화예요. 실제 레이어의 기능이 칼로 자르듯 나뉘는 것은 아닙니다.

저희가 보고 있는 가설은 일부 레이어를 반복해서 사용하는 구조예요. 모델을 계속 크게 만드는 대신, 중간의 같은 계산 블록을 여러 번 통과하면서 더 계산하는 방식입니다.

모델 안에는 입력을 숫자로 표현한 뒤 그 숫자를 여러 단계에 걸쳐 바꾸는 과정이 있습니다. 그 계산 단계를 레이어라고 생각하면 됩니다. 고정된 깊이의 모델은 한 번의 순전파, 즉 입력에서 출력을 향해 계산하는 과정에서 정해진 단계들을 통과합니다.

서로 다른 가중치를 계속 추가하지 않고도 계산 단계를 늘릴 여지가 있다는 뜻입니다. 가중치는 모델이 학습으로 얻은 수치들이고요. 하지만 계산이 공짜가 되지는 않아요. 같은 블록을 다시 실행하니 시간과 전력은 듭니다.

아이디어 자체가 없었던 건 아닙니다. 같은 네트워크가 반복 과정에서 여러 역할을 해야 하니까, 안정적으로 학습시키는 일이 어려운 거죠. 제 전공에서는 여러 기능이 겹친 신경 회로를 분석했는데, 여기서는 그런 기능들을 한 구조 안에서 함께 작동하게 만드는 문제를 보게 되는 겁니다.

그 문제도 포함됩니다. 반복할수록 필요한 정보가 사라지거나 결과가 나빠지면 소용이 없잖아요. 훈련을 통해 유용한 계산이 이어지도록 만들어야 합니다. 학습이 수렴한다는 말은 오차와 동작이 안정되는 방향으로 훈련이 진행된다는 뜻이고요.

네. 그 가정이 맞다면 기존에 안 된다고 생각했던 이유부터 다시 봐야 하는 겁니다. 다만 저희도 구체적으로 어떻게 훈련했는지가 궁금한 상태예요.

중간 추론을 토큰으로 표현하고 그걸 다음 계산에 사용하는 방식과, 내부에서 반복 계산을 하는 방식의 차이를 보고 있는 거예요. 내부에서 더 많은 계산을 처리한다면 밖으로 생성해야 하는 토큰이 줄 수 있다는 겁니다.

맞습니다. 중간 추론을 토큰으로 만드는 것과 그 토큰을 사용자에게 보여주는 것은 별개예요. 화면에 보이지 않는 추론 토큰도 있을 수 있죠.

함께 쓸 수 있어요. 에이전트 루프는 모델 호출, 도구 실행, 결과 확인을 바깥에서 반복하는 구조예요. 내부 반복은 모델 한 번의 실행 안에서 특정 계산 블록을 다시 사용하는 것이고요. 반복하는 위치와 역할이 다르니 하나가 있다고 다른 하나가 반드시 없어지지는 않습니다.

그렇게 보장되지는 않습니다. 추가 계산이 도움이 되는 범위가 있고, 너무 반복해서 성능이 떨어질 수도 있어요. 언제 멈출지 정하는 문제도 남습니다. 반복 가능한 구조라는 것과 스스로 정답을 알아보고 멈춘다는 것은 다른 능력입니다.

저도 그 부분을 상상했어요. 계산 도중 진행 상태를 묻거나 조건을 추가할 수 있다면, 지금처럼 밖에서 모델을 여러 번 호출할 필요가 줄 수도 있겠죠. 물론 루프가 있다고 그런 인터페이스가 저절로 생기지는 않습니다. Astra에서 실제로 가능한지, 반복 횟수에 제한이 없는지는 저도 아직 몰라요.

o1이 나오고 나서 DeepSeek의 공개 연구가 등장했던 흐름이 떠올라요. DeepSeek나 Kimi 같은 팀이 비슷한 접근을 공개하면 충격이 더 넓게 번질 수 있겠죠. 저는 반년 정도면 나올 수도 있다고 봐요. 정해진 일정을 아는 건 아니고요. 대규모 계산과 고품질 데이터 덕분에 학습이 가능하지 않았을까 싶은데, 그것도 제 추측입니다. 실제로 어떻게 훈련했는지는 공개돼야 알겠죠.

지금은 많은 사업이 토큰을 얼마나 처리하느냐를 기준으로 돌아가잖아요. 그런데 비슷한 길이의 답을 만드는 데 실제로는 훨씬 다른 양의 계산이 들어갈 수 있다면, 토큰량과 비용의 관계를 다시 봐야 하는 겁니다.

그렇죠. 답은 짧아도 계산은 오래 할 수 있습니다. 생성한 텍스트의 길이만으로 내부 작업량을 알기 어려워지는 거예요. 추론 토큰이나 계산 시간을 따로 측정해서 요금을 받을 수도 있겠죠. 그래서 토큰 기반 요금이 반드시 사라진다고 보지는 않아요.

그게 또 중요한 문제입니다. 내부에서 몇 번 반복할지가 요청마다 달라진다면, 답이 나오기까지의 시간도 달라질 수 있어요. 기존의 서빙 시스템이 그 작업들을 어떻게 배치할지 다시 생각해야 합니다.

우선 요청을 어느 장비에 보낼지, 어떤 요청들을 묶어서 처리할지 조정해야 해요. 메모리 배분과 실패한 요청 처리도 필요하고요. 학습된 모델이 실제 사용자에게 응답하도록 운영하는 이 모든 일을 서빙이라고 합니다.

네. 요청 하나가 들어와 답이 끝날 때까지 따라가보죠. KV 캐시를 쓰는 일반적인 자기회귀 트랜스포머를 기준으로 보면 돼요. Astra의 비공개 구조는 저도 모르지만, 기존 모델이 텍스트를 만드는 과정은 설명할 수 있습니다.

앞서 처리한 입력의 Key와 Value는 재사용합니다. 방금 선택한 토큰을 모델에 넣고, 이전에 저장한 정보를 참고해서 다음 토큰의 확률을 계산해요. 새 토큰의 Key와 Value도 캐시에 추가합니다. 이렇게 선택한 토큰이 다시 다음 계산의 입력이 됩니다.

첫 토큰까지 걸리는 시간을 TTFT, Time to First Token이라고 부릅니다. 측정 구간에 따라 요청 전송과 대기, 입력 준비, 프리필, 첫 토큰 선택까지의 시간이 포함될 수 있어요. 따라서 TTFT가 길다고 곧바로 프리필이 느리다고 단정하면 안 됩니다. 추론 토큰을 먼저 생성하는 모델에서는 첫 내부 토큰과 사용자가 보는 첫 답변 사이에도 차이가 생길 수 있고요.

서버가 같은 입력 앞부분의 KV 캐시를 재사용할 수 있도록 구현돼 있다면 이미 처리한 구간의 계산을 줄일 수 있습니다. 이를 프리픽스 캐싱이라고 부르죠. 새로 추가된 입력은 처리해야 하고, 캐시가 남아 있는지, 모델과 입력이 일치하는지 같은 조건도 맞아야 합니다. 대화 화면에 이전 내용이 보인다고 서버가 반드시 그 캐시를 유지하는 것은 아닙니다.

병목은 전체 속도를 가장 강하게 제한하는 부분이에요. 주방으로 비유하면, 재료는 충분한데 요리가 오래 걸릴 수도 있고, 요리사는 빠른데 재료가 늦게 도착할 수도 있죠.

네. 어떤 계산을 반복하고 어떤 데이터를 다시 읽는지가 달라지니까요. 기존에 무엇을 빠르게 만드는 데 최적화했는지부터 다시 봐야 합니다.

HBM은 고대역폭 메모리입니다. 연산 장치에 많은 데이터를 빠르게 공급하는 데 쓰여요. 여기서 용량과 대역폭을 구분해야 합니다. 용량은 얼마나 담는지, 대역폭은 일정 시간에 얼마나 옮기는지예요.

가중치를 재사용할 가능성은 있지만, 반복한다는 사실만으로 결론을 낼 수는 없습니다. 데이터가 어느 메모리에 머무르는지, 다시 얼마나 읽어야 하는지, 중간 상태를 얼마나 저장하는지에 달려 있어요. 가중치를 적게 보관하는 것과 데이터를 적게 옮기는 것도 다른 문제입니다.

기존에는 어텐션 계산에서 이전 토큰에 대해 만든 Key와 Value를 저장해뒀다가 다음 토큰을 만들 때 재사용하죠. 반복 구조에서는 한 블록을 여러 번 지나가니, 어느 반복에서 만든 정보를 다시 쓸지까지 생각해야 해요.

저장해뒀다가 재사용하는 건 Key와 Value예요. 어텐션은 현재 위치에서 이전 정보 중 무엇을 얼마나 참고할지 계산하는 방식인데요. Query는 지금 찾는 정보의 기준, Key는 그 기준과 비교할 표현, Value는 비교 결과에 따라 가져와 조합할 내용입니다. 모두 모델 내부의 숫자 표현이고요.

네. KV 캐시는 모델 계산을 줄이기 위한 것이고, 에이전트의 장기 메모리는 업무 기록이나 사용자 정보를 나중에 다시 쓰기 위한 장치입니다. 완성된 답을 저장했다가 그대로 보여주는 응답 캐시와도 달라요.

각 반복의 상태를 따로 보관할지, 일부를 공유할지에 따라 필요한 메모리와 계산량이 달라질 수 있어요. 무엇을 남겨두고 다시 쓸지가 설계의 문제가 되는 거죠.

기존의 연산 흐름에 강하게 최적화한 칩이라면, 그 흐름이 달라졌을 때 불리할 수 있다는 생각입니다. GPU는 프로그래밍 유연성이 있으니 대응할 여지가 크고요. 특정 방식에 맞춰 효율을 높였던 설계를 다시 봐야 할 수 있습니다.

GPU는 많은 계산을 병렬로 처리하는 장치이고, 지금은 AI 계산에도 널리 사용합니다. NPU는 신경망 계산에 특화한 가속기를 넓게 부르는 이름입니다. TPU는 Google이 만든 가속기 제품군이고요. NPU라는 이름만으로 모든 칩의 구조나 기능이 같다고 생각하면 안 됩니다.

실행할 수 있는지와 효율적으로 실행할 수 있는지는 다릅니다. 모델의 연산을 기계 명령으로 바꾸는 컴파일러, 실행을 관리하는 런타임, 메모리와 제어 구조를 함께 봐야 해요.

네. 제 우려는 그 변화의 폭이 작지 않을 수 있다는 겁니다.

국내의 리벨리온과 퓨리오사AI, 해외의 Cerebras와 SambaNova, Google TPU 등이 떠올랐어요. 걱정은 크지만, 설계가 다 다른데 전부 루프를 실행하지 못한다고 말할 수는 없죠. 제품별 제어 흐름이나 컴파일러, 메모리 구조를 제가 다 아는 것도 아니고요. 제가 걱정하는 건 특정 연산 패턴에 맞춰 얻었던 효율이 새 구조에서도 유지되겠느냐는 겁니다.

네. 어떤 추론 단계에 맞춰 칩을 만들고, 메모리와 장비 간 연결을 어떻게 구성하는지를 보면 앞으로 어떤 계산이 중요해질지 생각해볼 수 있습니다. 저는 제품 방향에 관한 이야기들을 보면서 모델 쪽 변화를 미리 고려한 것인지 궁금했던 겁니다.

네. GPU가 자기 메모리에서 데이터를 가져오는 속도와 여러 GPU가 서로 데이터를 주고받는 속도는 따로 봐야 해요. NVLink와 NVSwitch는 GPU 사이의 데이터 교환을 돕는 기술입니다. 한 장에 모델을 다 담을 수 없거나 여러 장이 협력할 때 그 연결이 중요해지죠.

중단됐던 계획이 HBM을 쓰는 형태로 다시 추진된다는 이야기를 들었어요. 그래서 NVIDIA가 이런 계산 방식의 변화를 미리 알고 있었던 것 아닐까 생각한 거죠. 하지만 실제로 계획을 바꿨는지, 미리 알고 있었는지는 저도 모릅니다. 처음 공개한 Rubin CPX는 128GB GDDR7 사양이에요. HBM 이야기는 제가 들은 전언이고, 모델 변화와 연결한 건 제 추측입니다.

그렇죠. 여러 모델에 일을 나눠주고, 그걸 묶어 자동화하는 구조를 만들었어요. 그런데 훨씬 강한 단일 모델이 복잡한 일을 더 잘 처리하면, 우리가 어렵게 만든 분업 구조가 얼마나 의미 있게 남을지 다시 봐야 합니다.

예를 들면 한 에이전트는 코드를 쓰고, 다른 에이전트는 테스트하고, 또 다른 에이전트는 결과를 검토하게 하는 겁니다. 작업을 나눠 동시에 처리할 수도 있어요. 다만 서로 결과를 전달하고 조정하는 비용과 오류도 생깁니다.

병렬 처리나 권한 분리, 독립적인 검증을 위한 분업은 여전히 유용할 수 있어요. 반면 모델의 부족한 능력을 메우려고 복잡하게 나눠놓은 일은 다시 합칠 수 있겠죠. 여러 에이전트가 필요 없어지는 게 아니라, 왜 나눴는지를 다시 보는 겁니다.

네. 그래서 기술뿐 아니라 제품의 차별점도 다시 생각해야 한다는 겁니다.

내부에서는 Kimi와 Qwen 계열 모델 여러 인스턴스를 묶어서 작업을 분산하는 팜을 운영해왔어요. 그걸 스쿼드라는 작업 흐름으로 조직했고요. 여러 모델이 협업하는 방식을 제품으로 만든 건데, 단일 모델이 그 결과를 넘어선다면 조정에 들이던 비용이 아까워질 수 있잖아요. 우리 제품의 차별점도 다시 계산해야 합니다. 최적화도 반복을 빠르게 하거나 어텐션을 가속하는 쪽으로 중심이 옮겨갈 가능성을 보고 있어요.

우리만 잘 쓰는 동안에는 좋겠죠. 그런데 다른 회사도 같은 도구로 비슷한 것을 만들 수 있으면, 생산성이 좋아지는 것과 사업의 경쟁력이 높아지는 것은 별개입니다. 지금 저희가 하는 최적화도 가설을 세우고 실험하고 측정하는 반복이에요. 그 과정이 크게 빨라지면 필요한 자원 자체가 달라질 수 있습니다.

그렇습니다. 기술적인 진입 장벽이 낮아지면 새로운 경쟁자가 들어오기 쉬워지니까요. 그렇다고 보안, 고객의 업무 이해, 실제 운영과 장애 대응까지 모두 사라지는 건 아닙니다. 어떤 부분을 고객이 계속 돈을 내고 살지 구분해야 합니다.

그게 주말 내내 고민했던 부분입니다. 예전부터 언젠가는 올 변화라고 생각했지만, 실제로 가까워졌다고 느끼면 경영의 문제가 되죠.

하드웨어의 이론적 성능 한계에 얼마나 가까이 가느냐가 중요합니다. Roofline 모델로 보면 계산 성능과 메모리 대역폭 중 무엇이 한계를 정하는지 살필 수 있어요. 연산량에 비해 데이터를 얼마나 옮겨야 하는지를 보고 병목을 찾는 방법입니다. 저희도 실험을 분산하고 결과를 비교하면서 그 한계에 접근해왔습니다.

모델의 지능과 실제 서비스에 연결되는 경험 사이에 간격이 있다는 말씀이군요.

사람들이 익숙한 경험 안에서 그걸 제공하는 것도 중요하겠네요.

저도 예전에는 AI를 전기에 비유했어요. 그런데 지금은 자동차가 더 맞을 수 있겠다는 생각도 합니다. 같은 이동 기능을 제공해도 차마다 가격과 경험이 크게 다르잖아요.

네. 얼마만큼의 계산을 쓸 수 있는지, 얼마나 빠르게 결과를 얻는지에 따라 격차가 남을 수 있다는 거예요. 더 많은 돈을 내면 더 많은 연구와 개발을 하고, 빠른 응답에도 돈을 낼 수 있습니다.

그렇죠. 모델을 사용할 수 있다는 것과 충분한 규모로 사용할 수 있다는 것은 다릅니다. 그래서 ‘무제한의 R&D를 하는 회사와 어떻게 경쟁할 것인가’라는 질문이 나오는 겁니다.

문제를 잘 골라야 하고, 데이터가 있어야 하고, 결과를 평가할 기준도 필요하죠. 실제 현장에 적용하는 능력도 중요합니다. ‘무제한’은 그런 한계가 없다는 뜻이 아니라 경쟁 상대가 투입할 수 있는 실험 규모가 압도적으로 커질 수 있다는 표현입니다.

맞아요. 소프트웨어는 빠르게 바뀌지만 콘크리트는 느립니다. 공장과 데이터센터를 짓고 전력을 연결하는 일은 같은 속도로 바뀌지 않아요. 그 속도의 차이가 계속 발목을 잡습니다.

그렇습니다. 좋은 설계 파일은 금방 전달할 수 있지만 공장은 전달할 수 없잖아요. 제조와 검증, 장비 설치, 전력 공급에는 별도의 시간이 듭니다. 디지털 영역이 빨라진다고 물리적 공급이 즉시 따라오는 것은 아닙니다.

초파리의 뇌 연결망을 다룬 실험도 떠올라요. 그런 사례까지 보니까 변화의 속도를 다시 생각하게 됩니다.

여기서 뇌 연결 지도, 즉 커넥톰은 어떤 신경세포가 다른 신경세포와 연결돼 있는지를 나타내는 자료입니다. 그 연결을 연구하는 분야가 커넥토믹스고요. 연결망을 계산 모델로 만들고, 가상 몸에서 들어오는 감각을 입력한 뒤 신경 활동을 움직임으로 연결하면 반응을 관찰할 수 있습니다.

그런 가능성을 보면서 반도체 설계까지 생각이 이어진 겁니다. 물론 초파리 연결망 실험 하나가 칩 설계 자동화의 완성을 증명하지는 않아요. 반도체는 전력과 성능, 면적의 제약을 함께 맞추고 설계 검증을 거쳐야 합니다. 그래도 가설을 만들고 계산으로 시험하고 수정하는 과정이 얼마나 빨라질 수 있는지는 다시 물어야 한다고 봤어요.

너무 길게 보시는 것 같아요. 저는 6개월이면 끝날 거라고 봅니다.

네. 지금 말씀드린 시간은 설계 자동화에 대한 제 전망이지, 칩을 생산하고 공급하는 전 과정이 그 안에 끝난다는 뜻은 아닙니다. 설계가 빨라져도 공장과 데이터센터, 전력망은 같은 속도로 지을 수 없어요. 소프트웨어와 콘크리트가 움직이는 속도 차이가 생기는 겁니다.

저희는 계속 AI 플랫폼을 만드는 일을 해왔어요. 사업을 완전히 바꿨다기보다, 그 안에서 어디에 집중할지 결정한 순간들이 있었습니다. 처음에는 Sorna였고 이후 Backend.AI가 됐죠.

여러 작업이 자원을 나눠 쓰면서도 병목이 생기지 않게 운영하는 게 중요해요. 작업이 늘면 자원도 확장해야 하지만, 장비를 더 붙인다고 저절로 효율이 나오는 건 아니거든요.

Stable Diffusion이 나왔을 때도 변화가 컸어요. 이전에는 모델을 훈련하는 고객들이 중심이었다면, 실제로 모델을 실행해서 결과를 만드는 추론 시장이 중요해졌죠. 모델을 만드는 쪽에서 사용하는 쪽으로 중심축이 이동하는 상황을 본 겁니다.

훈련은 데이터로 모델의 가중치를 조정하는 과정이고, 추론은 그렇게 학습한 모델을 실제 질문이나 작업에 사용하는 과정입니다. 모델 연구팀을 지원하는 것과 많은 사용자의 요청을 안정적으로 처리하는 것은 고객 요구와 운영 방식이 달라요.

자본을 댈 테니 그쪽으로 가보자는 제안이 있었는데 최종적으로 받지 않았습니다. 매출은 커질 수 있지만, 제 관점에서는 자산 임대업에 가까워지는 것 같았고 수익성에도 의문이 있었어요.

네오클라우드는 AI 연산 자원 제공에 특화한 클라우드 사업이잖아요. 고객의 장비를 효율적으로 쓰게 하는 소프트웨어를 만드는 것과, 저희가 직접 장비를 확보해 공급하는 건 필요한 자본과 감당할 위험이 달라요. 비싼 장비를 사놓고 얼마나 계속 가동할 수 있느냐가 중요해지는 거죠.

49명 규모예요. 해외에서 일하는 두 분도 있고, 사업과 프런트엔드 쪽 역할을 맡고 있어요. 인력이 한정돼 있으니 어디에 집중할지 정해야 하잖아요. 기술이 바뀌면 조직도 바로 그 문제를 고민하게 됩니다. 오늘 아침에도 그 위기감을 공유하고 왔습니다.

개별 에이전트가 데스크톱의 파일이나 화면을 다루고, 여러 에이전트를 팀처럼 묶어 업무를 줄 수 있습니다. 권한을 정하고, 언제 무엇을 자동으로 실행할지 설정하고, 스쿼드로 작업 흐름을 구성하는 식이에요.

네. 여러 에이전트의 작업을 파이프라인으로 묶는 거예요. 예를 들어 자료 조사, 초안 작성, 검토를 연결한다면 각 단계가 무엇을 받고 다음 단계에 무엇을 넘길지 정하는 거죠.

스킬을 가져오거나 커뮤니티가 만든 자원을 다운로드하는 기능을 보여드릴 수 있어요. OpenClaw나 Hermes 통합도 있습니다. 지금 시연하는 버전에 보이는 것 외에 별도로 통합해둔 부분도 있고요.

스킬은 특정 작업의 절차와 참고자료 등을 재사용하도록 묶는 방식이에요. 사람이 업무 매뉴얼을 참고하듯 에이전트가 작업 방법을 활용하게 하는 겁니다.

실제로 점점 비슷해지고 있어요. 사람들의 요구가 비슷하니까요. 일을 맡기려면 지시서와 참고자료가 필요하고, 누가 언제 무엇을 했는지 추적해야 하잖아요. 저희는 모델 런타임에서 시작했지만 다른 출발점의 도구와도 비슷한 곳으로 가고 있습니다.

네. 사용자가 매번 이전 일을 설명하면 일을 맡기는 의미가 줄어들잖아요. 작업 이력을 보관하고 필요한 정보를 다시 꺼낼 수 있어야 합니다. 조사에 쓴 원자료를 보관하고, 사람이 위키로 읽거나 에이전트가 도구를 통해 찾아 쓰게 할 수도 있고요.

모델이 파일을 읽거나 검색을 실행하라고 요청하면 플랫폼이 해당 기능을 실행하고 결과를 돌려주는 겁니다. 답변 문장만 만드는 것에서 실제 일을 처리하는 것으로 넘어가려면 그런 연결이 필요해요.

그래서 우리가 이걸 굳이 만들어야 하나 하는 생각도 했죠. 다만 아래 인프라부터 최종 사용자 경험까지 연결하려면 위의 플랫폼도 필요하다고 보고 계속 만들고 있습니다.

네. 고객이 필요한 건 특정 단계의 최적화만이 아니라 최종적으로 일이 끝나는 경험이니까요. 아래의 자원 관리와 모델 서빙, 토큰 생산, 위의 에이전트 플랫폼을 연결해서 보게 됩니다.

그렇습니다. 인프라 회사가 완성된 업무 제품을 만들고, 앱 회사가 모델 운영과 비용을 직접 최적화하면 경계가 겹칠 수 있어요. 서로 다른 층에 있었던 회사들이 같은 사용자에게 무엇을 제공할지 경쟁하게 됩니다.

지금은 브랜드가 남는 게 아닌가 생각하고 있습니다. 자동차의 기반 기술이 비슷해도 사람들이 선택하는 브랜드와 기대하는 경험은 다르잖아요. 비슷한 지능을 이용해 비슷한 기능을 만들어도 마지막 선택이 완전히 같지는 않을 수 있다는 거죠.

그런 문제와 연결된다고 봐요. 사용자가 어느 정도 품질을 기대해도 되는지, 어디까지 일을 맡겨도 되는지, 문제가 생기면 누가 책임지는지가 중요하겠죠. 말로 약속한다고 경쟁력이 생기지는 않을 테고, 실제로 써본 경험이 쌓여야 할 겁니다.

기존 메신저 회사들도 그런 방향을 생각하고 있을 겁니다. 그런데 이미 가진 브랜드와 사용자의 기대가 있으니 바꾸기 쉽지만은 않겠죠.

익숙함이 사용자를 데려오는 자산이면서 변화의 제약이 될 수 있다는 거네요. 메시지를 주고받으러 들어온 사람에게 갑자기 다른 역할을 요구하면 부담스러울 수 있으니까요.

카카오 관계자에게 내년 상반기를 목표로 에이전트 중심 개편을 준비한다는 이야기를 들었어요. 공식 일정인지는 모르고요. 첫 화면을 바꾸는 데도 저항이 있잖아요. 카카오톡에 붙은 ChatGPT도 기대보다 덜 쓴다는 이야기를 들었는데, 정확한 이용률은 저도 모릅니다. 카나나를 보면서도 사용자가 기대하는 경험을 바꾸기가 쉽지 않겠다고 느꼈어요.

Facebook과 Instagram을 생각해봐도 한 회사 소유라는 이유로 사용자 경험과 브랜드를 하나로 만들 수는 없잖아요. 각각 기대하는 게 다르니까요. 자동차도 화웨이나 폭스콘 같은 공통 기반을 활용하더라도 사용자가 고르는 브랜드와 경험은 다를 수 있어요. 가령 Apple Car가 나온다고 해보죠. 그걸 사는 사람은 차를 사는 걸까요, Apple을 사는 걸까요?

연구자로서는 재미있고 놀라워요. 그런데 사업을 하는 저도 있으니까요. 그쪽은 비상 모드입니다. 기존에 세웠던 가정이 계속 유효한지 다시 생각하고 있습니다.

네, 그게 걱정이에요. 구현이 쉬워져도 실제 운영과 고객 경험, 자원 접근의 문제는 남겠죠. 그중 무엇을 계속 직접 만들고 무엇을 다른 기술에 맡길지 판단해야 하는 거고요.

기후위기가 언젠가 닥칠 경고가 아니라 이미 대응해야 할 현실로 느껴지는 순간 같아요. 가능성으로만 알던 일이 당장 결정을 내려야 할 문제로 다가오는 거죠. 지금 제가 느끼는 게 그래요.

신기하고 재미있는 것과 회사를 책임지는 것은 다르니까요. 회사는 비상 모드로 고민하고 있습니다. 초등학생과 중학생 아이들이 살아갈 미래까지 생각하면 질문은 더 커져요. 정답을 찾았다는 이야기가 아니라, 기존 전제로는 답하기 어려운 질문들을 본격적으로 마주했다는 뜻입니다.