지난 1편에서는 배치 크기(Batch size)와 시퀀스 길이(Sequence length)를 조정하는 방법부터, 학습 과정에서 메모리를 아껴 쓰는 최적화 기법까지 다양한 기법을 살펴보았습니다.요약하자면 비싼 GPU 메모리를 어떻게 효율적으로 활용해 적은 자원으로도 최적의 학습을 할 수 있을지를 고민해봤습니다.이번에는 학습 알고리즘 최적화에 대해 이야기해보려고 합니다. 전편보다 조금 더 전문적인 내용을 다뤄야 할 것 같은데, 개발자의 시선으로 쉽게 풀어보려고 합니다.이번 글에서는 다음과 같은 주제를 다루고 있습니다.• None Learning Rate가 모델 학습에 미치는 영향• None Learning Rate 스케줄링이 필요한 이유Part1 편은 아래 링크를 참고하세요.• None 실험으로 알아보는 LLM 파인튜닝 최적화 가이드 Part 1.• None 이번 포스팅에서 사용된 코드는 아래 GitHub 링크에서 다운로드할 수 있습니다.• None 모델 학습에는 HuggingFace Transformers 라이브러리를 활용했으며, 관련 Training Arguments에 대한 내용을 본문의 각 세션에 표기 했습니다.• None 실험 환경은 별도 언급이 없는 경우, 다음과 같은 환경에서 진행되었습니다.딥러닝 모델을 학습할 때, 우리는 모델이 예측한 값과 실제 정답 간의 차이를 측정하기 위해 손실 함수(Loss Function)를 정의합니다.모델을 학습한다는 것은 이 손실 값을 최소화하는 과정이며, 이것이 바로 최적화(Optimization)입니다.Optimizer란 이러한 최적화를 수행하는 알고리즘입니다. 쉽게 말해 어떻게 하면 손실 함수의 최소값을 빨리 찾아 낼 방법을 결정하는 역할을 하는 것이죠딥러닝 기법이 본격적으로 사용된 이래로 현재까지 많은 옵티마이저들이 제안되었지만, 현재 LLM 파인튜닝에서 가장 일반적으로 사용되는 옵티마이저는 Adam의 변형인 AdamW 입니다.그럼 Adam 계열의 옵티마이저를 간단히 살펴보고, 메모리 효율화를 위해 개선된 형태도 살펴보겠습니다.Adam은 마치 운전할 때 가속과 브레이크를 자동으로 조절하는 ‘스마트 크루즈 컨트롤’과 같은 역할을 합니다.일반적인 경사 하강법(SGD)이 고정된 속도로 움직이는 것이라면, Adam은 1차 모멘트(평균)와 2차 모멘트(그래디언트 제곱값의 이동 평균)를 각각 추적하여 학습률을 자동으로 조정합니다.1차 모멘트는 현재까지의 그래디언트 평균을 계산하여 방향과 속도를 결정하는 역할(가속 페달)을 하고, 2차 모멘트는 그래디언트의 변화량을 추적하여 급격한 변화를 방지하는 역할(브레이크)을 합니다.즉, 변화가 크면 학습률을 줄이고, 변화가 적으면 학습률을 늘리는 방식으로 빠르고 안정적인 학습이 가능합니다.단점으로는 두 개의 모멘트 값을 저장해야 하므로 메모리 사용량이 증가한다는 문제가 있습니다.Adam이 가속과 브레이크를 조절하며 최적의 속도를 찾는다면, AdamW는 여기에 불필요한 연료 소모(가중치 증가)를 방지하는 연비 최적화 기능(Weight Decay)을 추가한 "연비 개

안녕하세요, 현대오토에버 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 파이프라인을 실행해야해, 간단한 변경사항임에도 시간이

