뜻: 답만 바로 내게 하기보다, 중간 단계 reasoning을 더 분명하게 드러내도록 유도하는 프롬프트 전략입니다. 즉 최종 답 하나만 요구하는 대신, 결론에 이르는 중간 판단 흐름을 함께 끌어내려는 접근입니다. 사람이 풀이 과정을 적어 보듯, 모델에도 중간 추론 경로를 더 명시적으로 드러내게 하는 방식이라고 볼 수 있습니다.
왜 중요한가: 조건이 많은 추론 문제에서 어떤 기준을 따라 결론에 도달했는지 더 읽기 쉽게 만들어, 출력 경로를 점검하는 데 도움을 줍니다. 다만 reasoning을 드러낸다고 해서 사실성이 자동 보장되는 것은 아니라는 점도 함께 이해하게 해 줍니다. 이 개념이 있어야 답을 맞혔다와 어떻게 그 답에 도달했는가를 분리해 읽게 되고, 중간 경로 점검이 필요한 문제와 외부 근거 검증이 필요한 문제를 같은 것으로 섞지 않게 됩니다. 또한 CoT를 이해해야 설명이 길어졌다는 사실과 실제 추론 품질이 좋아졌다는 사실을 별도로 점검하게 됩니다.
함께 볼 개념: 프롬프트 엔지니어링(prompt engineering), self-consistency, 정렬(alignment)
뜻: 많은 설명 축을 가진 데이터를 더 적은 축으로 옮겨 보면서 중요한 구조를 최대한 유지하려는 방법입니다. 즉 원래 데이터의 모든 숫자를 그대로 보존하기보다, 거리 관계나 분산 구조 같은 핵심 모양을 덜 복잡한 좌표계에 압축하는 접근입니다. 다시 말해 차원 축소는 정보를 버린다보다 사람과 모델이 더 읽기 쉬운 축으로 다시 펼친다는 쪽에 가깝습니다.
왜 중요한가: 복잡한 고차원 데이터는 사람이 직접 보기 어렵기 때문에, 시각화하거나 요약하려면 더 단순한 표현이 필요합니다. 차원 축소 개념이 있어야 정보를 일부 줄이더라도 구조를 더 잘 보이게 만든다는 판단을 이해할 수 있고, 임베딩 시각화와 군집 해석도 더 자연스럽게 읽을 수 있습니다. 또한 차원 축소를 이해해야 축을 줄인 그림이 곧 원본 데이터 전체를 완벽히 보여 주는 것은 아니라는 점도 함께 읽게 됩니다.
함께 볼 개념: 비지도학습(unsupervised learning), 차원(dimension), 표현(representation)
뜻: 벡터가 가진 값의 개수 또는 좌표 축의 수를 가리키는 표현입니다. 점 하나를 선 위에 놓으면 1차원, 평면 위에 놓으면 2차원, 값이 아주 많아지면 고차원 벡터가 되듯이, 몇 개의 독립된 방향이나 자리로 대상을 표현하는가를 세는 말에 가깝습니다. 즉 차원은 데이터가 얼마나 많은 축 위에서 표현되는지를 말하는 구조 언어입니다.
왜 중요한가: 벡터와 행렬의 모양을 읽고 어떤 비교와 계산이 가능한지 판단하는 기준이 되기 때문입니다. 이 개념이 있어야 이미지, 임베딩, 표 데이터가 각각 몇 축과 몇 특징으로 표현되는지 읽을 수 있고, 차원이 커질수록 시각화와 검색이 왜 어려워지는지도 자연스럽게 이어집니다. 또한 차원을 이해해야 값이 많다는 사실과 표현 축이 많다는 사실을 구분하고, 고차원 문제에서 직관이 왜 쉽게 깨지는지도 함께 읽게 됩니다. 결국 차원은 데이터가 얼마나 큰가보다 데이터가 몇 개의 표현 축 위에 놓여 있는가를 읽게 하는 말입니다.
뜻: 둘 이상의 이름이 같은 객체를 함께 가리키는 상태입니다. 값이 두 개 복제된 것이 아니라, 같은 대상을 여러 이름표가 함께 보고 있는 상황입니다. 즉 변수 이름이 하나 더 생겼다고 해서 데이터가 자동으로 복제되는 것은 아니라는 점을 보여 주는 개념입니다. 말하자면 참조는 복사본이 늘어난 것이 아니라 같은 원본을 보는 창이 늘어난 것에 가깝습니다.
왜 중요한가: 리스트나 딕셔너리를 한쪽에서 바꿨을 때 다른 이름으로 본 결과도 함께 바뀌는 이유를 읽는 기준이 되기 때문입니다. 참조 개념이 있어야 대입, 얕은 복사, 깊은 복사의 차이를 자연스럽게 설명할 수 있습니다. 또한 참조를 이해해야 값을 바꿨다와 같은 객체를 다른 이름으로 보고 있었다를 구분하게 되어, 파이썬에서 생기는 많은 변경 버그를 더 정확히 해석하게 됩니다. 결국 참조를 이해해야 변경이 값 자체의 변화인지 같은 객체 공유의 결과인지 분리해 읽게 됩니다.
함께 볼 개념: 대입(assignment), 얕은 복사(shallow copy), 객체(object)
뜻: AI 출력이나 자동화 결과가 문제를 일으켰을 때 누가 검토했고 누가 설명하고 누가 수정할 책임이 있는지 분명히 하는 원칙입니다. 모델이 그랬다로 끝내지 않고, 시스템 설계와 운영의 책임 주체를 남기는 관점이라고 볼 수 있습니다. 더 넓게는 설계, 데이터 선택, 검토, 승인, 배포, 사후 대응의 각 단계에서 누가 어떤 판단을 맡았는지 추적 가능하게 두는 기준이기도 합니다.
왜 중요한가: 생성형 AI의 결과는 자연스럽게 보일 수 있어도, 고위험 사용 맥락에서는 책임 주체와 검토 절차가 없으면 피해를 막기 어렵기 때문입니다. 책임 구조가 있어야 로그, 승인, 검토 기록도 실제 의미를 갖습니다. 이 개념이 있어야 문제가 생겼을 때 단순히 사람을 탓하는 데서 멈추지 않고, 어떤 통제와 기록이 빠졌는지까지 함께 다시 보게 됩니다. 결국 책임은 사후 비난용 장치가 아니라, 사전에 역할과 검토 구조를 분명히 만드는 설계 원칙이기도 합니다.
함께 볼 개념: 인간 감독(human oversight), 디지털 안전성(safety), 검토(review), 로그(log)
뜻: 일정 시간 동안 시스템이 처리할 수 있는 요청, 토큰, 작업의 양입니다. 하나를 얼마나 빨리 끝내는가보다 단위 시간에 전체를 얼마나 많이 흘려보내는가에 초점을 둔 지표이며, 서비스가 몰릴 때 얼마나 버틸 수 있는지를 읽는 기준에 가깝습니다. 즉 처리량은 개별 요청의 체감 속도보다, 시스템 전체가 얼마나 많은 일을 소화하는지 보는 숫자입니다.
왜 중요한가: 한 요청을 잘 처리하는 것과 많은 요청을 동시에 감당하는 것은 다른 문제입니다. 지연 시간이 낮아도 전체 처리량이 낮으면 사용자가 몰릴 때 서비스가 버거워질 수 있으므로, 시스템 성능은 개별 응답 속도와 전체 처리 능력을 따로 봐야 합니다. 이 개념이 있어야 배치 처리, 캐싱, 호출 제한 같은 전략이 왜 종종 처리량 개선을 목표로 논의되는지도 더 자연스럽게 연결됩니다. 결국 처리량을 이해해야 서비스 성능을 한 명이 얼마나 빨리 받는가와 모두가 합쳐 얼마나 많이 처리되는가로 나누어 읽게 됩니다.
함께 볼 개념: 지연 시간(latency), 레이트 리밋(rate limit), 배치(batch), 캐싱(caching)
뜻: 긴 문서나 긴 텍스트를 검색과 비교에 쓰기 좋게 더 작은 문단 단위나 조각으로 나눈 묶음입니다. 보통 한 문서 전체를 통째로 다루기보다, 질문과 직접 닿을 만한 부분을 더 잘 찾도록 쪼갠 검색 단위라고 볼 수 있습니다. 즉 청크는 문서를 잘라 버리는 일이 아니라, 검색 가능한 단위로 다시 포장하는 작업입니다.
왜 중요한가: 문서 전체를 한 번에 임베딩하면 질문과 직접 관련된 부분을 놓치거나, 너무 넓은 문맥이 한 벡터에 섞일 수 있습니다. 그래서 실제 검색과 RAG에서는 얼마나 크게 자를지, 어떻게 겹치게 자를지가 검색 품질과 근거 회수 품질을 함께 좌우합니다. 너무 작게 자르면 맥락이 잘려 의미가 약해지고, 너무 크게 자르면 잡음이 섞여 관련 문단을 끌어올리기 어려워질 수 있다는 점도 핵심입니다. 결국 청크를 이해해야 RAG 품질이 임베딩 모델만이 아니라 문서를 어떤 단위로 쪼개는지에도 크게 달려 있다는 점을 읽게 됩니다.
함께 볼 개념: 임베딩(embedding), 문서(document), 검색 증강 생성(retrieval-augmented generation, RAG)
중심 Section: P1-13.1
등장 Section: P1-13.2, P1-13.3, P1-14.2, P6-12.1, P6-12.2
뜻: 학습을 시작하기 전에 가중치와 같은 파라미터를 어떤 값으로 배치할지 정하는 단계입니다. 완전히 비슷한 값으로 둘지, 분산을 어느 정도로 줄지처럼 학습 출발점의 숫자 지형을 미리 세팅하는 과정이라고 볼 수 있습니다. 즉 초기화는 학습 전에 어디서 출발할 것인가를 정하는 숫자 배치 단계입니다.
왜 중요한가: 출발점이 너무 같거나 너무 극단적이면 여러 뉴런이 같은 역할로 묶이거나 값과 gradient 흐름이 흔들려, 깊은 네트워크가 제대로 학습을 시작하기 어려울 수 있기 때문입니다. 이 개념이 있어야 학습 실패가 항상 데이터나 모델 구조 탓만은 아니고, 출발점 설정에서도 이미 크게 갈릴 수 있다는 점을 이해하게 됩니다. 또한 초기화를 이해해야 학습은 완전히 빈 상태에서 자동으로 잘 시작되는 것이 아니라, 시작 숫자 배치 자체도 중요한 설계 선택이라는 점을 읽게 됩니다.
함께 볼 개념: 수치 안정성(numerical stability), 가중치(weight), 역전파(backpropagation)
뜻: 질문 벡터나 기준 벡터와 가장 가깝게 위치한 후보입니다. 여기서 가깝다는 말은 보통 거리나 유사도 기준에 따라 계산된 가까움이지, 사람이 눈으로 보기 비슷하다는 뜻만은 아닙니다. 다시 말해 최근접 이웃은 이 입력과 가장 닮은 예시는 무엇인가를 수치 비교로 정한 결과입니다.
왜 중요한가: 유사도 검색이 모든 문서를 읽는 것이 아니라, 먼저 가장 가까운 관련 후보부터 고르는 과정이라는 점을 이해하게 해 줍니다. 이 개념이 있어야 검색과 분류에서 무엇을 근거 사례로 삼는가를 설명할 수 있고, 거리 기준을 바꾸면 결과가 왜 달라지는지도 읽을 수 있습니다. 또한 최근접 이웃을 이해해야 복잡한 규칙을 직접 세우지 않아도, 이미 있는 사례 가운데 가까운 것들을 근거로 새 입력을 해석하는 방식이 가능하다는 점도 자연스럽게 보게 됩니다. 더 나아가 전처리나 정규화가 바뀌면 가장 가까운 후보 자체가 달라질 수 있으므로, 최근접 이웃은 단순 결과가 아니라 입력 표현의 영향을 직접 드러내는 관찰 창이 되기도 합니다.
함께 볼 개념: 유사도 검색(similarity search), 거리(distance), 상위 k개(top-k)
뜻: 사람이나 에이전트나 도구가 현재 작업에 꼭 필요한 범위까지만 접근 권한을 갖도록 제한하는 보안 원칙입니다. 할 수 있으면 편하다가 아니라 꼭 필요한가를 먼저 묻는 원칙이며, 읽기와 쓰기, 내부와 외부 전송, 특정 폴더와 전체 시스템 접근을 세밀하게 나누어 여는 방식과 연결됩니다. 즉 최소 권한은 자동화를 막자는 말이 아니라, 피해가 커질 수 있는 범위를 처음부터 좁혀 두자는 설계 원칙입니다.
왜 중요한가: 생성형 AI 시스템은 검색, 파일 수정, 네트워크 호출, 배포처럼 실제 상태를 바꾸는 도구와 연결되기 쉬워, 넓은 권한 하나가 작은 실수를 큰 사고로 번지게 만들 수 있기 때문입니다. 이 개념이 있어야 권한이 있다와 지금 이 작업에 필요한 권한만 있다를 구분하게 되고, 승인 절차와 실행 범위 제한이 왜 함께 필요해지는지도 이해하게 됩니다. 또한 최소 권한을 이해해야 보안은 모델 출력 품질보다 먼저 시스템 행동 범위를 줄이는 설계 문제라는 점, 그리고 프롬프트 인젝션 같은 공격이 일어나도 피해 규모를 줄이는 마지막 방어선이 권한 제한이라는 점도 더 분명히 읽게 됩니다.
함께 볼 개념: 권한(permission), 승인(approval), 보안(security), 에이전트(agent), 도구 사용(tool use)
뜻: 어떤 정보가 지금 시점에도 여전히 유효한지, 최근 변화가 반영되어 있는지를 보는 기준입니다. 과거에는 사실이었던 정보라도 현재 기준에서는 이미 바뀌었을 수 있다는 시간 축 점검을 뜻하며, 내용 자체의 정확성과는 다른 종류의 확인입니다. 즉 최신성은 문장의 사실 여부만이 아니라, 그 사실이 어느 시점 기준의 사실인지를 함께 묻는 질문입니다.
왜 중요한가: 제품 기능, 가격, 정책, 법률, 모델 사양처럼 바뀔 수 있는 정보는 사실성만으로 충분하지 않고 시점 검토가 함께 필요하기 때문입니다. 그래서 최신성은 맞는 말인가와 별개로 지금도 맞는 말인가를 묻는 기준이며, 검색 결과를 붙였더라도 문서 날짜와 확인 시점을 함께 읽어야 하는 이유를 설명해 줍니다. 이 개념이 있어야 오래된 정답을 현재 정답으로 오인하는 문제를 따로 보게 되고, 검색·출처 확인이 끝나도 마지막에 날짜를 다시 확인해야 하는 이유를 더 분명히 이해하게 됩니다.
함께 볼 개념: 사실성(factuality), 근거(evidence), 평가(evaluation), 출처 추적(provenance), 검색(search)
뜻: 여러 후보 가운데 기준과 제약을 고려해 더 나은 값을 찾는 문제입니다. 꼭 수학적으로 완벽한 정답 하나를 닫는 일만 뜻하지는 않고, 현재 목적 함수(objective function)를 더 좋게 만드는 방향으로 값을 조정해 가는 과정 전체를 가리키기도 합니다.
왜 중요한가: 학습을 정답 암기가 아니라 손실을 줄이는 값 탐색 과정으로 읽게 해 주기 때문입니다. 이 개념이 있어야 모델 학습, 경로 탐색, 자원 배분처럼 겉모습이 다른 문제들도 무엇을 좋다고 보고, 어떤 제약 아래서, 어떤 값을 조정하는가라는 공통 틀로 읽을 수 있습니다. 또한 최적화는 정답을 바로 계산한다보다 더 나은 쪽으로 점진적으로 이동한다는 사고를 요구하므로, 학습이 왜 반복 절차로 표현되는지도 함께 이해하게 됩니다. 결국 최적화는 모델이 어떻게 좋아지는가를 설명하는 가장 넓은 행동 틀입니다.
함께 볼 개념: 목적 함수(objective function), 경사하강법(gradient descent), 제약(constraint)
뜻: 실행은 끝났지만 확신 차이가 낮거나, 오분류이거나, coverage가 낮아 다음 반복에서 먼저 다시 봐야 한다고 별도로 표시해 둔 샘플입니다. 단순 오답 전체와 달리, 지금 당장 구조 변경이나 데이터 보강 판단에 더 직접적인 단서를 줄 것 같은 사례를 따로 고정한 표지라고 볼 수 있습니다. 즉 추가 검토 샘플은 나중에 다시 보자가 아니라 다음 반복의 첫 재검토 후보를 문서 안에 명시한 기록입니다.
왜 중요한가: 모든 실패 샘플을 같은 강도로 다시 볼 수는 없으므로, 실제로 어떤 샘플이 다음 조치와 가장 직접 연결되는지를 따로 남겨 두어야 회고와 개선 계획이 흐려지지 않기 때문입니다. 이 개념이 있어야 단순 오답 목록과 우선 재검토 대상이 구분되고, 샘플별 비교표와 평가 기록도 무엇을 먼저 다시 볼 것인가라는 실제 작업 순서 위에서 다시 읽게 됩니다. 또한 추가 검토 샘플을 이해해야 Part 7의 실행 요약이 점수 보관이 아니라 다음 질문을 여는 작업 메모라는 점도 더 선명하게 읽게 됩니다.
함께 볼 개념: 검토 대상(review target), 평가 기록(evaluation record), 실행 요약(execution summary), 오류 사례(error case), 우선순위(priority)
뜻: 현재 사실에 맞는 규칙을 찾아 적용하는 장치입니다. 단순히 규칙을 저장해 두는 것이 아니라, 지금 어떤 사실이 참인가, 다음에 어떤 규칙을 적용할 수 있는가를 순서대로 따지며 결론을 만들어 가는 실행 장치라고 볼 수 있습니다. 즉 추론 엔진은 규칙을 읽어 두는 곳이 아니라, 규칙을 실제 결론 생성 절차로 움직이는 부분입니다.
왜 중요한가: 규칙 기반 시스템이 단순 규칙 목록이 아니라 적용 절차를 가진 시스템임을 보여 줍니다. 같은 규칙 집합이라도 어떤 사실부터 보고 어떤 규칙을 먼저 적용하느냐에 따라 결론 경로가 달라질 수 있어, 지식 표현과 실행 절차를 함께 이해하게 해 주는 핵심 개념입니다. 이 개념이 있어야 지식 기반은 저장소이고, 추론 엔진은 그 저장소를 실제로 움직이는 실행기라는 역할 차이도 분명해집니다. 결국 추론 엔진을 이해해야 규칙 기반 AI에서 무엇을 안다와 어떻게 결론에 도달한다를 분리해 읽게 됩니다.
뜻: 문맥에 따라 두 뜻으로 쓰입니다. 기호 기반 AI에서는 주어진 지식에서 결론을 이끌어 내는 과정이고, 머신러닝에서는 학습된 모델을 새 입력에 실행해 출력을 얻는 과정일 수 있습니다. 한국어로는 둘 다 추론이라 부르지만, 영어로는 reasoning에 가까운 경우와 model inference에 가까운 경우를 나누어 읽어야 합니다.
왜 중요한가: 같은 한국어 표현이 서로 다른 영어 문맥을 가리킬 수 있어 혼동을 줄여야 합니다. 이 차이를 놓치면 모델이 추론한다는 말을 논리적 사고 과정과 실행 단계로 뒤섞어 이해하게 됩니다. 이 개념이 있어야 문서나 강의에서 추론이 나왔을 때 지금 말하는 것이 규칙 적용인지, 학습된 모델 실행인지, 생성 단계인지 먼저 구분하게 됩니다. 결국 추론은 번역어 하나만 보고 넘기기보다, 문맥과 영어 원어를 함께 확인해야 하는 대표적인 용어입니다.
함께 볼 개념: 추론 엔진(inference engine), 학습(training), 예측(prediction), 생성(generation)
중심 Section: P1-5.3
등장 Section: P1-2.1, P1-3.2, P1-5.2, P5-6.1, P5-6.3
뜻: 데이터를 어떻게 저장하는지보다 어떤 연산을 제공해야 하는지를 기준으로 정의한 개념적 구조입니다. 즉 내부에 배열을 썼는지 연결 구조를 썼는지보다, 넣기, 빼기, 맨 앞 보기 같은 동작 약속이 먼저인 자료 개념이라고 볼 수 있습니다.
왜 중요한가: 스택, 큐처럼 동작 규칙과 실제 구현 방식을 구분해야 자료구조 이름을 더 정확하게 읽을 수 있기 때문입니다. 이 개념이 있어야 무엇을 할 수 있어야 하는가와 어떻게 저장했는가를 분리해 읽게 되고, 같은 추상 자료형이 배열이나 연결 리스트처럼 여러 구현으로 실현될 수 있다는 점도 자연스럽게 이해하게 됩니다. 또한 추상 자료형을 이해해야 API 설계와 내부 구현을 분리하는 기본 감각도 함께 생겨, 겉에서 보이는 사용 규칙과 안쪽 구현 최적화를 다른 개념으로 다루게 됩니다. 결국 추상 자료형은 사용 약속을 먼저 정하고 구현 방법은 나중에 선택하는 사고방식을 붙잡게 합니다.
함께 볼 개념: 자료구조(data structure), 연산(operation), 구현(implementation)
뜻: 하나의 요청이 어떤 단계들을 거쳐 처리되었는지 순서와 연결 관계를 따라 남기는 기록입니다. 단일 로그 한 줄이 아니라, 한 요청 안에서 여러 호출과 하위 작업이 어떻게 이어졌는지를 묶어 보여 주는 실행 흐름 기록이며, 무슨 일이 있었는가보다 어떤 흐름으로 이어졌는가를 보는 데 더 가깝습니다. 즉 추적은 낱개 사건 목록보다, 모델 호출과 검색과 도구 실행과 사람 개입이 어떻게 한 줄기의 요청 경로를 이루었는지 복원하는 지도에 가깝습니다.
왜 중요한가: 최종 결과만으로는 모델 호출, 검색, 도구 실행, 오류가 어디서 발생했는지 구분하기 어렵습니다. 추적이 있어야 에이전트 실행을 단계별로 다시 읽고, 어느 단계에서 지연이 커졌는지, 어떤 호출이 실패했는지, 어떤 하위 작업이 전체 결과를 흔들었는지 더 정확히 분석할 수 있습니다. 이 개념이 있어야 로그가 낱개 사건 기록이라면, 추적은 그 사건들을 요청 단위 흐름으로 묶는 기록이라는 차이도 더 분명해집니다. 또한 추적을 이해해야 출력 오류를 단순 모델 성능 문제로만 보지 않고, 검색 실패, 잘못된 도구 선택, 승인 대기, 재시도 반복 같은 흐름 문제로도 분해해서 읽게 됩니다.
함께 볼 개념: 로그(log), 관찰(observation), 하네스(harness), 요청 실행 기록(run record)
뜻: 표본으로 모집단의 값이나 성질을 조심스럽게 짐작하는 일입니다. 즉 지금 손에 든 일부 데이터를 바탕으로, 전체가 어떨지를 수치나 규칙으로 가늠하는 과정입니다. 직접 전체를 다 볼 수 없기 때문에, 현재 관측에서 얻은 신호를 근거로 가장 그럴듯한 값을 세우는 판단 절차라고 볼 수 있습니다.
왜 중요한가: 우리가 가진 데이터와 점수는 현실 전체를 직접 본 결과가 아니라 일부 표본에서 계산한 근사치라는 점을 잊지 않게 해 주기 때문입니다. 이 감각이 있어야 현재 데이터셋 점수와 실제 환경 전체 성능을 구분하게 되고, 표본이 바뀌면 평균과 성능 평가도 흔들릴 수 있다는 점을 더 자연스럽게 받아들이게 됩니다. 예를 들어 테스트셋 정확도 92%는 항상 92%라는 확정 진실이 아니라, 지금 가진 표본에서 그렇게 보였다는 추정 결과입니다. 결국 추정 개념이 있어야 숫자를 결과 그 자체가 아니라, 오차와 불확실성을 가진 판단 근거로 읽게 됩니다.
뜻: 사용자, 항목, 맥락 정보를 바탕으로 지금 보여 주거나 제안할 후보를 고르는 문제 유형입니다. 핵심은 맞다/틀리다 하나를 고르는 것이 아니라, 여러 후보를 어떤 순서와 근거로 내놓을지를 정하는 데 있습니다. 따라서 추천은 정답 하나 찾기보다 지금 이 사람에게 어떤 후보 묶음이 더 적절한가를 판단하는 문제에 가깝습니다.
왜 중요한가: 분류처럼 하나의 정답 범주를 맞히는 문제와 달리, 추천은 보통 상위 몇 개를 어떤 순서로 먼저 보여 줄 것인가를 다루기 때문입니다. 이 차이를 이해해야 검색, 추천, 광고, 피드 정렬이 비슷해 보여도 서로 다른 평가 기준과 사용자 경험 문제를 가진다는 점을 읽을 수 있습니다. 또한 추천은 보통 사용자가 무엇을 좋아할까를 예측하는 문제와 무엇을 먼저 노출할까를 결정하는 문제를 함께 품고 있어, 예측과 순위화가 결합된 구조로 읽는 감각을 만들어 줍니다. 같은 항목 집합이라도 어떤 사용자를 기준으로, 어떤 시점에, 어떤 목표로 보여 주느냐에 따라 추천 결과가 달라진다는 점을 이해하는 출발점이기도 합니다.
함께 볼 개념: 순위화(ranking), 생성(generation), 예측(prediction)
뜻: 배열 계산이 어느 방향을 따라 진행되는지 정하는 기준 축입니다. 몇 번째 축을 기준으로 본다는 말은 그 방향으로 값을 모으거나 나누거나 선택한다는 뜻입니다. 즉 축은 단순 번호가 아니라, 현재 배열에서 어느 방향을 샘플로 보고 어느 방향을 특징이나 열로 볼 것인가를 정하는 읽기 기준입니다.
왜 중요한가: 같은 합계 계산도 어느 축을 줄이는지에 따라 결과 shape가 바뀝니다. 축 감각이 없으면 행과 열, 배치와 특징, 샘플과 채널을 섞어 읽기 쉬워서 배열 계산 해석이 무너집니다. 이 개념이 있어야 무엇을 남기고 무엇을 줄였는가를 계산 결과와 함께 읽게 됩니다. 예를 들어 axis=0 평균과 axis=1 평균은 같은 숫자 계산이 아니라, 서로 다른 방향의 정보를 요약하는 일입니다. 결국 축을 이해해야 배열 계산을 문법 암기가 아니라 어느 방향을 기준으로 읽고 있는가의 문제로 해석하게 됩니다.
뜻: 계산 결과를 비교 리포트, 검토 후보 큐, 목표 라벨 후보처럼 어떤 형식의 문제 결과로 내보낼지 정한 설계상의 결과 틀입니다. 즉 정답이 무엇인가만이 아니라 결과를 어떤 그릇에 담아 누가 다음에 쓸 것인가를 함께 정하는 층위입니다. 숫자 하나를 바로 내보낼지, 사람이 읽을 비교 표로 바꿀지, 후속 모델 학습에 넣을 후보 묶음으로 저장할지는 모두 출력 구조 선택에 해당합니다. Part 7의 프로젝트 글쓰기에서는 실행 요약, 비교표, 결과 해석 표, 틀린 사례 목록을 어떤 순서로 남길지도 이 출력 구조 설계에 포함됩니다.
왜 중요한가: 같은 원천데이터라도 결과를 무엇이 달라졌는지 보여 주는 비교 표로 끝낼지, 사람이 먼저 볼 대상을 고르는 검토 구조로 바꿀지, 나중에 학습할 목표 후보로 올릴지에 따라 데이터셋 설계 전체가 달라지기 때문입니다. 출력 구조를 먼저 정해야 검토 절차와 자동화 단계도 함께 설계할 수 있습니다. 이 개념이 있어야 무슨 답을 낼 것인가와 그 답을 어떤 작업 흐름에 맞는 형식으로 내보낼 것인가를 분리해 생각하게 되고, 예측 문제와 업무 산출물 설계를 같은 말로 섞어 보지 않게 됩니다. 또한 출력 구조를 이해해야 Part 7의 문서가 긴 로그 복사가 아니라, 질문에 맞는 실행 장면과 해석 단위를 골라 남긴 기록이라는 점도 더 또렷하게 읽게 됩니다.
함께 볼 개념: 비교 리포트(comparison report), 타깃(target), 샘플(sample), 문제 정의(task definition)
뜻: 답을 표, 목록, JSON, 문단, 단계별 설명처럼 어떤 모양으로 돌려받을지 정하는 조건입니다. 핵심 내용 자체와는 별개로, 결과를 사람이 읽기 좋게 받을지 기계가 다시 처리하기 좋게 받을지를 정하는 인터페이스 조건이라고 볼 수 있습니다. 즉 출력 형식은 무슨 내용을 낼까보다 그 내용을 어떤 껍데기로 내보낼까를 정하는 층입니다.
왜 중요한가: 같은 내용이라도 결과를 어떻게 받느냐에 따라 후처리, 검토, 재사용 가능성이 크게 달라지므로 프롬프트 설계의 중요한 축이 됩니다. 이 개념이 있어야 무엇을 답할 것인가와 어떤 구조로 돌려줄 것인가를 분리해 설계할 수 있습니다. 또한 출력 형식을 이해해야 내용 품질이 충분해도 형식이 맞지 않으면 자동화 파이프라인이나 검토 절차 전체가 흔들릴 수 있다는 점도 자연스럽게 보게 됩니다. 결국 출력 형식은 내용의 옳고 그름과 별도로 결과를 어떻게 소비할 것인가를 정하는 인터페이스 조건입니다.
함께 볼 개념: 프롬프트(prompt), 제약(constraint), 지시(instruction)
뜻: 모델이 내야 하는 결과입니다. 숫자 하나일 수도 있고, 범주 하나일 수도 있고, 문장·리포트·후보 목록처럼 더 복잡한 형식일 수도 있습니다. 핵심은 출력이 단순히 마지막에 보이는 답이 아니라, 문제를 어떤 형태로 풀기로 했는지 드러내는 설계 선택이라는 점입니다.
왜 중요한가: 같은 현실 문제도 어떤 출력을 정의하느냐에 따라 전혀 다른 모델링 과제가 되기 때문입니다. 결국 문제 정의는 무엇을 입력으로 보고 무엇을 출력으로 받을 것인가를 정하는 일과 거의 같은 의미가 됩니다. 이 개념이 있어야 같은 데이터를 두고도 분류, 회귀, 요약, 추천, 비교 리포트 생성처럼 전혀 다른 과업이 생길 수 있다는 점을 이해하게 되고, 평가 기준도 출력 정의에 따라 함께 바뀐다는 점이 더 분명해집니다. 예를 들어 고객 문의 데이터를 두고도 카테고리 하나를 고르는가, 답변 초안을 쓰는가, 우선 검토할 후보 목록을 만드는가에 따라 필요한 모델과 검토 절차는 완전히 달라집니다. 결국 출력을 이해해야 모델 성능 논의보다 먼저 우리가 무엇을 결과로 받을 것인가를 설계해야 한다는 점을 붙잡게 됩니다.
함께 볼 개념: 입력(input), 라벨(label), 모델(model), 출력 구조(output structure), 문제 정의(task definition)
중심 Section: P1-4.2
등장 Section: P1-8.1, P1-10.1, P1-14.1, P1-14.3, P1-14.5, P1-15.3
뜻: 현재 답변이나 생성 결과가 어떤 문서와 어떤 조각을 참고했는지 다시 따라갈 수 있게 남기는 출처 정보입니다. 단순 링크 모음이 아니라, 이 결과가 어떤 근거 경로를 거쳐 나왔고 어떤 자료 조각이 실제 판단에 쓰였는지를 되짚게 하는 연결 기록에 가깝습니다. 즉 출처 추적은 무엇을 봤는가만 적는 일이 아니라, 무엇을 실제로 근거로 삼았는가를 다시 복원할 수 있게 남기는 작업입니다.
왜 중요한가: RAG에서 문서를 붙였다고 끝나는 것이 아니라, 실제로 어떤 근거를 사용했는지 확인해야 검토와 책임 추적이 가능해지기 때문입니다. 출처 추적이 있어야 최신성 확인과 오류 수정도 더 빨라지고, 나중에 같은 답변이 왜 나왔는지 설명하거나 잘못된 근거를 교체하는 작업도 더 쉬워집니다. 이 개념이 있어야 단순 참고 링크와 실제 판단에 쓰인 근거 경로를 구분하게 되고, 답변 재검토도 훨씬 구체적으로 진행할 수 있습니다. 또한 출처 추적을 이해해야 문서를 검색했다는 사실과 그 문서의 어느 부분이 결론을 바꾸었는가를 अलग개념으로 읽게 되고, 책임 있는 AI 사용에서 로그, 검토, 최신성 확인이 왜 출처 정보와 함께 움직여야 하는지도 더 선명해집니다.
함께 볼 개념: 근거(evidence), 검색 증강 생성(retrieval-augmented generation, RAG), 검토(review), 로그(log), 최신성(recency)
뜻: 제한된 시간과 자원 안에서 실제로 쓰기에는 충분하다고 판단하는 해답입니다. 수학적으로 가장 좋은 값임이 증명된 해라기보다, 현재 목적과 비용을 함께 놓고 볼 때 더 탐색을 계속하지 않아도 된다고 결정한 실용적 답에 가깝습니다. 즉 완벽하진 않아도 지금 의사결정에 쓸 만큼 괜찮다는 종료선을 붙인 해답입니다.
왜 중요한가: 모든 문제에서 최적해만 기다릴 수는 없다는 점을 보여 주며, 휴리스틱이 현실 문제에서 왜 자주 쓰이는지 이해하게 해 주기 때문입니다. 이 개념이 있어야 정확도 100%나 전역 최적해를 못 얻었다고 해서 항상 실패는 아니라는 점, 그리고 실제 시스템 설계가 시간·비용·품질의 절충 위에서 돌아간다는 점을 읽을 수 있습니다. 또한 충분히 좋은 해를 이해해야 검색, 추천, 에이전트 실행에서 왜 빠른 응답과 적절한 품질이 종종 절대 최적성보다 더 중요한지 더 분명하게 설명하게 됩니다.
함께 볼 개념: 휴리스틱(heuristic), 완전 탐색(exhaustive search), 최적화(optimization)