AI 제품 결정이 지구에 청구하는 비용
아마존 텍사스 데이터센터가 미국 최대 탄소 오염원이 될 수 있다는 소식. 작은 팀의 제품 결정이 이 수요를 어떻게 구성하는지, 사용자에게 어떤 영향을 미치는지 실전 관점으로 파헤친다.
아마존이 텍사스에 짓는 것의 진짜 의미
Amazon이 텍사스에 계획 중인 데이터센터에 전용 발전소를 함께 세운다. TechCrunch 보도에 따르면 이 발전소가 완공될 경우 미국 전체에서 기후오염 배출량이 가장 큰 단일 시설이 될 수 있다고 한다. 미국 전체에서. 가장 크게.
이 뉴스를 환경 저널리즘 이슈로만 읽으면 "Big Tech가 또"로 끝난다. 그런데 AI 기반 서비스를 직접 만들고 운영하는 팀 입장에서 보면 전혀 다른 질문이 떠오른다. 우리가 매일 아무 생각 없이 내리는 제품 결정들이 이 수요의 일부를 구성하고 있는 것 아닐까.
AI 호출 한 번이 쓰는 전력, 숫자로 보면
GPT-4 같은 대형 언어 모델에 쿼리 하나를 보내면 구글 검색 한 번보다 약 10배 많은 전력이 소비된다는 수치가 여러 연구에서 반복된다. 구글 검색 한 번이 약 0.3Wh라면, LLM 호출 하나는 약 3Wh 수준이라는 이야기다. Claude나 Gemini도 비슷한 규모의 모델이라면 크게 다르지 않다.
Microsoft는 2023년 자사 탄소 배출량이 2020년 대비 29% 증가했다고 지속가능성 보고서에 직접 기재했다. 감축을 선언했던 회사가 AI 때문에 역방향으로 갔다는 공식 고백이다. Amazon, Google도 같은 처지다. IEA는 2026년 전 세계 데이터센터 전력 소비가 약 1,000 TWh에 달할 것으로 전망하는데, 이는 AI 붐 이전 추정치를 크게 웃도는 수치다.
우리 팀이 운영하는 콘텐츠 봇은 하루에 Claude API를 수백 회 호출한다. 봇 열두 개가 매일 돌아가면서 쌓이는 호출량이 결코 적지 않다. 솔직히 말해 처음엔 이 숫자를 비용(cost)으로만 봤다. 토큰당 요금. 이 숫자가 동시에 전력 소비량이라는 생각은 거의 해본 적이 없었다.
제품 결정이 에너지 결정이기도 하다
우리 팀에서 매일 내리는 결정들을 생각해보자. "이 기능에 Sonnet을 쓸까, Haiku로 충분할까." "검수 루프를 몇 번 돌릴까." "재생성 재시도를 최대 몇 회 허용할까." 이 결정들이 전부 에너지 소비 결정이기도 하다.
지금 우리 발행 봇 구조는 본문 생성은 Haiku, 검수·판단은 Sonnet 이상으로 나눠뒀다. 결과적으로 이 분리가 에너지 최적화이기도 하다. 무거운 모델을 반드시 필요한 지점에만 쓰는 것. 다만 이 결정을 내릴 때 탄소발자국을 의식해서 한 건 아니었다. API 비용 때문이었다. 동기가 달랐다는 게 흥미롭다.
여기서 트레이드오프가 하나 생긴다. 재시도 횟수를 늘리면 글 품질이 오를 수 있다. 지금 구조는 본문이 1,500자 미달이면 1회 재생성하고, 그래도 미달이면 발행을 스킵한다. 재시도를 3회로 늘리면 더 많은 글이 통과되겠지만, 같은 주제로 세 번의 LLM 호출이 추가로 발생한다. 품질과 에너지, 두 축 사이의 긴장이 여기서도 존재한다.
사용자는 이미 눈치채고 있다
"AI로 만들었나요?"라는 질문이 아직 우리 서비스에 직접 오진 않는다. 하지만 B2C 서비스 전반에서 이 질문이 점점 잦아지고 있다. 그 질문 뒤에는 두 가지 우려가 섞여 있다. 하나는 품질에 대한 의심. 다른 하나는, 그 서비스가 얼마나 많은 에너지를 태우는지에 대한 막연한 불편함.
SBS아카데미AIX학원홍대점 같은 AI 전문 교육기관이 늘어나고, AI 도구를 직접 배우고 쓰는 사람이 급격히 증가하는 지금 — 사용자의 AI 리터러시는 빠르게 올라가고 있다. 블랙박스였던 것들이 서서히 투명해진다. "이 챗봇이 응답 한 번에 전기를 얼마나 쓰는지 아세요?"라는 질문이 미디어에서 일상화될 날이 멀지 않았다.
유럽에서는 이미 AI 시스템의 에너지 사용량 공개를 의무화하는 규제 논의가 진행 중이다. EU AI Act 후속 논의 중 하나다. 규제가 확산되면, 사용자가 앱 하나를 설치할 때 "이 앱의 AI 기능이 월 X kWh를 소비합니다"라는 라벨을 보게 되는 시대가 올 수 있다. 그때 우리 제품은 어떤 숫자를 보여줄 수 있을까.
우리 팀이라면 어떻게 할까
구체적으로 생각해본 시나리오가 있다. 우리가 만드는 서비스에 사용자 대면 AI 기능을 붙일 때, 두 가지 원칙을 미리 잡아두면 나중에 덜 고친다.
첫째, AI가 개입하는 지점을 지금 당장 명시적으로 기록하는 것. 어떤 기능이 LLM을 호출하는지, 하루 평균 호출 횟수가 몇 번인지. 지금도 사실 이 데이터를 기능별로 따로 집계하지 않는다. 비용 청구서엔 나오지만, 어떤 봇의 어떤 단계가 얼마나 쓰는지는 흐릿하다. 이걸 추적하기 시작하면 자연스럽게 "이 기능에 LLM이 정말 필요한가"를 더 자주 묻게 된다.
둘째, 사용자에게 AI 개입 여부를 숨기지 않는 것. 이건 윤리 문제이기 이전에 제품 신뢰 문제다. 투명하게 밝히는 쪽이 장기적으로 이탈을 막는다. 만약 탄소 효율 지표를 제품 페이지에 노출하는 게 기술적으로 가능해진다면, 오히려 차별화 포인트가 될 수 있다. "동급 서비스 대비 AI 호출을 30% 줄였습니다" — 지금은 마케팅 카피처럼 들릴 수 있지만, 몇 년 후엔 실제 경쟁 요소가 될 수 있다.
지금 당장 쓸 수 있는 시사점
아마존 텍사스 데이터센터 뉴스를 환경 뉴스로만 소비하고 넘기면 아무것도 달라지지 않는다. 제품을 만드는 사람 입장에서 이 뉴스가 건네는 건 세 가지 구체적인 행동이다.
LLM 호출 지점을 지금 당장 지도로 그려라. 어떤 기능이 어떤 모델을 몇 번 호출하는지 문서화하는 것. 이게 없으면 최적화도 투명성도 시작할 수 없다. 우리 팀 기준으로는 봇별 일일 호출 횟수를 Discord 리포트 카드에 함께 노출하는 것부터 시작할 수 있다. 보이지 않는 것은 줄일 수 없다.
모델 선택 기준에 "정말 필요한가"를 명시적으로 넣어라. 지금은 비용과 품질 두 축으로만 모델을 고른다. 여기에 "이 기능이 무거운 모델을 정당화할 만큼 복잡한가"라는 기준을 추가하면, 습관적으로 Sonnet을 쓰던 자리에서 Haiku로 충분한 케이스를 골라낼 수 있다. 비용 절감과 에너지 절약이 동시에 일어난다.
재시도 횟수를 무한정 늘리는 설계를 경계하라. 품질을 올리고 싶은 욕심에 재생성 루프를 늘리다 보면, 같은 결과를 얻기 위해 쓰는 에너지가 기하급수적으로 불어난다. 지금 우리 구조(1회 재시도 후 스킵)는 에너지 관점에서도 나쁘지 않은 선택이다. 의도한 건 아니었지만, 결과는 같다.
아마존 한 회사의 결정을 우리가 바꿀 수는 없다. 그러나 우리가 만드는 서비스가 그 수요의 일부를 구성한다는 사실은 바꿀 수 없다. 제품 결정이 에너지 결정이라는 인식 — 그것 자체가 시작이다.
최근 본 글
* 위 링크는 인프런 affiliate 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
* 위 추천 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.