저는 저스틴 리악입니다. DX의 수석 기술 책임자이고, 개발자00:12

경험과 생산성과의 관계에 대한 연구를 진행하고 있습니다.00:18

지난 1년 동안 많은00:21

그 연구는 개발자 경험에 대한 AI의 영향과 조직 내 기본적인 측면에 집중해 왔습니다.00:24

생산성에 대해 다루고 있습니다. 그래서 분기별 보고서를 발행하고, 저희는 'AI 상태'00:30

그리고 'AI 영향 보고서'를 통해 저희 플랫폼에서 얻을 수 있는 많은 원시 데이터를 살펴봅니다.00:36

저희 플랫폼에서 데이터를 확보할 수 있습니다. 저희 플랫폼은 연구 기반으로00:41

도라 메트릭, 스페이스 프레임워크, 그리고 데벡스 프레임워크를 개발한 같은 사람들이 만들었습니다.00:46

데벡스 프레임워크와 결국 데이터 수집 플랫폼입니다.00:50

조직 전체의 다양한 트렌드를 파악할 수 있습니다.00:53

어떻게 개발자 경험에 집중하고 있는지, 그리고 결과와00:57

개발자 경험 개선을 보고 있는지, 확실히 결과를 보고 있나요?01:01

우리가 워크플로우에서 AI를 사용하는 방식과 관련해서 이번 세션은01:05

345 세션과는 조금 다를 거예요. 아마 오늘 리더십룸에서 진행될 것 같아요.01:10

오늘 오후에 리더십룸에서 진행되는 최신 보고서의 원시 데이터를 분석하는 내용이에요.01:13

조금 미리 살펴보는 건데, 조직 트렌드와 워크플로우 변화 등을 살펴볼 예정입니다.01:18

저희가 보고 있는 데이터에 기반해서 우선 먼저 살펴보겠습니다.01:24

속도 영향 측면에서 무엇을 보고 있는지, 혹시01:28

PR 처리량이나 배포 빈도와 같은 다양한 속도 지표를 살펴보는 데 익숙하신 분들은01:32

이 지표들이 완벽하지 않다는 점, 그리고 프록시 지표라는 점을 이해해주셨으면 좋겠어요.01:37

조직 내 업무 흐름을 이해하기 위한 지표는 완벽하게 대표하지 않아요01:41

가치 창출을 제대로 반영하진 않지만, 관련 지표도 살펴보겠지만01:46

일단 기술이 단순히 속도 지표에 어떤 영향을 미치는지 이해해 봅시다01:50

조직 내 배포 빈도를 나타내는 도라(Dora) 지표가 있습니다. 도라 지표를 아는 분 계신가요?01:56

지표에 대해 잘 아시는 분이 많군요, 좋아요.02:01

이것은 핵심 지표 중 하나이며,02:03

환경 내에서 업무를 배포하는 속도를 파악하려고 시도하며, 꾸준히 증가하고 있어요.02:08

조금씩 감소하는 경향이 있는데, 그럴 만한 이유가 있다고 생각해요.02:15

초기에 봤던 급증은 사람들이 더 자주 PR을 배포했기 때문이에요02:19

이런 일들이 있어서 증가세를 보이고 있지만, 이것은 작은 부분에 불과해요.02:26

SDLC PDLC의 일부죠, PR 생성부터 실제로02:32

배포를 시도하는 과정이죠. 롤백 비율에 대해서는 알려주지 않고02:37

결함 비율에 대해서도, 변경 실패율에 대해서도 알려주지 않아요02:41

얼마나 많은 양을 프로덕션으로 밀어내고 있는지 정도만 알려줘요02:44

프로덕션으로 밀어내고 있는데, 데이터는 이 숫자가 꾸준히 증가하고 있다는 것을 보여주고 있어요, 알겠죠?02:48

지역별로 추세가 조금씩 달라요.02:54

북미는 상승하는 경향을 보이고 있어요02:57

상승하는 것 같아요. 유럽은 지난 분기 동안 약간 후퇴했어요03:00

