본문으로 건너뛰기
피드

인텔, 클라우드·통신사·에이전틱 AI용 제온6+ 정식 출시

backend 약 7분
vote
0
댓글
북마크

인텔이 E코어 기반 서버 프로세서 제온6+를 정식 출시했다. 인텔 18A 공정, 리본펫, 파워비아, 포베로스 3D, EMIB까지 파운드리 기술을 총동원해 소켓당 최대 288코어를 밀어 넣은 제품이다. 인텔은 오래된 제온 서버를 제온6+로 바꾸면 랙과 서버 수를 크게 줄이고, 확보한 전력·공간을 AI 인프라로 돌릴 수 있다고 강조한다.

  • 1

    제온6+는 소켓당 최대 288개 E코어를 탑재한 스케일아웃 서버용 프로세서다.

  • 2

    컴퓨트 타일은 인텔 18A 공정으로 만들고, 리본펫과 파워비아를 적용했다.

  • 3

    48개 랙·960대 서버 규모의 구형 제온 구성을 10개 랙·100대 서버 수준으로 줄일 수 있다는 게 인텔의 주장이다.

  • 4

    제온6+ 6990E+는 AMD 에픽 9965 대비 주요 데이터센터 워크로드에서 스레드당 성능과 전력 효율이 최대 1.3배 높다고 제시됐다.

  • 5

    응용프로그램 에너지 텔레메트리 기능으로 앱 단위 에너지 사용량을 실시간 측정해 클라우드 과금에 활용할 수 있다.

인텔이 제온6+로 노리는 건 ‘많은 코어가 필요한 서버판’임

  • 인텔이 서버용 프로세서 제온6+를 정식 출시함. 코드명은 클리어워터 포레스트고, 작년 9월 시제품 공개 후 9개월 만에 나온 제품임.

    • 타깃은 클라우드 서비스 제공자, 통신사, 에이전틱 AI 같은 대규모 코어 집적이 필요한 환경임.
    • 고성능 단일 코어보다 처리량, 집적도, 전력 효율이 중요한 스케일아웃 워크로드를 노린 쪽에 가까움.
  • 핵심은 저전력·고효율 E코어인 다크몬트를 엄청나게 많이 넣었다는 점임.

    • 소켓당 최대 288코어까지 탑재 가능함.
    • 수랭식 32U 랙 단위 구성에서는 제온6+ 코어를 최대 3만6864개까지 집적할 수 있다고 인텔이 설명함.
    • 인텔은 이 구성이 대규모 AI 에이전트 실행 환경을 받쳐줄 수 있다고 보고 있음.

중요

> 인텔의 메시지는 간단함. “AI 시대에도 GPU만 필요한 게 아니라, 수많은 에이전트와 서비스 백엔드를 돌릴 CPU 밀도도 중요하다”는 얘기임.

공정과 패키징은 인텔 기술 쇼케이스에 가까움

  • 제온6+의 컴퓨트 타일 12개는 인텔 18A 공정으로 생산됨.

    • 여기에 리본펫 트랜지스터와 후면 전력 전달 기술인 파워비아가 모두 들어감.
    • 인텔은 같은 전력 조건에서 더 높은 성능과 효율, 더 높은 집적도를 확보했다고 설명함.
  • 베이스 타일에는 인텔 3-T 공정이 쓰이고, 실리콘 관통전극까지 추가됨.

    • 컴퓨트 타일과 베이스 타일을 결합하는 데는 포베로스 3D가 쓰임.
    • 여기에 평면 칩렛 연결 기술인 EMIB까지 붙여서 고대역폭·저지연 데이터 전송을 구현했다는 설명임.
    • 쉽게 말하면, 이번 칩은 인텔 파운드리의 최신 공정과 패키징 기술을 한 번에 꺼내 든 제품임.

어디에 쓰라고 만든 칩인가

  • 인텔이 꼽은 대표 워크로드는 처리량과 집적도가 중요한 서버 작업들임.

    • 5G 코어 네트워크, 데이터 플레인, 콘텐츠 전송 네트워크, 미디어 트랜스코딩, 웹 서비스, 마이크로서비스, 데이터 분석, 스토리지 같은 영역이 언급됨.
    • 특히 통신 인프라와 클라우드 서비스 제공자 쪽 활용도가 높을 거라고 봄.
  • 에이전틱 AI도 핵심 수요처로 잡고 있음.

    • 인텔은 2030년까지 AI 워크로드와 기존 서버 연산 수요가 각각 절반가량을 차지할 것으로 추산함.
    • 즉, GPU가 모델 학습·추론의 중심이라면, 제온6+는 그 주변에서 대규모 에이전트 실행과 서비스 처리를 담당하는 CPU 인프라 쪽을 노리는 셈임.

인텔이 가장 세게 민 부분은 TCO 절감임

  • 인텔은 제온6+의 장점으로 데이터센터 현대화와 총소유비용 절감을 전면에 내세움.

    • 예시가 꽤 세다. 48개 랙, 960대 서버로 구성된 2세대 제온 플랫폼을 제온6+로 전환하면 10개 랙, 100대 서버로 줄일 수 있다고 주장함.
    • 서버 수가 줄면 상면, 전력, 냉각 비용이 같이 줄고, 남는 전력과 공간을 신규 서비스나 AI 인프라에 돌릴 수 있다는 논리임.
  • 경쟁 제품 대비 성능 수치도 공개됨.

    • 제온6+ 6990E+는 AMD 에픽 9965 대비 데이터센터 주요 워크로드에서 스레드당 성능이 최대 1.3배 높다고 제시됨.
    • 스레드당 전력 효율도 최대 1.3배 높다는 게 인텔의 설명임.
    • 벤치마크는 항상 실제 워크로드로 다시 봐야 하지만, 인텔이 이제 효율 경쟁을 정면으로 걸고 있다는 점은 분명함.

