"실전 사례로 배우는 하네스 엔지니어링 (4/4) — OpenAI, Anthropic, Vercel, GitHub, Cursor는 어떻게 설계했나"

-

하네스 엔지니어링을 이해하는 가장 빠른 길은 추상 이론보다 공개 사례를 비교하는 것이다. 같은 "AI 에이전트"라는 말 아래서도 OpenAI는 런타임을, Anthropic은 작업자 운영 표면을, Vercel은 배포와 제품화를, GitHub는 PR 워크플로우를, Cursor는 클라우드 작업장을 전면에 둔다. 중요한 차이는 모델이 아니라 어디를 작업 표면으로 삼았는가에 있다.

핵심 요약

  • 공개 사례를 읽을 때는 모델 성능보다 실행 환경, 도구 표면, 검증 artifact, handoff, 권한 경계 다섯 축이 더 중요하다.
  • OpenAI는 에이전트를 위한 표준 런타임 부품을 강하게 밀고 있다. Responses API, shell tool, hosted container workspace, App Server가 그 표면이다.
  • Anthropic은 Claude Code와 Research 사례에서 작업 분리와 컨텍스트 분리를 전면에 둔다. subagent, hook, permission, background task, orchestrator-worker 패턴이 중심이다.
  • Vercel은 에이전트를 "코드 생성기"보다 배포 가능한 제품 표면에 가깝게 다룬다. v0, AI SDK ToolLoopAgent, Vercel MCP가 한 줄로 이어진다.
  • GitHub는 에이전트를 PR 워크플로우 속에 넣는다. branch, commit, review, Actions log, MCP 서버가 모두 검토 가능한 협업 단위로 붙어 있다.
  • Cursor는 클라우드 VM과 handoff UX를 전면에 세운다. 에이전트가 만든 결과를 screenshot, demo, video artifact로 검증하게 만드는 점이 특히 강하다.
  • 우리 실무 관점의 결론은 간단하다. 좋은 하네스는 더 많은 능력을 주기보다, 사람이 검토하기 쉬운 작업장과 artifact를 만든다.

1. 이 글을 읽는 관점: 회사 소개가 아니라 설계 표면 비교

기능 나열로 읽으면 다 비슷해 보인다. "도구를 부를 수 있다", "긴 작업을 할 수 있다", "코드를 고친다", "MCP를 지원한다" 같은 설명만 남기 쉽다. 하지만 하네스 엔지니어링 관점에서는 더 중요한 질문이 있다.

  1. 에이전트는 어디에서 일하는가
  2. 어떤 도구 표면을 기본값으로 삼는가
  3. 사람이 무엇을 보고 결과를 검토하는가
  4. 긴 작업은 어떻게 이어지는가
  5. 권한과 위험은 어디서 잘리는가

이번 편은 이 다섯 질문으로 공개 사례를 읽는다.

2. 다섯 사례를 한 표로 먼저 보면

회사 에이전트의 기본 작업장 강하게 드러난 하네스 포인트 실무적으로 배울 점
OpenAI API 런타임 + container workspace + App Server tool loop, shell, hosted workspace, cross-surface protocol 에이전트 기능을 제품별 UI보다 공통 실행 엔진으로 묶는다
Anthropic Claude Code 작업면 + subagent + hook + background task context isolation, permission layering, orchestrator-worker 긴 작업은 메모리보다 역할 분리와 작업 분리가 먼저다
Vercel v0 제품 표면 + AI SDK + 배포 경로 + Vercel MCP prompt-to-product, deployability, remote MCP with OAuth 생성 결과가 바로 배포/운영으로 이어져야 제품성이 생긴다
GitHub GitHub Actions 기반 cloud agent + branch/PR/review PR-native workflow, logs, MCP defaults, human review loop 에이전트를 채팅이 아니라 코드 리뷰 프로세스에 넣는다
Cursor local + cloud agents + remote machine + demo artifact isolated machine, parallel agents, handoff UX, visual proof 장시간 코딩은 "답변"보다 검증 가능한 작업 흔적이 더 중요하다

이 표만 봐도 각 회사가 어디를 핵심 표면으로 삼는지 다르다.

