콘텐츠로 이동

04 rieul

LoRA

  • 뜻: 기반 모델의 큰 가중치 본체는 최대한 유지하고, 작은 추가 조정분만 학습해 목적 적응 비용을 줄이려는 효율적 조정 방식입니다. 직관적으로는 거대한 본체를 통째로 다시 쓰기보다, 필요한 방향 변화만 작은 보조 조정판처럼 덧붙이는 방법이라고 볼 수 있습니다. 그래서 같은 기반 모델을 공유하면서도 업무별 추가분만 따로 저장하는 운영이 가능해집니다.
  • 왜 중요한가: 전체 파인튜닝이 너무 무거운 상황에서도 같은 기반 모델을 여러 업무에 맞게 더 가볍게 적응시키는 대표 실무 선택지이기 때문입니다. 이 개념이 있어야 모델을 다시 조정한다는 일이 언제나 본체 전체를 다시 학습하는 뜻은 아니라는 점을 이해하게 되고, 성능·비용·저장 공간 사이의 절충으로 조정 전략을 고른다는 실무 감각도 함께 붙잡게 됩니다. 또한 LoRA는 기반 모델을 얼마나 유지하면서 어떤 수준의 업무 특화를 얻고 싶은지 판단하는 절충점이라는 점도 중요합니다. 즉 완전한 독립 모델을 새로 만드는 방식과, 프롬프트만 바꾸는 방식 사이에 놓인 중간 적응 전략으로 읽을 수 있습니다.
  • 함께 볼 개념: 미세조정(fine-tuning), 파라미터(parameter), 양자화(quantization)
  • 중심 Section: P6-8.2
  • 등장 Section: P6-9.4, P6-9.5

라벨(label)

  • 뜻: 데이터 사례에 사람이 붙인 정답이나 목표 출력입니다. 모델이 스스로 발견한 구조가 아니라, 현재 문제에서 무엇을 맞았다고 볼지 사람이 정의해 놓은 기준이라고 볼 수 있습니다. 즉 라벨은 데이터 안에 자연히 숨어 있는 값이라기보다, 이번 학습에서 무엇을 답으로 삼을 것인가를 정해 둔 해석 규칙에 가깝습니다. 분류에서는 보통 범주 이름이 라벨이 되고, 회귀에서는 맞혀야 할 수치 값이 라벨 역할을 합니다.
  • 왜 중요한가: 지도학습에서는 모델이 무엇을 맞혀야 하는지를 라벨이 정해 줍니다. 같은 입력 데이터라도 라벨 정의가 달라지면 전혀 다른 문제와 평가 방식으로 바뀔 수 있습니다. 이 개념이 있어야 데이터에 원래 들어 있던 사실 기록과, 학습을 위해 사람이 부여한 정답 기준을 구분해 읽게 되고, 모델 성능 문제가 사실은 라벨 정의 문제일 수도 있다는 점도 함께 이해하게 됩니다. 특히 애매한 기준으로 붙인 라벨, 사람마다 다르게 붙는 라벨, 현실을 지나치게 단순화한 라벨은 학습 한계를 미리 만들어 버릴 수 있으므로, 데이터 품질을 볼 때 라벨 설계 자체를 함께 점검해야 합니다.
  • 함께 볼 개념: 사례(example), 데이터(data), 출력(output), 라벨링(labeling), 타깃(target)
  • 중심 Section: P1-4.2
  • 등장 Section: P1-2.1, P1-3.2, P1-8.1

라벨링(labeling)

  • 뜻: 데이터 사례에 사람이 구분 표식이나 목표 출력을 붙이는 작업입니다. 단순 입력 작업이 아니라, 어떤 기준으로 사례를 나누고 무엇을 정답으로 인정할지 운영 규칙을 문서화하는 과정까지 포함할 수 있습니다. 즉 라벨링은 데이터에 이름표를 붙이는 일만이 아니라, 모델이 무엇을 배우게 할지 기준을 현실 데이터 위에 새기는 과정입니다.
  • 왜 중요한가: 지도학습의 성능은 모델 구조만이 아니라 어떤 기준으로 라벨을 붙였는지에도 크게 좌우되므로, 학습 전 준비 과정 자체를 따로 읽어야 하기 때문입니다. 라벨링 기준이 흔들리면 모델 품질보다 먼저 데이터 의미가 흔들립니다. 이 개념이 있어야 정답이 있다는 말을 당연하게 보지 않고, 그 정답이 어떤 사람의 어떤 기준으로 만들어졌는지도 함께 묻게 됩니다. 결국 라벨링을 이해해야 모델 오류의 일부가 알고리즘보다 정답 설계와 작업 규칙에서 왔을 수 있다는 점도 읽게 됩니다.
  • 함께 볼 개념: 라벨(label), 지도학습(supervised learning), 타깃(target), 문제 정의(task definition)
  • 중심 Section: P1-8.1

