KT의 AI 관련 직무를 준비하는 취업 준비생의 프로젝트를 함께 점검하다 보면 생성형 AI 서비스를 만들어본 경험은 있는데, 그 서비스가 실제 기업 환경에서 어떤 인프라와 데이터를 사용하고 어떻게 운영되는지까지 설명하는 단계에서는 답변이 짧아지는 경우가 있습니다. LLM API를 연결해 챗봇을 만들었고 RAG 프로젝트도 진행했지만, 모델이 어느 환경에서 서빙되는지, 서비스 사용량이 늘어나면 어떤 자원을 확인해야 하는지, 에이전트가 어떤 데이터와 업무 시스템을 사용할 수 있는지를 질문하면 각각 별개의 기술처럼 받아들이는 식입니다. 반대로 클라우드와 데이터 관련 기술을 공부한 취업 준비생 중에도 비슷한 문제가 나타납니다. Azure와 AWS에서 서버를 배포하고 SQL과 데이터 파이프라인도 경험했지만, AI 서비스가 확대될 때 기존 클라우드 운영과 무엇이 달라지는지, 데이터 품질과 권한이 왜 더 중요해지는지, 에이전트가 실제 업무까지 수행한다면 어떤 시스템 연계가 필요한지를 설명하지 못하는 경우입니다. KT가 2026년 공개한 기술 방향을 보면 이 세 영역은 실제로 서로 분리되어 있지 않습니다. KT의 클라우드 AI 플랫폼 ASTRA는 Microsoft Azure 기반의 통합 플랫폼으로, 모델 서빙과 Agent 운영, Observability를 하나의 기반에서 제공하고 있으며 마이 K AI 에이전트와 사장이지 AI 에이전트 같은 서비스도 지원하고 있습니다. KT는 이 플랫폼에서 Azure 리소스와 LLM 서빙, Agent 오픈 지원, 보안조치, 운영 자동화까지 함께 다루고 있습니다. 기업용 AI 방향에서도 비슷한 흐름이 나타납니다. KT는 2026년 Agentic Fabric을 공개하며 여러 AI 기술과 에이전트를 연결해 기업 업무 전반을 수행하는 구조를 제시했고, 실제 통신·재무·구매·영업 등 업무 적용 사례를 공개했습니다. 또한 2026년 9월 AI agent 플랫폼 개발 경력채용에서는 LLM 기반 에이전트 런타임, 외부 도구와 업무 시스템 연계, 멀티에이전트 구조, 모델 서빙과 모니터링, 성능 평가까지 하나의 직무 영역으로 제시했습니다. 이 흐름에서 취업 준비생이 볼 핵심은 AI 개발자 채용만 늘어난다는 의미가 아닙니다. 클라우드에서는 AI 서비스를 안정적으로 실행하고 운영하는 역할, 데이터에서는 에이전트가 사용할 정보를 신뢰할 수 있게 만드는 역할, 에이전트에서는 모델과 도구, 업무 시스템을 실제 실행 흐름으로 연결하는 역할이 서로 가까워지고 있다는 점이 중요합니다.
이번 글에서는 KT의 AI 서비스 확대에서 주목해야 할 IT 직무를 클라우드, 데이터, 에이전트 세 가지 기준으로 나누어 정리하겠습니다.
클라우드는 AI 모델과 에이전트를 실제 서비스로 운영하기 위한 기반입니다
- AI 서비스가 늘어날수록 서버를 만드는 것보다 운영 가능한 플랫폼을 구성하는 경험이 중요해집니다
AI 서비스를 공부할 때는 API를 호출해 답변을 받거나 모델을 서버에 올리는 단계까지 경험하는 경우가 많습니다. 하지만 실제 서비스가 여러 개로 늘어나면 각각의 모델과 에이전트를 따로 운영하기보다 공통 인프라와 인증, 로그, 모니터링 체계를 함께 관리할 필요가 생깁니다.
클라우드 직무에서는 다음 내용을 연결해서 볼 수 있습니다.
- AI 서비스가 어떤 컴퓨팅 자원을 사용하는지 구분합니다.
- 모델 서빙과 일반 애플리케이션 서버의 역할 차이를 이해합니다.
- API와 인증정보를 안전하게 관리하는 구조를 확인합니다.
- 여러 서비스의 로그와 지표를 공통 기준으로 수집합니다.
- 사용량 증가에 따라 자원과 비용이 어떻게 변하는지 살펴봅니다.
- 장애 발생 시 어느 서비스와 리소스가 영향을 받았는지 추적합니다.
KT의 ASTRA 사례에서도 Azure 기반 공통 리소스와 AKS, APIM, Key Vault, LLM 서빙, Observability 등을 하나의 AI 플랫폼에서 운영하고 있습니다. 즉 AI 서비스가 늘어날수록 단일 서버를 만드는 능력보다 여러 서비스가 공통으로 사용할 수 있는 플랫폼을 구성하고 운영하는 역량이 중요해질 수 있습니다.
- 일반 클라우드 운영과 AI 클라우드 운영은 관찰해야 하는 대상에서 차이가 생깁니다
기존 웹서비스 운영에서도 CPU와 메모리, 네트워크와 장애 로그를 확인합니다. AI 서비스에서는 여기에 모델 호출과 토큰 사용량, 추론 지연시간, Agent 실행 상태와 같은 새로운 지표가 추가될 수 있습니다.
- 일반 애플리케이션 운영: 서버 자원과 응답시간, 오류율을 중심으로 상태를 확인합니다.
- 모델 서빙 운영: 모델 로딩과 추론 응답시간, 처리량, 자원 사용률을 함께 확인합니다.
- 에이전트 운영: 하나의 요청이 여러 도구와 모델을 거쳐 실행되는 과정을 추적합니다.
- 비용 운영: 모델과 클라우드 자원 사용량이 서비스 비용에 어떤 영향을 주는지 살펴봅니다.
- Observability 운영: 요청이 어느 단계에서 실패했는지 로그와 트레이스를 통해 확인합니다.
KT의 2026년 AI agent 플랫폼 개발 채용에서도 처리량과 응답 지연, 자원 사용률 기반 모니터링과 LLM 모델 서빙, 고가용성 운영을 함께 요구했습니다. 이는 AI 플랫폼 직무가 단순 인프라 운영을 넘어 모델과 에이전트의 실행 상태까지 관찰하는 역할로 확장되고 있음을 보여주는 사례입니다.
- AI 플랫폼 프로젝트에서는 운영 자동화 경험도 함께 연결할 수 있습니다
AI 서비스 수가 증가하면 운영자가 반복적으로 확인해야 하는 리소스와 인증서, 비용, 변경 이력도 많아질 수 있습니다. 이런 영역을 수작업으로 관리하면 서비스가 늘어날수록 운영 부담도 커질 수 있습니다.
프로젝트에서는 다음 경험을 만들 수 있습니다.
- 주요 클라우드 리소스 상태를 주기적으로 조회합니다.
- 인증서와 비밀정보의 만료 상태를 확인합니다.
- 사용하지 않는 자원과 과도하게 할당된 자원을 구분합니다.
- 변경 이력을 저장하고 장애 시점과 연결합니다.
- 특정 상태가 발생하면 알림을 전달합니다.
- 자동화가 실제 리소스를 임의로 변경하지 않도록 권한을 제한합니다.
KT의 ASTRA 운영팀은 2026년 실제 운영 사례에서 인증서 만료, 저사용 자원, 미사용 자원, 리소스 의존성, 변경 이력을 자동으로 탐지하는 공통 파이프라인을 구축했습니다. 또한 자동화 도구가 운영 환경을 직접 변경하지 않도록 읽기 전용 구조와 허용 목록을 적용했습니다. 이런 경험이 있으면 클라우드 포트폴리오도 서버 배포에서 끝나지 않고 운영 위험을 발견하고 자동화하되 안전하게 통제한 경험으로 발전합니다.
- 클라우드 직무 준비는 특정 CSP 사용법보다 AI 서비스 전체 흐름을 이해하는 방향으로 확장할 수 있습니다
KT 사례에서 Azure가 중요한 기반으로 사용되고 있지만 취업 준비 단계에서 특정 서비스 이름을 모두 외우는 것이 가장 중요한 것은 아닙니다. 다른 CSP를 사용하더라도 컴퓨팅과 네트워크, 인증, 배포, 로그와 모니터링의 기본 구조는 연결해서 이해할 수 있습니다.
- 인프라 기본 단계: Linux와 네트워크, 컨테이너가 어떤 역할을 하는지 이해합니다.
- 클라우드 단계: 컴퓨팅과 스토리지, IAM, 가상 네트워크를 구성합니다.
- AI 플랫폼 단계: 모델 서빙과 API, 에이전트가 필요한 공통 자원을 연결합니다.
- 운영 단계: 로그와 메트릭, 비용과 장애를 관찰합니다.
- 자동화 단계: 반복적인 점검과 배포, 상태 확인을 코드와 파이프라인으로 관리합니다.
이렇게 준비하면 KT의 AI 서비스 확대를 단순히 Azure 인력 수요 증가로 해석할 필요가 없습니다. 클라우드 인프라 위에서 AI 모델과 에이전트를 안정적으로 실행하고 관찰할 수 있는 플랫폼 운영 역량이 중요해지는 변화로 보는 편이 더 적절합니다.
데이터는 AI가 실제 업무를 수행하기 위해 신뢰할 수 있는 정보를 제공하는 영역입니다
- 에이전트가 실제 업무를 수행할수록 데이터 품질과 구조의 중요성도 커집니다
AI 서비스가 단순 질의응답에서 실제 업무 수행으로 확장되면 모델이 사용하는 데이터도 달라질 수 있습니다. 문서뿐 아니라 고객 데이터와 서비스 이력, 운영정보, 상품 기준과 여러 업무 시스템의 데이터까지 연결될 수 있기 때문입니다.
데이터 직무에서는 다음 내용을 함께 볼 수 있습니다.
- AI가 사용할 데이터의 출처를 구분합니다.
- 최신 데이터와 오래된 데이터를 구분합니다.
- 같은 의미가 여러 형태로 저장되어 있는지 확인합니다.
- 데이터가 어느 업무 시스템에서 생성되었는지 추적합니다.
- AI가 사용할 수 있는 데이터 범위를 권한에 따라 구분합니다.
- 잘못된 데이터가 에이전트 실행 결과에 어떤 영향을 주는지 검증합니다.
예를 들어 소상공인 서비스 에이전트가 매출과 상권 데이터를 이용해 분석 결과를 제시한다고 가정할 수 있습니다. 데이터가 최신인지와 동일한 사업장이 여러 ID로 중복되어 있지 않은지, 사용자가 접근할 수 없는 정보가 포함되어 있지 않은지를 확인하지 않으면 모델 성능과 별개로 서비스 결과가 흔들릴 수 있습니다. KT는 2026년 데이터 거버넌스 관련 기술 공유에서 기존의 표준과 메타데이터, 플랫폼 기반 거버넌스를 AI Readiness 관점으로 확장해 가는 방향을 설명했습니다.
- 기존 데이터 분석과 AI 서비스용 데이터는 최종 사용 방식에서 차이가 있습니다
데이터 분석은 사람이 결과를 보고 판단하는 경우가 많습니다. 에이전트 시스템에서는 데이터가 모델의 판단과 다음 작업의 입력으로 바로 사용될 수 있기 때문에 오류가 다른 단계로 이어질 가능성도 고려해야 합니다.
- 분석용 데이터: 사용자가 지표와 그래프를 확인하고 최종 판단을 내립니다.
- 검색용 데이터: 에이전트가 질문과 관련된 문서나 정보를 찾아야 합니다.
- 실행용 데이터: 일정 변경이나 업무 처리처럼 다음 행동을 결정하는 입력으로 사용됩니다.
- 평가용 데이터: 모델과 에이전트가 올바르게 동작하는지 테스트하는 기준이 됩니다.
- 운영용 데이터: 실행 로그와 사용량, 오류 이력을 분석해 서비스 상태를 확인합니다.
KT 기술 조직에서도 정형 데이터와 웹 정보를 함께 사용하는 멀티소스 RAG 에이전트, 학습데이터 품질 검증 자동화, Agent 품질평가 같은 프로젝트가 공개되고 있습니다. 이는 AI 서비스가 확대될수록 데이터 역할이 단순 분석을 넘어 검색·실행·평가·운영의 기반으로 넓어질 수 있음을 보여줍니다.
- 데이터 프로젝트에는 수집보다 데이터가 실제 AI 결과에 어떻게 연결되는지가 보여야 합니다
AI 직무 포트폴리오에서 데이터를 많이 수집했다는 사실만 강조하면 실제 서비스와의 연결이 약할 수 있습니다. 어떤 데이터가 모델이나 에이전트의 어느 판단에 사용되었는지를 추적할 수 있는 구조가 중요합니다.
프로젝트에서는 다음 내용을 확인할 수 있습니다.
- 원본 데이터와 가공 데이터의 관계를 기록합니다.
- 데이터가 생성된 시점과 갱신 주기를 남깁니다.
- 결측과 중복, 비정상 값을 검증합니다.
- AI 입력에 사용된 데이터의 출처를 추적할 수 있게 합니다.
- 새로운 데이터가 추가되었을 때 같은 검증 기준을 적용합니다.
- 잘못된 데이터가 발견되면 AI 결과를 다시 확인합니다.
예를 들어 고객 추천 에이전트가 잘못된 상품을 추천했다면 LLM만 수정할 필요는 없습니다. 고객 데이터가 잘못 매핑되었는지와 최신 상품 정책이 반영되어 있는지, 검색 데이터가 오래된 것은 아닌지부터 확인해야 할 수 있습니다. 이런 과정을 경험하면 데이터 프로젝트가 ETL이나 SQL 중심에서 끝나지 않고 AI 결과의 신뢰성을 만드는 데이터 엔지니어링 경험으로 연결됩니다.
- AI 시대의 데이터 직무는 거버넌스와 품질, 평가까지 함께 볼 필요가 있습니다
기업 AI에서는 데이터가 많다는 사실만으로 충분하지 않습니다. 어떤 데이터가 신뢰할 수 있고 누가 사용할 수 있으며, 모델과 에이전트의 결과를 평가할 기준 데이터가 준비되어 있는지도 중요합니다.
- 데이터 거버넌스 관점: 데이터 정의와 소유자, 사용 범위를 명확하게 관리합니다.
- 데이터 품질 관점: 누락과 중복, 오류와 최신성을 일정한 기준으로 확인합니다.
- AI Readiness 관점: AI가 실제로 사용할 수 있도록 데이터 구조와 메타데이터를 준비합니다.
- 평가 데이터 관점: 모델과 에이전트의 결과를 검증할 테스트 셋과 기준을 구성합니다.
- 운영 데이터 관점: 서비스 실행 로그와 품질 변화를 지속적으로 분석합니다.
KT의 2026년 AI Quality Engineering 채용에서도 테스트 셋과 품질 기준을 관리하고 모델·Agent 서비스의 기능과 성능, 안정성을 평가하는 업무가 제시되었습니다. 데이터 관련 준비 역시 AI 모델 학습 데이터에서 끝나지 않고 서비스 품질을 측정하고 개선하는 데이터까지 확장해 볼 수 있습니다.
에이전트는 모델과 데이터, 업무 시스템을 연결해 실제 실행 흐름을 만드는 영역입니다
- AI 에이전트 프로젝트에서는 챗봇보다 어떤 작업을 실제로 수행하는지를 보여주는 것이 중요합니다
LLM 기반 프로젝트를 시작하면 질문을 입력하고 답변을 받는 챗봇부터 만드는 경우가 많습니다. 에이전트는 여기서 한 단계 더 나아가 사용자의 요청을 해석하고 필요한 도구와 데이터를 선택해 여러 단계의 작업을 수행하는 방향으로 확장될 수 있습니다.
에이전트 프로젝트에서는 다음 내용을 연결해서 볼 수 있습니다.
- 사용자의 요청을 어떤 작업 단계로 나누는지 정의합니다.
- 어떤 조건에서 외부 도구를 호출할지 구분합니다.
- 필요한 데이터와 API를 어느 단계에서 사용하는지 설계합니다.
- 여러 에이전트가 역할을 나누는 경우 협업 구조를 정합니다.
- 실패한 작업을 다시 시도하거나 중단하는 기준을 설정합니다.
- 중요한 실행에는 사람의 확인을 포함할 수 있습니다.
KT가 2026년 공개한 Agentic Fabric은 여러 AI 기술과 에이전트를 연결해 기업의 핵심 업무를 수행하는 구조를 목표로 하고 있습니다. 또한 KT의 Agent Orchestrator 연구에서는 멀티턴 대화와 태스크 분해, 동적 라우팅, 계층적 상태 등을 실제 프로덕션 문제로 다뤘습니다. 따라서 취업 포트폴리오에서도 에이전트 개수를 늘리는 것보다 어떤 업무를 어떤 판단과 실행 흐름으로 해결하는지가 더 중요합니다.
- 단일 LLM 서비스와 AI 에이전트 서비스는 시스템 연결 범위에서 차이가 있습니다
LLM을 이용한 서비스와 에이전트 서비스는 모델을 사용한다는 점에서는 비슷해 보입니다. 하지만 실제 실행 구조에서는 차이가 생길 수 있습니다.
- LLM 응답 중심: 입력된 질문을 모델이 해석하고 텍스트 답변을 생성합니다.
- RAG 중심: 외부 문서를 검색한 뒤 관련 정보를 기반으로 답변을 생성합니다.
- 도구 활용 Agent: API와 데이터베이스, 검색 시스템 등을 상황에 따라 호출합니다.
- 워크플로 Agent: 여러 단계의 업무를 순서대로 실행하고 중간 상태를 관리합니다.
- 멀티 Agent: 서로 다른 역할을 가진 에이전트가 하나의 목표를 나누어 처리합니다.
KT의 2026년 AI agent 플랫폼 개발 공고에도 외부 도구 및 업무 시스템 연계, 멀티 agent 구조, 업무 자동화 워크플로우, 이력 추적, 모델 서빙과 평가가 하나의 직무 안에 포함되어 있습니다. 이런 구조를 보면 에이전트 개발 역량은 프롬프트 작성 하나로 설명하기 어렵습니다. API와 데이터, 상태 관리, 백엔드 개발, 클라우드 운영을 함께 이해하는 시스템 개발 역량과 연결될 가능성이 높습니다.
- 에이전트 프로젝트에는 성공 결과뿐 아니라 실패와 평가 과정도 남아 있어야 합니다
에이전트는 여러 단계와 도구를 거치기 때문에 최종 답변 하나만 보고 정상 여부를 판단하기 어려울 수 있습니다. 어떤 단계에서 잘못된 도구를 선택했는지와 필요한 데이터가 부족했는지, 모델 판단이 틀렸는지를 구분해야 개선할 수 있습니다.
프로젝트에서는 다음 내용을 기록할 수 있습니다.
- 사용자의 의도를 잘못 분류한 사례를 구분합니다.
- 잘못된 도구를 호출한 실행을 확인합니다.
- 도구 호출 결과가 비정상일 때 처리 방식을 기록합니다.
- 멀티에이전트 환경에서 잘못된 라우팅 사례를 분석합니다.
- 동일한 테스트 셋으로 변경 전후 결과를 비교합니다.
- 응답시간과 비용, 성공률을 함께 살펴봅니다.
KT의 Agentic AI 관련 기술 조직도 에이전트 평가를 단순 정답 일치가 아니라 다단계 상호작용과 지시 이행, 판단의 적절성까지 검토해야 하는 문제로 다루고 있습니다. 또한 AI Quality Engineering 직무에서는 Agent 기반 서비스의 테스트와 품질 기준, 자동화된 반복 검증을 핵심 업무로 제시했습니다. 이런 경험이 있으면 에이전트 포트폴리오가 데모 화면에서 벗어나 실패 원인을 찾고 품질을 개선한 시스템 프로젝트로 발전합니다.
- KT의 AI 서비스 확대는 에이전트 개발자만이 아니라 여러 IT 직무의 접점을 넓히는 변화로 볼 수 있습니다
AI 에이전트가 실제 기업 서비스로 확장되면 모델 연구자 한 명의 역할만으로 완성되기 어렵습니다. 모델과 데이터, 클라우드, 애플리케이션, 보안과 품질이 함께 연결되어야 하기 때문입니다.
- 클라우드 엔지니어: 모델과 Agent 서비스를 실행할 인프라와 배포, 관측 환경을 운영합니다.
- 데이터 엔지니어: Agent가 사용할 데이터와 검색, 파이프라인을 구축하고 품질을 관리합니다.
- AI Agent 엔지니어: LLM과 도구, API, 업무 시스템을 연결해 실행 흐름을 설계합니다.
- AI Quality 엔지니어: 모델과 Agent의 기능과 성능, 안정성을 평가하고 품질 기준을 관리합니다.
- 백엔드·플랫폼 엔지니어: 실제 업무 시스템과 Agent 사이의 인터페이스와 운영 기능을 개발합니다.
2026년 10월 10일 기준 KT는 AI agent 플랫폼 개발 채용을 진행하고 있으며, 올해 별도로 AI Agent Engineer와 AI Platform Engineer, AI Quality Engineer 채용도 운영했습니다. 채용 명칭 자체를 전체 신입시장으로 일반화할 수는 없지만 KT가 AI 서비스를 모델 개발 하나가 아니라 플랫폼·Agent·품질까지 세분화된 엔지니어링 영역으로 다루고 있다는 점은 확인할 수 있습니다. 따라서 KT AI 직무를 준비할 때 특정 직무명 하나만 쫓기보다 자신의 기존 IT 기반이 클라우드와 데이터, 에이전트 시스템 가운데 어디에서 가장 강하게 연결되는지를 먼저 구분하는 것이 좋습니다.
- conclusion
KT의 AI 서비스 확대를 취업 준비 관점에서 보면 AI 모델 개발자 채용이 늘어난다는 한 문장으로 정리하기 어렵습니다. 2026년 KT가 공개한 기술 사례를 보면 AI 서비스의 공통 기반이 되는 Azure 기반 클라우드 AI 플랫폼과 데이터 거버넌스, Agentic Fabric과 멀티에이전트, 품질평가와 운영 자동화가 서로 연결되고 있습니다. 클라우드에서는 AI 모델과 에이전트를 실제 서비스 환경에서 안정적으로 실행할 수 있어야 합니다. 컨테이너와 API, 인증과 네트워크뿐 아니라 모델 서빙과 Observability, 자원 사용량과 비용, 장애 대응까지 함께 보는 준비가 필요해질 수 있습니다. 데이터에서는 AI가 사용할 정보를 신뢰할 수 있게 만드는 역할이 중요합니다. 데이터를 많이 확보하는 것보다 출처와 최신성, 품질과 권한을 관리하고 AI 결과가 잘못되었을 때 어느 데이터에서 문제가 시작되었는지 추적할 수 있어야 합니다. 에이전트에서는 모델의 답변을 만드는 데서 끝나지 않고 API와 데이터, 업무 시스템을 연결해 실제 작업 흐름을 구성해야 합니다. 여러 단계가 연결될수록 상태 관리와 실패 처리, 품질평가와 모니터링도 함께 중요해집니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 클라우드 환경에서 AI 서비스를 배포하고 운영한 경험이 있는지 확인합니다.
- 모델 서빙과 일반 애플리케이션 운영의 차이를 설명할 수 있는지 살펴봅니다.
- AI가 사용하는 데이터의 출처와 품질을 추적할 수 있는지 확인합니다.
- 데이터 접근권한과 최신성을 관리하는 기준이 있는지 점검합니다.
- LLM과 외부 API, 업무 시스템을 연결한 경험이 있는지 살펴봅니다.
- Agent의 실행 결과를 로그와 테스트 셋으로 평가한 경험이 있는지 확인합니다.
KT AI 관련 직무 준비 흐름은 다음과 같이 연결할 수 있습니다.
- Python과 Linux 기초 → API와 데이터 처리 → 클라우드 컴퓨팅과 네트워크 → Docker와 배포 → SQL과 데이터 파이프라인 → 데이터 품질과 거버넌스 → LLM API 활용 → RAG와 검색 → Tool Calling → Agent 워크플로우 → 클라우드 모델 서빙 → 로그와 Observability → Agent 평가와 실패 분석 → 운영 자동화 → 프로젝트 문서화 → 포트폴리오와 면접 연결
결국 KT의 AI 서비스 확대에서 주목할 부분은 새로운 AI 직무명이 몇 개 생겼는지가 아닙니다. 클라우드에서는 AI 서비스를 안정적으로 실행하고, 데이터에서는 AI가 사용할 정보를 신뢰할 수 있게 만들며, 에이전트에서는 모델과 도구를 실제 업무 실행으로 연결하는 역량이 하나의 시스템 안에서 가까워지고 있다는 점이 핵심입니다. 자신의 기존 직무 기반 위에서 이 세 영역 가운데 하나를 깊게 준비하고 나머지 영역과의 연결 구조까지 이해한다면 KT뿐 아니라 AI 서비스를 실제 사업과 업무에 적용하는 기업의 직무 변화를 포트폴리오와 면접에서도 더 구체적으로 설명할 수 있습니다.