[11일차] - 완독 (이제부터는 부록입니다.)

그럼에도 중요한 것은 형식이나 표기가 아닙니다. 개발자가 활용할 수 있도록 하는 설계 형식이나 표기라는 것에 정답은 없습니다. 다만 같은 상태도라도 본인의 경험에 따라 그것을 응용하는 방식이 달라지는 것뿐입니다. 개발자와 더 많이 소통하고 여러 번 프로젝트를 진행할수록 그것은 더욱 분명해집니다. 중요한 것은 어떤 모델링 기법으로 어떤 설계도를 그리느냐가 아니라 소통이 가능하게 하는 것이죠. 간단한 표를 활용해서도 전달하고자 하는 바를 전할 수 있습니다.

[10일차] - 12p.

먼저 설계는 코딩을 대신 해 주지 않습니다. 두 번째로 기술적 가정을 검증하지 않고, 당장 개발을 위한 소 통에 쓰이지 않는 문서나 그림 형태로 설계하는 일은 지양해야 합니다. 그림을 그 리지 말라는 말이 아닙니다. 설계 결과물은 소통의 일부로, 함께 대화하는 맥락 (다른 말로 도메인이라고 함) 안에서만 힘을 갖는다는 말입니다.

[9일차]- 20p.

일단, 정원 관리와 프로그래밍의 연결은 생소할 수 있는데요. 이는 자신이 짠 코드를 다듬고 계속해서 잘 쓰이게 하는 일에 대한 은유 입니다. 정원 관리가 정원이 있는 집에 사는 대가로 치러야 하는 일상의 노력이듯 이 코드를 장기적으로 사용하려면 매번 기능을 추가하는 일과 별개의 노력을 들여 야 합니다. 개발자들은 이를 흔히 리팩터링이라고 부릅니다. 변수 이름을 성의껏 짓는 일처럼 작은 단위부터, 여러 곳에 흩어진 코드에 영향을 주는 구조적인 변경까지를 일컫는 말입니다.

[8일차 ] - 21p. (이제부터는 부록입니다.)

코드 정리를 토끼굴에 비유하여 시간을 낭비한다는 뉘앙스를 주는 것에 대해 주저되는데, 그걸 의도한 것이 맞나요? 비슷합니다. 사업하는 사람들은 동작 변경을 원합니다. 우리 프로그래머들 역시 그렇죠. 하지만, 우리는 동작 변경에서 벗어나 모든 가능한 구조 변경을 상상하고는 합니다. 그 지점이 코드를 정리하는 토끼굴에 빠지는 순간이죠. 하지만, 너무 빠지면 덜 중요한 일에 매달릴 수 있으니 주의를 기울여야 합니다.

[7일차 - 22p. (이제부터는 부록입니다.)]

코드가 유기체와 같다고 느끼는 장면이 그런 부분인데, 그 많은 사연을 코드를 읽을 시점에 누가 나에게 알려주지 않습니다. 그렇게 막막해질 수 있는 나를, 혹은 그렇게 될 동료를 그대로 내버려둘 것인가요? 때로는 간결하게만 코드를 정리하는 것이 아니라 오히려 하나의 더미가 되게 뭉쳐야 한다는 사실은 모순처럼 느껴집니다만, 결국 프로그래머는 감정과 인지적 한계를 지닌 사람이고, 코드의 줄거리를 이해할 수 있는 상태가 된 이후에야 코드를 정리할 수 있다는 당연한 사실을 새삼 분명하게 인지하게 되었습니다.

[6일차 - 29p. ]

결합도 분석은 단순히 프로그램의 소스 코드를 보는 것만으로는 부족합니다. 두 요소가 결합되어 있는지 여부를 판단하려면, 먼저 어떤 변경이 발생했거나 발생할 가능성이 있는지 알아야 합니다 (테스트해 보려면 하나의 커밋에서 어떤 파일 쌍이 함께 나타나는 경향이 있는지 살펴보세요. 그런 파일들은 결합되어 있습니다.). 또한, 결합도는 소프트웨어 비용을 결정합니다. 결합도는 매우 근본적인 개념이기 때문에 저는 가능한 한 다양한 방식으로 표현하고 시각화합니다.

우선은 가볍게 프로로 입문해보겠숩니다!

[5일차 - 13p.]

