당신의 에이전트는 자신이 완료되었다고 말할 것입니다. 에이전트는 녹색 체크 표시, 통과된 데모, 그리고 자신이 구축한 것에 대한 깔끔한 요약과 함께 자신 있게 그렇게 말할 것입니다. 그리고 에이전트는 매우 자주 틀릴 것이며, 이로 인해 "에이전트가 완료되었다고 했다"라는 말은 AI 구축 과정에서 조용히 가장 비용이 많이 드는 문구가 되었습니다. 문제는 에이전트가 거짓말을 한다는 것이 아닙니다. 문제는 아무도 에이전트에게 '완료'가 무엇을 의미하는지 말해주지 않았기 때문에, 에이전트가 스스로 정의를 내렸고, 그 정의가 "해피 패스 (happy path)가 작동한다"라는 점입니다.

소프트웨어 역사의 대부분 동안, 그 간극은 팀에 의해 메워졌습니다. 개발자가 기능을 완료하면, 팀이 명시되지 않은 표준을 공유하고 있었기에 '완료'에는 테스트, 리뷰, 배포가 포함된다는 것이 이해되었습니다. 이제 개발자는 명시되지 않은 표준도 없고 공유된 것도 없는 에이전트입니다. 에이전트는 당신이 기록한 것만을 가지고 있으며, 나머지는 완성된 것처럼 보이는 무언가로 가는 가장 짧은 경로로 채워버립니다. 따라서 이 포스트가 전제로 하는 가설은 다음과 같습니다: 에이전트가 구축 작업의 더 많은 부분을 수행할수록, '완료'에 대한 공유된 감각에 의존할 수는 줄어들며, 그 표준을 하나의 명시적인 모든 기능 공통 기준으로 문서화해야 할 필요성은 더 커집니다. 그 기준에는 이름이 있습니다. 그것이 바로 당신의 완료의 정의 (definition of done)입니다.

완료의 정의 (definition of done)란 실제로 무엇인가

이 용어는 애자일 (agile)에서 유래되었으며, 애자일의 정의는 깔끔하기 때문에 유지할 가치가 있습니다. 완료의 정의 (definition of done)란 어떤 작업이 완료되었다고 부르기 전에 반드시 충족해야 하는 공유된 조건들의 집합입니다. Scrum.org에서는 이를 제품에 요구되는 품질을 충족했을 때의 작업 상태에 대한 공식적인 설명으로 정의합니다. 핵심 단어는 "공유된 (shared)"입니다. 이는 기능별로 적용되는 것이 아닙니다. 로그인 화면을 출시하든 결제 페이지를 출시하든 상관없이 적용되는, 모든 기능에 적용되는 상시 기준이자 체크리스트입니다.

이 점이 흔히 혼동되는 개념과 다른 점입니다. 수락 기준 (Acceptance criteria)은 기능별로 "이것이 올바른 것인가"에 답합니다. 반면, 완료의 정의 (Definition of done)는 매번 "표준에 맞게 구축되었는가"에 답합니다. 로그인 기능의 수락 기준은 잘못된 비밀번호를 입력했을 때 오류가 표시되어야 한다고 명시할 수 있습니다. 하지만 당신의 완료의 정의는 해당 기능과 다른 모든 기능에 대해, 테스트를 통과했는지, 변경 사항이 기준에 따라 검증되었는지, 그리고 단순히 데모 환경이 아닌 실제 환경에서 작동하는지를 규정합니다. 하나는 특정 기능에 국한된 것이고, 다른 하나는 그 모든 기능 아래에 깔린 기준선입니다. 당신은 두 가지 모두가 필요하며, 기능별 기준에 대해서는 AI 에이전트가 검증할 수 있는 수락 기준을 작성하는 방법에서 자세히 다룹니다. 이 포스트는 상시 기준(standing bar)에 관한 것입니다.

