최근 「〇〇 엔지니어링」이라는 말이 늘어났습니다.

프롬프트 엔지니어링 (Prompt Engineering). 컨텍스트 엔지니어링 (Context Engineering). 하네스 엔지니어링 (Harness Engineering). 루프 엔지니어링 (Loop Engineering).

새로운 용어가 나올 때마다 「또 외울 것이 늘었다」고 생각했습니다.

하지만 조사해 보니, 이것들은 따로 떨어진 기법이 아니라, 중첩된 4개의 계층이었습니다. 게다가 순서대로 배우면 되는 구조로 되어 있습니다.

이 기사에서는 그 4개 계층을 최대한 쉽게 설명하겠습니다. 후반부에서는 실제로 제가 어떻게 구성하고 있는지도 나열하겠습니다.

먼저 전체상입니다.

바깥쪽으로 갈수록 AI에게 맡기는 범위가 넓어집니다.

새로운 것이 오래된 것을 대체하는 것이 아닙니다. 바깥쪽을 만들려면 안쪽도 필요합니다.

가장 안쪽. ChatGPT나 Claude에 입력하는 그 지시문입니다.

NG: 느낌 있게 코드를 작성해줘
OK: 이 에러의 원인을 3가지 들고, 각각의 확인 방법도 써줘

이 부분은 많은 사람이 이미 하고 있는 단계라고 생각합니다. 구체적으로 쓰기, 역할 부여하기, 출력 형식 지정하기 정도가 전형적입니다.

다만, 프롬프트만으로 힘내려고 하면 한계가 옵니다. AI가 전제 조건을 모르기 때문입니다.

「이 프로젝트는 Node 18에서는 동작하지 않는다」

이것을 AI가 모른다면, 아무리 정중하게 프롬프트를 써도 Node 18을 전제로 한 코드가 돌아옵니다.

컨텍스트 엔지니어링 (Context Engineering)은 AI에게 전달할 정보를 설계하는 것입니다.

• 프로젝트의 규칙을 파일에 써둔다 (CLAUDE.md나 AGENTS.md 등)
• 관련 있는 코드만 전달한다 (전부 전달하면 오히려 정밀도가 떨어집니다)
• 과거의 대화 내용을 기억시킨다

포인트는 「전부 전달하는 것」이 정답은 아니라는 점입니다. 정보가 너무 많으면 중요한 지시가 묻힙니다. 과부족 없이 전달하는 것이 설계입니다.

하네스 (Harness)는 「마구(馬具)」, 「안전벨트」를 뜻합니다.

AI에게 손발을 부여하면서, 위험한 일을 하지 못하게 하는 틀을 만드는 계층이라고 생각하세요.

손발을 부여하기

• 파일을 읽고 쓰게 하기
• 명령어를 실행하게 하기
• 검색하게 하기

틀을 씌우기

• 운영 환경에는 건드리지 못하게 하기
• 테스트를 통과하지 못하면 다음으로 넘어가지 못하게 하기
• 위험한 조작은 인간의 승인을 거치게 하기

여기서 중요한 것은 틀을 「부탁」으로 만들지 않는 것입니다.

프롬프트에 「운영 DB는 건드리지 마」라고 써도 지켜질 보장이 없습니다. 애초에 권한을 주지 않는다, 접근할 수 없도록 해둔다. 그런 메커니즘으로 묶는 것이 하네스입니다.

가장 바깥쪽. AI가 한 번 대답하고 끝나는 것이 아니라, 반복해서 돌아가는 메커니즘을 설계하는 계층입니다.

예를 들어 「테스트를 작성한다 → 실행한다 → 실패하면 수정한다 → 다시 실행한다」. 이 반복을 AI가 스스로 돌리게 합니다. 인간은 매번 지시하지 않습니다.

여기서 등장하는 것이 HITL과 HOTL입니다. 이름은 비슷하지만 역할이 다릅니다.

HITL은 확실하지만 인간이 대기하고 있어야 합니다. HOTL은 빠르지만, 멈추는 버튼과 이상을 알아차리는 메커니즘이 필요합니다.

전부를 HITL로 만들면 인간이 피폐해집니다. 어디를 멈추고 어디를 맡길 것인가의 선긋기 그 자체가 설계 대상입니다.

