PR 리뷰와 이슈 코멘트, 영어로 쓸 때 자꾸 어긋나는 순간들

스탠드업에서 어제 한 일을 한 줄로 적어야 할 때, 이상하게 손이 멈추는 순간이 있어요. 한국어로는 "그거 고쳤고 리뷰 요청했어요" 한 마디면 되는데, 영어로 옮기려니까 "고쳤다"가 fix인지 fixed인지, 리뷰를 request한 건지 ask한 건지 갑자기 애매해지죠.

PR 설명란도 비슷해요. 코드는 자신 있게 짰는데, 그 코드가 뭘 하는지 영어로 한 문장 쓰는 데서 막힙니다. 리뷰어가 남긴 코멘트에 답장할 때도 마찬가지고요. "이거 왜 이렇게 했냐"는 질문에 방어적으로 들리지 않게 답하는 게, 사실 코드 짜는 것보다 어려운 날도 있어요.

그런데 이런 문장들은 대부분 짧고, 패턴이 정해져 있습니다. 매일 반복되는 상황이라는 뜻이에요. 그래서 오늘은 개발자·PM·연구직이 스탠드업, PR, 이슈, 문서에서 실제로 쓰는 문장을 골라, 왜 그렇게 써야 하는지 하나씩 짚어볼게요.

스탠드업의 "어제 뭐 했어요"는 과거인데, 왜 자꾸 헷갈릴까

스탠드업에서 어제 한 일을 말할 때는 과거의 완료된 동작이에요. 그래서 과거형이 기본입니다. 그런데 한국어로 "리뷰 요청 중이에요" 같은 진행 상태를 섞어 말하다 보면, 시제가 뒤죽박죽되곤 해요.

특히 "아직 안 끝났다"는 뉘앙스를 살리려다 실수가 나옵니다. 완료 안 된 일은 현재완료진행이나 진행형으로, 끝난 일은 과거형으로. 이 구분만 잡아도 스탠드업 한 줄이 깔끔해져요.

fix를 과거형 fixed로 바꾼 이유는 "어제"라는 명확한 과거 시점이 있기 때문이에요. 리뷰 요청도 어제 끝냈다면 requested가 맞습니다. am requesting은 "지금 이 순간 요청하는 중"이라는 뜻이라 스탠드업 맥락과 안 맞아요. 그리고 review 앞에 관사 a가 붙는데, 여기서는 "한 건의 리뷰"라는 셀 수 있는 대상이라 관사가 필요합니다.

PR 설명은 "이 코드가 무엇을 한다"는 사실이라 현재형

PR 제목이나 설명을 쓸 때 많은 분이 과거형으로 시작해요. 내가 방금 코드를 짰으니까요. 하지만 PR 설명은 "이 변경이 무엇을 하는가"를 설명하는 자리라, 코드가 지금도 그 일을 한다는 관점에서 현재형을 씁니다.

영어권 오픈소스 커밋 메시지를 보면 대부분 동사 원형이나 현재형으로 시작해요. Add, Fix, Update처럼요. "내가 추가했다"가 아니라 "이 변경이 무언가를 추가한다"는 시선이에요.

fixed를 fixes로 바꾼 건, 이 PR이 병합되면 앞으로도 계속 그 버그를 고친 상태를 유지하기 때문이에요. 시점이 과거에 갇힌 게 아니라 지금 유효한 사실이라는 거죠. 참고로 parser 앞의 the는 "우리 프로젝트의 그 파서" 즉 서로 아는 특정 대상이라 정관사를 씁니다. 처음 언급하는 일반적인 파서라면 a parser가 됐을 거예요.

리뷰 코멘트에 답할 때, 명령조를 피하는 법

리뷰어가 "여기 왜 이렇게 했어요?"라고 물으면, 답장이 은근히 어렵습니다. 한국어 그대로 옮기면 "You should do it like this"처럼 명령조가 되기 쉬운데, 리뷰는 협업이라 이런 표현이 딱딱하게 들려요.

부탁이나 제안을 할 때는 could, might, would 같은 조동사를 쓰면 훨씬 부드러워집니다. 격식 있는 문서라면 이 뉘앙스 차이가 협업 분위기를 바꿔요.

must를 could로 바꾼 이유는, must가 "반드시 해야 한다"는 강한 의무를 뜻해서 리뷰 코멘트에서는 명령처럼 들리기 때문이에요. could we는 "우리 이렇게 하면 어떨까"라는 제안이 됩니다. is confusing을 might be confusing으로 바꾼 것도 같은 맥락이에요. is는 "확실히 헷갈린다"는 단정이고, might be는 "좀 헷갈릴 수도 있다"는 여지를 남기는 표현이라 상대를 덜 몰아세워요.

이슈를 쓸 때 "재현된다"는 자동사인가 타동사인가

버그 이슈를 쓸 때 "이 버그가 재현됩니다" "에러가 발생합니다" 같은 문장을 자주 씁니다. 여기서 자동사와 타동사를 헷갈리면 문장이 어색해져요. 자동사는 목적어 없이 혼자 쓰고, 타동사는 뒤에 목적어가 와야 합니다.

happen은 자동사예요. "무언가가 저절로 일어난다"는 뜻이라 목적어를 안 붙여요. 반면 cause는 타동사라 뒤에 원인이 만든 결과가 와야 하고요. 이 둘을 섞으면 문장이 무너집니다.

is happened가 틀린 이유는, happen이 "일어나다"라는 자동사라서 수동태(is + 과거분사)로 만들 수 없기 때문이에요. 에러가 "일어나짐을 당하는" 게 아니라 그냥 "일어나는" 거죠. 그래서 능동으로 occurs나 happens를 써야 합니다. 이슈 문서처럼 살짝 격식 있는 글에서는 occurs가 더 깔끔하게 들려요.

문서에 "이 함수는 값을 반환한다"고 쓸 때의 관사

API 문서나 함수 설명을 영어로 쓸 때, 관사 하나 때문에 의미가 미묘하게 달라져요. "값을 반환한다"에서 "값"이 특정한 하나인지, 어떤 종류의 값 하나인지에 따라 the와 a가 갈립니다.

처음 언급하는 대상이고 여러 개 중 하나라면 a를, 앞에서 이미 말했거나 서로 아는 특정 대상이면 the를 씁니다. 문서는 여러 사람이 읽으니까 이 구분이 오해를 줄여줘요.

boolean value 앞에 a를 붙인 이유는, "하나의 불리언 값"이라는 셀 수 있는 단수 명사라 관사 없이는 문장이 완성되지 않기 때문이에요. 반면 user 앞에는 the를 썼는데, 여기서 유저는 "이 함수를 호출하는 그 유저" 즉 문맥상 특정된 대상이라 정관사가 어울립니다. 관사를 통째로 빼면 문법이 틀린 것처럼 보여서 문서 신뢰도가 떨어져요.

이렇게 보면, PR과 이슈에서 쓰는 영어는 결국 시제, 자·타동사, 관사, 격식 뉘앙스 몇 가지가 반복되는 거예요. 매일 마주치는 상황이니까, 한 번 제대로 이해해두면 다음부터는 손이 먼저 움직입니다.

읽고 이해하는 것과 직접 써서 내 문장으로 만드는 건 다른 일이에요. 오늘 스탠드업 한 줄, PR 설명 한 문장부터 직접 써보고, 왜 그렇게 썼는지 한 번 더 짚어보면 충분해요. 그렇게 쓴 문장이 하나씩 쌓이면, 어느 순간 고민하는 시간이 눈에 띄게 줄어 있을 거예요.