리눅스 메모리 사용량을 확인하는 5가지 방법 (free, top, htop, vmstat, ps)

서버가 갑자기 느려졌나요? 지난 15년간 수많은 시스템 장애를 해결해 온 제 경험에 비추어 볼 때, 원인의 90%는 CPU 아니면 메모리 문제였습니다. 특히 메모리는 시스템 성능의 가장 민감한 지표 중 하나이지만, 많은 분들이 그 상태를 오해하곤 합니다.

터미널에 free를 입력하고 used 수치가 높게 찍힌 것을 보고 '메모리가 부족하구나!'라고 섣불리 단정 짓는 실수를 저지르곤 하죠. 하지만 그 숫자는 진실의 일부에 불과합니다. 리눅스 커널은 우리가 생각하는 것보다 훨씬 똑똑하게 메모리를 관리하고 있으며, 이 영리한 전략을 이해하지 못하면 엉뚱한 곳에서 원인을 찾게 될 수 있습니다.

이 글 하나로 리눅스 메모리에 대한 모든 오해를 풀고, 시스템의 건강 상태를 정확히 진단하는 전문가의 시각을 얻어가시길 바랍니다. 더 이상 여러 블로그를 전전할 필요가 없을 겁니다. 초심자의 눈높이부터 시작해 시스템의 내부 동작 원리를 파헤치는 전문가의 영역까지, 모든 것을 담았습니다.

내 서버의 메모리, 10초 만에 현황 파악하기 (free)

리눅스 시스템 관리자라면 누구나 가장 먼저 배우는 명령어가 바로 free입니다. 마치 의사가 환자를 처음 볼 때 체온과 혈압부터 재는 것처럼, free 명령어는 시스템 메모리의 전반적인 상태를 가장 빠르고 간단하게 확인하는 기본 도구입니다.

왜 free 명령어의 'free'는 믿으면 안 되는가?

터미널에 free -h를 입력해봅시다. -h 옵션은 사람이 읽기 쉬운 단위(GB, MB)로 보여줍니다.

free -h

실행 결과

---

total used free shared buff/cache available
Mem: 15Gi 4.5Gi 502Mi 2.0Mi 10Gi 10Gi
Swap: 2.0Gi 0B 2.0Gi

여기서 많은 초심자들이 함정에 빠집니다. free 컬럼에 502Mi라는 낮은 숫자를 보고 "아, 내 서버 메모리가 500MB밖에 안 남았구나! 큰일이다!"라고 생각하는 것이죠. 하지만 이는 완전히 잘못된 해석입니다.

이 free 값은 말 그대로 시스템이 부팅된 후 아무도 건드리지 않은, '완전히 놀고 있는' 메모리를 의미합니다. 건강하게 일하고 있는 리눅스 시스템에서 이 수치가 낮은 것은 지극히 정상이며, 오히려 바람직한 상태입니다. 왜 그럴까요? 그 비밀은 바로 옆에 있는 buff/cache에 있습니다.

진짜 봐야 할 숫자: available 메모리의 의미

우리가 정말로 주목해야 할 숫자는 available입니다. 위 예시에서는 10Gi로 표시되어 있네요. 이 available은 현재 실행 중인 애플리케이션에 영향을 주지 않고, 새로운 애플리케이션을 위해 즉시 할당될 수 있는 메모리의 예상치를 의미합니다.

즉, 시스템에 새로운 프로그램을 실행하거나 기존 프로그램이 더 많은 메모리를 요구할 때, 스와핑(Swapping, 디스크를 메모리처럼 사용하는 느린 작업) 없이 바로 내어줄 수 있는 실질적인 여유 공간이 10GB라는 뜻입니다. free 컬럼의 502MB와는 엄청난 차이죠. 이 available 값이야말로 시스템의 메모리 압박 상태를 판단하는 가장 중요한 지표입니다.

'used'를 부풀리는 착한 주범: 버퍼(Buffer)와 캐시(Cache)의 정체

그렇다면 available 메모리는 어떻게 free 메모리보다 훨씬 클 수 있을까요? 정답은 buff/cache에 있습니다. 리눅스 커널은 "사용하지 않는 메모리는 낭비되는 메모리다"라는 철학을 가지고 있습니다. 그래서 당장 사용되지 않는 여유 메모리를 디스크 캐시로 적극 활용하여 시스템 전체의 성능을 끌어올립니다.

