셔틀의 노다르 다넬리야 CEO 및 공동 창립자 – 인터뷰 시리즈

노다르 다넬리야, 셔틀의 CEO 및 공동 창립자 – 인터뷰 시리즈: 노다르 다넬리야는 2019년에 회사를 설립한 이후 셔틀의 공동 창립자 및 CEO로 재직하며, 초기 YC Summer 2020 스타트업에서 개발자 중심의 플랫폼 엔지니어링 회사로 성장하였습니다. 셔틀 이전에는 Provenance Technologies Ltd의 Chief Risk Officer를 포함한 역할을 수행하며, 정량적 헤지 펀드 전략을 담당하였고, 런던 및 구글에서 기술 및 데이터 역할을 수행했습니다.

셔틀은 개발자들이 별도의 구성 파일이나 복잡한 클라우드 설정을 관리하지 않고 Rust 또는 다른 코드를 작성하는 데 집중할 수 있도록 코드 주석에서 인프라를 파생하는 오픈 소스 클라우드 인프라 플랫폼입니다. 이 플랫폼은 빠른 배포, 즉시 리소스 프로비저닝 및 원활한 확장을 가능하게 하며, 13만 개 이상의 배포를 통해 수만 명의 엔지니어들이 사용하고 있습니다. 셔틀은 제로 구성, AI 지원 경험을 모든 언어로 확장하고 GitHub Copilot 및 Cursor와 같은 도구와 통합하는 것을 목표로 합니다.

어떤 순간이나 좌절이 Shuttle을 공동 창립하게 했으며, 처음에는 어떤 문제를 해결하려 했나요?

전환점은 제가 정량적 헤지펀드에서 거래 업무를 이끌던 때였습니다. 박사 학위 소지자, 선임 플랫폼 전문가, 머신러닝 연구자 등 뛰어난 엔지니어들이 있었지만 그런 인재들이 있어도 클라우드 인프라는 늘 병목이었습니다. 거래 모델이나 백엔드 서비스를 만드는 일이 어려운 것은 아니었습니다. 문제는 안전하게 가동하고 규모를 확장하며 클라우드 서비스들을 연결하는 배포 작업이었습니다. 모든 일이 거기서 느려졌습니다. 한때는 엔지니어링 팀의 절반 이상이 시스템을 계속 가동하기 위한 DevOps 업무를 하고 있었습니다.

제게 남은 것은 코드나 수학의 정교함이 아니었습니다. 능력이 뛰어난 사람들이 정말 중요한 것을 만드는 대신 클라우드와 싸우는 데 대부분의 시간을 소모하는 모습이었습니다. 아무도 원하지 않는 일이었지만 피할 수 없었습니다. Shuttle은 바로 그 마찰, 즉 “무언가를 만들었다”와 “그것이 안정적으로 실행된다” 사이의 간극을 해결하기 위해 만들어졌습니다.

Shuttle은 오늘날의 AI 코딩 도구 물결 이전인 2019년에 설립되었습니다. AI 지원 개발이 주류가 되면서 원래의 비전은 어떻게 발전했나요?

핵심 문제는 그대로였지만 AI가 이를 극적으로 증폭시켰습니다. 시작할 때부터 인프라는 뛰어난 엔지니어링 팀을 제약하는 요소였습니다. Copilot, Cursor, Claude 같은 도구가 등장하자 그 병목은 더 이상 무시할 수 없게 되었습니다.

갑자기 개발자들은 몇 분 만에 완전한 애플리케이션을 생성할 수 있었지만, 그 앱들은 곧바로 벽에 부딪혔습니다. AI는 코드를 작성할 수 있지만 클라우드 리소스를 안정적으로 구성하고 관리하지는 못합니다. 우리가 해결하려던 간극은 훨씬 넓고 시급해졌습니다. 이제 수백만 명이 프로토타입을 만들지만 실제 프로덕션에 도달하는 것은 일부에 불과합니다.

비전은 “개발자가 인프라를 더 쉽게 사용하게 하자”에서 “완전히 새로운 세대의 제작자를 위해 인프라가 작동하게 하자”로 발전했습니다. 백엔드 코드는 만들 수 있지만 클라우드 구성과 씨름하고 싶지 않은 1인 창업자, 소규모 팀, AI 에이전트가 그 대상입니다. 이제 전통적인 엔지니어만을 위한 서비스가 아닙니다. 사용자층이 폭발적으로 늘었습니다.

Cursor와 GitHub Copilot 같은 AI 도구는 개발자의 코드 작성 방식을 바꿨습니다. 소프트웨어 수명 주기에서 가장 크게 개선된 부분과 여전히 팀들이 어려움을 겪는 부분은 무엇인가요?

코드 생성은 크게 발전했습니다. 그 부분은 거의 해결되었습니다. 기능을 설명하면 AI가 기본 구조를 만들어 줍니다. 특히 프런트엔드는 구성요소, 스타일, 레이아웃처럼 패턴이 잘 알려져 있어 큰 혜택을 받았습니다.

