나의 바이브 코딩 (vibe-coding) 작업에서, 인간의 확인 과정을 줄이는 것은 프로젝트가 원래의 방향에서 크게 벗어나도록 만들었습니다. 주기적인 수정 작업도 이러한 표류(drift) 현상이 다시 발생하는 것을 막지 못했습니다.

그러한 경험은 나로 하여금 사양 주도 개발 및 품질 보증 프레임워크인 SDAQF를 구축하기 시작하게 만들었습니다. 이유는 간단합니다. 내가 검증할 수 있는 최고 수준의 품질을 목표로 하면서도, 사람이 수행해야 하는 확인 작업의 양을 줄이고 싶기 때문입니다. 이 프레임워크는 아직 개발 중입니다.

이 글은 진행 중인 실험에 대해 설명합니다. 이 글은 문제가 해결되었다거나 도구가 우수하다는 주장을 하지 않습니다.

나의 작업 가설은 바이브 코딩 (vibe coding)이 오류의 주요 원인을 변화시킨다는 것입니다. 이는 일부 수동 구현 실수는 줄여주지만, 확인되지 않은 모델의 가정, 환각 (hallucinations), 그리고 확증 편향 (confirmation bias)의 위험은 증가시킵니다.

확인은 최소화하되, 인간의 판단은 유지하기

이 글에서 나는 사람이 자연어로 대부분의 방향을 제시하고 에이전트 (agent)가 구현의 상당 부분을 생성하는 워크플로우를 위해 “바이브 코딩 (vibe coding)”이라는 용어를 사용합니다. 이는 이 글을 위한 작업 정의이며, 보편적인 정의는 아닙니다.

“인간의 개입을 줄인다”는 말은 개발에서 인간을 제거하는 것처럼 들릴 수 있습니다. 나의 목표는 어떤 결정에 주의가 필요하며, 그 주의가 언제 필요한지를 바꾸는 것입니다.

SDAQF는 목적, 사양 변경, 리스크, 게시 및 기타 제한된 선택 사항과 같은 더 적은 수의 결정에 인간의 참여를 집중시키도록 설계되었습니다. 이는 제품, 윤리, 법적 또는 게시와 관련된 인간의 판단을 명시적으로 대체하지 않으며, 결함이 없는 소프트웨어를 보장하지도 않습니다.

내가 목표로 하는 인간의 역할은 다음과 같습니다:

• 목표, 비목표 (non-goals), 그리고 허용 가능한 리스크를 결정합니다.
• 제품이 수행해야 하는 내용을 변경하는 사양 관련 질문을 해결합니다.
• 게시, 되돌릴 수 없는 작업, 그리고 증거로 해결할 수 없는 예외 사항을 승인합니다.

에이전트는 이러한 결정과 관련된 반복적인 작업, 즉 상태 유지(maintaining state), 미결 질문 식별(identifying open questions), 증거 수집(collecting evidence), 그리고 다음 작업 준비(preparing the next action)를 처리해야 합니다. 에이전트가 단순히 코드를 생성하는 것을 마쳤다는 이유만으로 자신의 출력이 정확하다고 선언하도록 허용해서는 안 됩니다.

만약 프로젝트가 올바른 방향으로 가고 있는지 확인하기 위해 생성된 모든 줄을 여전히 다시 읽어야 한다면, 타이핑 양은 줄었을지 몰라도 실제 검토 부담(checking burden)은 줄어들지 않은 것입니다.

여러 번 확인되는 사양 (Specification)

에이전트가 사양을 한 번 읽고 점차 잊어버린다면, 초기에 작성된 상세한 사양은 가치를 잃게 됩니다.