애자일 (Agile) 용어를 걷어내면 이 개념은 소프트웨어보다 더 오래되었습니다. 완료의 정의는 모든 빌더가 항상 답해야 했던 질문, 즉 "언제 멈춰야 하는가"에 대한 답일 뿐입니다. 과거에는 그 답이 사람들의 머릿속에 머물러 있었습니다. 하지만 이제는 더 이상 그럴 수 없습니다.

왜 AI 빌더들에게 이것이 누구보다 더 필요한가

사람들을 놀라게 하는 부분이 여기 있습니다. 완료의 정의는 프로세스상의 미덕, 즉 성숙한 팀은 갖추고 있지만 작은 팀은 건너뛰는 것으로 취급됩니다. AI 구축의 경우, 그 반대입니다. 운영 규모가 작고 속도가 빠를수록 이것이 더 필요합니다. 에이전트가 당신이 놓친 부분을 잡아내는 능력보다 더 빠르게 움직이기 때문입니다.

Claude Code를 통해 바이브 코딩 (vibe coding)에서 에이전트 엔지니어링 (agentic engineering)으로 전환하는 것에 관한 apimatic 팀의 글에 나온 문장을 살펴보십시오:

"올바르게 작동해야 한다"는 기준이 될 수 없습니다.

그것이 바로 다섯 단어로 요약된 문제의 핵심입니다. 당신에게 "올바르게 작동해야 한다"는 것은 명백한 기준입니다. 하지만 에이전트에게 그것은 노이즈(noise)에 불과합니다. 왜냐하면 그 문장에는 검증 가능한 것이 아무것도 없기 때문입니다. 에이전트는 "올바르게" 실행될 수 없습니다. 에이전트는 테스트를 실행하거나, 엔드포인트(endpoint)를 호출하거나, 페이지를 렌더링할 수 있을 뿐입니다. 당신의 기준은 '느낌'인데 에이전트는 오직 '사실'만을 이해한다면, 에이전트는 자신이 볼 수 있는 사실에 부합하는 버전만을 배포하고 나머지 모든 것은 조용히 누락시켜 버립니다. 완료의 정의(Definition of Done)란 당신이 느끼는 기준을 에이전트와 당신이 실제로 확인할 수 있는 사실로 번역하는 방법입니다.

이 문제의 위험성은 자율성(autonomy)에 비례하며, 이것이 바로 모델이 발전할수록 상황이 악화되는 정확한 이유입니다. 에이전트가 현재 작동하는 루프 기반(loop-driven) 방식에 대해 이야기하던 Addy Osmani는, The Register가 이 개념 전체에 대해 반론을 제기했을 때 다음과 같이 명확하게 지적했습니다.

루프는 업무를 변화시키지만, 업무에서 당신을 삭제하지는 않습니다. 에이전트는 매달 루프의 더 많은 부분을 관리자 없이 실행합니다. 사라지지 않는 업무는 바로 무엇을 루프가 완료된 것으로 간주하도록 허용할지 결정하는 것입니다. 완료의 정의(Definition of Done)는 한 번 작성되어 모든 실행에 적용되는 바로 그 결정입니다.

무엇을 포함하는가 (그리고 무엇을 포함하지 않는가)

AI 구축을 위한 좋은 완료의 정의는 짧고, 구체적이며, 모든 기능에 대해 동일해야 합니다. 그것은 기능 명세서(feature spec)가 아닙니다. 그것은 최저 기준선(floor)입니다. 에이전트가 통과할 수 있는 기준과 에이전트가 통과할 수 없는 바람(wish)의 차이는 다음과 같습니다.

바람(wish): "기능이 완료되고, 테스트되었으며, 사용자가 사용할 준비가 되어 있어야 한다."

