Should, Shall, Must를 기술사양서에서 바꿔 쓰면 안 되는 이유｜Requirement Language의 정확한 의미

기술사양서에서 단어 선택이 중요한 이유

기술사양서나 계약서, 혹은 중요한 프로젝트의 요구사항 정의서를 작성할 때 우리는 흔히 ‘할 수 있다’, ‘해야 한다’, ‘해야만 한다’와 같은 표현을 섞어서 사용합니다. 하지만 엔지니어링이나 법률, 비즈니스 영역에서 이러한 단어는 단순히 문장을 매끄럽게 만드는 도구가 아닙니다. 이는 시스템의 생존과 직결된 ‘요구사항 언어(Requirement Language)’입니다.

왜 Shall, Should, Must를 함부로 바꿔 쓰면 안 될까요? 그 이유는 바로 모호함이 가져오는 비용 때문입니다. 요구사항이 명확하지 않으면 개발자는 잘못된 기능을 구현하게 되고, 발주처는 기대와 다른 결과물을 받게 되며, 결국 프로젝트는 일정 지연과 막대한 추가 비용이라는 대가를 치르게 됩니다. 국제 표준 기구인 ISO나 IEEE, 그리고 수많은 소프트웨어 공학 가이드라인에서 이 단어들을 엄격하게 구분하는 이유가 바로 여기에 있습니다.

요구사항 언어의 핵심 삼총사 이해하기

기술 문서에서 가장 빈번하게 사용되면서도 가장 많이 오해받는 단어 세 가지를 살펴보고, 각 단어가 가진 법적, 기술적 무게를 알아보겠습니다.

Must 그리고 Shall의 결정적 차이

많은 사람이 Shall과 Must를 ‘반드시 해야 하는 것’이라는 의미로 혼용합니다. 하지만 전문적인 사양서 작성 규범에서 이 둘은 미묘하지만 확실한 차이를 가집니다.

• Must: 시스템이 반드시 갖추어야 할 절대적인 제약 사항입니다. 이것이 충족되지 않으면 해당 기능은 실패한 것으로 간주합니다. 주로 보안, 안전, 물리적 한계와 관련된 ‘필수 불가결한 조건’을 명시할 때 사용합니다.
• Shall: 계약상의 의무를 나타냅니다. ‘Shall’이 포함된 문장은 법적 구속력을 가집니다. 즉, 공급자가 고객에게 제공하기로 약속한 기능적 요구사항을 나타낼 때 사용합니다. “시스템은 2초 이내에 응답해야 한다(The system shall respond within 2 seconds)”라고 적혀 있다면, 이는 성능 보증의 근거가 됩니다.

Should의 부드러운 권고

Should는 ‘권장 사항’입니다. 반드시 구현해야 하는 것은 아니지만, 품질 향상이나 사용자 경험을 위해 강력하게 추천하는 기능입니다. 만약 프로젝트 예산이나 시간이 부족하다면 Should로 작성된 항목은 우선순위에서 밀려나거나 생략될 수 있습니다. 이를 Must와 혼용하면 개발자는 모든 것을 다 만들어야 한다고 오해하여 불필요한 리소스를 낭비하게 됩니다.

단어 선택에 따른 오해와 실제 사례

현장에서 흔히 발생하는 오해 중 하나는 “문장을 부드럽게 만들기 위해 단어를 바꾼다”는 점입니다. 예를 들어, “시스템은 로그인 기능을 제공해야 합니다”라고 적어야 할 곳에 “로그인 기능을 제공할 수 있습니다(Can)”라고 적는 경우가 있습니다.

이때 ‘Can’은 가능성을 의미합니다. 즉, 로그인 기능이 있어도 그만, 없어도 그만이라는 뜻으로 해석될 여지가 있습니다. 개발자가 “이 기능은 선택 사항이구나”라고 판단하여 구현하지 않는다면, 나중에 비즈니스 로직에 큰 구멍이 생기게 됩니다. 반대로 ‘Must’를 너무 남발하면 어떻게 될까요? 모든 사소한 UI 요소까지 ‘Must’로 도배된 문서는 개발자에게 극심한 피로감을 주며, 결국 무엇이 정말 중요한 요구사항인지 식별할 수 없게 만듭니다.

표준 요구사항 언어 가이드라인

기술 문서 작성 시 통용되는 표준적인 의미 체계를 표로 정리했습니다. 이 기준을 팀 내에서 공유하는 것만으로도 소통 비용을 획기적으로 줄일 수 있습니다.

비용 효율적인 활용을 위한 실무 팁

정확한 단어 사용은 단순히 문법 공부가 아니라 비용 절감 전략입니다. 다음은 실무에서 바로 적용할 수 있는 유용한 팁입니다.

• 요구사항 사전 정의: 프로젝트 시작 전, 팀원들과 함께 ‘우리 프로젝트에서 Shall과 Should의 정의를 어떻게 내릴 것인가’를 문서화하십시오.
• 단어 일관성 검사: 문서를 작성한 후 Ctrl+F 기능을 활용해 Shall, Should, Must, Can이 의도한 대로 정확히 쓰였는지 전수 조사하십시오.
• 부정문 사용 지양: “시스템은 에러가 발생해서는 안 된다”와 같은 부정문보다는 “시스템은 에러 발생 시 로그를 기록해야 한다”와 같이 긍정문으로 명확한 행동을 정의하십시오.
• 비즈니스 가치에 따른 분류: 요구사항을 나열할 때 Shall(필수)과 Should(권장)를 별도의 섹션으로 나누어 관리하면, 프로젝트 막바지에 우선순위를 결정하기 훨씬 수월합니다.

흔히 범하는 실수와 전문가의 조언

전문가들이 지적하는 가장 큰 실수는 ‘문서의 양’에 집착하는 것입니다. 사양서가 길다고 해서 좋은 문서가 아닙니다. 오히려 핵심 요구사항이 모호한 단어 속에 파묻혀 있을 가능성이 큽니다.

많은 주니어 기획자나 엔지니어들이 ‘Will’이라는 단어를 남용하곤 합니다. “시스템은 데이터를 저장할 것입니다”라고 적는 것은 미래의 막연한 계획일 뿐, 기술적인 의무를 나타내지 않습니다. ‘Will’ 대신 ‘Shall’을 사용하여 명확한 의무를 부여하는 습관을 들이세요.

또한, ‘Must’를 사용할 때는 신중해야 합니다. 모든 것을 ‘Must’로 규정하면 시스템의 유연성이 사라집니다. 정말로 이것이 시스템의 핵심 가치인지, 아니면 나중에 개선해도 되는 부분인지 끊임없이 질문해야 합니다. 전문가들은 “모든 것에 우선순위를 두는 것은, 아무것도 우선순위를 두지 않는 것과 같다”라고 조언합니다.

자주 묻는 질문과 답변

Q: Should를 사용하면 개발자가 구현을 안 할 수도 있지 않나요?

A: 네, 맞습니다. 하지만 그것이 Should의 존재 이유입니다. 리소스가 한정된 상황에서 무엇을 먼저 버릴지 결정할 때 Should는 아주 훌륭한 가이드라인이 됩니다. 만약 반드시 구현되어야 한다면 고민하지 말고 Shall을 사용하십시오.

Q: 기술사양서가 아닌 일반 이메일에서도 이 규칙을 지켜야 하나요?

A: 모든 상황에서 엄격할 필요는 없지만, 협업을 위한 요청사항을 전달할 때는 유용합니다. 특히 외부 업체와 소통할 때 “이 기능은 Should입니다”라고 명확히 하면 상대방도 업무 부담을 덜고 우선순위를 이해하기 쉬워집니다.

Q: 단어를 바꾸지 말라는 것이 문장을 똑같이 복사하라는 뜻인가요?

A: 아닙니다. 문장의 구조는 상황에 맞게 바꾸되, 핵심 동사와 조동사(Shall, Should, Must)만큼은 정의된 의미대로 일관성 있게 사용하라는 뜻입니다.

기술 문서의 완성도를 높이는 한 끗 차이

결국 기술사양서는 읽는 사람과 쓰는 사람 사이의 ‘언어적 계약’입니다. 사소해 보이는 단어 하나가 시스템의 전체 아키텍처를 바꾸기도 하고, 수천만 원의 추가 개발비를 발생시키기도 합니다. 오늘부터 작성하는 모든 문서에서 Must, Shall, Should를 의식적으로 구분해 보세요. 명확한 언어 사용은 당신의 전문성을 높여줄 뿐만 아니라, 팀 전체의 생산성을 극대화하는 가장 강력한 도구가 될 것입니다.

기술은 결국 사람이 만드는 것이며, 사람 사이의 소통은 단어에서 시작됩니다. 정확한 단어 선택이 곧 정확한 시스템 구현으로 이어진다는 점을 잊지 마시기 바랍니다. 작은 차이가 모여 견고한 제품을 만듭니다. 지금 바로 당신의 문서 속 조동사들을 검토해 보십시오. 그것이 프로젝트 성공을 향한 첫걸음이 될 것입니다.