9월 5일 토요일
오늘 Tech 판의 공통점은 모델 능력보다 실행 경계다. 추론 서빙, SDLC 하네스, 에이전트 협업 모두 병목이 시스템 설계와 검증으로 이동하고 있다.
토큰 경제성은 GPU FLOPS만으로 결정되지 않는다
LLM 추론의 비용은 프리필과 디코드, KV 캐시, 배칭, Roofline 위치가 함께 만든다. 서비스 설계자는 빠른 첫 응답과 GPU당 처리량을 같은 표에서 봐야 한다.
프리필과 디코드는 다른 병목이다
AI 반도체 원문이 가장 먼저 분리하는 것은 LLM 추론의 두 단계다. 프리필은 사용자가 넣은 긴 입력을 한꺼번에 처리하며 계산 집약적이 되기 쉽다. 반대로 디코드는 새 토큰을 하나씩 순차 생성하므로 이미 저장된 Key와 Value를 계속 읽어야 하고, 메모리 대역폭에 묶인다. 같은 GPU를 써도 입력을 처리하는 시간과 답변을 이어 쓰는 시간의 병목이 다르기 때문에, 단일 벤치마크 숫자로 서비스 체감을 설명하기 어렵다. 특히 긴 문서 요약과 짧은 챗 응답, 에이전트의 반복 도구 호출은 서로 다른 비율로 프리필과 디코드를 사용한다. 운영자는 평균 토큰 속도만이 아니라 어떤 요청군이 어떤 자원을 붙잡는지 나눠 봐야 한다.
KV 캐시는 문맥 길이의 숨은 비용이다
긴 컨텍스트와 에이전트의 반복 호출이 늘면 KV 캐시는 HBM을 크게 점유한다. 사용자가 보는 것은 긴 대화 유지와 빠른 응답이지만, 운영자가 보는 것은 동시 사용자 수와 메모리 압박이다. 원문은 KV 용량을 줄이기 위한 재사용, 압축, 오프로딩 전략을 서비스 비용의 핵심 변수로 다룬다. 따라서 컨텍스트 창을 무조건 키우는 결정은 제품 기능이 아니라 인프라 예산과 지연 시간의 선택이기도 하다. 같은 모델도 문맥을 어떻게 보존하고 재사용하느냐에 따라 GPU 한 장이 감당하는 세션 수가 달라진다. 에이전트 제품일수록 이 비용은 백그라운드 반복 실행 때문에 사용자 눈에 보이지 않는 형태로 커진다.
스케줄링은 하드웨어 선택만큼 중요하다
정적 배칭만으로는 요청마다 다른 길이와 생성 속도를 효율적으로 처리하기 어렵다. 원문은 iteration-level scheduling, PagedAttention, prefix caching, chunked prefill, speculative decoding, prefill-decode disaggregation을 함께 설명한다. 이 기법들은 모두 같은 질문으로 돌아간다. 사용자가 원하는 인터랙티비티를 유지하면서 GPU당 처리량을 얼마나 끌어올릴 것인가. Roofline 분석은 그 선택이 연산 병목인지 메모리 병목인지 판단하는 기준점이 된다.
에이전트 SDLC의 핵심은 파일과 권한의 체인이다
INTENT.MD, 지식 업무 에이전트 인프라, 회사 지식 두뇌 사례는 모두 에이전트가 실행하기 전에 무엇을 읽고, 어디까지 바꾸며, 누가 승인하는지를 고정해야 한다고 말한다.
코드 작성 속도가 더 이상 병목이 아니라면 에이전트 개발 시스템은 무엇을 영속화해야 할까?
Claude Code 팀의 INTENT.MD 논의는 AI-native SDLC를 프롬프트 모음이 아니라 버전 관리되는 아티팩트 체인으로 본다. 아이디어는 intent.md에 고정되고, 승인된 의도는 spec.md, plan.md, 코드, 테스트, PR, 운영 이벤트로 이어진다. Composio 발표가 지식 업무 에이전트에서 강조한 여섯 원칙도 같은 구조를 다른 도메인에 옮긴 것이다. 중앙화된 작업 중심, 이력, 구조적 맥락, 자체 검증, 거버넌스, 가역성이 없으면 에이전트는 Salesforce, Notion, Gmail, Slack, Zendesk 사이에서 눈이 먼 상태로 행동한다. PromptQL의 회사 지식 두뇌 발표는 이 구조의 위험 경계를 더 좁힌다. 회사 전체 위키가 유용하려면 파일별 읽기·쓰기 권한, 사람의 승인, 사용자 자격 증명 기반 도구 실행이 필요하다.
- 01
의도의 영속화
INTENT.MD는 에이전트에게 넘길 목표를 대화창 밖의 파일로 고정한다. 중요한 점은 문서화 자체가 아니라 다음 단계의 spec, plan, 테스트, PR이 같은 의도를 추적할 수 있다는 것이다.
- 02
코딩 환경의 이식
코딩 에이전트가 먼저 발전한 이유는 저장소, 커밋 이력, 테스트, CI, 리뷰, 되돌리기가 이미 있었기 때문이다. 지식 업무 에이전트는 이 기반을 업무 앱 전반에 새로 만들어야 한다.
- 03
권한의 귀속
회사 지식 두뇌는 모든 맥락을 한곳에 모을수록 권한 상승 위험이 커진다. PromptQL 발표는 에이전트가 자체 자격 증명을 보관하는 대신 실제 사용자의 클레임으로 읽기와 도구 실행을 제한해야 한다고 설명한다.
- 04
검증과 가역성
코드의 실패는 테스트와 revert로 다룰 수 있지만, 잘못 보낸 이메일이나 삭제, 송금은 영구적일 수 있다. 그래서 지식 업무 에이전트에는 실행 전 샌드박스와 정책 게이트가 하네스의 핵심 기능이 된다.
에이전트 SDLC의 설계 단위는 더 좋은 답변 하나가 아니다. 의도 파일, 작업 이력, 조직 맥락, 권한 모델, 검증 결과가 이어지는 체인을 만들어야 장기 실행을 감사 가능한 소프트웨어 공정으로 바꿀 수 있다. 이 체인이 없으면 에이전트는 빠르게 움직일수록 더 위험해진다. 반대로 체인이 있으면 모델 교체, 스킬 변경, 자동화 범위 확대를 조직이 추적 가능한 실험으로 관리할 수 있다.
능력 확장은 신뢰 경계를 더 선명하게 만든다
Astra의 컴퓨터 사용 능력, 에이전트 간 컨텍스트 검색, 불확실성 보정, 국가별 AI 스택 주권은 서로 다른 층위지만 모두 실행 전에 어떤 경계를 검증할지 묻는다.
모델과 에이전트가 더 많은 일을 할수록 시스템은 어떤 검증 경계를 새로 가져야 할까?
- 1
실행 능력
Astra 첫인상은 컴퓨터 사용, 3D 작업, 장기 에이전트 작업에서 큰 도약을 말하지만 코딩과 프런트엔드에는 실수, 과잉 설계, 리뷰 대응 실패가 남았다고 정리한다. 능력 향상은 곧바로 완전 자율성을 뜻하지 않는다.
- 2
컨텍스트 검색
에이전트 간 협업 발표는 협업을 에이전트 숫자가 아니라 필요한 정보를 프라이버시 경계 안에서 컨텍스트 창에 올리는 검색 문제로 재정의한다. shared silo, 인간 매개, 블랙박스 검색은 자동화 수준과 정보 노출 위험 사이의 서로 다른 절충안이다.
- 3
불확실성 표시
불확실성 원문은 정확도만으로 부족하다고 본다. 모델이 어떤 주장에 얼마나 확신하는지 보정하지 못하면 자율주행, 예측, 과학 시스템에서 과신이 위험해진다. 확률적 예측과 신뢰도 표시는 답을 약하게 만드는 장식이 아니라 행동 기준이다.
- 4
스택 통제
AI 주권 논의는 컴퓨팅, 데이터, 모델, 애플리케이션 계층을 누가 통제하는지에 주목한다. 온톨로지와 검증 계층은 모델 답변을 국가·산업 맥락에 맞게 제한하는 장치다.
공통 결론은 능력이 커질수록 더 많은 자동화를 허용하라는 것이 아니다. 실행 권한, 컨텍스트 접근, 확신 보정, 스택 통제의 경계를 관찰 가능한 형태로 두어야 모델 개선이 운영 신뢰로 이어진다.
아직 못 읽은 북마크
북마크를 고르는 중…