2026년 하네스 엔지니어링은 왜 갑자기 튀어나왔을까

AI 이야기를 따라가다 보면 단어가 너무 빨리 바뀌어서 헷갈릴 때가 있습니다. 어제까지는 프롬프트 엔지니어링이라더니, 어느 날은 컨텍스트 엔지니어링이 중요하다고 하고, 2026년 2월부터는 갑자기 하네스 엔지니어링이라는 말까지 등장했으니까요.

이 글은 그 흐름을 아주 쉽게 정리한 글입니다. 제 결론부터 먼저 말하면 이렇습니다.

• 프롬프트 엔지니어링은 AI에게 말을 잘 거는 단계였어요.
• 컨텍스트 엔지니어링은 AI가 일을 잘할 수 있게 자료를 잘 챙겨주는 단계였어요.
• 하네스 엔지니어링은 AI가 실제로 오래 일해도 망가지지 않게, 작업장 전체를 설계하는 단계예요.

이건 단순한 유행어 바꾸기가 아닙니다. AI가 한두 문장 답하는 도구에서, 여러 단계를 스스로 처리하는 에이전트로 바뀌면서 필요한 기술 이름도 같이 바뀐 거예요.

먼저 비유부터 하자. 숙제 도와주는 로봇을 떠올리면 쉽다

숙제를 도와주는 똑똑한 로봇이 있다고 해볼게요.

프롬프트 엔지니어링은 이 로봇에게 질문을 잘하는 기술입니다. "수학 문제를 풀어줘"라고 말할지, "초등학교 5학년 수준으로, 풀이 과정을 3단계로 나눠서 설명해줘"라고 말할지의 차이예요.

컨텍스트 엔지니어링은 질문만 잘하는 걸 넘어서, 로봇 옆에 필요한 참고서를 같이 놔주는 일입니다. 교과서, 지난 숙제, 선생님이 좋아하는 답안 형식, 계산기, 메모장까지 함께 주는 거예요. 그러면 로봇이 훨씬 덜 헤맵니다.

하네스 엔지니어링은 여기서 한 단계 더 갑니다. 로봇이 숙제만 푸는 게 아니라, 답을 검사하고, 틀리면 다시 풀고, 모르면 사람에게 묻고, 기록도 남기고, 정해진 규칙을 어기면 멈추게 만드는 전체 교실 시스템을 만드는 일입니다.

즉, 하네스는 로봇의 말솜씨가 아니라 로봇이 일하는 운동장 전체라고 보면 됩니다.

2025년 초에는 아직 프롬프트 엔지니어링의 시대였다

2025년 초까지만 해도 많은 사람이 AI를 잘 쓰는 비결을 좋은 프롬프트에서 찾았습니다. 어떻게 문장을 쓰면 더 잘 답하는지, 어떤 역할을 주면 더 똑똑하게 행동하는지, 예시를 몇 개 넣으면 더 안정적인지 같은 이야기들이 중심이었어요.

이 단계에서는 AI를 주로 한 번 물어보고 한 번 답받는 도구처럼 바라봤습니다. 그래서 핵심도 자연스럽게 "질문을 잘 쓰는 법"에 가까웠어요.

이 표현이 틀린 건 아니었습니다. 실제로 프롬프트는 지금도 중요합니다. 다만 AI가 복잡한 일을 하기 시작하면서, 사람들은 곧 한 가지 문제를 보게 됩니다. 질문만 잘 써서는 한계가 있다는 점이었어요.

2025년 중반, 사람들은 프롬프트보다 컨텍스트가 더 중요하다고 말하기 시작했다

흐름이 눈에 띄게 바뀐 시점은 2025년 6월입니다.

2025년 6월 19일, Shopify의 Tobi Lütke는 prompt engineering보다 context engineering이라는 말이 더 좋다고 말했습니다. 이유는 간단했습니다. 진짜 중요한 능력은 예쁜 문장 하나를 쓰는 게 아니라, LLM이 문제를 풀 수 있게 필요한 맥락 전체를 넣어주는 일이기 때문이라는 설명이었습니다.

