AI Agent 는 어디까지 발전해왔을까?AI Agent 는 대규모 언어 모델 (LLM: Large Language Model) 을 기반으로 환경을 인지, 분석하고 자율적으로 도구 (Tool) 를 활용하여 목표를 달성하는 지능형 시스템입니다.2022년~2023년 초기의 에이전트 시스템이 단일 작업 처리에 집중했다면,현재는 Multi-Tool Orchestration 과 맥락 기반 의사결정 (Context-Aware Decision Making) 기능을 중심으로 발전하고 있습니다.AI Agent 의 핵심 기술 중 하나인 Tool Calling 은 언어 모델이 외부 도구, API 또는 기타 리소스를 활용하여 정보를 얻거나 작업을 수행할 수 있도록 해주는 혁신적인 기능입니다.위의 그림은 Tool Calling 프로세스를 표현한 것입니다.사용자가 애플리케이션에 프롬프트를 입력하면, 애플리케이션은 이를 모델로 전달하고, 필요한 경우 함수 호출(Function Call)을 통해 API와 상호작용합니다.모델은 함수 식별자와 매개변수를 기반으로 API 요청을 생성하고, API로부터 받은 응답을 처리하여 최종 결과를 사용자에게 반환합니다.이 과정은 애플리케이션과 모델 간의 협력을 통해 복잡한 작업을 자동화하고 효율적으로 처리하는 데 중점을 둡니다.그러나, 기존에 사용되던 이러한 Tool Calling 은 다음과 같이 여러 한계가 존재했습니다.• None 기존의 Tool Calling 은 미리 정의된 함수나 API 에 의존하여, AI 가 수행할 수 있는 작업의 범위를 제한하였습니다.• None 또한 여러 단계의 복잡한 계산이나 데이터 처리, 그리고 데이터를 그래프나 차트로 시각화하는 것과 같은 작업에는 여전히 한계가 있었습니다.• None 특히, 동적으로 변하는 데이터나 사용자 입력에 따라 즉시 계산을 수행하는 것이 제한적이었습니다.이 포스팅에서 소개할 Code Interpreter 기술의 등장으로 이러한 한계를 많은 부분 해결하게 됩니다.미리 정의된 API 의 입출력에 의존하지 않고, LLM 모델을 사용하여 도구를 동적으로 생성하고 보다 유연한 패러다임으로 발전하게 되었는데요,이로써 Code Interpreter 는 Tool Calling 매커니즘의 진화를 가져오며 AI Agent 의 기능 범위를 혁신적으로 확장시킬 수 있게 되었습니다.Code Interpreter 는 사용자의 자연어 명령을 분석하여 Python 코드를 자동으로 생성하고 Sandbox 환경에서 코드를 실행하여 작업을 해결할 수 있는 기술입니다.Open AI 가 GPT-4 에 최초로 도입한 이 기술은, 동적으로 코드를 생성하는 기능을 포함하고 있다는 점에서 기존의 전통적인 Interpreter 와의 근본적인 차이를 보입니다.이렇게 Code Interpreter 를 통해 동적으로 생성된 Tool 은 LLM 런타임에 사용자의 프롬프트에 따라 생성한 함수 또는 코드 블록입니다.즉, 코드베이스에서 모든 가능한 시나리오를 미리 정의할 필요가 없으므로 훨씬 더 개방적이고 창의적인 문제 해결이 가능합

