「업무 플로우 부분만 지적이 빈약하지 않나요?」——AI에게 설계서 리뷰를 부탁했을 때, 그런 경험이 없으신가요.

지난번 기사(「이 설계서, 리뷰해줘」라고 부탁했을 때 검출률 0%였던 건)에서는, 총무성의 세무 시스템 표준 사양서를 AI에게 리뷰하게 하여, 부탁하는 방식에 따라 검출률이 0%에서 86%까지 변하는 실측 데이터를 작성했습니다. 사실 그때 업무 플로우는 PDF로 전달했기 때문에, 이 「지적이 빈약한」 문제는 발생하지 않았습니다.

그 정체에 도달한 것은, 동일한 검증 도중에 다른 공개 자료를 조사하고 있었을 때입니다. 디지털청이 공개하고 있는 업무 플로우 Excel을 openpyxl(Python의 xlsx 읽기 라이브러리)로 열었더니, 셀에 들어있는 값은 단 5개뿐이었습니다. 업무의 내용 180개는 전부 「도형 (Shapes)」 안에 있었습니다.

그리고 AI는 셀의 5개만 전달되었음에도 불구하고 「리뷰했습니다」라는 얼굴로 대답합니다. 이 기사는 그 함정을 실제 공개 자료와 코드로 해부한 단독 버전입니다.

열어보니 제목밖에 없었다

주제로 삼은 것은 디지털청이 공개하고 있는 「지방공공단체 정보 시스템 공통 기능 표준 사양서」의 별지, 신청 관리 기능의 운용 플로우 Excel(20230929_policies_local_governments_common-feature-specification_outline_05.xlsx, 2026년 6월 취득)입니다. 실제 공개 자료입니다.

(검증 환경: Python + openpyxl. Claude를 사용한 실험은 브라우저 버전 claude.ai의 Pro 플랜 · Sonnet 5 · 사고 모드 최대 설정으로, 모두 2026년 6월 말~7월 초에 실시했습니다.)

import openpyxl
bw = openpyxl.load_workbook("業務フロー.xlsx")
for row in wb.active.iter_rows():
...

결과는 허탈할 정도로 심플했습니다. 업무 플로우 시트의 셀에 들어있는 값은 신청자 · 지자체 · 마이나포털 · 신청 관리 기능 · 표준 준수 시스템의 5개뿐이었습니다. 이것은 스윔레인 (Swimlane, 담당별로 나누어진 가로줄)의 제목입니다. 병합된 셀도 5개. 업무의 내용을 나타내는 단어는 셀 안에 단 하나도 없었습니다.

그렇다면 실제 업무(신청 데이터의 가져오기나 심사 결과의 연계)는 어디로 사라진 것일까요?

내용은 전부 도형 안에 있었다

Excel 파일의 정체는 ZIP 압축된 XML의 묶음입니다. 도형(텍스트 박스나 오토셰이프 (Autoshape))의 텍스트는 xl/drawings/drawing*.xml이라는, 셀의 값과는 완전히 다른 파일에 저장되어 있습니다. 이곳을 직접 전개하여 <a:t> 태그(도형 내 텍스트의 실체)를 정규 표현식으로 추출해 보았습니다.

import zipfile, re
with zipfile.ZipFile("業務フロー.xlsx") as z:
    xml = z.read("xl/drawings/drawing1.xml").decode("utf-8")
...

drawing1.xml만으로 114개. 같은 방식으로 각 시트의 drawing*.xml을 합치니 총 180개였습니다. 참고로 <a:t>는 서식의 경계마다 분할될 수 있기 때문에, 이 180이라는 숫자는 엄밀히 말하면 「도형의 수」가 아니라 「도형 내 텍스트 덩어리의 수」에 가까운 값입니다. 내용은 신청 데이터 가져오기 · 주소 번호 변환 · 형식 심사 결과 · 실질 심사 · 심사 결과 연계 · 신청 처리 상황 등록 API · 업무 DB——그야말로 업무 플로우의 본체입니다.

셀에 5개, 도형에 180개. 이 차이를 본 순간 「그럼 지적이 빈약할 수밖에 없지」라고 탄식이 나왔습니다. 복사 붙여넣기나 텍스트 읽기로 Excel을 전달하면, AI의 눈에는 제목 5개만 비치고 있었던 것입니다. 그런데도 대답은 옵니다. 내용이 전달되지 않았다는 사실을 전달한 쪽이 알아차리지 못하는 것이 가장 까다로운 부분입니다.

