안녕하세요 여러분. 제가 테레사입니다. 오늘 소프트웨어 팩토리(Software Factory)에 대해 이야기할게요.00:37

모두가 소프트웨어 팩토리에 대해 이야기하지만, 실제로 구축하는 사람은 몇 명 안 돼요,00:44

더군다나 어떻게 구축해야 하는지, 그리고 정의하려면 어떻게 해야 하는지 아는 사람도 더 적어요.00:50

그래서 소프트웨어 팩토리가 무엇인지, 직접 구축할지 아니면 외주를 맡길지00:55

어떤 것들이 이미 프로덕션에서 작동하는지, 주요 과제는 무엇인지, 그리고 총 비용은 얼마나 들지 이야기할게요.01:00

저는 테레사이고, factory.com이라는 회사에서 일해요. 저희는 이 개념을01:09

오랫동안 구축해 왔지만, 드디어 기술이 따라잡고 있고01:15

EY나 Adobe와 같은 기업을 위해 프로덕션에서 이것을 구축할 수 있게 되었어요.01:21

저는 소프트웨어 팩토리를 자율성을 가진 소프트웨어 개발의 전체 루프, 전체 라이프사이클이라고 정의하고 싶어요.01:27

코딩하고 코드를 생성하는 것만 의미하는 건 아니에요.01:34

제가 말씀드리는 것은 모든 신호를 수집하고 사용자 피드백과 로그에 반응하는 것을 의미해요.01:37

중요한 것을 우선순위화하고, 전체를 조정하며 실행하는 것이에요.01:42

검증하고, 실제 운영 환경에서 훌륭한 테스트를 수행하는 거죠.01:47

그리고 이 모든 것을 반복하면서도 지속적으로 개선하고01:50

새로운 지식과 기술을 습득하는 것이에요. 그래서 이것은 저희 소프트웨어 팩토리가 어떻게 보이는지 보여주는 대시보드예요.01:55

전체 주기를 포착하고 있어요.02:02

이것은 역사에 대한 간략한 설명이고, 역사는 여기서는 2023년의 AI를 의미해요.02:06

그래서 소프트웨어 팩토리는 이전에는 정말 불가능했어요. 비록 저희는02:12

처음부터 chat GPT 출시와 다른 것들을 통해 이 아이디어를 항상 가지고 있었어요.02:16

이러한 연속적인 루프에 대한 아이디어였는데, 이미 GPT 베이비 AGI와 함께 했었어요.02:21

소프트웨어를 반복하는 개념은 있었지만, 이전에는 작동하지 않았어요.02:26

요소들이 환각을 일으키거나, 컨텍스트 길이 문제나 문제가 있었고02:31

추론 품질과 같은 다양한 문제들이 있었어요. 또는 좋은02:36

에이전트가 격리된 환경에서 실제로 작업할 수 있는 환경이 부족했죠. 그래서 모두02:41

이런 모든 것들이 소프트웨어 팩토리가 점점 인기를 얻고 있는 패러다임이 된 이유를 설명해요.02:45

지금은 유용하게 사용되고 있어요.02:52

저는 무엇인가를 정의할 때 그것이 아닌 것으로 정의하는 것을 좋아해요.02:55

그래서 소프트웨어 팩토리는 코딩 에이전트가 아니에요. 심지어 수천 개의 에이전트로 이루어진 군집도 아니에요.02:58

코드를 생성하고 작성하는 것은 다른 모든 것들에 비해 쉬운 부분이에요. 엔지니어들은 대부분의 시간을 코딩만 하는 것이 아니에요.03:03

다른 모든 것들에 비하면 쉬운 부분이죠. 엔지니어들은 대부분의 시간을 코딩하는 데 쓰지 않아요.03:09

어려움은 나머지 부분이고, 이것이 제가 강조하고 싶은 부분이에요.03:15

단순히 컨설팅이나 추상적인 전략도 아니에요. 누군가가03:20

당신과 조직에 판매하려고 하는 접근 방식은03:25

물론 다르겠지만, 조직을 완전히 재건해야 한다고 생각해요.03:30

소프트웨어 팩토리가 되기 위해 처음부터 다시 구축해야 해요. 컨설턴트를 불러서03:34

