[끝없는 뽐뿌질] 맥북 에어 13인치

한동안 컴퓨터를 비롯한 전자기기에 일절 관심을 끊고 살다가(뽐뿌질 안 당하겠다 이거지. ㅋㅋ), 어떻게 되어 한시적으로 맥북 에어 13인치랑 맥 미니를 사용하게 되었다. 그래서 오늘은 맥북 에어 13인치부터 뽐뿌질을 해보자.

어떤 물건을 손에 넣었냐 하면... 화면 해상도 때문에 13형을, 가격 대비 성능을 맞추기 위해 128GB 플래시를 장착한 모델이다. 11인치와 13인치를 두고 잠시 고민했는데 제품 사양을 보면 알겠지만 13형이 11형보다 가로 2.5cm, 세로 3.5cm 정도밖에 차이가 안 난다. 그래서 넷북을 조금 써본 경험에 따라 세로 해상도가 768이 아닌 900인 13인치의 손을 들어줬다. 세로 해상도가 768인 경우 문서 작업을 하거나 웹 브라우징을 할 때 스크롤이 많아지므로 아무래도 패드나 마우스에 손이 많이 가기 마련이다. 참고로 맥북 프로 13인치 해상도가 1280x800이므로 1440x900인 맥북 에어는 정말 운동장이라는 느낌이 들테다. ㅋㅋ

부팅 속력은 15~20초 안에 끝나고(IBM 씽크패드 잠든 상태에서 깨어나는 시간보다 빠르다 T_T), Core i5와 SSD를 탑재한 관계로 코어2듀오를 탑재한 맥북 프로 15인치보다 응용 프로그램 시동 속력이 훨씬 개선되었다는 느낌이 팍팍 온다. 가상화 소프트웨어를 돌려도 전혀 무리가 없이 쌩쌩 날아다닌다. 크기가 작고 무게가 적게 나가므로 배터리가 조금 걱정될 가능성이 있는데, 제품 사양에 따르면 7시간(실제로는 4시간 정도 사용이 가능해보인다)이므로 어댑터 없이 컴퓨터 본체만 바깥에 들고 나가서 작업해도 될 것 같다. 키보드 백라이트 기능이 추가되어 있기에 키보드 배열을 달달 다 외우는 B급 프로그래머에게는 해당되지 않지만 어두운 곳에서도 불편없이 쓸 수 있다(물론 전원 절약을 위해 밝기를 줄녀 놓길 권한다). USB 단자는 2개로 각각 좌측과 우측에 있는데, 좌측에 있는 USB가 Mag Safe 전원 단자랑 가까워서 간섭이 조금 일어나긴 한다. 13형은 오른쪽에 SD 카드 슬롯이 있으므로 디지털 카메라 애호가들에게 끌릴 것으로 보인다.

자, 그러면 맥북 에어 13인치를 사용하면서 잠시 B급 프로그래머도 햇갈린 두 가지 사실을 짚고 넘어가자. 먼저 어댑터 이야기를 해보자. 수중에 맥북 13인치(가장 초기 모델), 맥북 프로 15인치(코어2듀오), 맥북 에어 13인치가 있는데, 그러다보니 어댑터가 3개다! 신형 L타입 45W(맥북 에어 13인치), T타입 60W(맥북 13인치), T타입 85W(맥북 프로 15인치)이 뒹굴고 있는데 어떤 컴퓨터에 어떤 어댑터를 쓸 수 있는지 잠시 고민했다(자주 가는 장소에 어댑터를 각각 두면 아주 편리하기 때문이다). W, V, A가 모두 다르므로, 잘못 연결하면 고장이 날 가능성이 높아서 Intel 기반 Apple 휴대용 컴퓨터 전원 확인을 찾아보니, 필요한 용량보다 높은 W 어댑터를 연결하면 문제가 없고, 낮은 어댑터를 연결하면 문제가 생기는 듯이 보인다. 실제로 45W 어댑터 대신 85W 어댑터를 맥북 에어에 연결하니 문제 없이 충전되었다(실험으로 입증하는 이 용감함. ㅋㅋ). 시스템 정보에 들어가면 어떤 어댑터가 장착되어있는지 나오므로, 시스템 펌웨어 레벨에서 어댑터를 인식하고 상호 협상 과정을 거치는 듯이 보인다(그래서 전원이 남아돌면 천천히 달라고 요청하고 전원이 부족하면 배터리 충전 회로를 꺼버리는 듯이 보인다). 혹시 맥북 시리즈를 혼합해서 사용하시는 분이라면 혹시 추가 어댑터를 구매할 경우 용량이 큰 85W를 사기 바란다(실제로 프리스비 등에서도 85W만 잔뜩 갖다 놓았다. 혹시 잘못 구입해 문제가 생길 경우 일어나는 민원을 피할 수 있기 때문이 아닐까 싶다.) 아, 그리고 실험 결과 T형과 L형은 상호 호환이 가능하다(초기에는 L형을 요구(?)하는 노트북들이 T형을 연결하면 인식 못하는 문제가 있었다고 하는데 EFI 펌웨어 업데이트로 해소했다는 이야기를 들었다. 실제로 맥북 에어 13형에 T형 85W를 연결해보니 인식 잘 하고 충전 잘 되었다.)

