에이전트에게 일 맡겨보기

올해 3월 크리에이터 멤버십 프로젝트를 맡아 고객이 상품을 살펴보고 결제하는 서비스와 상품·주문을 관리하는 어드민의 프론트엔드 구현을 담당하게 되었다. 구독형(정기 결제)과 세션형(단건 결제) 상품의 결제·환불 흐름을 다루는 일이었다. 기존 상품과 다른 서비스여서 처음부터 만들어야 했다.

카드 결제 심사 일정에 맞춰 6월 24일에 배포해야 했다. 준비할 화면은 고객 서비스 20개, 어드민 34개, 주어진 일정은 근무일로 약 75일이었다.
일정이 빠듯하여 처음에는 이런 생각을 했다.

AI를 최대한 돌리면 일정 안에 가능하겠지..? 🧑‍🏭

기능 구현을 AI가 하게 되면서, 나는 일하는 방식을 생각해 볼 수 있게 되었다.
기획서를 읽고 티켓을 만들고, 구현이 끝나면 QA와 배포를 진행했다. 매번 비슷한 형태였으니 스킬 또는 자동화를 만들어 볼 수 있지 않을까 싶었다.

구현 전에 정한 것들#

에이전트에게 여러 화면을 맡겨도 데이터 변경과 API 호출 방식은 일정했으면 했다. 코드의 구조부터 정해 뒀다.

• 앱 초기 스캐폴딩, 디렉토리 구조·코딩 컨벤션 설계 및 에이전트용 작업 규칙 문서화
• 고객 앱의 데이터 변경을 Server Action 기반으로 구성
• 서비스 화면 데이터 조회 시 React Server Components(RSC) 사용
• 댓글·좋아요에 서버 응답 전 화면을 갱신하는 낙관적 업데이트 적용
• 백엔드 OpenAPI 명세를 SSOT로 삼아 orval로 어드민의 타입·API 클라이언트 생성

멤버십이 나중에 별도 서비스로 분리될 가능성도 있어, 초기 설계에서는 Next.js 멀티존으로 앱을 나누는 방안을 검토했다. 다만 당시 필요한 범위에 비해 구조가 복잡해진다고 판단해 도입하지 않았다.

반복하던 작업을 스킬로 만들기#

개발과 QA·운영에서 반복하던 절차를 스킬로 정리해, 프로젝트에 맞는 작업 하네스를 구성했다. 각 스킬에는 참고 문서와 작업 순서, 완료 조건을 적었다.

스킬은 필요할 때 불러 썼고, QA에서 수정할 일이 생기면 작업 시작과 마무리를 반복했다. 계획 검토와 배포처럼 내 확인이 필요한 단계에서는 멈추고, 확인을 받은 뒤 다음 작업을 진행하도록 했다.

1. 기획 문서 확인 (/spec)#

/spec으로 피그마에서 읽을 화면을 정하면, 화면별 에이전트가 병렬로 동작과 상태를 정리한다. 시안만으로 알 수 없는 동작이나 정책은 질문 목록으로 따로 뽑게 했다. 이 단계에서는 문서만 만들고, 내가 읽고 확인한 뒤에 다음 단계로 넘겼다.

2. 기능을 티켓으로 나누기 (/backlog)#

/backlog는 기획 문서와 기능 목록으로 티켓과 일정 초안을 만든다. 범위와 일정은 내가 확인한 뒤에 티켓을 생성하게 했다. 규칙이 빠지지 않도록 도메인별로 작업을 나눴다.

3. 작업 시작 준비 (/start)#

티켓에 연결된 피그마 자료를 읽고 작업 계획을 로그로 남긴다. 재개된 작업은 이전 로그부터 읽어 맥락을 이어가게 했다.
담당자를 확인한 뒤 티켓을 진행 상태로 바꾸고, 다른 사람의 티켓일 경우 확인을 먼저 받는다. 새 기능은 계획이 티켓 범위에 맞는지 검토한 뒤 구현에 들어간다.

4. 구현과 작업 마무리 (/done)#