카카오 분산데이터베이스 조직에서 안정적인 MongoDB 운영을 위해 노력하고 있습니다.안녕하세요, 카카오 분산데이터베이스 조직에서 MongoDB를 운영하고 있는 앤디입니다.MongoDB의 메인 스토리지 엔진인 WiredTiger에 관한 시리즈의 첫 글 "MongoDB WiredTiger의 파일 구조"에서는 WiredTiger의 구성요소와 아키텍처를 전반적으로 살펴보았습니다.이번 글에서는 조금 더 세부적으로 들어가서, MongoDB WiredTiger에서 B+Tree를 활용한 데이터 관리 방법을 심층적으로 다루어 보겠습니다. 앞선 “MongoDB WiredTiger의 파일 구조” 내용과 더불어 MongoDB에 대한 기반 지식이 필요한 내용이 포함될 수 있으니 참고해 주시길 바라며, MongoDB의 데이터 저장 방식에 관심 있는 분들께 유용한 자료가 되기를 기대합니다.이번 글 작성에 사용된 MongoDB 버전과 주요 도구는 아래와 같습니다.• gdb (GNU Debugger) : 프로그램 실행을 제어하고 메모리 상태를 분석하는 데 유용한 도구입니다. (구체적인 빌드 방법 및 사용법은 부록을 참조해 주시기 바랍니다.)B+Tree는 1970년대에 등장해 지금까지도 Oracle, MySQL, PostgreSQL과 같은 주요 DBMS에서 사용되고 있는 자료구조입니다. B+Tree는 데이터 삽입과 삭제 시에도 트리의 높이를 균형 있게 유지하는 동적인 트리 구조로, 여기에서 'B’는 보통 Balanced를 의미합니다. "+"는 실제 레코드가 가장 하위 레벨인 리프 노드(leaf node)에만 저장된다는 것을 의미하며 레코드들은 항상 정렬된 상태를 유지합니다. 아래 그림은 가장 일반적으로 접할 수 있는 B+Tree의 형태를 나타냅니다.앞서 언급한 DBMS보다는 한참 어린 2007년생 MongoDB도 B+Tree를 사용하고 있는데요. 이렇게 오랜 기간 동안 발전하면서 범용적으로 쓰이다 보니, B+Tree의 세부 구현은 각 DBMS의 특성에 따라 다를 수 있습니다.이번 문서에서는 제가 주목하는 MongoDB WiredTiger의 B+tree에 대해 몇가지 특징을 살펴보려고 합니다. 특히 페이지 간의 연결구조와 리프 페이지에서의 데이터 추가, 삭제, 변경 처리를 상세히 다루고, 마지막으로 이해를 돕기 위해 MySQL의 InnoDB에서 사용되는 B+Tree와도 가볍게 비교해 보도록 하겠습니다.페이지는 B+Tree에서 노드라고도 불리며, 데이터를 저장하거나 검색하는 기본 단위로 사용됩니다. 그리고 여러 페이지를 스캔해야하는 범위 쿼리(range query) 혹은 순차 접근(sequential access)이 필요한 작업에서의 효율성을 위해 <그림 1>과 같이 동일한 레벨의 페이지끼리의 연결을 유지하는 방식을 보편적으로 사용합니다.하지만 WiredTiger에서는 동일한 레벨의 페이지끼리 연결을 유지하지 않습니다. 이를 확인하기 위해 WiredTiger의 B+Tree 구조를 살펴보겠습니다.먼저 그림에서 확인할 수 있는 내용을 정리하고, gdb를 통해 상세 구조를 하

AWS CDK(Cloud Development Kit)는 클라우드 인프라를 코드로 정의하고 프로비저닝할 수 있는 강력한 프레임워크입니다.TypeScript, Python, Java 등 익숙한 프로그래밍 언어를 사용하여 AWS 리소스를 관리할 수 있습니다.특히 AWS 공식 문서와 다양한 핸즈온 예제들에서 CDK를 적극적으로 활용하고 있습니다.개발자들은 Github나 AWS 공식 사이트 등에서 어렵지 않게 구할 수 있는 CDK 프로젝트의 빌드 및 실행을 통해 실제로 클라우드 인프라를 구성하고 실행해 볼 수 있습니다.이를 통해 손쉽게 AWS 인프라를 학습하고 클라우드 웹 서비스의 구성을 경험해볼 수 있습니다.그러나 웹 상에서 얻은 좋은 예제들도 빠르게 진행되는 CDK의 소프트웨어 업데이트 및 AWS 클라우드 인프라 정책의 변경으로 실행에 어려움을 겪게 되는 경우가 많습니다.최근에 저도 묵혀놓았던 CDK 프로젝트를 다시 꺼내어 기존에 작성된 CDK코드를 그대로 사용하여 클라우드에 배포를 해보았는데요.생각처럼 한번에 되지 않아 어려움을 겪고 웹 검색 및 문서들을 참조하여 해결할 수 있었습니다.그 때의 경험했던 이슈들을 정리하고 그 외 잠재적으로 발생가능한 문제점들에 대해 정리해보았습니다.AWS CDK 버전 업데이트 가이드• None• None AWS CDK는 메이저.마이너.패치 형식의 시맨틱 버전 관리를 사용합니다. 마이너 및 패치 릴리스는 이전 버전과 호환되며, 동일한 메이저 버전 내에서는 안전하게 업그레이드할 수 있습니다.• None #### CDK v1에서 v2로의 전환• None CDK v1은 2023년 6월 1일부로 지원이 종료되었습니다.• None 각 모듈별 Import 방식이 aws-cdk-lib로 통합되었습니다.• None 이전 버전의 구문과 새로운 버전의 구문이 호환되지 않는 경우가 있습니다• None v1에서 v2로 전환할 때는 다음 단계를 따르는 것이 좋습니다:• None 더 이상 사용되지 않는 구성요소들이 존재합니다• None 이전 버전의 코드를 그대로 실행하면 경고나 오류가 발생할 수 있습니다오래 전에 구성해 놓았던 CDK프로젝트를 AWS인프라에 재배포해보았는데 역시 한번에 되지 않았습니다.소프트웨어 패키지나 라이브러리의 버전을 업데이트하고 난 후에도 여러가지 에러가 있었습니다.가장 먼저 마주했던 문제는 ECS클러스터를 구성하는 스택에서 발생 하였습니다.에러 메시지를 분석하고 검색해보니 AutoScalingGroup을 설정하여 배포하는데 필요하였던 Autoscailing configuration구문이 더 이상 사용되지 않아 발생하는 문제였습니다.아래의 aws-cdk 공식 Github의 issue에서 관련한 문제에 대해 알 수 있습니다.AWS::AutoScaling::LaunchConfiguration 유저가이드 문서에도 Launch Configuration을 사용하지 말고 Launch Template을 사용할 것을 강력 권고하고 있네요.아마도 CDK으 특정 버전 이상부터는 사용이 되지 않도록 강제 되어있는 것 같습니다.다음

