AI 캠퍼스가 커질수록 우리 자동화는 더 잘 깨진다

OpenAI가 데이터센터를 'AI 컴퓨트 캠퍼스'로 부르겠다고 했다. 그리고 이게 소규모 개발팀에게 실제로 중요한 이유는, 이름이 바뀌어서가 아니다. 이름을 바꿀 만큼 투자 규모가 물리적으로 커졌다는 신호이기 때문이다. AI 개발속도가 가속된다는 건 결국 모델이 더 자주 바뀐다는 뜻이고, 그게 곧 우리가 공들여 짠 프롬프트와 자동화 파이프라인이 더 자주 망가진다는 의미다.

다만 이 결론을 그대로 받아들이면 함정이 하나 있다. "모델이 자주 바뀌니 자동화를 덜 믿어야 한다"는 방향으로 가는 것. 그건 틀린 대응이다.

이름 뒤에 숨은 숫자

'캠퍼스'라는 단어는 단기 투자 프로젝트에는 안 쓴다. 수십 년 운영을 전제로 땅 사고 전력망 깔고 건물 올릴 계획이 있을 때 쓴다. OpenAI와 소프트뱅크가 발표한 Stargate 프로젝트의 총규모는 최대 5000억 달러, 초기 약정만 1000억 달러다.

비교 기준이 잘 와 닿지 않으면 이렇게 보면 된다. 전 세계 원자력 발전소 건설 비용이 기가와트당 약 60~80억 달러 수준이다. 이 인프라 베팅이 얼마나 물리적으로 무거운 커밋인지 감이 온다. 이 돈이 들어가면 경쟁사들도 따라가야 한다. Anthropic도, Google도, Meta도. AI 인프라는 지금 군비경쟁 국면이다.

문제는 이 투자가 "AI가 잘 될 것"이라는 낙관론의 증거가 아니라, AI 개발속도 자체를 직접 연료처럼 태운다는 점이다. 인프라가 커지면 더 큰 모델을 더 빨리 훈련할 수 있다. 훈련 주기가 짧아지면 우리가 매일 호출하는 API 뒤의 모델도 6개월, 빠르면 3~4개월마다 갱신된다.

모델이 바뀌면 프롬프트가 먼저 죽는다

직접 겪어보니 LLM 의존 자동화에서 가장 조용하게 터지는 장애는 모델 교체다. 서버 다운도 아니고, API 에러도 아니다. 어느 날 보니 콘텐츠 품질이 슬금슬금 떨어져 있거나, 분류기가 엉뚱한 판정을 내리기 시작한다. 로그엔 에러가 없다. 그냥 모델이 조용히 바뀐 것이다.

Claude Haiku 구버전에서 최신 버전으로 넘어갈 때 이런 경험을 했다. 특정 구조의 JSON 응답을 유도하는 시스템 프롬프트가 있었는데, 구버전에선 95% 이상 원하는 포맷으로 나오던 게 새 버전에선 한동안 70%대까지 떨어졌다. 모델이 나빠진 게 아니다. 오히려 더 똑똑해졌는데, "더 창의적으로" 해석하다 보니 제약을 덜 따르게 된 것이었다. 성능이 올라가면서 프롬프트가 오히려 깨진 역설적인 상황.

AI 인프라 투자가 가속될수록 이 주기는 짧아진다. 소규모 팀에게 이건 단순한 기술 변화가 아니라 유지보수 부채가 축적되는 속도의 문제다.

나쁜 소식 옆에 있는 좋은 소식

공평하게 보면 인프라 투자 확대가 가져오는 직접적인 이득도 있다. 인퍼런스 비용이 내려간다는 것.

GPT-4 출시 초기 토큰 비용과 지금을 비교하면 같은 성능 기준으로 10분의 1 수준으로 떨어진 케이스가 있다. 우리가 사용하는 Claude Haiku 계열도 지난 1년 동안 비용 대비 성능이 체감상 40~50%는 좋아졌다. 더 많은 자동화를 더 싼 가격에 돌릴 수 있다.

