AI 네이티브 SDLC - 개발 전 과정을 에이전트에 맞게 재설계하기

• 에이전트가 코드 작성 시간을 크게 줄여도 계획과 검토, 보안 승인, 배포가 기존 속도로 움직이면
  병목이 개발 전후 단계로 이동할 뿐 전체 출시 속도는 크게 나아지지 않음
• 기존의 선형적인 역할별 인계 대신 계획, 설계, 구현, 테스트, 배포, 운영에 AI를 넣고, 각 단계가 만든 산출물이 다음 단계를 자동으로 시작하는
  순환 구조로 바꿀 것을 제안함
  intent.md

, spec.md

, plan.md

, 코드와 테스트, PR 검토 결과, 장애 기록을 Git에 남겨 사람과 에이전트가 같은 정보를 읽고 작업하게 하며, 커밋 기록을 감사 추적으로 사용함

• 기계적인 검증과 정책 적용은 테스트, 평가 스위트, 스킬, 훅과 샌드박스로 자동화하고, 사람은 요구사항 승인과 위험 판단, 중요 코드 검토와 프로덕션 배포 같은 판단 지점에 집중함
• 운영 지표가 허용 범위를 벗어나면 결정론적 감시가 에이전트를 호출해 진단 결과를 새
  intent.md

로 만들고, 다시 계획부터 배포까지 같은 통제 경로를 순환하게 함

코드를 빨리 만드는 것만으로는 개발이 빨라지지 않음

• 기존 SDLC는 코드를 작성하고 구현하는 단계가 가장 오래 걸린다는 전제에서 만들어짐
• 요구사항 문서, 작업량 추정, 설계 검토와 보안 승인은 수주에서 수개월 걸리는 구현 과정에서 정렬과 통제를 유지하기 위한 장치였음
• 코딩 에이전트로 구현이 몇 시간까지 줄어들면 기존 과정의 균형이 깨짐
• 계획과 요구사항 정리는 여전히 회의와 문서 작업을 기다리고, 코드 검토와 보안팀은 사람이 만든 코드 양을 전제로 운영됨
• 코드 생성량만 늘리면 검토 대기가 쌓이거나 충분히 확인하지 못한 코드가 배포되는 문제가 생김
• 규제와 보안 요구가 있는 조직은 둘 다 받아들이기 어려우므로, 구현 단계뿐 아니라
  개발 수명주기 전체가 에이전트의 속도에 맞춰 바뀌어야 함

선형 인계에서 산출물이 이어지는 순환 구조로

• 전통적인 개발 과정에서는 프로덕트 매니저가 요구사항을 쓰고, 설계자가 이를 해석하며, 엔지니어와 QA, 배포와 운영팀으로 작업이 순차적으로 넘어감

• 각 인계는 문서와 티켓, 회의와 승인으로 이루어져 느리고 원래 의도가 손실되기 쉬움

• AI 네이티브 SDLC에서는 각 단계가 사람이 검토할 수 있고 다음 에이전트가 실행할 수 있는 산출물을 Git에 커밋함

• 산출물의 흐름은 다음과 같음

• 문제와 원하는 결과를 담은
  intent.md

• 요구사항과 설계를 담은
  spec.md

• 변경 파일과 순서, 위험과 검증 방법을 담은
  plan.md

• 실제 코드 변경과 테스트

• PR과 여러 검토 에이전트의 발견 사항

• 배포 기록과 운영 중 발생한 장애 기록

• 승인된 산출물의 커밋이 다음 단계를 시작하는 신호가 됨

• 누가 무엇을 요청했고 에이전트가 무엇을 만들었으며 누가 승인했는지가 버전 관리 기록에 남아
  자동화와 감사 가능성을 함께 확보함

1단계 계획, 아이디어를 intent.md

로 바로 기록

