Developer Summit 2026 Summer(데브사미 2026 여름)의 2일차인 2026년 7월 17일에 참가하여, 3개의 세션을 청강했습니다. 지난 1일차 리포트에서는 '확률적인 생성을 결정론으로 받아들인다', '인간에게 판단을 남긴다', '컨텍스트(Context)가 성패를 가른다'라는 공통 테마가 떠올랐으나, 2일차는 그 연장선상에서 다른 각도로 깊이 파고드는 하루가 되었습니다.

이 기사에서는 청강한 3개 세션——지식 그래프(Knowledge Graph)로 AI 에이전트를 '팀메이트'로 만드는 이야기(DevRev), 도메인 전문가 × PdM이 고객의 목소리 '너머'를 보는 이야기(Works Human Intelligence), Verifiable Credentials에 산학 협력으로 도전하는 이야기(Itochu Techno-Solutions × Keio University)——를 강연의 흐름에 따라 가능한 한 상세하게 정리합니다. 테마는 AI 에이전트, 프로덕트 매니지먼트(Product Management), 디지털 아이덴티티(Digital Identity)로 제각각인 것처럼 보이지만, 끝나고 보니 '기억', '본질', '신뢰'라는 단어로 깔끔하게 연결되어 있었습니다. 마지막 '공통 테마'까지 읽어주시면, 1일차와 합쳐 2026년 여름의 현재 위치를 입체적으로 파악하실 수 있을 것입니다.

💡 본 기사는 필자 개인의 청강 메모에 기반한 리포트입니다. 강연의 모든 내용을 망라하거나 정확하게 재현하는 것이 아니며, 강연 중의 수치는 슬라이드 메모를 바탕으로 하였기에 독자적인 검증은 수행하지 않았습니다. 모든 책임은 필자에게 있습니다.

청강한 세션의 타임테이블입니다.

먼저 2일차의 개요를 말씀드리자면, 'AI에게 전달해야 할 것은 똑똑한 모델이 아니라 기억', '인간의 일은 목소리 너머에 있는 본질을 꿰뚫어 보는 것', '신뢰는 정신론이 아니라 구현할 수 있는 것'이라는 3가지 기둥이었습니다. 순서대로 살펴보겠습니다.

(스즈키 타카노리 씨 / DevRev Japan)

자칭 '지식 그래프(Knowledge Graph) 아저씨'인 스즈키 씨에 의한 세션입니다. Zenn Book 『LLM을 더 똑똑하게 만드는 지식 그래프 실전 입문』의 저자이자, 모두가 Claude Code를 사용하여 함께 개발하는 경험을 만드는 OSS인 'cc-room'의 개발자이기도 합니다. DevRev는 개발(Dev)과 고객(Rev)을 하나의 지식 그래프로 잇는 AI 플랫폼으로, 2020년 미국 팔로알토에서 창업(Nutanix 공동 창업자가 설립)하였으며, 직원 750명·전 세계 8개 거점, 2025년 9월 일본 법인 설립, 특허 30건 이상을 보유한 회사입니다.

테마의 한 문장이 강렬했습니다. "RAG를 도입하고 데모에서는 완벽하게 작동했다. 그럼에도 실전에서 AI는 자신 있게 틀린다". 많은 팀이 직면하는 이 과제를 한 단계 더 깊은 곳에서 재정의한다는 구성입니다.

강연은 데모 시나리오(가상의 SaaS 기업에 대한 문의)로 시작됩니다. "TKT-421: 로그인할 수 없습니다. 아침부터 전 직원이 접속하지 못하고 있습니다. 긴급히 부탁드립니다"——에텍 제작소로부터 온 긴급 티켓입니다. AI 에이전트에게 "원인과 영향 범위를 조사해줘"라고 요청하면, MCP를 통해 4개의 도구를 직렬로 호출합니다.

이 도표의 포인트는 개별 도구 호출은 전부 '성공'했음에도 불구하고 답이 틀린다는 점입니다. 검색은 '현재 있는 것'만을 반환합니다(진짜 원인은 아직 아무도 기입하지 않음). 시스템 간에 공통 키가 없습니다(유사도로 '아마 이쪽일 것'이라고 추측할 수밖에 없음). 유사도만으로는 '현행 버전'을 선택할 수 없습니다. 이는 모델의 성능 문제가 아니라, 빠른 모델이든 똑똑한 모델이든 해결할 수 없는 문제입니다. AI에게 전달하고 있는 '기억'의 문제라는 것이 첫 번째 주장입니다.

