AI Native 개발 체계 구축

LLM 기반 소프트웨어 개발 에이전트가 계획을 세우고 구현한 뒤 코드 리뷰·문서 갱신·E2E 검증을 거쳐 사람이 최종 승인하는 개발 파이프라인을 직접 설계·구현했습니다.

AI 협업 자동화가 커질수록 규칙, 훅과 상태 파일을 이해하는 비용도 함께 늘었습니다. 실제 사용 기록을 측정해 실패를 드러내는 검증과 사람 승인만 남기는 방향으로 단순화했습니다.

문제의 시작

기능 하나를 구현한 뒤에는 정적 검사, 단위 테스트, 문서 갱신과 비운영 환경의 화면 확인이 이어졌습니다. 이 과정이 사람의 기억과 수작업에 의존하면서 개발자마다 확인 범위가 달랐고, 코드는 바뀌었지만 스키마·API·운영 문서가 이전 상태로 남는 일이 생겼습니다. 긴 작업에서는 에이전트가 한 번 응답한 뒤 멈춰 사람이 계속 다음 단계를 지시해야 했습니다.

자동화를 붙일 대상에는 코드 생성만 있지 않았습니다. 작업을 완료 조건이 있는 계획으로 나누고, 구현 결과를 리뷰하고, 변경 종류에 맞는 문서를 갱신하고, 브라우저에서 실제 사용자 흐름을 확인한 뒤 PR 증거로 모아야 했습니다. 동시에 운영 주소에서 E2E가 실행되거나 외부 시스템의 업무·리소스를 임의로 바꾸는 위험은 차단해야 했습니다.

처음에는 이 문제를 막기 위해 종료 훅, 상태 파일, 단계별 규칙과 안전 규약을 계속 추가했습니다. 자동 반복 덕분에 한 번의 요청으로 여러 단계를 이어 갈 수 있었지만, 시간이 지나면서 상시 규칙과 리뷰 절차가 비대해졌습니다. 자동화가 무엇을 하는지 이해하고 상태 파일을 복구하는 비용이 커져, 개발보다 자동화 체계 자체를 디버깅하는 순간이 생겼습니다.

규칙을 더 추가하는 접근은 단기 실패를 막아도 모든 세션의 입력을 키우고 같은 판단을 여러 계층에서 반복하게 했습니다. 반대로 에이전트에게 완료 여부까지 맡기는 단순화는 외부 변경과 배포 판단의 안전 경계를 없앱니다. 따라서 계획·구현·리뷰·문서·E2E는 에이전트가 수행하되, 완료를 선언할 증거와 사람이 반드시 결정할 지점을 분리하는 것을 설계 원칙으로 삼았습니다.

검증 기준은 ‘에이전트가 끝났다고 말했다’가 아니었습니다. 정적 검사와 단위 테스트가 통과하는지, 변경된 화면을 허용된 비운영 환경에서 재현하는지, 코드와 관련 문서가 같은 작업에서 갱신되는지, 중단 요청·사용자 결정 대기·반복 상한에서 자동 루프가 예측 가능하게 멈추는지를 확인했습니다. 이후에는 실제 사용 기록을 바탕으로 구성 요소를 제거한 뒤에도 같은 완료 기준을 통과하는지를 비교했습니다.

계획에서 사람 승인까지

이 기준을 하나의 흐름으로 연결한 결과가 계획부터 검증 증거 작성까지는 에이전트가 수행하고, 병합과 최종 완료는 사람이 승인하는 개발 파이프라인입니다.

개발 요청을 완료 조건이 있는 계획으로 바꾸고, 에이전트가 작은 단위로 구현하도록 했습니다. 결과는 코드 리뷰와 문서 갱신, E2E 증거를 차례로 모은 뒤 사람의 승인 지점에서 멈춥니다.

이 흐름은 배포를 자동 결정하지 않습니다. 에이전트는 판단 근거를 만들고, 외부 환경을 바꾸거나 완료를 확정하는 권한은 사람에게 남겼습니다.

AI 개발 에이전트의 승인 파이프라인

에이전트가 계획부터 검증 증거까지 만들고 완료 여부는 사람이 결정합니다.

계획, 구현, 코드 리뷰, 문서 갱신, E2E 검증을 거친 변경 내역과 검증 증거를 사람이 승인하거나 보완 요청합니다.

종료 훅으로 이어 가는 자동 반복

한 작업 차례가 끝날 때 상태 파일을 읽어 현재 단계와 반복 횟수를 확인하고, 완료되지 않았으면 다음 단계 안내만 다음 턴에 전달했습니다. 전체 문서를 매번 넣지 않아 대화 입력이 불필요하게 길어지는 문제를 막았습니다.

세션 일치 여부, 중단 표시, 사용자 결정 대기, 완료 신호와 반복 상한을 차례로 검사했습니다. 자연어 추측이 아니라 명시된 단계 전환 규칙으로 반복을 멈추게 했습니다.