라인 플롯(line plot)

  • 뜻: 순서나 시간에 따라 변하는 값을 점과 선으로 이어 보여 주는 기본 차트입니다. 개별 값 하나하나보다 앞뒤 값이 어떻게 이어지는가를 읽게 하는 시계열형 표현이라고 볼 수 있습니다. 즉 라인 플롯은 같은 크기 비교보다, 값이 흐르며 올라가고 내려가는 추세를 보는 데 더 맞는 그림입니다.
  • 왜 중요한가: 학습 반복에 따른 손실 변화, 함수 모양, 시간 흐름 같은 질문은 값 사이의 연속적 관계를 읽어야 하므로 가장 자주 쓰이는 시각화 기준이 되기 때문입니다. 이 개념이 있어야 막대그래프처럼 크기 비교가 중심인 차트와, 변화 추세를 읽는 차트를 구분하게 되고, 학습 곡선 해석도 더 자연스럽게 붙잡게 됩니다. 또한 라인 플롯을 이해해야 값 하나의 높낮이만이 아니라, 전체 흐름이 안정적으로 내려가는지 흔들리는지를 함께 읽게 됩니다. 즉 라인 플롯은 각 점의 크기보다 점들이 이어 만드는 흐름을 읽는 차트입니다.
  • 함께 볼 개념: 그래프(plot), 손실 곡선(loss curve), 축(axis)
  • 중심 Section: P2-13.2
  • 등장 Section: P2-13.3

랜덤포레스트(random forest)

  • 뜻: 여러 결정트리를 서로 조금씩 다르게 학습시켜 그 예측을 합쳐 더 안정적인 결과를 만드는 앙상블 모델입니다. 각 트리가 데이터 일부와 특징 일부를 다르게 보도록 만들어, 하나의 트리에만 과하게 의존하지 않게 하는 방식이라고 볼 수 있습니다. 즉 같은 문제를 보는 작은 트리 여러 개의 집단 판단으로 이해하면 됩니다.
  • 왜 중요한가: 하나의 트리가 흔들리기 쉬운 문제를 여러 트리의 합의로 줄이는 대표적 방식입니다. 이 개념이 있어야 왜 단일 결정트리보다 예측이 더 안정적일 수 있는지, 그리고 해석은 쉬운 단위성능은 더 안정적인 집합이 어떻게 결합되는지 설명할 수 있습니다. 또한 랜덤포레스트를 이해해야 여러 모델을 순차 보정하는 방식인 그래디언트 부스팅과 달리, 서로 조금씩 다른 트리를 병렬적으로 모아 평균내는 사고라는 점도 더 선명히 구분하게 됩니다.
  • 함께 볼 개념: 결정트리(decision tree), 앙상블(ensemble), bootstrap
  • 중심 Section: P4-15.1
  • 등장 Section: P4-15.2, P4-15.3

런타임 상태(runtime state)

  • 뜻: 현재 실행 중인 노트북 환경 안에 메모리, 변수, 불러온 모듈, 설정처럼 이미 올라가 있는 상태입니다. 파일에 적힌 코드와 별도로, 지금 세션 안에 살아 있는 실행 흔적 전체라고 볼 수 있습니다. 즉 런타임 상태는 적혀 있는 코드가 아니라 실제로 실행한 뒤 남아 있는 현재 문맥입니다.
  • 왜 중요한가: 파일 내용만 봐서는 알 수 없는 실행 맥락이 남아 있어, 노트북을 처음부터 다시 돌리면 다른 결과가 나오는 이유를 설명해 주기 때문입니다. 노트북 재현성이 흔들리는 대표 원인이 바로 이 런타임 상태입니다. 예를 들어 위 셀에서 데이터를 미리 바꾸거나 변수를 덮어쓴 뒤 아래 셀만 다시 실행하면, 코드 줄은 같아도 결과는 달라질 수 있습니다. 결국 런타임 상태를 이해해야 코드가 같다실행 조건이 같다를 같은 말로 보지 않게 되고, 재실행 가능한 기록이 왜 셀 순서와 초기화까지 함께 관리해야 하는지도 더 분명히 읽게 됩니다.
  • 함께 볼 개념: 숨은 상태(hidden state), 실행 순서(execution order), 실행 환경(runtime)
  • 중심 Section: P2-10.3
  • 등장 Section: P2-10.1, P2-10.2

