「루프 엔지니어링 (Loop Engineering)」이 확산되고 있다

최근 「루프 엔지니어링 (Loop Engineering)」이라는 설계 기법을 자주 접하게 되었다.

손으로 AI 에이전트에게 프롬프트를 입력하는 대신, 에이전트에게 계속해서 지시를 내리는 메커니즘(루프) 그 자체를 설계하는 방식이다. "이제 에이전트에게 프롬프트를 입력하지 마라, 에이전트에게 프롬프트를 입력하는 루프를 설계하라"고 말한 Peter Steinberger, "내 업무는 루프를 쓰는 것이다"라고 말한 Anthropic의 Boris Cherny——그 흐름을 Google의 Addy Osmani가 2026년 6월 7일, 「Loop Engineering」이라는 이름을 붙여 정리했다.

목적을 한 번 정의하면, 나머지는 AI가 완료될 때까지 자율적으로 실행된다는 것이 그 발상이다. 엔지니어의 손은 「코드를 작성하는 것」에서 「루프를 설계하는 것」으로 옮겨간다고 설명된다. 목표를 정하고, 성공 기준을 세우고, 검증 메커니즘을 구축하며, 아키텍처 판단을 쥐는 것으로 말이다.

여기서 흥미로운 점은, 루프 엔지니어링을 이야기하는 사람들 스스로가 그 본질을 "맡길 범위와 인간이 남길 범위의 경계 짓기 그 자체다"라고 표현하고 있다는 것이다.

즉, 새로운 것은 「AI에게 맡길 수 있는 것」이 아니다. 어디까지를 맡기고, 어디서부터를 자신이 계속 쥐고 있을 것인가라는 경계를 설계하는 것——AI로 개발하는 현장에 몸담고 있으면, 지금 전면에 나서고 있는 것은 바로 이것이라고 나에게는 보인다. 그리고 이 경계 짓기는 루프 엔지니어링이라고 자칭하든 아니든, 지금 AI를 사용하는 모든 사람의 손안에서 이미 일어나고 있는 것처럼 보인다.

Osmani 자신도 기사 말미에 이렇게 적었다——같은 루프라도, 깊이 이해하고 있는 작업을 가속하기 위해 사용하는 사람과, 이해를 피하기 위해 사용하는 사람 사이에서 결과는 정반대가 된다. 루프는 그 차이를 알지 못한다. 사용하는 본인만이 알 수 있다고 말이다.

그리고 선을 긋는 것은 동시에 자신의 작업을 한 단계 위로 이동시키는 것이기도 하다——나에게는 그렇게 보인다. 코드를 쓰던 손이 리뷰 관점을 선택하는 손이 된다. 구현하던 손이 사양(Specification)을 쓰는 손이 된다. 수중에 있는 세세한 작업을 AI에게 넘긴 만큼, 자신의 손은 그 한 단계 위의 작업으로 옮겨간다.

질문

문제는 이 이동이 빠르고 조용하게 일어나기 때문에 당사자에게는 잘 보이지 않는다는 점이다. 나 자신도 내 손이 지금 어디에 있는지 즉시 말로 표현하지 못할 때가 있다. 「편해졌다」 「빨라졌다」는 실감만이 남을 뿐이다.

그래서 한 가지 묻고 싶다.

당신은 어떤 작업을 AI에게 넘겼으며, 그 결과 자신은 무엇을 내려놓고 무엇을 쥐게 되었는가? 그것을 자각하고 있는가?

「어떤 작업을 넘겼는가」 「그 결과, 자신은 지금 무엇을 쥐고 있는가」. 이것에 답할 수 없다면, 경계 짓기는 스스로 설계한 것이 아니라 어느샌가 저절로 내려가고 있는 것일지도 모른다.

실례: 나의 경우 ― L2A-SCP에서 무엇을 옮겼는가

독자에게 묻기 전에, 먼저 스스로 답해본다.

나는 L2A-SCP(SPEC Compiling Pipeline)라는 개발 프로세스를 만들어 사용하고 있다. 한마디로 말하면, SPEC과 유스케이스(Use Case)를 넣으면 그 이후의 구현이 나오는 상태로 만든 것이다.

예를 들어 「사용자는 이메일 주소로 로그인할 수 있다」라는 유스케이스를 넣으면, 거기서부터 사양·테스트 관점·구현·대응 관계 검사가 순차적으로 생성된다. 다만, 그 유스케이스가 타당한지, 수락 조건은 무엇인지, 마지막에 출하해도 좋은지는 인간이 쥐고 있다.