또 하나 중요한 정리는 '읽기'와 '액션(Action)'의 비대칭성입니다. 질문하여 답변을 받는 '읽기'는 정밀도가 낮더라도 대화를 통해 보완할 수 있지만, 데이터를 수정하거나 전송하는 '액션'은 한 번 실행하면 되돌릴 수 없습니다(타 회사로 장애 정보를 오전송하거나, 고객 DB를 덮어쓰기하여 파괴하는 등 실행된 시점에서 사고입니다). 따라서 AI에게는 초안 작성까지만 맡길 수 있으며, 최종 액션은 반드시 인간이 확인해야 합니다. 결과적으로 AI가 아무리 빨라도 인간이 병목(Bottleneck)이 됩니다. 실전에서 전력이 되지 못하는 이유는 "안심하고 맡길 수 없기 때문"이라는 진단이었습니다.

동일한 문의를 사내에서 상황을 가장 잘 파악하고 있는 서포트 매니저(전 개발부 인증 시스템 담당)에게 물으면, 10초 만에 이렇게 대답할 수 있습니다. "인증 관련 로그인 장애입니다. 지난주 장애는 로그인 유효 기간 설정 오류로 해결되었으므로 이번에는 별개의 원인입니다. 개발부의 나카무라 씨에게 조사를 요청하세요. 에이텍 제작소는 계약 갱신이 임박했으니 영업부에도 공유해 주세요".

이 사람의 머릿속에 있는 것은 점과 점의 연결입니다. TKT-421—에이텍 제작소—9,000만 엔 규모의 상담—담당 영업. TKT-421—로그인 기능—ISS-9(지난주 종료·별개 원인)—ISS-12(이번 실제 원인)—매뉴얼 v2(현재 공개 버전). 선을 따라가면 추측이었던 판단이 근거를 가지고 확정됩니다(별도 회사로 확정, 지난주 ISS-9는 시계열상 무관, 이번에는 새로운 Issue 필요, 현재 매뉴얼은 v2, 9,000만 엔 규모의 상담이 연결되므로 영업에 연락……). 파편화되어 있던 점들이 선으로 연결되는 순간, AI는 추측이 아니라 '추적하여' 답할 수 있습니다. 지식 그래프 (Knowledge Graph)란, 이러한 '숙련된 사람의 머릿속'을 미리 정의된 관계(온톨로지 (Ontology))에 따라 AI에게 전달할 수 있는 형태로 만든 계층이며, 개발 티켓(Development Ticket)·고객 지원(Customer Support)·제품 피드백(Product Feedback)의 세 가지를 통합하는 것이라는 정의입니다.

지식 그래프의 효능은 세 가지 핵심 요소로 정리되었습니다.

핵심 ① 관계: 연결을 추적하면 영향 범위까지 한 번에 파악할 수 있습니다. graph.traverse(start="TKT-421", depth=3)

단 한 번의 쿼리(41ms)로 원인(ISS-12, 영구 수정 v2.4.2를 7/8 출시 예정), 영향 고객 3개사(데이터 통합 완료), 중단된 9,000만 엔 규모의 상담, 대응 절차(매뉴얼 v2, 먼저 인증 서버 재시작 필요)까지 취득합니다. "추측에서 멈출 것인가, 근거를 가지고 답할 것인가" -
핵심 ② 시계열: "그 시점"만을 보지 못하는 AI는 할 수 없는 판단을 할 수 있습니다. timeline(node="로그인 기능", window="30d")

을 통해, 6/25 ISS-9 수정 종료 → 6/29 22:00 v2.4 출시 → 6/30 09:15 인증 에러 급증 → 6/30 10:20 ISS-12 기안 → 7/7 수정 80%라는 전후 관계가 보입니다. "비슷하지만 별개의 원인"이라는 판단은 전후 관계를 알고 있기 때문에 가능합니다 -
핵심 ③ 권한: 누가 묻느냐에 따라 답이 달라집니다. 똑같은 "TKT-421의 상황을 알려줘"라도, 영업부에는 9,000만 엔 규모의 상담 중단 중·7/8 수정 예정·고객 공유 권장(기술적 상세 내용은 요약만)을, 서포트부에는 원인 ISS-12·대응 절차 v2(상담 금액은 포함되지 않음)를 전달합니다. 권한 외의 데이터는 애초에 답변에 포함되지 않으므로, 누구라도 안심하고 사용할 수 있습니다.

이를 시스템화한 것이 4계층 아키텍처 (4-layer Architecture)입니다.

