언제 써야 하나 — 구성 요소는 5개 + 기억

그냥 자동화와의 차이, 그리고 하네스의 한 층 위에서 루프가 기존 접근의 어디에 놓이는지를 봤다. 이 글은 두 가지 실용적인 질문에 답한다. 하나는 "그래서 언제 써야 하나"이고, 답은 "그 작업이 반복해서 일어나는가"라는 한 줄 기준으로 모인다. 다른 하나는 "실제로 짜려면 뭐가 필요하나"이고, 오스마니가 드는 구성 요소 5개에 토대인 기억을 더한 '5개 + 기억'의 지도를 펼친다. 각 부품은 다음 글 자동화·워크트리·스킬 — 기동 장치, 작업 분리, 프로젝트 지식부터 하나씩 본다.

언제 써야 하나 ── 맞고 안 맞고를 가려내자

판단 기준은 "그거 반복해서 일어나는 작업이냐?"

루프 엔지니어링은 만능 처방이 아니다. 잘 듣는 장면과 그렇지 않은 장면이 뚜렷하다. 판단 기준은 단순하다. "그건 반복해서 일어나는 작업인가?"다.

루프가 힘을 발휘하는 장면

루프가 힘을 발휘하는 건 반복을 전제로 한 작업이다. 오스마니가 드는 예는 이렇다.

• 일간 트리아지 — 매일 아침 새로 들어온 이슈·알림·문의를 분류하고 우선순위를 매긴다
• CI 실패 요약 — 지속적 통합(CI)에서 테스트가 깨질 때마다 원인을 요약해 정리한다
• 정기적인 버그 찾기 — 일정 주기로 코드베이스를 훑어서 수상한 곳을 뽑아낸다

이것들의 공통점은 같은 종류의 작업이 모양을 바꿔 몇 번이고 찾아온다는 점이다. 이런 작업은 한 번 루프로 짜 두면 구축 비용이 횟수로 나뉘면서 금세 회수된다. 발견·실행·검증·기억을 자동으로 돌리는 구조가 매번의 수고를 대신해 준다.

단발 작업에는 과하기 쉽다

반대로 일회성·단발 작업에는 루프 구축 비용이 과해지기 쉽다. '이 메일 초안 하나를 고치고 싶다', '이 설정 파일을 딱 한 번만 바꾸고 싶다' 같은 작업을 위해 완료 조건을 정의하고, 검증 역할을 준비하고, 기억 둘 자리를 정하고… 하며 루프를 짜는 건 누가 봐도 수지가 안 맞는다. 그럴 땐 그냥 프롬프트를 한 번 던지는 게 빠르다.

톤에는 주의하자

톤은 조심해서 읽을 필요가 있다. 원전이 '단발 작업에는 맞지 않는다'고 강하게 단정하지는 않았다. 어디까지나 '루프는 반복을 전제로 한 투자이고, 단발에는 구축 비용이 안 맞기 쉽다' 정도의 얘기로 받아들이면 된다.

판단 요령은 "이 작업을 다음 주에도, 그다음 주에도 하나?"라고 자문하는 것이다. 답이 '한다'면 루프화를 검토할 가치가 있다.

구성 요소는 '5개 + 기억'

추상적인 아이디어를 구체적인 부품으로 떨어뜨린다

루프는 추상적인 아이디어지만 실제로 짜려면 구체적인 부품이 필요하다. 오스마니는 구성 요소로 5개를 들고, 그걸 떠받치는 토대로 기억(상태)을 따로 세워 중요하게 다룬다.

이제부터는 '5개 + 기억'으로 하나씩 글을 나눠 본다. 늘어놓으면 이렇다.

각 요소에는 원문의 취지를 짧게 덧붙인다. Claude Code 쪽 기능과 바로 연결해 두고 싶다면 기존 글 Claude Skills란 무엇인가, MCP — 외부 도구 연결하기, 서브 에이전트로 작업 나누기가 각각 ③·④·⑤의 바탕이 된다. 그럼 ①의 자동화부터 하나씩 보자.

다음 글: 자동화·워크트리·스킬 — 기동 장치, 작업 분리, 프로젝트 지식