From Code to System: 2026년 AI 엔지니어링의 5계층

몇 년 전까지만 해도 “AI를 잘 쓴다”는 말은 곧 “프롬프트를 잘 쓴다”는 뜻이었습니다. 그런데 지금, 팀 단위로 코드를 쓰고 리뷰하고 배포까지 밀어붙이는 에이전트를 마주하다 보면 그 정의가 더 이상 성립하지 않는다는 감각이 옵니다. 모델을 다루는 기술이 아니라 모델을 감싸는 시스템이 핵심이 되었기 때문이죠.

이 글은 프롬프트 → 컨텍스트 → 하네스 → 오케스트레이션 → 평가(Evals)로 쌓이는 AI 엔지니어링의 5계층을, 각 계층에서 인간에게 남는 역할과 함께 정리합니다. 관통하는 방향은 하나입니다. From Code to System.

한 장으로 보는 AI 엔지니어링 5계층

각 계층은 앞 계층을 대체하지 않고 감쌉니다. 아래로 내려갈수록 AI는 단일 출력에서 시스템의 일부로 통합되죠.

flowchart LR
  P[프롬프트] --> C[컨텍스트]
  C --> H[하네스]
  H --> O[오케스트레이션]
  O --> E[평가]
  E -.피드백.-> P

마지막 계층인 평가가 다시 프롬프트로 돌아오는 점선이 중요합니다. AI 엔지니어링이 결국 루프라는 걸 보여 주는 화살표죠.

Layer 1 — 프롬프트 엔지니어링(Prompt Engineering): 작가로서의 인간

가장 먼저 자리잡았고 가장 오래 이야기된 계층입니다. “좋은 질문이 좋은 답을 만든다”는 전제 위에서, 역할 부여(너는 시니어 엔지니어다), Few-shot 예제, 단계별 지시(Chain-of-Thought) 같은 기법들이 한때 블로그 글의 주력 소재였죠.

이 계층의 인간은 작가입니다. 문장을 다듬고, 제약을 설계하고, 예시를 고르는 사람이죠. 지금도 대부분의 사용자 경험은 프롬프트 박스에서 출발합니다.

하지만 2025년을 지나오며 분위기가 달라졌습니다. Shopify의 Tobi Lutke는 2025년 6월 X에 이런 글을 남깁니다.

“I really like the term ‘context engineering’ over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.” — Tobi Lutke, 2025년 6월 ↗

Simon Willison 역시 같은 달 블로그에서 “I think ‘context engineering’ is going to stick” ↗라는 평을 남겼습니다. 프롬프트 박스 하나에 담기는 재치로는 더 이상 문제를 풀 수 없다는 공감대가 형성된 시점입니다.

Layer 2 — 컨텍스트 엔지니어링(Context Engineering): 사서로서의 인간

문제는 “모델이 무엇을 아는가”가 아니라 “지금 이 태스크를 풀기 위해 무엇을 보여 줘야 하는가”로 넘어옵니다. RAG, 메모리, 도구 호출 결과, 파일 시스템 접근 등 모델이 참고할 수 있는 “데이터 환경(data environment)” 전체가 설계 대상이 됩니다.

이 계층의 인간은 사서에 가깝습니다. 방대한 자료 중에서 태스크에 필요한 문서만 선반에서 꺼내 주고, 모델이 읽을 수 있는 형식으로 정리해 주는 역할이죠.

핵심 기술은 세 가지로 정리할 수 있습니다.

• RAG 파이프라인(Retrieval-Augmented Generation) — 벡터 검색, 리랭킹, 문서 청크 전략
• 메모리 계층(Memory Hierarchy) — 단기(턴 단위)·중기(세션)·장기(프로젝트) 메모리 분리
• 도구 출력 가공(Tool Output Shaping) — API/DB/코드 실행 결과를 모델이 쓰기 좋은 형태로 다듬기

개인 수준에서의 컨텍스트 설계 예시는 Karpathy의 LLM-Wiki가 잘 보여 줍니다. 매번 원문을 새로 던지는 대신, LLM이 직접 유지 관리하는 위키를 한 겹 둬서 정보가 쌓이도록 만드는 구조입니다.

Layer 3 — 하네스 엔지니어링(Harness Engineering): 안전 요원으로서의 인간

