저는 수라즈 구프타입니다. 워프에서 하니스 개발을 담당하고 있습니다.00:12

워프를 처음 들어보셨다면, 저희는 최첨단 에이전트 기반 개발 환경을 구축하는 것으로 시작했습니다.00:16

거기에 약 백만 명의 활성 사용자가 있습니다.00:23

그것은 현대 터미널에서 탄생했습니다.00:26

요즘에는 팀이 소프트웨어 팩토리를 구축할 수 있도록 클라우드 에이전트 플랫폼을 구축하고 있습니다.00:28

오늘 저는 스스로 개선하는 소프트웨어 팩토리들에 대해 이야기하겠습니다.00:35

아마 '버즈워디'하게 들릴 수도 있지만, 자세히 설명해서 여러분이 실제로 적용할 수 있는 구체적인 내용을 얻어 가셨으면 좋겠습니다.00:40

직접 구현해 보세요.00:47

여러분은 아마 이 컨퍼런스 전체에서 자체 개선과 소프트웨어 팩토리라는 두 용어를 모두 들어보셨을 겁니다. 하지만00:49

독립적으로 들어보셨을 거라고 확신합니다.00:55

자기 개선이 어떻게 되는지 들어보셨을 거예요00:58

에이전트가 시간이 지남에 따라 개선될 수 있고, 에이전트와 모델도 있다는 것을 아시죠01:01

사람을 그 루프에서 빼서 개선 루프를 자동으로 만들 수 있죠01:08

소프트웨어 팩토리가 소프트웨어 개발 패러다임을01:13

개별 코딩 에이전트에서 트라이아지까지 작업을 처리하는 자동화를 구축하는 방식으로 전환되고 있다는 것을 알고 계실 거예요01:19

생산까지 이어지지만, 소프트웨어 팩토리 스스로가01:25

시간이 지남에 따라 스스로 개선되어 공장이 더 좋아지고 효율적이며 빨라질 수 있도록01:31

그리고 소프트웨어 엔지니어로서 우리 일의 매우 중요한 부분이 될 거라고 생각해요01:37

우리가 제품을 만드는 것에서 공장을 만들고 유지보수하는 것으로 전환하면서요.01:41

자, 시작해 볼까요.01:47

자기 개선은 상당히 포괄적인 개념이지만, 세 가지 구체적인 방법에 초점을 맞추겠습니다.01:50

에이전트가 시간이 지남에 따라 개선될 수 있고, 에이전트 팩토리가 시간이 지남에 따라 개선될 수 있습니다.01:54

먼저 기술에 대해 이야기하고, 그 다음에는 지속적인 메모리에 대해 이야기한 후 모델 라우팅에 대해 마무리하겠습니다.01:58

기술은 에이전트에게 절차적 기억을 부여하는 좋은 방법입니다.02:06

그것을 자세히 설명할 필요는 없을 것 같아요. 에이전트에게 절차를 설명해주면02:09

반복적으로 작업을 수행해야 하는 절차를 알려줍니다. 예를 들어, 소프트웨어 팩토리에서 흔히 구축하는 트라이아지 에이전트를 만들고 있다고 가정해 봅시다.02:14

소프트웨어 팩토리에서 흔히 구축하는 일입니다.02:20

그리고 이슈를 재현하는 방법에 대한 기술을 부여합니다.02:24

그 기술은 시간이 지남에 따라 устаревает. 사람들이 에이전트에게 피드백을 제공합니다.02:28

에이전트는 자체 실행 및 경로를 통해 학습합니다.02:32

이전에 부여했던 기술이 구식이 되죠.02:37

그럼 어떻게 이 문제를 해결하고, 에이전트가 그 기술을 활용하여 시간이 지남에 따라 개선되도록 할까요?02:41

한 가지 방법은 외부 루프 에이전트를 배포하는 것입니다. 저희 내부 소프트웨어02:46

공장에서 실제로 생산성이 높았습니다. 아이디어는 내부 루프 에이전트가02:51

실제로 기술을 적용하는 부분입니다. 트라이아주를 수행하는 것과 같아요.02:58

그리고 다른 외부 루프 에이전트가 내부 루프 에이전트의 실행을 관찰하고 시간이 지남에 따라 기술을 개선합니다03:01

