화면이 열리고 테스트가 모두 통과하면, 작업을 마쳤다고 적기 쉽습니다. 화면과 테스트가 같은 요구를 확인했는지는 그 문장만으로 알 수 없습니다.
저는 2026년 8월 수업에서 사용할 채용관리시스템을 만들며 이 차이를 봤습니다. 가상의 기업이 보낸 제안요청서에서 시작해 요구사항, 접수 화면, 테스트까지 연결했습니다. 요구가 어디로 이어지는지 적은 연결표에는 21건이 들어갔습니다.
시스템 전체의 자동 테스트 182건이 통과했고 주요 화면 주소도 정상 응답했습니다. 182건은 요구 21건과 일대일로 대응하는 숫자가 아닙니다. 기업과 제안요청서는 가상으로 만들었지만, 테스트 통과 건수는 실제 실행 기록입니다. 브라우저에서 실제로 클릭해 보는 검증은 남아 있었습니다.
막힌 곳: 문서는 연결됐지만 확인 상태가 달랐습니다
처음에는 제안요청서의 문장을 기능으로 옮기고, 기능마다 테스트를 붙이면 충분하다고 생각했습니다. 하지만 요구사항 하나를 따라가 보면 확인의 종류가 달랐습니다. 전체 시스템에서는 주요 화면 주소 응답도 확인했지만, 이는 특정 요구의 사용자 동작을 증명하지 않습니다. 주소가 응답한다는 것은 서버가 페이지를 돌려줬다는 뜻입니다. 공고 목록을 열 수 있다는 요구에는 화면 빌드, 즉 실행할 프로그램을 만드는 검사 기록만 있었고, 열람 동작을 확인한 자동 테스트나 브라우저 기록은 없었습니다.
작업 진행률만 보여주면 이 차이가 사라집니다. 21건 중 몇 건을 구현했는지보다, 각 요구에 어떤 근거가 있고 무엇을 아직 확인하지 못했는지가 더 필요했습니다.
요구공학 문서에서 같은 질문을 찾았습니다
SDD는 명세 주도 개발(Spec-Driven Development)의 약자입니다. 무엇을 만들지 정한 명세를 설계, 작업, 구현, 검증까지 이어서 쓰는 방식입니다. GitHub의 Spec Kit은 명세에서 계획과 작업 목록을 만들고, 구현 결과가 명세와 맞는지 다시 확인하는 흐름을 제공합니다. AI 개발 도구 Kiro는 요구사항, 설계, 작업을 각각 문서로 남깁니다. 저는 이 도구들을 사례에 적용한 것이 아니라, 사례의 판단을 돌아보기 위해 공식 문서를 대조했습니다.
새 도구가 등장하기 전부터 요구공학, 즉 요구를 명확히 적고 검증하는 분야는 같은 질문을 다뤘습니다. ISO/IEC/IEEE 29148은 요구사항을 관리하는 기준을 다룹니다. NASA의 요구사항 작성 지침은 요구가 모호하지 않고 검증 가능해야 한다고 묻습니다. 제 작업에서는 “이 요구를 충족했는지 무엇으로 확인할까”라는 질문이 연결표의 빈칸을 찾는 기준이 됐습니다.
예를 들어 ‘지원서 제출이 잘돼야 한다’는 문장만으로는 결과를 판정하기 어렵습니다. ‘필수 항목이 비어 있을 때 접수를 저장하지 않고 누락 항목을 표시한다’고 적으면 입력 조건과 기대 결과가 생깁니다. 여기에 실제로 확인할 방법을 붙여야 테스트 통과와 화면 확인을 구분할 수 있습니다. 이 문장은 설명을 위한 예시이며, 위 채용관리시스템의 실제 요구사항을 옮긴 것은 아닙니다.
바꾼 결정: 진행률 대신 요구별 근거를 보여줬습니다
교육 과정에는 채용 지원자가 보는 접수 화면과 강사가 요구사항을 살펴보는 별도 작업 화면이 있었습니다. 처음 작업 화면은 변경 요청의 진행 상황을 중심에 뒀습니다. 저는 그 중심을 요구사항 추적으로 옮겼습니다. 제안요청서의 항목에서 요구 ID를 거쳐 사용자 관점의 기능, 인수기준, 화면, 테스트 근거까지 따라갈 수 있게 했습니다. 인수기준은 “어떤 조건에서 무엇이 보이면 받아들일지” 정한 기준입니다.
요구별 상태도 ‘로컬 검증’, ‘부분 근거’, ‘추가정보 필요’로 나눴습니다. ‘로컬 검증’은 해당 요구에 개발 환경의 자동 테스트 근거가 있는 상태입니다. 브라우저나 실사용까지 확인했다는 뜻은 아닙니다. ‘부분 근거’는 필요한 근거 중 일부가 비어 있고, ‘추가정보 필요’는 요구에 대한 결정이 먼저 필요한 상태입니다. 원본 연결표 21건 중 17건은 로컬 자동 테스트 근거가 있어 로컬 검증, 4건은 부분 근거였습니다. 추가정보가 필요한 요구는 없었습니다.
공개 공고를 목록에서 열 수 있어야 한다는 요구는 해당 화면의 빌드를 통과했습니다. 이 요구의 열람 동작을 확인한 자동 테스트는 없었습니다. 주요 화면의 주소 응답도 공고 목록 요구의 통과 근거로 옮기지 않았습니다. 실제 브라우저 열람도 확인하지 못해 ‘부분 근거’로 남겼습니다. 연결표 한 줄에는 ‘공고 열람 요구 → 해당 화면 → 빌드 통과 → 열람 동작 미확인 → 부분 근거’가 적혔습니다. 다른 세 건에도 빈칸이 있었습니다. 운영 시간에 서비스를 이용할 수 있는지 관측하는 검사가 없었고, 개인정보를 가리는 테스트는 통과했지만 정해 둔 보존기간에 맞춰 삭제하는 기능과 테스트는 없었습니다. 모바일 화면은 화면 스타일을 코드로 검사하는 단계만 통과해, 실제 크기로 띄워 보는 확인이 남았습니다.
공고 열람 조건이 바뀐다면 이 연결표의 요구 문장과 테스트, 아직 확인하지 못한 브라우저 동작도 함께 다시 살펴야 합니다.
아직 남은 문제: 자동 테스트와 브라우저 확인은 서로 다른 근거입니다
이 사례에서 자동 테스트 통과와 주소 응답은 확인했습니다. 당시 개발 검증을 수행한 작업 환경에는 실제 화면을 띄워 조작할 브라우저가 연결돼 있지 않았습니다. 그래서 클릭 흐름 검사와 모바일 화면 캡처를 실행하지 못했습니다. 사람이 별도로 시연한 기록도 남기지 못했습니다. 이 글은 그 시점의 기록입니다. 확인된 성과는 요구와 검증 근거의 연결, 그리고 검증 공백의 가시화까지입니다. 제품 품질의 변화는 측정하지 않았습니다.
이 방식을 자기 작업에 옮길 때는 기능 하나를 골라 요구 문장, 인수기준, 확인 방법을 먼저 연결해 봅니다. 앞의 예시라면 필수 항목을 비웠을 때 저장되지 않는지 확인하는 식입니다. 확인을 실행하기 전에는 통과로 표시하지 않습니다. 연결할 수 없는 칸이 나오면 그 칸의 결정을 맡을 사람을 찾습니다.
마치며: 명세의 끝에는 확인한 근거가 있어야 합니다
요구별 근거를 연결해 보고 가장 오래 남은 질문은 어디까지 확인했고 어디서 멈췄는지를 말할 수 있는가였습니다. 지금 진행 중인 기능에서 요구사항 한 건만 골라, 그 요구를 확인한 테스트와 아직 보지 못한 화면을 나란히 적어 보시길 권합니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO/IEC/IEEE 29148:2018: https://standards.ieee.org/ieee/29148/6937/
- NASA, How to Write a Good Requirement: https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
- GitHub Spec Kit, Spec-Driven Development Quickstart: https://github.com/github/spec-kit/blob/main/docs/quickstart.md
- GitHub Spec Kit, Spec Persistence Models: https://github.com/github/spec-kit/blob/main/docs/concepts/spec-persistence.md
- Kiro, Feature Specs: https://kiro.dev/docs/specs/feature-specs/