솔리디티 코스 #3: pragma와 컴파일러 버전 전략

독자는 이 글을 통해 pragma solidity로 컴파일러 범위를 안전하게 지정하는 법을 빠르게 이해하고, 프로젝트에서 발생할 수 있는 버전 호환 이슈를 예측 가능하게 관리하는 방법을 얻게 됩니다.

버전 선언의 목적

• pragma solidity는 컴파일러 버전 호환 범위를 명시해 코드 동작을 예측 가능하게 합니다.
• 언어 기능·내장 보안이 버전에 따라 달라져 의도치 않은 동작을 방지합니다.
• 팀/CI 환경에서 일관된 빌드 재현성을 보장합니다.

핵심: “코드는 읽는 시점의 컴파일러에서도 동일하게 컴파일돼야 한다.”

형식과 예시

• 기본 문법:

pragma solidity [버전 범위];

특정 버전 이상

pragma solidity >=0.8.0;

• 0.8.0 이상에서만 컴파일.
• 상위 메이저로 올라가면 언어 변경에 노출될 수 있음.

특정 범위 지정

pragma solidity >=0.8.0 <0.9.0;

• 0.8.x에서만 컴파일(안정성 + 최신 패치 활용).
• 팀 협업/오픈소스 라이브러리에 널리 쓰이는 균형형 전략.

고정 버전(핀 고정)

pragma solidity 0.8.10;

• 정확히 해당 버전에서만 컴파일.
• 보안 감사·규제 요건·장기 LTS 빌드에 유리하나 업데이트 수고가 큼.

모범 사례와 전략

• 최신 안정화 0.8.x 범위 고정
  >=0.8.20 <0.9.0처럼 패치 라인 안에서 최신 기능과 패치를 누립니다.
• 감사/메인넷 배포 전 고정
  릴리스 태그 시점에는 0.8.24처럼 정확 버전 핀 고정으로 재현성 확보.
• CI에서 컴파일러 잠금
  foundry.toml 또는 hardhat.config.ts의 solc 버전을 pragma와 일치시켜 이중 가드.
• 보안 변화 인지
  0.8.x의 기본 산술 검사처럼 언어 레벨 보안 변화를 릴리스 노트로 추적.

팁: 라이브러리 업데이트 주기가 빠르다면 >=0.8.20 <0.9.0 + 정기 리그레션 테스트가 실무 효율이 좋습니다.

자주 하는 실수

버전 선언 누락

// X 비권장: 컴파일러에 따라 예상치 못한 동작
contract NoVersion {
    uint256 public value;
}

• 도구가 최신 컴파일러를 선택하며, 코드 의미가 바뀔 수 있습니다.

지나치게 오래된 범위

pragma solidity ^0.6.0; // X 현대 도구/라이브러리와 충돌 소지

• 최신 보안 패치/기능을 놓치고, 감사 기준과도 어긋납니다.

캐럿(^) 오해

pragma solidity ^0.8.19;

• 캐럿은 0.9.0 미만까지 허용합니다. 팀이 모르면 상위 패치에서 의도치 않은 변경에 노출될 수 있습니다.

선택 가이드(요약 표)

시나리오	권장 선언	장점	주의점
학습/프로토타입	>=0.8.20 <0.9.0	최신 패치 활용	상위 패치 변화는 CI로 검증
생산/감사 직전	0.8.24	재현성 극대화	보안 패치 반영에 추가 작업
라이브러리 배포	>=0.8.20 <0.9.0	호환성+채택성	breaking 변화 모니터링 필수

주의: 범위를 넓게 잡을수록 릴리스 노트/체인별 컴파일러 버전 지원을 상시 점검해야 합니다.

실무 체크리스트

1. pragma solidity를 파일 최상단에 선언한다.
2. 팀 합의된 범위를 정하고 도구 설정과 일치시킨다(Hardhat/Foundry).
3. 새 패치 릴리스 시 리그레션 테스트를 자동화한다.
4. 배포 태그 기준으로 정확 버전 고정을 남긴다.
5. 주요 보안 변화(산술 검사, ABI 변경 등)를 릴리스 노트로 공유한다.

내부 학습을 이어가려면 솔리디티 코스 #2: 컨트랙트 구조·구성요소 을 먼저 읽어 기초 구성을 확인하세요.