잠재상태로서의 요구사항
AI 코딩 에이전트를 써보면 이상한 장면이 반복된다. 사용자는 분명히 요구사항을 말했다고 생각하지만, 에이전트는 그 말을 다르게 해석하고 엉뚱한 방향으로 구현한다. 사용자가 더 자세히 설명하면 나아지는 것 같지만, 설명이 길어질수록 또 다른 모호성이 생긴다. 문제는 자연어가 부정확하다는 데서 끝나지 않는다. 더 근본적인 문제는 우리가 요구사항을 "문장 안에 들어 있는 것"으로 착각한다는 데 있다.
요구사항의 '실체'는 문장 자체가 아니라 잠재상태로 있고, 자연어로 표현되는데 이건 흔들리기 쉽다. 사용자의 목적, 조직의 관행, 기존 시스템의 제약, 암묵적 기대, 실패 경험, 비용과 책임 경계가 얽힌 것이 요구사항의 실체이고, 자연어 문장은 그 잠재상태가 표면에 드러난 관측값일 뿐이다. 사용자가 "검색이 잘 되게 해줘"라고 말할 때, 그 말은 랭킹 품질을 뜻할 수도 있고, 응답 속도를 뜻할 수도 있으며, 누락 없는 검색을 뜻할 수도 있고, 질의 보조 UI를 뜻할 수도 있다. 에이전트가 해야 하는 일은 이 문장을 그대로 실행하는 것이 아니라, 자연어 표현을 증거로 삼아 실체의 요구사항을 다시 복원하는 것이다.
이 관점에서 보면 AI 개발에서 반복되는 실패는 프롬프트를 더 잘 쓰면 해결되는 문제가 아니다. 에이전트가 자연어 표현을 요구사항의 실체로 오인한 채 바로 실행에 들어가는 데 문제가 있다. 자연어는 유연하지만, 그 유연성 때문에 같은 요구가 여러 표현으로 나타나고, 같은 표현이 여러 요구를 가리킨다. 따라서 요구사항 분석은 문서 해석이 아니라 잠재상태 추론이다. 사용자의 말, 기존 코드, 테스트 실패, 도메인 제약, 사용자 피드백, 승인 여부가 모두 잠재 요구사항을 추정하기 위한 증거가 된다.
여기서 EARS라는 개념이 등장한다. EARS는 Easy Approach to Requirements Syntax의 약자로, 요구사항을 일정한 자연어 패턴으로 쓰게 만드는 문법이다. "When 어떤 사건이 발생하면, the system shall 어떤 동작을 수행한다", "While 특정 상태가 유지되는 동안, the system shall 어떤 동작을 수행한다" 같은 식으로 조건과 시스템의 행동을 분리해서 적는다. 핵심은 요구사항을 자유로운 산문으로 두지 않고, 트리거, 상태, 주체, 행동을 구분해 모호성을 줄이는 데 있다. 하지만 EARS는 원래 시스템 요구사항을 안정되게 문서화하기 위한 문법에 가깝다. AI 코딩 에이전트 환경에서는 요구사항의 주체가 반드시 "시스템"만은 아니다. 서비스, 컴포넌트, 에이전트, 함수, 파일, 워크플로우, 데이터 파이프라인일 수 있다. 그래서 GEARS 같은 확장 문법이 의미를 갖는다. GEARS는 EARS의 발상을 일반화해서, 어디에서, 어떤 조건에서, 어떤 주체가, 어떤 행동을 해야 하는지를 더 넓은 개발 맥락에 적용하려는 시도다.
EARS나 GEARS를 문장 템플릿으로 보면 그 의미가 작아진다. 이들은 요구사항을 예쁘게 쓰는 방식이 아니라, 잠재 요구사항을 더 안정적으로 추정하기 위한 관측 모델의 정규화다. 자유로운 자연어 표현은 관측값의 분산이 크다. 반면 조건, 상태, 주체, 행동, 산출물을 분리하면 에이전트가 추론해야 할 자유도가 줄어든다. 이 문법은 요구사항의 실체를 완전히 포착하지는 못하지만, 적어도 에이전트가 무엇을 근거로 해석해야 하는지 더 명확한 관측면을 제공한다.
Spec-Driven Development, 즉 스펙 기반 개발은 이 정규화된 요구사항을 개발의 1차 산출물로 삼는 흐름이다. 전통적인 개발에서는 스펙이 구현 전에 작성되는 참고 문서이거나, 구현 이후에 방치되는 문서가 되기 쉽다. 반면 스펙 기반 개발에서는 spec.md, plan.md, tasks.md 같은 파일이 에이전트가 읽고 실행하는 작업 상태가 된다. 명세는 더 이상 사람만 읽는 문서가 아니라, 에이전트가 다음 행동을 선택하기 위해 참조하는 상태파일이다. 그러나 중요한 점은 스펙이 요구사항의 실체가 아니라는 것이다. 스펙은 잠재 요구사항에 대한 현재 추정치다. 사용자의 말과 기존 맥락을 바탕으로 만들어진 posterior의 언어적 표현이라고 볼 수 있다. 새로운 피드백이 들어오거나, 구현 과정에서 모순이 드러나거나, 테스트 실패가 반복되면 스펙은 갱신되어야 한다. 따라서 좋은 스펙 기반 개발은 명세를 절대화하는 방식이 아니라, 명세를 계속 검증하고 수정하는 방식이어야 한다.
이 지점에서 하네스가 필요해진다. 하네스는 에이전트가 어떤 상태를 관찰하고, 무엇을 수정할 수 있으며, 어떤 기준으로 성공과 실패를 판정하고, 실패했을 때 어디까지 되돌릴 수 있는지를 정의하는 실행 환경이다. 제어공학적으로 보면 현재 상태, 목표 상태, 오차, 제어 입력, 상태전이, 피드백 경로를 묶은 장치다. 요구사항이 잠재상태라면, 하네스는 그 잠재상태에 대한 추정이 실행을 통해 맞는지 틀린지 확인하는 제어 루프다. 반대로 스킬은 특정 작업을 수행하는 능력의 패키지다. 테스트를 작성하는 스킬, 배포를 수행하는 스킬, 문서를 EARS 형식으로 변환하는 스킬은 모두 재사용 가능한 행동 정책이다. 스킬은 actuator에 가깝고, 하네스는 controller에 가깝다. actuator만 있으면 열린 루프 자동화가 되고, controller만 있으면 실제 전이가 일어나지 않는다.
AskUserQuestion 같은 사용자 입력 루프도 이 맥락에서 이해해야 한다. 에이전트가 요구사항 잠재상태를 복원하는 과정에서 불확실성이 높아졌을 때 추가 관측을 얻는 정보획득 행동이다. 여러 해석이 가능하고, 그 해석에 따라 구현 결과가 크게 달라지며, 잘못 실행했을 때 되돌리기 어렵다면 에이전트는 질문해야 한다. 반대로 사소한 모호성마다 질문하면 실행성이 무너진다. 그래서 좋은 하네스는 질문이 필요한 조건까지 포함해야 한다. 승인 루프도 마찬가지다. 에이전트가 외부 상태를 되돌리기 어렵게 바꿀 때는 제안과 승인이 먼저 와야 한다. 승인은 인간에게 책임을 떠넘기는 절차가 아니라, 잠재 요구사항에 대한 에이전트의 현재 추정을 사용자가 다시 관측하고 판정하는 과정이다.
WorldLoops류 구조는 이 관점을 더 선명하게 만든다. 신호가 들어오면 곧바로 외부 실행으로 바꾸지 않고, 미해결 루프를 열고, 제안을 만들고, 승인을 받은 뒤, 로컬 상태전이를 기록하고, 영수증을 남기는 방식이다. 중요한 것은 "에이전트가 무엇을 했다"가 아니라, "어떤 신호를 어떤 요구로 해석했고, 어떤 제안을 만들었으며, 어떤 승인 이후에 어떤 전이를 남겼는가"다. 이 기록이 있어야 나중에 요구사항 추정이 틀렸을 때 어느 관측, 어느 해석, 어느 실행에서 오류가 생겼는지 추적할 수 있다. receipt는 로그가 아니라 잠재 요구사항 추론의 흔적이다.
여기서 메모리의 역할도 다시 정의된다. 에이전트 메모리는 과거 대화를 많이 저장하는 공간이 아니다. 저장된 상호작용이 현재 요구사항 추정에 어떻게 영향을 주고, 어떤 경우에 과거 패턴을 신뢰하며, 어떤 경우에는 폐기해야 하는지 정하는 갱신 규칙이 더 중요하다. 저장된 기록이 벡터DB에 쌓여 있을 뿐이면 그것은 경험이 아니라 저장이다. 경험이 적응이 되려면 저장된 관측값이 현재 posterior를 바꾸고, 그 변화가 실행 정책에 반영되어야 한다.
이 관점에서 보면 기존 요구사항 공학과 에이전트 기반 개발은 결정적으로 다르다. 기존 그림에서는 요구사항을 발견하고, 문서화하고, 합의한 뒤, 구현으로 내려보낸다. 하지만 에이전트 기반 개발에서는 요구사항이 처음부터 완성된 형태로 존재하지 않는다. 요구사항은 사용자와 에이전트의 반복 상호작용, 코드베이스의 저항, 테스트 실패, 배포 환경의 제약, 조직적 승인 과정을 통과하면서 점진적으로 안정화된다. 스펙은 출발점이면서 동시에 계속 갱신되는 상태 추정치다.
내가 보기에 스펙 기반 개발의 본질은 "자연어 요구사항을 코드로 번역하는 것"이 아니다. 그것은 불안정한 자연어 관측값들로부터 요구사항이라는 잠재상태를 추정하고, 그 추정을 스펙이라는 상태파일로 고정하며, 실행과 피드백을 통해 계속 갱신하는 폐루프 시스템을 만드는 일이다. EARS와 GEARS는 관측값의 분산을 줄이는 문법이고, spec-kit은 추정된 요구사항을 실행 가능한 개발 상태로 고정하는 장치이며, AskUserQuestion과 approval loop는 불확실성과 책임 경계를 처리하는 관측 채널이다. skill은 특정 상태에서 가능한 행동 정책이고, harness는 관측, 판정, 승인, 복구를 묶은 제어면이다. 결국 좋은 AI 개발 에이전트는 말을 잘 알아듣는 모델이 아니다. 흔들리는 표현 속에서 안정된 의도를 추정하고, 그 추정을 명시적 상태로 보존하며, 실행 중 드러나는 오차를 다시 요구사항 이해에 반영하는 시스템이다. 이 지점에서 스펙 기반 개발은 문서 작성법이 아니라, 에이전트 시대의 요구사항 추론 아키텍처가 된다.
참고
Mavin, Alistair, et al. 2009. "Easy Approach to Requirements Syntax (EARS)." IEEE RE, 2009.
"Generalized EARS: The AI-Ready Spec Syntax." Medium, 2026.
"spec-kit: Spec-Driven Development." GitHub, 2026.
"Spec-Driven Development with ADK." Google Codelabs, 2026.
"User Input — Claude Code Agent SDK." Claude Code Docs, 2026.
"WorldLoops." GitHub, 2026.
"Ouroboros: Agent OS." GitHub, 2026.