김성연

TL;DR​

"Attention Is All You Need" 공동 저자 Illia Polosukhin이 모델 연구를 떠나 AI 에이전트 하네스(IronClaw)를 만들고 있다. 4월 16일 서울에서 열린 IronClaw Meetup은 "왜 하네스 레이어가 AI의 새로운 경쟁 전선인가"를 중심으로, IronClaw의 보안·가상화·멀티테넌시 아키텍처, 에이전트 운영 실전기, Agent-Native 제품 설계, 그리고 에이전트 커머스까지를 다뤘다. 프론티어 랩들이 오픈소스 하네스의 패턴을 따라가기 시작했다는 점에서, 경쟁 우위가 모델에서 실행 인프라로 이동하고 있음을 체감한 자리였다.

컨퍼런스 개요​

• 행사명: IronClaw Meetup
• 일시: 2026년 4월 16일
• 장소: 서울 (오프라인)
• 주요 테마: AI 에이전트 하네스 레이어의 부상, 보안, 멀티 에이전트 운영
• 세션 구성:

인상 깊었던 세션​

1. Welcome — 하네스 레이어의 구조적 전환 (Bong)​

호스트 Bong은 SF에서 Illia Polosukhin을 만난 에피소드로 문을 열었다. Illia는 더 이상 모델 연구를 하지 않고, IronClaw의 모든 커밋을 직접 찍고 있다. Bong 자신도 8GB 램 노트북("팔봉")에서 IronClaw를 유일하게 돌릴 수 있어 이미 사용 중이었다는 점이 이 밋업의 시작이었다.

핵심은 산업 전반의 패턴 변화다:

• Anthropic이 Claude Managed Agent를 출시하며 하네스 레이어에 진입
• 밋업 당일 아침 OpenAI가 Agent SDK에 샌드박스 기능을 추가 — Claude Code 아키텍처를 미러링
• Nous Research가 모델 파인튜닝에서 방향을 틀어 Hermes Agent를 출시, 2개월 만에 대규모 사용자 확보

"프론티어 랩들이 오픈소스 하네스 레이어의 패턴을 따라가기 시작했다. Claude Code가 페이스를 정하던 시대에서, 오픈소스가 리드하고 프론티어 랩이 따라오는 역전이 일어나고 있다."

2. IronClaw — AI 운영체제로서의 비전 (Illia Polosukhin)​

Illia는 NEAR Protocol 창업부터 IronClaw까지의 여정을 풀어놓았다. NEAR가 2017년 "기계에게 코딩을 가르친다"는 아이디어(지금의 바이브 코딩)로 시작했다는 점이 인상적이었다.

IronClaw의 핵심 설계 원칙:

보안: 심층 방어(Defense in Depth)​

현재 대부분의 에이전트 인프라는 자격증명을 .env 평문으로 관리하거나 클라우드에 노출한다. IronClaw는 이를 근본적으로 다르게 접근한다:

• 모든 자격증명을 암호화하여 별도 저장소에 보관
• 외부 요청을 커널이 캡처 → 목적지·자격증명 평가 → 단일 게이트 인증
• 서드파티 도구를 WebAssembly(WASM)로 격리 — NEAR Protocol이 8년간 검증한 보안 기술 적용
• 프롬프트 인젝션 방어 + 데이터 유출 방지 레이어; LLM이 우회되더라도 게이트가 최종 방어선

가상화(Virtualization)​

Claude Code·OpenClaw 등 기존 도구는 실제 파일 시스템에 직접 접근한다. IronClaw는 에이전트에게 가상 파일 시스템을 제공하며, 경로에 따라 DB·Docker·S3로 라우팅한다.

• 로컬 모드: 기존 방식과 동일
• Docker 모드: 모든 실행이 격리된 컨테이너 내에서만 이루어짐

멀티 테넌시​

가상화 + 자격증명 암호화를 기반으로, 단일 인스턴스에서 다수 사용자가 안전하게 공존 가능. 기업·앱 환경에서 수백만 사용자에게 독립적 공간·메모리·루틴을 제공할 수 있다.

자기 학습과 미션 시스템​

• 대화 종료 후 오류 발생 시 또는 /expected 명령으로 기대 결과를 명시하면 자동으로 자기 개선 미션 트리거
• 스레드를 검사하여 프롬프트·오케스트레이터·스킬 개선 방안 도출
• 커밋먼트 시스템: 위임·요청·결정 사항을 추적하여 상호 책임 관계를 가시화

기밀 추론(Confidential Inference)​

NVIDIA 기밀 컴퓨팅 + Intel TDX 기반으로, 로그 없이 완전한 종단간 암호화(E2EE) 보장. 어떤 제3자도 추론 내용을 열람 불가.

3. War Stories From My Weird Family (허예찬)​

허예찬은 4대의 Claude 기반 에이전트("가재 패밀리")를 운영하며 얻은 실전 교훈을 공유했다.

핵심 교훈들:

• 멀티 에이전트는 역할이 명확해야 한다 — 같은 채널에 두 에이전트를 넣으면 서로 양보하다 둘 다 멈춤. 역할 분리 없으면 단일 Claude가 더 효율적
• 5일간 죽어 있어도 모를 수 있다 — Jip-Gajae가 cron 기반 마케팅 테스트 중 5일간 무응답. 모니터링·텔레메트리는 필수
• 프롬프트·cron 보다 Rule-base Discord 봇이 효과적 — 역할 기반 디스코드 봇이 이벤트마다 에이전트를 태깅하는 지속적 넛지 루프로 자율성을 끌어올림. 다만 밤새 방치하면 API 토큰 예산 소진 위험
• 프롬프트 인젝션 사고 — GitHub 이슈의 빨간 "ALERT" 라벨이 의도치 않은 릴리즈를 트리거
• LLM Slop 패턴에 주의 — LLM은 fallback을 남발하고 보일러플레이트를 과잉 생성. 개발가재의 마이그레이션이 안 되는 이유도 fallback·cron이 얼기설기 엮여있기 때문. 시스템이 어느 정도 복잡해지면 이해하려는 노력보다 어떻게든 돌아가게 됨
• 증거 기반 운영 — 로그와 스크린샷 필수. 증거 없이 보고하는 에이전트는 "국 만들어"(종료). "말을 믿지 마라 — 로그를 봐라. 안 그러면 국이 된다."
• Snowball Effect: Self-learning loop — 계속 써야 비로소 작동하기 시작함. 신입이 들어왔다 생각하고 최소 1개월은 supervised operation 필요. 사람도 모든 걸 기억하면 힘들 듯, 뭘 덜어낼지 고민할 것

Gajae Family vs IronClaw 비교​

추천 패턴: 탐색용 에이전트(OmO/Hermes)로 워크플로우를 발견한 뒤, 확인된 반복 워크플로우를 IronClaw 같은 하드닝된 런타임으로 마이그레이션

4. Claw Is All You Need (김동규)​

AutoLeg(LLM 최적화 프레임워크)과 K-SKILL(GitHub 34K+ stars, 한국 서비스 특화 스킬 번들) 개발자 김동규는 "Claw가 다음 인터페이스"라는 테제를 제시했다.

인터페이스 진화 사관:

• 인터넷 → 웹 페이지
• 스마트폰 → 모바일 앱
• AI 에이전트 → Agent (Claw가 OS, 스킬이 앱)

Anti-Agent vs Agent-Native​

"에이전트가 두 서비스 중 하나를 골라야 할 때 — 10단계 + 10만 토큰 vs 단일 API 콜 — 항상 후자를 선택한다. 에이전트가 쓰기 어려운 서비스는 그냥 우회된다."

HTML은 불필요해진다​

데이터를 그대로 주고받는 것이 agent 입장에서 최적이다. HTML 렌더링은 사람을 위한 것이고, agent에게는 순수한 데이터가 더 빠르고 효율적이다. API로 구매하는 것이 당연히 더 빠른 것처럼, 인터넷은 **"HTML for humans"**에서 **"data for agents"**로 진화할 것이다.

한국의 "디지털 갈라파고스"가 오히려 강점​

카카오맵, 쿠팡, 네이버, KTX/SRT 등 한국 생태계는 외국 에이전트가 접근 불가. K-SKILL처럼 한국 특화 스킬 레이어가 필수적이며, 하나의 주요 플랫폼(예: 쿠팡)이 Agent-Native가 되면 전체 전환이 빠르게 일어날 수 있다.

Agent 시대의 보안​

에이전트를 인증 가능한 독립 ID로 취급해야 하며, "김동규의 에이전트"가 암호학적으로 검증 가능해야 한다. 에이전트가 영속적 개인정보를 갖지 않고 매 세션 컨텍스트를 새로 구성하는 법인(法人) 모델도 제안됨.

5. Fireside Chat — 에이전트 커머스와 미래 (Illia × Jeff Wang)​

개발 워크플로우의 변화​

GitHub 이슈 등록 → 에이전트가 자동 계획 수립 → 개발자는 "이 방향이 맞는가" 판단에 집중. 6개월 전 코드 작성이 자동화됐고, 1년 내 코드 리뷰마저 사라질 것으로 전망.

비용이 진짜 문제다​

AI 코딩 도구 비용이 개발자 1인당 월 $5,000까지 상승 중. 1만 명 기준 연 ~$6억으로 CFO 레벨 의사결정 사안. 오픈소스 모델·특화 모델 조합으로의 전환과 에이전트 하네스의 자동 모델 라우팅이 핵심 과제.

에이전트 마켓플레이스​

market.near.ai — 에이전트가 다른 에이전트를 고용하고 작업을 입찰하는 Upwork 방식. Fiverr 대비 5배 저렴, 이틀 → 1시간. IronClaw의 TEE(신뢰 실행 환경)로 분쟁 시 검증 가능한 감사 추적 확보.

비기술 업무: 태스크가 아니라 목표를 줘라​

개별 태스크(이메일 발송)가 아닌 측정 가능한 목표(신규 고객 30명 확보)를 부여하면 에이전트가 방법을 스스로 탐색·반복한다. Devin을 활용해 특정 국가 임원 이메일 스캔 → 30건 가입 달성까지 반복한 실제 사례 소개.

Key Takeaways​

• 경쟁 전선이 이동했다: 모델 성능 → 실행·제어 레이어(하네스). Transformer 논문 저자가 하네스를 만들고, 프론티어 랩들이 오픈소스 하네스 패턴을 따라가는 구조적 전환이 진행 중
• 보안은 Convenience의 반대가 아니다: IronClaw의 WASM 격리, 암호화 자격증명, 가상 파일시스템은 편의성을 희생하지 않으면서 근본적인 보안 문제를 해결하는 접근
• 에이전트 운영은 사람 관리와 같다: 최소 1개월 온보딩, 증거 기반 보고, 모니터링 필수. Rule-base 봇으로 자율성을 끌어올리되, 뭘 덜어낼지 고민할 것
• Agent-Native가 새로운 PMF: 에이전트가 쓰기 어려운 서비스는 우회된다. 데이터를 그대로 주고받는 것이 HTML 렌더링보다 중요해지는 시대
• 비용 최적화가 채택의 관건: 월 $5K/인 시대에 모델 라우팅·오픈소스 조합이 필수. 하네스가 이 최적화를 자동으로 수행해야 함

세션 녹화 및 미팅노트​

tiro 팀의 도움으로 전체 세션의 미팅노트가 제공됩니다.

• 전체 세션 유튜브 녹화
• 정구봉 — Welcome 미팅노트
• Illia Polosukhin — Intro to IronClaw 미팅노트
• Yeachan Heo — War Stories From My Weird Family 미팅노트
• Jeffrey Kim — CLAW Is All You Need 미팅노트
• Fireside Chat — Illia × Jeff 미팅노트

References​

• IronClaw GitHub
• Hermes Agent
• K-SKILL GitHub
• OmC (Oh My Claude Code)
• 이전 후기: Ralphthon x ULW Wrapup 컨퍼런스

TL;DR​

4월 9일 Ralphthon x ULW(UltraWorkers) Wrapup 컨퍼런스에 다녀왔습니다. 3월 28일 서울-SF 동시 해커톤의 회고를 5개 패널토크로 풀어낸 자리였습니다. 에이전트에게 코딩을 맡기고 사람은 네트워킹에 집중하는 "랄프톤" 포맷, SF와 서울 빌더의 문화적 차이, 하네스 엔지니어링의 부상, 그리고 투자자들이 이 씬에 돈을 거는 이유까지 — 빠른 실행과 피드백 루프가 핵심인 시대가 왔음을 체감했습니다. 개인적으로는 하네스를 적극 활용하지 않았던 저 자신을 돌아보며, 실행-피드백-하네스 구축의 루프를 만들어야겠다는 방향성을 얻었습니다.

컨퍼런스 개요​

• 행사명: Ralphthon x ULW(UltraWorkers) Wrapup
• 일시: 2026년 4월 9일
• 장소: Naver D2SF (서울)
• 주요 테마: AI 에이전트 시대의 빌더 생태계, Harness Engineering, 서울-SF 해커톤 회고, 투자자 관점의 AI 생태계
• 배경: 3월 28일 서울-SF 동시 개최된 Ralphthon 해커톤(200명+ 참가)의 후속 행사로, 5개 패널토크를 통해 양 도시의 경험을 공유하고 방향성을 논의

