그냥 자동화와의 차이, 그리고 하네스의 한 층 위

앞 편에서 루프 엔지니어링을 "지시하는 사람을 시스템으로 갈아 끼우는 일"로 정의했습니다. 이 편은 그 정의를 들었을 때 가장 먼저 나오는 반문, "그거 옛날부터 있던 자동화랑 뭐가 달라?"에 답합니다. 그리고 프롬프트 엔지니어링에서 컨텍스트, 하네스를 거쳐 루프로 이어지는 흐름 속에서 루프가 어느 층에 있는지를 봅니다.

읽고 나면 자기 작업이 "자동화"인지 "루프"인지 세 가지 기준으로 가를 수 있고, 하네스와 루프를 섞어 부르지 않게 됩니다. 다음 편은 루프를 언제 써야 하는지와 부품 다섯 가지를 다룹니다.

핵심 요약

• 그냥 자동화와 루프의 차이는 세 가지입니다. 검증이 내장돼 있는가, 절차 대신 목적을 받는가, 돌릴수록 나아지는가.
• 프롬프트, 컨텍스트, 하네스, 루프는 각각 "무엇을 말할까", "무엇을 보여줄까", "무엇을 막을까", "누가 다음 바퀴를 돌릴까"에 답합니다.
• 하네스는 규칙과 게이트이고, 루프는 그 하네스 위에서 실행과 검증을 반복시키는 관제실입니다.
• 하네스만으로는 한 번의 실행을 안전하게 만들 뿐, 다음 실행을 스스로 시작하지 못합니다.

그냥 자동화와 뭐가 다른가, 세 가지 차이

"그거 옛날부터 있던 자동화랑 뭐가 달라?"에 대한 답

정당한 질문입니다. 우리 맥미니에는 launchd 잡이 여럿 돌고 있습니다. 매일 00시 30분에 그날의 작업 기록을 모아 노션 「작업 일지」에 쓰는 잡, 5분마다 원격 데스크톱 프로세스를 살피는 워치독, 사이트를 띄우는 잡. 이것들은 전부 "자동화"입니다. 그중 일부만이 "루프"입니다. 구분선은 다음 세 가지입니다.

첫째, 검증이 내장돼 있다

그냥 자동화는 "정해진 절차를 정해진 시각에 실행"합니다. 성공했는지는 사람이 나중에 로그를 열어 봐야 압니다. 루프는 실행 직후 완료 조건과 대조하는 단계가 안에 들어 있고, 그 결과에 따라 다음 행동이 갈립니다.

배포 스킬 deploy-mini가 예입니다. 미니에서 pull, 설치, 빌드, launchctl kickstart까지는 절차입니다. 그 뒤에 로컬 4400 포트와 도메인이 200을 돌려주는지 확인하고, 실패하면 에러 로그의 첫 Error: 줄을 읽어 보고하는 단계가 붙어 있습니다. 이 마지막 단계가 없으면 "배포 자동화"이고, 있으면 "배포 루프"입니다. 7주차 교재의 문장을 빌리면, 무인 잡은 만들었을 때가 아니라 로그를 확인할 때 믿을 수 있습니다. 루프는 그 확인을 사람 대신 시스템이 합니다.

둘째, 절차가 아니라 목적을 준다

크론 잡에는 명령을 줍니다. pnpm build && pnpm start. 루프에는 목적을 줍니다. "홈 페이지 구조 유사도 95 이상." 절차는 시스템이 스스로 찾습니다. 디자인 벤치마크에서 우리는 "어느 CSS를 어떻게 바꿔라"를 한 번도 미리 적지 않았습니다. 채점자가 라운드마다 수정 지시를 다섯 개 이하로 내놓고, 제작자가 반영하고, 다시 채점받았습니다. 절차는 62라운드 동안 매번 달랐고 목적은 한 번도 바뀌지 않았습니다.

이 차이가 중요한 이유는 절차가 깨지는 순간 때문입니다. 원본 사이트의 클래스명이 바뀌면 절차형 스크립트는 죽습니다. 목적형 루프는 실측 단계에서 새 클래스명을 읽고 계속 갑니다.

셋째, 쓸수록 스스로 개선된다

크론 잡은 백 번을 돌아도 백 번째가 첫 번째와 같습니다. 루프는 라운드마다 남긴 기록이 다음 라운드의 입력이 됩니다. 채점자가 "스티키 헤더가 없다"고 오판했을 때 우리는 scrollY 700에서 헤더 top이 66px인 실측값으로 반박하고 기록했습니다. 그 뒤 같은 오판은 나오지 않았습니다. 이 개선이 사람 손으로 프롬프트를 고친 결과라는 점은 솔직히 적어 둡니다. 다만 고친 프롬프트가 스킬 파일에 남아 다음 작업부터 자동 적용된다는 점에서 루프는 돌릴수록 나아집니다.