다음으로 외부 디스플레이 어댑터 이야기를 좀 해야겠다. 알다시피 요즘 애플은 USB 3.0 대신 썬더볼트를 밀고 있다. 맥북 에어도 썬더볼트 단자가 있는데, 기존 맥북 프로에서 사용하던 미니 디스플레이 단자가 없는 듯이 보였다. 따라서 외부 디스플레이랑 연결하기 위해 썬더볼트2VGA 연결 장치를 별도로 구입해야 하지 않을까 생각하고 맥 스토어를 뒤졌지만 안 나온다. T_T 그래서 가만히 맥북 에어 액서서리 추가 구매 항목을 보니 놀랍게도 미니 디스플레이 어댑터가 들어있었다. 투철한 실험 정신을 발휘해 맥북 프로용 미니 디스플레이2VGA를 꽃아서 외부 모니터에 연결하니 잘 동작한다. 혹시나 맥북 에어 구매하면서 외부 디스플레이를 고민하신 분들이라면 참고하시기 바란다. ㅋㅋ(아 이 뽐뿌질).

결론: 비용만 제외하고 생각하면 1st 노트북으로 맥북 에어를 강력하게 추천한다. $을 제외한 무게/성능/디자인 모든 면에서 무척 만족스럽다.

EOB

[독서광] MongoDB 완벽 가이드

오늘은 클라우드 컴퓨팅라는 용어가 인구에 회자되면서 NoSQL에 대한 이야기에 사람들이 관심이 많은 듯이 보인다. 오늘은 NoSQL의 진수(?)라고 책 표지에 적힌 MongoDB 완벽 가이드라는 책을 읽은 소감을 정리해보겠다. 요즘 기억력이 부쩍 감퇴하고 있기에 읽은 즉시 정리해야 휘발되지 않으므로 서둘러본다.

NoSQL(not only SQL)이라는 말을 많이 하는데, 위키피디아 정의에 따르면 다음과 같은 상당히 포괄적인 의미가 함축되어 있다.

몇 가지 측면에서 전통적인 데이터베이스 관리 시스템인 RDBMS과 다른 데이터베이스 관리 시스템의 넓은 클래스 자료는 고정된 테이블 스크마를 요구하지 않으며, 일반적으로 join 연산을 피하고, 수평 확장이 가능하다.

