참석해 주셔서 감사합니다. 이곳 컨퍼런스의 마지막 날입니다.00:12

아시겠지만 일주일이 길었을 거라고 생각해요00:16

일주일을 보내느라 힘드셨겠지만, 제가 정말 중요하게 생각하는 주제에 대해 이야기하게 되어 기뻐요,00:17

소프트웨어 팩토리입니다.00:25

이 개념은 여러분 중 누구에게도 새롭지 않을 거라고 생각해요. 다 같이 여기 계신 걸 보니 소프트웨어 팩토리에 대해 잘 알고 계실 것 같아요.00:28

램프에서 몇 달 전, 아마 작년 12월쯤에 그들의 인스펙트에 대해 블로그를 올렸어요.00:34

정확히 언제였는지 기억은 안 나네요. 시간이 좀 흘렀어요. 그리고 그 사실이 전체 산업을00:41

생각하는 방식에 큰 영향을 줬어요. 이제 우리는 소프트웨어를 훨씬 다르게 만들 수 있다는 거죠.00:46

AI가 코드를 작성할 수 있을 정도로 매우 능력이 뛰어나기 때문이에요.00:50

다른 많은 회사들도 뒤따랐고, 여기에는 일종의 표준 설정이 있어요.00:54

코드를 넣을 수 있는 샌드박스가 있어요. 실행하세요.01:01

거기에 AI 에이전트를 넣고, 클로드 코드 섹션이나 오픈 코드를 사용할 수도 있죠.01:04

프롬프트를 통해 PR을 생성하고 병합할 수 있어요.01:11

아마 이미 직접 구축하고 계실 수도 있을 거예요. 저희 워크OS에서는 조금 다른 접근 방식을 취했어요.01:16

저희가 만들고 있는 것의 동기는01:24

성공 지표들이 실제로 많은01:27

'출력'에 집중하고 있다는 거죠. X나 블로그에서 보시는 것처럼01:33

PR 비율이나 풀 리퀘스트 수, AI가 생성하는 코드 양에 대해 이야기하고 있죠.01:39

생성된 코드가 프로덕션으로 이동하는 것에 대해서요.01:45

이것은 단순히 출력 지표일 뿐이에요.01:49

이런 것들이 실제로는 시스템이 얼마나 잘 작동하는지 가릴 수 있어요.01:52

PR 비율이나 PR 수는 전체적인 PR 증가를 숨길 수도 있죠.01:58

출력이 실제로 결과를 이끌고 있는지 판단하기는 어려워요.02:04

그래서 소프트웨어 팩토리를 생각할 때 이런 부분에 집중하고 있어요.02:10

자동화 수준을 구축하기 위해 엔지니어링 시간을 투입한다면요.02:16

이 작업에는 어느 정도 노력이 필요하고, 전담 팀이 필요해요.02:22

이것의 성공을 어떻게 정의할지, 그리고 이것이 실제로 가치를 창출하는지 생각해 봐야 해요.02:27

for our organization, our engineering organization? And so we measure instead of just code output,02:34

우리는 결과 지표를 보고 있어요. 그리고 그것은 정말로 우리 기능 제공 능력을 가속화하고 있는지에 대한 것02:41

기능을 제공하는 것을 얼마나 빠르게 할 수 있는지요? 소프트웨어 팩토리의 꿈은02:48

각 엔지니어에게 작은 엔지니어링 팀을 제공하는 것이죠.02:52

그래서 그 결과로 우리는 더 많이 만들고, 더 많이 배포해야 해요.02:57

복잡한 기능들을 시작할 때 훨씬 빠르게 구축할 수 있어야 하는 거죠.03:02

그럼 이것이 실제로 어떻게 보이는 걸까요?03:11

글쎄요, 다른 팩토리에서 보셨던 것과 비슷한 방식으로 시작했어요.03:13

Cloudflare 위에 구축한 샌드박스로 시작했죠.03:21

거기에 오픈 코드 모델 라우터를 넣었어요.03:24

프롬프트를 입력하고 있어요.03:27

그리고 저희는 매우 빠르게 이것이 더 많은 성과를 이끌어내지 못한다는 상황에 직면했어요.03:30

엔지니어가 노트북에서 코드를 직접 작성하는 것보다 점진적인 증가도, 지수적인 증가도 없었어요.03:36

저희에게는 거의 구분이 안 될 정도였어요.03:43

그래서 저희는 정말로 엔지니어링 프로세스를 어떻게03:47

팩토리 자체에 통합할 수 있을까 생각하기 시작했어요. 팩토리가 코드를 생성하는 것만으로는 충분하지 않아요.03:54