• 잠재적인 동작 변경의 가치가 변동성이 클수록 더 좋습니다. • 개발 기간이 길면 길수록 좋습니다. 물론 앞으로 더 저렴하게 개발할 수 있다면 더 좋겠지만, 그것은 가치의 극히 일부분에 불 과했습니다. • 더 작은 설계 작업으로 옵션을 만들 수 있다면 더 좋았습니다.

[4일차] 23p.

다음 상황에는 코드 정리를 하지 마세요. • 앞으로 다시는 코드를 변경하지 않을 때 • 설계를 개선하더라도 배울 것이 없을 때 다음 상황에서는 나중으로 정리를 미루세요. • 정리할 코드 분량이 많은데, 보상이 바로 보이지 않을 때 • 코드 정리에 대한 보상이 잠재적일 때 • 작은 묶음으로 여러 번에 나눠서 코드 정리를 할 수 있을 때 다음 상황에서는 동작 변경 후에 정리하세요. • 다음 코드 정리까지 기다릴수록 비용이 더 불어날 때 • 코드 정리를 하지 않으면 일을 끝냈다는 느낌이 들지 않을 때 다음 상황에서는 코드 정리 후에 동작 변경을 하세요. • 코드 정리를 했을 때, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있을 때 • 어떤 코드를 어떻게 정리해야 하는지 알고 있을 때

[3일차 -20p.]

코드 정리는 자꾸 손이 가는 감자칩과 같습니다. 한 개를 먹으면 바로 또 먹고 싶어집니다. 따라서 코드를 계속 정리하고 싶은 충동을 관리하는 것도 코드 정리의 핵심 기술입니다. 방금 정리했는데 더 정리해도 될까요? 상황에 따라 다릅니다 (3부에서 어떻게 달라지는지 설명하겠습니다).

[2일차 -20p.]

데이터 종속을 수작업으로 분석한다면, 결국 실수를 하게 될 것입니다. 구조만 개선하려고 하다가 실수로 동작까지 변경하게 될 수도 있습니다. 그래도 문제는 없습니다. 올바른 버전의 코드로 되돌리면 됩니다. 작은 단계로 작업하세요. 그 방식이 바로 코드 정리 방법입니다. 커다란 설계 변경은 어렵고 무섭죠? 더 작은 단계로 진행하세요. 그래도 무섭다면, 더 작게 하세요. 두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다.

오앙, 오늘 좀 늦게 퇴근하고 인천광역버스를 탔는데 산타버스네요! 🎅 기사님이 산타 복장으로 승객들한테 츄파춥스를 하나씩 나눠주시더라고요! 괜히 기분이 좋네요!

어제 해커스펍 송년회를 잘 다녀왔습니다. 이동하는 버스 안에서 제 해커스펍 주소를 QR 코드로 열심히 만들었는데, 막상 공유할 용기는 없어서 못 했네요 ㅋㅋ

전날까지도 갈까 말까 고민을 많이 했었는데, 부담감을 이기고 다녀오길 정말 잘했다는 생각이 들었습니다. 라이트닝 토크도 하나같이 유익했어요.

저는 클로드 코드는 아직 써보지 않았는데 (토큰이 살살 녹는다는 얘기를 들어서요 ㅋ ), 이야기를 듣다 보니 요즘 대세는 확실히 클로드 코드인가 싶더라고요. 이제 써볼까 생각만 하고 있었는데, 어제 라이트닝 토크 발표를 듣고 나니 “바로 시작해봐야겠다”는 생각이 들었습니다. 🐱‍💧

[1일차] 19p.

코드 정리는 작은 리팩터링으로 누구도 싫어할 수 없을 정도로 사랑스럽고 포근합니다.

읽을책 <켄트 벡의 Tidy First?: 더 나은 소프트웨어 설계를 위한 32가지 코드 정리법 전 2권> 켄트 벡 저자 · 안영회 번역

컴퓨터/IT | 한빛미디어 | 248p

Hackers' Pub @ Seoul 송년회에서 뵐게요! 낯을 좀 가리는 편이라 살짝 부끄럽네요 😹

오앙! 요즘 현생이 너무 바빠서 간만에 해커스펍에 들어왔는데, 초대장 하나가 생겨 있었네요! 😆

[7일차] 완독