RDBMS와 차별화 포인트를 가져가면 나쁜 점과 좋은 점이 생기게 되는데, 지속적인 손해는 일시적인 손실로 처리하고 일시적인 이익은 반복적인 매출로 잡는 엔론의 분식 회계처럼 NoSQL의 장점은 극대화하고 단점은 이야기하지 않는 방법으로 거의 모든 문제점을 해결하는 만병 통치약에 은총알로 승격시키려는 움직임도 눈에 보인다. 하지만 AWS SimpleDB를 살펴보고 이 책도 읽고나서 든 느낌이지만, NoSQL은 절대로 만병 통치약이 아니며, 용도에 맞춰 제대로 사용해야 장점을 얻을 수 있기에 일반적인 상황에서는 MySQL/PostgreSQL과 같은 RDBMS가 월등이 유리하지 않을까 싶다(뭐 이건 어디까지나 B급 프로그래머 머리 속 생각일 뿐이고 절대로 남에게 이래라 저래라 _강요_하지 않는다. NoSQL 계열 데이터베이스를 쓰실 분은 얼마든지 능력껏 상황껏 마음껏 쓰시라. 뭐, B급 프로그래머도 AWS SimpleDB를 용도에 맞춰 재미있게 쓸테니... 다 같이 잘 살아보세~~~). 여러 전자 상거래와 SNS 회사에서 NoSQL을 사용한다고 하지만, 간도 크게 모든 서비스에 다 적용하지는 못하며 아직까지는 핵심 기능이 아닌 기능에 시범적으로 적용하는 경우가 많다는 생각이다. 물론 처음부터 NoSQL로 다 구축했다고 말하는 대규모 서비스도 존재하겠지만, 그 서비스가 바로 당신이 만들려고 하는 서비스가 아닌 이상 적용 범위와 효과는 '그 때 그 때 달라요'다.

NoSQL에 대한 이야기만 잔뜩 늘어놓았는데 본론으로 들어가보면, MongoDB 완벽 가이드는 '완벽'은 아니지만 처음 MongoDB를 사용하는 사람들에게 힌트를 줄만한 책이다. 그런데 처음 MongoDB를 사용하는 사람이지 처음 컴퓨터 프로그래밍에 입문하는 사람을 위한 친절한 안내서는 절대로 아니다. 이 책을 읽으려면 자바스크립트 언어에 익숙해야 하며(그냥 copy&paste 수준으로는 안 된다), 데이터베이스 기본 이론에 대해 확실하게 알고 있어야 한다. 그렇지 않으면 얇은 페이지임에도 불구하고 읽는 과정에서 조금 애를 먹게 된다. 내용은 MongoDB 셸을 사용한 문서 생성/갱신/삭제/질의/색인 방법, 집계(맵리듀스도 일부 나온다), 고급 기능(제목과는 달리 그리 깊은 내용은 없다), 시스템 관리와 모니터링, 복제/레플리카와 샤딩 등이며, 책 끝 부분에는 자바, PHP, 루비, 파이썬을 사용한 예제 애플리케이션 작성 기법도 나오긴 하는데 20페이지 분량이므로 크게 건질 내용은 없다. 전반적으로 심도 깊은 내부 구조나 철학을 다루기보다는 소개 중심으로 가고 있으므로 MongoDB를 이용한 응용 프로그램 개발자를 표적으로 한다고 보면 되겠다.

MongoDB는 자바스크립트 엔진을 탑재한 셸과, SQL과는 전혀 닮지 않은 질의 방식으로 인해 전통적인 RDBMS 사용자라면 조금 과격하다는 느낌이 들지도 모르겠다. AWS SimpleDB만 하더라도 연산자 형태는 단순 key - value 저장, 질의 형태는 SQL과 유사한 질의어를 사용하지만 MongoDB는 기존의 관습을 무시하고 독자적인 세상을 구축해 놓았으므로(궁금하신 독자분들께서는 SQL to Mongo Mapping Chart를 보시라. 말이 Mapping Chart지... T_T) 학습 과정에 애로 사항이 꽃필 가능성이 높다. 각종 프로그래밍 언어 라이브러리를 사용하더라도 독특한 활용법에 맞춰야 하는 관계상 그리 쉬워보이지는 않는다. RDBMS만 보다가 객체 지향형 데이터베이스를 보는 느낌이라고 설명하면 조금 이해가 갈지도 모르겠다. 지금까지 겁을 좀 줬지만, NoSQL 자체가 기존 RDBMS의 복잡도를 줄이려는 목표로 시작되었기 때문에 책을 읽다보면 전반적인 기능과 한계점이 눈에 보일 것이다.

