하네스 엔지니어링은 새로운 것이 아니다

2026년, 하네스 엔지니어링이 뜨겁다

분명 뜨거운 주제다. 하지만 나는 이 "하네스 엔지니어링"이라는 단어가 가진 의미가 과연 무엇인지, 조금 더 생각해볼 필요가 있다고 느낀다.

기업들이 원하는 건 결국 하나다

지금 AI를 도입하는 기업들의 목표는 다 같다. 자기 도메인에서 최적의 답변을 내놓는 AI. 법률 회사는 법률에 특화된 AI를, 의료 회사는 의료에 특화된 AI를 원한다. 이건 AI 시대 이전에도 마찬가지였다. 어떤 시스템이든 특정 도메인에 투입하면 그 도메인의 규칙을 가르쳐야 한다.

하네스 엔지니어링이 해결하려는 문제라는 것도 결국 이거다. AI 모델이 우리 도메인의 맥락을 모르니까, 그걸 알려주고, 엉뚱한 답을 하지 않게 울타리를 치는 것.

신입사원 온보딩과 다를 게 없다

아무리 뛰어난 개발자를 뽑아도, 회사에 처음 들어오면 온보딩을 받는다. 코드 컨벤션, 아키텍처 결정 사항, 배포 프로세스, 도메인 용어, 이런 것들은 그 사람이 아무리 실력이 좋아도 알 수 없다. 회사 밖에는 없는 지식이니까.

AI 모델도 마찬가지다. GPT든 Claude든, 모델이 아무리 똑똑해져도 우리 회사의 내부 API 규칙이나 비즈니스 로직을 알 리가 없다. 그래서 프롬프트로 규칙을 알려주고, lint로 스타일을 잡고, 테스트로 동작을 검증한다.

이게 하네스 엔지니어링의 실체다. 새로운 엔지니어링 분야가 아니라, 원래 해야 했던 일 이다.

이건 모델 성능 향상이 아니다

여기서 중요한 구분이 있다. 하네스 엔지니어링은 모델의 성능을 끌어올리는 일이 아니다. 이미 정해진 모델의 능력을 특정 방향으로 유도하는 것이다.

lint가 코드의 품질을 올리는 게 아니라 스타일을 강제하듯, tsc가 프로그래머의 실력을 올리는 게 아니라 타입 안전성을 강제하듯, 하네스는 모델의 출력을 제약할 뿐이다. 모델 자체가 더 똑똑해지는 건 아니다.

OpenAI가 커스텀 린터와 구조 테스트로 아키텍처를 강제하고, 주기적으로 드리프트를 스캔하여 에이전트가 수정을 제안하게 한다는 이야기도 결국 같은 맥락이다. 모델이 더 잘하게 만든 게 아니라, 모델이 잘못하는 걸 덜 잘못하게 만든 것이다.

그런데 담론은 과열되어 있다

하네스 엔지니어링 담론에서 불편한 점이 있다.

첫째, 정의조차 합의되지 않았다. DEV Community의 비교 글을 보면, 5개 회사가 5가지 다른 정의를 내리고 있다. OpenAI는 선언적 제약 시스템이라 하고, Anthropic은 context anxiety 해결이라 하고, LangChain은 벤치마크 최적화 도구라 하고, Böckeler는 TypeScript strict mode 같은 기존 도구도 하네스라고 한다. 무엇이 하네스이고 무엇이 아닌지의 경계조차 불분명한데, 이미 학술 논문이 나오고 직군 이름이 되려 하고 있다.

둘째, 수치가 실체보다 앞서간다. LangChain 블로그에서 인상적인 사례가 나온다. GPT-5.2-Codex로 Terminal Bench 2.0을 돌렸을 때, 기본 프롬프트와 도구 세팅으로 52.8%를 기록했고, 커스텀 프롬프트와 미들웨어를 추가하자 63.6%, 추론 강도를 올리자 66.5%까지 올라갔다. 모델은 그대로인 채로. 이걸 "하네스 엔지니어링의 성과"라고 부른다. 하지만 실제로 한 일을 보면 시스템 프롬프트를 바꾸고, 빌드-검증 루프를 추가하고, reasoning 레벨을 xhigh로 올린 것이다. 이건 프롬프트 튜닝과 도구 세팅이지, 새로운 엔지니어링 분야의 성과라고 부르기엔 과하다.

셋째, "moat는 하네스에 있다"는 주장은 성급하다. InfoSec Today는 하네스가 모델보다 더 큰 경쟁 우위라고 분석했고, Philipp Schmid는 하네스가 캡처하는 실행 궤적 자체가 경쟁 우위가 된다고 주장한다. 하지만 프롬프트와 가드레일로 만든 울타리가 경쟁의 해자가 된다는 건, 설정 파일이 기술 장벽이라고 말하는 것과 다를 바 없다. moat는 그 안에 담기는 도메인 지식이지, 울타리 자체가 아니다.

모델이 발전해도 하네스는 사라지지 않는다

Latent Space 논쟁에서 Noam Brown은 "현재 사람들이 만드는 스캐폴딩도 결국 모델이 더 똑똑해지면 대체될 것"이라고 했다. 이른바 Bitter Lesson, 영리한 엔지니어링보다 단순한 스케일링이 장기적으로 이긴다는 교훈이다.

나는 이 주장에 동의하지 않는다.

모델이 아무리 발전해도, 세상에 없는 지식은 학습할 수 없다. 우리 회사의 내부 코드 컨벤션, 아직 공개되지 않은 API 스펙, 우리 팀만 아는 도메인 규칙, 이런 것들은 인터넷 어디에도 없다. 모델의 파라미터를 10배로 늘려도 모르는 건 모른다.

그래서 하네스는 사라지지 않는다. 다만 그건 "하네스 엔지니어링이 대단한 분야여서"가 아니라, 도메인 지식 전달은 어떤 시스템에든 필요한 기본적인 일이기 때문이다.

결국 AI는 사람에 가까워지고 있다

이 글을 쓰면서 한 가지 생각이 계속 맴돌았다. 하네스 엔지니어링이라는 담론을 따라가다 보면, 결국 우리가 AI에게 하는 일이 사람에게 하는 일과 점점 닮아가고 있다는 걸 느낀다.

신입사원이 들어오면 온보딩 문서를 읽히고, 코드 컨벤션을 지키게 하고, 시니어가 코드 리뷰를 하고, CI가 테스트를 돌린다. 잘못된 패턴을 쓰면 lint가 잡고, 위험한 코드를 머지하려 하면 리뷰어가 막는다. 이 모든 과정의 목표는 하나다, 이 사람을 우리 도메인에 최적화된 인재로 만드는 것.

하네스 엔지니어링이 하는 일도 정확히 이거다. 프롬프트로 맥락을 주고, 가드레일로 제약을 걸고, 테스트로 검증하고, 잘못되면 재시도시킨다. 대상이 사람에서 모델로 바뀌었을 뿐, 구조는 같다.

인공신경망으로 학습된 모델이 사람의 사고 방식에 가까워지고 있다면, 그 모델을 조직에 적응시키는 방법도 사람을 적응시키는 방법과 닮아가는 건 어쩌면 당연하다. 하네스 엔지니어링은 새로운 엔지니어링 분야가 아니라, AI가 충분히 사람과 비슷해졌기 때문에 생긴 자연스러운 현상일 뿐이다.

거창한 이름이 붙었다고 해서 본질이 달라지는 건 아니다. 우리는 예전부터 이 일을 해왔다. 대상이 바뀌었을 뿐이다.