루프 설계? 결국 사람의 일을 줄인다.

프롬프트를 잘 쓴다는 게 능력인 줄 알았다

Claude Code를 반년째 쓰고 있다. 매일 쓴다. 그러면서 이상하게 느낀 게 있다. 반년을 매일 썼는데 나는 여전히 같은 자리다. "이 파일 수정해", "테스트가 틀렸잖아", "다시 해봐". 그 다음엔 또 기다린다. 결과를 보고, 또 명령 하나 던진다. 도구는 더 좋아졌는데 나는 더 나아졌나, 라는 질문을 반년 만에 처음 했다.

루프라는 걸 들은 건 꽤 됐다. 그런데 솔직히 말하면 나는 그게 코딩하는 사람들 얘기인 줄 알았다. 아니면 MCP 설정에 여섯 시간 쓸 수 있는 덕후들 얘기. 나는 그 사람들이 아니니까 패스했다. 반년을 매일 쓰면서도 그 개념이 내 얘기라는 생각을 한 번도 못 한 거다. 그게 실수였다는 걸 최근에야 알았다. 루프는 코딩 얘기가 아니었다. 일하는 방식 얘기였다. 그리고 그 방식에서 나는 아직도 한 단계 아래에 있다.

내생각은 단순하다. 루프를 제대로 꾸미는 것만이 이 무한 노가다에서 빠져나올 길이다. 매번 AI 옆에 앉아서 다음 명령을 생각해내는 것, 그게 노가다가 아니면 뭔가.

---

솔직히 말하면 나는 프롬프트를 꽤 잘 쓴다고 생각했다. 맥락을 잘 설명하고, 원하는 출력 형식을 정해주고, 예시를 넣고. 주변에서도 "프롬프트 엔지니어링"이라는 말을 쓰면서 그게 새로운 스킬이라고들 했다. 나도 그 말을 믿었다. 

 

그런데 Claude Code를 직접 만든 보리스 천(Boris Cherny)이 한 말을 들었을 때 기분이 묘했다. 그는 이제 Claude에게 직접 프롬프트를 쓰지 않는다고 했다. 대신 루프를 돌리고, 그 루프가 Claude에게 프롬프트하게 한다고. 일하는 층위가 달라졌다는 거다. "그냥 요리하게 놔둬라"는 표현도 썼다. 요리사한테 간 맞춰, 불 세기 낮춰, 뒤집어 — 이러고 있는 게 나라는 거다. 셰프 옆에서 조리 보조 하는 중간관리자.

프롬프트를 잘 쓰는 게 능력인 줄 알았는데, 그 능력 자체가 이미 한 단계 아래의 일이 되고 있다. 이게 제일 불편한 부분이다. 배워봤자 이미 구식이 된다는 그 타이밍의 문제. 반도체 업계 20년 일하면서 이 패턴을 몇 번이나 봤는지 모르겠다. 기술이 바뀌는 게 아니라 — 일하는 방식의 층위가 통째로 올라가 버리는 것. 그때도 나는 항상 한 박자 늦었다.

---

리모콘을 잡고 있는 사람의 문제

기존 방식을 정확하게 묘사하자면 이렇다. AI한테 일을 시키는데, 매번 다음 명령을 사람이 만들어 낸다. "이 파일 고쳐" → 결과 확인 → "테스트 잘못됐잖아" → 결과 확인 → "이 부분 다시". 이게 리모콘 방식이다. 채널 하나 누르고, 화면 보고, 또 누르고.

문제는 이 방식이 나쁜 게 아니라는 데 있다. 결과는 나온다. 그리고 내가 개입하고 있다는 느낌도 있다. 주도하는 기분. 그런데 그게 착각이다. 삼국지2에서 무장을 클릭클릭 움직이는 것과 시나리오를 짜는 건 다르다. 전자는 매 순간 개입하는 것처럼 보이지만 판을 주도하는 게 아니다. 판을 짜는 사람 따로, 클릭하는 사람 따로. 나는 계속 클릭만 했다.

루프 방식은 다르다. 처음에 목표를 정하고, 완료 기준을 설계하고, 반복 조건을 걸어두면 — AI가 그 안에서 알아서 반복 검증하며 완수한다. 사람이 매번 옆에 없어도 된다. 아니, 있어봤자 방해다. 요리사한테 맡겼으면 주방에서 나와야지.

---

loop.md라는 게 뭔지 궁금해서 찾아봤다

처음 들었을 때 loop.md가 새로운 AI 기능인 줄 알았다. 아니었다. 문서다. 설계 문서 위에 얹는 '감독관 문서'라는 표현이 맞는 것 같다. AI에게 "이걸 완수했다고 판단하려면 이 기준을 통과해야 한다"를 명시해두는 문서.