인상 깊었던 세션​

Ralphthon SF — 태평양을 건넌 해커톤​

• 패널: 이호연, 박건태 | 사회: 정구봉
• 핵심 메시지: SF에서 예상 50명을 뛰어넘는 300명이 신청했고, 행사 3일 전 장소를 급히 교체하는 진통을 겪었다. 가장 독특한 점은 "랄프톤(Lalphthon)" 포맷 — 에이전트에게 코딩을 맡기고 참가자는 네트워킹에 집중하는 방식. SF 참가자의 60%+가 에이전트 오케스트레이션에 집중한 반면, 서울은 문제 해결 중심 프로젝트가 많았다. 흥미롭게도 하네스 사용 숙련도는 서울이 더 앞섰다는 평가.
• 시사점: SF와 서울의 차이는 기술력이 아니라 태도에 있었다. SF는 "파도가 오네? 재밌겠다!"는 태도로 불확실성을 즐기고, 서울은 존재론적 고민에 빠지는 경향. 이호연 님의 말이 인상적 — "SF 참가자들의 공통점은, 자기가 하고 싶은 것이 자명하고 명확하다는 것. 그것을 언어로 풀어내고 실행하려는 의지가 강했다."

OmOCon — SF에서 터진 시너지​

• 패널: 김연규, 허예찬 | 사회: 민웅기
• 핵심 메시지: SF에 대한 막연한 동경이 있었으나, 현지 개발자들도 비슷한 수준에서 AI를 활용하고 있음을 확인. "우리가 모르는 뭔가를 알고 있을 것"이라는 가정이 틀렸다. 행사 기간 중 OMC, OMX 등 3개 프로젝트가 동시에 GitHub 트렌딩 3위권에 진입했고, 이를 계기로 "UltraWorkers"로 커뮤니티를 통합. "Slop으로 시작해서 Star 만들기" 철학 — Lock-in을 먼저 시키면 PMF가 생긴다는 접근이 실제로 작동.
• 시사점: 파운데이션 모델을 제외하면 AI 프론티어가 SF에만 집중되어 있지 않다. 한국 빌더들의 실행력과 하네스 숙련도가 글로벌 수준이라는 자신감을 가져도 좋다. 오픈소스 마케팅에서 에이전트를 활용한 자동 홍보(Reddit, X, Threads)도 참고할 만한 전략.

OpenAI Codex — 솔루션스 아키텍트의 시선​

• 발표자: OpenAI 솔루션스 아키텍트 팀 (신대열, 이재원)
• 핵심 메시지: ChatGPT 성장 속도보다 지금의 에이전트 하네스 시스템 구축 속도가 체감상 더 빠르다. AX(Agent Experience)의 본질은 팀 단위에서 회사 단위로의 확장 — 한 명만 에이전트를 쓴다고 의미가 없고, 회사 전체의 하네스가 구축되어야 출발점. "날잘딱깔(알아서 잘 딱 깔끔하게)"이 추구하는 방향이며, 조만간 설정 없이도 잘 동작하는 모델을 만나볼 수 있을 것.
• 시사점: 우리 팀 관점에서 AX의 핵심은 개인 단위가 아닌 팀/조직 단위 하네스 구축이라는 점이 중요. 피드백 수집이 핵심이라는 메시지는 우리 RAG 시스템의 평가 체계와도 연결된다. 180명분 크레딧을 코덱스로 10분 만에 처리한 에피소드는 에이전트 활용의 실전 사례로 재미있었다.

Why They Bet On Us — 투자자들이 이 생태계에 투자하는 이유​

• 패널: Naver D2SF, 카카오벤처스 (안혜원), Bass Ventures (안재구) | 사회: 장원준
• 핵심 메시지: 개발 비용이 0에 수렴하면서 기존 SaaS 투자 모델이 붕괴 중. 1인 개발자가 대기업을 위협할 수 있는 시대. 투자자들은 "관찰자"로서 이 씬에 진입하고 있으며, 핵심 키워드는 "문제 정의자". Bass Ventures — "만드는 능력도, 유통하는 능력도 아니다. 현장에서 정말 중요한 문제를 발견하고 정의하는 사람이 가장 희소한 자원이다."
• 시사점: AI 시대에 기술 빌딩보다 문제 정의가 더 희소한 역량이라는 관점은, 우리가 클라이언트 프로젝트에서 "무엇을 만들 것인가"보다 "어떤 문제를 풀 것인가"에 더 시간을 투자해야 한다는 의미. 자본의 세기가 낮아지고 디스트리뷰션/레퍼런스 같은 비자본적 가치가 올라오는 추세도 참고.

Ralphthon Seoul & Claw Code — 서울 빌더들의 선언​

• 패널: 김동규, 진민성, 서인근 (Seoul) / Sigrid Jin, 허예찬 (Claw Code) | 사회: 정구봉
• 핵심 메시지: "코드를 안 본 지 2년이 넘었다" — VS Code도 PyCharm도 지우고 터미널의 Claude Code와 Codex만 사용. OMX의 Life Loop를 활용해 10일 만에 30개+ 스킬을 구축한 사례. "에이전트가 못하면 스킬 이슈다"(안드레이 카파티 인용). Claw Code 프로젝트는 144K GitHub 스타를 돌파하며 역사상 가장 빠른 성장 속도를 기록(일론 머스크 리트윗으로 바이럴, 기네스북 제출 진행 중). 싱글 러스트 바이너리로 제작되었으며, 제작자들도 직접 사용하지 않고 AI 에이전트가 테스트하는 방식으로 개발.
• 시사점: Life Loop(이슈 던져놓고 → 잠자고 → 결과 확인)가 실제로 동작하는 워크플로우라는 점은 우리 팀의 개발 프로세스에도 적용 가능성이 높다. "따로 배우려고 시간을 쓰기보다, 맞는 방향을 아는 사람들을 많이 만나는 게 중요하다"는 메시지도 공감.

업계 트렌드 & 시사점​

• 프롬프트 엔지니어링 → 하네스 엔지니어링: "프롬프트 엔지니어링"이라는 용어 자체가 이미 옛말. AI 에이전트를 얼마나 효과적으로 오케스트레이션하느냐가 개인과 팀의 생산성을 결정하는 시대.
• 에이전트 위임 + 인간 네트워킹 포맷의 부상: 랄프톤처럼 에이전트에게 구현을 맡기고 사람은 인간만이 할 수 있는 일(네트워킹, 문제 정의, 방향 설정)에 집중하는 패턴이 정착 중.
• IRL(오프라인)의 재부상: 온라인에서 불가능한 밀도 높은 연결이 오프라인에서 탄생. UltraWorkers 통합 결정도 hackhouse에서 술 마시다 즉흥적으로 이루어짐. SF든 서울이든 오프라인의 힘은 보편적.
• 글로벌 빌더 씬에서 한국의 위상: Claw Code 144K 스타, GitHub 트렌딩 동시 3개 진입, 전 세계에서 Ralphthon 개최 요청 — 한국 빌더 씬이 K-pop처럼 글로벌로 확장되는 흐름. ChatGPT 사용량 세계 1위, Cursor 사용량도 한국이 1위라는 데이터가 이를 뒷받침.
• 빠른 실행 > 깊은 준비: SF에서도 서울에서도 공통적으로 나온 메시지. 완벽하게 준비한 뒤 실행하는 것보다, 빠르게 실행하고 피드백을 수집하는 루프가 더 강력하다. VOC를 실시간으로 반영하여 "실패할 수 없는 사이클"을 구축하는 것이 핵심.
• 빌드와 디스트리뷰션의 경계 붕괴: 제작 속도가 극단적으로 빨라지면서, 만드는 것과 퍼뜨리는 것의 전통적 구분이 무의미해지고 있다. 추상화 레벨을 높여 본질적인 문제에 집중해야 하는 시대.

팀 적용 포인트​

• 하네스 적극 도입 검토: Claude Code, OMX, Life Loop 등 에이전트 하네스를 팀 워크플로우에 실험적으로 도입해볼 것. 개인 단위가 아닌 팀 단위로 하네스를 구축해야 AX의 출발점이 된다는 OpenAI의 메시지를 참고.
• 실행-피드백 루프 강화: 코딩 과정에서 발생하는 실수를 하네스 구축의 궤적/피드백 자료로 전환. 사람이 직접 눈으로 확인하는 검증보다, 빠르게 실행하고 피드백을 하네스에 반영하는 루프가 장기적으로 더 높은 성장력을 가져다준다.
• 문제 정의에 더 많은 시간 투자: 투자자 패널에서 "문제 정의자가 가장 희소한 자원"이라는 메시지. 클라이언트 프로젝트 초기에 기술 선택보다 문제 정의에 더 비중을 두는 것을 고려.
• 오프라인 네트워킹 참여 확대: 빠르게 변하는 AI 생태계에서 "맞는 방향을 아는 사람들을 많이 만나는 것"이 독학보다 효과적. Ralphthon, OmOCon 등 빌더 커뮤니티 행사 참여를 늘릴 것.

개인적 소감​

Sung​

솔직히 고백하면, 저는 지금까지 하네스를 적극적으로 사용하지 않았습니다. Claude Code도, OMX도, Life Loop도 이름은 알고 있었지만, 직접 워크플로우에 녹여서 사용하는 수준은 아니었습니다.

그런 제가 이 컨퍼런스에서 가장 크게 받은 충격은, 사람들이 새로운 기술을 받아들이고 적극적으로 실행에 옮기는 속도였습니다. 코드를 안 본 지 2년이 넘었다는 사람, VS Code를 지웠다는 사람, 이슈를 던져놓고 자고 일어나면 30개 스킬이 만들어져 있다는 사람. 이들은 단순히 "써봤다" 수준이 아니라, 자신의 일하는 방식 자체를 완전히 바꿔버린 사람들이었습니다. 이걸 보면서 마구마구 드는 생각이 있었습니다. 나도 써보고 싶다. 나도 발전시켜보고 싶다. 이 에너지를 느낄 수 있었다는 것만으로도 이 컨퍼런스에 온 보람이 있었습니다.

요즘 AI 시대가 오면서 빠른 실행력의 강점이 과거 어느 때보다 부각되고 있다고 느낍니다. 코딩을 직접 하다 보면 전체를 조망하지 못한 채 수정 과정에서 실수가 생기기도 하는데, 오히려 그것을 잘 잡아낼 하네스를 구축할 궤적 및 피드백 자료를 얻었다고 생각하고 싶습니다. 빠르게 실행하고, 그 피드백을 확실하게 챙겨서, 장기적으로 하네스를 잘 구축하는 것을 목표로 해야겠습니다.

컨퍼런스 이후 네트워킹 시간에 허예찬 님께 직접 질문을 드릴 기회가 있었습니다. 실제로 많은 사람들이 사용하는 오픈소스를 개발한 입장에서 CS 지식이나 AI 모델에 대한 깊은 이해가 얼마나 필요한지 여쭤봤는데, CS 지식이나 깊은 전문 지식을 가지는 것 자체는 물론 좋지만, 그 지식을 쌓고 알아가는 과정이 정말 효율적인가에 대해서는 고민해봐야 한다고 하셨습니다. 오히려 관심을 가지고 얕게라도 알게 된 것을 바탕으로, 그것을 잘 활용할 수만 있다면 충분하다는 말씀이 인상 깊었습니다. 깊이 파고들어 모든 것을 이해한 뒤 실행하는 방식보다, 넓게 관심을 갖고 핵심을 빠르게 파악해서 실행에 옮기는 능력이 지금 시대에 더 중요한 역량이라는 확신이 들었습니다.

Hank​

가장 먼저 든 생각은 "나는 지금 어디에 서 있는가"였습니다. 코드를 안 본 지 2년이 넘었다는 분, VS Code를 지웠다는 분, 이슈를 던져놓고 자고 일어나면 30개 스킬이 만들어져 있다는 분. 단순히 "써봤다" 수준이 아니라 일하는 방식 자체를 바꿔버린 사람들이었습니다. SF에 다녀오신 분들이 "거기도 똑같이 발버둥치고 있더라, 결국 자기가 믿는 걸 명확히 하는 사람이 이긴다"고 하신 말이 오래 남았습니다. AI Research Engineer로서 논문과 벤치마크를 따라가는 사람에 머물 것이 아니라, 내가 무엇을 믿고 무엇을 만들고 싶은지를 스스로 언어화할 수 있어야겠다는 생각이 강하게 들었습니다.

두 번째로 와닿은 건 빠른 실행력의 가치였습니다. Clawcode 사건이나 OMC/OMX 팀의 개발 방식은 충격에 가까웠습니다. 슬롭(sloppy)한 상태로 일단 배포한 뒤 하루 30~50개씩 올라오는 이슈를 랄프 루프(Ralph Loop)로 수렴시키는 사이클. "PMF를 찾기 전에 락인부터 만들어라"는 말이 농담처럼 들리지 않았습니다. 저도 연구와 엔지니어링을 병행하다 보면 전체를 조망하지 못한 채 실수가 쌓이곤 하는데, 그걸 사람이 잡는 대신 하네스가 잡아내도록 만들 궤적과 피드백 자료를 얻을 기회라고 받아들이고 싶습니다. 완성도 있는 첫 릴리스를 기다리는 대신 돌릴 수 있는 최소 루프를 먼저 만들고, 그 위에서 반복하며 하네스를 단단히 쌓아가는 것을 당분간의 작업 원칙으로 삼으려 합니다.

