#acl +All:read

AOSA Series

= AOSA Vol 1. Preface =

목공은 까다로운 기술이며, 사람들은 목공을 잘하는 방법을 배우기 위해 평생을 보낼 수 있습니다. 하지만 목공은 건축이 아닙니다. 피치 보드와 연귀 이음에서 한 발짝 물러나면 건물 전체를 설계해야 하며, 이를 수행하는 것은 공예나 과학만큼이나 예술입니다. ~-Carpentry is an exacting craft, and people can spend their entire lives learning how to do it well. But carpentry is not architecture: if we step back from pitch boards and miter joints, buildings as a whole must be designed, and doing that is as much an art as it is a craft or science.-~

프로그래밍 또한 까다로운 기술이며, 사람들은 평생 동안 프로그래밍을 잘하는 방법을 배우는 데 시간을 할애할 수 있습니다. 하지만 프로그래밍은 소프트웨어 아키텍처가 아닙니다. 많은 프로그래머는 더 큰 설계 문제에 대해 수년간 고민하거나 씨름합니다: 이 애플리케이션을 확장할 수 있어야 하는가? 그렇다면 스크립팅 인터페이스를 제공해야 하는가, 플러그인 메커니즘을 통해 해야 하는가, 아니면 완전히 다른 방식으로 해야 하는가? 클라이언트가 해야 할 일은 무엇이고, 서버에 맡겨야 할 일은 무엇이며, '클라이언트-서버'가 이 애플리케이션에 대해 생각할 때 유용한 방법일까요? 이는 계단을 어디에 놓을 것인지가 목공의 문제인 것처럼 프로그래밍에 관한 질문이 아닙니다. ~-Programming is also an exacting craft, and people can spend their entire lives learning how to do it well. But programming is not software architecture. Many programmers spend years thinking about (or wrestling with) larger design issues: Should this application be extensible? If so, should that be done by providing a scripting interface, through some sort of plugin mechanism, or in some other way entirely? What should be done by the client, what should be left to the server, and is "client-server" even a useful way to think about this application? These are not programming questions, any more than where to put the stairs is a question of carpentry.-~

건물 건축과 소프트웨어 아키텍처는 공통점이 많지만 한 가지 중요한 차이점이 있습니다. 건축가는 교육 과정과 커리어를 통해 수천 개의 건물을 연구하는 반면, 대부분의 소프트웨어 개발자는 소수의 대형 프로그램만 잘 알 수 있습니다. 그리고 그 대부분은 자신이 직접 작성한 프로그램인 경우가 많습니다. 그들은 역사상 위대한 프로그램을 보거나 숙련된 실무자가 작성한 프로그램 설계에 대한 비평을 읽을 기회도 없습니다. 그 결과, 그들은 서로의 성공을 기반으로 구축하기보다는 서로의 실수를 반복합니다. ~-Building architecture and software architecture have a lot in common, but there is one crucial difference. While architects study thousands of buildings in their training and during their careers, most software developers only ever get to know a handful of large programs well. And more often than not, those are programs they wrote themselves. They never get to see the great programs of history, or read critiques of those programs' designs written by experienced practitioners. As a result, they repeat one another's mistakes rather than building on one another's successes.-~

이 책은 이를 바꾸기 위한 시도입니다. 각 장에서는 오픈 소스 애플리케이션의 구조, 각 부분의 상호 작용 방식, 그렇게 만들어진 이유, 다른 큰 디자인 문제에 적용할 수 있는 교훈 등 오픈 소스 애플리케이션의 아키텍처에 대해 설명합니다. 이러한 설명은 소프트웨어를 가장 잘 아는 사람들, 즉 복잡한 애플리케이션을 설계하고 재설계한 경험이 수년 또는 수십 년 있는 사람들이 작성합니다. 애플리케이션은 간단한 그리기 프로그램과 웹 기반 스프레드시트부터 컴파일러 툴킷과 수백만 줄의 시각화 패키지에 이르기까지 그 규모가 다양합니다. 출시된 지 몇 년 되지 않은 애플리케이션도 있고, 30주년을 맞이하는 애플리케이션도 있습니다. 이 모든 것의 공통점은 제작자가 디자인에 대해 오랫동안 열심히 고민했고, 그 생각을 여러분과 기꺼이 공유한다는 것입니다. 여러분도 이들의 작품을 즐겨보시기 바랍니다. ~-This book is our attempt to change that. Each chapter describes the architecture of an open source application: how it is structured, how its parts interact, why it's built that way, and what lessons have been learned that can be applied to other big design problems. The descriptions are written by the people who know the software best, people with years or decades of experience designing and re-designing complex applications. The applications themselves range in scale from simple drawing programs and web-based spreadsheets to compiler toolkits and multi-million line visualization packages. Some are only a few years old, while others are approaching their thirtieth anniversary. What they have in common is that their creators have thought long and hard about their design, and are willing to share those thoughts with you. We hope you enjoy what they have written.-~

