Solidity 컴파일러 설치

Solidity 컴파일러 설치 (Installing the Solidity Compiler)

Solidity 컴파일러를 설치하고 사용하는 다양한 방법을 소개해요. Remix, npm(Node.js), Docker, Linux·macOS 패키지, 정적 바이너리, 소스 빌드까지 상황에 맞는 방법을 고를 수 있어요. 배포에는 항상 최신 릴리스 버전을 사용하는 것이 좋아요.

출처: 문서

본문

버전 관리 (Versioning)

Solidity 버전은 의미적 버전 관리(Semantic Versioning)를 따르며, 그 외에도 메이저 릴리스 0(즉 0.x.y)을 가진 패치 수준 릴리스는 breaking change를 포함하지 않아요. 즉 버전 0.x.y로 컴파일되는 코드는 0.x.z(z > y)로도 컴파일될 거라고 기대할 수 있어요.

릴리스 외에도 다가오는 기능을 시험하고 조기 피드백을 제공하기 쉽도록 prerelease와 nightly 개발 빌드를 제공해요. 그런 빌드는 개발 브랜치의 최첨단(bleeding-edge) 코드를 포함하며 전체 릴리스와 같은 품질이 보장되지 않아요. 우리의 최선의 노력에도 불구하고, 실제 릴리스의 일부가 되지 않을 문서화되지 않았거나 깨진 변경을 포함할 수 있어요. 프로덕션용으로 만들어지지 않았어요.

컨트랙트를 배포할 때는 Solidity의 최신 릴리스 버전을 사용해야 해요. breaking change와 새 기능, 버그픽스가 정기적으로 도입되기 때문이에요. 우리는 현재 빠른 변경 속도를 나타내기 위해 0.x 버전 번호를 사용해요.

Remix

작은 컨트랙트와 Solidity를 빨리 배우는 데는 Remix를 권장해요. 온라인으로 Remix에 접속하면 되고, 아무것도 설치할 필요가 없어요. 인터넷 연결 없이 사용하고 싶으면 릴리스 페이지에서 Remix Desktop을 다운로드해요. Remix는 여러 Solidity 버전을 설치하지 않고 nightly 빌드를 테스트하기에도 편리한 옵션이에요.

이 페이지의 추가 옵션들은 컴퓨터에 명령줄 Solidity 컴파일러 소프트웨어를 설치하는 것을 자세히 설명해요. 더 큰 컨트랙트를 작업하거나 더 많은 컴파일 옵션이 필요하면 명령줄 컴파일러를 선택해요.

npm / Node.js

Solidity 컴파일러인 solcjs를 설치하는 편리하고 이식 가능한 방법으로 npm을 사용해요. solcjs 프로그램은 이 페이지 아래쪽에서 설명하는 컴파일러 접근 방식보다 기능이 적어요. 명령줄 컴파일러 사용하기 문서는 완전한 기능을 가진 컴파일러 solc를 사용한다고 가정해요. solcjs의 사용법은 자체 저장소 안에 문서화돼 있어요.

참고: solc-js 프로젝트는 Emscripten을 사용해 C++ solc에서 파생됐으며, 이는 둘 다 같은 컴파일러 소스 코드를 사용한다는 뜻이에요. solc-js는 JavaScript 프로젝트에서(Remix처럼) 직접 사용될 수 있어요. 지침은 solc-js 저장소를 참고해요.

npm install --global solc

참고 (Note)

명령줄 실행 파일의 이름은 solcjs예요. solcjs의 명령줄 옵션은 solc와 호환되지 않으며, solc의 동작을 기대하는 도구(geth 같은)는 solcjs에서 동작하지 않아요.

Docker

Solidity 빌드의 Docker 이미지는 ghcr.io의 argotorg 조직의 solc 이미지를 사용해 사용할 수 있어요. 최신 릴리스 버전에는 stable 태그를, develop 브랜치의 잠재적으로 불안정한 변경에는 nightly를 사용해요.

Docker 이미지는 컴파일러 실행 파일을 실행하므로 모든 컴파일러 인자를 그것에 전달할 수 있어요. 예를 들어 아래 명령은 solc 이미지의 스테이블 버전을 가져와서(아직 없다면) 새 컨테이너에서 실행하며, --help 인자를 전달해요.

