안녕하세요, 여러분.00:09

다들 잘 지내시나요? 와!00:14

혹시 더 많은 루프를 할 준비 되셨나요? 네!00:17

제 이름은 로랑입니다. 저와 공동 창업자는 'XAI'라는 신화적인 곳에서 에이전트 개발에 열심히 매달렸었습니다.00:22

인프라 쪽을 담당하고 있었는데, 독립적으로 해결해야 할 새로운 문제가 있다는 것을 깨닫고 몇 달 전에 회사를 떠나서 다음 단계가 어떻게 될지 진지하게 고민하기 시작했습니다.00:29

어떻게 배포해야 하는지에 대해 정말로 파악하려고 했어요.00:36

항상 실행되고, 장기간 진행되며, 미래를 내다보는 작업들이 있습니다.00:42

그리고 발표해 드릴 만한 몇 가지 결과들을 얻게 되어 기쁩니다.00:46

그리고 이번 발표는 고객님들과 함께 확장해 나갈 수 있는 방식으로 이러한 아이디어를 제품화하는 방법에 대한 내용입니다.00:52

고객님의 규모에 맞춰 확장 가능한 방식으로 이 아이디어들을 제품으로 만드는 방법에 대해 말씀드리겠습니다.00:56

자동 연구에 대해 많이 들어보셨을 거예요. 저희는 2026년 이후를 위한 청사진이 있다고 생각합니다.01:01

자동 연구에 대해 어떻게 생각해야 하는지에 대한 방법입니다.01:07

결국 세 가지 핵심 아이디어로 귀결됩니다. 첫 번째에 대해 알아볼까요?01:11

루프가 제품입니다.01:15

이것은 우리 모두에게 익숙하죠. 모델의 경우, 모든 것이 RLHF로 귀결되고 어떻게01:21

모델을 더 나은 추론 능력을 갖도록 학습시켜야 한다는 점으로 빠르게 전환되었습니다. 그리고 나서 하니스(harness)를 사용하게 되었죠.01:28

그리고 모델이 상품화되었고, 하니스에 모든 것이 달려있다는 것을 말씀드리고 있습니다.01:33

이제 루프에 대해 이야기하고 있는데, 이러한 루프를 어떻게 구축해야 하고 더 이상 코드를 수정하지 않아야 한다는 내용입니다. 하지만 무엇을 말씀하시는 거죠?01:37

정확히 무슨 뜻인지 궁금하고, 왜 모두 그렇게 말하는지 아시나요? 혹시 클로봇 기억하시나요?01:44

그게 바로...01:49

현재 오픈클로(OpenClaw)라고 알려진 것의 원래 이름이었고, 이 분,01:51

에이제이(AJ) 님이 처음으로 클로봇(ClawBot)을 활용한 루프를 만들었습니다.01:58

그가 했던 일은 자동차를 더 저렴하게 구매하기 위해 판매자들과 소통하고 레딧 사용자들에게 정보를 얻는 방법을 찾는 것이었습니다.02:02

그는 이 네 단계를 따랐고, 그는...02:08

정말로 오픈클로였어요, 그걸 직접 하신 분이요. 레딧에서 가격을 찾아보고 재고를 확인하고, 딜러들과 이야기를 나누셨죠.02:15

딜러들에게 연락하는 거죠.02:22

딜러들을 서로 경쟁하게 만들어서, 어떻게 서로 가격을 높이게 할 수 있는지 알아내려고 하세요.02:25

가격이 어느 정도인지 확인할 수 있는 확실한 방법이 있어야 합니다.02:31

맞아요, 그리고 가격을 고정해서 차를 얻는 거죠.02:34

그리고 그렇게 됐어요.02:38

아마 이 시기가 모든 맥 미니를 다 팔던 때였을 거예요.02:40

하지만 이것이 루프가 제품 자체가 되는 첫 번째 실제 사례였습니다.02:42

그리고 이쯤 되면 스타트업으로 시작해야 할 만한 아이디어였을지도 모르지만, 저희는 이것이 어떻게 발전해왔는지 보았습니다.02:50

모두가 루프를 구축할 수 있는 레시피가 되었죠. 하지만 잠시 뒤로 돌아가 보겠습니다.02:56

왜 여기 오게 되었나요?03:01

저희는 모델들이 이 루프를 염두에 두고 학습되었을 거라고 생각하며, 이는 OODA 루프라는 개념에서 비롯된 것 같습니다.03:03

