AI에게 일을 맡겼는데 왜 계속 헛돌까: 하네스·루프·그래프 쉽게 이해하기

AI에게 “블로그 글 한 편을 써서 내일 아침에 예약해 주세요”라고 부탁했다고 해볼까요. 문장은 잘 썼는데 같은 글을 두 번 올리거나, 예약 버튼만 누르고 “완료했습니다”라고 말한다면 곤란합니다. 글을 쓰는 능력과 일을 제대로 끝내는 능력 사이에 빈틈이 있는 셈입니다.

하네스 엔지니어링, 루프 엔지니어링, 그래프라는 말은 이 빈틈을 어떻게 다룰지 설명할 때 나옵니다. 이름부터 외우기보다 AI가 무엇을 쓸 수 있고, 결과를 어떻게 확인하며, 다음에 무엇을 할지 생각하면 훨씬 쉽습니다. 아래의 예약 도우미는 이해를 돕기 위한 가상 사례입니다.

하네스: AI가 일할 수 있게 주변을 갖추기

하네스(harness)는 AI가 도구를 쓰고 작업하도록 마련한 환경을 가리킬 때 쓰는 말입니다. 사람마다 포함하는 범위는 조금 다르지만, 이 글에서는 쓸 수 있는 도구, 허용된 행동, 확인 방법, 작업 기록을 묶어서 생각하겠습니다. ‘하네스 엔지니어링’은 이 환경을 설계하고 고치는 일입니다.

예약 도우미에게는 글을 쓰는 기능만 있어서는 부족합니다. 기존 예약을 읽는 도구, 초안을 저장할 공간, 예약 결과를 확인하는 화면이 필요합니다. 어떤 계정과 블로그에서 작업할지, 새 글은 몇 편까지 올려도 되는지도 정해져 있어야 합니다.

“실수하지 마”라는 지시만 길게 적어두는 것과는 차이가 있습니다. 초안만 만들 수 있게 하려면 발행 권한을 주지 않고, 예약까지 맡긴다면 허용한 시간과 글 수를 실제 실행 과정에서 검사하게 만드는 식입니다. 규칙을 적는 일과 도구가 그 규칙을 지키게 만드는 일을 함께 해야 합니다.

그렇다고 하네스가 AI의 틀린 판단을 모두 막아주는 것은 아닙니다. 확인 도구가 엉뚱한 화면을 읽거나 완료 기준이 허술하면 잘못된 결론이 나올 수 있습니다. “예약했다는 답변” 대신 “관리 목록에 제목과 예약 시각이 보이는지”를 확인하도록 만드는 이유입니다.

루프: 한 번 해보고, 결과를 보고, 필요한 만큼 고치기

루프(loop)는 반복입니다. AI 작업에서는 보통 시도 → 확인 → 수정 → 다시 확인하는 흐름을 말합니다. 이 반복에서 무엇을 확인하고 언제 멈출지 설계하는 일을 루프 엔지니어링이라고 부르기도 합니다. 매번 같은 요청을 던지는 것만으로는 충분하지 않습니다.

가령 초안을 읽어보니 같은 설명이 세 번 나왔다면, “더 잘 써” 대신 중복된 문단을 알려주고 하나로 합치게 합니다. 다음에는 실제로 중복이 줄었는지 읽습니다. 실패한 이유가 다음 시도에 반영되어야 반복할 의미가 있습니다.

중요한 점은 모든 행동을 반복해도 되는 것은 아니라는 것입니다. 초안 수정은 다시 할 수 있지만, 예약 요청을 보낸 뒤 화면이 멈췄다고 버튼을 또 누르면 중복 예약이 생길 수 있습니다. 이때 반복할 것은 제출이 아니라 결과 조회입니다. 이미 등록됐는지 확인한 뒤 다음 행동을 정해야 합니다.

멈추는 조건도 처음부터 필요합니다. 가상 도우미라면 “검토를 통과하면 예약으로 이동”, “수정 두 번 뒤에도 해결되지 않으면 사람에게 확인 요청”, “제출 결과가 불명확하면 다시 제출하지 않고 상태 확인”처럼 정할 수 있습니다. 두 번이라는 숫자는 예시이며, 작업에 맞게 정하면 됩니다.

루프를 돌린다고 모델 자체가 자동으로 학습하거나 매번 더 좋은 결과를 내는 것은 아닙니다. 잘못된 평가를 믿고 반복하면 오히려 좋은 부분까지 고칠 수 있습니다. 바뀐 내용과 검사 결과를 남겨야 이전 시도보다 나아졌는지 비교할 수 있습니다.