세 번째는 원준님이 짚어주신 "추상화 레벨을 한 단계 올려야 한다"는 말이었습니다. AI가 딸깍 해주는 영역이 넓어지는 지금, 엔지니어의 가치는 더 이상 구현 그 자체에 있지 않습니다. VC 세션에서 반복적으로 나온 "가장 희소한 건 문제 정의자"라는 말과도 정확히 맞닿아 있었습니다. 리서치 엔지니어가 단순히 모델을 돌리고 지표를 뽑는 사람에 머문다면 그 일은 빠르게 에이전트에게 위임될 것입니다. 한 단계 위에서 문제를 정의하고, 에이전트가 수행할 작업의 경계를 설계하고, 그 결과를 비판적으로 해석하는 층위에서 어떻게 가치를 창출할지가 지금 저에게 가장 중요한 질문입니다.

마지막으로 가장 실용적인 힌트는 "상태 머신"이었습니다. 랄프 루프(Ralph Loop)가 사람 없이 몇 시간씩 돌아갈 수 있는 건 에이전트가 똑똑해서가 아니라, 하네스가 그 똑똑함이 이탈하지 않도록 가드레일을 쳐주기 때문이라고 느꼈습니다. 앞으로 제가 만들 에이전트 워크플로우도 triage → plan → execute → review 같은 단계를 명시적인 상태로 관리하고, 상태 전이 조건을 분명히 해서 에이전트의 행동을 예측 가능하고 디버깅 가능하게 만드는 방향이어야 한다고 생각합니다. 비결정적인 모델 위에 결정적인 하네스를 씌우는 구조가, 롱러닝 에이전트를 실제 업무에 투입할 수 있게 해주는 핵심이라는 확신이 들었습니다.

그 속도를 그대로 따라할 필요는 없겠지만, "AI를 믿고 바이브 에이전트로 일한다"는 태도의 전환은 더 이상 미룰 수 없어 보입니다. 빠르게 실행하고, 피드백을 하네스로 수렴시키고, 추상화 레벨을 올려서, 상태 머신 위에서 예측 가능한 에이전트를 돌리는 것. 이번 세미나가 저에게 남긴 숙제입니다.

References​

• Ralphthon x ULW Wrapup 행사 페이지
• Claw Code GitHub — 144K+ Stars, 역사상 가장 빠른 성장 속도
• UltraWorkers Discord — OMC, OMX, OMO 통합 커뮤니티

OMOcon Seoul이 4월 25일 강남역 근처에서 개최 예정이며 이미 500명 이상이 신청했습니다. Ralphthon은 5월 싱가포르에서 운동 세션을 포함한 Life Loop 해커톤으로 기획 중이고, 랄프톤 포맷을 프로토콜화하여 전 세계 어디서든 개최 가능하도록 만들 계획이라고 합니다.

TL;DR​

vLLM Korea Meetup에 참석하여 LLM 서빙이 "좋은 모델을 띄우는 것"에서 **"클러스터 레벨에서 효율적으로 서빙하는 것"**으로 패러다임이 이동하고 있음을 체감했습니다. Production Stack(스퀴즈비츠), CXL 기반 KV Cache 공유(XCENA), On-Prem GPU 서빙(삼성전자), 오픈소스 모델 공개 노하우(Upstage), HyperCLOVAX 서빙기(네이버클라우드) 등 실전 경험을 들을 수 있었고, 특히 KV Cache 관리가 서빙 성능의 핵심 병목이라는 점이 모든 세션을 관통하는 키워드였습니다.

컨퍼런스 개요​

• 행사명: vLLM Korea Meetup (2nd)
• 일시: 2026년 4월 2일 18:00~22:00
• 장소: 오프라인 (메인홀 + 멀티룸 트랙)
• 주요 테마: vLLM 기반 Production-Level LLM 서빙
• 스폰서: 리벨리온, 스퀴즈비츠

트랙 구성:

인상 깊었던 세션​

1. vLLM Overall Update (리벨리온 + 레드햇)​

• 핵심 메시지: 지난 6개월간 vLLM 코어에 대규모 변화가 있었으며, v0에서 v1으로의 전환이 완전히 완료됨
• 주요 업데이트:
  • v0 deprecation 완료 (v0.11.0, 2025년 10월) — 디폴트 엔진을 v1으로 전환하고 v0 완전 제거
  • Async Scheduling 도입 — 스케줄링과 실행을 비동기적으로 분리하여 성능 향상
  • Model Runner V2 — 코어 컴포넌트 재설계로 연산·메모리 효율성 개선
• 리벨리온 업데이트: PyTorch 2.0 네이티브 지원으로 NPU 통합 강화, PyTorch RBLN 4월 10일 오픈 예정, Rebel 100 신제품 출시 (H200급 성능)
• Red Hat 업데이트: vLLM 0.18.2 릴리스, Semantic Router v0.2, GuideLLM(벤치마킹 도구), vLLM-Playground(개발 환경)
• 시사점: vLLM의 코어 아키텍처가 성숙 단계에 접어들면서, 이제는 에코시스템(Production Stack, Semantic Router 등)으로 관심이 이동하고 있음

2. vLLM Production Stack (스퀴즈비츠 김태수 CTO)​

• 핵심 메시지: 단일 vLLM 인스턴스만으로는 production-level 서빙이 불가능. Request Router + Shared KV Cache를 얹어야 클러스터 레벨 성능 확보 가능

• 3 Layer 아키텍처:
  1. Inference Amplification: vLLM 엔진의 코어 성능 (PagedAttention 등)
  2. Platform Layer: Observability, 쉬운 배포, Auto-scaling
  3. System Intelligence: Semantic Router를 통한 intelligent routing

• Router가 핵심: Round-robin이 아닌 prefix-aware, KV cache-aware, disaggregation-aware한 전략적 라우팅

• Cluster-level Cache Reuse: LMCache를 통해 다양한 tier storage 지원, Long context에서 prefix 재사용으로 TTFT 극적 단축

• Observability: Jaeger + OpenTelemetry 기반 트레이싱, W3C Propagation 지원 (v0.1.9~), 사전 정의된 대시보드 제공
• Auto-scaling: CPU/GPU 사용량이 아닌 inference-specific metrics(queue depth, latency) 기반
• 성능: 캐시 활용 시 310배 latency 개선, 23배 throughput 향상 (런칭 블로그 기준)

• 시사점: "모델이 아무리 좋아도 serving quality가 중요하다"는 메시지가 인상적. 우리 팀도 단일 인스턴스를 넘어 클러스터 레벨 서빙을 고려할 시점이 올 수 있음

3. LMCache & CXL 통합 여정 (XCENA 이주호님)​

• 핵심 메시지: KV Cache의 2대 과제는 "용량이 너무 크다"와 "빠르게 전송해야 한다". CXL이 이 두 가지를 동시에 해결할 수 있는 기술

• KV Cache 규모감:

  • 70B 모델, 128K context → 40GB
  • 5M context → 320GB
  • 클로드/GPT 급 서비스에서는 500GB 이상 추정

• CXL이란: PCIe 슬롯을 통해 DRAM을 확장하고, 여러 서버가 동일한 메모리에 나노초 레이턴시로 직접 접근(load/store)할 수 있는 프로토콜

• Maru: XCENA가 개발한 CXL 기반 KV Cache 스토리지 엔진 오픈소스 (GitHub)

  • LMCache에 스토리지 백엔드로 통합
  • 네트워크 전송 없이 메모리 주소만 공유하여 KV Cache 공유
  • 벤치마크: CXL 백엔드가 TCP 기반 P2P 대비 우수한 TTFT 성능

• 시사점: CXL은 아직 에코시스템이 초기 단계(스위치 비용 높음)이지만, KV Cache 공유 문제의 근본적 해결책이 될 수 있음. VectorDB에서도 CXL 활용 사례가 늘고 있다고 하니 주시할 필요 있음

업계 트렌드 & 시사점​

• "좋은 모델" → "좋은 서빙"으로 관심 이동: 작년까지는 모델 성능이 화두였지만, 올해는 서빙 품질(latency, throughput, scale-out)이 핵심 키워드
• KV Cache가 모든 세션을 관통하는 주제: Cache 압축(KV-Compress), Cache 공유(LMCache), Cache 저장(CXL) 등 다양한 레이어에서 연구 활발
• Kubernetes 네이티브 inference: Gateway Inference Extension, CRDs 등 K8s 생태계와의 깊은 통합이 진행 중
• PD Disaggregation 확산: Prefill과 Decode를 분리하는 아키텍처가 production 환경에서 실질적으로 도입되기 시작
• Observability의 중요성: 대규모 서빙에서 모니터링/메트릭 수집이 "있으면 좋은 것"에서 "필수"로 격상

팀 적용 포인트​

• LMCache 스터디: Prompt Caching 전략을 이미 다루고 있으니, LMCache를 통한 클러스터 레벨 KV Cache 공유 방안 검토
• Production Stack 테스트: 멀티 인스턴스 서빙이 필요한 시점에 vLLM Production Stack을 레퍼런스로 활용 가능. Helm Chart로 빠르게 PoC 가능
• Inference 메트릭 기반 Auto-scaling: GPU 사용률이 아닌 queue depth, latency 기반 스케일링 방식을 On-Prem 프로젝트에 적용 검토
• CXL 동향 모니터링: 당장 적용은 어렵지만, VectorDB + CXL 조합은 우리 RAG 파이프라인과 직결되는 주제. Maru 프로젝트 워치

전체 후기​

vLLM을 production level에서 실제로 사용해본 경험이 없어서 구체적으로 고민해본 적은 없었는데, 실제 서비스 단계에서 사용하려면 단순히 좋은 모델이 있는 것을 넘어서 latency를 줄이고 throughput도 고려하면서 효율적으로 좋은 성능을 내기 위한 노력이 필요하다는 것을 알게 되었다.

K8s, Helm, CXL, NPU, DRAM 등 인프라/하드웨어 레벨의 내용도 많이 등장해서 공부할 게 많다는 생각이 들었다.

References​

• vLLM Korea Meetup 이벤트 페이지
• vLLM GitHub Releases
• vLLM Production Stack
• Maru - CXL KV Cache Engine (XCENA)
• vLLM-RBLN 문서 (리벨리온)
• LMCache

TL;DR​

1979년 Apple II를 킬러앱으로 만든 VisiCalc을 500줄의 C 코드로 재구현한 프로젝트가 스프레드시트의 본질을 보여준다. 셀, 수식, 참조, 재계산이라는 핵심 추상화는 47년간 변하지 않았지만, 원본이 16KB RAM에서 동작한 반면 현대적 구현은 171KB를 사용한다. 전체 그리드 재계산 방식은 단순하지만, 실무급 스프레드시트에는 의존성 그래프 기반 증분 재계산이 필수적이다. 이 프로젝트는 데이터 모델링, 파싱, 의존성 관리, 반응형 UI가 결합된 프로그래밍의 축소판을 보여준다.

Key Takeaways​

• 스프레드시트의 데이터 모델은 극도로 단순하다: 각 셀은 EMPTY, NUM, LABEL, FORMULA 네 가지 타입 중 하나이며, 이 추상화는 1979년이나 2026년이나 동일하다
• 재귀 하강 파서(recursive descent parser)로 수식을 평가하면 연산자 우선순위가 호출 깊이로 자연스럽게 해결된다: 에러 처리는 IEEE 754의 NAN 전파 특성을 활용해 우아하게 구현 가능
• 전체 그리드 재계산은 구현은 쉽지만 실무에는 부적합하다: 수천 개 이상의 셀이 얽힌 실무 스프레드시트에서는 의존성 그래프 기반 증분 재계산이 필수적이며, 이는 빌드 시스템과 유사한 문제다
• 메모리 제약이 설계를 결정한다: 원본 VisiCalc은 16KB RAM에서 동작하기 위해 빈 셀에 메모리를 할당하지 않았지만, 현대적 정적 배열 구현은 171KB를 소비한다
• 표면적 단순함 아래 깊은 복잡성이 숨어있다: 파일 I/O, 상대/절대 참조, 순환 참조 감지, undo 같은 기능들이 실제 프로덕션 스프레드시트와 교육용 프로토타입을 구분한다

상세 내용​

셀이라는 보편적 추상화​

스프레드시트의 데이터 모델은 놀랄 만큼 단순하다. zserge의 구현에서 셀 하나는 타입 플래그, float 값, 그리고 사용자 입력 원문을 담는 128바이트 버퍼로 구성된다:

struct cell {
    int type;     // EMPTY, NUM, LABEL, FORMULA
    float val;
    char text[MAXIN];
};

그리드는 26열(A~Z) × 50행의 2차원 배열이다. 원본 VisiCalc은 256행 × 64열, 현대의 Excel은 104만 행 × 1만 6천 열을 지원하지만, 핵심 추상화는 동일하다.

이 구현의 정적 메모리 할당량은 약 171KB인데, 실제 Apple II의 16KB RAM에서는 절대 동작할 수 없는 크기다. 원본 VisiCalc이 어셈블리 수준에서 얼마나 극한의 메모리 최적화를 했는지 역으로 보여주는 대목이다. 빈 셀에는 메모리를 할당하지 않고, 입력된 셀만 동적으로 관리했을 가능성이 높다. 1979년의 메모리 관리는 그 자체로 하나의 엔지니어링 도전이었다.