기준(standard): "모든 수락 기준(acceptance criterion)이 증거와 함께 검증되었다. 새로운 동작에 대한 자동화된 테스트(automated tests)를 통과했다. 변경 사항이 로컬(locally)뿐만 아니라 실제 프리뷰 환경(preview environment)에서 실행된다. 실패해야 하는 입력값(비어 있거나, 잘못되었거나, 형식이 잘못된 경우)이 해피 패스(happy path)뿐만 아니라 적절히 처리된다. 이전에 작동하던 기능 중 망가진 것이 없다."

첫 번째 항목은 완성된 느낌은 주지만 아무것도 검증하지 않습니다. 두 번째 항목은 다섯 가지 사실로 구성되며, 각 사실은 당신이 구축하는 어떤 기능에 대해서도 참(true) 또는 거짓(false)으로 판별될 수 있습니다. 에이전트(Agent)에게 두 번째 목록을 지시할 수 있습니다. 머지(merge) 버튼을 누를 때 이를 따라 내려가며 확인할 수 있습니다. 두 사람 모두 기분이나 분위기를 해석할 필요가 없습니다.

목록에 없는 것이 무엇인지 주목하십시오. 비즈니스 로직(business logic)도 없고, "보고서에 월간 수익이 표시되어야 한다"와 같은 기능 상세 내용도 전혀 없습니다. 그것은 해당 개별 기능의 수락 기준(acceptance criteria)에 속하는 내용입니다. 완료의 정의(definition of done)는 의도적으로 일반적(generic)입니다. 왜냐하면 그 역할은 당신이 무엇을 구축하든 상관없이 유지되는 단 하나의 기준(bar)이 되는 것이기 때문입니다. 특정 기능을 설명하기 시작하는 순간, 그것은 완료의 정의가 아니라 사양(spec)이 되어버립니다.

빌드 과정에서 이 두 계층이 어떻게 함께 자리 잡는지 보여줍니다.

flowchart LR
  A[아이디어] --> B[수락 기준 (Acceptance criteria)<br/>올바른 것을 만들고 있는가?]
  B --> C[에이전트 빌드]
...

수락 기준(Acceptance criteria)은 빌드의 앞단(front)을 통제합니다: 우리가 올바른 것을 만들고 있는가? 완료의 정의(definition of done)는 뒷단(back)을 통제합니다: 구축된 것이 '완료'되었다고 불릴 자격이 있는가? 첫 번째는 통과하고 두 번째는 통과하지 못한 에이전트는 올바른 기능을 나쁘게 만든 것이며, 이는 AI 작업이 완료된 것처럼 보이지만 실제로는 그렇지 않은 가장 흔한 사례입니다.

함정, 그리고 솔직한 한계

명시적으로 언급해야 할 실패 모드(failure mode)는 데모(demo)입니다. 에이전트가 당신 앞에서 실행되는 무언가를 만들어내면, 실행되는 데모는 가장 설득력 있는 증거인 동시에 가장 신뢰할 수 없는 증거가 됩니다. 데모는 에이전트가 언제나 완벽하게 해낼 수밖에 없었던 해피 패스(happy path)입니다. 당신의 완료의 정의(definition of done)는 데모가 결코 던지지 않는 질문을 던지기 위해 존재합니다: 잘못된 입력(bad input)이 들어오면 어떻게 되는가, 상류(upstream)에서 무엇이 망가졌는가, "클릭했을 때 괜찮아 보였다"라는 말 외에 단 한 조각의 증거라도 있는가? 데모가 작동했다는 이유로 승인하는 것은 80%를 승인하고 나머지 누락된 20%를 떠안는 것과 같습니다.