3. OpenAI: 에이전트의 공통 런타임을 표준 부품으로 만든다

2026년 2월 4일 OpenAI는 Codex App Server를 설명하며, 웹 앱, CLI, IDE extension, macOS app이 모두 같은 Codex harness 위에 있다고 공개했다. 이어 2026년 3월 11일에는 Responses API에 shell tool과 hosted container workspace를 붙여, 모델이 제안한 행동을 격리된 실행 환경에서 처리하는 구조를 설명했다.

이 사례의 핵심은 OpenAI가 에이전트를 "대화형 모델"의 확장으로 보기보다, 공통 실행 루프를 가진 런타임으로 본다는 점이다.

공개 표면에서 보이는 특징

  • 모델은 직접 파일시스템을 만지지 않고, tool call을 제안한다.
  • 플랫폼은 shell tool, filesystem, structured storage, restricted network 같은 실행 환경을 소유한다.
  • Codex App Server는 여러 클라이언트 표면이 같은 하네스를 재사용하게 만든다.
  • 즉, 제품 간 차이는 UI일 수 있어도, 실행 핵심은 한곳으로 모은다.

무엇을 배워야 하나

OpenAI식 설계는 "에이전트 기능을 어디에 복제할 것인가"보다 "어떤 루프를 공통 엔진으로 만들 것인가"에 가깝다.

이 접근의 장점은 분명하다.

  • CLI, IDE, 앱이 서로 다른 규칙을 갖기보다 같은 동작 의미를 공유할 수 있다.
  • tool loop, diff, streaming progress, workspace inspection 같은 기능을 제품마다 다시 짜지 않아도 된다.
  • 권한과 실행 제약을 UI가 아니라 런타임에서 더 일관되게 강제할 수 있다.

우리 실무로 옮기면 교훈은 이렇다.

에이전트 경험이 여러 표면으로 퍼질 예정이라면, prompt 템플릿을 복제하기보다 실행 루프와 artifact 형식을 먼저 공통화해야 한다.

4. Anthropic: 긴 작업은 subagent와 운영 규칙으로 버틴다

Anthropic의 공개 표면은 다소 다르다. Claude Code docs는 subagent가 별도 context window, 별도 tool permission을 가질 수 있다고 설명하고, hooks docs는 PreToolUse, PostToolUse, SubagentStop 같은 이벤트 지점을 공식화한다. 2025년 6월 13일 공개한 Research engineering 글은 lead agent가 subagent를 병렬로 띄우는 orchestrator-worker 패턴을 공개했다. 2025년 9월 29일 Claude Code background 작업 소개도 장시간 작업 지속성을 한 축으로 내세웠다.

즉 Anthropic은 에이전트를 위한 핵심 차별점으로 작업 분리와 운영 장치를 공개 표면에 올려놓는다.

공개 표면에서 보이는 특징

  • subagent는 독립된 context window를 갖고, 필요한 도구만 허용할 수 있다.
  • hook은 도구 전후 지점에 정책과 자동화를 걸 수 있는 강제 표면이다.
  • Research 사례는 lead agent가 병렬 worker를 관리하는 구조를 노출한다.
  • background task는 긴 실행과 사람의 비동기 협업을 염두에 둔다.

무엇을 배워야 하나

Anthropic 사례가 주는 가장 큰 교훈은 "장시간 에이전트 = 메모리 무한 확장"이 아니라는 점이다. 오히려 더 중요한 것은 아래다.

  • context pollution을 줄이는 분리
  • 역할별 tool permission
  • 중간 단계 자동 점검
  • 주 작업자와 하위 작업자의 경계

즉 Anthropic은 기억을 키우는 것보다 일을 잘 나누고, 규칙을 언제 강제할지 정하는 일에 더 많은 설계 무게를 둔다.

우리 실무 관점에서는 이 문장이 남는다.

긴 작업을 잘하게 하려면 하나의 거대한 지시문보다, 좁은 역할과 좁은 권한을 가진 작업자를 여러 층으로 배치하는 편이 낫다.

5. Vercel: 생성과 배포가 끊기지 않는 제품 표면을 만든다