이 도표의 포인트는 LLM 아래에 '기억' 계층이 명시적으로 끼어 있다는 점입니다. 핵심 문구는 "LLM에게 검색하게 하지 마라. 기억이 먼저이고, LLM은 판단만 한다."였습니다.

만약 처음부터 기억을 가진 에이전트 (Agent)가 있었다면 어땠을까 하는 '그날 아침의 리플레이'도 구체적이었습니다. ① 9:02 장애 발생과 동시에 에이전트 기동, 과거 Issue와의 시계열 비교를 통해 "별개 사건일 가능성이 높음"이라고 판정 → ② 배포 이력(Deployment History) × 로그 상관관계로 원인이 된 릴리스를 특정 → ③ v2.4에는 보안 수정(세션 고정 공격 대응)이 포함되어 있어 롤백(Rollback)이 불가능하며 전방 수정이 필요하다는 '움직일 수 없는 판단'을 이유와 함께 기록 → ④ ISS-12 자동 기안·담당자 할당·Slack 채널 자동 생성 (인간의 판단 = 이 방침으로 진행할지 여부, 승인 ①) → ⑤ affects 링크를 통해 영향받는 3개사를 특정하여 영업 및 SE에 자동 통지, 고객 대상 1차 답변 초안 생성 (인간의 판단 = 고객에게 보내기 전 최종 확인, 승인 ②) → ⑥ 수정 배포를 감지하여 자동 종료, Jira/Zendesk/Salesforce 교차 업데이트, 영업부에 "상담 재개 가능" 신호 전달.

인간이 한 일은 승인 2회뿐입니다. 일주일 후에 "지난주 로그인 장애 어떻게 됐어?"라고 물으면 그래프를 추적하여 경위를 답해주고, 장애 중에 원인과 수정 예정 사항을 사전에 공유했기에 큰 클레임으로 이어지지 않았으며, 동일한 로그인 기능을 사용하는 다른 2개사로부터 문의가 오기 전에 설명할 수 있었고, 중단되었던 9,000만 엔 규모의 상담은 수정 완료 연락과 함께 재개되었습니다——"관계를 이해한 AI는, 질문받기 전에 움직일 수 있다".

나아가 「데이터의 복리 (Data Compounding)」라는 개념도 소개되었습니다. 이번에 인간이 내린 판단(전방 수정으로 진행)이 기억이 되어, 3개월 후 유사한 장애가 발생했을 때 에이전트가 "이전의 판단 이유는 이것입니다. 이번에는 어떻게 할까요?"라고 제시해 옵니다. 머지않아 누군가의 실수를 다른 사람이 반복하지 않게 됩니다. 기억이 있으면 툴 간의 "어긋남"("PR은 QA까지 진행되었는데 Jira만 업데이트되지 않은 상태" 등)도 감지하여 자동 동기화할 수 있습니다. "memory.md는 자신의 경험에서만 배운다. 조직의 기억은 모두의 경험으로부터 배운다."라는 문장은, Claude Code의 메모리 기능을 사용하고 있는 입장에서 매우 가슴에 와닿는 것이 있었습니다.

뒷받침하는 숫자도 풍부했습니다.

그리고 결정타는 "모델을 최신으로 업데이트해도 +1pt, 올바른 기억을 전달하면 +18pt. 병목(Bottleneck)은 모델이 아니라 기억이다."였습니다. 1일차 쿠로다 씨의 "성패를 가른 것은 모델의 성능이 아니라 컨텍스트의 구조였다"라는 말과 독립적으로 완벽하게 일치하는 결론이었습니다.

마지막은 제품에 대한 이야기도 솔직했습니다. 지식 그래프(Knowledge Graph) · 시계열 · 권한 필터와 같은 기본 구조는 OSS(Open Source Software)로도 구축할 수 있다고 명시한 뒤, 제품으로서의 차별점은 4건의 특허(이종 시스템의 이벤트 통합·자동 상관 / 변경의 인텔리전트 알림 / 3층 스케일러블 벡터 DB / LLM + 라이브 컨텍스트 기반 응답 생성)와, 200명 이상의 엔지니어가 2년 이상 · 1.5억 달러 이상을 들여 만들어 온 "마지막 2%의 디테일"("지루한 2%"라고 표현됨; 4개 시스템의 복합 매칭을 통한 자동 명칭 통합, 프리빌트 온톨로지(Pre-built Ontology), 검색과 SQL을 빠짐없이 제어하는 전체 엔진으로의 권한 주입)이라고 설명했습니다. 소규모 팀이나 단일 툴로 완결되는 범위라면 직접 만드는 것이 더 빠를 수도 있으며, 자체 구축과 제품 도입은 요구사항에 따라 다르다는 공정한 마무리였습니다. 요약하는 문장은 "AI 에이전트는 팀메이트가 될 수 있다. 조건은 관계 · 시계열 · 권한이라는 '기억'을 전달하는 것. Work Softer."였습니다.