「MCP 서버라면 읽을 수 있지 않을까」——실측했더니 0개였다

「Excel 대응 도구를 중간에 끼워 넣으면 되지 않을까」라고 생각할지도 모릅니다. 저도 처음에는 그렇게 생각했습니다.

하지만, Excel 대응 MCP 서버(AI에게 Excel 조작을 위한 손발을 달아주기 위한 연결 규격의 서버)로서 대표적인 negokaz 씨의 excel-mcp-server(v0.12.0)로 실측해 본 결과, 제공되는 도구는 셀의 값·수식·시트·테이블 조작의 6종이었으며, 도형을 읽어오는 도구는 존재하지 않았습니다. 기본 플로우의 시트 전역을 읽게 해도, 가져온 것은 스윔레인(Swimlane) 헤더 5개뿐——openpyxl의 셀 읽기와 동일한 결과였습니다. 도형 내 텍스트 180개 중, 찾아낸 것은 0개. 도구에 도형을 읽는 입구가 없으니 당연한 결과입니다.

시사하는 바가 있는 것은, 이 서버에 Windows 한정의 「시트 스크린샷」 기능이 붙어 있다는 점입니다. 도형은 "이미지로 보여줄" 수밖에 없다는 것을 제작자도 알고 있는 것이라 생각합니다.

도형 안의 텍스트를 가져오고 싶다면, 이번 ZIP 전개(수 줄의 스크립트)가 확실합니다. 다만——텍스트를 가져올 수 있어도, 아직 부족한 것이 있습니다.

텍스트를 가져와도, 연결성이 사라진다

업무 플로우의 본질은 상자 안의 내용물뿐만 아니라 「어느 상자에서 어느 상자로」라는 연결성입니다. 화살표의 위치 관계는 Excel 내부에서 좌표 정보로 저장되어 있습니다. 텍스트만을 추출하는 방식으로는 이 좌표=연결성 정보가 통째로 누락됩니다. 180장의 포스트잇을 건네받았는데, 붙어 있던 순서만 알려주지 않는 상태와 비슷합니다.

대조 실험으로서, IPA(정보처리추진기구)가 공개하고 있는 제조업 업무 플로우 자료 「신업무 플로우(상세)」를, 이번에는 PDF 상태 그대로 Claude에게 읽게 해 보았습니다. 결과는 대조적이었습니다. 담당 레인(사업자·관계회사·당사 각 그룹)도, 8단계에 이르는 처리 흐름과 순서도, 중간의 분기점도 정확하게 읽어냈습니다. 우편·전화·이메일과 같은 연계 수단이나, 「시스템화 대상=녹색」이라는 색상 구분 범례까지 찾아냈습니다. 화살표의 방향도 색상도, 이미지로서 전달하면 살아나는 것입니다.

같은 「업무 플로우」라도, PDF(이미지로 전달)냐 텍스트 추출이냐에 따라 이 정도로 차이가 납니다.

4가지 수법 비교

결론은, 너무나 당연한 이야기지만 「흐름까지 읽게 하고 싶다면, PDF화가 가장 확실하다」입니다. 도형 안의 텍스트만이라면 ZIP 전개로 가져올 수 있지만, 화살표의 연결성은 시각 정보이므로 텍스트 추출로는 원리적으로 재현할 수 없습니다.

「Claude for Excel 공식 애드인은?」이라고 생각하는 분도 계실지 모릅니다. 2026년 7월 시점에서 모든 유료 플랜 사용자에게 정식 제공되고 있습니다만, 공식 도움말에서 언급하는 것은 셀·수식·표에 대한 질의응답이나 디버깅이며, 도형(텍스트 박스)의 읽기는 기재되어 있지 않았습니다. 도형이 전제된 업무 플로우를 읽히는 용도라면, 현재로서는 PDF화가 더 확실합니다.

후일담: AI는 스스로 "눈"으로 전환하고 있었다

흥미로운 후일담이 있습니다. 「셀에 5개밖에 없다면, 브라우저 버전의 Claude에게 전달해도 플로우를 설명할 수 없을 것이다」라고 생각하여, 동일한 Excel 파일을 그대로 전달하고 어떤 업무 흐름이 그려져 있는지 설명을 부탁해 보았습니다.

