Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / 땜질식 디버깅은 그만: .NET과 Azure를 위한 GitHub Copilot 에이전트 모드 (AI 더빙)

Transcript

땜질식 디버깅은 그만: .NET과 Azure를 위한 GitHub Copilot 에이전트 모드 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이저와 업무의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비하셨나요?
0:08
오는 1월, M365 컨이더 커진 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 제공하는 라이브 세션, 실무 데모, 실용적인 지식을 직접 경험해보세요.
0:18
뻔한 슬라이드는 없습니다. 지루한 유행어도 없습니다.
0:21
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실제적인 과제들을 다룹니다.
0:29
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위해 마련된 세션이 준비되어 있습니다.
0:35
10일 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 소통할 수 있습니다.
0:40
라이브로 시청하고 실무에 바로 적용할 수 있는 인사이트를 얻어가세요.
0:44
2027년 1월, 10일간의 행사, 하나의 마이크로소프트 커뮤니티, 지금 바로 등록하세요.
0:51
M365 con.net에 접속하여 오늘 바로 자리를 확보하세요.
0:56
M365 con.net입니다.
0:59
M365 con.net에서 참여하시고 1월 라이브 행사에서 뵙겠습니다.
1:05
솔루션을 열자마자 복잡하게 얽힌 파일과 참조, 그리고 숨어있는 버그 때문에 압도당한 경험이 있으신가요?
1:10
여러분만 그런 것은 아닙니다.
1:12
대부분의 개발자는 여기를 수정하고 저기를 디버깅하는 식으로 수동적인 작업을 합니다.
1:15
기터브 코파일럿 위 에이전트 모드는 더 넓은 컨텍스트를 유지하고 파일 전반의 변경사항을 조율하는 것을 목표로 합니다.
1:20
이 영상에서는 실제 넷 및 에이저 프로젝트에서 해당 워크플로우가 어떻게 작동하는지 보여드리겠습니다.
1:25
실제 솔루션을 살펴보고 에이전트 적용 전후의 모습을 비교해보겠습니다.
1:28
더 적은 오버헤드로 다중파일 코드를 생성하고 파일 간 오류를 더 빠르게 해결하며 일반 언어 사양으로 기능을 스케폴딩하는 방법을 확인하실 수 있습니다.
1:36
본격적으로 시작하기 전에 우리 모두가 매일 겪는 디버깅 루프의 숨겨진 비용에 대해 먼저 이야기해봅시다.
1:41
패치워크 디버깅의 숨겨진 비용. 간단해 보이는 오류를 수정하려고 자리에 앉습니다.
1:46
애플리케이션이 빌드되지 않고 콘솔은 메인 프로젝트 파일에 한 줄을 가리킵니다.
1:50
메서드를 수정하고 다시 컴파일한 뒤 해결했다고 생각했지만 메시지는 약간 다른 형태로 다시 나타납니다.
1:56
진짜 문제를 찾기 전까지 또 30분이 훌쩍 지나갑니다.
1:59
다른 프로젝트 폴더에 숨겨져 있던 누락된 종속성이 원인이었습니다.
2:02
참조를 수정하고 다시 배포할 때쯤이면 오후 시간 대부분이 패치 작업으로 사라져버립니다.
2:07
계획했던 기능 개발 업무는 내일로 미뤄집니다.
2:09
이런 패턴은 너무나 흔해서 이제는 당연하게 느껴질 정도입니다.
2:12
겉으로 보기에는 버그를 잡을 때 마다 성취감을 느끼며 앞으로 나아가는 것처럼 보입니다.
2:15
하지만 실제로는 제자리 걸음을 하고 있는 셈이죠.
2:18
코딩, 컴파일, 오류 발생, 수정, 그리고 반복.
2:21
원인과 결과를 쫓느라 몇 시간이 사라지고 결국 의미 있는 개선보다는 수동적 인대처에 그치게 됩니다.
2:26
이런 루프에 빠져 오후 시간을 허비해본 분들이 얼마나 계신가요?
2:29
한 줄 댓글을 남겨주시면 상위 댓글 들을 읽어보겠습니다.
2:32
이 악순환이 지치는 이유는 주변 도구는 계속 발전하는데 패턴은 그대로이기 때문입니다.
2:37
편집기는 새로운 기능을 추가하고 프레임워크는 진화하며 통합은 더 깊어지지만 디버깅은 여전히 수동적인 접근 방식을 요구합니다.
2:44
마치 양동이 하나로 번지는 불길을 막으려는 것과 같습니다.
2:47
매번 발생하는 화재는 즉각 처리되지만 불씨를 일으킨 근본적인 조건은 남아있어 다음 화재가 거의 확실시됩니다.
2:52
탭을 전환할 때마다 숨겨진 비용은 계속 늘어납니다.
2:55
서비스 클래스에서 설정 파일로 이동하고 다시 의존성 그래프로 건너뛰습니다.
3:00
전환할 때마다 붙잡고 있던 논리의 흐름은 끊어지고 강제로 정신적 재설정을 하게 됩니다.
3:04
창을 전환하는 데 드는 몇 초의 문제가 아니라 맥락을 반복해서 재구성해야 하는 정신적 소모가 문제입니다.
3:10
하루 종일 이런 작은 재설정들이 쌓여 큰 부담이 됩니다.
3:13
개별 개발자에게 이러한 피로감은 좌절과 시간 낭비로 나타납니다.
3:16
엔터프라이즈 프로젝트를 수행하는 팀에게는 그 영향이 배가 됩니다.
3:20
디버깅 반복은 스프린트 목표를 궤도에서 이탈하게 하고 기능 출시를 지연시키며 줄어드는 속도보다 빠르게 쌓이는 백로그를 만듭니다.
3:26
기술부채가 심화되는 것은 불을 끊으라 낭비되는 시간의 또 다른 부작용일 뿐입니다.
3:31
많은 팀이 개발 시간의 상당 부분을 수동적 인디버깅에 속고 있다고 보고합니다.
3:35
엔지니어링에서 흥미로운 부분이 아닙니다.
3:37
똑같은 의존성 불일치를 5번씩 쫓아다니는 로드맵을 계획하는 사람은 없습니다.
3:42
하지만 매주 팀의 역량은 바로 여기에 소모됩니다.
3:44
오류 수정이 진척의 기준이 되면 새로운 기능 개발은 뒷전이 되고 아키텍처는 조용히 망가져갑니다.
3:51
불편한 진실은 임시방편적인 디버깅이 단순히 속도만 늦추는 게 아니라는 점입니다.
3:55
그것은 설계 중심이 아닌 반응 중심의 문화를 강화합니다.
3:58
여러분은 시스템을 구축하는 것이 아니라 불을 끄는 데 시간을 쓰고 있습니다.
4:02
단기적으로는 제품을 유지할 수 있을지 몰라도 팀이 얼마나 확장할 수 있는지 얼마나 자신있게 출시할 수 있는지를 제안합니다.
4:07
자 소방활동 이라는 이 이미지에 대해 잠시 생각해보죠.
4:10
불이 난 곳으로 달려가 물을 붓고 다음 장소로 이동합니다.
4:12
문제는 개발자들이 일을 못해서가 아닙니다.
4:15
잘하고 있죠.
4:16
문제는 불길이 절대 멈추지 않는다는 것입니다.
4:18
불길은 그저 위치를 바꿔가며 새로운 파일, 프로젝트, 설정에서 다시 타오르며 모두를 창조 모드가 아닌 대응 모드에 머물게 합니다.
4:25
그렇다면 이 악순환이 오롯이 개인의 몫이 아니라면 어떨까요?
4:29
추적, 전환, 패치의 반복적인 과정이 다르게 관리되고 여러분은 오직 구축에만 집중할 수 있다면 어떨까요?
4:36
소방활동의 부담은 분명하지만 우리가 아직 다루지 않은 또 다른 압박지점이 있기 때문입니다.
4:41
프로젝트가 단순히 하나의 파일이나 모듈이 아닐 때 진짜 부담이 시작됩니다.
4:45
수정이 필요한 부분이 여러 계층에 걸쳐 있을 때가 바로 그렇습니다.
4:48
로직이 서로 다른 프로젝트, 서비스, 라이브러리에 흩어져 있는 솔루션을 열고 앉아있다고 상상해보세요.
4:54
필요한 기능이 세 곳에 나누어져 있고 이를 머릿속으로 정리하는 것 자체가 큰 싸움입니다.
5:00
다중파일의 혼란 대 AI 위 컨텍스트 제어.
5:03
프로젝트가 여러 계층에 걸쳐 있을 때 진짜 도전과제는 코드를 작성하는 게 아닙니다.
5:08
모든 움직이는 요소들을 하나로 묶어두는 일입니다.
5:11
다중파일의 혼란과 AI 기반 컨텍스트 제어 사이의 긴장감이 가장 명확하게 드러나는 지점이 바로 여기입니다.
5:16
10개 이상의 프로젝트로 구성된 대규모 넷솔루션을 예로 들어보겠습니다.
5:19
새로운 기능은 보통 여러 계층을 동시에 건드리게 됩니다.
5:22
한 곳에는 컨트롤러가, 다른 곳에는 서비스가, 또 다른 곳에는 구성 파일 세트가 존재하죠.
5:27
코드 한 줄을 쓰기도 전에 참조를 추적하고 위존성을 확인하며 작은 변경이 전체에 예상치 못한 오류를 일으키지 않기를 바라며 시간을 보냅니다.
5:35
그런 워크플로우는 예외가 아닙니다.
5:37
엔터프라이즈 애플리케이션에서는 일반적인 일이며, 특히 에이저 서비스와 통합이 도입되면 더욱 그렇습니다.
5:42
이런 시스템의 구조는 평면적이지 않습니다.
5:45
인터페이스, 위존성 주입 맵핑, 그리고 프로젝트 간 참조가 모두 중요한 역할을 합니다.
5:50
에이저가 포함되면 일부 위존성은 솔루션 폴더를 완전히 벗어나 함수 앱, 서비스 버스 바인딩, 리소스 설정, 스토리지 연결 등으로 뻗어나갑니다.
5:58
여러분은 IDE 위 코드, 디스크의 설정 파일, 클라우드에 정의된 서비스 사이를 조율해야 합니다.
6:03
그 어떤 것도 여러분이 클릭을 줄이고 싶어 한다는 사실에는 관심이 없습니다.
6:06
컨텍스트를 전환할 때마다 전체적인 그림을 다시 구성하는 데 에너지를 낭비하게 됩니다.
6:10
우리 대부분은 그 컨텍스트를 작업 기억력으로 감당하려고 애씁니다.
6:13
처음에는 관리할 수 있지만 프로젝트가 커지면 실수가 끼어들게 됩니다.
6:16
서비스에 새 메서드를 추가하고는 DI 등록을 잊어버리는 시기죠.
6:20
에이저 함수를 코딩하다가 나중에 야호스트, 제이선이나 배포 템플릿에 바인딩이 추가되지 않아듬을 깨닫기도 합니다.
6:25
런타임이 되기 전까지는 아무것도 알려주지 않기에 결국 개발이 아닌 디버깅을 하게 됩니다.
6:28
코드 자체가 어려운 부분은 아닙니다.
6:30
바로 파일 간의 조율이 어려운 것이죠.
6:32
컨트롤러에서 서비스로, 모델로, 다시 설정 파일로 탭으로 가다 결국 왜 그 파일을 열었는지 조차 잊어버리는 기분, 모두가 잘 아실 겁니다.
6:41
하루에도 수십 번씩 반복되는 작은 방해 요소입니다.
6:45
이런 상호작용이 쌓이면 실제 진도를 늦추는 마찰이 발생합니다.
6:48
결과적으로 전달 속도가 느려지는데, 이는 작성이 느려서가 아니라 모든 것을 동기화하느라 집중력이 흐트러지기 때문입니다.
6:54
이런 오버헤드는 클라우드 우선 프로젝트일수록 더 커집니다.
6:57
에이전은 로컬 구성 파일, 환경 변수, 암 또는 바이셉 템플릿, CIE, CD 파이프라인 등 여러 곳의 핵심 설정을 분산시킵니다.
7:06
단일 기능 요청처럼 보이는 작업이 실제로는 4가지 추상화 계층에 걸쳐 퍼져 있는 경우가 많습니다.
7:10
이러한 복잡성은 선택사항이 아닙니다.
7:13
생태계가 작동하는 방식에 내재되어 있습니다.
7:15
이제 에이전트 모드가 잠재적 인 변화의 계기로 등장합니다.
7:18
모든 조정 작업을 사용자에게 맡기는 대신, 여러 파일에 걸쳐 더 넓은 문맥을 유지하도록 설계되었습니다.
7:22
즉, 한 계층에서 변경을 요청하면 다른 계층을 무시하지 않습니다.
7:27
데모에서는 새로운 에이저 함수를 생성하여 에이전트가 메서드 복문을 생성하고 바인딩 구성을 만들며 호스트를 업데이트하는 과정을 보여드리겠습니다.
7:34
JSON 파일은 물론 올바른 DI 등록까지 제한해줍니다.
7:38
이는 보통 여러 파일에 흩어져 있는 다단계 프로세스입니다.
7:41
에이전트는 이를 하나의 흐름으로 간소화할 수 있습니다.
7:44
이는 여러분의 판단을 대체하는 것이 아니라 반복적인 관리 작업을 제거하여 실제 설계 선택에 집중할 수 있게 하는 것입니다.
7:50
사람은 대략 적인 계율을 머릿속에 담아두거나 화이트보드에 스케치할 수 있습니다.
7:54
AI는 전체 흐름을 놓치지 않고 파일별로 세부사항을 추적할 수 있습니다.
7:58
우리에게 엄청난 인지 부하처럼 느껴지는 것이 에이전트에게는 기본적인 문맥일 뿐입니다.
8:02
실제 차이점은 분산된 탭을 넘나드는 작업에서 동기화가 유지되는 통합된 변경 작업으로 전환된다는 것입니다.
8:07
데모 도중 에이전트가 생성 한풀 리퀘스트 나딕을 띄워 어떤 편집이 이루어졌는지 정확히 보여드리겠습니다.
8:12
이러한 가시성은 중요합니다.
8:14
여러 파일을 업데이트하는 번거로운 작업은 자동으로 처리되면서 여러분은 검토하고 승인하는 완전한 통제권을 갖게 됩니다.
8:19
따라서 오후 내내 파편화된 코드 조각을 이어붙이는 대신 한 번의 지시로 변경을 수행하고 생성된 업데이트를 확인한 뒤 상위 수준의 설계로 넘어갈 수 있습니다.
8:26
클릭이나 키 입력을 줄이는 것만이 아니라 수십 개의 파일이 어떻게 연결되는지 되짚어보는 대신 실제 문제를 해결하는 데 집중할 수 있다는 점이 진정한 안도감을 줍니다.
8:34
이러한 장점은 시스템이 고장났을 때 가장 확실하게 드러납니다.
8:37
강력한 문맥 처리에도 불구하고 시스템은 실패하고 구성은 달라지며 참조 불일치가 다시 발생하기 때문입니다.
8:42
바로 여기서 다음 시험대가 시작됩니다.
8:44
오류가 발생했을 때 이를 어떻게 추적하고 해결할 것인가 하는 점입니다.
8:47
오류 추적에서 자율적 수정으로의 전환입니다.
8:49
단일 파일을 직접 가리키는 오류 메시지를 얼마나 자주 마주치는지 생각해보세요.
8:53
스택 트레이스를 따라가 해당 메서드를 찾고 약간 수정한 뒤 다시 빌드합니다.
8:58
그것이 명확한 해결책처럼 느껴지지만 동일한 오류가 조금 다른 형태로 다시 나타날 뿐입니다.
9:03
그때서야 비로소 스택 트레이스가 증상만 보여졌다는 것을 깨닫게 됩니다.
9:06
진짜 문제는 완전히 다른 곳, 아마도 지원 클래스나 일주일 내내 열어보지 않은 구성 파일 속에 숨어있을지도 모릅니다.
9:11
모든 개발자는 그런 종류의 잘못된 방향 지시를 경험해보았을 것입니다.
9:14
문제처럼 보이는 곳이 실제 해결해야 할 곳이 아닌 경우가 있습니다.
9:16
이는 시간을 빠르게 잡아먹습니다.
9:18
무언가를 수정하고 다시 빌드하고 기다립니다.
9:21
그러면 새로운 오류가 나타나 또 다른 파일을 수정하고 조정하고 다시 빌드하게 만듭니다.
9:25
계속 움직이고 타이핑하고 재컨파일하기 때문에 생산적인 것처럼 보이지만 실제로는 해결보다는 시행착오에 가깝습니다.
9:32
이러한 과정은 몇 시간을 허비하게 만들고 거탈기식 수정만 남긴 채 원래 시작했던 기능은 전혀 진전되지 않게 합니다.
9:38
여기서 진정한 비용은 바로 기회비용입니다.
9:41
빌드와 재시도의 굴레에 갇혀있는 동안 비즈니스 문제를 해결하거나 사용자가 기다리는 기능을 출시하지 못하기 때문입니다.
9:47
설계가 아닌 추측의 추진력을 낭비하게 됩니다.
9:50
당장은 바쁘게 느껴지지만 그 시간 들은 시스템이 고장나지 않게 유지하는 것 이상의 성과를 내지 못합니다.
9:55
팀 전체로 보면 이러한 피상적인 움직임은 모든 것을 지연시키고 기능 구현이 계속 밀리는 백로그를 만듭니다.
10:02
여기서 에이전트 워크플로우는 다르게 작용하기 시작합니다.
10:05
스택트레이스가 강조하는 한 줄에만 멈추지 않는다는 점이 핵심입니다.
10:08
대신 시스템 수준의 컨텍스트를 유지하도록 설계되어 이 파일이 무엇을 해야 할지뿐만 아니라
10:13
일관성을 회복하기 위해 연결된 부분들 전체에 어떤 일련의 변경이 필요한지를 고려합니다.
10:18
실제로 이는 여러 파일에 걸친 편집을 제한하는 것으로 나타납니다.
10:22
예를 들어 데모에서 보시겠지만 메서드 변경이 필요할 때 에이전트는 직접 찾아다닐 필요 없이 관련 설정이나 배포 템플릿에 일치하는 수정사항을 제한할 수 있습니다.
10:30
이것이 바로 자동완성에서 더 넓은 영역으로의 도약입니다.
10:33
자동완성이 코드줄을 완성한다면 에이전트는 파일 간의 조정을 수행하며 오류가 한 곳에만 머물지 않을 때의 조정 기능이 가장 빛을 발합니다.
10:40
흔한 에이저 시나리오를 예로 들어보겠습니다.
10:42
새로운 함수 앱을 구축했지만 배포 후 바인딩이 메서드 서명과 일치하지 않아 Q 트리거가 실패하는 상황입니다.
10:48
보통은 로그를 뒤지고 어떤 바인딩이 잘못되었는지 파악하고 함수 JSON을 수동으로 조정하며 값이 어긋난 경우 인프라 템플릿까지 수정해야 합니다.
10:57
각 단계가 별도의 추적 과정이며 수정할 때 마다 테스트를 다시 실행해야 합니다.
11:01
에이전트 모드에서는 워크플로우가 다릅니다.
11:04
에이전트는 코드 변경을 제한하고 올바른 함수 JSON 바인딩을 생성하며 정렬되지 않은 배포 스크립트에 대한 수정사항을 제시할 수 있습니다.
11:10
각 계층을 맞추느라 몇 시간씩 커비할 필요 없이 검토하고 확인한 뒤 바로 다음 단계로 넘어갈 수 있습니다.
11:14
여기서 핵심은 신뢰입니다. 누구도 보이지 않는 곳에서 편집이 이루어지고 있다는 느낌을 받아서는 안 됩니다.
11:18
그렇기에 검토 과정이 중요한 것입니다. 이 데모를 통해 함께 살펴보겠습니다.
11:22
에이전트가 조정된 변경사항을 제안합니다.
11:25
딥을 열어 생성된 내용을 정확히 검토하고 단위 테스트를 실행하며 로컬에서 빌드를 검증한 후에야 수정사항을 수락할지 거부할지 결정합니다.
11:33
이러한 검증 루프는 반복적인 작물을 제거하면서도 여러분이 모든 제어권을 유지하게 합니다.
11:37
분명히 강조할 점은 에이전트가 더 빠른 작업을 도울 수는 있지만 좋은 엔지니어링 관행을 대체할 수는 없다는 것입니다.
11:42
여전히 코드 리뷰와 CI를 필수적인 관문으로 다뤄야 합니다.
11:45
AI가 문제 해결을 위한 탐색 시간을 줄 이도로가 돼 자동화된 검사와 인간의 검토를 안전망으로 유지하세요.
11:51
이러한 균형이 신뢰 문제를 해결하고 속도 향상이 안정성을 저해하지 않도록 보장합니다.
11:55
속도의 차이는 이론에 그치지 않습니다.
11:58
오류를 쫓고 수동으로 패치하는데 반나절이 걸릴 일도 조율된 제안을 통하면 몇 분 만에 단축될 수 있습니다.
12:03
그렇게 확보된 시간은 여러분이 실제로 에너지를 쏟고 싶은 작업에 다시 투입됩니다.
12:07
사용자가 체감하는 기능과 코드 베이스를 개선하는 아키텍처 결정 같은 것들 말이죠.
12:11
런타임의 문제를 수습하는 대신 자신있게 미리 설계할 수 있습니다.
12:15
따라서 디버깅 루프가 더 이상 여러분의 하루를 좌우하지 않아도 됩니다.
12:18
에이전트가 파일 간 업데이트를 제안함으로써 무작위로 검색하는 방식에서 검토 후 승인하는 방식으로 흐름이 바뀝니다.
12:24
오류 속을 헤매는 대신 디버깅을 워크플로에 구조화되고 거의 자동화된 단계로 다루기 시작합니다.
12:30
이러한 변화는 단순히 결함을 패치하는 것이 아니라 기능을 구축하는 데 필요한 사고의 여유와 시간을 확보해줍니다.
12:35
오류 수정이 증상을 쫓는 것에서 벗어나게 되면 더 큰 가능성이 열립니다.
12:39
전체 기능을 어떻게 동일한 구조적 방식으로 시작할 수 있을지 생각해보세요.
12:43
조율된 수정사항을 제안하는 동일한 워크플로가 일반 언어로 된 사양을 받아 그 주위에 작동하는 구조를 형성한다고 상상해보십시오.
12:50
바로 거기서 다음 단계의 개발이 시작됩니다.
12:53
오버헤드 없는 사양 주도 개발입니다.
12:55
가장 흥미로운 변화 중 하나는 파일이나 메서드 단위로만 생각하던 방식에서 벗어나 일반 언어로 업무를 구상하기 시작할 때 나타납니다.
13:02
그 지점이 바로 오버헤드 없는 사양 주도 개발이 필요한 이유입니다.
13:06
간단한 기능 요청을 작성한다고 그려보세요.
13:08
월간 요약을 생성하고 저장하며 관리자 페이지를 통해 조회할 수 있는 보고 워크플로를 추가합니다.
13:14
단순히 몇 개의 고립된 코드 조각만 얻는 대신 앱 전체에 맵핑된 작동 구조를 결과물로 받게 됩니다.
13:19
컨트롤러 스톱이 생성되고 모델이 만들어지며 서비스가 등록되고 구성이 연결됩니다.
13:24
위도를 설명하는 것에서 구체적인 스케폴드가 프로젝트에 나타나는 것을 확인하느니 과정이야말로의 접근방식이 이론을 넘어 실용적으로 느껴지는 지점입니다.
13:32
전통적인 환경에서 사양 우선 개발은 부담스러운 명성이 있습니다.
13:35
대규모 조직에서 이는 보통 긴 요구사항 문서, 여러 페이지의 설계 시트, 그리고 작업 속도를 늦추는 경직된 다이어그램을 의미합니다.
13:42
규제가 엄격한 산업이나 전세계에 분산된 팀에서는 타당할지 몰라도 일상적인 코딩에서 대부분의 개발자는 이를 생략합니다.
13:47
상세한 사양을 작성하고 유지하는 것은 누구도 시간과 인내심을 드리고 싶어 하지 않는 비용이 듭니다.
13:52
기능을 배포하는 것만으로도 벅찬되 추가적인 작업까지 얹혀지니 마감이 다가오면 결국 그런 여분의 공수는 희생되기 마련입니다.
13:58
아이러니하게도 개발자들은 사실 더 넓은 관점에서 생각하는 것을 좋아합니다.
14:01
구조를 미리 파악하고 있으면 안심이 되기 때문이죠.
14:04
문제는 의도가 아니라 유지보수입니다.
14:06
일단 사양이 실제와 어긋나기 시작하면 유지보수는 짐이 됩니다.
14:10
그래서 철저한 계획을 강조하는 회사조차도 실제 업무는 완벽한 설계보다는 임기응변으로 흐르는 경우가 많습니다.
14:17
에이전트 워크플로우가 그 대안을 제시합니다.
14:20
완벽한 설계 문서를 요구하는 대신 평문으로 된 사양을 다듬을 수 있는 스케폴드로 변환하도록 도울 수 있습니다.
14:26
UML 다이어그램이나 직접 그린 인터페이스 맵은 필요 없습니다.
14:29
단순히 새로운 API 엔드포인트가 포함된 보고 모듈을 만들고 저장소에 연결한 뒤 역할 기반 액세스로 보안을 설정하라고 말하면
14:36
시스템이 내 솔루션의 여러 파일에 걸쳐 기본 코드를 생성합니다.
14:40
데모에서 평문 사양을 소리내어 읽은 다음 에이전트가 생성 한 컨트롤러, 모델, 서비스 등록 파일을 보여드리고 수동으로 수정해야 했던 부분을 짚어드리겠습니다.
14:50
그래야 여러분이 직접 품질을 판단할 수 있으니까요.
14:53
이는 두 가지 개발 방식 사이의 중간 지점을 마련해줍니다.
14:56
한쪽에는 빠르고 자유롭지만 장기적인 시스템에는 최악한 바이브 코딩이 있습니다.
15:01
반대쪽에는 신뢰할 수 있지만 매우 느린 사양 중심 설계가 있습니다.
15:05
에이전트의 도움을 받으면 자연어로 아이디어를 설명하고 스캡폴드를 얻을 수 있어 조직적인 구조의 이점을 유지하면서도 바이브 코딩만큼 빠르게 반복 작업이 가능합니다.
15:14
아까의 보고 워크플로우를 다시 예로 들어보죠.
15:16
보통은 모델을 만들고 데이터 서비스를 구축하고 컨트롤러를 연결하고 보안을 구성한 뒤 시작 단계에서 모든 것을 통합해야 합니다.
15:23
그 과정에서 여러 파일을 오가며 일관성이 유지되길 바랄 뿐이죠.
15:26
이 접근 방식을 사용하면 스캡폴드가 한 번에 제자리에 배치됩니다.
15:30
진정한 효율은 코드를 덜 치는 것보다 서비스 구축 후 등록을 깜빡하는 것과 같은 파일 간의 실수를 방지하는 데서 나옵니다.
15:36
물론 스타일 문제는 늘 존재합니다.
15:39
AI 가상투적 인코드를 강요하거나 관례를 무시하지 않을까요?
15:42
실제로 에이전트는 제안을 할 때 기존 프로젝트의 패턴을 반영하는 경우가 많습니다.
15:46
데모를 통해 양면을 모두 보시게 될 겁니다.
15:48
우리 팀의 컨트롤러 구조와 완벽하게 일치한 부분도 있고 추측이 어긋난 부분도 있을 것입니다.
15:54
그러한 혼합이 중요합니다.
15:55
무엇을 신뢰할 수 있고 무엇을 직접 조정해야 할지 알게 될 테니까요.
15:58
최종 결과물은 찍어낸 듯한 코드가 아닙니다.
16:00
수동으로 스케폴드를 짜는 수고만 줄어들 뿐 여전히 여러분의 프로젝트처럼 느껴질 것입니다.
16:04
속도를 유지하면서도 향후 성장을 위해 개선 가능한 기반을 계속 활용할 수 있습니다.
16:09
설계 작업이 다이어그램 작성에 인내심이 있는 아키텍트만의 영역인 대신
16:12
이제는 체계를 희생하지 않으면 서도 빠르게 실험하려는 모든 개발자를 위한 도구가 됩니다.
16:17
이것이 일상적인 작업 흐름의 일부가 되면
16:19
사양 정의는 형식적인 기업 절차가 아니라 가벼운 야거처럼 느껴지게 됩니다.
16:24
위도를 설명하면 시스템이 기초를 다지고 여러분은 세부사항을 구체화하는 데 집중하게 됩니다.
16:29
더 큰 영향력은 단순히 생성되는 코드에서 오는 것이 아니라
16:32
매주 축적되는 시간 절약의 의미에서 옵니다.
16:35
기능 구현을 위한 시간은 늘리고 설정 작업의 고충은 줄입니다.
16:38
이제 모든 개발자가 가장 관심을 갖는 질문으로 바로 넘어가겠습니다.
16:41
이러한 변화가 생산성 측면에서 실제로 어떤 결과를 가져오는지에 대한 질문입니다.
16:45
생산성 향상 효과입니다.
16:47
진짜 중요한 질문은 여기저기서 몇 분을 아끼느냐가 아니라
16:50
그 작은 변화들이 어떻게 일주일 내내 의미 있는 시간으로 쌓이느냐는 것입니다.
16:54
이것이 바로 생산성 향상 효과입니다.
16:56
컨텍스트 전환, 반복적인 빌드 주기, 수동 패치 작업 등으로
17:00
무의식 중에 흘려보내던 시간을 되찾는 것입니다.
17:02
대부분의 개발자는 이러한 작은 손실을 업무의 일부로 받아들입니다.
17:05
설정 값을 찾느라 10분, 참조 오류로 다시 실행하느라 15분,
17:09
혹은 연결 확인을 위해 파일을 오가는 시간들입니다.
17:11
개별적으로는 사소하게 느껴질 수 있습니다.
17:14
하지만 전체 스프린트에 걸쳐 합산해보면
17:15
실제로 얼마나 많은 가치가 전달되는지를 결정짓습니다.
17:18
일상적인 동작처럼 보이는 것들이 실제로는 납기 일정에 큰 걸림돌이 됩니다.
17:22
숨겨진 부담은 컴파일 시간이나 타이핑 속도에 있는 것이 아닙니다.
17:25
집중력을 방해하는 끊김 있는 작업 리듬에 있습니다.
17:28
파일을 하나 옮길 때마다 내는 초기화 과정을 거칩니다.
17:31
그 초기화에는 대가가 따릅니다.
17:32
반복적 인수정 작업을 에이전트에 맡기면 이러한 부담이 줄어듭니다.
17:36
끊임없이 컨텍스트를 재구성하는 대신
17:38
더 큰 설계 문제를 해결하는 등 중요한 곳에 집중할 수 있습니다.
17:41
많은 팀이 이러한 미세한 비용을 추적하지 못하는 이유는
17:44
지라 티켓이나 기트 기록에 나타나지 않기 때문입니다.
17:46
진전 없는 작업은 기록되지 않지만 여전히 에너지를 소모합니다.
17:50
그리고 코드베이스가 확장될수록 이러한 마찰은 단순히 선형적으로 증가하지 않습니다.
17:53
계층이 많아 질수록 메모리에 담아 야할 위존성이 늘어나고
17:56
작업을 진행하기 전에 구조를 맞추느라 시간을 낭비할 가능성도 커집니다.
17:59
에이전트 워크플로우는 이러한 소모적인 요소를 직접 겨냥하여 계산 방식을 바꿉니다.
18:03
단순히 메서드 스톱을 더 빨리 채우는 것만이 아닙니다.
18:06
오후 시간을 잡아먹는 검색, 수정, 재실행의 굴레를 줄여줍니다.
18:09
에이전트 워크플로우를 사용하는 팀은
18:11
많은 경우 문제 해결까지 걸리는 시간이 단축되었다고 보고합니다.
18:14
이번 영상에서는 여러분이 직접 효과를 판단하실 수 있도록
18:16
작업 전후 사례 하나를 시현하겠습니다.
18:18
동일한 에이저 기능을 수동으로 구현할 때와
18:20
에이전트를 사용하여 구현할 때 걸리는 시간을 기록하여
18:23
생산성 향상을 구체적으로 보여드리겠습니다.
18:25
비즈니스 관점에서 그 가치는 프로젝트 속도에서 드러납니다.
18:29
더 빠른 사이클은 단순히 개발자의 만족만을 위한 것이 아닙니다.
18:32
기능을 이번 릴리스에 포함할지 아니면 몇 분기 뒤로 미룰지를 결정합니다.
18:35
더 적은 해킹과 회귀버그가 백로그로 유입되므로 기술 부채에도 영향을 미칩니다.
18:39
흐름이 원활해지면 팀은 이전 스프린트의 깨진 작업을 되돌아보는 대신
18:42
깔끔하게 앞으로 나아갈 수 있습니다.
18:44
이러한 일관성이 쌓이면 시간이 지남에 따라 문제 해결에 쏟는 시간은 줄고
18:47
더 강력한 결과물을 내놓게 됩니다.
18:49
인적인 요소도 있습니다.
18:50
오류를 쫓느라 하루를 보내면 어떤 엔지니어든 지치기 마련입니다.
18:53
피로가 쌓이면 깔끔한 설계를 하기가 더 어려워지고
18:55
세부 사항을 놓치며 실수가 파고듭니다.
18:58
기계적인 수정 작업을 에이전트에게 맡기면
18:59
개발자는 더 오랫동안 집중력을 유지할 수 있습니다.
19:02
그 추가적인 집중력은 생산성과 품질을 모두 높여줍니다.
19:06
반복되는 마찰에 시달리지 않을 때
19:07
비로소 폭넓게 생각하고 더 효과적으로 계획할 수 있습니다.
19:11
실제 현장에서의 차이는 다음과 같습니다.
19:13
여러 바인딩과 서비스 통합이 포함된 새로운 에이저 함수는
19:16
혼자 작업할 경우 꼬박이틀이 걸릴 수도 있습니다.
19:18
구성, 테스트, 일치하지 않는 참조를 역추적하다 보면
19:22
작업이 계속 늘어집니다.
19:23
에이전트의 도움을 받으면 같은 함수를 반나절만에 완성할 수 있습니다.
19:27
편법을 써서가 아니라 파일간 설정과 오케스트레이션이
19:30
첫 시도부터 일관되게 적용되기 때문입니다.
19:32
잘못된 시작과 중복되는 노력을 제거함으로써 일정이 단축됩니다.
19:36
일부 개발자들은 타당한 우려를 제기합니다.
19:38
유지보수를 에이아이에 의존하면 자신의 기술이 무뎌지지 않을까요?
19:41
이런 시각은 무엇이 실제로 변화하고 있는지 놓치는 경우가 많습니다.
19:44
반복적인 설정을 덜어내는 것은 전문성을 약화시키는 것이 아니라
19:46
판단력이 레버리지를 창출하는 설계와 아키텍처를 위해 전문성을 보존하는 것입니다.
19:50
실제로 여러분은 사소한 수정에 에너지를 낭비하는 대신
19:52
고차원적인 문제 해결을 연습할 여유를 얻게 됩니다.
19:55
직접 시도해보시고 스프린트에서 몇 시간을 확보했는지 댓글로 알려주세요.
19:58
흥미로운 답변들은 향후 영상에서 다루도록 하겠습니다.
20:01
다른 팀들이 변화를 어떻게 경험하는지 들어보는 것은
20:04
데모나 예제를 넘어 실제 가치를 더 잘 이해하는 데 도움이 됩니다.
20:07
한 가지 주의할 점은 자동화는 도움이 되지만 안전은 여전히 중요하다는 것입니다.
20:10
항상 테스트를 실행하고 코드 리뷰를 통해 에이전트가 생성 한 변경 사항을 검증하세요.
20:14
번거로운 작업은 줄어들 것이라고 믿되 기존의 안전장치는 그대로 유지하세요.
20:18
속도의 차이는 품질이 일정하게 유지될 때만 빛을 발합니다.
20:21
강력한 테스트와 혁명한 PR 리뷰가 취약한 자동화로부터
20:24
여러분의 릴리스 파이프라인을 보호합니다.
20:26
성과는 코드를 빨리 찍어내는 것이 아니라
20:28
더 강력한 솔루션을 만들기 위한 여유를 확보하는 데 있습니다.
20:31
피로를 줄이고 더 적은