Vercel은 OpenAI나 Anthropic처럼 "코딩 에이전트 자체"를 전면 브랜드로 밀기보다, 생성 결과가 곧 제품과 배포로 이어지는 표면을 보여 준다. v0 docs는 자연어로 UI와 앱을 만들고 Vercel에 배포할 수 있다고 설명한다. Vercel Academy의 agent skeleton은 AI SDK ToolLoopAgent를 통해 prompt -> tool call -> execute -> result -> next step 루프를 명시한다. 2026년 2월 12일 기준 Vercel MCP docs는 https://mcp.vercel.com을 공식 remote MCP with OAuth로 공개하고, 프로젝트/배포/로그 분석을 연결한다.

여기서 중요한 점은 Vercel이 agent를 runtime primitive + deploy surface + operational connector로 묶는다는 것이다.

공개 표면에서 보이는 특징

  • v0는 "만들기"와 "배포하기"가 한 제품 이야기 안에 들어 있다.
  • AI SDK는 툴 루프를 개발자에게 직접 노출한다.
  • Vercel MCP는 외부 에이전트가 프로젝트와 배포 로그까지 다룰 수 있게 한다.
  • 결과적으로 생성, 실행, 운영이 같은 제품 흐름 안에서 이어진다.

무엇을 배워야 하나

Vercel 사례의 강점은 "에이전트가 뭔가 만들었다"에서 끝나지 않는다는 점이다. 배포 가능성과 운영 연결성이 처음부터 표면에 들어가 있다.

즉 이 회사가 보여 주는 하네스 교훈은 다음과 같다.

  • 코드 생성만으로는 제품성이 완성되지 않는다.
  • 실제 가치가 생기는 지점은 generate -> run -> deploy -> inspect가 이어질 때다.
  • MCP도 문서 검색용 부가기능이 아니라 운영 시스템에 들어가는 연결면으로 봐야 한다.

실무적으로는 이런 판단으로 바꿔 읽을 수 있다.

에이전트가 낸 산출물이 바로 다음 운영 단계로 이어지지 않는다면, 그 하네스는 아직 반쪽짜리일 가능성이 높다.

6. GitHub: 에이전트를 PR 워크플로우 안에 넣는다

GitHub Copilot cloud agent docs는 에이전트가 GitHub Actions-powered environment에서 저장소를 조사하고, 계획을 만들고, 브랜치에서 수정하고, 필요하면 PR까지 연다고 설명한다. MCP 관련 docs는 GitHub와 Playwright MCP 서버가 기본값으로 잡혀 있다고 밝히며, GitHub 서버는 현재 저장소에 대한 read-only token을 기본으로 쓴다. review docs는 Copilot이 만든 PR도 일반 PR처럼 철저히 검토해야 하고, 일부 승인 정책은 자동 충족되지 않는다고 분명히 적는다.

즉 GitHub의 하네스 철학은 아주 선명하다. 에이전트를 IDE 대화창보다 branch, commit, PR, review, workflow log 안에 넣는다.

공개 표면에서 보이는 특징

  • 코딩과 반복은 GitHub 위에서 진행된다.
  • 작업 단위는 session이면서 동시에 branch/PR artifact다.
  • 기본 MCP 서버도 GitHub 데이터와 Playwright 검증처럼 리뷰 친화적이다.
  • 사람은 최종 리뷰어로 남고, 로그와 PR이 검토 표면이 된다.

무엇을 배워야 하나

GitHub 사례가 좋은 이유는 "에이전트를 더 똑똑하게 만들었다"는 설명보다, 팀이 이미 익숙한 협업 artifact를 유지하기 때문이다.

그 결과 얻는 이점은 크다.

  • 새 전용 UI를 배우지 않아도 된다.
  • 작업 이력, diff, workflow, review comment가 기존 개발 문화와 붙는다.
  • 사람 승인과 조직 정책을 자연스럽게 재사용할 수 있다.

우리 관점의 교훈은 이것이다.

팀 협업형 에이전트는 대화 품질보다 PR 품질로 읽는 편이 더 현실적이다.

7. Cursor: 클라우드 작업장과 검증 artifact를 전면에 둔다