면접관도 사람이다. 해결해야 할 일이 있고, 그 일을 하는 데 필요한 사람을 찾고 있을 뿐이다. 누군가를 평가하고 자신의 위치를 과시하려는 것이 아니라 고민하고 있는 것들을 해결 해 줄 수 있는 사람을 열심히 찾고 있다. 지원자가 회사에 들어 가고 싶은 마음 못지않게 면접관도 ‘같이 일하고 싶은 사람’을 찾고 싶다는 기대를 갖고 면접장에 들어온다. 면접은 그런 두 사람이 만나는 곳이다. 조금은 가볍게, 조금은 더 즐겁게 면접에 임하자.

면접에서 느끼는 부담감을 조금 내려놓아야겠습니다.

[6일차] 24p.

무언가에 푹 빠지게 된 계기는 사소한 것이어도 상관없다. 처음부터 계획하지 않아도 된다. 우리가 살아가면서 마주하는 모든 순간들을 통제하며 살아갈 수는 없다. 마음이 가는 대로 어떤 것들은 가볍게, 어떤 것들은 깊이 살피면 된다. 관심이 가고, 더 들여다보게 된다. 그렇게 하다 보면 어느 순간 크고 작은 벽에 부딪히게 되는데, 그럴 때 포기 하지 않고 계속 알아가고 싶다는 것을 느끼면 바로 그것이 푹 빠지는 것이다. 자신의 삶에서 그런 경험들이 있는가. 그 가운데 어떠한 것을 이야기할 것인가. 왜 그렇게 생각하는가.

[5일차] 36p.

아무래도 면접에서는 시간의 제약으로 인해 면접관이 할 수 있는 질문은 한정적일 수밖에 없다. 그러나 자기 자신에게는 얼마든지 질문할 수 있다. 자신에 대해 궁금해하고 관심을 갖게 되면 걸어갈 때나, 책을 읽을 때, 뭔가에 몰입할 때, 아침에 샤워할 때, 집중해서 일할 때, 그리고 한참을 집중하다 잠깐 밖에 나왔을 때도 자신에 대해 궁금한 것들이 생기고, 그 질문에 대해 곰곰이 생각해 볼 수 있게 된다. 나에 대한 이해가 높아지면, 다른 사람의 관점에서 내가 어떻게 보이는지 이해하게 된다.

안녕하세요! 어도비 포토샵 웹 구글 확장 프로그램이 출시되었어요!

12월 8일까지 설치하면 1년 무료로 이용할 수 있다고 해서 안내드립니당! 제가 바로 설치해보니 신용카드 등록 없이 바로 사용할 수 있네요!

https://chromewebstore.google.com/detail/adobe-photoshop/kjchkpkjpiloipaonppkmepcbhcncedo?linkId=19220927&pli=1&media_id=3774615548895390111_66394115840&media_author_id=66394115840&ranking_info_token=GCAyNGZhMTZhY2E2NGQ0YjE1ODRhYzM0YWUxNDg4NWY0OCWI+okFFdCsBxa8wb6SDRgTMzc3NDYxNTMwOTIwNzcwMTU5MygDaGlsAA%3D%3D&utm_source=ig_text_post_permalink

[4일차] 21p.

면접은 시험이 아니다. 시험에서는 모르는 개념이나 용어가 나와도 감독관에게 물을 수 없다. 아쉬운 대로 어림짐작으로 때려 맞혀야 한다. 그러나 면접은 다르다. 면접관의 질문이 이해되지 않거나, 면접관이 사용하는 용어가 익숙하지 않으면 그 의미를 애써 짐작만 할 필요가 없다. 그냥 물어보면 된다. 그것도 모르냐고 면박을 주는 면접관은 거의 없다. '아, 내가 좀 더 설명을 잘해야겠구나' 생각하며 그러한 질문을 한 지원자를 긍정적으로 바라보게 될 것이다. 질문을 이해하지 못한 채로 엉뚱한 답을 하는 지원자보다는 모르는 부분에 대해서 확인한 뒤에 자신의 이야기를 하는 지원자가 훨씬 더 현명해 보인다. 일할 때도 마찬가지다. 업무 지시가 이해되지 않는다면 무작정 시작하는 것보다 업무 지시의 의미나 내용을 고민해보고 다시 질문하는 것이 필요하다. 정말 급하게 처리해야 하는 예외적인 상황이 아니라면 확실하지 않을 때 가장 확실한 방법은 질문하는 것이다. 모르는 것이 있을 때는 아는 척하지 말 것. 질문을 통해 면접관이 무엇을 묻고 싶어 하는지 확인하면 된다. 필요하다면 '잠시 생각한 후에 말씀드려도 될까요?' 라고 양해를 구해도 된다. '아니요, 바로 답하셔야 합니다'라고 반응할 면접관은 없을 것이다.