다른 부분은 다 차치하고서라도 복제/레플리카, 샤딩에 눈이 번쩍 뜨이는 분들도 많으시리라. 클라우드에서 이 단어들은 솔직히 큰 관심을 불러일으키는 주요 논쟁 거리기 때문이다. 그런데, 여전히 문제점은 남아 있다. 복제/레플리카 과정에서 일어나는 성능 저하, 타임 랙(lag)은 피할 수 없어 보이며, 샤딩 과정에서 사용자가 머리를 써서 샤딩 기준을 마련해야 한다는 사실은 변치 않고 있다. 자동 샤딩에 대한 이야기도 아아주우 조금 나와있는데, _자동_이라는 말을 100% 믿을 수 있을지는 각자 판단에 맡긴다.

EOB

[일상다반사] 정전사태와 매뉴얼

이번에 전국적인(이라고 쓰고 후진국형이라고 읽는) 정전 사태 때문에 누구 잘못이냐 책임이냐 시끌벅적한 상황이다. 그 중에서 매뉴얼과 관련해 여러 가지 의견을 나열해보면 다음과 같다.

• 매뉴얼을 따르지 않아 문제가 생겼다.
• 매뉴얼이 낡아 현실을 반영하지 않았기에 따를 수가 없었다.
• 매뉴얼도 나오지 않는 비상 상황이 발생했다. 그래서 임의로 조치를 취했다.
• (이건 B급 관리자 생각) 평상시 매뉴얼대로 연습을 하지 않거나 매뉴얼을 무시했다.

매뉴얼을 제대로 만들고 제대로 따르면 모든 문제가 다 해결될 듯이 언론에서 연일 집중 포화를 때리는데, 정말 그럴까? 천만의 말씀. 아니라고 생각한다. Managing the Unexpected에도 이미 설명을 했지만, 다시 한번 서평에 적었던 내용을 옮겨본다.

정신 바짝 차려 행동하는 조직은 예기치 못한 사건을 초기에 찾아내 재앙으로 번지기 전에 문제를 이해하고 적극 대응한다. 반면 일반적인 조직은 규칙과 위기 계획에 맞춰 사건을 미리 구체화하므로 예기치 못한 사건이 벌어질 경우 이를 기존 틀에 끼워맞추려고 할 뿐 새롭게 배우고 분류하려고 애쓰지 않는다.

만일 매뉴얼 자체가 그야말로 바늘 하나도 들어가지 못할 정도로 꼼꼼하고 완벽하다면 규칙과 위기 계획에 맞춰 사건을 미리 구체화한 셈이 된다. 그러면 사건을 선험적으로 예측할 수 있다는 말인데, 미래를 예측했으니 미리 손을 썼을테고 그 결과... 사건이 발생하지 않아야 정상이다. 하지만 블랙 스완 이론에 따르면 세상 일이 이렇게 정규 분포를 그리며 선형적으로 예측에 맞춰 돌아가지는 않는 듯이 보인다. 결국 이번 정전 사태를 보면 매뉴얼이 아무리 잘 만들어져 있고 여기 맞춰 기계적으로 대응을 했다고 하더라도 문제가 생길 여지가 있다는 말이고, 결국 유연하게 대응하는 주체인 _사람_이 아주 중요하다는 결론을 내릴 수 있다. 자 여기서 궁금한 점. 지경부, 한전, 전력 거래소 등 이번 사태에 책임이 있는 각종 정부/공기관에 낙하산 내려보낸 사람은 누굴까? 해당 분야의 전문 지식이 아니라 지위와 나이로 문제를 풀려고 하니 애당초부터 문제의 소지가 있었다.