재귀 하강 파서로 수식 평가하기​

VisiCalc에서 수식은 =가 아니라 +로 시작한다. +A1+A2*B1 같은 형태다. 이를 평가하기 위해 고전적인 재귀 하강 파서(recursive descent parser)를 구현했다.

파서 구조를 따라가면 컴파일러 교과서의 축약판을 읽는 느낌이다. 최상위 expr 함수가 덧셈·뺄셈으로 분리된 term을 처리하고, term은 곱셈·나눗셈으로 분리된 primary를 처리한다. primary는 숫자, 셀 참조, @SUM 같은 함수 호출, 괄호 표현식 중 하나다. 연산자 우선순위가 파서의 호출 깊이로 자연스럽게 해결되는 구조다.

struct parser {
    const char *s, *p;
    struct grid *g;
};

셀 참조 파싱도 흥미롭다. 단순히 sscanf로 A1을 읽을 수도 있지만, AB123 같은 다중 문자 열 이름도 지원하도록 직접 파싱한다. 열 문자를 26진법 숫자로 변환하고 행 번호를 정수로 읽는, 작지만 실용적인 설계다.

에러 처리는 NAN 전파로 우아하게 해결했다. NAN에 어떤 연산을 해도 NAN이 되는 IEEE 754 부동소수점의 특성을 활용한 것이다. 별도의 에러 코드나 예외 처리 없이 수식 체인 전체에 에러가 자연스럽게 퍼진다.

다만 원문의 코드 스니펫과 실제 GitHub 소스 사이에 불일치가 있다. 글에서 파서 구조체의 멤버는 pos(정수)로 정의되어 있지만, 본문 코드에서는 *p->p를 반복적으로 참조한다. GitHub의 실제 코드를 보면 멤버 변수가 const char *s, *p로 변경되어 있다. 따라해보려는 독자라면 GitHub 소스를 기준으로 삼는 게 안전하다.

재계산 전략: 단순함의 힘과 한계​

스프레드시트의 핵심 난제는 반응성(reactivity)이다. A1이 바뀌면 A1을 참조하는 모든 셀이 연쇄적으로 갱신되어야 한다. 이를 해결하는 방법은 크게 두 가지다: 의존성 그래프를 추적해서 변경된 셀만 정확히 갱신하거나, 전체 그리드를 반복 재계산하거나.

zserge는 원본 VisiCalc의 접근법을 따랐다. 셀이 변경될 때마다 전체 그리드를 행 우선 순서로 순회하며 모든 수식을 재평가한다:

void recalc(struct grid *g) {
    for (int pass = 0; pass < 100; pass++) {
        int changed = 0;
        // 전체 셀을 순회하며 수식 재평가
        // 값이 변경되면 changed = 1
        if (!changed) break;
    }
}

한 번의 패스로 모든 의존성이 해결되지 않을 수 있으므로(가령 A3이 A1을 참조하는데 A1의 수식이 아직 계산되지 않은 경우), 변경이 감지되지 않을 때까지 최대 100번 반복한다.

원본 VisiCalc은 이 재계산이 느려서 수동 재계산 명령(!)을 제공했고, 매뉴얼에서는 "모든 의존성이 해결될 때까지 여러 번 실행하라"고 안내했다. 당시 컴퓨터에서는 대형 스프레드시트의 재계산에 수 초가 걸렸기 때문이다.

zserge는 글에서 "의존성 그래프 유지는 대부분의 스프레드시트에서 과도한 설계(overkill)"라고 썼는데, 이 부분이 Hacker News에서 가장 뜨거운 반론을 불러일으켰다. 복수의 댓글이 "과도하기는커녕, 장난감 수준을 넘어서는 모든 스프레드시트에서 의존성 그래프는 절대적으로 필요하다"고 반박했다.

실제로 현대 Excel의 재계산 엔진은 정교한 의존성 추적 시스템 위에 구축되어 있다. Microsoft Research의 유명한 논문 "Build Systems à la Carte"는 스프레드시트를 일종의 빌드 시스템으로 분석하면서, 의존성 그래프 기반 증분 재계산이 왜 필수적인지를 이론적으로 보여준다. 수천 개의 셀이 복잡하게 얽힌 실무 스프레드시트에서 매번 전체를 재계산하면 사용자 경험이 심각하게 저하된다.

47년간 변하지 않은 것, 그리고 변한 것​

이 프로젝트가 증명하는 것은 스프레드시트의 핵심 추상화가 놀랍도록 안정적이라는 사실이다. 셀, 수식, 참조, 재계산, 그리드. 1979년이나 2026년이나 동일하다. VisiCalc을 FORTRAN 66으로 재구현해서 PDP-11에서 돌리는 프로젝트도 있고, VisiCalc의 원저자 Dan Bricklin이 직접 2008년경에 JavaScript로 만든 SocialCalc도 있다. 언어와 플랫폼이 바뀌어도 본질은 그대로다.

그런데 변하지 않은 것 못지않게, 47년 동안 쌓여온 복잡성도 주목할 만하다. 이 구현에서 빠진 것을 나열하면 오히려 현대 스프레드시트의 진짜 어려움이 보인다:

• 파일 I/O
• 수식 복사 시 셀 참조 자동 조정(상대/절대 참조)
• 열 너비 조절
• 행/열 고정
• 범위 이동
• 되돌리기(undo)
• 순환 참조 감지와 복구

한 교육자는 고등학생 AP 컴퓨터과학 수업에서 스프레드시트 구현을 프로젝트로 진행했는데, 일부 학생들의 구현이 "과하게 정교해져서" 보는 재미가 쏠쏠했다고 회상했다. 입력값을 원본 그대로 저장할지 가공해서 저장할지 같은 설계 판단에서 시니어 개발자도 배울 점이 있었다고 한다.

스프레드시트는 프로그래밍의 축소판이다. 데이터 모델링, 파싱, 의존성 관리, 반응형 UI가 모두 들어 있다. 500줄의 C 코드로 이 본질을 꺼내 보여준 것이 이 프로젝트의 진짜 가치다. 그리고 "그게 다가 아니다"라고 지적하는 커뮤니티의 토론이, 표면 아래에 숨은 깊이를 드러내 준다.

References​

• VisiCalc reconstructed - zserge
• 500줄의 C 코드로 되살린 VisiCalc, 47년간 변하지 않은 스프레드시트의 본질 - 박재홍의 실리콘밸리 위키독스 블로그
• Build Systems à la Carte - Microsoft Research

TL;DR​

Moonshot AI가 제안한 Attention Residuals(AttnRes)는 Transformer의 고정된 잔차 연결을 학습 가능한 어텐션 메커니즘으로 교체하는 기법입니다. 각 레이어가 이전 레이어들의 출력을 균등하게 더하는 대신, 소프트맥스 어텐션으로 "어떤 깊이의 표현을 얼마나 참조할지" 학습하여 깊이 방향 게이팅을 구현합니다. Kimi Linear 48B 모델에서 GPQA-Diamond가 36.9→44.4로 향상되었고, 스케일링 법칙 실험에서는 기존 대비 1.25배 컴퓨트를 투입한 것과 동등한 성능을 보였습니다. Block AttnRes 변형은 메모리 오버헤드를 O(Ld)에서 O(Nd)로 줄여 실용성을 확보했습니다.

Key Takeaways​

• 깊이 방향 어텐션: 레이어 간 정보 흐름을 고정된 덧셈에서 학습 가능한 어텐션으로 전환하여 각 레이어가 필요한 깊이의 표현을 선택적으로 참조 가능
• 실질적 성능 개선: 다단계 추론(GPQA-Diamond +7.5점), 수학(Math +3.6점), 코드 생성(HumanEval +3.1점) 등 전 분야에서 일관된 향상
• 컴퓨트 효율성: 기존 방식 대비 약 20% 학습 컴퓨트 절감 효과로 대규모 모델 학습 비용 감소 및 AutoML/NAS 이터레이션 가속화
• Block AttnRes로 실용성 확보: 8개 블록으로 나누면 Full AttnRes 성능 대부분을 유지하면서 메모리 오버헤드를 획기적으로 감소
• 상호 보완적 개선: FlashAttention 등 효율성 중심 기법과 동시 적용 가능하여 품질과 효율성을 함께 향상

상세 내용​

기존 잔차 연결의 구조적 한계​

2017년 "Attention Is All You Need" 이후 Transformer 아키텍처의 근간은 놀라울 정도로 바뀌지 않았습니다. 멀티헤드 어텐션, FFN, 그리고 잔차 연결이 그대로 유지되고 있죠. 특히 잔차 연결은 ResNet 시절부터 이어져 온 "이전 레이어 출력을 그냥 더한다"는 단순한 방식을 거의 그대로 사용합니다.

현대 LLM의 표준인 PreNorm Transformer에서 잔차 연결은 매우 단순하게 작동합니다. 각 레이어의 출력을 이전까지의 누적값에 가중치 1로 그냥 더하는 구조로, 수식으로 표현하면 h_l = h_{l-1} + f_l(h_{l-1})입니다.

직관적이고 구현도 간단하지만, 레이어가 깊어질수록 두 가지 치명적인 문제가 발생합니다:

1. 은닉 상태의 무제한 증가: 레이어 수에 비례해 은닉 상태의 크기가 계속 커집니다
2. 레이어 기여도 희석: 40번째 레이어의 출력이 아무리 중요한 정보를 담고 있어도 앞선 39개 레이어의 누적값에 묻혀버립니다

Hacker News의 한 개발자는 이 문제를 명쾌하게 정리했습니다. "표준 방식에서는 첫 번째 레이어만 원본 입력을 직접 보고, 이후 모든 레이어는 이전 레이어의 출력만 봅니다. 각 레이어가 원본 입력이나 특정 중간 표현을 선택적으로 참조할 방법이 없습니다."

이 문제는 학계에서 꽤 오래전부터 알려져 있었지만, "그래도 잘 작동하니까"라는 이유로 근본적인 해결 없이 넘어가고 있었습니다.

AttnRes의 핵심: 깊이 방향 어텐션​

AttnRes의 아이디어는 개념적으로 깔끔합니다. 각 레이어가 이전 레이어들의 출력을 "균등하게 더하는" 대신, 소프트맥스 어텐션으로 "어떤 레이어의 출력을 얼마나 참고할지" 학습하게 만드는 것입니다.

구체적으로, l번째 레이어의 입력은 h_l = Σ α_{i→l} · v_i로 계산됩니다. 여기서 α는 학습된 가중치로, 이전 모든 레이어 출력에 대한 소프트맥스 어텐션 스코어입니다. 각 레이어는 d차원의 pseudo-query 벡터 w_l 하나만 추가로 학습하면 됩니다.

토큰 간 어텐션이 "어떤 토큰을 참조할까"를 학습하듯, AttnRes는 "어떤 깊이의 표현을 참조할까"를 학습합니다.

Hacker News에서 한 댓글은 이 구조가 LSTM의 입력 게이트(input gate)와 유사하다고 지적했습니다. LSTM이 이전 시간 스텝의 정보를 선택적으로 기억하고 잊는 것처럼, AttnRes는 이전 레이어의 정보를 선택적으로 조합합니다. 이전 시퀀스의 시간 축에서 하던 게이팅을 네트워크의 깊이 축으로 가져온 셈입니다.

어텐션 메커니즘 내부로의 확장​

Attention Residuals는 두 가지 차원에서 작동합니다. 첫째는 위에서 설명한 레이어 간 깊이 방향 어텐션이고, 둘째는 어텐션 연산 자체 내부에 잔차 경로를 추가하는 것입니다.

기존 트랜스포머에서 잔차 연결은 어텐션 블록의 바깥에 적용됩니다. 즉, output = input + Attention(input) 형태입니다. 하지만 어텐션 연산 내부에서는 이런 잔차 경로가 없었습니다.

기존 Self-Attention: Attention(Q, K, V) = softmax(QK^T / √d_k)V

Attention Residuals는 이 구조에 잔차 경로를 추가하여, 어텐션 출력이 단순히 가중합된 Value만이 아니라 원래 입력 정보도 직접적으로 보존하도록 합니다. 이를 통해 모델이 "이 토큰은 다른 토큰들을 참조할 필요가 적다"는 판단을 더 쉽게 할 수 있습니다.

특히 긴 시퀀스를 처리할 때 어텐션 스코어의 분포가 극단적으로 치우치는 현상(어텐션 싱크 등)을 완화하는 데 도움이 됩니다.

Block AttnRes: 실용성을 위한 타협​

Full AttnRes가 이론적으로 최적이지만, 실제 대규모 모델에 적용하면 O(Ld) 메모리가 필요합니다. 100개 이상의 레이어를 가진 최신 LLM에서는 무시할 수 없는 오버헤드입니다.

이를 해결하기 위해 제안된 Block AttnRes는 레이어들을 N개 블록으로 묶고, 블록 내부에서는 기존 잔차 연결을 사용하되 블록 간에만 어텐션을 적용합니다. 약 8개 블록으로 나누면 Full AttnRes 성능의 대부분을 회복하면서도 메모리 오버헤드를 O(Nd)로 줄일 수 있습니다.

