1. 하네스 엔제니어링 탄생 배경
얼마 전까지만 해도 AI 업계의 최대 관심사는 단 하나였습니다.
어떤 모델이 더 똑똑한가?
작년에만 해도 테크뷰에서는 GPT와 클로드, 제미나이 등을 자주 비교했습니다. 새 모델이 나올 때마다 벤치마크 점수를 비교하고, 경쟁했습니다.
그런데 지금은 조금 달라졌습니다.
(1) 모델들이 너무 비슷해졌습니다
코딩을 시키든, 글을 쓰게 하든, 웬만한 질문에 답하게 하든 요즘 주요 모델들의 결과물을 나란히 놓으면 일반 사용자 입장에서 차이를 구분하기가 쉽지 않습니다. 실제로 어느 쪽이 더 좋은 답인지 사람들에게 물어보는 실험을 해보면, 정답률이 동전 던지기 수준에 가까워지고 있습니다.
(2) 그렇다고 더 키우기도 어렵습니다
더 똑똑한 모델을 만들면 되지 않을까요? 문제는 비용입니다.
모델 성능을 조금만 더 올리려 해도 학습에 드는 컴퓨팅 비용이 기하급수적으로 늘어납니다. 예전처럼 돈을 더 쏟아부으면 성능이 따라온다는 공식이 이제는 잘 맞지 않는 상황이 됐습니다.
그래서 AI 업계 전체의 시선이 다른 곳을 향하기 시작했습니다.
모델 자체를 더 크게 만드는 것 말고, 모델을 더 잘 쓰는 방법은 없을까?
이게 바로 하네스 (Harness) 엔지니어링이 주목받게 된 배경입니다. 다음 섹션에서는 AI 엔지니어링이 어떤 흐름을 거쳐 여기까지 왔는지 살펴보겠습니다.
2. 패러다임의 진화
AI를 잘 쓰는 방법도 시간이 지나면서 계속 진화해왔습니다. 크게 세 단계로 나눌 수 있습니다.
(1) 프롬프트 엔지니어링: 질문 잘하기
프롬프트 엔지니어링 초기에는 질문하는 방법이 중요했습니다. 같은 AI라도 질문을 어떻게 던지느냐에 따라 결과물의 품질이 크게 달랐기 때문입니다.
그냥 질문하는 것보다, 당신은 10년 경력의 마케터라고 정의해주는 것이 더 답변 퀄리티가 높은 것이 이와 관련됩니다.
(2) 컨텍스트 엔지니어링: 맥락 설계
그 다음 단계는 단순히 질문을 잘하는 것을 넘어, AI가 최적의 답을 낼 수 있도록 필요한 정보를 적절한 타이밍과 형태로 구성해서 제공하는 것이었습니다.
예를 들어 고객 응대 AI를 만든다면, 단순히 친절하게 답해줘라고 지시하는 게 아니라 회사 소개, 자주 묻는 질문, 응대 원칙, 최근 이슈까지 체계적으로 정리해서 AI에게 넘겨주는 방식입니다. 질문을 잘하는 것에서, 환경을 잘 설계하는 것으로 무게중심이 이동한 것입니다.
(3) 하네스 엔지니어링: 실행 시스템 설계
여기서 최근에는 세 번째 단계가 본격적으로 시작됐습니다.
하네스 엔지니어링은 AI 모델 바깥에 실행 시스템 전체를 설계하는 것입니다. AI가 단순히 질문에 답하는 것을 넘어, 스스로 계획을 세우고, 도구를 사용하고, 결과를 검증하고, 다시 시도하는, 즉 에이전트처럼 행동하게 만드는 구조를 만드는 일입니다.
하네스(Harness)란?
말에 마구를 씌워 원하는 방향으로 제어하듯, AI 모델에 ‘제어 장치’를 씌워 복잡한 일을 안정적으로 수행하게 만드는 외부 실행 구조를 뜻합니다.
핵심 전환을 한 줄로 정리하면 이렇습니다.
“모델 내부의 성능”에서 “모델 외부의 시스템 설계”로 전환!
이제 중요한 건 모델이 얼마나 똑똑한가가 아니라, 그 모델을 감싸고 있는 시스템이 얼마나 잘 설계되어 있는가입니다. 다음 섹션에서는 하네스 엔지니어링이 구체적으로 어떤 구조로 이루어져 있는지 살펴보겠습니다.
3. 하네스 엔지니어링이란?
하네스 엔지니어링을 쉽게 표현하면 다음과 같습니다.
AI 모델을 둘러싼 실행 시스템 전체를 설계하는 기술
모델에게 질문 하나를 던지고 답을 받는 것이 아니라, 복잡한 목표를 주면 AI가 스스로 단계를 나누고, 필요한 도구를 쓰고, 결과를 확인하고, 틀리면 다시 시도하는 구조를 만드는 일입니다.
(1) 핵심 구조 : 역할을 나눈다
잘 설계된 하네스는 하나의 AI가 모든 걸 혼자 처리하지 않습니다. 마치 아래 팀처럼 역할을 나눕니다.
- 플래너 : 큰 목표를 작은 단계로 쪼갭니다
- 제너레이터 : 실제 결과물을 만들어냅니다
- 이밸류에이터 : 결과물이 괜찮은지 검증합니다
- 오케스트레이터 : 이 흐름 전체를 조율합니다
혼자 처리할 때보다 이렇게 역할을 나눴을 때 결과물의 품질이 확연히 달라집니다. 실제로 같은 모델을 쓰더라도, 하네스 설계에 따라 결과물 품질이 크게 차이납니다.
조금 이해하기 어려우신가요? 하네스 엔지니어링의 구조는 건축 현장과 놀랍도록 닮아 있습니다.
- 현장 소장이 전체 공정을 지휘하듯 오케스트레이터가 에이전트 흐름을 총괄합니다.
- 건축가가 도면을 그리듯 플래너가 목표를 단계로 쪼갭니다.
- 시공 팀이 실제로 건물을 올리듯 제너레이터가 결과물을 만들어내고,
- 감리사가 품질을 검수하듯 이밸류에이터가 결과를 검증합니다.
이처럼 건축 현장에서 감리사가 문제를 발견하면 재시공이 이루어지듯, AI 에이전트도 검증 결과에 따라 생성 → 검증 → 재생성 사이클을 반복하며 품질을 높여갑니다. 결국 하네스 엔지니어링은 AI에게 단순히 일을 시키는 것이 아니라, 팀으로 일하게 만드는 설계입니다.
(2) 핵심 원리 : 루프를 돈다
하네스의 또 다른 핵심은 반복입니다.
한 번에 완벽한 답을 내려는 것이 아니라, 생성하고 → 평가하고 → 다시 생성하는 사이클을 돌면서 점점 나은 결과를 만들어냅니다.
사람이 글을 쓸 때도 초고를 쓰고, 읽어보고, 고치는 과정을 반복하는 것과 같은 원리입니다. 하네스는 이 과정을 AI가 자동으로 반복하게 만듭니다.
(3) 왜 지금 중요한가
클로드 코드 유출 사건에서 드러난 것처럼, 이미 최고 수준의 AI 제품들은 하네스 설계에 엄청난 공을 들이고 있습니다. 그리고 흥미로운 점은 어떤 모델을 쓰느냐보다 하네스를 어떻게 설계하느냐가 결과 품질에 더 큰 영향을 미친다는 사실이 점점 더 분명해지고 있습니다.
평가 기준도 바뀌고 있습니다. 예전에는 이 모델의 벤치마크를 봤다면, 이제는 복잡한 업무를 얼마나 안정적으로 완수하는가를 더 중요한 지표로 봅니다.
모델은 점점 상향평준화되고 있습니다. 결국 차이를 만드는 건 그 모델을 어떻게 엮어서 쓰느냐입니다.
4. 최근 핫 이슈 : 클로드 코드 유출
지난 2026년 3월 31일, AI 개발자 커뮤니티가 술렁였습니다.
Anthropic이 만든 AI 코딩 도구 클로드 코드 내부 소스코드가 외부에 공개된 것입니다.
(1) 무슨 일이 있었나
원인은 단순한 실수였습니다.
Anthropic이 클로드 코드 업데이트 버전을 npm(개발자들이 소프트웨어를 공유하는 플랫폼)에 배포하면서, 내부 디버깅용 파일을 실수로 함께 올린 것입니다. 이 파일 안에는 51만 줄에 달하는 내부 코드가 고스란히 담겨 있었습니다.
클로드 코드 확인하러가기 (지금은 소스맵 제거된 버전)
발견되기까지 걸린 시간은 단 몇 분. 이후 수천 명의 개발자들이 코드를 내려받아 분석하기 시작했고, 삭제되기 전에 이미 여러 곳에 복사본이 퍼져나갔습니다.
Anthropic은 “고객 데이터나 보안 자격증명은 포함되지 않았으며, 보안 침해가 아닌 패키징 실수“라고 공식 확인했습니다.
더 알아보기 : 하네스 엔지니어링 개념 정리 모음 링크
(2) 왜 이게 중요한가
단순한 실수 하나로 끝날 수 있는 사건이었지만, 유출된 내용이 업계에 던진 충격은 상당했습니다.
유출된 코드의 핵심은 LLM 모델 자체가 아니었습니다.
클로드 코드의 진짜 경쟁력은 모델을 감싸고 있는 하네스, 즉 실행 시스템에 있었습니다.
코드를 분석한 개발자들이 발견한 것들을 보면 그 규모가 드러납니다.
- 컨텍스트가 넘쳐흐를 때를 대비한 5가지 압축 전략
- 에이전트를 여러 개 동시에 돌리면서도 비용을 최소화하는 서브에이전트 구조
- 사용자 불만 감지를 LLM이 아닌 단순 패턴 매칭으로 처리하는 실용적 설계
- 항상 켜진 상태로 백그라운드에서 작동하는 KAIROS 기능
(위 내용은 다소 난해하고 복잡합니다. 다음번 글 주제로 상세히 다룰 예정입니다)
특히 마지막 항목에서 하네스 설계의 철학이 잘 드러납니다. 비싼 AI 호출이 필요한 곳에만 AI를 쓰고, 그렇지 않은 곳은 훨씬 단순한 방법으로 처리하는 것입니다.
(3) 이 사건이 남긴 시사점
이번 유출은 역설적으로 하네스 엔지니어링의 중요성을 가장 강력하게 증명한 사례가 됐습니다.
연간 2조 원이 넘는 매출을 올리는 클로드 코드의 핵심 경쟁력이 모델이 아닌 하네스에 있었다는 사실과 그리고 그 하네스 설계도가 경쟁사들에게 그대로 공개됐다는 사실은, AI 시대의 진짜 기술력이 어디에 있는지를 업계 전체에 다시 한번 각인시켰습니다.
결국 모델은 이제 누구나 쓸 수 있다. 차이를 만드는 건 그 모델을 어떻게 연결하는지 여부다!
이번 사건은 그 명제를 코드 51만 줄로 증명해 보인 셈입니다.
5. 지금 중요한 것
지금까지 흐름을 정리하면 이렇습니다.
모델 성능의 차이는 좁혀졌고, 더 키우는 데 드는 비용은 한계에 가까워지고 있습니다.
그 빈자리를 채우는 것이 바로 하네스 엔지니어링입니다. 그리고 클로드 코드 유출 사건은 이 흐름이 이미 현실이 됐음을 코드 51만 줄로 증명했습니다.
(1) 모델 중심에서 시스템으로
어떤 모델 보다 어떻게 연결해서 쓸까가 더 중요한 질문이 됐습니다. GPT를 쓰든, 클로드를 쓰든, 그 모델을 감싸는 시스템이 부족하면 결과도 허술합니다. 반대로 하네스가 잘 설계되어 있으면, 조금 덜 비싼 모델로도 충분히 좋은 결과를 낼 수 있습니다.
이건 비용 절감의 문제이기도 하지만, 더 본질적으로는 AI를 진짜 업무에 쓸 수 있느냐 없느냐의 문제입니다.
(2) 그렇다면 우리는 무엇을 해야 하나
당장 복잡한 멀티 에이전트 시스템을 구축하자는 이야기가 아닙니다. 지금 시점에서 현실적으로 집중할 수 있는 것은 이렇습니다.
AI에게 일을 맡길 때, 단순히 질문 하나를 던지는 것을 넘어, 어떤 순서로, 어떤 정보를 주고, 결과를 어떻게 검증할지를 함께 설계하는 습관을 만드는 것입니다. 작은 차이처럼 보이지만, 이것이 하네스 엔지니어링의 출발점입니다.
AI를 그냥 쓰는 것과, 잘 엮어서 쓰는 것 사이의 간격은 생각보다 큽니다. 그 간격을 좁혀가는 이야기를 계속 다루도록 하겠습니다.
오늘 소개한 하네스 엔지니어링 솔루션 외에도 최근 테크뷰에서는 구글 프로젝트 지니, 몰트봇, Genspark AI 등 다양한 솔루션을 소개해드리고 있는데요.
아래 테크뷰 홈페이지를 통해 많은 관심 부탁드리겠습니다.
함께 읽기 좋은 글
클로드 코워크 사용 방법 및 주요 기능 정리: 플러그인 11종 공개
몰트봇 Moltbot 사용 방법 및 비용, 중요 이슈 점검 (ft. 클로드봇)
Genspark AI 어디까지 가능할까? (ft. 사용 후기 및 신규 기능 AI 시트)
GPT 5.1 업데이트 및 Siri – Gemini 통합 임박 : 최신 AI 키워드 보기
Claude Skills – AI 업무 혁신의 시작
AI 에이전트 대전환 – AWS 베드록 에이전트코어, Salesforce, OpenAI
나노바나나 (Nano Banana) 구글의 새로운 AI 이미지 생성 모델
댓글 남기기