[GenLayer 계약이 통과해야 하는 서로 다른 세 가지 시험]
@GenLayer
Studio에서 PolicyGuard를 만들며 한 번 저장한 정책 기준선을 수정할 수 없도록 설계했습니다.
개발 중 기준선을 다시 잡아야 할 때는 계약을 재배포해야 했고 그 과정에서 함수가 실행되는 것과 예외 상황에서도 올바르게 판단하는 것이 얼마나 다른지 알 수 있었습니다.
GenLayer는 이런 문제를 단계별로 점검할 수 있는 개발 도구를 제공합니다.
첫 번째는 코드 검사입니다.
genvm-lint는 허용되지 않는 Python import, 잘못된 저장소 타입, 비결정적 호출의 위치 같은 GenVM 규칙 위반을 찾아줍니다.
계약이 실행되기 전부터 잡을 수 있는 오류들이죠.
두 번째는 Direct Mode 테스트입니다.
Studio 서버를 띄우지 않고 메모리에서 계약 로직을 검사할 수 있고 웹 응답과 LLM 결과를 모의 데이터로 넣어볼 수도 있습니다.
PolicyGuard 같은 문서 판정 계약이라면 단순한 문구 수정, 기한이 7일에서 3일로 바뀐 경우, 웹페이지 읽기 실패를 각각 다른 테스트로 구성할 수 있습니다.
같은 정책을 다르게 표현한 문장은 변경으로 판단하지 않으면서 짧은 숫자 수정이 실제 권리나 의무를 바꾼다면 이를 구분하는지 확인하는 방식입니다.
세 번째는 통합 테스트입니다.
GenLayer Studio에 연결해 합의 절차를 포함한 트랜잭션 동작을 검사합니다.
Direct Mode에서 함수가 의도대로 작동했더라도 검증자들의 평가와 트랜잭션 상태 변경까지 확인하려면 별도의 테스트가 필요합니다.
GenLayer 프로젝트 보일러플레이트에는 세 단계에 대응하는 실행 명령이 들어 있습니다.
-genvm-lint check contracts/my_contract.py
-pytest tests/direct/ -v
-gltest tests/integration/ -v -s
Claude Code와 Codex에서 사용할 수 있는 GenLayer Skills도 공개돼 있어 이러한 개발, 검증 작업을 AI 코딩 에이전트와 연결할 수 있습니다.
다만 테스트 자동화가 잘못된 판단 기준까지 알아서 찾아주는 것은 아닙니다.
어떤 입력을 넣고 무엇을 실패로 간주할지는 개발자가 정해야 합니다.
Builder 결과물에는 실행 화면뿐 아니라 어떤 입력에서 실패하도록 설계했고 그 실패가 실제로 확인됐는지를 남기는 편이 유용합니다.
특히 웹 데이터와 LLM을 사용하는 Intelligent Contract에서는 코드 문법, 판단 로직, 검증자 합의가 각각 다른 오류를 만들 수 있습니다.
세 종류의 검사가 필요한 이유도 여기에 있습니다.
직접 개발하면서 어려웠던 부분을 다른 Builder들이 더 쉽게 점검할 수 있도록 제가 다음 계약을 만든다면 이 테스트 사례부터 준비하는게 좋다고 생각합니다.
개발 가이드: https://t.co/WcR4GqfFGK
#GenLayer #GenLayerDOKDOPioneer
AI가 똑똑해질수록 계약서는 더 구체적이어야 한다
AI에게 판단을 맡기면 계약 조건을 대충 써도 될까?
오히려 반대일 수 있다.
예를 들어 AI 에이전트에게 상품 설명 번역을 맡겼다고 하자. "자연스럽게 번역해 주세요"라는 조건만 있으면, 결과물이 마음에 들지 않을 때 무엇으로 따질까?
제품명은 유지했는가
숫자와 단위는 정확한가
금지 표현을 사용하지 않았는가
이런 기준이 있어야 판단도 검증할 수 있다.
@GenLayer 의 Intelligent Contracts는 자연어와 웹 정보를 활용할 수 있다. 이때 중요한 장치가 계약
![[GenLayer 계약이 통과해야 하는 서로 다른 세 가지 시험] 대표 이미지](/api/thumb?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHVs1onJbMAAxQKB.jpg&w=640&s=7e9gPFjdgwOAdlWU1FDVfT5b)