EVM 메모리 완벽 정리: 레이아웃·확장 가스·Solidity 안전 수칙

Solidity 함수는 단순해 보여도 예상보다 많은 가스를 쓰거나, 직접 작성한 어셈블리 때문에 엉뚱하게 동작할 수 있어요. 이때 놓치기 쉬운 작업 공간이 **EVM 메모리(EVM Memory)**입니다. 메모리를 이해하면 실용적인 블록체인 기초와 컨트랙트가 읽고, 바꾸고, 해시하고, 반환한 뒤 버리는 바이트를 연결해서 볼 수 있습니다.

호출마다 새 모눈종이 두루마리를 받는다고 생각해 보세요. 컨트랙트는 종이 어디든 메모할 수 있지만, 더 멀리 펼칠수록 가스를 냅니다. 호출이 끝나면 종이는 폐기돼요. 이 글에서는 Solidity가 기대하는 메모리 레이아웃, 현재 확장 비용 공식, 저수준 코드를 검토할 때 지켜야 할 안전 경계를 설명합니다.

EVM 메모리란 무엇인가요?

컨트랙트 실행 중 EVM은 수명이 서로 다른 여러 데이터 영역을 사용합니다. 이더리움 EVM 공식 문서는 메모리를 일시적인 바이트 주소 기반 작업 공간으로 설명해요. 256비트 스택(Stack), 영구적인 컨트랙트 스토리지(Storage)와 별개입니다.

각 메시지 호출 프레임(Call Frame)은 독립된 메모리를 받아요. 자식 호출이 부모 메모리를 직접 공유하지는 않습니다. 호출 명령은 지정된 입력 바이트를 자식 실행 맥락으로 복사하고, 실행 뒤 반환 데이터를 다시 복사해요. 새 프레임의 메모리는 0으로 시작하고 성공이나 리버트(Revert) 여부와 관계없이 프레임이 끝나면 사라집니다.

데이터 영역	일반적인 용도	쓰기 가능 여부	수명
스택(Stack)	연산자와 작은 값	가능	현재 호출 프레임
메모리(Memory)	변경 가능한 임시 바이트	가능	현재 호출 프레임
콜데이터(Calldata)	외부 호출 입력	불가	현재 호출 프레임
스토리지(Storage)	컨트랙트 상태	가능	트랜잭션 이후에도 유지
트랜지언트 스토리지	임시 컨트랙트 상태	가능	현재 트랜잭션

이 차이는 의미와 비용을 모두 바꿉니다. 참조형 데이터를 calldata나 storage에서 memory로 옮기면 독립된 복사본이 생겨요. 반면 메모리 변수끼리 대입하면 같은 객체를 가리키는 또 다른 참조가 만들어질 수 있습니다. 정확한 규칙은 Solidity의 데이터 위치와 대입 동작 문서에서 확인할 수 있어요.

Solidity 메모리 레이아웃은 어떻게 생겼나요?

EVM 자체에는 평평한 바이트 배열이 있습니다. Solidity는 컴파일된 코드와 인라인 어셈블리가 같은 의미로 영역을 사용하도록 규칙을 더해요. 공식 메모리 레이아웃 문서는 처음 128바이트를 다음처럼 예약합니다.

바이트 범위	Solidity 규칙
`0x00–0x3f`	해싱 같은 짧은 연산을 위한 64바이트 스크래치 공간
`0x40–0x5f`	프리 메모리 포인터(Free Memory Pointer)가 들어 있는 워드
`0x60–0x7f`	빈 동적 배열의 초기 포인터로 쓰는 제로 슬롯(Zero Slot)
`0x80…`	일반 할당 영역

0x40에 저장된 값은 처음에 0x80을 가리킵니다. 고수준 Solidity는 새 객체를 현재 프리 포인터 위치에 놓고 포인터를 앞으로 옮겨요. 호출 중 메모리를 해제하는 내장 기능은 없습니다.

동적 메모리 배열은 32바이트 길이 값으로 시작하고 원소가 뒤따릅니다. 대부분의 배열 원소는 Solidity 자료형이 더 작아도 32바이트의 배수를 차지하지만 bytes와 string은 촘촘하게 저장되는 예외예요. 고정 길이 메모리 배열에는 길이 워드가 없습니다. 작은 값 여러 개가 하나의 영구 슬롯을 나눠 쓸 수 있는 이더리움 컨트랙트 스토리지 슬롯과는 배치 규칙이 달라요.

Warning

프리 메모리 포인터 이후의 미사용 영역이 항상 0이라고 가정하면 안 됩니다. Solidity는 포인터를 옮기지 않은 채 그 이후 공간을 임시로 쓸 수 있고, 공식 문서도 이 영역이 0으로 초기화되어 있다고 기대하지 말라고 경고해요.