docker run ghcr.io/argotorg/solc:stable --help

참고 (Note)

특정 컴파일러 버전은 ghcr.io/argotorg/solc:0.8.23 같은 Docker 이미지 태그로 지원돼요. 우리는 사용자가 기본으로 최신 버전을 얻고 오래된 버전 문제를 피하도록, 특정 버전 태그 대신 여기서 stable 태그를 전달할 거예요.

Docker 이미지를 사용해 호스트 머신의 Solidity 파일을 컴파일하려면, 입력과 출력을 위한 로컬 폴더를 마운트하고 컴파일할 컨트랙트를 지정해요. 예를 들어:

docker run \
    --volume "/tmp/some/local/path/:/sources/" \
    ghcr.io/argotorg/solc:stable \
        /sources/Contract.sol \
        --abi \
        --bin \
        --output-dir /sources/output/

표준 JSON 인터페이스도 사용할 수 있어요(도구링과 함께 컴파일러를 사용할 때 권장). 이 인터페이스를 사용할 때, JSON 입력이 자급자족적(즉 임포트 콜백이 로드해야 하는 외부 파일을 참조하지 않는)이라면 어떤 디렉토리도 마운트할 필요가 없어요.

docker run ghcr.io/argotorg/solc:stable --standard-json < input.json > output.json

Linux 패키지 (Linux Packages)

우리는 추가 설치 단계 없이 대부분의 배포판에서 실행되어야 하는 컴파일러의 독립 바이너리를 제공해요. 0.8.30까지 버전에 대한 Ubuntu 패키지는 ethereum/ethereum PPA에서 사용할 수 있어요. 그러나 우리는 이 배포 방식을 중단했고 미래 버전은 거기에 추가되지 않을 거예요.

일부 Linux 배포판은 자체 패키지를 제공해요. 이 패키지들은 직접 유지하지 않지만 보통 각 패키지 관리자가 최신 상태로 유지해요.

일부 배포판에서는 컴파일러를 빌드하고 설치하는 비공식적이고 커뮤니티가 유지하는 스크립트도 사용할 수 있어요:

  • Arch Linux / (AUR): solidity(소스에서 빌드), solidity-bin(독립 바이너리 사용).
  • Nix: solc.nix(소스에서 빌드).

참고 (Note)

이 스크립트들은 사용자가 만들고 유지하며 distro 유지관리자가 어떤 식으로든 검증하지 않아요. 사용에 주의를 기울이세요.

snap 패키지도 있지만 현재는 유지되지 않아요. 지원되는 모든 Linux distro에 설치할 수 있어요. 최신 스테이블 버전의 solc를 설치하려면:

sudo snap install solc

가장 최근의 변경이 있는 Solidity 최신 개발 버전 테스트를 돕고 싶다면 다음을 사용해요:

sudo snap install solc --edge

참고 (Note)

solc snap은 strict confinement를 사용해요. 이것은 snap 패키지의 가장 안전한 모드지만, /home과 /media 디렉토리의 파일에만 접근하는 것 같은 제한을 수반해요. 자세한 내용은 Demystifying Snap Confinement을 참고해요.

macOS 패키지 (macOS Packages)

Homebrew를 통해 Solidity 컴파일러를 소스 빌드 버전으로 배포해요. 사전 빌드된 병(bottles)은 현재 지원되지 않아요.

brew update
brew upgrade
brew tap ethereum/ethereum
brew install solidity

가장 최근의 0.4.x / 0.5.x 버전의 Solidity를 설치하려면 각각 brew install solidity@4와 brew install solidity@5를 사용할 수도 있어요.

특정 버전의 Solidity가 필요하면 GitHub에서 Homebrew 공식을 직접 설치할 수 있어요. GitHub에서 solidity.rb 커밋을 봐요. 원하는 버전의 커밋 해시를 복사해 머신에서 체크아웃해요.

git clone https://github.com/ethereum/homebrew-ethereum.git
cd homebrew-ethereum
git checkout <your-hash-goes-here>

brew로 설치해요:

brew unlink solidity
# eg. Install 0.4.8
brew install solidity.rb

정적 바이너리 (Static Binaries)

모든 지원 플랫폼에 대한 과거·현재 컴파일러 버전의 정적 빌드를 포함하는 저장소를 solc-bin에서 유지해요. nightly 빌드를 찾을 수 있는 곳이기도 해요. 이 저장소는 최종 사용자가 박스에서 바로 쓸 수 있는 바이너리를 얻는 빠르고 쉬운 방법일 뿐 아니라, 제3자 도구에도 친숙하도록 만들어졌어요:

  • 콘텐츠는 https://binaries.soliditylang.org에 미러되며, 인증 없이, 속도 제한 없이, git 사용 없이 HTTPS로 쉽게 다운로드할 수 있어요.
  • 콘텐츠는 올바른 Content-Type 헤더와 관대한 CORS 구성으로 제공돼 브라우저에서 실행되는 도구가 직접 로드할 수 있어요.
  • 바이너리는 설치나 압축 해제를 요구하지 않아요(필요한 DLL과 함께 번들된 오래된 Windows 빌드 제외).
  • 우리는 높은 수준의 하위 호환을 위해 노력해요. 한번 추가된 파일은 제거되거나 이동되지 않으며, 옛 위치에 symlink/redirect를 제공해요. 또한 제자리에서 수정되지 않고 항상 원본 체크섬과 일치해야 해요. 유일한 예외는 그대로 두면 해로움보다 이로움이 큰 깨진 또는 사용할 수 없는 파일이에요.
  • 파일은 HTTP와 HTTPS 둘 다로 제공돼요. 파일 목록을 안전한 방식으로(git, HTTPS, IPFS로 또는 그냥 로컬에 캐시해서) 얻고 다운로드 후 바이너리의 해시를 검증한다면, 바이너리 자체에 HTTPS를 사용할 필요가 없어요.

같은 바이너리는 대부분의 경우 GitHub의 Solidity 릴리스 페이지에서도 사용할 수 있어요. 차이는 일반적으로 GitHub 릴리스 페이지에서 옛 릴리스를 갱신하지 않는다는 것이에요. 즉 이름 규칙이 바뀌어도 이름을 바꾸지 않고, 릴리스 시점에 지원되지 않았던 플랫폼에 대한 빌드도 추가하지 않아요. 이는 solc-bin에서만 일어나요.

solc-bin 저장소에는 각각 단일 플랫폼을 나타내는 여러 최상위 디렉토리가 있어요. 각각은 사용 가능한 바이너리를 나열하는 list.json 파일을 포함해요. 예를 들어 emscripten-wasm32/list.json에서 버전 0.7.4에 대한 다음 정보를 찾을 수 있어요:

{
  "path": "solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js",
  "version": "0.7.4",
  "build": "commit.3f05b770",
  "longVersion": "0.7.4+commit.3f05b770",
  "keccak256": "0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3",
  "sha256": "0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2",
  "urls": [
    "dweb:/ipfs/QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS"
  ]
}

이는 다음을 의미해요:

  • 같은 디렉토리에서 solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js 이름으로 바이너리를 찾을 수 있어요. 파일이 symlink일 수 있으며, git으로 다운로드하지 않거나 파일시스템이 symlink를 지원하지 않으면 직접 해석해야 해요.
  • 바이너리는 https://binaries.soliditylang.org/emscripten-wasm32/solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js에도 미러돼 있어요. 이 경우 git이 필요하지 않고 symlink는 파일 사본을 제공하거나 HTTP redirect를 반환해 투명하게 해석돼요.
  • 파일은 IPFS의 QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS에서도 사용할 수 있어요. urls 배열의 항목 순서는 미리 정해지거나 보장되지 않으며 사용자가 의존해서는 안 된다는 점을 알아두세요.
  • 바이너리의 무결성은 그 keccak256 해시를 0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3과 비교해 검증할 수 있어요. 해시는 명령줄에서 sha3sum이 제공하는 keccak256sum 유틸리티나 JavaScript의 ethereumjs-util의 keccak256() 함수로 계산할 수 있어요.
  • 바이너리의 무결성은 그 sha256 해시를 0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2과 비교해서도 검증할 수 있어요.

