MCP(Model Context Protocol)는 LLM 애플리케이션을 외부 데이터와 도구에 잇는 공개 프로토콜이다. 2024년 11월 Anthropic이 공개한 뒤 개정을 거듭해, 현재판은 2026-07-28 개정판 이다. 공식 명세를 기준으로 구조와 바뀐 점을 정리했다. 들어가며: 명세가 말하는 MCP 명세 는 MCP를 애플리케이션이 언어 모델에 맥락을 건네고, AI 시스템에 도구와 기능을 내보이고, 조합 가능한 통합을 만드는 표준 방법이라고 소개한다. 여러 개발 도구에 프로그래밍 언어 지원을 붙이는 방식을 표준화한 Language Server Protocol(LSP)에서 영감을 받았다고 밝힌다. 메시지는 JSON-RPC 2.0(JSON으로 메서드 호출과 응답을 주고받는 규약) 형식이고 세 역할이 있다. 호스트 : 연결을 시작하는 LLM 애플리케이션 클라이언트 : 호스트 안의 커넥터 서버 : 맥락과 기능을 제공하는 서비스 1부. 무엇을 주고받나 서버는 세 가지 기능을 클라이언트에게 제공할 수 있다. 리소스 : 사용자나 AI 모델이 쓰는 맥락과 데이터 프롬프트 : 사용자를 위한 템플릿 메시지와 작업 흐름 도구 : AI 모델이 실행하는 함수 클라이언트는 서버에게 엘리시테이션 (elicitation)을 제공할 수 있다. 서버가 사용자에게 추가 정보를 묻는 기능이다. 이 밖에 설정, 진행 상황 추적, 취소, 오류 보고 같은 보조 기능이 있다. 핵심 프로토콜 바깥에는 선택 확장이 있다. 확장은 클라이언트와 서버가 모두 명시적으로 지원해야 쓸 수 있다. 명세가 대표로 드는 것은 오래 걸리는 작업을 비동기로 처리하는 Tasks, 대화 안에 차트나 양식 같은 UI를 띄우는 MCP Apps, 작업 흐름 지시를 MCP로 주고받는 Skills over MCP다. 2부. 어떻게 실어 나르나 전송 방식 은 메시지를 어떻게 나누고 전달하는지만 정하고, 메시지의 뜻은 정하지 않는다. 표준 전송은 둘이다. stdio : 클라이언트가 띄운 하위 프로세스의 표준 입출력으로, 줄바꿈으로 구분한 메시지를 주고받는다. Streamable HTTP : 메시지마다 하나의 MCP 엔드포인트로 HTTP POST를 보낸다. 응답은 JSON 객체나 그 요청에만 쓰는 SSE(Server-Sent Events, 서버가 HTTP 응답으로 이벤트를 이어 보내는 방식) 스트림으로 온다. JSON-RPC 메시지는 UTF-8로 인코딩해야 한다. 그 밖의 통신 채널로 직접 전송 방식을 만들 수도 있지만, JSON-RPC 형식과 메시지 패턴과 요청별 메타데이터 모델은 지켜야 한다. 예전 전송 방식인 HTTP+SSE는 2025-03-26 개정부터 지원 중단 상태다. 3부. 2026-07-28 개정에서 바뀐 것 버전 이름은 YYYY-MM-DD 꼴이고, 하위 호환이 깨지는 변경이 마지막으로 들어간 날짜를 뜻한다. 하위 호환을 지키는 변경은 버전을 올리지 않는다. 지금까지 나온 개정판은 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28이다. 2026-07-28 변경 기록 에서 큰 줄기만 추리면 이렇다. 무상태가 됐다. initialize / notifications/initialized 핸드셰이크와 프로토콜 수준 세션( Mcp-Session-Id 헤더)을 없앴다. 요청마다 메타데이터 필드 _meta 에 프로토콜 버전과 클라이언트 능력(capabilities)을 싣는다. 버전이 맞지 않으면 서버는 UnsupportedProtocolVersionError 로 자기가 지원하는 버전 목록을 돌려준다. server/discover 가 생겼다. 서버는 반드시 구현해야 하고, 지원 버전·능력·자기 정보(identity)를 알려 준다. 클라이언트는 먼저 불러도 되고 안 불러도 된다. 서버가 먼저 요청하지 않는다. 예전에는 서버가 roots/list , sampling/createMessage , elicitation/create 같은 요청을 먼저 보냈다. 이제는 다중 왕복 요청(MRTR) 방식으로, 서버가 정보가 더 필요하면 InputRequiredResult 를 돌려주고 클라이언트가 필요한 정보를 담아 원래 요청을 다시 보낸다. 모든 결과에는 resultType ( complete 또는 input_required )이 붙는다. 엘리시테이션 같은 요청은 이제 InputRequiredResult 의 inputRequests 에 담겨 온다. 변경 알림은 subscriptions/listen 하나로 받는다. 예전의 HTTP GET 엔드포인트와 resources/subscribe 를 대신한다. Tasks는 핵심 프로토콜에서 빠져 공식 확장이 됐다. Roots, Sampling, Logging은 지원 중단 예정이 됐다. 지원 중단 기간에는 그대로 동작하지만 새 구현은 지원하지 말라고 권한다. 명세가 제안하는 대안은 Roots 대신 도구 인자나 리소스 URI로 경로를 넘기고, Sampling 대신 LLM 제공자 API를 직접 쓰고, Logging 대신 stderr나 OpenTelemetry를 쓰는 것이다. 이번 개정은 지원 중단 정책도 정했다. 지원 중단된 기능은 최소 12개월 동안 명세에 남는다. 현재 진행 중인 보안 위험이 있어 앞당기더라도 최소 90일은 남긴다. 예전 판과 함께 쓰기 명세는 요청마다 메타데이터를 싣는 2026-07-28 이후 판을 모던, initialize 핸드셰이크를 쓰는 2025-11-25와 그 이전 판을 레거시라고 부른다. 둘 다 지원하는 구현이면 상대가 어느 쪽인지 알아내 맞춰 쓸 수 있다. 다만 모던 전용 클라이언트와 레거시 서버, 레거시 클라이언트와 모던 전용 서버의 조합은 동작하지 않는다. 4부. 보안 원칙 명세는 MCP가 임의의 데이터 접근과 코드 실행 경로를 열어 주는 만큼, 구현하는 쪽이 지켜야 할 원칙을 셋으로 정리한다. 사용자 동의와 통제 : 사용자는 모든 데이터 접근과 작업을 명시적으로 동의하고 이해해야 하며, 무엇을 공유하고 무엇을 할지 통제권을 쥐어야 한다. 데이터 프라이버시 : 호스트는 사용자 데이터를 서버에 넘기기 전에 명시적 동의를 받아야 하고, 동의 없이 리소스 데이터를 다른 곳으로 보내면 안 된다. 도구 안전 : 도구는 임의 코드 실행이므로 조심해서 다뤄야 한다. 어노테이션(annotations)처럼 도구 동작을 설명하는 정보는 믿을 수 있는 서버에서 온 것이 아니면 믿지 말아야 하고, 호스트는 도구를 부르기 전에 사용자 동의를 받아야 한다. 명세는 프로토콜 수준에서 이 원칙을 강제할 수는 없다고 밝히고, 구현하는 쪽이 동의와 권한 흐름을 직접 만들라고 권한다. 마치며 MCP는 호스트·클라이언트·서버 세 역할이 JSON-RPC 2.0으로 리소스·프롬프트·도구를 주고받는 프로토콜이다. 2026-07-28 개정판에서 세션과 핸드셰이크가 사라지고, 서버가 먼저 요청하던 기능은 다중 왕복 요청으로 바뀌었다. MCP가 2024년 11월 공개된 뒤 2025년 12월 Agentic AI Foundation에 기부되기까지의 경위는 이 시리즈의 첫 글 에 정리했다. 참고 Model Context Protocol 명세(현재판) 2026-07-28 변경 기록 전송 방식 버전 관리 Introducing the Model Context Protocol — Anthropic (2024-11-25)
0. 개요 일반적으로, runserver를 하면 서버의 연결이 끊기거나... 하면 서비스가 종료된다 따라서 백그라운드에서 돌아가게 해 주는 과정이 필요함. 따라서 본 글에서는 그 방법을 서술해 놓고자 함. 1. 방법 nohup 명령어를 사용해 주면 된다. no hangup이라는 뜻이다 nohup python manage.py runserver 0.0.0.0:8000 이렇게 해 주면 백그라운드에서 runserver가 돌아가며, 서버의 연결을 끊더라도 서버 내에서 계속 실행됨.
오늘의 핵심 반복되는 UI는 복사해서 쓰는 게 아니라 Component 로 원본을 만들고 Instance 를 꺼내 쓴다. 같은 요소의 상태 차이는 Variant 로 묶어서 관리한다. 01. Component — 원본 하나, 복사본은 여러 개 버튼이나 카드처럼 여러 화면에서 반복해서 사용하는 UI 요소 를 Component로 등록한다. Main Component = 원본 Instance = 원본을 가져와 사용하는 복사본 원본의 여백·크기·구조 등을 수정하면 Instance에도 반영된다. Instance에서는 텍스트나 일부 속성처럼 내용만 다르게 사용할 수 있다. 즉, ❌ 버튼을 화면마다 복붙해서 각각 관리 ⭕ 버튼 하나를 Component로 만들고 Instance를 여러 번 사용 2번 이상 반복되는 요소 부터 컴포넌트화한다. 02. Instance — Assets에서 꺼내 사용 컴포넌트를 만든 뒤에는 새로 복붙하지 않고 Assets → 해당 Component를 드래그해서 사용한다. 여기서 중요한 구분은: 내용은 Instance에서 / 구조는 Main Component에서 예를 들어 제품 카드라면 Instance마다 상품명 가격 이미지 같은 내용은 바꿔도 된다. 반대로 카드 Padding 요소 간 Gap 전체 크기 규칙 같이 모든 카드가 공유해야 하는 구조는 Main Component에서 수정 하는 것이 좋다. 03. Variant — 하나의 UI에 여러 상태 넣기 버튼은 하나의 디자인만 있는 게 아니라 상태에 따라 존재한다. 그래서, Default / Hover / Disabled 이 3개를 만들어 하나의 Component Set으로 묶는다. 흐름은: 버튼 제작 → 3개 복제 → 상태별 디자인 변경 → 각각 Component → 3개 선택 → Combine as variants 이렇게 되면 버튼 하나 안에서 State 값만 바꿔 상태를 전환할 수 있다. 04. Variant 이름은 속성=값 ❌ 잘못된 방식 버튼1 / 버튼2 / 버튼3 ⭕ 옳은 방식 State=Default State=Hover State=Disabled 종류까지 여러 개라면: Type=Primary Type=Secondary 크기까지 관리한다면: Size=Large Size=Medium 즉** 무엇이 달라지는지 = 어떤 값인지**가 이름만 보고 보여야 한다. 영어를 자주 쓰는 듯. 05. 오늘자 과제 강의에선 Type + State를 합치면 6개가 된다는 예시가 나오지만, 직접 진행하는 과제에서는 간략하게 진행되었다. 버튼 종류 자체를 별도 Component Set으로 나눠서: Button/Primary Default Hover Disabled Button/Secondary Default Hover Disabled 이렇게 만든다. 즉, 버튼 2종 × 상태 3개 = 총 6개 버튼 디자인 , 하지만 Component Set은 2개 라고 이해하면 된다. 만들 것 이름 Variant 구매하기 버튼 Button/Primary Default / Hover / Disabled 장바구니 버튼 Button/Secondary Default / Hover / Disabled 제품 카드 Card/Product 없음 최종 결과물은 컴포넌트 3종 . 카드는 Variant가 필요 없고, Instance 2개 정도를 꺼내 상품명과 가격을 서로 다르게 변경해서 제대로 연결됐는지만 확인한다. 피그마에서 실제 작업 순서 1 Primary 버튼 Day 23의 구매하기 버튼 선택 → Create component → 2개 복제 → Default / Hover / Disabled 모양 제작 → 세 개 모두 선택 → Combine as variants → Property 이름을 State_로 변경 → 값은 _Default / Hover / Disabled → Component Set 이름을 Button/Primary 2 Secondary 버튼 똑같이 진행해서 Button/Secondary 를 만들고 State도 동일하게 Default / Hover / Disabled 로 맞춘다. 3 Product Card Day 23 카드 하나 선택 → Create component → 이름 Card/Product 그다음 Assets에서 _Card/Product_를 2개 꺼내서 Instance A 딩독 마약김밥 18,900원 Instance B 딩독 마약햄버거 16,900원 같은 식으로 텍스트만 다르게 만든다. 그리고 Main Component의 Padding이나 Gap을 한 번 변경해서 두 Instance가 동시에 따라오는지 확인 한다. ⭐ 오늘 기억해둘 것 1. UI 요소를 컴포넌트로 등록한다. 원본 하나, 인스턴스 여럿, 2번 이상 쓰는 것만. 2. 상태는 Variant로 모은다. State = Default / Hover / Disabled. 속성=값으로 이름을 적는다. 3.버튼 2종, 카드 1종을 점검한다. 원본 수정, 상대 전환, 스타일 유지. Button, Card가 나와야 함.
오늘은 좀 더 다양한 go 의 사용법을 알아보자 일단 결론 부터 서술 하겠다. go의 반복문안 switch 문 case 안에서 break 를 하면 반복문을 탈출하는게 아니라 switch문을 탈출한다. go의 Atoi 는 공백을 처리 못한다. go의 구조체는 캡슐화가 가능하며 구조체를 정의하는 시작문자의 대소문자로 판별한다. 대문자로 시작 (Exported): 다른 외부 패키지에서 접근 가능 (public 역할) 소문자로 시작 (Unexported): 동일한 패키지 내부에서만 접근 가능 (private 역할) slice 에서 len 랑 range 의 차이점은 len은 길이를 구하는 내장 함수이고, range는 슬라이스를 순회(반복)할 때 사용하는 키워드 이다. if 문에서 초기화를 하고 바로 조건 검사를 할 수 있다. if i := strings.TrimSpace; i == "Hello"{<code>} 이런 식으로 가능하다. 아직까지 큰 문제는 go 의 자료구조와 에러처리 방법 문법에 대해서 어려움을 가지고 있다는 것이다. 특히 문법을 틀려서 error 가 나는 상황에서 수정을 하는데 너무 괴롭다. 문제를 찾기위해 문법 검사기가 알려주는 error의 정의에 대해서 찾고 그걸 다시 내코드에 적용하는 과정이 힘들다. 코드 package main import ( "bufio" "errors" "fmt" "os" "strconv" "strings" ) type Task struct { ID int Title string Done bool } type Store struct { Tasks []Task NextID int } func (s *Store) Add(title string) (Task, error) { task := strings.TrimSpace(title) if task == "" { return Task{}, errors.New("title is empty") } s.NextID++ tmp := Task{ ID: s.NextID, Title: task, Done: false, } s.Tasks = append(s.Tasks, tmp) return tmp, nil } func (s *Store) Complete(id int) error { for i := 0; i < len(s.Tasks); i++ { if s.Tasks[i].ID == id { s.Tasks[i].Done = true fmt.Println(s.Tasks[i]) return nil } } return errors.New("No match ID check again") } func split_token(scan *bufio.Scanner) ([]string, error) { if scan.Scan() { text := scan.Text() reValue := strings.TrimSpace(text) for i := 0; i < len(reValue); i++ { b := reValue[i] if isASCIIAlpha(b) == false { return []string{reValue[:i], reValue[i:]}, nil } } return []string{reValue}, nil } return nil, errors.New("Scanning Error Checkagain") } func (s *Store) Done(str string) error { number, err := strconv.Atoi(strings.TrimSpace(str)) if err != nil { return errors.New("AtoiError") } for i := range s.Tasks { if s.Tasks[i].ID == number { s.Tasks[i].Done = true return nil } } return errors.New("not found ID") } func isASCIIAlpha(b byte) bool { return (b >= 'a' && b <= 'z') || (b >= 'A' && b <= 'Z') } func newStore() *Store { return &Store{NextID: 0} } func (s *Store) print_list() { for _, task := range s.Tasks { fmt.Println(task) } } func main() { store := newStore() Scanner := bufio.NewScanner(os.Stdin) for { if text, err := split_token(Scanner); err == nil { switch text[0] { case "add": if len(text) == 2 { store.Add(text[1]) } else { fmt.Println("add command is : add <title>") } case "list": store.print_list() case "done": if len(text) == 2 { if err := store.Done(text[1]); err != nil { fmt.Println(err) } } else { fmt.Println("add command is : add <title>") } case "exit": fmt.Println("good bye sir") return case "": continue default: fmt.Println("Command type is ADD, list , exit") } } else { fmt.Println(err) } } }
Anthropic은 2025년 9월 29일 Effective context engineering for AI agents 를 냈다. 에이전트를 만들 때 컨텍스트 창에 무엇을 넣고 무엇을 뺄지에 대한 글이다. 정의와 지침, 긴 작업을 위한 기법을 원문을 따라 정리했다. 들어가며: 무엇을 컨텍스트 엔지니어링이라 부르나 문서는 컨텍스트 엔지니어링을 "LLM이 추론하는 동안 최적의 토큰(정보) 집합을 고르고 유지하는 전략"이라고 정의한다. Anthropic은 이것을 프롬프트 엔지니어링이 자연스럽게 나아간 다음 단계로 본다. 지시문을 잘 쓰는 데서 여러 턴에 걸친 컨텍스트 상태 전체를 관리하는 쪽으로 넓어졌다는 것이다. 왜 관리가 필요한지도 설명한다. 트랜스포머에서는 모든 토큰이 다른 모든 토큰을 참조하므로 토큰 n개면 n2개의 관계가 생긴다. 그래서 모델에는 쓸 수 있는 주의력의 한도(주의 예산, attention budget)가 있고, 토큰이 늘수록 그 안의 정보를 정확히 떠올리는 능력이 떨어진다(컨텍스트 로트, context rot). 문서가 내놓는 원칙은 "원하는 결과가 나올 가능성을 최대로 하는 가장 작은 고신호 토큰 집합을 찾으라"는 것이다. 1부. 컨텍스트를 이루는 것들 시스템 프롬프트 — 알맞은 높이 문서는 시스템 프롬프트가 흔히 빠지는 양극단을 든다. 한쪽은 원하는 동작을 정확히 끌어내려고 복잡하고 깨지기 쉬운 조건 분기를 프롬프트에 박아 넣는 것으로, 시간이 갈수록 고치기 어려워진다. 다른 쪽은 높은 수준의 막연한 지침만 주는 것으로, 모델에게 구체적인 신호를 주지 못하거나 맥락을 공유한다고 잘못 가정한다. 그 사이의 알맞은 높이(altitude)는 "행동을 효과적으로 이끌 만큼 구체적이면서, 모델에게 강한 판단 기준을 줄 만큼 유연한" 것이다. 도구 도구는 "스스로 완결되고, 오류에 강하고, 쓰임새가 아주 분명해야" 한다. 문서가 드는 기준은 이렇다. 어떤 상황에 어느 도구를 써야 하는지 사람 엔지니어도 확실히 말하지 못한다면 AI 에이전트가 더 잘하길 기대할 수 없다. 예시 예시를 넣는 few-shot 프롬프팅은 문서도 계속 강하게 권한다. 다만 예외 상황을 잔뜩 늘어놓기보다, 에이전트에게 기대하는 행동을 잘 보여 주는 다양하고 대표적인 예시를 골라 담으라고 한다. 2부. 언제 넣을지 — 적시 조회 필요한 데이터를 미리 다 싣는 대신, 에이전트가 파일 경로나 링크 같은 가벼운 식별자만 들고 있다가 필요할 때 도구로 불러오는 방식을 문서는 적시 조회(just-in-time)라 부른다. 에이전트가 이렇게 탐색하며 필요한 맥락을 조금씩 찾아가는 것을 문서는 점진적 공개(progressive disclosure)라고도 부른다. 문서는 미리 싣기와 적시 조회를 섞는 방식(hybrid)도 소개하는데, Claude Code가 그 예다. CLAUDE.md 파일은 처음부터 컨텍스트에 그대로 넣고, glob과 grep 같은 기본 도구로 환경을 탐색하며 파일은 그때그때 찾아 읽는다. 3부. 긴 작업을 버티는 세 기법 컨텍스트 창보다 긴 작업을 위해 문서는 세 가지를 든다. 압축 컨텍스트 한도에 가까워지면 대화를 요약해 새 컨텍스트에서 이어 간다. Claude Code는 대화 기록을 모델에게 넘겨 가장 중요한 내용을 요약하게 한다. 이때 설계 결정, 풀리지 않은 버그, 구현 세부는 남기고 중복된 도구 출력이나 메시지는 버린다. 에이전트는 압축된 컨텍스트에 최근에 연 파일 5개를 더해 일을 이어 간다. 더 가벼운 방법도 있다. 문서는 오래전 도구 호출과 그 결과를 컨텍스트에서 지우는 것을 가장 가볍고 안전한 압축으로 꼽고, 최근 Claude Developer Platform에 기능으로 출시됐다고 적는다. 구조화된 메모 에이전트가 컨텍스트 밖에 메모를 적어 두었다가 나중에 다시 읽는 방식이다. 할 일 목록이나 NOTES.md 같은 파일이 예다. 문서는 Claude가 포켓몬 게임을 하며 수천 단계에 걸쳐 진행 상황을 메모로 이어 가는 예를 든다. 서브에이전트 전문 서브에이전트가 깨끗한 컨텍스트에서 좁은 일을 맡고, 주 에이전트는 큰 계획을 조율한다. 서브에이전트는 수만 토큰 이상을 써 가며 깊게 탐색할 수 있지만, 돌려주는 것은 압축한 요약뿐이다. 문서는 그 요약이 보통 1,000~2,000토큰이라고 적는다. 마치며 문서는 컨텍스트를 한정된 자원으로 보고, 원하는 결과를 낼 가장 작은 고신호 토큰 집합을 찾으라고 권한다. 시스템 프롬프트는 알맞은 높이로, 도구는 쓰임새가 분명하게, 예시는 대표적인 것만 담는다. 긴 작업에는 압축, 구조화된 메모, 서브에이전트를 쓴다. 같은 원리는 이 시리즈의 Agent Skills 글 에서 다룬 스킬에도 있다. 스킬도 내용을 처음부터 모두 싣지 않고 필요할 때 읽는 방식이다. 참고 Effective context engineering for AI agents — Anthropic (2025-09-29)
이 글은 NIA(한국지능정보사회진흥원) 디지털서비스 이슈리포트 2026-9호 에 기고한 리포트입니다. 📄 NIA 원문 · 브런치 (그림은 원문에서 볼 수 있습니다) 들어가며: 청구서가 먼저 온다 에이전트를 프로덕션에 올린 조직이 그다음 달에 가장 먼저 받아 드는 것은 거버넌스 대시보드가 아니라 청구서다. 지난 편에서 에이전트(스스로 계획을 세워 여러 단계를 실행하는 AI 프로그램)를 만드는 일은 쉬워졌고 남은 문제는 통제라고 정리했는데, 그 통제 문제가 실무에서 가장 먼저 비용의 형태로 드러난다. 에이전트는 한 번의 결과를 내놓기 위해 계획을 세우고, 도구를 호출하고, 돌아온 결과를 다시 읽고, 필요하면 처음으로 돌아가 다시 시도하는데, 이 과정이 쌓이면서 같은 일을 단발성 질의로 처리할 때보다 10배에서 30배에 이르는 토큰을 소비한다고 업계는 본다. 파일럿 시절에는 반올림 값이나 오차에 가까웠던 이 비용이 길지 않은 시간 후에 예산에서 별도 항목으로 관리해야 하는 상시 운영비가 되었다. 이 변화를 업계의 언어로 가장 선명하게 정리한 쪽은 공교롭게도 칩을 파는 회사였다. 엔비디아의 젠슨 황은 2026년 3월 GTC 2026 기조연설에서 데이터센터를 'AI 팩토리'로 재정의했는데, 투입되는 원료는 전기와 데이터이고 공장에서 나오는 완제품은 토큰이며, 생산성은 와트당 토큰으로 잰다는 것이다[1]. 칩 회사가 스스로를 토큰 생산 인프라 사업자로 설명하기 시작했다는 것은 토큰이 규격화된 원자재로 취급되기 시작했다는 뜻이고, 구매자의 언어로 옮기면 추론은 이제 기술 선택의 문제이기 이전에 조달의 문제가 되었다는 것이다. 가트너는 2026년 8월 전망에서 AI에 최적화된 인프라 서비스(IaaS) 지출이 2026년 423억 달러로 전년 대비 96% 늘고, 그 가운데 추론이 233억 달러로 학습의 190억 달러를 처음 넘어서 전체의 55%를 차지할 것으로 내다봤다[2]. 기업의 예산 편성에서도 같은 흐름이 확인되는데, a16z는 기업 CIO 100명을 조사해 기업 한 곳의 평균 대규모 언어 모델(LLM) 예산이 2025년 700만 달러에서 2026년 말 1,160만 달러로 늘어날 것으로 전망했다[3]. 이번 리포트는 그 토큰을 '사는 쪽'의 이야기다. 추론 산업은 세 개의 층으로 쌓여 있고, 이 글은 CIO와 CTO가 실제로 지갑을 여는 맨 위층을 다루며, 공장을 '짓는 쪽'의 사정은 다음 편에서 이어진다. 이번 보고서에서의 질문은 다음의 셋이다. 1) 어디서 살 것인가, 2) 어떤 방식으로 살 것인가, 그리고 3) 얼마에 살 것인가. 그런데 2026년의 조직은 이 셋을 한 번 정해 두고 끝내지 못하는데, 애플리케이션이나 에이전트가 모델을 호출할 때마다 셋을 다시 판단하는 일을 사람 대신 소프트웨어가 맡기 시작했기 때문이다. 이 질문들에 답할 수 있는 상태, 곧 무엇을 얼마나 쓰는지 알고 필요하면 갈아탈 수 있는 상태를 이 글은 구매 역량이라 부르고, 그 역량을 어떻게 갖출 것인가로 글을 정리한다. 토큰은 어디서 와서 어떻게 팔리는가 토큰이 오는 곳, 세 개의 층 맨 아래층은 AI 데이터센터로, 부지와 전력을 갖춘 사업자와 그 위에 GPU를 놓고 연산 시간을 파는 사업자를 합쳐 부르는 이름이며 공장에 비유하자면 건물과 설비다. 그 위의 추론 인프라는 같은 GPU에서 더 많은 토큰을 뽑아내는 서빙 엔진과 최적화의 층이고 생산 라인에 해당한다. 맨 위의 토큰 팩토리는 완제품인 토큰을 API로 판매하는 층이며, 엔비디아가 AI 팩토리라 부르는 것이 세 층을 합친 전체라면 이 글의 토큰 팩토리는 그 맨 위층만을 가리킨다. 세 층은 회사의 경계라기보다 기능의 경계여서 한 회사가 두 층을 품기도 하고, 구매자가 GPU를 직접 두고 오픈 모델을 돌리는 셀프호스트 방법으로 가운데 층을 스스로 떠안기도 한다. 그리고 이 세 층으로 쌓인 구조의 맨 위에는 모델을 호출할 때마다 어느 공급자에게서 살지를 고르는 구매 데스크가 새로 얹어진다. 이 세 층은 가동률을 기준으로 한 지점에서 만난다. 데이터센터의 자본 지출은 그 자체로는 비용일 뿐이고 추론 인프라가 GPU를 쉬지 않고 돌려 토큰으로 바꿔낼 때에만 매출이 되는데, 그래서 이 산업의 마진은 GPU 시간을 빌려주는 아래층보다 토큰을 파는 위층에서 커질 수 있다. 하지만, 그것은 가동률을 채웠을 때에만 실현되는 잠재적 마진이고 커모디티화(어디서 사든 같은 물건이 되어 가격으로만 경쟁하게 되는 것)의 압력이 그 마진을 계속 깎아내린다. 구매자에게 이는 선택지로 여겨지는데, 토큰을 사면 GPU가 쉬든 말든 신경 쓸 일이 없는 대신 남의 마진을 함께 지불하고, GPU 시간을 사면 마진을 줄이는 대신 가동률을 스스로 책임져야 한다. 세 가지 구매 모드: 택시, 대절 버스, 자가용 실무에서 추론을 사는 방식은 크게 셋이며, 탄 만큼 내는 택시(서버리스 API)와 시간당 빌리는 대절 버스(전용 엔드포인트), 사서 직접 모는 자가용(셀프호스트)에 해당한다. 셋을 가르는 것은 무엇을 남에게 맡기고 무엇을 직접 지느냐인데, 다만 택시에도 분당 토큰 한도라는 사실상의 용량 계약이 붙는다. 표 1: 세 가지 구매 모드 비교(칸의 값은 대표적인 경우이며 사업자와 리전에 따라 다르다) 구분 서버리스 API 전용 엔드포인트 셀프호스트 비유 탄 만큼 내는 택시 시간당 빌리는 대절 버스 사서 직접 모는 자가용 과금 단위 토큰당 GPU 시간당 GPU 구매·임대 + 운영 인건비 지연 가변 안정 튜닝에 따라 최적화 가능 처리량 유연 보장 자체 용량 한도 내 자유 모델 선택 제공 목록 한정 제공 목록 + 커스텀 모델 반입 오픈 모델 전면 자유 데이터 주권 낮음~중간 중간 완전 관리 부담 최소 낮음 높음 세 모드 사이의 경계선을 긋는 것이 가동률(확보한 처리량 대비 실제로 쓴 처리량)이다. 서버리스와 전용 엔드포인트의 손익분기점은 대체로 GPU 가동률 40 50% 부근에 놓인다는 분석이 있고[4], 셀프호스트는 GPU 임대 원가만 놓고 보면 응답 속도 요구에 따라 22 48% 구간에서 손익이 갈리지만[5] 운영 비용을 얹으면 그 경계는 위로 올라간다. 같은 분석은 거의 유휴 상태인 셀프호스트 GPU가 서버리스보다 2~4배 비쌀 수 있다고 계산하는데[5], 그 차이는 인건비와 피크에 맞춰 확보해 두는 유휴 용량에서 온다. 사실상의 표준이 된 vLLM과 프리픽스 재사용 구조(RadixAttention)로 이름을 알린 SGLang 같은 오픈소스 서빙 엔진이 진입 문턱을 낮추기는 했지만, 양자화 수준을 정하고 병렬 구성과 문맥 캐시(KV 캐시) 메모리를 조정하고 장애를 복구하는 일에는 여전히 전담 인력이 필요하다. 이 경계는 어느 서버리스 단가와 견주느냐에 따라서도 크게 달라진다. 같은 오픈 모델을 여러 사업자가 동시에 서빙하는 구조가 자리 잡으면서, 널리 쓰이는 한 오픈 모델을 기준으로 최저가 사업자와 최고가 사업자의 100만 토큰당 단가는 8배 넘게 차이가 난다. 초당 생성 속도 역시 사업자마다 크게 다른데, 단가와 속도가 비례하지 않아서 가장 빠른 사업자가 가장 비싼 사업자는 아니다[6]. 단가표의 한 줄도 들여다보면 입력과 출력, 캐시 적중, 긴 문맥 구간에 따라 요금이 나뉘고, 사고 단계를 거치는 추론(reasoning) 모델은 화면에 보이지 않는 사고 토큰까지 출력 요금으로 청구한다. 구매자가 고를 여지가 이만큼 넓다는 사실이 다음 절의 구매 데스크가 존재하는 이유다. 구매 데스크: 호출마다 공급자를 고르는 층 같은 상품의 가격이 8배 넘게 벌어져 있다면, 모든 호출을 최상위 모델로 보내는 것은 모든 출장을 일등석으로 보내는 일과 다르지 않다. 그래서 애플리케이션과 모델 사이에 새로운 층이 끼어들었는데, 호출이 일어날 때마다 이번 토큰은 어느 공장에서 살지를 자동으로 결정하는 계층이며 앞의 층 위에 놓인 구매 데스크라 부를 만하다. 이런 자동 선택이 편의 못지않게 위험도 가져온다는 사실은 2025년 8월 오픈AI의 GPT-5 출시가 보여 줬다. 오픈AI는 챗GPT에서 쉬운 질의는 소형 모델로, 어려운 질의는 대형 모델로 보내는 실시간 라우터를 기본값으로 켰는데(API에서는 사용자가 세 가지 크기의 모델을 직접 고른다[7]), 초기 라우팅이 제대로 작동하지 않으면서 복잡한 질의까지 소형 모델로 흘러갔고 새 모델이 오히려 퇴보했다는 반발이 일자 이전 모델의 선택지를 되살리는 것으로 대응했다[8]. 소비자 제품에서 먼저 벌어진 이 일은 관리형 라우팅을 사려는 기업에서도 그대로 되풀이될 수 있는데, 내 질의를 무엇이 처리했는지 모르는 상태에서는 품질 저하를 진단할 수도 책임을 물을 수도 없다. 이 편의와 위험을 함께 다루는 상품은 세 갈래로 나뉜다. 품질과 비용 사이의 다이얼을 사용자에게 넘기는 독립 게이트웨이, 라우팅을 기본 기능으로 흡수한 하이퍼스케일러, 그리고 GPT-5처럼 라우팅을 제품 안에 넣어 소비자가 모델 대신 결과의 품질 등급을 사게 하는 모델 벤더다. 앞의 두 갈래는 다음 장의 오픈라우터 절과 AWS 베드록·마이크로소프트 파운드리 절에서 본다. 시장이 라우팅을 상품으로 팔아 온 동안, 학계는 같은 문제를 공개된 연구 과제로 다뤄 왔다. 값싼 모델부터 시도하는 캐스케이드 방식을 처음 정식화한 프루갈GPT(FrugalGPT, 2023)에서 2026년의 LLM라우터(LLMRouter)까지, 개별 기법이 표준 벤치마크를 거쳐 통합 라이브러리로 수렴했다. 학습된 라우터가 성능 지표에서 최강의 단일 고정 모델보다 상대적으로 14.6% 나은 결과를 냈다는 LLM라우터의 보고는[9], 비용과는 별개로 모델마다 잘하는 질의가 달라 조합이 단일 최강 모델을 이길 수 있다는 뜻이다. 라우팅은 특정 업체의 비밀로 남지 않는 표준화 가능한 학습 문제이며, 자사의 질의 분포와 그 위의 품질 판정 데이터로 직접 학습시켜 내재화할 수 있는 역량이기도 하다. 라우팅 기술이 그렇게 범용화되는 동안 구매 데스크라는 자리는 오히려 비싸졌다. 팔로알토 네트웍스는 게이트웨이 스타트업 포트키(Portkey)를 인수해 자사 보안 플랫폼의 통제점으로 삼았고[10], 스트라이프(Stripe)는 2026년 8월 오픈라우터(OpenRouter) 인수에 합의했는데 보도된 가격은 70억 달러 이상으로 석 달 전 기업가치의 5배가 넘는다[11]. 라우팅의 값은 기술이 아니라 그 자리에 매겨지고 있는 셈이다. 여기서 한 가지 질문이 남는데, 스위치 하나로 수요가 공장 사이를 즉시 옮겨 다닐 수 있고 그 스위치를 만드는 기술마저 오픈소스로 풀려 있다면, 토큰을 만들어 파는 쪽에는 무엇이 남는가. 다음 장의 여섯 벤더는 각자의 방식으로 이 질문에 답하는 중이다. 주요 벤더별 솔루션 심층 분석 이 영역의 주요 플레이어인 여섯 벤더를 가치사슬의 위치 순서로 살펴본다. 독립 추론 클라우드, 전용 실리콘 진영, 구매 데스크, 하이퍼스케일러의 순이며, 각 벤더가 커모디티화의 압력 앞에서 무엇을 해자로 내세우는지에 초점을 맞춘다. 파이어웍스 AI: 속도에 값을 매기다 독립 추론 클라우드인 파이어웍스 AI(Fireworks AI)는 속도를 해자로 삼는 전략의 가장 성공한 사례다. 회사에 따르면 2026년 7월 연간 반복 매출이 10억 달러를 넘겼고 하루에 처리하는 토큰은 40조 개를 넘는다[12]. 커서·노션·쿼라·버셀 같은 고객 명단이 파이어웍스의 위치를 잘 보여 주는데[13], 코드 편집기와 문서 도구처럼 사용자가 응답을 기다리는 시간이 곧 제품 품질인 회사들이다. 기술의 중심에는 자체 개발한 어텐션 커널 파이어어텐션(FireAttention)이 있고, 그 위에 같은 GPU에서 토큰 산출을 높이는 최적화 기법들이 쌓여 있다. 회사는 이 커널의 FP8 구현이 오픈소스 엔진 vLLM보다 4배 빠르다고 밝혀 왔고[14], 고객인 노션은 응답 지연을 약 2초에서 350밀리초로 줄였다고 말한다[13]. 서버리스 외에 전용 엔드포인트와 온프레미스 배포까지 세 가지 구매 모드를 모두 갖췄고, 2026년에는 마이크로소프트 파운드리 안에서 정식 서비스로 제공되기 시작해 독립 추론 클라우드가 하이퍼스케일러의 계약과 청구서 안으로 들어간 드문 사례가 됐다. 속도에는 값이 붙는다. 파이어웍스의 서버리스 단가는 16B 초과 모델 기준 100만 토큰당 0.90달러로, 최저가 사업자의 0.12달러와 견주면 7.5배에 이르러[15][6], 밤새 돌리는 배치 요약처럼 속도가 필요 없는 워크로드에는 과잉이고, 양자화 수준과 캐싱 옵션이 많아 최적의 조합을 찾는 데에도 학습 비용이 든다. 빠른 토큰은 아직 원자재가 되지 않았다는 것이 파이어웍스의 주장이고, 응답 속도가 곧 제품 품질인 워크로드에서만 그 값을 치를 이유가 있다. 투게더 AI: 백화점이 공장을 갖기 시작할 때 투게더 AI(Together AI)는 오픈소스 모델 생태계의 백화점을 자처한다. 폐쇄형 API보다 크게 저렴하다는 것을 정면에 내세우고, 수백 개의 오픈 모델을 서빙하는 카탈로그 위에 파인튜닝 서비스와 전용 GPU 클러스터까지 잇는 스펙트럼을 갖췄으며, 회사는 2026년 7월 기준 수주 잔고가 11억 5,000만 달러이고[16], 8월에는 월간 처리 토큰이 400조 개에 이른다고 밝혔다[17]. 2026년 7월의 투자 유치 발표에서 눈여겨볼 숫자는 따로 있는데, 투게더가 확보했다고 밝힌 500메가와트(업계는 확보한 계산 능력을 전력 용량으로 센다)의 커밋 컴퓨트다[18]. 위층의 마진은 가동률로만 지켜지므로 투게더는 가동률의 근원인 공급을 잡으러 가치사슬 아래로 내려간 것이고, 2026년 8월에는 IBM 클라우드에 추론 전용 GPU 클러스터를 두는 2억 4,000만 달러 규모의 다년 계약을 맺어 남의 공장까지 빌린 셈이다[17]. 투게더가 내세우는 것은 규모의 경제와 파인튜닝인데, 플레이그라운드에서 모델을 비교하다 같은 화면에서 파인튜닝 작업을 시작하는 흐름이 사용자 경험의 강점이다. 반면 위와 아래에서 동시에 압력을 겪는데, 위로는 폐쇄형 최상위 모델이 없으므로 오픈 모델로 충분한지를 검증하는 일이 고객의 몫이고, 아래로는 자체 GPU를 직접 운영해 단가로 경쟁하는 사업자들이 있어 오픈 모델끼리 견주면 투게더는 오히려 비싼 축에 속한다. 6~20배 저렴하다는 회사의 주장은 폐쇄형 모델과 견줄 때의 이야기다[18]. 그록과 세레브라스: GPU에서는 나오지 않는 속도 GPU 대신 전용 실리콘으로 토큰을 만드는 이 두 회사가 내세우는 것은 클러스터 전체의 처리량보다 요청 하나가 체감하는 속도, 곧 첫 토큰이 나오기까지의 지연과 그 뒤의 생성 속도다. 토큰을 하나 만들 때마다 모델 가중치 전체를 메모리에서 읽어야 하므로 생성 단계는 연산보다 메모리 대역폭에 묶이는데, 두 회사는 가중치를 GPU의 외장 메모리(HBM) 대신 칩 위의 SRAM에 두어 이 병목을 피한다. 그록(Groq)의 LPU는 실행 순서가 미리 정해져 대기 시간이 없는 구조로 소형·중형 모델에 특화되어, 독립 벤치마크 기준 널리 쓰이는 70B급 오픈 모델을 초당 300토큰 이상으로 생성해 GPU 기반 사업자의 속도를 큰 차이로 앞선다[6]. 실시간 에이전트나 음성 대화처럼 응답이 몇백 밀리초만 늦어져도 제품으로서 실패하는 워크로드가 그록의 영역이다. 세레브라스(Cerebras)는 같은 원리를 훨씬 큰 칩에 적용한다. 웨이퍼 하나를 통째로 칩으로 쓰는 WSE-3는 GPU의 칩 내장 메모리보다 수백 배 큰 SRAM을 갖춰 405B급 초대형 모델까지 초당 900토큰 넘게 생성한다. 회사는 2026년 5월 나스닥에 상장해 55억 달러 안팎을 조달했고[19], 8월에 발표한 2분기 실적에서 클라우드 부문 매출이 전년 동기 대비 4배 가까이 늘었다고 밝혔으며[20], 오픈AI와는 750메가와트 규모, 200억 달러 이상의 다년 공급 계약을 맺었다[21]. 반면 두 회사는 같은 값을 치르는데, 가중치를 SRAM에 담아야 하므로 큰 모델일수록 칩 수가 급증하고 새 모델을 올릴 때마다 포팅 비용이 들어 모델 커버리지가 GPU 사업자보다 좁으며, 공급 능력이 수요를 따라가지 못하는 시기가 반복된다. 그러나 다이얼을 아무리 돌려도 GPU에서는 나오지 않는 속도가 있고, 그 속도의 값을 가장 크게 매긴 쪽은 GPU 회사 자신이었는데, 엔비디아는 2025년 12월 그록 추론 기술의 비독점 라이선스를 보도에 따르면 약 200억 달러에 사들이고 창업자 조너선 로스를 포함한 핵심 인력을 데려갔으며, 그록은 독립 회사로 남아 GroqCloud를 계속 운영하고 있다[22]. 오픈라우터: 결제 회사가 산 구매 데스크 오픈라우터는 여섯 벤더 가운데 유일하게 GPU가 없다. 400개가 넘는 모델과 80곳이 넘는 공급자를 오픈AI 호환 단일 API 뒤에 모아 놓고, 공급자의 토큰 단가는 그대로 넘기되 크레딧을 결제할 때 5.5%의 수수료를 얹는다[23]. 앞에서 언급한 공장이 아니라 대표적인 구매 데스크이며, 2026년 5월 기준 사용자는 800만 명, 처리량은 월 100조 토큰으로 6개월 만에 5배가 됐다[24]. 그리고 2026년 8월, 결제 회사 스트라이프가 이 구매 데스크를 사기로 합의했다[11]. 핵심 기능은 폭넓은 모델 선택지, 한 공급자가 장애를 일으키면 자동으로 다른 공급자로 넘기는 폴백, 그리고 품질과 비용 사이의 다이얼을 사용자에게 넘기는 자동 라우터다. 구매 데스크에 서면 시장 전체가 보인다는 점도 오픈라우터만의 자산인데, 회사가 공개하는 사용 통계에 따르면 프로그래밍 워크로드가 2025년 초 전체 토큰의 11%에서 연말에는 절반 이상으로 늘었고[25], 2026년 2월에는 중국 모델이 주간 토큰 처리량에서 미국 모델을 처음 앞질러 6월 기준 라우팅된 토큰의 46%를 차지했다[26]. 반면 구매 데스크라는 위치의 약점은 그대로다. 사용량이 커진 고객은 볼륨 할인과 약정 요금을 얻기 위해 공급자와 직접 계약하려 하고, 라우팅 기술은 오픈소스로 풀려 있어 자체 구축이 가능하며, 감사 로그와 예산 통제 같은 엔터프라이즈 거버넌스 기능은 아직 성숙 중이다. 그렇다면 스트라이프는 무엇을 산 것인가. 오픈라우터의 수수료가 결제할 때 붙는다는 사실이 답의 절반이고, 스트라이프의 패트릭 콜리슨이 인수 발표에서 "토큰은 AI로 제품을 만드는 회사들의 중심 통화"라고 말한 것이 나머지 절반이라 할 수 있다[11]. 오픈라우터의 창업자는 자사를 'AI의 스트라이프'라 불렀는데, 스트라이프가 산 것은 라우팅 기술이라기보다 800만 사용자가 토큰을 결제하는 계산대이고, 구매 데스크의 자리가 그 자리에 서 있는 기술보다 비싸다는 것이 이 거래의 뜻이다. AWS 베드록: 이미 맺어 둔 계약이라는 자산 이전 보고서에서 베드록 에이전트코어를 에이전트 실행 인프라로 다뤘다면, 이번에 보는 것은 같은 베드록의 아래층, 곧 토큰을 파는 층이다. AWS의 관리형 추론 서비스인 베드록(Bedrock)은 수백 개의 파운데이션 모델을 단일 API로 제공하며, 아마존에 따르면 12만 5,000곳이 넘는 고객과 포춘 100대 기업의 약 80%가 이용한다[27]. 이미 체결된 AWS 계약과 IAM 권한, VPC 경계, 규정 준수 인증, 곧 심사가 끝난 보안 울타리 안에서 토큰을 산다는 것은 조달 부서와 보안 부서에 새 벤더를 심사하는 절차를 통째로 생략해 준다는 뜻이기도 하다. 구매 모드의 관점에서 베드록은 세 요금제를 한 제품 안에서 다룬다. 토큰당 과금하는 온디맨드, 지연을 감수하는 대신 업계 관행대로 절반 가격인 배치 추론, 처리량을 약정하고 그 용량을 채워 쓰면 30 50%를 절감하는 프로비저닝 처리량이 그것이며, 앞의 가동률 논의를 벤더를 바꾸지 않고 요금제만 바꿔 따라갈 수 있게 한 것이다. 라우팅도 안으로 흡수했는데, 2025년 4월 정식 출시된 지능형 프롬프트 라우팅(Intelligent Prompt Routing)은 요청별로 응답 품질을 예측해 같은 모델 계열 안에서 크기가 다른 모델을 오가며, AWS에 따르면 내부 테스트에서 계열에 따라 16 56%의 비용 절감을 보였다[28]. 반면 심사가 끝난 울타리 안에 머무는 대가는 선택의 제한이다. 새 모델이 시장에 나온 뒤 베드록 카탈로그에 오르기까지 시차가 있고, 라우팅은 같은 계열 안에서만 작동하므로 계열을 넘는 선택은 여전히 사람의 몫이며, 모델별 단가가 AWS 정가로 고정되어 있어 사업자 간 8배가 넘는 단가 격차는 이 울타리 안으로 들어오지 않는다. 베드록을 붙드는 것은 토큰의 값보다 이미 맺어 둔 계약이며, 그것은 구매자 입장에서 가장 경계해야 할 종류의 편의이기도 하다. 마이크로소프트 파운드리: 유통망이 된 애저 마이크로
[머신러닝] 5강. 특징 추출 📌 오늘의 학습 목표 고차원 데이터에서 핵심 정보만 남기는 특징 추출(Feature Extraction) 과 변환 함수 의 관계를 이해합니다. Representative 선형변환 기법인 PCA(주성분분석법) 와 LDA(선형판별분석법) 의 도입 이유와 동작 원리의 차이점을 구별합니다. 선형변환의 한계점과 이를 보완하는 거리 기반 비선형 차원 축소 기법의 특징을 파악합니다. 1. 특징 추출과 차원 축소의 개요 (1) 특징 추출(Feature Extraction)의 존재 이유 문제 상황 : 원본 데이터는 크기(차원)가 너무 크고, 불필요한 정보나 잡음(Noise)이 많이 포함되어 있습니다. 이를 그대로 머신러닝 모델에 사용하면 계산 시간이 급증하고 모델 성능이 떨어지는 차원의 저주 문제가 발생합니다. 해결 방법 : 기존 변수들을 종합 및 변환하여 중요한 정보만 축약한 새로운 저차원의 특징 벡터 를 뽑아내는 특징 추출 을 진행합니다. (2) 변환 함수(Transformation Function)의 역할 관계 : 특징 추출이라는 목적(결과)을 달성하기 위해 사용하는 수학적 연산 도구 가 바로 변환 함수 입니다. 선형변환 vs 비선형변환 : 선형변환 : $y = W^T x$ 식과 같이 데이터에 변환 행렬 $W$를 단순 곱하는 방식입니다. 공간을 휘지 않고 그대로 기울이거나 특정 평면에 투영하여 줄입니다. (예: PCA, LDA) 비선형변환 : 복잡한 함수 $\phi(x)$나 인공신경망을 활용해 공간을 꺾고 구부리면서 변환하는 방식입니다. 복잡하고 왜곡된 데이터 처리에 적합합니다. 2. 주성분분석법 (PCA, Principal Component Analysis) (1) 존재 이유 (Story & Purpose) 정답(클래스 라벨)이 없는 비지도학습 환경에서, 데이터의 정보 손실을 최소화하면서 차원을 축소하기 위해 등장했습니다. (2) 핵심 원리 (Condition & Logic) 데이터가 넓게 펼쳐져 있는 방향, 즉 분산(Variance)이 가장 큰 방향(주성분 축)에 유용한 정보가 집중되어 있다고 판단합니다. 수행 단계 : 입력 데이터 $X$의 평균을 0으로 맞추는 정규화(Centering) 진행 공분산 행렬 $\Sigma_x$ 계산 공분산 행렬의 고유치 분석을 통해 고유치(Eigenvalue)와 고유벡터(Eigenvector) 계산 고유치가 가장 큰 순서대로 $m$개의 고유벡터를 선택하여 변환 행렬 $W$ 구성 $y = W^T x$ 변환을 거쳐 저차원 데이터로 변환 3. 선형판별분석법 (LDA, Linear Discriminant Analysis) (1) 존재 이유 (Story & Purpose) 정답(클래스 라벨)이 존재하는 지도학습 환경에서, 단순 차원 축소를 넘어 분류(Classify) 성능을 극대화 하기 위해 등장했습니다. (2) 핵심 원리 (Condition & Logic) 서로 다른 클래스 간의 거리는 멀어지게 하고, 같은 클래스 내부의 거리는 좁혀지도록 데이터를 투영시킵니다. 핵심 지표 : 클래스 내 분산 ($S_W$, Within-class scatter matrix) : 최소화해야 함 클래스 간 분산 ($S_B$, Between-class scatter matrix) : 최대화해야 함 수행 단계 : 전체 평균 및 각 클래스별 평균 벡터 계산 클래스 내 분산 행렬 $S_W$와 클래스 간 분산 행렬 $S_B$ 계산 $S_W^{-1} S_B$ 행렬의 고유치 분석을 수행하여 고유치가 큰 $m$개의 고유벡터 추출 구한 고유벡터들로 변환 행렬 $W$를 구성하여 투영 4. 거리 기반 차원 축소 및 선형변환의 한계 (1) 선형변환의 한계 데이터의 구조가 직선이나 평면으로 잘리지 않고 휘어져 있는 곡면(비선형 매니폴드 구조) 형태인 경우, 선형변환(PCA/LDA)으로는 고유의 데이터 구조를 보존하기 어렵습니다. (2) 거리 기반 차원 축소 기법 다차원 척도법 MDS (Multidimensional Scaling) : 데이터 개체 간의 거리(유클리드안 거리) 정보를 저차원 공간에서도 가급적 그대로 유지하도록 변환합니다. t-SNE : 고차원 공간에서 데이터 점들 사이의 확률적 친밀도(Similarity)를 유지하도록 저차원에 매핑하여 시각화에 널리 사용됩니다. Isomap : 단순 유클리드안 거리가 아닌, 데이터의 휘어진 공간 곡면을 따라가는 측지선 거리(Geodesic Distance)를 보존하며 차원을 축소합니다. 5. 오늘 배운 내용 요약 특징 추출 은 고차원 원본 데이터의 핵심 정보만 변환 함수를 이용해 저차원으로 압축하는 방법입니다. PCA 는 라벨 없이 데이터 분산을 최대화하는 비지도 기법이고, LDA 는 클래스 구분(분류) 성능을 극대화하는 지도 기법입니다.
ReAct 논문 은 언어 모델에게 생각(추론)과 행동을 번갈아 내게 하면 둘이 서로를 보완한다고 주장한다. 지금 에이전트들이 쓰는 "생각하고, 도구를 부르고, 결과를 보고, 다시 생각하는" 순서를 논문은 어떻게 실험했고 무엇이 나왔는지 원문 숫자로 정리했다. 들어가며: 논문 정보 저자는 프린스턴대 2명과 Google Research Brain 팀 5명, 모두 7명이고 Shunyu Yao가 제1저자다. arXiv에 2022년 10월 6일 처음 올라왔고 ICLR 2023에서 발표됐다. 실험의 주 모델은 PaLM-540B이고, 부록 표(Table 5)에서는 같은 ReAct 프롬프트를 GPT-3(text-davinci-002)로도 돌려 비교한다. 1부. 방법 생각·행동·관찰 ReAct가 과제를 푸는 기록, 곧 궤적(trajectory)은 매 단계를 Thought , Action , Observation 으로 적는다. 모델이 생각을 적고, 행동을 하나 고르고, 환경이 돌려준 관찰을 보고 다음 생각을 적는다. 생각은 환경을 바꾸지 않는다. 계획을 세우고, 관찰에서 필요한 정보를 뽑고, 다음 행동을 정하는 데 쓰인다. 행동 공간 지식 과제는 여러 문서를 거쳐 답해야 하는 질문 답변(HotpotQA)과 주장이 사실인지 판정하는 과제(Fever)다. 여기서는 논문이 만든 간단한 Wikipedia API를 쓴다. 행동은 셋이다. search[entity] 는 그 항목 문서의 첫 5문장을 돌려주고, 문서가 없으면 비슷한 항목 5개를 제안한다. lookup[string] 은 열린 문서에서 그 문자열이 든 다음 문장을 돌려준다(브라우저의 Ctrl+F와 같다). finish[answer] 는 답을 내고 끝낸다. 논문은 이 행동 공간이 최신 검색기보다 훨씬 약하다고 밝힌다. 사람이 Wikipedia를 다루는 방식을 흉내 내려는 설계라는 것이다. 비교 대상 비교 대상은 ReAct 궤적에서 일부를 지워 만든다. Standard : 생각·행동·관찰을 모두 지운 일반 프롬프트 CoT(Chain-of-Thought) : 행동과 관찰을 지우고 추론만 남긴 것 CoT-SC(Self-Consistency) : CoT 궤적 21개를 온도 0.7로 뽑아 다수결로 답을 고르는 것 Act : 생각을 지우고 행동과 관찰만 남긴 것 ReAct와 CoT-SC를 섞는 방법도 둘 시험했다. ReAct→CoT-SC 는 ReAct가 정해진 단계(HotpotQA 7단계, Fever 5단계) 안에 답을 못 내면 CoT-SC로 넘어간다. CoT-SC→ReAct 는 CoT-SC 표본 n개 중 다수 답이 n/2번 미만으로 나오면, 즉 모델 내부 지식만으로는 확신이 없으면 ReAct로 넘어간다. 2부. 지식 과제 — HotpotQA와 Fever HotpotQA는 정답과 정확히 같은지(EM, exact match)로, Fever는 정확도로 잰다. ReAct 단독은 Fever에서 CoT를 앞섰고(60.9 대 56.3) HotpotQA에서는 조금 뒤졌다(27.4 대 29.4). 가장 높은 점수는 두 방법을 섞은 쪽에서 나왔다. HotpotQA는 ReAct→CoT-SC가 35.1, Fever는 CoT-SC→ReAct가 64.6이었다. 참고로 같은 표의 지도 학습 최고 기록은 HotpotQA 67.5, Fever 89.5로, 프롬프트만 쓴 방법들과 차이가 컸다. 무엇이 맞고 무엇이 틀렸나 저자들은 HotpotQA에서 ReAct와 CoT의 궤적을 정답 50건, 오답 50건씩, 모두 200건을 골라 직접 분류했다(Table 2). 정답이었지만 추론이나 사실이 환각이었던 경우(거짓 양성)는 CoT가 14%, ReAct가 6%였다. 오답 가운데 환각이 원인인 경우는 CoT가 56%로 가장 큰 실패 유형이었고, ReAct는 0%였다. 반대로 추론 오류는 ReAct가 47%, CoT가 16%였다. 논문은 생각·행동·관찰을 번갈아 하는 구조가 근거를 단단하게 하는 대신 추론의 유연성을 줄였다고 본다. ReAct에만 있는 흔한 오류로 같은 생각과 행동을 되풀이하는 경우를 들고, 이를 추론 오류에 넣어 셌다. ReAct 오답의 23%는 검색 결과가 비었거나 쓸모없는 경우였다. 답은 맞았는데 정답 표기와 정확히 같지 않아 오답이 된 경우는 ReAct 29%, CoT 28%였다. 3부. 의사결정 과제 — ALFWorld와 WebShop ALFWorld는 글로 된 가상 집안 환경에서 "물건 찾아 옮기기" 같은 일을 해내는 과제이고, WebShop은 실제 상품 데이터로 만든 쇼핑 사이트에서 지시에 맞는 상품을 사는 과제다. 이 두 과제에서는 생각을 매 단계가 아니라 필요할 때만 드문드문 넣는다. ALFWorld에서 ReAct는 6번 시도 중 가장 좋은 회차가 성공률 71%로, Act의 최고(45%)와 BUTLER의 최고(37%)를 앞섰다. 가장 나쁜 ReAct 회차(48%)도 두 방법의 최고 회차보다 높았다. 6번의 대조 실험에서 Act 대비 상대 향상은 33~90%, 평균 62%였다. WebShop에서는 ReAct의 성공률이 40.0%로 Act(30.1%)보다 높았다. 이전 최고 기록은 사람이 단 궤적 1,012개로 학습한 모방 학습(IL, 29.1%)과 지시 10,587개로 더 학습한 모방+강화 학습(IL+RL, 28.7%)이었는데, 이보다 10%p 남짓 높다. 다만 숙련자의 59.6%와는 차이가 컸다. 논문은 사람이 상품을 훨씬 많이 살펴보고 검색어를 고쳐 쓴다고 설명한다. 마치며 ReAct는 생각·행동·관찰을 번갈아 적는 형식을 프롬프트로 시험했다. 지식 과제에서 ReAct 단독은 Fever에서 CoT를 앞서고 HotpotQA에서 조금 뒤졌으며, 둘을 섞은 방법이 가장 높았다. 실패 분석에서는 CoT보다 환각이 적고 추론 오류가 많았다. 의사결정 과제에서는 생각을 지운 Act보다 꾸준히 높았다. 이 시리즈의 SWE-agent 글 에서 다룬 에이전트도 매 단계 생각과 명령을 하나씩 내는데, SWE-agent 논문은 이 방식의 출처로 ReAct를 인용한다. 참고 ReAct: Synergizing Reasoning and Acting in Language Models — arXiv:2210.03629, ICLR 2023
함수를 다중 정의하는 이유는 사용자의 편의성과 확장성을 얻을 수 있기 때문입니다. 그런데 사용자를 편하게 해주기 위해서 제작자는 같은 일을 여러 번 반복해야 합니다. 더 큰 문제는 같은 일을 하는 코드가 다중 정의된 함수 여러 개로 존재한다는 것입니다. 이런 문제를 해결하기 위해서 C++에서는 함수 템플릿을 사용할 수 있습니다. template <typename T> 반환형식 함수이름(매개변수) { } 템플릿은 컴파일러가 실제 사용된 타입에 맞는 함수 템플릿 인스턴스를 생성합니다. template<typename T> void mySwap(T& a, T& b) { T temp = a; a = b; b = temp; } int main() { int a = 3, b = 5; float c = 2.5, d = 4.5; char e = 'x', f = 'y'; mySwap<int>(a, b); mySwap<float>(c, d); mySwap<char>(e, f); return 0; } 템플릿 함수의 호출자에서 형식을 지정하지 않아도 타입을 보고 컴파일러가 T를 자동 추론할 수 있습니다. template<typename T> void mySwap(T& a, T& b) { T temp = a; a = b; b = temp; } int main() { int a = 3, b = 5; float c = 2.5, d = 4.5; char e = 'x', f = 'y'; mySwap(a, b); mySwap(c, d); mySwap(e, f); return 0; } 그러나 함수의 기능에 따라 자동 추론이 불가능한 경우도 있습니다. template<typename T> T getValue() { return T{}; } 위 함수에 경우 매개변수가 없기 때문에 함수 인자를 통해 T를 추론할 수 없기 때문에 직접 지정해 줘야 합니다.