$4억 칩 베팅이 바꾸는 AI 에이전트 도입 타이밍
Situational Awareness의 Source Foundry 4억 달러 투자가 보내는 AI 추론 비용 신호 — 불완전한 에이전트를 지금 올려야 하는 이유와 사고 이후 레이어를 쌓는 실전 방법을 짚는다.
에이전트는 완벽하지 않아도 지금 올리는 게 낫다. 이게 이 글의 핵심 결론이다. 단, 지금 올리면 사고가 반드시 난다 — 그 사고를 어떻게 다음 레이어로 바꾸느냐가 진짜 전략의 시작점이다.
논란 많은 펀드가 왜 4억을 칩에 쏟는가
Situational Awareness는 제법 시끄러운 펀드다. AI 투자 전략을 전면에 내세우면서도 올해 내내 잡음을 달고 다녔고, 그 와중에 칩 스타트업 Source Foundry에 4억 달러(약 5,600억 원)를 집어넣었다. "어려움에 처한 펀드가 여전히 대형 베팅을 한다"는 게 TechCrunch 기사의 요지인데, 정작 더 주목할 포인트는 다른 데 있다.
이 펀드는 스스로 AI를 써서 투자 결정을 내리는 구조다. 에이전트를 직접 굴리는 조직이 AI 추론에 필요한 실리콘에 대규모 자본을 쐈다는 것. 이건 단순한 칩 섹터 투자 스토리가 아니다. "앞으로 추론 비용이 더 내려간다"는 방향에 확신을 건 플레이어가, 그 방향이 맞다고 자기 돈으로 다시 검증한 것이다. 논란에 시달리는 와중에도 멈추지 않는다는 건 — 에이전트가 완벽하지 않아도 방향 자체는 의심하지 않는다는 뜻이기도 하다.
추론 비용 곡선이 꺾이면 설계 방식이 달라진다
AI 추론 비용이 빠르게 내려왔다는 건 이미 숫자로 확인된 사실이다. 20222025년 사이 주요 모델 API 가격은 대략 1020배 수준으로 떨어졌다. GPT-3 급 모델이 1,000토큰에 수십 달러이던 시절에서, 지금 Haiku 계열이 1,000토큰에 1센트 미만으로 돌아가는 현실까지 — 같은 3년 안에 일어난 일이다. Source Foundry 같은 칩 스타트업이 본격 양산 단계에 들어가면 이 곡선이 한 번 더 꺾인다는 게 $400M 투자의 핵심 논리다.
그 예측이 현실이 되면 에이전트를 설계하는 방식도 바뀐다. 지금은 많은 팀이 방어적 설계를 쓴다. Haiku로 초안을 뽑고 Sonnet으로 검수를 분리하거나, 컨텍스트를 최소화하거나, 한 번의 호출에 최대한 많이 뽑으려 한다. 전부 토큰 비용을 아끼는 구조다. 비용이 10분의 1로 더 내려가면 이 타협들이 의미 없어진다. 지금부터 "정확도를 최대화하는 구조"를 염두에 두고 설계하는 게 낫다. 그래야 비용이 떨어졌을 때 아키텍처를 처음부터 다시 짜는 수고를 피할 수 있다.
직접 해보니 알게 된 것인데, review_loop에서 Haiku 1차 필터 → Sonnet 2차 판단의 2단계를 처음 설계했을 때 Haiku 필터가 오히려 노이즈를 만들어 Sonnet 호출이 늘어나는 역효과가 있었다. 토큰 아끼려다 더 쓴 케이스다. 결국 처음부터 Sonnet 직행이 낫다는 결론이 났고, 비용이 더 내려갈수록 이 방향이 더 자연스러워진다는 확신이 강해진다.
"API 비용"이 아닌 진짜 비용을 계산해야 한다
에이전트 도입을 가로막는 이유로 가장 많이 나오는 게 API 비용이다. 틀린 말은 아닌데, 렌즈가 좁다. 진짜 비용은 에이전트가 없을 때 사람이 쓰는 시간이다. 더 정확히는 — 사람이 리소스 부족으로 그 일을 아예 포기하고 방치하는 기회 비용이다.
우리 팀 기준으로 계산해보면, blog 봇 한 건 발행에 Haiku 기준 약 1015만 토큰이 들어간다고 치면 건당 비용은 12원 수준이다. 같은 품질의 글을 조사·초안·검수 포함해서 사람이 쓰면 건당 2~4시간이 든다. 비교 자체가 성립이 안 된다. 월 API 비용이 5만 원이어도, 그게 주 10시간 이상의 반복 작업을 처리한다면 ROI는 명확하다. 칩 공급이 늘어 추론 비용이 절반으로 내려가면 이 계산은 더 극단적으로 기울어진다.
트레이드오프를 솔직히 얘기하자면 — 지금 올리면 불완전한 에이전트를 운영하면서 사고를 맞는 리스크가 있다. 우리도 겪었다. kpopdex에서 가짜 컴백 뉴스가 혼입됐고, vtuber 소속사가 오분류됐다. 반면 나중을 기다리면 그 사이 쌓였을 운영 경험과 실패 로그가 없다. 70점짜리 에이전트를 지금 돌리는 게 6개월 후 처음 올리는 에이전트보다 나은 이유가, 바로 그 6개월치 학습 데이터 때문이다.
에이전트를 실제로 올리면 생기는 일들
우리 팀 봇 파이프라인은 처음부터 지금 이 구조가 아니었다. 처음엔 "크롤 → 발행" 두 단계뿐이었다. 검수 루프는 발행 품질 문제가 터진 뒤에 붙었다. news_guard는 kpopdex 가짜 컴백 사고 이후 추가됐다. vtuber_guard는 소속사 오분류가 잡힌 이후 붙었다. 사고가 날 때마다 레이어가 하나씩 추가됐다.
에이전트 설계의 현실이 이렇다. 완벽한 구조를 먼저 그리고 올리는 게 아니라, 돌리다 터진 걸 막는 레이어를 계속 쌓아가는 방식. Situational Awareness가 논란 속에서도 계속 대형 베팅을 하는 구조와 닮아 있다 — 완벽하지 않아도 방향은 멈추지 않는다.
Source Foundry의 칩이 추론을 더 싸게 만들어준다면, 이 가드 레이어들을 더 정교하게 올릴 수 있게 된다. 지금은 발행 후 비동기로 돌아가는 Sonnet 검수가 있는데, 비용이 더 내려가면 발행 전 동기 판단 게이트로 바꾸는 게 현실적인 선택지가 된다. 실시간으로 Sonnet이 OK를 내줘야 INSERT가 되는 구조. 지금은 레이턴시와 비용 두 가지가 동시에 걸리는데, 칩 성능이 올라가면 둘 다 줄어든다. 그때 빠르게 올리려면 지금부터 뭔가가 이미 돌아가고 있어야 한다.
지금 당장 써먹을 수 있는 시사점
지금 수동으로 반복하는 것 중 가장 지루한 한 가지를 골라 에이전트를 붙여라. 거창한 자동화 로드맵부터 그리면 실패한다. "무엇을 자동화할 것인가"보다 "지금 당장 가장 귀찮은 게 뭔가"가 더 나은 시작 질문이다. 첫 번째 에이전트가 실제로 돌아야 두 번째가 나온다.
비용 계산에 API 요금만 넣지 마라. "이 에이전트 없으면 사람이 주 몇 시간 쓰나"를 함께 넣어야 판단이 선다. 칩 가격이 내려갈 것을 기다리며 지금을 버리지 말고, 지금 올리고 비용이 떨어지면 규모를 키우는 방향이 낫다.
사고가 났을 때 에이전트를 끄지 마라. 가드를 하나 추가하라. 같은 종류의 실패가 두 번 나지 않도록 자동 필터를 한 겹 더 씌우는 것 — news_guard나 vtuber_guard처럼. 그 레이어가 쌓일수록 나중에 에이전트를 확장할 때 훨씬 빠르게 올릴 수 있다.
마지막으로, 비용이 내려갈 것을 전제하고 지금 아키텍처를 설계하라. "비용이 10분의 1이 되면 무엇을 바꿀 것인가"를 지금 그려두어야, 그때가 왔을 때 레거시를 갈아엎는 대신 스위치 하나 올리는 것처럼 대응할 수 있다. $400M은 그 방향이 온다는 쪽에 건 돈이다.
최근 본 글
* 위 링크는 인프런 affiliate 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
* 위 추천 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.