경고 (Warning)

강한 하위 호환 요구 때문에 저장소에는 일부 레거시 요소가 있지만, 새 도구를 작성할 때는 그것들을 피해야 해요:

  • 최고의 성능을 원한다면 bin/ 대신 emscripten-wasm32/을 사용해요(emscripten-asmjs/ 폴백 포함). 버전 0.6.1까지 우리는 asm.js 바이너리만 제공했어요. 0.6.2부터 훨씬 더 나은 성능의 WebAssembly 빌드로 전환했어요. 옛 버전을 wasm용으로 다시 빌드했지만 원래 asm.js 파일은 bin/에 남아 있어요. 새 파일은 이름 충돌을 피하기 위해 별도 디렉토리에 배치해야 했어요.
  • wasm인지 asm.js 바이너리인지 확실히 하고 싶다면 bin/과 wasm/ 디렉토리 대신 emscripten-asmjs/와 emscripten-wasm32/을 사용해요.
  • list.js와 list.txt 대신 list.json을 사용해요. JSON 목록 형식은 옛 형식의 모든 정보와 그 이상을 포함해요.

경고 (Warning)

solc-bin.ethereum.org 도메인은 더 이상 지원되지 않아요. 앞으로 Solidity 바이너리의 소스로 여전히 그것을 사용하는 도구는 binaries.soliditylang.org로 전환할 것을 권장해요.

경고 (Warning)

바이너리는 https://argotorg.github.io/solc-bin/에서도 사용할 수 있지만, 이 페이지는 버전 0.7.2의 릴리스 직후에 업데이트가 중단됐으며, 어떤 플랫폼에 대해서도 새 릴리스나 nightly 빌드를 받지 않고, non-emscripten 빌드를 포함한 새 디렉토리 구조를 제공하지 않아요. 사용 중이라면 드롭인 교체인 https://binaries.soliditylang.org로 전환해요. 이렇게 하면 기본 호스팅을 투명하게 변경하고 중단을 최소화할 수 있어요. 우리가 전혀 통제하지 않는 argotorg.github.io 도메인과 달리, binaries.soliditylang.org는 장기적으로 동작하고 같은 URL 구조를 유지함을 보장해요.

소스에서 빌드 (Building from Source)

사전 요구사항 - 모든 운영체제 (Prerequisites - All Operating Systems)

다음은 모든 Solidity 빌드의 의존성들이에요:

소프트웨어 비고
CMake (Windows에서 버전 3.21.3+, 그 외 3.13+) 크로스-플랫폼 빌드 파일 생성기.
Boost (버전 1.83+) C++ 라이브러리.
Git 소스 코드 검색용 명령줄 도구.
z3 (버전 4.8.16+, 선택) SMT checker와 함께 사용.

참고 (Note)

0.5.10 이전 Solidity 버전은 Boost 1.70+ 버전에 제대로 링크되지 않을 수 있어요. 가능한 해결책은 cmake 명령을 실행해 Solidity를 구성하기 전에 <Boost install path>/lib/cmake/Boost-1.70.0을 일시적으로 이름을 바꾸는 것이에요. 0.5.10부터 Boost 1.70+에 대한 링크는 수동 개입 없이 동작해야 해요.

참고 (Note)

기본 빌드 구성은 특정 Z3 버전(코드가 마지막으로 갱신된 시점의 최신 버전)을 요구해요. Z3 릴리스 사이에 도입된 변경은 종종 약간 다른(그러나 여전히 유효한) 결과가 반환되게 해요. 우리의 SMT 테스트는 이러한 차이를 고려하지 않으므로, 테스트가 작성된 버전과 다른 버전에서는 실패할 가능성이 높아요. 이것은 다른 버전을 사용한 빌드가 잘못됐다는 뜻은 아니에요. CMake에 -DSTRICT_Z3_VERSION=OFF 옵션을 전달하면 위 표의 요구를 충족하는 어떤 버전으로도 빌드할 수 있어요. 그러나 그렇게 하면 SMT 테스트를 건너뛰려고 --no-smt 옵션을 scripts/tests.sh에 전달하는 것을 기억해야 해요.