조직 중간에 무언가를 던지는 것과는 달라요.03:40

정말 신중하게 다시 처음부터 재건해야 해요.03:45

소프트웨어 팩토리를 구축하는 데 이 접근 방식을 보여드리는 것을 좋아해요.03:50

그리고 저는 이것이 실제 인간 팀을 만드는 것과 비슷하다고 생각해요. 에이전트가 많으니까요.03:55

말했듯이 테스트하고 검증하고 반복하면서 모두 큰 혼란으로 끝날 수 있어요.04:01

그래서 주의해야 해요. 그리고 중요한 세 가지는 소프트웨어 팩토리에서 무관심해야 한다는 거예요,04:08

LLM 선택이나 조직의 기존 방식에 의존하지 않도록 하는 거죠,04:14

그다음 자율적이어야 하고, 에이전트에게 적절한 신뢰와 권한, 거버넌스를 줘야 해요,04:21

그리고 오랫동안 실행할 수 있도록 믿어야 해요04:26

예상에 따르면 에이전트는 인간의 개입 없이도 1년 이상 운영될 수 있다고 하니까요.04:29

물론 야심찬 이야기처럼 들리겠지만, 예를 들어 저희의 미션들은 이미,04:35

저희의 장기 실행 세션은 이미 여러 가지를 만들고 몇 주 동안 운영되고 있으니, 그렇게 이상한 이야기는 아니에요.04:39

그리고 세 번째는 항상 개선하는 거예요. 사람 조직과 마찬가지로,04:45

팀의 새로운 팀원을 온보딩할 때04:49

좋은 코드 베이스, 이해도, 좋은 구조, 문서화를 제공하고 개선하도록 해야 해요.04:53

프로세스에서 경험하고 새로운 지식을 얻어 팀 내에서 공유해야 해요.04:59

이것이 세 가지 핵심 내용이고, 이제 범용적인 부분에 대해 이야기해 보겠습니다.05:04

제가 말씀드리고 싶은 중요한 점은, 만약 여러분이 소프트웨어 팩토리의 다양한 기본 요소를 구축하는 빌더라면05:10

소프트웨어 팩토리의 다양한 기본 요소들을 구축할 때, 이미 팀원들이 어떻게 작업하고 있는지에 대비해야 해요.05:14

슬랙, GitHub과 같은 환경을 넘나들며 모든 것과 연결해야 합니다.05:19

사람들이 이미 사용하고 있는 구독 서비스를 가져올 수 있도록 허용하는 것도 필요합니다.05:25

새로운 기술, 새로운 프론티어 모델, 새로운 벤치마크가 나올 때마다05:29

따라잡기도 어렵고 무엇이 승리할지 예측하기도 어려우므로, 모두를 위해 범용적으로 접근하는 것이 가장 좋습니다.05:36

다음으로 모델에 대한 범용성을 고려해야 할 주제가 있습니다.05:44

이것은 최근 많은 논의가 이루어지고 있는 주제이며, 이 차트는 다음에서 가져온 것입니다.05:47

Coinbase CEO가 트윗했는데, 회사 내에서 돈을 절약하기 시작했어요.05:54

AI에 대한 지출은 줄이지 않고 토큰 사용량을 줄였어요. 검은 선은 토큰에 얼마를 쓰는지 보여줘요.06:02

토큰 사용량과 최대화는 계속 늘어나지만, 돈을 많이 쓰지 않게 됐어요.06:08

다양한 트릭으로 해냈는데, 예를 들어 다양한 기본 모델을 제공해서06:12

사람들이 프론티어를 기본적으로만 사용하지 않도록 하고, 캐싱도 해서06:18

물론 매번 같은 것을 선호하는 걸 멈추고, 지출 제한도 없애고06:23

많이 사용했을 때 결과를 확인해야 하고, 마지막으로 중요한 건06:29

라우팅이에요. LLM 간의 스마트 라우팅과 간단히06:34

토큰을 많이 사용하지 않고 LLM 사이에서 토큰을 최적화하는 거예요.06:40

Factory에서 자동 모델 라우팅이라는 기능을 만들었어요.06:47

