AI 에이전트 아키텍처: 실서비스를 위한 설계와 운영 기준

AI 에이전트 아키텍처는 사안을 조사하고, 조치를 제안한 뒤, 승인을 기다리며 멈출 수 있는 단일 에이전트에서 시작합니다. 모델과 표준 인프라는 외부 서비스를 활용하고, 비즈니스 규칙과 권한 경계, 업무가 올바르게 완료됐음을 입증하는 체계는 직접 구축합니다.

고객 지원 에이전트는 고객의 메시지를 해당 계정, 적용 정책, 필요한 조치와 연결할 수 있을 때 쓸모가 생깁니다. 여기에 애플리케이션이 에이전트의 접근 내역을 설명하고, 권한 없는 변경을 막고, 툴 장애에서 복구할 수 있어야 신뢰할 수 있는 시스템이 됩니다.

이 시스템을 대중교통망에 빗대어 보면 이해하기 쉽습니다. 모델은 경로를 선택하고, 툴은 목적지에 도달하게 하며, 메모리는 이동 과정을 보존하고, 오케스트레이션은 운행을 관리합니다. 가드레일과 승인 단계는 접근을 통제합니다. 평가와 로그는 승객이 올바른 목적지에 도착했는지 알려줍니다.

아래 구성 요소 설명은 2026년 10월 25일에 Anthropic, OpenAI, Google Cloud 문서와 Model Context Protocol 명세를 기준으로 검증했습니다. 고객 지원 워크플로는 설계를 설명하기 위한 예시이며, 실제 고객사에 배포된 시스템을 소개하는 것은 아닙니다.

AI 에이전트 아키텍처에서 시스템이 책임져야 할 것

아키텍처는 모델이 선택해도 되는 일과 애플리케이션이 반드시 강제해야 하는 일을 구분합니다. 어떤 프레임워크를 쓰느냐보다 이 경계가 중요합니다.

Anthropic이 설명하는 **확장형 LLM(augmented LLM)**은 검색, 툴, 메모리를 연결한 언어 모델로, 설계의 출발점으로 삼기 좋은 구성 요소입니다. Anthropic의 가이드는 실행 경로가 코드로 정해진 워크플로와 다음 행동을 동적으로 선택하는 에이전트를 구분합니다. 또한 작업에 필요한 경우에만 복잡성을 더하라고 권합니다. Anthropic의 에이전트 가이드

고객 문의를 분류하고 처리 방향을 정할 때, 모델은 문제 해결 가이드를 검색할지 주문 내역을 확인할지 선택할 수 있습니다. 그래도 어느 고객의 기록을 읽을 수 있는지, 제안한 환불이 허용되는지, 실행이 중간에 멈추면 어떻게 처리할지는 애플리케이션 코드가 결정해야 합니다.

처리 방식이 정해진 업무는 그대로 유지합니다. 계정 인증, 이용 권한 확인, 완료된 조치 기록에 에이전트의 임기응변은 필요하지 않습니다. 메시지를 이해하고 관련 근거를 골라 유용한 다음 단계를 제안하는 일처럼, 판단이 필요한 부분을 모델에 맡깁니다.

AI 에이전트 구조도: 계층별 역할과 연결 방식

에이전트에는 실행을 통제할 수 있는 반복 구조와 이를 둘러싼 영속 상태 관리, 검증 절차가 필요합니다. 아래 계층은 각각의 책임을 나타냅니다. 계층마다 별도 서비스나 구독이 필요하다는 뜻은 아닙니다.

연결 관계를 하나의 반복 흐름으로 읽으면 됩니다. 애플리케이션이 컨텍스트를 구성하면 모델이 조치를 요청하고, 런타임이 이를 검증한 뒤 실행합니다. 그 결과는 다음 판단의 컨텍스트가 됩니다. 이 주기와 종료 조건은 에이전트 루프 가이드에서 자세히 다룹니다.

모델: 문의를 해석하고 다음 조치 제안하기

에이전트 워크플로를 구축하는 라이브러리인 OpenAI Agents SDK는 모델, 지침, 툴을 Agent로 묶습니다. 모델은 티켓을 해석하고 다음에 할 일을 제안합니다. 이 설계에서는 계정 접근 문제를 전달받으면 답변 초안을 쓰기 전에 관련 이용 권한 기록을 요청합니다. 실제 업무를 대표하는 고객 지원 사례를 평가해 모델을 선택해야 합니다. 문장이 유려하다는 이유만으로 올바른 툴을 선택했거나 조치를 수행할 권한이 있다고 볼 수는 없습니다. OpenAI의 에이전트 정의