여기까지 적고 나면 댓글이 뭐라고 달릴지 충분히 예측 가능하다(물론 과거의 경험에 따라). '그렇게 잘하면 너가 가서 한전 사장해라', '너가 전기 계통이 얼마나 복잡한지 알긴 아냐? 책 몇 권 읽고나서 아는 채 되게 하네', '너 빨간색이지?' 미리 예상 댓글을 달아드렸으니 엉뚱한 댓글을 다는 대신 이제 좀더 생산적인 시간을 보내보자. 전기도 그렇지만 컴퓨터를 사용해 서비스를 제공할 때 피크 타임에 대응하기 위한 문제를 하나 내고 넘어간다.

문제: AWS와 같은 클라우드 환경에서는 AutoScaling과 같은 기능을 제공해 정해진 조건에 따라 자동으로 EC2 인스턴스 개수를 늘이고 줄일 수 있게 되어 있다. 또한 CloudWatch를 사용할 경우 알람을 설정해 특정 조건을 충족하면(아래 그림 CPUUtilization 조건 설정 마법사 화면 참조) 자동으로 사용자에게 알려주거나 큐에 넣을 수 있다. 그렇다면 사용자가 많이 몰리는 피크 타임과 한가롭게 노는 타임을 확실히 구분해 서비스에 지장이 없는 동시에 비용을 최소로 줄이도록 만드는 일관된 조건 집합(예: CPU, HDD, 네트워크, I/O 등 정량적으로 측정 가능한 메트릭을 기준으로)을 찾아낼 수 있을까? 만일 찾아내기가 어렵다면 어떤 방법을 동원해야 할까? 다 함께 생각해보자.

EOB

[독서광] Middleware and Cloud Computing

지난번에 이어 오늘도 클라우드 컴퓨팅에 관련된 원서를 하나 소개하겠다. 부제가 'Oracle on Amazon Web Services and Rackspace Cloud'라고 길게 붙은 'Middleware and Cloud Computing'이라는 책이다. 부제를 보면 알겠지만, 이 책은 대표적인 IaaS형 클라우드 서비스인 AWS와 랙스페이스 위에서 오라클 관련 소프트웨어를 이용해 서비스를 제공하는 방법을 설명하고 있다. 지난번 소개했던 Programming Amazon EC2와 마찬가지로 이 책 역시 약파는 내용이 아니라 실전 위주로 되어 있기 때문에, 클라우드가 뭔지 궁금하신 분들이 펼쳤다가는 기절하므로 어느 정도 시스템 관리 경험이 있고 프로그램 작성이 가능한 개발자가 보기 바란다.

책 목차를 보면 크게 클라우드 컴퓨팅에 대한 소개 부분(이 부분은 건너뛰어도 무방해보인다), AWS에 대한 소개(AWS 서비스를 사용하기 위한 기본적인 절차와 방법이 나오므로 처음 AWS에 접하는 분들은 도움이 되겠다), 랙스페이스에 대한 소개(랙스페이스를 다루는 책이 그리 많지 않다는 사실에 주목하자), 오라클 퓨전 미들웨어 소개와 설정 방법(오라클에 관심이 없는 분들이라면 이 부분은 당연히 건너뛰자), 클라우드 설계 방법(일반적인 설계 지침을 소개한다), 클라우드 데이터베이스(AWS 상에서 RDS와 SimpleDB, 웹 로직 소개), 클라우드 관리(이 부분은 사실상 아아주 부실하므로 목차 정도가 도움이 되겠다. 라이트스케일 관리 도구 소개는 읽어볼만 하다), 가용성(웹 로직 중심으로 설명하므로 다소 불만스럽다. SQS에 대한 이야기도 그냥 스치고 지나간다), 규모 확장성(이 부분은 로드밸런싱, AWS Auto Scaling, CloudFront에 대한 기초적인 내용을 설명한다. HAProxy와 비교도 나오므로 개념을 잡기 위해 읽을만하다), 모니터링(이 부분은 웹 로직 관련 내용이 주를 이루며, AWS는 SNS 정도만 다룬다), 오라클 VM(이 부분은 뭐 사실상 없어도 되는 부분으로 보인다)으로 구성되어 있다. 개념적으로 AWS를 이해하는 분들이라면 정리를 위해 아마존에서 아마존 책 페이지에서 목차를 보면 도움이 되겠다.

