프로그램이 디스크 읽기를 요청했습니다. 디스크는 CPU보다 수만 배 느립니다. 요청한 프로그램은 그동안 무엇을 해야할까요. 답이 두 가지입니다.동기식 입출력(synchronous I/O): 입출력이 끝난 뒤에야 제어가 사용자 프로그램으로 넘어옵니다. 요청한 프로그램은

"C101이나 M201을 들은 학생", "같은 학과 학생 쌍" 같은 질문은 결과 두 개를 붙이거나 릴레이션을 겹쳐야 답이 나옵니다.집합 연산(UNION, INTERSECT, EXCEPT)은 합집합 호환성(union compatibility)이 전제입니다. 조인(join

앞 편에서 본 관계 대수는 절차적입니다. 무엇을 어떤 순서로 계산할지 사람이 직접 적어야 하고, 산술 연산도 정렬도 갱신도 안 됩니다. 실제 데이터베이스를 쓰려면 그것들이 전부 필요합니다.SQL은 1974년 IBM 산호세 연구소에서 System R이라는 관계 DBMS

인터넷의 계층은 다섯 개입니다.각 층은 아래 층에게 "알아서 배달해 달라"고 맡기고, 자기 층에서 필요한 정보를 header(헤더)에 적어 붙입니다. 그래서 데이터는 내려갈수록 헤더가 겹겹이 쌓이고, 받는 쪽에서는 반대로 한 겹씩 벗겨집니다. 이것이 encapsulat

컴퓨터는 CPU, 메모리(memory), 입출력 장치(I/O device) 세 덩어리로 나뉩니다.여기서 중요한 전제가 하나 있습니다. 메모리는 CPU의 작업 공간이라는 것입니다. CPU는 디스크에 있는 데이터를 직접 읽지 못합니다. 반드시 메모리에 올라온 것만 처리합니

같은 코드라도 어떤 하드웨어와 소프트웨어 위에서 돌리느냐에 따라 성능이 달라집니다. CPU 속도, 메모리, 운영체제, 인터프리터 구현이 전부 제각각이기 때문입니다.그래서 초 단위 실측값은 알고리즘의 성능이라기보다 "이 알고리즘을 이 환경에서 돌린 결과"에 가깝습니다.

SQL만 아는 상태에서는 "같은 결과를 내는 두 쿼리의 속도가 왜 다른가"를 설명할 수 없습니다. SQL은 원하는 결과만 적을 뿐 계산 순서를 적지 않기 때문입니다. 그 순서를 적는 언어가 관계 대수이고, DBMS는 SQL을 관계 대수 식으로 바꾼 뒤 그 식을 변형해

인터넷은 크게 network edge(네트워크 엣지)와 network core(네트워크 코어)로 나뉩니다. 노트북, 휴대폰, 서버 같은 end system은 모두 edge에 있습니다. 우리가 배포하는 서비스도 여기 있습니다. core에는 router(라우터)가 있고,

프로그램 하나를 실행한다고 해봅시다. 운영체제가 없다면 이 프로그램은 CPU를 언제부터 얼마나 쓸지, 메모리의 어느 주소에 올라갈지, 디스크의 어느 위치에 파일을 쓸지를 스스로 정해야 합니다. 프로그램이 둘 이상이 되면 문제가 커집니다. 서로 같은 메모리 영역을 덮어쓰

프로그램이 다루는 것은 결국 자료(data)입니다. 자료는 어딘가에 놓여야 하고, 그 자리가 메모리입니다. 그런데 값을 메모리에 올려두기만 하면 할 수 있는 일이 없습니다. 값을 꺼내 오고, 바꾸고, 중간에 끼워 넣고, 지우고, 찾을 수 있어야 비로소 쓸모가 생깁니다.

딕셔너리로 하는 일의 대부분은 결국 세 가지입니다. 값에 접근하고, 대입하고, 삭제하는 것입니다. 이 중에서 유독 코드가 지저분해지는 지점이 "키가 아직 없을 때"의 처리입니다. 투표 집계, 태그별 그룹핑, 사용자별 이벤트 누적처럼 흔한 작업마다 같은 분기가 반복됩니다

파이썬 3.7부터 dict는 키를 삽입한 순서대로 순회한다는 것이 언어 명세로 보장됩니다. 덕분에 정렬 코드를 따로 쓰지 않고도 "가장 먼저 등록된 항목"을 첫 번째로 꺼내 쓰는 코드가 자연스럽게 자리 잡았습니다. 여기까지는 안심해도 좋습니다.함정은 함수가 받는 인자가

리스트 세 개를 순서대로 이어 붙이려고 이중 for 문을 쓰고, 인접한 두 원소를 비교하려고 range(len(items) - 1)을 꺼내고, 고정 크기로 잘라 배치 전송하려고 인덱스 계산을 손으로 하고 있는 경우가 있을 겁니다. 이런 코드는 대체로 짧지만 경계 조건에

십만 줄짜리 로그 파일을 훑으면서 "손상된 줄이 하나라도 있는가"를 판단하는 코드를 상상해 보시기 바랍니다. 두 번째 줄에서 이미 손상이 발견됐다면 나머지 구만 구천여 줄은 읽을 이유가 없습니다. any와 all은 정확히 그런 판단을 위해 만들어진 내장 함수입니다. a

딕셔너리를 돌면서 조건에 맞는 항목에 파생 키를 하나씩 붙이는 코드를 짜다가 RuntimeError: dictionary changed size during iteration을 만난 적이 있을겁니다. 논리적으로는 아무 문제가 없어 보이는데 인터프리터가 갑자기 에러를 내

리스트를 받아 잘 동작하던 함수가 제너레이터(generator)를 넘기는 순간 빈 결과를 뱉는 상황을 만나신 적 있을겁니다. 예외도 없고 로그도 조용한데 결과만 비어 있는 이 증상은, 함수가 인자를 두 번 이상 순회할 때 벌어집니다.원인은 이터레이터(iterator)가

파이썬의 for 루프 변수는 루프 안에서만 사는 존재가 아닙니다. 루프가 끝난 뒤에도 마지막 값을 그대로 품은 채 바깥 스코프에 남아 있습니다. C나 자바에서 블록 안에 선언한 변수가 블록을 벗어나면 사라지는 것과는 정반대의 동작입니다.이 성질을 알고 나면 유혹이 따라

파이썬은 for와 while 루프 바로 뒤에 else 블록을 붙일 수 있게 허용합니다. 다른 언어에서 보기 힘든 문법이라 처음 발견하면 뭔가 대단한 기능처럼 느껴지지만, 실제 동작을 확인하고 나면 대부분 고개를 갸웃하게 됩니다.혼란의 원인은 else라는 단어가 파이썬

실무에서 다루는 리스트는 혼자 다니는 법이 거의 없습니다. 사용자 이름 리스트가 있으면 그 사용자의 점수 리스트가 따로 있고, 컴프리헨션(comprehension)으로 원본 리스트를 가공해 파생 리스트를 하나 더 만드는 일도 흔합니다. 이렇게 만들어진 두 리스트는 "같

range는 정수 집합을 순회할 때 쓰라고 만든 도구입니다. 난수를 여덟 번 뽑거나 0부터 9까지 더하는 코드라면 range가 정확히 제자리를 찾은 셈입니다.문제는 이 도구가 리스트 순회에까지 끌려 나올 때 생깁니다. "인덱스도 같이 필요하다"는 이유로 range(le