Transcript
00:00:00소프트웨어 개발이 완전히 달라졌다는 이야기는 아마 귀가 따갑도록 들으셨겠지만,
00:00:03새로운 툴을 도입하는 것만으로는 겉핥기에 불과합니다.
00:00:06오늘날 구축되는 시스템은 과거의 소프트웨어와는 전혀 다르게 작동하기 때문입니다.
00:00:10따라서 기업들이 기반으로 삼던 프레임워크도 전환되어야만 했습니다.
00:00:14기존 프로세스를 고집하다가는 그 프로세스로는 도저히 해결할 수 없는 문제에 부딪힐 테니까요.
00:00:18따라서 이러한 변화하는 환경에 맞추기 위해,
00:00:21개발자 커뮤니티에는 처음부터 에이전트를 염두에 두고 설계된 새로운 프레임워크가 등장했습니다.
00:00:25이번 영상에서는 이 새로운 라이프사이클 프레임워크가 무엇인지,
00:00:29그리고 왜 이를 도입해야 하는지 자세히 살펴보겠습니다.
00:00:31수년 동안 소프트웨어 개발은 SDLC를 기반으로 진행되어 왔습니다.
00:00:35소프트웨어 개발 라이프사이클은 수십 년간 사용되어 온 구조화된 프로세스로,
00:00:39설계, 개발, 테스트, 배포, 유지보수, 지속적인 지원 등 여러 단계로 구성됩니다.
00:00:45그 핵심 개념은 비즈니스 목표와 사용자 요구사항을 반영하여 소프트웨어를 개발하고,
00:00:51각 단계의 결과물이 다음 단계의 입력물이 되도록 하는 것입니다.
00:00:54하지만 이는 기술 영역에 AI가 등장하기 전까지만 유효한 이야기였습니다.
00:00:57AI가 본격적으로 주목받기 시작하면서 가장 먼저 대체하기 시작한 것은 코딩이었습니다.
00:01:02AI 이전의 개발은 코드를 수없이 반복해서 작성하는 시스템이었으며,
00:01:06문제를 해결할 시스템을 만들기 위해 여러 곳의 스니펫과 로직을 합치는 반복적인 과정인 경우가 많았습니다.
00:01:12모델이 점점 발전하고 Claude Code나 Cursor 같은 툴들이 업계를 지배하기 시작하면서
00:01:18기존의 SDLC만으로는 한계에 부딪히게 되었습니다.
00:01:20제대로 된 가치를 제공하기 위해서는 자생력을 잃은 SDLC의 변화가 불가피합니다.
00:01:24이것이 바로 에이전트 기반 개발 라이프사이클, 즉 ADLC가 등장한 배경입니다.
00:01:28ADLC는 기존 SDLC와 현재의 기술 환경 사이의 간극을 메워줍니다.
00:01:32ADLC가 필요했던 이유는 기존 SDLC를 적용하던 시스템의 경우,
00:01:36기획 단계에서 이미 시스템의 동작을 예측할 수 있었고 이를 검증할 방법도 있었기 때문입니다.
00:01:41쉽게 말해, SDLC는 소프트웨어를 '정적인 저작물'로 취급하는 반면 ADLC는 '살아있는 시스템'으로 다룹니다.
00:01:47AI 에이전트는 예측이 불가능하고, 스스로 추론하며 자신이 속한 환경에 태스크를 맞추어
00:01:53진화해 나가기 때문에, 전통적인 소프트웨어 기준의 지표로 평가하기가 까다롭습니다.
00:01:59결국 ADLC가 개발된 근본적인 이유는 프로덕션 환경에 배포된 AI 에이전트의 '비결정론적 특성' 때문입니다.
00:02:05AI 에이전트는 끊임없이 학습하고 지속적으로 발전하므로,
00:02:09에이전트가 어떤 아웃풋을 낼지 미리 확정 지을 수 없습니다.
00:02:12AI로 작업할 때 내리는 결정들은 프롬프트, 컨텍스트, 모델,
00:02:16그리고 연결된 모든 외부 툴에 따라 달라집니다.
00:02:18모델 자체도 여전히 가변적이기 때문에, 특정 프롬프트가 무엇을 반환할지 100% 확신할 수 없습니다.
00:02:25그렇기 때문에 본질적으로 SDLC와는 다른 성공 지표를 가져가야 합니다.
00:02:29ADLC에는 7가지 단계가 있으며, 각 단계는 어떤 식으로든 기존 SDLC 단계와 정확히 매핑됩니다.
00:02:36에이전트 시스템이든 아니든, 첫 번째 단계는 언제나 '기획'입니다.
00:02:41달라지는 것은 기획을 '어떻게' 하느냐입니다.
00:02:43에이전트의 경우, 비에이전트 시스템과 같은 방식으로 기획할 수 없습니다.
00:02:46전통적인 시스템과 달리, 로직의 흐름이 동일하게 적용되지 않기 때문입니다.
00:02:51따라서 ADLC의 첫 번째 단계인 '준비 및 가설 설정'은
00:02:54시스템 설계나 모델을 확정하기 전에 문제에 대한 탄탄한 이해를 다지는 것을 목표로 합니다.
00:02:59에이전트를 다룰 때는 사용자가 시스템과 어떻게 상호작용할지 이해해야 하며,
00:03:04모든 이해관계자와 조율하여 워크플로우가 끊기는 지점이 어디인지,
00:03:07반복되는 수동 작업이 무엇인지 파악해야 합니다. 에이전트가 실제로 해결해야 할 과제가 바로 이것이니까요.
00:03:12그런 다음 기존 워크플로우와 정책을 검토하여 현재 상황이 어떻게 처리되고 있는지 확인하고,
00:03:16그 내용이 명확해지면 에이전트가 워크플로우를 보조하거나 자동화할 지점에 대해 테스트 가능한 가설을 수립합니다.
00:03:22이 단계를 통째로 건너뛰면 엉뚱한 작업을 자동화하게 되고,
00:03:26문제를 해결하기는커녕 상황을 악화시킬 수 있습니다.
00:03:28여기서 SDLC와의 결정적인 차이는 '동작 방식'에 있습니다.
00:03:31SDLC에서는 동일한 입력이 언제나 동일한 출력을 보장하므로 동작을 예측할 수 있었습니다.
00:03:37하지만 ADLC는 모델이 개입하기 때문에 확률론적이며,
00:03:40같은 입력을 넣어도 완전히 똑같은 출력이 나오지 않을 수 있습니다.
00:03:43이 점을 인지하고, 가장 먼저 해야 할 일은 '기획 모드'를 켜는 것입니다.
00:03:47그리고 사용 중인 에이전트에게 구현 방식이 아닌, 개발하려는 에이전트의 '행동 양식'을 기획하도록 하세요.
00:03:52코드에 대한 생각은 접어두고 전체 워크플로우를 매핑하도록 프롬프트를 작성하세요.
00:03:56에이전트가 사용자와 어떻게 상호작용하는지, 어떤 문제가 발생할 수 있는지, 오버헤드는 무엇인지,
00:04:00시스템에 대한 모든 가정을 채워 넣는 겁니다.
00:04:03그렇게 하면 에이전트 구축 프로세스가 핵심 가정에서부터 시작되어,
00:04:06무작정 아키텍처 기획으로 뛰어드는 것보다 훨씬 좋은 길잡이가 됩니다.
00:04:10초기 기획이 끝나면 바로 다음 레이어가 이어지는데,
00:04:13여기서는 범위와 문제를 정확하게 식별하게 됩니다.
00:04:16이 단계는 비즈니스 요구사항을 분석하고 구현 가능성을 따지던
00:04:20SDLC의 '분석 단계' 또는 '타당성 검토'와 매핑됩니다.
00:04:25즉, ADLC의 이 단계는 주요 프로세스를 식별하고 이를 해결하는 데 있어 AI의 역할을 정의하며,
00:04:31제약 조건과 기술적 경계를 설정하는 영역입니다.
00:04:33또한 시간, 비용, 레이턴시, 타당성 같은 명확한 비즈니스 및 기술적 KPI를 사전에 정의합니다.
00:04:39이 시점에서 허용 가능한 요소와 그렇지 않은 요소를 구분하여 트레이드오프도 정의합니다.
00:04:44하지만 이 단계에서 가장 중요한 부분은 '인간-에이전트 책임 모델'을 제대로 설계하는 것입니다.
00:04:49이 모델이 있어야 책임 구조가 만들어지기 때문입니다.
00:04:52에이전트에게 모든 결정을 맡길 수는 없으므로 사람이 검토할 필요가 있습니다.
00:04:56이 단계가 끝날 때쯤이면 워크플로우 단계별 핵심 KPI가 명시되고,
00:05:02인간-에이전트 책임 모델이 명확히 담긴 문서가 준비됩니다.
00:05:05이것이 중요한 이유는 실패가 발생했을 때 그 책임을 모델에게만 전가할 수 없기 때문입니다.
00:05:09최종 책임은 결국 사람에게 귀속되어야 합니다.
00:05:12이러한 인간의 책임 기획은 과거 AI가 없던 시절에는 필요하지 않았던 부분입니다.
00:05:17이는 에이전트의 자율성 경계를 정의하는 것이며, 이 단계를 건너뛰면
00:05:21프로덕션 환경에서의 컴플라이언스와 책임 관리에 심각한 리스크를 안게 됩니다.
00:05:24이를 에이전트와 함께 진행하려면 다시 기획 모드를 활용해 워크플로우, 레이턴시, 시스템 문제,
00:05:30아키텍처에 포함되어야 할 모든 기능과 예상되는 실패 시나리오를 기획하도록 프롬프트를 작성하세요.
00:05:34이 내용들이 명확해지면 에이전트는 빌드 과정에서 반복 개선해 나갈 올바른 범위를 이해하게 됩니다.
00:05:39범위와 상위 수준의 기능이 정의되었다면 이제 '설계 단계'로 넘어갈 차례입니다.
00:05:43이 단계에서는 에이전트 자체의 시스템 아키텍처를 정의합니다.
00:05:47여기서 ReAct나 Plan-and-Act, 혹은 멀티 에이전트 구성 등 에이전트가 따를 패턴을 결정하게 됩니다.
00:05:54그리고 지점 간의 데이터 흐름을 기획하게 되는데, 이는 멀티 에이전트 환경에서 훨씬 더 중요해집니다.
00:06:00에이전트가 정확한 데이터를 받지 못하면 문제를 해결하기는커녕 또 다른 문제를 만들어내기 때문입니다.
00:06:05토큰 이코노믹스, 컨텍스트 편집 기능, 컴팩션(Compaction) 같은 비용 구조를 설계하고,
00:06:10이 에이전트를 프로덕션에 배포할 때 드는 비용이 어떤 수준일지,
00:06:14수많은 사용자를 처리하기 시작할 때 어떤 일이 일어날지 파악해야 합니다.
00:06:17또한 이 시점에 사용할 모델, 오케스트레이션 프레임워크,
00:06:23데이터베이스 및 기타 연계 기술을 실제로 선택하게 되며, 코드를 작성하기 전에
00:06:28무엇이 성공인지 정의해 두어야 TDD 방식으로 에이전트를 빌드할 수 있습니다.
00:06:32시스템이 라이브되기 전에 레이턴시, 정확도, 환각 현상 등의 트레이드오프를 이미 고려한 상태여야 합니다.
00:06:38이 단계에서도 에이전트의 기획 모드가 필요합니다.
00:06:41프롬프트를 통해 에이전트 아키텍처, 데이터 흐름, 비용 모델 및 전반적인 기술 구조를
00:06:46포괄하는 구체적인 설계를 그리게 함으로써 확고한 계획을 가지고 다음 단계로 나아갈 수 있습니다.
00:06:51초기 기획과 설계가 끝나면 다음 단계는 '시뮬레이션 및 가치 검증'입니다.
00:06:55여기서는 실제 데이터를 사용해 이전 단계들에서 세운 가정들을 테스트합니다.
00:06:59프로토타입을 만들어 이 에이전트를 계속 빌드해 나갈 가치가 있는지 판단하는 것이죠.
00:07:04기본적으로 이 단계는 실패 비용이 훨씬 낮기 때문에, 에이전트 개발 여부를 최종 결정하는 분수령이 됩니다.
00:07:10따라서 행동 테스트를 위한 데이터셋이나 그라운드 트루스(Ground Truth)를 준비하고,
00:07:15이전에 기록해 둔 리스크 높은 가정들을 테스트해 볼 프로토타입을 빌드하며,
00:07:19데이터 품질, 환각률, 정확도, 답변 품질 및 벤치마크를 검증하는 작업들이 핵심 활동에 포함됩니다.
00:07:25또한 초기 가설을 다시 짚어보며 투자 대비 효율(ROI)이 나올지 판단합니다.
00:07:30결과물로는 정확히 측정된 성능 및 비용 베이스라인과 함께,
00:07:33앞서 언급한 그라운드 트루스 문서가 생성되며, 이는 회귀 테스트와 모델 파인튜닝의 자산으로 활용됩니다.
00:07:40이 단계는 일종의 검증 관문 역할을 합니다.
00:07:42여기서 만족스러운 결과가 나오면 에이전트 개발을 계속 진행할 수 있습니다.
00:07:46그렇지 않다면 이 빌드는 실패한 것이며, 이를 조기에 발견하는 편이 훨씬 낫습니다.
00:07:50이 상태로 프로덕션에 나갔다면 그 피해는 걷잡을 수 없이 컸을 테니까요.
00:07:54이를 위해 AI 에이전트에게 첫 프로토타입을 만들도록 유도하고, 방금 기획한 모든 내용에 대해 테스트를 진행합니다.
00:08:00더 나아가기 전에, 저희 후원사인 Softr에 대해 잠시 말씀드리겠습니다.
00:08:04바이브 코딩(Vibe coding) 툴은 UI를 생성하는 데는 훌륭하지만, 실제 인증이나
00:08:08사용자 역할, 권한 관리, 또는 확장 가능한 데이터베이스가 필요한 순간 모든 것이 무너지고 다시 코드를 짜야 합니다.
00:08:14Softr는 단 한 번의 프롬프트로 이 모든 것을 처리하는 AI 앱 빌더입니다.
00:08:18필요한 기능을 평범한 영어로 설명하면, AI 공동 빌더가 풀스택, 데이터베이스, 페이지, 내비게이션, 로그인 및 역할 기반 권한을 한 번에 생성합니다.
00:08:28이것들은 껍데기뿐인 프로토타입 페이지가 아니라 실제로 작동하는 페이지들입니다.
00:08:30앱을 미리 보고 각 사용자 역할별로 무엇이 보이는지 확인할 수 있으며, 배포를 누르면 호스팅, 사용자 그룹, 엔터프라이즈급 보안 및 액세스 제어가 적용된 상태로 앱이 실시간 라이브됩니다.
00:08:40게다가 유지보수를 위해 개발자가 따로 필요하지도 않습니다.
00:08:42모든 것이 시각화되어 있어 워크플로우 업데이트, 사용자 관리, 기능 추가를 직접 하실 수 있습니다.
00:08:47소프트웨어의 진짜 비용은 구축이 아니라 유지보수에 있으며, Softr가 바로 그 문제를 해결합니다.
00:08:52더보기란의 링크를 클릭해 무료 AI 크레딧을 받고 지금 시작해 보세요.
00:08:57여기까지가 기획 단계를 마치는 지점이며, 이제 많은 이들이 바로 뛰어들곤 하는 '구현 단계'로 넘어갑니다.
00:09:03앞선 단계들을 제대로 수행했다면, 단계를 건너뛰었을 때 이 지점에서 대부분의 사람들이 겪게 되는 흔한 문제들을 피할 수 있기 때문에 매우 중요합니다.
00:09:11이 시점이 되어서야 실제로 에이전트를 개발하고, 핵심 로직을 구축하며, 개발 워크플로우를 조율하게 됩니다.
00:09:16그리고 여기서 SDLC와 ADLC의 가장 명확한 차이점 중 하나를 볼 수 있습니다.
00:09:20SDLC에서 로직은 코드, 구성 파일 및 서드파티 의존성 내에 존재합니다.
00:09:25반면 ADLC에서 로직은 코드, 프롬프트, 모델, 툴 및 외부 서비스 전반에 걸쳐 분산됩니다.
00:09:30따라서 이제는 소프트웨어만 관리하는 것이 아니라 이 모든 레이어를 함께 관리해야 하며, 어느 레이어 하나만 바뀌어도 시스템의 동작이 달라질 수 있습니다.
00:09:38개발할 멀티 에이전트 시스템이 있다면, 워크플로우를 조율하는 방법 중 하나로 Claude Code의 새로운 '에이전트 뷰(agents view)'를 활용할 수 있습니다.
00:09:44에이전트 뷰를 사용하면 일반적인 Claude 사용 방식보다 태스크를 훨씬 더 효율적으로 위임할 수 있습니다.
00:09:49서로 다른 Claude Code 세션을 각각 관리하는 대신, 단일 오케스트레이션 레이어를 관리하며 이를 통해 에이전트 매니저 프롬프트로 모든 에이전트를 조율하기 때문입니다.
00:09:57이제 이 단계에서 MCP 및 API 같은 툴을 연동하게 됩니다.
00:10:01예를 들어 개인 비서를 구축한다면 Google Calendar MCP, Gmail MCP, 그리고 Notion MCP 같은 것들이 필요하다는 점을 인지하게 되죠.
00:10:09그리고 여기서 무엇보다 중요한 것은 바로 '컨텍스트 관리'입니다.
00:10:11프로덕션을 위한 에이전트를 구축할 때, 컨텍스트 관리는 가장 치명적인 요소 중 하나가 되기 때문입니다.
00:10:16현재 Gemini나 Opus가 제공하는 100만 토큰 수준의 거대한 컨텍스트 창이 있더라도 여전히 세심한 핸들링이 필요합니다.
00:10:24에이전트가 올바른 메모리를 유지하고 '컨텍스트 부패(Context Rot)'가 일어나지 않도록 보장해야 합니다.
00:10:28무관한 정보가 과도하게 쌓이면 에이전트의 집중력이 흐트러지고 아웃풋의 품질이 저하되기 때문입니다.
00:10:34또한 변경 사항이 생길 때마다 요구사항에 맞춰 에이전트 구성을 수동으로 검증함으로써 행동의 일관성을 확보하는 개발자 측면의 테스트도 이 단계에서 수반되어야 합니다.
00:10:44에이전트 시스템에서 개발과 검증은 분리될 수 없습니다.
00:10:48작은 변화 하나가 전체 워크플로우에 거대한 나비효과를 불러올 수 있으므로, 끊임없는 테스트 없이는 한 걸음도 나아갈 수 없습니다.
00:10:54따라서 나중에 별도의 테스트 단계에만 의존할 것이 아니라, 에이전트를 빌드함과 동시에 개발자 수준의 검증을 나란히 진행해야 합니다.
00:11:01시스템 구축을 완료했다면 다음 단계는 '테스트 단계'입니다.
00:11:05앞서 말씀드렸듯이 테스트는 빌드 과정 전반에 걸쳐 지속되어야 하지만, 시스템이 완성된 후에는 개별 컴포넌트 단위가 아닌 실제 프로덕션과 유사한 환경에서 테스트를 거쳐야 합니다.
00:11:14이 시점이 바로 '통합 테스트'를 수행하는 단계입니다.
00:11:16또한 실제 사용자들로부터 피드백을 수집하고 이를 다시 시스템에 반영하는 '사용자 수용 테스트(UAT)'도 진행합니다.
00:11:24라이브 버전이 배포되기 전에 안전성을 확보할 수 있도록 편향성, 컴플라이언스, 성능 및 기타 리스크 관련 요소를 종합적으로 테스트합니다.
00:11:32그리고 이 지점이 바로 성공 지표의 패러다임이 완전히 바뀌는 곳입니다.
00:11:35SDLC에서는 단순히 통과(Pass) 아니면 실패(Fail)로 나뉘는 테스트를 통해 기능적 정확성을 측정했습니다.
00:11:40반면 ADLC에서는 정확도 분포, 환각률, 결과물당 비용을 측정하는데, 이 지표들은 단순한 성공이나 실패로 무 자르듯 나눌 수 없기 때문입니다.
00:11:48테스트의 패러다임 자체도 함께 이동합니다.
00:11:50SDLC에서는 미리 정의된 테스트가 기정의된 코드 경로를 검증했습니다.
00:11:54그러나 ADLC에서는 추론 능력, 안전성 및 툴 사용에 대한 지속적인 평가가 주를 이룹니다. 에이전트가 같은 경로를 똑같은 방식으로 두 번 달리는 경우는 없기 때문입니다.
00:12:02RAGAS나 DEEPVAL 같은 다양한 평가 프레임워크가 존재하지만, 결국 정확성을 검증하는 핵심은 앞서 정의한 지표 대비 데이터가 어떤 성과를 내는가입니다.
00:12:12에이전트 시스템을 테스트하는 방법에는 기능, 비기능, 구조 및 부하 테스트를 포함하여 여러 가지가 있습니다.
00:12:18이 각각의 테스트는 에이전트 기반 시스템 자체를 활용하여 철저히 수행되어야 하며, 이를 통해 예외 케이스(edge case)를 제대로 식별하고 프로덕션 반영 전에 수정해야 합니다.
00:12:27또한 저희 콘텐츠가 마음에 드신다면 좋아요 버튼을 눌러주세요. 더 좋은 영상을 만들고 더 많은 분들께 다가가는 데 큰 도움이 됩니다.
00:12:34시스템이 준비되었다면 이제 이를 배포하여 실제 세상에 공개할 시간입니다.
00:12:39그저 다이렉트로 배포하고 끝내서는 안 됩니다. 에이전트 시스템에는 훨씬 더 많은 고려사항이 얽혀있기 때문입니다.
00:12:44일반적인 시스템에서 배포란 보통 코드를 프로덕션에 밀어 넣고 시스템 헬스(정상 작동 여부)를 모니터링하는 것을 의미합니다.
00:12:49하지만 에이전트 시스템에서는 완전히 다른 양상을 보이며, 여기서 배포라는 단어의 의미 자체가 변화합니다.
00:12:54SDLC에서 배포는 개발의 종료이자 안정적인 운영 단계의 시작이었으며, 소프트웨어가 안정기에 접어드는 시점이었습니다.
00:13:02반면 ADLC에서 배포는 모델 업데이트, 컨텍스트 드리프트(drift), 가변적인 환경 변화에 대응하기 위한 활발한 모니터링과 제어의 시작점입니다.
00:13:11따라서 개발이 완료되었더라도 이 단계가 훨씬 더 크리티컬합니다. 이제 에이전트의 행동적 지표와 시스템적 지표를 능동적으로 추적해야 하기 때문입니다.
00:13:19또한 품질, 안전성, 성능 문제를 지속적으로 감시하는 알림 규칙을 설정하여 대규모 프로덕션 에러로 번지기 전에 조기에 잡아내야 합니다.
00:13:28배포는 본질적으로 실제 사용자가 시스템과 상호작용하는 동안 지속적인 관찰을 수반하는 '통제된 활성화' 과정입니다.
00:13:34단순히 인프라 건강 상태에만 치중할 것이 아니라 행동 성능에 집중해야 전체 사용자에게 전파되기 전에 문제를 잡을 수 있습니다.
00:13:41실무적으로는 우선 제한된 유저 그룹에 시스템을 릴리스하여 실제 환경에서 사용하게 합니다.
00:13:46그런 다음 시간이 지남에 따라 에이전트 시스템이 어떻게 반응하는지 관찰한 후 점진적으로 전체 확대 배포를 진행합니다.
00:13:52구현이 모든 프로세스를 거치고 나면, 유지보수와 지속적인 학습 및 성장의 연속적인 사이클로 접어듭니다.
00:13:58이는 에이전트의 정확도를 유지하고 실제 세상의 요구사항과 얼라인먼트를 맞추기 위해 매우 중요한 단계입니다.
00:14:03전통적인 시스템에서는 피드백 루프가 상대적으로 단순했습니다.
00:14:06사용자가 버그를 제보하면 개발자가 이를 수정하기 위해 코드를 수정하는 방식이었죠.
00:14:10하지만 에이전트 시스템은 어느 한 시점에 멈추지 않는 지속적인 개선 프로세스를 기반으로 하기 때문에 완전히 다릅니다.
00:14:16이 사이클은 모델을 끊임없이 정제하며, 모든 부정적인 시그널을 다시 피드백으로 취합해 시간이 흐를수록 행동을 개선해 나갑니다.
00:14:22이는 대개 답변에 대한 유저의 반응을 포착하는 '좋아요'나 '싫어요' 같은 UI 시그널을 통해 이루어집니다.
00:14:29이미 많은 프로덕션 시스템에서 복수의 출력 중 하나를 선택하거나 답변 순위를 매기는 방식을 쓰고 있으며, ChatGPT나 Claude의 피드백 시스템이 좋은 예시입니다.
00:14:39이러한 시그널들이 에이전트 시스템으로 다시 유입되어 에이전트가 학습하고 더 나은 성능을 향해 나아갈 수 있도록 합니다.
00:14:44또한 데이터 소스와 임베딩을 정기적으로 업데이트하여 시스템이 최신 상태를 유지하고 노후화된 정보로 인해 문제 가 생기지 않도록 관리합니다.
00:14:52프롬프트 인젝션 같은 온갖 종류의 리스크와 프롬프트 공격에 대해 안전장치와 가드레일이 유효하도록 얼라인먼트를 상시 모니터링해야 합니다.
00:15:00여기서 핵심 변수는 지속적인 비용 관리, 품질 추적, 제품 개선 백로그, 그리고 모델 업그레이드이며, 이 모두가 장기적으로 시스템을 안정적이고 안전하며 정상 작동하도록 유지하기 위해 지속 관리되어야 합니다.
00:15:11준비한 내용은 여기까지입니다.
00:15:13채널을 후원하고 이러한 영상 제작을 계속해서 응원하고 싶으시다면 아래의 Super Thanks 버튼을 이용해 주시기 바랍니다.
00:15:20시청해 주셔서 언제나 감사드리며, 다음 영상에서 찾아뵙겠습니다.