안녕하세요. 자율주행개발센터의 데이터 엔지니어 백주헌입니다.최근 딥시크社가 자체 학습한 거대언어모델(LLM) DeekSeek-R1 을 출시하여 세간의 화제가 됐습니다. 하지만 한편으로는 정보유출에 대한 우려로 세계 각국에서 딥시크 온라인 서비스 사용을 금지하고 나서기도 했는데요. 이 글에서는 이러한 우려들을 해소할 수 있는, 오프라인 로컬 환경에서의 딥시크 모델 사용법을 안내해보고자 합니다.딥시크, 뭐가 대단한건가요?본격적인 튜토리얼에 앞서 딥시크가 왜 화제가 되었는지 그 특징을 간단히 살펴보겠습니다.효율적인 학습 및 최적화 방안으로 적은 수의 GPU만으로도 ChatGPT 수준의 최고사양 성능 달성강화학습을 활용한 보다 발전된 Reasoning model 개발 방법론 제시LLaMA 등 공개모델을 차용해 애플리케이션 배포에 최적화된 DeepSeek-Distill 모델 배포학습모델과 추론코드를 오픈소스로 공개한마디로 딥시크는 시중의 경쟁모델보다 우수한 성능의 모델을 더 적은 GPU로, 더 빠르게, 더 저렴하게, 더 가볍게 만들어내는 데 성공했습니다. 그러한 과정을 담은 논문을 공개해 학술적으로도 기여했고, 애플리케이션 배포를 위한 최적화 모델도 별도로 공개하였죠. 사람들이 따라해볼 수 있도록 추론코드와 학습모델을 모두 Github와 Hugging Face 오픈소스 플랫폼에 공유했습니다. 값비싼 GPU를 많이 갖춘 거대 기업만이 LLM을 개발할 수 있다는 편견을 깨부수게 되면서 딥시크가 전 세계를 뜨겁게 달궜던 것이죠.DeepSeek-Janus 로컬 환경에서 구축하기현재 공개된 딥시크 모델 중 이번 글에서는 VLM 모델인 DeepSeek-Janus을 먼저 다뤄보겠습니다. DeepSeek-Janus 는 1B 부터 7B 까지 다양한 사이즈의 모델을 제공합니다. 따라서 개발환경 사양에 맞는 사이즈의 모델을 시도해보면 됩니다. 여기서 B란 1B=1 Billion, 즉 모델의 파라미터 개수가 10억개라는 뜻입니다. 7B 모델은 그 7배인 70억개라는 뜻이 됩니다. 당연히 사이즈가 큰 모델일수록 더 높은 사양이 요구됩니다.기본 요구사항ModelDeepSeek-Janus-1.3BDeepSeek-Janus-Pro-1BDeepSeek-Janus-Pro-7BOSLinuxLinuxLinuxPythonPython>=3.8Python>=3.8Python>=3.8GPUNVIDIA GPU 8GB 이상의 VRAMNVIDIA GPU8GB 이상의 VRAMNVIDIA GPU32GB 이상의 VRAMMemory16GB 이상의 메모리16GB 이상의 메모리32GB 이상의 메모리Storage10GB 이상의 저장공간10GB 이상의 저장공간20GB 이상의 저장공간*해당 수치들은 저자가 직접 모델을 실행해보면서 측정한 값으로, 측정 환경에 따라 다를 수 있습니다! 각자 개별 환경에서 아래 명령어들로 성능을 측정해볼 수 있습니다.사양 모니터링하기$ watch -n 0.1 nvidia-smi # 0.1초마다 갱신하며 nvidia GPU 성능 확인$ htop # CPU Core, Memory 등의 실시간 성능 확인$ df -h # 파일 시스템 저장공간 확인Janus-Pro-1B 모델의 이미지 생성 작업의 소요 자원을 측정한 (좌) nvidia-smi (우) htop 결과. GPU memory를 약 14GB, 시스템 메모리는 13GB 사용함을 확인할 수 있다.1. 사전 작업 - 가상환경 생성편리한 개발환경 구축을 위해 python 가상환경을 생성해 진행하겠습니다. docker 컨테이너를 만들어 사용하셔도 무방합니다.가상환경 생성# 파이썬3.10 가상환경 패키지 설치$ sudo apt install python3.10-venv # deepseek 라는 이름으로 가상환경 생성$ python3 -m venv deepseek # deepseek 가상환경 진입$ source deepseek/bin/activate deepseek 가상환경 활성화된 모습2. 코드 및 학습모델 다운로드딥시크는 github에 추론코드를, hugging face에 모델 파일을 업로드 해놓았습니다. 추론코드는 Janus repository를 공용으로 사용하며, 원하는 모델을 각각의 hugging face 링크에서 다운받은 뒤 코드가 위치한 폴더에 이동시켜주면 됩니다.코드 다운로드$ pip install git # git 패키지 설치$ git clone https://github.com/deepseek-ai/Janus.git # 추론 코드 다운로드모델 다운로드$ cd Janus # 코드 위치로 이동$ mkdir deepseek-ai$ cd deepseek-ai # 모델을 저장할 폴더 생성 후 해당 폴더로 이동$ git lfs install# 원하는 모델 선택하여 다운로드$ git clone https://huggingface.co/deepseek-ai/Janus-Pro-1B$ git clone https://huggingface.co/deepseek-ai/Janus-1.3B$ git clone https://huggingface.co/deepseek-ai/Janus-Pro-7B코드 및 모델 폴더트리 구성3. 패키지 설치패키지 설치$ cd .. # 코드 위치로 이동$ pip install -e .4. 추론 코드 편집 및 예제 실행Image Understanding 예제먼저 Image Understanding 예제를 실행해보겠습니다. inference.py 코드 내의 model_path 를 실행하고자 하는 모델로 변경해준 후, 커맨드를 입력해줍니다. 저는 Janus-1.3B 모델을 사용해보겠습니다. inference.py 코드에 작성되어 있는 기본 예제는 equation.png 라는  입력 이미지 파일에 "Convert the formula into latex code." 라는 프롬프트를 수행하는 예제이네요. conversation 리스트 내의 "content" 와 "images" 를 수정해 원하는 입력을 넣어줄 수도 있습니다.$ python inference.py # 이미지 분석 예제 실행inference.py 예제 내 model_path와 프롬프트 입력에 해당하는

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 런타임에 사용자의 프롬프트에 따라 생성한 함수 또는 코드 블록입니다.즉, 코드베이스에서 모든 가능한 시나리오를 미리 정의할 필요가 없으므로 훨씬 더 개방적이고 창의적인 문제 해결이 가능합