보리스 천이 이 영상에서 제시하는 방식으로는, 루프 기준에 세 층위가 있다. 첫째, 필수 통과 조건 — 빌드, 타입 체크, 테스트. 이 중 하나라도 실패하면 완수가 아니다. 둘째, 측정 — 숫자로 보여줄 수 있는 것. 셋째, 평가 — 1점에서 5점. 단, 점수만 쓰면 안 된다. 근거와 수정 액션이 반드시 붙어야 한다.

점수만 쓰게 하면 의미가 없다. AI도 자기 일에 후한 점수를 준다. 사람이랑 똑같다. 오상무한테 자기 성과 자평하라고 하면 전부 A+다. 왜 그 점수인지, 뭘 고쳐야 하는지가 있어야 루프가 제대로 돈다.

이게 AI 루프 설계의 문제라는 게 이제 이해된다. AI한테 "잘 됐어?" 물어보는 게 아니라, "이 조건들이 전부 통과됐는지 확인하고, 통과 안 된 게 있으면 뭘 고쳐야 하는지 써라" — 이게 루프 설계다.

---

AI한테 뭘 맡기고 뭘 내가 해야 하는지 — 그게 설계다

루프를 잘못 설계하면 사고 제조기가 된다.

예시가 구체적이다. PR 상태는 15분마다 자동으로 확인하고, CI 실패 원인을 분류하고, 단순 수정은 자동으로 처리한다. 여기까지는 AI가 한다. 그런데 DB 스키마 변경이나 인증 정책 변경은 사람한테 넘긴다. 이 경계를 명확하게 설정해두지 않으면 AI가 혼자 DB를 바꾸는 사태가 생긴다.

이건 비단 코딩 얘기만이 아니다. 내가 지금 하는 블로그 자동화 파이프라인에도 같은 원리가 적용된다. 자막 추출, 요약 생성, 초고 작성 — 여기까지는 루프로 돌린다. 그런데 글감 선택, 최종 발행 결정 — 이건 내가 한다. 경계를 어디에 그을 건지가 루프 설계의 전부다.

나는 지금까지 이 경계를 매번 즉흥으로 결정했다. 결과물 보고, 어 이건 내가 해야겠다, 어 이건 맡겨도 되겠다. 그게 리모콘이었다. 경계를 미리 설계해두는 게 루프다.

---

결국 내가 해야 할 일은 설계다

프롬프트를 잘 쓰는 것과 루프를 잘 설계하는 것은 완전히 다른 일이다. 전자는 매 순간 좋은 명령을 만들어내는 것이고, 후자는 명령을 만들지 않아도 되는 구조를 미리 짜두는 것이다. 조리 보조와 셰프의 차이가 아니라, 셰프와 레스토랑 오너의 차이에 가깝다.

문제는 이 설계 자체가 쉽지 않다는 거다. 그리고 잘못 짜면 그냥 불편한 게 아니라 — 루프가 엉뚱한 방향으로 혼자 달려간다. 완료 기준을 명확하게 쓴다는 게, 처음 해보면 막막하다. "잘 됐으면 됐지"를 구체적인 조건으로 바꾸는 훈련이 되어 있지 않다. 수십 년을 "대충 알지 않냐" 문화에서 일한 사람한테는 더 그렇다. 기준을 수치로 쓰고, 통과 조건을 명시하고, 실패 시 액션을 정의하는 것 — 이게 새로운 근육이다. 아직 없는 근육.

그래도 루프를 꾸미는 게 맞다. 설계가 어렵고 실패 비용이 있다는 걸 알면서도, 이 무한 노가다에서 빠져나올 다른 길이 안 보인다. 매번 옆에 앉아서 다음 명령을 생각해내는 것, 그게 지속 가능하지 않다는 건 이미 반년이 증명했다. 루프를 모르면 영원히 리모콘 잡고 있는 사람이 된다. 설계를 잘못 짜면 사고 제조기가 된다. 두 가지 다 싫다고 말은 할 수 있다. 근데 싫다고 해서 바뀌는 건 없다.

나는 지금 loop.md를 하나씩 만들어보고 있다. 아직 서툴다. 기준을 쓰다 보면 내가 뭘 원하는지 모르겠어서 막히는 경우가 더 많다. 도구 문제가 아니라 내 문제다. 결국 이게 항상 내 문제더라.

---

참고 영상

• 프롬프트의 시대는 가고 루프의 시대가 시작되었다 프롬프트 안녕~