그리고 솔직한 한계도 말씀드리겠습니다. 그렇지 않은 척하는 것 자체가 일종의 과장(hype)이 될 것이기 때문입니다. 완료의 정의(Definition of Done)는 천장이 아니라 바닥입니다. 이는 예측 가능하고 반복되는 격차, 누락된 테스트, 처리되지 않은 오류, 망가진 인접 기능 등을 잡아냅니다. 하지만 미묘한 보안 결함이나, 기술적으로는 "완료"되었으나 전략적으로 잘못된 설계 결정까지 잡아내지는 못합니다. 개인 프로젝트의 경우, 강력한 완료의 정의와 행동 검토(behavioral review)만으로도 충분히 자신 있게 출시할 수 있습니다. 하지만 실제 사용자 데이터나 돈을 다루는 것이라면, 그 위에 더 깊은 기술적 검토(technical pass)가 여전히 필요합니다. 이 기준(bar)은 당신의 바닥을 훨씬 높여줍니다. 하지만 당신에게 어떤 수준의 바닥이 필요한지에 대한 판단을 대신해주지는 않습니다.

기준이 스스로 강제되게 만드는 방법

머릿속에만 머물러 있거나 아무도 열어보지 않는 문서에 적혀 있는 완료의 정의는 없는 것과 마찬가지입니다. 완료의 정의가 갖는 진정한 가치는, 당신이 일일이 기억하지 않아도 모든 기능에 대해 그것이 체크된다는 점에 있습니다. 이것이 표준을 '아는 것'과 표준이 '지켜지게 하는 것' 사이의 차이입니다.

이 지점에서 BrainGrid가 역할을 하며, 빌드 과정의 양측 모두에 자리 잡고 있습니다. 당신이 기능을 설명하면, Planning Agent(기획 에이전트)가 이를 명시적인 수락 기준(acceptance criteria)을 가진 요구사항으로 변환하여, 코드가 존재하기 전에 기능별로 "올바른 작업"이 문서화되도록 합니다. Builder Agent(빌더 에이전트)가 이를 구축할 때, BrainGrid Cloud의 라이브 프리뷰를 통해서든, 혹은 Claude Code, Cursor, 또는 Codex를 사용한 당신의 자체 저장소(repo)를 통해서든, 검증(verification) 단계에서 모든 기준에 대해 결과를 대조하고 증거를 보고합니다. 따라서 "기준에 따라 검증됨"이라는 말이 당신이 직접 감시해야 하는 막연한 희망 사항이 아니라, 모든 기능에서 실행되는 하나의 단계가 됩니다. 이것이 바로 자동화된 상시 기준(standing bar)입니다. 매 빌드마다 동일한 체크가 이루어지며 증거가 첨부됩니다. 이는 Plan(계획), Build(빌드), Verify(검증), Repeat(반복) 루프에서 Verify(검증) 단계에 해당하며, "에이전트가 완료했다고 말함"을 "완료되었다는 증거가 여기 있음"으로 바꾸어 놓는 핵심입니다.

따라서 이 가설에 대한 결론은 다음과 같습니다. 에이전트가 더 빠르게 움직일수록, 공유된 완료(done)의 개념을 당연하게 가정할 수 있는 여지는 줄어들고 이를 더 명시적으로 작성해야 합니다. 왜냐하면 자율적인 빌더(autonomous builder)가 스스로 제공할 수 없는 단 한 가지는 바로 스스로의 중단 기준이기 때문입니다. 기준(bar)을 한 번만 작성하십시오. 모든 기능이 그 기준을 명확히 따르도록 만드십시오. 코드는 저렴하고 빨라졌습니다. 무엇이 완료된 것으로 간주될지에 대한 결정은 여전히 당신의 몫이며, 그 결정은 그 어느 때보다 더 큰 비중(load-bearing)을 차지합니다.

FAQ

코드에서의 완료의 정의(Definition of Done)란 무엇인가요?

