Claude Skill로 기술 문서 용어를 자동화한 사례

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

kt cloud는 Claude Skill을 활용해 Technical Writer의 용어 관리 업무를 사람의 기억과 반복 검수 중심 구조에서 정책 기반 실행 구조로 바꿨습니다. 25개 서비스와 728개 화면에서 11,961개 용어와 3,473개 고유 용어가 확인된 상황에서 Figma UI 데이터를 구조화하고, Agent가 용어 추출·표준화·예외 탐지·정책 후보 제안을 수행하도록 연결했습니다. “생성중”을 “생성 중”으로, “Server”를 “서버”로 바꾸는 규칙을 Skill에 담아 반복 적용했으며, 용어 추출과 표준화는 각각 하루와 수일에서 1시간 이내로 줄고 전체 작업은 반나절 수준이 됐습니다. 이에 따라 Technical Writer는 직접 문구를 고치는 업무보다 용어 정책과 품질 기준을 설계하고 예외를 관리하는 데 집중하는 역할로 이동합니다.

섹션별 상세

화면과 서비스가 늘어날수록 같은 기능이 “삭제”와 “삭제하기”, “Server”와 “서버”, “생성중”과 “생성 중”처럼 서로 다르게 표기되는 문제가 누적됩니다. 기존에는 용어 기준이 문서보다 사람의 기억과 경험에 의존했기 때문에 Figma, 코드, 문서를 오가며 리뷰할수록 컨텍스트 스위칭과 반복 작업이 커졌습니다. 25개 서비스와 728개 화면에서 11,961개 용어와 3,473개 고유 용어가 확인되면서, 문제의 핵심이 용어의 양보다 사람 중심 관리 구조의 확장성 부족에 있다는 판단으로 이어졌습니다.

서비스 A와 서비스 B가 같은 삭제 기능을 각각 “삭제”와 “삭제하기”로 표기한 사례를 비교한 다이어그램입니다. — Diagram이미지는 동일한 기능의 동작이 서비스마다 다른 동사 표현으로 기록되는 문제를 시각화합니다. 글에서 말하는 용어 정책의 부재가 UI 문구의 일관성 저하로 이어지고, Skill이 이런 표기 차이를 규칙 기반으로 통일해야 하는 이유와 직접 연결됩니다.

근거

25개 서비스와 728개 화면에서 11,961개 용어와 3,473개 고유 용어가 확인됐다. — 본문의 ‘문제 정의 — Technical Writer 업무는 왜 병목이 되는가’와 용어 분석 리포트 이미지 설명

문서를 사람이 읽고 판단하는 대상으로 두지 않고 구조화 가능한 데이터로 바꾸면서 Technical Writer 업무의 입력과 처리 방식이 달라졌습니다. Figma의 UI 데이터를 추출하면 용어 수집이 화면을 눈으로 확인하는 작업에서 데이터 파싱으로 전환되고, 이후 표준화와 예외 탐지는 명시된 정책에 따라 처리됩니다. 이 접근은 용어 관리의 기준을 개인의 감각에서 규칙과 데이터로 옮겨 서비스와 화면이 늘어날 때도 동일한 처리 흐름을 유지하려는 구조입니다.

기존 Technical Writer 프로세스를 UI 문서 배포, 용어 추출, 용어 표준화, 정책 고도화, 개발 적용, UI 문서 현행화의 6단계로 나타낸 흐름도입니다. — Diagram각 단계마다 UIUX 디자이너, Technical Writer, FE 개발자가 수작업을 수행하고, 시간 소요와 휴먼 에러, 반복 작업, 품질 편차, 문서·코드 불일치가 발생하는 구조를 함께 제시합니다. 글에서 자동화 대상이 기존 6단계 대부분으로 확대된 배경과 수작업 프로세스의 병목을 시각적으로 뒷받침합니다.

Technical Writer Agent는 Figma에서 추출한 UI 데이터를 입력으로 받아 용어를 모으고, 정의된 정책을 적용해 표준화한 뒤 규칙에 맞지 않는 항목을 찾아냅니다. 기존 정책으로 설명되지 않는 패턴이 발견되면 새로운 정책 후보를 제안해 정책 개선의 입력으로 되돌립니다. 따라서 Technical Writer는 문구를 매번 직접 수정하는 역할에서 용어 정책과 품질 기준을 설계하고 예외를 관리하는 역할로 이동합니다.