또 하나 중요한 것은, 루프는 서로 다른 시간대의 중첩 구조로 되어 있다는 점입니다.

안쪽의 「몇 분 루프」는 AI에게 맡길 수 있습니다. 하지만 바깥쪽의 루프는 인간이 돌립니다.

「AI에게 통째로 맡겼더니 이상한 것이 만들어졌다」는 것은, 대개 바깥쪽 루프를 아무도 돌리고 있지 않을 때 일어납니다.

이제부터는 자신이 하고 있는 일을 4개의 층으로 대입해 보겠습니다. 기술 기사를 Qiita에 게시하는 작업을 AI와 함께 수행하는 예시입니다.

평범하게 지시를 작성합니다. 이 부분은 특별한 것을 하고 있지 않습니다.

• 프로젝트의 규칙을 CLAUDE.md에 작성한다 (단, 길게 만들지 않는다. 지시서가 길면 지켜지지 않는다는 연구 결과가 있습니다)
• 기사를 쓸 때는 논문의 PDF에서 본문을 추출하여 전달한다. 요약 사이트의 내용은 전달하지 않는다 (요약은 결론이 빠져 있는 경우가 있기 때문)

공정마다 할 일을 정해둔 절차서를 준비해 두었습니다.

특히 검증은 인간의 육안 확인을 그만두고 스크립트로 대체했습니다. 눈으로 직접 확인했을 때 두 번이나 놓쳤기 때문입니다.

이것이 '틀을 끼워 맞추는 것'의 실례입니다. '주의해서 확인한다'가 아니라, 기계가 0건이라고 말할 때까지 앞으로 나아가지 않는다.

• 수 분 단위의 루프 (Loop): AI가 작성 → 검사 스크립트 실행 → 걸리면 수정. 이 부분은 AI가 스스로 돌립니다.
• 수십 분 단위의 루프 (Loop): 나온 기사를 읽고, 방향이 다르면 축(Axis)부터 수정. 이 부분은 인간 (HITL)
• 주 단위의 루프 (Loop): 좋아요 수나 조회수를 보고, 다음에 무엇을 쓸지 결정. 이 부분도 인간

가장 효과가 컸던 것은 수 분 단위의 루프를 자동화한 것이었습니다. 지금까지 제가 직접 했던 체크를 기계가 대신 해줍니다.

반대로, 바깥쪽 루프를 자동화하려고는 하지 않습니다. '무엇을 써야 하는가'는 AI가 결정할 수 없기 때문입니다.

초보자를 위한 결론으로서, 순서대로 올라가는 것이 좋다고 생각합니다.

갑자기 ④부터 시작하더라도, ②와 ③이 없으면 이상한 방향으로 고속 주행할 뿐이 됩니다.

그리고 ④까지 도달하면 인간의 역할이 바뀝니다.

'AI에게 뭐라고 말할까'를 고민하는 사람에서, 'AI가 어떻게 돌아갈까'를 설계하고 감시하는 사람으로.

이것이 이 4개의 층을 관통하는 가장 큰 변화라고 생각합니다.

• '〇〇 엔지니어링'은 별개의 수법이 아니라, 중첩된 4개의 층
  • ① 프롬프트 (무엇이라 말할 것인가) → ② 컨텍스트 (무엇을 알려줄 것인가) → ③ 하네스 (무엇을 시킬 것인가) → ④ 루프 (어떻게 돌릴 것인가)
• 새로운 것이 오래된 것을 대체하는 것이 아니라, 바깥쪽을 만들려면 안쪽도 필요하다
• 루프에는 **HITL (멈추고 기다림)**과 **HOTL (감시하다가 필요하면 멈춤)**이 있다
• 루프 자체도 수 분·수십 분·주 단위의 중첩 구조. 안쪽은 AI에게 맡길 수 있지만, 바깥쪽은 인간이 돌린다

우선은 ②부터 시작하세요. 프로젝트의 규칙을 파일 하나에 적는 것만으로도 돌아오는 답변이 달라집니다.

참고

• 「〇〇 엔지니어링」이 너무 많아져서 정리해 보았다 — 4층의 중첩 구조에 대해 이 기사보다 더 자세한 정리가 있습니다
• Human in the Loop (HITL) vs Human on the Loop (HOTL) — 두 가지 차이에 대한 해설