https://www.youtube.com/watch?v=pKjf4B6WqU8
📌 Copilot Studio Dudecast EP3에서 Bas Brekelmans는 누구인가?
Copilot Studio의 CTO인 Baz Brekelmans와 함께하는 이 대화는 AI 모델의 급격한 발전 속도에 맞춰 엔터프라이즈 AI 플랫폼이 어떻게 진화해야 하는지에 대한 핵심 통찰을 제공합니다. 특히, 모델 선택의 유연성 확보와 안정적인 배포 프로세스 재정립이라는 CTO의 고민을 통해, 개발자들이 과도한 프롬프트 엔지니어링 대신 평가(Evals) 기반의 데이터 중심 접근으로 전환해야 하는 실질적인 이유를 배울 수 있습니다. 이 콘텐츠는 AI 기술의 최전선에서 발생하는 엔지니어링 및 아키텍처의 근본적인 변화를 이해하고, 미래 AI 개발의 방향성을 설정하는 데 필수적인 인사이트를 제공합니다.
1. 팟캐스트 소개 및 게스트 소개
팟캐스트 시작: Copilot Studio Dudecast의 세 번째 에피소드 시작을 알림.
특별 게스트 소개: Copilot Studio의 CTO인 Baz Brekelmans가 게스트로 출연함.
인사 및 근황: 진행자(Dwayne)와 Baz가 오랜만에 만나 인사를 나누며, 최근 콘퍼런스 참석 등으로 매우 바빴음을 언급함.
진행자 근황 설명: 진행자가 최근 영상 제작이 뜸했던 이유로 추수감사절, 크리스마스 등 연이은 행사 참석을 꼽음.
게스트 환영: Baz가 진행자에게 반가움을 표함.
2. Baz Brekelmans의 경력 및 대화의 배경
2.1. 대화의 배경 및 AI 발전 속도
과거 인연: 진행자와 Baz는 오랫동안 함께 일했으며, Baz는 PVA 팀에 합류했을 때부터 Bot Framework에 관여했음.
Baz의 역할: Baz는 SAS 서비스 구축 초기부터 대화형 AI 분야의 주요 아키텍트 중 한 명이었음.
Baz의 경력:
십대 때부터 소프트웨어 개발에 열정적이었음.
네덜란드 출신이며 시애틀에서 11년째 근무 중이며, 모든 경력이 Microsoft에서 이루어졌음.
약 6년간 대화형 AI 분야에서 일했으며, 2019년 말경에 초기 PVA 팀에 합류했음.
AI 발전의 롤러코스터: 진행자는 ChatGPT 등장(2022년 11월경) 이후 대화형 AI 분야가 급격히 변화했으며, 특히 GPT-3 이후 모델들이 빠르게 진화하고 있음을 언급함.
2.2. GPT-2 시기의 초기 실험
GPT-2 활용: ChatGPT 이전인 GPT-2 시기에도 실험을 진행했음.
초기 에이전트 구조: 전통적인 의도(Intent) 기반 에이전트에서, 의도가 트리거되지 않을 경우 GPT-2 모델(당시의 기초적인 LLM)을 트리거하여 사용했음.
GPT-2의 능력: GPT-2는 텍스트 완성 모델로, 이전 발언(예: 이름, 성, 아버지 이름)을 기반으로 모노그램 수건에 들어갈 세 글자를 추론하는 등 일부 추론이 가능했으나, 주로 묘기(gimmicky) 수준이었음.
3. ChatGPT 이후 엔터프라이즈 AI의 진화와 CTO의 고민
3.1. 초기 RAG 도입과 모델 발전 속도
ChatGPT 폭발적 성장: 2022년 말/2023년 초에 ChatGPT가 폭발적으로 성장하면서 엔터프라이즈 대화형 AI 공간의 진화 필요성을 인식함.
초기 RAG: 초기에는 간단한 RAG(검색 증강 생성)를 사용하여 웹 검색 및 SharePoint 검색을 수행했으며, 이는 마법처럼 보였음.
지속적인 개선: 이후 액션 오케스트레이션 등을 통해 RAG를 개선했으며, 모델 발전 속도가 가속화되고 있음을 확인하고 있음.
3.2. CTO의 주요 고민: 모델 관리와 안정성
가속화되는 모델 출시: GPT-5 출시 이후 GPT-5.1, GPT-5.2가 불과 2주 간격으로 나오는 등 모델 출시 속도가 매우 빨라지고 있음.
플랫폼의 과제: 플랫폼으로서 다음과 같은 문제들을 관리해야 함.
어떤 에이전트가 어떤 모델을 사용할지 관리하는 방법.
고객이 최신 모델로 전환할 때 기존 시스템이 깨지지 않도록 보장하는 방법.
진행자의 질문: 진행자는 이러한 빠른 변화가 Baz를 잠 못 이루게 하는 이유가 무엇인지 질문함.
4. 엔터프라이즈 배포 프로세스의 재정립
4.1. 전통적 배포 방식의 한계
주요 도전 과제: 가속화되는 모델 변화 속도에 맞추는 것이 주요 도전 과제임.
전통적인 엔터프라이즈 소프트웨어 방식: Copilot Studio 플랫폼은 전통적인 엔터프라이즈 소프트웨어처럼 작동했음.
개발자가 Pull Request(PR)를 작성하면 여러 사람이 검토함.
PR은 광범위한 테스트와 여러 환경 배포 단계를 거침.
이 배포 프로세스는 약 4주가 소요되었음.
새 모델 출시 시 문제: 새로운 모델이 출시되는 당일에 배포 프로세스를 시작하면, 고객들은 한 달 후에야 새 모델을 사용하게 되어 "왜 이렇게 느리냐"고 불만을 제기하게 됨.
인프라 및 패턴 재구상: 이러한 문제를 해결하기 위해 인프라와 패턴을 재구상하는 과정에 있으며, 당일 출시를 목표로 하고 있음.
4.2. 안정성과 최신 모델 사용의 상충 해결
상충되는 요구사항:
안정성 요구: 대규모 워크로드를 운영하는 프로덕션 고객은 안정성을 요구함.
최신 모델 요구: 다른 고객들은 새로운 모델을 즉시 사용해보고 싶어 함.
새로운 배포 프로세스: 두 요구사항을 모두 충족시키기 위해 배포 및 엔지니어링 프로세스를 재정비함.
즉시 배포: 프로덕션에 즉시 배포하되, 모델을 선택하고 옵트인(opt-in)한 고객에게만 적용함.
점진적 롤아웃: 이후 시간이 지남에 따라 점진적으로 광범위하게 롤아웃함.
아키텍처 변화: 백엔드 구성 요소를 다양한 유형의 에이전트와 고객에게 노출하는 방식에 대한 재고가 필요해짐.
4.3. 모델 선택 기능의 중요성
모델 선택 토글: 모델 선택 기능이 출시되면서, 사용자가 구형 모델에 30일 더 머무를 수 있는 토글 기능이 추가되어 테스트 시간을 확보할 수 있게 됨.
모델 선택의 영향 범위: 모델 선택 기능은 초기처럼 요약 엔진뿐만 아니라 전체 오케스트레이션 엔진에도 영향을 미치며, 지침(Instructions) 및 설명(Descriptions) 적용 방식에도 영향을 줌.
오케스트레이션의 슈퍼파워: 진행자는 오케스트레이션 계층이 단순 RAG와 Copilot Studio의 진정한 차별점(슈퍼파워)이라고 강조하며 이에 대한 설명을 요청함.
5. 오케스트레이션 계층의 진화: 프롬프트에서 도구 호출로
5.1. 모델 능력에 따른 오케스트레이션 변화
혁신 속도와 모델 연동: 혁신 속도가 모델 발전에 매우 밀접하게 연관되어 있어 플랫폼도 자주 재정비해야 함.
초기 모델의 한계 (GPT-3/3.5): 초기 모델들은 요약에는 능숙했으나, 대규모 컨텍스트 분석 및 반복적인 의사 결정에는 취약했음.
초기 LLM 기반 액션 결정: Copilot Studio 초기에는 LLM이 사용자 입력에 기반하여 어떤 액션을 취할지 결정하도록 시도했음 (클래식 인텐트 트리거링 모델을 LLM 기반으로 전환).
도구 호출 이전의 패턴: 당시 모델들은 도구 호출(Tool Calling)이나 대규모 컨텍스트 창을 지원하지 않았음.
푸시(Pushy) 기법 사용: 사용자의 입력 요약본을 추출하고 어떤 액션을 취할지 결정하도록 유도하는 매우 적극적인 프롬프트 패턴을 사용함.
가드레일 및 프롬프트: 액션 결정 후 파라미터를 채우기 위해 많은 가드레일과 프롬프트를 추가했음.
모델 진화에 따른 변화: 모델이 발전하면서 이러한 가드레일을 제거할 수 있게 됨.
5.2. 최신 모델(Sonnet 45, GPT-4, GPT-5)의 변화
Sonnet 45의 경우: Copilot Studio에서 Sonnet 45를 사용할 경우, 사실상 프롬프트가 거의 필요 없으며, 에이전트 지침이 모델에 전송되고, 추가된 토픽/지식/액션은 도구로 작동함 (엔터프라이즈 보안 및 거버넌스 적용).
GPT 모델의 변화: GPT-4도 이전 버전 대비 가드레일이 많이 제거되었으며, GPT-5는 더 많은 가드레일을 제거하는 추세임.
목표: GPT 모델에서도 Anthropic 스타일의 오케스트레이션(개발자가 에이전트에 넣는 지침만 프롬프트로 사용)을 구현하는 것을 목표로 함.
6. 보안, 정확성, 성능 관점의 변화
6.1. 과거의 제어 방식과 현재의 보안/정확성 접근법
진행자의 질문: GPT-4o 시기에 컨트롤 플레인의 프롬프트를 제거하는 것이 보안에 취약해지는 것이 아닌지, 과거와 현재의 오케스트레이션 방식 차이와 성능 영향에 대해 질문함.
과거 제어의 목적: 과거에 구축한 구조(컨트롤)는 순전히 정확도(Accuracy)를 높이기 위한 목적이었음.
프롬프트 보안의 한계: 프롬프트를 사용하여 시스템을 보호하는 것은 작동하지 않으며, 이는 SQL 쿼리에서 파라미터화가 되기 전의 상황과 유사함 (보안 패턴과 우회 시도 간의 고양이와 쥐 게임).
LLM의 특성: LLM은 데이터와 지침을 분리하는 개념이 없으나, 사용자 데이터와 시스템 지침을 분리하는 능력이 향상되고 있음.
보안 및 접지(Grounding) 접근:
보안: 프롬프팅에 의존할 수 없으므로, LLM 레이어 외부에서 추가적인 보호 장치를 적용함.
환각 방지 (Grounding): HR 정책 문서와 같은 특정 문서 기반 답변이 필요할 때, 모델에게 인용(Citations)을 많이 포함하도록 지시하고, 해당 인용이 실제 내용과 일치하는지 외부에서 확인하여 보호 장치를 마련함.
안정성: 모델이 진화해도 이러한 외부 가드레일은 비교적 안정적으로 유지될 수 있음.
과거 제어의 본질: 과거에 인텐트 캡처, 파라미터 수동 채우기 등을 분리했던 것은 정확도를 높이기 위함이었으며, 특히 3.5 Turbo 모델에서 도구 호출 정확도가 낮았기 때문임.
6.2. 성능(Latency) 및 비용 관리
현재의 단순화: 모델이 발전하여 이제는 단순히 모델을 호출할 수 있게 됨.
LLM 실행의 복잡성: LLM 실행은 여러 GPU가 동시에 작동해야 하는 복잡한 엔지니어링 과제이며, 실패 시 재시도 등으로 인해 지연 시간(Latency)이 증가하고 비용도 높아짐.
최적화 목표: 경험적으로 모델과의 왕복 횟수(Round Trips)가 많을수록 지연 시간과 비용이 증가하므로, 왕복 횟수를 줄이는 것이 목표임.
정확도와 트레이드오프:
왕복 감소: 모델의 향상된 추론 능력을 활용하여 왕복 횟수를 줄여 더 빠르고 안정적인 결과를 얻고자 함.
데이터 피딩 증가: 정확도를 높이기 위해 LLM에 더 많은 데이터를 피딩하고 있으나, 이는 비용과 지연 시간을 약간 증가시킴. 하지만 정확도 향상이라는 이점이 항상 가치가 있음.
7. 단일 호출(One-Shot) 목표와 실시간 음성 대화
7.1. 단일 호출(One-Shot) 목표 달성 노력
과거의 다중 호출: 과거에는 정확도와 규칙을 맞추기 위해 모델에 6번까지 호출해야 하는 경우도 있었음.
궁극적 목표: 단 한 번의 호출(One Shot)로 필요한 결과를 얻는 것이 궁극적인 목표임.
지연 시간 문제: 다중 호출은 응답 시간을 계속 증가시키므로, 이 지연 시간을 해결하는 것이 중요함.
가까워지는 실현: 진행자는 이러한 수준의 빠른 대화(낮은 지연 시간)가 생각보다 가까워지고 있다고 기대함.
7.2. 실시간 음성 시나리오와 워크플로우 결합
실시간 모델 파트너십: Microsoft의 컨택 센터 그룹 및 음성 기반 시스템과 협력하여 실시간 모델을 사용하고 있음.
음성 대화의 구조:
Copilot Studio 에이전트 지침으로 모델을 지시하고, 에이전트의 도구를 사용함.
모델은 사용자(User)와 실시간으로 인터페이스하며, 오디오 프레임이 모델과 오가도록 함.
Copilot Studio 시스템은 런타임보다는 컨트롤러 역할을 수행함.
API 호출이나 통합이 필요할 때만 개입함.
결과: 사용자는 실시간 음성 대화가 가능해짐.
결정적 워크플로우와의 페이징(Paging): Copilot Studio의 강점 중 하나는 결정적 워크플로우(Deterministic Workflow)와 LLM 실행 간에 전환(Phase In/Out)할 수 있다는 점임.
예시 (계좌 잔액 확인): 계좌 잔액 확인을 위해 인증(PIN 코드 확인 등)이 필요할 경우, LLM 대화에서 결정적 워크플로우로 전환하여 기존 IVR처럼 처리한 후, 워크플로우 완료 시 업데이트된 컨텍스트와 지침을 가지고 다시 LLM으로 돌아옴.
엔터프라이즈 적용: 음성 대화는 훌륭하지만, 실제 배포 가능한 엔터프라이즈 시나리오로 전환되려면 이러한 워크플로우 결합이 필수적임.
9. 개발 패러다임의 근본적 변화: 토픽에서 지침(Instructions)으로
9.1. 토픽 작성 불필요성의 대두
플랫폼 전반의 진화: 플랫폼 전반에 걸쳐 많은 작업이 진행 중임.
지침(Instructions)의 중요성: 진행자는 이제 토픽(Topic)을 작성할 필요 없이 지침과 설명을 통해 기존 토픽보다 더 유연한 결과물을 만들 수 있다는 개념을 정착시키고 싶어 함.
복잡한 시나리오 예시 (조달 시스템): 진행자가 SAP Aribo를 백엔드로 사용하는 복잡한 조달 시스템을 구축한 사례를 언급함.
이 시스템은 하위 에이전트(Child Agents)와 지침, 도구, 설명만을 사용하여 구축되었으며, 기존의 토픽 기반 방식보다 훨씬 복잡한 대화 능력을 구현함.
과거와의 비교: 과거에는 인텐트 정확도와 발화(Firing)가 중심이었으나, 이제는 그 단계를 넘어섰음.
9.2. 에이전트 구축의 새로운 가치: 평가(Evaluations) 중심 접근
과거의 에이전트 구축: 과거에는 에이전트 구축이 마치 애플리케이션을 만드는 것과 같았으며, AI 모델은 일부 기능만 수행하는 결정론적이고 예측 가능한 방식이었음.
미래 가치: 앞으로의 진정한 가치는 에이전트 주변에 구축할 수 있는 평가(Evaluations, Evals)에 있음.
새로운 에이전트 시작 방식: 에이전트 구축은 "이 에이전트에게 무엇을 기대하는가?", "어떤 데이터가 입력되어야 하는가?", "결과물은 무엇이어야 하는가?"를 정의하는 것에서 시작됨.
평가자(Evaluators) 기능 출시: 한 달 전에 제품 내 평가자 구축 기능의 첫 버전을 출시했으며, 이는 강력한 집중 영역임.
채점자(Graders) 기능:
사용자가 자체적인 채점자(Graders)를 추가할 수 있음.
예시 (HR 정책 에이전트): HR 정책 준수 여부를 평가하는 채점자를 만들어, 에이전트의 응답이 정책에 얼마나 부합하는지 점수를 매길 수 있음.
결과 확인: 현재 프롬프트, 모델, 도구 조합으로 특정 데이터 세트에서 에이전트가 어떻게 작동하는지에 대한 판단(Judgment)을 얻을 수 있음.
자신감을 가지고 진화: Evals는 에이전트를 자신감을 가지고 진화시키는 데 도움을 줌 (새 기능 추가, 지침 변경, 모델 변경 테스트).
모델 추천: 시간이 지남에 따라 Evals를 사용하여 최적의 모델을 추천할 수 있게 됨 (예: GPT-5.1이 특정 에이전트에 더 잘 작동한다고 추천).
패러다임 전환: 에이전트 구축이 모델 훈련과 유사하게 변모했으며, 결정은 다양한 사용 사례와 시나리오를 평가한 데이터를 기반으로 이루어져야 함.
시간 축 이동: 개발 시간 축이 특정 워크플로우나 액션 개발에서, 입력 대비 기대되는 결과를 정의하는 쪽으로 이동함.
9.3. 피드백 루프를 통한 지속적 개선
분석을 통한 문제 식별: 사용자 분석을 통해 에이전트가 답변하지 못한 질문(예: 스위스 휴가 정책)을 파악할 수 있음.
Evals 추가 및 개선: 해당 질문에 대한 Evals를 추가하고, 기대하는 결과를 설정한 후, 에이전트가 실패하는 것을 확인하고 필요한 지식/문서를 추가하여 개선되는 것을 관찰함.
순환 구조: 에이전트를 평가하는 데이터를 추가하고 개선하는 피드백 루프를 통해 반복적으로 발전시킴.
10. 개발자 관점의 변화: 프롬프트 엔지니어링 과잉과 위임
10.1. 조달 시스템 구축 사례와 프롬프트 과잉 문제
현대적 접근 시도: 진행자는 조달 시스템을 현대적인 생성형 AI 애플리케이션 방식으로 구축하려 시도함.
도구 정의: 첫 단계는 필요한 데이터 호출과 반환 데이터를 정의하고, 모델이 이를 이해하도록 도구를 설명하는 것이었음.
하위 에이전트 활용: 기능 그룹별로 논리적으로 묶어 오케스트레이션하고 제어하기 위해 하위 에이전트를 사용함.
예기치 않은 결과 (재주문): 과거 주문 조회 도구를 만들었을 때, 재주문(Reorder) 기능은 별도 구축 없이 자동으로 작동함.
과도한 제어의 부작용: 첫 테스트에서 모델이 모든 것을 재주문해버렸고, 이에 "실행 전에 확인하라"는 지침을 추가해야 했음.
올바른 접근:
필요한 데이터 정의, 기능 컨테이너화, 제어 및 설명.
이후에는 프롬프트를 과도하게 엔지니어링하는 대신, 살짝 넛지(nudge)하고 테스트(Evaluation)를 통해 개선해야 함.
전통 개발자의 함정: 전통적인 개발자들은
if-then구조를 쓰려는 경향이 있어, 오히려 과도하게 제어하려다가 에이전트의 기능을 저해하고 비효율적으로 만들고 있음.오케스트레이션의 변화: 개발자가 백엔드에서 무거운 작업을 처리하는 대신, 모델이 오케스트레이션의 많은 부분을 처리하도록 위임하는 방향으로 변화하고 있음.
10.2. 개발자 역할의 변화: 관리자 역할로의 전환
개발자 역할의 변화: 개발자들은
if-then개념을 버리고, 데이터 과학자나 모델 트레이너처럼 넛지를 통해 에이전트를 유도해야 함.엔지니어링 에이전트 개발 사례: Baz는 엔지니어 지원 에이전트를 개발하며 Evals로 시작했음 (누락된 지식 소스, 잘못된 모델 선택 등).
지침의 역효과: GPT-5.1, 5.2에서 테스트했을 때, "에이전트 지침에 항상 접지되어야 한다"는 지침이 오히려 많은 경우 성능을 악화시켰음.
모델의 능력: 최신 모델, 특히 추론 모델은 매우 뛰어나서, 개발자는 무엇을 할지 설명만 하면 되고, 어떻게 할지를 지시할 필요가 없음.
인사 관리 비유: 유능한 직원에게는 문제만 제시하고 해결을 맡기지만, 덜 유능한 직원에게는 세부 지침을 제공해야 하는 것과 같음. 최신 모델은 전자에 해당함.
10.3. 개발자의 역할 변화와 기술 격차
위임의 수용: 개발자들은 더 많은 것을 위임하고 덜 직접 제어하는 방향으로 나아가야 하며, 이는 많은 사람들에게 어려운 전환임.
코드 삭제: Copilot Studio 내부에서도 과거에 필요했던 코드를 삭제하고 모델이 처리하도록 두는 작업을 진행 중임.
11. 엔지니어링 조직 및 플랫폼의 변화
11.1. 엔지니어링 생산성 및 인력 재편
진행자의 농담: 진행자는 Baz 밑에서 2주 일했으며, Baz가 자신에게 많은 지침을 줘야 했던 직원 중 하나였다고 농담함.
엔지니어링 변화: Baz는 엔지니어링 조직 내에서도 많은 변화가 일어나고 있음을 언급함.
고성과자 생산성 증가: 최고 성과를 내는 엔지니어들은 더욱 생산적이 되고 있음.
선임 엔지니어의 역할 변화: 선임 엔지니어들은 문제 해결 방법을 후배에게 설명하고 위임하는 데 능숙했으나, 이제 AI 모델이 더 유능해짐.
GitHub Copilot 활용: 팀 엔지니어의 99%가 GitHub Copilot을 매일 사용하고 있음.
새로운 인력 요구사항: 생산성 향상은 문제 영역을 식별하고 문제를 명확하게 설명하는 능력에 달려 있으며, 이는 아키텍트나 시니어 엔지니어의 역할임.
인력 파이프라인 압력: 전체 엔지니어링 인력과 파이프라인에 압력이 가해지고 있으며, 더 많은 사람들을 고성과자처럼 만드는 방법에 대한 고민이 필요함 (재교육, 훈련, 견습 제도 등).
자동화된 기술 부채 해결: 패키지 업그레이드, 보안 수정, 기술 부채 해결 등도 자동화되고 있음.
패턴 식별: 주요 작업은 문제의 패턴을 식별하고 해결 방법을 정의하는 것임.
에이전트의 역할: 이 패턴을 에이전트에게 주면, 에이전트가 코드를 검토하고 PR을 보내며 매우 빠르게 작동함.
코드 생성 능력의 기하급수적 성장: 최신 모델들은 자율적으로 여러 파일을 편집하고 대규모 리팩토링을 수행하며, 테스트도 매우 잘 되어 있어 결과물이 기하급수적으로 증가하고 있으며, 이는 플랫폼 개선 속도를 높임.
11.2. 디자인 문서 생성 사례
디자인 문서 자동화: 이제는 설계 문서 작성 방식도 변하고 있으며, Baz는 Researcher를 많이 사용하고 있음.
Researcher 활용: 지난주, 특정 문제에 대해 한 페이지 분량의 요구사항을 작성하고 Researcher에게 기술 설계 문서를 요청함.
결과: Researcher는 12분 만에 29페이지 분량의 상세 설계 명세서를 생성했으며, 이는 인간이 몇 주를 투자해야 나올 수 있는 수준보다 뛰어났음.
모델의 지식: 모델은 엣지 케이스, 확장성 문제, 테스트 및 검증 방법, 통합 방법 등 본질적인 소프트웨어 엔지니어링 지식을 바탕으로 모든 것을 매우 잘 설명함.
광범위한 영향: 이러한 변화는 디지털 또는 텍스트 기반 출력이 있는 거의 모든 분야에 영향을 미칠 것임.
12. 역할 변화에 대한 논의: 관리자화와 언어 숙련도
12.1. 개발자의 역할 변화: 관리자 및 평가자
고객 사례: 진행자가 한 엔지니어링 관리자 고객에게 "설명하고, 데이터 가져올 방법을 제공한 후, 넛지하라"는 접근법을 보여주었을 때, 그 관리자는 직업을 바꿔야 할 것 같다고 반응함.
진화의 필요성: 직업을 바꿀 필요 없이, 작업 방식을 진화시켜야 함.
새로운 역할: 모든 인간이 '관리자(Manager)'가 되어 '실행자(Doers)'를 관리하는 역할로 전환되고 있음.
핵심 업무: 실제 코딩이나 작업을 수행하는 것이 아니라, 결과물을 평가하고 등급을 매기는 것이 핵심 업무가 됨.
위임과 평가: 원하는 작업을 수행하도록 올바른 직원(에이전트)에게 설명하고 위임하며, 그 성능을 평가하는 역할임.
12.2. 언어 숙련도의 중요성
언어 장벽: C를 잘 모르면 C# 코드를 작성하기 어려운 것처럼, 사용하는 언어(자연어)에 대한 숙련도가 중요해짐.
가치 제안의 변화: 과거에는 작성한 코드 라인 수가 가치였다면, 이제는 관리할 수 있는 에이전트의 수가 가치가 될 수 있음.
12.3. 명시적 프로세스 정의와 언어 장벽의 위험
위임 능력: 모든 사람은 작업 위임 능력을 갖춰야 함.
암묵적 프로세스의 명시화: 문제를 해결할 때 무의식적으로 하던 단계(예: 어떤 파일을 변경할지 매핑하는 단계)를 의식적으로 명시해야 함.
전문 에이전트의 부재: 소프트웨어 엔지니어링 분야에는 이미 전문 에이전트가 있어 암묵적인 단계를 처리해주지만, 다른 분야에는 아직 강력한 범용 에이전트가 부족함.
자기 성찰의 필요성: 문제 해결 과정(추론 방식, 단계)을 반성하고 명시할 수 있어야 자동화에 활용할 수 있음.
언어 장벽의 위험: 진행자는 일본어를 모르기 때문에 일본어 지원 에이전트를 운영해도 고객이 만족할 수 있지만, 자신이 제대로 하고 있는지 알 방법이 없음.
위험성: 전문 지식(예: 일본어) 없이는 에이전트가 잘못된 일을 하고 있어도 알 수 없어 위험함.
필요성: 효과적으로 자동화하고 개선하려면, 해당 분야의 전문 지식(언어 능력)이 필요함.
Evals의 역할: 전문가의 감독 없이 모델을 사용할 때 발생하는 위험을 줄이기 위해 Evals를 정의하고 기대치를 설정하는 것이 중요함.
12.4. 언어 능력의 미래 가치
미래의 코딩 언어: 진행자는 구사하는 언어(Spoken Languages)가 미래의 코딩 언어가 될 것이라고 믿음.
언어 능력의 가치: 영어를 할 수 있는 것은 기본이지만, Baz가 네덜란드어를 유창하게 하는 것은 네덜란드어 에이전트를 제작할 때 매우 가치 있는 자산이 됨.
가치 재평가: 과거에는 여행 시 맥주 주문 정도의 유용한 스킬이었으나, 이제는 훨씬 더 가치 있는 기술 세트가 됨.
농담: 진행자는 암스테르담에 갈 때 Baz를 데려가 맥주 주문을 맡긴다고 농담하며 Baz의 다국어 능력을 칭찬함.
13. Baz가 기대하는 미래 기술과 플랫폼 발전 방향
13.1. 플랫폼의 빠른 진화와 모델 배포 준비
가장 기대되는 점: 올해는 시스템을 더 빠르게 진화할 수 있도록 만드는 데 집중했으며, 내년에는 이 속도가 더욱 가속화될 것으로 기대함.
모델 제공업체와의 동시 출시: 하반기부터 모델 제공업체와 동시에 모델을 출시하기 시작함.
새로운 파트너십: Anthropic과의 새로운 파트너십을 구축했으며, 향후 더 많은 파트너십이 있을 수 있음.
내부 배포 포털: 내부 포털을 통해 새로운 모델을 Copilot Studio에 배포할 수 있도록 시스템을 진화시킴.
테스트: 기존 프롬프트에서 모델이 작동하는지 테스트함.
실제 고객 데이터 재현: 실제 고객 대화 기록을 사용하여 새 모델이 이전 모델보다 더 잘 작동하는지 안전하게 재현(Replay)하고 품질 보고서를 받을 수 있음.
평가를 통한 모델 전환: 구축된 평가 기준을 사용하여 기존 고객에게 새 모델이 더 나은지 또는 동일한지 이해할 수 있게 됨.
기대 효과: 모델의 급속한 진화에 대비하여 기하급수적인 성장 곡선에 대비할 수 있게 되었으며, 플랫폼의 핵심 AI 역량을 개선하는 것에 가장 기대하고 있음.
13.2. 코딩 에이전트와 비즈니스 자동화
코딩 에이전트의 강력함: 코딩 에이전트가 매우 강력하다는 것을 확인했으며, Anthropic 데모에서 Claude.ai 애플리케이션을 6시간 만에 재구축한 사례를 언급함 (약 10,000줄의 코드를 생성).
비즈니스 자동화: 이러한 능력을 조달, HR 등 현재는 사람들이 하기 싫어하는 시시한 작업(menial tasks)에 적용하여 자동화할 수 있음.
궁극적 목표: 사람들이 더 의미 있는 일에 시간을 쓸 수 있도록 돕는 데 기여하는 것에 흥분하고 있음.
주요 기대 사항: 평가 기능 개선, 음성 기능 출시, 그리고 제품을 모델에 더 가깝게 만들고 모델 진화를 통해 모든 것을 강력하게 만드는 것이 최우선 목표임.
13.3. 코딩 에이전트를 오케스트레이터로 활용
코딩 에이전트의 기능: 파일 생성, 읽기, 데이터 분석, 스크립트 생성 및 실행이 가능함.
새로운 오케스트레이터 구상: 현재 코딩 에이전트를 Copilot Studio의 오케스트레이터로 배포하는 작업을 진행 중임.
작동 방식: 파일, 도구, 컨텍스트를 제공하면, 에이전트가 몇 분 또는 몇 시간 동안 복잡한 문제를 해결하도록 자동화할 수 있음.
13.4. 메이커를 위한 자동화된 모델 전환 제안
미래의 메이커 경험: 이 모든 것이 성공적으로 작동하면, 메이커가 Copilot Studio 인터페이스에 접속했을 때 팝업이 뜰 것임.
팝업 내용: "분석 및 테스트 결과에 따라 이 모델로 전환하면 정확도와 효율성이 이만큼 증가합니다."
내부 A/B 테스트: 이는 오늘날 필요한 모든 테스트 없이도 내부적인 A/B 테스트를 통해 최적의 모델을 찾아주는 것과 같음.
자가 개선 추천: 에이전트가 실패했던 지점을 되돌아보고, 자가 개선을 위한 변경 사항을 추천할 수도 있음.
14. 진행자의 역할 인식과 Baz의 플랫폼 기여에 대한 감사
14.1. 진행자의 역할 재정의
진행자의 배경: 진행자는 Copilot Studio Dude 채널을 운영하지만, 역사적으로 개발자가 아닌 기능 아키텍트(Functional Architect) 역할이었으며, Exchange 데이터베이스 IOPS 계산 등을 담당했음.
Copilot Studio의 가치: 코딩을 하지 않았음에도 Copilot Studio를 통해 멋진 결과물을 만들 수 있었음을 Baz가 증언할 수 있다고 언급함.
진행자의 가치: 진행자가 가진 가치는 "이런 기능이 필요하다"고 설명하면, 개발팀(이제는 에이전트 그룹)이 그것을 구현해주는 능력, 즉 기능 아키텍트의 능력에서 나옴.
14.2. 위임 능력의 중요성 재확인
명시적 사고의 필요성: Baz는 모든 사람이 작업 위임에 능숙해져야 한다고 재차 강조함.
프로세스 명시화: 문제를 해결할 때 자신이 무의식적으로 하던 단계를 명시적으로 생각하고 기록해야 함.
전문성 부족의 위험: 언어(예: 일본어)를 모르면 에이전트가 잘하고 있는지 판단할 수 없어 위험하며, 정확하게 조종하려면 전문 지식이 필요함.
Evals의 역할: Evals 정의와 기대치 설정이 정확한 조종을 위해 필수적임.
14.3. 후속 정보 및 마무리
감사 인사: 진행자는 Baz에게 나와서 이야기해 준 것에 대해 감사 인사를 전함.
팔로우할 곳 추천:
Copilot Studio Dude 웹사이트 (
copilotstudiodude.com).Reddit (Baz가 가끔 질문에 답하며 팀원들이 활동 중임).
커뮤니티 블로그 및 공식 웹사이트.
제품 업데이트 자동화: 제품 업데이트가 제품 내에 더 명확하게 표시되도록 노력 중이며, 에이전트 개선 프로세스 자동화도 시도 중임 (에이전트가 에이전트 구축을 돕는 방식).
플랫폼 발전 속도: 진행자는 Baz와 팀의 노고에 감사하며, 현재 기능 발전 속도가 놀랍다고 언급함.
연말 인사 및 향후 계획: 진행자는 연말 휴가를 위해 몇 주간 자리를 비울 예정이며, 1월에 매우 흥미로운 콘텐츠가 많이 나올 것이라고 예고함.
댓글
댓글 쓰기