서문: 모델 배포가 끝이 아니다 - AI 시대의 숙제, MLOps최근 몇 년간 AI와 머신러닝(ML)은 단순한 연구 단계를 넘어 기업의 핵심 비즈니스 동력으로 자리 잡았습니다. 데이터 과학자가 뛰어난 성능의 ML 모델을 개발하는 것은 매우 중요한 일입니다. 하지만 그 모델이 실제 사용자에게 가치를 제공하려면 '프로덕션 환경'에서 안정적으로 작동해야 합니다.문제는 여기에 있습니다. 코드로만 이루어진 일반 소프트웨어와 달리, ML 모델은 코드, 데이터, 하이퍼파라미터라는 세 가지 요소에 의해 성능이 결정되며, 시간이 지나면서 새로운 데이터에 의해 성능이 저하(Data Drift)될 수 있다는 것입니다.이러한 복잡성을 해결하고 AI 시스템의 개발부터 운영까지의 전 과정을 효율적으로 통합하는 방법론이 바로 ML..

Kubernetes를 공부하거나 실제로 운영 환경에 적용하다 보면 "컨테이너"와 "파드"라는 용어가 자주 등장합니다. 두 개념은 비슷해 보이지만, Kubernetes에서는 엄연히 다른 역할을 가지고 있습니다. 이 글에서는 컨테이너와 파드의 개념을 비교하며, 어떤 차이가 있는지 정리해보겠습니다.컨테이너란?컨테이너(Container)는 애플리케이션과 그 실행 환경을 하나로 패키징한 단위입니다. 운영체제 수준의 가상화를 통해, 어떤 환경에서도 동일하게 애플리케이션을 실행할 수 있도록 만들어줍니다. 대표적으로 Docker 컨테이너가 많이 사용됩니다.컨테이너는 다음과 같은 특징을 가집니다.애플리케이션, 라이브러리, 설정 파일 등을 포함격리된 환경에서 실행되며, 가볍고 빠르게 구동됨단독 실행도 가능 (docker ..

최근 온프레미스(on-premise) 환경에서 Docker Compose로 서비스를 구성하는 작업을 진행하게 되었습니다. 그런데 예상대로 문제가 하나 생겼습니다. Compose 파일 내의 일부 서비스는 build: 지시어를 통해 Dockerfile을 기반으로 이미지를 빌드하도록 되어 있었는데, 온프레미스 환경에서는 외부 인터넷이 차단되어 있어 apk update, apt-get install 등 외부 패키지 설치 명령이 전혀 작동하지 않았습니다.1. 외부 네트워크 환경에서 이미지 미리 빌드먼저, 외부 인터넷이 가능한 환경에서 Dockerfile 기반으로 필요한 이미지를 미리 빌드했습니다.docker build -t myapp:latest .이렇게 하면 myapp:latest라는 이름의 Docker 이미지..

Spring Boot 기반 애플리케이션을 Kubernetes 환경에 배포하면서, 로그 수집 방식에서 다음과 같은 문제가 발생했다. 동일한 로그 경로에 여러 Pod가 동시에 접근하면서 로그가 덮어씌워지거나 뒤섞이는 문제가 생긴 것이다. 이를 해결하기 위해 Pod별로 로그를 분리하고, 날짜 기준으로 Rolling 되도록 설정한 경험을 정리해본다.1. 로그 파일이 충돌하는 문제 발생애플리케이션 로그는 app.log라는 고정된 파일명으로 기록되고 있었고, 이는 여러 Pod가 동일한 볼륨을 공유할 경우 로그 충돌을 일으켰다. 특히 상태 비저장(Stateless)한 구조에서 동시성이 높은 상황에서는 로그 유실이나 파일 잠금 문제가 발생할 수 있었다. 따라서 Pod마다 고유한 로그 파일을 생성하는 방식이 필요했다.2..

AWS Elastic Container Registry(ECR)를 사용할 때, MFA(Multi-Factor Authentication)가 활성화된 계정을 이용하는 경우에는 매번 임시 세션 토큰을 발급받아야만 인증이 가능합니다. 이 과정을 수동으로 반복하다 보면 번거롭고 비효율적일 수 있습니다. 특히 Docker로 이미지를 푸시하거나 풀(Pull)하는 작업이 잦은 경우에는 인증 절차를 자동화하는 것이 큰 도움이 됩니다.이 글에서는 Windows 환경에서 배치 파일(.bat)을 사용하여 AWS CLI와 Docker 로그인을 자동화하는 방법을 소개합니다. 사용자로부터 MFA 코드를 입력받아 임시 자격 증명을 발급받고, 해당 자격 증명을 사용해 ECR에 로그인하는 과정을 자동화합니다.사전 준비 사항자동화 스크..