"요구사항 관리 (requirements management)"를 검색하면 1998년으로 돌아간 듯한 기분을 느끼게 됩니다. 검색 결과는 항공우주 프로그램이나 의료 기기 준수 사항을 위해 구축된 기업용 제품들뿐이며, 모두 추적성 매트릭스 (traceability matrices), DOORS 라이선스, 그리고 "도출 (elicitation)"과 같은 단어들로 가득 차 있습니다. 이 중 그 어떤 것도 여러분이 Cursor를 열고 앱에 대해 설명하기 시작할 때 하는 작업과 조금도 닮아 있지 않습니다. 그래서 대부분의 AI 빌더들은 이를 한 번 훑어보고는 요구사항 관리는 다른 사람들에게나 일어나는 일이라고 판단한 뒤, 다시 프롬프팅 (prompting)으로 돌아갑니다.

그 본능은 절반은 맞습니다. 도구는 여러분에게 맞지 않습니다. 하지만 관행은 그렇지 않습니다.

상황을 반전시키는 지점은 바로 여기입니다. 여러분의 코딩 에이전트 (coding agent)가 더 유능해질수록, 요구사항 관리는 덜 필요한 것이 아니라 더 많이 필요해집니다. 여러분의 아이디어를 절반만 이해한 느린 인간 개발자는 천천히 빌드하며 진행 과정에서 질문을 던질 것입니다. 하지만 여러분의 아이디어를 절반만 이해한 빠른 에이전트는 잘못된 것을 최대 속도로 빌드한 다음, 그 잘못된 것이 작동한다는 것을 증명하는 테스트를 작성합니다. 여러분이 의도한 것과 기록한 것 사이의 간극은 과거에는 대화를 통해 스스로 메워졌습니다. 하지만 에이전트와 함께할 때는 요구사항 (requirement) 외에는 아무것도 그 간극을 메울 수 없습니다.

요구사항 관리의 실제 모습 (기업용 버전을 제외한)

기업용 패키징을 벗겨내면 요구사항 관리는 세 가지 단순한 활동으로 요약됩니다. 소프트웨어가 무엇을 해야 하는지 포착(capture)합니다. 이해도가 변함에 따라 해당 문구들을 최신 상태로 유지(maintain)합니다. 그리고 구축된 결과물이 그것들에 부합하는지 확인(verify)합니다. 포착, 유지, 확인. 이것이 이 학문의 전부입니다. Jama나 IBM DOORS가 그 위에 추가하는 모든 것들, 즉 승인 워크플로 (sign-off workflows), 컴플라이언스 감사 추적 (compliance audit trails), 수백 명 규모의 추적성 등은 400명의 엔지니어가 참여하는 규제 대상 프로그램이 소송에서 살아남을 수 있는 종이 기록을 필요로 하기 때문에 존재하는 것입니다.

여러분은 심박 조율기를 만드는 것이 아닙니다. 종이 기록은 필요하지 않습니다. 여러분에게 필요한 것은 바로 그 세 가지 활동입니다. 왜냐하면 그것들이 여러분의 의도와 에이전트의 추측 사이에 놓인 방어선이기 때문입니다. 이것이 명세 기반 개발 (spec-driven development)의 실질적인 핵심입니다. 빌드(build)가 따라야 하는 것은 채팅이 아니라 바로 명세 (spec)입니다.

진지하게 고민해 볼 가치가 있는 관점의 전환은 다음과 같습니다. AI 빌더에게 요구사항 (requirement)은 문서 (documentation)가 아닙니다. 그것은 빌드 (build)를 위한 입력값 (input)입니다. 인간 팀의 경우, 요구사항은 커뮤니케이션 산출물 (communication artifact)로서 제품 관리자 (product manager)가 엔지니어에게 무엇을 만들지 전달하는 수단입니다. 하지만 엔지니어가 에이전트 (agent)일 때, 요구사항은 에이전트가 직접 읽고 실행하는 문자 그대로의 대상입니다. 모호하게 입력하면 모호하게 출력되며, 이는 기계의 속도로 이루어집니다. "메모로서의 요구사항"에서 "빌드 입력값으로서의 요구사항"으로의 이 단 한 번의 변화가, 이 관행이 지루한 기업용 명칭을 가졌을 때보다 지금 더 중요한 이유입니다.

여러분이 이미 인지하고 있는 실패 모드

여러분이 이를 요구사항 문제라고 부른 적이 없더라도, 이미 이런 경험을 해보셨을 것입니다. 기능을 설명하면 에이전트가 완성된 것처럼 보이는 무언가를 빌드하고, 데모를 클릭해 보면 잘 작동합니다. 하지만 두 가지 기능이 더 지나면 여러분이 건드리지도 않은 무언가가 고장 나고, 앱이 원래 무엇을 하기로 되어 있었는지 확인하려 돌아가 봐도 어디에도 적힌 답이 없습니다. 여러분의 의도 (intent)를 기록한 유일한 기록은 채팅 (chat)뿐이었고, 그 채팅은 사라졌습니다.

