인터넷의 근본 문제는 ‘연결’이 아니라 ‘조정’이다. Sui를 인터넷의 네이티브 조정 레이어로 제시하며, 객체 중심의 원자적 API와 프로그래머블 트랜잭션 블록(PTB)로 조합 가능한 실행 환경을 구현하는 방법을 설명한다. 에이전트 시대를 위한 결정적이고 검증 가능한 컴포저빌리티를 주장한다.
인터넷의 최종 형태는 더 빠른 사일로가 아니다. 코드, 가치, 정체성이 하나의 원자적 단위로 함께 이동하는 글로벌 조정 레이어다. Sui는 그 레이어다.
주의: 읽는 데 약 11분. 커피 한 잔 준비하세요!
추신: 업데이트를 받으려면 제 Substack 링크를 확인하세요:
인터넷은 우리가 오늘 그것에 요구하는 것을 처리하도록 만들어지지 않았다.
인터넷은 원래 보편적 기질, 즉 기본적으로 개방적이고 민주적이며 조합 가능한 것으로 설계되었다. 모든 것이 맞물리도록 되어 있어 혁신이 누적될 수 있는 그런 것 말이다.
그게 꿈이었다. 하지만 우리가 얻은 것은 매우 달랐다.
오늘날 인터넷은 겉보기엔 빠르지만, 내부를 들여다보면 분절되어 있고, 불투명하며, 매우 취약하다.
번지르르한 앱 뒤에는 맞춤형 커넥터, 일회성 통합, 손으로 쓴 글루 코드의 뒤엉킨 덩어리가 있다.
동영상:
시스템 간 데이터를 옮길 때마다 아무것도 고장 나지 않기를 바랄 뿐이다.
새로운 앱은 매번 재발명이다. 사용자 경험은 무식하게 꿰매 붙인다. 우리는 깨진 기반 위에 더 많은 추상화를 얹어 왔지만, 그 기반 자체를 고치러 돌아간 적은 없다.
결국 우리는 ‘조합되지 않는’ 웹을 갖게 되었다.
서비스마다 사일로이고, 앱과 시스템, 에이전트 간 조정은 인프라에 네이티브가 아니라 사후에 덕트 테이프로 붙인다.
가치는 느리게 움직이고, 로직은 이동할 수 없으며, 가장 기본적인 상호작용조차도 수많은 중개인에 대한 신뢰를 요구하는 인터넷을 만들었다.
그리고 상자를 조금만 벗어난 일을 하려 할 때마다 그걸 느끼게 된다. 깊이 들여다볼수록 더 명확해진다.
그 위에 더 쌓을수록 더 나빠진다.
새 앱 하나가 복잡성을 한 겹 더한다. 엔드포인트 하나, 스키마 하나, 시스템 간 ‘묵시적 합의’ 하나가 더 늘고, 깨질 때까지 아무도 기억하지 못한다.
문제는 연결이 아니다. ‘조정’이 안 된다는 것이다.
개발자들은 몇 분이면 맞물려야 할 서비스를 연결하느라 몇 주를 보낸다.
앱에서 결제를 트리거하고, 데이터베이스를 업데이트하고, 알림을 보내고, 파일을 저장하고 싶다고?
축하한다! 이제 기본적인 일을 하려고 5개의 서로 다른 API, 3셋의 인증 키, 2개의 타임아웃을 곡예처럼 다뤄야 한다.
출처 링크:
공유 컨텍스트도, 네이티브 조정 방식도, 서비스 간 진정한 조합형 경험을 만드는 방법도 없다.
우리는 이 마찰을 인터넷에서 사업하기 위한 ‘원가’로 받아들였다. 누더기를 정상으로 만들고, 그 난장판을 관리하는 데 평생을 바치는 커리어도 설계한다.
하지만 그 비용이 제품 로드맵 전체를 집어삼키기 시작하면 어떻게 될까?
‘통합을 작동시키기’만 하려고 팀 전체를 채용할 때?
아무것도 조합되지 않기 때문에, 이미 존재하는 것을 처음부터 다시 만들 수밖에 없을 때?
그게 지금 우리가 살고 있는 세계다.
진정한 조합성이 없다는 사실을 가리기 위해 SDK, 개발 도구, 글루 코드의 경제가 통째로 생겨났다.
출처 링크:
추상화로 문제를 벗어났다고 생각할 때마다, 우리는 결국 같은 오래된 균열 위에 새로운 추상화를 또 올려놓는다. 그리고 일이 필연적으로 깨지면, 우리는 기반을 의심하지 않고 증상을 땜질하고 넘어간다.
하지만 그 마찰 비용은 사라지지 않는다. 쌓이고, 복리로 불어나고, 결국 어디에나 모습을 드러낸다.
분절 상태를 유지하는 비용은 기술적 부채만이 아니라, 결코 출시되지 못한 혁신이다.
개발자들은 제품 자체와 무관한 코드를 씨름하는 데 시간을 거의 40%나 쓴다. 디자인도, 핵심 기능 개발도, 가능성의 경계를 넓히는 일도 아닌, 그저 마찰과 싸우는 데 쓴다.
그리고 금세 눈덩이처럼 불어난다.
출처 링크:
산업 전반에서, 서로 말이 통하지 않도록 설계된 시스템들을 연결하는 데만 매년 수십억 달러가 불타고 있다.
그건 추상적 비효율이 아니다. 개발자 급여, 제품 일정, 시장 기회가 통째로 잡아먹히는 일이다.
그리고 팀이 마침내 출시할 때쯤이면, 재사용이 너무 어려워 이미 있는 일을 중복해 구현해 버린 경우가 많다. API는 제각각이고, 인증 플로우는 지저분하고, 비즈니스 로직은 모듈식으로 재사용되도록 만들어지지 않았다.
그래서 팀은 밑단에 조합 가능한 기반이 없기 때문에, 약간씩 다른 포장만 바꿔 같은 것을 계속 다시 만든다.
matt swanson 
@_swanson
요즘 SaaS의 상당 부분은 이렇다: 네 데이터베이스를 감싸는 API를 만들어라. 그래야 내가 JSON을 파싱해서 내 데이터베이스에 집어넣을 수 있으니까.
통합 지연은 배포 주기를 몇 주에서 분기 단위로 늘린다.
PM은 마감일을 지키려 기능을 죽인다. 스타트업은 타이밍을 놓친다. 엔터프라이즈는 출시가 멈춘다. 끝내 모멘텀을 죽이는 건 경쟁이 아니라 내부의 저항이다.
이게 분절의 진짜 결과다.
출처 링크:
아이디어 한 세대가 백로그 림보 속에서 죽어간다. 조정 비용이 정당화하기엔 너무 크기 때문이다. 그런데도 이상하게, 이게 정상처럼 굳어졌다. 더는 묻지도 않는다.
하지만 충분히 멀리서 보면 그림이 선명해진다.
문제는 시간이나 비용이 아니라 ‘아키텍처’다. 뭔가 근본이 깨졌다. 처음부터 그랬다.
증상을 탓하기 쉽다. 글루 코드, 다운타임, 통합 작업에 사라지는 개발 시간. 하지만 그건 못난 팀이나 나쁜 계획에서 시작된 게 아니다. 인터넷의 DNA에서 비롯되었다.
원죄는 아키텍처적이다. 원래의 프로토콜은 우리가 오늘 요구하는 용도를 염두에 두고 만들어지지 않았다.
출처 링크:
그들은 ‘프로그램’이 아니라 ‘문서’를 위해 만들어졌다. ‘퍼블리싱’을 위해서지 ‘조정’을 위해서가 아니다. 정보를 보내기 위해서지, 로직을 조합하기 위해서가 아니었다.
스택 전체가 읽기 전용의 세계 모델을 중심으로 설계됐다. 페이지를 로드하고, 링크를 클릭하고, 폼을 보내고, 끝. (초기 웹 1.0)
하지만 현대의 인터넷은 그렇지 않다.
오늘날 모든 것이 인터랙티브하다. 앱은 다른 앱과 대화하고, 서비스는 다운스트림 서비스를 호출한다. 그러나 그 어떤 것도 인프라의 네이티브가 아니다.
HTTP는 서비스 간 상태 있는 조정을 지원하도록 만들어지지 않았다. API는 메모리 없는 원격 호출일 뿐이다.
보장도, 결정성도 없다. 도메인 간 동작을 합성해 모두 함께 성공하거나 함께 실패하도록 만들 방법도 없다.
공유 실행 레이어가 없다. 그저 허공에 떠 있는 엔드포인트들뿐, 누군가 제대로 선을 연결해 주기를 바랄 뿐이다.
그래서 우리는 우회로를 만든다. 미들웨어에 로직을 욱여넣는다.
마이크로서비스를 써서 마이크로서비스를 다른 마이크로서비스에 붙인다. 재시도, 폴링, 웹훅, 크론 잡에 의존해 ‘조정’이 되는 듯한 환상을 만든다.
하지만 그건 말 그대로 환상일 뿐이다.
바닥에는 여전히 문서 공유에서 한 발도 진화하지 못한 시스템이 있다. 서비스가 조합되지 않고, 로직은 이동할 수 없으며, 신뢰는 앱의 가동 시간에 관심 없는 제3자에게 외주를 줘야 하는 시스템.
우리는 여전히 이 아키텍처 위에서 짓고 있다. 그리고 그 용도를 한참 넘어서 밀어붙였다.
더 멀리 가고 싶다면, 에이전트가 행동하고, 서비스가 조정하며, 가치가 로직과 함께 이동하는 인터넷을 원한다면, 이 기반이 실제로 무엇이어야 하는지 다시 생각해야 한다.
다음 질문은 이것이다:
현대 앱과 곧 뒤따라올 AI 에이전트가 움직일 때마다 중력과 싸우지 않고 네이티브로 조정하려면 어떤 기반이 필요할까?
명확한 것부터 시작하자!
현대 소프트웨어는 더 이상 페이지 묶음이 아니다. 끊임없이 실행되는 프로세스들의 무리, 즉 API, 마이크로서비스, 데이터 스트림이다.
이 모든 것은 일주일짜리 배관 공사와 미들웨어 산을 쌓은 뒤가 아니라, 온라인이 되는 순간부터 조정되어야 한다.
서비스 간 동작은 ‘베스트에포트’ 핸드셰이크여서는 안 된다. 내 코드베이스 안의 함수 호출에서 기대하는 것과 동일한 원자적 확실성이 필요하다.
그리고 참여자는 누구나, 자신이 요청한 일이 실제로 일어났음을 즉시, 암호학적으로 검증할 수 있어야 한다.
그게 새로운 체크리스트를 세운다.
첫째, 조합성: 어떤 서비스든 레고 블록처럼 다른 서비스에 딱 맞아야 한다.
둘째, 검증 가능성: 한 서비스가 다른 서비스를 호출하면 양쪽 모두 무엇이, 언제, 어떤 규칙 아래 일어났는지 정확히 알아야 한다.
셋째, 런타임의 암호학적 보장: 더는 재시도·웹훅·크론 잡 같은 누더기가 아니라, 기질 자체가 계약을 집행해야 한다.
이것이 부서지기 쉬운 엔드포인트에서 살아 움직이는 로직의 시스템으로 졸업하기 위한 최소 사양이다.
우리는 네트워크 전체를 하나의 프로그래머블 표면으로 취급하는 공유 실행 환경이 필요하다.
이메일을 초안하는 LLM은 귀엽다. 하지만 한 번의 라운드트립으로 여행을 예약하고, 통화를 교환하며, 비용을 정산하는 에이전트? 그것에는 기계 속도로 동작하는 결정적이고 조합 가능한 조정이 필요하다.
그보다 못하면 에이전트 경제는 시작도 전에 멈춰 선다.
조정은 기질 자체의 내재적 성질이어야 한다.
진짜 질문: 이것이 인터넷 다음 레이어의 스펙 시트라면, 이미 이것을 ‘배송’하고 있는 곳은 어디인가?
Sui를 인터넷의 ‘빠져 있던 조정 레이어’라고 생각하라.
서비스가 원래 그래야 했던 방식으로 상호작용하도록, 즉 매끄럽고, 예측 가능하며, 글루 코드 없이도 결합되도록 해 주는 마지막 퍼즐 조각이다.
Sui의 차별점은 빠르다거나, 저렴하다거나, 병렬화되었다는 데 있지 않다. 물론 그것들도 맞다. 하지만 진짜 다른 점은 ‘앱이 무엇인가’를 바라보는 관점이다. 대부분의 플랫폼은 여전히 서비스를 고립된 사일로로 취급한다.
Sui는 네트워크를 프로그래머블 표면으로 취급한다.
한 조각의 로직이 다른 조각과 대화하고, 가치와 정체성과 행동이 하나의 단위로 함께 이동하도록 밑바닥부터 설계됐다. 사후에 덧대는 것이 아니다. 열 개의 미들 레이어를 통과시키는 것도 아니다.
네이티브. 조합 가능. 결정적.
토큰 하나를 A에서 B로 넘기려고 전체 아키텍처를 스캐폴딩할 필요가 없다. 두 서비스가 무엇이 일어났는지 합의하게 하려고 별도의 큐 시스템이 필요하지도 않다.
Sui에서는 ‘조정’이 환경의 기능이 된다. 스프린트 계획에서 주니어에게 던져 줄 ‘통합 작업’이 아니다.
즉, 이건 인프라의 업그레이드가 아니라 리셋이다. 서비스가 조정하는 방식, 로직이 이동하는 방식, 시스템이 조합되는 방식에 대한 새로운 기반이다.
하지만 진짜 잠금 해제는 이것을 가능하게 하는 프리미티브를 보면 일어난다.
겉으로는 더 빠른 체인 이상을 제공하지만, Sui는 인터넷에 최초의 ‘네이티브 조합 단위’를 준다.
Sui가 보여 주는 마법은 이것이다: 네트워크의 모든 공개 함수를 ‘원자적 API’로 바꾼다.
허가 없이 어떤 워크플로에도 끼워 넣을 수 있는 호출 가능하고 조합 가능한 단위.
그 밑바닥에서 함수는 임의의 키-값 덩어리가 아니라 ‘객체’를 다룬다. 시스템이 명확하게 추적하고, 소유하고, 변이시킬 수 있는 객체다.
모든 것이 객체 중심이기 때문에, 런타임은 항상 누가 무엇을 소유하는지, 어떤 필드가 바뀌었는지, 두 트랜잭션이 같은 상태를 건드리는지를 안다.
이 지식 덕분에 Sui는 결정성을 해치지 않고 트랜잭션을 병렬로 실행할 수 있다. 더 중요한 것은 개발자가 ‘라이브러리 임포트’만큼 단순하게 ‘조합’을 추론할 수 있게 해 준다는 점이다.
여기에 ‘프로그래머블 트랜잭션 블록(PTB)’을 얹어 보자.
PTB는 네트워크에 쏘는 오케스트레이션 스크립트라고 보면 된다: 이 함수를 호출하고, 그 출력을 저 함수에 넣고, 새 객체를 만들고, 소유권을 이전하라. 이 모든 것을 하나의 매끄러운 연산으로.
전체 의도를 하나의 블록에 패키징하고 서명하면, 네트워크가 ‘전부 일어나거나 전혀 일어나지 않거나’를 보장한다.
갑자기 서비스들을 꿰매는 일이 부서지기 쉬운 통합 코드를 쓰는 느낌이 아니라, 에디터에서 순수 함수를 합성하는 일처럼 느껴진다.
여기서부터 흥미로워진다. PTB는 어떤 원자적 API도 호출할 수 있으므로, 완전히 다른 팀이 작성한 모듈 간에 로직을 체인으로 연결할 수 있다.
항공권 예약 서비스가 좌석을 잡고, 철도 운영사가 기차를 확정하고, 호텔 시스템이 객실을 확정한다. 세 개의 분리된 도메인이 하나의 실행 컨텍스트에서, 글루 코드 없이.
오케스트레이션은 크론 잡이나 새벽 2시에 간호해야 하는 메시지 큐가 아니라, 블록 안에 산다.
그 결과 움직이는 부품이 줄고, 엣지 케이스가 줄며, 결정적으로, 기계가 사람의 손을 빌리지 않고도 검사하고 검증할 수 있는 실행 흐름이 된다.
개발자에게 주는 이점은 명확하다: 연결 작업에 덜 시간을 쓰고, 기능을 더 빨리 선적한다.
AI 에이전트에게는 더 크다. 에이전트는 네트워크를 스캔해 원자적 API를 발견하고, PTB로 즉석에서 조합하며, 결과가 결정적이고 감사를 통과할 것을 확신할 수 있다.
조정은 부서지기 쉬운 사후 고려가 아니라, 기계 속도로 믿고 의존할 수 있는 일급 능력이 된다.
이것이 새로운 빌딩 블록이다: 원자적 API의 객체 중심 세계, PTB로 오케스트레이션되고, 기본적으로 프로그래머블·검증 가능·확장 가능한 워크플로.
이제 질문은 “이게 실제로 작동할까?”에서 “모든 앱이 레고처럼 서로 딱 맞게 끼워질 때 무엇이 일어날까?”로 바뀐다.
원자적 API와 PTB가 생기는 순간 근본적인 변화가 일어난다: 더는 ‘앱’을 모놀리식으로 짓지 않고, 조합 가능한 파츠의 시스템으로 짓는다.
통합도, 의존성도 아니다. 백엔드를 갈아엎거나 아키텍처 옆구리에 새 API를 덕트 테이프로 붙이지 않고도, 끼워 넣고 재사용하고 교체하고 리믹스할 수 있는 모듈이다.
모든 접합부를 손코딩하는 것과, 조합이 예외가 아니라 기본값인 언어를 건네받는 것의 차이다.
여기서 Sui는 조용히 앱 개발의 모델을 뒤집는다.
모든 앱이 결제 플로, 권한 레이어, 알림 시스템, 사용자 레지스트리를 매번 재발명할 필요가 없다. 그 기능들은 주소 지정 가능하고, 호출 가능한 단위가 된다.
한 번 존재하면 재사용할 수 있다. 한 컨텍스트에서 동작하면, 다른 컨텍스트에서 조합할 수 있다.
남이 이미 구현한 것을 처음부터 만들 필요가 없다. 그들의 원자적 API를 호출해, 당신의 로직으로 PTB에 감싸면 끝이다.
그것만으로도 개발 주기는 분기에서 며칠로 압축된다. 더 중요하게는, 이전에는 너무 복잡하고, 너무 부서지기 쉬웠고, 너무 비싸서 조정할 수 없던 전혀 새로운 종류의 워크플로가 열린다.
이건 블록체인 얘기만이 아니다. 소프트웨어를 만드는 새로운 모델이다.
실행 환경을 신뢰할 수 있는 순간, 당신은 스택 전체를 소유할 필요가 없다. 중요한 부분만 조합하면 된다.
다음 도약은 이것이다:
그 시스템들이 더는 사람이 중앙에서 조작하지 않아도 된다면?
소프트웨어가 소프트웨어와 조정한다면? 정적으로가 아니라, 동적으로, 문맥적으로, 실시간으로?
충분히 멀리서 보면, 우리가 떠들어 대는 ‘AI 시대’에는 이상한 점이 있다.
모두가 모델을 만들고, 모두가 에이전트를 얘기한다. 하지만 우리가 직감적으로 기대하는 방식으로 ‘정말’ 작동하는 것은 아직 없다.
PDF를 요약하고, 시를 쓰고, 이메일을 초안하는 LLM이 있다. 코드를 자동 완성해 주거나 계약서를 쓰는 데 도움을 주는 코파일럿도 있다.
하지만 AI 에이전트에게 현실 세계에서 유용한 일을 시켜 보라. 항공권을 예약하고, 벤더에게 돈을 지불하고, 양식을 제출하고, 비즈니스 프로세스를 실행하라고 하면 거의 즉시 비틀거린다.
그게 충분히 ‘똑똑하지 않아서’가 아니다. 그 밑바닥의 인터넷이 그 무엇도 ‘하게’ 두지 않기 때문이다.
그 AI 에이전트가 갈 곳이 없다.
최고의 에이전트조차 똑같은 오래된 벽에 부딪힌다: 조합되지 않는 엔드포인트, 서로 언어가 다른 API, 다른 머신이 호출하도록 만들어지지 않은 서비스들.
그래서 우리는 래퍼를 만든다. 플러그인, 에이전트 프레임워크, 더 많은 스캐폴딩. 그런데도 흐르지 않는다. 바닥이 모래인데 로봇에게 달리기를 가르치는 꼴이다.
하지만 Sui 같은 조정 레이어가 있으면, 그 바닥은 콘크리트가 된다.
에이전트는 더 이상 HTTP 요청을 억지로 이어 붙여 워크플로를 ‘흉내’ 낼 필요가 없다. 실제로 조정하고, 서비스를 발견하고, 그것과 조합하고, 하나의 결정적이고 감사를 통과할 수 있는 라운드트립 안에서 실제 로직을 실행할 수 있다.
인터넷은 인간만이 아니라 에이전트도 주소 지정할 수 있게 된다. 모든 함수가 호출 가능하고 조합 가능한 ‘능력’이 된다.
그리고 소프트웨어의 역할은 UI와 백엔드의 폐쇄 고리에서, 런타임에 생각할 수 있는 시스템이 엮어 내는 ‘열린 로직 네트워크’로 바뀐다.
이게 모든 것을 바꾼다.
미디어를 재생할 수 없습니다.
에이전트가 마찰 없이 조정할 수 있게 되면, 소프트웨어 스택 전체가 달라 보이기 시작한다.
백엔드, 스케줄러, 커스텀 통합이 필요했던 애플리케이션에서, 우리가 ‘인프라’라고 불렀던 대부분이 네트워크 위에 네이티브로, 내장되어 존재하는 세계로 이동한다.
누구든, 무엇이든 사용할 수 있도록.
그 세계에서 개발자는 빌더라기보다 지휘자에 가깝다. 매번 오케스트라를 다시 만들지 않는다. 새로운 편곡을 ‘작곡’할 뿐이다.
그리고 우리는 여기서 이 변화를 완성한다!
우리는 한 바퀴 돌아왔다. 30년 전 웹은 문서를 연결했다. 오늘 우리는 마침내 ‘로직’을 연결할 준비가 되었다.
지금까지 살펴본 원자적 API, PTB, 객체 중심 데이터, 에이전트 수준의 조합성은 하나의 깨달음으로 모인다.
Sui는 개발자 도구 상자의 또 하나의 도구가 아니다. 인터넷의 DNA를 다시 쓰는 것이다.
엔드포인트와 베스트에포트 호출의 세계를, 코드·가치·정체성이 하나의 원자적으로 검증 가능한 단위로 함께 이동하는 ‘직물’로 대체한다.
그 말은 다음 킬러 앱은 ‘앱’이 아니라는 뜻이다. 전 세계의 재사용 가능한 서비스 풀에서 능력을 끌어와 실시간으로 땋아 올리는 ‘컴포지션’이다.
그렇다면 우리는 어디에 와 있는가?
엔드포인트의 누더기가 아니라, 전 지구적 연산을 위한 살아 있는 운영체제에 가까운 인터넷의 문턱에 서 있다.
당신이 빌더라면, 무언가 새로운 것을 가장 빠르게 선적하는 길은 더 이상 스택을 재발명하는 것이 아니다. 네트워크에 ‘능력’을 릴리스하고 다른 이들이 그것을 자신의 플로에 끼워 넣게 두는 것이다.
당신이 자본 배분자이거나 전략가라면, 혁신의 표면적이 폭발적으로 넓어졌다는 뜻이다. 조정 비용이 거의 0에 수렴했기 때문이다.
그리고 그저 기술의 향방을 걱정하는 사람이라면, 이제 기본적으로 개방적이고, 설계상 지능적이며, 모든 레이어에서 조합 가능한 인터넷으로 가는 길이 생겼다는 뜻이다.
그게 엔드게임이다. 더 빠른 사일로가 아니라, 데이터·가치·정체성이 함께 마찰 없이 이동하는 ‘글로벌 조정 레이어’.
기초는 이미 부어졌다. 이제 우리 몫은 스카이라인을 올리는 것이다.
다음 글을 놓치지 마세요!
여기에서 제 Substack을 구독해 업데이트를 받아보세요:
면책 조항: 여기서 표현된 견해는 제 개인적인 의견이며, Mysten Labs 또는 Sui Foundation의 입장을 반드시 대변하지는 않습니다. 이 글은 정보 제공만을 위한 것입니다.
