하네스 엔지니어링: 개발자의 역할은 코드 작성에서 환경 설계로?!
요즘 바이브 코딩으로 서비스를 만들었다는 얘기가 엄청 많습니다.
회사에서도 계속 AI를 써서 생산성을 높이라는 얘기도 많이하고, 프론트엔드 뿐만아니라 백엔드까지 혼자 감당해야하는 요구사항도 점점 많아지고 있어요. ㅜㅜ 당연히 AI가 발전하는 만큼 그걸 활용해서 개발하는게 맞다는 생각에도 당연히 동의합니다.
하지만~ 왠지 모르게 저는 반갑지는 않았던 것 같은데요... 분명 클로드 코드가 잘 만들어주기는 합니다. 예전보다 초기 프로젝트 세팅이나 초안을 빠르게 만들어주고 막히던 부분들도 빠르게 해결해주고 있어요. 근데 그렇다고해서 그 결과를 전부 신뢰할 수 있냐는 것에 대해서는 아니였습니다. 결국 의도한 요구사항에 맞게 개발된 건지, 빠뜨린 부분은 없는지, 실제 서비스에 사용해도 되는 코드인지 확인하는 작업은 여전히 필요하다고 생각했는데, 이런 부분이 제가 약간의 반감(?)을 가졌던게 아닐까 싶습니당....ㅎ
그러다가 다른 사람들은 어떻게 생각하고 어떻게 활용하고 있는지 궁금해서 글들을 찾아보다가 테오의 우리, 프로그래머들 — .md로 코딩하는 시대를 보게 되었습니다.
해당 글을 읽으면서 제가 막연하게 느끼고 있던 부분들이 조금 정리가 되는 느낌을 받았는데요!
AI가 코드를 잘짜는 시대가 왔다고 해서 개발자들의 역할이 사라지는게 아니라, 오히려 디테일을 다루는 책임과 추상화를 설계하는 능력이 더 중요해진다고 하는 부분에서 공감을 했습니다.
그리고 여기서 하네스(Harness) 엔지니어링이라는 개념을 접하게 되었습니다!
하네스(Harness) 엔지니어링이란
하네스(Harness)는 원래 말의 힘을 억누르기 위한 장비가 아니라 강한 힘을 원하는 방향으로 제어하기 위한 장치를 뜻합니다. 최근 이 비유가 AI 에이전트 맥락에서 널리 쓰이기 시작했고, 2026년 들어 OpenAI, LangChain, Thoughtworks 같은 곳에서 이 용어를 본격적으로 다루며 빠르게 확산됐습니다. 특히 OpenAI는 2026년 2월 Codex 실험을 공개하며 에이전트 중심 개발에서 왜 하네스가 중요한지 보여줬습니다.
LangChain은 이 개념을 아주 직관적으로 정리하고 있습니다.
Agent = Model + Harness.
즉! 모델만으로는 에이전트가 아닙니다. 시스템 프롬프트, 도구 정의, 실행 환경, 상태 관리, 메모리, 피드백 루프, 승인 절차, 가드레일처럼 모델 바깥의 모든 설계 요소가 붙어야 비로소 "일하는 에이전트"가 됩니다. LangChain은 이를 "모델의 지능을 실제 작업 엔진으로 바꾸는 시스템"이라고 설명합니다.
이렇게 보면 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링은 경쟁 개념이라기보다 포함 관계에 가깝다고 볼 수 있습니다.
프롬프트 엔지니어링이 "무엇을 물어볼까"라면 컨텍스트 엔지니어링은 "무엇을 보여줄까"에 가깝고 하네스 엔지니어링은 그보다 한 단계 더 바깥에서 전체 환경을 어떻게 설계할까를 다루고 있습니다. OpenAI와 LangChain 모두 시스템 프롬프트, 도구 선택, 실행 흐름, 메모리, 검증, 피드백 구조까지 포함해서 하네스를 설명하고 있습니다.
제가 하네스 엔지니어링 개념에 끌려서 찾아보았던 이유도 여기에 있는데요!
하네스 엔지니어링은 "AI에게 뭘 시킬까?"보다 "AI가 일을 잘할 수 있도록 하려면 어떤 구조를 만들까?"에 더 가까워 보였기 때문입니다. 이건 단순히 프롬프트를 어떻게 잘 정리해서 쓰지?가 아니라 AI를 실제 개발 환경에 투입했을 때 무너지지 않게 만드는 문제라고 생각합니다.
왜 지금 하네스 엔지니어링인가
이 개념이 지금 중요해지고 있는 이유는 AI 코딩이 더 이상 "신기한 데모" 수준이 아니라 실제 제품과 팀 생산성의 문제로 들어왔기 때문이라고 합니다.
AI 코딩의 발전 단계
마틴 파울러 사이트의 Keif Morris 글은 AI와 사람의 상호작용을 단계별로 명확하게 정리하고 있습니다.
1단계, Human Outside the Loop. 흔히 말하는 바이브 코딩입니다. 사람은 기획과 아이디어만 담당하고 AI가 코드를 알아서 만듭니다. 코드 내부가 어떻게 생겼는지는 신경 쓰지 않고 기능이 돌아가는지만 봅니다.
2단계, Human In the Loop. Cursor 같은 IDE에서 채팅 인터페이스를 통해 AI에게 명령을 내리고 생성된 코드를 실시간으로 검증하는 방식입니다. 코드 단위로 직접 체크하면서 AI와 상호작용합니다.
3단계, Human On the Loop. AI에게 가이드를 주고 자율적으로 해결하게 하는 방식입니다. 여기서 "가이드"가 바로 하네스입니다. 2단계와 3단계의 차이는 결과물이 마음에 안 들 때 가장 선명하게 드러난다고 하는데요. In the Loop은 결과물을 직접 고칩니다. On the Loop은 하네스를 고칩니다. 결과물이 아니라, 결과물을 만들어내는 시스템을 개선하는 것입니다.
다음 단계, Agent Flywheel. AI가 스스로 테스트와 실패를 통해 하네스를 보강해나가는 완전 자동화 단계입니다. 아직은 연구 중이며, 현재는 3단계가 주류로 올라오는 과도기에 있다고 합니다.
"AI가 만든 코드를 AI로 검증하면 되지 않을까?"의 함정
AI가 만든 코드가 불안하면.. 똑똑한 다른 AI에게 검증을 시키면 되지 않을까? 라고 저도 처음에 그렇게 생각했습니다. 하지만 이 접근에는 오라클 문제(Oracle Problem)라는 근본적인 난제가 있다는걸 처음 알았어요.
오라클 문제란 "시스템의 동작이 올바른지 판단하는 기준을 어떻게 세울 것인가"에 대한 문제입니다. 명확한 기준이 없으면 서로가 서로를 판단하며 결국 엔트로피만 높아지고 실제로 최신 LLM에게 자기 코드를 비판하게 맡겼더니, 올바른 정답조차 "틀렸다"며 고쳐버려서 정확도가 수직 하락했다는 연구 결과도 있다고 하는군요 .. .ㅠㅠ.
이것은 LLM의 골 픽세이션(Goal Fixation) 때문입니다. "검증을 해야 한다"는 목표가 주어지면, AI는 자신이 지어낸 잣대를 진짜 정답이라고 착각하고 멀쩡한 코드까지 "틀렸다"고 판단해버린다고 합니다. 결국 비결정적 함수(AI)의 출력을 검증하려면 컴파일러, 테스트 러너, 린터같이 기준만큼은 반드시 결정적인 방식이어야 합니다!
소규모 서비스와 대규모 서비스의 결정적 차이
혼자 클로드 코드나 커서를 써서 사이드 프로젝트를 만드는 건 충분히 가능하다고 생각합니다. 저도 실제로 그렇게 하고 있고 생산성이 체감될 정도로 올라갔습니다! 하지만 대규모 서비스나 팀 협업 프로젝트에서는 이야기가 완전히 달라지는것 같습니다.
토스의 기술 블로그 글을 보면서 공감했던 부분이 있습니다. 개인의 AI 활용 능력에는 편차가 있고 그 편차가 곧 조직 전체의 품질 저점을 결정한다.는 것이였는데요....!!! 누군가는 프롬프트를 잘 설계해서 깔끔한 코드를 뽑아내지만 누군가는 프랑켄슈타인 같은 코드를 양산하고, 이 상태로 프로덕션에 코드가 들어가면 문제는 기하급수적으로 커진다는 것입니다.
그래서 LLM 활용 능력이 더 이상 개인의 센스 영역에 머물러서는 안 되고 그것은 팀이 설계하고 배포해야 할 시스템의 영역으로 넘어가야 한다고 합니다. 하네스는 바로 이 역할을 하고 개인의 '슈퍼'를 넘어 팀의 '표준'으로 만드는 장치인 것이라고 했습니다.
개발자의 역할은 어떻게 바뀌고 있나용,,
글들을 읽으면서 가장 크게 와닿았던 점은 이 변화가 "개발자는 이제 필요 없다"는 이야기가 아니라는 점이였습니다. 오히려 반대이고 모델이 더 많은 구현을 맡게 될수록 개발자는 더 높은 레벨에서 구조를 잡고 기준을 만들고 검증 체계를 설계해야 한다는 것입니다. OpenAI도 사람이 루프에서 사라진 게 아니라, 우선순위를 정하고 수용 기준을 정의하고 시스템을 튜닝하는 쪽으로 역할이 이동했다고 설명합니다.
이것도 결국 코딩의 연장선 같은데요. 예전에는 .ts 나 .py 파일에 로직을 주로 담았다면 이제는 .md 파일, 규칙 파일, 스킬, 파이프라인, 훅, 검증 루프에도 엔지니어링의 엄밀함이 들어갑니다. 단일 책임, 변경 가능성, 추상화, 인터페이스 같은 소프트웨어 설계 감각이 코드 본문 밖으로 번지고 있는 셈이고, 그래서 "프롬프트를 잘 쓰는 사람"보다, AI가 안정적으로 일하는 구조를 설계하는 사람이 더 중요해지는 것 같습니다.
결국 지금은 직접 코딩하는 능력이 의미 없어졌다는 말은 아니고,,,!!! 오히려 코드가 실제로 어떻게 망가지는지, 어떤 디테일이 중요한지 알수록 하네스도 더 잘 설계할 수 있다라는 것입니다. 엄밀함의 위치가 코드 작성 자체에서 환경 설계와 운영 설계 쪽으로 일부 이동하고 있을 뿐인 것이지요...
마무리
처음에는 저도 막연히 불안하기는 했는데요 ,, AI가 코드를 잘 짜면 진짜 제가 해야할 역할은 뭐가 남을까라는 고민도 좀 되고,, 그랬습니다. 하지만 하네스 관점을 접하고 나니 고민하는 방향이 바뀌게 된 것 같습니다. AI가 제대로 일하도록 무엇을 통제하고 설계해야 할까?를 좀 더 고민하는 관점으로요,,
AI를 많이 믿어도 되는 게 아니고 믿을 수 환경을 만드는 것으로요!
참고자료
5개의 댓글
한번 맛(?)이 간 스레드는 포기하고 새로 명령을 정리해야하던 기억이 어제같아요. md를 이용해서 요새는 영속성있는 ai코딩을 하네요. 코딩 실력보다 명령과 체계를 잘 짜는게 중요해진 개발자의 시대라니 변화가 정말 빨라요..
프롬프트 잘 쓰는 것도 중요하지만, AI를 안정적으로 계속 일하게 만드는 게 더 중요하다고
쓰신 부분에서 엄청 공감했습니다.
껐다 켜면 초기화되니까, 계속 방향을 잡아주는 게 진짜 핵심인 듯합니다.
요새 핫한 주제여서 재밌게 읽었습니다
요즘 회사에서 하네스 엔지니어링이 좋다 라는 말들을 너나 할 것 없이 말하곤 하는데
내심 모두가 생산성의 향상에 집중하고 앞만보는 환경에서 누군가는 돌아보는 역할을 해야하지 않나라는 고민을 하고 있는데요! 유익하게 읽었습니다!
관련 고민을 많이 했어서 반가운 포스트네요. md 파일로 제대로 환경을 구성해서 프로젝트를 꾸려본 적은 없었는데 이제는 필수인 것 같아서 한 번 해보자! 싶고, 그 AI를 부리는 입장에서 개발자의 역할도 여전히 없진 않구나 생각이 들어요.
글 너무 공감하면서 읽었습니다. 저도 회사에서 비결정적인 AI를 위해서는 최소한의 강제성을 부여하기위해 의존성 방향을 강제하고, 테스트코드를 추가하고, lint를 타이트하게 잡는 등의 작업을 진행했는데, 이 일이 맞는 방향인지에 대한 고민이 덕분헤 해소되었습니다.
저는 아직 2단계인 human in the loop에 있는 것 같은데 더 발전해야겠습니다~!
좋은 글 감사합니다~!!!