저희는 엔지니어가 제품을 만들기 위해 하는 다른 작업들을03:59

자동화하고 싶었어요. 그래서 저희는 이걸 두 부분으로 나눴어요.04:05

하나는 저희가 TARS라고 부르는 시스템이 있어요.04:11

이건 사용자가 코딩 에이전트와 상호 작용할 수 있는 방법이에요,04:14

그리고 저희가 사용하는 도구에 내장되어 있어요.04:19

슬랙뿐만 아니라 리니어와 깃허브에도요.04:23

TARS를 통해 웹훅을 구독해서 TARS가 프로젝트 진행 상황을 추적할 수 있도록 했어요.04:27

코드 출력 생성 외에도04:34

그리고 호라이즌이라는 별도의 시스템을 구축했는데, 이것은 인프라 오케스트레이션 계층이에요.04:38

인스펙트나 미니언즈와 다른 회사들이 만든 다른 시스템과 유사하게04:45

하지만 MCP 게이트웨이 앞에 위치해요.04:52

그 MCP 게이트웨이가 우리에게 정말 혁신적인 변화를 가져다주었는지에 대해 조금 더 이야기할게요.04:56

그래서 웹훅 활동을 피드하여05:07

다른 소스 코드 시스템과 프로젝트 추적 시스템에서 발생하는 것들을05:12

공장이 단순히 코딩 작업이 아닌 제품 엔지니어링 작업을 수행하는 자율성의 수준에 도달하고 있어요.05:18

예시는 무엇일까요? 리니어에서 의존성이 있는 티켓을 정의할 수 있어요.05:25

한 티켓이 다른 티켓을 차단해요. 큰 작업 단위를 작은 단위로 나누는 데 흔히 사용되는 방식이에요.05:31

TARS가 티켓 완료 시 웹훅을 받아서 주기적인 다음 티켓을 자동으로 선택할 수 있어요.05:40

그래서 저희의 계획 과정을 통해,05:47

어떻게 이 계획이 진행될지 지도를 구성하고05:50

자율적으로 실행할 수 있어요.05:54

또 다른 점은 단계 사이에 티켓이 완료되면 TARS에게05:58

리니어 프로젝트를 다시 평가하고 누락된 티켓이 있는지 알려줄 수 있니라고 물어볼 수 있어요.06:04

작업을 진행하면서 계획의 빈틈이 어디인지 알게 되기 때문이에요.06:09

에이전트를 이용해서 계획을 계속 최신 상태로 유지하고 싶어요.06:13

에이전트는 우리가 처음 계획했던 것에서 누락된 부분이 있을 수 있다고 판단해요.06:20

프로젝트와 염두에 둔 목표를 위해요.06:26

그래서 저희는 WorkOS에서 제품 엔지니어링 문화를 운영하고 있어요.06:31

이곳에서는 엔지니어가 제품 기능의 많은 부분을 담당해요.06:35

현재 팀에 제품 매니저가 없어요.06:39

그리고 이 제품 엔지니어링 프로세스의 의식 중 하나는 Hilltop 문서를 만드는 거예요.06:42

이것은 PRD이고, 프로젝트의 목적을 정의하는 것과 동시에06:48

고객들이 무엇에 대해 이야기하고 있는지, 어디에서06:55

이 작업 단위에 대한 필요성을 확인하고 경쟁사 분석도 살펴봐요. 마치07:01

시중에 나와 있는 유사한 제품이 있는지, 영감을 얻을 수 있는지07:06

디자인 초기 디자인 화면을 가져오기 시작하고 개요를 작성해요.07:09

주요 이정표는 무엇인지, 그리고 정보를 통합함으로써07:15

이 정보를 문서화하여 표준화하는 것은 저희 제품 엔지니어들이 회사 전체에서 해왔던 일이에요.07:20

이제 이 리소스를 에이전트에게 제공할 수 있게 되었어요.07:24

에이전트는 이걸 작업 단위로 분할할 수 있어요. 그래서 저희에게는 정말 강력한 방법이었어요.07:32

기존 프로세스를 가져와서 자체적으로 팩토리에 코딩하는 것이죠.07:39

제가 말씀드렸듯이 웹훅을 감지하고 있어요. 어떤 모습인지 예시를 보여드릴게요.07:44

하지만 힐탑 문서가07:48

리니어 티켓을 통해 검토되고 승인되었고, 승인이 되었기 때문에07:51

이 프로젝트에 자동으로 작업을 시작할 수 있어요. 그래서 저희는 인간이 모든 단계별로 이 에이전트를 인도할 필요가 없어요.07:58

