이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
AI coding agent는 빌드와 테스트를 통과한 코드도 초기 요구사항을 잘못 해석한 채 production에 보낼 수 있으므로, 코드 자체보다 해석과 구현을 연결하는 증거가 필요합니다. Salesforce 팀은 요구사항과 성공 기준을 계약으로 고정하고, repository에서 확인 가능한 lookup은 에이전트가 처리하며 제품 판단이 필요한 judgment만 사람에게 넘기는 Spec-Driven Development workflow를 구축했습니다. 계획은 실제 repository 근거로 검증하고 성공 기준은 테스트와 Compliance Matrix로 추적했으며, Conclave의 독립적인 adversarial review가 마지막 약점을 공격했습니다. AI-powered mobile application designer 기능에서 4,500개 이상의 테스트와 production build를 통과하고 사람의 개입을 제품 결정 1회로 제한한 결과는 인간을 제거하는 대신 인간의 판단을 필요한 지점에 집중하는 방식을 뒷받침합니다.
섹션별 상세
AI coding agent가 만든 대규모 pull request는 빌드와 자동 테스트를 통과하고 코드 리뷰에서도 문제가 없어 보일 수 있지만, 초기 요구사항을 잘못 해석했다면 모든 후속 결정이 일관된 채로 잘못된 결과를 만들 수 있습니다. Salesforce 팀은 AI-powered mobile application designer를 개발하며 코드 생성 능력보다 그 결과를 믿을 근거를 확보하는 일이 더 어렵다는 문제를 만났습니다. 따라서 신뢰를 최종 diff에서 역추적하기보다 구현 전에 단계별 증거를 쌓는 구조가 필요해졌습니다.
팀은 에이전트가 바로 구현하지 못하도록 먼저 요구 동작, 성공 기준, 가정, 미해결 질문, 실패 조건을 담은 specification을 작성했습니다. 이 specification은 배경 문서가 아니라 이후 계획과 테스트가 따라야 할 계약이 되었고, 성공 여부의 기준도 구현 결과가 아니라 계약으로 이동했습니다. 각 단계에는 다음 단계로 넘어가기 전에 통과해야 하는 독립적인 gate가 배치되어 불확실성을 초기에 드러냈습니다.
근거
- Specification이 요구사항과 성공 기준을 계약으로 고정하고 계획과 테스트의 공통 기준이 됐다. — Make Uncertainty Visible Before Writing Code 절에서 specification의 구성 요소와 계약으로서의 역할을 설명한 부분
모든 미해결 질문을 사람에게 보내면 엔지니어가 판단자가 아니라 저장소 검색 서비스가 되므로, 팀은 lookup과 judgment를 분리했습니다. 파일 존재 여부, 유틸리티 선택, 패키지 관례, 테스트 명령처럼 코드와 문서에서 답을 찾을 수 있는 lookup은 에이전트가 근거와 함께 해결하고, 선호할 사용자 경험이나 호환성 단절의 허용 여부처럼 증거만으로 결정할 수 없는 judgment는 사람에게 넘겼습니다. 이 구분은 사람의 개입을 줄이는 대신 개입이 필요한 질문의 성격을 더 선명하게 만들었습니다.
근거
- Lookup은 repository 근거로 에이전트가 해결하고 judgment는 사람이 결정하도록 불확실성을 분리했다. — Lookup Is Not Judgment 절의 lookup과 judgment 정의 및 예시
계획은 실제 repository를 조사했다는 증거를 포함해야 했으며, 이미 존재하는 기능을 먼저 재사용하고 새 추상화를 만드는 일을 뒤로 미뤘습니다. 계획에는 확장할 컴포넌트, 재사용할 유틸리티, 변경을 소유한 state-management 경로, 수정할 테스트와 각 단계의 근거가 들어갔고, Skeptic Agent가 가상의 의존성이나 빠진 통합 단계를 반박했습니다. 이렇게 검증된 계획도 계약을 충실히 구현한다는 보장은 아니므로, 다음 단계에서 성공 기준을 실행 가능한 테스트로 변환했습니다.
팀은 specification의 성공 기준마다 테스트를 연결하고, 예상한 이유로 테스트가 먼저 실패하는지 확인한 뒤 최소 구현을 작성했습니다. 이후 테스트, regression suite, production build를 실행하고 Compliance Matrix로 각 요구사항이 구현과 테스트 증거에 추적되는지 확인했습니다. 테스트가 모두 통과해도 작성된 테스트만 검증했을 가능성이 남기 때문에, 단순한 녹색 결과보다 요구사항 전체가 실행 가능한 증명으로 바뀌었는지를 기준으로 삼았습니다.
근거
- Compliance Matrix가 각 성공 기준을 구현과 테스트 증거에 연결해 테스트 통과 이상의 추적성을 확보했다. — Did Every Requirement Become Executable Proof? 절의 Compliance Matrix 설명
구현 결과는 Conclave라는 multi-agent adversarial review에 들어갔고, 검토자들은 서로의 판단에 끌려가지 않도록 독립적으로 보안, 정확성, 사용자 경험, 접근성, repository history를 점검했습니다. Advocate는 구현을 지지하는 가장 강한 근거를 제시했으며, 이후 각 지적은 코드 근거를 바탕으로 유지, 수정, 철회 중 하나로 분류됐고 Judge Agent가 남은 쟁점을 판정했습니다. Judge는 통과한 결과를 낮출 수만 있고 실패한 gate를 올릴 수 없었으므로, 설득력 있는 문장이 부족한 증거를 대신할 수 없고 진행할수록 신뢰 기준만 엄격해졌습니다.
근거
- Conclave는 독립 비평, 상호 검증, Judge Agent 판정으로 근거가 약한 결과를 낮추는 구조를 사용했다. — Challenge the Evidence 절의 Conclave 검토 라운드와 Judge 규칙
AI-powered mobile application designer의 실제 기능에서는 data-bound property에 표시되는 control을 추가해 binding을 제거하거나 다른 data field에 연결하도록 했습니다. 에이전트는 binding expression의 감지와 직렬화 방식, 기존 picker, 초기화 방법, undo와 redo 통합, 접근성 관례를 repository에서 찾아 근거를 제출했으며, 사람에게 도달한 질문은 binding 제거 시 전체 값을 지울지 정적 부분을 보존할지뿐이었습니다. 팀은 예측 가능한 경험을 위해 전체 값을 지우기로 결정했고, 이 선택이 기존 specification의 가정과 충돌하자 성공 기준, 테스트, 실패 동작을 구현 전에 갱신했습니다.
실행 결과는 focused commit 6개, 통과한 테스트 4,500개 이상, 컴파일된 production build, 모든 성공 기준을 포괄하는 compliance evidence, required action이 없는 adversarial review로 이어졌으며 사람의 개입은 제품 결정 1회였습니다. 다른 work item은 repository 근거만으로 모든 질문을 해결해 사람의 개입 없이 진행됐습니다. 이 방식의 목표는 인간을 제거하는 것이 아니라 불확실성이 검색으로 해소되는지 판단이 필요한지에 따라 개입 지점을 정하는 데 있습니다.
근거
- 실제 기능 개발에서 4,500개 이상의 테스트가 통과했고 사람의 개입은 제품 결정 1회로 제한됐다. — What Happened in Production? 절의 실행 결과 수치와 human interruption 기록
용어 해설
- AI 코딩 에이전트(AI coding agent)
- — AI coding agent는 자연어 요구사항을 바탕으로 저장소를 탐색하고 계획을 세운 뒤 코드를 작성하는 소프트웨어 개발 도구입니다. 이 글에서는 코드 생성보다 요구사항 해석과 근거 검증을 연결하는 역할에 초점을 둡니다.
- Spec-Driven Development
- — Spec-Driven Development는 구현을 먼저 시작하지 않고 요구사항, 성공 기준, 가정, 미해결 질문, 실패 조건을 명세로 고정하는 개발 방식입니다. 이후 계획과 테스트가 같은 계약을 따라가도록 만들어 AI가 임의로 해석한 부분을 조기에 드러냅니다.
- Compliance Matrix
- — Compliance Matrix는 명세의 각 성공 기준을 실제 구현과 테스트 증거에 연결하는 추적표입니다. 테스트 전체가 통과했다는 사실만 확인하지 않고, 모든 요구사항이 실행 가능한 검증으로 바뀌었는지 점검하는 데 사용됩니다.
- Adversarial Review
- — Adversarial Review는 여러 검토자가 보안, 정확성, 사용자 경험, 접근성, 저장소 이력처럼 서로 다른 관점에서 결과물을 공격적으로 점검하는 절차입니다. 독립 검토와 상호 반박을 거쳐 근거가 약한 지적은 수정하거나 철회합니다.
- 저장소 근거(Repository Evidence)
- — Repository Evidence는 코드, 테스트, 문서, 커밋 이력, 아키텍처 규칙에서 확인한 사실을 뜻합니다. AI가 존재하지 않는 파일이나 API를 전제로 계획을 세우지 않도록 재사용 대상과 변경 지점을 실제 저장소 자료로 뒷받침합니다.
기술
- AI coding agents
- Spec-Driven Development
- Skeptic Agent
- Compliance Matrix
- Conclave
- Judge Agent
활용 사례
- AI coding agent가 대규모 pull request를 생성하는 소프트웨어 개발
- repository 근거와 테스트를 활용한 AI-generated code 검증
- 제품 판단이 필요한 요구사항을 사람에게 에스컬레이션하는 개발 workflow
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 21.수집 2026. 08. 21.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