안녕하세요. 쏘카 데이터엔지니어링팀 삐약, 루디입니다.내용을 시작하기에 앞서, 저희 팀의 업무와 역할에 대해 간략히 소개해 드리겠습니다.데이터엔지니어링팀은 신뢰할 수 있는 데이터를 쏘카 구성원들이 안정적으로 활용할 수 있도록 기반을 마련하고, 이를 실제 비즈니스에 적용할 수 있는 서비스를 개발하며 환경을 구축하고 있습니다. 데이터 마트 관리, 데이터 인프라 구축, 그리고 데이터 제품(Data as a Product) 개발 등 폭넓은 업무를 수행하고 있습니다.특히 주요 업무로는 배치 및 실시간 스트리밍 파이프라인을 설계하고 개발하여, 쏘카의 모든 서비스에서 발생하는 데이터를 비즈니스 분석에 효과적으로 활용할 수 있도록 지원하는 역할을 하고 있습니다.이번 글에서는 저희 팀이 관리 및 운영하는 데이터 파이프라인 중, 비즈니스 의사 결정 시 지표로 사용되는 서버 로그를 데이터 웨어하우스로 사용하고 있는 BigQuery에 적재하는 로그 파이프라인 개선 과정을 소개드리고자 합니다개선을 하게 된 가장 주요 이유 중 하나는 데이터 스키마 변경으로 인해 겪는 어려움 이었습니다. 이를 해결하기 위해 데이터 컨트랙트를 도입하게 되었고, 이 과정에서 얻은 경험을 나누고자 합니다. 이번 시리즈는 비슷한 문제를 겪고 계신 분들께 도움이 되길 바랍니다.• 데이터 파이프라인을 구축하거나 개선하고자 하는 데이터 엔지니어• 데이터 컨트랙트를 도입하려는 개발자• 데이터 엔지니어의 업무에 대해 궁금한 분2. 기존 로그 파이프라인 현황기존 파이프라인을 설명하기에 앞서, 아키텍처의 문제를 더 명확히 이해하기 위해 원본 데이터의 구조와 요구사항을 먼저 살펴보겠습니다.원본 데이터에서 하나의 로그 파일은 다음과 같은 형식으로 제공됩니다.하나의 파일에는 여러 종류의 로그 데이터가 섞여 있으며, 모든 데이터에는 로그의 종류(type)와 생성 시간(timeMs) 같은 공통 필드가 포함되어 있습니다. 또한 각 로그 타입마다 고유한 필드도 존재합니다.파이프라인의 요구사항은 아래와 같습니다.• BigQuery 테이블화: 로그 데이터는 타입별로 구분된 BigQuery 테이블에 저장되어야 하며, 이를 통해 조회 및 분석이 가능해야 합니다.• 특정 타입 데이터 적재: 요청한 타입의 데이터만 BigQuery에 적재해야합니다.• 배치성 처리: 데이터 처리와 적재는 최소 2시간 이내에 이루어져야 하며, 가능하면 더 빠르게 처리되어야 합니다.이러한 데이터 구조와 요구사항을 바탕으로, 기존 파이프라인이 어떻게 구성되어 있는지 살펴보겠습니다.2-2. 기존 파이프라인 아키텍처우선 어떻게 데이터 파이프라인을 개선할 것인가에 대한 질문에 대한 답을 하기에 앞서 기존 아키텍처에 대하여 이해하고 어떤 부분에서의 문제가 발생하고 있는지의 파악이 필요합니다.기존 파이프라인 설계 당시의 상황과 고려 사항을 살펴보면, 이미 Amazon Kinesis Data Stream(KDS)과 Firehose를 통해 AWS S3에 데이터가 적재되고 있는 환경이었습니다. 더불어 로그 데이터는 주로 분석 용도로 활용될 예정이었기에 실시간성

