AI/AX

마이크로소프트 CEO가 말한 '러닝 루프', 작은 회사의 시선에서

마이크로소프트 CEO 나델라가 말한 'AI 러닝 루프'는 옳지만 대기업의 전제 위에 쓰여 있습니다. 같은 개념을 작은 회사의 규모에서 어떻게 번역하고 실제 프로젝트에 적용해왔는지, 우리 스튜디오의 경험을 바탕으로 정리했습니다.

2026년 6월 17일 · 4분 읽기Pivot Studio

지난 주말 사티아 나델라가 X에 올린 긴 글 하나가 화제가 됐습니다. 제목은 "A frontier without an ecosystem is not stable" — 생태계 없는 프런티어는 안정적이지 않다, 정도로 옮길 수 있겠네요.

논지를 거칠게 요약하면 이렇습니다. AI 시대에 기업의 경쟁력은 '어떤 모델을 고르느냐'에서 나오지 않습니다. 모델은 누구나 갈아끼울 수 있는 엔진일 뿐이고, 진짜 자산은 그 위에 회사 고유의 지식과 판단을 쌓아 올린 러닝 루프(learning loop)라는 이야기입니다. 나델라는 이걸 '언덕 오르기 기계'에 비유했습니다. 쓸수록 데이터가 쌓이고, 쌓인 데이터가 다시 시스템을 개선하고, 그 개선이 또 복리로 누적되는 구조죠. 그래서 일찍 이 루프를 만든 회사는 새 모델이 아무리 좋아져도 쉽게 따라잡히지 않는다는 겁니다.

저는 이 글에 거의 전부 동의합니다. 사실 새삼스럽지도 않았습니다. 우리가 몇 년째 해온 일을 3조 달러짜리 회사의 CEO가 대신 정리해준 느낌에 가까웠으니까요.

다만, 그 글은 대기업의 언어로 쓰여 있습니다

동의하면서도 한 가지가 계속 걸렸습니다. 나델라가 그리는 그림에는 사내 eval 팀이 있고, 자체 강화학습 환경이 돌아가고, 조직의 지식베이스를 관리하는 인력이 있습니다. 그건 마이크로소프트의 규모에서 가능한 이야기입니다.

한국의 중소기업, 혹은 저희처럼 둘이서 스튜디오를 운영하는 사람들에게 그 그림은 솔직히 그림의 떡입니다. private RL 환경을 누가 구축할까요. 결과를 측정할 eval 팀을 어디서 데려올까요. 개념은 옳은데, 그 개념이 서 있는 전제가 우리 현실과는 조금 멀게 느껴집니다.

그래서 저는 이 글을 읽으면서 반박할 생각은 전혀 들지 않았습니다. 대신 든 생각은 이것이었습니다. "이 거대한 개념을, 우리 규모에서는 어떻게 번역할 수 있을까."

우리가 실제로 만든 루프

거창한 답은 아닙니다. 우리의 러닝 루프는 나델라가 말한 풀스택 시스템이 아니라, 훨씬 가벼운 형태입니다. 핵심은 하나입니다. 나쁜 코드를 짤 수 없는 틀을 먼저 짠다.

저는 이걸 pivot-forge라고 부릅니다. 매번 프로젝트를 백지에서 시작하지 않습니다. 대신 그동안 쌓인 판단 — 인증은 이렇게, 레이어는 이렇게, 디자인 토큰은 이렇게 — 을 재사용 가능한 틀(pivot-base, pivot-core)에 박아 넣습니다. 그러면 다음 프로젝트는 그 틀 위에서 출발합니다. 모델이 GPT든 Claude든 바뀌어도, '회사 베테랑'의 판단은 틀 안에 남아 있습니다. 나델라가 말한 "제너럴리스트 모델은 갈아끼우되 베테랑의 전문성은 시스템에 남긴다"는 원칙이, 작은 팀 규모에서는 결국 잘 설계된 보일러플레이트로 구현되는 셈입니다.

이게 추상적인 이야기가 아니라는 걸, 최근 한 프로젝트에서 다시 확인했습니다. 미국 클라이언트의 예약 앱을 견적 낼 때, pivot-base와 pivot-core 덕분에 약 1맨먼스 분량의 작업이 이미 끝나 있는 상태에서 출발할 수 있었습니다. 저는 이걸 클라이언트에게 '할인'으로 제시하지 않았습니다. '마진'으로 잡았습니다. 그 1맨먼스는 깎아주는 비용이 아니라, 우리가 그동안 루프를 돌려 쌓아온 자산이 만들어낸 여유이기 때문입니다. 나델라식으로 말하면, 복리로 쌓인 루프의 우위가 실제 견적서에 숫자로 찍힌 순간이었습니다.

그리고 한 가지, 그의 논리를 한 발 더 밀어보면

나델라는 각 회사가 자기 러닝 루프를 '소유'해야 한다고 했습니다. 이 대목에서 저는 그의 주장에 동의하면서, 그 논리를 조금만 더 끌고 가보고 싶어집니다.

루프를 소유해야 한다면, 그 루프가 어디에 쌓이느냐도 함께 따져봐야 합니다. 회사의 축적된 지식이 전부 특정 플랫폼 위에서만 굴러간다면, 그건 소유라기보다 임대에 가깝습니다. 플랫폼이 정책을 바꾸거나 가격을 올리면, 내 자산이라고 믿었던 루프가 통째로 흔들릴 수 있으니까요. 그래서 저는 루프를 만들 때 '옮길 수 있는가'를 먼저 봅니다. 데이터는 가능한 한 우리 쪽에 두고, 틀은 특정 벤더에 묶이지 않게 설계합니다.

이건 나델라를 거스르는 게 아닙니다. 오히려 그가 말한 '소유'를 끝까지 밀어붙이면 자연스럽게 도착하는 결론이라고 생각합니다. 거대 플랫폼은 생태계의 비전을 그릴 수 있습니다. 다만 그 생태계 위에서 자기 자산을 실제로 지키는 일은, 결국 각자의 몫으로 남습니다.

정리하며

나델라의 글은 옳습니다. 그리고 그 옳음은 대기업만의 것이 아닙니다. 핵심은 규모가 아니라 방향이라고 생각합니다. 한 번 쓰고 버려지는 작업이 아니라, 쓸수록 쌓이는 구조에 시간을 넣는 것. 모델을 쫓는 대신, 모델이 바뀌어도 남는 틀을 먼저 짜는 것.

우리는 단 두 사람의 에이전시 규모에서 그 일을 해왔습니다. 그래서 같은 고민을 하는 회사들 — 'AI를 도입하긴 해야 하는데, 우리 지식이 그냥 모델 속으로 빨려 들어가 사라지는 건 아닐까' 걱정하시는 분들 — 과 우리가 번역해온 방식을 함께 이야기 나눌 수 있으면 좋겠습니다. 거대한 시스템이 아니라, 그 회사의 규모에 맞는 러닝 루프부터요.