이 에이전트를 전체 라이프사이클의 모든 단계를 거치도록요.08:03

그래서 저희는 이 프로세스의 특정 부분에 맞춰 에이전트를 만들었어요. 저희는 그걸 PM이라고 불러요.08:09

그리고 저희가 제공하는 간단한 사양을 바탕으로 힐탑 초안을 작성하고 있습니다.08:14

그것에 맥락을 추가하면서08:21

사람의 검토 내용을 읽고 구현 단계를 파악하여 티켓으로 나누기도 합니다.08:25

이 프로세스의 각 단계에서 사람이 참여할 기회가 있습니다.08:31

AI가 생성한 티켓에 사람이 개입하거나 의견을 제시하는 것은 매우 흔합니다. 그리고08:36

더 자세한 지침이나 개선 작업을 하기도 하지만, 사실 콜드 스타트08:42

문제를 해결하여 다양한 리소스를 생성하는 초기 단계를 극복할 수 있습니다.08:47

자, 이것이 실제로 어떻게 보이는지 살펴봅시다. 지난달 또는 2개월 전에 시작한 프로젝트가 있습니다.08:52

제가 이끄는 Volts라는 제품에 새로운 API를 추가하고 있습니다.09:00

그리고 슬랙에서 이 명령어를 사용하면,09:04

저는 간단한 설명, 보통 몇 문장 정도로 무엇을 달성하려 하는지 적고 이 프로젝트를 시작할 수 있어요.09:09

그러면 TARS가 들어가서 제게 필요한 모든 리소스를 생성해줘요.09:16

저는 선형적으로 프로젝트를 만들 필요가 없어요.09:19

Notion 문서 초안이나 의사 결정 로그 같은 것들을 만들 필요도 없어요.09:21

미결정 질문들도요.09:28

이것은 그런 작업의 초기 버전을 만드는 거예요.09:30

그래서 저는 리드 프로덕트 엔지니어로 쉽게 참여할 수 있는 프레임워크를 제공하고09:32

더 자세한 사양을 제공하고 제가 알고 있는 지식으로 잘 정의되지 않은 부분을 보완하기 시작해요09:39

프로젝트를 통해 무엇을 달성하려고 하는지 파악한 후, 실행을 위해 TARS에게 다시 넘겨줘요.09:46

자, 이것이 프로젝트의 예시입니다.09:53

그리고 제가 말씀드린 것처럼, 제품 엔지니어링 프로세스를 중심으로 첫 번째 이정표를 설정해요.09:57

그래서 아직 힐탑 리뷰는 여기에서 진행하지 않았어요.10:04

그게 완료되면 이 티켓을 완료 처리할 거예요,10:07

그리고 TARS가 그것을 가져다가 프로젝트 구현의 다음 단계로 넘어갈 거예요.10:12

그래서 저희가 발견한 것은 많은 팀들이10:18

이제 에이전트가 모든 정보를 제공할 수 있기 때문에 프로젝트 브리프와 힐탑 작업을 더 많이 하고 있어요.10:22

글쓰기에서 흔히 있는 백지 현상과 같아요. 이미 정보가 들어있는 문서를10:29

정보가 있고, 에이전트들이 완벽하지 않다는 것을 알아요. 때로는 저희가 이 프로젝트를 통해 달성하려고 하는 목표를 지나치게10:34

과대평가해서 저희가 제시한 범위를 많이 잘라내야 할 때도 있지만 괜찮아요.10:40

엔지니어가 시간을 들여 입력하는 것보다 훨씬 간단해요.10:46

이러한 기본 요소를 직접 설정하는 것보다 훨씬 간단해서, 슬랙을 통해 이 작업을 계속 진행할 수 있어요,10:52

리니어(Linear)를 거쳐서 결국 깃허브(GitHub)에 풀 리퀘스트(PR)로 이어지죠.10:58

또 다른 중요한 점은, 코딩 에이전트를 사용해서 작업을 구현해야만 하는 경우는 없을 수도 있다는 거예요,11:04

우리 코딩 에이전트로 작업 단편을 구현할 필요는 없어요.11:07

데본(Devon)은 인기가 많아요. 많은 사람들이 데본을 사용하는 것을 좋아해요.11:12

데빈에게 티켓과 동일한 문서를 가리켜서 데빈이 필요한 맥락을 제공할 수 있어요.11:15

작업의 다른 부분을 구현하도록 할 수 있죠. 로컬 클라우드 코드와 마찬가지로 오퍼스(Opus)를 로컬 환경에서 사용하는 경우에도요.11:23