작업 종료 뒤 다시 시작되는 자동 반복

자동 반복은 모델의 기억이 아니라 외부 상태와 명시적인 종료 조건으로 이어집니다.

사용자가 작업을 시작하면 세션이 상태를 기록하고 종료 훅이 단계와 반복 횟수를 확인해 다음 단계 안내만 전달하며 완료 시 결과를 반환합니다.

종료 훅이 멈춰야 할 조건

자동 반복보다 더 중요한 기능은 예측 가능하게 멈추는 것입니다.

작업 차례가 끝날 때 자동 반복이 켜져 있는지, 중단과 결정 대기, 완료와 반복 상한을 확인해 종료하거나 다음 단계 안내를 전달합니다.

코드와 문서를 같은 작업 안에서 함께 갱신하기

문서 동기화를 나중 일로 미루지 않고 변경 종류에 따라 갱신할 문서를 매핑했습니다. 데이터 구조, API 계약, 아키텍처 결정, 운영 절차와 빌드 명령이 각각 어떤 문서에 영향을 주는지 표로 만들었습니다.

자동 변경 범위는 허용 목록으로 제한하고 문서 규칙 자체가 오래되지 않았는지 확인하는 문서 분류표 자체를 갱신하는 규칙도 두었습니다.

변경 종류가 갱신할 증거를 결정

문서 갱신은 기억에 의존하지 않고 변경 종류의 완료 조건에 포함했습니다.

코드 변경의 종류에 따라 스키마 문서, 기술 명세, 결정 기록과 운영 가이드를 갱신하고 같은 작업의 검증 증거로 묶습니다.

E2E 자동화에 안전 확인 절차 두기

브라우저 시나리오는 매번 현재 요구에서 생성하고 장기 보관하지 않았습니다. 오래된 시나리오가 제품 동작을 잘못 규정하는 일을 피하기 위해서였습니다.

실제 운영 주소에서는 실행을 거부하고 허용된 검증 환경에서만 브라우저를 열었습니다. 화면 캡처와 API 응답, 로그를 함께 남기고, 검증이 끝난 뒤 생성한 리소스를 정리한 다음 사람이 결과를 확인했습니다.

실행 환경을 먼저 확인하는 E2E

자동화의 첫 단계는 실행이 아니라 환경이 안전한지 확인하는 일입니다.

E2E 요청이 허용된 검증 환경인지 확인하고 시나리오와 브라우저를 실행해 화면과 API 응답과 로그를 모은 뒤 사람이 검수합니다.

실제 사용 기록을 바탕으로 간소화하기

기반 모델과 도구가 발전한 뒤 기존 AI 개발 자동화 체계의 실제 호출 빈도와 유지 비용을 셌습니다. 거의 쓰이지 않는 상태 파일, 신호 규약과 다층 작업 목록을 제거하고 대화 내용과 단계별 실행 흐름, 자동 검사로 대체했습니다.

상시 로드 규칙 문서는 385줄에서 88줄로 77% 줄었고, 리뷰 자동화 문서도 591줄에서 210줄로 줄었습니다. 전체 코드는 4,524줄 순감소했습니다.

상태 파일 기반 자동 반복에서 단계별 실행으로

자동화 구성 요소의 수가 아니라 실제로 실패를 잡는 흐름을 남겼습니다.

이전의 종료 훅, 상태 파일과 다층 규칙을 단계별 실행 절차, 대화 내용, 자동 검사와 사람 승인으로 단순화합니다.

실패와 복구의 경계

검사가 실패하면 전체 작업을 처음부터 반복하지 않고 실패한 범위만 좁혀 재시도했습니다. 외부 환경 변경이나 사용자의 선택이 필요한 지점에서는 자동화가 멈추도록 했습니다.

완료 선언은 신뢰하지 않고 정적 검사, 단위 테스트, E2E와 변경 증거를 완료 조건으로 묶었습니다. 자동화는 결정을 대신하지 않고 사람이 판단할 근거를 모았습니다.

완료를 결정하는 증거 흐름

완료는 모델의 말이 아니라 재현 가능한 검사와 사람의 승인으로 결정합니다.

AI 결과가 정적 검사, 단위 테스트와 E2E를 거쳐 검증 결과로 남고 사람이 승인하면 완료되며, 실패하면 해당 범위만 다시 실행합니다.

검증과 배운 점

실제 사용 기록에서 규칙별 호출 빈도와 유지 비용을 비교하고, 제거 전후에도 같은 정적 검사·단위 테스트·E2E 완료 기준을 통과하는지 확인했습니다. 안전한 환경 거부와 중단 조건은 스모크 테스트로 별도 검증했습니다.

자동화를 만드는 것보다 걷어내는 일이 더 어렵습니다. 도구는 기반 능력의 변화를 전제로 설계해야 하며, 실패를 개인의 실수보다 검증 기준의 결함으로 보면 더 작고 강한 체계를 만들 수 있습니다.