자동화 작업을 하다 보면 어느 순간 ‘검증’이라는 말이 자꾸 늘어납니다. 빌드 검증, 서버 상태 검증, 배포 전 검증, 데이터 검증. 비개발자인 제 눈에는 처음엔 전부 비슷해 보였습니다. 그래서 이번에는 AI에게 물었습니다. 검증 관련 스킬이 여러 개 있는데, 혹시 중복 아니냐고요.
처음에는 파일 이름만 보고 정리하면 될 줄 알았습니다. 그런데 AI와 함께 들여다보니 문제는 이름의 개수가 아니었습니다. 각각 언제 불려야 하는지, 어디에 있어야 하는지, 같은 행동을 다른 말로 반복하고 있지는 않은지가 더 중요했습니다.
막힌 지점 1: 이름이 비슷하면 중복처럼 보인다
먼저 이름에 verify가 들어간 스킬들을 확인했습니다. 하나는 코드 변경 후 커밋하고 푸시하기 전까지의 절차였습니다. 실제 쿼리 재현, 빌드, git diff 확인, 커밋과 푸시로 이어지는 ‘출고 전 확인표’에 가까웠습니다.
다른 하나는 운영 중인 동기화 서버의 상태를 확인하는 절차였습니다. PM2 프로세스가 살아 있는지, 로그에 오류가 없는지, 헬스체크가 정상인지 살펴보는 ‘운영 점검표’였습니다.
둘 다 verify라는 단어를 쓰지만, 하나는 작업물을 내보내기 전의 검증이고 다른 하나는 돌아가고 있는 서버의 건강검진이었습니다. 이름만 보고 합치면 오히려 더 위험해질 수 있겠다는 생각이 들었습니다.
막힌 지점 2: 진짜 중복은 다른 곳에 있었다
AI가 찾아낸 진짜 문제는 verify라는 이름 자체가 아니었습니다. 서버 상태를 점검하는 스킬의 내용이 이미 다른 동기화 백업 관련 스킬에 들어 있는 PM2 점검 절차와 겹치고 있었습니다.
비개발자인 저는 여기서 중요한 교훈을 얻었습니다. 중복은 파일 이름이 아니라 ‘실제로 안내하는 행동’을 기준으로 판단해야 한다는 점입니다. 같은 명령과 절차를 두 곳에서 서로 다른 깊이로 설명하면, 나중에 AI에게 “동기화 서버를 점검해줘”라고 했을 때 어느 절차를 따라야 할지 흔들릴 수 있습니다.
막힌 지점 3: 어디에 두느냐도 설계였다
또 하나 흥미로웠던 점은 위치였습니다. 운영 서버 전용으로 작성된 절차가 개인 전역 스킬 폴더에 들어가 있었습니다. 특정 프로젝트에서만 의미 있는 규칙이 개인 계정 전체에 적용되면 다른 프로젝트에서도 엉뚱하게 불릴 수 있습니다. 반대로 프로젝트의 협업 기록에는 남지 않을 수도 있습니다.
저는 그동안 ‘파일이 있으면 되는 것’ 정도로 생각했습니다. 하지만 자동화에서는 위치도 문맥이었습니다. 프로젝트용 지식은 프로젝트 안에 두고, 여러 프로젝트에 공통으로 적용할 습관만 전역에 두는 것이 맞겠다는 감이 왔습니다.
AI와 함께 정리한 방향
AI는 바로 수정하지 않고 먼저 정리 방향을 나눠서 보여줬습니다. 서버 점검 스킬은 프로젝트 수준으로 옮기고, 기존 동기화 백업 스킬에는 상세 절차를 반복하지 않고 관련 스킬을 참고하도록 연결하는 방식이었습니다. 커밋 전 검증 스킬은 목적이 다르므로 그대로 두기로 했습니다.
이 흐름이 좋았던 이유는 ‘일단 다 합쳐버리자’가 아니었기 때문입니다. 비슷한 말이 있어도 역할이 다르면 분리하고, 같은 역할을 반복하면 한곳으로 모으는 방식이었습니다. 비개발자인 저에게는 코드 정리라기보다 실제 운영 기준을 정돈하는 일처럼 느껴졌습니다.
비개발자 김부장이 배운 점
이번 작업에서 배운 것은 세 가지입니다.
첫째, 자동화 지식도 오래 두면 잡초처럼 자랍니다. 처음에는 도움이 되던 체크리스트도 비슷한 항목이 늘어나면 오히려 AI를 헷갈리게 할 수 있습니다.
둘째, ‘검증’이라는 단어 하나로 모든 절차를 묶으면 안 됩니다. 배포 전 검증, 운영 서버 점검, 데이터 동기화 확인은 목적도 다르고 실행하는 시점도 다릅니다.
셋째, AI에게 일을 맡기려면 AI가 참고하는 지식창고도 가끔 청소해야 합니다. 프롬프트를 잘 쓰는 것보다 AI가 읽을 기준서를 역할에 맞게 나눠두는 일이 더 중요할 때가 있었습니다.
다음 편에서는 이런 자동화 지식 정리가 실제 업무 화면 수정이나 배포 실수 방지와 어떻게 연결되는지도 더 적어보려고 합니다. 비개발자인 저는 아직 코드를 모두 이해하지는 못하지만, 적어도 이제는 AI가 무엇을 기준으로 판단하는지 함께 점검해야 한다는 걸 알게 됐습니다.