이 용어는 미국에서 1970년대에 처음 만들어졌습니다.03:10

미국 공군에서 전투기가 빠르게 변화하는 환경에 어떻게 대응해야 하는지에 대한 개념입니다.03:15

도구들을 호출하고 관찰을 수행하는 모델이라고 생각하신다면요, 03:23

사람으로서 그리고 이제 에이전트로서 우리가 학습해온 방식과 같습니다.03:29

신호입니다. 이제 강한 신호와 검증 가능한 작업을 다른 쪽 끝에 놓았을 때 어떤 일이 발생하는지 살펴보겠습니다.03:33

반대쪽에 두면 어떻게 될까요?03:41

이러한 작업자나 클라우드 코드 에이전트에 도달하게 되는데, 여기서 중요한 것은요.03:41

검증자의 품질이 중요합니다.03:48

신호가 루프의 성공률과 검증기의 품질을 결정합니다.03:49

성공이 실제로 정확한 것인지 검증기가 판단할 수 있습니다.03:57

하지만 여기 또 다른 루프가 있습니다. 그 내용을 신호에 다시 넣으면 어떻게 될까요?04:03

이것이 바로 루핑의 의미입니다.04:10

핵심은 첫 번째 루프의 끝에서 이러한 아티팩트를 어떻게 생성하는가 하는 것입니다.04:12

그 다음 두 번째 루프를 실행하고 지속적으로 개선할 수 있는 방법을 갖는 것인데요.04:18

그리고 이것은 제 두 번째 포인트 시스템 증류 방식과 관련이 있습니다. 즉, 모드와 실제로 관련이 있다는 뜻입니다.04:23

정말로 가능성을 의미합니다.04:25

첫 번째 루프에서 무엇이 잘 되었고 잘못되었는지 이해하고, 두 번째 루프에서 어떻게 처리할지 알아야 합니다.04:31

그걸 바탕으로 어떻게 조정해야 할까요?04:38

각 루프는 하니스, 프로필, 평가, 모델, 리소스, 도구 및 환경에 대한 유용한 정보를 생성합니다.04:42

이러한 정보들은 모두 활용할 수 있는 자료입니다.04:48

정말로 원하시는 건 이런 걸 계속 휴대할 수 있는 방법이 있고, 버전 관리하고04:51

시간에 따라 진화시킬 수 있는 방법을 갖는 것입니다.04:58

연구에서 데이터 레시피라고 생각해보신다면, 이것이 강화 학습이 잘 작동하기 시작한 방식입니다.05:00

레시피를 이해하고 지속적으로 레시피를 변경하는 방법을 이해하게 되었습니다.05:08

환각이나 보상과 관련된 일부 행동들을 막기 위한 레시피라고 할 수 있습니다.05:13

그러면 최종 데이터 레시피가 되는 스택에 도달하게 됩니다.05:18

하네스에는 그런 게 없고요. 일반적인 인공지능 시스템에도 그런 건 없습니다.05:22

그래서 저희는 그러한 무언가가 필요하다고 생각했습니다. 평가 항목들을 포함하는, 말이죠.05:28

초기에는 미리 정해지지 않은 수정 사항이나 인간의 판단, 이런 모든 것들을 포함합니다.05:33

하지만 에이전트가 환경에서 활동하면서 더 많은 것을 배우게 되면, 이러한 요소들이 정의됩니다.05:38

저희는 레시피를 이것에 적용할 수 있을 것 같고, 같은 이름을 사용하는 것이 좋다고 생각합니다.05:47

에이전트의 레시피는 실제로 재현 가능한 선두 AI 시스템을 구축할 수 있도록 해주는 것을 의미합니다.05:51

시간이 지날수록 더욱 강화되는 경쟁 우위를 확보할 수 있게 해주는 것이죠, 그리고05:58

특정 플랫폼이나 제공업체에 종속되지 않습니다.06:05

그것은 여러분이 통제하고, 회사 내부에 존재하며, 사용하시는 모델과 제공업체에 구애받지 않는 것입니다.06:07

그리고 루프는 이러한 점에 집중해야 합니다.06:14

루프는 시스템을 레시피로 추출하는 방법이 되어야 합니다.06:18

실패 패턴은 판단 기준과 평가가 되고, 반복적인 행동은 기술과 프롬프트가 되어야 합니다.06:22

사용자 불만 사항, 확장 기능, 그리고 기억 장치 같은 것들이 모두 포함됩니다. 06:27