(스기타 세이라쿠 씨 · 나가이 히로아키 씨 / Works Human Intelligence)

통합 인사 시스템 「COMPANY」를 다루는 Works Human Intelligence (WHI)에서 도메인 전문가(Domain Expert)와 PdM(Product Manager) 2명이 등단한 세션입니다. 나가이 씨는 2015년 WHI의 전신 회사에 입사한 후, DevOps 조직에서의 제품 개발, 도입 컨설턴트 · 도입 방법론 기획 · 유지보수 컨설턴트 등의 고객 대응 부문을 거쳐, 2022년에 제품 및 업무 도메인 전문가로서 제품 개발 부문으로 재합류(re-join)하였고, 2026년부터 COMPANY Web Service의 Domain Expert로서 정식으로 종사하고 있습니다. 금융(정부계 금융기관 · 지방은행), 제조·건설(자동차 · 식품 · 종합 공조 설비 제조사), 생활협동조합 등을 담당해 왔다고 합니다. 스기타 씨 또한 2015년 입사하여 개발 프로세스 거버넌스 구축 · QE(Quality Engineering) → 개발 사이클 전체 → 공통 기능 개발 책임자 → 2026년부터 PdM이라는 경력을 가지고 있습니다. 두 분 모두 "하나의 제품을 축으로 다양한 직종을 경험해 온 것"이 현재 역할의 토대가 되고 있습니다.

전제가 되는 「COMPANY」의 규모가 우선 압도적입니다. 약 1,200개 법인 그룹이 이용하고, 약 570만 명의 인사 데이터를 관리하며, 소스 코드는 수천만 행 규모입니다. ERP 시장 및 인사/급여 업무 분야에서 점유율 No.1(ITR 조사)로, 1996년 탄생 이래 인사 업무의 전 영역을 하나의 소스(1 Source)로 커버하며, 개별 기업 맞춤형 커스터마이징이 아닌 표준 기능으로 모든 것을 충당한다는 방침으로 복잡한 일본의 인사 제도에 적응해 왔습니다.

하지만 강점에는 그 이면의 과제가 있습니다. 개발 측면에서는 기능이 쌓이면서 코드가 비대해지고 복잡해져, 변경에 따른 영향 범위를 파악하기 어려워 릴리스(Release) 시 신중함이 필요합니다(대응 방향은 "릴리스를 더욱 빠르고 안정적으로", "AI를 활용하기 위한 코드 기반 정비"). 유지보수 측면에서는 사용법이 워란 풍부한 만큼 최적의 이용 제안을 위해 숙고가 필요하며, 문의와 기능 요청이 많아 모든 요구에 응답하기 어렵습니다. 개발자는 "제품이 보유한 풍부한 노하우", "수많은 고객의 목소리", "시장의 변화" 모두와 마주할 시간을 확보하지 못해 피로를 느끼고, 정리되지 않은 채 개발을 진행하여 **임기응변식의 아웃풋(Output)**에 빠지게 된다는 현 상황의 과제가 솔직하게 공유되었습니다. 그럼에도 불구하고 "사실은 그렇지 않다! 재미있다...!! 라는 것을 전달하고 싶다"가 이 세션의 메시지입니다.

역할의 정의는 다음과 같습니다. **도메인 전문가 (Domain Expert)**는 풍부한 노하우를 품은 "제품"과, 그것을 마주하며 쌓아온 압도적인 "도메인 지식 (Domain Knowledge)"을 바탕으로 인사 업무의 표준과 정답을 만들어가는 단계의 선두에 섭니다. **프로덕트 매니저 (Product Manager)**는 고객의 요구에 진심으로 마주하면서 제품 진화에 필요한 본질을 파악하고, 선택과 집중의 전략을 세웁니다.