MCP를 통해 가져올 수 있어요,11:29

이 문서 조각들을 모두 가져와서 작업 맥락으로 사용할 수 있죠.11:32

그 작업에 활용할 수 있도록요.11:39

물론 프로젝트 채널에서 협업하는 사람들도 있어요.11:41

보시다시피 저희 보안팀은 새로운 프로젝트를 검토하고 보안에 미치는 영향을 평가하는 등 참여합니다.11:45

제가 개발 초기 단계에 말씀드린 것처럼, 저희는 자체 MCP 게이트웨이를 만들었어요.12:00

저희는 이걸 컨텍스트 엔진이라고 부릅니다.12:08

이것은 내부 시스템과 연결되고, 시스템 프롬프트와 컨텍스트를 생성하기도 해요.12:10

어떤 도구를 어떻게 사용해야 하는지, 언제 사용해야 하는지에 대한 정보를 제공합니다.12:17

그래서 저희의 주요 데이터 레이크인 Snowflake에 연결되어 있어요.12:22

저희는 제품 사용량을 설명하는 의미론적 테이블을 Snowflake에 구축했어요.12:27

또는 고객과의 대화도 있습니다. 그리고 저희 MCP 서버를 통해 에이전트를 제공할 수 있어요.12:33

도구 설명에는 테이블 목록이 여기에 있어요.12:39

이것은 그 내용이고, 이런 유형의 콘텐츠에 대한 질문에 답하려고 한다면12:44

콘텐츠에 대해 쿼리를 작성하세요. 그래서 저희에게 약간의 방향을 제시해 줘요.12:49

에이전트가 저희가 도구를 어떻게 사용하는지 이해하도록 도와주고요,12:54

저희가 리니어와 스노우플레이크를 어떻게 정리했는지 알려주고 정보를 어디서 찾을 수 있는지에 대한 안내도 제공해요.12:58

정말 놀라운 점은 저희가 지금 이 MCP 서버를 실제로 사용하고 있다는 거예요13:06

다른 여러 내부 도구에서도 사용하고 있어요. 슬랙에서 직접 쿼리를 할 수 있도록 열어줬거든요.13:12

데이터나 고객 분석을 위해 사용하는데, 처음에는 이것이 그냥13:19

저희 에이전트 또는 코딩 에이전트를 모든 시스템에 연결하는 방법일 거라고 생각했지만, 정말 굉장한13:24

저희 내부 팀들에게 큰 도움이 되고 있고, 다른 여러 도구를 이것을 기반으로 만들고 있어요.13:30

MCP 게이트웨이 위에 많은 도구를 구축하고 있으니, 소프트웨어에 대해 생각하기 시작한다면13:35

소프트웨어 팩토리에 대해 생각하기 시작한다면, 내부 MCP 게이트웨이 서버에 투자할 가치가 충분합니다.13:41

모든 도구를 연결하고, 에이전트가 해당 도구를 사용하는 방법을 알려주는 설명을 가지고13:48

그리고 정보가 어떻게 구성되어 있는지 구체적으로 설명합니다.13:53

그러면 다른 여러 사용 사례에서도 유용하게 사용할 수 있을 거라고 생각해요.13:56

제가 말씀드린 것처럼, 저희는 소프트웨어 개발의 다른 부분도 자동화하려고 노력하고 있어요.14:06

버그가 ...14:12

Slack을 통해 들어오는 요청이 있습니다. 그래서 TARS는 웹훅을 통해 이를 수신하고, 초기 분류 작업을 수행할 수 있어요.14:15

버그를 수정하기 위한 PR을 열고 구현하는 작업도 처리합니다.14:22

저희 고객님들도 Slack의 공유 채널에 많이 참여하고 계세요.14:25

TARS가 저희가 Slack을 통해 받는 지원 요청을 분류하는 데 매우 유용하다는 것을 알게 되었어요.14:30

그것 덕분에 코드를 보고 고객이 저희 제품 사용 중 어떤 문제를 겪고 있는지 파악할 수 있어요.14:37

코드 관점에서요. 저희가 주요 기능들을 어떻게 정리하는지 예시를 보여드렸어요.14:44

이것을 중심으로요. 그리고 마지막으로 정말 흥미로운 부분이 있어요.14:51

저희는 모두 스스로 개선되는 소프트웨어 또는 자율 주행 소프트웨어로 나아가려고 노력하고 있어요.14:54

그래서 저희는 자체 샌드박스 인프라를 구축하기 위해 TARS를 사용하고 있어요.14:59