실수가 있었던 부분을 찾거나, 사람이 제공한 피드백을 살펴보면서요.03:08

이제 그 예시를 보여드리겠습니다. 잠시 전환할게요.03:14

좋아요. 이것은 실제로 Warp 내부에서 사용했던 기술입니다.03:19

저희는 클라이언트 저장소를 오픈 소스했고, 완전히 공장처럼 운영되고 있습니다.03:23

그래서 이것은 오늘 저희가 사용하는 트라이아지 에이전트를 지원하는 기술의 예시예요.03:28

아이디어는 GitHub에 문제가 들어오면 자동으로 실행하도록 하는 거예요.03:34

에이전트를 통해 사용자가 제공하지 않은 어떤 정보인지 파악하는 거죠. 앞으로03:41

저희가 만들어야 할 만한 것인지, 아니면 그냥 중복 제거해도 되는 기존 문제인지, 혹은 다른 문제인지 판단하는 데 도움이 될 거예요.03:48

그리고 저희는 죄송하지만, 잠시 전환해 볼게요.03:56

그리고 실제로 그 트라이아지 에이전트를 실행하는 워크플로우가 있어요.03:59

이것은 꽤 간단한 워크플로우예요. 레포에 이슈가 제출될 때마다 이 워크플로우가 실행되는 방식이에요.04:06

그리고 이것은 트라이아지 에이전트가 수행한 작업을 살펴보고 시간이 지남에 따라 개선하는 실제 Outerloop 에이전트예요.04:13

아이디어는 에이전트가 내부 루프 트라이아지 에이전트가 내린 결정들을 살펴본다는 거예요.04:21

그리고 이슈에 대한 긍정 또는 부정 피드백 신호를 수집해요.04:27

사용자들이 이슈에 댓글을 달 수도 있고, Warp의 직원 중 한 명이04:33

이슈에 대해 피드백을 주면서 에이전트가 무엇을 했는지 알려줄 수도 있죠.04:38

그리고 결국에는 그 반복 과정의 통합으로 이어져요.04:43

그래서 Outerloop 에이전트를 통해 기본적으로 내부 루프 스킬을 업데이트하게 돼요.04:49

그게 바로 스킬과 함께하는 자기 개선 루프로 이어지는 거죠. 정말 좋은 점은 네 번째 단계에서04:55

트라이지 스킬을 편집하고 풀 리퀘스트를 여는 것을 볼 수 있어요. 즉, 내부 루프 스킬에 대한 모든 개선 사항은05:02

Git을 통해 추적될 거라는 뜻이에요. 그래서 시간이 지남에 따라 해당 스킬이 어떻게 변환되는지 완전히 파악할 수 있죠.05:09

그리고 사람이 실제로 그 스킬 업데이트를 검토하게 된다는 뜻이기도 해요.05:15

이렇게 하면 Outerloop 에이전트가 실수를 하지 않도록 하고 결국 트라이지 에이전트의 성능을 저하시키는 것을 방지할 수 있죠.05:20

네, 그래서 스킬에 관해 제가 이야기하고 싶었던 내용이에요.05:28

이제 지속적인 메모리에 대해 이야기해 볼게요. 슬라이드 쇼로 돌아가겠습니다.05:32

하지만 멋지죠. 스킬은 절차를 기억하는 데 좋지만, 다른 모든 것은 어떨까요?05:39

그러면 센트리 에이전트가 문제를 찾을 때 무슨 일이 발생하나요?05:44

문제를 발견하고, 그것에 대한 컨텍스트를 수집하기 위해 작업을 수행하나요?05:49

그리고 문제를 해결했지만, 미래에 비슷한 문제가 발생하면 어떻게 되나요?05:54

센트리 에이전트는 운이 좋으면 처음과 같은 근본 원인을 알아낼 수도 있지만,06:00

처음처럼 보장되지는 않아요. 그리고 그렇게 하더라도 이미 해결된 문제에 대해 컨텍스트를 다시 수집하는 데 많은 토큰을 낭비했을 가능성이 높습니다.06:06

이전에 이미 해결한 문제죠. 그래서 지속적인 메모리와 같은 것이 필요합니다.06:13

에이전트에 스코프된 팩트 저장소라고 생각할 수 있습니다.06:18