툴과 MCP: 비즈니스 시스템에 접근하기

Model Context Protocol(MCP)은 AI 애플리케이션과 외부 기능을 연결하는 표준 인터페이스입니다. inputSchema를 갖는 이름 있는 툴과 tools/list를 통한 툴 탐색, tools/call을 통한 호출을 정의합니다. 계정 조회 기능은 MCP로 제공할 수도 있고, 비즈니스 API를 호출하는 일반 함수로 구현할 수도 있습니다. 어느 쪽이든 실제 요청을 처리하는 서비스가 인자를 검증하고 해당 계정에 대한 접근 권한을 강제해야 합니다. MCP는 연결 방식을 표준화합니다. 프로토콜과 신뢰 경계는 MCP 해설에서 다룹니다. MCP 툴 명세

메모리: 필요한 컨텍스트 보존하기

Google의 에이전트 구축 프레임워크인 Agent Development Kit(ADK)는 상호작용 내 정보를 Session과 state로 관리하고, Memory Bank 같은 구성 요소를 통해 세션 간 메모리도 지원합니다. 고객 지원에서는 현재 사안과 승인 대기 상태를 애플리케이션 저장소에 보관하고, 계정의 최신 정보는 원본 시스템에서 조회하며, 고객 선호 정보는 적절한 경우에만 유지합니다. 이들은 서로 다른 역할로 다뤄야 합니다. 컨텍스트, 세션 저장소, 장기 메모리는 에이전트 메모리 가이드에서 설명합니다. Google Cloud 아키텍처 가이드

오케스트레이션: 진행, 일시 중지, 복구 관리하기

OpenAI의 에이전트 구축 가이드는 Agents SDK가 툴 호출 루프, 핸드오프, 가드레일을 처리한다고 설명합니다. 애플리케이션은 이를 통해 모델이 이끄는 작업을 실행할 수 있습니다. 이 실행기 바깥에서는 티켓이 조사 중인지, 검토 대기 중인지, 조치 실행 중인지, 완료됐는지를 영속적으로 저장해야 합니다. 그래야 프로세스가 재시작돼도 처리를 이어갈 수 있습니다. 에이전트 실행을 더 긴 비즈니스 프로세스에 어떻게 결합하는지는 오케스트레이션 가이드에서 설명합니다. OpenAI 에이전트 가이드

가드레일과 사람의 승인: 조치가 미치는 영향 통제하기

OpenAI Agents SDK는 자동 가드레일과 승인 인터럽트를 구분합니다. 승인 인터럽트는 툴 호출을 멈추고 재개 가능한 상태를 반환합니다. 고객 지원 에이전트에서는 계정 접근과 제안된 인자를 자동으로 검증한 뒤, 민감한 변경은 권한 있는 사람이 승인해야 실행되도록 합니다. 이 통제는 실제 조치를 수행하는 툴에 붙여야 합니다. 구체적인 검증 항목은 가드레일 가이드에서 다룹니다. OpenAI의 가드레일과 사람의 검토

평가와 관측 가능성: 무슨 일이 있었고 결과가 적절했는지 확인하기

OpenAI Agents SDK의 트레이싱은 모델 호출, 툴 호출, 핸드오프, 가드레일 작동을 기록합니다. 트레이스 채점 가이드는 명시적인 기준에 따라 워크플로의 동작을 평가하는 방법을 설명합니다. 관측 가능성은 고객 지원 티켓이 어떤 과정을 거쳤는지 보여줍니다. 평가는 에이전트가 올바른 계정을 선택하고 정책을 따랐으며 근거 있는 답변을 만들었는지 확인합니다. LLM 관측 도구를 비교하기 전에 무엇을 수집하고 얼마나 보관할지부터 신중하게 정합니다. SDK 트레이싱, 에이전트 평가

Google Cloud의 참조 아키텍처는 ADK, Cloud Run, 모델 접근, MCP 연결, Model Armor, 관측 기능을 하나의 구체적인 배포 구성으로 묶습니다. 다만 문서의 예시는 다이어그램에서 메모리와 세션 저장소를 명시적으로 제외합니다. 따라서 사안의 상태를 영속적으로 보관하는 방식은 포함돼 있다고 가정할 기능이 아니라 직접 설계해야 할 부분입니다. 참조 아키텍처

