필사 모드: AI 엔지니어 회의 영어: 모른다고 말하면서 신뢰를 잃지 않는 법

들어가며: 이 분야에서 제일 많이 하는 말

AI 팀 회의 녹취를 훑어보면 눈에 띄는 점이 있습니다. 시니어일수록 확신하는 문장을 적게 씁니다. 대신 아는 것과 모르는 것의 경계를 긋는 문장을 많이 씁니다. 이 두 가지는 완전히 다른 능력입니다.

영어 회의 자료는 대부분 반대로 가르칩니다. 자신 있게 말하라고, 애매한 표현을 줄이라고 합니다. 일반적인 사무 환경에서는 맞는 조언일 수 있습니다. 그런데 AI 개발에서는 이 조언을 그대로 따르면 오히려 신뢰를 잃습니다.

이유는 이 분야의 숫자가 전부 조건부이기 때문입니다. 어떤 평가 점수든 어떤 하네스로, 어떤 심사자로, 어떤 데이터에서 쟀는지에 따라 달라집니다. 리더보드와 벤치마크를 읽는 법에서 정리한 것처럼, 자체 보고 수치와 하네스 차이와 심사자 편향은 예외가 아니라 기본 조건입니다. 그런 분야에서 조건 없이 숫자만 말하는 사람은 자신감 있어 보이는 게 아니라 조건을 모르는 사람으로 보입니다.

그래서 이 글의 주제는 하나입니다. AI 회의에서 가장 자주 필요한 영어는 확신의 언어가 아니라 불확실성을 신뢰감 있게 표현하는 언어입니다. 모르겠다는 말을 무능하지 않게 하는 능력이 이 분야의 핵심 회의 기술입니다.

왜 초반의 모른다가 신용 자산인가

먼저 왜 이게 손해가 아닌지부터 정리하겠습니다. 이 논리를 스스로 납득하지 않으면 실제 회의에서 그 문장이 안 나옵니다.

불확실성을 정확히 말하는 사람은 확실하다고 말할 때 믿을 수 있습니다. 반대로 매번 확신하는 사람은 한 번 틀리는 순간부터 모든 숫자에 할인이 붙습니다. 이게 실질적인 손해입니다. 다음에 정말로 확실한 결과를 들고 갔을 때 그 확신이 전달되지 않습니다.

두 번째 이유는 이 분야의 구조에서 옵니다. 숨긴 회귀는 반드시 드러납니다. 다른 사람이 같은 평가를 돌리고, 다른 팀이 같은 모델을 붙여 보고, 결국 사용자가 봅니다. 늦게 드러날수록 비용이 큽니다. 이미 그 결과 위에 다른 결정이 쌓였기 때문입니다.

세 번째는 시간입니다. 원인을 다 밝힌 다음에 보고하겠다는 태도는 성실해 보이지만, 그 사이에 팀은 잘못된 전제로 일정을 짭니다. 정보가 없어서 못 하는 결정과, 잘못된 정보로 이미 내린 결정은 복구 비용이 다릅니다.

이 글에는 결과를 좋아 보이게 만드는 문장이 없습니다. 의도적으로 뺐습니다. 그런 문장은 한두 번 통하고 그 뒤로는 통하지 않으며, 통하지 않게 된 시점에는 이미 커리어 비용이 발생한 뒤입니다.

신뢰감 있는 불확실성의 세 조각

모른다는 말이 무능하게 들리는 건 모르기 때문이 아닙니다. 어디까지 모르는지를 말하지 않기 때문입니다. 같은 상황에서 나온 두 문장을 비교해 보겠습니다.

[신뢰를 잃는 형태]
I'm not sure. I'll look into it.

[신뢰를 얻는 형태]
I don't know yet whether it's the model or the harness.
What I do know is that it started after Tuesday's deploy,
and it only shows up on the long-context slice.
I'm bisecting the commits and I'll have an answer Thursday.

두 번째 문장에도 모른다는 말이 그대로 들어 있습니다. 정보량이 다를 뿐입니다. 여기에 들어간 세 조각이 이 글의 뼈대입니다.

경계가 빠지면 무능하게 들립니다. 모른다는 상태만 보고하는 셈이라 듣는 사람이 할 수 있는 게 없습니다.

근거가 빠지면 가볍게 들립니다. 같은 82점도 한 번 돌린 값인지 다섯 번 평균인지에 따라 완전히 다른 문장인데, 그 차이가 사라집니다.

다음 단계가 빠지면 회피처럼 들립니다. 이 부분이 가장 자주 빠집니다. 모른다고 말한 뒤에 침묵하면 상대가 다음 행동을 만들어야 하고, 그러면 모른다는 말의 대가를 상대가 치릅니다.