에이전트를 실행하고, 스킬 개선 루프와 마찬가지로 아우터 루프 에이전트가 있습니다.06:22

내부 루프 에이전트로부터 사실과 학습 내용, 결과를 추출하게 돼요.06:26

이렇게 하면 에이전트의 향후 실행은 과거에 수행된 작업을 활용할 수 있어요.06:30

그래서 이것의 예시를 보여드릴게요.06:34

여기 슬라이드로 돌아갈게요. 제가 언급했듯이 워프나 오즈에서 클라우드 에이전트 플랫폼을 구축했어요.06:37

클라우드에서 에이전트를 실행할 수 있고, 모든 에이전트에 메모리 저장소를 연결할 수 있어요.06:44

다시 말씀드리지만, 메모리 저장소는 단순히 사실들의 모음이에요. 여기서는 센트리가 있어요.06:51

과거에 수행했던 근본 원인 분석에 대한 메모리를 수집한 에이전트예요.06:56

멋진 점은 이 메모리의 버전을 관리할 수 있다는 거예요. 인간이 업데이트하거나 새로운 메모리를 만들거나 삭제할 수도 있어요.07:03

하지만 주로 이 메모리 생성 루프는 에이전트에 의해 구동돼요.07:09

이 메모리가 어디에서 소스되었는지도 확인할 수 있어요. 그래서 실행을 열어볼게요.07:14

아, 제 IP 주소가 계속 바뀌는 것 같아요.07:21

그리고 저희 스테이징 플랫폼은 IP 주소로 제한되어 있어요.07:25

어쨌든 그 기억들이 어디에서 가져온 건지 확인할 수 있어서, 예를 들어07:28

그게 실제로 중요한 기억이 아니었거나, 제가 메모리 저장소에 포함하고 싶지 않은 지역 최댓값이었을 수도 있어요.07:35

그리고 에이전트가 계속 실행되면, 이 경우에는 Sentry 에이전트가 여러 번 실행을 했어요.07:41

그 기억들을 생성한 후에, 새로운 문제를 분류할 때 미래에 그 기억들을 활용할 수 있어요.07:48

이 경우에는 이 에이전트가 실행되었던 걸 확인할 수 있어요.07:55

근본 원인 분석을 위해 많은 작업을 했고, 결국 어떤 기억들을 사용했는지 보고했어요.07:58

이 경우에는 제가 그 메모리 저장소에 가지고 있던 다섯 개의 기억을 활용해서 작업을 가속화할 수 있었어요.08:05

이번에 제가 했던 작업들을요.08:12

좋아요. 다시 프레젠테이션으로 돌아가겠습니다.08:15

Oz에서 멋진 점은, 지속적인 메모리가 모든 하니스에서 작동한다는 거예요.08:21

워프 존, 독점 하니스, 플롯 코드, 코덱스, Oz에서 무엇을 실행하든 크게 중요하지 않아요.08:25

메모리는 자동으로 생성돼요.08:30

하지만 여러분은 해당 메모리를 검토하고, 버전을 관리하고, 삭제하거나 원하는 대로 편집할 수 있는 제어 권한도 가지고 있어요.08:33

모든 작업이 완벽하게 추적 가능하도록요.08:40

좋아요. 메모리에 대해 말씀드릴 건 여기까지예요.08:43

마지막으로 이야기하고 싶은 것은 모델 라우팅이에요. 아마 자가 개선08:46

팩토리의 루프에 어떻게 적용되는지 궁금해하실 수도 있을 거예요. 우선 팩토리에 모델 라우팅이 왜 중요한지에 대해 말씀드릴게요.08:52

단순한 작업을 수행하는 모든 에이전트를 실행하면 비용이 너무 많이 들 수 있어요.08:58

트riage나 간단한 CI 실패 수정 같은 작업에 Opus를 사용하는 것09:02

시간이 지날수록 정말 비싸질 거예요. 아마 여러분 중 일부는 이 때문에 피해를 입었거나, 조직들이09:06

피해를 입었다는 이야기를 들었을 수도 있어요.09:13

어떤 모델을 어떤 작업에 사용할지 선택하는 것은 매우 중요하며, 저희 Warp에서 노력하고 있는 부분이에요.09:15