한마디로 정리하면

자동화는 "같은 일을 같은 정확도로 반복"하고, 루프는 "목적을 향해 검증하며 반복하되 기록을 남겨 다음 바퀴를 더 잘 돌게" 합니다. 검증, 목적, 개선. 셋 중 하나라도 없으면 아직 자동화입니다.

프롬프트, 컨텍스트, 하네스, 루프의 흐름

뜬금없어 보여도 실은 쌓여 온 흐름

루프 엔지니어링이 갑자기 튀어나온 유행어처럼 보일 수 있지만, 지난 몇 년의 관심사를 순서대로 놓으면 자연스럽게 다음 칸입니다.

초점은 이렇게 옮겨 왔다

프롬프트 단계의 관심은 한 번의 요청 문장이었습니다. 컨텍스트 단계에서는 요청 주변에 무엇이 놓이는지로 넓어졌습니다. Claude Code 문서가 CLAUDE.md를 "강제된 구성이 아닌 컨텍스트"로 부르는 이유입니다. 하네스 단계에서는 모델이 무엇을 결정하든 클라이언트가 강제하는 층이 생겼습니다. 같은 문서가 "작업을 차단하려면 PreToolUse 훅을 쓰라"고 적는 것이 그 층입니다. 루프 단계에서는 관심이 한 번의 실행에서 실행의 열로 옮겨갑니다. 이번 실행이 끝났을 때 다음 실행을 누가 시작하느냐가 질문입니다.

단계를 잇는 피드백 루프

네 단계는 포함 관계입니다. 루프 안에서 매 바퀴 프롬프트가 쓰이고, 컨텍스트가 실리고, 하네스가 막습니다. 반대로 루프가 남긴 기록은 다시 프롬프트(스킬의 채점 뼈대), 컨텍스트(CLAUDE.md의 규칙 한 줄), 하네스(새 훅)로 흘러 들어갑니다. 결제 코드 교차 리뷰 4라운드에서 경쟁 조건을 찾은 뒤 프로젝트 규칙 6번 "결제 코드 수정 시 교차 리뷰 필수"가 추가된 것이 그 예입니다. 루프의 산출물이 하네스가 됐습니다.

루프는 하네스의 "한 층 위"에 있다

왜 "한 층 위"라고 부르는가

하네스는 실행 한 번을 안전하게 만듭니다. 위험한 명령을 막고, 편집 뒤에 린트를 돌리고, 멈추려 할 때 테스트 통과를 요구합니다. 그런데 하네스는 스스로 다음 실행을 시작하지 않습니다. Stop 훅이 exit code 2로 "아직 멈추지 마라"를 되돌릴 수는 있지만, 그것은 한 세션 안의 이야기입니다. 세션이 닫히면 하네스도 잠듭니다.

루프는 그 위에 있습니다. launchd가 00시 30분에 세션을 새로 열고, /loop 20m이 20분마다 프롬프트를 다시 넣고, 채점 스크립트가 "수정 필요"를 받으면 제작 세션을 다시 부릅니다. 하네스가 "이 실행이 규칙을 지키는가"를 보는 층이라면, 루프는 "다음 실행이 필요한가, 필요하면 무엇을 들고 시작하는가"를 보는 층입니다. 그래서 한 층 위입니다.

건물에 비유하면 관제실이다

프롬프트는 각 방에 붙은 작업 지시서, 컨텍스트는 방에 들어갈 때 쥐는 도면과 자재, 하네스는 방마다 달린 잠금장치와 화재 감지기입니다. 루프는 옥상의 관제실입니다. 어느 방의 작업이 끝났는지 보고, 검사관을 보내고, 불합격이면 같은 팀을 다시 넣고, 합격이면 다음 방을 엽니다. 관제실은 잠금장치를 대신하지 않습니다. 잠금장치 없는 건물에 관제실만 있으면 사고가 빨리 반복될 뿐입니다. 우리가 루프를 돌리기 전에 "운영 DB는 성역", "결제 금액은 서버가 정한다" 같은 하네스부터 세우는 이유입니다.

정리

• 자동화와 루프를 가르는 기준은 검증 내장, 목적 입력, 기록을 통한 개선 세 가지입니다.
• 프롬프트, 컨텍스트, 하네스, 루프는 순서대로 쌓인 흐름이며 포함 관계입니다.
• 루프가 남긴 기록은 다시 프롬프트, 컨텍스트, 하네스로 흘러 들어갑니다.
• 하네스는 한 번의 실행을 지키고, 루프는 다음 실행을 시작합니다. 그래서 루프는 하네스의 한 층 위입니다.
• 하네스 없는 루프는 사고를 빨리 반복하는 장치입니다.

자주 묻는 질문