QA 엔지니어로 10년 이상 일해 왔습니다.

장애의 근본 원인을 추적해 보면, 결국 「사양(Specification) 작성이 나빴다」와 「요건(Requirement)이나 수락 기준(Acceptance Criteria)이 모호했다」로 귀결되는 케이스가 많습니다. 쓸 시간이 없었다는 이유로.

구현 버그든 테스트 누락이든 상상력의 결여 때문이기도 하지만, 애초에 사양 단계에서 조건이나 동작(Behavior)이 다 쓰여 있지 않은 일이 당연하게 있었습니다. 있었습니다.

그래서 구현자는 상상으로 보충하고, 테스트 설계자는 어디를 테스트할지 확신을 갖지 못해, 결과적으로 장애가 발생하는 케이스가 많았다고 절실히 느끼고 있습니다.

그래서 나름대로 「상류 공정의 사양 품질이 하류 공정을 어떻게 망가뜨리는가」를 정리하고, 실무적인 대책을 제안할 수 있으면 좋겠다고 생각하고 있습니다.

제가 보는 「좋지 않은 사양」이란, 조건과 동작의 대응 관계가 다 쓰여 있지 않은 사양을 말합니다.

예를 들어 「금액에 따라 할인을 적용한다」라는 사양이 있다고 가정해 봅시다. 있다고 가정해 봅시다.

지적할 부분이 있을 것 같지만, 일단 제가 바로 떠올린 것이 아래와 같으므로 그것으로 진행하겠습니다.

• 그 금액의 경계는 어디인가 (5,000엔 단위 등 정해진 배수인지, 자유롭게 설정할 수 있는지)
• 경계마다 할인율을 변경할 수 있는가, 일률적인가
• 잔돈은 사사오입(반올림)인가, 버림인가, 올림인가
• 다른 할인(쿠폰 등)과의 병용은 가능한가, 불가능한가
• 다른 할인과의 우선순위는 어느 쪽이 높은가
• 세금을 포함하는가, 포함하지 않는가
• 본체 이외, 즉 배송비·수수료는 포함하는가

구현자는 이 모호함을 「아마 이럴 것이다」로 채웁니다.

QA는 「아마 이렇게 읽힐 것이다」로 테스트 케이스를 만듭니다.

이 두 가지 「아마」가 어긋날 때, 장애가 발생합니다.

설령 장애가 발생하지 않더라도 PdM(Product Manager)이나 요청자가 다르다고 말하면 끝입니다.

그렇게 되기 전에, 스프린트 계획에 넣기 전에 확인하거나, 리파인먼트(Refinement)를 제대로 하자

반면, 「5,000엔 미만은 할인 없음, 5,000~10,000엔은 5%, 10,001엔 이상은 10%로 고정, 쿠폰과 병용 시에는 할인율이 높은 쪽을 적용, 잔돈은 버림」이라고 적혀 있다면, 구현도 테스트 설계도 일의적으로 결정됩니다.

상상으로 보충할 여지가 없기 때문입니다.

여기서 비즈니스 요건과 비교하며 리파인먼트에서 고민하는 것이 묘미. 확장성까지 고려하면 더욱 좋다.

여기서 주의해야 할 점은 사양은 하나의 통덩어리가 아니라는 것입니다. 많은 개발 현장에서 사양은 다음과 같은 두 개의 층으로 나뉘어 있습니다.

기능 사양 (기초 사양) — PdM이나 PO(Product Owner)가 작성하는 「무엇을 만들 것인가」. 비즈니스 로직, 사용자 관점에서의 동작, 수락 기준. 「5,000엔 이상이면 무료 배송」과 같은 이야기가 여기에 해당합니다.

기술 설계 (구현 사양) — EN(Engineer)이 작성하는 「어떻게 만들 것인가」. DB 설계, API 설계, 기존 테이블과의 관계, 퍼포먼스 요건, 에러 핸들링 방침.

「좋지 않게 되는」 패턴은 두 가지가 있습니다.

첫 번째는 기능 사양 단계에서 모호한 케이스. 앞서 말한 할인 예시가 이에 해당합니다.

조건과 동작이 다 쓰여 있지 않기 때문에, 엔지니어도 테스트 엔지니어도 상상으로 보충하게 됩니다.

두 번째는 기능 사양은 명확한데, 기술 설계로 옮길 때 어긋나는 케이스입니다.

