블루투스가 끊긴 범인은 CPU가 아니라 메모리였습니다 — 클로드 코드용 PC 사양

한눈에

• 「무거운 계산 = CPU 문제」는 제 경우 틀렸습니다. 그 계산은 논리 코어 22개 중 1개만 썼고, 세 개를 동시에 돌려도 사용률이 14%였습니다.
• 진짜 원인은 램이었습니다. 15.5GB 중 여유가 2.1GB, 한창일 때는 78MB까지 떨어졌고 초당 193회씩 디스크로 밀려나고 있었습니다. 그 줄에 음악도 같이 섭니다.
• 가상 메모리는 램 부족을 고쳐주지 않습니다. 프로그램이 뻗는 걸 막아줄 뿐이고, 그걸 쓰기 시작한 순간 이미 느려집니다 — 해결한 건 «공유 메모리»(같은 데이터를 한 벌만 두는 것)였습니다.
• 클로드 코드로 개발할 때 병목은 CPU가 아니라 램입니다. 지금 이 컴퓨터에서 클로드 코드가 2,890MB, 브라우저가 3,853MB를 쓰고 있고, 프로그램들이 잡아둔 총량 16.78GB는 물리 램 15.46GB를 이미 넘었습니다. 8GB는 권하지 않고, 32GB부터 편합니다.

음악을 들으면서 무거운 계산을 돌리면 블루투스 스피커 소리가 자꾸 끊겼습니다. 계산이 시작되면 소리가 뚝뚝 끊기고, 끝나면 멀쩡해집니다.

AI에게 물었더니 답이 명쾌했습니다. CPU가 바빠서 오디오 스레드가 밀린 것이라고요. 처방도 구체적이었습니다 — 프로그램 우선순위를 낮추고, CPU 코어 일부를 오디오용으로 비워두고, 워커 수를 줄이라는 것이었습니다.

그런데 재보니 CPU는 놀고 있었습니다. 원인은 완전히 다른 데 있었고, 그걸 찾는 과정에서 「클로드 코드로 개발하려면 어떤 컴퓨터가 필요한가」에 대한 답도 같이 나왔습니다. 제 컴퓨터 실측값을 그대로 공개하면서 적겠습니다.

먼저 CPU가 아니라는 것부터 확인했습니다

처방을 적용하기 전에 전제가 맞는지부터 쟀습니다. 제 프로그램이 CPU를 정말 많이 쓰고 있는가.

결과는 아니오였습니다. 그 계산은 코어 하나만 쓰는 작업이었습니다. 제 컴퓨터는 논리 코어가 22개인데 그중 1개만 씁니다. 세 개를 동시에 돌려도 3/22 = 14%입니다. 이 정도 부하로 오디오가 밀릴 이유가 없습니다.

그래서 받은 처방들이 전부 빗나갑니다.

받은 처방	이 컴퓨터에서의 판정
프로그램 우선순위 낮추기	CPU 경합이 아니므로 근거 없음 — 속도만 잃습니다
CPU 코어 일부 비워두기	이미 20개가 놀고 있습니다
워커 수 줄이기	해당 없음
오디오 서비스 우선순위 올리기	같은 이유로 불필요

처방이 틀렸다기보다 제 상황에 대한 진단이 틀렸습니다. 저는 증상만 말했고, 답한 쪽은 「무거운 계산 = CPU 100%」라는 흔한 가정을 얹었습니다. 그 가정이 제 경우엔 안 맞았습니다.

진짜 범인은 램이었습니다

같은 시점에 램을 재보니 이랬습니다.

항목	실측
전체 램	15.5GB · 여유 2.1GB (사용률 86%)
계산 하나가 먹는 램	1.7~2.6GB
한창일 때 남은 램	78MB
그때 디스크로 밀려난 횟수	초당 193회

램이 모자라면 윈도우는 당장 안 쓰는 내용을 디스크로 밀어냅니다. 이걸 스왑이라고 합니다. 그리고 그 내용이 다시 필요해지면 디스크에서 도로 읽어옵니다.

여기서 중요한 게 있습니다. 스왑이 시작되면 CPU가 아무리 남아돌아도 소용이 없습니다. 모든 게 디스크를 기다리는 상태가 되기 때문입니다. 그리고 디스크를 기다리는 줄에는 음악도 같이 섭니다.

블루투스 오디오는 정해진 간격으로 계속 소리 조각을 보내야 합니다. 그 조각을 만들어 넘기는 일이 몇 밀리초만 늦어도 소리가 끊깁니다. 「느려짐」과 「소리 끊김」은 서로 다른 증상이 아니라 같은 원인의 두 얼굴이었습니다.

그런데 램을 늘릴 수가 없었습니다

가장 간단한 답은 램을 더 꽂는 것입니다. 그래서 확인해봤더니 이 컴퓨터는 램을 늘릴 수 없었습니다.

