11장. Spec과 BDD는 코드 이전의 공통언어다

개발하지 않더라도 spec은 필요하다.

이 문장은 중요하다. Spec과 BDD는 개발 산출물이기 전에 조직의 공통언어 도구다. 코드로 만들지 않더라도 필요하다. 오히려 코드로 만들기 전일수록 더 필요하다.

업무는 사람마다 머릿속 정의가 다르다.

"입사 처리 끝났어?"라는 말 하나를 두고도 팀마다 다른 장면을 떠올린다. 인사팀은 계약서가 서명되었으면 끝났다고 느낄 수 있다. 총무팀은 장비가 지급되어야 끝났다고 본다. IT는 계정이 만들어져야 끝났다고 본다. 재무는 급여 정보가 들어와야 끝났다고 본다. 대표는 첫 출근에 문제가 없어야 끝났다고 본다.

모두 같은 말을 쓰지만 서로 다른 완료 정의를 들고 있다.

이때 필요한 것이 spec이다.

Spec은 업무 객체의 공통 정의다. 이 업무에서 무엇을 객체로 볼지, 어떤 상태가 있는지, 어떤 조건을 만족해야 다음 상태로 넘어가는지, 누가 책임지는지, 무엇이 완료인지 정한다. Spec은 업무의 철학 선언이 아니다. 업무의 물리법칙이다.

BDD는 그 정의가 실제 장면에서 어떻게 적용되는지 맞춰보는 문장이다.

SOP와 매뉴얼은 보통 순서로 쓴다.

• 신청서를 받는다
• 담당자가 확인한다
• 승인권자에게 전달한다
• 처리한다
• 기록한다

이 구조는 정상 흐름에는 좋다. 하지만 실제 업무는 정상 흐름보다 예외에서 깨진다.

• 신청서가 불완전하면?
• 승인권자가 휴가면?
• 긴급 건이면?
• 증빙이 없으면?
• 금액이 기준을 넘으면?
• 이미 처리된 요청이 중복으로 들어오면?
• 퇴사자가 장비를 반납하지 않으면?

SOP는 기본 루트를 쓴다. BDD spec은 그 루트가 현실의 조건과 예외 속에서도 같은 의미로 작동하게 만든다.

Cucumber식 BDD 문법은 그래서 개발 테스트 이전에 업무 문서로 유용하다.

예를 들면 이렇게 쓴다.

• Given 신규 직원의 입사일이 내일이고
• And 근로계약서는 서명 완료되었고
• And 노트북은 아직 배정되지 않았고
• When 경영지원팀이 입사 준비 상태를 확인하면
• Then 입사 상태는 "준비중"이어야 한다
• And "입사완료"로 표시하면 안 된다
• And 총무 담당자에게 장비 배정 요청이 떠야 한다

이 문장은 테스트 코드가 아니다. 공통언어다.

이 시나리오를 읽으면 팀은 바로 알게 된다. 입사완료란 계약서만 받은 상태가 아니다. 장비, 계정, 급여 정보, 서류가 특정 조건을 만족해야 하는 상태다. "완료"라는 단어가 사람의 감각에서 빠져나와 조직의 규칙이 된다.

퇴사 오프보딩도 마찬가지다.

• Given 직원이 "퇴사예정" 상태이고
• And 퇴사일이 오늘이고
• And 노트북이 "미반납" 상태이면
• When 인사 담당자가 "퇴사완료"로 변경하려고 하면
• Then 상태 전이는 거부되어야 한다
• And 총무 담당자에게 장비 회수 요청이 생성되어야 한다
• And 오프보딩 체크리스트에는 "장비 회수 대기"가 표시되어야 한다

이 문장을 보면 퇴사완료가 단순히 마지막 출근이 끝났다는 뜻이 아니라는 사실이 고정된다. 장비 회수, 계정 회수, 급여 정산, 서류 보관까지 포함하는 조직 언어가 된다.

SOP는 해야 할 일을 순서로 쓴다.

BDD spec은 그 일이 특정 상황에서 어떻게 판단되어야 하는지를 사례로 쓴다.

따라서 매뉴얼의 정석 구조는 이렇게 된다.

• 업무 객체 정의
• 상태 목록
• 기본 SOP
• Cucumber-style BDD scenarios
• 예외/리스크
• SLA/SLO
• 기록/증빙
• 책임자/승인권자

이 구조가 있으면 교육도 쉬워진다. 인수인계도 쉬워진다. 나중에 앱으로 만들 때도 그대로 설계 재료가 된다. 그러나 앱으로 만들지 않아도 이미 효과가 있다. 사람들이 같은 단어를 같은 장면으로 이해하기 때문이다.

업무를 코드로 만들기 전에 먼저 말이 같아져야 한다.

Spec은 업무 객체의 공통 정의이고, BDD는 그 정의가 실제 상황에서 어떻게 적용되는지 맞춰보는 조직의 공통언어다.