LLM 기술 블로그 최신 글

LLM 관련 최신 기술 블로그 글

• [기술 가이드] Kubernetes의 핵심 변화: DRA를 통한 GPU 자원 동적 할당

  kt cloud Container Service팀 박지선 님 요약 SUMMARY 이 글에서는 Kubernetes 1.34에서 GA로 전환된 DRA를 중심으로 GPU 자원 동적 할당과 ResourceClaim 활용 방법을 다룹니다. CDI 기반 장치 주입과 MIG 연계 방식 등 GPU 운영에 필요한 주요 변화를 정리합니다. #Kubernetes #DRA #GPU스케줄링 #ResourceClaim #CDI AI/ML 워크로드가 기업 인프라의 핵심으로 자리 잡으면서, GPU 자원을 얼마나 효율적으로 스케줄링하고 관리하느냐가 경쟁력의 척도가 되고 있습니다. Kubernetes 1.34(2025년 8월 출시)는 바로 이 지점에서 중요한 전환점을 마련했습니다. Kubernetes 1.34 버전 릴리스의 주요 enhancement 중 하나는 DRA(Dynamic Resource Allocation)의 GA 승격입니다. 기존 Device Plugin 방식의 정적이고 경직된 GPU 할당 방식에서 벗어나, 이제는 "메모리 20GB 이상의 GPU 아무거나 주세요" 와 같이 조건 기반의 유연한 자원 요청이 가능해졌습니다. 이는 LLM 학습, 추론 서비스, 멀티테넌트 GPU 공유 등 다양한 시나리오에서 운영 효율을 획기적으로 높여줍니다. 또한 지난 2026년 3월 KubeCon Europe에서 NVIDIA는 GPU용 DRA 드라이버를 CNCF에 기증하며 커뮤니티 주도의 GPU 오케스트레이션 생태계로의 전환을 공식화했습니다. 이 포스팅에서는 Kubernetes 1.34에서 GPU 관련 변화에 대해 자세히 살펴보겠습니다. 핵심 변화 Kubernetes 1.34 에서 본격적인 Feature 변경사항에 대해 설명합니다. 변화 1: DRA (Dynamic Resource Allocation) - 드디어 GA [DRA란?] DRA(Dynamic Resource Allocation) 는 resource.k8s.io API 그룹 기반의 Kubernetes 프레임워크입니다. ResourceClaim 이나 ResourceClaimTemplate 리소스를 생성하여 여러 GPU 자원 중 NVLink로 묶인 자원만 Pod에 할당하거나, Pod가 실행될 때만 GPU를 동적으로 예약하는 등 보다 유연하게 활용할 수 있는 특장점을 가집니다. DRA Driver 사용 시 Kubernetes v1.34.2 이상을 사용하세요. v1.34.0/v1.34.1에는 알려진 이슈가 있습니다. ResourceClaim / ResourceClaimTemplate ResourceClaim은 특정 Pod가 실행되기 위해 필요한 하드웨어 자원의 구체적인 명세와 예약 현황을 기록하는 객체이며, ResourceClaimTemplate은 이 ResourceClaim을 동적으로 자동 생성하기 위해 미리 정의해 둔 템플릿입니다. ResourceClaim 과 Pod는 1:1 바인딩되며 GPU 자원을 락(Lock)을 걸어, Pod에만 독점합니다. Deployment나 StatefulSet 아키텍처에서는, ResourceClaimTemplate 을 사용하여 Pod replicas 변화될때 마다 자동으로 ResourceClaim 복제본이 생성되도록 사용할 수 있습니다. [DRA 사용 방법] DeviceClass 확인 NVIDIA GPU Operator 를 설치하면 nvidia.com/gpu 이름의 DeviceClass가 자동 생성됩니다. # kubectl get deviceclasses apiVersion: resource.k8s.io/v1 kind: DeviceClass metadata: name: nvidia.com/gpu spec: selectors: - cel: expression: device.driver == "gpu.nvidia.com" ResourceClaim 리소스를 생성 사용자가 이 DeviceClass를 사용하는 ResourceClaim 또는 ResourceClaimTemplate 을 생성합니다. 다양한 조건 기반으로 GPU 자원 할당을 요청합니다. # 16GiB 이상 메모리를 가진

  기술 블로그 (Tech) | kt cloud2026년 11월 4일

• [기술 분석] Ampere부터 Vera Rubin까지, GPU 진화가 바꾼 북미 AIDC 인프라

  kt cloud DC글로벌고객팀 심재문 님 요약 SUMMARY 이 글에서는 NVIDIA GPU가 Ampere부터 Vera Rubin으로 진화하면서 북미 AI 데이터센터의 전력 밀도와 배전·액체냉각 인프라를 어떻게 변화시켰는지 다룹니다. 고밀도 GPU 환경에 필요한 인프라 설계 방향과 설비 노후화 리스크를 정리합니다. #NVIDIA #GPU로드맵 #AIDC #전력밀도 #액체냉각 1. 실리콘의 한계가 인프라의 임계점으로 Image: AI-Generated Content 무어의 법칙(Moore's Law)이 종말을 고하고, 단일 칩 수준의 미세 공정 전환 속도가 둔화함에 따라 반도체 업계는 다이(Die)를 쪼개어 붙이는 칩렛(Chiplet) 구조와 극단적인 가속 컴퓨팅 아키텍처로 방향을 선회했습니다. 이 변화의 최전선에 서 있는 하드웨어가 바로 거대언어모델(LLM)과 생성형 AI 연산의 심장인 GPU입니다. 하지만 트랜지스터 밀도의 수직 상승과 다이 사이즈의 확장은 필연적으로 칩 한 개가 소모하는 열설계전력(TDP)의 폭발적인 증가를 수반했습니다. 이러한 실리콘 수준의 로드맵 변화는 소프트웨어를 담는 단순 부동산 공간이었던 과거의 데이터센터를, 하드웨어와 고전압 전력 공학 및 열역학이 유기적으로 결합된 시스템 엔지니어링 룸인 'AI 데이터센터(AIDC)'로 진화시켰습니다. 특히 전 세계 하이퍼스케일 트렌드를 선도하는 북미 시장의 글로벌 CSP(Cloud Service Provider) 및 빅테크 기업들은 수만 장의 GPU를 하나의 거대한 가속기 풀(Pool)인 초거대 클러스터로 묶는 과정에서 기존 공랭식 인프라가 가진 물리적 법칙의 한계에 직면하게 되었습니다(U.S. Department of Energy, 2026). 2. GPU 가속 로드맵과 랙당 전력 밀도의 상관관계 지난 수년간 엔비디아가 발표한 GPU 아키텍처의 세대별 변화를 분석해 보면, 데이터센터 인프라 엔지니어들이 마주한 '전력 밀도'와 '발열량'의 압박이 얼마나 급격하고 파괴적인 속도로 진행되었는지 명확히 파악할 수 있습니다. GPU 세대 (아키텍처) 대표 모델 출시(예정) 단일 GPU 최대 TDP 표준 서버 랙당 전력 밀도 지배적인 냉각 아키텍처 Ampere A100 2020년 400W 10 kW ~ 15 kW 일반 공랭식 (Air-Cooled, 항온항습기 중심) Hopper H100 / H200 2022~2024년 700W ~ 1,410W 30 kW ~ 40 kW 하이브리드 (공랭 + RDHx 후면 냉각 코일) Blackwell B200 / B300 2024~2025년 1,020W ~ 1,200W 60 kW ~ 100 kW (NVL72) 직접액체냉각 (DLC, Direct-to-Chip) 표준 필수화 Rubin Vera Rubin 2026년 (예정) 1,500W+ 추정 120 kW ~ 140 kW 고도화된 DLC + 루프형 다중 매니폴드 체계 Rubin Ultra Rubin Ultra 2027년 (예정) 1,800W+ 추정 150 kW+ 이상 액침 냉각(Immersion Cooling) 및 특수 유체 냉각 2.1 Ampere에서 Hopper로: 공랭 엔지니어링의 구조적 종말 2020년 도입된 Ampere 아키텍처 기반의 A100 GPU는 단일 칩 기준 TDP가 최대 400W 수준으로, 보편적인 8Way 서버 설계 시 랙당 전력 소모량이 10kW에서 15kW 내외에 머물렀습니다. 이는 기존 하이퍼스케일 데이터센터가 전통적으로 채택해 온 차가운 공기와 뜨거운 공기를 물리적으로 격리하는 컨테인먼트(Aisle Containment) 구조와 고풍량 바닥 공조 시스템을 통해 충분히 방열할 수 있는 상한선이었습니다. 그러나 Hopper(H100/H200) 세대에 이르러 상황은 반전되었습니다. 단일 칩의 TDP가 700W로 두 배 가깝게 급증했고, 고대역폭 메모리(HBM3)와 초고속 Interconnect 아키텍처가 단일 서버 섀시에 밀집되면서 랙당 요구 전력이 30kW에서 40kW에 육박하게 되었습니다. 기체인 공기는 비열과 열전도율이 극도로 낮기 때문에, 40kW

  기술 블로그 (Tech) | kt cloud2026년 11월 4일