에이전트가 실제 파일을 고치고 명령어를 실행하고 외부 API를 호출하기 시작하면, 그때부터는 경계선이 설계 대상이 됩니다. 모델을 바꾸지 않고도 에이전트의 능력과 안전성을 좌우하는 “모델을 둘러싼 모든 것” — 이것을 최근 일부 문헌에서는 하네스(Harness)라고 부릅니다.

Martin Fowler의 Harness Engineering 아티클 ↗과 Red Hat Developer의 2026년 4월 기사 ↗에서는 이 관계를 다음과 같이 요약합니다.

Agent = Model + Harness

모델이 바뀌어도 하네스는 남고, 하네스가 바뀌면 같은 모델도 전혀 다른 에이전트가 됩니다.

이 계층의 인간은 안전 요원입니다. 에이전트가 어디까지 갈 수 있고, 어디부터는 막아야 하는지를 설계하죠.

• 샌드박스(Sandbox) — 격리된 파일 시스템, 네트워크 정책
• 가드레일(Guardrails) — 민감 파일 편집 금지, rm -rf 금지, 커밋 서명 요구
• 테스트 루프(Test Loop) — 타입 체크·테스트·린트 자동 실행 및 실패 시 자기수정
• 휴먼 인 더 루프(Human-in-the-Loop) — 위험 액션 앞 명시적 승인

철학적으로 보면 하네스 엔지니어링은 비결정성을 결정론으로 감싸는 작업입니다. 모델이 매번 같은 답을 주지 않더라도, 주변 시스템이 같은 조건과 같은 검증 기준을 강제하면 결과는 재현 가능해집니다.

Layer 4 — 오케스트레이션(Orchestration): 감독으로서의 인간

단일 에이전트가 해결할 수 없는 문제가 쌓이면서 등장한 계층입니다. 리서치, 작성, 리뷰, 배포를 서로 다른 에이전트가 분담하고, 오케스트레이터가 이를 조정합니다.

이 계층의 인간은 감독입니다. 대본을 쓰진 않지만 캐스팅을 하고, 씬 구성을 짜고, 누가 언제 무엇을 하게 할지 결정하죠.

대표적인 접근은 크게 세 갈래로 분화되는 중입니다.

• LangGraph — 그래프 기반 상태 관리, 복잡한 분기·합류에 강점
• CrewAI — 역할(Role)·목표(Goal) 중심, 팀 은유에 충실
• Anthropic Agent SDK 등 벤더 SDK — 모델 제공사별로도 에이전트 1급 지원이 확장되는 중

2025~2026년 사이 이 영역이 본격 프로덕션 성숙기에 들어섰다는 평이 많습니다. 프레임워크 비교는 datacamp의 CrewAI vs LangGraph vs AutoGen 분석 ↗에서 한눈에 정리해 두었습니다. 이 비교는 오픈소스 프레임워크 중심이며, 벤더 SDK 계열은 별도로 살펴보는 편이 낫습니다.

실전 사례는 제 블로그에서도 몇 편 다룬 적이 있습니다. 여러 모델을 태스크별로 갈아 끼우는 접근은 Perplexity Computer의 19개 모델 오케스트레이션에서, Claude Code 인스턴스들이 팀으로 묶이는 구조는 Claude Code Agent Teams 가이드에서 확인할 수 있습니다.

Layer 5 — 평가(Evals): 비평가로서의 인간

마지막 계층이자, 가장 저평가된 계층입니다. “좋아 보이는 답”과 “실제로 쓸 만한 답”은 다르고, 그 간극을 메우려면 평가 체계 자체가 시스템이 되어야 합니다.

이 계층의 인간은 비평가입니다. 무엇이 좋은 답인지 정의하고, 그 정의를 재현 가능한 지표로 환원하는 역할이죠.

핵심 구성 요소는 다음과 같습니다.

• 데이터셋 큐레이션(Dataset Curation) — 실제 사용 로그 기반 대표 샘플
• 자동 판정(Automated Judgment) — LLM-as-a-Judge, 규칙 기반 체커, 단위 테스트
• 관측성(Observability) — 트레이싱, 프롬프트·버전·컨텍스트 메타데이터 수집

