🤖 AI 에이전트 시대, 인프라 소프트웨어의 대전환

 

개발자가 아니라 AI가 쓰는 데이터베이스

요즘 TiDB Cloud에서 매일 생성되는 새 데이터베이스 클러스터의 90% 이상이 사람이 아니라 AI 에이전트가 직접 만든다고 해요. 이건 이론이 아니라 실제 프로덕션 환경에서 일어나고 있는 일이에요.

저도 처음엔 놀랐어요. 그런데 곰곰이 생각해보니 이건 시작에 불과하더라고요. 앞으로 인프라 소프트웨어의 주 사용자는 개발자(인간)에서 AI 에이전트로 급격하게 전환될 거예요. 이미 Claude Code 같은 도구들이 터미널에서 직접 코딩 작업을 처리하고 있잖아요.

그렇다면 질문이 생기죠. AI가 주 사용자가 되는 세상에서, 인프라 소프트웨어는 어떻게 설계되어야 할까요?

AI가 이해하는 건 UI가 아니라 멘탈 모델

UI나 API 디자인에 대해 우리가 그동안 고민했던 것들, 사실 AI 시대엔 큰 의미가 없어요. AI가 진짜 이해하는 건 그 뒤에 숨은 '멘탈 모델'이거든요.

생각해보세요. LLM은 학습 과정에서 엄청난 양의 코드와 엔지니어링 사례를 봤어요. 그 과정에서 AI가 본 건 다양한 세계가 아니라 반복되는 패턴이었죠. 파일 시스템, 운영체제, SQL 쿼리처럼 수십 년간 검증된 추상화 개념들이요.

OpenAI의 2024년 개발자 설문에 따르면, GPT-4를 활용하는 개발자의 78%가 기존에 익숙한 도구와 패턴을 그대로 사용한다고 답했어요. 새로운 프레임워크를 배우는 것보다 익숙한 것을 활용하는 게 훨씬 효율적이기 때문이죠.

그래서 저는 LangChain 같은 새로운 에이전트 프레임워크에 회의적이에요. 사람도 배우기 싫어하는데, AI가 잘 이해할 리 없잖아요. 오히려 파일 시스템, Bash 스크립트, SQL처럼 오래되고 안정적인 멘탈 모델을 따르는 게 훨씬 효과적이에요.

확장 가능한 멘탈 모델의 힘

좋은 멘탈 모델은 확장 가능해야 해요. 파일 시스템이 대표적인 예죠. Linux의 VFS나 Plan 9의 9P는 기존 멘탈 모델을 깨지 않으면서도 완전히 새로운 구현을 추가할 수 있게 해줘요.

최근 제가 실험한 agfs라는 프로젝트가 있어요. 플러그인 방식의 파일 시스템인데요, 그 안의 vectorfs라는 구현이 재밌어요. 겉보기엔 그냥 평범한 파일과 디렉토리인데, 파일을 복사하면 자동으로 청크 단위로 나뉘고, 임베딩되고, 벡터 인덱스에 저장돼요. grep 명령어는 단순 문자열 매칭이 아니라 의미 기반 유사도 검색으로 작동하고요.

핵심은 이거예요. 인터페이스는 똑같아요. echo, cat, ls, cp 전부 그대로 작동해요. 하지만 내부 구현은 완전히 다른 일을 하죠. 이게 바로 안정적인 추상화의 힘이에요.

AI 시대엔 이게 더 중요해져요. AI 에이전트는 사람보다 수천 배 빠르게 코드를 작성하거든요. 시스템도 그만큼 빠르게 진화해야 하는데, 추상화가 불안정하면 금방 통제 불능 상태가 되겠죠.

생태계는 여전히 중요할까?

MySQL이냐 PostgreSQL이냐. MongoDB냐 다른 NoSQL이냐. 사람들은 이런 선택을 두고 끝없이 논쟁하죠. 그런데 AI 에이전트한테는 이게 거의 의미가 없어요.

에이전트는 선호가 없어요. 구문이 우아한지, 커뮤니티 문화가 어떤지 관심 없어요. 인터페이스가 안정적이고, 시맨틱이 명확하고, 문서가 온라인에 있으면 그냥 빠르게 적응해요.

2024년 GitHub Copilot 사용 통계를 보면, 개발자들이 Copilot을 통해 생성한 코드의 85%가 기존에 널리 쓰이는 라이브러리와 프레임워크를 활용한 것으로 나타났어요. 새로운 도구보다 검증된 도구를 압도적으로 선호하는 거죠.

그렇다고 생태계가 아예 의미 없다는 건 아니에요. 중요한 건 근본적인 멘탈 모델이 올바르고 안정적인가예요. MySQL이든 PostgreSQL이든, 둘 다 SQL이라는 검증된 추상화를 공유하잖아요. 에이전트 입장에선 둘 다 '이해 가능한' 시스템이에요.

결국 표면적인 생태계 차이가 아니라, 밑바탕의 모델이 제대로 되어 있는지가 관건이에요.

인터페이스 설계의 3가지 원칙

AI 에이전트가 사용자인 시대에, 좋은 소프트웨어 인터페이스는 세 가지 조건을 만족해야 해요.