예를 들어 기능 사양에 「5,000엔 이상이면 무료 배송」이라고 적혀 있어도, 기술 설계에서 「세금 포함인가 세금 별도인가」, 「포인트 사용 후의 금액인가 사용 전인가」가 정의되어 있지 않으면 구현자의 해석으로 결정되어 버립니다.

어느 층에서 모호함이 스며들더라도 결과는 같습니다. 이보다 더 하류 공정이 망가질 가능성이 커집니다.

개발 플로우를 정리하면 사양의 모호함이 어디서 현상화되는지 보입니다.

시장 조사 / 요청 수리
↓
요건 정의
...

사양의 모호함은 대체로 수락 기준 작성 단계부터 스며들기 시작합니다.

그리고 모호함은 하류 공정으로 전파됩니다.

개발 측은 모호한 사양을 **「자신의 해석」**으로 구현합니다.

QA 측은 모호한 사양을 **「자신의 해석」**으로 테스트 설계합니다.

이 두 가지 해석이 우연히 일치하면 장애는 발생하지 않지만, 뭐, 그런 일은 없습니다.

일치하지 않으면 리뷰 단계에서 비로소 「사양의 의도는 어느 쪽이었는가」라는 논의가 시작됩니다.

즉, 리뷰가 상류 공정에서 막을 수 있었을 모호함을 알아챌 수 있는 첫 번째 기회입니다.

그리고 다음 깨달음의 기회는 테스트 실시 단계이지만, 이곳을 지나면 장애나 의도하지 않은 손실로 직결됩니다.

가령 테스트 실시 혹은 릴리스 직전에 알아챘다고 칩시다.

이 단계에서의 재작업(Rework)은 장애를 제외하면 가장 비용이 높습니다.

• 구현은 완료되어 있다.
• 테스트는 시작되었다.
• 경우에 따라서는 릴리스(Release) 날짜가 임박해 있다.

거기서부터 사양(Specification)에 대한 인식을 다시 맞추게 된다…… 자, 이제 야근할 시간입니다!!

얌전하게 릴리스를 미룹시다. 다른 문제도 분명히 나올 겁니다. 저라면 그렇게 하겠습니다.

최소한 설계 리뷰(Design Review)와 관점 리뷰(Perspective Review) 단계에서 **상호 리뷰(Mutual Review)**를 수행하는 것이 중요합니다.

개발과 QA가 각각 별도로 리뷰하는 것이 아니라, QA가 사양을 읽고 테스트 설계의 관점에서 피드백을 주는 것입니다.

다만 "이 사양으로 테스트할 수 있나요?"라는 식의 질문은 당연하게도 상대방이 "어, 싸우자는 건가?"라고 느끼게 만듭니다.

리뷰에 동석했다면 아마 꽤나 납작 엎드려 사죄해야 할 상황일 겁니다. 술이라도 한잔 사야죠. 그랬습니다. 한 8년 전쯤에.

그래서 다음과 같은 관점으로 확인합니다.

• 조건의 망라성(Comprehensiveness): 이 기능의 입력에 대한 조건 분기가 전부 작성되어 있는가.
• 동작의 명확성(Clarity of Behavior): 각 조건에 해당했을 때의 처리는 입력값에 따라 결과가 달라지는가? 달라진다면 그 경계(Boundary)는 어디인가.
• 기존 기능과의 정합성(Consistency with Existing Features): 신규 기능의 조건이 기존의 할인, 포인트, 캠페인 등과 결합되었을 때, 우선순위나 계산 순서가 명시되어 있는가. (아마 가장 놓치기 쉬운 부분)
• 이상계(Exception Path)의 정의: 조건에 해당하지 않는 케이스(경계 외, null, 예상치 못한 타입)의 동작은 정의되어 있는가.

이러한 질문들에 대해 사양서를 보고 알 수 있다면, 그 사양은 "결이 좋다(筋が良い)"라고 할 수 있습니다.

답할 수 없다면 사양이 부족한 것입니다.

경험상, 무서운 점은 게으름을 피우는 것이 아니라 그냥 자각이 없는 경우도 종종 있다는 것입니다. 자각이 없는 게 가장 무섭습니다.

리뷰에서 "무엇을 물어볼지"를 알더라도, 그것을 매번 사람의 의식만으로 돌리는 데에는 한계가 있습니다.

사양의 품질을 조직적으로 담보하기 위해, 다음과 같은 3가지 메커니즘을 도입하면 대체로 좋은 결과를 얻을 수 있습니다.