• 아이디어가 백로그와 사용자 스토리, 추정 회의와 여러 차례의 정제 과정을 거치기 전에 제안자가 Claude와 직접 대화해 의도를 구체화함
• 정형화된 표현을 몰라도 현재의 문제, 영향을 받는 사용자, 원하는 상태와 제외할 범위를 자신의 말로 설명할 수 있음
• Claude는 범위와 제약, 성공 조건과 열린 질문을 확인하고 조직의 템플릿에 맞춘
  intent.md

초안을 작성함

• 제안자는 오해한 내용을 수정하고 프로덕트 오너가 이를 승인하거나 거절함

• 파일에는 다음 정보가 포함됨

• 해결하려는 문제와 제안 결과

• 영향을 받는 사용자와 시스템

• 보안과 규제, 기술적 제약

• 아직 답이 필요한 질문

• 아이디어를 낸 사람의 표현을 유지한 채 사람이 읽고 에이전트가 실행할 수 있는 최초 산출물을 만드는 것이 목적

• Git을 모르는 구성원도 Claude의 GitHub 연결 등을 통해 파일을 커밋할 수 있게 구성함

• 효과는 최초 대화에서
  intent.md

커밋까지 걸린 시간과, 실제 설계 단계로 받아들여진 의도 문서의 비율로 측정함

2단계 설계, 요구사항과 디자인을 한 세션에서 작성

• 승인된
  intent.md

를 기반으로 Claude가 요구사항과 설계를 spec.md

로 작성함

• 브랜드, 보안, 규제, 사용자 경험 정책은 조직의 스킬로 만들어 설계 작성 시점에 적용함
• 분석가가 요구사항을 정리하고 디자이너가 다시 해석하는 두 단계를 한 번의 작업 세션으로 압축함
• 프론트엔드 작업은
  intent.md

에서 화면 모형을 만들고 반복 수정한 뒤 구현 도구로 넘길 수 있음

• 에이전트는 서로 충돌하는 정책이나 충족할 수 없는 제약을 숨기지 않고 우려 사항으로 표시해야 함

• 프로덕트 오너는 문장을 직접 처음부터 작성하기보다 다음 항목을 검토함

• 원래 문제를 실제로 해결하는가

• 열린 질문에 답했거나 다음 단계로 명확히 전달했는가

• 정책 충돌과 위험이 빠짐없이 표시됐는가

• 중요한 판단과 고위험 변경의 진행 여부는 여전히 사람과 기술 책임자가 결정함
  intent.md

와 spec.md

를 함께 보존해 무엇을 요청했고 어떤 설계 결정을 내렸는지 추적함

3단계 구현, 코드를 쓰기 전에 plan.md

승인

• 엔지니어는 승인된
  spec.md

를 Claude Code의 계획 모드에 전달해 코드 수정 없이 저장소를 먼저 분석하게 함

• 계획에는 변경할 파일, 작업 순서, 예상 위험, 선택하지 않은 대안과 성공을 입증할 테스트가 포함돼야 함
• 다른 엔지니어가 대화 기록을 보지 않아도 구현할 수 있을 정도로 구체화한 뒤
  plan.md

로 커밋함

• 구현 도중 계획과 다른 판단을 했다면 코드와 함께
  plan.md

도 갱신해 실제 변경과 문서가 어긋나지 않게 함

• 완성된 diff를 처음 본 시점에 설계 오류를 발견하는 대신,
  코드를 생성하기 전에 변경 접근과 위험을 검토하는 구조
• 계획이 충분히 구체적이면 구현은 에이전트가 한 번에 수행할 가능성이 높아지고 사람의 관심은 코딩보다 설계 판단에 집중됨

저장소 지식을 에이전트가 읽는 파일로 만들기

• 팀의 개발 관례와 오래된 시스템의 제약이 사람의 기억과 구두 설명에만 있으면 에이전트가 반복해서 같은 실수를 만듦
• 저장소 루트의
  CLAUDE.md

에 빌드와 테스트 명령, 코딩 관례, 아키텍처와 에이전트가 자주 틀리는 내용을 기록함
CLAUDE.md

