Week 5: 스마트 계약 기초 - 자주 묻는 질문

Solidity가 가장 대표적이지만, 유일한 언어는 아닙니다. 다른 선택지도 있습니다:

• Vyper: Python과 유사한 문법, 보안에 초점
• Rust: Solana, Near Protocol 등에서 사용
• Move: Aptos, Sui에서 사용하는 새로운 언어

하지만 이더리움 생태계가 가장 크고, 대부분의 DeFi 프로토콜이 Solidity로 작성되어 있으므로 Solidity를 먼저 배우는 것이 효율적입니다.

Solidity는 JavaScript, C++, Python의 영향을 받았습니다. 특히 JavaScript나 C 계열 언어 경험이 있으면 문법이 익숙할 것입니다. 프로그래밍 경험이 전혀 없다면 JavaScript를 먼저 간단히 학습하는 것을 권장합니다.

^0.8.19는 "0.8.19 이상, 0.9.0 미만"의 컴파일러 버전을 사용하겠다는 의미입니다.

• ^ 기호: 마이너 버전까지 호환
• >=0.8.0 <0.9.0: 범위 지정도 가능
• 0.8.19: 정확한 버전만 사용

0.8.x 버전부터 오버플로우/언더플로우 자동 검사가 포함되므로 0.8.0 이상을 사용하는 것이 안전합니다.

uint는 uint256의 축약형으로, 둘은 동일합니다. 256비트 부호 없는 정수로, 0부터 2^256 - 1까지 표현 가능합니다. 명시성을 위해 uint256으로 작성하는 것이 권장됩니다.

가스 최적화가 필요한 경우 uint8, uint128 등 더 작은 타입을 사용할 수 있지만, EVM은 내부적으로 256비트 단위로 연산하므로 단독 변수에서는 큰 차이가 없습니다.

데이터 저장 위치에 대한 키워드입니다:

• storage: 블록체인에 영구 저장. 상태 변수의 기본 위치. 가스비가 매우 높음
• memory: 함수 실행 중에만 존재하는 임시 저장소. 함수 종료 시 삭제됨
• calldata: external 함수의 매개변수에 사용. 읽기 전용이며 가스비가 가장 저렴

참조 타입(string, array, struct)을 함수 매개변수로 사용할 때 반드시 위치를 명시해야 합니다.

트랜잭션을 실행하는 사람(msg.sender)이 가스비를 부담합니다. 가스비는 이더(ETH)로 지불되며, 실행에 필요한 연산량에 비례합니다.

• 가스 가격(Gas Price): 사용자가 설정, 높을수록 빠르게 처리
• 가스 한도(Gas Limit): 최대 사용 가스량
• 실제 비용 = 사용된 가스 x 가스 가격

view/pure 함수는 블록체인 상태를 변경하지 않으므로 가스비가 발생하지 않습니다. 단, 다른 계약 내부에서 호출되면 가스가 소모됩니다.

"Out of gas" 에러가 발생하며 트랜잭션이 실패합니다. 이때 상태 변경은 모두 롤백되지만, 사용된 가스비는 환불되지 않습니다. 이것이 가스 한도를 적절히 설정하는 것이 중요한 이유입니다.

require가 실패하면 트랜잭션이 취소(revert)되고, 남은 가스는 환불됩니다. 하지만 실패 지점까지 소모된 가스는 환불되지 않습니다. Solidity 0.8.x부터는 에러 메시지와 함께 커스텀 에러(custom errors)를 사용하면 가스를 더 절약할 수 있습니다.

스마트 계약은 "계약"이라는 이름이 붙어 있지만, 법적 계약과는 다릅니다. 코드로 작성된 자동 실행 프로그램입니다. 법적 효력은 국가와 관할권에 따라 다르며, 현재 대부분의 국가에서는 스마트 계약 자체를 법적 계약으로 인정하지 않습니다. 다만 법적 계약의 이행을 자동화하는 도구로 활용할 수 있습니다.

원칙적으로 블록체인에 배포된 코드는 수정할 수 없습니다. 이것이 "불변성"입니다. 하지만 우회 방법이 있습니다:

• 프록시 패턴: 로직 계약을 분리하여 교체 가능하게 설계
• 마이그레이션: 새 계약을 배포하고 데이터를 이전
• 셀프 디스트럭트: 계약을 파괴 (0.8.x 이후 deprecated)

WIA-FIN-007에서는 업그레이드 가능한 프록시 패턴을 권장합니다.

EVM(Ethereum Virtual Machine)은 스마트 계약을 실행하는 가상 컴퓨터입니다. Solidity 코드는 컴파일되어 바이트코드로 변환되고, 이 바이트코드가 EVM에서 실행됩니다. 네트워크의 모든 노드가 동일한 EVM을 실행하므로 동일한 결과가 보장됩니다. Java의 JVM과 비슷한 개념이라고 생각하면 됩니다.

아닙니다! 이것은 매우 중요한 개념입니다. private은 다른 계약에서 코드를 통해 접근하는 것만 막습니다. 블록체인의 모든 데이터는 공개되어 있으므로, 누구나 노드를 통해 스토리지 슬롯을 직접 읽을 수 있습니다. 비밀번호나 개인키 같은 민감한 정보는 절대 스마트 계약에 평문으로 저장하면 안 됩니다.

금융 스마트 계약은 실제 자산을 다루기 때문에 높은 수준의 보안과 신뢰성이 요구됩니다. WIA-FIN-007은 다음을 제공합니다:

• 보안 취약점 예방을 위한 설계 가이드라인
• 감사 가능성 확보를 위한 이벤트 로깅 표준
• 접근 제어 및 권한 관리 패턴
• 규제 준수(KYC/AML)를 위한 프레임워크
• 업그레이드 및 유지보수 전략

ERC(Ethereum Request for Comment)는 이더리움 커뮤니티의 기술 표준(ERC-20, ERC-721 등)이고, WIA-FIN-007은 금융 분야에 특화된 상위 수준의 설계 및 규제 준수 가이드라인입니다. 두 표준은 상호 보완적이며, WIA-FIN-007을 준수하는 계약이 ERC 표준도 함께 구현하는 것이 일반적입니다.

글로벌 금융 기관과 핀테크 기업들이 WIA 표준군을 참조하여 블록체인 기반 금융 서비스를 구축하고 있습니다. 특히 CBDC(중앙은행 디지털 화폐), STO(증권형 토큰), DeFi 프로토콜에서 WIA-FIN 시리즈 표준이 활용되고 있습니다. 한국에서도 금융위원회의 가이드라인과 함께 참조되고 있습니다.

여러 도구가 있습니다:

• Hardhat: Node.js 기반, 테스트/디버깅에 강력 (실무 표준)
• Foundry: Rust 기반, 매우 빠른 컴파일/테스트
• Truffle: 오래된 프레임워크 (현재는 Hardhat이 더 인기)
• Brownie: Python 기반 개발 환경

이번 과정에서는 Remix로 시작하고, 심화 단계에서 Hardhat을 다룰 예정입니다.