• [5편] 숫자가 정답이 아닐 때, 결국 사용자를 만나야 알 수 있습니다

  WORXPHERE 채용 지원 UT의 가설 세 개와 가설 밖 발견 세 개 안녕하세요. 잡플래닛에서 채용 지원 영역을 맡고 있는 6년차 프로덕트 디자이너 송인경입니다. 이번 글은 우리 팀이 연속 지원과 AI 이력서 매핑, 두 축에서 세 개의 가설을 기반으로 사용자를 만난 기록입니다. 결과만 먼저 공유드리면, 가설 두 개 중 둘은 기각되었고 하나만 조건부로 남았습니다. 대신 예상하지 못한 발견을 안고 돌아왔습니다. 정량 데이터가 가리키는 방향과 사용자가 실제로 원하는 방향이 다를 수 있다는 것을, 아홉 번의 인터뷰로 다시 배운 사흘이었습니다. 검증에 쓴 프로토타입은 Claude로 직접 만들어 GitHub Pages에 배포했습니다. 그 과정은 [2편] 코드 못 짜던 디자이너가, 네 프로젝트를 깃허브 저장소 하나로 합친 기록에서 자세히 다뤘으니 궁금하신 분은 2편을 봐주세요. 시작은 깔끔한 데이터 한 줄이었습니다 지원을 완료하고 10분 안에 다른 공고의 ‘지원하기’ 버튼을 누르는 사용자가 약 40% 였습니다. 채용 영역 중 어디부터 개선하면 좋을 지 지표를 훑다가 눈에 들어온 숫자였습니다. “사용자가 이미 연속 지원을 하고 있으니 연속 지원을 더 쉽게 해주면 더 많이 지원하지 않을까?” 생각은 자연스럽게 그쪽으로 흘렀습니다. 그렇게 가설을 세 개 세웠습니다. H1은 연속 지원, H2는 이력서 작성 부담을 줄이는 두 가지 접근(H2‑1, H2‑2)으로 나눴습니다. H1. 사용자는 지원을 완료한 뒤, 유사한 공고를 추천해주면 이어서 여러 군데 지원할 것이다. H2‑1. AI가 타사 혹은 가지고 있는 기존 이력서를 기반으로 자동으로 작성해주면, 잡플래닛에서도 이력서를 새로 작성할 것이다. (전제 조건: 새 이력서 작성에대한 부담감이 있을 것이다) H2‑2. 이력서 폼에서 필수와 선택 항목을 시각적으로 한눈에 구분해주면, 어디까지만 작성하면 되는지 빠르게 파악해 입력 부담이 줄 것이다. 채택 기준은 인터뷰 전에 미리 정해두었습니다. 9명 중 7명 이상이면 검증, 4~6명이면 조건부 채택, 3명 이하면 재설계로 판단하기로 했습니다. 결과를 본 뒤 기준을 바꾸는 일을 막기 위해서였습니다. 참여자는 이직이 급한 사람을 중심으로 모집했고, 긴급 7명과 비긴급 2명, 총 9명을 만났습니다. 그런데 가설이 뒤집혔습니다 첫 번째 가설은 9명 중 1.5로 연속 지원 40%라는 기존 데이터가 무색해졌습니다. 9명 중 7명이 거의 같은 이유로 거절했기 때문입니다. “진짜 막 지원할 때 아니고는, 첫 문장이라도 바꿔서 이력서를 다시 내려고 해요.” (P1, PM) “공고마다 직무 이름이 달라서 맞춰서 내요. 같은 이력서로 여러 군데를 어떻게 내지? 싶어서 저는 그냥 패스.” (P2, UX 리서처) “각각의 JD에 맞는 내용을 이력서에 넣어야 되기 때문에 똑같은 이력서로 연속 지원은 안 할 것 같아요.” (P4, 전략 기획) 여기서 알게 됐습니다. 40%는 ‘다시 지원하는 행동’의 숫자였지, ‘같은 이력서로 다시 지원하고 싶다’는 의향의 숫자는 아니었습니다. 사용자를 직접 만나지 않았다면 몰랐을 겁니다. 데이터만 봐서는 알 수 없는 이야기였으니까요. ‘방금 낸 이력서를 그대로 쓴다’는 건 우리 팀의 생각이었을 뿐, 사용자에게는 당연한 일이 아니었습니다. 화면 앞에서 머뭇거리는 모습을 보고 나서야 알았습니다. ‘AI 이력서’라는 단어가 만든 또 다른 오해 H2‑1, AI 이력서 매핑도 예상 밖이었습니다. 5명은 이력서 작성 화면에 진입조차 하지 않았습니다. “AI 이력서 채우기 기능이 있는 건 좋지만, 작성 페이지까지 넘어와서 이 여정을 시작하진 않을 것 같아요.” (P1) “이미 만들어 놓은 이력서가 있으니까, 여기서 새로 만들 필요가 없다고 느껴져요.” (P8) 힌트는 P8의 “여기서 만들 필요가 없다”는 말이었습니다. 우리는 기존 이력서를 그대로 불러올 수 있도록 설계했는데, 사용자는 새로 작성하는 기능으로 인지하고 진입 자체를 포기한 셈입니다. 진입한 4명 중 3명이 긍정적으로 반응했지만, 모두 조건을 달았습니다. 매칭률이 70%나 100%처럼

  worxphere-tech - Medium2026년 11월 3일