참고 (Note)

기본적으로 빌드는 pedantic 모드로 수행되며, 이는 추가 경고를 활성화하고 컴파일러가 모든 경고를 에러로 취급하도록 지시해요. 이는 개발자가 경고가 생기면 고치도록 강제하여 "나중에 고치기"가 축적되지 않게 해요. 릴리스 빌드를 만드는 것에만 관심이 있고 그런 경고를 처리하도록 소스 코드를 수정할 의도가 없다면, CMake에 -DPEDANTIC=OFF 옵션을 전달해 이 모드를 비활성화할 수 있어요. 일반 사용에는 권장되지 않지만, 우리가 테스트하지 않는 툴체인을 사용하거나 더 새 도구로 옛 버전을 빌드하려 할 때 필요할 수 있어요. 그런 경고를 만나면 보고해 주시길 고려해요.

최소 컴파일러 버전 (Minimum Compiler Versions)

다음 C++ 컴파일러와 최소 버전으로 Solidity 코드베이스를 빌드할 수 있어요:

  • GCC, 버전 13.3+
  • Clang, 버전 18.1.3+
  • MSVC, 버전 2019+

사전 요구사항 - macOS (Prerequisites - macOS)

macOS 빌드의 경우 최신 버전의 Xcode가 설치되어 있는지 확인해요. 여기에는 Clang C++ 컴파일러, Xcode IDE 및 OS X에서 C++ 애플리케이션을 빌드하는 데 필요한 기타 Apple 개발 도구가 포함돼요. Xcode를 처음 설치하거나 새 버전을 방금 설치했다면, 명령줄 빌드를 하기 전에 라이선스에 동의해야 해요:

sudo xcodebuild -license accept

우리 OS X 빌드 스크립트는 외부 의존성 설치에 Homebrew 패키지 관리자를 사용해요. 처음부터 다시 시작하고 싶다면 Homebrew를 제거하는 방법은 다음과 같아요.

사전 요구사항 - Windows (Prerequisites - Windows)

Windows 빌드에는 다음 의존성을 설치해야 해요:

소프트웨어 비고
Visual Studio 2019 Build Tools C++ 컴파일러
Visual Studio 2019 (선택) C++ 컴파일러와 개발 환경.
Boost (버전 1.77+) C++ 라이브러리.

이미 IDE가 하나 있고 컴파일러와 라이브러리만 필요하다면 Visual Studio 2019 Build Tools를 설치할 수 있어요. Visual Studio 2019는 IDE와 필요한 컴파일러·라이브러리 둘 다 제공해요. IDE가 없고 Solidity를 개발하려 한다면, Visual Studio 2019가 모든 것을 쉽게 설정하게 해주는 선택이 될 수 있어요.

Visual Studio 2019 Build Tools 또는 Visual Studio 2019에 설치해야 할 구성 요소 목록은 다음과 같아요:

  • Visual Studio C++ 핵심 기능
  • VC++ 2019 v141 툴셋 (x86, x64)
  • Windows Universal CRT SDK
  • Windows 8.1 SDK
  • C++/CLI 지원

필요한 모든 외부 의존성을 설치하는 헬퍼 스크립트가 있어요:

scripts\install_deps.ps1

이것은 boost와 cmake를 deps 하위 디렉토리에 설치할 거예요.

저장소 클론 (Clone the Repository)

소스 코드를 클론하려면 다음 명령을 실행해요:

git clone --recursive https://github.com/argotorg/solidity.git
cd solidity

Solidity 개발을 돕고 싶다면 Solidity를 포크하고 개인 포크를 두 번째 remote로 추가해야 해요:

git remote add personal [email protected]:[username]/solidity.git

참고 (Note)

이 방법은 prerelease 빌드를 만들어 예를 들어 그런 컴파일러가 만든 각 바이트코드에 플래그가 설정되는 결과를 내요. 릴리스된 Solidity 컴파일러를 다시 빌드하려면 GitHub 릴리스 페이지의 소스 tarball을 사용해요: https://github.com/argotorg/solidity/releases/download/v0.X.Y/solidity_0.X.Y.tar.gz (GitHub가 제공하는 "Source code"가 아니라).