는 저장소의 모든 작업에 적용되는 간결한 안내서로 유지하고, 특정 작업의 긴 절차는 별도 스킬로 분리함

• 스킬에는 보안 API 검토나 데이터 마이그레이션처럼 특정 상황에서만 필요한 지식과 반복 가능한 절차를 담음
• 파일과 스킬을 Git으로 관리하면 변경 내용과 승인자를 확인하고 이전 버전으로 돌아갈 수 있음
• 반복되는 리뷰 지적은 개인에게 다시 설명하는 대신
  CLAUDE.md

와 스킬에 반영해 다음 작업부터 예방함

• 조직 지식을 기계가 읽을 수 있게 만든다고 해서 사람용 문서를 없애는 것이 아니라,
  사람과 에이전트가 같은 최신 규칙을 읽게 하는 것

훅을 구현 단계의 자동 안전장치로 사용

• 프롬프트에 규칙을 적는 것만으로는 에이전트가 항상 지킨다고 보장할 수 없음
• 훅은 도구 실행 전후에 결정론적인 스크립트를 실행해 특정 행동을 허용하거나 차단함
• 데이터베이스 마이그레이션이나 인프라 파일 수정에 변경 티켓을 요구하고, 비밀 파일 읽기와 승인되지 않은 네트워크 접근을 막을 수 있음
• 버그 수정 과정에서 에이전트가 실패하는 테스트를 수정해 통과시키지 못하도록 테스트 파일 변경을 차단할 수도 있음
• 안내 문서는 에이전트가 따라야 할 의도를 전달하고, 훅은 조직이 반드시 지켜야 할 경계를 강제하는 역할
• 여러 세션과 서브에이전트를 병렬로 실행할 때도 각 작업을 별도 worktree와 샌드박스로 격리하고, 최종 검증은 구현 맥락을 공유하지 않은 새 에이전트가 수행할 수 있음

4단계 테스트, 에이전트가 자신의 작업을 직접 검증

• 에이전트가 코드를 만든 뒤 사람이 처음으로 오류를 찾는 구조에서는 사람의 검토가 새로운 병목이 됨
• 각 작업 세션에 테스트와 빌드, 화면 캡처 비교처럼 스스로 결과를 확인할 수 있는 피드백 루프를 제공함
• 여러 명령과 환경 지식이 필요한 검증은
  make test

나 npm test

처럼 한 번에 실행되고 실패 시 오류 코드를 반환하는 명령으로 묶음
CLAUDE.md

에는 명령과 정상 출력의 예시, 완료 전에 반드시 실행해야 할 검사를 기록함

• 버그 수정은 다음 순서를 권장함

• 문제를 재현하는 실패 테스트를 먼저 작성함

• 해당 이유로 실제 실패하는지 사람이 확인하고 테스트를 커밋함

• 이후 에이전트는 테스트를 수정하지 않고 제품 코드를 바꿔 통과시킴

• UI 작업은 브라우저나 화면 캡처 도구를 제공해 구현, 캡처, 기준 화면 비교와 수정 과정을 반복함

• 별도 검증 서브에이전트는 구현에 사용한 가정에 영향받지 않도록 새로운 컨텍스트에서 최종 결과를 확인함

• 테스트 출력과 빌드 기록, 화면 차이 자체가 사람이 검토할 수 있는 증거로 남음

에이전트 설정도 코드처럼 회귀 테스트하기

• 모델이나
  CLAUDE.md

, 스킬과 훅이 바뀌면 같은 작업에서 이전과 다른 결과가 나올 수 있음