안녕하세요, 현대오토에버 CCS정보팀 장성호 책임입니다. 현대자동차그룹 커넥티드 카 서비스(CCS) 시스템 중, 글로벌 CCS1.0 코어 시스템 개발 및 운영을 맡고 있습니다. 담당 시스템의 VM Blue-Green 전환 프로젝트를 맡게 되어, 이에 대한 경험을 공유하고자 합니다. 프로젝트 배경CCS 1.0의 CI/CD는 주로 VM 환경에 Artifact를 배포하는 방식입니다. 또한 Property 주입은 FreeMarker를 활용해 .ftl 확장자에 JSON 값을 배치하는 방식으로 사용되고 있었습니다.그림 1. 기존 CCS 1.0 CI/CD이러한 구조는 다음과 같은 문제점이 있었습니다.FreeMarker 기반 Maven plugin 사용으로 빌드 도구가 maven에 종속Property 주입이 빌드 시점에 이루어져, Property 변경시 항상 CI/CD 파이프라인 전체 재실행 필요War 파일 중 최신 버전만 가져와 Rollback에 취약개발자가 VM에 접속해 일일이 chef-client 명령어를 실행시켜줘야 배포 진행*Chef - Ruby DSL를 활용해 인프라를 코드로 작성하는 IT 자동화 플랫폼. 작성된 코드는 cookbook이라고 부른다. *chef-client - Chef 플랫폼 배포 명령어. Chef cookbook에 명시되어 있는대로 명령어를 수행한다.FreeMarker그림 2. FreeMarker 구조FreeMarker에 대해 간단히 소개하자면, 변경되는 데이터를 템플릿에 따라 텍스트 출력(HTML, XML, 메일 등)으로 만들어주는 Java 라이브러리입니다. MVC 패턴이 익숙하시다면 Model을 View에 표출해주기 위한 템플릿 엔진이라고 이해하셔도 무방합니다. Freemarker Template Language(FTL)에 따라 템플릿을 작성해놓고 동적 데이터를 HTML로 변환하기 위해 만들어졌으나, HTML이나 웹에만 국한되진 않고 다양하게 사용가능합니다.기존 CI/CD에서도 FTL 템플릿에 JSON 값을 배치하고 나면, 텍스트 출력으로 properties.xml 이라는 파일이 만들어지는 구조였습니다. 이러한 로직을 빌드 시점에 사용하기 위해서 maven plugin으로 만들어놓은 상태였죠. 아쉽게도 maven에 대한 종속성이 생겨 gradle로 이관하기 쉽지 않은 상태였습니다.*MVC 패턴 - 하나의 애플리케이션를 구성할 때 Model, View, Controller 세가지 역할로 구분한 패턴. *Maven - pom.xml 기반으로  작성하는 Java 빌드 자동화 도구.*Gradle - Groovy/Kotlin DSL로 작성하는 Java 빌드 자동화 도구개편 방향VM Blue-Green 전환 프로젝트는 기존 문제점을 개선하기 위해 CI/CD를 선언적 방식으로 개편하였습니다.Git repository를 활용해 Property 관리Container Image을 활용한 Artifact 버전 관리Blue-Green 배포로 Production 환경에서 배포 테스트 수행 후, 실 트래픽을 받도록 전환Volume mount를 활용해 Property 주입을 배포 시점으로 변경이를 위해서 아래처럼 Harbor, AWX, Envoy, Docker compose와 같은 기술 스택이 추가되었습니다. 이러한 CI/CD 툴 변경은 인포테이먼트CCS개발팀에서 담당해주셨습니다. 그림 3. 신규 CCS 1.0 CI/CD*Blue-Green 배포 - 기존 버전인 Blue container에서 신규 버전인 Green container로 트래픽을 전환하는 무중단 배포 방식*Harbor - Container image를 저장하는 저장소 기능을 하는 오픈소스 프로젝트*AWX - Ansible 프로젝트 관리를 위한 웹 기반 사용자 인터페이스, REST API 및 Task 엔진 제공하는 툴. Ansible은 Python을 활용해 인프라를 코드로 작성하는 IT 자동화 플랫폼*Envoy - Lyft에서 c++로 개발한 Proxy. Side car로 배포되어 Application 간 트래픽이 Envoy를 거치게 해 트래픽 조정 및 Observability 확보에 유용하다.Volume mount를 통한 Property 주입컨테이너 환경으로 전환하면서 Docker compose로 편리하게 컨테이너 안에 필요한 파일을 주입할 수 있게 되었습니다. 외장 Tomcat + Spring war 조합을 사용하고 있었기에, 아래 경로에 resource 파일을 위치시키면 서버에서 필요한 파일을 불러올 수도 있었죠./usr/local/tomcat/webapps/MY_SERVER/WEB-INF/classes따라서 docker-compose.yaml 에서 다음처럼 기입하면 컨테이너 내에 properties.xml 파일을 위치시킬 수 있습니다. CICD 파이프라인을 잘만 구성한다면 Dev / Staging / Production에 따라 알맞는 property 파일을 주입할 수 있습니다.version: '3.8'services: my-app-blue: image: ${DOCKER_REGISTRY}/${DOCKER_APP_NAME}:${DOCKER_APP_VERSION} container_name: ${DOCKER_APP_NAME}-blue restart: always volumes: - /path/host/properties.xml:/usr/local/tomcat/webapps/MY_SERVER/WEB-INF/classes/properties.xml로컬 개발도 편리하도록 개선하기하지만 문제되는 것은 로컬 개발 환경입니다. 보통은 IntelliJ IDEA 같은 개발 툴을 사용할텐데, 매번 로컬 컴퓨터에 있는 Tomcat에 properties.xml을 옮기는 것은 여간 귀찮은게 아닙니다. 특히나 환경이 바뀐다면 일일이 주석을 바꿔야하는 불편함이 있었습니다.그림 4. Property 주입을 위한 properties.xml물론 소스 코드 내부에 환경별로 Property 파일을 만들 수도 있습니다. 그치만 값을 수정하고 배포하려면 Jenkins 부터 AWX 까지 전체 CICD 파이프라인을 실행해야해, 간단한 변경사항임에도 시간이