그리고 2025년 6월 25일, Andrej Karpathy도 여기에 힘을 실었습니다. 그는 실제 산업용 LLM 앱에서는 중요한 일이 짧은 요청문을 꾸미는 것이 아니라, 다음 단계에 필요한 정보를 컨텍스트 창에 정확히 채우는 일이라고 설명했습니다. 여기에는 작업 설명, 예시, 검색으로 가져온 자료, 도구, 상태, 대화 기록, 압축된 요약 같은 것들이 다 포함됩니다.

이 장면이 왜 중요했냐면, AI 업계가 처음으로 "문장 한 줄"보다 "문장 바깥의 준비물"이 더 중요하다고 공개적으로 말하기 시작했기 때문입니다.

그런데 컨텍스트만으로도 부족해졌다

여기서 한 번 더 생각해봐야 합니다. 자료를 잘 챙겨주기만 하면 끝일까요?

작은 작업이라면 어느 정도 맞습니다. 하지만 코딩 에이전트처럼 긴 일을 맡기면 문제가 달라집니다.

예를 들어 AI에게 이런 일을 맡긴다고 해볼게요.

• 버그를 재현하기
• 테스트를 돌리기
• 실패 영상을 찍기
• 코드를 수정하기
• 다시 테스트하기
• 풀 리퀘스트를 열기
• 리뷰 댓글을 반영하기
• 빌드가 깨지면 다시 고치기

이쯤 오면 중요한 건 단순히 "자료를 얼마나 잘 넣었나"가 아닙니다. AI가 어떤 도구를 쓸 수 있는지, 어디까지 권한이 있는지, 어떤 규칙을 어기면 멈춰야 하는지, 기록을 어디에 남기는지, 실패했을 때 어떻게 복구하는지까지 필요해집니다.

즉, 컨텍스트는 중요하지만, 에이전트 시대에는 컨텍스트를 담는 운영 틀이 더 중요해진 겁니다.

2026년 2월 4일, OpenAI는 먼저 하네스의 실체를 보여줬다

2026년 2월 4일 OpenAI는 Unlocking the Codex harness: how we built the App Server라는 글을 공개했습니다.

여기서 OpenAI는 웹 앱, CLI, IDE 확장, macOS 앱 등 여러 Codex 경험이 사실상 같은 Codex harness 위에서 돌아간다고 설명했습니다. 그리고 이 하네스가 단순한 모델 호출기가 아니라는 점도 분명히 했어요.

OpenAI 설명을 쉽게 풀면 하네스에는 이런 것들이 들어갑니다.

• 대화를 오래 기억하고 이어가는 스레드 관리
• 설정과 로그인 상태 관리
• 셸, 파일, MCP, 스킬 같은 도구 실행
• 에이전트가 한 일을 이벤트로 기록하고 다시 이어받는 구조

쉽게 말하면 AI 두뇌만 있는 게 아니라, 손발과 책상과 규칙판과 출석부가 함께 붙어 있는 셈입니다.

2026년 2월 11일, 하네스 엔지니어링이 이름을 얻었다

결정적인 장면은 2026년 2월 11일이었습니다. OpenAI는 Harness engineering: leveraging Codex in an agent-first world라는 글을 공개했습니다.

이 글에서 OpenAI는 지난 다섯 달 동안 사람 손으로 직접 코드를 쓰지 않고, Codex가 코드베이스 전체를 작성하는 실험을 했다고 밝혔습니다. 시작 시점은 2025년 8월 말이었고, 다섯 달 뒤 저장소에는 약 100만 줄의 코드와 약 1,500개의 풀 리퀘스트가 쌓였다고 설명했습니다. 작은 팀이 이런 속도를 낼 수 있었던 이유로, 모델 자체보다 에이전트가 안정적으로 일할 수 있는 환경을 설계한 점을 강조했습니다.