[3일차] 21p.

그렇다면 지원자는 어떻게 대비하는 것이 좋을까? 먼저 기본으로 돌아가라고 권하고 싶다. 자신이 했던 업무를 다른 사람이 알기 쉽게 전달할 수 있는 방법을 고민하고, 그에 맞게 이력서를 작성하는 것이 중요하다. 자신이 해온 업무를 중요도의 구분 없이 이것저것 병렬식으로 나열하는 것은 좋지 않다. 그런 이력서는 면접관의 눈에 잘 들어오지 않고, 면접관이 지원자에게 무엇을 물을지 가늠하기도 어려워진다. 그러니 중요도에 따라 업무를 쉽고 간결하게 묶고 재배치하여 지 원자에 대한 면접관의 이해를 높이는 노력이 필요하다. 이력서 자체가 면접관에게 질문의 가이드가 되도록 하는 것이다.

[2일차] 23p.

이렇게 면접의 주도권을 가져오기 위해 지켜야 할 원칙이 있다. 절대 자기소개를 달달 외우지 말라는 것이다. 앞에서도 언급했지만, 면접은 누구에게나 긴장될 수밖에 없는 상황이다. 고도로 훈련된 전문 배우가 연기를 하는 것이 아닌 이상, '외워서 하는 이야기'에는 생명력이 없다. 외운 것을 그대로 말해야 한다는 압박 때문에 자기도 모르게 로봇처럼 뻣뻣하게 대사를 읊게 되고, 대본이 기억나지 않으면 말문이 막혀버린다. 자신이 외운 내용에 확신이 없으면 목소리가 점점 작아지고 느려지면서 면접관들의 집중력을 떨어뜨리게 될 것이다. 누군가의 관심을 끌려고 할 때와 정확히 반대의 현상이 벌어지는 것이다.

아오 또.. 공개

[1일차] 43p.

사실 면접에서 가장 중요한 것은 면접관이 이 지원자와 함께 일하고 싶은 마음이 드는가 하는 점이다. 지원자로부터 자신이 듣고 싶었던 답을 들었기 때문에 같이 일하고 싶은 마음이 드는 것이 아니라, 질문과 답변을 주고받는 과정에서 지원자의 사고방식을 이해하고, 이 사람과 함께 일했을 때 어떻게 일하게 될지 머릿속에 그려질 때 지원자에 대한 호감도가 상승할 것이다. 그런 면에서 지원자의 솔직함은 그 사람을 이해하는데 매우 중요한 요소라는 것을 잊지 말자.

악 조용히 공개여야 하는데 ㅠㅠ

읽을책 <면접의 질문들> 저자 김형석

자기계발 | 노르웨이숲 | 200p

[17일차] 23p.

If-Modified-Since 상태 헤더는 문서 인스턴스의 마지막 수정된 날짜를 검사하므로, 우리는 마지막 수정된 날짜를 검사기라고 말할 수 있다. If-None-Match 조건부 헤더는 문서의 ETag 값을 평가한다. ETag는 특별한 키워드이거나 엔터티와 관련된 버전 식별 태그이다. Last-Modified와 ETag는 HTTP에 의해 사용되는 두 개의 주요한 검사기다.

[16일차] 21p.

콘텐츠 인코딩 과정은 다음과 같다.

1. 웹 서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
2. 콘텐츠 인코딩 서버(아마 원 서버이거나 다운스트림 프락시일 것이다)가 인코딩된 메시지를 생성한다. 인코딩된 메시지는 Content-Type은 같지만(본문이 압축되었거나 했다면) Content-Length는 다르다. 콘텐츠 인코딩 서버는 Content-Encoding 헤더를 인코딩된 메시지에 추가하여, 수신 즉 애플리케이션이 그것을 디코딩할 수 있도록 한다.
3. 수신 측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

[15일차] 22p.

