인턴십 계약을 블록체인으로 관리하면?
StajChain이 설계한 대학·학생·기업 간 신뢰의 구조
인턴십 계약은 학생과 기업만의 일이 아니다. 학생이 고용 계약을 작성하면 기업이 확인하고, 학부나 지도교수가 학업 요건과 적합성을 검토한 뒤, 대학의 중앙 인턴십 부서가 최종 활성화하는 식으로 여러 주체가 차례로 참여한다.
그런데 이 과정은 여전히 종이 서류, 수기 서명, 이메일 첨부파일, 수동 확인에 의존하는 경우가 많다. 문서가 여러 곳에 흩어지면 최신본을 찾기 어렵고, 누가 언제 무엇을 승인했는지도 한눈에 확인하기 힘들다. 승인 순서가 뒤섞이거나 서류가 수정·분실되더라도 사후에 경위를 추적하기가 쉽지 않다.
2026년 발표된 졸업 프로젝트 보고서 「StajChain: A Hyperledger Fabric-Based Multi-Party Internship Agreement System」은 이러한 문제를 허가형 블록체인으로 해결하려는 프로토타입을 제안한다. 이 글에서는 논문의 구현 내용을 일반 독자가 이해하기 쉬운 언어로 풀어보고, 이 시스템이 실제로 무엇을 해결하며 어떤 한계를 갖는지 살펴본다.
인턴십 계약의 본질은 ‘파일 저장’이 아니라 ‘다자간 승인’이다
인턴십 계약을 파일 하나로만 보면 핵심 문제가 보이지 않는다. 실제로 중요한 것은 여러 기관이 같은 계약을 검토하고, 각자의 책임에 따라 승인하며, 그 과정을 나중에 검증할 수 있어야 한다는 점이다.
| 참여 주체 | 시스템에서 수행하는 역할 |
| 학생 | 인턴십 계약을 만들고 본인의 내용을 승인한다. |
| 기업 | 인턴십 조건과 학생 수용 여부를 확인한다. |
| 학부·교수진 | 학업 요건과 인턴십의 적합성을 검토한다. |
| 중앙 인턴십 부서 | 최종 승인, 활성화, 완료 처리와 이력 관리를 담당한다. |
기존 방식에서는 각 승인 결과가 이메일, 종이 문서, 별도 행정 시스템에 나뉘어 기록될 수 있다. 이때 “누가 승인했는가”뿐 아니라 “그 승인이 어떤 버전을 대상으로 이루어졌는가”도 확인해야 한다.
StajChain은 계약을 단순한 문서가 아니라 상태가 정해진 순서로 변화하는 디지털 기록으로 다룬다. 예를 들어 학생 승인이 끝나지 않았는데 기업이 먼저 승인하거나, 중앙 부서가 활성화하지 않은 계약을 완료 처리하는 경우를 시스템 규칙으로 막는 방식이다.
핵심은 종이를 블록체인으로 옮기는 데 있지 않다. 여러 참여자가 함께 처리하는 승인 절차를 명확한 규칙과 검증 가능한 이력으로 바꾸는 데 있다.
왜 공개 블록체인이 아니라 Hyperledger Fabric인가
StajChain이 사용하는 블록체인은 누구나 익명으로 참여하는 공개 블록체인과 다르다. 대학 인턴십 시스템에는 신원이 확인된 학생, 등록된 기업, 대학 구성원만 참여해야 하며, 개인정보와 기업 정보 역시 무제한으로 공개되어서는 안 된다.
이런 환경에 적합한 것이 허가형 블록체인(permissioned blockchain)이다. 허가형 블록체인은 참여자의 신원을 확인하고, 역할에 따라 접근 권한을 제한한다. 논문은 이러한 요구사항을 충족하기 위해 Hyperledger Fabric을 선택했다.
Hyperledger Fabric은 기관 간 업무 흐름을 구축할 수 있도록 멤버십 서비스, 거래 승인 정책, 채널, 스마트 계약(chaincode) 등을 제공한다. StajChain에서는 이를 활용해 다음 질문을 거래가 실행될 때마다 확인한다.
| 확인 항목 | 의미 |
| 호출자 | 요청을 보낸 사용자가 누구인가? |
| 역할 | 학생·기업·학부·중앙 부서 중 어떤 권한을 갖는가? |
| 현재 상태 | 계약이 현재 어느 단계에 있는가? |
| 다음 작업 | 지금 요청한 상태 변경이 허용되는가? |
따라서 이 시스템에서 블록체인의 역할은 모든 데이터를 무조건 저장하는 것이 아니다. 여러 기관이 공동으로 신뢰해야 하는 계약의 핵심 상태와 변경 이력을 위변조가 어렵게 기록하는 것이다.
데이터는 블록체인과 일반 데이터베이스에 나누어 저장한다
StajChain 프로토타입은 React 프론트엔드, Node.js·Express 백엔드, SQLite 오프체인 데이터베이스, Hyperledger Fabric 원장으로 구성된다.
| 계층 | 담당 기능 |
| React 프론트엔드 | 사용자 화면과 역할별 업무 기능을 제공한다. |
| Node.js·Express 백엔드 | 인증, 권한 확인, 업무 규칙 검증, 데이터베이스 처리, Fabric 거래 호출을 담당한다. |
| SQLite | 사용자, 기업, 기업 등록 요청, 계약 메타데이터 등 애플리케이션 운영 정보를 저장한다. |
| Hyperledger Fabric | 핵심 계약 기록, 계약 상태, 상태 전이와 이력을 저장한다. |
이러한 분리는 현실적인 설계다. 로그인, 검색, 화면 구성에 필요한 운영 정보까지 모두 블록체인에 기록하면 시스템이 불필요하게 복잡해질 수 있다. 반면 계약의 승인 상태와 변경 이력처럼 여러 기관이 함께 확인해야 하는 정보는 원장에 기록하는 편이 적합하다.
다만 블록체인이 데이터의 진실성까지 자동으로 보장하는 것은 아니다. 누군가 처음부터 잘못된 정보를 입력하면, 그 정보가 위변조되지 않은 상태로 보존될 뿐이다. 논문이 향후 과제로 안전한 문서 저장과 기업 검증 강화를 제시한 이유도 여기에 있다.
스마트 계약은 인턴십 절차의 교통경찰이다
StajChain의 스마트 계약은 단순한 저장 프로그램이 아니다. 계약 변경을 요청한 주체와 현재 계약 상태를 확인하고, 허용된 다음 단계인지 검증한 뒤에만 원장을 갱신한다.
대표적인 계약 흐름은 다음과 같다.
계약 생성 → 학생 승인 → 기업 승인 → 학부 승인 → 중앙 부서 활성화 → 인턴십 완료
승인 과정에서 반려가 발생하면 계약은 정상적인 흐름과 구분되는 상태로 처리된다. 또한 다음과 같은 인턴십 관련 규칙도 검증 대상에 포함된다.
| 검증 영역 | 논문에서 다룬 예시 |
| 학생 요건 | 최소 학점 등 기본 자격 조건 |
| 일정 | 시작일 제약, 근무일 확인, 기간 중복 방지 |
| 기업 | 시스템에 등록되고 승인된 기업인지 확인 |
| 권한 | 각 역할에 맞는 작업인지 확인 |
| 상태 전이 | 현재 상태에서 허용된 다음 단계인지 확인 |
모든 규칙을 한 곳에서 처리하지 않는 점도 특징이다. 백엔드는 최소 학점, 시작일, 기업 등록 여부, 학생 메타데이터처럼 애플리케이션 수준의 조건을 검사한다. 스마트 계약은 호출자 권한, 허용된 상태 전이, 원장 상태의 일관성, 일정 중복 방지와 이력 접근 규칙을 강제한다.
쉽게 말하면 백엔드는 시스템의 입구이고, 스마트 계약은 여러 참여자가 공유하는 최종 기록의 규칙 집행자다.
실험 결과: 읽기는 빠르고, 쓰기는 신중하다
논문은 전체 계약 수명주기, 계약 생성 규칙, 승인과 반려, 기업 등록, 잘못된 입력, 권한 없는 작업, 잘못된 상태 전이를 대상으로 기능 테스트를 수행했다. 정상적인 작업은 성공했고, 허용되지 않은 작업은 예상대로 거부되었다.
성능에서는 읽기와 쓰기의 차이가 뚜렷했다. Fabric 기반 계약 읽기 작업은 124.52~159.53 TPS를 기록했고, P95 지연시간은 100ms 미만이었다. 여기서 P95는 전체 요청 중 95%가 해당 시간 안에 완료되었다는 뜻이다. SQLite 기반 승인 기업 조회는 917.13 TPS, 14.49ms P95 지연시간으로 더 빠르게 측정되었다.
반면 원장에 상태를 기록하는 주요 쓰기 작업은 약 2초의 P95 지연시간을 보였다. Fabric의 쓰기 거래는 데이터베이스의 단순 갱신과 달리 거래 승인, 순서 지정, 검증, 커밋 단계를 거쳐야 하기 때문이다.
| 작업 유형 | 보고된 결과 | 의미 |
| Fabric 계약 읽기 | 124.52~159.53 TPS, P95 100ms 미만 | 계약 상태와 이력 조회에 충분한 응답성 |
| SQLite 승인 기업 조회 | 917.13 TPS, P95 14.49ms | 오프체인 단순 조회가 더 빠름 |
| 주요 Fabric 쓰기 | P95 약 2초 | 원장 합의·검증·커밋에 따른 지연 |
| 기업 승인 | P95 397.99ms | 기업 기록, 계정, Fabric 신원 생성이 함께 수행됨 |
이 결과를 두고 블록체인이 무조건 느리다거나 빠르다고 결론 내리기는 어렵다. StajChain은 고빈도 결제 시스템이나 실시간 게임 서버가 아니라, 한 건의 인턴십 계약을 여러 기관이 검토하고 기록하는 행정 시스템이다. 이 환경에서는 몇 초의 쓰기 지연보다 누가 승인했는지 추적할 수 있고, 잘못된 순서의 승인을 차단할 수 있는지가 더 중요할 수 있다.
StajChain이 해결하는 것과 해결하지 않는 것
StajChain의 가장 큰 가능성은 블록체인 자체보다 책임 있는 업무 흐름을 디지털화했다는 점에 있다. 계약 상태가 명시적으로 관리되고, 역할별 권한이 적용되며, 중요한 변경 이력이 원장에 남으면 사후 감사와 분쟁 확인이 쉬워진다. 여러 기관이 하나의 기록을 바라보면서도 각자의 권한 범위 안에서만 작업할 수 있다는 점도 장점이다.
하지만 블록체인이 만능 해결책은 아니다. 기업이 실제로 존재하는지, 학생이 입력한 정보가 정확한지, 개인정보를 어느 범위까지 보관할지, 전자서명이 법적으로 어떤 효력을 갖는지는 별도의 제도·보안·운영 문제다. 또한 논문의 수치는 특정 프로토타입 환경과 설정에서 측정된 결과이므로, 대규모 다기관 네트워크에 그대로 일반화하기보다는 추가 검증이 필요하다.
논문은 후속 연구 방향으로 실제 여러 조직이 참여하는 분산형 Hyperledger Fabric 네트워크 배포, 안전한 문서 저장, 기업 검증 강화, 승인·반려 알림, 보고서 기능을 제시한다.
결론: 중요한 것은 블록체인 도입보다 신뢰의 설계다
StajChain은 인턴십 계약이라는 익숙한 행정 절차를 블록체인 관점에서 다시 설계한 사례다. 학생·기업·학부·중앙 부서가 각자의 역할을 수행하고, 스마트 계약이 권한과 순서를 확인하며, Hyperledger Fabric이 핵심 상태와 이력을 공유한다.
이 접근의 가치는 종이를 블록체인으로 바꾼 데만 있지 않다. 더 본질적인 변화는 계약을 ‘파일을 주고받는 과정’이 아니라 규칙이 있는 공동 업무 흐름으로 표현했다는 데 있다.
실제 대학 시스템으로 발전하려면 개인정보 보호, 법적 효력, 기관 간 운영 책임, 기업 검증, 사용자 경험을 함께 해결해야 한다. 그럼에도 StajChain은 중요한 질문을 던진다.
여러 조직이 함께 처리하는 문서 업무에서 서로를 완전히 신뢰하기 어렵다면, 신뢰를 이메일과 개인의 기억에만 맡기지 않고 시스템의 규칙과 검증 가능한 이력으로 설계할 수 있지 않을까?
StajChain은 이 질문에 대한 하나의 기술적 답변이다. 인턴십 계약 관리라는 작은 업무에서 출발했지만, 같은 원리는 산학협력 문서, 교육 행정, 자격 검증, 기관 간 승인 업무에도 확장될 수 있다.