이런 상황은 익숙하시겠지만, 이를 어떻게 생각하고 정의해야 할지에 대한 적절한 용어가 없었습니다.06:32

그리고 저희는 레시피가 모든 것을 하나로 모아 깃(Git) 저장소에 넣고, 지속적인 전략으로 관리하는 방법이라고 생각합니다.06:39

모든 것을 함께 깃(Git) 저장소에 넣어 지속적인 전략으로 취급할 수 있는 방법이라고 생각합니다.06:44

이러한 스스로 개선되는 시스템을 구축하기 위해서입니다. 그래서 저희는 내부를 살펴보고 계신데, 이를 다음과 같이 생각하실 수 있습니다.06:51

인트로스펙션은 이러한 레시피를 생성하는 방법이라고 생각하시면 됩니다. 따라서 레시피는...06:58

시스템을 내부적으로 검토하면서, 저희는 이식 가능하고 서비스 제공업체에 구애받지 않는 무언가를 만들고 싶었습니다. 그래서 레시피 접근 방식을 파이(pie) 기반으로 구축했습니다.07:02

저희의 접근 방식은 레시피를 기반으로 하고 있습니다.07:07

평가들을 위해 하네스(harness)과 하버(harbor)를 활용했고, Git 저장소에 통합했습니다.07:14

그래서 모든 것을 버전 관리할 수 있고, 에이전트들이 이러한 변경 사항을 지속적으로 추적할 수 있는 방법을 제공하게 되었습니다.07:21

왜 그렇게 되어야 하는지, 그리고 여러분이 소유하지만 에이전트들이 관리해야 하는 이유는 바로 이것입니다.07:27

앞으로 제품을 개발하는 방식은 이러한 점을 고려해야 합니다.07:32

거의 모든 것, 즉 더 높은 수준의 취향이나 개성을 가진 사람에게 소유권이 있다는 의미입니다.07:36

하지만 에이전트들은 방 안의 취향에 맞춰 스스로를 조정하려고 노력해야 합니다.07:44

제작자이므로, 레시피는 제작자의 취향을 코딩하는 방식으로 구축되어야 한다고 생각합니다.07:49

다른 사람의 것을 사용하고 싶다면요.07:54

레시피라면, 저도 그 맛을 재현할 수 있어야 합니다. 단순히 하니스나 모델 자체가 아니에요. 어떻게 이 특정 레시피에 도달하게 되었는지, 그리고 왜 그렇게 했는지에 대한 과정이 중요합니다.07:58

그 레시피를 통해 그 맛을 따라 할 수 있어야 하고요. 단순히 장비나 모델뿐만 아니라, 어떻게 이 레시피를 만들게 되었고, 그 이유는 무엇인지도 중요합니다.08:03

그리고 그것이 바로 재현 가능한 제품과 서비스의 핵심에 자리 잡고 있습니다.08:07

종종 그렇습니다.08:09

에이전트들을 중심으로 하고 있습니다. 초기 버전의 레시피가 있는데, 'pie.recipes'라고 불립니다. 이전의 스킬즈와 매우 유사하지만, 한 단계 더 발전했습니다.08:16

기존 2025년도의 스킬즈와 비슷하지만, 더욱 발전된 형태입니다.08:22

그리고 프론티어 에이전트를 만들기 위해 무엇이 필요할까요?08:28

평가에 붙여넣는 방식으로 모든 것을 코딩해야 할까요?08:32

어떻게 평가를 실행하나요? 시간이 지남에 따라 평가를 지속적으로 개선하기 위한 루프는 어떻게 구성해야 할까요?08:35

어떻게 신호를 처리하고 어떤 신호가 적절한지 판단할 수 있을까요?08:40

어떤 도구들이 특정 모델과 함께 작업하는 데 적합할까요? 그리고 하니스를 통해 다양한 모델을 다루기 위한 여러 프로필은 어떻게 설정해야 할까요?08:45

그리고 그 중간의 모든 부분들도요. 중간에, 여기에서 저희가 구축해온 내용을 살펴보세요.08:52

아직 초기 단계이지만, 부디08:57

여러분께서 시작하시는 데 도움이 될 만큼 유용하기를 바라며, 저희는 이것이 무언가로 발전할 것이라고 생각합니다.09:00

다양한 제작자의 레시피를 에이전트의 맛처럼 활용할 수 있도록 정말 유용하게 만들어 드립니다.09:05

다른 제작자들의 레시피를 여러분의 에이전트에 적용하실 수 있습니다.09:12