체제 숫자가 인상적이었습니다. 나가이 씨가 담당하는 COMPANY Web Service(신청 워크플로우·정보 조회. 개인정보 신청·마이넘버 신청·경비 정산·연말정산 신고·급여 정보 조회·평가·발령 신청 등)의 개발 조직은 15개 도메인 영역·80개 서브시스템·7개 그룹입니다. 이에 대해 도메인 전문가는 2명이며, 각 서브시스템과 그룹에 교차 기능적(Cross-Functional)인 서포트를 수행합니다. 미션은 ①버그 수정(BugFix) 및 기능 구현(Function)을 불문하고 도메인 지식이 필요한 안건에 대한 리뷰 참여, ②도메인 전문가 스스로가 과제라고 느낀 제품 과제를 재량권을 가지고 해결하는 것입니다. "개발 안건의 질 향상"과 "개발 공수 확보"라는 두 바퀴로 조직에 기여한다는 설계입니다.

나가이 씨가 도메인 전문가가 되기까지의 경험담이 이 세션의 뼈대였습니다. 도입 컨설턴트 시절에 보였던 과제는 이중적이었습니다. 고객 입장에서는 폭넓고 일반적인 업무 영역에서도 설계와 설정을 처음부터 구축해야 하기에, 방대한 설정량과 짧은 시간 내의 캐치업(Catch-up)이 부담이 되어 패키지의 노하우를 실감하기 어렵습니다. 컨설턴트 입장에서는 일반적인 업무 영역의 안내에 공수가 할애되어, 본래 시간을 쓰고 싶었던 개별 기업의 요구사항에 시간을 쓸 수 없습니다. 패키지의 장점이 "공수의 기회 손실"로 직결되었던 셈입니다.

"표준 설계·표준 설정·표준 도입 방법"이 있다면 좋을 것입니다. 하지만 수천만 행의 코드와 80개 서브시스템, 방대한 파라미터(Parameter) 앞에서 표준의 정의는 매우 난이도가 높습니다. 여기서 발상의 전환이 효과를 발휘했습니다. "표준"이 존재하지 않는 것은 "정의할 수 없어서"가 아니라 "단순히 결정될 수 있는 것이 아니기 때문"이 아닐까? 그래서 설정을 세 가지로 분류합니다.

이 분류에 기반하여 "설계"도 "설정"도 템플릿(설정 파일 + 설정 문서)으로서 패키지화했습니다. 템플릿을 가져오는 것만으로 화면과 제어가 처음부터 완성된 상태로 시작할 수 있게 되었습니다. 고객은 30년의 실적에서 도출한 "인사 업무의 최적해"에서 시작하여 최소한의 핏 앤 갭(Fit & Gap)만으로 완성할 수 있고, 개발자는 복잡한 사양 이해에서 해방되어 마땅히 있어야 할 업무 흐름을 파악한 상태에서 기능 개선의 설계 및 구현에 들어갈 수 있습니다. "제품"과 "업무" 양쪽의 지견이 있었기에 가능했던 일이라는 이야기입니다. 모든 설정을 일률적으로 다루지 않고 "결정 방식의 성질"로 분류한 지점에서 도메인 전문가 업무의 본질이 드러나고 있다고 느꼈습니다.

활동 실적도 구체적이었습니다. Domain Expert(도메인 전문가)가 참여한 리뷰는 BugFix 67건 + Function 85건 = 합계 152건. 그리고 관여 방식의 철학은 '제안'과 '실행'의 세트입니다. 설계서는 '함께 작성했다', 문의는 '대신 답변했다', 릴리스 노트는 '대신 작성했다', 사용자 인터뷰는 '함께 들었다'. 리뷰에서 지적만 하고 돌려보내는 '블로커(Blocker)'가 아니라, 직접 손을 움직여 개발 공수 확보에 기여하는 '반주자(伴走者, 동반자)'라는 점입니다. 전문가 리뷰가 병목 현상의 원인이 되기 쉬운 조직에는 뼈아픈 이야기일지도 모릅니다.

Function(기능)의 구체적인 예로, 개별 기업의 요청이 있었던 중요 안건 2건(이동 발령 신청 / 해외 부임 신청)이 소개되었습니다. 포인트는 목표가 '개별 기업 요청의 달성'이 아니라 '패키지 제품으로서 업무를 표준화하여 정의하는 것'에 놓여 있다는 점입니다.