SDAQF에서 요구사항(requirements)은 안정적인 식별자(stable identifiers)를 부여받습니다. 시스템은 기능적 및 비기능적 요구사항(functional and non-functional requirements), 제외 사항(exclusions), 가정(assumptions), 미결 결정(open decisions), 수락 기준(acceptance criteria), 그리고 검증 방법(verification methods)을 기록합니다. 또한 모호성(ambiguity), 모순(contradiction), 누락된 가정(missing assumptions), 그리고 구현 또는 검증이 불가능한 요구사항을 탐지하도록 설계되었습니다.

이러한 식별자들은 전체 개발 경로 동안 유지되어야 합니다. 하나의 요구사항은 설계(design), 구현(implementation), 테스트(tests), 증거(evidence), 그리고 릴리스 상태(release status)와 계속 연결되어 있어야 합니다. 요구사항을 제거하거나 약화시키려면 승인이 필요하며, 검증되지 않은 요구사항이 조용히 "구현됨" 상태로 넘어가서는 안 됩니다.

사양 자체가 여전히 틀릴 수도 있습니다. 따라서 가정(assumptions)과 미결 결정(open decisions)은 계속 가시적으로 유지되어야 하며, 에이전트가 이를 조용히 채워 넣어서는 안 됩니다. 저는 에이전트가 상세한 요구사항을 초안하고 제품 동작에 영향을 미치는 선택 사항들을 드러내기를 원합니다. 그러면 사람이 해당 제한된 질문들(bounded questions)에 대해 결정할 수 있습니다. 일단 기준선(baseline)이 수락되면, 이후의 변경 사항은 점진적인 프롬프트 드리프트(prompt drift)가 아니라 명명된 요구사항의 변경으로서 나타나야 합니다.

의도된 루프는 다음과 유사합니다:

의도(intent) -> 사양(specification) -> 계획(plan) -> 구현(implementation)
       -> 증거(evidence) -> 독립적 검토(independent review) -> 릴리스 결정(release decision)
          ^ 동일한 요구사항 ID를 기준으로 확인됨 ^

여기서 게이트(gate)는 필요한 증거(evidence)나 승인이 존재할 때까지 진행을 차단하는 결정 지점(decision point)을 의미합니다. G1은 요구사항 베이스라인(requirements baseline)을 다룹니다. G2는 구현 증거(implementation evidence)를 요구합니다. G3는 독립적인 검토(independent review)를 요구합니다. G4는 릴리스 후보(release candidate)를 점검합니다. G5는 별도로 승인된 공개 GitHub 릴리스를 다룹니다.

이것이 중요한 이유는 테스트 통과가 모든 요구사항에 대한 자동으로 증거가 되지는 않기 때문입니다. SDAQF는 클레임-증거 원장(Claim–Evidence Ledger), 즉 각 클레임(claim)을 이를 뒷받침하는 증거와 연결하는 기록을 유지합니다. 각 테스트는 실제로 검증하는 수락 기준(acceptance criteria)을 가리켜야 합니다. 관련 없는 테스트를 통과하는 것만으로는 누락된 요구사항을 종결할 수 없습니다.

컨텍스트(Context), 에이전트(agents), 그리고 증거(evidence)는 서로 다른 역할을 수행합니다

로드맵은 작업을 M0, M1 등으로 표기된 번호가 매겨진 마일스톤(milestones)으로 나눕니다; M은 마일스톤(milestone)을 의미합니다. 공개 릴리스 후보(public release candidate)에는 M0부터 M4까지가 포함됩니다. 이후의 마일스톤들은 서로 다른 상태에 있으며, 끝부분에 있는 상태 표(status table)에서 이를 공개 main, 로컬 개발(local development), 그리고 계획된 작업(planned work)으로 구분합니다.

컨텍스트 프레임워크(context framework)는 재현성(reproducibility) 문제를 다룹니다. M5는 릴리스 후보 외부에 있습니다. 이는 공개 main 상의 구현 후보(implementation candidate)이며, 독립적인 검토(independent review), Windows/Linux CI, 그리고 Git 확정(Git finalization)이 아직 대기 중인 상태입니다. 이는 선택된 입력의 출처(provenance) 또는 기원(origin), 특정 자료가 선택되거나 제외된 이유, 그리고 결정에 사용된 정확한 입력을 고정하는 스냅샷(snapshot)을 기록합니다.

