2025년 AI를 활용한 업무 효율화 시도와 시행착오

2025년은 동료들의 퇴사로 인한 인력 부족과 사내 AI 도입 분위기 속에서, 여러모로 업무 효율을 고민하던 시기였다.

그중 의미 있는 성과를 보았거나, 아직 효용성을 검토 중인 주요 항목을 기록으로 남긴다.

1. Jira 이슈 업데이트 Slack 웹훅 알림
2. 문서 체인지로그 자동화
3. Confluence API 스크립트를 활용한 페이지 대량 수정
4. AI를 활용한 서비스 문서 작성

1. Jira 이슈 업데이트 Slack 웹훅 알림

배경

매달 서비스 정기 배포를 준비하며 Jira 티켓을 참고해 주요 배포 스펙과 문서 수정 내역을 정리한다.

다만 개발 스펙 마감일 이후, 또는 배포 내역을 한 차례 정리한 이후에도 배포 스펙과 Jira 티켓이 추가로 생성되는 경우가 많았다.

Jira 티켓의 Linked Issues 목록에서 추가되거나 빠진 항목이 있는지 직접 비교하는 과정이 번거롭고 비효율적이라고 느꼈다.

그래서 티켓이 추가될 때 Slack 웹훅으로 알림을 받아보도록 했다.

사용 도구

ChatGPT로 Python 스크립트를 생성했다.

알림 메시지 형식에 하이퍼링크를 추가하고, 기존 Linked Issues 목록과 새로 받아온 목록을 비교하는 캐싱 로직을 추가하는 등 요구사항을 여러 차례 보완해 반영했다.

적용 방법

하나의 Jira 티켓 Key를 기준으로 새 티켓이 link될 경우, New linked issue detected: [{issue-key}]() issue title 형식으로 Slack 알림이 오도록 했다.

간략한 적용 방법은 다음과 같다.

1. 웹훅 알림을 받을 채널 생성
2. 채널 앱으로 Slack 웹훅 추가
3. Python 스크립트에 Jira 토큰과 티켓 Key 입력 후 저장
4. macOS crontab을 사용해 주기적으로 스크립트를 실행하도록 설정

결과/코멘트

• 개발자가 티켓 링크를 누락하지 않는 이상, 스펙 누락이 확실히 줄었다.
• 매달 잘 활용하고 있다. 다만 delink된 이슈는 직접 찾아야 하는 점이 아쉽다.
• 매월 정기 배포 스펙이 연결된 Jira 티켓 Key를 스크립트에서 직접 수정해야 하는 번거로움이 있다.

2. 문서 체인지로그 자동화

배경

전체 문서의 수정 이력을 체인지로그 파일(.md)로 관리하고 있다.

| 날짜(yyyy.mm.dd.) | 변경 유형(신규, 업데이트, 삭제) | 수정 내용 | 문서 링크 | 형태의 마크다운 표로 요약해 기재하는데, 문서를 수정할 때마다 변경 사항을 직접 작성하고 상대 경로 링크를 하나하나 복사하는 과정이 번거롭게 느껴졌다.

사용 도구

ChatGPT에 요구사항과 상세 배경을 전달해 스크립트를 제작했다.

적용 방법

체인지로그 자동화 스크립트는 두 차례에 걸쳐 개선했다.

첫 번째로, 스테이징 또는 커밋 내역을 기준으로 날짜, 변경 유형, 문서 링크를 자동 추출하는 Bash 스크립트를 만들었다. 스크립트 실행 후 터미널에서 {수정 내용}을 입력하면, 마크다운 테이블 row가 체인지로그 파일에 추가되는 형태였다.

하지만 터미널에서 한글 입력 시 글자가 밀리거나 누락되는 문제가 있어, 체인지로그 파일에서 추가 수정이 필요했다.

그래서 두 번째로 OpenAI API를 활용해 프롬프트를 전달하고, git diff 내역을 자동 요약하도록 개선했다. 당시 팀에서 다른 업무로 OpenAI API를 이미 활용하고 있었기 때문에 Azure 계정과 리소스를 비교적 수월하게 생성할 수 있었다.

기존 커밋의 diff 내역을 토대로 AI 생성 요약본과 직접 작성 요약본을 비교하며 테스트했고, 프롬프트도 여러 차례 수정하여 아래와 같이 정리했다.