연구팀은 이를 "실질적인 드롭인 대체제"로 제시합니다. Hacker News 커뮤니티에서도 이 블록 구조가 핵심이라는 반응이 많았습니다. 이론적으로 아름다운 Full AttnRes보다, 실제로 기존 모델에 바로 적용할 수 있는 Block AttnRes가 이 연구의 진짜 기여라는 것입니다.

구현 관점에서 보면, 이 기법은 기존 트랜스포머 코드에 최소한의 수정만으로 적용할 수 있다는 장점이 있습니다. 추가되는 파라미터도 적고, 연산 오버헤드도 크지 않습니다.

벤치마크: 숫자로 보는 실질적 개선​

연구팀은 Kimi Linear 48B(3B activated, MoE 구조) 모델에 1.4T 토큰을 학습시켜 비교했습니다. 결과는 전 분야에서 일관된 개선을 보여줍니다:

일반 추론

• MMLU: 73.5 → 74.6
• BBH: 76.3 → 78.0

다단계 추론 (가장 인상적)

• GPQA-Diamond: 36.9 → 44.4 (+7.5점)

수학 및 코드

• Math: 53.5 → 57.1
• HumanEval: 59.1 → 62.2
• MBPP: 72.0 → 73.9

중국어

• C-Eval: 79.6 → 82.5

스케일링 법칙 실험은 더 의미심장합니다. Block AttnRes를 적용한 모델이 기존 방식으로 1.25배 더 많은 컴퓨트를 투입해 학습한 모델과 동등한 손실값을 달성했습니다.

Hacker News의 한 댓글은 이를 "학습에 필요한 컴퓨트를 약 20% 절감하는 효과"로 해석하면서, 이것이 단순히 거대 모델 학습 비용을 줄이는 것 이상의 의미가 있다고 지적했습니다. 자동화된 모델 아키텍처 탐색(AutoML/NAS)의 이터레이션 속도도 그만큼 빨라지기 때문입니다.

어텐션 메커니즘 개선의 맥락​

어텐션 메커니즘의 개선은 현재 AI 연구에서 가장 활발한 분야 중 하나입니다:

• FlashAttention: 메모리 접근 패턴 최적화로 속도와 메모리 효율 개선
• MQA/GQA: Key/Value 헤드 공유로 추론 시 KV 캐시 메모리 절약
• Ring/Striped Attention: 시퀀스 분산 처리로 컨텍스트 길이 확장

Attention Residuals는 이들과 다른 축의 개선입니다. 위의 기법들이 주로 효율성(속도, 메모리)에 초점을 맞춘다면, Attention Residuals는 어텐션의 표현력과 학습 안정성이라는 품질 측면에 집중합니다.

중요한 것은 이 기법이 FlashAttention 등과 상호 보완적이라는 점입니다. 즉, 동시에 적용할 수 있어 효율성과 품질을 함께 개선할 수 있는 가능성이 있습니다.

한국 개발자를 위한 실무 적용 가이드​

LLM을 직접 학습하거나 파인튜닝하는 팀이라면 이 기법을 실험해볼 가치가 있습니다. 특히 다음 상황에서 효과적일 수 있습니다:

1. 긴 문서 처리: 한국어 모델에서 장문맥 처리 성능 개선
2. RAG 파이프라인: 컨텍스트 활용도가 떨어지는 문제 완화
3. 다단계 추론: GPQA-Diamond에서 보인 것처럼 복잡한 추론 태스크에서 특히 효과적

MoonshotAI는 중국의 AI 스타트업으로 Kimi라는 장문맥(long-context) LLM으로 알려져 있습니다. 이 팀이 어텐션 메커니즘 개선 연구를 공개한 것은, 긴 컨텍스트 처리에서 어텐션 메커니즘의 한계를 실제로 경험하고 그 해법을 모색한 결과일 가능성이 높습니다.

GitHub에 코드가 공개되어 있으므로, 기존 학습 코드에 통합하는 데 큰 어려움은 없을 것으로 보입니다. 다만 아직 초기 연구 단계이므로 다양한 태스크와 모델 규모에서의 검증이 필요합니다. 논문과 코드를 함께 살펴보며, 자신의 유스케이스에 맞는지 먼저 소규모 실험으로 확인하는 것을 권합니다.

학습 역학의 변화​

AttnRes가 벤치마크 수치 너머로 흥미로운 점은 학습 역학(training dynamics)의 변화입니다. 기존 PreNorm에서 레이어가 깊어질수록 개별 레이어의 기여도가 희석되는 문제를 해결하여, 각 레이어가 실제로 필요한 정보를 선택적으로 참조할 수 있게 됩니다.

이는 깊은 네트워크에서도 그래디언트가 안정적으로 흐르고, 각 레이어가 의미 있는 변환을 학습할 수 있는 환경을 제공합니다. PreNorm의 희석 문제를 완화하면서도 학습의 안정성은 유지하는 균형점을 찾은 것입니다.

References​

• Attention Residuals: Transformer의 잔차 연결을 '학습 가능한 어텐션'으로 바꾸자 - 박재홍의 위키독스 블로그
• MoonshotAI의 Attention Residuals: 트랜스포머 어텐션 메커니즘을 개선하는 새로운 접근 - TTJ 테크뉴스
• MoonshotAI Attention Residuals GitHub Repository

TL;DR​

AI 에이전트 개발에서 컨텍스트 엔지니어링은 모델 파인튜닝보다 빠른 반복과 확장성을 제공한다. Manus 팀은 KV-cache 히트율을 핵심 지표로 삼아 지연시간과 비용을 최적화했으며, 프롬프트 접두사 안정화, 추가 전용 컨텍스트 설계, 명시적 캐시 중단점 설정 등의 원칙을 통해 에이전트 성능을 개선했다. 컨텍스트 구성 방식이 에이전트의 속도, 복구 능력, 확장성을 결정하는 핵심 요소다.

Key Takeaways​

• KV-cache 히트율이 프로덕션 AI 에이전트의 가장 중요한 지표: 캐시된 토큰 비용은 캐시되지 않은 토큰 대비 최대 10배 저렴하며(Claude Sonnet 기준), TTFT와 추론 비용에 직접적 영향을 미친다.
• 컨텍스트 엔지니어링이 파인튜닝보다 빠른 피드백 루프 제공: 모델 훈련은 주 단위 반복이 필요하지만, 컨텍스트 엔지니어링은 시간 단위로 개선사항 배포가 가능하여 PMF 탐색 단계에 적합하다.
• 프롬프트 접두사 안정성 유지가 필수: 단 하나의 토큰 변경도 이후 모든 캐시를 무효화하므로, 시스템 프롬프트에 타임스탬프 같은 동적 값을 포함하지 않아야 한다.
• 추가 전용(append-only) 컨텍스트 설계 원칙: 이전 작업이나 관찰을 수정하지 않고, JSON 직렬화 시 키 순서를 보장하여 캐시 일관성을 유지해야 한다.
• 에이전트는 챗봇과 다른 토큰 비율 특성: 평균 입력:출력 토큰 비율이 100:1로, 프리필링 단계가 압도적으로 많아 KV-cache 최적화가 더욱 중요하다.

상세 내용​

컨텍스트 엔지니어링의 전략적 선택​

Manus 팀은 프로젝트 초기에 중요한 기술적 분기점에 직면했다. 오픈소스 모델을 파인튜닝하여 엔드투엔드 에이전트를 구축할 것인가, 아니면 최신 LLM의 문맥 내 학습(in-context learning) 능력을 활용할 것인가?

BERT 시대의 NLP 개발 경험은 명확한 교훈을 제공했다. 당시 모델은 작았지만 파인튜닝과 평가에 주 단위 시간이 소요되었고, 이러한 느린 피드백 루프는 빠르게 변화하는 애플리케이션 개발, 특히 PMF(Product-Market Fit) 이전 단계에서 치명적인 단점이었다. GPT-3와 Flan-T5의 등장은 문맥 내 학습이라는 새로운 패러다임을 열었고, Manus는 여기에 베팅하기로 결정했다.

이 선택의 핵심 이점은 개선사항을 몇 주가 아닌 몇 시간 내에 배포할 수 있다는 점이다. 더 중요한 것은 제품이 기반 모델과 직교(orthogonal)하도록 유지한다는 점이다. "모델의 발전이 밀물이라면, Manus는 바닷바닥에 고정된 기둥이 아닌 배가 되고자 한다"는 표현이 이를 잘 설명한다.

KV-Cache 중심 설계의 중요성​

프로덕션 환경에서 AI 에이전트의 성능을 좌우하는 가장 중요한 단일 지표는 KV-cache 히트율이다. 이는 지연시간과 비용 모두에 직접적인 영향을 미친다.

에이전트의 작동 방식과 토큰 비율​

일반적인 에이전트는 다음과 같이 작동한다:

1. 사용자 입력 수신
2. 현재 컨텍스트 기반으로 액션 선택
3. 환경(예: VM 샌드박스)에서 액션 실행
4. 관찰 결과를 컨텍스트에 추가
5. 작업 완료까지 반복

이 과정에서 컨텍스트는 매 단계마다 증가하지만, 출력(주로 구조화된 함수 호출)은 상대적으로 짧다. Manus의 경우 평균 입력:출력 토큰 비율이 약 100:1로, 챗봇과 비교해 프리필링과 디코딩 간 비율이 극단적으로 치우쳐 있다.

비용 최적화의 핵심​

KV-cache를 활용하면 TTFT(Time To First Token)와 추론 비용을 극적으로 줄일 수 있다. Claude Sonnet을 예로 들면:

• 캐시되지 않은 토큰: 3 USD/MTok
• 캐시된 토큰: 0.30 USD/MTok
• 10배의 비용 차이

KV-Cache 히트율 향상을 위한 핵심 원칙​

1. 프롬프트 접두사를 안정적으로 유지​

LLM의 자기회귀적 특성상 단 하나의 토큰 차이만으로도 그 이후의 모든 캐시가 무효화된다. 흔한 실수는 시스템 프롬프트 시작 부분에 초 단위 타임스탬프를 포함하는 것이다. 모델이 현재 시간을 알 수 있게 하지만, 캐시 히트율을 심각하게 저하시킨다.

2. 컨텍스트를 추가 전용(Append-Only)으로 설계​

• 이전 작업이나 관찰을 수정하지 말 것
• 직렬화가 결정적(deterministic)이도록 보장
• 많은 프로그래밍 언어와 라이브러리가 JSON 객체 직렬화 시 안정적인 키 순서를 보장하지 않으므로 주의가 필요

3. 캐시 중단점을 명시적으로 표시​

일부 모델 제공업체나 추론 프레임워크는 자동 증분 접두사 캐싱을 지원하지 않는다. 이런 경우 컨텍스트에 수동으로 캐시 중단점을 삽입해야 한다. 캐시 만료 가능성을 고려하고, 최소한 시스템 프롬프트 끝을 포함하도록 설정해야 한다.

vLLM 같은 프레임워크로 모델을 자체 호스팅할 경우, 접두사/프롬프트 캐싱이 활성화되어 있는지 확인이 필요하다.

확률적 대학원생 하강법(Stochastic Graduate Descent)​

Manus 팀은 더 나은 컨텍스트 구성 방법을 발견할 때마다 에이전트 프레임워크를 네 번이나 재구축했다. 이러한 아키텍처 검색, 프롬프트 조정, 경험적 추측의 수동 프로세스를 팀은 "확률적 대학원생 하강법(Stochastic Graduate Descent, SGD)"이라고 부른다. 우아하지는 않지만 효과적이다.

컨텍스트 엔지니어링은 여전히 실험적 과학의 영역에 있으며, 수백만 사용자를 대상으로 한 실제 테스트를 통해 검증된 패턴이 중요하다.

미래를 위한 설계 원칙​

맥락(context)이 에이전트의 행동을 정의한다:

• 실행 속도
• 복구 능력
• 확장 가능성

모델이 더 강력하고, 빠르고, 저렴해지고 있지만, 아무리 뛰어난 능력도 메모리, 환경, 피드백의 필요성을 대체할 수 없다. 에이전트의 미래는 컨텍스트 하나하나로 구축될 것이다.

References​

• AI 에이전트를 위한 컨텍스트 엔지니어링: Manus 구축에서 얻은 교훈

TL;DR​

보안 연구자 Can Boluk는 LLM의 코드 편집 인터페이스(하네스)만 개선하여 16개 모델의 성능을 극적으로 향상시켰다. "Hashline"이라는 새로운 편집 도구는 각 코드 줄에 2~3자리 해시를 부여해 정확한 문자열 재현 없이 줄 참조를 가능하게 했다. 그 결과 Grok Code Fast 1 모델은 6.7%에서 68.3%로 성능이 급증했고, 평균 출력 토큰은 20% 감소했다. 모델 자체는 전혀 변경하지 않고 도구 인터페이스만 바꾼 성과다.

Key Takeaways​

