실사가 늦어진다고 알리는 메일, "sorry for the delay"로 시작하면 왜 약해질까요
목요일 저녁, QoE(실사 재무검토)가 또 밀렸습니다. 매도인 쪽 자료 제출이 늦어서인데, 어쨌든 클라이언트한테는 알려야 합니다. 메일 창을 열고 커서를 깜빡거립니다. 늘 쓰던 그 문장이 또 손끝에 올라옵니다. "Sorry for the delay, we are working on it."
문제는 이게 사실 틀린 문장이 아니라는 겁니다. 문법도 맞고 정중하기도 합니다. 그런데 보내고 나면 뭔가 찜찜합니다. 내가 일을 놓친 것도 아닌데 왜 내가 사과부터 하고 있지. 그리고 상대는 "그래서 언제 되는데?"라고 다시 물어옵니다. 알려줬는데 또 물어본다는 건, 메일이 할 일을 안 했다는 뜻입니다.
딜 실사 지연 통보는 사과 메일이 아닙니다. 상황 보고입니다. 지연이 '났다'는 사실, 왜 났는지, 그래서 일정이 어떻게 바뀌는지. 이 세 가지를 순서대로 쥐고 있으면, 사과 한마디 없이도 훨씬 신뢰가 갑니다. 오늘은 그 세 덩어리를 영어로 어떻게 쥐는지 봅니다.
"sorry"로 열면, 통제권을 먼저 내려놓는 겁니다
지연을 알릴 때 가장 흔한 실수가 사과를 맨 앞에 두는 겁니다. 사과가 나쁜 건 아닙니다. 다만 맨 앞에 오면, 읽는 사람은 "이 사람이 뭔가 잘못했구나"로 프레임을 잡습니다. 특히 지연 원인이 내 쪽이 아닐 때는 손해입니다.
먼저 사실을 담담하게 알리고, 사과가 필요하면 짧게 뒤에 붙이세요. 순서만 바꿔도 "보고하는 사람"이 됩니다.
여기서 be동사(is expected)를 쓴 게 핵심입니다. "We are working on it"은 '우리가 작업 중'이라는 행위(do) 중심이라, 읽는 사람 입장에선 진행 상태를 알 수 없습니다. 반면 "is expected to wrap up by..."는 상태와 시점을 함께 못 박습니다. 영어에서 상태를 선언할 때는 do동사로 과정을 늘어놓는 것보다, be동사로 '언제 어떤 상태가 된다'를 고정하는 게 훨씬 또렷하게 읽힙니다.
원인은 "because"로 붙이면 변명이 됩니다
지연 사유를 쓸 때 because를 바로 붙이면 이상하게 방어적으로 들립니다. "~때문에 늦었어요"는 한국어로도 구차한데, 영어도 마찬가지입니다. 사유는 원인 자체를 주어로 세우는 게 깔끔합니다.
"We are late because..."는 '우리가 늦은 주체'로 못 박고 시작합니다. 반면 "The delay stems from..."은 지연이라는 사실을 주어로 놓고, 그 출처를 가리킵니다. 책임을 떠넘기는 게 아니라, 인과를 객관적으로 서술하는 거죠. stem from은 '~에서 비롯되다'라는 뜻인데, 이렇게 중립적인 자동사를 쓰면 감정이 빠집니다. 참고로 blame(탓하다) 같은 타동사를 쓰면 즉시 책임 공방처럼 읽히니, 이런 메일에선 피하는 게 좋습니다.
"ASAP"는 일정이 아닙니다
지연을 알리면서 새 일정을 안 주면, 알린 의미가 없습니다. 그런데 많은 분들이 "as soon as possible" "shortly" "very soon" 같은 말로 때웁니다. 받는 사람 입장에선 아무 정보도 아닙니다. 오히려 "이 사람 일정 모르는구나"로 읽힙니다.
날짜를 못 박기 어렵다면, '범위'와 '다음 업데이트 시점'을 주세요. 이게 프로의 방식입니다.
by와 until을 헷갈리지 마세요. by Thursday는 '목요일까지는 완료'라는 마감 시점이고, until Thursday는 '목요일까지 계속'이라는 지속의 의미입니다. 보고서를 목요일에 넘기겠다는 뜻이면 반드시 by입니다. until을 쓰면 "목요일까지 뭔가를 하고 있겠다"는, 전혀 다른 말이 됩니다. 그리고 circulate(돌리다, 공유하다)는 send보다 격식 있고, 여러 관계자에게 배포하는 뉘앙스라 딜 실무 메일에 잘 맞습니다.
지연이 딜 전체에 미치는 영향은, 미리 좁혀서 말하세요
클라이언트가 가장 불안해하는 건 '이 지연이 딜 전체를 뒤흔드는가'입니다. 실사 하나 밀렸다고 사이닝까지 밀리는지, 아닌지. 이걸 안 짚으면 상대는 최악을 상상합니다. 영향 범위를 먼저 좁혀주면 불안이 줄고, 메일 한 통으로 끝납니다.
여기서 might affect와 affects의 차이가 큽니다. might affect는 '영향을 줄지도 모른다'는 추측이라, 읽는 사람은 "줄 수도 있다는 거네"로 최악을 가정합니다. affects(현재형 단정)는 '이 부분에만 영향을 준다'고 못 박아서, 나머지는 괜찮다는 안심을 줍니다. 모호할 때 추측형을 쓰면 친절해 보일 것 같지만, 실무 보고에선 오히려 불안을 증폭시킵니다. 아는 범위는 단정하고, 모르는 범위만 유보하세요. remains unchanged(변동 없음)도 '아직 그대로다'를 분명히 선언하는 표현이라 안심 효과가 큽니다.
매번 다른 지연, 매번 같은 메일을 피하는 법
실사 지연은 딜마다 원인이 다릅니다. 매도인 자료 지연, 외부 감사인 일정, 규제 승인 대기, 데이터룸 접근 문제. 그런데 쓰는 문장은 매번 똑같습니다. "sorry for the delay, working on it, will update soon." 원인이 다른데 문장이 같으니, 받는 사람은 상황을 구분할 수 없습니다.
내가 썼던 지연 통보 문장이 전부 남아 있다면, 다음 딜에서 상황만 갈아끼우면 됩니다. 원인별로 문장 틀이 쌓이니까요.
resume은 '중단됐던 걸 다시 시작하다'는 뜻이라, 데이터룸 접근 문제로 멈췄다가 풀린 상황에 정확히 맞습니다. 그냥 start를 쓰면 처음 시작하는 것처럼 읽혀서 어색합니다. 그리고 was restored처럼 수동태를 쓴 건, 복구된 '상태'에 초점을 두기 위해서입니다. 누가 복구했는지는 중요하지 않고, 접근이 가능해졌다는 사실이 핵심이니까요.
영작만에서는 이렇게 매번 쓴 문장이 저장되고, 며칠 뒤 복습으로 돌아옵니다. 검색해서 그때만 쓰고 잊히는 표현이 아니라, 내 딜 상황에서 내가 직접 쓴 문장이 쌓이는 거죠. 다음 지연 통보는 처음부터 다시 고민하지 않아도 됩니다.
지연을 알리는 메일은 사실 사과의 기술이 아니라 순서의 기술입니다. 지연 사실, 중립적인 원인, 못 박은 새 일정, 좁힌 영향 범위. 이 네 덩어리만 순서대로 쥐면, "sorry for the delay" 없이도 프로답게 읽힙니다. 다음에 QoE가 또 밀리면, 커서 깜빡이는 시간이 조금은 줄어들 겁니다.