What Is a Smart Contract—and Why Its Rules Cannot Be Changed Retroactively?

Disclaimer: This article is for educational purposes only. It is not financial, legal, or investment advice.

A smart contract is often described as a “digital agreement.” That is a useful analogy, but it is not the full picture. More precisely, a smart contract is a program deployed on a blockchain that stores data and executes predefined instructions.

예를 들어 조건이 충족된 뒤에만 전송을 허용하고 참여자를 추적하거나 작업이 성공한 뒤 기록을 업데이트할 수 있습니다. 누군가 트랜잭션을 제출하면 네트워크가 코드를 실행하고 결과를 기록합니다.

처음부터 고려해야 할 두 가지 한계가 있습니다:

‘Smart’라는 말이 프로그램이 생각하거나 의도를 판단할 수 있다는 뜻은 아닙니다.
‘컨트랙트’라는 명칭만으로 코드에 계약의 법적 지위가 자동으로 부여되는 것은 아닙니다.

스마트 컨트랙트는 코드가 허용하는 작업만 수행합니다. 로직에 버그, 안전하지 않은 관리 기능 또는 잘못된 가정이 있어도 블록체인이 자동으로 수정하지 않습니다.

핵심 요점

스마트 컨트랙트는 블록체인 주소에 저장된 코드와 데이터입니다.

네트워크는 사전에 정의된 규칙에 따라 기능을 실행합니다.

확인된 작업은 나중에 임의로 수정할 수 없습니다.

일부 컨트랙트는 조정 가능한 매개변수 또는 업그레이드 가능한 로직으로 설계됩니다.

사용자는 컨트랙트 주소뿐 아니라 역할, 권한 및 업그레이드 메커니즘도 확인해야 합니다.

스마트 컨트랙트를 쉽게 이해하는 방법

자동 보관함을 떠올려 보세요.

규칙에는 "수신자는 지정된 날짜 이후에만 보관함을 열 수 있다"고 적혀 있습니다.
송신자가 자산을 예치합니다.
수신자가 너무 일찍 열려고 하면 기기가 이를 거부합니다.
해당 날짜가 지난 뒤 다른 모든 조건이 충족되면 같은 요청이 성공합니다.

차이점은 스마트 컨트랙트가 한 회사의 서버에서 실행되지 않는다는 것입니다. 블록체인 네트워크가 명령을 처리하고 공동의 결과에 도달한 후 이를 기록합니다.

그렇다고 컨트랙트가 배송 완료 여부, 날씨 또는 적정 환율을 자동으로 아는 것은 아닙니다. 블록체인은 제공된 데이터를 바탕으로 작동합니다. 외부 세계의 정보에는 흔히 오라클이라고 부르는 추가 출처가 필요하며 결과도 해당 출처에 의존합니다.

코드, 상태 및 트랜잭션

스마트 컨트랙트에는 확인해야 할 세 가지 측면이 있습니다:

Code: its available functions and checks.
State: its current data, such as balances, statuses, and configuration values.
Transaction history: the sequence of operations that changed that state.

공개 데이터를 읽는 작업은 일반적으로 상태를 변경하지 않습니다. 토큰 전송이나 참여 등록처럼 상태를 바꾸는 작업에는 트랜잭션이 필요합니다. 사용자가 서명하고 네트워크가 처리하며 보통 수수료가 부과됩니다.

트랜잭션이 블록에 포함되고 최종 확정되면 체인의 기록이 됩니다. 코드가 허용하면 이후 트랜잭션이 현재 상태를 바꿀 수 있지만 이전 기록을 다시 쓰지는 않습니다. 두 이벤트 모두 계속 표시됩니다.

‘소급 변경할 수 없다’는 말의 실제 의미

컨트랙트가 주소 A에서 주소 B로 100 토큰을 전송한 기록을 남겼다고 가정해 보겠습니다. 확정된 후에는 관리자가 해당 블록을 열어 원래 작업이 없었던 것처럼 100 을 10 으로 바꿀 수 없습니다. 이미 확정된 트랜잭션의 수신자를 몰래 변경할 수도 없습니다.

If the code includes a refund, reversal, or compensation function, using it creates a new transaction. The blockchain will show the original action and the later response.

이 때문에 온체인 기록은 독립적인 검증을 지원할 수 있습니다. 서로 다른 관찰자가 네트워크를 조회하고 동일한 사건 순서를 확인할 수 있습니다.

블록체인은 "어떤 상황에서도 절대 변경되지 않는다"고 말하는 것 역시 정확하지 않습니다. 네트워크마다 고유한 완결성 모델이 있으며 프로토콜 장애나 공격에 노출될 수 있습니다. 실질적인 요점은 더 제한적입니다. 정상 작동 중에는 사용자나 앱 관리자가 비공개 데이터베이스의 행처럼 확인된 블록체인 기록을 수정할 수 없습니다.

그렇다면 컨트랙트는 절대 변경되지 않는다는 뜻인가요?