분기 동안이죠. 그 이유가 몇 가지 있을 거라고 생각해요.03:05

이 지역에서 일하는 방식은 다르겠죠. 이 기술에 돈을 쓰고 토큰 사용량을 생각하는 방식도 달라요.03:09

규제도 다르죠. 하지만 그냥 보면03:15

전반적인 흐름을 보면, 여전히 이 지표 하나에서는 개선이 보이고03:19

배포 빈도라는 지표를 보면 다양한 지역에서도 약간의 차이가 있어요.03:25

지역별로 조금씩 다른 양상을 보입니다. 그중 흥미로운 하나는03:29

엔지니어가 느끼는 배송 속도, 즉 얼마나 더 빠르게 무엇을03:35

배송하는지에 대한 인식은 조금 상승했어요. 이 수치는 약 4.5% 증가를 보여주지만03:41

약 4.5% 정도의 증가인데, 1년이라는 시간이 지나고03:46

AI에 대한 투자와 비용, 새로운 지출을 고려하면, 이 인식이03:52

더 많이 상승하지 않은 것이 흥미로워요.03:56

특히, 명성이 자자한 잘못된 METR 연구를 보면 더욱 그렇습니다.04:00

잘 아시는 그 연구, 2월에 발표된 그 연구의 후속 보고서가 나왔는데, 수집한 일부 데이터는04:05

불완전했고, 일부 내용을 재고해야 한다고 했는데, 흥미로운 점은 그 연구에 참여한 16명의 엔지니어04:12

작고 결함이 있는 연구였지만 생산성은 약 19% 감소했고, 하지만04:18

인지도는 약 20% 상승하여 생산성 인지도의 격차가 40% 정도 발생했어요.04:23

생산성에 대한 인식과 실제 생산성의 차이가 있지만, 여기서는04:28

전체적인 관점에서 보면 흥미롭게도 결과가 거의 변동이 없어요.04:32

품질과 배송에 미치는 영향은 어떻죠? 속도나 효율성 지표일 뿐이지만04:37

속도와 효율성을 나타내는 지표이지만, 실제 소프트웨어 품질에 어떤 영향을 미치나요? 여기에서 살펴볼 첫 번째 지표는04:41

DORA 변경 실패율 지표입니다. 미리 말씀드릴게요.04:48

앉으셔야 할 것 같아요. 이 기간 동안 품질에 미치는 영향이 매우 변동성이 커요.04:53

이 그래프의 각 선은 이 연구의 특정 부분에 참여한 회사 중 한 곳을 나타냅니다.04:58

그리고 그 선은 변경 실패율이 증가했는지 감소했는지를 보여줍니다.05:05

아래로 가고 싶어요. 이 그래프의 하단에 위치하고 싶죠.05:11

흥미로운 점은 몇몇 상위 선을 보면 사람들이05:15

최대 2%까지 증가하는 것을 볼 수 있는데, 그게 별로 크지 않다고 생각할 수도 있지만05:18

산업 표준이 약 4% 정도이기 때문에 잠재적으로 50% 더 많은05:22

결함을 이전보다 더 많이 배포하게 되는 것이므로 어느 쪽을 향하고 있는지 이해하는 것이 중요합니다.05:27

이 그래프의 어느 쪽에 있는지 파악하고 측정하기 시작해야 합니다. 이05:31

패턴은 AI가 없어도 존재하며, 이는 순전히 인과 관계는 아닙니다.05:35

AI와 관련이 있는데, 릴리스 파이프라인이나 자동화된 것들과도 관련이 있습니다.05:40

테스팅을 포함해서 코드를 배포하는 방식과 관련된 모든 것들이 패턴은 유지되고05:43

동일하게 유지되지만, AI 때문에 진폭이 변했어요. 볼라티리티의 이러한 변화는 항상 나타나지만05:48

보통 이런 극단적인 수준은 아니었고, 이것이 우리가 보는 AI 효과예요. 여기에는05:54

