Claude Code Skill을 활용한 레거시 백오피스 툴 개선기: 엑셀 한 행 붙여넣기로 16개 언어 완성

요즘 코딩 에이전트 이야기가 나오면 꼭 Skill 이야기가 뒤따른다. 실제 업무에 적용해보려고 우리 팀이 쓰는 백오피스 툴에 Claude Code의 Skill을 가볍게 써봤다. 그 경험을 공유하면서 Skill을 어디에, 어떻게 쓰면 좋을지 이야기해보려 한다.

우리 팀은 게임 이벤트 페이지를 개발한다. 이벤트를 운영하다 보면 크고 작은 수정이 계속 생긴다.

이벤트가 상용 환경에 오픈된 뒤 가장 자주 고치는 항목은 필독사항과 이벤트 기간이다. 두 항목은 CDN에서 관리되는데, 별도 코드 핫픽스 없이도 운영할 수 있도록 툴을 만들어 협업하는 비개발 직군 팀이 직접 편집하게 해왔다.

지원 언어가 많은 게임일수록 이 작업은 번거로워진다. 컴투스의 인기 게임 서머너즈 워: 천공의 아레나는 16개 언어를 지원한다. 사업·기획 담당자는 16개 언어의 문구를 언어별로 하나씩 CKEditor에 붙여넣으며 편집해왔다. 이 과정에서 마크업 구조가 어긋나면 태그가 깨지거나 링크가 빠져 페이지가 깨질 수 있었고, 그럴 때는 웹 개발자가 핫픽스로 대응하기도 했다.

처음 툴을 만들 때는 기획자가 HTML 태그를 몰라도 위지윅(WYSIWYG) 편집기로 안전하게 문구를 넣을 수 있도록 CKEditor를 택한 것이 합리적인 선택이었을 것이다. 하지만 게임마다 요구사항이 달라지고, 일하는 방식도 시간이 지나며 바뀌기 마련이다.

이런 구조에서는 문제가 생겼을 때 책임이 편집자에게 돌아가기 쉽다. 개발자들도 리팩토링이 필요하다는 것은 알지만, 이런 서브 툴은 늘 업데이트 우선순위에서 밀린다.

이번에는 Claude Code의 Skill을 활용해 CKEditor 기반 편집 방식을 하루 만에 새로 짤 수 있었다. 그 과정에서 겪은 일을 차례로 정리해본다.

새 편집기의 첫 결과물은 CKEditor를 대체할 LangRowEditor였다. 우리 팀의 로컬라이제이션 결과물은 엑셀 파일로 관리되고, 한 행에 16개 언어 문구가 나란히 들어 있다. LangRowEditor는 이 행을 복사해 한 번 붙여넣으면 언어별 입력 필드가 자동으로 채워지는 편집기다.

작업에는 Claude Code 자체 기능 외에 플러그인 두 개를 함께 썼다. 하나는 시각 디자인 방향을 잡아주는 frontend-design 플러그인이다. 색이나 여백을 임의로 고르는 대신 플러그인이 다양한 스타일을 제안해줘서, 입맛에 맞는 안을 고르기만 하면 됐다.

다른 하나는 superpowers 플러그인이다. 여러 Skill을 묶어놓은 패키지로, 브레인스토밍부터 스펙 작성, 계획 수립, 실행, PR 생성까지 이어지는 워크플로를 따르도록 강제한다. 기능 하나를 붙일 때마다 “왜 이걸 하는지”와 “무엇은 건드리지 않는지(비목표)”를 먼저 스펙 문서로 정리하고, 그다음 실행 계획을 세운 뒤 마지막에 PR로 마무리하는 순서다. 덕분에 레거시 코드에 즉흥적으로 손대지 않고, 매번 변경 범위를 문서로 남기며 진행할 수 있었다.

AI가 유효했던 지점

스파게티 코드로 얽힌 레거시 뷰 파일이었지만, Claude Code는 문제없이 모던한 스타일의 새 UI를 완성했다. 엑셀 붙여넣기, 클립보드 파싱, 언어별 필드 매핑으로 이어지는 반복 로직도 초안 단계에서 빠르게 뽑아냈다.

작업 히스토리가 잘 남아 있지 않거나 담당자가 부재해도 문제없었다. Claude와 함께 코드를 추론하며 스냅샷을 남기고 md 파일을 잘 관리하면 개선과 롤백에 부담이 없다. superpowers처럼 이미 완성된 플러그인을 쓰면 브레인스토밍도 쉽다.

사람이 개입해야 했던 지점

첫 구현은 큰 틀에서는 동작했지만 샌드박스 검증만으로는 부족했다. 테스트 시나리오를 자세히 주지 않으면 놓치는 버그가 있었다. 드롭다운에서 항목을 선택하기만 해도 폼이 초기화되는 문제처럼, 화면을 직접 띄워봐야만 재현되는 종류였다. 언어별 편집칸을 가로 스크롤로 바꾸거나 불필요한 수정 배지를 없애는 UX 조정도 사람이 판단해야 했다.