아래 상황별 표현은 전부 이 세 조각의 변주입니다. 표현을 외우기보다 어느 조각이 빠졌는지 보는 눈을 기르는 편이 오래 갑니다.

상황 1: 평가 결과를 발표하면서 한계를 함께 말하기

가장 자주 오는 상황이고, 가장 자주 실수하는 상황입니다. 흔한 실수는 숫자를 먼저 말하고 한계를 나중에 붙이는 것입니다. 그러면 한계가 변명처럼 들립니다. 한계를 먼저 말하고 숫자를 주면 같은 내용이 신중함으로 읽힙니다.

숫자를 말할 때 함께 붙이면 좋은 조건이 넷 있습니다. 어떤 데이터, 몇 번 실행, 어떤 심사자, 무엇과 비교. 넷을 다 말할 필요는 없지만, 하나도 안 말하면 그 숫자는 회의실에서 실제보다 단단하게 유통됩니다.

상황 2: 회귀가 났는데 원인을 아직 모를 때

여기서 가장 큰 유혹은 원인을 알아낸 다음에 말하는 것입니다. 하루를 아끼려다 팀 전체의 사흘을 태우는 선택입니다.

Heads up은 엔지니어링 대화에서 표준에 가까운 표현이지만 구어체입니다. 임원에게 가는 문서나 격식 있는 메일에서는 I want to flag를 쓰는 편이 어울립니다. 이 판단은 회사 문화에 따라 다릅니다. 문서에서도 캐주얼한 톤을 쓰는 팀에서는 굳이 바꿀 필요가 없습니다.

No action needed from you yet은 짧지만 효과가 큽니다. 나쁜 소식을 들은 사람의 첫 반응은 대개 내가 뭘 해야 하나이고, 그 질문에 먼저 답해 주면 보고가 훨씬 가볍게 받아들여집니다.

상황 3: 지표는 올랐는데 실제 품질은 아닐 때

이 분야에서 가장 말하기 어려운 상황일 수 있습니다. 좋은 소식을 스스로 취소하는 자리이기 때문입니다. 그런데 이걸 말하지 않으면 팀 전체가 잘못된 방향으로 한 분기를 씁니다.

이 상황의 이름이 이미 있습니다. 리워드 해킹입니다. 지표는 진짜로 올랐는데 과제는 실패한 상태를 가리키고, 시스템 고장이 아니라 우리가 정의한 목표를 정확히 최적화한 결과라는 점이 핵심입니다.

영어권 ML 팀에서는 That might be Goodhart처럼 굿하트의 법칙을 줄여 부르는 말이 통합니다. 다만 이건 ML 팀 안에서만 통하는 축약이라 다른 부서가 섞인 회의에서는 풀어 말하는 편이 안전합니다. We may be optimizing the measure instead of the thing we care about 정도면 누구에게나 전달됩니다.

상황 4: 데이터 품질과 라벨링 이견

라벨링 논쟁이 길어지는 이유는 대개 사람들이 서로 다른 것을 논쟁하고 있어서입니다. 모델이 틀렸는지를 다투는 줄 알았는데 실은 라벨 정의를 다투고 있는 경우가 많습니다. 먼저 무엇을 다투고 있는지 이름 붙이는 문장이 시간을 가장 많이 아낍니다.

여섯 번째 문장은 등록 판단이 들어간 표현입니다. 라벨 품질 문제를 제기하면 그 작업을 한 사람이나 팀을 비판하는 것처럼 들리기 쉽습니다. 비판의 대상을 사람에서 지침으로 옮기면 같은 문제 제기가 훨씬 안전하게 전달됩니다. 그리고 대개 이게 사실이기도 합니다. 라벨이 흔들리는 진짜 원인은 작업자의 성실성이 아니라 정의의 모호함인 경우가 많습니다.

일곱 번째 문장은 논증으로도 강합니다. 사람 사이에 일치하지 않는 기준을 모델에게 요구하는 건 불가능한 요구라는 지적이라, 반박하기가 어렵습니다.

상황 5: 비용과 지연 시간 트레이드오프

이 대화에서 엔지니어가 자주 하는 실수는 기술적 판단과 사업적 판단을 섞어 말하는 것입니다. 둘을 분리해서 말하면 발언의 무게가 오히려 올라갑니다. 내 영역에서는 단정하고, 남의 영역에서는 정보만 주는 형태입니다.