릴리스된 M2 레이어(layer)는 역할(role) 및 도구(tool) 계획을 처리합니다. 이는 문제의 규모, 리스크, 유용한 병렬성(parallelism)에 따라 역할을 선택할 수 있으며, 구현자(implementer)와 독립적인 검토자(independent reviewer)를 분리합니다. 에이전트(agents)의 수는 품질 점수가 아닌 제약 조건(constraint)으로 취급됩니다.

M6는 활성 로컬 개발(active local development)에서 별도의 실행 제어 계층(execution-control layer)이며, 공개 로드맵에는 여전히 계획된 상태로 기재되어 있습니다. 여기서 호스트(host)는 실제 에이전트 세션(agent sessions)을 시작하는 주변의 Codex 또는 세션 환경을 의미합니다. 서브에이전트(Subagent)는 해당 환경으로부터 범위가 지정된 작업(scoped task)을 부여받은 별도의 에이전트입니다. SDAQF는 계획(planning), 검증(validation), 정책(policy), 상태(state), 예산(budgets) 및 감사 기록(audit records)을 관리하며, 호스트는 디스patch(dispatch) 및 Git 워크트리(worktree) 효과를 관리합니다.

이 경계는 릴리스 후보(release candidate)에도 적용됩니다. 이는 독립적 또는 순차적 세션을 위한 서브에이전트 계획(Subagent plans)과 폴백 프롬프트(fallback prompts)를 생성할 수 있지만, 패키지 자체가 중첩된 Codex 프로세스를 실행하지는 않습니다.

제가 의도한 호스트 측 검토 워크플로(host-side review workflow)는 모든 검토자에게 어떤 결론에 도달해야 하는지 말하지 않는 것을 원칙으로 합니다. 독립적으로 실행되는 각 검토자는 원하는 판결(verdict) 없이 범위(scope), 사양(specification), 수락 기준(acceptance criteria) 및 가용 증거(available evidence)를 전달받게 됩니다. 합의(Agreement) 그 자체만으로는 증거가 될 수 없으며, 불일치(disagreements)는 사양, 반례(counterexamples) 및 증거의 강도(evidence strength)를 통해 해결될 것입니다.

단순히 더 많은 에이전트를 추가하는 것은, 특히 그들의 작업과 컨텍스트가 거의 동일할 때 하나의 가정을 반복할 뿐입니다. 역할(Role)과 증거(evidence)의 분리가 투표(vote)보다 더 중요합니다. 유용한 검토자라면 위반된 요구사항, 반례 또는 누락된 증거를 지적할 수 있어야 합니다. “세 명의 에이전트가 동의했다”는 것은 품질 게이트(quality gate)가 아닌 하나의 관찰 결과(observation)로 남아 있어야 합니다.

증거(Evidence)는 세 번째 메커니즘입니다. 주장-증거 원장(Claim–Evidence Ledger)은 어떤 증거가 어떤 주장을 뒷받침하는지 기록하며, 뒷받침되지 않는 완료 주장(completion claims)은 차단된 상태로 유지됩니다. 확신에 찬 검토 문단이 증거(proof)를 대신할 수는 없습니다.

모델 외부에 제한된 체크(bounded checks) 배치하기

AI가 생성한 테스트는 여전히 모델의 출력물입니다. 두 번째 에이전트가 첫 번째 에이전트와 동일한 가정을 반복할 수 있으므로, 에이전트 간의 합의가 최종 체크가 될 수는 없습니다.