이 개념을 작업대에 비유해 보겠습니다.

• 물리 메모리(RAM): 당신의 넓은 작업대(total 15Gi)
• 프로세스가 사용 중인 메모리: 현재 손에 들고 작업 중인 도구들(used의 일부)
• 순수 여유 메모리(free): 작업대 위 아무것도 놓이지 않은 빈 공간(502Mi)
• 버퍼/캐시 메모리(buff/cache): 망치, 드라이버, 렌치처럼 자주 쓰는 도구들을 작업대 위에 미리 꺼내놓은 것(10Gi). 이 도구들은 손에 들고 있진 않지만(프로세스가 직접 사용하진 않지만), 필요할 때 서랍(느린 디스크)을 열지 않고 바로 집을 수 있어 작업 속도가 비약적으로 빨라집니다. 만약 아주 큰 새 프로젝트를 위해 작업대 공간이 필요하다면, 이 도구들을 재빨리 서랍에 다시 집어넣고 공간을 확보할 수 있습니다.

이처럼 buff/cache는 시스템의 성능 향상을 위한 '투자'이지, 낭비가 아닙니다. 기술적으로는 다음과 같이 나뉩니다.

• 버퍼 캐시(Buffer Cache): 파일의 내용이 아닌, 파일의 속성 정보(크기, 소유자, 수정 시간 등 메타데이터)를 저장하는 공간입니다. 파일 시스템 관련 작업을 빠르게 해줍니다.
• 페이지 캐시(Page Cache): 디스크에서 읽어온 파일의 실제 '내용'을 저장하는 공간입니다. 한번 읽은 파일은 페이지 캐시에 저장되어, 다음번에 같은 파일을 요청하면 느린 디스크 대신 빠른 메모리에서 바로 읽어오므로 I/O 성능이 크게 향상됩니다.

결론적으로, free 명령어의 used가 높고 free가 낮더라도, buff/cache와 available이 충분하다면 시스템은 매우 건강하고 효율적으로 작동하고 있는 것입니다.

실전 예제: -h, -w, -t 옵션으로 더 똑똑하게 보기

free 명령어는 몇 가지 유용한 옵션을 제공합니다.

• free -h: 앞서 본 것처럼 사람이 읽기 좋은 단위로 보여주는 가장 기본적인 옵션입니다.
• free -w: 구형 시스템에서 buff/cache가 한 컬럼으로 합쳐져 보일 때, buffers와 cache를 별도의 컬럼으로 나누어 보여줍니다. 더 세밀한 분석이 필요할 때 유용합니다.
• free -s 5: 5초 간격으로 메모리 상태를 계속해서 업데이트하며 보여줍니다. 특정 작업을 실행했을 때 메모리 변화를 실시간으로 관찰하고 싶을 때 매우 유용합니다.

실시간 범인 찾기: 어떤 녀석이 메모리를 잡아먹고 있을까? (top, htop)

free 명령어로 시스템의 전반적인 메모리 건강 상태를 확인했다면, 다음 단계는 "그래서 어떤 프로세스가 메모리를 얼마나 쓰고 있는가?"를 파악하는 것입니다. 이때 사용하는 것이 바로 top과 htop입니다. 이들은 시스템의 CCTV처럼 현재 활동 중인 프로세스들을 실시간으로 감시하는 강력한 도구입니다.

종합 상황실 top: 전체 시스템 상태와 메모리 점유율 확인

top은 리눅스에 기본적으로 설치된 실시간 모니터링 도구입니다. 터미널에 top을 입력하면 시스템의 전반적인 상태(CPU, 로드 에버리지, 작업 수)와 함께 현재 실행 중인 프로세스 목록이 나타납니다.

top

실행 결과

---

top - 10:30:15 up 2 days, 15:40, 1 user, load average: 0.05, 0.10, 0.12
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 0.2 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 15360.0 total, 5120.0 free, 4880.0 used, 5360.0 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 10240.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 root 20 0 2.5g 1.2g 100m S 5.0 8.0 1:23.45 java
6789 mysql 20 0 1.8g 800m 20m S 2.0 5.2 0:45.67 mysqld
...

