'프롬프트 엔지니어링'은 끝났다? OpenAI가 던진 '하네스 엔지니어링'

요즘 개발자 사이에서 “프롬프트만 잘 쓰면 된다"는 말이 슬슬 옛말이 되어가고 있습니다. AI가 단순히 답을 뱉는 도구를 넘어, 스스로 코드를 짜고 실행하는 ‘에이전트’로 진화하고 있기 때문인데요. 그 변화의 한가운데에서 OpenAI가 던진 새로운 키워드가 바로 하네스 엔지니어링(Harness Engineering)입니다. 오늘은 이 낯선 개념이 왜 지금 주목받는지 풀어보겠습니다.

먼저 솔직하게 말씀드리면, 이 주제는 아직 커뮤니티에서 활발하게 토론되는 단계는 아닙니다. 최근 30일간 레딧 같은 곳에서는 관련 논의가 거의 잡히지 않았는데요. 대신 OpenAI 엔지니어들의 컨퍼런스 발표 영상을 중심으로 개념이 퍼지고 있는 상황입니다. 그래서 오늘 글은 ‘뜨거운 논쟁’보다는 ‘곧 다가올 흐름을 미리 읽기’에 가깝습니다.

하네스 엔지니어링, 도대체 뭔가요

이 개념이 본격적으로 알려진 건 AI Engineer 컨퍼런스에서였습니다. OpenAI의 Ryan Lopopolo가 발표한 “Harness Engineering: How to Build Software When Humans Steer, Agents Execute” 영상은 조회수 14만 회, 좋아요 2,700여 개를 기록하며 가장 큰 반응을 얻었는데요.

제목 자체가 핵심을 담고 있습니다. “인간은 방향을 잡고(steer), 에이전트는 실행한다(execute)"는 것입니다. 여기서 ‘하네스(harness)‘는 원래 말이나 동물에게 채우는 ‘마구’, 혹은 안전벨트 같은 ‘결속 장치’를 뜻합니다. 비유하자면 이렇습니다. 강력한 AI 에이전트라는 ‘말’이 폭주하지 않고 올바른 방향으로 달리도록, 그 위에 채우는 제어 장치를 설계하는 일이 바로 하네스 엔지니어링입니다.

왜 ‘프롬프트’에서 ‘하네스’로 넘어가나

프롬프트 엔지니어링은 본질적으로 ‘한 번의 대화’를 잘 다루는 기술이었습니다. 질문을 어떻게 던져야 AI가 좋은 답을 주는지에 집중했죠. 하지만 에이전트 시대는 다릅니다.

에이전트는 한 번 답하고 끝나지 않습니다. 파일을 읽고, 코드를 수정하고, 테스트를 돌리고, 실패하면 다시 시도하는 긴 작업의 연속을 스스로 수행합니다. 이렇게 되면 “프롬프트를 잘 쓰는 능력"만으로는 부족해집니다. 에이전트가 일할 ‘환경’ 전체를 설계해야 하기 때문인데요.

어떤 도구에 접근할 수 있는지, 어디까지 권한을 줄지, 무엇을 검증하고 어디서 멈춰야 하는지를 미리 정해두는 것. 이 ‘판을 까는 작업’이 하네스 엔지니어링의 핵심입니다.

Codex가 만드는 ‘에이전트 우선’ 개발

OpenAI는 이 흐름을 자사의 코딩 에이전트 Codex와 묶어서 밀고 있습니다. 관련 영상 제목들이 이를 잘 보여주는데요. “Leveraging Codex in an Agent-First World”, “Designing Systems Where Codex Agents Build the Future” 같은 발표들이 잇따라 올라왔습니다.

여기서 눈여겨볼 단어가 에이전트 우선(Agent-First)입니다. 지금까지 소프트웨어는 ‘사람이 짜는 것’을 전제로 만들어졌습니다. 코드 구조도, 문서도, 테스트도 전부 사람이 읽고 쓰기 좋게 설계됐죠. 그런데 에이전트 우선 세계에서는 전제가 뒤집힙니다. 에이전트가 일하기 좋은 구조로 시스템을 다시 짠다는 발상입니다.

다만 솔직히 짚자면, 이 발표들 상당수는 조회수가 수백 회 수준에 머물러 있습니다. 14만 회를 기록한 첫 영상을 빼면 아직 대중적 관심까지는 도달하지 못한 셈인데요. 개념은 던져졌지만 검증은 이제 시작 단계라고 보는 게 정확합니다.

개발자의 역할은 어떻게 바뀔까

그렇다면 개발자는 일자리를 잃는 걸까요. 하네스 엔지니어링이라는 개념은 오히려 반대 방향을 가리킵니다. 손으로 코드를 한 줄씩 치는 일은 줄어들겠지만, 방향을 잡고 제어 장치를 설계하는 일의 중요성은 커진다는 것입니다.

에이전트에게 어떤 작업을 맡길지 정의하고, 결과물이 올바른지 검증하는 체계를 세우고, 잘못된 방향으로 갈 때 멈출 안전장치를 만드는 일. 비유하자면 직접 운전하던 사람에서 관제탑 관리자로 역할이 옮겨가는 셈입니다. 코드를 짜는 능력보다 ‘시스템을 설계하고 판단하는 능력’이 더 귀해지는 방향인데요.

마무리

정리하면, 하네스 엔지니어링은 아직 OpenAI가 던진 ‘제안’ 단계의 개념입니다. 커뮤니티의 뜨거운 검증을 거친 검증된 트렌드라기보다는, 에이전트 시대를 먼저 고민한 회사가 내놓은 일종의 방향 제시에 가깝습니다. 그래서 지금은 정답이 아니라 질문으로 받아들이는 게 맞다고 봅니다.

여러분이라면 어떨까요. 더 이상 코드를 직접 짜지 않고 AI 에이전트의 방향만 잡아주는 개발자, 이건 새로운 기회일까요 아니면 또 하나의 과장된 마케팅 용어일까요. 적어도 “어떻게 하면 AI를 잘 시킬 것인가"라는 고민은, 앞으로 모든 개발자의 숙제가 될 것 같습니다.