계획된 솔버 (solver) 레이어는 제약 조건 (constraints)으로 표현될 수 있는 유계 질문 (bounded questions)을 위한 것입니다. 여기서 SAT/SMT는 특정 구체적인 할당 (assignment)이나 상태 경로 (state path)가 해당 제약 조건을 만족하는지 기계에게 묻는 것을 줄여서 표현한 것입니다. 저의 첫 번째 목표는 상태 전이 도달 가능성 (state-transition reachability)입니다. 예를 들어, 어떤 워크플로우에 draft, reviewed, approved, published 상태가 있다고 가정해 봅시다. 저는 다음과 같은 질문에 대해 기계적인 검증을 수행하고자 합니다:

approved를 거치지 않고
draft에서 published로 가는
허용된 경로가 존재하는가?

만약 그러한 경로가 존재한다면, 그 구체적인 전이 시퀀스 (sequence of transitions)는 증거 (witness)가 됩니다. 즉, 모델에게 그것이 그럴듯해 보이는지 묻지 않고도 규칙을 통해 다시 실행해 볼 수 있는 결과물입니다. 만약 솔버가 UNKNOWN을 반환하거나 시간 초과 (timeout)가 발생하면, 프레임워크는 해당 결과를 미해결 상태로 보존해야 합니다.

이는 여전히 향후 과제로 남아 있습니다. 이번 릴리스에는 해당 기능이 포함되어 있지 않습니다. M7은 현재 유계 가능성 (bounded feasibility), SAT/SMT 방식의 추론 (reasoning), 이산 최적화 (discrete optimization) 및 스케줄링을 위한 선택적인 수학적 계산 및 솔버 프레임워크로 계획되어 있습니다. 로드맵에는 타입이 지정된 요청 및 결과 (typed requests and results), 선택적인 로컬 Z3 커맨드 라인 어댑터 (command-line adapter), 그리고 프레임워크가 이를 수락하기 전 각 증거 (witness)에 대한 재평가가 포함됩니다. 핵심 기능은 선택적 솔버를 사용할 수 없는 상황에서도 계속 작동해야 합니다.

의도는 모델을 사용하여 정식화 (formulation)를 제안하도록 하되, 최종적인 유한 검증 (finite check)은 모델의 권한 밖에서 유지하는 것입니다. 솔버의 결과가 승인을 부여하거나 개발이 완료되었다고 결정하지는 않을 것입니다.

재사용 가능한 API 템플릿 계획

API 애플리케이션 템플릿은 향후 방향성입니다. 현재 릴리스에서는 완성된 API 스타터 (starter)를 제시하지 않습니다.

기존 사양에는 이미 대상, 호환 버전, 의존성 (dependencies), 라이선스, 금지 조건 및 검증 날짜를 기록하기 위한 재사용 가능한 템플릿이 요구됩니다. 나중에 API 템플릿이 추가된다면, 이 계약 (contract)을 통해 의도된 범위와 마지막 검증 시점을 명확히 알 수 있을 것입니다.

현재 존재하는 것과 여전히 아이디어 단계인 것

공개 저장소는 작업의 공개적인 부분을 보여줍니다. 여기에는 2026년 7월 31일에 게시된 SDAQF v1.0.0-rc.1이라는 프리릴리스 (prerelease) 버전이 포함되어 있습니다. 대상 독자는 프레임워크 평가자와 숙련된 Codex 사용자이며, 해당 릴리스 자료는 운영 환경 (production)에서의 사용을 제외합니다. 링크에는 아래에서 설명할 로컬 M6 작업 내용은 표시되지 않습니다.

릴리스된 M0–M4 범위는 다음과 같습니다:

• M0: 워크스페이스 (workspace) 및 저장소 경계 (repository-boundary) 체크, 스키마 (schemas), 테스트, 그리고 설정, 검증 및 상태 확인을 위한 Python 커맨드 라인 인터페이스 (command-line interface);
• M1: 명세 (specification) 입력, 안정적인 요구사항 ID, 수락 기준 (acceptance criteria), 모호성 진단 (ambiguity diagnostics), 추적성 (traceability), 계획, 그리고 G1 결정;
• M2: 에이전트 (agent) 및 도구 레지스트리 (tool registries), 역할 계획, 구현자/검토자 분리 (implementer/reviewer separation), 도구 체크, 승인 및 체크포인트 (checkpoints);
• M3: 주장-증거 원장 (Claim–Evidence Ledger), 구현 및 독립 검토 결정, 기록된 UI 검증, 릴리스 후보 (release-candidate) 체크, 그리고 저장된 핸드오프 (handoff) 상태;
• M4: 평가 피스처 (evaluation fixtures), 하드 블로커 (hard blockers), 그리고 에이전트/도구 레지스트리 (Agent/Tool Registry) 마이그레이션.

해당 릴리스 이후의 상태에는 몇 가지 라벨이 필요합니다:

현재 릴리스 자료에서 보이는 문서 결함도 있습니다. GitHub 릴리스 객체 (release object)가 존재함에도 불구하고, 일부 텍스트에는 여전히 태그와 릴리스가 생성되지 않았다고 기재되어 있습니다. 저는 GitHub 객체를 출판의 증거로 간주하며, 오래된 텍스트는 여전히 수정이 필요한 사항으로 취급합니다.

저장소에는 작성된 비교 분석이 포함되어 있으나, 이는 명시적으로 비경험적 (non-empirical)이며 비인과적 (non-causal)입니다. 따라서 저는 이를 근거로 SDAQF가 이미 소프트웨어 품질을 개선했다고 말할 수 없습니다.

내가 목표로 하는 작은 인간의 역할

제가 원하는 워크플로우는 사람이 의도(intent)와 리스크 경계(risk boundaries)를 설정하면, 에이전트(agent)가 이를 상세 사양(specification)으로 확장하는 방식입니다. 사람은 해결되지 않은 제품 관련 질문에만 답변합니다. 에이전트는 구현을 수행하고, 증거(evidence)를 수집하며, 동일한 요구사항 ID(requirement IDs)를 기준으로 검토를 진행합니다. 증거가 부족하거나 승인이 누락된 경우 게이트(gate)가 진행을 차단합니다. 사양이 변경되어야 하거나, 증거가 리스크를 해결할 수 없거나, 되돌릴 수 없는 작업(irreversible action)이 제안될 때만 사람이 다시 개입합니다.

저는 이 루프가 전체적인 인간의 작업량을 줄이거나 품질을 개선한다는 것을 입증하지는 못했습니다. 향후 평가에서는 인간의 개입(human intervention)과 검증된 요구사항 커버리지(verified requirement coverage)를 모두 가시적으로 유지해야 합니다. 커버되지 않은 요구사항이 있는 저개입(low-intervention) 실행은 품질 목표를 달성하지 못할 것이며, 지속적인 수동 확인이 필요한 완전 검증 실행은 개입 최소화 목표를 달성하지 못할 것입니다.

M8 로드맵은 요구사항(requirements), 컨텍스트(context), 스케줄링(scheduling), 솔버 사용(solver use), 증거(evidence), 핸드오프(handoff), 복구(recovery), 그리고 가용 비용(available cost)에 대해 하나의 통합 점수로 합치지 않고, 각각 별도의 명칭을 가진 측정 지표를 요구합니다. 결과가 분리되어 있어야 트레이드오프(trade-offs)를 더 쉽게 조사할 수 있습니다.

현재로서는 SDAQF는 제가 해당 실험을 어떻게 구조화하려고 노력하고 있는지에 대한 기록입니다. 만약 여러분이 Codex나 Claude Code로 시작하고 있다면, 저는 다음과 같은 간단한 질문에 관심이 있습니다. 여러분은 어떤 결정을 항상 직접 유지하고 싶으며, 시스템이 여러분의 주의를 요청하기 전에 어떤 조건들을 검증하기를 원하십니까?