명령줄 빌드 (Command-Line Build)

빌드 전에 외부 의존성(위 참고)을 설치해야 해요. Solidity 프로젝트는 빌드를 구성하는 데 CMake를 사용해요. 반복 빌드를 빠르게 하려면 ccache를 설치하고 싶을 수도 있어요. CMake가 자동으로 그것을 잡아요.

Linux, macOS 및 기타 Unix에서 Solidity 빌드는 상당히 비슷해요:

mkdir build
cd build
cmake .. && make

또는 Linux와 macOS에서는 더 쉽게 다음을 실행할 수 있어요:

# note: this will install binaries solc and soltest at usr/local/bin
./scripts/build.sh

경고 (Warning)

BSD 빌드는 동작해야 하지만 Solidity 팀이 테스트하지는 않았어요.

Windows:

mkdir build
cd build
cmake -G "Visual Studio 16 2019" ..

scripts\install_deps.ps1이 설치한 boost 버전을 사용하려면 cmake 호출에 -DBoost_ROOT="deps/boost" -DBoost_INCLUDE_DIR="deps/boost/include"와 -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded를 인자로 추가로 전달해야 해요. 이는 그 빌드 디렉토리에 solidity.sln이 생성되는 결과를 내야 해요. 그 파일을 더블클릭하면 Visual Studio가 시작돼요. Release 구성을 빌드하는 걸 권장하지만, 다른 모든 것도 동작해요.

대안으로 다음처럼 명령줄에서 Windows용 빌드를 할 수 있어요:

cmake --build . --config Release

CMake 옵션 (CMake Options)

어떤 CMake 옵션을 사용할 수 있는지 관심이 있다면 cmake .. -LH를 실행해요.

SMT 솔버 (SMT Solvers)

Solidity는 선택적으로 SMT 솔버, 즉 z3, cvc5, Eldarica를 사용할 수 있어요. 그러나 그 존재는 런타임에만 확인되고, 빌드가 성공하는 데는 필요하지 않아요.

참고 (Note)

emscripten 빌드는 Z3를 요구하고 대신 그것에 정적으로 링크해요.

버전 문자열 상세 (The Version String in Detail)

Solidity 버전 문자열은 네 부분을 포함해요:

  • 버전 번호
  • prerelease 태그, 보통 develop.YYYY.MM.DD, pre.N 또는 nightly.YYYY.MM.DD
  • commit.GITHASH 형식의 커밋
  • 플랫폼 및 컴파일러에 대한 상세를 포함하는 임의 개수의 항목을 가진 플랫폼

로컬 수정이 있으면 커밋이 .mod로 접미사가 붙어요. 이 부분들은 SemVer가 요구하는 대로 결합되는데, Solidity prerelease 태그는 SemVer prerelease와 같고 Solidity 커밋과 플랫폼이 합쳐져 SemVer 빌드 메타데이터를 구성해요.

예:

  • 릴리스: 0.4.8+commit.60cc1668.Emscripten.clang
  • prerelease: 0.4.9-pre.3+commit.fb60450bc.Emscripten.clang
  • nightly 빌드: 0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang

버전 관리에 대한 중요한 정보 (Important Information About Versioning)

릴리스가 만들어진 후 패치 버전 수준이 올라가는데, 오직 패치 수준 변경만 뒤따른다고 가정하기 때문이에요. 변경이 병합되면 버전은 SemVer와 변경의 심각도에 따라 올려야 해요. 마지막으로 릴리스는 항상 현재 빌드의 버전으로 만들어지지만 prerelease 지정자 없이 만들어져요.

예:

  • 0.4.0 릴리스가 만들어짐.
  • 이제 nightly 빌드와 prerelease는 0.4.1 버전을 가짐.
  • 비-브레이킹 변경이 도입됨 → 버전 변경 없음.
  • 브레이킹 변경이 도입됨 → 버전이 0.5.0으로 올라감.
  • 0.5.0 릴리스가 만들어짐.

이 동작은 버전 pragma와 잘 동작해요.

더 알아보기 (Learn more)