기업 AI 문서 읽기, 무엇이 어려운가: 페이지 넘는 표에서 시작

서문

기업 지식 베이스의 첫 버전은 대개 어렵지 않게 구축할 수 있습니다. PDF를 업로드하고, 내용을 추출하고, 분할해 저장하고, 검색과 질의응답을 연결하면 됩니다. 기존 도구만으로도 이 흐름은 돌아갑니다. 문제는 구체적인 업무 질문을 던지기 시작한 뒤에 생깁니다.

파일은 분명히 온전히 업로드됐는데 답변에는 제한 조건이 빠져 있고, 숫자는 찾았는데 설비 모델명이 맞지 않으며, 글은 매끄럽게 읽히는데 원문을 다시 펼쳐 보니 인용한 것이 다른 표였습니다. 프롬프트를 조정하면 한 문제는 구제할 수 있을지 몰라도 다음 파일이 왜 또 틀리는지는 설명하지 못합니다.

우선 입력으로 돌아가 보는 편이 좋습니다. Agent가 실제로 읽은 내용은 원본 문서의 의미를 여전히 간직하고 있을까요?

설비 기술 사양을 예로 들면, 하나의 파라미터 표가 두 페이지에 걸쳐 있을 수 있고, 여러 모델이 하나의 병합 셀을 공유하며, 표 아래에는 특정 파라미터의 적용 범위를 한정하는 각주가 달려 있을 수 있습니다. "이 설비를 현재 프로젝트에 사용할 수 있는가"에 답하려면 모델, 수치, 단위, 조건을 함께 읽어 내야 합니다.

사람에게는 이것이 그저 위로 한 번 표 머리글을 올려다보고, 뒤로 한 페이지를 넘기는 일일 뿐입니다. 그러나 문서 처리 시스템에게는 표 구조, 읽기 순서, 내용 연관성이 얽힌 문제입니다. 어느 한 곳에서 관계가 끊기면 뒤따르는 검색과 답변도 따라서 틀어질 수 있습니다.

1. 문서 속 구조 자체가 정보이다

문서를 읽을 때 우리는 계속해서 판면을 근거로 내용을 이해합니다. 어떤 숫자가 "정격 출력" 아래에 적혀 있는지 "피크 출력" 아래에 적혀 있는지에 따라 의미가 다릅니다. 어떤 설명이 어느 소절 아래에 달려 있는지에 따라 어느 부분의 내용을 제약하는지가 정해집니다. "상동" "아래 표 참조" "다음 모델에만 적용" 같은 표현 역시 문맥이 있어야 설명이 됩니다.

문서가 순수 텍스트로 변환된 뒤에는 이러한 정보가 반드시 남아 있지는 않습니다. 표가 숫자 나열로 변할 수 있고, 두 단 컬럼 본문이 뒤섞여 배열될 수 있으며, 머리글과 바닥글이 문단 중간에 끼어들 수도 있습니다. 문자 인식률만 봐서는 이런 문제들을 찾아낼 수 없습니다. 글자 자체는 대개 틀리지 않았고, 틀린 것은 글자들 사이의 관계이기 때문입니다.

이런 손실은 처리 흐름을 따라 계속 전달됩니다. 표가 파싱 과정에서 흩어지면 분할 프로그램이 수치와 표 머리글을 서로 다른 조각에 나눠 담을 수 있습니다. 제한 조건이 다른 조각에 떨어져 있고 검색 시 함께 가져오지 않으면, 모델이 최종적으로 받은 자료는 모두 원문에서 나온 것이지만 온전한 판단을 뒷받침하지 못합니다.

문제를 점검할 때는 원문, 파싱 결과, 검색 조각, 최종 답변을 나란히 놓고 봅니다. 표 머리글이 빠졌으면 먼저 파싱을 확인하고, 각주가 이미 추출됐는데도 답변에 들어가지 않았다면 다시 분할과 검색을 확인합니다. 문제가 어느 단계에서 발생했는지에 따라 그 단계를 고치면 됩니다.

현재의 배경 속에서 단순히 Agent만으로 문서, 표 등의 파싱을 완수하는 것은 여전히 제대로 해결하기 어려운 문제가 상당히 많습니다. 이런 문제에 대응해 저는 여러 제품을 사용해 문제를 해결해 보았고, 아래에서는 사용해 본 결과 효과가 매우 좋았던 제품 TextIn xParse를 소개하겠습니다. TextIn xParse는 파싱 단계를 담당합니다. PDF, Office 문서, 스캔본, 이미지를 Markdown, JSON 등 구조화 데이터로 변환해 지식 베이스, RAG 또는 Agent가 이어서 처리하도록 넘겨줍니다.

2. TextIn xParse: Agent가 복잡한 문서를 안정적으로 이해하도록

TextIn xParse는 허허정보(合合信息) 산하의 LLM과 Agent를 겨냥한 문서 인텔리전스 인프라로, 복잡한 문서를 깨끗하고 일관되며 AI에 활용 가능한 구조화 데이터로 변환할 수 있으며, 지식 베이스, RAG 또는 기타 AI 워크플로 다운스트림 애플리케이션에 적합합니다.

제품 포지셔닝에서 보면 xParse는 단순한 OCR이 아니라 LLM을 겨냥한 문서 파싱 서비스입니다. 입력은 PDF, 이미지 등 일반적인 형식을 지원하고, 출력은 HTML, Markdown, JSON 등 다양한 구조화 형식을 제공합니다.

공식 주소: www.textin.com/register/co…

공식 문서 주소: docs.textin.com/xparse/over…

2.1 표: 수치와 행·열이 맞아야 한다

기업 문서의 표에는 대개 데이터와 설명이 함께 있습니다. 다단 표 머리글은 동일 지표의 서로 다른 운전 조건을 구분하고, 병합 셀은 한 모델군의 공통 속성을 표현하며, 페이지를 넘어 이어지는 표는 앞선 표 머리글로 뒤쪽 데이터를 해석합니다.

TextIn xParse는 다단 표 머리글, 병합 셀, 페이지 넘김 표의 구조 복원을 지원합니다. 다운스트림 프로그램이 어떤 파라미터 항목을 읽으려면 그 항목의 행 제목, 열 제목, 단위를 동시에 찾아야 합니다. 대응 관계가 유지되어야 데이터에 의미가 생깁니다.

이러한 관계는 추출에도 직접 영향을 줍니다. 설비 파라미터를 데이터베이스에 기록하려면 "2.0" 하나를 추출하는 것만으로는 부족합니다. 그것이 출력인지 무게인지, 어떤 단위인지, 어느 모델에 속하는지를 모두 밝혀야 합니다. 표 구조는 바로 이러한 의미를 판단하는 근거 가운데 하나입니다.

2.2 장·절과 읽기 순서: 분할에 근거를 남긴다

긴 보고서 안에서는 같은 단어가 반복해서 등장합니다. "유지보수 요구사항"은 장·절 제목일 수도 있고, 본문이나 목차, 머리글에도 나타날 수 있습니다. 제목 계층이 유지되어야 이후 프로그램이 내용의 위치와 귀속을 구분할 수 있습니다.

읽기 순서도 마찬가지입니다. 두 단 컬럼 본문, 이미지 옆 설명, 표 아래 주석은 모두 합리적으로 배열되어야 하며, 그렇지 않으면 문장은 완전하지만 앞뒤가 이어지지 않습니다.

TextIn xParse가 출력하는 제목 계층과 읽기 순서는 분할을 배치하는 데 활용할 수 있습니다. 문단에 소속 장·절을 남기고, 표와 관련 설명을 함께 묶는 것입니다. 긴 장·절은 여전히 나눠야 할 수 있고, 짧은 표는 통째로 유지하는 편이 더 적합하며, 어느 정도로 나눌지는 문서와 질문의 범위에 따라 달라집니다.

2.3 혼합 PDF: 페이지별로 처리

기업이 받는 PDF는 여러 출처가 뒤섞여 있는 경우가 많습니다. 본문은 전자적으로 내보낸 것이고, 첨부는 스캔본이며, 중간에 사진으로 업로드한 서명 페이지가 끼어 있기도 합니다. 일률적으로 같은 방식으로 읽으면 모든 페이지의 정보를 다 활용하지 못할 수 있습니다.

전자 페이지는 원본 텍스트를 보존할 수 있고, 스캔 페이지는 시각 인식에 의존해야 합니다. TextIn xParse는 전자 파싱, OCR, 멀티모달 파싱을 결합해 페이지별로 파싱 경로를 선택하는 것을 지원하며, 도면, 수식, 복잡한 시각 판면에 대해서는 멀티모달 강화 파싱도 제공합니다.

도면이나 수식을 테스트할 때는 먼저 그 작업이 어느 단계까지 수행하는 것인지 구분해야 합니다. 주석을 추출하는 것인지, 표현을 보존하는 것인지, 아니면 공학적 판단을 해야 하는 것인지입니다. 앞의 두 가지는 입력 처리에 속하며, 공학적 결론은 전문 규칙과 실제 업무 정보를 결합해야 하고 검사 기준도 다릅니다.

혼합 PDF는 전체 흐름을 검증하기에 매우 적합하지만, 처음 몇 차례는 페이지 유형을 먼저 분리하는 것이 좋습니다. 그래야 특정 페이지에서 항목이 누락됐을 때 그것이 이미지 품질 문제인지, 페이지 구조 문제인지, 아니면 이후 처리의 문제인지 구분할 수 있습니다.

먼저 깨끗한 전자 페이지로 제목과 표를 확인한 다음, 내용이 동일한 페이지를 스캔본으로 변환해 텍스트, 구조, 위치가 여전히 쓸 수 있는지 살펴볼 수 있습니다. 두 입력의 내용이 일치해야 비교할 때 차이가 또렷하게 보입니다. 이후에 변수를 하나씩 추가합니다. 약간의 회전, 낮은 대비를 각각 기록합니다. 한 번에 조건을 전부 바꾸지 마십시오.

복잡한 시각 페이지도 먼저 작업을 명확히 해야 합니다. 도면 한 장이라면 먼저 주석 텍스트와 위치를 확인하고, 다음으로 파라미터와 대상이 서로 맞는지 확인할 수 있습니다. 그것으로 공학적 결론을 도출할 수 있는지는 별개의 문제이며 전문 정보가 더 필요합니다. 입력 추출과 업무 판단을 분리해 검증해야 한 층을 맞게 처리한 것을 일 전체를 해냈다고 착각하지 않게 됩니다.

샘플에서 평범한 페이지도 빠뜨리지 마십시오. 빈 페이지, 구분 페이지, 반복되는 머리글은 모두 본문에 섞여 들어와 문단을 끊거나 검색에 노이즈를 더할 수 있습니다. 복잡한 페이지만 골라 역량을 보여주는 것으로는 부족하며, 매일 실제로 받는 파일을 제대로 처리할 수 있는지도 봐야 합니다.

3. 세 가지 샘플로 파싱과 질의응답 점검하기

“请总结全文”는 빠른 훑어보기에는 적합하지만, 구조적 오류를 드러내기에는 쉽지 않다. 각주 한 줄을 빠뜨려도 요약문은 그럴듯하게 읽히기 때문이다. 아래 세 가지 소규모 샘플은 각각 정답이 명확하며, 각기 다른 페이지에 걸친 표, 조건 제한, 그리고 혼합된 페이지를 점검한다.

모델명, 수치, 텍스트는 모두 샘플 구성을 위한 예시다. 먼저 기대 정답을 원문에 근거해 정한 뒤 테스트를 시작한다.

3.1 테스트 시나리오 1: 페이지를 넘는 긴 표

기업 문서의 긴 표는 여러 페이지에 걸쳐 이어지는 경우가 많고, 이어지는 페이지에는 대개 표 머리(헤더)가 반복되지 않으며 “계속표” 같은 아주 약한 표식으로만 구분할 수 있다. 시스템은 먼저 이 페이지가 앞선 표의 연속인지, 아니면 또 다른 새 표인지를 판단해야 하며, 이어 붙일 때는 표 머리와 열 너비까지 함께 계승해야 한다. 이 단계에서 판단을 틀리면 긴 표가 쉽게 분리되고, 무관한 표가 잘못 합쳐질 수도 있으며, 표 머리가 어긋나면 데이터 매칭도 함께 틀어진다. 여기에 페이지를 넘는 병합 셀까지 겹치면 난이도는 더욱 올라간다.

문제의 근원은 OCR 문자 인식이 아니라, 문서 전역 모델링이나 페이지 분할 상태 관리 같은 아키텍처 역량이 부족하다는 데 있다. 페이지를 넘는 파싱에는 전역 표 이해 능력을 갖춘 모델이 필요하다.

아래는 한 아파트 단지 주차 관리의 긴 표인데, 저는 몇 가지 다른 제품으로 테스트해 보았으나 하나의 표로 정상 파싱하지 못했고, TextIn xParse는 정상적으로 하나의 표로 인식·파싱했다.

또한 TextIn xParse는 파싱 시 여러 가지 설정을 지원하므로, 자신의 문서 유형에 따라 더 정확한 유형을 선택해 더 적합한 파싱 효과를 얻을 수 있다.

3.2 테스트 시나리오 2: 여러 행 셀 + 밀집한 작은 글씨

어떤 경우에는 일부 표 문서에 행 수가 많은 셀과 아주 밀집한 작은 글씨가 존재하는데, 이는 일부 제품에서 대량이고 복잡한 구매 명세서나 주문 발주 코드 문서 등에서 사용된다.

이런 경우 수량이 많고 글씨가 작기 때문에 문자 파싱 오류가 발생할 수 있어, 제품의 기본기를 상당히 시험하게 된다.

아래는 전원 연결 주문 문서인데, 기업 문서에는 이런 주문 표가 대량으로 존재하며, 파싱에 아무런 문제가 없음을 볼 수 있다. 이는 문서 수요가 많은 경우에 아주 훌륭한 경험이다.

3.3 테스트 시나리오 3: 테두리 없는 표 + 중첩된 표 머리

아래 그림은 어느 투자설명서의 표로, 상당히 복잡한 표이며 그 안에는 무선(불연속) 표, 중첩된 표 머리, 번체자, 검은색 밑줄 셀 등 여러 가지 방해 요소가 있다.

TextIn xParse로 파싱한 후에는 표 머리와 내용 모두 문제없이 파싱된 것을 볼 수 있으며, 텍스트, 수치, 줄바꿈과 셀이 비교적 정확하여 정상적으로 사용할 수 있다.

Markdown, JSON, 표 등의 형식으로도 파싱할 수 있어 기능도 비교적 완비되어 있으며, Agent가 분석할 때 구체적인 셀 데이터의 정확한 대응 관계를 이해할 수 있게 해 준다.

4. 파싱 이후, 구조를 어떻게 지식베이스에 담을 것인가

파싱 결과가 깔끔해 보인다고 해서 이미 라이브러리에 제대로 적재되었다는 뜻은 아니다. 분할, 변환, 저장 과정에서 정보가 또 한 번 손실될 수 있다. 제목은 인식되었지만 적재 후에는 본문만 남을 수 있고, 표는 완전히 복원되었지만 분할 시 중간에서 잘려나갈 수 있다. 이 몇 단계는 파싱 출력과 함께 점검해야 한다.

먼저 섹션을 보자. 한 문단이 “설치 전에 검사를 완료해야 한다”라고만 적혀 있을 수 있고, 무엇을 검사하는지는 상위 제목이 알려 주는데, 분할 시 문단만 남기면 검색해 왔을 때 대상이 빠진다. 따라서 조각에 소속 섹션 경로를 붙여, 프로그램이 그것이 어느 장 어느 절에서 왔는지 알 수 있게 해야 한다. 제목 계층은 단지 조직 근거일 뿐이며, 얼마나 잘게 나눌지는 비즈니스 질문이 보통 어느 정도 범위의 문맥을 필요로 하는지에 달려 있다.

표는 별도로 처리한다. 작은 표는 전체를 유지할 수 있고, 큰 표는 나누어야 할 수 있지만 나눈 뒤에도 열 제목, 단위, 필요한 주석을 여전히 알아야 한다. 과제가 다르면 필요도 다르다. 어떤 모델의 파라미터를 답할 때는 그 행을 중심으로 구성하면 충분하지만, 여러 모델을 비교할 때는 관련 레코드 묶음을 가져와야 한다. 고정 길이 분할은 이런 차이를 쉽게 무너뜨린다.

원문 위치를 끝까지 함께 가져가야 한다. 하나의 조각이 원문의 여러 영역에 대응될 수 있고, 하나의 답변이 여러 페이지의 자료를 종합할 수도 있다. 단락 전체에 페이지 번호 하나만 저장하면, 표시할 때 각 근거를 정확히 가리키지 못할 수 있다. 통합 시 실제 인터페이스 반환에 따라 출처와 내용 사이의 매핑을 보존하고, 비즈니스 필드로 변환한 뒤에는 필드 값만 남지 않도록 해야 한다.

파일도 구분되어야 한다. 같은 이름의 파일은 내용이 다를 수 있고, 이름이 바뀌었다고 해서 비즈니스 내용이 바뀐 것도 아니다. 자료 관리 계층에서 출처, 버전, 처리 배치를 기록해야 사후에 어떤 출력이 어느 입력을 사용했는지 설명할 수 있다.

검수 시에는 필드 하나를 골라 처음부터 끝까지 추적해 보라. 원문 위치가 맞는지, 파싱이 빠짐없이 되었는지, 적재 후에도 구조가 남아 있는지, 답변 시에는 무엇을 다시 가져왔는지. 필드 하나를 끝까지 따라가면 링크드 체인의 어디서 누수가 생겼는지 보인다.

5. 문서 파싱에서 기업 지식 서비스로

여기까지, 단일 문서의 내용, 구조, 위치에 대한 점검 방법을 갖추었다. 그러나 구매 주문, 입고 전표, 송장은 서로 다른 파일에 흩어져 있어 관련 정보를 서로 맞춰야 한다. 서로 다른 전표의 필드명과 형식은 다르지만, 주문, 금액, 납기일은 서로 맞아야 한다.

TextIn 제품 체인에서 DocFlow는 혼합 문서 패키지를 관리한다. 세트 분류, 필드 추출, 구조 정규화, 검증·심사, 수동 검토를 거쳐, 최종적으로 내용을 계속 처리할 수 있는 비즈니스 정보로 정리한다.

더 나아가면 문제는 단일 문서 처리를 넘어선다. 고객이 약칭으로 바뀌고, 주문 진행 상황이 달라지고, 공급업체가 또 새 이메일을 보내면, Agent가 사용하는 지식도 그에 맞춰 유지보수되어야 한다. 각 애플리케이션이 각자 자료를 접속하고 정리하고 갱신하면, 같은 질문에 서로 다른 시점, 서로 다른 기준의 답변이 나올 수 있다.

10월 22일, QCon 글로벌 소프트웨어 개발 콘퍼런스에서 허허정보 산하 TextIn이 기업 지식 서비스 엔진을 출시했다. 이 엔진은 xParse와 DocFlow의 문서 처리 축적을 바탕으로, 문서, 표, 비즈니스 시스템에 있는 정보를 가공하고 연관시켜, Agent가 지속적으로 사용할 수 있는 컨텍스트를 형성하고 여러 Agent에 공유되는 기업 지식을 제공한다.

TextIn 기업 지식 서비스 엔진은 이미 예약 체험을 시작했다. 기업 지식 관리나 Agent 애플리케이션 수요가 있는 팀은 b.intsig.com/solution-ap… 에 방문해 신청할 수 있다.

5.1 신제품의 세 가지 역량

기업 지식 서비스 엔진은 지식 구축, 지식 운영, 지식 서비스 세 부분으로 구성되며, 각각 자료의 조직, 변화의 유지보수, 애플리케이션으로의 지식 제공을 담당한다.

**지식 구축은 접속과 조직을 담당한다.** 정보는 문서, 데이터베이스, API 또는 기타 자료원에서 올 수 있으며, 들어온 후에는 파싱, 추출, 정제, 품질 점검을 거친 뒤 비즈니스 정의에 따라 객체, 속성, 관계, 규칙을 조직화한다. 주문이 어떤 고객과 연관되고, 어떤 계약을 인용하며, 어떤 자재를 포함하는지는 모두 표현해야 하는 비즈니스 관계에 속한다.

어떤 주문의 납품 상황을 물으면, 애플리케이션은 이 주문의 계약, 진행 상황, 통지를 가져와야 한다. 주문과 자료의 관계가 사전에 명확히 조직되어 있어야만 “납품”이라는 두 글자만으로 다른 프로젝트의 조각을 검색해 오지 않는다.

**지식 운영은 변화와 신뢰성을 담당한다.** 기업 정보는 계속 변하기 때문에 시스템은 버전을 추적하고, 추가·수정·확인 대기 중인 내용을 관리하며, 출처 간 충돌을 처리해야 한다. 출처 근거, 수동 확인, 품질 모니터링도 이 부분에 있다.

예를 들어 두 시스템이 서로 다른 납기를 제시했다면, 임의로 하나를 최종 사실로 골라서는 안 된다. 그것들은 각각 계약 합의, 내부 계획, 공급업체 예상을 대표할 수 있어 의미가 원래부터 다르며, 실제로 확인 대기 중인 충돌일 수도 있다. 이러한 차이를 유지보수해야만 Agent가 적합한 정보를 사용할 수 있다.

**지식 서비스는 지식을 애플리케이션에 제공한다.** 객체, 컨텍스트, 증거 세 가지 인터페이스는 각각 서로 다른 호출 요구에 대응하며, API, MCP 등의 방식으로 통합된다. 객체 서비스는 비즈니스 객체와 그 속성 및 관계를 대상으로 하고, 컨텍스트 서비스는 현재 작업을 중심으로 관련 정보를 제공하며, 증거 서비스는 출처 근거를 반환하는 역할을 맡는다.

개발자는 작업에 따라 선택한다. 주문 속성을 읽거나, 납기 판단을 위한 자료를 준비하거나, 인용 근거를 사용자에게 보여주는 식이다. 필요한 데이터가 다르면 호출 방식도 따라 달라진다.

5.2 새 자료를 보충하고, 다시 한 번 검증한다

지식 서비스가 돌아가기 시작한 뒤에는 간단한 비즈니스 관계로 업데이트를 검증할 수 있다. 먼저 고객, 계약, 주문을 입력한 다음, 새로운 예정일이 담긴 통지서를 한 부 보충한다.

통지서가 검색되는지만 확인해서는 안 되고, 올바른 주문에 연결되었는지, 기존 약정이 그대로 남아 있는지, 애플리케이션이 기록의 신구와 의미를 구분할 수 있는지도 봐야 한다.

같은 객체를 두고 각각 물어볼 수 있다. "계약 요구 사항은 무엇인가", "현재 예정은 무엇인가", "이번에 무엇이 바뀌었나". 세 질문에 필요한 자료 조합은 서로 다르다. 답이 모두 같은 날짜라면 비즈니스 필드나 버전, 또는 컨텍스트 선택 방식을 살펴봐야 한다.

출처가 상충하는 두 자료를 만나면 시스템이 확인 대기 상태를 어떻게 제시하는지 본다. 비즈니스 담당자가 아직 확인하지 않았다면 애플리케이션이 그중 한 값을 이미 확인된 사실로 포장하게 해서는 안 되며, 확인된 뒤에는 어느 기록을 근거로 했고 어떤 프로세스에서 처리했는지 조회할 수 있어야 한다. 이 몇 단계를 통해 지식 구축, 운영, 서비스를 같은 실제 작업 안에서 볼 수 있다.

다중 Agent 재사용도 이 관계를 따라 펼칠 수 있다. 고객 서비스는 납기를 조회하고, 생산 어시스턴트는 준비 조건을 읽으며, 각각 그들이 받은 정보가 자신의 작업과 권한에 부합하는지 본다. 공유 지식에 필요한 것은 관련성 있고 관리되는 기록이지, 모든 애플리케이션이 똑같은 내용을 보는 것이 아니다.

요약

서두의 그 페이를 넘나드는 표로 돌아가 보자. 틀린 답은 대개 글자를 못 알아본 것이 아니라, 글자와 글자 사이의 관계를 가져오지 못한 것이다.

파싱 단계에서 표, 장절, 페이지 유형, 원문 위치를 남겨 두어야 이후의 분할, 검색, 답변에 근거가 생긴다. 검증도 큰 프로젝트부터 시작할 필요는 없다. 답이 명확한 작은 샘플 몇 개로 중간 결과를 남겨 두면 문제가 어느 단계에서 막히는지 분명히 볼 수 있다.

특히 여러 배치의 문서를 처리할 때 다수의 기업이 이미 AIAgent를 사용하기 시작했으며, 이때 우수한 제품을 선택하는 것이 특히 중요해졌다.

현재 TextIn xParse는 이미 상용 Agent들에 두루 포진해 있다. 예를 들어 더우바오, WorkBuddy 등에는 공식 제공 대응 플러그인이 있어, 사용할 때 바로 검색해 플러그인을 추가해 사용할 수 있으므로 일반 사용자에게도 매우 편리하다.

呆呆敲代码的小Y

公众号：呆呆敲代码的小Y

171

文章

381k

阅读

418

粉丝