김루이(金磊), 선전 발
양자위(量子位) | 위챗 공식계정 QbitAI
두려움은 아주 나쁜 의사결정 방식입니다.
AI 전환의 기회 창을 놓칠까 걱정하는 기업들에 대해 아마존 CTO Werner Vogels은(는), 다급해할수록 먼저 분명히 해야 한다고 강조했습니다. 즉, 기업이 해결하려는 것이 무엇인지, 그리고 AI가 어떤 도움을 줄 수 있는지를 말입니다.
요즘은 매주 새로운 모델이 쏟아져 나와 사람들은 볼수록 더 불안해하며, 한 발 늦으면 계속 늦을까 봐 조바심을 냅니다. 효율을 높이고 혁신을 이루고자 하는 마음은 하루가 다르게 절실해지지만, 정작 기술이 무엇을 할 수 있는지는 차마 살펴볼 겨를이 없습니다.
선전에서의 한 차례 교류에서 그는, 기업이 지금 당장 AI를 사용하지 않는다고 해서 곧바로 문을 닫는 것은 아니라고 말했습니다. 따라서 결정을 내리기 전에 기업은 먼저 엔지니어와 경영진이 충분히 학습하여 기술의 능력을 파악해야 합니다.
그러나 이 말이 Werner의 입에서 나왔다는 점에는 어느 정도 반전이 있습니다.
20년 넘게 아마존 CTO를 맡아온 이 기술계 베테랑은 원래 '불가능'이라는 말을 받아들이길 거부하는 인물이니까요. 클라우드 컴퓨팅의 이면에 담긴 이야기를 들려줄 때도, 컴퓨터 선구자 Grace Hopper의 명언을 인용하며 개발자들에게 '우리는 늘 이렇게 해왔다'는 말을 경계하라고 당부했습니다.
엔지니어들에게 끊임없이 관례를 깨라고 독려하던 사람이 왜 AI 앞에서는 모두에게 조금만 쉬어가라고 할까요?
그가 이야기한 한 차례의 데이터베이스 장애가, 이런 겉보기에 모순적인 태도를 설명해줄지도 모릅니다.
데이터베이스가 겪었던 시행착오를 AI가 또 한 번 겪어야 할까?
2004년 12월 12일, 아마존은 크리스마스 쇼핑 시즌의 중요한 시점에 있었습니다. 당시 25달러 이상 구매하면 무료 배송 혜택이 있었지만, 배송에는 시간이 걸리기에 하루라도 늦게 주문하면 택배가 크리스마스까지 도착하지 못할 수 있었습니다.
바로 이날, 고객 데이터베이스의 공유 디스크에 장애가 발생해 사용자들은 로그인도, 주문도 할 수 없었습니다. Werner의 회상에 따르면 이번 장애는12시간 넘게지속되었고, 아마존에수백만 달러의 손실을 안겼습니다。
이후 데이터베이스 공급업체가 찾아왔을 때, Werner는 상대가 정중히 사과할 것이라 생각했지만 들은 말은 '여러분이 테스트를 잘 해뒀어야죠'였습니다.
제품에 문제가 생겼는데 어찌 고객을 탓하는 것인가?
Werner은 물론 화가 났지만, 나중에 그는 아마존의 규모가 이미 이 상용 소프트웨어의 설계 범위를 훨씬 초과했다는 것도 깨달았습니다. 공급업체와 계속 다퉌봤자 다음 번 장애는 해결되지 않았을 것입니다.
그래서 팀은 좀 더 근본적인 문제를 조사하기 시작했습니다.아마존은 과연 데이터베이스를 어떻게 사용하고 있을까?
조사 결과, 관계형 데이터베이스 사용 사례의 약 70%는 키-값 접근만 필요로 하는 것으로 나타났습니다.
장바구니를 예로 들면, 시스템은 보통 사용자 식별자에 따라 해당하는 장바구니를 가져오기만 하면 됩니다. 아마존은 모든 사용자의 장바구니를 불러와 복잡한 쿼리를 수행할 필요가 없습니다.
수요가 이러하다면, 팀은 다른 구현 방식으로 바꿀 수 없을까? 실제 접근 방식을 따라 생각하며, 그들은 키-값 저장 시스템Dynamo을 구축했는데, 이것이 바로 DynamoDB의 전신입니다.
이 경험을 오늘날에 비추어 보면, 심상치 않은 데자뷔가 느껴집니다. 당시 사람들이 관계형 데이터베이스라는 큰 망치로 갖가지 데이터 문제를 처리했다면, 오늘날 대형 모델 역시 그 편리한 망치가 되기 쉽습니다.
기업의 AI 도입에 대해 이야기할 때, Werner가 반복해서 던지는 질문도 이와 비슷한 것들이다.기업이 정확히 무엇을 해결하려 하는지, AI가 적합한지, 그리고 현재 세대의 AI가 적합한지?
그는 이미지 인식, 음성 처리, 예측 등의 분야에는 오래전부터 수많은 효과적인 방법이 축적되어 왔다고 일깨운다. 기업은 기술을 선택하기 전에 먼저 과제 자체를 살펴봐야 한다. 대규모 모델을 쓴다 해도 꼭 리더보드 1위를 좇을 필요는 없다.
Werner는 벤치마크 테스트에 일정한 유보적인 입장을 갖고 있는데, 인위적으로 만들어진 테스트와 실제 비즈니스 사이에는 여전히 간격이 있기 때문이다. 어떤 모델이 이미 과제를 수행하기에 충분하다면, 기업이 더 높은 순위를 위해 계속 돈을 지불할지는 이익을 다시 저울질해야 한다.
게다가 Werner는 이 장부를이미 20년 넘게 계산해 왔다.。
대화의 주제가 클라우드 컴퓨팅이 가져온 근본적인 변화로 옮겨가자, 그는 경제 모델의 변화를 특히 중요하게 여긴다.
과거에는 기업용 소프트웨어를 살 때 기업이 흔히 5년, 10년짜리 계약을 먼저 체결해야 했다. 경영자는 내년의 수요조차 예측하기 어려운데도 돈을 먼저 지불해야 했다. Werner는 이것이 마치 손님이 식당에 들어와 1,000달러를 먼저 내려놓고 다 먹지 못해도 환불받지 못하는 것과 같다고 생각한다.
클라우드 컴퓨팅은 자원 사용량과 비용을 연결함으로써 '축소(scale down)'에도 실질적인 의미를 부여했다. 밤에는 사용자가那么多지 않다면, 기업은 필요 없는 자원을 꺼버릴 수 있다. 비용이 마침내 아키텍처 논의에 들어올 수 있게 되었고, 사업 부서도 어떤 기능이 대체로 얼마나 돈을 들일 가치가 있는지 답해야 한다.
AI 시대에 이르자, 이 장부에는 새로운 항목이 생겼다.
예를 들어 양자위(量子位)에서 물어보면,“에이전트는 왜 망각조차 중요한 공학 문제가 되었는가?”라고 물었을 때, Werner는 에이전트가 작업을 시작할 때마다 자신이 아는 모든 것을 훑어야 한다면 시스템 오버헤드가 커지게 된다고 솔직히 말했다. 개발자는 작업에 정말로 중요한 내용만 남기도록 만들 방법을 찾아야 한다.
그는 또한 일부 코딩 도구는 재시작할 때 프로젝트 내용을 다시 불러온다고 언급했다. 사용자는 어제 이러한 준비 작업에 이미 비용을 지불했는데, 오늘 또다시 같은 비용을 지불해야 한다. Kiro의 세션 간 메모리는 바로 이런 반복 작업을 줄이려는 것이다.
따라서 모델이 얼마나 똑똑한지 외에도, 개발자는 하나의 작업을 완료하기 위해 모델이 얼마나 많은 쓸데없는 반복 작업을 했는지 따져봐야 한다.
이것은 Werner가 더 작은 모델과 DeepSeek, 통의천문(Qwen), Kimi 등 오픈 웨이트 모델을 기꺼이 이야기하는 이유도 설명해 준다. 그의 관찰에 따르면, 일부 고객은 지속적인 실험을 통해 더 작은 모델로도 수요를 충족할 수 있고 사용 비용도 훨씬 낮다는 것을 발견했다.
무엇을 쓰고, 어떻게 쓰고, 얼마를 쓸 것인가. 이 오랜 질문들은 기업이 AI 앞에서도 여전히 피할 수 없는 과제다.
Agent가 저지른 실수의 책임은 누가 짊어지는가?
기업이 비용을 계산했다 하더라도, 개발 팀을 기다리는 또 다른 문제가 있다.
챗봇은 한 단락의 텍스트를 제시하며, 사람은 그것을 읽고 어떻게 할지 결정할 수 있다. Agent는 대신 사용자를 대표해 행동을 취한다. 일정을 바꾸고, 도구를 호출하고, 프로그램을 실행한다. 모델이 한 번 잘못된 답을 주면, 오류는 실행 과정을 따라 실제 결과로 이어질 수 있다.
Werner는 대화 과정에서 Agent가 기차표 변경을 도와주는 것은 기꺼이 허용하겠지만, 명확한 요구 조건도 있다고 말했다. 시스템은 조작 방법을 알고 그의 선호를 기억해야 하며, 동시에 제약을 받아야 한다.
그리고 이런 경계에 대한 집착은 그가 말한Nitro이야기에서 이미 언급된 바 있다.
초기 클라우드 컴퓨팅은 가상화에 의존해 한 대의 물리 서버를 여러 사용자에게 나누어 주었다. 그러나 가상 머신을 관리하고 네트워크와 스토리지 접근을 처리하는 소프트웨어 자체도 자원을 소비했다. 가상 머신이 많아질수록 관리 계층은 병목이 될 수 있었다.
AWS는 이후 Nitro를 구축해 다수의 네트워크, 스토리지 기능을 전용 하드웨어로 오프로드하고, 기존의 완전한 Linux 관리 환경인 dom0를 제거했다. 팀은 성능 병목을 완화했고, 그와 동시에 공격 표면의 상당 부분도 축소했다.
Nitro에는 ‘수동 통신(passive communication)’이라는 흥미로운 설계도 있다. Werner의 소개에 따르면, 하이퍼바이저는 Nitro 컨트롤러가 명령을 내려주기를 기다린다. 만약 하이퍼바이저가 거꾸로 컨트롤러에 능동적으로 연락한다면, 정상 흐름에서 있을 수 없는 행동이므로 플랫폼은 이를 근거로 해당 시스템을 서비스에서 제외하고 조사를 시작할 수 있다.
이 사고방식을 따라가면, Agent에 대한 Werner의 요구 사항을 쉽게 이해할 수 있다. 사용자가 시스템에게 무엇을 허용하는지는 반드시 사전에 명확히 해야 한다. 그는 간단한 예를 들었다. 사용자는 Agent가 하루에 100달러 이상 지출하지 못하도록 규정할 수 있으며, 초과하는 경우에는 사람이 의사 결정에 참여해야 한다.
그의 소개에 따르면, 아마존은 Agent를 위한 규칙 집행 메커니즘을 설계해, Agent의 도구 접근, 스크립트 실행 등의 작업을 검사함으로써 고객이 명시적으로 승인한 범위 안에서 행동하도록 제한한다.
사용자의 승인은 자율적 행동에 구체적인 범위를 그어 준다. 모델이 어떤 일을 할 가치가 있다고 판단하더라도, 실행 시스템은 여전히 그것을 할 권한이 있는지 검사해야 한다.
하지만 이런 제약이 Agent의 효율을 떨어뜨리지는 않을까? 이 질문 앞에서 Werner가 먼저 이야기한 것은책임。
이었다. “너가 만들었으면, 너가 책임진다.(You build it, you own it.)”
그의 견해로는, Agent의 개발자는 반드시 그것을 통제할 수 있어야 한다. 시스템이 어떤 행동을 취했는지, 경계를 벗어났는지에 대해 최종적으로 여전히 사람이 책임져야 한다.
Werner는 AI에 대한 신뢰를 분산 시스템의 경험으로 되돌려 놓았다. 엔지니어들은 어떤 구성 요소도 영원히 신뢰할 수 있다고 가정하지 않기 때문에, 복제, 격리와 각종 신뢰성 메커니즘이 필요하다. 팀이 개별 구성 요소에 대해 경계심을 유지해야만 전체 시스템에 대한 신뢰를 구축할 수 있다.
다만 엔지니어들이 이러한 보호 메커니즘을 고객이 부담할 수 있고 작업을 뚜렷이 느리게 하지 않는 서비스로 만들려면, 상당한 타협을 거쳐야 한다. Lambda도 비슷한 난제를 겪은 적이 있다.
초창기 WeTransfer는 S3에 업로드된 파일을 처리하기 위해 일괄 컴퓨팅 인스턴스를 계속 가동하며 새 파일의 도착을 기다려야 했다. 고객은 이벤트 발생을 기다리기 위해서만으로도 인프라 세트 전체를 유지해야 했다.
AWS는 이런 작업을 넘겨받아, 고객이 코드를 제출하고 실행 시간과 메모리 사용량에 따라 비용을 지불하도록 하고자 했다. 팀은 과금 방식은 분명히 정했지만, 하위 계층을 어떻게 효율적으로 구현할 것인가는 여전히 난제였다.
서로 다른 고객을 격리하기 위해 초기 Lambda가 사용한 가상 머신은 함수 작업에 비해 여전히 너무 컸고 비용도 높았다. 이후 팀은 Firecracker를 통해 격리 단위를 더 가벼운 마이크로 가상 머신으로 만들어서야 자원 활용률을 높였다.
격리 문제가 해결된 후, 팀은 콜드 스타트도 처리해야 했다. 함수가 실제로 실행되기 전에 시스템은 실행 환경, 코드, 의존성을 준비해야 한다. SnapStart는 이미 초기화된 환경의 스냅샷을 저장함으로써 이 부분의 준비 오버헤드를 줄이고 시작 성능을 개선했다.
고객에게 보이는 것은 한 번의 함수 호출일 수 있다. 그러나 엔지니어링 팀은 그 이면에서 격리, 자원 할당, 시작, 네트워크 메커니즘을 지속적으로 다듬어야 한다.
Werner는 이러한 작업을 다음과 같이 불렀다."보이지 않는 엔지니어링 혁신"(Invisible Engineering)。
Agent가 실제 업무에 투입되려면, 개발 팀 역시 이런 세밀한 작업들이 빠질 수 없다. 데모가 정상 작동한 후에도 팀은 권한을 어떻게 제한할지, 예외를 어떻게 처리할지, 그리고 사용자가 어느 범위까지의 작업을 맡길 의향이 있는지 계속 명확히 해야 한다.
경험에는 압축 알고리즘이 없다
Agent가 코드를 작성하기 시작하면, 앞서 언급한 이러한 문제들이 다시 개발 팀 자신에게 돌아온다.
초급 엔지니어의 취업에 관한 이야기가 나오자, Werner는 아마존이 초급 엔지니어를 뽑는 규모는 과거와 같다고 답했다. 이어서 그는 신입이 팀에 들어온 후의 학습으로 화제를 돌렸다.
갓 졸업한 사람이 S3 팀에 합류하면 마주하게 되는 것은 20년 전의 코드일 수 있다. 학교에서는 그러한 시스템을 어떻게 이해하고, 그것을 유지보수하는 사람들과 어떻게 협업하는지를 미리 가르치기 어렵다.
그래서 Werner는 호기심, 학습 능력, 오픈소스 프로젝트 경험을 중시한다. 신입이 오픈소스 협업에 참여한 적이 있다는 것은, 그의 코드가 다른 사람들의 검토를 거쳤고, 다른 사람들과 함께 문제를 해결해야 했다는 것을 의미한다.
AI는 신입에게 팀 규칙을 설명해 주어, 시니어 엔지니어가 반복해서 설명하는 데 쓰는 시간을 줄일 수 있다. Werner가 Kiro를 소개하면서 강조한 것도 명세 기반 스펙 주도였다. 개발자가 먼저 요구사항, 아키텍처, 개발 규칙을 명확히 정리한 뒤, 시스템이 작업을 진행하도록 하는 방식이다.
다만 AI가 코드를 생성하는 속도는 빨라졌지만, 팀이 이 코드를 이해하고 검토하는 속도가 이를 따라갈 수 있을지는 미지수다.
Werner는 개발 팀이 주목할 만한 개념 하나를 언급했는데, 바로 검증 부채(validation debt)다.
과거에는 진행 일정을 맞추기 위해 개발자가 지름길을 택하고, 나중에 수정하기로 메모해 두면서 쌓인 것이 기술 부채였다. 지금은 AI가 생성한 코드 중 아직 검증되지 않은 부분이 있어, 팀은 또 다른 부채를 남기게 된다.
인터페이스 요소가 몇 밀리미터 어긋난 것과, 고객 정보를 유출할 가능성이 있는 코드는 그 결과가 크게 다르다. 개발 팀은 위험도에 따라 검사를 배치하고, 가장 검증이 필요한 곳에 역량을 투입해야 한다.
Werner의 생각을 따라가 보면, 팀이 코드 생산량을 늘리는 것은 쉽지만, 그 코드를 이해하고 그로 인한 결과를 감당할 수 있는지는 별도로 따져야 한다. 그렇지 않으면 개발자가 오늘 절약한 시간은 이후 문제 추적과 재작업에서 다시 쓰이게 될 수 있다.
이것이 Werner가 주니어 엔지니어에게 코드를 읽게 하고, 시니어 엔지니어와 함께 검토하고 토론하도록 고집하는 이유이기도 하다. 도구는 지식을 설명할 수 있지만, 구체적인 문제 앞에서 사람에게 필요한 판단력은 여전히 조금씩 쌓아야 한다.
경험에는 압축 알고리즘이 없다.(There is no compression algorithm for experience.)
개발자의 불안에 대한 답으로 Werner의 이 말은 꽤나 적절하다.
다만 중국 방문 이야기를 하면서, 그는 AI 응용에 대해 더 낙관적으로 만들어 준 사례 하나를 들었다. 그는 '大米和小米(대미화소미)'를 방문한 경험을 소개하는 데 적지 않은 시간을 썼다.
이 기관은 자폐증, 주의결핍 과잉행동장애 등 발달 지원이 필요한 아동에게 개입 서비스를 제공한다. Werner의 소개에 따르면, 기관은 AI를 활용해 교육 기록을 분석하고 아이들의 진전 상황을 관찰하며, 재활 치료사에게 방안 제안을 제공한다. 재활 치료사는 전문적 판단을 결합해 어떤 제안을 채택할지 결정한다.
그에게 인상 깊었던 점은 AI가 전문 인력의 사무적 업무를 줄여, 아이와 가족에게 더 많은 역량을 쏟을 수 있게 했다는 것이다.
이야기가 여기에 이르자, Werner의 낙관에는 구체적인 대상이 생겼다. 기술은 누구의 부담을 덜어 줄 수 있고, 원래 지원을 받기 어려웠던 누구를 도울 수 있을까? 이러한 구체적인 응용에서 그는 AI의 가치를 보았다.
다시 '일단 일시정지 버튼을 누르자'는 말로 돌아가 보면, 기업이 멈춰서 생각해야 할 일들이 구체화된다. 과업을 AI에게 맡겨도 되는지, 비용을 감당할 수 있는지, 행동 범위를 어떻게 규정할지, 결과를 누가 검증할지, 개발 팀은 항목마다 하나하나 답해야 한다.
Werner는 개발자의 가장 뛰어난 작업은 다른 사람의 눈에 보이지 않는 곳에 숨어 있는 경우가 많다고 말했다.
AI가 사람 대신 한 단락의 코드를 더 작성했다 하더라도, 엔지니어는 그 코드가 배포된 후 무슨 일이 일어날지 여전히 알아야 한다.