배치 API는 더 직접적인 수혜다. Anthropic의 Message Batches API는 동일 요청 기준으로 50% 비용 절감이 공식 수치다. 실시간 응답이 필요 없는 콘텐츠 생성, 검수, 분류 작업을 배치로 전환하면 비용이 반으로 줄어든다. 3~4명 팀이 15개 이상의 봇을 돌릴 때 이 차이는 무시하기 어렵다.

단, 함정이 있다. 배치 전환은 처리 지연을 수 시간까지 허용한다는 전제를 깔아야 한다. 지금 cron 기반으로 촘촘하게 돌아가는 파이프라인 대부분은 배치로 바꾸려면 타이밍 로직을 다시 설계해야 한다. 쉬워 보이지만 마이그레이션 비용이 분명히 있다.

우리 팀이라면 어떻게 설계를 바꿀까

bots monorepo 구조를 기준으로 생각하면, 가장 취약한 지점은 모델명 하드코딩이다. model="claude-haiku-4-5-20251001" 같은 값이 각 봇 파일에 흩어져 박혀 있으면, 모델이 deprecated될 때마다 레포 전체를 grep해야 한다. AI 개발속도에 끌려다니는 구조다.

실용적인 해결은 간단하다. common/config.py 하나에 모델 상수를 몰아두는 것. MODEL_DEFAULT = "claude-haiku-4-5-20251001", MODEL_JUDGE = "claude-sonnet-4-6" 식으로 모아두고, 모든 봇이 여기서만 가져가도록 강제하면 다음 버전이 나와도 한 줄 수정으로 끝난다.

프롬프트도 같은 논리다. 각 봇의 시스템 프롬프트가 코드에 인라인으로 박혀 있으면 변경 추적이 안 된다. 봇별로 prompts/ 디렉토리를 만들고 .txt 파일로 분리해두면, 모델 교체 후 품질이 떨어졌을 때 git blame 한 줄로 "이 프롬프트가 언제 바뀌었는지"를 잡아낼 수 있다. 정교한 eval 시스템이 아니어도 된다. 변경 추적이 가능한 구조만으로도 디버깅 시간이 크게 줄어든다.

조금 더 나아가면, 주요 자동화 태스크별로 "정상 출력 예시 10~20개"를 파일로 저장해두는 것도 방법이다. 새 모델이 나왔을 때 같은 입력을 넣어보고 눈으로 비교하는 최소한의 기준점이 생긴다. 수동이지만, 아무것도 없는 것과는 천지 차이다.

지금 바로 적용할 수 있는 것

먼저 grep -r "claude-" /opt/bots 한 번 돌려보라. 몇 개 파일에 모델명이 박혀 있는지 숫자로 나온다. 10개가 넘으면 오늘 정리할 이유가 충분하다.

실시간 응답이 불필요한 봇 중 하나를 골라 Batches API 전환 실험을 해보라. 검수 루프처럼 완료 시간이 촉박하지 않은 작업이 첫 번째 후보다. 50% 비용 절감이 체감되면 나머지로 확장하면 된다. 전체를 한 번에 바꿀 필요 없다.

마지막으로 주요 봇 3개만 골라 "현재 시스템 프롬프트 + 정상 출력 예시 5개"를 파일로 떼어내 커밋해두라. 다음 번 모델 교체 때 이 파일이 있는 팀과 없는 팀의 대응 시간은 완전히 다르다.

OpenAI가 데이터센터를 뭐라고 부르든, 그 규모의 투자가 만드는 AI 개발속도 가속은 실제로 일어나고 있다. 이름이 캠퍼스가 되든 뭐가 되든, 중요한 건 그 속도에 끌려다니지 않을 수 있는 구조를 지금 만들어두는 것이다.

원문: AI News & Artificial Intelligence | TechCrunch