네 번째 문장이 이 절의 핵심입니다. that's a product call, not a technical one은 내 의견을 밝히면서 결정 권한은 상대에게 남겨 둡니다. 의견을 안 내는 것도 아니고 남의 결정을 대신하는 것도 아닌 자리를 만들어 줍니다.

마지막 문장은 세 조각 중 근거에 해당합니다. 추정치와 측정치를 구분하지 않고 말하면, 나중에 실측이 다르게 나왔을 때 신뢰가 깎입니다. 추정임을 밝히고 말한 추정은 틀려도 비용이 없습니다.

상황 6: 연구 일정과 제품 일정이 부딪칠 때

연구는 언제 결과가 나올지 모르고 제품은 날짜가 필요합니다. 이 충돌은 해결되지 않고 관리될 뿐이라, 관리 가능한 형태로 바꿔 말하는 것이 이 대화의 전부입니다.

decision date와 delivery date를 구분하는 프레임이 여기서 가장 실용적입니다. 연구가 언제 끝날지는 모르지만, 언제쯤이면 계속할지 접을지 판단할 수 있는지는 대개 말할 수 있습니다. 그리고 제품 쪽이 실제로 필요한 것도 대부분 그것입니다.

등록에 대한 판단을 하나 붙이겠습니다. I'd rather give you a date I believe than a date you want to hear처럼 상대를 살짝 지목하는 변형이 돌아다니는데, 이건 팀에 따라 원칙적으로 들리기도 하고 수동공격적으로 들리기도 합니다. 상대를 문장에서 빼고 나에 대해서만 말하는 형태가 어느 팀에서든 안전합니다. 위 표의 다섯 번째 문장이 그 형태입니다.

상황 7: 비기술 이해관계자에게 불확실성 설명하기

이 자리에서 실패하는 방식은 두 가지입니다. 지나치게 단순화해서 사실이 아닌 말을 하거나, 정확하게 말하려다 아무것도 전달하지 못하거나.

세 가지 규칙이 대체로 잘 통합니다. 숫자는 하나만 주고, 전문 용어를 빼고, 실패 모드를 반드시 함께 말합니다.

마지막 문장은 이 청중에게 특히 중요합니다. 비기술 이해관계자가 가장 자주 놓치는 것이 틀리는 방식입니다. 실패하면 멈출 거라고 생각하고 계획을 짜는데, 언어 모델의 실패는 대개 그렇지 않습니다. 이걸 미리 말하지 않으면 나중에 놀라움이 사고가 됩니다.

빼야 할 단어의 예를 들면 이렇습니다. eval, harness, ablation, in-distribution, held-out, seed. 이 단어들이 나쁜 게 아니라 이 자리에서 안 통할 뿐입니다.

상황 8: 아직 모른다고 말하되 다음 단계를 함께 주기

앞의 세 조각이 가장 압축적으로 필요한 순간입니다. 회의 중에 갑자기 질문이 들어오고, 답을 모르고, 방에는 여덟 명이 있습니다.

네 번째 문장이 특히 유용합니다. 즉답을 요구받았을 때 그 요구를 거절하지 않으면서 조건을 되돌려 주는 형태입니다. 상대가 추측이라도 필요하다고 하면 추측을 주면 되고, 정확한 답이 필요하다고 하면 시간을 얻습니다. 어느 쪽이든 내가 말한 것의 성격이 명확해집니다.

마지막 문장은 이 분야에서 자주 필요합니다. 영어 벤치마크 결과를 한국어나 일본어로 그대로 옮길 수 없는 경우가 많은데, 그 경계를 미리 그어 두면 나중에 놀랄 일이 줄어듭니다.

상황 9: 남의 실험 결과에 이견 제기하기

여기서의 원칙은 하나로 정리됩니다. 결론을 반박하지 말고 조건을 확인하십시오.

이유는 단순합니다. 조건 질문에는 답이 있고 공격에는 답이 없습니다. That's wrong에는 방어 말고 할 수 있는 게 없지만, What was the baseline?에는 답이 있습니다. 그리고 답하는 과정에서 대개 문제가 저절로 드러납니다.

One of us has a bug는 이 분야에서 특히 잘 작동하는 문장입니다. 두 사람의 결과가 다를 때 누가 틀렸는지를 미정으로 남기면서 원인이 있다는 사실만 확정합니다. 상대가 방어할 이유가 없어지므로 대화가 바로 기술적인 쪽으로 넘어갑니다.

Before I push back도 유용합니다. 이견이 온다는 것을 미리 알려서 상대가 준비할 시간을 줍니다. 다만 이 정도의 예고가 필요한지는 팀에 따라 다릅니다. 직설적인 토론이 기본값인 팀에서는 불필요한 완충으로 느껴질 수 있고, 반대로 조심스러운 팀에서는 이 한 문장이 갈등을 막습니다. 어느 쪽인지 모르겠으면 붙이는 편이 손해가 적습니다.