/done은 해당 티켓의 변경을 커밋하고, 테스트를 통과해야 PR을 만든다. 열린 PR이 있으면 재사용한다.
티켓은 해결 상태로 바꾸고, 작업 로그에는 결과와 남은 일을 적게 했다.
개발을 마친 것과 QA를 통과해 최종 완료한 것은 구분했다.

5. 개발 환경에 배포하기 (/deploy)#

/deploy는 배포할 앱과 환경, 코드 버전을 먼저 보여 준다. 공유 환경이라 내가 확인한 뒤에야 배포를 실행하고, 결과까지 추적하게 했다.

6. QA 전에 테스트 케이스 확인하기 (/tc)#

QA에 넘기기 전에는 QA가 시트에 작성한 테스트 케이스(TC)의 기대 결과를 따라 한 번 더 테스트했다.

• 로직·컴포넌트는 Vitest로 검증
• 화면 흐름은 Playwright와 ego-browser로 검증
• 필요한 테스트 데이터는 TablePlus MCP로 준비
• 시각 확인·실결제·외부 연동은 수동 검증

자동 테스트에는 TC 번호를 적어 원본과 연결했고, 케이스가 많으면 범위부터 정했다.

7. QA 티켓 확인과 수정 (/qa-sweep)#

/qa-sweep은 시작할 때 내 확인을 받고, QA 티켓의 하위 작업을 한 시간 간격으로 살피게 했다. 프론트엔드 작업이 분명한 티켓만 할당하고, 애매하면 프론트엔드와 API 저장소를 함께 읽게 했다. 그래도 판단하기 어려운 건 내가 확인하도록 남겼다.

처음 정한 자동 수정 범위 안의 작은 작업은 /start → 수정 → /done으로 이어 갔다. 여러 건이면 한 건씩 처리하고, 재개된 티켓은 로그와 QA 실패 사유를 읽어 기존 브랜치에서 이어 갔다. 배포를 확인한 뒤 티켓을 QA 대기 상태로 바꾸게 했다. QA를 통과하면 완료하고, 실패하면 재개 사유에 따라 다시 작업했다.

8. 제품 릴리즈 준비하기 (/release)#

/release는 아직 배포되지 않은 변경을 티켓 상태·릴리즈 버전과 대조하고, 포함 여부를 확인해야 하는 작업을 따로 추린다. 내가 포함할 변경을 정하면 그에 맞춰 배포 변경 목록을 작성하게 했다.

믿음 vs 판단#

자동 수정 범위를 정하면서 아직 AI에 대한 믿음이 부족해서인지, 직접 판단할 일도 같이 정리했다.

• 백엔드 작업이거나 소관이 불분명한 티켓은 검토 대기로 남겼다.
• 재개 사유나 재현 정보가 부족한 QA 티켓도 검토 대기로 남겼다.
• 수정할 파일이 다섯 개를 넘거나 공용 컴포넌트·결제 로직을 건드리면 멈추도록 했다.
• 테스트 실패 원인을 한 차례 고친 뒤에도 통과하지 못하면 내가 다시 살폈다.
• 같은 티켓이 두 차례 연속 재개된 경우도 내가 다시 살폈다.

결제·정원·환불은 사용자의 돈과 운영 기준에 영향을 주는 만큼, 합의한 내용을 직접 확인했다.

QA 티켓 수치로 살펴보기#

고객 서비스와 어드민에서 내 담당 QA 티켓은 116건이었다. 버그 외에 디자인 수정과 추가 요구도 섞여 있어, 실제 내용을 기준으로 나눠 봤다.

기획과 다르게 동작하거나 저장된 기능 버그가 59건, 크기·색·정렬 등의 디자인 불일치가 20건으로, 구현 이슈는 총 79건이었다. 지라의 Defect 타입에도 개선 요청이 섞여 있어, 티켓 유형만으로 집계한 값과는 차이가 있다.

어드민은 별도 디자인 시안 없이 shadcn/ui로 구성했다. 그래서 디자인 불일치를 고객 서비스와 같은 기준으로 비교하기는 어렵다. 😪

이전 작업인 포트폴리오와 비교해 보기#

