AI 개발
AI 개발은 LLM을 실제 제품에 붙이는 엔지니어링 전반을 다룬다. 프롬프트 설계, 도구 호출, RAG, 평가, 비용·지연 관리까지 포함한다. 모델 호출 한 줄은 쉽지만, 환각 제어와 출력 신뢰성·재현성을 확보하는 데서 진짜 난이도가 나온다.
NVIDIA, 몇 가지 명령만으로 엣지 애플리케이션용 AI 모델 실행 가능하다고 소개
NVIDIA 기술 블로그는 개발자들이 몇 가지 명령만으로 엣지 애플리케이션 개발을 위해 AI 모델을 실행할 수 있다고 소개했다. AI는 데이터센터를 넘어 엣지로 확장되고 있으며, 개발자들은 운전자 주의 상태와 차량 내부 상황을 모니터링하는 에이전트, 로봇이 주변을 이해하고 작업을 계획하도록 돕는 에이전트, 생산 라인에서 기계 군을 조율하는 에이전트를 만들고 있다. 기사는 이러한 피지컬 AI 애플리케이션이 제한된 메모리, 전력, 지연 시간 예산 안에서 인지하고 추론하며 행동하는 모델에 의존한다고 설명한다.
NVIDIA Dynamo를 Kubernetes에서 검증된 런타임으로 구축하는 방법
NVIDIA Dynamo는 GPU 워커 전반에 걸쳐 모델 서빙을 조율하는 분산 추론 프레임워크다. 기사는 모델 구성에서 동작하는 추론 엔드포인트까지 반복 가능한 경로가 필요하다는 점을 짚는다. Kubernetes에 Dynamo를 배포하는 것은 첫 단계일 뿐이며, 성공적인 모델 배포를 위해서는 GPU 드라이버, 리소스 할당, 스케줄링, 네트워킹, 모니터링이 모두 제대로 동작해야 한다고 기사는 설명한다.
Supabase, 에이전트가 쓰기 좋은 백엔드 방향 발표: Docker 없는 로컬 런타임·선언형 스키마·Compute 알파
Supabase는 Docker 없이 로컬에서 백엔드를 실행하는 alpha 런타임, Git에 보관하는 선언형 스키마, 데이터베이스 옆에서 컨테이너를 돌리는 Supabase Compute(private alpha)를 공개했다. 에이전트가 백엔드를 읽고 수정할 수 있게 만든 변화로, 앱 생성부터 운영까지의 마찰을 줄이는 방향이다. Latent Space의 팟캐스트에서 Paul Copplestone과 Ant Wilson은 Supabase Select에서 발표한 Build, Operate, Scale 항목을 설명했다. 로컬 백엔드 실행에 Docker가 필요 없는 alpha 런타임, 데이터베이스 상태를 Git 파일로 기술하는 선언형 스키마, 데이터베이스와 같은 위치에서 청크 분할이나 임베딩 같은 장시간 작업을 돌리는 Compute가 핵심이다. 기사는 필자가 frontier AEO tracker로 확인했을 때 Astra부터 Fable, Muse까지 모든 frontier 모델이 앱 백엔드 첫 번째 선택으로 Supabase를 꼽았다고 전한다. Supabase는 하루 약 500만 개 규모의 데이터베이스를 만들고 있다고 밝혔으며, 에이전트 사용이 늘면 이 수치가 수십억 개 애플리케이션 규모로 커질 수 있다고 보고 있다. 기사는 OrioleDB, Multigres(private alpha), Turso 인수를 확장성 작업으로 소개했다. 또 AI 기반 사용이 늘면서 활성화와 전환율이 좋아졌다는 점을 두 창업자가 언급했다.
Vicki Boykis, DataPhilly 발표 슬라이드 공개: 임베딩 기반 검색·랭킹과 ONNX 추론 정리
Vicki Boykis가 DataPhilly 밋업에서 임베딩 기반 검색(retrieval)과 랭킹, 머신러닝 모델 아티팩트 생성과 추론을 주제로 30분간 발표했다. 발표 자료는 블로그에 슬라이드와 PDF로 공개됐다. 발표는 일반 모델과 소형 모델의 차이, 지연 시간(latency)과 ONNX 변환의 트레이드오프를 다뤘다. 청중은 무엇을 임베딩할 수 있는지, 추론을 직접 호스팅하는 것과 API를 쓰는 것의 장단점, 모델의 데이터와 아키텍처 중 무엇이 더 중요한지 등을 질문했다. Boykis는 2013년 같은 밋업에서 데이터 접근의 어려움에 대해 발표했으며, 이후 10년 이상 개발자로 일하며 직접 접근 패턴을 작성해 왔다고 밝혔다. 슬라이드는 블로그 페이지에 임베드돼 있고 PDF로도 내려받을 수 있다.
AI 시대의 시스템 사고: 엔지니어의 역할은 기술 수행에서 전문가 협업 조율로 확장된다
기사는 엔지니어가 AI 도구로 연구 검색, 설계안 생성, 시뮬레이션 테스트를 수행한 뒤 결과를 전문가에게 넘기는 협업 방식을 제시한다. 최종 판단과 책임은 여전히 사람에게 있으며, 엔지니어의 역할이 각 기술 단계 수행에서 사람·기계·전문가 지식의 결합 방식을 결정하는 쪽으로 넓어진다고 설명한다. 기사는 의료 기기 사례를 들어 설명한다. AI가 여러 센서 설계안을 만들고 각 설계의 성능을 예측하면, 엔지니어는 예측을 검증해 기술 요건을 어기는 설계를 제외한다. 이후 임상의가 실제 사용 가능성을 판단하고, 환자와 실무자가 엔지니어나 개발자가 놓친 문제를 드러낼 수 있다고 본다. 기사는 AI가 설득력 있는 답을 내놓아도 가정이 약하거나, 한 테스트에서만 동작하는 코드를 만들거나, 잘못된 목표로 설계를 최적화할 수 있다고 지적하며 사람의 전문성이 더 중요해진다고 강조한다. 기사는 IEEE가 여러 분야 전문가를 묶는 커뮤니티를 만들고, 임상 AI·복원력 있는 인프라·자율 시스템 같은 문제 중심 협업을 지원할 수 있다고 제안한다. 또한 AI 생성 결과를 언제 검증해야 하는지, 불확실성을 어떻게 기록하는지, 사람의 판단과 기계의 출력이 섞인 시스템에서 책임 주체가 누구인지에 대한 실무 표준이 필요하다고 덧붙인다.
AI 진단의 신뢰도는 AI에게 판단을 덜 맡기면서 높아졌다
AI 기반 웹페이지 진단 서비스가 같은 페이지에 매번 다른 점수를 내는 문제를 겪은 뒤, 진단 전체를 AI에게 맡기는 방식을 버렸다. 확인 가능한 사실은 코드가 판정하고, 판단이 필요한 항목만 AI가 맡도록 역할을 나눈 과정을 정리했다. 초기 버전은 진단을 AI에게 통째로 맡겼고, 같은 페이지를 세 번 돌렸을 때 72점, 85점, 61점이 나왔다. 이후 robots.txt, 태그, HTTPS, 모바일 대응처럼 사실로 확인할 수 있는 항목은 코드가 검사하도록 바꿨다. 다만 robots.txt 검사는 응답 코드 200만 보면 부족했다. 에러 페이지가 정상 응답으로 돌아오는 경우가 있어, 응답 내용이 실제 robots.txt나 사이트맵 형식인지까지 확인하도록 고쳤다. 전체 차단(Disallow: /) 뒤에 검색엔진별 허용 규칙이 이어지는 설정은 첫 줄만 보고 오판했다가 고객 피드백으로 바로잡았다. AI가 맡는 정성 평가에는 입력 통제와 출력 검증을 씌우는 하네스 구조를 적용했다. 판단 항목은 '전문가가 쓴 것 같은가'처럼 뭉뚱그린 질문 대신 '저자가 본문에 드러나 있는가', '주장에 출처가 붙어 있는가'처럼 좁은 질문으로 나눴다. 좁게 물어도 AI가 댓글 입력란의 닉네임을 저자로 잘못 집어온 사례가 있어, 탐색 범위를 제한하는 장치를 추가했다.
Ray Train DLC와 EFA로 EKS에서 분산 학습 구성하기
AWS가 CUDA, NCCL, EFA 스택과 Ray를 미리 묶어 배포하는 Ray Train Deep Learning Container(DLC)를 사용해, 이미지를 직접 빌드하지 않고 EKS에서 PyTorch 분산 학습 클러스터를 띄우는 방법을 소개한다. 학습 코드와 클러스터 매니페스트만으로 두 인스턴스 간 노드 통신을 EFA로 처리할 수 있다는 점이 핵심이다. 기사는 Qwen2.5-1.5B를 PyTorch Fully Sharded Data Parallel(FSDP)으로 미세 조정하는 예제를 다룬다. 구성은 g6.12xlarge 인스턴스 2대에 NVIDIA L4 GPU 8개이며, 제어 노드(m7i.xlarge)에서 KubeRay 오퍼레이터와 Ray head가 돌고 GPU 워커 노드 2대가 같은 가용 영역에 놓인다. KubeRay는 하나의 RayCluster 매니페스트에서 head 그룹과 worker 그룹을 만들고, 각 GPU마다 워커 하나씩 총 8개의 워커를 배치한다. 사용 이미지는 public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1 태그로, Ray 2.58.0, PyTorch 2.13.0, CUDA 13.0.2, NCCL 2.29.7, EFA 최신 버전과 AWS OFI NCCL 플러그인이 포함되어 있다. 인스턴스 간 집합 통신은 파드가 EFA를 요청하는 순간부터 EFA 경로로 흐른다. 기사는 같은 이미지가 KubeRay로 EKS에서 실행되든, EC2에서 직접 시작되든 동일하게 head와 worker 역할을 맡는다고 설명한다. 사용자가 추가하는 것은 인스턴스 종류, 파드당 GPU 수, NCCL이 쓸 네트워크 전송 방식, 작업에 필요한 Python 패키지 같은 설정뿐이며 모두 이미지 외부에서 지정한다. 샘플 저장소와 함께, 같은 KubeRay-on-EKS 기반을 쓰는 다중 노드 Ray Serve 예제도 링크되어 있다.
SageMaker SDK v3로 엣지 카메라별 컴퓨터 비전 모델을 대규모 관리하는 파이프라인
AWS가 공장 라인마다 여러 카메라에 각각 맞춘 컴퓨터 비전 모델을 대규모로 학습·평가·배포하는 샘플 파이프라인을 공개했다. 이 구조는 수천 개 모델을 사람이 일일이 관여하지 않고 운영해야 하는 품질 검사 환경의 문제를 다룬다. 이 샘플은 2023년 시리즈의 패턴을 최신 Amazon SageMaker Python SDK v3에 맞춰 갱신한 것으로, 지원 중단된 SageMaker Edge Manager 대신 Amazon SageMaker Neo로 엣지 최적화를 수행한다. 카메라 ID로 파라미터화된 13단계 SageMaker Pipeline이 카메라마다 이상 탐지용 합성곱 오토인코더와 결함 분류용 ResNet18 분류기를 함께 학습하고, 각 모델은 ONNX로 내보낸 뒤 평가와 품질 게이트를 통과해야 한다. 통과한 모델은 대상 엣지 장치용으로 SageMaker Neo 컴파일을 거쳐 SageMaker Model Registry에 등록된다. 동시 실행은 Amazon SQS FIFO 큐, AWS Lambda, AWS Step Functions, DynamoDB 세마포어로 제어되어 재학습 요청이 한꺼번에 몰리지 않고 일정한 속도로 처리된다. 완료와 실패 알림은 Amazon SNS로 전달되며, 전체 파이프라인을 합성 데이터로 한 번 돌리는 데 약 $0.07의 컴퓨팅 비용이 든다고 기사는 밝히고 있다. 배포는 AWS CDK로 수행하며 샘플 코드는 aws-samples GitHub 저장소에 공개되어 있다.
크롬 개발자 도구로 LLM이 보는 자바스크립트 페이지 디버깅하기
조너선 무어가 Search SEOul 2026에서 발표한 내용으로, 사용자가 보는 페이지와 LLM이 받아 가는 페이지의 차이를 크롬 개발자 도구로 찾는 방법을 다룬다. 안드레 알파의 테스트에 따르면 ChatGPT·Claude·Gemini 등 여러 AI 어시스턴트는 자바스크립트를 렌더링하지 않는 것으로 나타났다. 발표는 소스 보기(View Source)와 DOM의 차이를 기본 개념으로 삼는다. 소스 보기는 서버가 처음 브라우저로 보내는 원본 HTML이고, DOM은 자바스크립트 실행 후 브라우저가 표현하는 페이지다. 이 둘을 비교하면 자바스크립트에 의존하는 콘텐츠가 어디서 빠지는지 확인할 수 있다. 렌더링 방식으로는 서버 사이드 렌더링(SSR) 등이 소개됐으며, 페이지 제목·메타 디스크립션·H1 같은 요소가 서버에서 바로 전달되는지를 점검 대상으로 제시했다. 발표자는 자바스크립트 자체보다 자바스크립트가 실패 지점이 되는 문제를 강조했다. 구글은 자바스크립트를 처리한다고 안내해 왔지만 LLM은 그렇지 않을 수 있다는 것이 핵심 문제 제기다. 발표는 두 편으로 나뉘며 이번 1회에는 배경, 디버깅 원칙, 크롬 개발자 도구 세팅과 텍스트 검색까지 다뤘다.
LLM 대응 자바스크립트 디버깅 2편: 요청 필터·차단으로 페이지를 무너뜨리는 파일 찾기와 AI처럼 접속해 보기
조너선 무어는 서치 서울 2026 발표를 두 편으로 나눈 2편에서, 네트워크 탭의 필터와 요청 차단으로 페이지 렌더링을 깨뜨리는 파일을 찾는 방법을 설명했다. 1편에서 다룬 원본 HTML과 DOM 비교의 나머지 세 단계를 이어서 소개한다. 네트워크 탭에서는 domain: 와일드카드 필터로 특정 도메인의 요청만 걸러 자사 도메인과 서드파티 리소스를 구분할 수 있고, 반전(Invert) 체크박스로 조건의 반대를 볼 수 있다. Ctrl 클릭으로 Fetch/XHR, 문서(Doc), 자바스크립트(JS) 등 MIME 유형을 여러 개 함께 선택할 수 있다. 요청은 URL 또는 도메인 단위로 차단할 수 있고, 명령어 메뉴의 요청 조건(Request conditions) 서랍에서 직접 입력해 막을 수도 있다. 저자는 페이지를 하이드레이션하는 GraphQL 파일(queries.gql)을 차단하자 상품 콘텐츠가 사라졌다고 보고했다. 요청 이니시에이터 체인과 Shift 키를 이용한 의존성 트리 하이라이트로 리소스 간 연결 관계도 확인할 수 있다고 설명했다. 기사는 콘텐츠가 빠진 페이지를 클로드나 챗GPT가 가져갈 경우 같은 상황이 된다고 본다고 적었다. 요청이 수백 개일 때는 의존성 트리가 한 화면에 다 보이지 않는다는 점도 함께 언급했다.
NVIDIA GPUDirect Storage로 Python에서 데이터를 GPU 메모리에 읽는 방법
NVIDIA 기술 블로그는 GPU 애플리케이션이 점점 커지는 데이터셋을 처리하고 있다고 소개한다. 기사에 따르면 2025 Stanford AI Index 기준 주목할 만한 AI 모델의 컴퓨팅 양은 약 5개월마다, LLM 학습 데이터셋의 크기는 약 8개월마다 두 배로 늘고 있다. 연산과 데이터가 함께 커지면서 스토리지에서 데이터를 효율적으로 옮기는 일이 중요해졌다는 것이 기사의 출발점이다.
AWS CDK로 SageMaker AI 엔드포인트 오토스케일링 자동 오케스트레이션하기
SageMaker AI 실시간 엔드포인트의 인스턴스 타입·개수·환경 변수를 바꾸면 CloudFormation이나 AWS CDK 배포가 실패하는 문제를 다룬다. 기사는 오토스케일링 등록 해제와 재등록을 엔드포인트 업데이트 전후에 자동으로 수행하는 재사용 가능한 CDK 컨스트럭트를 소개한다. 기사는 등록된 스케일러블 타깃이 있는 상태에서 엔드포인트를 업데이트하면 SageMaker AI가 "must be deregistered as scalable targets with Application Auto Scaling" 오류로 업데이트를 거부한다고 설명한다. 수동으로 AWS CLI로 등록을 해제한 뒤 설정만 바꾸면 배포는 성공하지만 CloudFormation이 오토스케일링을 다시 등록하지 않아 엔드포인트가 오토스케일링 없이 실행될 수 있다고 지적한다. 또 등록을 해제한 상태에서 오토스케일링 파라미터를 바꾸면 존재하지 않는 ScalableTarget 리소스를 갱신하려다 UPDATE_ROLLBACK_FAILED가 발생해 콘솔에서 수동 복구가 필요해진다고 밝힌다. 해결책은 네이티브 AWS::ApplicationAutoScaling::ScalableTarget과 ScalingPolicy 리소스를 세 개의 커스텀 리소스로 대체하는 것이다. 순서는 등록 해제, 엔드포인트 업데이트(CDK 관리), 엔드포인트가 InService가 된 뒤 스케일러블 타깃 등록, 조회 가능해진 뒤 타깃 트래킹 정책 적용이다. 스케일러블 타깃 등록은 1시간, 정책 적용은 15분의 total_timeout 안에서 30초 간격으로 완료 여부를 확인하며, ConfigHash 속성은 설정값이 바뀔 때 Lambda를 다시 호출하게 한다.
Flint-interactive, 에이전트가 만든 차트를 클릭·필터·줌으로 탐색하게 하는 인터랙티브 시각화 언어
Microsoft Research가 공개한 Flint-interactive는 AI 에이전트가 생성한 데이터 시각화를 사용자가 클릭, 필터링, 줌, 하이라이트, 차트 간 상호작용으로 직접 탐색할 수 있게 하는 언어다. 저수준 시각화 코드 없이 고수준 의미 이벤트와 업데이트 연산자로 상호작용을 정의할 수 있다는 점이 핵심이다. Flint-interactive는 Flint 위에서 동작하는 인터랙티브 데이터 시각화 언어다. Flint 컴파일러가 사용자 선택을 그 의미를 담은 시맨틱 이벤트로 변환하고, 고수준 연산자가 이 이벤트에 맞춰 시각화를 갱신한다. 상호작용과 시각 요소 사이의 의존성 처리를 컴파일러가 맡아, 사용자나 에이전트는 고수준 명세만으로 복잡한 상호작용을 기술할 수 있다. 채팅 환경에서는 Flint-MCP와 MCP Apps를 통해 사용하며, 릴리스 기준으로 에이전트가 Flint 차트 명세와 함께 interaction_spec을 생성해 대화창에 인터랙티브 차트를 렌더링한다. 앱 개발자는 Flint Interactive Canvas에서 이벤트 핸들러로 시맨틱 이벤트를 받아 테이블 필터링이나 다른 차트 갱신, 애플리케이션 상태 변경을 처리할 수 있다. Flint의 프리셋을 넘어서는 상호작용은 트리거와 사용자 정의 핸들러 함수로 작성하며, 예시로 클릭한 국가를 강조하고 이름을 라벨로 표시하는 동작이 제시되었다. 기사는 기존 방식의 한계로 높은 생성 비용과 신뢰성 문제를 든다. 에이전트는 한 번의 턴으로 만족스러운 인터랙티브 시각화를 거의 만들지 못하고, 추론·코딩·디버깅을 여러 차례 반복하며 토큰과 시간을 소모한다. 또한 복잡한 인터랙티브 차트는 레이아웃이나 상호작용이 쉽게 깨지며, 이를 고치는 과정에서 새 문제가 생길 수 있다고 설명한다. 일부 시각화 라이브러리의 내장 상호작용은 맞춤형 차트를 만들기에 충분히 표현적이지 않다는 점도 함께 언급되었다.
엔터프라이즈 AI 경쟁력은 모델 선택보다 서빙 하네스 설계에 달려 있다
엔터프라이즈 AI의 다음 경쟁 우위는 어떤 모델을 고르느냐보다 모델 주변에 무엇을 구축하느냐에 있다는 주장이 제기됐다. 운영 단계에서는 지연 시간, 동시성, 메모리 압박, GPU 활용률, 인프라 비용 같은 제약이 성능을 좌우하기 때문이다. 기사는 아키텍처, 메모리 관리, 스케줄링, 최적화 결정을 포함한 모델 주변의 엔지니어링 시스템을 서빙 하네스로 정의한다. 기사에 따르면 워크로드가 제약 조건을 정하고 그 제약이 아키텍처를 결정해야 하며, 최적화 전에 먼저 측정하고 지배적인 병목을 찾아 해결한 뒤 결과를 다시 측정하라고 권한다. 예로 추론 시 KV 캐시가 활성 요청과 컨텍스트 길이에 따라 커져 컴퓨트 여유가 있어도 GPU 메모리가 부족해질 수 있다는 점을 들었다. 양자화, 추측 디코딩, 최적화된 어텐션 같은 기법도 병목을 제거하는 데 필요한 경우에만 적용하라고 설명한다. 기사는 오늘의 최고 모델이 곧 대체될 것이므로 서빙 구조가 모델과 하드웨어 변화를 흡수할 수 있어야 한다고 강조한다. 이 경우 모델 교체는 아키텍처 재구축이 아니라 평가와 설정 변경으로 처리할 수 있다. 기사는 이 내용을 EXL의 Engineering the Harness 시리즈에서 더 깊이 다룬다고 소개하며, EXL이 작성한 콘텐츠라는 점을 명시했다.
GitHub, 저장소 쓰기 잠금을 참조 단위로 바꿔 Azure 이전 및 처리량 향상
GitHub가 저장소 전체 단위로 걸리던 쿼럼 잠금을 개별 참조(reference) 단위로 좁혀, 가장 바쁜 저장소까지 Azure로 옮길 수 있는 다리 구조를 공개했다. 이 변경으로 서로 다른 참조에 대한 쓰기가 동시에 진행될 수 있게 되어 저장소의 쓰기 처리량 상한이 올라간다. 기존 쿼럼은 쓰기 하나를 커밋할 때 정상 복제본 전부의 응답(타임아웃까지)을 기다리고 쓰기 동안 저장소 전체에 잠금을 걸었다. 두 지역 사이의 왕복 지연이 약 25ms라 가장 느린 복제본이 모든 쓰기의 지연과 처리량 상한을 정했다. 이를 참조별 직렬화로 바꾸면 서로 다른 브랜치에 대한 쓰기는 기다리지 않고 동시에 진행된다. 내부 테스트에서 실제에 가까운 트래픽으로 측정했을 때 서로 다른 참조에 대한 쓰기 처리량이 3~4배 높았고 지연은 더 낮았다. 기사에 따르면 대부분 저장소는 읽기가 쓰기보다 100~1,000배 많다. 저장소 데이터를 Azure Blob Storage에 내구성 있게 저장하고 쓰기마다 갱신하면, 읽기 트래픽을 쓰기 쿼럼에서 분리해 각각 따로 확장할 수 있다고 설명했다.
2026년 브라우저 밖 JavaScript 동향: Node.js 연 1회 릴리스 전환, Deno·Bun 인수, npm 공급망 공격 대응
네이버 D2 연재 2편은 2019년 이후 7년간 브라우저 밖 JavaScript 생태계의 변화를 정리했다. Node.js는 연 1회 릴리스로 일정을 바꾸기로 했고, Deno와 Bun은 각각 Cloudflare와 Anthropic에 합류했다. 2019년 글에서 Node.js 12.13이던 최신 버전은 2026년 10월 기준 26.12로 메이저 버전이 열네 번 나왔다. 기사는 Node.js가 TypeScript 파일을 바로 실행하고, 테스트 러너와 SQLite, WebSocket 클라이언트를 내장하며, 권한 모델로 파일과 네트워크 접근을 제한한다고 소개한다. 패키지 생태계에서는 2020년 GitHub의 npm 인수 이후 2025년부터 chalk, debug 등 메인테이너 계정 탈취와 Shai-Hulud 웜 같은 공급망 공격이 주요 문제가 되었고, npm과 pnpm은 설치 스크립트를 기본으로 실행하지 않도록 바꾸었다. 2026년 10월 Deno 팀의 Cloudflare 합류로 Deno 런타임 개발은 1년간 보안 업데이트 후 종료되며, Deno Deploy는 6개월 뒤 종료된다. Bun 1.4와 pnpm 12는 2026년 8월 각각 Rust로 재작성되었고, npm 12는 2026년 7월 설치 스크립트 기본 미실행 정책을 도입했다.
Xolotl 기반의 DeepSeek-V4.1-Flash 엔진 성능
Xolotl은 Strata 기반의 추론 엔진으로, DeepSeek-V4.1-Flash(552B)를 단일 RTX 4090에서 실행한다. 이 시스템은 27 tok/s의 디코드 속도와 180-320 tok/s의 프리필 속도를 제공하며, 512K의 컨텍스트를 지원한다. 또한, GLM-5.3-Flash, Qwen3.8-Flash-Next 및 Qwen3.8-27B도 실행 가능하다. 현재 uncensored V4.1(152 GiB) 양자화 버전이 있으며, 새로운 DeepSeek-V4.1-Flash-1017 업데이트를 다운로드 중이다.
Sam Newman의 Building Resilient Distributed Systems 출간 및 재난 복구 전략
Sam Newman이 저술한 'Building Resilient Distributed Systems'는 소프트웨어 엔지니어들에게 중요한 주제를 다룬다. 이 책은 재난 복구(DR) 절차, 클라우드 지역 및 데이터 센터에서의 재난 대응 전략, 복구 지점 목표(RPO) 및 복구 시간 목표(RTO)와 같은 구체적인 목표 설정 방법을 제시한다. 또한 AI 기반 소프트웨어의 회복력, 모델 제공자의 회복력, 불확실성 처리 방법에 대해서도 논의한다. DR 전략을 수립할 때 비용과 복잡성을 고려해야 하며, 다양한 DR 옵션을 통해 시스템에 적합한 접근 방식을 선택해야 한다.
Epic Games, 디즈니 게임 개발에 AI 활용
Epic Games는 발표되지 않은 디즈니 게임의 코드와 아트를 생성하기 위해 AI를 사용할 계획이다. 이 게임은 원래 3월 출시 예정이었으나 지연되었다. 개발자들은 'AI 우선' 지침을 받아 Anthropic의 Claude와 같은 도구를 사용해야 하며, 모든 아트워크는 '완전한 AI 워크플로우'로 생성될 예정이다.
핸즈온 머신러닝 with 사이킷런. 파이토치 출간
오렐리앙 제롱의 『핸즈온 머신러닝 with 사이킷런. 파이토치』가 한빛미디어에서 2026년 9월 28일 출간되었다. 이 책은 머신러닝의 기본 원리부터 트랜스포머, LLM, 멀티모달까지 실제 코드를 통해 구현하며 현대 AI 기술의 흐름을 이해하도록 돕는다. 기초 개념과 최신 기술을 체계적으로 연결하여 AI의 원리를 깊이 있게 학습할 수 있도록 구성되어 있다.
Hive Metastore에서 get_table RPC 복원 과정
네이버의 Hadoop 플랫폼 C3에서 Hive Metastore를 Apache Hive 4.2 기반으로 업그레이드하는 과정에서 Spark 잡이 'Invalid method name: 'get_table'' 오류로 실패하는 현상이 발생했다. 이 문제는 Thrift RPC의 메서드 이름 기반 디스패치 방식과 Hive와 Spark 간의 버전 호환성 문제로 인해 발생했으며, 이를 해결하기 위해 get_table RPC를 복원하는 과정을 다루고 있다. 코드 변경은 IDL 두 줄과 서버 구현 몇 줄로 이루어졌지만, Thrift RPC의 동작 방식 이해가 중요하다.
AI 작업 부하를 위한 GPU 클러스터 준비 상태 검증
GPU 클러스터는 모든 건강 검사를 통과하더라도 AI 작업 부하를 실행하지 못할 수 있다. 모든 GPU, 네트워크 링크, 포드가 건강하다고 보고하더라도, 512-GPU 훈련 작업이 저조한 성능을 보이거나 실패할 수 있다. 이는 느린 GPU, 부하에서 저하되는 링크, 또는 느린 경로로 트래픽을 조용히 라우팅하는 구성 때문일 수 있다.
Amazon EKS에서 NVRx를 이용한 내결함성 분산 훈련
대규모 분산 훈련 작업은 여러 노드에서 수 시간 또는 수일 동안 실행되며, 이 과정에서 네트워크 분할, 메모리 오류, 소프트웨어 예외 등이 발생할 수 있다. NVIDIA Resiliency Extension (NVRx)을 PyTorch Fully Sharded Data Parallel (FSDP) 훈련에 통합하여 비동기 체크포인팅, 프로세스 내 재시작, 작업 내 재시작 기능을 제공한다. Amazon EKS는 관리형 Kubernetes 서비스로, p5.48xlarge 인스턴스에서 NVIDIA H100 GPU를 사용하여 훈련 작업을 수행한다.
토스증권의 GPU-native 클러스터 구축 과정
토스증권은 Kubernetes 기반의 GPU 클러스터를 구축하여 GPU-aware 상태에서 GPU-native 상태로 발전시켰다. GPU-aware 상태는 쿠버네티스가 GPU를 자원으로 인식하고 할당하는 것이며, GPU-native 상태는 GPU의 정상 여부를 판단하고, 검증된 노드만 워크로드를 받게 하며, 서비스에 필요한 단위로 자원을 나누고 배치할 수 있는 조건을 갖춘 상태를 의미한다. 이를 위해 NVIDIA 커널 드라이버, NVIDIA Container Toolkit, NVIDIA Device Plugin 등을 활용하여 GPU를 쿠버네티스의 스케줄링 대상으로 만들었다.