정말 흥미로운 것들이 있는데, 보통 동기화되는 두 가지 질적 품질 지표가 있어요.06:00

서로 연관되어 있습니다. 코드 유지보수성, 개발자들이 코드를 얼마나 유지보수 가능하다고 생각하는지06:07

변경을 하기 쉽다고 느끼는 정도인데, 저희 데이터에 따르면 이 숫자는 거의 4% 증가했어요.06:12

이 데이터를 수집하기 위해 이번 연구에서 약 20만 명의 엔지니어를 대상으로 하고 있습니다.06:17

데이터를 분석하고 있는데, 코드 변경에 대한 자신도는 전통적으로06:21

코드 유지보수성과 밀접하게 관련되어 왔어요. 이 코드는 유지보수가 가능하고 모듈화되어 있어서 수정하기도 쉬워요, 변경에 대해06:28

자신이 있다고 느끼지만, 저희의 코드 변경 자신도 수치가 하락했습니다.06:34

6% 정말 흥미로운 긴장감이에요. 에이전트와 어시스턴트가06:39

어시스턴트는 제가 코드를 이해하고 수정하는 것을 더 쉽게 만들어 주지만06:43

출력을 덜 신뢰하게 되었고, 이제 예전보다 물건을 망칠까 봐 더 걱정돼요.06:47

1년 전보다 심리적으로 흥미로운 효과가 나타나고 있어요.06:52

여기서 볼 수 있는 현상 중 많은 부분은 풀 리퀘스트 크기가 눈에 띄게 증가하고 있기 때문이에요. 올해 저희가 살펴볼 가장 중요한 지표 중 하나가 될 거예요.06:56

아직 두 배는 되지 않았지만, 그 추세도를 보세요. 이건07:03

거의 1년 동안 같은 기간 동안 풀 리퀘스트가 평균 44라인에서07:08

평균 72라인까지 증가했어요. 물론, 그 이유도 여러 가지가 있죠.07:14

이 모델들이 작동하는 방식 때문에07:19

상대적으로 평범한 코드를 출력하도록 훈련받고 있기 때문만은 아니에요.07:23

저는 90년대 후반부터 전문적으로 코딩을 해왔어요. 같은 사용 사례를 가능한 한 적은 코드로 구현할 수 있는 개발자에게 높은 평가가 주어졌던 시절이 있었죠.07:27

적은 코드 양으로 구현하는 것이 중요했죠. 지금은 그냥 빨리 결과물을 내는 게 우선이고, 당신은07:33

생성되는 코드는 평균적으로 평범할 가능성이 높아요, 평균의 법칙이죠.07:37

게다가 빌드 파이프라인이 45분이나 한 시간이나 걸린다고 생각해 보세요.07:40

이제 AI가 즉시 함수를 생성해 주니, 저는07:46

서로 다른 네 개의 함수에 대해 네 개의 PR을 밀어 넣고 45분이나 한 시간이나 기다려야 할까요?07:51

빌드를 기다려야 하나, 아니면 그냥 모든 코드를 하나의 PR에 쑤셔 넣어야 하나, 그렇죠. 여러 가지 이유가 있어요.07:56

이러한 현상에는 여러 가지 이유가 있지만, 추가적인 코드 한 줄마다 잠재적인08:01

버그나 취약점이 될 수 있고, 리뷰해야 할 양이 늘어나고, 코드를 덜 이식 가능하게 만들어요. 따라서 이 지표에도 주의를 기울여야 해요.08:06

저희도 이 지표와 함께 이것이 인식과 관련되어 나타나는 것을 보고 있기 때문이죠.08:10

점진적인 배포를 통해 작은 점진적인 변경 사항을 작업할 수 있어서08:15

지난해에 영향을 미친 가장 낮은 품질의 개발자 경험 요소 중 하나예요.08:20

이 수치와 감성은 지난 10년 동안 감소했고, 점진적인 배포가 끔찍하다는 것은08:24