팀들이 어려움을 겪는 것은 그다음의 모든 일, 즉 배포, 인프라, 운영입니다. AI는 API 엔드포인트를 생성할 수 있지만 이를 실제로 작동하게 할 데이터베이스, 스토리지, 큐, 네트워크, 권한, 배포 파이프라인을 자동으로 만들지는 못합니다. 백엔드 인프라는 코드 생성의 발전 속도를 따라가지 못했습니다.

그 결과 진전이 고르지 않습니다. 처음부터 끝까지 일이 단순해지는 대신 새로운 압박 지점이 생깁니다. 팀은 몇 분 만에 전체 백엔드를 생성한 뒤 안전하게 배포하려다 며칠씩 막힙니다. 때로는 AI가 팀에서 실제로 실행하거나 유지할 수 있는 양보다 더 많은 코드를 생성해 상황을 악화시킵니다. 이제 실질적인 마찰은 그곳에 있습니다.

배포는 AI 생성 애플리케이션의 가장 큰 병목으로 자주 언급됩니다. 코드를 생성하는 것보다 이러한 시스템을 프로덕션 환경에 투입하는 일이 훨씬 어려운 구체적인 이유는 무엇인가요?

문제는 신뢰성과 결과입니다. 코드 생성에서는 실수를 바로 보고 고칠 수 있습니다. 인프라 실수는 다릅니다. 잘못된 권한 하나, 잘못 구성된 리소스 하나, 비용이나 보안에 대한 잘못된 가정 하나가 나중에야 드러날 실제 문제를 만들 수 있습니다.

초기에는 AI가 애플리케이션 코드에서 인프라를 자유롭게 추론하도록 해 보았습니다. 데모에서는 훌륭했지만 실제 시스템에서는 무너졌습니다. AI는 거의 맞지만 완전히 맞지는 않는 구성을 자신 있게 만들었습니다. 지나치게 넓은 권한, 이상한 리소스 선택, 모르는 사이 비용이 커지는 설정 등이었습니다.

이 경험은 중요한 사실을 가르쳐 주었습니다. 프로덕션에서 경계 없는 지능은 문제를 만듭니다. AI에 필요한 것은 더 많은 자유가 아니라 더 나은 안전장치입니다. AI가 제안하고 속도를 높이되 무분별하게 행동하지 못하는 시스템을 설계해야 합니다. 이것이 AI 생성 앱의 프로덕션 투입을 코드 생성보다 훨씬 어렵게 만드는 기술적 과제입니다.

Shuttle은 최근 플랫폼의 다음 단계로 Neptune을 선보였습니다. 범용 AI 플랫폼 엔지니어라는 설명은 프로토타입에서 프로덕션용 백엔드로 넘어가는 개발자에게 실제로 어떤 의미인가요?

Neptune은 코드와 프로덕션 사이에 빠져 있던 계층입니다. 개발자나 AI 에이전트는 애플리케이션 로직 작성에 집중하고, Neptune은 필요한 인프라 파악, 리소스 프로비저닝, 비밀 정보 관리, 배포, 서비스 오케스트레이션을 비롯한 나머지를 처리합니다.

개발자가 애플리케이션을 클라우드 인프라로 변환하게 하는 대신 Neptune이 애플리케이션을 이해하고 그 주변의 인프라를 생성합니다. 코드가 설계도이고 Neptune이 실행에 필요한 환경을 구축합니다. Dockerfile도, Terraform도, 끝없는 구성 작업도 필요하지 않습니다.

프로토타입에서 프로덕션으로 넘어가는 사람은 갑자기 DevOps를 배워야만 하는 벽에 부딪히지 않게 됩니다. 만든 애플리케이션은 규모를 확장해도 계속 작동합니다. Neptune은 “무언가를 만들었다”와 “그것이 프로덕션에서 안정적으로 실행된다” 사이의 간극을 메웁니다.

개발자들이 백엔드 시스템 생성에 AI를 더 많이 활용하면서 속도와 추상화의 이점을 제어, 보안, 관측 가능성의 필요와 어떻게 조화시키나요?

답은 신뢰입니다. 인프라에서는 능력보다 신뢰가 중요합니다. 보안 취약점, 실패한 배포, 막대한 클라우드 청구서 같은 나쁜 돌발 상황 한 번이면 사용자의 신뢰를 잃습니다.

우리는 AI가 다루는 모든 것은 이해하고 검토할 수 있어야 한다는 점을 일찍 배웠습니다. 개발자가 직접 구성하지 않았더라도 무엇이 왜 일어나는지 볼 수 있어야 합니다. 그래서 Neptune은 결정론적 인프라 규칙을 사용합니다. AI는 제안하고 속도를 높일 수 있지만 모든 동작은 검토하고 예측하고 시험할 수 있는 명세에 근거합니다.

우리는 “AI가 결정한다”에서 “AI가 제약 안에서 제안한다”로 전환했습니다. 이것이 재미있는 데모와 중요한 순간에 신뢰할 수 있는 시스템의 차이입니다. 개발자들은 결정에 쓰는 시간을 줄이는 것이 아닙니다. 타이핑에 쓰는 시간을 줄이고 무엇이 있어야 하는지, 무엇을 수용할 수 있는지, 어떤 절충이 합리적인지 판단하는 데 더 많은 시간을 씁니다. 가장 뛰어난 팀은 AI를 유능한 주니어 엔지니어처럼 대합니다. 도움이 되고 생산적이지만 최종 결정권자는 아닙니다.