본문에는 표를 사용해 여러 가지 내용을 일목요연하게 정리하고 있으며 그림을 덧붙인 완결된 예제와 명령행 유틸리티를 소개하고 기타 유용한 3rd party 프로그램을 소개하고 있으므로, 한국인 정서에 맞을 가능성이 상당히 높다. 당연한 말이지만, 이미 시간이 어느 정도 경과했기에 반드시 AWS나 랙스페이스 홈 페이지에 들어가서 내용을 교차 비교하고 3rd party 프로그램의 홈 페이지를 방문해 신형 버전을 확인해야 한다.

아, 이 책 내용은 일부가 PDF로 공개되어 있다. 클라우드 설계 방법과 클라우드 데이터베이스를 살펴보면 이 책 구성에 대해 감을 잡을 수 있을테다.

결론: 이 책은 크게 얻을만한 심도 깊은 내용은 없지만, 처음 AWS나 랙스페이스 환경에서 막 개발을 시작하려는 사람에게 기초서로 적합하다.

EOB

[독서광] 건축가처럼 생각하기

몇 차례에 걸쳐 블로그에서 페트로스키 큰 형님께서 지은 책과 사상을 소개한 적이 있었다. 종이 한 장의 차이를 보면 디자인에 대해 아주 흥미로운 이야기가 나오므로 디자인에 관심이 많은 애독자들분께서 좋아했으리라는 생각이 든다. 오늘은 기계 공학이 아니라 건축으로 넘어가 디자인을 한번 생각해보는 기회를 마련하려고 한다. 오늘 소개할 책은 아쉽게도 지난 5월에 돌아가신(고인의 명복을 빈다) 할 박스 교수가 '지은 건축가처럼 생각하기'다.

다들 충분히 알고 계시다시피, 전산쪽에서는 본질적으로 어려운 문제를 풀어내는 과정으로서 디자인에 대해 많은 관심을 기울여 왔다. 구조화 설계, 객체 지향 설계, 패턴, 안티 패턴, CBD(Component Based Design)과 같은 여러 가지 설계 프레임워크나 기법이 등장했고, 다양한 분야에서 디자인 기법을 차용하려 많은 공을 들여왔다. 예를 들어, 크리스토퍼 알렉산더가 집필한 'A Pattern Language'는 어찌된 판인지 한국에서는 건축 분야보다 전산 분야에서 더 널리 알려지는 흥미로운 광경을 연출하기도 했다. 하지만 막상 전산 쪽 사람들이 건축 쪽 설계에 대해 잘 아느냐? 본인부터 거울에 비춰보면 막상 그렇지도 않은 듯이 보인다(물론 일반화의 오류라고 생각하시는 분들도 계시겠지만, 'A Pattern Language'를 _제대로_ 읽어보신 분 있으면 댓글을 달아보시라. 커피 한 잔 사드린다.) 어찌되었거나... 건축 대가들이 설계를 바라보는 관점이 어떤지 무척 궁금하던 차에 서점 가판을 뒤지다 이 책을 발견했는데, 초대박이다.