그리고 이 부분에 대해 많은 질문이 있었는데, 이게 하는 일은 자동으로06:52

프로세스 내의 서로 다른 모델 간을 연결해줘요.06:57

중요한 건 가장 최적의 모델이 무엇인지 먼저 결정한다는 거예요.07:01

그리고 나서 다른 모델로 전환할 수 있어요07:04

작업에 실패하거나 문제가 발생했을 경우에도, 하지만 보통은 그렇지 않아요.07:08

일어나요. 중요한 건 돈을 절약해주는 것 외에도07:12

안정성이나 속도 향상에도 도움이 돼요. 왜냐하면 오픈 소스 모델은 종종07:18

더 빠르거든요. 그리고 한 LN 제공업체가 실패하더라도 다른 곳으로 바로 전환할 수 있어요07:23

자동으로 전환되니까 돈을 절약하는 것 외에도 훨씬 더 많은 일을 해내요.07:28

이것은 저희의 벤치마크인데, 매우 보수적으로 잡았어요.07:32

저는 보수적인 벤치마크를 선호하지만, 방향은 명확하다고 생각해요.07:36

예를 들어 25%라고 말할 수 있지만, 어쩌면 그보다 더 많이 될 거예요.07:40

라우팅이 어떻게 작동하는지, 네 가지 부분이 있어요. 우선 작업을 할당하고, 특별히 뭘 할 필요는 없지만,07:47

하지만 조직적으로 보면, 예를 들어 다른 사람들에게 서로 다른 권한과 모델을 부여할 수 있는데, 이게 아주 유용해요,07:54

서로 다른 사람들에게 할당할 수 있는데, 매우 유용해요,07:59

마케팅이나 영업, 엔지니어처럼 다른 기본 모델을 사용할 수도 있고08:01

그다음 분류가 중요한 부분이고, 이게 마법이죠08:07

라우팅의 핵심은 프롬프트 구조를 자세히 살펴봐야 하고08:10

코드 베이스와 작업 난이도, 어떤 도구를 사용하는지 등 모든 요소들을08:15

이 요소들을 고려해서 작업의 난이도를 분류하고 나서요.08:20

기본적으로 작업을 완료하기에 충분한 수준의 임계값을 정하고, 그 기준을 넘는 가장 저렴한 모델을 선택해요.08:26

임계값 이상의 가장 저렴한 모델을 선택해서 진행하는 거에요.08:32

이걸 출시했을 때, 실제로 작동하냐는 질문을 많이 받았어요.08:41

모델이 잘못 라우팅되면 어떻게 되나요? 더 느린가요?08:46

실제로 더 비싼 건가요? 모델이 작업을 완료할 수 없다면 어떻게 되죠?08:50

작업을 완료하지 못하거나, 업그레이드가 필요하다면 캐싱은 어떻게 처리하나요?08:53

이 모든 질문들이 타당하다고 생각해요. 그래서 좋은 라우터를 만드는 게 어려운 거에요.08:58

기본적으로는 매우 잘 분류해야 하고, 도전 과제는 너무 자주 전환할 필요가 없는 거예요.09:03

너무 자주 전환하지 않는 것이고, 작업 중간에 더 어려운 모델로 전환하더라도09:09

전반적으로는 아마 더 빠를 거에요. 그래도 가치가 있으니까요.09:14

이것은 캐싱에 대한 개요일 뿐이에요. 관련 질문도 많이 받았는데,09:21

캐싱을 어떻게 처리해야 할까요? 사용자에게 할인을 제공할까요?09:27

LLM Labs는 물론 캐싱으로 많은 돈을 절약하고 컨텍스트 프리필을 계속해서 건너뛰기 때문이에요.09:32

오픈 모델도 이와 같이 할 수 있어요. 사람들이 종종 잊는 것 같아요,09:40

그리고 전용 컴퓨팅 환경에서 오픈 모델을 호스팅할 수도 있고요,09:44

캐싱의 동일한 이점을 얻을 수 있어요. 사용자에게 최종 가격을 낮추고 싶어요.09:48

단지 가격 결정 문제일 뿐이에요. 캐싱은 누구나 할 수 있으니 기술적인 문제는 아니에요.09:56