문의 접수부터 해결 안내까지

에이전트에는 범위가 명확하고 완료 여부를 확인할 수 있는 사안을 맡깁니다. 이 예시에서는 고객이 이용료를 지불했는데도 서비스를 사용할 수 없다고 문의합니다. 에이전트는 원인을 조사하고 수정안을 준비할 수 있으며, 초기 도입 단계에서는 고객 지원 책임자가 계정 변경과 고객에게 보낼 답변을 승인합니다.

아래 툴 이름은 직접 구현할 애플리케이션 함수를 가리킵니다. 공급업체가 완제품으로 제공하는 고객 지원 연동 기능이 아닙니다.

1. 1

   문의를 접수하고 고객 확인하기

   고객 지원 시스템이 보내는 이벤트인 티켓 웹훅은 티켓의 외부 식별자를 기준으로 처리 건을 생성하거나 재개합니다. 고객 인증은 기존 계정 인증 흐름을 따릅니다. 메시지에 적힌 이메일 주소만으로 계정 접근을 허용해서는 안 됩니다. 수신 메시지는 신뢰할 수 없는 고객 입력으로 저장합니다.

2. 2

   기능 범위가 좁은 툴로 근거 수집하기

   에이전트에 get_account_entitlement, search_support_policy 같은 기능을 제공합니다. 애플리케이션 코드에서 계정 접근 범위를 인증된 사용자에게 묶고, 관련 기록과 정책 참조를 반환합니다. 모델은 데이터베이스에 제한 없이 접근하지 않고도 어떤 근거를 요청할지 선택할 수 있습니다.

3. 3

   근거를 갖춘 조치안 준비하기

   모델은 고객이 설명한 상황을 계정 기록 및 적용 정책과 대조합니다. 근거상 이용 권한 수정이 타당하면 변경안과 답변 초안을 작성합니다. 근거가 부족하거나 서로 모순되면 추가 설명을 요청하거나 상위 담당자에게 넘깁니다. 검토자가 판단의 근거를 확인할 수 있도록 제안과 함께 근거 자료의 참조를 저장합니다.

4. 4

   실제 업무 조치 전에 멈추기

   제안한 작업이 정책에 부합하는지 검증한 뒤, 대기 중인 조치와 승인 상태를 저장합니다. 고객 지원 책임자에게 대상 계정, 정확한 변경안, 뒷받침하는 근거, 고객에게 보낼 답변을 보여줍니다. 승인이 거절되면 쓰기 작업은 계속 차단하고, 해당 건을 수정하거나 수동으로 처리하도록 돌려보냅니다.

5. 5

   조치를 실행하고 결과 확인하기

   승인 후에는 계정과 제안 내용이 검토 당시와 여전히 일치하는지 다시 확인한 다음 수정 툴을 호출합니다. 실제 처리 서비스가 지원한다면 멱등성 키를 사용합니다. 이는 재시도할 때 같은 작업이 다시 적용되지 않도록 하는 식별자입니다. 접근 권한이 복구됐다는 답변을 보내기 전에 실제 이용 권한을 확인합니다. 답변 전송 결과까지 기록한 다음 해당 건을 완료 처리합니다.

6. 6

   처리 결과를 평가 근거로 남기기

   실행 결과, 승인된 답변, 최종 처리 상태를 트레이스와 연결합니다. 타임아웃을 성공이나 실패로 단정하지 말고, 결과가 불확실한 건은 사람에게 넘깁니다. 검토 과정에서 오류가 발견되면 민감 정보를 적절히 가린 사례를 평가 세트에 보관합니다.

특히 주의해야 할 실패는 쓰기 결과가 불분명한 경우입니다. 애플리케이션이 응답을 받지 못했더라도 계정 서비스에는 변경이 이미 적용됐을 수 있습니다. 재시도하기 전에 원본 시스템의 상태와 대조해야 합니다. 대화 기록에 “접근 권한을 복구하겠습니다”라고 적혀 있다는 것은 의도를 보여줄 뿐, 실제 권한이 바뀌었다는 증거는 아닙니다.

