goldtag

하네스 엔지니어링이란 무엇인가 — AI 에이전트의 고삐를 설계하는 시대 이 시리즈의 1편에서 프롬프트 엔지니어링의 퇴장을 이야기했다. CLI 기반 도구가 등장하면서 정교한 프롬프트를 수작업으로 다듬는 행위의 가치가 줄어들고 있다고. 그런데 2026년 들어, 프롬프트 엔지니어링을 대체한 것이 단순히 "더 나은 도구"가 아니라는 걸 깨닫게 됐다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 그리고 지금, 하네스 엔지니어링 이라는 완전히 새로운 패러다임이 자리잡고 있다. 이 글에서는 하네스 엔지니어링이 무엇인지, 왜 지금 이것이 중요한지, 그리고 어떤 구성 요소로 이루어져 있는지를 다룬다. 말에게 씌우는 마구, 에이전트에게 씌우는 하네스 하네스(Harness)는 원래 말에게 장착하는 마구를 뜻한다. 고삐, 안장, 등자 — 말의 강력한 힘을 억누르는 것이 아니라, 올바른 방향으로 전달하기 위한 장비다. AI에서 하네스는 정확히 같은 의미다. AI 에이전트의 강력한 능력을 올바른 방향으로 제어하고 전달하는 외부 시스템 전체. 공식으로 쓰면 이렇다. Agent = Model + Harness 모델이 아닌 모든 것이 하네스다. 시스템 프롬프트, 도구 정의, 샌드박스 환경, 오케스트레이션 로직, 피드백 루프, 메모리 관리, 미들웨어 훅. 에이전트를 감싸는 이 모든 것을 설계하는 행위가 하네스 엔지니어링이다. 왜 모델만으로는 부족한가 LLM은 본질적으로 이런 한계를 가진다. 세션 간 상태를 유지하지 못한다 코드를 직접 실행하지 못한다 실시간 정보에 접근하지 못한다 자기가 만든 결과물을 스스로 검증하지 못한다 ChatGPT와의 "대화"도 사실 기본적인 하네스의 산물이다. 이전 메시지를 추적하고, while 루프를 돌리는 것. 그 자체가 원시적인 하네스다. Anthropic은 이 한계를 직접 경험했다. Claude Opus 4.5에게 "claude.ai의 클론을 만들어라"라는 고수준 지시...

AI 활용법, 1년 반 만에 완전히 바뀌었다 — 프롬프트 엔지니어링은 이제 필요 없을까? 2024년 11월 말, 처음으로 AI를 사용했다. 그로부터 1년 반. 그 사이에 일어난 변화는 단순한 도구의 발전이 아니었다. 일하는 방식 자체가 바뀌었고, 바뀌는 속도 자체가 가속되고 있다. 처음에는 6개월 단위로 새로운 패러다임이 등장했다. 그것이 3개월로 줄었고, 지금은 한 주가 멀다 하고 새로운 것이 쏟아진다. AI는 태동기를 지나 과도기에 접어들었다. 그리고 과도기의 한가운데에 서 있는 지금, 이 1년 반을 돌아보는 것이 의미가 있겠다는 생각이 들었다. 과거 — 복사 붙여넣기, 그리고 프롬프트 엔지니어링 대화창 시대 정확히 말하면 ChatGPT에 코드를 물어보는 것부터 시작했다. 함수 하나, 에러 메시지 하나를 붙여넣고 답변을 받아 복사해서 에디터에 옮기는 방식. 구글 검색 대신 AI에게 물어본다는 것 자체가 신선했고, 답변의 정확도에 꽤 놀랐다. 하지만 사용 방식은 본질적으로 검색과 다르지 않았다. 질문하고, 답변을 읽고, 수동으로 적용하는. 그 반복이었다. 그때는 이것만으로도 충분히 혁신적이라고 생각했다. 프롬프트 엔지니어링이라는 발견 몇 달이 지나자 한계가 보이기 시작했다. 같은 질문인데 어떻게 물어보느냐에 따라 답변의 질이 확연히 달라졌다. "이 코드 고쳐줘"라고 하면 대충 수정해주지만, 역할을 부여하고 맥락을 설명하고 출력 형식을 지정하면 전혀 다른 수준의 결과가 나왔다. 2025년 초, 프롬프트 엔지니어링을 본격적으로 학습하기 시작했다. 시스템 프롬프트 설계, 체인 오브 씽킹, 퓨샷 러닝, 역할 지정. 프롬프트 하나를 설계하는 데 코드를 작성하는 것만큼의 시간을 들이기도 했다. 실제로 효과가 있었다. 같은 모델이라도 프롬프트에 따라 주니어 개발자 수준의 답변과 시니어 개발자 수준의 답변을 오갔다. AI를 제대로 활용하려면 프롬프트 엔지니어링은 필수라고 확신했다. 그런데 그 확신은 오래가지 않았다. 프롬프트 엔지...

AI에게 시나리오를 던지면 생기는 일 이 프로젝트를 진행하면서, AI와 가장 많이 대화한 건 시나리오 설계였다. 시스템 구조, 캐릭터 설정, 갈등 패턴, 시간 구조. 모든 과정에서 AI를 썼다. 솔직한 후기를 남기려 한다. AI가 뭘 잘하고, 뭘 못 하고, 어떻게 써야 효과적인지. AI가 잘하는 것 구조 정리. 이건 압도적이다. "감정 시스템을 설계하고 싶어"라고 말하면, 체계적인 변수 구조와 계층 분리를 즉시 제안한다. 사람이 하면 며칠 걸릴 정보 정리를 몇 분에 해낸다. 3계층 감정 모델의 골격은 AI와의 대화에서 한 시간 만에 나왔다. 변수 간 일관성 검증. "이 이벤트에서 신뢰가 올라가면 긴장은 어떻게 돼야 해?" 같은 질문에 논리적으로 답한다. 변수가 많아지면 사람은 빠뜨리는 게 생기는데, AI는 빠뜨리지 않는다. Part 9에서 3계층 모델의 변수 간 상호작용을 정의할 때, AI가 "신뢰가 높고 긴장도 높은 상태"의 의미를 즉시 분석해줬다. 사람이면 "그런 조합이 가능한가?"부터 고민할 텐데, AI는 가능한 모든 조합과 각각의 의미를 체계적으로 정리해준다. 패턴 제시. "갈등의 종류를 분류해줘", "엔딩 구조의 패턴을 정리해줘" 같은 요청에 광범위한 패턴을 빠르게 나열한다. 바닥부터 시작하지 않아도 된다. AI가 내놓은 10개 패턴 중 2~3개를 골라서 깊이 파면 된다. 코드 생성. Ren'Py용 이벤트 함수, 감정 변화 로직, 조건 분기 코드를 빠르게 만들어준다. 초안으로서 매우 유용하다. Part 9에서 3계층 감정 모델을 코드로 옮길 때, AI가 기본 구조를 30분 만에 만들어줬다. 성향층, 순간 감정층, 관계층의 상호작용 로직까지 포함해서. 물론 세부 수치 조정은 직접 해야 했지만, 골격을 잡는 속도는 압도적이었다. AI가 못하는 것 감정의 무게 판단. "이 두 선택지 중 어느 쪽이 더 아프냐?...