안녕하세요 Dev Platform & Corporate IT팀 팀 박진규입니다.이번 포스팅에서는 Windows Container에 대한 내용을 공유드리려 합니다.제가 담당하는 서비스들 중에서는 Windows OS에 종속적인 서비스들이 존재하는데,(ex. net framework)어느 날 이러한 서비스들을 Container 위에서 동작시킬 수 없을까 의문이 들었습니다.일반적으로 Container는 Linux 기반이다 보니,Windows에서는 이를 어떻게 해결할 수 있을까 찾아보던 도중Windows Container에 대해 알게 되었고,이에 대한 내용을 정리해서 공유드립니다.Windows Container 란?Windows 어플리케이션을 Windows Server 환경에서 격리하여 실행하기 위한 기능입니다.Windows Server 2016부터 지원되고 있습니다.Linux 컨테이너와 유사하게 애플리케이션을 독립된 환경에서 실행하지만Windows 컨테이너는 Windows 커널을 기반으로 실행됩니다.Windows Container 특이점1. 기본 이미지Windows Container 는 Microsoft에서 제공해 주는 4가지 종류의 기본 이미지를 사용해서 빌드가 가능합니다.각 이미지는 포함된 Windows 기능들이 다르기 때문에 상황에 따라 필요한 이미지를 선택하여 사용하시면 됩니다.(포함된 기능이 많을 수록 이미지 크기가 커집니다.)Microsoft에서는 대부분의 사용자에게 Windows Server Core 및 Nanoserver 를 추천하고 있습니다.아래는 직접 docker pull로 기본 이미지를 받았을 때이미지 사이즈를 정리한 내용입니다.이미지 종류이미지 사이즈특이사항Nano Server약 300 MB Server Core약 5 GB Windows약 9 GBwindows server 2019 까지만 지원합니다. (ltsc2019)windows server 2022 부터는 Windows Server 이미지를 사용해야 합니다.Windows Server약 10 GBwindows server 2022 부터 지원합니다. (ltsc2022) 2. 호환성Windows Container를 구동하기 위해서는 별도의 컨테이너 호환성 요구 사항이 존재합니다. Windows에서는 Linux와 다르게 사용자 모드와 커널 모드가 긴밀하게 결합되어 있고이로 인해 Windows Container 는 Host 서버의 Windows OS 버전에 따라 구동이 불가능한 경우가 생깁니다. 대표적으로 Windows 10 환경에서는 Windows Server 2022 이미지의 Container를 구동하는 게 불가능합니다. 실제로 Windows 10 환경에서 Windows Server 2022 이미지의 Container를 실행할 경우 아래와 같은 오류가 발생합니다.docker: a Windows version 10.0.20348-based image is incompatible with a 10.0.19043 host..Net Framework App을 Windows Cont