무엇을 AI에게 넘겼는가. SPEC 이후의 단계——코드 생성, 테스트 생성, 리뷰 관점 적용, 사양과 구현의 대응(Traceability) 검사. 손을 움직이는 대상이 「코드를 작성하는 것」에서 「SPEC과 유스케이스를 작성하는 것 = 무엇을 만들 것인지를 정의하는 것」으로 올라갔다. 나의 손은 코드에서 한 단계 위의 작업으로 옮겨간 것이다.

무엇을 자신의 손에 남겼는가. 두 가지가 있다. 하나는 안건 안에서의 판단——무엇을 만들지 쓰는 것, 출력을 의심하는 것, 마지막에 「이것을 내보낸다」고 결정하는 것. 승인·기각이나 완성 판정이 인간에게 남도록 메커니즘으로 구성되어 있다. 다른 하나는 더 높은 층이다——이 개발 프로세스(L2A-SCP) 자체를 만들고, 관리하고, 유지보수하는 것. 무엇을 AI에게 넘기고 무엇을 계속 쥐고 있을 것인가라는 경계를 설계하고, 그 경계를 구현한 메커니즘 자체를 계속 유지하는 것. 이 부분은 누구에게도 넘기지 않았다.

넘긴 것은 부하가 사라진 것이 아니라 이동한 것이다. 코드를 작성하는 부하는 줄었지만, 대신 — "사양이 올바른가", "이 출력을 믿어도 되는가", "이것을 내보내도 되는가"라는 판단과, 그리고 프로세스 그 자체를 설계하고 유지보수하는 일에 부하가 집중되게 되었다. 손을 뗀 것이 아니다. 손을 움직이는 장소가 코드에서 사양과 프로세스 설계로 올라갔을 뿐이다.

보충 설명을 하나 하자면, AI는 확률적으로 출력하기 때문에 때때로 나쁜 결과가 섞인다. 그래서 L2A-SCP는 AI 내부를 건드려 똑똑하게 만드는 것이 아니라, AI의 외부에 여러 개의 독립적인 확인 경로를 두어 어긋남을 관측하도록 설계되어 있다. 이것 역시 "무엇을 넘기고, 무엇을 자신(과 독립된 메커니즘)에게 남길 것인가"라는 경계 긋기의 일부다.

L2A-SCP와 트레이서빌리티 (Traceability) 부품인 legixy는 아직 초기 단계의 시도이며, 모든 중간 성과물을 공개하고 있다:

자각의 유무로 결과는 달라진다

이것은 정신론이 아니다. 관측 결과가 있다.

Anthropic이 2026년 초에 공개한 실험에서, 52명의 엔지니어(대부분 주니어)에게 참가자들에게 미지의 Python 라이브러리(Trio)를 학습시켰다. 절반은 AI 지원이 있었고, 절반은 없었다. 직후에 이해도 퀴즈를 실시한 결과, AI를 사용한 집단은 직접 작성한 집단보다 17% 낮았다 (대략 2단계의 성적 차이). 작업 속도는 조금 빨라졌지만, 그 차이는 통계적으로 유의미하지 않았다.

하지만 중요한 것은 그 이후다. 연구자들은 다음과 같이 결론짓고 있다 — 모든 AI 의존이 동일한 것은 아니다. 효율을 위해 AI와 어떻게 관계를 맺느냐가 얼마나 배울 수 있는지를 좌우한다라고.

점수가 낮았던 사람들은 AI에게 코드 생성을 통째로 맡긴 사람들(40% 미만)이었다. 점수가 높았던 사람들은 AI에게 개념적인 질문을 던지고 설명을 요구하며, 이해를 쌓아가며 사용한 사람들(65% 이상)이었다. 같은 도구, 같은 시간, 정반대의 결과. 이를 가른 것은 — 무엇을 넘기고, 무엇을 자신의 손(이해·판단)에 남겼는가가 아니겠는가. 나는 이 결과를 그렇게 읽고 있다.

가장 큰 차이는 디버깅에서 나타났다. 통째로 맡긴 사람들은 자신의 코드가 왜 망가질 수 있는지 설명하지 못했다고 한다. 넘겨준 대상에 대해 자신은 더 이상 알지 못한다 — 그런 상태가 조용히 진행되는 것이라고, 나는 이 숫자를 보며 생각한다.

물론 이 실험은 "미지의 라이브러리를 배우는 단시간 태스크"였으며, 작업 직후의 이해도를 측정한 것이다. 이미 익숙한 영역의 구현 모두에 그대로 적용되는 것은 아니며, 연구자 자신도 샘플의 크기와 단기 측정의 한계를 언급하고 있다. 하지만 — AI에게 작업을 넘길수록, 이해·디버깅·감독의 힘을 어디에 남겨둘지를 설계해야만 한다. 적어도 나는 이 연구를 그렇게 받아들이고 있다.

자신의 손을 점검하기

그러므로 방법론의 좋고 나쁨을 논하기보다, 자신의 손을 점검하고 싶다. 우선 두 가지만 확인하자.