특히 지금이라면 AI를 활용하지 않을 이유가 없으므로, 저 나름의 현대적인 해석을 내놓겠습니다.

티켓이나 리파인먼트(Refinement) 자료에 기록해 둡시다.

지금은 회의록 AI도 있으니 각 이벤트 후에 작성하는 것도 간단할 것이라 생각합니다.

기록하는 것, 제가 좋아하는 말입니다.

※ 품질 게이트(Quality Gate)란, 다음 공정으로 넘어가기 전에 "이 기준을 충족하는가"를 확인하는 검문소 같은 이벤트입니다.

기준을 충족하지 못하면 앞으로 나아갈 수 없다는 규칙을 만듦으로써, 모호한 사양이 하류(Downstream)로 흘러가는 것을 방지합니다.

1. 리파인먼트 단계에서의 자동 체크

리파인먼트 완료 시, 사양서를 AI에 통과시켜 조건의 누락을 기계적으로 체크합니다.

리파인먼트에서의 티켓 완료 조건에 이 체크 통과를 포함함으로써, 개인의 역량에 의존하는 속성(Person-dependency)을 배제할 수 있습니다.

※ Devin 등을 사용하여 Git 리포지토리로부터 자연어로 된 사양서를 자동 생성하고, 그것을 베이스로 조건의 망라성을 검증하는 방법도 유효합니다.

※※ 혹은 처음에는 빠져나가는 것이 있다고 가정하고 skills 등으로 보완하십시오. 작게 만들어서 완성을 향해 장기적으로 노력하는 방향으로 갑시다.

2. AI를 활용한 정합성 검증

신규 기능의 사양과 기존 기능의 사양을 AI에 읽히고, 모순이나 조건의 누락을 검출합니다.

기능이 쌓여가는 프로덕트는 인간의 리뷰만으로는 기존 사양과의 불일치를 놓치기 쉽기 때문에, AI에 의한 보완이 효과적입니다.

※ 이 체크는 수락 기준(Acceptance Criteria) 확정 직후부터 사양이 굳어진 직후 사이에 배치하면 꽤 효과적입니다.

3. 장애 발생 시의 피드백 루프

장애 발생 시의 근본 원인 분석(RCA)에서 "리파인먼트 등의 각 페이즈에서 잡아낼 수 있었던 사양 누락이었는가"를 확인하고, 프로세스 개선으로 연결합니다.

구체적으로는, 장애 티켓(또는 테스트 중 발견된 버그 티켓에도)에 "요건 기인", "수락 기준 기인", "사양 기인", "구현 기인", "테스트 누락" 등 개발 플로우별로 라벨을 붙여 비율을 시각화합니다.

이 수치가 있으면, 회고(Retrospective)에서의 논의가 "주의합시다"로 끝나지 않고, "사양 기인이 전체의 ○%를 차지하고 있으니 상류(Upstream) 체크를 강화하자"라는 구체적인 액션으로 이어집니다.

특히 팀이 많아져 단독 스크럼에서 LSM(Large Scale Scrum)으로 이행하는 시점이나, 각 프로덕트 간의 연계가 필수적이 되는 페이즈부터 효과가 나타납니다.

품질 게이트 도입을 제안해도 채택되지 않거나 정착되지 않는 경우가 있습니다. 흔한 패턴과 대책을 정리합니다.

패턴 1: 속도 중심의 문화

스타트업이나 신규 사업 페이즈에서 "일단 내보내고 고치자"가 문화로 자리 잡고 있다면, 품질 게이트는 릴리스 속도를 늦추는 족쇄처럼 보입니다.

대책으로는 품질 게이트 자체를 가볍게 만드는 것입니다. AI에 의한 자동 체크라면 몇 분 만에 완료됩니다. "인간의 리뷰 회의를 늘린다"가 아니라 "AI에게 사양을 통과시킨다"라는 방식으로 보여준다면, 속도와의 양립이 가능하다는 점을 보여줄 수 있습니다.

패턴 2: 기준의 모호함

"AI에 통과시켜 체크한다"라고 해도, 무엇을 기준으로 통과시킬지가 정의되어 있지 않으면 매번 판단이 개인의 역량에 따라 달라집니다.

결국 "통과한 것으로 치자"가 상시화되어 폐지되는 패턴입니다.

대책은 통과 기준을 구체적으로 정의하는 것입니다.