안녕하세요. 강남언니 커뮤니케이션 리더 죠앤 Joanne 입니다.강남언니 팀에서 채워지는 기록과 대화들이 많아질수록, 소개하고 싶은 우리의 이야깃거리가 참 많아졌어요. 그 이야기를 [동료 생각 좇기] 코너로 담아보려 합니다. 지난 번 글로벌 스쿼드 Mondri와 나눈 강남언니 태국 진출기에 이어, 오늘은 강남언니 후기 도메인을 리딩하고 있는 애틀란타 스쿼드 PO Carlos와의 대화입니다. 고객들이 더 좋은 미용의료 후기를 경험할 수 있도록 애틀란타 스쿼드에서 어떤 치열한 고민을 하고 있는지 좇아가봅니다. 1. 오늘의 주제: 아름답도록 정확한 시술성형 후기를 위해강남언니의 브랜드 광고 메시지들입니다. 미용의료 시장은 국내외 불문하고 의료 소비자와 공급자 간 정보불균형 문제를 풀어가고 있어요. 시술과 성형을 고민하는 사람들이 믿을 수 있는 병원 정보를 찾고, 고민에 딱 맞는 병원을 결정하기가 정말 어려운 고관여 영역의 의료 서비스라 그 문제는 더욱 심각합니다.강남언니가 2024년 말 새롭게 내세운 메시지 에는 두 가지 중의적 의미가 담겨있습니다. 첫째는 ‘아름답도록 정확하다’에 초점을 두어 가짜 의료정보 문제를 해결하고 있는 노력이 담겨있고요. 둘째는 ‘아름답고 정확한 정보’로서 강남언니의 정보 플랫폼 정체성을 강조했습니다. 즉, 강남언니가 의료 소비자 중심의 정보 균형을 맞추며 시장 문제를 해결하고 있다는 메시지입니다.오늘은 ‘시술성형 후기’에 대해 깊게 이야기하고자 합니다. 사람들은 여드름 고민 하나로 피부과를 찾을 때도 시술가격, 의사경력 같은 사실 정보뿐 아니라 다른 유저가 느낀 불편 등 가치 정보까지 다양하게 알고 싶어해요. 여기서 말하는 대표적인 가치 정보는 라고 할 수 있습니다.유저에게 큰 영향을 미치는 중요한 정보인만큼 강남언니는 1) 객관적인 후기 2) 체계적이고 풍부한 후기 를 제공할 수 있는가 관점에서 더 좋은 후기 도메인을 만들고자 노력 중입니다. 이에 대한 구체적인 고민과 액션, 성과들에 대해 애틀란타 PO Carlos와 나눈 대화를 소개합니다. (1) ‘광고 같은 후기’ 문제를 해결하려면Q. Joanne 👧🏻 애틀란타 스쿼드는 강남언니 후기 도메인의 오너십을 가지고 있어요. Carlos는 강남언니 팀 합류 전 창업, 핀테크, 여행 플랫폼 PO 등 다양한 경험이 있으시죠. 당시 경험들과 현재 일을 공통적으로 관통하는 메시지가 있나요?A. Carlos 👨🏼‍🦰 ‘고객 목소리’가 가장 중요하다는 걸 잊지 않는거요. 강남언니 플랫폼에서 유저 목소리가 가장 직접적으로 드러나는 공간이 후기입니다. 유저가 자신의 병원 경험담을 다른 유저를 위해 손수 작성하고, 다른 유저가 쓴 후기를 보며 어떤 병원과 시술을 결정해야 할지 영향을 받아요. 이전에 제가 커머스를 직접 운영할 때 후기 평판으로 초기 사업 성패가 결정난다는 걸 깨닫고서는 고객 목소리를 정말 중요하게 생각합니다.Q. Joanne 👧🏻 시술성형 후기가 유저 의사결정에 많은 영향을 끼치는 반대 작용으로 ‘어뷰징’이라는 고질적 문제가 오래 지속돼왔습니다. 강남언니 후기에서