Hacker News의 한 빌더는 자신이 견고하다고 생각한 계획에 따라 에이전트를 밤새 실행시킨 후 정확히 이 상황을 다음과 같이 설명했습니다:

"루프 (loop)의 어딘가에서 에이전트가 결정을 내려야 했고, 잘못된 결정을 내렸습니다. 코드는 '작동'했지만 시스템 설계 (system design)가 잘못되었고, 자신의 가정을 바탕으로 가장 취약한 테스트 (brittle tests)를 작성하여 스스로의 결정을 검증했습니다."

이것은 코딩의 실패가 아닙니다. 에이전트는 코딩을 잘했습니다. 이것은 요구사항의 실패입니다. 계획 (plan)이 에이전트가 새벽 3시에 내린 결정을 고정 (pin down)하지 못했기 때문에, 에이전트는 스스로 결정을 내리고 스스로의 숙제를 채점해 버린 것입니다. 관리되는 요구사항 (managed requirement)이 있었다면 그 결정은 동전 던지기가 아니라 확인 가능한 사실 (checkable fact)이 되었을 것입니다. 이는 우리가 왜 당신의 AI 에이전트가 작동하던 것을 계속 망가뜨리는가에서 파헤쳤던 것과 동일한 함정입니다. 지속 가능한 의도 (durable statement of intent)가 없다면, 모든 세션은 제로에서 시작되며 에이전트는 여러분이 이미 내린 결정을 마음대로 재발명할 자유를 갖게 됩니다.

요구사항 관리 (Requirements management) vs. "그저 좋은 프롬프트 작성하기"

흔한 반론: "저는 이미 상세한 프롬프트를 작성하고 있는데, 그것과 똑같은 것 아닌가요?" 아닙니다. 그 차이가 바로 핵심입니다.

프롬프트 (Prompt)는 단일 메시지입니다. 한 번의 턴 (turn) 동안만 존재하다가 사라집니다. 관리되는 요구사항 (Requirement)은 대화보다 더 오래 지속됩니다. 요구사항은 에이전트가 경로를 벗어날 때 다시 돌아가야 할 지점이며, 첫 번째 에이전트가 컨텍스트 제한 (context limit)에 도달했을 때 두 번째 에이전트가 읽게 될 내용이며, 검증 (verification) 단계에서 빌드 결과물을 대조하여 확인하는 기준입니다. 프롬프트는 지금 당장 에이전트와 대화하는 방식입니다. 요구사항은 제품이 자신이 무엇이어야 하는지를 기억하는 방식입니다.

두 가지를 나란히 놓아보겠습니다:

프롬프트: "사용자가 비밀번호를 재설정할 수 있는 방법을 추가해 주세요. 보안을 유지해야 합니다."

요구사항: "인증된 사용자와 인증되지 않은 사용자 모두 이메일을 통해 비밀번호 재설정을 요청할 수 있다. 재설정 링크는 30분 후에 만료되며 단 한 번만 사용할 수 있다. 성공 시, 해당 사용자의 모든 기존 세션은 무효화된다. 재설정 요청은 이메일당 시간당 5회로 속도 제한 (Rate-limit)을 둔다. 시스템에 이메일 존재 여부와 관계없이 동일한 확인 메시지를 표시한다."

프롬프트는 비밀번호 재설정 기능을 만들어 줍니다. 어떤 동작을 얻게 될지는 그날 에이전트의 기분에 달려 있습니다. 요구사항은 그러한 동작들을 얻게 해주며, 더 중요한 것은 에이전트가 완료되었다고 말할 때 확인해야 할 다섯 가지 구체적인 항목을 제공한다는 점입니다. "보안을 유지하세요"는 검증할 수 없습니다. "재설정 링크는 30분 후에 만료된다"는 검증할 수 있습니다. 이러한 검증 가능성 (checkability)이 요구사항 관리가 존재하는 이유 전체이며, 아무리 상세하더라도 좋은 프롬프트가 제공할 수 없는 바로 그 지점입니다. 프롬프트는 나중에 보관하고 대조하며 검증할 수 있는 대상이 아니기 때문입니다.

이 과정이 루프(loop) 내에서 차지하는 위치

요구사항 관리는 시작할 때 한 번만 수행하는 단계가 아닙니다. 이는 빌드 루프 (build loop)에서 다른 모든 것이 의존하는 부분입니다. 계획 (Plan), 빌드 (Build), 검증 (Verify), 반복 (Repeat): 계획 단계는 요구사항이 캡처되고 유지되는 곳이며, 검증 단계는 요구사항이 확인되는 곳입니다. 첫 번째 단계를 건너뛴다면, 마지막 단계에는 대조할 대상이 아무것도 남지 않게 됩니다.

flowchart LR
    A[아이디어 (Idea)] --> B[수락 기준 (Acceptance criteria)과 함께<br/>요구사항으로 캡처]
    B --> C[요구사항에 따라<br/>에이전트가 구축]
...

요구사항이 일회성 입력이 아니라 중심 허브(hub)라는 점에 주목하세요. 작업 시작 2주 후에 마음이 바뀌면 요구사항을 변경하고, 검증(verify) 단계는 이제 새로운 목표를 기준으로 확인하게 됩니다. 이것이 바로 "유지 관리 (maintain)" 활동이 제 역할을 수행하는 방식입니다. 반면, 새로운 채팅창에서 마음을 바꾸고 에이전트가 지난 6개의 결정을 기억하기를 바라는 방식은 앱이 아무도 설명할 수 없는 상태로 표류하게 만드는 원인이 됩니다.

이것이 바로 BrainGrid가 메우기 위해 만들어진 간극입니다. 사용자가 아이디어를 설명하면, 플래닝 에이전트 (Planning Agent)가 이를 실제 수락 기준 (acceptance criteria)을 갖춘 요구사항으로 변환합니다. 이 과정에서 사용자가 무심코 운에 맡겼던 결정들을 끌어내는 명확화 질문 (clarifying questions)을 던지며, 코드가 존재하기 전에 해당 요구사항이 실제로 구축될 준비가 되었는지 점수를 매깁니다. 그다음 빌더 에이전트 (Builder Agent)가 BrainGrid의 클라우드 내에서, 혹은 Claude Code, Cursor, 또는 Codex를 통해 사용자의 자체 리포지토리 (repo)에서 해당 요구사항에 따라 구축을 진행합니다. 그리고 검증 (verification) 단계는 완성된 작업물을 모든 기준에 따라 확인하므로, "완료 (done)"는 느낌이 아니라 증거가 됩니다. 요구사항은 제출하고 잊어버리는 문서가 아닙니다. 그것은 전체 루프가 돌아가는 척추이며, 제품 기록 (product record)에 축적되어 다음 기능이 빈 프롬프트 (blank prompt)가 아닌 앱의 현재 상태로부터 시작할 수 있게 합니다. 이는 실제로 중요한 세 가지 산출물 (the three artifacts that actually matter), 즉 요구사항, 수락 테스트 (acceptance tests), 그리고 코드라는 순서 뒤에 숨겨진 것과 동일한 규율입니다.

솔직한 트레이드오프 (The honest trade-off)

요구사항을 작성하는 것은 프롬프트를 던지고 무언가 나타나는 것을 지켜보는 것보다 시작 단계에서 더 느립니다. 이는 사실이며, 그렇지 않은 척하는 것은 부정직한 일일 것입니다. 에이전트가 이미 생성 작업을 할 수 있는 상황에서, 기능의 "완료 (done)"가 무엇을 의미하는지 정의하는 데 쓰는 첫 10분은 마치 오버헤드 (overhead)처럼 느껴질 수 있습니다.

그 대가는 나중에 나타납니다. 요구사항 (requirements)을 건너뛰는 비용은 첫 번째 기능에서 지불되지 않습니다. 그것은 네 번째 기능에서 지불됩니다. 에이전트 (agent)가 당신이 전혀 보지 못한 수십 가지의 결정을 조용히 내렸을 때, 그리고 그 결정들을 풀어내는 데 오후 시간과 엄청난 양의 토큰 (tokens)이 소모될 때 말입니다. 당신은 지금 10분의 명확함을 선택할 것인지, 아니면 나중에 오후 내내 고고학적 발굴 작업을 할 것인지 사이에서 선택하고 있는 것입니다. 그냥 한 번 써보고 버릴 주말용 장난감이라면, 진심으로 건너뛰어도 좋습니다. 하지만 계속 유지하고, 관리하며, 사용자 앞에 내놓을 의도가 있는 것이라면, 10분의 투자는 매번—즉, 모든 기능마다—승리할 것입니다.

핵심 요약 (The takeaway)

요구사항 관리 (requirements management)는 소프트웨어 분야에서 가장 기업용 (enterprise)스러운 문구처럼 들리며, 실제로 수십 년 동안 그러했습니다. AI 빌더 (AI builders)들은 이 과정이 해결하는 문제는 물려받았지만, 그 실행 방식은 물려받지 못했습니다. 이것이 바로 수많은 '바이브 코딩 (vibe-coded)' 앱들이 아무도 진단할 수 없는 벽에 부딪히는 이유입니다. 해결책은 컴플라이언스 제품군 (compliance suite)이 아닙니다. 요구사항을 현재의 정의대로 다루는 것입니다. 즉, 에이전트가 읽는 빌드 입력값 (build input), 검증 (verification) 단계가 확인하는 목표 (target), 그리고 채팅이 종료된 후에도 제품이 유지하는 기억 (memory)으로 취급하는 것입니다. 에이전트가 빨라질수록, 기록된 의도 (written-down intent)만이 당신이 의도한 것과 당신이 출시한 것 사이의 경계선을 지켜주는 유일한 수단이 됩니다.

자주 묻는 질문 (FAQ)

요구사항 관리 (requirements management)란 무엇인가요?

요구사항 관리란 소프트웨어가 무엇을 해야 하는지를 포착하고, 이해도가 변함에 따라 해당 명세들을 최신 상태로 유지하며, 구축된 소프트웨어가 이를 준수하는지 확인하는 관행입니다. 전통적으로 이는 규제 산업을 위한 무거운 기업용 도구들을 의미했습니다. AI 빌더들에게 있어 이는 더 단순하고 직접적입니다. 요구사항은 당신의 코딩 에이전트가 그에 맞춰 구축하는 계획이자, 당신의 검증 단계가 확인하는 기준입니다.

AI 빌더와 바이브 코더 (vibe coders)에게도 실제로 요구사항 관리가 필요한가요?

네, 그리고 어쩌면 전통적인 팀들보다 더 필요할 수도 있습니다. 당신의 의도를 오해하는 빠른 코딩 에이전트 (coding agent)는 잘못된 것을 전속력으로 만들어낼 뿐만 아니라, 심지어 자신의 잘못된 가정을 검증하는 테스트를 작성할 수도 있습니다. 관리된 요구사항 (managed requirement)은 에이전트가 스스로 내릴 법한 결정들을 고정해 주는 역할을 합니다. 기업용 도구 (enterprise tooling)가 필요한 것은 아니지만, 의도 (intent)를 포착하고, 유지하며, 검증하는 과정은 반드시 필요합니다.

상세한 프롬프트 (prompt)가 요구사항과 같은 것인가요?

아니요. 프롬프트는 단 한 번의 대화 턴 (conversation turn) 동안만 존재하다가 사라집니다. 요구사항은 대화보다 더 오래 지속됩니다. 요구사항은 에이전트가 경로를 벗어날 때 다시 돌아가야 할 지점이며, 첫 번째 에이전트가 컨텍스트 제한 (context limit)에 도달했을 때 두 번째 에이전트가 읽어야 할 내용이고, 당신의 검증 (verification) 단계가 완성된 빌드물을 대상으로 확인하는 기준입니다. 프롬프트가 현재 에이전트와 대화하는 방식이라면, 요구사항은 제품이 자신이 무엇이어야 하는지를 기억하는 방식입니다.

요구사항 관리 (requirements management)와 요구사항 관리 소프트웨어의 차이점은 무엇인가요?

요구사항 관리는 실무적인 관행 (포착, 유지, 검증)을 의미합니다. 요구사항 관리 소프트웨어는 추적성 매트릭스 (traceability matrices), 승인 워크플로 (sign-off workflows), 감사 추적 (audit trails) 등을 갖추고 규제 대상 프로그램들을 위해 대규모로 이를 수행하도록 구축된 기업용 도구 (enterprise tools) 카테고리를 의미합니다. 대부분의 AI 빌더들에게는 그런 장치가 필요하지 않습니다. 그들에게 필요한 것은 빌드 루프 (build loop) 내에 내장되어, 에이전트가 실제로 명세 (spec)를 읽는 곳과 가까운 곳에 위치한 실무적인 관행입니다.

AI 에이전트가 구현할 수 있는 요구사항을 어떻게 작성하나요?

의도가 아닌, 확인 가능한 동작 (checkable behavior)으로 작성하세요. "로그인을 안전하게 만들어줘" 대신에 관찰 가능한 사실들을 명시해야 합니다: 세션 만료 (session expiry), 속도 제한 (rate limits), 성공 및 실패 시 발생하는 일, 각 경우에 사용자가 보게 되는 것 등입니다. 각 문장은 나중에 구축된 앱을 대상으로 참 또는 거짓인지 확인할 수 있는 것이어야 합니다. 만약 어떤 문장이 확인될 수 없다면, 그것은 요구사항이 아니라 바람 (wish)일 뿐입니다. 전체적인 방법론은 AI 에이전트가 실제로 검증할 수 있는 수락 기준 (acceptance criteria) 작성법을 참조하세요.

BrainGrid는 당신의 아이디어를 에이전트가 구축할 수 있는 요구사항(requirement)으로 변환하고, 그 구축 결과가 요구사항과 일치함을 증명하는 계획 우선(plan-first) 앱 빌딩 플랫폼입니다. braingrid.ai에서 체험해 보세요.

원문은 BrainGrid 블로그에 게시되었습니다.