이동 발령 신청의 경우, 개발자가 "개별 기업의 요청이 표준적인 업무인지 판단할 수 없어..."라며 망설이는 지점에서 "업무로서 일반적이고 표준화할 수 있으므로, 필요성을 충분히 설명할 수 있습니다!"라며 함께 설계서를 작성합니다. 해외 부임 신청에서는 "업무가 독특해서 기능으로 구현하기 어려워..."라는 상황에 "조금 특수한 업무이니, 함께 표준화할 수 있을지 고민해 봅시다!"라며 함께 설계를 구상합니다. 이동 발령의 예에서는 소속 변경 시 조직도에 기반한 값이 자동 입력되고 강제되는 사양에 대해, "이례적인 경우에는 신청자가 덮어쓰기를 가능하게 해달라"는 개별 기업의 요청에서 에센스를 추출하여, 모든 고객에게 가치가 있는 기능으로 진화시켰다고 합니다.

총괄은 서두에서 제기한 과제에 대한 해답 확인이었습니다. 제품이 보유한 풍부한 노하우 $
ightarrow$ "인사 업무의 정답을 만들고, 표준을 만들어 나간다". 수많은 고객의 목소리 $
ightarrow$ "목소리의 본질을 파악하여, 정말 중요한 요소를 추출한다". 시장의 변화와 니즈도 고려하며, 개개인이 도메인 지식(Domain Knowledge)을 갖춘 출발선에 서서 고객의 본질을 마주하는 개발로. 임기응변이 아닌 '전략적인 아웃풋(Output)'으로. 마무리 메시지는 "인간이기에, 엔지니어이기에, 고객의 목소리 '너머'를 바라보며 기대를 뛰어넘는 가치를 창조해 나가자"였습니다.

AI 이야기가 거의 나오지 않은 세션이었지만, 그렇기에 오히려 1일차부터 이어지는 흐름 속에서 더욱 돋보였습니다. 구현 비용이 낮아질수록 가치가 높아지는 '상류 단계의 판단(Judgment)' — 무엇이 표준이고 무엇이 개별 기업의 특수 사항인지를 가려내는 일 — 을 조직의 역할로서 제도화한 실례라고 받아들였습니다.

(사다히로 다카유키 씨 · 후지타 카즈나리 씨 / 이토추 테크노 솔루션즈, 하시모토 코타로 씨 · 이토 유타 씨 / 게이오기주쿠 대학)

2일차의 마무리는 게이오기주쿠 대학 $ imes$ 이토추 테크노 솔루션즈(CTC)의 산학 협력으로 개발 중인, 국제 표준을 준수하는 OSS(Open Source Software) 툴체인 'VC Knots'(github.com/trustknots/vcknots, TypeScript & Go) 세션입니다. 오늘의 목표는 겸손하게도, "Verifiable Credentials란 무엇인가", "IHV 모델이란 무엇인가"를 어렴풋이 이해하고 "뭔가 해두는 것이 좋겠구나"라고 느끼게 하는 것, 그리고 VC Knots에 ⭐(Star)를 달아주신다면 기쁘겠다는 것이었습니다 (VC는 우선 직접 만져보며 이해하는 것이라고 합니다).

먼저 배경입니다. 증명서의 디지털화는 이용 사례가 확대되고 있습니다. 물리적인 증명서는 창구에서 보여주거나 받는 대면 전제의 운용으로 몇 분에서 며칠이 걸리던 것이, 디지털화되면 스마트폰 상에서 '휴대', '제시', '읽기'만으로 완결되어 절차가 몇 초로 단축됩니다 (기존 사례로는 은행 계좌 개설이나 스마트폰 신규 계약, 향후에는 학생 할인 이용이나 취업 시 스킬 증명 등).

문제는 신뢰의 근거입니다. 물리적인 증명서는 워터마크, 복사 방지 가공, 날인, 그리고 높은 위조 비용(졸업 증서의 경우 15만 엔이라는 이야기도 있음)을 통해 신뢰가 담보되어 왔습니다. 디지털은 내용이 0과 1의 나열이라 복사가 용이하고 위조 비용은 거의 무료입니다. 그렇다면 근거를 어떻게 마련할까요? 여기서 **Verifiable Credentials (VC)**가 등장합니다. 디지털 서명을 통해 진위 확인 및 위변조 방지를 실현하는 기계 판독 가능한 디지털 증명서 포맷으로, ① 종이 증명서의 디지털화, ② 발행처·발행처의 특정 및 제시처 지정, ③ 내용·발행처의 위변조 감지, ④ 선택적 공개(필요 최소한의 정보만 제시), ⑤ W3C Verifiable Credentials Data Model 2.0으로서의 표준화가 특징입니다. 증명서에 국한되지 않고 범용적인 '신뢰할 수 있는 데이터의 그릇'으로도 사용할 수 있습니다.

VC를 다루는 등장인물이 바로 IHV (Issuer-Holder-Verifier) 모델입니다.