= AOSA Vol 2. Preface =

이 시리즈의 1권 서문에서 다음과 같이 썼습니다: ~-In the introduction to Volume 1 of this series, we wrote:-~

    건물 건축과 소프트웨어 아키텍처는 공통점이 많지만 한 가지 중요한 차이점이 있습니다. 건축가는 교육 과정과 커리어를 통해 수천 개의 건물을 연구하는 반면, 대부분의 소프트웨어 개발자는 소수의 대형 프로그램만 잘 알게 됩니다... 그 결과 서로의 성공을 기반으로 구축하기보다는 서로의 실수를 반복합니다... 이 책은 이를 바꾸기 위한 시도입니다. ~-Building architecture and software architecture have a lot in common, but there is one crucial difference. While architects study thousands of buildings in their training and during their careers, most software developers only ever get to know a handful of large programs well… As a result, they repeat one another's mistakes rather than building on one another's successes… This book is our attempt to change that.-~

이 책이 나온 후 1년 동안 이십여 명의 사람들이 여러분이 손에 들고 있는 속편을 만들기 위해 열심히 노력했습니다. 그들은 우리와 마찬가지로 소프트웨어 디자인은 모범을 통해 배울 수 있고 또 배워야 하며, 전문가처럼 생각하는 방법을 배우는 가장 좋은 방법은 전문가가 생각하는 방법을 연구하는 것이라고 믿기 때문에 그렇게 해왔습니다. 웹 서버와 컴파일러부터 건강 기록 관리 시스템, Mozilla가 Firefox를 출시하는 데 사용하는 인프라에 이르기까지, 우리 주변 곳곳에 교훈이 있습니다. 이 책에 그 중 일부를 모아서 더 나은 개발자가 되는 데 도움이 되기를 바랍니다. ~-In the year since that book appeared, over two dozen people have worked hard to create the sequel you have in your hands. They have done so because they believe, as we do, that software design can and should be taught by example—that the best way to learn how think like an expert is to study how experts think. From web servers and compilers through health record management systems to the infrastructure that Mozilla uses to get Firefox out the door, there are lessons all around us. We hope that by collecting some of them together in this book, we can help you become a better developer.-~

= The Performance of Open Source Software Introduction. Preface =

컴퓨터 하드웨어가 너무 빨라져서 대부분의 개발자는 성능에 대해 걱정할 필요가 없다고 말하는 것이 일반적입니다. 실제로 더글러스 크록포드는 이러한 이유로 이 책의 챕터 집필을 고사했습니다: ~-It’s commonplace to say that computer hardware is now so fast that most developers don’t have to worry about performance. In fact, Douglas Crockford declined to write a chapter for this book for that reason:-~

    만약 제가 챕터를 쓴다면 성능 추구에 쏟는 대부분의 노력은 낭비라는 반성능에 관한 내용이 될 것입니다. 여러분이 찾고 있는 것은 그런 것이 아니라고 생각합니다. ~-If I were to write a chapter, it would be about anti-performance: most effort spent in pursuit of performance is wasted. I don’t think that is what you are looking for.-~

도널드 크누스도 30년 전에 같은 지적을 했습니다: ~-Donald Knuth made the same point thirty years ago:-~

    작은 효율성은 잊어버려야 한다, 즉 97% 정도는 조기 최적화가 만악의 근원이라는 것입니다. ~-We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.--~

그러나 전력과 메모리가 제한된 모바일 장치와 테라바이트 단위의 데이터를 처리해야 하는 데이터 분석 프로젝트 사이에서 점점 더 많은 개발자가 코드를 더 빠르게 만들고, 데이터 구조를 더 작게 만들고, 응답 시간을 더 짧게 만들어야 합니다. 그러나 수백 권의 교과서가 운영 체제, 네트워크, 컴퓨터 그래픽, 데이터베이스의 기본 사항을 설명하지만, 실제 애플리케이션에서 너무 느린 문제를 찾아서 수정하는 방법을 설명하는 책은 거의 없습니다. ~-but between mobile devices with limited power and memory, and data analysis projects that need to process terabytes, a growing number of developers do need to make their code faster, their data structures smaller, and their response times shorter. However, while hundreds of textbooks explain the basics of operating systems, networks, computer graphics, and databases, few (if any) explain how to find and fix things in real applications that are simply too damn slow.-~

