개발자 없이 5분 만에 버그를 고친 QA, 우리가 설계한 것과 설계하지 않은 것

부제: code-forge에서 Anvil까지, 비개발자도 쓰는 슬랙앱으로

AI 코딩 도구를 처음 써보면 대부분 비슷한 경험을 합니다. 빠르긴 한데, 그대로 쓸 수는 없습니다. 정책을 모르고, 컨벤션을 안 지키고, 같은 요청에도 매번 다른 결과가 나옵니다. 결국 사람이 하나하나 확인하고 고쳐야 해서, 빨라진 만큼 검증 비용이 따라붙습니다.

저희 회사에는 월요일마다 사내 직원들이 AI 활용 사례를 발표하는 시간이 있습니다. 광고센터에서 만들어 쓰고 있던 AI 코딩 워크플로우와 플러그인 이야기를 발표해보면 어떻겠냐는 추천을 받아 발표한 내용을 공유드리려고 합니다.

이번 글은 그 발표에서 다뤘던 내용을 정리한 것입니다. 사고 모델과 하네스 엔지니어링은 이전 두 글에서 충분히 풀어뒀으니, 이번에는 그 다음 이야기인 개인 도구가 어떻게 팀 플러그인이 되고, 결국 비개발자도 Slack에서 쓸 수 있는 앱이 됐는지를 다룹니다.

• 이전 글 1: AI 코딩 에이전트에게 사고 과정을 설계하다 — 사고 모델과 /start 워크플로우
• 이전 글 2: 프롬프트 엔지니어링은 끝났다 — 하네스 엔지니어링으로 AI 에이전트를 길들인 이야기 — 시스템 레벨에서 에이전트를 감싸는 방법

배경: 혼자 쓸 때는 잘 됐는데

못 보신 분들을 위해 정리해보겠습니다.

광고센터에서 AI 코딩 에이전트를 도입하면서, 처음엔 “코드베이스가 스승이다”라는 사고 모델을 만들었습니다.

에이전트가 코드를 먼저 읽고 기존 패턴을 따르도록 /start 워크플로우에 판단 순서를 고정한 건데, 프롬프트만으로는 한계가 있어서 hooks·권한·품질 게이트 같은 시스템 장치도 추가했습니다. 좋은 규칙을 만드는 것과 그걸 지키게 만드는 건 다른 문제였습니다.

혼자 쓸 때는 잘 작동했습니다. 반복 피드백이 줄었고, 하나의 작업을 분석부터 구현·검증까지 한 흐름으로 밀고 갈 수 있었습니다.

문제는 팀으로 확장하는 순간이었습니다. 규칙 파일을 깃에 올리고 팀원들이 각자 pull 받아 적용하는 방식으로 시작했는데, 곧바로 동기화 문제가 터졌습니다.

누군가는 최신 규칙을, 누군가는 2주 전 버전을, 누군가는 로컬에서 살짝 고쳐 자기 방식으로 유지하고 있었습니다. 정책이 바뀌면 같은 요청인데도 결과가 달라졌습니다.

이때부터 문제 정의가 바뀌었습니다. 더 좋은 프롬프트를 쓰는 게 아니라 배포 방식 자체를 바꿔야 하는 문제였습니다.

code-forge: 플러그인 하나로 팀 전체가 같은 기준으로

이 문제를 풀기 위해 code-forge라는 Claude Code 플러그인을 만들었습니다. 설치하고 /setup만 실행하면 프로젝트 스택을 자동으로 감지해서 그에 맞는 규칙을 세팅합니다.

구조는 크게 세 층으로 나뉩니다.

위험한 명령을 차단하고 코드 수정 후 lint를 자동으로 돌리는 시스템 강제 장치(Hooks) , 1편에서 설계한 사고 모델을 에이전트의 판단 순서로 녹인 AI 가이드 , 그리고 민감 파일 생성을 막는 접근 제어 . 프롬프트는 무시할 수 있어도 Hooks는 시스템이 강제하기 때문에, 에이전트가 아무리 우회하려 해도 매번 실행됩니다. (기술 상세는 2편에서 자세히 다뤘습니다.)

이렇게 바꾸자 기준이 개인 로컬 설정에서 플러그인 배포 단위로 올라왔고, “최신 버전 반영해주세요”라는 수동 작업이 사라졌습니다.

같은 프롬프트, 다른 결과

발표에서 가장 반응이 좋았던 건 데모였습니다.

같은 캠페인 등록 폼을 두 개 준비했습니다. 하나는 아무 설정 없는 base 프로젝트, 하나는 code-forge가 세팅된 프로젝트였고 동일한 요구사항을 주고 결과를 비교했습니다.

코드베이스의 다른 페이지에 “정산 규칙은 한 달 28일 기준”, “최소 주문 금액은 5만 원”이라는 정책이 이미 구현되어 있었습니다. 프롬프트에는 이 정책을 별도로 언급하지 않았습니다.

같은 프롬프트인데 환경이 다르니까 결과가 달라졌습니다. AI가 똑똑해서가 아니라, 코드베이스를 먼저 읽게 만들었느냐의 차이였습니다.

실제로 운영하면서도 차이가 느껴졌습니다.

예를 들면 광고센터 PG 연동 작업이 있었습니다.

결제 플로우는 카드/계좌이체/간편결제별로 분기가 갈리고, 각 분기마다 성공·실패·취소·환불 시나리오가 따로 존재합니다.

평소라면 QA 전에 엣지 케이스를 정리하고 그에 맞는 단위 테스트를 일일이 작성해야 하는데, code-forge가 기존 결제 정책 파일과 검증 로직을 먼저 읽고 분기별 케이스를 자동으로 도출해서 테스트로 만들어줬습니다. 사람이 놓치기 쉬운 “취소 후 재결제” 같은 케이스까지 포함되어 있었습니다.

또 하나는 광고센터 내부에 여러 벌로 나뉘어 유지보수가 어려웠던 주문서 컴포넌트들이었습니다. 캠페인 종류마다 조금씩 다른 주문서가 따로 만들어져 있어서, 정책 한 줄 바꾸려면 여러 곳을 동시에 수정해야 했습니다. code-forge에 “공통점과 차이점을 분석하고 한 벌로 합쳐달라”고 맡겼더니, 기존 코드를 전수 분석해서 공통 베이스 + 캠페인별 옵션 구조로 마이그레이션해줬습니다. 원래였으면 며칠은 잡아야 했을 작업인데, 한 흐름 안에서 끝났습니다.

그런데, 병목 발생

여기까지 오면 팀의 개발자들은 같은 기준으로 움직일 수 있습니다. 그런데 현실의 병목을 보면 다른 곳에 있었습니다.

“이거 갑자기 안 돼요”, “텍스트가 이상하게 나와요” 같은 운영 이슈가 올라왔는데, 담당 개발자가 휴가 중이거나 다른 급한 작업을 하고 있으면 5분이면 끝날 수 있는 일이 하루이틀씩 밀렸습니다.

병목은 난이도가 아니라 권한과 진입 경로에 있었습니다.

Anvil: 누구나 와서 작업할 수 있는 작업대

code-forge가 대장간 시스템이라면, Anvil은 그 위에서 누구나 작업할 수 있는 모루(작업대)입니다.

한 가지 먼저 얘기하자면, 비개발자가 코드를 만지게 하는 것 자체는 어렵지 않습니다. GitLab 권한을 열어주고 가이드 몇 줄 붙이면 됩니다.

어려운 건 그게 아니라, 누가 수정하든 일정한 코드 품질이 나오게 만드는 것이었습니다. 권한만 열면 결과물은 사람마다 들쑥날쑥해지고, 결국 그 차이를 메우는 비용이 다시 개발자에게 돌아옵니다.

AI도 마찬가지입니다. 하네스가 붙어있는 모델은 코드베이스의 규칙을 읽고 그 안에서 움직이지만, 하네스 없이 그냥 붙여놓은 모델은 어떤 사이드이펙트를 낼지 예측하기 어렵습니다. 그걸 추적해서 다시 고치는 건 결국 개발자의 몫입니다.

Anvil이 작동할 수 있었던 건 단독으로 만든 시스템이 아니라, 앞서 깐 두 단계 위에 올라탔기 때문입니다.

1편에서 설계한 사고 모델(“코드베이스가 스승이다”)과 2편에서 시스템 레벨로 감싼 하네스(hooks·권한·품질 게이트) 이 두 가지가 Anvil 안에 그대로 들어가 있어서, 작업자가 누구든 동일한 기준 위에서 코드가 만들어집니다. 비개발자한테 인터페이스를 여는 건 마지막 한 겹이고, 진짜 중요한 건 그 아래에서 품질을 잡아주는 하네스입니다.

Slack 앱으로 만든 건 비개발자가 터미널에서 일하지 않기 때문입니다. 아무리 좋은 워크플로우가 있어도 접근 가능한 인터페이스가 아니면 개발자 전용 도구로 남습니다.

코드베이스 Q&A

QA 담당자분이 비슷하지만 조금씩 다른 API 엔드포인트 여러 개가 실제로 사용 중인지, 어디에서 호출되는지 물어본 적이 있었습니다. 예전이라면 개발자가 레포를 열어 검색하고 경로를 정리해서 알려줬을 질문입니다.

개발자에게 “이거 어디서 쓰이는 거예요?”라고 물어보지 않아도 되는 구조가 된 겁니다.

티켓 분석 → 영향 범위에 따라 흐름이 나뉩니다.

“내 티켓 보여줘”라고 하면 Jira 미완료 목록을 가져오고, 티켓을 선택하면 어떤 파일이 영향을 받는지, 정책 변경 가능성이 있는지 먼저 분석합니다.

여기서 흐름이 나뉩니다. 단순 수정이면 바로 구현 플로우로, 정책이나 코어 로직에 닿는 작업이면 담당 개발자에게 승인 요청이 갑니다.

[단순 작업] 문구 수정, UI 위치 변경
  → 바로 구현 → 품질 게이트 → 배포 요청 → 개발자 MR 리뷰

[정책/코어 변경] 정책 상수, 검증 규칙, 코어 로직
  → 담당 개발자 확인 요청 → 승인 → 구현 → 품질 게이트 → MR 리뷰

중요한 건 두 가지입니다.

하나, 누가 시작하든 내부적으로는 같은 사고 모델과 품질 게이트를 탄다는 점입니다. Anvil은 별개의 새 시스템이 아니라 code-forge 위에 Slack 인터페이스를 얹은 형태라서, 작업자가 개발자든 QA든 기획자든 코드가 통과해야 하는 검문소는 동일합니다. 바깥 인터페이스만 달라졌을 뿐, 코드 품질 기준은 개발자가 직접 작업할 때와 같습니다.

둘, 최종 머지 판단은 항상 개발자가 합니다. 모든 병목이 나쁜 건 아닙니다. 반드시 사람이 봐야 하는 지점을 남겨둬야, 나머지 부분을 더 넓게 열 수 있습니다.

실제로 쓰는 사람이 생기니까 보이는 것들

Anvil을 실제로 돌리면서 예상 못 한 문제들이 바로바로 터졌습니다. Jira 상태 전환에서 부분 매칭 버그가 나왔고, 레포 자동 판별이 안 되는 케이스도 있었고, 브랜치 전략도 실제 워크플로우에 맞게 바꿔야 했습니다. 이런 건 설계할 때는 예측하기 어려운 것들이었습니다. 실제로 쓰는 사람이 생기니까 비로소 보이는 문제들이었습니다.

발표 이후, “우리도 쓸 수 있나요?”

사내 발표에서 이 내용을 공유했는데, 질문이 “AI가 얼마나 똑똑한가”보다 “이걸 실제 업무에 어떻게 붙일 수 있는가”에 집중되어 있었습니다.

“우리 프로젝트에도 code-forge를 붙일 수 있나요?”

“기획자나 QA도 Slack에서 바로 물어보고 처리할 수 있나요?”

“어디까지 자동으로 해도 되고, 어디부터 승인이 필요한가요?”

역할별로 기대하는 지점이 달랐습니다

기획자: “개발자에게 물어보기 전에 내가 먼저 확인할 수 있는 범위가 어디까지인지”에 관심이 컸습니다. 정책 문서와 코드베이스를 같이 읽어서 답해주는 Q&A, 티켓 영향 범위 분석, 간단한 수정 요청 흐름에 반응이 강했습니다.

추가적으로 개발 전 기획을 실제 화면을 구현해보면서 체크해 볼 수 있는지에 대한 아이디어도 나왔습니다.

디자이너: 이미 한 분은 GTM 관련 코드를 직접 Claude로 짜서 가져온 적이 있었습니다. “내가 생각한 인터랙션이나 트래킹 변경을 직접 실험해볼 수 있는가”에 대한 기대가 있었습니다.

QA: 가장 즉각적으로 반응한 그룹이었습니다. 특정 API, 문구, 버튼 조건이 실제로 어느 화면에서 쓰이는지 빠르게 물어보고 영향 범위를 파악할 수 있다는 점이, 매일 하는 업무와 가장 가까웠기 때문입니다.

개발자에게는 구현 가속 도구로 보였고, 비개발자에게는 개발자에게 묻기 전에 먼저 탐색하고 움직일 수 있게 해주는 인터페이스로 보였습니다.

사진 : 개발의 경계가 흐려진다 개발의 경계가 흐려진다

다른 프로젝트에서도 써보기 시작했습니다

발표 이후 가장 의미 있었던 변화는, 다른 팀에서도 도입을 시작했다는 점입니다. 그중에는 이미 상용 배포까지 마친 사례도 있습니다.

그중에서도 통합어드민 가격최적화 스쿼드 애쉬 사례가 기억에 남습니다.

통합 어드민 가격 최적화 대시보드 신규 필드 추가 작업을 Anvil로 직접 진행했고, Slack DM으로 애쉬 혼자 시작한 작업이 영향 범위 분석 → 코드 수정 → MR 생성(코드리뷰, 검증) → 배포 요청까지 한 흐름으로 이어져 개발자 없이 상용 환경까지 배포가 완료됐습니다. 광고센터 외부 스쿼드에서 Anvil로 시작된 작업이 상용까지 통과한 첫 사례였습니다.

코드수정완료 알림과 코어로직 수정 시 담당개발자에게 수정 요청이 오는 앤빌 캡쳐

코드 수정 후 MR 생성 시 프로세스 및 코드리뷰 결과 포함 dev/stage MR 생성 담당자에게 알림 캡쳐

이게 가능했던 건 code-forge가 플러그인이라서 도입 장벽이 낮았기 때문입니다.

설치하고 cms 레포에서 /setup만 실행하면 그 프로젝트의 스택을 자동으로 감지해서 그에 맞는 모듈만 골라 입혀줍니다. React인지 Next.js Pages인지 App Router인지, 상태관리는 Jotai인지 Zustand인지, 스타일링은 Emotion인지 Tailwind인지, 프로젝트마다 스택은 다 다른데, 3층 구조의 프레임은 그대로 가져가면서 스택 모듈만 갈아 끼우는 구조라서 가능했습니다. 스택뿐 아니라 기존 코드베이스의 컨벤션도 분석해서 반영하기 때문에, 새로 도입한 프로젝트에서도 코드 품질의 일관성을 유지할 수 있습니다.

물론 모든 프로젝트가 처음부터 잘 맞은 건 아닙니다. 모노레포에서는 워크스페이스마다 스택이 다른 경우가 많아서 /setup이 잡아내는 범위를 조정해야 했고, 사내 백엔드 컨벤션이 강한 곳에서는 그 컨벤션에 맞는 모듈을 새로 추가해야 했습니다. 다만 이런 보강은 한 프로젝트에서 한 번 해두면 다음 프로젝트부터는 그대로 재사용됐습니다. 그러다 보니 적용하는 프로젝트가 늘수록 다음 도입이 쉬워지는 구조가 되고 있습니다.

지금은 어디까지 왔나

지금까지의 흐름을 정리하면 다섯 단계였습니다.

각 단계에서 풀어야 할 문제의 종류가 완전히 달랐습니다.

혼자 쓸 때는 “AI가 더 잘 따르게 만들기”가 문제였습니다. 팀으로 넓히면서는 “팀 전체가 같은 기준으로 움직이게 만들기”가 고민이었고, 비개발자까지 열 때는 “안전하게 열면서도 진짜 쓸모 있게 만들기”를 풀어야 했습니다.

답도 달랐습니다. 사고 모델로는 개인 품질을 올렸고, 플러그인으로는 팀의 기준을 맞췄고, Slack 앱으로는 진입 장벽을 없앴습니다. 그리고 모든 단계에서 공통으로 필요했던 건 열어주되, 어디를 잠가둘지 먼저 설계하는 것이었습니다.

좀 더 길게 보면 이런 방향도 생각하고 있습니다. 지금은 제가 주로 쓰는 모델과 광고센터 코드베이스 위에서 하네스가 잡혀 돌아가지만, 하네스 자체가 충분히 단단해진 다음에는 모델을 갈아 끼울 수 있어야 한다고 생각하고 있습니다. Gemini를 비롯한 다른 모델까지 지원해서, 누구든 자기 환경을 Slack에 연결하기만 하면 동일한 코드 품질을 받을 수 있는 구조, 하네스를 잘 잡아두면, 그 안에서 어떤 모델을 쓰든 일관된 품질이 나온다는 게 다음 단계의 목표입니다.

마무리

AI를 도입하는 많은 팀이 “어떤 모델을 쓸까”에서 출발합니다. 하지만 실제로 팀의 일하는 방식을 바꾸려면, 모델 선택보다 그 모델이 돌아가는 환경을 설계하는 게 더 중요했습니다.

디자이너분이 자기 손으로 트래킹 코드를 짜서 가져오고, QA분이 Slack에서 API 사용처를 바로 확인하고, 다른 스쿼드 팀원이 직접 필드를 추가해 상용까지 배포했습니다. 누가 시킨 게 아니라 도구가 열려 있으니까 자연스럽게 일어난 일이었습니다.

AI가 코드를 수정하는 시대에, 개발자가 할 일이 줄어드는 게 아니라 종류가 바뀐다고 생각합니다.

코드를 직접 치는 시간은 줄어들겠지만, 사고 모델을 만들고 하네스를 구성하고 정책을 코드베이스에 녹여두는 일은 오히려 더 중요해집니다. 그냥 권한을 여는 게 아니라, 누가 작업하든 일정한 품질이 나오는 환경을 먼저 만드는 것. 그게 앞으로 개발자에게 더 많이 요구될 역할이라고 생각합니다.

백오피스웹개발팀에서 이런 변화를 먼저 시작하고 있습니다. 관심 있으신 분들은 편하게 연락주세요.