top 화면에서 메모리 괴물을 찾아내는 가장 빠른 방법은 키보드에서 대문자 M (Shift + m)을 누르는 것입니다. 그러면 프로세스 목록이 메모리 사용량(%MEM) 순으로 정렬되어, 어떤 녀석이 가장 많은 메모리를 차지하고 있는지 한눈에 알 수 있습니다.

top 명령어, 이것만은 알고 쓰자 (VIRT, RES, SHR의 차이)

top의 프로세스 목록에는 VIRT, RES, SHR이라는 세 가지 중요한 메모리 관련 컬럼이 있습니다. 이들의 차이를 이해하는 것이 정확한 분석의 핵심입니다.

많은 개발자들이 VIRT 값이 높은 것을 보고 놀라지만, 실제로 시스템에 부담을 주는 것은 RES (Resident Memory) 입니다. 메모리 부족 문제를 해결할 때는 항상 RES 값을 기준으로 용의자를 찾아야 합니다.

그래서, top보다 htop을 추천하는 진짜 이유는?

top은 훌륭한 도구지만, 1984년에 처음 만들어진 오래된 도구이기도 합니다. 현대적인 시스템 환경에서는 htop이라는 훨씬 더 직관적이고 강력한 대안이 있습니다. 만약 당신의 시스템에 htop이 설치되어 있지 않다면, 지금 바로 설치하는 것을 강력히 추천합니다.

sudo apt install htop

sudo dnf install htop

htop을 추천하는 이유는 단순히 예쁘기 때문이 아닙니다. 진단 효율을 극적으로 높여주는 실용적인 장점들 때문입니다.

• 컬러 디스플레이와 막대 그래프: htop은 CPU 코어별 사용량, 메모리, 스왑 사용량을 텍스트가 아닌 시각적인 막대 그래프로 보여줍니다. 시스템 상태를 1초 만에 파악할 수 있게 해주죠.
• 쉬운 상호작용: top처럼 암호 같은 단축키를 외울 필요가 없습니다. 화살표 키로 위아래로 스크롤하고, F9 키로 프로세스를 종료하는 등 매우 직관적으로 조작할 수 있습니다.
• 트리 뷰(Tree View): F5 키를 누르면 프로세스들이 부모-자식 관계의 트리 구조로 표시됩니다. "대체 이 정체불명의 프로세스는 누가 실행시킨 거지?"라는 의문이 들 때, 그 프로세스의 부모를 추적하여 근원을 파악하는 데 매우 유용합니다.
• 검색 및 필터링: 슬래시(`/`) 키로 특정 프로세스를 빠르게 검색하거나, F4 키로 특정 이름(예: `nginx`)을 포함하는 프로세스들만 필터링해서 볼 수 있어 수많은 프로세스 속에서 원하는 대상을 즉시 찾아낼 수 있습니다.

top에서 htop으로의 진화는 시스템 관리 도구의 큰 흐름을 보여줍니다. 단순히 데이터를 나열하는 것에서 벗어나, 관리자가 더 빠르고 정확하게 상황을 인지할 수 있도록 돕는 사용자 중심의 시각화로 발전하고 있는 것입니다. 비상 상황에서 문제 해결 시간(MTTR, Mean Time To Resolution)을 1분 1초라도 단축해야 하는 SRE나 시스템 관리자에게 htop은 선택이 아닌 필수 도구입니다.

현미경으로 들여다보기: 특정 프로세스 정밀 분석과 근본 원인 파악 (ps, /proc/meminfo)

htop으로 실시간 용의자를 특정했다면, 이제는 현미경을 들고 더 깊이 파고들 차례입니다. ps 명령어는 특정 프로세스를 정밀 타격하거나 스크립트를 통해 자동화된 분석을 할 때, /proc/meminfo는 모든 메모리 정보의 근원인 커널의 속살을 직접 들여다볼 때 사용합니다.

ps 명령어로 특정 프로세스의 메모리 사용량만 콕 집어보기

ps (process status) 명령어는 top이나 htop처럼 실시간으로 업데이트되지는 않지만, 특정 조건의 프로세스 정보를 스냅샷 형태로 보거나 스크립트에 활용하기에 매우 강력합니다.