레이어 정규화(layer normalization)

  • 뜻: 한 위치의 표현값들을 평균과 분산 기준으로 다시 정리해, 다음 계산으로 넘길 값 범위를 안정적으로 맞추는 정규화 방식입니다. 배치 전체 통계를 쓰는 방식과 달리, 현재 한 사례 안의 표현 벡터를 기준으로 값을 다듬는 쪽에 가깝습니다. 그래서 입력이 하나씩 들어오더라도 비교적 일관된 방식으로 값 스케일을 정리할 수 있습니다.
  • 왜 중요한가: Transformer 블록이 깊게 반복될 때 값의 스케일이 지나치게 흔들리지 않도록 도와, attention과 feed-forward 계산을 더 안정적으로 이어 가게 만들기 때문입니다. 이 개념이 있어야 깊은 층을 쌓을 때 왜 단순 계산 블록만 반복하지 않고 중간에 값 범위를 정돈하는 단계가 필요한지 이해하게 됩니다. 또한 배치 정규화와 달리 시퀀스 길이와 배치 구성 변화에 덜 묶이는 이유를 읽게 되어, 왜 Transformer 계열에서 layer normalization이 자주 등장하는지도 더 자연스럽게 연결됩니다.
  • 함께 볼 개념: 트랜스포머(Transformer), 잔차 연결(residual connection), 피드포워드 네트워크(feed-forward network)
  • 중심 Section: P5-14.1
  • 등장 Section: P5-14.2

레이트 리밋(rate limit)

  • 뜻: 짧은 시간 안에 보낼 수 있는 요청 수나 토큰 수를 제한하는 사용 규칙입니다. 시스템을 무한히 두드릴 수 없도록 정한 운영 한계이며, 서비스 보호와 자원 배분을 위해 두는 속도 상한선에 가깝습니다. 즉 레이트 리밋은 가능한가/불가능한가의 문제가 아니라, 얼마나 자주 호출해도 되는가를 정하는 운영 경계입니다.
  • 왜 중요한가: 서비스 장애처럼 보이는 실패가 실제로는 호출 한도 초과일 수 있어, 재시도와 대기 정책, 요청 설계를 이 제한에 맞춰야 하기 때문입니다. 이 개념이 있어야 모델이 틀렸다는 문제와 너무 자주 불렀다는 문제를 분리해 읽을 수 있고, 처리량을 늘리려는 시도와 허용 한도 사이의 긴장도 함께 이해하게 됩니다. 또한 레이트 리밋을 이해해야 실패 대응이 무조건 재시도가 아니라, 속도 조절과 호출 분산 설계 문제일 수 있다는 점도 읽게 됩니다.
  • 함께 볼 개념: 재시도(retry), 처리량(throughput), 비용(cost), 지연 시간(latency)
  • 중심 Section: P1-14.6
  • 등장 Section: P1-14.5