사용자에게 어떤 가격을 적용하고 API 제공업체와 어떤 계약을 맺느냐의 문제일 뿐이에요.10:01

이것은 기술에 구애받지 않는다는 의미입니다. 이제 소프트웨어 팩토리의 핵심인 자율성을 살펴보겠습니다.10:07

모두가 루프에 대해 이야기하고 있어요.10:15

루프는 제가 생각하기에 이미 이전부터 다양한 맥락에서 존재했어요.10:19

이제 수준이 높아지고 에이전트의 맥락으로 이동하고 있어요.10:23

RALF 루프와 작업을 지정하고 에이전트를 위한 하위 작업으로 분할하는 것에 대해 아마 들어보셨을 거예요.10:27

이것은 잘 알려진 개념이고, 중요한 것은 루프 자체가 아니라 질문이에요.10:34

루프 안에서 완료되었다는 것을 어떻게 정의하는가 하는 것이에요.10:40

이것은 동료의 한 예시인데, 에이전트들이 구축하는 루프를 만들었어요.10:43

로고 3D 프린팅인데, 여기서 루프의 어려움을 볼 수 있을 거예요.10:49

루프 때문이에요. 이전에는 프로그래밍 그룹에서 무엇이 잘 되었다는 것을 판단하는 명확한 기준이 있었어요.10:55

이제 기준은 열린 상태가 되었고, 많은 작업들이10:59

비결정적이에요. 기본적으로 세상이 열려 있어서 무엇이든 할 수 있어요.11:05

실제 프린팅 같은 작업은 어떻게 해야 하는지 정의하기가 정말 어려워요.11:08

루프가 완료되었는지, 작업이 수행되었는지 확인하는 게 어렵죠.11:13

그게 어려운 부분이에요.11:16

네, 검증 가능해야 해요. 저는 이걸 무서운 차트라고 부르죠.11:20

기본적으로 보여주는 건 바로11:24

에이전트와 함께 작업들이 얼마나 자율적으로 실행되는지 시간이 늘어났지만 여전히11:26

그렇게 신뢰할 수 있는 건 아니에요. 아주 오랫동안 실행할 수 있다고 해도11:32

실제 운영 환경에서 신뢰할 수 있다는 보장이 없고, 아직 반복해서 개선하고 피드백을 제공해야 할 거예요.11:36

아직 해결되지 않았고, 부정행위 같은 문제도 있어요. 예를 들어, 무엇을11:43

잘못된 방식으로 작성하면 에이전트는 테스트를 통과하려고 할 수 있지만, 실제로는11:48

무엇을 해야 하고 달성해야 하는지 검증하는 대신 단순히 테스트를 통과하는 것을 해결하려고 시도해서 부정행위를 하는 거죠.11:55

저희는 팩토리 미션이라는 걸 가지고 있는데, 이건 에이전트의 장기 실행 세션이고 저희는 그걸 미션이라고 부릅니다.12:03

에이전트를 미션에 보내고, 미션은 작업 루프 안에서 반복하며 완료될 때까지 작업을 진행해요.12:10

몇 주 동안 지속하기도 하고, 주요 에이전트는 오케스트레이터예요.12:17

그리고 작업자 에이전트에게 작업을 할당해요.12:22

그리고 검증자들이 작업을 검토하는데, 이건 실제의 한 예시이고12:25

고객사에서 실행한 16시간짜리 미션으로, 얼마나 중요한지 확인하기 위해서예요.12:31

검증이 얼마나 중요한지 보여주는데, 전체 프로세스의 40%를 차지하기도 해요.12:37

오케스트레이터는 완료되었다고 판단하는 조건을 결정하고 작성해요.12:42

그리고 작업자라고 불리는 에이전트에게 전달하고, 에이전트들은 그것을 처리하고...12:47

흥미로운 점이나 주목할 만한 것은 순서대로 작업한다는 거예요, 스웜이나 병렬로12:52

병렬로 작업하지 않고 에이전트들은 순서대로 작업하고 모두가12:56

무언가를 완료하고 다음 단계로 넘겨주는데, 실제로 그렇게 하면13:00

이렇게 하면 더 신선한 컨텍스트와 신선한 상태가 유지되는 것을 알게 되었어요, 마치13:05