`PROMPT="다음은 개발자 문서에서 재생성된 file diff입니다. \
체인지로그에 기록할 내용을 150자 이내로 요약해 주세요. \
우리 팀의 체인지로그는 다음과 같은 스타일로 작성됩니다:
예시: 지급 처리 하지 않았던 결제 처리 건에 처리가 필요하다는 내용과 복구 처리 시 최대 10초의 딜레이가 발생할 수 있다는 내용을 업데이트하였습니다.
스타일 지침:
명확하고 간결한 문장으로 작성해 주세요.
존댓말은 사용하지 마세요.
의미 중심으로 요약하되, 실제 문서 변경 내용을 빠짐없이 반영해 주세요.

아래 file diff를 참고하여 동일한 스타일로 요약해 주세요:
${DIFF}"`

결과/코멘트

테크니컬 라이터 Tom Johnson의 블로그 아티클 Using file diffs for better release notes in reference docs를 읽고 시도해 본 개선 작업이었다.

해당 스크립트는 현재까지도 매우 잘 사용하고 있으며, 리소스를 효과적으로 절감할 수 있었다. 정기적으로 가이드 배포 내역을 정리하는 작업 시간이 약 2시간에서 30분 안팎으로 크게 단축되었다.

또한 AI 생성 요약이 직접 작성한 요약보다 상세하여 변경점 파악이 수월했고, 톤도 더 일관되게 유지할 수 있었다.

동일한 문서 수정에 대한 요약 비교 예시는 아래와 같다.

• AI 자동 요약: Unity용 {서비스 이름} 문서가 C# 기반 구조로 전환되었으며, 예제 코드, API 설명, 오류 코드, 링크 등이 Unity 기준으로 수정되었습니다. Unreal 문서도 일부 표현을 통일하고 정리했습니다.
• 직접 작성 요약: Unity API에 Unreal 내용이 기재된 오류를 수정하였습니다.

현재는 스크립트만 원격 저장소에 업로드하고, OpenAI 리소스 환경변수 파일은 로컬에서 관리하고 있다. 다만 활용하는 사람이 점차 늘어나면서, 환경변수 파일도 원격 저장소에서 함께 관리할지 고민 중이다.

3. Confluence API 스크립트를 활용한 페이지 대량 수정

배경

리브랜딩으로 유저 콘솔 명칭이 변경되어, 기존 가이드에 표기된 콘솔 이름을 텍스트 치환해야 했다.

예전 같으면 모든 Confluence 페이지를 일일이 조회해 직접 업데이트했겠지만, 대상 범위가 약 500페이지로 너무 많았고 단순 작업에 투입되는 리소스가 아까웠다. 직전에 Confluence API로 페이지 생성 테스트를 해본 경험이 있어 이를 활용해 보기로 했다.

사용 도구

Gemini에 요구사항을 전달해 스크립트를 제작했다.

적용 방법

모든 페이지를 한 번에 업데이트하는 것은 리스크와 부하가 있을 것으로 우려했다. (수정 결과 검토도 필요했기 때문이다.)

따라서 Confluence 페이지가 ID를 가진다는 점, 그리고 콘솔 가이드가 “메뉴 카테고리 페이지 > 상세 가이드 페이지” 구조를 가진다는 점에 착안해 카테고리 단위로 업데이트하도록 스크립트를 구성했다.

생성한 스크립트는 다음 기능을 포함한다.

• 치환 대상 기존 UI 용어(OLD_UI_TERM)와 신규 UI 용어(NEW_UI_TERM) 및 최상위 페이지 ID 입력
• 최상위 페이지 ID를 기준으로 하위 계층의 모든 페이지를 Confluence API로 조회해 OLD_UI_TERM 검색
• 해당 페이지에 기존 용어가 있는 경우 업데이트
• 업데이트된 페이지 제목 반환

결과/코멘트

약 500페이지 규모의 대량 수정 작업을 효율적으로 진행할 수 있었다.

2024년 서비스 리브랜딩으로 유사한 업무를 수행했을 때는 4명이 약 10일간 작업했으나, 이번에는 Confluence API 스크립트를 활용해 혼자 약 7일 만에 완료했다. (수정 작업뿐 아니라 확인 사항을 팀 내부 또는 기획자와 논의한 기간도 포함한다.)

