AI 문서 검토 자동화, 정말 노코드로 가능할까? - 프로토타입 검증기
안녕하세요, IT Dev본부 김혜원입니다! 오늘은 대규모 마이그레이션 프로젝트에서 겪었던 반복적인 문서 검토 업무를 AI와 Power Automate를 이용해 ‘노코드(No-Code)’로 자동화한 경험을 공유해 드리고자 합니다. 개발자가 아니더라도 충분히 구현 가능한 AI 기반 업무 효율화, 그 생생한 후기를 지금부터 시작합니다. 1. 들어가며: 동료들의

안녕하세요, IT Dev본부 김혜원입니다! 오늘은 대규모 마이그레이션 프로젝트에서 겪었던 반복적인 문서 검토 업무를 AI와 Power Automate를 이용해 ‘노코드(No-Code)’로 자동화한 경험을 공유해 드리고자 합니다. 개발자가 아니더라도 충분히 구현 가능한 AI 기반 업무 효율화, 그 생생한 후기를 지금부터 시작합니다. 1. 들어가며: 동료들의

Azure Confidential Computing과 Managed HSM을 통한 클라우드 주권 확보 전략 클라우드 환경에서 데이터는 물리적 경계를 넘어 저장되고 처리되며, 이는 데이터 주권(Digital Sovereignty)과 보안 통제에 대한 새로운 도전 과제를 야기합니다. 특히 정부 기관과 규제가 엄격한 산업군에서는 데이터의 위치, 접근 권한, 암호

2025년 4월 중순, KT가 ‘N사 차세대 컨택센터 구축’ 사업에 참여 한다고 전달 받았다. 우리 기술은 기존 AICC 사업에서 좋은 성과를 보였기 때문에 해볼만한 사업이라고 판단됐지만 두 가지의 문제가 있었다. 첫째, 고성능의 화자분리(Speaker Diarization)기술 필요했으며 둘째, BMT 까지 우리에겐 주어진 시간은 단 한 달 이었다. 사업

시큐어 퍼블릭 클라우드(Secure Public Cloud)란? 시큐어 퍼블릭 클라우드를 처음 들어보신 분들은 아래 Tech 아티클을 먼저 읽어주세요. 시큐어 퍼블릭 클라우드 설계/구축 및 서비스 오픈 시큐어 퍼블릭 클라우드 공통/ 산업 특화 Policy 시큐어 퍼블릭 클라우드가 일반 랜딩존과 다른 점은 크게 두 가지, Policy와 기밀컴퓨팅(Confid

KT Azure Migration 프로젝트 이해하기 안녕하세요, KT On-Premise 서비스를 Azure Public Cloud로 Migration 하는 과정에서 경험했던 Lessons Learned를 공유하고자 합니다. 먼저 KT가 진행하고 있는 Azure Migration 프로젝트에 대해 간략한 소개와 Rehost or Replatform 방식의 M

안녕하세요. KT의 AI Futuer Lab의 심성보 입니다. AI 기술은 매일 새로운 가능서을 열어주지만, 그만큼 빠르게 따라잡아야 할 과제도 많아졌습니다. 편해졌지만 그 만큼의 숙제도 받은 느낌이랄까요? 연구 개발도 많은데 기술을 확보하고, 검증하고, 실제 서비스에 적용하기까지… 이 모든 걸 내부 자원만으로 해내기엔 시간도, 인프라도 부족한 게 현실이죠

안녕하세요. Cloud AX Assurance 업무를 맡고 있는 김도현입니다. KT가 ‘AICT 컴퍼니(Company)’로써 본격적으로 나아가기 위해 작년에 마이크로소프트와 전략적 파트너십을 체결했습니다. 이 협약과 더불어 MS Azure를 사용하여 다양한 사내 서비스들을 Azure 환경으로 전환하는 Azure Migration Factory 프로젝트도 작

안녕하세요, KT AX교육프로그램(클테코3기) “클테코 마마” IT Dev본부 정치훈 입니다. 빠르게 변화하는 클라우드 시대, KT는 내부 개발문화 혁신과 기술 내재화를 목표로 클라우드 네이티브 전문가 양성 프로그램, 클테코(KT Cloud Native Tech Course)를 2024년부터 운영해오고 있습니다. 그리고 2025년 이제, 한층 더 업그레이드

0. Azure 랜딩존으로 구축하는 엔터프라이즈급 하이브리드 클라우드 데이터센터 기업이 디지털 전환을 가속화하면서, 온-프레미스 환경의 장점과 클라우드의 확장성을 모두 활용할 수 있는 하이브리드 클라우드 환경에 대한 수요가 급증하고 있습니다. 특히 보안 및 규정 준수 요구사항을 충족하면서도 빠른 혁신을 추진해야 하는 기업들에게 Azure 랜딩존은 최적의 해

서비스가 성장하면 반드시 마주치는 숙제가 있습니다. 바로 도메인 구조의 복잡성입니다. 처음엔 example.com 하나만 잘 관리하면 됐습니다. 하지만 시간이 지나면서 서비스가 분화되고 사용자 그룹이 나뉘다 보면 api.example.com, admin.example.com, user.example.com처럼 기능별 하위 도메인이 생겨나기 시작하죠. 문제는