저희는 일부 샌드박스를 서비스에서 벗어나 직접 소유하고자 해요.15:04

인프라 계층을 자체적으로 관리하려고요.15:09

그 이유 중 하나는 세션 정보에 대한 깊이 있는 제어를 원하기 때문이에요.15:13

그리고 인프라의 다양한 부분으로 워크로드를 이동할 수 있기를 바라요.15:19

그래서 다음으로 구축하고 있는 것은 저희의 메모리 레이어예요. 그리고 이것을 지속적인 컨텍스트로 만들고 싶어요.15:25

회사 내 모든 사람이 어떤 일을 하고 있는지, 어느 팀에 속해 있는지, 어떤 제품을15:32

책임지는지. 그리고 조직 수준에서 WorkOS와 우리가 일하는 방식에 대한 의미는 무엇인가요?15:38

이것을 소프트웨어 팩토리에 연결할 수 있을 뿐만 아니라, 그 맥락을 팩토리에서 꺼내서15:45

다른 AI 도구에도 적용하고 싶어요.15:51

이것이 우리가 얻은 주요 결론이라고 생각해요15:58

많은 사람들이 단순히 출력에만 노력을 기울이는 곳에서, 실제로16:01

팩토리에서 인간의 기하급수적인 가치를 얻을 수 있다고 생각해요.16:07

실제로 고객에게 가치를 제공할 수 있을까요?16:12

배송과 고객 영향에 대해 많이 생각하고 있기 때문에, 그것을 소프트웨어 팩토리 자체에 반영하고 싶어요.16:15

제품에 불안정성을 도입하는 것에 대해서는 확실히 걱정하고 있어요.16:23

그럼 결함률을 측정할 수 있을까요?16:28

그리고 다른 복구 시간 지표도요?16:31

그리고 많은 일화들을 살펴보고 싶어요. 저희 엔지니어들이16:35

TARS를 사용하는 것을 통해 가치를 얻고 업무 속도를 높이는지 확인하고 싶습니다.16:40

그들이 로컬 하니스에서 벗어나 클라우드 샌드박스로 이동하는 것을 보고 싶어요.16:46

그리고 실제 목표는 이 정보를 활용할 수 있다는 것입니다.16:58

저희가 인프라를 소유하고 있기 때문에 인프라에서 무슨 일이 일어나고 있는지 볼 수 있습니다.17:01

이 정보를 활용하여 팩토리를 자체 개선합니다. 학습하도록 만들고 싶습니다.17:04

코드 작성 방식에 대해 더 나아지도록 만들고 싶습니다.17:09

저희 엔지니어들이 어떤 부분을 개선할 수 있는지 확인하고 싶습니다.17:13

AI 분야에서 정말 많은 것들이 빠르게 움직이고 있어요.17:18

끊임없이 최신 팁과 기술을 따라잡기 위한 경쟁 같아요.17:21

저희는17:28

에이전트를 세션으로 지정해서 어떤 부분이 부족하고, 사람들이 저희 팩토리를 어떻게 사용하는지 확인할 수 있어요.17:29

에이전트가 실수를 했다면 어떤 기술을 개발해야 할까요?17:35

더 이상 필요 없는 기술은 무엇일까요? 코드가 바뀐 정도 때문에17:39

6개월 전에 작성한 기술이 쓸모없게 되었을 수도 있어요. 그래서 계속해서17:45

검증 작업을 진행해요. 세미 온라인은 저희가 실제로17:49

모든 인프라를 직접 소유하는 것이 큰 장점이라고 생각해요.17:55

세 번째로 말씀드리지만, 샌드박스는 정말 좋아요.18:02

에이전트를 실행하고 PR을 여는 것도 멋진 일이죠.18:08

저희는 소프트웨어 엔지니어링 방법과 프로세스에 대해 정말 심각하게 생각하고, 그걸 자동화에 담고 싶어해요.18:11

저는 라이언입니다. WorkOS에서 엔지니어 중 한 명이에요. 저희는 발표 구역 바로 맞은편에 부스를 마련해뒀어요.18:21

소프트웨어 벡터를 구축하고 계시다면, 정말 이야기 나누고 싶습니다. 어떻게 인증을 처리하는지 듣고 싶어요.18:26

저희가 아직 스스로 해결하지 못했기 때문에 이 부분에 대해서는 이야기하지 않았어요.18:31

하지만 여러분 중에 통찰력이 있을 수도 있으니, 부스에 들러주세요.18:36

저와 이야기 나누세요. 정말 즐겁게 대화할 수 있을 거예요. 감사합니다.18:39