이 책은 건축을 둘러싼 다양한 담론을 편지 형태로 다루기 때문에 복잡한 건축 이론이나 수식이 최소로 나온다. 이렇듯 책 내용이 쉬우면 부실하다는 인상을 주기 쉽지만 이 책은 자신이 직접 엄청난 규모의 건축물을 설계하고, 학생들을 가르치고, 자기가 살 집을 지은 경험을 토대로 주제를 뽑고 있으므로 그냥 책상에 앉아 대충 끄적인 책과는 수준부터 다르다. 전반적으로 다루는 주제나 전개 방식이 아주 훌륭하다고 느껴지지만, 특히 책 제목과도 똑같은 8장 '건축가처럼 생각하기: 디자인 전개 과정', 9장 '그림과 모형, 연픽과 컴퓨터로 표현해보기: 시각화 과정', 13장 '디자인 의사 결정', 14장 '스타일, 취향, 디자인 이론' 이 4장은 한 페이지도 놓치기 싫을만큼 좋은 이야기가 많이 나온다. 중간 중간에 크리스토퍼 알렉산더에 대한 일화도 나오고('A Pattern Language'가 나왔을 때, 학생들이 읽으면 안 될 금서로 지정하자는 교수도 있었다고 한다. ㅋㅋ), 모더니즘이 오히려 편안하고 친숙한 공간을 만드는 과정에 방해가 되는 설명도 나오고, 미국의 주간 고속도로가 설립되면서 도시 구조가 지극히 돈만 밝히는 형태로 짜여진 이유도 나오고(미국에서 렌트해 실컷 운전하면서 도심, 주거지, 상업지구가 확실하게 구분되는 이유를 몰랐는데, 이제야 감을 잡았다. T_T), (무엇보다) 소프트웨어 뿐만 아니라 건축 과정에서도 계속 설계가 바뀐다는(이 때문에 여분의 자금을 모아놓아야 한다고 조언한다) 상당히 충격적인 이야기도 나오므로 건축에 대한 오해가 아아주 조금이라도 풀린 느낌이다.

본문에 좋은 이야기가 많이 나오므로 오늘은 8장에서 선별한 내용 중에 다시 선별해 정리해보았다. 책을 그대로 다 옮기고 싶지만 꾹 참아본다.

디자인은 정보와 영감과 솜씨 있는 해결 방안과 표현의 수단을 찾기 위한 직접적이고 논리적인 탐구 과정입니다. 창조적인 문제 해결 방안이 예술이 된 것이라 생각할 수도 있습니다. 기능을 담고, 기능을 특징으로 하는 예술 말이입니다.

예산은 프로젝트의 가장 중요한 현실입니다. 예산이 상황을 좌우합니다. 모든 것이 기준이 됩니다.

목표나 재료에 변동이 생기면 예산도 바뀌어야 합니다.

디자인 전개 과정 중에, 새로운 요인들이 발견되고, 우선 순위가 바뀌면서 계획이 재조정되는 경우가 다반사입니다.

건축 디자인이 복잡한 이유는 언제나 너무도 많은 변수들이 경합을 벌이고 있기 때문입니다.

가장 좋은 해결 방안은 문제 해결 과정을 시각화하는 것이라고 할 수 있습니다.

이 모든 것들을 하나로 종합했다면, 머리 속에 커다란 솥을 걸고 찌개를 끓이는 일을 생각하세요. 잘 저어 가며 끓이다가 때때로 조금씩 떠서 맛을 봐야 하지요.

제가 그리는 양과 지우는 양은 거의 맞먹을 정도입니다.

철저한 조사로 준비하라. 별난 천재처럼 흩어짐 없이, 사로잡힌 듯, 열정적으로 집중하라. 꿈을 꾸고 행동하라. 소중하게 품어 왔던 생각을 내려놓고 새로운 아이디어를 구하라. 대지를 찾아가 보고 아이디어를 논하고 이전에 지어진 건축물을 평가하며 '번뜩이는 통찰력'을 찾아라. 효과적으로 일하라. 발전시킨 아이디어를 디자인에 적용해 문제를 해결하라. 스스로의 작업을 평가하라. 만일 만족스런 작품을 얻지 못했다면 다른 시각으로 네가 원하는 결과에 도달할 때까지 이 과정을 되풀이하라.

우리가 창조하려는 건축은 머릿속의 막연한 환상이 아닌 도면과 모델과 이미지로 표현되어야 합니다.

복합적인 것을 복잡한 것과 헷갈려서는 안 됩니다.

도면 작업이 끝났다고 해서 디자인까지 멈추는 것은 아닙니다.

설계를 하는 데는 개념을 파악하는 능력과 기본적인 지식, 이 두 가지가 모두 필요합니다.

디자인 전개 과정은 기능적인 문제와 건물 시스템, 미적인 문제 사이에서 전진과 후진을 반복하기 마련입니다. 이 때 일정하게 정해진 디자인 이론을 지침으로 삼으면 효과적으로 작업을 진행할 수 있습니다.