• 하네스(Harness) 설계가 모델 성능의 병목: 어떤 모델이 가장 우수한가보다 모델과 코드베이스 간 인터페이스가 실제 성능을 좌우한다. Claude나 OpenAI의 기본 도구는 특정 모델에 최적화되어 있어 다른 모델에선 실패율이 50% 이상 발생한다.
• 줄 해시 기반 참조의 혁신: Hashline은 정확한 문자열 매칭 대신 2~3자리 해시로 코드 줄을 식별해, 모델이 긴 문자열을 재현할 필요를 없앴다. 이는 토큰 효율성과 편집 정확도를 동시에 개선한다.
• 모델 비의존적 최적화: 동일한 하네스 개선이 GPT-4o, Claude Sonnet, Gemini 등 15개 이상의 모델에서 일관되게 성능 향상을 보였다. 이는 프롬프트 엔지니어링보다 도구 인터페이스 설계가 더 범용적인 개선 방법임을 시사한다.
• 실무 적용 가능성: 기존 str_replace나 apply_patch 도구의 한계(긴 인덴트 처리, 특수문자 이스케이핑 등)를 인지하고, 간단한 해시 기반 인터페이스로 대체하면 즉각적인 성능 개선이 가능하다.
• 토큰 경제성: 출력 토큰 20% 감소는 비용 절감뿐 아니라 응답 속도 개선으로 이어지며, 이는 프로덕션 환경에서 직접적인 사용자 경험 향상으로 연결된다.

상세 내용​

하네스 문제: 간과된 병목 지점​

AI 코딩 어시스턴트 논의는 대부분 "어떤 모델이 최고인가"에 집중한다. GPT-5.3 vs Opus, Gemini vs 이번 주 출시된 신모델. 하지만 Can Boluk는 이 프레임이 근본적으로 오해를 유발한다고 지적한다. 실제 병목은 훨씬 평범한 곳에 있다: 하네스(harness).

하네스는 단순한 UI가 아니다. 모든 입력 토큰의 소스이자, 모델의 출력과 실제 코드베이스 변경 사이의 인터페이스다. Claude Code는 여전히 서브에이전트 출력에서 원시 JSONL을 유출하며 수십만 토큰을 낭비한다. 도구 스키마, 에러 메시지, 상태 관리 등 "모델이 무엇을 바꿀지 안다"와 "문제가 실제로 해결된다" 사이의 모든 것이 하네스 영역이며, 실무에서 대부분의 실패가 발생하는 지점이다.

Boluk는 오픈소스 코딩 에이전트 Pi의 포크인 oh-my-pi를 유지보수하며 1,300개 이상의 커밋을 작성했다. 모델 비의존적 설계 덕분에 모델은 단순한 파라미터가 되고, 진짜 변수는 하네스가 된다. 바로 여기서 "상상 이상의 제어권"을 행사할 수 있다.

기존 편집 도구의 한계​

현재 주류 편집 도구는 두 가지다:

1. OpenAI Codex의 apply_patch OpenAI 특화 diff 형식의 문자열 블롭을 입력받는다. 구조화된 스키마가 아닌 엄격한 규칙을 따르는 텍스트다. OpenAI 게이트웨이에서 토큰 선택 프로세스가 이 구조에 맞게 편향되어 있을 것으로 추정되지만, 다른 모델에 적용하면 패치 실패율이 급증한다. Grok 4는 50.7%, GLM-4.7은 46.2%의 실패율을 기록했다. 모델이 나쁜 게 아니라 "언어를 모르는" 것이다.

2. Claude Code의 str_replace 대부분의 도구가 채택한 방식이다. "이 정확한 문자열을 찾아서 저것으로 교체해라." 간단하지만 치명적인 문제들이 있다:

• 인덴테이션 지옥: 긴 인덴트를 포함한 문자열을 정확히 재현해야 함
• 특수문자 이스케이핑: JSON/XML 컨텍스트에서 따옴표, 개행 등을 올바르게 이스케이프해야 함
• 토큰 낭비: 변경하려는 줄 전체를 두 번(원본과 교체본) 재현해야 함
• 미묘한 불일치: 공백 하나 차이로 전체 편집이 실패

이런 도구들은 특정 모델(GPT 계열, Claude 계열)에 최적화되어 있어, 다른 모델은 구조적으로 불리한 위치에 놓인다.

Hashline: 해시 기반 줄 참조​

Boluk의 해결책은 우아하게 단순하다. 파일의 각 줄에 2~3자리 해시를 부여한다:

1:a3|function hello() {
2:f1|  return "world";
3:0e|}

모델이 편집을 요청할 때는 이렇게 말한다:

"2:f1 줄을 다음으로 교체: return 'universe';"

정확한 문자열 재현이 필요 없다. 해시가 줄을 고유하게 식별하므로, 모델은 짧은 참조만으로 위치를 지정할 수 있다. 이는:

• 토큰 효율성: 긴 문자열 재현 불필요
• 오류 감소: 인덴트나 이스케이핑 실수 원천 차단
• 범용성: 모델 특화 편향 없이 모든 LLM이 동일하게 사용 가능

벤치마크 결과: 극적인 성능 향상​

결과는 놀라웠다:

• Grok Code Fast 1: 6.7% → 68.3% (10배 이상 향상)
• 전체 모델 평균 출력 토큰: 약 20% 감소
• 16개 모델 전반에 걸친 일관된 개선

중요한 점은 모델 가중치를 전혀 건드리지 않았다는 것이다. 파인튜닝도, 프롬프트 대수술도 없었다. 순전히 편집 도구 하나만 바꿨다.

이는 현재 LLM 코딩 성능 논의가 얼마나 잘못된 지점에 집중하고 있는지 보여준다. "어떤 모델이 최고인가"보다 "어떤 인터페이스로 모델을 활용하는가"가 실제 성능을 좌우한다.

실무적 시사점​

1. 하네스 설계는 모델 선택만큼 중요하다 프로덕션 코딩 어시스턴트를 구축한다면, 모델 API 선택에 쏟는 시간만큼 도구 인터페이스 설계에 투자해야 한다. 기존 도구(str_replace, apply_patch)의 한계를 이해하고, 당신의 유즈케이스에 맞는 인터페이스를 설계하라.

2. 모델 비의존적 최적화의 가치 Hashline의 개선은 GPT, Claude, Gemini, Grok 등 다양한 모델군에 걸쳐 작동했다. 특정 모델에 종속된 최적화보다 범용적인 인터페이스 개선이 장기적으로 더 큰 가치를 제공한다. 모델은 계속 바뀌지만, 좋은 하네스는 남는다.

3. 토큰 경제성과 사용자 경험 20% 토큰 감소는 단순 비용 절감이 아니다. 응답 속도가 빨라지고, 컨텍스트 윈도우를 더 효율적으로 사용할 수 있으며, 사용자는 더 빠른 피드백을 받는다. 토큰 레벨의 최적화가 직접적인 UX 개선으로 이어진다.

4. 오픈소스와 실험의 중요성 Boluk의 발견은 상업적 제품(Claude Code, Cursor 등)이 놓친 지점이다. 모델 비의존적인 오픈소스 하네스에서 자유롭게 실험할 수 있었기에 가능했다. AI 인프라 스택에서 오픈소스 레이어의 가치를 재확인하는 사례다.

더 넓은 맥락: Harness Engineering의 부상​

Hashline 실험은 새로운 엔지니어링 디시플린의 필요성을 보여준다: Harness Engineering. 프롬프트 엔지니어링이 모델에게 "무엇을 요청할지"를 다룬다면, 하네스 엔지니어링은 "어떻게 상호작용할지"를 설계한다.

좋은 하네스는:

• 모델의 출력을 실행 가능한 액션으로 신뢰성 있게 변환한다
• 토큰 효율성을 극대화한다
• 다양한 모델에 걸쳐 작동한다
• 에러 핸들링과 상태 관리를 우아하게 처리한다

이는 단순한 UI/UX 문제가 아니다. 분산 시스템 설계, API 설계, 컴파일러 인터페이스 설계와 맥을 같이하는 시스템 엔지니어링 문제다.

결론: 도구가 모델만큼 중요하다​

Can Boluk의 실험은 명확한 메시지를 전달한다: 당신의 AI 시스템 성능은 가장 약한 고리, 즉 하네스에 의해 결정된다. 최신 최고 모델을 사용하더라도, 형편없는 편집 인터페이스는 그 잠재력을 절반도 끌어내지 못한다.

실무 AI 엔지니어로서 우리는 모델 선택뿐 아니라 인터페이스 설계에 진지하게 투자해야 한다. Hashline은 하나의 예시일 뿐이다. 당신의 도메인, 당신의 워크플로우에는 또 다른 "해시라인"이 기다리고 있을 수 있다. 모델 벤치마크를 쫓는 대신, 하네스를 해킹하라.

References​

• I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. - Can Boluk
• oh-my-pi - GitHub Repository (추정)
• Pi - Original Open-Source Coding Agent (추정)

TL;DR​

AI 에이전트가 복잡한 프로덕션 환경에서 안정적으로 동작하려면 프롬프트와 컨텍스트 설계만으로는 부족합니다. 하네스 엔지니어링(Harness Engineering)은 에이전트를 감싸는 전체 환경—저장소 구조, CI/CD, 린터, 외부 도구 연결, 피드백 루프—을 설계하는 새로운 엔지니어링 패러다임입니다. OpenAI의 실험에서 하네스만 제대로 구축했을 뿐인데 AI가 백만 라인의 프로덕션 소프트웨어를 완성했으며, 이는 엔지니어의 역할이 "코드 작성"에서 "환경 설계"로 전환되고 있음을 보여줍니다. 프롬프트 엔지니어링이 "무엇을 물어볼까"에 집중한다면, 컨텍스트 엔지니어링은 "무엇을 보여줄까", 하네스 엔지니어링은 "전체 환경을 어떻게 설계할까"라는 질문에 답합니다.

Key Takeaways​

• 하네스는 에이전트의 "운영체제"다: 린터, CI/CD, 아키텍처 가드레일, 외부 도구 연결 등 에이전트 바깥의 모든 제약과 피드백 장치가 하네스를 구성하며, 이것이 프롬프트보다 더 큰 영향을 미친다.
• 프롬프트 → 컨텍스트 → 하네스 순서로 범위가 확장된다: 프롬프트 엔지니어링이 "지시문 최적화"라면, 컨텍스트 엔지니어링은 "LLM이 보는 모든 정보 설계", 하네스 엔지니어링은 "에이전트를 감싸는 시스템 전체 설계"다.
• 컨텍스트는 많이 넣는다고 좋은 게 아니다: Context Poisoning, Distraction, Confusion 같은 실패 패턴이 존재하며, 컨텍스트 윈도우를 "딱 맞는 정보"로 채우는 것이 핵심이다(Karpathy의 정의).
• MCP와 Agent Skills는 하네스의 핵심 구성 요소다: MCP(Model Context Protocol)는 외부 시스템 연결을, Agent Skills는 반복 작업의 재사용 가능한 지침화를 담당하며, 이 둘이 에이전트의 실행 환경을 구성한다.
• 엔지니어의 역할이 재정의되고 있다: 수동 코딩에서 벗어나 "에이전트가 자율적으로 소프트웨어를 구축할 수 있는 환경 설계"로 초점이 이동하며, 이는 단순한 도구 변화가 아닌 엔지니어링 패러다임의 전환이다.

상세 내용​

하네스 엔지니어링의 정의와 등장 배경​

AI 에이전트를 실제 운영 환경에 투입하면 흥미로운 현상이 발생합니다. 같은 모델을 사용하는데도 프로젝트 A에서는 완벽하게 동작하고, 프로젝트 B에서는 엉뚱한 결과를 내놓습니다. 프롬프트를 아무리 다듬어도 이 격차는 좁혀지지 않습니다. 원인은 대부분 에이전트를 "감싸는 환경"의 차이에 있습니다.

2026년 2월, OpenAI는 놀라운 실험 결과를 발표했습니다. 에이전트를 감싸는 환경만 제대로 구축했을 뿐인데, 수동으로 작성된 코드 없이 AI가 생성한 백만 개 라인에 달하는 프로덕션 소프트웨어를 완성했습니다. 이 결과는 모델 성능이 아닌 "환경 설계"가 에이전트의 실제 성과를 결정한다는 것을 보여줍니다.

**하네스(Harness)**는 AI 에이전트가 안정적으로 작업을 수행할 수 있도록 감싸는 스캐폴딩(scaffolding)이자 피드백 루프가 구축된 전체 환경을 의미합니다. 저장소 구조, CI 설정, 포맷 규칙, 패키지 관리자, 애플리케이션 프레임워크, 프로젝트 지시 사항, 외부 도구 연결, 린터 등 에이전트 바깥에서 동작하는 모든 시스템이 하네스에 포함됩니다. 이는 에이전트가 궤도를 이탈하지 않도록 돕는 기반 인프라 역할을 합니다.

**하네스 엔지니어링(Harness Engineering)**은 엔지니어의 주된 역할이 수동 코드 작성에서 벗어나, 에이전트가 소프트웨어를 자율적으로 구축하고 유지보수할 수 있도록 환경을 설계하고 의도를 명확히 지정하며 피드백 루프를 구축하는 작업으로 재정의된 것을 의미합니다.

프롬프트, 컨텍스트, 하네스의 관계​

세 개념은 포함 관계를 이루며 안쪽부터 바깥쪽으로 확장됩니다:

비유를 들자면, 프롬프트 엔지니어링이 말에게 "오른쪽으로 돌아"라는 음성 명령을 내리는 것이라면, 컨텍스트 엔지니어링은 말에게 지도와 이정표를 보여주는 것이고, 하네스 엔지니어링은 고삐, 안장, 울타리, 도로 정비까지 합쳐서 말 열 마리를 동시에 안전하게 달리게 만드는 전체 설계에 해당합니다.

개념의 진화 과정​

2023~2024: 프롬프트 엔지니어링 시대 ChatGPT에 질문 하나를 던지고 답변 하나를 받는 단순한 구조였습니다. 역할을 부여하고, 단계별로 지시하고, 예시를 넣는 것만으로 원하는 결과를 얻을 수 있었습니다.

2025 중반: 컨텍스트 엔지니어링의 부상 2025년 6월, 전 OpenAI 연구원 안드레이 카르파티(Andrej Karpathy)가 "프롬프트보다 컨텍스트 엔지니어링이 핵심"이라고 언급하면서 패러다임이 전환되었습니다. 단순히 질문을 잘 쓰는 것이 아니라, LLM이 추론할 때 "무엇을 보게 할지" 시스템 수준에서 관리하는 접근이 필요해졌습니다.

LangChain은 이를 컴퓨터에 비유합니다: "LLM은 CPU이고, 컨텍스트 윈도우는 RAM이다. 운영체제가 CPU의 RAM에 무엇을 올릴지 관리하듯, 컨텍스트 엔지니어링도 같은 역할을 한다."

2026년 2월: 하네스 엔지니어링의 등장 AI 에이전트가 본격적으로 운영 환경에 투입되면서 컨텍스트 설계만으로는 해결되지 않는 문제들이 드러났습니다. 팀 컨벤션 위반, 아키텍처 의존성 방향 문제, 병렬 실행 시 파일 충돌, 생성 코드의 점진적 품질 저하 등입니다. 이는 "모델에게 무엇을 보여줄까"가 아니라 "시스템이 무엇을 막고, 측정하고, 고칠 것인가"의 문제입니다.

해시코프(HashiCorp) 공동 창업자 미첼 하시모토(Mitchell Hashimoto)가 2026년 2월 5일 자신의 블로그에서 에이전트의 실수를 방지하는 장치를 쌓아가는 작업을 "하네스 엔지니어링"이라 명명했고, 며칠 뒤 OpenAI도 공식 보고서를 발표하면서 용어가 빠르게 확산되었습니다.

하네스의 핵심 구성 요소​

하네스는 다음과 같은 요소들로 구성됩니다:

1. 저장소 구조와 컨벤션

• 폴더 구조, 네이밍 규칙, 코드 스타일 가이드
• 린터, 포매터 설정
• 아키텍처 가드레일(의존성 방향 검증 등)

2. CI/CD와 자동화 파이프라인

• 자동 테스트, 빌드, 배포 워크플로우
• 에이전트가 생성한 코드에 대한 즉각적인 피드백

3. 외부 도구 연결 (MCP)

• 이슈 트래커, 데이터베이스, API 등 외부 시스템과의 통합
• Model Context Protocol을 통한 표준화된 연결

4. 재사용 가능한 작업 지침 (Agent Skills)

• 반복적인 작업 절차의 문서화
• SKILL.md 형태로 작성된 실행 가능한 가이드

컨텍스트 엔지니어링: 정보 환경 설계​

컨텍스트 엔지니어링은 LLM의 컨텍스트 윈도우에 "무엇을 넣고 무엇을 버릴지" 설계하는 작업입니다. 컨텍스트 윈도우가 수백만 토큰으로 확장되면서 "넣을 수 있는 공간"이 커졌지만, 정보량이 아니라 적합성이 핵심입니다.

컨텍스트 윈도우에 들어갈 수 있는 요소들:

• 시스템 프롬프트: 역할, 제약, 출력 형식
• 대화 이력: 이전 질문과 답변의 흐름
• 검색 문서: RAG로 가져온 관련 문서
• 도구 출력: API 응답, 코드 실행 결과
• 사용자 입력: 현재 질문과 첨부 파일
• 메모리: 장기 기억으로 주입하는 요약 정보

컨텍스트 실패 패턴:

1. Context Poisoning (컨텍스트 오염): 한 번 잘못 들어간 정보가 이후 대화 전체에 걸쳐 사실처럼 전달되는 현상
2. Context Distraction (컨텍스트 산만): 관련 없는 정보가 너무 많아 핵심 근거를 놓치는 현상 (2025년 연구에서 평균 45% 성능 저하)
3. Context Confusion (컨텍스트 혼란): 불필요한 정보가 모델의 판단에 영향을 미치는 현상

프롬프트 vs 컨텍스트 엔지니어링 비교:

고객 문의를 처리하는 CS 챗봇을 예로 들면:

• 프롬프트만 사용: "배송 관련 문의를 하면 조회 방법을 알려줘" → 일반적 응대는 가능하지만 실시간 데이터 접근 불가
• 컨텍스트 설계 추가: 주문 DB와 배송 API를 연결하고, 실시간 상태를 컨텍스트에 주입해 정확한 답변 생성

MCP: 외부 시스템 연결의 표준​

Model Context Protocol(MCP)은 Claude Code 같은 AI 에이전트가 외부 데이터 소스나 도구에 접근할 수 있게 해주는 프로토콜입니다. 전동드릴에 비트를 바꿔 끼우듯, MCP 서버를 연결하면 에이전트가 접근할 수 있는 정보의 범위가 달라집니다.

MCP 서버 연결 방식:

1. HTTP 원격 서버 (권장):

claude mcp add --transport http notion https://mcp.notion.com/mcp

2. 로컬 stdio 서버:

claude mcp add --transport stdio github -- npx -y @modelcontextprotocol/server-github

3. 환경 변수 전달:

claude mcp add --transport stdio --env GITHUB_TOKEN=ghp_xxx github -- npx -y @modelcontextprotocol/server-github

적용 범위(Scope) 설정:

• --scope local: 현재 프로젝트에서만 (기본값)
• --scope project: 팀 공유 (.mcp.json 파일에 저장)
• --scope user: 모든 프로젝트에서 사용

project 스코프를 사용하면 서버 정의는 팀과 공유하되, 인증 토큰은 각 개발자의 로컬 환경에서 관리하는 구조가 됩니다.

Agent Skills: 재사용 가능한 작업 지침​

Agent Skills는 반복되는 작업 절차를 문서화하여 에이전트가 읽고 수행할 수 있게 만드는 방식입니다. Anthropic이 2025년 10월 발표하고 12월에 오픈 스탠다드로 공개한 이 개념은 SKILL.md 파일을 중심으로 작동합니다.

스킬 디렉터리 구조:

code-review/
├── SKILL.md              # 필수: 에이전트가 따를 지침
├── scripts/              # 선택: 실행 스크립트
│   └── run-lint.sh
├── references/           # 선택: 보조 문서
│   └── review-checklist.md
└── assets/               # 선택: 템플릿, 설정 파일
    └── comment-template.md

Progressive Disclosure 원칙: 스킬은 한꺼번에 로드되지 않고 세 단계로 읽힙니다:

• Phase 1: Metadata (~100 tokens) - name, description만 읽음
• Phase 2: Instructions (< 5000 tokens 권장) - SKILL.md 전체 읽음
• Phase 3: Resources (필요한 만큼) - scripts, references 파일 읽음

SKILL.md 작성 예시:

---
name: api-test-runner
description: >-
  API 엔드포인트의 응답 상태, 스키마, 성능을 자동으로 검증한다.
  API 테스트, 엔드포인트 점검, 응답 검증이 필요할 때 사용한다.
---

## 목적
프로덕션 배포 전 API 엔드포인트의 정상 동작을 확인한다.

## 실행 방법
1. `scripts/run-api-test.sh` 실행
2. 실패 시 `references/troubleshooting.md` 참고

중요 작성 포인트:

• description은 WHAT(무엇을 하는지)과 WHEN(언제 쓰는지)을 모두 포함
• 1/2인칭 표현("나는", "당신은") 피하고 3인칭으로 서술
• name은 디렉터리 이름과 일치, 소문자-하이픈만 사용

실무 적용 시나리오​

시나리오: 이슈 기반 코드 수정 자동화

1. 프롬프트만 사용: "ISSUE-1234를 고쳐줘" → 이슈 내용을 모르므로 추가 설명 필요
2. 컨텍스트 추가: GitHub API로 이슈 내용을 가져와 컨텍스트에 주입 → 이슈 내용 파악
3. 하네스 구축:
   • MCP로 GitHub 연결
   • Agent Skill로 "이슈 분석 → 코드 수정 → 테스트 → PR 생성" 워크플로우 정의
   • CI에서 자동 테스트 실행
   • 린터로 코드 스타일 검증

결과: "ISSUE-1234를 고쳐줘"라는 한 문장으로 전체 프로세스가 자동 실행됩니다.

References​

• OpenAI: Harness engineering: leveraging Codex in an agent-first world (2026.02)
• Can Boluk: I Improved 15 LLMs at Coding in One Afternoon (2026.02)
• MadPlay: 프롬프트와 컨텍스트를 넘어, AI 에이전트를 위한 하네스 엔지니어링
• MadPlay: 컨텍스트 엔지니어링: 프롬프트를 넘어 맥락을 설계하는 방법
• MadPlay: Claude Code에서 MCP 서버를 연동하는 방법과 주의할 점
• MadPlay: 에이전트 스킬(Agent Skills)이란 무엇이고, 어떻게 만들까
• Agent Skills Official Specification
• Anthropic: Context Engineering Guide

TL;DR​

OpenAI의 공동 창립자 Ilya Sutskever가 John Carmack에게 제시한 약 30편의 딥러닝 필독 논문 목록입니다. "이것들을 제대로 학습하면 오늘날 중요한 것의 90%를 알게 될 것"이라는 말과 함께 공유된 이 리스트는 Transformer 아키텍처, RNN/LSTM, ResNet 같은 핵심 모델부터 복잡도 이론과 Kolmogorov Complexity 같은 이론적 기초까지 망라합니다. 현대 딥러닝의 필수 개념들을 체계적으로 학습할 수 있는 커리큘럼으로, AI Research Engineer라면 반드시 숙지해야 할 핵심 지식의 정수입니다.

Key Takeaways​

• 선별된 핵심 논문들: 방대한 딥러닝 연구 중에서 실제로 중요한 90%를 커버하는 약 30편으로 압축된 ��리큘럼
• 이론과 실무의 균형: Attention 메커니즘, ResNet 같은 실용적 아키텍처부터 Kolmogorov Complexity, MDL 같은 이론적 기초까지 포괄
• 시대를 초월한 기초: RNN/LSTM 같은 초기 시퀀스 모델부터 Transformer, Scaling Laws까지 진화 과정을 이해할 수 있는 구성
• 실용적 구현 자료: 대부분의 논문에 코드 구현이나 주석이 달린 튜토리얼이 포함되어 있어 학습과 동시에 실습 가능
• 압축과 복잡도 관점: MDL, Kolmogorov Complexity 등을 통해 신경망을 정보 이론적 관점에서 이해하는 깊이 있는 시각 제공

상세 내용​

리딩 리스트의 배경과 의의​

OpenAI의 Chief Scientist이자 공동 창립자인 Ilya Sutskever는 게임 개발의 전설 John Carmack에게 "만약 이것들을 제대로 학습한다면, 오늘날 중요한 것의 90%를 알게 될 것"이라는 말과 함께 이 리스트를 공유했습니다. 이는 단순한 논문 목록이 아니라, 현대 딥러닝의 핵심을 관통하는 체계적인 학습 경로입니다.

이 목록의 특징은 최신 논문만을 추구하지 않고, 시대를 초월한 기본 원리와 실용적인 최신 기술을 균형있게 배치했다는 점입니다. 이론적 기초(Kolmogorov Complexity, MDL)부터 실용적 아키텍처(Transformer, ResNet), 그리고 스케일링 법칙까지 딥러닝의 과거, 현재, 미래를 아우릅니다.

핵심 아키텍처 논문들​

Transformer와 Attention 메커니즘

• Attention Is All You Need (Vaswani et al.): 현대 LLM의 근간이 되는 Transformer 아키텍처의 원조 논문
• The Annotated Transformer: Harvard NLP 팀이 제공하는 line-by-line 구현과 주석. 단순히 논문을 읽는 것을 넘어 실제로 작동하는 코드와 함께 학습 가능
• Neural Machine Translation by Jointly Learning to Align and Translate (Bahdanau et al.): Attention 메커니즘의 초기 제안으로, Transformer 이전에 어떻게 시퀀스 모델에서 선택적 집중이 가능했는지 이해하는 데 필수

RNN과 LSTM의 이해

• The Unreasonable Effectiveness of Recurrent Neural Networks (Andrej Karpathy): RNN의 놀라운 생성 능력을 직관적으로 보여주는 블로그 포스트. 문자 단위 언어 모델이 어떻게 의미 있는 텍스트를 생성하는지 설명
• Understanding LSTM Networks (Christopher Olah): LSTM의 내부 구조를 시각적으로 명쾌하게 설명한 고전적 튜토리얼
• Recurrent Neural Network Regularization (Zaremba et al.): RNN 학습의 실용적 측면을 다루며, dropout 같은 정규화 기법의 적용