HTTPS는 HTTP의 가장 유명한 보안 버전이다. 널리 구현되었으며 주류 상용 브라우저와 서버에 구현되어 있다. HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다. 이 기법들의 집합은 무정부 상태의 분권화된 글로벌 인터넷 환경에서도 HTTPS를 매우 안전한 동시에 매우 유연하고 관리하기 쉽게 만들어 준다. HTTPS는 인터넷 애플리케이션의 성장을 가속한 동시에 웹 기반 전자상거래의 고속 성장을 이끄는 주력이다. HTTPS는 또한 분산된 웹 애플리케이션의 광역 보안 관리에 있어 대단히 중요하다.

[11일차] 22p.

단순함이 중요하다는 것에 다들 공감을 하지만 막상 실천하기는 어렵다. 커뮤니케이션을 할 때 대중을 위해 미리 핵심을 선택하고 정리하는 작업을 거쳐야 하는데 그 과정이 만만치 않다. 게다가 개인의 독특한 개성을 중시하는 트렌드 속에서 간결함과 개성 사이에서 어떻게 균형을 유지하느냐도 반드시 직면하는 문제다. 그러나 몇 가지 원칙을 지킨다면 이런 문제를 더욱 수월하게 해결할 수 있을 것이다. 비즈니스 커뮤니케이션 전문가인 앨런 시겔은 저서 《심플》에서 단순한 커뮤니케이션을 위한 세 가지 기본 원칙을 제안 했다. 그것이 바로 단순화 원칙인 '공감하기,'핵심만 거르기, '명료하게 말하기'다.

[10일차] 23p.

비즈니스 커뮤니케이션에 성공하려면 시간, 공간, 목적과 선호도 등 외부 요소를 고려하여 최선을 다해 임해야 한다. 비즈니스 세계에 지나친 준비, 지나친 예절은 존재하지 않는다. 준비가 부족하고 예의에 어긋나는 것보다는 다소 과한 편이 낫다.

[9일차] 20p.

가설을 제기할 때 해당 문제에 능통한 전문가의 개입이 필요할까? 전혀 필요하지 않다. 전문가를 초빙하더라도 가설 제기 과정, 특히 초기의 브레인스토밍 활동에 너무 이르게 개입하는 것은 금물이다. 하향식 사고방식을 구현하는 가설 제기는 경험 지향적인 상향식 사고방식과는 완전히 다르기 때문에 균형을 잡아주지 않으면 첨예한 충돌이 일어나게 된다. 전문가가 체계적인 구조화 사고 훈련을 받지 않았다면 습관적으로 전문가적 사고에 편중될 것이고, 5단계 기법 중 앞의 4단계를 뛰어넘어 이른바 정답'을 바로 제공할 것이다.

[14일차] 21p.

한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하기 위한 것이며, 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것이다. 인코딩 키는 모두를 위해 공개되어 있다(그래서 공개키 암호 방식이라는 이름이 붙었다). 하지만 호스트만이 개인 디코딩 키를 알고 있다.

[13일차] 24p.

Base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터(어떤 시스템에서는 문제를 일으킬 수 있는) 문자열 받아서 전송할 수 있게, 그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다. 전송 중에 원본 문자열이 변질될 걱정 없이 원격에서 디코딩할 수 있다. base-64 인코딩은 국제 문자나 HTTP 헤더에서 사용할 수 없는 문자{큰따옴표, 콜론, 캐리지 리턴)를 포함한 사용자 이름이나 비밀번호를 보내야 할 때 유용할 수 있다. 또한, base-64는 어렵지 않게 사용자 이름과 비밀번호 문자를 섞을 수 있기 때문에, 서버나 네트워크를 관리하면서 뜻하지 않게 사용자 이름과 비밀번호가 노출되는 문제를 예방하는 데 도움이 된다.

[12일차] 20p.

쿠키는 크게 세션 쿠키(session Cookie)와 지속 쿠키(persistent cokite) 두 가지 타입으로 나눌 수 있다. 세션 쿠키는 사용자가 사이트를 탐색할 때, 관련한 설정과 선호사항들을 저장하는 임시 쿠키다. 세션 쿠키는 사용자가 브라우저를 닫으면 삭제된다. 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다. 지속 쿠키는 디스크에 저장되어, 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다. 지속 쿠키는 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하려 고 사용한다. 세션 쿠키와 지속 쿠키의 다른 점은 파기되는 시점뿐이다. 뒤에서 다룰 것이지만, 쿠키는 Discard 파라미터가 설정되어 있거나, 파기되기까지 남은 시간을 가리 키는 Expires 혹은 Max-Age 파라미터가 없으면 세션 쿠키가 된다.

