요약 SUMMARY
용어 표준화와 문서 품질 관리 구조로 전환한 사례를 다룹니다.
AI 자동화를 반복 작업 대체가 아닌 업무 기준과 운영 방식의 재설계 관점에서 정리합니다.
#Claude #ClaudeSkill #TechnicalWriter #기술문서자동화 #용어표준화
들어가며 — 왜 용어는 항상 틀릴까
프론트엔드 개발을 하다 보면 누구나 한 번쯤은 비슷한 경험을 한다.
분명 같은 기능을 구현했는데도, 화면마다 용어가 다르고, 리뷰를 할 때마다 기준이 달라진다.
어떤 화면에서는 “삭제”라고 되어 있고, 다른 화면에서는 “삭제하기”라고 되어 있다.
어떤 서비스에서는 “Server”를 사용하고, 어떤 곳에서는 “서버”라고 표기한다.
심지어 “생성중”과 “생성 중” 같은 사소한 띄어쓰기조차 통일되지 않는다.
이 문제는 단순히 표기 실수나 리뷰 누락의 문제가 아니다.
조금 더 구조적으로 바라보면, 이 현상 뒤에는 하나의 공통된 원인이 존재한다.
용어는 규칙으로 관리되지 않고, 사람의 기억과 경험에 의존하고 있다.
이 구조에서는 아무리 숙련된 리뷰어가 참여하더라도 결국 한계에 도달할 수밖에 없다.
서비스가 늘어나고 화면 수가 증가할수록, 사람의 인지 능력으로 유지할 수 있는 일관성에는 분명한 한계가 있기 때문이다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/boE8AR/dJMcagT8vZr/AAAAAAAAAAAAAAAAAAAAAEwMlOaa4rRaCoSDu53zGKRm4wYLare8j1KntRo6BPsM/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=TI1lRhRAw3pyHgBmoSWtjH%2FVko0%3D)
문제 정의 — Technical Writer 업무는 왜 병목이 되는가
이 문제를 해결하기 위해 먼저 기존의 용어 관리 프로세스를 다시 살펴봤다.
일반적인 흐름은 다음과 같다.
UIUX 담당자들이 Figma 문서를 배포하면, Technical Writer가 각 화면을 기반으로 용어를 추출하고,
전사 용어 가이드를 참고해 이를 표준화한다. 이후 개발자가 해당 용어를 코드에 반영한다.
이 과정은 겉으로 보기에는 합리적인 협업 구조처럼 보인다.
하지만 실제로 운영해 보면 몇 가지 문제가 반복적으로 발생한다.
우선 Figma와 코드, 그리고 문서를 계속 오가며 비교해야 하기 때문에 컨텍스트 스위칭 비용이 높다.
또한 동일한 작업이 반복되면서 생산성이 떨어지고, 무엇보다 중요한 기준이 문서가 아니라 사람의 머릿속에 존재한다는 점이 문제다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/erxbDs/dJMcagT8vZu/AAAAAAAAAAAAAAAAAAAAAFWEOBGJNQDBb0Qlu1JNXKTskuukAWf7wviQuuO2PZLN/img.jpg?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=0tGww0wxAfeDQCAg%2BYTww40nITg%3D)
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/vWE8Z/dJMcagT8vZw/AAAAAAAAAAAAAAAAAAAAAFJsVvTUbd1qQ1vHRl5_-J-DzQSc3yPiBAMsI8DNOgK6/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=QQ%2FBe%2FbWzRExDLxPP0jwdhArlrE%3D)
이 구조의 가장 큰 문제는 단순한 비효율이 아니라 확장 불가능성이다.
실제로 데이터를 기반으로 분석해보면 그 이유는 더욱 명확해진다.
25개 서비스, 728개의 화면을 기준으로 분석했을 때
총 11,961개의 용어가 존재했고, 그 중 고유 용어만 3,473개에 달했다
이 정도 규모가 되면 더 이상 사람이 일관성을 유지하면서 관리할 수 있는 영역이 아니다.
즉, 문제의 본질은 “용어가 많다”는 것이 아니라,
사람이 관리해야 하는 구조 자체가 잘못되어 있다는 것이다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/dohyPp/dJMb99N8Is5/AAAAAAAAAAAAAAAAAAAAAK_--nO6exmhSI1y9Zb7ITlguo6HnxDgAlWFWR3naZLX/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=qC0ljMJ1rNoXOSA0Bf8i7zEMwII%3D)
용어의 수와 중복률을 통해 문제의 규모를 데이터로 확인
접근 전환 — 문서를 데이터로 바라보는 순간
이 문제를 해결하기 위해 가장 먼저 바꾼 것은 도구가 아니라 관점이었다.
기존에는 문서를 사람이 읽고 이해해야 하는 대상으로 봤다면,
이제는 문서를 구조화 가능한 데이터로 보기 시작했다.
이 작은 관점의 변화는 생각보다 큰 구조적 변화를 만들어낸다.
문서를 데이터로 보기 시작하는 순간,
용어 추출은 사람이 화면을 보며 찾는 작업이 아니라 구조를 파싱하는 작업으로 바뀌고,
용어 수정은 감각이나 경험에 의존한 판단이 아니라 규칙 기반 처리로 전환된다.
즉, Technical Writer의 업무는 더 이상 “문서를 다루는 작업”이 아니라
데이터를 처리하는 문제로 재정의된다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/coQjYl/dJMb99N8Is7/AAAAAAAAAAAAAAAAAAAAANqQQu4oMKnJzUAmOu-0q9tJmc7TJFiN7gUyyHq1ZSYk/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=0qn608mV4BWdhBUv8sCAlufK9qA%3D)
Figma 문서를 구조화된 데이터로 변환하는 흐름
실행 구조 — Technical Writer Agent의 등장
이러한 관점 전환 이후, Technical Writer의 역할도 자연스럽게 변화한다.
기존에는 용어를 직접 작성하고 수정하는 역할이었다면,
이제는 용어를 생성하고 변환하는 규칙을 정의하는 역할로 바뀐다.
실제 실행은 사람이 아니라 Agent가 수행한다.
Figma에서 UI 데이터를 추출하면, Agent가 해당 데이터를 기반으로 용어를 수집하고,
정의된 정책을 적용해 표준화하며, 규칙에 맞지 않는 부분을 자동으로 탐지한다.
더 나아가 기존 정책으로 설명되지 않는 패턴을 발견하면,
그 자체를 새로운 정책 후보로 제안하기도 한다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/c0s6L3/dJMb99N8Is8/AAAAAAAAAAAAAAAAAAAAAAQ8s2zZ71elno8WFibnw6KJ9zcblw-0Z_P3oKO_atgo/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=XUWc5yFFjmBxs0gmmO2qyslsuQY%3D)
이 구조에서 중요한 점은 단순히 자동화가 이루어졌다는 것이 아니다.
사람이 하던 일을 대신 수행하는 것이 아니라,
업무 자체가 실행 가능한 구조로 재설계되었다는 점이다.
Skill 구조 — 정책을 코드로 만든다는 의미
이 프로젝트의 핵심은 Technical Writer 업무를 Skill로 전환한 것이다.
기존에는 용어 표기 가이드나 띄어쓰기 규칙이 문서 형태로 존재했고,
사람이 이를 참고하여 수작업으로 적용했다.
하지만 이 구조에서는 그 가이드를 그대로 두지 않는다.
실행 가능한 형태로 변환하여 Agent가 직접 적용하도록 만든다.
예를 들어, “생성중”이라는 표현은 자동으로 “생성 중”으로 변환되고,
“Server”는 “서버”로 통일된다.
이러한 규칙은 사람이 기억하거나 판단할 필요 없이,
Skill로 정의되어 일관되게 적용된다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/bYNbDy/dJMcagT8vZA/AAAAAAAAAAAAAAAAAAAAANCOeWSOmOa69O37UMDqZ3uIVhs78cremVE9YxuqyzaZ/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=CApmwiseeTTJaNm%2BpK42LSSwOek%3D)
용어 표준화가 사람의 판단이 아닌 규칙 기반 실행으로 전환된 사례
이렇게 되면 더 이상 “이게 맞는 표현인가?”를 고민할 필요가 없다.
모든 결과는 동일한 규칙에 의해 생성되기 때문이다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/bVQC2H/dJMb99N8Ita/AAAAAAAAAAAAAAAAAAAAAIc7KbBUblpm4XcGG-okMJHNw4k7-xB754cLSOJ-cSyi/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=DTyVCv4NmNSIsSK6A7gdK6NIzoU%3D)
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/diRvre/dJMcajb93ql/AAAAAAAAAAAAAAAAAAAAALoWcJbeGvvXObq6Dgqy16_ZHaJJfkX0dKj0zXXRNenf/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=SomJEl6DzdnZk2fjag%2B5yfS%2Bsr8%3D)
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/dRTLur/dJMb99N8Itf/AAAAAAAAAAAAAAAAAAAAAL3srkiZpNz2OrqRpS_Kh4hBgN7mxSDXfGE_6k7zgirj/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=slvWm8EqEFy8THtJqVSlQK%2FciRM%3D)
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/dqvnGh/dJMcagT8vZD/AAAAAAAAAAAAAAAAAAAAALDWMc-FrnDZVICcsxhxpwvZM1Zk_IDz4chf9a_xnWU0/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=HNO2%2B%2FI86nbafKnZT0GdHFrnZU0%3D)
정의되지 않은 패턴까지 탐지하고 정책 개선을 제안하는 구조
여기서 중요한 점은 Skill이 단순한 프롬프트가 아니라는 것이다.
Skill은 사람이 수행하던 판단을 대체하는
실행 가능한 업무 로직이다.
자동화 범위 — 어디까지 가능한가
실제 스킬화를 통해 확인한 결과, 자동화 범위는 예상보다 훨씬 넓었다.
용어 추출, 표준화, 정책 분석뿐 아니라
개발 코드 반영과 Figma 문서 업데이트까지 대부분의 단계가 자동화 가능했다.
이는 기존 6단계로 구성된 프로세스 중 대부분이 자동화 대상이라는 의미다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/4QcFW/dJMcajb93qs/AAAAAAAAAAAAAAAAAAAAAKUkFkfJ13oGtqVO61-CLR_7cPUSId118yh0lQ-QK8z2/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=0%2FecpEbr6bftd5cFXJkcRT4Vd74%3D)
기존 수작업 프로세스와 자동화 구조의 차이
이 결과는 단순한 효율 개선을 넘어선다.
효과 — 단순한 효율이 아닌 구조의 변화
자동화 이후 가장 눈에 띄는 변화는 시간 단축이다.
기존에는 용어 추출에 하루, 표준화에 수일이 걸렸던 작업이
모두 1시간 이내로 수행되며, 전체 작업이 반나절 수준으로 줄어든다.
![[AI활용] Claude 실무편 - Technical Writer Skill 만들기](https://blog.kakaocdn.net/dna/bDx44T/dJMcajb93qv/AAAAAAAAAAAAAAAAAAAAAOX2gafdJ2RSkszibpfRBRn2nAXELciawpfT9Jz9PHFG/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1788188399&allow_ip=&allow_referer=&signature=rfvsgSgwq2wnLnihkolJwfLFBZs%3D)
시간 단축뿐 아니라 작업 구조 자체가 변화한 결과
핵심 인사이트 — Technical Writing을 실행 가능한 구조로 전환한다는 것
이 사례를 통해 얻은 가장 중요한 결론은 단순하다.
Technical Writer의 역할이 사라진 것이 아니라,
그 역할을 구성하고 있던 반복 작업과 규칙 기반 업무가
보다 효율적인 방식으로 재구성되었다는 점이다.
기존에는 용어를 추출하고, 비교하고, 수정하는 과정이
사람의 경험과 반복 작업에 의존했다면,
이제는 그 과정을 정책 기반으로 정의하고,
AI가 일관되게 실행하도록 만들 수 있게 되었다.
그 결과, Technical Writer는 단순한 작업 수행자가 아니라
용어 정책을 설계하고 품질 기준을 정의하는 역할에 더 집중할 수 있게 된다.
결론 — AI는 생산성을 증폭시키는 구조로 활용된다

AI를 도입한다는 것은 단순히 새로운 도구를 사용하는 것이 아니다.
기존의 업무를 그대로 둔 채 자동화하는 것이 아니라,
업무를 더 효율적으로 수행할 수 있도록 구조를 재정의하는 과정이다.
이번 Technical Writer Skill화 사례는
AI를 통해 생산성과 업무 효율성을 어떻게 실질적으로 개선할 수 있는지를 보여준다.
특히 이 구조는 특정 개인이나 팀에 국한되지 않는다.
향후에는 Claude Plugin 형태로 확장하여
다양한 구성원이 동일한 정책과 기준을 기반으로
용어 검수 및 표준화 작업을 수행할 수 있도록 발전시킬 수 있다.
이를 통해 조직 전체의 문서 품질과 개발 일관성을 동시에 향상시키는 것이 가능해진다.
이번 작업은 단순한 기술 구현이 아니라, 용어 표준화라는 조직 공통 과제를 함께 풀어가는 과정이었다. Cloud상품기획1팀의 권새하님과의 협업을 통해 기존 용어 정책을 정리하고, 이를 실행 가능한 구조로 전환하는 방향을 함께 설계할 수 있었다. 기획과 개발이 같은 문제를 바라보고 해결해 나간 의미 있는 경험이었다.
자주 묻는 질문 FAQ
'Tech Story > etc.' 카테고리의 다른 글
| [AI활용] AI가 코딩하고, kt cloud AI NEXUS로 AI 서비스를 배포한다 (0) | 2026.08.06 |
|---|---|
| [도입전략] 공공 AI 전환을 위한 AX Readiness Check 활용법 (0) | 2026.07.09 |
| [AI활용] AI 에이전트의 안전벨트, 하네스 엔지니어링: Claude Code와 Terraform 사례 (0) | 2026.07.03 |
| [트렌드 리포트] 2026 상반기 트렌드 결산: AI 활용부터 인프라 전환까지 (0) | 2026.06.22 |
| [설계가이드] Terraform 모듈 설계, 원칙 없이 만들면 반드시 무너진다 (0) | 2026.06.01 |