사람이 다른 동료에게 코드를 검토받는 것과 비슷하게13:10

비슷한 방식으로 에이전트들을 다음 단계로 넘어가게 하지만, 여전히 모든13:15

순서대로 작업하는 워커는 더 작은 작업을 위해 병렬 에이전트를 가질 수 있고, 그래서13:19

웹에서 조사하거나 파일을 만드는 것과 같은 작업도 할 수 있어요.13:24

그래서 순서대로 진행되고 모두 서브 에이전트도 가지고 있어요.13:27

그리고 검증자들은 결과를 검토하고 피드백을 제공해서 처음으로 다시 보내요.13:30

중요한 건 검증자가 자신이 작성하지 않은 코드를 판단한다는 거예요.13:39

오케스트레이터 에이전트에서 제공하는 검증 계약이라는 것이 코드가 작성되기 전에13:44

작성되고, 첫 번째 유형은 스크루티니 검증자이고 두 번째는 사용자 테스트예요.13:50

스크루티니 검증자는 코드베이스의 모습을 실제로 확인하는 역할을 해요.13:55

린터와 테스트를 통해 코드를 정말 엄격하게 검사하지만, 두 번째는14:00

정말 흥미로운 건 사용자 테스트 검증자이고, 그게 바로14:05

실제로 사용 환경에서 시도해보는 역할을 해서 어떻게 만들어졌든 상관하지 않고14:10

그저 가상 컴퓨터에서 작동하는지, 그리고 클릭해보고14:14

모든 것이 제대로 작동하는지 확인해요. 저희 에이전트로 코드베이스를 마이그레이션하는 엔지니어를 봤는데, 결국에는14:20

에이전트가 필요한데, 다른 제품들은 단순히 결과물을 만들 뿐 작동하지 않고 인터랙티브하지 않았기 때문이에요.14:27

다른 제품들은 그냥 결과물을 만들었지만 작동하지 않았고 상호작용적이지도 않았어요.14:33

그냥 가짜 결과물이었기 때문에 저희 에이전트가 실제로 클릭하는 기능을 통해 확인하도록 해줬어요.14:39

코드상으로는 괜찮아 보이지만 실제로는 작동하는지 확인할 수 있도록 해주는 거죠.14:46

컴퓨터 사용의 발전과 지속적인 환경, 그리고 에이전트를 위한 가상 머신 덕분에 가능해진 멋진 점이라고 생각해요.14:49

가상 머신 덕분인데 이전에는 없거나 좋지 않았지만 지금은 정말 좋아요.14:55

에이전트로서 경기장에 진출할 수 있도록 해주는 거죠.15:01

이것은 사용자로부터 받은 실제 미션의 한 예시이고, 사용자들이 무엇을 만들고 있는지 배우는 것을 좋아해요.15:07

피드백을 얻고, 이것이 여러분의 대시보드에서 어떻게 보이는지 보여드릴게요.15:12

미션을 시각화한 모습이고, 흥미로운 점은15:17

모든 에이전트가 루프 안에서 실행되기 때문에 작은 루프로 이루어진 루프예요.15:24

이것 또한 루프로 진행되지만 전체적으로는 큰 루프와 같아요. 음, 어쩌면 조금15:29

이상하게 느껴질 수도 있지만, 작은 루프로 이루어진 모든 루프가 마음에 들어요.15:34

좋아요, 그리고 세 번째 부분은 항상 개선하고, 항상 학습하는 거예요.15:38

에이전트와 관련된 '침묵하지 못할 문제'가 있어요.15:43

정당한 질문들이 많아요. 예를 들어, 긴 미션을 진행하면서 어떻게 컨텍스트 증가를 관리하느냐는 거죠?15:48

소프트웨어 팩토리에서 어떻게 컨텍스트를 깨끗하게 유지하느냐고요?15:55

그건 매우 타당한 질문이에요. 특히 기업들은 수백 개의 도구를 사용하거든요.15:59

Figma, Notion, Gmail, Drive, Slack 같은 수백 개의 도구를 평균적으로 사용해요.16:04