첫째, 자연어로 설명 가능해야 해요. 이건 "자연어 입력을 지원한다"는 뜻이 아니에요. "인터페이스의 의도를 자연어로 명확하게 표현할 수 있다"는 거예요.

Claude Code가 전통적인 GUI를 버린 이유가 여기 있어요. GUI는 언어로 정확하게 설명하기 어렵거든요. "여기 클릭하고, 저기 드래그하고" 같은 건 시각적 맥락 없이는 거의 불가능해요. 반면 코딩은 대부분 기호와 언어의 세계에서 일어나죠.

둘째, 기호 논리로 고정될 수 있어야 해요. 자연어는 의도를 표현하기엔 좋지만, 실행 의미론에는 형편없어요. 작업이 재사용되고, 조합되고, 자동 검증되려면 명확하고 안정적인 형태로 압축되어야 해요.

그래서 성공한 시스템들은 거의 다 중간 표현 계층을 둬요. SQL, 스크립트, 코드, 설정 파일처럼요. 한번 생성되면 더 이상 맥락 해석에 의존하지 않는 형태로 말이죠.

셋째, 결정론적 결과를 제공해야 해요. 이건 두 번째가 잘 되면 자연스럽게 따라와요.

코드가 여전히 최고의 표현 방식인 이유

2025년 말 기준으로, 가장 좋은 기호 표현은 여전히 코드예요. 비프로그래밍 에이전트에게도요.

비용 절약 때문이 아니에요. 인지 밀도 때문이에요. 예를 들어볼게요. 영어 단어 1만 개 리스트가 있고, LLM에게 중국어 정의를 추가하고 싶다고 해봐요. 무식하게 하려면 전체 리스트를 보내고 주석 달라고 하는 건데, 토큰이 엄청 들겠죠.

더 나은 방법은 로직을 코드로 고정하는 거예요. 로직이 코드로 표현되면, 더 이상 모든 데이터를 컨텍스트에 넣을 필요가 없어요. 모델이 규칙을 한 번 이해하면 임의 규모의 데이터에 적용할 수 있죠. 적은 수의 기호로 무한히 반복 가능한 프로세스를 설명하는 거예요.

Anthropic의 2024년 보고서에 따르면, Claude를 활용한 코드 생성 작업 중 73%가 기존 코드 패턴의 변형이었다고 해요. 완전히 새로운 코드를 작성하는 것보다 기존 패턴을 활용하는 게 훨씬 효율적이라는 거죠.

일회용 워크로드가 중요해진다

AI 에이전트가 인프라의 주 사용자가 되면, 우리가 당연하게 여겼던 많은 가정이 무너져요. 사용자는 더 이상 신중하게 계획하고 장기적으로 관리하는 인간 개발자가 아니에요. 빠르게 리소스를 생성하고, 실험하고, 버리고, 재시도하는 에이전트예요. 속도는 사람보다 수천 배 빠르고요.

에이전트 워크로드는 근본적으로 일회용이에요. 즉각 사용 가능하고, 쉽게 생성되고, 실패 비용이 제로인 게 장기적 안정성보다 중요해요. 성공해도 대부분 임시적이고요.

이건 인프라가 더 이상 "클러스터는 소중하다"고 가정할 수 없다는 뜻이에요. 인스턴스는 저렴하고, 수명이 짧고, 대규모로 확장 가능해야 해요.

TiDB를 사용하는 에이전트들을 관찰해보면 명확해요. 여러 브랜치를 병렬로 띄우는 걸 좋아하거든요. 하나가 작동하면 나머지는 버려요. SQL도 코드도 대부분 글루 코드처럼 보여요. 우아하진 않지만 실행되고 아이디어를 검증하면 그만이죠.

극단적인 비용 효율성

"극단적으로 낮은 비용"은 단순히 저렴하다는 뜻이 아니에요. 시스템이 엄청난 롱테일 수요를 감당할 수 있다는 뜻이에요.

많은 에이전트 워크로드는 접근 빈도가 극히 낮아요. 하루에 한 번, 심지어 며칠에 한 번이요. 하지만 여전히 온라인 서비스예요.

전통적인 모델, 즉 작업당 실제 인프라 환경 하나, 또는 에이전트당 Postgres 프로세스 하나는 확장이 안 돼요. 하드웨어 비용을 떠나서, 수백만 개의 프로세스, 하트비트, 상태를 관리하는 것만으로도 버틸 수 없거든요.

그래서 피할 수 없는 결론이 나와요. 모든 에이전트, 모든 수요에 실제 물리 인스턴스를 제공할 수 없어요. 가상화를 도입해야 해요. 가상 데이터베이스 인스턴스, 가상 브랜치, 가상 환경처럼요. 리소스는 최대한 공유하되, 시맨틱은 격리되어야 하죠.

어려운 부분은 여기예요. 리소스 재사용을 최대화하면서도, 에이전트 입장에선 상호작용상 "내 전용 환경"처럼 느껴져야 해요.