Cursor는 2026년 2월 24일 "agents can now control their own computers" 발표에서 cloud sandbox, screenshot, video artifact, browser testing을 전면에 내세웠다. 2026년 4월 2일 Cursor 3 발표는 multi-repo layout, local/cloud handoff, sidebar에서의 병렬 agent 관리, GitHub·Slack·Linear 등 다중 표면 연결을 강조했다. background agents docs는 isolated ubuntu-based machine, GitHub branch handoff, environment.json, install/start/terminal 분리를 설명한다.

즉 Cursor는 에이전트를 위한 핵심 표면을 클라우드에서 실제로 일하는 작업장으로 본다.

공개 표면에서 보이는 특징

  • remote machine이 기본이며, 패키지 설치와 백그라운드 프로세스를 포함한 환경 구성이 있다.
  • cloud agent가 만든 결과를 screenshot, demo, video로 검증한다.
  • local과 cloud 사이 handoff UX를 명시적으로 설계한다.
  • 여러 에이전트를 한 UI에서 병렬 관리한다.

무엇을 배워야 하나

Cursor 사례는 "정답 텍스트"보다 작업 결과를 보여 주는 artifact를 중요하게 본다. 이건 매우 실무적이다.

  • UI 작업이면 screenshot이 낫다.
  • 브라우저 상호작용이면 video artifact가 낫다.
  • 장시간 수정이면 remote branch handoff가 낫다.

즉 Cursor는 에이전트의 결과를 사람이 믿게 만들려면 설명문보다 보여 줄 수 있는 증거가 필요하다고 설계한 셈이다.

실무적 교훈은 선명하다.

에이전트 출력이 사람이 바로 검토 가능한 형태로 남지 않으면, 장시간 자동화일수록 신뢰는 오르지 않는다.

8. 다섯 사례를 나란히 놓으면 보이는 공통 패턴

이제 공통점을 보자. 회사는 다르지만 반복해서 나타나는 하네스 원칙이 있다.

8-1. 에이전트는 답변기가 아니라 작업장 안의 실행자다

OpenAI는 container workspace, Cursor는 cloud machine, GitHub는 Actions environment, Vercel은 deploy surface, Anthropic은 Claude Code 작업면을 전면에 둔다. 모두 "모델 답변"만으로 끝나지 않는다.

8-2. 도구가 많다는 사실보다 도구 표면이 중요하다

GitHub는 기본 MCP 서버를 좁게 잡고, Anthropic은 subagent별 tool permission을 강조하고, OpenAI는 shell tool과 workspace를 명시하고, Vercel은 deploy/log 중심 연결을 드러낸다. 전부 선택 가능한 표면을 설계한다.

8-3. 긴 작업은 메모리보다 handoff 구조가 더 중요하다

Cursor의 local/cloud handoff, GitHub의 PR artifact, Anthropic의 subagent 분리, OpenAI의 cross-surface harness 재사용은 모두 세션이 바뀌어도 일이 이어지게 만든다.

8-4. 사람 검토를 위한 artifact가 반드시 있다

  • OpenAI: diff와 progress stream
  • Anthropic: hook과 subagent 구조, background 운영 표면
  • Vercel: deployable output과 project/deployment/log
  • GitHub: branch, commit, PR, review, workflow log
  • Cursor: screenshot, demo, video, branch handoff

좋은 하네스는 에이전트만 이해하는 내부 상태가 아니라, 사람이 검토 가능한 외부 흔적을 남긴다.

9. 우리 실무에 바로 가져올 수 있는 체크리스트

이 다섯 사례를 보고 바로 적용할 수 있는 것은 의외로 크지 않다. 하지만 강하다.

1. 에이전트의 기본 작업장을 먼저 정한다

채팅창인지, 저장소인지, PR인지, 배포 파이프라인인지, 원격 머신인지부터 정해야 한다. 작업장이 흐리면 나머지 설계가 다 흔들린다.

2. 도구 수보다 도구 표면을 줄인다

검색, 읽기, 수정, 실행, 발행, 배포를 분리하라. 이름과 위험도가 섞이면 모델보다 사람이 먼저 헷갈린다.

3. 긴 작업은 대화가 아니라 artifact로 이어받는다

plan, handoff, branch, PR, screenshot, deploy log 같은 것이 다음 세션의 출발점이 돼야 한다.

