AI 개발 에이전트는 “수정했습니다”, “테스트를 통과했습니다”라고 말할 수 있습니다. 하지만 이 문장은 배포 가능한 상태를 증명하지 않습니다. 어떤 요구사항을 해석했는지, 어떤 파일을 바꿨는지, 어떤 테스트가 실제로 실행됐는지, 예외와 보안 영향은 확인했는지가 함께 남아야 합니다.
Superpowers는 테스트 주도 개발, 코드 리뷰, 완료 전 검증을 별도 스킬로 두고, 추측보다 검증을 우선하는 방법론을 제시합니다. 이 방식은 규제산업에만 필요한 것이 아닙니다. AI가 생산성을 높일수록 사람의 검토를 위한 증거를 더 구조적으로 남겨야 합니다.
이 글은 외부 오픈소스 프로젝트인 Superpowers의 방법론을 업무 적용 관점에서 검토한 참고 자료입니다. GXPLOUD의 자체 제품·제휴 기능을 소개하는 글이 아니며, 도구 사용만으로 개발 품질·보안·규정 준수가 보장되지는 않습니다. 실제 적용 범위와 승인 책임은 조직의 개발·보안 기준에 따라 별도로 정해야 합니다.
완료의 증거를 네 층으로 나눕니다
개발 에이전트가 만든 변경은 최소 네 종류의 증거로 확인할 수 있습니다.
| 증거 | 확인할 내용 | 대표 산출물 |
|---|---|---|
| 요구사항 증거 | 요청을 올바르게 이해했는가 | 문제 정의, 수용 기준, 변경 계획 |
| 구현 증거 | 필요한 코드·설정만 바뀌었는가 | 변경 목록, 설계 결정, 영향 범위 |
| 동작 증거 | 예상한 상황에서 실제로 동작하는가 | 단위·통합·화면·연동 테스트 결과 |
| 운영 증거 | 배포 후 되돌리고 관찰할 수 있는가 | 배포 절차, 로그·모니터링, 롤백 기준 |
빌드 통과는 동작 증거의 일부일 뿐입니다. 권한, 데이터 이전, 외부 연동, 운영 절차가 바뀌는 작업이라면 네 층을 모두 확인해야 합니다.
테스트는 ‘실행했다’가 아니라 ‘무엇을 반증했는가’로 봅니다
Superpowers가 제시하는 RED-GREEN-REFACTOR 흐름은 테스트를 구현 뒤의 장식으로 두지 않습니다. 먼저 실패하는 테스트로 기대 행동을 명확히 하고, 최소 변경으로 통과시키며, 그 뒤 구조를 다듬는 방식입니다.
이 원칙을 업무 플랫폼에 적용하면 테스트는 다음 질문에 답해야 합니다.
- 승인 권한이 없는 사용자는 결정을 확정할 수 없는가
- 반려·재제출·대리 승인 같은 예외가 정의된 흐름으로 처리되는가
- 상태 변경과 변경 근거가 함께 기록되는가
- AI가 만든 초안이 최종 승인으로 자동 전환되지 않는가
- 기존 시스템 연동이 실패했을 때 재처리·조정 경로가 있는가
테스트 수가 많아도 이 질문을 놓치면, 실제 운영에서 중요한 결함을 놓칠 수 있습니다.
에이전트에게 주는 작업 지시는 검증 기준까지 포함해야 합니다
좋지 않은 지시는 “승인 화면을 개선해 주세요”처럼 모호합니다. 검증 가능한 지시는 다음 정보를 포함합니다.
- 대상 사용자와 역할
- 변경할 업무 규칙과 예외
- 영향을 받는 데이터와 연동
- 화면 또는 API의 수용 기준
- 실행해야 할 테스트와 사람이 확인할 화면
- 완료 후 남겨야 할 변경 기록
에이전트에게도 이런 구조를 제공하면, 결과물을 생성하는 도구에서 검증 가능한 개발 작업을 수행하는 보조자로 역할이 바뀝니다.
리뷰는 두 번 나눕니다
코드 리뷰에서 모든 것을 한 번에 보려 하면 중요한 문제가 묻힙니다. Superpowers의 흐름처럼 다음 두 질문을 분리하는 편이 효과적입니다.
- 요구사항 준수: 요청한 업무 규칙과 수용 기준을 만족하는가?
- 구현 품질: 보안, 성능, 유지보수성, 테스트, 예외 처리가 충분한가?
특히 AI가 만든 변경에서는 첫 번째 질문이 중요합니다. 코드는 그럴듯해도, 처음의 업무 문제를 다른 방식으로 해석했을 수 있기 때문입니다.
배포 전에는 사람이 결정을 확인합니다
AI가 테스트·리뷰 결과를 모아 줄 수는 있지만, 배포 승인 책임까지 가져갈 수는 없습니다. 다음 조건은 사람이 확인하는 게 적절합니다.
- 권한이나 승인 규칙의 변경
- 고객·개인·민감 데이터의 처리 방식 변경
- 데이터 마이그레이션과 되돌림 계획
- 외부 시스템에 영향을 주는 연동 변경
- 규제·감사 대응에 필요한 기록의 변경
이는 에이전트를 불신해서가 아니라, 조직의 책임 구조를 보존하기 위한 설계입니다.
가상의 업무 예시: 요청 상태 연동의 수정
외부 티켓 상태를 내부 승인 안내에 반영하는 가상 변경을 놓고 보겠습니다. 에이전트의 테스트가 정상 응답만 확인했다면, 중복 웹훅·순서가 뒤바뀐 이벤트·권한 없는 요청·외부 장애가 남습니다. 검토자는 어떤 이벤트가 어떤 상태를 바꿀 수 있는지, 이미 처리한 이벤트를 어떻게 식별하는지, 실패 건을 누가 재처리하는지를 요구사항 증거로 남깁니다. 그 후 정상·중복·실패 시나리오의 실행 결과와 로그 위치를 동작·운영 증거로 묶어 배포 판단에 사용합니다.
배포 전 확인표
- 요청별 수용 기준과 예외 기준이 변경 기록에 연결되어 있다.
- 실행한 테스트의 명령, 환경, 결과와 아직 실행하지 못한 검증이 구분되어 있다.
- 권한·개인정보·외부 연동·데이터 변경 영향은 담당자가 별도로 확인했다.
- 실패를 관찰할 로그와 되돌림 판단 기준이 배포 문서에 있다.
다음 변경에서 에이전트의 완료 문구 대신 네 층의 근거를 제출 형식으로 정해 보세요. 문구 수정은 화면 확인으로 충분할 수 있지만, 승인 규칙이나 외부 연동 변경에는 권한·중복·실패 처리와 배포 뒤 관찰 방법까지 필요합니다. 증거의 양보다 변경 위험에 맞는 근거를 고르는 것이 핵심입니다.
증거는 배포 뒤에도 이어져야 합니다
배포 전 시험이 모두 통과해도 실제 입력 분포와 권한 조합은 다를 수 있습니다. 그래서 증거 중심 개발은 배포 시점에 끝나지 않습니다. 변경 식별자, 배포 버전, 관찰 기간, 확인할 오류 신호, 되돌림 기준을 연결해 둡니다. 승인 규칙 변경이라면 정상 승인 수만 보지 말고 차단돼야 할 요청이 차단됐는지, 보류 건이 대기열에 남았는지, 이력에 사유가 기록됐는지를 함께 표본 점검합니다.
가상의 웹훅 연동에서 중복 이벤트가 발견됐다고 하겠습니다. 운영자는 ‘에이전트가 테스트했다’는 설명이 아니라, 어떤 이벤트 식별자가 몇 번 들어왔고 어느 처리에서 막혔는지를 확인합니다. 중복을 막지 못했다면 영향을 받은 업무 건을 먼저 격리하고, 재처리 기준을 담당자가 승인합니다. 그 뒤 요구사항 증거에 중복·순서 역전 조건을 추가하고, 동작 시험과 운영 대시보드에 같은 식별자를 추적하는 검사를 넣습니다. 사고 기록은 개인의 실수가 아니라 다음 변경의 검증 자산이 됩니다.
| 증거 | 배포 판단에 쓰는 질문 |
|---|---|
| 요구사항 | 허용·금지 행동과 예외가 합의됐는가 |
| 변경 영향 | 데이터·권한·소비자 영향이 검토됐는가 |
| 시험 결과 | 정상·실패·중복 조건을 실제로 실행했는가 |
| 운영 관찰 | 문제를 발견하고 되돌릴 신호와 담당자가 있는가 |
완료 선언은 이 네 근거를 대체하지 않습니다. 에이전트가 생산한 결과일수록 사람은 무엇을 확인하지 못했는지도 명시적으로 남겨야 합니다.
예를 들어 배포 직전에 테스트 환경의 외부 연동이 멈췄다면, 통과하지 못한 시험을 통과한 것처럼 취급할 수 없습니다. 개발자는 검증 공백과 가능한 영향을 기록하고, 운영자는 실제 환경에서 관찰할 대체 신호를 준비하며, 책임자는 범위를 줄여 배포할지 연기할지 판단합니다. 장애가 발생하면 배포 번호와 증거 묶음을 기준으로 영향을 좁히고, 되돌린 뒤에도 어떤 요구사항이 미검증 상태였는지 회고에 반영합니다.
증거에는 대상과 생성 조건이 붙어야 합니다
화면 캡처, 테스트 통과 메시지, 리뷰 의견은 그 자체로는 강한 증거가 아닙니다. 어느 커밋과 설정을 대상으로 했는지, 누가 어떤 환경에서 실행했는지, 사용한 시험 데이터가 무엇인지 연결돼야 배포 대상과 같은 결과인지 판단할 수 있습니다. 코드가 바뀐 뒤 이전 시험 결과를 그대로 붙이거나, 개발 환경의 권한 설정으로 만든 화면을 운영 인수 근거로 쓰면 증거의 모양은 갖춰도 계보가 끊깁니다.
따라서 변경마다 하나의 식별자를 두고 요구사항, 설계 결정, 코드 버전, 시험 실행, 리뷰, 배포를 연결하는 편이 좋습니다. 모든 로그를 영구 보존하자는 뜻은 아닙니다. 위험 수준에 맞게 보존 기간과 접근 권한을 정하되, 최소한 배포 당시 어떤 근거를 보고 승인했는지는 나중에 재구성할 수 있어야 합니다. 민감 데이터가 시험 결과나 캡처에 들어가지 않도록 마스킹과 접근 제한도 증거 생성 단계에서 함께 설계합니다.
서로 모순되는 결과를 없애지 말고 판단 대상으로 올립니다
자동 시험은 통과했지만 수동 화면 확인에서 오류가 보이거나, 요구사항 리뷰는 승인됐지만 보안 검토에서 권한 누락이 발견될 수 있습니다. 이때 최신 결과 하나로 앞선 결과를 덮으면 왜 판단이 바뀌었는지 알 수 없습니다. 담당자는 증거마다 확인한 범위와 시점을 비교하고, 모순이 환경 차이·시험 데이터·구현 결함·요구사항 해석 중 어디에서 생겼는지 분류합니다. 원인이 설명되기 전에는 가장 편리한 결과를 완료 근거로 선택하지 않습니다.
가상의 승인 API 변경에서 단위 시험은 권한 없는 요청을 차단했지만 통합 시험에서는 관리용 토큰으로 모든 요청이 통과했다고 하겠습니다. 개발자는 단위 시험의 성공을 유지하면서도 실제 호출 경로의 인증 맥락이 달랐음을 기록합니다. 보안 담당자는 토큰 발급과 전달 범위를 확인하고, 제품 책임자는 영향받은 역할과 업무 건을 정합니다. 수정 후에는 동일한 호출 경로와 역할 조합으로 다시 시험하고, 이미 생성된 결과가 있다면 별도 영향 분석을 수행합니다.
운영 검증은 배포 승인 당시의 가정을 확인합니다
배포 전에 세운 가정은 실제 사용량, 데이터 분포, 외부 시스템의 응답에 따라 깨질 수 있습니다. 운영 검증 기간에는 단순 오류율뿐 아니라 이번 변경이 지켜야 했던 금지 조건과 보류 조건을 관찰합니다. 새 자동 분류가 정답을 많이 냈더라도 검토가 필요한 건을 조용히 확정했다면 성공으로 볼 수 없습니다. 운영자는 예외 대기열과 거부 로그를 보고, 현업 책임자는 표본 업무 건의 판단 근거를 확인하며, 개발자는 배포 버전과 실행 경로를 대조합니다.
문제가 확인되면 증거 묶음은 복구의 출발점이 됩니다. 어느 버전부터 오류가 생겼는지, 어떤 조건을 시험하지 못했는지, 어떤 업무 결과가 이미 확정됐는지를 구분해야 기술 롤백과 업무 정정을 따로 계획할 수 있습니다. 코드를 되돌렸다고 잘못된 승인이나 전송 결과가 자동으로 사라지지는 않습니다. 영향 건의 격리, 책임자의 재검토, 수정 결과의 확인까지 이어져야 비로소 배포 후 검증이 닫힙니다.
이 연결이 유지돼야 다음 배포의 검토자가 과거 결론을 그대로 믿지 않고, 같은 조건에서 다시 확인할 수 있습니다.
검증하지 못한 조건을 안고 배포해도 되는가
검토자는 많은 테스트 결과보다 변경 위험에 맞는 근거가 있는지 봅니다. 개발자는 실행하지 못한 시험을 숨기지 않고 제한 사항으로 기록하며, 제품 책임자는 그 공백을 안고 배포해도 되는지 판단합니다. 운영 담당자는 배포 뒤 같은 위험을 발견할 수 있는 로그와 대기열을 준비합니다. 세 역할의 결론이 다르면 가장 낙관적인 해석을 택하지 말고, 범위를 줄이거나 추가 검증을 위한 배포로 바꿔야 합니다. 증거가 부족한 상태를 명확히 말할 수 있는 것이 자동화된 개발의 신뢰를 지키는 방법입니다.