상황 10: 재현이 안 될 때

재현 실패는 거의 항상 누군가의 실수인데, 그 누군가가 누구인지는 아직 모르는 상태입니다. 먼저 내 쪽을 의심하는 문장으로 시작하면 대화가 조사로 흐르고, 상대 쪽을 먼저 의심하면 대화가 방어로 흐릅니다.

That's probably on my end에 대해서는 등록 판단을 하나 덧붙여야 합니다. 이건 상대의 체면을 지키면서 문제를 제기하는 장치이고, 나중에 상대 쪽 문제로 밝혀져도 아무도 손해를 보지 않습니다. 다만 이 표현을 습관적으로 남발하면 실제로 자신 없어 보일 수 있습니다. 자기 비하를 낮게 평가하는 팀에서는 특히 그렇습니다. 재현 실패처럼 원인이 정말로 불확실한 상황에서는 쓰고, 명백히 상대 코드의 문제일 때는 쓰지 않는 편이 좋습니다.

헤지의 세기 눈금

불확실성 표현을 잘 쓰려면 세기를 조절할 수 있어야 합니다. 아래는 대략의 눈금입니다. 정확한 확률로 매핑되는 것은 아니고 관행적인 인상에 가깝습니다.

여기에 하나의 규칙을 붙이겠습니다. 한 주장에 헤지는 하나면 충분합니다. I could be wrong, but I think maybe it might be the tokenizer처럼 네 개를 쌓으면 주장 자체가 사라지고, 듣는 사람은 내용 대신 화자의 자신감 없음을 기억합니다.

다만 이 판단은 팀 문화에 따라 달라집니다. 완곡함이 기본값인 조직에서는 헤지 두 개가 예의의 하한선일 수 있습니다. 반대로 직설적인 엔지니어링 팀에서는 하나도 많게 느껴집니다. 회의 두세 번만 관찰하면 그 팀의 기본값이 보입니다. 가장 빠른 방법은 그 팀에서 신뢰받는 시니어 한 명의 말투를 기준선으로 잡는 것입니다.

미국식과 영국식이 갈리는 지점

회의에서 실제로 오해를 만드는 몇 가지가 있습니다.

table 동사는 뜻이 정반대입니다. 미국에서 Let's table this는 나중으로 미루자는 뜻이고, 영국에서 to table an item은 안건으로 올리자는 뜻입니다. 회의 진행 중에 정확히 반대로 알아들을 수 있는 단어라 위험합니다. 양쪽이 섞인 회의에서는 그냥 Let's come back to this later나 Let's add this to the agenda로 풀어 말하는 게 안전합니다.

quite의 세기가 다릅니다. 미국에서 quite good은 꽤 좋다는 칭찬에 가깝고, 영국에서 quite good은 나쁘지는 않다는 정도의 미지근한 평가로 읽히는 경우가 많습니다. 평가 결과를 논평할 때 오해가 나기 쉬운 단어입니다. 확실하게 말하고 싶으면 quite를 빼고 숫자를 말하는 편이 낫습니다.

momentarily도 갈립니다. 미국에서는 곧이라는 뜻으로, 영국에서는 잠깐 동안이라는 뜻으로 쓰이는 경향이 있습니다. in a moment나 briefly로 바꾸면 오해가 없습니다.

Sorry의 무게가 다릅니다. 영국에서 Sorry는 사과보다 대화의 완충재에 가깝게 훨씬 자주 쓰입니다. 영국 동료가 사과를 남발하는 것처럼 보여도 그건 사과가 아닙니다. 반대로 미국 회사 문화에서는 지연을 사과하는 대신 Thanks for your patience로 바꾸는 것을 선호하는 경우가 많습니다. 다만 이건 회사 문화 차이가 나라 차이만큼 크므로 일반화하지는 않겠습니다.

하지 않는 편이 나은 것들

결과를 부풀리는 문장. 이 글에는 그런 예시가 없고 앞으로도 넣지 않겠습니다. 이유는 윤리적인 것만이 아닙니다. AI 개발에서는 부풀린 숫자가 대개 그 분기 안에 검증됩니다. 다른 팀이 같은 평가를 돌리고, 제품에 붙이고, 사용자가 씁니다. 부풀린 문장의 유효기간은 그 숫자가 재현되기까지의 시간뿐입니다.