AI 에이전트 설계 패턴: 에이전트를 더 나눠야 하는 시점

업무가 일관된 정책, 툴 구성, 책임 주체를 공유한다면 단일 에이전트를 유지합니다. 역할을 분리해야 할 문제가 분명할 때 전문 에이전트를 추가하고, 조정 작업이 늘어난 뒤에도 개선 효과가 유지되는지 검증합니다.

OpenAI는 전문 에이전트가 대화를 넘겨받는 **핸드오프(handoffs)**와, 주 에이전트가 답변에 대한 책임을 유지한 채 전문 에이전트를 호출하는 **에이전트의 툴 활용(agents as tools)**을 구분합니다. 지침, 기능, 정책에 실질적인 차이가 있을 때 분리하는 것을 권합니다. 오케스트레이션과 핸드오프

고객 지원 사례에서 도움말 검색과 답변 초안 작성은 그 자체만으로 에이전트를 나눌 이유가 되지 않습니다. 반면 결제 분쟁은 별도 에이전트가 필요할 수 있습니다. 다른 정책, 접근이 제한된 재무 툴, 다른 검토자가 필요할 수 있기 때문입니다. 고객 지원 에이전트가 해당 건을 계속 책임지면서 전문 에이전트에게 한정된 범위의 판단을 요청할 수도 있고, 결제 워크플로가 처리를 주도해야 한다면 책임을 명시적으로 넘길 수도 있습니다.

멀티 에이전트 구조도: 책임이 달라지는 경계에서 나누기

정책의 차이는 역할 분리를 검토할 좋은 계기이지만, 모든 분리에 필요한 조건은 아닙니다. 서로 독립적인 근거 수집 업무도 작업 에이전트를 병렬로 둘 이유가 될 수 있습니다. 다만 최종 책임자가 상충하는 결과를 조정할 수 있어야 하고, 실제로 확인한 이점이 추가 모델 작업을 감수할 만해야 합니다.

전문 에이전트를 추가하기 전에 해결하려는 실패를 적어 봅니다. 잘못된 툴 선택인지, 지침 간 충돌인지, 과도한 컨텍스트인지, 전문성 부족인지 명확히 합니다. 실패 사례를 포함해 동일한 사례들로 제안한 설계를 비교합니다. 지연 시간, 사용량, 디버깅, 검토 부담이 늘어나는 것을 감수할 만큼 결과가 좋아질 때만 유지합니다. 이는 의사결정 기준이지, 성능 향상을 보장하는 공식은 아닙니다.

에이전트에 “조사자”, “비평가”, “관리자”라는 이름을 붙인다고 독립적인 판단이 생기지는 않습니다. 같은 잘못된 근거를 공유한다면 서로 동의하는 과정이 오류를 되풀이하는 데 그칠 수 있습니다. 더 넓은 분류는 AI 에이전트 유형 안내를 참고합니다.

AI 에이전트 개발: 외부 서비스를 쓸 부분과 직접 책임질 부분

대체 가능한 기반 구성 요소는 외부에서 조달하고, 업무가 지켜야 할 조건은 직접 책임집니다. 첫 실서비스용 에이전트를 만들 때 구성 요소를 직접 개발할 가장 분명한 이유는 기존 구성 요소로는 워크플로에 필요한 동작을 구현하거나 확인할 수 없기 때문입니다.

창업자라면: 실제 워크플로, 승인 경계, 근거 자료 내보내기를 지원하는 관리형 에이전트 제품을 선택합니다. 계정별 정책이나 연동 동작이 경쟁력의 핵심이라면 표준 구성 요소를 바탕으로 구축합니다. 시연이 설득력 있어도 일시 중지된 건을 복구하거나 실패한 조치를 살펴볼 수 없다면 충분하지 않습니다.

CTO와 개발자라면: 비즈니스 툴의 기능 범위를 좁게 유지하고 모델 없이도 독립적으로 테스트할 수 있게 만듭니다. 관리형 런타임은 애플리케이션을 호스팅할 수 있지만, 환불을 요청하는 고객과 환불을 처리할 권한이 있는 직원의 차이를 알아서 판단할 수는 없습니다. 실제 작업을 수행하는 서비스에서 그 차이를 정의해야 합니다.

