8월 30일 일요일
AI 코딩의 속도가 빨라질수록 승부처는 생성량이 아니라 명세·검증·인프라를 함께 설계하고, 각 제약을 증거로 확인하며, 결과를 반복 재현하는 능력으로 이동한다. 이 변화는 코드 생성보다 검증 가능한 시스템 설계를 우선하게 만든다.
생성 속도보다 먼저 설계해야 할 것은 검증 경계다
에이전트가 더 많은 코드를 만들수록 사람은 의도와 품질 기준을 고정하고, 기계는 반복 가능한 검증을 맡아야 한다.
작은 성공 다음에 오는 품질의 벽
Figma의 도입 경험은 코딩 에이전트를 붙이는 일이 곧바로 조직 생산성으로 이어지지 않는다는 점을 보여준다. 단순하고 범위가 분명한 작업에서는 에이전트가 약 10배 빠르게 보일 수 있지만, 같은 방식을 큰 문제에 그대로 확장하면 버그와 나쁜 코드가 늘고 초기 신뢰가 무너진다. 이 실패 뒤에 필요한 것은 더 화려한 프롬프트가 아니라 어떤 일은 에이전트에 넘기고 어떤 판단은 사람이 보유할지 다시 나누는 설계다. 회의적인 숙련자가 발견한 예외와 코드베이스의 함정도 개인의 정신적 덕트 테이프로 남겨두지 않고 검증 과제로 바꿔야 한다.
사람은 의도를 고정하고 기계는 구현을 증명한다
스펙 주도 개발은 일회성 대화를 팀의 저장소에 남는 실행 경로로 바꾼다. 헌법은 보안과 품질 같은 협상 불가능한 원칙을, 명세는 무엇을 만들어야 하는지를, 계획은 어떤 기술로 만들지를, 태스크는 구현 순서를 기록한다. 사람은 명세가 실제 의도와 같은지 검토하고, 에이전트는 그 명세에서 코드와 테스트를 만든다. 형식 검증에서도 역할은 같다. Lean4의 작은 신뢰 커널은 복잡한 tactic이 만든 증명을 확인하지만, 잘못된 명세까지 바로잡아 주지는 않는다. upstream의 요구를 사람이 소유해야 downstream의 코드와 증명이 맞는 방향을 향한다.
검증을 결정적 흐름으로 내려보내기
속도를 안전하게 쓰려면 이미 알려진 검사를 매번 모델의 추론에 맡기지 않고 코드화해야 한다. Figma 사례가 말하듯 린터·컴파일러·단위 테스트처럼 빠르고 반복 가능한 검증은 에이전트가 수행하고, TDD에서는 먼저 실패하는 테스트를 세워 목표를 고정한 뒤 구현을 통과시킨다. 스펙 주도 흐름은 결과를 작은 검토 단위로 쪼개며, 한 계획을 약 20개의 10~100줄 PR로 나누는 사례도 제시한다. Lean의 zlib 변환은 약 일주일과 32,000줄의 증명이 필요한 더 강한 보증의 예다. 중요한 것은 모든 코드를 한 번에 형식화하는 것이 아니라 실패 비용이 큰 로직부터 계약과 불변식을 명시하는 순서다. 이 경계가 분명하면 에이전트의 산출량을 그대로 신뢰하지 않고, 각 단계에서 어떤 자동 검사와 사람의 판단이 필요한지 설명할 수 있다. 결과적으로 속도는 막연한 체감이 아니라 작고 검토 가능한 변경과 증거의 누적으로 측정된다. 따라서 검증은 생성 뒤의 부속 절차가 아니라 설계의 일부여야 한다. 또한 테스트가 통과했다는 사실만으로 요구사항이 옳다는 보장이 생기지는 않는다. 명세와 테스트가 같은 의도를 가리키는지 사람의 검토가 남아야 하며, 이 경계를 지켜야 자동화가 만든 자신감을 실제 품질로 오인하지 않는다. 실패 비용이 큰 부분부터 이 절차를 적용하는 이유도 여기에 있다. 에이전트가 만든 작은 변경도 왜 안전한지 설명할 수 있어야 다음 단계의 속도를 감당할 수 있다. 그 설명이 증거의 일부다.
AI 인프라의 승부처는 칩 단품을 넘어선다
엔비디아의 해자와 새로운 인프라 투자의 공통점은 모델 아래의 메모리·전력·공급망을 시스템으로 봐야 한다는 데 있다.
왜 AI 인프라 경쟁은 칩의 절대 성능보다 전체 시스템 설계로 이동하는가?
엔비디아의 지배력은 GPU 성능 하나가 아니라 CUDA 생태계, 고대역폭 메모리, 공급 계약과 생산 규모가 겹친 결과다. 그러나 같은 구조가 고객의 탈출 시도도 만든다. 중국 연구소와 서비스가 Huawei 칩을 사용하고, OpenAI는 자체 Jalapeno 추론 칩으로 비용과 전력 의존을 낮추려 하며, 애플은 통합 메모리로 용량과 대역폭의 선택을 다시 제시한다. a16z의 인프라 관점은 이 변화를 칩 교체로 축소하지 않는다. 추론이 늘수록 메모리·네트워크·전력·냉각·데이터센터가 함께 병목이 되므로, 성능을 말하려면 토큰당 전력과 실제 공급 가능성까지 같은 시스템 안에서 계산해야 한다.
- 01
해자: 소프트웨어와 공급망의 결합
CUDA용 코드와 인력의 축적은 다른 칩으로 옮길 때 소프트웨어와 연구 도구까지 다시 맞추게 만든다. 여기에 HBM과 대형 고객 계약, 공급망 규모가 더해져 단일 경쟁 제품이 즉시 지배력을 뒤집기 어렵다.
- 02
병목: 모델 남쪽의 물리 계층
a16z는 모델 자체보다 메모리·컴퓨트·네트워크·전력·냉각·데이터센터가 성장을 막는다고 본다. 칩 설계 주기는 보통 3~4년, 데이터센터 건설은 4~5년이어서 소프트웨어 수요의 속도를 물리적 공급이 그대로 따라가기 어렵다.
- 03
측정 기준: 전력당 토큰과 시스템 밀도
Jalapeno와 차세대 인프라 논의가 공통으로 가리키는 지표는 단순한 최고 성능이 아니다. 같은 전력으로 얼마나 많은 토큰을 만들 수 있는지, 메모리와 연결 구조가 모델을 받치는지, 데이터센터가 필요한 전력을 확보할 수 있는지가 구매와 확장의 조건이 된다.
따라서 엔비디아의 현재 해자가 곧 사라진다고 결론 내리기보다, 경쟁의 단위를 GPU에서 추론 시스템으로 다시 정의해야 한다. 중국산 칩, 자체 ASIC, 통합 메모리, 전력·냉각 설계는 서로 다른 제품처럼 보이지만 모두 같은 질문을 던진다. 필요한 모델을 실제 제약 안에서 얼마나 싸고 안정적으로 실행할 수 있는가?
오늘의 구현 신호 두 가지
모델 자체보다 사용 인터페이스와 작업별 선택지가 제품 경쟁을 가른다는 짧은 신호를 모았다.
- 01
a16z모델보다 인간·모델 인터페이스에 집중한 Cursor
Cursor는 모델 성능만 겨루기보다 인간과 모델이 상호작용하는 인터페이스에 집중해 사용자를 빠르게 확보했다. 이후 엔터프라이즈 영업, 자체 모델, 인수합병으로 경쟁 범위를 넓혔다는 신호다.
- 02
Peter Yang멀티모델 시대의 정답은 사용 사례별 선택
ChatGPT·Claude·Grok·Gemini는 한 줄 순위로 정리되지 않는다. 비교 결과는 ChatGPT의 실행, Claude의 디자인·계획, Gemini의 영상, Grok의 프로토타이핑처럼 사용 사례에 따라 강점이 갈린다고 말한다.
다음에 검증할 것은 현장 데이터와 스킬 거버넌스다
에이전트의 데모가 실제 운영 역량으로 바뀌는지 확인할 두 가지 조건을 남긴다.
- 1
현장 업무의 예외가 학습 자산으로 쌓이는가
실제 직원과 에이전트가 업무를 함께 수행할 때 도구 호출, 막힘, 실패, 예외와 수정 흔적이 트레이스로 남는지 본다. 지붕 수리나 장부 마감처럼 결과가 분명한 ground truth와 주간 회귀 테스트까지 연결될 때 데모와 운영의 간극이 줄어드는지 확인할 수 있다. 두 조건이 함께 기록될 때만 자동화가 통제 가능한 운영 체계로 남는다.
- 2
자동 진화 전에 스킬의 가드레일이 있는가
스킬 레지스트리에 소유자·버전·의존성·접근 권한·평가 결과가 기록되고, 호출 조건과 구조가 먼저 검증되는지 본다. 정책과 보안 통제 없이 자동 진화를 켜면 낮은 품질의 규칙과 취약점까지 조직 전체로 복제될 수 있다는 경고가 기준이다. 이 기록이 쌓여야 자동화가 개별 실험이 아니라 재사용 가능한 조직 능력이 된다.
아직 못 읽은 북마크
북마크를 고르는 중…