우리가 시도하는 방식에 있어서도 매우 중요하다고 배웠어요.08:31

쉽게 롤백할 수 있고, 밀어넣는 변경 사항을 이해하고 검토할 수 있는 방식이죠.08:36

좋아요, 인구 통계학적 차이는 어떤가요?08:42

주니어 개발자처럼 AI의 영향이 어떻게 다른가요?08:45

? 주니어 엔지니어가 AI를 가장 많이 사용해요. 이건 정말 놀랍지 않아야 하죠.08:50

새로운 도약이 있을 때마다 전문적으로 코드를 작성해 왔어요,08:55

90년대 후반부터 베테랑이라고 할 수 있죠. 저도 이 여정을 함께하고 있지만, 덜 배워야 할 것들이 있어요.08:59

배우고 싶지 않은 것을 덜 배워도 되죠. 많은 경우에09:04

학교 졸업 후 바로 이런 종류의 것들을 사용해 본 적이 있을 거예요.09:09

실제로 일을 시작하면 더 쉽게 적용할 가능성이 높아요. 저희는09:12

다른 트렌드도 확인했어요. 사용 사례별로 효율성을 살펴보는 흥미로운 방법이 있어요.09:18

오늘 나중에 두 번째 발표에서 자세히 설명할게요. 그중 하나가09:22

에이전트의 경험을 살펴보는 거예요. 실제로 에이전트에게 묻고 있어요.09:26

사람들과 함께 일하는 경험에 대해 알아보고, 어떤 사용 사례를 진행하고 있는지, 그리고 얼마나 많은 토큰을 소비했는지 파악하려고 노력해요.09:31

그리고 주니어 개발자가 시니어 개발자보다 동일한 사용 사례에서 더 많은 토큰을 소비하는 경향도 확인했어요.09:38

동일한 사용 사례에서요. 그건 학습 곡선 때문이죠.09:45

물론 예상했던 결과예요. 하지만 가장 많이 사용하는 사람이 누구냐 하면, 주니어가 가장 많이 사용하고 있어요.09:48

그 추가적인 사용에도 불구하고, 스태프 및 일부 더 경험 많은 엔지니어들은 비슷한 양의 시간을 절약하고 있어요.09:53

토큰 소모량도 줄어들고 있고요. 그 점을 확실히 말씀드리고 싶어요.10:01

원시적인 시간 절약과 이의 집계 출력 측면에서 보면10:04

기술을 더 많이 사용하는 주니어 엔지니어와 스태프 엔지니어 사이에 거의 차이가 없어요.10:08

환각 현상을 쉽게 발견하고 변경 사항의 아키텍처를 이해하는10:12

아키텍처와 관련된 것들을 더 잘 처리하는10:16

작은 회사들이 시간 절약 측면에서 앞서 나가요. 물론 릴리스 파이프라인이10:20

덜 복잡할 거예요. 조직 전체의 복잡성도 적어요.10:24

시간 절약을 이끌어낼 거예요. 이미 마찰이 적은 회사는10:28

더 큰 회사보다 조금 더 민첩성을 가지고 있어요.10:33

측정에 대해 어떻게 생각해야 할까요? 개발자10:40

생산성을 측정하고 개발자 경험을 측정하는 것은 AI 이전에도 어려웠고10:46

그 대화는 거의 끝내지 못했고, 이제 가속화제를 뿌린 것과 같다고 할 수 있겠죠.10:51

아직도 어려운 일이고, 저는 AI 때문에 더욱 어려워졌다고 생각해요.10:55

AI의 여러 측면에 의해 복잡해졌기 때문이에요.10:59

하지만 올해는 우리 모두 이 질문에 답해야 할 거예요, 그렇죠?11:03

오늘 제 토큰 강연을 들으시면 1천만 달러 이상이 필요할 거예요. 우리 10배 생산성은 어디에 있죠?11:07

이것을 생각할 때 우리가 측정하는 것을 버리지 않는 것이 중요해요, 그렇죠?11:15

