컨텍스트 엔지니어링 뜻, 프롬프트⁠·에이전틱⁠·하네스와 차이

컨텍스트 엔지니어링이 무슨 뜻인지, 프롬프트⁠·에이전틱⁠·하네스 엔지니어링과는 어떻게 다른지 회사 생활에 빗대 설명합니다. 새 용어가 나올 때마다 따라가느라 불안했다면, 네 개념이 사실은 직장에서 매일 겪는 일과 같은 구조라는 점부터 잡고 가면 됩니다. AI를 잘 쓰는 사람의 조건과 오늘 바로 해 볼 첫걸음도 담았습니다.

새 AI 용어가 나올 때마다 불안하다면

프롬프트를 겨우 익혔더니 컨텍스트 엔지니어링이 나옵니다. 그걸 찾아보면 에이전틱 엔지니어링이 있고, 이어서 하네스 엔지니어링까지 등장합니다. "나만 뒤처지는 건가?" 싶어지는 게 당연합니다.

그런데 이 개념들은 회사에서 일해 본 사람이라면 이미 다 아는 내용입니다. 이름이 새로울 뿐, 일을 시키고 자료를 건네고 팀을 꾸리고 규칙으로 묶는 과정과 똑같습니다. 그러니 용어가 새로 나올 때마다 흔들릴 필요는 없습니다. 멈춰야 하는 것은 공부 자체가 아니라 새 용어를 불안하게 쫓아다니는 태도입니다. 배우려는 마음과 따라가려는 의지가 없으면 아무리 좋은 도구도 시작조차 안 됩니다.

도구만 잘 쓰면 AI 고수가 될까

요즘 회사들은 팀 단위로 AI 도구를 도입합니다. 예를 들어 Anthropic의 Claude 팀 플랜은 2명부터 150명까지 쓰는 요금제로, 공식 요금표 기준 프리미엄 좌석이 월 결제 시 1인당 월 125달러(연 결제 시 월 100달러), 일반 좌석이 월 25달러(연 결제 시 월 20달러)입니다. 요금은 바뀔 수 있으니 도입 전에는 공식 요금 안내를 확인해야 합니다.

비싼 도구를 들여놓으면 팀원들은 이제 도구만 잘 쓰면 AI 고수가 될 거라고 기대하기 쉽습니다. 이건 착각입니다. 도구는 같아도 결과를 가르는 것은 일을 어떻게 맡기고 어떤 구조로 돌리느냐입니다. 그 구조를 단계별로 부르는 이름이 아래 네 가지입니다.

김과장 이야기로 보는 네 가지 엔지니어링

경영기획팀 김과장이 일하는 과정에 하나씩 대입해 보면 차이가 선명해집니다.

프롬프트 엔지니어링: 지시를 구체적으로

상사가 김과장에게 한마디 합니다. "이 기획안 평가해 줘."

오래 일한 김과장은 알아서 합니다. 팀의 신사업 타당성 가이드라인을 적용해 초기 투자, 회수 기간, 손익분기점, 이익률을 뽑아 보고서를 만듭니다.

그런데 같은 한마디를 AI에게 하면 그런 결과는 절대 나오지 않습니다. AI는 김과장이 어느 팀 사람인지, 상사 스타일이 어떤지, 팀 평가 기준이 뭔지 모르기 때문입니다.

그래서 필요한 것이 세 가지입니다.

• 역할을 알려 준다
• 목적을 명확히 한다
• 기준을 제시한다

프롬프트 엔지니어링은 "너는 지금 이런 사람이고, 이런 기준으로 답하라"고 AI에게 지시를 구체적으로 세팅해 주는 일입니다. 예를 들면 이렇게 씁니다.

너는 우리 회사 경영기획팀에서 신사업 타당성을 검토하는 담당자야.
목적: 첨부한 기획안을 임원 보고 전에 사업성 관점에서 평가하는 것.
기준: 초기 투자, 회수 기간, 손익분기점, 이익률 네 항목을 표로 정리하고, 항목마다 근거 숫자를 기획안에서 찾아 붙여 줘. 기획안에 없는 숫자는 "자료 없음"으로 적어.

컨텍스트 엔지니어링: 회사 내부 교과서를 쥐여 주기

이제 김과장에게 고민이 생깁니다. 매번 이렇게 긴 질문을 던지기 귀찮고, AI가 가끔 엉뚱한 데서 자료를 끌어와 틀린 답을 냅니다.

그래서 팀의 신사업 타당성 분석 가이드라인을 아예 지식으로 넣어 버립니다. 필요한 내부 규정과 팀에 쌓인 지식을 바탕으로 AI가 움직이게 하는 것, 이것이 컨텍스트 엔지니어링입니다. 한마디로 AI에게 회사 내부 교과서를 쥐여 주는 것입니다.

컨텍스트(context)는 AI가 답을 만들 때 참고하는 배경 정보 전체를 말합니다. 실제로는 Claude의 프로젝트에 가이드라인 문서를 올려 두거나, 사내 문서를 검색해 답에 붙이는 RAG(검색 증강 생성, 질문과 관련된 문서를 찾아 AI에게 함께 넘기는 방식)를 쓰거나, 에이전트가 늘 읽는 규칙 파일(Claude Code의 CLAUDE.md 같은 파일)을 두는 식으로 구현합니다. 프롬프트가 "그때그때 하는 말"이라면 컨텍스트는 "늘 손에 쥐여 주는 자료"입니다.

에이전틱 엔지니어링: AI로 드림팀 꾸리기

기획팀이 기획안을 냈다고 일이 끝나지는 않습니다. 개발, 디자인, QA, 마케팅, 영업, 재무가 각자 움직여야 서비스가 나옵니다.

AI도 마찬가지로 한 AI가 다 할 수는 없습니다. 디자인 책임자(CDO), 기술 책임자(CTO), 재무 책임자(CFO)처럼 역할을 나눠 에이전트(스스로 여러 단계를 나눠 일하는 AI)를 설계하고, 각 역할이 최선의 결과를 내도록 계속 고치고 보완합니다. 이것이 에이전틱 엔지니어링이고, 비유하자면 AI로 드림팀을 꾸리는 일입니다.

하네스 엔지니어링: 벗어나지 못하게 울타리 치기

여기서부터가 진짜입니다. 팀들이 한자리에 모이면 저절로 잘 굴러갈까요?

현실은 이렇습니다. 기획팀이 신사업을 하자고 하면 개발팀은 속으로 지금도 일이 산더미라고 생각하고, 재무팀은 손익 관리가 늘어난다고 짜증을 냅니다. 회의실에서는 다들 "좋아요, 검토해 볼게요" 하지만 문 닫고 나가면 딴 얘기를 합니다.

AI 에이전트도 똑같습니다. 여러 에이전트를 설계해 놓고 알아서 협력할 거라고 생각하면 큰일 납니다. "이렇게 해, 이거 하지 마"라고 말로만 해서는 안 먹히는 경우가 많고, 상황이 조금만 바뀌어도 엉뚱한 방향으로 흐릅니다.

그래서 회사로 치면 대표이사가 필요합니다. 각 팀이 엇나가지 않게 통제하고 조율하며, 꼭 지킬 규칙은 아예 시스템으로 강제하는 역할입니다. 하네스 엔지니어링은 AI 에이전트들이 정해 둔 시스템 규칙에서 벗어나지 못하도록 울타리를 설계하는 것입니다. 하네스(harness)는 원래 말에 채우는 마구라는 뜻입니다. 작업 전후에 자동으로 도는 검사, 통과하지 못하면 다음 단계로 못 넘어가는 관문, 에이전트가 건드릴 수 없는 파일 범위 같은 장치가 여기에 들어갑니다.

네 가지 엔지니어링을 한 줄씩

• 프롬프트: 일을 시킬 때 역할⁠·목적⁠·기준을 말해 준다
• 컨텍스트: 팀 규정과 지식을 넣어 준다
• 에이전틱: 역할별로 팀을 꾸린다
• 하네스: 대표이사처럼 규칙으로 묶는다

네 가지 모두 직장에서 매일 겪는 일입니다. 순서도 그대로입니다. 지시를 잘하는 데서 시작해, 자료를 쥐여 주고, 팀을 꾸리고, 마지막에 규칙으로 묶습니다.

AI를 잘 쓰는 사람의 조건 세 가지

첫째, 도구를 넘어 설계를 합니다. Claude를 잘 쓰는 사람이 아니라 Claude로 구조를 짜는 사람이 되어야 합니다.

둘째, 모든 분야의 기초를 두루 압니다. 마케팅, 개발, 재무, 기획 같은 각 분야의 언어를 알아야 AI와 제대로 대화가 됩니다. "딸각"(클릭 한 번)으로 끝내는 게 아니라 왜 그렇게 동작하는지를 먼저 익히는 것이 핵심입니다. 비개발자라면 개발 기초를, 개발자라면 기획과 재무의 기초를 익혀 두는 식입니다. 물론 자기 전문 분야에서는 프로가 되어야 합니다.

셋째, 문제를 찾아 끝까지 추적합니다. 문제가 왜 생겼는지, 어떻게 풀지 가정을 세우고, 실행하고, 결과를 보고, 다시 조정합니다. 이 사이클을 AI와 함께 돌릴 수 있는 사람이 진짜 고수입니다.

다른 시각도 있습니다. 하네스⁠·프롬프트⁠·컨텍스트 엔지니어링은 결국 표면적인 활용 기술이고, 본질은 지금 세대 AI가 무엇을 못하는지 한계를 아는 데서 출발해야 한다는 견해입니다. 이 관점에서는 끝까지 파고드는 지적 집요함, 그리고 내 지식⁠·AI의 능력⁠·문제의 구조라는 세 가지 지도를 함께 갖추는 것이 더 중요하다고 봅니다.

네 단계를 실제로 쌓는 예: 컨설팅 스타일 PPT 스킬

네 개념이 실제 작업에서 어떻게 쌓이는지는 컨설팅 스타일 PPT를 만드는 스킬(AI에게 특정 작업 방법을 알려 주는 파일 묶음)을 설계하는 예로 보면 쉽습니다. 구성은 이렇습니다.

• 스킬 본문 파일(SKILL.md): PPT 전체 작업의 6단계 워크플로를 적은 파일
• 프롬프트 파일: 모든 PPT에 공통으로 적용할 품질 기준
• 컨텍스트 라이브러리 파일: 요청을 분석해 분기 실적 분석인지 전략 제안인지 유형별로 자동 매칭하는 규칙
• 프레임 유형 파일: PPT 프레임 유형을 정의해 컴포넌트(재사용하는 부품)로 만들고 QA 기준까지 둔 파일

먼저 구조화된 프롬프트 시스템을 깔고, 그다음 에이전트 구조로 올린 뒤, 마지막에 하네스 엔지니어링을 더합니다. 앞에서 설명한 순서 그대로입니다.

구조를 먼저 공들여 설계하는 방식과, PPT 유형별 템플릿으로 바로 작업하는 방식 중 어느 쪽이 나은지는 작업마다 다릅니다. 같은 요청 몇 건을 두 방식으로 돌려 결과물 품질과 걸린 시간을 직접 비교해 보는 것이 가장 확실합니다.

오늘 해 볼 첫걸음

지금 앞에 놓인 문제 딱 하나만 골라 AI에게 같이 해결하자고 해 보세요. 이때 앞의 프롬프트 엔지니어링을 그대로 적용해, 역할⁠·목적⁠·기준 세 가지부터 적고 시작합니다.

너는 (내 업무 분야)의 (역할)이야.
목적: (지금 풀고 싶은 문제 한 가지)를 해결하는 것.
기준: (결과물이 갖춰야 할 조건 2~3개). 모르는 부분은 지어내지 말고 나에게 먼저 질문해.

답이 마음에 들지 않으면 왜 그런지 가정을 세우고, 기준을 고쳐 다시 시킵니다. 같은 일을 자주 맡기게 되면 그때 가이드라인 문서를 넣어 컨텍스트 엔지니어링으로 넘어가면 됩니다.