“왜 스킬을 처음 쓸 때 버벅거리지?” 처음 스킬을 사용하면 순간적으로 프레임이 뚝 끊긴다.그런데 같은 스킬을 두 번째부터 사용하면 멀쩡하다. 처음에는 Niagara 시스템 생성 비용인가 싶었다.에셋 로딩 문제도 의심해서, 런타임 동기 로드를 꽤 많이 정리했다.그런데도 첫 발동 순간의 히치(Hitch)는 남아 있었다.결국 문제를 조금 더 깊게 파고들어 보니 원인은 렌더링 파이프라인 깊숙한 곳에 있었다. 바로 PSO(Pipeline State Object) 컴파일이었다.이번 글은 Niagara VFX가 처음 실행될 때 발생하던 스터터를 추적하면서PSO Precaching, Bundled PSO Cache, 로딩 화면 대기, VFX Warm-up까지 조사하고 프로젝트에 적용 방향을 잡은 기록이다. 1. 문제..

지금의 AI는 ‘사람을 보조하도록’ 설계되어 있다. 아직 ‘사람이 신경 쓰지 않아도 일을 끝내도록’ 설계된 것은 아니다.1. 어려운 수학은 AI 혼자 잘 풀면서, 왜 고객 응대에는 사람이 남을까?AI는 어려운 수학 문제를 혼자 푸는데, 왜 고객 서비스처럼 상대적으로 단순해 보이는 의사결정에는 여전히 사람의 의사결정을 남겨둘까? 대부분의 LLM은 RLHF로 만들어졌는데, 이 RLHF 프로세스 과정에서 HUMAN을 염두에 두고 만들었기 때문이라고 한다. 코딩 에이전트처럼 사람이 계속 옆에서 결과를 확인하고 만족도를 판단하는 작업에서는 AI가 꽤 강하다. 왜냐하면 RLHF로 만들어진 LLM은 코드가 실행되는 것만으로 끝나지 않는다. 사용자의 의도를 따라가고, 대화하면서 방향을 조정하고, 사람이 납득할 만한 결..

보호되어 있는 글입니다.

AI가 성장하면 관련 기업이 모두 돈을 버는 것처럼 보인다. 실제로는 다르다. AI 시장에서는 컴퓨트, 모델, 소프트웨어, 기업 고객, 인재 사이로 돈이 흐른다. 각 층의 수익 구조와 위험도 다르다.1. 네오클라우드: 매출보다 투자가 더 클 수 있다코어위브 같은 네오클라우드는 AI용 GPU와 데이터센터를 빌려준다. 일부 기업(IREN, 아이렌)은 암호화폐 채굴에 쓰던 전력과 부지를 AI 인프라로 전환했다.a16z에 따르면 코어위브는 출범 후 약 25분기 만에 분기 매출 26억 달러에 도달했다. 성장 속도는 매우 빠르다. 하지만 이 사업은 자본집약적이다. 2026년 1분기 코어위브는 매출 20억8천만 달러를 기록했지만 자본지출은 68억 달러에 달했다는 보도가 나왔다. GPU 감가상각과 부채 이자도 부담으..

AI 코딩 도구 생태계의 진화 속도가 매섭다. 단순히 개발자의 질문에 답하거나 코드 몇 줄을 자동 완성해 주던 시대는 끝났다. 이제 시장은 로컬 환경과 클라우드 에이전트가 끊김 없이 소통하고, 대규모 프로젝트의 컨텍스트를 통째로 이식하는 ‘멀티 에이전트 워크플로우’로 진입하고 있다. 그 중심에 최근 공개된 xAI의 그록 4.5(Grok 4.5)와 그록 빌드(Grok Build)가 있다.1. 성능과 가성비를 모두 잡은 그록 4.5의 파괴력개발 환경에서 도구의 교체 주기를 결정하는 핵심 요인은 결국 '성능'과 '비용'이다. 최근 소프트웨어 엔지니어링 성능을 극한까지 측정하는 FrontierSWE 벤치마크 결과가 공개되었다. 기존 SWE-Bench가 단순한 버그 수정 위주였다면, FrontierSWE는 한 ..