• 국내 최초 광고 MCP를 출시하며, 개발자의 역할은 어디까지 넓어졌을까?

  안녕하세요. 당근 광고실 광고주플랫폼팀에서 백엔드 엔지니어로 일하는 제이크(Jake)예요. 얼마 전 저희 팀 엔지니어링 매니저 Iltaek이 프론트엔드와 백엔드를 한 팀으로 합친 이야기를 글로 나눴어요. 그 글이 팀의 경계를 넘어 일하는 이야기였다면, 이번 글은 제가 당근 광고 MCP를 만들며 개발자의 역할을 넓혀 본 이야기예요. MCP(Model Context Protocol)는 AI 서비스가 외부 서비스의 데이터를 불러올 때 쓰는 표준 연결 방식이에요. 광고주가 Claude 같은 AI 서비스에 “지난주 광고 성과 어땠어?”라고 물으면, AI가 광고 MCP를 거쳐 당근 광고의 계정 정보와 광고 정보, 성과 데이터를 가져와서 답해 줘요. 해외 광고 플랫폼에서는 구글, 메타, 아마존이 이미 MCP를 공개했고, 국내에서는 당근이 처음으로 공식 광고 MCP를 출시했어요. 저는 개발자로 이 프로젝트에 참여하는 줄 알았는데, 하다 보니 로드맵과 PRD부터 출시까지 맡아야 했어요. 이 글에서는 그 과정에서 겪은 일과, 제가 일하는 방식이 어떻게 달라졌는지 이야기해 보려고 해요. 로드맵과 PRD를 처음 써 봤어요 그동안은 PM과 함께 일하면서 엔지니어로서 개발에 필요한 의견을 나누고, PRD를 어떻게 구현할지 고민했어요. 그런데 이번에는 Iltaek에게 로드맵과 PRD까지 맡아 달라는 요청을 받았어요. 솔직히 요청을 받았을 때는 “이것도 개발자인 내 일인가?” 싶었어요. 로드맵은 PM이 그리는 거 아닌가, 내가 로드맵을 제시하는 게 맞나 하는 생각이 먼저 들었어요. 해 본 적 없는 일이라 부담도 됐고요. 그때 Iltaek이 오너라는 마음가짐으로 해 보라고 했어요. 그 말대로 “내 프로젝트”라고 생각하다 보니, 이 프로젝트를 더 잘되게 하려면 뭘 해야 할지 고민하게 되더라고요. 스스로 던지는 질문부터 달라졌어요. 로드맵을 그리려고 하니, 당근 광고 플랫폼은 생각보다 크고 복잡했어요. 전문가모드, 간편모드, 대행사 플랫폼¹까지 합치면 광고주가 할 수 있는 일이 정말 많아요. 광고 보고서, 광고 수정, 소재 만들기, 타겟팅, 전환 추적, 결제와 충전까지요. 이걸 한 번에 다 MCP로 열 수는 없어서, 범위를 좁혀야 했어요. 혹시나 잘못되더라도 광고주에게 손해가 없는 일인지, 화면보다 AI로 했을 때 더 편한 일인지, 더 많은 광고주에게 도움이 되는 일인지, 이렇게 세 가지 기준을 세워 봤어요. 그래서 리스크가 가장 낮은 조회 기능부터 열었어요. 광고를 수정하는 기능은 충분히 검증한 뒤에 열기로 했어요. AI가 예산이나 입찰가를 바꾸다 실수하면 광고비가 의도와 다르게 나갈 수 있어서요. 결제나 광고 삭제처럼 AI로 하는 게 오히려 불편하거나 위험한 일은 아예 열지 않기로 했어요. 그리고 당근 광고에서 가장 많이 집행되는 디스플레이 광고부터 시작했어요. 그렇게 로드맵을 그리고, 그 안에서 이번에 할 일의 범위를 정했어요. 그다음 저희 팀에서 쓰는 PTBSMAF라는 프레임워크로 PRD를 썼어요. 문제 정의(Problem Statement), 트레이드오프(Trade-off), 벤치마크(Benchmark), 해결책(Solution), 지표(Metrics), 중단 조건(Andon), 피드백 루프(Feedback Loop)의 앞 글자를 딴 이름이에요. 그중에서도 문제 정의, 트레이드오프, 벤치마크가 특히 도움이 됐어요. 문제를 제가 이해한 대로 풀어 쓰다 보니 생각이 정리됐고, 조회만 먼저 열면 무엇을 얻고 무엇을 포기하는지 적으면서 트레이드오프가 분명해졌어요. 특히 벤치마크에서는 다른 광고 플랫폼의 사례를 찾아보면서, 그대로 참고할 부분과 우리 상황에 맞게 바꿔야 할 부분이 구분됐어요. PRD를 쓰면서 이전에는 생각해 보지 못했던 부분까지 고민하게 됐어요. 이 기능으로 플랫폼이 무엇을 얻을지, 어느 제품부터 고려할지, 뭐가 더 나은 방향인지 같은 제품 관점의 고민은 전부 처음이었어요. 이렇게 정한 것들이 정답인지 100% 확신할 수는 없었지만, 적어도 근거를 가지고 정했다는 점은 지금 돌아봐도 만족스러워요. 로드맵은 PM이 그리는 거라고 생각

  당근 기술 블로그 - Medium2026년 11월 3일

• 검색해도 안 나오는 SQL을 새로 만들다

  K-Metrics 제작 후기 #2 검색해도 안 나오는 SQL을 새로 만들다 최고운 AX팀 AI로 더 나은 일하는 방식을 고민하는 AI 엔지니어 업무의 언어를 이해하고, 함께 쿼리를 고치기까지 지난 편에서는 동료들이 업무에서 사용하고 확인한 쿼리를 모아, 자연어로 찾아 재사용하는 이야기를 했어요. 등록된 쿼리로 답할 수 있는 질문이라면 새 SQL을 만들지 않고도 업무를 시작할 수 있죠. 그렇다면 검색이 “못 찾았어요”라고 답한 요청은 어떻게 처리할까요? 등록된 쿼리가 다루지 않는 대상을 조회하거나, 다른 기준으로 집계해야 한다면 새로운 SQL이 필요합니다. 이번 편은 그다음을 다룹니다. 검색으로 답하기 어려운 요청을 K-Metrics가 어떻게 새로운 SQL로 만드는지, 그 과정에서 업무 용어를 해석하고 필요한 조건을 사용자와 확인하는 방법을 살펴볼게요. 만들어진 쿼리를 업무 의도에 맞게 이어서 고치는 과정도 함께 다룹니다. SQL 한 번을 생성하는 것만큼, 그 SQL을 사용자의 업무 의도에 맞게 다듬어 가는 과정에 집중했습니다. 질문이 SQL이 되기까지 “지난달 A상품 신규 가입 고객 수를 연령대별로 보여 줘”라는 요청을 예로 들어볼게요. 이 질문에 답하려면 무엇을 셀지, 어떤 데이터를 사용할지, 기간과 집계 기준을 어떻게 적용할지 정해야 합니다. K-Metrics는 질문을 요구사항으로 나누고, 테이블·컬럼과 조건을 정해 SQL을 작성한 뒤 검증해요. 문제가 있으면 필요한 단계로 돌아가고, 재시도 한도 안에서 해결되지 않으면 남은 문제를 정리해 반환합니다. SQL 생성과 검증·재시도 흐름 이 과정을 모델에게 한 번에 맡기지 않고 여러 단계로 나눈 데에는 이유가 있습니다. 왜 자율 에이전트보다 단계별 워크플로우가 필요했을까? 검색이나 스키마 조회를 도구로 제공하고, 모델이 다음 행동을 선택하도록 만들 수도 있습니다. 판단하고 도구를 사용한 뒤 그 결과로 다음 행동을 정하는 ReAct 방식이라면, SQL 생성 외의 정보 탐색까지 유연하게 연결할 수 있죠. 다만 이 서비스에서는 그 자유도보다 운영 중 처리 과정을 추적하고 통제할 수 있는 구조가 더 중요하다고 봤어요. 그 출발점은 모델에게 한 번에 맡기는 판단의 범위를 정하는 일이었습니다. 온프렘 LLM의 제한된 컨텍스트를 효율적으로 쓰기 위해 작업을 작은 목표로 나눴어요. 테이블을 고를 때는 요구사항과 후보 설명을, SQL을 작성할 때는 선택한 스키마와 확정된 계획을 전달합니다. 각 단계가 해야 할 일과 필요한 정보를 함께 좁힌 것이죠. 작업을 나누고 나니, 단계 사이에서 반드시 지켜야 할 순서도 분명해졌습니다. 특히 생성한 SQL의 검증을 모델에게 도구로 주고 ‘필요하면 호출해’라고 맡기고 싶지는 않았어요. SQL 작성 뒤에는 구조 검증으로 이어지고, 결과에 따라 의도 검증이나 수정으로 넘어가도록 경로를 정했습니다. 모델이 복구 방향을 제안하더라도, 이동할 수 있는 단계와 재시도·종료 조건은 코드가 관리하도록 했어요. 자율 에이전트와 단계별 워크플로우의 차이 이렇게 단계와 경로를 명시하면, 결과가 잘못됐을 때 되짚을 지점도 생깁니다. 최종 SQL만 보는 대신 요구사항 해석·테이블 선택·컬럼 매핑의 중간 결과를 따라가며 어느 판단에서 문제가 시작됐는지 확인할 수 있어요. 단계별 입출력을 기준으로 프롬프트 수정과 테스트의 출발점도 좁혀 볼 수 있습니다. LangGraph는 이 설계를 실행 흐름으로 옮기는 데 사용했습니다. 단계별 결과는 상태로 전달하고, 검증 결과에 따라 앞 단계로 돌아가는 분기와 반복은 조건부 연결로 표현했어요. LangGraph로도 자율 에이전트를 만들 수 있고, ReAct에도 검증과 재시도 제한을 붙일 수 있습니다. 결국 선택의 핵심은 프레임워크의 우열이 아니라, 판단은 모델에 맡기되 반드시 거쳐야 할 검증과 재시도·종료 조건은 코드로 관리하겠다는 것이었어요. 사내에서 쓰는 용어를 실제 조건으로 만들기 생성 흐름을 나눴다고 해서 모델이 우리 행의 업무까지 이해하지는 못 합니다. 사용자가 평소 쓰는 줄임말도 알아들어야 하고, 짧은 요청에 생략된 업무 기

  케이뱅크 공식 블로그2026년 11월 3일