로그(log)

  • 뜻: 실행 과정에서 나중에 다시 확인할 수 있도록 남기는 기록입니다. 단순 결과 저장만이 아니라, 언제 어떤 입력을 받았고 무엇을 읽었으며 어떤 도구를 어떤 순서로 호출했고 어떤 오류와 응답이 돌아왔는지 되짚게 하는 운영 기록을 뜻합니다. 즉 로그는 시스템이 무슨 일을 했는가를 사후에 복원하게 해 주는 시간 순서의 흔적입니다.
  • 왜 중요한가: 에이전트 실행에서는 최종 답변만으로는 무엇을 근거로 판단했고 어디서 실패했는지 설명하기 어려워, 책임 추적과 재현 검토를 위해 기록이 필요하기 때문입니다. 특히 승인, 권한, 개인정보, 비용 문제를 나중에 점검하려면 로그가 핵심 증거가 됩니다. 이 개념이 있어야 결과만 본다과정을 함께 본다를 분리하게 되고, 품질 문제와 운영 문제를 같은 실행에서 함께 읽을 수 있습니다. 또한 로그를 이해해야 추적 가능성을 높이는 일과 개인정보를 과도하게 남기지 않는 일을 동시에 설계해야 한다는 긴장도 함께 읽게 됩니다.
  • 함께 볼 개념: 추적(trace), 하네스(harness), 재현성(reproducibility), 책임(accountability)
  • 중심 Section: P7-6.2
  • 등장 Section: P1-14.3, P1-14.5, P1-15.3, P7-6.1, P7-7.1, P7-7.2

로지스틱 회귀(logistic regression)

  • 뜻: 선형 계산 결과를 확률처럼 읽히는 점수로 바꾸어 분류 문제를 다루는 선형 모델입니다. 이름에 회귀가 들어가지만, 보통은 연속값 예측보다 어느 범주에 더 가까운가를 판단하는 분류 모델로 배웁니다. 즉 입력 특징을 직선 경계로 나누어 두 범주를 가르는 가장 기본적인 분류기 중 하나라고 볼 수 있습니다.
  • 왜 중요한가: 분류 문제에서 가장 기본적인 출발점이면서, 점수와 임계값(threshold)을 분리해 읽는 감각을 만들어 줍니다. 이 개념이 있어야 모델이 낸 확률 비슷한 점수그 점수를 바탕으로 실제로 어떤 클래스를 선택할지를 다른 개념으로 이해할 수 있습니다. 또한 로지스틱 회귀를 이해해야 단순한 선형 경계 모델이 어디까지 설명력을 가지는지, 더 복잡한 모델이 정말 필요한지 비교하는 기준선도 세울 수 있습니다. 결국 로지스틱 회귀는 간단하지만 해석 가능한 분류 기준선으로 자주 쓰인다는 점이 중요합니다.
  • 함께 볼 개념: 분류(classification), 임계값(threshold), 결정 경계(decision boundary)
  • 중심 Section: P4-11.1
  • 등장 Section: P4-11.2

로컬 환경(local environment)

  • 뜻: 내 컴퓨터 안에서 코드를 실행하기 위해 준비된 프로그램, 파일, 설정의 묶음입니다. 브라우저 너머 원격 런타임이 아니라, 현재 내 장치에 설치된 실행 조건 전체를 뜻합니다. 운영체제, Python 설치 위치, 패키지 상태, 환경 변수, 작업 폴더 같은 요소가 함께 엮여 현재 로컬 환경을 이룬다고 볼 수 있습니다.
  • 왜 중요한가: 같은 Python 코드라도 어느 컴퓨터와 어느 설정에서 실행했는지에 따라 결과와 오류가 달라질 수 있기 때문입니다. Colab 같은 호스팅 환경과 대비해 보면, 설치 자유도가 큰 대신 환경 차이도 더 직접 관리해야 한다는 점이 드러납니다. 예를 들어 브라우저에서는 잘 되던 코드가 로컬에서는 패키지 누락, 경로 차이, Python 버전 차이 때문에 바로 실패할 수 있습니다. 결국 로컬 환경을 이해해야 코드가 틀렸다는 문제와 실행 자리가 다르다는 문제를 분리해 읽게 되고, 설치·가상환경·재현성 점검도 더 체계적으로 따라가게 됩니다.
  • 함께 볼 개념: 실행 환경(runtime), 가상환경(virtual environment), 작업 폴더(working directory)
  • 중심 Section: P2-7.1
  • 등장 Section: P2-7.4, P2-7.5, P2-10.2

