02. 번역기의 배신

2편: 번역기의 배신

공식문서를 번역기로 읽으면 되지 않나?

1편에서 공식문서의 중요성을 강조했더니 이런 질문이 들어올 수 있습니다.

“요즘 번역기 좋아졌는데? ChatGPT도 있고, DeepL도 있고, 구글 번역도 있고… 굳이 영어 공부할 필요 있나? 공식문서도 번역기로 읽으면 되잖아?”

저도 그렇게 생각했습니다. 2025년이면 AI가 완벽하게 번역해줄 줄 알았죠. GPT-5도 있고, Claude도 있고, 번역 특화 AI들도 많은데 뭐가 문제겠어요? 하지만 이런 시나리오를 생각해봅시다. 생각이 좀 달라지실거에요.

시나리오 1: 프로덕션 배포 직전의 대참사

한 개발자가 Redis 문서를 번역기로 읽고 있었는데, 이런 문장이 있었습니다(EXPIRE 명령어 설명):

"Set a timeout on key. After the timeout has expired, the key will automatically be deleted."

번역기 결과:

"키에 시간 초과를 설정합니다. 시간 초과가 만료된 후, 키는 자동으로 삭제됩니다."

별 문제 없어 보이죠? 저도 그렇게 생각했습니다. 그런데 동료가 제 코드를 리뷰하다가 물어봅니다.

“왜 expire를 1로 설정했어요?”

“문서에 시간 초과를 설정하라고 해서… 1초면 충분할 것 같아서요.”

“…이거 TTL(Time To Live)이에요. 1초 후에 데이터 사라져요.”

“네? 아 그게… 시간 초과가…”

말문이 막혔습니다. “timeout”을 “시간 초과”로 번역하니까 “연결이 끊기는 시간”으로 오해했던 겁니다. 실제로는 “유효 기간”이었는데. 만약 이대로 배포했다면 모든 캐시 데이터가 1초마다 사라지는 대참사가 일어날 뻔했습니다.

시나리오 2: 문맥을 정확하게 파악하지 못하는 기계번역

Semaphore는 운영체제/동시성 프로그래밍에서 공유 자원에 동시에 접근할 수 있는 작업(스레드/프로세스)의 ‘허용 가능한 개수’를 제어하는 동기화 기법입니다. 그냥 음차해서 “세마포어”라고 쓰는 것이 표준적이며, 직역해서 신호기라고 하면 의미가 흐려집니다. 특히 GitHub README 같은 곳을 기계번역한 초벌본에서 자주 보이는 실수입니다.

공식 문서(일반적인 정의)에서 흔히 나오는 문장 예:

A counting semaphore is a type of lock that allows you to limit the number of processes
that can concurrently access a resource to some fixed number.

이걸 제대로 해석하면: “카운팅 세마포어는 어떤 자원에 동시에 접근할 수 있는 프로세스(혹은 스레드)의 수를 고정된 상한으로 제한하는 락(동기화 수단)의 한 종류다.”

번역기를 그대로 쓰면 종종 신호기 기반 잠금 같이 어색한 표현이 나오고, 개념을 처음 접하는 사람은 ‘신호를 주고받나?’ 같은 잘못된 심상을 가지기 쉽습니다.

예시 - 어떤 오픈소스 프로젝트의 README:

원문:
"This library uses semaphores to handle concurrent requests. 
The semaphore limits the number of parallel operations to prevent resource exhaustion."

번역기 결과:
"이 라이브러리는 동시 요청을 처리하기 위해 신호기를 사용합니다.
신호기는 자원 고갈을 방지하기 위해 병렬 작업 수를 제한합니다."

이걸 읽고 이해할 수 있나요? 신호기가 대체 뭘 하는 건지…

실제로 일어난 대화:

나: "이 부분 신호기로 처리하면 될 것 같은데요"
팀장: "신호기요? 무슨 신호?"
나: "아... README에서 본 건데... semaphore..."
팀장: "아 세마포어. 번역기로 문서 읽으셨군요."

순간 공기가 얼어붙었습니다.

기술 용어 번역의 근본적 한계

1. 도메인 특화 용어

개발에서 쓰는 단어들은 일반적인 뜻과 완전히 다른 경우가 많습니다:

영어	일반 번역	개발에서 의미	문제점
thread	실	스레드 (실행 단위)	“실을 생성한다”?
memory leak	기억 누출	메모리 누수	“기억이 샌다”?
cache	은닉처	캐시 (임시 저장소)	“은닉처를 비운다”?
cookie	쿠키(과자)	쿠키 (웹 데이터)	“과자를 저장한다”?
daemon	악마	데몬 (백그라운드 프로세스)	“악마를 실행한다”?

2. 새로운 용어들

기술이 발전하면서 새로 생긴 용어들은 번역 데이터베이스에 없습니다:

• containerization → 번역기: “용기화” / 실제: “컨테이너화”
• orchestration → 번역기: “오케스트라 연주” / 실제: “오케스트레이션”
• serverless → 번역기: “서버 없는” / 실제: “서버리스”
• edge computing → 번역기: “가장자리 컴퓨팅” / 실제: “엣지 컴퓨팅”

3. 문맥 의존적 번역

같은 단어여도 상황에 따라 완전히 다릅니다:

// 'build'의 경우
"build a Docker image" → 도커 이미지를 빌드한다 (O) / 건설한다 (X)
"build a house" → 집을 짓는다 (O) / 빌드한다 (X)

// 'run'의 경우  
"run the application" → 애플리케이션을 실행한다 (O) / 달린다 (X)
"run a marathon" → 마라톤을 뛴다 (O) / 실행한다 (X)

2025년 현재 GPT-5, Claude 4, DeepL 같은 최신 AI 번역기도 이런 미묘한 맥락 차이를 완벽하게 구별하지 못합니다.

실제 개발할 때 겪는 문제들

검색 결과가 엉망

번역된 용어로 검색하면:

• “신호기 프로그래밍” 검색 → 교통 신호등 제어 시스템 나옴
• “약속 체이닝” 검색 → 결혼 상담소 광고 나옴
• “semaphore programming” 검색 → 제대로 된 자료 나옴
• “promise chaining” 검색 → JavaScript 튜토리얼 나옴

Stack Overflow 검색 지옥

실제 경험:

• 한국어로 번역해서 검색: 결과 0개
• 영어로 검색: 정확히 같은 문제 해결한 답변 5개

Promise가 “약속”이 되면서 생기는 문제

JavaScript 문서에서 메서드 설명이 이렇게 되어 있다면 어떨까요?:

// 원문
"This method returns a Promise that resolves when the operation completes"

// 번역
"이 메서드는 작업이 완료될 때 해결되는 약속을 반환합니다"

이걸 읽고 이해할 수 있나요? 실제 코드와 비교해보면:

// "약속이 해결되면 then을 실행한다"고 이해하면?
fetch('/api/data')
  .then(response => response.json())  // 약속이... 뭐?
  .then(data => console.log(data))    // 그 다음 약속이...?
  .catch(error => console.error(error)); // 약속을 잡는다?

// "Promise가 resolve되면 then을 실행한다"고 이해하면?
fetch('/api/data')
  .then(response => response.json())  // Promise가 성공하면 실행
  .then(data => console.log(data))    // 체이닝된 Promise 처리
  .catch(error => console.error(error)); // Promise rejection 처리

어떤 게 더 이해하기 쉬운가요?

번역기의 또 다른 함정들

1. 뉘앙스 완전 손실

원문: "This feature is experimental. Use with caution."
번역: "이 기능은 실험적입니다. 주의해서 사용하세요."

실험적이라는 말은 실제로는 서비스 제공자(Provider)가 동작 오류에 대해 책임을 지지 않는다는 의미로 사용하는 경우가 많기 때문에, 직역하면 이상한 의미가 됩니다.

2. 경고 메시지 오독

원문: "DEPRECATED: This will be removed in v3.0"
번역: "사용되지 않음: 이것은 v3.0에서 제거될 것입니다"

Deprecation은 단순히 사용하지 않음을 의미하는 것이 아닌 업데이트 지원 중단으로 권장되지 않는 메서드를 의미합니다.

3. 코드 주석까지 번역되는 재앙

# 원본 코드
# Initialize the connection pool
pool = ConnectionPool()

# 번역기 거친 후
# 연결 수영장을 초기화합니다
pool = ConnectionPool()  # pool이 수영장...?

결론: 번역기는 보조 도구일 뿐

번역기는 100% 이해했을 때 검증 용도로만 써야 합니다.

잘못된 사용법:

1. 영어 문서 열기
2. 전체 선택 → 번역기 돌리기  
3. 번역 결과 맹신하기
4. 이상한 코드 작성
5. 프로덕션 터뜨리기 직전
6. 동료가 구해줌

올바른 사용법:

1. 영어 문서 직접 읽기
2. 모르는 단어만 사전 찾기
3. 이해 안 되는 문장만 번역기 참고
4. 여러 번역 결과 비교
5. 원문과 대조하여 검증
6. 확실히 이해한 후 코드 작성

그럼 어떻게 해야 하나?

답: 영어 배우기를 피하지 말자

“번역기 있는데 왜 배워?”가 아니라 “번역기 때문에 더 배워야 한다”

왜냐하면:

• 번역이 맞는지 틀린지 판단하려면 영어를 알아야 함
• 검색할 때 영어 키워드를 써야 제대로 된 자료 나옴
• 동료들과 소통할 때 원래 용어를 알아야 함
• GitHub, Stack Overflow에서 활동하려면 영어 필수
• 새로운 기술 정보는 100% 영어로 먼저 나옴

번역기가 발전해도 개발자가 영어를 배워야 하는 이유는 변하지 않습니다. 오히려 AI 시대가 되면서 더 많은 영어 자료를 더 빠르게 소화해야 하는 상황이 되었죠.

다음 편 예고

“그래, 영어 배워야 하는 건 알겠는데… 어떻게?”

영어를 어떻게 배워야 하는지에 대한 구체적인 방법을 모르는 경우가 많습니다. 학원? 인강? 문법책? 다 해봤는데 안 되던데?

“기술 영어”라는 특별한 영역을 정복하는 법, 곧 공개합니다.

---

⬅ 이전: 1편 당신이 당신의 문제를 스스로 만든다

다음: 3편 영어가 아니라 기술 영어다 ➡