• 넘겨준 검증을 다시 똑같은 상대(똑같은 AI)에게 확인시키고 있지는 않은가? 확인하는 눈이 넘겨준 대상으로부터 독립되어 있는가?
• "이것으로 정말 괜찮은가"라는 되묻기나, "이것을 내보낸다"라고 결정하는 판단까지 나도 모르게 넘겨버리고 있지는 않은가?

그 후에, 자신의 경계 긋기를 한 번 표로 써보는 것이 좋다.

채우는 방식은 현장마다 달라도 좋다. 중요한 것은, 채워지지 않는 행이 있다면 그곳이 "어렴풋이 넘기고 있는" 장소라는 점이라고 생각한다.

어디까지 넘길지는 도메인과 실패 비용이 결정한다

넘겨도 좋은 범위는 일률적이지 않다. 실패의 비용이나 영향 범위에 따라 달라진다.

개인이 사용하는 CLI 도구처럼 망가져도 타격이 작은 것이라면, 구현부터 검사까지 통째로 넘겨도 좋다. 쥐고 있는 것은 "이것이 내가 원했던 것인가"라는 얇은 한 점이면 충분하다.

반면, 임베디드(Embedded)나 규제 분야처럼 실패의 비용이 큰 경우에는 경계 긋기를 상단에 유지해야 한다. 최종 판단과 넘겨준 대상으로부터 독립된 확인은 손에 남겨둔다. 여기서 선을 너무 낮추면, 저렴하고 빨라진 대신에 쥐어야 할 것을 놓쳤다는 사실을 나중에 깨닫게 될 것이다.

어디에 선을 그을지는 당신과 도메인이 결정할 일이다. 다만, 선을 긋고 있다는 사실을 자각하고 있는 것만은 어떤 도메인에서도 변하지 않는다.

분리(切り分け)는 지금 요구되는 능력이다

AI가 업무에 들어온 지금, 특히 관리직이나 리드 엔지니어에게 요구되는 것은 — 어떤 작업을 AI에게 맡기고, 어떤 작업을 인간이 할 것인지를 논리적이고 명확하게 분리하는 능력이라고 나는 생각한다.

여기서 「논리적으로」라는 말이 핵심이다. 경계선은 취향이나 기세로 긋는 것이 아니어야 한다. 하나하나의 작업에 대해, 왜 그것을 맡기는지, 왜 그것은 남겨두는지를 이유를 들어 말할 수 있어야 한다. 실패 비용이 작기 때문에 맡긴다. 독립적인 확인이 필요하기 때문에 별도의 계통으로 돌린다. 이것은 인간만이 판단할 수 있기 때문에 남겨둔다——그렇게 설명할 수 있는 선이 설계된 선이라고 생각한다. 설명할 수 없다면, 그것은 그저 퇴보하고 있는 선일지도 모른다.

그리고 상위에 있는 사람일수록, 이러한 구분은 자신만을 위한 것이 아니게 된다. 팀의 경계선을 어디에 그을지, 무엇을 출하해도 좋을지에 대한 책임을 지는 입장에서는, 그 선을 자신의 언어로 제시할 수 있는 것이 곧 업무가 된다.

결국의 질문

도구는 언제나 똑같은 일을 해온 것처럼 보인다. 어떤 작업의 실행 비용을 낮추고, 인간의 손을 그 한 단계 위로 밀어 올린다. AI도 마찬가지일 것이다. 다만 다른 점은, 그 이동이 빠르고, 조용하며, 심지어 기분 좋게 일어난다는 것이다. 생각을 멈춰도 결과물은 그럴싸하게 완성된다. 그래서 이동하고 있다는 사실을 알아차리기 어렵다.

다시 한번, 질문을 던진다.

당신의 업무 중 어느 부분이 지금 AI로 대체되고 있는가. 당신은 그것을 의식하고 있는가.

AI를 사용하는 능력은 프롬프트 (Prompt)를 작성하는 능력만이 아니다. 어떤 작업을 맡기고, 어떤 판단과 책임을 인간에게 남길지를 설계하고, 그 선을 자신의 언어로 설명할 수 있는 능력이다. 그 지점이 앞으로의 개발 프로세스를 가를 것이다.

참고

Addy Osmani,

Loop Engineering(2026년 6월 7일. Peter Steinberger·Boris Cherny의 발언을 토대로 정리)

Anthropic,

How AI assistance impacts the formation of coding skills(52명·17%·「not all AI-reliance is the same」의 출처. 연구자 스스로가 샘플이 작고 작업 직후의 이해도를 측정한 것이며, 장기적인 기술 형성을 직접적으로 나타내는 것은 아니라는 한계를 명시)

(관련) L2A-SCP / SPEC Compiling Pipeline

Discussion