이전에 만들었던 포트폴리오는 어땠을까 싶어 기록을 나란히 놓아 봤다. 어드민을 제외한, 각 고객 서비스의 신규 구현에 대한 1차 QA만 비교했다. 코드량도 QA 당시를 기준으로 잡았다.

화면 코드량은 멤버십이 약 2.5배였다. 내 담당 Defect 티켓은 31건과 34건으로 비슷했지만 코드 1,000줄당 티켓은 약 8.5건에서 3.7건으로 줄었다. 구현 규모가 커졌는데도 QA 티켓 수는 크게 늘지 않았고 오히려 코드 대비 티켓 밀도는 낮아졌다.

프로젝트의 기능과 QA 기간이 달라 이 차이가 전부 일하는 방식 덕분이라고 단정하기는 어렵다. 그래도 이 기록으로 확인되는 것은 두 가지다.

• 처리량: 비교한 고객 서비스만 해도 화면 코드가 약 2.5배였다. 여기에 어드민까지 더해 화면 54개를 약 75일 안에 만들었고, 6월 24일 배포 일정을 맞췄다.
• 품질: 1차 QA에서 코드 1,000줄당 결함 티켓은 약 8.5건에서 3.7건으로, 절반 아래로 줄었다.

이전에는 기능을 많이 만들수록 QA도 함께 늘어났다. 그런데 이번에는 코드가 2.5배로 늘었는데도 QA 티켓은 31건에서 34건으로 거의 늘지 않았다. 어떻게 이게 가능했을까? 그 이유로 이번에 달라진 두 가지를 꼽는다. 하나는 스킬로 절차를 고정해, 모든 티켓이 같은 순서와 완료 조건을 거치게 한 것이다. 다른 하나는 QA에 넘기기 전에 TC의 기대 결과로 먼저 검증한 것이다. 단순히 코드 레벨 테스트뿐 아니라 에이전트가 브라우저를 제어하는 방식을 사용한 것도 효과를 봤다. 이러한 방식이 생산성과 품질 향상에 도움을 줬다고 생각한다.

멤버십을 만들고 나서#

처음 멤버십을 맡았을 때는 '이걸 혼자서 어떻게 하라는 거지' 싶었다. 설계부터 고객 서비스, 어드민까지 짧은 기간 안에 많은 양을 다 만들어야 한다니 솔직히 화가 좀 났다.

그러다 이왕 이렇게 된 거, AI를 최대한 써보자는 생각이 들었다. 화면 구현뿐 아니라 기획 정리, 작업 분할, 테스트와 QA까지 전부 맡겨 봤다. 예전에도 AI를 쓰긴 했지만 그냥 해달라고 던지는 식이어서 일정 부담은 그대로였다. 이번에는 반복되는 절차를 스킬로 만들고, 일을 맡긴 뒤 무엇을 확인할지, QA에서 다시 열린 작업은 어디서부터 이어갈지까지 정해 뒀다. 그 덕분에 매번 다음에 뭘 할지 고민하는 부담과 일정 압박이 많이 줄었다.

이런 과정을 겪게 되니 이제 일정을 맞추지 못할 거라는 생각이 전혀 들지 않게 되더라. 오히려 다 할 수 있을 거란 자신감이 생겼다. 온종일 AI한테 질문하고 구현해 달라고 하는 과정 속에 살고 있는데, 그래도 어떤 부분에서 인간의 판단이 필요할지 알 수 있는 계기가 되었다. 사실 이런 인간의 판단이 필요 없어질 시기가 코앞인 거 같긴 하지만.. 🫠

내가 적용한 방식도 곧 레거시가 되겠지만, 한 번도 생각해 보지 않았던 일하는 방식 자체를 고민할 수 있어서 정말 좋은 경험이었다. 생각보다 일하는 과정이 단순해서 놀라기도 했다.

AI에 대한 믿음이 더 확고해지고, 이제 앞으로 뭐 하지?라는 고민은 여전하지만 AI를 열심히 굴리다 보면 어떤 답이 나오겠지 하며, 너무 고민에 매몰되지 않기로 하자!