ℹ️참고

> 서버 CPU 교체는 단순히 “성능 몇 배”로 끝나는 일이 아님. 랙 수, 전력 여유, 냉각 비용, 클라우드 과금 모델까지 같이 움직여서 인프라 팀 입장에서는 훨씬 복잡한 계산이 됨.

클라우드 사업자를 위한 AET도 들어감

  • 제온6+에는 응용프로그램 에너지 텔레메트리 기능이 기본 탑재됨.

    • 앱이 사용한 전력 등 에너지 이용량을 실시간으로 측정하는 기능임.
    • 클라우드 서비스 제공자는 이 데이터를 고객사 과금이나 내부 비용 분석에 참고할 수 있음.
    • 별도 설정 없이 바로 쓸 수 있고, 모든 제온6+ 제품군에 기본 제공된다고 함.
  • 인텔은 내년 출시할 P코어 기반 차세대 제온 프로세서 다이아몬드래피즈도 살짝 언급함.

    • 이 제품은 인텔 18A-P 공정 기반으로 나올 예정임.
    • 메모리 대역폭을 두 배로 늘리고, PCI 익스프레스 6.0을 지원해 입출력 성능을 높일 계획임.
    • 더 자세한 내용은 8월 말 핫칩스 2026에서 공개될 예정임.

기술 맥락

  • 이번 제온6+의 선택은 “한 코어를 더 세게”보다 “전력 안에서 코어를 더 많이”에 가까워요. 클라우드, 통신, 마이크로서비스는 요청이 잘게 쪼개져 많이 들어오기 때문에, 절대 성능보다 처리량과 랙 밀도가 비용에 바로 꽂히거든요.

  • 인텔 18A, 리본펫, 파워비아를 강조한 이유도 여기에 있어요. 소켓당 288코어를 넣으려면 전력 공급, 발열, 배선, 지연시간이 다 병목이 되는데, 공정과 패키징을 같이 바꿔야 밀도를 올릴 수 있어요.

  • 포베로스 3D와 EMIB는 칩렛을 많이 쓰면서도 데이터 이동 비용을 줄이기 위한 선택이에요. 서버 CPU는 코어만 많다고 끝이 아니라, 타일 사이 통신이 느리면 실제 워크로드에서 성능이 잘 안 나오거든요.

  • AET가 흥미로운 건 성능 기능이라기보다 운영 기능이기 때문이에요. 클라우드 사업자는 이제 고객별 CPU 사용량만 보는 게 아니라, 에너지 사용량까지 과금·최적화 기준으로 삼고 싶어 해요. AI 인프라 시대에는 전력이 곧 원가라서 이런 계측 기능이 점점 중요해져요.

인텔이 AI 가속기 경쟁만 바라보는 대신, 대량의 CPU 코어가 필요한 클라우드·통신·에이전트 실행 환경을 정조준한 제품이다. 국내 클라우드·통신 인프라 쪽에서는 전력, 랙 밀도, 과금 모델까지 같이 봐야 하는 얘기라 꽤 현실적인 포인트가 많다.

댓글

댓글

댓글을 불러오는 중...

backend

내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장

Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다.

backend

DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다

DBOS는 durable workflow를 구현할 때 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이터가 꼭 필요하지 않다고 주장한다. 핵심 아이디어는 워크플로우 상태를 어차피 데이터베이스에 체크포인트로 저장한다면, Postgres 자체를 오케스트레이터처럼 쓰는 편이 더 단순하다는 것이다. 확장성, 가용성, 관측성, 보안까지 Postgres 운영 경험을 그대로 활용할 수 있다는 게 글의 논지다.

backend

Go에서 Rust로 옮길 때 진짜로 바뀌는 것들

이 글은 Go 백엔드 서비스를 Rust로 옮길 때 속도보다 컴파일 타임 보장, 런타임 트레이드오프, 개발자 경험이 더 중요하다고 설명한다. nil 패닉, 데이터 레이스, 에러 처리, 제네릭, 비동기 모델, 마이그레이션 전략까지 실무 관점에서 Go와 Rust를 길게 비교한다.

backend

Python 3.15에서 헤드라인은 못 탔지만 꽤 쓸만한 기능들

Python 3.15에는 lazy imports나 Tachyon profiler 같은 큰 기능 말고도 실무에서 바로 체감될 만한 작은 개선들이 들어가. TaskGroup 취소, 컨텍스트 매니저 데코레이터 개선, 스레드 안전 이터레이터처럼 평소 애매하게 불편했던 지점들이 꽤 깔끔해졌어.

backend

심평원, DUR부터 의료영상 심사까지 클라우드로 갈아엎는다

심평원이 정보시스템 클라우드 전환과 함께 병·의원 업무에 직접 닿는 DUR, 의료영상 AI 심사, 요양급여내역 조회 시스템을 고도화한다. 핵심은 설치형 프로그램 중심이던 연계를 웹과 API 기반으로 넓히고, 진료·청구 과정에서 실시간 확인과 자동 판독을 강화하는 쪽이다.