마지막으로 말씀드릴 부분은 와트당 성능입니다. 왜 이것이 점수가 되는 걸까요?09:18

커서와 인지 기능 팀이 최고의 제품을 만드는 것에서부터 시작해서...09:23

제품을 위한 최고의 평가를 구축하고, 이전 두 가지 결과물을 바탕으로 최고의 모델을 구축하는 것을 의미합니다.09:31

앞으로 모든 일에 적용될 수 있는 레시피라고 생각합니다.09:36

코딩 분야에서 이것이 처음으로 성공을 거둔 영역이었습니다.09:41

고객 지원, 법무, 연구 등 모든 것을 넘어섭니다.09:45

이 아이디어로 귀결될 것 같습니다. 와트당 얼마나 많은 가치를 얻고 있는지 측정하는 것이 중요합니다.09:51

어떻게 측정해야 할까요?09:54

가장 중요한 것은 가치이고, 그 가치를 얻고 있는지 어떻게 알 수 있느냐가 다음 단계입니다.09:57

두 번째라고 할 수 있습니다. 아마 이 설명을 통해 조금 더 명확해지실 겁니다.10:02

저희 모두 기본 상태에서 시작했어요.10:06

기본 평가 지표들을 활용해서 프론티어로 나아갔습니다.10:09

그 과정을 거쳐야 하는 이유는 이 시스템들을 실제 운영 환경에서 실행해야 하기 때문입니다.10:14

프론티어(Frontier)가 무엇인지 알 수 있는 방법은 실제로 운영해 보는 것밖에 없습니다.10:17

시작입니다. 하지만 여기서 마지막 단계는, 많은 연구가 필요한 부분인데,10:21

좋습니다. 프론티어에 도달했다면, 어떻게 경제적으로 타당하게 만들 수 있을까요?10:29

즉, 이 정도의 가치를 창출하는 데 필요한 것보다 더 많은 돈을 쓰지 않도록 하는 방법은 무엇인가요?10:35

그리고 저희는 그 방법을 가지고 있다고 생각합니다.10:40

이제 접근 가능하게 하고 효율적으로 만들 수 있는 기본 구성 요소를 갖추고 있습니다.10:43

미세 조정 API나 인프라를 보신 것처럼요.10:47

이 과정을 진행하실 수 있도록 그 부분들이 추상화되어 있습니다.10:52

아직은 없는 노하우이고, 저희가 이 부분을 발전시켜 나가고 싶습니다.10:55

평가(evals)에 맛을 코딩하고, 실험을 통해 그것을 검증하는 노하우는 아직 존재하지 않습니다.11:02

이전에도 평가(evals)와 실험에 대해 많이 들어보셨을 겁니다.11:07

진짜로 그들을 어떤 건지 생각해보신 적은 없으세요? 그냥 테스트가 아니라, 창작자의 '맛'이 무엇인지에 대한 고민이에요.11:12

에이전트가 재현하고 스스로 발전시켜 나갈 수 있는 창작자의 취향이나 개성을 의미합니다.11:18

그리고 이걸 얼마나 쉽게 이동할 수 있도록 만들지 고민한 사람은 아무도 없었어요.11:24

제가 아티스트로서 또는 소프트웨어 개발자로서 느끼는 감각을 누구나 따라 할 수 있게 만드는 방법은 무엇일까요?11:29

그 사람이 제 머릿속에 다운로드받아서 저와 완전히 똑같은 복제품이 될 수 있을까요?11:35

그리고 이것은 현재 강화 학습(RL)이 다루는 내용과 일맥상통합니다. 즉, 저희는 이 트렌드 세터를 어떻게 활용할 수 있을까요?11:39

환경과 평가들을 만들어서 그 안으로 통합하고, 그걸로 가중치에 반영할 수 있도록 하는 거죠.11:47

하지만 그것뿐만이 아닙니다.11:53

작업자를 내부 루프로 생각할 수 있고, 이 작업자가 모든 결과물을 생성하지만, 그 결과물을 어떻게 보고 무엇을 바꿔야 할지 아는 것이 취향입니다.11:55

결과물을 보고 무엇을 수정해야 하는지를 결정하는 것이 바로 취향이라고 할 수 있습니다.12:02

그리고 이것이 무엇을 변경해야 하는 후보를 만들고, 어떻게 적용해야 할지를 결정하는 과정입니다.12:05

어떻게 적응해야 하는지, 그리고 실험을 통해 스스로 학습해 나가는 방식입니다.12:10

