PR 설명에 "이거 고쳤어요" 한 줄, 리뷰어가 못 알아듣는 이유
PR을 올렸습니다. Description 칸에 커서가 깜빡입니다. 코드는 다 짰는데 여기서 3분이 지나갑니다. "Fixed the bug." 이렇게 써도 되나. 뭔가 부족한 것 같은데 뭐가 부족한지 모르겠고, 결국 그냥 올립니다.
며칠 뒤 리뷰어가 코멘트를 답니다. "What was the root cause?" 아, 그건 설명했어야 했는데. 다시 답글을 답니다. 이번엔 문장이 더 꼬입니다. 분명 한국어로는 30초면 설명할 내용인데, 영어로 옮기니 자꾸 "무엇을 고쳤다"까지만 나오고 "왜"가 빠집니다.
개발자·PM·연구직이 영어에서 겪는 어려움은 단어가 부족해서가 아닙니다. 오히려 기술 용어는 다들 압니다. 문제는 그 사이를 잇는 동사와 시제, 그리고 "무엇을 했다"와 "왜 그렇게 했다"를 구분해 전달하는 감각입니다. 오늘은 스탠드업·PR·이슈에서 실제로 새는 지점들을 문장 단위로 뜯어보겠습니다.
"고쳤어요"가 리뷰어에게 안 닿는 이유
PR 설명에서 가장 흔한 문장이 "Fixed the bug"입니다. 틀린 문장은 아니에요. 근데 리뷰어 입장에서는 정보가 하나도 없습니다. 무슨 버그였는지, 왜 생겼는지, 어떻게 고쳤는지가 다 빠져 있거든요.
여기서 핵심은 동사 선택이에요. "fix"만 쓰면 결과만 남습니다. 원인을 말할 때 영어는 "happened because", "was caused by" 같은 구조로 인과를 명시하는 걸 좋아해요. 한국어는 "토큰 만료 때문에 크래시가 났다"에서 '때문에'가 자연스럽게 원인을 물지만, 영어에서 이걸 생략하면 리뷰어가 다시 물어봅니다. "Now it works"도 피하는 게 좋아요. 근거 없는 자신감처럼 읽히거든요. 대신 무엇을 어떻게 처리했는지를 남기면 리뷰어가 코드를 안 봐도 맥락을 잡습니다.
스탠드업에서 "어제 그거 했어요"의 함정
데일리 스탠드업에서 어제 한 일을 말할 때, 한국어 감각으로 옮기면 시제가 자주 어긋납니다. "I do the API work yesterday" 같은 문장이 나오는 거죠. do를 쓸지 be를 쓸지, 완료인지 진행인지가 흐려집니다.
여기서 do가 문제예요. "do the work"는 뭘 했는지 하나도 안 알려주는 만능 동사거든요. 개발 맥락에선 finished(끝냈다), started(시작했다), refactored(리팩터링했다)처럼 구체적인 동사가 훨씬 잘 읽힙니다. 그리고 "Today I will do"보다 "Today I'm doing"이 더 자연스러워요. 스탠드업에서 '오늘 할 일'은 이미 진행 중이거나 곧 착수하는 계획이라, 영어는 현재진행형(I'm writing)으로 지금의 흐름을 표현하는 게 관례입니다. will은 좀 더 먼 미래, 아직 결정 안 된 일에 가깝습니다.
이슈에 재현 절차 쓸 때, 명령이 아니라 사실로
버그 이슈를 쓸 때 재현 절차(steps to reproduce)를 적잖아요. 여기서 한국어 "~하면 ~된다"를 그대로 옮기면 조건절이 어색해지거나, 반대로 사용자에게 지시하는 것처럼 읽힙니다.
"is crash"는 문법이 아예 안 맞아요. crash는 be동사와 붙지 않습니다. be동사는 상태를 나타내는 형용사나 명사랑 짝을 이루는데, crash는 동사거든요. "the page crashes"(페이지가 죽는다, 자동사) 또는 "clicking crashes the page"(클릭이 페이지를 죽인다, 타동사)로 써야 합니다. 그리고 이슈는 재현 조건을 정확히 담는 게 생명이라, "on the second attempt"(두 번째 시도에서)처럼 언제 발생하는지를 붙여주면 리뷰어가 바로 재현할 수 있어요. 조건을 "When you click"으로 풀면 문장이 길어지니, 동명사(Clicking)로 주어를 만들면 훨씬 간결합니다.
문서에 "~할 예정" 쓸 때 격식이 무너지는 지점
설계 문서나 RFC를 쓸 때 "이 기능은 다음 스프린트에 추가될 예정"처럼 계획을 적잖아요. 이걸 will로만 도배하면 문서가 가볍게 읽히고, 반대로 딱딱하게만 쓰면 읽기 힘들어집니다.
"It will make faster"는 목적어가 빠졌어요. make는 타동사라 "무엇을" 빠르게 만드는지 대상이 있어야 합니다. "make it faster" 또는 여기선 아예 "reduce the response time"(응답 시간을 줄인다)처럼 구체적으로 쓰는 게 문서 톤에 맞아요. 그리고 문서에서 will을 남발하면 "무조건 그렇게 된다"는 단정처럼 읽혀서, 나중에 안 지켜졌을 때 곤란해집니다. plan to(계획한다), should reduce(줄여줄 것으로 본다)처럼 확신의 정도를 조절하는 표현을 쓰면 훨씬 프로페셔널하게 읽혀요. 관사도 놓치기 쉬운데, 처음 언급하는 개념은 "a caching layer"로 부정관사를 붙입니다.
코멘트로 되물을 때, 무례하지 않게 확인하기
리뷰어의 코멘트에 답하거나, 반대로 남의 PR에서 뭔가를 확인할 때 톤 조절이 어렵습니다. 직역하면 자꾸 따지는 것처럼 들려요. "Why did you do this?" 같은 문장은 한국어 "왜 이렇게 하셨어요?"보다 훨씬 공격적으로 읽힙니다.
"It is not good"은 사실 진술처럼 보이지만 상대에겐 평가로 꽂힙니다. 영어 리뷰 문화에서는 단정보다 질문 형태가 훨씬 잘 받아들여져요. "Was there a reason to..."(~할 이유가 있었나요)는 상대의 판단을 존중하면서 근거를 묻는 구조입니다. "I'm curious"(궁금해서요)로 시작하면 추궁이 아니라 호기심으로 톤이 잡히고요. 이건 문법의 문제라기보다 격식과 뉘앙스의 문제인데, 왜 그렇게 쓰는지 알고 나면 다음부터는 스스로 조절할 수 있게 됩니다.
여기까지 보면 알겠지만, 개발자·PM·연구직의 영어는 결국 "무엇을"과 "왜"를 나눠 전하고, 동사와 시제로 상태·완료·계획을 구분하고, 확신의 정도를 톤으로 조절하는 일입니다. 이건 표현을 몇 개 외운다고 해결되지 않아요. 내가 실제로 쓴 PR 설명, 스탠드업 메모, 이슈 문장을 직접 영작해보고, 왜 그 문장이 어색했는지 설명을 들으면서 몸에 익는 겁니다.
읽어서 아는 것과 써서 아는 것은 다릅니다. 오늘 올릴 PR 설명 한 문장부터, 직접 써보고 왜인지 확인해보면 어떨까요.