이 도표의 핵심은 점선 부분입니다. "검증자는 발행자에게 확인할 필요가 없다" —— 이것이 VC의 핵심이며, 발행자에게 문의하지 않고도 검증할 수 있다는 점이 프라이버시 보호와 가용성(Availability) 모두를 뒷받침합니다. 프로토콜은 Issuer→Holder 간이 OID4VCI, Holder→Verifier 간이 OID4VP이며, 포맷 예시는 IETF SD-JWT VC로, "프로토콜 × 포맷"의 조합이 표준의 중심입니다.

국내외 동향도 소개되었습니다. 마이넘버카드의 스마트폰 탑재(iPhone은 2025년 6월 시작, Android는 2026년 가을 예정), 정부 운영 OpenID Provider인 디지털 인증 앱. 실증 사례로는 디지털청 주도의 PoC 2건 —— 대학 재학 증명 + 국민 ID로 할인 운임을 받는 "재학 증명 × 통학 정기권" (대학이 발행자, 학생이 보유자, 철도 회사가 검증자), 산장에서 오프라인 검증하는 QR 기반의 "야마노아카시 프로젝트" (등산객 증명서, 2025년) —— 외에도, 자동차 업계의 데이터 유통 기반인 Catena-X (트레이서빌리티(Traceability) · 탄소 배출량 · 디지털 제품 패스포트를 VC로 "신뢰할 수 있는 데이터"로서 유통시키는 실운용 산업 기반)가 언급되었습니다.

여러 기업과 지자체로부터 "VC를 자사 서비스에 편입하고 싶다"는 목소리(신분 증명의 디지털화, 본인 확인 · 자격 확인을 수 초 내에 완료하는 온라인 절차의 효율화, 자사가 발행원이 되는 새로운 신뢰 서비스)가 들려오는 한편, 앞을 가로막는 것은 "표준 사양의 정글"입니다. W3C VCDM, SD-JWT VC, ISO mdoc (ISO/IEC 18013-5), OID4VCI, OID4VP, 여기에 DIF PE, DCQL, JWT, CWT, DID……. 경쟁하는 사양이 너무 많아서 명확한 답이 너무 적습니다. 데이터 모델 · 포맷 · 프로토콜 · 식별자 중 무엇을 선택할지, 어떻게 조합할지도 사양서만 읽어서는 답이 나오지 않습니다.

세션 개요에도 있었던 "사양(spec)을 읽기만 해도 하루가 다 간다……"는 **사양 피로(spec fatigue)**라고 명명되었습니다. JOSE/COSE, OAuth 2.0 관련 (DPoP · RAR · PAR), DIDComm v2, Trust Framework/Trust Registry 등 범위도 넓고, Issuer/Wallet/Verifier 중 어디부터 손을 댈지도 막막합니다. 게다가 구현의 난관은 사양 그 자체가 아니라 "조합하는 순간"에 나타납니다. 데이터 모델/형식 × 발행/제시 프로토콜 × 암호/서명/키 × 식별자/신뢰 기반이라는 4가지 사양 레이어가 동시에 얽히는 "조합 설계"로 인해, 결과적으로 구현자는 "선택한다 · 구현한다 · 연결한다 · 추종한다"라는 4가지 부하를 짊어지게 됩니다. 개발자들의 본심으로 "빨리 출시하고 싶다. 하지만 망가뜨리고 싶지 않다", "표준을 따르고 싶다. 하지만 얽매이고 싶지 않다", "사양은 쫓아가고 싶다. 하지만 본업은 따로 있다", "사양의 차이를 매번 쓰고 싶지 않다"라는 말이 나열된 것은 많은 이들이 공감하는 부분일 것입니다. 개발자가 원하는 것은 변경에 견딜 수 있는 구현의 토대입니다.

그 토대가 바로 VC Knots입니다. 게이오기숙대학 SFC 연구소 × CTC의 공동 연구 프로젝트 "Trust Knots"에서 얻은 지견을 VC 구현 OSS SDK로 녹여낸 것으로, 국제 표준에 대응하는 주요 기능을 모듈화하고 있습니다. PoC를 폐쇄적으로 만들지 않기 위해서는 발행 · 검증뿐만 아니라 Wallet을 포함한 일련의 흐름이 필요하며, Issuer · Wallet · Verifier의 세 기능을 횡단하여 상호 운용성을 검증할 수 있는 구성, 사양 차이를 흡수하는 경계, 동작하는 샘플부터 시작하여 요구 사항에 따라 확장할 수 있다는 점의 3가지가 설계 사상입니다.