안녕하세요. 저는 검색서비스팀의 유성규입니다. 저희 팀은 에이닷 내 다양한 서비스에 사용되는 검색 및 추천 기능 개발과 운영에 주력하고 있습니다.이번 블로그에서는 저희가 어떻게 쿠버네티스를 이용해 컨테이너 기반 검색추천 시스템을 구축했는지,그리고 이 시스템이 에이닷 3.0 및 B tv 셋탑에서 출시된 미디어 에이전트 서비스에 어떻게 도입되었는지를 소개하고자 합니다.쿠버네티스를 사용하여 검색추천 시스템을 컨테이너화함으로써 여러 가지 중요한 이점을 얻을 수 있었습니다. 주요 이점은 다음과 같습니다.• None 개발 및 운영 효율성 향상: 반복적인 작업들을 자동화하며 개발과 운영 과정을 간편하고 효과적으로 관리할 수 있었습니다.• None 빠른 서비스 배포: 필요한 컴포넌트를 쉽게 배치하여 검색추천 서비스를 빠르게 제공했습니다.• None 중앙 집중화된 모니터링 도입: 모든 서비스 상태를 중앙에서 통합적으로 모니터링하고 관리할 수 있어 문제 해결과 운영 관리를 더욱 쉬웠습니다.쿠버네티스를 통해 효율성 및 자동화를 실현하기 위해, 저희가 세운 주요 목표는 다음과 같습니다.• None 상용화 가능한 쿠버네티스 클러스터 구축: 안정적이고 확장 가능한 쿠버네티스 클러스터를 구축하여, 다양한 서비스가 원활하게 운영될 수 있도록 합니다.• None 검색추천 시스템을 컨테이너로 배포: 기존의 검색추천 시스템을 컨테이너 기반으로 전환하여, 서비스의 유연성과 확장성을 확보합니다.• None 컨테이너 기반의 애플리케이션 모니터링 시스템 구축: 컨테이너 환경에서 효율적인 모니터링 시스템을 구축하여, 서비스 운영 상태를 실시간으로 확인하고 관리할 수 있도록 합니다.본 글에서는 목표를 달성하기 위한 진행한 작업들에 대해서 전체적으로 공유하고자 합니다.쿠버네티스(Kubernetes)는 API 서버, 스케줄러, 컨트롤러 매니저 등으로 구성된 컨트롤 플레인과 각 노드에 설치되는 Kubelet 데몬을 포함하고 있습니다.이 시스템은 컨테이너 런타임과 네트워킹 기반 위에서 작동하며, 대부분의 컴포넌트는 리눅스 커널 기능에 크게 의존합니다.따라서 리눅스 커널 설정 및 파라미터 관리가 매우 중요합니다.쿠버네티스 클러스터를 초기화하는 작업은 도구로 지원되지만, 컨테이너 런타임 구성, 네트워킹 설정, 리눅스 커널 파라미터 조정 등 다양한 세부 사항의 관리는 여전히 클러스터 관리자의 책임입니다.이는 여러 공식 문서를 따르면서 진행할 수도 있지만, 이 방법은 복잡하고 시간이 많이 소요될 수 있습니다.이를 해결하기 위해 오픈소스 도구인 Kubespray를 사용하였습니다.Kubespray는 쿠버네티스 구성 요소의 설치뿐만 아니라 리눅스 커널 설정과 다양한 옵션들을 자동화하며,오랜 시간 동안 개선되고 활발한 커뮤니티 지원 덕분에 상용화 가능한 수준의 쿠버네티스 클러스터를 쉽게 구축할 수 있습니다.저희는 Kubespray 2.23 버전을 사용하여 쿠버네티스 클러스터를 설정하였습니다.클러스터를 구성한 후에는, 클러스터 환경을 더욱 컨테이너 중심 방식으로 운영하기 위해 추가적인 오픈소스 도구들을