AI 워크로드가 기존 엔터프라이즈 서버보다 단위 시간당 전력을 수배 이상 소비한다는 사실, 저는 이걸 논문이 아니라 실제 개발 과정에서 체감했습니다. 해커톤에서 LLM 기반 서비스를 만들면서 클라우드 모니터링 화면에 찍히는 API 호출 횟수를 보고 처음으로 "이게 친환경 서비스일 수 있을까"라는 의문이 들었습니다.
AI 개발 현장에서 마주한 탄소의 무게
저는 두 개의 AI 프로젝트를 직접 개발해 봤습니다. 하나는 Spotify API와 날씨 데이터를 결합해 실시간 분위기에 맞는 음악을 추천하는 것과, 다른 하나는 호남권 LLM 해커톤에서 네이버 클라우드의 하이퍼클로바X(HyperCLOVA X)와 공공데이터를 연동해 만든 지역 축제 커뮤니티 서비스였습니다. 두 대회 모두 동상을 받으며 좋은 결과를 냈지만, 개발 과정에서 제가 마주한 건 단순히 기술적 성취만이 아니었습니다.
저의 서비스의 핵심은 RAG(Retrieval-Augmented Generation) 아키텍처였습니다. RAG란 LLM이 답변을 생성할 때 사전 학습된 지식에만 의존하지 않고, 실시간으로 외부 데이터베이스에서 관련 문서를 검색해 맥락으로 주입하는 방식입니다. 쉽게 말해 AI에게 시험 직전에 참고자료를 쥐여주는 것과 같습니다. 덕분에 환각 현상(Hallucination)을 줄이고 정확도를 높일 수 있었지만, 동시에 사용자가 질문 한 줄을 던질 때마다 내부적으로 수천에서 수만 토큰 규모의 문서 묶음이 클라우드 서버로 흘러 들어가는 구조가 만들어졌습니다.
테스트 과정에서 API 호출 횟수가 불과 몇 분 만에 수백 건을 넘는 걸 봤을 때, 솔직히 이건 예상 밖이었습니다. 고작 열 명 남짓한 테스터를 위해 이 정도였는데, 만약 이 서비스가 수만 명에게 배포된다면 데이터센터에서 발생하는 열과 전력 소비가 어느 수준일지 가늠조차 되지 않았습니다. 하지만 해커톤 평가 기준은 오직 모델 정확도와 서비스 완성도였습니다. "이 아키텍처가 얼마나 에너지를 쓰는가"를 묻는 심사위원은 단 한 명도 없었습니다. 저희 팀 역시 성능을 위해 더 무거운 모델을 고집하는 방향으로만 달렸고, 탄소 효율성 같은 개념은 처음부터 우선순위에 없었습니다.
일반적으로 클라우드 기반 AI 서비스는 개발자에게 자원의 한계를 체감하지 못하게 만든다고 알려져 있습니다. 그리고 제 경험상 이건 사실입니다. 물리 서버를 직접 조달해야 했다면 예산과 발열이라는 물리적 제약이 자연스럽게 소비를 억제했을 텐데, API 호출은 그 장벽을 없애버립니다. 전력 집약도(Energy Intensity), 즉 단위 연산당 소비되는 에너지량이 아무리 높아도 개발자 화면에는 그냥 숫자 하나로만 표시됩니다.
그린옵스가 AI 시대에 살아남으려면
그린옵스(GreenOps)란 클라우드 인프라 운영에서 에너지 소비와 탄소 배출을 측정·최적화하는 운영 방법론입니다. 원래는 핀옵스(FinOps), 즉 클라우드 비용을 체계적으로 관리하는 방법론에서 파생되어 낭비 리소스 제거, 인스턴스 최적화, 유휴 서버 종료 같은 방식으로 출발했습니다. 그런데 AI 워크로드가 등장하면서 이 전제가 흔들리고 있습니다.
AI 연산은 구조적으로 기존 워크로드와 다릅니다. GPU 기반 가속 하드웨어를 상시 가동하고, 고밀도 연산과 고속 네트워크를 동시에 요구합니다. 국제에너지기구(IEA)에 따르면 AI 데이터센터의 전력 수요는 2026년까지 2022년 대비 두 배 이상 증가할 것으로 전망됩니다(출처: 국제에너지기구(IEA)). 클라우드 인스턴스를 아무리 최적화해도 AI 사용량이 10배로 늘어나면 효율 개선이 사용량 증가에 삼켜지는 리바운드 효과(Rebound Effect)가 발생합니다. 리바운드 효과란 기술 효율이 높아질수록 오히려 총 사용량이 늘어나는 역설적 현상을 말합니다.
제 경험으로 돌아가면, 'Flova' 개발 당시 RAG 파이프라인에서 가장 낭비가 심했던 부분은 모든 질문에 전체 문서 코퍼스를 다 검색하게 설계한 부분이었습니다. 나중에 알게 된 것이지만, 질문 의도를 먼저 가볍게 분류하고 벡터 DB(Vector Database) 필터링으로 범위를 좁힌 뒤 핵심 문서만 LLM에 전달하는 방식이 정확도 손실 없이 연산량을 크게 줄일 수 있습니다. 벡터 DB란 텍스트나 이미지를 수치 벡터로 변환해 의미 기반 유사도 검색이 가능하도록 저장하는 데이터베이스입니다. 이런 설계 결정 하나가 토큰 소비량, 나아가 전력 소비량을 직접적으로 바꿉니다.
탄소를 고려한 AI 아키텍처 설계에서 실무적으로 적용 가능한 접근법을 정리하면 다음과 같습니다.
- 충분한 성능이 보장된다면 대형 모델 대신 경량 모델을 우선 선택한다.
- 동일 질문이 반복될 경우 재생성 대신 캐싱(Caching) 결과를 반환하도록 설계한다.
- RAG 파이프라인에서 전체 문서 검색 전에 벡터 DB 필터링으로 컨텍스트 범위를 좁힌다.
- 긴급하지 않은 모델 학습 작업은 전력망의 탄소 집약도가 낮은 시간대로 스케줄링한다.
- 추론 단계에서 오버프로비저닝이 발생하지 않도록 부하 테스트를 통해 적정 인스턴스를 선택한다.
기업 차원에서는 AI 이니셔티브를 승인할 때 ROI(투자 대비 수익)만이 아니라 예상 에너지 소비와 탄소 영향을 함께 검토하는 거버넌스 체계가 필요합니다. 구글은 이미 전력망 탄소 집약도가 낮은 시간과 지역으로 워크로드를 이동하는 탄소 인지 컴퓨팅(Carbon-Aware Computing) 방식을 실제 운영에 적용하고 있다고 밝혔습니다(출처: Google Sustainability). 탄소를 사후 보고 지표가 아니라 아키텍처 설계 단계의 제약 조건으로 삼는다는 접근입니다. 제가 해커톤에서 경험한 것처럼 개발자가 성능만 보도록 설계된 환경에서는 이런 사고방식이 자연스럽게 생기지 않습니다. 평가 기준을 바꾸지 않으면 행동은 바뀌지 않습니다.
AI 시대의 그린옵스는 낭비를 줄이는 수준에서 한 발 더 나아가, 설계 초기부터 탄소 비용을 명시적으로 계산하는 방향으로 진화해야 합니다. 대학생 때부터 "이 아키텍처의 탄소 가성비는 얼마인가"를 묻는 습관을 들이는 것, 그리고 해커톤이나 공모전 평가 기준에 에너지 효율성 지표를 포함하는 것이 제가 직접 경험하고 나서 내린 결론입니다. 지속가능성 보고서에 예쁜 차트를 그리는 것과, 개발 결정 하나하나에 탄소 비용을 반영하는 것은 완전히 다른 일이기 때문입니다. 지금 우리에게 필요한 건 전자가 아니라 후자입니다.