하네스 엔지니어링도 못했는데 루프 엔지니어링이라고 또 나왔어요!
앗, Codex 에는 /goal 이 있고, Claude Code 에는 /loop 이 있군요.
근데 그래서, 그냥 반복적으로 실행하다 보면 된다고요?
네. 그래서 생긴 프롬프트 엔지니어링입니다.
처음에는 무식하게 ‘목표 줄테니 완성해’ 였지만, 사람들이 이걸 또 하네스 달듯 고도화를 시켜놨습니다.
아랫것들은 이미 여러분이 충분히 경험했을 겁니다.
워크트리: 격리된 공간에서 수행
스킬: 노하우 전수
플러그인: 말 그대로 플러그인이나, 외부 서비스, MCP 등을 연동하여 작업 간 연동해야 할 매개체 정의
서브에이전트: 각 역할을 나눌 담당자들
여기서 2가지 중요한 준비물을 챙기면 됩니다. 바로, 메모리와 목표죠.
목표: 여러분의 요구사항을 이루기 위한 목표를 정량적으로 정의하세요. 정성적 말고 정량적이어야 AI가 말귀를 알아먹습니다.
메모리: 이제 Context 에 에이전트를 맡기지 않습니다. 루프 돌 때마다 그는 잊어먹습니다. 사람이 깜박하듯이 말이죠. 그레서 메모할 곳이 필요합니다. 어디 경로를 쓰든, 아니면 어디 지식 베이스, 혹은 DB 등이 있죠.
그럼 하네스와 무슨 차이가 있냐, 네. 아주 차이 많이 납니다.
하네스: 사람이 ‘시~작’ 하면 끝날때까지 사람이 정한 워크플로를 모두 태웁니다.
루프: 사람이 ‘시~작’ 하면 모르는 채로 시작하고, 또 모르는 채로 시작해서, 목표를 완수할 때까지 같은 작업을 계속 시킵니다.
그럼 이게 효과가 있나요?
네. 그래서 Codex와 Claude 에 공식 추가된 게 위 명령어들입니다.
하지만 그래도 결국엔 사람이 간섭해야 하잖아요!
네 맞습니다. 여러분이 코딩해서 나온 산출들을 누가 쓸 겁니까? 사람이 쓸 거죠?
그럼 사람이 쓰기 좋은지 ‘사람’이 검증해야죠. 누가 검증하겠습니까.
그리고 사람이 손을 볼 수 있는지도 중요하죠. 그러기 위해선 많은 시행착오를 통해 규칙을 완성해야 하겠죠.
루프를 돌기 전, 그리고 그 중간, 그리고 후에 모두 잘 돌아가는지도 파악해야 합니다.
그럼 왜 이게 중요한거에요?
여기서 여러분의 실력이 드러나기 때문입니다. 여러분이 배경지식을 모르면, 그냥 무식하게 목표 주고 루프 돌려서 시-작! 하고 루프 끝나면 다됐다 싶어서 산출물을 제출하겠죠.
하지만 여러분이 어플리케이션을 만드는 사이클을 경험해 봤다면, 설계부터 배포까지 해왔다면, 여기서 루프를 어떻게 해야 하는지 생각하는 자세가 바로 달라집니다.
네. 개발자는 건재합니다. 단, 설계부터 배포까지 전통적인 개발 방식을 얼마나 알고 있느냐에 따라 품질이 천차만별이죠.
정보처리기사 공부했다면 네. 그 지식을 가지고 루프 엔지니어링 하는 겁니다.
아니 개발자 뿐만 아니라 그냥 공무원 될려고 혈안이었던 그 잡자격증을요?
그리고 그거 따고 10년 일하면 감리사 시험자격 주어집니다.
그리고 엔지니어들이 또하나 발견을 합니다.
최근 나온 오픈소스 로컬 모델인 Gemma 4 나 Qwen 3.6 에서 이 기법으로 여태까지 상용 모델을 못따라갔던 한계에서 드디어 빛을 보기 시작했다는 점을요.