이 사례 연구 모음은 이러한 격차를 메우기 위한 시도입니다. 각 장은 기존 시스템을 더 빠르게 만들어야 했거나 처음부터 빠르게 설계해야 했던 실제 개발자가 작성했습니다. 다양한 종류의 소프트웨어와 성능 목표를 다루고 있지만, 공통점은 실제로 어떤 일이 언제 일어나는지, 대규모 애플리케이션의 여러 부분이 어떻게 서로 맞물려 있는지에 대한 상세한 이해가 있다는 것입니다. 이 책이 전작인 '오픈 소스 애플리케이션의 아키텍처'와 마찬가지로 전문가들의 어깨 너머로 더 나은 개발자가 되는 데 도움이 되기를 바랍니다. ~-This collection of case studies is our attempt to fill that gap. Each chapter is written by real developers who have had to make an existing system faster or who had to design something to be fast in the first place. They cover many different kinds of software and performance goals; what they have in common is a detailed understanding of what actually happens when, and how the different parts of large applications fit together. Our hope is that this book will—like its predecessor The Architecture of Open Source Applications—help you become a better developer by letting you look over these experts’ shoulders.-~

= 500 Lines or Less. Preface =

이 책은 오픈 소스 애플리케이션의 아키텍처 시리즈의 네 번째 책으로, 제목에 '오픈 소스 애플리케이션'이라는 단어가 없는 첫 번째 책입니다. ~-This is the fourth volume in the Architecture of Open Source Applications series, and the first to not feature the words "open source applications" anywhere in the title.-~

이 시리즈의 첫 세 권은 대형 프로그램이 해결해야 하는 큰 문제를 다루었습니다. 경력 초기의 엔지니어에게는 수천 줄의 코드보다 훨씬 큰 프로그램을 이해하고 이를 기반으로 구축하는 것이 어려울 수 있으므로 큰 문제는 흥미롭게 읽을 수 있지만 배우기도 어려울 수 있습니다. ~-The first three volumes in the series were about big problems that big programs have to solve. For an engineer who is early in their career, it may be a challenge to understand and build upon programs that are much bigger than a few thousand lines of code, so, while big problems can be interesting to read about, they can also be challenging to learn from.-~

'500줄 이하'는 프로그래머가 새로운 것을 만들 때 작은 단위에서 내리는 설계 결정에 초점을 맞춥니다. 이 책에서 읽게 될 프로그램은 모두 이러한 목적으로 처음부터 작성되었습니다(일부 프로그램은 저자가 이전에 작업했던 대규모 프로젝트에서 영감을 얻었지만). ~-500 Lines or Less focuses on the design decisions that programmers make in the small when they are building something new. The programs you will read about in this book were all written from scratch for this purpose (although several of them were inspired by larger projects that the authors had worked on previously).-~

각 장을 읽기 전에 먼저 문제를 어떻게 해결할 수 있을지 생각해 보시기 바랍니다. 저자가 중요하게 고려할 디자인 고려 사항이나 제약 조건은 무엇이라고 생각하시나요? 어떤 추상화를 기대하시나요? 문제가 어떻게 분해될 것이라고 생각하시나요? 그런 다음, 챕터를 읽으면서 무엇이 놀라웠는지 파악해 보세요. 단순히 각 장을 처음부터 끝까지 읽는 것보다 이렇게 함으로써 더 많은 것을 배울 수 있기를 바랍니다. ~-Before reading each chapter, we encourage you to first think about how you might solve the problem. What design considerations or constraints do you think the author is going to consider important? What abstractions do you expect to see? How do you think the problem is going to be decomposed? Then, when reading the chapter, try to identify what surprised you. It is our hope that you will learn more by doing this than by simply reading through each chapter from beginning to end.-~

500줄 미만의 소스 코드로 유용한 프로그램을 작성하는 것은 그 자체로도 어려운 일이지만, 인쇄된 책에 깔끔하게 렌더링되어 교육용으로 읽힐 수 있도록 작성하는 것은 훨씬 더 어렵습니다. 따라서 편집자들은 때때로 소스를 책으로 옮길 때 일부 소스 서식을 자유롭게 변경했습니다. 각 장의 원본 소스는 해당 프로젝트 폴더의 코드 하위 디렉터리에서 찾을 수 있습니다. ~-Writing a useful program in fewer than 500 lines of source code---without resorting to cheap tricks---is a challenging exercise in itself; writing one to be read for pedagogical purposes when neatly rendered in a printed book is even tougher. As such, the editors have occasionally taken liberties with some of the source formatting when porting it into the book. The original source for each chapter can be found in the code subdirectory of its project folder.-~

이 책에 담긴 저자들의 경험이 여러분의 프로그래밍 실력이 한 단계 성장하는 데 도움이 되기를 바랍니다. ~-We hope that the experiences of the authors in this book will help you grow out of your comfort zone in your own programming practice.-~