실용적인 예제:

• 메모리를 가장 많이 사용하는 상위 10개 프로세스 확인 (전통적인 방식):

  # RSS(Resident Set Size, 실제 물리 메모리 사용량) 기준으로 내림차순 정렬
  ps aux --sort -rss | head -n 11

  여기서 aux는 시스템의 모든 프로세스를 자세히 보여주는 옵션이고, --sort -rss는 top의 RES와 같은 개념인 RSS를 기준으로 정렬하라는 의미입니다.

• 메모리를 가장 많이 사용하는 상위 10개 프로세스 확인 (모던한 방식):

  # 원하는 컬럼(PID, 사용자, 메모리%, RSS, 명령어)만 깔끔하게 보기
  ps -eo pid,user,%mem,rss,cmd --sort=-rss | head -n 11

  -eo 옵션을 사용하면 원하는 출력 형식을 직접 지정할 수 있어, awk나 `cut` 같은 추가적인 명령어 없이도 필요한 정보만 깔끔하게 얻을 수 있습니다.

• 특정 프로세스(예: nginx)의 메모리 사용량만 확인:

  # pgrep으로 nginx의 PID를 찾고, ps로 해당 PID의 상세 정보 출력
  ps -p $(pgrep -d, nginx) -o pid,user,%mem,rss,cmd

  이처럼 pgrep과 ps를 파이프라인으로 연결하면 특정 서비스의 상태를 매우 효율적으로 확인할 수 있습니다.

모든 정보의 원천: /proc/meminfo 직접 탐험하기

지금까지 소개한 free, top, htop, ps 같은 명령어들은 사실 모두 하나의 원천에서 정보를 가져와 예쁘게 가공해서 보여주는 것에 불과합니다. 그 원천이 바로 /proc/meminfo라는 가상 파일입니다. 이 파일은 리눅스 커널이 관리하는 메모리 상태를 실시간으로 보여주는 창문과 같습니다. 진정한 전문가가 되려면 이 원천 데이터를 직접 읽고 해석할 줄 알아야 합니다.

cat /proc/meminfo 명령으로 그 내용을 직접 확인해봅시다. 수많은 항목들이 나타나지만, 전문가가 주목하는 핵심 항목들은 다음과 같습니다.

/proc 파일 시스템을 이해하는 것은 단순히 도구를 사용하는 '기술자'에서 시스템의 동작 원리를 이해하는 '엔지니어'로 넘어가는 분기점입니다. 미리 만들어진 도구의 한계를 넘어, 특정 문제에 맞는 자신만의 진단 도구를 만들 수 있게 되기 때문입니다.

쉘 스크립트 활용: 메모리 사용량 임계치 초과 시 알림 받기

/proc/meminfo를 직접 다룰 수 있게 되면 다음과 같은 간단한 자동화 스크립트도 만들 수 있습니다.

#!/bin/bash

# 사용 가능한 메모리 임계치 설정 (단위: KB)
# 예: 500MB = 512000 KB
THRESHOLD=512000

# /proc/meminfo에서 MemAvailable 값을 추출
available_mem_kb=$(grep MemAvailable /proc/meminfo | awk '{print $2}')

# 임계치와 비교하여 로그 남기기
if [ $available_mem_kb -lt $THRESHOLD ]; then
    # 현재 시간과 함께 경고 로그를 파일에 기록
    echo "$(date): WARNING - Available memory is below ${THRESHOLD}KB: ${available_mem_kb}KB" >> /var/log/mem_alert.log
    # 여기에 이메일이나 슬랙 알림을 보내는 로직을 추가할 수 있습니다.
fi

이 스크립트를 cron에 등록해 주기적으로 실행하면, 고가의 모니터링 솔루션 없이도 서버의 메모리 위험 신호를 조기에 감지할 수 있습니다. 이것이 바로 원리를 이해하는 것의 힘입니다.

전문가의 영역: 과거 데이터 분석과 미래 장애 예측 (vmstat, sar)