램이 슬롯에 꽂힌 부품이 아니라 메인보드에 직접 붙어 있는 형태(온보드)였습니다. 8개 채널에 2GB씩 붙어 총 16GB이고, 이 메인보드가 인식하는 최대 용량 자체가 16GB입니다. 빼서 32GB로 바꿔 끼우는 게 애초에 불가능합니다.

여기서 제가 가장 놀랐던 게 있습니다. 이건 노트북이 아니라 데스크탑입니다. 정확히는 올인원 데스크탑인데, 이런 기종은 화면 뒤에 본체를 다 넣어야 해서 노트북용 부품 구성을 그대로 씁니다. CPU도 노트북용이고 램도 노트북처럼 붙박이입니다. 「데스크탑이니까 나중에 부품을 바꾸면 되겠지」가 통하지 않았습니다.

컴퓨터를 사실 계획이라면 이것부터 확인하십시오 — 「램을 나중에 늘릴 수 있는가」. 얇은 노트북은 대부분 붙박이이고, 올인원이나 미니 PC처럼 «데스크탑»으로 팔리는 것도 붙박이인 경우가 많습니다. 제 것이 그랬습니다. 붙박이라면 살 때 정한 용량이 그 컴퓨터의 평생 용량입니다. CPU 등급을 한 칸 낮추더라도 램을 한 단계 올리는 쪽이 후회가 적습니다.

그래서 «같은 것을 여러 벌 만들지 않는» 쪽으로 고쳤습니다

램을 못 늘리니 덜 쓰는 수밖에 없었습니다. 클로드와 함께 찾아낸 게 이것입니다.

계산을 여러 개 동시에 돌릴 때, 프로그램마다 같은 데이터를 각자 통째로 램에 올리고 있었습니다. 여섯 개를 돌리면 같은 것이 여섯 벌 있는 셈입니다. 그래서 한 벌만 만들어놓고 여섯이 같이 들여다보게 바꿨습니다.

이걸 공유 메모리라고 합니다. 이름이 「가상 메모리」와 비슷해서 헷갈리기 쉬운데, 완전히 다른 것입니다.

	공유 메모리	가상 메모리
무엇인가	여러 프로그램이 같은 램을 함께 보는 것	램이 모자랄 때 디스크를 램인 척 빌려 쓰는 것
효과	램을 실제로 덜 씁니다	프로그램이 죽는 걸 막아줍니다
속도	빨라집니다	느려집니다 (디스크는 램보다 훨씬 느립니다)

이게 이 글에서 가장 중요한 구분입니다. 가상 메모리는 부족한 램을 메워주지 않습니다. 프로그램이 뻗지 않게 받쳐주는 안전망일 뿐이고, 그 안전망을 쓰기 시작한 순간 이미 느려지고 있습니다. 소리가 끊기는 건 바로 그 순간입니다.

공유 메모리로 바꾸고 나서 여섯 개를 동시에 돌려도 램 여유가 유지됐습니다. 예전 방식으로는 두 개도 못 띄웠습니다.

여기에 세 가지를 더 붙였습니다

① 램을 재고 나서 시작하게 했습니다. 프로그램을 여러 개 띄우기 전에 남은 램을 먼저 재고, 부족하면 개수를 알아서 줄이거나 자리가 날 때까지 기다립니다. 조용히 느려지는 대신 「램이 부족해서 6개를 5개로 줄였다」고 화면에 찍습니다.

② 음악 몫을 따로 비워뒀습니다. 시스템용으로 남겨둘 양을 1GB에서 2GB로 올렸습니다. 계산이 램을 끝까지 긁어가지 않게 막는 장치입니다. 확인해보니 원래 설정은 명목상 1GB였지만 실제로 남는 건 0.14GB뿐이었습니다 — 사실상 아무것도 안 비워두고 있었던 셈입니다.

③ 블루투스 어댑터의 절전 기능을 껐습니다. 이건 램과 무관한데, 확인해보니 켜져 있었습니다. 윈도우가 전원을 아끼려고 블루투스를 잠깐씩 재우는 옵션입니다.

장치 관리자(Win+X → 장치 관리자) → Bluetooth 펼치기 → 어댑터 본체(제 것은 Intel Wireless Bluetooth) 우클릭 → 속성 → 전원 관리 탭 → "전원을 절약하기 위해 이 장치를 끄도록 허용" 체크 해제

⚠ 그 아래 보이는 스피커·이어폰 이름 같은 항목은 연결된 기기라 전원 관리 탭이 없습니다. 어댑터 본체를 찾으셔야 합니다.

그래서 클로드 코드에는 어떤 컴퓨터가 필요한가

여기서부터가 이 글을 쓰는 이유입니다. 위 소동을 겪으면서 알게 된 건 AI로 코딩할 때 병목은 CPU가 아니라 램이라는 것이었습니다.

제 컴퓨터를 그대로 공개합니다.

