"모든 인스턴스는 오브젝트죠" — 판교 사투리가 만드는 회의실의 진입장벽

회의실에서 언어의 밀도가 올라가는 순간

AI 스타트업과의 미팅. 대표와 개발자, 기획자가 함께 앉아 서로의 BM을 이야기하고 에이전트 같은 특정 기술 개발까지 논의가 이어졌다. 기획 내용이 그려지면 R&R을 나누고 개발 마일스톤을 구성하는 이야기로 넘어간다.

문제는 개발 이슈가 본격적으로 끼어들면서 시작된다. 영어라고 하기엔 한국어에 가깝고 한국어라고 하기엔 영어가 곳곳에 박힌 이른바 '판교 사투리'의 밀도가 급격히 올라간다. 기획자도 개발자도 고개를 끄덕이는데, 옆자리 팀장이 귓속말을 건넨다. "혹시 잘 이해하고 있어요?" "네, 뭐… 대충 알아듣겠지만…."

"오늘 이야기 나눈 거 메일로 공유 좀 해주세요." "네, 저희가 PRD랑 SoW부터 준비해서 메일로 전달하겠습니다."

영어를 배우면 해결되나

답은 아니다. 영어를 잘한다고 개발자들이 쓰는 용어를 이해하게 되는 것도 아니고, 개발 언어를 배운다고 영어가 따라오는 것도 아니다.

단어 하나에 여러 뜻이 겹치기 때문이다. 'right'은 맞다는 뜻도, 권리도, 오른쪽도 된다. 'object'는 물체, 대상, 객체로 두루 쓰이는데 개발 미팅에서는 번역 없이 그대로 나온다. "모든 인스턴스는 오브젝트죠."

같은 일은 한국어 안에서도 벌어진다. "주소가 어떻게 되죠?"라는 질문에 "서울시…"라고 답했다가 "아 아뇨, 사이트 어드레스요"라는 정정이 돌아오는 식이다. 파이썬에서도 객체 주소(object address)라는 표현을 쓴다.

필요한 건 사전이 아니라 맥락 감각

결국 언어는 상황과 맥락에 따라 같은 단어가 전혀 다른 옷을 입는다. 맥락만 잡아내면 단어를 몰라도 대화는 굴러간다. 완벽한 사전적 이해보다 '지금 이 상황에서 이 단어가 뭘 가리키는지' 감을 잡는 능력이 더 실전적이다. 경험이 중요한 이유이기도 하다.

되묻기는 비효율이 아니다

대학에서 배우는 SMCRE 모델(발신자-메시지-채널-수신자-효과)은 깔끔하지만, 실무에서는 이 흐름을 하나하나 들여다볼 틈이 없다. 그랬다간 회의가 늘어지고 의사결정이 늦어진다.

대신 쓸 수 있는 도구가 되묻기다. "그럼 여기 이 포인트에서 말씀하신 내용은 이렇게 가져간다는 거죠?" 내뱉어진 말을 한 번 통역해 확인하는 문장이다. 이 한 문장이 나중에 스펙 해석 차이로 생기는 재작업보다 훨씬 싸다. 회의 구조 자체를 결론이 나오도록 설계하는 방법은 미팅에도 기승전결이 있다에 정리돼 있다.

효율을 위한 언어가 장벽이 될 때

판교 사투리는 없어지지 않을 것이다. 그 바닥에서는 이런 표현이 더 빠르고 정확하게 통하기 때문이다. 문제는 효율을 위해 만들어진 언어가 누군가에게는 진입장벽이 된다는 점이다. 편리함과 소외감이 한 테이블 위에 놓인다.

다행인 것은 이제 하나하나 검색하지 않고 생성형 AI에게 바로 물어볼 수 있다는 점이다. 미팅 전 최소한의 예습 비용이 크게 낮아졌다. 다만 진짜 해법은 개인의 예습이 아니라 팀 차원의 언어 정렬이다. 새 사람이 들어올 때마다 같은 진입장벽이 반복된다면, 그건 개인의 학습 문제가 아니라 온보딩 설계 문제다. 조직에 없는 역량을 채용으로 메우려 할 때 생기는 문제는 'AI 프로덕트 빌더' 채용을 시도했다가 배운 것에서도 비슷한 형태로 나타난다.

자주 묻는 질문