• 최근 실제 작업에서 대표 사례 20개에서 50개를 골라 프롬프트와 성공 조건을 평가 항목으로 만듦
• 코드 테스트 통과, 린트, 동작 보존과 정책 준수처럼 받아들일 수 있는 결과를 검증 가능한 조건으로 작성함
• 평가 스위트는 일정에 따라 실행하고, 에이전트 설정 파일이 바뀌는 PR에서도 자동으로 실행함
• 통과율을 낮추는 스킬과 프롬프트 변경은 코드 회귀처럼 병합 전에 검토함
• 프로덕션 장애가 발생하면 해당 사례를 새로운 평가 항목으로 추가해 같은 종류의 문제가 재발하지 않도록 함
• 모델이 발전해 기존 사례가 더 이상 차이를 보여주지 못하면 새로운 어려운 사례로 계속 갱신해야 함

5단계 검토, 기계적 확인과 인간 판단 분리

• 모든 PR에 버그, 보안, 규제와 설계 준수 검토를 같은 기준으로 실행함
  REVIEW.md

에 검토할 항목과 중요도 기준, 보고하지 않을 생성 파일과 CI가 이미 검사하는 항목을 명시함

• 에이전트는 발견 사항을 심각도별로 분류하고, 사소한 지적 수를 제한해 중요한 문제를 묻히지 않게 함
• PR 댓글에서 Claude를 호출하면 지적을 반영해 코드를 수정하고 검사를 다시 실행할 수 있음
• 같은 실수가 반복되면 해당 규칙을
  CLAUDE.md

에 추가해 이후 PR에서 더 일찍 잡음

• 에이전트가 작성한 코드를 같은 에이전트가 최종 승인할 수 없으며, 브랜치 보호를 통해 코드 소유자의 승인을 계속 요구함
• 사람은 모든 줄을 다시 읽는 역할에서 벗어나 변경이 원래 의도와 계획에 맞는지, 남은 위험을 받아들일 수 있는지 판단함
• PR 기록에는 요청, 에이전트의 발견과 수정, 사람의 승인이 모두 남아 감사 자료가 됨

정책을 검토 시점이 아니라 행동 시점에 적용

• 기존 거버넌스는 코드가 완성된 뒤 주간 회의나 보안 검토에서 정책 위반을 발견하는 경우가 많음

• 에이전트가 행동하기 전에 실행되는 훅으로 허용, 승인 요청, 차단을 결정하면 정책을 작업 시점에 강제할 수 있음

• 프로덕션 배포와 보호된 파일 변경, 인프라 작업에 승인 조건을 지정함

• 팀별 훅은 저장소 설정에 넣고 누구도 우회하면 안 되는 규칙은 중앙 관리 설정으로 배포함

• 규제 환경에서는 다음 통제를 조합할 수 있음

• 비밀 파일과 자격 증명 읽기 차단

• 허용된 도메인만 접근하는 네트워크 샌드박스

• 샌드박스가 실행되지 않으면 작업 자체를 중단

• 승인된 스킬과 MCP 서버, 플러그인만 사용

• 조직이 검증한 최소 Claude Code 버전 강제

• 통제 수준은 저장소의 데이터 민감도와 업무에 맞춰 조정해야 하며, 모든 차단은 에이전트의 기능과 생산성을 일부 제한함

CI/CD 안에서 에이전트가 판단 작업 수행

• 초기에는 실패한 빌드 분석, 불안정한 테스트 요약과 변경 기록 초안처럼 읽기 전용 작업부터 적용함

• 이후 린트 수정과 생성 문서 갱신, PR 피드백 반영을 허용하되 모든 변경은 PR과 기존 브랜치 보호를 통과하게 함

• 에이전트 작업은 컨테이너와 네트워크 정책으로 격리하고, 장기간 유지되는 프로덕션 자격 증명 대신 짧고 범위가 제한된 토큰을 사용함

• 배포와 상태 확인, 롤백을 MCP 도구로 노출해 에이전트가 실행할 수 있는 행동을 명시적인 허용 목록으로 만듦

• 환경별로 자동화 수준을 다르게 설정함

• 개발 환경은 에이전트가 자유롭게 배포

• 스테이징은 위험에 따라 일부 승인 필요