구현 측면의 이야기도 구체적이었습니다. TypeScript (Issuer+Verifier)는 프로바이더 패턴(Provider pattern)을 사용하여, 각 Provider가 kind와 canHandle()을 가지며 Registry가 이를 통합합니다 (vcknots({ providers: [...] })). Go (Wallet)는 디스패처 패턴(Dispatcher pattern)을 사용하여, map[EnumType]Plugin을 보유하고 RegisterPlugin(key, impl)로 등록하며 enum 키로 불러오는 형태입니다.

플러그형(Pluggable) 구조의 중요성은 세 가지입니다. 첫째, 에코시스템(Ecosystem)마다 전제가 다르다는 점(어떤 산업은 mdoc을, 다른 산업은 SD-JWT VC를 선호하여 하나의 포맷으로 고정할 수 없음), 둘째, 암호 민첩성(Cryptographic Agility)(오늘의 암호 알고리즘이 내일도 안전하다는 보장이 없으므로 서명 방식이나 키 타입을 교체할 수 있는 구조가 필요함), 셋째, 재구축 없이 비교 검토가 가능하다는 점(플러그인 교체만으로 비교가 가능하여 PoC(Proof of Concept) 속도가 달라짐)입니다.

OSS(Open Source Software)일 필요성에 대한 설명도 논리적이었습니다. 진입 장벽을 낮추고, 단일 기업의 신뢰에 국한되지 않으며, 상호 운용성(Interoperability)을 구현으로 보여주는 것입니다. OSS로 공개 → 오픈 표준(Open Standard) 준수 → 상호 운용성 담보(타사 월렛 및 공공 월렛과 연결) → VC 커뮤니티 확대라는 흐름을 따르며, EU의 디지털 ID 월렛(EUDIW) 또한 소스 공개와 표준 채택이 신뢰의 전제가 되고 있다고 합니다. 그리고 품질의 뒷받침은 적합성 테스트(Conformance Test)(OpenID Foundation Conformance Suite)입니다. 이를 통과하면 자사의 주장이 아닌 외부 기준을 통해 사양 준수를 증명할 수 있어, "작동합니다"라는 말을 증거와 함께 설명할 수 있습니다. 현재 상황은 OpenID4VCI 1.0의 경우 Issuer가 Conformance를 통과하여 Wallet이 대응 중이며, OID4VP 1.0은 대응 중, AWS 대응 및 문서·샘플 앱 정비, 그리고 다음 표준 대응으로 이어지는 로드맵을 보여주었습니다.

산학 협력 파트도 좋은 내용이었습니다. CTC 측은 기업 이용 및 PoC에서 VC를 사용할 수 있는 형태로 구체화하여, 업무 요구사항과 사양 사이의 격차를 설계에 환원합니다. 대학 측은 OSS 구현을 통해 사양의 한계와 확장점을 발견하고, 이를 다음 연구 아젠다(Agenda)에 반영합니다. 즉, 구현이 다음 연구 테마를 낳는 순환 구조입니다(앱과 SDK를 병행 개발하는 과정에서 프라이버시 등의 과제가 떠올라 연구실의 아젠다가 되었다고 합니다).

학생의 관점도 솔직했습니다. 연구 측면에서는 초심자가 0부터 Wallet을 구현하는 것은 높은 장벽이지만, VC Knots를 통해 직접 실험 환경을 구축할 수 있어 졸업 연구나 실증 실험을 원활하게 진행할 수 있었습니다. IIW(Internet Identity Workshop) 참여나 아이디어톤을 통해 시야도 넓어졌습니다. 개발 측면에서는 참여 전에는 "VC는 Issuer/Holder/Verifier로 구성되어 단순해 보인다"라고 생각했으나, 실제로는 상상보다 "사양이 많은" 프로젝트였으며, 필수 항목 하나를 검증하는 것만으로도 사양서를 반복해서 확인해야 했고 OAuth 2.0/JWT/DPoP 등 전제 지식도 줄줄이 필요했습니다. 하지만 사양이 엄격하기 때문에 오히려 구현에 전념할 수 있는 측면도 있었으며, VC Knots가 세부적인 사양 대응을 흡수해 주기 때문에 앱 개발자는 안전한 플로우(Flow)를 즉시 구동할 수 있습니다. 스크럼(Scrum) 개발 참여를 통해 우선순위 선정도 자연스럽게 체험할 수 있었다는—산학 협력 특유의 배움이었습니다.