WEBVTT 00:00:00.000 --> 00:00:07.840 마이크로소프트 365, 코파일럿, AI, 에이저와 업무의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비하셨나요? 00:00:08.300 --> 00:00:11.960 오는 1월, M365 컨이더 커진 규모로 돌아옵니다. 00:00:12.180 --> 00:00:18.400 전세계 MVP와 업계 전문가들이 제공하는 라이브 세션, 실무 데모, 실용적인 지식을 직접 경험해보세요. 00:00:18.620 --> 00:00:21.540 뻔한 슬라이드는 없습니다. 지루한 유행어도 없습니다. 00:00:21.900 --> 00:00:29.300 코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실제적인 과제들을 다룹니다. 00:00:29.300 --> 00:00:35.180 IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위해 마련된 세션이 준비되어 있습니다. 00:00:35.640 --> 00:00:40.140 10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 소통할 수 있습니다. 00:00:40.580 --> 00:00:44.640 라이브로 시청하고 실무에 바로 적용할 수 있는 인사이트를 얻어가세요. 00:00:44.880 --> 00:00:50.940 2027년 1월, 10일간의 행사, 하나의 마이크로소프트 커뮤니티, 지금 바로 등록하세요. 00:00:51.800 --> 00:00:55.760 M365 con.net에 접속하여 오늘 바로 자리를 확보하세요. 00:00:56.760 --> 00:00:58.600 M365 con.net입니다. 00:00:59.300 --> 00:01:04.600 M365 con.net에서 참여하시고 1월 라이브 행사에서 뵙겠습니다. 00:01:05.000 --> 00:01:10.380 솔루션을 열자마자 복잡하게 얽힌 파일과 참조, 그리고 숨어있는 버그 때문에 압도당한 경험이 있으신가요? 00:01:10.640 --> 00:01:12.060 여러분만 그런 것은 아닙니다. 00:01:12.240 --> 00:01:15.440 대부분의 개발자는 여기를 수정하고 저기를 디버깅하는 식으로 수동적인 작업을 합니다. 00:01:15.600 --> 00:01:20.160 기터브 코파일럿 위 에이전트 모드는 더 넓은 컨텍스트를 유지하고 파일 전반의 변경사항을 조율하는 것을 목표로 합니다. 00:01:20.160 --> 00:01:25.080 이 영상에서는 실제 넷 및 에이저 프로젝트에서 해당 워크플로우가 어떻게 작동하는지 보여드리겠습니다. 00:01:25.380 --> 00:01:28.500 실제 솔루션을 살펴보고 에이전트 적용 전후의 모습을 비교해보겠습니다. 00:01:28.840 --> 00:01:36.300 더 적은 오버헤드로 다중파일 코드를 생성하고 파일 간 오류를 더 빠르게 해결하며 일반 언어 사양으로 기능을 스케폴딩하는 방법을 확인하실 수 있습니다. 00:01:36.520 --> 00:01:41.520 본격적으로 시작하기 전에 우리 모두가 매일 겪는 디버깅 루프의 숨겨진 비용에 대해 먼저 이야기해봅시다. 00:01:41.520 --> 00:01:46.300 패치워크 디버깅의 숨겨진 비용. 간단해 보이는 오류를 수정하려고 자리에 앉습니다. 00:01:46.540 --> 00:01:50.500 애플리케이션이 빌드되지 않고 콘솔은 메인 프로젝트 파일에 한 줄을 가리킵니다. 00:01:50.680 --> 00:01:56.080 메서드를 수정하고 다시 컴파일한 뒤 해결했다고 생각했지만 메시지는 약간 다른 형태로 다시 나타납니다. 00:01:56.300 --> 00:01:59.280 진짜 문제를 찾기 전까지 또 30분이 훌쩍 지나갑니다. 00:01:59.460 --> 00:02:02.660 다른 프로젝트 폴더에 숨겨져 있던 누락된 종속성이 원인이었습니다. 00:02:02.840 --> 00:02:07.200 참조를 수정하고 다시 배포할 때쯤이면 오후 시간 대부분이 패치 작업으로 사라져버립니다. 00:02:07.480 --> 00:02:09.740 계획했던 기능 개발 업무는 내일로 미뤄집니다. 00:02:09.740 --> 00:02:12.380 이런 패턴은 너무나 흔해서 이제는 당연하게 느껴질 정도입니다. 00:02:12.520 --> 00:02:15.720 겉으로 보기에는 버그를 잡을 때 마다 성취감을 느끼며 앞으로 나아가는 것처럼 보입니다. 00:02:15.900 --> 00:02:17.920 하지만 실제로는 제자리 걸음을 하고 있는 셈이죠. 00:02:18.100 --> 00:02:21.200 코딩, 컴파일, 오류 발생, 수정, 그리고 반복. 00:02:21.360 --> 00:02:26.540 원인과 결과를 쫓느라 몇 시간이 사라지고 결국 의미 있는 개선보다는 수동적 인대처에 그치게 됩니다. 00:02:26.780 --> 00:02:29.620 이런 루프에 빠져 오후 시간을 허비해본 분들이 얼마나 계신가요? 00:02:29.820 --> 00:02:32.480 한 줄 댓글을 남겨주시면 상위 댓글 들을 읽어보겠습니다. 00:02:32.880 --> 00:02:37.300 이 악순환이 지치는 이유는 주변 도구는 계속 발전하는데 패턴은 그대로이기 때문입니다. 00:02:37.300 --> 00:02:43.920 편집기는 새로운 기능을 추가하고 프레임워크는 진화하며 통합은 더 깊어지지만 디버깅은 여전히 수동적인 접근 방식을 요구합니다. 00:02:44.080 --> 00:02:46.820 마치 양동이 하나로 번지는 불길을 막으려는 것과 같습니다. 00:02:47.160 --> 00:02:52.680 매번 발생하는 화재는 즉각 처리되지만 불씨를 일으킨 근본적인 조건은 남아있어 다음 화재가 거의 확실시됩니다. 00:02:52.840 --> 00:02:55.500 탭을 전환할 때마다 숨겨진 비용은 계속 늘어납니다. 00:02:55.760 --> 00:02:59.300 서비스 클래스에서 설정 파일로 이동하고 다시 의존성 그래프로 건너뛰습니다. 00:03:00.100 --> 00:03:04.360 전환할 때마다 붙잡고 있던 논리의 흐름은 끊어지고 강제로 정신적 재설정을 하게 됩니다. 00:03:04.360 --> 00:03:09.920 창을 전환하는 데 드는 몇 초의 문제가 아니라 맥락을 반복해서 재구성해야 하는 정신적 소모가 문제입니다. 00:03:10.060 --> 00:03:12.900 하루 종일 이런 작은 재설정들이 쌓여 큰 부담이 됩니다. 00:03:13.120 --> 00:03:16.780 개별 개발자에게 이러한 피로감은 좌절과 시간 낭비로 나타납니다. 00:03:16.980 --> 00:03:20.160 엔터프라이즈 프로젝트를 수행하는 팀에게는 그 영향이 배가 됩니다. 00:03:20.440 --> 00:03:26.740 디버깅 반복은 스프린트 목표를 궤도에서 이탈하게 하고 기능 출시를 지연시키며 줄어드는 속도보다 빠르게 쌓이는 백로그를 만듭니다. 00:03:26.880 --> 00:03:31.100 기술부채가 심화되는 것은 불을 끊으라 낭비되는 시간의 또 다른 부작용일 뿐입니다. 00:03:31.100 --> 00:03:35.540 많은 팀이 개발 시간의 상당 부분을 수동적 인디버깅에 속고 있다고 보고합니다. 00:03:35.740 --> 00:03:37.740 엔지니어링에서 흥미로운 부분이 아닙니다. 00:03:37.920 --> 00:03:41.760 똑같은 의존성 불일치를 5번씩 쫓아다니는 로드맵을 계획하는 사람은 없습니다. 00:03:42.080 --> 00:03:44.640 하지만 매주 팀의 역량은 바로 여기에 소모됩니다. 00:03:44.900 --> 00:03:50.960 오류 수정이 진척의 기준이 되면 새로운 기능 개발은 뒷전이 되고 아키텍처는 조용히 망가져갑니다. 00:03:51.140 --> 00:03:55.360 불편한 진실은 임시방편적인 디버깅이 단순히 속도만 늦추는 게 아니라는 점입니다. 00:03:55.560 --> 00:03:58.400 그것은 설계 중심이 아닌 반응 중심의 문화를 강화합니다. 00:03:58.400 --> 00:04:01.960 여러분은 시스템을 구축하는 것이 아니라 불을 끄는 데 시간을 쓰고 있습니다. 00:04:02.200 --> 00:04:07.480 단기적으로는 제품을 유지할 수 있을지 몰라도 팀이 얼마나 확장할 수 있는지 얼마나 자신있게 출시할 수 있는지를 제안합니다. 00:04:07.640 --> 00:04:10.160 자 소방활동 이라는 이 이미지에 대해 잠시 생각해보죠. 00:04:10.300 --> 00:04:12.700 불이 난 곳으로 달려가 물을 붓고 다음 장소로 이동합니다. 00:04:12.920 --> 00:04:14.980 문제는 개발자들이 일을 못해서가 아닙니다. 00:04:15.160 --> 00:04:15.860 잘하고 있죠. 00:04:16.120 --> 00:04:18.360 문제는 불길이 절대 멈추지 않는다는 것입니다. 00:04:18.620 --> 00:04:25.100 불길은 그저 위치를 바꿔가며 새로운 파일, 프로젝트, 설정에서 다시 타오르며 모두를 창조 모드가 아닌 대응 모드에 머물게 합니다. 00:04:25.100 --> 00:04:28.980 그렇다면 이 악순환이 오롯이 개인의 몫이 아니라면 어떨까요? 00:04:29.280 --> 00:04:36.180 추적, 전환, 패치의 반복적인 과정이 다르게 관리되고 여러분은 오직 구축에만 집중할 수 있다면 어떨까요? 00:04:36.360 --> 00:04:40.980 소방활동의 부담은 분명하지만 우리가 아직 다루지 않은 또 다른 압박지점이 있기 때문입니다. 00:04:41.160 --> 00:04:44.860 프로젝트가 단순히 하나의 파일이나 모듈이 아닐 때 진짜 부담이 시작됩니다. 00:04:45.060 --> 00:04:48.280 수정이 필요한 부분이 여러 계층에 걸쳐 있을 때가 바로 그렇습니다. 00:04:48.520 --> 00:04:54.600 로직이 서로 다른 프로젝트, 서비스, 라이브러리에 흩어져 있는 솔루션을 열고 앉아있다고 상상해보세요. 00:04:54.600 --> 00:05:00.320 필요한 기능이 세 곳에 나누어져 있고 이를 머릿속으로 정리하는 것 자체가 큰 싸움입니다. 00:05:00.900 --> 00:05:03.720 다중파일의 혼란 대 AI 위 컨텍스트 제어. 00:05:03.880 --> 00:05:08.320 프로젝트가 여러 계층에 걸쳐 있을 때 진짜 도전과제는 코드를 작성하는 게 아닙니다. 00:05:08.540 --> 00:05:10.860 모든 움직이는 요소들을 하나로 묶어두는 일입니다. 00:05:11.040 --> 00:05:15.860 다중파일의 혼란과 AI 기반 컨텍스트 제어 사이의 긴장감이 가장 명확하게 드러나는 지점이 바로 여기입니다. 00:05:16.040 --> 00:05:19.120 10개 이상의 프로젝트로 구성된 대규모 넷솔루션을 예로 들어보겠습니다. 00:05:19.540 --> 00:05:22.300 새로운 기능은 보통 여러 계층을 동시에 건드리게 됩니다. 00:05:22.300 --> 00:05:27.640 한 곳에는 컨트롤러가, 다른 곳에는 서비스가, 또 다른 곳에는 구성 파일 세트가 존재하죠. 00:05:27.840 --> 00:05:35.440 코드 한 줄을 쓰기도 전에 참조를 추적하고 위존성을 확인하며 작은 변경이 전체에 예상치 못한 오류를 일으키지 않기를 바라며 시간을 보냅니다. 00:05:35.660 --> 00:05:37.440 그런 워크플로우는 예외가 아닙니다. 00:05:37.660 --> 00:05:42.560 엔터프라이즈 애플리케이션에서는 일반적인 일이며, 특히 에이저 서비스와 통합이 도입되면 더욱 그렇습니다. 00:05:42.800 --> 00:05:45.000 이런 시스템의 구조는 평면적이지 않습니다. 00:05:45.000 --> 00:05:49.960 인터페이스, 위존성 주입 맵핑, 그리고 프로젝트 간 참조가 모두 중요한 역할을 합니다. 00:05:50.160 --> 00:05:58.400 에이저가 포함되면 일부 위존성은 솔루션 폴더를 완전히 벗어나 함수 앱, 서비스 버스 바인딩, 리소스 설정, 스토리지 연결 등으로 뻗어나갑니다. 00:05:58.600 --> 00:06:03.580 여러분은 IDE 위 코드, 디스크의 설정 파일, 클라우드에 정의된 서비스 사이를 조율해야 합니다. 00:06:03.780 --> 00:06:06.500 그 어떤 것도 여러분이 클릭을 줄이고 싶어 한다는 사실에는 관심이 없습니다. 00:06:06.740 --> 00:06:10.200 컨텍스트를 전환할 때마다 전체적인 그림을 다시 구성하는 데 에너지를 낭비하게 됩니다. 00:06:10.200 --> 00:06:13.280 우리 대부분은 그 컨텍스트를 작업 기억력으로 감당하려고 애씁니다. 00:06:13.420 --> 00:06:16.660 처음에는 관리할 수 있지만 프로젝트가 커지면 실수가 끼어들게 됩니다. 00:06:16.900 --> 00:06:19.900 서비스에 새 메서드를 추가하고는 DI 등록을 잊어버리는 시기죠. 00:06:20.060 --> 00:06:24.940 에이저 함수를 코딩하다가 나중에 야호스트, 제이선이나 배포 템플릿에 바인딩이 추가되지 않아듬을 깨닫기도 합니다. 00:06:25.120 --> 00:06:28.540 런타임이 되기 전까지는 아무것도 알려주지 않기에 결국 개발이 아닌 디버깅을 하게 됩니다. 00:06:28.740 --> 00:06:30.480 코드 자체가 어려운 부분은 아닙니다. 00:06:30.640 --> 00:06:32.460 바로 파일 간의 조율이 어려운 것이죠. 00:06:32.460 --> 00:06:41.640 컨트롤러에서 서비스로, 모델로, 다시 설정 파일로 탭으로 가다 결국 왜 그 파일을 열었는지 조차 잊어버리는 기분, 모두가 잘 아실 겁니다. 00:06:41.900 --> 00:06:44.760 하루에도 수십 번씩 반복되는 작은 방해 요소입니다. 00:06:45.000 --> 00:06:48.420 이런 상호작용이 쌓이면 실제 진도를 늦추는 마찰이 발생합니다. 00:06:48.640 --> 00:06:54.020 결과적으로 전달 속도가 느려지는데, 이는 작성이 느려서가 아니라 모든 것을 동기화하느라 집중력이 흐트러지기 때문입니다. 00:06:54.020 --> 00:06:57.300 이런 오버헤드는 클라우드 우선 프로젝트일수록 더 커집니다. 00:06:57.480 --> 00:07:06.260 에이전은 로컬 구성 파일, 환경 변수, 암 또는 바이셉 템플릿, CIE, CD 파이프라인 등 여러 곳의 핵심 설정을 분산시킵니다. 00:07:06.440 --> 00:07:10.740 단일 기능 요청처럼 보이는 작업이 실제로는 4가지 추상화 계층에 걸쳐 퍼져 있는 경우가 많습니다. 00:07:10.960 --> 00:07:12.820 이러한 복잡성은 선택사항이 아닙니다. 00:07:13.020 --> 00:07:15.040 생태계가 작동하는 방식에 내재되어 있습니다. 00:07:15.400 --> 00:07:18.060 이제 에이전트 모드가 잠재적 인 변화의 계기로 등장합니다. 00:07:18.320 --> 00:07:22.960 모든 조정 작업을 사용자에게 맡기는 대신, 여러 파일에 걸쳐 더 넓은 문맥을 유지하도록 설계되었습니다. 00:07:22.960 --> 00:07:26.980 즉, 한 계층에서 변경을 요청하면 다른 계층을 무시하지 않습니다. 00:07:27.160 --> 00:07:34.520 데모에서는 새로운 에이저 함수를 생성하여 에이전트가 메서드 복문을 생성하고 바인딩 구성을 만들며 호스트를 업데이트하는 과정을 보여드리겠습니다. 00:07:34.860 --> 00:07:37.940 JSON 파일은 물론 올바른 DI 등록까지 제한해줍니다. 00:07:38.160 --> 00:07:41.020 이는 보통 여러 파일에 흩어져 있는 다단계 프로세스입니다. 00:07:41.280 --> 00:07:43.780 에이전트는 이를 하나의 흐름으로 간소화할 수 있습니다. 00:07:44.060 --> 00:07:50.220 이는 여러분의 판단을 대체하는 것이 아니라 반복적인 관리 작업을 제거하여 실제 설계 선택에 집중할 수 있게 하는 것입니다. 00:07:50.220 --> 00:07:54.220 사람은 대략 적인 계율을 머릿속에 담아두거나 화이트보드에 스케치할 수 있습니다. 00:07:54.460 --> 00:07:58.000 AI는 전체 흐름을 놓치지 않고 파일별로 세부사항을 추적할 수 있습니다. 00:07:58.240 --> 00:08:02.180 우리에게 엄청난 인지 부하처럼 느껴지는 것이 에이전트에게는 기본적인 문맥일 뿐입니다. 00:08:02.380 --> 00:08:07.240 실제 차이점은 분산된 탭을 넘나드는 작업에서 동기화가 유지되는 통합된 변경 작업으로 전환된다는 것입니다. 00:08:07.400 --> 00:08:12.320 데모 도중 에이전트가 생성 한풀 리퀘스트 나딕을 띄워 어떤 편집이 이루어졌는지 정확히 보여드리겠습니다. 00:08:12.660 --> 00:08:14.000 이러한 가시성은 중요합니다. 00:08:14.000 --> 00:08:19.100 여러 파일을 업데이트하는 번거로운 작업은 자동으로 처리되면서 여러분은 검토하고 승인하는 완전한 통제권을 갖게 됩니다. 00:08:19.240 --> 00:08:26.040 따라서 오후 내내 파편화된 코드 조각을 이어붙이는 대신 한 번의 지시로 변경을 수행하고 생성된 업데이트를 확인한 뒤 상위 수준의 설계로 넘어갈 수 있습니다. 00:08:26.260 --> 00:08:33.900 클릭이나 키 입력을 줄이는 것만이 아니라 수십 개의 파일이 어떻게 연결되는지 되짚어보는 대신 실제 문제를 해결하는 데 집중할 수 있다는 점이 진정한 안도감을 줍니다. 00:08:34.120 --> 00:08:37.140 이러한 장점은 시스템이 고장났을 때 가장 확실하게 드러납니다. 00:08:37.140 --> 00:08:42.040 강력한 문맥 처리에도 불구하고 시스템은 실패하고 구성은 달라지며 참조 불일치가 다시 발생하기 때문입니다. 00:08:42.140 --> 00:08:44.040 바로 여기서 다음 시험대가 시작됩니다. 00:08:44.240 --> 00:08:47.340 오류가 발생했을 때 이를 어떻게 추적하고 해결할 것인가 하는 점입니다. 00:08:47.540 --> 00:08:49.680 오류 추적에서 자율적 수정으로의 전환입니다. 00:08:49.900 --> 00:08:53.640 단일 파일을 직접 가리키는 오류 메시지를 얼마나 자주 마주치는지 생각해보세요. 00:08:53.960 --> 00:08:58.040 스택 트레이스를 따라가 해당 메서드를 찾고 약간 수정한 뒤 다시 빌드합니다. 00:08:58.360 --> 00:09:03.120 그것이 명확한 해결책처럼 느껴지지만 동일한 오류가 조금 다른 형태로 다시 나타날 뿐입니다. 00:09:03.320 --> 00:09:06.420 그때서야 비로소 스택 트레이스가 증상만 보여졌다는 것을 깨닫게 됩니다. 00:09:06.420 --> 00:09:11.480 진짜 문제는 완전히 다른 곳, 아마도 지원 클래스나 일주일 내내 열어보지 않은 구성 파일 속에 숨어있을지도 모릅니다. 00:09:11.660 --> 00:09:14.220 모든 개발자는 그런 종류의 잘못된 방향 지시를 경험해보았을 것입니다. 00:09:14.380 --> 00:09:16.740 문제처럼 보이는 곳이 실제 해결해야 할 곳이 아닌 경우가 있습니다. 00:09:16.980 --> 00:09:18.340 이는 시간을 빠르게 잡아먹습니다. 00:09:18.580 --> 00:09:20.800 무언가를 수정하고 다시 빌드하고 기다립니다. 00:09:21.040 --> 00:09:25.100 그러면 새로운 오류가 나타나 또 다른 파일을 수정하고 조정하고 다시 빌드하게 만듭니다. 00:09:25.280 --> 00:09:32.040 계속 움직이고 타이핑하고 재컨파일하기 때문에 생산적인 것처럼 보이지만 실제로는 해결보다는 시행착오에 가깝습니다. 00:09:32.040 --> 00:09:38.480 이러한 과정은 몇 시간을 허비하게 만들고 거탈기식 수정만 남긴 채 원래 시작했던 기능은 전혀 진전되지 않게 합니다. 00:09:38.700 --> 00:09:40.860 여기서 진정한 비용은 바로 기회비용입니다. 00:09:41.060 --> 00:09:47.600 빌드와 재시도의 굴레에 갇혀있는 동안 비즈니스 문제를 해결하거나 사용자가 기다리는 기능을 출시하지 못하기 때문입니다. 00:09:47.820 --> 00:09:50.260 설계가 아닌 추측의 추진력을 낭비하게 됩니다. 00:09:50.520 --> 00:09:55.940 당장은 바쁘게 느껴지지만 그 시간 들은 시스템이 고장나지 않게 유지하는 것 이상의 성과를 내지 못합니다. 00:09:55.940 --> 00:10:01.880 팀 전체로 보면 이러한 피상적인 움직임은 모든 것을 지연시키고 기능 구현이 계속 밀리는 백로그를 만듭니다. 00:10:02.020 --> 00:10:04.900 여기서 에이전트 워크플로우는 다르게 작용하기 시작합니다. 00:10:05.120 --> 00:10:08.460 스택트레이스가 강조하는 한 줄에만 멈추지 않는다는 점이 핵심입니다. 00:10:08.640 --> 00:10:13.400 대신 시스템 수준의 컨텍스트를 유지하도록 설계되어 이 파일이 무엇을 해야 할지뿐만 아니라 00:10:13.400 --> 00:10:18.200 일관성을 회복하기 위해 연결된 부분들 전체에 어떤 일련의 변경이 필요한지를 고려합니다. 00:10:18.480 --> 00:10:22.020 실제로 이는 여러 파일에 걸친 편집을 제한하는 것으로 나타납니다. 00:10:22.020 --> 00:10:30.640 예를 들어 데모에서 보시겠지만 메서드 변경이 필요할 때 에이전트는 직접 찾아다닐 필요 없이 관련 설정이나 배포 템플릿에 일치하는 수정사항을 제한할 수 있습니다. 00:10:30.860 --> 00:10:33.740 이것이 바로 자동완성에서 더 넓은 영역으로의 도약입니다. 00:10:33.960 --> 00:10:40.480 자동완성이 코드줄을 완성한다면 에이전트는 파일 간의 조정을 수행하며 오류가 한 곳에만 머물지 않을 때의 조정 기능이 가장 빛을 발합니다. 00:10:40.640 --> 00:10:42.500 흔한 에이저 시나리오를 예로 들어보겠습니다. 00:10:42.940 --> 00:10:48.220 새로운 함수 앱을 구축했지만 배포 후 바인딩이 메서드 서명과 일치하지 않아 Q 트리거가 실패하는 상황입니다. 00:10:48.220 --> 00:10:57.260 보통은 로그를 뒤지고 어떤 바인딩이 잘못되었는지 파악하고 함수 JSON을 수동으로 조정하며 값이 어긋난 경우 인프라 템플릿까지 수정해야 합니다. 00:10:57.420 --> 00:11:01.560 각 단계가 별도의 추적 과정이며 수정할 때 마다 테스트를 다시 실행해야 합니다. 00:11:01.780 --> 00:11:03.960 에이전트 모드에서는 워크플로우가 다릅니다. 00:11:04.220 --> 00:11:10.380 에이전트는 코드 변경을 제한하고 올바른 함수 JSON 바인딩을 생성하며 정렬되지 않은 배포 스크립트에 대한 수정사항을 제시할 수 있습니다. 00:11:10.560 --> 00:11:14.420 각 계층을 맞추느라 몇 시간씩 커비할 필요 없이 검토하고 확인한 뒤 바로 다음 단계로 넘어갈 수 있습니다. 00:11:14.420 --> 00:11:18.660 여기서 핵심은 신뢰입니다. 누구도 보이지 않는 곳에서 편집이 이루어지고 있다는 느낌을 받아서는 안 됩니다. 00:11:18.900 --> 00:11:22.300 그렇기에 검토 과정이 중요한 것입니다. 이 데모를 통해 함께 살펴보겠습니다. 00:11:22.700 --> 00:11:24.840 에이전트가 조정된 변경사항을 제안합니다. 00:11:25.040 --> 00:11:32.840 딥을 열어 생성된 내용을 정확히 검토하고 단위 테스트를 실행하며 로컬에서 빌드를 검증한 후에야 수정사항을 수락할지 거부할지 결정합니다. 00:11:33.060 --> 00:11:37.200 이러한 검증 루프는 반복적인 작물을 제거하면서도 여러분이 모든 제어권을 유지하게 합니다. 00:11:37.400 --> 00:11:42.280 분명히 강조할 점은 에이전트가 더 빠른 작업을 도울 수는 있지만 좋은 엔지니어링 관행을 대체할 수는 없다는 것입니다. 00:11:42.280 --> 00:11:45.540 여전히 코드 리뷰와 CI를 필수적인 관문으로 다뤄야 합니다. 00:11:45.700 --> 00:11:51.220 AI가 문제 해결을 위한 탐색 시간을 줄 이도로가 돼 자동화된 검사와 인간의 검토를 안전망으로 유지하세요. 00:11:51.440 --> 00:11:55.700 이러한 균형이 신뢰 문제를 해결하고 속도 향상이 안정성을 저해하지 않도록 보장합니다. 00:11:55.920 --> 00:11:57.880 속도의 차이는 이론에 그치지 않습니다. 00:11:58.120 --> 00:12:03.320 오류를 쫓고 수동으로 패치하는데 반나절이 걸릴 일도 조율된 제안을 통하면 몇 분 만에 단축될 수 있습니다. 00:12:03.540 --> 00:12:07.420 그렇게 확보된 시간은 여러분이 실제로 에너지를 쏟고 싶은 작업에 다시 투입됩니다. 00:12:07.620 --> 00:12:11.540 사용자가 체감하는 기능과 코드 베이스를 개선하는 아키텍처 결정 같은 것들 말이죠. 00:12:11.540 --> 00:12:15.120 런타임의 문제를 수습하는 대신 자신있게 미리 설계할 수 있습니다. 00:12:15.320 --> 00:12:18.340 따라서 디버깅 루프가 더 이상 여러분의 하루를 좌우하지 않아도 됩니다. 00:12:18.580 --> 00:12:24.180 에이전트가 파일 간 업데이트를 제안함으로써 무작위로 검색하는 방식에서 검토 후 승인하는 방식으로 흐름이 바뀝니다. 00:12:24.340 --> 00:12:29.800 오류 속을 헤매는 대신 디버깅을 워크플로에 구조화되고 거의 자동화된 단계로 다루기 시작합니다. 00:12:30.060 --> 00:12:34.940 이러한 변화는 단순히 결함을 패치하는 것이 아니라 기능을 구축하는 데 필요한 사고의 여유와 시간을 확보해줍니다. 00:12:35.120 --> 00:12:39.060 오류 수정이 증상을 쫓는 것에서 벗어나게 되면 더 큰 가능성이 열립니다. 00:12:39.060 --> 00:12:43.040 전체 기능을 어떻게 동일한 구조적 방식으로 시작할 수 있을지 생각해보세요. 00:12:43.220 --> 00:12:50.560 조율된 수정사항을 제안하는 동일한 워크플로가 일반 언어로 된 사양을 받아 그 주위에 작동하는 구조를 형성한다고 상상해보십시오. 00:12:50.700 --> 00:12:53.320 바로 거기서 다음 단계의 개발이 시작됩니다. 00:12:53.520 --> 00:12:55.500 오버헤드 없는 사양 주도 개발입니다. 00:12:55.760 --> 00:13:02.700 가장 흥미로운 변화 중 하나는 파일이나 메서드 단위로만 생각하던 방식에서 벗어나 일반 언어로 업무를 구상하기 시작할 때 나타납니다. 00:13:02.700 --> 00:13:06.000 그 지점이 바로 오버헤드 없는 사양 주도 개발이 필요한 이유입니다. 00:13:06.160 --> 00:13:08.420 간단한 기능 요청을 작성한다고 그려보세요. 00:13:08.740 --> 00:13:14.160 월간 요약을 생성하고 저장하며 관리자 페이지를 통해 조회할 수 있는 보고 워크플로를 추가합니다. 00:13:14.380 --> 00:13:19.700 단순히 몇 개의 고립된 코드 조각만 얻는 대신 앱 전체에 맵핑된 작동 구조를 결과물로 받게 됩니다. 00:13:19.960 --> 00:13:24.540 컨트롤러 스톱이 생성되고 모델이 만들어지며 서비스가 등록되고 구성이 연결됩니다. 00:13:24.540 --> 00:13:32.080 위도를 설명하는 것에서 구체적인 스케폴드가 프로젝트에 나타나는 것을 확인하느니 과정이야말로의 접근방식이 이론을 넘어 실용적으로 느껴지는 지점입니다. 00:13:32.260 --> 00:13:35.640 전통적인 환경에서 사양 우선 개발은 부담스러운 명성이 있습니다. 00:13:35.860 --> 00:13:42.080 대규모 조직에서 이는 보통 긴 요구사항 문서, 여러 페이지의 설계 시트, 그리고 작업 속도를 늦추는 경직된 다이어그램을 의미합니다. 00:13:42.240 --> 00:13:47.620 규제가 엄격한 산업이나 전세계에 분산된 팀에서는 타당할지 몰라도 일상적인 코딩에서 대부분의 개발자는 이를 생략합니다. 00:13:47.820 --> 00:13:52.000 상세한 사양을 작성하고 유지하는 것은 누구도 시간과 인내심을 드리고 싶어 하지 않는 비용이 듭니다. 00:13:52.000 --> 00:13:57.920 기능을 배포하는 것만으로도 벅찬되 추가적인 작업까지 얹혀지니 마감이 다가오면 결국 그런 여분의 공수는 희생되기 마련입니다. 00:13:58.080 --> 00:14:01.500 아이러니하게도 개발자들은 사실 더 넓은 관점에서 생각하는 것을 좋아합니다. 00:14:01.700 --> 00:14:04.220 구조를 미리 파악하고 있으면 안심이 되기 때문이죠. 00:14:04.400 --> 00:14:06.380 문제는 의도가 아니라 유지보수입니다. 00:14:06.640 --> 00:14:10.380 일단 사양이 실제와 어긋나기 시작하면 유지보수는 짐이 됩니다. 00:14:10.700 --> 00:14:17.380 그래서 철저한 계획을 강조하는 회사조차도 실제 업무는 완벽한 설계보다는 임기응변으로 흐르는 경우가 많습니다. 00:14:17.640 --> 00:14:20.060 에이전트 워크플로우가 그 대안을 제시합니다. 00:14:20.060 --> 00:14:25.980 완벽한 설계 문서를 요구하는 대신 평문으로 된 사양을 다듬을 수 있는 스케폴드로 변환하도록 도울 수 있습니다. 00:14:26.200 --> 00:14:29.520 UML 다이어그램이나 직접 그린 인터페이스 맵은 필요 없습니다. 00:14:29.860 --> 00:14:36.800 단순히 새로운 API 엔드포인트가 포함된 보고 모듈을 만들고 저장소에 연결한 뒤 역할 기반 액세스로 보안을 설정하라고 말하면 00:14:36.800 --> 00:14:40.720 시스템이 내 솔루션의 여러 파일에 걸쳐 기본 코드를 생성합니다. 00:14:40.720 --> 00:14:50.400 데모에서 평문 사양을 소리내어 읽은 다음 에이전트가 생성 한 컨트롤러, 모델, 서비스 등록 파일을 보여드리고 수동으로 수정해야 했던 부분을 짚어드리겠습니다. 00:14:50.760 --> 00:14:53.560 그래야 여러분이 직접 품질을 판단할 수 있으니까요. 00:14:53.720 --> 00:14:56.620 이는 두 가지 개발 방식 사이의 중간 지점을 마련해줍니다. 00:14:56.820 --> 00:15:01.160 한쪽에는 빠르고 자유롭지만 장기적인 시스템에는 최악한 바이브 코딩이 있습니다. 00:15:01.460 --> 00:15:05.420 반대쪽에는 신뢰할 수 있지만 매우 느린 사양 중심 설계가 있습니다. 00:15:05.420 --> 00:15:13.980 에이전트의 도움을 받으면 자연어로 아이디어를 설명하고 스캡폴드를 얻을 수 있어 조직적인 구조의 이점을 유지하면서도 바이브 코딩만큼 빠르게 반복 작업이 가능합니다. 00:15:14.180 --> 00:15:16.480 아까의 보고 워크플로우를 다시 예로 들어보죠. 00:15:16.680 --> 00:15:23.420 보통은 모델을 만들고 데이터 서비스를 구축하고 컨트롤러를 연결하고 보안을 구성한 뒤 시작 단계에서 모든 것을 통합해야 합니다. 00:15:23.620 --> 00:15:26.800 그 과정에서 여러 파일을 오가며 일관성이 유지되길 바랄 뿐이죠. 00:15:26.980 --> 00:15:30.100 이 접근 방식을 사용하면 스캡폴드가 한 번에 제자리에 배치됩니다. 00:15:30.100 --> 00:15:36.800 진정한 효율은 코드를 덜 치는 것보다 서비스 구축 후 등록을 깜빡하는 것과 같은 파일 간의 실수를 방지하는 데서 나옵니다. 00:15:36.980 --> 00:15:38.880 물론 스타일 문제는 늘 존재합니다. 00:15:39.120 --> 00:15:42.260 AI 가상투적 인코드를 강요하거나 관례를 무시하지 않을까요? 00:15:42.460 --> 00:15:46.260 실제로 에이전트는 제안을 할 때 기존 프로젝트의 패턴을 반영하는 경우가 많습니다. 00:15:46.480 --> 00:15:48.520 데모를 통해 양면을 모두 보시게 될 겁니다. 00:15:48.840 --> 00:15:53.780 우리 팀의 컨트롤러 구조와 완벽하게 일치한 부분도 있고 추측이 어긋난 부분도 있을 것입니다. 00:15:54.020 --> 00:15:55.260 그러한 혼합이 중요합니다. 00:15:55.520 --> 00:15:58.340 무엇을 신뢰할 수 있고 무엇을 직접 조정해야 할지 알게 될 테니까요. 00:15:58.340 --> 00:16:00.500 최종 결과물은 찍어낸 듯한 코드가 아닙니다. 00:16:00.640 --> 00:16:04.300 수동으로 스케폴드를 짜는 수고만 줄어들 뿐 여전히 여러분의 프로젝트처럼 느껴질 것입니다. 00:16:04.460 --> 00:16:08.840 속도를 유지하면서도 향후 성장을 위해 개선 가능한 기반을 계속 활용할 수 있습니다. 00:16:09.100 --> 00:16:12.740 설계 작업이 다이어그램 작성에 인내심이 있는 아키텍트만의 영역인 대신 00:16:12.740 --> 00:16:17.420 이제는 체계를 희생하지 않으면 서도 빠르게 실험하려는 모든 개발자를 위한 도구가 됩니다. 00:16:17.860 --> 00:16:19.980 이것이 일상적인 작업 흐름의 일부가 되면 00:16:19.980 --> 00:16:24.500 사양 정의는 형식적인 기업 절차가 아니라 가벼운 야거처럼 느껴지게 됩니다. 00:16:24.500 --> 00:16:29.520 위도를 설명하면 시스템이 기초를 다지고 여러분은 세부사항을 구체화하는 데 집중하게 됩니다. 00:16:29.740 --> 00:16:32.420 더 큰 영향력은 단순히 생성되는 코드에서 오는 것이 아니라 00:16:32.420 --> 00:16:34.940 매주 축적되는 시간 절약의 의미에서 옵니다. 00:16:35.120 --> 00:16:38.120 기능 구현을 위한 시간은 늘리고 설정 작업의 고충은 줄입니다. 00:16:38.340 --> 00:16:41.520 이제 모든 개발자가 가장 관심을 갖는 질문으로 바로 넘어가겠습니다. 00:16:41.820 --> 00:16:45.500 이러한 변화가 생산성 측면에서 실제로 어떤 결과를 가져오는지에 대한 질문입니다. 00:16:45.660 --> 00:16:47.060 생산성 향상 효과입니다. 00:16:47.320 --> 00:16:50.080 진짜 중요한 질문은 여기저기서 몇 분을 아끼느냐가 아니라 00:16:50.080 --> 00:16:54.420 그 작은 변화들이 어떻게 일주일 내내 의미 있는 시간으로 쌓이느냐는 것입니다. 00:16:54.620 --> 00:16:56.560 이것이 바로 생산성 향상 효과입니다. 00:16:56.760 --> 00:17:00.060 컨텍스트 전환, 반복적인 빌드 주기, 수동 패치 작업 등으로 00:17:00.060 --> 00:17:02.200 무의식 중에 흘려보내던 시간을 되찾는 것입니다. 00:17:02.380 --> 00:17:05.660 대부분의 개발자는 이러한 작은 손실을 업무의 일부로 받아들입니다. 00:17:05.880 --> 00:17:09.080 설정 값을 찾느라 10분, 참조 오류로 다시 실행하느라 15분, 00:17:09.440 --> 00:17:11.640 혹은 연결 확인을 위해 파일을 오가는 시간들입니다. 00:17:11.900 --> 00:17:13.820 개별적으로는 사소하게 느껴질 수 있습니다. 00:17:14.080 --> 00:17:15.720 하지만 전체 스프린트에 걸쳐 합산해보면 00:17:15.720 --> 00:17:18.440 실제로 얼마나 많은 가치가 전달되는지를 결정짓습니다. 00:17:18.440 --> 00:17:22.060 일상적인 동작처럼 보이는 것들이 실제로는 납기 일정에 큰 걸림돌이 됩니다. 00:17:22.260 --> 00:17:25.280 숨겨진 부담은 컴파일 시간이나 타이핑 속도에 있는 것이 아닙니다. 00:17:25.480 --> 00:17:27.720 집중력을 방해하는 끊김 있는 작업 리듬에 있습니다. 00:17:28.040 --> 00:17:30.740 파일을 하나 옮길 때마다 내는 초기화 과정을 거칩니다. 00:17:31.000 --> 00:17:32.520 그 초기화에는 대가가 따릅니다. 00:17:32.780 --> 00:17:36.060 반복적 인수정 작업을 에이전트에 맡기면 이러한 부담이 줄어듭니다. 00:17:36.220 --> 00:17:38.180 끊임없이 컨텍스트를 재구성하는 대신 00:17:38.180 --> 00:17:41.640 더 큰 설계 문제를 해결하는 등 중요한 곳에 집중할 수 있습니다. 00:17:41.980 --> 00:17:44.280 많은 팀이 이러한 미세한 비용을 추적하지 못하는 이유는 00:17:44.280 --> 00:17:46.700 지라 티켓이나 기트 기록에 나타나지 않기 때문입니다. 00:17:46.700 --> 00:17:49.980 진전 없는 작업은 기록되지 않지만 여전히 에너지를 소모합니다. 00:17:50.140 --> 00:17:53.740 그리고 코드베이스가 확장될수록 이러한 마찰은 단순히 선형적으로 증가하지 않습니다. 00:17:53.900 --> 00:17:56.440 계층이 많아 질수록 메모리에 담아 야할 위존성이 늘어나고 00:17:56.440 --> 00:17:59.800 작업을 진행하기 전에 구조를 맞추느라 시간을 낭비할 가능성도 커집니다. 00:17:59.960 --> 00:18:03.340 에이전트 워크플로우는 이러한 소모적인 요소를 직접 겨냥하여 계산 방식을 바꿉니다. 00:18:03.500 --> 00:18:05.860 단순히 메서드 스톱을 더 빨리 채우는 것만이 아닙니다. 00:18:06.040 --> 00:18:09.540 오후 시간을 잡아먹는 검색, 수정, 재실행의 굴레를 줄여줍니다. 00:18:09.740 --> 00:18:11.280 에이전트 워크플로우를 사용하는 팀은 00:18:11.280 --> 00:18:14.100 많은 경우 문제 해결까지 걸리는 시간이 단축되었다고 보고합니다. 00:18:14.300 --> 00:18:16.860 이번 영상에서는 여러분이 직접 효과를 판단하실 수 있도록 00:18:16.860 --> 00:18:18.380 작업 전후 사례 하나를 시현하겠습니다. 00:18:18.740 --> 00:18:20.740 동일한 에이저 기능을 수동으로 구현할 때와 00:18:20.740 --> 00:18:23.520 에이전트를 사용하여 구현할 때 걸리는 시간을 기록하여 00:18:23.520 --> 00:18:25.500 생산성 향상을 구체적으로 보여드리겠습니다. 00:18:25.820 --> 00:18:28.900 비즈니스 관점에서 그 가치는 프로젝트 속도에서 드러납니다. 00:18:29.120 --> 00:18:32.020 더 빠른 사이클은 단순히 개발자의 만족만을 위한 것이 아닙니다. 00:18:32.200 --> 00:18:35.480 기능을 이번 릴리스에 포함할지 아니면 몇 분기 뒤로 미룰지를 결정합니다. 00:18:35.480 --> 00:18:39.560 더 적은 해킹과 회귀버그가 백로그로 유입되므로 기술 부채에도 영향을 미칩니다. 00:18:39.760 --> 00:18:42.920 흐름이 원활해지면 팀은 이전 스프린트의 깨진 작업을 되돌아보는 대신 00:18:42.920 --> 00:18:44.580 깔끔하게 앞으로 나아갈 수 있습니다. 00:18:44.800 --> 00:18:47.640 이러한 일관성이 쌓이면 시간이 지남에 따라 문제 해결에 쏟는 시간은 줄고 00:18:47.640 --> 00:18:49.000 더 강력한 결과물을 내놓게 됩니다. 00:18:49.180 --> 00:18:50.240 인적인 요소도 있습니다. 00:18:50.560 --> 00:18:53.520 오류를 쫓느라 하루를 보내면 어떤 엔지니어든 지치기 마련입니다. 00:18:53.720 --> 00:18:55.880 피로가 쌓이면 깔끔한 설계를 하기가 더 어려워지고 00:18:55.880 --> 00:18:57.840 세부 사항을 놓치며 실수가 파고듭니다. 00:18:58.020 --> 00:18:59.980 기계적인 수정 작업을 에이전트에게 맡기면 00:18:59.980 --> 00:19:02.400 개발자는 더 오랫동안 집중력을 유지할 수 있습니다. 00:19:02.600 --> 00:19:05.760 그 추가적인 집중력은 생산성과 품질을 모두 높여줍니다. 00:19:06.000 --> 00:19:07.680 반복되는 마찰에 시달리지 않을 때 00:19:07.680 --> 00:19:10.840 비로소 폭넓게 생각하고 더 효과적으로 계획할 수 있습니다. 00:19:11.100 --> 00:19:12.960 실제 현장에서의 차이는 다음과 같습니다. 00:19:13.320 --> 00:19:16.180 여러 바인딩과 서비스 통합이 포함된 새로운 에이저 함수는 00:19:16.180 --> 00:19:18.600 혼자 작업할 경우 꼬박이틀이 걸릴 수도 있습니다. 00:19:18.820 --> 00:19:22.380 구성, 테스트, 일치하지 않는 참조를 역추적하다 보면 00:19:22.380 --> 00:19:23.780 작업이 계속 늘어집니다. 00:19:23.980 --> 00:19:27.340 에이전트의 도움을 받으면 같은 함수를 반나절만에 완성할 수 있습니다. 00:19:27.340 --> 00:19:30.300 편법을 써서가 아니라 파일간 설정과 오케스트레이션이 00:19:30.300 --> 00:19:32.400 첫 시도부터 일관되게 적용되기 때문입니다. 00:19:32.540 --> 00:19:35.960 잘못된 시작과 중복되는 노력을 제거함으로써 일정이 단축됩니다. 00:19:36.160 --> 00:19:38.180 일부 개발자들은 타당한 우려를 제기합니다. 00:19:38.400 --> 00:19:41.340 유지보수를 에이아이에 의존하면 자신의 기술이 무뎌지지 않을까요? 00:19:41.520 --> 00:19:44.240 이런 시각은 무엇이 실제로 변화하고 있는지 놓치는 경우가 많습니다. 00:19:44.420 --> 00:19:46.780 반복적인 설정을 덜어내는 것은 전문성을 약화시키는 것이 아니라 00:19:46.780 --> 00:19:50.140 판단력이 레버리지를 창출하는 설계와 아키텍처를 위해 전문성을 보존하는 것입니다. 00:19:50.340 --> 00:19:52.680 실제로 여러분은 사소한 수정에 에너지를 낭비하는 대신 00:19:52.680 --> 00:19:55.060 고차원적인 문제 해결을 연습할 여유를 얻게 됩니다. 00:19:55.060 --> 00:19:58.700 직접 시도해보시고 스프린트에서 몇 시간을 확보했는지 댓글로 알려주세요. 00:19:58.900 --> 00:20:01.320 흥미로운 답변들은 향후 영상에서 다루도록 하겠습니다. 00:20:01.600 --> 00:20:04.020 다른 팀들이 변화를 어떻게 경험하는지 들어보는 것은 00:20:04.020 --> 00:20:06.900 데모나 예제를 넘어 실제 가치를 더 잘 이해하는 데 도움이 됩니다. 00:20:07.120 --> 00:20:10.560 한 가지 주의할 점은 자동화는 도움이 되지만 안전은 여전히 중요하다는 것입니다. 00:20:10.740 --> 00:20:14.540 항상 테스트를 실행하고 코드 리뷰를 통해 에이전트가 생성 한 변경 사항을 검증하세요. 00:20:14.760 --> 00:20:18.260 번거로운 작업은 줄어들 것이라고 믿되 기존의 안전장치는 그대로 유지하세요. 00:20:18.260 --> 00:20:21.320 속도의 차이는 품질이 일정하게 유지될 때만 빛을 발합니다. 00:20:21.500 --> 00:20:24.260 강력한 테스트와 혁명한 PR 리뷰가 취약한 자동화로부터 00:20:24.260 --> 00:20:26.080 여러분의 릴리스 파이프라인을 보호합니다. 00:20:26.300 --> 00:20:28.180 성과는 코드를 빨리 찍어내는 것이 아니라 00:20:28.180 --> 00:20:31.420 더 강력한 솔루션을 만들기 위한 여유를 확보하는 데 있습니다. 00:20:31.700 --> 00:20:33.120 피로를 줄이고 더 적은