예를 들어 큰 틀로서 "모든 조건 분기(Condition Branch)에 대해 입력과 출력의 조합이 명기되어 있을 것", "이상계(Exception Case)의 동작이 정의되어 있을 것"과 같이, Yes/No로 판정할 수 있는 기준으로 삼습니다.

품질 게이트(Quality Gate)의 공수는 눈에 보이지만, 품질 게이트가 없었기 때문에 발생했을 재작업(Rework) 공수는 눈에 보이지 않습니다.

"매 스프린트마다 2시간이 소요된다"는 말은 할 수 있어도, "없었다면 재작업으로 10시간이 소요되었을 것이다"는 증명하기 어려워 예산이나 리소스 승인을 받지 못합니다.

대책은 앞서 언급한 장애 티켓의 "요건 기인/수락 기준 기인/사양 기인/구현 기인/테스트 누락" 라벨입니다.

품질 게이트 도입 전후로 사양 기인 장애 건수와 재작업 공수를 비교할 수 있다면, 비용 대비 효과를 숫자로 보여줄 수 있습니다.

테스트 블로킹(Test Blocking) 시간도 포함해도 좋습니다.

PdM은 "기능 사양은 작성했다, 나머지는 엔지니어의 책임"이라고 생각하고, 엔지니어는 "사양이 모호한 것은 PdM의 책임"이라고 서로 생각하고 있다면, 품질 게이트를 누가 주도할지를 두고 다투게 되어 도입이 중단됩니다.

대책은 품질 게이트의 운영을 QA가 담당하는 것입니다.

QA는 기능 사양도 기술 설계도 테스트 설계의 관점에서 읽는 입장에 있기 때문에, 어느 계층에 모호함이 있는지를 중립적으로 지적할 수 있습니다.

책임을 서로 떠넘기는 것이 아니라, "사양의 품질을 팀 전체에서 높인다"는 방향으로 이끌 수 있습니다.

QA가 없는 팀의 경우에는 다른 팀의 PdM이나 EN에게 의뢰할 수 있는 조직적인 유연함을 갖추도록 합시다.

3가지 메커니즘을 갑자기 모든 팀에 도입하면 허들이 높기 때문에, 하나의 팀부터 전개하는 것이 현실적입니다.

사양 기인 장애가 많은 팀보다, 팀의 수용성(Acceptance)이 높은 곳부터 시작하는 것을 추천합니다.

가능한 한 빨리 적절한 피드백(FB)을 얻는 것이 목적이기 때문입니다.

따라서 AI에 거부감이 없고, 리파인먼트(Refinement) 등도 원활히 돌아가는 팀이 결과적으로 좋든 나쁘든 결과를 내줍니다.

밑작업으로 다른 팀의 회식 자리에 얼굴을 비추고 다니는 것이 편하다는 사실은 레이와 시대에도 변함이 없습니다.

"AI 품질 게이트를 도입했더니 사양 기인 장애가 이만큼 줄었다"라는 실적이 있다면, 다른 팀으로의 전개는 매끄럽게 진행됩니다.

숫자 없이 일제히 도입하려고 하면 "공수만 늘어난다"라는 저항이 나오므로, 이는 반드시 피해야 합니다.

먼저 1개 팀에서 증명하는 것이 지름길입니다.

• 장애의 대부분은 사양이 조건과 동작을 다 써내지 못한 것에 기인한다.
• 사양의 모호함은 개발과 QA로 전파되어, 테스트 실시 단계에서 가장 비용이 높은 재작업을 발생시키며, 최악의 경우 장애와 사양 변경 비용도 커진다.
• 리뷰에서는 "조건 분기가 전부 작성되어 있는가", "각 조건의 동작이 입력값에 따라 변하는가"를 구체적으로 질문하고 리파인먼트 자료에 기록한다.
• AI 품질 게이트, 기존 사양과의 정합성 체크, 장애 기인 사후 분석의 3가지를 규칙화한다.
• 도입은 수용성이 높은 1개 팀부터 시작한다.

상류 공정의 사양 품질은 테스트 기법이나 테스트 자동화로는 보완할 수 없습니다.

테스트는 사양이 완벽히 작성되어 있어야 비로소 신뢰할 수 있는 것이 됩니다.

품질을 하류에서 담보하는 것이 아니라, 상류에서 만들어 나갑니다.

이를 위한 메커니즘을 우선 하나의 팀부터 시작해 보세요.

작게 만들고, 작게 전파하며, 작은 결과를 추구하십시오.

천리 길도 한 걸음부터, 제가 좋아하는 말입니다.