그 점을 조정해 보세요. 제 취향은 실제로 프로덕션 환경에서 사용자들을 통해 검증되고 있습니다.12:14

그리고 오프라인 평가를 통해서 제작자뿐만 아니라 사용자도 만족하는지 확인하고 있습니다.12:18

사용자분들도 만족하시고, 저희가 좋은이라고 생각하는 것에 동의해 주시는 평가들을 진행합니다.12:24

실제로 어떻게 작동하는지 보여드리는 예시를 하나 살펴볼까요.12:30

기준 에이전트, 예를 들어 인재 소싱 에이전트를 한번 살펴볼까요?12:35

이것은 매우 전형적인 경우의 예시입니다.12:41

모두가 채용을 다르게 진행하고 있고, 좋은 채용이라는 것이 무엇보다 중요한 게 아니라, 채용을 잘한다고 생각하는 리더가 누구인지가 중요합니다.12:45

채용을 좋다고 판단하는 리더십이 더 중요하다는 의미입니다.12:52

그래서 이 경우에는 간단한 것부터 시작합니다.12:57

웹 검색이나 링크드인 같은 다양한 도구와 하위 에이전트들을 활용하는 거죠.12:58

코덱이나 코드, 시스템 지시사항과 같은 도구들에 의해 이미 널리 알려진 것들이 있습니다.13:04

채용 담당자가 가장 먼저 알아야 할 사항입니다.13:11

다음 단계는 신호를 정말 잘 이해하는 것입니다. 패턴을 분석하는 방법이라고 생각하실 수 있습니다.13:15

흔히 발생하는 행동이나 사용자들의 불만을 파악하기 위해 로그를 살펴보는 방식으로 볼 수도 있습니다.13:20

그리고13:27

그것들을 클러스터로 묶는 거죠. 에이전트가 아이디어를 내고 연락을 취하는 것과 같은 방식으로요.13:27

채용 담당자로서, 대기업 직원들을 많이 채용하는 건 원하시는 바가 아닐 겁니다. 숨겨진 보석을 찾는 것이 중요하고, 존 카맥 같은 분을 직접 고용하려고 노력하기보다는 에이전트가13:34

그런 역할을 할 수 있습니다.13:38

존 Carmack은 정말 대단한 분이죠, 왜 연락을 안 할 이유가 없잖아요.13:44

이건 코딩할 생각조차 안 들 정도로 자연스럽게 발견되는 행동입니다.13:49

에이전트가 그런 경향을 보이는 것, 바로 그 패턴에서 신호를 발견하고 알려주는 방식이죠.13:54

다음에는 무엇을 해야 할지 안내해 주는 것이죠.14:01

교정(Calibration), 평가자(judges), 그리고 평가(evals)는 우리가 어떻게 이러한 행동들을 규정화해야 할지 생각했던 방식입니다.14:05

이를 여러 추적 결과와 실행 과정에 걸쳐 동일한 판단을 적용할 수 있도록 하는 것입니다.14:11

자, 경로를 분석해서 정확히 그런 패턴을 식별하는 에이전트를 만든다고 가정해 보겠습니다.14:18

예를 들어, 이 에이전트가 숨겨진 정보를 찾으려고 하기보다 구글 직원에게 연락을 시도했나요?14:25

깃허브에서 숨겨진 보석들을 찾는 것과 교정 및 평가 생성 부분은 그렇게 어렵지 않습니다.14:31

에이전트가 구축할 수 있을 거예요. 사람의 개입을 통해 '이것'이라고 말해주는 정도면 충분합니다.14:38

저희가 취하고 있는 접근 방식입니다. 그렇게 판단하시는지 동의하시나요?14:44

정말로 그렇게 판단하는 것에 동의하시나요?14:48

대기업 직원보다는 숨겨진 인재를 더 찾아보는 게 좋을까요?14:50

거의 다 됐습니다. 평가 시스템을 실제로 구축할 때 인간의 도움이 필요하지 않습니다.14:57

평가 데이터를 보정하는 데 필요하고, 에이전트들이 제작자의 의도를 파악해서 코드로 옮기는 역할을 해야 합니다.15:01

이렇게 되면 레시피를 만드는 것이 상당히 쉬워집니다.15:07

후보군들을 말씀드리는 건데요, 이게 바로 여러분이 맛을 보고 싶어하는 차이점들입니다.15:13

그리고 그것을 가지고 계실 수 있습니다.15:16