일부 버그는 도메인 지식 없이는 AI가 스스로 짚어낼 수 없었다. “이벤트가 실제로 지원하지 않는 언어는 표시하지 않는다”가 그 예다. 이 시스템에서 언어 지원 여부가 어떻게 결정되는지 아는 사람이 문제를 정의해줘야 AI가 고칠 수 있었다.

이런 경험을 반영해 피드백 루프를 계속 개선한 뒤로는 사람이 직접 확인해야 하는 경우가 눈에 띄게 줄었다.

새 편집기는 마크업 구조를 보존하고, 붙여넣기에서 생기는 여러 케이스에 대응하도록 만들었다. 그동안 “사람이 잘못 붙여넣었다”로 처리되던 케이스를 이제는 시스템이 직접 받아낸다.

중첩된 태그, 주석 처리된 옛날 코드, 화면에 보이지 않는 숨김 필드, 언어 하나가 블록 두 개로 나뉜 경우처럼 실제 마크업에서 나올 수 있는 변형을 하나씩 확인하며 반영했다. 실제 엑셀에서 복사한 내용이 어떤 형태로 들어오는지를 기준으로 설계하자, 편집자 책임으로 넘어가던 문제 상당수가 애초에 발생하지 않게 됐다.

플러그인 설치부터 개발 완료와 자체 리뷰까지 걸린 시간은 몇 시간에 불과했다.

Skill은 기능 추가에만 쓸 수 있을까?

그렇지 않다. 팀에 커밋 규칙이 있다면 commit-message 스킬을 하나 만들고, description에 언제 이 스킬을 써야 하는지 트리거 기준만 적어두면 된다. 그러면 팀원 누구든 그 규칙을 자동으로 따르게 할 수 있다.

Skill을 어디에 쓸지 정하려면 먼저 CLAUDE.md와 Skill이 각각 언제 읽히는지 알아야 한다. 두 방식의 차이는 다음과 같다.

Skill 개념을 이해하고 나서, 커밋 전에 특정 메서드를 호출했는지 강제하는 것처럼 결정론적으로 판단할 수 있는 체크는 처음부터 Skill 대상에서 뺐다. 이런 체크는 SonarQube 같은 정적 분석 도구가 이미 잘하는 영역이다.

“AI assistants can be inconsistent, but static code analysis is deterministic.”

– Sonar, AI Code Review –

AI 어시스턴트의 판단은 일관되지 않을 수 있지만, 정적 분석은 같은 코드에 언제나 같은 결과를 낸다는 뜻이다. 반면 AI 기반 Skill은 사람이 Claude에게 작업을 맡겨야 작동하고, 판단이 매번 같다는 보장이 없으며, 호출할 때마다 비용이 든다. 정적 분석으로 해결할 수 있는 영역까지 Skill로 끌어올 이유는 없었다.

대신 Skill은 “이 처리가 이 맥락에서 충분한가”처럼 판단이 필요한 지점에만 붙였다. 이 경계는 레거시 코드베이스에서도 유효했다. 존재 여부처럼 기계적으로 판단할 수 있는 체크는 정적 분석에 맡기고, 맥락을 읽어야 하는 부분에만 AI를 투입하는 식으로 역할을 나눴다.

이 경계를 정할 때 출발점으로 삼은 것은 andrej-karpathy-skills다. 이 글을 쓰는 시점 기준 GitHub에서 19만 개에 가까운 star를 받은, 요즘 꽤 유명한 규칙 모음이다. 이전 컴투스온 기사에서도 언급된 적 있는 안드레이 카파시(Andrej Karpathy)가 X(옛 트위터)에 남긴 ‘LLM이 코딩할 때 흔히 저지르는 실수’에 대한 관찰을 바탕으로 만들어졌다. 가정하지 말고 확인할 것, 요청받지 않은 기능은 만들지 말 것, 요청한 부분만 정확히 건드릴 것 같은 원칙을 담고 있다.

여러 도구의 데이터를 한데 모아 써야 하는 상황이었다면 MCP(Model Context Protocol) 도입도 검토해볼 만했다. 하지만 지금 단계에서는 그 정도 확장성이 필요하지 않다고 판단해 제외했고, Skill만으로 충분했다.

이렇게 기준을 정리하고 나니 백오피스 툴에서 얻은 경험을 실제 업무의 메인 레포지토리에도 편하게 가져갈 수 있었다.

이번 작업에서 가장 즐거웠던 점은 효율적으로 고민한 끝에 짧은 시간 안에 유의미한 결과까지 얻어냈다는 것이다.

그동안은 전역 규칙인 CLAUDE.md를 공유하고 대화하며 코딩하는 게 전부였다. 이제는 작업별 절차를 Skill로 만들어 체계적으로 관리할 수 있게 돼 만족스럽다.

어디에 AI를 쓰고 어디에 쓰지 않을지 고민하고, 그 결과를 우리 팀 Skill에 꾸준히 정리해나가는 일은 팀원 한 명을 레벨업시키는 것과 비슷하지 않을까?

Anthropic이 Skill을 처음 선보인 지도 어느덧 1년이 지났고, 우리 팀의 작업 방식도 조금씩 달라져왔다. 아직 Skill을 써보지 않았다면 반복되는 작은 업무 하나부터 맡겨보자. 생각보다 빨리 다음 업무에도 적용할 방법을 찾게 될 것이다.