MLOAD·MSTORE와 가장 높은 바이트 규칙

세 가지 기본 명령을 보면 구조가 선명해집니다.

MLOAD(offset)는 offset부터 32바이트를 읽어요.
MSTORE(offset, value)는 32바이트 워드 전체를 씁니다.
MSTORE8(offset, value)는 value의 가장 낮은 바이트 하나를 써요.

명령이 현재 활성 크기 밖의 비어 있지 않은 범위에 접근하면 메모리가 확장됩니다. 새 크기는 32바이트 워드 경계로 올림해요. 몇 바이트만 쓰려 했는지가 아니라 도달한 가장 높은 바이트가 확장량을 결정합니다. 아주 큰 오프셋 한 곳에 쓰는 것만으로도 그 지점까지 모든 메모리를 요구해 가스 부족(Out of Gas)이 날 수 있어요.

콜데이터나 반환 데이터를 복사하고, 메모리 영역을 해시하고, 로그 데이터를 내보내고, 다른 컨트랙트를 호출하거나, 결과 또는 리버트 데이터를 반환할 때도 메모리를 사용합니다. 각 명령 자체의 비용이나 워드별 비용은 아래의 메모리 확장 추가 비용과 별도로 계산돼요.

EVM 메모리 확장 가스는 어떻게 계산하나요?

현재 이더리움 EVM 규칙에서 활성 메모리 크기가 32바이트 워드 a개일 때 누적 비용은 다음과 같습니다.

Cmem(a) = 3 × a + floor(a² / 512)

이더리움 옐로 페이퍼가 이 공식을 정의합니다. 한 명령은 접근 전후 누적 비용의 차이만 지불해요.

확장 비용 = Cmem(확장 후 워드 수) - Cmem(확장 전 워드 수)

따라서 조금씩 여러 번 늘린다고 최종 누적 확장 비용을 피할 수는 없습니다. 이차항은 22워드까지 0이고 23워드부터 처음 생겨요. 가장 높은 접근 오프셋이 커질수록 영향도 커집니다.

활성 메모리	워드 수	누적 `Cmem` 가스
128바이트	4	12
704바이트	22	66
736바이트	23	70
1,024바이트	32	98
4,096바이트	128	416

이 숫자는 순수한 EVM 메모리 확장 가스이지 사용자가 내는 전체 트랜잭션 수수료가 아닙니다. 실제 비용에는 다른 모든 명령, 콜데이터, 상태 접근, 사용 가스, 기본 수수료(Base Fee), 우선 수수료(Priority Fee)가 함께 반영돼요. 전체 가스비는 더 넓은 실행 맥락까지 포함해 계산해야 합니다.

공식 실행 명세 구현도 같은 워드 올림, 선형항, 이차항, 차액 부과 방식을 코드로 표현합니다. 포크 규칙은 바뀔 수 있으므로 가스에 민감한 도구는 블로그 공식을 영구 상수로 취급하지 말고 대상 네트워크의 활성 명세를 확인해야 해요. 예를 들어 EIP-7686은 선형 메모리 한도를 제안하지만 상태가 Stagnant입니다. 위에서 설명한 현재 적용 규칙이 아니에요.

인라인 어셈블리에서 안전하게 할당하는 패턴

Solidity 인라인 어셈블리 문서는 핵심 할당 방식을 다음처럼 보여줍니다.

function allocate(uint256 length) pure returns (uint256 pos) {
    assembly ("memory-safe") {
        pos := mload(0x40)
        mstore(0x40, add(pos, length))
    }
}

실제 할당 코드는 이후 객체가 워드 정렬을 요구한다면 바이트 길이를 올림하고, 덧셈이 넘치지 않는지도 확인해야 합니다. 핵심 순서는 단순해요. 포인터를 읽고, 겹치지 않는 영역을 예약한 뒤, Solidity가 다른 객체를 같은 자리에 놓기 전에 포인터를 갱신합니다.

memory-safe 표시는 런타임 안전장치가 아닙니다. 해당 블록이 Solidity 관리 메모리, 직접 올바르게 할당한 메모리, 0x00–0x3f 스크래치 영역 또는 조건에 맞는 포인터 이후 임시 영역만 건드린다는 컴파일러와의 약속이에요. 컴파일러는 이 약속을 믿고 추가 최적화를 적용할 수 있습니다. 거짓으로 표시하면 테스트에서 쉽게 드러나지 않는 잘못된 미정의 동작이 생길 수 있어요.