로크(loc)

  • 뜻: Pandas에서 행과 열을 라벨 이름 기준으로 고를 때 쓰는 선택 도구입니다. 즉 몇 번째인가보다 어떤 이름표인가를 기준으로 선택하는 방식입니다. 다시 말해 0번째 줄이 아니라 index가 A인 줄, 열 이름이 score인 열처럼 의미 이름으로 접근하는 도구입니다.
  • 왜 중요한가: 표를 읽을 때 몇 번째 위치가 아니라 어떤 이름표를 가진 행과 열을 보고 싶은지 구분해야, 인덱스와 열 이름의 의미를 자연스럽게 살린 선택이 가능하기 때문입니다. loc를 이해해야 DataFrame이 단순 2차원 배열이 아니라 라벨이 붙은 표라는 점이 분명해집니다. 이 개념이 있어야 표를 볼 때 값의 위치보다 행과 열의 의미를 먼저 살리는 선택 습관을 갖게 되고, iloc와의 차이도 더 안정적으로 구분하게 됩니다. 결국 loc어디 있나보다 무슨 이름인가를 먼저 묻는 선택 방식입니다.
  • 함께 볼 개념: 인덱스(index), 열(column), 아이로크(iloc)
  • 중심 Section: P2-12.2
  • 등장 Section: P2-12.3

롱 컨텍스트(long-context)

  • 뜻: 더 긴 입력을 실제로 유지하고, 앞쪽 단서와 뒤쪽 단서를 한 작업 안에서 다시 참고하려는 설계 문제 전체를 가리키는 표현입니다. 단지 토큰 한도를 늘리는 문제가 아니라, 긴 문서 속에서 무엇을 계속 들고 가고 무엇을 요약하거나 버릴지까지 포함한 문맥 관리 문제라고 볼 수 있습니다. 즉 롱 컨텍스트는 길게 넣을 수 있다를 넘어서 길게 넣은 정보를 어떻게 유지하고 활용할 것인가의 문제입니다.
  • 왜 중요한가: 단순히 숫자 큰 context window를 자랑하는 문제가 아니라, 비용·지연 시간·핵심 단서 보존을 함께 다뤄야 하는 실제 서비스 설계 문제라는 점을 드러내기 때문입니다. 이 개념이 있어야 긴 입력을 잘 다루는 능력이 모델 스펙 하나로 닫히지 않고, 검색·요약·메모리 전략과 함께 설계된다는 점을 이해하게 됩니다. 결국 롱 컨텍스트를 이해해야 긴 입력 처리 능력을 창 크기 숫자가 아니라 시스템적 문맥 관리 역량으로 읽게 됩니다.
  • 함께 볼 개념: 문맥 창(context window), 검색 증강 생성(retrieval-augmented generation, RAG), sparse attention
  • 중심 Section: P6-4.3
  • 등장 Section: P5-14.2

리다이렉션(redirection)

  • 뜻: 명령의 출력이 향하는 곳이나 입력을 읽어 오는 곳을 화면 대신 파일 같은 다른 대상으로 바꾸는 표기입니다. 즉 명령 자체보다 결과가 어디로 흐르는가를 바꾸는 셸 문법입니다. 화면에 보이기만 하던 결과를 파일로 저장하거나, 파일 내용을 키보드 입력 대신 명령에 넘길 때 주로 쓰는 흐름 제어 장치라고 볼 수 있습니다.
  • 왜 중요한가: 터미널 명령이 단순히 화면에 결과를 보여 주는지, 아니면 파일을 만들고 덮어쓰고 다른 명령의 입력으로 넘기는지 먼저 읽게 해 주기 때문입니다. 같은 명령어라도 리다이렉션이 붙으면 단순 조회가 아니라 파일 변경이나 입력 경로 변경이 되어 의미가 크게 달라집니다. 이 개념이 있어야 무슨 명령을 썼는가뿐 아니라 결과가 어디로 흘러갔는가까지 함께 해석하게 됩니다. 초심자에게 특히 중요한 이유는, 화면에는 조용해 보여도 실제로는 파일이 바뀌고 있을 수 있다는 점을 읽게 해 주기 때문입니다.
  • 함께 볼 개념: 파이프(pipe), 셸 스크립트(shell script), 환경 변수(environment variable)
  • 중심 Section: P2-7.8
  • 등장 Section: P2-7.9, P2-12.3

