글로벌 팀에서 속으로 한숨 쉬게 만드는 한국 영어 8가지

1. "This looks weird"

QA 중에 화면 하나가 뭔가 이상하다. 시간이 없으니까 Jira에 빠르게 코멘트를 단다. "This looks weird, can you fix it?" 코멘트를 받은 사람이 그 티켓을 열고 멈춘다. 'weird'가 뭔데? 색상? 크기? 위치? 전체 레이아웃? 본인이 만든 화면 전체를 다시 뜯어봐야 한다. 그 시간은 누가 책임지는 건지.

"The header height is showing as 60px, but the Figma spec shows 80px — could you take a look?"

핵심은 관찰 + 기준 + 요청, 이 세 개다. 내가 뭘 봤는지, 어디 기준인지, 뭘 해달라는 건지. 이 구조만 지켜도 소통 퀄리티가 완전히 달라진다.

2. "I don't like this button color"

디자이너가 CTA 버튼 색상을 올렸다. 회의에서 누군가 자연스럽게 말한다. "Hmm, I don't like this button color." 디자이너와 개발자가 눈을 마주친다. 색상 결정은 브랜드 가이드 기반으로 내린 의사결정이다. "I don't like it"은 그 결정을 개인 취향으로 뒤집겠다는 말이다. 아무도 할 말이 없어진다.

"I noticed the CTA button is using #FF5733, but our brand guide specifies #FF6B35. Could we align this?"

좋아하고 싫어하고의 문제가 아니라, 맞고 틀리고의 문제로 프레임을 바꿔야 한다. 그래야 근거 있는 피드백이 된다.

3. "Can you make this prettier?"

스프린트 데모가 끝났다. 화면이 뭔가 촌스러운 느낌이다. 누군가 피드백을 준다. "Can you make this a bit prettier?" 피드백을 받은 사람이 고개를 끄덕인다. 그리고 자리로 돌아가서 아무것도 안 한다. 뭘 어떻게 해야 할지 모르기 때문이다. 이건 말한 사람 본인도 뭘 원하는지 모른다는 신호다.

"The spacing between elements seems inconsistent — could we apply the 8px grid from our design tokens?"

레이아웃, 정렬, 여백 — 이것들은 다 수치로 말할 수 있다. '예쁘다'를 '8px 그리드가 맞지 않는다'로 번역하는 것. 그게 기준 있는 피드백이다.

4. "This should be easy, right?"

회의에서 새로운 기능 아이디어가 나왔다. 누군가 확신에 찬 표정으로 말한다. "This should be easy, right? Maybe just a day or two?" 개발자의 표정이 굳는다. 이 말이 위험한 이유는 공수 판단을 본인이 하는 것처럼 들리기 때문이다. "아니요, 사실 꽤 복잡해요"라고 말하면 이미 갈등이 시작된 거다. 반대로 억지로 맞춰주면 야근이 시작된다.

"Before we commit to this, could you give me a rough estimate on the level of effort?"

'rough estimate'이라는 표현을 쓰면 정확한 숫자가 아니어도 된다는 여지를 준다. 상대방이 부담 없이 솔직하게 말할 수 있게 되는 거다.

5. "I told you this before"

저번 주 회의에서 분명히 말했다. 그런데 상대방이 다르게 이해했다. 답답해서 말한다. "I told you this before — we discussed it in the meeting." 상대방도 억울하다. 본인은 그렇게 들은 기억이 없다. 이 상황이 생기는 건 대부분 문서로 안 남겼기 때문이다. 글로벌 팀은 타임존이 다르다. 회의 내용을 기억에 의존하면 반드시 어긋난다. 구두 합의는 합의가 아니다.

"Let me reshare the Notion doc where I captured this — here's the link."

링크 하나가 모든 오해를 끝낸다. "저번에 말했잖아요"가 자꾸 나온다면, 그건 팀 전체의 문서화 습관을 점검할 신호다.

6. "Just change this"

Slack으로 메시지가 온다. "Hey, just change this. Thanks." 받은 사람이 스크린샷을 다시 열어본다. 뭘 어떻게 바꾸라는 건지가 없다. 'just'는 영어에서 굉장히 조심해야 하는 단어다. "It's just a small change"라고 말하는 순간 — 상대방은 속으로 '그럼 네가 해'라고 생각한다. 명확하지 않은 요청은 반드시 한 번의 왕복을 만들고, 그 왕복이 쌓일 때마다 신뢰가 조금씩 깎인다.

"Could you update the CTA button text from 'Start' to 'Get Started for Free'?"

From A to B. 이 구조가 제일 명확하다. 바꿀 대상, 현재 값, 바꿀 값. 이 세 개면 충분하다.

7. "Why isn't this working?"

배포 직후 버그를 발견했다. 급하다. Slack에 바로 메시지를 보낸다. "Why isn't the login working?? This was working yesterday!" 받은 사람이 메시지를 읽는다. 그리고 방어적으로 반응하기 시작한다. 특히 영어에서 "Why" + "isn't/didn't/don't"로 시작하는 문장은 공격적인 뉘앙스가 있다. 의도가 없어도 비난처럼 들린다. 한 번 방어적인 반응이 나오면, 그 다음부터 소통이 막힌다.

"I'm encountering an issue with the login flow. Here's how to reproduce it: [steps]. Expected behavior: [X]. Actual behavior: [Y]. I've logged this in Jira — tagging you for visibility."

버그를 리포트할 때 필요한 건 세 가지다: 재현 방법, 기대 결과, 실제 결과. 이렇게 말하면 상대방은 바로 작업에 들어갈 수 있다. 같이 해결하는 톤이 되면, 관계도 유지된다.

8. "I need this ASAP"

마감이 얼마 안 남았다. 다급하게 메시지를 보낸다. "I need this ASAP — it's really urgent." 받은 사람은 지금 하고 있는 작업을 멈춰야 하는지 판단할 수가 없다. 'ASAP'이 오늘 COB인지, 이번 주인지, 그냥 빨리 해달라는 건지 알 수가 없다. 'ASAP'은 쓸수록 효과가 떨어지는 단어다. 모든 게 ASAP이면, 아무것도 ASAP이 아닌 거다.

"This is time-sensitive for the Q1 launch. Would it be possible to have this by Friday EOD? If not, let's discuss what we can adjust."

날짜를 주고, 안 되면 조율하겠다는 여지를 남긴다. 이 한 문장이 ASAP보다 훨씬 더 빠르게 일을 움직인다.

결국 이 모든 게 하나로 연결된다

글로벌 팀에서 영어로 협업할 때, 직군에 상관없이 해야 할 일은 같다. 내 느낌을 기준으로 번역하는 것.

Figma 시안, 브랜드 가이드라인, 디자인 시스템, PRD, 티켓 — 이것들이 전부 기준이 된다. 이 기준을 근거로 말할 때, 비로소 진짜 협업이 된다. 영어를 잘하는 사람이 되려는 게 아니다. 영어로도 신뢰받는 사람이 되는 거다.

자주 쓰는 협업 영어 표현 모음