운영 책임자라면: 예외 처리 대기열과 해결 완료의 정의를 책임집니다. 해결되지 않은 건을 누가 넘겨받는지, 어떤 근거 자료를 전달받는지, 언제 티켓을 종료할 수 있는지 정합니다. 아무도 확인하지 않는 승인함이 있다면 워크플로는 완성된 것이 아닙니다.

이 고객 지원 에이전트에 코드 실행 기능은 필수가 아닙니다. 이후 작업에서 생성된 코드를 실행해야 한다면 격리 방식을 별도로 결정하고 에이전트 코드 샌드박스 가이드를 참고합니다. 계정을 조회하기 위해 범용 셸까지 도입할 필요는 없습니다.

사람의 승인은 어디에 두고, 로그는 무엇부터 남겨야 할까요?

위임받은 권한이 필요한 조치 바로 앞에 승인 단계를 둡니다. 계정 변경이 끝난 뒤 에이전트의 문장을 검토해도 이미 일어난 변경을 막을 수는 없습니다.

OpenAI의 승인 메커니즘은 일시 중지된 실행과 재개 가능한 상태를 반환합니다. 애플리케이션은 보류 중인 결정을 처리하고 실행을 재개합니다. 같은 문서에서는 에이전트 수준의 입출력 검사가 중간에 발생하는 모든 툴 호출을 감싸지는 않는다고 경고합니다. 따라서 실제 조치가 일어나는 경계에 별도의 검증이 필요합니다. 승인 수명 주기와 워크플로 경계

이 도입 예시에서는 검토자가 정확한 계정 변경안과 답변을 함께 확인합니다. 검토 이후 조치, 수신자, 근거가 바뀌면 다시 판단을 받아야 합니다. 누가 무엇을 승인했는지, 어떤 정책이 적용됐는지, 실제 실행이 승인 내용과 일치했는지를 저장합니다.

로그의 기본 규격은 아래 항목에서 시작할 수 있습니다. **트레이스(trace)**는 한 건의 처리에서 발생한 이벤트들을 연결하고, **스팬(span)**은 그 안의 개별 작업을 기록합니다.

• 처리 건 식별 정보: 처리 건 식별자, 트레이스 식별자, 최초 이벤트, 인증된 계정 참조입니다. 고객 세부 정보를 곳곳에 복제하지 말고 참조를 사용합니다.
• 설정: 공급자가 반환한 모델 식별자, 지침 버전, 툴 스키마 버전, 정책 버전입니다. 어떤 동작 기준이 적용됐는지 설명하는 정보입니다.
• 근거: 조회한 문서 식별자, 관련 개정 버전, 접근 범위입니다. 비공개 기록을 무분별하게 복사하지 않으면서 판단을 뒷받침한 자료를 남깁니다.
• 조치: 툴 이름, 민감 정보를 가린 인자, 타임스탬프, 소요 시간, 결과 상태, 재시도 또는 멱등성 식별자입니다. 제안한 조치와 완료된 조치를 구분할 수 있을 만큼의 정보를 보존합니다.
• 결정: 검증 결과, 상위 담당자에게 넘긴 이유, 승인 상태, 검토자 참조, 승인된 제안입니다.
• 결과와 사용량: 최종 티켓 상태, 확인된 시스템 변경 등 부수 효과, 전달 결과, 공급자가 보고한 사용량, 평가 레이블입니다. 고객 지원 시스템에서 제공한다면 고객의 정정 요청이나 재개된 처리 건도 추적합니다.

이는 권장 애플리케이션 스키마이며, SDK가 모든 필드를 자동으로 수집한다는 뜻은 아닙니다. 접근을 제한하고 보관 기간을 정하며, 내보내기 전에 비밀 정보를 가립니다. 모델 내부의 숨겨진 추론을 필수 로그로 요구하지 않습니다. 관찰 가능한 입력, 출력, 조치, 근거만으로 감사 추적이 가능해야 합니다.

실제로 중요한 한계와 과장된 기대

가장 중요한 한계는 에이전트에 위임하는 권한입니다. 실행 시간, 툴 사용, 자원 사용에 명확한 상한을 두고, 사람에게 넘기는 경로도 분명하게 정합니다. 한도 값은 데모의 임의 설정을 가져오지 말고 실제 워크로드와 서비스 요구사항에 맞춰 선택합니다.