리소스(resource)

  • 뜻: 모델이나 앱이 읽을 수 있도록 제공되는 문서, 파일, 레코드, 응답 같은 맥락 데이터입니다. 무엇인가를 실행하는 기능이 아니라, 판단과 생성에 참고할 입력 재료를 제공하는 쪽에 가깝습니다. 쉽게 말해 리소스는 행동 버튼보다는 읽을거리와 참고자료에 가까운 외부 입력 단위입니다.
  • 왜 중요한가: 외부 연결에서 무엇을 실행할 수 있는가무엇을 읽을 수 있는가를 구분해야 RAG, 상태 확인, 도구 실행의 경계를 더 분명히 설명할 수 있기 때문입니다. 이 차이를 알아야 읽기 전용 연결과 상태 변경 연결의 위험을 혼동하지 않게 됩니다. 또한 리소스 개념이 있어야 모델이 내부 파라미터만으로 답한 것과 바깥 자료를 참고해 답한 것을 구분하게 됩니다. 결국 리소스는 모델 성능 자체를 늘리는 장치라기보다, 현재 질문에 맞는 외부 맥락을 안전하게 주입하는 통로라는 점이 핵심입니다.
  • 함께 볼 개념: 도구(tool), 프롬프트(prompt), 모델 컨텍스트 프로토콜(Model Context Protocol, MCP), 검색 증강 생성(retrieval-augmented generation, RAG)
  • 중심 Section: P1-14.4
  • 등장 Section: P1-14.3, P1-14.5

리스트(list)

  • 뜻: 여러 값을 순서대로 담고, 인덱스(index)로 다시 꺼낼 수 있는 선형 자료구조입니다. Python에서는 서로 다른 타입의 값도 함께 넣을 수 있습니다. 즉 리스트는 순서 있는 값 모음을 가장 일반적인 형태로 다루는 기본 그릇입니다.
  • 왜 중요한가: 초심자는 리스트, 벡터, 배열을 쉽게 같은 말로 섞기 때문입니다. 리스트는 우선 순서 있는 값 묶음이라는 프로그래밍 구조를 가리키고, 수치 계산용 배열이나 수학적 벡터는 그다음 층위에서 구분해 읽어야 합니다. 이 개념이 있어야 Python 입문에서 다루는 일반 자료구조와 NumPy가 다루는 계산 구조를 섞지 않게 되고, 같은 대괄호 표기라도 용도와 성질이 다를 수 있다는 점을 이해하게 됩니다. 또한 리스트는 값 추가, 순서 유지, 반복 순회처럼 일반 프로그래밍 작업의 기본 그릇이라는 점도 자연스럽게 붙잡게 됩니다. 나중에 배열이나 텐서를 배울 때도, 리스트를 기준점으로 삼아 어떤 점이 더 계산 특화되어 있는가를 비교하게 됩니다.
  • 함께 볼 개념: 인덱스(index), 딕셔너리(dictionary), 반복(loop)
  • 중심 Section: P2-8.2
  • 등장 Section: P2-8.3, P2-8.4, P2-8.7, P2-9.1

리콰이어먼트 파일(requirements.txt)

  • 뜻: 프로젝트에 필요한 패키지 목록과 버전을 기록하는 대표적인 텍스트 파일입니다. 실행 환경을 그대로 복사하지 않더라도, 어떤 의존성을 다시 설치해야 하는지 적어 두는 설치 명세에 가깝습니다. 즉 소스코드 옆에 놓이는 이 코드를 돌리려면 무엇을 설치해야 하는가에 대한 최소한의 환경 설명서라고 볼 수 있습니다.
  • 왜 중요한가: 가상환경 자체를 통째로 공유하지 않아도, 어떤 패키지를 어떤 버전 범위로 다시 설치해야 하는지 전달하는 출발점이 되기 때문입니다. 재현성은 코드 파일만으로 생기지 않고, 이런 의존성 기록이 함께 있어야 가까워집니다. 이 개념이 있어야 코드는 같은데 왜 실행 결과가 다르지라는 질문을 코드 논리뿐 아니라 패키지 버전과 설치 상태 문제로도 나누어 보게 됩니다. 협업에서도 내 컴퓨터에서는 된다를 줄이려면 코드와 함께 이런 설치 명세가 남아 있어야 한다는 점이 핵심입니다.
  • 함께 볼 개념: 의존성(dependency), 버전 고정(version pinning), 재현성(reproducibility)
  • 중심 Section: P2-7.5
  • 등장 Section: P2-7.7