• 팀이 신뢰할 수 있는 AI 분석 환경 만들기: 추천팀의 컨텍스트 설계

  안녕하세요. 카카오톡 숏폼 추천 모델을 개발하고 있는 루퍼트(rupert)입니다. 저희 추천팀은 추천 지표 분석에 AI 에이전트를 사용합니다. AI 에이전트에게 분석을 요청하면, 에이전트가 미리 정리해 둔 지침 문서(CLAUDE.md)를 읽고 SQL을 작성해 기존 Hadoop 환경에서 실행한 뒤 집계 결과를 리포트로 완성합니다. 지난 글에서는 데이터 엔지니어, 분석가만 알고 있던 로그 데이터 접근 방법과 분석 기준을 AI를 통해 조회하는 사례를 소개했습...

  tech.kakao.com2026년 10월 27일

• 손가락 튕기기로 LLM 비용 줄이기

  토스의 수많은 서비스와 내부 업무에도 생성형 AI가 정말 많이 사용되고 있습니다. 복잡한 정책을 읽고, 상품 정보를 비교하고, 문서를 요약하고, 정해진 형식의 값을 추출하는 등, LLM이 맡는 범위도 빠르게 넓어지고 있죠. 시간도 비용도 비싼 데이터 레이블링을 통해 모델을 학습하고 문제를 해결하던 과거 방식과 달리, LLM을 사용하면 빠른 시간 내에 사용할 수 있는 솔루션이 만들어집니다. 프롬프트를 작성하고, 몇 가지 예시를 넣고, 응답 형식을 고정하면 동작하는 Workflow가 나오죠. 하지만 프롬프트 튜닝을 마치고 본격적으로 대용량 호출을 시작하면 새로운 문제가 보이기 시작합니다. 바로 비용과 Latency입니다. 이 토큰 먹는 하마는 정말 토스의 모든 문제 해결에 지속적으로 필요한걸까요? LLM Fine-Tuning is all you need? 상용 LLM을 사용하지 않고 내재화 한다면, 비용을 크게 절감할 수 있습니다. 작업 목표에 따라 LoRA(Low-Rank Adaptation)처럼 효율적인 Adapter 학습을 사용할 수도 있고, 더 큰 품질 개선이나 안정성이 필요하다면 Full Fine-Tuning을 검토할 수도 있습니다. 실제로 토스에서도 LLM Fine-Tuning 을 통해 비용을 크게 절감한 사례도 있어요. 그런데 모든 LLM 호출에 같은 수준의 능력이 필요한 것은 아닙니다. 복잡한 문맥을 이해하고 긴 답변을 생성해야 하는 작업도 있지만, 두 상품이 같은지 판단하거나 정해진 카테고리 중 하나를 고르는 작업도 있어요. 이런 작업이 반드시 범용 LLM의 모든 능력을 필요로 하지는 않습니다. 작업의 복잡도와 요구되는 품질에 따라, 전통적인 ML 모델이나 특정 작업에 최적화한 소형 모델을 적절히 선택해도 충분히 처리할 수 있는 경우가 있죠. 중요한 것은 모델의 크기보다, 주어진 작업에 필요한 품질을 확보할 수 있느냐입니다. Figure 1. LLM이 처리하는 다양한 작업. 작업의 특성과 요구 품질에 따라 적합한 모델도 달라집니다. 전환이 가능한 트래픽부터 내재화하기 '작은 모델'이 가지는 장단점은 명확합니다. 빠르고, 자원 소모가 적지만, 처리할 수 있는 문제의 범위에는 제약이 있어요. 간단한 질문으로 시작해봤습니다. 내재화 모델은 꼭 LLM과 동등한, 혹은 견줄 만한 수준으로 성능을 끌어올려야만 사용할 수 있는 걸까? 빠르고 작은 모델이라도 쉬운 요청은 충분히 처리할 수 있을 텐데? 이 질문으로부터 선택적 내재화(SNAP, Selective Native AI Processing)를 기획하게 되었어요. SNAP의 핵심은 해결해야 하는 문제의 모든 요청을 한 번에 Native Model로 처리하는 것이 아니라, 작은 모델도 높은 신뢰도로 처리할 수 있는 트래픽부터 빠르게 처리하는 것입니다. 고비용 LLM Traffic을 한 번에 없애기보다, 처리 가능한 구간을 찾아 타노스가 손가락을 튕기듯(SNAP!) 손쉽게 줄여보자는 의미도 담겨 있죠. 큰 틀에서 SNAP은 다음 3가지 규칙을 하나의 Workflow로 묶습니다. 비교적 쉬운 요청은 작업별 소형 내재화 모델이 처리합니다. 어렵거나 애매한 요청은 기존 LLM으로 Fallback합니다. Fallback의 기준은 내재화 모델의 Confidence와 Offline 검증 결과로 정합니다. 자, 그렇다면 작업별 소형 모델을 만들기 위해서 먼저 작업별로 학습데이터가 될 LLM 로그부터 수집해야겠죠? 그런데 여기서 한 가지 문제가 있었습니다. 방대한 LLM 로그들을 동일한 작업으로 어떻게 분류하죠? LLM 호출 로그에는 굉장히 다양하고 이질적인 요청들이 섞여서 들어옵니다. LLM 으로 보내는 요청은 사람에게 말하듯 높은 자유도가 주어지기 때문에 같은 API Key, 같은 Endpoint를 사용해 호출하더라도 동일한 작업임을 전혀 보장할 수가 없죠. 그래서 먼저 요청을 작업 단위로 묶을 기준이 필요했습니다. 다양한 Task들의 로그에서 나타나는 공통적인 특징은 Prompting 방식이었습니다. 많은 LLM Workflow는 System Prompt 앞부분에서 LLM에

  토스 기술 블로그, 토스 테크2026년 10월 27일