항상 그런 것은 아닙니다. 바로 이 지점에서 "변경 불가능한 컨트랙트"라는 표현을 자주 오해합니다.

1. 업그레이드할 수 없는 컨트랙트

배포된 코드는 원래 로직에 따라 계속 실행됩니다. 개발자는 새 주소에 새 컨트랙트를 배포할 수 있지만 기존 주소와 기록은 남습니다. 사용자는 새 버전으로 의도적으로 전환해야 합니다.

2. 매개변수를 조정할 수 있는 컨트랙트

코드에는 한도 변경, 작업 일시 중지, 허용 목록 관리 또는 수수료 수신자 변경을 위한 관리자 함수가 포함될 수 있습니다. 이러한 함수도 새로운 트랜잭션이 필요하며 코드에 정의된 권한만 행사할 수 있습니다.

과거 기록을 다시 쓰지는 않지만 향후 작업의 규칙을 변경할 수는 있습니다.

3. 업그레이드 가능한 아키텍처

일반적인 설계에서는 프록시 컨트랙트를 사용합니다. 프록시 주소는 그대로 유지되며 호출을 별도의 구현 컨트랙트로 전달합니다. 거버넌스가 그 구현을 변경할 수 있다면 앞으로 프록시 주소의 동작도 달라질 수 있습니다.

이는 ‘주소가 변경되지 않았다’는 사실이 반드시 ‘로직이 한 번도 변경되지 않았다’는 뜻은 아님을 의미합니다. 신중한 검토에서는 다음을 확인합니다:

해당 주소가 프록시인가?
누가 구현을 업그레이드할 수 있나요?
서명 하나로 충분한가, 여러 개가 필요한가?
시간 지연이 있는가?
작업을 일시 중지할 수 있는가?
관리자가 변경할 수 있는 매개변수는 무엇인가요?

예시: 한도 변경

일일 한도가 1,000 단위인 컨트랙트를 가정해 보겠습니다.

월요일에 사용자가 800 단위 작업을 완료합니다.
화요일에 권한 있는 주소가 새 트랜잭션을 통해 한도를 500 단위로 변경합니다.
월요일의 작업이 사라지거나 다른 기록으로 바뀌지는 않습니다.
컨트랙트 로직에 그렇게 지정되어 있다면 화요일부터 500 단위 한도가 적용됩니다.

블록 탐색기는 두 트랜잭션을 모두 보여 줄 수 있습니다. 그 결과를 이해하려면 어떤 함수가 호출되었고 해당 함수에 어떤 권한이 있는지도 알아야 합니다.

블록체인이 입증하는 것과 입증하지 않는 것

공개 블록체인은 다음을 검증하는 데 도움이 됩니다:

참여 주소;
트랜잭션 시간 및 상태;
전송된 자산 및 금액;
데이터가 올바르게 해석된 경우 호출된 함수;
이벤트 및 작업 순서;
배포된 바이트코드와 대조해 검증된 경우의 소스 코드.

Deployment on a blockchain does not by itself guarantee:

버그 또는 취약점의 부재;
정직한 개발자;
경제적 지속 가능성;
정확한 외부 데이터;
관리자 권한의 부재;
법적 보호;
잘못된 전송 후 복구.

투명성은 근거를 확인할 수 있다는 뜻입니다. 보이는 모든 것이 안전하다는 뜻은 아닙니다.

상호작용 전 실용 체크리스트

Verify the address. Obtain it from an official project source and compare it carefully.
Verify the network. The same address format may exist across several EVM networks.
Check source verification. Published source code makes analysis easier, but it is not a security audit.
Look for proxies and upgrades. Identify the implementation and the upgrade authority.
Review administrator powers. Look for owner, admin, pause, upgrade, fee, and access-control functions.
Review token approvals. Before approving, confirm the token, spender, and allowance.
Start small. For a first interaction, consider a small test amount while accounting for fees.

사용자의 서명이 중요한 이유

스마트 컨트랙트가 지갑 전체에 자동으로 접근하는 것은 아닙니다. 특정 호출을 받고 부여된 권한만 사용할 수 있습니다.

서명은 단순 전송보다 더 많은 권한을 부여할 수 있습니다. 토큰 사용 승인, 무제한 허용량 부여, 자산 교환, NFT 전송 또는 복잡한 호출 순서를 실행할 수 있습니다.

지갑이 요청 내용을 명확히 설명하지 못하면 사용자는 "블라인드 서명" 위험에 노출됩니다. 익숙한 채팅에서 받은 링크이거나 공식 사이트와 비슷해 보인다는 이유만으로 트랜잭션을 승인해서는 안 됩니다.

결론

스마트 컨트랙트는 약속이나 공정성에 대한 마법 같은 보장이 아닙니다. 코드로 작성된 규칙을 실행하고 검증 가능한 기록을 남기는 프로그램입니다.

A confirmed operation cannot be quietly edited after the fact. However, future parameters or logic may be changeable if the architecture was designed that way. The most useful question is therefore not only “Is there a smart contract?” but also: “What does its code allow, and who can influence how it works in the future?”

핵심 요점