이 근처에 꽤 괜찮은 오프라인 평가 데이터 세트가 있지만, 실제 서비스에서 테스트할 때가 중요합니다.15:20

그렇다면 최종 사용자가 큰 규모의 것을 건너뛰는 여러분의 취향에 동의하나요?15:25

기술 직원들이시죠? 그리고 이것은 원하시는 바와 비슷합니다. 여러분의 취향을 정말 강조하는 제품을 만드는 것입니다.15:33

그리고 사용자분들이 그 취향을 인정하고 높이 평가하도록 하는 것이 중요합니다.15:39

그리고 A-B 테스트를 통해 그런 경우가 맞는지 확인하는 방법이 있었습니다.15:44

그래서 다중 팔 밴디트 시나리오의 경우, 예를 들어 그렇게 잘 할 수 있습니다.15:49

그래서, 일단 여러분의 취향이 좋고 사용자들도 그렇게 생각한다는 것을 확인하게 되면요.15:54

그때 홍보를 시작하고, 에이전트 레시피의 다음 버전으로 넘어가게 됩니다.15:59

비결은 이걸 계속 반복해서 하다 보면, 끊임없이16:06

자신의 취향과 좋은 점을 코딩화해서 재현할 수 있는 에이전트에 담는 것입니다.16:10

다른 사람들에게 동일한 서비스나 제품을 제공하고, 당신의 취향이 좋고 실행력도 뛰어나다는 데 동의하게 되는 것이죠.16:17

그리고 좋은 루프를 구축하는 비결은 바로 이것인데요. 다른 사람이 할 수 있을까요?16:24

제 시스템을 미란다처럼 좋은 예시로 삼아 개선해 나가야 할 것 같아요. 아시다시피요.16:29

악마는 입고 있다에 나오는 미란다는 어떤 상황에서 어떻게 했을까요?16:36

그러한 사고방식을 좀 더 고차원적인 수준에서 동일한 작업을 수행할 수 있는 에이전트, 즉 에이전트로 체계화하고 싶어하시는 거죠.16:41

결론은 다음과 같습니다.16:48

이 루프는, 더 높은 수준의 판단자로 자동화하려고 노력하는 제품입니다.16:49

두 번째 루프 에이전트들이 그렇게 할 수 있는지 확인하고 싶으실 겁니다.16:56

시도하는 에이전트에 동일한 판단 기준을 적용해야 합니다.17:01

비트 시스템 증류가 핵심 모드인데, 어떻게 지속적으로 그 맛을 주입할 수 있을까요?17:07

이 작업자들에게 주입하고, 그들이 지속적으로 스스로 검증하며 협업하도록 하는 것이 가장 중요합니다.17:11

더 빨리 할수록 더 빠르게 진행할 수 있습니다.17:15

수직형 인공지능 기업으로 발전할 수 있는 방어적인 접근법을 구축해야 합니다.17:22

마지막으로, 와트당 가치 있는 작업량을 통해 진행 상황을 측정해야 합니다. 제가 진전하고 있는지 아닌지를 판단하는 기준이 됩니다.17:28

그러니까, 우선 생성하는 작업이 가치 있는지 확인하세요.17:34

두 번째로, 경제적인 부분도 확인해야 합니다.17:39

이해가 되고요, 가격 차이가 사람들이 클라우드 코드를 떠나서 저희가 제공하는 것으로 전환하게 되는 주된 이유입니다.17:41

이런 아이디어들을 많이 고민해 봤고, 지금은17:48

실제 프로덕션 환경에 배포하는 방법에 대한 매우 흥미로운 제품들을 개발하고 있습니다.17:55

이 부분에 대해 더 자세히 듣고 싶습니다.17:59

저희에게도 배우고 싶습니다. 특정 수직형 SaaS 기업들이 어떻게 프로덕션으로 전환하는지, 또는 에이전트 랩에서 이 아이디어에 대해 어떻게 생각하고 있는지 더 잘 이해하고 싶습니다.18:00

어떤 회사들이 제품과 함께 자동 연구소를 만들어서 이 아이디어를 고려하고 있는지 궁금합니다.18:07

자체 제품에 대한 자동 연구실을 구축하는 이런 방식은 연락을 취하게 만들고, 이 주제에 대해 더 자세히 이야기할 수 있도록 저희가 계속 자리를 지키겠습니다. 정말 감사합니다.18:15

저희는 이 문제에 대해 더 많은 이야기를 나누기 위해 주변에 머무르고, 진심으로 감사드립니다.18:20