진정한 전문가는 눈앞의 불을 끄는 데 그치지 않습니다. 재를 분석하여 다음 화재를 예방합니다. vmstat과 sar는 시스템의 과거 행적을 기록하고 분석하여, 현재의 문제를 넘어 미래의 장애를 예측하고 예방하게 해주는 전문가의 도구입니다. 이 영역은 시스템 안정성을 책임지는 SRE나 시니어 관리자에게 특히 중요합니다.

시간의 흐름에 따른 변화 추적: vmstat으로 스와핑(si, so) 감지하기

vmstat (Virtual Memory Statistics)은 시스템의 각종 활동 통계를 일정 간격으로 보여주는 명령어입니다. 특히 메모리가 부족해 디스크를 사용하기 시작하는 '스와핑' 현상을 포착하는 데 매우 효과적입니다.

vmstat 1 10 명령은 1초 간격으로 10번 상태를 출력합니다.

vmstat 1 10

실행 결과

---

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 5242880 102400 5488640 0 0 4 20 100 150 1 1 98 0 0
0 0 0 5242880 102400 5488640 0 0 0 0 110 160 0 0 100 0 0
0 1 0 5242880 102400 5488640 0 256 0 512 120 170 2 3 90 5 0 <-- so 발생! 메모리 부족으로 디스크 쓰기 시작
0 1 256 5242624 102400 5488640 128 0 256 0 130 180 3 4 85 8 0 <-- si 발생! 디스크에서 다시 메모리로 읽어오기 시작
...

여기서 가장 주목해야 할 컬럼은 swap 영역의 si(swap-in)와 so(swap-out)입니다.

• so (Swap-out): 메모리가 부족하여 RAM에 있던 내용을 디스크(스왑 공간)로 내보내는 양.
• si (Swap-in): 디스크로 내보냈던 내용을 다시 RAM으로 불러오는 양.

어쩌다 한 번 so 값이 작게 발생하는 것은 괜찮을 수 있습니다. 하지만 위 예시처럼 so와 si 값이 지속적으로, 그리고 높은 수치로 나타난다면 이는 시스템이 '스레싱(thrashing)' 상태에 빠졌다는 명백한 증거입니다. 스레싱은 메모리가 부족해 RAM과 디스크 간에 데이터를 끊임없이 옮기느라 정작 아무 일도 처리하지 못하는 최악의 성능 저하 상태를 말합니다. vmstat에서 이 현상이 보인다면 즉각적인 조치가 필요합니다.

시스템의 건강검진 기록: sar로 과거 메모리 사용량 리포트 만들기

sar (System Activity Reporter)는 시스템의 '블랙박스'와 같습니다. 시스템의 다양한 성능 지표를 주기적으로 수집하여 파일로 저장해두기 때문에, 이미 지나간 과거의 특정 시점에 시스템에 무슨 일이 있었는지 분석할 수 있게 해줍니다.

sudo apt install sysstat

sudo dnf install sysstat

사용 예제:

• 오늘의 메모리 사용량 기록 보기: -r 옵션은 메모리 통계를 의미합니다.

  sar -r

• 과거 특정 날짜(예: 20일)의 기록 분석: -f 옵션으로 로그 파일을 지정합니다.

  sar -r -f /var/log/sa/sa20

sar의 진정한 가치는 패턴 분석에 있습니다. "매일 새벽 2시에 메모리 사용량이 급증했다가 떨어지는 패턴이 보이네. 혹시 그때 실행되는 백업용 cron job이 범인 아닐까?" 이처럼 sar는 단순한 문제 해결 도구를 넘어, 시스템의 동작 패턴을 이해하고 잠재적인 문제를 사전에 찾아내는 분석 도구의 역할을 합니다.

[심화] OOM Killer는 왜, 언제, 누구를 죽이는가?

OOM Killer (Out of Memory Killer)는 시스템이 메모리 부족으로 완전히 멈춰버리는 최악의 상황을 막기 위해 리눅스 커널이 사용하는 최후의 수단입니다. 커널이 더 이상 메모리를 확보할 수 없을 때, 특정 프로세스를 강제로 '죽여서' 메모리를 회수하는 비상 장치입니다. OOM Killer가 동작했다는 것은 시스템이 심각한 메모리 고갈 상태에 처했다는 뜻입니다.

