블록체인 API 개발자금 2차 공고, 매칭펀드 계산 전에 확인할 세 가지

페이지 정보
profile_image
작성자 최고관리자
댓글 0건 조회 5회 작성일
본문

과학기술정보통신부와 한국인터넷진흥원은 2026년 7월 22일 블록체인 응용서비스(API) 개발 자금 지원사업 2차 모집 공고를 게시했습니다. 신청기업은 공식 페이지에 첨부된 공고문·공모안내서·공모서식·민간부담금 계산파일을 모두 확인해야 하며, 1차 모집의 금액이나 조건을 2차에 그대로 적용해 작성해서는 안 됩니다. 이 사업의 핵심은 블록체인 기술 자체를 개발하는 설명보다 국내외 수요기업의 실제 서비스에 연결할 API와 검증 가능한 활용 시나리오를 제시하는 데 있습니다.

 

공식 공고는 국내 블록체인 기술이 국내외 수요기업 서비스에 활용되도록 응용서비스 API 개발을 지원하는 목적을 밝히고 있습니다. 게시 페이지에는 별도 매칭펀드 민간부담금 계산파일도 제공됩니다. 이는 정부지원금만으로 전 비용을 충당한다고 가정하기보다 기업 규모와 부담방식, 현금·현물 인정 범위를 공고문 기준으로 계산해야 한다는 뜻입니다.

 

4e66b0e7015124c8905e5235d5b2d7a6_1786596760_5313.webp

 

첫째, 기술 보유기업과 수요기업의 역할을 분리한다

 

사업계획서에서 블록체인 기업은 API를 개발하고 운영할 기술역량을 보여줘야 합니다. 수요기업은 API가 연결될 실제 서비스, 이용자, 업무 흐름과 도입 필요성을 설명해야 합니다. 수요처 이름만 넣고 담당부서나 연계범위가 정해지지 않았다면 실증 가능성이 낮게 보일 수 있습니다.

 
참여 주체반드시 정할 내용확인 자료
개발기업API 기능·보안·운영 책임기술구성도·인력경력
수요기업적용 업무와 이용자도입의향·업무흐름
공동 참여기관데이터·인프라 제공 범위역할분담·협약자료
외부 서비스연계 규격과 비용이용약관·견적·기술문서
 

컨소시엄이 필요하다고 판단되면 제안서 작성 전에 데이터 제공, 개발 결과물 소유, 장애 대응, 사업 종료 후 운영비를 협의해야 합니다. 선정 뒤 처음 논의하면 일정과 예산이 크게 달라질 수 있습니다.

 

둘째, API가 해결할 문제를 거래 단위로 설명한다

 

‘블록체인으로 신뢰를 높인다’는 문장은 너무 넓습니다. 어떤 데이터가 생성되고 누가 검증하며 어느 시점에 위·변조 위험이 발생하는지 보여줘야 합니다. 예를 들어 자격 증명, 유통이력, 계약·정산, 데이터 동의처럼 기록의 출처와 변경 이력이 중요한 업무를 선택하고 기존 시스템의 문제와 연결합니다.

 

API 사양에는 요청·응답 데이터, 인증방식, 처리속도, 오류코드, 개인정보 포함 여부, 호출량과 장애복구 기준을 넣어야 합니다. 블록체인 원장에 모든 원문을 저장하기보다 해시값과 필요한 검증정보만 기록하는 구조가 적절한지 검토하고, 삭제·정정 요구가 생길 수 있는 개인정보는 별도 설계를 해야 합니다.

 

셋째, 매칭펀드를 총액이 아니라 항목별로 계산한다

 

공식 페이지가 민간부담금 계산파일을 별도로 제공하는 만큼 기업은 자부담을 마지막에 임의로 맞추지 않아야 합니다. 정부지원 비율, 기업 유형별 부담, 현금과 현물 인정기준, 부가가치세 처리, 인건비와 외주비 제한을 공모안내서에서 확인해야 합니다. 정확한 2차 지원금액과 부담률은 첨부 공고문을 기준으로 입력해야 하며, 1차 사업 소개의 수치를 복사하면 안 됩니다.

 

예산은 개발기능과 직접 연결해야 합니다. API 설계, 개발, 보안점검, 수요처 연동, 시험, 클라우드 운영, 사용자 검증과 사업화 활동이 일정표와 맞는지 봅니다. 이미 개발이 끝난 기능의 비용을 새 개발비처럼 넣거나 관계없는 장비를 포함하면 설명이 어려워질 수 있습니다.

 

실증 성공 기준은 이용자 수만으로 정하지 않는다

 

실증서비스는 가입자나 호출 건수 외에도 정확도, 처리시간, 장애율, 비용절감, 업무시간 단축 같은 지표가 필요합니다. 초기 이용자가 적은 B2B 서비스라면 거래 한 건의 검증시간과 수작업 감소를 측정하는 편이 더 적절할 수 있습니다. 목표치는 희망 숫자가 아니라 기존 시스템의 기준값과 시험환경을 근거로 설정해야 합니다.

 

보안과 운영지표도 포함해야 합니다.

 

• API 인증키 발급과 폐기 절차

 

4e66b0e7015124c8905e5235d5b2d7a6_1786596761_0259.webp

 

• 비정상 호출과 재전송 통제

 

• 개인정보와 영업비밀의 원장 기록 여부

 

• 노드 장애 때 서비스 지속 방식

 

• 수요기업 시스템 변경 시 버전관리

 

• 사업 종료 뒤 유지보수 책임과 비용

 

접수 파일은 네 종류를 함께 읽는다

 

공고문은 자격과 지원조건, 공모안내서는 평가와 집행 세부사항, 공모서식은 실제 작성항목, 계산파일은 민간부담금 구조를 확인하는 역할을 합니다. 한 파일만 보고 작성하면 같은 용어를 다르게 해석하거나 필수 첨부를 놓칠 수 있습니다. 공식 전자접수 시스템의 마감시각과 제출완료 상태도 별도로 확인해야 합니다.

 

관련 Q&A

 

블록체인을 쓰는 아이디어만 있어도 신청할 수 있나요?

 

공식 목적은 블록체인 기술을 수요기업 서비스에 활용하는 API 개발입니다. 단순 아이디어 단계가 자격을 충족하는지는 2차 공고문에 적힌 신청대상과 기술보유 요건을 확인해야 합니다. 최소한 구현할 API, 수요처, 데이터와 실증계획을 설명할 수 있어야 사업 수행 가능성을 보여줄 수 있습니다.

 

민간부담금을 투자금으로 나중에 마련해도 되나요?

 

부담금 납부 시기와 인정방식은 협약·사업비 관리기준을 따라야 합니다. 선정 후 투자유치가 될 것이라는 예상만으로 현재 조달능력을 증명할 수 있는지는 공고문을 확인해야 합니다. 현금 부담이 필요한 경우 자금계획을 미리 세우고, 현물 인건비도 실제 참여인력과 증빙 가능한 범위로 계산해야 합니다.

 

2차 모집은 이전 차수의 문서를 고쳐 내는 작업이 아닙니다. 수요기업의 실제 업무와 API 사양, 매칭펀드, 실증지표를 하나의 실행계획으로 연결한 뒤 공식 첨부문서 기준으로 제출해야 합니다.

 
 
#블록체인API #개발자금지원 #KISA #매칭펀드 #스타트업지원
 


댓글목록

등록된 댓글이 없습니다.