회귀를 다음 보고까지 미루기. 위와 같은 이유로 결국 드러나고, 늦게 드러날수록 그 위에 쌓인 결정이 많아집니다.

It should work. 엔지니어링 영어에서 이 문장은 사실상 테스트를 안 했다는 신호로 읽힙니다. should는 보고가 아니라 예측이기 때문입니다. 대신 무엇을 테스트했고 무엇을 안 했는지 말하는 편이 낫습니다. I tested the happy path and the empty input. I haven't tested concurrency.

단독으로 쓰는 I'm not sure. 내부 상태만 보고하고 상대에게 아무것도 남기지 않습니다. 뒤에 경계나 다음 단계 중 하나만 붙어도 완전히 달라집니다.

조건 없는 숫자. 82라고만 말하면 회의록에는 82만 남고, 그 82는 몇 주 뒤에 근거로 인용됩니다. 어떤 데이터와 몇 번 실행이었는지는 그때 아무도 기억하지 못합니다.

질문으로 끝내는 불확실성 보고. Let me know if you have any questions.로 끝내면 다음 행동을 상대에게 미루는 셈입니다. 불확실성을 보고할 때는 내가 다음 단계를 제시하고 끝내는 편이 낫습니다.

남의 실험을 결론으로 반박하기. 조건 확인이 먼저입니다. 조건을 확인하고 나서도 이견이 남으면 그때 결론을 말하면 되고, 그 시점의 이견은 훨씬 강합니다.

실전 흐름: 주간 모델 리뷰

앞의 조각들이 실제 회의에서 어떻게 붙는지 보겠습니다.

PM:  So the new checkpoint is better, right? Can we ship Friday?

나:  Two caveats before the number.
     It is a single run, and it is on our internal set,
     so it is not comparable to the vendor numbers.
     With that said, we are up two points.
     Two points is inside the noise for this set,
     so I would not call it a win yet.

PM:  Okay. When will you know?

나:  What I can give you is a decision date, not a delivery date.
     Three more seeds is about two days of compute.
     By Wednesday I will know whether the gain is real.

PM:  And if it is real?

나:  Then there is a second question. I read twenty outputs by hand
     and some of them got longer without getting better.
     The metric moved, but I am not sure the task did.
     I would want a human check on a small sample before we ship.

동료: I saw the opposite last week - my run showed a clear gain.

나:  That is interesting, because it contradicts mine.
     One of us has a bug. Before I push back,
     what was your baseline, and how many seeds?

동료: Baseline was the March checkpoint. One seed.

나:  Okay, mine is against last month. That could be the whole difference.
     Can we get to the same number before we decide anything on top of it?

PM:  What do I tell leadership on Thursday?

나:  Short version: it looks promising, we do not know yet if it is real,
     and we will know by Wednesday.
     The failure mode to watch is longer answers that are not better ones.
     No decision needed from them this week.

이 대화에서 나는 좋은 소식을 한 번도 확정하지 않았습니다. 그런데 회의는 막히지 않았습니다. 매번 경계를 긋고, 근거를 밝히고, 다음 단계와 시점을 함께 줬기 때문입니다.

오늘 바로 해볼 것

표현을 전부 외울 필요는 없습니다. 세 개만 자동으로 나오게 만드세요.

1. 한계를 앞에 두는 한 문장: Two caveats before I give you the number. 숫자를 말하기 전에 조건을 먼저 놓는 습관이 이 글 전체에서 가장 값이 큽니다.
2. 모른다를 완성하는 한 문장: I don't know yet. Here's what would tell us, and here's when. 경계와 다음 단계가 한 문장에 들어 있습니다.
3. 이견을 조건 확인으로 바꾸는 한 문장: I'm not doubting the number. I'm trying to work out what it's comparable to.

그리고 다음 회의에서 한 번만 확인해 보세요. 내가 말한 숫자에 조건을 붙였는가. 붙이지 않았다면, 그 숫자는 지금 회의실에서 내가 아는 것보다 단단한 것으로 유통되고 있습니다.

이어서 읽기

• 상황이 없어도 영어가 느는 법 — 위 상황들을 실제 회의 전에 혼자 돌려 보는 방법.
• 리더보드와 벤치마크를 읽는 법 — 어떤 조건을 붙여야 하는지, 그 조건 목록의 근거.
• AI 벤치마크 탐색기 — 회의에서 인용할 수치의 출처와 조건을 직접 확인해 봅니다.
• 하네스 RPG — 평가자 병목과 리워드 해킹이 실제로 어떻게 생기는지 시뮬레이션으로 겪어 봅니다.
• 영어 회화 연습 — 위 대화 흐름을 소리 내어 연습합니다.