• 왜, 언제 동작하는가? 커널이 캐시를 비우는 등 모든 노력을 다했음에도 불구하고 합법적인 메모리 할당 요청을 처리할 수 없을 때 발동됩니다.
• 누구를 죽이는가? OOM Killer는 무작위로 희생양을 고르지 않습니다. 각 프로세스마다 oom_score라는 점수를 계산하여 가장 점수가 높은 프로세스를 종료시킵니다. 일반적으로 다음과 같은 프로세스가 높은 점수를 받습니다.
  • 메모리를 많이 사용하고 있는 프로세스
  • 실행된 지 얼마 안 된 프로세스
  • 우선순위(nice 값)가 낮은 프로세스
• 어떻게 확인하고 대처하는가?
  • OOM 발생 확인:

    dmesg | grep -i "out of memory"

    명령으로 커널 로그에서 OOM Killer의 흔적을 찾을 수 있습니다.
  • 프로세스 점수 확인:

    cat /proc/PID/oom_score

    로 특정 프로세스의 현재 OOM 점수를 볼 수 있습니다.
  • 중요 프로세스 보호: 데이터베이스처럼 절대 죽으면 안 되는 중요한 프로세스는 OOM Killer의 희생양이 되지 않도록 보호할 수 있습니다.

    echo -1000 > /proc/PID/oom_score_adj

    명령을 실행하면 해당 프로세스의 점수가 크게 낮아져 사실상 OOM Kill 대상에서 제외됩니다.

[심화] 메모리 누수(Memory Leak) 탐지를 위한 기본 접근법

메모리 누수는 프로세스가 메모리를 할당받아 사용한 뒤, 이를 해제하지 않아 RES 사용량이 무한정 증가하는 현상입니다. 단기적인 모니터링으로는 찾기 어렵습니다.

메모리 누수를 탐지하는 가장 기본적인 전략은 장기적인 추세 관찰입니다. sar나 상용 모니터링 도구를 사용하여 핵심 애플리케이션의 RES 값을 며칠, 혹은 몇 주에 걸쳐 추적합니다. 다른 요인이 없음에도 불구하고 RES 값이 계단식으로 꾸준히, 그리고 결코 줄어들지 않고 증가한다면 이는 메모리 누수의 전형적인 징후입니다. 이처럼 과거 데이터 분석은 실시간으로 보이지 않는 서서히 진행되는 문제를 찾아내는 데 결정적인 역할을 합니다.

마무리: 진정한 의미의 메모리 관리

지금까지 우리는 리눅스 메모리 사용량을 확인하는 여정을 함께했습니다. free 명령어의 숫자가 주는 착시에서 시작해, htop으로 실시간 범인을 추적하고, ps와 /proc/meminfo로 현미경 분석을 거쳐, sar와 OOM Killer라는 전문가의 영역까지 탐험했습니다.

이제 여러분은 더 이상 free 명령어의 used 숫자에 속지 않을 것입니다. available의 중요성을 이해하고, buff/cache가 시스템을 위한 현명한 투자임을 알게 되었습니다. 어떤 도구를 언제 사용해야 하는지, 그리고 각 도구가 보여주는 숫자들이 시스템 내부에서 어떤 의미를 갖는지에 대한 깊은 통찰을 얻으셨기를 바랍니다.

진정한 의미의 메모리 관리는 단순히 숫자를 읽는 행위가 아닙니다. 시스템의 동작 철학을 이해하고, 데이터의 이면에 숨겨진 '이야기'를 해석하며, 과거의 데이터를 바탕으로 미래를 예측하는 종합적인 기술입니다. 오늘 배운 명령어들을 여러분의 서버에서 직접 실행해보며 진짜 '내 것'으로 만드시길 바랍니다. 시스템이 보내는 신호를 정확히 읽어내는 유능한 엔지니어로 거듭나는 첫걸음이 될 것입니다.

자주 묻는 질문 (FAQ)

(초심자): `buff/cache` 메모리가 너무 많은데, 수동으로 비워주는 게 좋은가요?

echo 3 > /proc/sys/vm/drop_caches

(전문가): `swappiness` 값을 조절하는 것이 항상 성능에 도움이 되나요?

(관리자/아키텍트): 클라우드에서 서비스에 적절한 메모리 용량을 산정하는 팁이 있을까요?