4. 검증 결과는 사람 눈에 바로 보이게 만든다

테스트 통과 문장보다 diff, screenshot, preview URL, workflow log가 더 강한 검증 표면일 때가 많다.

5. 권한은 UI 설명이 아니라 실행 경계로 강제한다

승인, sandbox, branch isolation, read-only token, remote OAuth, hook 같은 것이 실제 안전장치다.

10. 가장 흔한 오해

"좋은 사례는 결국 더 많은 기능을 넣은 사례다"

아니다. 대부분의 강한 사례는 기능 수보다 실행 표면과 검토 표면을 선명하게 만든다.

"장시간 에이전트의 핵심은 더 긴 컨텍스트다"

아니다. 공개 사례를 보면 더 중요한 것은 handoff, isolation, artifact, permission이다.

"MCP를 붙이면 하네스가 좋아진다"

부분적으로만 맞다. MCP는 연결 표준일 뿐이다. 무엇을 연결하고 어떤 권한으로 노출할지가 더 중요하다.

11. 결론: 공개 사례는 모두 같은 말을 다른 제품 언어로 반복한다

OpenAI, Anthropic, Vercel, GitHub, Cursor는 표면 언어가 다르다.

  • OpenAI는 런타임 언어로 말한다.
  • Anthropic은 작업자 운영 언어로 말한다.
  • Vercel은 배포 가능한 제품 언어로 말한다.
  • GitHub는 협업과 리뷰 언어로 말한다.
  • Cursor는 클라우드 작업장과 검증 artifact 언어로 말한다.

하지만 다섯 사례를 하네스 관점으로 다시 읽으면, 결국 같은 원칙을 반복한다.

좋은 에이전트는 더 좋은 모델에서만 나오지 않는다. 더 선명한 작업장, 더 좁은 도구 표면, 더 강한 handoff, 더 검토 가능한 artifact, 더 분명한 권한 경계에서 나온다.

이것이 D 시리즈 전체의 결론이기도 하다. 패턴은 반복 가능해야 하고, 결정은 운영 가능한 구조여야 하며, ACI는 작업대를 선명하게 만들어야 한다. 실제 사례는 그 세 가지가 한곳에서 만날 때 에이전트 품질이 올라간다는 사실을 보여 준다.

참고 자료

  • docs/blog_series_하네스엔지니어링_총괄_design.md
  • sources/260518_하네스엔지니어링_15장_블로그활용노트.md
  • OpenAI, Unlocking the Codex harness: how we built the App Server (2026-02-04) — https://openai.com/index/unlocking-the-codex-harness/
  • OpenAI, From model to agent: Equipping the Responses API with a computer environment (2026-03-11) — https://openai.com/index/equip-responses-api-computer-environment/
  • Anthropic, How we built our multi-agent research system (2025-06-13) — https://www.anthropic.com/engineering/multi-agent-research-system
  • Anthropic Docs, Subagents / Hooks reference / Security (2026-05-19 확인) — https://docs.anthropic.com/en/docs/claude-code/sub-agents / https://docs.anthropic.com/en/docs/claude-code/hooks / https://docs.anthropic.com/en/docs/claude-code/security
  • Vercel Docs, v0 / Use Vercel's MCP server / Vercel Academy Agent Skeleton (2026-05-19 확인, 문서 기준 2026-02-12 업데이트 포함) — https://v0.app/docs / https://vercel.com/docs/agent-resources/vercel-mcp / https://vercel.com/academy/filesystem-agents/agent-skeleton
  • GitHub Docs, About Copilot cloud agent / MCP and Copilot cloud agent (2026-05-19 확인) — https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent / https://docs.github.com/en/copilot/concepts/agents/cloud-agent/mcp-and-cloud-agent
  • Cursor, Cursor agents can now control their own computers (2026-02-24) / Meet the new Cursor (2026-04-02) — https://cursor.com/blog/agent-computer-use / https://cursor.com/blog/cursor-3

이 글은 패턴·전략·사례 시리즈의 4/4 편입니다. 앞선 편: 하네스 패턴 12선, 하네스 설계의 7가지 결정, 하네스가 전부다.

시리즈 전체 안내: 하네스 엔지니어링 시리즈 안내

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »