스탠드업·PR·이슈에서 영어가 자꾸 애매해지는 이유
스탠드업에서 어제 한 일을 말하려는데, "I fixed the bug"라고 쓰고 잠깐 멈칫한 적 있으신가요. 고친 건 맞는데, 이게 이미 배포까지 된 건지, 로컬에서만 된 건지, 리뷰 대기 중인지가 이 한 문장에는 안 담깁니다. 한국어로는 "그거 고쳤어요"면 맥락으로 다 통하는데, 영어로 옮기면 그 뉘앙스가 통째로 새어나가죠.
PR 설명이나 이슈 코멘트도 비슷합니다. 우리가 쓰는 문장은 대부분 상태를 보고하거나, 뭔가를 요청하거나, 이유를 설명하는 겁니다. 그런데 이 세 가지가 영어에서는 시제·태·동사 선택으로 꽤 정교하게 갈립니다. 문법책에서 배운 규칙은 다 맞는데, 실무 문맥에 놓으면 자꾸 미끄러지는 지점이 있어요.
오늘은 개발자·PM·연구직이 하루에도 몇 번씩 쓰는 문장들을 골라, 왜 어색해지는지 문장 단위로 뜯어보려 합니다. 규칙을 외우자는 얘기가 아니라, "왜 이렇게 쓰는지"를 알면 다음에 비슷한 상황에서 스스로 고를 수 있으니까요.
스탠드업: 완료 시제가 상태를 말해준다
스탠드업에서 가장 흔한 실수는 모든 걸 단순 과거로 말하는 겁니다. "어제 뭐 했어요"라는 질문에 반응하다 보니 자연스럽게 과거형이 나오는데, 사실 팀이 궁금한 건 "그래서 지금 어떤 상태냐"인 경우가 많아요.
단순 과거 fixed는 "어제 그 시점에 고치는 행동을 했다"는 사실만 전합니다. 반면 현재완료 have fixed는 "고쳤고, 그 결과가 지금까지 유효하다"는 상태를 함께 전해요. 스탠드업은 대부분 진행 상황 공유가 목적이라, "지금 리뷰 가능하다"까지 이어지는 완료 시제가 훨씬 정확합니다. 어제라는 시점을 콕 집어 말하고 싶을 때만 과거를 쓰세요. 두 시제를 같은 문장에 섞어서 yesterday I've fixed처럼 쓰면 안 되는 이유도 여기 있습니다. 현재완료는 특정 과거 시점(yesterday)과 함께 쓰지 않거든요.
PR 제목: 명령형이 왜 표준인지
PR이나 커밋 메시지 제목을 쓸 때, "이 PR은 로그인 버그를 고칩니다"를 그대로 옮기려다 어색해지는 분이 많습니다. 관사와 주어를 붙이다 보면 문장이 무거워져요.
커밋·PR 제목은 관례적으로 명령형(동사 원형)으로 시작합니다. "이 커밋을 적용하면 무슨 일이 일어나는가"를 서술하는 방식이라 Fix, Add, Remove처럼 동사 원형으로 열어요. 여기에는 주어(This PR)도, 불필요한 관사도 잘 넣지 않습니다. 짧고 스캔하기 좋아야 하니까요. 그리고 bug of login은 어색합니다. of는 소유·소속을 나타내는데, 로그인이 버그를 소유한 게 아니라 로그인 '영역에서 발생한' 버그거든요. 이럴 땐 명사를 형용사처럼 앞에 붙여 login bug라고 씁니다. 이렇게 명사를 겹쳐 쓰는 방식이 영어 기술 문서에서는 훨씬 자연스럽습니다.
이슈 리포트: 재현 조건은 조건절로
버그 리포트를 쓸 때 "이렇게 하면 이런 일이 일어난다"를 옮기다가, when과 if를 아무렇게나 섞어 쓰는 경우가 있습니다. 둘은 뉘앙스가 다릅니다.
if는 "그럴 수도, 아닐 수도 있는" 조건입니다. when은 "그 상황이 되면 반드시"에 가깝고요. 버그가 매번 재현된다면(every time) 불확실한 if가 아니라 when이 맞습니다. 재현이 간헐적일 때만 if를 쓰세요. 그리고 is crash는 흔한 실수예요. crash는 그 자체로 "충돌하다"라는 동사입니다. be동사 is를 앞에 붙이면 "~인 상태다"라는 뜻이 되어버려서, 동사 crash와 충돌합니다. 상태를 말하려는 게 아니라 동작을 말하는 거라면 be동사 없이 crashes 하나면 충분합니다. 이 be vs do 구분이 헷갈리면, "~이다/~인 상태다"인지 "~하다"인지를 먼저 생각해보세요.
리뷰 코멘트: 요청을 부드럽게 만드는 법
코드 리뷰에서 수정을 제안할 때, 직역하면 명령처럼 딱딱해지기 쉽습니다. 특히 동료에게 남기는 코멘트라면 톤이 관계에 영향을 주죠.
Change로 시작하는 명령문은 "바꿔라"라는 지시로 읽힙니다. 코드 리뷰는 협업이지 지시가 아니니, Could we로 시작하면 "함께 이렇게 해볼까요"라는 제안의 뉘앙스가 생겨요. we를 쓰는 것도 포인트인데, "너의 문제"가 아니라 "우리가 함께 다듬을 부분"으로 프레임을 바꿔줍니다. 그리고 It is confusing은 단정적으로 들립니다. a bit(약간)이나 hard to follow(따라가기 어렵다) 같은 완충 표현을 넣으면, 상대를 탓하지 않으면서도 문제는 정확히 짚을 수 있어요. 격식 뉘앙스는 이런 작은 단어 선택에서 갈립니다.
문서: 연구 결과는 능동태로 또렷하게
연구직이나 PM이 실험 결과, 데이터 분석을 문서로 쓸 때, 습관적으로 수동태를 남발하는 경우가 많습니다. 학술적으로 보이려는 의도인데, 오히려 문장이 흐려집니다.
It was found that은 "무언가가 발견되었다"인데, 누가 발견했고 무엇이 무엇을 줄였는지가 안개처럼 흐려집니다. 능동태 The new cache reduced latency는 주어(캐시)와 동사(줄였다)와 목적어(지연)가 한눈에 들어와요. 정보 밀도가 훨씬 높습니다. 실무 문서는 논문 초록이 아니라 빠르게 읽혀야 하는 글이라, 능동태가 대부분 더 낫습니다. 여기에 by 30%처럼 구체적 수치를 붙이면 "reduced가 정확히 얼마나"까지 담겨서, 읽는 사람이 되물을 필요가 없어져요.
이런 문장들은 하나하나 보면 사소해 보이지만, 하루에 수십 번 쓰다 보면 그 사소함이 쌓여서 "영어로 일하는 게 피곤하다"는 감각을 만듭니다. 반대로 왜 그렇게 쓰는지를 한 번 이해해두면, 다음부터는 같은 유형에서 스스로 고를 수 있어요.
한 가지 팁이라면, 오늘 쓴 스탠드업 문장이나 PR 설명을 그냥 흘려보내지 말고 한 번 다시 써보는 겁니다. 내가 실제로 쓰는 문장이 가장 좋은 교재니까요. 검색해서 찾은 표현은 금방 잊히지만, 내가 직접 고쳐 쓴 문장은 다음 스탠드업에서 다시 떠오릅니다.