메모리는 최종 판단의 기준이 되는 원본 데이터가 아닙니다. 저장된 대화에는 고객이 이용 권한을 갖고 있다고 나오는데 계정 시스템의 정보는 다르다면, 현재의 공식 기록을 기준으로 불일치 원인을 조사합니다. 기억하는 텍스트가 늘어난다고 오래된 근거가 바로잡히지는 않습니다.

MCP 연결 자체가 권한 부여를 뜻하지는 않습니다. MCP 툴 명세에서도 접근 통제와 입력 검증을 요구합니다. 넓은 범위의 작업을 제공하는 커넥터에는 직접 만든 API와 똑같이 업무상 권한 검토가 필요합니다. MCP 보안 요구사항

실행이 끝났다고 문의가 성공적으로 해결된 것은 아닙니다. 올바른 계정이 변경됐는지, 정책을 따랐는지, 답변이 실제 결과와 일치하는지 평가합니다. OpenAI의 평가 가이드는 트레이스 검토에서 출발해 반복 평가가 가능한 데이터셋으로 확장하는 방식을 제시합니다. 그래야 변경 사항을 일관된 기준으로 판단할 수 있습니다. 에이전트 워크플로 평가

에이전트가 여러 개여도 책임 주체는 필요합니다. 최종 답변, 공유 근거, 해결되지 않은 예외에는 책임자가 있어야 합니다. 전문 에이전트의 가치는 맡는 책임이 다르다는 데 있습니다. 아키텍처 다이어그램을 더 정교해 보이게 하는 데 있지 않습니다.

에이전트 아키텍처에 관한 자주 묻는 질문

AI 에이전트 아키텍처란 무엇인가요?

AI 에이전트 아키텍처는 애플리케이션이 작업을 수행할 수 있도록 모델의 판단, 툴, 메모리, 오케스트레이션, 통제, 평가를 배치하고 연결한 구조입니다. 업무용 에이전트에서는 누가 조치를 승인할 수 있는지, 완료 여부를 어떻게 검증할지도 아키텍처가 정합니다.

AI 에이전트는 어떤 개념인가요?

AI 에이전트(AI agent)는 모델을 이용해 목표를 향한 행동을 선택하고, 결과를 관찰한 뒤, 다음에 어떻게 진행할지 결정합니다. 실제로 활용할 수 있는 자율성의 범위는 애플리케이션이 제공하는 툴, 권한, 종료 규칙으로 제한됩니다.

에이전트 아키텍처에는 어떤 유형이 있나요?

실무에서는 미리 정의된 워크플로, 여러 툴 중 사용할 툴을 선택하는 단일 에이전트, 서로 협업하는 전문 에이전트로 구분할 수 있습니다. 업무를 얼마나 예측할 수 있는지, 책임이 다른 영역에 별도의 툴·정책·책임자가 필요한지에 따라 적합한 방식이 달라집니다. 이는 구현 패턴을 나눈 것이며, 모든 에이전트에 적용되는 보편적 분류는 아닙니다.

다음 업무일에 할 일: 기술 스택보다 처리 흐름부터 그리기

반복적으로 들어오는 고객 문의가 있고, 원본 기록에 접근할 수 있으며, 예외를 책임질 담당자가 있다면 지금 시작할 수 있습니다. 대표 사례를 골라 수신 이벤트, 허용된 조회, 제안할 쓰기 작업, 승인 지점, 종료에 필요한 근거를 표시합니다. 처음에는 초안을 작성하고 검토받는 방식으로 워크플로를 운영합니다. 이후 실제로 관찰한 실패를 바탕으로 어느 권한까지 책임 있게 확대할 수 있을지 판단합니다.

계정의 신원 확인, 정책의 책임 주체, 완료를 입증할 근거가 정리되지 않았다면 자율 실행은 미룹니다. 그 기반을 갖추는 동안에도 검색과 초안의 품질은 개선할 수 있습니다. 워크플로가 이미 신뢰할 수 있는 결정적 규칙으로 작동하고 모델의 판단이 필요하지 않다면 기존 자동화를 유지합니다.

첫 결과물은 접수부터 최종 결과까지 설명할 수 있는 처리 사례여야 합니다. 승인이 거절되거나 툴의 실행 결과를 알 수 없을 때 어떻게 되는지도 포함해야 합니다.

AI 시스템 구축과 운영에 관한 실무 가이드를 받아보려면 뉴스레터를 구독하세요.