스펙 변경 공지가 늘 뒷북이 되는 건, 영향 범위를 문장으로 못 좁혀서예요
정산 로직에 필드 하나가 바뀌었습니다. 원래 세 자리였던 코드가 네 자리로 늘어난, 그 정도 변경이었어요. PM인 당신은 스레드에 짧게 공지를 올립니다. "We changed the settlement code format." 그리고 다음 주, 데이터팀이 배치 파이프라인이 깨진 채로 회의에 들어옵니다. "왜 미리 말 안 했어요?" 분명히 공지는 했는데요.
문제는 공지를 안 한 게 아니라, 공지에서 '누가 영향을 받는지'가 빠졌다는 거예요. 스펙 변경은 사실 자체보다 영향 범위가 핵심입니다. 무엇이 바뀌었는지보다, 그 변경이 어디까지 번지는지를 문장 안에서 좁혀줘야 상대가 자기 일로 받아들여요. 영어로 쓸 때 이 부분이 특히 잘 미끄러집니다. 한국어에선 "관련 팀은 참고 바랍니다" 한 줄로 뭉갤 수 있지만, 영어에선 그 뭉갬이 그대로 정보 누락이 되거든요.
오늘은 요구사항 명세와 변경 공지에서 영향 범위를 문장으로 좁히는 다섯 가지 각도를 다룹니다. 문법 얘기가 나오지만, 결국은 "이 문장을 읽은 사람이 자기가 뭘 해야 하는지 아느냐"의 문제예요.
무엇이 바뀌었나가 아니라, 무엇에 영향을 주나
변경 공지의 첫 문장이 change에서 멈추면 안 됩니다. 바뀐 사실은 시작일 뿐이고, 읽는 사람이 궁금한 건 "그래서 내 쪽은?"이에요. 동사를 change에서 affect로 옮기는 것만으로 문장의 무게중심이 달라집니다.
before 문장은 "우리가 바꿨다"에서 끝나요. 정보로는 맞지만, 읽는 사람이 자기 일인지 판단하려면 스스로 추론해야 합니다. after는 which affects the daily reconciliation batch로 영향 대상을 문장 안에 넣었어요. affect는 자동사가 아니라 타동사라, effect(명사, 결과)와 헷갈리지 말고 뒤에 목적어를 반드시 붙여야 합니다. "affects the batch"처럼요. 이 한 조각이 있으면 데이터팀은 첫 문장에서 이미 자기 일임을 압니다.
능동태로 '누가 무엇을 해야 하는지'를 드러내기
수동태는 정중해 보이지만 책임 주체를 지워요. 변경 공지에서 수동태를 남발하면 "누가 뭘 하라는 거지?"가 흐려집니다. 특히 액션이 필요한 대상에게는 주어를 살려야 해요.
before는 "매핑 테이블이 업데이트되어야 한다"는 상태만 말합니다. 문법은 완벽하지만, 누가 하는지가 빠졌어요. 그래서 다들 "누군가 하겠지" 하고 넘깁니다. after는 The data team을 주어로 세워서 needs to update의 주체를 못 박았어요. 여기서 need는 be동사가 아니라 일반동사라, needs to update처럼 to부정사가 따라옵니다. "is need to"가 아니라요. 공지에서 액션 아이템은 반드시 사람 주어로 쓴다고 규칙을 정해두면, 뒷북이 확 줄어듭니다.
시제로 '이미 적용됐다'와 '적용될 예정이다'를 가르기
변경 공지에서 가장 비싼 오해가 시점 오해예요. 이미 프로덕션에 나간 변경인지, 다음 릴리스에 나갈 변경인지에 따라 상대의 대응이 완전히 달라집니다. 그런데 시제를 대충 쓰면 이게 뭉개져요.
before의 현재시제 "We update"는 습관이나 일반적 사실처럼 읽혀요. "우리는 API를 업데이트합니다"는 뉘앙스라, 언제 적용됐는지가 안 보입니다. after는 We've already deployed로 현재완료를 써서 "이미 배포가 끝났고 그 결과가 지금 유효하다"를 담았어요. 현재완료는 과거의 행동이 현재에 미치는 영향을 말하는 시제라, 변경 공지에 딱 맞습니다. 반대로 다음 주에 적용될 거면 "We'll deploy this next Tuesday"처럼 미래를 분명히 쓰세요. 시제 하나가 데이터팀의 대응 타이밍을 정합니다.
관사로 '어느 것'인지 좁히기
핀테크 명세엔 비슷한 대상이 여럿이에요. 테이블도 여럿, 엔드포인트도 여럿, 필드도 여럿. 관사 a와 the를 대충 쓰면 "그래서 어느 걸 말하는 거야?"가 생깁니다. the는 "우리 둘 다 아는 그거"라는 신호예요.
before는 관사도 없고 어느 필드인지도 없어서, 받는 사람이 스키마 전체를 뒤져야 합니다. after는 the currency_code field로 딱 하나를 지목했어요. 여기서 the를 쓴 이유는 "그 스키마 안의, 우리가 지금 얘기하는 바로 그 필드"이기 때문입니다. 처음 언급하는 대상이라도 문맥상 특정될 수 있으면 the를 씁니다. 그리고 format changed로 무엇이 어떻게 바뀌었는지(alpha-2에서 alpha-3로)까지 붙였어요. 관사 하나, 값 하나가 영향 범위를 필드 단위로 좁혀줍니다.
조건절로 '이 경우에만 영향'을 못 박기
모든 변경이 전원에게 영향을 주진 않아요. 특정 조건에서만 문제가 되는 경우가 많습니다. 이걸 "관련 팀 참고"로 뭉개면, 상관없는 사람은 불안해하고 정작 영향받는 사람은 못 알아챕니다. If절로 조건을 명시하면 각자 자기 해당 여부를 스스로 판단해요.
before의 "some downstream jobs"는 아무도 안 챙기는 문장이에요. some이 누구인지 모르니, 다들 "내 얘긴 아니겠지" 하고 넘깁니다. after는 If your job reads the raw_amount column directly로 조건을 정확히 걸었어요. 이 조건에 해당하는 사람만 긴장하면 되고, 나머지는 안심합니다. 그리고 will break로 결과를, because the column is now nullable로 이유를 붙였어요. may affect의 흐릿한 가능성 대신, 조건과 결과와 이유를 다 담은 문장 하나가 훨씬 친절합니다. 영향 범위를 좁힌다는 건 결국 이 If절을 얼마나 정확히 쓰느냐예요.
정리하면, 변경 공지가 뒷북이 되는 건 정보를 안 줘서가 아니라 영향 범위가 문장에서 빠져서예요. affect로 대상을 붙이고, 능동태로 주체를 세우고, 시제로 시점을 가르고, 관사로 대상을 지목하고, If절로 조건을 걸면, 같은 변경도 훨씬 덜 부딪힙니다.
이런 문장은 한 번 배운다고 손에 붙지 않아요. 다음에 스펙 변경 공지를 쓸 때, 첫 문장을 affect로 시작해보고 그 문장이 어땠는지 남겨두는 것. 그렇게 내가 실제로 써 본 문장이 쌓여야, 급할 때 그 문장이 나옵니다. 오늘 공지 한 줄부터 그렇게 써보세요.