그래서 이 모든 것들이 코드에 명세가 있고, 스키마와 파라미터, 로그 설명이 있어요.16:09

그러면 에이전트가 이 정보로 인해 부풀어 오르고, 두 개의 도구가 비슷하게 들린다면 잘못된 도구를 선택하거나16:17

발음이 비슷하거나 문맥을 잃어버리기 때문에 문맥 창에 채워져 압축해야 할 수도 있어요.16:21

그래서 이것은 정말 위험해요. 그래서 소프트웨어 팩토리 내에서16:29

우리가 '지연된 문맥 엔진'이라고 부르는 것을 만들었고, 점진적으로 공개하도록 설계했어요.16:34

문맥에 무엇이 있는지 그리고 어떤 도구를 사용할지 알려요. 그래서 기본적으로 나중에 도움이 되는 깜짝 도구를 가지고 있어요.16:41

필요할 때만 사용해요. 먼저 도구 목록과 짧은 설명만 보여줘요.16:48

그리고 코드에서 실제로 필요할 때 도구를 호출하고 완전히 로드할 수 있어요. 중요한 것은 아무것도 제거되는 것이 아니에요.16:56

제거되는 게 아니라 숨겨져서 필요할 때까지 접근할 수 없도록 하는 거예요. 나중에 사용하기 위한 거죠, 그리고17:02

중요한 것은 규모가 커질수록 많은 토큰을 절약해 준다는 점이에요.17:09

도구를 더 많이 사용할수록 더 많이 절약할 수 있어요.17:12

정말로 확장되고 토큰을 50% 이상 절약할 수 있어요.17:16

좋아요, 또 하나 까다로운 점은 제가 처음 알게 된 건데, AI를 도입할 때17:22

큰 성공을 거두거나 똑같이 크게 실패할 수도 있어요.17:29

약간의 파워 법칙과 같아서, 코드베이스가 준비되지 않았다면,17:32

구조화된 코드베이스가 없고 중요한 것들이 없다면,17:37

소프트웨어 팩토리로 전환하면 오히려 더 나빠질 수도 있어요.17:40

코드 품질을 저하시키고 생산성 격차가 커지고 있어요.17:45

AI를 도입한 사람들 대비 조금 더 생각한 사람들과의 사이에요.17:51

그리고 스탠포드에서 구조화되지 않은 코드베이스가 없는 경우에 대한 또 다른 데이터가 있는데,17:58

준비가 되어있지 않고 잘 문서화하지 않으면 AI가 코드를 더 나쁘게 만들 수 있어요.18:04

그리고 엔지니어라면 아마 가끔 AI가18:07

정말 엉망을 만들고, 이게 계속 누적되어 되돌리기 어려워요.18:12

소프트웨어 팩토리의 일부로 저희는 ~라는 것을 가지고 있어요18:19

~라고 하는 에이전트 리디네스라는 것이 있고, 이 단어인 프레임워크는 별로 좋아하지 않지만18:23

프레임워크라고 생각하되, 코드 베이스에 대한 위생 점검과 해야 할 것들을18:27

해야 하는 이유는 코드의 상태와18:32

모든 세부 사항과 AI를 얼마나 잘 활용해서18:36

정신없는 코드 베이스 대신 생산적으로 만들 수 있는지에 대한 상관관계가 있어요.18:40

예를 들어 개발자 환경이 얼마나 재현 가능한지, 혹은18:44

좋은 테스트를 작성했는지, 모든 것을 잘 문서화했는지, 코드 스타일은 어떤지18:50

코드, 모든 테스트와 린터, 코드를 깨끗하게 유지하기 위해 하는 모든 것들에 대해서는요.18:54

코드 베이스를 깨끗하게 유지하는 것도 중요해요. 이런 요소들이 실제로 매우 유용하다는 것을 알았고, 저희가19:00

큰 고객들이 에이전트 준비 상태 프레임워크를 통해19:06

모든 점검을 수행하고, 권장되는 조치를 따라 문제를 해결할 수 있어요.19:09

그렇게 수정하는 것이 중요하다고 생각해요. 컨텍스트와 지속적인 학습에 대해서는 또 다른 점이 있고요.19:15

소프트웨어 팩토리에서 AI를 사용할 때, 대부분의 경우19:22