[11일차] 22p.

오늘날 검색엔진들은 그들이 갖고 있는 전 세계의 웹페이지들에 대해 '풀 텍스트 색인(full-text indexes)'이라고 하는 복잡한 로컬 데이터베이스를 생성한다. 이 색인은 웹의 모든 문서에 대한 일종의 카드 카탈로그처럼 동작한다. 검색엔진 크롤러들은 웹페이지들을 수집하여 집으로 가져와서, 이 풀 텍스트 색인에 추가한다. 동시에, 검색엔진 사용자들은 핫봇(http://www.hotbot.com)이나 구글(http://www.google.com)과 같은 웹 검색 게이트웨이를 통해 풀 텍스트 색인 에 대한 질의를 보낸다. 크롤링을 한 번 하는데 걸리는 시간이 상당한 데 비해 웹페이지들은 매 순간 변화하기 때문에, 풀 텍스트 색인은 기껏 해봐야 웹의 특정 순간에 대한 스냅숏에 불과하다.

[10일차] 22p.

로봇 커뮤니티는 로봇에 의한 웹 사이트 접근이 유발할 수 있는 문제를 알고 있었다. 1994년, 로봇이 그들에게 맞지 않는 장소에 들어오지 않도록 하고 웹 마스터에게 로봇의 동작을 더 잘 제어할 수 있는 메커니즘을 제공하는 단순하고 자발적인 기법이 제안되었다. 이 표준은 "Robots Exclusion Standard"라고 이름 지어졌지만, 로봇의 접근을 제어하는 정보를 저장하는 파일의 이름을 따서 종종 그냥 robots.txt 라고 불린다. robots.txt의 아이디어는 단순하다. 어떤 웹서버는 서버의 문서 루트에 robots.txt라고 이름 붙은 선택적인 파일을 제공할 수 있다. 이 파일은 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보가 담겨있다. 만약 어떤 로봇이 이 자발적인 표준에 따른다면, 그것은 웹 사이트의 어떤 다른 리소스에 접근하기 전에 우선 그 사이트의 robots.txt를 요청할 것이다.

[9일차] 21p.

웹 크롤러는, 먼저 웹페이지를 한 개 가져오고, 그 다음 그 페이지가 가리키는 모든 웹페이지를 가져오고, 다시 그 페이지들이 가리키는 모든 웹페이지들을 가져오는, 이러한 일을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇이다. 웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, HTML 하이퍼링크 들로 만들어진 웹을 따라 기어다니기(craw) 때문이다. 인터넷 검색엔진은 웹을 돌아다니면서 그들이 만나는 모든 문서를 끌어오기 위해 크롤러를 사용한다. 이 문서들은 나중에 처리되어 검색 가능한 데이터베이스로 만들어지는데, 이는 사용자들이 특정 단어를 포함한 문서를 찾을 수 있게 해준다.

[8일차] 20p.

미국의 심리학자 헬레나 매튜트Helena Matute는 그의 논문 〈인과관계의 환각 Illusions of Causality〉에서 이렇게 지적했다. "시각적 환상과 같이 인과의 환각은 모든 사람에게서 흔히 발생한다. 과학적 사고 방법은 인과의 환각을 방지하는 최적의 경로다. 그러나 과학적 사고 방법은 본능적 반응이 아니며 습득이 필요한 기법이다." 헬레나 매튜트가 언급한 과학적 사고 방법은 구조화 전략 사고와 결을 같이하며 이성적 사고, 즉 느린 사고에 속한다.

[7일차] 21p.

문제 정의는 말 그대로 문제의 뜻과 한계를 명확히 하고 '우리는 지금 무슨 문제를 해결하고 있는가'라는 질문에 답하는 것이다. 이는 모든 문제 해결 방법론의 첫걸음이자 가장 중요하면서도 어려운 시작이다. 문제를 분명하게 정의할 수 있다면 진정한 해결 방안 을 찾는 것도 그렇게 어렵지 않다. 사람들은 까다로운 문제에 봉착하면 급한 마음에 눈앞의 문제부터 해결하려고 한다. 문제를 정의하고 분석, 검증하는 단계는 시간이 없다는 이유로 건너뛰곤 한다. 그러나 문제 정의는 문제 해결의 근본적인 방향성을 제시하는 중요한 단계다. 문제 정의에 오류 가 생기면 다른 단계에도 오류가 생기며 결국 동문서답식의 엉뚱한 답을 내놓게 된다. 문제를 정의하는 것은 경험에 의존하는 전문가적 사고와는 다른 전략적 사고로, 비판적 사고자들의 두드러진 특성이기도 하다.

[8일차] 23p.

Cache-Control: must-revalidate 응답 헤더는 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 재검사 없이는 제공해서는 안 됨을 의미한다. 캐시는 자유롭게 신선한 사본을 제공할 수 있다. 만약 캐시가 must-revalidate 신선도 검사를 시도했을 때 원 서버가 사용할 수 없는 상태라면, 캐시는 반드시 504 Gateway Timeout error를 반환해야 한다.

[7일차] 23p.

문서 적중률과 바이트 단위 적중률은 둘다 캐시 성능에 대한 유용한 지표다. 문서 적중률은 얼마나 많은 웹 트랜잭션을 외부로 내보내지 않았는지 보여준다. 트랜잭션은 고정된 소요 시간을 포함하게 되는데, 이것은 종종 길 수도 있기 때문에(예를 들어 서버로의 TCP 커넥션을 맺는 경우), 문서 적중률을 개선하면 전체 대기시간(지연)이 줄어든다. 바이트 단위 적중률은 얼마나 많은 바이트가 인터넷으로 나가지 않았는지 보여준다. 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

[6일차] 21p.

웹 서버는 여러 종류의 리소스 매핑을 지원한다. 하지만 리소스 매핑의 가장 단순한 형태는 요청 URI를 웹 서버의 파일 시스템 안에 있는 파일 이름으로 사용하는 것이다. 일반적으로 웹 서버 파일 시스템의 특별한 폴더를 웹 콘텐츠를 위해 예약해 둔다. 이 폴더는 문서 루트 혹은 docroot로 불린다. 웹 서버는 요청 메시지에서 URI를 가져와서 문서 루트 뒤에 붙인다.

[5일차] 20p.

한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 그 트랜잭션은 멱등(idempotent)하다고 한다. GET, HEAD, PUT, DELETE, TRACE 그리고 OPTIONS 메서드들은 멱등하다고 이해하면 된다. 클라이언트는 POST와 같이 멱등인 아닌 요청은 파이프라인을 통해 요청하면 안 된다. 그렇지 않으면 전송 커넥션이 예상치 못하게 끊어져 버렸을 때, 알 수 없는 결과를 초래할 수 있다. 비멱등인 요청을 다시 보내야 한다면, 이전 요청에 대한 응답을 받을 때까지 기다려야 한다. 비멱등인 메서드나 순서에 대해 에이전트가 요청을 다시 보낼 수 있도록 기능을 제공한다 하더라도, 자동으로 재시도하면 안 된다. 예를 들어 대부분 브라우저는 캐시된 POST 요청 페이지를 다시 로드하려고 할 때, 요청을 다시 보내기를 원하는 지 묻는 대화상자를 보여준다.

[6일차] 25p.

구조화 전략 사고는 논리적 사고 기법의 일종이다. 논리적 사고와 창의적 사고는 뇌의 특정 부위에서 이루어지지만, 둘은 대립 관계라기보다는 오히려 상호 보완적 관계다. 때로는 논리적인 사고를 할 때 상식을 뒤엎는 창의력이 필요하다. 논리적 사고법을 제대로 사용하려면 빠른 사고의 고정관념에서 탈피해 전방위로 문제 해법을 찾아야 한다.

[5일차] 21p.

브레인스토밍의 첫 단계는 생각할 수 있는 모든 요소를 일단 나열하는 것이다. 그다음에 이를 하나하나 조사하고 분류한다. 팀원들은 절차나 순서에 상관없이 자유롭게 아이디어를 제시하고 당신은 이를 화이트보드에 적는다. 이후 팀원들은 각 요소가 합리적인지 가치를 따져보고 그중 필요 없는 것은 걸러낸다. 이렇게 간략한 선별 과정을 거쳐 관련 요소만을 칠판에 남겨놓는다. 팀원들이 적극적으로 토론에 참여했다면 칠판은 브레인스토밍 결과로 나온 의사결정 요소로 빼곡할 것이다.