그래프: 다음에 갈 곳을 그린 작업 지도

그래프(graph)는 작업 단계와 연결 관계를 나타내는 방식입니다. 상자 하나를 ‘기존 예약 확인’이나 ‘초안 검토’ 같은 단계로 보고, 화살표를 다음에 갈 길로 보면 됩니다. 조건에 따라 갈림길을 만들거나 앞 단계로 돌아오는 길도 그릴 수 있습니다.

예약이 없으면 초안을 쓰고, 같은 주제의 예약이 이미 있으면 멈춥니다. 검토를 통과하면 예약하고, 중복 설명이 있으면 수정으로 돌아갑니다. 결과를 확인할 수 없으면 사람의 확인을 기다립니다. 같은 작업이라도 현재 상황에 따라 다음 단계가 달라지는 모습입니다.

그래프가 스스로 똑똑한 판단을 만들어내는 것은 아닙니다. “예약이 있으면 종료” 같은 조건은 프로그램으로 정할 수 있고, 글의 자연스러움처럼 판단이 필요한 부분은 AI나 사람이 맡을 수 있습니다. 누가 무엇을 근거로 길을 고르는지가 핵심입니다.

‘체인’은 보통 A → B → C처럼 순서가 정해진 흐름을 뜻하며, 그래프의 단순한 형태로 볼 수 있습니다. 체인에도 중간 검사와 중단 조건을 넣을 수 있습니다. 그래서 체인은 무조건 낡았고 그래프는 무조건 우수하다는 식의 구분은 정확하지 않습니다. 순서가 늘 같은 일에는 단순한 연결만으로 충분합니다.

작업을 이어가려면 ‘지금 어디까지 했는지’가 필요합니다

도우미가 중간에 꺼졌다가 다시 켜지면 어떨까요. 앞선 대화를 모두 기억할 것이라고 기대하기보다, 초안 위치와 검사 결과, 제출 여부를 남기는 편이 낫습니다. 이런 ‘현재 상황을 나타내는 값’을 상태(state)라고 부릅니다.

가령 “초안 작성 완료 / 중복 검사 통과 / 예약 요청 보냄 / 결과 미확인”이라는 기록이 있다면, 다음 실행은 글을 새로 쓰는 대신 예약 목록부터 확인할 수 있습니다. 재시작 후에도 이어가려면 기록을 파일이나 데이터베이스처럼 남는 곳에 저장해야 합니다.

AI를 여러 개 쓰더라도 이 기록은 중요합니다. 한쪽은 문장을 검토하고 다른 쪽은 이미지 설명을 확인할 수 있지만, 두 AI가 같은 예약 버튼을 각각 누르게 해서는 안 됩니다. 독립된 검토만 나누고 예약 제출은 한 단계에서만 처리하도록 설계할 수 있습니다. 작은 작업은 AI 하나로도 충분하며, 역할을 나누면 전달과 결과 취합에 드는 일도 늘어납니다.

처음에는 다섯 줄짜리 작업 지시서면 됩니다

특정 프레임워크부터 설치할 필요는 없습니다. 먼저 한 가지 일을 골라 다음 다섯 항목을 적어보세요. 아래는 가상 예약 도우미에 적용한 예입니다.

• 목표: 중복되지 않는 글 한 편을 지정한 시각에 예약한다.
• 도구와 권한: 기존 글을 읽고 초안을 저장하며, 허용된 블로그에 한 편만 예약한다.
• 완료 기준: 관리 목록에서 제목, 예약 상태, 날짜와 시각을 확인한다.
• 중단 조건: 로그인에 실패하거나, 수정 한도에 도달하거나, 예약 결과를 확인할 수 없으면 멈추고 기록한다.
• 이어받을 기록: 초안 위치, 검사 결과, 제출 여부, 확인한 글 주소를 남긴다.

이렇게 적어보면 부족한 것이 도구인지, 확인 절차인지, 다음 행동의 기준인지 드러납니다. AI가 계속 헛돈다면 지시문을 더 길게 쓰기 전에, 마지막으로 확인된 사실과 다음에 확인해야 할 사실부터 나눠보세요. 그 두 지점 사이를 연결하는 일이 하네스와 루프를 설계하는 좋은 출발점입니다.