제 경험에 비추어보면 에이전트에게 어떻게 해야 하는지 계속 반복해서 설명하게 돼요.19:28

일하는 방식을 알려주는데, 에이전트가 이해하지 못하는 것 같아요.19:32

그리고 이것은 다시 한번 인간 조직이나 팀과 비슷한 점이에요. 새로운 회사에 합류할 때19:35

많은 규칙들이 명확하게 정의되어 있지 않은 경우가 많아요.19:42

그냥 어떻게 하는지 배우고 관찰해야 하고, 겉으로 드러나지 않는 많은 것들이 있다는 거죠.19:45

관찰하는 것 외에는 정말 배울 수 없는 것들이죠.19:51

에이전트에게도 큰 도전 과제라고 생각하고, 그래서 저희가 플러그인을 출시했는데요.19:55

패키지로 묶인 재사용 가능한 기술과 컨텍스트, 그리고 숨겨진 기능들을 말해요.20:00

정말로 코딩할 수 있거나, 자동 위키처럼 자동으로 업데이트되는 것들이죠.20:06

저희의 문서들을 검토하고 기록하는 거죠.20:11

그래서 질문은, 이런 소프트웨어 팩토리를 만든다면 우리 인간들에게 무슨 일이 벌어질까요?20:19

인간들이 일자리를 잃고 영구적인 하층민이 될까요?20:25

저는 그렇지 않을 거라고 생각해요. 긍정적으로 보고, 이런 평행선을 생각하고 있어요.20:30

인간들이 이전보다 더 멋진 업무로 레벨업하는 거죠.20:36

저희도 이전에 같은 경험을 했었다고 생각해요.20:43

인간이 몇 단계 추상화하면서 실제로 인간 컴퓨터로 시작했어요.20:48

처음에는 우리가 모든 세부적인 작업을 하는 컴퓨터였어요.20:54

그러다가 프로그래밍 언어를 통해 일부를 코딩하고 추상화했고, 그리고20:58

에이전트 코딩을 해서 일부는 아웃소싱하지만, 여전히 루프 안에 있고 매우21:03

매우 주의 깊게 감시하면서 이제는 소프트웨어 팩토리로 옮겨가고 있어요.21:08

소프트웨어 팩토리에서 오르케스트레이터 에이전트라고 말씀드린 것처럼 에이전트를 관리하고21:13

그리고 작업자, 검증자, 그리고 구조화된 팀의 에이전트들21:18

반복적으로 루프 안에서 일하고, 우리는 그냥 모니터링하고 결정해요.21:23

무엇을 만들지 결정해야 해요. 그래서 저는 긍정적으로 마무리하고 싶어요.21:28

우리는 인간으로서21:32

소프트웨어에서 무엇을 만들지 결정하고, 어떻게 만들지는 신경 쓰지 않아야 해요. 왜냐하면21:34

그건 에이전트에게 맡길 수 있고, 이 지속적인 자율 소프트웨어 사이클을 통해21:39

실제로 그걸 달성할 수 있다고 생각해요.21:46

이것은 경고 차트 중 하나이고, 만약 누군가가 AI가21:48

우리의 멋진 것들을 가져갈 거라고 생각한다면, 저는 오히려 귀찮은 것들을 가져갈 거라고 믿어요. 기업과 조직에서는 이미21:53

귀찮은 일들을 처리하고, 회사는 이미 많은 시간을 쏟고 있어요.21:57

회의에서 의견을 조율하는 데 쓰고 있죠. 제가 말씀드린 것처럼22:01

겉으로 드러나지 않는 중요한 부분은 모두에게 맥락을 전달해야 한다는 점이에요.22:06

상태를 공유하고, 회의에서 아이디어를 나누는 모든 것들이22:10

실제로 소프트웨어 팩토리에 외주로 맡기고, 멋진 일들에 대해서만 이야기할 수 있어요.22:15

멋진 일들에 대해 이야기할 수 있죠, 좋아요. 이것이 전부예요. 정말 감사합니다, 이제 나가서 햇볕 좀 쬐세요.22:19

에이전트가 대신 빌드하게 하세요. 감사합니다.22:24