항목	사양
형태	올인원 데스크탑 (노트북 아님)
CPU	Intel Core Ultra 7 155H · 16코어 / 22스레드 (노트북용 칩)
램	16GB (온보드 · 확장 불가)
저장장치	SSD 512GB
운영체제	Windows 11
가상 메모리	23.5GB (윈도우가 알아서 잡은 값)

그리고 이 글을 쓰고 있는 지금 이 순간의 사용량입니다.

무엇	메모리
클로드 코드 (프로세스 13개)	2,890MB
브라우저 (프로세스 33개)	3,853MB
물리 램 사용률	79% (여유 3.3GB)
프로그램들이 필요하다고 잡아둔 양	16.78GB

「프로세스가 왜 이렇게 많은가」 싶으실 텐데, 브라우저는 탭 하나마다 프로세스를 따로 만듭니다. 한 사이트가 멈춰도 다른 탭과 격리하려는 안전장치입니다. 그리고 프로세스 수는 코어 수와 무관합니다 — 지금 이 컴퓨터에서 도는 프로세스는 291개인데 논리 코어는 22개입니다. 운영체제가 아주 짧은 간격으로 번갈아 배정해서 다 도는 것처럼 보이게 합니다.

⭐그런데 여기에 이 글의 핵심이 들어 있습니다. 프로세스는 코어를 «나눠 쓸» 수 있지만 메모리는 못 나눠 씁니다. 291개가 코어 22개를 돌려쓰는 건 되는데, 각자 잡은 램은 각자 물고 있어야 합니다. 병목이 CPU가 아니라 램이 되는 이유가 이것입니다.

마지막 줄을 보십시오. 16.78GB는 물리 램 15.46GB보다 큽니다. 무거운 계산을 하나도 안 돌리고 글만 쓰는 지금도 이미 램이 모자라는 상태라는 뜻입니다. 모자란 만큼은 디스크가 대신 받아주고 있습니다.

권장 사양 — 제 실측에서 나온 것

일반론이 아니라 위 숫자에서 그대로 나오는 결론만 적겠습니다.

램	제 실측에 비춘 판단
8GB	⛔ 권하지 않습니다. 클로드 코드 2.9GB + 브라우저 3.9GB만 해도 6.8GB인데 윈도우 자체가 이미 몇 GB를 씁니다. 아무것도 안 해도 스왑 구간입니다
16GB	돌아갑니다. 다만 제 경우가 이것이고, 여유가 3.3GB뿐입니다. 무거운 작업을 붙이면 바로 위 소동이 납니다
32GB	⭐ 여기부터 편합니다. 지금 잡아둔 16.78GB의 두 배라 브라우저를 안 닫아도 되고, 계산을 돌리면서 글도 씁니다

CPU는 생각보다 덜 중요했습니다. 제 경우 22개 스레드 중 1개만 쓰는 작업이 병목이었습니다. 물론 프로그램을 어떻게 짜느냐에 따라 다르지만, 「코어를 늘려서 해결되는 문제」와 「램이 없어서 생기는 문제」는 다릅니다. 그리고 후자는 코어를 아무리 늘려도 안 고쳐집니다.

SSD는 있어야 합니다. 램이 모자라 디스크로 밀려나는 상황이 어차피 생기는데, 그때 받아주는 게 저장장치입니다. 이게 느린 하드디스크면 스왑이 시작되는 순간 컴퓨터가 멈춘 것처럼 됩니다.

가상 메모리는 손대지 않아도 됩니다. 제 컴퓨터는 윈도우가 알아서 23.5GB를 잡아뒀고, 저는 아무것도 설정한 적이 없습니다. 그리고 앞서 적었듯 가상 메모리를 아무리 키워도 램 부족은 안 고쳐집니다. 뻗는 걸 막아줄 뿐입니다.

이 일에서 남은 교훈

돌아보면 값진 건 처방이 아니라 순서였습니다.

처음 받은 답은 그럴듯했고, 그대로 적용했으면 프로그램만 느려지고 소리는 계속 끊겼을 것입니다. 원인을 안 고쳤으니까요. 그리고 저는 왜 안 낫는지도 몰랐을 겁니다.

「고치기 전에 먼저 재라」 — 이게 전부입니다. CPU가 문제라는 답을 받았을 때 CPU를 실제로 재봤고, 그 한 번의 측정이 방향을 완전히 바꿨습니다.

클로드 코드로 작업하실 때도 같습니다. 증상만 말하면 흔한 원인을 짚습니다. 대신 "고치기 전에 먼저 측정해줘"라고 하시면 전제부터 확인합니다. 제 경우 그 한마디가 며칠을 아꼈습니다.

컴퓨터를 새로 장만하실 생각이라면 클로드 코드 설치와 첫 실행도 같이 보시면 됩니다.

※ 본문의 수치는 전부 제 컴퓨터에서 실제로 잰 값입니다. 프로그램 구성과 작업 종류에 따라 필요한 사양은 달라질 수 있으니, 권장 사양은 참고용으로 봐주시기 바랍니다.