Fable 5의 성능은 상당하다...!그러나 복잡한 개발 작업을 처음부터 끝까지 맡기는 방식은 치명적인 단점이 존재한다. 바로 막대한 비용과 느린 속도다. 모든 과정을 최고 사양 모델로 구동하면 단 한 번의 작업 흐름에 50달러가 넘는 비용이 청구되기도 한다.이 문제를 해결하기 위해 터미널 애플리케이션 Ghostty의 제작자이자 HashiCorp의 창업자인 미첼 하시모토(Mitchell Hashimoto)가 AI 활용법을 공개했다. 핵심은 간단하다. 가장 똑똑한 거인의 어깨에 올라타되, 역할표를 영리하게 짜서 좋은 과실만 체리피킹하는 것이다. 이 글에서는 계획, 코딩, 심판을 분리하여 품질을 유지하면서도 비용을 59% 이상 절감한 AI 워크플로우를 분석한다. 1. 하시모토의 3단계 AI 분업 아키텍처..

"이 코드 누가 짰어요?"3개월 전의 나다. 남이 짠 복잡한 코드는 물론이고, 과거의 내가 작성한 코드조차 시간이 흐른 뒤 다시 열면 완전히 낯선 남의 코드가 된다...프로젝트의 규모가 커질수록 전체 구조를 머릿속에 담아두는 일은 불가능에 가까워진다. 특히 언리얼 엔진이나 대규모 웹 프로젝트처럼 수많은 파일과 클래스가 복잡하게 얽혀 있는 환경에서는 코드 한 줄을 수정하는 것조차 거대한 모험이 된다. 이 글에서는 레포지토리 주소 단 하나만으로 복잡한 구조를 한눈에 파악할 수 있게 돕는 오픈소스 도구, Understand-Anything을 활용해 레거시 분석 스트레스를 해결한 여정을 공유한다.1. 문제의 발견: 구조를 모르면 리팩토링도 없다새로운 기능을 추가하거나 성능 최적화를 진행할 때 개발자가 가장 먼..

Cerebras x Google Gemma 4: $5000 Hackathon · LumaCerebras is excited to present the Cerebras and Google DeepMind Gemma 4 24-Hour Hackathon! We’ve teamed up with Google DeepMind — leading AI research lab and…luma.comCerebras x Gemma 4 해커톤에 참여하면서 Cerebras DocLens라는 AI 문서 도구를 만들었다. Cerebras DocLens는 보험 약관, 법률 계약서, 의료 동의서처럼 읽기 어려운 문서를 업로드하면, Gemma 4 31B와 Cerebras API를 이용해 핵심 내용을 쉽게 풀어주는 웹 앱이다.단순한 PD..

한글 IME 버그부터 28,000 토큰 낭비 해결까지, AI 에이전트를 구축하며 얻은 인사이트에디터 밖 AI가 가진 명확한 한계일반적인 채팅형 AI에게 언리얼 엔진 작업을 부탁하면 대개 모호한 답변을 내놓는다. "현재 레벨에 어떤 액터가 배치되어 있어?", " Lv_TitlePhase 레벨을 열어줘" 같은 구체적인 요청을 던져도 에디터 내부 상태를 직접 보지 못하기 때문이다. 결국 AI는 추측에 의존하거나, 사용자에게 파이썬 콘솔 명령어를 복사해 직접 실행하라는 임시방편만 제시할 뿐이다. 이러한 문제를 해결하기 위해 UnrealEditor 내부에서 바로 AI와 대화하고, 에디터 상태를 읽거나 조작할 수 있는 인에디터 AI 에이전트 하네스(Harness: 소프트웨어를 제어하고 연결하는 구동 환경)인 Un..

2026년 현재, 개발 패러다임은 단순히 코딩 AI의 비서 역할을 받는 단계를 넘어섰다. 이제는 여러 개의 특화된 AI 에이전트를 적재적소에 배치하고 지휘하는 'AI 오케스트레이션(Orchestration)'의 시대!! 화면 하나에서 기획, 시각 분석, 코드 구현, 교차 검증(Code Review)까지 실시간으로 돌아가는 초생산성 멀티 에이전트 개발 환경을 나름대로 구축해보았다.1. 에이전트 팀 라인업과 역할 분담단 하나의 강력한 AI 모델에게 모든 걸 맡기면 컨텍스트가 꼬이거나 환각(Hallucination) 현상이 발생할 수 있다. 각자의 ' 전공 분야'가 명확한 에이전트들을 배치하여 분업 구조를 만들었다.에이전트 위치이름 (기반 모델)핵심 역할비고가운데 패널Claude Code (VS 확장)메인 아..