데이터 중심 애플리케이션 설계(DDIA) 6쇄 개인적인 번역 정오표

- 최근 업데이트 : 2026-06-02

지속적으로 업데이트중 입니다.

* 2026-06-02 기준 3장 읽는중이며, 읽는 속도가 빠르지 않습니다. 책을 모두 읽고 개인 번역 정오표가 어느 정도 정리되면 이 안내 문구는 삭제할 예정입니다.

---

 

  데이터 중심 애플리케이션 설계(이하 DDIA) 초반부를 읽고 있습니다. 내용 자체는 좋은 책이라고 느끼고 있습니다.

다만 읽는 중 일부 번역에서 원문의 뉘앙스가 약해지거나, 문맥상 의미가 어색하게 읽히는 부분이 있어 개인적으로 정리해두려 합니다.

 

  이 글은 공식 정오표가 아니라, DDIA 한국어판 6쇄를 읽으며 개인적으로 발견한 번역상 아쉬운 부분을 원서와 대조해 정리한 글입니다. 1번처럼 실제 정오표에 추가 요청한 항목도 있고, 이후 읽으면서 추가 발견되는 내용이 있으면 계속 갱신할 예정입니다.

 

---

 

1. 17p 아래에서 11번째 줄

• 번역서 : 하지만 단일 노드에 상태 유지(stateful) 데이터 시스템을 분산 설치하는 일은 아주 많은 복잡도가 추가적으로 발생한다.
• 원문 : taking stateful data systems from a single node to a distributed setup …

 

  이 문장은 from a single node to a distributed setup 구조이므로, “단일 노드에” 상태 유지 데이터 시스템을 분산 설치한다는 의미가 아니라, “단일 노드의 상태 유지 데이터 시스템을” 분산 구성으로 옮기는 의미에 가깝습니다.

 

  해당 내용은 뉘앙스 차이라기 보단 오류에 가깝다고 생각하여 정오표 추가 요청드렸고, 현재 정오표에 반영된 것으로 보입니다.

 

  다만 정오표에는 5쇄 항목으로 들어가 있어 6쇄 구매자가 확인하기에는 다소 혼동될 수 있어 보입니다. 실제론 6쇄 정오표에 들어가야 하는 내용입니다.

 

 

 

2. 20p 아래에서 10번째줄

• 번역서 : 성능 문제 해결을 목표로 한 해킹
• 원문 : hacks aimed at solving performance problems

 

  여기서 hacks는 보안 침해나 공격 의미의 “해킹”이라기보다는, 성능 문제를 해결하기 위해 넣은 꼼수성 구현 또는 임시 우회책에 가깝다고 보입니다. "성능 문제를 해결하려고 넣은 임시방편" 정도가 자연스러울 것 같습니다. 한국어로 '해킹'이 일반적으로 보안 침해나 공격 쪽으로 먼저 읽히지 않나 생각됩니다.

 

 

3. 75p 아래에서 7번째줄

• 번역서 : 이런 유형의 작업 부하에서는 쓰기가 아주 많지만 고유 키는 많지 않다. 즉, 키 당 쓰기 수가 많지만 메모리에 모든 키를 보관할 수 있다.
• 원문 : In this kind of workload, there are a lot of writes, but there are not too many distinct keys—you have a large number of writes per key, but it’s feasible to keep all keys in memory.

 

  원문 뉘앙스가 좀 사라진 느낌입니다. 원문은 "고유 키 수가 너무 많지는 않아서, 모든 키를 메모리에 보관하는 것이 현실적으로 가능하다"는 조건부 뉘앙스가 있습니다. 반면 번역문은 단정적으로 읽힙니다.

  전체적으로 이정도가 자연스러워 보입니다. "이런 유형의 작업 부하에서는 쓰기 수는 많지만, 서로 다른 키의 수는 메모리에 올릴 수 없을 만큼 많지는 않다. 즉, 키마다 많은 쓰기가 발생하지만 전체 키 집합은 메모리에 보관할 수 있는 수준이다."

 

 

4. 77p '파일 형식' 내용

• 번역서 : 바이트 단위의 문자열 길이를 부호화한 다음 원시 문자열(이스케이핑할 필요 없이)을 부호화하는 바이너리 형식을 사용하는 편이 더 빠르고 간단하다.
• 원문 : It’s faster and simpler to use a binary format that first encodes the length of a string in bytes, followed by the raw string (without need for escaping)

 

  번역문에서는 “부호화”가 두 번 나오면서, 문자열 길이와 원시 문자열을 각각 별도로 부호화한다는 느낌이 강하게 듭니다. 원문의 핵심은 길이를 먼저 기록하고, 그 뒤에 원본 문자열 바이트를 그대로 둔다는 것입니다. 이정도가 자연스러워 보입니다. "문자열의 바이트 길이를 먼저 기록하고, 이어서 문자열 원본을 그대로 저장하는 바이너리 형식을 사용하는 편이 더 빠르고 단순하다. 이 방식에서는 이스케이프 처리가 필요 없다."

 

 

5. 93p 2번째줄

• 번역서 : 초창기 비즈니스 데이터 처리는 데이터베이스 쓰기가 보통 판매, 공급 업체에 발주, 직원 급여 지불 등과 같은 커머셜 트랜잭션(상거래)에 해당했다.
• 원문 : In the early days of business data processing, a write to the database typically corre sponded to a commercial transaction taking place: making a sale, placing an order with a supplier, paying an employee’s salary, etc.

 

  'a write to the database'를 '데이터베이스 쓰기' 라고 옮긴 부분이 한국어 문장으로는 다소 어색하게 읽힙니다. "초창기 비즈니스 데이터 처리 시스템은 주로 판매, 공급업체 발주, 급여 지급처럼 실제로 발생한 상업적 거래를 데이터베이스에 기록하는 데 사용됐다" 정도가 자연스러워 보입니다.

 

 

 

... 책 읽으면서 계속 추가중 (읽는 속도 느림)