DeepSeek-R1은 강화 학습(RL)을 통해 대형 언어 모델(LLM)의 추론 능력을 향상시키는 데 중점을 둔 모델입니다.이 모델의 핵심 아이디어는 기존 지도 학습(Supervised Fine-Tuning, SFT) 없이도 모델이 자율적으로 추론 능력을 향상시킬 수 있음을 증명하는 것입니다.DeepSeek-R1에는 두 가지 주요 버전이 있습니다: DeepSeek-R1-Zero와 DeepSeek-R1.DeepSeek-R1은 다음과 같은 특징을 가지고 있습니다.• None 강화 학습 기반 추론 강화: GRPO(Group Relative Policy Optimization) 기법을 활용하여 RL 비용을 절감하면서도 효과적으로 모델 성능을 향상시키는 방법을 사용합니다.• None Cold Start 데이터 적용: 초기 데이터를 학습 후 RL을 적용하는 방식으로 학습을 진행하여 가독성 향상과 훈련 안정성을 증가시킵니다.• None 지식 증류(Distillation) 활용: 대형 모델의 학습 패턴을 효과적으로 작은 모델로 추출할 수 있음을 입증했습니다. 다양한 크기의 소형 모델(1.5B, 7B, 14B, 32B, 70B)을 훈련하여 소형 모델에서도 강력한 성능을 보였습니다.• None 강화 학습 기법 적용: GRPO 기법을 사용하여 RL 비용을 절감하면서도 효과적으로 모델 성능을 향상시킵니다.• None 보상 모델(Reward Model) 도입: 정확성과 형식 기반 보상을 설정하여 모델이 적절한 논리적 사고를 수행하도록 유도합니다.• None "Aha Moment": 모델이 자율적으로 논리적 사고를 개선하는 현상이 관찰됩니다.• None 가독성 향상을 위해 Cold Start 데이터 도입: 초기 데이터를 학습 후 RL을 적용하여 가독성 향상과 훈련 안정성을 증가시킵니다.• None 훈련 안정성을 높이고 언어 혼합 문제 해결: 초기 데이터를 활용하여 모델의 가독성을 향상시키고, 언어 혼합 문제를 해결합니다.• None 1.5B ~ 70B 모델 크기별 최적화: 다양한 크기의 소형 모델을 훈련하여, 소형 모델에서도 강력한 성능을 보였습니다.• None Open-source 모델 대비 우수한 성능 달성: 지식 증류를 통해 Open-source 모델 대비 우수한 성능을 달성하였습니다.• None 기존 모델(Deepseek-R1)에서 데이터를 추출해 지도 학습(SFT) → R1-Distill 생성• None R1-Distill을 기반으로 강화 학습(GRPO) 적용 → R1-Zero 생성DeepSeek-R1은 다양한 벤치마크에서 기존 모델과 비교하여 뛰어난 성능을 보였습니다.DeepSeek-R1은 OpenAI-o1-1217과 비슷한 수준의 성능을 유지하면서도, 특히 코드 및 수학 문제 해결 성능이 뛰어난 것으로 나타났습니다.또한, DeepSeek-R1에서 추출된 데이터를 활용한 소형 모델(DeepSeek-R1-Distill-Qwen-7B, 14B, 32B 등) 역시 기존 오픈소스 모델 대비 성능이 우수함을 입증하였습니다.• None DeepSeek-R1을 사