LLM이 LLM을 평가한다는 접근은 Zheng et al.의 “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (NeurIPS 2023) ↗ 이후 표준적인 기법으로 자리잡았습니다. 논문은 GPT-4 판정자가 인간 평가와 80% 이상 일치한다는 결과를 보고했고, 공개 구현은 FastChat의 llm_judge 모듈 ↗에 공개되어 있습니다.

흐름을 관통하는 개념들

바이브 코딩(Vibe Coding)

Andrej Karpathy가 2025년 2월 X에 처음 쓴 표현입니다.

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — Karpathy, 2025년 2월 ↗

이 표현은 이후 개발자 커뮤니티를 넘어 일반 매체에서도 회자될 만큼 빠르게 확산됐습니다. 흥미로운 건 Karpathy 본인도 1주년 리트로스펙티브 ↗에서 더 정확한 용어로 agentic engineering을 제시했다는 점입니다. 직접 발언을 빌리면 “agents who do and acting as oversight” — 개발자는 99% 코드를 쓰는 사람이 아니라 에이전트를 조율하고 감독하는 사람이라는 관점입니다. 개념은 남되 이름은 진화 중이라는 뜻이죠.

하네스 엔지니어링의 철학

Layer 3을 한 줄로 압축하면 이렇습니다: 비결정성을 결정론으로 감싼다. 모델이 확률적으로 흔들려도, 주변 시스템의 검증 경로가 일정하면 전체는 결정론적으로 행동합니다. 하네스는 이 “감싸는 힘”의 이름이죠.

AI Native

a16z는 AI Native를 “AI를 처음부터 핵심 기능으로 설계한 애플리케이션” ↗으로 정의합니다. 중요한 차이는 배치가 아니라 설계 원점입니다. 기존 앱에 AI 기능을 얹은 것이 아니라, AI가 없으면 애초에 성립하지 않는 제품을 말하죠.

바이브 코딩의 UI 판본이라 할 만한 사례는 Google Stitch의 바이브 디자인에서도 관찰할 수 있습니다. 같은 철학이 다른 도메인에서 반복되는 중입니다.

개발 속도 vs 코드 품질의 긴장

바이브 코딩이 퍼지며 함께 회자되는 주제는 생산된 코드의 품질과 유지보수성(Quality & Maintainability)입니다. 일부 개발자 커뮤니티에서는 “품질세(Quality Tax)” 같은 표현으로 이 긴장을 부르기도 하지만, 아직 업계 공용어로 정착한 표현이라고 보기는 어렵습니다. 중요한 건 용어보다, “빠르게 만든 코드는 언젠가 평가·리뷰·하네스에서 값을 치른다”는 구조적 사실 쪽이죠.

From Code to System — 2026년의 방향

위 5계층을 한 줄로 관통하는 표현이 From Code to System입니다. 코드를 쓰는 기술에서, AI를 품은 시스템을 설계하는 기술로 무게중심이 옮겨 갔다는 뜻이죠.

이 변화가 2026년 현재 가장 또렷하게 드러나는 세 가지 장면은 이렇습니다.

• Agentic Workflows — 단발 응답이 아니라 반복 루프를 1급 시민으로 본다
• LLM-as-a-Judge — 평가 자체를 AI가 수행하고, 사람은 평가의 평가자가 된다
• 오케스트레이터로서의 개발자 — 한 줄의 코드보다, 에이전트 간 책임 경계를 긋는 일이 더 중요해진다

이 관점에서 보면 Layer 1~5는 독립된 단계가 아니라, 하나의 시스템을 이루는 다섯 계층입니다.

마무리

프롬프트만 잘 쓰면 되던 시기는 짧았습니다. 지금 AI 엔지니어링의 중심은 프롬프트 상자 밖, 즉 컨텍스트를 공급하고, 하네스로 감싸고, 여러 에이전트를 조율하고, 평가로 검증하는 시스템 전체로 넘어와 있습니다.

참고 자료

• Andrej Karpathy, “Vibe Coding” (X, 2025년 2월) ↗
• Andrej Karpathy, 1주년 리트로스펙티브 — agentic engineering (X, 2026년 2월) ↗
• Tobi Lutke, “Context Engineering” (X, 2025년 6월) ↗
• Simon Willison, “Context Engineering” (2025-06-27) ↗
• Martin Fowler, “Harness Engineering” ↗
• Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (NeurIPS 2023) ↗