제가 아는 가장 훌륭한 디자인 원리는 뭔가를 '아주 적절하게' 만드는 일에 대해 끊임없이 생각하는 것입니다.

이 정도면 뽐뿌질은 충분했으리라 보고 나머지 좋은 이야기는 직접 본문을 확인하시길... 그러면, 애독자 여러분들께서 추석 연휴 모두 즐겁게 보내기를 기원한다.

EOB

[독서광] Programming Amazon EC2

오늘은 간만에 영어로 된 원서를 한번 소개해보자(요즘 계속해서 한국어판 책만 읽었더니 영어 독해 실력이 줄어드려고 해서...). 지난번 클라우드 컴퓨팅 구현 기술에 이어 오늘은 클라우드 컴퓨팅 환경의 대명사인 AWS 관련 책을 하나 소개하겠다.

Programming Amazon EC2는 아마존 웹 서비스에서 EC2를 중심으로 동작하는 응용 프로그램을 작성하는 방법을 설명하는 책이다. 이 책의 특징은 기존에 제공하고 있는 실제 서비스를 예로 들어 AWS에서 제공하는 기능을 활용하는 방법을 설명하는 데 있다. 따라서 장점과 단점이 극명하게 드러나는데, 기초가 부족한 초보자가 접근하기 아주 어려운 반면(아예 책 표지 뒷 장에 까놓고 '프로그래밍 경험을 권장한다'라고 적어놓았다), 어느 정도 클라우드 서비스 개념을 이해하고 있고 인터프리터 언어(루비, PHP)나 자바 코드 작성이 가능한 개발자라면 빠른 시간 내에 AWS를 맛볼 수 있다. 페이지가 얇기 때문에 특별한 내용이 없으리라 보면 오산이며, 있을 건 다 있다. 물론 전통적인 오라일리 서적 특성을 그대로 이어받아 코드나 설정 파일은 조각나 있고, 처음부터 끝까지 따라하기란 불가능한 방식으로 필요한 부분만 건너뛰며 설명을 진행한다. 이 책을 읽고서 EC2 인스턴스라도 하나 만들어보려면 최소한 리눅스 기반 시스템 관리에 발은 담궈봤어야 한다는 사실에 주목해야 한다(만일 이 책 독자가 시스템 관리자가 아니라면 실습이 제대로 잘 안 될 거다. ㅋㅋ).

목차를 보면 알겠지만, 처음에는 AWS 기본 개념에 대해 잠시 설명하는 듯 하다 바로 프로그램으로 들어간다. EC2와 S3를 설명한 다음에 바로 SQS, SimpleDB, SNS로 넘어가고, CloudWatch를 좀 보다가 클라우드 환경에서 가장 중요한 디커플링 된 시스템 예를 들면서 끝을 맺는다. AWS는 계속해서 서비스가 확장되며 라이브러리나 API가 추가되는 특성으로 인해 이 책을 읽고나서 바로 AWS 홈페이지를 방문해 문서를 찾는 편이 정신 건강에 이롭다고 힌트를 준다. 이 책은 흔히 클라우드에서 자주 입에 오르내리는 분산 파일 시스템이나 MapReduce에 대한 내용은 한 줄도 안 나오므로 빅 데이터에 관심이 많은 분이라면 미리 알아서 피해 가시라.

뱀다리: AWS는 가입 후 1년 동안 free tier를 제공하므로 대용량 서버를 여러 대 생성하거나 대규모 트래픽을 발생시키지 않는 이상 어느 정도 범위 내에서 실습이 가능하다. 단 해외 사용 신용카드 번호를 입력해야 실 사용자로 등록이 가능하므로 실수하지 않도록 정말 조심하기 바란다(개인 카드야 말할 나위 없고 심지어 한도액이 빵빵한 법인 카드가 꽃혀있더라도 나중에 시말서 안 쓰려면 AWS에서 제공하는 가격 조건표를 열심히 읽으며 인스턴스도 만들고 프로그램도 작성하고 테스트도 주의 깊게 하시라.). EOB