Solidity 입문 코스 한 방에 끝내기: 실행 흐름부터 컨트랙트 구조, 컴파일러 버전, 실습 로드맵까지
Solidity를 처음 시작할 때 필요한 핵심 뼈대(실행 모델, 컨트랙트 구성 요소, 컴파일러 버전 관리, Remix→Hardhat 실습 흐름, 배포 관점 체크)를 연결해 정리한 입문 필러 글입니다.
Solidity를 처음 배우면 “문법은 따라 치는데, 왜 이렇게 동작하는지”가 잘 안 잡히는 구간이 옵니다.
특히 트랜잭션과 조회(call)의 차이, 상태(state)가 바뀌는 순간, 가스 비용이 생기는 지점을 이해하지 못하면, 그 다음부터는 계속 감으로만 코드를 보게 됩니다.
이 글은 문법을 늘어놓기 위한 글이 아닙니다.
Solidity가 어떤 실행 모델을 가지고 있고(무엇이 언제 실행되는지), 컨트랙트는 어떤 구조로 구성되며, 컴파일러 버전은 왜 중요하고, 실습 환경은 어떤 흐름으로 가져가야 하는지를 한 번에 정리하기 위한 입문 지도입니다.
참고: 이 필러글에서는 세부 문법 글을 따로 운영합니다.
1) Solidity는 “백엔드 언어”가 아니라 “규칙을 체인에 고정하는 언어”입니다
Solidity를 웹 개발 언어처럼 접근하면 초반에 쉽게 헷갈립니다.
Solidity는 요청이 오면 서버가 처리하는 구조가 아니라, 트랜잭션이 들어올 때 규칙을 실행하고 상태(state)를 바꾸는 구조입니다.
따라서 입문 단계에서는 아래 질문이 먼저 정리되어야 합니다.
- 누가 실행할 수 있습니까? (권한/접근 제어)
- 어떤 경우에 상태가 바뀝니까? (트랜잭션 vs 조회)
- 비용(가스)은 어디서 발생합니까? (저장/연산/로그)
문법을 외우는 것보다 “실행 흐름을 그릴 수 있는가”가 훨씬 중요합니다.
2) 실행 흐름을 잡으면 컨트랙트 코드가 갑자기 읽히기 시작합니다
초보자가 가장 많이 하는 오해가 있습니다.
- “함수를 호출하면 그냥 실행된다”
실제로는 트랜잭션으로 호출했는지, 조회(call)로 실행했는지에 따라 결과가 달라집니다.
정리하면 다음과 같습니다.
- 조회(call): 상태 변경 없이 결과만 확인하는 실행입니다.
- 트랜잭션(tx): 상태가 바뀔 수 있고 가스 비용이 발생합니다.
이 감각이 잡히면 view/pure가 왜 필요한지, revert가 왜 중요한지, 이벤트를 왜 찍는지도 자연스럽게 따라옵니다.
실행 흐름 상세는 이 글과 함께 보면 흐름이 깔끔해집니다.
3) 컨트랙트 구조는 “설계의 언어”입니다: 상태, 함수, 권한이 한 덩어리로 움직입니다
Solidity 컨트랙트는 보통 아래 요소로 구성됩니다.
- 상태 변수(state): 컨트랙트가 기억하는 값(온체인 저장)
- 함수(function): 상태를 읽거나 바꾸는 인터페이스
- 이벤트(event): 외부(프론트/백엔드)가 추적하기 쉬운 로그
- 접근 제어(modifier/role): 누가 어떤 행동을 할 수 있는지
- 초기화(constructor/initializer): 배포 시점에 필요한 세팅
입문자에게는 “상태 변수는 곧 비용”이라는 감각이 중요합니다.
무작정 저장하면 가스가 늘고, 반대로 저장을 줄이면 설계가 복잡해집니다. 이 균형이 Solidity의 핵심 난이도입니다.
컨트랙트 구조는 아래 글과 함께 보면 좋습니다.
4) 컴파일러 버전(pragma)은 사소해 보이지만, 협업과 배포에서 가장 많이 사고가 납니다
입문 단계에서는 pragma solidity가 그냥 “버전 적는 줄”로 보이기 쉽습니다.
하지만 실제로는 팀 협업, 라이브러리 호환성, 배포 재현성에 직접 영향을 줍니다.
대표적인 사고 패턴은 이렇습니다.
- 로컬에서는 잘 되는데 CI/배포에서 컴파일 옵션이 달라져 결과가 달라집니다.
- optimizer 설정/버전이 달라 verify가 실패합니다.
- 라이브러리의 지원 버전과 프로젝트 버전이 충돌합니다.
이 단계에서는 “왜 범위를 잡는지”까지 이해하는 것이 좋습니다.
5) 실습은 Remix로 빠르게 시작하고, Hardhat으로 옮겨가면 실력이 “유지되는 형태”가 됩니다
입문자에게 가장 좋은 흐름은 다음과 같습니다.
- Remix에서 컴파일/배포/호출을 한 번에 경험합니다.
- 작게라도 Hardhat 프로젝트를 만들고, 배포/테스트를 코드로 남깁니다.
Remix 실습 가이드는 여기서 이어서 보면 됩니다.
Hardhat 설정은 이 글을 참고하면 됩니다.
Truffle은 레거시 프로젝트에서 마주칠 가능성이 있어, “필수는 아니지만 읽어두면 도움”이 됩니다.
6) 배포는 “올렸다”로 끝나지 않습니다: 운영 관점에서 한 번 더 확인해야 합니다
실무에서 컨트랙트 배포는 이벤트 하나로 끝나지 않습니다. 보통 다음까지 포함됩니다.
- 네트워크/체인ID 확인
- 배포 계정/권한 확인
- 생성자/초기값 확인
- 익스플로러 verify(검증)
- 핵심 함수 호출/이벤트 로그 점검
배포 프로세스 전체 흐름은 아래 글과 연결됩니다.
7) 여기서부터는 “세부 문법”으로 확장하면 됩니다
이 필러글은 입문 코스의 뼈대를 잡는 글입니다.
이후에는 아래 주제들이 자연스럽게 이어집니다.
- 접근 제어(Ownable/Role 기반)와 안전한 권한 설계
- 이벤트 설계와 오프체인 인덱싱 관점
- 저장 구조 최적화(가스 최적화와 트레이드오프)
- 업그레이더블(프록시) 아키텍처 기초