• 프로덕션은 에이전트가 준비하되 지정된 릴리스 관리자가 최종 승인

• 롤백은 에이전트가 실행할 수 있는 하나의 검증된 명령으로 만들고 스테이징에서 반복적으로 연습함

• 원칙은
  에이전트가 프로덕션 승인 지점까지 모든 일을 할 수 있지만 그 지점을 스스로 넘을 수는 없게 하는 것

6단계 운영, 장애를 새로운 의도로 되돌려보내기

• 운영 단계는 사람이 티켓을 발견해 개발 과정을 다시 시작하는 수동 단계에서, 감시가 자동으로 새 작업을 만드는 단계로 바뀜

• 오류율과 CI 실패율, PR 처리 시간처럼 안정적인 기준선을 가진 지표를 선택함

• 모델이 이상을 직접 판단하게 하지 않고 평균과 표준편차, Western Electric 규칙 같은 결정론적인 감지 스크립트로 허용 범위 이탈을 확인함

• 심각도에 따라 에이전트의 권한을 다르게 설정할 수 있음

• 1시그마 이탈은 기록만 남김

• 2시그마 이탈은 읽기 전용 진단 수행

• 3시그마 이탈은 PR을 열거나 사전 승인된 롤백 절차 실행

• 에이전트는 이상 현상과 증거, 영향을 받는 시스템과 제안 결과를
  intent.md

로 작성함

• 사람은 이를 즉시 수정할지, 나중에 처리할지, 오탐으로 닫을지 판단함
• 수정이 배포되면 같은 장애 유형을 테스트와 평가 스위트에 추가해 다음 작업의 검증 기준으로 만듦
• 운영에서 발견한 문제가 다시 계획 단계로 들어가면서 SDLC가 닫힌 순환 구조가 됨

정기 보안 검사와 채널 기반 대응

• 코드와 모델이 계속 바뀌므로 보안 검사를 출시 전 한 번 수행하는 이벤트가 아니라 정기 작업으로 전환함
• 모델 기반 검사는 정적 분석과 의존성 검사를 대체하지 않고, 문맥을 이해해야 찾을 수 있는 취약점을 보완함
• 작은 문제는 패치 PR로 보내고 여러 서비스에 걸친 구조적 문제는
  intent.md

로 작성해 계획 단계부터 처리함

• 발견과 신뢰도, 기각 이유와 수정 기록을 남겨 어떤 위험을 고쳤고 의도적으로 받아들였는지 추적함
• Slack 같은 업무 채널에서는 Claude Tag를 사고 대응 구성원으로 참여시켜 대화 맥락에서 진단과 가설 검증을 수행할 수 있음
• 작은 수정은 PR로, 큰 작업은
  intent.md

로 보내며 요청과 진단, 사람의 승인과 수정 결과가 채널과 Git 기록에 남음

사람의 판단은 줄어드는 것이 아니라 위치가 바뀜

• AI 네이티브 SDLC는 사람을 모든 단계에서 제거하는 완전 자동화 방식이 아님

• 사람은 문서를 처음부터 작성하고 모든 코드 줄을 기계적으로 검사하는 작업에서 벗어남

• 대신 다음 판단에 집중함

• 어떤 문제를 해결할지와 의도를 승인함

• 정책 충돌과 설계 위험을 해소함

• 계획과 실제 변경이 목적에 맞는지 판단함

• 중요 코드와 규제 대상 변경을 승인함

• 프로덕션 배포와 위험 수용을 결정함

• 자동화의 목표는 기존 통제를 없애는 것이 아니라
  같은 통제 목적을 에이전트의 속도에 맞는 방식으로 집행하는 것

• Anthropic Applied AI 팀과 고객 작업에서 얻은 Claude 중심의 실무 지침으로, 조직은 여섯 단계를 한꺼번에 바꾸기보다 의존성이 적고 현재 병목이 큰 부분부터 도입할 수 있음

댓글과 토론