개요

배경 및 목적

다양한 분야의 기술 문헌을 지속적으로 수집·평가하고 싶다는 니즈를 많은 고객이 요청하고 있다. 기존에는 PDF나 특허 문서를 폴더로 관리할 뿐, "어떤 기술이 어느 정도의 성숙도인가", "관련도가 높은 문헌은 무엇인가"와 같은 횡단적인 파악이 어려웠다.

이에 LDX hub StructFlow를 사용하여 PDF·특허 문서에서 구조화 데이터(Structured Data)를 자동 추출하고, SharePoint를 데이터 기반(Data Foundation)으로, Power Automate로 업데이트를 자동화하며, Power Apps와 HTML 대시보드로 시각화하는 일관된 시스템 「TechLit Viewer」를 구축했다.

시스템 설계: 4개의 레이어로 구성된 아키텍처 (Architecture)

// TechLit Viewer 시스템 구성
[1] 입력층 문헌 파일 (PDF·특허·보고서)
└─ SharePoint 문서 라이브러리에 저장. 18건의 기술 문헌이 대상.
...

플로우 설계: 2개의 플로우로 「자동」과 「일괄」을 구분하여 사용

업데이트 트리거(Trigger)를 두 가지 패턴으로 나누어, 일상적인 운영의 자동화와 초기 데이터 투입·재처리 모두에 대응하고 있다.

① TechLit_파이프라인 UPDATE (상시 가동)

SharePoint 리스트의 아이템 업데이트를 트리거로 자동 실행. 신규 문헌 등록이나 기존 레코드(Record)의 변경을 감지하여, 대상 파일을 StructFlow로 전송하고 추출 결과를 즉시 다시 기록한다. 일상적인 문헌 추가는 이 플로우로 완전 자동화된다.

② TechLit_일괄 업데이트 (수동 실행)

전체 18건을 일괄 처리하는 수동 트리거 플로우. 스키마(Schema) 변경이나 프롬프트(Prompt) 개정 후의 재추출, 초기 데이터 투입에 사용한다. foreach 루프를 통해 모든 아이템을 순차적으로 처리하며, StructFlow의 폴링(Polling)을 대기하면서 결과를 리스트에 기록한다.

추출 스키마: StructFlow에 정의한 8개 필드

기술 문헌에서 가치 있는 정보를 끌어내기 위해, 전략적 평가에 필요한 8개의 필드를 스키마로 정의했다.

Power Apps 구성: 4개 화면으로 용도를 구분한 열람 인터페이스

HTML 대시보드: 스탠드얼론(Standalone)으로 동작하는 기술 전략 뷰

Power Apps와는 별개로, 브라우저 단독으로 동작하는 스탠드얼론 HTML 대시보드 (techlit_dashboard.html)도 병행하여 정비했다. Power Apps에 의존하지 않고 경영진·외부 이해관계자(Stakeholder)에게 공유가 가능하다는 점이 최대의 장점이다.

// StructFlow 추출 결과를 그대로 데이터 배열(Array)에 저장
const data = [
{
...

4종의 차트(기술 영역 분포·TRL 분포·연도별 트렌드·문서 종류 비율)와 전체 검색이 가능한 문헌 목록 테이블로 구성된다. StructFlow로부터 얻은 구조화 데이터를 Chart.js에 전달하는 것만으로 분석 그래프가 자동 생성된다.

검증 결과: 18건의 기술 문헌을 구조화 데이터로 활용 가능하게 함

StructFlow 추출 정밀도

18건 중 모든 필드가 정상적으로 추출된 것은 15건(83%). 나머지 3건은 FieldMajor의 언어 표기 불일치(영어·일본어 혼재)가 발생했으나, 데이터로서 활용하는 데 지장은 없다.

Power Automate 자동화

일괄 업데이트 플로우의 1건당 평균 처리 시간은 약 67초(StructFlow 폴링 포함). 18건 전체 처리는 약 20분 만에 완료되었다. 정기 실행 및 트리거 실행 모두 안정적인 가동을 확인했다.

기술 영역의 시각화

Environmental Science 계열이 가장 많았으며(6건), Materials Science가 그 뒤를 이었다(4건). TRL (기술성숙도) 분포에서는 기초 연구(13)가 8건으로 가장 많았고, 실용화 단계(79)는 3건이었다. 포트폴리오의 전체상을 처음으로 정량적으로 파악할 수 있었다.

관련도 평가

18건 중 15건이 RelevanceScore = High로 판정되었다. StructFlow의 프롬프트에 자사 사업 문맥(번역·로컬라이제이션)을 포함함으로써, 업무와 직결된 평가 축을 통한 자동 스크리닝을 실현했다.

이번의 배움

SharePoint 열(Column) 타입은 프로젝트 시작 전에 결정한다

열의 타입(하이퍼링크 타입 vs 1행 텍스트 타입)은 나중에 변경할 수 없다. Power Automate에서 쓰는 값의 형식을 먼저 확인하고, 열 설계를 확정한 후 구축에 들어가는 것이 필수적이다.

StructFlow의 스키마는 「평가 축」으로부터 설계한다

필드 설계는 "무엇을 추출할 수 있는가"가 아니라 "무엇으로 의사결정을 하고 싶은가"로부터 역산해야 한다. TRL, RelevanceScore와 같은 평가 축 필드를 처음부터 포함함으로써 대시보드의 가치가 크게 달라졌다.

Power Apps와 HTML 대시보드의 역할을 분리한다

Power Apps는 일상적인 검색 및 업데이트 작업에 적합하고, HTML 대시보드는 공유 및 프레젠테이션에 적합하다. 동일한 데이터 소스를 두 가지 UI로 나누어 사용함으로써 이용자층과 용도를 넓힐 수 있다.

FieldMajor의 표기 통일은 프롬프트로 제어한다

"Materials Science"와 "재료과학"이 혼재되면 집계가 분산된다. StructFlow의 시스템 프롬프트에 "기술 영역은 반드시 영어 표기로 출력할 것"이라고 명시함으로써 표기 불일치를 방지할 수 있다.

향후 전개