스크립트
00:00:00Better Stack 팟캐스트에 오신 것을 환영합니다. 여기서는 소프트웨어 개발,
00:00:04AI, 그리고 온갖 새로운 기술에 대해 이야기합니다. 저는 진행자인 Andrus이고, 오늘 두 분을 모셨습니다.
00:00:10James와 Alex입니다. Alex, 쇼에 오신 것을 환영합니다. 초대해 주셔서 감사합니다. 그럼 먼저
00:00:16운영 중인 회사에 대해 이야기해 보죠. Hookdeck이라고 하죠. 익숙하지 않은 분들을 위해
00:00:22Hookdeck이 무엇인지, 무슨 일을 하는지 더 자세히 알려주세요. 네, 저는 Hookdeck을
00:00:27웹훅을 죽이려는 웹훅 회사라고 생각합니다. 그건 아마 우리가 이야기해 볼 수 있는 주제겠죠.
00:00:32우리는 크게 두 가지 핵심 제품을 만듭니다. 하나는 이벤트 게이트웨이(Event Gateway)입니다. 이벤트 게이트웨이는
00:00:37인프라 외부에서 들어오는 모든 이벤트를 위한 일종의 특수 이벤트 버스 역할을 합니다.
00:00:41웹훅이 가장 대표적이지만, IoT나 SDK 기반 유스케이스 등도 많이 접하고 있습니다.
00:00:47기본적으로 신뢰할 수 없는 엔드포인트를 제공하는 셈이죠. 어떤 이벤트든 보낼 수 있습니다.
00:00:51그리고 그런 이벤트를 관리할 수 있는 모든 기능을 제공합니다. 필터링부터 시작해서
00:00:55변환, 라우팅, 대기열, 알림, 이슈 관리, 재전송까지 모든 것을 아우릅니다.
00:01:01그러니까 제가 함께 일하는 모든 공급업체로부터 이벤트와 웹훅을 수신해야 한다는 의미에서
00:01:05상호 운용성을 보장하는 것이죠. 예를 들면 Stripe, Shopify, Twilio,
00:01:10WhatsApp, TikTok 등 뭐든 말이죠. 각자 나름의 기준과 특이점,
00:01:16그리고 구체적인 요구 사항이 있습니다. 우리는 그걸 표준화해서
00:01:20단일 계약으로 가져올 수 있습니다. 그리고 대기열 측면에서의 모든 것이죠. 예를 들어
00:01:27Shopify 스토어에서 플래시 세일이 열리면 정말 엄청나게
00:01:31많은 이벤트가 쏟아져 들어옵니다. 그 트래픽을 정규화해서 이벤트 게이트웨이에서 처리량을
00:01:38조절할 수 있는 것이죠. 그게 큰 부분을 차지합니다. 소비자 측면의 이야기죠. 그리고
00:01:42거기서부터 Hookdeck 이야기가 시작됐습니다. 최근에는 Outpost도 출시했습니다. Outpost는 완전히
00:01:49오픈 소스인 아파치 2.0 프로젝트입니다. 이제는 관리형 서비스도 제공하고 있습니다. 이벤트를
00:01:55전송하기 위한 것이죠. 그러니까 방정식의 반대편인 셈입니다. 게시자나 플랫폼, 개발자 도구로서
00:01:59이제는 누구나 이벤트를 보내고 있죠. 매일 놀라울 따름입니다. 그래서 Outpost는 관리형 서비스나
00:02:05직접 호스팅하는 서비스로 사용할 수 있습니다. 테넌트가 누구인지, 목적지는 어디인지, 등록된 엔드포인트는 무엇인지,
00:02:12토픽을 설정하고 이벤트를 게시할 수 있습니다. 가시성, 지표, 전송
00:02:17보장, 재시도, 그리고 서명이나 서명 교체와 같은 일반적인 사항까지 모두 처리합니다.
00:02:23웹훅을 죽이려고 한다는 농담은 Outpost가
00:02:28웹훅 전송뿐만 아니라 사용자의 메시지 버스로 이벤트를 직접 게시할 수 있게 해주기 때문입니다.
00:02:35Outpost는 기본적으로 이벤트 대상을 지원합니다. 그래서 웹훅은
00:02:39전송 라우터로 간주됩니다. 기본적으로 웹훅을 통해 이벤트를 전송하고
00:02:46웹훅이 표준 전송 메커니즘인 것이죠. RabbitMQ나 Kafka 같은 MQ처럼
00:02:53새로운 전송 프로토콜을 선택할 수도 있습니다. Pub/Sub,
00:02:59SQS, AWS EventBridge 등 일반적인 대상은 물론, Hookdeck 이벤트 게이트웨이로도
00:03:05SQS, AWS EventBridge, 그리고 당연히 YokeDeck Event Gateway까지 지원하죠. 그러니까 저는 이걸 일종의
00:03:12이 아이디어의 시작이 웹훅이 싫어서였는지, 아니면 관리하기가 너무 힘들어서였는지
00:03:18궁금합니다. 아이디어가 어떻게 나왔는지 말씀해 주시죠. 네, 사실 얼마 전에도 다른 사람에게 이야기했는데요.
00:03:25한 5년 전쯤에 Medium에 글을 하나 썼습니다. 이제 거의 6년이 다 되어가네요.
00:03:31글 제목이 방금 하신 말씀과 연결되는데요, “웹훅은 최악이다, 하지만 뭔가 방법은 있다”였죠.
00:03:37지하실에서 이것저것 만져보며 Hookdeck의 V1 프로토타입을 만들 때였습니다.
00:03:42하지만 그건 순전히 좌절감에서 시작되었습니다. 저는 당시 이커머스 쪽에서 일하고 있었는데,
00:03:48구독 관리부터 창고, 물류 관리까지 파워를 실어줄 커스텀 소프트웨어를 정말 많이 만들었거든요.
00:03:54그런데 문제의 대부분이 웹훅으로 귀결되더라고요. 농담처럼 들릴 수도 있는데,
00:03:59한쪽에서는 여성 패션 비즈니스를 판매하려고 하고 있는데, 다른 한쪽에서는
00:04:05대체 웹훅이 어디 갔냐며 쩔쩔매고 있으니 말이죠. 관심사가 너무 안 맞는 것 같았어요.
00:04:10그래서 순전히 웹훅 소비자로서의 좌절감에서 시작된 거였습니다. 이 문제를
00:04:15해결할 수 있는 제대로 된 방법이 없다는 것에 대한 좌절감이었죠.
00:04:18온라인에서 추천을 찾아봐도 웹훅은 새로운 게 아니잖아요. 결국 HTTP 요청이니까요.
00:04:23대처 방법은 이미 정립된 패턴이 있고요. 하지만 금방 복잡해지죠.
00:04:28자동 확장이 가능한 수신 컨슈머가 필요하고, SQS 같은 대기열에 담아야 하고,
00:04:33SQS에서 메시지를 가져올 컨슈머 세트도 배포해야 하죠. 만약 문제가 생기면 데드레터 큐에 쌓이고,
00:04:38왜 문제가 생겼는지 이해하고 복구할 스크립트가 필요합니다. 모든 게 다 고민거리죠.
00:04:43복잡성이 커지면 수신했던 과거 이벤트를 재전송할 수 있어야 하고,
00:04:46웹훅 페이로드가 정확히 무엇인지 볼 수 있어야 합니다. 게다가 공급업체마다
00:04:50Stripe는 UI를 주는데 Intercom은 안 줄 수도 있고, 제각각 다루기 힘든 특이점이 있죠.
00:04:55거기서 이런 솔루션이 왜 없을까 하는 생각이 들었습니다. 처음엔 관측성(Observability) 측면에서 봤는데
00:05:00잘 안 되더군요. 제가 놓친 부분은 관측성은 단지 일부라는 것이었습니다. 저는 웹훅을
00:05:05이벤트 기반 아키텍처로 가는 관문 마약이라고 부릅니다.
00:05:09웹훅 대신 이벤트라는 용어를 고집하는 이유도, 모든 웹훅 뒤에는 이벤트가 있고,
00:05:14웹훅과 함께 패키지로 제공되는 이벤트 기반 아키텍처 패러다임이 있기 때문입니다.
00:05:18중요한 유스케이스나 대규모 서비스에서 웹훅을 수신할 때마다,
00:05:22멱등성, 순서 보장, 전송 보장 등을 고려해야 하죠.
00:05:26비동기 이벤트 기반 프로그래밍 패러다임을 다룰 때 겪게 되는 모든 도전 과제들입니다.
00:05:31결국 우리가 만든 것은 완전한 기능을 갖춘 대기열 시스템이었습니다.
00:05:35상호 운용성을 확보하고 이벤트 자체를 처리하는 것이 핵심이었죠.
00:05:41하지만 그 뒤에 따르는 모든 의미론적 고민들은 pub/sub 시스템을 다루는 것과 비슷합니다.
00:05:47우리는 대기열을 다시 발명하려던 게 아니었는데, 꽤 흥미로운 아이디어들을 우연히 찾게 되었습니다.
00:05:51지금 목격하고 있는 현상은 사람들이 스택에서 pub/sub이나 SQS를 걷어내고
00:05:56Hookdeck으로 옮겨오고 있다는 겁니다. 저는 그게 좀 의아합니다. VPC는 우리가 운영하지 않으니까요.
00:06:01로드맵에 포함될지는 모르겠지만, 사람들은 이벤트 기반 아키텍처의 의미론에 익숙해졌고
00:06:07아무도 의문을 가지지 않죠. 왜 우리는 다시 데드레터 큐를 만들고 있죠?
00:06:14데드레터 큐가 대기열 오류를 처리하는 편리한 방식이라고 생각하는 사람이 있을까요?
00:06:19어쨌든 이 부분에 대해 몇 가지 강한 의견이 있습니다. 여러분이 pub/sub이나
00:06:25이벤트 기반 아키텍처에 얼마나 진심인지 모르겠네요. 너무 깊게 들어가고 싶지는 않습니다.
00:06:29네, 저도 데드레터 큐 같은 건 잘 모릅니다. 오늘 처음 듣는 얘기도 있네요.
00:06:33저도 아주 잘 아는 건 아니지만, 웹훅을 좀 다뤄보면서 언급하신 문제들을 겪어봤습니다.
00:06:38웹훅이 이벤트 기반 아키텍처로 가는 관문이라는 말에 공감합니다.
00:06:43저 같은 배경을 가진 개발자라면 아마 처음으로 웹훅을 접하면서
00:06:48“잠깐, 이게 비동기라고? 어떻게 처리하지?”라는 고민을 하게 될 겁니다.
00:06:53전형적인 빙산의 일각이죠. 눈에 보이는 HTTP 요청 뒤에는
00:06:57수면 아래에 훨씬 더 큰 빙산이 숨어 있는 거니까요.
00:07:05제가 하려는 것은 이 분야에서 아직 달성하지 못한 수준의 개발자 경험(DX)을 제공해서,
00:07:09남은 빙산을 직접 파헤치지 않아도 되게 하는 것입니다.
00:07:13물론 불가피한 것들도 있습니다. 잘못 전달하고 싶지는 않네요.
00:07:19이런 문제들을 다루기 시작하면 멱등성이나
00:07:25순서 보장에 대해 잘 이해하고 있어야 합니다. 모든 문제를 마법처럼
00:07:29해결할 수는 없죠. 결국 이벤트를 다루는 거니까요.
00:07:35하지만 문제 공간과 관련된 근본적인 복잡성보다, 도구가 제대로
00:07:40설계되지 않아서 발생하는 복잡함이 더 큽니다. 현재 우리는 두 부류의 고객을
00:07:48지원하고 있습니다. 하나는 문제의 깊이를 정말 잘 아는 고객들이라,
00:07:53현재의 Kafka 설정에 맞춰 솔루션 엔지니어링을 할 수 있는 사람들이죠.
00:07:57우리가 새로운 의미론적 접근을 제시하면 아주 좋아합니다.
00:08:01그게 첫 번째 카테고리이고, 또 다른 카테고리는...
00:08:06아마 처음으로 '어, 이거 비동기네? 이걸 어떻게 다루지?'라고 접하게 되는 계기일 거예요.
00:08:12그 과정에서 배우는 곡선이 존재하죠. 마치 전형적인 빙산 같아서,
00:08:17겉으로 보이는 HTTP 요청뿐만 아니라,
00:08:21물밑에 가려진 나머지 빙산 부분이 존재하니까요. 그래서 제가 노력하는 건,
00:08:26이 분야에서 그동안 달성하지 못했던 수준의 개발자 경험(DX)을 제공해서,
00:08:32나머지 빙산까지 다 파악할 필요 없게 만드는 겁니다. 물론 피할 수 없는 부분들도 있죠.
00:08:37잘못 전달하고 싶지는 않아요. 일단 그런 종류의 문제들을 다루기 시작하면,
00:08:40멱등성(idempotency)에 대해 확실히 이해하고 있어야 하고,
00:08:45순서 보장에 대해 잘 이해하고 있어야 하거든요. 그러니
00:08:49모든 문제를 해결할 수 있다는 건 아니에요. 결국 여전히 이벤트들을
00:08:53처리하고 있는 거니까요. 하지만 많은 의미론적 복잡성은
00:08:58해당 문제 공간의 본질적인 복잡성보다는 도구가 충분히 고민되지 않은 탓이 더 크다고 생각합니다.
00:09:05그래서 현재 우리는 크게 두 종류의 고객을 만족시키고 있어요.
00:09:13문제를 깊이 있게 잘 알고 있어서
00:09:18기존 Kafka 설정 등을 중심으로 직접 솔루션을 엔지니어링하는 고객들이죠.
00:09:23그런 분들에게 새로운 의미론을 제안하면 정말 열광하시더라고요. 그게 한 부류고요.
00:09:28다른 부류는 이런 걸 배우고 싶어 하지 않는 분들이에요.
00:09:31이런 복잡한 건 피하고 싶어 하죠. 기본적으로 전 이런 문제를
00:09:36우회하고 싶어 합니다. 그래서 저희는 이런 두 가지 유형의 고객들을 주로 봅니다.
00:09:41개발자들이 쉽게 시작할 수 있도록 이 도구 Outpost를 오픈 소스로 공개한 것도 그런 이유인가요?
00:09:47어느 정도는요. 또 다른 이유는 우리는 Outposts로
00:09:53돈을 벌 필요가 없거든요. 그냥 오픈 소스로 푸는 게 낫겠다 싶었죠. 네, 그냥,
00:10:01저희 유튜브 시청자분들이 새로운 오픈 소스 도구에 대해 아는 걸 정말 좋아하신다는 걸 알거든요. 그래서
00:10:07그 부분에 대해서도 질문드려 본 거고요. 그런데, 먼저 저는,
00:10:13초창기에 오픈 소스 중심의 접근 방식을 조금 더 취하지 못했던 게 후회되기도 해요.
00:10:18오픈 소스를 염두에 두고 소프트웨어를 만드는 것과
00:10:21폐쇄형으로 만드는 것은 구축 방식이 완전히 다르거든요. 하지만
00:10:26오픈 소스 결정과 관련해, 요즘 벤처 투자를 받는
00:10:30스타트업들을 보면 이른바 '가짜 오픈 소스'가 많다는 걸 볼 수 있죠.
00:10:34오픈 소스이긴 한데 오픈 코어 모델이거나, 오픈 소스라고는 하지만
00:10:39사용자가 오픈 소스 버전을 쓰길 원치 않거나, 결국 라이선스를
00:10:44진정한 오픈 소스 라이선스가 아닌 것으로 바꾸기도 하죠. 그래서,
00:10:49제가 Outposts와 오픈 소스에 열광하게 된 이유는 올바른 인센티브를 가질
00:10:54기회라고 느꼈기 때문입니다. 사업적으로 어떻게 생각하는지까지 자세히 들어가면
00:10:59너무 깊어질 수 있겠지만, 제 생각에 웹훅을 받아야 하는
00:11:03소비자 측 사용자가 웹훅을 보내야 하는 사람보다 최소 2~3배는 더 많습니다.
00:11:09생각해 보세요. 제가 웹훅을 보낸다면,
00:11:13모든 고객에게 보내는 거죠. 고객이 10명일 수도 있고, 막 시작했다면
00:11:17100명, 1,000명, 200만 명일 수도 있죠. 필연적으로 소비자 측이 훨씬
00:11:24사람이 많아요. 그래서 사업가의 관점에서 생각하면,
00:11:28소비자 측 시장을 공략하는 사업에 더 흥미가 생기죠. 하지만 깨달은 건,
00:11:33좋은 생산자 없이는 소비자도 없다는 점입니다. 점점 더
00:11:37개발하는 앱 전반에서 웹훅에 대한 수요가 늘고 있죠. 그래서
00:11:42더 많은 사람들이 이를 제공하고 싶어 하지만 기술적 부채나 오버헤드는 겪고 싶어 하지 않죠.
00:11:46제 관점에서는, 우선 웹훅을 보내는 건 더 간단한 문제입니다. 왜냐하면
00:11:51매개변수를 제어할 수 있으니까요. 반면 받는 쪽은 벤더가 매개변수를
00:11:57결정하죠. 그래서 단순하다고 말하고 싶지는 않지만,
00:12:02물론 잘못 구현할 방법은 많습니다. 하지만 문제 공간의 측면에서 보면
00:12:06소비자 측보다는 생산자 측이 훨씬 제한적입니다. 그리고 둘째로,
00:12:10우리의 일은 이벤트 생성을 장려하는 것입니다. 그게 결국 우리가
00:12:15신경 쓰는 일이죠. 더 많은 사람이 그 웹훅을 소비해서 결국엔
00:12:19고객이 되길 바라니까요. 그래서 우리는 이렇게 말할 수 있습니다.
00:12:23Outpost를 오픈 소스로 쓰든 관리형 버전의 Hookdeck으로
00:12:29배포하든 저희에겐 중요하지 않습니다. 둘 다 사업적 목표를 달성하는 거니까요.
00:12:35그런 인센티브의 정렬이 저를 정말 흥분시켰습니다. 몇 가지 한 게 있는데요,
00:12:40먼저, 관리형 버전을 만들기 전부터 오픈 소스를 공개했습니다.
00:12:44오픈 소스를 만들 당시엔 관리형 버전을 만들 계획이 아예 없었어요.
00:12:48오픈 소스 프로젝트는 2년 전쯤 공개되었습니다.
00:12:52그러니까 관리형 버전을 만들어 달라는 요청이 많아지기까지 거의 2년이 걸린 거죠.
00:12:57그게 첫 번째 부분입니다. 그리고 또 다른 부분은,
00:13:03Outpost의 관리형 버전이 오픈 소스 버전의 Docker 빌드와 완전히 동일하다는 점입니다.
00:13:08Docker Hub에 게시된 오픈 소스 빌드를 그대로 쓰죠. 비공개 포크가
00:13:13존재하지 않습니다. 기능을 따로 빼서 관리하지 않아요. 정말 똑같은 Docker 빌드를 실행합니다.
00:13:19그래서 질문은 '어떤 버전에 어떤 기능이 있느냐'가 아니라,
00:13:23직접 배포하고 운영 부담을 떠안을 것인가, 아니면 비용을
00:13:29지불하고 대신 관리하게 할 것인가의 차이일 뿐입니다.
00:13:34옳고 그른 답은 없습니다. 기업마다 수준이나
00:13:38편의성, 규정 준수 요건 등에 따라 달라지죠. 하지만 그렇기 때문에,
00:13:44해당 프로젝트를 통해 오픈 소스 커뮤니티에 좋은 기여자가 될 수 있다고 느낍니다. 네,
00:13:51이 작업은 정말 기뻤어요. 첫 번째로 하는 대규모 오픈
00:13:55소스 프로젝트였거든요. 기여를 듣는 것 외에도 핵심 메인테이너로서
00:14:01참여하는 건 처음이었죠. 그래서 좋았습니다.
00:14:05Claude Code 같은 도구들이 존재하는 지금, 오픈 소스 세계는 어떤가요?
00:14:09의미 없는 PR이나 보안 취약점 제보가 많았나요, 아니면 관리가 괜찮았나요?
00:14:14음, 다른 분들이 겪는 규모와 비교해서 말할 상황은 아닙니다.
00:14:20상황을 잘못 전달하고 싶지는 않아요. 확실히 많은 분께는 상황이
00:14:25나쁘게 들릴 수도 있겠죠. 저는 우리가 받은 기여의 품질에 놀랐습니다.
00:14:30하지만 분명 특정 PR도 있었어요. 아마 지금도 레포지토리에 열려 있을 텐데,
00:14:34Cloudflare Queues를 이벤트 목적지로 추가하는 내용이었죠.
00:14:40지원되는 목적지 중 하나로요. 겉으로 보기에는 설명도 좋고 그럴듯했어요.
00:14:44그런데 실제로 코드를 파고 들어가 보면 완전히 엉터리인 Cloudflare API들을
00:14:48사용하고 있었죠.
00:14:52제대로 확인도 안 했더라고요. PR을 올린 사람이 실제로 실행조차
00:14:56안 해본 게 분명했죠. 네. 이제 부담은 저희 몫이 된 거예요.
00:15:02공개 PR이 올라와 있는데, 우리가 경쟁자로 비춰질 수 있는 대상의
00:15:08기여자를 배척하는 것처럼 보일까 봐 조금 걱정되기도 했고요.
00:15:12그러니 Cloudflare Queues를 추가해야 하는 건 맞다고 생각하지만,
00:15:15동시에 이건 비공개 로드맵에 있었던 것도 아니고 그 사람 말고는
00:15:19요청한 사람도 없었죠. 그래서 아주 묘한 상태가 된 겁니다.
00:15:24닫으면 경쟁자를 배척하는 것처럼 보일까 봐.
00:15:28그렇다고 리소스를 들여서 로드맵을 앞당겨야 할까요?
00:15:33정확하게 구현하려면 말이죠. 그런 상황은 일종의 진퇴양난이었습니다.
00:15:37하지만 지금까지는 전반적으로 정말 좋은 경험이었습니다.
00:15:43같은 빌드를 사용하니까요. 저희가 하나 정한 원칙은 고객이 피드백을
00:15:48주거나 특정 기능에 대해 이야기할 때마다
00:15:53GitHub에 이슈를 열거나 기존 PR과 이슈를 안내하는 것입니다.
00:15:58레포지토리가 여기 있으니 기여할 수 있다는 걸 항상 알리려고
00:16:03하죠. 그 결과, 실제로 관리형 사용자들이 여러 차례
00:16:07직접 기여하고 스스로 기능을 구현해 주기도 했어요.
00:16:13그 덕분에 진정한 사용 사례에 대한 기여 장벽이 엄청나게 낮아졌죠.
00:16:18역사적으로 Go 프로젝트의 경우, 저희 사용자들 대부분은 Go 개발자가
00:16:24아니거든요. Python, TypeScript, Node.js 사용자가 많습니다.
00:16:28Go는 진입 장벽이 있었죠. 새로운 프로젝트를 배워서 기여한다는 건
00:16:35결코 쉽지 않으니까요. 그래서 그 장벽을 크게 낮춘 것은
00:16:39정말 좋은 일입니다.
00:16:42이제 사용자로서 '이건 정말 불편해'라는 문제를 겪을 때,
00:16:48메인테이너 입장에서도 그 기능이 구축할 가치가 있다는 강력한 신호가 되거든요.
00:16:53누군가 시간을 내어 자신의 워디 토큰을 들여 기능을 구현해 주는 것은
00:16:58정말 중요한 기능이라는 신호가 됩니다. 무엇이 가장 중요한지에 대한
00:17:02우선순위를 정하는 측면에서 말이죠. 진입 장벽을 낮추는 것은 정말 좋은 일이라고 생각합니다.
00:17:07스팸의 홍수나 다른 문제들만 잘 관리할 수 있다면, 긍정적인 면이 아주 많거든요.
00:17:12분명히 많은 장점이 있습니다.
00:17:14랜딩 페이지에서 눈에 띄는 것이 Vercel CEO의 추천사였습니다.
00:17:21Vercel도 제품으로서 훅덱(Hookdeck)을 사용하고 있더군요.
00:17:25해당 인용문을 읽어보면 그것을 추천하고 있기도 하고요.
00:17:29아, 그렇군요.
00:17:29Vercel 사용자들과 그런 종류의 사람들에게 말이죠.
00:17:32그런데 거기엔 사실 재미있는 이야기가 하나 있습니다.
00:17:35기예르모가 어느 토요일 밤에 트윗을 올렸거든요.
00:17:39전혀 예상하지 못했습니다.
00:17:40기예르모와는 이전에 친분이 있었던 것도 아니었고요.
00:17:45이건 커뮤니티에서 영향력 있는 사람들의 힘을 보여주는 사례죠.
00:17:48그 일로 인해 발생한 가입자 수와 인지도는
00:17:53정말 엄청났습니다.
00:17:54그 이후로 기예르모와는 가끔 연락을 주고받고 있습니다.
00:17:57항상 즐겁게 대화하고 있고요.
00:17:59흥미로운 점은,
00:18:00사실 Vercel 같은 회사를 보면 기예르모가 말해준 것이 하나 있는데
00:18:04웹훅(Webhooks)을 사용하는 사람이 훨씬 더 많아지고 있다는 점입니다.
00:18:07그는 그 이유가 주로 LLM 사용 때문이라고 분석하더군요.
00:18:12그것이 새로운 데이터 활용 사례를 만들어내고 있으니까요.
00:18:15예전에는 신경 쓰지 않았던 것들까지 말이죠.
00:18:18고객 지원 시스템을 예로 들어봅시다.
00:18:20상담원이나 사람이 직접 처리하는 환경에서는,
00:18:23새로운 티켓 이벤트 같은 것을 활용할 이유가 거의 없었습니다.
00:18:29그런 것들은 말이죠.
00:18:30어쨌든 그 메시지에 답변하는 건 사람이니까요.
00:18:34하지만 이제는 완전히 세상이 바뀌었습니다.
00:18:37사람이 에이전트를 작동시키는 시대에서 에이전트가 이벤트를 직접 다루는 시대로 변했죠.
00:18:42맞습니다.
00:18:42그러니 이제는 고객 지원 시스템, 마케팅 도구,
00:18:46기타 등등에서 발생하는 이벤트들이 중요해진 겁니다.
00:18:48그렇죠.
00:18:48플랫폼 기업들이 공통적으로 느끼고 있는 부분이라고 생각합니다.
00:18:54저희에게도 아주 흥미로운 논의 주제였죠.
00:18:57Vercel 자체가 저희를 직접 사용하는 건 아니지만,
00:19:01Vercel의 개발자들이 로컬 CLI 등에서 저희를 많이 사용할 거라고 확신합니다.
00:19:05네, 그렇습니다.
00:19:06그렇다면 훅덱을 사용하는 전형적인 고객은 누구인가요?
00:19:10소규모 티셔츠 쇼핑몰을 운영한다면 훅덱을 어떻게 사용할 수 있을까요?
00:19:15사용하는 게 의미가 있을까요?
00:19:17아마 아닐 겁니다.
00:19:19그렇군요.
00:19:21알겠습니다.
00:19:22정말 어려운 질문을 하셨네요. 저희가 항상 고민해왔던 문제거든요.
00:19:26사람들이 웹훅에 의존하는 이유가 너무나 다양하기 때문입니다.
00:19:32그 범위가 정말 엄청나게 넓어요.
00:19:35스트라이프(Stripe)나 쇼피파이(Shopify) 같은 익숙한 업체들도 있고,
00:19:40호주의 통신사들이나 영국의 결제 기관들에서도 웹훅을 사용합니다.
00:19:47EVE 온라인 게임사에서도 많이 사용하고요.
00:19:5015년쯤 된 코난 바바리안 게임을 여전히 즐기는 커뮤니티도 있습니다.
00:19:55그들도 웹훅을 아주 잘 활용하고 있죠.
00:19:58왜인지는 묻지 마세요.
00:20:00그렇군요.
00:20:00맞습니다.
00:20:01핵심은 저희 고객층이 너무 다양해서 특정하기가 매우 어렵다는 겁니다.
00:20:06특정 집단이 고객의 전부가 아니니까요.
00:20:08맞습니다.
00:20:09사용자층을 살펴보면 특정 용도가 전체의 10%를 넘지 않아요.
00:20:13그룹화하기도 어렵고요.
00:20:14아까 말씀하신 이커머스 사례로 돌아가서,
00:20:16작은 티셔츠 가게는 자체 앱을 구축하지는 않겠지만,
00:20:19거의 확실하게 여러 서드파티 앱들을 설치해서 사용할 겁니다.
00:20:25그 앱들이 웹훅에 의존하는 경우가 많죠.
00:20:27리뷰 수집 앱이나 재입고 알림 앱,
00:20:30재고 관리 앱, 3PL 연동 앱 등이 대표적입니다.
00:20:35그 서비스들이 전부 웹훅을 통해 통신하니까요.
00:20:39그런데 이 모든 서비스들은 거의 전적으로 웹훅(Webhooks)에 의존하고 있습니다.
00:20:43그렇죠.
00:20:43그래서 재입고 알림을 보내고 싶다면, 웹훅을 통해 쇼핑몰의 모든 재고 업데이트 내역을
00:20:48계속 감시하고 있는 겁니다.
00:20:50그러다가 품절되었던 상품이 다시 재고가 확보되는 즉시,
00:20:53바로 '알겠다, 이메일을 보내야지'라고 하는 거죠.
00:20:54맞아요.
00:20:55기본적으로 그들이 설치하거나 추가하는 모든 기능들은 결국
00:20:59보이지 않는 곳에서 웹훅에 의존하게 되는 겁니다.
00:21:00고객별 맞춤 정보 처리 같은 작업들이죠.
00:21:02이 모든 것이 웹훅을 통해 이루어집니다.
00:21:07그러니까 아주 작은 상점은 잘 모를 수도 있지만,
00:21:09어느 정도 규모가 있는 곳이라면,
00:21:11웹훅을 사용하지 않는 곳이 거의 없습니다.
00:21:14알겠습니다.
00:21:19그럼 AWS EventBridge와는 무엇이 다른가요?
00:21:22이들은 시스템 통합을 위해 커스텀 앱을 구축하는데, 주로 운영적인 측면에서
00:21:28주문을 3PL과 동기화해야 할 시점의 순서 제어나 메모 추가 같은 작업들이죠.
00:21:34맞습니다. AWS도 훌륭하지만 저희는 더 나은 경험을 제공하려고 합니다.
00:21:39적절한 API, 멋진 UI,
00:21:41탄탄한 안정성 등이죠.
00:21:41AWS는 서비스 종류가 너무 많아서 설정이 복잡하고,
00:21:46관리가 분산되어 있는 경우가 많습니다.
00:21:51가장 큰 차이점은 AWS EventBridge는 범용적이지 않다는 점이에요.
00:21:55판매자가 AWS와 연동되어 있어야만 사용할 수 있거든요.
00:21:59선택할 만한 곳 중에서는 WebEx를 잘 안 쓰는 곳이겠지만, 하지만 아시다시피
00:22:04그 분야에 속한 거의 모든 곳이라면, 결국에는
00:22:08WebEx를 사용하는 회사와 마주하게 될 겁니다.
00:22:09코드를 재배포할 필요도 없고요.
00:22:10그게 AWS와의 결정적인 차이입니다.
00:22:11AWS EventBridge 같은 것과는 어떻게 비교되나요?
00:22:14Azure Event Grid 같은 곳도 경쟁자이긴 하지만,
00:22:17저희가 하려는 범위는 훨씬 더 넓습니다.
00:22:19물론 AWS 생태계를 선호하는 분들도 계시겠죠.
00:22:24시장 점유율이 100%일 필요는 없으니까요.
00:22:25적절한 해결책을 찾는 분들에게는
00:22:26훅덱이 최선이 될 수 있다고 봅니다.
00:22:31최근 들어 대형 기업들의 다운타임이 늘어난 것 같습니다.
00:22:37GitHub이 다운되는 밈도 많아졌고요.
00:22:40예전에는 P99가 조금만 떨어져도 심각한 문제였는데,
00:22:46이제는 일상이 된 것 같아요.
00:22:47정말 그렇습니다.
00:22:47이런 상황에서 훅덱을 통해 어떤 도전 과제를 보시나요?
00:22:51웹훅을 사용하는 기업들, 특히 GitHub 같은 곳은
00:22:56정말 어려운 인프라 문제를 겪고 있습니다.
00:22:59에이전트 사용이 늘어나면서,
00:23:01트래픽이 폭증하고 있거든요.
00:23:01정말 힘든 문제겠죠.
00:23:02하지만 더 넓게 보면 AWS EventBridge는 실제로는 누구와도 통합되지 않는다는 점입니다,
00:23:07누구하고도요.
00:23:08그러니까 벤더 측에서 AWS EventBridge와 통합을 해줘야 한다는 거죠.
00:23:11API 게이트웨이 같은 걸 사용해서 우회할 방법들은 있지만요.
00:23:16그런데, 음, 핵심은 이게 애초에 AWS 생태계를 위해 만들어졌다는 겁니다. 그래서 대부분의
00:23:23사용 사례가 사실은 AWS 내부 이벤트에 관한 것이죠. 예를 들면 새로운 S3 문서가 업로드되었다거나,
00:23:31그런 종류의 일들 말이에요.
00:23:31그리고 서드 파티와의 상호 운용성은, 뭐 40여 개 정도의 벤더를 지원한다고 하지만,
00:23:36아, 지금은 업데이트되었을 수도 있으니 너무 믿지는 마시고요. 어쨌든 수천 개는 아니란 거죠.
00:23:40항상 이런 상황에 처하게 돼요. 오케이, Shopify는 EventBridge를 지원하는데, Twilio는 안 된다거나 하는 식이죠.
00:23:45이런 도구가 있다면 운영이 훨씬 쉽겠네요.
00:23:47감사합니다.
00:23:47오늘 대화는 여기까지 하죠.
00:23:51좋은 시간이었습니다.
00:23:52그래서 저희가 하려는 것이 바로 그런 점입니다.
00:23:54벤더가 동의하거나 허락해 줄 필요 없이,
00:23:59다음에 또 뵙겠습니다.
00:24:02그런 의미에서 저희가 '데크'를 구축하는 방식은 꽤 혁신적이라고 생각하는데,
00:24:08HTTP 기반으로만 작동하기 때문입니다.
00:24:10즉 저희가 URL을 하나 제공해 드리면, 기존의 웹 URL을
00:24:15저희가 제공한 URL로 교체만 하면 됩니다.
00:24:17그러면 데크 내에서 목적지가 원래의 데크 URL이 되는 거죠.
00:24:22저희는 그 사이에서 일종의 푸시 기반 큐(push-based queue) 역할을 합니다.
00:24:25그래서 모든 웹 데이터를 HTTP로 받아온 뒤, 설정하신 속도에 맞춰
00:24:28좋은 하루 보내세요.
00:24:31하지만 이건 코드를 다시 배포할 필요조차 없다는 뜻이죠.
00:24:34어떤 클라우드나 스택을 쓰든 상관없이 즉시 바로 작동하니까요.
00:24:39네.
00:24:40결국 필요한 건 URL을 업데이트하는 것뿐이니까요.
00:24:44AWS EventBridge와는 완전히 다른 이야기죠. 거기는 철저한 벤더 종속이기도 하고,
00:24:48특정 호환성이 필요해서 AWS 생태계 내에서만 작동하니까요.
00:24:53수고하세요.
00:24:53하지만 전 보통 EventBridge를 다른 거대한 이벤트 게이트웨이 중 하나로 생각해요.
00:24:58경쟁 제품인 Azure Event Grid도 실제로 세력을 넓혀가고 있고요.
00:25:04그래서 우리의 가장 직접적인 경쟁 상대나 영감을 주는 대상을 생각해보면
00:25:10어떤 면에서는 바로 그 두 제품이라고 할 수 있죠.
00:25:13하지만 우리가 지향하는 범위는 훨씬 더 크다고 생각합니다.
00:25:17어떤 사람들에게는 그게 장점이 되겠죠.
00:25:18또 어떤 이들에게는 아닐 수도 있고요, 그렇죠?
00:25:20누군가에게는 딱 그게 필요할 테니까요.
00:25:22AWS 생태계에 완전히 익숙한 사용자들은 말이죠.
00:25:24그들은 CloudFormation을 사용하고,
00:25:26고생 많으셨습니다.
00:25:27필요한 기능들을 직접 골라서 쓸 수 있길 원하죠.
00:25:30뭐, 그건 괜찮아요.
00:25:31시장 점유율을 100% 가져갈 생각은 전혀 없습니다.
00:25:34미국 시장에서는 사실 몇 퍼센트 정도만 차지해도 충분할 것 같거든요.
00:25:38그래서 저희는 특정 기업들이나 개발자들에게 적합한 솔루션이라는 점을 강조하려고 합니다.
00:25:45그들에게는 그게 맞는 해결책이 될 테니까요.
00:25:48또 다른 경우엔 AWS 이벤트 브리지(EventBridge)를 쓰겠죠. 그것도 괜찮습니다.
00:25:51최근 1년 사이에 대기업들의 서비스 장애가 점점 더 잦아지고 있다는 느낌을 받았거든요.
00:25:59장애가 늘고 있는 거죠.
00:26:00GitHub 장애 관련 밈 같은 것들도 있잖아요.
00:26:022년 전만 해도 P99 지표가 99.5% 밑으로 떨어지면,
00:26:07팀 전체가 모여서 심각하게 회의를 하곤 했거든요.
00:26:13도대체 왜 이런 일이 생기냐면서요.
00:26:14그땐 그랬는데, 지금은 그냥 일상이 된 것 같아요.
00:26:15맞아요.
00:26:17네.
00:26:17사람들이 이제 GitHub이 한참 동안 먹통이 되어도 그러려니 하게 됐죠.
00:26:23훅(Hook)의 관점에서 볼 때 올해 들어 서비스 장애가 예전보다 훨씬 많아졌다고 보시나요?
00:26:28그리고 그런 문제들을 어떻게 해결하고 계신가요?
00:26:33재밌는 질문이네요. GitHub 웹훅(Webhooks)을 사용하려 할 때 반드시 고려해야 할 부분이니까요.
00:26:37GitHub 웹훅을 사용하려고 할 때, 특히 GitHub 웹훅이 상당히 골칫거리죠.
00:26:42Railway나 Vercel 같은 곳에 로그인하면 두 번 중 한 번은,
00:26:46작은 배너가 떠 있을 거예요.
00:26:47GitHub 웹훅이 작동하지 않아서 배포가 중단됐다는 식의 알림이죠.
00:26:51실제로 GitHub CTO가 인프라 안정성에 관해 블로그에 글을 올리기도 했어요.
00:26:58온갖 밈들이 쏟아지는 와중에 상황을 좀 진정시켜 보려고요.
00:27:02상황을 좀 진정시키려 했던 거죠.
00:27:03별 효과는 없었던 것 같지만요.
00:27:05어쨌든 그 글에서 명확히 언급한 문제 중 하나가 웹훅 안정성이었는데,
00:27:09그게 어떻게 MySQL 같은 것에 의존하는지 등등을 다뤘죠.
00:27:12네.
00:27:13그들의 공로를 인정하자면, 제가 생각하기에 기사에서 이 부분을 표현하는 방식이 좀 무시하는 투인 것 같거든요.
00:27:17그들이 겪는 인프라 문제가 정말 엄청나게 복잡할 거라는 점은 조금도 의심하지 않습니다.
00:27:21감사합니다.
00:27:23마치 오픈소스 메인테이너들이 넘쳐나는 요청에 시달리는 것과 같은 상황이죠.
00:27:26그게 바로 인프라 과부하 문제이기도 하고요.
00:27:30그래서 정말 극도로 어려운 도전 과제일 거라고 확신합니다.
00:27:33하지만 제가 드리고 싶은 말씀은, 네, 우리도 그걸 보고 있다는 겁니다.
00:27:38그뿐만 아니라, 실제로 일부 벤더에 대해서는 모니터링도 하고 있고요.
00:27:41그래서 예를 들면, 저희는 '웹훅 레이더(WebHook Radar)'라고 부르는 기능을 갖추고 있습니다.
00:27:44그 개념은 모든 고객과 모든 웹훅으로부터 수집된 통계를 바탕으로 전체적인 상황을 파악하는 것입니다.
00:27:49덱을 통해 들어오는 웹훅 데이터를 모아서 전송 지연 시간 같은 수치를 계산해냅니다.
00:27:53예를 들어, 특정 벤더의 P99 전달 지연 시간이나 가동 시간 같은 것들을 확인하는 식이죠.
00:27:58Shopify를 위한 저희 레이더 기능은 꽤 인기가 많습니다.
00:28:01이미 수백 명의 구독자가 있기도 하고요.
00:28:04그래서 기본 아이디어는, 지연 시간이 특정 기준치를 벗어나면 알림을 보내주는 것입니다.
00:28:09기준 지연 시간의 표준 편차를 벗어나는 경우죠.
00:28:12맞아요.
00:28:12Shopify의 경우, 일반적인 전달 지연 시간은 약 4~5초 정도입니다.
00:28:17전달 시에요.
00:28:1710초 이상 넘어가면 알림을 보내도록 설정하죠.
00:28:19그렇군요.
00:28:20일종의 경고 알림을 보내는 방식입니다.
00:28:22이런 시계열 데이터를 모니터링하면서 상황을 파악할 수 있게 하는 것이죠.
00:28:26단순히 가동 시간뿐만 아니라 지연 시간 프로필이 시간에 따라 어떻게 변하는지도 볼 수 있고요.
00:28:31시간이 지남에 따라 말이죠.
00:28:32그건 확실히 확인할 수 있는 부분입니다.
00:28:33Shopify 팀도 그 부분을 잘 알고 있습니다.
00:28:36하지만 전달 시간에 꽤 많은 변동성이 있다는 것을 알 수 있죠.
00:28:41두 달에 한 번꼴로 지연 시간과 관련해 꽤 큰 사건이 발생하곤 합니다.
00:28:46지연 시간과 관련된 유의미한 사건들이요.
00:28:49평소에는 보기 힘든 현상이기도 하죠.
00:28:51맞아요.
00:28:52다운타임은 훨씬 감지하기 쉬우니까요.
00:28:54Datadog이나 Better Stack 같은 곳에서 확인할 수 있죠.
00:28:57그걸 뭐라고 하더라, 메트릭 제품이라고 하던가요?
00:29:01가시성(Observability)이죠.
00:29:02네, 맞습니다. 가시성.
00:29:03Better Stack 같은 곳에서 그런 걸 구축하잖아요.
00:29:05맞아요.
00:29:06엔드포인트로 향하는 HTTP 호출이 뚝 끊기면 바로 알 수 있죠.
00:29:11그렇죠.
00:29:11문제는 명확하고 해결하기도 쉽습니다.
00:29:14하지만 지연 시간이 60초까지 늘어지면 실제 메트릭으로 알아차리기가 매우 어렵습니다.
00:29:19현재의 메트릭 데이터로는 파악하기가 힘들죠.
00:29:22맞아요.
00:29:23그건 처리하는 데 걸리는 지연 시간 때문인데, 아마 추적(tracing) 등을 통해 확인할 수 있겠죠.
00:29:27그렇지만 기본적으로는 벤더 측의 지연 문제입니다.
00:29:28벤더 쪽에서 발생하는 지연인 거죠.
00:29:31만약 코드나 비즈니스 운영에 실시간성이라는 새로운 가정이 포함되어 있다면,
00:29:34이벤트가 60초 뒤에 도착할 경우 여러 미묘한 문제나 버그, 잘못된 가정이 생길 수 있습니다.
00:29:39코드 전체에 걸쳐 의도치 않은 문제들을 일으키기 시작하는 것이죠.
00:29:44그래서 저는 저희가 좋은 데이터를 제공하는 데 더 유리한 위치에 있다고 봅니다.
00:29:46문제가 나에게 있는지, 아니면 벤더 측에 있는지 명확히 알 수 있게 말이죠.
00:29:50양질의 데이터를 제공하는 것이죠.
00:29:52문제가 어디서 발생하는지 파악할 수 있으니까요.
00:29:55맞아요.
00:29:56어디서 문제가 생기는지 아는 게 중요하죠.
00:29:57이 문제가 얼마나 자주 발생하는지 경험적으로 확답할 수는 없습니다.
00:30:03늘 언급되는 흔한 범인들이 있긴 하죠.
00:30:06책임을 묻기 쉬운 대상들이 있기는 합니다.
00:30:08이걸 전반적으로 발생하는 분산형 문제라고 할 수 있을지는 잘 모르겠어요.
00:30:13특정 벤더에 집중된 경우가 더 많은 것 같습니다.
00:30:16사람들이 가장 골머리를 앓는 부분은 역시 전달 지연 문제입니다.
00:30:23사람들은 대부분의 벤더에서 전달 지연이 실제보다 더 낮을 것이라고 생각하는 경향이 있어요.
00:30:27보통은 몇 초 정도 걸리는데, 관점에 따라 긴 시간일 수도 아닐 수도 있죠.
00:30:31하지만 전달 시간 차트를 보여주면 사람들이 놀라곤 합니다.
00:30:34Shopify 개발자들에게 이 지연 차트를 보여주면 첫 반응이 '이 정도일 줄은 몰랐다'입니다.
00:30:40예상과 다른 결과에 충격을 받죠.
00:30:43맞아요.
00:30:43기존의 기대를 깨는 경험을 하게 되는 거죠.
00:30:46저도 예전에 꽤 큰 전자상거래 회사에서 일할 때 똑같은 문제를 겪었습니다.
00:30:53지연 시간 문제는 심각한데, 모두가 서로를 탓하는 스파이더맨 밈 같은 상황이었죠.
00:30:58누구 팀 책임인지 서로 핑퐁을 치는 거예요.
00:30:59말씀하신 대로 보통은 써드파티 벤더 탓으로 돌아가곤 합니다.
00:31:05가끔은 어쩔 도리가 없는 경우도 많고요.
00:31:07그저 우회해서 해결해야 하는 거죠.
00:31:08멋진 일이죠.
00:31:09벤더 탓만 하기에도 조심스러운 면이 있습니다.
00:31:11맞습니다.
00:31:11하는 일의 맥락에서 보면 이런 문제는 항상 발생하기 마련이죠.
00:31:16흔한 문제라고 할 수 있습니다.
00:31:18문제가 터지면 항상 벤더에게 얼마나 책임을 물어야 할지 고민하게 되죠.
00:31:22어디까지가 합리적이고 어디까지가 비합리적인지 판단하는 것도 어렵고요.
00:31:27단순한 우연인지, 아니면 구조적 결함인지 구분해야 하니까요.
00:31:29얼마 전 Railway에서 발생했던 사례처럼요. 일부 아웃포스트 관리 배포 작업이 Railway에서 실행되는데,
00:31:34그쪽의 가격 정책 때문에 운영 중이었거든요.
00:31:36오픈소스와 동일한 버전을 실행해야 해서 멀티 테넌트 방식을 적용하지 않았죠.
00:31:40그런 방식은 오픈소스 환경에는 적합하지 않으니까요.
00:31:44그래서 기본적으로 모든 고객을 위해 실제 배포를 따로 진행합니다.
00:31:48네.
00:31:49무료 플랜 사용자를 위해 Railway에 인스턴스를 배포하는데,
00:31:52일반적으로는 아주 잘 작동합니다.
00:31:54하지만 얼마 전 그들의 GCP 계정이 차단되는 바람에 6시간 정도 서비스가 중단됐었죠.
00:31:59그렇죠.
00:31:59맞아요.
00:31:59그럴 땐 대체 뭐라고 설명해야 할지 참 난감하죠.
00:32:06책임을 돌리는 것과는 별개로 말입니다.
00:32:09물론 벤더에 대한 책임은 우리에게 있지만요.
00:32:11어쨌든 그 경계를 걷는 건 참 어렵습니다.
00:32:14사람들이 무의식적으로 손가락질하며 남 탓을 하려는 경향이 있다는 것을 잘 알죠.
00:32:18그게 스스로의 책임감을 덜어주기 때문이기도 하고요.
00:32:20그런 심리에 맞서 싸워야 하는 부분도 분명 있습니다.
00:32:23맞아요.
00:32:24벤더의 문제라는 확신이 들 때가 문제죠.
00:32:28그걸 정확히 식별해내고 데이터를 확보하는 건 정말 중요합니다.
00:32:31하지만 벤더 쪽 문제는 항상 데이터 부족이 걸림돌이죠.
00:32:35그렇죠.
00:32:35상대방의 내부 데이터는 볼 수 없으니까요.
00:32:37그래서 벤더 문제라고 확신하며 실증적 증거를 제시하기가 참 어렵습니다.
00:32:42그게 확실히 그들의 탓이라고 말하기엔요.
00:32:43자체 데이터를 바탕으로 추론해야 하는데, 맞을 수도 있고 틀릴 수도 있으니까요.
00:32:46맞습니다.
00:32:47Shopify나 Stripe 같은 곳에서 중단 사태가 발생했을 때가 궁금합니다.
00:32:51이벤트들이 어떻게 밀린 작업을 처리하는지, 그리고 그게 저희 서버에 큰 부담이 되지는 않는지요?
00:32:57네, 기본적으로 렉(lag)이 심하게 발생하죠.
00:33:00항상 하는 말이, 웹훅 볼륨을 임의로 가정해서는 안 된다는 겁니다.
00:33:05특정 볼륨을 무조건적으로 가정해선 안 되죠.
00:33:09흠.
00:33:09모든 벤더가 타임아웃을 강제한다는 특징이 있거든요.
00:33:14그렇죠.
00:33:14보통 3초에서 5초 정도를 주죠.
00:33:15플랫폼에 따라 응답 대기 시간이 다릅니다.
00:33:18그 시간 내에 유의미한 작업을 완료하기란 거의 불가능합니다.
00:33:21네트워크 지연 시간 등을 고려하면 더더욱 그렇고요.
00:33:25맞아요.
00:33:25이유가 그것만은 아니지만요.
00:33:28그래서 큐(queue)를 사용하는 것이 상식적인 이유이기도 합니다.
00:33:31동기적으로 처리할 수 있는 영역이 아니거든요.
00:33:33아, 제가 무슨 이야기를 하고 있었죠?
00:33:39혹시 질문을 한 번만 다시 해주실 수 있을까요?
00:33:42Stripe나 Shopify 같은 기업의 중단 사태와 그 이후의 대응에 대해 물어봤어요.
00:33:45아, 그랬죠.
00:33:45작업이 밀렸을 때의 상황이요.
00:33:47네.
00:33:47맞습니다.
00:33:47네.
00:33:47지연 문제 등등 장황하게 설명했지만, 요점은 자동 확장이 필수적이라는 겁니다.
00:33:52Auto scaling이 필요하다는 거죠.
00:33:53아주 짧은 시간 내에 확장이 가능해야 하니까요.
00:33:56이런 스파이크는 다양한 이유로 발생합니다.
00:33:58고객이 대량으로 데이터를 가져오거나(bulk import) 하는 경우도 있고요.
00:34:03그런 건 흔하죠.
00:34:03맞아요.
00:34:03스파이크가 발생하는 이유는 여러 가지입니다.
00:34:05하지만 중단 사태도 그중 하나죠.
00:34:07맞습니다.
00:34:07Shopify가 30분 정도 중단되었다가 복구되면,
00:34:11그들은 쌓인 백로그를 처리하기 위해 엄청난 속도로 요청을 쏟아냅니다.
00:34:16큐에 쌓인 부담을 줄이려고 하는 거죠.
00:34:17중단 기간 동안 축적된 모든 작업을 한꺼번에 처리하려고 하는 겁니다.
00:34:22그 때문에 평소보다 훨씬 높은 용량을 사용하게 됩니다.
00:34:26밀린 작업을 따라잡으려 하기 때문이죠.
00:34:28그렇죠.
00:34:28결국 최종 스토어들로 엄청난 요청을 보내게 되는 결과를 초래합니다.
00:34:32즉, 트루풋(throughput)의 불규칙성은 우리 때문이 아닙니다.
00:34:37우리 책임이 아니라는 거죠.
00:34:38100% 벤더의 책임입니다. 그들도 자기들 인프라 문제를 겪는 것이니까요.
00:34:42그런 복합적인 상황이 있는 거죠.
00:34:44분명히 Shopify가 웹훅을 보내는 용량은 우리가 받는 용량보다 훨씬 큽니다.
00:34:49거의 대부분 그런 상황이죠.
00:34:52네.
00:34:52재밌는 사실은, 저희 투자자 중 한 명이 Twilio의 CPO였다는 점입니다.
00:34:56그래서 저희 사업에 더 관심을 가졌던 것 같고요.
00:34:59그가 말하길 Twilio가 고객들을 상대로 의도치 않게 DDoS를 자주 했다고 합니다.
00:35:04거의 모든 면에서 그랬다고 하더군요.
00:35:07벤더 주도 이벤트에서 발생하는 이런 현상은 어느 정도 불가피한 부분이 있습니다.
00:35:14업계에선 꽤 잘 알려진 문제죠.
00:35:17벤더들 사이에서 흔히 발생하는 문제입니다.
00:35:21그들도 응답 지연 시간 등을 통해 충분히 추적할 수 있는 내용입니다.
00:35:24서버 응답 지연 시간도 말이죠.
00:35:26고객을 DDoS 공격하듯 과부하를 주면 당연히 지연 시간은 올라갑니다.
00:35:29그러다 어느 순간 타임아웃이 발생하죠.
00:35:31타임아웃이 길어질수록 처리량은 줄어드니 상황은 더 악화됩니다.
00:35:34HTTP 연결을 오래 잡고 있어야 해서 처리할 수 있는 요청 수는 줄어들죠.
00:35:38서버 워커들의 효율이 떨어지게 됩니다.
00:35:40그럼 확장을 해야 하고, 확장하니 요청은 더 쏟아지고, 악순환이죠.
00:35:45그냥 문제가 계속 쌓이는 겁니다.
00:35:46스스로 더 강해지는 악순환이라고 볼 수 있어요. 웹훅을 처리할 능력이 부족해지면,
00:35:52응답 지연 시간은 빠르게 악화되니까요.
00:35:57서버가 포화 상태에 도달하면 지연 시간은 정말 걷잡을 수 없이 나빠지죠.
00:36:01그런데 요청은 계속해서 쏟아져 들어오고요.
00:36:04많은 벤더는 어느 순간 엔드포인트를 아예 비활성화해버립니다.
00:36:07계속 쌓이는 것을 막아야 하니까요.
00:36:10서버 응답이 느리다고 수십만 개의 HTTP 연결을 붙잡고 있을 수는 없으니까요.
00:36:14비효율적이니까요.
00:36:15하지만 비활성화하는 순간 데이터는 유실됩니다.
00:36:19그게 가장 큰 문제죠.
00:36:21통제 불가능한 변수 속에서 응답 시간을 보장하는 것이 큰 도전 과제입니다.
00:36:25쉽지 않은 문제죠.
00:36:29AI 시대가 도래하면서 웹훅 생태계는 어떻게 변하고 있다고 보시나요?
00:36:37LLM이 더 많은 웹훅을 보내고 처리하고 있다고 하셨는데 말이죠.
00:36:43Hookdeck 내부적으로는 AI를 어떻게 활용하고 계신가요?
00:36:48이 분야에서 AI의 미래를 어떻게 보시는지도 궁금합니다.
00:36:51네, 그 방면에서 많은 일이 일어나고 있습니다.
00:36:54소프트웨어 개발 업체로서 저희도 마찬가지고요.
00:36:57여러분도 비슷한 고민을 겪고 계실 것 같아요.
00:37:02매주 바뀌는 워크플로우와 토큰 비용 문제 같은 것들 말이죠.
00:37:05적절한 토큰 비용은 어느 정도인지 고민하는 것도 그렇고요.
00:37:10네, 리더보드는 필요 없어요.
00:37:15전 리더보드라는 아이디어가 꽤 두렵습니다.
00:37:18마진을 갉아먹는 확실한 방법이 될 것 같거든요.
00:37:24두 가지 생각을 말씀드리고 싶네요.
00:37:25앞서 말씀드린 것처럼, 에이전트 기반의 사용 사례로 인해 이벤트의 성장이 이루어지고 있습니다.
00:37:29에이전트들이 이제 인간의 수동 트리거에서 벗어나 이벤트 트리거로 이동하고 있으니까요.
00:37:35클라우드 에이전트 제품들이 쏟아져 나오고 있고, 에이전트들이 활발히 움직이고 있습니다.
00:37:41많은 것들이 변하고 있죠.
00:37:42결국 이 모든 건 스케줄이나 이벤트에 의해 트리거됩니다.
00:37:46이벤트가 추상화되어 있지만, GitHub PR이나 커밋, 댓글처럼 다 웹 기반이죠.
00:37:49GitHub PR이나 커밋, 혹은 GitHub에 댓글을 달 때 같은 일들 말이죠. 이 모든 게 웹 기반입니다.
00:37:56하지만 분명히 그 범위를 훨씬 넘어설 겁니다. 고객 지원이나 Slack, 이런저런 것들,
00:38:00심지어 센서 데이터 같은 것들로부터 현실 세계에서 발생하는 실시간 데이터까지 포함해서 말이죠.
00:38:04그렇지 않나요?
00:38:08많은 에이전트들이 기본적으로 다른 에이전트와 이벤트를 주고받을 필요가 생길 거라고 생각합니다.
00:38:12에이전트의 결과물이 곧 이벤트가 되어,
00:38:17그게 다른 회사나 다른 에이전트를 트리거하게 되는 식이죠. 물론 이걸,
00:38:21웹훅(Webhooks) 유즈케이스로 설명할 수도 있고, 실제로도 그런 셈이죠.
00:38:23하지만 현재 웹훅과 관련된 몇 가지 의미론적 측면들은 다소 결함이 있다고 생각합니다.
00:38:28그런 부분들 때문에 저희는 이벤트 목적지(event destinations)를 더 나은 패턴으로,
00:38:33이를 위한 더 최적화된 패턴으로 밀고 있는 것이죠.
00:38:36또 다른 점은, 이벤트에 대응하여 실행하는 것이 에이전트 기반 워크플로우라면,
00:38:40이들은 비결정론적일 수 있고 꽤 오래 실행될 수도 있어서,
00:38:47이벤트 결과에 따라 용량을 조정하고 확장하기가 훨씬 더 어려워진다는 것입니다.
00:38:51그래서 처리량 관리나 용량 관리 같은 것들이 훨씬 더 까다로워질 겁니다.
00:38:55클라우드 타임아웃이나 평가(evals) 실패 등으로 인해 실패율도 더 높아질 것이고요.
00:39:00그런 것들은 전부 다 예상 가능한 일들이죠.
00:39:07따라서 애플리케이션 구축 관점에서 볼 때, 어떤 핵심 원시(primitive)를 사용할지,
00:39:12어디서 실행할지, 얼마나 오래 실행할지, 그리고 배압(back pressure) 처리는 어떻게 할지 같은 문제들에 대해,
00:39:16새로운 도전 과제들이 정말 많습니다. 그리고 내부적으로 저희가 하려는 방식에 대해서는,
00:39:21아직 적절한 방법을 찾아가는 중이라고 생각합니다.
00:39:25저도 용량(capacity) 문제에는 완전히 압도당하는 기분입니다. 이건 누구에게나 그렇겠죠. 제가 특별히 독창적인 통찰을 가져온 것 같진 않네요.
00:39:29다만 한 가지 말하고 싶은 건, CLI 프롬프트나 코덱스 같은 것에서부터,
00:39:34실제로 높은 품질의 세련된 제품을 배포하기까지의 과정에서 필요한,
00:39:41미묘한 차이(nuance)들이 수많은 밈이나 노출 속에서 여전히 잃어버려지고 있다는 점입니다.
00:39:45그런 토큰들을 다 써가며 과연 세상을 위해 실질적인 가치를 더하는 무언가를 만들 수 있을지,
00:39:50저는 의구심이 듭니다.
00:39:55물론 지금까지 저희 경험상 보안이나 코드 리뷰 같은 부분에서는 확실히 큰 조력자가 되어줍니다.
00:40:01하지만 그것들은 일종의 기본 조건(table stakes)일 뿐이라고 봅니다.
00:40:06그것들이 결국 근본적으로 가치를 더해주는 핵심은 아니라는 거죠.
00:40:11사람들이 정말로 가치를 느끼는 무언가를 만드는 문제에 있어서는 말이죠.
00:40:14아직은 꽤 간극이 있다고 봅니다.
00:40:19그 수준의 감각과 통찰력, 고객 이해도와 공감 능력을 가져오는 것은 여전히 우리 팀의 몫입니다.
00:40:25그런 것들은 단순히 챗박스에서 바로 얻을 수 있는 게 아니거든요.
00:40:31어쩌면 저희가 너무 고지식하게 굴어서, 더 빠르게 움직일 수 있음에도 그러지 못하는 건지도 모르죠.
00:40:35만약 우리가 모든 걸 대충 한 번에 처리하고 달렸다면 결과는 달랐겠지만, 현재 저희 접근 방식은,
00:40:42최종 결과물에 대한 기대치를 여전히 높게 유지하며 사용자에게 가치를 전달하는 것입니다.
00:40:47물론 우리가 더 많은 일을 할 수 있게 된 것은 분명합니다.
00:40:53감각과 공감 능력을 갖춘 더 많은 사람들이 사용자에게 가치를 줄 수 있게 되었죠. 왜냐하면 코딩이라는 장벽이 낮아졌으니까요.
00:40:57예를 들어, 이제 우리 회사 거의 모든 사람이 이른바 '코딩'을 합니다.
00:41:01우리 디자이너는 이제 코딩을 담당하고, 웹사이트를 전적으로 책임지고 있습니다.
00:41:06대시보드 작업이나 제품 마케팅, 개발자 관계 관리(dev rel) 쪽도 마찬가지고요.
00:41:11토큰을 낭비하는 게 아니라면, 리더보드가 있다면 아마 그들이 상위권에 있을 겁니다.
00:41:16이건 정말 좋은 현상입니다.
00:41:20그런 사람들은 세련된 최종 사용자 경험을 제공하기 위해 필요한 비판적 사고를 갖추고 있어야 하고,
00:41:25이제 코딩은 더 이상 장벽이 아니니까요.
00:41:30그래서 어떤 면에서는, 순수한 엔지니어링보다 더 큰 이점이 거기서 나온다고 봅니다.
00:41:36물론 순수 엔지니어링도 큰 가치를 얻고 있지만,
00:41:40병목 현상은 여전히 그 '감각'에 남아 있습니다. 게다가 전 요즘,
00:41:45의미 없는 PR(풀 리퀘스트)들을 검토하는 데 너무 많은 시간을 쓰고 있습니다. 이것도 단점이죠.
00:41:51맞아요. 확실히 그렇고, 검토해야 할 코드 양도 엄청나죠.
00:41:56거의 가능성이 없는 모호한 취약점 같은 것까지 만들어내니까요.
00:42:01심지어 낮은 우선순위조차 아니라고 생각하지만, 일단 표면 위로 드러나면,
00:42:06그것에 대해 책임감을 느껴야 하니까요. 그건 정상적인 일이라고 봅니다.
00:42:09어느 순간 보니까, 우리가 지금까지 이 정도로 많은 PR을 열어둔 적이 있었나 싶더라고요.
00:42:14이 모든 걸 제대로 파악하는 게 조금 정신없어지기 시작했습니다.
00:42:18모든 것을 할 수 있다고 해서 모든 것을 해야 하는 건 아니라는,
00:42:21어떤 판단력을 가져오는 것이 LLM 시대의 태도와 아주 밀접하게 관련이 있다고 봅니다.
00:42:26무엇이 결과적으로 가치를 만들어낼지, 혹은 가치를 창출할 잠재력이 있는지에 대한,
00:42:31판단력을 갖추는 게 그 어느 때보다 중요합니다.
00:42:34에이전트와 함께 작업하다 보면 체크리스트를 하나씩 채워가는 만족감이 있거든요.
00:42:39가끔은 뇌가 멈춘 것 같은 기분이 들 때도 있습니다.
00:42:44그냥 목록을 훑어보면서 체크, 체크, 체크, 이렇게 해치우고 싶은 거죠.
00:42:48LLM을 사용하면 그런 만족감이 드는데, 대화를 시작하고 또 시작하고 또 시작해서,
00:42:53다섯, 여섯 개의 에이전트가 돌아가게 됩니다.
00:42:57그들은 모두 각자의 체크리스트를 하나씩 확인하고 있죠.
00:43:02맞아요. 맞아요. 맞아요. 맞아요. 네. 네. 그러니까, 음, 뭔가 그런,
00:43:06그런 만족감이나 즉각적인 보상과 관련된 뭔가가 있죠. 제 생각에는 때때로
00:43:11그게 우리를 휘두르기도 하는 것 같습니다. 적어도 제 경험으로는 말이죠.
00:43:15지금 팀 규모는 얼마나 되나요? 10명입니다. 우와, 정말 작군요. 대단하네요.
00:43:23제가 스스로를 최고의 관리자라고 생각하지 않아서, 다들 그게 더 편할 것 같아요.
00:43:29사실 우리는 코로나가 한창일 때 시작했으니까요. 모두가 원격 근무였죠.
00:43:33처음부터 아주 경험 많은 시니어급 인재들을 채용하자는 마인드였어요.
00:43:38아주 자율적인 사람들 위주로 말이죠.
00:43:45실감을 위해 말씀드리자면, 제품과 인프라에 대해 2주마다 한 번씩 짧게 회의를 하는 게 전부입니다.
00:43:50우리는 최대한 비동기적인 워크플로우를 유지하려고 노력합니다.
00:43:56그게 AI 사용 사례에도 잘 맞는다고 봐요. 우린 이미 그런 자율성을 가진 사람들을 채용했으니까요.
00:44:01뭐가 옳고 그르다고 말하려는 건 아니에요.
00:44:06우리가 하는 방식을 강요할 생각은 없지만, 우리에겐 효과적인 방식이죠.
00:44:11적어도 제 정신 건강에는 도움이 되니까요.
00:44:14대화 처음에 언급하셨던 '웹훅은 죽었고 새로운 방식은 이벤트 게이트웨이다'라는 말씀에 대해 더 듣고 싶네요.
00:44:21그 용어를 직접 만드신 건가요, 아니면 이미 어디선가 쓰이던 건가요? 이벤트 게이트웨이가 대체 뭔가요?
00:44:27전혀 감이 안 잡히네요.
00:44:32네, 우리가 만든 용어입니다. 정립되지 않은 제품 카테고리를 구축하는 건 꽤 어려운 일이죠.
00:44:37마케팅이나 소통, 그리고 이 제품을 어떻게 설명할지 같은 도전 과제들이 있거든요.
00:44:41한동안은 그냥 '웹훅 관리 인프라' 정도로 불렀죠.
00:44:46입에 착 붙는 이름은 아니었고요.
00:44:51소통도 문제지만 제품 자체의 도전도 있습니다.
00:44:54기존 카테고리에서 제품을 만들 때는 사람들이 무엇을 최적화하고 싶어 하는지 명확하거든요.
00:44:58예를 들어 가시성(observability)처럼 말이죠.
00:45:02가격 책정이나 개발자 경험 같은 것들이 USP(독보적인 판매 가치)가 되겠죠.
00:45:07중요한 건, 핵심 의미론(semantics)이 이미 존재한다는 겁니다.
00:45:10당신이 최적화하려는 독특한 가치 제안이 이미 있다는 거죠.
00:45:14하지만 존재하지 않는 영역에서 제품을 만들 때는, 의미론부터 새로 만들어내고 그 위에,
00:45:19설득력 있는 가치 제안까지 쌓아야 하니 정말 어렵죠.
00:45:24지난 몇 년간 배운 점인데, 새로운 카테고리를 만드는 건 정말 어렵습니다.
00:45:28이벤트 게이트웨이라는 이름은,
00:45:32최대한 기억하기 쉬운 단어로 제품의 기능을 나타내고자 고민 끝에 탄생했습니다.
00:45:37이벤트 버스와 API 게이트웨이 사이를 연결하는 다리가 되고 싶었거든요.
00:45:43게이트웨이가 벤더와 시스템 간의 인터페이스 역할을 한다는 점을 착안한 거죠.
00:45:49이벤트 버스는 본격적인 이벤트 관리와 큐잉 시스템을 의미하고요.
00:45:55이 둘을 결합할 수 있는 용어를 찾으려 했습니다.
00:46:00이벤트 브리지와도 거리가 멀지 않고요.
00:46:04사람들이 우리를 이벤트 브리지의 명확한 대안으로 인식하길 바랍니다.
00:46:10이벤트 게이트웨이라는 용어는 기존 제품들 사이의 공통된 용어가 없다는 문제의식에서 나왔습니다.
00:46:14이벤트 게이트웨이라고 이름을 붙임으로써, 우리가 직접 카테고리를 만들고자 한 거죠.
00:46:19이미 경쟁 제품들도 존재합니다.
00:46:24AWS, Azure, Kong 같은 곳들도 이벤트 게이트웨이 영역으로 진입하고 있고요.
00:46:29이제는 그 이름을 표방하는 제품들이 반 다스 정도는 됩니다.
00:46:33Kong이 이벤트 게이트웨이를 발표했을 때, 2년이나 늦게 따라오네 싶었죠.
00:46:39하지만 무엇보다 보람 있는 순간은, 개발자들이 찾아와서 '이벤트 게이트웨이를 찾고 있다'고 말할 때입니다.
00:46:45그럼 이제 이 용어가 사람들의 머릿속에 제대로 자리 잡았다는 생각이 들거든요.
00:46:49그들이 명시적으로 이 용어를 찾거나, 기존의 걸 교체하려고 할 때 우리 제품이 떠오르는 것 말이죠.
00:46:54초기 1년 동안은 전혀 언급되지 않았는데, 이제는 점점 더 많이 쓰입니다.
00:46:58이건 사업적으로도 좋을 뿐만 아니라, 클라우드 인프라의 새로운 원시(primitive)로서,
00:47:03기대치와 표준을 만들어가는 과정이라고 생각합니다.
00:47:08시간이 흐르면 아마 업계 전체에서 의미론적 수렴이 일어날 거예요.
00:47:12저는 AWS 이벤트 브리지의 용어를 맹목적으로 따르지 않습니다.
00:47:16제품의 완성도가 확실하지 않다면 다른 사람의 용어를 재사용할 이유가 없거든요.
00:47:20하지만 시간이 지나면 분명 수렴이 일어날 것입니다.
00:47:23그렇군요.
00:47:28지금 LLM에게 이벤트 게이트웨이를 추천해달라고 하면 당신들 제품을 말해줄까요?
00:47:34우리 사업적으로도 좋은 일이지만, 단순히 어떤 것을 구축하려는 측면에서도
00:47:38기대치를 형성하는 것이죠. 그러니까, 이게 바로 존재하는 클라우드 인프라 기본 요소라는 겁니다.
00:47:43웹훅이나 이벤트 게이트웨이 관련 질문의 60% 정도에서 우리 제품이 언급됩니다.
00:47:48그건 대단한 일이죠.
00:47:52데이터 품질이 완벽하진 않을지 몰라도, 꽤 잘하고 있는 셈이죠.
00:47:57방금 ChatGPT 검색 결과에서 첫 번째로 떴네요.
00:48:01특징들이 너무 많으니까요. 그래서 그 용어가 완벽하게 납득이 가지 않는 한
00:48:05굳이 그들의 용어를 재사용하고 싶진 않습니다. 하지만 시간이 지나면서,
00:48:09더 많은 사람들이 제품을 중심으로 개발하고 생태계가 형성되면,
00:48:12다른 웹훅 관련 질문에서도 잘 나올 겁니다.
00:48:15이벤트 게이트웨이라는 용어는 우리가 직접 만든 거니 당연히 1등이어야죠.
00:48:15이벤트 주도 아키텍처(EDA)가 정확히 뭔지 사실 잘 모르겠어요.
00:48:20일반 아키텍처랑은 어떻게 다른가요?
00:48:24지금 바로 해볼 수도 있겠네요.
00:48:25예, 그리고 아니오입니다.
00:48:27EDA는 일종의 패러다임이자 기대치입니다.
00:48:27물론 Kafka 같은 도구는 필요하지만, 그게 전부는 아닙니다.
00:48:31WebEx나 이벤트 게이트웨이 같은 것과 관련된 거의 모든 프롬프트에 저희가 언급되고 있죠.
00:48:35정말 멋지네요. 저희가 분명히 많은 시간을 투자한 부분이기도 하고요. 데이터 품질 측면에서
00:48:42그렇게 높지는 않을지 몰라도, 꽤 잘해내고 있거든요. 그래서,
00:48:46목록에서 첫 번째였어요.
00:48:48오, 좋네요.
00:48:49잘됐네요.
00:48:49방금 ChatGPT가 알려준 결과예요. 잘했네요.
00:48:52네. 하지만 이벤트 게이트웨이뿐만 아니라 WebEx 관련 쿼리도
00:48:56저희가 꽤 잘할 거라고 생각해요. 하지만 이벤트 게이트웨이는 확실히
00:49:00저희에게 유리한 면이 있어요. 왜냐면 저희가 그 용어를 만들었으니까요. 만약 저희가
00:49:03첫 번째가 아니라면 화가 날 것 같아요.
00:49:05사실 이제야 깨달았는데, 이벤트 기반 아키텍처가 정확히 뭔지 모르겠어요. 일반 아키텍처와는
00:49:11어떻게 다른가요? 만약 제 시스템에 Kafka 큐를 그냥 추가하면,
00:49:17그게 바로 이벤트 기반 아키텍처가 되는 건가요?
00:49:21맞기도 하고 아니기도 해요. 이벤트 기반 아키텍처라고 하면
00:49:25그와 관련된 일련의 패러다임과 기대치가 더 중요하거든요. 그래서 일부는
00:49:31도구가 맞아요. Kafka나 메시지 큐, 혹은 이벤트 스트리밍을
00:49:35사용해서 시스템을 분리하려는 의도니까요. 결국 핵심은
00:49:39생산자와 소비자가 있다는 것이고, 두 시스템은 서로를
00:49:43알 필요가 없다는 거죠. 소비자는 누구든 생성할 수 있는 이벤트 스트림으로부터
00:49:47데이터를 소비할 수 있어요. 그리고 여러분이 가지는 유일한 기대치는
00:49:53이벤트 자체에 대한 계약 같은 거예요. 페이로드는 무엇이고, 형태는 어떤지 말이죠.
00:49:57네. 그리고 종종 스키마가 있어요. 사람들이 특정 스키마를 사용하는 거죠.
00:50:02Avro 기반 스키마나 Protobuf 같은 것들이요. 그런 페이로드가
00:50:06어떠해야 하는지에 대해 표준화된 기대치가 존재하는 거죠. 결국 계약의 핵심은
00:50:11이러한 이벤트들이 존재한다는 것이고, 특정 시점에 이벤트가 발생하면 소비자로서
00:50:16주문 생성이나 상품 업데이트 같은 상황에서 해야 할 일을 하는 게 책임인 거죠.
00:50:21맞아요. 하지만 EDA를 진정으로 받아들인 조직을 보면, 일종의
00:50:25체계화된 패턴을 갖추고 있어요. 이를 어떻게 수행해야 하고,
00:50:29페이로드 형태가 어떠해야 하는지에 대한 구체적인 가이드라인이 있죠.
00:50:32의도적으로 서비스를 분리하고 통신을 이벤트 기반으로
00:50:36만드는 아키텍처 접근 방식을 취하는 거예요.
00:50:41많은 기업이 하이브리드 방식을 취하는 것 같아요. 일부는 이벤트 기반이고,
00:50:45그렇지 않은 부분도 있는 거죠. 목표가 100% 이벤트 기반이 되는 건가요?
00:50:50아니면 그저 아키텍처 패러다임의 일부인 건가요?
00:50:54100%는 아니라고 생각해요. 그냥 시간이 지나면서 성장하고 복잡성이 증가하면,
00:51:00외부 의존성이 더 많아지면서 자연스럽게 그렇게 흘러가는 거죠.
00:51:04왜냐면 어떤 시점에서는 모든 시스템을 결합해 두는 게 너무 힘들거든요.
00:51:09그러면 확장성이나 상호 의존성 같은 것들을 고려해야 하는데, 그게 꽤 어려워지죠.
00:51:14하지만 일반적으로 우리가 이벤트 기반 아키텍처라는 용어를 생각할 때,
00:51:19보통 사람들은 큰 엔터프라이즈를 떠올리는 것 같아요.
00:51:23지난 10년간은 주로 대기업에 집중되어 있었죠. 하지만 이제는
00:51:28변화하고 있어요. 사람들이 패턴에 익숙해졌고,
00:51:32WebEx 같은 것들이 일종의 진입 장벽을 낮춰주는 역할을 했거든요. 그리고 도구들도 더 좋아졌고요.
00:51:37RabbitMQ나 Redis 기반의 Bull MQ 같은 라이브러리들도 있고요.
00:51:41Python에는 Celery가 있고, Ruby에는 Sidekiq이 있죠.
00:51:46Sidekiq 개발자들이 만든 Foundation이라는 또 다른 것도 있더군요.
00:51:51아무튼, 점점 더 다루기 쉬운 도구들이 나오고 있어서,
00:51:57덜 위협적으로 느껴지게 되었죠. 이제는 거창한 아키텍처 팀이나
00:52:01비싼 비용이 드는 Kafka 배포가 없어도 이벤트 기반 아키텍처를 시작할 수 있게 됐죠.
00:52:05하지만 용어 자체는 원래 의미를 조금 잃어버린 것 같기도 해요. 제 말에 동의하지 않는 분들도 있겠지만요.
00:52:11시간이 흐르면서 그 의미가 좀 흐려졌거나, 무엇을 의미하는지 혼란스러워진 것 같아요.
00:52:15제가 말할 때 의도하는 것은 주로 시스템 분리예요.
00:52:19또한 엔지니어로서 고민해야 할 프로그래밍 측면에서의 우려사항들도 포함되죠.
00:52:25독립성이나 순서 등을 고려해야 한다는 점이죠. 그래서 제가
00:52:31이벤트 기반 아키텍처를 말할 때는, 이제 그런 고민들이 필요한 세상으로 진입했다는 뜻이에요.
00:52:37앱을 만들 때 이전에는 없었던 고민들을 하게 된다는 거죠.
00:52:43네, 이해했습니다. 그런 고민들을 해결하기 위해 개발 방식을 배우고 채택하는 것이 중요하군요.
00:52:48꼭 큰 엔터프라이즈 방식만을 의미하는 건 아니라고 생각해요.
00:52:52저희가 하는 일은 그런 것들을 모두에게 가져다주려는 시도이기도 하니까요.
00:52:58물론 저희만 그러는 건 아니고요. 다른 접근 방식을 취하는 사람들도 많죠.
00:53:03큰 기업 방식대로 하려는 건 아니고요. 우리도 일종의
00:53:08그런 가치를 모두에게 전달하려고 노력하는 셈이죠. 저희만
00:53:14그런 일을 하는 건 아니에요. 각기 다른 접근법을 취하는 곳들도 많거든요.
00:53:18워크플로우 엔진이나 스텝 펑션 같은 것들이 겹치기도 하고요.
00:53:22Temporal, Ingest, Trigger.dev 같은 곳들도 있죠. 그래서 이 분야는
00:53:28정말 많은 일이 벌어지고 있고, 딱히 고정된 정의는
00:53:34없어진 것 같아요. 이벤트 기반 아키텍처나
00:53:38그와 관련된 패러다임에 대해 더 알고 싶은 분들이 있다면,
00:53:42데이비드 보이안(David Boyan)이라는 분을 추천해요. 전 AWS 개발자 에반젤리스트였고
00:53:49EventBridge 관련 업무를 했죠. 그림으로 설명해주는 시리즈로 유명한데,
00:53:55지금은 아마 수백 개는 될 거예요. 'Event Catalog'라는 오픈 소스 프로젝트도 운영하고 있어서
00:54:02팟캐스트 게스트로 모셔도 좋을 것 같아요. 정말 깊이 있게 다루는데,
00:54:07그 깊이가 과할 정도죠. 관심 있는 분들에게 꼭 추천하고 싶어요.
00:54:14좋네요, 쇼 노트에 추가할게요. 이벤트나 웹훅에 대한 지식이
00:54:19상당하신데, 그냥 Hookdeck을 만들면서 다 습득하신 건가요?
00:54:23아까 웹훅 관련해서 문제가 좀 있었다고 하셨는데, 그때 깊게 파고드신 건가요?
00:54:27네, 아주 많이요. 문제 해결 과정에서 배운 것도 크지만, 원리 원칙적으로
00:54:34접근했어요. 당시에는 그 문제들에 대해 제가 아는 게 거의 없었거든요.
00:54:38그게 바로 제가 그 문제들을 겪고 있던 이유이기도 했죠. 그래서
00:54:42해결책을 먼저 정해두고 끼워 맞추기보다는, 문제 자체를 풀기 위해
00:54:47고민하면서 자연스럽게 알게 된 것 같아요. 결과적으로 지금은
00:54:51다양한 분야의 수십만 개 웹훅을 다루고 있으니까요.
00:54:55그러면서 대화를 통해 많이 흡수했죠. 정말 흥미로운 경험이었어요.
00:54:59저는 원래 프로덕트 디자이너로 시작했어요. 프로덕트 디자이너였다가,
00:55:05풀스택 개발자, 백엔드 엔지니어, 그리고 이제는 인프라 엔지니어까지,
00:55:11정말 깊은 굴 속으로 들어온 셈이죠. 고객들의 고민을 듣고,
00:55:15아키텍처를 검토하면서 배운 것들이 커요. 물론 뛰어난 경험을 가진 우리 팀원들도 한몫했고요.
00:55:21그들의 지식이 회사에 많은 도움이 되었거든요. 시장성을 언제
00:55:26확신하셨나요? 처음에 만들어서 어디 올렸을 때 바로 반응이 왔나요?
00:55:30아니면 사람들이 이게 더 나은 선택이라는 걸 알리기까지 시간이 좀 걸렸나요?
00:55:33천천히 퍼진 수준이 아니었어요. 말씀하신 대로 미디엄 글 하나로 시작했거든요.
00:55:38웹훅에 문제가 있고, 그에 대한 해결책이 있다는 글이었죠. 저는 원래
00:55:42사람들을 위한 제품을 만들자는 주의라서, 첫 버전도 셀프 서비스 형태였어요.
00:55:47직접 접속을 만들 수 있게 했죠. 비즈니스로 키울 야망 같은 건 없었어요.
00:55:53실패했던 스무 개의 사이드 프로젝트 중 하나였거든요. 지금 생각해보면
00:55:57숫자가 너무 보잘것없어 보이죠. 연락 온 사람이 다섯 명뿐이었으니까요.
00:56:01하지만 사이드 프로젝트를 해본 사람이라면, 다섯 명에게 사용해달라고
00:56:07설득하는 게 얼마나 어려운지 알 거예요. 저에겐 그 다섯 명이 대단했죠.
00:56:12정말 흥분됐어요. 그때 저는 브리티시 컬럼비아에서 캠핑카를 타며 암벽 등반 중이었거든요.
00:56:16스타트업 같은 건 꿈도 안 꿨죠. 그냥 그 다섯 명과 대화하면서
00:56:21그들이 겪는 문제를 이해하고 함께 고민하는 게 즐거웠어요.
00:56:26그러다 조금씩 가입자가 늘어났고, 암벽 등반 중에 슬랙 알람을 보면
00:56:32가입 알림 채널에 누군가 새로 등록했다는 소식이 뜨는 거예요.
00:56:376년째 운영 중인 그 채널은 지금 너무 빨리 올라가서 확인조차 어렵지만,
00:56:42그 당시엔 그 알람을 보고 정말 놀랐죠. “오 이런, 누가 가입했네!” 하면서요.
00:56:48설마 슬랙을 DDOS 공격하신 건 아니죠?
00:56:55아니요, 그땐 전혀 아니었죠. 지금은 잘 되고 있어서 가끔 생각나긴 하지만,
00:57:00DDOS 수준은 아니에요. 아무튼 초기의 핵심 가정은
00:57:05가시성 확보를 위한 도구라는 점이었는데, 그건 충분하지 않았어요.
00:57:08단순한 도구에서 메시지 버스를 재창조하는 것으로 관점을 바꾸자
00:57:13범위가 급격히 넓어졌어요. 첫 번째 큐 엔진을 만들 때 공동 창업자를 만났고,
00:57:18이 일이 생각보다 훨씬 큰 프로젝트가 되겠구나 싶었죠.
00:57:21그래서 엔젤 투자자들로부터 프리시드 투자를 받기로 했어요.
00:57:25꽤 큰 비용이 들 거라 예상했는데, 실제로도 비용이 많이 들었죠.
00:57:31실리콘밸리 방식이 아니라 몬트리올에서 시작하셨다고 들었어요.
00:57:38음, 사실 그건 조금 다르게 알려진 부분이 있어요. 엔젤 투자자들에게
00:57:4440만 달러 정도의 프리시드 투자를 받았고, 그 후 해커 뉴스(HN)에 올렸죠.
00:57:48최고의 반응은 아니었어도 기대 이상이었어요. 300달러짜리 플랜을 결제한
00:57:54사용자가 있었는데, 그걸 보고 공동 창업자랑 “우리 해냈다!”며
00:57:58샴페인을 터뜨리며 근사한 저녁을 먹으러 갔던 기억이 나네요.
00:58:02그 이후로 투자자들에게서 적극적인 제안이 많이 들어왔고,
00:58:08결국 실리콘밸리의 매트릭스 파트너스라는 곳에서 투자를 받았어요.
00:58:15캐나다 법인으로 남았고, 델라웨어 LLC로 바꾸지도 않았죠.
00:58:19투자자들은 정말 훌륭했고, 탁월한 선택이었다고 생각해요.
00:58:23코로나 이후로 원격 근무가 일반화되기도 했고요.
00:58:28자피어나 깃랩 같은 회사들이 이미 길을 닦아놓기도 했고요.
00:58:32캐나다 창업자 트위터에서는 델라웨어 법인 전환이 필수라는 얘기가 많은데,
00:58:36투자자들이 무조건 요구하니까요. 하지만 핵심은
00:58:39“아니요”라고 말할 수 있다는 겁니다.
00:58:44왜 안 하냐고 묻겠지만, 거절해도 괜찮더라고요. 경험상 그래요.
00:58:51결국 그들의 일은 자본을 배치하는 거고, 좋은 아이디어를 찾는 거니까요.
00:58:56델라웨어의 장점도 있겠지만, 선택은 창업자의 몫이죠.
00:59:00좋은 아이디어와 노력이 있다면 투자자들은 존중해줄 겁니다.
00:59:05기대 이상이었죠. 재미있는 일화가 있는데, 어떤 사람이 300달러짜리 플랜을 결제한 거예요.
00:59:11여전히 몬트리올에서 즐겁게 일하고 있습니다.
00:59:18같은 캐나다인으로서 성공 사례를 들으니 반갑네요.
00:59:22토론토로 이사해서 다 망치신 건 아니고요?
00:59:25하하, 같은 영연방이니 통하는 게 있네요. 왕도 같고요.
00:59:31여왕이 화폐에 있었는데, 지금은 국왕으로 바뀌었겠죠?
00:59:34정말 흥미로운 이야기들이네요.
00:59:38맞아요, 저희에겐 아직 여왕의 기억이 남아있죠.
00:59:44파트너스죠. 그래서 저희는 여전히 캐나다 회사로 중앙 집중식 팀을 유지하고 있어요. 아직
00:59:50델라웨어 LLC로 변경하지 않았거든요. 하지만 동시에 투자자분들이 정말 큰 도움을 주셨고
00:59:55그렇게 진행해서 정말 기쁩니다. 그리고 코로나19 상황 때문에도 그렇고
01:00:00어디에 기반을 두느냐보다 원격 팀을 꾸리는 것에 대한 수용도가
01:00:04많이 높아졌다고 봅니다. 이미 많은 사람들이 그렇게 하고 있었고요. 저희가 처음 시작한 건 아니죠.
01:00:08이미 재피어(Zapier)나
01:00:12깃랩(GitLab) 같은 회사들이 훨씬 전부터 그렇게 운영해 왔으니까요.
01:00:17그런 방식이 이제는 보편화된 것 같아요. 제 생각엔 제가 너무 순진한 건지 몰라도,
01:00:21일부 창업자분들에게서 그런 고민을 보곤 했는데요.
01:00:27캐나다 창업자들 사이에서는 델라웨어 법인 설립이나 트위터상의 캐나다 창업자 커뮤니티,
01:00:32그리고 YC에서 한때 캐나다 법인을 받지 않겠다고 했던 이슈 같은 것들이 큰 화제였거든요.
01:00:38결국 결정을 번복하긴 했지만, 마치 모든 투자자가
01:00:42델라웨어 LLC로 바꾸라고 요구할 거라는 인식이 있었죠. 그분들 말이 맞아요.
01:00:47모든 투자자가 다 그렇게 요구할 겁니다. 하지만 그 이야기에서 빠진 사실은, 그냥 “아니오”라고 거절할 수 있다는 점이에요.
01:00:54물론 투자자들은 “왜 안 되죠?”라고 묻겠죠. 그게 그들에겐 편하니까요.
01:00:58하지만 그냥 싫다고 해도 아무 문제 없더라고요. 적어도 제 경험이나
01:01:03제 주변 사람들의 사례를 보면 그래요. 그게 그 이야기에서 빠진 부분인 것 같습니다.
01:01:07결국 그들의 본업은 자본을 투자하는 것이고, 투자할 사람이나
01:01:11독창적인 아이디어를 찾고 있는 것이니까요.
01:01:15법인 위치의 장단점을 따지며 논쟁하고 싶지는 않아요. 분명 긍정적인 면도 많겠죠.
01:01:19하지만 결국 창업자이자 빌더로서 누구와 함께, 어디서 일을 할지는 본인의 선택이니까요.
01:01:24창업자이자 개발자로서 누구와, 또 어디에서 일할지는 여러분의 선택이니까요.
01:01:27좋은 아이디어가 있고 그만큼 노력한다면 투자자들도 여전히
01:01:31그 점을 존중해 줄 겁니다. 최소한 몇몇 투자자들은 분명히 존중해 줄 거예요. 맞아요.
01:01:36그러니 그런 사람을 찾는 게 여러분의 일이겠죠. 뭐, 우리가 그 거품에서 완전히
01:01:41벗어나 있다고 말하는 건 솔직하지 못한 것 같긴 하지만, 개인적으로 저는 여기서 삶의 기반을 다졌고
01:01:47지금도 몬트리올에 살고 있어서 꽤 만족합니다. 같은 캐나다인으로서 캐나다의 성공 사례를
01:01:52듣게 되어 기쁘네요. 축하합니다. 그런데 토론토로 이사 가더니 다 망쳐버렸잖아요.
01:01:57그건 뭐, 인정합니다. 같은 영연방 국가로서 좋지 않나요? 같은 왕을 모시잖아요.
01:02:06똑같죠, 그렇죠? 네. 우리가 여전히 여왕을 모시고 있나 모르겠네요.
01:02:11이제 왕으로 바뀌었는지 모르겠지만, 지폐에는 여왕이 있었거든요.
01:02:14훅덱(Hookdeck)이 창업자로서 처음 시작한 스타트업이었나요, 아니면 투자자를 만나고
01:02:19찾는 방법을 배울 수 있었던 다른 여정들이 있었나요? 저는 원래
01:02:23처음부터 사업가 기질이 있었어요. 작은 회사에서 일하거나, 14~15살 때부터
01:02:27은퇴자들의 컴퓨터를 수리해 주는 식이었죠. 음, 그래서 그런
01:02:34기업가 정신에 대해서는 이야기할 수 있겠지만, 사실 대부분은
01:02:38실패한 프로젝트들이었어요. 예를 들면 어디서 빛도 보지 못한 비디오 게임을 출시한다거나,
01:02:44한때는 소셜 네트워크를 만들어 보기도 했죠. 저처럼 사교 모임을 제일 싫어하고
01:02:48친구들과 무언가를 조직하는 데 소질이 없는 사람이 말이에요. 어쨌든 우여곡절을 겪었죠.
01:02:53그래도 말씀드리자면, 이커머스 회사에서의 경험은 꽤나 큰 도움이 됐어요.
01:02:58그곳에 첫 직원으로 들어가 창업 팀과 깊게 관여했었거든요.
01:03:03저희는 3년 만에 4명에서 40명 규모로 성장했어요.
01:03:07사업을 구축하는 모든 과정과 관련된 경험을 할 수 있었죠.
01:03:13그런 면에서 훅덱이 제 첫 창업이라 생각하지만, 그전까지 아무런
01:03:19경험이 없었다고 하면 거짓말이겠죠. 어느 정도 노출은 있었으니까요.
01:03:23분명 그전에도 투자자들과 일하며 이사회와 관계를 맺는 법 등을 배웠고,
01:03:27그 이커머스 회사의 첫 번째 투자자가 훅덱의 초기 투자자이기도 했거든요.
01:03:31그래서 맨땅에 헤딩하는 것과는 거리가 있었지만,
01:03:36어쨌든 몇 년 전까지만 해도 제가 이 자리에 있을 줄은 몰랐죠. 정말 좋습니다.
01:03:39키위 모닝스(Kiwi Mornings)라는 건강한 아침 식사 스타트업을 운영하셨던데, 어떤 내용인가요?
01:03:44그것도 실패한 사업 중 하나였죠.
01:03:48아내와 함께 시작했는데, 아내가 직장에 아침을 챙겨갔더니 동료들이 다들 부러워하며
01:03:54자기도 달라고 했대요. 영업팀 사람들이 왜 아침밥을 아내한테 조르냐고요.
01:04:02그렇게 아내가 매일 아침 5~6인분의 아침을 만들게 됐고, 그러다 이게 사업이 되지 않을까?
01:04:09하는 다소 엉뚱한 생각을 한 거죠.
01:04:14그래서 사무실용 제로 웨이스트 아침 식사 배달 서비스를 만들었어요.
01:04:19요거트나 스무디, 치아 푸딩 같은 걸 유리병에 담아 사무실 냉장고에 채워두는 거였죠.
01:04:24저답게 일을 너무 크게 벌려서, 슬랙 봇을 통해 주문을 받고,
01:04:30회사가 아침 식사 비용의 50%를 직원 복지로 지원하는 구조를 만들었어요.
01:04:36그런데 결국 실패로 끝났습니다. 새벽 4시에 모든 일이 잘못되기 일쑤였고,
01:04:41음식 장사는 돈이 안 된다는 걸 깨달았죠. 이 두 가지가 합쳐지니
01:04:47지속 가능한 사업을 하기가 정말 어렵더라고요. 결국 슬랙 봇만 매각하고 사업을 정리했습니다.
01:04:51다행히 그게 2021년 1월이었어요. 코로나 터지기 두 달 전이었죠.
01:04:56당시 오피스 점심 식사를 제공하던 거의 모든 회사가 문을 닫았거든요.
01:05:01타이밍 덕분에 조금 운이 좋았던 셈이죠. 어차피 망할 운명이었으니까요.
01:05:06그래도 총 2만 개 정도의 아침 식사를 팔았으니 괜찮은 경험이었어요.
01:05:11아주 멋지네요.
01:05:16항상 게스트분들께 묻는 질문인데, 업계나 AI에 대해 아주 뜨거운 의견(Hot take)이 있다면 말씀해 주세요.
01:05:20벌써 몇 가지 말씀드린 것 같은데요. 정말 불타오르는 의견을 듣고 싶어요.
01:05:25불타오르는 거요? 좋습니다. 아마 이 부분에서 의견이 갈릴 수도 있겠네요.
01:05:29아키텍처 설계와 관련된 아주 기술적인 내용이니까요. 청취자분들 중 일부는 이해하실 겁니다.
01:05:34제 아주 뜨거운 의견은, '풀(Pull) 방식의 소비자나 큐 시스템은 푸시(Push) 방식보다 매우 멍청하다'는 겁니다.
01:05:42우리가 푸시 방식을 채택하지 않은 이유는 제대로 된 푸시 시스템을 구축한 큐가 없기 때문입니다.
01:05:46배경을 설명하자면, 큐를 만들 때마다 소비자를 하나씩 붙여야 하죠.
01:05:52그런데 고객별로 큐를 나누고 싶어지면 문제는 복잡해집니다.
01:05:57한 고객이 큐를 독점하지 못하게 하려면 말이죠. 그러면 큐만큼 소비자가 필요해지는데,
01:06:01이 멀티플렉싱 문제가 엄청나게 복잡해지죠.
01:06:06푸시 기반 시스템의 큰 장점은 모든 큐가 하나의 소비자에게 푸시할 수 있다는 점이에요.
01:06:12로드 밸런서 뒤에 있는 API가 그 역할을 할 수 있고, 가로 세로 확장이 가능하죠.
01:06:18즉, 얼마나 많은 큐가 있는지와는 완전히 독립적으로 구축할 수 있다는 겁니다.
01:06:22복잡한 사용 사례로 갈수록 큐를 나눌 조건은 점점 더 세분화됩니다.
01:06:29토픽별, 고객별로 큐를 나누다 보면 큐 100개, 소비자 100개가 되는 난장판이 벌어지죠.
01:06:35하지만 푸시 기반 메시지 큐를 찾기는 여전히 어렵습니다.
01:06:42처리량(throughput)을 어디서 제어하느냐의 문제 때문이죠.
01:06:49소비자가 초당 50개 메시지를 처리하고 싶다고 할 때, 실제 용량은 워커의 성능과 숫자에 달려있거든요.
01:06:56나머지 코드의 속도에 따라 다르기 때문에 단순히 50개라고 말한다고 되는 게 아닙니다.
01:07:02많은 시스템이 처리량을 세밀하게 제어할 수 있는 기능을 제공하지 않아요.
01:07:07예를 들어 GCP Pub/Sub은 푸시 모드가 있지만, API가 느려질 때까지 전송 속도를 높였다가,
01:07:12성능이 저하되면 다시 속도를 줄이는 식이죠.
01:07:16그러다 보니 시스템이 크리프(creeps) 현상처럼 성능 저하가 오고, 0으로 떨어졌다가 다시 올라가는,
01:07:21완전히 엉망인 패턴이 반복됩니다. 말이 안 되죠.
01:07:26처리량과 소비 속도를 아주 정교하게 제어할 수 있는 푸시 기반 큐를 만든다면
01:07:31아키텍처가 훨씬 단순해질 겁니다. 이게 제가 걸고 넘어가려는 고집스러운 생각입니다.
01:07:36다 이해하지는 못했지만 그럴듯하게 들리네요.
01:07:41그 내용을 이해하신 분들은 훅덱을 꼭 확인해 보세요.
01:07:45정확합니다.
01:07:49감사합니다. 지금까지 베터 스택(Better Stack) 팟캐스트였습니다.
01:07:54스포티파이, 애플 뮤직 등 어디서든 저희를 찾아주세요.
01:07:58조건별, 고객별로 큐를 나누는 식이죠. 그러다 보면 상황이 완전히 엉망이 됩니다.
01:08:02큐가 100개, 컨슈머도 100개, 데드 레터 큐까지... 그에 따른 복잡함은 이루 말할 수 없죠.
01:08:07하지만 요즘은 푸시 기반 메시지 큐를 찾기가 매우 어렵습니다.
01:08:13그 이유는 처리량(throughput) 제어 방식이 바뀌기 때문입니다. 만약
01:08:17컨슈머 쪽에서 처리량을 제어한다면, 각 컨슈머는 직접 요청해야 하죠.
01:08:22초당 50개의 메시지를 처리하겠다거나, 동시성 수준을 정하는 식입니다. 그러면 얼마나 소비할지는
01:08:29워커의 용량에 따라 달라집니다. 워커는 몇 개나 있는지, 그리고 실제
01:08:33유효 용량은 얼마인지가 중요하죠. 초당 50개 처리를 원한다고 해서 그대로 되는 게 아닙니다.
01:08:37나머지 코드들이 충분히 빠른지에 따라 실제 처리 속도는 달라지니까요.
01:08:40맞아요. 우리가 푸시 기반 큐로 넘어가지 못한 이유는 대부분의 서비스가
01:08:45필요한 수준의 처리량 제어를 제공하지 못하기 때문이라고 봅니다. 예를 들자면,
01:08:50GCP Pub/Sub은 푸시 모드가 있지만, 요청 속도를 계속 높이다가
01:08:55API가 느려지기 시작할 때까지 밀어붙입니다. 그 시점이 되면 이미 서비스는
01:09:00성능이 저하된 상태죠. 성능이 떨어지기 시작하면 그때야 전달 속도를 줄입니다.
01:09:06결국 속도가 계속 올라가다가 서버가 죽거나 성능이 크게 저하되고,
01:09:11그럼 다시 0으로 줄었다가, 다시 속도를 올리고, 또 올리고,
01:09:15다시 0으로 돌아가길 반복하죠. 정말 말이 안 되는 방식입니다. 제 생각에는,
01:09:20처리량과 소비 속도를 정밀하게 제어할 수 있는 푸시 기반 메시지 큐를 구축하면
01:09:24아키텍처가 정말 단순해질 겁니다. 이게 제가 생각하는 핵심이고,
01:09:29어... 저는 이 신념을 끝까지 밀고 나갈 생각입니다.
01:09:34무슨 말인지 완전히 이해한 건 아니지만, 들어보니 타당한 말이네요.
01:09:40이해되셨다면 'Hookdeck'을 확인해보세요. 바로 그거죠.
01:09:46좋은 정보 감사합니다. 네, Alex 님 감사합니다. 'Better Stack Podcast'를
01:09:50청취해주셔서 감사합니다. Spotify, Apple Music 등 팟캐스트를 들으시는 곳이라면 어디서든 저희를 찾으실 수 있습니다.
01:09:57오늘은 여기서 작별 인사를 드립니다. 다들 안녕히 계세요. 안녕히 계세요. 안녕히 계세요.