우리 개발자 경험과 생산성 지표는 여전히 가장 중요한 것11:21

중요하고, AI가 이것에 어떤 영향을 미치는지 이해하고 싶어요.11:25

이미 살펴보고 있는 신뢰할 수 있는 지표들을 살펴보는 것도 좋을 것 같아요11:30

사용자 그룹에서 API 텔레메트리 데이터 등을 가져올 수도 있을 거예요11:34

도구에서 나오는 데이터를 활용해서 누가 무엇을 어디서 사용하는지 이해할 수 있죠11:39

하지만 이러한 그룹들을 비교적으로 살펴볼 의향은 있을 거예요11:43

기본 지표에 비례해서 품질에 어떤 영향을 미치는지, 그리고11:46

속도에 어떤 영향을 미치고 조직에 어떤 영향을 주는지 알아봐야 해요11:50

그리고 가치 창출에도 영향을 줘요. 그래서 우리 AI 측정 프레임워크가 나오게 된 거에요11:54

이 부분에 너무 많은 시간을 할애하지 않을게요. 자세한 내용은 백서로 나와 있어요.11:59

저의 동료인 앤톤은12:02

흰 셔츠를 입고 방 뒤에 서 있는 그는 보고서 사본을 나눠줄 수 있을 거예요12:04

발표 후에 이 방법론을 어떻게 도출했고, 어떻게 활용하고12:09

생각해 볼 수 있어요. 측정의 세 가지 주요 측면에 초점을 맞춰서 사용률을 살펴보고,12:13

매일 활성 사용자, 주간 활성 사용자 같은 그런 것들을 살펴봐요.12:18

영향인데 어떤 지표를 봐야 바늘을 움직일 수 있을까요?12:23

사용률이 증가함에 따라 무엇을 기대할 수 있나요?12:27

사업 영향과 비용이죠. 지난 주요 과열에서 15년이나12:32

지난 주요 과열 이후에도 아직 클라우드 비용을 파악하느라 애쓰고 있는데, 이런 것들은 점점 비싸지고 있으니 측정해야겠어요.12:37

이것을 성숙도 곡선으로 생각할 수도 있죠. 대부분의 사람들은 왼쪽에서 사용률부터 시작해서12:43

기술을 사용하는 사람이 누구인지, 무엇을 얼마나 자주 어떤 용도로 사용하는지 파악한 다음, 어떻게 하면 이것들을 영향 지표와 교차 검증할 수 있을까요?12:50

투자 가치가 있는지 확인하기 위해 실제로 무엇을 이해하고 싶어하는지, 즉 이것이 우리가 정말로 원하고 싶은 거죠.12:56

어떻게 이런 상관관계를 파악할 수 있는지 예시일 뿐이에요.13:03

두 개의 사용자 그룹을 비교해 볼 수도 있어요.13:07

PR 주기 시간이나 PR 크기, 리뷰에서 피드백과 같은 지표를 통해요.13:11

이것을 생각하는 방법은 지금 당장은 분리된 그룹으로 나누는 것이죠.13:17

그런 다음 이러한 기본적인 생산성 지표에 어떻게 영향을 미치는지 살펴보세요.13:22

우리가 신뢰할 수 있는 이러한 지표들을 이해해야 하고요, 저희는 또한13:25

플랫폼의 준비 상태를 말씀드리고 싶어요. 2024년에는 모두에게 코딩 어시스턴트를 제공했고13:30

2025년에는 에이전트 구축을 시작했는데, 지금은 저희 인프라가 이 모든 것에 대비되지 않았다는 것을 깨닫고 있어요. 여기 있는 많은 벤더들이13:34

이 문제를 해결하는 솔루션을 판매하고 있습니다. 플랫폼의 AI 준비 상태를 측정할 수 있다면13:41

토큰을 효율적으로 사용하고 에이전트에게 컨텍스트를 제공하는 방법을 훨씬 더 잘 파악할 수 있을 거예요.13:48