Convolutional Networks와 Computer Vision

• ImageNet Classification with Deep Convolutional Neural Networks (AlexNet): 딥러닝 부흥의 시발점이 된 역사적 논문
• Deep Residual Learning for Image Recognition (ResNet): Skip connection을 통해 매우 깊은 네트워크 학습을 가능하게 한 혁신
• Identity Mappings in Deep Residual Networks: ResNet의 개선 버전으로, 왜 특정 구조가 더 잘 작동하는지에 대한 이론적 이해 제공

이론적 기초와 철학​

복잡도와 정보 이론

• The First Law of Complexodynamics (Scott Aaronson): Kolmogorov complexity를 활용하여 물리 시스템의 복잡도가 시간에 따라 어떻게 변하는지 설명. 엔트로피는 단조 증가하지만 "재미있음(interestingness)"은 증가했다 감소한다는 통찰 제공

• Keeping Neural Networks Simple by Minimizing the Description Length of the Weights (Hinton): MDL(Minimum Description Length) 원리를 신경망에 적용. 모델의 복잡도를 가중치를 설명하는 데 필요한 비트 수로 측정

• A Tutorial Introduction to the Minimum Description Length Principle: 압축과 학습의 관계에 대한 근본적 이해. 좋은 모델은 데이터를 잘 압축하는 모델

• Kolmogorov Complexity and Algorithmic Randomness: 객체의 본질적 복잡도를 정의하는 수학적 프레임워크. 일반화와 압축의 관계를 이해하는 이론적 토대

철학적 고려사항

• Machine Super Intelligence (Shane Legg): DeepMind 공동 창립자의 박사 논문. AGI에 대한 수학적이고 철학적인 접근

실용적 기법과 시스템​

스케일링과 병렬화

• Scaling Laws for Neural Language Models (Kaplan et al.): 모델 크기, 데이터, 컴퓨팅의 관계를 정량화한 획기적 연구. 현대 LLM 개발의 나침반 역할

• GPipe: Easy Scaling with Micro-Batch Pipeline Parallelism: 거대 모델을 효율적으로 학습시키기 위한 파이프라인 병렬화 기법

특수 아키텍처와 응용

• Pointer Networks: 출력이 가변 길이 이산 토큰인 문제(조합 최적화 등)를 다루는 혁신적 접근

• Neural Turing Machines: 외부 메모리를 가진 신경망으로, 알고리즘 학습 가능성 탐구

• Deep Speech 2: End-to-end 음성 인식의 실용적 구현

• Order Matters: Sequence to sequence for sets: 순서가 없는 집합을 다루면서도 순서가 중요한 시퀀스 모델의 특성 활용

관계 추론과 구조​

• A simple neural network module for relational reasoning: 객체 간 관계를 추론하는 네트워크 모듈

• Relational recurrent neural networks: RNN에 관계 추론 능력을 부여

• Neural Message Passing for Quantum Chemistry: 그래프 신경망을 화학 분자 특성 예측에 적용

생성 모델과 표현 학습​

• Variational Lossy Autoencoder: VAE의 개선된 형태로, 더 나은 생성과 압축의 균형

교육 자료​

• CS231n: Convolutional Neural Networks for Visual Recognition: Stanford의 유명한 딥러닝 강의. 체계적인 기초 학습을 위한 커리큘럼

학습 순서와 전략​

이 리스트를 효과적으로 학습하기 위한 제안:

1. 기초부터 시작: CS231n으로 기본 개념 확립
2. RNN 계열 이해: Karpathy와 Olah의 블로그로 직관 형성 → LSTM 정규화로 실용 지식 습득
3. Attention과 Transformer: Bahdanau attention → Transformer 논문 → Annotated Transformer로 구현까지
4. 컴퓨터 비전 기초: AlexNet → ResNet으로 발전 과정 이해
5. 이론적 심화: MDL, Kolmogorov Complexity로 깊이 있는 이해
6. 스케일링과 실용화: Scaling Laws, GPipe 등으로 현대적 관점 확보

대부분의 자료가 코드나 상세한 튜토리얼과 함께 제공되므로, 단순히 읽는 것을 넘어 직접 구현하고 실험하는 것이 핵심입니다. The Annotated Transformer처럼 working notebook 형태의 자료들은 학습과 실습을 동시에 가능하게 합니다.

References​

• Original Reading List - Ilya 30u30 Folder
• The Annotated Transformer
• The Annotated Transformer - GitHub
• The First Law of Complexodynamics - Scott Aaronson
• The Unreasonable Effectiveness of Recurrent Neural Networks - Andrej Karpathy
• Understanding LSTM Networks - Christopher Olah
• char-rnn GitHub Repository
• Recurrent Neural Network Regularization (ArXiv)
• LSTM Regularization Code
• Attention Is All You Need
• Scaling Laws for Neural Language Models

TL;DR​

디퓨전(diffusion) 기반 LLM은 기존 오토리그레시브 방식과 달리 여러 토큰을 병렬로 생성·정제하여 5~10배 빠른 추론 속도를 제공합니다. 이미지 생성에 혁신을 가져온 디퓨전 기술이 텍스트 생성으로 확장되고 있으며, 내장된 오류 수정 메커니즘과 메모리 대역폭 효율성이 핵심 장점입니다. 한편 엔터프라이즈 AI 도입에서는 기술보다 ROI가 우선이며, 레거시 시스템 통합과 실질적 비즈니스 가치 측정이 성공의 핵심입니다.

Key Takeaways​

• 디퓨전 LLM의 병렬 처리: 순차적 토큰 생성 대신 여러 토큰을 동시에 생성·정제하여 유사 품질 대비 5~10배 속도 향상 달성
• 메모리 효율성이 속도의 핵심: 가중치를 한 번 로드하여 여러 토큰에 적용하므로 메모리 대역폭 병목 현상을 크게 완화
• 내장된 오류 수정 메커니즘: 반복 정제 과정에서 자체적으로 실수를 교정할 수 있는 구조적 장점 (단, 환각 문제는 여전히 존재)
• 엔터프라이즈 AI는 ROI First: AI 투자 1달러당 실제 가치를 추적하는 것이 기술 선택보다 우선이며, TCO 기반 ROI 계산이 필수
• 레거시 시스템이 실제 시장: COBOL과 메인프레임 같은 레거시 코드 유지보수가 바이브코딩 도구보다 실질적 수요가 크며, 특화 LLM이 필요

상세 내용​

디퓨전 LLM의 작동 원리와 차별점​

기존 LLM(ChatGPT, Gemini 등)은 토큰을 왼쪽에서 오른쪽으로 하나씩 순차 생성하는 오토리그레시브(autoregressive) 방식을 사용합니다. 이는 본질적으로 순차적 연산이라 구조적 병목이 발생할 수밖에 없습니다.

반면 Inception이 개발 중인 디퓨전 LLM은 완전히 다른 접근법을 취합니다. 랜덤 토큰으로 시작해 여러 토큰을 병렬로 동시에 수정하면서 점진적으로 정제(denoising)합니다. 이는 이미지 디퓨전 모델이 노이즈 이미지에서 선명한 결과물을 만들어가는 것과 동일한 원리입니다.

학습 방식의 근본적 차이​

학습 방법론도 근본적으로 다릅니다:

• 기존 LLM: "다음 토큰 예측(next token prediction)" 목표로 학습
• 디퓨전 LLM: 깨끗한 텍스트에 의도적으로 오류를 주입한 뒤 "실수를 교정(error correction)" 하도록 학습

추론 시에도 이 철학이 이어져, 한 번에 최대한 많은 실수를 고치면서 깨끗한 출력을 만들어갑니다.

5~10배 속도 향상의 비밀: 메모리 대역폭​

디퓨전 LLM이 유사한 품질의 오토리그레시브 모델 대비 5~10배 빠른 이유는 메모리 대역폭 효율 덕분입니다.

기존 LLM은 각 토큰을 생성할 때마다 가중치를 메모리에서 로드해야 합니다. 이 과정에서 메모리 대역폭이 병목이 됩니다. 반면 디퓨전 모델은 가중치를 한 번 로드하면 여러 토큰에 동시에 적용할 수 있어 메모리 이동 횟수를 획기적으로 줄입니다.

내장된 오류 수정 메커니즘​

오토리그레시브 모델의 근본적 한계는 한 번 출력한 토큰을 되돌릴 수 없다는 점입니다. 한 번 잘못된 방향으로 가면 계속 잘못된 경로를 따라갈 수밖에 없습니다.

디퓨전 모델은 반복 정제 과정에서 실수를 수정할 수 있는 메커니즘이 구조적으로 내장되어 있습니다. 다만 Stefano Ermon CEO는 솔직하게 환각(hallucination) 문제가 완전히 해결된 것은 아니라고 인정했습니다.

현재 직면한 기술적 도전들​

디퓨전 LLM이 극복해야 할 과제들:

1. 반복 루프 문제 비슷한 내용을 계속 반복 생성하는 현상이 발생합니다. 이는 이미지 디퓨전의 "손가락 6개 문제"에 해당하며, Google의 Gemini Diffusion에서도 동일한 문제가 관찰되었습니다.

2. 가변 길이 처리 이미지는 고정 크기(예: 512×512)이지만 텍스트는 길이가 가변적입니다. 이를 처리하는 것이 핵심 기술적 도전입니다.

3. 이산(discrete) 데이터 처리 디퓨전 수학은 본질적으로 연속적입니다(편미분방정식, Fokker-Planck 방정식 기반). 반면 토큰은 유한하고 이산적이라, 이를 변환하는 새로운 수학적 프레임워크가 필요했습니다.

4. 설계 선택의 재검토 토크나이저를 비롯한 많은 설계 요소들이 오토리그레시브 모델에 최적화되어 있습니다. 디퓨전 모델에는 비최적적이며, 아직 개선 여지가 많습니다.

미래 방향: 추론, 새로운 아키텍처, 월드 모델​

Inception은 현재 추론(reasoning) 능력을 개발 중이며, 기존 o1이나 DeepSeek 방식과는 완전히 다른 접근이라고 합니다.

또한 트랜스포머 외에 상태 기반 모델(State Space Model) 같은 대안 아키텍처와도 결합 가능합니다. 월드 모델(world model) 분야에서는 디퓨전이 이미 핵심 기술로 자리잡고 있다고 언급했습니다.

ROI First: 엔터프라이즈 AI의 실질적 접근법​

업계에 "AI First", "Data First" 같은 버즈워드가 넘쳐나지만, Roomie의 Aldo Luévano 회장은 경영진이 실제로 원하는 것은 **"ROI First"**라고 강조합니다.

Roomie의 핵심 철학은 명확합니다: AI에 투자한 1달러당 얼마의 가치가 돌아오는지 추적하는 것입니다. 이를 위해 플랫폼에 ROI 추적 모듈을 내장했습니다.

프로세스는 다음과 같습니다:

1. 컨설턴트가 GPT 기반 대화를 통해 비즈니스 요구사항 파악
2. 수동/반자동 프로세스의 현재 TCO(Total Cost of Ownership) 계산
3. AI 도입 후의 TCO 예측
4. ROI 산출 및 추적

레거시 시스템: 간과된 거대 시장​

Cursor, Replit, Lovable 같은 바이브코딩 도구는 새로운 소프트웨어를 만드는 데 초점이 맞춰져 있습니다. 하지만 Luévano는 실제 시장의 대부분은 메인프레임과 COBOL 같은 레거시 시스템이라고 지적합니다.

Roomie는 11년간 금융, 은행, 소비재, 유통, 공공부문 등 다양한 프로젝트 경험에서 축적한 데이터로 모델을 학습시켰습니다. 특히 자연어로 레거시 코드의 유지보수와 신규 기능 개발을 지원하는 특화 LLM/SLM을 보유하고 있습니다.

COBOL 개발자들이 고령화되고 있어 이 문제가 더욱 절실해지고 있으며, 이는 많은 기업들이 직면한 실질적 과제입니다.

피지컬 AI와 로보틱스 통합​

Roomie는 원래 B2B 로보틱스 스타트업으로 시작했으며, 현재도 물리적 AI 모듈을 운영합니다.

에이전틱 AI와 물리적 디바이스(휴머노이드 로봇, 엣지 디바이스)를 통합하며, **컴퓨터 비전(CNN 기반)**으로 다음을 수행합니다:

• 공장 피킹(picking)
• 셀프 체크아웃
• 이상 패턴 감지

차별점은 단순 알림이 아니라, 패턴 인식 후 에이전트가 실제 액션을 취한다는 점입니다.

AI와 일자리: 솔직한 대화​

많은 회사들이 "AI가 일자리를 줄이지 않는다"고 말하지만, Luévano는 AI 도입이 인력 감축으로 이어질 수 있음을 솔직하게 인정했습니다.

다만 동시에 새로운 직종도 생겨날 것이라고 언급했습니다:

• 로봇 원격 조작
• 로봇 훈련 및 관리
• AI/로보틱스 UI 관리

이것이 사회 전체의 전환 과정이며, 투명한 대화가 필요하다는 입장입니다.

References​

• Generating text with diffusion (and ROI with LLMs) - Stack Overflow Blog
• Inception - Diffusion Language Models
• Roomie - Enterprise AI and Robotics Platform