현재 독립 개발자, 스타트업, 대규모 엔지니어링 조직 중 어떤 팀들이 Neptune에서 가장 큰 가치를 얻고 있나요?

사용자층은 크게 달라졌습니다. 처음 Rust 쪽에서는 개인 개발자, 초기 스타트업, 스케일업, 심지어 자동차, IoT, 금융, 암호화폐 분야의 기업 팀까지 다양했습니다. 신뢰성과 성능이 중요한 곳이라면 어디든 해당했습니다. 이들은 복잡한 클라우드 인프라를 관리하는 부담 없이 Rust의 강력함을 원했습니다.

하지만 지난 1년간 AI 기반 개발의 부상은 소프트웨어를 만드는 사람들을 완전히 바꿨습니다. 이제 1인 창업자, 인디 개발자, AI 에이전트, 소규모 팀, 전통적인 소프트웨어 회사가 모두 전례 없는 속도로 백엔드 코드를 생성합니다. 사용자층은 더 이상 전문 분야의 선임 엔지니어만이 아닙니다.

1인 창업자와 소규모 팀이 한 번의 작업 세션에 아이디어에서 배포된 백엔드까지 나아가는 모습을 자주 봅니다. 설정에 며칠을 쓸 필요가 없기 때문입니다. 시간 절약만이 아니라 초기 단계에서 무엇보다 중요한 추진력을 유지하는 것입니다. 가장 큰 가치는 바로 여기에 있습니다. 만들 능력은 있지만 아이디어를 출시하기 위해 인프라 전문가까지 되고 싶지는 않은 사람들을 돕는 것입니다.

기술적으로 Neptune은 AI 생성 코드를 배포 가능한 프로덕션 백엔드로 바꿀 때 환경 구성, 비밀 정보 관리, 인프라 오케스트레이션을 어떻게 처리하나요?

Neptune은 코드와 인프라를 하나의 통합 시스템으로 취급합니다. 대부분의 배포 도구는 배송 서비스처럼 작동합니다. 사용자가 컨테이너를 가져오면 실행하려고 합니다. 클라우드 리소스를 연결하고, 구성을 작성하고, 환경 변수를 다루고, 비밀 정보를 관리하고, 데이터베이스를 프로비저닝하는 일은 여전히 사용자의 책임입니다.

Neptune은 그 모델을 뒤집습니다. 개발자가 애플리케이션을 클라우드 인프라로 변환하는 대신 Neptune이 애플리케이션을 이해하고 주변 인프라를 생성합니다. 이는 AI 네이티브 DevOps 접근법입니다. 코드가 설계도이고 Neptune이 비밀 정보 관리, 환경 구성, 리소스 오케스트레이션을 포함한 실행 환경을 만듭니다.

핵심은 AI가 결정론적 인프라 규칙 안에서 작동한다는 것입니다. 임의의 구성을 만들 수 없습니다. 모든 것을 계속 검토하고 예측할 수 있으며, 이는 프로덕션 환경의 보안과 비용 통제에 필수적입니다.

AI 시스템이 다른 소프트웨어 시스템을 점점 더 많이 구축하고 배포하고 관리하는 생태계에서 Neptune의 역할은 앞으로 어떻게 발전할까요?

우리는 아이디어와 작동하는 제품 사이의 간극이 거의 없는 세계로 나아가고 있습니다. 머지않아 제품은 더 빨리 만들어질 뿐 아니라 사람들이 실제로 사용하는 방식에서 나오는 실시간 피드백을 바탕으로 스스로 계속 개선될 것입니다.

그 세계에서 소프트웨어는 정적이지 않을 것입니다. 앱, 에이전트, 시스템이 끊임없이 생성되고 수정되고 발전할 것입니다. 그 모든 것은 여전히 어딘가에서 실행되어야 하며 인프라, 권한, 리소스, 신뢰성이 필요합니다.

장기 목표는 AI 지원 DevOps의 기본 시스템, 본질적으로 AI 플랫폼 엔지니어가 되는 것입니다. 개발자가 Cursor에서 코드를 작성하든 AI 에이전트가 자율적으로 생성하든, Neptune은 코드를 완전히 실행되고 확장 가능한 프로덕션급 서비스로 바꾸는 계층이어야 합니다.

창의력이 무한해진다면 인프라가 제약이 되어서는 안 됩니다. AI 에이전트와 스스로 발전하는 제품이 일반화될수록 클라우드 인프라와의 상호작용을 원활하고 예측 가능하며 안전하게 만드는 것이 우리의 일입니다. 우리는 그 과정을 보이지 않게 하여 개발자, 창업자, 기업이 인프라와 싸우는 대신 가치를 만드는 데 집중하도록 하는 데 주력합니다.

훌륭한 인터뷰에 감사드립니다. 더 자세히 알고 싶은 독자는 Shuttle을 방문하시기 바랍니다.