이것은 명확하고 정확하며 잘 구조화된 문서, 간단한 관계를 가진 데이터 구조, 관리 가능한 모듈식 코드와 같은 것들입니다.13:54

안정적인 로컬 CI 환경과 안정적인 테스트 스위트가 필요합니다. 참고로 이 내용이 익숙하게 들린다면,14:01

그것은 이전부터 이걸 좋은 개발자 경험이라고 불렀기 때문이에요.14:06

하지만 인간에게 좋으면 에이전트에게도 좋다는 것이 밝혀졌어요. 그래서 역설적으로 지난 20년 동안 해야 했을 투자를 이제야 하고 있을지도 모르겠네요.14:09

지난 20년 동안 해야 했을 투자를 이제야 하고 있을지도 모르겠네요. 저희는 또한 AI를 사용하는 방식의 효과성을 이해하고 싶습니다.14:15

이것은 그 방법 중 하나입니다.14:22

여기서 보시는 것은 에이전트로부터 돌아오는 피드백, 즉 문제점을 알려주는 질적 피드백입니다.14:24

사람과의 조율, 제공된 컨텍스트, 그리고 그들이 거쳐야 했던 피드백 루프에 대한 내용이죠,14:31

그래서 저희는 에이전트로부터 데이터를 받아 팀들이 AI와 함께 일하는 데 얼마나 효과적인지 파악하려고 하고 있으며, 이것을 사용 사례별로 세분화할 수 있습니다.14:37

사용 사례별로 나누는 것도 매우 중요합니다.14:44

어떤 사용 사례가 가장 효율적인 토큰 소비를 제공하는지 이해하고 싶고, 또 가치 창출과14:46

비즈니스 내 생산성을 높이는 데 도움이 되는지 알고 싶습니다. 마지막으로 다섯 번째 트렌드는 SDLC와 PDLC 전반에 걸친 통합입니다.14:54

왜 이런 작업을 하고 싶을까요? 왜냐하면 코드 생성 자체가 처음부터 병목 지점은 아니었으니까요.15:00

엔지니어가 모델에서 100% 정확한 즉각적인 코드를 얻는다고 해도15:05

그렇지 않죠. 전체 가치 흐름의 14~16% 정도만 해결할 수 있을 거예요.15:10

따라서 그 이상을 생각해야 합니다. 특히 지금 우리가 얻고 있는 생산성 향상이15:16

기대보다 скромный하고, 추가적인 PR15:20

처리량 증가에도 불구하고 11월에 실시한 연구에서 중앙값 증가는15:25

올해 2월까지 약 7.7% 증가하는 것으로 나타났습니다.15:30

이 속도 지표는 평균 13%였지만, 최고 성과자들도 7015:35

퍼센트 범위에 속했고, 2배나 5배, 10배를 달성한 사람은 아무도 없어요. 왜냐하면15:40

AI에서 얻는 시간 절약 효과가 다른 비-AI 요인에 의해 상쇄되고 있어요.15:46

우리 조직 내의 요인이죠. AI로 많은 시간을 절약할 수도 있지만15:51

그건 좋지만, 회의가 많거나 맥락 전환이 잦고 다른 종류의15:55

방해 요소들 때문에 누적 효과가 발생하고, 코드를 중심으로 소프트웨어를 만드는 방식에서 마찰이 있다면16:02

병목을 해결하지 못하는 거예요. 엘리 골드랫이라는 분은 제약 이론과 책 'The Goal'의 영감을 주셨고16:09

‘피닉스 프로젝트’에 대한 영감을 주셨는데, 병목이 아닌 곳에서 절약한 한 시간은16:12

가치 없다고 말씀하시죠. 그래서 우리는 병목을 찾아내고16:16

병목을 해결해야 해요. 많은 조직들이 그렇게 하고 있어요.16:20

하고 있습니다. 모건 스탠리는 Dev를 개발하는 것에 대해 매우 공개적으로 이야기해 왔어요.16:23

Dev Gen AI 에이전트로, 메인프레임과 같은 레거시 코드를 해석하는 에이전트예요.16:28

