스크립트
00:00:00제 이름은 클레어 리구리이고, AWS의 수석 프린시펄 엔지니어입니다.
00:00:17주로 저희의 에이전트 디코딩 어시스턴트인 키로(Kiro)를 담당하고 있지만, 오늘은
00:00:23아마존 내부 팀들 사이에서 목격하고 있는 몇 가지 관행에 대해 이야기하려 합니다. 그동안
00:00:28AI로 보아왔던 것과는 차원이 다른, 계단식 함수 형태의 흥미로운 생산성 향상 결과를
00:00:35확인할 수 있었습니다. 저는 3년 넘게 에이전틱 AI를 연구해 왔으며,
00:00:43AI 코딩 어시스턴트와 관련해 업계에서 일어난 진화 과정을 지켜보았습니다.
00:00:48처음에는 다음 줄이나 다음 함수 작성을 돕는 인라인 코드 완성 기능이 있었습니다.
00:00:55그후 코드에 대해 질문하는 채팅으로 발전했죠. 작년 어느 시점부터는 모두가 바이브 코딩을
00:01:02시작했지만, 이제는 저희가 '프런티어 개발(frontier development)'이라고 부르는
00:01:08초기 얼리어답터 단계가 나타나기 시작했습니다. 제 개인적인 경험에 비추어 보면,
00:01:14이전에 거쳐온 모든 단계에서는 생산성이 고작 10~20% 정도 향상된 것만 느꼈습니다.
00:01:20하지만 현재 아마존 내부에서는 전사의 다양한 팀들과 함께 파일럿을 운영 중이며,
00:01:27중앙값 기준 4.5배, 때로는 10배가 넘는 생산성 향상을 확인하고 있습니다. 따라서
00:01:34생산성에서 이러한 계단식 향상이 나타나면서 정말 많은 것이 변했습니다.
00:01:40저는 아마존 내부에서 '프런티어 개발자'라고 부르는 이들을
00:01:47제가 목격한 세 가지 행동 양식으로 정의하곤 합니다. 첫째는 핸즈오프 코딩입니다. 프런티어 개발자는 자신이 작성하는
00:01:54코드의 1~2% 정도만 직접 작성할 수도 있습니다. 나머지는 에이전트가 처리하죠. 둘째는 에이전트와
00:02:01자주 상호작용하지 않는다는 점입니다. 이들은 코딩 어시스턴트가 자신의 개입 없이
00:02:08최대 몇 시간 동안 실행되도록 목표를 설정합니다. 셋째는 유휴 시간을 최소화한다는 것입니다. 이러한 프런티어 개발자들은 경향이 있습니다
00:02:15여러 에이전트를 병렬로 실행하여 태스크 백로그를 빠르게 처리합니다. 프런티어
00:02:24개발자 팀을 처음 본 것은 베드락 맨틀(Bedrock Mantle) 팀이었습니다. 베드락은 저희의 모델 호스팅 서비스로, 클로드나 GPT 같은 LLM을 호스팅합니다.
00:02:34작년 어느 시점에, 베드락 팀은 새로운 추론 데이터 플레인을 구축해야 한다는 사실을 알고 있었습니다.
00:02:43하지만 인력 30명이 18개월 동안 작업해야 할 것으로 예상되었죠. 이는 매우 거대한 서비스입니다.
00:02:52새로운 시스템을 구축하고, 고객을 마이그레이션하며, 모델을 마이그레이션하는 데는 시간이 걸릴 예정이었습니다.
00:02:58그리고 그들은 한 발 물러서기로 결정했습니다. 6명의 인원으로 키로를 이용해 76일 만에 이를 구축해 냈습니다.
00:03:06정말 엄청난 성과였습니다. 아마존 내부에서 이런 종류의 성과를 본 것은 처음이었습니다.
00:03:12최대 20배에 달하는 생산성 향상이 가능함을 증명한 진정한 패스파인더 팀이었습니다. 이제 그들은 커밋을 살펴보았고,
00:03:21생산성 향상을 측정하는 다른 몇 가지 방법에 대해서도 이야기하겠습니다. 하지만
00:03:27이 이야기에는 한 가지 문제가 있었습니다. 그렇습니다, 6명이서 구축한 것이 맞습니다. 그것도
00:03:34두 명의 프린시펄 엔지니어를 포함해 사내에서 말 그대로 최고 수준의 엔지니어들이 참여했습니다. 따라서 이 팀은
00:03:40그냥 평범한 6명으로 구성된 팀이 아니었습니다. 분산 시스템 전문가이자 LLM 및 아키텍처 전문가들이었죠.
00:03:49그래서 이 이야기는 놀라웠고 아마존 전역에 들불처럼 퍼져나갔습니다. 하지만 동시에
00:03:57많은 팀들에게는 너무 달성하기 어려운 목표이기도 했습니다. 과연 다른 팀에서도 이것이 실제로
00:04:03재현될 수 있을지에 대한 많은 의문이 있었습니다. 그래서 제가 말씀드리고 싶은 또 다른 실험은
00:04:10프라임 비디오 조직에서 진행된 실험적 스프린트입니다. 10일간의 스프린트를 통해 실험을 진행했는데, 이번에도 엔지니어 6명을
00:04:19방에 모아두고 키로를 마음껏 활용하게 했습니다. 프로젝트 납기 예상 기간을 기존에
00:04:29예상되었던 90주에서 이 10일간의 스프린트 동안 이뤄낸 모든 진척도를 바탕으로 24주로 단축했습니다.
00:04:36그리고 이들은 커밋 기록을 살펴보았고, 이 10일간의 스프린트 이전에
00:04:42무엇을 했었는지, 그리고 이 10일 동안에만 얼마나 많은 커밋을 생성했는지 확인했습니다. 이 스프린트는 진정으로
00:04:49Bedrock Mantle 팀이 달성했던 것과 거의 비슷한 수준의 성과를
00:04:58하지만 이 이야기에도 역시 과제가 있었습니다. 온콜(On-call) 업무가 없고,
00:05:05회의도 제한적이며, 방해 요소가 거의 없는 방에 엔지니어 6명이 모여 있었다는 점입니다. 우리 모두가 알다시피 이는 엔지니어의 일상에서 흔치 않은 환경이죠.
00:05:12팀 내 시니어 엔지니어는 지난
00:05:203주 동안 이 6명의 엔지니어가 2주 동안 곧바로 실행할 수 있도록 상세한 요구사항이 담긴
00:05:28작고 잘 정의된 태스크들을 만드느라 시간을 보냈습니다. 따라서 이것 역시 반드시 현실의 모습이라고 볼 수는 없습니다.
00:05:35구조화된 스프린트이자, 이러한 성과를 낼 수 있었던 특정 시점의 일이었죠. 하지만 다시 한 번
00:05:41의문이 듭니다. 과연 실제 팀들의 일상적인 업무에서도 이것이 달성 가능할까요? 그래서 아마존 스토어즈는, 여기에는
00:05:51Amazon.com과 모든 소매 웹사이트 및 오프라인 매장이 포함되는데, 좀 더 체계적인 파일럿을 진행했습니다.
00:05:59초기 경력자, 중견 경력자, 시니어 엔지니어가 정규 분포를 이루는 아주 평범한 50개 팀을 지켜보았습니다.
00:06:07맨틀 팀이 처음부터 새로 구축할 수 있었던 그린필드 프로젝트가 아니라, 기존 코드베이스가 있는 기존 시스템을 다루는 팀들이었습니다.
00:06:14작년 하반기 대부분의 기간 동안 이들을 지켜본 결과, 매우 흥미로운 사실을 발견했습니다.
00:06:21절반의 팀과 나머지 절반의 팀 사이에 생산성 향상 폭에서 큰 차이가 난다는 점이었습니다.
00:06:28여기서 이들은 생산성 지표로 프로덕션 배포 속도를 사용했습니다. 단순한 커밋 횟수가 아니라,
00:06:34얼마나 많은 커밋을 생성하느냐가 아니라 변경 사항을 얼마나 빨리 고객에게 전달하느냐를 본 것입니다.
00:06:41얼마나 신속하게 기능을 배포할 수 있는가? 절반의 팀은 3배 미만의 증가를 기록한 것으로 나타났습니다.
00:06:483배 미만의 생산성 향상을 보인 팀들과, 중앙값 기준 4.5배, 어떤 경우에는 10배 이상 향상된 팀들 간의 차이를 가른 요인은
00:06:56바로 도구를 사용하는 방식이었습니다.
00:07:01이 팀들의 90%가 내부 도구 중에서도 키로를 사용했습니다. 발견된 사실은 도구 자체가 중요한 것이 아니라 일하는 방식이 중요하다는 점이었습니다.
00:07:11계단식 향상을 이뤄낸 팀들은 일하는 방식을 의도적으로 바꾸었지만,
00:07:18나머지 팀들은 기존의 일하는 방식 위에 키로와 기타 내부 도구들을 대충 얹어놓기만 했습니다.
00:07:26적어도 저에게는 이것이 큰 깨달음을 준 순간이었습니다. AI가 약속했던 엄청난
00:07:31생산성 향상을 그동안 온전히 체감하지 못했던 이유가 바로 일하는 방식을 바꾸는 데 있었다는 점을 깨달았죠.
00:07:39따라서 이번 파일럿 전반에 걸쳐 파일럿에 참여한 팀들은 물론 베드락 맨틀 팀, 프라임 비디오의 다른 팀들도 인터뷰한 결과, 다섯 가지 습관을 찾아냈습니다.
00:07:47제가 '습관'이라는 단어를 매우 의도적으로 사용하는 이유는, 단 한 번의 스프린트가 아니라 이를 매일 실천하는 것이 중요하기 때문입니다.
00:07:55이러한 다른 팀들, 즉 Bedrock Mantle 팀이나 Prime Video 팀도 조사하여 다섯 가지 습관을 찾아냈습니다. 제가
00:08:03일하는 방식을 바꿀 때 이러한 습관을 형성하기란 어렵고, 습관을 만드는 데는 시간이 걸립니다.
00:08:09그럼 하나씩 살펴보겠습니다. 첫 번째 습관은 에이전트 컨텍스트에 투자하는 것입니다.
00:08:15우리 머릿속에는 많은 정보가 들어 있으며, 우리는 슬랙 대화, 온보딩 멘토링,
00:08:22코드 리뷰, 스탠드업 및 스프린트 계획 등을 통해 그 정보들을 다른 사람에게 전달하곤 합니다. 그리고 이들은 그 모든 것을 문서화해야 했습니다.
00:08:30구축한 습관은, 에이전트가 실수를 하거나 내가 원하지 않는 방식으로 무언가를 처리할 때마다
00:08:35내 스킬 파일에 무엇이 빠졌는가? 에이전트에게 필요한 스티어링 파일에 무엇이 누락되었는가?를 자문하는 것이었습니다.
00:08:42하지만 우리도 알다시피, 지난해 동안 모델의 능력과 행동 양식은 엄청나게 도약했습니다.
00:08:50구축했어요. 에이전트가 실수를 하거나 내가 원하지 않는 방식으로 무언가를 처리할 때마다 생각하는 거죠.
00:08:55하지만 작년 11월에 나온 Opus 4.5부터는 그럴 필요가 훨씬 줄어들었으며,
00:09:01그 이후로 출시된 모든 새로운 모델 버전들과 함께 6개월 이상, 즉 반년이 넘는 개선 기간을 거쳤습니다.
00:09:09따라서 새로운 질문과 새로운 습관은 여전히 스티어링 파일에 이것이 필요한가? 아니면 단순한 컨텍스트 낭비(bloating)에 불과한가? 하는 것입니다.
00:09:16두 번째는 속도를 높이기 위해 속도를 늦추는 것입니다. 인터뷰에 응한 거의 모든 팀은
00:09:23새로운 일하는 방식을 의도적으로 도입함에 따라 오히려 생산성이 떨어졌다고 보고했습니다. 직관에 반하는 일이죠,
00:09:29그렇지 않나요? 생산성의 하키 스틱 곡선을 보기 위해서는 그 전에 의도적인 엔지니어링 작업을 수행해야 합니다.
00:09:35에이전트가 코드베이스에서 성공적으로 작동하려면, 특히 브라운필드 기존 코드베이스에서는 먼저 코드베이스 내에서 실제 작업을 수행해야 하기 때문입니다.
00:09:41그래서 에이전트 컨텍스트를 구축해야 했고, 모델이 실패했을 때 무슨 일이 일어났는지 알 수 있도록 기존 도구의 오류 메시지를 개선했으며,
00:09:48모델이 필요한 작업을 실제로 완수할 수 있도록 돕는 새로운 도구와 새로운 MCP 서버를 구축했습니다.
00:09:53많은 팀들이 에이전트가 더 쉽게 코드를 탐색할 수 있도록 코드베이스를 재구조화했습니다.
00:09:59심지어 코드베이스의 프로그래밍 언어를 바꾸는 것과 같은 과감한 변화도 목격했습니다. 파이썬이나 자바스크립트는
00:10:05타입이 지정되지 않은 언어이기 때문에 팀들이 어려움을 겪는 것을 자주 보았습니다. 테스트하기 어렵고,
00:10:11컴파일러 오류가 없습니다. 그래서 모델이 대충 추측해서 결과를 건네줍니다. 이에 따라
00:10:17타입스크립트로 전환하는 팀들을 보았습니다. 러스트(Rust)도 아마존 내에서 큰 인기를 얻고 있습니다. 컴파일러가 훌륭한 오류 메시지를 제공하기 때문입니다.
00:10:24이런 고생을 할 필요가 없죠. 하지만 생산성 향상을 위해 이러한 의도적인 변화를 꾀하는 팀들이 많습니다.
00:10:29에이전트가 더 쉽게 탐색할 수 있도록 했습니다. 심지어 프로그래밍 언어를
00:10:36아예 바꾸는 과감한 변화까지 보았습니다. 파이썬이나 자바스크립트는 동적 타이핑 언어이기 때문에
00:10:43팀들이 어려움을 겪는 것을 자주 보았습니다. 테스트가 어렵고 컴파일러 에러가 없죠.
00:10:50그래서 모델이 대략 추측해서 결과를 돌려줍니다. 그 후 팀들이 타입스크립트로 전환하는 것을 보았고, 러스트는
00:10:56아마존 내부에서 매우 인기가 높아졌습니다. 컴파일러가 훌륭한 에러 메시지를 제공하므로 직접 할 필요가 없죠.
00:11:03하지만 많은 팀이 생산성 향상을 위해 이러한 의도적인 변화를 들이고 있습니다.
00:11:09세 번째는 에이전트에게 밥을 먹이는 것이지, 베이비시팅을 하는 게 아니라는 점입니다. 제게는 이것이 왜 우리가
00:11:16이러한 단계적 생산성 향상을 목격하고 있는지 깨닫게 된 아하 순간 중 하나였습니다. 만약 바이브 코딩을 하고 있다면,
00:11:23하루 종일 에이전트와 대화를 주고받고 있다면, 당연히 4~5배의 생산성
00:11:30향상을 볼 수 없을 것입니다. 왜냐하면 내내 루프 안에 갇혀 있기 때문입니다. 아마도
00:11:36코드가 생성되고 검토할 코드를 가지고 돌아올 때까지 30초에서 1분 동안
00:11:42그 자리에 앉아 기다리게 될 것입니다. 거기에 앉아서 기다리고 있다면 다른 일을 할 수 없습니다.
00:11:48다른 작업을 하기가 어렵습니다. 에이전트를 병렬로 실행하기도 어렵고 자신을 여러 에이전트로
00:11:55복제하기도 매우 어렵습니다. 따라서 대화가 왼쪽과 같다면 에이전트를 활용하는 것이 아니라
00:12:01오른쪽처럼 에이전트가 무엇을 해야 하고 어떻게 스스로 검증할 수 있는지 먹이를 주는 셈이 됩니다.
00:12:08그래야 에이전트가 스스로 수정하고, 특정 품질 기준을 충족할 때, 즉 실제 실행되어
00:12:14컴파일되고 테스트를 통과할 때, 테스트가 가능하고 높은 커버리지를 가질 때만 여러분을 찾게 됩니다.
00:12:20물론 다음 단계는 이 모든 내용을 지침 파일에 넣는 것입니다. 그러면 프롬프트를 입력하지 않아도 매번 그렇게 작동합니다.
00:12:26지침 파일에 넣는 것입니다. 그러면 프롬프트를 입력하지 않아도 매번 그렇게 작동합니다.
00:12:33네 번째 습관은 의도를 명확하게 만드는 것입니다. 아마존에서는 사양 및 개발 방식을 많이 실천하고 있습니다.
00:12:40우리는 그것을 Kiro 제품에 내장했습니다. 그래서 아마존 엔지니어들이 Kiro에서 이를 채택하는 것은 매우 자연스럽습니다.
00:12:46최첨단 엔지니어링과 달리 바이브 코딩에서 전형적으로 보아온 것은 매우 고수준의 프롬프트를 제공하고,
00:12:54에이전트가 수많은 코드를 생성하게 한 다음, 오, 이건 정말 내가 뜻한 게 아니야, 요구사항을 정확히
00:13:02맞추지 못했잖아 하며 앞뒤로 대화를 주고받는 것입니다.
00:13:10아니, 사실 그런 식으로 만들고 싶었던 게 아니야. 여기 기술 설계서가 있어. 의도 자체가 잘못되었을 때 코드에 대해 에이전트와 반복 작업하는 것은
00:13:17생산성이 떨어진다는 것을 알게 되었습니다. 그래서 모호하고 복잡한 기능의 경우 아마존 엔지니어들은 종종
00:13:26사양서를 작성하는 과정을 거치게 됩니다.
00:13:34물론 Kiro에서는 이 전체 사양서를 직접 작성할 필요 없이 모델이 생성하도록 할 수 있습니다.
00:13:39하지만 코드베이스 전반에 흩어져 있는 코드 변경 사항에 대해 논의하는 것보다 문서에 대해 모델과
00:13:46주고받으며 소통하는 것이 훨씬 쉽습니다. 다섯 번째는 테스트를 왼쪽으로 이동(Shift-left)하는 것입니다.
00:13:56여기서 핵심 중 하나는 에이전트에게 빠른 피드백 루프를 제공하는 것입니다. 그래야 에이전트가 몇 시간 동안 스스로 수정 작업을 계속할 수 있기 때문입니다.
00:14:04에이전트는 실수를 할 것이며, 그것은 괜찮습니다. 하지만 올바른 신호를 주면 스스로 수정하고 그 과정을 한참 동안 수행할 수 있습니다.
00:14:12그래서 팀들이 린터, 유닛 테스트, 통합 테스트, 성능 테스트, 보안 테스트를 추가하는 것을 보았습니다.
00:14:20이것들은 모두 우리가 처음부터 계속했어야 한다는 것을 알고 있던 것들입니다. 좋은 엔지니어링 위생과 관행이죠.
00:14:24하지만 이제는 이에 투자할 가치가 드디어 충분해졌다고 생각합니다.
00:14:32많은 팀이 하고 있는 것 중 하나는 서비스를 모의 객체(mock)로 대체하는 것입니다.
00:14:40통합 테스트의 경우, 라이브 서비스를 포함하여 전체 시스템을 엔드투엔드로 테스트하곤 했습니다.
00:14:46하지만 결정론적 응답과 함께 완전히 로컬에서 실행되는 모의 서비스에 많은 투자를 해왔습니다.
00:14:52에이전트가 모든 것을 로컬에서 수행할 수 있게 해주기 때문입니다. 수많은 다른 서비스를 띄우고 클라우드 서비스에 연결할 필요 없이
00:15:01랩탑에서 모든 것을 처리하면 모든 것이 훨씬 빨라집니다.
00:15:07에이전트가 빠른 피드백을 받을 수록 더 많은 루프를 돌 수 있고, 에이전트 자체의 생산성도 더 높아지기 때문입니다.
00:15:14지금까지 말씀드린 것들이 우리가 보아온 몇 가지 습관입니다.
00:15:21하지만 이 모든 습관을 채택하면 해탈의 경지에 이르러 세상에서 가장 생산적인 엔지니어링 조직이 될 것이라고 말씀드리면 거짓말이겠죠.
00:15:28해탈의 경지에 이르러 세상에서 가장 생산적인 엔지니어링 조직이 될 것이라고 말씀드리면 거짓말이겠죠.
00:15:35여전히 일은 어렵습니다. 우리는 여전히 얼리 아답터 단계에 있으며 팀들은 여전히 방법을 찾아가는 중입니다.
00:15:42조직 차원에서 팀들 사이에 공통으로 나타나는 위험 중 하나는 번아웃입니다.
00:15:48이 용어를 제가 만든 것은 아니며 어떤 컨퍼런스에서 누가 만들었는지 기억 안 나지만 FOMAT은 실존합니다.
00:15:56엔지니어들이 밤늦게까지 깨어 있어 에이전트가 밤새 몇 시간 동안 실행되도록 완벽한 프롬프트를 만들려고 하는 것을 봅니다.
00:16:03그래야 아침에 코드 변경 사항이 준비되어 일어날 수 있으니까요. 여러 에이전트를 병렬로 실행할수록 인지 부하가 증가하고
00:16:09여러 에이전트를 병렬로 실행할수록 인지 부하가 증가하고, 터미널 탭 사이를 끊임없이 전환하게 됩니다.
00:16:15또한 AI 결과물을 검토하는 것이 실제로 작성하는 것보다, 특히 경력 초기 개발자들에게는 더 어렵다는 것을 알 수 있습니다.
00:16:22시니어 엔지니어들은 이미 커리어의 상당 부분을 다른 사람의 코드를 검토하는 데 보냈습니다.
00:16:29하지만 주니어 엔지니어들은 아직 그런 근육이 없습니다. 따라서 검토하는 것이
00:16:37실제로 코드를 작성할 때 익숙했던 것보다 훨씬 더 큰 인지 부하로 느껴질 수 있습니다.
00:16:44또 다른 문제는 조직의 변화입니다. 엔지니어로서 일하는 방식을 바꾸는 것은 이미 어려운 일입니다.
00:16:52최첨단 엔지니어가 되면 하루 종일 보내는 방식이 완전히 달라집니다. 하지만 조직도
00:16:58최첨단 엔지니어링 팀을 지원하기 위해 변화해야 합니다. 매우 흔하게 본 것 중 하나는 속도를 내기 위해 느려지는 것을 받아들이는 것입니다.
00:17:07저 자신도 이런 과오를 범했습니다. 다른 리더 동료들도 마찬가지로 이렇게 말하곤 했습니다.
00:17:14이제 AI 도구도 있고 모델도 정말 놀랍잖아. 왜 더 빨리 진행하지 못하는 거지?
00:17:22그 이유는 코드베이스에 투자하여 팀에 가장 적합한 모범 사례를 찾고, 팀의 어려운 습관 변화를 만들기 위해
00:17:29두 달이라는 시간을 투자해야 하기 때문입니다. 이 놀라운 모델들이 생겼고
00:17:38X(구 트위터)상의 많은 기업들이 하루에 20개의 PR을 배포한다고 하니
00:17:44매달 기능을 배포할 것이라고 끊임없이 기대한다면, 우리는 속도를 내기 위해 속도를 늦춰야 합니다.
00:17:54두 번째는 조직 전체로 너무 빨리 너무 광범위하게 확장하는 것입니다.
00:18:01대규모 조직의 모든 팀이 즉시 최첨단 팀이 될 것을 기대했다면, 우리는 패스파인더나
00:18:08스프린트 실험, 아마존 내 파일럿 팀들로부터 얻은 배움을 얻지 못했을 것입니다.
00:18:16이제 우리의 과제는 이를 어떻게 확장할 것인가이며, 그것이 2026년의 핵심입니다.
00:18:22아마존에게 있어 2026년은 이를 50개 팀이 아니라 그다음 2,000개 팀으로 어떻게 확장할 것인가에 대한 해답을 찾는 것입니다.
00:18:31너무 빨리 도입하면 무엇을 해야 할지 모르는 팀들이 많아지게 됩니다.
00:18:37조직에 가장 적합한 모범 사례와 조직에 필요한 맥락을 찾을 시간이 없었던 것입니다.
00:18:43그리고 마지막은 새로운 병목 현상을 발견하게 될 것이라는 점입니다.
00:18:49예전에는 수동으로 코드를 작성하는 것이 병목 현상이었습니다. 하지만 아마존 내에서 우리가 발견한 것은
00:18:58의사결정 속도가 새로운 병목 현상이 된다는 점입니다. 새 제품을 실제로 만들지에 대한 결정을 검토하는 데 시간을 많이 쓸수록,
00:19:05코드를 작성하는 데는 1~2개월밖에 걸리지 않기 때문에 제품을 빌드하는 속도는 오히려 느려집니다.
00:19:12제품 출시와 관련된 모든 검토 프로세스가 병목 현상이 됩니다.
00:19:20예전에는 새 제품을 만드는 데 9~12개월이 걸렸을 때는 전체적인 과정에서 그 비중이 그렇게 크지 않았습니다.
00:19:27제품 제작을 결정하는 데 두 달, 출시를 승인하는 데 두 달이 걸린다면 말이죠.
00:19:33하지만 이제는 그것들이 병목 현상, 즉 가장 오래 걸리는 긴 막대가 됩니다. 그래서 우리를 늦추는 이러한 모든 것들을 마주하게 됩니다.
00:19:40최첨단 엔지니어링 팀은 코드를 작성하는 것보다 의사결정을 내리는 데 더 많은 시간을 보낸다는 것을 종종 발견합니다.
00:19:48따라서 특히 쉽게 되돌릴 수 있는 결정을 중심으로 빠른 의사결정을 내릴수록 좋습니다.
00:19:54그러므로 제가 여기에 계신 모든 분들께 드리고 싶은 한 가지 핵심 메시지는 최첨단 엔지니어링이란 일하는 방식을 의도적으로 바꾸는 것에 관한 것입니다.
00:20:03그리고 그것은 어렵습니다. 시간이 걸립니다. 그것은 새로운 습관과 새로운 일하는 방식을 형성하는 것입니다.
00:20:10이는 모든 엔지니어링 팀뿐만 아니라 조직 전체에 해당됩니다.
00:20:18따라서 여러분이 AI 도구와 어떻게 상호작용하고 있는지, 그리고 반복 작업에서 벗어나기 위해 어떻게
00:20:27방식을 바꿀 수 있을지 고민해 보시길 권장합니다. 감사합니다. 뒤쪽에 질문이 있으신 분들이 있다면 조금 남아 있겠습니다.
00:20:34오늘 시간 내주셔서 감사합니다.