태그: #영어
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 30 편
I'll address this in a follow-up PR: 지금 말고 다음 PR 에서 하겠다는 약속
리뷰 지적 중 일부를 이번 PR 이 아니라 다음 PR 에서 처리하겠다고 할 때 I'll address this in a follow-up PR 이라고 씁니다. follow-up 은 「후속」이라는 뜻의 명사·형용사이고, 동사로 쓸 때는 follow up 으로 띄어 씁니다. 리뷰어가 이 말을 왜 경계하는지(Google 의 리뷰 지침), 약속을 믿게 만드는 법, 한국인이 자주 하는 하이픈 실수와
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#PR 설명#코드 리뷰This is out of scope for this PR: 범위를 지키며 정중하게 선을 긋기
PR 하나에는 문제 하나만 담는 것이 좋습니다. 리뷰 중에 「이것도 같이 고치면 어때요?」라는 제안이 오면, 거절이 아니라 범위의 문제라는 점을 This is out of scope for this PR 로 전합니다. scope 의 뜻, PR 설명에 범위를 미리 밝히는 법, I'd rather keep this PR focused 같은 부드러운 대안, 한국인이 자주 쓰는 「It is not
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#PR 설명#코드 리뷰No functional change: 동작은 그대로라고 리뷰어를 안심시키는 말
이름 바꾸기, 파일 옮기기, 정리 작업처럼 동작을 바꾸지 않는 PR 에는 No functional change 라고 적습니다. LLVM 은 이것을 NFC 라는 줄임말로 커밋 첫 줄에 붙이는 관례가 있습니다. 리뷰어가 무엇을 덜 봐도 되는지 알려 주는 표현이라 큰 리팩터링 PR 에서 특히 쓸모 있습니다. NFC 의 쓰임, intended 를 붙이는 이유, behavior change 와의 구분
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#PR 설명#리팩터링Fixes #1234: PR 설명의 첫 줄, 이슈를 닫는 키워드
PR 설명에 Fixes 1234 라고 쓰면 PR 이 기본 브랜치에 병합될 때 그 이슈가 자동으로 닫힙니다. 단순한 영어 문장이 아니라 GitHub 가 읽는 키워드이므로 정해진 단어를 정해진 모양으로 써야 합니다. 닫는 키워드 아홉 가지, 기본 브랜치에서만 동작한다는 조건, 닫지 않고 연결만 할 때 쓰는 Related to 와 Part of, 한국인이 자주 쓰는 어색한 PR 첫 줄을 정리합니다
2026-10-27 · 6 분 읽기 #영어#영어 표현#오픈소스#PR 설명#GitHubLet me know if I'm missing something: 내 이해가 틀렸을 가능성을 열어 두는 한 줄
버그라고 생각하지만 혹시 의도된 동작일지도 모를 때, 문장 끝에 Let me know if I'm missing something 을 붙입니다. 「제가 놓친 것이 있으면 알려 주세요」라는 뜻으로, 주장을 하면서도 상대의 맥락을 존중합니다. miss 의 뜻, 현재진행형을 쓰는 이유, Correct me if I'm wrong 과의 차이, 한국인이 자주 쓰는 Sorry if I'm wrong 남
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#이슈#코드 리뷰Would you be open to ...?: PR 을 보내기 전에 방향을 묻는 공손한 제안
큰 변경을 PR 로 바로 보내기 전에 메인테이너의 의향을 묻는 표현이 Would you be open to ...? 입니다. 「~을 받아들일 생각이 있으신가요?」라는 뜻이라 결정권이 상대에게 있음을 인정하면서 제안을 꺼냅니다. 뒤에 동명사(-ing)나 명사가 온다는 문법, Can I ...? 와 Should I ...? 와의 차이, 한국인이 자주 쓰는 과잉 공손 표현을 정리합니다.
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#이슈#제안As far as I can tell: 확신과 겸손 사이, 「제가 본 바로는」
원인을 찾았지만 100% 확신할 수는 없을 때 As far as I can tell 을 문장 앞에 붙입니다. 「내가 확인한 범위에서는 그렇다, 다만 내가 모르는 것이 있을 수 있다」는 뜻이라 주장의 근거와 한계를 함께 전합니다. AFAICT 라는 줄임말, I think 와의 차이, 한국인이 자주 쓰는 In my opinion 남용을 고치는 법을 정리합니다.
2026-10-27 · 5 분 읽기 #영어#영어 표현#오픈소스#이슈#코드 리뷰I can't reproduce this on ...: 재현이 안 될 때 상대를 탓하지 않고 말하기
다른 사람이 올린 버그를 내 환경에서 재현하지 못했을 때 쓰는 표현이 I can't reproduce this on ... 입니다. 「당신이 틀렸다」가 아니라 「내 환경에서는 다르게 나온다」는 사실만 전하고, 어떤 환경에서 시험했는지를 on 뒤에 붙이는 것이 핵심입니다. repro 라는 줄임말, could not 과 can't 의 차이, 재현 정보를 정중하게 요청하는 법을 정리합니다.
2026-10-27 · 6 분 읽기 #영어#영어 표현#오픈소스#이슈#버그 보고What did you expect to happen: 버그 보고의 기본, 기대한 동작과 실제 동작
버그 이슈의 핵심은 「무엇을 기대했고 실제로는 무엇이 일어났는가」입니다. Kubernetes 의 버그 보고 양식도 What happened? 와 What did you expect to happen? 을 맨 앞에 둡니다. Expected behavior 와 Actual behavior 를 나눠 쓰는 법, 시제와 관사를 맞추는 법, 한국인이 자주 쓰는 「It doesn't work」 한 줄 보
2026-10-27 · 7 분 읽기 #영어#영어 표현#오픈소스#이슈#버그 보고Happy to take a stab at this: 이슈를 맡겠다고 나설 때
오픈소스 이슈에 「제가 해 보겠습니다」라고 나설 때 가장 자연스러운 한 줄이 Happy to take a stab at this 입니다. take a stab at 은 「한번 시도해 보다」라는 비격식 관용구라서, 자신감을 과장하지 않으면서도 의지를 분명히 보여 줍니다. 뜻과 공손함의 정도, 이슈 댓글과 Slack 예문, I'd like to work on this 와의 차이, 한국인이 자주
2026-10-27 · 6 분 읽기 #영어#영어 표현#오픈소스#이슈#오픈소스 기여