내추럴과 COBOL, 그리고 인정하기 싫지만 Perl도 많이 썼어요. 제 경력에서요.16:33

경력이지만 지금은 레거시가 되었네요. 이 에이전트는 엔지니어에게 전달할 PRD를 실제로 생성해요.16:36

엔지니어에게 역공학 단계를 없애기 위해, 모건 스탠리를 절약하고 있어요.16:40

모건 스탠리는 현재 연간 약 30만 시간을 절약하고 있고, Zapier는 제가 가장 좋아하는 AI 이야기 중 하나예요.16:44

지금 AI에서 그들이 사용하는 전체 에이전트 생태계가 있어요. 그걸 이용해서16:48

많은 관리 업무와 오버헤드를 처리하고 있어요, 매일 스탠드업 같은 것들을요.16:52

그런 것들로 스탠드업 시간을 줄였어요. 에이전트 요약본을 사용해서요, 그리고16:56

그들이 구축한 이 생태계에서 일주일에 두 번으로 줄었어요.17:01

일주일에 다섯 번인 것보다 엔지니어를 성공적으로 온보딩하고 있어요.17:04

약 두 주 만에 엔지니어를 온보딩하는데, 정말 빠른 속도예요. 우리 업계의 기준은 보통 한 달이 넘거든요.17:08

보통 한 달 이상 걸리는데, 이 이야기에서 제가 가장 좋아하는 부분은17:12

엔지니어당 약 15%의 추가적인 가치 창출을 보고 있어서요. 그래서 그들은17:16

회사 역사상 가장 많은 인력을 채용하고 있어요. 왜냐하면 여기에서 중요한 진실을 깨달았기 때문이죠. 단일 엔지니어당 더 많은 역량을 확보할 수 있다는 것을17:21

엔지니어당 더 나은 투자 수익률을 얻고 있고, 그리고17:27

더 많은 엔지니어를 채용하면 경쟁력을 향상시킬 수 있다는 것이 올바른 태도예요. 이건 처리량 증가에 대한 이야기입니다.17:31

혁신 역량 증대에 대한 이야기입니다. 인원 대체에 대한 이야기가 아니에요. 맞죠?17:37

주당 약 3,000개의 코드 리뷰를 자동화하고 있는데, 풀 리퀘스트에서 시작돼요.17:42

그리고 표면적인 부분들을 확인해요. 여전히 인간이 필요하지만17:47

루프에 참여해야 해요. 하지만 에이전트에서 나오는 초기 표면적인 리뷰는 시스템의 일부입니다.17:51

기록으로 남아요. PR 댓글에 그대로 남아있고요. 그래서 다음 리뷰 엔지니어는17:57

에이전트가 이미 살펴본 내용을 파악해서 시간을 절약할 수 있을 거예요. 스포티파이라면18:02

데브옵스에서 스포티파이 모델을 기억하는 분들이 계실 텐데요, 그들은 데브옵스의 북극성 같은 존재였어요18:07

SRE를 위한 에이전트를 구축해서 런북에서 복구 단계를 수집하고18:12

사건에 대한 정보를 모아서 SRE 커뮤니케이션 채널에 전달해줘요. 그러면18:17

사건이 발생했을 때 SRE는 즉시 상황을 파악하고 여러18:22

분 동안 알아내려고 애쓰지 않아도 돼요. 더 자세히 알고 싶다면18:28

데이터를 더 깊이 파고 싶으시다면, 2분기 보고서가 몇 주 안에 나올 예정이지만18:32

1분기 보고서에도 이 세션에서 얻은 유용한 정보들이 많이 담겨 있어요. 그리고18:37

뉴스레터에 구독하시거나, 홈페이지를 방문하시면 7월 중순쯤에는18:40

7월에 저희의 Q2 보고서가 나올 거고, 그 보고서 미리보기를 원하시면18:44

오늘 오후에 제가 할 강연에서 확인하실 수 있습니다. 시간 내주셔서 감사합니다.18:48