코드에서 완료의 정의(Definition of Done)란, 변경 사항이 병합(merge)되거나 배포(ship)되기 전에 충족해야 하는 일련의 고정된 조건들을 의미하며, 매번 새로 작성하는 것이 아니라 모든 기능에 적용됩니다. 전형적인 조건은 다음과 같습니다: 새로운 동작에 대한 자동화된 테스트(automated tests) 통과, 수락 기준(acceptance criteria)에 따른 변경 사항 검증, 로컬 환경뿐만 아니라 실제 환경에서의 실행 가능성, 오류 및 예외 케이스(edge cases) 처리, 그리고 기존에 작동하던 기능의 파손 없음 등이 있습니다. 이는 의도적으로 일반적(generic)입니다. 기능별 요구사항은 수락 기준(acceptance criteria)에 존재하며, 완료의 정의(Definition of Done)는 어떤 기능을 구축하든 상관없이 유지되는 품질의 최저선(quality floor)입니다.

완료의 정의(Definition of Done)와 수락 기준(Acceptance Criteria)의 차이점은 무엇인가요?

수락 기준(Acceptance criteria)은 하나의 특정 기능에 국한되며 "우리가 올바른 것을 만들었는가"에 답합니다. 예를 들어, 잘못된 비밀번호 입력 시 오류 표시, 보고서에 월간 매출 합계 포함 등이 이에 해당합니다. 반면 완료의 정의(Definition of Done)는 일반적이며 "표준에 맞춰 만들어졌는가"에 답합니다. 즉, 테스트 통과, 기준 검증 완료, 배포 가능 여부, 예외 케이스 처리 등이 포함됩니다. 수락 기준은 기능마다 변하지만, 완료의 정의는 모든 기능에 걸쳐 동일하게 유지됩니다. 이 두 가지 모두가 필요합니다. 왜냐하면 어떤 기능이 수락 기준(올바른 것)은 충족하더라도, 완료의 정의(잘못된 구축, 테스트 부재, 다른 기능 파손 등)를 통과하지 못할 수 있기 때문입니다.

애자일(Agile)에서 DoR과 DoD란 무엇인가요?

DoR은 준비 완료의 정의 (Definition of Ready)를, DoD는 완료의 정의 (Definition of Done)를 의미합니다. 준비 완료의 정의 (Definition of Ready)는 누군가 작업을 시작하기 전에 통과해야 하는 기준이며, 보통 작업 내용이 명확하고, 범위 (scope)가 정해져 있으며, 수락 기준 (acceptance criteria)을 갖추고 있음을 의미합니다. 완료의 정의 (Definition of Done)는 누군가 그것을 완료되었다고 부르기 전에 통과해야 하는 기준입니다. AI 빌더들에게 이 쌍은 루프 (loop)에 깔끔하게 매핑됩니다. 준비 상태 (readiness)는 계획이 에이전트 (agent)에게 넘겨주기에 충분히 좋은지 여부이며, 완료 (done)는 에이전트가 생성한 결과물이 배포 (ship)하기에 충분히 좋은지 여부입니다. 두 가지 모두 추측을 방지하기 위해 존재하며, 하나는 시작 단계에서, 다른 하나는 종료 단계에서 작동합니다.

소프트웨어에서 "완료 (done)"란 무엇을 의미하나요?

소프트웨어에서 "완료 (done)"란, 단순히 작동하는 것처럼 보이는 것을 넘어, 팀이 합의한 완료의 모든 조건을 충족하는 변경 사항을 의미합니다. 여기에는 보통 기능이 명세대로 동작하고, 자동화된 테스트 (automated tests)를 통과하며, 변경 사항이 검토(review) 또는 검증(verify)되었고, 기존 동작을 파괴하지 않고 실제 환경에 배포 (deploy)되는 것이 포함됩니다. 팀이 이를 완료의 정의 (definition of done)로 명문화하는 이유는, 그렇지 않으면 "완료"라는 말이 사람마다 조금씩 다르게 의미될 수 있고, AI 에이전트 (AI agent)는 이에 대한 공유된 개념이 전혀 없기 때문입니다. 명시적인 표준이 없다면, "완료"는 가장 낮은 수준의 기준인 "데모가 돌아갔다"는 수준으로 격하됩니다.

소규모 팀이나 개인 빌더에게도 정말 완료의 정의 (definition of done)가 필요한가요?