[인프라 실무의 정석 #6] CPU 증설의 완성: 인프라의 '할당'과 AP의 '인식' 사이

🔗 [인프라 실무의 정석] 시리즈 다시보기

• [[제5편] vCPU 할당의 마법: 1:3의 비율은 '약속'인가, '실제'인가?]

---

1. 인프라의 '클릭' vs 어플리케이션의 '현실'

가상화 기술의 발전으로 우리는 서버를 끄지 않고도 CPU를 추가하는 'CPU Hot-Add' 기능을 갖게 되었습니다. 인프라 담당자 입장에서는 "온라인 중에 넣어드렸으니 확인해 보세요"라고 가볍게 말하기 쉽지만, 실제 서비스를 담당하는 AP(어플리케이션) 담당자의 대답은 다릅니다. "CPU는 늘었는데 WAS가 그대로인데요? 재기동해야 할 것 같습니다."

 

2. 왜 인프라에서 줘도 바로 못 쓰는가?

자원이 들어와도 어플리케이션이 이를 제대로 활용하지 못하는 이유는 크게 두 가지입니다.

• OS 레벨의 인식 문제: 최신 OS는 Hot-Add를 지원하지만, 특정 커널 버전이나 설정에 따라 새로 추가된 CPU를 'Offline' 상태로 두기도 합니다. 인프라가 자원을 밀어 넣어도 OS가 이를 깨워주지 않으면 무용지물입니다.
• 미들웨어(WAS)의 라이브러리 정책: 가장 큰 형님은 WAS입니다. Java 기반의 WAS(Tomcat, WebLogic 등)나 DB 엔진은 기동 시점의 시스템 리소스를 기준으로 Thread Pool이나 Memory Heap 설정을 최적화합니다. 이미 돌아가고 있는 프로세스에 CPU 코어만 늘려준다고 해서, WAS가 "오, 코어가 늘었네? 스레드를 더 만들어야지!"라고 능동적으로 반응하지 않습니다.

3. 아키텍트의 정석: "증설은 인프라의 끝이 아니라 서비스의 시작이다"

실무에서 무중단 증설을 과신하다가는 '성능 수치 세탁'에 불과한 상황에 빠질 수 있습니다.

• Hot-Add의 과신 금지: 가급적 서비스 영향이 적은 점검 시간에 **작업(Maintenance Window)**을 잡고, OS와 AP가 새로운 리소스를 완벽히 인지하도록 재기동을 병행하는 것이 가장 안전한 정석입니다.
• 커뮤니케이션의 기술: 6편에서 언급한 '빌런 TA'들이 "무중단으로 다 된다"고 호언장담할 때, 아키텍트는 "서비스의 안정적인 리소스 바인딩을 위해 AP 재기동 절차가 수반되어야 한다"고 제동을 걸어야 합니다.

💡 여기서 잠깐: 기술보다 무서운 '현장의 미신'
 
기술적으로는 2코어든 3코어든 자유로운 증설이 가능하지만, 현장에서는 전혀 다른 '미신'이 팩트를 압도하기도 합니다. 운영자가 없는 밀실에서 벌어진 **'2진법 증설 미신'**과 시니어 빌런의 황당한 가스라이팅 사건을 확인해 보세요.
 
👉 [[가상화의 미신] "2코어 증설은 안 됩니다" – 시니어 빌런과 SM 총괄의 위험한 독대: 인프라 생존기 시즌2-26편]

---

📖 오늘의 인프라 묵상

"새 포도주는 새 부대에 넣어야 할 것이니라" (누가복음 5:38)

 
새로운 CPU(새 포도주)를 추가했다면, 그 자원을 온전히 담아낼 어플리케이션의 상태(새 부대)도 새롭게 정비되어야 합니다. 단순히 자원만 밀어 넣는 것이 아니라, 서비스 전체가 조화를 이루도록 절차를 설계하는 것이 진정한 엔지니어의 자세입니다.

 

[다음 이야기 예고]

제7편. P2V의 기술과 예술: 물리 서버를 가상화로 옮기는 '라이브 솔루션'의 신뢰성

이제는 가장 예민하고 까다로운 숙제를 마주할 시간입니다. 바로 낡은 물리 서버의 하드웨어 종속성을 끊어내고 가상화의 생명력을 불어넣는 **P2V(Physical to Virtual)**입니다.
 
"물리 장비를 통째로 복제하는데 정말 서비스 중단이 없을까?"라는 의구심과 "데이터 정합성은 완벽할까?"라는 불안함. 18년 차 아키텍트가 경험한 **'Live P2V'**의 실전 신뢰성과, 그 과정에서 본질(데이터)을 지켜내기 위해 반드시 챙겨야 할 **'최종 동기화(Final Sync)'**의 정석을 공개합니다.
 
보이는 껍데기를 넘어 보이지 않는 서비스의 가치를 영구히 보존하는 법. 인프라의 세대교체를 주도하는 아키텍트의 소명을 7편에서 만나보세요.