• 대AI시대에 일하는 방식의 변화에 대한 고찰

  1인 1작업에서 1인 N작업으로, 병목이 코딩에서 판단으로 옮겨간 시대에 일하는 방식은 어떻게 달라지는가 들어가며 무신사 물류플랫폼팀에서 백엔드를 개발하고 있습니다. 먼저 밝혀두자면, 무언가를 가르치거나 교훈을 전하려는 목적은 없습니다. AI 코딩 에이전트와 본격적으로 일하기 시작한 뒤 제 일하는 방식이 어떻게 바뀌었고 어디에서 넘어졌는지, 그래서 지금은 어떤 방식으로 일하는지를 돌아보는 글에 가깝습니다. 저도 아직 이 방식이 맞는지 의심하는 중입니다. 요즘 제 모니터에는 터미널 창이 여러 개 떠 있습니다. 각 창에서는 서로 다른 작업을 맡은 에이전트가 돌고 있고, 저는 그 사이를 오가며 결과를 읽고, 승인하고, 다음 지시를 내립니다. 몇 년 전의 저라면 이 화면을 보고 “저렇게 하면 하나도 제대로 못 끝낸다”고 했을 겁니다. 실제로 그때는 그 말이 맞았습니다. 이 글은 세 가지 질문을 따라갑니다. 왜 예전에는 한 번에 하나만 했는가. 무엇이 바뀌어서 지금은 여러 개를 동시에 굴리게 됐는가. 그리고 사람은 어디까지 따라갈 수 있는가. 왜 우리는 한 번에 하나만 했을까 돌이켜보면 1인 1작업은 규칙이라기보다 물리 법칙에 가까웠습니다. 첫째, 코딩 자체가 병목이었습니다. 설계하고, 코드를 작성하고, 테스트를 돌리고, 리뷰를 받는 흐름의 속도는 결국 제가 직접 작업하는 속도에 묶여 있었습니다. 두 작업을 동시에 잡으면 둘 다 눈에 띄게 느려졌습니다. 둘째, 컨텍스트 스위칭 비용이 컸습니다. 브랜치를 옮기면 머릿속도 같이 리셋됐습니다. 어디까지 봤는지, 왜 이렇게 고치려 했는지를 다시 떠올리는 데 시간이 들었습니다. 그래서 IDE 하나, 워킹 트리 하나, 브랜치 하나가 자연스러운 상태였습니다. 스프린트에서도 티켓을 하나 잡아 끝낸 뒤 다음으로 넘어갔습니다. 한 번에 하나에 집중하는 것이 미덕이었던 이유는 간단합니다. 제가 직접 생산해야 했기 때문입니다. 생산자가 한 명이면 생산 라인도 사실상 하나였습니다. 무엇이 바뀌었나: 기다림이 병렬을 불렀다 계기는 거창하지 않았습니다. 에이전트에게 작업을 맡기면 몇 분씩 돌아갑니다. 그동안 저는 화면을 멍하니 보고 있었고, 그 시간이 아까웠습니다. 그래서 다른 터미널을 열고 다른 작업을 시켰습니다. 마침 동시에 처리해야 할 요청이 몰리던 시기였고, 어차피 밀린 일은 많았습니다. 그게 굳어져 지금의 형태가 됐습니다. 요즘 제 아침은 대개 이렇게 시작합니다. git worktree로 갈라둔 작업 디렉터리마다 tmux 창을 하나씩 열고, 각 창의 Claude Code 세션에 서로 다른 기능을 맡깁니다. 한 세션에서는 조사와 구현을 서브에이전트로 나눠 동시에 돌립니다. 변경이 끝난 세션의 테스트와 자동 코드 리뷰는 백그라운드로 넘기고, 저는 다른 창으로 옮겨갑니다. 코드 창 옆에는 인프라 설정을 만지는 창과 위키나 티켓을 정리하는 창이 나란히 떠 있는 날이 많습니다. 하루의 작업 구조: 판단은 관제탑 하나, 라인은 여럿 이 그림에서 제 역할의 중심은 생산 라인 위의 작성자에서 여러 라인을 조율하는 관제사로 옮겨갑니다. 두 방식을 표로 놓고 보면 이렇습니다. 이 표에서 가장 중요한 줄은 “병목”입니다. 코딩 속도가 병목이던 시절에는 손이 하나라서 작업이 하나였습니다. 지금은 코딩 속도가 병목이 아닙니다. 그래서 처음에는 작업 수를 얼마든지 늘릴 수 있을 줄 알았습니다. 실제로는 다른 한계가 금방 나타났습니다. 그런데 사람이 따라가지 못했다 관제사 비유: 레이더에 뜬 열 대 중 교신 중인 것은 세 대 항공 관제사를 떠올리게 됐습니다. 관제사는 비행기를 직접 조종하지 않습니다. 대신 여러 대의 움직임을 동시에 살피며 충돌하지 않게 순서를 정하고 착륙을 허가합니다. 비행기가 아무리 좋아져도 관제사가 동시에 교신할 수 있는 비행기 수에는 한계가 있고, 그 한계를 넘기면 비행기 성능과 무관하게 사고가 납니다. 제 경우 그 한계는 세 개였습니다. 동시에 관리할 수 있는 작업이 세 개까지였다는 뜻입니다. 세 개까지는 창을 오가면서도 각 세션이 어디까지 왔는지, 내가 무엇을 시켰는지, 다음에 무엇을 확인해

  MUSINSA techblog — 무신사 테크 블로그 - Medium2026년 10월 26일

• 같은 지표를 물었는데//다른 숫자가 나오는 이유를 파보다

  K-Metrics 제작 후기 #1 같은 지표를 물었는데 다른 숫자가 나오는 이유를 파보다 안상규 AX팀 AI로 혼자서는 어려웠던 일을 가능하게 만드는 AI/ML Engineer 안녕하세요, 케이뱅크 AX팀에서 AI/ML Engineer로 일하고 있는 안상규입니다. 요즘은 AI로 반복 업무를 덜고, 혼자서는 하기 어려웠던 일을 할 수 있게 돕는 일을 하고 있습니다. 동료들이 데이터를 더 쉽게 쓰도록 만드는 것도 그중 하나예요. 이런 회의, 한 번쯤 겪어 보셨을 겁니다. 각자 지표를 뽑아 왔는데 화면에 띄운 숫자가 서로 다릅니다. 그러면 본론에 들어가기 전에 어떤 기준으로 쿼리를 짰는지부터 확인해야 합니다. 쿼리를 열어 보면 테이블이 다르거나, 조건 하나가 빠졌거나, 기간을 잡는 기준이 달라요. 한참 걸려 맞춰도 그 결과가 공유되지 않으니, 다음 주에 누군가 같은 지표를 뽑으면 쿼리 확인부터 다시 시작합니다. 그래서 일단, 저희가 해야 할 목표를 두 가지로 정의해봤습니다. 1. 흩어진 쿼리를 하나로 통일하는 것 2. SQL을 몰라도 자연어로 필요한 쿼리를 찾을 수 있게 만드는 것 이렇게 탄생한 K-Metrics는 지표나 원하는 고객군을 자연어로 물으면, 누군가 이미 검증해 올려 둔 쿼리를 찾아 주고, 없으면 새로 만들어 주는 서비스입니다. 이번 포스팅에서는 ‘검색’ 기능에 대해서 이야기 해보려합니다. 숫자는 매번 다르고, 답을 받으려면 사람을 기다려야 하고 아까 앞에서 제가 알려드린 문제 상황, 기억하시죠? 정리하면 두 가지라 할 수 있는데요. 첫 번째는 숫자가 다른 겁니다. 두 번째는 기다림입니다. 두 문제 모두 검증된 쿼리가 공유 자산으로 존재하지 않는다는 것에서 시작되었다 생각했습니다. 누군가 이미 특정 쿼리를 짜고 검증까지 했는데도, 그 쿼리가 개인 PC의 파일이나 머릿속에만 있으면 다른 사람은 처음부터 다시 만들거나 그 사람을 찾아가야 합니다. 그런데 문제는 이뿐만이 아닙니다. 금융 회사, 특히 은행은 망 분리 정책에 따라 실제 고객 데이터가 있는 망과 직원들이 업무를 보는 망을 분리해 두어야 하는데요. 이중 사내 인트라넷처럼 임직원들이 사용하는 사내 서비스, 은행이 보유하고 있는 DB는 철저하고 엄격하게 사내망에만 존재해야 합니다. SQL을 작성해주는 에이전트는 있을 수 있어도, 그 SQL을 사내 시스템에서 실행하거나 실제 DB를 대상으로 돌릴 순 없습니다. 그림으로 표현하면 아래와 같습니다. 이렇듯 일반적인 text2SQL과 달리, 스스로 검산할 수 없는 K-Metrics는 틀린 쿼리를 그대로 사용자에게 보여 줄 위험성이 필연적으로 존재합니다. 일단 믿고 쓸 수 있는 서비스가 되려면 무엇을 지켜야 하는지 세 가지 조건으로 정리했습니다. 1. 같은 지표를 물으면 항상 같은 쿼리를 줄 것 2. 실행 결과 없이도 믿을 수 있는 근거를 보여 줄 것 3. 맞는 쿼리가 없으면 없다고 말할 것 사용자 중에는 쿼리에 익숙하지 않은 비개발자가 더 많을 수도 있습니다. 그래서 엉뚱한 쿼리를 자신 있게 내미는 상황을 가장 위험한 상황이라 판단했습니다. 지표를 통일하는 네 가지 방법 위의 세 조건을 기반으로, 네 가지 방향을 차례로 검토했습니다. 방법 통일 대상 한계점 ① 표준 쿼리 저장소만 두기 쿼리 파일 찾기 어려우면 안 쓰게 되고, 기간·조건은 매번 직접 수정 ② 대시보드로 계산 결과 모으기 계산 결과 조회 권한·망 협의가 먼저 필요 ③ 자연어를 SQL로 생성 없음 — 매번 새 SQL 검증되지 않은 SQL이 나옴 ④ 검증 쿼리 자산화 + 자연어 검색 검증된 쿼리 ← 선택 2번의 경우 대시보드로 결과가 나오기 때문에 데이터를 쉽게 해석할 수 있다는 장점은 있습니다. 하지만 데이터의 조회 권한 문제가 있기에 실현하는데 제약이 있습니다. 3번의 경우 등록된 쿼리가 없어도 답할 수 있다는 장점은 있지만, 매번 다른 SQL이 나와서 첫 번째 조건과 맞지 않았습니다. 결국엔 ④번 방향을 골랐습니다. 지표 정의나 계산 결과가 아니라 검증된 쿼리를 통일의 기준으로 삼고, 쿼리를 찾고 조건을 채우는 단계에 LLM을 활용했습니다. 검색이

  케이뱅크 공식 블로그2026년 10월 26일

