루프 엔지니어링이 뭐지?
본격적으로 에이전트 바이브 코딩에 뛰어들 무렵, 가장 인기 있는 도구는 bkit이었다. 나도 그걸 적극적으로 쓰며 한동안 개발했다. 작업에 들어가기 전에 분석과 설계를 촘촘히 세우고, 그 위에서 코드를 짜 내려가는 방식이었다.
그런데 어느 순간 이 방식이 어딘가 ‘바이브’하지 않게 느껴졌다. 바이브 코딩의 매력은 가볍게, 쉽게 접근하는 데 있는데, 시작부터 모든 설계를 끝내 놓고 출발한다는 건 그 가벼움과 정면으로 부딪혔다. 쓰면서도 계속 불편했다.
그래서 설계라는 개념 자체를 지워 버렸다. 대신 역할을 바꿨다. 나는 앱을 만들고 싶은 고객이고, 에이전트는 내가 돈을 주고 고용한 업체다. 큰 그림을 던지고, 결과를 보고, 다시 요구한다. 요구·분석·추가 요구를 가볍게 주고받으며 세부로 파고들었다. 설계서 대신 대화가 일을 끌고 갔다.
한참 그렇게 일하다 깨달았다. 이 주고받음이 곧 하나의 루프였고, 나는 그 루프의 한 축으로 돌고 있었다. 그런데 좋은 고객은 업체가 짠 코드의 컴파일 에러까지 대신 잡아주지 않는다. 그건 업체의 몫이다. 그렇다면 이 관계에서 고객인 내가 직접 해야 하는 일은 정확히 어디까지인가.
그 불편함의 정체
돌이켜보면 그 불편함에는 구조적인 이유가 있었다. 설계를 다 끝내고 출발하는 방식은 제어이론으로 보면 open-loop, 그러니까 피드포워드(feedforward) 제어다. 지능을 전부 사전 설계에 몰아넣고, 실행은 정해진 궤도를 따라가게 한다. 현실이 설계와 일치하면 이만한 게 없다. 결정론적이고, 싸고, 추적 가능하다.
문제는 현실이 어긋나는 순간이다. 피드백으로 궤도를 고칠 장치가 없으니 그냥 깨진다. 더 나쁜 경우는 깨진 줄도 모르고 끝까지 달려가 그럴듯한 쓰레기를 내놓는 것이다. 에이전트가 다루는 일은 대부분 사전에 다 예견되지 않는다. 그래서 내 설계서는 점점 두꺼워졌는데, 빗나감은 그만큼 줄지 않았다. 예견에 베팅하는 전략의 한계였다.
그래서 나는 루프가 되었다
설계를 내려놓은 자리에 들어온 것이 수동 루프다. 이 구조를 분해하면 정체가 드러난다.
시키고 → [보고] → 고쳐 → [보고] → 고쳐 → ...
(행동) (관찰·판단) (지시)행동(actuator)은 에이전트가 하지만, 결과를 관찰하고(sensor) 다음 행동을 결정하는(controller) 피드백 고리는 전부 내가 닫고 있다. 즉 이 closed-loop의 컨트롤러는 나 자신이다. bkit이 판단을 ‘설계 시점’에 몰아넣은 것이었다면, 수동 루프는 판단을 ‘매 턴 실시간으로’ 사람이 투입하는 것이다. 정반대처럼 보이는 두 방식은 사실 같은 질문에 대한 두 답이다 — 판단을 어디에 둘 것인가, 사전이냐 런타임이냐.
내 “보고"를 분해하면
수동 루프는 편하다. 그러나 나를 모든 것의 컨트롤러로 만든다. 매 턴 내 눈을 들이대야 한다. 그런데 그 “보고"가 정말 전부 내 직관이었을까. 한 작업을 끝까지 따라가 봤다. 로그인 폼에 이메일 검증을 추가하라고 시켰을 때 내가 내린 수정요청들이다.
- “빈 문자열이 통과되잖아, 고쳐”
- “테스트를 안 짰네”
- “에러 메시지가 영어네. 우린 한글 쓰지”
- “됐다. 근데 이 검증 위치를 폼 위로 올려”
네 번 중 세 번은 직관이 아니었다. 빈 문자열과 테스트 누락은 돌려보면 드러나는 것이고, 한글 메시지는 전에도 말했던 규칙이다. 내 직관이 진짜 필요했던 건 마지막 하나, 검증의 위치뿐이었다. 직관은 하나의 덩어리가 아니다. 적어도 세 층이 섞여 있다.
- 객관적으로 체크되는 것 — 안 돌아간다, 시킨 게 빠졌다, 형식이 다르다. 직관이 아니라 그냥 내가 눈으로 빨리 처리했을 뿐이다.
- 말로 된, 아직 안 적은 규칙 — “난 항상 이렇게 해”. 같은 수정을 두 번째 하고 있다면 그것은 직관이 아니라 머릿속에만 있는 규칙이다.
- 진짜 취향 — “이 위치가 더 낫다”. 이건 나에게 남는다. 남는 게 맞다.
눈을 대신할 신호를 만든다
1층과 2층은 사람이 아니어도 된다. 단, 그 자리를 대신할 피드백 신호를 만들어 줘야 한다. 여기가 핵심이자 진짜 어려운 부분이다. 루프 엔지니어링의 난이도는 자동화 배관에 있지 않다. 내 눈을 대신할 만큼 믿을 만한 신호를 제조하는 데 있다.
이미 나와 있는 사례들이 전부 이 한 가지를 변주한다. 무엇으로 사람의 눈을 대체했는가.
- 코딩 테스트 루프 — 코드를 쓰고, 테스트를 돌리고, 실패 로그를 읽어 고치고, 초록불이 들어올 때까지 반복한다. 판사가 사람이 아니라 “돌아가느냐"라는 현실이다. Anthropic이 “Building Effective Agents"에서 정리한 실무의 기본형이다.
- Voyager (Minecraft 에이전트, 2023) — 에이전트가 스킬 코드를 짜서 게임에 실행하고, 게임이 뱉는 에러를 피드백으로 받아 고친다. 환경 자체가 판사다.
- Reflexion (2023) — 실패하면 “왜 틀렸는지"를 스스로 언어로 적어 메모리에 남기고, 다음 시도에 그 메모를 읽고 반영한다. 사람의 교정 지시를 에이전트의 자기 대화로 옮긴 것이다.
- Self-Refine (2023) — 한 모델이 생산자와 비평가를 번갈아 맡아, 초안을 스스로 비평하고 고친다. 객관 신호가 없는 영역에서 근사적인 자기 보고를 만들려는 시도다. 취향을 흉내내려는 프론티어이고, 한계는 분명하다.
공통점은 분명하다. 어느 것도 사람의 직관 그 자체는 아니다. 직관이 필요 없는 부분만 걸러내는 프록시(proxy)일 뿐이다. 여기서 한 칸 도약할 수 있다. 신호로 환원되는 판단은 위임할 수 있다. 위임할 수 없는 것만이 진짜 직관이다. 명확한 규칙을 위임할 수 있다는 이야기를 전에 문서 분류를 두고 한 적이 있는데, 여기서는 그 대상이 실행 제어로 바뀌었을 뿐이다.
덜어내기의 대가, 폭주
신호 없이 덜어내면 그것은 위임이 아니라 폭주다. “보고"를 대충 자동화하면 — 자기 결과를 제대로 판단할 신호가 없는데 “다 됐다” 하고 다음 턴으로 넘어가면 — 에이전트는 헛것을 확신에 차서, 그것도 더 빠르게 만들어낸다. 그래서 잘 닫힌 루프에는 신호만큼이나 제동장치가 필요하다. 종료 조건, 최대 반복 횟수와 토큰 예산, 건드려도 되는 범위를 긋는 권한 경계. 루프를 닫는 기술의 절반은 결국 언제 멈추고 사람을 부를 것인가에 있다.
하네스는 내 개입의 윤곽선을 따라 자란다
이 모든 것 — 도구, 컨텍스트 규칙, 피드백 신호, 종료 조건, 가드레일 — 을 모아 둔 것이 하네스(harness)다. 모델을 둘러싼 제어 구조 전체다. 처음의 bkit과 헷갈리기 쉽지만 인코딩하는 대상이 다르다. bkit은 무엇을 할지(절차)를 적고, 하네스는 맞는지 어떻게 알고 언제 멈추는지(피드백 환경)를 짠다.
그리고 하네스는 한 번에 지어지지 않는다. 개념이 말하는 방식은 이렇다 — 돌려보고, 내가 또 어디에 손을 댔는지 보고, 그 개입이 곧 ‘아직 안 심긴 신호’라는 것을 알아채 하네스에 흡수시킨다. 같은 수정을 두 번 했다면 규칙이 빠졌다는 신호이고, 매번 같은 곳에서 깨진다면 검증이 빠졌다는 신호다. 하네스는 그렇게 내 개입의 윤곽선을 따라 자란다. 루프 엔지니어링은 거창한 사전 설계가 아니라, 이 흡수를 반복하는 일상의 동작에 가깝다.
내 작업은 아직 이 흡수가 본격적으로 시작되기 전 단계에 있다. 지금은 같은 수정을 대체로 손으로 처리한다. 뒤집어 보면, 그렇게 손으로 반복하는 수정들이야말로 하네스로 옮길 후보 목록이 이미 쌓여 있다는 뜻이다. 무엇을 신호로 굳혀야 하는지는, 내가 매 턴 어디에 손을 대고 있는지가 그대로 알려준다.
아직은 내가 루프다
돌아보면 설계서를 두껍게 쓰던 나와 매 턴 눈을 들이대는 지금의 나는, 같은 가정 위에서 다른 방식으로 움직였을 뿐이다. 둘 다 내 판단이 전부 필요하다고 전제한다. 하나는 그 판단을 미리 쏟아부었고, 다른 하나는 실시간으로 쏟아붓는다.
루프 엔지니어링은 사람을 루프에서 빼는 기술이 아니다. 직관이 필요 없는 부분을 하나씩 신호로 바꿔 루프에 흡수시키고, 그렇게 해서 사람에게 남는 것이 직관뿐이게 — 고객은 바이브만, 나머지는 업체가 — 만드는 과정이다. 나를 루프에서 빼는 것이 아니라, 내가 있어야만 하는 자리로 올려보내는 것이다.
이 관점을 실제 작업에 들이면, 지금 매 턴 손으로 하던 검수의 상당 부분은 신호로 넘길 수 있다고 본다. 빈 문자열도, 한글 메시지 규칙도 애초에 내 눈을 거칠 이유가 없던 일이다. 다음 작업부터는 같은 수정을 두 번째로 내뱉는 순간을 신호 삼아, 그것을 손이 아니라 하네스에 올린다. 그렇게 해서 검수 부담이 실제로 얼마나 줄어드는지는 직접 굴려 보며 확인할 영역으로 남겨 둔다.
댓글 0