여기서 직업의 무게중심이 바뀝니다. 사람 엔지니어의 일이 직접 코드를 많이 쓰는 것에서 환경을 설계하고, 의도를 명확히 적고, 피드백 루프를 만드는 것으로 이동한 거예요. 바로 이 지점을 OpenAI가 하네스 엔지니어링이라고 부른 것입니다.

왜 하필 2026년에 이 말이 급부상했을까

제가 자료를 읽고 정리한 해석은 이렇습니다.

첫째, AI가 이제 한 번 답하고 끝나는 도구가 아니게 됐습니다. 스스로 파일을 읽고, 명령어를 실행하고, 테스트를 돌리고, PR까지 여는 에이전트가 되면서 운영 난도가 훨씬 올라갔어요.

둘째, 문제의 병목이 모델 안쪽에서 모델 바깥쪽으로 이동했습니다. 예전에는 "어떻게 물어볼까"가 가장 큰 고민이었다면, 나중에는 "무슨 자료를 보여줄까"가 중요해졌고, 2026년에는 "이 에이전트가 안전하고 반복 가능하게 일하도록 시스템을 어떻게 짤까"가 가장 큰 문제가 된 겁니다.

셋째, 실제 서비스 팀이 이 문제를 공개적으로 증명했습니다. OpenAI는 2026년 2월 11일 글에서 단지 개념만 설명한 게 아니라, 실제 저장소 운영 방식과 문서 구조, 린트, 구조 테스트, 품질 점검, 백그라운드 정리 작업까지 보여줬습니다. 그러니 사람들 입장에서는 "아, 이제는 프롬프트 요령보다 작업장 설계가 더 중요하구나"라고 받아들이기 쉬웠습니다.

한 문장으로 요약하면 이런 흐름이다

이 흐름을 아주 짧게 줄이면 이렇게 볼 수 있습니다.

• 2025년 초: AI에게 말을 잘 거는 법이 중요해서 프롬프트 엔지니어링이 중심에 있었다.
• 2025년 6월: 진짜 성능은 자료와 도구와 기억을 어떻게 넣느냐에 달려 있다는 인식이 퍼지며 컨텍스트 엔지니어링이 급부상했다.
• 2026년 2월: 에이전트가 실제로 긴 작업을 수행하기 시작하자, 이제는 작업장 전체를 설계하는 하네스 엔지니어링이 필요해졌다.

저는 그래서 하네스 엔지니어링을 컨텍스트 엔지니어링의 다음 칸이라고 봅니다. 컨텍스트가 도시락이라면, 하네스는 급식실 운영 규칙까지 포함한 학교 시스템에 더 가깝습니다.

그래서 앞으로 엔지니어는 뭘 잘해야 할까

앞으로 중요한 능력은 세 가지가 함께 갈 가능성이 큽니다.

• 일을 작게 나누고 목표를 분명하게 쓰는 능력
• AI가 참고할 문서, 예시, 규칙, 테스트를 잘 정리하는 능력
• AI가 실수해도 크게 망가지지 않게 울타리와 검사기를 만드는 능력

즉, 좋은 개발자는 단순히 코드를 빨리 치는 사람보다, 사람과 에이전트가 함께 일할 수 있는 환경을 설계하는 사람에 가까워질 수 있습니다.

하네스 엔지니어링은 멋있어 보이려고 만든 새로운 단어라기보다, AI가 진짜로 일을 시작하자 뒤늦게 붙은 현실적인 이름에 가깝습니다.

참고한 자료

• OpenAI, Harness engineering: leveraging Codex in an agent-first world , 2026년 2월 11일
• OpenAI, Unlocking the Codex harness: how we built the App Server , 2026년 2월 4일
• Simon Willison, Context engineering , 2025년 6월 27일
• OpenAI Developers, Prompting