예상은 빗나갔습니다. 15분 후, 5개 레인의 구성부터 처리 순서·분기·API 명칭까지, 거의 완전한 설명이 돌아왔습니다.

정말로 파일을 읽은 것인지는 의심스러웠습니다. 처리 중에 웹 검색을 한 흔적이 있었고, 소재가 공개 자료이므로 「외부 지식으로 이야기했을」 가능성이 남아 있기 때문입니다. 그래서 도형의 문구를 딱 두 곳만 가상의 이름으로 바꾸고, 웹 검색을 끈 상태로 재시험했습니다. 결과, 그 가상의 이름을 정확히 포착하여 설명해 왔습니다. 파일을 읽고 있는 것은 확실합니다.

어떻게 읽었는가. 두 번째 답변의 서두에 이렇게 적혀 있었습니다.

「셀 자체에는 레인(Lane) 이름만 들어있었기 때문에, PDF로 변환하여 그림(Figure)으로 읽어 들였습니다」

첫 번째 처리 중에는 「SVG 도표를 구축하여 시각화」라는 표시도 나타났습니다. 읽은 경로에 대한 설명은 AI의 자기 신고이므로 어느 정도 감안하더라도, "텍스트로 읽을 수 없다는 것을 깨달으면 스스로 시각화한 뒤 '눈'으로 읽는다"라는 회피책을 자력으로 실행했다는 점은 가공의 이름을 사용한 재시험을 통해 확인되었습니다.

본문에서 내용을 해부한 지금이라면, 이 동작의 의미를 명확히 말할 수 있습니다. 셀을 읽어도 5개뿐입니다. 그래서 AI는 스스로 이미지화하는 단계로 넘어갔고, 거기에 15분이 걸린 것입니다. 처음부터 PDF로 전달했다면 그 우회 과정 자체를 생략하여 수십 초 만에 끝낼 수 있었습니다.

내일부터 할 수 있는 것

Excel의 도형(텍스트 박스·오토셰이프(AutoShape))으로 그려진 업무 플로우는 전달하기 전에 PDF로 변환한다. Excel for the web의 '인쇄' 기능을 통해 PDF로 저장하는 것만으로도 충분합니다 -
도형 안의 텍스트만 추출하면 되는 용도(검색·목록화)라면, ZIP 압축 해제 + XML 추출(위의 몇 줄 스크립트)만으로 충분합니다. Excel 대응 MCP 서버는 실측 결과 도형을 지원하지 않았습니다. 어떤 방식을 사용하더라도 화살표의 연결 관계까지는 파악되지 않는다고 간주하십시오 -
"AI에게 던졌더니 평범하게 답변이 왔다"는 것이 안전의 신호는 아닙니다. 답변이 오는 것과 내용을 제대로 읽고 있는지는 별개의 문제입니다. 업무 플로우와 같이 도표 중심의 자료에서 지적 사항의 양이 묘하게 적을 때일수록 의심하십시오

서두의 "업무 플로우에 대한 지적만 옅다"의 정체는 AI의 태만이 아니라, 셀과 도형이라는 저장 위치의 차이였습니다. 만약 지금 Excel 도형이 포함된 설계서를 그대로 AI에게 전달하고 있다면, 한 번 PDF로 변환한 뒤에 같은 질문을 해보시기 바랍니다. 지적하는 양이 아마 달라질 것입니다.

출처: 디지털청 웹사이트 「지방공공단체 정보시스템 공통기능 표준사양서」 관련 자료(신청 관리 기능의 운용 플로우) / IPA(정보처리추진기구) 공개 자료 「신 업무 플로우(상세)」. 본문에 기재한 도형 텍스트는 모두 공개 자료를 그대로 사용했습니다 (후일담의 재시험에서 사용한 2곳의 가공 이름으로의 교체는 검증 전용 복사본으로 진행하였으며, 본문의 수치·인용에는 포함되지 않았습니다).

3가지 페르소나를 통한 관점 분할 리뷰 등, 설계서 리뷰 전체의 실측(검출률 0% → 86%)은 이 기사에, 실제로 사용한 프롬프트 세트는 note의 실천 패키지에 정리해 두었습니다.

🔍 moname_ai — Claude를 본업에서 최대한 활용한 실측 기록을 쓰고 있습니다. 다음 내용은 X (@tommy_worklab)에서 확인하세요.

Discussion