구체적인 예시로, Manus 1.5의 에이전트들은 TiDB Cloud를 데이터베이스로 써요. 테이블 생성하고, 삭제하고, 실험하고, 쓰레기 같은 SQL 돌려도 다른 에이전트에게 영향 없어요. 부작용 걱정도 없고요.

이게 안 되면, 에이전트들은 "조심히 리소스를 사용하는" 모드로 돌아가야 해요. 그러면 병렬 탐색과 빠른 반복의 장점이 완전히 사라지죠.

작업당 컴퓨팅 레버리지 측정하기

에이전트 인프라에서 거의 논의되지 않는 주제가 하나 있어요. 작업당 얼마나 많은 컴퓨팅을 활용할 수 있는가?

현재 대부분의 상호작용 패턴, ChatGPT든 로컬 코딩 에이전트든, 직렬이에요. 요청 하나, GPU 하나, 응답 하나. 강력하지만 근본적으로 순차적이죠.

하지만 실제 세계의 많은 문제는 팀 규모의 병렬성이 필요해요. 수백 개의 NeurIPS 논문을 훑는다고 상상해봐요. 전통적 에이전트는 순차적으로 읽겠죠. 분산 에이전트 접근법은 작업을 수백, 수천 개의 작업으로 병렬 분할한 다음, 결과를 집계하고, 교차 검증하고, 구조화할 거예요.

그 모델에서는 단위 시간당 컴퓨팅이 GPU 하나에서 수백, 수천 개로 확장돼요. Gartner의 2024년 분석에 따르면, 엔터프라이즈 AI 워크로드의 62%가 향후 2년 내 분산 처리 방식으로 전환될 것으로 예상된다고 해요.

이건 구체적인 인프라 질문을 던져요. 당신 시스템은 1,000개의 워크스테이션을 저렴하게 띄울 수 있나요? 작업을 분배하고, 결과를 집계하고, 중복 제거하고, 재시도하고, 재생할 수 있나요? 비용을 실시간으로 볼 수 있나요?

비즈니스 모델의 대전환

비즈니스 모델의 가장 큰 변화는 이거예요. 이전에는 경제성이 없던 많은 모델이 갑자기 말이 되기 시작했어요.

전통적인 소프트웨어에서 맞춤화는 위험 신호였어요. 엔지니어는 비싸니까요. 작은 고객은 그만한 가치가 없었죠. 작은 식료품점 주인이 재고 관리 시스템을 원한다고요? 역사적으로 불가능했어요. 양쪽 다 너무 비쌌거든요.

수요는 항상 존재했어요. 그저 경제성이 막았을 뿐이죠. 에이전트가 이걸 바꿔요. 계산을 민주화하거든요. 코딩, 프로토타이핑, 실험이 저렴해져요. 수요가 사라진 게 아니라 비용이 마침내 충분히 낮아진 거예요.

그래서 저는 점점 더 확신해요. 성공적인 에이전트 기업은 "토큰을 파는" 게 아니어야 해요. 토큰 기반 모델은 구조적 문제가 있어요. 사용량이 비용과 함께 증가하거든요. 토큰 가격이 떨어져도 토큰을 더 많이 팔면 비용이 여전히 증가해요. 그건 취약해요.

지속 가능한 모델은 클라우드 서비스 회사처럼 보여요. 사용자 기반이 에이전트로 인해 100배, 1,000배 증폭되는 거죠. 핵심은 반복적인 추론을 재사용 가능하고, 결정론적인 시스템 기능으로 전환하는 거예요. 지루한 온라인 서비스지만 한계 비용은 거의 제로죠.

마치며: 이미 세상은 바뀌었어요

에이전트 시대는 이미 왔어요. 프로그래머로서 우리가 당연하게 여겼던 많은 가정들을 다시 생각해봐야 해요. 코드는 더 이상 희소하지 않아요. 소프트웨어를 신중하게 보존할 필요도 없고요. 시스템은 자연스럽게 생성되고, 테스트되고, 버려질 거예요.

이게 엔지니어링을 덜 중요하게 만들진 않아요. 오히려 정반대예요. 초점이 이동하는 거죠. 개별 시스템을 완벽하게 만드는 것에서, AI가 대규모로 사용하고 반복하고 저렴하게 실행할 수 있는 기초 역량을 설계하는 것으로요.

"코드 작성"이나 "시스템 제어"에 대한 집착을 내려놓으면, 앞으로 나아갈 길이 더 명확해져요. 진짜 중요한 질문은 대부분 오래된 질문을 다시 묻는 거예요. 세상은 이미 사용 방식을 바꿨어요. 저항할 필요 없어요. 환영하세요, 기계의 세상에.

핵심 요약: AI 에이전트가 인프라 소프트웨어의 주 사용자가 되면서, 설계 철학이 근본적으로 바뀌고 있어요. 안정적이고 검증된 멘탈 모델을 유지하면서도, 일회용 워크로드를 대규모로 처리할 수 있는 극단적 비용 효율성이 필수가 되었죠. 비즈니스 모델도 토큰 판매에서 에이전트 증폭형 클라우드 서비스로 전환되고 있어요. 이미 변화는 시작됐고, 우리는 그 흐름에 올라타야 해요.