시작말안녕하세요.저는 ICT본부 CDO 기업데이터실에서 글로벌 기업데이터허브를 구성 & 관리 & 서비스 하고 있습니다.데이터 엔지니어링 업무를 수행하며 고민하거나 현재하고 있는 부분들을 공유 드리려고 합니다.저는 현재 Airflow 를 활용하여 데이터 수집, 처리, 저장 등의 다양한 Task들을 스케줄링 하고 있습니다.먼저 Airflow 가 어떤 것이고 왜 Airflow 를 활용하고 있는지에 대해서 공유 드리려고 합니다.Airflowhttps://airflow.apache.org/docs/apache-airflow/stable/index.html#what-is-airflowApache Airflow 는 Airbnb 에서 workflow 들을 관리하고 스케줄링 하기 위해 만든 파이썬 기반의 오픈 소스 입니다.Workflow 를 Python code 로 작성할 수 있으며, DAG(Directed Acyclic Graph) 라는 대분류 안에 workflow 들이 속하여 스케줄링 됩니다.간단한 모니터링 화면을 제공하지만 제법 필요한 기능들을 포함하고 있습니다.https://airflow.apache.org/docs/apache-airflow/stable/index.html#workflows-as-codeApache Airflow 공식 문서 - DAG 시각화Apache Airflow 공식 문서 - DAG 시각화왜 Airflow 를 사용하는지?기존의 Hadoop 생태계를 사용하셨다면 Oozie 를 많이 활용했던 경험이 있으실 듯 합니다.Oozie 와 비슷한 개념들을 많이 가지고 있지만, 확실히 차별적으로 가지고 있는 기능들도 많이 있기 때문에 Airflow 를 메인 스케줄러로 활용합니다.아래와 같은 이유로 Airflow 사용을 고려했습니다.Open Source 입니다.Python 기반의 Workflow 작성을 제공합니다.팀구성원 분들이 다양하게 사용하는 언어 중 공통적으로 일치하는 부분이 Python 입니다.앞으로 함께 일 하실 분들의 대다수가 Python 활용 가능자 일 듯 합니다.빌드를 하지 않고 수정할 수 있는 스크립트 언어가 유지보수하기 편합니다.Kubernetes 를 지원합니다.물론 Local Executor 나 Celery (자체 클러스터) 를 지원합니다.https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/executor/index.html#local-executorshttps://airflow.apache.org/docs/apache-airflow-providers-celery/stable/celery_executor.html현재 Kubernetes 플랫폼을 구축 중이며 상당히 이식이 편리할것으로 생각됩니다.https://airflow.apache.org/docs/apache-airflow-providers-cncf-kubernetes/stable/kubernetes_executor.htmlHelm 차트를 활용할 수 있습니다.https://airflow.apache.org/docs/helm-chart/stable/index.html다만 Hadoop YARN 을 지원하지 않습니다.Airflow 를 활용하여 배치 플랫폼 구축이 용이 합니다.Airflow 에서는 Python 파일을 DAGS 경로에 넣어주면 읽히기 때문에 모듈화된 데이터 수집 프로세스를 쉽게 사용할 수 있도록 구성할 수 있습니다.https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html#distributed-airflow-architectureAirflow 는 API 관련 문서를 잘 정리해두기 때문에 스케줄링, Workflow, Task 들을 API 를 활용하여 관리하기 편리합니다.https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.htmlXCOM 을 통하여 Task 간 간단한 정보 전달이 용이 합니다.Pool 을 지정하여 더욱 타이트한 스케줄 자원 관리를 할 수 있습니다.Sensor 나 Trigger 를 활용하여 이벤트에 의한 배치 flow 를 구성할 수도 있습니다.https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/sensors.html#sensorshttps://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/deferring.htmlAirflow 아키텍처https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/plugins.htmlhttps://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html#distributed-airflow-architecturehttps://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html#separate-dag-processing-architectureAirflow 의 구성에 대해서 소개해 드리겠습니다.Airflow 는 3가지 형태로 구성할 수 있습니다.Basic Airflow deployment기본적으로 Airflow 를 설치할 때 필수로 구성되는 아키텍처 입니다.Apache Airflow 공식 문서 - Basic Airflow deploymentDistributed Airflow architecture흔히들 설치 시 많이 따르고 있는 아키텍처 입니다.Apache Airflow 공식 문서 - Distributed Airflow architectureSeparate DAG processing architectureDAG Processor 를 보안상의 이유로 별도로 분리한 아키텍처 입니다. 기존의 scheduler 에서 DAG 파일을 읽어 들였다면, 해당