• Flava MCP Hub가 걸어온 길: AI 시대를 위한 배관 공사

  들어가며"우리 서비스, 지금 어떤 상태야?"AI 에이전트에게 이렇게 물어보신 적 있으신가요? 아마 겉보기에는 그럴듯하지만 실제로 활용하기는 어려운 답이 돌아왔을 겁니다. LLM(l...

  LY Corporation Tech Blog2026년 10월 26일

• 모델만 바꿨는데 LLM 비용이 3배가 된 이유

  안녕하세요, 당근 커뮤니티홈팀에서 백엔드를 개발하는 제이(Jay)예요. 당근 앱의 커뮤니티 탭에는 이웃이 알려 주는 동네 정보부터 소소한 일상과 취미까지 나누는 동네생활, 모임, 카페, 아파트가 모여 있어요. 커뮤니티홈팀은 이 서비스들의 글을 한데 모아 보여 주는 피드를 맡고 있어요. 피드를 맡으며 가장 고민하는 건 사용자에게 더 알맞은 글을 어떻게 보여 줄지예요. 그래서 기존 머신러닝 추천에 더해, LLM으로 글의 다양한 메타데이터를 뽑아 추천에 쓰고 있어요. 그중 하나가 LLM에 카테고리 목록과 글을 주고 어느 주제에 속하는지 고르게 하는 주제 분류예요. 추천은 보여 줄 글 후보를 모으는 단계와 그 순서를 정하는 단계로 나뉘는데, 글마다 주제가 붙어 있으면 첫 단계부터 사용자가 관심 있는 주제의 글을 골라 올 수 있어요. 주제 분류를 할 때 LLM에 보내는 요청을 열어 보면 대부분이 매번 똑같은 지시문과 카테고리 목록이고, 글 본문은 끝에 조금 붙어 있을 뿐이에요. 이 글에서는 요청마다 똑같은 이 부분을 고정부라고 부를게요. 2026년 8월, 이 작업의 모델을 Gemini에서 단가가 20% 낮은 OpenAI GPT-5.6으로 바꿨어요. 응답은 정상이었고 에러도 한 건 없었어요. 닷새 뒤 보니 단가는 내렸는데 요청당 비용은 3.2배가 돼 있었어요. 원인은 프롬프트 캐시였어요. 입력 중 캐시에서 읽어 온 비율인 캐시 히트율이 85.8%에서 2.3%로 떨어져 있었죠. 교체 전후의 응답을 나란히 놓으면 달라진 곳은 사용량 정보 안의 캐시 필드 하나뿐이었어요. 캐시가 깨져도 에러는 나지 않아요. 비용만 늘어요. 이 글은 그 일을 해결하며 알게 된 것을 정리한 기록이에요. 캐시가 무엇을 재사용하는지, 비용은 어떻게 매겨지는지, 언제 켜지고 어디까지 저장되는지, 캐시에서 읽었는지는 어떻게 확인하는지를 OpenAI, Anthropic, Google Gemini를 나란히 놓고 살펴봐요. 같은 지시문에 입력만 바꿔 LLM을 대량으로 부르거나, 챗봇이나 에이전트처럼 앞부분이 같은 요청을 되풀이해 보내는 분이라면 참고가 될 거예요. 프롬프트 캐시의 원리 신입 검수자에게 매번 규정집 20쪽과 오늘 볼 글 한 편을 함께 준다고 해 볼게요. 규정집은 늘 같고 글만 바뀌는데, 이 검수자는 기억을 못 해서 글마다 규정집을 처음부터 다시 읽어요. 하루 10만 편이면 규정집을 10만 번 읽는 셈이에요. LLM도 똑같이 요청마다 프롬프트 전체를 처음부터 다시 읽어요. 이 낭비를 줄이는 게 프롬프트 캐시예요. 앞 토큰을 돌아보는 어텐션 LLM은 글을 토큰 단위로 하나씩 이어 써요. 다음 토큰을 고르기 전에는 앞 토큰들을 돌아보며 무엇을 참고할지 따지는데, 이 계산을 어텐션(attention)이라고 해요. “어제 시장에서 산 사과를 깎아서” 다음에 올 토큰을 고른다고 해 볼게요. 사람은 바로 “먹었다”를 떠올려요. “사과”와 “깎아서”가 가장 관련 있고 “어제”나 “시장에서”는 덜 중요하다는 걸 알기 때문이에요. 모델은 이 판단을 마지막 토큰 “깎아서” 자리에서 숫자로 해요. 어텐션에는 토큰마다 세 가지 값이 쓰여요. 도서관에서 자료를 찾는 일에 비유해 볼게요. Q(Query, 질문): 마지막 토큰이 다음 토큰을 고르려고 들고 있는 질문이에요. “무엇을 했는지 이어 쓰려면 어떤 정보가 필요하지?” 같은 것이에요. K(Key, 분류표): 앞 토큰마다 붙은 꼬리표예요. 책의 분류표처럼 “먹을 수 있는 물건”, “때를 나타내는 말” 같은 정보를 담아요. V(Value, 내용): 앞 토큰이 실제로 건네주는 정보예요. 책의 본문에 해당해요. 마지막 토큰 “깎아서”는 자기 Q를 앞 토큰들(자기 자신 포함)의 K와 하나씩 맞춰 보고 점수를 매겨요. “사과”와 “깎아서”는 높은 점수를, “어제”는 낮은 점수를 받아요. 그다음 점수 비율대로 V를 섞고 그 결과로 다음 토큰 “먹었다”를 골라요. 분류표(K)로 관련 있는 책을 고른 뒤, 그 책들의 본문(V)을 점수만큼 읽는 것과 같아요. 실제 Q, K, V는 사람이 읽을 수 있는 문장이 아니라 숫자 묶음(벡터)이고,

  당근 기술 블로그 - Medium2026년 10월 21일

• [인사이트] 로봇은 왜 챗봇과 GPU 수요가 다를까? 피지컬 AI 시대의 인프라 전략

  kt cloud AI사업개발팀 정소라 님 요약 SUMMARY 이 글에서는 피지컬 AI의 로봇 파운데이션 모델(RFM)이 요구하는 학습·시뮬레이션·엣지 추론 인프라와 GPU 수요 구조를 다룹니다. 제조 중심의 국내 활용 환경에서 데이터 확보와 단계별 컴퓨팅 인프라 설계가 갖는 의미를 정리합니다. #피지컬AI #로봇파운데이션모델 #GPU인프라 #로봇시뮬레이션 #엣지추론 로봇은 왜 챗봇보다 GPU를 더 먹을까 — 피지컬 AI 시대의 RFM… 젠슨 황의 두 번째 방한이 남긴 신호 1. 젠슨 황은 왜 7개월 만에 다시 왔나 2026년 6월 초, 젠슨 황 NVIDIA CEO가 다시 한국을 찾았습니다. 지난해 10월 경주 APEC, 이른바 '깐부치킨 회동'으로 GPU 26만 장 공급을 발표한 지 약 7개월 만입니다. 이번엔 공식 행사 없이 국내 파트너 기업만 겨냥한 순수 사업 목적 방문이었고, 회동 대상 기업만 아홉 곳이 넘었습니다. 주목할 건 방문의 '주제'가 달라졌다는 점입니다. 1차(2025.10): 반도체·메모리(HBM)·자율주행 동맹. 키워드는 GPU 공급량 2차(2026.06): 로보틱스·휴머노이드·제조 데이터. 키워드는 피지컬 AI 젠슨 황은 대만 GTC 타이베이(6월 1일) 무대에서 로보틱스를 한국과의 '다음 협력 축'으로 지목했고, 방한 기간에는 로봇이 배치된 현대차 사옥, 로봇 친화형 네이버 사옥, 로봇 계열사를 둔 두산 등을 동선에 넣었습니다. 무엇보다 그는 "피지컬 AI 구현에서 가장 어려운 과제는 데이터 확보"라고 못을 박기도 했습니다. 이 한마디가 이 글의 출발점입니다. 데이터가 병목이라는 말은, 곧 그 데이터를 만들어내기 위한 컴퓨팅이 새로 필요하다는 뜻이기 때문입니다. LLM과는 다른 종류의 GPU 수요가 여기서 생깁니다. 2. RFM이란 무엇인가 — LLM과 무엇이 다른가 RFM(Robot Foundation Model)은 한마디로 로봇 버전의 거대모델입니다. LLM이 '텍스트를 받아 텍스트를 내놓는' 모델이라면, RFM은 멀티모달을 말합니다. 입력: 카메라 영상(Vision) + 언어 지시(Language) + 센서·관절 상태 출력: 텍스트가 아니라 행동(Action) — 어느 관절을 몇 도 움직일지 즉 RFM은 '보고(Vision) → 이해하고(Language) → 움직이는(Action)' 루프를 하나의 모델로 통합한 구조입니다. 챗봇은 틀린 답을 내도 사용자가 다시 물어보면 되지만, 로봇은 틀린 '행동'을 하면 물리 세계에서 사고가 납니다. 그래서 RFM은 정밀도와 안정성의 요구 수준이 다르고, 그만큼 학습·검증 비용이 큽니다. Image: AI-Generated Content 3. 핵심: RFM은 '한 대'가 아니라 '세 대'의 컴퓨터를 쓴다 여기서 LLM과 RFM의 결정적 차이가 나옵니다. NVIDIA는 이를 '세 대의 컴퓨터(Three Computers)' 구조로 설명합니다. 단계 역할 대표 스택 GPU 성격 ① 학습 (Training) 대규모 멀티모달 모델 학습 DGX / B300·H200 초고밀도 분산학습 클러스터 ② 시뮬레이션·합성데이터 (Simulation) 가상 환경에서 학습 데이터 생성 Omniverse · Cosmos · RTX PRO 시뮬레이션·렌더링 워크로드 ③ 엣지 추론 (Edge Inference) 로봇에 탑재된 실시간 추론 Jetson · Thor 저전력 온디바이스 Image: AI-Generated Content LLM은 사실상 ①과 약식 추론만 씁니다. 텍스트 데이터는 인터넷에 차고 넘치니, 데이터를 '만드는' 단계가 거의 필요 없습니다. RFM은 ②가 필수입니다. 로봇이 현실에서 수백만 번 넘어지며 데이터를 모을 수는 없기 때문입니다. 그래서 Omniverse·Cosmos 같은 디지털 트윈/월드 모델 안에서 가상으로 데이터를 합성합니다. 바로 이 시뮬레이션 단계가 LLM에는 없던 새로운 대규모 GPU 수요를 만듭니다. 젠슨 황이 말한 "데이터가 가장 어렵다"는 문제를, NVIDIA는 'GPU로 데이터를 찍어내는' 방식으로 푸는 셈입니다. 정리하면, 같은 파라미

  기술 블로그 (Tech) | kt cloud2026년 10월 21일

• LLM 추론 칩 검증 이야기 1편: 칩의 정답은 어디서 오는가

  LLM 추론 칩 검증에서 정답의 출처를 다룹니다. IP 레벨은 스펙 문서를, Top 레벨은 AI 모델의 결과를 정답으로 삼는 이유와 각 비교 축이 잡아내는 오류를 설명합니다.

  HyperAccel Tech Blog2026년 10월 21일

• [기술해설] AI 질문 한 줄은 얼마나 많은 에너지를 쓸까? 데이터센터가 지능을 만드는 법

  kt cloud DC글로벌고객팀 심재문 님 요약 SUMMARY 이 글에서는 AI 토큰 생성에 필요한 에너지와 데이터센터의 고밀도 GPU 랙 전력 공급, 직접액체냉각(DLC), PUE를 다룹니다. AI 인프라의 연산 효율과 안정적인 운영을 좌우하는 전력·냉각 설계의 중요성을 정리합니다. #AI데이터센터 #데이터센터전력 #GPU전력밀도 #액체냉각 #PUE 1. 디지털 언어의 화폐 '토큰'에 내재된 물리적 실체 대중에게 AI는 단순히 화면 위에 텍스트를 출력하는 소프트웨어에 불과하지만, 이를 지탱하는 하드웨어 엔지니어링 관점에서 AI는 '에너지를 지능으로 변환하는 변환기'입니다. 이 변환의 최소 입자가 바로 토큰(Token)입니다. 1.1 토큰화(Tokenization)와 연산 밀도 언어 모델(LLM)은 텍스트를 숫자의 나열인 벡터로 처리하기 위해 언어를 쪼개는 과정을 거칩니다. 한글은 영어보다 토큰화 과정이 복잡하며, 한 글자가 생성될 때마다 GPU 내 수천 개의 텐서 코어(Tensor Core)는 수조 번의 부동 소수점 연산을 수행합니다. 이 과정에서 발생하는 전자의 이동은 저항을 만나 열에너지로 변하며, 이는 고스란히 데이터센터 전력 계통에 부하로 작용합니다. 즉, 토큰은 데이터센터의 수전 용량을 소모시키는 '에너지 화폐'인 셈입니다. 1.2 1토큰의 에너지 등가성 추산 최신 하이퍼스케일 모델(예: Llama 3 70B 이상)을 구동한다고 가정할 때, 1개 토큰을 출력하기 위해 시스템 전체(IT 장비 및 냉각 설비 포함)에서 소모되는 전력은 약 0.003~0.005kWh로 추정됩니다. 이를 물리적 에너지 단위인 줄(Joule)이나 칼로리(cal)로 환산하면, 우리가 무심코 받는 한 문장의 답변이 실제로는 종이컵 하나 분량의 물을 끓일 수 있는 에너지를 소모하고 있음을 알 수 있습니다. 2. 30MW 데이터센터: 서울 도심의 열역학적 엔진룸 서울 가산, 상암 등지에 위치한 중대형 데이터센터의 수전 용량은 보통 22MW에서 30MW 사이입니다. 이 수치는 단순한 전력량이 아니라, 도시 전력망이 단일 건축물에 허용할 수 있는 공학적 임계점입니다. 2.1 30MW의 물리적 규모와 전력 인입 과정 30MW는 인구 10만 명 규모의 중소도시 전체가 사용하는 전력량과 맞먹습니다. 이 막대한 에너지를 한 건물로 집중시키기 위해 데이터센터는 한국전력 변전소로부터 154kV(154,000V) 초고압 전력을 직접 인입받습니다. 이 전기가 서버가 사용할 수 있는 전압으로 낮아지는 과정에서 발생하는 변압 손실과 유도열 또한 데이터센터가 해결해야 할 거대한 공학적 숙제입니다. 30MW 전력망의 1%만 손실되어도 300kW의 열이 발생하며, 이는 일반 빌딩 전체를 난방할 수 있는 수준입니다. 2.2 지능의 생산 한계점 30MW급 센터가 냉각 및 기타 손실(PUE)을 제외하고 순수하게 AI 연산에 투입할 수 있는 전력을 25MW라고 한다면, 이 센터는 이론적으로 초당 수백만 개의 토큰을 동시에 생산할 수 있는 '지능 발전소'가 됩니다. 그러나 이 발전소의 출력은 곧 '냉각 능력'에 의해 제한됩니다. 3. 랙당 80kW의 시대: 극한의 열 밀도와 공학적 필연성 과거 CPU 중심의 데이터센터는 랙당 전력 밀도가 5~10kW 수준이었습니다. 그러나 GPU 기반의 AIDC(AI Data Center)는 서버 한 대가 수 kW를 소모하며, 랙 하나에 서버를 실장했을 때 전력 밀도는 80kW까지 치솟습니다. 3.1 공랭식(Air Cooling)의 한계와 열역학적 모순 80kW는 좁은 캐비닛 하나에서 8만 와트의 열이 뿜어져 나온다는 뜻입니다. 공기는 비열(Specific Heat)이 매우 낮아 열을 실어 나르는 능력이 떨어집니다. 이 열을 공기로만 식히려면 태풍급의 풍량을 24시간 내내 쏴주어야 하며, 이 과정에서 팬(Fan)이 소모하는 전력이 서버가 쓰는 전력을 앞지르는 '냉각 역설'이 발생합니다. 3.2 버스웨이(Busway)와 고전류 공급 시스템 80kW의 전류를 일반적인 구리 케이블로 공급하려면 팔뚝 굵기 이상의 전선이 필요합니다. 전선 자체의

  기술 블로그 (Tech) | kt cloud2026년 10월 21일

• 글로벌 최고 수준의 자체 비전 인코더, Kanana-2-vision-encoder 개발기

  안녕하세요. 카카오 Multimodal Model Training팀에서 카나나를 연구·개발하는 Polar(엄지환)입니다. 카카오가 자체 기술력만으로 밑바닥부터(from scratch) 개발한 독자 비전 인코더, Kanana-2-vision-encoder를 소개합니다. Kanana-2-vision-encoder는 카카오 언어모델 Kanana-2 LLM[1]의 가중치와 구조를 활용해 학습과 추론 모두에서 높은 효율성을 자랑합니다. 또한, 고해상도 이미지 ...

  tech.kakao.com2026년 10월 20일

• 프론티어 모델 대신, 우리 모델이 모든 상담을 분석합니다

  상담 분석 LLM을 자체 모델로 바꾸며, 비용은 99.4% 줄이고 성능은 상용 LLM보다 높인 이야기

  채널 테크 블로그2026년 10월 19일

• 갈림길에서 묻는 시험, SciPiVot이 재는 연구 판단

  6개월 현장 기록에서 뽑은 248개 갈림길로 LLM 에이전트의 연구 판단력을 재는 SciPiVot을 구조와 기록 조건, 63.5 대 73.4의 간격 중심으로 읽는다.

  블로그 | Patty2026년 10월 17일

• 도구 선택은 이름이 아니라 스키마가 바꾼다

  367,174개 MCP 도구 분석과 요인별 통제 실험으로 이름, 설명, 스키마 중 무엇이 LLM의 도구 선택을 움직이는지 풀어낸 연구 해설

  블로그 | Patty2026년 10월 16일

• 인공물의 첫 시험, 초지능을 재는 LLM 참조 C-test

  사람도 최신 모델도 기준이 될 수 없을 때 시험의 난이도를 어디에 고정할지에 대한 논문을 풀어쓴 해설입니다. 역문제와 Levin의 Kt, LLM을 참조 기계로 쓰는 발상을 따라가며 초지능 구간을 인증하는 시험 파이프라인을 살펴봅니다.

  블로그 | Patty2026년 10월 14일

• [AI활용] AI가 만든 코드, 팀은 어떻게 관리하나?

  kt cloud 그룹사업기획팀 변세림 님 요약 SUMMARY 이 글에서는 팀이 AI 생성 코드의 일관성과 보안을 위해 페르소나, SKILL.md, YAML 기반 Harness 검증 체계를 설계한 과정을 다룹니다. 코드 생성 이후의 검증 병목을 줄이기 위한 팀 규칙의 명문화와 자동 검증, 사람의 최종 판단 원칙을 정리합니다. #AI생성코드 #코드거버넌스 #SKILLmd #Harness #Terraform Image: AI-Generated Content 안녕하세요. 지난 글에서 AI 자동화의 진짜 문제는 "만드는 것"이 아니라 "유지하는 것"이라는 이야기를 나누었습니다. 그리고 그 전제 조건으로, 팀의 암묵지를 먼저 명문화해야 한다는 점도 강조했었죠. 그렇다면 실제 현업에서는 이를 어떻게 구현하면 될까요? 이번 글에서는 그 고민을 팀 단위로 확장했을 때 어떤 일들이 벌어지는지, 그리고 저희 팀이 어떤 시행착오를 거쳐 지금의 거버넌스 구조에 이르게 되었는지를 이야기해 보려 합니다. 1단계: 혼자 쓸 때는 괜찮았습니다 처음에는 로컬 환경에서 혼자 AI를 활용했습니다. 제가 원하는 결과물을 Claude나 Cursor에게 요청하면 코드가 나왔고, 제가 직접 눈으로 확인하고 수정했습니다. 혼자 쓸 때는 이것만으로도 충분했습니다. 제 머릿속에 모든 맥락이 있었고, 제가 짠 코드이기에 제가 책임지면 그만이었으니까요. 그런데 이것을 '팀'의 영역으로 가져오는 순간부터 묘한 문제들이 생기기 시작했습니다. 2단계: 팀으로 확장하자 생긴 일 저희 팀은 Terraform을 활용해 Azure 인프라를 관리하고 있습니다. AI 코딩 도구가 팀 안으로 들어오면서 코드 생성 속도는 확실히 빨라졌고, GitHub에 올라오는 PR의 수도 눈에 띄게 늘었습니다. 그런데 속도가 빨라짐과 동시에 새로운 딜레마에 빠졌습니다. 코드는 빠르게 쏟아져 나오는데, 그 코드가 팀 기준에 맞는지 확인하는 건 여전히 '사람의 눈'에 달려있었기 때문입니다. 저희 팀에는 인프라 코드를 작성할 때 반드시 지켜야 할 기준들이 있습니다. 리소스 명명 규칙, 필수 태그 여부, 보안 정책 준수 여부 같은 것들입니다. 예전에는 모듈 수가 적었기 때문에 PR 리뷰 시 사람이 직접 꼼꼼히 확인하면 되었습니다. 그런데 AI가 코드 생성 속도를 폭발적으로 끌어올리면서 리뷰해야 할 코드의 양은 산더미처럼 늘어났고, 리뷰어의 수는 그대로였습니다. 결국 병목 현상이 '코드 생성'에서 '코드 검증'으로 이동했을 뿐이었습니다. 더 큰 문제는 따로 있었습니다. AI는 가끔 "그럴듯하지만 틀린" 코드를 아주 자신 있게 내놓는다는 점입니다. 명명 규칙을 미묘하게 벗어났거나, 필수 태그가 하나 빠졌거나 하는 자잘한 오류들은 리뷰어가 지치면 그냥 스쳐 지나가기 십상입니다. 팀의 인프라 기준이 전적으로 '사람의 주의력'에 의존하는 아슬아슬한 구조가 되어버린 것입니다. 3단계: AI에게 맥락을 주는 방법의 진화 이 문제를 처음 마주했을 때 가장 먼저 시도한 방법은 '페르소나(Persona) 정의'였습니다. "너는 우리 팀의 인프라 엔지니어야. 명명 규칙은 이렇고, 태그는 이걸 써야 해." 프롬프트 앞에 팀 기준을 줄줄이 적어서 AI에게 역할을 부여하는 방식입니다. 처음엔 꽤 효과가 있었습니다. AI가 맥락을 이해하고 팀 기준에 맞는 코드를 더 잘 생성해 주었죠. 그런데 한계가 금방 드러났습니다. 페르소나 정의는 대화가 길어질수록 점차 희석됩니다. 초반에 설정한 역할을 AI가 점점 잊어버리고, 대화 중반쯤 되면 처음과 전혀 다른 스타일의 코드가 튀어나오기 시작합니다. 매번 새로운 대화를 시작할 때마다 같은 맥락을 반복해서 주입해야 하는 피로감도 컸습니다. 그래서 다음으로 시도한 것이 'SKILL.md' 방식입니다. 팀의 인프라 작성 기준, 명명 규칙, 자주 쓰는 패턴들을 마크다운(Markdown) 파일로 깔끔하게 정리해 두고, AI가 작업을 시작할 때 이 파일을 참조하게 하는 구조입니다. # SKILL.md ## 명명 규칙 - Resource Group: rg-{service}-{env}-{region} - V

  기술 블로그 (Tech) | kt cloud2026년 10월 14일

더 찾아보기