요구사항 명세서에서 "이건 이번 스코프 아님"을 영어로 못 그으면, 변경은 뒷북이 됩니다
정산 로직 하나 바꾸는 스펙 문서를 올렸습니다. 리뷰에선 아무도 이의가 없었어요. 그런데 개발 절반쯤 왔을 때 백엔드에서 물어봅니다. "이거 환불 케이스도 포함이에요?" 명세서엔 그 얘기가 없었죠. 없었으니까 누군가는 포함이라 읽고, 누군가는 제외라 읽었습니다. 그 순간 스펙 변경 공지를 다시 써야 하고, 그 공지는 이미 뒷북입니다.
문제는 변경이 늦게 통보돼서가 아닙니다. 애초에 명세서가 경계를 안 그어서예요. "무엇을 만드는가"만 쓰고 "무엇은 만들지 않는가"를 안 써두면, 나중에 그 빈칸이 전부 변경 요청으로 돌아옵니다. 영어로 쓸 때 이게 더 심해집니다. 한국어라면 "이건 이번엔 빼요" 한마디로 넘어갈 걸, 영어로는 그 경계 문장을 어떻게 세워야 할지 몰라서 그냥 안 쓰거든요.
오늘은 요구사항 명세와 변경 공지에서, 영향 범위를 문장 하나로 좁히는 법을 봅니다. 포함과 제외, 조건과 전제를 영어로 못 박는 다섯 개의 자리를 골랐어요. 문법은 어렵지 않습니다. 어느 동사를, 어느 시제로, 어느 자리에 놓느냐의 문제예요.
포함을 쓰는 문장보다, 제외를 쓰는 문장이 경계를 만듭니다
스펙에서 제일 자주 빠지는 게 "이건 안 한다"는 문장입니다. 포함 목록만 쭉 쓰면, 목록에 없는 건 전부 해석의 여지로 남아요. 명시적으로 out of scope를 문장으로 박아야 나중에 "이건 원래 포함 아니었어요"가 성립합니다.
does not handle을 쓰면 "환불을 처리하지 못한다"는 기능적 한계처럼 읽힙니다. 그러면 상대는 "왜 못 해요? 언제 되나요?"로 따라오죠. out of scope는 능력의 문제가 아니라 이번 범위 선긋기라는 걸 명확히 합니다. be동사로 상태를 서술하는 게 핵심이에요. handle 같은 do동사는 행위와 능력을 끌고 오지만, are out of scope는 그냥 경계선을 그은 사실을 놓습니다. 감정도 변명도 안 붙어요.
"포함될 수도 있다"는 will을 쓰면 약속이 됩니다
미확정 항목을 명세에 쓸 때가 제일 위험합니다. "다음 릴리스에 넣을게요" 같은 뉘앙스를 무심코 will로 쓰면, 그건 약속으로 저장됩니다. 나중에 그 항목이 밀리면, 당신이 한 말을 뒤집는 셈이 되죠.
will include는 미래에 대한 단정입니다. 조건도 유보도 없이 "넣는다"고 못 박은 거죠. 하지만 아직 우선순위도 안 정해진 항목이라면, 이건 지킬 수 없는 약속이 됩니다. is being considered는 현재진행 수동태로, "지금 검토 중"이라는 상태만 전합니다. 확정이 아니라는 걸 문장 구조 자체가 말해주죠. 그리고 the next release가 아니라 a future release예요. the는 특정된 릴리스를 가리키니까 "다음 번"으로 못 박히고, a는 "언젠가의"로 열어둡니다. 관사 하나가 약속의 무게를 바꿉니다.
조건이 붙는 요구사항은, 조건절을 앞에 세워 전제를 먼저 보여주세요
"A가 되면 B를 한다"는 의존 관계를 명세에 쓸 때, 결과부터 쓰면 조건이 뒤에 묻힙니다. 읽는 사람은 결과만 보고 "이거 무조건 되는구나"로 받아들이죠. 전제를 문장 머리에 세우면, 그게 조건부라는 걸 먼저 읽게 됩니다.
before는 "즉시 정산 지원"을 먼저 던지고, 조건을 뒤에 붙였습니다. 바쁘게 읽는 사람은 앞 절만 보고 "즉시 정산 된다"로 기억해요. 조건절을 앞에 세우면, 전제를 읽고 나서 결과를 읽습니다. 이해 순서가 문장 순서와 맞아떨어지죠. 그리고 returns를 responds로 바꿨어요. return은 "무엇을 반환하다"는 타동사라 목적어를 기다리게 만듭니다. respond within은 "제한 시간 안에 응답한다"는 자동사 구문으로, 응답 여부 자체에 초점이 갑니다. 여기선 무얼 반환하느냐가 아니라 시간 안에 오느냐가 조건이니까요.
변경 공지는 "무엇이 바뀌는가"보다 "누가 영향받는가"를 주어로
스펙 변경을 알릴 때, 바뀐 내용만 쓰면 각자 "이게 나랑 상관 있나"를 계산해야 합니다. 영향받는 대상을 주어로 세우면, 읽는 사람이 자기 이름을 바로 찾습니다. 영향 범위를 좁힌다는 건 결국 주어를 좁히는 일이에요.
before는 "정산 스케줄이 바뀌었다"는 사실만 놓습니다. 그러면 모든 팀이 "이거 우리 얘긴가?"를 각자 따져야 하고, 그 계산 중에 뒷북이 생겨요. after는 주어를 Merchants on the weekly payout plan으로 좁혔습니다. 주간 정산 쓰는 가맹점만 읽으면 되고, 나머지는 자기 얘기가 아니라는 걸 첫 단어에서 압니다. has changed의 현재완료는 "바뀌었다"는 완료 사실이지만, will see ... shift는 "당신이 무엇을 겪게 되는지"를 그려줍니다. 영향을 문장으로 눈에 보이게 만드는 거예요.
발효 시점은 "언제부터"를 as of로 못 박아 회색지대를 없애세요
변경 공지에서 "곧 적용됩니다" "다음 주부터요" 같은 애매한 시점은 반드시 질문을 부릅니다. "그럼 그 전에 들어온 건요?" 발효 시점을 정확한 날짜로, 그것도 정해진 전치사로 박아야 회색지대가 사라집니다.
will apply from next week은 두 군데가 흐립니다. next week은 정확히 언제인지 안 정해졌고, from은 시작점만 있고 그 전 건의 처리는 안 말합니다. takes effect on March 3은 현재시제로 확정된 사실을 못 박아요. 미래형 will 없이 현재시제를 쓰면 "이건 이미 정해진 규정"이라는 확정성이 강해집니다. 그리고 뒤에 "그 날 전에 접수된 건은 기존 규칙을 따른다"를 한 문장 붙였죠. 변경 공지가 뒷북이 되는 이유의 절반은 이 경계 처리를 안 써서예요. 발효일과 소급 여부는 항상 한 세트입니다. please prepare 같은 막연한 요청은 뺐어요. 대신 무엇이 어떻게 처리되는지 사실을 주니까, 상대가 알아서 준비할 수 있습니다.
정리하면
스펙 변경이 뒷북이 되는 건, 변경을 늦게 알려서가 아니라 처음 명세에서 경계를 안 그어서입니다. 포함만 쓰고 제외를 안 쓰고, 미확정을 약속처럼 쓰고, 영향받는 대상을 주어로 안 세우고, 발효일과 소급 여부를 한 세트로 안 묶으면, 그 빈칸들이 전부 나중에 변경 요청으로 돌아옵니다.
경계를 긋는 영어는 화려한 표현이 아니라 정확한 동사와 시제, 관사입니다. be동사로 상태를 놓고, 조건절을 앞에 세우고, out of scope로 선을 긋는 것. 오늘 쓴 명세서에서 "이건 안 한다"는 문장 한 줄이 있는지부터 보세요. 없다면, 거기가 다음 뒷북이 시작될 자리입니다.