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

파이썬 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

기본 언패킹(unpacking)에는 분명한 한계가 하나 있습니다. 왼쪽에 적은 변수 개수와 오른쪽 시퀀스의 길이가 정확히 맞아떨어져야 한다는 점입니다. 그래서 "가장 큰 값 둘만 따로 보고 나머지는 한 덩어리로 두겠다" 같은 요구가 들어오면 대부분 인덱스와 슬라이스로

파이썬은 리스트를 일정한 간격으로 건너뛰며 잘라내는 문법을 제공합니다. somelist\[start:end:stride] 형태이고, 이 세 번째 값을 스트라이드(stride)라고 부릅니다. 짝수 번째 원소만 뽑거나 문자열을 뒤집을 때 x\[::2], x\[::-1] 한

1장은 Rust 문법이라기보다 "환경을 깔고 첫 프로그램을 돌리는 법 + 기본 도구" 에 대한 내용입니다. 다른 언어를 해봤다면 대부분 익숙한 흐름이라, Rust에서 무엇이 다른지만 짚고 넘어가겠습니다.rustup(러스트업)은 Rust 버전과 관련 도구를 관리하는 명령

개인 프로젝트 doc-graph-agent 이야기입니다. 문서를 지식그래프로 바꾸고, 그 위에서 질문에 답하는 GraphRAG를 만들었는데, 단순 어휘검색(BM25)이랑 같은 문제로 붙여보니 졌습니다. 이 글은 그다음에 한 일들의 기록인데, 솔직히 성공기는 아닙니다.

1. 왜 이 멘토링에 참여했는가 ChatGPT가 "그건 잘 모르겠어요"라고 답할 때마다, 또는 RAG 시스템이 분명 문서에 있는 정보를 못 찾아낼 때마다 같은 의문이 들었습니다. > 비정형 문서 사이의 관계를 LLM이 추론하게 만들 수는 없을까? VectorRAG

이 챕터의 thesis는 다음과 같다. 이상 탐지는 본질적으로 "흩어진 식별자들이 같은 인물·집단을 가리키는지"를 판별하는 entity linking 문제이며, 그래프는 이를 관계의 직접적인 표현으로 환원해 단순한 SQL 질의로는 도달할 수 없는 패턴을 드러낸다. Su

이 챕터의 thesis는 다음과 같다. 추천은 본질적으로 "관련 있는 후보를 찾는 단계"와 "부적절한 후보를 걸러내는 단계"로 분해되며, RAG는 vector similarity로 전자를, similarity score cutoff로 후자를 수행한다. KG와 LLM이

이전 편에서 graph representation learning과 message passing의 일반론을 다뤘다. 이번 챕터는 그 위에서 실제로 두 가지 대표 태스크—node classification과 link prediction—를 어떻게 동일한 framework

이전 편까지의 GraphRAG 시리즈는 지식 그래프를 "구성"하고 "탐색"하는 문제를 다뤘다. 텍스트로부터 entity를 추출하고, 관계를 정제하고, Cypher로 traversal하는 흐름이다. 그러나 그래프 위에서 ML 모델을 직접 학습시키려면 또 하나의 단계가 필

이번 글의 thesis는 다음과 같다. 그래프 ML의 성공은 vectorization의 품질에 달려 있으며, 그 품질은 해석가능성과 자동화 사이의 의식적 trade-off로 결정된다. Manual feature engineering, semiautomated 접근(Re