다만 이 스크립트를 다른 업무에도 재활용할 수 있을지는 아직 확신이 없다.

4. AI를 활용한 서비스 문서 작성과 관리

배경

아직 진행 중인 R&D로, 여러모로 고민하며 시도해 보고 있다. 사람들이 AI를 가장 많이 활용하는 분야 중 하나가 문서 작성인 만큼, 이런 상황에서 테크니컬 라이터로서 할 수 있는 역할이 무엇인지 고민하게 된다.

두려워만 할 수는 없어서, 이것저것 시도해 보며 실마리를 찾아가는 중이다.

사용 도구

ChatGPT, Gemini, Gemini Code Assist, Notion AI를 활용했다.

전사적으로 Gemini 사용이 권장되어 현재는 주로 Gemini를 사용한다.

적용 방법

문서 작성 단계를 기획 > 구조화 > 작성 > 검토 > 배포의 5단계로 나눴을 때, 현재 시도해 본 분야는 다음과 같다.

• 작성: 기획서, 개발 문서 등 소스 자료를 기반으로 초안 생성
• 작성: 개발자 체인지로그를 릴리즈 노트 포맷 및 톤앤매너에 맞게 변환
• 작성: 서비스 담당자가 작성한 초안을 TW가 설계한 문서 구조에 맞게 분리
• 배포: Markdown 스타일 가이드를 기반으로 문서 서식 적용
• 배포: 비어 있는 상대 경로 자동 채우기
• 기타: 용어집에 들어갈 용어 수집 자동화

결과/코멘트

아직 완전 자동화는 어렵고, 결국 손이 많이 간다. ㅠㅠ

또한 AI 활용이 작업 단위로 쪼개져 있고, 하나의 연속적인 프로세스로 이어지지 못하는 점이 아쉽다.

총평

AI를 사용하며 느낀 점을 나열해 보면 다음과 같다.

• 남들이 AI를 어떻게 활용하는지 사례를 인풋으로 넣어야 나도 아이디어를 얻을 수 있다. Tom Johnson 블로그에서 많은 아이디어를 얻었다. ㅠㅠ
• 내 프롬프트가 부족한 탓인지 대화가 길어지고 컨텍스트가 많아지면 최초 요구사항이 누락되는 경우를 종종 발견했다. 코드 예제까지 임의로 수정해 버리는 경우가 있어, AI 생성 결과물은 반드시 오류나 의도치 않은 변경이 없는지 검토해야 했다. 다만 그 결과물을 제대로 검토하려면 내가 소스 자료를 상세히 파악하고, 서비스와 기능을 정확히 이해하고 있어야 한다.
• 최근 회의에 참석하며, 사내에서 기술 문서를 유저가 직접 읽고 따라 하기 위한 목적보다 AI 학습에 활용하기 쉬운 작업물로 보려는 니즈가 커지고 있음을 느꼈다. 앞으로 문서는 LLM이나 챗봇 학습용으로 더 많이 활용될 것이고, 컨텍스트나 소스 자료로 쓰기 좋은 형태로 작성되어야 한다고 어렴풋이 생각해 왔다. 그런데 사실 LLM이 가장 잘 이해할 수 있는 형태는 LLM이 쓴 작업물이 아닐까 하는 생각도 든다. AI가 쓴 콘텐츠만 넘쳐나는 세상이 될 수도 있고.
• AI에게 단순히 문서 작성을 맡기기보다는, 테크니컬 라이터 역할 중 내가 좋아하고 몰입하는 영역과 단순 반복 작업을 분리해 전자에 더 집중하고, 후자는 AI로 개선하는 방향이 가장 이상적이라고 느낀다.

올해는 새로운 조직으로 이동하면서 다른 조직과 문서 작업을 나누게 되었다. 담당 서비스가 줄어든 만큼 다른 영역에 집중해 볼 수 있지 않을까 생각한다.

한편 해당 조직에서 가이드 배포 자동화 시스템을 고민 중이다.

나는 뭘 하지? 계속 테크니컬 라이터를 할 수 있을까?

재밌는 거 하고 싶다.