화이트보드에 UI 문서와 Technical Writer Agent의 업무 흐름으로 보이는 메모와 연결선이 기록되어 있습니다. — Photo화이트보드에는 UI 문서, FE, TW, Agent, 콘솔과 관련된 작업 흐름이 손글씨로 배치되어 있어 기획·개발·문서화 작업을 연결하려는 설계 과정을 나타냅니다. 세부 글씨는 일부 판독이 어렵지만, 사람이 반복 수행하던 문서 업무를 Agent 중심의 실행 흐름으로 재구성했다는 본문의 내용과 관련됩니다.

근거

Figma UI 데이터를 추출한 뒤 Agent가 용어 수집, 정책 적용, 표준화, 예외 탐지를 수행하고 새로운 정책 후보를 제안한다. — 본문의 ‘실행 구조 — Technical Writer Agent의 등장’ 단락과 Technical Writer Agent 전체 흐름 이미지

이 프로젝트는 용어 가이드와 띄어쓰기 규칙을 참고용 문서로 남기는 대신 Agent가 실행할 수 있는 Skill로 변환했습니다. 그 결과 “생성중”은 “생성 중”으로, “Server”는 “서버”로 자동 통일되며 용어 추출과 표준화뿐 아니라 정책 분석, 개발 코드 반영, Figma 문서 업데이트까지 기존 6단계 프로세스의 대부분을 자동화 대상으로 삼을 수 있었습니다. 프롬프트를 매번 작성하는 일회성 요청과 달리 Skill은 동일한 정책을 반복 적용하므로 결과의 일관성과 재현성을 높이는 기반이 됩니다.

근거

‘생성중’은 ‘생성 중’으로, ‘Server’는 ‘서버’로 Skill 규칙에 따라 자동 변환된다. — 본문의 ‘Skill 구조 — 정책을 코드로 만든다는 의미’ 단락과 용어 표준화 전후 비교 이미지

자동화 전에는 용어 추출에 하루, 표준화에 수일이 걸렸지만 자동화 후에는 두 작업이 모두 1시간 이내에 수행되고 전체 작업은 반나절 수준으로 줄었습니다. 시간 단축은 단순히 사람이 하던 단계를 빠르게 처리한 결과가 아니라, 정책을 코드와 유사한 실행 로직으로 바꾸고 Agent가 추출부터 반영까지 연결한 데서 나왔습니다. 이 구조를 Claude Plugin 형태로 확장하면 여러 구성원이 같은 정책과 기준으로 용어 검수와 표준화를 수행할 수 있어 조직 단위의 문서 품질 관리로 이어질 수 있습니다.

용어 해설

Technical Writer: — 기술 문서와 제품 화면에 쓰이는 용어를 추출하고 표준화하며 품질을 관리하는 역할입니다. 이 글에서는 사람이 직접 문구를 고치는 방식에서 벗어나 용어 정책을 실행 가능한 Skill로 바꾸고, Agent가 반복 작업을 수행하도록 업무 구조를 재설계하는 핵심 주체로 다뤄집니다.
Agent: — 입력 데이터를 바탕으로 정해진 정책을 적용하고 여러 단계를 연속 실행하는 소프트웨어 구조입니다. 이 글의 Technical Writer Agent는 Figma에서 UI 데이터를 추출한 뒤 용어를 수집하고 표준화하며, 기존 정책으로 설명되지 않는 패턴을 찾아 새로운 정책 후보까지 제안합니다.
Skill: — 사람이 수행하던 판단과 작업 절차를 재사용 가능한 실행 규칙으로 정의한 구조입니다. 글에서는 용어 가이드와 띄어쓰기 규칙을 문서로 남겨두는 대신 Agent가 직접 적용할 수 있는 형태로 변환해, 같은 입력에 일관되고 재현 가능한 결과를 만드는 방식으로 사용합니다.
컨텍스트 스위칭(Context Switching): — 작업자가 서로 다른 도구나 정보 사이를 오가며 작업 맥락을 바꾸는 데 드는 비용입니다. 기존 프로세스에서는 Figma, 코드, 문서를 반복해서 비교해야 했고, 이 전환이 용어 표준화와 검수 업무의 생산성을 낮추는 병목으로 작용했습니다.
Figma: — UI 화면을 설계하고 문서화하는 협업 도구입니다. 기존 흐름에서는 Figma 문서를 사람이 읽고 용어를 추출했지만, 개선된 구조에서는 UI 데이터를 구조화해 Agent의 용어 수집과 정책 적용을 위한 입력으로 활용합니다.

기술

Claude
Claude Skill
Figma
Agent
Claude Plugin

활용 사례

Figma UI 문서의 용어 추출과 표준화
기술 문서와 개발 코드의 용어 일관성 검수
띄어쓰기와 한글·영문 표기 규칙의 자동 적용
정의되지 않은 용어 패턴 탐지와 정책 후보 생성
개발 코드 반영과 Figma 문서 업데이트 자동화