Warp에서는 바로 사용 가능한 모델 라우터를 사용할 수 있어요.09:22

저희는 이것들을 오토 모델이라고 부릅니다.09:26

새로운 모델이 나올 때마다 패레토 효율성 측면에서 어떤 모델이 가장 좋은지 평가하고 있어요.09:28

그래서 새로운 사용자가 시작하기를 원한다면, Opus나 Haiku처럼 특정 모델에 고정하는 것보다 훨씬 좋아요.09:34

예를 들어 Opus나 Haiku 같은 경우에요.09:39

Warp에서 그 경험을 보여드릴게요.09:44

자, 여기로 가볼게요.09:47

잠시만요. 이걸 여기로 드래그할게요. 자, 여기 제 Warp 데스크탑이 있어요.09:53

모델을 정의하거나 Warp의 자동 모델을 사용할 수 있다는 점과 함께 볼 수 있어요.09:59

자동 모델을 사용할 수 있는 것도 하나의 옵션이고, 여기 예시 모델처럼요. 하지만 사용자 정의 라우팅 모델도 정의할 수 있어요.10:06

기본적으로 규칙 세트를 저희에게 제공하면, 그 규칙에 따라 모델 라우팅 결정을 내리는 방식이에요.10:13

그 규칙에 기반하여 모델 라우팅 결정을 내릴 수 있어요. 그래서 제가 정의한 설정 파일 예시가 여기 있네요.10:19

GLM으로 데이터베이스 마이그레이션을 하고 싶다는 몇 가지 규칙을 정의했어요,10:26

또는 저는 퀀(Quen)으로 런북과 API 문서를 처리하고 싶어요.10:31

그래서 작업 유형을 정의할 수 있어요.10:38

그리고 이 종류의 작업은 이 모델로 처리하고 싶다고 말할 수 있죠, 왜냐하면 지금까지 그렇게 해왔으니까요.10:42

하지만 지금은 과학보다는 예술에 가깝다고 할 수 있어요.10:48

그래서 저희가 다음으로 작업하고 있는 것은 고객에게 보여지는 평가를 정의할 수 있도록 하는 것입니다10:51

어떤 점을 중요하게 생각하는지, 그리고 이러한 구성에서 어떤 설정을 조정하고 싶은지를 실제로 정의할 수 있는 거죠.10:58

그리고 실제로 하이쿠가 GLM보다, 오퍼스보다 낫나요?11:04

특정 워크플로우에 특화된 문제 유형에서만,11:10

누군가가 온라인에 올린 일반적인 벤치마크가 아니라,11:14

여기 돌아가 볼게요. 한번 볼게요.11:19

좋아요.11:30

네, 그래서 제가, 아, 슬라이드쇼에 들어가 있네요.11:34

자, 여기는 현재 Warp에서 이 기능이 어떻게 작동하는지에 대한 개괄적인 내용입니다.11:43

그래서 내부적으로는 모델 라우팅 규칙이 있어요.11:47

하지만 평가 측면에서 어떤 작업들이 어떤 모델과 더 잘 어울리는지 판단하고 있어요.11:50

그리고 저희는 간단한 베스트 K 접근 방식을 사용하는데, 프롬프트를 입력하면 여러 에이전트가 Oz에서 다양한 모델들을 실행해요.11:57

Oz에서 다양한 모델 세트를 통해 실행했는데, 어떤 모델이 어떤 작업을 더 잘 수행하는지 판단하는 데 성공했어요.12:02

UI 작업은 GLM으로 정말 잘 처리돼요. Opus로는 실행할 필요가 없어요.12:08

GLM으로 실행하는 것이 훨씬 효율적이에요. 그래서 저희는 그렇게 사용해 왔어요.12:12

곧 이 기능을 제품에 통합할 예정인데, 고객님들이 자신의 워크플로우에서 활용하실 수 있도록요.12:15

네, 오늘 발표할 내용은 여기까지예요.12:23

저희는 부스에 있습니다. 이런 내용에 관심이 있으시면 저에게 와서 이야기해주세요.12:26

항상 이런 주제로 이야기하는 것을 좋아해요. 오늘 시간 내주셔서 감사합니다.12:31

이것밖에 없었어요.12:35